Geoクラスタリングのクイックスタート #
Geoクラスタリングは、グローバルに分散したデータセンター全体でワークロードを保護します。このマニュアルでは、crmシェルで提供されているGeoブートストラップスクリプトを使用して、基本的なGeoクラスタをセットアップする手順を説明します。
Copyright © 2006–2024 SUSE LLC and contributors.All rights reserved.
この文書は、GNUフリー文書ライセンスのバージョン1.2または(オプションとして)バージョン1.3の条項に従って、複製、頒布、および/または改変が許可されています。ただし、この著作権表示およびライセンスは変更せずに記載すること。ライセンスバージョン1.2のコピーは、「GNUフリー文書ライセンス」セクションに含まれています。
SUSEの商標については、https://www.suse.com/company/legal/を参照してください。サードパーティ各社とその製品の商標は、所有者であるそれぞれの会社に所属します。商標記号(®、™など)は、SUSEおよびその関連会社の商標を示します。アスタリスク(*)は、第三者の商標を示します。
本書のすべての情報は、細心の注意を払って編集されています。しかし、このことは絶対に正確であることを保証するものではありません。SUSE LLC、その関係者、著者、翻訳者のいずれも誤りまたはその結果に対して一切責任を負いかねます。
1 概念の概要 #
SUSE® Linux Enterprise High Availabilityを基にしたGeoクラスタは、各クラスタサイトが従来のクラスタ内の1つのクラスタノードに対応する「オーバーレイ」クラスタであると考えることができます。オーバーレイクラスタは、ブースクラスタチケットマネージャ(以後「ブース」と呼びます)によって管理されます。Geoクラスタ内のそれぞれの参加クラスタがboothd
というサービスを実行します。これは、他のサイトで実行されているブースデーモンに接続し、接続性の詳細を交換します。サイト全体でクラスタリソースを高可用性にするため、ブースはチケットと呼ばれるクラスタオブジェクトに依存します。チケットは指定のクラスタサイトの特定のリソースを実行する権利を付与します。ブースはすべてのチケットが一度に1サイトにのみ付与されることを保証します。
2つのブースインスタンス間の通信が途切れる場合、クラスタサイト間のネットワークの障害か、または一方のクラスタサイトの停止が原因と考えられます。この場合、決定(サイト間のリソースのフェールオーバーなど)について合意状態に達するための追加のインスタンス(3つ目のクラスタサイトまたはarbitrator
)が必要です。アービトレータは特殊なモードでブースインスタンスを実行する(クラスタ外の)単一マシンです。各Geoクラスタは1つまたは複数のアービトレータを持つことができます。
2サイトGeoクラスタをアービトレータなしで実行することもできます。この場合、Geoクラスタの管理者は手動でチケットを管理する必要があります。チケットを複数のサイトに同時に付与する必要がある場合は、ブースで警告が表示されます。
Geoクラスタの概念とコンポーネント、およびGeoクラスタで採用されているチケット管理の詳細については、管理ガイドを参照してください。
2 使用シナリオ #
このマニュアルに記載されている手順に従うと、2つのクラスタサイトと1つのアービトレータを含む基本的なGeoクラスタが構築されます。
クラスタサイトが
amsterdam
およびberlin
という名前であることを想定しています。また、各サイトは2つのノードで構成されていることを想定しています。ノード
alice
およびbob
は、クラスタamsterdam
に属しています。ノードcharlie
およびdoro
は、クラスタberlin
に属しています。サイト
amsterdam
は、仮想IPアドレス192.168.201.100
を取得します。サイト
berlin
は、仮想IPアドレス192.168.202.100
を取得します。アービトレータにはIPアドレス
192.168.203.100
が設定されていることを想定しています。
続行する前に、次の要件が満たされているかどうか確認してください。
- 2つの既存のクラスタ
Geoクラスタに組み合わせる既存のクラスタが2つ以上ある(最初に2つのクラスタを設定する必要がある場合、インストールとセットアップクイックスタートの指示に従ってください)。
- 意味のあるクラスタ名
各クラスタの名前がその場所を反映している意味のある名前である(
amsterdam
、berlin
など)。クラスタの名前は、/etc/corosync/corosync.conf
で定義されています。- アービトレータ
既存のクラスタの一部ではなく、アービトレータとして使用される3つ目のマシンを設置している。
各項目の詳細要件については、3項 「要件」も参照してください。
3 要件 #
すべてのマシン(クラスタノードとアービトレータ)は、少なくとも次のモジュールおよび拡張機能が必要です。
Basesystem Module 15 SP6
Server Applications Module 15 SP6
SUSE Linux Enterprise High Availability 15 SP6
マシンをインストールする際には、HA GEO Node
としてsystem role
を選択します。これにより、デフォルトでGeo Clustering
for High Availability (ha_geo)
パターンのパッケージがインストールされる最小限のシステムになります。
各クラスタサイトに使用される仮想IPはGeoクラスタ間でアクセスできる必要があります。
ブースインスタンスあたり1つのUDPポートと1つのTCPポートを通じて、サイトにアクセスできる必要があります。すなわち、間に配置されているすべてのファイアウォールとIPsecトンネルをこの要件に合わせて設定する必要があります。
セットアップに関する他の決定によって、さらに多くのポートを開く必要が生じることがあります(たとえばDRBDやデータベースレプリケーション用など)。
すべてのサイト上のすべてのクラスタノードはクラスタ外のNTPサーバと同期する必要があります。詳細については、Administration Guide for SUSE Linux Enterprise Server 15 SP6を参照してください。
ノードが同期されていない場合、ログファイルまたはクラスタレポートは分析が難しくなります。
Geoクラスタでは、「奇数」のサイトを使用します。これにより、ネットワーク接続が途切れた場合に、引き続きサイトの過半数が確実に存在するようにします(スプリットブレインシナリオを回避するため)。クラスタサイトの数が偶数の場合は、チケットの自動フェールオーバーを処理するためにアービトレータを使用してください。アービトレータを使用しないときは、チケットを手動でフェールオーバーする必要があります。
各サイトのクラスタには、
amsterdam
やberlin
などの、意味のある名前があります。各サイトのクラスタ名はそれぞれの
/etc/corosync/corosync.conf
ファイルで指定されています。totem { [...] cluster_name: amsterdam }
次のcrmshコマンドを実行して名前を変更します。
#
crm cluster rename NEW_NAME
クラスタサービスを停止して起動し、変更内容を有効にします。
#
crm cluster restart
1つのクラスタ内に複数のアーキテクチャを混在させることはできません。ただし、Geoクラスタの各メンバーには異なるアーキテクチャを(クラスタサイト用、アービトレータ用といった具合に)割り当てることができます。たとえば、Geoクラスタを3つのメンバー(2つのクラスタサイトと1つのアービトレータ)で構成する場合、一方のクラスタサイトをIBM Z、他方のクラスタサイトをx86、アービトレータをPOWERで実行できます。
4 Geoブートストラップスクリプトの概要 #
crm cluster geo_init
を使用して、あるクラスタをGeoクラスタの最初のサイトにします。このスクリプトは、クラスタの名前、アービトレータ、1つまたは複数のチケットなどのパラメータを取得し、それらから/etc/booth/booth.conf
を作成します。ブース設定を現在のクラスタサイトのすべてのノードにコピーします。また、現在のクラスタサイトのブースに必要なクラスタリソースも設定します。詳細については、6項 「Geoクラスタの最初のサイトの設定」を参照してください。
crm cluster geo_join
を使用して、現在のクラスタを既存のGeoクラスタに追加します。このスクリプトは既存のクラスタサイトからブース設定をコピーし、それを現在のクラスタサイトのすべてのノード上の/etc/booth/booth.conf
に書き込みます。また、現在のクラスタサイトのブースに必要なクラスタリソースも設定します。詳細については、7項 「Geoクラスタへの別のサイトの追加」を参照してください。
crm cluster geo_init_arbitrator
を使用して、現在のマシンをGeoクラスタのアービトレータにします。このスクリプトは既存のクラスタサイトからブース設定をコピーし、それを/etc/booth/booth.conf
に書き込みます。詳細については、8項 「アービトレータの追加」を参照してください。
すべてのブートストラップスクリプトは/var/log/crmsh/crmsh.log
にログを記録します。ブートストラッププロセスの詳細については、ログファイルを確認してください。ブートストラッププロセス中に設定されたオプションは後で変更できます(ブース設定の変更やリソースの変更など)。詳細については、管理ガイドを参照してください。
5 高可用性パッケージおよびGeoクラスタリングパッケージのインストール #
Geoクラスタを設定および管理するためのパッケージは、High Availability
インストールパターンおよびGeo Clustering for High Availability
インストールパターンに含まれています。これらのパターンは、SUSE Linux Enterprise High Availabilityのインストール後にのみ使用できます。
SUSE Customer Centerに登録して、SUSE Linux Enterprise Serverのインストール中またはインストール後にSUSE Linux Enterprise High Availabilityをインストールできます。SUSE Linux Enterprise Serverの詳細については、Deployment Guideを参照してください。
コマンドラインから高可用性パターンおよびGeoクラスタリングパターンをインストールします。
#
zypper install -t pattern ha_sles ha_geo
クラスタの一部になる「すべての」マシンに高可用性パターンおよびGeoクラスタリングパターンをインストールします。
注記: すべてのノードへのソフトウェアパッケージのインストールSUSE Linux Enterprise Server 15 SP6およびSUSE Linux Enterprise High Availability 15 SP6を自動インストールする場合は、AutoYaSTを使用して既存のノードをクローンします。詳細については、3.2項 「AutoYaSTによる大量インストールと展開」を参照してください。
6 Geoクラスタの最初のサイトの設定 #
crm cluster geo_init
コマンドを使用して、既存のクラスタをGeoクラスタの最初のサイトにします。
amsterdam
を使用して最初のサイト(crm cluster geo_init
)を設定する #サイトへのアクセスに使用可能なクラスタサイトごとの仮想IPを定義します。この目的のために
192.168.201.100
および192.168.202.100
を使用することを想定しています。仮想IPをクラスタリソースとして設定する必要はまだありません。これはブートストラップスクリプトによって実行されます。クラスタサイトで特定のリソースを実行する権利を付与する少なくとも1つのチケットの名前を定義します。チケットに依存するリソースを反映する、意味のある名前を使用します(たとえば、
ticket-nfs
)。ブートストラップスクリプトはチケット名のみが必要です。10項 「次のステップ」で説明されるように、後で既存の詳細(リソースのチケット依存関係)を定義できます。既存のクラスタのノードにログインします(たとえば、クラスタ
alice
のノードamsterdam
)。crm cluster geo_init
を実行します。たとえば、次のオプションを使用します。#
crm cluster geo_init \ --clusters "amsterdam=192.168.201.100 berlin=192.168.202.100" \
1--tickets ticket-nfs \
2--arbitrator 192.168.203.100
3
ブートストラップスクリプトはブース設定ファイルを作成し、それをクラスタサイト間で同期します。また、ブースに必要な基本的なクラスタリソースも作成します。手順 2のステップ 4の結果、次のブース設定およびクラスタリソースが作成されます。
crm cluster geo_init
によって作成されたブース設定 ## The booth configuration file is "/etc/booth/booth.conf". You need to # prepare the same booth configuration file on each arbitrator and # each node in the cluster sites where the booth daemon can be launched. # "transport" means which transport layer booth daemon will use. # Currently only "UDP" is supported. transport="UDP" port="9929" arbitrator="192.168.203.100" site="192.168.201.100" site="192.168.202.100" authfile="/etc/booth/authkey" ticket="ticket-nfs" expire="600"
crm cluster geo_init
によって作成されたクラスタリソース #primitive1 booth-ip IPaddr2 \ params rule #cluster-name eq amsterdam ip=192.168.201.100 \ params rule #cluster-name eq berlin ip=192.168.202.100 \ primitive2 booth-site ocf:pacemaker:booth-site \ meta resource-stickiness=INFINITY \ params config=booth \ op monitor interval=10s group3 g-booth booth-ip booth-site \ meta target-role=Stopped4
各クラスタサイトの仮想IPアドレス。各クラスタサイトで持続的なIPアドレスを必要とするブースデーモンによって要求されます。 | |
ブースデーモンのプリミティブリソース。他のクラスタサイト上のブースデーモンと通信します。デーモンは、サイトの任意のノードで起動できます。リソースを同一ノードに維持するには、可能な場合は、resource-stickinessを | |
両方のプリミティブのためのクラスタリソースグループ。この設定では、各ブースデーモンは、デーモンが実行しているノードとは関係なく、個々のIPアドレスで使用できます。 | |
クラスタリソースグループはデフォルトでは開始されません。クラスタリソースの設定を確認(およびセットアップを完了するために必要なリソースを追加)した後で、リソースグループを開始する必要があります。詳細についてはGeoクラスタのセットアップを完了するために必要な手順を参照してください。 |
7 Geoクラスタへの別のサイトの追加 #
Geoクラスタの最初のサイトを初期化した後で、crm cluster geo_join
で説明されるように、2つ目のクラスタを手順 3を使用して追加します。このスクリプトはすでに設定されているクラスタサイトへのSSHアクセスを必要とします。また、現在のクラスタをGeoクラスタに追加します。
berlin
を使用して2番目のサイト(crm cluster geo_join
)を追加する #追加するクラスタサイトのノードにログインします(たとえば、クラスタ
charlie
のノードberlin
。)crm cluster geo_join
コマンドを実行します。例:#
crm cluster geo_join \ --cluster-node 192.168.201.100\
1--clusters "amsterdam=192.168.201.100 berlin=192.168.202.100"
2
crm cluster geo_join
コマンドは、ブース設定を1からコピーします。例 1を参照してください。また、ブースに必要なクラスタリソースを作成します(例 2を参照)。
8 アービトレータの追加 #
crm cluster geo_init
およびcrm cluster geo_join
を使用してGeoクラスタのすべてのサイトを設定した後で、crm cluster geo_init_arbitrator
を使用してアービトレータを設定します。
crm cluster geo_init_arbitrator
を使用したアービトレータの設定 #アービトレータとして使用するマシンにログインします。
次のコマンドを実行します。例:
#
crm cluster geo_init_arbitrator --cluster-node 192.168.201.100
1ブース設定のコピー元の場所を指定します。すでに設定されているGeoクラスタサイトのノードのIPアドレスまたはホスト名を使用します。または、(この例のように)既存のクラスタサイトの仮想IPアドレスを使用します。
crm cluster geo_init_arbitrator
スクリプトは、ブース設定を1からコピーします。例 1を参照してください。また、アービトレータ上でブースサービスを有効化および開始します。このようにして、ブースサービスがクラスタサイトで実行されると、アービトレータはそれらのサイトのブースインスタンスと通信する準備が整います。
9 クラスタサイトの監視 #
両方のクラスタサイトのブートストラッププロセス中に作成したリソースおよびチケットを表示するには、Hawk2を使用します。Hawk2 Webインタフェースは、複数の(無関係な)クラスタとGeoクラスタを監視および管理できます。
Hawk2の
で監視するすべてのクラスタでは、SUSE Linux Enterprise High Availability 15 SP6を実行している必要があります。すべてのクラスタノードにあるHawk2の自己署名証明書を独自の証明書(または公式認証局によって署名された証明書)で置き換えていない場合は、「すべての」クラスタの「すべての」ノードで、少なくとも1回はHawk2にログインします。証明書を検証します(または、ブラウザで例外を追加して警告をスキップします)。そうしない場合、Hawk2はクラスタに接続できません。
Webブラウザを起動し、最初のクラスタサイト
amsterdam
の仮想IPを入力します。https://192.168.201.100:7630/
または、
alice
またはbob
のIPアドレスまたはホスト名を使用します。ブートストラップスクリプトを使用して両方のノードを設定している場合は、hawk
サービスが両方のノードで実行されるはずです。Hawk2 Webインタフェースにログインします。
左のナビゲーションバーから、
を選択します。Hawk2に、現在のクラスタサイトのリソースとノードの概要が表示されます。また、Geoクラスタに設定されているすべての
が表示されます。このビューで使用されるアイコンに関する情報が必要な場合は、 をクリックします。図 2: 1つのクラスタサイト(amsterdam
)を表示するHawk2ダッシュボード #2つ目のクラスタサイトのダッシュボードを追加するには、
をクリックします。berlin
.一方のクラスタノードの完全修飾ホスト名を入力します(この場合、
charlie
またはdoro
)。- 図 3: 両方のクラスタサイトが表示されたHawk2ダッシュボード #
クラスタサイトやその管理に関する詳細を参照するには、サイトのタブに切り替えてチェーンアイコンをクリックします。
Hawk2はこのサイトの
ビューを新しいブラウザウィンドウかタブに表示します。この部分のGeoクラスタをそこから管理できます。
10 次のステップ #
Geoクラスタリングブートストラップスクリプトを使用すると、テスト目的で使用可能な基本的なGeoクラスタを迅速に設定できます。ただし、結果として生じたGeoクラスタを、運用環境で使用可能な機能するGeoクラスタに移行するには、さらに手順が必要です。
- クラスタサイト上のブースサービスの開始
ブートストラッププロセスの後で、アービトレータブースサービスはまだクラスタサイト上のブースサービスと通信できません。クラスタサイト上のブースサービスは、デフォルトでは開始されないためです。
各クラスタサイト用のブースサービスは、ブースリソースグループ
g-booth
によって管理されます(例2「crm cluster geo_init
によって作成されたクラスタリソース」を参照)。サイトあたり1つのブースサービスインスタンスを開始するには、各クラスタサイト上でそれぞれのブースリソースグループを開始します。これにより、すべてのブースインスタンスが相互に通信できるようになります。- チケット依存関係と順序の制約の設定
リソースがGeoクラスタブートストラッププロセス中に作成したチケットに依存するようにするには、制約を設定します。制約ごとに、チケットがクラスタサイトから取り消された場合の各リソースの動作を定義する
loss-policy
を設定します。詳細については、第6章 「Configuring cluster resources and constraints」を参照してください。
- まずチケットをサイトに付与する
ブースがGeoクラスタ内の特定のチケットを管理するためには、まずチケットを手動でサイトに「付与」する必要があります。チケットを付与するには、ブースクライアントのコマンドラインツールまたはHawk2のいずれかを使用できます。
詳細については、第8章 「Managing Geo clusters」を参照してください。
ブートストラップスクリプトは、両方のクラスタサイトで同一のブースリソース、およびアービトレータを含むすべてのサイトで同一のブース設定ファイルを作成します。(運用環境へ移行するため) Geoクラスタセットアップを拡張するときは、多くの場合、ブート設定を微調整し、ブース関連のクラスタリソースの設定を変更します。その後、Geoクラスタの他のサイトへの変更を有効にするため、変更内容を同期する必要があります。
ブース設定の変更をすべてのクラスタサイト(アービトレータを含む)に同期するには、Csync2を使用します。詳細については、第5章 「Synchronizing configuration files across all sites and arbitrators」を参照してください。
CIB (クラスタ情報データベース)は、Geoクラスタのクラスタサイト間で自動的に同期されません。つまり、すべてのクラスタサイトで必要なリソース設定の変更を他のサイトに手動で転送する必要があります。これを行うには、各リソースをタグ付けし、それらを現在のCIBからエクスポートして、他のクラスタサイト上のCIBにインポートします。詳細については、6.4項 「Transferring the resource configuration to other cluster sites」を参照してください。
11 詳細の参照先 #
本製品の他のマニュアルは、https://documentation.suse.com/sle-ha/で入手できます。設定および管理タスクの詳細については、包括的な『Geo Clustering Guide』を参照してください。
DRBDを介したGeoクラスタ間のデータレプリケーションに関する詳細については、次のSUSE Best Practices documentを参照してください。