Adaptive Queueing против Storage I/O Control

В данном посте мы рассмотрим две разные технологии 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.

Типы архитектур систем хранения данных

Это не новая тема, я её уже освещал на VMworld 2013 на сессии STO5420. Хранилища (такие штуки которые хранят информацию, и делают разные вещи с информацией) можно разделить на 4 группы. Главное здесь не зациклиться на не основных вещах.

Люди мысленно разделяют хранилища по их физическим свойствам типа интерконнекта (они все используют Infiniband!), протоколу (блочная СХД! Или NFS! Или мультипрокольная!) или даже аппаратное это или только программное решение (это просто софт на сервере!).

Это все не правильная таксономия и неправильный способ группировки! Программная архитектура - вот главный принцип группировки, так как именно по нему определяются фундаментальные характеристики. Все остальные элементы - частности реализации архитектуры.

Поймите меня правильно - они важны, но не фундаментальны.

Тип 1. Кластеризованная архитектура (вертикально масштабируемые решения)

Такие решения характеризуются тем, что в них не используется общая память между контроллерами, и, по сути, данные находятся в кэше одного контроллера. СХД может быть A/A (оба контроллера активны), A/P (один контроллер пассивен), A/S (каждый контроллер обрабатывает свой объём данных, то есть у контроллеров ассиметричный доступ к данным).

Обработка данных такими СХД выглядит так:

Плюсы:

• Задержка между контроллерами минимальна. Практически нулевая.
• Скорость работы массива зависит от дисков.
•  Так как задержки в таких решениях минимальны, то СХД идеальны для транзакционной модели доступа к данным.
• Простая архитектура и минимальные коммуникации между контроллерами делают архитектуру очень легко расширяемой функционально (компрессия, дедупликация, тиринг).
• Легко поддерживать, управлять, настраивать.

Минусы:

•  Масштабируемость ограничена мощностью контроллера или парой. Обычно до 1000 дисков.
• Доступность данных гарантируется переключением между контроллерами. Что может привести к понижению производительности при выходе одного из строя.

Точки отказа:

•  Сам контроллер и его компоненты - железо и ПО.
• Диски, порты в фабрике и т.д.

Примеры:

• Active/Standby- Nimble, Pure Storage, Tintri, UCS Whiptail
• Active/Passive- NetApp, EMC VNX*
• Active/Active- HDS HUS, Dell Compellent, EMC VNX*, IBM V7000

 Сюда же попадает все PCIe решения типа Fusion-IO или EMC XtremCache только без отказоустойчивости. Если это решение использует специализированное ПО для обеспечения отказоустойчивости, распределённого хранилища данных, целостности данных - смотрите на ПО, оно попадает под одну из четырёх архитектур.

Поверх такого можно поставить федеративное решение, чтобы сделать их более горизонтально масштабируемыми с точки зрения управления. Однако IO будет балансироваться ровно до попадания данных на контроллер. Такие решения также могут использоваться для балансировки между контроллерами и пулами (VDM Mobility у VNX и Clustered ONTAP у NetApp). Как по мне, такое решение можно с натяжкой назвать горизонтально масштабируемым. Так как данные, так или иначе, находятся за одним или другим контроллером. Балансировка и тюнинг важны, в отличие от архитектур 2 и 3, где она просто есть.

Тип 2. Слабо связанные (горизонтально масштабируемые решения)

Архитектурно звучит как самое простое решение, хотя на самом деле, это самое сложное решение. Такое решение тоже не использует общую память между нодами, но сами данные распределены по множеству нод. Также такому решению характерно большое количество коммуникаций между нодами при записи данных (дорогая операция с точки зрения задержек). Но они всё равно транзакционны - записи хоть и распределены, но все консистентны.

Заметьте на картинке нода обозначена без отказоустойчивости, считается что устойчивость гарантируется распределённостью и копиями данных.

Обычно задержки в таких массивах прячут за хранилищем с низкой латентностью (NVRAM, SSD и т.д.), но в любом случае всегда больше задач по балансировке и копирования данных чем в обычном кластере типа 1 так как операции записи распределённые.

Иногда выделяется группа нод, хранящая только метаданные об остальных нодах. Логика сходна с федерацией в предыдущей архитектуре.

Преимущество такой архитектуры в простоте масштабирования и управления. Горизонтальное масштабируемые системы просто идеальны для транзакционных нагрузок так как из-за распределённой природы таких систем можно использовать не отказоустойчивые сервера не связанные между собой, с чем отлично справится старый добрый Ethernet.

Несмотря на то, что способы интерконнекта могут отличаться (Ethernet, Infiniband и тд), для всех таких решений критичным местом является сеть для распределённой записи данных. Подтверждение о записи будет отправлено инициатору только после успешной записи данных на нескольких разных нодах. Это, в свою очередь, приводит к увеличению зоны отказа. Эти два параметра являются основными ограничивающими масштаб факторами.

Обработка запроса на запись выглядит следующим образом:

 И, соответственно, на чтение:

Плюсы:

• В конвергентных решения задержки на запись практически нулевые от клиента к массиву. Основные задержки вызывает копирование между нодами
• Быстрый локальный кэш для минимизации задержек синхронизации
• Производительность масштабируется практически линейно
• Отличная производительность при последовательном чтении
• Практически не используются специализированные аппаратные решения
• Обычно используются большие пулы ресурсов, что облегчает администрирование

Минусы:

• Больше нод - больше ресурсов на координацию
• В случае выхода какого-либо компонента из строя сбойной помечается вся нода
• Компромисс между производительностью и требованием к объёму данных. Некоторые решения разбивают данные на блоки с хэшами или контрольными суммами, что уменьшает скорость случайного доступа и требование к пространству или используют несколько копий данных, увеличивая требования к пространству
• Создание дискового пула является сложной фоновой задачей съедающей ресурсы
• Некоторые приложения не могут использовать все преимущества такой архитектуры, что приводит к локальной высокой нагрузке.

Точки отказа:

• Все отказы на ноде приводят к полному её отказу.
• Некоторые решения используют локальные RAID массивы, что приводит к тому что выход локального диска не приведёт к вывод из строя всей ноды.

Примеры:

• Аппартные решения: EMC Isilon, Dell Equallogic, HP StoreVirtual 4000
• Программные решения: VMware VSAN, IBM SONAS,  HP StoreVirtual VSA, EMC ScaleIO, VMware Virsto
• Конвергентные решения: SimpliVity, Nutanix.

Тип 3. Связанные, горизонтально масштабируемые архитектуры
Архитектура, в которой используется общая память между контроллерами (кэш или метаданные), а сами данные разнесены по разным нодам. Огромное количество коммуникаций между контроллерами по любому типу операций.

Общая память является критичным моментом для данной архитектуры. Изначально это позволяло
получить симметричный доступ к данным через любой контроллер. Разрабатывалась так, чтобы при выходе из строя любого элемента (запланированном или нет) операции ввода-вывода оставались относительно сбалансированными.

Несмотря на то, что схема данной архитектуры очень похожа на предыдущую, разница в том что модель распределённого и общего доступа к метаданным означает что такие решения не просто используют Infiniband, а зависят от RDMA для обеспечения общего доступа к метаданным между нодами.

Возьмём к примеру два решения от EMC - Isilon и XtremeIO. Не смотря на то что они оба очень похожи - оба решения горизонтально масштабируемы и оба используют Infiniband для интерконнекта разница в том, что Isilon использует Infiniband для минимизации задержек между нодами, и не использует общей памяти между нодами. Фактически, Isilon может использовать Ethernet (так и есть в VA версии), а XtremeIO зависим от RDMA.

Еще один важный момент отличия между двумя архитектурами: чем больше связанны контроллеры между собой, тем меньше, и предсказуемо меньше, будут задержки, но меньше масштабируемость из-за роста сложности системы.

Операции ввода-вывода выглядят так:

Плюсы:

• Задержки между контроллерами практически нулевые
• Задержки записи данных зависят в основном от физических дисков
• Идеально подходят для высоконагруженных систем
• Ограничением масштабируемость гарантируется производительность

Минусы:

•  Масштабируемость ограничена максимальным количеством контроллеров
• Хотя некоторые системы и используют x86 архитектуру, для них используется собственное аппаратное обеспечение. В остальных случаях используются ASIC. Оба этих фактора приводят к более долгому переходу на новые технологии.

Точки отказа:

• Архитектура разработана с учётом отсутствия или отказоустойчивости любого элемента.

Примеры:

• EMC Symmetrix VMAX
• HDS VSP
• HP 3Par

Тип 4. Распределённая архитектура без общих элементов (shared nothing)

В распределённых системах не используется общая память, данные разнесены по разным нодам, но не транзакционно, а "лениво". То есть данные записываются на одну ноду, и с определённой периодичностью (иногда) копируются на другие ноды для обеспечения защищённости. Системы данного типа не транзакционны.

Неизбежный интерконнет всегда построен на Ethernet (просто потому что дёшево и всегда доступно), ноды не отказоустойчивы. Корректность данных не всегда обеспечивается СХД, а программным стеком выше с помощью контрольных сумм.

Эта простота делает данную архитектуру самой масштабируемой из всех. У неё абсолютно никакой зависимости от аппаратного обеспечения, и практически всегда выполнена в программном виде. Масштабируется до петабайт с такой же лёгкостью как другие СХД до терабайт.  Обычно используется объектные и non-POSIX файловые системы часто даже лежащие поверх локальных ФС, используемых для базовых задач.

Примеры:

• HDFS
• EMC Atmos
• Блочный доступ в EMC ViPR
• Amazon AWS S3 (хотя никто за пределами Amazon не знает как на самом деле обстоит дело, я склоняюсь к типу 3)
• Ceph
• Openstack Swift

Оригинал: virtualgeek.typepad.com
Оригинал:  vmtyler.com

Комментарии и ответы

Коллеги, прошу прощения у всех, кому не было ответа на комментарии и вопросы в блоге. В потоке спама все просто потерялось.
Постараемся ответить на все.

В будущем, если вы хотите консультацию - продублируйте пожалуйста ваш вопрос почтой.

Не получается подключиться к NFS на Iomega

При попытке создать NFS датастор появляется сообщение

Call "HostDatastoreSystem.CreateNasDatastore" for object "ha-datastoresystem" on ESXi "192.168.X.X" failed.NFS mount 192.168.X.X:/mnt/part2/nfs_vmware failed: Unable to connect to NFS server.

При этом все остальное работает, сеть везде прописана, IP пингуется.

Проблема в том, что Iomega (в моем случае это ix4-200d) пытается отрезолвить DNS в обратную сторону. Ну а поскольку у меня все полегло после переключения питания, а DNS лежит на этой самой Iomega - замкнутый круг.

Решение:
1. Включить Support Mode на Iomega (простыми словами SSH доступ) на странице https://ix4-vadmin/support.html (заменить ix4-vadmin на IP вашей хранилки).
2. SSH на хранилку с логином root, и паролем из вашего административного пароля с добавкой soho в начале. Если пароля нет, значит просто soho.
3. Прописать в /etc/hosts имена ESXi, с которых будете подключаться
...
PROFIT!

Почему загрузка файлов на VMFS такая медленная?

Мы все видели это множество раз - залить файл на VMFS датастор занимает слишком много времени. Например, ISO с образом Windows 7 заливается 10 минут на iSCSI, и менее минуты на NFS. Оба датастора не имеют проблем и достаточно быстрые, на обоих работают ВМ.

Проблема с VMFS заключается в избыточных операциях с метаданными. Прежде всего, копирование файла блок за блоком вызывает множество обновлений метаданных по мере роста размера файла. Одно из решений - создать большой файл, скопировать его и обрезать по размеру в конце. Поэтому мы рекомендуем использовать vmkfstools для перемещения ВМ между датасторами из командной строки. По мере роста файла кусочками VMFS вынуждена постоянно обновлять метаданные для выделения новой порции ресурсов VMFS. Причем все это нужно для гарантирования целостности данных. В случае с NFS это просто не требуется в связи с принципиально иным механизмом блокировок файлов.

Один из путей подтверждения этого - статистика VAAI для дисковых массивов с поддержкой VAAI, или статистика SCSI reservation для массивов без. В качестве простейшего примера можно использовать gzip большого vmdk файла на VMFS датасторе (множество маленьких операций чтения и записи). Даже для VAAI будет видно множество запросов ATS и ZERO:

ATS ATSF ZERO ZERO_F MBZERO/s
42052 3 61370 0 5.72

Заключаем, что gzip блокирует ресурсный блок, заполняет нулями, а затем копирует содержание. То же самое происходит при загрузке файла на VMFS как из GUI, так и из командной строки.

Автор: Cormac Hogan

Nicira Virtualization Platform. NVP Manager

В третьей части мы обратим всё свое внимание на NVP Manager, который позволит провести дальнейшую настройку NVP.

Роль NVP Manager
NVP была разработана так чтобы интегрироваться с самыми разнообразными платформами управления облаком (CMP) с помощью набора «северных» API. Фактически эти REST API реализованы в контроллерах NVP, а не NVP Manager. Менеджер предоставляет вэб интерфейс, используемый для следующих задач:

Добавление гипервизоров
Добавление транспортных нод (шлюзы и сервисные ноды)
Настройку транспортных зон
Сбор информации и отладка

NVP Manager ориентирован на настройку, а не обеспечение работоспособности NVP. Другими словами – данный компонент вы будете использовать для управления компонентами платформы NVP – шлюзами, гипервизорами, но фактическое использование возможностей NVP, создание логических сетей, логических маршрутизаторов и тому подобное, будет происходить из CMP через вызовы к REST API к контроллерам. Таким образом, я буду использовать NVP Manager для выполнения некоторых задач, которые должны выполняться в CMP, но просто потому что под рукой у меня нету CMP.

Итак, разобравшись с ролью данного компонента перед к процессу установки и настройки.

Corrupt дисковой системы. Что делать?

Рассмотрим ситуацию: достоверно известно, что случился corrupt на уровне дисковой системы. Битые сектора или что-то еще - не столь важно. Сверху живет VMFS и виртуальные машины, но в ВМ вроде ничего не случилось, они продолжают работать.
В этой ситуации вполне может быть, что битая область вообще не затрагивает ВМ и все данные остались целыми. Так что же сделать, чтобы свести риски к минимуму?

1. Выключаем затронутые ВМ.
2. Клонируем ВМ на заведомо исправный датастор.
3. Включаем клоны, запускаем проверку целостности файловой системы в каждой ВМ. Можно использовать встроенные средства ОС или использовать любой Rescue CD.

Зачем выключать? При дальнейшей работе, в особенности в случае машин с тонкими дисками и снапшотами, можем затронуть битую область и соотв. ВМ приходит в негодность.
Обратите внимание, что ВМ именно клонируем, а не перемещаем. И тем более не делаем Storage vMotion, иначе есть риск остаться наедине с резервной копией. В случае если она вообще есть.