劉良啓 建築技術同盟 2021-04-12 07:50
からの抜粋:
https://mp.weixin.qq.com/s/o9HH-8TF0DbMqHrvsFh1NA
IOT、ビッグデータ、モバイルインターネットなどのアプリケーションの急速な成長に伴い、生成されるデータはますます増加しており、ストレージ市場全体も年々増加しており、分散ストレージがストレージ全体の50％を占めると予想されています。 2021 年までに市場が拡大し、2027 年までに分散ストレージが市場全体の 70% を占めるようになるでしょう。Cephは分散ストレージソフトウェアの代表的なものです。
ソフトウェア デファインド ストレージ プロバイダーとして、Shanyan Data はソフトウェア開発とハードウェアの組み合わせから切り離すことができず、ファーウェイとの ARM エコシステムの構築が Shanyan の開発の主な焦点です。現在、Shanyan Data のオブジェクト ストレージ MOS とブロック ストレージ USP は、Kunpeng プラットフォームへの適応作業を完了し、商用利用の準備が整っています。
以下は、Shanyan Data Cloud Storage のシニア R&D エンジニアである Liu Liangqi が Huawei Developer Conference で行った、Ceph の開発とアプリケーションの経験の共有です。
1. Ceph とは何ですか?
ユーザーレベルでは、Ceph は 3 つの外部サービスを提供します。
1. ブロック ストレージ (RDB ブロック ストレージ インターフェイス): フォーマットされていない U ディスクと同様、初めて個人 PC に接続すると、Windows オペレーティング システムは、ユーザーがより重要なパラメータなどを選択するためのフォーマットされた要求インターフェイスをポップアップ表示します。 NTFS、exFAT、その他のファイル システムなどのファイル システム オプションを選択できます。フォーマットが完了した後でのみ、U ディスクを使用してディレクトリを作成し、ファイルをコピーできます。仕事や生活のために建物に入る前に、建物に必要なものが必要です。装飾される、つまりフォーマットされる。建物に人が 1 人だけということは不可能なので、プロパティを管理する必要があります。プロパティはファイル システムにたとえられます。
2. オブジェクトストレージ（RADOS GW オブジェクトストレージ）：私たちが普段使っているクラウドディスクや、私たちが使っているスマートフォンのクラウドバックアップ機能など、オブジェクトストレージは私たちの生活の中でも広く使われており、すべてオブジェクトストレージをベースにしたビジネスパフォーマンスです。したがって、オブジェクトストレージは、情報化時代における大量の不規則ファイルのストレージ問題を解決することになります。世界に同じ葉っぱが 2 つと存在しないのと同じように、人はそれぞれ異なる情報を生成します。これらの固有のデータのストレージをどのように解決するか、オブジェクト ストレージがソリューションを提供します。
3. Flie システム ファイル システム: Ceph が提供するファイル システム サービスは、パーソナル コンピュータの購入プロセスにたとえられます。DIY ユーザーは、さまざまなハードウェアと部品を購入して、使用する前にオペレーティング システムを組み立て、インストールすることができます。Windows システムを搭載した完全なマシンユーザーが選択してプリインストールされており、購入後、電源を入れるだけですぐに使用できます。Ceph が提供するファイル システム サービスは、このような完全なマシンに似ており、ユーザーは対応するディレクトリをローカルにマウントするだけで作業できます。
RGW: オブジェクト ストレージ インターフェイス。このインターフェイス サービスを使用するには、いくつかのクライアント ソフトウェアが必要です。もちろん、携帯電話のクラウド バックアップ機能は、モバイル オペレーティング システムの組み込み APP によってサポートされているため、追加のソフトウェアをインストールする必要はありません。
RBD: ブロック ストレージ インターフェイス。Linux システムを使用している場合、カーネル モジュール krbd を使用して、ユーザーが使用できるブロック デバイスをローカルに直接生成できます。Windows システムの場合、ユーザーが iSCSI プロトコルを通じて使用できるようにハードディスクを仮想化できます。
RADOS: さらにその下には、Ceph クラスター全体の統合抽象化レイヤー RADOS、つまり抽象オブジェクト ストレージ クラスターがあります。これは、上記のすべてのインターフェイス データが処理後にオブジェクトの形式でクラスターに保存されることを意味します。同時に、RADOS はクラスタ全体でこれらのインターフェイス データの一貫性も保証しますが、LIBRADOS は主に RADOS 層のインターフェイス ライブラリにアクセスします。
次に、Ceph クラスター内のいくつかの重要なコンポーネント (mgr、ミラーなど) を示します。これらのグループはクラスター内の各サーバーに分散されており、上の図には示されていません。各コンポーネントの機能を以下に簡単に説明します。
-
MON: クラスターの頭脳とみなされるモニターは、クラスターの状態の維持とメタデータの管理を担当します。
-
MDS: Ceph FS インターフェイス サービスのファイル階層の取得とメタデータ管理を提供するメタデータ サービス Ceph FS サービスが必要ない場合は、このコンポーネントをデプロイしないことを選択できます。
-
OSD: オブジェクトストレージデバイス 主にクラスタ全体でユーザーデータを運ぶ端末デバイスで、基本的にユーザーのデータの読み書き要求はすべてOSDによって最終的に実行されます。したがって、OSD のパフォーマンスが上位層ビジネス全体のパフォーマンスを決定します。OSD は通常、ハードディスクやハードディスク パーティションなどの大きな記憶領域をバインドし、OSD 管理記憶領域のローカル ストレージ インターフェイスには主にファイル ストアとブルー ストアが含まれます。もちろん、ファイル ストアはストレージ領域を管理するためにローカル ファイル システム (XFS など) を使用する必要もあります。Blue Store は RAW デバイスを直接引き継ぐことができるため、その IO パスを削減してパフォーマンスを向上させることができます。
全体として、Ceph は統合分散ストレージ システムです。その設計目標は、優れたパフォーマンス、信頼性、拡張性です。これは、Ceph のアーキテクチャの観点から見ると、専用のキャッシュ層がないため、パフォーマンスがあまり理想的ではないためです。コミュニティでは、この問題に対して階層型キャッシュ (層) 機能も推進していますが、この機能はまだ製品段階に達していません。そのため、現在の一般的な方法は、Ceph データをオペレーティング システム レベルでキャッシュすることです。カーネルのブロック層は、dm -cache、bcache、enhancedIO、およびその他のオープンソース ソフトウェアをオペレーティング システム レベルで高速デバイス (SSD など) にキャッシュして、Ceph のパフォーマンスを向上させます。
2. Ceph の既存のアーキテクチャとビジネスにはどのような問題がありますか?
1. Ceph データとカーネル キャッシュの分割の問題。BlueStoreを例に挙げると、OSDのメタデータをRockDBに保存し、RockDBは簡易ファイルシステム(Blue FS)上で動作するため、このときBlue FSのIOがOSDのメタデータであると考えることができますが、カーネル キャッシュに関する限り、OSD によって配信されるデータがメタデータとビジネス データに分割されていることを認識できません。
2. カーネル キャッシュは、OSD ビジネスのホット データとコールド データを区別できません。たとえば、ユーザーは一般的な 3 コピー ストレージ戦略を構成します。このとき、マスター コピー データのみがクライアントに読み取りおよび書き込みサービスを提供します。スレーブ コピーはキャッシュを直接使用しませんが、カーネル層キャッシュはこの違いを区別できません。DM キャッシュを使用すると、一部のデータをキャッシュするためにメモリ内にスペースが割り当てられるため、間違いなくメモリ リソースが無駄になります。
一般的に、カーネル キャッシュ内のキャッシュ領域の無駄遣い、キャッシュ ヒット率の低下、頻繁なキャッシュ リフレッシュによるキャッシュ デバイスの寿命の短縮などの欠点があります。
3. 解決策は何ですか?
BlueStore が IO を配信する場所にアダプテーション レイヤーを追加して、配信される IO のタイプをマークし、カーネル キャッシュの入り口にアダプテーション レイヤーを追加して OSD の IO タイプをキャプチャします。 IO タイプには、異なるライトバックおよび消去戦略があります。
たとえば、3 つのコピーのうち 2 つは、IO 要求とともにアダプテーション層を介して NOCACHE タグを使用してカーネル キャッシュに取り込まれるため、カーネル キャッシュをキャッシュせずにバックアップ ディスクに直接書き込むことができます。同時に、Blue FS の IO をメタデータ タイプとしてマークして、カーネル キャッシュに長期間保持できるようにすることができます。または、ユーザーのビジネス ニーズに応じて、ユーザーが所有し、頻繁に読み書きするより重要なデータを高レベルとしてマークし、その他の重要でないデータを中レベルまたは低レベルとしてマークし、高レベルのメタデータと同じ方法を使用します。カーネル キャッシュ内のレベル データの処理戦略。このようにして、ユーザーのニーズに応じてさまざまな削除およびライトバック戦略を実装できます。
BlueStore は Libaio API インターフェイスを使用して IO リクエストを発行します。このとき、発行されたリクエストの IO パラメータとして IOCB 構造体が必要です。io_prep_pwrite 関数で iocb 構造体を生成した後、IO フラグを IOCB の Flag 構造体に設定します。 io_submitのパラメータとして一緒にカーネル層にサブミットされ、カーネルがVFS層でDirect ioをキャプチャする際にフラグをBIOのbi_rw構造など一般的なブロックデバイス層のBIO構造に変換し、これは現時点では一般ブロック層にあります。カーネル キャッシュは上位層のビジネス タグをキャプチャできます。カーネル キャッシュは、メタデータをキャッシュ内に長く常駐できるようにしたり、高レベルのユーザー データとメタデータが同じキャッシュ戦略を実装できるようにしたりするなど、さまざまなタグに応じてさまざまなライトバックおよび割り当て戦略を実装できます。
4. ARM アーキテクチャ上で Ceph が直面する問題と課題
Huawei Kunpeng プロセッサと Intel Xeon プロセッサの間には、次の 6 つの主な違いがあります。
1. ARM のクロスチップ アクセス: 主にメモリに反映されます (データは推定値であり、測定データではなく、評価はありません)。X86と比べてARMにはメリットがないため、以下の最適化方法でクロスチップ沼を回避する動作を行っています。
2. ベクトル計算: この点に関しては、Kunpeng の具体的なパラメータを取得していませんが、ARM の A76 を参考にすると、現時点で ARM が優勢ではありません。
3. 物理コアの数: ARM には、物理コアの数に固有の利点があります。
4. コプロセッサ: アクセラレータ アクセラレータに関しては、Kunpeng 920 は EC/RSA/zlib などの周辺コプロセッサを備えており、汎用の X86 6148 よりも豊富です。
5. メモリ操作: ARM はロードストアのマイクロ アーキテクチャを採用しています。これは単純に次のように理解されます。ARM はメモリとメモリ間のコピーに参加するために CPU を必要としますが、X86 はメモリ間のコピーに参加するために CPU を直接必要としません。 -メモリ転送コピー。これは ARM マイクロアーキテクチャによって決まります。
6. 消費電力比: 全体的な消費電力だけではあまり正確ではありませんが、結局のところ、消費電力は有効になっている物理コアの数にも関係します。もちろん、先進技術により消費電力を削減できます。単一の物理コアの電力消費率の点では、ARM は X86 よりも優れています。
5. Kunpeng プラットフォームに基づく Ceph チューニング
Kunpeng プラットフォーム上の Ceph には、現在次の主流の最適化ソリューションがあります。
1. クロスチップ NUMA 操作シナリオの場合、プロセスはチップ NUMA 上での実行に限定されます。
クロススライス NUMA 操作シナリオの場合、プロセスはスライス上の NUMA に制限されます。Ceph を例にとると、Ceph M 以降のバージョンでは、OSD プロセス全体が実行する NUMA を制限できる OSD_uma_node パラメーターが提供されます。他のバージョンの ceph を使用している場合は、numactl と taskset の 2 つのツールを使用して、指定した uma で実行するプロセスを制限する機能を実現できます。
プロセスの開始時に umactl を設定する必要があります。主なパラメータは、割り当てられたメモリをバインドするための NUMA (-membind)、実行するプロセスをバインドするための NUMA (-cpunodebind)、およびバインドのための物理コア (-physcpubind) です。実行するプロセス。タスクセットはより柔軟で、プロセスの実行中に設定できます。NUMA が制限される前に、ネットワーク カード、メモリ、SSD などの対応するハードウェアを可能な限りオンチップ バスの下に配置する必要があります。これを回避するには、対応するオンチップ バスの下に可能な限り配置する必要があります。クロスチップアクセス。
2. ベクトル演算の短いボードはコプロセッサーの助けを借りて埋められます。
ベクトル コンピューティングの観点からは、Kunpeng 920 プラットフォームのアクセラレータを使用できます。ファーウェイはいくつかのインフラストラクチャ インターフェイス ドキュメントを提供しており、これらのドキュメントに基づいて対応する調整を行うことができます。設定とパラメータ構成はコード レベルで調整する必要があります。今回は、多くの労力を費やして安定性テストを行う必要があります。
3. スレッド数とメモリ操作を増やす
Kunpeng の物理コアの利点を活かし、業務処理に応じたプロセスやスレッドの追加が可能で、負荷の高い業務スレッドについてはスレッドを 2 つに分割し、異なる物理コアに割り当てることができます。
メモリ操作に関しては、メモリ操作の削減に加えて、ファーウェイは ARM マイクロアーキテクチャ用のパッチをリリースしました。このパッチは主にメモリ インターフェイスを最適化します。パフォーマンスを向上させるために、ファーウェイのインフラストラクチャ Web サイトからパッチをダウンロードできます。さらに、他の最適化方法もあります。
-
バインディング ネットワーク カード/SSD の中断: irqbalace サービスを最初に閉じる必要があります。閉じないと、irqbalace サービスがバインディングのバランスを再調整します。
-
Cgroup分離ビジネス：主にCPUキャッシュを考慮し、ビジー状態のスレッドやプロセスに対して効果的ですが、関係のないプロセスやスレッドにCPUを切り替えると、CPUキャッシュがリフレッシュされ、ヒット率が低下します。キャッシュの先読みもメモリ帯域幅を無駄にします。同時に、プロセス CPU が切り替えられると、パイプライン全体がクリアまたは空になり、この時点で同時命令の数も減少するため、依然としてパフォーマンスに影響します。主な理由は、ビジネスが比較的混雑している場合にパフォーマンスの向上が比較的大きくなるからです。
-
サードパーティ ライブラリ: 主にメモリ割り当てと回復効率を最適化するため、Tcmalloc と jemalloc はオプションです。Tcmalloc と jemalloc の Web サイトにアクセスして、読み取り用の関連ファイルをダウンロードできます。
次に、次の図に示す 3 つの Ceph パフォーマンス観察ツールを紹介します。
Ceph の OSD perf/perf デーモン: Ceph に付属するツールです。このうち、OSD perf は主に IO の読み取りと書き込みの遅延を記録し、ボトルネックがハードディスクにあるかどうかを最初に判断できます。ボトルネックがある場合は、それに対応する最適化方法を提供します。採用可能です。
perf デーモンは主に Ceph の IO リクエスト全体の処理フローを記録しており、これらの処理フローに費やされた時間がこのコマンドを通じてエクスポートされ、事前診断に使用できます。
オペレーティング システム—パフォーマンス ツール: より一般的に使用されるパフォーマンス トップは、システム全体の現在の実行ステータスを示します。上の図の右上隅に示すように、OSD プロセスは明らかに CPU を大量に消費します。階層ピーリングを実行できます。ホット機能の場所を見つけてから、ホットスポット機能のターゲットを絞った最適化を行います。パフォーマンス統計は主に、一定期間にわたるプロセスの全体的な状況を収集します。また、perf レコードを使用してデータを記録し、FlamGraph を組み合わせてフレーム グラフを生成することもできます。これは比較的直感的です。ここでは消費される CPU 時間の割合が比較的大きく、これが最適化の目標であるため、いくつかのフラットヘッド関数呼び出し (図) に主に焦点を当てます。
Systemtap: 主に Redhat システムで使用されます。カーネル関数、システムコール、ユーザー関数の動作情報、関数の出入りデータなどを収集し、これらのデータをもとに機能レベルの分析を行います。例えば、openresty-systemtap-toolkitツールをベースに二次開発を行います。このツールを使用すると、システム全体またはプログラムのどこにボトルネックがあるかを分析し、ボトルネックのパフォーマンスを最適化できます。
6. 最適化された Ceph ストレージ システムのパフォーマンスはどのようなものですか?
互換性: プロセス全体の最初から最後まで、比較的大きな障害点はありません。依存ライブラリといくつかの技術的問題の解決策は、Huawei のインフラストラクチャ Web サイトで見つけることができます。Ceph を Kunpeng プラットフォームに移植するプロセス全体は比較的簡単です。スムーズ。
最適化されたパフォーマンス: 既存のサーバー構成に基づく最適化前後の比較に基づくと、ここでのテストは Kunpeng CPU の限界ではなく、主なボトルネックはハードディスクです。主に、上で紹介した最適化方法と手段による最適化後の結果を示します。表に示すように、最適化されたパフォーマンスが向上していることがわかります。
低消費電力: 主に、ARM の単一物理コアの消費電力が X86 の消費電力よりも実際に低いという事実に反映されており、そのため、後の運用コストで有利になります。
以下は、Kunpeng プラットフォーム上で実行されているブロック ストレージ製品のステータスを紹介します。メイン インターフェイスには、ブロック ストレージ製品クラスタ全体のステータスが表示されます。ノード情報セクションには、モニターや OSD などのコンポーネントが展開されています。ここでのサーバー情報は、Huawei の TaiShan サーバーであることがわかります。TaiShan 200 (モデル 2280) サーバーは Kunpeng 920 プロセッサを使用しています。
ボリューム管理などの他の管理機能については、カーネルの krbd モジュールを介して Linux システムをローカルにマウントできます。また、ユーザーが使用できるように iSCSI プロトコルを介して Windows システムにマウントすることもできます (図)。他の機能がある場合は拡張されません。
6. 今後の展望と計画
1つ目は、TaiShanサーバーをベースにした長期計画で、オールフラッシュストレージのシナリオに基づいた製品のリリースなどですが、このシナリオでは、すべてのハードディスクのパフォーマンスが比較的高く、従来のイーサネットネットワークがボトルネックになります。 TaiShan サーバーは RDMA 機能のみをサポートしており、ネットワーク ポートの追加の適応や調整を必要とせずに、オール フラッシュ ストレージ シナリオの展開への道が開かれます。
seastar ARMアーキテクチャの場合、マルチコア競争においてクロスチップアクセスのパフォーマンスが不利になるが、今回はシェアードナッシングプログラミングのseastarフレームワークを採用し、ARMクロスチップアクセスのデメリットを回避する。 seastar アーキテクチャのコミュニティも積極的に投資を行っており、今後もフォローアップしていきます。
最後に、セキュア ストレージ製品はデータの暗号化、復号化、圧縮解除にとってより重要であり、Kunpeng ペリフェラル アクセラレータ zlib/rsa/md5/sm3 は効率的なデータ セキュリティ処理プロセスを提供できます。
強結合カーネル キャッシュの変換後にオペレーティング システムを再コンパイルする必要がありますか? いいえ、I/O は VFS 層でのカーネル ハッキングによって処理されるため、カーネルの元のロジックを変更する必要はありません。変更された KO をオペレーティング システムにロードするだけで、カスタマイズされた IO が処理されます。
青いストア内にキャッシュを作成することを検討してみてはいかがでしょうか? Blue Store は将来のオールフラッシュ シナリオに向けてコミュニティによって設計されており、ハイブリッド シナリオは考慮されていませんでした。また、ハイブリッド シナリオは長期的なものではなく単なる過渡期であるため、コミュニティは設計時にキャッシュの追加を考慮しませんでした。 Blue Store に実装されているため、コミュニティの設計コンセプトに反していると同時に、コミュニティをフォローアップする場合でも、将来的にコミュニティに変更を加える場合でも、Blue Store 全体の処理が非常に複雑になります。 、面倒になりますよ。