Red Hat Summit第4章 アーキテクチャー例
本章では、Red Hat OpenStack Platform デプロイメントのアーキテクチャー例のリファレンスを記載します。
アーキテクチャー例はすべて、KVM ハイパーバイザーを使用する Red Hat Enterprise Linux 7.3 上に OpenStack Platform をデプロイすることを前提とします。
4.1. 概要
通常、デプロイメントはパフォーマンスまたは機能性をベースにします。デプロイメントは、デプロイするインフラストラクチャーをベースにすることもできます。
| 例 | 説明 |
|---|---|
|
特定の技術的または環境の要件が不明な場合に使用する一般的な高可用性クラウド。このアーキテクチャータイプは、柔軟性が高く、単一の OpenStack コンポーネントを重視しているわけではないので、特定の環境に制限されません。 | |
|
Hadoop クラスターなどの大量のデータの管理/分析向けに設計された、パフォーマンス重視のストレージシステム 。このアーキテクチャータイプでは、OpenStack は Hadoop と統合し、Ceph をストレージバックエンドとして使用して Hadoop クラスターを管理します。 | |
|
データベースの IO 要件が高いことを想定し、ソリッドステートドライブ (SSD) を使用してデータを処理するハイパフォーマンスストレージシステム。このアーキテクチャータイプは、既存のストレージ環境に使用することができます。 | |
|
OpenStack デプロイメントで一般的に使用されているクラウドベースのファイルストレージ/共有サービス。このアーキテクチャータイプは、クラウドトラフィックの受信データが送信データを上回る場合にクラウドバックアップアプリケーションを使用します。 | |
|
大規模な Web アプリケーション向けのハードウェアベースのロードバランシングクラスター。このアーキテクチャータイプは、SSL オフロード機能を提供し、テナントネットワークに接続してアドレスの消費を低減し、Web アプリケーションを水平スケーリングします。 |
4.2. 汎用アーキテクチャー
具体的な技術/環境のニーズが不明な場合には、汎用の高可用性クラウドをデプロイすることができます。この柔軟なアーキテクチャータイプは、単一の OpenStack コンポーネントを重視していないので、特定の環境には制限されません。
このアーキテクチャータイプは、以下を含む潜在的なユースケースの 80% に対応します。
- シンプルなデータベース
- Web アプリケーションランタイム環境
- 共有アプリケーション開発環境
- テスト環境
- スケールアップ型ではなくスケールアウト型の拡張を必要とする環境
このアーキテクチャータイプは、高度なセキュリティーを必要とするクラウドドメインには推奨されません。
インストールおよびデプロイメントに関する説明は、「5章デプロイメントの情報」を参照してください。
4.2.1. ユースケースの例
あるインターネット広告会社では、Apache Tomcat、Nginx、MariaDB を含む Web アプリケーションをプライベートクラウドで実行することを検討しています。ポリシー要件を満たすために、クラウドインフラストラクチャーはその会社のデータセンター内で稼働します。
同社は、予想可能な負荷の要件がありますが、毎晩の需要拡大に対応するためのスケーリングを必要としています。現在の環境には、オープンソースの API 環境を稼働するという同社の目標に対応するための柔軟性がありません。
現在の環境は以下のコンポーネントで構成されています。
- Nginx および Tomcat をインストールしたシステムが 120 - 140。各システムには 2 つの仮想 CPU と 4 GB のメモリーを搭載。
- 3 ノードの MariaDB および Galera のクラスター。それぞれ 4 つの仮想 CPU と 8 GB のメモリーを搭載。Galera ノードの管理には Pacemaker を使用。
同社は、ハードウェアロードバランサーと、Web サイトにサービスを提供する複数の Web アプリケーションを実行しています。環境のオーケストレーションには、スクリプトと Puppet を併用しています。Web サイトはアーカイブが必要な大量のログデータを毎日生成します。
4.2.2. 設計について
この例のアーキテクチャーには、3 つのコントローラーノードと、少なくとも 8 つの Compute ノードが含まれます。静的オブジェクトには OpenStack Object Storage を、その他すべてのストレージニーズには OpenStack Block Storage を使用します。
OpenStack インフラストラクチャーの高可用性を確保するために、ノードは Red Hat Enterprise Linux 用の Pacemaker アドオンと HAProxy を併用します。
このアーキテクチャーには以下のコンポーネントが含まれます。
- 一般向けのネットワーク接続用のファイアウォール、スイッチ、ハードウェアロードバランサー
- Image、Identity、Networking を実行する OpenStack コントローラーサービスにサポートサービスとして MariaDB と RabbitMQ を組み合わせます。これらのサービスは、少なくとも 3 つのコントローラーノード上で高可用性に設定されます。
- クラウドノードは、Red Hat Enterprise Linux 用の Pacemaker アドオンとともに高可用性に設定されます。
- Compute ノードは、永続ストレージが必要なインスタンスに OpenStack Block Storage を使用します。
- OpenStack Object Storage はイメージなどの静的オブジェクトに対応します。
4.2.3. アーキテクチャーコンポーネント
| コンポーネント | 説明 |
|---|---|
|
Block Storage |
インスタンス用の永続ストレージ |
|
Compute コントローラーサービス |
Compute の管理とコントローラー上で実行するサービスのスケジューリング |
|
Dashboard |
OpenStack の管理用 Web コンソール |
|
Identity |
ユーザーおよびテナントの基本的な認証と承認 |
|
Image |
インスタンスの起動とスナップショットの管理に使用するイメージを保管します。 |
|
MariaDB |
全 OpenStack コンポーネント用のデータベース。MariaDB サーバーインスタンスは、NetApp や Solidfire などの共有エンタープライズストレージ上のデータを保管します。MariaDB インスタンスに障害が発生した場合には、ストレージは再度他のインスタンスにアタッチして Galera クラスターに再び参加させる必要があります。 |
|
ネットワーク |
プラグインと Networking API を使用してハードウェアバランサーを制御します。OpenStack Object Storage を拡張する場合には、ネットワーク帯域幅の要件を考慮する必要があります。OpenStack Object Storage は、ネットワーク接続スピードが 10 GbE 以上で実行することを推奨します。 |
|
Object Storage |
Web アプリケーションサーバーからのログを処理し、アーカイブします。また、Object Storage を使用して静的な Web コンテンツを OpenStack Object Storage コンテナーから移動したり、または OpenStack Image で管理されているイメージをバックアップすることもできます。 |
|
Telemetry |
その他の OpenStack サービスのモニタリングとレポーティング |
4.2.4. Compute ノードの要件
Compute サービスは、各 Compute ノードにインストールされます。
この汎用アーキテクチャーでは、最大で 140 の Web インスタンスを実行可能で、少数の MariaDB インスタンスに 292 の仮想 CPU と 584 GB のメモリーが必要です。ハイパースレッディング対応で、デュアルソケット、ヘキサコア の Intel CPU を搭載した標準的な 1U サーバーで、2:1 CPU オーバーコミット比を前提とする場合、このアーキテクチャーには 8 Compute ノードが必要です。
Web アプリケーションインスタンスは、各 Compute ノードのローカルストレージから起動します。Web アプリケーションインスタンスはステートレスなので、いずれか 1 つのインスタンスにエラーが発生した場合でも、アプリケーションは実行を継続することができます。
4.2.5. ストレージ要件
ストレージには、サーバーにストレージを直接アタッチする、スケールアウト型ソリューションを使用します。たとえば、グリッドコンピューティングソリューションと同様の方法でコンピュートホストにストレージを追加したり、ブロックストレージのみを提供する専用のホストに追加することが可能です。
コンピュートホストにストレージをデプロイする場合には、ハードウェアがストレージとコンピュートのサービスを処理できることを確認してください。
4.3. ストレージを重視したアーキテクチャー
4.3.1. ストレージを重視したアーキテクチャーのタイプ
クラウドストレージモデルでは、物理ストレージデバイス上の論理プールにデータを保管します。このアーキテクチャーは、統合ストレージクラウドと呼ばれる場合もよくあります。
クラウドストレージは、一般的にはホストされたオブジェクトストレージサービスのことを指しますが、この用語には、サービスとして利用可能なその他のタイプのデータストレージも含まれる場合があります。OpenStack は Block Storage (cinder) と Object Storage (swift) の両方を提供しています。クラウドストレージは通常仮想化インフラストラクチャー上で実行され、インターフェースのアクセス可能性、弾力性、スケーラビリティー、マルチテナンシー、従量制課金リソースなどの面で、より広範なクラウドコンピューティングと似ています。
クラウドストレージサービス、オンプレミスまたはオフプレミスで使用することができます。クラウドストレージは冗長性とデータの分散によって耐障害性が高く、またバージョン付きコピーを使用することで高い持続性を提供し、一貫したデータレプリケーションを実行することが可能です。
クラウドストレージアプリケーションには以下のような例があります。
- アクティブなアーカイブ、バックアップ、階層型ストレージ管理
- 一般的なコンテンツストレージと同期 (例: プライベートのドロップボックスサービス)
- 並列ファイルシステムによるデータ分析
- サービス向けの非構造データストア (例: ソーシャルメディアのバックエンドストレージ)
- 永続的なブロックストレージ
- オペレーティングシステムとアプリケーションイメージストア
- メディアのストリーミング
- データベース
- コンテンツの配信
- クラウドストレージピアリング
OpenStack ストレージサービスについての詳しい情報は、「OpenStack Object Storage (swift)」および「OpenStack Block Storage (cinder)」の項を参照してください。
4.3.2. データ分析アーキテクチャー
大量のデータセットの分析は、ストレージシステムのパフォーマンスに大きく左右されます。並列ファイルシステムは、ハイパフォーマンスのデータ処理を提供することができるので、パフォーマンスを重視した大規模なシステムに推奨されます。
インストールおよびデプロイメントに関する説明は、「5章デプロイメントの情報」を参照してください。
4.3.2.1. 設計について
OpenStack Data Processing (sahara) は Hadoop と統合してクラウド内の Hadoop クラスターを管理します。以下の図には、ハイパフォーマンス要件の OpenStack ストアを示しています。
ハードウェア要件と設定は、「ハイパフォーマンスデータベースアーキテクチャー」に記載のハイパフォーマンスアーキテクチャーと似ています。この例では、アーキテクチャーは、キャッシュプールに接続して利用可能なプールを加速することができる Ceph の Swift 対応 REST インターフェースを使用します。
4.3.2.2. アーキテクチャーコンポーネント
| コンポーネント | 説明 |
|---|---|
|
Compute |
Compute の管理およびスケジューリングサービスは、コントローラー上で実行されます。Compute サービスは、各コンピュートノード上でも実行されます。 |
|
Dashboard |
OpenStack の管理用 Web コンソール |
|
Identity |
基本的な認証と承認 |
|
Image |
インスタンスの起動とスナップショットの管理に使用するイメージを保管します。このサービスは、コントローラーを実行して少量のイメージセットを提供します。 |
|
ネットワーク |
ネットワークサービス。OpenStack Networking についての詳しい情報は、「2章ネットワークに関する詳細」を参照してください。 |
|
Telemetry |
その他の OpenStack サービスのモニタリングとレポーティング。このサービスは、インスタンスの使用状況のモニタリングとプロジェクトクォータの調整に使用します。 |
|
Object Storage |
Hadoop バックエンドでデータを保管します。 |
|
Block Storage |
Hadoop バックエンドでボリュームを保管します。 |
|
Orchestration |
インスタンスおよびブロックストレージボリューム用のテンプレートを管理します。ストレージを集中的に使用する処理用に追加のインスタンスを起動し、自動的にスケーリングするには、このサービスを Telemetry と共に使用します。 |
4.3.2.3. クラウドの要件
| 要件 | 説明 |
|---|---|
|
パフォーマンス |
パフォーマンスを強化するには、ディスクアクティビティーをキャッシュする特別なソリューションを選択することができます。 |
|
セキュリティー |
伝送中のデータと保存されているデータの両方を保護する必要があります。 |
|
ストレージの近接性 |
ハイパフォーマンスまたは大容量のストレージスペースを提供するには、各ハイパーバイザーにストレージをアタッチするか、中央ストレージデバイスからサービスを提供する必要がある可能性があります。 |
4.3.2.4. 設計の考慮事項
「3章設計」に記載した基本的な設計の考慮事項に加えて、「ストレージを重視したアーキテクチャーの考慮事項」に記載の考慮事項にも従うべきです。
4.3.3. ハイパフォーマンスデータベースアーキテクチャー
データベースアーキテクチャーは、ハイパフォーマンスのストレージバックエンドのメリットを享受します。エンタープライズストレージは必須ではありませんが、多くの環境には、OpenStack クラウドでバックエンドとして使用可能なストレージが含まれます。
ストレージプールを作成して、OpenStack Block Storage でインスタンスおよびオブジェクトインターフェース用にブロックデバイスを提供することができます。このアーキテクチャーの例では、データベースの入出力要件が高く、高速な SSD プールからのストレージが要求されます。
4.3.3.1. 設計について
このストレージシステムは、従来のストレージアレイで、SSD のセットによりバッキングされた LUN を使用し、OpenStack Block Storage の統合または Ceph などのストレージプラットフォームを採用します。
このシステムは、追加のパフォーマンス機能を提供することが可能です。データベースの例では、以下のデータベース例では、SSD プールの一部がデータベースサーバーに対するブロックデバイスとして機能します。ハイパフォーマンスの分析例では、インライン SSD キャッシュ層が REST インターフェースを加速化します。
この例では、Ceph が Swift 対応の REST インターフェースを提供するとともに、分散ストレージクラスターからのブロックレベルストレージも提供します。これは、柔軟性が非常に高い上、自己復旧や自動バランシングなどの機能により、運用コストを削減することができます。イレイジャーコーディング対応プールは、使用可能な容量を最大化するのに推奨されます。
イレイジャーコーディング対応プールには、より高いコンピューティング要件やオブジェクトに許可される操作の制限などを特別に考慮する必要があります。イレイジャーコーディング対応プールは、部分的書き込みはサポートしません。
4.3.3.2. アーキテクチャーコンポーネント
| コンポーネント | 説明 |
|---|---|
|
Compute |
Compute の管理およびスケジューリングサービスは、コントローラー上で実行されます。Compute サービスは、各コンピュートノード上でも実行されます。 |
|
Dashboard |
OpenStack の管理用 Web コンソール |
|
Identity |
基本的な認証と承認 |
|
Image |
インスタンスの起動とスナップショットの管理に使用するイメージを保管します。このサービスは、コントローラーを実行して少量のイメージセットを提供します。 |
|
ネットワーク |
ネットワークサービス。OpenStack Networking についての詳しい情報は、「2章ネットワークに関する詳細」を参照してください。 |
|
Telemetry |
その他の OpenStack サービスのモニタリングとレポーティング。このサービスは、インスタンスの使用状況のモニタリングとプロジェクトクォータの調整に使用します。 |
|
モニタリング |
Telemetry サービスプロジェクトクォータを調整する目的の計測を実行します。 |
|
Object Storage |
Ceph バックエンドでデータを保管します。 |
|
Block Storage |
Ceph バックエンドでボリュームを保管します。 |
|
Orchestration |
インスタンスおよびブロックストレージボリューム用のテンプレートを管理します。ストレージを集中的に使用する処理用に追加のインスタンスを起動し、自動的にスケーリングするには、このサービスを Telemetry と共に使用します。 |
4.3.3.3. ハードウェア要件
SSD キャッシュ層を使用して、ブロックデバイスを直接ハイパーバイザーやインスタンスにリンクすることができます。REST インターフェースもインラインキャッシュとして SSD キャッシュシステムを使用することが可能です。
| コンポーネント | 要件 | ネットワーク |
|---|---|---|
|
10 GbE の水平スケーリングが可能なリーフ/スパイン型バックエンドストレージおよびフロントエンドネットワーク |
ストレージハードウェア |
* 24x1 TB SSD を搭載したストレージサーバー (キャッシュ層用) 5 台 * 1 台あたり 12x4 TB のディスクを搭載したストレージサーバー 10 台。合計の容量は 480 TB に相当。レプリカを 3 回作成後の使用可能な空き容量は約 160 TB。 |
4.3.3.4. 設計の考慮事項
「3章設計」に記載した基本的な設計の考慮事項に加えて、「ストレージを重視したアーキテクチャーの考慮事項」に記載の考慮事項にも従うべきです。
4.3.4. ストレージを重視したアーキテクチャーの考慮事項
ストレージ集約型のアーキテクチャーには、基本的な設計の考慮事項 (「3章設計」) とストレージノードの設計 (「ストレージのリソース」) に加えて、以下の項目を検討すべきです。
- 接続性
- 接続性がストレージソリューションの要件に対応していることを確認します。一元管理されたストレージアレイを選択する場合には、ハイパーバイザーがアレイにどう接続するかを決定します。接続性は、レイテンシーおよびパフォーマンスに影響する場合があるので、ネットワークの特性がレイテンシーを最小限に抑え、設計の全体的なパフォーマンスを高めるようにします。
- 密度
- インスタンスの密度。ストレージを重視したアーキテクチャーでは、インスタンスの密度と、CPU/メモリーのオーバーサブスクリプション比は低くなります。設計にデュアルソケットハードウェアを使用している場合には特に、予想されるスケールをサポートするホストがより多く必要になります。
- ホストの密度。クワッドソケットプラットフォームを使用することにより、ホスト数が多い構成に対応できます。このプラットフォームでは、ホストの密度を低くなり、ラック数が増えます。この構成は、電源接続数に加えて、ネットワークや冷却の要件にも影響を及ぼします。
- 電源と冷却。2U、3U、4U サーバーの電源および冷却の密度の要件は、ブレード、スレッド、1U サーバー設計よりも低い可能性があります。この構成は、より古いインフラストラクチャーを使用するデータセンターに推奨されます。
- 柔軟性
- 組織は、オフプレミスとオンプレミスのクラウドストレージオプションのいずれかを選択する柔軟性を必要とします。たとえば、運用の継続性、障害復旧、セキュリティー、記録の保管に関する法律、規制、ポリシーなどは、ストレージプロバイダーの費用対効果に影響を及ぼす場合があります。
- レイテンシー
- ソリッドステートドライブ (SSD) は、インスタンスのストレージのレイテンシーを最小限に抑え、ストレージのレイテンシーによって生じる場合のある CPU の遅延を低減することができます。下層のディスクシステムのパフォーマンスを向上させるためにコンピュートホストで RAID コントローラーカードを使用することによるメリットを評価します。
- 監視と警告
監視と警告のサービスは、ストレージリソースに対する需要の高いクラウド環境では極めて重要です。これらのサービスは、ストレージシステムの正常性とパフォーマンスのリアルタイムのビューを提供します。統合管理コンソール、または SNMP データを視覚化するその他のダッシュボードは、ストレージクラスター内で発生した問題の発見と解決に役立ちます。
ストレージを重視したクラウド設計には以下の要素が含まれるべきです。
- 物理ハードウェアと環境リソース 監視 (例: 温度、湿度)
- 使用可能なストレージ、メモリー、CPU などのストレージリソースの監視
- ストレージシステムが想定通りのパフォーマンスを達成していることを確認するための詳細なストレージパフォーマンスデータの監視
- ストレージへのアクセスに影響するサービス停止をチェックするためのネットワークリソースの監視
- 一元化されたログ収集とログ分析の機能
- 問題追跡のためのチケットシステムまたはチケットシステムとの統合
- 担当チームへの警告と通知、またはストレージに伴う問題が発生した際に解決することができる自動システム
- スタッフを配置し、問題解決に常時対応可能なネットワーク運用センター (NOC)
- スケーリング
- ストレージを重視した OpenStack アーキテクチャーは、スケールアウトではなく、スケールアップにフォーカスすべきです。コスト、電源、冷却、物理ラック、床面積、サポート/保証、管理容易性などの要素に基づいて、少数の大型ホストの構成にするか、多数の小型ホストの構成にするかを決定する必要があります。
4.4. ネットワークを重視したアーキテクチャー
「大規模な Web アプリケーション向けのアーキテクチャー」
4.4.1. ネットワークを重視したアーキテクチャーのタイプ
OpenStack デプロイメントすべて、サービスをベースとしているので、適切に機能するには、ネットワーク通信に依存します。ただし、場合によっては、ネットワーク設定はよりクリティカルで設計における追加の考慮事項が必要です。
以下の表では、ネットワークを重視した一般的なアーキテクチャーについての説明をまとめています。このようなアーキテクチャーは、ユーザーとアプリケーションの要件を満たす、信頼できるネットワークインフラストラクチャーとサービスに依存します。
| アーキテクチャー | 説明 |
|---|---|
|
ビッグデータ |
ビッグデータの管理/収集に使用されるクラウドは、ネットワークリソースに対して多大な需要をもたらします。ビッグデータは、多くの場合、データの部分的なレプリカを使用して、大型の分散型クラウドの整合性を維持します。大量のネットワークリソースを必要とするビッグデータアプリケーションには Hadoop、Cassandra、NuoDB、Riak、その他の SQL 以外の分散データベースがあります。 |
|
コンテンツ配信ネットワーク (CDN) |
CDN は、多数のエンドユーザーによるビデオのストリーミングや、写真の閲覧、Web コンファレンスのホスティング、分散されたクラウドベースのデータリポジトリーへのアクセスに使用することができます。ネットワーク設定は、レイテンシー、帯域幅、インスタンスの分散に影響を及ぼします。コンテンツの配信とパフォーマンスに影響するその他の要素には、バックエンドシステムのネットワークスループット、リソースの場所、WAN アーキテクチャー、キャッシュの方法などがあります。 |
|
高可用性 (HA) |
高可用性の環境は、サイト間のデータレプリケーションを維持するネットワークのサイズに左右されます。1 つのサイトが利用不可になった場合に、そのサイトのサービスが復旧するまで、他のサイトが増えた分の負荷に対応することができます。追加の負荷を処理できるネットワーク容量にサイズを設定することが重要です。 |
|
ハイパフォーマンスコンピューティング (HPC) |
HPC 環境には、クラウドクラスターのニーズに対応するためのトラフィックフローと使用パターンをさらに考慮する必要があります。HPC は、ネットワーク内の分散コンピューティングのための水平方向 (east-west) のトラフィックパターンが高いですが、アプリケーションによっては、ネットワークに出入りする垂直方向 (north-south) のトラフィックも相当な量となる場合があります。 |
|
高スピードまたは高容量のトランザクションシステム |
このようなタイプのアプリケーションは、ネットワークジッターとレイテンシーの影響を受けます。環境の例としては、財務システム、クレジットカード取引用アプリケーション、商取引用のシステムなどがあります。これらのアーキテクチャーは、高ボリュームの水平方向と垂直方向のトラフィックのバランスを取って、データ配信の効率性を最大限に高める必要があります。このようなシステムの多くは、大型でハイパフォーマンスのデータベースバックエンドにアクセスしなければなりません。 |
|
ネットワーク管理機能 |
DNS、NTP、SNMP などのバックエンドネットワークサービスの配信をサポートする環境。これらのサービスは、内部ネットワークの管理に使用することができます。 |
|
ネットワークサービスオファリング |
サービスをサポートするための顧客向けネットワークツールを実行する環境。VPN、MPLS プライベートネットワーク、GRE トンネルなどがその例です。 |
|
仮想デスクトップインフラストラクチャー (VDI) |
VDI は、ネットワークの輻輳、レイテンシー、ジッターの影響を受けます。VDI にはアップストリームとダウンストリームの両方のトラフィックが必要で、キャッシュに依存してアプリケーションをエンドユーザーに提供することはできません。 |
|
Voice over IP (VoIP) |
VoIP システムは、ネットワークの輻輳、レイテンシー、ジッターの影響を受けます。VoIP システムには、対称的なトラフィックパターンがあり、最適なパフォーマンスを提供するにはネットワーク QoS が必要です。また、アクティブなキュー管理を実装して、音声およびマルチメディアのコンテンツを配信することができます。ユーザーは、レイテンシーとジッターの変動の影響を受け、非常に低いレベルでそれらを検知することができます。 |
|
ビデオまたは Web コンファレンス |
コンファレンスシステムは、ネットワークの輻輳、レイテンシー、ジッターの影響を受けます。ビデオコンファレンスシステムには、対称的なトラフィックパターンがありますが、ネットワークが MPLS プライベートネットワークでホストされていない場合には、システムはネットワーク QoS を使用してパフォーマンスを向上させることはできません。VoIP と同様に、このシステムのユーザーは低いレベルでもネットワークパフォーマンス問題を検知します。 |
|
Web ポータル/サービス |
Web サーバーは、クラウドサービスにおける共通のアプリケーションなので、そのネットワーク要件を理解する必要があります。ネットワークは、ユーザーの需要を満たし、最小の待ち時間で Web ページを配信するためのスケールアウトが必要です。アーキテクチャーを計画する際には、ポータルのアーキテクチャー詳細に応じて、内部の水平/垂直方向のネットワーク帯域幅を検討すべきです。 |
4.4.2. クラウドのストレージとバックアップのアーキテクチャー
このアーキテクチャーは、ファイルストレージおよびファイル共有を提供するクラウドが対象です。これはストレージを重視したユースケースと見なされる場合がありますが、ネットワーク側の要件によりネットワークを重視したユースケースとなります。
インストールおよびデプロイメントに関する説明は、「5章デプロイメントの情報」を参照してください。
4.4.2.1. 設計について
以下のクラウドバックアップアプリケーションのワークロードには、ネットワークに影響を及ぼす 2 つの特定の動作があります。
このワークロードには、外部向けのサービスと内部でレプリケーションを行うアプリケーションが含まれ、どちらも垂直/水平方向のトラフィックを考慮する必要があります。
- 垂直方向のトラフィック
垂直方向のトラフィックは、クラウドに出入りするデータで構成されます。ユーザーがコンテンツをアップロードして保管すると、そのコンテンツは OpenStack 環境の中に入ります (下向き)。ユーザーがコンテンツをダウンロードすると、そのコンテンツは OpenStack 環境の外に移動します (上向き)。
このサービスは、主にバックアップサービスとして稼働するので、トラフィックの大半は環境の内部に移動します。このような状況では、OpenStack 環境の入ってくるトラフィックが環境から出て行くトラフィックよりも大きくなるため、ネットワークを非対称的なダウンストリームに設定すべきです。
- 水平方向のトラフィック
- 水平方向のトラフィックは、環境内を移動するデータで構成されます。レプリケーションは任意のノードで開始し、アルゴリズムによって複数の他のノードをターゲットとする場合があるので、このようなトラフィックは、完全に対称的となる傾向があります。ただし、このトラフィックは、垂直方向のトラフィックに干渉する場合があります。
4.4.2.2. アーキテクチャーコンポーネント
| コンポーネント | 説明 |
|---|---|
|
Compute |
Compute の管理およびスケジューリングサービスは、コントローラー上で実行されます。Compute サービスは、各コンピュートノード上でも実行されます。 |
|
Dashboard |
OpenStack の管理用 Web コンソール |
|
Identity |
基本的な認証と承認 |
|
Image |
インスタンスの起動とスナップショットの管理に使用するイメージを保管します。このサービスは、コントローラーを実行して少量のイメージセットを提供します。 |
|
ネットワーク |
ネットワークサービス。OpenStack Networking についての詳しい情報は、「2章ネットワークに関する詳細」を参照してください。 |
|
Object Storage |
バックアップコンテンツの保管 |
|
Telemetry |
その他の OpenStack サービスのモニタリングとレポーティング |
4.4.2.3. 設計の考慮事項
「3章設計」に記載した基本的な設計の考慮事項に加えて、「ネットワークを重視したアーキテクチャーの考慮事項」に記載の考慮事項にも従うべきです。
4.4.3. 大規模な Web アプリケーション向けのアーキテクチャー
このアーキテクチャーは、需要の急激な増加に対応するように水平方向にスケーリングして、インスタンス数を高くする大規模な Web アプリケーション向けです。このアプリケーションは、データを保護する SSL 接続が必要で、個別のサーバーへの接続を失うことはできません。
インストールおよびデプロイメントに関する説明は、「5章デプロイメントの情報」を参照してください。
4.4.3.1. 設計について
以下の図は、このワークロード向けの設計例を示しています。
この設計には、以下のコンポーネントとワークフローが含まれます。
- ハードウェアロードバランサーは、SSL オフロード機能を提供し、アドレスの使用を削減するためにテナントネットワークに接続します。
- ロードバランサーは、アプリケーションの仮想 IP (VIP) にサービスを提供する際にルーティングアーキテクチャーにリンクします。
- ルーターとロードバランサーは、アプリケーションのテナントネットワークの GRE トンネル ID と、テナントサブネット内でアドレスプール外の IP アドレスを使用しますが、この設定により、パブリックの IP アドレスを使用せずにロードバランサーがアプリケーションの HTTP サーバーと通信することができます。
4.4.3.2. アーキテクチャーコンポーネント
Web サービスアーキテクチャーは、数多くのオプションとオプションコンポーネントで構成される場合があります。そのため、このアーキテクチャーは、複数の OpenStack 設計で使用することができます。ただし、大半の Web スケールワークロードを処理するには、いくつかの主要コンポーネントをデプロイする必要があります。
| コンポーネント | 説明 |
|---|---|
|
Compute |
Compute の管理およびスケジューリングサービスは、コントローラー上で実行されます。Compute サービスは、各コンピュートノード上でも実行されます。 |
|
Dashboard |
OpenStack の管理用 Web コンソール |
|
Identity |
基本的な認証と承認 |
|
Image |
インスタンスの起動とスナップショットの管理に使用するイメージを保管します。このサービスは、コントローラーを実行して少量のイメージセットを提供します。 |
|
ネットワーク |
ネットワークサービス。分離したネットワークの構成は、プライベートテナントネットワーク上にあるデータベースと互換性があります。そのようなデータベースは、大量のブロードキャストトラフィックを生成せず、コンテンツ用のデータベースと相互接続する必要がある場合があるためです。 |
|
Orchestration |
スケールアウト時およびトラフィックバースト中に使用するインスタンスのテンプレートを管理します。 |
|
Telemetry |
その他の OpenStack サービス用のモニタリングとレポーティング。このサービスは、インスタンスの使用状況のモニタリングと Orchestration サービスからのインスタンステンプレートの呼び出しに使用します。 |
|
Object Storage |
バックアップコンテンツの保管 |
4.4.3.3. 設計の考慮事項
「3章設計」に記載した基本的な設計の考慮事項に加えて、「ネットワークを重視したアーキテクチャーの考慮事項」に記載の考慮事項にも従うべきです。
4.4.4. ネットワークを重視したアーキテクチャーの考慮事項
ネットワーク集約型のアーキテクチャーには、基本的な設計の考慮事項 (「3章設計」) とネットワークノードの設計 (2章ネットワークに関する詳細) に加えて、以下の点を検討すべきです。
- 外部の依存関係
以下のような外部ネットワークコンポーネントの使用を検討してください。
- ワークロードの分散または特定の機能の負荷を軽減するハードウェアロードバランサー
- 動的ルーティングを実装するための永続デバイス
OpenStack Networking は、トンネリング機能を提供しますが、ネットワーク管理されたリージョンのみに制限されています。OpenStack リージョンを超えて、他のリージョンまたは外部システムにトンネルを拡張するには、OpenStack の外部にトンネルを実装するか、トンネル管理システムを使用して、外部トンネルへのトンネルまたはオーバーレイをマッピングします。
- 最大転送単位 (MTU)
一部のワークロードは、大型のデータブロックを転送するために大きな MTU が必要です。ビデオストリーミングやストレージのレプリケーションなどのアプリケーション用のネットワークサービスを提供する場合には、OpenStack ハードウェアノードと、可能な場合にはジャンボフレーム用の補助ネットワーク機器を設定します。この構成は、利用可能な帯域幅の使用率を最大化します。
パケットが通過する全パスにわたってジャンボフレームを設定します。1 つのネットワークコンポーネントがジャンボフレームに対応できない場合には、全パスがデフォルトの MTU に戻ります。
- NAT の使用
固定のパブリック IP ではなく、Floating IP が必要な場合は、NAT を使用する必要があります。たとえば、DHCP サーバーの IP にマッピングされている DHCP リレーを使用します。この場合には、各新規インスタンスにレガシーや外部のシステムを再設定する代わりに、インフラストラクチャーがターゲットの IP アドレスを新規インスタンスに適用するように自動化した方が簡単です。
OpenStack Networking によって管理される Floating IP 用の NAT は、ハイパーバイザー内に常駐しますが、その他のバージョンの NAT は他の場所で実行される場合があります。IPv4 アドレスが不足している場合には、以下の方法を用いて OpenStack 外の IPv4 アドレス不足を軽減することができます。
- ロードバランサーを OpenStack 内でインスタンスとして実行するか、外部でサービスとして実行します。OpenStack の Load-Balancer-as-a-Service (LBaaS) は、ロードバランシングソフトウェア (例: HAproxy) を内部で管理することができます。このサービスが仮想 IP (VIP) アドレスを管理する一方、HAproxy インスタンスからのデュアルホームコネクションが全コンテンツサーバーをホストするテナントプライベートネットワークにパブリックネットワークを接続します。
- ロードバランサーを使用して仮想 IP にサービスを提供するとともに、外部の方法やプライベートアドレスを使用してテナントオーバーレイネットワークに接続します。
場合によっては、インスタンスで IPv6 アドレスのみを使用し、NAT ベースの移行テクノロジー (例: NAT64、DNS64) を提供するインスタンスまたは外部サービスを稼働することもできます。この設定は、グローバルでルーティング可能な IPv6 アドレスを提供し、IPv4 アドレスは必要のある場合にしか使用しません。
- サービス品質 (QoS)
QoS は、ネットワークパフォーマンスの低下により優先順位が高くなったパケットに対して即時にサービスを提供するので、ネットワーク集約型のワークロードに多大な影響を及ぼします。Voice over IP (VoIP) のようなアプリケーションでは、継続的な運用には、通常、差別化されたサービスコードポイントが必要です。
複数の混在するワークロードで QoS を使用して、優先順位が低く帯域幅の大きいアプリケーション (例: バックアップサービス、ビデオコンファレンス、ファイル共有など) が他のワークロードの継続的な運用に必要な帯域幅をブロックしてしまわないようにすることもできます。
ファイルとストレージ間のトラフィックに低いクラスのトラフィック (例: ベストエフォート、スカベンジャーなど) のタグを付けて、優先度の高いトラフィックがネットワークを通過できるようにすることが可能です。クラウド内のリージョンが地理的に分散されている場合、WAN 最適化を使用してレイテンシーやパケット損失を軽減することができます。
- ワークロード
ルーティングとスイッチングのアーキテクチャーは、ネットワークレベルの冗長性を必要とするワークロードに対応すべきです。この構成は、選択したネットワークハードウェア、選択したハードウェアのパフォーマンス、ネットワークモデルによって異なります。例としては、リンクアグリゲーション (LAG)、ホットスタンバイルータープロトコル (HSRP) があります。
ワークロードは、オーバーレイネットワークの有効性に影響します。アプリケーションネットワークの接続が少量、短期間、またはバースト性の場合には、動的なオーバーレイを実行すると、ネットワークが伝送するパケットの分だけの帯域幅を生成することができます。オーバーレイは、ハイパーバイザーで問題が発生する原因となるのに十分な長さのレイテンシーを起し、パケット毎秒や接続数毎秒などでパフォーマンス低下をもたらす場合もあります。
デフォルトでは、オーバーレイには第 2 のフルメッシュオプションがあり、ワークロードによって異なります。たとえば、大半の Web サービスアプリケーションは、フルメッシュのオーバーレイネットワークで大きな問題はありませんが、一部のネットワーク監視ツールやストレージレプリケーションワークロードでは、スループットでパフォーマンスの問題が発生するか、ブロードキャストトラフィックが過剰となります。
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}