目次
本記事は、下記の通り4回シリーズになっております。
（1/4）AWS EC2でWindowsクラスタ検証：共有ストレージ検討編
（2/4）AWS EC2でWindowsクラスタ検証：iSCSI共有ストレージ設定編
（3/4）AWS EC2でWindowsクラスタ検証：クラスタ構築編
（4/4）AWS EC2でWindowsクラスタ検証：動作確認編 ＜－本記事
前回までに構築したWindows Failoverクラスタ環境の動作確認を行います。
確認したいポイントは次のものです。
- 稼働系のサーバが停止した際に、待機系のサーバにクラスタが切り替わるか？
- 待機系のサーバにクラスタが切り替わった際に、クラスタやサービス用のIPアドレスが付与されるか？
- 待機系に切り替わった際に、、PCなどのサーバ外部からアクセスするユーザが、アクセス可能な状態になっているか？
まず、稼働系のサーバ: dstyo001をシャットダウンし、待機系システムに切り替えを行ってみます。
①稼働系サーバ: dstyo001をシャットダウン
下図は稼働系サーバをシャットダウンした後のクラスタ管理の画面です。各リソースの状態が、Offlineになっています。
②待機系サーバ: dstyo002でクラスタやサービスが起動された状態。サービスのIPアドレスも待機系のアドレス: 172.31.38.152に切り替わりました。
クラスタ環境が稼働系から待機系に切り替わることは確認しましたが、外部のユーザからクラスタやサービスにアクセスするには、IPアドレスではアクセスできません。クラスタ名やサービス名に関するIPアドレスが、サーバ切り替え前後で更新されている必要があります。DNSサーバの登録状況を確認してみます。
DNSサーバ登録状況の確認
①稼働系サーバ: dstyo001でサービスが動作している状態
サービス: DI_JOBSERVICEに対するアドレスが、172.31.5.167になっています。
②待機系サーバ: dstyo002でサービスが動作している状態
サービス: DI_JOBSERVICEに対するアドレスが、172.31.38.152になっています。
以上で、クラスタ切り替え時にDNSのエントリが更新されていることがわかりました。クラスタ外部からサービスにアクセスするためには、DNS検索を行うことで、アクセス先のサーバを変更することができます。
AWS上のAZ間でWindows Failoverクラスタを使用する上での注意点
異なるAZ間でのクラスタは、共通の仮想IPアドレスが使えません。動作的には、災害対策用の遠距離クラスタのような動作となります。
クラスタ切り替えを行った場合、他のシステムやクライアントが新しいIPアドレスにアクセスする必要があります。アプリケーションによっては、DNS再検索を行わないものもあり、アプリケーションの再起動が必要となる場合があります。特にERPなどのエンタープライ系のアプリケーションで、システム間連携を行っている場合は、IPアドレスが変わってしまうことの影響の方が多いかもしれません。
このような場合には、稼働系のサーバが停止した場合に単純に待機系に切り替えるのではなく、稼働系サーバの再起動で対応できる場合が多いかと思います。
- カテゴリー
この記事をシェアする
