VMWare上のCeph Storage Clusterを10分で

このマニュアルは、家庭用PCの仮想環境で分散Cephファイルストレージの柔軟性と利便性を試したい人向けに書かれています。 10分がクラスター自体をデプロイする時間であるとすぐに説明します（仮想マシンでのCephのインストールと構成）。 ただし、仮想マシンの作成とクローン作成、OSのインストールには時間がかかります。

記事の終わりまでに、3台のコンピューターの仮想クラスターと、ストレージクライアントとしてのWindows PCが完成します。 次に、猫の写真をそこにドロップし、1つのメモをドロップしてから、それを拾い上げ、もう1つをドロップし、猫の写真をダウンロードして戻します。

Cephのテーマに他に誰もいない場合は、紹介記事「 Introducing Ceph in pictures 」を読み、メーカーのファッショナブルなプロモーションを見てください。

私の立場はこんな感じでした：

PC設定
CPU：i5-6500
メモリ：16 GB（ただし、理論上は8 GBで十分です）
ディスク：100 GBの空き容量がある通常の家庭用HDD
OS：Windows 7 x64

仮想マシンの設定（3つすべてが同じです）
CPU：1コア
メモリー：1024 MB
サブネット：192.168.1.0/24
ディスク：各10 GBの4つの仮想ディスク（OS用に1つ、ストレージ用に3つ）
OS：Ubuntu Server 16.04.2 x64

実験の目的は可能性を試して、さらなる儀式のためのプラットフォームを作成することであることを思い出したいと思います。 ただし、9台の仮想ディスク（システムディスクは考慮していません）が同じ物理ディスク上にあるという事実を考慮すると、このシステムに許容可能なパフォーマンスは期待できません。 パフォーマンスは非常に低くなりますが、テストには十分です。

計画

-cn1仮想マシン（ceph-node-1）を作成します
-OSのインストール、構成
-2つのクローン（cn2とcn3）を作成し、IPアドレスを変更します
-Cephクラスターを上げる
-いずれかのマシンでiSCSIターゲットを構成します
-Windowsをクライアントとして接続する
-ファイルのアップロード/ダウンロード/削除、ノードのドロップを試みます

仮想マシンを作成する

仮想マシンのパラメーターは上記のとおりです。 ストレージ用に、事前に割り当てられた非分割ディスクを作成しました。 VMWareサブネットは、DHCPでNATを取ることができます。 将来的には、これを取得する必要があります。

192.168.1.11-cn1（iSCSIターゲットもあります）
192.168.1.12-cn2
192.168.1.13-cn3
192.168.1.1-クライアント（iSCSI-initiator）

ゲートウェイ/マスク：192.168.1.2 / 255.255.255.0

OSのインストールとセットアップ

このマニュアルはUbuntu Server 16.04.2で動作するはずです。他のバージョンまたはディストリビューションでは、一部の設定が異なります。

単純なパスワードを使用して、ルートからすべての設定を行います。 そして、ここで私は間違いなく指を振る必要があり、セキュリティ上の理由から、戦闘クラスターでこれを行わない方が良いと言及しなければなりません。

OSをインストールします。


OSがインストールされたので、OSを起動して、発行されたアドレスを確認します。

ip -4 addr | grep inet 

192.168.1.128を得ました。 SSH経由で接続します。 ルートのパスワードを設定します。

 sudo su passwd root 

ネットワークインターフェイスを構成します（IPが変更されたため、この時点でSSHからスローされます）。

 cd /etc/network cp interfaces interfaces.BAK IFACE=ens32 ADDR=192.168.1.11 MASK=255.255.255.0 GW=192.168.1.2 sed -i "s/iface $IFACE inet dhcp/iface $IFACE inet static\naddress $ADDR\nnetmask $MASK\ngateway $GW\ndns-nameservers $GW/g" interfaces ip addr flush to 192.168.1.0/24 && ip addr add $ADDR/24 dev $IFACE 

新しいアドレス（192.168.1.11）に接続され、ルートを使用してマシンに接続できます。

 su cd /etc/ssh/ cp sshd_config sshd_config.BAK sed -i "s/PermitRootLogin.*/PermitRootLogin yes/g" sshd_config 

近隣のホスト名とホスト名を設定します。

 HOSTNAME=cn1 echo $HOSTNAME > /etc/hostname sed -i "s/127.0.1.1.*/127.0.1.1\t$HOSTNAME/g" /etc/hosts echo " # Ceph-nodes 192.168.1.11 cn1 192.168.1.12 cn2 192.168.1.13 cn3" >> /etc/hosts 

アドレスを変更した後、デフォルトルートが必要になる場合があります。これがないと、必要なパッケージを配信できません。 パッケージのうち、ntpをインストールして、すべてのノードの時刻を同期する必要があります。 htopでは、Cephデーモンとそのフローを目で見ると便利です。

 ip route add default via 192.168.1.2 dev ens32 apt update apt install mc htop ntp -y 

すべての準備が整い、最初のマシンが軸、必要なパッケージと設定を受け取りました。これらはクローンが継承します。 車の電源を切る：

 shutdown -h now 

クローンを作成し、ネットワークを設定します

この時点で、マシンのスナップショットを作成し、このスナップショットを示す2つの完全なクローンを作成します。 これが、cn2およびcn3マシンの誕生の様子です。 クローンはcn1ノードの設定を完全に継承しているため、同じIPアドレスを持つ3台のマシンがあります。 したがって、逆の順序で順番にオンにし、同時にIPアドレスを正しいものに変更します。

cn3をオンにする
マシンを起動し、SSH経由で192.168.1.11にルートで接続し、インターフェース設定を192.168.1.13に変更します。その後、古いアドレスでのSSHセッションは終了します。

 HOST_ID=3 echo cn$HOST_ID > /etc/hostname sed -i "s/127.0.1.1.*/127.0.1.1\tcn$HOST_ID/g" /etc/hosts sed -i "s/address.*/address 192.168.1.1$HOST_ID/g" /etc/network/interfaces ip addr flush to 192.168.1.0/24 && ip addr add 192.168.1.1$HOST_ID/24 dev ens32 

cn2をオンにする
cn3では、アドレスは既に正しいアドレスです。cn2では、まだ192.168.1.11があり、それに接続して、アドレス192.168.1.12に対して同じセットアップを行います。

 HOST_ID=2 echo cn$HOST_ID > /etc/hostname sed -i "s/127.0.1.1.*/127.0.1.1\tcn$HOST_ID/g" /etc/hosts sed -i "s/address.*/address 192.168.1.1$HOST_ID/g" /etc/network/interfaces ip addr flush to 192.168.1.0/24 && ip addr add 192.168.1.1$HOST_ID/24 dev ens32 

競合するアドレスが残っておらず、cn2とのセッションが終了したため、
cn1をオンにします。

192.168.1.11に接続し、これからこのノードですべての作業を行います（残りのノードの管理を含む）。 これを行うために、SSHキーを生成し、それらをすべてのノードに分解します（これは私の気まぐれではありません、Cephはこれを求めています）。 その過程で、パスワードを入力し、彼の質問にうなずく必要があります。

 #   cn1    ,     ssh-keygen #   cn1    for node_id in 1 2 3; do ssh-copy-id cn$node_id; done #   cn1  cn2,  ,   cn2    ssh cn2 ssh-keygen for node_id in 1 2 3; do ssh-copy-id cn$node_id; done exit #   cn1 #   cn3 ssh cn3 #   cn1  cn3,  ,   cn3    ssh-keygen for node_id in 1 2 3; do ssh-copy-id cn$node_id; done exit #   cn1 

したがって、クラスターサブネットを、記事の冒頭で説明した状態にしました。 すべてのノードは、パスワードなしで近隣のルートアクセス権を持っています*指で脅します*

クラスターはまだクラスターではありませんが、いわばクラスタリングの準備ができています。 ただし、リボルバーで空を撮影し、ストップウォッチで10分間の測定を開始する前に、車の電源を切り、「ready_for_ceph」という名前のスナップショットを作成することを強くお勧めします。私たちの儀式中に間違っていました。

Cephクラスターを上げる

10分が過ぎました...

すべてのマシンを起動し、SSH経由でcn1に接続します。 まず、すべてのノードにceph-deployをインストールします。これは、いくつかのクラスターコンポーネントのインストールと構成を簡素化するように設計されています。 次に、クラスターを作成し、すべてのノードにCephディストリビューションをインストールし、クラスターに3つのモニターを追加します（モニターを1つ持つこともできますが、モニターのクラッシュはクラスター全体のクラッシュと同じになります）。ストレージをディスクで満たします。

 #  ceph-deploy   : for node_id in 1 2 3; do ssh cn$node_id apt install ceph-deploy -y; done #     Ceph: mkdir /etc/ceph cd /etc/ceph #   : ceph-deploy new cn1 cn2 cn3 #   Ceph  : ceph-deploy install cn1 cn2 cn3 #  ,    : ceph-deploy mon create-initial #   Ubuntu  systemd #    -     , #     systemd : for node_id in 1 2 3; do ssh cn$node_id systemctl enable ceph-mon; done #        : ceph-deploy disk zap {cn1,cn2,cn3}:{sdb,sdc,sdd} #     : # ceph-deploy disk zap cn1:sdb cn1:sdc cn1:sdd cn2:sdb cn2:sdc cn2:sdd cn3:sdb cn3:sdc cn3:sdd #    OSD    : ceph-deploy osd create {cn1,cn2,cn3}:{sdb,sdc,sdd} 

クラスターの準備がほぼ整いました。ceph-sまたはceph statusコマンドでステータスを確認してください。

 root@cn1:/etc/ceph# ceph -s cluster 0cb14335-e366-48df-b361-3c97550d6ef4 health HEALTH_WARN too few PGs per OSD (21 < min 30) monmap e1: 3 mons at {cn1=192.168.1.11:6789/0,cn2=192.168.1.12:6789/0,cn3=192.168.1.13:6789/0} election epoch 6, quorum 0,1,2 cn1,cn2,cn3 osdmap e43: 9 osds: 9 up, 9 in flags sortbitwise,require_jewel_osds pgmap v107: 64 pgs, 1 pools, 0 bytes data, 0 objects 308 MB used, 45672 MB / 45980 MB avail 64 active+clean 

このレポートの重要な行は正常性であり、HEALTH_WARN状態にあります。 これはHEALTH_ERRよりも優れています。これは、それほどではありませんが、少なくともクラスターが機能するためです。 そして、HEALTH_WARNのすぐ下に、なぜ_WARNであるかが書かれています。つまり、「OSDあたりのPGが少なすぎます（21 <分30）」。OSDあたり最小21 PGになるように配置グループの数を増やす必要があることを示しています。 次に、9 OSDに21を掛けて189を取得し、次に最も近い2のべき乗に切り上げて256を取得します。PGの現在の数は64であり、pgmap行にはっきりと表示されます。 これはすべて、 Cephのドキュメントで説明されています 。

この場合、クラスターの要件を満たし、これを行います。

 PG_NUM=256 ceph osd pool set rbd pg_num $PG_NUM ceph osd pool set rbd pgp_num $PG_NUM 

システムに数秒を与えてマップを再構築し、クラスターのステータスを再度確認します。

 root@cn1:/etc/ceph# ceph -s cluster 0cb14335-e366-48df-b361-3c97550d6ef4 health HEALTH_OK monmap e1: 3 mons at {cn1=192.168.1.11:6789/0,cn2=192.168.1.12:6789/0,cn3=192.168.1.13:6789/0} election epoch 6, quorum 0,1,2 cn1,cn2,cn3 osdmap e50: 9 osds: 9 up, 9 in flags sortbitwise,require_jewel_osds pgmap v151: 256 pgs, 1 pools, 0 bytes data, 0 objects 319 MB used, 45661 MB / 45980 MB avail 256 active+clean 

大切なHEALTH_OKが表示されます。これは、クラスターが正常で動作する準備ができていることを示しています。

デフォルトでは、プール複製係数は3です（変数のサイズとmin_sizeについては、 入門記事で確認できます）。 これは、各オブジェクトが異なるディスクに3つずつ保存されることを意味します。 私たちの目で見てみましょう：

 root@cn1:/etc/ceph# ceph osd pool get rbd size size: 3 root@cn1:/etc/ceph# ceph osd pool get rbd min_size min_size: 2 

ここで、サイズを2に、min_sizeを1に減らします（実稼働環境ではこれを行わないことを強くお勧めします！しかし、仮想スタンド内では、これにより生産性が向上します）

 ceph osd pool set rbd size 2 ceph osd pool set rbd min_size 1 

次は？ 次に、作業中のクラスターを試す必要があります。

3つのよく知られた方法（ブロックデバイス、ファイルシステム、およびオブジェクトストレージ）のいずれかで、クラスターとファイル共有操作を実行できます。 箱から出してすぐに、Windows 7は従来のiSCSIを好むため、この方法はブロックデバイスです。 この場合、ノードにiSCSIターゲットをインストールする必要があります（cn1にします）。

iSCSIターゲットのインストールと構成

単純なターゲットではなく、RBD（Rados Block Device）のサポートが必要です。 tgt-rbdパッケージは機能するため、cn1にインストールします。

 apt install tgt-rbd -y #    rbd: tgtadm --lld iscsi --mode system --op show | grep rbd rbd (bsoflags sync:direct) # ,   

Cephはデフォルトでブロックデバイス用のrbdプールを作成します。その中にrbdイメージを作成します。

 rbd create -p rbd rbd1 --size 4096 --name client.admin --image-feature layering #  rbd -  , rbd1 -  , 4096 -    

次に、ターゲットに任意のIPアドレスのイメージrbd1を提供するように依頼し、これを構成に書き込みます。

 echo '<target virtual-ceph:iscsi> driver iscsi bs-type rbd backing-store rbd/rbd1 # Format: <pool_name>/<rbd_image_name> initiator-address ALL </target>' > /etc/tgt/conf.d/ceph.conf #   : systemctl restart tgt 

ストップウォッチを見ます：8分。 彼らはそれをやった。

iSCSIを介したWindows PCの接続

Windowsには組み込みユーティリティiscsicpl.exeが搭載されており、rbd1イメージをローカルディスクとしてマウントできます。 起動し、[オブジェクトの終了]タブに移動します。 「オブジェクト」フィールドにcn1ノードのIPアドレス（192.168.1.11）を入力し、「クイック接続」をクリックします。 すべてを正しく構成すると、iSCSIターゲットがリストに表示されます。 それを選択して接続します。



その後、未割り当てのディスクがシステムに表示されます。 diskmgmt.mscディスク管理コンソールに、新しい4ギガデバイスが表示されます。 その上にパーティションを作成し、Cephとしてマークしてフォーマットする必要があります。



これで、私のコンピューターにアクセスして結果を喜ぶことができます。

テスト

猫の写真でクラスタを埋めるときです。 猫の写真として、手元にあるさまざまなバージョンのubuntaの分布の4つの画像を使用します。合計ボリュームは2.8ギガバイトです。

それらを新しいローカルディスクにアップロードしようとします。 ただし、ファイルが迅速にアップロードされることに最初に誤って気付くかもしれませんが、これは単にバッファを埋めているだけで、そこからクラスタの物理ディスクにデータが徐々に書き込まれます。 私の場合、700から800メガバイトの最初の3つのファイルがそれぞれすぐに飛び去り、最後のファイルが落ち込んで、速度が予想したものに落ちました。

クラスターノードでceph -wコマンドを実行すると、クラスターの状態をリアルタイムで監視できます。 データ、ブレードダンプ、ノード、またはモニターの読み取り/書き込み。これらはすべてこのログにリアルタイムで表示されます。

ノードを順番にドロップおよびレイズできます。主なことは、cn1をドロップしないことです（マルチパスを使用しないiSCSIターゲットのみがあるため）。一度に2つのノードをドロップしません。 ただし、サイズを3に戻す場合、これで十分です。

破壊行為の時が来ました。VMWareの停止ボタンを押してcn3ノードをドロップし、cn1のceph -wを確認してください。 最初に、一部のOSDが長時間応答しないことをクラスターが心配する様子を確認します。

 osd.6 192.168.1.13:6800/6812 failed (2 reporters from different host after 21.000229 >= grace 20.000000) osd.7 192.168.1.13:6804/7724 failed (2 reporters from different host after 21.000356 >= grace 20.000000) osd.8 192.168.1.13:6808/8766 failed (2 reporters from different host after 21.000715 >= grace 20.000000) osdmap e53: 9 osds: 6 up, 9 in 

5分間、クラスターは、ディスクが心を変えて戻ってくるという希望の状態のままになります。 しかし、5分後（これがデフォルト値です）、クラスターは損失に耐えて、死んだOSDからのデータのバランスを取り直し、他のディスク上の失われたオブジェクトを塗りつぶし、以前に応答しないOSDを古いものとしてマークし、配置グループマップを修正します：

 osd.6 out (down for 300.042041) osd.7 out (down for 300.042041) osd.8 out (down for 300.042041) 

リバランスが完了するまで、cef -sはステータスHEALTH_WARNを表示しますが、ファイルは使用可能になりますが、パフォーマンスが低下するわけではありません。はい。 HEALTH_WARNの理由により、次のように記述されます。

 health HEALTH_WARN 102 pgs degraded 102 pgs stuck unclean recovery 677/1420 objects degraded (47.676%) 1 mons down, quorum 0,1 cn1,cn2 

私なしで続けてください。