この章では、DiskSuite で使用できるいろいろな種類のメタデバイスについて解説します。次の表を参考にして、必要な箇所を探してください。
シンプルメタデバイスは、スライスのみから構成されるメタデバイスで、そのまま使用するか、ミラーやトランスメタデバイスの基本構築ブロックとして使用します。シンプルメタデバイスには、連結方式メタデバイス、ストライプ方式メタデバイス、およびストライプ方式で連結したメタデバイスの 3 種類があります。
多くの場合は、連結方式メタデバイスとストライプ方式メタデバイスが初めに採用されます (ストライプ方式で連結したメタデバイスは、スライスを連結することによって最初の構成から拡張されたストライプ方式メタデバイスと考えることができます) 。
シンプルメタデバイスを使用すると、ディスクの記憶容量をすばやく簡単に拡張することができます。短所は、シンプルメタデバイスではデータの冗長性が提供されないという点です。ミラーや RAID5 メタデバイスでは、データの冗長性を保証します。 (シンプルメタデバイスで特定のスライスに障害が発生すると、そのスライスのデータは失われます。)
シンプルメタデバイスは、以下を除くファイルシステム用のスライスで構成することができます。
ルート (/)
/usr
swap
/var
/opt
オペレーティングシステムのアップグレードやインストール時にアクセスされるファイルシステム
ルート (/) 、/usr、swap、/var、または /opt をミラー化すると、1 面のサブミラーとして機能する単純連結 (1 つのスライスで構成される単純連結) にファイルシステムが配置されます。この単純連結は、単純連結される他のサブミラーによってミラー化されます。
連結方式メタデバイス (または単に単純連結) は、ディスクスライス上でデータを直列に配置させて編成したメタデバイスで、1 つの論理記憶ユニットを構成します。
連結方式メタデバイスは、複数のスライスの容量を論理的に結合させてディスク領域を増やすために使用します。領域が不足してきたら、スライスを追加することができます。
連結方式メタデバイスを使用すれば、オンラインの状態で、記憶容量やファイルシステムサイズを増やすことができます。連結方式メタデバイスでは、メタデバイスのスライスが使用中であっても、新しいスライスを追加することができます。
ストライプ方式メタデバイスの領域を増やすためには、ストライプ方式の連結を構築しなければなりません (「ストライプ方式の連結」を参照) 。
連結方式メタデバイスでは、システムを動作させたままで、動作中の、マウントされている UFS ファイルシステムを拡張することができます。一般に、連結方式メタデバイスの容量は、構成するすべてのスライスの合計サイズに等しくなります。単純連結に状態データベースの複製が含まれる場合には、複製用のスライスの領域を除いたすべてのスライスの合計サイズが、単純連結の容量となります。
連結方式メタデバイスは、1 つのスライスだけでも構築できます。1 つのスライスだけで連結方式メタデバイスを作成しておき、後で領域が不足してきたら、新たにスライスを追加することができます。
連結方式メタデバイスには、他のメタデバイスと同じような名前 (d0、d1 など) が付けられます。メタデバイス名についての説明は、表 1-4 を参照してください。
連結方式メタデバイスが必要な状況
連結方式メタデバイスは、既存のデータセット (ファイルシステムなど) の容量を増やしたいときに構築します。
連結方式は、小規模のランダム入出力や入出力を均等に分散させる場合に適しています。
現実的には、連結方式メタデバイスには制限はありません。ルート (/) 、 swap、/usr、/opt、または /var をミラー化する場合には、単純連結を使用して、これらのファイルシステムをカプセル化しなければなりません。
連結方式メタデバイスの最大サイズは、1 テラバイトです。
図 2-1 に、3 つのスライス (ディスク) から構成される連結方式メタデバイスの例を示します。
データブロック (チャンク) は、ディスク A のスライスからすべてのスライスに渡って直列に書き込まれます。ディスク A には、論理チャンク 1 〜 4 が書き込まれます。ディスク B には論理チャンク 5 〜 8、ディスク C には論理チャンク 9 〜 12 が書き込まれます。メタデバイス d1 の合計容量は、3 つのドライブの合計容量となります。各ドライブの容量が 2 G バイトであれば、メタデバイス d1 の容量は 6 G バイトになります。
ストライプ方式メタデバイス (または単にストライプ) は、2 つ以上のスライスに渡ってデータを分散させるメタデバイスです。ストライプ方式では、2 つ以上のスライス上に同じサイズのセグメントを分散させて配置し、1 つの論理記憶ユニットを構成します。これらのセグメントはラウンドロビン (巡回的な) 方式でインタリーブされ、各スライスから交互に領域がメタデバイスに割り当てられます。
ストライプ方式メタデバイスを単にストライプと呼ぶこともありますが、ストライプ方式で連結されたメタデバイスの構成ブロックをストライプと呼ぶこともあります。「ストライプ化する」といった場合には、ディスクをチャンクに分割して、これらのチャンクを仮想デバイス (メタデバイス) に割り当てることによって、入出力要求を複数のディスクに分散させることを意味します。ストライプ化は、単純連結と同じように、RAID レベル 0 として分類されています。
ストライプ化も単純連結も複数のディスクスライスにデータを分散する方法ですが、ストライプ化の場合は、各ディスクスライスのチャンクに交互にデータを格納します。単純連結の場合は、1 つのディスクスライスが満杯になってから、次のディスクスライスに次のデータを格納します。
連結方式メタデバイスに対して順次入出力操作を行うと、DiskSuite は先頭スライスからすべてのブロックを読み取り、次のスライスからすべてのブロックを読み取り、という処理を繰り返します。
ストライプ方式メタデバイスに対して順次的な入出力操作を行うと、DiskSuite は先頭スライスからブロックセグメント単位 (飛び越しと呼ばれます) ですべてのブロックを読み取り、次のスライスのブロックセグメントからすべてのブロックを読み取り、という処理を繰り返します。
連結方式メタデバイスもストライプ方式メタデバイスも、すべての入出力は並列的に実行されます。
ストライプ方式メタデバイスでは、データを並列的にアクセスすることによって入出力の効率が向上し、入出力の能力が高くなります。新しいファイルシステムやデータセットに対しては、常にストライプ方式メタデバイスを使用してください。
ストライプは、複数のコントローラが同時にデータをアクセスできます。入出力要求処理にかかる時間のうち、メタデバイスを構成しているディスクではほとんどがビジー状態となっているため、並列的なアクセスによって入出力スループットを向上させることができます。
ストライプは、大規模な順次的入出力や入出力が均一にならない場合に適しています。
既存のファイルシステムをストライプ方式メタデバイスに直接変換することはできません。ファイルシステムをストライプ方式メタデバイス上に配置したいときは、ファイルシステムのバックアップをとって、ストライプ方式メタデバイスを作成してから、そのメタデバイスにファイルシステムを復元します。
ストライプを作成する際には、必ず等しいサイズのスライスを使用してください。スライスのサイズにばらつきがあると、ディスク領域の一部が使用されなくなります。
飛び越しの値は、ストライプ方式メタデバイスの論理データチャンクのサイズに等しく、K バイト、M バイト、またはブロック数で表わされます。メタデバイスのパフォーマンスを向上させるのに最適な飛び越し値は、使用するアプリケーションによって異なります。このパフォーマンスの向上は、入出力に参加するディスクの数が増えることによります。入出力要求が飛び越しサイズより大きければ、入出力パフォーマンスが向上します。
デフォルトの飛び越し値は 16 K バイトです。
新しいストライプ方式メタデバイスを (DiskSuite ツールまたはコマンド行インタフェースを使用して) 作成する際には、飛び越し値を設定することができます。ただし、ストライプ方式メタデバイスを作成した後で飛び越し値を変更することはできません。
既存のストライプ方式メタデバイスに対して飛び越し値を設定することはできません。既存のストライプ方式メタデバイスの飛び越し値を変更したい場合には、メタデバイス上のデータのバックアップを取り、メタデバイスを削除して、希望する飛び越し値で新しいストライプ方式メタデバイスを作成してから、そのメタデバイスにデータを復元します。
RAID5 メタデバイスも飛び越し値を使用します。詳しい説明は、「RAID5 メタデバイス」を参照してください。
図 2-2 に、3 つのスライス (ディスク) から構成されるストライプ方式メタデバイスの例を示します。
DiskSuite がストライプ方式メタデバイスのデータを物理ディスクに書き込む場合には、チャンク 1 のデータをディスク A、チャンク 2 のデータをディスク B、チャンク 3 のデータをディスク C に書き込みます。次に、チャンク 4 のデータをディスク A、チャンク 5 のデータをディスク B、チャンク 6 のデータをディスク C に書き込み、同じ処理を繰り返します。
飛び越し値は各チャンクのサイズと同じ値に設定されています。ストライプ方式メタデバイス d2 の合計容量は、最小スライスのサイズにスライス数を掛けた値になります (図 2-2 の各スライスのサイズが 2G バイトであれば、メタデバイス d2 の容量は 6G バイトになります) 。
ストライプ方式の連結は、ストライプ方式メタデバイスに追加のスライス (ストライプ) を単純連結して拡張したメタデバイスです。
DiskSuite ツールを使用して、複数のスライスを既存のストライプ方式メタデバイスまでドラッグすると、それらのスライスを単純連結にするか、ストライプにするかを尋ねられます。metattach(1M) コマンドを使用して複数のスライスを既存のストライプ方式メタデバイスに追加する場合には、ストライプとして追加しなければなりません。
ストライプ方式の連結に対して飛び越し値を設定するには、DiskSuite ツールの 「ストライプ情報」 ウィンドウを使用するか、metattach(1M) コマンドで -i オプションを使用します。ストライプ方式の連結に含まれる各ストライプに対しては、別々の飛び越し値を指定することができます。ストライプ方式の連結を最初から作成する場合に、特定のストライプに対して飛び越し値を指定しないと、その直前のストライプの飛び越し値が使用されます。
図 2-3 に、3 つのストライプを連結したメタデバイス d10 を示します。
ストライプ 1 は、3 つのディスク (A 〜 C) から構成されており、飛び越し値は 16 K バイトです。ストライプ 2 は、2 つのディスク (D と E) から構成されており、飛び越し値は 32 K バイトです。ストライプ 3 は、2 つのディスク (F と G) から構成されています。ストライプ 3 に対しては飛び越し値が指定されていないため、ストライプ 2 から飛び越し値 (この場合は 32 K バイト) を継承しています。まず、ストライプ 1 に、チャンク 1 〜 12 がストライプ方式で割り当てられます。ストライプ 1 が満杯になると、今度はストライプ 2 にチャンク 13 〜 20 が割り当てられます。最後に、ストライプ 3 にチャンク 21 〜 28 が割り当てられます。各ストライプでは、指定された飛び越し値にしたがって、データチャンクがインタリーブされます。
複数のスライスで構成されるシンプルメタデバイスを作成すると、先頭以外のスライスでは、スライスがシリンダ 0 から開始されている場合には、先頭のディスクシリンダは無視されます。たとえば、metastat(1M) コマンドで次のようなリストが出力されたとします。
# metastat d0 d0: Concat/Stripe Size: 3546160 blocks Stripe 0: (interface: 32 blocks) Device Start Block Dbase c1t0d0s0 0 No c1t0d1s0 1520 No c1t0d2s0 1520 No c1t0d2s0 1520 No c1t1d0s0 1520 No c1t1d1s0 1520 No c1t1d2s0 1520 No |
このリストを見ると、最初のスライス以外は、すべてブロック 1520 から開始されていることがわかります。これは、最初のスライス以外のすべてのスライスでは、ディスクセクターの先頭にディスクラベルを保存するためです。メタデバイスドライバは、ストライプ境界を越えてアクセスをマッピングする場合には、最初のディスク以外の少なくとも先頭セクターをスキップしなければなりません。先頭セクターのみをスキップすると、ディスクのジオメトリ (幾何学的配置) が不規則になるため、これらのディスクでは先頭シリンダ全体をスキップしています。こうすることで、上位レベルのファイルシステムソフトウェア (UFS) が、ブロック割り当てを正しく最適化できるようになります。このため、DiskSuite ではディスクラベルの上書きを禁止しており、先頭シリンダを意図的にスキップしています。
単純連結またはストライプにおいて、先頭シリンダをスキップしないスライスが存在しますが、この理由は UFS 側にあります。既存のファイルシステムから連結方式メタデバイスを作成して、後から領域を追加すると、データが失われます。これは、先頭シリンダがデータの開始位置として認識されているためです。
ミラーとは、サブミラーと呼ばれるシンプルメタデバイスのデータを他のメタデバイスにコピーできるメタデバイスです。このコピー操作をデータのミラー化と呼びます (ミラー化は、RAID レベル 1 としても知られています) 。
ミラーは、データの冗長なコピーを持ちます。これらのコピーは、デバイスの障害に備えて、別の物理デバイスに格納しなければなりません。
ミラーはディスク資源を多く必要とします。少なくとも、ミラー化するデータ量の 2 倍のディスク領域が必要になります。DiskSuite は、すべてのサブミラーにデータを書き込むため、書き込み要求の処理時間も長くなります。
構成したミラーは、物理スライスと同じように使用できます。
ミラーはオンラインバックアップ用に使用することもできます。すべてのサブミラーには、同じデータが入っているため、サブミラーをオフラインにして他のメディアに内容をバックアップすれば、ミラーメタデバイスの動作を妨げることなくバックアップ作業が行えます。3 面ミラーなら、バックアップ中も他の 2 つのサブミラーにデータが書き込まれます。バックアップ用に使用したサブミラーをオンラインに戻すと、他の 2 つのサブミラーとの間で同期を取ってから、サブミラーとしての機能を再開します。
既存のファイルシステムを含むすべてのファイルシステムをミラー化することができます。また、データベースなど、どのようなアプリケーションに対してでもミラー化を行えます。1 面のミラーを作成しておいて、後でサブミラーを追加することもできます。
DiskSuite のホットスペア機能をミラーと併用することで、データの安全性と可用度が高まります。ホットスペアについての詳細は、第 3 章「ホットスペア集合」を参照してください。
ミラーには、他のメタデバイスと同じような名前 (d0、d1 など) が付けられます。メタデバイス名についての説明は、表 1-4 を参照してください。各サブミラー (それぞれがメタデバイスでもあります) にも、固有のデバイス名が付けられます。
ミラーは、1 つ以上のストライプまたは単純連結から構成されます。ミラーを構成するストライプや単純連結は、サブミラーと呼ばれます (ミラーを RAID5 メタデバイスで構成することはできません) 。
ミラーは最大 3 つのサブミラーで構成することができます (実際には 2 面ミラーで十分です。3 番目のサブミラーは、データのミラー化を停止せずにオンラインバックアップを取るために使用します) 。
サブミラーは、通常はミラーからしかアクセスできないという点で、シンプルメタデバイスとは異なっています。サブミラーは、ミラーに接続されている状態では、ミラーからしかアクセスできません。
サブミラーをオフラインにすると、ミラーはそのサブミラーへの読み書きを停止します。この時点で、そのサブミラーへのアクセスが可能になり、バックアップなどを実行することができます。しかし、オフラインのサブミラーは読み取り専用になります。サブミラーがオフラインの間は、DiskSuite がミラーへのすべての書き込みを記録します。サブミラーがオンラインに戻ると、書き込み対象の部分 (再同期領域) のみが再同期されます。サブミラーは、エラーが発生した物理デバイスの障害を追跡したり修理したりする目的でもオフラインにできます。
サブミラーには、他のメタデバイスと同じような名前 (d0、d1 など) が付けられます。メタデバイス名についての説明は、表 1-4 を参照してください。
サブミラーは、いつでもミラーに接続したり、ミラーから切断したりすることができます。ただし、1 つ以上のサブミラーが接続されていて動作していることが必要です。サブミラーを強制的に切断するには、metadetach(1M) コマンドで -f オプションを使用します。DiskSuite ツールは、常にサブミラーを強制的に切断するため、専用のオプションはありません。通常は、 1 つのサブミラーのみで構成されるミラーを作成してから、2 番目のサブミラーを追加します。
ミラーによっては、データの可用度は最大となります。その反面、ミラー化するデータ量の 2 倍のスライス (ディスク) 容量が必要になります。
DiskSuite では、3 面 (サブミラーが 3 つ) までのミラーを構成することができます。ほとんどのアプリケーションでは、2 面ミラーで十分で、ディスクドライブのコストも低く抑えることができます。
ミラーの構築手順
ミラーを構築する場合には、必ず 1 面ミラーを作成してから、サブミラーを追加するようにします。こうすることによって、ミラーの再同期が実行され、すべてのサブミラーにおいてデータの整合性が保たれます。
図 2-4 に、d20 および d21 の 2 つのメタデバイス (サブミラー) で構成されるミラーの例を示します。
DiskSuite は、複数の物理ディスクを 1 つの仮想ディスクとしてアプリケーションに提供します。データの書き込みはすべて複製されます。データの読み取りは、ミラーを構成するいずれかのサブミラーからのみ行います。ミラー d2 の容量は (サブミラーのサイズが異なる場合には) 小さいほうのサブミラーのサイズと同じになります。
ミラーのパフォーマンスを最適化するため、以下のオプションを利用できます。
ミラーからの読み取りオプション
ミラーへの書き込みオプション
ミラーを再同期する順序 (パス番号)
ミラーオプションは、最初にミラーを作成するとき、またはミラーを作成した後で設定できます。これらのオプションの変更方法についての説明は、『Solstice DiskSuite 4.2.1 ユーザーズガイド』を参照してください。
ミラーの再同期とは、サブミラー障害やシステムクラッシュが発生した場合、サブミラーをオフラインにしてからオンラインに戻した場合、もしくは新しいサブミラーを追加した場合に、サブミラーから別のサブミラーに有効なデータをコピーする処理のことです。
ミラーの再同期の実行中も、ユーザーはミラーを読み書きできます。
ミラーの再同期は、すべてのサブミラーに (書き込みが進行中のデータを除いて) 同じデータを書き込むことによって、ミラーデータの有効性を保証するものです。
注 - ミラーの再同期は必須の作業で、省略することはできません。ミラーの再同期は自動的に実行されるため、手動で実行する必要はありません。
ミラーに新しいサブミラーを接続 (追加) すると、別のサブミラーから新しいサブミラーにすべてのデータが自動的にコピーされます。ミラーの再同期が完了すると、新しいサブミラーが読み取り可能になります。サブミラーは、切断されるまで接続されたままになります。
再同期の実行中にシステムがクラッシュした場合には、システムがリブートして復旧してから、再同期が実行されます。
システム障害後のリブート中や、オフラインになっていたサブミラーがオンラインに戻ったときには、DiskSuite は最適化されたミラーの再同期を実行します。メタデバイスドライバは、サブミラーの領域を管理しており、障害後にどの領域の同期が取れていないかを判断します。最適化された再同期は、同期が取れていない領域でのみ、データを再同期させます。リブート中にミラーを再同期させる順序 (パス番号) を指定したり、パス番号を 0 に設定することによってそのミラーの再同期を省略したりすることができます (「パス番号」を参照) 。
パス番号の 0 は、読み取り専用としてマウントされているミラーに対してのみ設定してください。
サブミラーを構成するスライスを交換すると、DiskSuite はデータの部分的な再同期を実行します。DiskSuite は、別のサブミラーで機能しているスライスから、新しいスライスにデータをコピーします。
0 〜 9 のパス番号は、システムリブート中にミラーを再同期させる順序を指定します。デフォルトのパス番号は 1 です。パス番号が小さいミラーほど先に再同期されます。0 を指定すると、そのミラーの再同期は省略されます。パス番号の 0 は、読み取り専用としてマウントされているミラーに対してのみ設定してください。同じパス番号のミラーは同時に再同期されます。
DiskSuite では、1 つのミラーに対して異なる読み取りオプションと書き込みオプションを設定することができます。これらのオプションをミラー構成に合わせて適切に設定することにより、読み書きのパフォーマンスを向上させることができます。
表 2-1 ミラーの読み取りオプション
読み取りオプション |
説明 |
---|---|
ラウンドロビン (巡回的) (デフォルト) |
サブミラー間で負荷を均一にします。すべての読み取りは、ミラーのすべてのサブミラーからラウンドロビンで (巡回的に) 実行されます。 |
ジオメトリック (幾何学的な配置順) |
論理ディスクブロックアドレスに基づいて、読み取りをサブミラー間で分割します。たとえば、2 面サブミラーであれば、ミラーのディスク領域を 2 つの等しいサイズの論理アドレス範囲に分割します。片方のサブミラーからの読み取りは論理アドレス範囲の前半に限定され、他方のサブミラーからの読み取りは後半に限定されます。この方針に従うと、読み取りに必要なシーク時間を効率よく短縮できます。パフォーマンスがどの程度向上するかは、システムの入出力負荷とアプリケーションのアクセスパターンによって異なります。 |
先頭のディスクから |
すべての読み取りを先頭のサブミラーに向けます。この方針は、先頭のサブミラーが他のサブミラーより高速である場合にのみ使用します。 |
表 2-2 ミラーの書き込みオプション
書き込みオプション |
説明 |
---|---|
並列 (デフォルト) |
ミラーへの書き込みを複製して、すべてのサブミラーに対して同時に実行します。 |
直列 |
サブミラーへの書き込みを直列に実行します (先頭のサブミラーへの書き込みが完了してから、次のサブミラーへの書き込みを開始します)。 直列オプションは、1 つのサブミラーへの書き込みが完了するまで次のサブミラーへの書き込みを開始してはならないことを指定します。直列オプションは、停電などのためにサブミラーが読み取り不能になった場合に備えて提供されています。 |
複数のスライスで障害が発生した場合には、ミラーが正常に動作を続けられるかどうかは保証されません。しかし、ミラーの構成によっては、複数のスライスで障害が発生した場合にも耐えられる場合があります。ミラー内で障害が発生した複数のスライスに同じ論理ブロックが含まれていなければ、ミラーは動作を続けられます (サブミラーがすべて同じ構成であることが必要です) 。
次の例を見てみましょう。
ミラー d1 は 2 つのストライプ (サブミラー) から構成されています。各ストライプは、構成と飛び越し値が同じ 3 つの物理ディスクから構成されています。ここで、ディスク A、B、および F で障害が発生しても、ミラーの範囲全体にわたり、1 つ以上のディスクによって保証されているため、ミラーは正常な動作を続けることができます。
しかし、ディスク A とディスク D で障害が発生した場合には、それらのディスクに対応する論理アドレス範囲のデータは利用できなくなり、その論理アドレス範囲へのアクセスはエラーとなります。
複数スライスの障害によってミラーのデータが利用できなくなっても、データが利用できる領域へのアクセスは正常に行われます。この場合にミラーは、不良ブロックを含むディスクのように機能します。つまり、破損している部分へはアクセスできませんが、その他の部分へはアクセスできます。
RAID は Redundant Array of Inexpensive Disks (または Redundant Array of Independent Disks) の頭文字を取ったものです。
RAID には 0 〜 6 の 7 段階のレベルがあり、それぞれが異なる方法でデータを分散させてデータの重複性を実現しています (RAID レベル 0 はデータの重複性を提供しませんが、使用されている RAID 構成の大半の基礎となっている構成であるため、RAID のレベルに含まれています)。
DiskSuite では、次の RAID レベルをサポートしています。
RAID レベル 0 冗長性のないディスク配列 (ストライプ化)
RAID レベル 1 ミラー化されたディスク配列
RAID レベル 5 ブロックインタリーブ形式の分散パリティ
RAID レベル 5 は、パリティとデータをすべてのディスクに分散させたストライプ方式メタデバイスです。ディスクが故障した場合には、他のディスクに分散しているデータとパリティ情報からディスクを再構築することができます。
DiskSuite では、RAID レベル 5 をサポートするメタデバイスを RAID5 メタデバイスと呼びます。
新しいスライスを追加すると、DiskSuite は自動的に RAID5 メタデバイスを初期化します。また、既存のスライスを交換すると、DiskSuite は自動的に RAID5 メタデバイスを再同期させます。システム障害やパニックが発生した後のリブートでは、DiskSuite は RAID5 メタデバイスを再同期させます。
RAID5 メタデバイスには、他のメタデバイスと同じような名前 (d0、d1 など) が付けられます。メタデバイス名についての説明は、表 1-4 を参照してください。
RAID5 メタデバイスは、ミラーよりも少ないディスク数でデータの冗長性を提供するので、コストを低く抑えることができます。
RAID5 メタデバイスには、3 つ以上のスライスが必要です。
RAID5 メタデバイスの最大スライス数
RAID5 メタデバイスのスライス数に制限はありませんが、スライス数が多いほど、スライス障害の発生時には読み取り動作にかかる時間が長くなります (RAID5 メタデバイスでは、本質的に書き込み動作に長い時間がかかります) 。
既存の RAID5 メタデバイスにスライスを単純連結することによって、RAID5 メタデバイスを拡張することができます。
RAID5 メタデバイスに追加したスライスのパリティ情報
RAID5 メタデバイスに新しいスライスを追加して拡張すると、新しいスライスのパリティ情報も格納されます。
RAID5 メタデバイスの制限
RAID5 メタデバイスは、ルート (/) 、/usr、swap、または既存のファイルシステムに対しては使用できません。
データブロックをゼロで初期化せずに RAID5 メタデバイスを構築しなおす方法
metainit(1M) コマンドで -k オプションを使用すると、データブロックをゼロで初期化せずに RAID5 メタデバイスを構築することができます (DiskSuite ツールではこの操作を行うことはできません) 。-k オプションは、RAID5 メタデバイスを初期化せずに再構築し、ディスクブロックを「正常」状態に設定します。RAID5 メタデバイスのディスクブロックにエラーが含まれている場合には、DiskSuite がデータを再生する場合もあります。このオプションを使用するかわりに、RAID5 メタデバイスを初期化して、テープからデータを復元することもできます。詳しい説明は、metainit(1M) コマンドのマニュアルページを参照してください。
図 2-6 に、RAID5 メタデバイス d40 を示します。
最初の 3 つのデータチャンクがディスク A 〜 C に書き込まれます。次に書き込まれるチャンクはパリティチャンクで、ディスク D に書き込まれます。このチャンクは、最初の 3 つのチャンクの排他的論理和を取ることによって作成されます。このようにデータチャンクとパリティチャンクを書き込むことにより、 RAID5 メタデバイスを構成するすべてのディスクにデータとパリティの両方が分散します。各ドライブは個別に読み取ることができます。パリティ情報により、いずれか 1 つのディスクが故障しても安全です。この例の各ディスクの容量が 2G バイトであるとすると、d40 の合計容量は 6G バイトになります (ディスク 1 つ分の領域がパリティ用に割り当てられます) 。
図 2-7 に、4 つのディスク (スライス) で構成される RAID5 メタデバイスに 5 つ目のディスクを追加して拡張した例を示します。
RAID5 メタデバイスの作成時には、パリティ領域が割り当てられます。パリティ情報用の領域は、スライス 1 つ分です。ただし、重要な情報が 1 つのディスクに集中するのを避けるため、パリティ情報はすべてのディスクに分散されます。RAID5 メタデバイスにスライスを追加すると、そのディスクにはデータのみが格納され、新しいパリティブロックは割り当てられません。ただし、連結されたスライス上のデータは、デバイス障害に備えてパリティ計算に含められます。
連結した RAID5 メタデバイスは、長期間の使用には適しません。このような RAID5 メタデバイスは大規模の RAID5 メタデバイスを構築できるようになるまでの一時的な手段として使用し、大規模な RAID5 メタデバイスを構築したら、新しい RAID5 メタデバイスにデータを移すようにしてください。
RAID5 メタデバイスに新しいスライスを追加すると、DiskSuite は、そのスライスのすべてのデータブロックを「ゼロ」にします。この結果、パリティ情報によって新しいデータが保護できるようになります。追加した領域にデータを書き込むと、DiskSuite はそのデータをパリティ計算に含めます。
UFS ロギングとは、ファイルシステム「メタデータ」への更新内容を UFS ファイルシステムに適用する前に、ログに書き込むプロセスです。
UFS ロギングでは、UFS トランザクションをログに記録します。トランザクションをログに記録しておくことで、後でファイルシステムにトランザクション情報を適用することができます。
リブート時には、システムは不完全なトランザクションを破棄しますが、動作が完了したトランザクションは適用します。完了しているトランザクションのみがリブートのたびに適用されるため、ファイルシステムの整合性が保たれます。このように、ファイルシステムの整合性が損なわれることはないため、通常は fsck(1M) コマンドで整合性をチェックする必要はありません。
システムクラッシュが発生すると、現在のシステムコールが中断されて、UFS の整合性が損なわれることがあります。システムクラッシュが発生した後は、fsck(1M) コマンドで UFS ファイルシステムの整合性をチェックしてください。整合性をチェックせずにファイルシステムをマウントすると、システムパニックが発生したり、データが破壊されたりする場合があります。
整合性のチェックはデータを読み取って検証するため、大規模なファイルシステムのチェックには時間がかかります。UFS ロギングを使用すれば、完了していないシステムコールからの変更内容は必ず破棄されるため、UFS ファイルシステムをチェックする必要はなくなります。
DiskSuite は、トランスメタデバイスを介して UFS ロギングを管理します。
UFS ロギングは、ファイルシステムに対して fsck(1M) コマンドを実行する必要をなくすことによって、障害の発生後のリブート時間を短縮します。
UFS ロギングの短所
ログが満杯になると、UFS が新しい情報を書き込む前にログを空にしなければならなくなるため、パフォーマンスが低下します。
UFS ロギングを使用できる Solaris バージョン
UFS ロギングは、Solaris 2.4 以降で使用できます。
UFS ではないファイルシステムとルート (/) ファイルシステムは、UFS ロギングの対象にはなりません。
トランスメタデバイスとは、UFS ロギングを管理するためのメタデバイスです。トランスメタデバイスは、マスターデバイスとロギングデバイスから構成されます。
マスターデバイスは、ロギングの対象となるファイルシステムが格納されているスライスまたはメタデバイスです。トランスメタデバイスがロギングデバイスを持っている場合には、そのトランスメタデバイスがマウントされた時点で自動的にロギングが開始されます。マスターデバイスに (トランスメタデバイスを作成してもマスターデバイスは変更されないため) 既存の UFS ファイルシステムを格納するか、もしくは後でトランスメタデバイス上でファイルシステムを作成することができます。同じように、トランスメタデバイスをクリアしても、マスターデバイス上の UFS ファイルシステムはそのまま残ります。
ロギンググデバイスは、ログが記録されるスライスまたはメタデバイスです。1 つのロギングデバイスを複数のトランスメタデバイスで共有することもできます。ログは一連のレコードで構成され、それぞれのレコードがファイルシステムへの変更内容を記述しています。
トランスメタデバイスには、他のメタデバイスと同じような名前 (/dev/md/dsk/d0、d1、d2 など) が付けられます。メタデバイス名についての説明は、表 1-4 を参照してください。
トランスメタデバイスを構成したら、物理スライスと同じように使用することができます。トランスメタデバイスは、ブロックデバイス (最大 2 G バイト) または raw デバイス (最大 1 T バイト) として使用できます。マスターデバイスがファイルシステムを持っていない場合には、トランスメタデバイス上に UFS ファイルシステムを作成することができます。
ロギングデバイスやマスターデバイスとしては、物理スライスまたはメタデバイスを使用できますが、信頼性と可用度を高めるためにはミラーを使用してください。物理的なロギングデバイスでエラーが発生すると、データが失われることがあります。ミラーや RAID5 メタデバイスをマスターデバイスとして使用することもできます。
ロギングデバイスは、1 M バイト以上の領域を必要とします (領域が大きいほど多くのファイルシステムトランザクションを同時に実行できます) 。最大サイズは 1 G バイトです。 1 G バイトのファイルシステムに対して 1 M バイトのログ領域が最低限必要です。できれば 100 M バイトのファイルシステムに対して 1 M バイトのログ領域を確保してください。最適なログサイズを決める規則はありません。最適なログサイズは、各システムの負荷や構成によって異なります。ただし、ほとんどの場合には、64 M バイトを超えるログ領域は必要ありません。ログサイズを変更するのはさほど難しくありません。
一般には、最大の UFS ファイルシステムと、データがもっとも頻繁に変更される UFS ファイルシステムがロギングの対象となります。読み取りトランザクションがほとんどである小さなファイルシステムをロギングする必要はありません。
ログを独立させる必要のあるファイルシステム
すべてのファイルシステムは同じログを共有することができます。しかし、最も負荷が大きいファイルシステムのログを独立させると、パフォーマンスを向上させることができます。
Solaris システムでソフトウェアをインストールまたはアップグレードする際には、/usr、/var、/opt、および Solaris のアップグレードやインストールでシステムが使用するファイルシステムは、ロギング対象から外してください。
ログは、ミラー、未使用のスライス、または状態データベースの複製と同じスライスに格納します。物理的なロギングデバイス (スライス) でエラーが発生すると、データが失われることがあります。
ロギングデバイス用のスライスが空いていない場合
ロギングデバイス用のスライスが空いていない場合でも、トランスメタデバイスを構成することはできます。エクスポートしたファイルシステムをロギングする場合には、ロギングデバイス用に使用するスライスが空いていなくても、トランスメタデバイスは有用です。スライスが利用できるようになったら、ロギングデバイスとしてトランスメタデバイスに接続します。この方法についての説明は、『Solstice DiskSuite 4.2.1 ユーザーズガイド』を参照してください。
ロギングデバイスを複数のファイルシステムで共有することはできますが、負荷の大きなファイルシステムに対しては独立したロギングデバイスを用意してください。ロギングデバイスを共有する際のデメリットは、発生したエラーの種類によっては、そのロギングデバイスを共有しているすべてのファイルシステムを fsck(1M) コマンドでチェックしなければならないということです。
図 2-8 に、ミラー化されたマスターデバイス d3 とミラー化されたロギングデバイス d30 から構成されるトランスメタデバイス d1 を示します。
図 2-9 に、ミラー化されたロギングデバイス d30 を共有している 2 つのトランスメタデバイス d1 および d2 を示します。各マスターデバイスも、共有されているロギングデバイスと同じようにミラー化されたメタデバイスです。