はじめに
InfoScale は、Google Cloud Platform（以降GCPと記述）上のWindowsでのクラスタリングを保証しています。ただし、顧客要件によって実装パターンが複数存在します。そして、InfoScaleをGCP上のWindowsに構築する場合は、以下２つのポイントに留意する必要があります。
１．どのような要件を満たすために、どのような構成のクラスターを構築するか
２．オンプレとは異なるInfoScaleの前提条件
本記事では、上記２つのポイントを中心に、GCP上でクラスタリングが必要になった場合に、要件毎の最適なソリューションと、実装上の注意点を説明します。
どのような要件を満たすために、どのような構成のクラスターを構築するか
同一Zone内で、共有ディスクを用いたクラスター
もっとも単純なクラスター構成です。クラスターの稼働系と待機系を同じZoneに配置するので、Zone全体障害時のクラスターによるリカバリーは必要ない要件や、データ量が膨大且つ高いI/Oパフォーマンスが必要で共有ディスク構成が必須の場合に用います。同一サブネット内ですので、GCPのPrivateIPをクラスターのノード間で切り替える事も可能です。Active-Standby型のクラスターで、切り替え時間が３分以上かかっても大丈夫な要件に向きます。
この構成は、Zone全体障害時はサービス停止になるので、ベリタスとしてはあまり推奨いたしません。
異なるZoneを跨いだ、ローカルディスクの仮想ミラーリングを用いたクラスター
GCPでは、異なるZoneを跨いで単一のサブネットを構成する事ができます。従ってZone跨ぎでもPrivateIPを切り替えるクラスターは可能です。しかし、異なるZoneに属するインスタンス間で同じブロックストレージを共有する事はできません。このような場合のクラスタリング要求に対応するための解決策が、レプリケーションを用いたクラスターです。InfoScale独自のSDS機能により、各インスタンスのローカルディスクをレプリケーションします。この構成では、クラスターノード間のローカルディスクのデータをレプリケーションにより同期する事でZone跨ぎのクラスタリングを実現する事ができます。レプリケーションは同期モードと非同期モードを選択できますので、ネットワークの遅延時間や要件に応じて適切な手法を選択できます。。
詳しい実装方法については、ベリタスよりホワイトペーパーが公開されています。是非こちらをご覧ください。
オンプレとは異なるInfoScaleの前提条件
GCP上にWindowsインスタンスを構築すると、一部オンプレ上と異なる挙動になります。InfoScaleを構築する場合、その違いによって構築が上手くいかない事があります。以下の点に注視してください。
NICのDHCPをoffにし、手動でIPを割り当てる事
nfoScaleは、DHCPを有効にしたNICを使用できません。WindowsのNIC設定で、DHCPではなく手動でIPを割り振るようにしてください。
Python SDK for GCPが使用できること
InfoScaleは、クラスタリングに必要なネットワークやディスクの管理のためにPython SDK for GCPを使用してIAM経由で必要な制御を行います。InfoScaleがインストールされるノードにPython SDK for GCPをインストールし、IAM経由でIPアドレスやブロックストレージをコントロールできるようサービスアカウントの権限を設定してください。
インスタンスからIAMにアクセスできること
Python SDK for GCPを使用してIAM経由で必要な制御を行うために適切なネットワークの設定を行ってください。クラスターを構築するインスタンスにパブリックIPをアサインするのは一般的ではないので、Cloud NAT を設定する事を推奨します。
おわりに
如何でしたでしょうか？ 今回の記事と記事中に紹介したホワイトペーパーによって、GCP上のWindowsでクラスターを構築する際のハードルはかなり下がったのではないでしょうか？
商談のご相談はこちら
本稿からのお問合せをご記入の際には「コメント/通信欄」に#GWCのタグを必ずご記入ください。
ご記入いただきました内容はベリタスのプライバシーポリシーに従って管理されます。
その他のリンク
【まとめ記事】ベリタステクノロジーズ 全記事へのリンク集もよろしくお願いいたします。