ハイブリッドクラウド時代の大海原を巡洋するのに欠かせない 「旗艦クラウド」と「鉄板ネットワーク・バックボーン」を実現する Power Virtual Server + Megaportネットワーク

記事をシェアする:

1. ハイブリッドクラウド時代の到来

みなさまの会社では、近年どのようなITインフラをご使用でしょうか。多くの会社においては、クラウドが使われるようになってきているかと存じます。その一方で、経済性、サービス要求レベル、法令対応などの観点で、オンプレミスで運用されているサーバー群も存続していることでしょう。また、クラウドも、複数のクラウドベンターのIaaS、PaaS、SaaSを組み合わせてご使用されているかもしれません。

ITにおいては、「One fits all (ひとつのソリューションですべてのニーズをカバーすること)」は難しいので、どうしても適材適所でのクラウドないしオンプレミスの導入となります。そうなると、会社には一つもしくは複数のプライベートクラウドがオンプレミスもしくはデータセンターに存在している一方で、パブリッククラウドも複数使用されている状況、つまりハイブリッドなマルチクラウド環境になってきています。

2. ハイブリッドクラウド時代に考えるべき二つのネットワークの視点

ヘテロ (不均一) なハイブリッドクラウド環境においては、ネットワーキングをどのように構築していくかが重要なポイントになります。なぜなら、ネットワーキングがハイブリッドクラウド全体のパフォーマンスやセキュリティーを決める重要な要素になるからです。

企業のERPシステムや基幹業務システム用の安心・安全なクラウド基盤として採用が進むPower Virtual Serverも例外ではありません。お客様の関心事は、企業アプリケーションとデータペースの中核に位置するこのクラウドシステムを、日々のDXを支えるSaaSやIaaSや、企業内外のユーザーと高パフォーマンスかつ安定して接続するにはどうすればよいかという、デジタル・ネットワーキングに及んでいます。

それでは、そのネットワーキングを二つの視点で見ていきましょう。

1) 視点その1: クラウド間接続

多くの企業が複数のクラウドを使用して様々な業務用アプリケーションを構築しています。クラウド間は、あるクラウドを中心としてスター型でつながっていたり、ひとつの線上にシーケンシャルにつながっていたり、またはN対Nでつながっていたりと、そのつながり方には様々なバリエーションがあります。アプリケーションのデザインによって形態は多様化します。

稼働当初に接続したときにはアプリケーションで取り扱うトランザクションが少なかったので問題にならなかったネットワーク・パフォーマンスも、業務量の増加とともに問題が顕在化してくることがあります。複数のクラウドを使用して一つのトランザクションを処理している場合は、どこかのクラウドでボトルネックが発生すると、トランザクション処理の完結そのものに影響を及ぼします。

クラウドのパフォーマンスを適切に維持するためには、クラウドそのもののパフォーマンスと、クラウド間のネットワークの帯域や遅延の両方を管理していく必要があります。また、クラウド間のネットワークが断絶したときには、その原因究明のために双方のクラウド業者と連絡を取る必要もあります。

2) 視点その2: クラウド- ユーザー側ネットワークの接続

いくつかのクラウドは、ユーザー側のネットワークと、もしくはユーザーのデバイスと直接つながります。ユーザーによってはすべてのクラウドがユーザー側に直接つながっていることもあるでしょう。ユーザーは自身のネットワークを管理しています。一方、クラウド内部のネットワークはクラウド業者が管理しています。クラウド時代には、クラウドと自社ネットワークの安定接続は極めて重要です。

3. IIJグローバルソリューションズによる検証結果

1) MegaportサービスによるPower Virtual Serverの利用

Megaportサービスの概要

Megaportサービスはクラウド接続やデータセンター接続サービスを提供するNaaS（Network as a Service）プロバイダーです。現在、欧米、欧州、東南アジアに多数のMegaport提携データセンターが存在し、これらのデータセンターからIBM Cloudを初めとした主要なクラウド・サービス・プロバイダーへのダイレクト接続を可能としています。

Megaportサービスのユーザーにとっての価値

Megaportサービスは企業の複雑なネットワーク管理の簡素化、クラウドサービスへのシームレスな接続、データセンターの仮想化などクラウドネイティブな企業ネットワーク・インフラストラクチャーを構築するために必要なサービスを提供しています。さらには、「納期」「料金」「品質」「提携データセンター数」においてユーザーに以下のメリットをもたらすサービスでもあります。

• 「納期」：設定情報さえ準備できれば最短即日でMegaportサービスを提供することができます。
• 「料金」：最低利用期間がなく（一部サービス除く）、必要な期間だけ利用することや、必要に応じて回線の増設・帯域幅の増減速を行うことができます。そのため回線に対するコストを必要最小限に抑えることができます。
• 「品質」：クラウド環境を閉域網で構築することができるため、クラウドサービスを安定した品質で利用することができます。また、最大10Gbpsまでの広帯域回線が利用可能です。
• 「提携データセンター数」：世界中で700を超えるデータセンターと主要なクラウドサービスとのダイレクト接続が可能です。

以上のように、Megaport社はハイブリッドないしマルチクラウド環境を利用したいユーザーや課題を持つユーザーにとって高い価値を提供するNaaS (ネットワーク・アズ・ア・サービス)プロバイダーとして高い注目を浴びています。

Megaportのサービスコンポーネント

Power Virtual Serverと接続するためには、Megaport社で提供されているサービスを組み合わせて接続することができます。以下にMegaport社で提供される基本的な3つのサービスを紹介します。

①Megaport（物理ポート）
物理ポートはMegaport社のサービスと接続するための物理的なイーサネット・インターフェースです。1Gbpsまたは10Gbpsまたは100Gbpsのキャパシティが用意されています。Megaport提携データセンターのMeet-Me-Room内にMegaport網内接続用のパッチパネルがありますので、物理ポートを契約後、光ケーブルを繋ぎ込みすることでMegaport網へ接続することができます。

②MCR（Megaport Cloud Router）
Megaport網内で利用できるLayer 3接続のための仮想ルーターです。BGPまたはStaticによるルーティングが可能で、Route FilterやNATなどの機能も利用できます。

③VXC（Virtual Cross Connect）
物理ポート、MCR、クラウド間のサービスを瞬時にPoint-to-Pointで接続する仮想イーサネット回線です。1Mbpsから10Gbpsの帯域幅で利用できます。

2) MegaportサービスによるPower Virtual Serverとの接続検証構成

IIJグローバルソリューションズでは上記3パターンでの検証を実施しました。クラウド・ユーザー間接続構成での試験については物理ポートが利用できる施設「アット東京 Cloud Lab」を利用して検証を行いました。

①マルチクラウド接続構成
MCRを利用することで、IBM CloudとAWSをVXCで接続した構成となります。IBM Cloudと他クラウド間連携も可能なマルチクラウドやハイブリッドクラウドを想定しています。

②クラウド・ユーザー間接続構成（シングル）
物理ポートを利用することで、Megaport社提携データセンターとPower Virtual Serverを接続した構成となります。顧客WANのブランチ拠点からハブとなるMegaport社提携データセンターを経由してPower Virtual Serverの活用することを想定しています。既にMegaport社提携データセンターを利用されているお客様であれば、安価に閉域網経由でのPower Virtual Serverを利用することができます。

構成図のL2スイッチと物理ポートの間は光ケーブル（LC-SCコネクタ）で接続しています。Megaportサービスの責任分界点として、物理ポートへの接続までがユーザー側の責任範囲となりますので、光ケーブルはユーザーが用意する必要があります。(アット東京内の顧客WANはインターネットを想定していますが、検証環境の顧客WANは実際にインターネットを利用していない疑似接続となっています)

③クラウド・ユーザー間接続構成（冗長化）
構成②と同じ想定で実施した構成ですが、構成③はVXCからPower Virtual Serverまでの経路が冗長化されており、Power Virtual Server上にある異なる物理ポートにVXCが接続されています。(本来であればMegaport社提携データセンター内のSEIL/X4から物理ポートまでも冗長化させ、物理的に異なる筐体上に作成される物理ポートを利用してVXC接続するべきですが、設備上の理由で本検証ではアット東京側の物理ポートは1つとなっています)

3) 構築手順の概要 (Caseによる各種パラメーターの連携等)

検証環境を構築するために、IBM CloudポータルとMegaport Portalからリソースの作成と設定が必要となります。また、Power Virtual Serverへの接続元となるMegaportサービス（物理ポートまたはMCR）によって設定する内容が異なります。また、Megaportサービスへの接続に関してはIBM Cloud上でCaseオープンすることで個別にIBM Cloudのサポート担当者に対応いただくため、受領する情報の順序が異なる場合があります。ただし、IBM Cloudのサポートチームに送付する情報接続や設定内容に関しては一意に決まっているため、ユーザー側が実施するアクションが変動することはありません。IIJグローバルソリューションズで検証環境を構築した際は、下図のようなフローでPower Virtual ServerのMegaportサービスへの接続を依頼できました。下図の「Megaport Portal」、「IBM Cloud Portal」の列はそれぞれのポータルで実施した内容、「Power IaaS Support」はIBM Cloudのサポートチームが実施した内容となります。

①事前準備
MegaportサービスとIBM Cloudを接続する前に、接続元であるMegaport Portalでサービス（MCRまたは物理ポート）の作成、IBM CloudポータルではPower Virtual Serverリソース作成・設定を行います。

②IBM Cloud上でCase (お問い合わせ票) を作成
事前準備完了後、IBM Cloudポータル上でCaseをオープンします。2022年1月現在、Power Virtual ServerへのMegaportサービスへの接続はIBM Cloudポータル上の操作だけではできないため、Caseを通じてPower IaaS Supportチームに個別設定をしてもらう必要があります。またPower IaaS Supportチームへの問い合わせは日本語対応不可のため、英語で問い合わせる必要があります。

③VXC作成
Caseで挙げた情報に問題がなければ、VXC作成の際に必要な情報がPower IaaS Supportから送付されます。これらの情報を利用してMegaport PortalでVXCを作成します。

④VXC情報をケースにあげる
VXC作成後、IBM Cloud上で作成した旨をCaseに記載しPower IaaS Supportに送付します。この時、BGPのMD5認証オプションを利用している場合は設定したパスワードも合わせてCaseに記載します。Power Virtual Serverまでの経路冗長はBGPによるルーティングで実現します。主系として利用したいVXC名を記載することでAct-Stn構成をとることができます。

優先するVXCは以下のように指定することができます。

・MegaportサービスからPower Virtual Server向きの通信
Power IaaS Support がPower Virtual ServerルーターにAS-pathを付加した経路を広報するように設定し、優先する経路を指定します。また、持ち込みルーターであればルートフィルターなどを利用して受信した経路に重みづけをすることでも優先する経路を指定することが可能です。

・Power Virtual ServerからMegaportサービス向きの通信
Power IaaS Support がPower Virtual ServerルーターにLocal Preferenceを設定し、優先する経路を指定します。

⑤BGP設定
VXCの承認, Power Virtual ServerルーターのBGP設定が完了した内容をPower IaaS Supportから受領後、MCRまたは持ち込みルーターのBGPの設定をします。持ち込みルーターであれば、Power Virtual Server側ASNを受領次第、任意のタイミングでBGPの設定をすることが可能ですが、構成①のようなMCR利用しているケースでは、VXCの承認期間中に設定変更をすることができません。

⑥ステータスの確認
ユーザー側のBGP設定が完了した時点でMCRまたは持ち込みルーターはBGPでPower Virtual Server宛の経路情報を受信できています。正常に経路が受信できていることが確認できましたら、Caseのクローズをします。

4) 検証内容と結果 (基本接続機能, 冗長構成による可用性検証等)

弊社では2つの構成で以下の確認と検証を実施しました。

構成①
・Pingレベルの基本的な通信
以下がAWS上の仮想マシン（東京）からMegaportサービスのMCRを経由してPower Virtual Server上のIBM（大阪）への通信試験結果です。閉域網で東阪間通信が平均8msであることを考えれば妥当な応答時間です。

構成②
・Pingレベルの基本的な通信
以下が顧客拠点想定のデータセンター内にあるクライアントPCからMegaportを経由してPower Virtual Server上のIBM i 区画（大阪）への通信試験結果です。構成①の仮想接続構成と同様に妥当な応答時間が結果として示されました。ただし、顧客WAN想定であるネットワークはインターネットを経由していないため、実際の環境では多少レスポンスタイムが遅くなるはずです。

・5250端末エミュレーターによるPower Virtual Server上のIBM iへのリモート接続とFTP通信
AWS上の仮想マシンに5250端末エミュレーターをインストールし、ping以外の通信についての試験も行いました。具体的にはエミュレーターによるPower Virtual Server上のIBM iへリモート接続とFTPによるファイルのgetができるかの試験です。実際にクラウド上の仮想マシンからエミュレーターでIBM iを利用する構成は少ないと思いますが、ここではpingのような基本的な通信以外も行うことができるかの確認となります。エミュレーター設定後、リモート接続を実施したところサインオン画面が表示され問題なくリモート接続ができたことが確認できました。FTP通信に関しても、AWS上の仮想マシンのコマンドプロンプトからftpコマンドによるgetを行いIBM iに保管されているsavfファイルの取得が問題なく行われたことが確認できました。

構成③
・5250端末エミュレーターによるPower Virtual Server上のIBM iへのリモート接続とFTP通信 ※ 冗長試験／障害発生時の通信を含む。

構成②においても顧客拠点想定のクライアントPCにもエミュレーターをインストールし、リモート接続試験とFTP通信の試験を行いましたが、構成①と同様に両通信共に問題なく行うことができました。

障害試験においては、顧客拠点データセンター設備のL2スイッチのVLANインターフェースをUP/DOWNさせることでアット東京-IBM Cloud間の障害を再現し、主系と副系経路の切り替わりについて確認しました。結果として、主系から副系への切り替わりは問題なく行われました。pingレベルでの通信断が10秒弱ありましたが、エミュレーターのセッション断は発生しませんでした。また、副系から主系への切り替わりも問題なく行われ、こちらはpingレベルでの通信断・エミュレーターのセッション断が発生しませんでした。

エミュレーターの設定や実際のインターネット環境を利用した場合、セッションタイムアウトし、エミュレーターでの再接続を実施する必要が発生する場合も考えられますが、結論としてはアット東京-IBM Cloud間の障害に対してBGPで冗長構成がとられたPower Virtual Serverの利用が可能であることが検証から判明しました。

4. IIJグローバルソリューションズへのお問い合わせ

IIJグローバルソリューションズでは、今回ご紹介したMegaport社のサービスを利用したPower Virtual Server接続を含むマルチクラウド接続サービス、そしてハイブリッドクラウド時代に向けた広範なネットワーク/セキュリティーサービスをご提供しており、Power Virtual Server 接続における知見を前述の検証を通じて蓄積しています。

Megaport社等による各種クラウド接続ネットワークや、SASE、CASB、SD-WAN、SD-LAN、EDR/XDRといった先進ネットワーク/セキュリティーサービスに関するご相談がございましたら下記お問い合わせ先までご連絡ください。