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 台のサーバーは、それぞれ別のゾーンに配置されています。各サーバーが別々の物理マシン上に存在するため、ゾーン障害の影響を回避できます。
次の図は、このチュートリアルでデプロイするアーキテクチャを示します。
共有ストレージ オプション
このチュートリアルでは、高可用性の共有ストレージとしてファイル サーバーを設定する方法については説明しません。
Google Cloud では、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 コンソールで Cloud Shell を使用します。 Google Cloud コンソールのユーザー インターフェースまたは gcloud CLI を使用してフェイルオーバー クラスタリングをセットアップすることも可能ですが、このチュートリアルでは作業を簡単に進められるように、主に Cloud Shell を使用しています。これにより、チュートリアルをより短時間で完了できます。手順によっては、 Google Cloud コンソールを使用するよう指示されていることもあります。
途中で Compute Engine の永続ディスクのスナップショットを作成することをおすすめします。何か問題が生じた場合は、スナップショットを使用することで、最初からやり直さなくて済みます。スナップショットを作成するタイミングは、その都度チュートリアルで指示されています。
手順がうまくいかない場合に備えて、そのとき読んでいるセクションに問題の対処方法が記載されている場合があります。そのような記載がない場合は、トラブルシューティングのセクションをご覧ください。
目標
- ネットワークを作成する。
- 2 つの Compute Engine VM に Windows Server 2016 をインストールする。
- Windows Server の 3 番目のインスタンスに Active Directory をインストールして構成する。
- フェイルオーバー クラスタをセットアップする（クォーラム用のファイル共有監視、ワークロードの役割を含む）。
- 内部ロードバランサをセットアップする。
- フェイルオーバーのオペレーションをテストして、クラスタが機能していることを確認する。
費用
このチュートリアルでは、Windows Server ライセンスを含む Compute Engine イメージを使用します。つまり、VM を実行したままにしておくと、このチュートリアルを実行するために相当な費用がかかる可能性があります。VM を使用していないときに VM を停止することをおすすめします。
このチュートリアルを完了するための費用の見積もりについては、料金計算ツールをご覧ください。
始める前に
- Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.
-
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
Roles required to select or create a project
- Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
-
Create a project: To create a project, you need the Project Creator
(
roles/resourcemanager.projectCreator), which contains theresourcemanager.projects.createpermission. Learn how to grant roles.
-
Verify that billing is enabled for your Google Cloud project.
-
Enable the Compute Engine API.
Roles required to enable APIs
To enable APIs, you need the Service Usage Admin IAM role (
roles/serviceusage.serviceUsageAdmin), which contains theserviceusage.services.enablepermission. Learn how to grant roles. -
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
Roles required to select or create a project
- Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
-
Create a project: To create a project, you need the Project Creator
(
roles/resourcemanager.projectCreator), which contains theresourcemanager.projects.createpermission. Learn how to grant roles.
-
Verify that billing is enabled for your Google Cloud project.
-
Enable the Compute Engine API.
Roles required to enable APIs
To enable APIs, you need the Service Usage Admin IAM role (
roles/serviceusage.serviceUsageAdmin), which contains theserviceusage.services.enablepermission. Learn how to grant roles. - Cloud Shell のインスタンスを開始します。
Cloud Shell に移動
ネットワークの作成
これから作成するクラスタにはカスタム ネットワークが必要です。Cloud Shell で gcloud コマンドを実行して、VPC を使用したカスタム ネットワークと 1 つのサブネットワークを作成します。
ネットワークを作成します。
gcloud compute networks create wsfcnet --subnet-mode custom作成したネットワークの名前は
wsfcnetです。サブネットワークを作成します。
[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 コマンドを使用してルールを作成します。
このチュートリアルでは、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]サブネットワークでは、サーバーが相互に通信できるように、すべてのポート上ですべてのプロトコルを許可します。本番環境システムでは、必要に応じて特定のポートだけを開くことを検討してください。
gcloud compute firewall-rules create allow-all-subnet --network wsfcnet --allow all --source-ranges 10.0.0.0/16source-rangesの値がサブネットワークの作成時に使用した CIDR 範囲と一致していることに注意してください。ファイアウォール ルールを表示します。
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-addrs と wsfc-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 に接続できます。
パスワードの生成
Google Cloud コンソールで、[VM インスタンス] ページに移動します。
新しいパスワードが必要な VM インスタンスの名前をクリックします。
インスタンスの詳細ページで [Windows パスワードを設定] ボタンをクリックし、パスワードを生成します。パスワードをコピーして安全な場所に保管してください。
RDP 経由で接続する
RDP を使用して Windows VM インスタンスに接続する方法の詳細については、Compute Engine のドキュメントに記載されています。これには次の方法があります。
- 既存のクライアントを使用する。
- Chrome RDP プラグインをブラウザに追加し、Google Cloud コンソールから接続する。
このチュートリアルでは、Windows インスタンスに接続する際、好みの RDP 接続方法を使用できます。
Windows ネットワークの構成
VM の作成時に割り当てた内部 IP アドレスは静的アドレスです。Windows で IP アドレスが静的として扱われるようにするには、これらのアドレスと一緒にデフォルト ゲートウェイと DNS サーバーの IP アドレスを Windows Server のネットワーク構成に追加する必要があります。
RDP を使用して wsfc-1、wsfc-2、wsfc-dc に接続します。各インスタンスに次の操作を行います。
- サーバー マネージャーの左ペインで [ローカル サーバー] を選択します。
- [プロパティ] ペインの [イーサネット] エントリで、[IPv4 アドレス（DHCP により割り当て）、IPv6（有効）] をクリックします。
- [イーサネット] を右クリックして [プロパティ] を選択します。
- [インターネット プロトコル バージョン 4 (TCP/IPv4)] をダブルクリックします。
- [次の IP アドレスを使う] を選択します。
作成時に VM に割り当てた内部 IP アドレスを入力します。
wsfc-1の場合は「10.0.0.4」と入力します。wsfc-2の場合は「10.0.0.5」と入力します。wsfc-dcの場合は「10.0.0.6」と入力します。
[サブネット マスク] に「255.255.0.0」と入力します。
[デフォルト ゲートウェイ] で「
10.0.0.1」を入力します。これは、サブネットwsfcnetsub1の作成時にデフォルト ゲートウェイに自動的に予約された IP アドレスです。デフォルト ゲートウェイの IP アドレスは常に、サブネットのプライマリ IP 範囲の 2 番目のアドレスになります。IPv4 サブネット範囲で使用できないアドレスをご覧ください。
wsfc-1とwsfc-2のみ:[次の DNS サーバーのアドレスを使う] をクリックします。
[優先 DNS サーバー] に「10.0.0.6」と入力します。
すべてのダイアログ ボックスを閉じます。
これらの変更を適用すると VM インスタンスの仮想ネットワーク アダプタがリセットされるため、RDP 接続は失われます。
RDP セッションを閉じてから、インスタンスに再接続します。前の手順のダイアログ ボックスがまだ開いている場合は、閉じます。
ローカル サーバーのプロパティ セクションで、[イーサネット] の設定にローカル サーバーの IP アドレス（
10.0.0.4、10.0.0.5、または10.0.0.6）が反映されていることを確認します。反映されていない場合は、[インターネット プロトコル バージョン 4（TCP/IPv4）] ダイアログ ボックスを再度開き、設定を更新します。
ここで、wsfc-1 と wsfc-2 のスナップショットを作成することをおすすめします。
Active Directory の設定
次に、ドメイン コントローラをセットアップします。
- RDP を使用して、
wsfc-dcという名前のサーバーに接続します。 - Windows の「コンピューターの管理」デスクトップ アプリを使用して、ローカル管理者アカウントにパスワードを設定します。
- ローカル管理者アカウントを有効にします。
下記の Microsoft の手順に沿ってドメイン コントローラをセットアップします。この作業に関する追加の注意事項を次に示します。ほとんどの設定でデフォルト値を使用できます。
- [DNS サーバー] の役割チェックボックスをオンにします。これは Microsoft の手順に示されていません。
- [必要に応じて対象サーバーを自動的に再起動する] チェックボックスをオンにします。
- ファイル サーバーをドメイン コントローラに昇格させます。
- [新しいフォレストを追加する] のステップで、ドメインに「WSFC.TEST」という名前を付けます。
- NetBIOS ドメイン名を「WSFC」（デフォルト）に設定します。
ここで wsfc-dc のスナップショットを作成することをおすすめします。
ドメイン ユーザー アカウントを作成する
wsfc-dc が再起動するまで少し時間がかかることがあります。サーバーをドメインに参加させる前に、RDP を使用して wsfc-dc にログインし、ドメイン コントローラが実行されていることを確認します。
クラスタ サーバーの管理者権限を持つドメイン ユーザーが必要です。手順は次のとおりです。
- ドメイン コントローラ（
wsfc-dc）で [スタート] をクリックし、「dsa」と入力して Active Directory ユーザーとコンピュータ アプリを検索して開きます。 - [WSFC.TEST] を右クリックし、[新規作成] をポイントして [ユーザー] をクリックします。
- [フルネーム] と [ユーザー ログオン名] に「
cluster-admin」と入力します。 - [次へ] をクリックします。
- ユーザーのパスワードを入力して確認します。ダイアログ ボックスでパスワード オプションを選択します。たとえば、パスワードが期限切れにならないように設定できます。
- 設定を確認し、[完了] をクリックします。
cluster-adminをwsfc-dcの管理者に設定します。cluster-adminを右クリックして [グループに追加] をクリックします。- 「Administrators」と入力して、[OK] をクリックします。
このチュートリアルでは、管理者アカウントが必要な場合、WSFC.TEST\cluster-admin アカウントを管理者アカウントとして使用します。本番環境システムでは、アカウントと権限の割り当てに関してお客様が通常使用しているセキュリティ対策に従ってください。詳しくは、フェイルオーバー クラスタに必要な Active Directory アカウントの概要をご覧ください。
サーバーをドメインに参加させる
2 つのクラスタノード サーバーを WSFC.TEST ドメインに追加します。各クラスタノード サーバー（wsfc-1 と wsfc-2）で次の手順を実行します。
- [サーバー マネージャー] > [ローカル サーバー] の [プロパティ] ペインで [ワークグループ] をクリックします。
- [変更] をクリックします。
- [ドメイン] を選択し、「WSFC.TEST」と入力します。
- [OK] をクリックします。
- ドメインに参加するために
WSFC.TEST\cluster-adminの認証情報を入力します。 - [OK] をクリックします。
- ダイアログ ボックスを閉じ、プロンプトに従ってサーバーを再起動します。
[サーバー マネージャー] で、
cluster-adminをwsfc-1とwsfc-2の管理者に設定します。グループ ポリシーを使用して管理者権限を管理することもできます。- [ツール] メニューで、[コンピューターの管理] > [ローカル ユーザーとグループ] > [グループ] > [管理者] の順に選択し、[追加] をクリックします。
- 「cluster-admin」と入力し、[名前の確認] をクリックします。
- [OK] をクリックします。
ここで 3 つの VM すべてのスナップショットを作成することをおすすめします。
フェイルオーバー クラスタリングのセットアップ
Compute Engine のクラスタに IP アドレスを予約する
フェイルオーバー クラスタを作成するときに、IP アドレスを割り当て管理アクセス ポイントを作成します。本番環境では、別のサブネットの IP アドレスが必要になる可能性がありますが、このチュートリアルでは、作成したサブネットの IP アドレスを予約します。IP アドレスを予約することで、他の IP 割り当てとの競合を避けることができます。
ホスト VM でターミナルを開くか、Cloud Shell を開きます。
IP アドレスを予約します。このチュートリアルでは、
10.0.0.8を使用します。gcloud compute addresses create cluster-access-point --region [YOUR_REGION] --subnet wsfcnetsub1 --addresses 10.0.0.8
次のコマンドで IP アドレスの予約を確認します。
gcloud compute addresses list
クラスタを作成する
フェイルオーバー クラスタを作成して構成するには:
- RDP を使用して、
wsfc-1とwsfc-2に接続します。 下記の Microsoft の手順で進めます。この作業に関する追加の注意事項を次に示します。
wsfc-1とwsfc-2にフェイルオーバー クラスタリング機能をインストールします。wsfc-dcにはフェイルオーバー クラスタリング機能をインストールしないでください。- フェイルオーバー クラスタ マネージャー アプリをドメイン ユーザー
WSFC.TEST\cluster-adminとして実行します。そうしないと、権限の問題が発生する可能性があります。必要な権限を確保するため、この方法で常にフェイルオーバー クラスタ マネージャーを実行するか、cluster-adminとしてサーバーに接続することをおすすめします。 wsfc-1とwsfc-2をノードとしてクラスタに追加します。構成を検証するとき:
- [テスト オプション] ページで [選択するテストのみを実行する] を選択し、[次へ] をクリックします。
[テストの選択] ページで [ストレージ] の選択を解除します。[ストレージ] オプションは、Compute Engine で実行すると失敗します（これは独立したスタンドアロンの物理サーバー用オプションです）。
クラスタの検証中によく発生する問題を以下に示します。
- レプリカの間にネットワーク インターフェースが 1 つしかない。これはクラウドベースのセットアップでは適用されないため、無視してかまいません。
- 両方のレプリカで Windows Update が同じでない。Windows インスタンスで更新プログラムを自動的に適用するよう構成している場合、一方のノードで、他方のノードがまだダウンロードしていない更新プログラムがすでに適用されている可能性があります。サーバーの構成を同一に保つ必要があります。
- 再起動が保留中。一方のサーバーに変更を加えた場合は、その変更を適用するために再起動する必要があります。これを無視しないでください。
- ドメインの役割がサーバー間で完全に一致していない。これは無視してかまいません。
- サーバーがすべて同じ組織部門（OU）に属していない。このチュートリアルでは OU をまったく使用しませんが、本番環境システムではクラスタを独自の OU に所属させることを検討してください。Microsoft の手順には、このベスト プラクティスが記載されています。
- 署名されていないドライバが見つかった。これは無視してかまいません。
[概要] ページで [検証されたノードを使用してクラスターを今すぐ作成する] を選択して、クラスタの作成に進むことができます。ウィザードをいったん閉じて再度開き直す必要はありません。
[クラスターの作成ウィザード] の [アクセス ポイント] ページで、次の操作を行います。
- クラスタに「testcluster」という名前を設定します。
- [アドレス] フィールドに、以前に予約した IP アドレス（
10.0.0.8）を入力します。
クラスタ管理者を追加する
クラスタの管理者としてドメイン アカウントを追加すると、Windows PowerShell などのツールからクラスタを操作できます。cluster-admin ドメイン アカウントをクラスタ管理者として追加します。
- クラスタ リソースをホストするクラスタノードでフェイルオーバー クラスタ マネージャーを開き、左ペインでクラスタを選択してから、右ペインで [プロパティ] をクリックします。
- [クラスターのアクセス許可] タブを選択します。
- [追加] をクリックして、
cluster-adminを追加します。 - [グループ名またはユーザー名] のリストで
cluster-adminを選択し、[アクセス許可] ペインで [フル コントロール] を選択します。 - [適用]、[OK] の順にクリックします。
ここでスナップショットを作成することをおすすめします。
ファイル共有監視の作成
これで 2 ノードのフェイルオーバー クラスタが作成されましたが、クラスタは投票メカニズムを使用してどちらのノードをアクティブにするかを決定します。クォーラムを達成するため、ファイル共有監視を追加できます。
このチュートリアルでは、単にドメイン コントローラ サーバーに共有フォルダを追加するだけにします。どちらかのクラスタノードが再起動すると同時にドメイン コントローラ サーバーがオフラインになった場合、残りのサーバーは単独で投票できないため、クラスタ全体の機能が停止する可能性があります。このチュートリアルは、ライブ マイグレーションや自動再起動などの GCP インフラストラクチャ機能が、共有フォルダを存続させるのに十分な信頼性を備えていることを前提としています。
より可用性の高いファイル共有監視を作成する場合は、次のオプションがあります。
- Windows Server のクラスタで記憶域スペース ダイレクトを使用して共有を提供する。この Windows Server 2016 の機能は、クォーラム監視用の高可用性の共有を提供できます。たとえば、Active Directory ドメイン コントローラ用のクラスタを作成して高可用性のドメイン サービスを提供すると同時に、ファイル共有監視も提供できます。
- SIOS Datakeeper などのデータ レプリケーション ソフトウェアと Windows Server フェイルオーバー クラスタリングを使用して、同期または非同期でレプリケーションを行います。
監視用のファイル共有を作成する手順は次のとおりです。
wsfc-dcに接続します。このサーバーでファイル共有をホストします。- エクスプローラで
Cドライブに移動します。 - タイトルバーの [新しいフォルダー] ボタンをクリックします。
- 新しいフォルダの名前を
sharesとします。 sharesフォルダをダブルクリックして開きます。- 新しいフォルダを追加し、
clusterwitness-testclusterという名前を付けます。
ファイル共有監視の共有を構成する
ファイル共有監視フォルダに対するアクセス許可を設定して、クラスタがこのフォルダを使用できるようにする必要があります。
- エクスプローラで
clusterwitness-testclusterフォルダを右クリックして [プロパティ] を選択します。 - [共有] タブで [詳細な共有] をクリックします。
- [このフォルダーを共有する] を選択します。
- [アクセス許可] をクリックし、[追加] をクリックします。
- [オブジェクトの種類] をクリックし、[コンピューター] を選択して [OK] をクリックします。
- マシン アカウント
testcluster$を追加します。 testcluster$に フル コントロールのアクセス権を与えます。- [適用] をクリックし、すべてのダイアログ ボックスを閉じます。
ファイル共有監視をフェイルオーバー クラスタに追加する
次に、フェイルオーバー クラスタでファイル共有監視がクォーラム投票として使用されるようにします。
- クラスタ リソースをホストするコンピュータ（
wsfc-1）でフェイルオーバー クラスタ マネージャーを開きます。 - 左ペインでクラスタの名前（testcluster.WSFC.TEST）を右クリックして [その他のアクション] をポイントし、[クラスター クォーラム設定の構成] をクリックします。
- [クォーラム構成オプションの選択] パネルで、[クォーラム監視を選択する] を選択します。
- [クォーラム監視を選択する] パネルで、[ファイル共有監視を構成する] を選択します。
- [ファイル共有パス] で、共有フォルダのパス（
\\wsfc-dc\clusterwitness-testclusterなど）を入力します。 - 設定を確認し、[完了] をクリックします。
フェイルオーバー クラスタのテスト
これで Windows Server フェイルオーバー クラスタが機能するはずです。インスタンス間でクラスタ リソースを手動で移動してテストできます。まだ終わりではありませんが、これは今までに行ったすべての作業に問題がないことを確認するのに良いチェックポイントです。
wsfc-1のフェイルオーバー クラスタ マネージャーで [現在のホストサーバー] の名前を確認します。cluster-adminとして Windows PowerShell を実行します。PowerShell で次のコマンドを実行して、現在のホストサーバーを変更します。
Move-ClusterGroup -Name "Cluster Group"
現在のホストサーバーの名前が他方の VM に変更されます。
ホストサーバーが切り替わらなかった場合は、これまでの手順を振り返って見落しがないか確認します。最も一般的な問題は、ファイアウォール ルールがないためにネットワーク上のアクセスがブロックされていることです。その他の確認すべき問題については、トラブルシューティングのセクションをご覧ください。
ホストサーバーが正常に切り替わった場合は、内部ロードバランサのセットアップに進むことができます。内部ロードバランサは、クラスタの現在のホストサーバーにネットワーク トラフィックをルーティングするために必要となります。
ここでスナップショットを作成することをおすすめします。
フェイルオーバー クラスタに役割を追加する
Windows フェイルオーバー クラスタリングでは、クラスタ化されたワークロードが役割によってホストされます。ロールを使用して、アプリケーションで使用する IP アドレスをクラスタ内で指定できます。このチュートリアルでは、テスト ワークロード（Internet Information Services（IIS）ウェブサーバー）の役割を追加し、IP アドレスを割り当てます。
Compute Engine のロールに IP アドレスを予約する
Compute Engine のサブネット内での IP アドレスの競合を避けるため、この役割に IP アドレスを予約します。
ホスト VM でターミナルを開くか、Cloud Shell を開きます。
IP アドレスを予約します。このチュートリアルでは、
10.0.0.9を使用します。gcloud compute addresses create load-balancer-ip --region [YOUR_REGION] --subnet wsfcnetsub1 --addresses 10.0.0.9
次のコマンドで IP アドレスの予約を確認します。
gcloud compute addresses list
ロールを追加する
手順は次のとおりです。
- フェイルオーバー クラスタ マネージャーの [アクション] ペインで [役割の構成] を選択します。
- [役割の選択] ページで [その他のサーバー] を選択します。
- [クライアント アクセス ポイント] ページで
IISを入力します。 - アドレスを
10.0.0.9に設定します。 - [記憶域の選択] と [リソースタイプの選択] はスキップします。
- 設定を確認し、[完了] をクリックします。
内部ロードバランサの作成
ネットワーク トラフィックがアクティブなクラスタ ホストノードにルーティングされるように、内部ロードバランサを作成して構成します。内部ロード バランシングの構成手順はユーザー インターフェースの方がわかりやすいため、この作業にはGoogle Cloud コンソールを使用します。
また、クラスタの各ゾーンに Compute Engine インスタンス グループを作成します。ロードバランサは、このグループを使用してクラスタノードを管理します。
インスタンス グループを作成する
クラスタノードを含む各ゾーンにインスタンス グループを作成し、ノードをそのゾーンのインスタンス グループに追加します。ドメイン コントローラ wsfc-dc はインスタンス グループに追加しません。
クラスタ内の各ゾーンにインスタンス グループを作成します。
[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]
各ゾーンのサーバーをそのゾーンのインスタンス グループに追加します。
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]
インスタンス グループが作成され、各グループに 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
ロードバランサを作成する
構成を開始する
Google Cloud コンソールで、[ロード バランシング] ページに移動します。
- [ロードバランサを作成] をクリックします。
- [ロードバランサの種類] で [ネットワーク ロードバランサ（TCP / UDP / SSL）] を選択し、[次へ] をクリックします。
- [プロキシまたはパススルー] で [パススルー ロードバランサ] を選択し、[次へ] をクリックします。
- [インターネット接続または内部] で [内部] を選択し、[次へ] をクリックします。
- [構成] をクリックします。
基本的な構成
- [名前] に「wsfc-lb」と入力します。
- 現在のリージョンを選択します。
- ネットワークの
wsfcnetを選択します。
バックエンドを構成する
GCP の内部ロードバランサは定期的なヘルスチェックを使用してアクティブ ノードを決定することを思い出してください。ヘルスチェックは、アクティブ クラスタノードで実行されている Compute Engine クラスタホスト エージェントに ping します。ヘルスチェックのペイロードは、クラスタ化された役割によって表されるアプリケーションの IP アドレスです。エージェントは、ノードがアクティブな場合は 1、アクティブでない場合は 0 のレスポンスを返します。
- [バックエンドの構成] をクリックします。
- [バックエンド] で、作成したインスタンス グループの名前を選択して [完了] をクリックし、インスタンス グループを追加します。
ヘルスチェックを作成します。
- [名前] に「wsfc-hc」と入力します。
- [プロトコル] の設定はデフォルトの [TCP] のままとし、[ポート] は「59998」に変更します。これはクラスタホスト エージェントからのレスポンス用のポートです。
- [リクエスト] に「10.0.0.9」と入力します。
- [レスポンス] に「1」と入力します。
- [チェック間隔] に「2」と入力します。
- [タイムアウト] に「1」と入力します。
- [保存して次へ] をクリックします。
フロントエンドを構成する
フロントエンド構成では、ロードバランサが着信リクエストをどのように処理するかを定義する転送ルールを作成します。このチュートリアルでは、シンプルにするため、サブネットワーク内の VM 間でリクエストを発行することによってシステムをテストします。
本番環境システムでは、おそらくインターネット トラフィックなどの外部トラフィックにまでシステムを開放する必要があります。そのためには、外部トラフィックを受け入れて内部ネットワークに転送する踏み台インスタンスを作成します。このチュートリアルでは、踏み台インスタンスの使用については説明しません。
- 中央ペインで [フロントエンドの設定] をクリックします。
- [名前] に「wsfc-lb-fe」と入力します。
- サブネットワーク（
wsfcnetsub1）を選択します。 - [内部 IP] で load-balancer-ip（10.0.0.9）を選択します。これは、ロールに設定した IP アドレスと同じです。
- [ポート] に「80」と入力します。
- [完了] をクリックします。
確認と完了
- 内部ロードバランサの設定の要約を表示するため、中央ペインで [確認と完了] をクリックします。右ペインに要約が表示されます。
[作成] をクリックします。ロードバランサの作成には少し時間がかかります。
ヘルスチェック用のファイアウォール ルールを作成する
ヘルスチェックがターゲットに到達できるようにファイアウォール ルールを作成する必要があることを知らせるメッセージが Google Cloud コンソールに表示されます。このセクションではファイアウォール ルールをセットアップします。
Google Cloud コンソールで、Cloud Shell に移動します。
次のコマンドを実行して、ファイアウォール ルールを作成します。
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-1 と wsfc-2 にファイアウォール ルールを作成します。
[セキュリティが強化された Windows ファイアウォール] アプリを開きます。
左側のナビゲーション パネルで、[受信の規則] を選択します。
右側のナビゲーション パネルで [新しい規則] を選択します。
[ルールの種類] パネルで、規則の種類に [カスタム] を選択して、[次へ] をクリックします。
[プログラム] パネルでデフォルトの値を受け入れ、[次へ] をクリックします。
[プロトコルおよびポート] パネルで次の操作を行います。
- [プロトコルの種類:] フィールドで TCP を選択します。
- [ローカル ポート:] フィールドで、[特定のポート] を選択して
59998を入力します。
[スコープ] パネルの [このルールを適用するリモート IP アドレスを選択してください] で次の操作を行います。
- [これらの IP アドレス:] を選択します。
[追加] をクリックして、次の IP アドレスを [この IP アドレスまたはサブネット] フィールドに追加します。
130.211.0.0/2235.191.0.0/16
[次へ] をクリックします。
[操作] パネルで、[接続を許可する] を承諾し、[次へ] をクリックします。
[プロファイル] パネルでデフォルト値を承諾し、[次へ] をクリックします。
ファイアウォール ルールの名前を指定して、[完了] をクリックします。
ロードバランサの検証
内部ロードバランサを実行した後、そのステータスを調べて内部ロードバランサが正常なインスタンスを検出できることを確認し、フェイルオーバーを再度テストできます。
Google Cloud コンソールで、[ロード バランシング] ページに移動します。
ロードバランサの名前（
wsfc-lb）をクリックします。サマリーの [バックエンド] セクションにインスタンス グループが表示されていることを確認します。
次の図は、
wsfc-lbロードバランサの詳細ページで、インスタンス グループwsfc-group-1にアクティブ ノードがあり、[正常] 列に 1 / 1 が表示されています。インスタンス グループwsfc-group-2にはアクティブでないノードが存在し、0 / 1 と表示されています。
両方のインスタンス グループに 0 / 1 が表示されている場合、ロードバランサでノードの同期が完了していない可能性があります。場合によっては、ロードバランサに IP アドレスを検出させるために少なくとも 1 回フェイルオーバー アクションを実行しなければならないことがあります。
フェイルオーバー クラスタ マネージャーで、クラスタ名を展開し、[役割] をクリックします。[所有者ノード] 列で、IIS 役割のサーバー名をメモします。
フェイルオーバーを開始するには、IIS 役割を右クリックして、[移動] > [最適なノード] の順に選択します。これにより、役割が別のノードに移動します。これは [所有者ノード] フィールドに示されます。
![フェイルオーバー クラスタ マネージャーの [所有者ノード] フィールド。](https://cloud.google.com/static/compute/docs/tutorials/images/failover-clustering-owner-node-field.png?authuser=0000&hl=ja)
ステータスが [実行中] になるまで待ちます。
[ロードバランサの詳細] ページに戻り、[更新] をクリックします。インスタンス グループの間で [正常] 列の 1 / 1 と 0 / 1 の値が入れ替わっていることを確認します。
gcloud compute backend-services get-health wsfc-lb --region=[REGION]
出力は次のようになります。
backend: https://compute.googleapis.com/compute/v1/projects/exampleproject/zones/us-central1-a/instanceGroups/wsfc-group-1
status:
healthStatus:
- healthState: HEALTHY
instance: https://compute.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://compute.googleapis.com/compute/v1/projects/exampleproject/zones/us-central1-b/instanceGroups/wsfc-group-2
status:
healthStatus:
- healthState: UNHEALTHY
instance: https://compute.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 をセットアップする
各クラスタノードに IIS をインストールします。
- [役割サービスの選択] ページを開き、[共通の HTTP 機能] で [既定のドキュメント] が選択されていることを確認してください。
- [確認] ページで、対象サーバーを自動的に再起動するチェックボックスをオンにします。
各ウェブサーバーが動作していることを確認します。
- RDP を使用して、
wsfc-dcという名前の VM に接続します。 - [サーバー マネージャー] で、ウィンドウの左側にあるナビゲーション パネルの [ローカル サーバー] をクリックします。
- 上部にある [プロパティ] セクションで、[IE セキュリティ強化の構成] をオフにします。
- Internet Explorer を開きます。
アドレス欄に各サーバーの IP アドレスを入力してウェブサーバーにアクセスします。
http://10.0.0.4/
http://10.0.0.5/
- RDP を使用して、
それぞれのケースで [ようこそ] ページが表示されます。これは IIS のデフォルトのウェブページです。
デフォルトのウェブページを編集する
それぞれのデフォルト ウェブページを変更して、現在どちらのサーバーがページを提供しているか簡単にわかるようにします。
- RDP を使用して、
wsfc-1という名前の VM に接続します。 - 管理者としてメモ帳を起動します。
- メモ帳で
C:\inetpub\wwwroot\iisstart.htmを開きます。ファイルを開く際のダイアログ ボックスで、テキスト ファイルだけでなく [すべてのファイル] が表示されるようにしてください。 <title>要素のテキストを現在のサーバーの名前に変更します。例:<title>wsfc-1</title>HTML ファイルを保存します。
<title>要素をwsfc-2に設定して、これらの手順をwsfc-2に繰り返します。
これで、どちらかのサーバーから提供されたウェブページを表示すると、サーバーの名前が Internet Explorer タブのタイトルとして表示されるようになりました。
フェイルオーバーをテストする
- RDP を使用して、
wsfc-dcという名前の VM に接続します。 - Internet Explorer を開きます。
ロードバランサの役割の IP アドレスにアクセスします。
http://10.0.0.9/[ようこそ] ページが開き、現在のサーバーの名前がタブのタイトルに表示されます。
現在のサーバーを停止して障害をシミュレートします。Cloud Shell で、次のコマンドを実行します。
[INSTANCE_NAME]は、前の手順で確認した現行サーバーの名前で置き換えます（例:wsfc-1など）。gcloud compute instances stop [INSTANCE_NAME] --zone=[ACTIVE_ZONE]wsfc-dcとの RDP 接続に切り替えてください。ロードバランサが移動を検出してトラフィックを再ルーティングするまで少し時間がかかることがあります。
30 秒ほどたったら、Internet Explorer でページを更新します。
これで、タブのタイトルに新しいアクティブ ノードの名前が表示されます。たとえば、
wsfc-1がアクティブな状態で手順を開始した場合、タイトルの表示はwsfc-2になります。すぐに変更が表示されない場合や、ページが見つかりませんというエラーが表示された場合は、ブラウザを再度更新してください。
以上でチュートリアルは終了です。これで Windows Server 2016 フェイルオーバー クラスタが GCP 上で正常に機能します。
トラブルシューティング
以下によくある問題を示します。手順がうまくいかない場合はこれらを確認してください。
GCP ファイアウォール ルールによってヘルスチェックがブロックされている
ヘルスチェックが機能しない場合は、ヘルスチェック システムで使用されている IP アドレス（130.211.0.0/22 と 35.191.0.0/16）からの受信トラフィックを許可するファイアウォール ルールがあることを再確認します。
Windows ファイアウォールによってヘルスチェックがブロックされている
各クラスタノードの Windows ファイアウォールでポート 59998 が開いていることを確認します。Windows ファイアウォールを開くをご覧ください。
クラスタノードが DHCP を使用している
クラスタ内の各 VM に静的 IP アドレスが設定されていることが重要です。VM 上の Windows が DHCP を使用するように構成されている場合は、Windows のネットワーク設定を変更して、その IPv4 アドレスを Google Cloud コンソールに表示される VM の IP アドレスと一致させます。さらに、ゲートウェイの IP アドレスを GCP VPC 内のサブネットワーク ゲートウェイのアドレスと一致させます。
ファイアウォール ルールの GCP ネットワーク タグ
ファイアウォール ルールでネットワーク タグを使用する場合は、すべての VM インスタンスで正しいタグが設定されていることを確認してください。このチュートリアルではタグは使用しませんが、なんらかの理由でタグを設定した場合は、一貫して使用する必要があります。
クリーンアップ
このチュートリアルで使用したリソースについて、Google Cloud アカウントに課金されないようにするには、リソースを含むプロジェクトを削除するか、プロジェクトを維持して個々のリソースを削除します。
チュートリアルが終了したら、作成したリソースをクリーンアップして、割り当ての使用を停止し、課金されないようにできます。次のセクションで、リソースを削除または無効にする方法を説明します。
プロジェクトの削除
課金されないようにする最も簡単な方法は、チュートリアル用に作成したプロジェクトを削除することです。
プロジェクトを削除するには:
- In the Google Cloud console, go to the Manage resources page.
- In the project list, select the project that you want to delete, and then click Delete.
- In the dialog, type the project ID, and then click Shut down to delete the project.
プロジェクトを削除せずにリソースをクリーンアップする
プロジェクトを残す必要がある場合は、チュートリアルのリソースを個別に削除し、クリーンアップできます。
インスタンスを削除する
Compute Engine インスタンスを削除するには:
- In the Google Cloud console, go to the VM instances page.
- Select the checkbox for the instance that you want to delete.
- To delete the instance, click More actions, click Delete, and then follow the instructions.
インスタンス グループの削除
- In the Google Cloud console, go to the Instance groups page.
- Select the checkbox for the instance group that you want to delete.
- To delete the instance group, click Delete.
ロードバランサを削除する
ロードバランサを削除するには:
Google Cloud コンソールで、[ロード バランシング] ページに移動します。
削除するロードバランサの名前の隣にあるチェックボックスをオンにします。
ページ上部にある [削除] ボタンをクリックします。
VPC ネットワークを削除する
VPC ネットワークを削除するには:
Google Cloud コンソールで、[VPC ネットワーク] ページに移動します。
削除するネットワークの名前をクリックします。
ページの上部にある [VPC ネットワークを削除] ボタンをクリックします。
予約済みの IP アドレスを解放する
Cloud Shell を使用して予約済みの IP アドレスを解放するには:
Google Cloud コンソールで、Cloud Shell に移動します。
予約済みの IP アドレスを解放します。
gcloud compute addresses delete cluster-access-point load-balancer-ip
永続ディスクを削除する
永続ディスクを削除する手順は次のとおりです。
Google Cloud コンソールで、[ディスク] ページに移動します。
削除するディスクの名前の横にあるチェックボックスをオンにします。
ページ上部にある [削除] ボタンをクリックします。
次のステップ
- Active Directory に関するチュートリアルを読む。
- Google Cloud に関するリファレンス アーキテクチャ、図、ベスト プラクティスを確認する。Cloud アーキテクチャ センターをご覧ください。