クラスタ化におけるストレージの考慮点
Oracle ZFS Storage Appliance をクラスタで使用するようにサイズ変更する際は、さらに 2 つの考慮点が重要となります。おそらく、もっとも重要な決定は、すべてのストレージプールの所有権を同じヘッドに割り当てるか、ストレージプール間で分割するかです。ここでは、次の表に示すようなトレードオフがあります。一般に、公称動作中のスループットを最適化する場合や、フェイルオーバー後のパフォーマンスに問題がない場合を除いて、プールは単一のヘッドに構成する必要があります。フェイルオーバーした状態時のパフォーマンス特性の正確な変更は、ワークロードの性質やサイズに大きく依存します。一般に、ヘッドが特定の軸で最大パフォーマンスに近づくほど、そのヘッドのピアでワークロードをテイクオーバーしたときの、その軸におけるパフォーマンス低下が大きくなります。当然、複数のプールがある場合は、この低下が両方のワークロードに適用されます。
どちらかの構成でも、任意の ReadZilla デバイスを使用できるのは、そのデバイスが割り当てられたプールが、そのプールの所有権が割り当てられたヘッド上にインポートされている場合だけであることに注意してください。つまり、ヘッドの障害のためにプールでテイクオーバーが発生すると、インポート済みのヘッドに未使用の ReadZilla デバイスがインストールされている場合でも、そのプールでは読み取りキャッシュができなくなります。このため、「アクティブ/パッシブ」クラスタでの ReadZilla は、Chapter 5, ストレージ構成のドキュメントの説明どおりに構成する必要があります。これは、LogZilla デバイスには適用されません。このデバイスはストレージファブリックに配置され、どちらのヘッドがプールをインポートしても常にアクセス可能です。
Table 10-5 クラスタ化におけるストレージの考慮点
|
|
|
|
合計スループット (通常の操作)
|
いつでも最大で合計 CPU リソースの 50%、DRAM の 50%、および合計ネットワーク接続の 50% をサービスの提供に使用できます。この方法は単純です。単一のヘッドのみがクライアントリクエストを処理するため、他方のヘッドはアイドル状態です。
|
いつでも全 CPU および DRAM リソースをサービスの提供に使用できます。いつでも最大で全ネットワーク接続の 50% を使用できます (フェイルオーバーをサポートするには、各ヘッドにダークネットワークデバイスが必要です)。
|
|
合計スループット (フェイルオーバー)
|
公称動作に関連するスループットの変更はありません。
|
動作しているヘッドのリソースの 100% がサービスの提供に使用されます。公称動作に関連する合計スループットは、公称動作中の使用率に応じて、およそ 40% から 100% の範囲です。
|
|
I/O 待機時間 (フェイルオーバー)
|
フェイルオーバー操作中は、ReadZilla を使用できません。これにより、使用可能な読み取りキャッシュに適合する読み取りの多いワークロードの待機時間が大幅に増加する可能性があります。書き込み操作の待機時間は影響を受けません。
|
フェイルオーバー操作中は、ReadZilla を使用できません。これにより、使用可能な読み取りキャッシュに適合する読み取りの多いワークロードの待機時間が大幅に増加する可能性があります。ヘッドリソースの競合が大きくなると、読み取り操作と書き込み操作の両方の待機時間が増加する可能性があります。これは、通常のヘッドではなく、動作しているヘッドで 2 つのワークロードが実行されると発生します。各ヘッドでの公称ワークロードがヘッドの最大性能に達すると、フェイルオーバー状態の待機時間が非常に長くなる可能性があります。
|
|
ストレージ柔軟性
|
使用可能な物理ストレージはすべて、シェアおよび LUN で使用できます。
|
特定のプールに割り当てられたストレージのみが、そのプールのシェアおよび LUN で使用できます。ストレージはプール間でシェアされないため、他方のプールには空き領域があるときに 1 つのプールが満杯になると、一部のストレージが無駄になる可能性があります。
|
|
ネットワーク接続
|
各ヘッド上のすべてのネットワークデバイスを、そのヘッドがサービスを提供している間に使用できます。
|
各ヘッド上の全ネットワークデバイスの半分のみを、そのヘッドがサービスを提供している間に使用できます。したがって、物理的に別々のネットワークの半数にしか各プールを接続できません。
|
|
2 番目に重要なストレージの考慮点は、単一障害点なし (NSPF) でプール構成を使用することです。クラスタ化を使用することはアプリケーションが可用性を非常に重視することを意味するため、単一 JBOD の障害で可用性が失われるような方法でストレージプールを構成する正当な理由はほとんどありません。このアプローチの弱点は、NSPF 構成では、単一障害点ありの構成を行う場合よりも多数の JBOD が必要になる点です。必要な機能が非常に少ない場合は、目的の RAID レベルで NSPF を提供するのに十分な JBOD をインストールすることが経済的でない可能性があります。
