私たち（ツェフォヴォドフ）の中に、「プロフェッショナルの極端さ」を好まない人はいるでしょうか？
それはありそうにありません。そうでなければ、この非常に興味深く面白い製品を使い回すことはなかったでしょう。
Ceph の運用に携わっている人の多くは、それほど頻繁ではない (というより、非常にまれである) ものの、時々需要があるケース、つまり iSCSI または FC 経由で Ceph を接続することに遭遇したことがあります。 何のために？ たとえば、何らかの理由でまだ仮想化されていない Windows または Solaris サーバーに Ceph からイメージを送信します。 または、仮想化されているが、Ceph を実行できないハイパーバイザーを使用している - ご存知のとおり、それらはたくさんあります。 例えば？ たとえば、HyperV や ESXi が積極的に使用されています。 そして、Ceph からゲスト マシンにイメージを提供するタスクが発生すると、これは非常にエキサイティングなタスクになります。
だから、与えられた：
- すでに実行中の Ceph クラスター
- iSCSI 経由で提供する必要がある既存のイメージ
- プール名 マイプール、画像名 マイイメージ
始める？
まず、FC または iSCSI について話す場合、イニシエーターとターゲットのようなエンティティが存在します。 ターゲットは実際にはサーバーであり、イニシエーターはクライアントです。 私たちのタスクは、最小限の労力で Ceph イメージをイニシエーターに送信することです。 つまり対象を拡大しなければならないということです。 しかし、どこの、どのコンピュータ上で?
幸いなことに、Ceph クラスターには、IP アドレスが固定され、Ceph の最も重要なコンポーネントの XNUMX つが構成されているコンポーネントが少なくとも XNUMX つあり、そのコンポーネントはモニターです。 したがって、モニターに iSCSI ターゲットをインストールします (少なくともテストの場合は同時にイニシエータもインストールします)。 私は CentOS でこれを実行しましたが、このソリューションは他のディストリビューションにも適しています。必要なのは、ディストリビューションで許容される方法でパッケージをインストールすることだけです。
# yum -y install iscsi-initiator-utils targetcli
インストールされるパッケージの目的は何ですか?
- ターゲットクリ — Linux カーネルに組み込まれた SCSI ターゲットを管理するためのユーティリティ
- iscsi-イニシエーター-ユーティリティ — Linux カーネルに組み込まれた iSCSI イニシエーターの管理に使用されるユーティリティを含むパッケージ
iSCSI 経由でイメージをイニシエーターに送信するには、イベントの開発には XNUMX つのオプションがあります。ターゲットのユーザースペース バックエンドを使用するか、イメージをオペレーティング システムから見えるブロック デバイスとして接続し、iSCSI 経由でエクスポートします。 私たちは XNUMX 番目の方法に進みます。ユーザー空間のバックエンドはまだ「実験的」状態にあり、生産的な使用の準備が少し整っていません。 さらに、これには落とし穴があり、それについてたくさん話したり、（恐ろしい！）議論したりすることができます。
サポートサイクルが長く、ある程度安定したディストリビューションであっても、使用しているカーネルは古い、古いバージョンになります。 たとえば、CentOS7 では 3.10.*、CentOS8 では 4.19 です。 そして、少なくとも 5.3 (正確には 5.4) 以上のカーネルに興味があります。 なぜ？ デフォルトでは、Ceph イメージには古いカーネルと互換性のない一連のオプションが有効になっているためです。 これは、リポジトリをディストリビューションの新しいカーネル (たとえば、CentOS の場合は elrepo) に接続し、新しいカーネルをインストールし、新しいカーネルで動作するようにシステムを再起動することを意味します。
- 実験用に選択したモニターに接続します
- 指示に従って elrepo リポジトリを接続します -
- カーネルをインストールします: yum -y —enablerepo=elrepo-kernel install kernel-ml
- モニターを使用してサーバーを再起動します (モニターが XNUMX つありますよね?)
画像をブロックデバイスとして接続する
# rbd map mypool/myimage
/dev/rbd0
残っているのはターゲットを構成することだけです。 この例では、いわゆるターゲットを設定します。 デモ モード - 認証なしで、誰でも表示され、アクセスできます。 実稼働環境では、認証を構成する必要があると思われますが、それは今日の単なる楽しみのための演習では少し範囲外です。
ファイル /dev/rbd/mypool/myimage に関連付けられた、disk1 という名前のバックエンドを作成します。 指定されたファイルは、udev デーモンによって /dev/rbd0 に自動的に作成されるシンボリック リンクです。 Ceph イメージがホストに接続される順序に応じて rbd デバイスの名前が変わる可能性があるため、シンボリック リンクを使用します。
バックエンドを作成します。
# targetcli /backstores/block create disk1 /dev/rbd/mypool/myimage
iSCSI ターゲットを作成します。
# targetcli /iscsi create iqn.2020-01.demo.ceph:mypool
バックエンドを LUN としてターゲットに接続します。
# targetcli /iscsi/iqn.2020-01.demo.ceph:mypool/tpg1/luns create /backstores/block/disk1
デモ モードのターゲットを設定しましょう。
# targetcli /iscsi/iqn.2020-01.demo.ceph:mypool/tpg1/ set
> attribute demo_mode_write_protect=0
# targetcli /iscsi/iqn.2020-01.demo.ceph:mypool/tpg1/ set
> attribute generate_node_acls=1
# targetcli /iscsi/iqn.2020-01.demo.ceph:mypool/tpg1/ set
> attribute cache_dynamic_acls=1
設定を保存します。
# targetcli saveconfig
ターゲットの存在を確認する:
# iscsiadm -m discovery -t st -p 127.0.0.1:3260
127.0.0.1:3260,1 iqn.2020-01.demo.ceph:mypool
ターゲットを接続します。
# iscsiadm -m node --login
Logging in to [iface: default, target: iqn.2020-01.demo.ceph:mypool, portal: 127.0.0.1,3260] (multiple)
Login to [iface: default, target: iqn.2020-01.demo.ceph:mypool, portal: 127.0.0.1,3260] successful.
すべてを正しく実行すると、サーバー上に新しいディスクが表示されます。これは SCSI デバイスのように見えますが、実際には Ceph からのイメージであり、iSCSI ターゲットを介してアクセスされます。 起動の問題を回避するには、接続されているディスクと検出されたターゲットをローカル イニシエータから削除することをお勧めします。
# iscsiadm -m node --logout
# iscsiadm -m discoverydb -o delete -t st -p 127.0.0.1:3260
残っているのは、イメージが自動的に接続され、接続後にターゲットが階層化されるように構成を永続化することだけです。 ターゲットの起動は、RBD の接続と実際のターゲットの起動という XNUMX つのステップで構成されます。
まず、RBD イメージのホストへの自動接続を設定しましょう。 これを行うには、/etc/ceph/rbdmap ファイルに次の行を追加します。
# cat /etc/ceph/rbdmap
# RbdDevice Parameters
mypool/myimage id=admin
# systemctl enable rbdmap
ターゲット構成の復元はもう少し複雑です。構成を復元する systemd のユニットを作成する必要があります。
# cat /usr/lib/systemd/system/scsi-target.service
[Unit]
Description=Start iSCSI target
After=network-online.target rbdmap.service
Before=remote-fs-pre.target
Wants=network-online.target remote-fs-pre.target
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/targetcli restoreconfig
[Install]
WantedBy=multi-user.target
# systemctl daemon-reload
# systemctl enable scsi-target
最後のテストは、モニターを再度再起動することです (モニターは現在 iSCSI ターゲットになっています)。 コマンドを使用してイニシエータのデータベースをクリアしなかった場合は、 iscsiadm -n Discoverydb -o delete ... サーバーが読み込まれなかったり、読み込みに時間がかかったりする可能性があります。
残っているものは何ですか？
ターゲットを送信するサーバー上でイニシエーターを構成します。
ターゲットの耐障害性を確保するにはどうすればよいでしょうか?
他のモニターでも同様にターゲットを構成し、マルチパスを設定できます (vmware はこれを理解して機能しますが、Hyper-V は理解できません。これには SCSI ロックが必要です)。 カーネルの Ceph クライアントはキャッシュを使用しないため、これは非常に有効です。 または、別のオプションは、専用のターゲット IP アドレス、rbdmap および scsi ターゲット サービスという XNUMX つのコンポーネントからなるクラスター リソースを作成し、このリソースをクラスタリング ツール (ペースメーカーなんて言ったのは誰ですか?) を通じて管理することです。
後の言葉の代わりに
明らかなように、この記事は少し冗談です。しかし、その中で私は、いくつかのかなり人気のあるトピックを「例を挙げて簡単に」同時に検討しようとしました - iSCSI ターゲット、これは必ずしも Ceph イメージをエクスポートするとは限りませんが、たとえば、 LVM ボリュームのエクスポート、iSCSI イニシエータの操作の基本 (ターゲットをスキャンする方法、ターゲットに接続する方法、切断する方法、データベースからターゲット エントリを削除する方法)、systemd 用の独自のユニットの作成など
この実験全体を完全に繰り返さなくても、少なくともこの記事の何かが役立つことを願っています。
出所： habr.com