Microsoft Connected Cache に関してよく寄せられる質問
はい、できます。 Microsoft Connected Cache は無料サービスです。
ISP として、ネットワークはバックボーンの負荷を軽減し、サポートされている Microsoft 静的コンテンツのカスタマー ダウンロード エクスペリエンスを向上させることができます。 また、CDN のコストを節約するのにも役立ちます。
Microsoft Connected Cache は、Akamai、Lumen、Edgecast などの複数の CDN から提供される静的コンテンツをオフロードすることで、ピアリングを補完します。 OS の更新プログラム、アプリ、ソフトウェアのインストールなどの静的コンテンツは、8075 経由で提供できません。 そのため、Microsoft とピアリングしている場合でも、接続済みキャッシュをインストールするとメリットが得られます。
いいえ。秘密保持契約は必要ありません。
- Azure サブスクリプション
- Microsoft Connected Cache をホストするハードウェア
- 任意の物理サーバーまたは VM 上の Ubuntu 22.04 LTS。
注意
Microsoft Connected Cache は Azure IoT Edge を使用してデプロイおよび管理され、Ubuntu 22.04 は Azure IoT Edge Tier 1 オペレーティング システムです。 さらに、Microsoft Connected Cache モジュールは Ubuntu 22.04 LTS 用に最適化されています。
推奨されるハードウェア構成を次に示します。
Microsoft Connected Cache Machine クラス | シナリオ | トラフィック範囲 | VM/ハードウェアに関する推奨事項 |
---|---|---|---|
Microsoft Edge | 小規模な ISP またはリモート サイトの場合は、大規模なネットワークの一部です。 | < 5 Gbps ピーク | VM 最大 8 コア 最大 16 GB のメモリ 1 500 GB SSD |
メトロ POP | ISP、IX、またはトランジット プロバイダーの場合、ネットワーク内のトラフィック量が中程度で、1 つ以上のキャッシュ ノードが必要になる可能性があります。 | 5 ~ 20 Gbps のピーク | VM またはハードウェア 16 コア* 32 GB メモリ 2 - 3 500 GB SSD |
データ センター | 毎日大量のトラフィックを提供する ISP、IX、またはトランジット プロバイダーの場合、複数のキャッシュ ノードのデプロイが必要になる場合があります。 | 20 ~ 40 Gbps のピーク | ハードウェアについては、以下のサンプル スペックを参照してください: 32 以上のコア* 64 GB 以上のメモリ 4 - 6 500 - 1 TB SSD** |
*PCIe バージョン 3 以降のシステム (チップセット、CPU、マザーボード) が必要です。
**ドライブ速度は重要であり、より高いエグレスを実現するには、m.2 PCIe スロット (バージョン 4 以上) で SSD NVMe を使用することをお勧めします。
1 人の顧客が、次のハードウェア仕様を使用して 30s Gbps 半ばのエグレス レートを実現できます。
- Dell PowerEdge R330
- 2 x Intel(R) Xeon(R) CPU E5-2630 v3 @ 2.40 GHz、合計 32 コア
- 48 GB、マイクロン テクノロジー 18ASF1G72PDZ-2G1A1、速度: 2133 MT/秒
- 4 - トランセンド SSD230s 1 TB SATA ドライブ
Intel Corporation イーサネット 10G 2P X520 アダプター (リンク集約)
Microsoft Connected Cache はソフトウェア専用のキャッシュ ソリューションであり、ソフトウェアをホストするために独自のサーバーを提供する必要があります。
Microsoft Connected Cache は読み取り集中型アプリケーションであるため、SSD の使用を強くお勧めします。 また、パフォーマンスを向上させるために複数のドライブを使用することをお勧めします。
手動 CIDR ブロックまたは BGP を使用してトラフィックをルーティングできます。 複数の Microsoft 接続キャッシュがある場合は、必要に応じて CIDR ブロックのサブセットを各キャッシュ ノードに割り当てることができます。 ただし、Microsoft Connected Cache には自動負荷分散があるため、すべてのトラフィックをすべてのキャッシュ ノードに追加することをお勧めします。
負荷分散を追加する必要はありません。 キャッシュ ノードの報告された正常性に基づいて同じ CIDR ブロックを提供する複数のキャッシュ ノードがある場合、このサービスはルーティング トラフィックを処理します。
推奨されるハードウェア テーブルに記載されているように、推奨される構成では、2 ポート リンク集約 NIC と 4 つのキャッシュ ドライブを使用して、40 Gbps の最大エグレスの近くを実現します。 必要なキャッシュ ノードの数を見積もるのに役立つ機能が近日公開予定です。 ISP が複数の国またはリージョンにまたがる場合は、国またはリージョンごとに個別のキャッシュ ノードを設定できます。
ハードウェアを管理しており、トラフィックとエンド カスタマーに基づいて場所を選択できます。 ルーターがある場所、またはトラフィックの密度が高い場所、またはその他のパラメーターを選択できます。
コンテンツの要求が行われると、NGINX は元の取得からキャッシュ コントロール ヘッダーを確認します。 そのコンテンツの有効期限が切れている場合、NGINX は新しいコンテンツのダウンロード中に古いコンテンツを引き続き提供します。 コンテンツは 30 日間キャッシュされます。 コンテンツはホット キャッシュ パス (オープン ハンドルなど) に 24 時間存在しますが、ディスク上には 30 日間存在します。 ドライブがいっぱいになり、nginxは独自のアルゴリズムに基づいてコンテンツを削除し始めます。
キャッシュされたコンテンツの詳細については、「 配信の最適化」と「Microsoft Connected Cache コンテンツ エンドポイント - Windows 展開」を参照してください。
現在、Microsoft Connected Cache は Xbox または Teams コンテンツをサポートしていません。 ただし、Xbox コンテンツのサポートは優先度が高く、近日中にこの機能が予定されています。 利用可能になるとすぐにお知らせします。
いいえ。現在、IPV6 はサポートされていません。 今後サポートする予定です。
既に世界中の多くの国や地域で ISP のオンボードに成功しており、肯定的なフィードバックを受けています。 ただし、CIDR ブロックの一部からいつでも開始して、接続キャッシュのパフォーマンスをテストしてから、より多くの顧客に拡張できます。
Microsoft Connected Cache は、クライアント要求によってウォームされたコールド キャッシュです。 クライアントはコンテンツを要求し、それがキャッシュを埋めるものです。 ピーク外のキャッシュフィルは必要ありません。 Microsoft Connected Cache は、クライアント デバイスと同様に、さまざまな CDN プロバイダーに問い合わせてください。 Microsoft Connected Cache からのトラフィック フローは、現在これらの CDN プロバイダーに転送する方法によって異なります。 コンテンツは、サード パーティの CDN または AFD から取得できます。
Microsoft は、Microsoft が提供するコンテンツの配信に十分な容量、冗長性、パフォーマンスを確保するために、第 1 およびサード パーティの CDN プロバイダーを動的に組み合わせて利用しています。 通知なしに変更される可能性があるため、利用する CDN ベンダーの一覧は提供していませんが、エンドポイントは一般の知識です。 エンドポイントに対して一連の DNS 参照を実行する場合 (たとえば tlu.dl.delivery.mp.microsoft.com)、特定の時点でローテーションされた CDN または CDN を特定できます。
$ dig +noall +answer tlu.dl.delivery.mp.microsoft.com |grep -P "IN\tA"
c-0001.c-msedge.net。 20 IN A 13.107.4.50
$ whois 13.107.4.50|grep "Organization:"
組織: Microsoft Corporation (MSFT)
私はネットワーク サービス プロバイダーであり、ダウンストリームのトランジット顧客を持っています。 ダウンストリームトランジットのお客様の 1 人が Microsoft Connected Cache にオンボードしている場合、トラフィックにどのような影響がありますか?
ダウンストリームのお客様が Microsoft Connected Cache ノードをデプロイする場合、キャッシュ コントローラーは、その ASN のトラフィックを処理するときにダウンストリーム ASN を優先します。
最初に、NOC ロールのメールが PeeringDB ページで正しいことをチェックします。 NOC ロールに関連付けられている電子メールが正しい場合は、送信者の "microsoft-noreply@microsoft.com" からのメールとメールの件名 (スパム フォルダー内の "Microsoft 接続キャッシュ検証コードはこちら") を検索します。 それでも見つかりませんか? メール管理者ルールで送信者 microsoft-noreply@microsoft.com
からのメールが許可されていることを確認します。
BGP ルーティングは、トラフィックをルーティングする自動方法として設定できます。 Microsoft Connected Cache での BGP の使用方法の詳細については、「 BGP ルーティング」を参照してください。
8k メッセージのクォータに達しても、接続キャッシュ機能は影響を受けません。 クライアント デバイスは、引き続き通常どおりコンテンツをダウンロードします。 また、8k メッセージの上限を超えて課金されることもないため、有料プランの取得についてまったく心配する必要はありません。 Connected Cache は常に無料サービスになります。 機能が影響を受けない場合は、何が必要ですか? 代わりに、構成またはエッジのデプロイに関するメッセージが影響を受けます。 つまり、接続キャッシュの更新要求があり、1 日あたりのクォータに達した場合、接続キャッシュが更新されない可能性があります。 その場合は、次の日の更新を待つだけです。 これは早期プレビューの制限に過ぎません。パブリック プレビュー中の問題ではありません。
Microsoft Connected Cache の詳細なサポートについては、「 Microsoft Connected Cache for ISP (パブリック プレビュー)の問題のトラブルシューティング」を参照してください。