OpenStackでCephを正しく使う方法

ストレージとして Ceph を使用する OpenStack に関する非常に貴重な記事を見つけました。この記事では、OpenStack と Ceph を組み合わせる最適な方法をまとめています。OpenStack で Ceph を使用した後のパラメータの最適化、SSD OSD ディスクの使用に関する推奨事項、プールの使用に関する推奨事項など、多くの質問に答えています。

Ceph と OpenStack は非常に便利で、非常に人気のある組み合わせです。ただし、Ceph/OpenStack を導入する際には、簡単に回避できる欠点がいくつかあることがよくあります。私たちは、それらの解決をお手伝いします。

show_image_direct_url と Glance v2 API を使用する

Ceph の RBD (RADOS ブロック デバイス) を使用すると、書き込み可能なスナップショット (スナップショットは通常読み取り専用) と考えることができるクローンを作成できます。クローン作成では、親スナップショットと比較して変更された部分のオブジェクトのみが作成されます。つまり、次のようになります。

スペースを節約できます。これは明白ですが、あまり説得力がありません。結局のところ、ストレージは分散システムの中で最も安価な部分です。

クローンの変更されていない部分は、元のボリュームによって引き続き提供されます。これは、どのクローンを使用しても、同じ RADOS オブジェクト、同じ osd に簡単にアクセスできるため重要です。つまり、これらのオブジェクトは OSD のページ キャッシュ、つまり RAM から提供されることになります。 RAM は他のどのストレージ アクセス方法よりも高速なので、メモリからの大容量の読み取りに最適です。このため、クローンボリュームからのデータの読み取りは、同じデータの完全なコピーよりも高速になります。

Cinder (イメージからボリュームを作成する場合) と Nova (ceph から一時ディスクを提供する場合) はどちらも、ceph をバックエンドとして RBD イメージのクローンを使用できます。これは自動的に行われますが、glance-api.conf で show_image_direct_url=true が設定され、構成で Glance v2 API を使用して Glance に接続する場合にのみ使用されます。

[[225735]]

Nova コンピューティングノードで libvirt/images_type = rbd を設定します。

NOVA (libvirt KVM コンピューティング ドライバーを使用) には、Cinder ボリュームから起動せずに一時イメージを保存するための構成がいくつかあります。 nova?compute.conf の [libvirt] で images_type を設定できます。

 [libvirt]  
 images_type = <タイプ>

デフォルトのタイプはディスクです。つまり、新しい VM を起動すると、次のことが起こります。

nova-compute は、VM 管理ノード上の Glance API に接続し、必要なイメージを検索して、そのイメージをコンピューティング ノードにダウンロードします。デフォルトでは、/var/lib/nova/instances/_base パスにあります。

次に、ダウンロードしたイメージをバックアップファイルとして使用してqcow2ファイルが作成されます。

このプロセスはコンピューティング ノード上で多くのスペースを占有し、コンピューティング ノードにイメージが事前にダウンロードされていない場合は、仮想マシンの起動に長い時間がかかります。これにより、ダウンタイムなしでそのような VM を別のホストにリアルタイムで移行することも不可能になります。

images_types を rbd に設定すると、ディスクは rbd バックエンドに保存され、元のイメージのクローンとしてすぐに作成され、起動の遅延や無駄なスペースがなく、クローン作成のすべての利点が得られます。ドキュメントを参照してください

Nova コンピューティングノードで RBD キャッシュを有効にする

librbd は、仮想化ホストの RAM をディスク キャッシュに使用できる、ceph 用の Qemu/KVM RBD ストレージ ドライバーをサポートするライブラリです。これを使うべきです。

はい、安全に使用できるキャッシュです。一方、virtio-blk と Qemu RBD ドライバーの組み合わせにより、ディスク フラッシュが正しく実装されます。つまり、VM 内のアプリケーションが「このデータを今すぐディスクに保存したい」と言うと、virtio-blk、Qemu、Ceph が連携して、書き込みが完了したときのみレポートします。

• プライマリOSDに書き込む
• 利用可能なレプリカOSDに複製する
• すべてのOSDジャーナルが書かれた場合にのみ、それらは認められる。

さらに、Ceph RBD にはスマートな保護機能があり、ライトバック キャッシュとして構成されている場合でも、ユーザーから最初のフラッシュ要求を受信するまでライトバック キャッシュは拒否されます (つまり、ライトスルー モードで動作します)。したがって、誤って構成されているかゲスト OS が古いために、これを実行しない VM を実行すると、RBD は頑なに書き込みのキャッシュを拒否します。対応する RBD オプションは rbd cache writethrough until flush と呼ばれ、デフォルトで true に設定されており、無効にしないでください。

nova-compute 構成ファイルで次のオプションを変更することで、ライトバック キャッシュを有効にすることができます。

 [libvirt]
画像タイプ = rbd
 ...
 disk_cachemodes= "ネットワーク=ライトバック"  

これをやるべき

イメージ、ボリューム、一時ディスクに別々のプールを使用する

これで、Glance で show_image_direct_url=true が有効になり、Glance と対話するときに Cinder と nova-compute が v2 API を使用するように構成され、libvirt/images_type=rbd を使用するように nova-compute が構成され、すべての VM とボリュームが rbd クローンを使用するようになりました。クローン作成はストレージ全体で機能します。つまり、1 つのストレージ プールに RBD イメージ (およびスナップショット) を作成し、別のストレージ プールにそのクローンを作成することができます。

これを実行する必要がある理由はいくつかあります。

個別のプールとは、それらのプールへのアクセスを個別に制御できることを意味します。これは標準的な軽減策にすぎません。nova-compute ノードが侵害され、攻撃者が一時ディスクを破損または削除できる場合、それは悪いことですが、Glance イメージも破損できる場合はさらに悪いことになります。

プールを分けるということは、サイズや pg_num などの異なるプール設定を行えることも意味します。

最も重要なのは、個別のプールで個別の crush_ruleset 設定を使用できることです。紹介します

通常、3 つの異なるプールがあります。1 つは Glance イメージ用 (通常は、glance または images という名前)、1 つは Cinder ボリューム用 (cinder または volumes)、もう 1 つは VM 用 (nova-compute または vms) です。

Ceph OSDジャーナルとしてSSDを使用する必要はありません

この記事のすべてのアドバイスの中で、これが最も奇妙で受け入れがたいものかもしれません。もちろん、従来の考え方では、OSD ジャーナルは常に高速なデバイスに配置し、SSD を通常のディスクに対して 1:4 から 1:6 の比率で展開するべきである、ということでしょうか?

見てみましょう。 1:6 の比率を使用すると仮定すると、SATA ディスクは 100 MB/秒で書き込むことができます。 6 つの OSD、各 OSD はエンタープライズ SSD パーティション上のパーティションをとして使用します。さらに、SSD が 500MB/秒で書き込み可能であると仮定します。

おめでとうございます。その場合、SSD がボトルネックになっていることになります。 OSD の合計帯域幅は 600 MB/秒をサポートしますが、SSD によってパフォーマンスが約 83% に制限されます。

この場合、実際には 1:4 の比率を使用できますが、総帯域幅がわずかに速くなるだけなので、SSD に大きな利点はありません。

さて、もちろん、別の方法も考えてみましょう。ジャーナルを OSD と同じデバイスに配置すると、同じデバイスに 2 回書き込むことになるため、平均して、ドライブの公称帯域幅の半分しか使用しなくなります。つまり、SSD がない場合、有効な単一の OSD 帯域幅は約 50 MB/秒に過ぎず、6 つのドライブから得られる合計帯域幅は 300 MB/秒程度になります。それでも 500 MB/秒は大幅な改善です。

したがって、自分の比率を上記の計算に照らし合わせて、価格とパフォーマンスを自分で評価する必要があります。 SSD ジャーナリングが万能薬になるとは思わないでください。 SSDを使うのは良いアイデアかもしれないが、重要なのは比較することだ

オールフラッシュOSDの使用

注意すべき点は、SSD ジャーナルでは読み取りパフォーマンスが向上しないということです。では、SSD の向上した読み取りパフォーマンスをどのように活用すればよいのでしょうか?

SSDをOSDとして使用します。つまり、OSD ジャーナルではなく、ファイル ストレージとジャーナルを備えた OSD です。このような SSD OSD は書き込み速度が速いだけでなく、読み取り速度も速いです。

オールフラッシュOSDを別のCRUSHルートに配置する

オールフラッシュ ハードウェアで実行しているのではなく、一部の OSD が標準でその他が SSD (または NVMe デバイスなど) であるコスト効率の高いハイブリッド クラスターを実行していると仮定すると、当然、それらの OSD を個別に処理する必要があります。最もシンプルで簡単な方法は、通常設定されているデフォルトのルートに加えて、別の CRUSH ルートを作成することです。

たとえば、CRUSH 階層を次のように設定できます。

 ID ウェイト タイプ名前アップ/ダウン ウェイトの再設定プライマリ-アフィニティ
-
 -1 4.85994 ルートデフォルト 
 -2 1.61998 宿主ヘラジカ
 0 0.53999 osd.0 アップ 1.00000 1.00000
 1 0.53999 osd.1 アップ 1.00000 1.00000
 2 0.53999 osd.2 アップ 1.00000 1.00000
 -3 1.61998 宿主ヘラジカ
 3 0.53999 osd.3 アップ 1.00000 1.00000
 4 0.53999 osd.4 アップ 1.00000 1.00000
 5 0.53999 osd.5 アップ 1.00000 1.00000
 -4 1.61998 ホストトナカイ
 6 0.53999 osd.6 アップ 1.00000 1.00000
 7 0.53999 osd.7 アップ 1.00000 1.00000
 8 0.53999 osd.8 アップ 1.00000 1.00000
 -5 4.85994 ルート 高性能
-6 1.61998 ホスト elk-ssd
 9 0.53999 osd.9 アップ 1.00000 1.00000
 10 0.53999 osd.10 アップ 1.00000 1.00000
 11 0.53999 osd.11 アップ 1.00000 1.00000
 -7 1.61998 ホスト moose-ssd
 12 0.53999 osd.12 アップ 1.00000 1.00000
 13 0.53999 osd.13 アップ 1.00000 1.00000
 14 0.53999 osd.14 アップ 1.00000 1.00000
 -8 1.61998 ホスト トナカイ-ssd
 15 0.53999 osd.15 アップ 1.00000 1.00000
 16 0.53999 osd.16 アップ 1.00000 1.00000
 17 0.53999 osd.17 アップ 1.00000 1.00000

上記の例では、OSD 0 ～ 8 はデフォルトのルートに割り当てられ、OSD 9 ～ 17 (SSD) はルート highperf に属します。これで、2 つの個別の CRUSH ルールを作成できます。

ルール複製ルールセット{
    ルールセット 0
    複製されたタイプ
    最小サイズ 1
    最大サイズ 10
    ステップデフォルトを取る 
    ステップ chooseleaf firstn 0 タイプ ホスト
    ステップ放出
} 
 
ルールhighperf_ruleset {
    ルールセット 1
    複製されたタイプ
    最小サイズ 1
    最大サイズ 10
    ステップを踏むハイパフォーマンス
    ステップ chooseleaf firstn 0 タイプ ホスト
    ステップ放出
}

デフォルトの crush ルールは、デフォルトのルートから OSD を選択する replicated_ruleset です。また、step take highperf in highperf_ruleset は、highperf ルート内の OSD のみを選択することを意味します。

ストレージプールのオールフラッシュルールを指定する

単一のプールを新しい CRUSH クルル (つまり別の OSD セット) に割り当てるには、次の単一のコマンドを使用します。

 ceph osd プールセット<名前> crush_ruleset <番号>

…はプールの名前で、は CRUSH ルールの ID です。クライアントがデータにアクセスしている間に、これをオンラインで実行できます。もちろん、再マップとバックフィルが大量に行われるため、全体的なパフォーマンスが少し低下します。

ここで、環境に SSD ストレージよりも通常のストレージが多いとします。したがって、オールフラッシュ OSD 用に別のプールを選択する必要があります。最初にオールフラッシュに移行できるプールがいくつかあります。次のリストは優先順位リストとして解釈できます。クラスターに SSD 容量を追加すると、プールをオールフラッシュ ストレージに 1 つずつ移動できます。

Nova 一時 RBD プール (vms、nova-compute)

radosgwバケットインデックス.rgw.buckets.indexおよび関連ファイル - radosgwを使用する場合は、OpenStack Swiftを置き換えてください。

Cinder ボリューム プール (cinder、ボリューム)

radosgw データ プール (.rgw.buckets および関連) - Swift ストレージで低レイテンシの読み取りと書き込みが必要な場合

Glance イメージ プール (glance、images)

Cinder バックアップ プール (cinder-backup) - 通常、これはオールフラッシュに変換される最後のプールです。

低レイテンシのローカルストレージを使用して、Ceph以外のコンピューティングホストを構成する

さて、Ceph が必要なレイテンシを生成しないユースケースが間違いなくいくつかあります。おそらく、ネットワークベースのストレージでは不十分でしょう。これは、ストレージとネットワーク技術の最近の進歩による直接的な結果です。

ほんの数年前まで、ブロック デバイスへの単一セクターの非キャッシュ書き込みの平均レイテンシは、数ミリ秒、つまり 1000 マイクロ秒 (μs) 程度でした。比較すると、512 バイト (1 セクター) のペイロードを伝送する TCP パケットで発生する遅延は約 50 μs で、往復で 100 μs になります。全体として、ネットワークからデバイスに書き込むことによって発生する追加の遅延 (ローカルに書き込むのではなく) は約 10% です。

その間、単一セクターの書き込み自体は、同価格帯のデバイスでは約 100μs でしたが、最上位の手頃な価格帯のデバイスでは約 40μs にまで低下しました。対照的に、ネットワーク遅延はそれほど変化しておらず、ギガビット イーサネットから 10 GbE では約 20% 低下しています。

したがって、ネットワーク経由で単一の複製されていない SSD デバイスにアクセスする場合でも、ローカルではわずか 40μs であるのに対し、レイテンシは 40 + 80 = 120μs になります。これはもう10%のオーバーヘッドではなく、なんと3倍のオーバーヘッドです

Ceph の場合、これはさらに悪化します。 Ceph は、最初にプライマリ OSD にデータを書き込み、次に (並行して) すべてのレプリカにデータを複数回書き込みます。したがって、単一セクターの書き込みが 40μs であるのに対し、少なくとも 2 回の書き込み操作と 2 回のネットワーク ラウンド トリップのレイテンシ、つまり 40×2 + 80×2 = 240μs となり、ローカル書き込みレイテンシの 6 倍になります。

幸いなことに、ほとんどのアプリケーションではレイテンシが重要ではないため、このレイテンシのオーバーヘッドを気にする必要はありません。残念なことに、非常に気にする人もいます。

それで、この理由で Ceph を放棄すべきでしょうか?いいえ。ただし、libvirt/images_type=rbd で構成されていないコンピューティング ノードをいくつか追加し、代わりにローカル ディスク イメージを使用することを検討してください。これらのホストを集約し、指定されたフレーバーにマッピングします。低レイテンシのアプリケーションを実行するには、このフレーバーを選択することをユーザーに推奨します。