
皆さんこんにちは、西下です。
Azure上でのAvailability Zone(以下、AZ)をまたいだHAクラスター構成についてお伝えいたします。Azureへ基幹系システムの移行を検討されている方はぜひご覧ください。
多くのシステムが影響を受けたAWSの広域障害
2019年8/23に発生したAWSの広域障害では、多くの影響が出ました。
当社でも複数のブログ記事を公開しています。
→[【AWS重大障害発生!!】持続するビジネスに必要なこと]
→[クラウドの障害対策4つの方法と最も信頼性のある構成とは?]
広域障害の発生時には、障害の影響が隔離されるAZを跨いだ復旧が有効です。
さらに、障害の検知から切り替えまでを自動的に行うことのできるHAクラスター構成の活用が最も効果的といえます。
実際、当社の標準構成であるAZを跨いだHAクラスターソリューションをお使いのお客様は、障害の影響を受けていないという報告をいただいています。
ということで、まずはシングルAZとマルチAZの違いについて学んでみましょう。
シングルAZとマルチAZの違いって?
シングルAZでは一つのAvailability Zone(=AZ)にHAクラスターが構成され、マルチAZは複数のAZに配置されています。図解すると下記のようになります。
点線がAZです。シングルAZは稼働系VM(左)と待機系VM(右)が同じAZに配置されています。一方、マルチAZは稼働系VMと待機系VMが異なるAZに配置されています。
それでは、シングルAZ構成とマルチAZ構成の相違点について考えてみましょう。
シングルAZ | マルチAZ | |
レイテンシ(遅延時間) | 小 | 中 |
仮想マシン(VM)障害時の影響 | 小 | 小 |
AZ障害時の影響 | 大 | 小 |
※塗りつぶし部分が長所
シングルAZのメリットはレイテンシが小さい点です。デメリットはAZ障害のような広域障害時にサービスが止まり復旧できない状況に陥ることです。一方、マルチAZのメリットは広域障害でもサービスが止まらない点です。デメリットはシングルAZに比べるとレイテンシが若干大きくなる点です。
要件に応じてどちらの方法が適切かは異なります。冗長化したいシステムが数時間のダウンタイムなら許容できるのか、それとも許容できないのかの検討が必要となります。例えばJP1・HULFT・SAPといった基幹系のソフトウェアの場合、最小限の時間での復旧が求められることが多いと思います。この場合、マルチAZ構成が選択肢に入るでしょう。
それでは、AzureでのマルチAZのHAクラスター構成について構成図を交えて詳しく見て行きましょう。
Azure上でのマルチAZ HAクラスター構成
Azure環境では、AZを跨いだHAクラスター構成は下記の3つがサポートされています。
- Linux:LifeKeeperとDataKeeperとの組み合わせ
- Windows:LifeKeeperとDataKeeperとの組み合わせ
- Windows:WSFC(Windows Server Failover Clustering)とDataKeeperとの組み合わせ
1&2. LifeKeeperとDataKeeperの組み合わせ(Linux・Windows共通)
当社製のHAクラスター製品のLifeKeeperとデータレプリケーション製品のDataKeeperを組み合わせた構成です。
3.Windows Server Failover ClusteringとDataKeeperの組み合わせ
Windows Server標準のHAクラスター機能のWSFC(Windows Server Failover Clustering)と、当社のDKCE(DataKeeper for Windows Cluster Edition)とを組み合わせた構成です。
DKCEは、Active/Standbyのローカルディスク(VHD)同士をブロックレベルでリアルタイムにレプリケーションすることで、論理的な共有ストレージとしてWSFCに認識されます。
下の図を見ると、DataKeeperのミラー領域が論理的な共有ディスクとしてWSFCに認識されていることがわかります。これにより、Azure上でも本来共有ストレージが必要なWSFCをオンプレと同じ感覚で構築することが可能になります。
さいごに
今後もLifeKeeperは、多様な環境で障害対策を実現できるよう様々なアップデートを計画しています。新たにサポートを開始した環境を利用してみたい等のご相談がありましたら、お気軽にお問い合わせください。