一瞬でのバックアップを実現するSolaris ZFSOpenSolarisで始めるブログサーバ構築(4)(4/4 ページ)

» 2008年04月08日 00時00分 公開
[川井聡サン・マイクロシステムズ株式会社]
前のページへ 1|2|3|4       

ゾーンのプロビジョニング

 前回は、Solarisコンテナを使って、サービスごとに異なるホスト環境を構築し、その中で各サービスを実行することでセキュリティを高める方法を紹介しました。今回は、ゾーン環境がセキュリティの面だけでなく、プロビジョニングにも役立つことを紹介しようと思います。当然、ZFSとも連携させます。

 例えば、前回の手順で構築したブログサイトの人気が高まり、アクセス数が伸びた結果、多くのユーザーに満足のいくサービスが提供できなくなってきたとしましょう。このような場合、図3のように複数のブログサーバを用意し、ロードバランサなどを利用して、各ブログサーバにネットワークトラフィックを均等に分配するといった手段が考えられます。

OpenSolaris 図3 ゾーンを活用した負荷分散

 ゾーンとZFSを使用していれば、このような既存の環境を、容易に、しかも迅速に図3のような構成に移行することができます。

 それでは、blog_zoneをマスターゾーンとして複製する方法を紹介しましょう(ただしblog_zoneは、IPインスタンスを使ったゾーン環境になっています。従って、実際にこの構成で構築するには、複数のネットワークインターフェイスを持ったマシンを用意したり、別のホストを利用する必要があるかもしれません)。

 すでに紹介したとおり、ゾーン環境はZFSファイルシステム上に構築されています。続いて、既存のゾーン環境の構成をマスターとして抜き出すために、blog_zoneの構成情報をエクスポートします。

# zonecfg -z blog_zone export -f /export/zones/blog_zone_master

 このマスターの構成情報を基に、新規のゾーンの構成を作成します。

# zonecfg -z blog_zone2 -f /export/zones/blog_zone_master

 次に、zonepathやネットワークインターフェイスなど、既存のゾーンと重複してはいけない部分を編集します。ここでは、zonepathに/pexport/zones/bolog_zone2を指定してください。

# zonecfg -z blog_zone2
zonecfg:blog_zone2> set zonepath=/export/zones/blog_zone2
zonecfg:blog_zone2> commit
zonecfg:blog_zone2> exit
#

 これでゾーン複製の準備ができたので、zoneadmのcloneサブコマンドを使用して、blog_zoneを複製します。cloneは、オリジナルのゾーンが停止状態でないと実行できませんので、いったん停止してから実行します。

 UFSなどのファイルシステム上に構築されたゾーン環境を複製(クローン化)する場合、ファイルのコピーには多少の時間を要します。しかし、上記のようにZFS上に構築されたゾーン環境から同じストレージプール内にクローン化する場合、このコマンドの実行は一瞬で終了します。

# zoneadm -z blog_zone halt
# zoneadm -z blog_zone2 clone blog_zone
Cloning snapshot mypool/zones/new@SUNWzone1
Instead of copying, a ZFS clone has been created for this zone.
#

 zonadmコマンドは、同一ストレージプール内でクローン化を行う場合、ファイルをコピーする代わりに、オリジナルのZFSスナップショットから作成したZFSクローンを利用します。このため、処理に時間はかかりません。

 複製が終了したら、新しいblog_zone2をブートし、blog_zoneのときと同じようにzlogin -Cコマンドを使って、システムのセットアップを行うだけです。これでゾーンの複製は終了です。同様の方法で、マスターとなるゾーンから必要なだけクローンを作成してください。容易にApache Roller環境を複製することができます。

 なお、ZFSのクローンについて少し補足しておきます。ZFSクローンは、ZFSスナップショットから作成されるファイルシステムであり、スナップショットが読み出ししかできないのに対して、クローンでは書き込みもできるという点で異なります。また、スナップショットからクローン化されたディスク領域はスナップショットと共有されているので、データ変更分以外のディスクを消費しないという点も大きなメリットです。

 ここでzfs listを実行してみましょう。

# zfs list
NAME                            USED AVAIL REFER MOUNTPOINT
mypool                         1.79G 17.8G   19K /mypool
mypool/zones                   1.79G 17.8G 23.5K /export/zones
mypool/zones/blog_zone         1.10G 17.8G 1.10G /export/zones/blog_zone
mypool/zones/db_zone           1.46G 16.3G 1.46G /export/zones/db_zone
mypool/zones/blog_zone@SUNWzone1 130K    - 1.10G -
mypool/zones/blog_zone2         230K 17.8G 1.10G /export/zones/blog_zone2

 mypool/zones/blog_zone@SUNWzone1というスナップショットが作成されていることが分かります。zoneadm cloneの実行により、自動的にSUNWzoneXというスナップショットが作成され、このスナップショットのクローンとしてmypool/zones/blog_zone2が生成されます。

 ここで、USEDのカラムに注目してください。blog_zone2はblog_zoneのクローンなので、ほとんどディスクを消費していません。ゾーンのブート後に行ったホスト固有のシステム設定の分だけが使用されていることが分かります。

 このように、ZFSを使用することで、データの管理が簡単になるだけでなく、リソースを無駄なく使用し、効率よくサービスを拡張できることがお分かりいただけたと思います(なお本記事では、ロードバランサの設定については割愛します)。

エンディアンに中立なデータ構造

  最後にもう一つ、ZFSの便利な点を紹介します。ZFSは、マシンのエンディアン(バイトオーダー)に依存しません

 通常、バイトオーダーの異なるコンピュータ間でデータをやりとりする場合、相手のバイトオーダーを考慮しなければ、値が異なってしまいます。しかし、ZFSを使用すれば、ビッグエンディアンであるSPARCマシン上で構築したストレージプールを、リトルエンディアンであるx86/x64アーキテクチャのマシン上に持っていき、そのまま使用することができます。

 これは、データを書き込む際にはマシンのネイティブエンディアン形式を使用してビットをセットし、読み出す際にはマシンのネイティブエンディアンと書き込まれているブロックのエンディアンが異なる場合にバイトスワップするという方法で実現されています。

 異なるシステムに付け替える手順は簡単です。zpool exportコマンドで切り離した後にストレージプールを取り外し、別のマシンに持っていき、接続した後にzfs importコマンドでインポートするだけです。

sparc# zpool export mypool
x86# zpool import mypool

 ほかにも紹介したいことがたくさんあるのですが、残念ながら紙幅が尽きました。さらなる詳細については、マニュアル「Solaris ZFS 管理ガイド」やSDCのコンテンツを参照してください。

 次回は、クラスタリングを用いて可用性を高める方法を紹介する予定です。

OpenSolarisに関する技術情報の多くは、Sunのブログサイト(http://blogs.sun.com)に提供されています。このサイトには、OpenSolarisに関する技術者・開発者たちによるダイレクトな情報が提供されています。また、SDC(http://sdc.sun.co.jp/portal/index.html)Sun Product用のドキュメントサイト(http://docs.sun.com)には、OpenSolarisやSolaris 10のインストール方法をはじめとするドキュメントや技術情報が掲載されています。これらの情報もぜひ活用してください。



前のページへ 1|2|3|4       

Copyright © ITmedia, Inc. All Rights Reserved.

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。