クラウドファイルストレージの人気は高まり続けており、その要件は増え続けています。 現在のシステムは、これらのシステムをサポートおよび拡張するためのリソースを大幅に消費することなく、これらの要件をすべて満たすことはできません。 システムとは、1つまたは別のレベルのデータアクセスを持つクラスターを意味します。 ユーザーにとって、ストレージの信頼性と高可用性は重要であり、ファイルを常に簡単かつ迅速に受信でき、データ損失のリスクはゼロになる傾向があります。 同様に、ハードウェアおよびソフトウェアコンポーネントのサポート、スケーラビリティ、および低コストのシンプルさは、そのようなリポジトリのサプライヤおよび管理者にとって重要です。

Cephに会う

Cephはオープンソースのソフトウェア定義の分散ファイルシステムであり、ボトルネックや単一障害点がありません。ペタバイトサイズに簡単に拡張できるノードのクラスターであり、さまざまな機能を実行し、データストレージとレプリケーションを提供し、負荷分散を保証します。高可用性と信頼性。 開発者は有料サポートを提供できますが、システムは無料です。 特別な機器は必要ありません。







ドライブ、ノード、またはノードのグループに障害が発生した場合、Cephはデータの安全性を確保するだけでなく、障害が発生したノードまたはディスクが機能するものと交換されるまで、失われたコピーを他のノードに復元します。 同時に、ダウンタイムなしで再構築が行われ、顧客には透過的です。

ノードの役割と悪魔

システムはソフトウェア定義されており、標準のファイルシステムとネットワークレベルで実行されるため、さまざまなサーバーを使用して、さまざまなサイズのさまざまなディスクでそれらを満たし、この幸福を何らかの種類のネットワークに接続して（より高速に）クラスターを上げることができます。 2番目のネットワークカードでこれらのサーバーに接続し、2番目のネットワークに接続して、サーバー間通信を高速化できます。 また、仮想環境でも設定と回路を使用した実験を簡単に実行できます。 私の実験の経験から、このプロセスで最も時間がかかるのはOSのインストールであることがわかります。 ディスクと構成済みネットワークを備えた3つのサーバーがある場合、デフォルト設定で稼働中のクラスターを上げるには5〜10分かかります（すべてが正しく行われた場合）。







Cephデーモンはオペレーティングシステム上で動作し、さまざまなクラスターロールを実行します。 したがって、1つのサーバーは、たとえばモニター（MON）とデータウェアハウス（OSD）の両方として機能できます。 一方、別のサーバーは、データウェアハウスおよびメタデータサーバー（MDS）として機能できます。 大規模なクラスターでは、デーモンは別々のマシンで実行されますが、サーバーの数が非常に限られている小規模なクラスターでは、一部のサーバーは一度に2つまたは3つの役割を果たします。 サーバーの能力と役割自体に依存します。 もちろん、すべてが別々のサーバーで高速に動作しますが、これを常に実装できるとは限りません。 クラスターは、1台のマシンと1台のディスクからでも組み立てることができ、機能します。 別の会話は、これは意味をなさないということです。 ソフトウェアの定義可能性により、ストレージはRAIDまたはiSCSIデバイスの上でも上げることができますが、ほとんどの場合、これも意味がありません。



ドキュメントには、3種類のデーモンがリストされています。

• 月-デーモンの監視
• OSD-リポジトリデーモン
• MDS-メタデータサーバー（CephFSを使用する場合にのみ必要）

最初のクラスターは、それらのクラスターの役割を組み合わせて、複数のマシンから作成できます。 その後、クラスターの成長と新しいサーバーの追加により、一部の役割を他のマシンに複製したり、別のサーバーに完全に転送したりできます。

ストレージ構造

そもそも、短くてわかりにくいです。 クラスターは、さまざまな目的と設定で1つまたは複数のデータプールを持つことができます。 プールは配置グループに分けられます。 配置グループには、クライアントがアクセスするオブジェクトが格納されます。 これにより、論理グループが終了し、物理グループが開始されます。これは、各配置グループに1つのメインディスクと複数のレプリカディスクがあるためです（プールレプリケーション係数に依存します）。 言い換えると、論理レベルでは、オブジェクトは特定の配置グループと、物理的に割り当てられたディスクに保存されます。 同時に、ディスクは物理的に異なるノードまたは異なるデータセンターに存在できます。







さらに詳細かつ理解可能。

レプリケーション係数（RF）

レプリケーション係数は、データの冗長性のレベルです。 異なるドライブに保存されるデータのコピーの数。 変数のサイズがこのパラメーターを担当します。 複製係数はプールごとに異なる場合があり、その場で変更できます。 一般に、Cephでは、ほとんどすべてのパラメーターをその場で変更でき、クラスター応答を即座に受信できます。 最初は、サイズ= 2に設定できます。この場合、プールは1つのデータの2つのコピーを異なるディスクに保存します。 このプールパラメーターは、サイズ= 3に変更でき、同時にクラスターがデータの再配布を開始し、クライアントを停止することなく、ディスク上の既存データの別のコピーをレイアウトします。

プール

プールは、ユーザーデータのストレージを整理するための論理的な抽象コンテナです。 データはオブジェクトとしてプールに保存されます。 配置グループの異なるセットを使用して、複数のプールを同じディスクに（または異なる構成方法で）展開できます。 各プールには、レプリケーション係数、配置グループの数、作業に必要なオブジェクトのライブレプリカの最小数など、多くの構成可能なパラメーターがあります。各プールは、独自のレプリケーションポリシー（都市、データセンター、ラック、さらにはディスク）で構成できます。 たとえば、ホスティングプールのサイズ= 3のレプリケーション係数があり、データセンターが障害ゾーンになります。 そして、Cephは、各データに3つのデータセンターに1つのコピーがあることを保証します。 それまでの間、仮想マシンのプールにはサイズ= 2のレプリケーション係数があり、サーバーラックはすでに障害レベルになっています。 この場合、クラスターは2つのコピーのみを保存します。 さらに、1つのデータセンターに仮想イメージストレージを備えた2つのラックがあり、別のデータセンターに2つのラックがある場合、システムはデータセンターに注意を払わず、データの両方のコピーが1つのデータセンターに飛ぶことができますが、必要に応じて異なるラックで保証されます。

配置グループ（PG）

配置グループは、物理ストレージレベル（ディスク）とデータの論理編成（プール）の間のリンクです。



論理レベルの各オブジェクトは、特定の配置グループに保存されます。 物理レベルでは、この配置グループに含まれる異なる物理ディスク上の必要なコピー数にあります（実際、ディスクではなくOSDですが、通常1つのOSDは1つのディスクであり、簡単にするためにこれを呼び出します）ドライブ、私はあなたに思い出させますが、その後ろにRAIDアレイまたはiSCSIデバイスがあるかもしれません）。 サイズ= 3の複製係数では、各配置グループに3つのディスクが含まれます。 ただし、同時に、各ディスクはさまざまな配置グループに属し、一部のグループではプライマリになり、他のグループではレプリカになります。 たとえば、OSDが3つの配置グループの一部である場合、そのようなOSDが落ちた場合、配置グループは作業からそれを除外し、各配置グループはその場所で作業OSDを選択し、その上にデータを拡散します。 このメカニズムを使用すると、データと負荷がかなり均一に分散されます。 これは非常にシンプルで柔軟なソリューションです。

モニター

モニターは、クラスターを開始するコーディネーターとして機能するデーモンです。 少なくとも1つのモニターが機能すると、Cephクラスターが作成されます。 モニターは、さまざまなカードを他のモニターと交換することにより、クラスターの状態と状態に関する情報を保存します。 クライアントはモニターに目を向けて、どのOSDにデータの書き込み/読み取りを行うかを見つけます。 新しいストレージを展開する場合、最初に行うことはモニター（または複数）を作成することです。 クラスターは1つのモニター上に存在できますが、1つのモニターの落下によるシステム全体の落下を避けるために、3つまたは5つのモニターを作成することをお勧めします。 主なことは、スプリットブレインの状況を避けるために、これらの数が奇数であるべきだということです。 モニターはクォーラムで動作するため、モニターの半分以上が落ちた場合、データの不整合を防ぐためにクラスターがブロックされます。

OSD（オブジェクトストレージデバイス）

OSDは、データ自体を保存し、他のOSDとデータを交換することでクライアント要求を処理するストレージユニットです。 これは通常、ディスクです。 通常、各OSDには、このディスクがインストールされている任意のマシンで実行できる個別のOSDデーモンがあります。 これは、デプロイ時にクラスターに追加する必要がある2番目のものです。 1つのモニターと1つのOSD-クラスターを持ち上げて使用を開始するための最小セット。 サーバーがストレージ用に12個のディスクをスピンする場合、サーバーは多くのOSDデーモンを実行します。 クライアントは、OSD自体と直接連携して、ボトルネックを回避し、負荷分散を実現します。 クライアントは常に、ある配置グループのプライマリOSDにオブジェクトを書き込み、このOSDは同じ配置グループの残りの（セカンダリ）OSDとデータを同期します。 成功したレコードの確認は、プライマリOSDへの書き込み直後、またはレコードの最小数に達した後（プールパラメーターmin_size）にクライアントに送信できます。 たとえば、複製係数がサイズ= 3およびmin_size = 2の場合、3つのOSDの少なくとも2つ（プライマリを含む）にオブジェクトが書き込まれると、成功した記録の確認がクライアントに送信されます。



これらのパラメーターを設定するためのさまざまなオプションを使用して、さまざまな動作を観察します。



サイズ= 3およびmin_size = 2の場合、3つのOSD配置グループのうち2つが有効である限り、すべて問題ありません。 ライブOSDが1つしか残っていない場合、クラスターは、少なくとも1つ以上のOSDが有効になるまで、この配置グループの操作をフリーズします。



size = min_sizeの場合、配置グループは、その一部であるOSDが落ちたときにブロックされます。 また、データスミアリングのレベルが高いため、少なくとも1つのOSDのクラッシュのほとんどは、クラスター全体またはほぼ全体の凍結で終了します。 したがって、サイズパラメータは常にmin_sizeパラメータより少なくとも1ポイント大きくする必要があります。



サイズ= 1の場合、クラスターは機能しますが、OSDが停止すると、回復不能なデータ損失が発生します。 Cephを使用すると、このパラメーターを1に設定できますが、管理者が短時間これを行っても、リスクを負うことになります。



OSDディスクは、ログとデータ自体の2つの部分で構成されています。 したがって、データは最初にログに書き込まれ、次にデータセクションに書き込まれます。 一方で、これは追加の信頼性といくつかの最適化を提供し、他方では、パフォーマンスに影響する追加の操作を提供します。 ログパフォーマンスの問題を以下で検討します。

クラッシュアルゴリズム

分散化と分散のメカニズムは、システムアーキテクチャで重要な役割を果たすいわゆるCRUSHアルゴリズム（Controlled Replicated Under Scalable Hashing）に基づいています。 このアルゴリズムにより、オブジェクトの名前のハッシュとクラスターの物理的および論理的構造（データセンター、ホール、行、ラック、ノード、ディスク）に基づいて形成される特定のマップに基づいて、オブジェクトの場所を一意に決定できます。 マップには位置情報は含まれません。 各クライアントは、CRUSHアルゴリズムと現在モニターを使用して、以前モニターに尋ねていたデータへのパスを自分で決定します。 ディスクを追加するか、サーバーをクラッシュすると、マップが更新されます。



決定論のため、2つの異なるクライアントが1つのオブジェクトへの同じ一意のパスを独自に見つけるため、これらのすべてのパスを一部のサーバーに保持して相互に同期する必要がなくなり、ストレージ全体に非常に大きな負荷がかかります。



例：







クライアントは、オブジェクトobject1をプールPool1に書き込みたいと考えています。 これを行うには、モニターが以前に親切に提供してくれた配置グループのマップを見て、Pool1が10個の配置グループに分割されていることを確認します。 次に、オブジェクト名とPool1内の配置グループの総数を入力として受け取るCRUSHアルゴリズムを使用して、配置グループのIDが計算されます。 マップに従って、クライアントはこの配置グループに3つのOSDが割り当てられていることを理解します（たとえば、番号は17、9、および22）。最初のOSDはプライマリであり、クライアントはその上に記録します。 ちなみに、このプールにはレプリケーション係数サイズ= 3が設定されているため、3つあります。 オブジェクトがOSD_17に正常に書き込まれた後、クライアントは終了し（プールパラメーターmin_size = 1の場合）、OSD_17はこのオブジェクトをこの配置グループに割り当てられたOSD_9およびOSD_22に複製します。 これは、アルゴリズムの操作の簡単な説明であることを理解することが重要です。



デフォルトでは、CRUSHカードはフラットで、すべてのノードは同じスペースにあります。 ただし、サーバーをラック、列のラック、ホールの列、データセンターのホール、異なる都市や惑星のデータセンターに分散させることで、このプレーンを簡単にツリーに変えることができます。どのレベルを障害ゾーンと見なすべきかを示します。 そのような新しいカードを使用すると、Cephは組織の個々の特性を考慮してデータを配信する能力が高まり、データセンターでの火災や都市全体でのmet石の悲しい結果を防ぎます。 さらに、この柔軟なメカニズムのおかげで、上位レベル（データセンターと都市）と下位レベル（たとえば、同じサーバー内のディスクグループへの追加分割）の両方で追加のレイヤーを作成できます。

キャッシング

Cephは、キャッシュ手法を使用してクラスターのパフォーマンスを向上させるいくつかの方法を提供します。



一次親和性

各OSDにはいくつかの重みがあり、そのうちの1つは、配置グループのどのOSDがプライマリになるかを担当します。 そして、前にわかったように、クライアントはデータをプライマリOSDに正確に書き込みます。 そのため、クラスターに多数のSSDドライブを追加して、常にプライマリにし、プライマリアフィニティHDDの重量をゼロに減らすことができます。 そして、記録は常に最初に高速ディスクで実行され、その後ゆっくりと低速ディスクに複製されます。 この方法は最も間違っていますが、実装が最も簡単です。 主な欠点は、データの1つのコピーが常にSSD上にあり、複製を完全にカバーするにはそのようなディスクが大量に必要になることです。 この方法は実際に誰かが使用していましたが、録音の優先順位を管理する可能性について話すために、私はむしろそれを言及しました。



SSDへのロギング

一般に、パフォーマンスの大部分はOSDログに依存します。 記録するとき、デーモンは最初にデータをログに書き込み、次にリポジトリ自体に書き込みます。 これは、BTRFSをOSDファイルシステムとして使用する場合を除き、常に当てはまります。OSDファイルシステムは、copy-on-writeテクニックのおかげでこれを並行して行うことができますが、産業用にどれだけ準備ができているかはまだわかりません。 各OSDには独自のログがあり、デフォルトでは、データ自体と同じドライブ上にあります。 ただし、1枚のSSDで4枚または5枚のディスクのログを取り出すことができるため、書き込み操作の速度が著しく低下することはありません。 この方法は非常に柔軟で便利ではありませんが、十分に単純です。 この方法の欠点は、ログを使用してSSDを終了すると、いくつかのOSDが一度に失われることです。これはあまり快適ではなく、クラスターの成長に合わせて追加のすべてのサポートがさらに困難になります。



現金引き裂き

この方法の正統性は、柔軟性とスケーラビリティです。 スキームは、コールドデータのプールとホットデータのプールがあることです。 オブジェクトに頻繁にアクセスすると、そのオブジェクトは加熱され、高速SSDで構成されるホットプールに落ちます。 次に、オブジェクトが冷めると、低速のHDDを備えたコールドプールに入ります。 このスキームにより、ホットプール内のSSDを簡単に変更できます。これは、加熱と冷却のパラメーターが調整可能であるため、任意のサイズにすることができます。

顧客の視点から

Cephは、データにアクセスするためのさまざまなオプション（ブロックデバイス、ファイルシステム、オブジェクトストレージ）をクライアントに提供します。







ブロックデバイス（RBD、Radosブロックデバイス）

Cephを使用すると、データプールにRBDブロックデバイスを作成し、それをサポートするオペレーティングシステムに後でマウントできます（執筆時点では、さまざまなLinuxディストリビューションしかありませんでしたが、FreeBSDとVMWareもこの方向で機能します）。 クライアントがRBDをサポートしていない場合（Windowsなど）、RBDをサポートする中間iSCSIターゲット（tgt-rbdなど）を使用できます。 さらに、そのようなブロックデバイスはスナップショットをサポートします。



CephFSファイルシステム

カーネルバージョン2.6.34以降のLinuxを使用している場合、クライアントはCephFSファイルシステムをマウントできます。 カーネルバージョンが古い場合は、FUSE（ユーザースペースのファイルシステム）を使用してマウントできます。 クライアントがCephをファイルシステムとしてマウントするには、クラスター内で少なくとも1つのメタデータサーバー（MDS）を上げる必要があります。



ゲートウェイオブジェクト

RGWゲートウェイ（RADOSゲートウェイ）を使用すると、RESTful Amazon S3またはOpenStack Swift互換APIを介してストレージを使用する機会を顧客に与えることができます。



その他

これらのデータアクセスレイヤーはすべて、RADOSレイヤーの上で動作します。 リストは、librados APIを使用して独自のデータアクセスレイヤーを開発することで補完できます（上記のアクセスレイヤーが機能します）。 現在、C、Python、Ruby、Java、およびPHPのバインダーがあります。



RADOS（Reliable Autonomic Distributed Object Store）は、簡単に言えば、クライアントとクラスター間の相互作用のレイヤーです。



ウィキペディアによると、Ceph自体はC ++およびPythonで記述されており、Canonical、CERN、Cisco、Fujitsu、Intel、Red Hat、SanDisk、およびSUSEが開発に参加しています。

印象

なぜこのすべてを書いて絵を描いたのですか？ そして、これらすべての利点にもかかわらず、Cephはあまり人気がないか、インターネット上の情報の量から判断して、密かにそれを食べます。



Cephは柔軟性があり、シンプルで便利であることがわかりました。 クラスターは、通常のネットワーク内の任意のハードウェアで発生させることができ、最小限の時間と労力を費やしますが、Ceph自体がデータの安全性を管理し、ハードウェア障害の場合に必要な措置を取ります。 Cephには柔軟性があり、シンプルで、スケーラブルであるという多くの観点があります。 ただし、パフォーマンスレビューは非常に多様です。 おそらく、誰かがログに対処しなかった、誰かがネットワークに失敗し、I / O操作が遅れたのでしょう。 つまり、クラスターを動作させるのは簡単ですが、高速で動作させるのはおそらく難しいでしょう。 したがって、本番環境でCephを使用した経験があるITプロフェッショナルにアピールします。 否定的な印象についてのコメントを共有してください。



参照資料

Cephウェブサイト

ウィキペディア

ドキュメント

Github

Cephレシピブック

Ceph Bookの学習

10分でVMWareのCeph

ロシア語で集中的なセフ