catch-img

Riverbed SteelConnect設定してみた!(3)

NOPエンジニアBlogをご覧のみなさん、こんにちは。 リバーベッド製品担当の池田です。

「Riverbed SteelConnect設定してみた!」シリーズの第3部では、クラウドをテーマにお話ししたいと思います。

今回のテーマはSteelConnectを使用して、オンデマンドネットワークをAWSやAzureといったクラウドへ簡単に拡張する機能です。

これまでのシリーズの第1部、第2部では、物理アプライアンスや仮想アプライアンスを使用した時に複数のサイトをMPLS WANおよびインターネットをアップリンクに接続することで自動的にそれらの間にオーバーレイVPNトンネルを構築しました。

構築するまでに行ったステップは非常に簡単なものでしたが、クラウド上で展開する際はもっと簡単です。 たった数回のクリックで、仮想SteelConnectゲートウェイをAWSまたはAzureのいずれかで迅速に展開することができます。

これらのクラウドゲートウェイは、すべてのサイトとオーバーレイVPNトンネルを自動的に構築し、すべてのSteelConnectゲートウェイへのルートをアドバタイズするので、物理サイト内のユーザーは、AWS(またはAzure)のRegionやVPC(またはVNET)に関係なく、数分でAWSまたはAzure上に構築したサーバ、アプリケーションにアクセスできます。

また、たった数回のクリックでCloud SteelHeadを追加して、いずれかのクラウドで実行されているアプリケーションを最適化し、ユーザーエクスペリエンスとアプリケーションのパフォーマンスをさらに向上させることもできます。

クラウドのSteelConnectゲートウェイでは、AWSが管理する仮想プライベートゲートウェイ(VPG)の要件はなく、すべてがSteelConnect Managerによって管理されます。 それでは導入してみましょう! AWSまたはAzure SteelConnect GWを導入するには、2つの方法があります。

1.SteelConnectマネージャを使用する。

2.AWSまたはAzure MarketplaceからSteelConnectゲートウェイを導入する。 本ブログでは、AWSを使って超簡単に展開できる最初のオプションに焦点を当ててご説明します。

SteelConnectマネージャの操作画面:ダッシュボード


​​​​​​​ まず、AWSに仮想SteelConnectゲートウェイをデプロイするには、APIを使う為に適切な役割とアクセス権を設定する必要があります。 クラウド設定は、Network Design -> AWS で処理されます。

アカウントに正しい資格情報を設定すると、次のようなメッセージが表示されます。資格情報を変更しない限り、このタブに再度アクセスする必要はありません。SteelConnectマネージャの操作画面:Netowork Design

次に、Import VPCs(AWS)タブを使用して、接続するVPCをインポートします。使用可能なネットワークは、前の手順で提供されたAPI資格情報を使用して取得されます。

アプリケーションが存在するサブネットにあるインスタンスだけにアクセスしたい場合、接続されているVPC/ネットワークに接続するだけです。

あらゆる場所でインスタンスを実行している場合は、すべてのサブネットに接続するだけでより簡単に自分自身で使用できます。 ダッシュボードマップ上にサイトを作成して最終ステップを準備する以外は、これだけでは何もしません。


SteelConnectマネージャの操作画面:Import VPCs

SCMダッシュボードは、ネットワークをインポートした後、実際のゲートウェイを展開する前にサイトは存在していますが、まだ展開されていないためにオフラインになっています。


SteelConnectマネージャの操作画面:ダッシュボード

SteelConnectマネージャの操作画面:Over view

 最後のステップでは、Virtual Gatewayと(オプションで)SteelHeadを配備して、自動的にトンネルとルーティングをセットアップして、自身の施設からインスタンスにアクセスできるようにします。

「Deploy Instances」に進み、「Deploy」をクリックします。 Virtual GatewayとSteelHeadよりリソースを選択して、[Submit]をクリックします。

SteelConnectマネージャの操作画面:Network Design

SteelConnectマネージャの操作画面:Deploy Instances

 ここではバックグラウンドでプロセスを開始してAWS でインスタンスを作成し、クラウドネットワークがオンサイトのSteelConnectゲートウェイにルート情報をアドバタイズされるように自動的にネットワークを構成します。

ここは、Amazonがリソースの請求を開始する部分でもあります。 私の場合は、展開から自動オーバーレイトンネルの接続まで約5分程度で完了し、AWS で実行されているアプリケーションにユーザーがアクセスすることができました。

SteelConnectマネージャの操作画面:アプリケーション

マップをもう一度見てみると、すべてのデバイスが緑色になり、すべてのサイト間、クラウド内の物理メッシュと物理アプライアンス間にフルメッシュトンネルが構築されています。

SteelConnectマネージャの操作画面:ダッシュボード

 最後に、SD-WANを使用してWANトラフィックを最適化することがどれだけ簡単かを示したいと思います。

これまでの手順で、AWS上にSteelConnectゲートウェイを配備するだけでなく SteelHeadも配備しました。SteelHeadはクラウドネットワーク内外のすべてのトラフィックがSteelHead(そして仮想ゲートウェイ)を通過するように自動的に構成されています。

たとえば、SteelHeadのIPアドレスはAWSコンソールの概要ページから取得できます。

SteelConnectマネージャの操作画面:AWSコンソール


SteelConnectマネージャの操作画面:SteelHeadログイン画面

    対向のHQサイト内には既に構築したVirtual Gatewayを介してネットワークに接続しているので、クライアントPCから直接アクセスできるようになっています。

また、私が接続しているVirtual Gatewayの配下にはSteelHeadを構築してあり、アプリケーション最適化機能も使えるようになっています。

AWS上に構築したインスタンスのWindows Server 2012R2 VM(172.31.19.219)上へリモートデスクトップ接続した際の結果がこちら。

デスクトップ

 あとは、ファイルサーバを構築するだけで、クライアントPC(Windows7)との間でSMB2.1が有効になります。

実際にHQサイトのクライアントPC(172.16.0.133)からEC2上のファイルサーバ(172.31.19.219)へファイルをアップロードした際の結果がこちら。

アップロード結果

SMB2.1を使ってアプリケーションが最適化できている事が確認できます。 次回はAzureを使った構築にもチャレンジしたいと思いますのでお楽しみに!