Amazon EC2, самый быстрый способ получить узел в существующий кластер
Способ зафиксировать это состоит в том, чтобы выполнить периодический опрос переключателя и автоматически сгенерировать Ваши конфигурации MRTG. Существует ключевая утилита, которая идет с MRTG, который это назвало cfgmaker. Это - утилита, которая автоматически сгенерирует страницы на основе данных, они выходят из данных SNMP цели. Ключ должен назвать Ваши страницы в честь интерфейсов и заполнить любые описательные имена на самой странице. Таким образом, тот же интерфейс сохранит свое имя, неважно, что включается в него.
После того как у Вас есть все это, можно связать это с indexmaker для создания динамического ключа для сайта. Но cfgmaker и indexmaker звонят в единственный сценарий и запущенный, что скрипт в любом расписании подходит Вам, и это просто сделает новые страницы, поскольку это находит их. Это работает довольно хорошее, я использовал MRTG для отслеживания определенной основанной на сервере статистики назад в день и имел чванство .bat файл, который генерировал все это.
Можно стать действительно сложными с ними относительно форматирования, но если Вы просто хотите значения по умолчанию, что-то вроде этого могло бы быть всем, в чем Вы нуждаетесь:
cfgmaker --subdirs=HOSTNAME --output=mypcnt-01.conf mysecret@powerConnectSwitch-01
indexmaker --output mypcnt\index.html mypcnt-01.conf
Просто выполните что-то как этот в расписании. Корректируйтесь к вкусу.
Краткий ответ:
Это зависит от вашего приложения - 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 мы могли бы использовать RDS от Amazon (хотя лично я предпочитаю поддерживать свою собственную настройку MySQL), что упростило бы развертывание дополнительных экземпляров MySQL (... по цене, конечно). Все наши веб-серверы обслуживают один и тот же контент, но теперь возможно, что контент может измениться. Изменения (например, новая статья, комментарий и т. Д.), Которые хранятся в базе данных, не являются проблемой - все серверы читают из одного и того же экземпляра базы данных. В идеале вы будете хранить свой код в каком-то центральном месте (например, S3), и каждый экземпляр будет извлекать его при запуске. Статические ресурсы могут обслуживаться из CDN, так что вы можете избежать локальной работы с распределенной файловой системой. (ELB может обрабатывать прикрепленные сеансы, но предпочтительнее просто централизованно хранить ваши сеансы (например, Memcached), чтобы все экземпляры имели к ним доступ - имейте в виду, что запрос может завершиться в любом экземпляре).
(AWS действительно имеет Elastic Beanstalk, который должен обрабатывать предоставление ресурсов, необходимых для определенных классов приложений (например, PHP / MySQL), но у меня нет личного опыта с этим).
Для более сложных настроек вы можете передать пользователя -data для экземпляров, и есть методы для получения списка всех запущенных экземпляров (и вы можете пометить свои экземпляры, чтобы сгруппировать их по своему усмотрению). Вы можете обрабатывать задачи в очередях сообщений (версия Amazon - Simple Queue Service ... или использовать версию с открытым исходным кодом, если хотите), чтобы ваш кластер обрабатывал каждый запрос только один раз. Конечно, вы также можете управлять своим кластером с помощью типичных инструментов высокой доступности (например, Heartbeat / Corosync, Pacemaker и т. Д.), Которые позволят всем узлам «знать» друг друга и предоставят вам контроль над ресурсами, работающими на каждый узел. Добавьте распределенную файловую систему (например, Gluster), и вы сможете обрабатывать большинство сценариев.
Помимо этого, вы все еще можете использовать те же инструменты, которые вы упомянули. Большинство приведенных выше идей основаны на том, что один и тот же AMI развернут несколько раз (вы настраиваете свой AMI и запускаете несколько его копий, каждая из которых должна быть оборудована для обработки своей собственной базовой конфигурации (например, получить последний код и т. Д.)) . и какие узлы зависят друг от друга. Самым простым сценарием всегда будет тот, в котором каждый узел может работать независимо друг от друга, и запрос, отправляемый на любой узел, даст тот же результат ... запустите экземпляр, настройте его, создайте свой AMI и автоматически масштабируйте его за ELB . Все остальные сценарии потребуют некоторого планирования, чтобы разработать что-то, что будет эффективно масштабироваться.
Учитывая вышесказанное, я считаю важным указать на обратную сторону - AWS - отличный сервис, потому что существует низкий барьер для входа - вы можете изучить его практически бесплатно (у них есть бесплатный уровень) - и вы можете масштабировать его в соответствии с вашими потребностями. Однако за все, что есть в AWS, взимается плата - количество часов, в течение которых вы запускаете экземпляр, количество ГБ, которое вы храните, количество операций ввода-вывода на вашем диске, количество запросов, которые вы отправляете S3, (исходящая) пропускная способность, которую вы используете - все. Из-за непредвиденных вещей легко накопить немалый счет за довольно короткий промежуток времени. AWS определенно не является решением всех проблем, и у него есть свои ограничения (например, отсутствие широковещательных / многоадресных пакетов в их сети).
(Ну, в итоге это оказалось немного больше, чем несколько строк, которые я намеревался написать ...)
Работа в полностью виртуальной среде (не только в EC2, хотя она хорошо оснащена API, и любой может ее использовать) предлагает несколько ускорений по сравнению с полностью физической средой:
- Вы можете по большей части игнорируйте выделение оборудования.
- Установка основана на образе, поэтому вы создаете образ gold-master с большей частью того, что вам нужно. Это обходит большинство частей установки ОС.
- Запуск puppet / cfengine / chef / whatnot выполняется быстрее, поскольку часть работы уже сделана.
Так что да, это действительно дает способы лучше упростить процесс. При наличии правильных операционных систем изменение идентичности сервера может быть довольно простым, поэтому вы можете предварительно построить системы гораздо более полно, чем при чисто физических, что минимизирует время постобработки изображений.