In hierdie artikel wil ek praat oor die kenmerke van All Flash AccelStor-skikkings wat met een van die gewildste virtualisasieplatforms werk - VMware vSphere. Fokus veral op daardie parameters wat jou sal help om die maksimum effek te kry deur so 'n kragtige instrument soos All Flash te gebruik.
AccelStor NeoSapphire™ Alle flitsskikkings is of nodus-toestelle gebaseer op SSD-aandrywers met 'n fundamenteel verskillende benadering tot die implementering van die konsep van databerging en die organisering van toegang daartoe deur gebruik te maak van eie tegnologie in plaas van die baie gewilde RAID-algoritmes. Die skikkings bied bloktoegang aan gashere via Fibre Channel- of iSCSI-koppelvlakke. Om regverdig te wees, let ons daarop dat modelle met 'n ISCSI-koppelvlak ook lêertoegang het as 'n lekker bonus. Maar in hierdie artikel sal ons fokus op die gebruik van blokprotokolle as die mees produktiewe vir All Flash.
Die hele proses van ontplooiing en daaropvolgende konfigurasie van gesamentlike werking van die AccelStor-skikking en die VMware vSphere-virtualiseringstelsel kan in verskeie stadiums verdeel word:
- Implementering van verbindingstopologie en konfigurasie van SAN-netwerk;
- Die opstel van All Flash-skikking;
- Opstel van ESXi-gashere;
- Die opstel van virtuele masjiene.
AccelStor NeoSapphire™ Fibre Channel-skikkings en iSCSI-skikkings is as voorbeeldhardeware gebruik. Die basissagteware is VMware vSphere 6.7U1.
Voordat u die stelsels wat in hierdie artikel beskryf word ontplooi, word dit sterk aanbeveel dat u die dokumentasie van VMware lees oor werkverrigtingkwessies ( ) en iSCSI-instellings ()
Verbindingstopologie en SAN-netwerkkonfigurasie
Die hoofkomponente van 'n SAN-netwerk is HBA's in ESXi-gashere, SAN-skakelaars en skikkingsnodusse. 'n Tipiese topologie vir so 'n netwerk sal soos volg lyk:
Die term Switch hier verwys na beide 'n aparte fisiese skakelaar of stel skakelaars (Stof), en 'n toestel wat tussen verskillende dienste gedeel word (VSAN in die geval van Fibre Channel en VLAN in die geval van iSCSI). Die gebruik van twee onafhanklike skakelaars/stowwe sal 'n moontlike punt van mislukking uitskakel.
Direkte verbinding van gashere aan die skikking, hoewel dit ondersteun word, word sterk nie aanbeveel nie. Die werkverrigting van All Flash-skikkings is redelik hoog. En vir maksimum spoed moet alle poorte van die skikking gebruik word. Daarom is die teenwoordigheid van ten minste een skakelaar tussen die gashere en NeoSapphire™ verpligtend.
Die teenwoordigheid van twee poorte op die gasheer-HBA is ook 'n verpligte vereiste om maksimum werkverrigting te behaal en fouttoleransie te verseker.
Wanneer 'n Fibre Channel-koppelvlak gebruik word, moet sonering opgestel word om moontlike botsings tussen inisieerders en teikens uit te skakel. Sones is gebou op die beginsel van "een inisieerderpoort - een of meer skikkingpoorte."
As jy 'n verbinding via iSCSI gebruik in die geval van die gebruik van 'n skakelaar wat met ander dienste gedeel word, dan is dit noodsaaklik om iSCSI-verkeer binne 'n aparte VLAN te isoleer. Dit word ook sterk aanbeveel om ondersteuning vir Jumbo Frames (MTU = 9000) te aktiveer om die grootte van pakkies op die netwerk te vergroot en sodoende die hoeveelheid oorhoofse inligting tydens transmissie te verminder. Dit is egter die moeite werd om te onthou dat dit vir korrekte werking nodig is om die MTU-parameter op alle netwerkkomponente langs die "initiator-skakelaar-teiken"-ketting te verander.
Stel All Flash-skikking op
Die skikking word aan kliënte met reeds gevormde groepe afgelewer . Daarom hoef geen aksies geneem te word om aandrywers in 'n enkele struktuur te kombineer nie. Jy hoef net volumes van die vereiste grootte en hoeveelheid te skep.
Gerieflikheidshalwe is daar funksionaliteit vir bondelskepping van verskeie volumes van 'n gegewe grootte gelyktydig. By verstek word dun volumes geskep, aangesien dit meer doeltreffende gebruik van beskikbare stoorspasie moontlik maak (insluitend ondersteuning vir Space Reclamation). Wat prestasie betref, is die verskil tussen "dun" en "dik" volumes nie meer as 1% nie. As jy egter "al die sap" uit 'n skikking wil druk, kan jy altyd enige "dun" volume in 'n "dik" een omskakel. Maar dit moet onthou word dat so 'n operasie onomkeerbaar is.
Vervolgens bly dit om die geskepte volumes te "publiseer" en toegangsregte daarvoor vanaf die gashere in te stel met behulp van ACL's (IP-adresse vir iSCSI en WWPN vir FC) en fisiese skeiding deur skikkingpoorte. Vir iSCSI-modelle word dit gedoen deur 'n teiken te skep.
Vir FC-modelle vind publisering plaas deur die skepping van 'n LUN vir elke poort van die skikking.
Om die opstelproses te bespoedig, kan gashere in groepe gekombineer word. Verder, as die gasheer 'n multipoort FC HBA gebruik (wat in die praktyk die meeste gebeur), dan bepaal die stelsel outomaties dat die poorte van so 'n HBA aan 'n enkele gasheer behoort danksy WWPN's wat met een verskil. Batch-skepping van Target/LUN word ook vir beide koppelvlakke ondersteun.
'n Belangrike nota wanneer die iSCSI-koppelvlak gebruik word, is om verskeie teikens vir volumes gelyktydig te skep om werkverrigting te verhoog, aangesien die tou op die teiken nie verander kan word nie en effektief 'n bottelnek sal wees.
Konfigureer ESXi Hosts
Aan die ESXi-gasheerkant word basiese konfigurasie uitgevoer volgens 'n heeltemal verwagte scenario. Prosedure vir iSCSI-verbinding:
- Voeg sagteware iSCSI Adapter by (nie nodig as dit reeds bygevoeg is, of as jy hardeware iSCSI Adapter gebruik nie);
- Skep 'n vSwitch waardeur iSCSI-verkeer sal slaag, en voeg 'n fisiese opskakel en VMkernel daarby;
- Voeg skikkingsadresse by Dynamic Discovery;
- Skep van datawinkel
Enkele belangrike notas:
- In die algemene geval kan u natuurlik 'n bestaande vSwitch gebruik, maar in die geval van 'n aparte vSwitch sal die bestuur van die gasheerinstellings baie makliker wees.
- Dit is nodig om Bestuur- en iSCSI-verkeer op aparte fisiese skakels en/of VLAN's te skei om prestasieprobleme te vermy.
- Die IP-adresse van die VMkernel en die ooreenstemmende poorte van die All Flash-skikking moet binne dieselfde subnet wees, weer as gevolg van werkverrigtingkwessies.
- Om fouttoleransie volgens VMware-reëls te verseker, moet vSwitch ten minste twee fisiese opskakels hê
- As Jumbo Frames gebruik word, moet jy die MTU van beide vSwitch en VMkernel verander
- Dit sal nuttig wees om jou te herinner dat dit volgens VMware-aanbevelings vir fisiese adapters wat gebruik sal word om met iSCSI-verkeer te werk, nodig is om Teaming en Failover op te stel. In die besonder moet elke VMkernel slegs deur een opskakel werk, die tweede opskakel moet na ongebruikte modus oorgeskakel word. Vir fouttoleransie moet jy twee VMkernes byvoeg, wat elkeen deur sy eie opskakel sal werk.
VMkernel Adapter (vmk#)
Fisiese netwerkadapter (vmnic#)
vmk1 (Storage01)
Aktiewe adapters
vmnic2
Ongebruikte adapters
vmnic3
vmk2 (Storage02)
Aktiewe adapters
vmnic3
Ongebruikte adapters
vmnic2
Geen voorlopige stappe is nodig om via Fibre Channel te koppel nie. U kan onmiddellik 'n Datastore skep.
Nadat u die datastoor geskep het, moet u seker maak dat die Round Robin-beleid vir paaie na die teiken/LUN as die beste gebruik word.
By verstek maak VMware-instellings voorsiening vir die gebruik van hierdie beleid volgens die skema: 1000 versoeke deur die eerste pad, die volgende 1000 versoeke deur die tweede pad, ens. Sulke interaksie tussen die gasheer en die twee-beheerder skikking sal ongebalanseerd wees. Daarom beveel ons aan dat die Round Robin-beleid = 1 parameter via Esxcli/PowerCLI ingestel word.
Parameters
Vir Esxcli:
- Lys beskikbare LUN's
esxcli stoor nmp toestel lys
- Kopieer toestelnaam
- Verander Round Robin-beleid
esxcli berging nmp psp roundrobin deviceconfig stel —type=iops —iops=1 —device=“Device_ID”
Die meeste moderne toepassings is ontwerp om groot datapakkies uit te ruil om bandwydtebenutting te maksimeer en SVE-lading te verminder. Daarom gee ESXi by verstek I/O-versoeke aan die stoortoestel in stukke van tot 32767KB. Vir sommige scenario's sal die uitruil van kleiner stukke egter meer produktief wees. Vir AccelStor-skikkings is dit die volgende scenario's:
- Die virtuele masjien gebruik UEFI in plaas van Legacy BIOS
- Gebruik vSphere Replication
Vir sulke scenario's word dit aanbeveel om die waarde van die Disk.DiskMaxIOSize-parameter na 4096 te verander.
Vir iSCSI-verbindings word dit aanbeveel om die Login Timeout-parameter na 30 (verstek 5) te verander om verbindingstabiliteit te verhoog en die DelayedAck-vertraging vir bevestigings van aangestuurde pakkies te deaktiveer. Albei opsies is in vSphere Client: Gasheer → Konfigureer → Berging → Bergingadapters → Gevorderde opsies vir iSCSI-adapter
'n Nogal subtiele punt is die aantal volumes wat vir die datastoor gebruik word. Dit is duidelik dat daar vir gemak van bestuur 'n begeerte is om een groot volume vir die hele volume van die skikking te skep. Die teenwoordigheid van verskeie volumes en dienooreenkomstig datastoor het egter 'n voordelige uitwerking op algehele prestasie (meer oor toue hieronder). Daarom beveel ons aan om ten minste twee volumes te skep.
Tot relatief onlangs het VMware aangeraai om die aantal virtuele masjiene op een datawinkel te beperk, weer om die hoogste moontlike werkverrigting te verkry. Nou, veral met die verspreiding van VDI, is hierdie probleem egter nie meer so akuut nie. Maar dit kanselleer nie die jarelange reël nie - om virtuele masjiene wat intensiewe IO benodig oor verskillende datawinkels te versprei. Om die optimale aantal virtuele masjiene per volume te bepaal, is daar niks beter as binne sy infrastruktuur.
Die opstel van virtuele masjiene
Daar is geen spesiale vereistes by die opstel van virtuele masjiene nie, of liewer dit is heel gewoon:
- Gebruik die hoogste moontlike VM-weergawe (versoenbaarheid)
- Dit is meer versigtig om die RAM-grootte in te stel wanneer virtuele masjiene dig geplaas word, byvoorbeeld in VDI (aangesien by verstek, by opstart, 'n bladsylêer geskep word van 'n grootte wat ooreenstem met die RAM, wat nuttige kapasiteit verbruik en 'n effek het op die finale uitvoering)
- Gebruik die mees produktiewe adapter weergawes in terme van IO: netwerk tipe VMXNET 3 en SCSI tipe PVSCSI
- Gebruik Thick Provision Eager Zeroed-skyftipe vir maksimum werkverrigting en Thin Provisioning vir maksimum stoorspasiebenutting
- Indien moontlik, beperk die werking van nie-I/O-kritiese masjiene deur Virtual Disk Limit te gebruik
- Maak seker dat u VMware Tools installeer
Notas oor toue
Tou (of uitstaande I/O's) is die aantal invoer/afvoerversoeke (SCSI-opdragte) wat op enige gegewe tydstip wag vir verwerking vir 'n spesifieke toestel/toepassing. In die geval van tou oorloop, word QFULL foute uitgereik, wat uiteindelik lei tot 'n toename in die latency parameter. By die gebruik van skyf (spil) bergingstelsels, teoreties, hoe hoër die tou, hoe hoër hul werkverrigting. U moet dit egter nie misbruik nie, aangesien dit maklik is om QFULL raak te loop. In die geval van All Flash-stelsels, aan die een kant, is alles ietwat eenvoudiger: die skikking het immers latensies wat ordes van grootte laer is en daarom is dit meestal nie nodig om die grootte van die toue afsonderlik te reguleer nie. Maar aan die ander kant, in sommige gebruikscenario's (sterk skeeftrekking in IO-vereistes vir spesifieke virtuele masjiene, toetse vir maksimum werkverrigting, ens.) Is dit nodig, indien nie om die parameters van die toue te verander nie, dan ten minste om te verstaan watter aanwysers bereik kan word, en die belangrikste ding is op watter maniere.
Op die AccelStor All Flash-skikking self is daar geen beperkings met betrekking tot volumes of I/O-poorte nie. Indien nodig, kan selfs 'n enkele volume al die hulpbronne van die skikking ontvang. Die enigste beperking op die tou is vir iSCSI-teikens. Dit is om hierdie rede dat die behoefte om verskeie (ideaal tot 8 stukke) teikens vir elke volume te skep om hierdie limiet te oorkom, hierbo aangedui is. Laat ons ook herhaal dat AccelStor-skikkings baie produktiewe oplossings is. Daarom moet jy alle koppelvlakpoorte van die stelsel gebruik om maksimum spoed te bereik.
Aan die ESXi-gasheerkant is die situasie heeltemal anders. Die gasheer self pas die praktyk van gelyke toegang tot hulpbronne vir alle deelnemers toe. Daarom is daar aparte IO-rye vir die gas-bedryfstelsel en HBA. Toue na die gas-bedryfstelsel word gekombineer van toue na die virtuele SCSI-adapter en virtuele skyf:
Die tou na die HBA hang af van die spesifieke tipe/verskaffer:
Die finale werkverrigting van die virtuele masjien sal bepaal word deur die laagste toudieptelimiet onder die gasheerkomponente.
Danksy hierdie waardes kan ons die prestasie-aanwysers evalueer wat ons in 'n spesifieke opset kan kry. Ons wil byvoorbeeld die teoretiese werkverrigting van 'n virtuele masjien (sonder blokbinding) met 'n latensie van 0.5ms weet. Dan is sy IOPS = (1,000 XNUMX/latency) * Uitstaande I/O's (Toue-diepte-limiet)
voorbeelde
Voorbeeld 1
- FC Emulex HBA Adapter
- Een VM per datastoor
- VMware Paravirtual SCSI Adapter
Hier word tou Diepte limiet bepaal deur Emulex HBA. Daarom IOPS = (1000/0.5)*32 = 64K
Voorbeeld 2
- VMware iSCSI sagteware adapter
- Een VM per datastoor
- VMware Paravirtual SCSI Adapter
Hier word die tou-diepte-limiet reeds deur die Paravirtual SCSI Adapter bepaal. Daarom IOPS = (1000/0.5)*64 = 128K
Topmodelle van All Flash AccelStor-skikkings (byvoorbeeld, ) in staat is om 700K IOPS-skryfprestasie teen 4K-blok te lewer. Met so 'n blokgrootte is dit duidelik dat 'n enkele virtuele masjien nie in staat is om so 'n skikking te laai nie. Om dit te doen, benodig jy 11 (byvoorbeeld 1) of 6 (byvoorbeeld 2) virtuele masjiene.
As gevolg hiervan, met die korrekte konfigurasie van al die beskryfde komponente van 'n virtuele datasentrum, kan u baie indrukwekkende resultate kry in terme van werkverrigting.
4K Willekeurig, 70% Lees/30% Skryf
Trouens, die werklike wêreld is baie meer kompleks as wat dit met 'n eenvoudige formule beskryf kan word. Een gasheer huisves altyd verskeie virtuele masjiene met verskillende konfigurasies en IO-vereistes. En I/O-verwerking word deur die gasheerverwerker hanteer, wie se krag nie oneindig is nie. Dus, om die volle potensiaal van dieselfde te ontsluit in werklikheid sal jy drie gashere nodig hê. Boonop maak toepassings wat binne virtuele masjiene loop, hul eie aanpassings. Daarom bied ons vir presiese grootte Alle Flash-skikkings binne die kliënt se infrastruktuur op werklike huidige take.
Bron: will.com