こんにちは、やまぱんです。
こんにちは、アーキテクトのやまぱんです。
補足コメントや質問、いいね、拡散、是非お願いします🥺!
間違ってたら優しく教えてください!
今回は、Azure の ExpressRoute (プライベート接続) の検証環境をつくるため OCI と連携してみました。
特に普段 Azure 使ってる側の立場で書いてみました。
触らなくてもイメージしやすいように画面ショットは豊富に入れたつもりです。
もしかしたら逆に多くて見にくいかもしれません。
最後に RTT も ExpressRoute - FastConnect 経由と、Public IP 経由 とで比較してました。
さて、はじめましょう!!
いきなりですがここで注意点😲❣
「私は以前この検証をするぞ!!」と意気込んで OCI アカウントを Osaka リージョン を指定して Oracle Free Tier アカウント を作ってしまいました。Tokyo リージョンで作りましょう。
結論からいうと OCI Osaka リージョン では今回の検証はできません。
詳細後述します🤞
モチベ
通常 ExpressRoute の検証はプロバイダーとの契約が必要だったり、敷居が高いのですが、OCI を使うことで自宅にいながら UI 操作のみでできるようになりました。
このことに関しては下記の記事でも触れられています。
下記で書かれている。「Oracle Cloud Infrastructure FastConnect (L3: Private Peering)」 が今回の内容にあたります。
そもそもの ExpressRoute についてはこちらが参考になります。
今回のシナリオに関する MS 公式ドキュメント
やりたいこと
一言で言えば 「Azure と OCI を専用線で接続して、プライベート接続を実現したい」です。
簡単にいつもながらの大変恐縮なフリーハンドな図を起こすとこんな感じの環境を作りたいです。
*Subnet は省略、Public IP アドレスも省略してます
ざっくり用語解説
もしかしたら正確さにかけるかもしれませんが、以下のような理解です。
- ExpressRoute: Azure の専用線接続サービス、ExpressRoute 回線や ExpressRoute Circuit も本記事の中では基本的に同じものを指します。
- FastConnect : OCI の専用線接続サービス
- VNet: Azure の上のプライベートネットワーク
- VCN :VCN(Virtual Cloud Network)、 OCI の上のプライベートネットワーク
- 仮想ネットワークGW(ERGW) : Azure の仮想ゲートウェイサービス。仮想ネットワークゲートウェイの種類の一つに ERGW (ExpressRoute Gateway)がある。
- DRG:OCI の仮想ゲートウェイサービス。動的ルーティング・ゲートウェイ(Dynamic Routing Gateway)
前準備
OCI アカウントの準備
以下から Tokyo リージョン を指定してアカウントを開設する。
結構アカウント開設にはクセがあります。
氏名・住所などは 半角英語で入力しましょう。
クレカの入力とかのところで一度はつまるはず。
ちなみにサポートに問い合わせしても、解決しませんでした😢
下記にアカウント作成向けの記事もありますので紹介しておきます。
Azure アカウントの準備
こちらは普段から Azure を利用しているので割愛します。
以下参考になるかも。
ただし VPNGW は無料サービスの中にありますが、ERGW はないので無料アカウントでは使えないかもしれません。
環境構築
Azure ひな形環境の構築
今回まず、こちらでひな形環境を作りましたが、Azure Portal で手動で好きに作っていただいても構いません。
- ひな形環境概要
1つのリソースグループに 1 つの Vnet をデプロイして、 同じサブネットに 2 つの VM (Windows と Ubuntu) をデプロイします
今回は主に Ubuntu を利用します。
以下今回のひな形環境情報
- リソースグループ:RG-ER-test
- VNet:VNet-Hub (10.100.0.0/16) , Subnet:Hub-Subnet (10.100.1.0/24)
- VM (Ubuntu) : Hub-Ubu , Private IP:10.100.1.5 , Public IP : 4.216.97.253
- VM (Windows) : Hub-Win , Private IP:10.100.1.4 , Public IP : 4.216.97.246
- NSG : Subnet(Hub-Subnet) に紐づけている
Ubuntu に SSH して apt update しておきます。
sudo apt update
OCI ひな形環境の構築
こちらは手動で 1つの VM をつくります。
秘密鍵と公開鍵の作成
OCI の VM は ID / password 認証ができないみたいなので準備します。
以下コマンドで作成できます。
VM 作成時に ".pub の方"(公開鍵) をアップロード、 ".pub がつかない方"(秘密鍵) は ssh する際に使います。
cd 【秘密鍵と公開鍵を生成したい場所】
ssh-keygen -q -t ed25519 -C '' -N '' -f id_rsa
OCI VM の作成
- ハンバーガーメニュ → 左ペインのメニューから コンピュート → インスタンス より作成
下記のように作成します。
OS は Ubuntu 、ここで先ほど作成した .pub ファイルをアップロードしておきます。
以下 OCI VM の情報
- OS:Ubuntu 20.04
- Public IP:138.3.208.58
- Private IP:10.0.0.212
- VCN (Virtual Cloud Network) : vcn-20240228-1242 (10.0.0.0/16)
*これはここからは確認できません。VCN の画面から確認 - サブネット:subnet-20240228-1242
- ホスト名 : wm-oci-ubu
- ユーザー名:ubuntu
接続確認
先ほど作成した、秘密鍵を指定して SSH できること確認
ssh -i .\id_rsa ubuntu@138.3.208.56
ついでに apt-update しておきます。
sudo apt update
Azure : ExpressRoute (ExpressRoute Circuit) 回線の作成
Azure 側で ExpressRoute を作ります。
イメージとしては [Azure VM → ERGW(仮想ネットワークGW) → ExpressRoute回線(ExpressRoute Circuit)] といった接続イメージになります。
OCI : DRG (Dynamic routing gateway) の作成とアタッチ
DRG は Azure でいうところの 仮想ネットワーク GW / ERGW
-
DRG (Dynamic routing gateway) を VCN (Virtual Cloud Nerwork) にアタッチ
作成した DRG の左ペインのメニュー → 仮想クラウド・ネットワーク・アタッチメント → 仮想クラウド・ネットワーク・アタッチメントの作成
以下のように作成
添付名 オプション: VCN-attach01
Fast Connect の作成
続いて Fast Connect の作成です。(Azure でいうところのExpressRoute Circuit / 回線)
- ハンバーガーメニュ → 左ペインのメニューから ネットワーキング → FastConncet より作成します。
- Fast Connect - 接続の作成 - 接続タイプ
注意:ここで Osaka リージョンで OCI フリーアカウントを作っている場合は ”Micorosoft Azure : ExpressRoute” が選択できません。
フリーアカウントの場合、アカウントの作り直しか、Tokyo リージョンで作った人のアカウントに招待してもらう必要があります。(ちなみに、アカウントの作り直しは何度もトライしましたがカードのところで躓いてしまい出来ませんでした)
-
Microsoft Azureへのアクセス
https://docs.oracle.com/ja-jp/iaas/Content/Network/Concepts/azure.htm
-
Oracle Cloudコンソール・ユーザーの追加
https://docs.public.oneportal.content.oci.oraclecloud.com/ja-jp/iaas/Content/applications-manager/add-apps-users.htm
-
Fast Connect - 接続の作成 - 構成
ここで Azure の ExpressRoute の画面で確認したサービスキーを入力、任意のIPアドレスを入力します。
今回は以下のように入力。そして [作成] をクリック
-
Fast Connect の完成
数分~10分ほど待つと、ライフライクル状態が プロビジョニング済に変わる。
これ (プロビジョニング済) で OCI (の FastConnect) と Azure (のER 回線) 自体は専用線で接続されました。が、まだ VM 同士は疎通できません。ポンチ絵の太い部分がつながったに過ぎません。
Azure : 仮想ネットワーク GW (ERゲートウェイ) の作成
VNet GW (ExpressRoute(ERGW))を作成し、VNnetとExpressRoute 回線をつなげます。
サブスクリプション XXXXXX-XXX-Ext
リソース グループ RG-ER-test
名前 ER-GW-OCI
地域 Japan East
SKU Standard
仮想ネットワーク Vnet-Hub
サブネット GatewaySubnet (10.100.0.0/24)
ゲートウェイの種類 ExpressRoute
ちなみにどれくらいかかるかというと、今回およそ 20 分今回かかりました。
トイレに行くなり、ストレッチするなり、コンビニいくなりすると良いでしょう。
もちろんその都度時間はかわりますし、SKUなどによっても時間は変化します。
OCI 側 の DRG の作成に比べて結構時間がかかります。
-
作成された 仮想ネットワーク GW (ERGW) の画面
ゲートウェイの種類:ExpressRoute になっていることが分かります。
余談ですが、ERGW も Windows ベースのVMで動いてます。(実態としてVMは見えないです)
- 仮想ネットワーク (VNet-Hub) の画面
仮想ネットワークゲートウェイに必要な専用サブネット (GatewaySubnet) が作成されています。
明示的にあらかじめ作っておかなくても自動で作ってくれていました。
・ゲートウェイ サブネット - ExpressRoute の仮想ネットワーク ゲートウェイについて
Azure : 仮想ネットワーク GW (ERゲートウェイ) と ExpressRoute 回線 との接続
下記の要領で接続します。
ルーティングと FW 設定
これで経路的にはつながったはずなのであとはルーティングやファイアウォールまわりの設定です❣❣
Azure 側
- OCI 側の確認
ここで設定するにあたり、OCI 側の設定を確認します。
ハンバーガーメニュ → 左ペインのメニューから ネットワーキング → ネットワーキング・ビジュアライザを確認しましょう
OCI 側 の IP レンジが 10.0.0.0/16 であることが分かります。(デプロイ時に確認してますが念のため)
-
ルーティングの設定の確認
Azure 側からこのアドレス帯に対する通信が ERGW (から ExpressRoute 回線) に向くように設定されているか確認します。
参考サイトの方ではルートテーブルを作成して紐づけていますが、実際にはルートテーブルの作成は不要です。
Azure 側の ERGW が存在する任意の仮想マシンの NIC から下記のように確認すると、OCI のセグメントに対するルーティング情報が入ってることを確認できます。
-
NSG の設定
後の検証のために、OCI VM の Public IPを許可しておく。
ERGW からの通信は VirtualNetwork の通信に含まれているので許可されているので明示的に許可する必要ない。
VirtualNetwork:
仮想ネットワーク アドレス空間 (仮想ネットワークに対して定義されているすべての IP アドレスの範囲)、すべての接続されたオンプレミスのアドレス空間、ピアリングされた仮想ネットワーク、仮想ネットワーク ゲートウェイに接続された仮想ネットワーク、ホストの仮想 IP アドレス、およびユーザーが定義したルートで使用されるアドレス プレフィックス。 このタグには、既定のルートも含まれる場合もあります。
OCI 側
-
まずは Azure 側のネットワークを確認します
今回のリソースグループ RG-ER-test から Vnet Hub を選択します。
Azure 側の NW レンジは 10.100.0.0/16 であることが分かります。
-
Azure 側へのルーティングの設定
ハンバーガーメニュ → 左ペインのメニューから ネットワーキング → 仮想クラウドネットワーク → 今回のネットワークルート表をクリックして、 ルート・ルールの追加 をクリック
以下のように設定します。
-
セキュリティルールの追加
Azure 側の NW を追加 & Azure VM (Ubuntu) のPublic IPを追加
疎通確認 (Ping)
左が OCI 側 VM (10.0.0.212) 、Azure 側 VM (10.100.1.5) にそれぞれ SSH して、お互いに ping を打ったところです。無事に Private IP で疎通できていることが分かります。
ExpressRoute - FastConnect 経由 と Public IP 経由 の RTT 比較
ついでなので、RTT 比較をしてみたいと思います。
ここで IP アドレスの確認
*時間をおいて再起動したので Public IP が変わっています
必要に応じて、ファイアウォール (NSGなど)や OS 内部のFW などの設定をします。
- OCI側 VM
Public IP:138.3.208.56
Private IP:10.0.0.212 - Azure 側 VM:
Public IP:74.226.153.212
Private IP:10.100.1.5
なお、参考記事にもあるように、Azure VM の RTT を図るのに Ping を使用すべきではありません!
なので今回は netperf コマンドを使います。
それぞれの Azure VM で apt update & netperf のインストール をしておきます。
sudo apt update
sudo apt-get install netperf
netperf -t omni -H (宛先IPアドレス) -- -d rr -T TCP -k MIN_LATENCY,MEAN_LATENCY,P90_LATENCY,P99_LATENCY,MAX_LATENCY,STDDEV_LATENCY
今回は OCI VM → Azure VM のRTT を ExpressRoute 経由 と Public IP 経由 の RTT 比較します。
ubuntu@vm-oci-ubu:~$ netperf -t omni -H 74.226.153.212 -- -d rr -T TCP -k MIN_LATENCY,MEAN_LATENCY,P90_LATENCY,P99_LATENCY,MAX_LATENCY,STDDEV_LATENCY
OMNI Send|Recv TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 74.226.153.212 () port 0 AF_INET : demo
MIN_LATENCY=2652
MEAN_LATENCY=3064.89
P90_LATENCY=3323
P99_LATENCY=4650
MAX_LATENCY=9384
STDDEV_LATENCY=418.75
ubuntu@vm-oci-ubu:~$ netperf -t omni -H 10.100.1.5 -- -d rr -T TCP -k MIN_LATENCY,MEAN_LATENCY,P90_LATENCY,P99_LATENCY,MAX_LATENCY,STDDEV_LATENCY
OMNI Send|Recv TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.100.1.5 () port 0 AF_INET : demo
MIN_LATENCY=2683
MEAN_LATENCY=3179.26
P90_LATENCY=3473
P99_LATENCY=4700
MAX_LATENCY=15167
STDDEV_LATENCY=437.48
Public IP経由 (74.226.153.212宛)への結果:
最小レイテンシー: 2652 μsec
平均レイテンシー: 3064.89 μsec
90パーセンタイルのレイテンシー: 3323 μsec
99パーセンタイルのレイテンシー: 4650 μsec
最大レイテンシー: 9384 μsec
標準偏差のレイテンシー: 418.75 μsec
ExpressRoute - FastConnect 経由 (10.100.1.5宛)への結果:
最小レイテンシー: 2683 μsec
平均レイテンシー: 3179.26 μsec
90パーセンタイルのレイテンシー: 3473 μsec
99パーセンタイルのレイテンシー: 4700 μsec
最大レイテンシー: 15167 μsec
標準偏差のレイテンシー: 437.48 μsec
*1 μsec / マイクロ秒 = 0.001 ms / ミリ秒
これらの結果から、今回 Public IP経由のネットワーク経路がExpressRoute - FastConnect経由よりも低いレイテンシーを示しています。しかし、ExpressRoute - FastConnect経由の方が最大レイテンシーが高く、標準偏差も大きいことが分かります。
有意な差かどうかは微妙なところです。
参考
- Microsoft Azure と Oracle Cloud を Cross-Cloud 接続してみてみた
こちら オラクルの方が書いてくださっている記事です。
今回非常に参考させていただきました✨✨✨
UI が当時と変わっていたり、実際には RTテーブルや NSG の設定など (現在の) Azure 側では不要な手順など一部もあります。
- Azure 仮想マシン 高速ネットワーク 概要 ~ Azure VM 間の RTT 測定に ICMP を使ってはいけない ~
当初 Ping で RTT 測定をしていたんですが、親愛なる仲間に 「それはあかんで」 と教えていただき、その時に参照として教えてもらった記事になります。
こちらの記事をみて Ping で実施していた RTT 比較をやり直しました。
簡単にいうと (少なくとも Azure) VM ではTCP は優先されてるから TCP で RTT しましょう。
Azure の仮想マシンでは、VM 間の TCP の通信も内部的には UDP に近い低遅延のプロトコルに変換されているということ。一方、TCP/UDP の枠組みでないプロトコルは高速化対象ではないため、通常の NIC を介して通信されているようです。
- ExpressRoute 導入の流れを確認してみる
こちら、より具体的に ExpressRoute の導入のイメージがつきやすい記事になっています。
- ssh-keygenを用いて秘密鍵と公開鍵を作る(Windows10とLinuxの違い)
- Azure OCI Interconnect (相互接続)でつないでみた
- Azure CAF にはマルチクラウド構成時のネットワークガイダンスあるよ
特に OCI ならこれだよ
- ExpressRouteで障害が発生する可能性のあるポイントとその対応策
- netperf の使い方
- netperf のドキュメント
- Latte と SockPerf を使った方法について ml
https://learn.microsoft.com/ja-jp/azure/virtual-network/virtual-network-test-latency?tabs=windows
謝辞
この記事を出すにあたり、コメントをいただいた親愛なる仲間 (S 氏) に感謝します。
また、Osaka リージョン で OCI アカウントを作ってしまい、OCI アカウントの作り直しも弾かれて、途方に暮れていた私に OCI アカウントを作ってかしてくれた K 氏にも大変感謝です。