Я новичок в Amazon AWS. Часто я слышу о людях, создающих экземпляры и почти мгновенно помещающих их за балансировщик нагрузки в существующий кластер.
В традиционном мире управляемых машин это будет включать в себя подготовку оборудования, установку ОС, настройку сети на машине и, как только сеть станет доступной, использование инструмента по вашему выбору, например CFengine, Puppet или Chef, для начальной загрузки машины на основе свой класс.
Похоже, существуют «ярлыки», с помощью которых можно запустить и запустить сервер определенного класса в Amazon EC2. Если на моем сервере работает определенный стек, такой как erlang, tomcat6 и т. Д., Какой самый быстрый способ их запустить и подключить к балансировщику нагрузки Amazon? От сети к программному стеку и настройке ядра? Это комбинация создания AMI и запуска такого инструмента, как Puppet, против нового экземпляра?
Любая идея
Короткий ответ:
Это зависит от вашего приложения - AMI всегда будет отправной точкой, от того, насколько вам нужно настроить свой экземпляр при его запуске, будет зависеть, что еще вам нужно, помимо простого примера «экземпляры автомасштабирования за балансировщиком нагрузки».
Не такой короткий ответ:
Экземпляры на EC2 очень похожи на VPS - по сути, это виртуальные машины (Amazon использует виртуализацию Xen). Ключевое различие, которое я вижу между VPS и «облачными» серверами, заключается в простоте развертывания - подготовка и добавление десятка экземпляров или нескольких сотен ГБ хранилища в «облаке» должно быть тривиальной задачей.
Поскольку Amazon использует виртуальные машины, у них есть «образы» этих машин. Эти образы ссылаются на хранилище и содержат ссылку на ядро по умолчанию (которое вы можете изменить). Содержимое этого образа обычно используется для создания корневого тома, подключенного к экземпляру.
Вы в значительной степени застряли в использовании (довольно многочисленных) ядер, которые предоставляет Amazon - компиляция собственного, как правило, не вариант, - но вы можете установить большинство параметров и использовать доступные модули ядра для достижения желаемого. После того как вы создали свой собственный AMI, все экземпляры, которые вы запускаете из него, будут одинаковыми (исключая любые скрипты, которые AMI запускает для настройки). Это делает его отправной точкой почти для всех случаев.
У «виртуальной» природы вещей есть определенные преимущества. Например, вы можете переключить корневой том, просто остановив экземпляр, отсоединив корневой том, подключив новый том и запустив резервное копирование экземпляра. Точно так же вы можете изменить тип экземпляра, остановив экземпляр, изменив атрибуты экземпляра и снова запустив экземпляр.
Когда вы запускаете экземпляр, вы указываете (среди прочего) тип экземпляра (например, m1.large) и AMI. Это означает, что ваш экземпляр запустится со всем, что было сохранено в этом AMI - предварительно настроенной операционной системе, установленном вами программном обеспечении и т. Д. Кроме того, AMI (или команда ec2-run-instance) может ссылаться на дополнительное хранилище - временное или временное. Поддержка EBS. В случае дополнительных томов хранилища EBS их можно создать из существующих моментальных снимков и присоединить к вашему экземпляру при его запуске. (Интересно, что содержимое этих снимков загружается «лениво» - это означает, что вы можете получить доступ к данным на них, прежде чем снимок будет полностью загружен, что удобно, если вы загружаете большие тома).
Рассмотрим простейший сценарий - кластер, в котором все машины эквивалентны - для начала, допустим, мы обслуживаем статический сайт. EC2 позволит вам масштабировать по вертикали (более мощный экземпляр) и по горизонтали (больше экземпляров). Итак, мы начинаем с самого маленького экземпляра - t1.micro и обнаруживаем, что в конечном итоге он не может справиться с нагрузкой. Теперь мы можем добавить второй экземпляр за Elastic Load Balancer (ELB). Таким образом, входящий запрос будет поступать в ELB (который должен быть разработан с учетом избыточности и масштабируемости - он должен автоматически добавлять больше ресурсов для удовлетворения предъявляемых к нему требований) - и он направит его в один из экземпляров, этот экземпляр обработает запрос и вернет его через балансировщик нагрузки.
Чтобы немного автоматизировать процесс, мы могли бы использовать автоматическое масштабирование Amazon - по сути, используя триггеры (значения метрик Cloudwatch), вы можете добавлять и удалять экземпляры на лету (и, как и при запуске экземпляра вручную, вы указываете тип экземпляра и AMI новых экземпляров). Более того, эти экземпляры могут быть (они не обязательно должны быть) связаны с ELB, автоматически увеличивающим или уменьшающим ваш кластер в зависимости от вариаций некоторых показателей (например, загрузки ЦП, использования ОЗУ или какой-либо другой настраиваемой переменной).
Теперь - почти все в приведенном выше сценарии - «плохая практика» - вам, вероятно, не следует масштабировать по горизонтали от t1.micro, поскольку это довольно слабые экземпляры - поэтому вы сначала увеличите размер экземпляра; стоимость ELB намного больше, чем стоимость (зарезервированного) t1.micro, что делает его (экономически) непрактичным в этом сценарии; и если бы вы обслуживали статический сайт на AWS, вы бы просто использовали S3 и вообще отказались от затрат и хлопот, связанных с экземплярами, но дело в иллюстрации.
Возьмем более сложный пример - сайт PHP / MySQL (например, Wordpress). Во-первых, мы отделяем базу данных от веб-сервера - поэтому давайте начнем с одного экземпляра каждого из них - теперь мы можем масштабировать каждый независимо. Возможно, вместо хостинга MySQL мы могли бы использовать Amazon RDS (хотя лично я предпочитаю поддерживать свою собственную настройку MySQL), что упростило бы развертывание дополнительных экземпляров MySQL (... по цене, конечно). Все наши веб-серверы обслуживают один и тот же контент, но теперь возможно, что контент может измениться. Изменения (например, новая статья, комментарий и т. Д.), Которые хранятся в базе данных, не являются проблемой - все серверы читают из одного и того же экземпляра базы данных. В идеале вы будете хранить свой код в каком-то центральном месте (например, S3), и каждый экземпляр будет извлекать его при запуске. Статические ресурсы могут обслуживаться из CDN, поэтому вы можете избежать локальной работы с распределенной файловой системой. (ELB может обрабатывать прикрепленные сеансы, но предпочтительно просто централизованно хранить ваши сеансы (например, Memcached), чтобы все экземпляры имели к ним доступ - имейте в виду, что запрос может закончиться в любом экземпляре).
(У AWS есть Elastic Beanstalk, который должен обрабатывать предоставление ресурсов, необходимых для определенных классов приложений (например, PHP / MySQL), но у меня нет личного опыта с этим).
Для более сложных настроек вы можете передавать пользовательские данные в экземпляры, и есть методы для получения списка всех запущенных вами экземпляров (и вы можете пометить свои экземпляры, чтобы сгруппировать их по своему усмотрению). Вы можете обрабатывать задачи в очередях сообщений (версия Amazon - Simple Queue Service ... или использовать версию с открытым исходным кодом, если хотите), чтобы ваш кластер обрабатывал каждый запрос только один раз. Конечно, вы также можете управлять своим кластером с помощью типичных инструментов высокой доступности (например, Heartbeat / Corosync, Pacemaker и т. Д.), Которые позволят всем узлам «знать» друг друга и предоставят вам контроль над ресурсами, работающими на каждый узел. Добавьте распределенную файловую систему (например, Gluster), и вы сможете обрабатывать большинство сценариев.
Помимо этого, вы по-прежнему можете использовать те же инструменты, которые упоминали. Большинство приведенных выше идей основаны на том, что один и тот же AMI развернут несколько раз (вы настраиваете свой AMI и запускаете несколько его копий, каждая из которых должна быть оборудована для обработки своей собственной базовой конфигурации (например, получить последний код и т. Д.)) . Если ваши экземпляры будут часто меняться, или у вас есть кластер большего размера (например, где было бы проблематично развернуть изменения на всех узлах), или если ваши узлы не похожи, то вы можете развернуть узлы по вашему выбору. программного обеспечения для управления конфигурацией (например, Puppet, Chef и т. д.).
Есть еще один шаг, который вы можете предпринять - это предоставить вашу собственную `` виртуальную частную сеть '' - по сути, позволяя вам создавать некоторые частные и некоторые общедоступные экземпляры с NAT, а также контролировать частный IP-адрес и сетевые интерфейсы. (например, у вас может быть несколько интерфейсов в одном экземпляре).
В конце концов, то, как вы развертываете свое приложение, очень сильно зависит от требований приложения - какой информацией каждый узел должен делиться, сколько узлов в вашем кластере и какие узлы зависят друг от друга. Самым простым сценарием всегда будет тот, в котором каждый узел может работать независимо друг от друга, и запрос, отправляемый на любой узел, даст тот же результат ... запустите экземпляр, настройте его, создайте свой AMI и автоматически масштабируйте его за ELB . Все остальные сценарии потребуют некоторого планирования, чтобы разработать что-то, что будет эффективно масштабироваться.
Учитывая вышесказанное, я считаю важным указать на обратную сторону: AWS - отличный сервис, потому что у него низкий барьер для входа - вы можете изучить его практически бесплатно (у них есть бесплатный уровень) - и вы его может масштабироваться в соответствии с вашими потребностями. Однако за все, что есть в AWS, приходится платить - количество часов, в течение которых вы запускаете экземпляр, количество ГБ, которое вы храните, количество операций ввода-вывода на вашем диске, количество запросов, которые вы делаете к S3, ( исходящая) используемая пропускная способность - все. Из-за непредвиденных вещей легко накопить немалый счет за довольно короткий промежуток времени. AWS определенно не является решением всех проблем и имеет свои ограничения (например, отсутствие широковещательных / многоадресных пакетов в их сети).
(Что ж, это оказалось немного больше, чем несколько строк, которые я намеревался написать ...)
Работа в полностью виртуальной среде (не только в EC2, хотя она хорошо оснащена API, и любой может ее использовать) предлагает несколько ускорений по сравнению с полностью физической средой:
Так что да, это дает способы лучше упростить процесс. При наличии правильных операционных систем изменение идентификатора сервера может быть довольно простым, поэтому вы можете предварительно собрать системы гораздо более полно, чем при чисто физических, что минимизирует время постобработки.