詳細分析: 金融企業向けコンテナ クラウド プラットフォームのストレージを選択するにはどうすればよいでしょうか?

1. コンテナクラウドプラットフォームとコンテナクラウドストレージ

クラウド プラットフォームにおける IaaS/PaaS は、クラウド テクノロジーの 2 つの比較的広く使用されている機能です。 PaaS は IaaS をベースにしており、ミドルウェア、データベース、コンテナ クラウドなどの便利な導入および運用・保守機能を提供します。ミドルウェアとデータベースは、仮想マシンの展開形式とコンテナ リソースの展開を提供できます。コンテナはプライベート クラウドの一般的な基本環境です。コンテナ クラウドは、多くの場合、プライベート クラウド内の PaaS のコンポーネントとして、または個別のコンテナ クラウドの形で表示されます。コンテナ自体の観点から見ると、IaaS レイヤーの基本的なコンピューティング能力を提供し、ステートレス アプリケーションでよく使用されます。コンテナが消えた後は、消えた時点の状態は保存できません。現在一般的に普及しているコンテナ技術とは、一般的に Open Container Initiative (OCI) の標準と仕様に準拠したコンテナ技術を指します。最も一般的な Docker に加えて、Podman、Containerd、CRI-O もあります。相対的に言えば、Docker は現在より広く使用されており、最も一般的なコンテナ エンジンです。金融業界では通常、コンテナのオーケストレーションと管理、およびコンテナのスケジューリングの実装に K8S を使用します。コンテナ技術の応用により、PaaS プラットフォームの実装に新しいリソース形式が提供されます。 K8S は、宣言型の構成と自動化を容易にする、コンテナ化されたワークロードとサービスを管理するための、移植可能で拡張可能なオープンソース プラットフォームです。金融プライベート クラウドでは、通常、テナントは IaaS リソースとコンテナ クラスター リソースを分離するために使用されます。テナントは、さまざまなアプリケーション システムを実行するために 1 つ以上の K8S クラスターを構成できます。コンテナとクラウド コンピューティング テナント機能を組み合わせることで、コンテナ クラウド プラットフォーム機能を実現できます。

現在、都市商業銀行はコンテナ クラウドを使用しており、これは主にアプリケーション層の一部のコンポーネントを展開するために使用されます。フラッシュセール、プロモーションオファー、その他の機密ビジネスなど、弾力的なスケーリングを必要とするビジネスシナリオでは、コンテナを使用して、アプリケーションレイヤーで純粋な Java プログラム、ミドルウェア、ステートレス Redis クラスターなどをデプロイします。さらに、コンテナ プラットフォームで状態を保存する必要のあるシナリオに徐々に遭遇することになります。 MySQL や Redis などのデータベースを導入しており、これらのデータベースによって生成されたデータをバックアップする必要があります。

2. K8Sストレージシステムの概要:

コンテナ ストレージについて話すときは、まず CSI/PV/PVC/StorageClass の基本的な概念を理解する必要があります。

2.1 ＣＳＩ

CSI は Container Storage Interface の略で、コンテナ オーケストレーション システム (COS) 上のユニバーサル コンテナ ストレージ インターフェイスです。サードパーティのストレージベンダーは、K8S のコアコードを変更することなく CSI プラグインを作成することで、K8S 上のコンテナ化されたワークロードにファイルストレージとブロックストレージを提供できます。事実上のコンテナ オーケストレーション (CO) 標準として、K8S の CSI 永続ストレージ インターフェイスのサポートはすでに商用化されています。 K8S V1.13 はすでに CSI コンポーネントの GA バージョンをサポートしています。現在、K8S の主な永続ストレージは、主にこの標準インターフェースを介して接続されています。

Pod 作成プロセス中に、外部ボリューム ストレージの作成を指定すると、PVC は StorageClass の動的プロビジョニングを通じて対応するバインドされた PV を生成します。 PV の作成とバインドは CSI によって実行されます。このとき、CSI はボリュームのロード方法とマウント方法を定義できます。

2.2 PVとPVC

PV の正式名称は Persistent Volume で、永続的なストレージ ボリュームです。ストレージ ボリュームを記述または定義するために使用されます。 PV は一般的に運用と保守によって作成されます。 PV には、accessModes と PersistentVolumeReclaimPolicy という 2 つの重要なパラメーターがあります。

accessModes: 4 つのタイプをサポートします。最初のタイプは ReadWriteMany です。これは、ボリュームをマウントして、クラスター内の複数のノードで読み取りおよび書き込みができることを意味します。 2 番目のタイプは ReadWriteOnce で、ボリュームは単一のクラスター ノードによってのみマウントおよび読み取ることができます。 3 番目のタイプは ReadOnlyMany です。ボリュームは複数のクラスター ノードによってマウントでき、読み取りのみ可能です。 4つ目は、新しく追加された機能 ReadWriteOncePod です。このボリュームは、単一のノード上の単一の Pod によってのみ読み取り/書き込みモードでマウントできます。 PVC アクセス モードが ReadWriteOncePod の Pod A が作成されると、K8S はクラスター全体で 1 つの Pod だけが PVC の読み取りと書き込みを実行できるようにします。 Pod B が作成され、Pod A と同じ PVC (ReadWriteOncePod) を参照する場合、PVC は Pod A によって参照されるため、Pod B は起動に失敗します。

PersistentVolumeReclaimPolicy: 3 つのポリシーもあります。このポリシーは、関連付けられた PVC が削除された後に PV 内のデータがどのように処理されるかを示します。

（１）保持は手動で再利用する方法です。通常、保持する必要があるデータとログを保存するため、実稼働システムで最も一般的に使用されます。保持 バインドされた PVC を削除すると、PV は解放済みとしてマークされ (PVC は PV からバインド解除されますが、リサイクル ポリシーはまだ実行されていません)、以前のデータは PV にまだ保存されていますが、PV は使用できません。データを手動で処理し、PV を削除する必要があります。

(2) リサイクル: リサイクル ポリシー リサイクルは、ボリュームに対していくつかの基本的な消去操作 (rm -rf /thevolume/*) を実行し、その後、ボリュームを新しい PVC クレームに使用できるようにします。

（3）削除削除リサイクルポリシーをサポートするボリュームプラグインの場合、削除アクションにより、K8SからPersistentVolumeオブジェクトが削除され、外部インフラストラクチャ（AWS EBS、GCE PD、Azure Disk、Cinderボリュームなど）から関連するストレージアセットも削除されます。動的にプロビジョニングされたボリュームは、StorageClass に設定されたリサイクル ポリシーを継承します。デフォルトのポリシーは削除です。

PVC は、使用するストレージの種類や満たす必要がある条件を記述するために使用されます。正式名称は Persistent Volume Claim で、永続的なストレージ要求を意味します。開発者はこれを使用して、コンテナーに必要なストレージを記述します。たとえば、次の PVC は NFS を使用します。PV は既存のストレージであり、PVC は必要なストレージです。 2 つがペアになるには、次の 2 つの条件が必要です。

PV と PVC の仕様キー フィールドは一致する必要があります。たとえば、PV のストレージ容量は、PVC で宣言された容量よりも小さくすることはできません。

PV と PVC の storageClassName フィールドは一致している必要があります。

2.3 ストレージクラス

StorageClass は、ストレージ クラスを記述するためのメソッドを提供します。異なるクラスは、異なるサービス品質レベルやバックアップ戦略、またはその他の戦略にマッピングされる場合があります。 PV は運用保守担当者によって作成され、ユーザーは PVC を操作します。ただし、大規模クラスターでは PV の数が多くなる場合があります。これらの PV すべてを運用・保守で手動で処理する必要がある場合、それは面倒な作業でもあります。そこで、動的プロビジョニングの概念が導入されます。動的プロビジョニングの鍵となるのは、PV テンプレートの作成に使用される StorageClass です。 StorageClass を作成するときは、ストレージの種類やサイズなどの PV 属性を定義する必要があります。また、このタイプの PV を作成するには、ストレージ プラグインが必要です。最終的な効果は、ユーザーが PVC を送信してストレージ タイプを指定すると、それが定義した StorageClass と一致する場合、PV が自動的に作成され、それにバインドされることです。

3. コンテナクラウドストレージタイプの選択要件分析

コンテナ クラウドでは、K8S にデプロイされたアプリケーションを Pod コンテナの形式で実行します。 Pod はステートレスであるため、Pod がデータ ボリュームをマウントしない場合、Pod が削除または再起動されるとデータは消えてしまいます。このデータを長期間保存したい場合は、Pod データ永続ストレージを使用する必要があります。さまざまなビジネス シナリオに基づいて、コンテナ クラウドのストレージ要件は、非永続ストレージと永続ストレージの 2 つのタイプに分けられます。

Pod の再起動後にデータが失われないようにするだけでなく、Pod 間でファイルを共有する必要が生じることもあります。したがって、Pod ストレージの永続性という話題が生まれます。クラウド プラットフォームのコンテナ クラウドでは、コンテナ上に永続ストレージをマウントする問題を解決するためのソリューションがいくつか提供されていますが、主に K8S が提案するボリューム オブジェクト ソリューションをカプセル化することで解決されています。

3.1 コンテナクラウドの非永続ストレージ要件

コンテナ クラウド コンテナは、物理サーバーまたは仮想サーバー上で実行されます。コンテナ アプリケーションには、イメージ リポジトリと実行中のコンテナ インスタンス、および一部のコンテナによって生成されるログが必要です。コンテナ クラウドでストレージを使用する必要があるシナリオは次のとおりです。

1. コンテナインスタンスの作成と操作。コンテナを作成するときには、一定量のストレージスペースが必要になります。各コンテナに必要なスペースのサイズは、コンテナの数と、コンテナにデプロイされる基本環境およびコンテナ アプリケーションによって決まります。コンテナ ワーカー ノード全体のストレージ スペースのサイズは、実行中のコンテナの種類と数によって決まります。単一のワーカー ノードのサイズは、そのノード上で実行される可能性のあるコンテナーのスペースの合計をカバーする必要があることに注意することが重要です。実行中のコンテナを保存するために使用されるストレージ スペースには比較的高いパフォーマンス要件があり、コンテナの高速な動的スケーリングとファイルの高速な読み取りおよび書き込みをサポートできます。

2. コンテナ アプリケーションの操作中に生成される一時ファイルなど、永続的なストレージを必要としないファイル。

アジャイルビジネスは通常、コンテナ内で実行されます。アジャイル ビジネスの特徴は、複数の作業ノードで開始または停止できるコンテナーの高度なビジネス同時実行性と弾力的なスケーリングをサポートすることと要約できます。上記の特性を考慮すると、非永続ストレージ用のコンテナの要件は、主にパフォーマンス レベルに集中します。スペース要件は高くありませんが、動作中のノードは簡単に識別でき、優れた IOPS 同時読み取りおよび書き込み機能を備えている必要があります。非永続ストレージでは主にローカル ハード ディスクまたは集中ストレージ マッピング ブロック ストレージが使用され、動作中のノードが認識できる限り要件を満たすことができます。

3.2 コンテナクラウドの永続ストレージ要件

これまで、銀行業界では主に社内管理用や業務量の少ないエッジ アプリケーションを実行していました。近年、コンテナ技術の成熟に伴い、銀行の重要なトランザクション業務の多くが、生産トランザクションをサポートするためにコンテナを使用するようになりました。その結果、永続的なストレージにコンテナが使用されるシナリオが増えています。主な使用シナリオは以下のとおりです。(1)画像や文書などのアプリケーションファイルの永続的な保存。このタイプのストレージは、ユーザー アプリケーション、入力済みフォーム、ビジネス トランザクションのビデオ録画などの重要な認証情報を保存するために銀行でよく使用されます。コンテナが消えてアーカイブされた後も長期間保存する必要があります。 （２）業務ログの永続的な保存コンテナが重要な業務である場合、その後のシステム障害分析やシステム最適化を容易にするために、業務によって生成されるトランザクションログや操作ログなどを保存する必要があります。 （３）KafkaやRedisなどのコンポーネントへのデータの永続的な保存。たとえば、複数のコンテナーが同時にメッセージ キューの読み取りと書き込みを行う必要があり、アプリケーションを再起動した後、キュー内の未使用のメッセージを処理する必要があります。または、Redis データベース内のデータを長期間保存する必要があります。 （4）イメージリポジトリ：イメージリポジトリは、作成されたすべてのイメージを統合して保存する場所であり、主にテストや本番環境でよく使用されるコンテナイメージを保存するために使用されます。コンテナ イメージは、Docker コンテナを作成するための指示が含まれる静的な読み取り専用ファイルです。コンテナ イメージ リポジトリのストレージ要件は主にスペース要件であり、パフォーマンス要件は高くありません。

コンテナアプリケーションが永続ストレージを使用する必要がある場合、永続ストレージ要件の主な特徴は次のとおりです。(1) 永続性要件:ビジネス分析の基礎となる本番システムのビジネスログは永続的に保存されます。 （２）ポッドがドリフトした後、同じストレージを別のノードにマウントすることで状態データの移行が実現されます。 （３）共有ストレージ要件：業務ファイルや画像の分散共有要件。 （４）拡張要件：柔軟なストレージ拡張要件、コンテナノードの柔軟な拡張および移行機能要件。 （５）パフォーマンス要件：画像や文書などのアプリケーションファイルの書き込みパフォーマンスは、ビジネスシステムの同時サポート能力に直接関係します。 （6）セキュリティと高可用性の要件：デュアルセンターアーキテクチャを確保するには、イントラネットストレージが必要です。

4. Container Cloud でサポートされるストレージの種類

コンテナのストレージ オプションには、永続型と非永続型も含まれます。コンテナ クラウドは、ISCSI/FC などのマップされたブロック ストレージ、NFS ファイル システム、オブジェクト ストレージ システム、AWS などのパブリック クラウド ストレージ サービス、EmptyDir や HostPath などの K8S 組み込みストレージ タイプなど、幅広いストレージ タイプをサポートしています。最も一般的なものは、NFS マップ ファイル システムと Hostpath 組み込みストレージです。 Cephfs などの分散オブジェクト ストレージ システムは、柔軟な拡張機能と大規模なストレージ機能を備えているため、現在、一部のユーザーによってコンテナのバックアップに使用されています。

HostPath ボリュームは、Pod がマウントされているホスト マシン上のディレクトリまたはファイルを参照します。 HostPath Volume を使用すると、コンテナーはホストのファイル システムをストレージとして使用できるようになります。 Hostpath はノード レベルのストレージ ボリュームです。 Pod が削除された後も、ストレージ ボリュームは Pod が実行されているワークノード上に存在し、削除されません。同じ Pod がノードにスケジュールされている限り、Pod が削除され、このノードに再スケジュールされた後も、対応するデータは存在します。 Hostpath ストレージ ボリュームの欠点は、Pod が削除された後、再作成時にデータが失われないように、同じノードにスケジュールする必要があることです。複数のノードがあるシナリオには適していません。

EmptyDir ボリュームは、Pod がノードに割り当てられたときに作成されます。 K8S はノードにディレクトリを自動的に割り当てるため、ホストノード上の対応するディレクトリ ファイルを指定する必要はありません。このディレクトリの初期内容は空です。 Pod がノードから削除されると、EmptyDir 内のデータは完全に削除されます。 EmptyDir ボリュームは、一部のアプリケーションで永続的に保存する必要のない一時ディレクトリや、複数のコンテナの共有ディレクトリなどに主に使用されますが、永続的なストレージには適していません。

4.1 非永続ストレージの選択経験

非永続ストレージを使用する場合、アプリケーション シナリオには、高 IO および低レイテンシのシナリオが含まれます。主にローカルストレージとブロックストレージが使用されます。パフォーマンスと接続方法を考慮すると、ローカル ハード ディスク上に HostPath または集中型ブロック ストレージを構築できます。相対的に言えば、IOPS と帯域幅は比較的高いです。ローカル SAS インターフェイス ハード ディスク グループまたは FC によって提供される LUN スループットは通常 1GB を超え、基本的に単一の動作ノードのコンテナー クラスター IO 要件を満たすことができます。動作ノードのローカル ハード ディスクを使用する場合は、ストレージの一定のフォールト トレランスを確保するために、Raid カードを介して Raid5 以上を構成することをお勧めします。 K8S クラスター自体は単一のコンテナインスタンスの例外を処理する機能を持っていますが、稼働ノード内の単一のハードディスクに障害が発生すると、稼働ノード全体のファイルシステムに異常が発生し、ノード上のコンテナサービスが一括して中断されます。これはビジネス レベルではまだ認識可能であり、通常のユーザー セッションが失われ、ユーザーが再度ログインする必要が生じる可能性があります。業務システム全体の信頼性を向上させるために、RAID を設定した後、単一のハードディスクのフォールト トレランスを設定することをお勧めします。

ブロック ストレージ デバイスは、データベース、ミドルウェア、その他のサービスなど、IO とレイテンシの要件が高いアプリケーション シナリオに適しています。非共有シナリオでは、ブロック ストレージは排他的であり、一度に 1 つの Pod のみが使用できます。ブロック ストレージは、非共有データのビジネス シナリオで検討できます。レプリカごとに 1 つのストレージ ボリュームを持つステートフル アプリケーションに適しています。ブロック ストレージを使用する場合は、集中型ブロック ストレージまたは分散型ブロック ストレージを選択できます。集中型ブロック ストレージを使用する場合、従来の Iaas で仮想マシンまたはベア メタルに接続された集中型ストレージの使用とほとんど変わりません。接続には通常、FC ネットワークと ISCSI ネットワークが使用されます。ただし、クラウド プラットフォームでは、IPSAN を介してコンピューティング仮想化サーバーにマッピングされた分散ストレージがより頻繁に使用されます。分散ストレージは、ブロック ストレージ、オブジェクト ストレージ、NAS ストレージなど、さまざまな種類のストレージ サービスを提供できます。 SSD+HDD またはオールフラッシュ構成のハードディスク グループを使用することで、分散ストレージのパフォーマンスを向上できます。

分散ブロック ストレージはスケーラビリティに優れており、一般的なプロトコルには isCSI などがあります。ローカル ストレージに関しては、ブロック ストレージは通常、AWS Elastic Block Store や Azure Disk などの RWO のみをサポートします。 GCE Persistent Disk、RBD、ScaleIO などの一部の製品は ROX をサポートできます。

4.2 永続ストレージの選択に関する推奨事項

永続ストレージを選択する際には、コンテナのビジネス シナリオへの適応性、ストレージ パフォーマンス、K8S CSI のサポート、拡張のサポート、クローンのサポートなどを考慮することをお勧めします。現在、一般的に使用されている永続ストレージ方式は、NAS とオブジェクト ストレージの 2 つです。

（１）オブジェクトストレージ

コンテナにオブジェクト ストレージが使用されるシナリオと NAS ストレージが使用されるシナリオには、重複する部分があります。たとえば、コンテナインスタンスでドキュメントや画像などの小さなファイルを共有する必要がある場合は、NAS とオブジェクトストレージの両方を検討できます。しかし、選択に直面したときには、一定の違いがあります。たとえば、アプリケーションがイメージングシステム、ビデオライブラリ管理システム、画像取得、分析システムなどであり、保存される画像データの量が数PBレベルに達し、単一ファイルのサイズがMBレベルを超え、ファイル数が数万以上である場合は、オブジェクトストレージがより推奨されます。メディアや画像などのメディア ファイルの読み取り専用シナリオでは、上記のファイル タイプはオブジェクト ストレージを通じて読み取ることができます。オブジェクト ストレージを使用する場合、通常、CSI 構成は必要ありません。オブジェクト ストレージでは、リソースの抽象化に PV/PVC は必要ありません。アプリケーションは、読み取りと書き込み用にアプリケーション内でオブジェクト ストレージのアドレスとキーを構成するだけで、オブジェクト ストレージに直接アクセスして使用できます。

（２）NASストレージ

NAS ストレージは、ログ ストレージなど、共有ディレクトリを読み取って長期間保存する複数のコンテナーをサポートします。異なる Pod コピーのログは共有ファイルなどの同じディレクトリに保存され、複数の Pod が同時に読み取りと書き込みを行うことができます。都市商業銀行の既存のケースでは、集中型 NAS ストレージまたは分散型 NAS ストレージを使用して永続ストレージ サービスを提供して、ファイル システムをコンテナ クラウドに分割し、PV ボリュームをマウントするというソリューションがより一般的です。現在、集中型または分散型の NFS ストレージは、安定性、高可用性、柔軟な拡張機能、および管理の利便性の面での要件をよりよく満たす永続ストレージ サービスを提供するために使用されています。その利点は次のとおりです。

a. NAS を使用して永続的なストレージを提供することで、Hostpath と比較して、マルチノード コンテナー内の分散アプリケーションの集中ログ管理を実現し、ログ管理の複雑さを軽減し、トラブルシューティングの効率を向上させることができます。

b. NAS ストレージ プラットフォームを使用する場合、ポート バインディングを使用して帯域幅を増やし、ビジネス負荷が高い場合でも帯域幅のパフォーマンスを確保し、高いビジネス同時実行性をサポートできます。

紀元前NAS ストレージ プラットフォームを使用すると、高い安定性と高い耐障害性を備えたストレージ サービスが提供されます。

コンテナがエラスティック スケーリングまたは障害回復を実行している場合、ストレージ ボリュームは頻繁にマウントおよびアンマウントされます。実稼働環境全体の安定性を確保するには、ボリュームのマウントおよびアンマウント操作中に十分な安定性を確保する必要があります。同時に、PV ボリューム サーバーは、アプリケーションの遅延を回避するために高いパフォーマンスを保証できる必要があります。専用の集中ストレージ NFS を使用すると、比較的安定した高性能なストレージ サービスを提供できます。集中型ストレージ デバイスは、RAID、冗長ストレージ ヘッド、分散クラスター マルチノードなどの機能により、ハードウェア障害が発生した場合でも高い安定性を保証します。 NFS のパフォーマンスが不十分な場合、集中型ストレージではポート バインディングを追加することで帯域幅を増やすことができます。分散ストレージでは、バインドされたポートを追加し、分散ノードを拡張することで帯域幅を増やし、クラスター全体のストレージ パフォーマンスを向上させることもできます。

a.実用的な災害復旧計画: 重要な業務は複数のセンターに展開する必要があります。 NAS ストレージを使用することで、マルチセンター アーキテクチャ内のコンテナ クラスターのデータ同期を実現し、重要なビジネスのコンテナ化された展開に実用的な災害復旧計画を提供できます。通常、銀行業界では、重要な業務を 2 つの場所にある 3 つのセンターに展開する必要があります。集中ストレージと分散ストレージのデュアルセンターデュアルアクティブ機能により、デュアルセンターアーキテクチャを備えたコンテナクラスターも構築できます。

b.簡素化された運用および保守管理: コンテナ ステートフル アプリケーションの増加に伴い、従来のストレージ運用および保守作業も課題となります。全体的なソリューションでは、俊敏かつ安全な運用と保守の両方を考慮する必要があります。集中型および分散型の NAS ストレージ製品には、ユーザーフレンドリーで便利な管理方法が備わっています。 NAS ストレージ製品を使用すると、直感的なグラフィカル インターフェイスを使用して、便利な構成とスイッチング管理が可能になり、操作と保守の複雑さが軽減されます。

紀元前クライアントはユーザー認証メカニズムを有効にすることができ、データはプレーンテキストまたは暗号テキストで送信されるため、比較的安全です（通常、ローカルエリアネットワークでの使用が推奨されます）。

NAS ストレージには明らかな利点がありますが、他のタイプと比較すると、いくつかの欠点もあります。

a. NAS ストレージは、ブロック ストレージと比較すると、高同時実行性における IOPS 効率/パフォーマンスの点で不利です。搭載するコンテナの数が多すぎると、ブロックストレージに比べて IOPS パフォーマンスが低下します。

b. K8S シナリオでは、K8S クラスターに NAS ディレクトリが設定されている場合、クォータ制限はなく、リソースを申請するすべてのユーザーはすべての NFS ストレージ プールを申請するのと同じです。

4.3 ケーススタディ

現在、弊社の環境では、独立した K8S コンテナ クラスターを使用して業務プログラムを実行する業務システムが複数存在します。そのうち、より大規模な業務システムでは、K8S クラスターに 12 個の Pod がデプロイされており、主に業務システムの Java アプリケーションと Web アプリケーションが実行されます。永続ストレージのシナリオは、主に業務操作ログを保存することです。コンテナ クラスターの永続ストレージは、デュアル センター レプリケーション ストレージ クラスターを備えた OceanStor シリーズ ストレージによって提供されます。アクティブ/アクティブ NAS ストレージを構成してコンテナ クラウド クラスターにサービスを公開することで、Pod 使用のための PV マッピングとして使用されます。他のクラスター セットは、コールド スタンバイ ソリューションを使用して構成されています。メインセンターの K8S クラスターはメインセンターの分散ストレージ (読み取りおよび書き込み可能) を使用し、SDS 分散クラスターはスタンバイセンターにデータを非同期的にコピーし、災害復旧センターのコールドスタンバイ K8S 災害復旧クラスターはスタンバイセンターの分散ストレージ (読み取りおよび書き込み不可) をマウントします。メイン センターに障害が発生し、メイン センターの K8S クラスターとストレージ クラスターに障害が発生した場合は、スタンバイ センターの K8S クラスターを手動でプルアップし、スタンバイ センターの分散ストレージ クラスターを読み取りおよび書き込み可能にプルアップして、ビジネス継続性を確保します。 Huawei OceanStor ストレージの NAS 機能も、このようなサービスを実行するために使用されます。要約すると、次のような利点が反映されます。

（1）Hostpathと比較して、マルチノードコンテナ内の分散アプリケーションの集中ログ管理を実現し、ログ管理の複雑さを軽減し、トラブルシューティングの効率を向上させます。

（２）このストレージプラットフォームを使用することで、ポートバインディングを使用して帯域幅を増やし、高いビジネス負荷下での帯域幅パフォーマンスを確保し、高いビジネス同時実行性をサポートできます。

（３）ストレージプラットフォームは、高い安定性と高い耐障害性を備えたストレージサービス、集中型ストレージRAID、冗長ストレージヘッドなどのハードウェア耐障害性機能を提供し、コンテナログの安全な保管をサポートし、ビジネスの継続的かつ安定した運用を保証します。

（4）このストレージプラットフォームを使用して実用的な災害復旧ソリューションを提供します。重要なビジネスは複数のセンターに展開する必要があります。 Huawei NAS ストレージを使用することで、マルチセンター アーキテクチャ内のコンテナ クラスターのデータ同期を実現でき、重要なビジネスのコンテナ化された展開に実用的な災害復旧ソリューションを提供できます。

（5）このストレージプラットフォームを使用することで、運用・保守管理機能が簡素化されます。直感的なグラフィカルインターフェースを備えたNASストレージ製品を使用することで、便利な構成と切り替え管理が可能になり、運用・保守の複雑さが軽減されます。​