В этой статье старший ИТ-архитектор COMPAREX AG Эрик Берг расскажет об использовании виртуальных машин в облачной среде, преимуществах и сопутствующих затратах.
Виртуальные машины являются частью решений «Инфраструктура как услуга» в Azure. По большому счету, нет существенных различий между виртуальными системами в Azure и другими системами, которые размещаются в специальном центре хранения и обработки данных (ЦОД) компании. Все они имеют определенный комплект аппаратного оборудования (CPU, RAM, HDD, сеть) и операционную систему. Тем не менее, виртуальные машины, используемые Azure, строго стандартизованы с целью оптимизации ресурсов и затрат.
Примеры классов:
Любое категоричное предположение о том, что управление виртуальными машинами в Azure приведет к сокращению затрат, вероятнее всего, является ошибочным. Количество затрат, возникающих в связи с использованием ВМ в Azure, равно затратам, связанным с использованием специального ЦОД.
Тем не менее, ВМ облачной среды, всё же имеют одно значительное преимущество перед их локальными приемниками: расходы возникают исключительно в момент их фактического использования. В общих чертах, именно это и является дополнительным преимуществом виртуальных машин, расположенных в облачной среде. Например, есть возможность минимизировать количество серверов в ферме удаленных рабочих столов, размещенную в Azure, в ночное время, а также использовать «полную» ферму с её пропорциональными затратами в дневное время. Аналогичным образом, будет вполне возможно динамично регулировать производительность ВМ и, в результате, активно реагировать на неустойчивое функционирование и потребности в ресурсах.
Именно такого рода гибкость придает ценность виртуальным машинам, используемым в Azure. Более того, при использовании виртуальных машин, пользователь может не использовать свое собственное аппаратное оборудование.
Системы эксплуатационного тестирования или разработки программ являются идеальным сценарием использования ВМ Azure, поскольку первоначальные преимущества сразу же проявляют себя даже на базовом уровне.
Практическая неограниченность ресурсов подразумевает, что даже крупные среды разработки и тестирования могут быть оснащены надежными мобильными устройствами.
Более того, проведение нового тестирования или выделение ресурсов становится доступным в Azure уже по первому требованию. Случаи использования внутренних процессов, когда тестирование и разработка происходили медленно и непроизводительно, уже уходят в историю.
Вопрос доступности является ключевым для выделения виртуальных машин в Azure. Для того чтобы пролить свет на данный вопрос, важно понять то, каким образом структурированы центры хранения и обработки данных и где размещаются ВМ.
Ключевую роль в функционировании виртуальных машин в Azure играют домены сбоя и обновления. В данном случае, домены сбоя описывают системы с идентичными зависимыми объектами, такими как источник электропитания, сетевой доступ или серверные шкафы. Домены обновления представляют собой системы, в которых применяется тот же самый цикл технического обслуживания, например введение идентичных «заплат».
Не стоит забывать, что системы, запущенные в одном и том же домене сбоя и / или обновления, при определенных обстоятельствах могут подвергаться одновременному сбою!
Именно поэтому SLA не заключаются в какой бы то ни было форме для отдельных ВМ в Azure. Для того чтобы получить гарантированную доступность, необходимо использовать, как минимум, две виртуальные машины в одной группе доступности. Так система будет настроена таким образом, чтобы гарантировать управление предлагающими одинаковые услуги ВМ на ведущих ЭВМ. Таким образом, в группе доступности будет всегда функционировать, по меньшей мере, одна виртуальная машина.
Соглашение об уровне обслуживания для виртуальных машин в Azure.
В каталоге Azure доступны несколько шаблонов для поставки виртуальных машин. Шаблоны в действительности представляют собой изображения ВМ, которые Microsoft регулярно обновляет. Они включают операционные системы Windows Server, а также Ubuntu или CentOS.
Кроме поставки виртуальных машин по шаблонам каталога, существует также возможность работы с изображениями или ВМ, которые пользователи создают самостоятельно.
Прежде всего, возможна миграция 1:1 виртуальных машин, которые прежде использовались локально в Azure. Здесь, локальный файл VHD перемещается в учетную запись хранения Azure, с которой он может быть запущен с помощью ВМ Azure.
Миграция ВМ в Azure
Существует ещё один метод хранения изображений ВМ в каталоге. Здесь виртуальная машина и все её настройки могут быть подготовлены в локальной среде. Система подготавливается к развертыванию с помощью утилиты Sysprep, и после завершения всех конфигураций создается подходящее изображение. Затем данное изображение загружается в Azure и используется для создания новых ВМ.
Загрузите собственное изображение в Azure
Метод создания изображений в облачной среде или для мобильности ВМ существует наряду с его гибридными аналогами. Он предусматривает оснащение виртуальной машины подходящей предварительной конфигурацией в Azure. Захват ВМ является методом перемещения данного вида виртуальной машины в ваш каталог изображений, где она может использоваться для создания новых ВМ.
Создайте собственное изображение в Azure
Виртуальные машины Azure, выступающие в качестве неотъемлемых элементов решения IaaS могут гибко использоваться, при этом затраты будут только в период их фактического использования. Это создает многочисленные сценарии, по которым модификации/поставки могут привести к заметному уменьшению расходов. Тем не менее, все возможные сценарии имеют одну общую черту: аппаратное и другое оборудование можно не задействовать. Вследствие этого пользователи сосредоточат свое внимание на действительно главном – виртуальных машинах.
Виртуальные машины являются частью решений «Инфраструктура как услуга» в Azure. По большому счету, нет существенных различий между виртуальными системами в Azure и другими системами, которые размещаются в специальном центре хранения и обработки данных (ЦОД) компании. Все они имеют определенный комплект аппаратного оборудования (CPU, RAM, HDD, сеть) и операционную систему. Тем не менее, виртуальные машины, используемые Azure, строго стандартизованы с целью оптимизации ресурсов и затрат.
Примеры классов:
Класс ВМ | Ядра CPU | RAM | HDD # |
---|---|---|---|
A2 | 2 | 3,5 ГБ | 4 |
A11 | Intel Xeon E5-2670 16 ядер @ 2,6 ГГц | 112 ГБ | 16 |
D4 | 8 | 28 ГБ | 400 GB local SSD |
G5 | 32 | 448 ГБ | 64 6596 GB local SSD |
Затраты
Любое категоричное предположение о том, что управление виртуальными машинами в Azure приведет к сокращению затрат, вероятнее всего, является ошибочным. Количество затрат, возникающих в связи с использованием ВМ в Azure, равно затратам, связанным с использованием специального ЦОД.
Тем не менее, ВМ облачной среды, всё же имеют одно значительное преимущество перед их локальными приемниками: расходы возникают исключительно в момент их фактического использования. В общих чертах, именно это и является дополнительным преимуществом виртуальных машин, расположенных в облачной среде. Например, есть возможность минимизировать количество серверов в ферме удаленных рабочих столов, размещенную в Azure, в ночное время, а также использовать «полную» ферму с её пропорциональными затратами в дневное время. Аналогичным образом, будет вполне возможно динамично регулировать производительность ВМ и, в результате, активно реагировать на неустойчивое функционирование и потребности в ресурсах.
Именно такого рода гибкость придает ценность виртуальным машинам, используемым в Azure. Более того, при использовании виртуальных машин, пользователь может не использовать свое собственное аппаратное оборудование.
Тестирование/Разработка
Системы эксплуатационного тестирования или разработки программ являются идеальным сценарием использования ВМ Azure, поскольку первоначальные преимущества сразу же проявляют себя даже на базовом уровне.
Практическая неограниченность ресурсов подразумевает, что даже крупные среды разработки и тестирования могут быть оснащены надежными мобильными устройствами.
Более того, проведение нового тестирования или выделение ресурсов становится доступным в Azure уже по первому требованию. Случаи использования внутренних процессов, когда тестирование и разработка происходили медленно и непроизводительно, уже уходят в историю.
Соглашение об уровне обслуживания (SLA)
Вопрос доступности является ключевым для выделения виртуальных машин в Azure. Для того чтобы пролить свет на данный вопрос, важно понять то, каким образом структурированы центры хранения и обработки данных и где размещаются ВМ.
Ключевую роль в функционировании виртуальных машин в Azure играют домены сбоя и обновления. В данном случае, домены сбоя описывают системы с идентичными зависимыми объектами, такими как источник электропитания, сетевой доступ или серверные шкафы. Домены обновления представляют собой системы, в которых применяется тот же самый цикл технического обслуживания, например введение идентичных «заплат».
Не стоит забывать, что системы, запущенные в одном и том же домене сбоя и / или обновления, при определенных обстоятельствах могут подвергаться одновременному сбою!
Именно поэтому SLA не заключаются в какой бы то ни было форме для отдельных ВМ в Azure. Для того чтобы получить гарантированную доступность, необходимо использовать, как минимум, две виртуальные машины в одной группе доступности. Так система будет настроена таким образом, чтобы гарантировать управление предлагающими одинаковые услуги ВМ на ведущих ЭВМ. Таким образом, в группе доступности будет всегда функционировать, по меньшей мере, одна виртуальная машина.
Соглашение об уровне обслуживания для виртуальных машин в Azure.
Поставка
В каталоге Azure доступны несколько шаблонов для поставки виртуальных машин. Шаблоны в действительности представляют собой изображения ВМ, которые Microsoft регулярно обновляет. Они включают операционные системы Windows Server, а также Ubuntu или CentOS.
Кроме поставки виртуальных машин по шаблонам каталога, существует также возможность работы с изображениями или ВМ, которые пользователи создают самостоятельно.
Прежде всего, возможна миграция 1:1 виртуальных машин, которые прежде использовались локально в Azure. Здесь, локальный файл VHD перемещается в учетную запись хранения Azure, с которой он может быть запущен с помощью ВМ Azure.
Миграция ВМ в Azure
Существует ещё один метод хранения изображений ВМ в каталоге. Здесь виртуальная машина и все её настройки могут быть подготовлены в локальной среде. Система подготавливается к развертыванию с помощью утилиты Sysprep, и после завершения всех конфигураций создается подходящее изображение. Затем данное изображение загружается в Azure и используется для создания новых ВМ.
Загрузите собственное изображение в Azure
Метод создания изображений в облачной среде или для мобильности ВМ существует наряду с его гибридными аналогами. Он предусматривает оснащение виртуальной машины подходящей предварительной конфигурацией в Azure. Захват ВМ является методом перемещения данного вида виртуальной машины в ваш каталог изображений, где она может использоваться для создания новых ВМ.
Создайте собственное изображение в Azure
В заключении
Виртуальные машины Azure, выступающие в качестве неотъемлемых элементов решения IaaS могут гибко использоваться, при этом затраты будут только в период их фактического использования. Это создает многочисленные сценарии, по которым модификации/поставки могут привести к заметному уменьшению расходов. Тем не менее, все возможные сценарии имеют одну общую черту: аппаратное и другое оборудование можно не задействовать. Вследствие этого пользователи сосредоточат свое внимание на действительно главном – виртуальных машинах.
Поделиться с друзьями
uterr
Как насчет виртуализации «для самых маленьких»?
Например, мне даже одного приложения (не ВМ) много, и я хотел бы, например, платить только за процессорное время (либо за комбинацию ресурсов) которые потребляют запросы в мое приложение. Планируется ли такое в Azure, или приложение это и есть минимальный квант, меньше которого не опустится?
mikhailt
В Azure вы и платите именно за время использования.
Если у вас что-то минимальное, есть бесплатный хостинг и для ASP.NET приложений и для баз данных MS SQL, MySQL.