Există printre noi (cei care folosesc Ceph) cineva care nu iubește „extremul profesional”?
E puțin probabil — altfel nu ne-am juca cu acest produs extrem de interesant și captivant.
Mulți dintre cei care au lucrat cu Ceph s-au întâlnit cu un caz mai puțin frecvent (sau mai degrabă extrem de rar), dar uneori solicitat — să conecteze Ceph prin iSCSI sau FC. De ce? De exemplu, pentru a livra o imagine de pe Ceph pe un server Windows sau Solaris care, din diverse motive, nu este virtualizat. Sau pe unul virtualizat, dar printr-un hypervisor care nu suportă Ceph — iar acestea, așa cum știm, sunt destule. De exemplu? Ei bine, de exemplu HyperV sau ESXi, care sunt folosite activ. Și dacă apare sarcina de a livra o imagine de pe Ceph pe o mașină gazdă, aceasta devine o sarcină foarte captivantă.
Așadar, avem:
- un cluster Ceph deja funcțional
- o imagine existentă pe care trebuie să o livrăm prin iSCSI
- Numele pool-ului mypool, numele imaginii myimage
Începem?
În primul rând, când vorbim despre FC sau iSCSI, ne apar entități precum initiator și target. Target-ul este de fapt serverul, initiator-ul — clientul. Sarcina noastră este să livrăm imaginea Ceph initiator-ului cu un minim de eforturi. Asta înseamnă că trebuie să configurăm target-ul. Dar unde, pe ce computer?
Din fericire, în clusterul Ceph avem cel puțin un component, al cărui IP este fixat și pe care este configurat unul dintre cele mai importante componente Ceph, iar acest component este monitorul. Prin urmare, pe monitor instalăm target-ul iSCSI (și initiator-ul de asemenea, cel puțin pentru teste). Am făcut asta pe CentOS, dar pentru orice altă distribuție soluția se potrivește de asemenea — este suficient să instalați pachetele în modul care este acceptabil pentru distribuția dumneavoastră.
# yum -y install iscsi-initiator-utils targetcli
Care este scopul pachetelor instalate?
- targetcli — utilitar pentru gestionarea target-ului SCSI integrat în nucleul Linux
- iscsi-initiator-utils — pachet cu utilitare utilizate pentru gestionarea, din nou, a initiator-ului iSCSI integrat în nucleul Linux
Pentru a trimite o imagine prin iSCSI către inițiator, există două opțiuni - fie să folosim un backend de tip userspace pentru target, fie să conectăm imaginea ca un dispozitiv bloc vizibil pentru sistemul de operare și să o exportăm prin iSCSI. Vom alege a doua variantă - backend-ul de tip userspace se află încă în stadiul „experimental” și nu este complet pregătit pentru utilizare produsivă. În plus, există capcane de care putem discuta mult și (oh, groază!) chiar să ne contrazicem.
Dacă folosim o distribuție stabilă cu un ciclu lung de suport, atunci nucleul va fi o versiune foarte veche. De exemplu, în CentOS7 este 3.10.*, iar în CentOS8 este 4.19. Și ne interesează un nucleu de cel puțin 5.3 (sau chiar 5.4) și mai nou. De ce? Pentru că, în mod implicit, imaginile din Ceph au un set de opțiuni activat, care nu este compatibil cu nucleele vechi. Asta înseamnă că trebuie să adăugăm un repository cu un nucleu nou pentru distribuția noastră (de exemplu, pentru CentOS este elrepo), să instalăm nucleul nou și să repornim sistemul pentru a lucra cu acesta:
- Ne conectăm la monitorul ales pentru experiment
- Adăugăm repository-urile elrepo conform instrucțiunilor —
- Instalăm nucleul: yum -y —enablerepo=elrepo-kernel install kernel-ml
- Repornim serverul cu monitorul (avem trei monitoare, nu-i așa?)
Conectăm imaginea ca dispozitiv bloc
# harta rbd mypool/myimage
/dev/rbd0
Rămâne doar să configurăm target-ul. În acest exemplu, voi configura target-ul în așa-numitul mod demo — fără autentificare, vizibil și accesibil pentru toți. Într-un mediu de producție, probabil că veți dori să configurați autentificarea — dar aceasta este puțin în afara subiectului exercițiului de astăzi, doar pentru distracție.
Creăm un backend denumit disk1, asociat cu fișierul /dev/rbd/mypool/myimage. Fișierul specificat este un link simbolic creat automat de demonul udev pentru /dev/rbd0. Folosim acest link simbolic deoarece numele dispozitivului rbd se poate schimba din cauza ordinii în care imaginile Ceph sunt conectate la host.
Creăm backend-ul:
# targetcli /backstores/block create disk1 /dev/rbd/mypool/myimage
Creăm target-ul iSCSI:
# targetcli /iscsi crea iqn.2020-01.demo.ceph:mypool
Conectăm backend-ul ca LUN la target:
# targetcli /iscsi/iqn.2020-01.demo.ceph:mypool/tpg1/luns create /backstores/block/disk1
Finalizăm configurarea target-ului pentru modul demo:
# targetcli /iscsi/iqn.2020-01.demo.ceph:mypool/tpg1/set
> atribut demo_mode_write_protect=0
# targetcli /iscsi/iqn.2020-01.demo.ceph:mypool/tpg1/set
> atribut generate_node_acls=1
# targetcli /iscsi/iqn.2020-01.demo.ceph:mypool/tpg1/set
> atribut cache_dynamic_acls=1
Salvăm configurația:
# targetcli saveconfig
Verificăm existența target-ului:
# iscsiadm -m discovery -t st -p 127.0.0.1:3260
127.0.0.1:3260,1 iqn.2020-01.demo.ceph:mypool
Conectăm target-ul:
# iscsiadm -m node --login
Conectarea la [iface: default, target: iqn.2020-01.demo.ceph:mypool, portal: 127.0.0.1,3260] (multiple)
Conectare la [iface: default, target: iqn.2020-01.demo.ceph:mypool, portal: 127.0.0.1,3260] reușită.
Dacă ați făcut totul corect, pe server va apărea un nou disc, care arată ca un dispozitiv SCSI, dar de fapt este o imagine din Ceph, accesibilă printr-un țintă iSCSI. Pentru a evita problemele la pornire, este mai bine să eliminați discul conectat și ținta detectată de la inițiatorul local:
# iscsiadm -m node --logout
# iscsiadm -m discoverydb -o delete -t st -p 127.0.0.1:3260
Tot ce a mai rămas este să persistați configurația, astfel încât imaginea să se conecteze automat și după conectare să pornească ținta. Pornirea țintei constă în două etape - conectarea RBD și efectiv pornirea țintei.
Mai întâi să configurăm conectarea automată a imaginilor RBD la gazdă. Acest lucru se face prin adăugarea de linii în fișierul /etc/ceph/rbdmap:
# cat /etc/ceph/rbdmap
# RbdDevice Parameters
mypool/myimage id=admin
# systemctl enable rbdmap
Cu restabilirea configurației țintei este puțin mai complicat - trebuie să scriem un unit pentru systemd, care va restabili configurația:
# 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
Testul final - să repornim din nou monitorul nostru (care acum este iSCSI-target). Trebuie remarcat că, dacă nu am curățat baza inițiatorului cu comanda iscsiadm -n discoverydb -o delete … am fi putut obține un server care nu pornește sau care se încarcă greu.
Ce a mai rămas?
Să configurăm initiatorul pe serverul pe care dorim să oferim ținta.
Cum să asigurăm redundanța țintei noastre?
Putem să configurăm similar țintele pe alte monitoare și să organizăm multipath (vmware va înțelege asta și va funcționa, Hyper-V nu va înțelege - acolo sunt necesare blocări SCSI). Deoarece clientul Ceph din kernel nu folosește caching, aceasta este o soluție viabilă. Sau o altă variantă - să creăm un resursă de cluster din trei componente - o țintă dedicată și serviciile rbdmap și scsi-target, și să gestionăm această resursă prin instrumente de clustering (cine a spus pacemaker?) adrese IP Cum se poate observa, acest articol este puțin o glumă - dar în el am încercat să abordez simultan câteva teme destul de populare - ținta iSCSI, care nu trebuie neapărat să exporte imagini Ceph - ci, de exemplu, să exporte volume LVM, bazele folosirii inițiatorului iSCSI (cum să scanați ținta, cum să vă conectați la țintă, să deconectați, să ștergeți înregistrarea despre țintă din bază), scrierea propriului unita pentru systemd și alte câteva.
În loc de postfață
După cum este evident, acest articol este puțin umoristic — dar în el am încercat să discut simultan mai multe subiecte destul de populare — ținta iSCSI, care nu este neapărat obligată să exporțeze imagini Ceph — ci, de exemplu, să exporțeze volume LVM, bazele utilizării inițiatorului iSCSI (cum să scanezi ținta, cum să te conectezi la țintă, să te deconectezi, să ștergi înregistrarea țintei din bază), scrierea propriului unit pentru systemd și câteva altele.
Sper că, chiar dacă nu veți repeta întreaga experientă, măcar ceva din acest articol să vă fie util.
Sursa: habr.com
