2014年2月公開
|
このドキュメントでは、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)アプリケーションが稼働しています。
実際のラボを開始する前に、次の操作を実行してラボ環境を準備する必要があります。
gz_1
)の構成ilb-zone
)と、Webサーバーをホストするためのゾーン3つ(web1
、web2
、web3
)ilb-zone
の構成:ラボに必要となるパッケージ(例:Apache Tomcat 6)のインストールなど/etc/hosts
ファイルの構成root
でのSSH接続の有効化ilb-zone
のクローニングによるweb1
、web2
、web3
の迅速なインストールilb-zone
の2つ目のVNIC構成(パブリック・インタフェース10.5.1.1)このラボを自宅またはオフィスから実行するには、次の手順を実行します。
"システムの準備(ラボの前提条件)"の項に示す手順を実行してx86マシンで環境を準備した後は、以下に示すラボの演習を行います。
ロードバランサのテストに必要となるネットワーク・トポロジやサーバー・トポロジを単純なx86マシン上でエミュレートするために、このラボでは次のOracle Solaris 11組込みテクノロジーを利用します。
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のサービス管理機能は、システム・サービスやアプリケーション・サービスを管理するために従来の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 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がインストールされます。グラフィカル環境は統合ロードバランサを使用するための前提条件ではありませんが、このラボではインストールすることを お勧めします。
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(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
/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
ファイルの内容
/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
ファイルの内容
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
[root@kafka]# zoneadm -z ilb-zone boot [root@kafka]# zlogin -C ilb-zone
図2:システム構成:Welcome画面
Network画面で、コンピュータ名にilb-zone
と入力し、ネットワークを手動で構成するように選択します(図3を参照)。
図3:システム構成:Network画面
Manually Configure画面(図4を参照)で、プライベート・インタフェースilb_2
を選択し、次の情報を入力して構成します。
図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
に変更します。
このラボでは、ロードバランサをテストするために、リクエストを処理したバックエンド・サーバーの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
のインストール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な ど)を自動的に直接インストールしました。このような自動化によって、ゾーンの作成と導入のプロセスが大幅に簡素化されます。なお、自動化については このドキュメントの範囲外です。
web1
、web2
、web3
に対して手動でネットワーク構成を行う場合は、表4の情報を使用します。
ゾーン名 | |||
---|---|---|---|
コンピュータ名 | web1 |
web2 |
web3 |
ネットワーク・インタフェース | web1_2 |
web2_2 |
web3_2 |
IPアドレス | 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を使用します。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
で実行します。
すでに説明したとおり、お使いのx86マシン上でOracle Solaris 11サーバーをホストするために、Oracle VM VirtualBoxを使用します。
図5:Oracle VM VirtualBoxコンソール
図6:Oracle Solarisログイン画面
図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
[root@kafka]# dladm show-etherstub LINK switch1 switch2
[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
[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を使用することもできます。
[root@ilb-zone]# svcadm disable ipfilter [root@ilb-zone]# svcs ipfilter STATE STIME FMRI disabled 2:39:22 svc:/network/ipfilter:default
[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
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]#
[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
[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
web2
ゾーンとweb3
ゾーンに対して繰り返します。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
[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-vip |
type |
ネットワークのトポロジを指定する。 | NAT 、HALF-NAT 、DSR |
proxy-src |
フルNATのみ必須。プロキシの発信元アドレス範囲として使用するIPアドレス範囲を指定する。 | IPアドレスの最大個数は10個 |
hc-name |
事前定義されたヘルス・チェック方法の名前を指定する(オプション)。 | |
hc-port |
チェックするヘルス・チェック・テスト・プログラムのポートを指定する(オプション)。 | キーワードのALL またはANY 、あるいはサーバー・グループのポート範囲内にある特定のポート番号 |
servergroup |
1つのサーバー・グループをターゲットとして指定する。 | 既存のサーバー・グループ |
[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
[root@ilb-zone]# arp -s 10.5.1.50 2:8:20:35:d0:17 pub permanent
[root@ilb-zone]# ping vip vip is alive
http://vip/ilbtest.jsp
http://vip:81/ilbtest.jsp
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モードでのテストの実行結果
図10:Apache JMeter
次に、作成しておいたJMeterテスト・ファイルILB_Test_Plan.jmx
を使用します。このファイルでは、5つのクライアントがロードバランサに対してそれぞれ4つのリクエストを送信する状態がシミュレートされます。
ILB_Test_Plan.jmx
ファイルを開きます。図11:Apache JMeterテストの実行
中央のフレームに、ロードバランサに送信された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
web2
のみが応答することを確認します。web1
でTomcatを再起動し、もう一度テストして、ロードバランサが再度web1
にリクエストを送信することを確認します。[root@ilb-zone]# ssh root@web1-priv svcadm enable tomcat6 [root@ilb-zone]# ssh root@web1-priv svcs tomcat6
DSRモードでは、バックエンド・サーバーがロードバランサを経由せずに直接応答します。そのため、バックエンド・サーバーに対してクライアントへのルートを設定する必要があります。
説明をわかりやすくするため、この演習では単純に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]#
[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
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
[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
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
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
http://vip:8080/ilbtest.jsp
を入力してFirefoxでDSRモードをテストします。 web1
がクライアント・リクエストに応答せず、web2
とweb3
のみがクライアント・リクエストに応答するようになります。
これでラボは完了ですが、統合ロードバランサについて知っておくべきことはまだ多く残っています。このテーマに関して理解を深めるには、オラクルのドキュメント(リンクは"参考資料"の項に記載)と付録Aを参照してください。
統合ロードバランサは、かなり大規模な構成の一部です。Oracle Solaris 11のネットワーク仮想化は、仮想ネットワーク・カード(VNIC)、仮想スイッチ(vSwitch)、その他の高度なネットワーク・コンポーネント (ロードバランサ、ルーター、ファイアウォールなど)を含む、あらゆる物理ネットワーク・トポロジをOracle Solarisオペレーティング・システム内に構築するための機能です。
ネットワーク仮想化には、インフラストラクチャ・コストの削減、インフラストラクチャの導入の迅速化などの利点があります。これは、すべてのネットワーク構成要素がハードウェア・ベースではなくソフトウェア・ベースであるためです。
図14:ネットワーク仮想化により実現できるインフラストラクチャ統合の例
統合ロードバランサは次のことを実行します。
libilb
ライブラリを提供する統合ロードバランサのおもな機能は次のとおりです。
統合ロードバランサは、DSRモード、ハーフNATモード、フルNATモードという3つの動作モードに対応しています。
DSRモードについて図15に示します。DSRモードの利点は、NATモードよりもパフォーマンスが良く、サーバーとクライアントの間で完全な透過性を実現できることです。
DSRモードには次の欠点があります。
図15:DSRモード
NATモードについて図16に示します。NATモードには次の利点があります。
NATの欠点は、DSRよりもパフォーマンスが劣ること、およびすべてのバックエンド・サーバーでロードバランサをデフォルト・ゲートウェイとして使用する必要があることです。
図16:NATモード
次のアルゴリズムによりトラフィック分散とサーバーの選択を制御します。
Oracle Solaris 11.1 Information Libraryには、統合ロードバランサに関するドキュメントがあります。Oracle Solaris 11.1 ネットワーク・パフォーマンスの管理を検索してください。
図17:統合ロードバランサのドキュメント
その他のリソースは次のとおりです。
Amir Javanshirは、オラクルのISV Engineeringグローバル・チームに所属するPrincipal Software Engineerであり、戦略的独立ソフトウェア・ベンダー(ISV)によるテクノロジーの導入やOracleシステム・テクノロジーの統合を支援してい ます。現在は仮想化、クラウド・コンピューティング、エンタープライズ・アーキテクチャ(EA)を専門としています。Amirは、Sun Microsystemsの買収に伴い、2010年にオラクルに入社しました。
リビジョン1.0、2014年2月12日 |