blue
BIG-IPについて その1
BIG-IPについて その1です。
読み方
・F5
エフゴやと思ってた。エフファイブと読む。
・SNAT
エスナットと思ってた。スナットと読む。
負荷分散対象
サーバだけではなくNW機器も可能。
L4で動作させる
TCP/UDPの情報までを参照する。
基本的にはポート番号の情報で決定する。
L7で動作させる
CookieParsistenceを使用したり
HTTPヘッダのUser-Agentを見て判別、など。
1つ目のHTTPリクエストをクライアントからBIG-IPが受信する前の
通信(3ウェイハンドシェイク)はBIG-IPが代理応答する。
VIPRION(ヴィプリオン)
機器。アプリケーションを停止せずに
性能を追加可能。
複数のブレードを搭載したVIPRIONでは、
1つのブレードを取り外した際に
他のブレードに瞬時に処理が引き継がれる。
管理作業とダウンタイムの発生率を低減。
サーバーでいうところのFTサーバーみたいな感じやね。
FirePass
機器。セキュアなリモートアクセス。
ARX
機器。ファイルストレージ仮想化。
TMOS（TrafficManagementOperationSystem）
トラフィック管理アーキテクチャ。
iControl
F5のアプリケーショントラッフィクマネジメント製品を
統合するためのインタフェースを提供する。
MGMTport
マネージメントポート、管理ポート。eth0:mgmt。
初期IPアドレスは192.168.1.245。
コンソール作業はconsoleportにシリアルケーブルを
繋ぐ方法でも可能。
ethernetport
左上から1.1、左下が1.2。
VLANに所属させinternal/externalに割り当てる。
GigabitSFP
光ファイバや銅線を接続する。
コンフィグレーションシート
BIG-IPを含むネットワーク設計用に、
F5Networks製のコンフィグレーションワークシートが有る。
UCS
バックアップファイルとしてファイルをまとめたもの。
ライセンス情報も含まれている。
Provisioning
リソースを計画的に調達する。
BIG-IPVEでは「RuntheSetupUtility」から設定する。
以下のレベルが有る。
●Dedicated
システム上で1つのモジュールのみが機能する。
※dedicated訳：献身的な
※dedicate訳：専念する
●Normal
最小限のリソースを使用し、使用できるリソースが
ある場合は、そのモジュールに追加リソースを配布する。
●Minimum
最小限の機能リソースを使用し、追加リソースは
他のモジュールに分散する。
●None
別のモジュールに専用リソースが必要。
ハードウェアプラットフォーム
●BIG-IPLTM8900シリーズ
クアッドコアCPUx2
16GRAM
16ポート
4ファイバポート
デュアルパワー
●BIG-IPLTM6900シリーズ
デュアルコアCPUx2
8GRAM
16ポート
4ファイバポート
デュアルパワー
●BIG-IPLTM3600シリーズ
デュアルコアCPU
4GRAM
8ポート
●BIG-IPLTM1600シリーズ
デュアルコアCPU
4GRAM
4ポート
TMM
Linux
トラフィックマネジメントマイクロカーネル。
プライマリのシステム。
AOM
AlwaysOnManagemet
8900,6900,3600,1600に搭載されている。
組み込み型Linux。
LightsOutManagementを行う。
TMM障害時にリモートでアクセスするために
専用のIPアドレスを設定しておく。
設定メニューを表示するにはコンソール画面で
「Escキー」の後に「(」を入力する。
その後メニューリスト中の「N」オプションを選択し
networkconfiguratorを実施する。
SCCP
SwitchCardControlProcessing
8800,6400,3400,1500に搭載されている。
組み込み型Linux。
LightsOutManagementを行う。
TMM障害時にリモートでアクセスするために
専用のIPアドレスを設定しておく。
設定メニューを表示するにはコンソール画面で
「Escキー」の後に「(」を入力する。
その後メニューリスト中の「N」オプションを選択し
networkconfiguratorを実施する。
コネクションテーブル
クライアントからBIG-IPへ始めてパケットが到着した時点で
コネクションテーブルへ以下のエントリの値が記載される。
・clientsideclientaddress
・clientsideserveraddress
・serversideclientaddress
・serversideserveraddress
・virtualaddress
・nodeaddress
・protocol
・sequencenumberfromclient
・sequencenumberfromserver
以後のパケットはこのコネクションテーブルに合致すれば
同じコネクションと見なされる。
FINパケット、RSTパケットが有った場合や
タイムアウトすればこのエントリは破棄される。
Node
IPアドレス
※IPアドレスのみ。ポートは含まれないことに注意。
PoolMember
ノード+ポート
Pool
PoolMembersのグループ
非対称ルーティング
パケットの行きと帰りが異なるルートを通ること。
行きはBIG-IPを通ってサーバーへ行き、サーバーからの帰りはルータを通る、
など。解決するにはサーバーのデフォルトルート設定かSNATを使用する。
ロードバランシング方法
種類は以下。RoundRobinとRatio以外は動的。
RoundRobin・Ratio・Observedが多い。
●RoundRobinラウンド・ロビン(静的)
順繰りに分散する方法。
wikipediaに記載の有った語源が面白かった。
●Ratioレシオ(静的)
前もって振り分ける対象ごとに割合を指定しておく方法。
訳：比率
●LeastConnectionsリーストコネクション
現在のコネクション数の最も少ないものへ送信する方法。
●Fastestファステスト
未処理のレイヤー7リクエスト数が最も少ないMemberへ送信する方法。
ping応答時間でもsyn/ack応答時間でも無いことに注意。
pingだとwebサーバーが返す時間は問わないことになるし、
syn/ackだとバックエンドサーバーの処理する時間は問わないことになる。
●Observedオブザーブド
レシオを使用する。1秒ごとにレシオを再割当てしている。
平均よりコネクション数が少なければRatio3、
平均よりコネクション数が多ければRatio2が割り当てられる。
●Predictiveプリディクティブ
レシオを使用する。1秒ごとにレシオを再割当てしている。
平均よりコネクション数が少なければRatio4、
平均よりコネクション数が多ければRatio1が割り当てられる。
なので4倍の差が出る。
レシオを使用するものは判定方法が2種類有る。Memberとnode。
Memberで振り分けている場合のhttpのリクエストは、
httpのコネクション数が最も少ないサーバーへ送信される。
その際はftpなど他のサービスのコネクション数は問わない。
各サービス毎の負荷の差が大きい場合はMemberで振り分けた方が
良いってことかな。
Nodeで振り分けている場合のhttpのリクエストは、
全てのサービスのコネクション数の合計が最も少ない
サーバーへ送信される。なかなか荒っぽい分け方な気がするね。
ポート番号を見ずに振り分けるだけ有って処理速度は速くなるかな。
PriorityGroupActivation
PoolMember6台で1つのPoolを構成し、
3台の優先度を10に、残りの3台の優先度を5に設定する。
この時、PriorityGroupActivation(2)が設定されていれば
優先度10のMembers3台のみを使用し負荷分散される。
もし優先度10のMembers3台のうち、1台のみ稼働し、
2台が停止している場合は使用可能なPoolMemberの最低数
「2台」の設定を下回るために優先度5の3台へも振り分けが
開始される。なので計4台で負荷分散される。
PoolMember3台で1つのPoolを構成し、
Priorityをそれぞれ3,2,1に設定する。
この時、PriorityGroupActivationが2に設定されていていれば
Priority3とPriority2の2台のみが使用される。
FallbackHost(httpのみ)
全Membersがダウンした場合はBIG-IPはhttpリダイレクトを
クライアントへ送信する。
HTTPProfileで設定する。
全Membersがダウンした場合の対処はiRule処理によって、
sorryserverへ振り分けたり、BIG-IP自身がhttpを返すように
することも出来る。
モニターチェックについて
種類は以下。
●ICMP(アドレスチェック)
ICMPEchoリクエストを発行する。応答として
EchoReplyを予期する。
●expected＝予期するって表現は度々BIG-IP資料で出て来る。
「特定の返答データを待つ」もしくは「期待して、待ち受ける」みたいな
やと思う。
●TCP_Half_Open(サービスチェック)
TCPSYNをパケットを発行して、SYN-ACKを予期。
SYN-ACKを受信したらRESETを発行する。
●HTTP(コンテンツチェック)
接続を開く。接続の完了時にGET/コマンドを発行する。
接続の完了と受信ルールが有る場合は受信ルールへの
応答の一致を予期する。データ(予期されるデータが有る
場合)を受信したら、接続を閉じる。
●FTP(インタラクティブチェック)
接続を開く。接続の完了時にユーザーIDとパスワードを
送信し、指定されたディレクトリへのCWDの発行、及び指定
されたファイル名に対するGET<ファイル名>の発行。接続の
完了およびファイル転送の成功を予期する。
ファイルを受信したら接続を閉じる。
Statusアイコンについて
●丸い緑色のアイコン
Available
Monitorチェックが成功。
新しいクライアント接続を送信する。
◆菱形で赤色のアイコン
Offline
Monitorチェックでタイムアウトした。
新しいクライアント接続は送信されない。
■四角で青色のアイコン
Unknown
Monitorが割り当てられていないか、
Monitorチェックの結果がまだ分からない。
新しいクライアント接続を送信する。
※Unknownでも接続を送信することに注意する。
▲三角で黄色のアイコン
Unavailable
設定されたコネクション数の制限に達している。
新しいクライアント接続は送信されない。
・VirtualSeverのStatusは、VirtualSeverに
関連付けしたPoolsのStatusによって決定されることに注意する。
・「NetworkMap」で、全てのStatusが一覧できる。
システムの稼働状況が一目で分かる。
左ウィンドウの「LocalTraffic」-「NetworkMap」から。
Profileについて
希望するトラフィック動作を定義しておく。
特定のVirtualServerを介したトラフィック処理方法を
BIG-IPに指示する。
パーシステンスプロファイルはVirtualServerのデフォルトの
負荷分散方法よりも優先される。負荷分散方法を上書きする訳ではない。
複数のVirtualServersに適用できるので便利。
デフォルトProfile(テンプレート)の格納場所は
/config/profile_base.conf。削除は出来ない。
デフォルトProfileそのものを編集することは推奨しない。
カスタムProfilesの格納場所は/config/bigip.conf。
デフォルトProfileから作成する、Windowsの
グループポリシーを思い出すね。
親子関係が有る。子プロファイルを作成終了した後で
親プロファイルを変更した場合、子プロファイルの設定の中で
ただ単に親プロファイルから引き継いだけの設定
(Customチェックボックスにチェックが入っていない項目)は、
影響を受けて(動的に)変更される。
例外として親プロファイルから引き継いだだけだが、
Customチェックボックスにチェックを入れていた項目については
静的とみなされ、変更されない。
Profileの例
●Services
●Persistence
Persistenceの詳細は
以下の「Persistenceについて」を参照。
●SSL
ClientSSLProfilesを有効にするには
以下の「SSLTerminationとClientSSL」を参照。
●FTP
通常、サーバー発信のクライアントへのパケットはBIG-IPLTMで破棄される。
荒っぽく言うと既定動作としてクライアントからの応答パケットしか返せない。
なのでFTPの動作(クライアントからポート21で制御接続を開始して
サーバーがポート20でデータ転送を開始する。)の場合、
FTPProfileを使用しなければサーバーのイニシエーションパケット
(Initiationpacket)はクライアントに到着しない。
Profileの種類
●ServersProfiles
レイヤー7関連。HTTPやFTP。
●iRuleでHTTP_REQUESTを使用して処理させている時など、
BIG-IPがそれら見る必要がある場合には必ずHTTPのProfileを設定しておくこと。
●PersistenceProfiles
Cookieやsourceaddress。
●ProtocolProfiles
レイヤー4関連
TCPやUDPやFastL4
●SSLProfiles
ClientSSLかServerSSLのどちらか。
暗号化されるトラフィックの名前が関連付けられる。
●AuthenticationProfiles
負荷分散の前に認証サーバーと連携してクライアント認証を行う。
LDAP、RADIUS、TACACS+。
●その他
StreamProfile。サーバーからクライアントへコンテンツが配信
される前にBIG-IPによってコンテンツを変更できる。
Profileの依存関係
1部のProfileは他のProfileに依存する。
●CookieProfileを使用するならHTTPProfileが必要
HTTPヘッダを読み取る必要があるため。
●HTTPProfileにはTCPProfileが必要。
●SSLProfileにはTCPProfileが必要。
(SSLTermination、ClientSSL及びServerSSLを使用する場合など)
以下の「レイヤー4Plofiles」を参照する。
レイヤー4Plofiles
●全てのVirtualServersにレイヤー4Plofileが存在している。
●よく使用されるPlofileはTCP・UDP・fastL4。
●自動的にVirtualServerが設定する。
共存できないProfile
VirtualServerにProfileを設定する場合、HTTPとFTPは共存不可。
TCPとUDPも共存不可。
Persistenceについて
●Cookie(CookiePersistence)
HTTPプロトコルにしか対応していない。
HTTPSで使用する場合はSSLTerminationを使う。
クライアントでcookieを無効にしてるか日付がoffの場合、
送信されない可能性が有る。
●ここで扱うCookie＝「特別なCookie」はプール名と
プールメンバー(エンコード)が含まれている、ということが重要。
CookiePersistenceのモードは以下。
●InsertMode
BIG-IPLTMが「特別なCookie」(プール名とプールメンバー(エンコード))を
HTTP応答に入れ込んでクライアントに返す。
期限切れで有れば新しいタイムスタンプで新しいCookieを入れ込む。
Cookieの最大保存容量の4Kバイトを超えればエラーになることに注意。
サーバーは「特別なCookie」の存在すら知らないし、貰う時は無い。
●RewriteMode
サーバーが空のCookieを作成し、
BIG-IPLTMが、InsertModeと同じ「特別なCookie」に書き換える。
サーバーは常に空のCookieをBIG-IPLTMへ渡す。
●PassiveMode
サーバーが常に「特別なCookie」を作成してBIG-IPLTMへ渡す。
BIG-IPLTMは受動的に使用する。
●ソースIPアドレス(SourceAddressPersistence)
ネットマスクで判断する方法です。
デフォルトのネットマスクは/32。それを/24にしたりする。
/32にした場合は接続しに来た全てのIPアドレスがPersistenceRecordで
管理されその分BIG-IP負担になる、と思われる。
NATデバイスやproxyサーバーを通過する場合など、
同じIPから大量にアクセスされる場合はサーバの負荷が偏る。
HTTPSVirtualServerでも使用可能。IPアドレスは暗号化されないため。
SourceAddressPersistenceの項目で記述設定できるのはTimeoutとmask。
●SSLセッションID(SSLSessionID)
SSLセッションIDで判断する方法。
セッションIDがブラウザで時間毎に変更されるためあまり有用ではない。
●ユーザーID・サーバID
cookieに対応していない携帯端末向けサイトなど
前回接続したサーバの情報(サーバID)をサーバ側でURLに埋め込み、負荷分散機器がそれを読み込む。
URL等に端末個体識別情報が含まれる場合はそれのハッシュ値により接続維持が可能。
●デスティネーションアドレスアフィニティ(DestinationAddressAffinity)
キャッシュサーバのキャッシュ内容を使用する。
PersistenceRecord
最初の接続時にBIG-IPがセッションデータを追跡し
PersistenceRecordに保存する。
クライアントの特性やクライアントリクエストを
処理したPoolMemberの情報が含まれる。
この情報を使用して再接続クライアントが決定される。
PersistenceRecordの有効期間内では同一のPoolMemberへ送信される。
ここでのセッションとはクライアントとPoolMember間との
仮想的な通信リンク、個別の接続のセット。
AdministrativeState
サーバー保守等で新しい接続を一旦停止する場合など使用する。
VirtualServers、PoolMembers、Nodesに対して設定する。
DisabledやForcedOfflineへ変更しても、即時既存のトラフィックが
切断される訳ではない。セッションが終了するかタイムアウトしない
限りは維持し続ける。
AdministrativeStateを変更した場合、MonitorStatusアイコンが
AdministrativeStatusアイコンになる。AdministrativeStateは以下の3つ。
実際の設定欄には以下のように説明されている。(PoolMenberへの設定時)
・Enabled(Alltrafficallowed)
・Disabled(Onlypersistentoractiveconnectionsallowed)
・ForcedOffline(Onlyactiveconnectionsallowed)
●Enabled
デフォルト状態。Monitorによって状態が決定される。
●Disabled
現在開かれてる接続と、
再接続クライアントの接続(=PersistenceRecordに一致する接続
=パーシステントセッション)を通す。
Disabledにすると、MonitorStatusアイコンが真っ黒の
AdministrativeStatusアイコンになる。形は変わらない。
もし全MemberをDisabledにしても再接続クライアントは通すため、
PoolはAvailableのまま。当然Poolの状態を参照するVirtualServerも
Availableのまま。
●ForcedOffline
現在開かれてる接続のみ通す。
PersistenceRecordなどは参照されない、無理。
Monitorチェックは実行されない。
ForcedOfflineになるとAdministrativeStatusアイコンが
どんな色や形で有ったにしろ、真っ黒で菱形のAdministrativeStatus
アイコンに変化する。OfflineでDisabledの真っ黒菱形アイコンと
見分けがつかなくなるけどね。その場合はアイコンの上にカーソルを
乗せれば説明が表示されるのでそれを確認すること。
もし全MemberがForcedOfflineになると新しい接続は受け付けないため
PoolはDown/Offlineとなる。当然Poolの状態を参照するVirtualServerも
Down/Offlineとなる。