第3章 設計

プロセッサーのコアおよびスレッドの数は、コンピュートノードで実行可能なワーカースレッドの数に直接影響を及ぼします。このため、サービスに基づいて、全サービスでバランスの取れたインフラストラクチャーをベースとする設計を決定する必要があります。

ワークロードのプロファイルによっては、追加のコンピュートリソースをクラウドに後で追加することが可能です。特定のインスタンスのフレーバーに対する需要は、ハードウェアを個別に設計するための正当な理由にはならない場合があり、代わりにコモディティー化したシステムが優先されます。

いずれの場合も、一般的なインスタンスの要求に対応することのできるハードウェアリソースを割り当てることから設計を開始します。追加のハードウェア設計をアーキテクチャー全体に加えるには、この手順は後で実行することができます。

プロセッサーの選択は、ハードウェアの設計における非常に重要な考慮事項です。特に、異なるプロセッサー間における機能とパフォーマンスの特性を比較する際に大切となります。

プロセッサーには、仮想化コンピュートホスト専用に、ハードウェア支援による仮想化、メモリーページング、EPT シャドウイングテクノロジーなどの機能を搭載することができます。これらの機能は、クラウド仮想マシンのパフォーマンスに大きな影響を及ぼします。

オンデマンドで提供するリソースの複数のプールを割り当てる Compute の設計を使用します。この設計により、クラウド内のリソースの使用率が最大限に高められます。各リソースのプールは特定のインスタンスフレーバーまたはフレーバーグループに対応する必要があります。

複数のリソースプールを設計することにより、Compute ハイパーバイザーに対してインスタンスがスケジュールされると必ず各ノードリソースセットが割り当てられて、利用可能なハードウェアの使用率を最大限に高めるのに役立ちます。これは一般的にはビンパッキングと呼ばれます。

リソースプール内のノード間で一貫したハードウェア設計を採用すると、ビンパッキングにも役立ちます。Compute リソースプールに選択されたハードウェアノードは、共通のプロセッサー、メモリー、およびストレージレイアウトを共有する必要があります。共通のハードウェア設計を選択することにより、デプロイメント、サポート、ノードのライフサイクル管理が容易になります。

OpenStack では、コンピュートノードの CPU とメモリーをオーバーコミットすることができます。これは、クラウド内で実行するインスタンスの数を増やすのに役立ちます。ただし、オーバーコミットにより、インスタンスのパフォーマンスが低下する場合があります。

オーバーコミット比とは、利用可能な物理リソースと比較した利用可能な仮想リソースの比率です。

CPU およびメモリーのオーバーコミット比は、コンピュートノードのハードウェアレイアウトに直接影響を及ぼすので、設計フェーズ中にチューニングしておくことが重要となります。Compute のリソースプールのようなインスタンスにサービスを提供するためのハードウェアノードを設計する際には、ノードで利用可能なプロセッサーコアの数とともに、フルキャパシティーで稼働するインスタンスにサービスを提供するのに必要なディスクとメモリーも考慮してください。

たとえば、m1.small のインスタンスは、1 仮想 CPU、20 GB の一時ストレージ、2048 MB のメモリーを使用します。10 コアの CPU が 2 つあり、ハイパースレッディングが有効化されたサーバーの場合には、次のようになります。

メモリーでノードのサイズ指定する際には、オペレーティングシステムとサービスのニーズに対応する必要な追加メモリーを考慮することも重要です。

単一のラックユニットを占有する 1U ラックマウント型サーバーは、ブレードサーバーのソリューションよりもサーバーの密度が高い場合があります。1 ラックに 1U サーバーを 40 ユニット使用して、Top-of-Rack (ToR) スイッチ用のスペースを提供することができます。これに対して、フルワイドのブレードサーバーは、1 ラックで 32 台しか使用することができません。

ただし、大手ベンダーの 1U サーバーは、デュアルソケット、マルチコアの CPU 設定のみとなっており、1U ラックマウントのフォームファクターでそれよりも高い CPU 設定をサポートするには、ODM (相手先ブランド設計製造業者) または二次製造業者からシステムを購入してください。

スレッドサーバーは、ラックマウント型のサーバーで、複数の独立したサーバーを単一の 2U または 3U 筐体でサポートします。これらのサーバーは、通常の 1U または 2U のラックマウント型サーバーよりも高い密度を提供します。

たとえば、多くのスレッドサーバーは、2U で 4 つの独立したデュアルノードを提供し、合計 CPU ソケットは 8 となります。ただし、各ノードがデュアルソケットに制限されているため、追加のコストや設定の複雑さを補うには十分でない可能性があります。

クラウドストレージソリューションを効果的に使用するには、アプリケーションが下層のストレージサブシステムを認識する必要があります。ネイティブで利用可能なレプリケーションが使用できない場合には、オペレーターがアプリケーションを設定してレプリケーションサービスを提供するようにできる必要があります。

下層のストレージシステムを検出できるアプリケーションは、多様なインフラストラクチャーで機能することが可能です。インフラストラクチャーの違いにかかわらず、基本的な操作は変わりません。

入出力パフォーマンスのベンチマークは、予想されるパフォーマンス水準のベースラインを提供します。ベンチマークの結果データは、異なる負荷がかかった状態の動作をモデリングして、適切なアーキテクチャーを設計するのに役立ちます。

アーキテクチャーのライフサイクル中には、異なる時点におけるシステムの健全性を記録するのに、より小さな、スクリプト化されたベンチマークが役立ちます。スクリプト化されたベンチマークから取得したデータは、スコープを定義し、組織のニーズをより深く理解するのに役立ちます。

対象となるオブジェクトデータに必要な可用性レベルを提供するオブジェクトストレージリソースプールを設計します。必要なレプリカ数に対応するラックレベルとゾーンレベルの設計を考慮してください。デフォルトのレプリカ数は 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 以上のドライブを収容することができます。このため、テラバイトあたりのコストを最低限に抑えて、ストレージの容量を最大化することができます。ただし、Object Storage ノードには、RAID コントローラーの使用はお勧めできません。

ストレージソリューションを設計する際には、Object Storage サービスが必要とする partition power を決定した上で作成可能なパーティション数を決定します。Object Storage は全ストレージクラスターデータを分散しますが、各パーティションは複数のディスクにまたがることはできないので、最大パーティション数は、ディスクの数より大きくすることはできません。

たとえば、最初のディスクが 1 つと partition power が 3 のシステムの場合には 8 パーティション (2³) を設けることができます。2 番目のディスクを追加すると、各ディスクに 4 パーティションに分割できることになります。1 パーティションにつき 1 ディスクの制限により、このシステムでは、8 よりも多いディスクを使用できず、スケーラビリティーが制限されますが、最初のディスクが 1 つで partition power が 10 のシステムでは、最大で 1024 (2¹⁰) パーティションを設けることができます。

システムバックエンドストレージの容量を増やす場合には必ず、パーティションマップが全ストレージノードにデータを再分散します。このレプリケーションは極めて大量のデータセットで構成されることがあり、その場合には、テナントからのデータへのアクセスと競合が発生しないバックエンドレプリケーションリンクを使用すべきです。

より多くのテナントがクラスター内でデータにアクセスし、データセットが拡大している場合には、フロントエンドの帯域幅を追加して、データアクセス要求に対応できるようにする必要があります。Object Storage クラスターに フロントエンドの帯域幅を追加するには、テナントがデータへのアクセスに使用できる Object Storage プロキシーとともに、プロキシー層のスケーリングを可能にする高可用性ソリューションを設計する必要があります。

テナントとコンシューマーがクラスター内に保管されているデータにアクセスするために使用するフロントエンドの負荷分散層を設計するべきです。この負荷分散層は、複数のゾーン/リージョンにわたって、あるいは地理的な境界を越えても分散することができます。

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

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

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 までにしか拡張できないソリューションよりも拡張性が高いと見なされます。このメトリックは、ワークロードの増加に応じたソリューションのパフォーマンスの尺度であるスケーラビリティーとは異なります。

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

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

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

Object Storage サービスを実行するディスクは、高速なパフォーマンスのディスクである必要はありません。このため、ストレージのテラバイトあたりの費用対効果を最大限に高めることができます。ただし、Block Storage サービスを実行するディスクには、パフォーマンスを強化する機能を使用すべきです。これには、 高パフォーマンスの Block Storage プールを提供するための SSD やフラッシュストレージが必要な場合があります。

インスタンス用に短期間使用するディスクのストレージパフォーマンスも考慮すべきです。コンピュートプールに高使用率の短期ストレージが必要な場合や、極めて高いパフォーマンスが要求される場合には、Block Storage 用にデプロイするのを同様のハードウェアソリューションをデプロイすべきです。

ネットワークサービスを分離し、トラフィックが不要な場所を経由せずに正しい送信先に流れるようにします。

以下に例示する要素を考慮してください。

ネットワークをハイパーバイザーにアタッチする方法により、セキュリティーの脆弱性にさらされる場合があります。ハイパーバイザーのセキュリティーホールが悪用されるリスクを軽減するには、他のシステムからのネットワークを分離して、 そのネットワークのインスタンスは専用のコンピュートノードにスケジューリングします。このような分離により、セキュリティーが侵害されたインスタンスから攻撃者がネットワークに侵入するのを防ぎます。

クラウドネットワークを設定して、ベンダー固有の機能を利用するとリスクが高くなる可能性があります。

たとえば、マルチリンクアグリゲーション (MLAG) を使用して、ネットワークのアグリゲータースイッチレベルで冗長性を提供します。MLAG は標準のアグリゲーション形式ではなく、各ベンダーが機能の専用フレーバーを実装しています。MLAG アーキテクチャーは、全スイッチベンダー間で相互運用可能ではないため、ベンダーロックインに陥り、ネットワークコンポーネントのアップグレード時に遅延や問題が発生する場合があります。

クラウドノードのアクセスが中断されないようにするには、ネットワークアーキテクチャーで単一障害点を特定し、適切な冗長性や耐障害性を提供する必要があります。

どのような設計にも、必要なポートを備えたネットワーク用ハードウェアが必要です。