忙しいプロジェクトで Ceph を使用するためのヒントとコツ

さまざまな負荷を持つプロジェクトで Ceph をネットワーク ストレージとして使用すると、一見単純または些細とは思えないさまざまなタスクに遭遇することがあります。 例えば：

• 新しいクラスター内の以前のサーバーを部分的に使用して、古い Ceph から新しい Ceph にデータを移行します。
• Ceph でのディスク領域割り当ての問題の解決策。

このような問題に対処するために、データを失わずに OSD を正しく削除する必要があります。これは、大量のデータを扱う場合に特に重要です。 これについてはこの記事で説明します。

以下で説明するメソッドは、Ceph のどのバージョンにも当てはまります。 さらに、Ceph が大量のデータを保存できるという事実も考慮されます。データ損失やその他の問題を防ぐために、一部のアクションは他のいくつかのアクションに「分割」されます。

OSDについての序文

説明した XNUMX つのレシピのうち XNUMX つは OSD 専用であるため (オブジェクトストレージデーモン)、実践的な部分に入る前に、Ceph の機能とそれがなぜそれほど重要なのかについて簡単に説明します。

まず第一に、Ceph クラスター全体は多くの OSD で構成されているということを言っておかなければなりません。 数が多いほど、Ceph の空きデータ量が増加します。 ここからだとわかりやすいですね メインOSD機能: Ceph オブジェクト データをすべてのクラスター ノードのファイル システムに保存し、そのデータへのネットワーク アクセス (読み取り、書き込み、その他のリクエスト用) を提供します。

同じレベルでは、異なる OSD 間でオブジェクトをコピーすることによって、レプリケーション パラメータが設定されます。 ここでさまざまな問題が発生する可能性があり、その解決策については以下で説明します。

ケースNo.1。 データを失わずに Ceph クラスターから OSD を安全に削除します

OSD を削除する必要があるのは、クラスターからサーバーを削除する (たとえば、サーバーを別のサーバーに置き換える) ことによって発生する可能性があります。これが私たちの身に起こり、この記事を書くきっかけになりました。 したがって、操作の最終目標は、特定のサーバー上のすべての OSD と mons を抽出して、サーバーを停止できるようにすることです。

便宜上、またコマンドの実行中に必要な OSD の指定を間違える状況を避けるために、削除する OSD の番号となる値を別の変数に設定します。 彼女に電話しましょう ${ID} — ここと以下では、そのような変数は、作業している OSD の番号を置き換えます。

作業を開始する前の状態を見てみましょう。

root@hv-1 ~ # ceph osd tree
ID CLASS WEIGHT  TYPE NAME      STATUS REWEIGHT PRI-AFF
-1       0.46857 root default
-3       0.15619      host hv-1
-5       0.15619      host hv-2
 1   ssd 0.15619      osd.1     up     1.00000  1.00000
-7       0.15619      host hv-3
 2   ssd 0.15619      osd.2     up     1.00000  1.00000

OSD の削除を開始するには、次の手順をスムーズに実行する必要があります。 reweight それをゼロにします。 このようにして、他の OSD とのバランスをとることで、OSD 内のデータ量を削減します。 これを行うには、次のコマンドを実行します。

ceph osd reweight osd.${ID} 0.98
ceph osd reweight osd.${ID} 0.88
ceph osd reweight osd.${ID} 0.78

...そしてゼロになるまで続きます。

スムーズなバランス調整が必要データを失わないように。 これは、OSD に大量のデータが含まれている場合に特に当てはまります。 コマンドの実行後にそれを確認するには reweight すべてうまくいきました、完了できます ceph -s または別のターミナルウィンドウで実行します ceph -w リアルタイムで変化を観察するため。

OSD が「空」になったら、標準操作を続行して OSD を削除できます。 これを行うには、目的の OSD を状態に転送します。 down:

ceph osd down osd.${ID}

OSD をクラスターから「引き出し」てみましょう。

ceph osd out osd.${ID}

OSD サービスを停止し、FS 内のそのパーティションをアンマウントしましょう。

systemctl stop ceph-osd@${ID}
umount /var/lib/ceph/osd/ceph-${ID}

OSDをから削除します クラッシュマップ:

ceph osd crush remove osd.${ID}

OSD ユーザーを削除しましょう。

ceph auth del osd.${ID}

最後に、OSD 自体を削除しましょう。

ceph osd rm osd.${ID}

注意: Ceph Luminous バージョン以降を使用している場合、上記の OSD 削除手順は XNUMX つのコマンドに減らすことができます。

ceph osd out osd.${ID}
ceph osd purge osd.${ID}

上記の手順を完了した後、次のコマンドを実行すると、 ceph osd treeの場合、作業が実行されたサーバーには、上記の操作が実行された OSD が存在しないことが明らかです。

root@hv-1 ~ # ceph osd tree
ID CLASS WEIGHT  TYPE NAME     STATUS REWEIGHT PRI-AFF
-1       0.46857      root default
-3       0.15619      host hv-1
-5       0.15619      host hv-2
-7       0.15619      host hv-3
 2   ssd 0.15619      osd.2    up     1.00000  1.00000

途中で、Ceph クラスターの状態が次のように変化することに注意してください。 HEALTH_WARNまた、OSD の数と利用可能なディスク容量も減少します。

以下では、サーバーを完全に停止し、それに応じて Ceph から削除する場合に必要な手順について説明します。 この場合、次のことを覚えておくことが重要です。 サーバーをシャットダウンする前に、すべての OSD を削除する必要があります このサーバー上で。

このサーバーに OSD がもう残っていない場合は、それらを削除した後、OSD マップからサーバーを除外する必要があります。 hv-2次のコマンドを実行します。

ceph osd crush rm hv-2

消去 mon サーバーから hv-2別のサーバー (つまり、この場合は hv-1):

ceph-deploy mon destroy hv-2

この後、サーバーを停止し、その後のアクション (サーバーの再デプロイなど) を開始できます。

ケースNo.2。 作成済みの Ceph クラスター内のディスク容量の配分

第二話はPGについての前置きから始めます(配置グループ）。 Ceph における PG の主な役割は、主に Ceph オブジェクトを集約し、それらを OSD でさらに複製することです。 PG の必要量を計算できる式は次のとおりです。 関連セクション Ceph のドキュメント。 この問題についても、具体的な例を挙げて説明されています。

つまり、Ceph を使用するときによくある問題の XNUMX つは、Ceph のプール間で OSD と PG の数が不均衡であることです。

まず、このため、小さなプールに指定されている PG が多すぎる状況が発生する可能性があり、これは本質的にクラスター内のディスク領域を不合理に使用することになります。 第 XNUMX に、実際には、OSD の XNUMX つでのデータ オーバーフローという、より深刻な問題があります。 これにより、クラスターは最初に次の状態に移行します。 HEALTH_WARNその後 HEALTH_ERR。 この理由は、Ceph が利用可能なデータの量を計算するときに (次のようにして調べることができます) ためです。 MAX AVAIL コマンド出力で ceph df プールごとに個別に) は、OSD で使用可能なデータの量に基づきます。 少なくとも XNUMX つの OSD に十分なスペースがない場合、データがすべての OSD に適切に分散されるまで、それ以上データを書き込むことはできません。

これらの問題については明確にする価値があります。 大部分は Ceph クラスターの構成段階で決定されます。 使用できるツールの XNUMX つは、 Ceph PGCalc。 その助けを借りて、必要なPGの量が明確に計算されます。 ただし、Ceph クラスターが すでに 正しく設定されていません。 ここで明確にしておきたいのは、修正作業の一環として、PG の数を減らす必要がある可能性が高く、この機能は古いバージョンの Ceph では利用できないことです (Ceph のバージョンでのみ登場しました)。 ノーチラス).

そこで、次の図を想像してみましょう。クラスターにはステータスがあります。 HEALTH_WARN OSD の XNUMX つがスペース不足になっているためです。 これはエラーによって示されます HEALTH_WARN: 1 near full osd。 以下は、この状況から抜け出すためのアルゴリズムです。

まず最初に、残りの OSD 間で利用可能なデータを分散する必要があります。 最初のケースでノードを「ドレイン」したときに同様の操作をすでに実行しましたが、唯一の違いは、わずかに減らす必要があることです。 reweight。 たとえば、0.95 まで:

ceph osd reweight osd.${ID} 0.95

これにより、OSD 内のディスク領域が解放され、ceph ヘルスのエラーが修正されます。 ただし、すでに述べたように、この問題は主に初期段階での Ceph の構成が正しくないために発生します。将来この問題が発生しないように再構成を行うことが非常に重要です。

私たちの特別なケースでは、最終的には次のようになります。

• 値が高すぎる replication_count プールの一つで、
• あるプールでは PG が多すぎますが、別のプールでは PG が少なすぎます。

すでに述べた計算機を使用してみましょう。 入力する必要がある内容が明確に示されており、原則として複雑なことは何もありません。 必要なパラメータを設定すると、次の推奨事項が得られます。

注意: Ceph クラスターを最初からセットアップする場合、計算機のもう XNUMX つの便利な機能は、表で指定されたパラメーターを使用してプールを最初から作成するコマンドの生成です。

最後の列はナビゲートに役立ちます - 推奨されるPG数。 この例では、レプリケーション乗数を変更することにしたため、レプリケーション パラメーターが示されている XNUMX 番目のオプションも役に立ちます。

したがって、最初にレプリケーション パラメータを変更する必要があります。乗数を減らすことでディスク領域を解放できるため、これは最初に実行する価値があります。 コマンドを実行すると、使用可能なディスク容量が増加することがわかります。

ceph osd pool $pool_name set $replication_size

そして完了したら、パラメータ値を変更します pg_num и pgp_num 次のようにします。

ceph osd pool set $pool_name pg_num $pg_number
ceph osd pool set $pool_name pgp_num $pg_number

それが重要だ: 各プールで PG の数を順番に変更する必要があり、警告が消えるまで他のプールの値を変更しないでください。 「データ冗長性の低下」 и 「n 個のページが劣化しました」.

コマンド出力を使用して、すべてがうまくいったことを確認することもできます。 ceph health detail и ceph -s.

ケースNo.3。 LVM から Ceph RBD への仮想マシンの移行

レンタルしたベアメタル サーバーにインストールされた仮想マシンをプロジェクトで使用する状況では、フォールト トレラント ストレージの問題がよく発生します。 このストレージに十分なスペースがあることも非常に望ましいです...もう XNUMX つのよくある状況: サーバー上にローカル ストレージを持つ仮想マシンがあり、ディスクを拡張する必要がありますが、ディスクがないため、どこにも行くことができません。サーバー上に残っている空きディスク容量。

この問題はさまざまな方法で解決できます。たとえば、別のサーバー (存在する場合) に移行するか、サーバーに新しいディスクを追加します。 ただし、これが常に可能であるとは限りません。そのため、LVM から Ceph への移行は、この問題に対する優れた解決策となる可能性があります。 このオプションを選択すると、ローカル ストレージをあるハイパーバイザーから別のハイパーバイザーに移動する必要がなくなるため、サーバー間の移行プロセスも簡素化されます。 唯一の問題は、作業の実行中に VM を停止する必要があることです。

以下のレシピは以下から引用しました このブログの記事、その指示は実際に動作してテストされています。 ところで、 手間のかからない移行方法についても説明されています。ただし、私たちの場合は単純に必要なかったため、チェックしませんでした。 これがプロジェクトにとって重要な場合は、コメントで結果についてお知らせください。

実践的な部分に移りましょう。 この例では、virsh を使用し、それに応じて libvirt も使用します。 まず、データの移行先となる Ceph プールが libvirt に接続されていることを確認します。

virsh pool-dumpxml $ceph_pool

プールの説明には、認証データを含む Ceph への接続データが含まれている必要があります。

次のステップでは、LVM イメージが Ceph RBD に変換されます。 実行時間は主に画像のサイズによって異なります。

qemu-img convert -p -O rbd /dev/main/$vm_image_name rbd:$ceph_pool/$vm_image_name

変換後、LVM イメージが残ります。これは、VM の RBD への移行が失敗し、変更をロールバックする必要がある場合に役立ちます。 また、変更をすぐにロールバックできるように、仮想マシン構成ファイルのバックアップを作成しましょう。

virsh dumpxml $vm_name > $vm_name.xml
cp $vm_name.xml $vm_name_backup.xml

...そしてオリジナルを編集してください(vm_name.xml）。 ディスクの説明が含まれるブロックを見つけてみましょう (次の行で始まります) <disk type='file' device='disk'> そして次で終わります </disk>) を次の形式に縮小します。

<disk type='network' device='disk'>
<driver name='qemu'/>
<auth username='libvirt'>
  <secret type='ceph' uuid='sec-ret-uu-id'/>
 </auth>
<source protocol='rbd' name='$ceph_pool/$vm_image_name>
  <host name='10.0.0.1' port='6789'/>
  <host name='10.0.0.2' port='6789'/>
</source>
<target dev='vda' bus='virtio'/> 
<alias name='virtio-disk0'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
</disk>

いくつかの詳細を見てみましょう:

1. プロトコルへ source Ceph RBD 上のストレージへのアドレスが示されます (これは最初の段階で決定された Ceph プールと RBD イメージの名前を示すアドレスです)。
2. ブロック内 secret タイプが示されています ceph、およびそれに接続するためのシークレットの UUID。 その uuid は、次のコマンドを使用して見つけることができます。 virsh secret-list.
3. ブロック内 host Ceph モニターへのアドレスが示されます。

構成ファイルを編集し、LVM から RBD への変換が完了したら、変更した構成ファイルを適用して仮想マシンを起動できます。

virsh define $vm_name.xml
virsh start $vm_name

仮想マシンが正しく起動したかどうかを確認します。たとえば、SSH 経由で仮想マシンに接続することで確認できます。 virsh.

仮想マシンが正しく動作しており、他に問題が見つからない場合は、使用されなくなった LVM イメージを削除できます。

lvremove main/$vm_image_name

まとめ

私たちはここで説明したすべてのケースに実際に遭遇しました。この手順が他の管理者が同様の問題を解決するのに役立つことを願っています。 Ceph を使用した経験からのコメントや同様のストーリーがあれば、喜んでコメント欄に記入してください。

PS

私たちのブログもお読みください:

• «私たちの手は退屈のためではありません: K8 での Rook クラスターの復元";
• «ルークに行くか、ルークに行かないか、それが問題だ";
• «Rook - Kubernetes 用の「セルフサービス」データ ウェアハウス";
• «Ceph に基づく Kubernetes でのプロビジョニングによる永続ストレージの作成'。

出所： habr.com