サイト内の現在位置を表示しています。

CLUSTERPRO X 6.0のご紹介 ~オブジェクトストレージハートビートリソース~

CLUSTERPRO オフィシャルブログ ~クラブロ~

はじめに

CLUSTERPRO Xの最新バージョンであるCLUSTERPRO X 6.0を2026年4月8日にリリースしました。CLUSTERPRO X 6.0では業務システム単位の可用性を可視化、ユーザビリティ向上、クラウド、セキュリティ、IaC対応、新OS・プラットフォーム対応など多数の機能強化を実施しました。詳細はpopup機能強化ポイントをご参照ください。

これらの機能強化の一つとして、新たにオブジェクトストレージハートビートリソースが追加されました。これにより、Amazon Web Services(以降、AWS)環境におけるHAクラスターのハートビートI/FとしてAmazon S3(以降、S3)のバケットも利用可能となりました。

本記事では、オブジェクトストレージハートビートリソースの概要、および、AWS環境上にミラーディスク型HAクラスターを構築し、S3バケットの作成からオブジェクトストレージハートビートリソースの設定、動作確認を行うまでの手順を紹介します。

この記事の内容

1. オブジェクトストレージハートビートリソースとは

ハートビートリソースの役割

HAクラスター内のサーバーは、稼働中は互いの死活監視を行っています。この死活監視に使用されるのがハートビートリソースです。各サーバーはハートビートを定期的に送受信し、相手サーバーの生存を確認します。ハートビートの送受信に使用されるサーバー間の通信経路のことを「インターコネクト」と呼びます。すべてのインターコネクト(ハートビート経路)で相手サーバーからの応答が途絶えた場合、そのサーバーに障害が発生したと判断し、フェールオーバーなどの回復動作を実行します。

死活監視の精度を高めるため、複数の経路のハートビートリソースを設定することが推奨されています。CLUSTERPRO X 5.3までは次のハートビートリソースが用意されています。

  • カーネルモードLANハートビートリソース
  • Witnessハートビートリソース
  • LANハートビートリソース(Linuxのみ)
  • ディスクハートビートリソース(Linuxのみ)

CLUSTERPRO X 6.0から新たにオブジェクトストレージハートビートリソースが追加され、プラットフォームとしてAmazon S3が選択可能になりました。これにより、AWS環境ではS3バケットを利用して通信経路の異なるハートビートリソースを追加できるようになりました。

オブジェクトストレージハートビートリソースの動作原理

オブジェクトストレージハートビートリソースは、オブジェクトストレージが保持しているオブジェクトを定期的に更新し、各サーバーに対応するオブジェクトの最終更新日時を定期的に確認することで、サーバーの死活監視を行います。仕組みとしてはWitnessハートビートリソースに似ていますが、WitnessハートビートリソースではWitnessサーバーがSPOF(単一障害点)となるリスクがある一方、本方式は高可用性のオブジェクトストレージを利用するため、そのリスクを低減できる点が長所です。

オブジェクトストレージハートビートリソース

2. HAクラスター構成

本記事では、CLUSTERPRO X 6.0を使用してAWS環境にミラーディスク型HAクラスターを構築します。HAクラスターを構成する2台のサーバーは異なるアベイラビリティゾーン(AZ)に配置し、可用性を高めます。HAクラスターにアクセスするクライアントをHAクラスターとは異なる独立したプライベートネットワークに配置しています。

オブジェクトストレージハートビートリソースのためにS3バケット(s3-objhb)を用意します。各サーバーはカーネルモードLANハートビートリソースに加えて、オブジェクトストレージハートビートリソースを追加し、S3バケットを経由しての死活監視も行うようにします。S3バケットに対するアクセスがプライベートアクセスとなるようにS3ゲートウェイエンドポイントを追加します。また、図では省略していますがEC2エンドポイントも追加し、AWS CLIの通信もVPCエンドポイントを経由するようにすることで、完全にVPC内に閉じた構成にします。OSアップデートやAWS CLIのダウンロード時にはインターネットアクセスが必要となりますが、本記事では必要な時に一時的にインターネットアクセスに必要な手段(NATゲートウェイ等)を用意するものとし、構成図からは割愛しています。

3. HAクラスターの構築手順

3.1 VPCの作成

以下の構成でVPCおよびサブネットを作成します。

- VPC (vpc-project)
- CIDR: 10.100.0.0/16
- Subnets
    - subnet-private-1a: 10.100.100.0/24 (ap-northeast-1a)
    - subnet-private-2a: 10.100.110.0/24 (ap-northeast-1a)
    - subnet-private-2c: 10.100.120.0/24 (ap-northeast-1c)

3.2 EC2インスタンスの作成

クライアントおよびサーバー用のEC2インスタンスを以下の通り作成します。本記事では、サーバーのOSはLinuxで作成していますがWindowsでもほとんど同様の手順となります。

- クライアント (client)
  - サブネット: subnet-private-1a
  - IPアドレス: 10.100.100.10
  - OS: Windows Server 2025

- サーバー1 (server01)
  - サブネット: subnet-private-2a
  - IPアドレス: 10.100.110.10
  - OS: Red Hat Enterprise Linux 10.0

- サーバー2 (server02)
  - サブネット: subnet-private-2c
  - IPアドレス: 10.100.120.10
  - OS: Red Hat Enterprise Linux 10.0

3.3 S3バケットの作成

HAクラスターを構築するリージョンと同じリージョンにオブジェクトストレージハートビートリソース用のS3バケットを作成します。ハートビート用のフォルダやオブジェクトはCLUSTERPRO Xが自動的に作成するため、バケットの中は空のままで問題ありません。特に記載のない項目は初期値のままです。

- S3バケット
  - バケットタイプ: 汎用
  - バケット名: s3-objhb

3.4 VPCエンドポイントの作成

S3バケットに対するアクセスおよびAWS CLIの実行をプライベート接続で実現するために、次の2種類のVPCエンドポイントを作成します。

  • S3ゲートウェイエンドポイント
  • EC2エンドポイント

S3ゲートウェイエンドポイントは次の手順で作成します。特に記載のない項目は初期値のままです。

  • 1.
    AWSマネジメントコンソールからVPCサービスを開く。
  • 2.
    左メニューの[エンドポイント]から[エンドポイントを作成]をクリックする。
  • 3.
    [名前タグ]に任意の名前(例:「vpce-s3」)を入力する。
  • 4.
    [サービス]で「com.amazonaws.ap-northeast-1.s3(Gateway)」を選択する。
  • 5.
    [VPC]で「vpc-project」を選択する。
  • 6.
    [ルートテーブル]で、server01およびserver02が所属するサブネットに関連付けられたルートテーブルを選択する。
  • 7.
    [エンドポイントを作成]をクリックする。

EC2エンドポイントも、[サービス]に「com.amazonaws.ap-northeast-1.ec2(Interface)」を選択するほかはS3ゲートウェイエンドポイントとほぼ同様の手順で作成します。

3.5 HAクラスターの構築

AWS環境でのHAクラスターの構築、AWS CLIのインストールおよびCLUSTERPRO Xのセットアップについては、以下の過去記事を参考に実施してください。

【参考】

上記記事の手順に沿って、IAMの設定、セキュリティグループの設定、CLUSTERPROのインストールおよびライセンス登録、HAクラスター構成情報の作成までを完了させてください。

なお、本記事では動作確認時に各ハートビートリソースの状態を確認しやすくするため、ネットワークパーティション解決リソースおよび強制停止リソースは設定していません。本来はすべてのインターコネクトでハートビートが途絶した場合にスプリットブレイン状態になることを防ぐため、ネットワークパーティション解決リソースおよび強制停止リソースもあわせて設定することを推奨しています。

CLUSTERPRO Xの設定は次の通りです。

■ Windows

クラスター名: Cluster1
サーバー名: server01、server02
フェールオーバーグループ:
    名前: failover1
    グループリソース:
        awsvip1 (AWS仮想IPリソース)
        md1 (ミラーディスクリソース)
        service1 (サービスリソース)
モニタリソース:
    awsvipw1 (AWS仮想IPモニタリソース)
    mdw1 (ミラーディスクモニタリソース)
    servicew1 (サービスモニタリソース)
    userw (ユーザー空間モニタリソース)

■ Linux

クラスター名: Cluster1
サーバー名: server01、server02
フェールオーバーグループ:
    名前: failover1
    グループリソース:
        awsvip1 (AWS仮想IPリソース)
        md1 (ミラーディスクリソース)
        exec1 (EXECリソース)
モニタリソース:
    awsvipw1 (AWS仮想IPモニタリソース)
    mdnw1 (ミラーディスクコネクトモニタリソース)
    mdw1 (ミラーディスクモニタリソース)
    genw1 (カスタムモニタリソース)
    userw (ユーザー空間モニタリソース)

3.6 オブジェクトストレージハートビートリソースの設定

オブジェクトストレージハートビートリソースの設定として、AWS側のIAMポリシーの許可設定と、Cluster WebUIでのリソース追加・プロパティ設定を行います。

IAMポリシーの許可設定

AWS IAM設定として、HAクラスター用サーバーからS3バケットへのアクセスに必要な以下の許可設定を行ったIAMポリシーを作成し、EC2のIAMロールにアタッチします。

アクション 説明
s3:ListBucket オブジェクトの最終更新日時取得に必要です。
s3:PutObject オブジェクトの更新に必要です。
s3:DeleteObject オブジェクトの削除に必要です。

オブジェクトストレージハートビートリソースの追加

Cluster WebUIを使用して、オブジェクトストレージハートビートリソースを設定します。

  • 1.
    Cluster WebUIの設定モードを開く。
  • 2.
    [クラスタプロパティ]を開き、[インターコネクト]タブを選択する。
  • 3.
    [追加]をクリックして通信経路を追加する。
  • 4.
    追加された行の[種別]列のセルをクリックし、「オブジェクトストレージ」を選択する。

プロパティの設定

インターコネクトの一覧で[オブジェクトストレージ]の行を選択し、[プロパティ]をクリックします。以下の項目を設定します。

設定項目 説明 今回の設定値
プラットフォーム オブジェクトストレージのプラットフォームを選択 Amazon S3
バケット名 オブジェクトストレージのバケット名を入力 s3-objhb
プレフィックス オブジェクトストレージのプレフィックスを入力 cluster1-

オブジェクトストレージハートビート - プロパティ

この設定の場合、実際にS3バケット(s3-objhb)上に作成されるオブジェクトは以下の通りとなります。

/cluster1-<ランダムなUUID>/objhb1/
  +-- server01/
     +-- downnotify
     +-- heartbeat
  +-- server02/
     +-- downnotify
     +-- heartbeat

[調整]ボタンをクリックすると表示される画面ではS3へのリクエスト(LIST/PUT/DELETE)ごとにコマンドのインターバルやタイムアウトを個別に設定可能ですが、今回はすべて既定値のまま使用します。

4. 動作確認

構築したHAクラスターのインターコネクトに関する動作確認を行います。

今回の構成ではカーネルモードLANハートビートリソースとオブジェクトストレージハートビートリソースの2種類が設定されており、もし両方のインターコネクトが通信できなくなった場合はスプリットブレイン状態になります。ここでHAクラスター用サーバー同士の通信を遮断するとカーネルモードLANハートビートリソースが異常となりますが、オブジェクトストレージハートビートリソースが正常のためスプリットブレイン状態にならないことを確認します。

  • 1.
    client上でWebブラウザを起動し、Cluster WebUIを表示します。
  • 2.
    Cluster WebUIでフェールオーバーグループをserver01で起動し、フェールオーバーグループ、グループリソース、モニタリソースが正常に起動していることを確認します。

  • 3.
    [サーバ]の左横の矢印を選択してハートビートのステータス表示を開き、カーネルモードLANハートビートリソース、およびオブジェクトストレージハートビートリソースが正常であることを確認します。

  • 4.
    AWSのネットワークACLの設定でインバウンドルールに対向サーバーからの通信をすべて拒否する規則を追加し、お互いのサーバーで相手からの通信を拒否するようにします。

  • 5.
    しばらくすると、サーバー間の通信が途絶したことによりクラスターが警告状態になります。下図は左側(server01)と右側(server02)のそれぞれのCluster WebUIにおけるクラスターの状態です。両サーバーは対向サーバーとの通信ができないため各リソースの状態を取得できません。しかし、各サーバーのオブジェクトストレージハートビートリソースは正常状態を維持しており、少なくとも対向サーバーが停止していないことを確認できます。また、待機系サーバーでフェールオーバーグループが起動していないことから、スプリットブレイン状態には陥っていないことが分かります。

  • 6.
    "4."で追加していたネットワークACLの拒否規則を削除します。しばらくすると、カーネルモードLANハートビートリソースおよびミラーディスクモニタリソースが正常に戻ることを確認します。

上記の手順により、サーバー間通信が途絶した場合でもS3バケットにアクセス可能な状態であればフェールオーバーの発生を抑制できることを確認できました。

まとめ

インターコネクトは、LANハートビートリソースをはじめ、複数の経路のハートビートリソースを設定した構成が推奨されています。CLUSTERPRO X 6.0で新たにオブジェクトストレージハートビートリソース(Amazon S3)が追加されたことで、AWS環境で通信経路の異なるハートビートリソースを容易に追加できるようになり、HAクラスター内のサーバーの死活監視の精度をさらに高められるようになりました。また、S3バケットは簡単に作成でき、アベイラビリティゾーンやVPCをまたいで利用できるため、AWS環境であればほとんどのシステム構成で採用しやすい点も大きな利点です。AWS環境でHAクラスターを構築する際には、インターコネクトの一つとしてオブジェクトストレージハートビートリソースの追加をぜひご検討ください。

本記事の構成をご検討の際は、CLUSTERPROのpopup試用版を用いて検証した後、ご提案・構築ください。

利用製品

本記事の環境を構築する際に利用した製品です。

■ OS共通
  – CLUSTERPRO X Media 6.0
  – CLUSTERPRO X Startup Kit 6.0
■ Windows
  – CLUSTERPRO X 6.0 for Windows VM (1ノードライセンス)
  – CLUSTERPRO X Replicator 6.0 for Windows (1ノードライセンス)
■ Linux
  – CLUSTERPRO X 6.0 for Linux VM (1ノードライセンス)
  – CLUSTERPRO X Replicator 6.0 for Linux (1ノードライセンス)

参考

CLUSTERPRO導入支援サービス(クラウドHAコンサル)ではオンプレミスやクラウド向けのクラスター構築支援サービスを行っております。クラスターの構築支援に関するご要望がありましたら、popup関連サービスの導入支援サービスの窓口までお問い合わせください。

お問い合わせ

本記事に関するお問い合わせは、popupお問い合わせ窓口までお問い合わせください。