Windows Server フェイルオーバー クラスタリングの実行

Google Cloud Platform(GCP)で Windows Server を使用してフェイルオーバー クラスタを作成できます。サーバーのグループが連携して Windows アプリケーションの可用性を向上させます。あるクラスタノードで障害が発生すると、別のノードがソフトウェアの実行を引き継ぎます。通常、フェイルオーバーは自動的に行われるようにします。また、フェイルオーバーを手動で開始することもできます。

このチュートリアルは、読者がフェイルオーバー クラスタリング、Active Directory(AD)、および Windows Server の管理に精通していることを前提とします。

GCP のネットワーキングの概要については、データセンター プロフェッショナルのための GCP: ネットワーキングをご覧ください。

アーキテクチャ

このチュートリアルでは、Compute Engine でフェイルオーバー クラスタを作成する方法について説明します。このシステム構成では、次の 2 台のサーバーを使用します。

  • Windows Server 2016 を実行するメインの Compute Engine VM インスタンス(ゾーン a
  • メイン インスタンスと一致するように構成された 2 番目のインスタンス(ゾーン b

また、AD ドメイン コントローラをデプロイします。このチュートリアルでは、このコントローラを次の目的で使用します。

  • Windows ドメインを提供する。
  • ホスト名を IP アドレスに解決する。
  • クラスタの必要なクォーラムを達成するために 3 番目の「投票者」となるファイル共有監視をホストする。

ドメイン コントローラは任意のゾーンに作成できます。このチュートリアルでは、ゾーン c を使用します。本番環境システムでは、ファイル共有監視を他の場所でホストできます。フェイルオーバー クラスタをサポートするためだけに別個の AD システムを配置する必要はありません。GCP での AD の使用に関する記事については、次のステップのリンクをご覧ください。

フェイルオーバー クラスタのデプロイに使用する 2 台のサーバーは、それぞれ別のゾーンに配置されています。各サーバーが別々の物理マシン上に存在するため、ゾーン障害の影響を回避できます。

次の図は、このチュートリアルでデプロイするアーキテクチャを示します。

フェイルオーバー クラスタ内の 2 つの Compute Engine VM を示すアーキテクチャ図

共有ストレージ オプション

このチュートリアルでは、高可用性の共有ストレージとしてファイル サーバーを設定する方法については説明しません。

GCP では、Windows Server フェイルオーバー クラスタリングで使用できる複数の共有ストレージ ソリューションをサポートしています。たとえば、次のソリューションを使用できます。

使用可能なその他の共有ストレージ ソリューションについては、次をご覧ください。

ネットワーク ルーティングの理解

クラスタがフェイルオーバーした後、リクエストは新しくアクティブになったノードに送られる必要があります。クラスタリング技術は通常、アドレス解決プロトコル(ARP)を使用してルーティングを処理します。このプロトコルは IP アドレスと MAC アドレスを関連付けます。GCP の Virtual Private Cloud(VPC)システムはソフトウェア定義ネットワーキングを使用します。これは MAC アドレスを提供しません。つまり、ARP によってブロードキャストされた変更はルーティングにまったく影響しません。したがって、クラスタでルーティングを機能させるには、内部ロードバランサからソフトウェアレベルの支援を受ける必要があります。

通常、内部負荷分散は、負荷を共有するために着信ネットワーク トラフィックを VPC 内部の複数のバックエンド インスタンスに分散します。フェイルオーバー クラスタリングでは、内部負荷分散を使用してすべてのトラフィックをただ 1 つのインスタンス(現在アクティブなクラスタノード)にルーティングします。内部負荷分散は次の方法で正しいノードを検出します。

  • 各 VM インスタンスは、Windows フェイルオーバー クラスタリングをサポートする Compute Engine エージェント インスタンスを実行します。このエージェントは VM インスタンスの IP アドレスを追跡します。
  • ロードバランサのフロントエンドは、着信トラフィック用の IP アドレスをアプリケーションに提供します。
  • ロードバランサのバックエンドはヘルスチェックを実行します。ヘルスチェック プロセスは、特定のポートを通じて VM インスタンスの固定 IP アドレスを使用することにより、各クラスタノード上のエージェントに定期的に ping します。デフォルト ポートは 59998 です。
  • ヘルスチェックには、リクエストのペイロードとしてアプリケーションの IP アドレスが含まれます。
  • エージェントは、リクエスト内の IP アドレスをホスト VM の IP アドレスのリストと比較します。一致する IP アドレスが見つかった場合、エージェントは値 1 のレスポンスを返します。それ以外の場合は 0 のレスポンスを返します。
  • ロードバランサは、ヘルスチェックに合格した VM に「正常」マークを付けます。ヘルスチェックに合格する VM は常に 1 つだけです。これは、そのワークロードの IP アドレスを持つ VM が 1 つしか存在しないためです。

フェイルオーバー時の動作

クラスタでフェイルオーバーが発生すると、次の変更が起こります。

  • Windows フェイルオーバー クラスタリングのアクティブ ノードで障害が発生したことを示すため、アクティブ ノードのステータスが変更されます。
  • クォーラムの定義に従って、障害が発生したノードから最適なノードにすべてのクラスタ リソースと役割が移動します。このアクションには、関連する IP アドレスの移動も含まれます。
  • ARP パケットがブロードキャストされ、IP アドレスが移動したことがハードウェアベースのネットワーク ルーターに通知されます。このシナリオでは、GCP ネットワーキングはこれらのパケットを無視します。
  • 移動後、障害ノードの VM ではリクエストで指定された IP アドレスはホストされないため、その VM 上の Compute Engine エージェントは、ヘルスチェックへのレスポンスを 1 から 0 に変更します。
  • 同様に、新しくアクティブになったノードの VM 上の Compute Engine エージェントもヘルスチェックへのレスポンスを 0 から 1 に変更します。
  • 内部ロードバランサは、障害ノードへのトラフィックのルーティングを停止し、新しくアクティブになったノードにトラフィックをルーティングします。

まとめ

これでおおよその概念がわかったので、次に上記のアーキテクチャ図について注目すべき点をいくつか示します。

  • wsfc-2 という名前の VM の Compute Engine エージェントは、ヘルスチェックに対して値 1 のレスポンスを返しています。これは、この VM が現在アクティブなクラスタノードであることを示します。wsfc-1 はレスポンス 0 を返しています。
  • ロードバランサは、矢印で示されているように、リクエストを wsfc-2 にルーティングします。
  • ロードバランサと wsfc-2 はどちらも IP アドレス 10.0.0.9 を持っています。ロードバランサの場合、これは指定されたフロントエンド IP アドレスです。VM の場合、これはアプリケーションの IP アドレスです。この IP アドレスは、フェイルオーバー クラスタの現在アクティブなノードに設定されます。
  • ロードバランサと wsfc-2 はどちらも IP アドレス 10.0.0.8 を持っています。VM がこの IP アドレスを持っているのは、この VM が現在クラスタ リソースをホストしているためです。

このチュートリアルを進める際のアドバイス

このチュートリアルには多くのステップがあります。場合によっては、Microsoft のドキュメントなどの外部ドキュメントの手順に従うよう指示されていることがあります。外部の手順に従うときは、このドキュメントに示された関連する注意事項を必ずお読みください。

このチュートリアルでは、Google Cloud Platform Console で Cloud Shell を使用します。GCP Console のユーザー インターフェースまたは Cloud SDK を使用してフェイルオーバー クラスタリングをセットアップすることも可能ですが、このチュートリアルでは作業を簡単に進められるように、主に Cloud Shell を使用しています。これにより、チュートリアルをより短時間で完了できます。手順によっては、GCP Console を使用するよう指示されていることもあります。

Cloud Shell

途中で Compute Engine の永続ディスクのスナップショットを作成することをおすすめします。何か問題が生じた場合は、スナップショットを使用することで、最初からやり直さなくて済みます。スナップショットを作成するタイミングは、その都度チュートリアルで指示されています。

手順がうまくいかない場合に備えて、そのとき読んでいるセクションに問題の対処方法が記載されている場合があります。そのような記載がない場合は、トラブルシューティングのセクションをご覧ください。

目標

  • ネットワークを作成する。
  • 2 つの Compute Engine VM に Windows Server 2016 をインストールする。
  • Windows Server の 3 番目のインスタンスに Active Directory をインストールして構成する。
  • フェイルオーバー クラスタをセットアップする(クォーラム用のファイル共有監視、ワークロードの役割を含む)。
  • 内部ロードバランサをセットアップする。
  • フェイルオーバーのオペレーションをテストして、クラスタが機能していることを確認する。

費用

このチュートリアルでは、Windows Server ライセンスを含む Compute Engine イメージを使用します。つまり、VM を実行したままにしておくと、このチュートリアルを実行するために相当な費用がかかる可能性があります。VM を使用していないときに VM を停止することをおすすめします。

このチュートリアルを完了するための費用の見積もりについては、料金計算ツールをご覧ください。

始める前に

  1. Google アカウントにログインします。

    Google アカウントをまだお持ちでない場合は、新しいアカウントを登録します。

  2. GCP Console のプロジェクト セレクタのページで、GCP プロジェクトを選択または作成します。

    プロジェクト セレクタのページに移動

  3. Google Cloud Platform プロジェクトに対して課金が有効になっていることを確認します。 詳しくは、課金を有効にする方法をご覧ください。

  4. Compute Engine API を有効にします。

    APIを有効にする

  5. Cloud Shell のインスタンスを開始します。
    Cloud Shell を開く

ネットワークの作成

これから作成するクラスタにはカスタム ネットワークが必要です。Cloud Shell で gcloud コマンドを実行して、VPC を使用したカスタム ネットワークと 1 つのサブネットワークを作成します。

  1. ネットワークを作成します。

    gcloud compute networks create wsfcnet --subnet-mode custom
    

    作成したネットワークの名前は wsfcnet です。

  2. サブネットワークを作成します。[YOUR_REGION] は近くの GCP リージョンに置き換えます。

    gcloud compute networks subnets create wsfcnetsub1 --network wsfcnet --region [YOUR_REGION] --range 10.0.0.0/16
    

    作成したサブネットワークの名前は wsfcnetsub1 です。

このサブネットワークの IP アドレスの CIDR 範囲は 10.0.0.0/16 です。これは範囲の一例であり、このチュートリアルではこの範囲を使用します。本番環境システムでは、ネットワーク管理者と相談して、システムの IP アドレスにとって適切な範囲を割り当ててください。

ファイアウォール ルールを作成する

デフォルトでは、ネットワークは外部トラフィックに対して閉じています。サーバーへのリモート接続を可能にするため、ファイアウォールのポートを開く必要があります。Cloud Shell で gcloud コマンドを使用してルールを作成します。

  1. このチュートリアルでは、RDP 接続を可能にするため、メイン ネットワーク上のポート 3389 を開きます。次のコマンドの [YOUR_IPv4_ADDRESS] は、VM インスタンスへの接続に使用する PC の IP アドレスに置き換えます。本番環境システムでは、IP アドレス範囲または一連のアドレスを指定できます

    gcloud compute firewall-rules create allow-rdp --network wsfcnet --allow tcp:3389 --source-ranges [YOUR_IPv4_ADDRESS]
    
  2. サブネットワークでは、サーバーが相互に通信できるように、すべてのポート上ですべてのプロトコルを許可します。本番環境システムでは、必要に応じて特定のポートだけを開くことを検討してください。

    gcloud compute firewall-rules create allow-all-subnet --network wsfcnet --allow all --source-ranges 10.0.0.0/16
    

    source-ranges の値がサブネットワークの作成時に使用した CIDR 範囲と一致していることに注意してください。

  3. ファイアウォール ルールを表示します。

    gcloud compute firewall-rules list
    

    出力は次のようになります。

    NAME              NETWORK  DIRECTION  PRIORITY  ALLOW            DENY  DISABLED
    allow-all-subnet  wsfcnet  INGRESS    1000      all                    False
    allow-rdp         wsfcnet  INGRESS    1000      tcp:3389               False

Compute Engine でフェイルオーバー クラスタリングを有効にする

Compute Engine エージェントでフェイルオーバー クラスタリングを有効にするには、VM 定義に enable-wsfc=true フラグを追加する必要があります。このフラグを VM のカスタム メタデータとして指定するか、VM ごとに構成ファイルを作成します(Compute Engine のドキュメントを参照)。

このチュートリアルでは、次のセクションで説明するように、VM の作成時にカスタム メタデータとしてフラグを定義します。また、wsfc-addrswsfc-agent-port のデフォルトの動作を利用するため、これらの値を設定する必要はありません。

サーバーの作成

次に、3 つのサーバーを作成します。Cloud Shell で gcloud コマンドを使用します。

最初のクラスタノード サーバーを作成する

新しい Compute Engine インスタンスを作成します。インスタンスを次のように構成します。

  • インスタンスに wsfc-1 という名前を付けます。
  • --zone フラグを近くの便利なゾーンに設定します。たとえば、us-central1-a などです。
  • --machine-type フラグを n1-standard-2. に設定します。
  • --image-project フラグを windows-cloud に設定します。
  • --image-family フラグを windows-2016 に設定します。
  • --scopes フラグを https://www.googleapis.com/auth/compute に設定します。
  • --can-ip-forward フラグを設定して IP 転送を有効にします。
  • --private-network-ip フラグを 10.0.0.4 に設定します。
  • ネットワークを wsfcnet に設定し、サブネットワークを wsfcnetsub1 に設定します。
  • --metadata パラメータを使用して enable-wsfc=true を設定します。

次のコマンドを実行します。[YOUR_ZONE_1] は、最初のゾーンの名前で置き換えます。

gcloud compute instances create wsfc-1 --zone [YOUR_ZONE_1] --machine-type n1-standard-2 --image-project windows-cloud --image-family windows-2016 --scopes https://www.googleapis.com/auth/compute --can-ip-forward --private-network-ip 10.0.0.4 --network wsfcnet --subnet wsfcnetsub1 --metadata enable-wsfc=true

2 番目のクラスタノード サーバーを作成する

2 番目のサーバーについても同じ手順に従いますが、次の点のみ変更します。

  • インスタンス名を wsfc-2 に設定します。
  • --zone フラグを最初のサーバーと異なるゾーンに設定します。たとえば、us-central1-b などです。
  • --private-network-ip フラグを 10.0.0.5 に設定します。

[YOUR_ZONE_2] は、2 番目のゾーンの名前で置き換えます。

gcloud compute instances create wsfc-2 --zone [YOUR_ZONE_2] --machine-type n1-standard-2 --image-project windows-cloud --image-family windows-2016 --scopes https://www.googleapis.com/auth/compute --can-ip-forward --private-network-ip 10.0.0.5 --network wsfcnet --subnet wsfcnetsub1  --metadata enable-wsfc=true

Active Directory 用の 3 番目のサーバーを作成する

ドメイン コントローラについても同じ手順に従いますが、次の点のみ変更します。

  • インスタンス名を wsfc-dc に設定します。
  • --zone フラグを他のサーバーと異なるゾーンに設定します。たとえば、us-central1-c などです。
  • --private-network-ip フラグを 10.0.0.6 に設定します。
  • --metadata enable-wsfc=true を省略します。

[YOUR_ZONE_3] は、使用するゾーンの名前に置き換えます。

gcloud compute instances create wsfc-dc --zone [YOUR_ZONE_3] --machine-type n1-standard-2 --image-project windows-cloud --image-family windows-2016 --scopes https://www.googleapis.com/auth/compute --can-ip-forward --private-network-ip 10.0.0.6 --network wsfcnet --subnet wsfcnetsub1

インスタンスを表示する

作成したインスタンスの詳細を表示できます。

gcloud compute instances list

出力は次のようになります。

NAME     ZONE           MACHINE_TYPE  PREEMPTIBLE INTERNAL_IP  EXTERNAL_IP     STATUS
wsfc-1   us-central1-a  n1-standard-2             10.0.0.4     35.203.131.133  RUNNING
wsfc-2   us-central1-b  n1-standard-2             10.0.0.5     35.203.130.194  RUNNING
wsfc-dc  us-central1-c  n1-standard-2             10.0.0.6     35.197.27.2     RUNNING

VM への接続

Windows ベースの VM に接続するには、最初に VM のパスワードを生成する必要があります。その後、RDP を使用して VM に接続できます。

パスワードを生成する

  1. [VM インスタンス] ページに移動します。

    [VM インスタンス] を開く

  2. 新しいパスワードが必要な VM インスタンスの名前をクリックします。

  3. インスタンスの詳細ページで [Windows パスワードを設定] ボタンをクリックし、パスワードを生成します。パスワードをコピーして安全な場所に保管してください。

RDP 経由で接続する

RDP を使用して Windows VM インスタンスに接続する方法の詳細については、Compute Engine のドキュメントに記載されています。これには次の方法があります。

  • 既存のクライアントを使用する。
  • Chrome RDP プラグインをブラウザに追加してから、GCP Console を通じて接続する。

    RDP の使用方法を見る

このチュートリアルでは、Windows インスタンスに接続する際、好みの RDP 接続方法を使用できます。

Windows ネットワークの構成

VM の作成時に割り当てた内部 IP アドレスは静的アドレスです。Windows で IP アドレスが静的として扱われるようにするには、これらのアドレスと一緒にデフォルト ゲートウェイと DNS サーバーの IP アドレスを Windows Server のネットワーク構成に追加する必要があります。

RDP を使用して wsfc-1wsfc-2wsfc-dc に接続します。各インスタンスに次の操作を行います。

  1. サーバー マネージャーの左ペインで [ローカル サーバー] を選択します。
  2. [プロパティ] ペインの [イーサネット] エントリで、[IPv4 アドレス(DHCP により割り当て)、IPv6(有効)] をクリックします。
  3. [イーサネット] を右クリックして [プロパティ] を選択します。
  4. [インターネット プロトコル バージョン 4 (TCP/IPv4)] をダブルクリックします。
  5. [次の IP アドレスを使う] を選択します。
  6. 作成時に VM に割り当てた内部 IP アドレスを入力します。

    • wsfc-1 の場合は「10.0.0.4」と入力します。
    • wsfc-2 の場合は「10.0.0.5」と入力します。
    • wsfc-dc の場合は「10.0.0.6」と入力します。
  7. [サブネット マスク] に「255.255.0.0」と入力します。

  8. [デフォルト ゲートウェイ] で 10.0.0.1 を入力します。これは、サブネット wsfcnetsub1 の作成時にデフォルト ゲートウェイに自動的に予約された IP アドレスです。

    デフォルト ゲートウェイの IP アドレスは常に、サブネットのプライマリ IP 範囲の 2 番目のアドレスになります。Virtual Private Cloud(VPC)ネットワークの概要の「予約済み IP」をご覧ください。

  9. wsfc-1wsfc-2 のみ:

    1. [次の DNS サーバーのアドレスを使う] をクリックします。

    2. [優先 DNS サーバー] に「10.0.0.6」と入力します。

  10. すべてのダイアログ ボックスを閉じます。

    これらの変更を適用すると VM インスタンスの仮想ネットワーク アダプタがリセットされるため、RDP 接続は失われます。

  11. RDP セッションを閉じてから、インスタンスに再接続します。前の手順のダイアログ ボックスがまだ開いている場合は、閉じます。

  12. ローカル サーバーのプロパティ セクションで、[イーサネット] の設定にローカル サーバーの IP アドレス(10.0.0.410.0.0.5、または 10.0.0.6)が反映されていることを確認します。反映されていない場合は、[インターネット プロトコル バージョン 4 (TCP/IPv4)] ダイアログ ボックスを再度開き、設定を更新します。

ここで wsfc-1wsfc-2 のスナップショットを作成することをおすすめします。

Active Directory のセットアップ

次に、ドメイン コントローラをセットアップします。

  1. RDP を使用して、wsfc-dc という名前のサーバーに接続します。
  2. Windows の「コンピューターの管理」デスクトップ アプリを使用して、ローカル管理者アカウントにパスワードを設定します。
  3. ローカル管理者アカウントを有効にします。
  4. 下記の Microsoft の手順に従ってドメイン コントローラをセットアップします。この作業に関する追加の注意事項を次に示します。ほとんどの設定でデフォルト値を使用できます。

    • [DNS サーバー] の役割チェックボックスをオンにします。これは Microsoft の手順に示されていません。
    • [必要に応じて対象サーバーを自動的に再起動する] チェックボックスをオンにします。
    • ファイル サーバーをドメイン コントローラに昇格させます。
    • [新しいフォレストを追加する] のステップで、ドメインに「WSFC.TEST」という名前を付けます。
    • NetBIOS ドメイン名を「WSFC」(デフォルト)に設定します。

    Microsoft の手順

ここで wsfc-dc のスナップショットを作成することをおすすめします。

ドメイン ユーザー アカウントを作成する

wsfc-dc が再起動するまで少し時間がかかることがあります。サーバーをドメインに参加させる前に、RDP を使用して wsfc-dc にログインし、ドメイン コントローラが実行されていることを確認します。

クラスタ サーバーの管理者権限を持つドメイン ユーザーが必要です。手順は次のとおりです。

  1. ドメイン コントローラ(wsfc-dc)で [スタート] をクリックし、「dsa」と入力して Active Directory ユーザーとコンピューター アプリを検索して開きます。
  2. [WSFC.TEST] を右クリックし、[新規作成] をポイントして [ユーザー] をクリックします。
  3. [フル ネーム] と [ユーザー ログオン名] に「cluster-admin」と入力します。
  4. [次へ] をクリックします。
  5. ユーザーのパスワードを入力して確認します。ダイアログ ボックスでパスワード オプションを選択します。たとえば、パスワードが期限切れにならないように設定できます。
  6. 設定を確認し、[完了] をクリックします。
  7. cluster-adminwsfc-dc の管理者に設定します。

    • cluster-admin を右クリックして [グループに追加...] をクリックします。
    • Administrators」と入力して、[OK] をクリックします。

このチュートリアルでは、管理者アカウントが必要な場合、WSFC.TEST\cluster-admin アカウントを管理者アカウントとして使用します。本番環境システムでは、アカウントと権限の割り当てに関してお客様が通常使用しているセキュリティ対策に従ってください。詳しくは、フェイルオーバー クラスタに必要な Active Directory アカウントの概要をご覧ください。

サーバーをドメインに参加させる

2 つのクラスタノード サーバーを WSFC.TEST ドメインに追加します。各クラスタノード サーバー(wsfc-1wsfc-2)で次の手順を実行します。

  1. [サーバー マネージャー] > [ローカル サーバー] の [プロパティ] ペインで [ワークグループ] をクリックします。
  2. [変更] をクリックします。
  3. [ドメイン] を選択し、「WSFC.TEST」と入力します。
  4. [OK] をクリックします。
  5. ドメインに参加するために WSFC.TEST\cluster-admin の認証情報を入力します。
  6. [OK] をクリックします。
  7. ダイアログ ボックスを閉じ、プロンプトに従ってサーバーを再起動します。
  8. [サーバー マネージャー] で、cluster-adminwsfc-1wsfc-2 の管理者に設定します。グループ ポリシーを使用して管理者権限を管理することもできます。

    • [ツール] メニューで、[コンピューターの管理] > [ローカル ユーザーとグループ] > [グループ] > [管理者] の順に選択し、[追加] をクリックします。
    • 「cluster-admin」と入力し、[名前の確認] をクリックします。
    • [OK] をクリックします。

ここで 3 つの VM すべてのスナップショットを作成することをおすすめします。

フェイルオーバー クラスタリングのセットアップ

Compute Engine のクラスタに IP アドレスを予約する

フェイルオーバー クラスタを作成するときに、IP アドレスを割り当て管理アクセス ポイントを作成します。本番環境では、別のサブネットの IP アドレスが必要になる可能性がありますが、このチュートリアルでは、作成したサブネットの IP アドレスを予約します。IP アドレスを予約することで、他の IP 割り当てとの競合を避けることができます。

  1. ホスト VM でターミナルを開くか、Cloud Shell を開きます。

    Cloud Shell に移動

  2. IP アドレスを予約します。このチュートリアルでは、10.0.0.8 を使用します。

    gcloud compute addresses create cluster-access-point --region [YOUR_REGION] --subnet wsfcnetsub1 --addresses 10.0.0.8
  3. 次のコマンドで IP アドレスの予約を確認します。

    gcloud compute addresses list

クラスタを作成する

フェイルオーバー クラスタを作成して構成するには:

  1. RDP を使用して wsfc-1wsfc-2 に接続します。
  2. 下記の Microsoft の手順に従います。この作業に関する追加の注意事項を次に示します。

    • wsfc-1wsfc-2 にフェイルオーバー クラスタリング機能をインストールします。wsfc-dc にはフェイルオーバー クラスタリング機能をインストールしないでください。
    • フェイルオーバー クラスタ マネージャー アプリをドメイン ユーザー WSFC.TEST\cluster-admin として実行します。そうしないと、権限の問題が発生する可能性があります。必要な権限を確保するため、この方法で常にフェイルオーバー クラスタ マネージャーを実行するか、cluster-admin としてサーバーに接続することをおすすめします。
    • wsfc-1wsfc-2 をノードとしてクラスタに追加します。
    • 構成を検証するとき:

      • [テスト オプション] ページで [選択するテストのみを実行する] を選択し、[次へ] をクリックします。
      • [テストの選択] ページで [ストレージ] の選択を解除します。[ストレージ] オプションは、Compute Engine で実行すると失敗します(これは独立したスタンドアロンの物理サーバー用オプションです)。

        クラスタの検証中によく発生する問題を以下に示します。

        • レプリカの間にネットワーク インターフェースが 1 つしかない。これはクラウドベースのセットアップでは適用されないため、無視してかまいません。
        • 両方のレプリカで Windows Update が同じでない。Windows インスタンスで更新プログラムを自動的に適用するよう構成している場合、一方のノードで、他方のノードがまだダウンロードしていない更新プログラムがすでに適用されている可能性があります。サーバーの構成を同一に保つ必要があります。
        • 再起動が保留中。一方のサーバーに変更を加えた場合は、その変更を適用するために再起動する必要があります。これを無視しないでください。
        • ドメインの役割がサーバー間で完全に一致していない。これは無視してかまいません。
        • サーバーがすべて同じ組織部門(OU)に属していない。このチュートリアルでは OU をまったく使用しませんが、本番環境システムではクラスタを独自の OU に所属させることを検討してください。Microsoft の手順には、このベスト プラクティスが記載されています。
        • 署名されていないドライバが見つかった。これは無視してかまいません。
    • [概要] ページで [検証されたノードを使用してクラスターを今すぐ作成する] を選択して、クラスタの作成に進むことができます。ウィザードをいったん閉じて再度開き直す必要はありません。

    • [クラスターの作成ウィザード] の [アクセス ポイント] ページで、次の操作を行います。

      • クラスタに「testcluster」という名前を設定します。
      • [アドレス] フィールドに、以前に予約した IP アドレス(10.0.0.8)を入力します。

    Microsoft の手順

クラスタ管理者を追加する

クラスタの管理者としてドメイン アカウントを追加すると、Windows PowerShell などのツールからクラスタを操作できます。クラスタ管理者として cluster-admin ドメイン アカウントを追加します。

  1. クラスタ リソースをホストするクラスタノードでフェイルオーバー クラスタ マネージャーを開き、左ペインでクラスタを選択してから、右ペインで [プロパティ] をクリックします。
  2. [クラスターのアクセス許可] タブを選択します。
  3. [追加] をクリックして、cluster-admin を追加します。
  4. [グループ名またはユーザー名] のリストで cluster-admin を選択し、[アクセス許可] ペインで [フル コントロール] を選択します。
  5. [適用] をクリックしてから [OK] をクリックします。

ここでスナップショットを作成することをおすすめします。

ファイル共有監視の作成

これで 2 ノードのフェイルオーバー クラスタが作成されましたが、クラスタは投票メカニズムを使用してどちらのノードをアクティブにするかを決定します。クォーラムを達成するため、ファイル共有監視を追加できます。

このチュートリアルでは、単にドメイン コントローラ サーバーに共有フォルダを追加するだけにします。どちらかのクラスタノードが再起動すると同時にドメイン コントローラ サーバーがオフラインになった場合、残りのサーバーは単独で投票できないため、クラスタ全体の機能が停止する可能性があります。このチュートリアルは、ライブ マイグレーション自動再起動などの GCP インフラストラクチャ機能が、共有フォルダを存続させるのに十分な信頼性を備えていることを前提としています。

より可用性の高いファイル共有監視を作成する場合は、次のオプションがあります。

  • Windows Server のクラスタで記憶域スペース ダイレクトを使用して共有を提供する。この Windows Server 2016 の機能は、クォーラム監視用の可用性の高い共有を提供できます。たとえば、Active Directory ドメイン コントローラ用のクラスタを作成して可用性の高いドメイン サービスを提供すると同時に、ファイル共有監視も提供できます。
  • Avere vFXT などのファイル サーバー ソリューションを使用する。
  • SIOS Datakeeper などのデータ レプリケーション ソフトウェアと Windows Server フェイルオーバー クラスタリングを使用して、同期または非同期でレプリケーションを行う。

監視用のファイル共有を作成するには、次の手順に従います。

  1. wsfc-dc に接続します。このサーバーでファイル共有をホストします。
  2. エクスプローラで C ドライブに移動します。
  3. タイトルバーの [新しいフォルダー] ボタンをクリックします。
  4. 新しいフォルダに shares という名前を設定します。
  5. shares フォルダをダブルクリックして開きます。
  6. 新しいフォルダを追加し、clusterwitness-testcluster という名前を付けます。

ファイル共有監視の共有を構成する

ファイル共有監視フォルダに対するアクセス許可を設定して、クラスタがこのフォルダを使用できるようにする必要があります。

  1. エクスプローラで clusterwitness-testcluster フォルダを右クリックして [プロパティ] を選択します。
  2. [共有] タブで [詳細な共有] をクリックします。
  3. [このフォルダーを共有する] を選択します。
  4. [アクセス許可] をクリックし、[追加] をクリックします。
  5. [オブジェクトの種類] をクリックし、[コンピューター] を選択して [OK] をクリックします。
  6. マシン アカウント testcluster$ を追加します。
  7. testcluster$フル コントロールのアクセス権を与えます。
  8. [適用] をクリックし、すべてのダイアログ ボックスを閉じます。

ファイル共有監視をフェイルオーバー クラスタに追加する

次に、ファイル共有監視がクォーラム投票として使用されるようにフェイルオーバー クラスタを構成します。

  1. クラスタ リソースをホストするコンピュータ(wsfc-1)でフェイルオーバー クラスタ マネージャーを開きます。
  2. 左ペインでクラスタの名前(testcluster.WSFC.TEST)を右クリックして [その他のアクション] をポイントし、[クラスター クォーラム設定の構成] をクリックします。
  3. [クォーラム構成オプションの選択] パネルで、[クォーラム監視を選択する] を選択します。
  4. [クォーラム監視を選択する] パネルで、[ファイル共有監視を構成する] を選択します。
  5. [ファイル共有パス] で、共有フォルダのパス(\\wsfc-dc\clusterwitness-testcluster など)を入力します。
  6. 設定を確認し、[完了] をクリックします。

フェイルオーバー クラスタのテスト

これで Windows Server フェイルオーバー クラスタが機能するはずです。インスタンス間でクラスタ リソースを手動で移動してテストできます。まだ終わりではありませんが、これは今までに行ったすべての作業に問題がないことを確認するのに良いチェックポイントです。

  1. wsfc-1 のフェイルオーバー クラスタ マネージャーで [現在のホストサーバー] の名前を確認します。
  2. cluster-admin として Windows PowerShell を実行します。
  3. PowerShell で次のコマンドを実行して、現在のホストサーバーを変更します。

    Move-ClusterGroup -Name "Cluster Group"
    

現在のホストサーバーの名前が他方の VM に変更されるはずです。

ホストサーバーが切り替わらなかった場合は、これまでの手順を振り返って何か見落としていないか確認します。最もよくある問題は、ファイアウォール ルールがないためにネットワーク上のアクセスがブロックされていることです。その他の確認すべき問題については、トラブルシューティングのセクションをご覧ください。

ホストサーバーが正常に切り替わった場合は、内部ロードバランサのセットアップに進むことができます。内部ロードバランサは、クラスタの現在のホストサーバーにネットワーク トラフィックをルーティングするために必要となります。

ここでスナップショットを作成することをおすすめします。

フェイルオーバー クラスタに役割を追加する

Windows フェイルオーバー クラスタリングでは、クラスタ化されたワークロードが役割によってホストされます。役割を使用して、アプリケーションで使用する IP アドレスをクラスタ内で指定できます。このチュートリアルでは、テスト ワークロード(Internet Information Services(IIS)ウェブサーバー)の役割を追加し、IP アドレスを割り当てます。

Compute Engine の役割に IP アドレスを予約する

Compute Engine のサブネット内での IP アドレスの競合を避けるため、この役割に IP アドレスを予約します。

  1. ホスト VM でターミナルを開くか、Cloud Shell を開きます。

    Cloud Shell に移動

  2. IP アドレスを予約します。このチュートリアルでは、10.0.0.9 を使用します。

    gcloud compute addresses create load-balancer-ip --region [YOUR_REGION] --subnet wsfcnetsub1 --addresses 10.0.0.9
  3. 次のコマンドで IP アドレスの予約を確認します。

    gcloud compute addresses list

役割を追加する

手順は次のとおりです。

  1. フェイルオーバー クラスタ マネージャーの [アクション] ペインで [役割の構成] を選択します。
  2. [役割の選択] ページで [その他のサーバー] を選択します。
  3. [クライアント アクセス ポイント] ページで IIS を入力します。
  4. アドレスを 10.0.0.9 に設定します。
  5. [記憶域の選択] と [リソース タイプの選択] はスキップします。
  6. 設定を確認し、[完了] をクリックします。

役割の設定を示す確認ダイアログ。

内部ロードバランサの作成

ネットワーク トラフィックがアクティブなクラスタ ホストノードにルーティングされるように、内部ロードバランサを作成して構成します。ユーザー インターフェースの方が内部負荷分散の構成がわかりやすいため、この作業には GCP Console を使用します。

また、クラスタの各ゾーンに Compute Engine インスタンス グループを作成します。ロードバランサは、このグループを使用してクラスタノードを管理します。

インスタンス グループを作成する

クラスタノードを含む各ゾーンにインスタンス グループを作成し、ノードをそのゾーンのインスタンス グループに追加します。ドメイン コントローラ wsfc-dc はインスタンス グループに追加しません。

  1. クラスタ内の各ゾーンにインスタンス グループを作成します。[ZONE_1] は最初のゾーン名で置き換え、[ZONE_2] は 2 番目のゾーン名で置き換えます。

    gcloud compute instance-groups unmanaged create wsfc-group-1 --zone=[ZONE_1]
    gcloud compute instance-groups unmanaged create wsfc-group-2 --zone=[ZONE_2]
  2. 各ゾーンのサーバーをそのゾーンのインスタンス グループに追加します。

    gcloud compute instance-groups unmanaged add-instances wsfc-group-1 --instances wsfc-1 --zone [ZONE_1]
    gcloud compute instance-groups unmanaged add-instances wsfc-group-2 --instances wsfc-2 --zone [ZONE_2]
  3. インスタンス グループが作成され、各グループに 1 つのインスタンスが存在することを確認します。

    gcloud compute instance-groups unmanaged list
      NAME          ZONE           NETWORK  NETWORK_PROJECT   MANAGED  INSTANCES
      wsfc-group-1  us-central1-a  wsfcnet  exampleproject    No       1
      wsfc-group-2  us-central1-b  wsfcnet  exampleproject    No       1

ロードバランサを作成する

  1. GCP Console で [負荷分散] ページに移動します。

    [負荷分散] を開く

    出力は次のようになります。

  2. [ロードバランサを作成] をクリックします。

  3. [TCP 負荷分散] カードで [設定を開始] をクリックします。

  4. [VM 間のみ] を選択して [続行] をクリックします。

  5. [名前] に「wsfc-lb」と入力します。

まだ [作成] はクリックしないでください。

バックエンドを構成する

GCP の内部ロードバランサは定期的なヘルスチェックを使用してアクティブ ノードを決定することを思い出してください。ヘルスチェックは、アクティブ クラスタノードで実行されている Compute Engine クラスタホスト エージェントに ping します。ヘルスチェックのペイロードは、クラスタ化された役割によって表されるアプリケーションの IP アドレスです。エージェントは、ノードがアクティブな場合は 1、アクティブでない場合は 0 のレスポンスを返します。

  1. [バックエンドの設定] をクリックします。
  2. 現在のリージョンを選択します。
  3. [ネットワーク] で wsfcnet を選択します。
  4. [バックエンド] で、作成したインスタンス グループの名前を選択して [完了] をクリックし、インスタンス グループを追加します。
  5. ヘルスチェックを作成します。

    • [名前] に「wsfc-hc」と入力します。
    • [プロトコル] の設定はデフォルトの [TCP] のままとし、[ポート] は「59998」に変更します。これはクラスタホスト エージェントからのレスポンス用のポートです。
    • [リクエスト] に「10.0.0.9」と入力します。
    • [レスポンス] に「1」と入力します。
    • [チェック間隔] に「2」と入力します。
    • [タイムアウト] に「1」と入力します。
    • [保存して次へ] をクリックします。

フロントエンドを構成する

フロントエンド構成では、ロードバランサが着信リクエストをどのように処理するかを定義する転送ルールを作成します。このチュートリアルでは、シンプルにするため、サブネットワーク内の VM 間でリクエストを発行することによってシステムをテストします。

本番環境システムでは、おそらくインターネット トラフィックなどの外部トラフィックにまでシステムを開放する必要があります。そのためには、外部トラフィックを受け入れて内部ネットワークに転送する要塞ホストを作成します。このチュートリアルでは、要塞ホストの使用については説明しません。

  1. 中央ペインで [フロントエンドの設定] をクリックします。
  2. [名前] に「wsfc-lb-fe」と入力します。
  3. サブネットワーク(wsfcnetsub1)を選択します。
  4. [内部 IP] で load-balancer-ip(10.0.0.9)を選択します。これは、役割に設定した IP アドレスと同じです。
  5. [ポート] に「80」と入力します。
  6. [完了] をクリックします。

確認と完了

  1. 内部ロードバランサの設定の要約を表示するため、中央ペインで [確認と完了] をクリックします。右ペインに要約が表示されます。
  2. [作成] をクリックします。ロードバランサの作成には少し時間がかかります。

    内部負荷分散の最終的な設定を示す GCP Console。

ヘルスチェック用のファイアウォール ルールを作成する

ヘルスチェックがターゲットに到達できるようにファイアウォール ルールを作成する必要があることを知らせるメッセージが GCP Console に表示されます。このセクションではファイアウォール ルールをセットアップします。

  1. GCP Console で Cloud Shell に戻ります。

    Cloud Shell を開く

  2. 次のコマンドを実行して、ファイアウォール ルールを作成します。

    gcloud compute firewall-rules create allow-health-check --network wsfcnet --source-ranges 130.211.0.0/22,35.191.0.0/16 --allow tcp:59998
    

Windows ファイアウォールを開く

ロードバランサが Windows システムにアクセスできるように、Windows ファイアウォールでクラスタノード wsfc-1wsfc-2 にファイアウォール ルールを作成します。

  1. [セキュリティが強化された Windows ファイアウォール] アプリを開きます。

  2. 左側のナビゲーション ペインで [受信の規則] を選択します。

  3. 右側のナビゲーション ペインで [新しい規則] を選択します。

  4. [規則の種類] パネルで、規則の種類に [カスタム] を選択して、[次へ] をクリックします。

  5. [プログラム] パネルでデフォルトの値を受け入れ、[次へ] をクリックします。

  6. [プロトコルおよびポート] パネルで次の操作を行います。

    1. [プロトコルの種類:] フィールドで TCP を選択します。
    2. [ローカル ポート:] フィールドで、[特定のポート] を選択して 59998 を入力します。
  7. [スコープ] パネルの [この規則を適用するリモート IP アドレスを選択してください] で次の操作を行います。

    1. [これらの IP アドレス:] を選択します。
    2. [追加] をクリックして、次の IP アドレスを [この IP アドレスまたはサブネット] フィールドに追加します。

      • 130.211.0.0/22
      • 35.191.0.0/16
    3. [次へ] をクリックします。

  8. [操作] パネルで、[接続を許可する] を承諾し、[次へ] をクリックします。

  9. [プロファイル] パネルでデフォルト値を承諾し、[次へ] をクリックします。

  10. ファイアウォール ルールの名前を指定して、[完了] をクリックします。

ロードバランサの検証

内部ロードバランサを実行した後、そのステータスを調べて内部ロードバランサが正常なインスタンスを検出できることを確認し、フェイルオーバーを再度テストできます。

  1. GCP Console の [負荷分散] ページに戻ります。

    [負荷分散] を開く

  2. ロードバランサの名前(wsfc-lb)をクリックします。

    サマリーの [バックエンド] セクションにインスタンス グループが表示されていることを確認します。

    次の図は、wsfc-lb ロードバランサの詳細ページで、インスタンス グループ wsfc-group-1 にアクティブ ノードがあり、[正常] 列に 1 / 1 が表示されています。インスタンス グループ wsfc-group-2 にはアクティブでないノードが存在し、0 / 1 と表示されています。

    ロードバランサのステータスを見ると、インスタンス グループ wsfc-group-1 で正常なインスタンス数が 1 / 1 と表示されています。これは、このグループにアクティブ ノードがあることを意味しています。

    両方のインスタンス グループに 0 / 1 が表示されている場合、ロードバランサでノードの同期が完了していない可能性があります。場合によっては、ロードバランサに IP アドレスを検出させるために少なくとも 1 回フェイルオーバー アクションを実行しなければならないことがあります。

  3. フェイルオーバー クラスタ マネージャーで、クラスタ名を展開し、[役割] をクリックします。[所有者ノード] 列で、IIS 役割のサーバー名をメモします。

  4. IIS 役割を右クリックし、[移動] > [最適なノード] をクリックして、ファイルオーバーを開始します。これにより、役割が別のノードに移動します。これは [所有者ノード] フィールドに示されます。

    フェイルオーバー クラスタ マネージャーの [所有者ノード] フィールド。

  5. [状態] が [実行中] になるまで待ちます。

  6. [ロードバランサの詳細] ページに戻り、[更新] をクリックします。インスタンス グループの間で [正常] 列の 1 / 10 / 1 の値が入れ替わっていることを確認します。

    2 つのインスタンスのうち 1 つが正常であることを示すロードバランサのステータス。

ヒント: gcloud ツールを使用して、どのインスタンスが正常であるかを確認できます。[REGION] は使用しているリージョンに置き換えます。

gcloud compute backend-services get-health wsfc-lb --region=[REGION]

出力は次のようになります。

backend: https://www.googleapis.com/compute/v1/projects/exampleproject/zones/us-central1-a/instanceGroups/wsfc-group-1
status:
  healthStatus:
  - healthState: HEALTHY
    instance: https://www.googleapis.com/compute/v1/projects/exampleproject/zones/us-central1-a/instances/wsfc-1
    ipAddress: 10.0.0.4
    port: 80
  kind: compute#backendServiceGroupHealth
---
backend: https://www.googleapis.com/compute/v1/projects/exampleproject/zones/us-central1-b/instanceGroups/wsfc-group-2
status:
  healthStatus:
  - healthState: UNHEALTHY
    instance: https://www.googleapis.com/compute/v1/projects/exampleproject/zones/us-central1-b/instances/wsfc-2
    ipAddress: 10.0.0.5
    port: 80
  kind: compute#backendServiceGroupHealth

アプリケーションのインストール

これでクラスタが作成されたので、次に各ノードでアプリケーションをセットアップし、クラスタ環境で実行されるように構成できます。

このチュートリアルでは、クラスタが実際に内部ロードバランサと連携していることを実証できるものをセットアップする必要があります。この例では、各 VM に IIS をセットアップして単純なウェブページを提供します。

高可用性 IIS はクラスタにセットアップしません。それぞれ異なるウェブページを提供する別々の IIS インスタンスを作成します。フェイルオーバーの後、ウェブサーバーは共有コンテンツではなく、そのサーバー独自のコンテンツを提供します。

その他のアプリケーションまたは高可用性 IIS をセットアップすることは、このチュートリアルの範囲を超えています。

IIS をセットアップする

  1. 各クラスタノードに IIS をインストールします。

    • [役割サービスの選択] ページを開き、[共通の HTTP 機能] で [既定のドキュメント] が選択されていることを確認してください。
    • [確認] ページで、対象サーバーを自動的に再起動するチェックボックスをオンにします。
  2. 各ウェブサーバーが動作していることを確認します。

    1. RDP を使用して、wsfc-dc という名前の VM に接続します。
    2. [サーバー マネージャー] で、ウィンドウの左側にあるナビゲーション ペインの [ローカル サーバー] をクリックします。
    3. 上部にある [プロパティ] セクションで、[IE セキュリティ強化の構成] をオフにします。
    4. Internet Explorer を開きます。
    5. アドレス欄に各サーバーの IP アドレスを入力してウェブサーバーにアクセスします。

      http://10.0.0.4/
      http://10.0.0.5/

それぞれのケースで [ようこそ] ページが表示されます。これは IIS のデフォルトのウェブページです。

デフォルトのウェブページを編集する

それぞれのデフォルト ウェブページを変更して、現在どちらのサーバーがページを提供しているか簡単にわかるようにします。

  1. RDP を使用して、wsfc-1 という名前の VM に接続します。
  2. 管理者としてメモ帳を起動します。
  3. メモ帳で C:\inetpub\wwwroot\iisstart.htm を開きます。ファイルを開く際のダイアログ ボックスで、テキスト ファイルだけでなく [すべてのファイル] が表示されるようにしてください。
  4. <title> 要素のテキストを現在のサーバーの名前に変更します。次に例を示します。

        <title>wsfc-1</title>
    
  5. HTML ファイルを保存します。

  6. wsfc-2 に対して同じ手順を繰り返し、<title> 要素を wsfc-2 に設定します。

これで、どちらかのサーバーから提供されたウェブページを表示すると、サーバーの名前が Internet Explorer タブのタイトルとして表示されるようになりました。

フェイルオーバーをテストする

  1. RDP を使用して、wsfc-dc という名前の VM に接続します。
  2. Internet Explorer を開きます。
  3. ロードバランサの役割の IP アドレスにアクセスします。

    http://10.0.0.9/
    

    [ようこそ] ページが開き、現在のサーバーの名前がタブのタイトルに表示されます。

  4. 現在のサーバーを停止して障害をシミュレートします。Cloud Shell で次のコマンドを実行します。[INSTANCE_NAME] は前の手順で表示された現在のサーバーの名前(wsfc-1 など)に置き換えます。

    gcloud compute instances stop [INSTANCE_NAME] --zone=[ACTIVE_ZONE]
    
  5. RDP 接続を wsfc-dc に切り替えます。

    ロードバランサが移動を検出してトラフィックを再ルーティングするまで少し時間がかかることがあります。

  6. 30 秒ほどたったら、Internet Explorer でページを更新します。

    これで、タブのタイトルに新しいアクティブ ノードの名前が表示されます。たとえば、wsfc-1 がアクティブな状態で手順を開始した場合、タイトルの表示は wsfc-2 になります。すぐに変更が表示されない場合や、ページが見つかりませんというエラーが表示された場合は、ブラウザを再度更新してください。

以上でチュートリアルは終了です。これで Windows Server 2016 フェイルオーバー クラスタが GCP 上で正常に機能します。

トラブルシューティング

以下によくある問題を示します。手順がうまくいかない場合はこれらを確認してください。

GCP ファイアウォール ルールによってヘルスチェックがブロックされている

ヘルスチェックが機能しない場合は、ヘルスチェック システムで使用されている IP アドレス(130.211.0.0/2235.191.0.0/16)からの受信トラフィックを許可するファイアウォール ルールがあることを再確認します。

Windows ファイアウォールによってヘルスチェックがブロックされている

各クラスタノードの Windows ファイアウォールでポート 59998 が開いていることを確認します。Windows ファイアウォールを開くをご覧ください。

クラスタノードが DHCP を使用している

クラスタ内の各 VM に静的 IP アドレスが設定されていることが重要です。VM 上の Windows が DHCP を使用するように構成されている場合は、Windows のネットワーク設定を変更して、その IPv4 アドレスを GCP Console に表示される VM の IP アドレスと一致させます。さらに、ゲートウェイの IP アドレスを GCP VPC 内のサブネットワーク ゲートウェイのアドレスと一致させます。

ファイアウォール ルールの GCP ネットワーク タグ

ファイアウォール ルールでネットワーク タグを使用する場合は、すべての VM インスタンスで正しいタグが設定されていることを確認してください。このチュートリアルではタグは使用しませんが、なんらかの理由でタグを設定した場合は、一貫して使用する必要があります。

クリーンアップ

このチュートリアルで使用したリソースについて、Google Cloud Platform アカウントに課金されないようにする手順は次のとおりです。

フェイルオーバー クラスタリングのチュートリアルが終了したら、GCP で作成したリソースをクリーンアップして、今後料金が発生しないようにします。次のセクションで、リソースを削除または無効にする方法を説明します。

プロジェクトの削除

課金をなくす最も簡単な方法は、チュートリアル用に作成したプロジェクトを削除することです。

プロジェクトを削除する手順は次のとおりです。

  1. GCP Console で [プロジェクト] ページに移動します。

    プロジェクト ページに移動

  2. プロジェクト リストで、削除するプロジェクトを選択し、[削除] をクリックします。
  3. ダイアログでプロジェクト ID を入力し、[シャットダウン] をクリックしてプロジェクトを削除します。

プロジェクトを削除せずにリソースをクリーンアップする

プロジェクトを残す必要がある場合は、チュートリアルのリソースを個別に削除し、クリーンアップできます。

インスタンスを削除する

Compute Engine インスタンスを削除するには:

  1. GCP Console の [VM インスタンス] ページに移動します。

    [VM インスタンス] ページに移動

  2. 次のチェックボックスをオンにします。 削除するインスタンス。
  3. インスタンスを削除するには、[削除] () をクリックします。

インスタンス グループを削除する

  1. GCP Console で、[インスタンス グループ] ページに移動します。

    [インスタンス グループ] ページに移動

  2. 次のチェックボックスをオンにします。 削除するインスタンス グループ。
  3. インスタンス グループを削除するには、ページの上部にある [削除]()をクリックします。

ロードバランサを削除する

ロードバランサを削除するには:

  1. GCP Console で [負荷分散] ページに移動します。

    [負荷分散] ページに移動

  2. 削除するロードバランサの名前の隣にあるチェックボックスをオンにします。

  3. ページ上部にある [削除] ボタンをクリックします。

VPC ネットワークを削除する

永続ディスクを削除するには:

  1. GCP Console で [VPC ネットワーク] ページに移動します。

    [VPC ネットワーク] ページに移動

  2. 削除するネットワークの名前をクリックします。

  3. ページの上部にある [VPC ネットワークを削除] ボタンをクリックします。

予約済みの IP アドレスを解放する

Cloud Shell を使用して予約済みの IP アドレスを解放するには:

  1. Cloud Shell のインスタンスを開始します。
    Cloud Shell を開く

  2. 予約済みの IP アドレスを解放します。

    gcloud compute addresses delete cluster-access-point load-balancer-ip

永続ディスクを削除する

永続ディスクを削除するには:

  1. GCP Console で [ディスク] ページに移動します。

    [ディスク] ページに移動

  2. 削除するディスクの名前の横にあるチェックボックスをオンにします。

  3. ページ上部にある [削除] ボタンをクリックします。

次のステップ

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

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

Compute Engine ドキュメント