[CLUSTERPRO]AWSで利用する場合の構成まとめ

CLUSTERPRO関連記事

コンニチハ。千葉です。

SQL ServerをMulti-AZ化したい！

ですが残念です。RDS for SQL ServerはTokyoリージョンにてMulti-AZ対応していないのです。(2015/11/10現在)

※Multi-AZ対応しているリージョン：US East (N. Virginia)、米国西部（オレゴン）、欧州（アイルランド）

最新の情報については、AWSの公式サイトよりご確認ください。

AWSでSQL ServerをMulti-AZ化をするには、SQL Server on EC2 + CLUSTERPROという手があります。 ということで今回は、CLUSTERPROをEC2で利用する場合の考えられる構成についてまとめます。

考えられるCLUSTERPROを利用した構成

• EIP(再関連付け)方式
• VIP(ルートテーブル切り替え方式)方式
• ハイブリッド方式(EIP+VIP方式)
• ENI切り替え方式

の4パターンについての説明と、メリット・デメリットについて考えたいと思います。

CLUSTERPROとは？

日本電気株式会社(NEC)が提供を行っているHAクラスタリングソフトウェアです。

引用：CLUSTERPRO

CLUSTERPRO(クラスタープロ)は、システムの障害を監視し、障害発生時には健全なサーバに業務を引継ぐことで、高可用性を実現する、日本No.1、日本を含むアジア・パシフィック No.1のHAクラスタリングソフトウェアです。

私は、オンプレにてOracleデータベースサーバの冗長化するとき、何度かお世話になっております。

CLUSTERPRO on EC2での前提

データの同期方式

クラスタ構成ではActiveサーバ、Standbyサーバ間で同じデータを参照する必要があります。

同じデータを参照するには共有ディスク方式、ミラーディスク方式とあるのですが、AWSでは共有ディスクが使えないので、自動的にミラーディスク方式となります。 (AWSでの共有ディスクとして、GlusterFSやEFSなどが考えられます今回は考慮していません)

インターネット接続が必須

クラスタサーバは、インターネットへのアウトバンド接続が必須となります。 これは、ENIの付替えやルートテーブル書き換える等、CLUSTERPROでAWSリソースを制御するため、AWS ENDPOINTへの接続が必要となるためです。

CLUSTERPRO on EC2での構成

EIP方式

VIP方式は1番シンプルな構成となります。クラスタはパブリックサブネットに配置され、EIP経由(追加したENIへEIPを関連付ける)によるアクセスとなります。

フェイルオーバー時の挙動は、EIPをStandby側のENIへ関連付けを行います。もちろん、クラスタで制御しているミドルウェア（AP、バッチ、DB等）もStandby側で自動で起動起動します。

VIPへのアクセスはインターネット経由となり、通信を暗号化する必要があります。そのためDB利用ではなく、オープンな処理に利用するとき利用できるシンプルな構成となります。

VIP方式

VIP方式は、EIP方式に比べセキュアになります。EIPというイターネット接続を前提とした通信ではなく、VPC内に閉じた通信となります。クラスタサーバは、プライベートサブネットに配置することが可能でDBサーバなどセキュアなサーバでの利用が望まれます。

構成についてはちょっと特殊ですので注意が必要です。

まず、VIPはVPC外のアドレス(どこのネットワークにも所属していない)を指定します。そんなアドレスで通信できるの？と思うかもしれません。これは、ルートテーブルでVIP向けのルーティングのターゲットをサーバのENIへ設定する、ENIの「Source/Dest Check」を無効にすることで実現します。

フェイルオーバー時の挙動は、VPCに所属している全ルートテーブルのVIP向けエントリをStandby側ENIへ書き換えます。

ただし、1つだけ課題がありNATサーバを必ず必要とします。(VIP制御のためクラスタサーバはAWS ENDPOINTにアクセスする必要があるためです) NATサーバは、Single Point of Failureになりやすいため考慮が必要です。 また、NATサーバがメンテナンス等で利用できない場合はクラスタも影響を受ける可能性があります。

ハイブリッド方式(EIP+VIP方式)

EIPのデメリット、VIPのデメリットを補おうと考えたのがこのハイブリッド方式です。 クラスタは、パブリックサブネットに配置しEIPとVIPどちらも利用します。

EIPはAPI ENDPOINTへのアクセス、VIPはAPサーバ等からのアクセスに利用します。 こうすることで、Single Point of Failureの排除、NATインスタンスの影響も受けず、通信はPrivate IPによるセキュアな通信が可能となります。

フェイルオーバー時の挙動はVIP方式と同じになります。ここでは、VIP方式との構成の違いを図にしています。

この構成を利用するにあたり、特に注意しなければいけない点は、セキュリティグループの設定です。

セキュリティグループをソースIPアドレスを絞らずに開けてしまうと、外部からアクセスが可能となります。

そのため、内部アクセスに絞る、外部からアクセスするIPアドレスを絞る必要があります。

この部分を注意さえできれば、一番可用性も高くセキュアな構成ではないかと思います。

ENI切り替え方式

この構成はオンプレとAWS間で連携する必要がある場合に利用します。具体的な例でいうと、オンプレのSQLサバーとAWS上のSQLサーバとで同期を行う場合です。

まず、データセンターとAWS間をDirect ConnectまたはVPNで接続します。データセンターからインスタンスへの接続はPrivate IPでの接続をします。 注意点としては、Activeサーバ、Standbyサーバは同一AZに配置する必要があります。これは、ENI付替えは同一AZでのみ実施が可能なためです。

フェイルオーバー時の挙動としては、ENIをStandby側に関連付けます。これで、Standby側との通信を行います。

まとめ

構成のポイントまとめです。

• EIP方式：インターネット通信のためオープンな通信、でも一番シンプルなクラスタ構成
• VIP方式：一番セキュアな方式だが、NATサーバを利用するためNATインスタンスの影響を受ける可能性がある
• ハイブリッド方式(EIP+VIP方式)：セキュリティグループの設定に注意が必要だが、セキュアかつシンプルな構成
• ENI切り替え方式：Direct ConnectやVPNを利用した、オンプレとの連携をする場合の構成

何かの参考になると幸いです。