主流の分散ストレージ技術の比較分析と応用についてお話ししましょう

[[323651]]

分散ファイルシステム

分散ファイルシステム (DFS) とは、必ずしもローカルノードに直接接続されているわけではなく、コンピュータネットワークを介してノードに接続されている物理ストレージリソースを管理するファイルシステムを指します。分散ファイルシステムの設計は、クライアント/サーバー (C/S) モデルに基づいています。一般的な分散ファイルシステムには、Lustre、Hadoop、FastDFS、Ceph、GlusterFS などがあります。

Ceph の紹介

Ceph には、公式 (有料) とオープンソースがあります。高いスケーラビリティ、高可用性、高パフォーマンスを備えた分散ファイルシステムです。 Ceph は、オブジェクトストレージ、ブロックストレージ、ファイルシステムストレージを提供できます。 Ceph は PB レベルのストレージスペース (PB --> TB --> --> GB) を提供できます。ソフトウェア定義ストレージ（Software Defined Storage）は、業界における主要な開発トレンドです。公式ウェブサイト: http://docs.ceph.org/start/intro.

Ceph の歴史

Ceph は Sage 氏の博士課程の研究から生まれました。結果は 2004 年に公開され、その後オープンソースコミュニティに貢献されました。長年の開発を経て、多くのクラウドコンピューティングおよびストレージベンダーからサポートされ、最も広く使用されているオープンソース分散ストレージプラットフォームになりました。

Ceph は、シナリオに応じて、オブジェクトストレージ、ブロックデバイスストレージ、ファイルストレージに分けられます。他の分散ストレージ技術と比較して、Ceph には次の利点があります。データを保存するだけでなく、ストレージノードの計算能力を最大限に活用します。各データを保存するときに、データが格納されている場所を計算し、データを均等に分散しようとします。同時に、CRUSHやHASHなどのアルゴリズムを使用しているため、従来の単一障害点がなく、規模が拡大してもパフォーマンスに影響はありません。

1. Ceph の主なアーキテクチャ

Ceph の最下層は、信頼性、インテリジェンス、分散という特徴を持つ RADOS (分散オブジェクトストレージシステム) です。高信頼性、高拡張性、高パフォーマンス、高自動化などの機能を実現し、最終的にはユーザーデータを保存します。 RADOS システムは主に OSD とモニターの 2 つの部分で構成されています。

RADOS の上位にあるのは LIBRADOS で、これはライブラリにアクセスすることでアプリケーションが RADOS システムと対話できるようにするライブラリであり、C、C++、Python などの複数のプログラミング言語をサポートしています。

LIBRADOS レイヤーに基づいて開発されたインターフェースは、RADOSGW、librbd、MDS の 3 つです。

RADOSGW は、オブジェクトストレージをサポートし、S3 および Swift と互換性のある、一般的な RESTFUL プロトコルに基づくゲートウェイです。

librbd は分散ブロックストレージデバイスインターフェイスを提供し、ブロックストレージをサポートします。

MDS は POSIX 互換のファイルシステムを提供し、ファイルストレージをサポートします。

Ceph 機能モジュール

Ceph のコアコンポーネントには、クライアント、MON 監視サービス、MDS メタデータサービス、および OSD ストレージサービスが含まれます。各コンポーネントの機能は次のとおりです。

クライアント: ストレージプロトコルへのアクセスとノードの負荷分散を担当
MON 監視サービス: クラスタ全体の監視、クラスタの健全性の維持、OSD マップ、モニタマップ、PG マップ、CRUSH マップなどのクラスタの状態を示すさまざまなチャートの維持を担当します。
MDSメタデータサービス: ファイルシステムのメタデータを保存し、ディレクトリ構造を管理する役割を担う
OSD ストレージサービス: 主な機能は、データの保存、データの複製、データのバランス調整、データの回復、および他の OSD とのハートビートチェックの実行です。通常、1 つのハードディスクは 1 つの OSD に対応します。

3.Cephリソース分割

Ceph はクラッシュアルゴリズムを使用して、大規模クラスターでの高速かつ正確なデータストレージを実現します。同時に、ハードウェア障害やハードウェア拡張が発生した場合のデータ移行を最小限に抑えることができます。原則は次のとおりです。

ユーザーが Ceph クラスターにデータを保存する場合、データは最初に複数のオブジェクトに分割されます (各オブジェクトにはオブジェクト ID があり、サイズを設定できます。デフォルトは 4MB)。オブジェクトは Ceph ストレージの最小のストレージ単位です。

オブジェクトの数が多いため、オブジェクトから OSD へのインデックステーブルを効果的に削減し、メタデータの複雑さを軽減し、書き込みと読み取りをより柔軟にするために、pg (配置グループ) が導入されました。PG はオブジェクトの管理に使用されます。各オブジェクトはハッシュを通じて pg にマッピングされます。 pg には複数のオブジェクトを含めることができます。

次に、Pg は CRUSH を通じて計算され、osd にマップされます。コピーが 3 つある場合、データの冗長性を確保するために、各 pg は 3 つの osd にマップされます。

4. Cephへのデータの書き込み

Cephデータ書き込みプロセス

データは負荷分散を通じてノードの動的 IP アドレスを取得します。
ブロック、ファイル、またはオブジェクトプロトコルを介してノードにファイルを転送します。
データは 4M 個のオブジェクトに分割され、オブジェクト ID が取得されます。
オブジェクト ID は、HASH アルゴリズムを使用して異なる PG に割り当てられます。
CRUSHアルゴリズムを通じて、異なるPGが異なるOSDに割り当てられます。

5. Cephの特徴

 Ceph はオブジェクトストレージ、ブロックストレージ、ファイルストレージサービスをサポートしているため、統合ストレージと呼ばれています。
 CRUSH アルゴリズムを使用すると、データは均等に分散され、高い並列性が得られ、固定されたメタデータ構造を維持する必要がなくなります。
 データは強力な一貫性を備えており、確認を返す前にすべてのコピーが書き込まれることを保証します。これは、読み取りが多く書き込みが少ないシナリオに適しています。
 分散化、MDSは同じステータスを持ち、固定された中央ノードは存在しない

Ceph にはいくつかの欠点があります。

 分散型ソリューションには事前の計画と設計が必要であり、技術チームに対する要件が比較的高くなります。
 Ceph を拡張すると、バランスのとれたデータ分散特性により、ストレージシステム全体のパフォーマンスが低下します。

GFS

GFS は、大量の検索データを保存するために特別に設計された Google の分散ファイルストレージシステムです。これは 2003 年に提案されたクローズドソースの分散ファイルシステムです。大きなファイルの読み取りや書き込みなど、大量の順次読み取りや順次追加に適しています。単一の読み取りと書き込みの遅延ではなく、大きなファイルの持続的で安定した帯域幅に重点を置きます。

1. GFSの主なアーキテクチャ

GFS アーキテクチャは比較的シンプルです。 GFS クラスターは通常、マスター、複数のチャンクサーバー、および複数のクライアントで構成されます。

GFS では、すべてのファイルは複数のチャンクに分割され、各チャンクには一意で不変の識別子 (チャンクの作成時にマスターによって割り当てられる) があり、すべてのチャンクは実際にはチャンクサーバーのディスクに保存されます。

災害復旧のために、各チャンクは複数のチャンクサーブに複製されます。

2. GFSの機能モジュール

 GFS クライアント: POSIX API に似たアプリケーション用の API を提供します。また、GFS マスターから読み取ったメタデータチャンク情報もキャッシュします。

 GFS マスターメタデータサーバー: コマンドスペース (ディレクトリ階層)、アクセス制御情報、ファイルとチャンクのマッピング、チャンクの場所など、すべてのファイルシステムのメタデータを管理します。同時に、マスターは、チャンクの作成、レプリケーション、データ移行、ガベージコレクションなど、システム内のさまざまなアクティビティも管理します。

 GFS チャンクサーバーストレージノード: すべてのチャンクを保存するために使用されます。ファイルは固定サイズ (デフォルトでは 64 MB) の複数のチャンクに分割され、各チャンクにはグローバルに一意のチャンク ID が付けられます。

3. GFS書き込みプロセス

クライアントは、変更するチャンクがどのチャンクサーバー上にあるか、またチャンクの他のコピーの場所情報をマスターに問い合わせます。
マスターはプライマリとセカンダリの関連情報をクライアントに返します。
クライアントはデータをプライマリとセカンダリにプッシュします。
すべてのレプリカがデータの受信を確認すると、クライアントはプライマリに書き込み要求を送信し、プライマリは異なるクライアントの操作にシーケンス番号を割り当てて、操作が順番に実行されるようにします。
プライマリは書き込み要求をセカンダリに送信し、セカンダリはプライマリによって割り当てられた順序ですべての操作を実行します。
セカンダリは実行を完了すると、実行結果をプライマリに応答します。
プライマリは実行結果をクライアントに応答します。

上記からわかるように、GFS はデータを書き込む際に次の特性を持ちます。

GFS がデータを読み書きする場合、データフローと制御フローは分離され、複数のレプリカにわたってデータを書き込むときに、リースメカニズムを使用して順次一貫性が確保されます。
マスターは、プライマリレプリカと呼ばれるレプリカの 1 つにチャンクリースを発行します。プライマリレプリカはチャンクが書き込まれる順序を決定し、セカンダリレプリカはこの順序に従うため、グローバルな順次一貫性が確保されます。
マスターは、プライマリレプリカとセカンダリレプリカの場所情報をクライアントに返します。クライアントは、将来使用するためにこの情報をキャッシュします。プライマリレプリカが配置されているチャンクサーバーが利用できない場合、または返されたリースの有効期限が切れた場合にのみ、クライアントはマスターに再度接続する必要があります。
GFS はチェーンプッシュを使用して、各マシンのネットワーク帯域幅を最大限に活用し、ネットワークのボトルネックや高遅延の接続を回避し、プッシュの遅延を最小限に抑えます。
GFS は、遅延を最小限に抑えるために TCP を使用してデータをストリーミングします。

4. GFSの機能

 大容量ファイル、特にGBレベルの大容量ファイルに適しており、データアクセスの遅延に敏感でない検索サービスに適しています。

 集中型アーキテクチャ、アクティブなマスターは1つだけ

 キャッシュとプリフェッチ: クライアント側でメタデータをキャッシュすることで、マスターとのやり取りを最小限に抑え、ファイルをプリフェッチすることで同時実行パフォーマンスを向上させることができます。

 高い信頼性。マスターが保持する必要があるデータは、操作ログとチェックポイントを通じて複数のコピーに保存されます。障害が発生すると、マスターは自動的に切り替わり、再起動します。

ハードウェア

HDFS (Hadoop Distributed File System) は、市販のハードウェア上で実行するのに適した分散ファイルシステムです。これは Hadoop のコアサブプロジェクトであり、ストリーミングデータモードで非常に大きなファイルにアクセスして処理するというニーズに基づいて開発されています。このシステムは Google ファイルシステム (GFS) をモデルにしており、GFS の簡略化されたオープンソースバージョンです。

1. HDFSの主なアーキテクチャ

 HDFS クライアント: NameNode からファイルの場所の情報を取得し、DataNode からデータを読み書きします。さらに、データを保存する際のファイルのセグメント化はクライアントの責任となります。

 NameNode（メタデータノード）：名前空間、データブロックのマッピング情報を管理し、レプリケーション戦略を構成し、クライアントの読み取りおよび書き込み要求を処理します。

 DataNode（ストレージノード）：実際の読み取りおよび書き込み操作を実行し、実際のデータブロックを保存する役割を担います。同じデータブロックが複数のデータノードに保存される

 セカンダリネームノード: メタデータを定期的にマージし、ネームノードにプッシュします。緊急時には、NameNode の HA リカバリを支援できます。

2. HDFS の特徴 (GFS と比較)

 より大きなブロック、各データブロックはデフォルトで 128 MB です。

 同時実行はサポートされておらず、同時に許可されるライターまたはアペンダーは 1 つだけです。

 プロセスの一貫性: 書き込まれたデータの送信順序は最終的な書き込み順序と一致しています。

 マスターHA、2.Xバージョンは2つのネームノード（それぞれアクティブとスタンバイ状態）をサポートし、フェイルオーバー時間は通常数十秒から数分です。

3. HDFSに適したアプリケーションシナリオ:

 大容量ファイルやビッグデータの処理に適しており、最大 GB、TB、さらには PB レベルのデータを処理します。

 ストリーミングファイルアクセス、一度書き込み、何度も読み取りに適しています。

 一度ファイルに書き込まれると、変更することはできず、追加することしかできなくなります。

4. HDFS が適さないシナリオ:

 低遅延のデータアクセス。

 小さなファイルストレージ

 同時書き込みとランダムファイル変更

迅速

Swift は、もともと Rackspace によって開発され、2010 年に OpenStack オープンソースコミュニティに提供された分散オブジェクトストレージサービスです。元のコアサブプロジェクトの 1 つとして、Nova サブプロジェクトに仮想マシンイメージストレージサービスを提供します。

1. Swiftの主なアーキテクチャ

Swift は、完全に対称的なリソース指向の分散システムアーキテクチャ設計を採用しています。すべてのコンポーネントはスケーラブルであるため、単一点障害によるシステム全体の可用性への影響を回避できます。

Swift コンポーネントには以下が含まれます。

 プロキシサーバー: オブジェクトサービスAPIを外部に提供し、対応するアカウント、コンテナ、またはオブジェクトサービスにリクエストを転送します。

 認証サーバー: ユーザーのID情報を確認し、アクセストークンを取得します

 キャッシュサーバー: トークン、アカウント、コンテナ情報をキャッシュしますが、オブジェクトデータ自体はキャッシュしません。

 アカウントサーバー: アカウントのメタデータと統計情報を提供し、コンテナーのリストを管理するサービス。

 コンテナサーバー: コンテナのメタデータと統計情報を提供し、コンテナに含まれるオブジェクトのリストを管理するサービス

 オブジェクトサーバー: オブジェクトメタデータとコンテンツサービスを提供します。各オブジェクトはファイルシステム内にファイルとして保存されます。

 レプリケータ: ローカルコピーとリモートコピーの整合性を確認し、プッシュを使用してリモートコピーを更新します。

 アップデータ: オブジェクトの内容を更新します

監査人: オブジェクト、コンテナ、アカウントの整合性をチェックします。エラーが見つかった場合、ファイルは隔離されます。

 アカウントリーパー: 削除対象としてマークされたアカウントを削除し、そのアカウントに含まれるすべてのコンテナとオブジェクトを削除します。

2. Swiftのデータモデル

**Swift のデータモデルは、3 つのレイヤーを持つ階層構造を採用しています: **Account/Container/Object (つまり、account/container/object)。各層のノード数に制限はなく、任意に拡張可能です。データモデルは次のとおりです。

3. 一貫性のあるハッシュ関数

Swift は、計算によって仮想空間内の仮想ノードにオブジェクトを均等に分散するコンシステントハッシュテクノロジに基づいており、ノードを追加または削除するときに移動する必要があるデータの量を大幅に削減できます。

効率的なシフト操作を容易にするために、仮想空間のサイズは通常 2n です。リングと呼ばれる独自のデータ構造を通じて、仮想ノードが実際の物理ストレージデバイスにマッピングされ、アドレス指定プロセスが完了します。次の図に示すように:

ハッシュ空間は4バイト（32ビット）で、仮想ノードの最大数は232です。ハッシュ結果をmビット右にシフトすると、2（32-m）個の仮想ノードを生成できます（上図のように、m=29のとき、8個の仮想ノードを生成できます）。

4. リングデータ構造

Swift は、アカウント、コンテナ、オブジェクトごとに個別のリングを定義します。

リングは、仮想ノード (パーティション) を一連の物理ストレージデバイスにマッピングし、ある程度の冗長性を提供するように設計されています。リングのデータ情報には、ストレージデバイスリストとデバイス情報、パーティションとデバイスのマッピング関係、計算されたパーティション番号の変位（上図のm）が含まれます。

アカウント、コンテナ、オブジェクトのアドレス指定プロセス。 (オブジェクトアドレス指定プロセスを例に挙げます)

オブジェクト階層 account/container/object をキーとして使用し、MD5 ハッシュアルゴリズムを使用してハッシュ値を取得します。

ハッシュ値の最初の 4 バイトに対して右シフト操作 (m ビット) を実行して、パーティションインデックス番号を取得します。

パーティションとデバイスのマッピングテーブルで、パーティションインデックス番号に従って、オブジェクトが配置されているパーティションに対応するすべての物理デバイス番号を検索します。以下のように表示されます。

5. Swiftの一貫したデザイン

Swift が Quorum 仲裁プロトコルを採用
定義: N: データのコピーの総数。 W: 書き込み操作が受け入れられることが確認されたコピーの数。 R: 読み取り操作のコピー数
強力な一貫性: R+W>N。これにより、レプリカの読み取り操作と書き込み操作が交差し、最新バージョンを読み取ることができることが保証されます。
弱い一貫性: R+W<=N、読み取り操作と書き込み操作のレプリカセットが交差しない可能性があり、この時点でダーティデータが読み取られる可能性があります。
Swift のデフォルト構成は N=3、W=2、R=2 です。つまり、各オブジェクトには 3 つのコピーがあり、書き込みを成功させるには少なくとも 2 つのコピーを更新する必要があります。 2 つの読み取りデータ間に不整合がある場合、検出および複製プロトコルを通じてデータ同期が完了します。
R=1 の場合、ダーティデータが読み取られる可能性があります。このとき、一定の一貫性を犠牲にすることで読み取り速度を向上させることができます（また、データの最終的な一貫性を確保するために、一貫性をバックグラウンドで同期することもできます）。

クォーラムプロトコルの例を以下に示します。

6. Swiftの機能

ネイティブオブジェクトストレージは、リアルタイムのファイル読み取り、書き込み、編集機能をサポートしていません。

完全に対称的なアーキテクチャ、マスターノードなし、単一障害点なし、スケールアップが容易、パフォーマンスと容量が直線的に増加

データは最終的な一貫性を実現し、すべてのコピーを書き込まなくても返すことができます。データを読み取るときは、データのコピーを検証する必要があります。

これは OpenStack のサブプロジェクトの 1 つであり、クラウド環境での展開に適しています。

Swift のオブジェクトストレージと Ceph が提供するオブジェクトストレージの違いは、クライアントがオブジェクトストレージシステムサービスにアクセスする場合、Swift ではクライアントが Swift ゲートウェイにアクセスしてデータを取得する必要があることです。 Ceph は各ストレージノード上の OSD (オブジェクトストレージデバイス) からデータ情報を取得できます。データの一貫性という点では、Swift のデータは結果的に一貫性がありますが、Ceph はクラスタ間で常に強い一貫性があります。

5. Lustre 分散ストレージ

Lustre は、Linux プラットフォームをベースにしたオープンソースのクラスター (並列) ファイルシステムです。これは、Pete Bramble によって設立された Cluster File Systems Inc. によって 1999 年に初めて開発されました。その後、HP、Intel、Cluster File System、米国エネルギー省によって共同開発されました。 2003 年に正式にオープンソースとなり、主に HPC スーパーコンピューティング分野で使用されています。

1. Lustreの主なアーキテクチャ

Lustre コンポーネントには次のものが含まれます。

管理サーバー (MGS): クラスター内のすべての Lustre ファイルシステムの構成情報を保存します。 Lustre クライアントは MGS に接続して情報を取得し、MDS とストレージスペースを共有できます。

 メタデータサーバー (MDS): MDT に保存されているメタデータを管理し、1 つ以上の MDT に保存されているメタデータを Lustre クライアントで使用できるようにします。各 MDS は 1 つ以上の MDT を管理できます。

メタデータターゲット (MDT): MDS は、メタデータ (ファイル名、ディレクトリ、権限、ファイルレイアウトなど) を保存するために使用されます。 1 つの MDT は複数の MDS で使用できますが、一度にアクセスできるのは 1 つの MDS のみです。

 オブジェクトストレージサーバー (OSS): 1 つ以上のローカル OST に対してファイル I/O サービスとネットワーク要求処理を提供します。通常、OSS は 2 ～ 8 個の OST にサービスを提供します。

 オブジェクトストレージターゲット（OST）：ユーザーファイルデータは1つ以上のオブジェクトに保存され、各オブジェクトは別々のOSTに配置されます。

 Lustre クライアント: Lustre クライアントソフトウェアを実行し、Lustre ファイルシステムをマウントできるコンピューティングノード。クライアントソフトウェアには、管理クライアント (MGC)、メタデータクライアント (MDC)、および複数のオブジェクトストレージクライアント (OSC) が含まれます。各 OSC はファイルシステム内の OST に対応します。

 論理オブジェクトボリューム (LOV) は、OSC を集約することによってすべての OST への透過的なアクセスを提供し、論理メタデータボリューム (LMV) は、MDC を集約することによってすべての MDT への透過的なアクセスを提供します。

2. 光沢の特徴

 数万のクライアントシステム、PBレベルのストレージ容量をサポートし、1つのファイルは最大320TBの容量をサポートします。

 RDMAネットワーク、大容量ファイルの読み取りと書き込みのシャーディング最適化をサポートし、複数のOSSでより高い総帯域幅を実現

 レプリケーションメカニズムが欠如しているため、単一障害点が発生します。クライアントまたはノードに障害が発生した場合、そのノードに保存されているデータは、再起動されるまでアクセスできなくなります。

 高性能コンピューティング（HPC）分野に適用可能で、大容量ファイルの連続的な読み書きに適しています。

6. 主流の分散ストレージ技術の比較

いくつかの主流の分散ストレージ技術の特性は次のように比較されます。

さらに、分散ストレージシステムの設計コンセプトによれば、ソフトウェアとハードウェアは分離されており、信頼性やパフォーマンスの向上など、分散ストレージの多くの機能はソフトウェアによって提供されるため、基盤となるハードウェアはもはや重要ではないと考えられる傾向があります。しかし、多くの場合、そうではありません。分散ストレージシステムを統合する場合、適切な分散ストレージテクノロジを選択するだけでなく、基盤となるハードウェアの互換性も考慮する必要があります。一般的に、分散ストレージシステム製品には、ハードウェアとソフトウェアのオールインワンマシン、ハードウェア OEM、ソフトウェア + 標準ハードウェアの 3 つの形式があります。選択する際には、製品の成熟度、リスク回避、運用および保守の要件と、自社の技術力を考慮して、適切な製品形態を選択する必要があります。

OpenStack の紹介

OpenStack は、主にコンピューティング、ストレージ、ネットワークを含む、相互に関連する多数のサブプロジェクトで構成されるオープンソースの IaaS 実装です。

Apache プロトコルの下でリリースされて以来、2010 年の開始以来、AT&T、AMD、Cisco、Dell、IBM、Intel、Red Hat など 200 社を超える企業が OpenStack プロジェクトに参加しています。

現在、OpenStack プロジェクトには 139 か国から 17,000 人を超える開発者が参加しており、その数は増え続けています。

OpenStack はいくつかの AWS インターフェースと互換性があり、より強力な機能を提供するために、OpenStack スタイルのインターフェース (RESTFul API) も提供しています。

他のオープンソース IaaS と比較して、疎結合、高度にスケーラブル、分散アーキテクチャ、純粋な Python 実装、フレンドリーでアクティブなコミュニティにより、非常に人気があります。半年に一度開催される開発サミットには、世界中の開発者、サプライヤー、顧客も集まります。

OpenStack の主なサブプロジェクトは次のとおりです。

Compute (Nova) はコンピューティング仮想化サービスを提供しており、仮想マシンの管理と作成を担当する OpenStack の中核です。簡単に拡張できるように設計されており、複数の仮想化テクノロジをサポートし、標準ハードウェアに導入できます。

Object Storage (Swift) は、オブジェクトストレージサービスを提供する、分散型でスケーラブルなマルチレプリカストレージシステムです。

ブロックストレージ (Cinder) は、OpenStack 仮想マシンにブロックストレージサービスと永続的なブロックレベルのストレージデバイスを提供します。 Ceph、EMC など複数のストレージバックエンドをサポートします。

ネットワーク (Neutron) は、ネットワーク仮想化サービスを提供する、プラグ可能で拡張可能な API 駆動型サービスです。

ダッシュボードは、ユーザーが OpenStack リソースに簡単にアクセスし、使用し、保守できるようにするグラフィカルコンソールサービスを提供します。

Image(glance) は、仮想マシンのディスクとイメージを検出、登録、配信するように設計されたイメージサービスを提供します。複数のバックエンドをサポートします。

Telemetry (Ceilometer) は使用状況統計サービスを提供しており、これを通じて OpenStack 課金機能を簡単に実装できます。

Orchestration (Heat) は、AWS の CloudFormation と同様に、OpenStack 内の多くのコンポーネントを統合し、ユーザーがテンプレートを通じてリソースを管理できるようにします。

Database(Trove)は、OpenStack上に構築されたサービスとしてのデータベースです。

通常、エンタープライズプライベートクラウドを構築する場合、基本的にはNova、Glance、Keystone、Neutronを使用してプライベートクラウドIAASの構築を完了できます。近年、PAAS クラウドサービスが人気を集めています。一般的に、ビジネスシステムは Docker 化され、コンテナクラウドはコンテナオーケストレーションを使用して構築されます。コンテナクラウドは、物理マシン上に独立して直接展開することも、OpenStack プライベートクラウドサービス IAAS 上に構築することもできます。

<<: これら4つのことはエッジコンピューティングの真の姿を理解するのに役立ちます

>>: エッジコンピューティングの4つの課題に対処する方法