Xsan 2 Administrator Guide - 計画を立てる際の考慮事項とガイドライン

第

2

章

ストレージ・エリア・ネットワークの計画を立てる

29

使用する

RAID

システムの数は、使用可能な領域だけでなく

SAN

のパフォーマンスにも影響を

及ぼすことに留意してください。詳しくは、

「パフォーマンスに関する考慮事項」を参照してく

ださい。

使用可能なストレージをユーザにどのように表示しますか？

特定のプロジェクトに参加しているユーザに対して専用の作業用ボリュームを表示する場合は、

プロジェクトごとにボリュームを作成します。ユーザに対し、ボリューム内のユーザ用の作業

フォルダに加えてほかのユーザのフォルダも表示することが妥当な場合は、

1

つのボリュームを

作成してそのボリュームを複数のプロジェクトフォルダに編成することができます。

ワークフローに関する考慮事項

ユーザのワークフローでは、いくつのファイル共有が必要ですか？たとえば、異なる複数のユー

ザまたはグループが同一のファイル上で同時にまたは連続して作業を行う場合、これらのファイ

ルを

1

つのボリュームに保存することで、コピーの維持や引き渡しをしなくて済みます。

Xsan

では、ファイルロックを使用して、複数のファイルの

1

つのコピーに対する共有アクセスを管理

します。

パフォーマンスに関する考慮事項

高解像度のビデオキャプチャや再生など、実行可能な最高速度で継続的なデータ転送を必要とす

るアプリケーションに

SAN

が対応する場合は、以下に示すパフォーマンス上の考慮事項を念頭

に置いて

SAN

を設計してください：

Â

高性能な

RAID

方式を使用して、

LUN

（

RAID

アレイ）を設定します。詳しくは、

30

ページの

「

LUN

の

RAID

方式を選択する」を参照してください。

Â

そのアプリケーション用のアフィニティタグに、最も高速な

LUN

を割り当てます。高度なパ

フォーマンスを要求されないアプリケーション用のアフィニティタグには、それより低速な

LUN

を割り当てます。

Â

並列処理を強化するには、

LUN

を異なる

RAID

コントローラ全体に展開します。データは各

LUN

にストライプされるので、

2

台の

RAID

コントローラで同時転送することによってパフォーマ

ンスが向上します。

Â

比較的小さな

LUN

（

1

個から数個のドライブモジュールの規模）に割り当てられたアフィニティ

タグで並列処理を強化するには、

1

個か

2

個のドライブモジュールから

LUN

を作成するので

はなく、

RAID

コントローラ上のすべてのドライブに類似のサイズのスライスを作成します。

Â

ファイル転送を可能な限り多くのドライブおよび

RAID

コントローラ全体に展開します。

スライスを

RAID

システムのドライブ全体に作成するようにしてから、これらのスライスを同

じアフィニティタグに割り当てます。

Â

スループットを向上させるには、クライアントのファイバーチャネル・カードの両方のポート

をファブリックに接続します。

Â

ファイルシステムのメタデータとジャーナルデータをユーザデータとは別のストレージプー

ルに保存し、メタデータの

LUN

がユーザデータの

LUN

と同じ

RAID

コントローラ上にないよ

うにします。

Â

SAN

メタデータ用に別の

Ethernet

ネットワークを使用します（各

SAN

コンピュータに追加の

Ethernet

ポートが必要です）。それが無理な場合は、ルーターを使用して、

SAN

が使用する

Ethernet

ネットワークを社内イントラネットまたはインターネットから分離します。

30

第

2

章

ストレージ・エリア・ネットワークの計画を立てる

Â

SAN

で、ディレクトリサービス、メールサービス、またはその他のサービスを独立したサーバ

で運用する場合は、

SAN

メタデータネットワークとは分離された

Ethernet

ネットワークを

使って

SAN

コンピュータをそのサーバに接続します。

Â

ボリュームごとに異なるプライマリ・メタデータ・コントローラを選択し、複数のボリューム

が同じメタデータコントローラにフェイルオーバーする可能性が最小限になるようにボ

リュームのフェイルオーバー優先順位を設定します。

可用性に関する考慮事項

データにとって高可用性が重要な場合は、プライマリ・メタデータ・コントローラに加えて、

1

つ以上のスタンバイ・メタデータ・コントローラを設定します。また、ファイバーチャネル・ス

イッチを冗長化して、各クライアント、メタデータコントローラ、およびストレージ装置間で

ファイバーチャネル接続を二重にすることも考慮してください。

セキュリティに関する考慮事項

セキュリティで完全に保護され、相互に分離されている必要のあるプロジェクトに

SAN

で対応

する場合は、プロジェクトごとにボリュームを作成して、ボリュームに保存されたファイルにク

ライアントまたはユーザが不正にアクセスする可能性を排除できます。

SAN

管理者は、どのクライアントコンピュータにボリュームの使用を許可するかを制御できま

す。クライアントは、クライアント自体の

SAN

ボリュームをブラウズまたはマウントすること

はできません。

「

Xsan Admin

」を使用して、アクセスを禁止したいクライアントでボリュームを

マウント解除します。

「

Xsan Admin

」でアクセス制御リスト（

ACL

）を設定したり、「

Finder

」で標準のファイルアク

セス権を使用してユーザとグループにフォルダへのアクセス権を割り当てることもできます。

LUN

の

RAID

方式を選択する

SAN

のデータの信頼性および復元可能性の多くは、

Xsan

自体ではなく、ストレージプールとボ

リュームを作成するために結合した

RAID

アレイにより提供されます。

SAN

を設定する前に、

RAID

システムの構成または管理アプリケーションを使って、特定の

RAID

方式に基づく

LUN

を

準備します。

RAID 0

アレイ（ストライピングのみ）で構成された

LUN

、または

1

つのドライブに基づく

LUN

は、障害が発生した場合に復元することが困難または不可能です。このような保護されていない

LUN

は、失われてもかまわないスクラッチファイルなどのデータを含むボリュームに対してだけ

使用するようにしてください。

警告：

スタンバイコントローラを使用していないでメタデータコントローラに障害が発生する

と、ボリュームのデータがすべて失われる可能性があります。スタンバイコントローラを使用

することをお勧めします。

警告：

Xsan

ボリュームに属する

LUN

で障害が発生して復元不可能な場合、 ボリューム上の

データはすべて失われます。

Xsan

ボリュームを作成する際には、冗長な

LUN

（

RAID 0

以外

の

RAID

方式に基づく

LUN

）だけを使用することを強くお勧めします。

第

2

章

ストレージ・エリア・ネットワークの計画を立てる

31

ほとんどの

RAID

システムは、一般的な

RAID

レベルすべてに対応しています。次の表に示すよ

うに、

RAID

方式ごとに、提供されるパフォーマンス、データ保護、およびストレージ効率のバ

ランスが異なります。

ボリュームの数を決定する

ボリュームは、

SAN

の共有ストレージの最も大きな単位です。ユーザがファイルへの共有アクセ

スを必要とする場合は、それらのファイルを同一のボリュームに保存する必要があります。これ

により、ユーザ間でファイルのコピーを受け渡しする必要がなくなります。

一方、セキュリティの保護が重要な場合は、クライアントアクセスを制御する

1

つの方法とし

て、複数のボリュームを作成し、アクセスを禁止したいクライアントでボリュームをマウント解

除します。

セキュリティと共有アクセスのバランスを取るより一般的な方法で、柔軟性のある妥協案として

は、

1

つのボリュームを作成し、フォルダアクセス権を使用するか「

Xsan Admin

」

（または

Mac

OS

X Server

の「サーバ管理」

）でアクセス制御リストを使用して、アクセスを制御します。

ボリュームの編成方法を決定する

定義済みのフォルダを作成することで、ユーザがボリュームのデータを編成するのを支援した

り、ユーザをボリューム内の特定の領域に制限したりできます。「

Xsan Admin

」を使ってアクセ

ス権を割り当てることによって、これらのフォルダへのアクセスを制御できます。

アフィニティを使用して、フォルダを特定のストレージプールに割り当てることができます。た

とえば、高速なアクセスを必要とするデータ用のフォルダを作成して、そのフォルダを最も高速

なストレージプールに割り当てることができます。

RAID

レベル

ストレージ効率

読み出しパフォーマ
ンス

書き込みパフォーマ
ンス

データ保護

RAID 0

最高

非常に高い

最高

なし

RAID 1

低

高

中

あり

RAID 3

高∼非常に高い

中

中

あり

RAID 5

高∼非常に高い

高

高

あり

RAID 0+1

低

高

高

あり

32

第

2

章

ストレージ・エリア・ネットワークの計画を立てる

LUN

をアフィニティタグに割り当てる

SAN

の要件に適したプリセットのボリュームタイプを使ってボリュームを作成すると、

「

Xsan

Admin

」によって、最善のパフォーマンスが得られるようにストレージプールとアフィニティタ

グが自動的に設定されます。管理者が行う必要があるのは、

LUN

を各アフィニティタグに割り当

てることだけです。

「

Xsan Admin

」では、ボリュームタイプおよび各アフィニティタグに割り当

てられた

LUN

の数に基づいて、最適なストレージプールの作成数が決定されます。最善のパ

フォーマンスを得るためには、下に示す数の倍数の

LUN

を割り当ててください。これらの倍数

は、ユーザデータに使用するアフィニティタグに適用されます。必要な

LUN

が

1

つだけである

メタデータおよびジャーナルのアフィニティタグには適用されません。

各アフィニティタグには、

同じ容量およびパフォーマンス特性を持つ

LUN

を割り当ててください。

Xsan

では、高いパフォーマンスを実現するために

RAID 0

方式を使って各ストレージプール内の

LUN

にデータをストライプするため、特定のアフィニティタグに割り当てる

LUN

の容量はすべ

て同じである必要があります。このストライピング方式では、ストレージプール内で最小の

LUN

の容量と同じだけの領域が各

LUN

で使用可能になります。

このため、ストレージプールの各

LUN

のサイズが異なる場合、容量が無駄になります。たとえば、

240 GB

の

RAID

アレイと

360 GB

の

RAID

アレイをストレージプールに割り当てる場合、容量の大きいアレイの

120 GB

は使用され

ません。特定のアフィニティタグにほぼ同じ容量の

LUN

を割り当てることで、使用可能なスト

レージを無駄にするのを避けることができます。

ユーザデータ用のアフィニティタグが複数あるボリュームタイプを使用する場合は、パフォーマ

ンスの向上が最も効果的な内容を含むフォルダに関連付けるアフィニティタグに、最も高速な

LUN

を割り当てます。

パフォーマンス要件が厳しくない内容を含むフォルダに関連付けるアフィ

ニティタグには、それよりも低速な

LUN

を割り当てます。

異なるドライブモジュールおよび異なる

RAID

コントローラで管理される

LUN

の組み合わせに

アフィニティタグを割り当てることによって、そのアフィニティタグのストレージプールのパ

フォーマンスを向上させることもできます。この方法では、データ転送の並列処理が強化される

ため、パフォーマンスが向上します。

ボリュームをマウントするクライアントを決定する

複数のボリュームを作成する場合は、どのクライアントにどのボリュームをマウントするかを決

定します。新しいボリュームは、初期状態ではすべてのクライアントにマウントされます。

「

Xsan

Admin

」を使用して、特定のクライアントからボリュームをマウント解除できます。

このボリュームタイプのユーザデータ用のアフィニティタグ

この倍数の

LUN

を割り当てる

カレンダー・サーバ・クラスタ

1

一般のファイルサーバ

2

ホームフォルダ・サーバ

2

メールクラスタ

1

Podcast Producer

クラスタ

4

SD

（

Standard Definition

）ビデオ

4

非圧縮

HD

（

High Definition

）ビデオ

4

第

2

章

ストレージ・エリア・ネットワークの計画を立てる

33

メタデータコントローラを選択する

SAN

メタデータコントローラにするコンピュータを

1

台以上選択する必要があります。

SAN

メ

タデータコントローラは、ファイルシステムのメタデータの管理を担当するコンピュータです。

参考：ファイルシステムのメタデータとジャーナルデータは、メタデータコントローラ自体では

なく、

SAN

ボリュームに保存されます。詳しくは、

33

ページの「メタデータとジャーナルデー

タの保存場所を選択する」を参照してください。

クライアントの数が少ないか、パフォーマンスがそれほど重要でない場合は、

1

つのコンピュー

タをメタデータコントローラ兼クライアントとして使用できます。

1

つのストレージ装置と、コ

ントローラ兼クライアントとして動作する

1

つのコンピュータで構成される

SAN

を設定するこ

ともできます（たとえば、ネットワークに接続したストレージとして使用できます）。

高可用性が重要である場合は、

2

台以上のメタデータコントローラを使用して、

1

台をプライマ

リコントローラに、もう

1

台をスタンバイコントローラにする必要があります。必要に応じて追

加のメタデータコントローラを指定し、各ボリュームのフェイルオーバー優先順位を設定して、

いずれかのボリュームのプライマリコントローラが応答しなくなった場合に使用されるコント

ローラの優先順序を指定できます。

パフォーマンスが重要である場合は、メタデータコントローラでほかのサーバサービスを実行し

たり、コントローラ自体を使用して

AFP

または

NFS

経由で

SAN

ボリュームを再共有しないでく

ださい。

スタンバイコントローラを選択する

SAN

ボリュームを常に使用可能にするため、プライマリ・メタデータ・コントローラに障害が発

生した場合に処理を引き継ぐスタンバイ・メタデータ・コントローラを

1

台以上設定します。

クライアントとコントローラを結合する

同じコンピュータをメタデータコントローラ兼クライアントとして機能させることができます。

たとえば、

1

つの

RAID

システムと、コントローラ兼クライアントとして動作する

1

台のコン

ピュータで構成される

SAN

を設定できます。コントローラとして指定したすべてのコンピュー

タは、クライアントとしても動作できます。

たとえば、スタンバイ・メタデータ・コントローラ専用のコンピュータがない場合は、通常はク

ライアントとして使用するコンピュータを、プライマリ・メタデータ・コントローラに障害が発

生した場合にコントローラの機能を引き継ぐように割り当てることができます。

クライアントとコントローラを別にしておくために、クライアント専用のコンピュータをユーザ
用に設定できます。

メタデータとジャーナルデータの保存場所を選択する

ボリュームについて説明するメタデータとジャーナルデータは、ボリュームのメタデータコント

ローラではなく、ボリューム自体に保存されます。デフォルトでは、これらのデータはボリュー

ム内の最初のストレージプールに保存されます。