ハイブリッド クラウドのコンピューティング ワークロード
注意事項
このコンテンツでは、サービス終了 (EOL) 状態の Linux ディストリビューションである CentOS について説明します。 適宜、使用と計画を検討してください。 詳細については、「CentOS のサポート終了に関するガイダンス」を参照してください。
Tailwind Traders には、シドニー、メルボルン、オークランドのデータセンター全体で、物理サーバー、仮想マシン (VM)、またはコンテナーとして実行しているコンピューティング ワークロードが混在しています。 これらのワークロードでは、プライマリ仮想化プラットフォームとして Hyper-V を構成して、Windows Server と Linux の組み合わせを実行しています。
この多様な一連のオペレーティング システムを管理することは、Tailwind Traders にとってすでに課題となっています。 この会社では、ハイブリッド体制に移行してオンプレミスとクラウドの両方でワークロードが実行すると、サーバー オペレーティング システムのワークロードとそれらのコンプライアンスの状態を把握することがさらに困難になるのではないかと懸念しています。
Tailwind Traders では、この数年間、Microsoft のハイ パフォーマンス コンピューティング (HPC) パックを使用して、エンジニアリング関連の一連の設計タスク用としてシドニーのデータセンターにある 16 ノードのコンピューティング クラスターを管理しています。 これらの計算が発生するのは、1 年のうちほんの短い期間だけです。 しかし、計算が複雑になるにしたがって、これらの計算に要する時間は長くなっています。
Tailwind Traders は、コンテナーを、仮想マシンでホストさせるのではなく、新しいアプリケーションのプライマリ プラットフォームとして使用することを計画しています。 同社は、ハイブリッド環境でコンテナーを調整できるプラットフォームに関心を持っています。
このユニットでは、ハイブリッド環境でコンピューティング ワークロードをサポートするさまざまな方法について学習します。
Azure Arc 対応サーバーとは
Azure Arc 対応サーバーを使用すると、組織は Azure 外部のネットワーク上の Windows および Linux サーバーを管理できます。 この機能には、組織の内部ネットワークでホストされているサーバーと、サードパーティ クラウド IaaS インフラストラクチャでホストされているサーバーが含まれます。
Azure Arc を使用してコンピューターを Azure にハイブリッド接続し、Azure Arc 対応サーバーのエージェントをインストールすると、サーバーを Azure リソースとして扱うことができます。 その後、サーバーをサブスクリプション内のリソース グループの一部として管理できます。 また、タグの適用だけでなく、構成および管理に関する Azure Policy も適用できます。
Azure Arc 対応サーバーのエージェントでは、次の Windows および Linux オペレーティング システムがサポートされています。
- Windows Server 2008 R2 SP1、2012 R2、2016、2019、2022
- Desktop と Server Core の両方のエクスペリエンスをサポート
- Azure Stack HCI で Azure のエディションをサポート
- Windows 10、11 (クライアント オペレーティング システムのガイダンスを参照)
- Windows IoT Enterprise
- Azure Stack HCI
- Ubuntu 16.04、18.04、20.04、および 22.04 LTS
- Debian 10 および 11
- CentOS Linux 7 および 8
- Rocky Linux 8
- SUSE Linux Enterprise Server (SLES) 12 SP3-SP5 および 15
- Red Hat Enterprise Linux (RHEL) 7、8、9
- Amazon Linux 2
- Oracle Linux 7 および 8
x86-64 (64 ビット) アーキテクチャのみがサポートされています。
Azure Arc 対応サーバーのエージェントでは、次の機能がサポートされています。
- Azure Policy のゲスト構成機能を使用すると、オペレーティング システムの構成を検証できます。
- Azure Monitor Log Analytics データのリソース コンテキストにより、Azure のロールベースのアクセス制御 (RBAC) を使用して、サーバー テレメトリにアクセスできるユーザーの範囲を制限できます。
ハイブリッド環境内のコンピューターに Azure Arc 対応サーバーのエージェントをデプロイする際に含まれる機能は進化しています。 最新情報については、Azure Arc でサポートされているクラウド運用と Azure Arc 対応サーバーの新機能に関する記事を参照してください。
Tailwind Traders の場合、ハイブリッド環境全体の Windows Server と Linux のワークロードを 1 か所で管理することにより、ハイブリッド環境の複雑さに関する運用チームの懸念の一部が解消されます。
Azure Stack HCI とは
Azure Stack HCI は、Windows および Linux オペレーティング システムを実行している Hyper-V 仮想マシンをホストするために使用できるハイパーコンバージド インフラストラクチャ オペレーティング システムです。 ハイパーコンバージド Windows Server Hyper-V クラスターで実行する場合とは異なり、Azure Stack HCI は、Azure portal または Windows Admin Center を介して仮想マシンをデプロイおよび管理するオプションを提供するように設計されています。
ローカルの運用チームがホスト オペレーティング システムの管理責任を担う従来の Windows Server 仮想化デプロイとは異なり、Azure Stack HCI は Azure サービスです。 お客様は、承認されたベンダーから検証済みのハードウェア構成を取得して、インターネットに接続されたネットワークにシステムを接続します。インフラストラクチャは、Azure サービスによって管理されます。 Azure Automation Update Management、Azure Site Recovery、Azure Backup などの Hybrid Azure サービスは自動的に統合されます。
Tailwind Traders の場合、Azure Stack HCI により、将来のプラットフォームが提供され、最終的には、そこにオンプレミスの仮想マシンを移行することができます。 この移行により、ハイブリッド環境内のすべての VM に対して、一貫した管理ツール セットを使用できるようになります。
ハイブリッド ハイパフォーマンス コンピューティングとは
ハイパフォーマンス コンピューティングでは、多数の CPU または GPU を使用して、特定の科学および工学計算などの複雑な数学タスクを実行します。 これらの CPU や GPU を同じコンピューターに接続するのではなく、HPC では、制御コンピューターが、ノードとして Windows および Linux オペレーティング システムを実行している個別のコンピューターにタスクを割り当てて、大規模で反復的なコンピューティング計算の個別のセグメントを実行する配置が使われます。 HPC クラスター内のノードが多いほど、HPC クラスターの計算速度は速くなります。
既存のオンプレミスの HPC ソリューションがある組織では、そのソリューションを Azure に接続できます。 この構造により、クラウドにバーストできます。 クラウドにバーストするには、既存のオンプレミス HPC ノード デプロイにクラウドベースの HPC ノードを追加する必要があります。 このアプローチを使用すると、必要に応じて、Azure で HPC コンピューティング ノードをインスタンス化して計算タスクを実行し、タスクが完了したら、そのノードを破棄することができます。
次の図は、クラウドへのバーストを示しています。
HPC 計算をクラウドにバーストできることで、組織は一般的な HPC タスク用に最少限のハードウェアをオンプレミスで保守できます。 その後、計算のメリットによって出費が妥当であると証明されれば、組織は必要に応じて追加のノードをデプロイできます。
Tailwind Traders にはすでに HPC のデプロイがあります。 しかし、この会社では、複雑な計算を実行するための容量が、物理および仮想環境内で HPC タスクに割り当てることができるコンピューティング リソースの量によって制限されています。 Tailwind Traders では、ハイブリッド HPC アプローチを採用することで、必要に応じて HPC 容量をスケーリングできるようになり、オンプレミス ノードを追加するためにハードウェアを購入する必要がなくなります。
Azure Arc 対応 Kubernetes とは
Azure Arc 対応 Kubernetes により、Kubernetes クラスターをアタッチして、Azure portal 経由で管理できるように構成できます。 Azure Arc 対応 Kubernetes を使用すると、次のことができます。
- Azure の外部で実行されている Kubernetes クラスターに接続して、インベントリ、グループ化、タグ付けのタスクを実行する。
- GitOps ベースの構成管理を使用して、アプリケーションをデプロイし、構成を Azure Arc 対応 Kubernetes クラスターに適用する。
- コンテナーに Azure Monitor を使用して、ハイブリッド環境の Kubernetes クラスターを確認し、監視する。
- Kubernetes ポリシー用の Azure Policy をハイブリッド環境の Kubernetes クラスターに適用する。
Azure Arc 対応 Kubernetes は、すべての Cloud Native Computing Foundation (CNCF) 認定 Kubernetes クラスターで動作します。 次の図に示すように、Azure Arc 対応 Kubernetes を使用すると、組織はハイブリッド環境でオンプレミスとクラウドの両方の Kubernetes クラスターを管理できます。
Azure Arc for Kubernetes を使用することの Tailwind Traders のメリットは、単一のツール セットを使用して Kubernetes クラスターを管理できることです。 また、ハイブリッド環境全体で一貫した方法で、それらの Kubernetes クラスターを構成し、セキュリティで保護することもできます。
Azure Arc 対応データ サービスとは
Azure Arc 対応データ サービスを使用すると、組織は、1 つのツール セットを使用して、Azure とオンプレミスで実行されているサポート対象のデータベースを管理できます。 組織は、Azure Arc 対応データ サービスを使用して、Azure Data Studio、Azure portal、または Azure CLI を介して SQL マネージド インスタンスを管理しながら、Azure Database for PostgreSQL サーバーとそれらのインスタンスをオンプレミスで実行できます。
Azure Arc 対応データ サービスが有効な場合、Azure に PostgreSQL および SQL マネージド インスタンスをデプロイすると、このサービスを使用することにより、これらのオンプレミス データベース インスタンスのパッチおよび更新のプロセスを、Microsoft がそれらのプロセスを管理するのと同じ方法で自動化できます。 さらに、Azure Arc 対応データ サービスにより、組織は、Azure SQL データベース用 Microsoft Defender for Cloud で利用できる、脅威に対する高度な保護機能を、オンプレミスで実行されているデータベース サーバー インスタンスに適用することもできます。
Azure Arc 対応データ サービスでは、オンプレミスのサービスに、コンテナーと Kubernetes インフラストラクチャを使用します。 また、Azure Arc 対応データ サービスを使用すると、これらのオンプレミス データ サービスと、Azure Backup などの Azure サービスを統合することもできます。
Tailwind Traders の観点から見ると、Azure Arc 対応データ サービスを使用することにより、現在のデータベース ワークロードの一部を別の方法で実行することができます。 同社は、オンプレミスのデータベースの一部を Azure Arc 対応データ サービスに移行できます。 この移行により、これらのインスタンスの管理とセキュリティに関する運用チームの懸念は軽減されます。
Azure Site Recovery とは
Azure Site Recovery を使用すると、組織は、物理および仮想オペレーティング システムと、それらがホストするワークロードを Azure クラウド プラットフォームにレプリケートすることにより、ディザスター リカバリー サイトを置き換えることができます。 Azure Site Recovery により、Azure へのフェールオーバーが可能になります。 Azure Site Recovery を使用すると、Azure からオンプレミスのデータセンターへのワークロードのフェールバックを実行できます。
次の図は、基本的な Azure Site Recovery 構成を示しています。
Azure Site Recovery により、Tailwind Traders は、デプロイがハイブリッドになったときに、オンプレミスのみの実装でメルボルンとシドニーのデータセンターをディザスター リカバリー サイトとして使用していた方法から、Azure を多数のワークロードのディザスター リカバリー サイトとして使用する方法に移行できます。 Tailwind Traders の課題は、一部のワークロードで、Azure への移行の妨げとなっている物理的またはその他の依存関係があることです。 同じ理由から、同社は Azure をディザスター リカバリー サイトとして使用することができません。