Пятый пост, написан Михаилом Михеевым на основе своего практического опыта в vCloud ИТ-ГРАД : «С технической точки зрения 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 от других, даже если оно подключено к той же внутренней сети или сети 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. А если нам нравится всё в облаке, зачем загружать? Мы продолжаем эксплуатировать нужные нам сервисы в облаке, продолжая пользоваться всеми вкусностями.
Сюда входит отсутствие необходимости инвестировать в локальное оборудование, единовременное добавление ресурсов, отсутствие головной боли по поводу низкоуровневого администрирования и высочайшая доступность.
Итак, по результатам тестирования вы также можете внедрить свое решение в продакшн-среду в облаке — скорее всего, вам все понравится.
А потом мы поговорим о других типах задач, которые можно решить с помощью такой инфраструктуры, и о ближайшем будущем — какие еще приятные вещи добавятся.
Теги: #Виртуализация #vmware #iaas #Виртуальный хостинг #виртуальная инфраструктура #it-grad #vcloud
-
Бартоли, Маттео Джулио
19 Oct, 24 -
Midi-Блютуз-Клавиатура На Esp32
19 Oct, 24 -
Внешний Мир Внутри Нашего Мозга
19 Oct, 24 -
Частицы Золота
19 Oct, 24 -
Как Представить Вашей Организации Openstack
19 Oct, 24
