![閉じる [x]](http://dw1.s81c.com/i/c.gif){kind=small}
ZFS は現在利用可能なファイルシステムの中で最も高度なファイルシステムの 1 つです。ZFS は Zettabyte File System の頭文字をとったものですが、そのストレージ能力 (最大 256 x 1015 ゼタバイト) をそのまま表現しています。別の言い方をすると、1 ゼタバイトは 1,073,741,824 テラバイトと同じです。
このユニークで強力なツールには、さまざまな側面があります。ここではスケーラブルで冗長性を持つストレージ・サーバーの構築に関連する側面に焦点を絞ります。そのために RAID-Z を使用します。RAID-Z は名前からもわかるように、RAID 技術と似ています (より具体的に言えば、RAID-5 と似ています)。
RAID をよく理解している人であれば、RAID-Z がどんなデバイス (またはコントローラー) によってディスクとデータを処理しているのか不思議に思うかもしれません。RAID-Z では、すべての処理はファイルシステム自体によって行われます。ただし RAID-Z は他の類似技術とは異なり、破損したブロックを即座に自己修復し、ユーザーの手を煩わせません。RAID-Z は常にデータのチェックサムを検証して完全性を確認し、また再構築が必要なブロックを特定することができます。RAID-Z はそうした操作を、要求されたデータがユーザーに渡される前に行います。
RAID-Z と ZFS の両方をサポートするオペレーティング・システムはいくつかあるため、どのオペレーティング・システムを選ぶかは皆さんのお好み次第です。この記事で紹介する例と手法のほとんどは、どの OS にも適用でき、どの OS でも適切に動作するはずです。
皆さんには現在、どの程度の容量が必要なのでしょう？ 1 年後にどの程度の容量が必要になると予測しているのでしょう？そのセットアップに適したハードディスク・ドライブの数は何台なのでしょう？作業を始める前に、これらの質問をすべて検討するとよいでしょう。ここでは最適な準備ができるように、これらの設計上の決定事項のそれぞれについて説明していきます。
ZFS ファイルシステムの機能とパフォーマンスをフルに活用するために、ZFS ファイルシステムをネイティブでサポートするオペレーティング・システムを使用することを強くお勧めします。これから説明する例ではすべて、オペレーティング・システムとして OpenIndiana を使用します (OpenIndiana は Open Solaris から分岐してコミュニティーによって保守が行われています)。そのため、コマンドや端末操作は OpenIndiana 環境を反映しています (OpenIndiana について詳しくは「参考文献」を参照)。
ただし、Linux を使い慣れており、この記事で実現する結果と同じ結果を得るための対応するコマンドを理解している人の場合には、選択したディストリビューションでは ZFS ファイルシステムをポーティングした zfs-fuse がサポートされているかどうかを確認する必要があります。
ストレージ空間は他の選択肢に直接影響するため、ストレージ空間がどの程度必要であるかを設計フェーズの最初に検討することが非常に重要です。またストレージ空間は、どのような方式の RAID-Z 構成が必要であるかによっても影響されます (この点については「RAID-Z の選択肢」セクションで詳しく説明します)。
ストレージ全体の一部として OS を含めてはなりません。OS は別のハードディスク・ドライブにインストールすることをお勧めします。そうした方が、共有ファイルシステムに影響を与えることなく容易にシステムの再インストールや修復を行うことができます。
どの程度のストレージ空間を想定している場合であれ、その想定と RAID-Z に必要な台数 (例えば、この記事の場合のように少なくとも 5 台のハードディスク・ドライブが必要、など) とが一致しているかどうかを確認する必要があります。サイズの異なるハードディスク・ドライブ (例えば 5 x 2 テラバイトのドライブと 1 x 1 テラバイトのドライブなど) を使用して RAID-Z を構築することもできますが、ZFS は実質的に、プール内にある最小容量のハードディスク・ドライブによってハードディスク・ドライブを定義します。
最適なパフォーマンスを得るためには、ハードディスク・ドライブには同じブランドで同じサイズのものを使用する必要があります。
RAID-Z を構築するにはさまざまな構成方法を利用することができます。ここではそのうちの 2 つについて説明し、次にこのプロジェクトで最終的に選択した方式について詳細に説明します。
RAID-Z はフォルト・トレランス性が最も低い方式です。この方式ではプールに 1 台のパリティー・ディスクがあります。複数のドライブで問題が発生すると、ストレージ・プールは破損して回復不能になります。
RAID-Z2 はパリティー用として 2 台のディスクを使用します。この 2 台のディスクのおかげで、ディスクの破損や動作不良といった問題が発生した場合にも安全です。RAID-Z2 を適切にセットアップするためには 2 台のハードディスク・ドライブが余分に必要ですが、RAID-Z2 は単純な RAID-Z よりもフォルト・トレランス性が高い方式です。
RAID-Z2 を構築するには少なくとも合計 5 台のドライブが必要であり (2 台はパリティーに使用されます)、全体としてのストレージに使用できるのは 3 台のドライブということになります。例えば 2 テラバイトのドライブを使用する場合は約 6 テラバイトのストレージが得られることになります。
先ほど触れたように、同じブランドで同じサイズのドライブを使用することがベストです。ドライブ・プールを構成する場合、最もよく似たハードディスク・ドライブを使用した方が安全です。
理想的には、ストレージ・サーバーを構築する際には少なくとも 1 台余分にハードディスク・ドライブを購入し、遅延発生の可能性を減らします。入手したハードディスク・ドライブに製造上の問題があることは珍しくありません。
ハードディスク・ドライブを追加するとデータがストレージ空間全体に分散されるため、速度が向上します。そのため、目標とするストレージ空間と合計サイズとが一致しているかどうかを確認することが重要です。マザーボードを拡張できる SATA コントローラーがいくつかありますが、事前に計画しておかないと、そうしたコントローラーがボトルネックとなる可能性があります。
スケーラブルで拡張可能なストレージにする上で重要な要素として、以下の 3 つがあります。
- ハードディスク・ドライブの数
- 全体的なストレージ容量
- ハードディスク・ドライブによるサーバー容量
私はごく最近、16 テラバイトのストレージ・サーバーを構築しましたが、このサーバーはその 2 倍の容量にまで拡張可能な機能を備えています。そのため、予想外の拡張に対応することができ、また予算を抑えることもできました。
私達は当初、オペレーティング・システムを別のドライブにインストールすることにし、それとは別に利用できるデバイスが 5 台ありました。後でストレージ・プールを作成する際にデバイスを指定できるように、各デバイスのラベルをメモしておく必要があります。
リスト 1. デバイス・ラベルを検出する
root@raidz:~# format Searching for disks...done AVAILABLE DISK SELECTIONS: 0. c7d0 DEFAULT cyl 4092 alt 2 hd 128 sec 32 /pci@0,0/pci-ide@1,1/ide@0/cmdk@0,0 1. c9t0d0 DEFAULT cyl 1022 alt 2 hd 128 sec 32 /pci@0,0/pci8086,2829@d/disk@0,0 2. c9t1d0 DEFAULT cyl 1022 alt 2 hd 128 sec 32 /pci@0,0/pci8086,2829@d/disk@1,0 3. c9t2d0 DEFAULT cyl 1022 alt 2 hd 128 sec 32 /pci@0,0/pci8086,2829@d/disk@2,0 4. c9t3d0 DEFAULT cyl 1022 alt 2 hd 128 sec 32 /pci@0,0/pci8086,2829@d/disk@3,0 5. c9t4d0 DEFAULT cyl 1022 alt 2 hd 128 sec 32 /pci@0,0/pci8086,2829@d/disk@4,0 Specify disk (enter its number): |
format コマンドを発行してラベル (または ID)
を検出していますが、選択するための数字は入力していません。Ctrl-C を入力してプロンプトを終了します。
ここではデバイス 0 に OS をインストールしましたが、その後、デバイス 0 とは別に 5 台のデバイスを追加することにしました。そのため、ストレージ・プールのためのラベルは以下のようになります。
- c9t0d0
- c9t1d0
- c9t2d0
- c9t3d0
- c9t4d0
ZFS には魅力的な機能があり、ZFS 自体が素早くファイルシステムを作成してくれます。ハードディスク・ドライブのフォーマットや再フォーマットには時間がかかることが多いものですが、このケースでファイルシステムの作成に要した時間は約 2 秒です。平均的に、ファイルシステムの作成に要する時間はハードディスク・ドライブのサイズによらず、数秒程度に収まるはずです。
リスト 2. ストレージ・プールを作成する
zpool create tank raidz2 c9t0d0 c9t1d0 c9t2d0 c9t3d0 c9t4d0 |
zpool create tank
コマンドはファイルシステムに対し、ドライブを何台か構築してフォーマットし、このストレージ・プールに tank というラベルを付けるように指示しています。ここでは
RAID-Z のタイプとして raidz2 を指定しましたが、raidz や raidz3 を選択することもできます。選択された 5
台のデバイスの ID はリスト 1 に示すとおりです。
これで、もう 1 つの重要なステップが完了しました。ストレージ・プールは既にマウントされ、使用できるようになっています。
リスト 3. プールが作成できたことを確認する
root@raidz:~# df -h Filesystem size used avail capacity Mounted on swap 642M 16K 642M 1% /tmp swap 642M 44K 642M 1% /var/run rpool/export/home 7.8G 21K 4.1G 1% /export/home rpool 7.8G 77K 4.1G 1% /rpool tank 5.8G 34K 5.8G 1% /tank |
簡潔にするためにコマンドの出力は短縮してありますが、tank が約 6 ギガバイトとして表示されており、既にファイルシステムのルート・レベルにマウントされていることがわかると思います。ここでは 2 台のディスクによるパリティーを選択したので、実質的なストレージ・サイズは他の 3 台のデバイスの合計に近くなります。これでストレージ・プールがマウントされて使用できるようになったので、ディスクとディスク・アレイ全体のヘルス・ステータスをチェックしましょう。
リスト 4. ストレージ・プールのステータス
root@raidz:~# zpool status tank pool: tank state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 raidz2 ONLINE 0 0 0 c9t0d0 ONLINE 0 0 0 c9t1d0 ONLINE 0 0 0 c9t2d0 ONLINE 0 0 0 c9t3d0 ONLINE 0 0 0 c9t4d0 ONLINE 0 0 0 errors: No known data errors |
必要な場合には、ストレージ・プール tank の中にネストされたファイルシステムを作成することもできます。そのようにすると、ストレージの一部を他とは異なる要求に対応させたい場合で、パーミッションが共有ファイルシステム自体に関連付けられている場合に非常に便利です。ただし、共有ファイルシステムが 1 つしかない場合にはファイルシステムをネストさせると複雑になる可能性があります。
リスト 5. 共有ファイルシステムを追加する
root@raidz:/tank# zfs create tank/bar root@raidz:/tank# zfs list NAME USED AVAIL REFER MOUNTPOINT rpool 3.74G 4.07G 77.5K /rpool rpool/ROOT 2.99G 4.07G 19K legacy rpool/swap 512M 4.43G 137M - tank 160K 5.83G 34.8K /tank tank/bar 34.0K 5.83G 34.0K /tank/bar |
ここでは、別の共有ファイルシステムのように表示される bar という名前の共有ファイルシステムを作成しました。共有ファイルシステムの作成はうまく行きましたが、tank/bar として約 6 ギガバイトが使用可能と表示されたからといって混乱しないでください。共有スペース全体を 2 倍にしたわけではなく、便利なように、ストレージ・プール全体のうちどの程度を利用できるかが表示されているのです。
これでストレージ・プールをセットアップできたので、データが破損していないか、あるいはハードディスク・ドライブに欠陥がないか、確認しておく必要があります。幸いなことに、ZFS と RAID-Z により、そうしたタスクの管理を容易に行うことができます。このセクションでは、ハードディスク・ドライブの故障やシステム全体の障害によってオペレーティング・システムが回復できない場合のシミュレーションをします。
このシナリオでは、意図的に 1 台のハードディスク・ドライブにサーバーがアクセスできないようにしました。その場合に ZFS がどのようなレポートを出力するかを見てみましょう。
リスト 6. 故障したドライブのステータス
root@raidz:~# zpool status tank pool: tank state: DEGRADED status: One or more devices could not be opened. Sufficient replicas exist for the pool to continue functioning in a degraded state. action: Attach the missing device and online it using 'zpool online'. scrub: none requested config: NAME STATE READ WRITE CKSUM tank DEGRADED 0 0 0 raidz2 DEGRADED 0 0 0 c9t0d0 ONLINE 0 0 0 c9t1d0 ONLINE 0 0 0 c9t2d0 ONLINE 0 0 0 c9t3d0 ONLINE 0 0 0 c9t4d0 UNAVAIL 0 0 0 cannot open errors: No known data errors |
ストレージ・プールの状態が劣化しています (STATE が DEGRADED になっています)。このステータス・コマンドから、ストレージ・プールで何が起こっているのか、どのハードディスク・ドライブが故障しているように見えるかがわかります。また、このストレージが完全に利用可能であることも重要ですので注意してください。最大 2 台のハードディスク・ドライブに障害が同時に発生しても耐えられる raidz2 を選択したことを思い出してください。このシナリオをもう少し実際の状態に近いものにするために、いくつかのログ・ファイルをストレージにコピーし、DEGRADED の状態をシミュレートしました。
故障したハードディスク・ドライブを交換した後、再度サーバーを起動し、その結果を観察しました。
リスト 7. DEGRADED の状態から回復する
root@raidz:~# zpool status tank pool: tank state: ONLINE status: One or more devices has experienced an unrecoverable error. An attempt was made to correct the error. Applications are unaffected. action: Determine if the device needs to be replaced, and clear the errors using 'zpool clear' or replace the device with 'zpool replace.' scrub: resilver completed after 0h0m with 0 errors on Tue Nov 9 07:25:23 2010 config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 raidz2 ONLINE 0 0 0 c9t0d0 ONLINE 0 0 0 c9t1d0 ONLINE 0 0 0 c9t2d0 ONLINE 0 0 0 c9t3d0 ONLINE 0 0 0 c9t4d0 ONLINE 0 0 2 31.5K resilvered errors: No known data errors |
私達が何も操作しなくても共有ファイルシステムが完全に回復されただけではなく、この出力を見ると、何が発生したのか、どんなアクションが実行されたのか、この結果 (ファイルの破損など) に満足できない場合にどんな選択肢があるのかについての詳細もわかります。
resilvered タグは、この特定のドライブに対してそれだけの量のデータが ZFS によって再構築されたことを意味しています。
このセクションでは、ブートできないというシステム・エラーを再現します。システムは重要なストレージと区別され、別のハードディスク・ドライブにインストールされているので、共有ファイルシステムと関連付けられたデバイスには触らずに、同じハードディスク・ドライブにシステムを再インストールすることができます。
先ほどとまったく同じように、zpool コマンドを使用してストレージを診断し、そのストレージを再度接続できるかどうかを判断します。
リスト 8. 再インストール後のストレージ・プールのステータス
root@reinstalled:~# zpool status pool: rpool state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM rpool ONLINE 0 0 0 c7d0s0 ONLINE 0 0 0 errors: No known data errors |
この結果から、インストールは成功したものの、まだストレージ・プールが検出されていないことがわかります。
リスト 9. ストレージ・プールを検出する
root@reinstalled:~# zpool import pool: tank id: 11026414298329032494 state: ONLINE status: The pool was last accessed by another system. action: The pool can be imported using its name or numeric identifier and the '-f' flag. see: http://www.sun.com/msg/ZFS-8000-EY config: tank ONLINE raidz2 ONLINE c9t0d0 ONLINE c9t1d0 ONLINE c9t2d0 ONLINE c9t3d0 ONLINE c9t4d0 ONLINE |
素晴らしい結果です。これがストレージ・プールです。このプールは完璧な状態にあり、いつでもインポートできる状態になっています。
リスト 10. ストレージ・プールをインポートし、検証する
root@reinstalled:~# zpool import tank cannot import 'tank': pool may be in use from other system, it was last accessed by raidz (hostid: 0x4013af) on Tue Nov 9 07:31:33 2010 use '-f' to import anyway root@reinstalled:~# zpool import -f tank root@reinstalled:~# zpool status tank pool: tank state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 raidz2 ONLINE 0 0 0 c9t0d0 ONLINE 0 0 0 c9t1d0 ONLINE 0 0 0 c9t2d0 ONLINE 0 0 0 c9t3d0 ONLINE 0 0 0 c9t4d0 ONLINE 0 0 0 errors: No known data errors root@reinstalled:~# df -h Filesystem size used avail capacity Mounted on / 7.8G 2.8G 4.2G 41% / /devices 0K 0K 0K 0% /devices swap 800M 368K 800M 1% /etc/svc/volatile rpool/export 7.8G 21K 4.2G 1% /export rpool 7.8G 79K 4.2G 1% /rpool tank 5.8G 104K 5.8G 1% /tank |
ここではプールをインポートしようとしましましたが、出力レポートを見ると、このプールが別のシステム (この場合は先ほどインストールしたシステム) で使用されている可能性があることがわかります。強制的にインポートを行ってステータスを確認してみると、何もエラーが返されません。最後に、マウントされたかどうかとマウントされた場所をチェックし、このプールが以前とまったく同じであることを確認します。
これで、一般的なシナリオを最後まで実行し、ほとんど手間もなくストレージを回復することができました。
共有は単純です。このセクションでは NFS を使用した共有について説明します。NFS は、さまざまな種類の Linux や UNIX を含め、いくつかのオペレーティング・システムでサポートされています。
ZFS はネイティブで NFS をサポートしているため、皆さんはファイルシステムと共有形式、そして共有の場所を知っていればよいのです。
リスト 11. NFS を使用した共有
root@reinstalled:~# zfs set sharenfs=on tank |
この場合、tank は共有ファイルシステムであり、ローカル・ネットワーク内の NFS 上で直ちに共有されます。また、特定の共有ファイルシステムにパーミッションを設定することもできます。ただし、共有ファイルシステムのルートを共有した場合、ルートの子として既に存在する (あるいは今後作成される) 共有ファイルシステムをすべて自動的に共有することになるので注意してください。
図 1. Mac OSX で NFS 共有ファイルシステムに接続する
通常、サーバー上に共有ファイルシステムを構築するには時間がかかりますが、ファイルシステム自体が NFS などの特定のプロトコルによる共有機能を持っているため、それを有効に活用することができます。
先ほどの共有ファイルシステムには、保護やパーミッションが設定されていなかったので、この共有ファイルシステムを変更し、ネットワーク内の特定のサブネットに対して読み書きアクションを実行できるようにしてみましょう。
リスト 12. ZFS 共有ファイルシステムにネットワーク・ベースのパーミッションを設定する
zfs set sharenfs=rw=@10.0.0.0/8 tank |
この種のネットワーク制限を有効にするために追加の構成は必要ありません。このコマンドが送信されると即座にアクセスが制限され、指定されたサブネット以外はこの共有ファイルシステムに対する読み書きができなくなります。
パーミッションの設定は特定のユーザーやグループのみがアクセスできるように微調整することができ、また実装や構成はシステムごとに異なる可能性があります。
ZFS は、さまざまなオペレーティング・システム上で動作するようにポーティングされてきました。現在はさまざまなバージョンの UNIX や Linux で ZFS を利用することができます。
ZFS と RAID-Z に関して説明すべきことは他にもたくさんありますが、この記事では共有ファイルシステムを構築する上で最も重要な項目について、設計時の決定からネットワークを介したストレージの共有まで説明しました。
ZFS で利用できるディスク・アレイの方式は RAID-Z のみではありません。通常はミラーリングの方が高速でメモリー使用量も少ないのですが、ミラーリングするためには同じ数のハードディスク・ドライブが必要になります。この記事で説明した例では、5 台のハードディスク・ドライブで共有ファイルシステムに対応していますが、5 台すべてを使用することはできませんでした。
複数のデバイスを保持できるストレージをサーバー上に構築し、そのストレージをネットワークで共有しようとする場合、ZFS は理想的です。ただし、少なくとも 2 台のデバイスが別にない限り、ZFS の利点のすべてを活用することはできません。デバイスの数が多ければ多いほど、高いパフォーマンスを得ることができます。
皆さんが ZFS について詳しく探る準備ができたこと、そしてこのファイルシステムが便利なものであることに気付いてくれたようであれば幸いです。
学ぶために
- OpenIndiana はコミュニティーで開発されたオープンソースの UNIX オペレーティング・システムであり、ZFS を完全にサポートしています。
- Illumos は OpenSolaris オペレーティング・システムから分岐してコミュニティーで開発された完全にオープンなオペレーティング・システムです。
- Nexenta OS は ZFS 用の Unix カーネルと Debian/Ubuntu のパッケージ・マネージャー (aptitude) を組み合わせたものです。
- ZFS in Ubuntu は Ubuntu で ZFS を使用する方法を解説したウィキ・ガイドです。
- ZFS
のベスト・プラクティスについての資料を読んでください。
- FreeBSD は FreeBSD で ZFS を使用するための完全なガイドです。
- ZFS
の歴史と機能についての説明を読んでください。
- ZFS と他の RAID 方式の比較資料を見てください。
- IBM
オープンソース開発者にとって関心のある、世界中で今後開催される会議や業界展示会、ウェブキャスト、その他のイベントについて調べてみてください。
- developerWorks の Open source ゾーンをご覧ください。オープンソース技術を使用した開発や、IBM 製品でオープンソース技術を使用するためのハウ・ツー情報やツール、プロジェクトの更新情報など、豊富な情報が用意されています。
製品や技術を入手するために
- 皆さんの次期オープンソース開発プロジェクトを IBM ソフトウェアの試用版を使って革新してください。ダウンロードあるいは DVD で入手することができます。
議論するために
- developerWorks
コミュニティーで開発者向けのブログ、フォーラム、グループ、ウィキなどを利用しながら、他の developerWorks
ユーザーとやり取りしてください。developerWorks コミュニティーの Real world open source グループを構築する作業を支援してください。
Alfredo Deza はソフトウェア技術者であり、元プロスポーツ選手であり、オリンピック選手であり、システム管理に豊富な経験を持っています。彼はオープンソース・ソフトウェアを熱心に支持し、また地域の技術グループや PyCon などの国際会議で頻繁に講演を行っています。彼は時間のあるときには写真の腕を磨き、またオープンソース・プロジェクトへの貢献を楽しんでいます。
タグ
スライダーバーを使用することで、より多く（少なく）タグを表示します。
人気のタグは、この特定のコンテンツ・ゾーン（例えば、Java テクノロジー、Linux や WebSphere など）に対するトップのタグを表示します。
マイ・タグは、この特定のコンテンツ・ゾーン（例えば、Java テクノロジー、Linux や WebSphere など）に対するお客様ご自身のタグを表示します。
記事の人気タグ |
記事のマイ・タグタグ・リストへスキップ
記事の人気タグ |
記事のマイ・タグ