INDEX Demo の目的 ゴール Scenario 1: 自動化 Scenario 2: 効率化 2

DemoCenter Live Demo:BIG-IPIPと vsphereにおけるクラウドアプリケーション F5 ネットワークスジャパン株式会社

INDEX Demo の目的 ゴール Scenario 1: 自動化 Scenario 2: 効率化 2

F5と VMware の連携で構築する クラウド クラウド についての様々な定義がある : インフラ プロバイダから CPU リソースを借りる ( 仮想マシンを渡す ) アプリケーション プロバイダからアプリケーションを含むリソースを借りる ( データを渡す ) 自前システムを仮想化 ( 仮想インフラを構築 ) など F5 と VMware の連係は仮想インフラの構築にメリットがある 自前システムで行う場合 あるいはインフラ アプリケーションのプロバイダとして仮想インフラを提供する場合に利用 ゴール : 1) 運用費用 (OpEx) の削減 : 運用にかかわる時間と手間を減らす 2) リソースの効率化 : 実際に必要なものにリソースを投資 3) 投資したものに最も高い ROI を実現 : アプリケーションとして最大限のパフォーマンスを実現 4) 新規サービス投入のリスクを軽減 : 低い CapEx で新サービスを提供 3

F5と VMware の連携で構築する クラウド ゴール 1) 運用費用 (OpEx) の削減 メインテナンス用の作業を短縮 様々な作業を自動化 運用にかかわる時間と手間を減らす 2) リソースの効率化 不要なとき 利用するリソースを減らす リソースが急に必要になった場合に自動的に増加 3) 投資したものに最も高い ROI を実現 アプリケーションのパフォーマンスを最大限に 実際に必要なものにリソースを投資 4) 新規サービス投入のリスクを軽減 CapEx を抑えながら新サービスを提供 4

Demo: クラウド化されたアプリケーション クラウド についての様々な定義から よくあげられる例を見てみよう : Web Based Application 本デモでは 次のメリットを確認する 急なトラフィック増加に対して追加リソースを自動的に確保 オフピーク時間はリソースを無駄にしない どの時でもサーバ仮想化に対して高い ROI を実現 必要以上の Host を使わない 各 Host 上に必要以上のリソースを利用しない たくさんの仮想サーバを 1 つの Host にまとめる リソース管理のためにアプリケーションを落とすことが不可能 クラウド基盤は仮想サーバの位置を把握し正しくトラフィックを処理 5

Demo Scenario 1: : 概要 ( 論理図 ) 論理プロセス 処理可能な Throughput と Connection 数がどんどん増加 1) 負荷が上がってしまうことによって Web/App サーバの CPU 使用率が 100% に近づく 2) 高 CPU 資料率が 30 秒以上続くと 新しい Web/App サーバが自動的に立ち上げる 負荷装置 3) 最終的にすべての Web/App サーバが負荷をうまく吸収する ( 各サーバの CPU 使用率が数十パーセントに収まる ) 4) 負荷が無くなった場合 不要となったサーバ ( 低 CPU 使用率 ) が自動的にシャットダウン DB サーバ Web/App サーバ 物理サーバである環境においてはほぼ不可能な運用方法! 6

Demo Scenario 1: : 詳細 ( 物理図 ) 論理プロセス 1 一定の負荷を送信 1) 負荷が上がってしまうことによって Web/App サーバの CPU 使用率が 100% に近づく 負荷装置 2) 高 CPU 資料率が 30 秒以上続くと 新しい Web/App サーバが自動的に立ち上げる 3) 最終的にすべての Web/App サーバが負荷をうまく吸収する ( 各サーバの CPU 使用率が数十パーセントに収まる ) 3 新 VM を BIG-IP のプールに追加 Host 1 4) 負荷が無くなった場合 不要となったサーバ ( 低 CPU 使用率 ) が自動的にシャットダウン Host 2 vcenter/ icontrol サーバ Web/App サーバ その他の重大サーバ ( 移動不可能 ) DB サーバ 5 負荷がなくなったら Host 2 及び不要の VM をシャットダウン 2 vcenter が VM の CPU 使用率に気づき 新 VM を起動 NAS Datastore 4 Host 1 の CPU リソースが足りなくなったら Host 2 を起動し vmotion で VM を移動する 7

Demo Scenario 1: 注釈 本デモではもっと素早く vmotion を実行させるために Host 1 にその他の負荷をかけている (DNS 等 ) BIG-IP は単純な L4 ロードバランサとして動作している (FastL4) 本デモは VMware と F5 の API における自動化を確認するため vmotion を実現するために 仮想マシンのファイルを NAS のデータストアに保存する必行がある 8

Demo Scenario 1: : 結果 Demo Scenario 1 では下記のゴールを実現した : 1) 運用費用 (OpEx) の削減 vmotion では 仮想マシンを動いたまま異なる Host へ移動できるため Host のメインテナンス時にサービスを落とす必要がない リソースの増加を仮想していない環境で実施するには とんでもないコストがかかるが F5+VMware の場合簡単にできる 2) リソースの効率化 アプリケーションが常に必要のリソースだけを利用しているので オーバスペックなどの無駄なリソースを用意しておく必要がない 9

Demo Scenario 1: : 補足 今回は増加可能なサーバ数を固定しておいた これによって最大限に使うリソースが予めわかって コントロールできる リソースを制限する必要がない環境では 本デモの動作にテンプレートから新規 VM をクローンする作業を追加できる FastL4 における単純ロードバランスは充分? 処理能力の高いハードウェアが安いので L4 ロードバランスは充分ではないか という考え方もある しかし 仮想マシンの概念ではこの考え方を適用できない : 仮想マシンは制限されているリソースを共有している 限られたリソースを効率よく使うのが ROI につながる Demo Scenario 2 で確認! 10

Demo Scenario 2: 概要 ( 論理 物理図 ) 一定の負荷を送信 負荷装置 論理プロセス 1) 負荷がをかけながら 仮想マシンの数を固定にして システム全体の Throughput と Connection 数を確認 Host 1 Web/App サーバ その他の重大サーバ ( 移動不可能 ) DB サーバ 2) 順次に BIG-IP の L7 機能を有効にする : a) フルアプリケーションプロキシ b) SrcIP パーシステンス Cookie パーシステンスへ変更 c) OneConnect d) Compression e) RAMCache f) WAM 3) 各ステップで Throughput と Connection 数の処理能力を確認 また Step 1) のシステム処理能力を実現するためにいくつの VM が必要かを確認 11

Demo Scenario 2: 詳細 - Full Proxy L4 ロードバランサ フルアプリケーションプロキシ 負荷装置 一定の負荷を送信 各 VM で処理能力によって システムとして処理可能なリクエスト数が限られる TCP HTTP プロキシ 各 VM の処理能力が変わらないが BIG-IP がリクエストを一旦受けることでシステム全体の Throughput Connection 数が上がる また BIG-IP の TCP スタックのチューニングにおける効果もあり 論理プロセス 1) 負荷がをかけながら 仮想マシンの数を固定にして システム全体の Throughput と Connection 数を確認 Host 1 Web/App サーバ その他の重大サーバ ( 移動不可能 ) DB サーバ 2) 順次に BIG-IP の L7 機能を有効にする : a) フルアプリケーションプロキシ b) SrcIP パーシステンス Cookie パーシステンスへ変更 c) OneConnect d) Compression e) RAMCache f) WAM 3) 各ステップで Throughput と Connection 数の処理能力を確認 また Step 1) のシステム処理能力を実現するためにいくつの VM が必要かを確認 12

Demo Scenario 2: 詳細 - Cookie Persistence SrcIP Persistence Cookie Persistence 一定の負荷を送信 HTTP プロキシなどによって複数のクライアントが同じサーバへ振り分けられることもある TCP HTTP プロキシ Cookie と実サーバのテーブル セッション ID を利用しより平衡な負荷分散を実施 負荷装置 論理プロセス 1) 負荷がをかけながら 仮想マシンの数を固定にして システム全体の Throughput と Connection 数を確認 Host 1 Web/App サーバ その他の重大サーバ ( 移動不可能 ) DB サーバ 2) 順次に BIG-IP の L7 機能を有効にする : a) フルアプリケーションプロキシ b) SrcIP パーシステンス Cookie パーシステンスへ変更 c) OneConnect d) Compression e) RAMCache f) WAM 3) 各ステップで Throughput と Connection 数の処理能力を確認 また Step 1) のシステム処理能力を実現するためにいくつの VM が必要かを確認 13

Demo Scenario 2: 詳細 - OneConnect L4 ロードバランス OneConnect 負荷装置 一定の負荷を送信 TCP コネクションをそのまま渡すので VM 側の処理能力を奪う 論理プロセス TCP/HTTP プロキシ Cookie と実サーバのテーブル OneConnect 変更 Keepalive へ変更することによって VM 側のコネクション数とそれに伴う処理能力の減少を抑えて ユニークなリクエストで処理可能な TCP セッションが増える 最近のクライアントは常に Keepalive を利用しているので 実際の効果が少ないと考える 1) 負荷がをかけながら 仮想マシンの数を固定にして システム全体の Throughput と Connection 数を確認 Host 1 Web/App サーバ その他の重大サーバ ( 移動不可能 ) DB サーバ 2) 順次に BIG-IP の L7 機能を有効にする : a) フルアプリケーションプロキシ b) SrcIP パーシステンス Cookie パーシステンスへ変更 c) OneConnect d) Compression e) RAMCache f) WAM 3) 各ステップで Throughput と Connection 数の処理能力を確認 また Step 1) のシステム処理能力を実現するためにいくつの VM が必要かを確認 14

Demo Scenario 2: 詳細 - Compression L4 ロードバランス HTTP 圧縮 一定の負荷を送信 各 VM で圧縮を実施しているので VM の CPU 処理能力を利用 TCP/HTTP プロキシ Cookie と実サーバのテーブル BIG-IP が代理に圧縮を実施するので VM の CPU リソースがより多くのリクエスト処理で利用できる OneConnect 変更 負荷装置 HTTP 圧縮 論理プロセス 1) 負荷がをかけながら 仮想マシンの数を固定にして システム全体の Throughput と Connection 数を確認 Host 1 Web/App サーバ その他の重大サーバ ( 移動不可能 ) DB サーバ 2) 順次に BIG-IP の L7 機能を有効にする : a) フルアプリケーションプロキシ b) SrcIP パーシステンス Cookie パーシステンスへ変更 c) OneConnect d) Compression e) RAMCache f) WAM 3) 各ステップで Throughput と Connection 数の処理能力を確認 また Step 1) のシステム処理能力を実現するためにいくつの VM が必要かを確認 15

Demo Scenario 2: 詳細 - RAMCache L4 ロードバランス RAMCache 一定の負荷を送信 すべてのコンテンツを VM からとらないといけないのでリクエスト毎に CPU リソースを使う TCP/HTTP プロキシ Cookie と実サーバのテーブル OneConnect 変更 HTTP 圧縮 Static コンテンツを BIG-IP のメモリでキャッシュすることによって VM へ転送するリクエストを減らす その分のユニークリクエストが処理可能となる 負荷装置 RAMCache 論理プロセス 1) 負荷がをかけながら 仮想マシンの数を固定にして システム全体の Throughput と Connection 数を確認 Host 1 Web/App サーバ その他の重大サーバ ( 移動不可能 ) DB サーバ 2) 順次に BIG-IP の L7 機能を有効にする : a) フルアプリケーションプロキシ b) SrcIP パーシステンス Cookie パーシステンスへ変更 c) OneConnect d) Compression e) RAMCache f) WAM 3) 各ステップで Throughput と Connection 数の処理能力を確認 また Step 1) のシステム処理能力を実現するためにいくつの VM が必要かを確認 16

Demo Scenario 2: 詳細 - WAM L4 ロードバランス WAM 負荷装置 一定の負荷を送信 すべてのコンテンツを VM からとらないといけないのでリクエスト毎に CPU リソースを使う WAM TCP/HTTP プロキシ Cookie と実サーバのテーブル OneConnect 変更 HTTP 圧縮 RAMCache 圧縮とキャッシュに Dynamic コンテンツのキャッシングを加えた WAM でさらにユニークリクエストの処理能力を増加 論理プロセス 1) 負荷がをかけながら 仮想マシンの数を固定にして システム全体の Throughput と Connection 数を確認 Host 1 Web/App サーバ その他の重大サーバ ( 移動不可能 ) DB サーバ 2) 順次に BIG-IP の L7 機能を有効にする : a) フルアプリケーションプロキシ b) SrcIP パーシステンス Cookie パーシステンスへ変更 c) OneConnect d) Compression e) RAMCache f) WAM 3) 各ステップで Throughput と Connection 数の処理能力を確認 また Step 1) のシステム処理能力を実現するためにいくつの VM が必要かを確認 17

Demo Scenario 2: 詳細 - その他の調整 WAM TCP/HTTP プロキシ Cookie と実サーバのテーブル irule/ Class Profile OneConnect 変更 HTTP 圧縮 RAMCache Demo に含まれていないがその他のアプリケーションとしてのチューニングが可能 たとえば : 1) Static コンテンツを効率よく処理するチューニングをした VM へ JPG, GIF, CSS, HTML に対してのリクエストを送信 2) CGI 等を Dynamic コンテンツに対してチューニングされた VM へリクエストを送信 これを irule や HTTP Class Profile で簡単にできる Host 1 Dynamic Contents Static Contents Web/App サーバ その他の重大サーバ ( 移動不可能 ) DB サーバ 18

Demo Scenario 2: 結果 Demo Scenario 2 では下記のゴールを実現した : 3) 投資したものに最も高い ROI を実現 リクエスト処理を BIG-IP へオフロードすることで 1 つの Host でより多くの VM が動作可能で VM 投資に対して高い ROI を実現できる 4) 新規サービス投入のリスクを軽減 各 VM の処理に当たるリソースを少なくすることで 他の VM を動作する余裕ができ 同じインフラで新しいサービスの提供が可能になる ソフトウェアの設定費用だけで新規サービスを立ち上げられる 19

F5と VMware の連携 : まとめ 今回のデモで F5 と VMware におけるクラウドインフラに対してのメリットをいくつ確認できた 主に 2 つの効果が見えた : リソースの効率化によって CapEx を抑える ( 投入する HW 等 ) 運用の自動化によって OpEx を抑える 20

THANK YOU ありがとうございましたお問い合わせ :F5 First Contact www.f5networks.co.jp/fc/ END END