Самодельный облачный провайдер

На вопрос "Что является вершиной использования технологий виртуализации с точки зрения монетизации?" ответ очевиден - создание облачного сервис провайдера сдающего инфраструктуру в аренду.

Инфраструктуру облачного сервис провайдера можно использовать для размещения различных сайтов, сервисов а также для размещения виртуальных машин к которым можно получать удаленный доступ с различных мест, с различных устройств.

Как же работает облачный провайдер с технологической точки зрения? На этот вопрос постарается ответить эта статья.

Изоляция публичных виртуальных машин от корпоративной сети

Мы научились создавать виртуальные машины в интересах компании, а что делать если кто-нибудь не из сотрудников попросит виртуальную машину для удаленной работы? Как защитить корпоративную сеть от обнаружения не говоря уже об атаке? 

По-умолчанию виртуальные машины получают доступ в интернет через узел виртуализации на котором они запущены. Простая видимость узла особенно в случае, если доступен порт управления через SSH, подвержен атаке через перебор и как следствие вся сеть к которой подключен узел виртуализации может быть подвержена компрометации.

В случае если виртуальные машины изолировать с помощью изолированной сети, они перестанут видеть узел виртуализации и как следствие не смогут произвести на него атаку. С другой стороны, виртуальные машины лишаются выхода в Интернет. 

Чтобы предоставить доступ в Интернет изолированным виртуальным машинам можно в изолированную сеть добавить виртуальную машину которую назначить шлюзом остальным машинам. Источником интернет соединения для виртуального шлюза изолированной сети конечно же можно назначить узел виртуализации, однако это приведет к тому что узел виртуализации вновь станет доступным и вся сеть снова сможет быть подвергнута сетевой атаке. Чтобы этого не произошло виртуальный шлюз следует подключить напрямую к шлюзовой сети т.е. перед шлюзом локальной сети. В таком случае локальная сеть будет защищена от атаки через изолированную сеть также как если бы атака осуществлялась через сеть интернет.

В случае если порты шлюза скрыты Knockd, a ICMP пакеты - сбрасываются, то атакующий не сможет даже обнаружить сервер локальной сети.

Чтобы облегчить настройку сети у виртуальных машин в изолированной сети, на виртуальном шлюзе можно использовать DHCP-сервер совместно с DNS-сервером.

Как же подключить виртуальный шлюз к шлюзовой сети? Возможно два решения:

  • К узлу виртуализации можно подключить обычную сетевую карту и пробросить её в виртуальный шлюз изолированной сети через MacVTtap. Проверено на Realtek 8139.
  • К узлу виртуализации можно подключить сетевую карту совместимую с SR-IOV и пробросить её с помощью PCI-проброса в виртуальный шлюз. В этом случае сетевое соединение будет работать быстрее и качественнее чем в предыдущем случае. Однако сетевая карта с поддержкой SR-IOV стоит некоторых денег. Серверные сетевые карты с поддержкой SR-IOV обнаружены на сайте Intel.

Чтобы изолированная сеть не контактировала с узлом виртуализации её следует настроить со следующими параметрами:
ipaddr: 0.0.0.1
netmask: 255.255.255.0
dhcp: no

или в синтаксе libvirt:

<network>
  <name>PUBNET</name>
  <uuid>d69f9959-690c-6b3a-d122-aeb20536e99c</uuid>
  <bridge name='virbr6' stp='on' delay='0' />
  <mac address='52:54:00:BB:EB:D3'/>
  <ip address='0.0.0.1' netmask='255.255.255.0'>
  </ip>
</network>

По мере развития, когда количество узлов виртулизации на которых будут размещаться частные виртуальные машины превысит одну штуку, будет необходимо:

  1. Частично вынести изолированную сеть на физический уровень - узлы виртуализации будут подключаться к физическому свитчу или хабу через который будет бегать трафик изолированной сети. 
  2. Виртуальный шлюз нужно будет вынести на отдельный узел - для того чтобы высвободить вычислительные ресурсы а также позволить видеть друг друга виртуальным машинам. 

Также можно перенести диски виртуальных машин в сетевое хранилище (SAN) это позволит осуществлять живую миграцию виртуальных машин т.е осуществлять перенос виртуальных машин с одного узла виртуализации на другой практически незаметно для пользователя. 

Организация доступа в Интернет. Суровые реалии.

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

Клиенты бывают разные, одни могут работать в Интернет в рамках закона, другие осуществляют подрывную деятельность, задирают полицаев или едросню. Чтобы обезопасится от обысков и изъятия оборудования следует шпионить за клиентами, подружиться с ФСБ и Министерством связи. 

Для того чтобы стать провайдером нужно: 

  • найти и подготовить помещение под узел связи,
  • получить лицензию (на телематические услуги связи и передачу данных), 
  • подключить магистральный канал,
  • купить сертифицированный софт и оборудование, 
  • надавать взяток оборотням в погонах.

В случае возникновения конфликтных ситуаций в случае если вы работаете как провайдер вы сливаете всю ответственность на клиента, в случае если вы не провайдер вы понесете полную ответственность за произошедшее.

Поэтому на первое время, пока вы не стали провайдером, необходимо отказаться от предоставления доступа в Интернет. Как вариант в виртуальные машины можно пробросить USB-модем клиента.

Организация управления виртуальными машинами 

Узел виртуализации может представить следующие интерфейсы для управления виртуальными машинами:

  • libvirt-cоединение
  • VNC-cоединение
  • SPICE-cоединение

Чтобы получить доступ к этим интерфейсам достаточно подключится к соответствующим портам на узле виртуализации. Шлюз корпоративной сети провайдера может осуществлять форвардинг портов т.е. перенаправлять запросы к своим портам на порты узлов виртуализации. Удаленный пользователь будет работать с портами шлюза даже не подозревая о том что они находятся на другом сервере.

VNC- и SPICE-соединения позволяют работать с экраном, звуком, мышью, клавиатурой, буфером обмена и проброшенными со стороны клиента USB-устройствами. Однако они не позволяют подключать и отключать оптические диски, менять конфигурацию оборудования, запускать или отключать виртуальную машину. 

Все что не могут VNC- и SPICE-соединения может libvirt-соединение. Однако libvirt-соединение позволяет управлять не одной виртуальной машиной а несколькими. По этой причине необходимо создание сервиса-посредника, который бы выполнял роль интерфейса управления виртуальными машинами оперирующего своей базой данных пользователей и назначенных им виртуальных машин. 

Проект libvirt представляет большое количество драйверов для различных языков программирования в том числе:

  • C#
  • Java
  • OCaml
  • Perl
  • PHP
  • Python
  • Ruby.

Вы можете написать свой сервис либо использовать уже имеющийся. Например, в качестве такого сервиса можно использовать сайт на движке свободном движке Yaps c модулем Virt.

Управление виртуальными машинами через Yaps с модулем Virt

Модуль Virt оперирует пулом узлов виртуализации и пулом виртуальных машин. Yaps предоставляет интерфейсы для работы с базой данных пользователей. Получение всей необходимой информации осуществляется через модуль libvirt-php

Администратор Yaps может назначить пользователям виртуальные машины которыми они будут управлять.

Пользователи могут:

  • Управлять состоянием виртуальной машины: включать, выключать жестко с потерей всех данных, плавно выключать через ACPI,  приостанавливать, возобновлять). 
  • Для осуществления перезагрузки нужно сначала выключить компьютер а потом включить. Так как не очевидно в каждом конкретном случае какое выключение использовать (магкое или плавное) перезагрузка по команде не осуществляется. 
  • Работать с приводами оптических дисков: подключать, извлекать образы дисков.

Процесс работы с виртуальной машиной через Yaps представлен на следующем видео:

Использование программного обеспечения

Лицензирование коммерческого программного обеспечения используемое на компьютерах, сдаваемых в прокат очень хитромудрое. Чтобы лишний раз не мучится, можно возложить ответственность за используемый софт на пользователя и порекомендовать ему использовать коробочные версии продуктов.

Использование же свободного программного обеспечения можно осуществлять бесплатно в любом обьёме. 

Установку программного обеспечения можно осуществлять как по сети так и с образа оптического диска. 
 
В случае установки ПО по сети пользователю достаточно дать команду на загрузку и установку и все необходимое ПО загрузится и установится.

В случае установки ПО с образа оптического диска пользователю потребуется:

  1. Создать образ
  2. Закачать образ по FTP в свою папку на специальный FTP-сервер
  3. Через сервис-посредник в настройках виртуального привода виртуальной машины указать путь к образу в папке к которой примонтирована папка пользователя FTP-сервера.

Предел мощности. Воспроизведение видео.

В результате эксперимента выяснилось, что для просмотра видео 720p (1280х1024) гостевая виртуальная машина должна обладать: 

  • двумя ядрами по 3.2 ГГЦ  
  • 2ГБ оперативной памяти

Настоятельно рекомендуется отключение FLASH плагина, так как это освободит болшое количество вычислительной мощности которое занимается прорисовкой баннеров, которое можно потратить на обработку видео.

На узле виртуализации должен стоять многоядерный процессор. В ходе эксперимента использовался AMD Phenom(tm) II X6 1090T Processor. 

По состоянию на 24.01.2013 клиент должен работать под управлением GNU/Linux, так как Spice-клиент для Windows не воспроизводит видео.

Для теоретического расчета количества виртуальных машин способных просматривать видео одновремено можно попробовать использовать два ядра на виртуальную машину плюс одно ядро на эмуляцию и одно ядро на операционнцю систему узла виртуализации и того приблизительно получаем:

AMD Phenom(tm) II X6 1090T Processor (6-core) ~ 2 ВМ
AMD FX 8350 (8-core) ~ 3ВМ
AMD Opteron 6386 SE (16-core) ~ 6-7 ВМ на процессор.

Более точные результаты может дать только практические эксперименты.

Итого

Как видим создание публичного облачного провайдера стоит больших средств, что конечно же не посильная роскошь для дотационного региона сырьевой колонии именуемой Россия. Однако создание частного облака вполне себе возможно и рентабельно так как за траты на юридические вопросы (лицензирование, сертификация, взятки) значительно ниже.

Так что если хотите почувствовать себя современным белым жителем метрополии, обладающего доступом к виртуальной машине по Интернет через планшет, а не негром из сырьевой колонии - частное облако для Вас!