1. はじめに¶
1.1. 対象読者と目的¶
1.2. 適用範囲¶
動作環境については 「スタートアップガイド」-「CLUSTERPRO の動作環境」を参照してください。
本書に記載した各製品・サービスのスクリーンショット等は執筆時点のものであり、それ以降に変更されている可能性があります。最新の情報はそれぞれのWebサイトやマニュアルを参照してください。
1.3. 本書の構成¶
「4. 構築手順(内部 TCP ロードバランサを使用したHAクラスターの場合)」:内部 TCP ロードバランサを使用したHAクラスターの構築手順について説明します。
「5. 構築手順(Cloud DNSを使用したHAクラスターの場合) 」:Cloud DNS を使用したHAクラスターの構築手順について説明します。
「6. エラーメッセージ一覧」:エラーメッセージと対処について説明します。
1.4. CLUSTERPRO マニュアル体系¶
CLUSTERPRO のマニュアルは、以下の 5 つに分類されます。各ガイドのタイトルと役割を以下に示します。
『CLUSTERPRO X スタートアップガイド』 (Getting Started Guide)
すべてのユーザを対象読者とし、製品概要、動作環境、アップデート情報、既知の問題などについて記載します。
『CLUSTERPRO X インストール&設定ガイド』 (Install and Configuration Guide)
CLUSTERPRO を使用したクラスタシステムの導入を行うシステムエンジニアと、クラスタシステム導入後の保守・運用を行うシステム管理者を対象読者とし、CLUSTERPRO を使用したクラスタシステム導入から運用開始前までに必須の事項について説明します。実際にクラスタシステムを導入する際の順番に則して、CLUSTERPRO を使用したクラスタシステムの設計方法、CLUSTERPRO のインストールと設定手順、設定後の確認、運用開始前の評価方法について説明します。
『CLUSTERPRO X リファレンスガイド』 (Reference Guide)
管理者、および CLUSTERPRO を使用したクラスタシステムの導入を行うシステムエンジニアを対象とし、CLUSTERPRO の運用手順、各モジュールの機能説明およびトラブルシューティング情報等を記載します。『CLUSTERPRO X インストール&設定ガイド』を補完する役割を持ちます。
『CLUSTERPRO X メンテナンスガイド』 (Maintenance Guide)
管理者、および CLUSTERPRO を使用したクラスタシステム導入後の保守・運用を行うシステム管理者を対象読者とし、CLUSTERPRO のメンテナンス関連情報を記載します。
『CLUSTERPRO X ハードウェア連携ガイド』 (Hardware Feature Guide)
管理者、および CLUSTERPRO を使用したクラスタシステムの導入を行うシステムエンジニアを対象読者とし、特定ハードウェアと連携する機能について記載します。『CLUSTERPRO X インストール&設定ガイド』を補完する役割を持ちます。
1.5. 本書の表記規則¶
本書では、注意すべき事項、重要な事項および関連情報を以下のように表記します。
注釈
この表記は、重要ではあるがデータ損失やシステムおよび機器の損傷には関連しない情報を表します。
重要
この表記は、データ損失やシステムおよび機器の損傷を回避するために必要な情報を表します。
参考
この表記は、参照先の情報の場所を表します。
また、本書では以下の表記法を使用します。
表記 |
使用方法 |
例 |
---|---|---|
[ ] 角かっこ |
コマンド名の前後
画面に表示される語 (ダイアログボックス、メニューなど) の前後
|
[スタート] をクリックします。
[プロパティ] ダイアログ ボックス
|
コマンドライン中の [ ] 角かっこ |
かっこ内の値の指定が省略可能であることを示します。 |
|
# |
Linux ユーザが、root でログインしていることを示すプロンプト |
|
モノスペースフォント |
パス名、コマンド ライン、システムからの出力 (メッセージ、プロンプトなど)、ディレクトリ、ファイル名、関数、パラメータ |
|
太字 |
ユーザが実際にコマンドラインから入力する値を示します。 |
以下を入力します。
# clpcl -s -a
|
|
ユーザが有効な値に置き換えて入力する項目 |
|
本書の図では、CLUSTERPROを表すために このアイコンを使用します。
2. 概要¶
2.1. 機能概要¶
リージョン
GCP ではリージョンと呼ばれる物理的および論理的な単位に分割されます(たとえば東京、大阪など)。1つのリージョン内にすべてのノードを構築することも可能ですが、ネットワーク障害や自然災害などによりすべてのノードがダウンし業務を継続できなくなるおそれがあります。そこで、ノードを複数のリージョンに分散させて配置することにより、可用性を高めることができます。リージョンはゾーンの集まりです。ゾーン
GCP では、ゾーンと呼ばれる論理的なグループに各ノードを配置できます。異なるゾーンに各ノードを配置することで、GCP の計画済みメンテナンスや物理ハードウェアの障害などの計画外メンテナンスによる影響を最小限に抑えることが可能です。
2.2. 基本構成¶
用途 |
選択する CLUSTERPRO のリソース |
必要な GCP のサービス |
---|---|---|
仮想 IP アドレスでクライアントからアクセスしたい場合 |
Google Cloud 仮想 IP リソース |
内部 TCP 負荷分散 |
DNS 名でクライアントからアクセスしたい場合 |
EXEC リソース(本書添付の Cloud DNS 対応スクリプトを使用) |
Cloud DNS |
ロードバランサを使用したHAクラスター
クライアントアプリケーションは、GCP 環境の仮想マシンに対して、仮想 IP アドレス(以下、VIP と記載)を使用してクラスターを構成するノードに接続することができます。 VIP アドレスを使用することにより、フェイルオーバーまたは、グループの移動が発生しても、クライアントは、仮想マシンの切り替えを意識する必要がありません。図 2.1 内部 TCP ロードバランサを使用したHAクラスター の GCP 環境上に構築したクラスタには、GCP のロードバランサ(Cloud Load Balancing)の VIP (Cloud Load BalancingのフロントエンドIP)を指定してアクセスします。クラスタの現用系と待機系は、GCP のロードバランサにおけるヘルスチェックを利用して切り替えます。 ヘルスチェックには Google Cloud 仮想 IP リソースが提供するポートを利用します。![]()
図 2.1 内部 TCP ロードバランサを使用したHAクラスター¶
SubNetwork-1
10.0.1.0/24
IP Address (Client)
10.0.1.200
Virtual IP Address (VIP)
10.0.1.100
SubNetwork-11
10.0.11.0/24
IP Address (Server1)
10.0.11.101
IP Address (Server2)
10.0.11.102
Health Check Port
12345
Cloud Load Balancing については以下を参照してください。Cloud Load Balancing:ロードバランサを使用したHAクラスターの構成例としては以下があります。
用途
使用するロードバランサ
構築手順
業務を GCP のネットワークの内部に公開する場合
内部 TCP ロードバランサ
ロードバランサを使用したHAクラスター構成において必要なリソース、モニタリソースは以下のとおりです。本書ではネットワークパーティション解決リソースを設定していませんが、「2.3. ネットワークパーティション解決」を参照し、お客様のシステム構成により決定してください。
リソース/モニタリソース種別
説明
設定
Google Cloud 仮想 IP リソース
業務が稼働するノードの特定のポートでロードバランサからの死活監視(ヘルスチェック用のポートへのアクセス)を待ち受ける仕組みを提供します。活性時にGCPのロードバランサからの死活監視を待ち受けるための制御プロセスを起動します。非活性時には死活監視を待ち受けるための制御プロセスを停止します。必須
Google Cloud 仮想 IP モニタリソース
Google Cloud 仮想 IP リソースが起動しているノードに対して、Google Cloud 仮想 IP リソース活性時に起動する制御プロセスの死活監視を行います。
必須
Google Cloud ロードバランスモニタリソース
Google Cloud 仮想 IP リソースが起動していないノードに対して、ヘルスチェック用ポートと同じポート番号が開放されていないかを監視します。
必須
その他のリソース、モニタリソース
ミラーディスクなど、HAクラスターで運用するアプリケーションの構成に従います。
任意
Cloud DNSを使用したHAクラスター
本構成では、DNS 名でアクセス可能とするために Cloud DNS を使用しています。また、GCP プラットフォームの計画済みメンテナンスや物理ハードウェアの障害などの計画外メンテナンスによる影響を最小限に抑えるために、2台の仮想マシンで異なるゾーンに配置しています。図 2.2 Cloud DNS を使用したHAクラスター のクラスターには、DNS 名を指定してアクセスします。CLUSTERPRO は、DNS 名から設定した IP アドレスが得られるように Cloud DNS のレコードセット(A レコード)の制御を行います。フェイルオーバーまたはグループの移動が発生しても、クライアントは仮想マシンの切り替えを意識する必要がありません。![]()
図 2.2 Cloud DNSを使用したHAクラスター¶
SubNetwork-1
10.0.1.0/24
IP Address (Client)
10.0.1.200
SubNetwork-11
10.0.11.0/24
IP Address (Server1)
10.0.11.101
IP Address (Server2)
10.0.11.102
Virtual host name
test-cluster.example.com
レコード書き換え前(Cloud DNS)
Name
Type
Data
test-cluster.example.com
A
10.0.11.101
レコード書き換え後(Cloud DNS)
Name
Type
Data
test-cluster.example.com
A
10.0.11.102
本書ではVPCネットワーク内のHAクラスターを構成するインスタンスがインターネットへアクセスできる構成について記載しています。これは、HAクラスターを構成するインスタンスが Cloud DNS 対応スクリプトが利用する gcloud CLI を実行する際に、インターネットへアクセスする必要があるためです。インターネットへのアクセスには、NATゲートウェイやNATインスタンスを使用する方法があります。本書ではNATゲートウェイ(Cloud NAT)を使用します。VPC ネットワークの作成手順やNATゲートウェイ/NATインスタンスの設定、ファイアウォールルールの設定の詳細は、GCP のドキュメントをご参照ください。Cloud DNS を使用したHAクラスター構成において必要なリソース、モニタリソースは以下のとおりです。本書ではネットワークパーティション解決リソースを設定していませんが、「ネットワークパーティション解決」を参照し、お客様のシステム構成により決定してください。
リソース/モニタリソース種別
説明
設定
EXEC リソース
DNS名 から設定した IP アドレスを得られるように Cloud DNS のレコードセット(A レコード)の制御を行います。
必須
その他のリソース、モニタリソース
ミラーディスクなど、HAクラスターで運用するアプリケーションの構成に従います。
任意
2.3. ネットワークパーティション解決¶
HAクラスターを構成している仮想マシンは、お互いにハートビートによって死活監視を行っています。各仮想マシンが異なるサブネットに分散している構成においては、ハートビートが途絶えた時に、サービスの二重起動など望ましくない状態が発生します。サービスの二重起動を回避するために、他の仮想マシンがダウンしたか、自身がネットワークから孤立した状態(ネットワークパーティション状態。以下、NP状態と記す)かのどちらであるかを区別する必要があります。ネットワークパーティション解決(以下、NP解決と記す)は、Pingなどの応答を返却可能な常時稼働している装置(応答確認先)に対してPing確認を行い、応答がない場合はNP状態が発生したと判断し、設定された処理(警告、回復処理、サーバダウン処理など)を行います。クラスタシステムにアクセスするクライアントの配置やオンプレミス環境との接続条件(専用線接続など)によって、NP解決先やNP解決の方法はその都度検討する必要があります。推奨のNP解決先やNP解決の方法はありません。NP解決については、以下を参照してください。
『リファレンスガイド』 - 「ハートビートリソースの詳細」
3. 動作環境¶
3.1. Cloud DNSを使用したHAクラスターの場合¶
以下の構成で動作確認済みです。
x86_64
OS
Red Hat Enterprise Linux 7.6
CLUSTERPRO
CLUSTERPRO X 4.2 for Linux(内部バージョン 4.2.0-1)CLUSTERPRO X Replicator 4.2 for Linuxリージョン
asia-northeast1(東京)
ミラーディスクサイズ
ディスクサイズ:20GB (クラスタパーティション:1GB、データパーティション:19GB)
Cloud SDK(gcloud CLI)
245.0.0
Cloud DNS 対応スクリプトは、Cloud DNS のサービスを利用しています。Cloud DNS については、以下を参照してください。Cloud DNS:Cloud DNS 対応スクリプトは、Cloud SDK の一部である gcloud CLI を利用し、Cloud DNS に対する操作をしています。Cloud SDK については、以下を参照してください。Google Cloud SDK のドキュメント:
4. 構築手順(内部 TCP ロードバランサを使用したHAクラスターの場合)¶
4.1. 構築例について¶
本書では、GCP において、CLUSTERPRO を使用した2ノードでの片方向スタンバイクラスタの構築手順を紹介します。GCP 上の同じ VPC ネットワーク内のクライアントからアクセス可能な HAクラスターを構築します。本手順は、server1 を現用系サーバとしたミラーディスク型の構成を対象としています。以下の表は既定値が存在しないパラメータ、および既定値から変更したパラメータについて記載しています。ファイアウォールルールの[IP範囲]は、GCP ヘルスチェックシステム(130.211.0.0/22, 35.191.0.0/16)からの通信を許可するために必要です。
GCPの設定(server1、server2で共通の設定)
設定項目
設定値
VPCネットワークの設定
名前
test-vpc
新しいサブネット 名前
subnetwork-1, subnetwork-11
新しいサブネット リージョン
asia-northeast1
新しいサブネット IPアドレス範囲
10.0.1.0/24, 10.0.11.0/24
ファイアウォールルールの設定
名前
test-allow-health-check
ネットワーク
test-vpc
トラフィックの方向
上り
一致したときのアクション
許可
ターゲット
指定されたターゲットタグ
ターゲットタグ
test-allow-health-check
ソースフィルタ
IP範囲
ソースIPの範囲
130.211.0.0/22, 35.191.0.0/16
指定したプロトコルとポート
すべて許可
ロードバランサの設定
種類
TCP 負荷分散
インターネット接続または内部専用
VM間のみ
マルチリージョンまたはシングルリージョン
シングルリージョンのみ
名前
test-lb
ロードバランサの設定(バックエンドの設定)
リージョン
asia-northeast1
ネットワーク
test-vpc
インスタンスグループ
test-ig-a, test-ig-b
ヘルスチェック 名前
test-health-check
ヘルスチェック プロトコル
TCP
ヘルスチェック ポート
12345
ヘルスチェック プロキシのプロトコル
なし
セッションアフィニティ
なし
ロードバランサの設定(フロントエンドの設定)
名前
test-frontend
サブネットワーク
subnetwork-1
内部IP
10.0.1.100
ポート
80(業務を提供しているポート番号)
GCPの設定(server1、server2でそれぞれ設定)
設定項目
設定値
server1
server2
インスタンスの設定
リージョン
asia-northeast1
asia-northeast1
ゾーン
asia-northeast1-a
asia-northeast1-b
新しいディスク
server1-datadisk-0
server2-datadisk-0
インスタンスグループの設定
名前
test-ig-a
test-ig-b
グループタイプ
非マネージド インスタンス グループ
非マネージド インスタンス グループ
リージョン
asia-northeast1
asia-northeast1
ゾーン
asia-northeast1-a
asia-northeast1-b
ネットワーク
test-vpc
test-vpc
サブネットワーク
subnetwork-11
subnetwork-11
VMインスタンス
server1
server2
ネットワークの設定
ネットワーク
test-vpc
test-vpc
サブネットワーク
subnetwork-11
subnetwork-11
内部IPアドレス
10.0.11.101
10.0.11.102
CLUSTERPROの設定(クラスタプロパティ)
設定項目
設定値
server1
server2
クラスタ名
Cluster1
Cluster1
サーバ名
server1
server2
CLUSTERPROの設定(フェイルオーバーグループ)
リソース名
設定項目
設定値
ミラーディスクリソース
リソース名
md1
ミラーディスクリソース
詳細タブ - ミラーパーティションデバイス名
/dev/NMP1
ミラーディスクリソース
詳細タブ - マウントポイント
/mnt/md1
ミラーディスクリソース
詳細タブ - データパーティションデバイス名
/dev/sdb2
ミラーディスクリソース
詳細タブ - クラスタパーティションデバイス名
/dev/sdb1
ミラーディスクリソース
詳細タブ - ファイルシステム
ext4
Google Cloud 仮想 IP リソース
リソース名
gcvip1
Google Cloud 仮想 IP リソース
ポート番号
12345(ヘルスチェック ポートで指定した値)
CLUSTERPROの設定(モニタリソース)
モニタリソース名
設定項目
設定値
ミラーディスクモニタリソース
モニタリソース名
mdw1
ミラーディスクコネクトモニタリソース
モニタリソース名
mdnw1
Google Cloud 仮想 IP モニタリソース
モニタリソース名
gcvipw1
Google Cloud 仮想 IP モニタリソース
回復対象
gcvip1
Google Cloud ロードバランスモニタリソース
モニタリソース名
gclbw1
Google Cloud ロードバランスモニタリソース
回復対象
gcvip1
4.2. GCPの設定¶
VPCネットワークの作成
GCP Console にアクセスします(https://console.cloud.google.com/)。VPCネットワーク、サブネットを作成します。詳細な手順は以下を参照してください。VPCネットワークの使用:
インスタンスの作成
公開イメージから インスタンスを作成します。また、インスタンス作成時にミラーディスク(クラスタパーティション、データパーティション)に使用するセカンダリ ディスクを追加します。インスタンスはクラスターを構成する仮想マシン分作成します。詳細な手順は以下を参照してください。入門ガイド:
インスタンスの設定
作成した server1、server2 へ接続し、ログインします。詳細な手順は以下を参照してください。インスタンスへの接続:次にミラーディスクリソース用のパーティションを設定します。インスタンスに追加したセカンダリ ディスクにクラスタパーティションおよびデータパーティションを作成します。ミラーディスクリソース用のパーティションの設定については、以下を参照してください。
ファイアウォールルールの作成
ロードバランサからインスタンスへのヘルスチェックを行う GCP ヘルスチェックシステム(130.211.0.0/22, 35.191.0.0/16)からの通信を許可するため、ファイアウォールルールを作成します。また、ターゲットタグをインスタンス server1、server2 のネットワークタグに追加してください。詳細な手順は以下を参照してください。ファイアウォール ルールの使用:ヘルスチェックの作成:
インスタンス グループの作成
Cloud Load Balancing のバックエンドに指定するインスタンス グループを作成します。インスタンス server1、server2 を追加します。詳細な手順は以下を参照してください。非マネージド インスタンス グループの作成:
ロードバランサの作成
ロードバランサを作成します。[TCP 負荷分散]を選択します。詳細な手順は以下を参照してください。ネットワーク負荷分散の設定:次にバックエンド、フロントエンドを設定します。フロントエンドの[ポート]には業務を提供しているポート番号を設定します。詳細な手順は以下を参照してください。内部 TCP/UDP 負荷分散の設定:
OS 起動時間の調整、ネットワーク設定の確認、ルートファイルシステムの確認、ファイアウォールの設定を確認、サーバの時刻を同期、SELinuxの設定を確認
各手順は以下を参照してください。
CLUSTERPROのインストール
インストール手順は以下を参照してください。インストール完了後、OSの再起動を行ってください。- 『インストール&設定ガイド』
CLUSTERPROのライセンスを登録
ライセンス登録手順は以下を参照してください。- 『インストール&設定ガイド』
4.3. CLUSTERPROの設定¶
Cluster WebUI のセットアップ、および接続方法は以下を参照してください。
『インストール&設定ガイド』 - 「クラスタ構成情報を作成する」
以下のリソース/モニタリソースを追加する手順を記述します。
ミラーディスクリソース
Google Cloud 仮想 IP リソース
Google Cloud 仮想 IP モニタリソース
Google Cloud ロードバランスモニタリソース
上記以外の設定は以下を参照してください。
クラスタの作成
最初に、クラスタ生成ウィザードを開始し、クラスタを構築します。
クラスタの構築
Cluster WebUI にアクセスし、[クラスタ生成ウィザード] をクリックします。 クラスタ生成ウィザード]の[クラスタ]が表示されます。[クラスタ名] に任意のクラスタ名を入力します。[言語] を適切に選択します。[次へ] をクリックします。 [基本設定]が表示されます。Cluster WebUI に接続したインスタンスがマスタサーバとして登録済みの状態で表示されます。[追加] をクリックし、残りのインスタンスを追加します(インスタンスの内部IPアドレスを指定します)。[次へ] をクリックします。 [インタコネクト] 画面が表示されます。インタコネクトのために使用するIPアドレス(各インスタンスの内部IPアドレス)を指定します。また、後で作成するミラーディスクリソースの通信経路として [MDC] に mdc1 を選択します。[次へ] をクリックします。 [NP解決] 画面が表示されます。何も指定せず [次へ] をクリックします。
グループリソースの追加
グループの定義
フェイルオーバーグループを作成します。
[グループ一覧] 画面が表示されます。[追加]をクリックします。 [グループの定義] 画面が表示されます。[名前] にフェイルオーバーグループ名(failover1)を設定します。[次へ] をクリックします。 [起動可能サーバ 画面が表示されます。何も指定せず [次へ] をクリックします。 [グループ属性] 画面が表示されます。何も指定せず [次へ] をクリックします。 [グループリソース一覧] 画面が表示されます。以降の手順で、この画面でグループリソースを追加していきます。ミラーディスクリソース
[グループリソース一覧] で [追加] をクリックします。 [グループ のリソース定義 | failover1] 画面が開きます。[タイプ] ボックスでグループリソースのタイプ(ミラーディスクリソース) を選択し、[名前] ボックスにリソース名を入力します。[次へ] をクリックします。 [依存関係] 画面が表示されます。何も指定せず [次へ] をクリックします。 [復旧動作] 画面が表示されます。[次へ] をクリックします。 [詳細] 画面が表示されます。[データパーティションデバイス名] [クラスタパーティションデバイス名] に「3. インスタンスの設定」で作成したパーティションのデバイス名を入力します。[マウントポイント]、[ファイルシステム]を入力します。 [完了] をクリックして設定を終了します。Google Cloud 仮想 IP リソース
GCP 上で CLUSTERPRO を利用する場合、業務が稼働するノードの特定のポートでロードバランサからの死活監視を待ち受ける仕組みを提供します。Google Cloud 仮想 IP リソースの詳細は以下を参照してください。
[グループリソース一覧] で [追加] をクリックします。 [グループ のリソース定義 | failover1] 画面が開きます。[タイプ] ボックスでグループリソースのタイプ (Google Cloud 仮想 IP リソース) を選択して、[名前] ボックスにリソース名を入力します。[次へ] をクリックします。 [依存関係] 画面が表示されます。何も指定せず [次へ] をクリックします。 [復旧動作] 画面が表示されます。[次へ] をクリックします。 [ポート] にロードバランサの設定(バックエンドの設定)時にヘルスチェックの [ポート] として指定した値を入力します。 [完了] をクリックします。
モニタリソースの追加
Google Cloud 仮想 IP モニタリソース
Google Cloud 仮想 IP リソースが起動しているノードに対して、死活監視のためのポートの監視機構を提供します。Google Cloud 仮想 IP リソースを1つ追加すると、Google Cloud 仮想 IP モニタリソースが1つ自動的に作成されます。Google Cloud 仮想 IP モニタリソースの詳細は以下を参照してください。Google Cloud ロードバランスモニタリソース
Google Cloud 仮想 IP リソースが起動していないノードに対して、ヘルスチェック用ポートと同じポート番号が開放されていないかの監視機構を提供します。Google Cloud 仮想 IP リソースを1つ追加すると、Google Cloud ロードバランスモニタリソースが1つ自動的に作成されます。Google Cloud ロードバランスモニタリソースの詳細は以下を参照してください。
設定の反映とクラスタの起動
以下を参照してください。- 『インストール&設定ガイド』 - 「クラスタを生成するには」
4.4. 動作確認¶
フェイルオーバーグループ(failover1)が、現用系ノードのserver1で起動します。Cluster WebUI [ステータス] タブにおいてfailover1がserver1で[起動済]になっていることを確認します。クライアントから、フロントエンドのIPアドレスにアクセスし、現用系ノードに接続できることを確認します。 Cluster WebUIのプルダウンより[操作モード]から[検証モード]に変更します。 Cluster WebUI [ステータス] タブにおいて gcvipw1 の[擬似障害発生]アイコンを選択します。 Google Cloud 仮想 IP リソース(gcvip1)が3回再活性後に、フェイルオーバーグループ(failover1)が異常になり、ノードserver2へフェイルオーバーします。Cluster WebUI [ステータス]タブにおいてfailover1がserver2で [起動済] になっていることを確認します。また、ロードバランサのフロントエンドのIPアドレスに対してフェイルオーバー後も正常にアクセスできることを確認します。
以上で、擬似障害の場合におけるフェイルオーバーの動作確認は完了です。その他の障害発生時の動作確認については適宜実施してください。
5. 構築手順(Cloud DNSを使用したHAクラスターの場合)¶
5.1. 構築例について¶
本書では、GCP において、CLUSTERPRO を使用した2ノードでの片方向スタンバイクラスタの構築手順を紹介します。GCP 上の同じ VPC ネットワーク内のクライアントからアクセス可能な HAクラスターを構築します。本手順は、server1 を現用系サーバとしたミラーディスク型の構成を対象としています。以下の表は既定値が存在しないパラメータ、および既定値から変更したパラメータについて記載しています。
GCPの設定(server1、server2で共通の設定)
設定項目
設定値
VPCネットワークの設定
名前
test-vpc
新しいサブネット 名前
subnetwork-1, subnetwork-11
新しいサブネット リージョン
asia-northeast1
新しいサブネット IPアドレス範囲
10.0.1.0/24, 10.0.11.0/24
CloudDNS の設定(DNS ゾーン)
ゾーンのタイプ
非公開
ゾーン名
test-zone
DNS 名
example.com
オプション
デフォルト(限定公開)
ネットワーク
test-vpc
CloudDNS の設定(レコードセット)
DNS名
test-cluster.example.com
リソースレコードのタイプ
A
TTL
5
TTLユニット
秒
IPv4アドレス
10.0.11.101
GCPの設定(server1、server2でそれぞれ設定)
設定項目
設定値
server1
server2
インスタンスの設定
リージョン
asia-northeast1
asia-northeast1
ゾーン
asia-northeast1-a
asia-northeast1-b
新しいディスク
server1-datadisk-0
server2-datadisk-0
ネットワークの設定
ネットワーク
test-vpc
test-vpc
サブネットワーク
subnetwork-11
subnetwork-11
内部IPアドレス
10.0.11.101
10.0.11.102
CLUSTERPROの設定(クラスタプロパティ)
設定項目
設定値
server1
server2
クラスタ名
Cluster1
Cluster1
サーバ名
server1
server2
CLUSTERPROの設定(フェイルオーバーグループ)
リソース名
設定項目
設定値
ミラーディスクリソース
リソース名
md1
ミラーディスクリソース
詳細タブ - ミラーパーティションデバイス名
/dev/NMP1
ミラーディスクリソース
詳細タブ - マウントポイント
/mnt/md1
ミラーディスクリソース
詳細タブ - データパーティションデバイス名
/dev/sdc2
ミラーディスクリソース
詳細タブ - クラスタパーティションデバイス名
/dev/sdc1
ミラーディスクリソース
詳細タブ - ファイルシステム
ext4
EXEC リソース
リソース名
exec1
CLUSTERPROの設定(モニタリソース)
モニタリソース名
設定項目
設定値
ミラーディスクモニタリソース
モニタリソース名
mdw1
ミラーディスクコネクトモニタリソース
モニタリソース名
mdnw1
5.2. GCPの設定¶
VPCネットワークの作成
GCP Console にアクセスします(https://console.cloud.google.com/)。VPCネットワーク、サブネットを作成します。詳細な手順は以下を参照してください。VPCネットワークの使用:
インスタンスの作成
公開イメージから インスタンスを作成します。また、インスタンス作成時にミラーディスク(クラスタパーティション、データパーティション)に使用するセカンダリ ディスクを追加します。インスタンスはクラスターを構成する仮想マシン分作成します。詳細な手順は以下を参照してください。入門ガイド:
インスタンスの設定
作成した server1、server2 へ接続し、ログインします。詳細な手順は以下を参照してください。インスタンスへの接続:次にミラーディスクリソース用のパーティションを設定します。インスタンスに追加したセカンダリ ディスクにクラスタパーティションおよびデータパーティションを作成します。ミラーディスクリソース用のパーティションの設定については、以下を参照してください。
DNS ゾーンの作成
gcloud CLI の設定
server1、server2 へログインし、gcloud CLI をインストールおよび SDK の初期化をします。既にインストールされている場合は、再インストールは不要です。gcloud CLI を使用する前に、root ユーザで Cloud SDK ツールの承認を済ませておく必要があります。Cloud SDK ツールの承認方法については以下を参照してください。Cloud SDK ツールの承認:その他の詳細な手順は以下を参照してください。Google Cloud SDK のインストール:Cloud SDK の初期化:クイックスタート:Cloud IAM の設定
Cloud SDK ツールの承認時に使用したユーザアカウント、またはサービスアカウントに Cloud DNS のレコードセットを操作する権限を持たせます。Cloud IAM を使用して、以下の権限を付与します。- dns.changes.create- dns.managedZones.get- dns.resourceRecordSets.create- dns.resourceRecordSets.update- dns.resourceRecordSets.delete- dns.resourceRecordSets.listもしくは、/roles/dns.admin 役割を付与します。Cloud IAM については、以下を参照してください。Cloud Identity and Access Management(IAM):リソースへのアクセス権の付与、変更、取り消し:アクセス制御:OS 起動時間の調整、ネットワーク設定の確認、ルートファイルシステムの確認、ファイアウォールの設定を確認、サーバの時刻を同期、SELinuxの設定を確認
各手順は以下を参照してください。
CLUSTERPROのインストール
インストール手順は以下を参照してください。インストール完了後、OSの再起動を行ってください。- 『インストール&設定ガイド』
CLUSTERPROのライセンスを登録
ライセンス登録手順は以下を参照してください。- 『インストール&設定ガイド』
5.3. CLUSTERPROの設定¶
Cluster WebUI のセットアップ、および接続方法は以下を参照してください。
『インストール&設定ガイド』 - 「クラスタ構成情報を作成する」
以下のリソース/モニタリソースを追加する手順を記述します。
ミラーディスクリソース
EXEC リソース
上記以外の設定は以下を参照してください。
クラスタの作成
最初に、クラスタ生成ウィザードを開始し、クラスタを構築します。
クラスタの構築
Cluster WebUI にアクセスし、[クラスタ生成ウィザード] をクリックします。 クラスタ生成ウィザード]の[クラスタ]が表示されます。[クラスタ名] に任意のクラスタ名を入力します。[言語] を適切に選択します。[次へ] をクリックします。 [基本設定]が表示されます。Cluster WebUI に接続したインスタンスがマスタサーバとして登録済みの状態で表示されます。[追加] をクリックし、残りのインスタンスを追加します(インスタンスの内部IPアドレスを指定します)。[次へ] をクリックします。 [インタコネクト] 画面が表示されます。インタコネクトのために使用するIPアドレス(各インスタンスの内部IPアドレス)を指定します。また、後で作成するミラーディスクリソースの通信経路として [MDC] に mdc1 を選択します。[次へ] をクリックします。 [NP解決] 画面が表示されます。何も指定せず [次へ] をクリックします。
グループリソースの追加
グループの定義
フェイルオーバーグループを作成します。
[グループ一覧] 画面が表示されます。[追加]をクリックします。 [グループの定義] 画面が表示されます。[名前] にフェイルオーバーグループ名(failover1)を設定します。[次へ] をクリックします。 [起動可能サーバ 画面が表示されます。何も指定せず [次へ] をクリックします。 [グループ属性] 画面が表示されます。何も指定せず [次へ] をクリックします。 [グループリソース一覧] 画面が表示されます。以降の手順で、この画面でグループリソースを追加していきます。ミラーディスクリソース
[グループリソース一覧] で [追加] をクリックします。 [グループ のリソース定義 | failover1] 画面が開きます。[タイプ] ボックスでグループリソースのタイプ(ミラーディスクリソース) を選択し、[名前] ボックスにリソース名を入力します。[次へ] をクリックします。 [依存関係] 画面が表示されます。何も指定せず [次へ] をクリックします。 [復旧動作] 画面が表示されます。[次へ] をクリックします。 [詳細] 画面が表示されます。[データパーティションデバイス名] [クラスタパーティションデバイス名] に「3. インスタンスの設定」で作成したパーティションのデバイス名を入力します。[マウントポイント]、[ファイルシステム]を入力します。 [完了] をクリックして設定を終了します。EXEC リソース
[グループリソース一覧] で [追加] をクリックします。 [グループ のリソース定義 | failover1] 画面が開きます。[タイプ] ボックスでグループリソースのタイプ (EXEC リソース) を選択して、[名前] ボックスにリソース名を入力します。[次へ] をクリックします。 [依存関係] 画面が表示されます。何も指定せず [次へ] をクリックします。 [復旧動作] 画面が表示されます。[次へ] をクリックします。 Start script を Cloud DNS 対応スクリプトの start.sh の内容に、stop script を Cloud DNS 対応スクリプトの stop.sh の内容にそれぞれ編集します。start.sh, stop.sh のパラメータの値は以下を参考に環境に合わせて設定してください。
パラメータ名
説明
値(本書での例)
SERVER1_NAME
server1のサーバ名
"server1"
SERVER1_IP
server1のIPアドレス
"10.0.11.101"
SERVER2_NAME
server2のサーバ名
"server2"
SERVER2_IP
server2のIPアドレス
"10.0.11.102"
ZONE_NAME
ゾーン名
"test-zone"
DOMAIN_NAME
DNS 名
"test-cluster.example.com"
DOMAIN_TYPE
レコードタイプ
"A"
DOMAIN_TTL
TTL値
"5"
[完了] をクリックします。
モニタリソースの追加
Cloud DNS 対応スクリプトでは、EXEC リソースで登録したレコードの存在確認や名前解決可否を監視する手段を提供しておりません。必要に応じて、カスタムモニタリソースを作成してください。詳細は以下を参照してください。- 『リファレンスガイド』 -「カスタムモニタリソースを理解する」設定の反映とクラスタの起動
以下を参照してください。- 『インストール&設定ガイド』 - 「クラスタを生成するには」
5.4. 動作確認¶
フェイルオーバーグループ(failover1)が、現用系ノードのserver1で起動します。Cluster WebUI [ステータス]タブにおいてfailover1がserver1で[起動済]になっていることを確認します。 クライアントから、test-cluster.example.com にアクセスし、現用系ノードに接続できることを確認します。$ nslookup test-cluster.example.com <DNSサーバー> Cluster WebUI から、フェールオーバーグループを現用系ノードから待機系ノードに手動で移動します。Cluster WebUI [ステータス]タブにおいてfailover1がserver2で[起動済]になっていることを確認します。 クライアントから、test-cluster.example.com にアクセスし、待機系ノードに接続できることを確認します。$ nslookup test-cluster.example.com <DNSサーバー>
7. 注意・制限事項¶
7.1. ロードバランサを使用したHAクラスターの場合¶
7.1.1. GCPの注意事項¶
マルチテナントのクラウド環境では、物理環境や一般的な仮想化環境(非クラウド環境)に比べて性能の差が大きくなる(性能の劣化率が大きくなる)傾向があります。性能を重視するシステムでは、設計フェーズにおいて、この点に留意する必要があります。
7.1.2. CLUSTERPROの注意事項¶
- GCP の仕様により、外部 TCP ネットワーク負荷分散では HTTP プロトコルを使用するレガシー ヘルスチェックが要求されます。Google Cloud 仮想 IP リソースは、TCP プロトコルを使用するヘルスチェックにのみ対応しているため、外部 TCP ネットワークロードバランサからのヘルスチェックに応答できません。そのため、外部 TCP ネットワークロードバランサによる Google Cloud 仮想 IP リソースを使用したHAクラスターはご利用になれません。内部 TCP ロードバランサをご利用ください。以下を参照してください。ヘルスチェックのコンセプト:
- 内部 TCP ロードバランサを使用したHAクラスター構成では、GCP の仕様により、HAクラスターと異なるリージョンのクライアントからは、HAクラスターにアクセスできません。以下を参照してください。内部 TCP / UDP 負荷分散のコンセプト:
- OS の起動時間は[ハートビートタイムアウト]より長くなるよう調整してください。
- [クラスタプロパティ]-[監視]タブ-[シャットダウン監視タイムアウト]にて、既定値(ハートビートのタイムアウトを使用する)から変更する場合、[ハートビートタイムアウト]以下となるよう調整してください。以下を参照してください。
以下も参照してください。
7.2. Cloud DNSを使用したHAクラスターの場合¶
7.2.1. GCPの注意事項¶
マルチテナントのクラウド環境では、物理環境や一般的な仮想化環境(非クラウド環境)に比べて性能の差が大きくなる(性能の劣化率が大きくなる)傾向があります。性能を重視するシステムでは、設計フェーズにおいて、この点に留意する必要があります。
- クライアントから名前解決できるようになるまでに時間が掛かる場合があります。以下のいずれかが考えられます。それぞれの設定を確認してください。- OS 側のリゾルバにより時間が掛かっている。- TTL の値が大きい。- Cloud DNS への変更が反映完了する前に名前解決を試みてしまうと DNS からは NXDOMAIN (存在しないドメイン)が返りますが、その場合はネガティブキャッシュの有効期間が経過するまでは名前解決に失敗します。
7.2.2. CLUSTERPROの注意事項¶
- Cloud DNS 対応スクリプトを使用した EXEC リソースは一つのみとしてください。GCP の仕様により、Cloud DNS に対してレコードセットに対する操作が同時に複数重なると、一部の操作が失敗することがあります。
- OS の起動時間は[ハートビートタイムアウト]より長くなるよう調整してください。
- [クラスタプロパティ]-[監視]タブ-[シャットダウン監視タイムアウト]にて、既定値(ハートビートのタイムアウトを使用する)から変更する場合、[ハートビートタイムアウト]以下となるよう調整してください。以下を参照してください。