Cephは、フェールオーバークラスターの構築に役立つように設計されたオブジェクトストレージです。 それでも、失敗は起こります。 Cephで働くすべての人は、CloudMouseまたはRosreestrについての伝説を知っています。 残念ながら、ネガティブな経験を私たちと共有することは慣習ではありません。失敗の原因はほとんどの場合隠されており、将来の世代が他人の過ちから学ぶことはできません。



さて、テストクラスターをセットアップしますが、実際のクラスターに近づき、骨で災害を分析します。 すべてのパフォーマンスの低下を測定し、メモリリークを見つけ、サービス回復のプロセスを分析します。 そして、すべて、落とし穴の研究にほぼ1年を費やしたArtemy Kapitulaのリーダーシップの下で、クラスターのパフォーマンスが低下し、ゼロに落ちず、レイテンシーが不適切な値にジャンプしませんでした。 そして、私は赤いグラフを得ました、それははるかに良いです。





次に、 DevOpsConf Russia 2018の最高のレポートの1つのビデオおよびテキストバージョンを見つけます。







スピーカーについて： Artemy KapitulaシステムアーキテクトRCNTEC。 同社は、IPテレフォニー（コラボレーション、リモートオフィスの組織、ソフトウェアデファインドストレージシステム、電源管理/配電システム）のソリューションを提供しています。 同社は主に企業部門で働いているため、DevOps市場ではあまり知られていません。 それでも、多くのプロジェクトでストレージインフラストラクチャの基本要素として使用されているCephには、ある程度の経験が蓄積されています。



Cephは、多くのソフトウェアコンポーネントを持つソフトウェア定義のリポジトリです。





図では：

• 上位レベルは、クラスター自体が通信する内部クラスターネットワークです。
• 下位レベル-実際にはCeph-は、データを格納する内部Cephのデーモン（MON、MDS、およびOSD）のセットです。

図では、それぞれ3つのOSDを持つ3つのグループを特別に選択しており、これらの各グループには通常1つのデータレプリカが含まれています。 その結果、データは3つのコピーに保存されます。



高レベルのクラスターネットワークは、Cephクライアントがデータにアクセスするためのネットワークです。 これを介して、クライアントはモニター、MDS（必要なユーザー）、OSDと通信します。 各クライアントは、各OSDおよび各モニターと独立して動作します。 したがって、 システムには単一障害点がないため 、非常に喜ばしいことです。

お客さま

●S3のお客様



S3はHTTP用のAPIです。 S3クライアントはHTTP上で動作し、Ceph Rados Gateway（RGW）コンポーネントに接続します。 それらはほとんどの場合、専用ネットワークを介してコンポーネントと通信します。 このネットワーク（S3ネットワークと呼びます）はHTTPのみを使用しますが、例外はまれです。



●仮想マシンを備えたハイパーバイザー



この顧客グループはよく使用されます。 これらはモニターおよびOSDで動作し、そこからクラスターの状態とデータの分布に関する一般情報を受け取ります。 データの場合、これらのクライアントは、クラスターパブリックネットワークを介してOSDデーモンに直接アクセスします。



●RBDクライアント



物理的なBR金属ホストもあり、通常はLinuxです。 RBDクライアントであり、Cephクラスター内に格納されているイメージ（仮想マシンのディスクイメージ）にアクセスします。



●CephFSクライアント



クライアントの4番目のグループはまだ多くありませんが、関心が高まっていますが、CephFSクラスターファイルシステムクライアントです。 CephFSクラスターシステムは、多くのノードから同時にマウントでき、すべてのノードが同じデータにアクセスして、各OSDと連携します。 つまり、ゲートウェイ自体はありません（Samba、NFSなど）。 問題は、そのようなクライアントはLinuxでしかなく、かなり新しいバージョンであるということです。





当社は企業市場で働いており、ESXi、HyperVなどが支配しています。 したがって、企業部門で何らかの形で使用されているCephクラスターは、適切な手法をサポートする必要があります。 Cephではこれだけでは不十分だったため、コンポーネントを使用してCephクラスターを改良および拡張する必要がありました。実際には、データを格納するための独自のプラットフォームであるCeph以外のものを構築しました。



さらに、企業部門のクライアントはLinuxを使用していませんが、ほとんどの場合Windows、場合によってはMac OSはCephクラスターに移動できません。 それらはある種のゲートウェイを通過する必要があり、この場合はボトルネックになります。



これらすべてのコンポーネントを追加する必要があり、わずかに幅の広いクラスターが得られました。





2つの中心的なコンポーネントがあります。SCSIGateways グループは 、FibreChannelまたはiSCSIを介してCephクラスター内のデータへのアクセスを提供します。 これらのコンポーネントは、HyperVおよびESXiをCephクラスターに接続するために使用されます。 PROXMOXクライアントは、RBDを介して独自の方法で動作します。



ファイルクライアントをクラスタネットワークに直接入れないようにし、いくつかのフォールトトレラントゲートウェイを割り当てます。 各ゲートウェイは、NFS、AFP、またはSMBを介してファイルクラスターシステムへのアクセスを提供します。 したがって、Linux、FreeBSD、またはクライアント、サーバー（OS X、Windows）だけでなく、ほぼすべてのクライアントがCephFSにアクセスできます。



これらすべてを管理するために、実際に独自のCephオーケストレーターと、多数のコンポーネントをすべて開発する必要がありました。 しかし、これについて話すのは意味がありません。これが私たちの開発だからです。 ほとんどの人は、まだ「裸の」Ceph自体に興味があります。



Cephは頻繁に使用され、場合によっては障害が発生します。 確かに、Cephで働くすべての人がCloudMouseの伝説を知っています。 これはひどい都市伝説ですが、すべてが見た目ほど悪くはありません。 Rosreestrについての新しいおとぎ話があります。 Cephはどこでも回転しており、その失敗はどこにでもありました。 どこかで致命的に終了し、どこかですぐに結果を排除することができました。



残念ながら、ネガティブな経験を共有することは慣習ではなく、誰もが関連情報を隠そうとしています。 外国企業はもう少しオープンです。特に、DigitalOcean（仮想マシンを配布する有名なプロバイダー）もほぼ1日間Cephに失敗しました。それは4月1日でした-素晴らしい日です！ 彼らは、いくつかのレポートを以下の短いログに投稿しました。





問題は午前7時に始まり、11時に何が起こっているのかを理解し、失敗を排除し始めました。 これを行うために、彼らは2つのコマンドを割り当てました。1つは何らかの理由でサーバーを実行し、そこにメモリをインストールし、もう1つは何らかの理由でサーバーを手動で起動し、すべてのサーバーを注意深く監視しました。 なんで？ ワンクリックですべてをオンにすることに慣れています。



分散システムが効果的に構築され、ほぼその機能の限界で動作する場合、基本的に何が起こるでしょうか？



この質問に答えるには、Cephクラスターの機能と障害の発生方法を調べる必要があります。

Ceph障害シナリオ

最初は、クラスターは正常に機能し、すべてが正常に機能しています。 その後、何かが発生すると、データが保存されているOSDデーモンは、クラスターの中央コンポーネント（モニター）との接続を失います。 この時点で、タイムアウトが発生し、クラスター全体が関与します。 クラスターは、何かがおかしいことに気付くまでしばらく待機し、その後、内部の知識を修正します。 その後、カスタマーサービスはある程度復元され、クラスターは再び劣化モードで動作します。 そして面白いのは、通常モードよりも速く動作することです-これは驚くべき事実です。



その後、障害を排除します。 電源が切れたと仮定すると、ラックは完全に切断されました。 電気技師が走って来て、すべてを復元し、電力を供給し、サーバーの電源を入れてから、楽しみが始まりました 。

サーバーが故障するとすべてが悪くなり、サーバーの電源を入れるとすべてが良くなるという事実に誰もが慣れています。 ここではすべてが間違っています。

クラスターは実質的に停止し、プライマリ同期を実行してから、スムーズで低速な回復を開始し、徐々に通常モードに戻ります。





上の図は、障害が発生したときのCephクラスターのパフォーマンスのグラフです。 ここで私たちが話したまさにその間隔が非常に明確にトレースされていることに注意してください：

• 約70秒までの通常動作。
• 1分から約130秒の失敗。
• 通常の動作よりも著しく高いプラトーは、劣化したクラスターの仕事です。
• 次に、欠落しているノードをオンにします-これはトレーニングクラスタであり、サーバーは3台とSSD 15台のみです。 サーバーは約260秒で起動します。
• サーバーの電源が入り、クラスターに入りました-IOPS'yが落ちました。

そこで実際に何が起こったのかを理解してみましょう。 私たちが最初に興味を持っているのは、チャートの最初の部分を掘り下げることです。

OSD障害

それぞれに複数のノードがある3つのラックを持つクラスターの例を考えてみましょう。 左側のラックに障害が発生した場合、すべてのOSDデーモン（ホストではありません！）一定の間隔でCephメッセージで自分自身をPingします。 複数のメッセージが失われた場合、メッセージがモニターに送信されます。「私、OSDなど、OSDなどに到達できません。」





この場合、メッセージは通常ホストごとにグループ化されます。つまり、異なるOSDからの2つのメッセージが同じホストに到着すると、それらは1つのメッセージに結合されます。 したがって、OSD 11とOSD 12がOSD 1に到達できないと報告した場合、これはホスト11がOSD 1について不平を言ったと解釈されます。OSD21とOSD 22が報告された場合、その後、モニターはOSD 1がダウン状態にあると見なし、これについてすべてのクラスターメンバーに（OSDマップの変更を介して）通知し、作業は低下モードで続行されます。





そのため、ここにクラスタと障害のあるラック（ホスト5とホスト6）があります。 電源がオンになったため、ホスト5とホスト6をオンにし、...

Cephの内部動作

そして今、最も興味深い部分は、 最初のデータ同期を開始していることです。 レプリカは多数あるため、それらは同期し、同じバージョンである必要があります。 OSDの開始プロセスの開始：

• OSDは、利用可能なバージョン、利用可能な履歴（pg_log-オブジェクトの現在のバージョンを判断するため）を読み取ります。
• その後、最新バージョンの劣化オブジェクト（missing_loc）がどのOSDにあり、どれが遅れているかを判断します。
• 下位バージョンが保存されている場合は、同期が必要です。新しいバージョンは、データの読み取りおよび書き込みの参照として使用できます。

すべてのOSDから収集されたストーリーが使用されますが、このストーリーは非常に多くなる可能性があります。 対応するバージョンが存在するクラスター内のオブジェクトのセットの実際の場所が決定されます。 クラスター内のオブジェクトの数、取得されたレコードの数、クラスターが劣化モードで長時間放置されている場合、ストーリーは長くなります。



比較のために 、RBDイメージで作業する場合のオブジェクトの一般的なサイズは4 MBです。 消去コードで作業する場合-1MB。 10 TBのディスクがある場合、ディスク上に100万メガバイトのオブジェクトを取得します。 サーバーに10個のディスクがある場合、既に1,000万個のオブジェクトがあり、32個のディスクがある場合（効率的なクラスターを構築しているため、割り当てが厳しい）、3200万個のオブジェクトをメモリに保持する必要があります。 さらに、実際には、各オブジェクトに関する情報は複数のコピーに保存されます。これは、各コピーがこの場所にこのバージョンにあり、このバージョンにあることを示しているためです。



RAMにある膨大な量のデータが判明します。

• オブジェクトが多いほど、missing_locの履歴が大きくなります。
• PGが多いほど、pg_logとOSDマップが多くなります。

さらに：

• ディスクサイズが大きいほど。
• 密度（各サーバーのディスク数）が高いほど、
• クラスターの負荷が高いほど、クラスターの速度が速くなります。
• OSDのダウン時間が長くなる（オフライン状態）;

言い換えると、 構築したクラスターが急勾配で、クラスターの一部が応答しなかった時間が長いほど、起動時に多くのRAMが必要になります 。

極端な最適化はすべての悪の根源です

「...そして、黒いOOMは夜に悪い男の子と女の子に来て、左右のすべてのプロセスを殺します」



市のシステム管理者の伝説

そのため、RAMには多くのメモリが必要であり、メモリ消費量が増加しており（クラスタの3分の1ですぐに開始しました）、当然のことながらシステムをSWAPに移行できます。 SWAPが悪いと思って、それを作成していないと考える人はたくさんいると思います。 私たちにはたくさんの記憶があります！」しかし、これは間違ったアプローチです。



SWAPファイルが事前に作成されていない場合、Linuxがより効率的に動作することが決定されたため、遅かれ早かれ、メモリキラー（OOMキラー）が発生します。最初に不運だった人。 私たちは楽観的な場所が何であるかを知っています-私たちは記憶を求め、彼らは私たちにそれを約束します、私たちは言います：「今、私たちに1つを与えてください」



これは、仮想メモリ領域で構成されていない限り、通常のLinuxジョブです。



プロセスはメモリキラーから抜け出し、素早く冷酷に抜け落ちます。 さらに、彼が死んだ他のプロセスは知りません。 彼は誰にも何かを通知する時間がなく、彼らは単に彼を終了させました。



その後、プロセスはもちろん再起動します-systemdを実行し、必要に応じて、落下したOSDも起動します。 倒れたOSDが始まり、...連鎖反応が始まります。





私たちの場合、OSD 8とOSD 9を起動しましたが、それらはすべてを粉砕し始めましたが、幸運なことにOSD 0とOSD 5はありませんでした。 彼らは再起動しました-彼らは彼らのデータを読み、同期し始め、残りを粉砕し始めました。 さらに3つの不運（OSD 9、OSD 4およびOSD 7）。 これら3つは再起動し、クラスター全体に圧力をかけ始めました。次のパックは不運でした。



クラスターは文字通り私たちの目の前でばらばらになり始めます 。 劣化は非常に迅速に発生し、この「非常に高速」は通常数分、最大数十分で表されます。 30個のノード（ラックごとに10個のノード）があり、停電のためにラックを削減した場合、6分後にクラスターの半分が存在します。



したがって、次のようなものが得られます。





ほとんどすべてのサーバーで、OSDに障害が発生しています。 そして、各サーバーで、つまり、障害のあるOSDの障害の各ドメインで発生する場合、 ほとんどのデータにアクセスできません 。 書き込み、読み取りのいずれの要求もブロックされますが、違いはありません。 それだけです！ 起きました。



そのような状況で何をすべきか？ より正確には、 何をする必要がありましたか？



回答：クラスター、つまりラック全体をすぐに起動しないでください。ただし、デーモンを1つずつ慎重に発生させてください。



しかし、私たちはそれを知りませんでした。 すぐに始めて、得たものを手に入れました。 この場合、4つのデーモン（8、9、10、11）のいずれかを起動すると、メモリ消費が約20％増加します。 原則として、私たちはそのような飛躍を遂げます。 その後、クラスターの性能低下に関する情報を保持するために使用された構造の一部がなくなるため、メモリ消費量が減少し始めます。 つまり、配置グループの一部が通常の状態に戻り、劣化状態を維持するために必要なすべてのものが解放されます- 理論的には解放されます。



例を見てみましょう。 左右のCコードはほとんど同じですが、違いは定数のみです。





次の2つの例は、システムに異なる量のメモリを要求します。

• 左-各1 MBの2048個。
• 右-2097152個の1 Kバイト。

それから両方の例は私達がそれらを上で撮影するのを待っています。 Enterキーを押すと、メモリが解放されます（最後の部分を除くすべて）。 これは非常に重要です-最後の部分が残ります。 そして再び、彼らは私たちが写真を撮るのを待っています。



以下は実際に起こったことです。

• まず、両方のプロセスが開始し、メモリを食べました。 真実のように聞こえます-2 GB RSS。
• ENTERを押して驚いてください。 大きなチャンクで強調表示された最初のプログラムはメモリを返しました。 しかし、2番目のプログラムは戻りませんでした。

これが起こった理由に対する答えは、Linux mallocにあります。



メモリを大きなチャンクで要求する場合、プロセッサのアドレス空間に与えられる匿名mmapメカニズムを使用して発行され、そこからメモリがカットされます。 free（）を実行すると、メモリが解放され、ページがページキャッシュ（システム）に返されます。



メモリを少しずつ割り当てると、sbrk（）が実行されます。 sbrk（）は、ポインタをヒープの末尾にシフトします。理論的には、メモリが使用されていない場合、メモリのページをシステムに返すことで、シフトされた末尾を戻すことができます。



次に図を見てください。 劣化したオブジェクトの場所の履歴には多くの記録があり、その後、ユーザーセッションが表示されました。これは長寿命のオブジェクトです。 私たちは同期し、余分な構造はすべてなくなりましたが、長命のオブジェクトは残り、sbrk（）を戻すことはできません。





SWAPがあれば解放できる空き領域がまだたくさんあります。 しかし、我々は賢いです-SWAPを無効にしました。



もちろん、ヒープの先頭からメモリの一部が使用されますが、これは一部に過ぎず、非常に重要な残りの部分が占有されたままになります。



そのような状況で何をすべきか？ 答えは以下です。

制御された起動

• 1つのOSDデーモンを起動します。
• 同期されるまで待機し、メモリバジェットを確認します。
• 次の悪魔の開始に耐えることができると理解したら、次の悪魔を開始します。
• そうでない場合は、ほとんどのメモリを消費したデーモンをすばやく再起動します。 彼は短い間ダウンしていた、彼は多くの歴史、行方不明などを持っていないので、彼はより少ないメモリを食べるでしょう、メモリの予算はわずかに増加します。
• クラスターを駆け巡り、それを制御し、すべてを徐々に上げていきます。
• 次のOSDに進むことができるかどうかを確認します。

DigitalOceanは実際にこれを達成しました。

「当社のデータセンターチームは、各ホストのメモリバジェットを手動で管理しながら、別のチームがゆっくりとノードを立ち上げながら、メモリ拡張を実行します。」





構成と現在の状況に戻りましょう。 これで、メモリー不足キラーの連鎖反応後にクラスターが崩壊しました。 赤のドメインではOSDの自動再起動を禁止し、青のドメインからノードを1つずつ起動します。 私たちの最初のタスクは常にserviceを復元することであるため、これがなぜ起こったのか理解することなく。 後でサービスを復元するときに整理します。 動作中、これは常に当てはまります。



サービスを復元するためにクラスターをターゲット状態にし、その後、方法論に従ってOSDの起動を開始します。 メモリバジェットを調整するために、必要に応じて他のコンポーネントを再起動します（次の9、10、11）。クラスタは同期され、メンテナンスを開始する準備ができているようです。



問題は、Cephでの書き込みメンテナンスの実行方法です 。





1つのマスターOSDと2つのスレーブの3つのレプリカがあります。 各配置グループのマスター/スレーブには独自のものがありますが、それぞれに1つのマスターと2つのスレーブがあることを明確にします。



書き込みまたは読み取り操作はマスターになります。 読むときに、マスターが正しいバージョンを持っている場合、彼はそれをクライアントに渡します。 記録はもう少し複雑です。すべてのレプリカで記録を繰り返す必要があります。 したがって、クライアントがOSD 0に64 KBを書き込むと、この例の同じ64 KBはOSD 5およびOSD 8に送られます。



しかし、多くのプロセスを再起動したため、OSD 8は非常に劣化しています。





Cephでは変更はバージョンからバージョンへの移行であるため、OSD 0およびOSD 5では新しいバージョンが、OSD 8では古いバージョンが使用されます。 つまり、記録を繰り返す（64 Kbを送信）には、OSD 8のバージョンを更新する必要があります-これは4 Mb（オブジェクトサイズ）です。 つまり、OSD 0で4 MBを読み取り、OSD 8に送信し、書き込み、同期状態になります。 今ではどこにも同じ新しいバージョンがあり、それから64 Kbを書き込みます。



今、数字が行く-最も興味深い。





クラスターパフォーマンスのテスト：

• 4 Kバイトの書き込み操作には1ミリ秒かかり、パフォーマンスは1ストリームで1000操作/秒です。
• サイズが4 MB（オブジェクトサイズ）の操作には22ミリ秒、パフォーマンスは45操作/秒かかります。

したがって、3つのドメインの1つに障害が発生すると、クラスターはしばらくの間劣化状態になり、ホットオブジェクトの半分は異なるバージョンに応じて拡散し、書き込み操作の半分は強制リカバリから始まります。



強制回復時間はおよそ計算されます-劣化したオブジェクトへの書き込み操作。





まず、22ミリ秒で4 MBを読み取り、22ミリ秒で書き込み、次に1ミリ秒で4 KBのデータ自体を書き込みます。 SSD上の劣化したオブジェクトへの書き込み操作ごとに合計45ミリ秒、標準パフォーマンスが1ミリ秒だった場合- パフォーマンスが45倍低下しました 。



劣化したオブジェクトの割合が多いほど、悪化します。

平均サービス時間

• オブジェクトの半分が劣化した場合、平均サービス時間は（45 + 1）/ 2 = 23ミリ秒です。
• オブジェクトの75％が劣化した場合、（45 * 3 + 1）/ 4 = 34ミリ秒 。
• 90％-（45 * 9 + 1）/ 10 = 41 ms-通常モードよりも40倍遅い場合。

これはCephの工場操作メカニズムであり、何もできません。 クラスターが部分的にオフラインになり、同時に別の部分がクライアントリクエストを処理した場合、スイッチをオンにすると、一部の操作でパフォーマンスが急激に数十回低下します。



次に、緊急モードでのCephパフォーマンステストの結果を2つのグラフで一度に検討します。

1. 一番下のグラフはおなじみです-これはクラスターのパフォーマンスです。通常モード、障害、障害検出、劣化モード、劣化モードでの動作です。
   
   
2. トップ-レイテンシー。 ここで、実際には、レイテンシは予想よりさらに悪化しています。 このクラスターは、テスト中にほぼ100％劣化しました（写真が見事なものになり、敗北の深さがあなたに届くように、特に長く保持しました）。 オーバーヘッドによる60ミリ秒からの遅延。初期計算では考慮されていません。
   
   

クラスターは通常の作業で復元され、主にネットワーク上に置かれます。 10 Gbネットワーク、つまり1,200 Mb / s。これは、ディスクの数に関係なく、サーバーあたり1秒あたり300オブジェクトを意味します。 10個のSSDがあります-毎秒300個すべてのオブジェクト、1つのディスク-おそらく毎秒300個のオブジェクトがあります。

効率的なクラスターを構築し、レプリケーションネットワークに入りました。

さらに、ディスク帯域幅がまだあります。 通常モードのディスクは900 MB / sを生成します（これは平均的なSSDです）。 通常、1秒あたり128 KBで約2,500の操作を提供します（通常、ESXiとHyperVは要求を128 KBに揃えます）。 しかし、劣化状態に入ると、1秒あたり225個のオブジェクトに遭遇します。 オブジェクトストアではなくファイルストアを使用すると、ログ（二重エントリ）もあり、1秒あたり110回の操作が行われ、すべてが非常に悲しくなります。



SSDは毎秒110回の操作を提供します-災害！



何ができますか？



回答1：アーキテクチャとのみ戦うことができます - 失敗の領域を増やしてください 。





ここで、列は左から右へ：失敗したドメインの数。 劣化したPGの割合。

対応する障害を考慮した平均サービス時間



拒否した場合：

• 3つのうち1つのドメイン、次に45ミリ秒は、楽観的な見積もりです。
• 10分の1の領域（予想を考慮に入れた確率論によれば）は約14ミリ秒です。
• 20のドメイン、次に8ミリ秒（PGの約10％が劣化）。

つまり、 ドメインの追加は効果的ですが 、障害のドメインは電源障害、サーバー、その他の機器向けに設計されており、これが常に可能であるとは限らないため、 費用がかかります。



回答2： 2番目のオプションは、画像内のオブジェクトのサイズ （順序、オブジェクトサイズ ）を小さくすることです。



オブジェクトのサイズを小さくすると、たとえば、4 MBからの操作は2または1 M​​Bになります。 その後、すべてが数倍高速になりますが、それでも通常モードよりはるかに遅くなります。 この場合：

• オブジェクトの複製時間は大幅に減少します
• 回復中のクラスターのレイテンシーを比例的に削減しました。

ただし、すべての料金を支払う必要があります。

• オブジェクトの数が増加します。
• メモリ消費量は、ほぼ要因によって増加します。
• 最も不快なことは、すでに作成されたイメージのオブジェクトのサイズを変更できないことです。 4 MBで作成されたため、そのまま残ります。

最大のパフォーマンス（32 MBオブジェクト）のために作成した場合、すぐに非常に明確になりました！



回答3：別の方法はCephを改良することです 。



私の機能的責任の一部として、システムアーキテクトおよび開発者として、私はCephに深く入りました 。 調査の過程で、劣化したオブジェクトでの記録中にクラスターを全員に複製させず、同時にクラスターの整合性を維持する、つまり送信データの一部を切り捨てるように強制しました。 ここで非常に興味深い写真であることが判明しました。





上のグラフのクラスターパフォーマンス、下のグラフ-レイテンシー。 青-人員配置図、赤-実験的。 遅延は実際には最小で30％増加しますが、このスケールでは見えないだけです。つまり、すべてがうまくいくわけではありません。



コミュニティでは、このコードは生産前の状態であるため、まだ利用できません。 外出先で有効にすることはできませんが、これは私たちには適していません。 最後にそれをもたらすとき、私たちはそれをします。

おわりに

この作業スケジュールを取得するのに約1人年かかりました。 それほど多くの労力を費やす機会がなく、Cephの中に入り、そこで基本的なことをするなら、ここでできることはここにあります。



● 事故の際に何かをするのは無意味です。

事故の間、パニックに陥ることはなく、そのための準備が必要です。 これは運動が必ず行われなければならないことを意味します。 これがなければ、あなたの理論的研究はすべて無駄です。 さらに、本番環境とほぼ同じ構成で演習を実施することを強くお勧めします。 演習で十分なデータがない場合、DigitalOceanと私たちが遭遇したメモリの問題を踏むことはありません。 大量のデータがある場合は、次に進むと何をすべきかわかりません。



さらに、データが少なく負荷が少ない場合、パフォーマンスがこのように低下​​することはありません。 クライアントがあなたのところに来て、叫び始めます。 何が起こったのですか？！」彼らはあなたの技術サポートを引き、技術サポートはあなたを、あなたは頭を握りしめます。 すべてが悲しくなります、そしてあなたはこのために準備する必要があります：我々が尋ねる場所、どれくらいのダウンタイムがおよそ続くかを理解するために。



● クラスターコンポーネント（OSD）を削除することはできません。

一見阻害的なコンポーネントを削除するたびに、データの一部、これまでの冗長データの一部が失われますが、他の場所で問題が発生した場合は、必要になる場合があります。 したがって、外出先でOSDクラスターコンポーネント（モニターなど）を削除しないでください 。 これを行う場合、あなた自身は邪悪なピノキオです。



● クラスターを正しく設計します。

設計段階では、スケジュールされたアクティビティまたは計画外の状況が発生した場合に、使用できないOSDの数を最小限に抑える必要があります。 可能であれば、より多くの障害ドメインを作成します 。 できない場合は、少なくともそのようなハードウェアを選択して、サーバーをシャットダウンせずにディスクを変更できるようにします。



● OSDノードに十分なRAMを割り当てます。



● SWAPを無効にしないでください。

SWAPの動作は、Cephの動作だけでなく、一般的なLinuxの動作全般です。 これに備えて、これを覚えておく必要があります。



● クラスター複製ネットワークのパフォーマンスを最大化します。

100％、さらには10％の通常モードで使用しないでください。 しかし、緊急事態が発生した場合、余分なギガビットがあれば、あなたの生活はより簡単になり、非常に大きくなります。



● 頻繁に変更されるRBDオブジェクトのサイズを小さくしたり、Rados Getwayでオブジェクトのサイズを小さくしたりすることが理にかなっている場合があります。

ただし、オブジェクトのサイズを小さくするには追加のRAMが必要になることに注意してください。 SWAPを追加することを忘れないでください-それを恐れる必要はありません。 SWAPアクティビティがあるという事実はそれほど恐ろしいものではありません。システムが特に積極的に使用されていないものを吹き飛ばす可能性が高いからです。

— DevOpsConf Russia. . , youtube , DevOps-.