Ceph iSCSI vasitəsilə - ya da xizək sürərək hamakda oturma

Bizim aramızda (ceph istifadəçiləri) «peşəkar ekstremal» sevməyən varmı?

Şübhəsiz ki, yoxdur - əks halda bu son dərəcə maraqlı və əyləncəli məhsul ilə fırlanmazdıq.

Ceph istifadə edən çoxsaylı insanlar nadir rast gəlinən (hətta çox nadir) lakin bəzən tələb olunan bir hadisə ilə qarşılaşıb - Ceph'i iSCSI ya da FC ilə qoşmaq. Niyə? Məsələn, Ceph'dən Windows ya da Solaris virtualizasiya edilməmiş bir serverə image təqdim etmək. Ya da virtualizasiya edilmişdir, ancaq Ceph'i dəstəkləməyən bir hipervizor vasitəsilə - ki, onların sayı kifayət qədərdir. Məsələn? Məsələn, istifadə olunan HyperV və ya ESXi. Və əgər Ceph'dən bir image'i qonaq maşına təqdim etməyi tələb edən bir vəzifə yaranırsa, bu, olduqca maraqlı bir işə çevrilir.

Beləliklə, verilmişdir:

  1. artıq işlək olan Ceph klasteri
  2. artıq mövcud olan bir image, hansı ki, iSCSI vasitəsilə təqdim edilməlidir
  3. Pulun adı mypool, image adı myimage

Başlayıq?

İlk növbədə, FC ya da iSCSI haqqında danışarkən, bizimdə iniciator (initiator) və hedef (target) adlanan varlıqlar yaranır. Target faktiki olaraq serverdir, initiator - müştəri. Bizim vəzifəmiz - ən az iş yükü ilə Ceph image'ini initiator'a təqdim etmək. Deməli, biz target'i açmalıyıq. Amma harada, hansı kompüterdə?

Xoşbəxtlikdən, Ceph klasterində ən azı bir komponent var, onun IP ünvanı sabitdir və burada Ceph'in ən vacib komponentlərindən biri konfiqurasiya olunur, və bu komponent - monitor. Məlumat olaraq, monitor üzərində iSCSI target (və eyni zamanda initiator, ən azı testlər üçün) quraşdırırıq. Bunu CentOS'da etdim, lakin başqa distros üçün bu həll də uyğundur - sadəcə olaraq, sizin distrosu üçün qəbul olunan üsulla paketləri quraşdırmaq kifayətdir.

# yum -y install iscsi-initiator-utils targetcli

Quraşdırılan paketlərin məqsədi nədir?

  • targetcli — Linux nüvəsinin daxilindəki SCSI target'in idarəetmə aləti
  • iscsi-initiator-utils — Linux nüvəsində yenidən quraşdırılan iSCSI initiator ilə idarəetmə üçün istifadə olunan alətlərin paketi

İniciator'a iSCSI vasitəsilə image təqdim etmək üçün iki variant mövcuddur - ya userspace'li target'in backend'indən istifadə etmək ya da image'i əməliyyat sisteminə görünən blok cihazı kimi qoşub, iSCSI ilə ixrac etmək. Biz ikinci yolu seçəcəyik - userspace'li backend hələ ‘eksperimental’ vəziyyətdədir və istehsalat istifadəsi üçün bir az hazır deyil. Həmçinin, onunla bağlı çox danışmaq və (bir dəhşət!) mübahisə etmək üçün çətinliklər var.

Əgər biz uzun müddət dəstəklənən, nisbətən stabilliyi olan bir d distribütordan istifadə ediriksə, o zaman nüvəmiz hansısa çox köhnə versiyadır. Məsələn, CentOS7-də bu 3.10.*, CentOS8-də isə 4.19-dur. Bizim isə ən azı 5.3 (daha tez-tez 5.4) və daha yeni bir nüvə maraqlıdır. Niyə? Çünki, Ceph-dəki imiclər standart olaraq köhnə nüvələrlə uyğun gəlməyən bir sıra seçimlərlə əlaqələndirilmişdir. Buna görə də, bizim distribütorumuz üçün yeni nüvə üçün bir repozitoriya açırıq (məsələn, CentOS üçün bu elrepo-dur), yeni nüvəni quraşdırırıq və yeni nüvə ilə işləmək üçün sistemi yenidən başladırıq:

  • Seçim üçün test monitoruna qoşuluruq
  • İnstruksiyaya uyğun olaraq elrepo repozitoriyalarını açırıq — elrepo.org/tiki/tiki-index.php
  • Nüvəni quraşdırırıq: yum -y --enablerepo=elrepo-kernel install kernel-ml
  • Monitor ilə serveri yenidən başladırıq (bizi üç monitor var, elə deyilmi?)

İmici blok qurğu kimi qoşuruq

# rbd xəritəsi mypool/myimage
/dev/rbd0

İndi tək qalan şey tənzimləməkdir. Bu misalda mən, görünən və hamıya açıq olan demo rejimində tənzimləyəcəyəm. İstehsal mühitində çox güman ki, autentifikasiya tənzimləmək istəyəcəksiniz — amma bu, bu gün sadəcə əyləncə üçün olan məşqimizin sahəsindən biraz kənardadır.

disk1 adında bir backend yaradılır, bu, /dev/rbd/mypool/myimage faylına uyğun gəlir. Göstərilən fayl, udev demonuna tərəfindən avtomatik yaradılsa da, /dev/rbd0-a simvolik bağlantıdır. Biz simvolik bağlantını istifadə edirik, çünki rbd cihazının adı Ceph imiclərinin hosta qoşulma sırasına görə dəyişə bilər.

Backend yaradırıq:

# targetcli /backstores/block create disk1 /dev/rbd/mypool/myimage

iSCSI hədəfi yaradırıq:

# targetcli /iscsi create iqn.2020-01.demo.ceph:mypool

Backend'i LUN olaraq hədəfə qoşuruq:

# targetcli /iscsi/iqn.2020-01.demo.ceph:mypool/tpg1/luns create /backstores/block/disk1

Demo rejimi üçün hədəfi tamamlayırıq:

# 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

Konfiqurasiyanı saxlayırıq:

# targetcli saveconfig

Hədəfin mövcudluğunu yoxlayırıq:

# iscsiadm -m discovery -t st -p 127.0.0.1:3260
127.0.0.1:3260,1 iqn.2020-01.demo.ceph:mypool

Hədəfi qoşuruq:

# iscsiadm -m node --login
[iface: default, target: iqn.2020-01.demo.ceph:mypool, portal: 127.0.0.1,3260] (çoxlu) daxil olunur
[iface: default, target: iqn.2020-01.demo.ceph:mypool, portal: 127.0.0.1,3260] giriş uğurludur.

Əgər hər şeyi düzgün etmisinizsə, serverdə bir SCSI qurğu kimi görünən yeni bir disk olacaq, amma əslində bu, Ceph-dən bir imicdir ki, iSCSI hədəfi vasitəsilə əlçatandır. Yük zamanı problemlərin qarşısını almaq üçün qoşulmuş diski və aşkar olunmuş hədəfi yerli initiatordan silmək daha yaxşıdır:

# iscsiadm -m node --logout
# iscsiadm -m discoverydb -o delete -t st -p 127.0.0.1:3260

Hələ də qalan iş - konfiqurasiyanı davamlı etməkdir ki, imic avtomatik qoşulsun və hədəf başladıldıqda başlamalıdır. Hədəfin başladılması iki addımdan ibarətdir - RBD-nin qoşulması və hədəfin özünün başladılması.

Öncə RBD imiclərini hosta avtomatik qoşulmağı konfiqurasiya edək. Bu, /etc/ceph/rbdmap faylına sətirləri əlavə etməklə edilir:

# pişik /etc/ceph/rbdmap
# RbdDevice Parameters
mypool/myimage id=admin
# systemctl aktivləşdir rbdmap

Hədəf konfiqurasiyası bərpası isə bir az çətindir - biz systemd üçün bir unit yazmalıyıq ki, konfiqurasiyanı bərpa etsin:

# cat /usr/lib/systemd/system/scsi-target.service
[Unit]
Təsvir=iSCSI hədəfini işə sal

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

Son test - monitorumuzu (artıq iSCSI hədəfi) bir daha yenidən başladırıq. Qeyd edə bilərik ki, əgər biz initiator bazasını iscsiadm -n discoverydb -o delete ... komandası ilə silməmiş olsaydıq, ... beləliklə, yüklənməyən və ya uzun müddət yüklənən bir server ala bilərdiniz.

Nə qaldı?

Hədəfi yerləşdirmək istədiyimiz serverdə initiatoru konfiqurasiya etmək.

Hədəfimizin etibarlılığını necə təmin edə bilərik?

Hədəfləri digər monitorlarda da eyni şəkildə konfiqurasiya etmək və multipath düzəltmək olar (vmware bunu başa düşəcək və hətta işləyəcək, Hyper-V başa düşməyəcək - orada SCSI kilidləri tələb olunur). Ceph müştərisi nüvədən önbellek istifadə etmədiyi üçün bu tamamilə işləkdir. Yaxşı bir alternativ - üç komponentdən ibarət bir klaster resursu yaratmaq - ayrılmış IP ünvanlarını hədəf və rbdmap və scsi-target xidmətləri, bu resursu klasterləşdirmə alətləri ilə idarə etmək (kim pacemaker demişdi?)

Son söz əvəzinə

Aydındır ki, bu məqalə bir az zarafatdır - amma burada "tez və nümunələrlə" bir neçə olduqca populyar mövzunu eyni anda nəzərdən keçirməyə çalışdım - iSCSI hədəfi, Ceph şəkillərini mütləq idxal etməməlidir - lakin məsələn, LVM həcmələrini idxal etmək, iSCSI initiatorunun işlənməsi (hədəfi necə skan etmək, hədəfə qoşulmaq, ayrılmaq, hədəf haqqında bazadan yazını silmək), systemd üçün öz unit-in yazılması və bəzi digər mövzular.

Ümid edirəm ki, bu eksperimentin tam olaraq təkrarlamayacaqsınızsa da, bu məqalədən ən azı bir şey sizin üçün faydalı olacaq.

Mənbə: habr.com

DDoS qoruması olan saytlara etibarlı hosting satın alın, VPS VDS serverlər 🔥 DDoS qoruması olan saytlara etibarlı hosting satın alın, VPS VDS serverlər | ProHoster