目次にジャンプ
documentation.suse.com / Geoクラスタリングのクイックスタート
SUSE Linux Enterprise High Availability 15 SP6

Geoクラスタリングのクイックスタート

発行日: 2024 年 12 月 12 日

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サイトクラスタ - 2x2ノード+アービトレータ(オプション)
図 1: 2サイトクラスタ - 2x2ノード+アービトレータ(オプション)

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

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

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つのクラスタを設定する必要がある場合、Article “インストールとセットアップクイックスタート”の指示に従ってください)。

意味のあるクラスタ名

各クラスタの名前がその場所を反映している意味のある名前である(amsterdamberlinなど)。クラスタの名前は、/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クラスタでは、「奇数」のサイトを使用します。これにより、ネットワーク接続が途切れた場合に、引き続きサイトの過半数が確実に存在するようにします(スプリットブレインシナリオを回避するため)。クラスタサイトの数が偶数の場合は、チケットの自動フェールオーバーを処理するためにアービトレータを使用してください。アービトレータを使用しないときは、チケットを手動でフェールオーバーする必要があります。

  • 各サイトのクラスタには、amsterdamberlinなどの、意味のある名前があります。

    各サイトのクラスタ名はそれぞれの/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にログを記録します。ブートストラッププロセスの詳細については、ログファイルを確認してください。ブートストラッププロセス中に設定されたオプションは後で変更できます(ブース設定の変更やリソースの変更など)。詳細については、Book “管理ガイド”を参照してください。

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を参照してください。

手順 1: 高可用性パターンおよびGeoクラスタリングパターンのインストール
  1. コマンドラインから高可用性パターンおよびGeoクラスタリングパターンをインストールします。

    # zypper install -t pattern ha_sles ha_geo
  2. クラスタの一部になる「すべての」マシンに高可用性パターンおよびGeoクラスタリングパターンをインストールします。

    注記
    注記: すべてのノードへのソフトウェアパッケージのインストール

    SUSE Linux Enterprise Server 15 SP6およびSUSE Linux Enterprise High Availability 15 SP6を自動インストールする場合は、AutoYaSTを使用して既存のノードをクローンします。詳細については、Book “管理ガイド”, Chapter 3 “SUSE Linux Enterprise High Availabilityのインストール”, Section 3.2 “AutoYaSTによる大量インストールと展開”を参照してください。

6 Geoクラスタの最初のサイトの設定

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

手順 2: amsterdamを使用して最初のサイト(crm cluster geo_init)を設定する
  1. サイトへのアクセスに使用可能なクラスタサイトごとの仮想IPを定義します。この目的のために192.168.201.100および192.168.202.100を使用することを想定しています。仮想IPをクラスタリソースとして設定する必要はまだありません。これはブートストラップスクリプトによって実行されます。

  2. クラスタサイトで特定のリソースを実行する権利を付与する少なくとも1つのチケットの名前を定義します。チケットに依存するリソースを反映する、意味のある名前を使用します(たとえば、ticket-nfs)。ブートストラップスクリプトはチケット名のみが必要です。10項 「次のステップ」で説明されるように、後で既存の詳細(リソースのチケット依存関係)を定義できます。

  3. 既存のクラスタのノードにログインします(たとえば、クラスタaliceのノードamsterdam)。

  4. 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.1003

    1

    クラスタサイトの名前(/etc/corosync/corosync.confで定義される)および各クラスタサイトに使用する仮想IPアドレス。この場合、それぞれが1つの仮想IPアドレスを持つ2つのクラスタサイト(amsterdamおよびberlin)があります。

    2

    1つまたは複数のチケットの名前。

    3

    クラスタ外のマシンのホスト名またはIPアドレス。

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

例 1: 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"
例 2: 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

1

各クラスタサイトの仮想IPアドレス。各クラスタサイトで持続的なIPアドレスを必要とするブースデーモンによって要求されます。

2

ブースデーモンのプリミティブリソース。他のクラスタサイト上のブースデーモンと通信します。デーモンは、サイトの任意のノードで起動できます。リソースを同一ノードに維持するには、可能な場合は、resource-stickinessをINFINITYに設定します。

3

両方のプリミティブのためのクラスタリソースグループ。この設定では、各ブースデーモンは、デーモンが実行しているノードとは関係なく、個々のIPアドレスで使用できます。

4

クラスタリソースグループはデフォルトでは開始されません。クラスタリソースの設定を確認(およびセットアップを完了するために必要なリソースを追加)した後で、リソースグループを開始する必要があります。詳細についてはGeoクラスタのセットアップを完了するために必要な手順を参照してください。

7 Geoクラスタへの別のサイトの追加

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

手順 3: berlinを使用して2番目のサイト(crm cluster geo_join)を追加する
  1. 追加するクラスタサイトのノードにログインします(たとえば、クラスタcharlieのノードberlin。)

  2. 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

    1

    ブース設定のコピー元の場所を指定します。すでに設定されているGeoクラスタサイトのノードのIPアドレスまたはホスト名を使用します。(この例のように)既存のクラスタサイトの仮想IPアドレスを使用することもできます。または、Geoクラスタにすでに設定されているアービトレータのIPアドレスまたはホスト名を使用します。

    2

    クラスタサイトの名前(/etc/corosync/corosync.confで定義される)および各クラスタサイトに使用する仮想IPアドレス。この場合、それぞれが1つの仮想IPアドレスを持つ2つのクラスタサイト(amsterdamおよびberlin)があります。

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

8 アービトレータの追加

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

手順 4: crm cluster geo_init_arbitratorを使用したアービトレータの設定
  1. アービトレータとして使用するマシンにログインします。

  2. 次のコマンドを実行します。例:

    # crm cluster geo_init_arbitrator --cluster-node 192.168.201.1001

    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はクラスタに接続できません。

手順 5: Hawk2ダッシュボードの使用
  1. Webブラウザを起動し、最初のクラスタサイトamsterdamの仮想IPを入力します。

    https://192.168.201.100:7630/

    または、aliceまたはbobのIPアドレスまたはホスト名を使用します。ブートストラップスクリプトを使用して両方のノードを設定している場合は、hawkサービスが両方のノードで実行されるはずです。

  2. Hawk2 Webインタフェースにログインします。

  3. 左のナビゲーションバーから、ダッシュボードを選択します。

    Hawk2に、現在のクラスタサイトのリソースとノードの概要が表示されます。また、Geoクラスタに設定されているすべてのチケットが表示されます。このビューで使用されるアイコンに関する情報が必要な場合は、凡例をクリックします。

    1つのクラスタサイト(amsterdam)を表示するHawk2ダッシュボード
    図 2: 1つのクラスタサイト(amsterdam)を表示するHawk2ダッシュボード
  4. 2つ目のクラスタサイトのダッシュボードを追加するには、クラスタの追加をクリックします。

    1. ダッシュボードでクラスタを識別するためのクラスタ名を入力します。この例では、次のようになります, berlin.

    2. 一方のクラスタノードの完全修飾ホスト名を入力します(この場合、charlieまたはdoro)。

    3. Add (追加)をクリックします。新たに追加されたクラスタサイトに対して、Hawk2は2つ目のタブにノードやリソースの概要を表示します。

      両方のクラスタサイトが表示されたHawk2ダッシュボード
      図 3: 両方のクラスタサイトが表示されたHawk2ダッシュボード
  5. クラスタサイトやその管理に関する詳細を参照するには、サイトのタブに切り替えてチェーンアイコンをクリックします。

    Hawk2はこのサイトのステータスビューを新しいブラウザウィンドウかタブに表示します。この部分のGeoクラスタをそこから管理できます。

10 次のステップ

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

Geoクラスタのセットアップを完了するために必要な手順
クラスタサイト上のブースサービスの開始

ブートストラッププロセスの後で、アービトレータブースサービスはまだクラスタサイト上のブースサービスと通信できません。クラスタサイト上のブースサービスは、デフォルトでは開始されないためです。

各クラスタサイト用のブースサービスは、ブースリソースグループg-boothによって管理されます(例2「crm cluster geo_initによって作成されたクラスタリソース」を参照)。サイトあたり1つのブースサービスインスタンスを開始するには、各クラスタサイト上でそれぞれのブースリソースグループを開始します。これにより、すべてのブースインスタンスが相互に通信できるようになります。

チケット依存関係と順序の制約の設定

リソースがGeoクラスタブートストラッププロセス中に作成したチケットに依存するようにするには、制約を設定します。制約ごとに、チケットがクラスタサイトから取り消された場合の各リソースの動作を定義するloss-policyを設定します。

詳細については、Book “Geo Clustering Guide”, Chapter 6 “Configuring cluster resources and constraints”を参照してください。

まずチケットをサイトに付与する

ブースがGeoクラスタ内の特定のチケットを管理するためには、まずチケットを手動でサイトに「付与」する必要があります。チケットを付与するには、ブースクライアントのコマンドラインツールまたはHawk2のいずれかを使用できます。

詳細については、Book “Geo Clustering Guide”, Chapter 8 “Managing Geo clusters”を参照してください。

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

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

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

11 詳細の参照先