Алгоритм открытия услуги


После заказа и оплаты услуги "Виртуальный сервер" BILLmanager начинает процесс ее открытия, который состоит из этапов:

  1. Создание учётной записи.
  2. Создание vApp.
  3. Создание виртуальной машины.
  4. Активация услуги.

Создание учетной записи на стороне Cloud Director

Проверяется наличие учётной записи клиента на стороне Cloud Director. Если клиент ещё не имеет учётной записи, то BILLmanager создаёт в Cloud Director пользователя с именем user(email@example.com) и правами, которые указаны в настройках обработчика услуги (по умолчанию Organization Administrator).

Создание vApp

Виртуальные машины каждого клиента создаются в отдельном vApp. После создания или поиска пользователя клиента на стороне Cloud Director проверяется наличие у пользователя vApp и количество виртуальных машин в нём. 

  • если vApp не существует, то BILLmanager создаёт его с именем vapp-email@example.com_1. Где:
    • email@example.com — email пользователя;
    • _1 — номер vApp пользователя.
  • если vApp существует и количество виртуальных машин в нём превышает 128 штук, то создаётся новый vApp, к имени которого добавляется _2 (3, 4 и т.д.), например, vapp-email@example.com_2.

Создание виртуальной машины

Создание виртуальной машины в vApp выполняется по следующему алгоритму:

  1. Производится поиск сети с наибольшим количеством свободных IP-адресов. Для этого перебираются все сети с префиксом, указанным в настройках обработчика услуг. Так как интеграция осуществляется с правами администратора организации, данные по занятым IP-адресам учитываются только для этой организации. 
  2. Создается виртуальная машина с параметрами, указанными в выбранном шаблоне vApp: nCPU, DISC, имя виртуальной машины.
  3. Создается сеть уровня vApp, которая подключается к сети, найденной на первом этапе.
  4. Применяются параметры виртуальной машины, указанные при заказе услуги в BILLmanager.
  5. Выполняется рекастомизация виртуальной машины.
  6. Виртуальная машина включается.
  7. После успешного создания виртуальной машины, услуга в BILLmanager активируется.

Активация услуги

Статус услуги в BILLmanager меняется на "Активен". Клиенту отправляется письмо об открытии услуги.

Очередь обработки виртуальных машин


Существует очередь на открытие виртуальных машин. В один момент времени может открываться только один сервер в Cloud Director. Если в BILLmanager единовременно заказано несколько виртуальных серверов, то они будут создаваться не параллельно, а по очереди. 

Одновременное создание услуг не возможно в силу архитектурных особенностей работы Cloud Director. Он не может самостоятельно выделять свободные IP-адреса из внешних сетей.

Удаление нескольких серверов также происходит последовательно. Такой алгоритм необходим для того, чтобы обработчик мог определить, является ли текущая виртуальная машина последней в vApp. Если машина является последней, то удаляется не VDS, а vApp. 

Изменение параметров виртуальной машины


Для существующей активной услуги в BILLmanager можно изменить следующие параметры (если разрешено изменение по тарифному плану):

  • Количество виртуальных процессоров, количество оперативной памяти. Эти параметры можно изменить как в меньшую, так и в большую сторону. При уменьшении этих ресурсов виртуальная машина будет перезагружена. Увеличение этих ресурсов может проходить без перезагрузки сервера. Для этого на стороне VMware должны быть активны опции Virtual CPU hot add и Memory hot add
  • Объем жесткого диска. Изменение размера жесткого диска возможно только в большую сторону. При изменении размера диска увеличивается размер блочного устройства, увеличивать размер файловой системы необходимо вручную. Виртуальная машина будет перезагружена для применения новой конфигурации.
  • Публичные IPv4-адреса. Увеличение/уменьшение количества IP-адресов виртуальной машины происходит незамедлительно. Виртуальный сервер будет перезагружен для применения изменений.

Логирование


  • /usr/local/mgr5/var/pmvmwarevds.log — лог-файл модуля обработки Cloud Director. В лог записывается подробная информация о запросах, отправляемых в Cloud Director и ответах системы на эти запросы.

Информация о выполняемой задаче в логе представлена в виде xml:

<Task ... operation="Stopped Virtual Application qwe1(58b81329-ea2a-4f94-b999-1c36923a0340)" operationName="vappUndeployPowerOff" status="running">
...
</Task>
CODE
  • operation — имя операции.
  • status — состояние задачи:
    • success — завершена успешно.
    • error — завершена неудачей.
    • canceled — отменена владельцем или администратором.
    • aborted — прервана администратором.
    • running — выполняется.

В состав xml могут входить дочерние узлы:

  • Error — предоставляет информацию об ошибке в случае, если задача завершилась неудачей.
  • Progress — показывает состояние задачи в процентах от 0 до 100.

Возможные ошибки

ОшибкаОписание
auth_token

Не удалось получить токен авторизации. Как правило, причина в указании неверного логина или пароля.

forbiddenПользователь, под которым выполнена интеграция с Cloud Direcrot, не имеет прав на вызываемую функцию
not_foundОбъект, которому адресован запрос, не существует
bad_request

Невозможно обработать запрос.

Частые причины:

  • Кончились ресурсы в ВДЦ
  • Невозможно создать виртуальный маршрутизатор с выбранным IP-адресом
  • Недостаточно прав на получение информации о ролях пользователей
task_error

Запрос на выполнение операции завершился ошибкой.

create_vds

Не удалось завершить создание виртуальной машины.

Частые причины:

  • Создание виртуальной машины из шаблона vApp завершилось ошибкой
  • Не удалось подключить виртуальную машину к сети ВДЦ
gen_vappname

Генерация обработчиком услуг уникального имени vApp завершилась ошибкой

edit_vdsНе удалось изменить параметры виртуальной машины