Моя компания переводит наш хостинг на Amazon, и я работаю над всеми проблемами миграции. Это был довольно сложный переход с физического оборудования на временные виртуальные машины.
Одна из последних проблем — выяснить, как управлять нашими EBS и снимками. Поскольку в настоящее время нет возможности назвать их описательно или добавить значение, мне интересно, как администраторы управляют своими ресурсами. Это не такая уж большая проблема с одним или двумя серверами, но как те, кто работает на нескольких серверах, справляются с этим? Все используют сторонние инструменты (вроде RightScale/Scalr), когда у них несколько серверов? Или вы ведете вики или другую вспомогательную документацию?
решение1
Я использую ec2-consistent-snapshot (http://alestic.com/2009/09/ec2-consistent-snapshot) для создания снимков (на базе RHEL/CentOS, производной от Amazon Linux) - он написан на Perl и напрямую использует API. Вы указываете тома, которые хотите сделать снимками, и он позволяет вам добавлять описание.
(В консоли AWS вы можете добавлять теги, если вам нужен более детальный контроль, но для простого резервного копирования это может быть необязательно и пока не поддерживается модулем Perl, использованным выше (Net::Amazon::EC2)).
Приведенный выше скрипт не удаляет моментальные снимки (только создает новые - последовательно (т.е. он может заморозить диск/базу данных перед моментальным снимком). Поскольку он довольно часто используется, и я не смог найти совместимый скрипт Perl для удаления старых моментальных снимков, я написал свой собственный (http://www.thatsgeeky.com/2011/06/rotating-ebs-snapshots-ec2-prune-snapshots/). Он хорошо справляется со своей задачей (ротация дед-отец-сын) и использует те же зависимости и параметры, что и приведенный выше скрипт.
Конечно, оба настроены на запуск через Cron.
(Теоретически, должно быть достаточно просто подключить несколько похожих скриптов (например, написанных на PHP и Ruby) к базе данных и вести собственный журнал томов и сделанных снимков — каждый снимок имеет уникальный идентификатор, поэтому, если записать его, любая дальнейшая внутренняя организация будет легко возможна. [Однако для целей резервного копирования идентификатора тома и даты часто бывает достаточно])
Не используйте инструменты CLI — они написаны на Java и работают смехотворно медленно по сравнению с любыми прямыми реализациями API.
решение2
Постепенно Amazon добавляет все функции, необходимые для эффективного управления, которое необходимо, если Amazon хочет привлечь корпоративный рынок. Были добавлены теги и улучшения, позволяющие пользователю иметь доступ только к определенным функциям. В будущем наверняка будут реализованы скрипты и развертывание. Я добавляю эти функции в свой бесплатный инструмент ElastDream.
решение3
За исключением написания собственного инструмента для индексации EBS и идентификаторов снимков по текстовым меткам, я обнаружил, что использование бесплатногоПравыйМасштабучетная запись и назначение псевдонимов — лучший способ управления нашими томами и снимками EBS.
Я лично считаю, что невозможность назначить легко запоминающуюся метку экземпляру EC2, AMI или тому — это большой пробел в текущем предложении Amazon. Мне это кажется очевидным решением.
решение4
ElasticFox, безусловно, один из самых удобных инструментов для (ручного) управления EC2. Но ключевая часть — регулярное создание образов ваших экземпляров, настройка автоматической инициализации при запуске нового экземпляра: разбиение на разделы и монтирование эфемерных дисков, монтирование тома EBS, как только он станет доступен, восстановление файлов и баз данных из EBS, общего хранилища или S3, запуск служб (MySQL, Apache, Tomcat, как хотите).