最適なネットワーク構成で MinIO を最大限に活用する — その方法は次のとおりです

MinIO は、複数の物理マシンまたは仮想マシンのコンピューティング リソースとストレージ リソースを効率的に利用できる分散方法で展開できます。これは、Amazon Web Services、Google Cloud Platform、Microsoft の Azure プラットフォームなど、プライベート クラウド環境またはパブリック クラウド環境で実行される MinIO です。 MinIO は、いくつかのタイプのトポロジに展開できます。運用環境では、マルチノード マルチドライブ(MNMD) 展開をお勧めします。 MinIO は、単一サイト展開に BC/DR グレードのフェイルオーバーとリカバリのサポートを提供するサイト レプリケーションを推奨します。これは、ユースケースに合わせて設計および最適化できます。

以前のブログ投稿で、 MinIO 展開用のハードウェアを選択する際に使用するベスト プラクティスのいくつかについてすでに説明しました。最適な領域、適切なドライブ、CPU とメモリの構成、さらには推奨されるネットワーク構成の選択に至るまで、ハードウェアのさまざまな側面について触れました。システム設計のさまざまなベスト プラクティスについて触れましたが、いつでもさらに深く掘り下げることができます。今日は、ドライブとネットワークから最高のパフォーマンスを引き出すための MinIO の設計に関する細かい点をいくつか掘り下げていきます。

このブログ投稿では、MinIO をさまざまなレプリケーション戦略とネットワーク トポロジに合わせて構成できるネットワーク構成について詳しく説明します。これらを使用して、複数の MinIO 展開間でデータが効率的に保存され、アクセスされるようにすることができます。ボンディング/デュアル NIC のセットアップ (追加のオーバーヘッドが追加される) などの複雑な構成を行う必要はありません。

シンプルなネットワーキング戦略

MinIO は、クラウドネイティブ サービス用の S3 互換ストレージ バックエンドです。一般に、ネットワーク トラフィックは、アプリとクラスターの間、またはクラスター内のノード間のいずれかであると考えられます。ノード間のトラフィックのため、ノード間のネットワークが可能な限り高速であることが最も重要です。各プールは、独自の消去セットを持つ独立したノード グループで構成されます。 MinIO は、各プールをクエリして、読み取りおよび書き込み操作を指示する正しい消去セットを決定する必要があります。これにより、プールが追加されるたびに、呼び出しごとに最小限のノード間トラフィックが追加されます。正しい消去セットを含むプールは、アプリケーションに対して完全に透過的な状態で操作に応答します。

企業が 1 GbE または 10 GbE NIC で対応できた時代は終わりました。最新のエンタープライズ ワークロードでは、100 GbE NIC を理想的に利用します。 TCP プロトコルの物理的な制限とオーバーヘッドを考慮すると、これらの NIC は利用可能な帯域幅の 80 ～ 90% を提供することが期待されます。通常、100 Gbps NIC の場合は約 10 GB/秒、十分にプロビジョニングされたネットワークでは最大 12 GB/秒です。 MinIO は、すべてのインターフェイスでリッスンするため、すべての帯域幅を活用するために、追加のネットワーク構成を追加の設定を必要としません。 MinIO は、すぐに使用できるように、複数のネットワーク インターフェイス (NIC) でのリッスンをサポートします。

MinIO ネットワークに他の特別な構成は必要ありませんが、必要に応じて、前に説明したネットワークの基本のいくつかを使用して、特定のインターフェイスを介して MinIO トラフィックをルーティングできます。

この例では、Linux オペレーティング システムを使用して説明しますが、どの OS を使用してもネットワークの基本は同じです。実装はネットワーク構成に応じて若干異なる場合がありますが、これでアイデアが得られるはずです。

まずルート テーブルをリストすることから始めます

$ ip route 10.56.98.0/24 dev eth0 proto kernel scope link src 10.56.98.18

MinIO サーバーが 10.56.98.16/28 CIDR 範囲内になるように構成した場合、MinIO ノードの IP アドレスの 1 つが 10.56.98.21 であるとします。これは、/28 が 10.56 のルート テーブル エントリと一致するため、eth0 インターフェイスを介してルーティングされます。 .98.0/24。

ただし、MinIO トラフィックを eth0 ではなく eth1 経由でルーティングしたい場合は、MinIO CIDR に特定のルートを追加して、そのサブネットに一致するトラフィックがその特定のネットワーク インターフェイス経由でルーティングされるようにする必要があります。

 $ ip route add 10.56.98.16/28 dev eth1

ルートが追加されたら、ルーティング テーブルを再度一覧表示して、どのように見えるかを確認してみましょう。

 $ ip route 10.56.98.0/24 dev eth0 proto kernel scope link src 10.56.98.33.18 10.56.98.16/28 dev eth1 scope link

/28 CIDR のルートが表示されます。 MinIO ノード 10.56.98.21 に ping を実行すると、eth1 インターフェイス経由でルーティングされるようになります。これは、/24 が /28 と重複する 2 つのルートがある場合、一般に、最も長いプレフィックスを持つルートが優先され (この場合は /28)、トラフィックをルーティングするときに他の短いプレフィックス ルートよりも優先されるためです。これは、最長一致プレフィックス ルールと呼ばれます。

10.56.98.21 に ping を実行し、以下のように tcpdump をチェックすると、10.56.98.16/28 からのトラフィックが適切にルーティングされていることを確認できます。送信元 10.56.98.18 からのトラフィックが eth1 経由で 10.56.98.21 にルーティングされていることがわかります。

 $ tcpdump -n -i eth1 icmp … 15:55:44.410450 IP 10.56.98.18 > 10.56.98.21: ICMP echo request, id 8416, seq 123, length 64 15:55:44.410471 IP 10.56.98.21 > 10.56.98.18: ICMP echo reply, id 8416, seq 123, length 64 15:55:45.434489 IP 10.56.98.18 > 10.56.98.21: ICMP echo request, id 8416, seq 124, length 64 15:55:45.434518 IP 10.56.98.21 > 10.56.98.18: ICMP echo reply, id 8416, seq 124, length 64 15:55:46.458490 IP 10.56.98.18 > 10.56.98.21: ICMP echo request, id 8416, seq 125, length 64 15:55:46.458520 IP 10.56.98.21 > 10.56.98.18: ICMP echo reply, id 8416, seq 125, length 64

MinIO を使用するとわかるように、トラフィック分離を実現するために追加の特別なポートやサービスは必要ありません。 MinIO はシンプルさを念頭に置いて設計されており、この場合、ゲートウェイ サービスのような複雑なものを構築するのではなく、構築するか購入するかを常に考えています。MinIO は、OS 層ですでに利用可能なネットワークの基本を活用して、最小限のオーバーヘッドで同じ結果を達成します。可能。

このアイデアをさらに一歩進めることができます。最近のサーバーには少なくとも 2 つのインターフェイスがあり、さらに追加するオプションもあります。そのため、アプリケーション トラフィックを MinIO と同じインターフェイスを通過させるのではなく、アプリケーションを別の CIDR ブロックでも実行させることができます (アプリケーションのサイズに適したブロックを選択します)。この分離により、レプリケーションとリバランスのための MinIO トラフィックがアプリケーションのパフォーマンスに影響を及ぼさないことが保証され、またその逆も同様になります。また、トラフィックを監視および追跡して、パフォーマンスに影響を与えることなく、MinIO が操作を実行するために必要な容量と帯域幅を常に確保できるようにします。

しかし、異なるサイトや地域にまたがって MinIO がある場合はどうなるでしょうか?パフォーマンスのボトルネックを確実になくすために効果的に構成するにはどうすればよいでしょうか? MinIO が最も厳しいユースケース向けに提供するレプリケーション構成には、いくつかの異なるタイプがあります。

最も多用なレプリケーション戦略の 1 つは、サイト間のレプリケーションです。これにより、単一クラスターで MinIO を開始し、必要に応じて N 個まで拡張することができます。 3 つの異なるサイトで実行される ETL/ELT アプリケーションがあると仮定します。一般に、データはいずれかのリージョンでのみ利用可能であり、他のリージョンはプロセスを実行するためにリージョン間で膨大な量のデータをプルする必要があります。言うまでもなく、これは非常に非効率であるだけでなく、ネットワーク インフラストラクチャに多大な負荷をかけ、WAN を共有する他のアプリケーションにボトルネックを引き起こす可能性があります。

サイト間のレプリケーション構成では、最初のサイトの MinIO クラスターにのみデータを書き込みます。レプリケーション プロセスにより、データが他のサイトに自動的にコピーされます。 ETL/ELT アプリケーションに追加の変更を加える必要はありません。各サイトのジョブを、Nginx などのリバース プロキシによってバックアップされたそれぞれの MinIO クラスターにポイントするだけで、以下に示すように、読み取りはリージョン全体の WAN 経由よりもはるかに高速になります。

しかし、そこで疑問が生じます。トラフィックをさらに微調整することは可能でしょうか?データ ファイルをサイト 1 に追加すると、時刻に関係なく、すぐに他のサイトにデータ ファイルがレプリケートされるとします。おそらく他の ETL/ELT ジョブが実行されていると同時に、次のバッチが実行される予定の翌日まで使用されない可能性のあるデータをレプリケートするためにネットワーク リソースが使用されているピーク時である可能性があります。その場合何ができるでしょうか？ここで、MinIO のバッチ レプリケーションが役に立ちます。バッチ レプリケーションを使用すると、特定の時間にレプリケートするデータの種類を選択でき、完全に構成可能です。この場合、トラフィックが最も少ない時間外にバッチ レプリケーション ジョブを実行するように設定できます。アプリケーションのアクセス時間は、日、週、さらには月によっても変化する可能性があるため、ここでMinIO ネットワーク トラフィックの監視が役立ち、バッチ ジョブを正確な時間に実行するように構成できます。ピア サイトを異なるラック、データ センター、または地理的地域に展開して、グローバルに分散された MinIO オブジェクト ストアでの BC/DR や地理ローカルな読み取り/書き込みパフォーマンスなどの機能をサポートできます。

最終的な考え

要約すると、MinIO のネットワーク アーキテクチャは、最もシンプルで簡単なものの 1 つです。 MinIO は、車輪を再発明するのではなく、ネットワークの基本を使用して、デバッグがほぼ不可能な複雑なネットワークとゲートウェイのセットアップを備えた他のデータ ストアの一部と同等の機能を実現します。同じ問題を何度デバッグしても、アーキテクチャの難読化の性質により、初めてその問題に遭遇したように感じるでしょう。むしろ、MinIO は、アプリケーション開発者がデータ レプリケーションを維持する負担を軽減し、データの保存と処理に重点を置く高レベルの抽象化に重点を置いています。

いつものように、MinIO ネットワークの構成やセットアップ方法についてご質問がある場合は、必ずSlackでお問い合わせいただくか、できればSUBNETサブスクリプションにサインアップしてください。