INDEX クラウドインフラとクラウドされたアプリケーションの設計 BIG-IP v10 の技術紹介 2

(1)

F5ネットワークスジャパン株式会社

DevCentral

エンジニアリングマネージャ

ジョー・ペルス

クラウドコンピューティング

と最新

BIG

BIG--IP

IPテクノロジー

テクノロジー

(2)

INDEX

■ クラウドインフラとクラウドされた

アプリケーションの設計

(3)

3

第3回DevCentral Members Meeting

「クラウドコンピューティング」

■ 「クラウド」とは何？

– さっきのディスカッションでク

ラウドを少し具体化してみた

• SaaS?

• PaaS?

• IaaS?

• 仮想データセンター？

– しかしそれでもどうしてもクラ

ウドはまだ少しぼやっとして

いるコンセプト

(4)

■ 「クラウド」定義の共通点：

– 強度

でありながら

柔軟

なインフラ

「クラウドコンピューティング」

(5)

5

クラウドでのアプリケーション構築

■ クラウドでのアプリケーション構築の特徴：

– サーバ構築が簡単で莫大なシステムを作るのが比較的に簡単

– 運用中のハードウェアで新サービスを試験的に構築することが可能

■ 上記の柔軟性から強度なインフラの必要性がでてくる：

– 莫大なシステムにはソースをきちんとした管理が必要

– ハードウェアリソースが実際に限られているとの意識が必要

■ つまり、クラウドで構築したアプリケーションには、クラウドのリソース管

理するものと連携できるキャパシティに余裕のあるフロントエンドが必須

– 柔軟なクラウドインフラにおいてのトラフィック処理はこれまでと違う

– Application Delivery Network Layer（ADN レイヤ）及びApplication

(6)

ADN

ADNには

には

_NW

_NWと

と

_App

_{Appの協力が必須}

の協力が必須

アプリケーション側

NW上の動作を意識しながら

アプリケーションを開発：

TCP/UDPフローを理解

アプリケーションを意識した

NW基盤を提供：

運用が簡単、キャパシティがある

この協力が少しずつ見え始めている！

• 「NW」装置をApp/Svr側で管理

• AppのNWを可能な限り簡単な構成

ADNレイヤ

(7)

7

NW

NW・・App

Appを個別に設計するアプローチ

を個別に設計するアプローチ



App者はサーバ、ソフトウェアを担当



NW者はサーバ間を含むパスを担当

(8)

ADN

ADNにおけるアプローチ

におけるアプローチ



App者とNW者がチームとしてアプリケーションを担当

 「アプリケーション」はサーバ以外の機器を含む！

 「システム」として設計

(9)

9

「システム」としての設計

 システム全体を見て、設計する

(10)

アーキテクト：ゴールを考えた設計

 システムとしてのゴール

› 同時ユーザ接続数

› ページ表示時間

› 利用する帯域幅

› 障害が発生したときのリカバリ時間、ステート（RTO、RPO）

› 細かいシステム仕様（例：負荷分散方法）はゴールではなく、ゴール

を満たすためのツールに過ぎない！

 クラウド化されているインフラはこのアプローチに適切である

(11)

11 エンド・ユーザ

ネットワーク

_{アプリケーション}

アプリケーション・アーキテクトによる設計



ユーザはどのようにアクセスする？

› ネットワーク特徴

› 端末特徴



ネットワーク・インフラのニーズは？

› 経路と運用



アプリケーションの特徴は？

› 低レイヤの動作

› 実装すべき機能

› オフロードすべき機能

(12)

Summary

Summary：クラウドと

：クラウドと

_BIG

_BIG--IP

_IP

■ クラウドインフラに必要なのは：

– １）柔軟性を提供する仮想マシン管理システム（vSphere）

– ２）仮想マシン管理システムと連携できるADC（BIG-IP）

– ３）仮想化されたインフラにおいてアプリケーションを設計するマイン

ドセット（アプリケーションアーキテクト）

(13)

BIG

BIG--IP v10

IP v10におけるテクノロジー

におけるテクノロジー

(14)

v10

v10のコンセプト

のコンセプト

■

_{Unified Application Delivery}

■ アプリケーションのフロントエンドに最も適切なデバイスになるため、

統合と集約の機能を強化：

• パフォーマンス

• CMP拡張

• WAM＋ASM併用可

• VIPRION＋ASM

• リソース割り当て

• マルチユーザ

• ルーティングドメイン

• 管理機能拡張（GUI、シェル）

(15)

15

Unified

Unified：：BIG

BIG--IP v9.6

IP v9.6と

と

_v9.4

_{v9.4の機能統合}

の機能統合

■ まずは、ベースは

v9.4と9.6でバラバラ

でリリースされた機能の統合

■

BIG-IP v9.4

– 管理用パーティション

– SCF

• BIG-IPを単一ファイルで設定

– イメージスナップショット

– HTTPプロファイルの拡張

• Cookie暗号化

• Webサーバ署名クローキング

• サーバエラーによるリダイレクト

■

BIG-IP v9.6 (VIPRION)

– GUIでソフトウェア管理

– CMP拡張

• パーシステンス

(16)

Unified

Unified：次世代の

：次世代の

_BIG

_BIG--IP

_{IP HW}

_HWで統合

で統合

■

BIG-IP テクノロジーリフレッシュ

– SCCP → AOM

– PVA → マルチコア

– シンプルなデザインによる品質向上

BIG-IP 6900

BIG-IP 1600

BIG-IP 3600

VIPRION

BIG-IP 8900

(17)

17

BIG

BIG--IP v10

IP v10の新機能

の新機能

■ 新しい

GUI －さらにユーザフレンドリー

• テンプレートによる設定

• ログアウトボタン

■

TMOS Shell－新しいシェルでGTMもCLIで設定可能

• 業界のスタンダード

■

iSession

• BIG-IP間の通信を圧縮や暗号化により最適化

■ リソース・プロビジョニング

• BIG-IPのリソースを細かくコントロール

■ ルーティング・ドメイン

• IPアドレスの重複、

• 複数のデフォルト・ゲートウェイ

■ インバンドモニタ

■

CMP拡張、など・・・

複数の管理者のあるシステム、

NW専門家以外の管理者が喜ぶ

NW専門家が喜ぶ

大きな仮想化された

システムを設計、

運用するアーキテクト

が喜ぶ

(18)

■

XUIの採用

• GUI上の個々のセクションが他の要素と分離しているため、

ひとつの要素の変更が他の部分に影響を与えない

■ ログイン画面

■ ログアウトボタン

■ デザインの変更

■

Fly-outメニュー表示

GUI

GUIの拡張、機能改善

の拡張、機能改善

カスタマイズ可能な

バナー

Form入力による認証

(19)

19 ■

Fly-outメニューにより、管理者は特定のタスクへ

ドリルダウンできる

• それぞれのページ（Profile、Services、HTTP）をロードしないので、

管理者にとっても

TMOSにとっても負荷が軽減

Fly

Fly--out

outメニュー

メニュー

(20)

設定テンプレート

(21)

21

冗長構成ウィザード

(22)

TMOS Shell



BIG-IP v10.0.0からの新しいCLI

 多くの新しい機能

– context sensitive help

– tab completion

– action/object syntax

– tree object structure

 今までのインターフェイス

(bash, bpsh)は当面使用可

 なぜ新しいシェル

?

– お客様からの強い要望

(23)

23 TMOS

TMOS Shell

Shellの例：

の例：バーチャルサーバの設定情報

バーチャルサーバの設定情報

root@lazy(Active)(tmos)# ltm

root@lazy(Active)(tmos.ltm)# virtual

root@lazy(Active)(tmos.ltm.virtual)# list

virtual http_vip {

destination 10.1.1.100:http

ip-protocol tcp

mask 255.255.255.255

pool http_pool

profiles {

http { }

tcp { }

}

snat automap

}

(24)

iSession

iSession －

－

_WAN

_{WANアプリケーション配信サービス}

アプリケーション配信サービス

サイト間の安全かつ最適化された通信

iSessions

Symmetric Adaptive Compression

SSL Encryption

Complete L7 QoS

TCP Express 2.0

iSessions – secure, optimized connection between two BIG-IPs

• iSessionは、BIG-IP上のWANアプリケーションサービスの基盤

• BIG-IP LTM v10からデフォルトでTMOSに含まれる

WAN

Servers

BIG-IP

Firewall

24

(25)

25

iSession

iSessionプロファイル

プロファイル



iSessionプロファイルで、BIG-IP間の通信を最適化

新しい

iSessionプロファイルを

使うことにより、BIG-IP間の通信

をトンネル内で行い、データの暗

号化、圧縮などが可能

•HTTP以外の通信も圧縮

•TCP通信のみ

(26)

iSession

iSessionを利用した

を利用した

_BIG

_BIG--IP

_IP間の

間の

_SSL

_{SSL トンネル}

トンネル

iSession VIP

iSession Pool

Clientside

VIP

ServerSSL:

encrypt

ClientSSL:

decrypt

Clientside VIP

- ServerSSL profile

- LAN optimized TCP profile

- WAN optimized TCP profile

- iSession profile ‘myiSession’

- context=server

- pool = none

Profile myiSession

- compression to match serverside

- port transparency

- Re-use connection

- target VIP = none

Pool myiSessionPool

- - member a.b.c.d:port

iSession VIP

- destination a.b.c.d:port

- ClientSSL profile

- iSession profile ‘myiSession’

- context=client

- LAN optimized TCP profile

- WAN optimized TCP profile

- pool = none

(27)

27

リソース・プロビジョニング

■ WAM、ASMなどの各ソフトウェアモジュールが利用できるCPU、メモリ、

ディスクのリソースが個別に設定できる

• 「Resource Provisioning」（リソース・プロビジョニング）と呼ばれる

• 各モジュールがソフトウェア的に独立している

■ 使用例

• 複雑なセキュリティポリシーを実装しているサイトで、ASMモジュールに多くのリ

ソースを設定

• 簡単なポリシーしか使っていないがVIP、Poolが多いサイトでLTM処理を優先

• ASMライセンスを最初から入れるが、検証が終わるまで本番環境はLTMに

最大限のリソースをアサイン

(28)

リソース・プロビジョニング



モジュール毎の

CPU、Memory、Diskリソースをアサイン

• CPU

－

v10の初期リリースでは、全てのモジュールがtmm以外の

CPUリソースを共有する形で動作

• Memory － tmmおよび各モジュールに個別にアサインされるメモリサイズ

• Disk

－モジュールが利用できるディスクサイズをアサイン

ブート領域や

/sharedのTMOS共有ディスクがカウントに入らない



アサイン対応モジュール

• LTM （つまりtmmデーモン）

• WAM

• ASM

• PSM

• GTM

(29)

29

BIG

BIG--IP

IP 6900 & 8900

6900 & 8900 －

－

_{WAM &}

_{WAM & ASM}

_ASM併用可

併用可

HTTPクラス

ASMとWAMモジュール

を

LTMに連携させる

処理の順番：

Client

WA

Plugin

Server

ASM

Plugin

REQ

RESP

(30)

ルーティング・ドメイン

ルーティング・ドメイン：：重複する

重複する

_IP

_{IPアドレス空間}

アドレス空間

■ そもそもどういうものか？

– 複数のVLAN上に同じIPアドレスが存在することを可能に

– これらのIPアドレス空間にて、個々に受信・送信双方のルーティングを可能