この記事のWVDは”Windows Virtual Desktop Spring 2020 Release”が対象です。
前回の記事に続いてWindows Virtual Desktop エクスペリエンス見積もりツール を試していきます。 今回は自宅のクライアント以外からラウンドトリップ時間を確認していきます。 具体的には中国本土から確認します。
中国本土からのテストですが、Alibaba Cloud の ECS を利用します。 中国本土のリージョンに Windows Server 2019 を起動し、Web ブラウザ ( Internet Explorer ) からWindows Virtual Desktop エクスペリエンス見積もりツール にアクセスし、ラウンドトリップ時間をリージョンごとに確認します。 中国本土以外外にも香港、シンガポールリージョンと東京リージョンも参考として確認します。
Alibaba Cloud の中国リージョンは Document Center で確認可能です。 いつの間にか 10 リージョンまで増えていました。
| Region | City | Region ID | Number of zones |
|---|---|---|---|
| China (Qingdao) | Qingdao | cn-qingdao | 2 |
| China (Beijing) | Beijing | cn-beijing | 8 |
| China (Zhangjiakou) | Zhangjiakou | cn-zhangjiakou | 3 |
| China (Hohhot) | Hohhot | cn-huhehaote | 2 |
| China (Ulanqab) | Ulanqab | cn-wulanchabu | 2 |
| China (Hangzhou) | Hangzhou | cn-hangzhou | 8 |
| China (Shanghai) | Shanghai | cn-shanghai | 7 |
| China (Shenzhen) | Shenzhen | cn-shenzhen | 5 |
| China (Heyuan) | Heyuan | cn-heyuan | 2 |
| China (Chengdu) | Chengdu | cn-chengdu | 2 |
しかし、コンソール上で確認すると 11 リージョンあることがわかります。”Guangzhou” がドキュメントに記載の無いリージョンです。
以下、中国本土11リージョンと香港、シンガポール、東京の14地点からWindows Virtual Desktop エクスペリエンス見積もりツール を利用した結果となります。
Hangzhou
Azure の East Asia までのラウンドトリップ時間は 5 ms です。
Shanghai
Azure の East Asia までのラウンドトリップ時間は 8 ms です。
Qingdao
Azure の East Asia までのラウンドトリップ時間は 2 ms です。
Beijing
Azure の East Asia までのラウンドトリップ時間は 2 ms です。
Zhangjiakou
Azure の East Asia までのラウンドトリップ時間は 90 ms です。
Hohhot
Azure の East Asia までのラウンドトリップ時間は 3 ms です。
Ulanqab
Azure の East Asia までのラウンドトリップ時間は 105 ms です。
Shenzhen
Azure の East Asia までのラウンドトリップ時間は 4 ms です。
Heyuan
Azure の East Asia までのラウンドトリップ時間は 3 ms です。
guangzhou
Azure の East Asia までのラウンドトリップ時間は 260 ms です。
Chengdu
Azure の East Asia までのラウンドトリップ時間は 5 ms です。
Hongkong
Azure の East Asia までのラウンドトリップ時間は 3 ms です。
Singapore
Azure の Southeast Asia までのラウンドトリップ時間は 4 ms です。
Tokyo
Azure の Japan East までのラウンドトリップ時間は 4 ms です。
ラウンドトリップ時間の結果を表にまとめました。
| Alibaba Cloud Region | Azure Region | Round Trip (ms) |
|---|---|---|
| China (Qingdao) | East Asia | 2 |
| China (Beijing) | East Asia | 2 |
| China (Zhangjiakou) | East Asia | 90 |
| China (Hohhot) | East Asia | 3 |
| China (Ulanqab) | East Asia | 105 |
| China (Hangzhou) | East Asia | 5 |
| China (Shanghai) | East Asia | 8 |
| China (Shenzhen) | East Asia | 4 |
| China (Heyuan) | East Asia | 3 |
| China (Chengdu) | East Asia | 5 |
| China (guangzhou) | East Asia | 260 |
| Hongkong | East Asia | 3 |
| Singapore (Singapore) | Southeast Asia | 4 |
| Japan (Tokyo) | Japan East | 4 |
気になったの点は2つあります。 Zhangjiakou , Ulanqab , guangzhou の遅延が大きいことが1点目。2点目はそれ以外のリージョンから Azure East Asia (Hongkong) への Round Trip が小さすぎる点です。 Alibaba Cloud の Hongkong リージョンから Azure の East Asia に対しての 3ms はわかります。それ以外の例えば Beijing や Qingdao は 2 ms 、他も1桁台のラウンドトリップ時間です。 物理的な距離を考えても遅延が小さすぎます。
Windows Virtual Desktop エクスペリエンス見積もりツール はどうやって遅延を測定しているのでしょうか。 CDN の近いノードにキャッシュした内容を応答しているのではないか？と推測されますが実際のところはわかりません。。。
せっかく中国にインスタンスを立ち上げたので Windows Virtual Desktop の仮想マシンに接続出来ることも確認してみます。 以前の記事でも Alibaba Cloud の上海リージョンと北京リージョンから利用出来ることは確認していました。 今回も接続を確認するとともに Windows Desktop Client の接続情報の確認機能からラウンドトリップ時間を確認し、Windows Virtual Desktop エクスペリエンス見積もりツールで確認できるラウンドトリップ時間と差異があるかを見ていきます。
Alibaba Cloud の北京リージョンの Windows Server 2019 にWindows Desktop Client をインストールし、フィードを取得します。
以下はフィード取得後の画面なのですが、ここに至るまで何度も認証を求められました。 以前のテストではそのようなことはなかったのですが何かおかしな感じです。
次に、実際のリソースにアクセスすると失敗しました。
エラーメッセージは以下の通りです。 Error code は “0x300000d” です。 メッセージ”The remote resource can’t be reached.” からクライアントから Azure East Asia にある Windows Virtual Desktop の管理コントロールプレーンにネットワーク的に接続出来ていないようです。
| [Window Title] Remote Desktop [Content] The remote resource can’t be reached. Check your connection and try again or ask your network administrator for help. [Expanded Information] Error code: 0x300000d Extended error code: 0x0 Timestamp (UTC): 2020-10-16T17:11:56.902Z Activity ID: e8a979f0-9f23-4239-8402-586260d30000 |
前回の記事でテストしたのは2020年7月です。 今日はたまたま接続出来ないだけなのか、出来なくなってしまったのかは不明です。 経路上どこに問題があったのか、北京以外のリージョンではどうなのか、切り分けできるところはあるのですが時間切れで今回は調査を断念します。 今回の記事を書くにあたり Alibaba Cloud の従量課金のインスタンスの自動リリースを1時間で設定しており、上記のエラーのあとほどなくして中国本土の11台の仮想マシンは自動リリースされてしまったということがありました。
なお、中国本土の11台の稼働マシンとは若干をおいて作成した東京リージョンの仮想マシンが残っていたのでこちらでも接続を確認します。
Windows Server 2019 上に Windows Desktop Client をインストールし、フィードを取得します。 こちらは問題なく実施出来ました。 北京リージョンであったAzure AD 認証の繰り返しのような挙動もありませんでした。
Windows Virtual Desktop の仮想マシンにも問題なく接続出来ました。
今回のテストでわかったことは、Windows Virtual Desktop エクスペリエンス見積もりツール で確認できるラウンドトリップ時間は正確ではない可能性があることです。 先に書いた通り、Azure の East Asia (Hong Kong)へのラウンドトリップ時間が 北京も青島も上海も 数ms であるはずがないからです。 仮説として考えた CDN の介在ですが、ツールの性質上、Azure 側で CDN を経由するように構成することもあまり考えられません。
あとは、Alibaba Cloud の北京リージョンから Windows Virtual Desktop を利用出来なかったことも気になります。 一時的なものなのかそうではないかは今日の結果だけではわからないので別日に再度確認する、他のリージョンでも確認するなど別途確認することになりそうです。
最後に。今回のテストは1時間もかからないものでしたが、そのわずか1時間で中国の11地点でサーバ立ち上げが出来ること、その料金も合計で数百円もかからないこと、それを日本にいる日本人の私が簡単に実施できること、この点は Alibaba Cloud の最大の強みだなと再認識しました。
今回の記事は以上となります。
