На habrahabr.ru уже появлялись статьи, рассказывающие о работе с сервисами cloud computing от Amazon – Amazon Web Services. Например, здесь подробно описано, как начать работать с AWS и о том, как работать с инстансом ubuntu. Я же остановлюсь на некоторых особенностях работы с инстансами под Windows и MS SQL Server в регионе EU.
Задача, которую я перед собой поставил, заключается в оценке применимости и отработке приемов работы с сервисами Amazon Web Services (Elastic Compute Cloud — EC2, Elastic Block Store — EBS, Simple Storage Service — S3 и т.д.) для ряда наших проектов.
Скажу сразу, что Amazon не является единственным игроком на этом рынке, я лично смотрел еще на rackspace cloud (ex-mosso), и их подход мне в чем-то нравится больше. Но у rackspace cloud, к сожалению, пока нет предложения серверов под Windows.
Оговорюсь сразу, до этого особого опыта работы с EC2 у меня не было — я поднимал пару инстансов (серверов) для интереса, но к реальному применению не приближался. Так что рассказ будет из серии «для чайников».
Наиболее важный момент, который нужно постоянно держать в голове при использовании EC2 — неперсистентность инстансов (серверов). Об этом писали, но я повторюсь — Ваш сервер существует, пока он запущен. Как только Вы его остановили или он «упал» сам — все, его больше нигде нет, также как и всех сделанных настроек, установленного на него ПО, данных и т.д.
Рекомендуемый выход из этой ситуации — сохранение образа сервера после установки и настройки всего необходимого ПО. В рамках этой процедуры сервер останавливается, делается снимок его содержимого, этот снимок сохраняется на сервисе S3, после чего его нужно зарегистрировать в качестве AMI – образа сервера, который может быть запущен в EC2. Кстати, у rackspace cloud сервера персистентны, чем они активно и обоснованно гордятся.
Этого достаточно для серверов приложений, не хранящих никаких ценных данных, но явно не подходит для серверов БД. Для них существует отдельный сервис EBS – Elastic Block Store, виртуализирующий инфраструктуру хранения блочных данных. С точки зрения привычных представлений EBS выглядит как том на внешнем дисковом массиве – его можно отключить от одного инстанса и подключить к другому. К одному серверу можно подключить несколько томов EBS, а вот подключить один том EBS к нескольким серверам нельзя, таким образом классические High Availability-кластера в такую архитектуру не вписываются.
В целом, на понятийном уровне все довольно просто, надо только соблюдать дисцплину и четко разделять, грубо говоря, код и данные. Что же с реализацией?
Свой тест я решил проводить на регионе eu-west-1 (всего их два, еще есть us-east-1, с которого и началось развитие AWS), что было обусловлено тем, что наши проекты ориентированы на аудиторию РФ и СНГ, а качество связи с европейским регионом все же лучше, чем с американским. В то же время, у использования сервисов в европейском регионе есть минус – они дороже.
В общем, я создал с помощью AWS Management Console экземпляр сервера на платформе Windows, содержащий MS SQL, и том EBS для хранения БД. Сервер стартовал довольно продолжительное время – около 20 минут. После старта я попытался подключить том EBS к серверу, однако у меня ничего не получилось – в форме подключения тома сервер отсутствовал в выпадающем списке. В процессе попыток я установил себе Elasticfox – плагин к Firefox, дающий более «продвинутый» интерфейс к EC2, чем AWS Management Console. Посредством Elasticfox мне удалость выяснить, что экземпляр сервера и том EBS были созданы в разных зонах доступности – сервер в eu-west-1b, а том в eu-west-1a, из-за чего, видимо, не могут быть подключены друг к другу.
Пришлось пересоздать сервер в зоне eu-west-1a, после чего том нормально подключился. В Elasticfox подключение тома можно выполнить как на закладке Instances (Attach an EBS Volume), так и на закладке Volumes and Snapshots (Attach this volume), в AWS Management Console – через меню Volumes -> Attach Volume.
После этого я зашел на сервер по RDP, запросив административный пароль на сервер (это можно сделать как через AWS Management Console – Instances -> More Actions -> Get Windows Password, так и через Elasticfox – Get Administrator Password). Проинициализировал через Disk Management и отформатировал том EBS. Далее создал свою БД, разместив ее на подключенном томе, выполнил свои скрипты. На выходе у меня был рабочий сервер БД. Что дальше?
Дальше, собственно, нужно было запустить процедуру снятия образа (Bundle image). Это делается нажатием одной кнопки в AWS Management Console (Instances -> More Actions -> Bundle Windows AMI) или Elasticfox (Bundle into an AMI). В форме снятия образа нужно ввести имя корзины (bucket) в S3, в которой образ будет храниться, и имя образа.
Конечно, это не заработало.
Процедура запустилась, погасила сервер, и сняла с него образ, последовательно показав прогресс в 3, 50 и 90%. Однако в итоге процедура выдала следующую ошибку — (301): The bucket you are attempting to access must be addressed using the specified endpoint. Please send all future requests to this endpoint.
Поиск решений дал понять, что проблема связана с тем, что сервер находится в регионе eu-west-1, а процедура bundle в GUI-консолях, что в AWS Management Console, что в Elasticfox пытается сохранить его в S3 американского региона, при этом более гибкие настройки возможны только через API Tools – набор утилит командной строки для работы с EC2.
API Tools был немедленно загружен. Инсталлятор как таковой создателями не предусмотрен, утилиты просто разархивируются в каталог, а дальнейшая настройка происходит путем задания переменных окружения ОС. В моем случае это Windows 7 RC, так что в этой части рассказа ничего полезного коллегам, работающим под *nix, я сообщить не смогу.
Во-первых, для работы API Tools нужна Java. Так что, если ее нет, то ее надо установить, а API Tools сообщить ее местонахождение с помощью переменной среды JAVA_HOME. В документации по API Tools ошибочно указано, что JAVA_HOME должна содержать путь к подкаталогу bin (в котором находится файл java.exe) того каталога, куда установлена Java. Это, по-видимому, не так, работоспособная конфигурация получается, если переменная содержит именно путь к каталогу Java (в моем случае – “C:\Program Files (x86)\Java\jre6\”).
Во-вторых, нужно указать путь к самим API Tools, задав переменную EC2_HOME. Она, в свою очередь, должна указывать на каталог, в который были разархивированы API Tools (в моем случае — C:\ec2-api-tools-1.3-36506).
В-третьих, при работе утилиты аутентифицируются в EC2 используюя сертификат и закрытый ключ, которые Вы создали в самом начале работы с EC2 на странице Your Account -> Access Identifiers (см. http://aws-portal.amazon.com/gp/aws/developer/account/index.html?action=access-key). Вы должны указать, какие сертификат и ключ использовать с помощью переменных EC2_CERT и EC2_PRIVATE_KEY.
При задании переменных не забывайте, что если Вы определите их с помощью команды SET, как предлагается в документации, то эти значения будут распространяться лишь на текущую сессию командной строки, что Вам вряд ли надо. Для того, чтобы переменные были заданы постоянно, используйте команду SETX или GUI Windows: System Properties -> Advanced -> Environment Variables.
После этого все просто – с помощью команды ec-describe-regions Вы запрашиваете у EC2 список регионов с их URLами и определяете переменную EC2_URL со значением, соответвующем Вашей зоне (в моем случае — eu-west-1.ec2.amazonaws.com).
Далее запускаете команду ec2-bundle-instance:
ec2-bundle-instance <имя_экземпляра> -b <имя корзины> -p <имя образа> -o <идентификатор ключа доступа AWS> -w <секретный ключ доступа AWS>
Идентификатор ключа доступа AWS (Access Key ID) и секретный ключ доступа AWS (Secret Access Key) копируются все с той же страницы http://aws-portal.amazon.com/gp/aws/developer/account/index.html?action=access-key">Your Account -> Access Identifiers.
И опять ничего не получается. Т.е. сервер гасится, образ снимается, но сохранение не происходит – выдается та же ошибка.
Я думаю, что для решения этой проблемы есть несколько способов. У меня сработал такой – с помощью еще одного плагина для Firefox – S3Fox, служащего для управления сервисом Amazon S3, нужно вручную содать корзину, при создании отметив, что ее нужно создать в регионе EU. После этого Вы указываете название корзины в качестве параметра команды ec2-bundle-instance и все получается – образ Вашего сервера попадает в созданную корзину.
Финальный штрих – зарегистрировать образ Вашего сервера в качестве AMI с помощью команды ec2-register:
ec2-register <имя корзины>/<имя манифест-файла>
Имя манифест-файла можно посмотреть в корзине через S3Fox, оно имеет вид <имя образа>.manifest.xml. В качестве результата Вам будет выдано имя Вашего AMI.
После этого Ваш AMI готов к запуску в том регионе, где Вы его создали и зарегистрировали. AMI можно мигрировать между регионами, но я этого пока не делал, поэтому писать об этом не буду, см. документацию.
Запустить AMI Вы можете как через AWS Management Console, так и через Elasticfox или API Tools. После запуска подключите к серверу том EBS (это можно сделать только после того, как сервер полностью загрузился), подключитесь к нему через RDP и используйте Disk Management для того, чтобы инициализировать том EBS для использования с данным экземпляром сервера (Reactivate Disk). После этого Вы увидите диск в системе и сможете работать с данными на нем. В моем случае мне пришлось еще перезапустить MS SQL для того, чтобы он поднял БД, расположенную на томе EBS.
На мой взгляд, успешное прохождение данной процедуры является водоразделом между баловством с EC2 и каким-либо его полезным применением – даже для тестовых целей: вряд ли Вам захочется каждый раз возиться с новым экземпляром сервера, устанавливая туда нужное Вам ПО и заливая данные, для того, чтобы потерять всю проделанную работу при его выключении. Можно возразить, что сервер можно и не выключать, но, во-первых, это не решает всех проблем – он может упасть и без Вашего участия, во-вторых, это лишает смысла использование EC2 – Вы будете платить за постоянно запущенный сервер, даже если он Вам не нужен, а в случае сервера под Windows и с MS SQL это вполне заметные деньги!
В следующей статье я продолжу описание развертывания и эксплуатации нашего проекта на Amazon EC2.
Задача, которую я перед собой поставил, заключается в оценке применимости и отработке приемов работы с сервисами Amazon Web Services (Elastic Compute Cloud — EC2, Elastic Block Store — EBS, Simple Storage Service — S3 и т.д.) для ряда наших проектов.
Скажу сразу, что Amazon не является единственным игроком на этом рынке, я лично смотрел еще на rackspace cloud (ex-mosso), и их подход мне в чем-то нравится больше. Но у rackspace cloud, к сожалению, пока нет предложения серверов под Windows.
Оговорюсь сразу, до этого особого опыта работы с EC2 у меня не было — я поднимал пару инстансов (серверов) для интереса, но к реальному применению не приближался. Так что рассказ будет из серии «для чайников».
Итак, этап 1. Развертывание инстанса MS SQL, создание БД на постоянном томе EBS, сохранение AMI (Amazon Machine Image) для последующего использования
Наиболее важный момент, который нужно постоянно держать в голове при использовании EC2 — неперсистентность инстансов (серверов). Об этом писали, но я повторюсь — Ваш сервер существует, пока он запущен. Как только Вы его остановили или он «упал» сам — все, его больше нигде нет, также как и всех сделанных настроек, установленного на него ПО, данных и т.д.
Рекомендуемый выход из этой ситуации — сохранение образа сервера после установки и настройки всего необходимого ПО. В рамках этой процедуры сервер останавливается, делается снимок его содержимого, этот снимок сохраняется на сервисе S3, после чего его нужно зарегистрировать в качестве AMI – образа сервера, который может быть запущен в EC2. Кстати, у rackspace cloud сервера персистентны, чем они активно и обоснованно гордятся.
Этого достаточно для серверов приложений, не хранящих никаких ценных данных, но явно не подходит для серверов БД. Для них существует отдельный сервис EBS – Elastic Block Store, виртуализирующий инфраструктуру хранения блочных данных. С точки зрения привычных представлений EBS выглядит как том на внешнем дисковом массиве – его можно отключить от одного инстанса и подключить к другому. К одному серверу можно подключить несколько томов EBS, а вот подключить один том EBS к нескольким серверам нельзя, таким образом классические High Availability-кластера в такую архитектуру не вписываются.
В целом, на понятийном уровне все довольно просто, надо только соблюдать дисцплину и четко разделять, грубо говоря, код и данные. Что же с реализацией?
Свой тест я решил проводить на регионе eu-west-1 (всего их два, еще есть us-east-1, с которого и началось развитие AWS), что было обусловлено тем, что наши проекты ориентированы на аудиторию РФ и СНГ, а качество связи с европейским регионом все же лучше, чем с американским. В то же время, у использования сервисов в европейском регионе есть минус – они дороже.
В общем, я создал с помощью AWS Management Console экземпляр сервера на платформе Windows, содержащий MS SQL, и том EBS для хранения БД. Сервер стартовал довольно продолжительное время – около 20 минут. После старта я попытался подключить том EBS к серверу, однако у меня ничего не получилось – в форме подключения тома сервер отсутствовал в выпадающем списке. В процессе попыток я установил себе Elasticfox – плагин к Firefox, дающий более «продвинутый» интерфейс к EC2, чем AWS Management Console. Посредством Elasticfox мне удалость выяснить, что экземпляр сервера и том EBS были созданы в разных зонах доступности – сервер в eu-west-1b, а том в eu-west-1a, из-за чего, видимо, не могут быть подключены друг к другу.
Пришлось пересоздать сервер в зоне eu-west-1a, после чего том нормально подключился. В Elasticfox подключение тома можно выполнить как на закладке Instances (Attach an EBS Volume), так и на закладке Volumes and Snapshots (Attach this volume), в AWS Management Console – через меню Volumes -> Attach Volume.
После этого я зашел на сервер по RDP, запросив административный пароль на сервер (это можно сделать как через AWS Management Console – Instances -> More Actions -> Get Windows Password, так и через Elasticfox – Get Administrator Password). Проинициализировал через Disk Management и отформатировал том EBS. Далее создал свою БД, разместив ее на подключенном томе, выполнил свои скрипты. На выходе у меня был рабочий сервер БД. Что дальше?
Дальше, собственно, нужно было запустить процедуру снятия образа (Bundle image). Это делается нажатием одной кнопки в AWS Management Console (Instances -> More Actions -> Bundle Windows AMI) или Elasticfox (Bundle into an AMI). В форме снятия образа нужно ввести имя корзины (bucket) в S3, в которой образ будет храниться, и имя образа.
Конечно, это не заработало.
Процедура запустилась, погасила сервер, и сняла с него образ, последовательно показав прогресс в 3, 50 и 90%. Однако в итоге процедура выдала следующую ошибку — (301): The bucket you are attempting to access must be addressed using the specified endpoint. Please send all future requests to this endpoint.
Поиск решений дал понять, что проблема связана с тем, что сервер находится в регионе eu-west-1, а процедура bundle в GUI-консолях, что в AWS Management Console, что в Elasticfox пытается сохранить его в S3 американского региона, при этом более гибкие настройки возможны только через API Tools – набор утилит командной строки для работы с EC2.
API Tools был немедленно загружен. Инсталлятор как таковой создателями не предусмотрен, утилиты просто разархивируются в каталог, а дальнейшая настройка происходит путем задания переменных окружения ОС. В моем случае это Windows 7 RC, так что в этой части рассказа ничего полезного коллегам, работающим под *nix, я сообщить не смогу.
Во-первых, для работы API Tools нужна Java. Так что, если ее нет, то ее надо установить, а API Tools сообщить ее местонахождение с помощью переменной среды JAVA_HOME. В документации по API Tools ошибочно указано, что JAVA_HOME должна содержать путь к подкаталогу bin (в котором находится файл java.exe) того каталога, куда установлена Java. Это, по-видимому, не так, работоспособная конфигурация получается, если переменная содержит именно путь к каталогу Java (в моем случае – “C:\Program Files (x86)\Java\jre6\”).
Во-вторых, нужно указать путь к самим API Tools, задав переменную EC2_HOME. Она, в свою очередь, должна указывать на каталог, в который были разархивированы API Tools (в моем случае — C:\ec2-api-tools-1.3-36506).
В-третьих, при работе утилиты аутентифицируются в EC2 используюя сертификат и закрытый ключ, которые Вы создали в самом начале работы с EC2 на странице Your Account -> Access Identifiers (см. http://aws-portal.amazon.com/gp/aws/developer/account/index.html?action=access-key). Вы должны указать, какие сертификат и ключ использовать с помощью переменных EC2_CERT и EC2_PRIVATE_KEY.
При задании переменных не забывайте, что если Вы определите их с помощью команды SET, как предлагается в документации, то эти значения будут распространяться лишь на текущую сессию командной строки, что Вам вряд ли надо. Для того, чтобы переменные были заданы постоянно, используйте команду SETX или GUI Windows: System Properties -> Advanced -> Environment Variables.
После этого все просто – с помощью команды ec-describe-regions Вы запрашиваете у EC2 список регионов с их URLами и определяете переменную EC2_URL со значением, соответвующем Вашей зоне (в моем случае — eu-west-1.ec2.amazonaws.com).
Далее запускаете команду ec2-bundle-instance:
ec2-bundle-instance <имя_экземпляра> -b <имя корзины> -p <имя образа> -o <идентификатор ключа доступа AWS> -w <секретный ключ доступа AWS>
Идентификатор ключа доступа AWS (Access Key ID) и секретный ключ доступа AWS (Secret Access Key) копируются все с той же страницы http://aws-portal.amazon.com/gp/aws/developer/account/index.html?action=access-key">Your Account -> Access Identifiers.
И опять ничего не получается. Т.е. сервер гасится, образ снимается, но сохранение не происходит – выдается та же ошибка.
Я думаю, что для решения этой проблемы есть несколько способов. У меня сработал такой – с помощью еще одного плагина для Firefox – S3Fox, служащего для управления сервисом Amazon S3, нужно вручную содать корзину, при создании отметив, что ее нужно создать в регионе EU. После этого Вы указываете название корзины в качестве параметра команды ec2-bundle-instance и все получается – образ Вашего сервера попадает в созданную корзину.
Финальный штрих – зарегистрировать образ Вашего сервера в качестве AMI с помощью команды ec2-register:
ec2-register <имя корзины>/<имя манифест-файла>
Имя манифест-файла можно посмотреть в корзине через S3Fox, оно имеет вид <имя образа>.manifest.xml. В качестве результата Вам будет выдано имя Вашего AMI.
После этого Ваш AMI готов к запуску в том регионе, где Вы его создали и зарегистрировали. AMI можно мигрировать между регионами, но я этого пока не делал, поэтому писать об этом не буду, см. документацию.
Запустить AMI Вы можете как через AWS Management Console, так и через Elasticfox или API Tools. После запуска подключите к серверу том EBS (это можно сделать только после того, как сервер полностью загрузился), подключитесь к нему через RDP и используйте Disk Management для того, чтобы инициализировать том EBS для использования с данным экземпляром сервера (Reactivate Disk). После этого Вы увидите диск в системе и сможете работать с данными на нем. В моем случае мне пришлось еще перезапустить MS SQL для того, чтобы он поднял БД, расположенную на томе EBS.
На мой взгляд, успешное прохождение данной процедуры является водоразделом между баловством с EC2 и каким-либо его полезным применением – даже для тестовых целей: вряд ли Вам захочется каждый раз возиться с новым экземпляром сервера, устанавливая туда нужное Вам ПО и заливая данные, для того, чтобы потерять всю проделанную работу при его выключении. Можно возразить, что сервер можно и не выключать, но, во-первых, это не решает всех проблем – он может упасть и без Вашего участия, во-вторых, это лишает смысла использование EC2 – Вы будете платить за постоянно запущенный сервер, даже если он Вам не нужен, а в случае сервера под Windows и с MS SQL это вполне заметные деньги!
В следующей статье я продолжу описание развертывания и эксплуатации нашего проекта на Amazon EC2.