Пятый пост, написанные Михаилом Михеевым по его практическому опыту работы в vCloud IT-GRAD:
«С технической точки зрения, vCloud Director это приложение-надстройка над vSphere. Оно имеет информацию о кластерах и пулах, распределенных коммутаторах и группах портов, о хранилищах. Задачу, которую решает эта надстройка, состоит в удобном выделении вышеназванных ресурсов под группы виртуальных машин – суть в предоставлении интерфейса.
Как уже упоминалось, в основе лежит правильное железо + vSphere + vCloud Director, Datacener Tier 3 и самое технологические продвинутая платформа для построения инфраструктуры виртуализации.
Подробности:
А вот на средстве превращения инфраструктуры в облачную остановимся слегка подробнее – чтобы было понимание, что и как с его помощью можно сделать.
Ключевой объект того облака, о которым мы говорим – VMware vCloud Director.
С технической точки зрения, vCloud Director это приложение-надстройка над vSphere.
Оно имеет информацию о кластерах и пулах, распределенных коммутаторах и группах портов, о хранилищах.
Задачу, которую решает эта надстройка, состоит в удобном выделении вышеназванных ресурсов под группы виртуальных машин – суть в предоставлении интерфейса.
С одной стороны, интерфейса для администратора облакопровайдера – чтобы разделить много много имеющихся ресурсов на «облачка» разных заказчиков.
С другой стороны – предоставление интерфейса администратору, или представителю заказчика без навыков именно системного администратора, для развертывания виртуальных серверов, работы с ними, управлением внутриоблачной сетью.
То есть администратору или оператору достаточно указать – выделить этому заказчику столько-то ресурсов. Для процессора это мегагерцы, гигабайты для памяти, на каком хранилище (грубо быстрее\медленнее) располагать диски его ВМ, какие сети доступны (о сетях чуть позже будет подробнее).
Теперь администратор компании, который получает это облако в свое распоряжение, в пару кликов создает себе необходимое число виртуальных машин, в заданных рамках выделяет им необходимое число ресурсов и подключает к нужным из имеющихся сетям. Все, дальше можно начинать делать необходимую нам работу. Подробности того, что и как – были приведены в предыдущих постах.
Если с выделением процессорной производительности, памяти и дисков все довольно понятно – обычно сколько мы указали сами для своих ВМ – столько получили и за столько заплатили; то с сетями расскажу чуть подробнее.
Например, что вижу я, зайдя в соответствующий раздел интерфейса (рис.1):
Рисунок 1. Внутриоблачные сети
Здесь я вижу две доступные мне сети. Они довольно наглядно называются NAT и Internal.
Что это означает (рис. 2):
Рисунок 2. Иллюстрация доступных по умолчанию внутриоблачных сетей
Что при необходимости какие-то ВМ мы подключим к изолированной сети, а какие-то – к сети с доступом во внешний мир.
Притом, даже подключенные к одной сети группы виртуальных машин одной галочкой (рис. 3) могут быть изолированны друг от друга – как будто они подключены к разным коммутаторам – для поднятия нескольких идентичных конфигураций может быть очень удобно, чтобы не заботиться об отсутствии конфликтов в нашей сети.
Рисунок 3. Атоматическая изоляция данной группы виртуальных серверов во внутриоблачной сети
На этом скриншоте виден шаг мастера развертывание vApp из шаблона – как раз тут мы можем указать изоляцию этого vApp от других, пусть даже он подключен к той же самой сети Internal или NAT.
Притом, облачная инфраструктура VMware все банальные вещи позволяет делать очень тривиальным образом. Если мы зайдем в свойства сети с первой картинки, то увидим следующие настройки:
Встроенный DHCP – он уже присутствует из коробки, мы просто настраиваем его под себя(рис. 4).
Рисунок 4. Настройка штатного сервера DHCP
Настройки брандмауэре, защищающего наши виртуальные машины от опасностей внешнего мира (рис. 5).
Рисунок 5. Настройка штатного брандмауэра между внешним миром и сетью NA
Какие публичные IP адреса нам доступны (на скриншоте нет, но там просто список), и настройки мапинга портов (рис. 6).
Рисунок 6. Настройка проброса портов извне на ВМ сети NAT
Таким образом, реализовать можно любой необходимый нам вариант взаимодействия виртуальных машин между собой и, при необходимости, с внешним миром. Притом, для случаев попроще, нам будет достаточно предлагаемых самой инфраструктурой серверов DHCP, брандмауэров и NAT. DNS, разумеется, тоже предоставляется.
Итак, за короткое время я создал парочку нужных мне vApp-наборов виртуальных машин (рис.7):
Рисунок 7. Инфраструктура для моей задачи
К любой виртуальной машине можно открыть консоль и, при минимальной настройке NAT – rdp или любую другую нужную сессию.
На любой группе виртуальных машин (их три на предыдущем рисунке), в контекстном меню есть возможность сохранить эту группу как шаблон – и затем тривиальнейшим образом тиражировать однажды подготовленные виртуальные машины, притом с обезличиванием, при необходимости (рис. 8,9).
Рисунок 8. Старт развертывания группы ВМ из шаблона
Рисунок 9. Шаги мастера развертывания группы ВМ из шаблона
Тестовая среда развернута.
Список виртуальных машин (рис. 10).
Рисунок 10. Список виртуальных машин из всех групп моего облака
К ним открываются консоли, RDP, клиент View подключается к десктопам – в общем, все на мази.
Отдельным плюсом является простота построения сетевых инфраструктур. Например, для View может быть актуальна задача развернуть сервер безопасности, выполняющий роль посредника. А еще в рамках усиления защиты правильно будет разделить сети на внешнюю и внутреннюю, см. картинку (рис. 11).
Рисунок 11. Иллюстрация изменения инфраструктуры View
Так вот, переход от конфигурации один к конфигурации два – опять же пара кликов мышью. Добавить ВМ, указать что у нее два сетевых интерфейса, что один подключен к внутренней, а другой – к внешней сети. Ну и установить требуемый сервис внутри.
В принципе, задача минимум решена – я установил нужные операционные системы, нужные приложения, выполнил требуемые настройки.
Задача оптимум и задача максимум – пилотный проект и внедрение. Для них потребуется минимум усилий. Вот смотрите (рис. 12).
Рисунок 12. Иллюстрация тривиальности загрузки серверов из облака к себе
Как видно, мы можем в пару кликов выгрузить «нажитое непосильным трудом» к себе, и уже у себя запускать отлаженные и заведомо работающие сервисы. Притом нет зависимости от приезда нашего локального железа – выгрузим тогда, когда будем готовы (рис. 13, 14).
Рисунок 13. Идет операция загрузки из облака к нам локально
Рисунок 14. Из этих файлов можно импортировть загруженную группу ВМ на свою локальную vSphere
А если нам все понравится в облаке – зачем выгружать? Продолжаем эксплуатировать необходимые нам сервисы в облаке, продолжая пользоваться всем плюшками. Это и отсутствие необходимости вкладываться в свое локальное железо, и добавление ресурсов на раз, и отсутствие головной боли об низкоуровневом администрировании, высочайшая доступность.
Так что по результатам тестирования внедрять свое решение в производственную среду можно тоже в облаке – скорее всего вам все понравится.
А дальше мы поговорим про другие типы задач, которые могут быть решены с использование такой инфраструктуры, и про недалекое будущее – какие еще приятные вещи будут добавляться.
«С технической точки зрения, vCloud Director это приложение-надстройка над vSphere. Оно имеет информацию о кластерах и пулах, распределенных коммутаторах и группах портов, о хранилищах. Задачу, которую решает эта надстройка, состоит в удобном выделении вышеназванных ресурсов под группы виртуальных машин – суть в предоставлении интерфейса.
Что там с технической стороны? Подробности...
Как уже упоминалось, в основе лежит правильное железо + vSphere + vCloud Director, Datacener Tier 3 и самое технологические продвинутая платформа для построения инфраструктуры виртуализации.
Подробности:
А вот на средстве превращения инфраструктуры в облачную остановимся слегка подробнее – чтобы было понимание, что и как с его помощью можно сделать.
Ключевой объект того облака, о которым мы говорим – VMware vCloud Director.
С технической точки зрения, vCloud Director это приложение-надстройка над vSphere.
Оно имеет информацию о кластерах и пулах, распределенных коммутаторах и группах портов, о хранилищах.
Задачу, которую решает эта надстройка, состоит в удобном выделении вышеназванных ресурсов под группы виртуальных машин – суть в предоставлении интерфейса.
С одной стороны, интерфейса для администратора облакопровайдера – чтобы разделить много много имеющихся ресурсов на «облачка» разных заказчиков.
С другой стороны – предоставление интерфейса администратору, или представителю заказчика без навыков именно системного администратора, для развертывания виртуальных серверов, работы с ними, управлением внутриоблачной сетью.
То есть администратору или оператору достаточно указать – выделить этому заказчику столько-то ресурсов. Для процессора это мегагерцы, гигабайты для памяти, на каком хранилище (грубо быстрее\медленнее) располагать диски его ВМ, какие сети доступны (о сетях чуть позже будет подробнее).
Теперь администратор компании, который получает это облако в свое распоряжение, в пару кликов создает себе необходимое число виртуальных машин, в заданных рамках выделяет им необходимое число ресурсов и подключает к нужным из имеющихся сетям. Все, дальше можно начинать делать необходимую нам работу. Подробности того, что и как – были приведены в предыдущих постах.
Если с выделением процессорной производительности, памяти и дисков все довольно понятно – обычно сколько мы указали сами для своих ВМ – столько получили и за столько заплатили; то с сетями расскажу чуть подробнее.
Например, что вижу я, зайдя в соответствующий раздел интерфейса (рис.1):
Рисунок 1. Внутриоблачные сети
Здесь я вижу две доступные мне сети. Они довольно наглядно называются NAT и Internal.
Что это означает (рис. 2):
Рисунок 2. Иллюстрация доступных по умолчанию внутриоблачных сетей
Что при необходимости какие-то ВМ мы подключим к изолированной сети, а какие-то – к сети с доступом во внешний мир.
Притом, даже подключенные к одной сети группы виртуальных машин одной галочкой (рис. 3) могут быть изолированны друг от друга – как будто они подключены к разным коммутаторам – для поднятия нескольких идентичных конфигураций может быть очень удобно, чтобы не заботиться об отсутствии конфликтов в нашей сети.
Рисунок 3. Атоматическая изоляция данной группы виртуальных серверов во внутриоблачной сети
На этом скриншоте виден шаг мастера развертывание vApp из шаблона – как раз тут мы можем указать изоляцию этого vApp от других, пусть даже он подключен к той же самой сети Internal или NAT.
Притом, облачная инфраструктура VMware все банальные вещи позволяет делать очень тривиальным образом. Если мы зайдем в свойства сети с первой картинки, то увидим следующие настройки:
Встроенный DHCP – он уже присутствует из коробки, мы просто настраиваем его под себя(рис. 4).
Рисунок 4. Настройка штатного сервера DHCP
Настройки брандмауэре, защищающего наши виртуальные машины от опасностей внешнего мира (рис. 5).
Рисунок 5. Настройка штатного брандмауэра между внешним миром и сетью NA
Какие публичные IP адреса нам доступны (на скриншоте нет, но там просто список), и настройки мапинга портов (рис. 6).
Рисунок 6. Настройка проброса портов извне на ВМ сети NAT
Таким образом, реализовать можно любой необходимый нам вариант взаимодействия виртуальных машин между собой и, при необходимости, с внешним миром. Притом, для случаев попроще, нам будет достаточно предлагаемых самой инфраструктурой серверов DHCP, брандмауэров и NAT. DNS, разумеется, тоже предоставляется.
Итак, за короткое время я создал парочку нужных мне vApp-наборов виртуальных машин (рис.7):
Рисунок 7. Инфраструктура для моей задачи
К любой виртуальной машине можно открыть консоль и, при минимальной настройке NAT – rdp или любую другую нужную сессию.
На любой группе виртуальных машин (их три на предыдущем рисунке), в контекстном меню есть возможность сохранить эту группу как шаблон – и затем тривиальнейшим образом тиражировать однажды подготовленные виртуальные машины, притом с обезличиванием, при необходимости (рис. 8,9).
Рисунок 8. Старт развертывания группы ВМ из шаблона
Рисунок 9. Шаги мастера развертывания группы ВМ из шаблона
Тестовая среда развернута.
Список виртуальных машин (рис. 10).
Рисунок 10. Список виртуальных машин из всех групп моего облака
К ним открываются консоли, RDP, клиент View подключается к десктопам – в общем, все на мази.
Отдельным плюсом является простота построения сетевых инфраструктур. Например, для View может быть актуальна задача развернуть сервер безопасности, выполняющий роль посредника. А еще в рамках усиления защиты правильно будет разделить сети на внешнюю и внутреннюю, см. картинку (рис. 11).
Рисунок 11. Иллюстрация изменения инфраструктуры View
Так вот, переход от конфигурации один к конфигурации два – опять же пара кликов мышью. Добавить ВМ, указать что у нее два сетевых интерфейса, что один подключен к внутренней, а другой – к внешней сети. Ну и установить требуемый сервис внутри.
В принципе, задача минимум решена – я установил нужные операционные системы, нужные приложения, выполнил требуемые настройки.
Задача оптимум и задача максимум – пилотный проект и внедрение. Для них потребуется минимум усилий. Вот смотрите (рис. 12).
Рисунок 12. Иллюстрация тривиальности загрузки серверов из облака к себе
Как видно, мы можем в пару кликов выгрузить «нажитое непосильным трудом» к себе, и уже у себя запускать отлаженные и заведомо работающие сервисы. Притом нет зависимости от приезда нашего локального железа – выгрузим тогда, когда будем готовы (рис. 13, 14).
Рисунок 13. Идет операция загрузки из облака к нам локально
Рисунок 14. Из этих файлов можно импортировть загруженную группу ВМ на свою локальную vSphere
А если нам все понравится в облаке – зачем выгружать? Продолжаем эксплуатировать необходимые нам сервисы в облаке, продолжая пользоваться всем плюшками. Это и отсутствие необходимости вкладываться в свое локальное железо, и добавление ресурсов на раз, и отсутствие головной боли об низкоуровневом администрировании, высочайшая доступность.
Так что по результатам тестирования внедрять свое решение в производственную среду можно тоже в облаке – скорее всего вам все понравится.
А дальше мы поговорим про другие типы задач, которые могут быть решены с использование такой инфраструктуры, и про недалекое будущее – какие еще приятные вещи будут добавляться.
