☰

Hyper V 上の SQL クラスタリング - クラスタ内のクラスタはメリットとなるか

tag-icon • tag-icon sql-server-2008 windows-server-2008-r2 cluster
Hyper V 上の SQL クラスタリング - クラスタ内のクラスタはメリットとなるか

これは、質問しばらく前に質問したのですが、コンサルタントが来て部門内の他のチームにアイデアを出し始めた後、問題全体が再び浮上したので、より詳細な回答を求めています。

私たちは、各 SQL インスタンスでさまざまなシステムを実行する複数の物理ブレードにまたがるマルチインスタンス SQL クラスターをセットアップする予定です。一般的な使用では、各 VM ホストで 1 つの仮想 SQL インスタンスが実行されます。また、一般的な操作では、各 VM ホストは専用の基盤ブレードで実行されます。このセットアップにより、すべての SQL インスタンスが必要に応じてフェールオーバーできるため、個々の VM または基盤ブレードのメンテナンスに多くの柔軟性が得られます。

当初の計画は次の通りでした。

  1. 各ブレードに2008 R2をインストールする
  2. 各ブレードにHyper Vを追加する
  3. 各ブレードに2008 R2 VMをインストールする
  4. VM 内でフェールオーバー クラスターを作成し、SQL Server クラスタリングをインストールします。

コンサルタントは代わりに次のことを行うことを提案しました。

  1. 各ブレードに2008 R2をインストールする
  2. 各ブレードにHyper Vを追加する
  3. 各ブレードに2008 R2 VMをインストールする
  4. すべての VM をホストする HOST マシン上にクラスターを作成します。
  5. VM 内でフェールオーバー クラスターを作成し、SQL Server クラスタリングをインストールします。

大きな違いは、ステップ 4 を追加して、すべてのゲスト VM もクラスター化することです。SQL クラスターと物理ハードウェアの間にはまったく関係がないため、メンテナンスがさらに改善されるという主張です。理論上は、SQL クラスターにまったく影響を与えずに、ゲスト VM をホスト間でライブ マイグレーションできるため、定期的なメンテナンスの物理ブレードでは、中断することなく、またフェイルオーバーの必要もなく、SQL クラスターを移動できます。

いいアイデアのように思えますが、インターネット上で、これを実行して問題なく動作したという話は見たことがありません。ゲスト内でホストされている SQL クラスターに支障をきたすことなく、ゲストのライブ マイグレーションを実際に実行できますか?

この設定について、良い点、悪い点など、何か経験のある方はいらっしゃいますか? 私が考慮していない長所や短所はありますか?

ミラーリングも検討する価値のあるオプションであることは理解しています。この場合、各インスタンス全体を実行し、データベースの数が多いため、クラスタリングを優先します。一部の DB は、ミラーリングではうまく動作しない可能性のある、扱いにくいサードパーティ システム用です (クラスタリングに関する私の理解では、フェイルオーバーはクライアントに対して完全に透過的です)。

ありがとう。

答え1

これらのブレードが SQL Server の実行専用になるのであれば、なぜ仮想化を気にする必要があるのでしょうか?

追加の仮想化オーバーヘッドなしで、それぞれに Windows Server と SQL Server をインストールし、それに応じてクラスターを設定してみてはいかがでしょうか。

答え2

複雑そうですね。

あなたのソリューションの「複雑さ」と、標準的な物理クラスター化された SQL サーバー実装の信頼性および相対的な単純さを比較検討する必要があります。

すべてのデータベースがミッションクリティカルですか? 私の経験では、通常はそうではないので、最も重要なデータベースを完全な復元力を備えたサーバーでホストし、残り (通常、大部分) をシンプルな SQL サーバーでホストする傾向があります。

これにより、すべてのボールを同時に空中に浮かせておく必要がなくなり、最も重要なシステムを稼働させ続けることに集中できるようになります。

すべてのサーバーは定期的なメンテナンスが必要です。セキュリティ パッチの定期性、厳しさ、重要性を考慮して、理論上の 5 ナインの稼働時間 (ユーザーには好まれますが、実際には必要ありません) を維持するという目標から、より現実的な「サーバーを安全かつセキュアに保ちますが、サーバーに適切なパッチを適用できるように、短いメンテナンス期間を設ける必要があります」という目標に移行しました。

答え3

リストされているオプションのうち、私は #2 を選びますが、SQL をクラスター化することはしません (手順 5)。これは、メリットがあまりない複雑さの層を追加するだけだからです。Hyper-V クラスタリングでは、どちらのホストでもその VM を実行できるため、ハードウェア障害に対処できます。

SQL ログとデータベース ボリュームに固定サイズの VHD を使用する予定であると想定します。

Hyper-V を完全にスキップして、2 つのブレードを通常の SQL クラスターとして使用するという他のユーザーのコメントは完全に理解できます。これは確かに従来のアプローチです。ただし、ワークロードを仮想化することで得られる柔軟性の利点は、メンテナンス、アップグレード、ハードウェア障害の点で非常に大きいです。VM の移植性は非常に魅力的です。

ただし、このソリューションの価値は環境によっても異なります。他の Hyper-V サーバーがなく、スタッフに Hyper-V の経験があまりない場合、最も重要なワークロードの 1 つを仮想化するのは得策ではないかもしれません。ただし、多くの IT ショップのように、それほど重要でないサーバーの仮想化を開始し、いくつかのホストを構築し、Hyper-V を安定して実行するためのスキルと手順を持っている場合は、その焦点をより重要なワークロードに拡大することはまったく合理的です。個人的には、SQL レベルではなくホスト レベルでクラスタリングを管理したいと考えており、まだ一般的ではありませんが、これがますます行われるようになると思います。

最後に、Hyper-V で SQL を実行することに関する質問です。はい、ライブ マイグレーションは SQL で正常に動作し、気付くことはありません。また、SQL データベース ミラーリングは優れていますが、普遍的にサポートされているわけではないため、すべての状況に適合するわけではありません。

答え4

あなたのコンサルタントの考えは正しいと思います。私も彼とまったく同じ考えを持っており、それを現在の環境に実装したいと考えています。2 つの物理ハードウェアがあり、各ハードウェアで Hyper-V が実行され、2 つの W2k8 がインストールされています。

  1. 最初の物理ホストに 2 つの VM をインストールします。
  2. VM1 に SQL をインストールし、複製された環境へのフェイルオーバーのために O/S レベルでフォールト トレランスを設定して VM2 とミラーリングまたはクラスター化します。
  3. 2 番目の物理サーバーに W2k8 をインストールし、Hyper-V をフェールオーバー クラスター化します。

これにより、SQL 環境で完全なレベルのフェイルオーバー クラスタリングと完全な H/A が実現します。

それとも私の考えは愚かなのでしょうか?

関連情報