Help us understand the problem. What is going on with this article?

AWS上の Windows で InfoScale を用いてクラスタリングしよう

はじめに

InfoScale は、AWS上のWindowsでのクラスタリングを保証しています。ただし、顧客要件によって実装パターンが複数存在します。そして、InfoScaleをAWS上のWindowsに構築する場合は、以下2つのポイントに留意する必要があります。
1.どのような要件を満たすために、どのような構成のクラスターを構築するか
2.オンプレとは異なるInfoScaleの前提条件
本記事では、上記2つのポイントを中心に、AWS上でクラスタリングが必要になった場合に、要件毎の最適なソリューションと、実装パターン毎の注意点を説明します。

どのような要件を満たすために、どのような構成のクラスターを構築するか

同一AZ内で、共有ディスクを用いたクラスター
もっとも単純なクラスター構成です。クラスタリングされたオンプレのシステムを、そのままAWSに移行する際に用います。同一AZ内ですので、共有ディスク構成をとることができますし、AWSのPrivateIPをクラスターのノード間で切り替える事も可能です。AZの障害を考慮しないActive-Standby型のクラスター要件に向きます。

aws_privateip.jpg
詳しい実装方法については、ベリタスよりホワイトペーパーが公開されています。是非こちらをご覧ください。

AZを跨いだクラスター
AWSのAZ障害に対応するためには、AZを跨いで複数のWindowsインスタンスを配置し、それらをクラスタリングする必要があります。このような場合、subnetが分かれますのでPrivateIPを切り替える事ができません。また、EBSを切り替える事もできません。従って、オンプレで通用していた従来のクラスタリング手法(最初に紹介した手法)は使用できません。しかし、InfoScaleのレプリケーション機能とOverlayIP機能を使用する事で、これらの問題を解決する事ができます。下記の構成では、クラスターノード間のローカルディスクのデータをレプリケーションし、AWSと連携してクライアントの要求先IPのルートテーブルを変更する事で、AZ跨ぎのクラスタリングを実現する事ができます。
aws_overlayip.jpg

詳しい実装方法については、ベリタスよりホワイトペーパーが公開されています。是非こちらをご覧ください。

オンプレとは異なるInfoScaleの前提条件

Windows OS構築時の注意点
AWS上にWindowsインスタンスを構築すると、一部オンプレ上と異なる挙動になります。InfoScaleを構築する場合、その違いによって構築が上手くいかない事があります。以下の点に注視してください。

ノード間でpingが通ること: InfoScaleはインストーラー時や稼働時に、pingによる相互監視を行います。しかし、AWS上のWindowsはデフォルトでpingが通らない設定になっています。セキュリティグループの「インバウンドの設定」を変更し、pingが通るようにしてください。

ハートビート用ネットワークとして2つのNICを持ち、そのNICに割り当てられたIPが、指定された2つのport(デフォルトは50000と50001だが変更も可能)経由で通信可能なこと: InfoScaleのクラスターハートビート用に2つのNICが必要です。サービス用のネットワークとは別のハートビート専用ネットワークを構築し、そこにサーバー毎に2つのNICを割り当ててください。2つのNICにはIPアドレスを割り当て、それぞれ必要なPort(デフォルトは50000とPort50001)で通信できるよう、AWSのネットワークやWindowsのFirewallを調整してください。

NICのDHCPをoffにし、手動でIPを割り当てること: InfoScaleは、DHCPを有効にしたNICをサポートしません。WindowsのNIC設定で、DHCPではなく手動でIPを割り振るようにしてください。

AWS関連の注意点と推奨事項
AWS上のWindowsをInfoScaleでクラスタリングする場合、AWSCLIの使用が必須です。その際、以下の点に注意してください。

AWSCLIをconfigureする際は、「Default output format」は、必ず「json」にしてください。「json」以外では、InfoScaleはAWSCLIと連携できません。
AWSCLI.jpg

InfoScaleがインストールされたノードからAWSCLIを使用する際、セキュリティの観点から、クラスターの動作に必要な機能のみが可能になるべきです。その為に、ポリシーとIAMロールを作成し、それをInfoScaleがインストールされたノード(インスタンス)に割り当てる事を推奨します。AWSCLIをconfigureする際に Access Key と Secret Key を入力する事で、ポリシーとIAMロール関係の作業を省略できますが、セキュリティの観点から、推奨できません。

おわりに

如何でしたでしょうか? 今回の記事と記事中に紹介したホワイトペーパーによって、AWS上のWindowsでクラスターを構築する際のハードルはかなり下がったのではないでしょうか? 今回の内容は、高可用性に関する様々な顧客要件を満たすInfoScaleのほんの一部をご紹介にしたにすぎません。次回は、クラスタリングした後でファイルシステムの拡張が必要になった場合の対応策(RHEL編)をお送りします!

商談のご相談はこちら

本稿からのお問合せをご記入の際には「お問合せ内容」に#GWCのタグを必ずご記入ください。ご記入いただきました内容はベリタスのプライバシーポリシーに従って管理されます。

Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Comments
Sign up for free and join this conversation.
If you already have a Qiita account
Why do not you register as a user and use Qiita more conveniently?
You need to log in to use this function. Qiita can be used more conveniently after logging in.
You seem to be reading articles frequently this month. Qiita can be used more conveniently after logging in.
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away