クラウドプラットフォーム上で分散ストレージプールを構築し実装した経験について話す

1. 概要

現在、クラウドプラットフォームが広く利用されています。クラウド プラットフォームの IAAS の主要コンポーネントとして、クラウド プラットフォームをオンラインで実装するときには、十分な安定性と柔軟性を維持し、その後の便利な使用と操作および保守を確保し、ビジネス開発をより適切にサポートするために、ストレージ プールを適切に計画する必要があります。金融業界のクラウド プラットフォーム コンピューティング プールでは、ベアメタル、仮想マシン、コンテナーなど、さまざまな実行リソースが実行されます。データベース、アプリケーション サーバー、コンテナー、ファイル ストレージなどのシナリオをサポートするために、エンタープライズ レベルのクラウド プラットフォーム ストレージ プールを確立する場合、通常、さまざまなシナリオのニーズをサポートするストレージ プールを形成するために、さまざまな特性を持つさまざまなストレージ デバイスを使用することを計画する必要があります。

2. アプリケーションシナリオを分析し、複数のクラウドプラットフォームストレージプールを確立する

ストレージを計画および構築する際には、ストレージ アプリケーション シナリオの分析が不可欠です。アプリケーションによって必要なソリューションが異なるため、クラウド ストレージをアプリケーション システムのストレージ、アーカイブ、バックアップ クラウド ストレージ、またはその他のアプリケーションのいずれに使用するかを検討する必要があります。クラウドのアプリケーション シナリオが決定したら、需要に基づいて対応計画を策定できます。たとえば、ビジネス トランザクションをサポートするデータベースなどのアプリケーション システムの場合、容量要件は比較的小さいですが、より高いパフォーマンスが求められます。たとえば、複数のシステム間でファイルを交換する場合、または複数のサーバー ノードが同じ共有ファイル ディレクトリを共有して維持する必要がある場合、共有ファイル サーバーには効果的なアクセス制御と適切な帯域幅が必要です。バックアップに使用するストレージにはセキュリティと可用性が求められますが、アーカイブには大容量で低コストのストレージが必要です。アプリケーション シナリオが決定されると、ストレージ プールの構築の方向も決定されます。

金融業界のコアおよびカウンター取引システムは、大規模なビジネス同時実行性と高いビジネス感度を備えています。したがって、対応するシステムのデータベースとアプリケーションは、極めて高い安定性とパフォーマンスを備えている必要があります。データベースや応答時間要件の高いアプリケーションの効率的で安定した動作を確保し、優れた IOPS と読み取り/書き込みレイテンシを実現するには、エンタープライズ クラウド プラットフォームのストレージ プールに集中型オールフラッシュ ストレージで構築された専用のストレージ リソース プールを計画する必要があります。ストレージ プールのこの部分は通常、ハイエンドの集中型ストレージで構成されます。ハイエンドの集中型ストレージ技術は成熟しており、長期間使用されており、事例も多く、サービスシステムも充実しています。通常、高速 NVME SSD を管理するために高性能ストレージ ヘッドが使用され、非常に高い IOPS 応答速度を実現できます。集中型ストレージは通常、効率的な FC プロトコルを使用してサービスを提供しますが、少数のユーザーは ISCSI などの IP SAN 方式を使用してサービスを提供します。集中型ストレージには、製品設計コンセプトに起因する特定の欠点があります。たとえば、ストレージ デバイスを拡張または移行する必要がある場合、単一のストレージ デバイスの拡張機能は比較的制限されており、拡張の柔軟性が低くなります。集中型ストレージの使用経験は比較的成熟しています。ディスク ドメインの計画、RAID およびホット スペア ディスクの計画、物理ポートの冗長性、マルチパスの計画など、ネットワークを計画する際に考慮する必要がある計画ポイントは広く使用されているため、この記事では詳しく説明しません。

3. クラウドプラットフォーム上の分散ストレージプールの計画と構築

クラウド プラットフォームでは現在、集中型ストレージ プールに加えて、分散ストレージを使用して一般的な仮想マシンやコンテナーをサポートし、大量のファイルを保存します。クラウド ストレージ ソリューションでは通常、分散設計コンセプトが採用されており、コスト、容量、スペースのスケーラビリティ、サービスの可用性、データの信頼性、インターフェイスの汎用性など、さまざまな側面でストレージの品質を向上させることができます。これらの明らかな利点により、分散クラウド ストレージは、ブロック ストレージ、オブジェクト ストレージ、NAS ストレージなどの複数のストレージ形式をサポートする効果的なストレージ タイプになりました。オブジェクト ストレージは、ビデオ画像情報ライブラリなどのデータの保存やサービスの共有によく使用され、便利で統一された管理と効率的なアプリケーションを実現するクラウド プラットフォームの基本コンポーネントになっています。

クラウド プラットフォームで分散ストレージ プールを計画および構築する場合、考慮する必要がある要素には通常、容量、パフォーマンス、セキュリティが含まれます。関連する計画ポイントには、クラスターのノード数、ディスク比率、ネットワーク計画、およびユーザー ロール計画が含まれます。以下では、CEPH 分散ストレージ セットを例に、その計画と実装のパスを説明します。

3.1 分散ストレージクラスタとノードハードディスクの計画と実装

分散ストレージ クラスターの計画の第一歩は、企業の現在のデータ量に基づいて過去 3 ～ 5 年間の容量増加を合理的に分析し、集中ストレージと分散ストレージのデータ量を区別することです。ノード プールは、クラスター内のノードで構成されるストレージ領域単位です。異なるノード プールにはクラスター内の複数のホストが含まれており、ユーザーに異なるストレージ サービスを提供します。ブロック ストレージ、ファイル ストレージ、オブジェクト ストレージ サービスを同時にサポートでき、各サービスは異なるノード プールに配置されます。各ノード プールには、独自の監視ノードとストレージ ノードがあります。ノード プールは独立しており、サブノード プールのストレージ リソースを使用します。データはノード プール内のホストにのみ分散および保存できます。異なるノード プール間のデータは完全に分離されており、相互に影響を与えません。ブロックストレージ、オブジェクトストレージ、ファイルストレージプールの要件を総合的に考慮する必要があります。 3 種類のストレージを独立したストレージ プールに展開し、異なる構成のサーバーをデータ ノードとして個別に計画することをお勧めします。

ディスク プールは、クラスター ノード プール内のハード ディスクで構成されたストレージ領域単位です。異なるディスク プールには、ノード プール内の複数のクラスター ホストに複数のハード ディスクが含まれており、ユーザーにさまざまなストレージ ビジネス サービスを提供します。ハードディスク プールは、異なるストレージ ビジネス データ間の分離や、パフォーマンスの異なるユーザーのストレージ ニーズにも対応できます。

各データノードのハードディスク計画の鍵は、SSD と機械式ハードディスクの比率を考慮することです。予算が十分で、ストレージ プールのパフォーマンス要件が高い場合は、オールフラッシュ メモリを使用してデータ ノードを構成し、オールフラッシュ分散ストレージ プールを構築することも検討できます。ハイブリッド フラッシュを使用して構成する場合、通常は 1 台以上の SSD ディスクがキャッシュ アクセラレーション ディスクおよびメタデータ ストレージ ディスクとして使用され、バックエンドでは 4 ～ 6 台の HDD が容量ディスクとして構成されます。 SSD+HDDがOSDを構成します。たとえば、オブジェクト ストレージ システムは、データ プールとメタデータ プールで構成されます。 HDD+SSDを使用してデータプールを構築できます。ストレージ プール全体のパフォーマンスを確保するには、OSD 内の SSD 容量を 20% 以上にすることをお勧めします。ただし、メタデータ プールを構築する場合は、SSD グループ プールを使用することをお勧めします。また、フォールト トレランスのために 2 台以上の SSD を構成することをお勧めします。通常、データ ノード サーバーは、パススルー モードをサポートする RAID カードを使用して構成する必要があります。

現在市場に出回っている主流のサーバーでは、2.5 インチ ハードディスクと 3.5 インチ ハードディスクの 2 つの仕様のサーバーが存在します。 2.5インチは回転速度が7200/10000/15000の異なる仕様があります。回転速度が速いほど、読み取りおよび書き込みのパフォーマンスが向上します。ただし、サイズの仕様上、2.5インチハードディスクの最大仕様は2.4TBとなります。したがって、単一の 2U サーバーがサポートできる生の容量は比較的限られています。 3.5 インチ ハード ドライブは、3.5 インチ HDD ディスク用のスロットを最大 24 個サポートし、最大 HDD 容量は 16 TB に達します。パフォーマンスを重視する場合は、より多くの SSD キャッシュ アクセラレーション レイヤーを備えた大容量の 3.5 インチ ハード ドライブを使用してデータ ストレージを構成することもお勧めします。

3.2 分散ストレージクラスタネットワークの計画と実装

クラウドストレージのパフォーマンスとセキュリティを確保するために、クラウドプラットフォームの分散ストレージクラスターは通常、ストレージビジネスネットワーク（ストレージ外部ネットワーク）、ストレージフロントエンドネットワーク（ストレージ内部ネットワーク）、ストレージバックエンドネットワーク（ストレージ内部ネットワーク）の3つのネットワークプレーンに論理的に分割されるように計画されています。パフォーマンスを確保するには、ストレージのフロントエンド ネットワークとバックエンド ネットワークを分離することをお勧めします。ただし、ネットワーク ポート リソースが限られている場合は、フロントエンド ネットワークとバックエンド ネットワークを統合できますが、ビジネス ネットワークとストレージ内部スイッチング ネットワークを分離する必要があります。

ストレージノード用の管理ネットワークもあります。一般的なネットワークの場合、3 つのデュアル ポート 10 ギガビット ネットワーク カードが推奨されます。分散ストレージの場合、GE ネットワークを使用できる管理ネットワークを除き、パフォーマンスを確保するために、他のネットワークでは 10GE 以上のネットワークを使用することをお勧めします。企業の IP アドレス割り当てによると、バックエンドおよびフロントエンド ネットワークの IP アドレスはストレージ プールの外部では使用されないため、一般的でないプライベート ネットワーク アドレスを使用できますが、ビジネス ネットワークの IP アドレスは企業の ISCSI ネットワークに含まれるものと見なされます。

表1: 分散ストレージクラスタネットワーク計画表

3.3 分散ストレージクラスタの役割の計画と実装

分散クラスターは、管理ノード、監視ノード、ストレージノードの 3 つの役割に分かれています。これら 3 つのロールのサービスは、同じ物理マシンに展開できます。単一のサービス展開では、3 つのロールが同時に展開されます。単一の物理サーバーに障害が発生すると、そのノード上の監視ノード、管理ノード、およびストレージ ノードにも同時に障害が発生します。リスク共有の観点から、物理サーバーの台数が十分にある場合は、ストレージノード、管理ノード、監視ノードを異なる物理サーバーに分離することをお勧めします。ストレージ クラスター内のノード数が 3 の場合、物理サーバーの制限により、管理ノード、監視ノード、およびストレージ ノードを 1 つに展開できます。

管理ノードは主にストレージ クラスターの管理プログラムを制御するために使用されます。計画後、管理ノードは計画された情報に従ってクラスターをインストールおよび展開し、監視情報をグラフ化し、ストレージ ノード サービスにコマンドを発行するなどします。クラスターは、アクティブ ノード 1 つとスタンバイ ノード 1 つの合計 2 つの管理ノードで構成する必要があります。 監視ノードは主にクラスターの健全性状態を監視するために使用されます。各クラスター内の監視ノードの数は、3 ～ 7 の奇数にする必要があります。3 ノード クラスターのノード ロール展開の推奨計画は次のとおりです。

表2: 分散ストレージクラスタの役割計画表

3.4 分散ストレージクラスタ構成計画

クラスターの高いフォールト トレランスを確保するには、クラスター サーバーが搭載されるラックで、キャビネットの電源障害やキャビネット ネットワークの切断などの障害シナリオを十分に考慮する必要があります。したがって、ラックの配置を計画するときは、実際の物理的な配置に基づいてラックの作成と計画を行い、1 つのラックに 1 つのノードだけを配置しないようにすることをお勧めします。

データ プールの冗長性戦略の計画。ストレージ クラスターでは、単一サーバーの障害や単一ハードディスクの障害などのシナリオを考慮し、安全なデータ冗長性戦略を計画する必要があります。一般的なデータ冗長性戦略には次の 2 つが含まれます。

（１）マルチコピー戦略複数のコピーは現在、分散ストレージにおける一般的なソリューションです。マルチコピー ソリューションに従ってフォールト トレランスを計画する場合、冗長性を確保するために複数のコピーに数倍のストレージ スペースが必要になります。コピーの数が多いほど、セキュリティが高くなります。ただし、欠点は、データを保存するために必要なスペースも指数関数的に増加することです。 N 個のコピーの最終的な使用可能容量は、ハード ディスクの実際の生の容量の 1/N になります。現在、最も一般的な 2 つの戦略は、2 コピーと 3 コピーです。データセキュリティがより高い業界やクラスターの場合は、3 つ以上のコピーを使用することをお勧めします。

レプリカ数とクラスターノード数の対応の計画:

2～6 部のコピーをサポートし、一般的には 2 部と 3 部のコピーを使用し、3 部のコピーの使用を推奨します。

レプリカ 2 つ、ノード 2 つ以上、4 つのノードが推奨されます。

レプリカは 3 つ、ノードは少なくとも 3 ～ 4 つ、5 つのノードが推奨されます。

レプリカ 4 つ、ノード 5 つ以上、6 つのノードを推奨。

（２）消去コードRAID 5 ストレージと同様に、消失訂正符号を使用して計画されたストレージ プールは、最終的に実際のハード ディスクの生容量の約 70% の使用可能容量を実現できます。消失訂正符号は、利用可能な容量が大きいデータ保護戦略です。データを複数のデータ ブロックに分割し、これらのデータ ブロックを展開してエンコードし、冗長チェック ブロックを生成して、異なる場所に保存します。消失訂正コード冗長化テクノロジを使用するクラスターの場合、保存されたデータの消失訂正コード検証を実行するために一定量のコンピューティング リソースが必要になるため、データ ノードの CPU オーバーヘッドが大きくなり、ストレージ ノードの CPU モデルに高い要件が課せられます。

ブロック ストレージとオブジェクト ストレージの両方のデータ プールでは、3 つのコピーまたは消去コーディング戦略を使用できます。クラスターが適切に動作し、ユーザーのニーズに応えるためには、単一のハードディスク (または単一のノード) の障害に耐えられる必要があります。クラスター用に一定量の容量を予約する必要があります。確保する必要があるスペースの具体的な量は、添付の表を使用して計算できます。

薄型収納機能。豊富な運用および保守経験を持つシステム管理者は、割り当てられた LUN の場合、アプリケーション システムは通常、LUN のすべての領域を使用しないことを知っています。ストレージが薄型構成を採用している場合、スペースの一部を予約用に確保するのではなく、使用するときだけストレージスペースを占有します。たとえば、クラスターの使用可能な容量が 10 TB で、1 TB の 2 レプリカ プールにストレージ ブロックが作成された場合、クラスターの使用可能な容量は減少せず、10 TB のままになります。 0.5T のデータがストレージ ブロックに書き込まれると、占有されるクラスター容量は 0.5T * 2 (コピー 2 つ) = 1T となり、クラスターの残りの使用可能容量は 9T になります。ストレージがシックプロビジョニングされている場合、スペースの一部が予約されます。

シン ボリューム機能は、テスト環境での使用を検討できます。通常、シン ボリュームでは複数の仮想マシンが実行されるため、ストレージ リソースの使用率が向上します。ただし、実稼働環境でシン ボリューム機能を有効にすると、より大きなリスクが発生します。 LUN スペースが不足すると、スペース不足により複数の仮想マシンまたは複数のビジネスがダウンタイムに陥るリスクが生じます。さらに、分散ストレージは拡張の柔軟性に優れているため、実稼働環境を計画する際には合理化された機能を有効にすることはお勧めしません。

あらゆる部分には、長所と短所があります。企業のクラウド プラットフォーム ストレージ プールを確立するための鍵は、ビジネス分析です。企業のストレージ管理担当者がビジネスを基盤とし、自社のビジネス発展の傾向とニーズを明確に理解し、ビジネスの具体的なニーズと予測に基づいて進めれば、クラウド プラットフォームのストレージ プールの計画と構築に冷静に取り組むことができます。新しいストレージ管理計画を立てる際には、技術担当者は各ビジネス システムについてより全体的な視点とより包括的な理解を持つ必要があります。計画の考え方を単一システムからシステムグループに転換し、各システムのパフォーマンスピークと容量ピーク量、ピークが発生する時間などの要素を十分に評価し、システムのコアニーズを十分に考慮し、分散型と集中型のメリットとデメリットを習得し、ビジネスシステムのニーズに基づいて具体的な分析を行い、科学的にマッチングし、合理的に構築を計画して実装する必要があります。