2 ノードの Hyper-V 2012 クラスターを初めてセットアップしたとき、フェイルオーバーはほぼ瞬時に行われました。8 GB の RAM が割り当てられた Sql Server 2012 (Win2012 上) VM がありました。その VM が稼働しているノードをバウンスすると、Sql 接続が切断されることなく他のノードにジャンプしました。
次に、8GB の 2 番目の VM (最初の VM のクローン) をクラスターに追加しました。これで、フェイルオーバーに数秒かかり、SQL 接続がリセットされます。これは、移動する必要がある RAM の量によるものなのでしょうか? ネットワークの影響を受けますか? クォーラム ディスクの速度によるものなのでしょうか?
私の場合、両方のノードが同じ DAS に接続されており、VM ファイルは CSV 上に存在します。移動する必要がないため、ディスクは要因ではないと思います。すべて RAM であるはずですよね? つまり、RAM が増えると、フェイルオーバーのパフォーマンスは低下するということですか?
答え1
振り返ってみると、私は知っているべきだったと思います。答えは 2 つの部分に分かれています。なぜなら、私の考えでは、計画されたフェイルオーバーと「実際の」/計画されていないフェイルオーバーがあり、計画されたフェイルオーバーはカウントされないからです。
計画的なフェイルオーバー
計画的フェイルオーバーは、実際にはクラスタリング システムがノードを空にして再起動するだけです。したがって、RDP 経由でノードを直接再起動するか、クラスタリング アプリの GUI で「クラスタ サービスを停止」すると、最初に VM のライブ マイグレーションが行われます。VM のライブ マイグレーションだけを行うため、かかる時間は転送する必要がある内容とネットワーク接続によって異なります。1Gb NIC を使用している場合は、しばらく時間がかかります (約 118MB/秒)。VM の RAM が多いほど、より高速なNICによって、より良いサービスが受けられる。
本当のフェイルオーバー
計画外の/「実際の」フェイルオーバーは、マシンのプラグを抜いたときに発生します。その場合、クラスタ システムは自動的に別のノードで VM を起動します。外部に対する動作は、VM を再起動した場合と同じです。VM にとっては、「電源をオフにして」再度起動した場合と同じです。したがって、「実際の」フェイルオーバーは、常に VM の起動にかかる時間に関するものになります。
正接
これは私にとっては概念的にがっかりです。なぜなら、ネット上のクラスタリングに関する話はすべて、(「ハード」) ノード障害はクラスタリング システムによって隠蔽され、サービスがダウンしなかったかのように見えるように思われるからです。これは、私が読んだ記憶のあるすべての Web ページがソフトウェアでクラスタ フェイルオーバーをテストしていた (計画されたフェイルオーバー) という事実によって広まっている可能性があります。つまり、実際に彼らが行っているのは、Live Migration が宣伝どおりに機能する (クライアントの観点からはダウンタイムがない) ことを証明することだけです。
私の主なミスは、フェイルオーバー自体を誤解していたことです。ホット/ウォーム/コールドバックアップサーバーの概念に加えて、ホットサーバーで自動フェイルオーバーが発生するホット/ウォーム/コールドフェイルオーバーもあります。前述のようにここホット フェイルオーバーは瞬時に行われ、ウォーム フェイルオーバーは数秒、コールド フェイルオーバーは数分で行われます。自動障害はすべて「ホット」であると想定するのは、私の考えが甘すぎました。RAM で何らかの魔法が起こり、クラスターが別のノードの VM の RAM のコピーを更新する、SQL Server のトランザクション ログ シッピングのようなものを期待していたのだと思います。ただし、それが確実に機能するには、マシン間の通信チャネルが少なくとも RAM と同じ速度である必要があります。