En ĉi tiu artikolo, mi ŝatus paroli pri la funkcioj de All Flash AccelStor-tabeloj laborantaj kun unu el la plej popularaj virtualigaj platformoj - VMware vSphere. Aparte, koncentriĝu pri tiuj parametroj, kiuj helpos vin akiri la maksimuman efikon de uzado de tia potenca ilo kiel All Flash.
AccelStor NeoSapphire™ Ĉiuj Flash-aroj estas aŭ nodaj aparatoj bazitaj sur SSD-diskoj kun fundamente malsama aliro al efektivigo de la koncepto de datumstokado kaj organizado de aliro al ĝi per propra teknologio. anstataŭ la tre popularaj RAID-algoritmoj. La aroj disponigas blokaliron al gastigantoj per Fibre Channel aŭ iSCSI-interfacoj. Por esti juste, ni rimarkas, ke modeloj kun ISCSI-interfaco ankaŭ havas dosieraliron kiel belan gratifikon. Sed en ĉi tiu artikolo ni koncentriĝos pri la uzo de blokprotokoloj kiel la plej produktivaj por All Flash.
La tuta procezo de deplojo kaj posta agordo de komuna funkciado de la tabelo AccelStor kaj la sistemo de virtualigo VMware vSphere povas esti dividita en plurajn stadiojn:
- Efektivigo de konekta topologio kaj agordo de SAN-reto;
- Agordo de All Flash-tabelo;
- Agordi ESXi-gastigojn;
- Agordo de virtualaj maŝinoj.
AccelStor NeoSapphire™ Fibre Channel-aroj kaj iSCSI-aroj estis utiligitaj kiel specimena aparataro. La baza programaro estas VMware vSphere 6.7U1.
Antaŭ ol disfaldi la sistemojn priskribitajn en ĉi tiu artikolo, estas tre rekomendite, ke vi legu la dokumentaron de VMware pri rendimentaj problemoj ( ) kaj iSCSI-agordoj ()
Ligtopologio kaj SAN-reta agordo
La ĉefaj komponentoj de SAN-reto estas HBAoj en ESXi-gastigantoj, SAN-ŝaltiloj kaj tabelnodoj. Tipa topologio por tia reto aspektus jene:
La esprimo Ŝaltilo ĉi tie rilatas al kaj aparta fizika ŝaltilo aŭ aro de ŝaltiloj (Ŝtofo), kaj aparato dividita inter malsamaj servoj (VSAN en la kazo de Fibre Channel kaj VLAN en la kazo de iSCSI). Uzado de du sendependaj ŝaltiloj/Ŝtofoj eliminos eblan punkton de fiasko.
Rekta konekto de gastigantoj al la tabelo, kvankam subtenata, estas tre ne rekomendita. La rendimento de All Flash-aroj estas sufiĉe alta. Kaj por maksimuma rapideco, ĉiuj havenoj de la tabelo devas esti uzataj. Tial, la ĉeesto de almenaŭ unu ŝaltilo inter la gastigantoj kaj NeoSapphire™ estas deviga.
La ĉeesto de du havenoj sur la gastiga HBA ankaŭ estas deviga postulo por atingi maksimuman rendimenton kaj certigi misfunkciadon.
Dum uzado de Fibre Channel-interfaco, zonigo devas esti agordita por elimini eblajn koliziojn inter iniciatintoj kaj celoj. Zonoj estas konstruitaj laŭ la principo de "unu iniciatinto-haveno - unu aŭ pluraj tabelhavenoj."
Se vi uzas konekton per iSCSI en la kazo de uzado de ŝaltilo kunhavita kun aliaj servoj, tiam estas nepre izoli iSCSI-trafikon ene de aparta VLAN. Estas ankaŭ tre rekomendite ebligi subtenon por Jumbo Frames (MTU = 9000) por pliigi la grandecon de pakaĵoj en la reto kaj tiel redukti la kvanton de supraj informoj dum transdono. Tamen, indas memori, ke por ĝusta funkciado necesas ŝanĝi la MTU-parametron sur ĉiuj retaj komponantoj laŭ la ĉeno "iniciator-ŝaltilo-celo".
Agordo de All Flash-tabelo
La tabelo estas liverita al klientoj kun jam formitaj grupoj . Tial, neniuj agoj devas esti prenitaj por kombini veturadojn en ununuran strukturon. Vi nur bezonas krei volumojn de la bezonata grandeco kaj kvanto.
Por oportuno, ekzistas funkcieco por grupkreado de pluraj volumoj de antaŭfiksita grandeco samtempe. Defaŭlte, maldikaj volumoj estas kreitaj, ĉar tio permesas pli efikan uzon de disponebla stoka spaco (inkluzive de subteno por Space Reclamation). Laŭ rendimento, la diferenco inter "maldikaj" kaj "dikaj" volumoj ne superas 1%. Tamen, se vi volas "elpremi la tutan sukon" el tabelo, vi ĉiam povas konverti ajnan "maldikan" volumenon en "dikan". Sed oni devas memori, ke tia operacio estas neinversigebla.
Poste, restas "publikigi" la kreitajn volumojn kaj agordi alirrajtojn al ili de la gastigantoj uzante ACL-ojn (IP-adresoj por iSCSI kaj WWPN por FC) kaj fizikan apartigon per taraj havenoj. Por iSCSI-modeloj tio estas farita kreante Celon.
Por FC-modeloj, eldonado okazas per la kreado de LUN por ĉiu haveno de la tabelo.
Por akceli la aranĝan procezon, gastigantoj povas esti kombinitaj en grupojn. Cetere, se la gastiganto uzas multiportan FC HBA (kio praktike plej ofte okazas), tiam la sistemo aŭtomate determinas, ke la havenoj de tia HBA apartenas al ununura gastiganto danke al WWPN-oj, kiuj diferencas je unu. Bata kreado de Target/LUN ankaŭ estas subtenata por ambaŭ interfacoj.
Grava noto dum uzado de la iSCSI-interfaco estas krei plurajn celojn por volumoj samtempe por pliigi rendimenton, ĉar la atendovico sur la celo ne povas esti ŝanĝita kaj efektive estos proplemkolo.
Agordante ESXi Gastigantoj
Ĉe la ESXi-gastiganto, baza agordo estas farita laŭ tute atendata scenaro. Proceduro por iSCSI-konekto:
- Aldonu Programaron iSCSI-Adaptilon (ne bezonata se ĝi jam estis aldonita, aŭ se vi uzas Hardware iSCSI-Adaptilon);
- Krei vSwitch tra kiu iSCSI-trafiko pasos, kaj aldonante fizikan suprenligo kaj VMkernal al ĝi;
- Aldonante tabelajn adresojn al Dynamic Discovery;
- Kreado de datumvendejo
Kelkaj gravaj notoj:
- En la ĝenerala kazo, kompreneble, vi povas uzi ekzistantan vSwitch, sed en la kazo de aparta vSwitch, administri la gastigajn agordojn estos multe pli facila.
- Estas necese apartigi Administradon kaj iSCSI-trafikon sur apartajn fizikajn ligilojn kaj/aŭ VLANojn por eviti rendimentajn problemojn.
- La IP-adresoj de la VMkernal kaj la respondaj havenoj de la All Flash-tabelo devas esti ene de la sama subreto, denove pro rendimentaj problemoj.
- Por certigi misfunkciadon laŭ VMware-reguloj, vSwitch devas havi almenaŭ du fizikajn suprenligojn
- Se Jumbo Frames estas uzataj, vi devas ŝanĝi la MTU de ambaŭ vSwitch kaj VMkernal
- Estus utile memorigi vin, ke laŭ VMware-rekomendoj por fizikaj adaptiloj, kiuj estos uzataj por labori kun iSCSI-trafiko, necesas agordi Teaming kaj Failover. Aparte, ĉiu VMkernal devas funkcii per nur unu suprenligo, la dua suprenligo devas esti ŝanĝita al neuzata reĝimo. Por erartoleremo, vi devas aldoni du VMkernals, ĉiu el kiuj funkcios per sia propra suprenligo.
VMkernel-Adaptilo (vmk#)
Fizika Reta Adaptilo (vmnic#)
vmk1 (Stokado01)
Aktivaj adaptiloj
vmnic2
Neuzataj Adaptiloj
vmnic3
vmk2 (Stokado02)
Aktivaj adaptiloj
vmnic3
Neuzataj Adaptiloj
vmnic2
Neniuj antaŭaj paŝoj estas bezonataj por konekti per Fibra Kanalo. Vi povas tuj krei Datumvendejon.
Post kreado de la Datumvendejo, vi devas certigi, ke la politiko Round Robin por vojoj al la Celo/LUN estas uzata kiel la plej efika.
Defaŭlte, VMware-agordoj provizas la uzon de ĉi tiu politiko laŭ la skemo: 1000 petoj tra la unua vojo, la sekvaj 1000 petoj tra la dua vojo, ktp. Tia interago inter la gastiganto kaj la du-regila aro estos malekvilibra. Tial ni rekomendas agordi la politikon Round Robin = 1 parametron per Esxcli/PowerCLI.
parametroj
Por Esxcli:
- Listigu disponeblajn LUN-ojn
esxcli stokado nmp aparato listo
- Kopiu Aparato Nomo
- Ŝanĝi Round Robin Politiko
esxcli stokado nmp psp roundrobin deviceconfig aro —type=iops —iops=1 —device=“Device_ID”
Plej modernaj aplikoj estas dizajnitaj por interŝanĝi grandajn datumpakaĵojn por maksimumigi bendolarĝan utiligon kaj redukti CPU-ŝarĝon. Tial, ESXi defaŭlte eldonas I/O-petojn al la stoka aparato en pecoj de ĝis 32767KB. Tamen, por iuj scenaroj, interŝanĝi pli malgrandajn pecojn estos pli produktiva. Por AccelStor-tabeloj, ĉi tiuj estas la sekvaj scenaroj:
- La virtuala maŝino uzas UEFI anstataŭ Legacy BIOS
- Uzas vSphere Replication
Por tiaj scenaroj, oni rekomendas ŝanĝi la valoron de la parametro Disk.DiskMaxIOSize al 4096.
Por iSCSI-konektoj, oni rekomendas ŝanĝi la Parametron de Ensaluttempo al 30 (defaŭlte 5) por pliigi konektstabilecon kaj malŝalti la DelayedAck-prokraston por konfirmoj de plusenditaj pakaĵoj. Ambaŭ opcioj estas en vSphere Client: Gastiganto → Agordu → Stokado → Stokado-Adaptiloj → Altnivelaj Opcioj por iSCSI-adaptilo
Sufiĉe subtila punkto estas la nombro da volumoj uzataj por la datumvendejo. Estas klare, ke por facileco de administrado, ekzistas deziro krei unu grandan volumon por la tuta volumeno de la tabelo. Tamen, la ĉeesto de pluraj volumoj kaj, sekve, datumvendejo havas utilan efikon al ĝenerala rendimento (pli pri atendovicoj sube). Tial ni rekomendas krei almenaŭ du volumojn.
Ĝis relative lastatempe, VMware konsilis limigi la nombron da virtualaj maŝinoj sur unu datumvendejo, denove por akiri la plej altan eblan rendimenton. Tamen nun, precipe kun la disvastiĝo de VDI, ĉi tiu problemo ne plu estas tiel akra. Sed ĉi tio ne nuligas la longdaŭran regulon - distribui virtualajn maŝinojn kiuj postulas intensan IO tra malsamaj datumbutikoj. Por determini la optimuman nombron da virtualaj maŝinoj per volumo, estas nenio pli bona ol ene de ĝia infrastrukturo.
Agordo de virtualaj maŝinoj
Ne estas specialaj postuloj dum agordado de virtualaj maŝinoj, aŭ prefere ili estas sufiĉe ordinaraj:
- Uzante la plej altan eblan VM-version (kongruo)
- Estas pli zorge agordi la RAM-grandecon, kiam oni metas dense virtualajn maŝinojn, ekzemple en VDI (ĉar defaŭlte, ĉe ekfunkciigo, estas kreita paĝdosiero kun grandeco proporcia al la RAM, kiu konsumas utilan kapablon kaj efikas sur la fina agado)
- Uzu la plej produktivajn adaptilojn laŭ IO: rettipo VMXNET 3 kaj SCSI tipo PVSCSI
- Uzu Thick Provision Eager Zeroed-disktipo por maksimuma rendimento kaj Thin Provisioning por maksimuma konserva spaco-utiligo
- Se eble, limigu la funkciadon de ne-I/O-kritikaj maŝinoj uzante Virtual Disk Limit
- Nepre instalu VMware Tools
Notoj pri Queues
Vico (aŭ Elstara I/Os) estas la nombro da enig/eligpetoj (SCSI-komandoj) kiuj atendas prilaborado en iu antaŭfiksita tempo por specifa aparato/aplikaĵo. En kazo de vostosuperfluo, QFULL-eraroj estas elsenditaj, kio finfine rezultigas pliiĝon en la latencia parametro. Kiam oni uzas diskojn (spindele) stokadsistemojn, teorie, ju pli alta la atendovico, des pli alta ilia rendimento. Tamen vi ne misuzu ĝin, ĉar estas facile renkonti QFULL. En la kazo de All Flash-sistemoj, unuflanke, ĉio estas iom pli simpla: finfine, la tabelo havas latentecojn kiuj estas ordoj de grandeco pli malaltaj kaj tial, plej ofte, ne necesas aparte reguligi la grandecon de la atendovicoj. Sed aliflanke, en iuj uzaj scenaroj (forta svingo en IO-postuloj por specifaj virtualaj maŝinoj, testoj por maksimuma rendimento, ktp.) necesas, se ne ŝanĝi la parametrojn de la atendovicoj, tiam almenaŭ kompreni kiajn indikilojn. povas esti atingita, kaj, la ĉefa afero estas en kiaj manieroj.
Sur la tabelo AccelStor All Flash mem ne ekzistas limoj rilate al volumoj aŭ I/O-havenoj. Se necese, eĉ ununura volumo povas ricevi ĉiujn rimedojn de la tabelo. La nura limigo sur la atendovico estas por iSCSI-celoj. Estas tial, ke la bezono krei plurajn (idee ĝis 8 pecoj) celojn por ĉiu volumo por venki ĉi tiun limon estis indikita supre. Ni ankaŭ ripetu, ke AccelStor-tabeloj estas tre produktivaj solvoj. Tial vi devus uzi ĉiujn interfacajn havenojn de la sistemo por atingi maksimuman rapidecon.
Ĉe la ESXi-gastiganto, la situacio estas tute malsama. La gastiganto mem aplikas la praktikon de egala aliro al rimedoj por ĉiuj partoprenantoj. Tial, ekzistas apartaj IO-vostoj por la gasto OS kaj HBA. Vicoj al la gasta OS estas kombinitaj de vostoj ĝis la virtuala SCSI-adaptilo kaj virtuala disko:
La atendovico al la HBA dependas de la specifa tipo/vendisto:
La fina rendimento de la virtuala maŝino estos determinita de la plej malalta Queue Depth-limo inter la gastigaj komponantoj.
Danke al ĉi tiuj valoroj, ni povas taksi la rendimentajn indikilojn, kiujn ni povas akiri en aparta agordo. Ekzemple, ni volas scii la teorian agadon de virtuala maŝino (sen bloka ligado) kun latenco de 0.5ms. Tiam ĝia IOPS = (1,000/latenteco) * Elstara I/Os (Limo de Profundo de Vidovico)
ekzemploj
ekzemple 1
- FC Emulex HBA-Adaptilo
- Unu VM per datumvendejo
- VMware Paravirtual SCSI-Adaptilo
Ĉi tie Queue Depth-limo estas determinita de Emulex HBA. Tial IOPS = (1000/0.5)*32 = 64K
ekzemple 2
- VMware iSCSI Programaro-Adaptilo
- Unu VM per datumvendejo
- VMware Paravirtual SCSI-Adaptilo
Ĉi tie la Queue Depth-limo jam estas determinita de la Paravirtuala SCSI-Adaptilo. Tial IOPS = (1000/0.5)*64 = 128K
Plej bonaj modeloj de All Flash AccelStor-tabeloj (ekzemple, ) kapablas liveri 700K IOPS-skriban rendimenton ĉe 4K-bloko. Kun tia blokgrandeco, estas sufiĉe evidente, ke ununura virtuala maŝino ne kapablas ŝarĝi tian tabelon. Por fari tion, vi bezonos 11 (ekzemple 1) aŭ 6 (ekzemple 2) virtualajn maŝinojn.
Kiel rezulto, kun la ĝusta agordo de ĉiuj priskribitaj komponantoj de virtuala datumcentro, vi povas akiri tre impresajn rezultojn laŭ rendimento.
4K Hazarda, 70% Legado/30% Skribo
Fakte, la reala mondo estas multe pli kompleksa ol ĝi povas esti priskribita per simpla formulo. Unu gastiganto ĉiam gastigas plurajn virtualajn maŝinojn kun malsamaj agordoj kaj IO-postuloj. Kaj I/O-pretigo estas pritraktata de la gastiga procesoro, kies potenco ne estas senfina. Do, por malŝlosi la plenan potencialon de la sama fakte, vi bezonos tri gastigantojn. Krome, aplikaĵoj kurantaj en virtualaj maŝinoj faras siajn proprajn ĝustigojn. Tial ni proponas por preciza grandeco Ĉiuj Flash tabeloj ene de la infrastrukturo de la kliento pri realaj aktualaj taskoj.
fonto: www.habr.com