Geo Clusteringのクイックスタート #

SUSE® Linux Enterprise High Availability Extensionを基にしたGeoクラスタは、各クラスタサイトが従来のクラスタ内の1つのクラスタノードに対応する「オーバーレイ」クラスタであると考えることができます。オーバーレイクラスタは、ブースクラスタチケットマネージャ(以後「ブース」と呼びます)によって管理されます。Geoクラスタ内のそれぞれの参加クラスタがboothdというサービスを実行します。これは、他のサイトで実行されているブースデーモンに接続し、接続性の詳細を交換します。サイト全体でクラスタリソースを高可用性にするため、ブースはチケットと呼ばれるクラスタオブジェクトに依存します。チケットは指定のクラスタサイトの特定のリソースを実行する権利を付与します。ブースはすべてのチケットが一度に1サイトにのみ付与されることを保証します。

2つのブースインスタンス間の通信が途切れる場合、クラスタサイト間のネットワークの障害か、または一方のクラスタサイトの停止が原因と考えられます。この場合、決定(サイト間のリソースのフェールオーバーなど)について合意状態に達するための追加のインスタンス(3つ目のクラスタサイトまたはアービトレータ)が必要です。アービトレータは特殊なモードでブースインスタンスを実行する(クラスタ外の)単一マシンです。各Geoクラスタは1つまたは複数のアービトレータを持つことができます。

図 1: 2サイトクラスタ - 2x2ノード+アービトレータ(オプション) #

 

2サイトGeoクラスタをアービトレータなしで実行することもできます。この場合、Geoクラスタの管理者は手動でチケットを管理する必要があります。チケットを複数のサイトに同時に付与する必要がある場合は、ブースで警告が表示されます。

Geoクラスタの概念とコンポーネント、およびGeoクラスタで採用されているチケット管理の詳細については、管理ガイドを参照してください。

以下では、2つのクラスタサイトおよび1つのアービトレータを含む基本的なGeoクラスタを設定します。

続行する前に、次の要件が満たされているかどうか確認してください。

各項目の詳細要件については、3項 「要件」も参照してください。

クラスタの一部になるすべてのマシン(クラスタノードおよびアービトレータ)には、少なくとも次のモジュールと拡張機能が含まれている必要があります。

マシンをインストールする際には、system roleとしてHA GEO Nodeを選択します。これにより、デフォルトでGeo Clustering for High Availability (ha_geo)パターンのパッケージがインストールされる最小限のシステムになります。

すべてのブートストラップスクリプトは/var/log/crmsh/crmsh.logにログを記録します。ブートストラッププロセスの詳細については、ログファイルを確認してください。ブートストラッププロセス中に設定されたオプションは後で変更できます(ブース設定の変更やリソースの変更など)。詳細については、管理ガイドを参照してください。

SUSE Linux Enterprise High Availability Extensionを使用することで、無制限の距離にまたがってHigh Availabilityクラスタを使用できるようになります。

Geoクラスタを設定するには、次のインストールパターンに含まれているパッケージが必要です。

両方のパターンを使用できるための条件は、お使いのシステムをSUSEカスタマセンター(またはローカル登録サーバ)に登録済みであること、かつそれぞれのモジュールまたはインストールメディアを拡張として追加済みであることです。拡張をインストールする方法の詳細については、SUSE Linux Enterprise 15 SP4の『導入ガイド』を参照してください。

コマンドラインを通じて両方のパターンからパッケージをインストールするには、Zypperを使用します。

root # zypper install -t pattern ha_sles ha_geo

重要: すべてのパーティへのソフトウェアパッケージのインストール

High AvailabilityクラスタおよびGeoクラスタに必要なソフトウェアパッケージは、クラスタノードに自動的にコピー「されません」。

• SUSE Linux Enterprise Server 15 SP4と、ha_slesパターンおよびha_geoパターンを、Geoクラスタの一部となる「すべての」マシンにインストールします。

• クラスタの一部となるすべてのマシンにパッケージを手動でインストールする代わりに、AutoYaSTを使用して既存のノードのクローンを作成します。詳細については、3.2項 「AutoYaSTによる大量インストールと展開」を参照してください。

crm cluster geo_initコマンドを使用して、既存のクラスタをGeoクラスタの最初のサイトにします。

ブートストラップスクリプトはブース設定ファイルを作成し、それをクラスタサイト間で同期します。また、ブースに必要な基本的なクラスタリソースも作成します。手順 1のステップ 4の結果、次のブース設定およびクラスタリソースが作成されます。

# 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"

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

Geoクラスタの最初のサイトを初期化した後で、手順 2で説明されるように、2つ目のクラスタをcrm cluster geo_joinを使用して追加します。このスクリプトはすでに設定されているクラスタサイトへのSSHアクセスを必要とします。また、現在のクラスタをGeoクラスタに追加します。

crm cluster geo_joinコマンドは、ブース設定を1からコピーします。例 1を参照してください。また、ブースに必要なクラスタリソースを作成します(例 2を参照)。

crm cluster geo_initとcrm cluster geo_joinを使用して、Geoクラスタのすべてのサイトを設定した後で、crm cluster geo_init_arbitratorを使用してアービトレータを設定します。

crm cluster geo_init_arbitratorスクリプトは、ブース設定を1からコピーします。例 1を参照してください。また、アービトレータ上でブースサービスを有効化および開始します。このようにして、ブースサービスがクラスタサイトで実行されると、アービトレータはそれらのサイトのブースインスタンスと通信する準備が整います。

両方のクラスタサイトのブートストラッププロセス中に作成したリソースおよびチケットを表示するには、Hawk2を使用します。Hawk2 Webインタフェースは、複数の(無関係な)クラスタとGeoクラスタを監視および管理できます。

Geoクラスタリングブートストラップスクリプトを使用すると、テスト目的で使用可能な基本的なGeoクラスタを迅速に設定できます。ただし、結果として生じたGeoクラスタを、運用環境で使用可能な機能するGeoクラスタに移行するには、さらに手順が必要です。Geoクラスタのセットアップを完了するために必要な手順を参照してください。

ブートストラップスクリプトは、両方のクラスタサイトで同一のブースリソース、およびアービトレータを含むすべてのサイトで同一のブース設定ファイルを作成します。(運用環境へ移行するため) Geoクラスタセットアップを拡張するときは、多くの場合、ブート設定を微調整し、ブース関連のクラスタリソースの設定を変更します。その後、Geoクラスタの他のサイトへの変更を有効にするため、変更内容を同期する必要があります。

注記: クラスタサイト間での変更の同期

• ブース設定の変更をすべてのクラスタサイト(アービトレータを含む)に同期するには、Csync2を使用します。詳細については、Chapter 5, Synchronizing configuration files across all sites and arbitratorsを参照してください。

• CIB (クラスタ情報データベース)は、Geoクラスタのクラスタサイト間で自動的に同期されません。つまり、すべてのクラスタサイトで必要なリソース設定の変更を他のサイトに手動で転送する必要があります。これを行うには、各リソースをタグ付けし、それらを現在のCIBからエクスポートして、他のクラスタサイト上のCIBにインポートします。詳細については、Section 6.4, “Transferring the resource configuration to other cluster sites”を参照してください。

Copyright © 2006– 2025 SUSE LLC and contributors.All rights reserved.

この文書は、GNUフリー文書ライセンスのバージョン1.2または(オプションとして)バージョン1.3の条項に従って、複製、配布、および/または改変が許可されています。ただし、この著作権表示およびライセンスは変更せずに記載すること。ライセンスバージョン1.2のコピーは、「GNUフリー文書ライセンス」セクションに含まれています。

SUSEの商標については、http://www.suse.com/company/legal/を参照してください。その他の第三者のすべての商標は、各社の所有に帰属します。商標記号(®、 ™など)は、SUSEおよび関連会社の商標を示します。アスタリスク(*)は、第三者の商標を示します。

本書のすべての情報は、細心の注意を払って編集されています。しかし、このことは絶対に正確であることを保証するものではありません。SUSE LLC、その関係者、著者、翻訳者のいずれも誤りまたはその結果に対して一切責任を負いかねます。