Azure Local は、お客様が所有するインフラストラクチャに Azure を拡張し、分散した場所で最新のアプリケーションと従来のアプリケーションをローカルで実行できるようにします。 このソリューションは、1 つのコントロール プレーンで統合された管理エクスペリエンスを提供し、信頼できる Microsoft パートナーから検証された幅広いハードウェアをサポートします。 Azure Local と Azure Arc の機能を使用して、ビジネス システムとアプリケーション データをオンプレミスに保持し、データ主権、規制とコンプライアンス、待機時間の要件に対処できます。
この記事では、ハイブリッド システムについて理解し、Azure Local に関する実用的な知識があることを前提としています。 この記事のガイダンスでは、Azure Well-Architected Framework の柱の原則にマップされたアーキテクチャに関する推奨事項を示します。
Von Bedeutung
このガイドの使用方法
各セクションには、設計チェックリスト があり、テクノロジ スコープにローカライズされた設計戦略と共に、関心のあるアーキテクチャ領域が示されています。
また、これらの戦略の具体化に役立つテクノロジ機能に関する 推奨事項 も含まれています。 推奨事項は、Azure Local とその依存関係で使用できるすべての構成の完全な一覧を表すわけではありません。 代わりに、設計パースペクティブにマップされた主要な推奨事項が一覧表示されます。 推奨事項を使用して概念実証を構築するか、既存の環境を最適化します。
主要な推奨事項を示す基本アーキテクチャ:
Azure ローカル ベースライン参照アーキテクチャ。
技術範囲
このレビューでは、次の Azure リソースに関する相互に関連する決定に焦点を当てます。
- Azure Local (プラットフォーム)、バージョン 23H2 以降
- Azure Arc VM（ワークロード）
注
この記事では、上記の範囲について説明し、 プラットフォーム アーキテクチャ と ワークロード アーキテクチャ別に整理されたチェックリストと推奨事項について説明します。 プラットフォームの懸念事項は、プラットフォーム管理者の責任です。 ワークロードの問題は、ワークロード オペレーターとアプリケーション開発者の責任です。 これらの役割と責任は異なり、個別のチームまたは個人が所有できます。 ガイダンスを適用するときは、その区別に留意してください。
このガイダンスでは、Azure Arc VM、Azure Kubernetes Service (AKS)、Azure Virtual Desktop など、Azure Local にデプロイできる特定のリソースの種類には焦点を当てません。 これらのリソースの種類を Azure Local にデプロイする場合は、それぞれのワークロード ガイダンスを参照して、ビジネス要件を満たすソリューションを設計してください。
信頼性
信頼性の柱の目的は、十分な回復性を構築 し、障害から迅速に回復する機能をして継続的な機能を提供することです。
信頼性設計の原則、個々のコンポーネント、システム フロー、およびシステム全体に適用される高度な設計戦略を提供します。
ハイブリッド クラウドデプロイでは、1 つのコンポーネント障害の影響を減らすことが目標です。 これらの設計チェックリストと構成の提案を使用して、Azure Local にデプロイするワークロードのコンポーネント障害の影響を軽減します。
プラットフォームの信頼性とワークロードの信頼性を区別することが重要です。 ワークロードの信頼性はプラットフォームに依存します。 アプリケーションの所有者または開発者は、定義された信頼性ターゲットを提供できるアプリケーションを設計する必要があります。
設計チェックリスト
信頼性 の設計レビュー チェックリストに基づいて、設計戦略を開始します。 Azure Local のパフォーマンスを考慮しながら、ビジネス要件との関連性を判断します。 必要に応じて、より多くのアプローチを含むように戦略を拡張します。
(Azure ローカル プラットフォームのアーキテクチャとワークロード アーキテクチャ) ワークロードの信頼性のターゲットを定義します。
可用性ターゲットを評価できるように、サービス レベル目標 (SLO) を設定します。 ワークロードのアップタイムを反映する 99.9%、99.95%、99.995%などの割合で SLO を計算します。 この計算は、Azure ローカル インスタンスまたはワークロードが出力するプラットフォーム メトリックのみに基づくのではないことに注意してください。 包括的なターゲット測定を取得するには、リリース中の予想されるダウンタイム、ルーチン運用、サポート可能性、その他のワークロード固有または組織固有の要因など、定量化される微妙な要因を考慮します。
Microsoft が提供するサービス レベル アグリーメント (SLA) は、多くの場合、SLO の計算に影響します。 ただし、Microsoft は、お客様のデータセンターの信頼性 (電源や冷却など) やプラットフォームを管理するユーザーとプロセスを制御しないため、Azure ローカル インスタンスまたはデプロイされたワークロードのアップタイムと接続に対する SLA を提供していません。
(Azure ローカル プラットフォーム アーキテクチャ) パフォーマンスと操作が信頼性に与える影響を検討します。
インスタンスまたはその依存関係のパフォーマンスが低下すると、Azure Local プラットフォームが使用できなくなる可能性があります。 例えば次が挙げられます。
適切なワークロード容量計画がなければ、設計フェーズで Azure Local インスタンスを適切にサイズ変更 することは困難です。これは、ワークロードが目的の信頼性目標を満たすことができるようにするための要件です。 インスタンスの設計時に Azure Local sizer ツール を使用します。 高可用性 VM が必要な場合は、"マシンの数に対する N+1 最小要件" を検討してください。 ビジネス クリティカルまたはミッション クリティカルなワークロードの場合は、回復性が最も重要な場合は、インスタンス サイズに "N+2 個のマシン" を使用することを検討してください。
プラットフォームの信頼性は、物理ディスクの種類など、重要なプラットフォームの依存関係のパフォーマンスによって異なります。 要件に適したディスクの種類を選択する必要があります。 待ち時間が短くスループットの高いストレージを必要とするワークロードでは、オールフラッシュ (NVMe/SSD のみ) ストレージ構成をお勧めします。 汎用コンピューティングの場合、ハイブリッド ストレージ (キャッシュの場合は NVMe または SSD、容量の場合は HDD) の構成では、より多くのストレージ領域が提供される場合があります。 ただし、トレードオフとして、ワークロードが キャッシュ ワーキング セットを超えると、回転ディスクのパフォーマンスが大幅に低下し、HDD の 平均故障時間 は NVMe/SSD と比較して大幅に低くなります。
パフォーマンス効率では、 これらの例について詳しく説明します。
不適切な Azure ローカル操作 は、デプロイの修正プログラムの適用とアップグレード、テスト、一貫性に影響を与える可能性があります。 いくつかの例を次に示します。
Azure Local プラットフォームが 最新のハードウェアオリジナル機器メーカー (OEM) ファームウェア、ドライバー、イノベーションと共に進化しない場合、プラットフォームは最新の回復性機能を利用しない可能性があります。 ハードウェア OEM ドライバーとファームウェアの更新プログラムを定期的に適用します。 詳細については、「 Azure ローカル ソリューション カタログ」を参照してください。
デプロイの前に、接続、ハードウェア、ID とアクセスの管理についてターゲット環境をテストする必要があります。 それ以外の場合は、Azure ローカル ソリューションを不安定な環境にデプロイすると、信頼性の問題が発生する可能性があります。 環境チェッカー ツールをスタンドアロン モードで使用すると、インスタンス ハードウェアが使用可能な前であっても、問題を検出できます。
(Azure ローカル プラットフォーム アーキテクチャ) インスタンスとそのインフラストラクチャの依存関係にフォールト トレランスを提供します。
ストレージの設計の選択肢。 ほとんどのデプロイでは、"ワークロードとインフラストラクチャ ボリュームを自動的に作成する" 既定のオプションで十分です。 [高度なオプション：「必要なインフラストラクチャ ボリュームのみを作成」]を選択した場合は、ワークロードの要件に基づいて Storage Spaces Direct において適切なボリュームフォールトトレランスを構成します。 これらの決定は、ボリュームのパフォーマンス、容量、回復性の機能に影響します。 たとえば、3 方向ミラーを使用すると、3 台以上のマシンがあるインスタンスの信頼性とパフォーマンスが向上します。 詳細については、「記憶域効率のフォールト トレランス」および 「記憶域スペース ダイレクト仮想ディスクとボリュームの作成」を参照してください。
ネットワーク アーキテクチャ。 検証済みのネットワーク トポロジを使用して Azure Local をデプロイします。 4 つ以上の物理マシンを持つ複数のマシン インスタンスには、"記憶域の切り替え" 設計が必要です。 2 台または 3 台のマシンを持つインスタンスは、必要に応じて "ストレージ スイッチレス" 設計を使用できます。 インスタンス サイズに関係なく、管理とコンピューティングの意図 (北と南のアップリンク) にデュアル トップ オブ ラック (ToR) スイッチを使用してフォールト トレランスを向上することをお勧めします。 デュアル ToR トポロジは、スイッチ サービス (ファームウェア更新) 操作中の回復性も提供します。 詳細については、「 検証済みネットワーク トポロジ」を参照してください。
(ワークロード アーキテクチャ) 冗長性を構築して回復性を提供します。
1 つの Azure ローカル インスタンスにデプロイするワークロードを、ローカル冗長デプロイ
とします。 インスタンスはプラットフォーム レベルで高可用性を提供しますが、"1 つのラック" にインスタンスをデプロイすることを覚えておく必要があります。 そのため、ビジネス クリティカルまたはミッション クリティカルなユース ケースでは、ワークロードまたはサービスの複数のインスタンスを 2 つ以上の個別の Azure Local インスタンスにデプロイすることをお勧めします。理想的には、別の物理的な場所に配置することをお勧めします。 ワークロードには業界標準の高可用性パターンを使用します。たとえば、アクティブ/パッシブ同期または非同期データ レプリケーション (SQL Server Always On など) を提供する設計などです。 もう 1 つの例は、別の物理的な場所にデプロイする Azure Local インスタンスで実行される複数のワークロード インスタンス間でユーザー要求をルーティングできる外部ネットワーク負荷分散 (NLB) テクノロジです。 パートナーの外部 NLB デバイスの使用を検討してください。 または、ハイブリッド サービスとオンプレミス サービスのトラフィック ルーティングをサポートする 負荷分散オプション (Azure ExpressRoute または VPN トンネルを使用してオンプレミス サービスに接続する Azure Application Gateway インスタンスなど) を評価します。
詳細については、「 複数の Azure ローカル インスタンスにワークロード インスタンスをデプロイする」を参照してください。
(ワークロード アーキテクチャ)ワークロード回復ポイント目標 (RPO) と目標復旧 時間 (RTO) の目標に基づいて復旧可能性を計画し、テストします。
十分に文書化されたディザスター リカバリー計画を作成します。 復旧手順を定期的にテストして、ビジネス継続性の計画とプロセスが有効であることを確認します。 Azure Site Recovery が、Azure Local で実行される VM を保護するための実行可能な選択肢であるかどうかを判断します。 詳細については、 Azure Site Recovery on Azure Local (プレビュー) を使用した VM ワークロードの保護に関するページを参照してください。
(ワークロード アーキテクチャ) ワークロードのバックアップと復元の手順を構成して定期的にテストします。
データ復旧とリテンション期間に関するビジネス要件が、ワークロード バックアップの戦略を推進します。 包括的な戦略には、 ワークロード オペレーティング システム (OS) とアプリケーションの永続データに関する考慮事項と、個々の (特定の時点の) ファイル レベルおよびフォルダー レベルのデータを復元する機能が含まれます。 データ復旧とコンプライアンスの要件に基づいてバックアップ保持ポリシーを構成します。これは、使用可能なデータ復旧ポイントの数と有効期間を決定します。 Azure ローカルのホスト レベルまたは VM ゲスト レベルのバックアップを有効にするオプションとして、Azure Backup を調べる。 関連する場合は、Backup の独立系ソフトウェア ベンダー パートナーからのデータ保護ソリューションを確認します。 詳細については、 Azure Backup のガイダンスとベスト プラクティスとAzure Backup for Azure Local に関するページを参照してください。
推奨事項
| 勧告 | メリット |
|---|---|
| 記憶域スペース ダイレクト記憶域プール内の マシンごとに 1 つの容量ディスク分の容量ディスクを 予約します。 | Azure ローカル インスタンスをデプロイした後にワークロード ボリュームを作成する場合 (詳細オプション: "必要なインフラストラクチャ ボリュームのみを作成する" ) は、 記憶域プールに割り当てられていないプール容量の合計の 5% から 10% のままにすることをお勧めします。 この予約済みで未使用の空き容量を使用すると、物理ディスクに障害が発生したときに記憶域スペース ダイレクトで "インプレース" を修復できます。これにより、物理ディスクの障害が発生した場合のデータの回復性とパフォーマンスが向上します。 |
| すべての物理マシンが、Azure Local と Azure Arc に 必要な送信 HTTPS エンドポイント の一覧にネットワーク アクセスできることを確認します。 | Azure Local インスタンスまたはワークロード リソースを確実に管理、監視、操作するには、必要な送信ネットワーク エンドポイントに直接またはプロキシ サーバー経由でアクセスできる必要があります。 一時的な中断はワークロードの実行状態には影響しませんが、管理容易性に影響する可能性があります。 |
| ワークロード ボリューム (仮想ディスク) を手動で作成する場合は、最も適切な 回復性の種類 を使用して、ワークロードの回復性とパフォーマンスを最大化します。 インスタンスをデプロイした後に手動で作成するユーザー ボリュームの場合は、 Azure でボリュームのストレージ パスを作成します。 ボリュームには、ワークロード VM 構成ファイル、VM 仮想ハード ディスク (VHD)、および VM イメージをストレージ パス経由で格納できます。 | 3 つ以上のマシンを持つ Azure Local インスタンスの場合は、3 方向ミラーを使用して最高の回復性とパフォーマンス機能を提供することを検討してください。 ビジネス クリティカルまたはミッション クリティカルなワークロードには、ミラー化ボリュームを使用することをお勧めします。 |
| ワークロードのアフィニティ対策ルールを実装して、同じサービスの複数のインスタンスをホストする VM が個別の物理ホストで実行されるようにすることを検討してください。 この概念は、Azure の "可用性セット" に似ています。 | すべてのコンポーネントを冗長にします。 ビジネス クリティカルまたはミッション クリティカルなワークロードの場合は、複数の Azure Arc VM または Kubernetes レプリカ セットまたはポッドを使用して、アプリケーションまたはサービスの複数のインスタンスをデプロイします。 この方法では、1 台の物理マシンの計画外の停止が発生した場合の回復性が向上します。 |
安全
セキュリティの柱の目的は、ワークロードに対して機密性、整合性、可用性を保証することです。
セキュリティ設計原則は、Azure Local の技術的な設計にアプローチを適用することで、これらの目標を達成するための高度な設計戦略を提供します。
Azure Local は、クラウド デプロイ プロセス中に 300 を超えるセキュリティ設定が有効になっている、既定でセキュリティで保護された製品です。 既定のセキュリティの設定は、デバイスが常に既知の適切な状態で起動するように、一貫したセキュリティ ベースラインを提供します。 また、ドリフト保護コントロールを使用して、大規模な管理を提供できます。
Azure Local の既定のセキュリティ機能には、強化された OS セキュリティ設定、Windows Defender アプリケーション制御、BitLocker によるボリューム暗号化、シークレットローテーション、ローカルの組み込みユーザー アカウント、Microsoft Defender for Cloud が含まれます。 詳細については、「 セキュリティ機能の確認」を参照してください。
設計チェックリスト
セキュリティの設計レビュー チェックリストに基づいて 、設計戦略を開始します。 セキュリティ体制を改善するための脆弱性と制御を特定します。 必要に応じて、より多くのアプローチを含むように戦略を拡張します。
(Azure ローカル プラットフォーム アーキテクチャ) セキュリティ ベースラインを確認します。 Azure のローカル標準とセキュリティ標準では、 プラットフォームとホストされているワークロードのセキュリティ体制を強化するためのベースライン ガイダンスが提供されます。 ワークロードが特定の規制コンプライアンス規制に準拠する必要がある場合は、Payment Card Industry Data Security Standards や Federal Information Processing Standard 140 などの規制セキュリティ標準を考慮してください。
Azure Local プラットフォームで提供される既定の設定 により、ID 制御、ネットワーク フィルター、暗号化などのセキュリティ機能が有効になります。 これらの設定は、新しくプロビジョニングされた Azure Local インスタンスの適切なセキュリティ ベースラインを形成します。 組織のセキュリティ要件に基づいて、各設定をカスタマイズできます。
望 ましくないセキュリティ構成の誤差を検出して保護してください。
(Azure ローカル プラットフォーム アーキテクチャ) 脅威を検出、防止、対応します。 Azure ローカル環境を継続的に監視し、既存の脅威や進化する脅威から保護します。
Defender for Cloud on Azure Local を有効にすることをお勧めします。 Defender Cloud Security Posture Management を使用して、基本的な Defender for Cloud プラン (Free レベル) を有効にして、Azure ローカル プラットフォームと他の Azure および Azure Arc リソースをセキュリティで保護するために実行できる手順を監視および特定します。
個々のサーバーと Azure Arc VM のセキュリティ アラートなど、強化されたセキュリティ機能の恩恵を受けるために、Azure ローカル インスタンス マシンと Azure Arc VM で Microsoft Defender for Servers を有効にします。
Defender for Cloud を使用して、Azure ローカル のマシンとワークロードのセキュリティ体制を測定します。 Defender for Cloud には、セキュリティ コンプライアンスの管理に役立つ 1 つのウィンドウエクスペリエンスが用意されています。
Defender for Servers を使用して、ホストされている VM の脅威と構成の誤りを監視します。 また、Azure ローカル コンピューターでエンドポイントの検出と応答の機能を有効にすることもできます。
すべてのソースのセキュリティおよび脅威インテリジェンス データを、 Microsoft Sentinel などの一元化されたセキュリティ情報およびイベント管理 (SIEM) ソリューションに集約することを検討してください。
(Azure ローカル プラットフォームのアーキテクチャとワークロード アーキテクチャ) ブラスト半径を含むセグメント化を作成します。 セグメント化を達成するには、いくつかの戦略があります。
ID。 プラットフォームとワークロードの役割と責任を分離します。 承認された ID のみが、指定されたロールと一致する特定の操作を実行することを許可します。 Azure ローカル プラットフォーム管理者は、プラットフォームの業務を行うために、Azure とローカル ドメインの両方の資格情報を使用します。 ワークロードオペレーターとアプリケーション開発者は、ワークロードのセキュリティを管理します。 アクセス許可の委任を簡略化するには、プラットフォーム管理者には "Azure ローカル管理者"、ワークロードオペレーターには "Azure ローカル VM 共同作成者" や "Azure ローカル VM 閲覧者" など、Azure Local 組み込みのロールベースのアクセス制御 (RBAC) ロールを使用します。 特定の組み込みロール アクションの詳細については、 ハイブリッド ロールとマルチクラウド ロールの Azure RBAC ドキュメントを参照してください。
ネットワーク。 必要に応じてネットワークを分離します。 たとえば、個別の仮想ローカル エリア ネットワーク (vLAN) とネットワーク アドレス範囲を使用する複数の論理ネットワークをプロビジョニングできます。 この方法を使用する場合は、Azure ローカル マシンが ToR スイッチまたはゲートウェイを介して vLAN ネットワークと通信できるように、管理ネットワークが各論理ネットワークと vLAN に到達できることを確認します。 この構成は、インフラストラクチャ管理エージェントがワークロードのゲスト OS と通信できるようにするなど、ワークロードの可用性管理に必要です。
セグメント化戦略の構築に関する推奨事項を確認して、追加情報を入手してください。
(Azure ローカル プラットフォームのアーキテクチャとワークロード アーキテクチャ) 信頼できる ID プロバイダーを使用してアクセスを制御します。 すべての認証と承認の目的で Microsoft Entra ID をお勧めします。 必要に応じて、ワークロードをオンプレミスの Windows Server Active Directory ドメインに参加させることができます。 強力なパスワード、多要素認証、RBAC、およびシークレットの管理のための制御をサポートする機能を利用します。
(Azure ローカル プラットフォームのアーキテクチャとワークロード アーキテクチャ) ネットワーク トラフィックを分離、フィルター処理、ブロックします。 フィルター処理のためにパートナー アプライアンスを取り込むことができるように、仮想ネットワーク、ネットワーク セキュリティ グループによるマイクロセグメント化、サービス ポリシーのネットワーク品質、または仮想アプライアンス チェーンを必要とするワークロードのユース ケースがある場合があります。 このようなワークロードがある場合は、ネットワーク コントローラーが提供するサポートされている機能の一覧については、 ネットワーク参照パターン に関するソフトウェア定義 のネットワーク に関する考慮事項を参照してください。
(ワークロード アーキテクチャ) 改ざんから保護するためにデータを暗号化します。 転送中のデータ、保存データ、使用中のデータを暗号化します。
デプロイ中に作成したデータ ボリュームでは、静止データの暗号化が有効になります。 これらのデータ ボリュームには、インフラストラクチャ ボリュームとワークロード ボリュームの両方が含まれます。 詳細については、「 BitLocker 暗号化の管理」を参照してください。
Azure Arc VM の信頼された起動を使用して、仮想トラステッド プラットフォーム モジュールを使用できるセキュア ブートなどの最新のオペレーティング システムの OS 機能を使用して Gen 2 VM のセキュリティを強化します。
シークレット管理を運用化します。 組織の要件に基づいて、Azure Local のデプロイ ユーザー ID に関連付けられている資格情報を変更します。 詳細については、「 シークレットローテーションの管理」を参照してください。
(Azure ローカル プラットフォーム アーキテクチャ) セキュリティ制御を適用します。 Azure Policy を使用して、"アプリケーション制御ポリシーを一貫して適用する必要がある" や "暗号化されたボリュームを実装する必要がある" などの組み込みポリシーを監査して適用します。 これらの Azure ポリシーを使用して、セキュリティ設定を監査し、Azure Local のコンプライアンス状態を評価できます。 使用可能なポリシーの例については、「 Azure ポリシー」を参照してください。
(ワークロード アーキテクチャ) 組み込みのポリシーを使用して、ワークロードのセキュリティ体制を改善します。 Azure Local で実行される Azure Arc VM を評価するには、セキュリティ ベンチマーク、Azure Update Manager、または Azure Policy ゲスト構成拡張機能を使用して組み込みのポリシーを適用できます。 さまざまなポリシーを使用して、次の条件を確認できます。
- Log Analytics エージェントのインストール
- 最新のセキュリティ パッチで更新が必要な古いシステム更新プログラム
- 脆弱性評価と潜在的な軽減策
- セキュリティで保護された通信プロトコルの使用
推奨事項
| 勧告 | メリット |
|---|---|
| セキュリティ ベースラインとドリフト コントロールの設定を使用して、インスタンス マシンにセキュリティ設定を適用および維持します。 | これらの構成は、Azure Local の意図したセキュリティ体制を適用するために 90 分ごとにセキュリティ設定を自動的に更新するため、不要な変更や誤差から保護するのに役立ちます。 |
| Azure Local で Windows Defender アプリケーション コントロール を使用します。 | Windows Defender アプリケーション制御により、Azure Local の攻撃対象領域が減少します。 Azure portal または PowerShell を使用して、ポリシー設定を表示し、ポリシー モードを制御します。 Windows Defender アプリケーション制御ポリシーは、システムで実行を許可されるドライバーとアプリを制御するのに役立ちます。 |
| BitLocker を使用したボリューム暗号化を有効にして 、保存データの暗号化を保護します。 | BitLocker は、Azure Local で作成されたインスタンス共有ボリュームを暗号化することで、OS とデータ ボリュームを保護します。 BitLocker では、XTS-AES 256 ビット暗号化が使用されます。 すべてのデータ ボリュームに対する Azure ローカル クラウドのデプロイ時に、ボリューム暗号化の既定の設定を有効にしておくことをお勧めします。 |
| BitLocker 回復キーをエクスポートして、Azure Local インスタンスの外部にある安全な場所に格納します。 | 特定のトラブルシューティングまたは回復操作中に BitLocker キーが必要になる場合があります。 'Get-AsRecoveryKeyInfo' PowerShell コマンドレットを使用して、各 Azure ローカル インスタンスから OS とデータ ボリュームの暗号化キーをエクスポート、保存、バックアップすることをお勧めします。 セキュリティで保護された外部の場所 (Azure Key Vault など) にキーを保存します。 |
| SIEM ソリューションを使用して、セキュリティの監視とアラート機能を強化します。 これを行うには、 Azure Arc 対応サーバー (Azure ローカル プラットフォーム マシン) を Microsoft Sentinel にオンボードします。 別の SIEM ソリューションを使用する場合は、選択したソリューションへの セキュリティ イベントの syslog 転送 を構成します。 | Microsoft Sentinel または syslog 転送を使用してセキュリティ イベント データを転送し、カスタマー マネージド SIEM ソリューションとの統合を通じてアラートとレポート機能を提供します。 |
| サーバー メッセージ ブロック (SMB) 署名を使用して、"既定のセキュリティ設定" で有効になっている転送中データ保護を強化します。 | SMB 署名を使用すると、Azure ローカル プラットフォームとプラットフォーム (北または南) の外部のシステム間の SMB トラフィックにデジタル署名できます。 リレー攻撃を防ぐために、Azure ローカル プラットフォームと他のシステム間の外部 SMB トラフィックの署名を構成します。 |
| SMB 暗号化設定を使用して、"既定のセキュリティ設定" で有効になっている転送中データ保護を強化します。 | インスタンス内トラフィックの SMB 暗号化設定は、ストレージ ネットワーク上の Azure ローカル インスタンス (東部または西部) 内の物理マシン間のトラフィックの暗号化を制御します。 |
コストの最適化
コストの最適化では、支出パターンの検出 、重要な領域への投資の優先順位付け、ビジネス要件を満たしながら組織の予算を満たすために他の での最適化に重点を置いています。
コスト最適化の設計原則は、Azure Local とその環境に関連する技術的な設計において、これらの目標を達成し、必要に応じてトレードオフを行う高度な設計戦略を提供します。
設計チェックリスト
投資のコスト最適化 の 設計レビュー チェックリストに基づいて、設計戦略を開始します。 ワークロードの設計を、そのワークロードに割り当てられた予算に合わせて微調整します。 設計では、適切な Azure 機能を使用し、投資を監視し、時間の経過と同時に最適化する機会を見つける必要があります。
Azure Local では、ハードウェア、ソフトウェア ライセンス、ワークロード、ゲスト VM (Windows Server または Linux) ライセンス、その他の統合クラウド サービス (Azure Monitor や Defender for Cloud など) のコストが発生します。
(Azure ローカル プラットフォームのアーキテクチャとワークロード アーキテクチャ) コスト モデリングの一環として、現実的なコストを見積もります。 Azure 料金計算ツールを使用して、Azure Local、Azure Arc、AKS on Azure Local などのサービスを選択して構成します。 さまざまな構成と支払いオプションを試して、コストをモデル化します。
(Azure ローカル プラットフォームのアーキテクチャとワークロード アーキテクチャ) Azure ローカル ハードウェアのコストを最適化します。 ビジネス要件と商用要件に合ったハードウェア OEM パートナーを選択します。 検証済みのマシン、統合システム、およびプレミア ソリューションの認定一覧については、 Azure ローカル ソリューション カタログを参照してください。 ワークロードの特性、サイズ、数量、パフォーマンスをハードウェア パートナーに伝え、Azure ローカル コンピューターとインスタンス サイズに対してコスト効率の高いハードウェア ソリューションを適切にサイズ変更できるようにします。
(Azure ローカル プラットフォーム アーキテクチャ) ライセンス コストを最適化します。 Azure ローカル ソフトウェアは、"物理 CPU コアごと" ベースでライセンスされ、課金されます。 Azure ハイブリッド特典で既存のオンプレミス コア ライセンスを使用して、Windows Server、SQL Server、AKS、Azure Arc 対応 Azure SQL Managed Instance を実行する Azure Arc VM などの Azure ローカル ワークロードのライセンス コストを削減します。 詳細については、「 Azure ハイブリッド特典コスト計算ツール」を参照してください。
(Azure ローカル プラットフォーム アーキテクチャ) 環境コストを節約します。 次のオプションがリソース使用量の最適化に役立つかどうかを評価します。
Microsoft が提供する割引プログラムを利用します。 Azure ハイブリッド特典を使用して、Azure Local ワークロードと Windows Server ワークロードを実行するためのコストを削減することを検討してください。 詳細については、「Azure ローカルの Azure ハイブリッド特典」を参照してください。
プロモーション オファーを調べる。 最初の概念実証または検証のために、登録後に Azure Local 60 日間の無料試用版を利用します。
(Azure ローカル プラットフォーム アーキテクチャ) 運用コストを節約します。
修正プログラムの適用、更新、およびその他の操作のテクノロジ オプションを評価します。 Update Manager は、Azure ハイブリッド特典と Azure Arc VM 管理が有効になっている Azure ローカル インスタンスでは無料です。 詳細については、「 Update Manager の FAQ 」と 「Update Manager の価格」を参照してください。
可観測性に関連するコストを評価します。 監視と監査のニーズを満たすように、アラート ルールとデータ収集規則 (DCR) を設定します。 ワークロードが取り込み、処理、保持するデータの量は、コストに直接影響します。 スマート保持ポリシーを使用して最適化し、アラートの数と頻度を制限し、ログを格納するための適切なストレージ層を選択します。 詳細については、 Log Analytics のコスト最適化ガイダンスを参照してください。
(ワークロード アーキテクチャ) 分離の密度を評価します。 Azure Local 上の AKS を使用して密度を向上させ、ワークロード管理を簡素化することで、コンテナー化されたアプリケーションを複数のデータセンターまたはエッジの場所にまたがってスケーリングできるようにします。 詳細については、 AKS on Azure Local の価格に関するページを参照してください。
推奨事項
| 勧告 | メリット |
|---|---|
| ソフトウェア アシュアランス付きの Windows Server Datacenter ライセンスがある場合は、 Azure Local の Azure ハイブリッド特典 を使用します。 | Azure Local のAzure ハイブリッド特典を使用すると、オンプレミス ライセンスの価値を最大化し、追加コストなしで既存のインフラストラクチャを Azure Local に最新化できます。 |
| Windows Server サブスクリプション アドオンを選択するか、ライセンスを持ち込んで Windows Server VM をライセンス認証し、Azure Local で使用します。 詳細については、「 Azure Local での Windows Server VM のライセンス」を参照してください。 | 使用可能な既存の Windows Server ライセンスとライセンス認証方法を使用できますが、必要に応じて、Azure Local でのみ使用できる "Windows Server サブスクリプション アドオン" を有効にして、Azure ローカル インスタンス内の物理コアの合計数に対して課金される Azure 経由の Windows Server ゲスト ライセンスをサブスクライブできます。 |
| サポートされている Azure 専用ワークロードがクラウドの外部で動作できるように、Azure Local に拡張された VM の Azure 検証 特典を使用します。 | この特典は、Azure Local バージョン 23H2 以降で既定で有効になっています。 VM が他の Azure 環境で動作し、ワークロードが Azure でのみ利用可能なオファー (Azure Arc で有効になっている拡張セキュリティ更新プログラムなど) を利用できるように、この特典を使用します。 |
オペレーショナル エクセレンス
オペレーショナル エクセレンスは主に、開発プラクティス、可観測性、リリース管理の手順に重点を置いています。
オペレーショナル エクセレンス設計原則、ワークロードの運用要件に対してこれらの目標を達成するための高度な設計戦略を提供します。
監視と診断は非常に重要です。 メトリックを使用してパフォーマンス統計を測定し、問題のトラブルシューティングと修復をすばやく行うことができます。 問題のトラブルシューティング方法の詳細については、「 オペレーショナル エクセレンス設計原則 」および 「Azure Local の診断ログを収集する」を参照してください。
設計チェックリスト
Azure Local に関連する監視、テスト、デプロイのプロセスを定義するための オペレーショナル エクセレンスの設計レビュー チェックリスト に基づいて、設計戦略を開始します。
(Azure ローカル プラットフォーム アーキテクチャ) Azure Local のサポート性を高める。 監視は、デプロイ時に既定で有効になります。 これらの機能により、プラットフォームのサポート性が向上します。 テレメトリと診断情報は、既定ですべての Azure ローカル マシンにインストールされている AzureEdgeTelemetryAndDiagnostics 拡張機能を使用して、プラットフォームから安全に共有されます。 詳細については、 Azure のローカル可観測性に関するページを参照してください。
(Azure ローカル プラットフォーム アーキテクチャ) Azure サービスを使用して、運用の複雑さを軽減し、管理スケールを増やします。 Azure Local は Azure と統合されており、プラットフォームにパッチを適用するための Update Manager や、監視とアラートのための Azure Monitor などのサービスを有効にします。 Azure Arc と Azure Policy を使用して、セキュリティ構成とコンプライアンス監査を管理できます。 Defender for Cloud を実装して、サイバーの脅威と脆弱性を管理します。 複雑さを軽減し、スケールの効率を向上させ、管理の整合性を向上させるために、これらの運用プロセスと手順のコントロール プレーンとして Azure を使用します。
(ワークロード アーキテクチャ) ワークロードの IP アドレス ネットワーク範囲の要件を事前に計画します。 Azure Local には、仮想化またはコンテナー化されたワークロードをデプロイおよび管理するためのプラットフォームが用意されています。 また、ワークロードで使用する論理ネットワークの IP アドレス要件も考慮してください。 次のリソースを確認します。
Azure Local にデプロイされたワークロードには 論理ネットワークが必要です。 具体的な例については、 AKS クラスターのネットワーク要件、 Azure Arc VM の論理ネットワーク、Azure Local を使用 した Virtual Desktop に関するページを参照してください。
(ワークロードの構成) Azure Local にデプロイするワークロードの監視とアラートを有効にします。 仮想マシンに Azure Monitor を使用することも、Arc VM の場合は VM Insights を使用することも、Container Insights とマネージド Prometheus AKS クラスターを使用することもできます。
ワークロードに一元化された Log Analytics ワークスペースを使用する必要があるかどうかを評価します。 共有ログ シンク (データの場所) の例については、「 ワークロードの管理と監視の推奨事項」を参照してください。
(Azure ローカル プラットフォーム アーキテクチャ) 安全なデプロイには、適切な検証手法を使用します。 スタンドアロン モードで環境チェッカー ツールを使用して、Azure ローカル ソリューションをデプロイする前に、ターゲット環境の準備状況を評価します。 このツールは、必要な接続、ハードウェア、Windows Server Active Directory、ネットワーク、Azure Arc 統合の前提条件の適切な構成を検証します。
(Azure ローカル プラットフォーム アーキテクチャ) 最新の状態を取得し、最新の状態を維持します。 Azure Local ソリューション カタログを使用して、Azure ローカル インスタンスのデプロイに関する最新のハードウェア OEM イノベーションを最新の状態に保ちます。 Premium ソリューションを使用して、追加の統合、ターンキーデプロイ機能、簡素化された更新エクスペリエンスを活用することを検討してください。
Update Manager を使用してプラットフォームを更新し、ソリューション拡張機能を含む OS、コア エージェント、サービスを管理します。 最新の状態を維持し、拡張機能に対して可能な場合は[自動アップグレードを有効にする]設定を使用することを検討してください。
推奨事項
| 勧告 | メリット |
|---|---|
|
Azure ローカル インスタンスで Monitor Insights を有効にして、ネイティブの Azure 機能を使用して監視とアラートを強化します。 Insights では、DCR によって収集されたインスタンス パフォーマンス カウンターとイベント ログ チャネルを使用して、Azure ローカルの主要な機能を監視できます。 Dell APEX などの特定のハードウェア インフラストラクチャでは、ハードウェア イベントをリアルタイムで視覚化できます。 詳細については、「 機能ワークブック」を参照してください。 |
Azure は Insights を管理するため、常に最新の状態になり、複数のインスタンスにわたってスケーラブルであり、高度にカスタマイズ可能です。 Insights では、基本的なメトリックを備えた既定のブックにアクセスできるとともに、Azure Local の主要な機能の監視用に作成された特殊なブックにもアクセスできます。 この機能は、ほぼリアルタイムの監視を提供します。 集計とフィルター機能を使用して、グラフとカスタマイズされた視覚化を作成できます。 カスタム アラート ルールを構成することもできます。 Insights のコストは、取り込まれたデータの量と Log Analytics ワークスペースのデータ保持設定に基づいています。 Azure Local Insights を有効にする場合は、Insights 作成エクスペリエンスによって作成された DCR を使用することをお勧めします。 DCR 名のプレフィックスは AzureStackHCI-。 必要なデータのみを収集するように構成されています。 |
|
アラートを設定し、組織の要件に基づいてアラート処理ルールを構成します。 正常性、メトリック、ログ、またはその他の種類の監視データの変更に関する通知を受け取ります。 - 健康アラート - ログ アラート - メトリック アラート 詳細については、「 メトリック アラートの推奨ルール」を参照してください。 |
Monitor アラートを Azure Local と統合して、追加コストなしでいくつかの重要な利点を得ることができます。 ほぼリアルタイムの監視を取得し、アラートをカスタマイズして、適切なチームまたは管理者に修復を通知します。 Azure Local では、コンピューティング、ストレージ、ネットワーク リソースのメトリックの包括的な一覧を収集できます。 ログ データに対して高度なロジック操作を実行し、Azure ローカル インスタンスのメトリックを定期的に評価します。 |
| 更新機能を使用して、Azure ローカル ソリューションのさまざまな側面を 1 か所で統合および管理します。 詳細については、「 Azure Local の更新プログラムについて」を参照してください。 | 更新オーケストレーターは、Azure ローカル インスタンスの初期デプロイ中にインストールされます。 この機能により、更新と管理の操作が自動化されます。 Azure Local をサポートされている状態に保つには、インスタンスが使用可能になったときに新しいベースライン ビルドに移行するように、定期的にインスタンスを更新してください。 この方法では、プラットフォームに新しい機能と機能強化が提供されます。 リリース 列車、更新プログラムの周期、各ベースライン ビルドのサポート 期間の詳細については、Azure Local バージョン 23H2 リリース情報を参照してください。 |
| 実践的なスキル、ラボ、トレーニング イベント、製品デモ、または概念実証プロジェクトを支援するには、 Azure Arc Jumpstart の使用を検討してください。 Azure 上の VM を使用してソリューションをデプロイすることで、物理ハードウェアを必要とせずに Azure Local を迅速にデプロイします。 |
LocalBox では 、Azure Local バージョン 23H2 がサポートされており、自己完結型サンドボックスでのネイティブ Azure Arc や AKS 統合など、Azure Edge 製品の最新機能の迅速なテストと評価が可能になります。 このサンドボックスを Azure サブスクリプションにデプロイするには、入れ子になった仮想化をサポートする VM を使用して、Azure VM 内の Azure ローカル インスタンスをエミュレートします。 最小限の手動で新しい クラウド デプロイ機能 などの Azure Local 機能を取得します。 詳細については、 Microsoft Tech Community のブログを参照してください。 |
パフォーマンス効率
パフォーマンス効率とは、容量の管理により、負荷が増加してもユーザー エクスペリエンスを維持することです。 この戦略には、リソースのスケーリング、潜在的なボトルネックの特定と最適化、ピーク パフォーマンスの最適化が含まれます。
パフォーマンス効率設計の原則、予想される使用に対してこれらの容量目標を達成するための高度な設計戦略を提供します。
設計チェックリスト
パフォーマンス効率 の設計レビュー チェックリストに基づいて、設計戦略を開始します。 Azure Local の主要なインジケーターに基づくベースラインを定義します。
(Azure ローカル プラットフォーム アーキテクチャ)OEM パートナー オファリング の Azure ローカル検証ハードウェア または統合システムを使用します。 Azure ローカル環境のパフォーマンスを最適化するには、 Azure ローカル カタログ で Premium ソリューション ビルダーを使用することを検討してください。
(Azure Local Platform Storage アーキテクチャ)ワークロードのパフォーマンスと容量の要件に基づいて 、Azure ローカル マシン に適した物理ディスクの種類を選択します。 待機時間が短く、スループットの高いストレージを必要とする高パフォーマンスワークロードの場合は、オールフラッシュ (NVMe/SSD のみ) ストレージ構成の使用を検討してください。 汎用コンピューティングまたは大規模なストレージ容量の要件については、ハイブリッド ストレージ (キャッシュ層の場合は SSD または NVMe、容量レベルの場合は HDD) の使用を検討してください。この場合、ストレージ容量が増加する可能性があります。
(Azure ローカル プラットフォーム アーキテクチャ)インスタンスの設計 (デプロイ前) フェーズで Azure Local sizer ツールを使用します。 Azure ローカル インスタンスのサイズは、ワークロードの容量、パフォーマンス、回復性の要件を入力として使用して適切にサイズ設定する必要があります。 このサイズにより、計画された (メンテナンス) イベントや計画外 (電源またはハードウェア障害) イベントなど、同時にオフラインにできる物理マシンの最大数 (クラスター クォーラム) が決まります。 詳細については、「 クラスター クォーラムの概要」を参照してください。
(Azure ローカル プラットフォーム アーキテクチャ) 高パフォーマンスまたは低待機時間の要件があるワークロードには、オールフラッシュ (NVMe または SSD) ベースのソリューションを使用します。 これらのワークロードには、高度なトランザクション データベース テクノロジ、運用 AKS クラスター、または低待機時間または高スループットのストレージ要件を備えたミッション クリティカルまたはビジネス クリティカルなワークロードが含まれますが、これらに限定されません。 オールフラッシュ デプロイを使用して、ストレージのパフォーマンスを最大化します。 All-NVMe またはすべての SSD 構成 (特に非常に小規模) では、ドライブがキャッシュ層として使用されないため、記憶域の効率が向上し、パフォーマンスが最大化されます。 詳細については、「 オール フラッシュ ベースのストレージ」を参照してください。
(Azure ローカル プラットフォーム アーキテクチャ)運用環境のワークロードをデプロイする前に 、Azure ローカル インスタンス ストレージのパフォーマンス ベースラインを確立 します。 1 つの Azure Local インスタンスまたは複数のインスタンスのパフォーマンスを同時に監視するように、Insights を使用して Azure Local の監視機能 を構成します。
(Azure ローカル プラットフォーム アーキテクチャ)Azure ローカル インスタンスに対して Insights を有効にした後は、 回復性のあるファイル システム (ReFS) の重複除去と圧縮の監視機能の使用を検討 してください。 ワークロード ストレージの使用量と容量の要件に基づいて、この機能を使用する必要があるかどうかを判断します。 この機能により、ReFS 重複除去と圧縮の節約、パフォーマンスへの影響、ジョブの監視が提供されます。 詳細については、「 ReFS 重複除去と圧縮の監視」を参照してください。
最小要件として、Update Management を使用して更新を実行するときにインスタンス マシンを確実にドレインできるように、インスタンス全体で
1 x physical machines (N+1)相当の容量を予約することを計画します。 ビジネスクリティカルなユース ケースまたはミッションクリティカルなユース ケースに対して、2 physical machines (N+2)マシンの容量を予約することを検討します。
推奨事項
| 勧告 | メリット |
|---|---|
| Azure ローカル インスタンスのデプロイ中に "インフラストラクチャ ボリュームのみを作成する" という高度なオプションを選択した場合は、パフォーマンスが高いワークロード用のワークロード ボリュームを 作成するときに、ミラーリングを使用して仮想ディスク を作成することをお勧めします。 | この推奨事項は、厳密な待機時間要件があるワークロードや、SQL Server データベース、Kubernetes クラスター、その他のパフォーマンスに依存する VM など、1 秒あたりのランダム読み取りと書き込みの入出力操作 (IOPS) が混在して高スループットを必要とするワークロードにメリットがあります。 ミラーリングを使用するボリュームにワークロード VHD をデプロイして、パフォーマンスと回復性を最大化します。 ミラーリングは、他のどの回復性の種類よりも高速です。 |
| DiskSpd を使用して、Azure ローカル インスタンスの ワークロード ストレージのパフォーマンス 機能をテストすることを検討してください。 また、VMFleet を使用して負荷を生成し、ストレージ サブシステムのパフォーマンスを測定することもできます。 ストレージ サブシステムのパフォーマンスを測定するために VMFleet を使用する必要があるかどうかを評価します。 |
運用環境のワークロードをデプロイする前に、Azure Local インスタンスのパフォーマンスのベースラインを確立します。 DiskSpd を使用すると、管理者はさまざまなコマンド ライン パラメーターを使用して、インスタンスのストレージ パフォーマンスをテストできます。 DiskSpd の主な機能は、読み取り操作と書き込み操作と出力パフォーマンス メトリック (待機時間、スループット、IOPS など) を発行することです。 |
トレードオフ
設計上のトレードオフは、柱のチェックリストで説明されているアプローチに関連しています。 利点と欠点の例をいくつか次に示します。
冗長性を構築するとコストが増加する
Azure Local ソリューション用のハードウェアを設計して調達する際に、ワークロード RTO と RPO のターゲットやストレージ パフォーマンス要件 (IOPS とスループット) など、ワークロードの要件を前もって理解します。 高可用性ワークロードをデプロイするには、少なくとも 3 台のマシン インスタンスを使用することをお勧めします。これにより、ワークロード ボリュームとデータの 3 方向ミラーリングが可能になります。 コンピューティング リソースの場合は、少なくとも "N+ 1 個の物理マシン" をデプロイしてください。これにより、 インスタンス内の "1 台のマシン分の領域" の容量が常に予約されます。 ビジネス クリティカルまたはミッション クリティカルなワークロードの場合は、回復性を高めるために、"容量に相当する N+2 台のマシン" を予約することを検討してください。 たとえば、インスタンス内の 2 台のマシンがオフラインの場合、ワークロードはオンラインのままです。 この方法では、計画された更新手順中にワークロードを実行しているマシンがオフラインになった場合 (その結果、2 台のマシンが同時にオフラインになる) 場合など、シナリオの回復性が向上します。
ビジネス クリティカルまたはミッション クリティカルなワークロードの場合は、2 つ以上の個別の Azure ローカル インスタンスをデプロイし、ワークロード サービスの複数のインスタンスを別々のインスタンスにデプロイすることをお勧めします。 データ レプリケーションとアプリケーション負荷分散テクノロジを利用するワークロード設計パターンを使用します。 たとえば、 SQL Server の常時接続可用性グループ では、同期または非同期のデータベース レプリケーションを使用して、異なるデータセンター内の個別のインスタンス間で低い RTO ターゲットと RTO ターゲットを実現します。
その結果、ワークロードの回復性が向上し、RTO と RPO のターゲットが減少すると、コストが増加し、適切に設計されたアプリケーションと運用の厳しさが必要になります。
効果的なワークロード計画なしでスケーラビリティを提供すると、コストが増加します
インスタンスのサイズ設定が正しくないと、容量が不足したり、ハードウェアがオーバープロビジョニングされた場合に投資収益率 (ROI) が低下したりする可能性があります。 どちらのシナリオもコストに影響します。
容量の増加は、コストの増加に相当します。 Azure ローカル インスタンスの設計フェーズでは、ワークロードの容量要件に基づいて 、機能とインスタンス マシンの数を適切にサイズ変更 するための適切な計画が必要です。 そのため、ワークロードの要件 (vCPU、メモリ、ストレージ、および X 個の VM) を理解し、予想される増加に加えて、いくつかの余分な ヘッドルーム を許可する必要があります。 "ストレージ切り替え" 設計を使用する場合は、マシンの追加ジェスチャを実行できます。 ただし、デプロイ後にハードウェアを増やすには長い時間がかかる場合があります。 また、アドイン ジェスチャは、初期デプロイ時にインスタンスのハードウェアとマシンの数 (最大 16 台のマシン) を適切にサイズ設定するよりも複雑です。
コンピューターのハードウェア仕様をオーバープロビジョニングし、正しくない数のマシン (インスタンスのサイズ) を選択すると、欠点があります。 たとえば、ワークロード要件がインスタンスの全体的な容量よりもはるかに小さく、ハードウェアの保証期間中にハードウェアの使用が不足している場合、ROI 値が低下する可能性があります。
Azure ポリシー
Azure には、Azure Local とその依存関係に関連する広範な組み込みポリシー セットが用意されています。 上記の推奨事項の一部は、Azure Policy を使用して監査できます。 たとえば、次のことを確認できます。
- ホストと VM のネットワークを保護する必要があります。
- 暗号化されたボリュームを実装する必要があります。
- アプリケーション制御ポリシーは一貫して適用する必要があります。
- セキュリティで保護されたコア要件を満たす必要があります。
Azure Local 組み込みポリシーを確認します。 Defender for Cloud には、組み込みポリシーのコンプライアンス状態を示す 新しい推奨事項 があります。 詳細については、「 Azure Security Center の組み込みポリシー」を参照してください。
Azure Local にデプロイした Azure Arc VM でワークロードが実行されている場合は、拡張セキュリティ更新プログラム ライセンスの作成や変更を拒否するなど、組み込みのポリシーを検討してください。 詳細については、「 Azure Arc 対応ワークロードの組み込みポリシー定義」を参照してください。
Azure ローカル インスタンスにデプロイする Azure ローカル リソースと Azure Arc VM の両方に対するガバナンスを強化するために、カスタム ポリシーを作成することを検討してください。 例えば次が挙げられます。
- Azure への Azure ローカル ホストの登録の監査
- ホストが最新の OS バージョンを実行していることを確認する
- 必要なハードウェア コンポーネントとネットワーク構成の確認
- 必要な Azure サービスとセキュリティ設定の有効化の検証
- 必要な拡張機能のインストールの確認
- Kubernetes クラスターと AKS 統合のデプロイの評価
Azure Advisor の推奨事項
Azure Advisor は、Azure デプロイを最適化するためのベスト プラクティスに従うのに役立つ、パーソナライズされたクラウド コンサルタントです。 VM の信頼性、セキュリティ、コスト効率、パフォーマンス、オペレーショナル エクセレンスの向上に役立つ推奨事項をいくつか次に示します。
次のステップ
この記事で強調表示されている推奨事項を示すリソースとして、Azure アーキテクチャ センターの次の記事を検討してください。
- 主要な推奨事項を示す基本的なアーキテクチャ: Azure ローカル ベースライン参照アーキテクチャ。
- 組織でハイブリッド アプローチが必要な場合は、ハイブリッド ネットワーク アーキテクチャに関連する設計の選択肢を慎重に選択します。 詳細については、「 ハイブリッド アーキテクチャの設計」を参照してください。
次の Azure Local 製品ドキュメントを使用して、実装の専門知識を構築します。
クラウド導入フレームワークのガイダンスを確認します。
クラウド導入フレームワーク の準備手法は、 クラウド導入のために環境を準備する際に顧客をガイドします。 この手法には、Azure クラウド導入環境の構成要素である Azure ランディング ゾーンなどの技術アクセラレータが含まれます。 ハイブリッド クラウド用に環境を準備する方法の詳細については、次の記事を参照してください。