nkjmkzk.net

powered by Kazuki Nakajima

Archive for the ‘zfs’ tag

Oracle Sun Technology Updateに行ってきました

昨日、8/19に目黒雅叙園にてOracle Sun Technology Updateが開催されました。3Track x 3でセッションが開催され、各セッションは大きく分けてJavaとSolarisを扱う内容でした。その中でも最新情報の提供を行うようなセッションと、DTraceチュートリアルのような具体的な技術話とかなり幅広い内容が提供されたように思います。

僕はSolaris Trackに一日中入り浸っていましたので簡単にレポートしたいと思います。

B-1 Solaris開発環境のご紹介

DSC_0015
大曽根 明さん

Mr.Solarisの異名をとる大曽根さんはOracle Solaris Operating Systemについてこれまでを振り返り、今後のロードマップを紹介しました。

次に新しいH/Wサポートメニュー「Premier Support for Systems」についても紹介しました。Premier Support for SystemsはH/Wの保守プログラムでありながら、同時にOracle Solaris, Oracle Enterprise Linux, Oracle VMが使いたい放題になることを説明。

また、ZFS, Containerについて概要を紹介し、特にZFSについては「非クラスター型で現在最強のファイルシステムだろう」と指摘。そしてSun Studioを使ったデモを披露する等幅広い内容をカバー。

B-2 開発環境でのSolaris ZFS

DSC_0032
野崎 宏明さん

先のセッションで「最強」とされたZFSについて、こちらの@IT記事でもわかりやすい解説をされてる野崎さんからプレゼン。End-to-Endの整合性チェック機構、CoW等ZFSの根幹を成す内部アーキテクチャについて説明。

B-3 DTrace活用術

ZFSと並ぶSolarisの代表的な機構であるDTraceについて藤田さん、本間さんからプレゼン。
DSC_0038
藤田 勇治さん

藤田さんはDTraceが何であるのか、どういった情報がとれて、どのように活用できるのかという全体象を事例を交えて紹介。端的で軽快なトークでDTraceのメリットを限られた時間ながら非常にわかり易く説明されていました。カーネルを特別なビルドオプション付きでコンパイルしたりする必要がない特別な起動オプションもいらないその場でほしい情報を動的に出力させることができる、ということがズドンと理解できる濃密な時間でした。

DSC_0042
本間 大輔さん

本間さんはDTraceのHow toを紹介。「こういう情報をとりたいときは・・」という切り口で実際のスクリプトを見せて解説しながら出力結果を確認していくという実践的なセッション。持ち時間は30分足らずであるにもかかわらずDTraceのサンプルスクリプトを含む実用的な資料を120枚作成するというパッション。事実、この資料はこれからDTraceを使ってみたい!という人にはバイブルでしょう。必見です。バイブルのダウンロードはこちら。
DTrace活用術

特別企画トークライブ:「2020年に向けてITエンジニアはどうやって生き残るか?」

DSC_0044
ウルシステムズ(株)の漆原様、(株)Preferred Infrastureの太田様、クックパッド(株)大野様によるパネルディスカッション。モデレータは弊社の伊藤さん。
はっきり言って、かなり面白いディスカッションでした。何が面白かったかというと、みなさんそれぞれ強い信念をお持ちで、その信念が名言となって出てくるとことです。僕が特に印象に残った名言を下記に挙げさせていただきました。

  • 製品や技術にコミットするかどうかは開発者に会って決める。信頼できるヤツならいける。(漆原様)
  • めちゃ難しいプロジェクトを社員に任せる。できたら、目一杯給料を払ってあげる。それを繰り返す。(漆原様)
  • 今日欲しいと言われたものは明日提供できなければそこに感動はない。(大野様)
  • やりたいことをやる。やりたくないことはやらない。やりたいことを宣言する。(大野様)

それぞれ深い思考や経験を元にしたパワフルな持論です。共感する部分や「なるほど〜」な気付きもあり、非常に有益な時間だったと思います。

個人的には今後SunのテクノロジーとOracleのテクノロジーの合体技をより具体的に訴求するようなセミナーをやりたいなと思っています。Solaris, ASM, ZFS、このあたりがキーワードになるでしょう。楽しくなりそうです。

without comments

Written by 中嶋 一樹

8月 20th, 2010 at 6:29 pm

Posted in Uncategorized

Tagged with , ,

ZFSでtpgtを使って接続先ポートを限定する

ZFSはご存知の通りzvolを作成してiSCSIでエクスポートすることができます。

とある環境でZFSサーバは複数のネットワークセグメントに接続されており、当然それぞれのセグメントでIPアドレスが割り振られているとします(多くの環境ではそのようになっているでしょう)。そのときzfs set shareiscsi=on [ZVOL]としてzvolをエクスポートすると、すべてのセグメントでzvolがエクスポートされてしまいます。

名称未設定.001

iSCSIセグメントからDiscoveryしにいったiSCSIクライアントにも1zvolにつき複数のターゲットが見えてしまいます。これは多くの環境で望ましくない挙動でしょう。本来はzvolがエクスポートされるのはiSCSIのストレージセグメントだけに留めておきたいはずです。

zvolがエクスポートされるセグメントを設定するにはtpgt (Target Port Group Tag)が有効です。tpgtを使えば下図のようにzvolをエクスポートするセグメントを限定できます。

名称未設定.002

設定手順です。

まずtpgtを作成します。tpgtの名前には1〜65535の任意の数字を割り当てます。

[root@~]# iscsitadm create tpgt 1

作成したtpgtにzvolをエクスポートしたいIPアドレスを追加します。

[root@~]# iscsitadm modify tpgt -i 10.2.0.1 1

zvolのアクセス制御リストとして作成したtpgtを設定します。

[root@~]# iscsitadm modify target -p 1 [TARGET]

これでtpgt 1に参加している10.2.0.1だけがzvolのエクスポート対象となります。

without comments

Written by 中嶋 一樹

6月 28th, 2010 at 3:03 pm

Posted in Uncategorized

Tagged with ,

Deduplication, 圧縮, スナップショットはどう違うのか?

前のエントリで予告したDeduplication, 圧縮, スナップショットの違いについて簡潔にまとめておきます。

Deduplicationと圧縮

例えば10Gbyteの仮想マシンイメージをgzipのようなアルゴリズムで圧縮した場合、10Gbyteのイメージにどれだけ空きスペースが含まれているかによりますが、もし空きスペースがほとんどなければあまり大きな圧縮効果は望めないでしょう。逆にもし10Gbyte中の4Gbyteが空きスペースであったなら、その部分はほとんど圧縮されるので最悪でも6Gbyte程度までは圧縮できるでしょう。ただしこの仮想マシンを10個クローンしたらどうでしょうか。ストレージは6Gbyte x 10 = 60Gbyteの容量を消費してしまいます。実際は同じデータであるにも関わらず、です。このストレージでDeduplication(重複排除)が有効であればどうでしょうか。10Gbyteの仮想マシンイメージを10個作成しても消費する容量は10Gbyteです。先ほどのgzip圧縮と比較するとトータルでこ重複排除の方が容量を節約できています。

ただしここで注意したいのはケースバイケースだということです。前述の仮想マシンイメージのような例は、特にDeduplicationが効果を発揮する環境です。Jeff Bonwick氏も自身のBlogエントリで度々仮想マシンイメージの例を引き合いに出しています。

そしてDeduplicationと圧縮は排他的な関係ではありません。補完し得る関係です。前述のシチューエーションをそれぞれのパターンでまとめてみます。

命題:10Gbyte (空き容量4Gbyte)の仮想マシンイメージを10個クローンする

gzip圧縮のみ

10Gbyteを圧縮して6Gbyteに。6Gbyteを10個クローンして最終的に60Gbyte消費

Deduplicationのみ

10Gbyteを10個クローンするが、10個のクローンはすべてのブロックが一致するはずなので新しいデータ領域は確保されない。最終的に10Gbyte消費

gzip圧縮 + Deduplication

まず10Gbyteを圧縮して6Gbyteに。それを10個クローンするがすべてのブロックが一致するはずなので新しいデータ領域は確保されない。最終的に6Gbyte消費

実際にテストしていませんが、理論的には上記のようになり得ます。要件によっては圧縮とDeduplicationを組み合わせたら最もディスク領域を節約できるケースがあることがわかります。

Deduplicationとスナップショット

Deduplicationとスナップショットは非常に近しい技術だと思います。どちらのコンセプトも「重複するデータの実体は一つしか保持しない」がベースになっています。僕は大きな違いは次の2点だと思っています。

主従関係

スナップショットでは主従関係が存在します。ほとんどのスナップショットの実装ではマスターのイメージがあり、スナップショットとはそのイメージのスレーブとして作成されます。なのでマスターとスレーブは対等な関係ではありません。スレーブは維持するけれどもマスターを削除する、という操作は行うことができません。ZFSのスナップショットでも同様です。

*ZFSでマスターを削除するにはマスターとスレーブの主従関係を逆転させるという選択肢はあります

これはDeduplicationの仕様とは明らかにことなります。前述の仮想マシンイメージの例で言えば、Deduplicationを使って10個の仮想マシンをクローンしてもそのオリジナルとクローンとの間には主従関係はありません。あるのはディスクに格納されているブロックの実体と、それを参照しているカウンタです。どの仮想マシンを削除するのも自由です。例えば大本の仮想マシンイメージを削除するにしてもそのブロックへの参照カウンタが一つ減るだけでスナップショットのように依存関係には縛られません。

コピー速度

ほとんどの実装においてスナップショットの作成は一瞬です。オリジナルイメージのスキャンが行われることもなければ新たなブロックが確保されてデータがコピーされることもありません。これはそもそもストレージ(あるいはボリュームマネージャ)にコピーではなくスナップショットという命令が明示されているからロジックを分けることができます。これはDeduplicationとは異なります。Decuplicationではコピー(あるいはクローン)する際、ユーザからの特別な命令はありません。通常通りファイルのコピーが命ぜられ、ストレージ側は粛々とファイルの構成要素となっているブロックについて一つ一つハッシュをチェックし、重複判定を行って重複していればデータのコピーは行わず参照カウンタをインクリメントして次のブロックに処理を移します。なのでスナップショットのようにどれだけコピー元のサイズが大きくても一瞬で処理を完了させれるような仕組みではなく、サイズが大きければ大きい程、例えば最終的にデータは複製しないにしろ、コピー処理には時間がかかるのが道理です。

ということでそれぞれの技術には得意不得意があり、ケースバイケースで適切な技術を選ぶ必要があると考えられます。

僕が開発しているovmzfsというツールの現在の仕様は、ZFSのスナップショット/クローンを使用して仮想マシンを高速に作成し、圧縮を使用してテンプレートのサイズ削減を行っています。これは検証環境では作業の高速化とストレージリソースの削減に大きく寄与しますが、今回Deduplicationが出てきたことで実装を少し見直さなければと思っています。現在の仕様では仮想マシンはテンプレートをスナップショット/クローンすることで作成しているため、高速に作成できるものの元のテンプレートと依存関係が発生します。すぐに問題とはなりませんが、より複雑な運用、大規模な環境ではもしかすると問題がでてくる可能性もなきにしもあらずです。まだDeduplicationを含むベストプラクティスを確立するには至っていませんが、最終的には適材適所でZFSのDeduplication、圧縮、スナップショットを採用してユーザからは透過的にストレージを最適に利用するツールにできればと思っています。

with one comment

Written by 中嶋 一樹

11月 8th, 2009 at 2:33 pm

Posted in Uncategorized

Tagged with , , , ,

ZFSのDeduplication実装について

ZFSのリードデベロッパー、Jeff Bonwick氏は11月2日に投稿した「ZFS Deduplication」のBlogエントリでZFSに重複排除機能を実装したことをアナウンスしました。重複排除はストレージ界隈では熱い注目を集めている機能で、オープンソースであるZFSがそれを搭載したということで多くのエンジニアの好奇心を刺激しています。重複排除技術に関しては最近ではNetAppとEMCが、DataDomainという重複排除機能をウリにしたストレージを販売する会社の買収合戦を繰り広げたことが記憶に新しいところです。

*結局DataDomainはEMCに買収されています

ということで各ストレージベンダーはこの技術を自社製品に実装し、差別化を計ることに躍起になっていると見受けられます。

ほとんどBonwick氏のBlogエントリの訳みたいになってしまいますが、このZFSの重複排除機能について少し私見を交えてまとめておきます。まず、ZFSの重複排除実装について重要な仕様を2つ列挙しておきます。

  • 重複判定単位:ブロックレベル
  • 重複判定時期:リアルタイム

この2点について以下で論じていきます。

この重複排除技術、何がいいのかというとつまるところ必要なストレージ容量を削減できる、という点です。例えばあるファイルの容量が100Mbyteであったとるすると、そのファイルを2つ格納すれば通常は必要ストレージ容量は200Mybteです。これに重複排除機構を適用すると、これまで別々のディスク領域を確保して格納されていた2つのファイルは同じデータであるとストレージが認識し、実体を一つにまとめることで必要ストレージ容量は100Mybteに圧縮できます。ただしこれは単純な「ファイルレベル」の重複排除であり、他にはブロックレベルの重複排除、バイトレベルの重複排除があります。ファイルレベルの重複排除ではストレージ側が同じファイルであると認識すればディスク上に格納される実体は一つにすることで必要容量をセーブすることができます。しかしファイルレベルの場合たとえ1byteでも違うと別のファイルと見なされるので、一方のファイルを少し編集してしまうと途端に必要ストレージ容量は100Mbyte -> 200Mbyteに膨らんでしまいます。ブロックレベルであればあくまでもブロック単位での重複判定となるため、編集した部分のブロックだけを別途確保すればこと足ります。ただし、ブロックレベルではこの重複判定をファイルレベルとは比較にならない程行う必要がでてくるので、その分処理性能に関してオーバーヘッドが見込まれます。ブロックレベルの重複排除は処理に幾分かオーバーヘッドが見込まれるものの、結果としてファイルレベルの重複排除よりも多くの容量をセーブできます。

そしてZFSの重複排除機能はブロックレベルで実装されています。これはストレージ側で実装する重複排除としてはブロックレベルが最も効率的ということと、ZFSというファイルシステムの設計思想として、より現代的なマルチコアで同時実行性能の高いH/Wや、そのマルチコアをうまく扱うことができるマルチスレッドOSを稼働環境の前提としていることが設計根拠に挙げられます。つまりCPUをより積極的に利用すべき、というスタンスです。

もう一つ、Deduplication機構の実装として注目すべきなのはいつ重複判定を行うのか、です。これはデータをディスクに書き出す前に行うリアルタイム型と、定期的にディスク上のデータをスキャンして一括して重複判定を行うバッチ型があります。ZFSでは前者のリアルタイム型を採用しています。当然リアルタイムに重複判定処理を行うとディスクI/Oのレスポンスに対するインパクトが懸念されます。これがどの程度のインパクトになるかは環境に大きく依存するところなので一概には言えないものの次のように考えることができます。現在のI/Aサーバでは頭でっかち(CPU性能:高)尻つぼみ(Disk I/O性能:低)なバランスとなっています。性能に余裕が見られがちなCPUリソースをより活用し、より精度の高い重複排除を行えばディスクに転送しなければならないI/Oを削減することができ、結果的によりバランスのとれたリソース稼働を実現できる可能性があります。こうなるとディスクの容量削減だけではなく、I/O帯域の削減につながってくるため、環境によってはボトルネックが解消されて全体的な性能が向上する可能性すらあります。なのでリアルタイム型の重複排除は理にかなっている、と考えることができます。

ここまででZFSの重複排除機構について最も重要な仕様については理解することができますが、同時に次のような疑問も湧いてきます。

「これまでも容量を削減する機構として圧縮やスナップショットがあったけどそれとはどう違うのか?」

この疑問について次のエントリでまとめようと思います。

with one comment

Written by 中嶋 一樹

11月 8th, 2009 at 1:33 pm

Posted in Uncategorized

Tagged with ,

ovmzfsセットアップ手順

資料ではかなり省略して書いてあったのでひとまずここにセットアップ手順を書いておきます。

構成のイメージ

ovmzfs_minimum_design

OpenSolarisセットアップ

OpenSolaris 2009.06をインストールします。

SUNWiscsidm, SUNWiscsit, SUNWiscsitgtをインストールし、iscsitgtdを起動する

[root@opensolaris]# pkg install SUNWiscsidm SUNWiscsit SUNWiscsitgt
[root@opensolaris]# svcadm enable iscsitgt

VM Server & VM Managerセットアップ

Oracle VM 2.2のVM Serverをインストールします(このあたりはマニュアル@ITの記事このブログの記事等を参照ください)

VM Serverのパーティションレイアウトはカスタム設定で以下のようにしておきます。

/boot ext3 200MByte

swap 1280MByte

/ ext3 残り全部

Oracle VM Managerをインストールします。もし、VM Manager用のゲストOSもしくはNativeOSを用意することが難しい場合は、VM Server上にVM Managerをインストールするという荒技も可能です。以下のようにVM ManagerのisoファイルをVM Server上でマウントし、通常通りrunInstaller.shを起動すればインストールできます。

[root@vmserver]# mount -o loop,ro OracleVM-Manager-2.2.iso /mnt
[root@vmserver]# sh /mnt/runInstaller.sh

VM ManagerをVM Server上にインストールした場合は、以下の[root@vmmanager]は[root@vmserver]と読みかえてください。

SSH設定

vmmanagerでovmzfsを実行するユーザにsuします。rootでもOKです。

公開鍵を生成します。

[root@vmmanager]# ssh-keygen

生成した公開鍵を以下に対して登録します。

  • VM Serverのrootユーザ
  • ZFSサーバPrimary Administratorとなっているユーザ(インストール時にユーザを作成していなければroot、作成していればそのユーザ)
[root@vmserver]# mkdir $HOME/.ssh && chmod 700 $HOME/.ssh
[root@vmserver]# vi $HOME/.ssh/authorized_keys

(vmmanagerのid_rsa.pubの内容をコピーする)

[user@opensolaris]$ mkdir $HOME/.ssh && chmod 700 $HOME/.ssh
[user@opensolaris]$ vi $HOME/.ssh/authorized_keys

(vmmanagerのid_rsa.pubの内容をコピーする)

*OpenSolarisのrootユーザを使用する場合は/etc/ssh/sshd_configのPermitRootLoginをyesにし、svcadm restart sshしておきます。

vmmanagerからそれぞれのホストのsshでログインして、プロンプトなしでログインできることを確認します。

python-ZSIインストール

VM Managerにpython-ZSIをインストールします。python-ZSIはULN(Unbreakable Linux Network)のEnterprise Linux 5 Add-onsのChannelにあります。

[root@vmmanager]# up2date python-ZSI

ULNが使えないという人はこちらからRPMをダウンロードしてrpm -iでインストールしてください。

python-ZSI-2.1-a1.el5.noarch.rpm

ovmzfsセットアップ

VM Managerにovmzfsをインストールします。ovmzfsは一つのpythonスクリプトなのでこのファイルをパスの通っているディレクトリに置けばOKです。

[root@vmmanager]# wget http://nkjmkzk.net/wp-content/uploads/2009/11/ovmzfs-0.81.zip
[root@vmmanager]# unzip ovmzfs-0.81.zip
[root@vmmanager]# mv ovmzfs /usr/bin/

以下のようにovmzfsを実行します。対話的に初期設定が行われ、必要なモジュールファイルがVM Managerからダウンロードされ、ZFSサーバでレポジトリが初期化されます。

[root@vmmanager]# ovmzfs init

ZFSサーバの初期化が成功すると以下のようなメッセージが出力されます。

>>>                                 >>>
>>> New repository has been created >>>
>>>                                 >>>
Shared Filesystem for /OVS is exported as opensolaris:/rpool/ovmzfs/[POOL NAME]/ovs
Please run following command on VM Server.

[root@vmserver]# /opt/ovs-agent-2.3/utils/repos.py --new opensolaris:/rpool/ovmzfs/[POOL NAME]/ovs
(UUID of this filesystem will be displayed)

[root@vmserver]# /opt/ovs-agent-2.3/utils/repos.py --root [UUID]
And then, please create Server Pool using VM Manager

このメッセージに沿ってVM Server上でレポジトリを登録します。

VM Serverで共有ディスクを登録します。

[root@vmserver]# /opt/ovs-agent-2.3/utils/repos.py --new opensolaris:rpool/ovmzfs/[POOl NAME]/ovs
[ NEW ] 5bcd80df-cb99-496a-8130-8713560f6fb8 => opensolaris:rpool/ovmzfs/[POOL NAME]/ovs

[root@vmserver]#/opt/ovs-agent-2.3/utils/repos.py --root 5bcd80df-cb99-496a-8130-8713560f6fb8

次にVM ManagerからServer Poolを作成し、先ほどのVM Serverを登録します。

このとき、Server Pool名はovmzfsの初期設定で入力した値と一致しなければいけないことに注意してください。

無事にVM ManagerでServer Poolが作成できればovmzfsのセットアップは完了です。VM Serverが複数ある場合はVM Managerから追加登録してください。

without comments

Written by 中嶋 一樹

11月 3rd, 2009 at 7:57 pm

Posted in Uncategorized

Tagged with , ,

Oracle VM meets ZFS !!!! – Oracle VM Forum 2009 東京 追加開催(10/30)

今月末の10/30日にOracle VM Forum 2009を東京で追加開催します。

Oracle VM Forum 2009 ~クラウドを掴む!次世代IT基盤構築のノウハウを伝授~

基本的に9/1におこなったイベントが好評だったのでその追加開催という形になるのですが、2セッション程新しい物に入れ替えています。僕がお話するセッションは下記2つです。

14:20 – 15:10 徹底解説「Oracle RAC on Oracle VM」で構築する次世代基盤実装

15:20 – 16:10 ZFSとOracle VMを連携させた門外不出の検証環境 構築手法(New !!!!)

後者のセッションが今回新規のものです。このセッションでは「イケてる仮想化検証環境」をどう構築するかにスポットを当てています。Oracle VM環境のストレージとしてOpenSolarisのZFSを使用し、瞬間仮想マシンプロビジョニング、スナップショットバックアップ等を実現する手法を紹介します。

Oracle VMはバージョン2.1.5から外部からマネージャ機能を呼び出せるWeb Service APIを装備しています(現在の最新バージョンは開催中のOracle Open Worldで発表となった2.2です)。 今回紹介する環境はこのAPIを叩いてZFSとOracle VMを連携させるツール「ovmzfs」を使い、ZFSの能力を仮想化環境で発揮させるというものです。セッションではこのツールの紹介/デモを行います。

そしてこのovmzfsというツールはオープンソースとしてそろそろ公開します。ZFSや仮想化環境にご興味のある方は是非!

without comments

Written by 中嶋 一樹

10月 15th, 2009 at 3:29 pm

Posted in Uncategorized

Tagged with , , , ,

ZFSのiSCSI TargetをLinuxから利用するときのアクセス制御設定

仮想化環境でゲストOSにネットワーク経由(iSCSI)で直接ストレージを認識させる場合、ストレージ側で何らかの接続制御を行う必要に迫られます。何も制御してないと、ゲストOS: NKJMからゲストOS:SUZUKI用のボリュームに接続できてしまったりと、意図的であろうとなかろうと本来接続するボリュームとは違うボリュームに接続してしまう可能性があるからです。

ちなみにゲストOSから直接ストレージを認識させる形式ではなく、一旦ホストOS(dom0)に認識させてからゲストOSに貸し出すような形であればホストOS側で制御できるのでそこまでデリケートになる必要はないでしょう。

今回はiSCSIストレージにZFS、ゲストOSにLinux(Oracle Enterprise Linux 5.x, Redhat Enterprise Linux 5.x, CentOS 5.x)を使用しているときのアクセス制御についてまとめておきます。

「オペレーションミスを予防する」という目的であればInitiator IQNでアクセス制御する程度がシンプルでいいでしょう。しかしInitiator IQNは簡単に詐称できるので、セキュリティを真に確保しなければいけないPublicな環境であればより強固な認証を実施することが求められるでしょう。

それぞれの制御方法について順に紹介していきます。

Initiator IQNで認証

特定のTargetにアクセスできるInitiator IQNをあらかじめ定義しておき、アクセス時のInitiator IQNをベースに制御を行うものです。

Initiator側(Linux)

特に設定は必要ありませんが、Initiator IQNの情報だけ取得しておく必要があります。

[root@initiator1]# cat /etc/iscsi/initiatorname.iscsi
InitiatorName=iqn.1994-05.com.redhat:123456

Target側(OpenSolaris)

まず接続を許可するInitiator IQNのオブジェクトを作成します。オブジェクト名は何でも構いませんが今回はinitiator1としています。

[root@target]# iscsitadm create initiator -n iqn.1994-05.com.redhat:123456 initiator1

次にそのInitiatorオブジェクトと、アクセスを許可したいTargetを紐づけます。

[root@target]# iscsitadm modify target -l initiator1 [TARGET_NAME]

これでTARGET_NAMEはinitiator1,つまりiqn.1994-05.com.redhat:123456からのアクセスのみを許可するようになります。

CHAP認証

CHAP認証ではInitiator IQNの検査に加えusername/passwordによる認証を行います。

Initiator側(Linux)

CHAPのusername/passwordを設定します。これには設定ファイルを編集する方法と、TargetをDiscoveryして登録し、登録されたTargetのプロファイルを設定する方法があります。前者はグローバルなデフォルト設定になるので、新しく登録されたTargetにはすべてこの設定ファイルに記載されているusername/passwordでログインしにいくようになります。Target個別に認証方法やusername/passwordを設定する場合は後者の方法で設定する必要があります。以下では前者の設定ファイルの編集を解説します。

[root@initiator1]# vi /etc/iscsi/iscsid.conf
node.session.auth.authmethod = CHAP
node.session.auth.username = user1
node.session.auth.password = zfszfszfszfs (12文字以上16文字以内)

編集が完了したら設定を反映させるためにiscsidをリスタートします。

[root@initiator1]# service iscsi restart

以上でInitiator側の設定は完了です。

Target側(OpenSolaris)

まず接続を許可するInitiator IQNのオブジェクトを作成します。オブジェクト名は何でも構いませんが今回はinitiator1としています。

[root@target]# iscsitadm create initiator -n iqn.1994-05.com.redhat:123456 initiator1

次にそのInitiatorにusername/passwordを設定します。これはInitiator側で設定したusername/passwordと一致しなければなりません。

まずはusernameです。

[root@target]# iscsitadm modify initiator -H initiator1 user1

次にpasswordです。

[root@target]# iscsitadm modify initiator -C initiator1
*プロンプトが表示され、パスワード(今回はzfszfszfszfs)を2度入力します。

次にそのInitiatorオブジェクトと、アクセスを許可したいTargetを紐づけます。

[root@target]# iscsitadm modify target -l initiator1 [TARGET_NAME]

これでTARGET_NAMEはinitiator1,つまりiqn.1994-05.com.redhat:123456からのアクセスのみを許可し、さらにCHAPの認証が通った場合だけアクセスできるようになります。以下のようにInitiator側から登録とログインを行ってみてください。

[root@initiator1]# iscsiadm -m discovery -t st -p [TARGET_IP]
[root@initiator1]# iscsiadm -m node --login

なお、すでにInitiator側でTargetを登録した状態でiscsid.confを編集してservice iscsi restartしてもログインは成功しません。すでにそのTargetのプロファイルはCHAP認証なしということで作成されているからです。この場合は一度プロファイルをiscsiadm -m node -o deleteとして削除してdiscoverからやり直すか、Targetのプロファイルを個別に設定してやる必要があります。その方法を以下に記載しておきます。

[root@initiator1]# iscsiadm -m node -T [TARGET_IQN] -o update -n node.session.auth.authmethod -v CHAP
[root@initiator1]# iscsiadm -m node -T [TARGET_IQN] -o update -n node.session.auth.username -n user1
[root@initiator1]# iscsiadm -m node -T [TARGET_IQN] -o update -n node.session.auth.password -n zfszfszfszfs

という感じです。

without comments

Written by 中嶋 一樹

9月 19th, 2009 at 6:12 pm

Posted in Uncategorized

Tagged with , , ,

OpenSolaris vs Linuxの超約

最近TuxRadarのOpenSolaris vs Linuxという記事が話題です。

内容はもちろんOpenSolarisとLinuxを比較する記事ですが、細かくスペックを比較するようなコンテンツではなくOpenSolarisの特徴的な機能/制約に言及することで客観的に両者を理解できる簡潔で読みやすいコンテンツになっています。その内容を以下に大雑把にまとめておきます。

広範囲なハードウェアサポートはLinuxに一日の長がある

今日のLinuxカーネルはデバイスドライバがその大部分を占めると言われるだけあって広範囲に及ぶデバイスのカバレージはLinuxに一日の長がある。ただしLinuxは「とにかくサポートするデバイスを増やす」ことに注力しており、そのためにはデバイスドライバ用のカーネルインターフェース仕様を変えることもいとわないというスタンス。それに対してOpenSolarisは互換性重視。今開発したドライバは10年後にも使えるというスタンス。

ZFS

名実ともに今のSolarisの人気を引っ張っているのはこのZFSといっても過言ではない。Linuxの事実上標準ファイルシステムであるext3はext2との互換性を重視したもので、ZFSはそれに比べてかなり先進的な機能が搭載されいている。

プールという概念

ZFSは今までのようにファイルシステム毎にディスクを区切って容量を分配するのではなく、容量はみんなで共有、ファイルシステムは管理上の独立性のために作成という仕様になっている。

注釈> Linuxでは100Gのディスクがひとつ在って、その上に4つのファイルシステムを作成するということはディスクを1/4づつに区切ることを意味する(均等分割すれば)。一方SolarisのZFSでは4つのファイルシステムすべてが100Gを共有するという仕様。より効率的なディスクリソースの使用が可能になる。ディスクはプールに追加され、そのプールをファイルシステムみんなで共有する。そのプールにはオンラインでディスクを抜き差し可能というのも大きなポイント。

スナップショット/リストア

ZFSではスナップショットとそれをリストアするという操作が可能。これらはコマンドラインでも可能だが、OpenSolaris 2009.06では洗練されたGUIが利用可能。中でも「タイムスライダー」は必見。つまみを左右することでタイムマシーンのようにファイルを過去の任意の時点に戻すことができる。

*詳しくは別サイトのこの動画でみてほしい。

TIme Slider Screencast

仮想化テクノロジー

OpenSolarisではxVMというXenベースの仮想化機構に加え、Zoneという仮想化も使用することができる。

注釈> 最近ZoneについてXenやVMwareにくらべて未熟な仮想化技術と思っている人をしばしば見かけますがそうではありません。Zoneは同じOSを高密度に動かすという要件であればXenやVMwareよりも優れた仮想化技術です。なので集約密度が命のVPSホスティングサービス業者はXenやVMwareよりもVirtuozzoというZoneに似た方式の仮想化ソフトを採用していることが多い。

コマンドの違いまとめ

これは優劣の問題ではないが、LinuxユーザがSolarisをつかったときに、「あれ、/var/log/にあんまりログないな」みたいなことがよくありますがそういうときに役に立つTipsです。

e38394e382afe38381e383a3-1

これも詳しくはオリジナルページでみてみてください。

あとはインストール時の注意事項についてもまとめられていますが、あんまり面白い話でもないので割愛。

特徴と言えばあとDTraceがありますが、これには触れられてないですね。

without comments

Written by 中嶋 一樹

9月 17th, 2009 at 11:11 pm

Posted in Uncategorized

Tagged with , ,

LVMのSnapshotは直感的か?(ZFSとの比較有り)

現在、Linuxのファイルシステムのスタンダードと言えばext3に間違いないでしょう。しかしながらext3はext2との互換性を可能な限り保ちながらジャーナリング機能を追加するという基本設計です。なのでファイルシステムとしては少々古びており、技術的に最も優れているというわけではありません。最近ext4の安定板がkernel 2.6.28で利用可能となりましたが、ext4についてもext2からの設計を受け継いでいるため、それほど大きな機能追加や基本設計の変更というのは多くありません。

そんな中、Snapshot機能は差分バックアップとして効率的な考え方ですが、現在ファイルシステムでその機能をサポートしているものは多くありません。ext3もSnapshot機能は実装されておらず、実際LinuxでSnapshotを行うにはボリュームマネージャ(LVM)で行うことが最も手軽でポピュラーだと言えます。LVMのSnapshot機能はその使い方についてはそこら中に情報がありますが、実装についてはあまり知られていない気がします。僕もそこまで細かく見ているわけではありませんが、ユーザが往々にしてハマりそうなポイントをいくつかの例を見ながら挙げてみたいと思います。

あるLV, /dev/test/dataがあるとします。このLVのSnapshotをdata-snapとしてとります。dataの中のファイル, test.img (1Gbyte)をrmしたらどうなるでしょうか? 個人的な感覚では、test.imgのdata block情報がdata-snap領域にコピーされてからtest.imgが削除される。なのでdata-snapに確保してある領域が1Gbyte減る、と思います。

しかし実際にはdata-snapの領域はほとんど減りません。

また、dataの中にnew.img (1Gbyte)を新たに作成したらどうなるでしょうか? 個人的な感覚では、特段dataの中のデータを変更したわけじゃないのでdata-snapは関知しないのではと思います。

しかし実際にはdata-snapの領域は1Gbyte消費されます。何か納得いかない感じ。

つまりLVMのSnapshotはファイルシステムが実際にdata blockを更新したときにもとのblockをコピーするということに尽きる、という感じです。もし元のdata blockが空であっても。rmの場合はファイルシステムがdata blockを上書きするのはrm発行時ではなく、次にそのblockがファイルシステムによって確保されたときなので、それまではdata-snapの方にはそのデータはコピーされず、存続してるデータを参照し続けています。ある種効率的と言えば効率的です。でも、要は直感的でないのです。個人的には。

これに対し、先進的なファイルシステムの一つとしてZFSがあります。ZFSは現在Solarisのデフォルトファイルシステムとして採用されています。このファイルシステムは悔しいけど正直すごい。Linuxでもbtrfsってのが同じようなコンセプトで開発されていますが、こちらはまだunstableでkernel 2.6.29 rc1とかでようやくメインストリームにマージされた模様。かなり遅れをとっています。ZFSがすごいポイントは結構一杯あるので今回はSnapshotところに焦点を絞ります。ZFSはファイルシステムではあるものの同時にボリュームマネージャでもあります。ファイルシステムの機能でSnapshotが撮れてしまいます。そしてZFSのSnapshot実装はLinuxのLVMとは異なります。

先の2つの例では結果が逆になります。つまり、data中のファイルをrmした場合は即時data-snapの方にコピーされます。また、dataにファイルを新規作成した場合は関知しません。

LVMが「data blockを変更したらオリジナルのdata blockをコピーする」というスタンスであるのに対し、ZFSは「オリジナルのデータを維持する」というより上位の考え方で実装されている気がします。

*ちなみに上記data blockはより正確にはchunkということになると思われます。

個人的にはZFSの方が好きです。あとZFSが優れているのがrollbackをちゃんと備えているところですね。LVMは残念ながらrollback(もしくはrevert)を行うためのコマンドを用意していません。なのでリストアするには少し七面倒くさい手順が必要です。ZFSの場合はzfs rollback xxxxxとすれば一発でオリジナルのファイルシステムをSnapshotを撮ったときの状態に戻すことができます。うーむ、ZFS良すぎ。

この他にもとんでもいい機能がかなりありますがそれはまた機会があれば。最後にOpenSolarisのスクリーンショットを。結構カッコいいのよね。。

3355737445_a11e7052f9_b

without comments

Written by 中嶋 一樹

3月 15th, 2009 at 10:30 pm

Posted in Uncategorized

Tagged with , ,

ZFSっていいんじゃないの

以前からちらほらと名前は聞いていたZFSですが、少し調べてみたところ相当良いのではと思いました。 ZFSはオープンソースとしてSun Microsystemsが開発しているファイルシステムで、もともとは将来のSolaris用に開発していたのを現在ではSolarisとは切り離して単独のオープンソースプロジェクトとして開発が進められている、というものです。

MacOS Xの次期バージョンでもオプショナルで採用予定とのことなのでこれを期に一気に認知度があがるんじゃないかなと思います。

さてこのZFS、何がいいのかというとまとめるとこんな感じ。

バックアップ、リストア関連
・フィアルシステムのスナップショット
・お気軽ロールバック

耐障害性関連
・同一Disk上でのデータ冗長化

柔軟性
・論理ドライブ、パーティションとかはもうナシ ひとつのストレージプールで表現

この中で特に僕がフムフムと思ったので柔軟性。
最近VA Linuxの高橋さんから「パーティションとかホントいらないよね」という話を聞いてなるほどーーっと思っていたところなのでこれは「おぉ、」と思いました。

要はパーティションでディスクを区切っちゃうと、シリンダの最後のパーティションなら容量を拡張することはなんとか可能ですが、真ん中くらいにあるパーティションの容量が足りなくなったりすると単純にそのパーティションを伸長することはできません。

これを「パーティションなんてもうナシよ。 ディスクはストレージプールで一括して抽象的に表現します」っていうのがZFS。 こうすることで、「オイオイ、予想外に/home足りねぇーぞ。 /home/nkjm使いすぎじゃね? /var死ぬ程余ってんのに。」ということがなくなります。

以下、www.opensolaris.orgより。

ZFS presents a pooled storage model that completely eliminates the concept of volumes and the associated problems of partitions, provisioning, wasted bandwidth and stranded storage. Thousands of filesystems can draw from a common storage pool, each one consuming only as much space as it actually needs. The combined I/O bandwidth of all devices in the pool is available to all filesystems at all times.

あとスナップショットによる高速インクリメンタルバックアップやロールバックとかも相当イイ! 来週は仕事してるフリしてZFSの検証でもしよっかなーー。 でも残念なことに今のとこLinuxにはportされてない模様。 検証するならopensolarisかFreeBSD上なのかな。 一応Linux向けには現在ZFS for FUSE/Linuxってのがあるみたい。

参考:

without comments

Written by 中嶋 一樹

12月 6th, 2008 at 6:56 pm

Posted in Uncategorized

Tagged with , ,