Ĉu estas inter ni tiuj (tsefovodov) kiuj ne ŝatas "profesian ekstremon"?
Estas neverŝajne - alie ni ne irus kun ĉi tiu ekstreme interesa kaj amuza produkto.
Multaj el tiuj, kiuj estis implikitaj en la funkciado de Ceph, renkontis unu ne tre oftan (aŭ pli ĝuste eĉ tre maloftan) sed foje en postula kazo - konektante Ceph per iSCSI aŭ FC. Por kio? Nu, ekzemple, sendu bildon de Ceph al Vindoza aŭ Solaris-servilo kiu ankoraŭ ne estis virtualigita ial. Aŭ virtualigita, sed uzante hiperviziilon, kiu ne povas fari Ceph - kaj, kiel ni scias, estas multaj. Ekzemple? Nu, ekzemple, HyperV aŭ ESXi, kiuj estas aktive uzataj. Kaj se aperas la tasko servi bildon de Ceph al gastmaŝino, ĉi tio fariĝas tre ekscita tasko.
Do, donita:
- jam kuranta Ceph-areto
- jam ekzistanta bildo kiu devas esti servita per iSCSI
- Naĝejo nomo mia naĝejo, bildonomo miabildo
Ĉu komenci?
Unue, kiam ni parolas pri FC aŭ iSCSI, ni havas tiajn entojn kiel iniciatinto kaj celo. Celo estas fakte servilo, iniciatinto estas kliento. Nia tasko estas sendi la Ceph-bildon al la iniciatinto kun minimuma peno. Ĉi tio signifas, ke ni devas vastigi celon. Sed kie, sur kiu komputilo?
Feliĉe, en Ceph-grupo ni havas almenaŭ unu komponanton, kies IP-adreso estas fiksita kaj sur kiu unu el la plej gravaj komponantoj de Ceph estas agordita, kaj tiu komponanto estas la monitoro. Sekve, ni instalas iSCSI-celon sur la monitoro (kaj iniciatilon samtempe, almenaŭ por testoj). Mi faris tion ĉe CentOS, sed la solvo ankaŭ taŭgas por iu ajn alia distribuo - vi nur bezonas instali la pakaĵojn laŭ la maniero, kiu estas akceptebla en via distribuo.
# yum -y install iscsi-initiator-utils targetcli
Kio estas la celo de la instalitaj pakoj?
- targetcli — ilo por administri la SCSI-celon enkonstruitan en la Linukso-kerno
- iscsi-initiator-utils — pako kun iloj uzataj por administri la iSCSI-iniciatilon enkonstruitan en la Linukso-kerno
Por sendi bildon per iSCSI al la iniciatinto, ekzistas du opcioj por la disvolviĝo de eventoj - uzu la uzantspacan malantaŭon de la celo aŭ konektu la bildon kiel blokaparato videbla al la operaciumo kaj eksportu ĝin per iSCSI. Ni iros la duan vojon - la uzantspaca malantaŭo ankoraŭ estas en "eksperimenta" stato kaj estas iomete ne preta por produktiva uzo. Krome, ĉe ĝi estas kaptiloj, pri kiuj oni povas multe paroli kaj (ho hororo!) argumenti.
Se ni uzas eĉ iom stabilan distribuon kun longa subtenciklo, tiam la kerno kiun ni havas estas iu antikva, antikva versio. Ekzemple, en CentOS7 ĝi estas 3.10.*, en CentOS8 ĝi estas 4.19. Kaj ni interesiĝas pri kerno de almenaŭ 5.3 (aŭ pli ĝuste 5.4) kaj pli nova. Kial? Ĉar defaŭlte Ceph-bildoj havas aron da opcioj ebligitaj, kiuj ne kongruas kun pli malnovaj kernoj. Ĉi tio signifas, ke ni ligas deponejon kun nova kerno por nia distribuo (ekzemple, por CentOS ĉi tio estas elrepo), instalas la novan kernon kaj rekomencas la sistemon por labori kun la nova kerno:
- Konektu al la monitoro elektita por la eksperimento
- Ni konektas elrepo-deponejojn laŭ la instrukcioj -
- Instalu la kernon: yum -y —enablerepo=elrepo-kernel install kernel-ml
- Rekomencu la servilon per la monitoro (ni havas tri monitorojn, ĉu ne?)
Konektante la bildon kiel bloka aparato
# rbd map mypool/myimage
/dev/rbd0
Restas nur agordi la celon. En ĉi tiu ekzemplo, mi agordos la celon en la tn. demo-reĝimo - sen aŭtentigo, videbla kaj alirebla por ĉiuj. En produktadmedio, vi verŝajne volos agordi aŭtentikigon - sed tio estas iom ekster-ampleksa por hodiaŭa nur por amuza ekzerco.
Kreu backend nomita disk1 asociita kun la dosiero /dev/rbd/mypool/myimage. La specifita dosiero estas simbola ligilo aŭtomate kreita de la udev-demono al /dev/rbd0. Ni uzas simbolan ligon ĉar la nomo de la rbd-aparato povas ŝanĝiĝi depende de la ordo en kiu la Ceph-bildoj estas konektitaj al la gastiganto.
Kreu backend:
# targetcli /backstores/block create disk1 /dev/rbd/mypool/myimage
Kreu iSCSI-celon:
# targetcli /iscsi create iqn.2020-01.demo.ceph:mypool
Ni konektas la backend kiel LUN al la celo:
# targetcli /iscsi/iqn.2020-01.demo.ceph:mypool/tpg1/luns create /backstores/block/disk1
Ni agordu la celon por demo-reĝimo:
# 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
Konservu la agordon:
# targetcli saveconfig
Kontrolante la ĉeeston de la celo:
# iscsiadm -m discovery -t st -p 127.0.0.1:3260
127.0.0.1:3260,1 iqn.2020-01.demo.ceph:mypool
Ni konektas la celon:
# 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.
Se vi faris ĉion ĝuste, nova disko aperos sur la servilo, kiu aspektas kiel SCSI-aparato, sed fakte estas bildo de Ceph, alirita per iSCSI-celo. Por eviti lanĉajn problemojn, estas pli bone forigi la konektitan diskon kaj la detektitan celon de la loka iniciatinto:
# iscsiadm -m node --logout
# iscsiadm -m discoverydb -o delete -t st -p 127.0.0.1:3260
Restas nur persisti la agordon, por ke la bildo konektiĝu aŭtomate kaj, post konekto, la celo tavoliĝas. Lanĉi celon konsistas el du paŝoj - konekti la RBD kaj efektive lanĉi la celon.
Unue, ni agordu la aŭtomatan konekton de RBD-bildoj al la gastiganto. Ĉi tio estas farita aldonante la sekvajn liniojn al la /etc/ceph/rbdmap-dosiero:
# cat /etc/ceph/rbdmap
# RbdDevice Parameters
mypool/myimage id=admin
# systemctl enable rbdmap
Restarigi la celan agordon estas iom pli komplika - ni devas skribi unuon por systemd, kiu restarigos la agordon:
# 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
La fina testo estas rekomenci nian monitoron (ĝi nun estas iSCSI-celo). Oni devas rimarki, ke se ni ne purigis la datumbazon de la iniciatinto per la komando iscsiadm -n discoverydb -o delete ... vi povus fini kun servilo kiu ne ŝarĝas aŭ bezonas longan tempon por ŝargi.
Kio restas?
Agordu la iniciatinton sur la servilo, kie ni volas sendi la celon.
Kiel certigi misfunkciadon de nia celo?
Vi povas simile agordi celojn sur aliaj ekranoj kaj agordi plurvojon (vmware komprenos tion kaj eĉ funkcios, Hyper-V ne komprenos - ĝi postulas SCSI-serurojn). Ĉar la Ceph-kliento de la kerno ne uzas kaŝmemoron, ĉi tio estas sufiĉe realigebla. Aŭ alia opcio estas krei cluster-rimedon de tri komponentoj - dediĉita cela IP-adreso kaj rbdmap kaj scsi-celaj servoj, kaj administri ĉi tiun rimedon per clustering-iloj (kiu diris korstimulilo?)
Anstataŭ epilogo
Kiel estas klare, ĉi tiu artikolo estas iom ŝerca - sed en ĝi mi provis "rapide kaj kun ekzemploj" konsideri plurajn sufiĉe popularajn temojn samtempe - iSCSI-celo, kiu eble ne nepre eksporti Ceph-bildojn - sed ekzemple, eksporti LVM-volumojn, la bazojn labori kun iSCSI-iniciato (kiel skani celon, kiel konekti al celo, malkonekti, forigi celeniron de la datumbazo), skribante vian propran unuon por systemd kaj iuj aliaj
Mi esperas, ke eĉ se vi ne ripetas ĉi tiun tutan eksperimenton plene, almenaŭ io el ĉi tiu artikolo utilos al vi.
fonto: www.habr.com