Департамент ИТ против частного облака

Департамент ИТ против частного облака from Anton Zhbankov

Транспортные протоколы резервного копирования VMware

Для резервного копирования виртуальных машин используется несколько транспортных протоколов – NBD, SAN, HotAdd. 

NBD (Network Block Device) является наиболее универсальным и доступным для любых видов СХД и окружений. При его использовании поток данных с СХД проходит через гипервизор ESXi и направляется на сервер резервного копирования по локальной сети. На практике его не рекомендуют использовать, если есть возможность работы с протоколами SAN и HotAdd, превосходящими его по разным отзывам от двух до десяти и более раз по скорости передачи данных.

SAN – используется при прямом подключении сервера резервного копирования в сеть хранения данных. Для его использования серверу РК необходим прямой доступ к томам с VMFS, что накладывает требования на конфигурирование хоста и ограничение доступа к нему. Для Windows необходимо отключить автоматическую инициализацию дисков во избежание перетирания сигнатур и метаданных VMFS. И разумеется никто не хочет, чтобы чьи-то неумелые или напротив, опытные, но зловредные потерли сами данные. Возможно предварительно их утащив.

В случае с Fiber Channel сетью сервер РК должен быть физическим и физически подключен в оптическую фабрику. В процессе резервного копирования гипервизор сообщает какие блоки необходимо забирать с тома VMFS и сервер РК читает их с СХД самостоятельно. Скорость резервного копирования ограничена лишь нагрузкой на СХД и способностью сервера РК справиться с потоком данных. Влияние гипервизора в данном случае минимально.

Несмотря на очевидное преимущество SAN протокола, не все так просто. Идеальным вариантом он является только при восстановлении толстых (thick) дисков, но наихудшим для тонких из-за постоянных вызовов API дискового менеджера (AllocateBlock, ClearLazyZero). В случае восстановления тонких дисков предпочтительно использовать NBD.

Также при восстановлении по SAN необходимо отключать CBT. Также не поддерживается запись в redo логи (снапшоты), восстановление идет только базовых дисков.
Особая тонкость в том, что размер диска должен быть точно кратен размеру блоку VMFS, иначе последний блок не сможет быть записан и весь процесс упадет с ошибкой "Invalid Argument". Для обхода этой проблемы софт резервного копирования должен дописать в конец блока недостающие нули.

HotAdd – способ, при котором к специальной виртуальной машине-прокси на горячую подключаются виртуальные диски целевой виртуальной машины, после чего прокси машина пересылает данные по локальной сети на сервер РК. Прокси может выполнять компрессию и дедупликацию данных при пересылке, в зависимости от используемого продукта РК. Роль прокси и сервера РК может быть также совмещена. Несмотря на использование дискового стека гипервизора для доступа к данным, скорость на практике практически равна варианту SAN.

В случае VMFS3 располагайте прокси на томах с большим размером блока VMFS, чтобы быть в состоянии бэкапить и восстанавливать очень большие файлы. Для VMFS5 размер блока унифицирован и эта рекомендация более неактуальна.

Поскольку при работе HotAdd создаются redo логи, не удаляйте подключенную ВМ пока не завершится процесс резервного копирования. Иначе гипервизор потом не сможет правильно обработать redo логи и диски от прокси придется отключать вручную. (!) Не удаляйте снапшоты до окончания резервного копирования (!).

Какой же язык программирования самый облачный?

Данный пост навеян обсуждением в Фейсбуке, начавшимся с "на JS и PHP написаны все говнооблака спорить не буду. А что потом? Так вот, за F# будущее".
В процессе обсуждения была высказана интересная мысль, даже смелая: "Облако - это новая вычислительная среда. Она устроена действительно по-иному нежели привычные нам персоналки".
И вот в чем вся соль: оба этих утверждения неверны.

Облако - это прежде всего самообслуживание и биллинг, это непременные атрибуты XaaS. Внизу облачный сервис состоит из множества маленьких сервисов, подсервисов и подсистем, каждая из которых может быть написана на любом языке или даже смеси языков. На некоторых языках программирования удобнее писать определенный вид сервисов. И то, если у вас есть команда разработчиков, хорошо владеющих данным языком и всей обвязкой к нему в виде библиотек и импортируемых модулей.
Я лично назвал бы только два с половиной языка, на которых можно написать полный стек облачного сервиса - это C, C++ и Java. Во всех остальных случаях придется использовать несколько языков. Но удивительное дело, ни один из них не нов и ни разу не облачен.

Вернемся ко второму утверждению о принципиально новом устройстве облачной среды с точки зрения программирования.
Как только мы отбрасываем биллинг и самообслуживание в PaaS, то оказываемся в совершенно традиционной среде, существовавшей задолго до облаков, хотя может быть и не столько популярной. И называется она Grid. Ничего нового облака нам снова не принесли, кроме значительной популяризации архитектуры грида. Возьми любое популярное PaaS облако, как например AWS или Azure - это не более чем набор очень больших гридов на каждый сервис и API к ним. API, кстати, тоже совсем не облачное изобретение.
Впрочем, есть пожалуй одна из архитектурных концепций, зародившихся примерно одновременно с облаками. Хотя я бы поставил ее как основу облаков, а не их следствие. Архитектура, построенная по принципу Design To Fail, или по-русски рассчитанная на отказ. Классическая привычная нам архитектура монолитных систем высокой доступности не может масштабироваться, и по сути ограничена сверху размером хоста. Для Scale-Out, неограниченно масштабируемой горизонтально системы, требуется не высокая доступность, а способность переживать отказ части узлов грида с минимальными последствиями для жизни всей системы.

Итого:
1. Нет никаких "облачных" языков, есть лишь универсальные и специализированные. Облако может быть построено на любом универсальном или любом миксе специализированных языков программирования.
2. Облака ничем не отличаются по архитектуре от дооблачных сервисов, несмотря на значительное развитие и появление новых сервисов в облачную эпоху.

VMware User Group 2015 - Программа

10 июля, Москва
Регистрация начинается в 9-30.

Владислав Кирилин (VMware), Сергей Горлинский (ActiveCloud) "Грузим грабли камазами"

Виктор Владимиров (VMware) "Horizon - плюсы и минусы из реальной практики внедрения"

Александр Серебряков (F5) "Построение отказоустойчивой платформы Horizon View"

Владимир Ескин (Veeam) "Veeam + VMware = Love"

Максим Шапошников (Nutanix) "Новости гиперковергентных инфраструктур"

Андрей Бешков (Microsoft) "Рекомендации по безопасности виртуальных инфраструктур"

Антон Жбанков (Step Logic), Сергей Груздов (Монт) "Демо-стенд на 1000ВМ. Только практика"

Константин Введенский (VMware) "Что такое vVols и с чем их едят"

Место проведения: Best Western Plus Vega Hotel & Convention Center

VMware User Group 2015

Друзья, рад объявить о проведении встречи VMware User Group 2015 10го июля в Москве. как всегда будет много очень технических докладов о реальной жизни и реальных проблемах.

Регистрация: ЗАКРЫТА

vVNX Community Edition

EMC опубликовала бесплатный полнофункциональный виртуальный VNX с ограничением до 4ТБ емкости. Поддерживается функционал vVols - соотв. это отличный способ попробовать их на практике.

Фактически это код от VNXe 3200, доступен в формате OVA и требует среду VMware.

http://www.emc.com/products-solutions/trial-software-download/vvnx.htm

Техническое описание VVol

Первое что хотелось бы отметить - технология называется VVol, не vVol, Vvol и прочее (от переводчика).


Традиционные системы хранения данных имеют следующие недостатки:

• Специализированное и дорогое железо - не общедоступное, стандартное оборудование, низкая утилизация и переподписка (overprovisioning);
• Архитектуру от устройства - статические уровни предоставления качества, стандартизированное выделение ресурсов, невозможность гранулярного контроля;
• Сложные процессы - недостаточность автоматизации, затратные по времени процессы, медленная скорость реакции на запросы.

Гипервизор позволяет реализовать автоматизацию СХД от приложения, так как:

• Знает все требования приложений в реальном времени;
• Является элементом пути в операции ввода-вывода;
• Видит все нижележащие СХД;
• Может динамически настраивать СХД;
• Независим от аппаратного обеспечения.

Традиционная модель - длительные циклы предоставления ресурсов, управление LUN, сложные и частые миграции данных.

Автоматизация от приложения - динамическое предоставление ресурсов СХД по мере необходимости. Контроль уровня предоставления сервиса на уровне отдельной ВМ. Общее управление разными устройствами.


vSphere Virtual Volumes

• Виртуализирует SAN и NAS устройства;
• Виртуальные диски нативно предоставляются массиву;
• Позволяют выполнять операции на уровне отдельной ВМ используя функции СХД;
• Управление хранилище на основе политик (SPBM, Storage policy-based management) позволяет автоматизировать потребление ресурсов при масштабировании;
• Широкая поддержка основнымит производителями СХД;
• Поставляется с vSphere.

Что такое VVol?

• Пять типов объектов VVols: Config, Data, MEM, SWAP, Other;
• Отсутствие необходимости использования СХД (VMFS отходит в историю);
• Объекты виртуальной машины хранятся нативно на СХД;

Контейнер массива (Storage Container)

• Логическая конструкция массива для группирования виртуальных томов;
• Обычно определяется администратором СХД на самом массиве для определения ёмкости массива и его ограничений;
• Ёмкость определяется физической ёмкостью массива.

Разница между контейнерами массива и LUN

• Размер контейнера основан на ёмкости массива;
• Максимальное количество контейнеров зависит от массива;
• Размер контейнера может быть расширен;
• LUN требует файловой системы, стандартизация размера LUN требует большего их количества.

Протокол конечной точки (Protocol End Points)

• Точка доступа реализовывающая коммуникацию между ESXi и СХД;
• На данный момент поддерживаются: iSCSI, NFS v3, FC, FCoE;
• Для каждой конечной точки единовременно поддерживается какой-то один обозначенный протокол;
• Конечная точка получает SCSI либо NFS команды;
• Контейнера массива - для большого количества метаданных и данных ВМ.

Панель управления

• VASA Provider (VP) - разрабатывается поставщиком СХД;
• Один VP может управлять несколькими массивами;
• VASA Provider может быть реализован как внутри массива, так и в виде внешней ВМ;
• Внеполосной (out of band) обмен сообщениями;
• ESXi и vCenter Server подключаются к VASA Provider.

Возможности массива и политики хранения ВМ (Storage Capabilities и VM Storage Policies)

• Являются функциями массива и требованиями ВМ к этим функциям, соответственно. Требования могут быть удовлетворены возможностями, предоставляемыми массивом;
• Возможности массива определяют что может предоставить массив в ответ на требования ВМ;
• Политики хранения ВМ являются компонентом хранилища на основе политик
• Представленные возможности - функции и сервисы массива, предоставленные гипервизору через VASA API;
• Управляются на уровне виртуального диска ВМ
• Используют концепцию соответствия для контроля предоставляемого уровня сервиса.

Сценарии операций

• Разгрузка операций: разворачивание, удаление, клонирование (полное и связанных), снепшоты;
• Снепшоты: управляемые ESXi или массивом.

В данной версии SRM не поддерживает VVol, но будет в следующей.

В будущих версиях VVol позволит пулу массива распространяться между физическими массивами.

Статья написана на основе доклада Роулинсона Риверы (Rawlinson Rivera) с VMware PEX 2015.

Оригинал: VVol Technical Overview