領事 + iptables = :3

2010年に同社は Wargaming 50 台のサーバーと、バックエンド、フロントエンド、ファイアウォールという単純なネットワーク モデルがありました。 サーバの数が増加し、モデルはより複雑になりました。ステージング、ACL を備えた分離 VLAN、次に VRF を備えた VPN、L2 の ACL を備えた VLAN、L3 の ACL を備えた VRF になりました。 頭が回ってる？ 後でもっと楽しくなります。

サーバーが 16 台あったとき、非常に多くの異種セグメントがあるため、涙を流さずに作業することは不可能になりました。 そこで私たちは別の解決策を考え出しました。 Netfilter スタックを取得し、そこに Consul をデータ ソースとして追加し、高速分散ファイアウォールを実現しました。 彼らはルーターの ACL を置き換え、外部および内部のファイアウォールとして使用しました。 ツールを動的に管理するために、製品ネットワークへのユーザー アクセスの管理からネットワーク セグメント間の分離に至るまで、あらゆる場所で使用される BEFW システムを開発しました。

彼は、それがどのように機能するのか、そしてなぜこのシステムを詳しく見る必要があるのか​​を説明します。 イワン・アガルコフ (アンムオール) は、同社のミンスク開発センターのメンテナンス部門のインフラストラクチャ セキュリティ グループの責任者です。 Ivan は SELinux ファンで、Perl が大好きで、コードを書いています。 情報セキュリティ グループの責任者として、彼は定期的にログ、バックアップ、研究開発に取り組んで、ハッカーから Wargaming を保護し、社内のすべてのゲーム サーバーの動作を保証しています。

歴史的情報

私たちがどのようにそれを行ったかを説明する前に、そもそもどのようにしてこれに至ったのか、そしてなぜそれが必要だったのかを説明します。 これを行うには、9 年前に戻ってみましょう。2010 年、World of Tanks が登場したばかりです。 Wargaming には約 50 台のサーバーがありました。

企業サーバーの成長グラフ。

ネットワークモデルがありました。 当時としては最適でした。

2010年ネットワークモデル。

フロントエンドには私たちを壊そうとする悪者がいますが、ファイアウォールがあります。 バックエンドにはファイアウォールはありませんが、そこには 50 台のサーバーがあり、それらはすべて把握されています。 すべてがうまくいきます。

4 年間で、サーバー フリートは 100 倍の 5000 に増加しました。最初の分離されたネットワークが出現しました - ステージング: 本番環境に移行できず、危険な可能性のあるものがそこで実行されていることがよくありました。

2014年ネットワークモデル。

慣性により、私たちは同じハードウェアを使用し、すべての作業は分離された VLAN 上で実行されました。ACL は VLAN に書き込まれ、ある種の接続を許可または拒否します。

2016 年にはサーバーの数が 8000 に達し、Wargaming が他のスタジオを吸収し、追加のアフィリエイト ネットワークが登場しました。 それらは私たちのものであるように見えますが、完全ではありません。VLAN はパートナーに対して機能しないことが多く、VRF を備えた VPN を使用する必要があり、分離はより複雑になります。 ACL 絶縁混合物が成長しました。

2016年ネットワークモデル。

2018 年の初めまでに、マシンのフリートは 16 台に増加しました。セグメントは 000 つありましたが、財務データが保存されている閉鎖されたセグメントを含む残りのセグメントはカウントされていませんでした。 IVS などから VPN 経由で接続されたコンテナ ネットワーク (Kubernetes)、DevOps、クラウド ネットワークが登場しています。 ルールが多くて大変でした。

2018 年のネットワーク モデルと分離方法。

分離には、L2 で ACL を備えた VLAN、L3 で ACL を備えた VRF、VPN などを使用しました。 過度に。

問題

誰もが ACL と VLAN を使用して生活しています。 どうしたの？ この質問には、ハロルドが痛みを隠しながら答えます。

問題はたくさんありましたが、大きな問題は XNUMX つありました。

• 新しいルールによる幾何学的な価格上昇。 新しいルールを追加するたびに、そのようなルールがすでに存在するかどうかを最初に確認する必要があったため、前のルールよりも時間がかかりました。
• セグメント内にファイアウォールはありません。 セグメントはどういうわけか互いに分離されており、内部にはすでに十分なリソースがありませんでした。
• ルールは長期間にわたって適用されました。 オペレーターは XNUMX 時間で XNUMX つのローカル ルールを手書きできます。 グローバルなものは数日かかりました。
• 監査ルールの難しさ。 より正確に言えば、それは不可能でした。 最初のルールが書かれたのは 2010 年で、その作成者のほとんどはもう同社で働いていませんでした。
• 低レベルのインフラストラクチャ制御。 これが最大の問題です。私たちは自分の国で何が起こっているのかよく知りませんでした。

これは、2018 年に「ACL がもう少し必要だ」と聞いたネットワーク エンジニアの様子です。

Решения

2018年の初めに、それについて何かをすることが決定されました。

統合の価格は常に上昇しています。 出発点は、デバイスのメモリが不足したため、大規模なデータセンターが分離 VLAN と ACL のサポートを停止したことでした。

解決策: 人的要因を排除し、アクセスの提供を最大限に自動化しました。

新しいルールが適用されるまでには長い時間がかかります。 解決策: ルールの適用を高速化し、分散化して並列化します。 これには、rsync や SFTP を使用せずにルール自体が千のシステムに配信される分散システムが必要です。

セグメント内にファイアウォールはありません。 セグメント内のファイアウォールは、同じネットワーク内に異なるサービスが登場したときに登場し始めました。 解決策: ホスト レベルでファイアウォール、つまりホストベースのファイアウォールを使用します。 Linux が存在するほとんどすべての場所、および iptables が存在する場所では、これは問題になりません。

監査ルールの問題。 解決策: レビューと管理のためにすべてのルールを XNUMX か所に保管し、すべてを監査できるようにします。

インフラストラクチャに対する制御レベルが低い。 解決策: すべてのサービスとサービス間のアクセスのインベントリを作成します。

これは技術的なプロセスというよりも管理プロセスに近いものです。 特にプロモーションやホリデーシーズンには、週に 200 ～ 300 の新しいリリースがリリースされることもあります。 さらに、これは DevOps の XNUMX つのチームにのみ適用されます。 リリースが非常に多いため、どのポート、IP、統合が必要なのかを確認することは不可能です。 そのため、特別な訓練を受けたサービス マネージャーが必要で、チームに「一体何があるのですか? なぜそれを持ち出したのですか?」と尋ねました。

私たちが立ち上げたすべてを経て、2019 年のネットワーク エンジニアは次のようになりました。

領事

私たちは、サービス マネージャーの助けを借りて見つけたものをすべて Consul に入れ、そこから iptables ルールを作成することにしました。

どのようにしてこれを行うことにしたのでしょうか?

• すべてのサービス、ネットワーク、ユーザーを収集します。
• それらに基づいて iptables ルールを作成しましょう。
• 制御を自動化します。
• ....
• 利益。

Consul はリモート API ではなく、すべてのノードで実行でき、iptables に書き込むことができます。 あとは不要なものを排除する自動制御を考え出すだけで、ほとんどの問題は解決します。 残りはやりながら解決していきます。

なぜ領事なのか？

それ自体は十分に証明されています。 2014 年から 15 年にかけて、パスワードを保存する Vault のバックエンドとしてこれを使用しました。

データを失わない。 Consul の使用中、一度の事故でデータが失われることはありませんでした。 これはファイアウォール管理システムにとって大きな利点です。

P2P 接続は変化の拡散を加速します。 P2P を使用すると、すべての変更がすぐに反映されるため、何時間も待つ必要はありません。

便利なREST API。 Apache ZooKeeper も検討しましたが、これには REST API がないため、松葉杖をインストールする必要があります。

Key Vault (KV) とディレクトリ (サービス検出) の両方として機能します。。 サービス、カタログ、データセンターを一度に保存できます。 これは、私たちだけでなく、近隣のチームにとっても便利です。なぜなら、私たちはグローバル サービスを構築するときに大きなことを考えるからです。

Wargaming スタックの一部である Go で書かれています。 私たちはこの言語が大好きで、多くの Go 開発者がいます。

強力なACLシステム。 Consul では、ACL を使用して、誰が何を書くかを制御できます。 ファイアウォール ルールが他のものと重複せず、これに関して問題が発生しないことを保証します。

しかし、Consul には欠点もあります。

• ビジネス バージョンを使用しない限り、データ センター内で拡張できません。 フェデレーションによってのみ拡張可能です。
• ネットワークの品質とサーバーの負荷に大きく依存します。 Consul は、速度が均一でないなど、ネットワークに遅延がある場合、ビジー状態のサーバー上のサーバーとして適切に動作しません。 これは、P2P 接続と更新配布モデルによるものです。
• 可用性の監視が難しい。 領事の地位にある彼はすべてが順調であると言えますが、彼はずっと前に亡くなっています。

これらの問題のほとんどは Consul を使用することで解決できたので、Consul を選択しました。 会社は代替バックエンドの計画を立てていますが、私たちは問題への対処方法を学び、現在は Consul と併用しています。

領事の仕組み

条件付きデータセンターにXNUMX台からXNUMX台のサーバーを設置します。 XNUMX 台や XNUMX 台のサーバーでは機能しません。データが一致しない場合、クォーラムを構成して、誰が正しく、誰が間違っているのかを判断することができません。 XNUMX つを超えると意味がなく、生産性が低下します。

クライアントは任意の順序でサーバーに接続します。同じエージェントがフラグを使用してのみ接続します。 server = false.

この後、クライアントは P2P 接続のリストを受け取り、クライアント間で接続を構築します。

グローバルレベルでは、複数のデータセンターを接続しています。 また、P2P に接続して通信します。

別のデータセンターからデータを取得したい場合、リクエストはサーバーからサーバーへと送られます。 このスキームはと呼ばれます サーフプロトコル。 Serf プロトコルは、Consul と同様に HashiCorp によって開発されています。

Consul に関する重要な事実

Consul には、その仕組みを説明したドキュメントがあります。 知っておく価値のある事実だけを厳選して紹介します。

領事サーバーは投票者の中からマスターを選択します。 Consul は各データセンターのサーバーのリストからマスターを選択し、サーバーの数に関係なく、すべてのリクエストはそのマスターにのみ送信されます。 マスター凍結は再選には繋がらない。 マスターが選択されていない場合、リクエストは誰によっても処理されません。

水平方向のスケーリングが必要でしたか? 申し訳ありませんが、いいえ。

別のデータセンターへのリクエストは、どのサーバーに送信されたかに関係なく、マスターからマスターへと送信されます。 選択されたマスターは、転送リクエストの負荷を除き、負荷の 100% を受け取ります。 データ センター内のすべてのサーバーにはデータの最新のコピーがありますが、応答するのは XNUMX 台だけです。

スケーリングする唯一の方法は、クライアントで古いモードを有効にすることです。

stale モードでは、クォーラムなしで応答できます。 これは、データの一貫性を放棄しますが、通常よりも少し速く読み取り、どのサーバーも応答するモードです。 当然ながらマスター経由のみでの録音となります。

Consul はデータセンター間でデータをコピーしません。 フェデレーションが構築されると、各サーバーには独自のデータのみが含まれます。 他の人のために、彼はいつも他の人に頼ります。

操作のアトミック性はトランザクション外では保証されません。 物事を変えることができるのはあなただけではないことを忘れないでください。 別の方法が必要な場合は、ロックを使用してトランザクションを実行します。

ブロック操作はロックを保証しません。 リクエストは直接ではなくマスターからマスターに送信されるため、たとえば別のデータセンターでブロックするときにブロックが機能するという保証はありません。

ACL もアクセスを保証しません (多くの場合)。 ACL は XNUMX つのフェデレーション データ センター (ACL データ センター (プライマリ DC)) に保存されているため、機能しない可能性があります。 DC が応答しない場合、ACL は機能しません。

XNUMX つのマスターがフリーズすると、フェデレーション全体がフリーズします。 たとえば、フェデレーション内に 10 のデータ センターがあり、そのうちの XNUMX つのネットワークに不良があり、XNUMX つのマスターに障害が発生したとします。 彼と通信する人は皆、要求があり、それに対する答えがなく、スレッドがフリーズするという循環に陥ることになります。 これがいつ起こるかを知る方法はなく、ほんのXNUMX、XNUMX時間以内に連邦全体が崩壊するでしょう。 それについては何もできません。

ステータス、定足数、選出は別のスレッドで処理されます。 再選は行われず、ステータスには何も表示されません。 あなたは生きている執政官がいると思って尋ねますが、何も起こりません - 答えはありません。 同時に、ステータスはすべてが正常であることを示します。

私たちはこの問題に遭遇し、それを回避するためにデータセンターの特定の部分を再構築する必要がありました。

Consul Enterprise のビジネス バージョンには、上記のいくつかの欠点がありません。。 投票者の選択、配布、スケーリングなど、多くの便利な機能があります。 「しかし」が XNUMX つだけあります。分散システムのライセンス システムは非常に高価です。

ライフハッキング： rm -rf /var/lib/consul - エージェントのすべての病気の治療法。 問題が解決しない場合は、データを削除し、コピーからデータをダウンロードしてください。 おそらく領事が機能するだろう。

BEFW

次に、Consul に追加した内容について説明します。

BEFW の頭字語です BACKEndF怒気W全て。 最初のテスト コミットをリポジトリに入れるために、リポジトリを作成するときに何らかの方法で製品に名前を付ける必要がありました。 この名前は残っています。

ルールテンプレート

ルールは iptables 構文で記述されます。

• -N BEFW
• -P 入力ドロップ
• -A INPUT -m 状態—状態 RELATED,ESTABLISHED -j ACCEPT
• -A 入力 -i lo -j ACCEPT
• -A 入力 -j BEFW

例外を除き、すべてが BEFW チェーンに入ります。 ESTABLISHED, RELATED そしてローカルホスト。 テンプレートは何でも構いませんが、これは単なる例です。

BEFW はどのように役立ちますか?

サービス

サービスには常にポート、つまりサービスが実行されるノードがあります。 私たちのノードからローカルでエージェントに問い合わせて、何らかのサービスがあることを確認できます。 タグも付けられます。

実行中で Consul に登録されているサービスはすべて iptables ルールになります。 SSH を使用しています - ポート 22 を開きます。Bash スクリプトは単純です。curl と iptables だけで、他には何も必要ありません。

クライアント

全員ではなく選択的にアクセスを開くにはどうすればよいでしょうか? サービス名ごとに IP リストを KV ストレージに追加します。

たとえば、22 番目のネットワーク上の全員が SSH_TCP_XNUMX サービスにアクセスできるようにしたいとします。 小さな TTL フィールドを XNUMX つ追加しますか? そして今では、例えばXNUMX日の一時的な許可が得られます。

アクセス

当社はサービスとクライアントを接続します。当社にはサービスがあり、KV ストレージはそれぞれに対応しています。 現在は全員にではなく、選択的にアクセスを許可しています。

グループ

毎回アクセスするために何千もの IP を書いていたら疲れてしまいます。 グループ化、つまり KV の別のサブセットを考えてみましょう。 これをエイリアス（またはグループ）と呼び、同じ原則に従ってそこにグループを保存しましょう。

接続しましょう: これで、特に P2P に対してではなく、グループ全体または複数のグループに対して SSH を開くことができるようになりました。 同様に、TTL があり、グループに追加したり、グループから一時的に削除したりできます。

Интеграция

私たちの問題は人的要素と自動化です。 これまでのところ、この方法で解決しています。

私たちは Puppet と連携し、システム (アプリケーション コード) に関連するすべてのものを Puppet に転送します。 Puppetdb (通常の PostgreSQL) には、そこで実行されているサービスのリストが保存されており、リソース タイプごとに見つけることができます。 そこで誰がどこに応募しているのかを知ることができます。 このためのプル リクエストとマージ リクエスト システムもあります。

私たちは、データ転送を支援するシンプルなソリューションである befw-sync を作成しました。 まず、同期 Cookie は puppetdb によってアクセスされます。 そこで HTTP API が構成されます。どのようなサービスがあるか、何を行う必要があるかをリクエストします。 そして彼らは領事に要請を出します。

統合はありますか? はい: 彼らはルールを作成し、プル リクエストの受け入れを許可しました。 特定のポートが必要ですか、それともホストをグループに追加しますか? プル リクエスト、レビュー - 「他の 200 個の ACL を見つけて、それについて何かをしてみる」という作業はもう必要ありません。

最適化

空のルール チェーンを使用して localhost に ping を実行すると、0,075 ミリ秒かかります。

このチェーンに 10 の iptables アドレスを追加しましょう。 その結果、ping は 000 倍に増加します。iptables は完全に線形であり、各アドレスの処理には時間がかかります。

数千の ACL を移行するファイアウォールには多くのルールがあり、これにより遅延が発生します。 これはゲーム プロトコルにとって好ましくありません。

しかし、 ipset 内の 10 のアドレス pingも下がります。

重要なのは、ルールの数に関係なく、ipset の「O」（アルゴリズムの複雑さ）は常に 1 に等しいということです。 確かに、制限はあります - 65535 個を超えるルールは存在できませんが、今のところはこれで対応しています: ルールを組み合わせたり、拡張したり、XNUMX つの ipset を XNUMX つに作成したりできます。

ストレージ

反復プロセスの論理的な継続は、サービスのクライアントに関する情報を ipset に保存することです。

ここで、同じ SSH を使用し、一度に 100 個の IP を書き込むのではなく、通信する必要がある IPset の名前と次のルールを設定します。 DROP。 これは「ここにいない人は DROP」という XNUMX つのルールに変換できますが、より明確です。

これでルールとセットができました。 主なタスクは、ルールを記述する前にセットを作成することです。そうしないと、iptables がルールを書き込めないからです。

一般スキーム

私が言ったことを図に表すと次のようになります。

私たちは Puppet にコミットし、すべてがホストに送信され、サービスはここに、ipset はそこに送信され、そこに登録されていない人は許可されません。

許可と拒否

すぐに世界を救ったり、誰かをすぐに無効にしたりするために、すべてのチェーンの最初に XNUMX つの ipset を作成しました。 rules_allow и rules_deny。 使い方？

たとえば、誰かがボットを使用して Web に負荷を与えているとします。 以前は、ログから彼の IP を見つけてネットワーク エンジニアに伝え、トラフィックの発信元を特定して彼を禁止する必要がありました。 今は違って見えます。

それを領事に送信し、2,5 秒待って完了です。 Consul は P2P を通じて迅速に配布できるため、世界中のどこでも機能します。

一度、ファイアウォールのミスでなぜかWOTを完全に停止してしまいました。 rules_allow - これはそのような場合に備えた当社の保険です。 ファイアウォールのどこかで間違いを犯した場合、どこかで何かがブロックされている場合、いつでも条件付きメッセージを送信できます。 0.0/0すべてをすぐに拾うこと。 後ですべてを手作業で修正します。

その他のセット

スペースに他のセットを追加できます $IPSETS$.

何のために？ たとえば、クラスターの一部のシャットダウンをエミュレートするために、ipset が必要になる場合があります。 誰でも任意のセットを持ち込むことができ、名前を付ければ領事から受け取ります。 同時に、セットは iptables ルールに参加することも、チームとして機能することもできます。 NOOP: 一貫性はデーモンによって維持されます。

メンバー

以前は、ユーザーはネットワークに接続し、ドメイン経由でパラメータを受信して​​いました。 新世代ファイアウォールが登場するまで、シスコはユーザがどこにいるのか、そして IP がどこにあるのかを理解する方法を知りませんでした。 したがって、アクセスはマシンのホスト名を介してのみ許可されました。

私たちが何をしたのですか？ 私たちはアドレスを受け取った瞬間に行き詰まってしまいました。 通常、これは dot1x、Wi-Fi、または VPN であり、すべてが RADIUS を経由します。 ユーザーごとに、ユーザー名ごとにグループを作成し、その中に dhcp.lease と同じ TTL を持つ IP を配置します。有効期限が切れるとすぐに、ルールは消えます。

これで、他のグループと同様に、ユーザー名によってサービスへのアクセスを開くことができます。 ホスト名を変更する際の煩わしさから解放され、Cisco が不要になったネットワーク エンジニアの負担も軽減しました。 現在では、エンジニア自身がサーバーにアクセスを登録しています。

断熱

同時に断熱材の解体も始めました。 サービス マネージャーが棚卸しを行い、私たちはすべてのネットワークを分析しました。 それらを同じグループに分割し、必要なサーバー上で、たとえば拒否するグループを追加しましょう。 現在、同じステージング分離はプロダクションの rules_deny に含まれますが、プロダクション自体には含まれません。

このスキームは迅速かつ簡単に機能します。サーバーからすべての ACL を削除し、ハードウェアをアンロードして、分離された VLAN の数を減らします。

完全性管理

以前は、誰かがファイアウォール ルールを手動で変更したときに報告する特別なトリガーがありました。 ファイアウォール ルールをチェックするための巨大なリンターを作成していましたが、それは困難でした。 整合性は BEFW によって管理されるようになりました。 彼は自分が作ったルールが変更されないように熱心に努めています。 誰かがファイアウォール ルールを変更すると、すべてが元に戻ります。 「自宅で仕事ができるように、すぐにプロキシを設定しました」――そのような選択肢はもうありません。

BEFW は、BEFW チェーン内のサービスのルールである befw.conf 内のサービスとリストから ipset を制御します。 ただし、他のチェーン、ルール、および他の ipset は監視しません。

衝突保護

BEFW は常に、最後に確認された正常な状態を state.bin バイナリ構造に直接保存します。 何か問題が発生した場合は、常にこの state.bin にロールバックされます。

これは、Consul がデータを送信しなかったり、誰かが間違いを犯して適用できないルールを使用したりした場合の、不安定な Consul の動作に対する保険です。 ファイアウォールがない状態にならないように、いずれかの段階でエラーが発生した場合、BEFW は最新の状態にロールバックします。

これにより、危機的な状況において、ファイアウォールが機能することが保証されます。 管理者が来て修正してくれることを期待して、灰色のネットワークをすべて開きます。 いつかこれを設定に入れるつもりですが、今は 10 つの灰色のネットワーク (8/172、12/192.168、16/XNUMX) だけがあります。 私たちの領事内では、これは私たちがさらに発展するのに役立つ重要な機能です。

デモ: レポート中に、Ivan は BEFW のデモ モードを実演します。 デモンストレーションが見やすくなります ビデオ。 デモソースコードが利用可能 GitHubで.

落とし穴

私たちが遭遇したバグについてお話します。

ipset 追加セット 0.0.0.0/0。 ipset に 0.0.0.0/0 を追加するとどうなりますか? すべての IP が追加されますか? インターネットアクセスは利用可能になりますか?

いいえ、バグが発生して 2016 時間のダウンタイムが発生します。 さらに、このバグは 1297092 年以降機能していません。このバグは RedHat Bugzilla の番号 #XNUMX にあり、開発者のレポートから偶然発見しました。

現在、BEFW では次のことが厳格なルールとなっています。 0.0.0.0/0 は XNUMX つのアドレスになります。 0.0.0.0/1 и 128.0.0.0/1.

ipset 復元セット < ファイル。 ipset に指示すると何をしますか restore? iptables と同じように機能すると思いますか? データは復旧するのでしょうか？

そのようなことはありません。マージが行われ、古いアドレスはどこにも行かず、アクセスはブロックされません。

分離のテスト中にバグが見つかりました。 現在、かなり複雑なシステムが存在します - 代わりに restore ハンドヘルド create tempそれから restore flush temp и restore temp。 スワップの終了時: 原子性のため、最初に実行すると flush そしてこの瞬間にパケットが到着すると、それは破棄され、何か問題が発生します。 つまり、そこにはちょっとした黒魔術があります。

consul kv get -datacenter=other. 先ほども述べたように、何らかのデータを要求していると考えられますが、データを取得するかエラーが発生するかのどちらかです。 Consul を介してローカルでこれを行うこともできますが、この場合は両方ともフリーズします。

ローカル Consul クライアントは、HTTP API のラッパーです。 しかし、それはただハングし、Ctrl + C、Ctrl + Z、またはその他のものに応答しません。 kill -9 次のコンソールで。 大規模なクラスターを構築しているときにこの問題が発生しました。 しかし、まだ解決策はなく、Consul でこのエラーを修正する準備をしています。

領事リーダーは応答していません。 データセンターのマスターが応答しないため、「もしかしたら、再選択アルゴリズムが機能するようになるのではないか？」と考えます。

いいえ、機能しません。監視しても何も表示されません。領事は、コミットメント指標があり、リーダーが見つかり、すべてが順調であると言うでしょう。

これにどう対処すればよいでしょうか? service consul restart cronで50時間ごとに。 サーバーが 16 台ある場合は、大きな問題はありません。 000 個もあれば、それがどのように機能するかがわかります。

まとめ

その結果、以下のようなメリットが得られました。

• すべての Linux マシンを 100% カバーします。
• スピード。
• オートメーション。
• 私たちはハードウェアとネットワークのエンジニアを奴隷状態から解放しました。
• Kubernetes、Ansible、Python など、ほぼ無限の統合の可能性が現れています。

コンズ: 領事、私たちはこれから一緒に暮らさなければなりません、そして間違いの非常に高い代償。 例として、ある時、午後 6 時 (ロシアのゴールデンタイム) にネットワークのリストで何かを編集していました。 当時、BEFW ではちょうど断熱材を構築していたところでした。 どこかで間違えて、間違ったマスクを指定したようですが、すべてがXNUMX秒で終わりました。 モニターが点灯し、当番のサポート担当者が駆けつけます。「すべて揃っています！」 部門長は、なぜこのようなことが起こったのかを企業に説明すると、顔面蒼白になった。

エラーの代償は非常に大きいため、当社では独自の複雑な防止手順を考案しました。 これを大規模な運用サイトに実装する場合、Consul のマスター トークンを全員に与える必要はありません。 これは悪い結果に終わります。

コスト。 一人で400時間コードを書きました。 私のチームは 4 人ですが、月に 10 時間を全員のサポートに費やしています。 新世代ファイアウォールの価格と比較すると、それは無料です。

計画。 長期計画は、領事に代わる、または補完する代替交通機関を見つけることです。 おそらくそれはカフカかそれに似たものになるでしょう。 しかし、今後数年間、私たちはConsulで生きていくことになるでしょう。

当面の計画: Fail2ban、モニタリング、nftables との統合、場合によっては他のディストリビューション、メトリクス、高度なモニタリング、最適化との統合。 現在、いくつかのクラスターがあり、その要望があるため、Kubernetes のサポートも計画のどこかに含まれています。

計画の詳細:

• トラフィックの異常を検索します。
• ネットワークマップ管理。
• Kubernetes のサポート。
• すべてのシステムのパッケージを組み立てる。
• ウェブUI。

私たちは構成の拡張、メトリクスの増加、最適化に常に取り組んでいます。

プロジェクトに参加してください。 このプロジェクトは素晴らしいものになりましたが、残念なことに、まだ一人のプロジェクトです。 に来てください GitHubの そして何かをしてみてください。コミットし、テストし、何かを提案し、評価を与えます。

その間に私たちは準備を進めています セイントハイロード++6 月 7 日と XNUMX 日にサンクトペテルブルクで開催され、高負荷システムの開発者を招待します。 レポートを申請する。 経験豊富なスピーカーはすでに何をすべきかを知っていますが、スピーカーの初心者には少なくとも次のことをお勧めします。 試すために。 講演者としてカンファレンスに参加すると、多くのメリットがあります。 たとえば最後にどれかを読むことができます この記事.

出所： habr.com