В данном посте мы рассмотрим две разные технологии vSphere по управлению глубиной очереди на ESXi хостах. Очередь определяет количество запланированных операций ввода-вывода, которые могут быть отправлены к СХД. В случае с vSphere, где обычно к одному общему дисковому устройству обращается несколько хостов, может быть полезно управлять глубиной очереди в моменты нехватки ресурсов. В данной статье мы сравним Adaptive Queues и Storage I/O Control (SIOC).
Чем эти технологии отличаются?
SIOC использует концепцию уровня перегруженности основанном на задержках доступа. По сути, если задержки на определённом datastore превысят определённый порог - включится SIOC. Этот порог может быть выставлен вручную (стандартное значение 30мс) или автоматически с помощью инжектора запросов (представлен в 5.1). В случае с адаптивным управлением очередью vSphere ждёт фактического наступления нехватки ресурсов, то есть получения от СХД в ответ на запрос команды ввода-вывода SCSI команды USY или QUEUE FULL.
Какой механизм когда работает?
Обе технологии урезают глубину очереди. В случае с SIOC каждая ВМ на datastore имеет своё значение долей (shares), при этом сами ВМ могут быть на разных хостах. Когда порог превышен доступ к LUN начинает контролироваться путём управления глубиной очереди для каждого отдельного хоста, но при этом учитываются доли каждой отдельной ВМ. Возьмём, к примеру, два хоста с двумя ВМ на каждом. Если доли ВМ на первом хосте будут по 1000, а на втором по 2000, то второй хост сможет отправить в два раза больше команд в момент нехватки ресурсов. Как только ситуация нормализуется - все хосты и ВМ смогут отправлять данные без ограничений глубины очереди, и SIOC перестанет ограничивать ресурсы.
Адаптивное управление очередью не настолько гибкое - в случае заполнения очереди команд, глубина очереди хоста к LUN урезается на половину. Поэтому очень важно чтобы на всех хостах подключённых к одному хосту было включено адаптивное управление очередью. Включение данной функции только на части хостов приведёт к серьёзному падению производительности, так как очередь будет зарезана только у части хостов, а не у всех. Как только очередь будет обработана - она снова инкрементально начнёт заполняться.
Когда какая технология была представлена?
SIOC впервые был представлен в vSphere 4.1 для блочных устройств и в vSphere 5.0 для NAS. Адаптивное управление очередью - в ESX 3.5U4.
Как включить данные технологии?
SIOC включается в свойствах каждого отдельного хранилища. По умолчанию данная функция выключена. Данная функция доступна только в редакции Enterprise+.
Для включения адаптивного управления очередью необходимо в расширенных настройках каждого отдельного хоста перейти в раздел Disk, и изменить значение параметров Disk.QFullSampleSize и Disk.QFullThreshold. По умолчанию параметр QFullSampleSize имеет значение 0, то есть выключено, а QFullThreshold редактирует необходимое количество команд о нормализации статуса для снятия блокировки.
Итоги
Каждая функция может принести свою пользу в вашей инфраструктуре. SIOC, по сравнению с адаптивной глубиной очереди, более гибкая технология, но и доступна она только в Enterprise+. Но, в свою очередь, адаптивная очередь требует настройки на каждом отдельном хосте. Также если порты СХД используются для работы с другими ОС, не только vSphere, я рекомендую прочитать следующую статью базы данных: 1008113.
Чем эти технологии отличаются?
SIOC использует концепцию уровня перегруженности основанном на задержках доступа. По сути, если задержки на определённом datastore превысят определённый порог - включится SIOC. Этот порог может быть выставлен вручную (стандартное значение 30мс) или автоматически с помощью инжектора запросов (представлен в 5.1). В случае с адаптивным управлением очередью vSphere ждёт фактического наступления нехватки ресурсов, то есть получения от СХД в ответ на запрос команды ввода-вывода SCSI команды USY или QUEUE FULL.
Какой механизм когда работает?
Обе технологии урезают глубину очереди. В случае с SIOC каждая ВМ на datastore имеет своё значение долей (shares), при этом сами ВМ могут быть на разных хостах. Когда порог превышен доступ к LUN начинает контролироваться путём управления глубиной очереди для каждого отдельного хоста, но при этом учитываются доли каждой отдельной ВМ. Возьмём, к примеру, два хоста с двумя ВМ на каждом. Если доли ВМ на первом хосте будут по 1000, а на втором по 2000, то второй хост сможет отправить в два раза больше команд в момент нехватки ресурсов. Как только ситуация нормализуется - все хосты и ВМ смогут отправлять данные без ограничений глубины очереди, и SIOC перестанет ограничивать ресурсы.
Адаптивное управление очередью не настолько гибкое - в случае заполнения очереди команд, глубина очереди хоста к LUN урезается на половину. Поэтому очень важно чтобы на всех хостах подключённых к одному хосту было включено адаптивное управление очередью. Включение данной функции только на части хостов приведёт к серьёзному падению производительности, так как очередь будет зарезана только у части хостов, а не у всех. Как только очередь будет обработана - она снова инкрементально начнёт заполняться.
Когда какая технология была представлена?
SIOC впервые был представлен в vSphere 4.1 для блочных устройств и в vSphere 5.0 для NAS. Адаптивное управление очередью - в ESX 3.5U4.
Как включить данные технологии?
SIOC включается в свойствах каждого отдельного хранилища. По умолчанию данная функция выключена. Данная функция доступна только в редакции Enterprise+.
Для включения адаптивного управления очередью необходимо в расширенных настройках каждого отдельного хоста перейти в раздел Disk, и изменить значение параметров Disk.QFullSampleSize и Disk.QFullThreshold. По умолчанию параметр QFullSampleSize имеет значение 0, то есть выключено, а QFullThreshold редактирует необходимое количество команд о нормализации статуса для снятия блокировки.
Итоги
Каждая функция может принести свою пользу в вашей инфраструктуре. SIOC, по сравнению с адаптивной глубиной очереди, более гибкая технология, но и доступна она только в Enterprise+. Но, в свою очередь, адаптивная очередь требует настройки на каждом отдельном хосте. Также если порты СХД используются для работы с другими ОС, не только vSphere, я рекомендую прочитать следующую статью базы данных: 1008113.
Сообщения
Комментариев нет:
Отправить комментарий