Red Hat Summit4.4. Storage-Focused アーキテクチャー
「Storage-Focused アーキテクチャーの考慮事項」
4.4.1. Storage-Focused アーキテクチャータイプ
クラウドストレージモデルは、データを物理ストレージデバイスの論理プールに格納します。このアーキテクチャーは、多くの場合、統合ストレージクラウドと呼ばれます。
クラウドストレージは通常、ホストされたオブジェクトストレージサービスを指します。ただし、用語には、サービスとして利用可能な他のタイプのデータストレージも含めることができます。OpenStack は、Block Storage (cinder)と Object Storage (swift)の両方を提供します。クラウドストレージは通常仮想インフラストラクチャーで実行され、インターフェイスアクセシビリティ性、スケーラビリティー、スケーラビリティー、マルチテナンシー、およびメーター化されたリソースの幅広いクラウドコンピューティングと類似しています。
オンプレミスまたはオンプレミスのクラウドストレージサービスを使用できます。クラウドストレージは冗長性とデータの分散に対して高い耐障害性があり、バージョン化されたコピーでは高い耐久性があり、一貫したデータレプリケーションを実行できます。
クラウドストレージアプリケーションの例には、以下が含まれます。
- アクティブなアーカイブ、バックアップ、および階層的なストレージ管理
- プライベートDropBox サービスなどの一般的なコンテンツのストレージと同期
- 並列ファイルシステムを使用したデータ解析
- ソーシャルメディアバックエンドストレージなどのサービス用の非構造化データストア
- 永続ブロックストレージ
- オペレーティングシステムとアプリケーションイメージストア
- メディアストリーミング
- データベース
- コンテンツ配信
- クラウドストレージピアリング
OpenStack Storage のサービスについての詳しい情報は、「OpenStack Object Storage (swift)」 および 「OpenStack Block Storage (cinder)」 を参照してください。
4.4.2. データ分析アーキテクチャー
大規模なデータセットの分析は、ストレージシステムのパフォーマンスに大きく依存します。並列ファイルシステムは、高パフォーマンスのデータ処理を提供する可能性があり、大規模なパフォーマンスに重点を置いたシステムに推奨されます。
インストールおよびデプロイメントのドキュメントは、5章デプロイメント情報 を参照してください。
4.4.2.1. 設計について
OpenStack Data Processing (sahara)は Hadoop と統合され、クラウド内の Hadoop クラスターを管理します。以下の図は、高パフォーマンスの要件を持つ OpenStack ストアを示しています。
ハードウェア要件と設定は、「高性能データベースアーキテクチャー」 で説明されている高性能アーキテクチャーと似ています。この例では、アーキテクチャーは Ceph Swift 互換の REST インターフェイスを使用してキャッシュプールに接続し、利用可能なプールの高速化を可能にします。
4.4.2.2. アーキテクチャーコンポーネント
| コンポーネント | 説明 |
|---|---|
| コンピュート | コンピュート管理およびスケジューリングサービスは、コントローラーで実行されます。Compute サービスは、各コンピュートノードでも実行されます。 |
| Dashboard | OpenStack 管理用の Web コンソール。 |
| Identity | 基本的な認証および承認機能。 |
| イメージ | インスタンスの起動およびスナップショットの管理に使用するイメージを保存します。このサービスはコントローラーで実行され、イメージの小さなセットを提供します。 |
| ネットワーク | ネットワークサービス。OpenStack Networking の詳細は、2章Networking In-Depthを参照してください。 |
| テレメトリー | 他の OpenStack サービスの監視およびレポート。このサービスを使用して、インスタンスの使用状況を監視し、プロジェクトクォータを調整します。 |
| オブジェクトストレージ | Hadoop バックエンドでデータを保存します。 |
| Block Storage | Hadoop バックエンドでボリュームを保存します。 |
| Orchestration | インスタンスおよびブロックストレージボリュームのテンプレートを管理します。このサービスを使用して、自動スケーリング用の Telemetry を使用して、ストレージ集約型処理用に追加のインスタンスを起動します。 |
4.4.2.3. クラウドの要件
| 要件 | 説明 |
|---|---|
| パフォーマンス | パフォーマンスを向上させるために、ディスクアクティビティーをキャッシュする特別なソリューションを選択できます。 |
| セキュリティー | 転送中および保管中のデータの両方を保護する必要があります。 |
| ストレージの近接性 | ハイパフォーマンスや大容量のストレージスペースを提供するには、各ハイパーバイザーに接続したり、中央のストレージデバイスから提供したりする必要がある場合があります。 |
4.4.2.4. 設計に関する考慮事項
3章設計 で説明されている基本的な設計に関する考慮事項に加えて、「Storage-Focused アーキテクチャーの考慮事項」 で説明されている考慮事項にも従う必要があります。
4.4.3. 高性能データベースアーキテクチャー
データベースアーキテクチャーは、高パフォーマンスストレージバックエンドの恩恵を受けます。エンタープライズストレージは必須ではありませんが、多くの環境には、OpenStack クラウドがバックエンドとして使用できるストレージが含まれます。
ストレージプールを作成して、インスタンスおよびオブジェクトインターフェイス用に OpenStack Block Storage をブロックデバイスに提供することができます。このアーキテクチャーの例では、データベース I/O 要件が高く、高速 SSD プールから必要なストレージがあります。
4.4.3.1. 設計について
ストレージシステムは、従来のストレージアレイで SSD のセットが対応する LUN を使用し、OpenStack Block Storage 統合または Ceph などのストレージプラットフォームを使用します。
このシステムは、追加のパフォーマンス機能を提供します。データベースの例では、SSD プールの一部が、データベースサーバーへのブロックデバイスとして機能できます。高パフォーマンス分析の例では、インライン SSD キャッシュレイヤーが REST インターフェイスを加速します。
この例では、Ceph は、分散ストレージクラスターからのブロックレベルのストレージに加えて、Swift 互換の REST インターフェイスを提供します。これは非常に柔軟であり、自己修復や自動バランシングなどの機能を備えた操作のコストを削減できます。使用可能な領域の量を最大化するために、イレイジャーコーディングされたプールを推奨します。
イレイジャーコード化されたプールには、計算要件が高く、オブジェクトで許可される操作に関する制限など、特別な考慮事項が必要です。イレイジャーコードプールは部分的な書き込みに対応していません。
4.4.3.2. アーキテクチャーコンポーネント
| コンポーネント | 説明 |
|---|---|
| コンピュート | コンピュート管理およびスケジューリングサービスは、コントローラーで実行されます。Compute サービスは、各コンピュートノードでも実行されます。 |
| Dashboard | OpenStack 管理用の Web コンソール。 |
| Identity | 基本的な認証および承認機能。 |
| イメージ | インスタンスの起動およびスナップショットの管理に使用するイメージを保存します。このサービスはコントローラーで実行され、イメージの小さなセットを提供します。 |
| ネットワーク | ネットワークサービス。OpenStack Networking の詳細は、2章Networking In-Depthを参照してください。 |
| テレメトリー | 他の OpenStack サービスの監視およびレポート。このサービスを使用して、インスタンスの使用状況を監視し、プロジェクトクォータを調整します。 |
| モニタリング | プロジェクトクォータを調整する目的で Telemetry サービスを使用し、メータリングを実行します。 |
| オブジェクトストレージ | Ceph バックエンドでデータを保存します。 |
| Block Storage | Ceph バックエンドでボリュームを保存します。 |
| Orchestration | インスタンスおよびブロックストレージボリュームのテンプレートを管理します。このサービスを使用して、自動スケーリング用の Telemetry を使用して、ストレージ集約型処理用に追加のインスタンスを起動します。 |
4.4.3.3. ハードウェアの要件
SSD キャッシュレイヤーを使用して、ブロックデバイスをハイパーバイザーに直接リンクするか、またはインスタンスにリンクすることができます。REST インターフェイスは、SSD キャッシュシステムをインラインキャッシュとして使用することもできます。
| コンポーネント | 要件 | ネットワーク |
|---|---|---|
| 10 GbE 水平的にスケーラブルなスパイン/リーフ型バックエンドストレージとフロントエンドネットワーク | ストレージハードウェア | * レイヤー 24x1 TB SSD のキャッシュ用の 5 つのストレージサーバー * サーバーごとに 12x4 TB ディスクを持つストレージサーバー 10 台。3 レプリカ後に約 160 TB の使用可能な領域の合計 480 TB に等しくなります。 |
4.4.3.4. 設計に関する考慮事項
3章設計 で説明されている基本的な設計に関する考慮事項に加えて、「Storage-Focused アーキテクチャーの考慮事項」 で説明されている考慮事項にも従う必要があります。
4.4.4. Storage-Focused アーキテクチャーの考慮事項
3章設計 で説明されている基本的な設計に関する考慮事項、「ストレージリソース」 で説明されているストレージノード設計に関する考慮事項に加えて、ストレージ集約型アーキテクチャーについては、以下の項目を考慮する必要があります。
- 接続性
- 接続がストレージソリューションの要件と一致していることを確認します。集中型ストレージアレイを選択した場合は、ハイパーバイザーをアレイに接続する方法を決定します。接続性は、レイテンシーとパフォーマンスに影響を及ぼす可能性があります。ネットワークの特性によって、設計の全体的なパフォーマンスを向上させるレイテンシーが最小限に抑えられていることを確認します。
- 密度
- インスタンスの密度ストレージ重視アーキテクチャーでは、インスタンスの密度および CPU/RAM のオーバーサブスクリプションは低くなります。特に設計でデュアルソケットハードウェア設計を使用している場合は、予想されるスケールをサポートするホストが多い必要があります。
- ホストの密度。高いホスト数に対応するには、クアッドソケットプラットフォームを使用します。このプラットフォームにより、ホストの密度が低下し、ラック数が増えます。この設定は、電源接続の数に影響し、ネットワークおよびコロケーションの要件にも影響します。
- パワーとコロリング。電源および協調密度の要件は、ブレード、sled、または 1U サーバー設計よりも 2U、3U サーバー、または 4U サーバーで低くなる場合があります。この設定は、古いインフラストラクチャーを持つデータセンターに推奨されます。
- 柔軟性
- 組織では、オンプレミスとオンプレミスのクラウドストレージオプションのいずれかを柔軟に選択できます。たとえば、運用の継続性、災害復旧、セキュリティー、および記録保持法、規制、およびポリシーは、ストレージプロバイダーのコスト効率に影響を与えます。
- レイテンシー
- ソリッドステートドライブ(SSD)は、インスタンスストレージのレイテンシーを最小限に抑え、ストレージレイテンシーが発生する可能性がある CPU の遅延を減らすことができます。コンピュートホストで RAID コントローラーカードを使用することから得点を評価し、基盤となるディスクサブシステムのパフォーマンスを向上させます。
- モニターおよびアラート
モニタリングおよびアラートサービスは、ストレージリソースへの需要が高いクラウド環境で重要です。これらのサービスは、ストレージシステムの正常性とパフォーマンスに関するリアルタイムビューを提供します。統合管理コンソール、または SNMP データを視覚化する他のダッシュボードは、ストレージクラスターの問題を検出し、解決するのに役立ちます。
ストレージ中心のクラウド設計には、以下が含まれている必要があります。
- 温度や非表示などの物理ハードウェアや環境リソースの監視。
- 利用可能なストレージ、メモリー、CPU など、ストレージリソースのモニタリング。
- 高度なストレージパフォーマンスデータを監視して、ストレージシステムが想定どおりに実行されるようにします。
- ストレージへのアクセスに影響するサービス中断についてネットワークリソースを監視する。
- 一元化されたログ収集およびログ分析機能。
- 問題を追跡するためのチケットシステム、またはチケットシステムとの統合。
- ストレージの発生時に問題を解決できる責任のあるチームまたは自動化システムのアラートと通知。
- ネットワークオペレーションセンター(NOC)スタッフは、問題を解決するために常に利用できます。
- スケーリング
- ストレージ中心の OpenStack アーキテクチャーは、スケールアウトではなく、スケールアップに集中する必要があります。コスト、電気、物理ラック、フォアスペース、サポート保証、および管理性などの要因に基づいて、より大きなホストの数を少なくするか、小さいホストの数を少なくするかを決定する必要があります。
