はじめに
InfoScale は、Azure上のRHELでのクラスタリングを保証しています。ただし、顧客要件によって実装パターンが複数存在します。そして、InfoScaleをAzure上のRHELに構築する場合は、以下２つのポイントに留意する必要があります。
１．どのような要件を満たすために、どのような構成のクラスターを構築するか
２．オンプレとは異なるInfoScaleの前提条件
本記事では、上記２つのポイントを中心に、Azure上でクラスタリングが必要になった場合に、要件毎の最適なソリューションと、実装上の注意点を説明します。
どのような要件を満たすために、どのような構成のクラスターを構築するか
同一サブネット内で、共有ディスクを用いたクラスター
もっとも単純なクラスター構成です。クラスタリングされたオンプレのシステムを、そのままAzureに移行する際に用います。同一サブネット内が前提ですので、同一障害ドメイン内で共有ディスク構成をとることができますし、AzureのPrivateIPをクラスターのノード間で切り替える事も可能です。Active-Standby型のクラスターで、切り替え時間が３分以上かかっても大丈夫な要件に向きます。
詳しい実装方法については、ベリタスよりホワイトペーパーが公開されています。是非こちらをご覧ください。
異なるサブネットを跨いだ、ローカルディスクの仮想ミラーリングを用いたクラスター
Azureでは、異なるサブネットを跨いでPrivateIPを切り替える事はできません。また、異なる障害ドメインに属するインスタンス間で同じブロックストレージを共有する事もできません。このような場合のクラスタリング要求に対応するための解決策の１つが、ローカルディスクの仮想ミラーリングとOverlayIPを併用したクラスター構成です。InfoScale独自のSDS機能により、各インスタンスのローカルディスクを仮想共有してミラーリングし、その上にクラスターファイルシステムを実装し、加えてOverlayIPを使用する事で、サブネットを跨いだクラスター切り替えを可能にします。ただし、仮想ミラーリングを用いる関係上、稼働系と待機系を結ぶクラスター専用ネットワークの遅延時間は数ミリ秒以内が求められますので、リージョンを跨いだ構成は現実的ではありません。この構成では、クラスターノード間のローカルディスクのデータを仮想ミラーリングにより同期し、OverlayIPによるクライアントの要求先IPのルートテーブル変更を行う事で、サブネット跨ぎのクラスタリングを実現する事ができます。
詳しい実装方法については、ベリタスよりホワイトペーパーが公開されています。是非こちらをご覧ください。
異なるサブネットを跨いだ、レプリケーションを用いたクラスター
前述の構成では、稼働系と待機系を結ぶクラスター専用ネットワークの遅延時間に制限がありますので、リージョンを跨いだクラスターは現実的ではありません。このような場合のクラスタリング要求に対応するための解決策が、レプリケーションとOverlayIPを併用したクラスターです。InfoScale独自のSDS機能により、各インスタンスのローカルディスクをレプリケーションし、加えてOverlayIPを使用します。この構成では、クラスターノード間のローカルディスクのデータをレプリケーションにより同期し、OverlayIPによるクライアントの要求先IPのルートテーブル変更を行う事で、サブネットだけでなくリージョン跨ぎのクラスタリングをも実現する事ができます。
詳しい実装方法については、ベリタスよりホワイトペーパーが公開されています。是非こちらをご覧ください。
オンプレとは異なるInfoScaleの前提条件
Azure上にRHELインスタンスを構築すると、一部オンプレ上と異なる挙動になります。InfoScaleを構築する場合、その違いによって構築が上手くいかない事があります。以下の点に注視してください。
RHELのインスタンスにsshを用いてrootでパスワードを用いてログインできること
InfoScaleのインストール時は、1台のノードからpush installを行いますが、その際に他のノードにsshを用いてrootでパスワードを用いてログインします。Azure上でdeployされるRHELは、デフォルトでsshを用いてrootでパスワードを用いてログインできるようになっていません。//etc/passwdを変更してパスワードを用いてrootでsshができるようにしてください。
yumが使用できること
Azure上でdeployされるRHELには、InfoScaleが必要とするパッケージの幾つかがインストールされていません。そのため、InfoScaleのインストーラーの中でyumを用いて必要なパッケージをインストールします。適切なネットワークの設定（踏み台サーバーを経由してyumのサーバーにアクセス等）もしくはyumのリポジトリの設定を行い、yumが使用できるようにしてください。
Python SDK for Azureが使用できること
InfoScaleは、クラスタリングに必要なネットワークやディスクの管理のためにPython SDK for Azureを使用してIAM経由で必要な制御を行います。InfoScaleがインストールされるノードにPython SDK for Azureをインストールし、IAM経由でIPアドレスやブロックストレージをコントロールできるようにしてください。
/optに4Gbyte以上の空き領域があること
Azure上に配備されるRHELのバージョンによっては、/optファイルシステムの容量が2Gbyteしかありません。InfoScaleのインストール時は、/optファイルシステムに4Gbyte以上の空き領域が必要ですので、/optファイルシステムを拡張してください。
OSのmultiqueue scheduler を無効化すること
Azureの market place からRHEL 7.6以降を配備した場合、デフォルトでOSの multiqueue scheduler が有効になっていますが、InfoScaleはこの機能をサポートしません。InfoScaleのインストールを行う前に、以下の例に従ってmultiqueue scheduler の無効化を行い、OSを再起動してください。
おわりに
如何でしたでしょうか？ 今回の記事と記事中に紹介したホワイトペーパーによって、Azure上のRHELでクラスターを構築する際のハードルはかなり下がったのではないでしょうか？ 今回の内容は、高可用性に関する様々な顧客要件を満たすInfoScaleのほんの一部をご紹介にしたにすぎません。次回は Windows 版をお送りします！
商談のご相談はこちら
本稿からのお問合せをご記入の際には「コメント/通信欄」に#GWCのタグを必ずご記入ください。
ご記入いただきました内容はベリタスのプライバシーポリシーに従って管理されます。
その他のリンク
【まとめ記事】ベリタステクノロジーズ 全記事へのリンク集もよろしくお願いいたします。