Google Meet は自動でネットワークの状況に適応するため、ネットワークで Meet 用に Quality of Service(QoS)を使用する必要はありません。ネットワークで輻輳が発生しているなどのやむを得ない理由があり、かつネットワーク内にエンドツーエンドの QoS モデルを導入、維持できる場合に限り QoS を使用してください。
QoS を使用する必要がある場合
ネットワークで輻輳が発生し、Meet で特定の QoS を確保する必要がある場合は、次のいずれかのオプションを選択します。
- Meet クライアントに QoS を追加する。
- ネットワーク エッジに QoS を追加する。
オプション 1: Meet クライアントに QoS を追加する
Meet クライアントに QoS を追加すると、企業ネットワーク内の QoS のクライアント マシンに Meet のトラフィックがタグ付けされます。トラフィックがインターネットに送信されると、QoS タグは削除されます。Meet の受信トラフィックは、企業のネットワークに入るとタグ付けされます。
Meet クライアントに QoS を追加するには:
- グループ ポリシー管理コンソールで、Windows の QoS ポリシーを使用して DSCP のマーキングを設定します。
- Meet の会議用にネットワークを準備するで説明されているように、Meet のポート範囲を使用して Meet のトラフィックを特定します。
- 内部ゲートウェイからインターネットに送信されるトラフィックの DSCP タグ付けを削除します。
- インターネットから受信した Meet のトラフィックをタグ付けします。このインターネット トラフィックは、Meet のポート範囲を使用する Real-time Transport Protocol または Real-time Transport Control Protocol(RTP/RTCP)のトラフィックです。
オプション 2: ネットワーク エッジに QoS を追加する
このオプションを使用すると、クライアントの Meet トラフィックは企業ネットワーク内の QoS のネットワーク エッジでタグ付けされます。トラフィックがインターネットに送信されると、QoS タグは削除されます。Meet の受信トラフィックは、企業のネットワークに入るとタグ付けされます。
ネットワーク エッジに QoS を追加するには:
- すべてのネットワーク エッジで、Meet のトラフィックをマーキングするルールを追加します。Meet のトラフィックに完全優先転送(EF)クラスを割り当てて、遅延とジッターを低く抑える必要があります。このトラフィックは、Meet のポート範囲を使用する RTP/RTCP トラフィックです。
- 内部ゲートウェイからインターネットに送信されるトラフィックの DSCP タグ付けを削除します。
- インターネットから受信した Meet のトラフィックを EF クラスでタグ付けします。このトラフィックは、Meet のポート範囲を使用する RTP/RTCP トラフィックです。
- 遅延、ジッター、損失の値を社内でおさえるには、EF トラフィックを優先し、それを低レイテンシまたは厳格な優先度のキューに入れます。EF トラフィックによってネットワーク上の他のトラフィック クラスが制限されないように、事前定義された帯域幅値を超えるレート制限などの予防措置を追加します。
QoS をテストする
ハードウェア ベンダーによって QoS の実装が異なるため、テストが若干異なる場合があります。エンドツーエンドの QoS を微調整する。
- まずは小規模なテスト環境で、1 台のデバイスのパフォーマンスを確認します。
- 個々のネットワーク デバイスを経由するパケットのパスに沿って、ネットワーク パスにクライアント マーキングが反映されていることを検証し、デバイスのキューの個別のドロップとスループットを把握します。
- このページの以下のセクションで、QoS をさらに確認してテストします。
ハブやローエンド スイッチなど一部のノンインテリジェント ネットワーク デバイスは、QoS 機能に完全に対応していない場合があります。アップストリーム デバイスでマーキングされている DSCP 値が変更されていないことを確認してください。こうすることで、ダウンストリームのインテリジェント デバイスは、正しいマーキングに基づいて正しい QoS 戦略を適用できます。
ネットワーク パスにクライアント マーキングが反映されていることを確認する
以下のツールを使用して、正しい DSCP マーキングを確認できます。
- パケット スニッフィング - たとえば、ネットワーク デバイス(AP、ルーター、スイッチ)とエンドデバイス(パソコン)の両方で適切な DSCP マーキングを確認できる Wireshark で、パケット スニッフィングを使用します。ポート ミラーリングまたはスイッチ ポート アナライザ(SPAN)で、キャプチャしたデータをローカルポート ミラーリングのため選択した宛先ポートに送信します。リモート スイッチ ポート アナライザ(RSPAN)などのリモートポート プロトコルは、キャプチャしたデータを分析のためにリモート サーバーに送信できます。
- NetFlow - NetFlow でネットワーク デバイス上の DSCP マーキングを確認できます。DSCP 値はデフォルトでコレクタにエクスポートされます。キャプチャしたデータから 5 タプル(IP、プロトコル、ポート)をフィルタして、特定のアプリケーションの DSCP 値を確認します。
ネットワーク レベルで Meet の QoS パフォーマンスをモニタリングする
Simple Network Management Protocol(SNMP)ベースのモニタリング ツールで、さまざまなキュー使用率とキューのドロップ率の傾向を表示します。アプリケーション レベルで Meet を EF としてマーキングすると、EF 使用率とこのクラスのドロップ率を確認することで、ネットワーク上のインターフェースでの Meet のパフォーマンスを把握できます。
アプリケーション データを集約することで、NetFlow はサイト固有のビューまたはグローバル ビューを重ねあわせたビューを表示できます。
輻輳のシミュレーションと QoS の検証
- テスト環境で、メディアの最大帯域幅を超える複数のトラフィック フローを生成します。たとえば、1 Gbps のパスに対して 2 Gbps のトラフィックを生成します。
- 受信エンドポイントのスループットを比較して、優先度の高いトラフィックが適切に処理されているかどうかを確認します。
ワイヤレス ネットワークの輻輳をシミュレートするには:
- 同じアクセス ポイントへの複数のフローを生成します。たとえば、802.11n の場合はフローごとに 2 x 150 mbps を送信します(802.11n は最大約 180 mbps のスループットをサポートするため)。
- 受信エンドポイントのスループットを確認します。
たとえば、優先度の高いトラフィックによりサービスが向上することを証明するには、Wi-Fi 経由で(同じアクセス ポイントにある、同じ競合ドメインにある)異なるクラスのトラフィックを送信します。優先度の高いトラフィックではドロップが発生せずすべてのスループットが実現しますが、優先度の低いトラフィックでは著しいドロップが発生します。
QoS が想定どおりに動作していることをテストするには、次のコマンドを入力します。
- ベスト エフォートの場合は、「iperf3 -c [IP アドレス] -u -b 150m -t 50 -l 1000B -i 10 -S 0x0」と入力します。
- EF の場合は、「iperf3 -c [IP アドレス] -u -b 150m -t 50 -l 1000B -i 10 -S 0xB8」と入力します。
Google、Google Workspace、および関連するマークとロゴは、Google LLC の商標です。その他すべての企業名および商品名は関連各社の商標です。