はじめに
InfoScale は、Azure上のWindowsでのクラスタリングを保証しています。ただし、顧客要件によって実装パターンが複数存在します。そして、InfoScaleをAzure上のWindowsに構築する場合は、以下２つのポイントに留意する必要があります。
１．どのような要件を満たすために、どのような構成のクラスターを構築するか
２．オンプレとは異なるInfoScaleの前提条件
本記事では、上記２つのポイントを中心に、Azure上でクラスタリングが必要になった場合に、要件毎の最適なソリューションと、実装上の注意点を説明します。
どのような要件を満たすために、どのような構成のクラスターを構築するか
同一サブネット内で、共有ディスクを用いたクラスター
もっとも単純なクラスター構成です。クラスタリングされたオンプレのシステムを、そのままAzureに移行する際に用います。同一サブネット内が前提ですので、同一障害ドメイン内で共有ディスク構成をとることができますし、AzureのPrivateIPをクラスターのノード間で切り替える事も可能です。Active-Standby型のクラスターで、切り替え時間が３分以上かかっても大丈夫な要件に向きます。
詳しい実装方法については、ベリタスよりホワイトペーパーが公開されています。是非こちらをご覧ください。
異なるサブネットを跨いだ、レプリケーションを用いたクラスター
Azureでは、異なるサブネットを跨いでPrivateIPを切り替える事はできません。また、異なる障害ドメインに属するインスタンス間で同じブロックストレージを共有する事もできません。このような場合のクラスタリング要求に対応するための解決策の１つが、レプリケーションとOverlayIPを併用したクラスターです。InfoScale独自のSDS機能により、各インスタンスのローカルディスクをレプリケーションし、加えてOverlayIPを使用します。この構成では、クラスターノード間のローカルディスクのデータをレプリケーションにより同期し、OverlayIPによるクライアントの要求先IPのルートテーブル変更を行う事で、サブネットだけでなくリージョン跨ぎのクラスタリングをも実現する事ができます。
詳しい実装方法については、ベリタスよりホワイトペーパーが公開されています。是非こちらをご覧ください。
オンプレとは異なるInfoScaleの前提条件
Azure上にWindowsインスタンスを構築すると、一部オンプレ上と異なる挙動になります。InfoScaleを構築する場合、その違いによって構築が上手くいかない事があります。以下の点に注視してください。
ノード間でpingが通ること
InfoScaleはインストーラー時や稼働時に、pingによる相互監視を行います。しかし、Azure上のWindows Serverはデフォルトでpingが通らない設定になっています。セキュリティグループの設定を変更してください。
NICのDHCPをoffにし、手動でIPを割り当てる事
InfoScaleは、DHCPを有効にしたNICをサポートしません。WindowsのNIC設定で、DHCPではなく手動でIPを割り振るようにしてください。
Python SDK for Azureが使用できること
InfoScaleは、クラスタリングに必要なネットワークやディスクの管理のためにPython SDK for Azureを使用して必要な制御を行います。InfoScaleがインストールされるノードにPython SDK for Azureをインストールし、IPアドレスやブロックストレージをコントロールできるようにしてください。
おわりに
如何でしたでしょうか？ 今回の記事と記事中に紹介したホワイトペーパーによって、Azure上のWindowsでクラスターを構築する際のハードルはかなり下がったのではないでしょうか？ 今回の内容は、高可用性に関する様々な顧客要件を満たすInfoScaleのほんの一部をご紹介にしたにすぎません。次回は Azure上の Windows でのストレージ管理についてご説明します！
商談のご相談はこちら
本稿からのお問合せをご記入の際には「コメント/通信欄」に#GWCのタグを必ずご記入ください。
ご記入いただきました内容はベリタスのプライバシーポリシーに従って管理されます。
その他のリンク
【まとめ記事】ベリタステクノロジーズ 全記事へのリンク集もよろしくお願いいたします。