次の方法で共有

配信の最適化のテスト

概要

配信の最適化は、企業が Microsoft コンテンツをダウンロードするための帯域幅使用量を管理するのに役立つ強力で便利なツールです。 これは、多数のデバイス、さまざまなコンテンツ サイズなどの大規模な環境で使用するように設計されたソリューションです。配信の最適化は、現在サポートされているバージョンの Windows にネイティブであり、一般的な顧客環境を最大限に活用するための既定の構成を提供します。 配信の最適化は、さまざまな種類のコンテンツを配信するために使用されるため、Microsoft のお客様は環境に最適なダウンロード エクスペリエンスをお楽しみください。 配信の最適化には、次の 3 つのコンポーネントがあります。

  1. HTTP ダウンローダー。
  2. ピアツーピア (P2P) クラウド テクノロジ。
  3. Microsoft Connected Cache。

配信の最適化を使用する最も強力な利点の 1 つは、ユーザーが特定の環境のニーズを満たすために Microsoft コンテンツ配信でダイヤルできるようにする設定を微調整できることです。

結果の監視

配信の最適化は既定でオンになっているので、配信の最適化 PowerShell コマンドレットを使用して 、または Azure の Windows Update for Business Report エクスペリエンスを使用して、"配信の最適化" の Windows 設定を使用して値を監視できます。

お使いの環境で配信の最適化が機能しない場合は、問題の根本に到達するために調査することが重要です。 配信の最適化が適切に動作していることを確認するために、一般的なデバイスを簡単に評価するためのテスト環境を作成することをお勧めします。 まず、2 台のマシン間での配信の最適化の使用をテストするために、"シナリオ 1: 基本セットアップ" を作成する必要があります。 このシナリオは、環境内のノイズを排除して、配信の最適化がデバイスで動作することを妨げるものがないことを確認するように設計されています。 ベースラインを作成したら、テスト環境を拡張して、より高度なテストを行うことができます。

期待と目標

この記事のテスト シナリオの焦点は、主に、P2P を使用したバイトの正常なダウンロードを中心とした配信最適化ポリシーのデモンストレーションに焦点を当てています。 具体的には、次の条件を使用して、ピアツーピアが期待どおりに動作していることを示す目標です。

  • ピアは互いを見つけることができます (たとえば、同じ LAN/サブネット/グループで 、"ダウンロード モード" ポリシーに一致します)。
  • ファイルは、"ダウンロード モード" ポリシー設定でダウンロードされます (DO クラウド、HTTP、およびローカル構成への接続を検証します)。
  • P2P 経由で少なくとも一部のダウンロードが行われている (ピア間の接続を検証します)。

配信の最適化を使用して、ピアリング全体に影響を与えるいくつかの要素。 最も一般的で影響を与える環境要因を考慮する必要があります。

  • キャッシュ内のファイルの数とデバイスの数は、全体的なピアリングに大きな影響を与えます。各クライアントから一度にピアリングに使用できるファイルの数が設定されているため、ピアリング デバイスが特定のファイルを提供していない可能性があります。
  • ファイル サイズとインターネット接続の信頼性が重要です。 P2P を使用する最小ファイル サイズを決定するための配信の最適化設定があります。 さらに、インターネット接続は、配信最適化クライアントがクラウド サービス API 呼び出しを行い、ファイルのダウンロードを開始する前にメタデータ ファイルをダウンロードできるように、十分にオープンで信頼性が高い必要があります。
  • 配信の最適化ポリシーが役割を果たすことができます。 一般に、配信の最適化の設定と既定の配信の最適化に関するリファレンスを理解することが重要です - Windows 展開 |Microsoft Docs..

配信の最適化はハイブリッド P2P プラットフォームです

  • 複数のソース (HTTP とピア) から並列にダウンロードする配信の最適化のハイブリッド アプローチは、コンテンツを配信する最適なソースを常に評価する大規模な環境では特に重要です。 また、参加しているデバイス間でのコンテンツ キャッシュの分散は、より多くのピアが利用可能になると、配信の最適化で帯域幅の節約を見つける能力に貢献します。

  • ダウンロードが開始された時点で、配信最適化クライアントは HTTP ソースからのダウンロードとピアの検出を同時に開始します。 ファイルが小さい場合、ピアが使用可能であっても、ピアに接続する前に HTTP ソースからほとんどのバイトをダウンロードできます。 ファイルと品質の高い LAN ピアが大きい場合、HTTP 要求率は 0 に近くなりますが、HTTP からの最初の要求を行った後にのみ低下する可能性があります。

  • 次のセクションでは、2 つのテスト シナリオによって、HTTP ピアとピアからのバイト数が異なる結果がどのように生成されるかを確認します。 これらのシナリオでは、コンテンツのダウンロード元となる最適な場所を継続的に評価する配信の最適化が示されます。

テスト シナリオ

シナリオ 1: 基本的なセットアップ

ゴール： 制御されたテスト環境で 2 台のマシンを使用して配信の最適化ピア ツー ピア テクノロジがどのように機能するかを示します。

予想される結果: マシン 1 はピアから 0 バイトをダウンロードし、マシン 2 はピアから 50 から 99% をダウンロードします。

テスト マシンのセットアップ

セットアップ チェックリスト 値/説明
使用されたマシンの数 2
仮想マシン/物理デバイス 2
Windows OS のバージョン Windows 10 (21H2) と Windows 11 (21H2)
RAM 8 GB
ディスク サイズ 127 GB
ネットワーク 同じネットワーク (企業ネットワークを代表するネットワーク) に接続されています。
Windows 更新プログラムを一時停止する これにより、テスト環境が制御され、テスト中に他のコンテンツが利用できなくなるため、テストの結果が変更される可能性があります。 問題が発生し、ピアリングが発生しない場合は、最初のマシンで 'Get-DeliveryOptimizationStatus' を使用して、接続されているピアのリアルタイム リストを返します。
すべてのストア アプリが最新の状態であることを確認する これにより、テスト中に新しい予期しない更新プログラムがダウンロードされるのを防ぐことができます。
配信の最適化 'ダウンロード モード' ポリシー 2 (グループ)(各マシンに設定)
配信の最適化 'GroupID' ポリシー 各テスト マシンで 同じ 'GUID' を設定します。 GUID は必須の値であり、PowerShell '[guid]::NewGuid().' を使用して生成できます。
Windows 11 デバイスでは、 配信の最適化 'ピアの選択を制限する' ポリシーのみを設定する必要があります 0 NAT (各マシンに設定)。 Windows 11 の既定の動作は、'2-Local Peer Discovery' に設定されています。 テスト目的で、これは NAT にスコープを設定する必要があります。

テスト手順

マシンごとに次の一連の手順が使用されます。

  1. PowerShell コンソールを "管理者" として開きます。

    • DO キャッシュ 'Delete-DeliveryOptimizationCache' をクリアします。
    • 'Get-DeliveryOptimizationStatus' を実行します。

  2. MS ストアを開き、"アスファルト凡例 9" を検索します。 [ 取得 ] を選択してコンテンツのダウンロードを開始します (コンテンツ サイズ: ~3.4 GB)。

マシン #1

  • 'Test Instructions' を実行する

    Windows 10 Windows 11
    Windows 10 21H2 - マシン 1 - 基本テスト。 Windows 11 21H2 - マシン 1 - 基本テスト。
    計測結果
    - コンテンツをダウンロードする最初のマシンにピアが見つかりませんでした。
    - 'TotalBytesDownloaded' はファイル サイズと同じです。
    - 将来のピアがコンテンツを使用できるように、状態はコンテンツを "キャッシュ" に設定します。
    - ダウンロードがフォアグラウンドで行われました。
    - DownloadMode が 'Group' に設定され、ピアが見つかりませんでした。
    - Windows 10 デバイスと Windows 11 デバイスの間に個別の観察は表示されません。

    5 分待ちます。

コンピューター #2

  • 'Test Instructions' を実行する

    Windows 10 Windows 11
    Windows 10 21H2 - マシン 2 - 基本テスト。 Windows 11 21H2 - マシン 2 - 基本テスト。
    計測結果 計測結果
    - コンテンツのピアが見つかり、合計バイトの 87% がピアから取得されました。
    - 1 つのピアがコンテンツに対して検出されました。これは、ピアリング グループに 2 つのデバイスしかないため、想定されています。
    - ダウンロード モードは "グループ" に設定されましたが、グループ モードには LAN デバイスとグループ デバイスの両方が含まれるため、検出された場合は配信の最適化によって LAN ピアが優先されます。 したがって、'BytesFromLanPeers' は、'BytesFromGroupPeers' が表示されないバイトを示します。
    - "DownloadDuration" は、マシン間でほぼ同じです。    		 - コンテンツのピアが見つかり、合計バイトの 90% がピアから取得されました。
    - その他のすべてのポイントは、Windows 10 の結果と同じです。

シナリオ 2: 事前セットアップ

ゴール：

配信の最適化ピア ツー ピア テクノロジが制御されていない環境でどのように機能し、3 台のマシンに拡張されるかを示す

予想される結果:

マシン 1 はピアから 0 バイトをダウンロードし、マシン 2 はピアを見つけ、ピアから 50 から 99% をダウンロードします。 マシン 3 は 2 つのピアを見つけ、ピアから 50 から 99% をダウンロードします。

テスト マシンのセットアップ

セットアップ チェックリスト 値/説明
使用されたマシンの数 3
仮想マシン 3
Windows OS のバージョン Windows 10 (21H2)
RAM 8 GB
ディスク サイズ 127 GB
ネットワーク 同じネットワーク (企業ネットワークを代表するネットワーク) に接続されています。
配信の最適化 'ダウンロード モード' ポリシー 2 (グループ)(各マシンに設定)。
配信の最適化 'グループ ID' ポリシー 各テスト マシンで 同じ 'GUID' を設定します。 GUID は必須の値であり、PowerShell '[guid]::NewGuid().] を使用して生成できます。(https://devblogs.microsoft.com/scripting/powertip-create-a-new-guid-by-using-powershell/)'。
配信の最適化 'http からのバックグラウンド ダウンロードの遅延' ポリシー 60 (各マシンに設定)。
配信の最適化 'http Policy からのフォアグラウンド ダウンロードの遅延 60 (各マシンに設定)。

テスト手順

マシンごとに次の一連の手順が使用されます。

  1. DO キャッシュ 'Delete-DeliveryOptimizationCache' をクリアします。
  2. MS ストアを開き、"アスファルト凡例 9" を検索します。 [ 取得 ] を選択してコンテンツのダウンロードを開始します (コンテンツ サイズ: ~3.4 GB)。
  3. 管理者として PowerShell コンソールを開きます。 'Get-DeliveryOptimizationStatus' を実行します。

マシン #1:

  • 'Test Instructions' を実行する

    出力: Windows 10 (21H2)

    Windows 10 21H2 - マシン 1 - 高度なテスト。

計測結果

  • デバイスのグループ内の最初のダウンロードでは、HTTP から送信されるすべてのバイト 'BytesFromHttp' が表示されます。
  • ストア アプリはストア アプリ内のユーザーによって開始されるため、ストア アプリがデバイス上でダウンロードを実行し、フォアグラウンドで実行しているため、ダウンロードは "フォアグラウンド" になります。
  • ピアが見つかりません。

5 分待ちます。

マシン #2:

  • 'Test Instructions' を実行する

    アウトプット Windows 10 (21H2)

    Windows 10 21H2 - Machine 2 - Advanced Test。

計測結果

  • 'PercentPeerCaching' は 99.8% です
  • まだ 'BytesFromHttp' ソースが使用されています
  • 1 つのピアが見つかりました
  • "BytesFromLanPeers" で示されているように、すべてのピアリングは LAN 上のデバイスから行われました

マシン #3:

  • 'Test Instructions' を実行する

    アウトプット： Windows 10 (21H2)

    Windows 10 21H2 - マシン 3 - 高度なテスト。

計測結果

  • 'PercentPeerCaching' は、マシン #2 とほぼ同じ 99.7% です。
  • これで、2 つのピアが見つかりました。
  • 'BytesFromHttp' の値で見られるように、HTTP ソースからまだダウンロードしています。

テスト グループ内のすべてのマシンのピア ソーシング監視

配信最適化テクノロジの分散特性は、各テスト マシンで 'Get-DeliveryOptimizationStatus' コマンドレットを再実行すると明らかです。 それぞれに、'BytesToLanPeers' フィールドに新しい値が設定されます。 このテストでは、使用可能なピアが増えるにつれて、バイトのダウンロード要求がピアリング グループ全体に分散され、ピアリング コンテンツのソースとして機能することを示します。 各ピアは、他方をサービスする役割を果たします。

アウトプット： マシン 1

マシン 1 から提供される 'BytesToPeers' は '5704426044' です。 これは、グループ内の 2 つのピアによってダウンロードされた合計バイト数を表します。

Windows 10 21H2 - マシン 1 - Advanced BytesToPeers テスト。

アウトプット： マシン 2

マシン 2 から提供される 'BytesToPeers' は '1899143740' です。 使用可能なバイトを持つピアがグループに 2 つある場合は、バイトの分布がマシン 1 またはマシン 2 のいずれかであることに注意してください。

Windows 10 21H2 - マシン 2 - Advanced BytesToPeers テスト。

アウトプット： マシン 3

マシン 3 から提供される 'BytesToPeers' は '0' です。 これは、他のピアがこのピアからバイトをダウンロードしていないことを意味します。これは、グループ内の最後のマシンであるために予想されます。

Windows 10 21H2 - マシン 3 - Advanced BytesToPeers テスト。

まとめ

配信の最適化を使用すると、帯域幅を最適化するためにお客様の環境に大きな影響を与えることができます。 ピアツーピア テクノロジは、どの組織にも柔軟に対応できるように設計された多くの構成を提供します。 配信の最適化では、さまざまなソースにまたがる分散キャッシュを使用して、各デバイスで使用されるリソースを制限しながら、最適なダウンロード エクスペリエンスを確保します。

このドキュメントに記載されているテスト シナリオは、制御されたテスト環境を示すのに役立ち、更新によってピアリングの結果が中断されるのを防ぐことができます。 もう 1 つの実世界のケースでは、ピア間で使用できるコンテンツをコンテンツのソースとして使用する方法を示します。

テスト中に問題が見つかった場合、配信の最適化 PowerShell コマンドレット は、環境内で何が起こっているかを説明するのに役立つツールです。