現在、GFS + iSCSIを使用して新しい環境のハードウェアおよびトポロジソリューションを評価しており、いくつかの提案/ヒントが必要です。過去に同様のソリューションを展開し、GFSノードにアクセスするすべてのホストがGFSノード自体でした。新しいトポロジは、GFSノードをそれらにアクセスするクライアントから分離することです。
基本的な図は次のようになります。
GFS_client <-> gigE <-> GFSノード<-> gigE <-> iSCSI SANデバイス
「最適な」設定はないと思います。 GFSの前にiSCSIイニシエーターを起動することを確認してください。冗長性/パフォーマンスの指標としてボンディングをすでに指定しています。ターゲットへのマルチパス接続の設定も検討する必要があります。NICが4つある場合は、冗長性を高めるために、2つのボンディングされたインターフェイス上に2つのパスを作成します。その機能をサポートする専用のiSCSIスイッチがある場合は、ジャンボフレームの使用も検討する必要があります。
サブシステムとしてのGFSは、システムにそれほど重くはありません。カーネルにはロックが保持されており、ノード間でいくつかのメンバーシップ情報/ハートビートが実行されています。これでほぼ完了です。一方、GFSノードとクライアントがアクセスするサーバーの両方にすることを計画しているので、おそらくNIC /スイッチとサーバー用のRAM)に投資する必要があります。
ジャンボフレーム。可能であれば、両側(iSCSIとクライアント)での803.2adリンクアグリゲーション。 tcpスタックの最適化(/ proc/sys/net/ipv4/tcp_rmem | wmem)
これはスキップします。10geのコストはわかりません。
私が答えを提案できるこの質問の唯一の部分は#4です。
SANの10GbEを評価および検討し、チーム化/負荷分散された1Gbアダプターを使用する方が、より安価で、より効果的で、より安全であると判断しました。 10GigEで同じレベルの冗長性を実現することは天文学的なことであり、クライアントのパフォーマンスをわずかに向上させました(結局、各クライアントに10GbEカードを配置することはありません)。
ネットワークの冗長性について考えたことはありますか? GFSクラスターは、ハートビートの欠落に対して非常に脆弱です。個別のスイッチに接続されたすべてのクラスターおよびiSCSIリンクにインターフェイスボンディングを使用します。
新しいSANのソリューションを評価しており、Equalogic製品はiscsiに非常に適しています。各バンドルは15台のディスクと2台のコントローラー(それぞれA/P 4GB)です。 15ディスクあたり2つのコントローラーを追加すると、ストレージ容量を追加しながらパフォーマンスが直線的に向上します。
今のところ10Geにはなりませんが、各コントローラーには4つのリンクがあります。真のシンプロビジョニングを提供します
LapTop006の投稿については(まだ)コメントできませんが、彼は絶対に注目しています!
ピンチは、IP-SAN内のすべてのネットワーク機器が同じ量のMTU(最大伝送ユニット)をサポートする必要があるということです。仕様によるジャンボフレームの最大MTUは9000バイトですが、9100以上を使用している人を見かけました。
#3&4に追加するだけ
ジャンボは、特にパケットの99.99%が大きくなる「ストレージ」ネットワークの場合、パフォーマンスにhuge有益な違いをもたらす可能性があります。ネット上のすべてのホストがそれらをサポートしていることを確認するために、最初に監査を行うようにしてください。
次に、これらすべての追加のGigEインターフェイスが速度を向上させていることを確認する価値があります。ほとんどのスイッチ(デフォルト)は実際にはMACまたはIPベースのハッシュを使用しているため、単一のホストペア間で実際に1Gbを超えることはありません。
10Gbeを投入するときは、弾丸を噛んで同じリンクレートではるかに高速なFCを使用するか、来年の初めにコンバージドイーサネットが最終的に「アーリーアダプター」以下で出荷されるまで待つ必要があります。価格設定。