Oracle Solarisの統合ロードバランサを60分で導入する方法

OTNのシステム管理者/開発者コミュニティのハンズオン・ラボ

Amir Javanshir


このラボでは、Oracle Solarisの統合ロードバランサ機能をロードバランシング・システムに簡単かつ迅速に導入する方法を説明します。また、統合ロードバランサが提供する、さまざまな種類のロードバランシング・モードの使用方法についても紹介します。


2014年2月公開


この記事についてコメントする場合は、リンクをFacebookのOTN Garageのページに投稿してください。同様の記事を共有する場合は、FacebookまたはTwitterに投稿してください。みんなで議論しましょう。
目次
概要とラボの目標
前提条件
ラボの演習の概要
このラボで利用するテクノロジー
ラボの大域アーキテクチャ
システムの準備(ラボの前提条件)
ラボの演習:詳細手順
付録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つ(web1web2web3
  • ilb-zoneの構成:ラボに必要となるパッケージ(例:Apache Tomcat 6)のインストールなど
  • /etc/hostsファイルの構成
  • rootでのSSH接続の有効化
  • JSPテスト・ファイルの作成(統合ロードバランサのテストに使用)
  • ilb-zoneのクローニングによるweb1web2web3の迅速なインストール
  • ilb-zoneの2つ目のVNIC構成(パブリック・インタフェース10.5.1.1)
  • Apache JMeterのインストールとテスト・ファイルの作成(別の方法による統合ロードバランサのテストに使用)

このラボを自宅またはオフィスから実行するには、次の手順を実行します。

  1. 使用するx86マシンが次の仕様を満たしているかを確認します。

    • 8GB以上のRAM、2コアCPU
    • Oracle VM VirtualBoxでサポートされるx86オペレーティング・システム(例:x86向けOracle Solaris、Microsoft Windows、ほとんどのLinuxディストリビューション、Apple Mac OSX)
  2. "システムの準備(ラボの前提条件)"の項に示す手順を実行し、上記で説明した操作を実行してラボ環境を準備します。

ラボの演習の概要

"システムの準備(ラボの前提条件)"の項に示す手順を実行してx86マシンで環境を準備した後は、以下に示すラボの演習を行います。

  1. Oracle VM VirtualBoxでOracle Solaris 11仮想マシンを起動します
  2. Oracle Solaris 11サーバーにログインします
  3. 現在の環境をチェックします
  4. 統合ロードバランサを有効化します
  5. Web環境を検証します
  6. ロードバランサをネットワーク・アドレス変換(NAT)モードで構成してテストします
  7. カスタマイズしたヘルス・チェック・スクリプトを作成してテストします
  8. ロードバランサをDirect Server Return(DSR)モードで構成してテストします
  9. バックエンド・サーバー・グループにサーバーを追加し、そのグループからサーバーを削除します

このラボで利用するテクノロジー

ロードバランサのテストに必要となるネットワーク・トポロジやサーバー・トポロジを単純な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
    

    ゾーンのステータスは、runninginstalled(シャットダウン済み)、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のサービス管理機能は、システム・サービスやアプリケーション・サービスを管理するために従来のinitスクリプト・メカニズムを置き換える機能であり、このラボでは統合ロードバランサとTomcatのサービスを管理するために使用します。表3に、このラボで共通して使用するコマンドを示します。

    表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(有効化済み)、disabledmaintenance(オンライン状態不可)のいずれかです。

ラボの大域アーキテクチャ

図1に、ラボのアーキテクチャに関する大域ゾーンの詳細なビューを示します。この大域ゾーンは2つのネットワークと4つのゾーンをホストします。

図1

図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. リスト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. リスト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ファイルの内容

  3. 残り2つのゾーン構成ファイル(web2.cfgweb3.cfg)を作成します。その際に、web1.cfgをテンプレートとして使用し、"web1"という文字列を"web2"、"web3"にそれぞれ置き換えます。
  4. これまでに作成した構成ファイルを使用してゾーンを構成します。

    [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のインストールと構成

  1. ilb-zoneゾーンをインストールします。

    [root@kafka]# zoneadm -z ilb-zone install
    
    
  2. インストールが完了したら、ゾーンを起動してコンソールにログインします。そうすれば、Oracle Solarisインストール時と同様に、初期起動時のシステム構成を実行できます。

    [root@kafka]# zoneadm -z ilb-zone boot
    [root@kafka]# zlogin -C ilb-zone
    
  3. System Configuration Tool(図2を参照)で[F2]キーを押します。この画面で、タイムゾーン、rootのパスワードなどの必要なシステム構成情報を指定できます。ここでもっとも重要になるのがネットワーク構成に関する情報です。

    図2

    図2:システム構成:Welcome画面

    Network画面で、コンピュータ名にilb-zoneと入力し、ネットワークを手動で構成するように選択します(図3を参照)。

    図3

    図3:システム構成:Network画面

    Manually Configure画面(図4を参照)で、プライベート・インタフェースilb_2を選択し、次の情報を入力して構成します。

    • IPアドレス:192.168.1.10
    • ネットマスク:255.255.255.0
    • ルーター(ゲートウェイ):192.168.1.10
    図4

    図4:システム構成:Manually Configure画面

    ネーム・サービス(DNSまたはNIS)を構成する必要はありません。

    最後に、タイムゾーンとrootのパスワードを選択して、システム構成を終了します。

    :システム構成ツールを使用して構成できるネットワーク・インタフェース・カード(NIC)は1つのみです。そのため、パブリック・インタフェースilb_1については、後でゾーンにログインして構成します。

  4. 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ゾーンのクローニングによるweb1web2web3のインストール

  1. 3つのWebゾーン(web1web2web3)を作成します。そのために、先ほどインストールした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
    
  2. ilb-zoneでの操作と同様に、3つのWebゾーンのそれぞれについて起動して構成を行う必要があります。そのためには、"ilb-zoneのインストールと構成"の項の手順2と手順3を、それぞれのWebゾーンに対して繰り返してください。

    :Oracle OpenWorldでこのラボを実施した際にはこのプロセスを完全に自動化し、オプションのXML形式のシステム構成ファイルを使用して、人の手を介さず に新しく作成したゾーンを構成しました。また、カスタムのマニフェスト・ファイルを使用して、人の手を介さずに他のすべてのパッケージ(Tomcatな ど)を自動的に直接インストールしました。このような自動化によって、ゾーンの作成と導入のプロセスが大幅に簡素化されます。なお、自動化については このドキュメントの範囲外です。

    web1web2web3に対して手動でネットワーク構成を行う場合は、表4の情報を使用します。

    表4:3つのWebゾーンのネットワーク構成
    ゾーン名
    コンピュータ名 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のインストールとテスト・ファイルの作成

ロードバランサをテストする別の方法として、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を使用します。

  1. コンソール」アイコンをクリックして、Oracle VM VirtualBoxコンソールを起動します。

    図5

    図5:Oracle VM VirtualBoxコンソール

  2. "Oracle Solaris 11.1のインストール"の項でOracle VM VirtualBoxにOracle Solaris をインストールしたときに自動的に作成されたVMを選択し、「起動」アイコンをクリックしてそのVMを起動します。
  3. しばらくすると、Oracle Solaris 11ログイン画面が表示されます。

    図6

    図6:Oracle Solarisログイン画面

Oracle Solaris 11サーバーへのログイン

  1. Oracle Solaris 11のインストール時に指定した資格証明を使用してログインします。
  2. 上部メニュー・バーの「ターミナル」アイコンをクリックするか、デスクトップを右クリックして「Open Terminal」を選択して、ターミナル・ウィンドウを開きます。

    図7

    図7:Oracle Solarisターミナル・ウィンドウ

現在の環境のチェック

この演習では現在の環境をチェックして、現在のセットアップやラボの今後の手順で使用するコマンドについて習得します。

  1. システムで稼働中のゾーンを表示します。

    [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
    
  2. 大域ゾーンのetherstubを表示します。

    [root@kafka]# dladm show-etherstub
    LINK
    switch1
    switch2
    
  3. 大域ゾーンの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
    
  4. 大域ゾーンのすべての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
    

統合ロードバランサの有効化

統合ロードバランサを使用する前にいくつかの構成や検証を行う必要があります。ここでは、そのプロセスについて順に見ていきます。

  1. 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を使用することもできます。

  2. IPフィルタを無効化してステータスをチェックします。

    [root@ilb-zone]# svcadm disable ipfilter
    [root@ilb-zone]# svcs ipfilter 
    STATE          STIME    FMRI
    disabled        2:39:22 svc:/network/ipfilter:default
    
  3. 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
    
  4. 統合ロードバランサがシステムにインストールされていることを確認します。

    [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
    
  5. 統合ロードバランサ・サービスを有効化し、オンラインになっていることを確認します。

    [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環境の検証

  1. 大域ゾーンから、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. 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
    
  3. この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
    
  4. デフォルト・ゲートウェイが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
    
  5. 手順1から手順4までを、web2ゾーンとweb3ゾーンに対して繰り返します。

ロードバランサのNATモードでの構成とテスト

  1. 大域ゾーンから、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]#
    
  2. 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]
    
    
  3. サーバー・グループを作成し、正しく作成されたかをチェックします。

    [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
    
  4. ヘルス・チェックを作成します。

    [root@ilb-zone]# ilbadm create-hc -h hc-timeout=3,hc-count=2,hc-interval=8,hc-test=PING web_hc
    
  5. フル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 ロードバランシング・アルゴリズムを指定する。 roundrobinhash-iphash-ip-porthash-ip-vip
    type ネットワークのトポロジを指定する。 NATHALF-NATDSR
    proxy-src フルNATのみ必須。プロキシの発信元アドレス範囲として使用するIPアドレス範囲を指定する。 IPアドレスの最大個数は10個
    hc-name 事前定義されたヘルス・チェック方法の名前を指定する(オプション)。  
    hc-port チェックするヘルス・チェック・テスト・プログラムのポートを指定する(オプション)。 キーワードのALLまたはANY、あるいはサーバー・グループのポート範囲内にある特定のポート番号
    servergroup 1つのサーバー・グループをターゲットとして指定する。 既存のサーバー・グループ
  6. 作成されたオブジェクト(サーバー・グループ、ヘルス・チェック、ルール)をチェックします。

    [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
    
  7. バックエンド・サーバーが稼働中としてレポートされるかをチェックします。

    [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
    
  8. クライアントがリクエストを送信するパブリック・インタフェース(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
    
    
  9. ARPテーブルに、前の手順で表示されたMACアドレスに関連付けるVIPアドレスを追加します。

    [root@ilb-zone]# arp -s 10.5.1.50 2:8:20:35:d0:17 pub permanent
    
  10. このVIPアドレスにpingできることを確認します。

    [root@ilb-zone]# ping vip
    vip is alive
    

Firefoxによるテスト

  1. 上部メニュー・バーの「Firefox」アイコンをクリックして大域ゾーンでFirefoxを起動し、セットアップした各ルール(フルNATとハーフNAT)について、それぞれ対応するURLを使用してテストします。

    • フルNAT:http://vip/ilbtest.jsp
    • ハーフNAT:http://vip:81/ilbtest.jsp
  2. ページを何度か再ロードします。更新されるたびに、web1web2が交互に応答します。

    :ページを更新中に[Shift]キーを押すと、Firefoxのキャッシュ・メカニズムが無視され、ページが強制的に再フェッチされます。

    図8に、フルNATモードでのテストの実行結果を示します。このテストでは、web2がクライアントのリクエストに応答しています。フルNATモードであるため、クライアントの実際のIPアドレス(10.5.1.6)がロードバランサのIPアドレス(192.168.1.10)に置き換わっています。

    図8

    図8:フルNATモードでのテストの実行結果

    図9では、テストをハーフNATモードで実行し、バックエンド・サーバーのweb1がリクエストに応答しています。クライアントのIPアドレスが異なることに注目してください。ここでは、クライアントの実際のIPアドレスがバックエンド・サーバーに送信されています。

    図9

    図9:ハーフNATモードでのテストの実行結果

Apache JMeterによるテスト

  1. デスクトップの「JMeter 1」アイコンをダブルクリックして、Apache JMeterを起動します。

    図10

    図10:Apache JMeter

    次に、作成しておいたJMeterテスト・ファイルILB_Test_Plan.jmxを使用します。このファイルでは、5つのクライアントがロードバランサに対してそれぞれ4つのリクエストを送信する状態がシミュレートされます。

  2. テストを開始するには、「再生」アイコンをクリックしてILB_Test_Plan.jmxファイルを開きます。

    図11

    図11:Apache JMeterテストの実行

  3. 結果を参照するには、左側のフレームの「View Results Tree」をクリックします。次に、中央のフレームの下側にあるリスト・ボックスで「HTML」を選択し、さらに右側のフレームの「Response data」タブをクリックします。

    中央のフレームに、ロードバランサに送信された20個のリクエストが表示されます。各リクエストをクリックすると、Response dataタブに、実際にそのリクエストを処理したバックエンド・サーバーが表示されます。web1が処理したリクエスト数とweb2が処理したリクエスト数は同一になります。

    新しいテストを実行する前に結果をクリアするには、「クリア」アイコンをクリックします。

カスタマイズしたヘルス・チェック・スクリプトの作成とテスト

次のすべてのコマンドをilb-zoneゾーンで実行します。

  1. ヘルス・チェックに従って、バックエンド・サーバーのステータスをチェックします。両方のバックエンド・サーバーが稼働中としてレポートされます。

    [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
    
  2. web1のTomcatサーバーを停止します。

    [root@ilb-zone]# ssh root@web1-priv svcadm disable tomcat6
    
    [root@ilb-zone]# ssh root@web1-priv svcs tomcat6
    
  3. もう一度、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
    
  4. カスタムのヘルス・チェック・スクリプトを作成します。

    上記の問題を解消するには、アプリケーション認識型のヘルス・チェック・スクリプトを使用する必要があります。リスト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 
    
  5. 現在のヘルス・チェックを削除し、そのヘルス・チェックを使用するルールも削除します。現時点では、ヘルス・チェックやルールの更新がサポートされていないためです。

    [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
    
  6. 次に、カスタム・スクリプトを使用してヘルス・チェックを再作成します。また、ルールも再作成します。

    [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
    
  7. 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
    
    
  8. Firefoxを使用してテストし、web2のみが応答することを確認します。
  9. 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)に接続します。

  1. 大域ゾーンから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. 演習の前に、ゾーンが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
    
  3. パブリック・ネットワークへのデフォルト・ルートを定義します。

    [root@web1]# route add default 10.5.1.6 -ifp web1_1
    
    
  4. 次に、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
    
  5. 同じ操作を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ロードバランシング・ルールの構成

  1. 新しいサーバー・グループのweb_sg_1を作成します。バックエンド・サーバーは前項までと同様(web1web2)ですが、今回はこれらのサーバーのパブリックIPアドレスを使用します。
    [root@ilb-zone]# ilbadm create-sg -s servers=web1,web2 web_sg_1
    
  2. 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
    
  3. URL http://vip:8080/ilbtest.jspを入力してFirefoxでDSRモードをテストします。

    図12

    図12:DSRモードでのロードバランシング・ルールのテスト結果

    ページを何度か更新します([Shift]キーを押してキャッシュ動作を防ぎます)。

    :DSRモードでは、ラウンドロビン・アルゴリズムを使用しません。代わりに、"発信元IP、ポー ト・ハッシュ"アルゴリズムを使用します。そのため、更新するたびにリクエストが必ずしも別のバックエンド・サーバーに送信されるわけではありません。同 じサーバーが複数回連続で応答しているとしても、それは正常な動作です。

バックエンド・サーバー・グループへのサーバーの追加とサーバーの削除

この演習では、まずサーバー・グループに第3のWebサーバーを追加し、その後既存のサーバーを1つ削除します。

web_sg_1サーバー・グループへのweb3の追加

  1. web_sg_1サーバー・グループにweb3を追加します。

    [root@ilb-zone]# ilbadm add-server -s server=web3 web_sg_1
    
    
  2. URL http://vip:8080/ilbtest.jspを入力してFirefoxでDSRモードをテストします。

    ページを何度か更新すると、web3がクライアントに応答するようになります。

    図13

    図13:サーバー・グループへのサーバーの追加のテスト

web_sg_1サーバー・グループからのサーバーの削除

  1. web_sg_1サーバー・グループからweb1を削除します。

    [root@ilb-zone]# ilbadm remove-server -s server=_web_sg_1.0 web_sg_1
    
    
  2. URL http://vip:8080/ilbtest.jspを入力してFirefoxでDSRモードをテストします。

    web1がクライアント・リクエストに応答せず、web2web3のみがクライアント・リクエストに応答するようになります。

これでラボは完了ですが、統合ロードバランサについて知っておくべきことはまだ多く残っています。このテーマに関して理解を深めるには、オラクルのドキュメント(リンクは"参考資料"の項に記載)と付録Aを参照してください。

付録A:ネットワーク仮想化と統合ロードバランサの詳細

Oracle Solarisのネットワーク仮想化

統合ロードバランサは、かなり大規模な構成の一部です。Oracle Solaris 11のネットワーク仮想化は、仮想ネットワーク・カード(VNIC)、仮想スイッチ(vSwitch)、その他の高度なネットワーク・コンポーネント (ロードバランサ、ルーター、ファイアウォールなど)を含む、あらゆる物理ネットワーク・トポロジをOracle Solarisオペレーティング・システム内に構築するための機能です。

ネットワーク仮想化には、インフラストラクチャ・コストの削減、インフラストラクチャの導入の迅速化などの利点があります。これは、すべてのネットワーク構成要素がハードウェア・ベースではなくソフトウェア・ベースであるためです。

図14

図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

図15:DSRモード

NATモードについて図16に示します。NATモードには次の利点があります。

  • ロードバランサを指定するようにデフォルト・ゲートウェイを変更することで、すべてのバックエンド・サーバーで動作する
  • ロードバランサが接続状態を維持するため、接続を中断せずにサーバーの追加や削除を行うことができる

NATの欠点は、DSRよりもパフォーマンスが劣ること、およびすべてのバックエンド・サーバーでロードバランサをデフォルト・ゲートウェイとして使用する必要があることです。

図16

図16:NATモード

統合ロードバランサのアルゴリズム

次のアルゴリズムによりトラフィック分散とサーバーの選択を制御します。

  • ラウンドロビン:リクエストのサーバー・グループへの割当てがローテーション・ベースで実行される
  • 発信元IPハッシュ:受信リクエストの発信元IPアドレスのハッシュ値に基づいてサーバーが選択される
  • 発信元IP、ポート・ハッシュ:受信リクエストの発信元IPアドレスと発信元ポートのハッシュ値に基づいてサーバーが選択される
  • 発信元IP、VIPハッシュ:受信リクエストの発信元IPアドレスと宛先IPアドレスのハッシュ値に基づいてサーバーが選択される

参考資料

Oracle Solaris 11.1 Information Libraryには、統合ロードバランサに関するドキュメントがあります。Oracle Solaris 11.1 ネットワーク・パフォーマンスの管理を検索してください。

図17

図17:統合ロードバランサのドキュメント

その他のリソースは次のとおりです。

著者について

Amir Javanshirは、オラクルのISV Engineeringグローバル・チームに所属するPrincipal Software Engineerであり、戦略的独立ソフトウェア・ベンダー(ISV)によるテクノロジーの導入やOracleシステム・テクノロジーの統合を支援してい ます。現在は仮想化、クラウド・コンピューティング、エンタープライズ・アーキテクチャ(EA)を専門としています。Amirは、Sun Microsystemsの買収に伴い、2010年にオラクルに入社しました。

リビジョン1.0、2014年2月12日

フォロー先:
ブログ | Facebook | Twitter | YouTube