パーソナライズされたリアルタイムのエクスペリエンスを追求するユーザーが増えるにつれ、アプリケーションはより低いレイテンシとほぼリアルタイムの処理が必要となります。エッジコンピューティングでは、アプリケーション・インフラストラクチャを一元化されたデータセンターからネットワークエッジに、可能な限り消費者に近づけることができます。このユースケースは、テレコミュニケーションだけでなく、ヘルスケア、エネルギー、小売、リモートオフィスなどにまで適用できます。
アプリケーションとその基盤となるインフラストラクチャの両方で、この新しいエッジモデルに適応する必要があります。このようなエッジの課題に対してRed Hatは、Red Hat OpenStack Platform 13に分散コンピューティングノード（DCN）というアーキテクチャを導入しました。このアーキテクチャにより、オペレーターは、ワークロードをホストするコンピューティングリソース（コンピュートノード）を消費者のデバイスの近く（エッジサイトなど）に展開しながら、コントロールプレーンを国や地域のサイトなどの従来のデータセンターに集中させることができます。
このモデルは、コストと運用に効率的であることが証明されていますが、重要なコンポーネントが欠けていました。エッジサイトでの永続ストレージやイメージ管理には対応していなかったのです。ワークロードはローカルのエフェメラルディスクに依存しなければなりませんでした。これは一部のステートレスアプリケーションでは問題ありませんが、エッジで信頼性の高い永続ストレージが必要とされるアプリケーションには、最適な選択肢ではない場合もあります。
純粋なアプリケーション要件に加えて、エッジのストレージには、Fast Boot、コピーオンライト、ストレージ暗号化、スナップショット、仮想マシン（VM）移行、ボリューム移行、ボリュームバックアップといった、かつては離れた大規模なコアデータセンターでのみ許可されていた機能など、新しいメリットが数多くあります。
Red Hat OpenStack Platform 16.1では、エッジでの永続ストレージとイメージ管理のサポートが導入されました。その実現につながった経緯を見てみましょう。
ハイレベルのアーキテクチャ
永続ストレージをエッジサイトに導入するには、設計上の重要な注意点に配慮しなければなりません。
何よりもまず、実際のストレージバックエンドのアーキテクチャをどのように設計するかです。Red Hat OpenStack Platformでは、専用のバックエンドを用意するというアプローチを採用し、各ストレージバックエンドはローカルからサイトへのコンピュートノードのみにサービスを提供するようにしました。
これにより、ストレッチ構成を行わずに、遅延の影響を受けやすいデータが高遅延リンクを介して送信されるのを防ぐことで、適切なパフォーマンスと拡張性を確保できます。そうすることで、特定のエッジサイトストレージの障害が他のサイトに影響を与えないというセキュリティとオペレーションの両方の観点から、適切に分離を行えます。各コンピュートは、ローカルからサイトへのストレージバックエンドを消費します。
他にも重要な設計上の注意点の一つが、イメージ管理システムです。Cinderの永続ストレージはユーザーデータに対応していますが、ワークロードを迅速かつ効率的に起動するには、コンピュートノードの近くにイメージも必要です。Red Hatでは、Glanceが複数のストレージバックエンドを管理できるようにする「マルチストア」という最近のGlanceイノベーションを採用しました。サイト別に専用のバックエンドアプローチを使用すると、各サイトでイメージをホストできます。
最後になりましたが、アーキテクチャをどのように導入していますか？どのサービスがエッジに導入されていますか？何よりも重要ですが、構成の更新、スケーリング、更新などDay2のオペレーションをどのように管理していますか？Red Hat OpenStack Platform展開ツール（ディレクター）はエッジに対応できるようになりました。複数のサイトを展開して、それらを個別に管理できます。
Red Hat Ceph Storageハイレベルアーキテクチャを備えたDCNストレージ
エッジでのストレージに関する重要な設計上の注意点を強調しました。次は「どのストレージバックエンドを使用する必要があるか」です。
機能豊富なOpenStackバックエンドであるRed Hat Ceph Storageを、ぜひ検討してください。そのソフトウェア定義の高度に分散された自己修復機能により、Ceph Storageはエッジストレージの堅実なソリューションになります。x86とそのハイパーコンバージェンス機能をサポートしているため、エッジのユースケースにぴったりです。ハードウェアの標準化とコスト削減という2つのメリットは、コンピューティングサービスとストレージサービスを同じノードに統合できることです。これは、サイトがスペース、冷却、電力によって制限される可能性があるエッジケースにとって重要です。
Red Hat OpenStack Platform 16.1は、エッジでRed Hat Ceph Storageを備えたDCNを完全にサポートしています。
どのような仕組みでしょうか？ハイレベルのアーキテクチャを見てみましょう。
ここで重要なのは、サイトごとと中央サイトで専用のCephクラスターを使用することです。ストレッチ構成を行う不要はありません。
導入に関しては、フットプリントを小さくして、ノードのハードウェア仕様を標準化するために、ハイパーコンバージドモデルに焦点を当てました。サイトあたりのノードの最小数は3であり、Ceph Storageでこれは必要な最小数です。現在のストレージ容量で可能であれば、ハイパーコンバージドノードを追加したり、コンピュート専用ノードを追加したりできます。最適なパフォーマンスを得るために、コンピューティングリソースとストレージリソースの適切なバランスを考慮してください。
ワークロードのスケジューリングに関しては、各サイトが専用のAZとして構成されているアベイラビリティーゾーン（AZ）アプローチを維持しました。特定のサイトでワークロードをスケジュールするには、ユーザーは起動時に対応するAZを選択します。
Cinderで永続ストレージを追加したので各サイトにも専用のストレージAZが追加されます。ユーザーは、ボリューム作成時にAZを指定して、ボリュームを作成するサイト（またはCephクラスター）を選択します。NovaとCinderのAZの両方の名前が一致して、サイトAのVMがサイトBにボリュームをマウントしないようにするために、クロスAZ接続を無効にできます。
純粋な運用の観点から、Red Hat Ceph Storageは、Red Hat OpenStack Platformと同じツールで展開できます。これにより、Day1とDay2の運用業務をスムーズに行えます。運用面は単一のツールで管理され、数十のCephクラスターを個別に管理する必要はありません。
Glanceマルチストアでイメージ管理を最先端に
前述のように、イメージ管理はエッジ展開では重要です。エッジ分散アプローチでは、ソリューションは、ユーザーエクスペリエンスを可能な限りシンプルに維持しながら、サイト全体の分散イメージ管理をサポートする必要があります。
通常、ユーザーはGlanceイメージを個別に扱い、同じイメージが他のサイトにも存在するため、複数のイメージエントリーを処理できません。DCNアーキテクチャは、Glanceマルチストア（バックエンドなど）を活用して、サイト間の位置に関わらず、ユーザーが単一のイメージエントリーを操作できるようにします。各GlanceストアはCeph Storageバックエンドにマッピングされます。各サイトには独自のバックエンドが含まれ、サイトごとにGlanceストアが表示されます（中央サイトを含む）。
イメージのコピーを追跡するために、Glanceは場所のメタデータ（場所URLのリストや各ストア名など）を追加します。これらのメタデータは、コントロールプレーンデータベースに保存されます。
メタデータはすべてのイメージの場所を追跡します。この例では、イメージは中央、サイト1、サイト2で使用できます。これらの3つのサイトでは、いつでもこのイメージからワークロードを起動し、コピーオンライトなどの機能を利用できます。ユーザーがサイト3でワークロードを起動したい場合は、イメージをそのサイトにコピーするオプションがあります（後で詳しく説明します）。
CLIにどのように反映されるのでしょう？
OSP管理者は、利用可能なストアを一覧表示できます。
$ glance stores-info
+----------+----------------------------------------------------------------------------------+
| Property | Value |
+----------+----------------------------------------------------------------------------------+
| stores | [{"id": "site1", "description": "site1 RBD backend"}, {"default": "true", "id": |
| | "central", "description": "central RBD backend"}, {"id": "site2", "description": |
| | "site2 RBD backend"}, {"id": "site3", "description": |
| | "site3 RBD backend"}] |
+----------+----------------------------------------------------------------------------------+
このコマンドは、中央、サイト1、サイト2、サイト3の4つのストアを返します。中央がデフォルトです（ストアが指定されていない場合、Glanceは中央サイトを使用します）。
openstack image show を実行すると、すべての場所（ストア）が返されます。
$ openstack image show my_image
(...)
locations='
[{u'url': u'rbd://dbb41ef0-15d2-11ea-a69a-244201a99610/images/35cb2a43-eb89-4bed-99a2-c4376133a492/snap', u'metadata': {u'store': u'central'}},
{u'url': u'rbd://fa9b85d0-15da-11ea-a69a-244201a99610/images/35cb2a43-eb89-4bed-99a2-c4376133a492/snap', u'metadata': {u'store': u'site1'}}]'
{u'url': u'rbd://fnhk9d7h-39b5-11ea-a69a-244201a99610/images/35cb2a43-eb89-4bed-99a2-c4376133a492/snap', u'metadata': {u'store': u'site2'}}]'
(...)
stores='central,site1,site2'
この例では、イメージ my_image が中央、サイト1、サイト2に存在することがわかります。
location フィールドには、以下のCeph RBD URIと一緒に場所の詳細が表示されます。
rbd://CEPH_CLUSTER_ID/images/IMAGE_ID/
CEPH_CLUSTER_ID は、サイトごとに専用のクラスターがあるため一意です。「images」はデフォルトのGlance Cephプールに対応し、IMAGE_ID はすべてのイメージコピーに共通のGlanceイメージIDに対応していまます。
また、コピーが保存されているストアについても説明します。
'metadata': {u'store': u'STORE_NAME'}
stores フィールドは、イメージが存在するすべてのストアを一覧表示する短縮バージョンです。
この新しいアプローチに対処するために、Glance CLIも改善されました。ユーザーが分散イメージを管理できるように、次の機能が追加されました。
-
アップロード時に複数のサイトにイメージをインポートします。
-
glance image-create-via-import --disk-format qcow2 --container-format bare --name image_name --uri http://server/image.qcow2 --import-method web-download --stores <list,of,stores>
-
既存のイメージを別のサイトにコピーします。
-
glance image-import <existing-image-id> --stores <list of comma separated stores> --import-method copy-image
-
特定のサイトからイメージのコピーを削除します。
-
glance stores-delete <image-id> --stores <store-id>
アーキテクチャに関しては、専用のGlance APIサービスのセットが各サイトに展開され、次の方法でさまざまなストレージの場所にアクセスできます。
-
Central Glance APIサービスは、デフォルトストアとしてローカルCephクラスターに書き込むことができ、追加のイメージストアとしてすべてのDCN Cephクラスターに書き込むこともできます
-
各DCN Glance APIサービス（サイトごとに3つ）は、デフォルトストアとしてローカルCephクラスターに書き込むことができ、オプションで追加のイメージストアとして中央Cephクラスターに書き込むこともできます。
エッジノードは、イメージをリクエストするときにローカルのGlanceサービスに依存し、指定されたサイト内にリクエストを保持します。
中央サイトはハブとして機能し、サイト間でイメージを適宜コピーします。ユーザーは中央サイトAPIと対話しますが、エッジAPIサービスとは直接対話しません。
イメージトラフィックがWANを通過するのは、中央サイトとエッジサイトの間でイメージがコピーされる時だけです。レイテンシーの影響を受けますが、非同期コピープロセスであり、実際のワークロードには影響しません。イメージがコピーされるとワークロードが起動され、ローカルからサイトへのコピーのみに依存します。
エッジVMスナップショットがサポートされており、中央サイトに転送して戻すことができます。中央サイトから、他のエッジサイトにコピーして、そこから起動できます。
パート2の詳細
最初のパートでは、Red Hat OpenStack Platform DCNの基本と主要なアーキテクチャの側面について説明しました。これは、エッジコンピューティングの現在と今後の課題を管理するためのOpenStackソリューションです。
そして、リモートサイトとストレージバックエンド間で分散されたイメージのコピーを管理する手段として、Glanceマルチストアを使用したエッジイメージ管理について詳しく掘り下げました。
本シリーズの次の最後のパートでは、OpenStack永続ストレージサービスであるCinderを設計して構成する方法と、Red Hat OpenStack Platformディレクターを使用してDCNを展開・運用する方法について説明します。本シリーズの最後に、最終的なユーザーエクスペリエンスの概要を説明する実践的なコマンドを紹介します。