第1章 OpenStack での永続ストレージの概要
OpenStack は、一時 ストレージと 永続 ストレージの 2 種類を認識します。一時ストレージは、特定の Compute インスタンスにのみ関連付けられるストレージです。インスタンスが終了されると、一時ストレージも終了します。この種別のストレージは、インスタンスのオペレーティングシステムの保存など、ランタイム時の基本的要件に対応する際に役立ちます。
一方、永続 ストレージは、実行中のインスタンスからは独立して存続 (永続) するように設計されています。このストレージは、別のインスタンスまたは有効期間を超えた特定のインスタンスが再利用する必要のあるデータに使用されます。OpenStack は以下の種別の永続ストレージを使用します。
- ボリューム
OpenStack Block Storage サービス (openstack-cinder) は、ボリューム を使用してブロックストレージデバイスにユーザーがアクセスできるようにします。一時ストレージを汎用の永続ストレージで拡張するために、インスタンスにボリュームを接続することができます。ボリュームは、任意でインスタンスからデタッチすることも、再度接続することもできます。接続したインスタンス経由でないと、ボリュームにはアクセスできません。
ボリュームには、バックアップやスナップショットを使用することで冗長性と災害復旧機能も備わっています。さらに、ボリュームを暗号化できるため、セキュリティーが強化されます。ボリュームに関する情報は、「2章Block Storage とボリューム」を参照してください。
注記一時ストレージは絶対に使用しないように、インスタンスを設定することも可能です。このような場合は、Block Storage サービスによりボリュームにイメージが書き込まれ、そのボリュームはインスタンスのブータブル root ボリュームとして利用することができます。
- コンテナー
OpenStack Object Storage サービス (openstack-swift) は、メディアファイル、大容量のデータセット、ディスクイメージなど、静的データやバイナリー オブジェクト を保存するために使用する完全に分散されたストレージソリューションを提供します。Object Storage サービスは、コンテナー を使用してこれらのオブジェクトを整理します。
ボリュームのコンテンツにはインスタンス経由でしかアクセスできませんが、コンテナーの中のオブジェクトは Object Storage REST API 経由でアクセスすることができます。そのため、クラウド内にあるほぼすべてのサービスが、Object Storage サービスをリポジトリーとして使用することができます。たとえば、Data Processing サービス (openstack-sahara) は、Object Storage サービスから直接、そのバイナリー、データ入力、データ出力、テンプレートをすべて管理できます。
- 共有
- OpenStack Shared File System サービス (openstack-manila) は、リモートにある共有可能なファイルシステムまたは 共有 を簡単にプロビジョニングする手段を提供します。共有により、クラウド内のテナントがオープンにストレージを共有できるため、共有を複数のインスタンスにより同時に消費することができます。
本リリースでは、OpenStack Shared File System は テクノロジープレビュー として提供されているため、Red Hat では全面的にはサポートしていません。これは、テスト目的のみでご利用いただく機能で、実稼働環境にデプロイすべきではありません。テクノロジープレビューについての詳しい情報は「「対象範囲の詳細」」を参照してください。
各ストレージの種別は、特定のストレージ要件に対応するために設計されています。コンテナーは、幅広いアクセスに対応できるように設計されているため、全ストレージ種別において最高レベルのスループット、アクセス、フォールトトレランスが備えられています。コンテナーは主にサービスへの使用を対象としています。
一方で、ボリュームは主にインスタンスの消費に使用されます。ボリュームは、コンテナーと同じレベルのアクセスやパフォーマンスには対応しにくくなっていますが、コンテナーに比べ、機能セットが幅広く、ネイティブのセキュリティー機能も多くなっています。この点では、共有はボリュームとよく似ていますが、共有は複数のインスタンスにより消費可能である点が異なります。
以下のセクションでは、具体的なストレージ基準との関連において、各ストレージ種別のアーキテクチャーおよび機能セットについて考察します。
1.1. スケーラビリティーおよびバックエンド
一般的に、クラスターストレージソリューションは、バックエンドのスケーラビリティーが高くなっています。Red Hat Ceph を Block Storage のバックエンドとして使用する場合は、Ceph OSD (Object Storage Daemon) ノードをさらに追加することで、ストレージの容量および冗長性をスケーリングできます。Block Storage も Object Storage サービスも、バックエンドとして使用する Red Hat Ceph をサポートします。
Block Storage サービスは、個別のバックエンドとして複数のストレージソリューションを使用することができます。バックエンドレベルでは、バックエンドを追加してサービスを再起動することで、容量をスケーリングすることができます。Block Storage サービスは、数多くのサポートバックエンドソリューションをサポートしており、その一部には追加のスケーラビリティー機能が備えられています。
デフォルトでは、Object Storage サービスは設定済みの ストレージノード を使用しており、空き容量がある分だけ使用することができます。Object Storage サービスは、XFS および ext4 ファイルシステムをサポートし、いずれのサービスもスケーリングして、下層にあるブロックストレージで利用可能な容量を消費することができます。また、ストレージデバイスをストレージノードに追加して、容量をスケーリングすることも可能です。
Shared File System サービスは、別の ストレージプール からのストレージでバッキングされる共有をプロビジョニングします。通常はサードパーティーのバックエンドサービスによって管理されるこのプールは、ファイルシステムレベルでストレージを共有に提供します。Shared File System サービスでは NetApp および CephFS の両方をサポートしており、事前作成済みのボリューム (プロビジョニングした共有でストレージとして使用可能) のストレージプールを使用するように設定できます。いずれのデプロイメントにおいても、プールにボリュームを追加してスケーリングを行います。
1.2. アクセシビリティーと管理
ボリュームは、インスタンスによってのみ消費され、1 回に 1 つのインスタンスにしか接続できず、またそのインスタンス内にしかマウントできません。ボリュームのスナップショットを作成して、クローンを作成する際や以前の状態にボリュームを復元する際に使用することができます (「冗長性および災害復旧」を参照)。Block Storage サービスでは、新規ボリュームを作成する際にこれらの設定を簡単に呼び出すことができるようにボリュームの各種設定 (例: サイズおよびバックエンド) をまとめた ボリューム種別 を作成することも可能です。これらの種別はさらに QoS スペックに関連付けて、ユーザー向けに異なるストレージ階層を作成することができます。
共有は、ボリュームと同様にインスタンスにより消費されますが、共有の場合はインスタンス内に直接マウントすることができるので、ダッシュボードまたは CLI 経由で接続する必要がありません。共有は、同時に複数のインスタンスによりマウントすることができます。File Share サービスは、共有のスナップショットやクローン作成もサポートしており、(ボリューム種別と同様に) 設定をまとめた 共有種別 を作成することも可能です。
コンテナー内のオブジェクトは、API 経由でアクセスすることができ、クラウド内のインスタンスやサービスからもアクセスすることができるようになるため、サービスのオブジェクトリポジトリーとして理想的です。たとえば、Image サービス (openstack-glance) は Object Storage サービスで管理するコンテナーにイメージを保存することができます。
1.3. セキュリティー
Block Storage サービスは、ボリュームの暗号化 を使用して基本的なデータセキュリティーを確保します。これにより、静的キーでボリューム種別を暗号化するように設定できます。このキーは設定したボリュームの種別から作成したボリュームすべてを暗号化する際に使用されます。詳細は「ボリュームの暗号化設定」を参照してください。
一方で、オブジェクトとコンテナーのセキュリティーは、サービスおよびノードレベルで設定されます。Object Storage サービスでは、コンテナーとオブジェクトに対するネイティブの暗号化はなく、Object Storage サービスによりクラウド内のアクセス性の優先順位が付けられるため、オブジェクトデータの保護はクラウドのネットワークセキュリティーにのみ依存します。
File Share サービスでは、インスタンスの IP アドレス、ユーザー/グループ、または TLS 証明書別にアクセス制限することで共有のセキュリティーを確保することができます。さらに、一部の File Share サービスのデプロイメントは、別の 共有サービス が備えられているため、共有ネットワークと共有間の関係を管理することができます。共有サーバーによっては追加のネットワークセキュリティーをサポートする (または必要とする) 場合があります。たとえば、CIFS 共有サーバーでは LDAP、Active Directory または Kerberos 認証サービスのデプロイメントが必要です。
1.4. 冗長性および災害復旧
Block Storage サービスには、ボリュームのバックアップと復旧機能があり、ユーザーストレージの基本的な災害復旧を行います。バックアップで、ボリュームのコンテンツを保護することができます。それに加え、サービスはクローン作成以外にスナップショットもサポートしており、以前の状態にボリュームを復元する際に役立ちます。
マルチバックエンドの環境では、バックエンド間でボリュームを移行することも可能です。この機能は、メンテナンスでバックエンドをオフラインにする必要がある場合に役立ちます。バックアップは通常、データが保護できるように、ソースのボリュームとは別のストレージバックエンドに保存されます。ただし、スナップショットはソースのボリュームに依存するため、この方法を用いることはできません。
Block Storage サービスは、整合性グループ の作成もサポートしており、ボリュームをグループ化して同時にスナップショットの作成ができます。これにより、複数のボリューム間のデータの整合性レベルを向上することができます。詳しい情報は「整合性グループの設定と使用」を参照してください。
最後に、Block Storage サービスには ボリュームの複製 機能も備えられているため、ボリューム間でコンテンツを複製するように設定して、基本的な冗長性を提供することができます。
ボリュームの複製は、特定のサードパーティーのバックエンド、およびそれに適したドライバーを使用することでのみ利用可能です。
Object Storage サービスには、バックアップ機能がないため、すべてのバックアップはファイルシステムまたはノードレベルで行う必要がります。ただし、このサービスにはより強力な冗長機能とフォールトトレランスが備えられており、Object Storage サービスの最も基本的なデプロイメントでさえ、複数回オブジェクトを複製します。dm-multipath などのフェイルオーバー機能を使用して冗長性を強化することができます。
File Share サービスは、共有に対するバックアップ機能が含まれていませんが、スナップショットを作成してクローンを作成したり、復元したりすることができます。
