分散ストレージ - ハードディスク容量の不均一性によるキャッシュディスク寿命の急速な低下の分析

[51CTO.com からのオリジナル記事] Ceph 分散ストレージは、スケーラビリティ、信頼性、パフォーマンスにおいて独自の利点があります。複数のサーバーを迅速に拡張し、PB レベルの容量まで動的に拡張できます。マルチコピー メカニズムにより、高いデータ信頼性、バランスの取れたデータ分散、高い同時パフォーマンスが保証されます。現在、インターネット、科学研究、教育、製造、政府など多くの分野で広く使用されています。 ZStack クラウド プラットフォームは現在、分散ブロック ストレージを使用した Ceph 分散ストレージへの接続をサポートしています。つまり、librbd ブロック デバイス インターフェイスを使用して、クラウド ホストとクラウド ディスクの IO 読み取りと書き込みのための Qemu アクセスを提供します。

Ceph 分散ストレージには上記の利点と特性がありますが、実際には、ハードウェア、特にハードディスクとネットワークの選択と構成には特別な要件があります。構成が不適切だと、ストレージの信頼性とパフォーマンスに影響が出ます。

最近、ZStack 実稼働環境の Ceph 分散ストレージの定期検査中に、顧客が新しく購入した 5 台のサーバーの SSD 寿命が異常に短くなっていることが判明しました。具体的な現象としては、半年使用した後、サーバーの帯域外管理インターフェースでは SSD 寿命損失が 89% しか表示されませんが、smartctl を使用して読み取ったメディア損失パラメータでは依然として 100% と表示されます。

この時点で、どちらのデータがより信頼できるのか疑問に思うかもしれません。 SSD の寿命が 89% しかない場合、Ceph 分散ストレージをどのように調整して最適化できますか?

問題のレビュー

この問題に対処するために、この分散ストレージのアーキテクチャを確認しましょう。当時、分散ストレージを導入するために、新規購入＋既存再利用のソリューションが採用されました。

対応する構成情報は次のとおりです。

このうち、新たに購入した5台のマシンは、Intel Xeon E5-2660 v4 CPUと256Gのメモリを採用しています。本機には 3.5 インチ ハードディスクを 8 台挿入できます。 RAID1 インストール システムを構成するために、2 つの 480G SSD ハード ディスクが使用されます。 Ceph 分散ストレージのキャッシュ ディスクとして 960G SSD が使用されます。各キャッシュ ディスクは 5 つの OSD データ ディスクに対応します。各キャッシュパーティションの容量は約 160G、各 OSD の容量は 4T です。ストレージは 10 ギガビット ネットワークを使用し、リンク アグリゲーション LACP モード 4 を実行します。

再利用された 4 台のマシンは、Intel Xeon E5-2697 V3 CPU と 256G のメモリを使用します。本機には 2.5 インチのハードディスクを 8 台挿入できます。 RAID1 インストール システムを構成するために、2 つの 480G SSD ハード ディスクが使用されます。 2 つの 480G SSD が Ceph 分散ストレージのキャッシュ ディスクとして使用されます。各キャッシュ ディスクは 2 つの OSD データ ディスクに対応します。各キャッシュ パーティションの容量は約 240G で、各 OSD の容量は 600G です。ストレージは 10 ギガビット ネットワークを使用し、リンク アグリゲーション LACP モード 4 を実行します。

最初の 5 台のマシンにはそれぞれ 4 TB のハードディスクが 5 台搭載されており、合計ストレージ容量は 100 TB になります。最後の 4 台のマシンにはそれぞれ 600 GB のハードディスクが 4 台搭載されており、合計ストレージ容量は 9.6 TB です。

当初は、すべての容量が同じストレージ プールに計画されており、総生容量は約 109T になります。 3つのコピーを構成すると、容量は約36Tになります。

環境は主にMySQL、Redis、ELK、Zabbix、Webサービス、Appサービスなどの業務を運用しており、業務種別全体ではIOPS集約型の業務が中心です。事業開始から最初の2か月間は、システム全体に問題は発生しませんでした。

SSD寿命パラメータ分析と診断

SSD 寿命損失の不一致を考慮して、SSD 寿命パラメータを参照して次の分析を実施しました。

耐久性評価 (生涯書き込み): ライフサイクル中の総書き込み容量。顧客環境で使用される 960G SSD のライフサイクル全体にわたる総書き込み量は 1.86 PBW であり、最大 1.86PB のデータを書き込むことができることを意味します。

DWPD: Device Writes Per Day (1 日あたりのデバイス書き込み数)、1 日あたりのハードディスク書き込み回数。ディスク全体の書き込みは 1 回としてカウントされます。ハードディスクの耐久性を評価するために使用されます。公式サイトによれば、960G SSD の公称耐久性は 1 DWPD で、これはディスク全体に 1 日 1 回書き込めることを意味します。

したがって、SSD ライフサイクル中の書き込み総量の観点から見ると、サーバーの帯域外管理インターフェイスで確認される寿命損失はより合理的です。

このハードドライブのライフサイクル中の総書き込み量と、1 日に 1 回消去できるという事実を組み合わせると、このハードドライブの使用時間は 1.86PB/960G/日 = 1860000B/960G = 1937 日、つまり約 5 年であることがわかります。これは、メーカーが約束した 5 年間の保証と一致しています。

ZStack クラウド プラットフォームの IO 監視ツールと smartctl ツールを使用して、960G SSD ハード ドライブの 1 日の書き込み量を調査および分析したところ、ハード ドライブの 1 日の書き込み量は 2.5T を超え、SSD ハード ドライブ 960G の容量の 3 倍近くになることがわかりました。

同時に、分析の結果、後者 4 台のサーバーの SSD キャッシュ ディスクのハードディスク書き込み量は非常に小さく、対応するハードディスクの総寿命にそれほど影響がないことがわかりました。

テストの結果、最初の 5 台のサーバーの SSD では、95% の IOPS が 3000 を超え、読み取り/書き込み比率は 15:85、平均読み取り IO ブロック サイズは約 16K、書き込み IO ブロック サイズは約 18K であることがわかりました。最初の 5 台のサーバーの OSD データ ディスクの場合、IOPS 95% は約 30、読み取り/書き込み比率は 86:14、平均読み取り IO ブロック サイズは約 30K、書き込み IO ブロック サイズは約 180K です。

そのため、最初の 5 台の物理マシンの SSD キャッシュ ディスクの 1 日の書き込み量は、公式サイトの公称値の 3 倍近くになります。ライフサイクル中の総書き込み量の損失推定によると、最初の 5 台のサーバーの SSD キャッシュ ディスクの寿命は 2 年未満になる可能性があります。

しかし、最後の 4 台のサーバーの SSD 使用率が上がらず、最初の 5 台のサーバーの SSD 使用率が均衡していないのはなぜでしょうか。

Ceph データ分散の基本原理を見てみましょう。 Ceph の CRUSH MAP アルゴリズムは、異なる容量のハードディスクを備えたストレージノード上でデータの均等な分散を実現します。 Ceph は、OSD データ ディスクの容量に応じて重みを計算し、データ分散戦略のストレージ クラスターのマッピングと配置ルールに基づいてハッシュ計算を実行します。同じストレージ プール内では、容量の大きい OSD データ ディスクでは IO 要求が多くなり、容量の小さい OSD データ ディスクでは IO 要求が少なくなります。 IO 要求はデータのハッシュから PG にマッピングされ、その後 PG はレプリカの数に応じてそれを異なる OSD にマッピングします。 OSD ハードディスクが異なる場合は、容量が大きい方がより多くの PG を処理できます。対応するIO処理はさらに増えます。対応する IO バランス戦略によれば、ストレージ プールの合計容量が 109T で、容量の 30% が使用されている場合、容量の 30% がすべてのデータ ディスクに均等に保存されます。たとえば、最初の 5 つのノードは 4T のデータ ディスクを使用し、各ディスクには約 1.2T のデータが格納され、最後の 4 つのノードは 600G のデータ ディスクを使用し、各ディスクには約 180G のデータが格納されます。

そのため、ハードディスク容量の不均衡により、対応する IO 要求も不均衡になります。ビジネス上のプレッシャーが高い場合、最後の 4 台のマシンでは全体の IO 要求を均等に処理できません。分散計画では、各マシンのハードディスク構成とネットワーク構成が一貫している必要があります。

分散ストレージ最適化ソリューション

以上の状況を踏まえ、以下の調整を検討します。

現在の業務使用量を確認し、業務使用量を調整し、重要でない業務の一部をシャットダウンして IO 使用量を削減し、調整後の対応する IO 使用量を監視します。 960G SSDの1日の書き込み量が1.8Tに削減されたことがわかりました。現時点では、事業を継続的に調整することはできなくなりました。

業務の調整ができない場合は、容量拡張やハードディスク調整しか検討できません。能力拡大を検討する際には、その後の取引量の伸びも考慮する必要があります。

現在のストレージ容量は現在の業務にストレージを提供できますが、キャッシュ ディスクのパフォーマンスは対応する業務のニーズをサポートするのに不十分であるため、この 960G SSD の毎日のハードディスク書き込み頻度 DWPD は 1 であり、ディスク全体をフラッシュできるのは 1 回だけです。ハードディスクの毎日の書き込み量を考慮すると、新しい 960GB SSD を新しいキャッシュ ディスクとして使用することをお勧めします。公式サイトのライフサイクル中の総書き込み量の公称値は 5.26PBW で、ハードディスクの 1 日の書き込み量は 3DWPD であり、1 日に 3 回の消去と書き込みが可能ということになります。

信頼性と経済性の基本原則に基づいて、拡張には次のハードウェア拡張ソリューションを検討します。

1. 合計書き込み容量が大きい 960GB SSD と 480G SSD システム ディスクを使用して、さらに 3 台のサーバーを追加しました。その他の構成は最初の 5 台のサーバーと同じです。

2. 最初の 5 台のサーバーでは、元の 960 GB SSD を、書き込み容量の合計が大きい 960 GB SSD に交換し、最初の 5 台のマシンの容量を同じ構成の 8 台のマシンに拡張しました。

3. 最後の 4 台のサーバーでは、手順 2 で取り外した 960 GB SSD にキャッシュ ディスクを交換します。これで、各サーバーに 5 つのデータ ディスクを配置できるようになります。

4. 最後の 4 台のサーバーでは、元の 2.5 インチ 600G SAS ハードディスクが 2.4T エンタープライズ レベルの SAS ハードディスクに変更されました。現在、2.5 インチのエンタープライズ レベルのハードディスクの最大容量は 2.4T に制限されています。

5. ストレージ計画: 8 台の E5-2660 サーバーは、5x4Tx8、約 160T のストレージ容量を提供します。最後の 4 台のサーバーは、5X2.4Tx4、約 48T のストレージ容量を提供します。

6. 最初の 8 台のマシンには個別のストレージ プールがあり、最後の 4 台のマシンにも個別のストレージ プールがあり、すべて 3 つのコピーで構成されています。

具体的な調整手順については、次の手順を参照してください。

1. 最後の 4 台のサーバーのハード ディスクをストレージ プールから削除し、これらの 4 台のマシンをシャットダウンします。

2. 新しく購入した 3 台のサーバーに Ceph ストレージ ノードをインストールして展開し、分散ストレージ クラスターのストレージ プールに追加します。

3. 最初の 5 台のサーバーのうち 1 台からハードディスクとサーバーを取り外し、Ceph ストレージ データのバランスが取れて復元されるまで待ちます。

4. Ceph のバランスが取れたら、サーバーをシャットダウンし、960G SSD をより耐久性の高い 960G SSD に交換します。

5. 手順 3 ～ 4 を繰り返して、最初の 5 台のマシンの変更を完了します。

6. 最後の 4 台のサーバーのハードウェアを変更し、最初の 5 台のマシンから 1 台の 960G SSD を最後の 4 台のサーバーのそれぞれに割り当て、各マシンの 600G SAS ハードディスクを 5 台の 2.4T SATA ハードディスクに交換して Ceph ストレージに追加し、これらの 2.4T ハードディスク用に別の Ceph ストレージ プールを計画します。

7. 手順 6 で作成した新しいストレージ プールを、データ クラウド ディスク プールとして ZStack の Ceph プライマリ ストレージに追加します。データ クラウド ディスクを作成するときに使用されます。ビジネスを使用する場合、一部のビジネスは最後の 4 台のマシンのストレージ プールに展開できます。

8. 新しく購入した 3 台のサーバーを ZStack コンピューティング ノード クラスターに追加し、それらを使用してコンピューティング リソースを提供します。

上記のソリューションの変更により、最初の 5 台のサーバーが 1 日に 3 回ハードディスクに書き込みを行い、SSD の寿命が急速に低下するという現在のビジネス シナリオの問題を解決できます。コンピューティングとストレージのハイパーコンバージェンス拡張を実行するために、さらに 3 台のサーバーが追加されました。 Ceph 容量ストレージ IO 要求が不均衡なシナリオでは、計画に別のストレージ プールも使用されます。同じ容量のハードディスクが同じストレージ プールに計画されるため、IO 要求と IO データのバランスをとることができます。各 SSD の使用も比較的バランスが取れており、つまり、8 台のサーバーの使用損失は一定であり、最後の 4 台のサーバーの使用損失も一定です。

結論

要約すると、分散ストレージを計画および展開する際には、次の点を考慮する必要があります。

1. 同じストレージ プールのハード ディスク モデルと容量は一貫している必要があります。そうしないと、同じストレージ プール内に異なる容量のハード ディスクが存在すると、IO 要求とストレージの分散が不均衡になります。 SSD キャッシュ ディスクを使用するシナリオでは、大容量のハード ディスクに対応する SSD IO 要求が多くなり、損失が速くなります。

2. 事前にビジネス計画を評価し、IOPS と帯域幅の書き込みを事前に計画する必要があります。高 IO ビジネスでは、準備されたハードウェアがビジネス ニーズを満たすかどうかを評価する必要があります。ビジネス ニーズが高い場合は、より高構成のハードウェアを使用するか、対応するハードウェア拡張を実行する必要があります。

3. 分散ストレージ用の SSD を選択する場合は、SSD の PBW (ライフサイクル全体の書き込み量) と DWPD (1 日あたりのディスク書き込み量) に注意することをお勧めします。業務形態に応じて、SSD の寿命と総書き込み量の損失を計画する必要があります。 IO 集約型のビジネスでは、より高い DWPD を持つ SSD を選択する必要があります。

[51CTO オリジナル記事、パートナーサイトに転載する場合は、元の著者とソースを 51CTO.com として明記してください]