Добрый день.
Для конечного пользователя облако, реализованное на базе Eucalyptus, представляет собой аморфную сущность с неисчерпаемыми ресурсами: “Мне надо поднять X машин CentOS 5.3 и Y машин Windows Server 2003″. Пользователю неважно, как его запрос будет обработан. Ему нужен результат. С другой стороны, облако ничего не знает про потребности пользователя. “Какой пользователь? Какие машины? Cloud Controller приказов не получал”. По сути, Eucalyptus-облако – это “вещь в себе”. Виртуальные машины поднимаются, выполняют свои задачи и исчезают. В текущей версии Eucalyptus нет возможности сделать снапшот запущенный машины или даже просто приостановить/возобновить ее работу. Возможности хранения информации в Walrus тоже ограничены и не соответствуют потребностям автоматизатора. Таким образом, задача владельца облака – реализовать интерфейс управления, позволяющий отслеживать состояние облака, выполнять запросы на поднятие гостевых машин и извлекать результаты их работы. Рассмотрим варианты организации такого интерфейса для Eucalyptus.
Управление через Web
Пожалуй, это самый популярный на сегодня вариант пользовательского приложения. Настолько популярный, что даже VMware Server 2.0 поставляется без привычной консоли, а все управление виртуальными машинами производится из браузера. Для Eucalyptus есть свободно распространяемые приложения, позволяющие выполнять сходные операции. Вот два примера: Cloud42 и EC2Dream. Сложность работы с этими пакетами состоит в том, что они еще более сырые, чем сам Eucalyptus. Вот цитата для Cloud42: “We’re waiting for an update of Typica, then we’ll release the new version compatible with Eucalyptus”. По сему, гораздо более надежным представляется путь создания собственного интерфейса. В качестве примера рассмотрим такую задачу: вывести в браузер структуру облака и доступные ресурсы. Вот один из вариантов bash-скрипта topology, выполняющего запрос (Листинг 1):
export EC2_AMITOOL_HOME=/home/eucloud/share/web/amazon/ec2-ami-tools-1.3-26357/ export EC2_HOME=/home/eucloud/share/web/amazon/ec2-api-tools-1.3-30349/ export PATH=$PATH:${EC2_HOME}/bin export PATH=$PATH:${EC2_AMITOOL_HOME}/bin EUCA_KEY_DIR=$(dirname $(readlink -f ${BASH_SOURCE})) export EC2_PRIVATE_KEY=${EUCA_KEY_DIR}/euca2-admin-77155669-pk.pem export EC2_CERT=${EUCA_KEY_DIR}/euca2-admin-77155669-cert.pem export EUCALYPTUS_CERT=${EUCA_KEY_DIR}/cloud-cert.pem /home/eucloud/share/web/amazon/ec2-api-tools-1.3-30349/bin/ec2-describe-availability-zones verbose
А вот php-код, вызывающий этот скрипт (Листинг 2):
<?php exec("/home/eucloud/share/web/topology", $output); echo implode ("<br>", $output); ?>
В браузере получим вывод команды ec2-describe-availability-zones verbose (Листинг 3):
AVAILABILITYZONE os111clust UP os111y AVAILABILITYZONE |- vm types free / max cpu ram disk AVAILABILITYZONE |- m1.small 0009 / 0010 1 600 1 AVAILABILITYZONE |- c1.medium 0008 / 0009 1 800 2 AVAILABILITYZONE |- m1.large 0007 / 0008 1 1000 5 AVAILABILITYZONE |- m1.xlarge 0003 / 0003 2 2200 20 AVAILABILITYZONE |- c1.xlarge 0001 / 0001 2 4048 20 AVAILABILITYZONE |- os111a certs[cc=true,nc=true] @ Mon Aug 17 17:48:11 MSD 2009 AVAILABILITYZONE |- os111y certs[cc=true,nc=true] @ Mon Aug 17 17:48:11 MSD 2009
К этим результатам мы еще вернемся, а пока поговорим о web-интерфейсе в целом. Такой пульт управления удобен, скорее, для демонстрационных целей. Да, можно навесить кнопки на запуск основных EC2-инструментов (к примеру, ec2-run-instances, ec2-terminate-instances, ec2-describe-instances и др.). Да, можно получить их результаты в браузере. Но в то же время, в повседневной работе, такой интерфейс бесполезен. К примеру, при тестировании распределенных систем есть необходимость регулярно поднимать N виртуальных машин по выходу нового билда. По сути, запуск гостевых машин – это промежуточный этап между выходом новой версии разрабатываемой системы и ее тестированием: готовится среда для развертывания всей инфраструктуры. Если сборка билда и дымовое тестирование автоматизированы, то устраивать между ними антракт в виде нажатия на кнопку нецелесообразно. Нужен диспетчер – набор инструментов для управления облаком, который можно интегрировать в общий процесс сборки и тестирования билда. Рассмотрим варианты управления облаком с Windows- и Linux-машины (удаленнное выполнение команд на контроллере по протоколу ssh).
Диспетчер
Если в роли диспетчера выступает Linux-машина, то создадим на ней ssh-ключи с помощью ssh-keygen. В ~/.ssh/ будут созданы два ключа: приватный и публичный (id_rsa и id_rsa.pub). Публичный ключ (id_rsa.pub) скопируем в файл <user_home_dir>/.ssh/authorized_keys на любом узле облака. В роли <user_home_dir> выступает домашний каталог пользователя, имеющего права на запуск EC2-инструментов (скажем, root). Дальше все просто: доступ к контроллеру узла по ssh и запуск требуемого скрипта:
ssh 10.30.33.66 "/home/work/custom_script"
Пример запуска custom_script чуть ниже.
Если в роли диспетчера выступает Windows-машина, то воспользуемся комплектом инструментов Putty, представляющего собой реализацию ssh-клиента. С помощью PuTTYgen создадим два ключа (private и public). В файл ~/.ssh/authorized_keys на узле облака поместим публичный (public) ключ. Второй ключ (private) должен быть на Windows-машине. Далее, воспользуемся утилитой plink для удаленного выполнения команд. Вот пример запуска (Листинг 4):
D:\Distrib\PuTTY>plink.exe 10.30.33.66 -i D:\Work\sshkeys\priv.ppk -l root /home/work/custom_script Authenticating with public key "rsa-key-20090803" RESERVATION r-55B509BF admin admin-default INSTANCE i-57100A60 emi-22600CB2 0.0.0.0 0.0.0.0 pending 0 m1.large 2009-08-17T15:45:41+0000 eki-9028 1380 eki-8F9616D5
В рассмотренных примерах custom_script выполняет запуск одного экземпляра гостевой машины. Вот код скрипта (Листинг 5):
export EC2_AMITOOL_HOME=/home/eucloud/share/amazon/ec2-ami-tools-1.3-26357/ export EC2_HOME=/home/eucloud/share/amazon/ec2-api-tools-1.3-30349/ export PATH=$PATH:${EC2_HOME}/bin export PATH=$PATH:${EC2_AMITOOL_HOME}/bin source /home/eucloud/share/euca2-admin-x509/eucarc ec2-run-instances emi-22600CB2 -n 1 -t m1.large --ramdisk eki-8F9616D5
Подобным образом можно запускать любые другие ec2-утилиты, передавая им параметры по своему усмотрению. Для имеющихся ec2-инструментов можно написать утилиты-оболочки, которые будут выполнять специфические задачи автоматизатора. Например, запуск ec2-run-instances с указанием исходного emi-образа и количества виртуальных машин. Или останов всех машин, поднятых по определенному emi, c помощью ec2-terminate-instances.
Еще один хороший пример: анализ запроса к облаку на предмет возможности этот запрос выполнить. Администратор облака знает, что ресурсы облака небеспредельны. Поэтому, когда поступает запрос поднять N машин, а текущие возможности облака позволяют поднять лишь N - 5, то эту ситуацию надо обработать: либо предложить пользователю изменить запрос, либо поднять столько машин, сколько физически возможно. Как провести такой анализ? Вернемся к команде ec2-describe-availability-zones verbose (Листинг 3 в разделе “Управление через Web”). Виртуальные машины в Eucalyptus соответствуют одному из пяти типов: m1.small, c1.medium, m1.large, m1.xlarge, c1.xlarge. Каждый тип определяется количеством процессоров (cpu), объемом оперативной памяти (ram) и размером жесткого диска (disk), которые будут у запускаемой виртуальной машины. Значения, соответствующие каждому типу, можно менять в интерфейсе администратора (https://your_cloud_controller:84443/). Команда ec2-describe-availability-zones говорит о том, сколько машин определенного типа облако способно поднять в данный момент времени. Рассмотрим вот эту строку:
AVAILABILITYZONE |- vm types free / max cpu ram disk AVAILABILITYZONE |- m1.large 0007 / 0008 1 1000 5
Строка говорит следующее: ресурсы облака позволяют поднять максимум 8 машин типа m1.large (поле max), но в данный момент времени ресурсы облака частично заняты, и потому оно сможет поднять лишь 7 машин этого типа (поле free). Обладая этой информацией, можно обрабатывать запросы пользователя в своих утилитах, сопоставляя его желания с имеющимися возможностями. Awk/grep/perl спешат на помощь и позволяют легко справиться с подобными задачами.
Работа с запущенными виртуальными машинами
Машины (instances) поднимаются с определенного образа (image). Если мы поднимем N машин из образа X, то у каждой из N машин будет одно и то же имя. В принципе, к машинам можно обращаться по IP-адресу, но в NetBIOS-сетях дупликаты имен нежелательны. Есть два варианта решить эту задачу. Первый вариант: создавать образ таким образом, чтобы при старте машины выполнялся скрипт, автоматически изменяющий имя машины. Второй вариант: решать эту задачу с диспетчера. По команде ec2-describe-instances доступны IP-адреса запущенных машин. Дальнейшие действия определяются операционной системой гостевой машины:
Если это Linux-машина, то к ней можно подключиться по ssh представленным выше способом и изменить ее имя в соответствующих файлах (/etc/HOSTNAME, /etc/sysconfig/network или другие в зависимости от дистрибута).
Если это Windows-машина, то на помощь придут инструменты Sysinternals. Вот один из вариантов (Листинг 6):
net use \\10.30.36.216\C$ password /user:Administrator copy newsid.exe \\10.30.36.216\C$\Windows\system32\ psexec.exe \\10.30.36.216 -u Administrator -p password newsid.exe /a blablabla
Пароль администратора известен (он задавался при создании образа). Утилита newsid.exe копируется на удаленную машину и затем запускается с помощью psexec.exe, изменяя имя машины.
Теперь облако в наших руках. Все готово к решению задач, стоящих перед автоматизатором. Оставайтесь с нами и зовите друзей. До встречи.
Что такое качество программного обеспечения и как его улучшить: теория и практика, задачи и решения, подводные камни и обходные пути.
Pingback : OpenQuality.ru | Мастерство тестировщика: перепросмотр | October 4, 2009
[…] Бесплатный ESXi или же стек ESX/vCenter/LabManager? А может быть, Eucalyptus? Как новые технологии смогут повысить эффективность […]
Pingback : OpenQuality.ru | Eucalyptus: поднятие гостевых Windows-машин | October 15, 2009
[…] обычный […]
Pingback : OpenQuality.ru | Тайные знания: как сохранить? | December 3, 2009
[…] Представим такую картину: надо сохранить 30 ссылок по Eucalyptus, а потом 20 ссылок по Selenium. В таких случаях на помощь […]
Pingback : OpenQuality.ru | Кому в облаках жить хорошо? | January 17, 2010
[…] систем на своих площадках. Хороший пример – Eucalyptus. Открытый код, слегка сыроват, но можно заточить под […]