Бележки виртуална администратор февруари 2018
В този пост ще разгледаме две различни технологии vSphere опашка управление дълбочина на ESXi домакини. Включете определя размера на планираните операции IO, които могат да бъдат изпратени на съхранение. В случай на vSphere, където обикновено един споделен диск устройство има достъп до множество домакини могат да бъдат полезни за контрол на дълбочината в точките на опашката за липса на ресурси. В тази статия се сравни Adaptive опашки и съхранение I / O Control (SIOC).
Какво тези технологии са различни?
SIOC използва концепцията за ниво на претоварването на базата на закъсненията в интернет. В действителност, ако забавянето на определена хранилище надвишава определен праг - превърнете SIOC. Този праг може да се настрои ръчно (по подразбиране 30ms) или автоматично от исканията за инжектор (представен 5.1). В случая с адаптивно управление vSphere опашка в очакване на действителното настъпване на липса на ресурси, която е получена от системата за съхранение в отговор на искането на USY SCSI IO Team или ОПАШКА пълен.
Адаптивно управление на опашката не е толкова гъвкав - в случай на пълнене опашката на инструкция, дълбочината опашка на приемащата на LUN намали наполовина. Ето защо е много важно, че всички хостове, свързани към един-единствен хост е включен адаптивно управление на опашките. Активирането на тази функция само от страна на домакините доведе до сериозен спад в производителността, тъй като всички ще бъдат заклани само в някои домакини, но не всички. След като опашката се обработват - той е отново постепенно започват да се запълнят.
Когато една технология е представен?
SIOC за първи път е въведена в vSphere 4.1 за блокови устройства и vSphere 5.0 за NAS. Адаптивно управление на опашката - в ESX 3.5U4.
За да се даде възможност на адаптивно управление на опашката трябва да се разширява всеки индивидуални настройки домакини, отидете на диск секция и променя настройките и Disk.QFullSampleSize Disk.QFullThreshold. QFullSampleSize опция по подразбиране е настроен на 0, че е изключен и QFullThreshold редактира необходимия брой екипи на нормализиране на състоянието, за да отключите.
резултати
Всяка функция може да донесе своя полза във вашата инфраструктура. SIOC, в сравнение с адаптивна на опашка, по-гъвкава технология, но тя е достъпна само в Enterprise +. Но, от своя страна, изисква адаптивни настройки на опашки за всеки хост. Също така, ако пристанищата за съхранение са свикнали да работите с други операционни системи, а не само на vSphere, ви препоръчвам да прочетете следната статия от базата знания: 1008113.
Хората с умствени споделени съхранение на техните физични свойства, като например свързване (всички те използват данни InfiniBand!), Протокол (съхранение блок! Или NFS! Или multiprokolnaya!) Или дори на хардуера е или софтуерно решение (това е просто софтуер на сървъра!).
Това не е правилно таксономия и грешен начин към групата! Софтуер архитектура - това е основният принцип на групиране, тъй като тя е за него, се определят от основи. Всички останали елементи - особено за изпълнението на архитектурата.
Не ме разбирайте погрешно - те са важни, но не са фундаментални.
Тип 1 групова архитектура (вертикално мащабируем)
Тези решения се характеризират с факта, че общата памет между контролерите не ги използвате, и в действителност, като данните са в кеша на контролера. Съхранение може да бъде А / А (както контролери са активни), A / P (един контролер е пасивно), A / S (всеки контролер обработва му количество данни, т.е. в асиметричен контролери достъп до данни).
Обработка съхранение на тези данни е както следва:
- Забавянето между контролерите е минимално. Почти нулев.
- Скоростта на масива зависи от диска.
- Тъй като закъснения в тези решения е минимална, а след това система за съхранение идеал за транзакционен модел за достъп до данни на.
- Обикновено архитектура и минимална комуникация между контролерите направи архитектурата е много лесно да се разшири функционалността (компресията, дедупликация, сълзене).
- Лесни за поддръжка, управление, конфигуриране.
- Скалируемост е ограничен или енергиен контролер двойка. Обикновено до 1000 дискове.
- Наличност на данни е гарантирана между комутационни контролери. Това може да доведе до влошаване на работата на, когато на изхода на една система.
- хардуер и софтуер - Самият и компоненти контролера.
- Предавки, пристанища в завода, и т.н.
- Активни / Standby- Пъргав, Pure съхранение, Tintri, UCS Whiptail
- Активни / Passive- NetApp, EMC VNX *
- Активни / с активно вещество HDS HUS, Dell Compellent, EMC VNX *, IBM V7000
От началото на тази можете да сложите федералното решение да ги направи по-хоризонтално мащабируема от управленска гледна точка на. Въпреки IO ще бъде базирана точно до данните, въведени в контролера. Такива решения могат да се използват за балансиране между контролери и басейни (VDM Mobility VNX у и у Клъстер ONTAP NetApp). Що се отнася до мен, такова решение може да бъде пресилено да се обадя хоризонтално мащабируема. Тъй като данните един или друг начин, са зад един или друг контролер. Балансиране и настройка са важни, за разлика от архитектури 2 и 3, където тя просто е.
Тип 2. свободно свързани (хоризонтално мащабируеми)
Архитектурни звучи като най-лесното решение, но в действителност, това е най-трудното решение. Това решение също не използва споделена памет между възлите, но данните се разпределят между възли, установени. Също такова решение се характеризира с голям брой съобщения между възли в записи на данни (скъпа операция по отношение на закъсненията). Но те все още са транзакциите - запис, макар и разделена, но последователен.
Забележете, че в снимката, посочен от възела без срив, се смята, че стабилността е гарантирана и разпространява копия на данните.
Обикновено забавянето на тези масиви за съхранение отделят ниска латентност (NVRAM, SSD, и т.н.), но във всеки случай винаги по-големи проблеми балансиране и архивиране на данни в сравнение с конвенционалните клъстер тип 1 като разпределя работата по записването.
Понякога, група от възли и ще съхрани само метаданни за nodah на почивка. Логиката е подобна на федерацията в предишната архитектура.
Предимството на такава архитектура за контрол и лекота на мащабиране. Хоризонтално мащабируеми системи са идеални за транзакционни натоварвания, тъй като на разпределеният характер от тях е не понася технически неизправности на сървъра, можете да използвате системите не са свързани помежду си, с които перфектно се справи обикновена стара Ethernet.
Въпреки факта, че методите за взаимно свързване може да се различават (Ethernet, данни InfiniBand и т.н.), всички от тези решения е критично място за разпределена мрежа от записи на данни. Потвърждение на влизане ще бъде изпратено до инициаторът само след успешни запис на данни от няколко различни nodah. Това, от своя страна, води до увеличаване на зона недостатъчност. Тези два параметъра са основните фактори, ограничаващи обхвата.
пиши обработка на искането е както следва:
И, съответно, да се чете:
Обща памет е критичен момент за тази архитектура. Първоначално позволено
Въпреки факта, че схема на тази архитектура е много подобен на предишния, разликата е, че моделът на разпределени и сподели метаданни означава, че такива решения не просто използват данни InfiniBand и RDMA зависи за обмен и споделяне на метаданни между възлите.
Вземете за пример двата разтвора от EMC - Isilon и XtremeIO. Въпреки факта, че и двете са много сходни - и двете решения са хоризонтално мащабируеми и двамата използваме данни InfiniBand помежду си за разликата е, че Isilon използва данни InfiniBand се сведе до минимум забавянето между възлите, и не използва споделена памет между възлите. В действителност, Isilon да използвате Ethernet (и там във версията VA) и XtremeIO зависи от RDMA.
Друг важен момент разлика между двете архитектури: колкото повече контролери са свързани един с друг, по-малък и по-малко предвидима, ще забави, но по-малко мащабируемост поради повишена сложност.
IO операция са както следва:
- Закъснения между контролери почти до нулата
- забавяне Въвеждане на данни зависи главно от физически дискове
- Идеален за тежки системи митата
- Limited мащабируемост гарантирана производителност
- Скалируемост ограничено до максимален брой контролери
- Въпреки че някои системи използват x86 архитектура, която се използва за собствените си хардуер. В други случаи се използва ASIC. И двете от тези фактори доведе до дълъг преход към нови технологии.
- Архитектурата е проектиран като се има предвид липсата на всеки елемент или отказоустойчивост.
- EMC Symmetrix VMAX
- HDS VSP
- HP 3PAR
В разпределени системи да не използват общата памет, данните се разделя на различни възли в, но не transactionally и "мързелив". Това означава, че данните се записват на един възел, както и с определена периодичност (понякога) се копират в други възли за да се гарантира сигурността на. Системи от този тип не са транзакционни.
Неизбежен interkonnet винаги построен на Ethernet (само защото е евтино и винаги на разположение), възелът не е виновен толерантни. Правилността на съхранение на данни не винаги е гарантирано, а стека на софтуер по-горе чрез шах.
Тази простота прави най мащабируема архитектура на всички. Тя няма абсолютно никакъв зависимост от хардуера, и почти винаги изпълнен под формата на софтуер. PB умножават със същата лекота и друга система за съхранение на терабайта. Той обикновено се използва обект и файлови системи не са POSIX често дори лежи на върха на локалната файлова система, използвана за основни задачи.
примери:- HDFS
- EMC Atmos
- Блок достъп до ЕМС VIPR
- Amazon AWS S3 (въпреки че никой извън Амазонка не знае как наистина да е така, че са склонни да въведете 3)
- Цеф
- OpenStack Swift
Оригинал: vmtyler.com