Коллеги, возникло желание поделиться практическим опытом эксплуатации сред виртуализации и связанных с ними систем.
В данной статье речь пойдет об особенностях работы систем хранения данных. В принципе, данная информация относится и к физическим серверам, использующим системы хранения, но в основном речь пойдет все же про виртуализацию, и про VMWare в частности.
Почему VMWare? Все просто, я являюсь специалистом по данной среде виртуализации, имею статус VCP5. Продолжительное время работал с крупными заказчиками и имел доступ к их системам.
Итак, начнем с истоков. Я постараюсь не напрягать читателей заумными словами и сложными выкладками. Не все являются специалистами в области, а материал может пригодиться многим.
Что такое виртуализация (в области серверов)? Это некая программно-аппаратная система, позволяющая на логическом уровне отделить вычислительные ресурсы от аппаратной части. В классическом виде на одном сервере может работать только одна операционная система, управляющая данным сервером. Все вычислительные ресурсы отданы этой операционной системе, и она ими монопольно владеет. В случае виртуализации, у нас добавляется прослойка программного обеспечения, которая позволяет эмулировать некоторую часть вычислительных ресурсов сервера в виде изолированного контейнера, и таких контейнеров (виртуальных машин) может быть множество. В каждый контейнер может быть установлена собственная операционная система, которая, возможно, и подозревать не будет, что её аппаратный сервер на самом деле является виртуальным контейнером. Подобная прослойка программного обеспечения называется гипервизором, средой для создания контейнеров, или виртуальных серверов.
Как работает гипервизор? Условно, все запросы от операционных систем в контейнерах (гостевых операционных систем), принимаются гипервизором и обрабатываются по очереди. Это касается как работы с процессорной мощностью, так и работы с оперативной памятью, сетевыми картами, а так же с системами хранения данных. О последних как раз и пойдет речь далее.
В качестве дисковых ресурсов, которые предоставляются гипервизором операционным системам в контейнерах, обычно используются дисковые ресурсы самого гипервизора. Это могут быть как дисковые системы локального физического сервера, так и дисковые ресурсы, подключенные с внешних систем хранения. Протокол подключения тут вторичен и рассматриваться не будет.
Все дисковые системы, по сути, характеризуют 3 характеристики:
1. Ширина канала передачи данных
2. Максимальное количество операций ввода-вывода
3. Величина средней задержки при максимально допустимой нагрузке
1. Ширина канала обычно определяется интерфейсом подключения системы хранения и производительностью самой подсистемы. На практике средняя нагрузка по ширине крайне незначительная и редко превышает 50…100 мегабайт в секунду даже для группы из 20-30 виртуальных серверов. Конечно, бывают и специализированные задачи, но мы сейчас говорим о средней температуре по больнице. Практика указывает именно на такие цифры. Естественно, бываю и пиковые нагрузки. В такие моменты полосы пропускания может и не хватить, поэтому при сайзинге (планировании) вашей инфраструктуры, надо ориентироваться именно на максимальные возможные нагрузки.
2. Операции ввода-вывода можно поделить на однопоточные и многопоточные. Учитывая тот факт, что современные операционные системы и приложения поголовно научились работать многопоточно, будем считать всю нагрузку многопоточной. Далее операции ввода-вывода можно поделить на последовательные и случайные. Со случайным доступом все понятно, а вот с последовательным? Учитывая нагрузку от большого количества виртуальных машин, да еще и многопоточную от каждой машины, мы в итоге получим практически полностью случайный доступ к данным. Конечно, варианты специфических случаев с последовательным доступом и малым количеством потоков возможны, но опять же, у нас рассматривается средняя температура. Наконец, операции ввода-вывода можно поделить на чтение и запись. Классическая модель говорит нам о 70% операций чтения и 30% операций записи. Возможно, так и есть для приложений внутри виртуальных машин. И ведь многие при тестировании и сайзинге принимают данную статистику за основу тестирования систем хранения. И делают огромную ошибку. Люди путают статистику доступа для приложений, и статистику доступа для дисковой подсистемы. Это не одно и то же. На практике для дисковой системы наблюдается следующее деление: порядка 30% операций на чтение и 70% на запись. Откуда такая разница?! Она из-за работы кэшей разного уровня. Кэш может быть у самого приложения, у операционной системы виртуальной машины, у гипервизора, у контроллера, у дискового массива, наконец у самого диска. Как итог, часть операций на чтение попадает в кэш какого либо уровня и не доходит до физических дисков. А операции записи доходят всегда. Это надо четко помнить и понимать при сайзинге систем хранения.
3. Задержки, или латентность системы хранения, это время, за которое гостевая операционная система получит запрашиваемые данные с её диска. Схематично и упрощенно запрос от приложения идёт следующим образом: Приложение-Операционная система-Виртуальная машина-Гипервизор-Система хранения данных-Гипервизор-Виртуальная машина-Операционная система-Приложение. На самом деле промежуточных звеньев цепи в 2-3 раза больше, но давайте опустим глубокие технические тонкости.
Что в этой цепочке может интересовать больше всего? В первую очередь ответ самой системы хранения и работа гипервизора с виртуальной машиной. С системой хранения вроде все ясно. Если у нас SSD диски, то время тратится на чтение данных из нужной ячейки и по сути все. Латентность минимальна, порядка 1 ms. Если у нас SAS диски 10к или 15к, то время доступа к данным будет складываться из многих факторов: глубины текущей очереди, позиции головки относительно очередной дорожки, угловой позиции пластины диска относительно головки и т.д. Головка позиционируется, ждет поворота диска, когда нужные данные окажутся под ней, производит операцию чтения или записи и летит к новой позиции. Умный контроллер хранит в себе очередь доступа к данным на дисках, корректирует очередность чтения в зависимости от траектории полета головки, меняет местами позиции в очереди, пытается оптимизировать работу. Если диски в RAID массиве, то логика доступа становится еще более сложной. Например, у зеркала есть 2 копии данных на 2-х половинках, так почему бы не читать разные данные из разных локаций одновременно двумя половинками зеркала? Аналогично ведут себя контроллеры и с другими типами RAID. В итоге для скоростных SAS дисков стандартная латентность равна 3-4 ms. У медленных собратьев NL-SAS и SATA этот показатель ухудшается до 9 ms.
Теперь рассмотрим звено цепи гипервизор-виртуальная машина. У виртуальных машин контроллеры жестких дисков тоже виртуальные, обычно это SCSI устройства. И общается гостевая операционная система со своим диском тоже ISCSI командами. В момент обращения к диску виртуальная машина блокируется гипервизором и не работает. В это время гипервизор перехватывает SCSI команды виртуального контроллера, после чего возобновляет работу виртуальной машины. Теперь уже сам гипервизор обращается к файлу с данными виртуальной машины (файлу диска виртуальной машины) и производит с ним необходимые операции. После этого гипервизор опять останавливает виртуальную машину, снова генерирует SCSI команды для виртуального контроллера и от имени диска виртуальной машины дает ответ на недавний запрос гостевой операционной системы. Данные операции подделки ввода-вывода требуют порядка 150-700 тактов центрального процессора физического сервера, то есть занимают около 0.5 микросекунды. С одной стороны не так много, но с другой стороны? Что если у машины активный ввод-вывод? Допустим, 50.000 IOPS. И что если она так же интенсивно общается с сетью? Добавим сюда достаточно вероятную потерю данных из кэша процессора, который мог смениться за время ожидания подделки запросов гипервизором. Или чего доброго, поменялось исполняющее ядро. В итоге мы имеем существенное снижение общей производительности виртуальной машины, что достаточно неприятно. На практике я получал падение производительности вплоть до 40% от номинала из-за влияния гиперактивного ввода-вывода виртуальной машины по сети и дисковой системе.
Медленная работа дисковой системы колоссально сказывается на работе приложений внутри гостевых машин. К сожалению, многие специалисты недооценивают это влияние, и при сайзинге аппаратной части стараются экономить на дисковой подсистеме: пытаются ставить недорогие, большие и медленные диски, экономят на контроллерах, отказоустойчивости. Потеря вычислительной мощности приводит к неприятностям и простою. Потери на уровне дисковой системы могут привести к потере всего, в том числе и бизнеса. Помните об этом.
Однако вернемся к операциям чтения и записи, а так же особенностям работы с ними различных уровней RAID. Если принимать stripe как 100% производительности, то следующие типы массивов имеют показатели:
Чтение RAID0=100%
Чтение RAID10=100%
Чтение RAID5=90%
Чтение RAID6=90%
Запись RAID0=100%
Запись RAID10=50%
Запись RAID5=25%
Запись RAID6=15%
Как мы видим, RAID5 и RAID6 имеют колоссальные потери производительности при записи. Тут нельзя забывать, что операции ввода-вывода нагружают дисковую систему совместно, и их нельзя считать по отдельности. Пример: в режиме RAID0 некая гипотетическая система имеет производительность 10.000 IOPS. Собираем RAID6, нагружаем классической нагрузкой среды виртуализации, 30% чтение и 70% записи. Получаем 630 IOPS чтения с одновременными 1550 IOPS записи. Не густо, правда? Конечно, наличие в системах хранения и контроллерах кэша в режиме записи write-back несколько увеличивает производительность, но у всего есть пределы. Считать IOPS надо правильно.
Пара слов о надежности, которые уже неоднократно были сказаны. При выходе из строя больших и медленных дисков наступает процесс ребилда массива (мы ведь позаботились о горячей замене?). На дисках 4ТБ процесс ребилда RAID 5 и 6 занимает около недели! А если нагрузка на массив велика, то и того больше. Так же процесс ребилда связан с резким ростом нагрузки на диски массива, что повышает вероятность сбоя еще одного диска. В случае с RAID 5 это приведет к безвозвратной потере данных. В случае с RAID 6 мы сталкиваемся с высокими рисками потери третьего диска. Для сравнения, в RAID10 при ребилде массива, по сути, просто копируются данные с одной половинки зеркала (одного диска) на другую. Это гораздо более простой процесс и занимает он относительно мало времени. Для диска 4 ТБ при средней нагрузке время ребилда составит порядка 10-15 часов.
Хочется добавить, что бывают в природе и умные системы хранения типа Dell Compellent SC800, которые имеют очень гибкий подход к хранению данных на базе различных настраиваемых уровней Tier. Например, эта система может писать новые данные только на SCL SSD диски в режиме RAID10, после чего, в фоновом режиме, перераспределит блоки данных на другие типы дисков и уровни RAID в зависимости от статистики обращения к этим блокам. Системы эти достаточно дороги и нацелены на специфического потребителя.
Подводя итоги, остается определить следующие тезисы:
— Система хранения под виртуализацию должна быть быстрой и надежной, с минимальными задержками
— При проектировании среды виртуализации на систему хранения необходимо закладывать порядка 40% всего бюджета аппаратной части
— При сайзинге системы хранения, в общем случае, стоит ориентироваться на RAID10
— Бэкапы спасут мир!
Автор: Sladky
