nkjmkzk.net

powered by Kazuki Nakajima

Archive for 9月, 2009

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 , ,