次の方法で共有

Azure Stack Hub 統合システムのデータセンター統合計画に関する考慮事項

  • [アーティクル]

Azure Stack Hub 統合システムに関心がある場合は、デプロイに関する主要な計画上の考慮事項と、システムがデータセンターにどのように適合するかを理解する必要があります。 この記事では、Azure Stack Hub 統合システムのインフラストラクチャに関する重要な決定を行う際に役立つ、これらの考慮事項の概要について説明します。 これらの考慮事項を理解することは、OEM ハードウェア ベンダーが Azure Stack Hub をデータセンターにデプロイする際に役立ちます。

手記

Azure Stack Hub 統合システムは、承認されたハードウェア ベンダーからのみ購入できます。

Azure Stack Hub をデプロイするには、デプロイを開始する前に計画情報をソリューション プロバイダーに提供して、プロセスを迅速かつ円滑に進める必要があります。 必要な情報は、ネットワーク、セキュリティ、ID に関する情報の範囲であり、さまざまな分野や意思決定者の知識を必要とする可能性がある多くの重要な意思決定を行います。 展開前にすべての必要な情報を準備するには、組織内の複数のチームのユーザーが必要です。 役に立つアドバイスがある可能性があるため、この情報を収集する際にハードウェア ベンダーと話をするのに役立ちます。

必要な情報を調査して収集する際に、ネットワーク環境にデプロイ前の構成の変更を加える必要がある場合があります。 これらの変更には、Azure Stack Hub ソリューションの IP アドレス空間の予約や、新しい Azure Stack Hub ソリューション スイッチへの接続を準備するためのルーター、スイッチ、ファイアウォールの構成が含まれる場合があります。 計画に役立つ対象領域の専門家が揃っていることを確認します。

容量計画に関する考慮事項

Azure Stack Hub ソリューションを取得用に評価するときは、Azure Stack Hub ソリューションの全体的な容量に直接影響するハードウェア構成の選択を行います。 これには、CPU、メモリ密度、ストレージ構成、全体的なソリューション スケール (サーバーの数など) の従来の選択肢が含まれます。 従来の仮想化ソリューションとは異なり、これらのコンポーネントを単純に計算して使用可能な容量を特定することは適用されません。 最初の理由は、Azure Stack Hub がソリューション自体内でインフラストラクチャまたは管理コンポーネントをホストするように設計されていることです。 2 つ目の理由は、ソリューションの容量の一部が、テナント ワークロードの中断を最小限に抑えるようにソリューションのソフトウェアを更新することで、回復性をサポートするために予約されていることです。

Azure Stack Hub Capacity Planner スプレッドシート は、2 つの方法で容量を計画するための情報に基づいた意思決定を行うのに役立ちます。 1 つ目は、ハードウェア オファリングを選択し、リソースの組み合わせを調整することです。 2 つ目は、Azure Stack Hub をサポートできる使用可能なハードウェア SKU を表示するために実行するワークロードを定義することです。 最後に、このスプレッドシートは、Azure Stack Hub の計画と構成に関連する意思決定を行う際に役立つガイドとして意図されています。

スプレッドシートは、独自の調査と分析の代わりに使用するためのものではありません。 Microsoft は、スプレッドシート内で提供される情報に関して、明示または黙示を問わず、一切の表明または保証を行いません。

管理に関する考慮事項

Azure Stack Hub は封印されたシステムであり、インフラストラクチャはアクセス許可とネットワークの両方の観点からロックダウンされます。 ネットワーク アクセス制御リスト (ACL) は、承認されていないすべての着信トラフィックとインフラストラクチャ コンポーネント間のすべての不要な通信をブロックするために適用されます。 このシステムでは、承認されていないユーザーがシステムにアクセスすることが困難になります。

毎日の管理と運用では、インフラストラクチャへの無制限の管理者アクセスはありません。 Azure Stack Hub オペレーターは、管理者ポータルまたは Azure Resource Manager (PowerShell または REST API を使用) を使用してシステムを管理する必要があります。 Hyper-V Manager やフェールオーバー クラスター マネージャーなど、他の管理ツールによるシステムへのアクセスはありません。 システムを保護するために、サードパーティ製ソフトウェア (エージェントなど) を Azure Stack Hub インフラストラクチャのコンポーネント内にインストールすることはできません。 外部管理およびセキュリティ ソフトウェアとの相互運用性は、PowerShell または REST API を使用して行われます。

アラート仲介の手順で解決されない問題のトラブルシューティングに、より高いレベルのアクセス権が必要な場合は、Microsoft サポートにお問い合わせください。 サポートを通じて、より高度な操作のためにシステムへの一時的な完全な管理者アクセスを提供する方法があります。

ID に関する考慮事項

ID プロバイダーの選択

Azure Stack Hub のデプロイに使用する ID プロバイダー (Microsoft Entra ID または AD FS) を検討する必要があります。 完全なシステムの再デプロイなしでは、デプロイ後に ID プロバイダーを切り替えることはできません。 Microsoft Entra アカウントを所有せず、クラウド ソリューション プロバイダーから提供されたアカウントを使用している場合、プロバイダーを切り替えて別の Microsoft Entra アカウントを使用する場合は、ソリューション プロバイダーに連絡して、コストでソリューションを再デプロイする必要があります。

ID プロバイダーの選択は、テナント仮想マシン (VM)、ID システム、使用するアカウント、Active Directory ドメインに参加できるかどうかなどには関係ありません。 これらは別々です。

同じ Microsoft Entra テナントまたは Active Directory を使用して、複数の Azure Stack Hub システムをデプロイできます。

AD FS と Graph の統合

AD FS を ID プロバイダーとして使用して Azure Stack Hub をデプロイする場合は、フェデレーション信頼を通じて、Azure Stack Hub 上の AD FS インスタンスを既存の AD FS インスタンスと統合する必要があります。 この統合により、既存の Active Directory フォレスト内の ID が Azure Stack Hub のリソースで認証されます。

Azure Stack Hub の Graph サービスを既存の Active Directory と統合することもできます。 この統合により、Azure Stack Hub Role-Based アクセス制御 (RBAC) を管理できます。 リソースへのアクセスが委任されると、Graph コンポーネントは LDAP プロトコルを使用して、既存の Active Directory フォレスト内のユーザー アカウントを検索します。

次の図は、統合された AD FS と Graph トラフィック フローを示しています。

AD FS と Graph トラフィック フローの を示す図

ライセンス モデル

使用するライセンス モデルを決定する必要があります。 使用可能なオプションは、インターネットに接続された Azure Stack Hub をデプロイするかどうかによって異なります。

  • 接続されたデプロイの場合は、従量課金制または容量ベースのライセンスを選択できます。 従量課金制では、使用状況を報告するために Azure への接続が必要です。その後、Azure コマースを通じて課金されます。
  • インターネットから切断された状態で を展開する 場合は、容量ベースのライセンスのみがサポートされます。

ライセンス モデルの詳細については、「Microsoft Azure Stack Hub のパッケージ化と価格に関するページを参照してください。

名前付けの決定

Azure Stack Hub 名前空間 、特にリージョン名と外部ドメイン名を計画する方法について考える必要があります。 パブリック向けエンドポイント用の Azure Stack Hub デプロイの外部完全修飾ドメイン名 (FQDN) は、これら2つの名前の組み合わせです: <リージョン>および<fqdn>。 たとえば、east.cloud.fabrikam.comします。 この例では、Azure Stack Hub ポータルは次の URL で使用できます。

  • https://portal.east.cloud.fabrikam.com
  • https://adminportal.east.cloud.fabrikam.com

重要

Azure Stack Hub のデプロイに選択するリージョン名は一意である必要があり、ポータルのアドレスに表示されます。

次の表は、これらのドメインの名前付けの決定をまとめたものです。

名前 説明
リージョン名 最初の Azure Stack Hub リージョンの名前。 この名前は、Azure Stack Hub が管理するパブリック仮想 IP アドレス (VIP) の FQDN の一部として使用されます。 通常、リージョン名は、データセンターの場所などの物理的な場所識別子になります。

地域名は、0 ~ 9 の文字と数字のみで構成する必要があります。 特殊文字 (-、#など) は使用できません。
外部ドメイン名 外部接続 VIP を持つエンドポイントのドメイン ネーム システム (DNS) ゾーンの名前。 パブリック VIP の FQDN に使用します。
プライベート (内部) ドメイン名 インフラストラクチャ管理のために Azure Stack Hub 上に作成されたドメイン (および内部 DNS ゾーン) の名前。

証明書の要件

デプロイの場合は、公開エンドポイントに Secure Sockets Layer (SSL) 証明書を提供する必要があります。 大まかに言えば、証明書には次の要件があります。

  • 単一のワイルドカード証明書を使用することも、一連の専用証明書を使用して、ストレージや Key Vault などのエンドポイントにのみワイルドカードを使用することもできます。
  • 証明書は、パブリック信頼証明機関 (CA) またはカスタマー マネージド CA によって発行できます。

Azure Stack Hub のデプロイに必要な PKI 証明書とその取得方法の詳細については、「Azure Stack Hub 公開キー 基盤証明書の要件 する」を参照してください。

重要

提供された PKI 証明書情報は、一般的なガイダンスとして使用する必要があります。 Azure Stack Hub の PKI 証明書を取得する前に、OEM ハードウェア パートナーと協力してください。 より詳細な証明書のガイダンスと要件が提供されます。

時刻同期

Azure Stack Hub の同期に使用する特定のタイム サーバーを選択する必要があります。 時間同期は、Kerberos チケットの生成に使用されるため、Azure Stack Hub とそのインフラストラクチャ ロールにとって重要です。 Kerberos チケットは、相互に内部サービスを認証するために使用されます。

時刻同期サーバーの IP を指定する必要があります。 インフラストラクチャ内のコンポーネントのほとんどは URL を解決できますが、一部のコンポーネントは IP アドレスのみをサポートします。 切断されたデプロイ オプションを使用している場合は、Azure Stack Hub のインフラストラクチャ ネットワークからアクセスできることを確認する、企業ネットワーク上のタイム サーバーを指定する必要があります。

重要

タイム サーバーが Windows ベースの NTP サーバーでない場合は、IP アドレスの末尾 ,0x8 追加する必要があります。 たとえば、10.1.1.123,0x8します。

Azure Stack Hub を Azure に接続する

ハイブリッド クラウドシナリオでは、Azure Stack Hub を Azure に接続する方法を計画する必要があります。 Azure Stack Hub の仮想ネットワークを Azure の仮想ネットワークに接続するには、次の 2 つの方法がサポートされています。

  • サイト間: IPsec (IKE v1 および IKE v2) 経由の仮想プライベート ネットワーク (VPN) 接続。 この種類の接続には、VPN デバイスまたはルーティングとリモート アクセス サービス (RRAS) が必要です。 Azure の VPN ゲートウェイの詳細については、「VPN Gatewayについて」を参照してください。 このトンネル経由の通信は暗号化され、セキュリティで保護されます。 ただし、帯域幅はトンネルの最大スループット (100 ~ 200 Mbps) によって制限されます。

  • 送信 NAT: 既定では、Azure Stack Hub 内のすべての VM が送信 NAT 経由で外部ネットワークに接続されます。 Azure Stack Hub で作成された各仮想ネットワークには、パブリック IP アドレスが割り当てられます。 VM にパブリック IP アドレスが直接割り当てられているか、パブリック IP アドレスを持つロード バランサーの背後にあるかにかかわらず、仮想ネットワークの VIP を使用して送信 NAT 経由で送信アクセスできます。 この方法は、VM によって開始され、外部ネットワーク (インターネットまたはイントラネット) 宛ての通信にのみ機能します。 外部から VM と通信するために使用することはできません。

ハイブリッド接続オプション

ハイブリッド接続の場合は、提供する展開の種類と展開場所を検討することが重要です。 テナントごとにネットワーク トラフィックを分離する必要があるかどうか、およびイントラネットとインターネットのどちらを展開するかを検討する必要があります。

  • シングルテナントの Azure Stack Hub: 少なくともネットワークの観点から見ると、1 つのテナントであるかのように見える Azure Stack Hub デプロイ。 テナント サブスクリプションは多数存在する場合がありますが、イントラネット サービスと同様に、すべてのトラフィックは同じネットワーク上を移動します。 あるサブスクリプションからのネットワーク トラフィックは、別のサブスクリプションと同じネットワーク接続を経由するため、暗号化されたトンネル経由で分離する必要はありません。

  • マルチテナント Azure Stack Hub: Azure Stack Hub の外部にあるネットワークにバインドされている各テナント サブスクリプションのトラフィックを、他のテナントのネットワーク トラフィックから分離する必要がある Azure Stack Hub デプロイ。

  • イントラネットのデプロイ: 企業のイントラネット上 (通常はプライベート IP アドレス空間と 1 つ以上のファイアウォールの背後) に配置される Azure Stack Hub デプロイ。 パブリック IP アドレスはパブリック インターネット経由で直接ルーティングできないため、本当にパブリックではありません。

  • インターネットデプロイ: パブリック インターネットに接続され、パブリック VIP 範囲にインターネットルーティング可能なパブリック IP アドレスを使用する Azure Stack Hub デプロイ。 デプロイは引き続きファイアウォールの背後に配置できますが、パブリック VIP 範囲にはパブリック インターネットと Azure から直接到達できます。

次の表は、ハイブリッド接続のシナリオと、長所、短所、ユース ケースをまとめたものです。

シナリオ 接続方法 プロ 短所 適した用途
シングル テナントの Azure Stack Hub、イントラネットデプロイ 送信 NAT より高速な転送のためのより良い帯域幅。 実装が簡単です。ゲートウェイは必要ありません。 トラフィックは暗号化されません。スタックの外部で分離または暗号化を行う必要はありません。 すべてのテナントが等しく信頼されているエンタープライズ 展開。

Azure への Azure ExpressRoute 回線を持つ企業。
マルチテナント Azure Stack Hub、イントラネットデプロイ サイト間 VPN テナント VNet から宛先へのトラフィックは安全です。 帯域幅はサイト間 VPN トンネルによって制限されます。

仮想ネットワーク内のゲートウェイと、宛先ネットワーク上の VPN デバイスが必要です。		 一部のテナント トラフィックを他のテナントからセキュリティで保護する必要があるエンタープライズ デプロイ。
シングル テナントの Azure Stack Hub、インターネットデプロイ 送信 NAT より高速な転送のためのより良い帯域幅。 トラフィックは暗号化されません。スタックの外部で分離または暗号化を行う必要はありません。 テナントが独自の Azure Stack Hub デプロイと Azure Stack Hub 環境への専用回線を取得するホスティング シナリオ。 たとえば、ExpressRoute とマルチプロトコル ラベル スイッチング (MPLS) などです。
マルチテナントの Azure Stack Hub、インターネットデプロイ サイト間 VPN テナント VNet から宛先へのトラフィックは安全です。 帯域幅はサイト間 VPN トンネルによって制限されます。

仮想ネットワーク内のゲートウェイと、宛先ネットワーク上の VPN デバイスが必要です。		 プロバイダーがマルチテナント クラウドを提供する必要があるホスティング シナリオ。テナントが相互に信頼せず、トラフィックを暗号化する必要があります。

ExpressRoute の使用

シングルテナント イントラネットとマルチテナントの両方のシナリオで、ExpressRoute を介して Azure Stack Hub を Azure に接続できます。 接続プロバイダー経由でプロビジョニングされている ExpressRoute 回線が必要です。

次の図は、シングルテナント シナリオ ("顧客の接続" が ExpressRoute 回線) の ExpressRoute を示しています。

シングルテナントの ExpressRoute シナリオ図

次の図は、マルチテナント シナリオの ExpressRoute を示しています。

マルチテナントの ExpressRoute シナリオ図

外部監視

Azure Stack Hub のデプロイとデバイスからすべてのアラートを 1 つのビューで取得し、チケット作成のために既存の IT サービス管理ワークフローにアラートを統合するには、Azure Stack Hub と外部データセンター監視ソリューションを統合 。

Azure Stack Hub ソリューションに含まれるハードウェア ライフサイクル ホストは、ハードウェア用の OEM ベンダー提供の管理ツールを実行する Azure Stack Hub の外部にあるコンピューターです。 これらのツールや、データセンター内の既存の監視ソリューションと直接統合するその他のソリューションを使用できます。

次の表は、現在使用可能なオプションの一覧をまとめたものです。

面積 外部監視ソリューション
Azure Stack Hub ソフトウェア Operations Manager 用 Azure Stack Hub 管理パック
Nagios プラグイン
REST ベースの API 呼び出し
物理サーバー (IPMI 経由 BMC) OEM ハードウェア - オペレーション マネージャー サプライヤー管理パック
OEM ハードウェア ベンダー提供ソリューション
ハードウェア ベンダーの Nagios プラグイン。
OEM パートナーがサポートする監視ソリューション (付属)
ネットワーク デバイス (SNMP) Operations Manager ネットワーク デバイスの検出
OEM ハードウェア ベンダー提供ソリューション
Nagios スイッチ プラグイン
テナント サブスクリプションの正常性の監視 Windows Azure 用システムセンターマネジメントパック

次の要件に注意してください。

  • 使用するソリューションはエージェントレスである必要があります。 Azure Stack Hub コンポーネント内にサードパーティのエージェントをインストールすることはできません。
  • System Center Operations Manager を使用する場合は、Operations Manager 2012 R2 または Operations Manager 2016 が必要です。

バックアップとディザスター リカバリー

バックアップとディザスター リカバリーの計画には、IaaS VM と PaaS サービスをホストする基になる Azure Stack Hub インフラストラクチャと、テナント アプリとデータの両方の計画が含まれます。 これらのことを個別に計画します。

インフラストラクチャ コンポーネントを保護する

指定した SMB 共有に Azure Stack Hub インフラストラクチャ コンポーネントをバックアップできます。

  • 既存の Windows ベースのファイル サーバーまたはサード パーティ製デバイス上に外部 SMB ファイル共有が必要です。
  • この同じ共有を、ネットワーク スイッチとハードウェア ライフサイクル ホストのバックアップに使用します。 OEM ハードウェア ベンダーは、これらのコンポーネントが Azure Stack Hub の外部にあるため、これらのコンポーネントのバックアップと復元に関するガイダンスを提供するのに役立ちます。 OEM ベンダーの推奨事項に基づいてバックアップ ワークフローを実行する責任があります。

致命的なデータ損失が発生した場合は、インフラストラクチャ バックアップを使用して、次のようなデプロイ データを再シードできます。

  • デプロイの入力と ID
  • サービス アカウント
  • CA ルート証明書
  • フェデレーション リソース (切断されたデプロイの場合)
  • プラン、オファー、サブスクリプション、クォータ
  • RBAC ポリシーとロールの割り当て
  • Key Vault の機密情報

警告

既定では、Azure Stack Hub スタンプは 1 つの CloudAdmin アカウントでのみ構成されます。 アカウントの資格情報が失われたり、侵害されたり、ロックされたりした場合、回復オプションはありません。 特権エンドポイントとその他のリソースへのアクセスが失われます。

自分の費用でスタンプの再デプロイを回避するために、追加の CloudAdmin アカウント を作成することを強くお勧めします。 これらの資格情報は、会社のガイドラインに基づいて文書化してください。

IaaS VM 上のテナント アプリを保護する

Azure Stack Hub では、テナント アプリとデータはバックアップされません。 Azure Stack Hub の外部のターゲットへのバックアップとディザスター リカバリー保護を計画する必要があります。 テナント保護は、テナント主導のアクティビティです。 IaaS VM の場合、テナントはゲスト内テクノロジを使用して、ファイル フォルダー、アプリ データ、およびシステム状態を保護できます。 ただし、企業またはサービス プロバイダーとして、同じデータセンターまたはクラウドの外部にバックアップと復旧ソリューションを提供することが必要な場合があります。

Linux または Windows IaaS VM をバックアップするには、ゲスト オペレーティング システムにアクセスできるバックアップ製品を使用して、ファイル、フォルダー、オペレーティング システムの状態、アプリ データを保護する必要があります。 Azure Backup、System Center Datacenter Protection Manager、またはサポートされているサードパーティ製品を使用できます。

セカンダリの場所にデータをレプリケートし、障害が発生した場合にアプリケーションのフェールオーバーを調整するには、Azure Site Recovery またはサポートされているサードパーティ製品を使用できます。 また、Microsoft SQL Server などのネイティブ レプリケーションをサポートするアプリは、アプリが実行されている別の場所にデータをレプリケートできます。

詳細情報

  • ユース ケース、購入、パートナー、OEM ハードウェア ベンダーの詳細については、Azure Stack Hub 製品ページ を参照してください。
  • Azure Stack Hub 統合システムのロードマップと geo 可用性の詳細については、ホワイト ペーパー「Azure Stack Hub: Azureの拡張機能」を参照してください。

次の手順

Azure Stack Hub デプロイ接続モデル