System Admins and Developers
Hands-On Labs
Oracle Solarisの統合ロードバランサを60分で導入する方法
Amir Javanshir
このラボでは、Oracle Solarisの統合ロードバランサ機能をロードバランシング・システムに簡単かつ迅速に導入する方法を説明します。また、統合ロードバランサが提供する、さまざまな種類のロードバランシング・モードの使用方法についても紹介します。
2014年2月公開
|
概要とラボの目標
前提条件
ラボの演習の概要
このラボで利用するテクノロジー
ラボの大域アーキテクチャ
システムの準備（ラボの前提条件）
ラボの演習：詳細手順
付録A：ネットワーク仮想化と統合ロードバランサの詳細
参考資料
著者について
概要とラボの目標
このドキュメントでは、Oracle OpenWorld Hands-On Lab 10181セッションで行ったすべての操作について詳細を説明します。
注：このラボは、自宅やオフィスのx86サーバー、デスクトップ、またはラップトップからでも実行できます。
Oracle Solaris 11は、統合ロードバランサと呼ばれる、追加設定不要のレイヤー3またはレイヤー4のロードバランシング機能を提供しています。この機能は、受信リクエス トをインターセプトし、カスタマイズされたロードバランシング・ルールに基づいて、バックエンド・サーバーへのリダイレクションを処理します。統合ロード バランサは、任意のOracle Solaris 11サーバーを、費用対効果に優れ、しかも強力なロードバランシング・システムへと変貌させます。
このハンズオン・ラボは、ロードバランシング・システムの導入や管理を行う必要のあるアプリケーション・アーキテクトまたはシステム管理者向け に作成されました。このラボでは、統合ロードバランサの有効化、構成、利用のプロセス全体に関する概要を説明します。具体例として、単純なApache Tomcat Webアプリケーションを複数のOracle Solarisゾーン（Oracle Solarisの一機能）に導入し、統合ロードバランサを使用してさまざまなロードバランシングのシナリオを紹介します。
このラボの途中で、統合ロードバランサをOracle Solarisゾーン内に構成して利用し、3つのApache Tomcat Webサーバーに対してロードバランシングを実行します。これらのWebサーバーでは、このラボ用に開発された単純なJavaServer Pages（JSP）アプリケーションが稼働しています。
前提条件
実際のラボを開始する前に、次の操作を実行してラボ環境を準備する必要があります。
- Oracle Solaris 11.1のインストール
- 仮想スイッチ（etherstub）と仮想NIC（VNIC）の作成
- 大域ゾーンのVNIC（
gz_1）の構成 - 4つのOracle Solarisゾーンの構成：統合ロードバランサをホストするためのゾーン1つ（
ilb-zone）と、Webサーバーをホストするためのゾーン3つ（web1、web2、web3） ilb-zoneの構成：ラボに必要となるパッケージ（例：Apache Tomcat 6）のインストールなど/etc/hostsファイルの構成rootでのSSH接続の有効化- JSPテスト・ファイルの作成（統合ロードバランサのテストに使用）
ilb-zoneのクローニングによるweb1、web2、web3の迅速なインストールilb-zoneの2つ目のVNIC構成（パブリック・インタフェース10.5.1.1）- Apache JMeterのインストールとテスト・ファイルの作成（別の方法による統合ロードバランサのテストに使用）
このラボを自宅またはオフィスから実行するには、次の手順を実行します。
- 使用するx86マシンが次の仕様を満たしているかを確認します。
- 8GB以上のRAM、2コアCPU
- Oracle VM VirtualBoxでサポートされるx86オペレーティング・システム（例：x86向けOracle Solaris、Microsoft Windows、ほとんどのLinuxディストリビューション、Apple Mac OSX）
- "システムの準備（ラボの前提条件）"の項に示す手順を実行し、上記で説明した操作を実行してラボ環境を準備します。
ラボの演習の概要
"システムの準備（ラボの前提条件）"の項に示す手順を実行してx86マシンで環境を準備した後は、以下に示すラボの演習を行います。
- Oracle VM VirtualBoxでOracle Solaris 11仮想マシンを起動します。
- Oracle Solaris 11サーバーにログインします。
- 現在の環境をチェックします。
- 統合ロードバランサを有効化します。
- Web環境を検証します。
- ロードバランサをネットワーク・アドレス変換（NAT）モードで構成してテストします。
- カスタマイズしたヘルス・チェック・スクリプトを作成してテストします。
- ロードバランサをDirect Server Return（DSR）モードで構成してテストします。
- バックエンド・サーバー・グループにサーバーを追加し、そのグループからサーバーを削除します。
このラボで利用するテクノロジー
ロードバランサのテストに必要となるネットワーク・トポロジやサーバー・トポロジを単純なx86マシン上でエミュレートするために、このラボでは次のOracle Solaris 11組込みテクノロジーを利用します。
- Oracle Solarisゾーンによるサーバー仮想化
Oracle Solarisゾーンテクノロジーは、特定のアプリケーション・ニーズに応えるために、同じOracle Solarisインスタンス上で複数の独立環境を作成できる機能を提供します。それぞれの環境が独自のホスト名、IPアドレス、IPスタックを持つ"実際 の"サーバーとして動作します。表1に、このラボで共通して使用するコマンドを示します。
表1：共通して使用するOracle Solarisゾーンコマンド目的 コマンド すべてのゾーンとそのステータスの表示 zoneadm list -civゾーンへのログイン zlogin zone_name
または
ssh root@zone_host_nameゾーンの起動 zoneadm -z zone_name bootゾーンの再起動 zoneadm -z zone_name rebootゾーンのシャットダウン zoneadm -z zone_name shutdown
このラボでは次のゾーンが作成されます。
[root@kafka]# zoneadm list -civ ID NAME STATUS PATH BRAND IP 0 global running / solaris shared 1 ilb-zone running /zones/ilb-zone solaris excl 2 web2 running /zones/web2 solaris excl 4 web1 running /zones/web1 solaris excl - web3 installed /zones/web3 solaris excl
ゾーンのステータスは、running、installed（シャットダウン済み）、configured（未インストール）のいずれかです。このラボの大域ゾーンのホスト名は
kafkaです。 - ネットワークの仮想化
Oracle Solaris 11は数あるネットワーク機能の中で、仮想ネットワーク・インタフェース・カード（VNIC）と仮想スイッチ（etherstub）の機能も提供していま す。これらを利用して、1つの筐体内で仮想データセンターを構築できます。表2に、このラボで共通して使用するコマンドを示します。
表2：共通して使用するネットワーク仮想化コマンド目的 コマンド すべての物理NICの表示 dladm show-physすべてのVNICの表示 dladm show-vnicすべてのetherstubの表示 dladm show-etherstubすべてのIPインタフェースの表示 ipadm show-ifすべてのIPアドレスの表示 ipadm show-addrルーティング・テーブルの表示 netstat -rn - Oracle Solarisサービス管理機能
Oracle Solarisのサービス管理機能は、システム・サービスやアプリケーション・サービスを管理するために従来の
表3：共通して使用するサービス管理機能コマンドinitスクリプト・メカニズムを置き換える機能であり、このラボでは統合ロードバランサとTomcatのサービスを管理するために使用します。表3に、このラボで共通して使用するコマンドを示します。目的 コマンド すべてのサービスの表示 svcs -aサービスのステータスの表示 svcs service_name
または
svcs -l service_name（詳細情報の表示）サービスの有効化 svcadm enable service_nameサービスの無効化 svcadm disable service_nameサービスの再起動 svcadm restart service_name保守状態にあるサービスのオンラインへの復帰の試行 svcadm clear service_name
サービスのステータスは、
online（有効化済み）、disabled、maintenance（オンライン状態不可）のいずれかです。
ラボの大域アーキテクチャ
図1に、ラボのアーキテクチャに関する大域ゾーンの詳細なビューを示します。この大域ゾーンは2つのネットワークと4つのゾーンをホストします。
図1：ラボのアーキテクチャ
注：これはラボで使用する大域アーキテクチャですが、ラボの開始時点ではロードバランサをNATモードで使用するために、web1ゾーン、web2ゾーン、web3ゾーンをプライベート・ネットワーク（赤色）にのみ接続します。後の演習で、ロードバランサをDSRモードで運用するためにこれらのゾーンをパブリック・ネットワーク（青色）に接続します。
システムの準備（ラボの前提条件）
ここでは、ラボの演習を開始する前のx86マシンの準備方法について説明します。すべてのコマンドはrootで実行します。
Oracle Solaris 11.1のインストール
はじめに、Oracle VM VirtualBoxにOracle Solaris 11.1をインストールします （お使いのx86マシンにまだOracle VM VirtualBoxがインストールされていない場合は、ダウンロードしてインストールしてください）。
Oracle Solaris 11.1は次の場所からダウンロードできます。http://www.oracle.com/technetwork/jp/server-storage/solaris11/downloads/index.html
複数のインストール・メディアが提供されていますが、"Oracle Solaris 11.1 Live Media for x86"を選択してください。このメディアにより、完全なグラフィカル環境を備えたOracle Solaris 11.1がインストールされます。グラフィカル環境は統合ロードバランサを使用するための前提条件ではありませんが、このラボではインストールすることを お勧めします。
仮想スイッチとVNICの作成
Oracle Solaris 11をインストールしたら、ログインして次のコマンドを実行し、仮想スイッチ（etherstub）とVNICを作成します。
[root@kafka]# dladm create-etherstub switch1 [root@kafka]# dladm create-etherstub switch2 [root@kafka]# dladm create-vnic -l switch1 gz_1 [root@kafka]# dladm create-vnic -l switch1 ilb_1 [root@kafka]# dladm create-vnic -l switch1 web1_1 [root@kafka]# dladm create-vnic -l switch1 web2_1 [root@kafka]# dladm create-vnic -l switch1 web3_1 [root@kafka]# dladm create-vnic -l switch2 ilb_2 [root@kafka]# dladm create-vnic -l switch2 web1_2 [root@kafka]# dladm create-vnic -l switch2 web2_2 [root@kafka]# dladm create-vnic -l switch2 web3_2
大域ゾーンのVNICの構成
内部的な"パブリック"ネットワークを作成します。そのためには、大域ゾーンをVNIC（gz_1）経由で仮想スイッチ（switch1）に接続する必要があります。これを設定するには、次のコマンドを実行します。
[root@kafka]# ipadm create-ip gz_1 [root@kafka]# ipadm create-addr -T static -a 10.5.1.6/24 gz_1/v4
4つのOracle Solarisゾーンの構成
- リスト1の内容を使用して、
/root/ilb-zone.cfgというゾーン構成ファイルを作成します。
create -b set brand=solaris set autoboot=true set zonepath=/zones/ilb-zone set autoboot=true set ip-type=exclusive add net set configure-allowed-address=true set physical=ilb_1 end add net set configure-allowed-address=true set physical=ilb_2 end
リスト1：
/root/ilb-zone.cfgファイルの内容 - リスト2の内容を使用して、
/root/web1.cfgというweb1のゾーン構成ファイルを作成します。
create -b set brand=solaris set autoboot=true set zonepath=/zones/web1 set autoboot=true set ip-type=exclusive add net set configure-allowed-address=true set physical=web1_1 end add net set configure-allowed-address=true set physical=web1_2 end
リスト2：
/root/web1.cfgファイルの内容 - 残り2つのゾーン構成ファイル（
web2.cfgとweb3.cfg）を作成します。その際に、web1.cfgをテンプレートとして使用し、"web1"という文字列を"web2"、"web3"にそれぞれ置き換えます。 - これまでに作成した構成ファイルを使用してゾーンを構成します。
[root@kafka]# zonecfg -z ilb-zone -f /root/ilb-zone.cfg [root@kafka]# zonecfg -z web1 -f /root/web1.cfg [root@kafka]# zonecfg -z web2 -f /root/web2.cfg [root@kafka]# zonecfg -z web3 -f /root/web3.cfg
ilb-zoneのインストールと構成
ilb-zoneゾーンをインストールします。
[root@kafka]# zoneadm -z ilb-zone install
- インストールが完了したら、ゾーンを起動してコンソールにログインします。そうすれば、Oracle Solarisインストール時と同様に、初期起動時のシステム構成を実行できます。
[root@kafka]# zoneadm -z ilb-zone boot [root@kafka]# zlogin -C ilb-zone
- System Configuration Tool（図2を参照）で[F2]キーを押します。この画面で、タイムゾーン、rootのパスワードなどの必要なシステム構成情報を指定できます。ここでもっとも重要になるのがネットワーク構成に関する情報です。
図2：システム構成：Welcome画面
Network画面で、コンピュータ名に
ilb-zoneと入力し、ネットワークを手動で構成するように選択します（図3を参照）。
図3：システム構成：Network画面
Manually Configure画面（図4を参照）で、プライベート・インタフェース
ilb_2を選択し、次の情報を入力して構成します。- IPアドレス：192.168.1.10
- ネットマスク：255.255.255.0
- ルーター（ゲートウェイ）：192.168.1.10
図4：システム構成：Manually Configure画面
ネーム・サービス（DNSまたはNIS）を構成する必要はありません。
最後に、タイムゾーンとrootのパスワードを選択して、システム構成を終了します。
注：システム構成ツールを使用して構成できるネットワーク・インタフェース・カード（NIC）は1つのみです。そのため、パブリック・インタフェース
ilb_1については、後でゾーンにログインして構成します。 ilb-zoneのシステム構成が完了したら、ログインしてこのラボに必要となる他のパッケージ（例：Apache Tomcat）を追加します。
[root@kafka]# zlogin ilb-zone [root@ilb-zone]# pkg install solaris-large-server tomcat tomcat-examples
/etc/hostsファイルの構成
大域ゾーンおよびilb-zoneゾーンの/etc/hostsファイルに、リスト3のコード内容を追加します。
::1 localhost 127.0.0.1 localhost loghost 10.5.1.6 kafka 10.5.1.10 ilb-zone 10.5.1.11 web1 10.5.1.12 web2 10.5.1.13 web3 10.5.1.50 vip 192.168.1.10 ilb-zone-priv 192.168.1.11 web1-priv 192.168.1.12 web2-priv 192.168.1.13 web3-priv
リスト3：/etc/hostsファイルの内容
rootでのSSH接続の許可
/etc/ssh/sshd_configファイルを編集し、PermitRootLogin noの行をPermitRootLogin yesに変更します。
JSPテスト・ファイルの作成
このラボでは、ロードバランサをテストするために、リクエストを処理したバックエンド・サーバーのIPアドレスを動的に出力する単純なJSPファイルを使用します。
リスト4のJSPコードを、ilb-zoneゾーンの/var/tomcat6/webapps/ROOTディレクトリ内のilbtest.jspというファイルに追加します。
注：このラボではilb-zoneゾーンがWebサーバーではなくロードバランサと
して動作するのに、なぜこのゾーンにTomcatをインストールしてJSPファイルを作成するのか疑問に思うかもしれません。その理由は、この最初に作成
したゾーンを、他のゾーンすべてのテンプレートとして使用することにあります。そうすれば、Webサーバーとして動作するゾーンの作成は、ilb-
zoneゾーンをクローニングするだけで済みます。この方法を使用する利点として、使用するディスク領域が少なくなることが挙げられますが、そのほかに大
幅な時間短縮にもつながります。既存のゾーンをクローニングして新しいゾーンを作成する操作はわずか数秒で完了するためです。
<html> <head> <title>Solaris 11 ILB Lab</title> </head> <body> <%@page import="java.net.InetAddress;" %> <TABLE width=100% border="0" cellpadding="3"> <TR> <TH align="center"><h2>Client</h2></TH> <TH align="center"><h2>Load Balancer</h2></TH> <TH align="center"><h2>Server</h2></TH> </TR> <TR> <TD align="center"> <TABLE cellpadding="2"> <TR> <TD>Client Host name:</TD> <TD><b><%= request.getRemoteHost() %></b></TD> </TR> <TR> <TD>Client IP:</TD> <TD><b><%= request.getRemoteAddr() %></b></TD> </TR> <TR> <TD>Client Port:</TD> <TD><b><%= request.getRemotePort() %></b></TD> </TR> </TABLE> </TD> <TD align="center"> <TABLE cellpadding="2"> <TR> <TD>Virtual Host name:</TD> <TD><b>vip</b></TD> </TR> <TR> <TD>Virtual IP:</TD> <TD><b>10.5.1.50</b></TD> </TR> <TR> <TD>VIP Port:</TD> <TD><b><%= request.getServerPort() %></b></TD> </TR> </TABLE> </TD> <TD align="center"> <TABLE cellpadding="2"> <TR> <TD>Server Host name:</TD> <TD><b><%= InetAddress.getLocalHost().getHostName() %></b></TD> </TR> <TR> <TD>Server IP:</TD> <TD><b><%= request.getLocalAddr() %></b></TD> </TR> <TR> <TD>Server Port:</TD> <TD><b><%= request.getLocalPort() %></b></TD> </TR> </TABLE> </TD> </TR> </TABLE> </body> </html>
リスト4：JSPファイルの内容
ilb-zoneゾーンのクローニングによるweb1、web2、web3のインストール
- 3つのWebゾーン（
web1、web2、web3）を作成します。そのために、先ほどインストールしたilb-zoneを停止してクローニングします。すでに説明したとおり、クローニングを使用することで必要なディスク領域が少なくなることに加えて、ゾーンがわずか数秒で作成されます。
[root@kafka]# zoneadm -z ilb-zone halt [root@kafka]# zoneadm -z web1 clone ilb-zone [root@kafka]# zoneadm -z web2 clone ilb-zone [root@kafka]# zoneadm -z web3 clone ilb-zone
ilb-zoneでの操作と同様に、3つのWebゾーンのそれぞれについて起動して構成を行う必要があります。そのためには、"ilb-zoneのインストールと構成"の項の手順2と手順3を、それぞれのWebゾーンに対して繰り返してください。
注：Oracle OpenWorldでこのラボを実施した際にはこのプロセスを完全に自動化し、オプションのXML形式のシステム構成ファイルを使用して、人の手を介さず に新しく作成したゾーンを構成しました。また、カスタムのマニフェスト・ファイルを使用して、人の手を介さずに他のすべてのパッケージ（Tomcatな ど）を自動的に直接インストールしました。このような自動化によって、ゾーンの作成と導入のプロセスが大幅に簡素化されます。なお、自動化については このドキュメントの範囲外です。
表4：3つのWebゾーンのネットワーク構成web1、web2、web3に対して手動でネットワーク構成を行う場合は、表4の情報を使用します。ゾーン名 コンピュータ名 web1web2web3ネットワーク・インタフェース web1_2web2_2web3_2IPアドレス 192.168.1.11 192.168.1.12 192.168.1.13 ネットマスク 255.255.255.0 255.255.255.0 255.255.255.0 ルーター（ゲートウェイ） 192.168.1.10 192.168.1.10 192.168.1.10 DNS/NIS構成 なし なし なし
ilb-zoneの2つ目のVNIC構成（パブリック・インタフェース10.5.1）
ilb-zoneゾーンを起動します（前項でクローニングのために停止されています）。
[root@kafka]# zoneadm -z ilb-zone boot
ilb-zoneのシステム構成時には、プライベートIPアドレスのみを構成しました。ilb-zoneは、（少なくともこのラボの前半では）パブリック・ネットワークとプライベート・ネットワークの両方に接続する唯一のゾーンです。そのため、次のコマンドを実行して、パブリック・インタフェースを構成する必要があります。
[root@kafka]# zlogin ilb-zone ipadm create-ip ilb_1 [root@kafka]# zlogin ilb-zone ipadm create-addr -T static -a 10.5.1.10/24 ilb_1/v4
Apache JMeterのインストールとテスト・ファイルの作成
ロードバランサをテストする別の方法として、Apache JMeterを使用します。JMeterを（オプションですが）使用する場合は、ダウンロードして大域ゾーンにインストールする必要があります。その後、リスト5のコードをILB_Test_Plan.jmxというファイルに追加します。このファイルは任意のアクセス可能ディレクトリ内に保存できます。
<?xml version="1.0" encoding="UTF-8"?> <jmeterTestPlan version="1.2" properties="2.4" jmeter="2.9 r1437961"> <hashTree> <TestPlan guiclass="TestPlanGui" testclass="TestPlan" testname="ILB Test Plan" enabled="true"> <stringProp name="TestPlan.comments"></stringProp> <boolProp name="TestPlan.functional_mode">false</boolProp> <boolProp name="TestPlan.serialize_threadgroups">false</boolProp> <elementProp name="TestPlan.user_defined_variables" elementType="Arguments" guiclass="ArgumentsPanel" testclass="Arguments" testname="User Defined Variables" enabled="true"> <collectionProp name="Arguments.arguments"/> </elementProp> <stringProp name="TestPlan.user_define_classpath"></stringProp> </TestPlan> <hashTree> <ThreadGroup guiclass="ThreadGroupGui" testclass="ThreadGroup" testname="ILB Clients" enabled="true"> <stringProp name="ThreadGroup.on_sample_error">continue</stringProp> <elementProp name="ThreadGroup.main_controller" elementType="LoopController" guiclass="LoopControlPanel" testclass="LoopController" testname="Loop Controller" enabled="true"> <boolProp name="LoopController.continue_forever">false</boolProp> <stringProp name="LoopController.loops">20</stringProp> </elementProp> <stringProp name="ThreadGroup.num_threads">1</stringProp> <stringProp name="ThreadGroup.ramp_time">10</stringProp> <longProp name="ThreadGroup.start_time">1376915632000</longProp> <longProp name="ThreadGroup.end_time">1376915632000</longProp> <boolProp name="ThreadGroup.scheduler">false</boolProp> <stringProp name="ThreadGroup.duration"></stringProp> <stringProp name="ThreadGroup.delay"></stringProp> </ThreadGroup> <hashTree> <CacheManager guiclass="CacheManagerGui" testclass="CacheManager" testname="HTTP Cache Manager" enabled="true"> <boolProp name="clearEachIteration">true</boolProp> <boolProp name="useExpires">true</boolProp> </CacheManager> <hashTree/> <ConfigTestElement guiclass="HttpDefaultsGui" testclass="ConfigTestElement" testname="HTTP Request Defaults" enabled="true"> <elementProp name="HTTPsampler.Arguments" elementType="Arguments" guiclass="HTTPArgumentsPanel" testclass="Arguments" testname="User Defined Variables" enabled="true"> <collectionProp name="Arguments.arguments"/> </elementProp> <stringProp name="HTTPSampler.domain">vip</stringProp> <stringProp name="HTTPSampler.port">80</stringProp> <stringProp name="HTTPSampler.connect_timeout"></stringProp> <stringProp name="HTTPSampler.response_timeout"></stringProp> <stringProp name="HTTPSampler.protocol"></stringProp> <stringProp name="HTTPSampler.contentEncoding"></stringProp> <stringProp name="HTTPSampler.path"></stringProp> <stringProp name="HTTPSampler.concurrentPool">4</stringProp> </ConfigTestElement> <hashTree/> <HTTPSamplerProxy guiclass="HttpTestSampleGui" testclass="HTTPSamplerProxy" testname="ILB Jsp Test Page" enabled="true"> <elementProp name="HTTPsampler.Arguments" elementType="Arguments" guiclass="HTTPArgumentsPanel" testclass="Arguments" testname="User Defined Variables" enabled="true"> <collectionProp name="Arguments.arguments"/> </elementProp> <stringProp name="HTTPSampler.domain"></stringProp> <stringProp name="HTTPSampler.port"></stringProp> <stringProp name="HTTPSampler.connect_timeout"></stringProp> <stringProp name="HTTPSampler.response_timeout"></stringProp> <stringProp name="HTTPSampler.protocol"></stringProp> <stringProp name="HTTPSampler.contentEncoding"></stringProp> <stringProp name="HTTPSampler.path">/ilbtest.jsp</stringProp> <stringProp name="HTTPSampler.method">GET</stringProp> <boolProp name="HTTPSampler.follow_redirects">true</boolProp> <boolProp name="HTTPSampler.auto_redirects">false</boolProp> <boolProp name="HTTPSampler.use_keepalive">false</boolProp> <boolProp name="HTTPSampler.DO_MULTIPART_POST">false</boolProp> <boolProp name="HTTPSampler.monitor">false</boolProp> <stringProp name="HTTPSampler.embedded_url_re"></stringProp> </HTTPSamplerProxy> <hashTree/> <ResultCollector guiclass="ViewResultsFullVisualizer" testclass="ResultCollector" testname="View Results Tree" enabled="true"> <boolProp name="ResultCollector.error_logging">false</boolProp> <objProp> <name>saveConfig</name> <value class="SampleSaveConfiguration"> <time>true</time> <latency>false</latency> <timestamp>true</timestamp> <success>true</success> <label>true</label> <code>true</code> <message>true</message> <threadName>true</threadName> <dataType>false</dataType> <encoding>false</encoding> <assertions>false</assertions> <subresults>false</subresults> <responseData>true</responseData> <samplerData>false</samplerData> <xml>false</xml> <fieldNames>false</fieldNames> <responseHeaders>true</responseHeaders> <requestHeaders>false</requestHeaders> <responseDataOnError>false</responseDataOnError> <saveAssertionResultsFailureMessage>false</saveAssertionResultsFailureMessage> <assertionsResultsToSave>0</assertionsResultsToSave> <hostname>true</hostname> </value> </objProp> <stringProp name="filename"></stringProp> </ResultCollector> <hashTree/> </hashTree> </hashTree> </hashTree> </jmeterTestPlan>
リスト5：Apache JMeterスクリプトの内容
この時点で、x86システムのラボ環境の構成が完了し、ラボを実行できるようになりました。
ラボの演習：詳細手順
ここでのラボの演習では、Oracle Solaris 11統合ロードバランサの構成と使用のプロセスについて段階的に見ていきます。すべてのコマンドはrootで実行します。
Oracle VM VirtualBoxでのOracle Solaris 11仮想マシンの起動
すでに説明したとおり、お使いのx86マシン上でOracle Solaris 11サーバーをホストするために、Oracle VM VirtualBoxを使用します。
- 「
」アイコンをクリックして、Oracle VM VirtualBoxコンソールを起動します。
図5：Oracle VM VirtualBoxコンソール
- "Oracle Solaris 11.1のインストール"の項でOracle VM VirtualBoxにOracle Solaris をインストールしたときに自動的に作成されたVMを選択し、「
」アイコンをクリックしてそのVMを起動します。
- しばらくすると、Oracle Solaris 11ログイン画面が表示されます。
図6：Oracle Solarisログイン画面
Oracle Solaris 11サーバーへのログイン
- Oracle Solaris 11のインストール時に指定した資格証明を使用してログインします。
- 上部メニュー・バーの「
」アイコンをクリックするか、デスクトップを右クリックして「Open Terminal」を選択して、ターミナル・ウィンドウを開きます。
図7：Oracle Solarisターミナル・ウィンドウ
現在の環境のチェック
この演習では現在の環境をチェックして、現在のセットアップやラボの今後の手順で使用するコマンドについて習得します。
- システムで稼働中のゾーンを表示します。
[root@kafka]# zoneadm list -civ ID NAME STATUS PATH BRAND IP 0 global running / solaris shared 1 ilb-zone running /zones/ilb-zone solaris excl 2 web2 running /zones/web2 solaris excl 4 web1 running /zones/web1 solaris excl - web3 installed /zones/web3 solaris excl
- 大域ゾーンのetherstubを表示します。
[root@kafka]# dladm show-etherstub LINK switch1 switch2
- 大域ゾーンのVNICを表示します。
[root@kafka]# dladm show-vnic LINK OVER SPEED MACADDRESS MACADDRTYPE VID gz_1 switch1 40000 2:8:20:7d:72:d7 random 0 ilb_1 switch1 40000 2:8:20:35:d0:17 random 0 ilb-zone/ilb_1 switch1 40000 2:8:20:35:d0:17 random 0 web1_1 switch1 40000 2:8:20:c0:54:3d random 0 web1/web1_1 switch1 40000 2:8:20:c0:54:3d random 0 web2_1 switch1 40000 2:8:20:d8:eb:1d random 0 web3_1 switch1 40000 2:8:20:e3:cf:ff random 0 web3/web3_1 switch1 40000 2:8:20:e3:cf:ff random 0 ilb_2 switch2 40000 2:8:20:f6:6f:b3 random 0 ilb-zone/ilb_2 switch2 40000 2:8:20:f6:6f:b3 random 0 web1_2 switch2 40000 2:8:20:68:c7:73 random 0 web1/web1_2 switch2 40000 2:8:20:68:c7:73 random 0 web2_2 switch2 40000 2:8:20:43:ea:86 random 0 web3_2 switch2 40000 2:8:20:ea:c2:10 random 0 web3/web3_2 switch2 40000 2:8:20:ea:c2:10 random 0
- 大域ゾーンのすべてのIPアドレスを表示します。
[root@kafka]# ipadm show-addr ADDROBJ TYPE STATE ADDR lo0/v4 static ok 127.0.0.1/8 net0/v4 dhcp ok 192.168.0.7/24 gz_1/v4 static ok 10.5.1.6/24 lo0/v6 static ok ::1/128 net0/v6 addrconf ok fe80::a00:27ff:fea3:34f1/10
統合ロードバランサの有効化
統合ロードバランサを使用する前にいくつかの構成や検証を行う必要があります。ここでは、そのプロセスについて順に見ていきます。
ilb-zoneにログインします。
[root@kafka]# zlogin ilb-zone [Connected to zone 'ilb-zone' pts/3] Oracle Corporation SunOS 5.11 11.1 September 2012 You have new mail. [root@ilb-zone]#
統合ロードバランサに実装されているNATコード・パスは、Oracle SolarisのIPフィルタ機能に実装されているコード・パスとは異なります。これら両方のコード・パスを同時に使用することはできません。そのため、IPフィルタ・サービスを無効化します。また、IPフォワーディングを有効化する必要があります。このラボではIPv4しか使用しませんが、IPv6を使用することもできます。
- IPフィルタを無効化してステータスをチェックします。
[root@ilb-zone]# svcadm disable ipfilter [root@ilb-zone]# svcs ipfilter STATE STIME FMRI disabled 2:39:22 svc:/network/ipfilter:default
- IPフォワーディングを有効化して新しい設定を確認します。
[root@ilb-zone]# ipadm set-prop -p forwarding=on ipv4 [root@ilb-zone]# routeadm Configuration Current Current Option Configuration System State --------------------------------------------------------------- IPv4 routing disabled disabled IPv6 routing disabled disabled IPv4 forwarding enabled enabled IPv6 forwarding disabled disabled Routing services "route:default ripng:default" Routing daemons: STATE FMRI disabled svc:/network/routing/ripng:default disabled svc:/network/routing/legacy-routing:ipv4 disabled svc:/network/routing/legacy-routing:ipv6 online svc:/network/routing/ndp:default disabled svc:/network/routing/route:default disabled svc:/network/routing/rdisc:default - 統合ロードバランサがシステムにインストールされていることを確認します。
[root@ilb-zone]# pkg info ilb Name: service/network/load-balancer/ilb Summary:IP layer 3/4 load balancer Description:The Integrated Load Balancer (ILB) provides Layer 3 and Layer 4 load-balancing capabilities.ILB intercepts incoming requests from clients, decides which back-end server should handle the request based on load-balancing rules, and then forwards the request to the selected server.ILB performs optional health checks and provides the data for the load-balancing algorithms to verify if the selected server can handle the incoming request. Category:System/Administration and Configuration State:Installed Publisher: solaris Version:0.5.11 Build Release:5.11 Branch:0.175.1.0.0.24.2 Packaging Date:September 19, 2012 06:45:40 PM Size:523.55 kB FMRI: pkg://solaris/service/network/load-balancer/ilb@0.5.11,5.11-0.175.1.0.0.24.2:20120919T184540Z - 統合ロードバランサ・サービスを有効化し、オンラインになっていることを確認します。
[root@ilb-zone]# svcs ilb STATE STIME FMRI disabled 7:38:55 svc:/network/loadbalancer/ilb:default [root@ilb-zone]# svcadm enable ilb [root@ilb-zone]# svcs ilb STATE STIME FMRI online 7:39:38 svc:/network/loadbalancer/ilb:default
Web環境の検証
- 大域ゾーンから、
web1ゾーンにログインします。
[root@kafka]# zlogin web1 [Connected to zone 'web1' pts/3] Oracle Corporation SunOS 5.11 11.1 September 2012 You have new mail. [root@web1]#
- Tomcatがオンラインであるかをチェックします。オンラインでない場合は、有効化します。
[root@web1]# svcs tomcat6 STATE STIME FMRI disabled 3:01:56 svc:/network/http:tomcat6 [root@web1]# svcadm enable tomcat6 [root@web1]# svcs tomcat6 STATE STIME FMRI online 3:02:28 svc:/network/http:tomcat6
- このWebゾーンがプライベート・ネットワーク上（192.168.1.0）にあることを確認します。
[root@web1]# ipadm show-addr ADDROBJ TYPE STATE ADDR lo0/v4 static ok 127.0.0.1/8 web1_2/v4 static ok 192.168.1.11/24 lo0/v6 static ok ::1/128 web1_2/v6 addrconf ok fe80::8:20ff:fe68:c773/10
- デフォルト・ゲートウェイが
ilb-zoneのプライベート・インタフェース（192.168.1.10）に設定されていることを確認します。この設定により、このゾーンがルーターとして動作します。
[root@web1]# netstat -rn Routing Table:IPv4 Destination Gateway Flags Ref Use Interface -------------------- -------------------- ----- ----- ---------- --------- default 192.168.1.10 UG 1 0 web1_2 127.0.0.1 127.0.0.1 UH 2 36 lo0 192.168.1.0 192.168.1.11 U 2 0 web1_2 Routing Table:IPv6 Destination/Mask Gateway Flags Ref Use If --------------------------- --------------------------- ----- --- ------- ----- ::1 ::1 UH 2 28 lo0 fe80::/10 fe80::8:20ff:fe68:c773 U 2 0 web1_2
- 手順1から手順4までを、
web2ゾーンとweb3ゾーンに対して繰り返します。
ロードバランサのNATモードでの構成とテスト
- 大域ゾーンから、
ilb-zoneにログインします。
[root@kafka]# zlogin ilb-zone [Connected to zone 'ilb-zone' pts/3] Oracle Corporation SunOS 5.11 11.1 September 2012 You have new mail. [root@ilb-zone]#
ilbadmコマンドを実行して、すべてのオプションを確認します。このラボで使用するコマンドについては太字で強調表示しています。
[root@ilb-zone]# ilbadm ilbadm: the command line is incomplete (more arguments expected) Usage: ilbadm create-rule|create-rl [-e] [-p] -i vip=value,port=value[,protocol=value] -m lbalg=value,type=value[,proxy-src=ip-range][,pmask=mask] -h hc-name=value[,hc-port=value]] [-t [conn-drain=N][,nat-timeout=N][,persist-timeout=N]] -o servergroup=value name ilbadm delete-rule|delete-rl -a | name ... ilbadm enable-rule|enable-rl [name ...] ilbadm disable-rule|disable-rl [name ...] ilbadm show-rule|show-rl [-e|-d] [-f |[-p] -o key[,key ...]][name ...] ilbadm create-servergroup|create-sg [-s server=hostspec[:portspec...]] groupname ilbadm delete-servergroup|delete-sg groupname ilbadm show-servergroup|show-sg [[-p] -o field[,field]] [name] ilbadm add-server|add-srv -s server=value[,value ...] servergroup ilbadm remove-server|remove-srv -s server=value[,value ...] servergroup ilbadm disable-server|disable-srv server ... ilbadm enable-server|enable-srv server ... ilbadm show-server|show-srv [[-p] -o field[,field...]][rulename ...] ilbadm show-healthcheck|show-hc [hc-name] ilbadm create-healthcheck|create-hc [-n] -h hc-test=value[,hc-timeout=value] [,hc-count=value][,hc-interval=value] hcname ilbadm delete-healthcheck|delete-hc name ... ilbadm show-hc-result|show-hc-res [rule-name] ilbadm export-config|export-cf [filename] ilbadm import-config|import-cf [-p] [filename] ilbadm show-statistics|show-stats [-p] -o field[,...]][-tdAvi] [-r rulename|-s servername] [interval [count]] ilbadm show-nat|show-nat [count] ilbadm show-persist|show-pt [count]
- サーバー・グループを作成し、正しく作成されたかをチェックします。
[root@ilb-zone]# ilbadm create-sg -s servers=web1-priv:8080,web2-priv:8080 web_sg_2 [root@ilb-zone]# ilbadm show-sg SGNAME SERVERID MINPORT MAXPORT IP_ADDRESS web_sg_2 _web_sg_2.0 8080 8080 192.168.1.11 web_sg_2 _web_sg_2.1 8080 8080 192.168.1.12
- ヘルス・チェックを作成します。
[root@ilb-zone]# ilbadm create-hc -h hc-timeout=3,hc-count=2,hc-interval=8,hc-test=PING web_hc
- フルNATルールをポート80で作成し、ハーフNATルールをポート81で作成します。
[root@ilb-zone]# ilbadm create-rule -e -i vip=10.5.1.50,port=80 -m lbalg=rr,type=NAT,proxy-src=192.168.1.10 -h hc-name=web_hc,hc-port=8080 -o servergroup=web_sg_2 web_rule_fn [root@ilb-zone]# ilbadm create-rule -e -i vip=10.5.1.50,port=81 -m lbalg=rr,type=HALF-NAT -h hc-name=web_hc,hc-port=8080 -o servergroup=web_sg_2 web_rule_hn
表5に、ルール作成に使用するオプションについて説明します。オプションの値では大文字小文字は区別されません。
表5：ルール作成のためのオプションオプション 説明 可能な値 -e作成されたルールを有効化する。デフォルトでは、ルールは無効になっている。 vipルールの仮想IP（VIP）アドレスを指定する。 portポート番号（またはポート範囲）を指定する。 lbalgロードバランシング・アルゴリズムを指定する。 roundrobin、hash-ip、hash-ip-port、hash-ip-viptypeネットワークのトポロジを指定する。 NAT、HALF-NAT、DSRproxy-srcフルNATのみ必須。プロキシの発信元アドレス範囲として使用するIPアドレス範囲を指定する。 IPアドレスの最大個数は10個 hc-name事前定義されたヘルス・チェック方法の名前を指定する（オプション）。 hc-portチェックするヘルス・チェック・テスト・プログラムのポートを指定する（オプション）。 キーワードの ALLまたはANY、あるいはサーバー・グループのポート範囲内にある特定のポート番号servergroup1つのサーバー・グループをターゲットとして指定する。 既存のサーバー・グループ - 作成されたオブジェクト（サーバー・グループ、ヘルス・チェック、ルール）をチェックします。
[root@ilb-zone]# ilbadm show-sg SGNAME SERVERID MINPORT MAXPORT IP_ADDRESS web_sg_2 _web_sg_2.0 8080 8080 192.168.1.11 web_sg_2 _web_sg_2.1 8080 8080 192.168.1.12 [root@ilb-zone]# ilbadm show-hc HCNAME TIMEOUT COUNT INTERVAL DEF_PING TEST web_hc 3 2 8 Y PING [root@ilb-zone]# ilbadm show-rl RULENAME STATUS LBALG TYPE PROTOCOL VIP PORT web_rule_fn E roundrobin NAT TCP 10.5.1.50 80 web_rule_hn E roundrobin HALF-NAT TCP 10.5.1.50 81
- バックエンド・サーバーが稼働中としてレポートされるかをチェックします。
[root@ilb-zone]# ilbadm show-hc-res RULENAME HCNAME SERVERID STATUS FAIL LAST NEXT RTT web_rule_fn web_hc _web_sg_2.0 alive 0 08:13:23 08:13:34 681 web_rule_fn web_hc _web_sg_2.1 alive 0 08:13:21 08:13:27 510 web_rule_hn web_hc _web_sg_2.0 alive 0 08:13:22 08:13:34 615 web_rule_hn web_hc _web_sg_2.1 alive 0 08:13:19 08:13:29 634
- クライアントがリクエストを送信するパブリック・インタフェース（
ilb_1）のMACアドレスを表示します。
[root@ilb-zone]# dladm show-vnic LINK OVER SPEED MACADDRESS MACADDRTYPE VID ilb_1 ? 40000 2:8:20:35:d0:17 random 0 ilb_2 ? 40000 2:8:20:f6:6f:b3 random 0
- ARPテーブルに、前の手順で表示されたMACアドレスに関連付けるVIPアドレスを追加します。
[root@ilb-zone]# arp -s 10.5.1.50 2:8:20:35:d0:17 pub permanent
- このVIPアドレスにpingできることを確認します。
[root@ilb-zone]# ping vip vip is alive
Firefoxによるテスト
- 上部メニュー・バーの「
」アイコンをクリックして大域ゾーンでFirefoxを起動し、セットアップした各ルール（フルNATとハーフNAT）について、それぞれ対応するURLを使用してテストします。
- フルNAT：
http://vip/ilbtest.jsp - ハーフNAT：
http://vip:81/ilbtest.jsp
- フルNAT：
- ページを何度か再ロードします。更新されるたびに、
web1とweb2が交互に応答します。
注：ページを更新中に[Shift]キーを押すと、Firefoxのキャッシュ・メカニズムが無視され、ページが強制的に再フェッチされます。
図8に、フルNATモードでのテストの実行結果を示します。このテストでは、
web2がクライアントのリクエストに応答しています。フルNATモードであるため、クライアントの実際のIPアドレス（10.5.1.6）がロードバランサのIPアドレス（192.168.1.10）に置き換わっています。
図8：フルNATモードでのテストの実行結果
図9では、テストをハーフNATモードで実行し、バックエンド・サーバーの
web1がリクエストに応答しています。クライアントのIPアドレスが異なることに注目してください。ここでは、クライアントの実際のIPアドレスがバックエンド・サーバーに送信されています。
図9：ハーフNATモードでのテストの実行結果
Apache JMeterによるテスト
- デスクトップの「
」アイコンをダブルクリックして、Apache JMeterを起動します。
図10：Apache JMeter
次に、作成しておいたJMeterテスト・ファイル
ILB_Test_Plan.jmxを使用します。このファイルでは、5つのクライアントがロードバランサに対してそれぞれ4つのリクエストを送信する状態がシミュレートされます。 - テストを開始するには、「
」アイコンをクリックして
ILB_Test_Plan.jmxファイルを開きます。
図11：Apache JMeterテストの実行
- 結果を参照するには、左側のフレームの「View Results Tree」をクリックします。次に、中央のフレームの下側にあるリスト・ボックスで「HTML」を選択し、さらに右側のフレームの「Response data」タブをクリックします。
中央のフレームに、ロードバランサに送信された20個のリクエストが表示されます。各リクエストをクリックすると、Response dataタブに、実際にそのリクエストを処理したバックエンド・サーバーが表示されます。
web1が処理したリクエスト数とweb2が処理したリクエスト数は同一になります。新しいテストを実行する前に結果をクリアするには、「
」アイコンをクリックします。
カスタマイズしたヘルス・チェック・スクリプトの作成とテスト
次のすべてのコマンドをilb-zoneゾーンで実行します。
- ヘルス・チェックに従って、バックエンド・サーバーのステータスをチェックします。両方のバックエンド・サーバーが稼働中としてレポートされます。
[root@ilb-zone]# ilbadm show-hc-res RULENAME HCNAME SERVERID STATUS FAIL LAST NEXT RTT web_rule_fn web_hc _web_sg_2.0 alive 0 12:40:14 12:40:25 4628 web_rule_fn web_hc _web_sg_2.1 alive 0 12:40:14 12:40:18 2120 web_rule_hn web_hc _web_sg_2.0 alive 0 12:40:09 12:40:18 669 web_rule_hn web_hc _web_sg_2.1 alive 0 12:40:10 12:40:21 563
web1のTomcatサーバーを停止します。
[root@ilb-zone]# ssh root@web1-priv svcadm disable tomcat6 [root@ilb-zone]# ssh root@web1-priv svcs tomcat6
- もう一度、
web1バックエンド・サーバーのステータスをチェックします。
Tomcatサーバーは停止されていますが、ヘルス・チェックではこの停止が認識されず、web1がバックエンド・サーバーの候補として維持さ れています。現在のヘルス・チェックの問題は、Tomcatをホストしているサーバーに単純なpingを実行していることです。サーバーがpingに応答する 限りは、ヘルス・チェックでこのサーバーが稼働中として認識されます。
[root@ilb-zone]# ilbadm show-hc-res RULENAME HCNAME SERVERID STATUS FAIL LAST NEXT RTT web_rule_fn web_hc _web_sg_2.0 alive 0 12:50:48 12:50:53 570 web_rule_fn web_hc _web_sg_2.1 alive 0 12:50:43 12:50:53 712 web_rule_hn web_hc _web_sg_2.0 alive 0 12:50:43 12:50:54 671 web_rule_hn web_hc _web_sg_2.1 alive 0 12:50:44 12:50:55 773
- カスタムのヘルス・チェック・スクリプトを作成します。
上記の問題を解消するには、アプリケーション認識型のヘルス・チェック・スクリプトを使用する必要があります。リスト6の内容を使用して、
/var/web_hc.shというファイルを作成します。このスクリプトは単純なcurlコマンドを使用して、Webサーバーから"<meta"という文字列で始まる応答が返されるかどうかをチェックします。応答が返される場合は、Webサーバーが稼働中であると見なすことができます。#!/bin/bash result=`curl -s http://$2:8080` if [ "${result:0:5}" = "<meta" ]; then echo 0 else echo -1 fiリスト6：カスタムのヘルス・チェック・スクリプトの内容
注：このカスタムのヘルス・チェック・スクリプトは実行可能ファイルである必要があるため、次のコマンドを実行します。
[root@ilb-zone]# chmod 755 /var/web_hc.sh
- 現在のヘルス・チェックを削除し、そのヘルス・チェックを使用するルールも削除します。現時点では、ヘルス・チェックやルールの更新がサポートされていないためです。
[root@ilb-zone]# ilbadm delete-rule web_rule_fn [root@ilb-zone]# ilbadm delete-rule web_rule_hn [root@ilb-zone]# ilbadm delete-hc web_hc
- 次に、カスタム・スクリプトを使用してヘルス・チェックを再作成します。また、ルールも再作成します。
[root@ilb-zone]# ilbadm create-hc -h hc-timeout=3,hc-count=2,hc-interval=8,hc-test=/var/web_hc.sh web_hc [root@ilb-zone]# ilbadm create-rule -e -i vip=10.5.1.50,port=80 -m lbalg=rr,type=NAT,proxy-src=192.168.1.10 -h hc-name=web_hc,hc-port=8080 -o servergroup=web_sg_2 web_rule_fn [root@ilb-zone]# ilbadm create-rule -e -i vip=10.5.1.50,port=81 -m lbalg=rr,type=HALF-NAT -h hc-name=web_hc,hc-port=8080 -o servergroup=web_sg_2 web_rule_hn
web1バックエンド・サーバーのステータスをチェックします。今回は、ヘルス・チェックが期待どおりに動作し、web1が非稼働としてレポートされます。web1にはこれ以上リクエストが送信されなくなります。[root@ilb-zone]# ilbadm show-hc-res RULENAME HCNAME SERVERID STATUS FAIL LAST NEXT RTT web_rule_fn web_hc _web_sg_2.0 dead 3 12:55:07 12:55:16 586 web_rule_fn web_hc _web_sg_2.1 alive 0 12:55:08 12:55:18 558 web_rule_hn web_hc _web_sg_2.0 dead 2 12:55:02 12:55:14 524 web_rule_hn web_hc _web_sg_2.1 alive 0 12:55:06 12:55:14 511
- Firefoxを使用してテストし、
web2のみが応答することを確認します。 web1でTomcatを再起動し、もう一度テストして、ロードバランサが再度web1にリクエストを送信することを確認します。
[root@ilb-zone]# ssh root@web1-priv svcadm enable tomcat6 [root@ilb-zone]# ssh root@web1-priv svcs tomcat6
ロードバランサのDSRモードでの構成とテスト
DSRモードでは、バックエンド・サーバーがロードバランサを経由せずに直接応答します。そのため、バックエンド・サーバーに対してクライアントへのルートを設定する必要があります。
Webゾーンの準備
説明をわかりやすくするため、この演習では単純にWebゾーンをパブリック・ネットワーク（10.5.1.0）に接続します。
- 大域ゾーンから
web1にログインします。
[root@kafka]# zlogin web1 [Connected to zone 'web1' pts/3] Oracle Corporation SunOS 5.11 11.1 September 2012 You have new mail. [root@web1]#
- 演習の前に、ゾーンが2つのIPインタフェースを持つように構成しましたが、そのうち1つのインタフェースは構成しませんでした。ここで、そのインタフェースをパブリック・ネットワークに接続するように構成します。
[root@web1]# ipadm create-ip web1_1 [root@web1]# ipadm create-addr -T static -a 10.5.1.11/24 web1_1/v4 [root@web1]# ipadm show-addr
- パブリック・ネットワークへのデフォルト・ルートを定義します。
[root@web1]# route add default 10.5.1.6 -ifp web1_1
- 次に、VIPアドレス（10.5.1.50）に送信されたリクエストに対して
web1ゾーンが応答するようにこのゾーンを構成します。
[root@web1]# ipadm create-vni vni0 [root@web1]# ipadm create-addr -T static -a 10.5.1.50/24 vni0/v4vip
- 同じ操作を
web2ゾーンとweb3ゾーンでも実行します。この際、IPインタフェース名とIPアドレスのパラメータについては、各ゾーンにあわせて変更します。
[root@web2]# ipadm create-ip web2_1 [root@web2]# ipadm create-addr -T static -a 10.5.1.12/24 web2_1/v4 [root@web2]# ipadm show-addr [root@web2]# route add default 10.5.1.6 -ifp web2_1 [root@web2]# ipadm create-vni vni0 [root@web2]# ipadm create-addr -T static -a 10.5.1.50/24 vni0/v4vip [root@web3]# ipadm create-ip web3_1 [root@web3]# ipadm create-addr -T static -a 10.5.1.13/24 web3_1/v4 [root@web3]# ipadm show-addr [root@web3]# route add default 10.5.1.6 -ifp web3_1 [root@web3]# ipadm create-vni vni0 [root@web3]# ipadm create-addr -T static -a 10.5.1.50/24 vni0/v4vip
ilb-zoneでのDSRロードバランシング・ルールの構成
- 新しいサーバー・グループの
web_sg_1を作成します。バックエンド・サーバーは前項までと同様（web1とweb2）ですが、今回はこれらのサーバーのパブリックIPアドレスを使用します。[root@ilb-zone]# ilbadm create-sg -s servers=web1,web2 web_sg_1
- DSRモードのロードバランシング・ルールをポート8080で追加します。
[root@ilb-zone]# ilbadm create-rule -e -i vip=10.5.1.50,port=8080 -m lbalg=hash-ip-port,type=DSR -h hc-name=web_hc,hc-port=8080 -o servergroup=web_sg_1 web_rule_dsr
- URL
http://vip:8080/ilbtest.jspを入力してFirefoxでDSRモードをテストします。
図12：DSRモードでのロードバランシング・ルールのテスト結果
ページを何度か更新します（[Shift]キーを押してキャッシュ動作を防ぎます）。
注：DSRモードでは、ラウンドロビン・アルゴリズムを使用しません。代わりに、"発信元IP、ポー ト・ハッシュ"アルゴリズムを使用します。そのため、更新するたびにリクエストが必ずしも別のバックエンド・サーバーに送信されるわけではありません。同 じサーバーが複数回連続で応答しているとしても、それは正常な動作です。
バックエンド・サーバー・グループへのサーバーの追加とサーバーの削除
この演習では、まずサーバー・グループに第3のWebサーバーを追加し、その後既存のサーバーを1つ削除します。
web_sg_1サーバー・グループへのweb3の追加
web_sg_1サーバー・グループにweb3を追加します。
[root@ilb-zone]# ilbadm add-server -s server=web3 web_sg_1
- URL
http://vip:8080/ilbtest.jspを入力してFirefoxでDSRモードをテストします。
ページを何度か更新すると、
web3がクライアントに応答するようになります。
図13：サーバー・グループへのサーバーの追加のテスト
web_sg_1サーバー・グループからのサーバーの削除
web_sg_1サーバー・グループからweb1を削除します。
[root@ilb-zone]# ilbadm remove-server -s server=_web_sg_1.0 web_sg_1
- URL
http://vip:8080/ilbtest.jspを入力してFirefoxでDSRモードをテストします。
web1がクライアント・リクエストに応答せず、web2とweb3のみがクライアント・リクエストに応答するようになります。
これでラボは完了ですが、統合ロードバランサについて知っておくべきことはまだ多く残っています。このテーマに関して理解を深めるには、オラクルのドキュメント（リンクは"参考資料"の項に記載）と付録Aを参照してください。
付録A：ネットワーク仮想化と統合ロードバランサの詳細
Oracle Solarisのネットワーク仮想化
統合ロードバランサは、かなり大規模な構成の一部です。Oracle Solaris 11のネットワーク仮想化は、仮想ネットワーク・カード（VNIC）、仮想スイッチ（vSwitch）、その他の高度なネットワーク・コンポーネント （ロードバランサ、ルーター、ファイアウォールなど）を含む、あらゆる物理ネットワーク・トポロジをOracle Solarisオペレーティング・システム内に構築するための機能です。
ネットワーク仮想化には、インフラストラクチャ・コストの削減、インフラストラクチャの導入の迅速化などの利点があります。これは、すべてのネットワーク構成要素がハードウェア・ベースではなくソフトウェア・ベースであるためです。
図14：ネットワーク仮想化により実現できるインフラストラクチャ統合の例
統合ロードバランサの機能
統合ロードバランサは次のことを実行します。
- SPARCシステムおよびx86システム上のOracle Solaris 11に対してレイヤー3とレイヤー4のロードバランシング機能を提供する
- クライアントから仮想IPアドレスに送信されたリクエストをインターセプトして、ロードバランシング・ルールに基づいて、リクエストを処理するバックエンド・サーバーを決定する
- 管理用のコマンドライン・インタフェースと、サード・パーティ・ベンダーが統合ロードバランサ機能を利用したソフトウェアを作成するための
libilbライブラリを提供する - IPv4とIPv6での動作モードとして、ステートレスDirect Server Return（DSR）モードとネットワーク・アドレス変換（NAT）モードをサポートする
- ヘルス・チェックによるサーバー監視機能を提供する
統合ロードバランサのおもな機能は次のとおりです。
- サービスを中断せずにサーバー・グループからサーバーを追加または削除する機能（NAT）
- セッション持続性（スティッキネス）
- 接続排出
- TCPポートおよびUDPポートのロードバランシング
- 同一のサーバー・グループ内で仮想サービス用の個別ポートを指定する機能
- 単純なポート範囲でのロードバランシング
- ポート範囲の移動と収縮
統合ロードバランサの動作モード
統合ロードバランサは、DSRモード、ハーフNATモード、フルNATモードという3つの動作モードに対応しています。
DSRモードについて図15に示します。DSRモードの利点は、NATモードよりもパフォーマンスが良く、サーバーとクライアントの間で完全な透過性を実現できることです。
DSRモードには次の欠点があります。
- バックエンド・サーバーが独自のIPアドレス（ヘルス・チェック用）と仮想IPアドレス（ロードバランシング・トラフィック用）の両方に応答する必要がある
- 接続状態を維持しないため、サーバーの追加または削除により接続が中断される
図15：DSRモード
NATモードについて図16に示します。NATモードには次の利点があります。
- ロードバランサを指定するようにデフォルト・ゲートウェイを変更することで、すべてのバックエンド・サーバーで動作する
- ロードバランサが接続状態を維持するため、接続を中断せずにサーバーの追加や削除を行うことができる
NATの欠点は、DSRよりもパフォーマンスが劣ること、およびすべてのバックエンド・サーバーでロードバランサをデフォルト・ゲートウェイとして使用する必要があることです。
図16：NATモード
統合ロードバランサのアルゴリズム
次のアルゴリズムによりトラフィック分散とサーバーの選択を制御します。
- ラウンドロビン：リクエストのサーバー・グループへの割当てがローテーション・ベースで実行される
- 発信元IPハッシュ：受信リクエストの発信元IPアドレスのハッシュ値に基づいてサーバーが選択される
- 発信元IP、ポート・ハッシュ：受信リクエストの発信元IPアドレスと発信元ポートのハッシュ値に基づいてサーバーが選択される
- 発信元IP、VIPハッシュ：受信リクエストの発信元IPアドレスと宛先IPアドレスのハッシュ値に基づいてサーバーが選択される
参考資料
Oracle Solaris 11.1 Information Libraryには、統合ロードバランサに関するドキュメントがあります。Oracle Solaris 11.1 ネットワーク・パフォーマンスの管理を検索してください。
図17：統合ロードバランサのドキュメント
その他のリソースは次のとおりです。
- ダウンロード：Oracle Solaris 11
- アクセス：Oracle Solaris 11の製品ドキュメント
- アクセス：Oracle Solaris 11に関するすべてのHow-To記事
- 学習：Oracle Solaris 11のトレーニングとサポート
- 参考：公式Oracle Solarisブログ
- Oracle Solarisのヒントと技：The ObservatoryブログとOTN Garageブログ
- Oracle Solarisのフォロー：FacebookとTwitter
著者について
Amir Javanshirは、オラクルのISV Engineeringグローバル・チームに所属するPrincipal Software Engineerであり、戦略的独立ソフトウェア・ベンダー（ISV）によるテクノロジーの導入やOracleシステム・テクノロジーの統合を支援してい ます。現在は仮想化、クラウド・コンピューティング、エンタープライズ・アーキテクチャ（EA）を専門としています。Amirは、Sun Microsystemsの買収に伴い、2010年にオラクルに入社しました。
| リビジョン1.0、2014年2月12日 |
Printer View