F5ネットワークスジャパン株式会社
DemoCenter
Live
Live Demo
Demo：：BIG
BIG--IP
IPと
と
vSphere
vSphereに
に
おけるクラウドアプリケーション
おけるクラウドアプリケーション
INDEX
■
Demoの目的、ゴール
■
Scenario 1: 自動化
F5
F5と
と
VMware
VMwareの連携で構築する「クラウド」
の連携で構築する「クラウド」
■ 「クラウド」についての様々な定義がある：
– インフラ・プロバイダからCPUリソースを借りる（仮想マシンを渡す）
– アプリケーション・プロバイダからアプリケーションを含むリソースを借りる
（データを渡す）
– 自前システムを仮想化（仮想インフラを構築）
– など、、、
■
F5とVMwareの連係は仮想インフラの構築にメリットがある
– 自前システムで行う場合、あるいはインフラ、アプリケーションのプロバイダとし
て仮想インフラを提供する場合に利用
■ ゴール：
– 1） 運用費用（OpEx）の削減：運用にかかわる時間と手間を減らす
– ２） リソースの効率化：実際に必要なものにリソースを投資
– ３） 投資したものに最も高いROIを実現：アプリケーションとして最大限のパフォーマン
スを実現
– 4） 新規サービス投入のリスクを軽減：低いCapExで新サービスを提供
F5
F5と
と
VMware
VMwareの連携で構築する「クラウド」
の連携で構築する「クラウド」
■ ゴール
– 1） 運用費用（OpEx）の削減
• メインテナンス用の作業を短縮
• 様々な作業を自動化
• 運用にかかわる時間と手間を減らす
– ２） リソースの効率化
• 不要なとき、利用するリソースを減らす
• リソースが急に必要になった場合に自動的に増加
– ３） 投資したものに最も高いROIを実現
• アプリケーションのパフォーマンスを最大限に
• 実際に必要なものにリソースを投資
– 4） 新規サービス投入のリスクを軽減
• CapExを抑えながら新サービスを提供
Demo:
Demo: クラウド化されたアプリケーション
クラウド化されたアプリケーション
■ 「クラウド」についての様々な定義から、よくあげられる例を見てみよう：
– Web Based Application
■ 本デモでは、次のメリットを確認する
– 急なトラフィック増加に対して追加リソースを自動的に確保
– オフピーク時間はリソースを無駄にしない
– どの時でもサーバ仮想化に対して高いROIを実現
• 必要以上のHostを使わない
• 各Host上に必要以上のリソースを利用しない
• たくさんの仮想サーバを1つのHostにまとめる
– リソース管理のためにアプリケーションを落とすことが不可能
• クラウド基盤は仮想サーバの位置を把握し正しくトラフィックを処理
Demo
Demo Scenario 1
Scenario 1：概要（論理図）
：概要（論理図）
Web/Appサーバ 負荷装置 DBサーバ
物理サーバである環境においては
ほぼ不可能な運用方法！
処理可能な
Throughputと
Connection数がどんどん増加
1） 負荷が上がってしまうことによって、Web/Appサーバの CPU使用率が100%に近づく。 2） 高CPU資料率が30秒以上続くと、新しいWeb/Appサーバ が自動的に立ち上げる。 3） 最終的にすべてのWeb/Appサーバが負荷をうまく吸収する （各サーバのCPU使用率が数十パーセントに収まる）。 4） 負荷が無くなった場合、不要となったサーバ（低CPU使用率） が自動的にシャットダウン論理プロセス
Demo
Demo Scenario 1
Scenario 1：詳細（物理図）
：詳細（物理図）
vCenter/ iControlサーバ Web/Appサーバ 負荷装置 ④ Host 1のCPUリソースが足りなくなったらHost 2を起動し、 vMotionでVMを移動する Host 2 Host 1 1） 負荷が上がってしまうことによって、Web/Appサーバの CPU使用率が100%に近づく。 2） 高CPU資料率が30秒以上続くと、新しいWeb/Appサーバ が自動的に立ち上げる。 3） 最終的にすべてのWeb/Appサーバが負荷をうまく吸収する （各サーバのCPU使用率が数十パーセントに収まる）。 4） 負荷が無くなった場合、不要となったサーバ（低CPU使用率） が自動的にシャットダウン DBサーバ NAS Datastore その他の重大サーバ （移動不可能）
論理プロセス
① 一定の負荷を送信 ② vCenterがVMのCPU使用率 に気づき、新VMを起動 ③ 新VMをBIG-IP のプールに追加 ⑤ 負荷がなくなったらHost 2及び 不要のVMをシャットダウンDemo
Demo Scenario 1
Scenario 1：： 注釈
注釈
■ 本デモではもっと素早く
vMotionを実行させるためにHost 1にその他の
負荷をかけている（
DNS等）
■
BIG-IPは単純なL4ロードバランサとして動作している（FastL4）
– 本デモはVMwareとF5のAPIにおける自動化を確認するため
■
vMotionを実現するために、仮想マシンのファイルをNASのデータスト
アに保存する必行がある
Demo Scenario 1
Demo Scenario 1：結果
：結果
■
Demo Scenario 1では下記のゴールを実現した：
– 1） 運用費用（OpEx）の削減
• vMotionでは、仮想マシンを動いたまま異なるHostへ移動できるため、Hostのメイ
ンテナンス時にサービスを落とす必要がない
• リソースの増加を仮想していない環境で実施するには、とんでもないコストがかか
るが
F5＋VMwareの場合簡単にできる
– ２） リソースの効率化
• アプリケーションが常に必要のリソースだけを利用しているので、オーバスペック
などの無駄なリソースを用意しておく必要がない
Demo Scenario 1
Demo Scenario 1：補足
：補足
■ 今回は増加可能なサーバ数を固定しておいた。これによって最大限に
使うリソースが予めわかって、コントロールできる。
■ リソースを制限する必要がない環境では、本デモの動作にテンプレート
から新規
VMをクローンする作業を追加できる。
■
FastL4における単純ロードバランスは充分？
– 処理能力の高いハードウェアが安いので、L4ロードバランスは充分ではない
か、という考え方もある
– しかし、仮想マシンの概念ではこの考え方を適用できない：
• 仮想マシンは制限されているリソースを共有している
• 限られたリソースを効率よく使うのがROIにつながる
• Demo Scenario 2で確認！
Demo Scenario 2:
Demo Scenario 2: 概要（論理・物理図）
概要（論理・物理図）
Web/Appサーバ Host 1 1） 負荷がをかけながら、仮想マシンの数を固定にして、システ ム全体のThroughputとConnection数を確認。 2） 順次にBIG-IPのL7機能を有効にする： a) フルアプリケーションプロキシ b) SrcIPパーシステンス→Cookieパーシステンスへ変更 c) OneConnect d) Compression e) RAMCache f) WAM 3） 各ステップでThroughputとConnection数の処理能力を確認。 また、Step 1)のシステム処理能力を実現するためにいくつのVM が必要かを確認。 DBサーバ その他の重大サーバ （移動不可能）論理プロセス
負荷装置 一定の負荷を送信Demo Scenario 2:
Demo Scenario 2: 詳細
詳細 －
－
Full
Full Proxy
Proxy
Web/Appサーバ 負荷装置 Host 1 1） 負荷がをかけながら、仮想マシンの数を固定にして、システ ム全体のThroughputとConnection数を確認。 2） 順次にBIG-IPのL7機能を有効にする： a) フルアプリケーションプロキシ b) SrcIPパーシステンス→Cookieパーシステンスへ変更 c) OneConnect d) Compression e) RAMCache f) WAM 3） 各ステップでThroughputとConnection数の処理能力を確認。 また、Step 1)のシステム処理能力を実現するためにいくつのVM が必要かを確認。 その他の重大サーバ （移動不可能）
論理プロセス
一定の負荷を送信 L4 ロードバランサ フルアプリケーションプロキシ 各VMで処理能力に よって、システムとして 処理可能なリクエスト 数が限られる 各VMの処理能力が 変わらないが、BIG-IP がリクエストを一旦受ける ことでシステム全体の Throughput、Connection数 が上がる。また、BIG-IP のTCPスタックのチューニング における効果もあり。 TCP HTTP プロキシDemo Scenario 2:
Demo Scenario 2: 詳細
詳細 －
－
Cookie
Cookie Persistence
Persistence
Web/Appサーバ Host 1 1） 負荷がをかけながら、仮想マシンの数を固定にして、システ ム全体のThroughputとConnection数を確認。 2） 順次にBIG-IPのL7機能を有効にする： a) フルアプリケーションプロキシ b) SrcIPパーシステンス→Cookieパーシステンスへ変更 c) OneConnect d) Compression e) RAMCache f) WAM 3） 各ステップでThroughputとConnection数の処理能力を確認。 また、Step 1)のシステム処理能力を実現するためにいくつのVM が必要かを確認。 DBサーバ その他の重大サーバ （移動不可能）
論理プロセス
負荷装置 一定の負荷を送信SrcIP Persistence Cookie Persistence
HTTPプロキシなどに よって複数のクライア ントが同じサーバへ 振り分けられることも ある セッションIDを利用し より平衡な負荷分散を実施 Cookie と実サーバ のテーブル TCP HTTP プロキシ
Demo Scenario 2:
Demo Scenario 2: 詳細
詳細 －
－
OneConnect
OneConnect
Web/Appサーバ Host 1 1） 負荷がをかけながら、仮想マシンの数を固定にして、システ ム全体のThroughputとConnection数を確認。 2） 順次にBIG-IPのL7機能を有効にする： a) フルアプリケーションプロキシ b) SrcIPパーシステンス→Cookieパーシステンスへ変更 c) OneConnect d) Compression e) RAMCache f) WAM 3） 各ステップでThroughputとConnection数の処理能力を確認。 また、Step 1)のシステム処理能力を実現するためにいくつのVM が必要かを確認。 その他の重大サーバ （移動不可能）
論理プロセス
負荷装置 一定の負荷を送信 L4 ロードバランス OneConnect TCPコネクションをそ のまま渡すので、VM 側の処理能力を奪う Keepaliveへ変更すること によってVM側のコネクショ ン数とそれに伴う処理能力 の減少を抑えて、ユニーク なリクエストで処理可能な TCPセッションが増える。 ※最近のクライアントは常 にKeepaliveを利用してい るので、実際の効果が少な いと考える Cookieと実 サーバのテー ブル TCP/HTTP プロキシ OneConnect 変更Demo Scenario 2:
Demo Scenario 2: 詳細
詳細 －
－
Compression
Compression
Web/Appサーバ Host 1 1） 負荷がをかけながら、仮想マシンの数を固定にして、システ ム全体のThroughputとConnection数を確認。 2） 順次にBIG-IPのL7機能を有効にする： a) フルアプリケーションプロキシ b) SrcIPパーシステンス→Cookieパーシステンスへ変更 c) OneConnect d) Compression e) RAMCache f) WAM 3） 各ステップでThroughputとConnection数の処理能力を確認。 また、Step 1)のシステム処理能力を実現するためにいくつのVM が必要かを確認。 DBサーバ その他の重大サーバ （移動不可能）
論理プロセス
負荷装置 一定の負荷を送信 L4 ロードバランス HTTP圧縮 各VMで圧縮を実施し ているので、VMの CPU処理能力を利用 BIG-IPが代理に圧縮を実 施するので、VMのCPUリ ソースがより多くのリクエス ト処理で利用できる Cookieと実 サーバのテー ブル TCP/HTTP プロキシ OneConnect 変更 HTTP圧縮Demo Scenario 2:
Demo Scenario 2: 詳細
詳細 －
－
RAMCache
RAMCache
Web/Appサーバ Host 1 1） 負荷がをかけながら、仮想マシンの数を固定にして、システ ム全体のThroughputとConnection数を確認。 2） 順次にBIG-IPのL7機能を有効にする： a) フルアプリケーションプロキシ b) SrcIPパーシステンス→Cookieパーシステンスへ変更 c) OneConnect d) Compression e) RAMCache f) WAM 3） 各ステップでThroughputとConnection数の処理能力を確認。 また、Step 1)のシステム処理能力を実現するためにいくつのVM が必要かを確認。 その他の重大サーバ （移動不可能）
論理プロセス
負荷装置 一定の負荷を送信 L4 ロードバランス RAMCache すべてのコンテンツを VMからとらないといけ ないのでリクエスト毎 にCPUリソースを使う StaticコンテンツをBIG-IP のメモリでキャッシュするこ とによってVMへ転送するリ クエストを減らす。その分 のユニークリクエストが処 理可能となる Cookieと実 サーバのテー ブル TCP/HTTP プロキシ OneConnect 変更 HTTP圧縮 RAMCacheDemo Scenario 2:
Demo Scenario 2: 詳細
詳細 －
－
WAM
WAM
Web/Appサーバ Host 1 1） 負荷がをかけながら、仮想マシンの数を固定にして、システ ム全体のThroughputとConnection数を確認。 2） 順次にBIG-IPのL7機能を有効にする： a) フルアプリケーションプロキシ b) SrcIPパーシステンス→Cookieパーシステンスへ変更 c) OneConnect d) Compression e) RAMCache f) WAM 3） 各ステップでThroughputとConnection数の処理能力を確認。 また、Step 1)のシステム処理能力を実現するためにいくつのVM が必要かを確認。 DBサーバ その他の重大サーバ （移動不可能）
