Сегодня хотелось бы вкратце обратить Ваше внимание на те новые функции и механизмы, которые появились в Windows Azure после его обновления (GA — General Availability) от 16 апреля официально вступившего в силу.
Хоть Windows Azure и была изначально PaaS-платформой (простите за тавтологию), но со временем она развилась — и теперь в ней есть то, что интересно и мне, инфраструктурщику — а именно — IaaS.
_mini_oszone.png)
Увеличить
Где что зачем
Прежде чем обсуждать варианты и опции в области виртуальных машин в Windows Azure, было бы сначала неплохо поговорить немного о способах развертывания ВМ в Windows Azure:
1) С помощью портала управления. Здесь все банально и просто — старый-добрый GUI Windows Azure оброс новыми менюшками и рюшками — впрочем, это нисколько не сказалось на его лаконичности и доступности.
_mini_oszone.png)
Увеличить
2) С помощью инструментария командной строки и PowerShell — специально для любителей автоматизации сложных сценариев!
3) С помощью вызовов REST API.
После того как вы определились с выбором — как вы будете разворачивать ВМ, вам необходимо определить необходимый для развертывания образ и размер виртуальной машины. После этого будет запущен процесс создания ВМ, чей виртуальный жесткий диск будет размещен в BLOB-хранилище Windows Azure.
Ну а раз мы заговорили с вами про размеры ВМ — то неплохо было бы ознакомиться с предложениями по этому поводу.
_mini_oszone.png)
Увеличить
Здесь, как мне кажется, все предельно ясно и понятно.
Помимо этого также есть еще 2 экстра типа ВМ — для ресурсоемких проектов:
- 4 ядра — 28 Гб ОЗУ
- 8 ядер — 56 Гб ОЗУ
Однако, есть один момент на который стоит обратить внимание — это персистентный диск.
В чем же заключается разница между VM Role и Virtual Machine в Windows Azure? А вся разница заключается в том, что в первом случае диск ОС был не персистентный — иными словами, все изменения произведенные в системе после перезагрузки такой ВМ сбрасывались. Основное отличие Virtual Machines заключается в том, что они использую персистентный диск, то есть перезагрузка нам не страшна — и мы можем работать с такой ВМ привычным для нас надежным образом, без опасений по поводу потери данных после перезагрузки.
Это конечно замечательно, но стоит также обратить внимание на факт наличия достаточно богатого списка доступных в Windows Azure образов для развертывания ВМ.
_mini_oszone.png)
Увеличить
Причем обратите внимание на наличие образов с SharePointи BizTalk — тут уже язык с трудом поворачивается назвать это IaaS'ом — так как это уже сильно начинает смахивать на PaaS (А чем SharePoint не платформа для внутреннего портала организации — пускай он и в облаке находится?..).
Ну и конечно же, из этого напрашивается вопрос — раз Microsoft впиндюривает в Azure компоненты своих платформ, то какие эе продукты от MS смогут без проблем работать на ВМ в Windows Azure? Ответ не заставит себя ждать.
_mini_oszone.png)
Увеличить
Если же мы с вами говорим про Windows Server — будь это WS2008R2 или же WS2012 — то вот список поддерживаемых ролей для развертывания в Windows Azure:
Active Directory Domain Services
Active Directory Federation Services
Active Directory Lightweight Directory Services
Application Server
DNS Server
Fax Server
Network Policy and Access Services
Print and Document Services
Web Server (IIS)
Windows Deployment Services
Windows Server Update Services
File Services
Ну и что мне очень лично важно и приятно — не забыт и System Center 2012!
А как быть с кастомными, своими образами ОС и имиджами для развертывания?
Тут все просто — вы можете загрузить VHD-файл с установленной и настроенной ОС.
Разница между просто диском для ВМ и образом для развертывания последующих ВМ из шаблона для Azure представляется очень легко:
- ОС была настроена и подвергнута генерализации с помощью команды sysprep = имидж для развертывания.
- ОС просто находится в VHD файле и он просто загружается в Azure — просто диск Windows Azure.
А как быть с доступностью?
Ну а вот с доступностью все еще прекраснее и проще (куда уж еще более!?).
Для экземпляров сервисов и служб, которые запущены на 1-ой ВМ (Некластеризированная служба) SLA гарантирует доступность в 99,9% — что примерно равно простою в 8,75 часа в год.
Для кластеризированных служб, которые имеют множество экземпляров определенной роли — этот параметр по SLA составляет 99,95% — что во временом эквиваленте составляет 4,38 часа допустимого простоя в год.
Цифры более чем привлекательные — да еще и закрепленные в SLA — есть над чем поразмыслить — предложение действительно вкусное!
Что же касается внутреннего устройства ВМ, точки зрения их надежности, а именно надежности виртуальных дисков — здесь мы наблюдаем следующее:
_mini_oszone.png)
Увеличить
Исходя из данных таблицы, мы понимаем что:
- В системе всегда точно есть 2диска — C и D — один системный — другой под кэш системы, соответственно. Системны диск ограничен объемом в 127 Гб.
- Все остальные диски — это диски данных, которые мы добавляем по своему усмотрению — их можно добавлять/удалять на лету, ровно также можно и включать/отключать функцию кэширования. Максимальный объем такого диска — 1 Тб.
Заключение
Ну что же, мой кратенький обзор по ВМ (IaaS) в Windows Azure на этом завершен.
В недалеком будущем у нас будет еще достаточно много материала — и не только на Хабре (Да-да — я про MVA), который более подробно и точно расскажет о всех нововведениях Windows Azure, которые касаются аудитории IT Pro (системных администраторов).
.png)
.png)
.png)
.png)
.png)
.png)
