はじめに

アマゾン ウェブ サービス ジャパン合同会社協力の下、2台のAWS Outposts サーバー(Intel Xeonプロセッサ、AWS Graviton2プロセッサ)をお借りして、AWS Outposts サーバー上に立てたEC2インスタンス間でのHAクラスターの構築を検証しました。
以下の2パターンの構成の検証をしましたので、本記事ではAWS Outposts サーバーでHAクラスターを構築する際に考慮すべき点、および、各構成での検証結果をご紹介します。

今回の検証では、アマゾン ウェブ サービス ジャパン合同会社 目黒オフィス17階のAWS Startup LoftにあるAWS Outposts servers lab Tokyo、NECの共創環境のNEC CONNECT 5G Labを利用しました。

この記事の内容

1. AWS Outpostsとは

AWS Outpostsはお客様データセンターや工場、店舗等の任意のロケーションに設置することでAWSサービスを実行可能にするフルマネージドサービスです。その実体は物理的なサーバーであり、AWS Outpostsを任意のロケーションに設置することで利用できます。
これにより、使い慣れたAWSのサービス・ツール・APIを利用して、オンプレミスのシステムと低レイテンシーで連携することができます。
AWS Outpostsには、AWS Outposts サーバーとAWS Outposts ラックの2種類があり、料金や筐体サイズの他に、プロセッサの種類や使用できるAWSサービスの数に違いがあります。現時点(2024年3月22日)では、それぞれ以下のプロセッサ、および、AWSサービスを使用することができます。

■ AWS Outposts サーバー

■ AWS Outposts ラック

AWS Graviton2はARMベースのプロセッサであり、エネルギー効率が高く、コスト削減や二酸化炭素排出量削減に繋げることができるといった特徴があります。
AWS GravitonプロセッサとAWS Outpostsの詳細は以下を参照ください。

【参考】

AWS Graviton プロセッサ

https://aws.amazon.com/jp/ec2/graviton/

AWS Outposts ファミリー

https://aws.amazon.com/jp/outposts/

2. AWS Outposts サーバーでCLUSTERPROを利用する際に考慮すべき点

今回の検証で使用するAWS Outpostsは、AWS Outposts サーバーになります。
AWS Outposts サーバー上のEC2インスタンスでHAクラスターを構築する場合、以下の点を考慮する必要があります。

2.1 インスタンスタイプ

インスタンスタイプはc6id (Intel Xeonプロセッサ)または、c6gd (AWS Graviton2プロセッサ)が利用可能です。また、それぞれのアーキテクチャとして、Intel Xeonプロセッサではx86_64アーキテクチャ、AWS Graviton2プロセッサではARMアーキテクチャを選択できます。
CLUSTERPRO Xでは2024年3月現在、ARMアーキテクチャに対応していませんが、今回はARM評価用の特別版CLUSTERPRO Xを使用して、AWS Graviton2を搭載したAWS Outpostsサーバーで検証を実施しています。

2.2 ストレージ

AWS Outposts サーバー上では、EC2インスタンス1台につき1つのインスタンスストアのみ利用可能です。そのサイズはインスタンスタイプによって固定されており、本検証で利用したc6id.2xlargeとc6gd.2xlargeでは、474GiB固定で拡張することもできません。加えて、AMIからEC2インスタンスを作成する際に、ルートパーティションを拡張して空き領域を全てルートパーティションとして専有します。
そのため、ミラーディスク型クラスターを構築する際は、以下の手順で予めインスタンスストア上にミラー用パーティションを作成したAMIを準備する必要があります。

また、ルートパーティションにインスタンスストアを使用することから、EC2インスタンスをOS上からシャットダウンすると、EC2インスタンスがターミネートされます。
そのため、障害発生後もEC2インスタンスを継続して利用する場合は、CLUSTERPROの回復動作に設定されたOSシャットダウンの動作をOS再起動等の動作に変更する必要があります。

2.3 ネットワークインターフェース

AWS Outposts サーバー上のEC2インスタンスには、以下の2種類のネットワークインターフェースがアタッチ可能であり、それぞれのIPアドレスの設定方法に違いがあります。

LNIのIPアドレスは、EC2インスタンス作成時に2つ目のネットワークインターフェースを設定することで自動的に設定されますが、このIPアドレスは使用することができません。
そのため、nmcliコマンドやifcfgファイルの編集でIPアドレスを設定する必要があります。
なお、利用するOSによっては、nmcliコマンドやifcfgファイルの編集でIPアドレスを変更できないため、その場合はDHCPサーバーから割り振るIPアドレスを指定します。

【参考】

ローカルネットワークインターフェース

https://docs.aws.amazon.com/ja_jp/outposts/latest/server-userguide/local-network-interface.html

2.4 CLUSTERPROのリソース

AWSのクラウド上のEC2インスタンスのENIではARPプロトコルがサポートされないため、CLUSTERPROのフローティングIPリソースを使用することが出来ず、代わりにAWS仮想IPリソースを使用する必要があります。一方、AWS Outposts サーバーのLNIではARPプロトコルがサポートされるため、フローティングIPリソースを使用することができます。
今回の検証では、LNIへアクセスする側をクライアントとしてHAクラスターを構築するため、フローティングIPリソースを使用します。

3. 検証

今回は以下の2パターンの構成でAWS Outposts サーバーの検証を実施しました。

AWS Outposts サーバー上に作成するEC2インスタンスのAMIには、2.2 ストレージの手順に沿って作成したAMIを使用します。AWS Outposts サーバー上でEC2インスタンスを作成する手順の詳細は、以下を参照ください。

【参考】

ステップ 2: Outpost 上でインスタンスを起動
https://docs.aws.amazon.com/ja_jp/outposts/latest/server-userguide/launch-instance.html#launch-instances

AWS Outposts サーバー上のEC2インスタンスへのCLUSTERPROのインストールについては、通常通りの手順でインストールしてください。
2.2 ストレージに記載したように、AWS Outposts サーバーではインスタンスストアのみが利用可能であり、OSシャットダウンを行うとEC2インスタンスがターミネートされます。
そのため、CLUSTERPROの動作で予期せぬOSシャットダウンが発生しないように、異常検出時のデフォルト動作を一括で[OS再起動]に変更します。

上記により、変更される動作の詳細は以下を参照ください。

【参考】
    CLUSTERPRO X システム構築ガイド
      ● CLUSTERPRO X 5.1 > Linux > リファレンスガイド
        → 第 2 章 パラメータの詳細
            → 2.2 クラスタプロパティ
                → 2.2.21 拡張タブ
                    → OS 停止動作を OS 再起動動作に変更する

3.1 検証① 1台のAWS Outposts サーバー上のEC2でのHAクラスターの構築

3.1.1 検証構成

検証①では、1台のAWS Outposts サーバー上に立てた2台のEC2インスタンスで、ミラーディスク型のHAクラスターの構築を検証しました。

■ HAクラスター構成サーバー

■ ネットワーク構成

■ CLUSTERPRO設定

3.1.2 検証結果

フェールオーバーグループの起動後、フローティングIPアドレスに対してクライアントからアクセス出来ること、それぞれのEC2インスタンスでフローティングIPアドレスを付与/解放できることを確認しました。また、ミラーディスクリソースによるデータのミラーリングが正常にできていることを確認しました。
異常発生時のテストとしては、ハードウェアの疑似障害(LNI LinkのNICの無効化、OS再起動)を発生させ、CLUSTERPROが異常を検出して回復動作を行うことを確認しました。

3.2 検証② 2台のAWS Outposts サーバー上のEC2でのHAクラスターの構築

3.2.1 検証構成

検証②では、2台のAWS Outposts サーバー(AWS Graviton2プロセッサ、Intel Xeonプロセッサ)それぞれに立てた2台のEC2インスタンスで、ディスクレス型のHAクラスターの構築を検証しました。

■ HAクラスター構成サーバー

■ ネットワーク構成

■ CLUSTERPRO設定

3.2.2 検証結果

フェールオーバーグループの起動後、フローティングIPアドレスに対してクライアントからアクセス出来ること、それぞれのEC2インスタンスでフローティングIPアドレスを付与/解放できることを確認しました。
異常発生時のテストとしては、ハードウェアの疑似障害(LNI LinkのLANケーブルの抜線(※)、OS再起動)を発生させ、CLUSTERPROが異常を検出して回復動作を行うことを確認しました。

まとめ

今回は、AWS Outposts サーバー上でHAクラスターの構築を検証してみました。
AWS Outposts サーバー上でも、CLUSTERPROを使用することで可用性を向上させることができます。また、AWS Outposts サーバー上でミラーディスク型クラスターを構築することで、各EC2インスタンスのインスタンスストアに保存されているデータをミラーリングすることができ、障害等で一方のEC2インスタンスでOSシャットダウンが起きた際でも正常なEC2インスタンスでデータを保持しているため、データ損失のリスクを低減することができます。

今回は検証できませんでしたが、2台のAWS Outposts サーバーそれぞれに立てた2台のEC2インスタンスでのミラーディスク型のHAクラスター構築の検証も検討中ですので、続報をお待ちください。

お問い合わせ