Azure上でのマルチAZ構成による障害対策

    皆さんこんにちは、西下です。
    本日は当社の取り組みとして、Azure上でのAvailability Zone(以下、AZ)をまたいだHAクラスター構成について一足早くお伝えいたします。Azureへ基幹系の移行を検討されている方はぜひご覧ください。

    多くのシステムが影響を受けたAWSの広域障害

    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
    レイテンシ(遅延時間)
    仮想マシン障害時の影響
    AZ障害時の影響

    ※塗りつぶし部分が長所

    シングルAZのメリットはレイテンシが小さい点、デメリットはAZが全滅するような広域障害時にサービスが止まり復旧できない状況に陥ることです。一方、マルチAZのメリットは広域障害でもサービスが止まらないこと、デメリットはシングルAZに比べるとレイテンシが大きくなる点です。

    要件に応じてどちらの方法が適切かは異なります。冗長化したいシステムが数分数時間のダウンタイムなら許容できるのか、そうでないのかなど整理してみると良いでしょう。


    可用性の観点から、当社では従来からAWSについてはマルチAZのHAクラスター構成を標準としています。一方AzureについてはAZが用意されたのが比較的最近であり、マルチAZのHAクラスター構成が一般的でなかったため、AZをまたがないシングルAZの構成を標準としてきました。

    しかしAzureでもAZが浸透してきたことと、上記のAWSの広域障害後にAWS・Azure問わずマルチAZでのHAクラスター構成のご相談が増えていることから、AzureについてもLinux環境でのマルチAZ構成がサポートされました!


    それでは、AzureでのマルチAZのHAクラスター構成について構成図を交えて詳しく見て行きましょう。

    Azure上でのAZをまたいだHAクラスター構成

    サポート開始に向け、AZをまたいだHAクラスター構成は下記の2つを進めています。

    1. Windows:WSFCとDataKeeperとの組み合わせ
    2. Linux:LifeKeeperとDataKeeperとの組み合わせ ※サポート済構成

    1.Windows Server Failover ClusteringとDataKeeperの組み合わせ

    Windows Server標準のHAクラスター機能のWSFC(Windows Server Failover Clustering)と、当社のDKCE(DataKeeper for Windows Cluster Edition)とを組み合わせた構成です。

    <Windows環境の概念図>

    ※2020年5月現在、当社未サポートの構成

    DKCEは、Active/Standbyのローカルディスク(VHD)同士をブロックレベルでリアルタイムにレプリケーションすることで、論理的な共有ストレージとしてWSFCに認識されます。

    これにより本来共有ストレージが必要なWSFCをAzure上でもオンプレと同じ感覚で構築ができます。

    <DataKeeperの作り出す論理的な共有ストレージ>

     

    2.LifeKeeperとDataKeeperとの組み合わせ

    つづいて、当社製のHAクラスター製品のLinux版のLifeKeeperとDataKeeperとの組み合わせです。

    <Linux環境の概念図>

    ファイルサーバーをAZまたぎで冗長化してみた

    当社では既に、Azure上でのAZをまたいだHAクラスター構成(Windows/Linuxともに)の検証を行っています。そのうち、上記1.のWSFC+DataKeeperの構成については、当社の海外拠点で検証内容が公開されていますのでご参考ください。
    →[STEP-BY-STEP: CONFIGURING A FILE SERVER CLUSTER IN AZURE THAT SPANS AVAILABILITY ZONES](英文)

    <検証時の構成の概念図>

    ※2020年5月現在、当社未サポートの構成

    上記記事では、上図の通りクライアント(クラスターノードと同じvNetに存在する前提)からはAzureのILB(Internal Load Balancer)に一旦アクセスし、その後Activeノードにリダイレクトされる方式を採用しています。
    これはAzureの環境ではクライアントからクラスターのIPアドレスに直接接続できないためです。

    当社では従来からシングルAZ構成でこのILBを使う構成を標準としてきましたが、当記事ではAZをまたいだ構成であっても同様にILBを使った構成を前提としています。

    今後Azure上でのAZをまたいだHAクラスター構成の公式サポートに向けて準備を進めてまいりますのでご期待ください。

    関連情報

    お問合せ

    今後もLifeKeeperは、多様な環境で障害対策を実現できるよう様々なアップデートを計画しています。新たにサポートを開始した環境を利用してみたい等のご相談がありましたら、お気軽にお問い合わせください。

    SNSでもご購読できます。