PowerVSで、「手動構成したDirect Link」の環境をPER環境に切り替える

はじめに

下記で書いた、「手動構成したDirect Link 2.0」を使ってx86 IaaS（VPCやClassic）に接続しているPowerVS環境をPER環境に切り替える手順です。
https://qiita.com/y_tama/items/bdd602defbb9b6ce4875

「自動構成したCloud Connection」は、この手順でのPER切り替えは行えません。

基本的には下記のdocsの通りです。
https://cloud.ibm.com/docs/power-iaas?topic=power-iaas-migrate-ws-per

PERへの移行に関する留意点

docsに記載されていますが、この手順で移行したワークスペースでは、サブネットの追加・変更・削除の際、caseを起票してサポート側でネットワーク設定に手を入れてもらう必要があります。移行前のワークスペースや、新規にPER環境として作成したワークスペースではセルフサービスで行える操作が、移行したワークスペースではcase起票が必要になる点にご留意ください。
https://cloud.ibm.com/docs/power-iaas?topic=power-iaas-migrate-ws-per#add-info-per-mig

caseを起票してPERへの移行を依頼

今回の初期状態としては、Direct Link 2.0でPowerVSとVPCを接続しています。Transit Gatewayは使っていません。

docsに従ってcaseを起票し、移行したいPowerVSワークスペースやサブネット、Direct Linkの情報を伝えます。（docsの手順のStep4）

PowerVSサポート側で必要な処理が行われると、caseに返信が来ます。

ワークスペースにアクセスすると、左側のメニューのNetworkingの配下から、Cloud connectionsとVPN connectionsが消えています。PER対応のワークスペースではこれらの機能は使えませんので、この事からも、ワークスペースがPERに対応した状態に切り替わったことが分かります。

Before

After

PER+Transit Gatewayの経路を作成

このワークスペースからPERを使う準備はできましたが、通信はまだ従来のDirect Linkを経由して行われています。
以下の作業でDirect Linkを廃止してPER経由の通信に切り替えます。

PER対応のワークスペースがx86 IaaSやオンプレミスと通信するためにはTransit Gateway経由である必要があるため、Transit Gatewayをオーダーし、PowerVSとVPCへのコネクションを作成します。（docsの手順のStep5）
caseに依頼して対応が行われる前は、該当のワークスペースは、Transit GatewayのPower Systems Virtual Serverのネットワークタイプには表示されませんでしたが、PER対応ワークスペースになったので、表示されるようになりました。

PowerVSとVPC、双方からルーティング情報が広告されていることが確認できます。

この時点で、PowerVSとVPC間は、「Direct Link経由」と「PER+Transit Gateway経由」の2つの経路でルーティング可能な状態になっています。

なお、PowerVSに接続したTransit Gatewayは、通常のTransit Gatewayとは異なる価格になります（一般のTransit Gatewayより安価です）。PowerVSに接続したLocalタイプのTransit Gatewayはデータ転送費用がかかりませんので、構成によりますが費用追加なく使える場合もあると思います。
https://cloud.ibm.com/docs/power-iaas?topic=power-iaas-pricing-virtual-server-on-cloud#per-pricing

Direct Linkの経路を廃止

次に、これまで使っていたDirect Link経由の経路を使わない状態にします。
具体的には、Direct Linkのフィルタリング機能でImport route filtersでDeny all import routesを設定し、PowerVSからのルーティング情報をブロックします。（docsの手順のStep5）

Direct Link経由の経路が使えなくなったので、PER経由の経路で通信するようになります。

VPC上のサーバーからPowerVSのLPARにpingを打ち続けながら、Direct LinkのDeny all import routesの設定を有効にしましたが、私の環境では、パケットロスは無く、数秒の遅延が発生する程度でした（下記の6行目）。

64 bytes from 172.16.50.157: icmp_seq=115 ttl=250 time=0.518 ms
64 bytes from 172.16.50.157: icmp_seq=116 ttl=250 time=0.528 ms
64 bytes from 172.16.50.157: icmp_seq=117 ttl=250 time=0.470 ms
64 bytes from 172.16.50.157: icmp_seq=118 ttl=250 time=0.515 ms
64 bytes from 172.16.50.157: icmp_seq=119 ttl=250 time=0.538 ms
64 bytes from 172.16.50.157: icmp_seq=120 ttl=250 time=4.92 ms
64 bytes from 172.16.50.157: icmp_seq=121 ttl=250 time=0.503 ms
64 bytes from 172.16.50.157: icmp_seq=122 ttl=250 time=0.475 ms
64 bytes from 172.16.50.157: icmp_seq=123 ttl=250 time=0.557 ms
64 bytes from 172.16.50.157: icmp_seq=124 ttl=250 time=0.564 ms

Direct Linkを削除

Direct Linkの経路をブロックしても問題なく通信できていることが確認できたら、Direct Linkを削除します（docsの手順のStep6）。

Step6が完了した旨、caseで連絡し、サポート側でStep7が完了したら切り替え完了です。