У рамках дадзенага артыкула жадалася б распавесці аб асаблівасцях працы All Flash масіваў AccelStor з адной з найпапулярных платформаў віртуалізацыі – VMware vSphere. У прыватнасці, акцэнтаваць увагу на тых параметрах, якія дапамогуць атрымаць максімальны эфект ад выкарыстання такой магутнай прылады, як All Flash.
All Flash масівы AccelStor NeoSapphire™ уяўляюць сабой або надавыя прылады на базе назапашвальнікаў SSD з прынцыпова іншым падыходам у рэалізацыі канцэпцыі захоўвання дадзеных і арганізацыі доступу да яе з выкарыстаннем уласнай тэхналогіі. замест вельмі папулярных алгарытмаў RAID. Масівы падаюць блокавы доступ для хастоў праз інтэрфейсы Fibre Channel ці iSCSI. Справядлівасці дзеля адзначым, што мадэлі з ISCSI інтэрфейсам таксама маюць файлавы доступ у якасці прыемнага бонуса. Але ў рамках дадзенага артыкула мы сфакусуемся на ўжыванні блокавых пратаколаў як найболей прадукцыйных для All Flash.
Увесь працэс разгортвання і наступнай налады сумеснай працы масіва AccelStor і сістэмы віртуалізацыі VMware vSphere можна падзяліць на некалькі этапаў:
- Рэалізацыя тапалогіі падключэння і настройка SAN сеткі;
- Настройка All Flash масіва;
- Настройка хастоў ESXi;
- Настройка віртуальных машын.
У якасці абсталявання для прыкладаў выкарыстоўваліся масівы AccelStor NeoSapphire з інтэрфейсам Fibre Channel і з інтэрфейсам iSCSI. У якасці базавага ПЗ - VMware vSphere 6.7U1.
Перад разгортваннем апісваных у артыкуле сістэм вельмі рэкамендуецца да азнаямлення дакументацыя ад VMware датычна пытанняў прадукцыйнасці. ) і налад iSCSI ()
Тапалогія падключэння і настройка SAN сеткі
Асноўнымі кампанентамі SAN сеткі з'яўляюцца адаптары HBA у хастах ESXi, SAN камутатары і ноды масіва. Тыповая тапалогія такой сеткі будзе выглядаць так:
Пад тэрмінам Switch тут разумеецца як асобны фізічны камутатар або набор камутатараў (Fabric), так і якое падзяляецца паміж рознымі сэрвісамі прылада (VSAN у выпадку Fibre Channel і VLAN у выпадку iSCSI). Выкарыстанне двух незалежных камутатараў/Fabric дазволіць выключыць магчымую кропку адмовы.
Прамое падлучэнне хастоў да масіва хоць і падтрымліваецца, але вельмі не рэкамендуецца. Прадукцыйнасць All Flash масіваў дастаткова высокая. І для максімальнай хуткасці патрабуецца задзейнічаць усе парты масіва. Таму наяўнасць хаця б аднаго камутатара паміж хастамі і NeoSapphire™ абавязкова.
Наяўнасць двух партоў у HBA хаста таксама з'яўляецца абавязковым патрабаваннем для дасягнення максімальнай прадукцыйнасці і забеспячэння адмоваўстойлівасці.
У выпадку выкарыстання інтэрфейсу Fibre Channel патрабуецца настройка занавання для выключэння магчымых калізій паміж ініцыятарамі і таргетамі. Зоны будуюцца па прынцыпе "адзін порт ініцыятара - адзін або некалькі партоў масіва".
Калі ж прымяняецца падлучэнне праз iSCSI ў выпадку выкарыстання падзялянага з іншымі сэрвісамі камутатара, то абавязкова неабходна ізаляваць трафік iSCSI ўнутры асобнага VLAN. Таксама вельмі рэкамендуецца ўключыць падтрымку Jumbo Frames (MTU = 9000) для павелічэння памераў пакетаў у сетцы і, тым самым, зніжэння колькасці службовай інфармацыі пры перадачы. Аднак варта памятаць, што для карэктнай працы патрабуецца змяніць параметр MTU на ўсіх кампанентах сеткі па ланцужку "ініцыятар-камутатар-таргет".
Настройка All Flash масіва
Масіў пастаўляецца заказчыкам з ужо сфарміраванымі групамі. . Таму ніякіх дзеянняў па аб'яднанні назапашвальнікаў у адзіную структуру рабіць не трэба. Досыць толькі стварыць тамы патрабаванага памеру і ў неабходнай колькасці.
Для зручнасці прысутнічае функцыянал пакетнага стварэння адразу некалькіх тамоў зададзенага аб'ёму. Па змаўчанні ствараюцца "тонкія" тамы, паколькі гэта дазваляе больш рацыянальна расходаваць даступную прастору захоўвання (у тым ліку дзякуючы падтрымцы Space Reclamation). З пункту гледжання прадукцыйнасці розніца паміж "тонкімі" і "тоўстымі" тамамі не перавышае 1%. Аднак калі патрабуецца "выціснуць усе сокі" з масіва, заўсёды можна сканвертаваць любы "тонкі" том у "тоўсты". Але трэба памятаць, што такая аперацыя незваротная.
Далей застаецца "апублікаваць" створаныя тамы і задаць правы доступу да іх з боку хастоў пры дапамозе ACL (IP адрасы для iSCSI і WWPN для FC) і фізічнага падзелу па партах масіва. Для iSCSI мадэляў гэта робіцца праз стварэньне Target.
Для FC мадэляў публікацыя адбываецца праз стварэнне LUN для кожнага порта масіва.
Для паскарэння працэсу налады хасты можна аб'ядноўваць у групы. Прычым, калі на хасце выкарыстоўваецца шматпартовая FC HBA (што на практыцы часцей за ўсё і адбываецца), то сістэма аўтаматычна вызначае, што парты такой HBA ставяцца да адзінага хасту дзякуючы WWPN, адрозным на адзінку. Таксама для абодвух інтэрфейсаў падтрымліваецца пакетнае стварэнне Target/LUN.
Важнай заўвагай у выпадку выкарыстання інтэрфейсу iSCSI з'яўляецца стварэнне для тамоў адразу некалькіх таргетаў для павелічэння прадукцыйнасці, паколькі чарга на таргеце нельга змяніць, і ён фактычна будзе вузкім месцам.
Настройка хастоў ESXi
З боку ESXi хастоў базавая налада выконваецца па цалкам чаканым сцэнары. Парадак дзеянняў для iSCSI злучэння:
- Дадаць Software iSCSI Adapter (не патрабуецца, калі ён ужо дададзены, або ў выпадку выкарыстання Hardware iSCSI Adapter);
- Стварэнне vSwitch, праз які будзе праходзіць iSCSI трафік, і дабаўленне ў яго фізічных uplink і VMkernal;
- Даданне ў Dynamic Discovery адрасоў масіва;
- Стварэнне Datastore
Некаторыя важныя заўвагі:
- У агульным выпадку, вядома, можна выкарыстоўваць і ўжо існуючы vSwitch, але ў выпадку асобнага vSwitch кіраванне наладамі хаста будзе значна прасцей.
- Неабходна падзяляць Management трафік і iSCSI па асобных фізічных лінках і / або VLAN у пазбяганне праблем з прадукцыйнасцю.
- IP адрасы VMkernal і адпаведных партоў All Flash масіва павінны знаходзіцца ў межах адной падсеткі зноў жа з-за пытанняў прадукцыйнасці.
- Для забеспячэння адмоваўстойлівасці па правілах VMware у vSwitch павінны быць хаця б два фізічных uplink
- Калі выкарыстоўваюцца Jumbo Frames неабходна змяніць MTU і ў vSwitch, і ў VMkernal
- Не лішнім будзе нагадаць, што паводле рэкамендацый VMware для фізічных адаптараў, якія будуць выкарыстоўвацца для працы з iSCSI трафікам, абавязкова неабходна вырабіць наладу Teaming and Failover. У прыватнасці, кожны VMkernal павінен працаваць толькі праз адзін uplink, другі uplink неабходна перавесці ў рэжым unused. Для адмоваўстойлівасці неабходна дадаць два VMkernal, кожны з якіх будзе працаваць праз свой uplink.
VMkernel Adapter (vmk#)
Physical Network Adapter (vmnic#)
vmk1 (Storage01)
Active Adapters
vmnic2
Unused Adapters
vmnic3
vmk2 (Storage02)
Active Adapters
vmnic3
Unused Adapters
vmnic2
Для злучэння праз Fibre Channel ніякіх папярэдніх дзеянняў не патрабуецца. Можна адразу ствараць Datastore.
Пасля стварэння Datastore неабходна пераканацца, што выкарыстоўваецца палітыка Round Robin для шляхоў да Target/LUN як найболей прадукцыйная.
Па змаўчанні наладамі VMware прадугледжвае выкарыстанне дадзенай палітыкі па схеме: 1000 запытаў праз першы шлях, наступныя 1000 запытаў праз другі шлях і т.д. Такое ўзаемадзеянне хаста з двухкантролерным масівам будзе незбалансаваным. Таму рэкамендуемы ўсталяваць параметр Round Robin policy = 1 праз Esxcli/ PowerCLI.
Параметры
Для Esxcli:
- Вывесці даступныя LUN
esxcli storage nmp device list
- Скапіяваць Device Name
- Змяніць Round Robin Policy
esxcli storage nmp psp roundrobin deviceconfig set -type=iops -iops=1 -device="Device_ID"
Большасць сучасных прыкладанняў спраектавана для абмену пакетамі даных вялікага памеру з мэтай максімальнай утылізацыі паласы прапускання і зніжэння нагрузкі на цэнтральны працэсар. Таму ESXi па змаўчанні перадае запыты ўводу/высновы на прыладу захоўвання порцыямі да 32767KB. Аднак для шэрагу сцэнарыяў абмен меншымі порцыямі будзе больш прадукцыйным. У дачыненні да масіваў AccelStor гэта наступныя сцэнары:
- Віртуальная машына выкарыстоўвае UEFI замест Legacy BIOS
- Выкарыстоўваецца vSphere Replication
Для такіх сцэнараў рэкамендуецца змяніць значэнне параметра Disk.DiskMaxIOSize на 4096.
Для iSCSI злучэнняў рэкамендуецца змяніць параметр Login Timeout на 30 (па змаўчанні 5) для падвышэння стабільнасці злучэння і выключыць затрымку пацверджанняў якія перасылаюцца пакетаў DelayedAck. Абедзве опцыі знаходзяцца ў vSphere Client: Host → Configure → Storage → Storage Adapters → Advanced Options для iSCSI адаптара
Досыць тонкім момантам з'яўляецца колькасць выкарыстоўваных тамоў для datastore. Зразумела, што для прастаты кіравання ўзнікае жаданне стварыць адзін вялікі том на ўвесь аб'ём масіва. Аднак наяўнасць некалькіх тамоў і, адпаведна, datastore дабратворна адбіваецца на агульнай прадукцыйнасці (падрабязней аб чэргах крыху ніжэй па тэксце). Таму мы рэкамендуем стварэнне як мінімум двух тамоў.
Яшчэ параўнальна нядаўна VMware раіла абмяжоўваць колькасць віртуальных машын на адным datastore ізноў жа з мэтай атрымаць максімальна магчымую прадукцыйнасць. Аднак цяпер, асабліва з распаўсюджваннем VDI, гэтая праблема ўжо не стаіць так востра. Але гэта не адмяняе даўняга правіла - размяркоўваць віртуальныя машыны, якія патрабуюць інтэнсіўнага IO, па розных datastore. Для вызначэння аптымальнай колькасці віртуалак на адзін том няма нічога лепшага, чым правесці у рамках сваёй інфраструктуры.
Настройка віртуальных машын
Пры наладзе віртуальных машын адмысловых патрабаванняў няма, дакладней яны суцэль пасрэдныя:
- Выкарыстанне максімальна магчымую версію VM (compatibility)
- Акуратней задаваць памер АЗП пры шчыльным размяшчэнні віртуальных машын, напрыклад, у VDI (т.к. па змаўчанні пры старце ствараецца файл падпампоўкі сувымернага з АЗП памеру, што расходуе карысную ёмістасць і аказвае эфект на выніковую прадукцыйнасць)
- Выкарыстоўваць найболей прадукцыйныя па частцы IO версіі адаптараў: сеткавы тыпу VMXNET 3 і SCSI тыпу PVSCSI
- Выкарыстоўваць тып дыска Thick Provision Eager Zeroed для максімальнай прадукцыйнасці і Thin Provisioning для максімальна эфектыўнага выкарыстання прасторы захоўвання
- Па магчымасці абмяжоўваць працу некрытычных да ўводу/высновы машын з дапамогай Virtual Disk Limit
- Абавязкова ўсталёўваць VMware Tools
Заўвагі аб чэргах
Чарга (ці Outstanding I/Os) – гэты лік запытаў уводу/высновы (SCSI каманд), якія чакаюць апрацоўкі ў кожны момант часу ў пэўнай прылады/прыкладанні. У выпадку перапаўнення чаргі выдаецца памылкі QFULL, што ў выніку выяўляецца ў павелічэнне параметра latency. Пры выкарыстанні дыскавых (шпіндзельных) сістэм захоўвання тэарэтычна чым вышэй чарга, тым вышэй іх прадукцыйнасць. Аднак марнатравіць не варта, паколькі лёгка нарвацца на QFULL. У выпадку All Flash сістэм, з аднаго боку, усё некалькі прасцей: бо масіў мае затрымкі на парадкі ніжэй і таму часцей за ўсё не патрабуецца асобна рэгуляваць памер чэргаў. Але з іншага боку, у некаторых сцэнарах выкарыстання (моцны перакос у патрабаваннях да IO для пэўных віртуальных машын, тэсты на максімальную прадукцыйнасць і да т.п.) патрабуецца калі не змяняць параметры чэргаў, то хаця б разумець, якіх паказчыкаў можна дасягнуць, і, галоўнае, якімі шляхамі.
На самім All Flash масіве AccelStor няма ніякіх лімітаў па стаўленні да тамоў або партоў уводу/высновы. Пры неабходнасці нават адзіны том можа атрымаць усе рэсурсы масіва. Адзінае абмежаванне на чарзе маецца ў iSCSI таргетаў. Менавіта па гэтым чынніку вышэй паказвалася неабходнасць у стварэнні некалькіх (у ідэале да 8 шт.) таргетаў на кожны том для пераадолення гэтага ліміту. Таксама паўторым, што масівы AccelStor з'яўляюцца вельмі прадукцыйнымі рашэннямі. Таму трэба задзейнічаць усе інтэрфейсныя парты сістэмы для дасягнення максімальнай хуткасці.
З боку ESXi хаста сітуацыя зусім іншая. Сам хост прымяняе практыку раўнапраўнага доступу да рэсурсаў для ўсіх удзельнікаў. Таму існуюць асобныя чэргі IO да гасцявой АС і HBA. Чэргі да гасцявой АС камбінуюцца з чэргаў да віртуальнага SCSI адаптара і віртуальнай кружэлцы:
Чарга да HBA залежыць ад канкрэтнага тыпу/вендара:
Выніковая прадукцыйнасць віртуальнай машыны будзе вызначацца найменшым значэннем паказчыка чаргі (Queue Depth limit) сярод кампанентаў хаста.
Дзякуючы гэтым значэнням можна ацаніць паказчыкі прадукцыйнасці, якія мы можам атрымаць у той ці іншай канфігурацыі. Напрыклад, мы хочам даведацца тэарэтычную прадукцыйнасць віртуальнай машыны (без прывязкі да блока) з latency 0.5ms. Тады яе IOPS = (1,000/latency) * Outstanding I/Os (Queue Depth limit)
прыклады
Прыклад 1
- FC Emulex HBA Adapter
- Адна VM на datastore
- VMware Paravirtual SCSI Adapter
Тут Queue Depth limit вызначаецца Emulex HBA. Таму IOPS = (1000/0.5) * 32 = 64K
Прыклад 2
- VMware iSCSI Software Adapter
- Адна VM на datastore
- VMware Paravirtual SCSI Adapter
Тут Queue Depth limit вызначаецца ўжо Paravirtual SCSI Adapter. Таму IOPS = (1000/0.5) * 64 = 128K
Топавыя мадэлі All Flash масіваў AccelStor (напрыклад, ) здольныя забяспечваць прадукцыйнасць 700K IOPS на запіс пры блоку 4K. Пры такім памеры блока зусім відавочна, што адзіная віртуальная машына не здольная загрузіць падобны масіў. Для гэтага спатрэбіцца 11 (для прыкладу 1) ці 6 (для прыкладу 2) віртуалак.
У выніку пры правільнай наладзе ўсіх апісаных кампанент віртуальнага датацэнтра можна атрымаць вельмі ўражлівыя вынікі ў плане прадукцыйнасці.
4K Random, 70% Read/30% Write
Насамрэч рэальны свет нашмат складаней, каб апісаць яго простай формулай. На адным хасце заўсёды размешчана мноства віртуальных машын з рознымі канфігурацыямі і патрабаваннямі да IO. Ды і апрацоўкай уводу/высновы займаецца працэсар хаста, магутнасць якога не бясконцая. Так, для раскрыцця поўнага патэнцыялу той жа у рэальнасці спатрэбіцца ад трох хастоў. Плюс прыкладанні, якія працуюць усярэдзіне віртуальных машын, уносяць свае карэктывы. Таму для дакладнага сайзінгу мы прапануем All Flash масіваў унутры інфраструктуры заказчыка на рэальных бягучых задачах.
Крыніца: habr.com