AKS on Azure Stack HCI でのアプリケーションの可用性

AKS on Azure Stack HCI は、Kubernetes 上でクラウドネイティブ アプリケーションを実行できる、完全にサポートされたコンテナー プラットフォームです。これは、Kubernetes コンテナー オーケストレーション プラットフォームに基づいています。 このアーキテクチャを使用すると、Azure Stack HCI および Windows Server 2019 Datacenter 上で、仮想化された Windows および Linux ワークロードを実行できます。

AKS on Azure Stack HCI の現在のアーキテクチャはフェールオーバー クラスタリングを使用して構築されており、ターゲット (ワークロード) クラスターに対してライブ マイグレーションが自動的に有効になります。 さまざまな中断イベントの際に、アプリケーションのダウンタイムが認識されることなく、顧客のワークロードをホストする仮想マシンを自由に移動できます。 これは、レガシ アプリケーションをシングルトンとして AKS on Azure Stack HCI にリフトアンドシフトしている従来の企業のお客様が、VM でレガシ アプリケーションを実行しているときに現在経験しているのと同様の (またはより優れた) 稼働時間を実現できることを意味します。

このトピックでは、中断中にアプリケーションを使用できるようにライブ マイグレーションが有効になった AKS on Azure Stack HCI 上で、コンテナー化されたアプリケーションを実行する必要があるユーザー向けに、基本的な概念について説明します。 "自発的中断" や "不本意なの中断" といった Kubernetes 用語は、ポッドで実行されているアプリケーションのダウンタイムのことを指すために使用されます。

ライブ マイグレーションとは

ライブ マイグレーションは、ダウンタイムを発生させることなく、実行中の仮想マシンを Hyper-V ホスト間で透過的に移動できるようにする Hyper-V 機能です。 ライブ マイグレーションの主な利点は柔軟性です。実行中の仮想マシンは、1 つのホスト マシンに関連付けられていません。 このため、ホストの使用停止またはアップグレードの前に、バーチャル マシンの特定ホストのドレインといった操作を実行できます。 ライブ マイグレーションを Windows フェールオーバー クラスタリングと組み合わせることにより、可用性が高くフォールト トレラントなシステムを作成できます。

AKS on Azure Stack HCI の現在のアーキテクチャは、お客様が Azure Stack HCI クラスター環境でライブ マイグレーションを有効にしていることを前提としています。 この場合、すべての Kubernetes ワーカー ノード VM は、ライブ マイグレーションが構成された状態で作成されます。 これらのノードは中断が発生したときに物理ホスト間で移動できるため、プラットフォームの高可用性を確保することができます。

フェールオーバー クラスタリングが有効になっている AKS on Azure Stack HCI を示す図

Kubernetes 上でシングルトンとしてレガシ アプリケーションを実行しているお客様の場合、このアーキテクチャによって高可用性のニーズが満たされます。 Kubernetes は、使用可能なワーカー ノードでポッドのスケジュールを管理しますが、ライブ マイグレーションは使用可能な物理ホスト上でワーカー ノード VM のスケジュールを管理します。

シングルトンとして実行されているレガシ アプリケーションの例を示す図

アプリケーションの中断のシナリオ

VM と AKS on Azure Stack HCI で実行されているアプリケーションの復旧時間を比較することで、一般的な中断イベントが発生した場合にアプリケーションへの影響が最小限に抑えられることが明らかになります。 中断シナリオの例を以下に 3 つ示します。

  • 物理マシンの再起動を伴う更新プログラムの適用。
  • ワーカー ノードの再作成を伴う更新プログラムの適用。
  • 予期せぬ物理マシンのハードウェア障害。

注意

これらのシナリオでは、アプリケーション所有者が、ワーカー ノード間でポッドを適切にスケジュールできるように、引き続き Kubernetes のアフィニティおよびアンチアフィニティ設定を使用することを前提としています。

中断イベント AKS on Azure Stack HCI での VM のアプリケーションの可用性 AKS on Azure Stack HCI でのアプリケーションの可用性
物理マシンの再起動を伴う更新プログラムの適用 影響なし 影響なし
ワーカー ノードの再作成 (または VM の再起動) を伴う更新プログラムの適用 影響なし 場合により異なる
予期せぬ物理マシンのハードウェア障害 6 から 8 分 6 から 8 分

物理マシンの再起動を伴う更新プログラムの適用

物理ホストのメンテナンス イベント (ホスト マシンの再起動が発生する、更新プログラムの適用など) 中に、クラスターで実行されているアプリケーションに影響が生じることはありません。 クラスター管理者は、ホストをドレインし、更新プログラムの適用前にすべての VM を確実にライブ マイグレーションすることができます。

ワーカー ノードの再作成を伴う更新プログラムの適用

このシナリオでは、定期的なメンテナンスを実行するために、ワーカー ノードの VM を停止する必要があります。 更新を準備するために、クラスター管理者はノードをドレインして分離します。これにより、更新プログラムを適用する前に、すべてのポッドが削除され使用可能なワーカー ノードに移動されます。 更新が完了すると、ワーカー ノードが再度参加し、スケジュールに使用できるようになります。

注意

アプリケーションの可用性は、基本コンテナー イメージ (特に、パブリック クラウドに格納されている大規模なイメージの場合) のダウンロードにかかる時間が含まれるため、さまざまです。 そのため、小規模な基本コンテナー イメージを使用することをお勧めします。また、Windows コンテナーの場合は、nano server 基本イメージの使用が推奨されます。

予期せぬ物理マシンのハードウェア障害

このシナリオでは、ワーカー ノード VM の 1 つでレガシ アプリケーション コンテナーまたはポッドをホストしている物理マシンに非自発的な中断イベントが発生します。 フェールオーバー クラスタリングはホストを分離された状態にしてから 6 から 8 分後に、存続しているホストにこれらの VM をライブ マイグレーションするプロセスを開始します。 この場合、アプリケーションのダウンタイムは、ホストとワーカー ノードの VM の再起動にかかる時間になります。

まとめ

AKS on Azure Stack HCI とフェールオーバー クラスタリング テクノロジはどちらも、コンピューティング環境の高可用性とフォールト トレランスを確保できるように設計されています。 ただし、中断シナリオにおいてポッドの回復性を確保するためには、アプリケーション所有者は、DeploymentsAffinity MappingRelicaSets などの Kubernetes 機能を使用するようにデプロイを構成する必要があります。