Compute Engine で Microsoft SQL Server Always On 可用性グループを作成する

このホワイト ペーパーでは、Google Compute Engine で Microsoft SQL Server Always On 可用性グループを作成する方法について説明します。本書は、Always On 可用性グループを使用して可用性の高い Microsoft SQL Server 環境を構築することを検討しているデータベース管理者、Windows 管理者、デベロッパーを対象としています。

本書では、以下の方法について学習します。

  • Compute Engine で最初の可用性グループを作成する
  • 4 つの失敗シミュレーションを使用して作業をテストする
  • Compute Engine でデータベースが適切に動作するかどうかを確認する

本書では、SQL Server のセットアップ(クラウドの仮想マシン(VM)でのインストールを含む)における多くの一般的なタスクについては省略しています。

一部のセットアップと設定のタスクは PowerShell を使用して実行しますが、PowerShell に慣れていなくても手順を進めることができます。

アーキテクチャについて

同じゾーンで 2 つの SQL Server 仮想マシンを使用する 2 ノードの Always On 可用性グループを作成します。

手順を簡素化するために、ネットワーク セキュリティ、VPN、アプリケーション サーバーなどは扱わず、SQL Server はインターネットに公開しません。

Always On 可用性グループ(AG)がクラウドに適している理由は次のとおりです。

  • 複数のデータベースの自動フェイルオーバー: これは一般的な高可用性の要件であり、オンプレミスの場合、DBA は通常、フェイルオーバー クラスタ インスタンス(FCI)を使用してこれを解決します。ただし、この場合には、今日の IaaS(Infrastructure-as-a-Service)クラウドでは一般的に利用できない共有ストレージが必要です。サードパーティ ソフトウェアや UNC パスに関連する回避策もいくつかありますが、いずれも IaaS では有効なオプションでありません。Always On 可用性グループは、共有ストレージを必要とすることなくこれを実現できます。
  • 破損したデータページの自動修復: 各レプリカは、データベースのデータページのコピーを保持します。ログに記録されたトランザクションのみがレプリカから別のレプリカに送信され、データページは送信されません。レプリカのデータページが破損すると、そのページのクリーンコピーを別のレプリカにリクエストし、自身で修復することができます。すべての破損から保護することはできませんが、多くの状況で役立ちます。
  • パッチ適用時のダウンタイムの短縮が可能: ダウンタイムを最小化するため、セカンダリ レプリカにパッチを適用し、パッチ適用が正常に行われたことを確認してから、停止時間を経て、プライマリ レプリカから新たにパッチが適用されたセカンダリにフェイルオーバーします。その後、前のプライマリ インスタンスにパッチを適用できます。いずれかのレプリカのパッチ適用で問題が発生した場合は、新しいレプリカを構築してそのレプリカを置き換え、AG に追加します。
  • ダウンタイムを短縮してスケールを容易にすることが可能: より大きなインスタンス タイプに切り替える場合、新しいインスタンスをプロビジョニングして AG に追加し、そのインスタンスにフェイルオーバーしてから、前のインスタンスを削除することができます。この方法でスケールアップとスケールダウンを行うことで負荷に対応できますが、スクリプト ベースで日常的な変動に対処する方法としては一般的に使用されません。むしろ時宜に応じて行う方法といえます。

2 ノードの可用性グループ設計には、いくつかのデメリットがあります。

  • 高コスト: ウォーム スタンバイ状態を維持することにより、Compute Engine の費用が倍増します。
  • 複雑化: 従来の独立した SQL Server VM よりも管理が難しく、Windows クラスタの知識が必要です。
  • ディザスタ リカバリがない: 別のゾーンまたはリージョンにフェイルオーバーできるようにするには、VM を追加する必要がありますが、これは後で行えます。

ホワイト ペーパー全体を読むには、次のボタンをクリックしてください。

PDF をダウンロード

このページは役立ちましたか?評価をお願いいたします。

フィードバックを送信...