Най-добри практики за стартиране на VMware vSphere на iSCSI
VMware предлага и поддържа редица различни технологии за съхранение и протоколи за представяне на външни устройства за съхранение на VMware vSphere хостове. През последните години протоколът iSCSI придоби популярност като метод за представяне на блокови устройства за съхранение през мрежа на vSphere хостове. VMware предоставя поддръжка за iSCSI съхранение от Virtual Infrastructure 3. Този документ може да ви помогне да разберете съображенията за проектиране и опциите за внедряване за разполагане на vSphere инфраструктури, използващи iSCSI съхранение. Той подчертава компромисите и факторите, които трябва да имате предвид при внедряването на iSCSI хранилище за поддръжка на vSphere среди. Това е допълнение, а не заместител на продуктовата документация на VMware.
iSCSI е протокол, който използва TCP/IP за транспортиране на SCSI команди, което позволява използването на съществуващата TCP/IP мрежова инфраструктура като SAN. Както при SCSI през Fibre Channel (FC), iSCSI представя SCSI цели и устройства на iSCSI инициатори (искатели). За разлика от NAS, който представя устройствата на ниво файл, iSCSI прави блоковите устройства достъпни през мрежата. Блоковите устройства се представят през IP мрежа на вашата локална система. Те могат да се консумират по същия начин като всяко друго блоково устройство за съхранение.
За центрове за данни с централизирано съхранение iSCSI предлага на клиентите много предимства. Той е сравнително евтин и се основава на познатите SCSI и TCP/IP стандарти. В сравнение с FC и Fibre Channel през Ethernet (FCoE) SAN внедрявания, iSCSI изисква по-малко хардуер, използва по-евтин хардуер и повече членове на ИТ персонала може да са запознати с технологията. Тези фактори допринасят за по-ниски разходи за внедряване.
Една основна разлика между iSCSI и FC е свързана с I/O претоварването. Когато пътят на iSCSI е претоварен, протоколът TCP/IP изпуска пакетите и изисква повторното им изпращане. FC комуникацията по специален път има вграден механизъм за пауза, когато възникне задръстване. Когато мрежовият път, пренасящ iSCSI трафик за съхранение, е значително претоварен, лошата ситуация бързо се влошава и производителността допълнително се влошава, тъй като изпуснатите пакети трябва да бъдат изпратени отново. Може да има множество причини за претоварване на iSCSI път, вариращи от свръхабонамент (твърде много трафик) до мрежови комутатори, които имат нисък портов буфер. Въпреки че някои доставчици на iSCSI хранилища са внедрили забавено потвърждение и избягване на задръстванията като част от техния TCP/IP стек, не всички са го направили. Различни доставчици на iSCSI масиви дори препоръчват деактивиране на DelayedAck за iSCSI адаптер. VMware препоръчва да се консултирате с доставчика на iSCSI масив за конкретни препоръки относно DelayedAck. За повече подробности относно този проблем, моля, вижте: https://kb.vmware.com/s/article/1002598
Друго съображение е честотната лента на мрежата. Мрежовата честотна лента зависи от използваните Ethernet стандарти (1Gb или 10Gb). Има и други механизми като агрегиране на портове и връзки за свързване, които осигуряват по-голяма честотна лента на мрежата. Когато внедрявате софтуер iSCSI, който използва мрежови интерфейсни карти, а не специални iSCSI адаптери, са необходими гигабитови Ethernet интерфейси. Тези интерфейси са склонни да консумират значително количество CPU ресурси.
Един от начините за преодоляване на това търсене на CPU ресурси е използването на функция, наречена TOE (TCP/IP разтоварваща машина). TOE прехвърлят задачите за обработка на TCP пакети от процесора на сървъра към специализирани TCP процесори на мрежовия адаптер или устройството за съхранение. Повечето мрежови чипсети на корпоративно ниво днес предлагат TCP разтоварване или разтоварване на контролна сума, което значително подобрява натоварването на процесора.
iSCSI се смяташе за технология, която не работи добре в повечето споделени широкообхватни мрежи. Към него се подхожда предимно като към технология за локална мрежа. Това обаче се променя. За записи при синхронна репликация (в случай на висока достъпност) или отдалечени записи на данни, iSCSI може да не е подходящ. Въвеждането на латентност води до по-големи забавяния при прехвърлянето на данни и може да повлияе на производителността на приложението. Асинхронната репликация, която не зависи от чувствителността към латентност, прави iSCSI идеално решение. Например, VMware vCenter™ Site Recovery Manager™ може да се основава на iSCSI асинхронна репликация за съхранение за проста, надеждна защита на сайта при бедствие.
iSCSI инициаторите трябва да управляват множество, паралелни комуникационни връзки към множество цели. По същия начин целите на iSCSI трябва да управляват множество паралелни комуникационни връзки към множество инициатори. В iSCSI съществуват няколко идентификатора, за да се случи това, включително име на iSCSI, ISID (идентификатори на iSCSI сесия), TSID (идентификатор на целева сесия), CID (идентификатор на iSCSI връзка) и iSCSI портали. Те ще бъдат разгледани в следващия раздел.
iSCSI възлите имат глобално уникални имена, които не се променят при промяна на Ethernet адаптери или IP адреси. iSCSI поддържа два формата на имена, както и псевдоними. Форматът на първото име е разширеният уникален идентификатор (EUI). Пример за име на EUI може да бъде eui.02004567A425678D. Вторият формат на име е iSCSI квалифицирано име (IQN). Пример за име на IQN може да бъде iqn.1998-01. com.vmware:tm-pod04-esx01-6129571c.
Мрежата за съхранение се състои от два типа оборудване: инициатори и цели. Инициаторите, като хостове, са потребители на данни. Цели, като дискови масиви или лентови библиотеки, са доставчици на данни. В контекста на vSphere iSCSI инициаторите попадат в три отделни категории. Те могат да бъдат софтуерно, хардуерно зависими или хардуерно независими.
Софтуерният iSCSI адаптер е VMware код, вграден във VMkernel. Той позволява на вашия хост да се свърже с iSCSI устройството за съхранение чрез стандартни мрежови адаптери. Софтуерният iSCSI адаптер обработва iSCSI обработката, докато комуникира с мрежовия адаптер. Със софтуерния iSCSI адаптер можете да използвате iSCSI технологията, без да купувате специализиран хардуер.
Този хардуерен iSCSI адаптер зависи от мрежата на VMware и интерфейсите за конфигурация и управление на iSCSI, предоставени от VMware. Този тип адаптер може да бъде карта, която представя стандартен мрежов адаптер и функция за разтоварване на iSCSI за същия порт. Функционалността за разтоварване на iSCSI зависи от мрежовата конфигурация на хоста за получаване на IP и MAC адреси, както и други параметри, използвани за iSCSI сесии. Пример за зависим адаптер е iSCSI лицензиран Broadcom 5709 NIC.
Този тип адаптер реализира свои собствени мрежови и iSCSI интерфейси за конфигурация и управление. Пример за независим хардуерен iSCSI адаптер е карта, която представя или само iSCSI разтоварваща функционалност, или iSCSI разтоварваща функционалност и стандартна NIC функционалност. Функционалността за разтоварване на iSCSI има независимо управление на конфигурацията, което присвоява IP адреса, MAC адреса и други параметри, използвани за iSCSI сесиите. Този раздел разглежда характеристиките и проблемите, свързани с всяка от тези технологии.
iSCSI инициаторите и целите използват TCP за създаване на връзки, наречени сесии. Тези сесии се идентифицират чрез iSCSI идентификатори на сесии (ISID). Идентификаторите на сесии не са обвързани с хардуера и могат да се запазят при размяна на хардуер. Инициаторът вижда една логическа връзка с целта, както е показано на фигура 1.
Фигура 1 - iSCSI сесия
Една iSCSI сесия може също да съдържа множество логически връзки. От гледна точка на vSphere хост, сесиите могат също да се разглеждат като пътища между инициатора и целта. Наличието на множество връзки на сесия дава възможност за агрегиране на честотна лента и може също така да осигури балансиране на натоварването. Пример за множество логически връзки към целта (идентифицирани чрез ID на връзката или CID) е показан на Фигура 2.
Фигура 2 - Множество връзки на сесия
Въпреки това, vSphere хост не поддържа множество връзки на сесия в момента.
iSCSI портали - iSCSI възлите следят връзките чрез портали, като позволяват разделяне между имена и IP адреси. Порталът управлява IP адрес и номер на TCP порт. Следователно, от архитектурна гледна точка, сесиите могат да бъдат съставени от множество логически връзки, а порталите проследяват връзките чрез TCP/IP порт/адрес, както е показано на фигура 3.
Фигура 3 - iSCSI портали
В по-ранните версии на vSphere iSCSI драйверът на VMware изпращаше I/O само през един портал (една сесия на връзка) и само когато това се провали, vSphere хостът се опитваше да използва други портали по Round Robin начин.
В по-нови версии това поведение се промени, така че драйверът вече влиза във всички портали, които се връщат в отговора за откриване на SendTarget. Причината за това подобрение беше да се активира поддръжка за нови активни/пасивни iSCSI масиви, които изискват поддръжка. С активни/пасивни масиви се изисква стекът за съхранение на хост vSphere да разпознава всеки от порталите като различни пътища (цели), за да извършва ефективно многопътно прехвърляне на грешки.
ЗАБЕЛЕЖКА: Не всички iSCSI масиви се държат по този начин. Някои масиви все още изискват администратор да добави допълнителни пътища ръчно
VMware поддържа iSCSI както с реализации на софтуерен инициатор, така и с хардуерен инициатор. Софтуерният инициатор iSCSI се включва в стека за съхранение на хост vSphere като драйвер на устройство по същия начин като другите SCSI и FC драйвери. Това означава, че той имплицитно поддържа водещата файлова система на VMware, VMware vSphere VMFS, както и Raw Device Mappings (RDM).
Както споменахме по-рано, хардуерните iSCSI адаптери попадат в две категории – хардуерно зависими и хардуерно независими. Зареждането от iSCSI също се поддържа както за софтуера, така и за хардуера iSCSI. Фигура 4 показва основните разлики между iSCSI хардуер и iSCSI софтуерна реализация.
Считано от vSphere 6.5 iSCSI зареждането също се поддържа в режим на зареждане на UEFI. Имайте предвид, че UEFI BIOS трябва да поддържа iSCSI и че IPv6 не се поддържа към момента на писане.
Фигура 4 - Софтуерни и хардуерни iSCSI инициатори
С внедряването на iSCSI на хардуерен инициатор, iSCSI HBA осигурява превода от SCSI команди в капсулиран формат, който може да бъде изпратен по мрежата. TCP разтоварващ механизъм (TOE) извършва този превод на адаптера.
Внедряването на iSCSI на софтуерния инициатор използва VMkernel за извършване на превода на SCSI към IP и изисква допълнителни цикли на процесора за извършване на тази работа. Както бе споменато по-рано, повечето мрежови набори чипове на корпоративно ниво предлагат разтоварване на TCP или контролна сума, което значително подобрява натоварването на процесора.
Поддържа се активиране както на софтуерния iSCSI, така и на хардуерния iSCSI на един и същ хост. Използването на софтуерни и хардуерни адаптери на един и същ vSphere хост за достъп до една и съща цел обаче не се поддържа. Човек не може да има достъп на хоста до една и съща цел чрез хардуерно зависими/хардуерно независими/софтуерни iSCSI адаптери за целите на множество пътища. Причината за това изявление за поддръжка е, че различните типове адаптери се отнасят предимно до производителност и управление. Например, всеки адаптер може да генерира различни скорости.
Освен това vSphere управлява софтуерните iSCSI адаптери, но хардуерните адаптери имат различни интерфейси за управление.
Накрая, може да има разлики в механизма за разтоварване, при който хардуерните адаптери могат да разтоварват по подразбиране, но за софтуера iSCSI това ще зависи от мрежовата карта. Може да имате или да нямате възможности за разтоварване.
По много начини е подобно на представянето на същия LUN от същия масив чрез iSCSI и FC. Можете да го видите по множество пътища и можете да изпращате I/O към него по множество пътища, но няма да се поддържа поради разликите, подчертани по-рано.
Въпреки това различни хостове може да имат достъп до едно и също iSCSI LUN чрез различни методи. Например, хост 1 може да има достъп до LUN чрез софтуерния iSCSI адаптер на VMware, хост 2 може да има достъп до него чрез хардуерно зависим iSCSI адаптер, а хост 3 може да има достъп до него чрез хардуерно независим iSCSI адаптер.
Дизайнът на мрежата е ключът към осигуряването на работа на iSCSI. В производствена среда гигабитовият Ethernet е от съществено значение за софтуера iSCSI. Хардуерният iSCSI в среда на VMware Infrastructure се внедрява със специални HBA.
iSCSI трябва да се счита за локална технология, а не за широкообхватна технология, поради проблеми със забавянето и проблеми със сигурността. Трябва също да отделите iSCSI трафика от общия трафик. Layer-2 VLAN са особено добър начин за прилагане на това разделяне.
Пазете се от свръхабонамент. Свръх абонамент възниква, когато към дадена система са свързани повече потребители, отколкото могат да бъдат напълно поддържани по едно и също време. Мрежите и сървърите почти винаги са проектирани с известно количество свръхабонамент, като се предполага, че потребителите не всички се нуждаят от услугата едновременно. Ако го направят, закъсненията са сигурни и са възможни прекъсвания. Свръх абонаментът е допустим в локални мрежи с общо предназначение, но не трябва да използвате конфигурация с прекомерен абонамент за iSCSI.
Най-добрата практика е да имате специална LAN за iSCSI трафик и да не споделяте мрежата с друг мрежов трафик. Също така е най-добрата практика да не прекалявате с абонамента за специалната LAN.
Накрая, тъй като iSCSI използва IP мрежата, VMkernel NIC могат да бъдат поставени в групови конфигурации. Препоръката на VMware обаче е да се използва свързване на портове, а не обединяване на NIC. Свързването на портове ще бъде обяснено подробно по-късно в тази статия, но е достатъчно да се каже, че с обвързването на портове iSCSI може да използва възможностите на VMkernel за многопътести, като преход при отказ при грешки на SCSI и политика за кръгови пътища за производителност.
В интерес на пълнотата ще бъдат обсъдени и двата метода. Обвързването на порт обаче е препоръчителната най-добра практика.
Необходима е VMkernel мрежа за IP съхранение и следователно е необходима за iSCSI. Най-добрата практика би била iSCSI трафикът да бъде отделен от другите мрежи, включително мрежите за управление и виртуални машини.
Започвайки с vSphere 6.0, поддръжката за IPv6 беше въведена както за хардуерни iSCSI, така и за софтуерни iSCSI адаптери, използващи статично и автоматично присвояване на IP адреси.
Има няколко налични опции за подобряване на производителността на iSCSI.
10GbE – Това е очевидна опция за начало. Ако можете да осигурите по-голяма тръба, вероятността е да постигнете по-голяма производителност. Разбира се, ако няма достатъчно I/O за запълване на 1GbE връзка, тогава по-голяма връзка няма да ви помогне. Но нека приемем, че има достатъчно виртуални машини и достатъчно хранилища за данни, за да бъде от полза 10GbE. Jumbo рамки – Тази функция може да осигури допълнителна пропускателна способност чрез увеличаване на размера на полезния товар във всеки кадър от MTU по подразбиране от 1500 до MTU от 9000. Въпреки това трябва да бъдете много внимателни и обмислени, ако решите да го приложите. Всички устройства, намиращи се в I/O пътя (iSCSI цел, физически превключватели, мрежови интерфейсни карти и VMkernel портове) трябва да могат да внедряват jumbo frames за тази опция, за да осигурят пълните предимства. Например, ако MTU не е правилно зададен на комутаторите, хранилищата за данни може да се монтират, но I/O няма да успее. Често срещан проблем при конфигурациите на джъмбо рамка е, че стойността на MTU на превключвателя не е зададена правилно. В повечето случаи това трябва да е по-високо от това на хостовете и хранилището, които обикновено са зададени на 9000. Превключвателите трябва да бъдат настроени по-високо, например на 9 198 или 9 216, за да отчетат режийните IP адреси. Обърнете се към документацията на доставчика на превключвателя, както и документацията на доставчика на хранилище, преди да се опитате да конфигурирате jumbo frames. Политика за кръгови пътища – Round Robin използва автоматичен избор на път, който се върти през всички налични пътища, което позволява разпределението на натоварването между конфигурираните пътища. Тази политика на пътя може да помогне за подобряване на I/O пропускателната способност. За активни/пасивни масиви за съхранение само пътищата до активния контролер ще се използват в правилата Round Robin. За активни/активни масиви за съхранение всички пътища ще се използват в правилата Round Robin. За масиви ALUA (присвояване на асиметрични логически единици), Round Robin използва само активните/оптимизирани (AO) пътища. Това са пътищата към диска през управляващия контролер. Активни/неоптимизирани (ANO) пътища към диска през неуправляващия контролер не се използват. Не всички масиви поддържат правилата за кръгов път. Обърнете се към документацията на доставчика на вашия масив за съхранение за препоръки относно използването на тази политика за избор на път (PSP).Тъй като iSCSI на VMware използва TCP/IP за прехвърляне на I/O, латентността може да бъде загриженост. За да намалите латентността, винаги трябва да се опитвате да минимизирате броя на преходите между хранилището и vSphere хоста. В идеалния случай човек не би насочвал трафик между vSphere хоста и масива за съхранение и и двата биха съществували съвместно в една и съща подмрежа.
ЗАБЕЛЕЖКА: Ако обвързванията на iSCSI портове са внедрени за целите на многопътието, не можете да маршрутизирате своя iSCSI трафик преди vSphere 6.5. С vSphere 6.5 се поддържа маршрутизиране на iSCSI трафик със свързване на портове.
vSphere хост има една таблица за маршрутизиране за всеки TCP/IP стек. Това налага някои ограничения върху мрежовата комуникация за интерфейси на VMkernel, използващи същия TCP/IP стек. Помислете за конфигурация, която използва два Ethernet адаптера с един VMkernel TCP/IP стек. Единият адаптер е в 10.17.1.1/24 IP мрежа, а другият в 192.168.1.1/24 мрежа. Да приемем, че 10.17.1.253 е адресът на шлюза по подразбиране. VMkernel може да комуникира с всички сървъри, достъпни от рутери, които използват шлюза 10.17.1.253. Може да не е в състояние да говори с всички сървъри в мрежата 192.168, освен ако и двете мрежи не са в един и същ домейн за излъчване.
Друга последица от единичната таблица за маршрутизиране засяга един подход, който иначе бихте могли да обмислите за балансиране на I/O. Помислете за конфигурация, в която искате да се свържете с iSCSI хранилище и също искате да активирате NFS монтиране. Може да изглежда, че можете да използвате един Ethernet адаптер за iSCSI и отделен Ethernet адаптер за NFS трафик, за да разпределите I/O натоварването. Този подход не работи поради начина, по който TCP/IP стекът на VMkernel обработва записи в таблицата за маршрутизиране.
Например, можете да зададете IP адрес 10.16.156.66 на VMkernel адаптера, който искате да използвате за NFS. След това таблицата за маршрутизиране съдържа запис за мрежата 10.16.156.x за този адаптер. Ако след това настроите втори адаптер за iSCSI и му присвоите IP адрес 10.16.156.25, таблицата за маршрутизиране съдържа нов запис за мрежата 10.16.156.x за втория адаптер. Въпреки това, когато TCP/IP стекът чете таблицата за маршрутизиране, той никога не достига до втория запис, тъй като първият запис удовлетворява всички маршрути към двата адаптера. Следователно никакъв трафик никога не излиза в iSCSI мрежата и целият трафик на IP хранилище излиза в NFS мрежата.
Фактът, че целият трафик на 10.16.156.x се насочва в NFS мрежата, причинява два вида проблеми. Първо, не виждате никакъв трафик на втория Ethernet адаптер. Второ, ако се опитате да добавите доверени IP адреси както към iSCSI масиви, така и към NFS сървъри, трафикът към единия или другия идва от грешен IP адрес.
Както споменахме по-горе, за vSphere хостове, мрежата за управление е на VMkernel порт и следователно използва VMkernel шлюза по подразбиране. Само един VMkernel шлюз по подразбиране може да бъде конфигуриран на vSphere хост на TCP/IP стек. Можете обаче да добавите статични маршрути от командния ред или да конфигурирате шлюз за всеки отделен VMkernel порт.
Настройването на шлюз на детайлно ниво за порт на VMkernel е въведено във vSphere 6.5 и позволява малко повече гъвкавост. Шлюзът за порт на VMkernel може просто да бъде дефиниран с помощта на vSphere Web Client по време на създаването на интерфейса на VMkernel. Също така е възможно да го конфигурирате с помощта на esxcli.
Забележка: Към момента на писане използването на персонализиран TCP/IP стек не се поддържа за iSCSI!
За постигане на висока достъпност, локалната мрежа (LAN), по която се изпълнява iSCSI трафикът, трябва да бъде проектирана с достъпност, избягване на престой, изолация и без единична точка на повреда (SPOF) в ума. Множество администратори трябва да участват в проектирането за висока наличност. Това са администраторът на виртуализацията и мрежовият администратор (и може би администраторът на хранилището). Този раздел очертава тези стъпки и проучва няколко опции, които могат да бъдат използвани, за да направите вашите iSCSI хранилища за данни изключително достъпни.
И в двата случая по-долу са необходими поне две мрежови интерфейсни карти. Докато 1Gb интерфейси ще отговорят на изискванията за високо достъпна мрежа, 10Gb мрежови адаптери също ще подобрят производителността.
Най-добрата практика за iSCSI е да се избягва функцията vSphere, наречена обединяване (на мрежовите интерфейсни карти) и вместо това да се използва обвързване на порт. Свързването на портове въвежда множество пътища за наличност на достъп до iSCSI цели и LUN. Ако по някаква причина това не е подходящо, тогава екипирането може да бъде алтернатива.
Ако планирате да използвате обединяване, за да увеличите наличността на вашия мрежов достъп до iSCSI масива за съхранение, трябва да изключите защитата на порта на превключвателя за двата порта, на които се споделя виртуалният IP адрес. Целта на тази настройка за сигурност на порта е да предотврати подправяне на IP адреси. Затова много мрежови администратори разрешават тази настройка. Ако обаче не го промените, настройката за сигурност на порта предотвратява прехвърлянето на виртуалния IP от един порт на комутатора към друг и обединяването не може да превключи от един път към друг. За повечето LAN комутатори защитата на портовете е активирана на ниво порт и по този начин може да бъде включена или изключена за всеки порт.
Друг начин за постигане на наличност е да се създаде конфигурация с множество пътища. Това е по-предпочитан метод пред обединяването на NIC, тъй като този метод ще се провали през I/O към алтернативни пътища въз основа на SCSI сензорни кодове, а не само мрежови повреди. Освен това обвързването на портове дава възможност на администраторите да балансират входно/изходното натоварване по множество пътища към устройството за съхранение. Допълнителни предимства около обвързването на порт ще бъдат обсъдени по-късно в този документ.
iSCSI заглавката и обобщенията на данните проверяват цялостността на некриптографските данни от край до край извън проверките за целостта, които предоставят други мрежови слоеве, като TCP и Ethernet. Те проверяват целия комуникационен път, включително всички елементи, които могат да променят трафика на мрежово ниво, като рутери, комутатори и проксита.
Активирането на обобщени заглавки и данни изисква допълнителна обработка както за инициатора, така и за целта и може да повлияе на пропускателната способност и използването на процесора.
Някои системи могат да разтоварят iSCSI обобщените изчисления към мрежовия процесор, като по този начин намаляват въздействието върху производителността.
Общият консенсус от нашите партньори за съхранение е, че хардуерно базираният контрол на потока се препоръчва за всички мрежови интерфейси и комутатори.
С обвързването на портове протоколът SCSI не само ще балансира натоварването между всички обвързани портове и ще премине към други обвързани портове при повреда на връзката, но също така ще използва грешки в SCSI сензорния код за задействане и на отказ. Когато не използвате Port Binding, вие разчитате на vSphere и мрежовия стек, за да определите най-добрия път, който да използвате за iSCSI трафик. Ако пътищата не са ясно дефинирани, могат да възникнат други проблеми, като по-дълго време за сканиране и непоследователна свързаност. Това не винаги е така, но трябва да се вземе предвид.
Надеждното съхранение винаги трябва да бъде ваш приоритет. Този преглед е една от най-надеждните и често срещани конфигурации за iSCSI. Няколко ключови конфигурации за тази настройка са вашите виртуални инфраструктурни VMkernels за iSCSI съхранение са в същата VLAN/подмрежа като вашия масив за съхранение, а контролерите за масив за съхранение също са в същата подмрежа/VLAN.
За простота, да кажем, че всеки vSphere хост има две 25Gb NIC (NIC0, NIC1) и вие използвате SW iSCSI адаптер. SW iSCSI адаптерите са най-често срещаните адаптери, използвани във vSphere среди и са в състояние да постигнат скорост, близка до линията. С модерните процесори минималните разходи на SW iSCSI се справят лесно. Това също намалява сложността, тъй като вече не трябва да поддържате HBA и техния фърмуер.
Първо, трябва да конфигурирате вашите виртуални комутатори и VMkernels. Трябва да има портгрупа и VMkernel за винаги NIC, който да се използва за iSCSI. Конфигурацията е подобна за стандартен или разпределен vSwitch, като разликата е дали конфигурирате на всеки хост или на vCenter. За този пример ще трябва да настроите две групи портове със специфични конфигурации за обединяване за всяка NIC. Всяка портова група на dVS или при настройване на VMkernel на стандартен vSwitch трябва да бъде настроена както следва, за да поддържа обвързване на порт.
За разпределен превключвател: първо създавате групите портове, а след това създавате VMkernel и го свързвате с конкретна група портове.
За стандартен превключвател: Първо създавате VMkernel, Portgroup се създава автоматично, след което влизате в свойствата на всяка портгрупа на VMkernel и променяте настройките за Teaming и failover.
Когато конфигурирате Teaming и failover, може да се наложи да поставите отметка на Override, за да промените настройката, различна от vSwitch по подразбиране. За да можете да използвате обвързване на порт, трябва да има само един активен NIC в конфигурацията на VMkernel/portgroup. Ако има мрежова карта в режим на готовност, вместо неизползвана, няма да можете да свържете това VMkernel към iSCSI.
iSCSI-P1
iSCSI-P2
Балансиране на натоварването
Използвайте изричен ред при отказ
Балансиране на натоварването
Използвайте изричен ред при отказ
Откриване на грешка в мрежата
Само състояние на връзката
Откриване на грешка в мрежата
Само състояние на връзката
Отказ
Не
Отказ
Не
Активна връзка нагоре
Връзка 1
Активна връзка нагоре
Връзка 2
Връзка в режим на готовност
Няма
Връзка в режим на готовност
Няма
Неизползвана връзка нагоре
Връзка2
Неизползвана връзка нагоре
Връзка 1
Разпределен vSwitch
Стандартен vSwitch
Свойства на VMkernel:
Забележете, че единствената разлика между двете VMkernels е коя NIC връзка нагоре е активна и IP.
Сега можете да конфигурирате своя SW iSCSI адаптер чрез обвързване на порт. Изберете вашия iSCSI адаптер и изберете раздела Свързване на мрежовия порт, ще забележите, че няма обвързани портове. Кликнете върху +Добавяне.
Тук можете да видите предварително конфигурираните VMkernels. Ако VMkernels не са конфигурирани правилно, те няма да се показват като налични. Отбележете и двете и щракнете върху OK.
След като щракнете върху OK, портовете на VMKernel ще бъдат свързани към SW iSCSI адаптера. Също така ще ви препоръча да направите повторно сканиране на този адаптер. Щракнете върху Повторно сканиране
Когато вашите VMkernels са правилно конфигурирани да използват конкретна NIC и вашите Vmkernels са свързани към вашия SW iSCSI адаптер, можете да продължите с добавяне на цели от вашия масив. Уверете се, че сте добавили iSCSI инициатора към вашия масив/LUN, които искате да бъдат достъпни от хоста. Няма да преминаваме през този процес, тъй като той е различен за всеки доставчик и масив.
Можете да добавяте цели в разделите Динамично откриване или Статично откриване. За тази дискусия изберете Динамично откриване и щракнете върху +Добавяне.
Въведете целия IP адрес за откриване на вашия масив и щракнете върху OK. Отново ще бъде препоръчително да сканирате отново адаптера, за да откриете целите. След повторното сканиране отидете в раздела Устройства и трябва да видите всички цели или LUN, които сте конфигурирали да бъдат достъпни от този SW iSCSI инициатор. След повторното сканиране вашите устройства ще се покажат в раздела устройство и вече са налични. Ако това е VMFS LUN, вече можете да създадете вашето VMFS хранилище за данни. Ако е vVols LUN, той може да има 512B, 1MB, с размер 1GB, варира между производителите. Този LUN не е директно предоставен, той е крайната точка на протокола за vVols и се използва с доставчика на VASA за настройка на IO пътя за всеки vVol. За повече информация относно vVols, моля, посететеcore.vmware.com
Сега, след като разгледахме най-лесната и често срещана конфигурация за обвързване на iSCSI порт, нека прегледаме някои други конфигурации.
Поддържани конфигурации за обвързване на порт:
Единичен vSwitch, VMkernerl портове в една и съща подмрежа/VLAN като контролери за масиви за съхранение VMKernels в една подмрежа/VLAN, контролери за съхранение в една отделна подмрежа/VLANНеподдържани конфигурации за свързване на портове:
Масивни контролери в различни подмрежи/VLAN Изисква отделен vSwitch за всяко VMKerneliSCSI маршрутизиране под vSphere 6.5За повече подробности относно конфигурациите за обвързване на порт вижте страницата с iSCSI ресурси на core.vmware.com
Следните елементи съдържат списък със съображения от гледна точка на сигурността при внедряването на iSCSI.
iSCSI трафикът за съхранение се предава в некриптиран формат през LAN. Следователно се счита за най-добра практика iSCSI да се използва само в надеждни мрежи и да се изолира трафикът на отделни физически комутатори или да се използва частна VLAN. Всички доставчици на iSCSI-масиви са съгласни, че е добра практика да се изолира iSCSI трафик от съображения за сигурност. Това би означавало изолиране на iSCSI трафика на собствени отделни физически комутатори или използване на специална VLAN (IEEE 802.1Q).
ISCSI поддържа няколко вида защита. IPSec (Internet Protocol Security) е развиващ се стандарт за сигурност в мрежата или слоя за обработка на пакети на мрежова комуникация. IKE (Internet Key Exchange) е IPSec стандартен протокол, използван за осигуряване на сигурност за VPN. Стартиране на vSphere 6.0 IPSec се поддържа на vSphere хост с помощта на IPv6 и софтуера vSphere iSCSI Adapater. Имайте предвид, че активирането на IPSec за интерфейса iSCSI най-вероятно ще има въздействие върху производителността. Не е извършено изпитване на ефективността, тъй като не може да се даде индикация за въздействието. Моля, тествайте въздействието върху вашето работно натоварване и I/O профил. VMware предпочита използването на удостоверяване в комбинация с напълно изолиран мрежов сегмент пред криптиране.
Има и редица методи за удостоверяване, поддържани с iSCSI.
KerberosSRP (сигурна отдалечена парола)SPKM1/2 (прост механизъм за публичен ключ)CHAP (протокол за удостоверяване на ръкостискане при предизвикателство)По време на писането на това писмо (vSphere 6.5), vSphere хост не поддържа Kerberos, SRP или публичен ключ методи за удостоверяване за iSCSI. Единственият поддържан протокол за удостоверяване е CHAP. CHAP проверява самоличността с помощта на хеширано предаване. Целта инициира предизвикателството. И двете страни знаят тайния ключ. Периодично повтаря предизвикателството, за да се предпази от повторни атаки. CHAP е еднопосочен протокол, но може да бъде приложен в две посоки, за да осигури сигурност и за двата края. Спецификацията iSCSI дефинира метода за защита CHAP като единствен протокол, който трябва да се поддържа. Реализацията на VMware използва тази опция за сигурност.
Преди vSphere хост да може да използва iSCSI съхранение, трябва да се предприемат следните стъпки за конфигуриране:
Създайте нова група портове на VMkernel за IP съхранение на вече съществуващ виртуален комутатор (vSwitch) или на нов vSwitch, когато е конфигуриран. vSwitch може да бъде vSphere Standard Switch (VSS) или VMware vSphere Distributed Switch™. Уверете се, че iSCSI инициаторът на vSphere хоста(ите) е активиран. Уверете се, че iSCSI хранилището е конфигурирано да експортира LUN, достъпен до vSphere хоста iSCSI инициатори в доверена мрежа.За мрежова свързаност потребителят трябва да създаде нова група портове на VMkernel, за да конфигурира vSwitch за достъп до IP съхранение. Потребителят трябва също така да попълни информацията за достъп до мрежата, включително всеки VLAN таг, свързан с мрежата за съхранение.
Фигура 5 - Настройки за свързване на VMkernel
За да активирате iSCSI инициатора, трябва също да се добавят допълнителни подробности като IP адреса на целевия масив и всички идентификационни данни, свързани с CHAP.
Фигура 6 - Активиране на софтуерен iSCSI адаптер
На този етап може също да се добавят подробности за обвързване на портове за целите на множество пътища.
Основният случай на използване на тази функция е да се създаде многопътна конфигурация със съхранение, което представя само един портал за съхранение, като решенията DELL EqualLogic и HP StoreVirtual iSCSI. Без iSCSI multipathing, този тип съхранение ще има само един път между vSphere хоста и всеки том. iSCSI multipathing ни позволява да извършваме многопътево към този тип клъстерно хранилище.
Друго предимство е възможността за използване на алтернативни VMkernel мрежи извън мрежата за управление на vSphere хост. Това означава, че ако мрежата за управление претърпи прекъсване, вие продължавате да имате iSCSI свързаност през VMkernel портовете, участващи в iSCSI свързванията.
ЗАБЕЛЕЖКА: VMware счита внедряването на iSCSI multipathing (Port Binding) през NIC teaming като най-добра практика.
В този пример ние конфигурираме софтуерен iSCSI адаптер, vmhba32. На този етап не са добавени цели, така че не са открити устройства или пътища. Преди да внедрите софтуерните iSCSI обвързвания, трябва да създадете редица допълнителни VMkernel портове (vmk) за обвързване на порт към софтуерния iSCSI адаптер.
Фигура 7 - Единичен VSS с два VMkernel порта
За да работи свързването на портове правилно, инициаторът трябва да може да достигне до целта директно в същата подмрежа преди vSphere 6.5 – свързването на iSCSI портове поддържа маршрутизиране само във vSphere 6.5. В тази конфигурация, ако поставите VMkernel портове на VLAN 74, те могат да достигнат до iSCSI целта, без да е необходимо да маршрутизират. Това е важен момент и изисква допълнително уточняване, защото предизвиква известно объркване. Ако не внедрите обвързване на порт и използвате стандартен VMkernel порт, тогава инициаторът може да достигне до целите чрез маршрутизирана мрежа, независимо от версията на vSphere. Това се поддържа и работи добре. Само когато iSCSI свързването е внедрено преди vSphere 6.5, се изисква директна, немаршрутизирана мрежа между инициаторите и целите. С други думи, инициаторите и целите трябва да са в една и съща подмрежа.
Има още един важен момент, който трябва да се отбележи, когато става въпрос за конфигурацията на обвързвания на iSCSI портове. На стандартните превключватели на VMware, които съдържат множество vmnic връзки нагоре, всеки VMkernel (vmk) порт, използван за iSCSI свързвания, трябва да бъде свързан с една vmnic връзка нагоре. Другата(ите) връзка(и) на vSwitch трябва да бъде поставена в неизползвано състояние. Това е изискване само когато има множество vmnic връзки нагоре на един и същ vSwitch. Ако използвате множество VSS с техните собствени vmnic връзки нагоре, това не е проблем.
Продължавайки с мрежовата конфигурация, се създава втори VMkernel (vmk) порт. Сега има два vmk порта, означени като iSCSI-01 и iSCSI-02. Те ще се използват за конфигурация за обвързване на iSCSI порт/мултипътиране. Следващата стъпка е да конфигурирате обвързванията и целите на iSCSI. Това се прави в свойствата на софтуерния iSCSI адаптер, който може да се намери на vSphere хоста под „Конфигуриране >> Адаптери за съхранение >> iSCSI софтуерен адаптер”. В този раздел щракнете върху „Свързване на мрежовия порт“, последвано от зеления знак плюс.
Фигура 8 - Свързване на мрежов порт
След като изберете VMkernel адаптерите за използване със софтуерния iSCSI адаптер, разделът Port Group Policy ще ви каже дали тези адаптери са съвместими или не за обвързване. Ако имате повече от една активна връзка нагоре на vSwitch, който има множество vmnic връзки нагоре, vmk интерфейсите няма да се показват като съвместими. Само една връзка нагоре трябва да е активна. Всички други връзки нагоре трябва да бъдат поставени в неизползвано състояние.
Следващата стъпка е да продължите към раздела Цели, където вече могат да се добавят целите на iSCSI. Тъй като се използва свързване на портове, iSCSI целите трябва да бъдат достъпни от софтуерния iSCSI адаптер през немаршрутизираща се мрежа, ако версията на vSphere е по-стара от 6.5. С други думи, портовете на контролера за съхранение са в същата подмрежа като NIC на VMkernel.
В този момент има два VMkernel порта, свързани към софтуерния iSCSI адаптер и свързани към iSCSI цел или цели (които всъщност са контролери на масиви). Всички тези цели отиват към един и същ масив за съхранение, така че LUN, представен на всички цели, ще бъде видим в множество пътища.
След като добавите целта, уверете се, че сте сканирали отново iSCSI софтуерния адаптер, така че всички цели, устройства и всички пътища до устройствата да могат да бъдат открити.
Фигура 9 – Добавяне на цел
Оразмеряването на томовете обикновено е пропорционално на броя виртуални машини, които се опитвате да внедрите, в допълнение към моментните снимки/променените блокове, създадени за целите на архивирането. Друго съображение е, че много масиви имат функции за дедупликация и компресия, което също ще намали изискванията за капацитет. Последно съображение е целта за точка на възстановяване (RPO) и целта за време за възстановяване (RTO). Те определят колко бързо можете да възстановите вашето хранилище за данни с текущата ви платформа за архивиране. Когато се вземат предвид размерите на тома, типът носител в масива. Например, масив с въртяща се медия се нуждае от повече шпиндели за производителност и обикновено се препоръчва да има повече хранилища за данни с по-малък размер. Обратно, един изцяло флаш масив има много производителност и обикновено се препоръчва да има по-малко, по-големи хранилища за данни.
Нещо друго, за което трябва да помислите, е, че ако използвате vVols за вашето хранилище за данни, тогава ще имате само едно vVols хранилище за данни. За повече информация относно vVols вижте Началното ръководство за vVols
Всеки доставчик на хранилища има свои собствени препоръки за оразмеряване и мащабиране на iSCSI LUN. VMware препоръчва да следвате най-добрите практики на доставчика на хранилище, за да осигурите оптимална производителност.
Този параметър не може да се настройва в по-голямата си част. Някои доставчици имат твърда настройка на 4KB, а други - 8KB. Размерите на блоковете обикновено са кратни на 4KB. Те се подравняват добре с размера на зърното от 4KB, използван във формата VMDK на VMware. За тези доставчици, които са го настроили на 8KB, препоръката е да форматират томовете в операционната система за гост (OS) до съответстващ размер на блока от 8KB за оптимална производителност. В тази област е най-добре да говорите с доставчика на вашия масив за съхранение, за да получите съвети за конкретния доставчик.
Въпросите, които човек трябва да зададе, са следните:
Какъв е размерът на обемния блок на масива? Може ли да се настройва? Ако е така, на какво трябва да го настроя? Не забравяйте да обясните, че хранилището за данни ще се използва от виртуални машини, така че работното натоварване ще бъде произволно в по-голямата си част. Има ли някакви съображения при форматирането на томовете в операционната система за гости?VMware представи поддръжка за iSCSI с ESX 3.x. Въпреки това, ESX може да стартира само от iSCSI LUN, ако е използван хардуерен iSCSI адаптер. Хостовете не можаха да стартират чрез софтуерния iSCSI инициатор на VMware. Във vSphere 4.1 VMware въведе поддръжка, която прави възможно зареждането на хоста от iSCSI LUN чрез софтуерния iSCSI адаптер. Това включва поддръжка както за наследен BIOS, така и за UEFI режим.
Не всички наши партньори за съхранение поддържат зареждане на iSCSI Boot Firmware Table (iBFT) от SAN. Обърнете се към собствената документация на партньора за пояснение.
Бързо стана ясно, че има нужда от стартиране чрез софтуер iSCSI. Партньорите на VMware разработваха блейд шасита, съдържащи блейд сървъри, съхранение и мрежова връзка в един шкаф. Ножовете обикновено бяха без дискове, без локално съхранение. Изискването беше блейд сървърите да стартират от iSCSI LUN с помощта на мрежови интерфейсни карти с iSCSI възможности, вместо да използват специални хардуерни iSCSI инициатори.
Голяма част от конфигурацията за зареждане чрез софтуер iSCSI се извършва чрез настройките на BIOS на мрежовите интерфейсни карти и хоста. Проверете VMware Hardware Compatibility List (HCL), за да се уверите, че мрежовата интерфейсна карта е съвместима. Това е важно, но е необходима предпазливост. Ако изберете конкретна мрежова интерфейсна карта и видите iSCSI като функция, може да приемете, че можете да я използвате за зареждане на vSphere хост от iSCSI LUN. Това не е така.
За да видите дали определена мрежова интерфейсна карта се поддържа за iSCSI зареждане, задайте типа I/O устройство на Мрежа (не iSCSI) в HCL и след това проверете бележките под линия. Ако в бележките под линия е посочено, че iBFT се поддържа, тогава тази карта може да се използва за зареждане от iSCSI.
След като се провери дали мрежовата интерфейсна карта се поддържа, следващата стъпка е да влезете в BIOS на мрежовата интерфейсна карта и да се уверите, че тя е активирана за iSCSI зареждане . Следва конфигурацията на мрежовата интерфейсна карта. Например, ако сте планирали да стартирате от софтуер iSCSI с мрежова интерфейсна карта Broadcom NetXtreme, това идва с агент за стартиране, софтуерната помощна програма Multi-Boot Agent (MBA) на Broadcom. Този агент позволява на хоста да изпълни процес на зареждане, използвайки изображения от отдалечени сървъри, включително iSCSI цели. В менюто за конфигурация на MBA iSCSI трябва да бъде избран като протокол за зареждане. Ако iSCSI не е наличен като протокол за зареждане, това може да означава, че iSCSI фърмуерът не е инсталиран или че iSCSI не е активиран на мрежовата интерфейсна карта. Обърнете се към документацията на доставчика на вашата мрежова интерфейсна карта за допълнителна информация.
Има редица различни параметри за конфигуриране. Когато правите първоначалната инсталация, Boot to iSCSI Target също трябва да бъде оставена Disabled. Трябва да го промените на Enabled за следващи зареждания.
В секцията с параметри на инициатора можете да въведете стойности за IP адреса, подмрежовата маска, шлюза по подразбиране, първичния DNS и вторичния DNS параметри на инициатора, ако е необходимо. Ако се изисква удостоверяване, трябва да се въведат CHAP ID (Challenge Handshake Authentication Protocol ID) и тайните параметри на CHAP.
В секцията с целеви параметри можете да въведете стойности за целевия IP адрес, целево име и информация за вход. Ако се изисква удостоверяване, тогава отново трябва да се въведат параметрите CHAP ID и CHAP secret.
ЗАБЕЛЕЖКА: Boot LUN ID (LUN на целта, който се използва за инсталацията на vSphere хост и последващи зареждания) също трябва да бъде конфигуриран.
Излезте и запазете, за да завършите конфигурацията на BIOS. Докато тази последователност от стъпки е за софтуерната помощна програма Broadcom MBA, трябва да се предприеме подобен набор от стъпки за други мрежови интерфейсни карти. Вече сме готови да инсталираме vSphere хост на iSCSI LUN чрез софтуерния iSCSI инициатор.
След като конфигурирате MBA параметрите в мрежовата интерфейсна карта на Broadcom, вече можете да продължите с инсталирането на vSphere хоста. Инсталационният носител се поставя в CD-ROM или се предоставя чрез друг метод в BIOS на хоста (например виртуален носител). Следващата стъпка е да се уверите, че контролерът за зареждане/редът на устройствата е зададен правилно в BIOS. За мрежови интерфейсни карти мрежовият адаптер трябва да се появи преди CD-ROM в реда на зареждане.
За да опростите процедурата за зареждане от iSCSI, уверете се, че LUN за зареждане първоначално е картографиран по един път само към vSphere хоста. Друга препоръчителна стъпка е да свържете LUN id 0 към хоста. Въпреки че това изискване се променя от масив за съхранение на масив за съхранение, по-лесно е просто да следвате тази инструкция, вместо да се консултирате с документацията на доставчика на масива за съхранение, за да определите дали е необходимо или не.
Когато хостът е включен, системният BIOS зарежда OptionROM кода на мрежовата интерфейсна карта и започва да го изпълнява. OptionROM съдържа код за стартиране и фърмуер на iSCSI инициатора. Фърмуерът на iSCSI инициатора установява iSCSI сесия с целта.
При стартиране трябва да се наблюдава успешно влизане в целта, преди да започне инсталирането. Ако получите грешка в този момент, трябва да прегледате стъпките за конфигуриране, направени преди това. Инсталацията сега започва.
Като част от инсталационния процес първо се зарежда VMkernel без състояние само за памет. Това трябва да открие подходящи LUN за инсталиране, едно от които е iSCSI LUN. Въпреки това, за да може iSCSI драйверът на VMkernel да комуникира с целта, той изисква TCP/IP протоколът да бъде настроен. Всичко това се прави като част от началния скрипт при стартиране. OptionROM на мрежовата интерфейсна карта също е отговорен за предаването на данните за инициатор и целева конфигурация към VMkernel. Протоколът за прехвърляне е iBFT. След като е настроена необходимата мрежа, се установява iSCSI сесия към целта, конфигурирана в iBFT. LUN под целите се откриват и регистрират с VMkernel SCSI stack (PSA).
Ако всичко е успешно по време на първоначалната инсталация, iSCSI LUN се предлага като дестинация за vSphere хост изображението. Вече можете да завършите инсталацията на vSphere хост нормално.
След като инсталацията приключи, е необходима една промяна на конфигурацията на iSCSI в конфигурацията на iSCSI. Отново, използвайки Broadcom NetXtreme като пример, целта Boot to iSCSI е зададена на Enabled. Когато хостът се рестартира, той ще стартира vSphere хоста от iSCSI LUN чрез софтуерния iSCSI инициатор.
Този параграф съдържа списък с елементи, които трябва да бъдат проверени в случай, че възникнат проблеми при зареждане от iSCSI.
Уверете се, че мрежовата интерфейсна карта е на HCL за iSCSI зареждане. Не забравяйте да проверите бележките под линия. Уверете се, че вашето устройство има версия на фърмуера, която поддържа iSCSI зареждане и че конфигурационните настройки на iSCSI за инициатор и цел са валидни. Проверете екрана за влизане, за да се уверите, че вашият инициатор може да влезе в целта. Ако направите промени във физическата мрежа, те трябва да бъдат отразени в iBFT. И накрая, CLI командата, esxcli iscsi ibftboot get, показва стойностите за зареждане на iBFT.Този раздел предоставя списък с допълнителни съображения, които трябва да имате предвид.
Това не е препоръка, специфична за iSCSI, тъй като също може да има неблагоприятен ефект върху производителността на цялото блоково хранилище. Независимо от това, за да се отчете всеки непредвиден случай, трябва да се счита за най-добра практика дяловете на операционната система за гости, работещи с виртуалната машина, да са подравнени към хранилището. Подробните описания на начина за извършване на това подравняване са извън обхвата на тази бяла книга. Обърнете се към документацията на вашия индивидуален доставчик на масив за съхранение за повече подробности.
Започвайки с пускането на vSphere 5.1, VMware поддържа до пет възела в Microsoft Cluster. Към момента на писане това все още е поддържаният максимум, дори и с vSphere 6.x. Освен това, от vSphere 5.5, VMware поддържа клъстерния кворум диск през iSCSI протокола. За най-новите подробности вижте https://kb.vmware.com/kb/2147661
Налични са редица софтуерни решения за iSCSI за гости. iSCSI драйверът на Microsoft е такъв, който често се вижда работещ във виртуална машина, когато операционната система за гости е версия на Microsoft Windows. Подкрепящото изявление за този драйвер може да бъде намерено в статия 1010547 от KB, която гласи, че „ако срещнете проблеми със свързването, използвайки iSCSI инициатор на софтуер на трета страна към устройството за съхранение на трета страна, ангажирайте доставчиците на трети страни за помощ. Ако доставчиците трети страни определят, че проблемът се дължи на липса на мрежова свързаност към виртуалната машина, свържете се с VMware за помощ при отстраняване на неизправности.“
Всички пътища надолу (APD) могат да възникнат на vSphere хост, когато устройство за съхранение бъде премахнато по неконтролиран начин или ако устройството се повреди и стекът за съхранение на ядрото на VMkernel не може да определи колко дълго ще продължи загубата на достъп до устройството. Един възможен сценарий за състояние на APD е повреда на FC превключвател, която отстранява всички пътища за съхранение или, в случай на iSCSI масив, проблем с мрежовата свързаност, който по подобен начин отстранява всички пътища за съхранение.
Друго състояние, което може да възникне, е постоянна загуба на устройство (PDL). Условието PDL позволява на vSphere хоста да предприеме конкретни действия, когато се установи, че загубата на устройство е постоянна. Хостът vSphere може да бъде информиран за PDL ситуация чрез специфични SCSI сензорни кодове, изпратени от целевия масив.
vSphere също поддържа PDL откриване за тези масиви, които имат само един LUN на цел. За тези iSCSI масиви, които имат единичен LUN за цел, се прави опит за влизане отново в целта след прекратена сесия. Ако има PDL условие, системата за съхранение отхвърля усилието за достъп до устройството. В зависимост от начина, по който масивът отхвърля опитите за достъп до LUN, vSphere хостът може да определи дали устройството е загубено за постоянно (PDL) или е временно недостъпно.
След като LUN бъде декларирано, че е в APD или PDL състояние, хостът на vSphere може да спре засегнатите виртуални машини и да накара vSphere HA да рестартира тези работни натоварвания на хостове, които все още имат достъп до хранилището за данни. Моля, направете справка с Ръководството за наличност на vSphere за повече подробности как да конфигурирате защитата на VM компонент (VMCP)
VMware идентифицира проблем с определени операционни системи за гости на Linux. RHEL 5 (GA), RHEL 4 U4, RHEL 4 U3, SLES 10 (GA) и SLES 9 SP3 може да имат техните файлови системи да станат само за четене в случай на натоварен I/O повторен опит или прехвърляне на пътя при отказ на SAN на ESXi хоста или iSCSI хранилище. Тази грешка в ядрото на Linux е коригирана в различни актуализации на различните дистрибуции на Linux. Вижте VMware KB статия 51306 за повече подробности.
Редица наши партньори са документирали, че ако използват правилата за кръгови пътища, най-добри резултати могат да бъдат постигнати с настройка IOPS=1. Това може да е вярно в много малки среди, където има малък брой виртуални машини и малък брой хранилища за данни. Въпреки това, тъй като средата се мащабира с по-голям брой виртуални машини и по-голям брой хранилища за данни, VMware счита, че настройките по подразбиране, свързани с политиката за пътя Round Robin, са достатъчни. Консултирайте се с доставчика на вашия масив за съхранение за съвет относно тази настройка.
В vSphere 6.7 VMware въведе нова политика Round Robin, базирана на латентността, която интелигентно оценява всички пътища и избира най-добрия път(и) за използване въз основа на работна средна стойност. За повече информация вижте статията за обявяване тук.
vSphere хостовете не поддържат iSCSI свързани лентови устройства.
Този раздел включва заключението, в допълнение към признателността и няколко реда за автора.
iSCSI вече е изключително популярен протокол за съхранение, намиращ се във vSphere инфраструктурите. Тази бяла книга обединява различни различни части от знания и документация за клиенти на VMware, които обмислят внедряване на iSCSI или вече са внедрили iSCSI и търсят някои най-добри практики. Този документ трябва да се използва заедно с документацията, налична от нашите партньори за масиви за съхранение.
Filter Tags StoragevSphere 6.5vSphere 6.7vSphere 7DocumentDeep DiveOperational TutorialReference ArchitectureIntermediateAdvancedDeployManageMigratePREV: Средната цена за наемане на процесорен сървър | Bizfluent
![[Решен] Не може да се свърже с MySql сървър на localhost (10061) (Вижте темата) * Форум на общността на Apache OpenOffice](http://website-google-hk.oss-cn-hongkong.aliyuncs.com/drawing/26/2022-3-1/7051.jpeg "[Решен] Не може да се свърже с MySql сървър на localhost (10061) (Вижте темата) * Форум на общността на Apache OpenOffice")
