3.3. ストレージリソース

アプリケーションは、クラウドストレージソリューションを効果的に使用するために、基盤となるストレージサブシステムを認識する必要があります。ネイティブで利用可能なレプリケーションが利用できない場合、操作担当者は、レプリケーションサービスを提供するようにアプリケーションを設定できる必要があります。

基盤となるストレージシステムを検出できるアプリケーションは、さまざまなインフラストラクチャーで機能し、基盤となるインフラストラクチャーの違いに関係なく、同じ基本的な動作を持ちます。

入力出力パフォーマンスのベンチマークは、予想されるパフォーマンスレベルのベースラインを提供します。ベンチマーク結果データは、異なる負荷での動作をモデル化するのに役立ち、適切なアーキテクチャーを設計するのに役立ちます。

アーキテクチャーのライフサイクル中のスクリプト化されたベンチマークは、異なるタイミングでシステムの正常性を記録するのに役立ちます。スクリプト化されたベンチマークからのデータは、組織のニーズの範囲とより深い理解を支援します。

オブジェクトストレージリソースプールを設計して、オブジェクトデータに必要な可用性レベルを提供します。必要なレプリカの数に対応するように、ラックレベルとゾーンレベルの設計を検討してください。レプリカ数は 3 です。データの各レプリカは、特定のゾーンに対応する独立した電力、色付け、およびネットワークリソースを持つ個別のアベイラビリティーゾーンに存在する必要があります。

OpenStack Object Storage サービスは、特定の数のデータレプリカをリソースノード上のオブジェクトとして配置します。これらのレプリカは、クラスター内のすべてのノードに存在する一貫したハッシュリングに基づいてクラスター全体に分散されます。さらに、オブジェクトノードに保存されたデータへのアクセスを提供する Object Storage プロキシーサーバーのプールで、各アベイラビリティーゾーンにサービスを提供する必要があります。

レプリカの数に対して最低限必要な正常な応答を提供するのに十分な数のゾーンで Object Storage システムを設計します。たとえば、Swift クラスターに 3 つのレプリカを設定する場合、Object Storage クラスター内で設定するためのゾーンの推奨される数は 5 です。

より少ないゾーンでソリューションをデプロイすることはできますが、一部のデータは利用できず、クラスターに保存されている一部のオブジェクトへの API リクエストが失敗する場合があります。したがって、Object Storage クラスターのゾーンの数を考慮して、必ず考慮してください。

各リージョンのオブジェクトプロキシーは、ローカルの読み取りおよび書き込みアフィニティーを利用して、ローカルストレージリソースが可能な限りオブジェクトへのアクセスを容易にします。プロキシーサービスが複数のゾーンに分散されるようにするには、アップストリームの負荷分散をデプロイする必要があります。場合によっては、サービスの地理的な配布を支援するために、サードパーティーのソリューションが必要になる場合があります。

Object Storage クラスター内のゾーンは論理分割であり、単一のディスク、ノード、ノードのコレクション、複数のラック、または複数の DC で設定できます。利用可能な冗長なストレージシステムを提供する際に、Object Storage クラスターをスケーリングできるようにする必要があります。特定のゾーン内のストレージの設計に影響を与える可能性のあるレプリカ、保持、およびその他の要素について、異なる要件でストレージポリシーを設定する必要がある場合があります。

OpenStack Object Storage のハードウェアリソースを設計する場合の主な目標は、各リソースノードのストレージ量を最大化することを主な目標とし、さらにテラバイトあたりのコストを最小限に抑えることです。これには、多数の回転ディスクを保持できるサーバーを利用することが多くなります。2U サーバーフォームファクターを使用すると、ストレージが接続されているか、多数のドライブを保持する外部シャーシでも使用できます。

OpenStack Object Storage の一貫性とパーティション耐性の特性により、特殊なデータレプリケーションデバイスを必要とせずに、データが最新の状態に保たれ、ハードウェアの障害が維持されます。

OpenStack Object Storage は、swift リング内の重み付けとドライブを混在させ、一致する機能を提供します。swift ストレージクラスターを設計する場合は、最もコスト効果の高いストレージソリューションを使用できます。

多くのサーバーシャーシは、ラックスペースの 4U に 60 個以上のドライブを保持することができます。したがって、テラバイトあたりの最適なコストで、各ラックユニットのストレージの量を最大化できます。ただし、オブジェクトストレージノードで RAID コントローラーを使用することは推奨されません。

ストレージソリューションを設計する場合は、Object Storage サービスが必要とする最大パーティションのべき乗を決定する必要があります。これにより、作成できるパーティションの最大数が決まります。オブジェクトストレージは、データをストレージクラスター全体に分散しますが、各パーティションは複数のディスクにまたがることができません。したがって、パーティションの最大数は、ディスクの数を超えることはできません。

たとえば、最初のディスクと 3 つのパーティションのべき乗があるシステムでは、8 つのパーティション(2³)パーティションを保持できます。2 番目のディスクを追加すると、各ディスクに 4 つのパーティションを保持できます。パーティションごとの 1 つの制限は、このシステムに 8 つ以上のディスクを割り当てることができず、そのスケーラビリティが制限されることを意味します。ただし、最初のディスクと、パーティションのべき乗が 10 のシステムでは、最大 1024 (2¹⁰)パーティションを使用できます。

システムバックエンドストレージ容量を増やすと、パーティションはストレージノード全体でデータを再分散します。場合によっては、このレプリケーションは非常に大きなデータセットで設定される場合があります。このような場合は、データへのテナントアクセスと競合しないバックエンドレプリケーションリンクを使用する必要があります。

より多くのテナントがクラスター内のデータへのアクセスを開始し、データセットが増加する場合には、データアクセスリクエストにフロントエンドの帯域幅を追加する必要があります。Object Storage クラスターにフロントエンド帯域幅を追加するには、テナントがデータへのアクセスを取得できるようにするオブジェクトストレージプロキシーと、プロキシー層のスケーリングを可能にする高可用性ソリューションを設計する必要があります。

クラスター内に保存されたデータにアクセスするためにテナントとコンシューマーが使用するフロントエンド負荷分散レイヤーを設計する必要があります。この負荷分散レイヤーは、ゾーン、リージョン、または地理的な境界に分散できます。

プロキシーサーバーとストレージノードの間で要求するネットワークリソースに、帯域幅および容量を追加する必要がある場合があります。したがって、ストレージノードとプロキシーサーバーへのアクセスを提供するネットワークアーキテクチャーはスケーラブルである必要があります。

アプリケーションの 1 秒あたりの入出力(IOPS)要求により、RAID コントローラーを使用するかどうかと、必要な RAID レベルが決定されます。冗長性には、RAID 5、RAID 6 などの冗長 RAID 設定を使用する必要があります。ブロックストレージボリュームの自動レプリケーションなど、特殊な機能によっては、より高い需要に対応するためにサードパーティーのプラグインやエンタープライズブロックストレージソリューションが必要になる場合があります。

Block Storage に極端な需要がある環境では、複数のストレージプールを使用する必要があります。各デバイスプールは、そのプール内のすべてのハードウェアノードで同様のハードウェア設計とディスク設定が必要です。この設計により、アプリケーションは、さまざまな冗長性、可用性、およびパフォーマンス特性を持つさまざまな Block Storage プールにアクセスできます。

ネットワークアーキテクチャーは、インスタンスが利用可能なストレージリソースを使用するために必要な East-West 帯域幅も考慮する必要があります。選択したネットワークデバイスは、大量のデータを転送するジャンボフレームをサポートする必要があります。ネットワークリソースの負荷を軽減するために、インスタンスと Block Storage リソース間の接続を提供するために、さらに専用のバックエンドストレージネットワークを作成しないといけない場合があります。

複数のストレージプールをデプロイする場合は、リソースノード全体でストレージをプロビジョニングする Block Storage スケジューラーへの影響を考慮する必要があります。アプリケーションが、特定のネットワーク、電源、および共存するインフラストラクチャーを持つ複数のリージョンにボリュームをスケジュールできることを確認します。この設計により、テナントは複数のアベイラビリティーゾーンに分散されるフォールトトレランスアプリケーションをビルドできます。

Block Storage リソースノードに加えて、ストレージノードをプロビジョニングしてアクセスを提供する API および関連サービスの高可用性および冗長性を設計することが重要です。REST API サービスの高可用性を実現するために、ハードウェアまたはソフトウェアロードバランサーのレイヤーを設計し、中断しないサービスを提供する必要があります。

Block Storage ボリュームの状態を処理し、保存するバックエンドサービスサービスへのアクセスを提供するために、追加の負荷分散レイヤーをデプロイする必要がある場合があります。MariaDB や Galera 等の Block Storage データベースを保存するために、高可用性データベースソリューションを設計する必要があります。

Block Storage サービスは、ハードウェアベンダーが開発したプラグインドライバーを使用するエンタープライズストレージソリューションを利用できます。OpenStack Block Storage と共に追加設定なしで提供される多数のエンタープライズプラグインは、サードパーティーのチャネルで利用できます。

汎用クラウドは通常、Block Storage ノードの大部分で直接接続されたストレージを使用します。したがって、追加のレベルのサービスをテナントに提供する必要がある場合があります。これらのレベルは、エンタープライズストレージソリューションのみが提供することができます。

Block Storage プールをアップグレードして、Block Storage サービス全体を中断することなくストレージ容量を追加できます。適切なハードウェアおよびソフトウェアをインストールおよび設定して、プールにノードを追加します。次に、メッセージバスを使用して適切なストレージプールに報告するように新規ノードを設定できます。

Block Storage ノードは、スケジューラーサービスにノードの可用性を報告するため、新規ノードがオンラインになり利用可能な場合に、テナントは新しいストレージリソースをすぐに使用できます。

インスタンスからの Block Storage への要求が、利用可能なネットワーク帯域幅を使い切られる場合があります。したがって、Block Storage リソースをサービスするようにネットワークインフラストラクチャーを設計して、容量と帯域幅をシームレスに追加する必要があります。

これには、ダウンストリームデバイスに容量を追加するための動的ルーティングプロトコルまたは高度なネットワークソリューションが必要になることがよくあります。フロントエンドおよびバックエンドストレージネットワーク設計には、容量と帯域幅を迅速かつ簡単に追加する機能が含まれている必要があります。

ノードハードウェアはクラウドサービスに十分なストレージをサポートする必要があり、デプロイ後に容量を追加できるようにする必要があります。ハードウェアノードは、RAID コントローラーカードに信頼のない多数の不安価なディスクをサポートする必要があります。

また、ハードウェアベースのストレージパフォーマンスと冗長性を提供するために、ハードウェアノードも高速ストレージソリューションと RAID コントローラーカードをサポートできる必要があります。破損したアレイを自動的に修復するハードウェア RAID コントローラーを選択すると、パフォーマンスが低下したストレージデバイスまたは破棄されたストレージデバイスの置き換えおよび修復に役立ちます。

拡張性は、ストレージソリューションの主なアーキテクチャー係数です。50 PB に展開されるストレージソリューションは、10 PB まで拡張できるソリューションよりも拡張可能です。このメトリクスはスケーラビリティーとは異なります。これは、ワークロードの増加時のソリューションのパフォーマンス測定値です。

たとえば、開発プラットフォームクラウドのストレージアーキテクチャーでは、商用製品クラウドと同じ拡張性とスケーラビリティーが不要な場合があります。

オブジェクトストレージリソースノードには、ハードウェアのフォールトトレランスまたは RAID コントローラーは必要ありません。Object Storage サービスはデフォルトでゾーン間でレプリケーションを提供するため、Object Storage ハードウェアでのフォールトトレランスを計画する必要はありません。

ブロックストレージノード、コンピュートノード、およびクラウドコントローラーには、ハードウェア RAID コントローラーとさまざまなレベルの RAID 設定を使用するハードウェアレベルでフォールトトレランスを組み込む必要があります。RAID のレベルは、クラウドのパフォーマンスおよび可用性の要件と一致している必要があります。

Object Storage サービスを実行するディスクは、高速で実行されるディスクである必要はありません。したがって、ストレージのテラバイトあたりのコスト効率を最大化することができます。ただし、Block Storage サービスを実行するディスクは、高パフォーマンスの Block Storage プールを提供するために SSD またはフラッシュストレージを必要とする可能性のあるパフォーマンス重視機能を使用する必要があります。

インスタンスに使用する短期ディスクのストレージパフォーマンスも考慮する必要があります。コンピュートプールで短期的なストレージの使用率が必要な場合や、非常に高いパフォーマンスが必要な場合には、Block Storage 用にデプロイするソリューションと同様のハードウェアソリューションをデプロイする必要があります。