Запуск MySQL на Amazon EC2 с EBS (Elastic Block Store) и Elastic Beanstalk

Я не использую Elastic Beanstalk, но руководство, которому вы следуете, предназначено для EC2 (с которым я определенно могу помочь). Первая трудность, с которой вы столкнулись, заключается в том, что вы используете руководство для Ubuntu 9.10; Linux от Amazon основан на CentOS / RHEL, поэтому вам будет легче, если вы найдете руководство по CentOS 6.

Корень вашей проблемы, похоже, связан с «прикреплением тома EBS». На EC2 вы можете подключить несколько томов EBS к одному экземпляру. У всех экземпляров есть корневой том - он может иметь поддержку S3 или EBS. Безусловно, предпочтительным подходом является использование корневого тома с поддержкой EBS (он стоит немного дороже, но компенсирует это гибкостью и надежностью). Экземпляр с корневым томом EBS почти всегда будет иметь этот том как / dev / sda1 - в современных системах Linux устройство фактически отображается как / dev / xvda1 (и именно последнее должно передаваться любым командам). (Помимо попытки отформатировать смонтированный том - вы пытались отформатировать свою корневую файловую систему с запущенным экземпляром - т.е. вы пытались стереть свою операционную систему, определенно не очень хорошая идея, если это вообще возможно).

В этом случае предлагается добавить второй том EBS - прикрепите его к вашему экземпляру (например, как / dev / sdh, но используйте / dev / xvdh для команд) и используйте его для хранения ваших данных MySQL. (Несмотря на то, что не используется Elastic Beanstalk) Мне трудно поверить, что Elastic Beanstalk не позволит вам присоединить второй том - поскольку эта функция является довольно важной для EC2.

Вы сможете получить список устройств EBS, запустив cat /proc/partitions (или используя fdisk -l).

Вы заметите, что на шаге 5 того, что вы сделали, вы фактически монтируете корневой том внутри себя (т.е. / dev / sda1 уже смонтирован как /, а вы монтируете / dev / sda1 как / ebsvol) - лучше всего Избегайте этого.

Кроме того, пока /etc/init.d/mysql stop не сработало, /etc/init.d/mysqld stop наверное, сработало бы. (Опять же, вы можете получить список скриптов init.d, запустив ls /etc/init.d - и должен иметь возможность использовать эти пути, как и вы, я обычно использую service хотя команда).

Базы данных MySQL должны находиться в / var / lib / mysql - однако ваши точки монтирования в / etc / fstab, вероятно, неверны (учитывая проблему с ebsvol в / ebsvol). Когда ты cd /var/lib/mysql вы должны увидеть свои базы данных - в противном случае ваши монтирования работали некорректно. (Убедитесь, что / var / lib / mysql смонтирован на другом устройстве с помощью mountpoint -d /var/lib/mysql и сравните устройство с cat /proc/partitions).

Основные идеи руководства, которому вы следуете, вполне верны - это обычная практика, когда ваши данные и базы данных размещаются на другом томе EBS, чем ваш корневой том, поскольку он предлагает множество преимуществ (производительность, простота создания моментальных снимков, простота перемещения между экземплярами и т. д.), а основные команды Linux не изменились - они предназначены только для Ubuntu.

Отмените крепления с помощью umount /path - как обычно, вам, конечно, нужно будет убедиться, что устройство не занято (что может не быть проблемой, если вам не удалось запустить MySQL). umount является временным, поэтому вам придется отредактировать /etc/fstab и удалите оттуда все ссылки на точки монтирования. Если у вас нет ничего ценного в экземпляре, вам может быть лучше начать заново (не потому, что сложно размонтировать несколько томов, а потому, что всегда легче понять, где вы ошиблись, когда начинаете с известное состояние).

Наконец, что касается MySQL на Elastic Beanstalk: суть Elastic Beanstalk должна заключаться в том, что он автоматически обрабатывает предоставление ресурсов и масштабирование - он по-прежнему основан на основных компонентах AWS (например, EC2, S3, ELB и т. Д.), Но он сделает для вас кое-что. Elastic Beanstalk обычно использует RDS для обработки баз данных MySQL. RDS - это версия MySQL, управляемая Amazon, которая упрощает подготовку и масштабирование экземпляров MySQL. Имейте в виду, что MySQL не поддается автомасштабированию без большой настройки. Вы не можете просто запустить второй экземпляр MySQL и распределить нагрузку между двумя экземплярами - вам нужно настроить репликацию, что может быть непростой задачей).

По сути, если вы можете настроить MySQL таким образом, чтобы он запускался с экземпляров вашего веб-сервера и мог автоматически масштабироваться, вам почти наверняка будет лучше использовать EC2 напрямую и не возиться с Elastic Beanstalk. Поэтому я бы предположил, что большинство людей на самом деле не настраивают MySQL на Elastic Beanstalk (вы могли бы настроить отдельный экземпляр MySQL, но если вы используете Beanstalk, RDS, вероятно, является более простым подходом).

Редактировать:

В отличие от множества других сервисов, которые работают в основном как черный ящик, Elastic Beanstalk действительно дает вам доступ к базовым компонентам. Тем не менее, если вы собираетесь вручную настраивать свои экземпляры EC2, вы теряете смысл Elastic Beanstalk.

Если вы используете EC2, есть несколько подходов к PHP / MySQL:

1. Вы можете разместить и свой веб-сервер, и базу данных в одном экземпляре - когда вы только начинаете, это может быть разумным подходом, однако он не очень хорошо масштабируется по горизонтали (но вы все равно можете масштабироваться по вертикали - используя более крупные экземпляры). Надеюсь, что к тому времени, когда вы превысите емкость x-large инстансов, вы сможете настроить более сложную настройку. Тем не менее, это плохо для избыточности - все находится в этом единственном экземпляре, и отказ любого компонента разрушает всю вашу установку.
2. Вы можете разместить свой веб-сервер на одном экземпляре и использовать RDS для своей базы данных. Большинство хорошо разработанных приложений облагают веб-сервер большей нагрузкой, чем базу данных (и в идеале нагрузка на базу данных будет смещена по чтению). В таком сценарии вы можете относительно легко масштабировать экземпляры своего веб-сервера (например, поместив их за ELB - с небольшим усилием, чтобы гарантировать, что все обслуживают один и тот же контент). RDS - это MySQL, управляемый AWS - он не совсем автоматический, но имеет большое значение для автомасштабирования. По сути, RDS предоставит несколько ведомых устройств только для чтения и одного ведущего устройства записи с несколькими горячими резервными копиями, которые могут взять на себя, если вам нужно. Обратной стороной является то, что вы платите за все запущенные экземпляры (и у вас нет полного контроля над некоторыми сложными настройками MySQL).
3. Последний подход заключался бы в использовании кластера веб-серверов и собственного кластера MySQL. По сути, вы можете масштабировать свои веб-экземпляры (как указано выше), а затем настроить экземпляры MySQL, которые будут масштабироваться отдельно. Вам нужно будет изучить репликацию MySQL (или, возможно, использовать кластер MySQL, если вы можете адаптировать свое приложение к его структурам данных).

Еще несколько ответов по той же теме:

• RDS против EC2
• Развертывание приложений
• Некоторые подходы к масштабированию EC2

Я обычно считаю, что решения в один клик - не лучший подход - мне нравится контроль, который предлагается делать вручную. Я обнаружил, что не только обычно получаю более индивидуальный и эффективный конечный результат, но также гораздо лучше понимаю, как работает система, что значительно упрощает определение того, что не так. Вы всегда можете автоматизировать свои собственные настройки, если хорошо разбираетесь в их тонкостях.

Следует иметь в виду, что RDS уже поддерживается EBS. RDS - это MySQL - это не что-то подобное или другая реляционная база данных. Это управляемый экземпляр MySQL, работающий на экземплярах EC2, поддерживаемых EBS. AWS будет поддерживать программное обеспечение в актуальном состоянии, и вы можете делать обычные снимки данных EBS и т. Д. У вас просто нет прямого доступа к базовому программному обеспечению, запущенному на экземпляре.

Что касается выбора операционной системы, то я неравнодушен к Linux от Amazon. Он хорошо поддерживается AWS и использует минимум ресурсов - он полностью совместим с CentOS (кстати, он включает репозиторий EPEL по умолчанию в последней версии). Обычная точка зрения - использовать любой дистрибутив Linux, который вам удобен, поскольку различия обычно незначительны (CentOS будет работать так же хорошо, как Ubuntu для инструкций, с которыми вы работаете - большинство команд (кроме apt-get) одинаковы в CentOS Учитывая, что моя собственная установка имеет базы данных на отдельном томе EBS с использованием Linux от Amazon, могу вас уверить, что это не сложно сделать).

Я бы предложил несколько основных соображений:

• Комфортность / готовность изучать системы Linux - если вы не против настроить свои собственные серверы и хотите лучше их понять, я бы определенно пошел по пути EC2. Вы получите лучший конечный результат, если сделаете все правильно, и в долгосрочной перспективе у вас будет больше возможностей. Я отмечу, однако, что если вы применяете этот подход, вы действительно хотите понимать, что делают выполняемые вами команды - простого следования руководству будет недостаточно, если вы действительно хотите его придерживаться.
• Бюджет - помните, что с AWS у всего есть цена. Чем больше AWS делает для вас, тем больше они взимают с вас. Экземпляр RDS стоит примерно на 30% больше, чем эквивалентный инстанс EC2 (а микроэкземпляр отсутствует), и если вам нужна предлагаемая ими избыточность, вам необходимо запустить несколько экземпляров RDS (и платить за каждый из них). Elastic Beanstalk предоставит вам экземпляры, балансировщики нагрузки, экземпляры RDS и т. Д. - затраты быстро увеличиваются.
• Время - если у вас нет времени, вы хотите нажать пару кнопок и получить что-то функциональное, Elastic Beanstalk, вероятно, лучший подход для вас.

Я бы посоветовал не использовать Elastic Beanstalk с MySQL, встроенным в ваш AMI - он, скорее всего, будет довольно нестабильным, если вообще будет работать. (Просто подумайте, что происходит, когда он добавляет и удаляет экземпляр в ваш кластер, или когда данные поступают в один экземпляр вместо другого ...)

Хорошо помнить о масштабируемости, но не оптимизируйте вещи слишком рано, иначе вы никогда ничего не добьетесь. Обязательно имейте это в виду, но если затраты (время, деньги и т. Д.) На масштабирование конкретного компонента в настоящий момент непрактичны, не беспокойтесь об этом слишком сильно - когда придет время масштабировать его, вы » Разберусь (в конце концов, большинство популярных сайтов начинали именно так).

Я бы посоветовал, если ваше приложение спроектировано таким образом, что оно может использовать некоторое кеширование, оно будет иметь большое значение.

Как правило, в EC2 лучше масштабировать по вертикали (для более крупных экземпляров), чем по горизонтали (для большего количества экземпляров). Однако для начала вы хотите выполнить масштабирование до двух экземпляров, чтобы иметь некоторую избыточность и минимизировать единичные точки отказа. Таким образом, возможный подход может быть следующим:

1. Начните с микроэкземпляра - разместите на нем и свою базу данных, и приложение (меньше этого вы не можете получить, что делает его хорошей отправной точкой).
   • Это, конечно, довольно легко масштабировать по вертикали, просто продолжайте обновлять свой экземпляр, пока вы не используете экземпляры x-large. Проблема сводится к избыточности - если с вашим экземпляром возникла проблема, ваше приложение отключено.
2. Теперь вы обычно хотите разделить свою базу данных на другой экземпляр (поскольку а) база данных будет видеть другую нагрузку, чем ваше приложение, и б) вы не можете автомасштабировать MySQL точно так же, как веб-серверы), но микро экземпляры просто не плохо справляется с нагрузкой, поэтому я бы предложил сначала перейти на более крупный экземпляр, по крайней мере, на небольшой, а затем, возможно, на средний (в основном идея состоит в том, что, когда вам понадобятся более крупные типы экземпляров, эффект, вероятно, будет больше)
3. Отделите вашу базу данных от вашего веб-сервера. Это позволит вам удовлетворить различные потребности в базах данных (например, с высокой памятью) по сравнению с веб-серверами (например, с более высоким ЦП) и различиями между тем, как вы масштабируете каждый (Рекомендуемое чтение). На этом этапе вы можете решить использовать RDS вместо запуска собственного экземпляра MySQL.
4. Теперь, когда у вас есть приложение, работающее на выделенном экземпляре, вы можете масштабировать его и не беспокоиться о своей базе данных - настройте автомасштабирование, чтобы получить некоторую избыточность. Это должно автоматически добавлять дополнительные узлы приложения, если какой-либо из них выходит из строя или когда нагрузка превышает указанные вами пороговые значения.
5. Добавьте второй узел базы данных и настройте репликацию между вашими узлами (если вы решите использовать кластер MySQL или решения NoSQL, вы также сможете настроить автоматическое масштабирование). На этом этапе все должно иметь избыточность, и даже в случае отказа узла вы все равно должны быть в сети.
6. Обновляйте по одному экземпляру до большего размера, если этого требует спрос.

Теперь, когда я немного ближе познакомился с Elastic Beanstalk и EC2, я решил отказаться от использования Elastic Beanstalk, потому что, хотя в нем есть несколько интересных функций, он слишком регламентирован на мой вкус. Например, мне не нравится тот факт, что я не могу изменить файл httpd.conf (ну, вы можете его изменить, но эти изменения исчезают при перезапуске вашей среды). Другая причина заключается в том, что единственный способ запустить Elastic Beanstalk с MySQL (правильно, то есть с автоматическим масштабированием и автоматическим резервным копированием) - это использовать RDS. Несмотря на то, что вы можете получить 3 месяца RDS бесплатно с новой подпиской, я не на том уровне, где мне нужны его функции, поэтому мне не стоит платить ~ 76 долларов в месяц за RDS.

Итог: если у вас достаточный объем трафика и вам нужно решение, которое масштабируется и само о себе позаботится, Elastic Beanstalk с RDS - отличный вариант. Мне нравится, что вы можете развернуть с помощью git. Это как Heroku для PHP. Руководство по началу работы должно включать инструкции по настройке MySQL.

Что я сделал: я решил использовать «Synthetic Elastic Beanstalk»: я могу воссоздать его функциональность с помощью различных предложений AWS и иметь гибкость, чтобы настроить его именно так, как я хочу. Пока я пинаю AWS, я установил MySQL в том же экземпляре EC2, что и мое веб-приложение (не идеально, если вам нужно масштабировать, но отлично подходит, пока вы изучаете основы использования AWS).

Это руководство это то, что я использовал для настройки стека LAMP на инстансе EC2 с AMI Amazon linux. Мне легче импортировать мои базы данных с помощью phpmyadmin. Поскольку я использую микро-экземпляр, он по умолчанию использует EBS, и вы можете делать снимки для резервного копирования данных. Я бы порекомендовал настроить инструменты CLI для EC2 и запустить

ec2-modify-instance-attribute --block-device-mapping "/dev/sda1=:false" i-xxxxxxx

где i-xxxxxxxx - это экземпляр EC2, к которому подключен том EBS. Это предотвращает удаление тома EBS в случае завершения работы вашего экземпляра. Поскольку этот том EBS - это место, откуда все запускается и где хранится моя база данных, я не хочу его терять (пока я играл с Elastic Beanstalk, мой экземпляр EC2 был остановлен, и Elastic Beanstalk мгновенно запустил другой с новым EBS том прикреплен, но я, к счастью, изменил параметр DeleteOnTermination на «false» для исходного тома EBS, поэтому я смог остановить новый экземпляр, отсоединить новый том EBS и присоединить старый том EBS, таким образом сохранив мою установку MySQL и база данных).

В целом, весь процесс переноса веб-приложения на AWS по-прежнему остается занозой в заднице. Теперь, когда я прошел через кривую обучения, я чувствую себя более комфортно, но не могу не думать, что для начала должна быть лучшая документация.