SDS Cephを選択して構成する

みなさん、こんにちは。読者の皆さん、実務家の皆さん！



SANを使用したあらゆる種類の多様なブロック/ファイルストレージを感じましたが、タスクが理解できるようになるまで、一般的に満足していました-オブジェクトストレージとは何ですか？ そして、すでに多くの決定が市場にある場合、1つを選択してください...

オブジェクトストレージが選ばれる理由

まあ、まず-これはオブジェクトを保存するために特別に設計されたストレージシステムです。 そして、これはまさにストレージです。



第二に-システムはエレガントにWORM （一度書き込み、多く読み取り）、またはその逆に変わります。

第三に、異なるユーザーのデータを使用してプールを分離し、ユーザーのクォータ、プールサイズ、オブジェクトの数、プール内のバケットの数を柔軟に設定します。 一般的に、ストレージシステム管理の通常の機能。

4番目、5番目など 彼がこれを必要とする理由を知っている人は誰でも、複数の利点を見つけるはずです。 たぶん欠陥。



オブジェクトストレージの選択要件：



-事実上の標準OS-CentOS;

-データセンター間で冗長なオブジェクトストレージが必要です。

-可能であれば、完全に無料です。

非常に貧弱で曖昧な要件です。



利用可能なものの概要から検索プロセスを開始しました。

• ScaleIOはクールでシンプルですが、側への一歩はライセンスであり、私は本当に独立を望んでいます。 また、移動中に、データセンターにフォールトトレランス構成を提供する可能性を発見しませんでした。
• OpenIOは明らかに初心者プロジェクトであり、必要な機能の説明が見つかりませんでした。
• Ceph-まあ、試してみてください。 最初のわずかな要件を満たします。

Cephを選んだので、私は熊手で歩く道に乗り出しました。そこには十分なものがありましたが、楽観的に渡されました。



最初に行われたのは、バージョンの選択です 。 私は最後のLuminousをインストールしませんでした。リリースがあっただけで、私たちは真面目な会社です。 :) Hammerについて多くの苦情がありました。 私は安定版のJewelが好きでした。 リポジトリを作成し、ceph.comにリンクし、タスクをクラウンに入れて、nginxを通じてリリースしました。 EPELも必要です。



# Ceph-Jewel

/usr/bin/rsync -avz --delete --exclude='repo*' rsync://download.ceph.com/ceph/rpm-jewel/el7/SRPMS/ /var/www/html/repos/ceph/ceph-jewel/el7/SRPMS/

/usr/bin/rsync -avz --delete --exclude='repo*' rsync://download.ceph.com/ceph/rpm-jewel/el7/noarch/ /var/www/html/repos/ceph/ceph-jewel/el7/noarch/

/usr/bin/rsync -avz --delete --exclude='repo*' rsync://download.ceph.com/ceph/rpm-jewel/el7/x86_64/ /var/www/html/repos/ceph/ceph-jewel/el7/x86_64/

# EPEL7

/usr/bin/rsync -avz --delete --exclude='repo*' rsync://mirror.yandex.ru/fedora-epel/7/x86_64/ /var/www/html/repos/epel/7/x86_64/

/usr/bin/rsync -avz --delete --exclude='repo*' rsync://mirror.yandex.ru/fedora-epel/7/SRPMS/ /var/www/html/repos/epel/7/SRPMS/

# Ceph-Jewel

/usr/bin/createrepo --update /var/www/html/repos/ceph/ceph-jewel/el7/x86_64/

/usr/bin/createrepo --update /var/www/html/repos/ceph/ceph-jewel/el7/SRPMS/

/usr/bin/createrepo --update /var/www/html/repos/ceph/ceph-jewel/el7/noarch/

# EPEL7

/usr/bin/createrepo --update /var/www/html/repos/epel/7/x86_64/

/usr/bin/createrepo --update /var/www/html/repos/epel/7/SRPMS/







さらに計画とインストールを進めました。



最初に、ソリューションのアーキテクチャを描画する必要があります。テストアーキテクチャであっても、努力する売上に合わせて簡単にスケーリングできます。 私は次のものを手に入れました：



-各データセンターに3つのOSDノード。

-3つのサイト上の3つのMONノード（それぞれに1つ）。Cephクラスターの大部分を提供します。 （モニターノードは他のロールと一緒に上げることができますが、一般的にはそれらを仮想化し、VMWareに配置することを好みました）

-S3またはSwiftプロトコルを介してObject StorageへのAPIアクセスを提供する2つのRGWノード（各データセンターに1つ）。 （RadosGWノードは他のロールと一緒に上げることができますが、それらを仮想化し、VMWareにレンダリングすることを好みました）

-展開および集中管理用のノード。 （VMWare環境のデータセンター間をロールする仮想サーバー）

-クラスター監視ノードと現在/過去のパフォーマンス。 （デプロイノードと同じストーリー）



ネットワークの計画 -Cephクラスター「エコシステム」に1つのネットワークを使用しました。 展開ノード、監視ノード、RGWノードへのアクセスのために、2つのネットワークが転送されました。



-リソースにアクセスするためのCephクラスターネットワーク。

-ネットワーク「パブリック」、これらのノードへの「外部からの」アクセス用。

公式ドキュメントでは、OSDノード間のハートビートとデータの移動にクラスター内で異なるネットワークを使用することを推奨していますが、同じドキュメントでは1つのネットワークを使用するとレイテンシーが減少すると述べています...クラスター全体で1つのネットワークを選択しました。



クラスタのインストールは、CentOSを使用したノードサーバーの準備という基本的な手順から始まります。

-リポジトリがローカルの場合、リポジトリを構成します。 （たとえば、私のような）EPELリポジトリも必要です。

-/ etc / hostsのすべてのノードで、クラスターのすべてのノードに関する情報を入力します。 インフラストラクチャがDHCPを使用している場合、アドレスをバインドし、とにかく/ etc / hostsを追加する方が適切です。

-ntpを設定し、時刻を同期します。これは、Cephが正しく機能するために重要です。

-Cephクラスターを管理するユーザーを作成します。名前は何でも、主なものは同じ名前ではありません-ceph。



たとえば、次のように：



sudo useradd -d /home/cephadmin -m cephadmin

sudo passwd cephadmin

echo "cephadmin ALL = (root) NOPASSWD:ALL" | sudo tee /etc/sudoers.d/cephadmin

chmod 0440 /etc/sudoers.d/cephadmin







-展開ノードにsshサーバーをインストールし、作成したユーザーのキーを生成し、クラスターのすべてのノードにキーをコピーし、NOPASSWDオプションでsudoに登録します。 ノードの展開からクラスターのすべてのノードへのユーザーのパスワードなしのログインを取得する必要があります。

-作成されたユーザーの構成ファイルを.sshディレクトリに作成し、すべてのノードを記述して、このファイルに600の権限を設定します。



[cephadmin@ceph-deploy .ssh]$ cat config

Host ceph-cod1-osd-n1

Hostname ceph-cod1-osd-n1

User cephadmin

...................

Host ceph-cod2-osd-n3

Hostname ceph-cod2-osd-n3

User cephadmin







-firewalldでポート6789 / tcpおよび6800-7100 / tcpを開きます（そのままにする場合）。

-SELinuxを無効にします。 （cefから-インストール済みのJewelバージョンですが、通常のSEポリシーはロールバックされます）

-クラスター管理ノードで、 yum install ceph-deployを実行します。

すべて準備完了のようです！ クラスター自体のインストールと構成に進みます

ユーザーのホームディレクトリで、クラスター構成が置かれるディレクトリを作成します。 このフォルダは失うことのないほうがいい 復元には非常に問題があります。 クラスターを構成し、さまざまな役割とサービスを台無しにするプロセスでは、このディレクトリにファイルとキーが補充されます。



将来のクラスターで最初のMONノードを作成します： ceph-deploy new＃our_ MON_ node_name 。 ceph.confファイルは以前に作成されたディレクトリに表示され、そこにクラスターの説明が入力され、その内容が必要なノードに適用されます。



すべてのノードにCeph-Jewel自体をインストールします： ceph-deploy install --release = jewel --no-adjust-repos＃node1＃node2 ... #nodeN --no-adjust-reposキーは、インストール用のリポジトリがローカルであり、インストールスクリプトが独自のリポジトリを登録するのではなく、既存の/etc/yum.repos.d/*.repoでパスを探す場合に使用する必要があります。 Jewelでは、特に明記されていない限り、安定バージョンがデフォルトでインストールされます。



インストールが成功したら 、 ceph-deploy mon create-initialクラスターを初期化します



クラスターの初期化後、初期設定はfsidを含むceph.confファイルに書き込まれます。 その後、このfsidがクラスターによって変更または失われると、その「崩壊」につながり、その結果、情報が失われます。 そのため、ceph.confで初期構成を取得した後、（バックアップを作成して）大胆に開き、必要な値の編集と入力を開始します。 必要なノードにスピルする場合、 -overwrite-confオプションを指定する必要があります。 まあ、おおよその構成の内容：



[root@ceph-deploy ceph-cluster]# cat /home/cephadmin/ceph-cluster/ceph.conf

[global]

fsid = #-_

mon_initial_members = ceph-cod1-mon-n1, ceph-cod1-mon-n2, ceph-cod2-mon-n1

mon_host = ip-adress1,ip-adress2,ip-adress3

auth_cluster_required = cephx

auth_service_required = cephx

auth_client_required = cephx



#Choose reasonable numbers for number of replicas and placement groups.

osd pool default size = 2 # Write an object 2 times

osd pool default min size = 1 # Allow writing 1 copy in a degraded state

osd pool default pg num = 256

osd pool default pgp num = 256



#Choose a reasonable crush leaf type

#0 for a 1-node cluster.

#1 for a multi node cluster in a single rack

#2 for a multi node, multi chassis cluster with multiple hosts in a chassis

#3 for a multi node cluster with hosts across racks, etc.

osd crush chooseleaf type = 1



[client.rgw.ceph-cod1-rgw-n1]

host = ceph-cod1-rgw-n1

keyring = /var/lib/ceph/radosgw/ceph-rgw.ceph-cod1-rgw-n1/keyring

rgw socket path = /var/run/ceph/ceph.radosgw.ceph-cod1-rgw-n1.fastcgi.sock

log file = /var/log/ceph/client.radosgw.ceph-cod1-rgw-n1.log

rgw dns name = ceph-cod1-rgw-n1.**.*****.ru

rgw print continue = false

rgw frontends = «civetweb port=8888»



[client.rgw.ceph-cod2-rgw-n1]

host = ceph-cod2-rgw-n1

keyring = /var/lib/ceph/radosgw/ceph-rgw.ceph-cod2-rgw-n1/keyring

rgw socket path = /var/run/ceph/ceph.radosgw.ceph-cod2-rgw-n1.fastcgi.sock

log file = /var/log/ceph/client.radosgw.ceph-cod2-rgw-n1.log

rgw dns name = ceph-cod2-rgw-n1.**.*****.ru

rgw print continue = false

rgw frontends = «civetweb port=8888»







コメントもいくつかあります。



-ceph-radosgw。*サービスが開始しない場合、ログファイルの作成に問題がありました。 私はこれを、手でファイルを作成し、その上にマスク0666を置くだけで決定しました。

-civetweb、fastcgi、およびapacheの間でクラスターのAPIのプロバイダーを選択できます。これは公式のドックの説明です。

firefly（v0.80）の時点で、Ceph Object Gatewayは、ApacheおよびFastCGIではなくCivetweb（ceph-radosgwデーモンに組み込まれています）で実行されています。 Civetwebを使用すると、Ceph Object Gatewayのインストールと構成が簡単になります。

要するに 、私たちのファイルには、グローバル変数、レプリケーションルール、クラスターの「サバイバル」ルール、およびクラスターに許可されているRGWノードを記述しています。 osdプールのデフォルトのpg numおよびosdプールのデフォルトのpgp numパラメーターについては、興味深いメモが見つかりました。

また、たとえば、合計64個のPGのカウント。 正直なところ、保護グループの計算はまだ完全に私を納得させないものであり、手動で構成することをCeph管理者に任せなければならない理由がわかりません。 とにかく、自動的に構成できない限り、エラーを取り除くために私が見つけた経験則は、CephがOSDごとに20から32 PGを期待しているように見えるということです。 20未満の値ではこのエラーが発生し、32を超える値では別のエラーが発生します。

したがって、私の場合は9つのOSDがあるため、最小値は9 * 20 = 180、最大値は9 * 32 = 288になります。 256を選択し、動的に構成しました。

そしてこれは：

PG（配置グループ）-OSDに複製されるCephのオブジェクトの配置グループまたは論理コレクション。 システムの複雑さのレベルに応じて、1つのグループが複数のOSDにデータを保存できます。 Cephの配置グループの計算式は次のとおりです。



PGの数=（OSDの数* 100）/レプリカの数



この場合、結果は最も近い2の累乗に丸められます（たとえば、丸め= 512の後、式= 700によって）。

PGP（配置目的の配置グループ）-配置目的の配置グループ。 この数は、プレースメントグループの総数と等しくする必要があります。

キーがあるすべてのノードで、権限を変更します：sudo chmod + r /etc/ceph/ceph.client.admin.keyring



OSDデバイスをクラスターに導入する前に、OSDノードで準備作業を実行する必要があります。



ログの下で使用するためにディスクを分割します。 SSDである必要がありますが（必要ではなく、専用ドライブのみ）、4つ以下の等しいパーティションに分割する必要があります。 パーティションはプライマリでなければなりません：



parted /dev/SSD

mkpart journal-1 1 15G

mkpart journal-2 15 30G

mkpart journal-3 31G 45G

mkpart journal-4 45G 60G







そしてxfsでフォーマットします。 マガジン用であり、Cephによって制御されるOSDノード上のディスクの権利を変更します。



chown ceph:ceph /dev/sdb1

chown ceph:ceph /dev/sdb2

chown ceph:ceph /dev/sdb3







そして 、これらのパーティションのGUIDを変更して、 udevが正常に動作し、再起動後に正しいデバイス権限が付与されるようにしてください。 OSDを再起動した後、ノードが起動したが、サービスが失敗した状態のときに、このレーキを踏んだ。 なぜなら 適切に実行されたudevは、デフォルトのルート（ルート所有者とグループ）を割り当てました。 彼らが言うように、結果は期待を超えていました...これが起こらないように、これを行います：



sgdisk -t 1:45B0969E-9B03-4F30-B4C6-B4B80CEFF106 /dev/sdb

GUID







デプロイノードを使用した後、 ceph-deploy disk zapおよびceph-deploy osd createを実行します 。 これにより、クラスターの基本インストールが完了し、コマンドceph -wおよびceph osd treeを使用して、そのステータスを確認できます。



しかし、どうすればデータセンターの復元力を確保できますか？



判明したように、Cephには非常に強力なツールがあります-crushmapでの作業

このマップにはいくつかの抽象化レベルを入力できます。また、単純化してプリミティブにしました。ラックの概念を導入し、データセンターに従って各ラックにノードを配置しました。 その瞬間から、あるラックに記録されたデータが別のラックに必須のレプリカを持つようにデータが再配布されました。 なぜなら Cephアルゴリズムは、同じラックに2つのレプリカを保存することは信頼できないと考えています。 :)これですべてです。1つのデータセンターのすべてのノードをオフにすると、データは実際に使用可能になりました。



[cephadmin@ceph-deploy ceph-cluster]$ ceph osd tree

ID WEIGHT TYPE NAME UP/DOWN REWEIGHT PRIMARY-AFFINITY

-1 1.17200 root default

-8 0.58600 rack ceph-cod1

-2 0.19499 host ceph-cod1-osd-n1

0 0.04900 osd.0 up 1.00000 1.00000

1 0.04900 osd.1 up 1.00000 1.00000

2 0.04900 osd.2 up 1.00000 1.00000

3 0.04900 osd.3 up 1.00000 1.00000

-3 0.19499 host ceph-cod1-osd-n2

4 0.04900 osd.4 up 1.00000 1.00000

5 0.04900 osd.5 up 1.00000 1.00000

6 0.04900 osd.6 up 1.00000 1.00000

7 0.04900 osd.7 up 1.00000 1.00000

-4 0.19499 host ceph-cod1-osd-n3

8 0.04900 osd.8 up 1.00000 1.00000

9 0.04900 osd.9 up 1.00000 1.00000

10 0.04900 osd.10 up 1.00000 1.00000

11 0.04900 osd.11 up 1.00000 1.00000

-9 0.58600 rack ceph-cod2

-5 0.19499 host ceph-cod2-osd-n1

12 0.04900 osd.12 up 1.00000 1.00000

13 0.04900 osd.13 up 1.00000 1.00000

14 0.04900 osd.14 up 1.00000 1.00000

15 0.04900 osd.15 up 1.00000 1.00000

-6 0.19499 host ceph-cod2-osd-n2

16 0.04900 osd.16 up 1.00000 1.00000

17 0.04900 osd.17 up 1.00000 1.00000

18 0.04900 osd.18 up 1.00000 1.00000

19 0.04900 osd.19 up 1.00000 1.00000

-7 0.19499 host ceph-cod2-osd-n3

20 0.04900 osd.20 up 1.00000 1.00000

21 0.04900 osd.21 up 1.00000 1.00000

22 0.04900 osd.22 up 1.00000 1.00000

23 0.04900 osd.23 up 1.00000 1.00000







PS何を言いたいですか？



原則として、Cephは私の期待に応えました。 オブジェクトストアのような。 もちろん、その構成の機能があり、このタイプのストレージのプールの構成は完全に「ブック」ではありません-日付のあるプールがあり、これがメタデータのあるプールであるように。 これについてもう少しお話しましょう。



また、ブロックストレージで遊んでみました。 残念ながら、CephはFCを介してブロックデバイスを「捨てる」方法を知りません。または、その方法を見つけられませんでした。 iSCSIに関しては-私にとってそれは真実で幸せな方法ではありません。 MPIOでも機能しますが。



私にとって最も有用と思われる3つのソース ：

公務員

非公式

チートシート