Fault Tolerance стал ближе к народу
Анонсированная в предыдущих версиях сферы технология Fault Tolerance (FT) позиционировалась как усиленная версия vSphere High Availability для действительно критичных серверов. Ну, знаете, тех, чей отказ пользователи чудесным образом замечают быстрее систем мониторинга. Идея была в том, чтобы обеспечить действительно мгновенное переключение на резервную VM при неполадках с основной.
Для этого VMware реализовала постоянную репликацию процессорных инструкций и содержимого памяти объединенных в FT виртуальных машин. Конечно, от программных сбоев на уровне гостевой системы такой кластер не поможет, но если что-то случится с виртуальной машиной или гипервизором — пользователи ничего не заметят, даже TCP-соединение не прервется!
В общем, выглядело все здорово, если бы не ограничение в 1 CPU на машину. Сложно представить себе какой-нибудь SAP или MS SQL на сервере с одним процессором, потому технология особым спросом не пользовалась. Теперь же ситуация наверняка изменится, ведь представлен улучшенный механизм Fault Tolerance с поддержкой 4 процессоров и 64 ГБ памяти на машину. В эти габариты уже вписывается большинство реальных корпоративных систем.
Увеличение числа vCPU потребовало пересмотра синхронизации процессоров и памяти. Если раньше использовался механизм повторения инструкций на резервной VM, то теперь внедрена новая схема fast check-pointing, которая выполняет инструкции одновременно на обеих виртуальных машинах. Любопытный нюанс: если выделенная для FT-трафика сеть медленнее, чем требуется для синхронизации, то исходная VM будет пропорционально замедлена.
Среди прочих улучшений FT явно выделяется поддержка технологии мгновенных снимков VM и нормального бэкапа через интерфейс VADP. Теперь можно использовать привычные инструменты резервного копирования на уровне образа VM, как это уже давно происходит для обычных виртуальных машин.
VADP (vStorage APIs for Data Protection) — интерфейс для корректного централизованного резервного копирования виртуальных машин. Отличается возможностью работы «по-горячему», отсутствием агентских компонентов внутри VM и полной поддержкой со стороны VMware.
Из дополнительных бонусов можно назвать совместимость с любыми типами виртуальных дисков для защищенных FT машин (раньше обязательно было использовать «толстые» Eager Zero Thick disks). Не оставили нас и без vMotion. Но без ложки дегтя все же не обошлось:
Но без ложки дегтя все же не обошлось:
- На одном сервере vSphere ESXi можно задействовать до 8 vCPU или 4 VM под защитой FT.
- Для работы SMP-FT (работа с более чем 1 CPU) требуется выделенная сеть 10 Гб (помним про нюанс с синхронизацией машин).
- Не поддерживается hot-add для памяти и процессоров виртуальных машин в кластере FT.
- Storage vMotion, репликация, vSAN/vVols/vFlash не доступны для SMP-FT.
Всемогущий vMotion
Для многих vMotion — это не просто удобный инструмент для бесшовной миграции VM между хостами, но едва ли не олицетворение идеи виртуализации. Казалось бы, разве можно что-то еще добавить к проверенной годами технологии? И все же VMware смогли нас порадовать. Судите сами:
- Раньше нельзя было перенести виртуальную машину на другой управляющий сервер vCenter? Теперь можно, и даже метаданные корректно переедут (настройки HA, правила DRS и т. п.). К примеру, можно легко перенести виртуальные машины с классического vCenter на vCenter Server Appliance.
- Появилась возможность переноса машины между виртуальными коммутаторами vSS (Standard switch) и vDS (Distributed switch) в различных сочетаниях. Исключением тут будет лишь вариант vDS -> vSS. Дело в том, что vDS содержит дополнительные метаданные, который стандартным коммутатором просто не воспринимаются.
- Нельзя было не провернуть перенос VM в значительно удаленный дата-центр через vMotion? С шестой версией это не помеха, ведь теперь поддерживаются маршрутизируемые каналы с задержками до 100 мс. Нюансом тут можно считать требование к пропускной способности канала: 250 Мбит на каждую сессию vMotion. Жаль, что совсем уж волшебства не получилось и IP-адреса перемещаемых машин придется менять самостоятельно, если в целевом дата-центре иная адресация.
- Миграция в облачную среду стала еще проще и «глаже» благодаря работе vMotion между дата-центрами без общего хранилища. В принципе, можно даже организовать переезд в облако без отключения юзеров и ночной беготни с дисками.
- Бывалые пользователи vSphere оценят возможность выделять трафик vMotion в определенную сеть vmkernel, что добавляет гибкости всей схеме.
Библиотека дистрибутивов стала глобальной
В шестой версии vSphere нам предложен довольно интересный инструмент Content Library. Идея проста, как все гениальное: объединить между всеми vCenter репозитории нужных в работе дистрибутивов. Таким образом, полностью отпадает необходимость искать где-то оставленный референсный образ ОС или шаблон для нового стенда. Работает Content Library в следующих режимах:
- Немедленная загрузка — все содержимое опубликованного каталога сразу загружается на всех подписчиков (серверы vCenter).
- Загрузка по требованию — вместо постоянного копирования новых данных забираются лишь метаданные (список). Загрузка самих данных инициируется администратором.
Content Library использует стандартную базу vCenter, позволяет разместить до 64 ТБ данных и синхронизирует информацию раз в сутки. Поддерживаются любые типы файлов.
vVOLS как новый виток виртуализации хранения
Технология виртуальных томов на деле не так очевидна, как может показаться. Фактически это даже не новая идея, а логичное «углубление» уже внедренных VMware подходов к работе с системами хранения. Чтобы лучше понять, что кроется за новой v-аббревиатурой, разложим ее по кирпичикам. Обычно при словах «революция», «новая технология» самопроизвольно возникают сомнения и скепсис, потому именно виртуальным томам посвятим самое пристальное внимание. Тем более что в Интернете сейчас можно много найти о виртуальных томах в шестой версии сферы, но не везде ясно обозначены границы интереса. На мой взгляд, vVols будет актуален в первую очередь для организаций с весьма крупной виртуальной инфраструктурой или четкими зонами ответственности администраторов. Не то чтобы все остальные пожмут плечами и пройдут мимо, но для раскрытия всех «плюшек» vVols нужны специфические сложности:
- Неэффективная работа vSphere из-за неполного использования возможностей СХД. Например, операции со снимками и виртуальными дисками выполняются процессором ESXi, а могли бы быть переданы более профильному устройству.
- Человеческий фактор при размещении виртуальных машин. Банальные ошибки администратора при выборе целевого хранилища для новой машины, ведь человек может просто не знать о наличии или отсутствии какой-то специфичной функции новой железки. В результате — паника и беготня, когда это всплывет в самый неподходящий момент.
По сути, две эти проблемы и решает технология виртуальных томов. Разберемся, как именно. В первую очередь, на новых томах иначе хранится сама виртуальная машина. Каждый диск VM размещается в невидимом администратору логическом каталоге на СХД (не datastore, а именно на самой железке). Не просто как файл на разделе VMFS, а для каждого виртуального диска vmdk создается что-то вроде собственного LUN. Эту идею хорошо иллюстрирует картинка из презентации NetApp:
Также vVols меняет подход к размещению виртуальных машин. Нам предлагают удобный фильтр подходящих datastore. По идее, ситуации вроде «положил VM на первый попавшийся datastore, а репликация там оказалась недоступна» должны самоисключиться. Вместо слова «репликация» можно подставить дедупликацию, уровень IOPS, надежность и прочее. Логично предположить, что здесь явно не обошлось без VASA, влияние которого теперь выходит за рамки просто вспомогательной технологии. Например, можно сделать профиль для высоконагруженных VM и туда автоматически будут добавлены только те хранилища, у которых есть запрошенные вами «галочки». Или если расписание репликации больше не соответствует хотелкам приложения (читай, VM), то VASA позволит инициировать его перенос на более благодатную почву.
VASA (vSphere API for Storage Awareness) — специальный интерфейс vSphere, через который можно собирать информацию о возможностях СХД и в некоторой степени их настраивать. Для использования опции обязательно наличие специального VASA-провайдера от производителя системы хранения (отдельная серверная служба или интегрированная возможность самого устройства).
Кроме того, возможности VASA в новой версии расширены, и теперь можно перекладывать на систему хранения еще больше задач vSphere. Например, можно значительно быстрее создать снимки VM или выполнить их клонирование. При этом серверы ESXi будут заниматься полезным делом, а не созданием клонов. Я видел несколько живых демонстраций того, как это работает: действительно впечатляет, выигрыш по времени чуть ли не в десять раз. Можно провести параллель со снимками LUN на уровне самого хранилища. Только в случае с vVols есть возможность копировать не все подряд, а лишь диски интересующей виртуальной машины. Резюмируем, что можно сделать при использовании новых виртуальных томов:
- Автоматически отфильтровать все подключенные к vSphere системы хранения по наличию тех или иных функций. Полезно при размещении новой виртуальной машины.
- Реализовать автоматическое перемещение машины, если хранящее ее устройство больше не соответствует политикам.
- Передать СХД некоторые функции vSphere. Яркий пример — создание снимков и клонов VM прямо на хранилище. Эффект оценят, к примеру, пользователи систем бэкапа на уровне образа VM.
В новой версии своего флагманского продукта VMware добавила немало серьезных нововведений и сделала значительный шаг на пути к виртуализации критичных приложений. vSphere 6 еще только готовится к покорению дата-центров по всему миру, а мы уже активно изучаем его возможности - подписывайтесь на наш блог чтобы новости нашли вас вовремя!
