Ceph միջոցով iSCSI - կամ դահուկներ, երբ կանգնած է ցանցաճոճ

Կա՞ն մեր մեջ (ցեֆովոդով), ովքեր չեն սիրում «պրոֆեսիոնալ էքստրիմը»։

Քիչ հավանական է, հակառակ դեպքում մենք չէինք շրջվի այս չափազանց հետաքրքիր և զվարճալի արտադրանքով:

Նրանցից շատերը, ովքեր ներգրավված են եղել Ceph-ի շահագործման մեջ, հանդիպել են ոչ շատ հաճախակի (ավելի ճիշտ, նույնիսկ շատ հազվադեպ), բայց երբեմն պահանջարկ ունեցող դեպքի` Ceph-ին միացնելը iSCSI-ի կամ FC-ի միջոցով: Ինչի համար? Դե, օրինակ, ներկայացրեք պատկերը Ceph-ից Windows կամ Solaris սերվերին, որը դեռևս չի վիրտուալացվել ինչ-ինչ պատճառներով: Կամ վիրտուալացված, բայց օգտագործելով հիպերվիզոր, որը չի կարող անել Ceph-ը, և, ինչպես գիտենք, դրանք շատ են: Օրինակ? Դե, օրինակ, HyperV կամ ESXi, որոնք ակտիվորեն օգտագործվում են: Եվ եթե առաջադրանք է առաջանում Ceph-ից պատկերը հյուրի մեքենային մատուցելը, դա վերածվում է շատ հետաքրքիր առաջադրանքի:

Այսպիսով, հաշվի առնելով.

1. արդեն գործող Ceph կլաստերը
2. արդեն գոյություն ունեցող պատկեր, որը պետք է սպասարկվի iSCSI-ի միջոցով
3. Լողավազանի անվանումը mypool, պատկերի անվանումը իմ պատկեր

Սկսե՞լ

Առաջին հերթին, երբ մենք խոսում ենք FC-ի կամ iSCSI-ի մասին, մենք ունենք այնպիսի սուբյեկտներ, ինչպիսիք են նախաձեռնողը և թիրախը: Թիրախը իրականում սերվեր է, նախաձեռնողը հաճախորդ է: Մեր խնդիրն է նվազագույն ջանքերով Ceph-ի կերպարը ներկայացնել նախաձեռնողին: Սա նշանակում է, որ մենք պետք է ընդլայնենք թիրախը։ Բայց որտե՞ղ, ի՞նչ համակարգչի վրա:

Բարեբախտաբար, Ceph կլաստերում մենք ունենք առնվազն մեկ բաղադրիչ, որի IP հասցեն ամրագրված է և որի վրա կազմաձևված է Ceph-ի ամենակարևոր բաղադրիչներից մեկը, և այդ բաղադրիչը մոնիտորն է: Համապատասխանաբար, մենք տեղադրում ենք iSCSI թիրախ մոնիտորի վրա (և միաժամանակ նախաձեռնող, գոնե թեստերի համար): Ես դա արեցի CentOS-ում, բայց լուծումը հարմար է նաև ցանկացած այլ բաշխման համար. պարզապես անհրաժեշտ է փաթեթները տեղադրել այնպես, ինչպես ընդունելի է ձեր բաշխման մեջ:

# yum -y install iscsi-initiator-utils targetcli

Ո՞րն է տեղադրված փաթեթների նպատակը:

• targetcli — Linux միջուկում ներկառուցված SCSI թիրախը կառավարելու օգտակար ծրագիր
• iscsi-initiator-utils — փաթեթ՝ կոմունալ ծառայություններով, որոնք օգտագործվում են Linux միջուկում ներկառուցված iSCSI նախաձեռնիչը կառավարելու համար

Պատկերը iSCSI-ի միջոցով նախաձեռնողին ներկայացնելու համար կա իրադարձությունների զարգացման երկու տարբերակ՝ օգտագործեք թիրախի օգտագործողների տարածքը կամ միացրեք պատկերը որպես օպերացիոն համակարգին տեսանելի բլոկային սարք և արտահանեք այն iSCSI-ի միջոցով: Մենք կգնանք երկրորդ ճանապարհով. userspace backend-ը դեռ գտնվում է «փորձնական» վիճակում և փոքր-ինչ պատրաստ չէ արդյունավետ օգտագործման համար: Բացի այդ, դրա հետ կապված որոգայթներ կան, որոնց մասին կարելի է շատ խոսել և (օ՜ սարսափ!) վիճել։

Եթե ​​մենք օգտագործում ենք նույնիսկ որոշակիորեն կայուն բաշխում երկար աջակցության ցիկլով, ապա մեր ունեցած միջուկը հնագույն, հնագույն տարբերակ է: Օրինակ, CentOS7-ում այն ​​3.10.* է, CentOS8-ում՝ 4.19։ Իսկ մեզ հետաքրքրում է առնվազն 5.3 (ավելի ճիշտ՝ 5.4) և ավելի նոր միջուկ։ Ինչո՞ւ։ Քանի որ լռելյայնորեն Ceph պատկերները միացված են ընտրանքների մի շարք, որոնք համատեղելի չեն հին միջուկների հետ: Սա նշանակում է, որ մենք միացնում ենք պահեստը նոր միջուկի հետ մեր բաշխման համար (օրինակ, CentOS-ի համար սա elrepo-ն է), տեղադրում ենք նոր միջուկը և վերագործարկում համակարգը՝ նոր միջուկի հետ աշխատելու համար.

• Միացեք փորձի համար ընտրված մոնիտորին
• Մենք միացնում ենք elrepo պահեստները ըստ հրահանգների. elrepo.org/tiki/tiki-index.php
• Տեղադրեք միջուկը՝ yum -y —enablerepo=elrepo-kernel install kernel-ml
• Վերագործարկեք սերվերը մոնիտորով (մենք ունենք երեք մոնիտոր, այնպես չէ՞):

Պատկերը որպես բլոկ սարքի միացում

# rbd map mypool/myimage
/dev/rbd0

Մնում է միայն կարգավորել թիրախը: Այս օրինակում ես կկարգավորեմ թիրախը այսպես կոչված. Դեմո ռեժիմ՝ առանց նույնականացման, տեսանելի և հասանելի բոլորի համար: Արտադրական միջավայրում, հավանաբար, կցանկանաք կարգավորել նույնականացումը, բայց դա մի փոքր դուրս է շրջանակից այսօրվա պարզապես զվարճանքի համար:

Ստեղծեք disk1 անունով backend՝ կապված /dev/rbd/mypool/myimage ֆայլի հետ: Նշված ֆայլը udev daemon-ի կողմից ավտոմատ կերպով ստեղծված սիմվոլիկ հղում է դեպի /dev/rbd0: Մենք օգտագործում ենք խորհրդանշական հղում, քանի որ rbd սարքի անվանումը կարող է փոխվել՝ կախված այն հաջորդականությունից, որով Ceph պատկերները միացված են հոսթին:

Ստեղծեք հետին պլան.

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

Ստեղծեք iSCSI թիրախ.

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

Մենք միացնում ենք backend-ը որպես 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-ի միացում և թիրախի իրական արձակում:

Նախ, եկեք կարգավորենք 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 ջնջել ... դուք կարող եք հայտնվել սերվերի հետ, որը չի բեռնվում կամ երկար ժամանակ է պահանջում բեռնման համար:

Ի՞նչ է մնացել։

Կազմաձևեք նախաձեռնողը սերվերի վրա, որտեղ մենք ցանկանում ենք ուղարկել թիրախը:

Ինչպե՞ս ապահովել մեր թիրախի սխալ հանդուրժողականությունը:

Դուք կարող եք նմանապես կարգավորել թիրախները այլ մոնիտորների վրա և կարգավորել բազմուղի (vmware-ը դա կհասկանա և նույնիսկ կաշխատի, Hyper-V-ն չի հասկանա. դրա համար պահանջվում են SCSI կողպեքներ): Քանի որ միջուկից Ceph հաճախորդը չի օգտագործում քեշավորում, սա բավականին գործունակ է: Կամ մեկ այլ տարբերակ երեք բաղադրիչներից բաղկացած կլաստերային ռեսուրս ստեղծելն է՝ հատուկ թիրախային IP հասցե և rbdmap և scsi-target ծառայություններ, և կառավարել այս ռեսուրսը կլաստերավորման գործիքների միջոցով (ո՞վ ասաց սրտի ռիթմավարը):

Կատարված բառի փոխարեն

Ինչպես պարզ է, այս հոդվածը մի քիչ կատակ է, բայց դրանում ես փորձեցի «արագ և օրինակներով» դիտարկել մի քանի բավականին հայտնի թեմաներ միաժամանակ՝ iSCSI թիրախ, որը կարող է պարտադիր կերպով չարտահանել Ceph պատկերներ, բայց օրինակ. արտահանել LVM ծավալներ, iSCSI նախաձեռնողի հետ աշխատելու հիմունքներ (ինչպես սկանավորել թիրախը, ինչպես միանալ թիրախին, անջատել, ջնջել թիրախային մուտքը տվյալների բազայից), գրել ձեր սեփական միավորը systemd-ի համար և մի քանի այլ

Հուսով եմ, որ նույնիսկ եթե այս ամբողջ փորձը ամբողջությամբ չկրկնեք, գոնե այս հոդվածից ինչ-որ բան օգտակար կլինի ձեզ համար:

Source: www.habr.com