パフォーマンス13倍、安定性3倍向上！ UCloudクラウドハードドライブはこんなことができる

最近、当社は、高性能シナリオに対するユーザーのニーズを満たすために、高性能 SSD クラウド ディスクをリリースしました。通常のクラウド ディスクと比較して、SSD クラウド ディスクは IOPS が 13 倍増加し、安定性が 3 倍向上し、平均レイテンシが 10 倍短縮されました。これを実現するために、昨年 10 月からクラウド ディスクのアーキテクチャを再設計し、レイテンシを完全に削減し、IO 機能を向上させました。また、一部のアーキテクチャとソフトウェアを再利用することで、一般的なクラウド ディスクのパフォーマンスと安定性が向上します。同時に、スタック/カーネルバイパス技術を段階的に導入し、次世代の超高性能ストレージを実現しました。新しいアーキテクチャの導入後、既存のネットワーク ユーザーの 3,400 を超えるクラウド ディスク インスタンスにサービスが提供され、合計ストレージ容量は 800 TB、平均クラスター IOPS は 1 秒あたり 310,000 に達しました。

アーキテクチャアップグレードのポイント

現在の問題と要件を分析した結果、このアーキテクチャのアップグレードの具体的なポイントが整理されました。

1. 元のソフトウェア アーキテクチャではハードウェアの機能を十分に活用できないという制限を解決します。

2. SSD クラウド ディスクをサポートし、QOS 保証を提供し、バックエンドの NVME 物理ディスクの IOPS と帯域幅のパフォーマンスを最大限に発揮し、単一のクラウド ディスクの IOPS は 2.4W に達します。

3. 32T 以上の大容量クラウド ディスクをサポートします。

4. IO トラフィックのホットスポットを完全に削減します。

5. 数千のクラウド ディスクの同時作成と数千のクラウド ディスクの同時マウントをサポートします。

6. 古いアーキテクチャのクラウド ディスクから新しいアーキテクチャへのオンライン移行をサポートし、通常のクラウド ディスクから SSD クラウド ディスクへのオンライン移行をサポートします。

新しいアーキテクチャ変革の実践

変革1: IOパスの最適化

古いアーキテクチャでは、IO パス全体に 3 つのレイヤーがあります。最初のレイヤーはホスト クライアント側、2 番目のレイヤーはプロキシ側、3 番目のレイヤーはストレージ チャンク レイヤーです。プロキシは、IO ルーティングの取得とキャッシュを担当します。 IO の読み取りと書き込みは次のストレージ層に転送され、IO の 3 つのコピーを書き込む役割を担います。

新しいアーキテクチャでは、ルートの取得はクライアントに引き渡され、IO 読み取りおよび書き込みクライアントはストレージ チャンク層に直接アクセスでき、3 つのコピーの書き込みもチャンクに引き渡されます。 IO パス全体は 2 つのレイヤーになります。1 つはホスト クライアント側、もう 1 つはストレージ チャンク レイヤーです。

アーキテクチャのアップグレード後、読み取り IO の場合、1 つのネットワーク要求がバックエンド ストレージ ノードに直接到達しますが、古いアーキテクチャでは 2 つの要求が必要でした。書き込み IO の場合、プライマリ コピー IO はネットワーク要求をバックエンド ストレージ ノードに直接送信し、他の 2 つのコピーはプライマリ コピーを経由して 2 回のネットワーク転送を経ますが、古いアーキテクチャでは 3 つのコピーがそれぞれ 2 回のネットワーク転送を経ます。読み取り IO レイテンシは平均 0.2 ～ 1 ミリ秒短縮され、書き込みテール レイテンシも短縮されるため、全体的なレイテンシも効果的に短縮されます。

変革 2: メタデータ シャーディング

分散ストレージでは、データはシャード化され、各シャードはクラスター内の複数のコピーに保存されます。下の図に示すように、シャード サイズが 1G の場合、200G のクラウド ディスクには 200 個のシャードがあります。古いアーキテクチャでは、シャード サイズは 1G です。実際のビジネスプロセスでは、一部のビジネスの IO ホットスポットが狭い範囲に集中していることがわかりました。 1G シャードを使用すると、通常の SATA ディスクのパフォーマンスは非常に低下します。さらに、SSD クラウド ディスクでは、IO トラフィックをさまざまなストレージ ノードに均等に分散することができません。

新しいアーキテクチャでは、1M サイズのシャードをサポートします。 100 万個のシャードでクラスター全体の容量を最大限に活用できます。高性能ストレージでは、ソリッド ステート ドライブのパフォーマンスが向上し、ビジネス IO ホットスポットがより狭い範囲に集中するため、より優れたパフォーマンスも実現できます。

ただし、UCloud メタデータは事前​​割り当ておよびマウント ソリューションを採用しています。クラウド ディスクを申請すると、システムはすべてのメタデータを直接割り当て、すべてをメモリにロードします。シャードが小さすぎると、同時に割り当てるかマウントする必要があるメタデータの量が非常に大きくなり、簡単にタイムアウトが発生し、一部のリクエストが失敗する可能性があります。

たとえば、300 GB のクラウド ディスクを 100 個同時に申請し、それを 1 GB のスライスに分割する場合、30,000 個のメタデータを同時に割り当てる必要があります。 100 万スライスに分割する場合、3000 万のメタデータを同時に割り当てる必要があります。

シャードが小さくなることでメタデータの割り当て/マウントが失敗する問題を解決するために、IO 中の割り当て戦略を変更して、クラウド ディスクがマウントされるときに割り当てられたメタデータをメモリにロードするようにしました。 IO 中に、IO 範囲がすでに割り当てられているルートに当たると、メモリ内のルートに従って IO が実行されます。 IO 範囲が未割り当てのルートに当たると、メタデータ モジュールにルートの割り当てをリアルタイムで要求し、そのルートをメモリに保存します。

IO 割り当てに基づいて、300G のクラウド ディスクを 100 個同時に申請し、同時にマウントし、同時に IO をトリガーすると、約 1000 IOPS が生成されますが、これは比較的ランダムです。最悪の場合、1000*100 = 10W のメタデータ割り当てがトリガーされます。 IO パスでは依然として多くの消費が行われています。

最終的に、新しいアーキテクチャでは、シャード メタデータを中央ノードに保存するソリューションを放棄し、一連の統一されたルールを使用してルートを計算して取得するソリューションを採用しました。

このソリューションでは、クライアントとクラスター バックエンドは同じ計算ルール R (シャード サイズ、pg の数、マッピング方法、競合ルール) を使用します。クラウド ディスクを申請する場合、メタデータ ノードは計算ルール 4 つを使用して容量が満たされているかどうかを判断します。クラウドディスクをマウントするときに、メタデータノードから計算ルール4倍が取得されます。 IO を実行する際、計算ルール R (シャード サイズ、pg 数、マッピング方法、競合ルール) に従ってルーティング メタデータが計算され、その後直接 IO が実行されます。この変換ソリューションにより、100 万のデータ シャードの場合にメタデータの割り当てとマウントがスムーズに行われ、IO パスの消費が削減されます。

変革3：SSD高性能クラウドディスクをサポート

上記の比較から、NVME ソリッド ステート ドライブのパフォーマンスは機械式ドライブの 100 倍であることがわかりますが、NVME ソリッド ステート ドライブの機能を活用するには、サポートするソフトウェア設計が必要です。

SSD クラウド ディスクは QoS 保証を提供し、単一ディスク IOPS: 最小{1200+30*容量、24000} SSD クラウド ディスクの場合、従来のシングル スレッド モードはボトルネックとなり、バックエンドの NVME ハード ディスクの数十万の IOPS と 1 ～ 2 GB の帯域幅をサポートすることは困難であるため、マルチスレッド モデルを採用しました。

SSD クラウド ディスクをできるだけ早く起動するために、従来の TCP ネットワーク プログラミング モデルを採用し、KernelBypass は使用しませんでした。同時に、ソフトウェアの詳細を最適化することで CPU 消費量を削減できます。

現在、1 つのスレッドで最大 6W IOPS の書き込みと最大 8W IOPS の読み取りが可能で、5 つのスレッドで基本的に NVME ソリッド ステート ドライブの機能を利用できます。現在、次のクラウド ディスク IO 機能を提供できます。

変革4: 過負荷防止機能

通常のクラウド ディスクの場合、新しいアーキテクチャのソフトウェアはボトルネックではなくなりましたが、一般的な機械式ハード ディスクの場合、キューの同時実行サイズは 32 ～ 128 程度しかサポートできません。クラウド ディスクが 100 個あり、複数の IO が同時に物理 HDD ディスクにヒットした場合、HDD ハード ディスク キューが小さいために、io_submit 時間が長くなったり、失敗したりするなどの問題がさらに発生します。クライアント側は、IO がタイムアウトしたと判断すると、IO 送信を再試行し、チャンク側の TCP バッファにますます多くの IO パケットが蓄積されることになります。タイムアウトがどんどん積み重なっていき、最終的にはシステムの過負荷につながります。

一般的なクラウド ディスクの場合、同時送信キューのサイズを制御する必要があります。キューのサイズに応じて、すべてのクラウド ディスクが順番にトラバースされ、上図の 1、2、3 に示すように、各クラウド ディスクの IO が発行されます。実際のコードロジックでは、クラウド ディスク サイズの重みも考慮する必要があります。

SSD クラウド ディスクの場合、従来のシングル スレッドがボトルネックとなり、数十万の IOPS と 1 ～ 2 GB の帯域幅をサポートすることが困難になります。

ストレス テスト中に、ホットスポットが特定のスレッドに集中するシナリオをシミュレートしたところ、このスレッドの CPU は基本的に 99% ～ 100% で完全にロードされ、他のスレッドはアイドル状態であることがわかりました。その後、スレッドのCPUとディスクの負荷状況を定期的に報告する方法を採用しました。スレッドが継続的にビジー状態であり、一部のスレッドが継続的にアイドル状態である場合、一部のスレッドの過負荷を回避するために、一部のディスク シャードの IO を選択し、アイドル状態のスレッドに切り替えます。

変革5: オンライン移行

古いアーキテクチャを持つ通常のクラウド ディスクのパフォーマンスは低くなります。一般的なクラウド ディスク ユーザーの中には、ビジネスが急速に発展しており、より高いビジネス発展のニーズを満たすために、一般的なクラウド ディスクから SSD クラウド ディスクに移行したいと考えている人もいます。現在、古いアーキテクチャのセットが 2 つオンラインになっています。オンライン移行という目標を早く達成するために、第一フェーズではシステム外部からのオンライン移行をサポートすることにしました。

移行プロセスは次のとおりです。

1. バックエンドに移行マークを設定します。

2. Qemu 接続が Trans Client にリセットされます。

3. Trans Client を介して IO ストリームを Trans モジュールに書き込み、Trans モジュールは 2 回の書き込みを実行します。1 回は古いアーキテクチャ用、もう 1 回は新しいアーキテクチャ用です。

4. トリガーはディスクをトラバースし、1M サイズのデータ​​ コマンドを Trans にトリガーして、データのバックグラウンド移行をトリガーします。移行が完了する前は、IO 読み取りはトランスを通じて行われ、古いアーキテクチャのプロキシから読み取られます。

5. すべての再配置が完了すると、Qemu 接続が新しいアーキテクチャ クライアントにリセットされ、オンライン移行が完了します。

トランスのレイヤーを追加して二重書き込みを行うと、移行中にパフォーマンスが低下します。ただし、通常のクラウド ディスクの場合、移行期間中は許容されます。現在、移行期間中のパフォーマンスへの影響を 5% 未満に抑えることを目標に、新しいアーキテクチャ用のジャーナル ベースのオンライン移行機能を構築しています。

上記の一連の変革を経て、新しいクラウド ハード ディスク アーキテクチャは基本的に当初のアップグレード目標を達成しました。現在、新しいアーキテクチャは正式にリリースされ、日常業務で効果的に使用されています。ここで、現在開発中のプロジェクトについてもいくつかお話しさせてください。

1. 容量は無制限に拡張可能

各アベイラビリティーゾーンには、複数のストレージ クラスター セットが存在します。各セットは約 1PB のストレージを提供できます (クラスターを無限に拡張することはできません)。 Set1 のクラウド ディスクを 1T から 32T または 100T に拡張する必要がある場合、Set1 の容量不足の問題が発生する可能性があります。

そこで、ユーザーが適用した論理ディスクをパーツに分割することを計画しています。各パーツは使用しなくなったセットに適用することができ、容量を無限に拡張することができます。

2. 超高性能ストレージ

過去 10 年間で、ハード ドライブは HDD -> SATA SSD -> NVME SSD へと進化してきました。同時に、ネットワークインターフェースも10G→25G→100Gへと飛躍的な発展を遂げてきました。しかし、CPU のメイン周波数はほとんど大きく進化しておらず、平均 2 ～ 3GHZ となっています。私たちが使用する物理マシンは 6 ～ 8 個の NVME ディスクを搭載できるため、物理マシンは 300 万～500 万の IOPS を提供できることになります。

従来のアプリケーション サーバー ソフトウェア モデルでは、TCP の Epoll ループに基づいて、ネットワーク カードのパケットの送受信、および IO の読み取りと書き込みは、ユーザー モードとカーネル モードで複数のレイヤーのコピーと切り替えを経由する必要があり、カーネル割り込みによって起動される必要があります。ソフトウェアがハードウェアの能力を最大限に引き出すのは困難です。たとえば、IOPS とレイテンシに関して言えば、IOPS を増やす唯一の方法はスレッドを追加することです。ただし、スレッドの増加に伴って IOPS が直線的に増加することは困難です。さらに、レイテンシジッターも高くなります。

ゼロコピー、ユーザーモード、ポーリングの技術ソリューションを導入することで、上図の 3 つの IO パスを最適化し、ユーザーモード、カーネルモード、プロトコルスタックの多層コピーと切り替えを減らし、ポーリングを組み合わせてハードウェアの能力を最大限に引き出すことを目指しています。

最終的に、RDMA、VHOST、SPDK という 3 つの技術ソリューションを選択しました。

• ソリューション 1: 超高性能ストレージ - VHOST

従来のモードは次のとおりです: IO は仮想マシンと Qemu ドライバーを通過し、UnixDomain ソケットを経由してクライアントに渡されます。ユーザー モード、カーネル モード、および IO パスで複数のコピーを実行した後。

VHOST ユーザー モードを使用すると、共有メモリを使用して、ユーザー状態 VM からクライアント側にデータを転送できます。実際には、SPDK VHOST を活用します。

R&D 環境では、クライアントが IO 要求を受信した直後に VM に IO 要求を返すことをシミュレートします。つまり、ストレージ バックエンドにデータは送信されません。得られたデータは上図の通りです。単一キューのレイテンシを 90 マイクロ秒短縮し、IOPS を数十倍に増加できます。

• ソリューション 2: 超高性能ストレージ - RDMA+SPDK

RDMA はメッセージ サービスを提供します。アプリケーションは RDMA を使用して、リモート コンピューター上の仮想メモリに直接アクセスできます。 RDMA は、CPU 使用率とメモリ帯域幅のボトルネックを削減し、高帯域幅を提供し、スタック バイパスとゼロ コピー テクノロジを使用して低レイテンシ特性を実現します。

SPDK は、ユーザー モード ドライバーを使用して、高度な同時実行性とゼロ コピー方式で NVME ソリッド ステート ドライブに直接アクセスできます。ポーリング モードは、カーネル コンテキストの切り替えと割り込み処理のオーバーヘッドを回避するために使用されます。

チームは現在、RDMA と SPDK を使用するストレージ エンジン フレームワークを開発しています。 R&D テスト環境では、バックエンドに NVME ソリッド ステート ドライブが使用されます。次のようにして、単一キューと IOPS を改善できます。

SPDK VHOST USERのクライアント側とRDMA+SPDKのストレージ側ソリューションを含め、パブリックベータ版は12月にリリースされる予定です。

要約する

過去 1 年間、クラウド ディスクのストレージ アーキテクチャを再設計および最適化し、古いアーキテクチャの多くの問題を解決し、パフォーマンスを大幅に向上させました。 4か月間の公開テストを経て、SSDクラウドディスクと新アーキテクチャの通常のクラウドディスクは8月に全面的にリリースされ、非常に高い安定性を維持しました。現在、単一のディスクで 2.4W の IOPS を提供できます。