Re:Q Techブログをご覧いただきありがとうございます。
インフラ技術部Iです。

前回のCLUSTERPROの続きとなり、ネットワークパーティション解決についての記事となります。
CLUSTERPRO Xの導入で知るべきオンプレミス環境とAWS環境の違い

オンプレミスとAWSでは、ネットワークパーティション解決でどのような違いがあるのかを簡単に記載します。

ネットワークパーティションとは？

クラスターグループに所属しているサーバー間のネットワーク経路において、障害が発生してネットワーク的に分断されてしまう状態を指します。
では、ネットワークパーティションの解決ができない場合に何が問題となるのでしょうか。

まず、クラスターグループのサーバー間では、ハートビートを使用してお互いの状態を確認しています。

しかし、そのハートビートのネットワーク経路に障害が発生した場合、サーバーがネットワーク障害を検出しても、
それがサーバー自体の障害なのか、ネットワークの障害なのかを判断できなくなります。

その結果、スタンバイ側のサーバーもアクティブとなり、両系活性状態となって複数のサーバーから
同一のデータにアクセスすることでデータ破壊を引き起こす可能性があります。

したがって、ネットワークパーティション状態となった場合の対処方法を設定することがとても重要となります。
その設定が、ネットワークパーティション解決です。

尚、オンプレミスとAWSの違いとはなりますが、AWSにおいてハートビートの設定として"DISKハートビート"は使用できません。

ネットワークパーティション解決とは？

ネットワークパーティション解決とは、ハートビートの途絶を検出した際に、
それがサーバー自体の障害なのか、ネットワークの障害なのかを判別するための設定です。
ネットワークパーティション解決で使用可能なPING方式、HTTP方式、Witness方式について、以下の表にまとめました。

方式	説明
PING方式	ネットワーク上の他のノードに対してICMP PINGを送信し、応答があるかを確認します。
HTTP方式	指定されたURLに対してHTTPリクエストを送り、応答を確認します。
Witness方式	第三者サーバー（Witnessサーバー）を利用して、サーバー間の連携状態を確認します。

以下は簡単なネットワークパーティション解決の使用例です。

設定にもよりますが、ネットワークパーティションを検出した際にネットワークパーティション解決先の
リソースに対して疎通が取れない場合、サーバーをシャットダウンします。

今回は、オンプレミスとAWSにおけるPING方式の設定先の違いについて記載します。

オンプレミスの場合

オンプレミスでは、クラスターグループに所属するサーバーは基本的に同一セグメントに配置されるため、
PING方式の疎通先として基本的にセグメント内のゲートウェイアドレスを指定することが可能です。

AWSの場合

AWSでは、冗長化のためにEC2インスタンスを異なるアベイラビリティゾーン（AZ）に配置することが一般的です。
その結果、クラスターグループに所属する複数のEC2インスタンスは異なるサブネットおよびセグメントに所属することになります。

そして、AWSでは異なるサブネットのゲートウェイに対してEC2インスタンスがPING疎通を行うことはできません。
そのため、ゲートウェイを使用したネットワークパーティション解決は設定できません。

例：Subnet-aに所属しているEC2は、Subnet-bのゲートウェイに対してPING疎通を行うことができません。

AWSではPING方式を採用する場合、別途PING応答が可能なEC2インスタンスなどを用意するか、
Direct Connectを利用してオンプレミス側のゲートウェイを設定する必要が有ります。

尚、AWSにおいてのCLUSTERPRO推奨方式はPING方式ではなく、Witness方式またはHTTP方式となっています。

最後に

ネットワークパーティション解決を行うことで、ネットワークパーティションが発生した際に、
ハートビートの途絶がサーバーの問題によるものなのか、ネットワークパーティションによるものなのかを判断することが可能となります。
そのため、クラスターグループにはネットワークパーティション解決を行うことが推奨されます。

今回はCLUSTERPROの例を取り上げましたが、クラウド環境へ移行する際には、オンプレミスで可能だった設定がクラウドではできないこともあります。
そのため、事前にドキュメントをよく確認し、クラウド環境に適した設定を行うことが重要となります。