Эта история про то, как компания ISPsystem и ведущий российский поставщик облачных услуг DataLine нашли друг друга на конференции WHD.global в Германии и что из этого вышло. Мы рассказали про высокую адаптируемость BILLmanager, а коллегам из DataLine нужен был новый личный кабинет для их проекта CloudLITE. В результате через месяц DataLine попросил нас адаптировать BILLmanager для предоставления облачных ресурсов на базе VMware.
Мы с удовольствием взялись за работу и в первую очередь совместно с DataLine определили недостатки их прежней биллинговой платформы:
- Невозможность самостоятельно сменить плательщика с физического лица на юридическое. Очень часто компании “примеряют” CloudLITE на свои задачи от лица ”физика” с целью оптимизации расходов.
- Отсутствие гибкости в тарификации услуг. Оплата происходила 1-го числа каждого месяца, и если на все 30/31 день денег на счёте не хватало, то предоставление услуг блокировалось. Посуточного списания средств не было.
- Отсутствие механизма управления своими VDS напрямую из биллинга. Выполнить настройку можно было только через vCloud Director, а его интерфейс, в свою очередь, отпугивал пользователей своей сложностью: обилие кнопок и настроек сбивало с толку. Как выяснилось, большинству пользователей не нужно тонко конфигурировать свои виртуальные машины, достаточно типового шаблона.
DataLine очень подробно описали все эти моменты в статье про CloudLITE 2.0. Рекомендуем к прочтению.
После выявления минусов прежней платформы последовало тщательное изучение BILLmanager специалистами DataLine. Во время этой работы мы отвечали на возникающие вопросы и проводили вебинары для того, чтобы исследование нашей биллинговой платформы было максимально комфортным. В результате проведённых испытаний партнёром было составлено одно из лучших технических заданий в нашей практике. Затем ТЗ обсуждалось и корректировалось. Мы внимательно изучали документ, выявляли «тонкие моменты» и предлагали более эффективные методы их решения, опираясь на наш опыт работы.
После утверждения ТЗ стал понятен общий план работ:
- Переделать интерфейс BILLmanager в соответствии с корпоративным стилем компании и пожеланиями DataLine;
- Реализовать новый тип услуги, “Виртуальный дата-центр”, и упрощённый механизм управления его виртуальными машинами;
- Написать обработчик для взаимодействия с API VMware vCloud.
Оставалось лишь установить сроки запуска Minimal Viable Product. Для этого обе стороны поставили под датами штампы-подписи, и работа закипела.
Процесс разработки
Каждый четверг мы показывали заказчику результаты работы за неделю. В пятницу проектная команда прорабатывала замечания, после чего в тот же день при необходимости проводилась видеоконференция. Кроме этого, сотрудники DataLine могли в любой момент зайти на тестовый стенд и буквально “на лету” наблюдать как появляются новые фичи.
Нужно отметить, что описание заслуживающих внимания организационных моментов и управленческих решений в проекте тянет на отдельный и немаленький хабрапост. Мы уже подбиваем материал. А в этой статье хотелось бы рассказать о наиболее интересных и сложных технических моментах разработки.
Первый ключевой пункт – создание виртуальной машины в ВДЦ из BILLmanager.
Алгоритм
Все действия производятся с правами администратора VDC.
1. На стороне биллинга инициируется создание ВМ
Необходимо заполнить следующие поля:
1.1. Шаблон vApp;
1.2. Сеть организации (если создана хотя бы одна сеть уровня организации в текущем VDC);
1.3. Имя vApp (если есть созданные vApp, то будет возможность указать уже существующий vApp);
1.4. Имя ВМ;
1.5. Пароль ВМ;
1.6. Параметры ВМ (HDD, CPU, MEM). Все параметры регламентированы значениями, указанными внутри шаблона vApp.
2. На стороне API VMware vCloud создаётся виртуальная машина
2.1. Создаём новый vApp;
2.1.1. Выполняем установку нового vApp;
2.1.2. При указании сети, к которой подключается vApp, создаём сеть уровня vApp;
2.1.3. Подключаем ВМ к сети уровня vApp;
2.1.4. Получаем список IP-адресов ВМ (внутренний/внешний);
2.1.5. Получаем имя ОС;
2.1.6. Применяем параметры ВМ (HDD, CPU, MEM);
2.1.7. Передаём BILLmanager 5 результат создания ВМ (успех/неудача).
2.2. Добавление ВМ в существующий vApp;
2.2.1. Производим рекомпозицию (Recompose) существующего vApp;
2.2.2. Применяем параметры ВМ (HDD, CPU, MEM);
2.2.3. Получаем имя ОС;
2.2.4. Проверяем, есть ли сеть vApp подключенная к необходимой нам сети организации (если указана в BILLmanager 5). Если сети нет, тогда создаём её.
Возвращаемся на уровень выше, продолжаем создание vApp
2.1.8. Подключаем ВМ к сети уровня vApp;
2.1.9. Получаем список IP-адресов ВМ (внутренний/внешний);
2.1.10. Передаём BILLmanager 5 результат создания ВМ (успех/неудача).
1. На стороне биллинга инициируется создание ВМ
Необходимо заполнить следующие поля:
1.1. Шаблон vApp;
1.2. Сеть организации (если создана хотя бы одна сеть уровня организации в текущем VDC);
1.3. Имя vApp (если есть созданные vApp, то будет возможность указать уже существующий vApp);
1.4. Имя ВМ;
1.5. Пароль ВМ;
1.6. Параметры ВМ (HDD, CPU, MEM). Все параметры регламентированы значениями, указанными внутри шаблона vApp.
2. На стороне API VMware vCloud создаётся виртуальная машина
2.1. Создаём новый vApp;
2.1.1. Выполняем установку нового vApp;
2.1.2. При указании сети, к которой подключается vApp, создаём сеть уровня vApp;
2.1.3. Подключаем ВМ к сети уровня vApp;
2.1.4. Получаем список IP-адресов ВМ (внутренний/внешний);
2.1.5. Получаем имя ОС;
2.1.6. Применяем параметры ВМ (HDD, CPU, MEM);
2.1.7. Передаём BILLmanager 5 результат создания ВМ (успех/неудача).
2.2. Добавление ВМ в существующий vApp;
2.2.1. Производим рекомпозицию (Recompose) существующего vApp;
2.2.2. Применяем параметры ВМ (HDD, CPU, MEM);
2.2.3. Получаем имя ОС;
2.2.4. Проверяем, есть ли сеть vApp подключенная к необходимой нам сети организации (если указана в BILLmanager 5). Если сети нет, тогда создаём её.
Возвращаемся на уровень выше, продолжаем создание vApp
2.1.8. Подключаем ВМ к сети уровня vApp;
2.1.9. Получаем список IP-адресов ВМ (внутренний/внешний);
2.1.10. Передаём BILLmanager 5 результат создания ВМ (успех/неудача).
Второй – двунаправленная синхронизация состояний виртуальных машин между vCloud и биллинговой системой, как в автоматическом, так и в ручном режиме.
Подробности
Во время синхронизации происходит сбор статистики с ВДЦ. Получаем такой вот “пакет”:
Расшифруем, что есть что.
Все эти значения агрегирует BILLmanager.
- Синхронизация всех виртуальных дата-центров происходит автоматически каждые 30 минут (есть задача в планировщике);
- Синхронизация пользовательского ВДЦ может быть запущена вручную по нажатию кнопки «Обновить» в меню виртуальных машин в биллинговой платформе.
Во время синхронизации происходит сбор статистики с ВДЦ. Получаем такой вот “пакет”:
<item id="2560" status="true" vdcid="9fdc0391-4a27-4a6c-9b9f-91137849c1da">
<net name="orgnet-ISP_TEST2">4b9de9ad-a4d1-44e5-a846-0143c380e854</net>
<vapp id="vapp-ef6ed6d8-6538-440a-a91c-3dd5574c8787" name="qwe" status="8">
<vm id="vm-7e779303-8bb5-46c0-b4b9-8973bf4b18f5" name="qwe" status="8" ext_ip="92.242.45.21" int_ip="192.168.100.100" vapp_template="3dd2ee97-2f2d-465b-b5d4-2c4e0f07c225">
<os value="CentOS 4/5/6 (32-bit)"/>
<password value="!R3!e3C7"/>
<disc id="2000" reserved="10240"/>
<cpu reserved="1"/>
<mem reserved="1024"/>
</vm>
</vapp>
</item>
Расшифруем, что есть что.
1. <item id="2560" status="true" vdcid="9fdc0391-4a27-4a6c-9b9f-91137849c1da">...</item>
1.1. id – ID услуги из BILLmanager;
1.2. status – включен ли VDC;
1.3. vdcid – UUID виртуального дата-центра.
2. <net name="orgnet-ISP_TEST2">4b9de9ad-a4d1-44e5-a846-0143c380e854</net>
2.1. name – имя сети организации;
2.2. значение узла – её UUID.
3. <vapp id="vapp-ef6ed6d8-6538-440a-a91c-3dd5574c8787" name="qwe" status="8">...</vapp>
3.1. id – UUID vApp;
3.2. name – имя vApp;
3.3. status – состояние vApp (6 - Process, 4 - Active, 3 - Suspended, 8 - Stopped).
4. <vm id="vm-7e779303-8bb5-46c0-b4b9-8973bf4b18f5" name="qwe" status="8" ext_ip="92.242.45.21" int_ip="192.168.100.100" vapp_template="3dd2ee97-2f2d-465b-b5d4-2c4e0f07c225">...</vm>
4.1. id – UUID ВМ;
4.2. name – имя ВМ;
4.3. status – см. выше;
4.4. ext_ip – внешний IP ВМ;
4.5. int_ip – внутренний IP ВМ;
4.6. vapp_template – vApp Template (шаблон контейнера), из которого была создана ВМ.
5. Параметры ВМ:
5.1. <os value="CentOS 4/5/6 (32-bit)"/> – операционная система;
5.2. <password value="!R3!e3C7"/> – Пароль ВМ;
5.3. <disc id="2000" reserved="10240"/> – ID виртуального жёсткого диска и его размер в МБ;
5.4. <cpu reserved="1"/> – количество CPU;
5.5. <mem reserved="1024"/> – количество MEM в МБ.
Все эти значения агрегирует BILLmanager.
Третий – реализация доступа к только-только обновлённой компанией VMware веб-консоли виртуальной машины.
Почувствовали себя первопроходцами, поскольку на тот момент никто кроме нас подобную интеграцию ещё сделать не успел.
Исходный код
При отправке клиенту подменяем на этой форме следующие поля:
"__VMNAME__" – имя виртуальной машины;
"__VMX__" – ссылка на VMX файл виртуальной машины;
"__HOST__" – имя хоста (или прокси-сервера), через который выполняется соединение с консолью;
"__PORT__" – порт для подключения консоли;
"__TICKET__" – секретный ключ для проверки подлинности клиента.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" "http://www.w3.org/TR/REC-html40/strict.dtd">
<html>
<head>
<meta charset="utf-8"/>
<title>vCloud WebConsole: __VMNAME__</title>
<link rel="stylesheet" type="text/css" href="../manimg/wmks/css/css/wmks-all.css"/>
<script type="text/javascript" src="https://ajax.aspnetcdn.com/ajax/jQuery/jquery-1.8.3.js"></script>
<script type="text/javascript" src="https://ajax.googleapis.com/ajax/libs/jqueryui/1.8.16/jquery-ui.js"></script>
<script type="text/javascript" src="../manimg/wmks/wmks.min.js"></script>
</head>
<body style="overflow-x:hidden; overflow-y:hidden; padding:0; margin: 0;">
<div id="toolbar" style="position:relative; width:100%; height:5%;">
<table cellpadding="5" cellspacing="0" border="0" align="center">
<tr>
<td>
<input type="button" value="Send Ctrl+Alt+Del" onclick="wmks.sendKeyCodes([17,18,46])"/>
</td>
</tr>
</table>
</div>
<div id="wmksContainer" style="position:relative; width:100%; height:95%;"/>
<script>
var wmks = WMKS.createWMKS("wmksContainer", {
"VCDProxyHandshakeVmxPath": "__VMX__",
"useVNCHandshake": false,
"enableUint8Utf8": true,
"rescale": true,
"changeResolution": true,
"useUnicodeKeyboardInput": true,
"position": WMKS.CONST.Position.CENTER
});
wmks.register(WMKS.CONST.Events.CONNECTION_STATE_CHANGE, function(event, data) {
console.log("Connection state change : " + data.state);
});
wmks.register(WMKS.CONST.Events.ERROR, function(event, data) {
console.log("Connection error : " + data.error);
});
wmks.connect("wss://__HOST__/__PORT__;__TICKET__");
</script>
</body>
</html>
При отправке клиенту подменяем на этой форме следующие поля:
"__VMNAME__" – имя виртуальной машины;
"__VMX__" – ссылка на VMX файл виртуальной машины;
"__HOST__" – имя хоста (или прокси-сервера), через который выполняется соединение с консолью;
"__PORT__" – порт для подключения консоли;
"__TICKET__" – секретный ключ для проверки подлинности клиента.
Конечно же, не всё шло гладко: мы нередко натыкались на ошибки в облачной платформе, и реализация некоторых алгоритмов занимала больше времени, чем предполагалось. Были моменты, когда принять решение о том, что делать дальше, было очень сложно. Например, эпизод, когда при уже идущем бета-тестировании CloudLITE проявил себя баг vCloud Director. Поэтому создание новых виртуальных машин было невозможно.
Суть: если запросить через API список привязанных к виртуальному дата-центру IP-адресов, то вернётся максимум 128, даже если их больше. Подробное описание, если кому интересно, можно почитать здесь.
Было два варианта: искать обходные пути или обновлять Director. В первом случае решение было громоздким. Во втором случае существовал немалый риск возникновения сбоев серверов при накате апдейтов. К тому же мы интегрировали BILLmanager со старой версией; как всё будет работать с новой – неизвестно. Что делать?
В результате было принято решение обновить облачную платформу. К счастью, процесс прошёл без каких-либо происшествий, биллинговая платформа тоже заработала исправно.
Результаты
Благодаря профессионализму наших разработчиков и быстрой реакции DataLine на поступающие к ним запросы, задачу интеграции с vCloud мы решили без опозданий. Релиз Minimal Viable Product состоялся в изначально установленный срок. Кто первый угадает сколько строк кода при этом было написано – тому плюс в карму; засчитывается “попадание” в радиусе 100 строк.
Что мы сделали:
- Интуитивно понятный личный кабинет для клиентов, имеющий упрощённую панель управления виртуальными машинами. Стало возможным создать, запустить, остановить и удалить виртуальную машину; подключиться к ней через веб-консоль. Если нужно, то изменить количество ядер процессора, объём оперативной памяти, а также увеличить виртуальный жёсткий диск. Таким образом, в подавляющем большинстве случаев клиентам теперь не нужно обращаться к громоздкому интерфейсу vCloud Director.
- Предоставление доступа к услугам пока есть средства для оплаты одного дня.
- Возможность самостоятельной смены плательщика с физического лица на юридическое.
DataLine высоко оценил конечный результат.
Мы не остановились на достигнутом и выполнили стандартизацию взаимодействующего с vCloud обработчика. Теперь он доступен бесплатно в BILLmanager 5 Corporate для тех, кто планирует предоставлять облачные услуги на базе этого продукта от VMware. Чтобы задействовать данный обработчик, перейдите в меню “Интеграция” > “Обработчики услуг”, создайте новый для нужного типа услуг, выбрав модуль обработки “VMware vCloud Director”. Затем в списке тарифов выделите нужный, нажмите кнопку “Обработчики” и включите только что созданный. Всё, взаимодействие с облачной платформой теперь будет выполняться автоматически.
В дальнейших наших планах — разработка интеграции с другими облачными решениями. Следите за новостями!
P. S. Если вы хотите установить BILLmanager – инструкцию как это сделать можно найти здесь.
Поделиться с друзьями