Azure VM の可用性を管理する
多くの場合、サービス企業の成功は、企業がその顧客と締結するサービス レベル アグリーメント (SLA) に直接関連します。 あなたのお客様は企業が提供するサービスが常に利用できること、自分のデータが安全に守られることを期待しています。 Microsoft はこのセキュリティを真剣に受け止めています。 顧客が会社のサービスをいつでも利用できるように、Azure では、可用性、データ セキュリティ、監視を管理するためのツールが提供されます。
Azure VM の管理は、VM で実行されるオペレーティング システムまたはソフトウェアの管理に限定されません。 サービスの可用性を確保し、自動化を支援する Azure サービスを把握する上で役立ちます。 このようなサービスは、事業継続とディザスター リカバリーの方針を計画するときに便利です。
ここでは、VM 可用性の改善、VM 管理タスクの合理化、VM データのバックアップとセキュリティを支援する Azure サービスを紹介します。 可用性の定義から始めましょう。
可用性とは何ですか?
可用性とは、あるサービスを利用できる時間の割合です。
あなたは Web サイトを所有していて、顧客が情報にいつでもアクセスできるようにするとします。 あなたは Web サイトのアクセスについて、100% の可用性を期待しています。
Azure を使用するとき、なぜ可用性について考慮する必要があるのでしょうか?
Azure VM は Azure データ センター内でホストされている物理サーバー上で実行されます。 多くの物理デバイスと同様に、故障が発生する可能性があります。 物理サーバーが故障した場合、そのサーバーでホストされている仮想マシンも停止します。 障害が発生した場合、Azure では、VM が正常なホスト サーバーに自動的に移動されます。 ただし、この自己修復移行には数分かかることがあり、その間、その VM でホストされているアプリケーションが利用できなくなります。
また、Azure 自身が開始する定期的な更新も VM に影響を与える可能性があります。 このような保守管理イベントはソフトウェアの更新からハードウェア アップグレードにまでわたりますが、プラットフォームの信頼性とパフォーマンスを改善することが必要です。 そうしたイベントは通常、ゲスト VM に影響を与えることなく実行されますが、更新またはアップグレードを完了するために仮想マシンが再起動することがあります。
可用性ゾーン
可用性ゾーンは、VM 上のアプリケーションとデータの可用性を維持するための制御レベルを拡張します。 可用性ゾーンとは、Azure リージョン内の物理的に独立したゾーンのことです。 サポートされている Azure リージョンごとに 3 つの可用性ゾーンがあります。
可用性ゾーンはそれぞれ異なる電源、ネットワーク、および冷却装置を持ちます。 複数のゾーンにレプリケートされた VM を使用するソリューションを設計することで、1 つのデータセンターで障害が発生してもアプリケーションとデータを保護することができます。 1 つのゾーンが侵害された場合、レプリケートされたアプリとデータが別のゾーンですぐに利用可能になります。
Virtual Machines スケール セット
Azure Virtual Machine スケール セットでは、負荷分散が行われる VM のグループを作成して管理することができます。 需要または定義されたスケジュールに応じて、VM インスタンスの数を自動的に増減させることができます。 スケール セットは、アプリケーションの高可用性を実現します。また、多数の VM の一元的な管理、構成、更新を可能にします。 スケール セット自体にはコストはかかりません。料金は、作成した各 VM インスタンスに対してのみ発生します。
スケール セット内の仮想マシンは、複数の可用性ゾーン、1 つの可用性ゾーン、またはリージョンにデプロイすることもできます。 可用性ゾーンのデプロイ オプションは、.オーケストレーション モードによって異なる場合があります。
Load Balancer
Azure Load Balancer と可用性ゾーンまたは可用性セットを結合することで、アプリケーションの回復性を最大化できます。 Azure Load Balancer は、複数の仮想マシンにトラフィックを振り分けます。 Microsoft の標準層の仮想マシンには Azure Load Balancer が含まれています。 すべての仮想マシン層に Azure Load Balancer が含まれているわけではありません。 仮想マシンの負荷分散の詳細については、Linux または Windows の仮想マシンの負荷分散に関する記事をご覧ください。
Azure Storage の冗長性
Azure Storage では、計画されたイベントや計画外のイベント (一時的なハードウェア障害、ネットワークの停止や停電、大規模な自然災害など) から保護するため、常にデータの複数のコピーが格納されます。 冗長性を確保することで、障害が発生した場合でも、ストレージ アカウントが可用性と耐久性に関する目標を確実に達成できます。
ご自身のシナリオに最適な冗長性オプションを決定する際には、低コストと高可用性のトレードオフを検討してください。 どの冗長性オプションを選択するかの判断に役立つ要因は次のとおりです。
- プライマリ リージョンでのデータのレプリケート方法
- 地域災害から保護するため、プライマリ リージョンから地理的に離れている 2 番目のリージョンにデータをレプリケートするかどうか
- プライマリ リージョンが何らかの理由で使用できなくなった場合に、アプリケーションがセカンダリ リージョンのレプリケートされたデータへの読み取りアクセスを必要とするかどうか
詳細については、「Azure Storage の冗長性」を参照してください。
場所間でのフェールオーバー
サイト間でインフラストラクチャを複製し、リージョン内でフェールオーバーすることもできます。 Azure Site Recovery では、プライマリ サイトからセカンダリの場所にワークロードが複製されます。 プライマリ サイトで停電が発生した場合、セカンダリの場所にフェールオーバーできます。 このフェールオーバーにより、中断なく、引き続きアプリケーションにアクセスできます。 その後、再び起動し実行されたら、プライマリの場所にフェールバックできます。 Azure Site Recovery の目標は仮想マシンまたは物理マシンの複製にあります。停電時、ワークロードの可用性を維持します。
Site Recovery には優れた技術的特徴がいろいろありますが、ビジネスにおいては利点が少なくとも 2 つあります。
Site Recovery を利用すれば、Azure を復元先として利用できます。そのため、第二の物理データセンターを保守するためのコストと煩雑さから解放されます。
Site Recovery では、運用環境に影響を与えることなく、復旧演習でフェールオーバーを極めてシンプルにテストできます。 この機能により、計画済みまたは計画外のフェールオーバーを簡単にテストできます。 結局のところ、フェールオーバーを試したことがなければ、良いディザスター リカバリーを計画できません。
Site Recovery で作成した復元計画は、シナリオで求められるなら、シンプルにも複雑にもすることができます。 計画にはカスタム PowerShell スクリプト、Azure Automation Runbook、手動介入手順を含めることができます。 復旧計画を使ってワークロードを Azure にレプリケートすることで、移行、急増期間中の一時的なバースト、または新しいアプリケーションの開発およびテストなどの新しい機会を容易に実現できます。
Azure Site Recovery は、Azure リソース、またはオンプレミス インフラストラクチャの Hyper-V、VMware、物理サーバーと連携します。 プライマリの場所に障害が発生した場合、ワークロードやアプリケーションのレプリケーション、フェールオーバー、復旧を調整することで、組織の事業継続とディザスター リカバリー (BCDR) 戦略の重要な部分となります。