Виртуализация - размерът на опашката (на опашка) и адаптивен алгоритъм за управление на опашките в VMware

Както администратори знаят системи за съхранение на данни, различни компоненти SAN мрежа имат параметър, наречен на опашка (Queue Depth). Той е на сървъра HBA-адаптер (който, например, работи VMware ESX / ESXi) и порт за съхранение Processor'a съхранение (SP). Дълбочината на опашка определя колко IOPS (IO) могат да бъдат обработени едновременно на устройството.

Виртуализация - размерът на опашката (на опашка) и адаптивен алгоритъм за управление на опашките в VMware

Както вече бе споменато. ако преди SP от ESX / ESXi сървър използва единична активна път, дълбочината на масива целевата порт опашка (Т) би трябвало да удовлетворява следната зависимост:

където Q - е дълбочина опашка HBA-адаптер и L - LUN номера обслужвани от система за съхранение SP. Ако имате няколко активни пътища към една и съща SP дясната страна също трябва да бъде умножена по P - няколко начина.

Съответно, във виртуалната инфраструктура VMware vSphere имаме няколко домакини имат достъп до една и съща LUN чрез своята SP и следната зависимост:

T> = ESX1 (Q * L * Р) + ESX2 (Q * L * Р) +, и т.н.

Опашка Дълбочина на сървъри

Тази опция е и по подразбиране е 32. Той е в световен мащаб определя колко много IOPS (МО), могат да издават максимум една виртуална машина на LUN едновременно. В същото време, тя определя максималната стойност на ЗИ за всички виртуални машини върху които LUN. Това е, ако е зададено на 32, всички машини могат едновременно да изтръгне 32-ЗИ е потвърдено, в статия, Jason Boche. където 3 коли генерират 32 едновременно IO до един LUN и LUN са наистина едни и същи 32 вместо 3 * 32:

В случая е видно, че дейността се извършва 30 отбора (максимум 32) за определяне DQLEN, а останалите 67 са все още в опашката. Това означава, че този параметър определя максималната бар в IO за една машина на LUN, или за всички машини в LUN.

Важно е, че дълбочината на параметрите на опашката и DSNRO са установени в една и съща стойност. Тази препоръка VMware. Така че, ако ви отведе в главата, за да се промени една от тях - не забравяйте за втората. И не забравяйте, че опция DSNRO за домакин - глобален и поради това се отнася за всички LUN, свързан с хост.

Целева Порт Queue Depth на масиви

За дисков масив (или по-скоро, SP) на всички - това е, когато той sladyvaet SCSI-команда по това време, докато обработват и екзекутиран на предишния пакет. Нормално среден клас масив е с дълбочина опашка от 2048 или повече. Ако масивът получава опашка IO команди по-голяма стойност Целева Порт Queue Depth, той инструктира преди QFULL. което означава, че на опашката е пълна и хост сървъра нужда от това да се направи нещо. VMware ESX / ESXi реагира на това, както следва: - намалява началото на LUN и периодично (на всеки 2 секунди) проверява дали QFULL изчезнали и ако е изчезнал, след това постепенно увеличаване на дълбочината опашка за тази LUN (това може да отнеме до една минута) , Това е причината, спирачките, които често се срещат в потребителите на VMware ESX / ESXi.

Как да управлявате опашката и адаптивен алгоритъм за VMware

Сега става ясно, защо ние не веднага да изложи параметър Disk.SchedNumReqOutstanding на Силите VMware ESX / ESXi до максималната стойност - можем да наречем на масива SP QFULL. От друга страна, за да го намали, твърде лошо - ние ще ограничи броя на операциите IO от домакина на LUN.

Ето защо, ние се нуждаем от гъвкав подход, и то е от VMware (адаптивно опашка дълбочина алгоритъм). Тя работи по следния начин: ние активирате използване Disk.QFullSampleSize параметри и Disk.QFullThreshold в Разширени настройки. Те оказват влияние тук, на които:

  • QFullSampleSize - ако броят на броя на отговорите QFULL (е BUSY) надвишава, за ESX / ESXi половината намалява дълбочината на опашката (LUN дълбочина опашка)
  • QFullThreshold - ако броят на отговорите, които QFULL или заети вече не е да го превишава, за ESX / ESXi постепенно ще се увеличи размерът на опашката LUN от 1 (като, на всеки 2 секунди).

Но без значение колко е намалял DQLEN - под зададената стойност DSNRO нас това няма да падне. Тя ни предпазва от неочакван провал на изпълнение. Между другото, тези параметри също са глобални - така че ако някой (например, инхибиране) на масива от хоста, ще бъдат подложени на най-адаптивни ефекти на ESX / ESXi, а след това за друг (например, производителността) също ще се извършва от тези трикове.

Сега можете да прочетете по-нататък по тази тема:

Т.е. Поука е - по подразбиране Описание за DSNRO Queue Depth и е подходящ за повечето случаи. Но понякога има смисъл да ги промените. Но в този случай е необходимо да се вземат под внимание параметрите на съхранение, SAN структура, броят на LUN и други параметри, които влияят върху изпълнението вход-изход.