現在、Brocade Silkworm 200e スイッチを 1 台稼働しています。企業の Exchange サーバーと 3 台の ESX 3.5 ホストは、このスイッチを介して clariion cx3 アレイに接続されています。ポート 0、1 は SPA0 と 1、ポート 4、5 は SPB0 と 1 です。
私の計画は、200 の隣に Brocade Silkworm 300 スイッチを追加し (すでにラックに取り付けられ、電源がオンになっています)、データセンターに移動して、200 から SPA1 と SPB0 を引き出して、300 スイッチのポートに挿入することです。
実稼働中の FC パスを取り外すことには、少し不安を感じています。SPA0 と SPB1 にフェールオーバーするだけで、A1 と B0 が失われることはないだろうという論理的な想定があります。ただし、可能であれば、リスクをさらに最小限に抑えるために何ができるかを 100% しっかりと理解しておきたいと思います。
LUN が現在 SPA によって所有されている場合、ラウンドロビンで SPA0 と SPA1 の両方が自動的に使用されますか、それともスイッチは、障害が発生しない限り特定のパスを排他的に優先しますか? 例: Exchange Server は SPA0 または SPA1 を使用していますか、それとも 0 と 1 の両方をアクティブ/アクティブで使用していますか?
SP アクティブ/アクティブへの両方のパスを使用している場合、もう一方のパスはすでに問題なく使用されていることが保証されているため、一方のパスを中断してもリスクは少ないと推測しています。これまで使用したことのない代替パスに強制的にフェイルオーバーして、ケーブルが不安定だったことが判明するのが怖いです。
フェイルオーバーがうまくいかなかった場合にデータが破損しないようにするために、会社に多大な混乱を招き、すべての仮想マシンと Exchange サーバーをシャットダウンするべきでしょうか? それとも、これはやりすぎでしょうか? いずれにしても、完全バックアップ サイクルの直後にこの操作を実行するつもりです。
フェイルオーバーが発生したら、どのように監視しますか? Brocade 200e は詳細にログを記録しますか? プラグを抜いたときにすべてがまだ動作していることを最大限に保証したいです。 esx ホストのストレージを再スキャンし、exchange の powerpath モニターを監視できます。 もっと良い方法はありますか?
初めてこのようなことをするとき、すべての卵がこの一つのカゴに入っているときに、自信過剰の仮定を立てるよりも、状況にふさわしい以上に慎重になるほうがいいと思います。
答え1
あなたの計画が 2 番目の独立したファブリックを設定することであることを願っています。それは一般的に良いアイデアだと考えられています。
サーバーに複数の HBA があるかどうかはわかりません。冗長ファブリックを適切に再構成できるようになるので、そうであることを願っていますが、そうでなくても、当面の計画に大きな影響を与えることはありません。
Powerpath は Exchange サーバーのフェイルオーバーを処理し、A0 が切断されたときに A1 経由のパスを選択し、両方の SPA ポートに障害が発生していない限り、B0 または B1 経由のパスを選択しません。いずれかのパスが動作していない場合は通知されます。または、少なくとも、期待するパスは表示されません。Powerpath のバージョン (SE バージョンまたは完全ライセンス バージョン) によっては、ロード バランシング マルチパス ポリシーがアクティブになっている場合がありますが、いずれにしても、パス フェイルオーバーは、記述したセットアップに対して信頼できるはずです。アクティブなパスを切断した場合、Powerpath は、障害が発生した IO を代替パス (正常である場合) 経由で再ルーティングします。Powerpath GUI 内でパスの状態を確認するか、コマンド ラインから を使用して、powermt check障害が発生したパスまたは新しいパスを確認するか、およびpowermt restoreを使用して、デッド パスまたは新しいパスを確認して削除または追加することができます。ロード バランシングのパス ポリシーがすでに設定されていて、SPA0 と SPA1 (たとえば) の両方を介して正常なパスが表示されている場合は、すべてが正常であるという確信がかなり高くなります。
ESX サーバーでは、VI Client -> 構成 -> ストレージ タブから各 LUN で使用可能なパスを確認できます。プロパティでは、使用可能なパス (アクティブおよびスタンバイ) が表示され、パスの管理ダイアログでポリシー (Fixed\MRU\Round Robin) を変更できます。何も変更する必要はありませんが、ここでも、使用するフェイルオーバー パスが使用可能であることを確認する必要があります。ここでも、ESX のマルチパス スタックがフェイルオーバーを処理します。アクティブ パスで IO が実行中の場合、パスに障害が発生したことを検出すると、別のパスで IO が再送信されます。ESX 3.5 はラウンド ロビン マルチパスを試験的にのみサポートしているため、この場合は変更しないでください。プロアクティブにしたい場合は、一時的に固定パス ポリシーを設定し、LUN を必要なパスに強制的に移動できますが、CX3 の標準設定は MRU のままにしておくことになっているため、これで問題ありません。
どちらの場合も、フェイルオーバーが発生するまでに多少の遅延が発生し、IO が一時的に停止する可能性がありますが、冗長パスが実際に正常であれば、何も失敗することはありません。