Назад | Перейти на главную страницу

В чем причина масштабирования Amazon EC2 по количеству инстансов, а не по параметрам инстансов?

Мы планируем перевести наш сайт на Amazon EC2.

Основная идея облака Amazon, похоже, такова: «Нужно больше ОЗУ? У вас есть. Жесткий диск? Конечно, вот и все». И т.п.

Но Amazon, похоже, увеличивает количество экземпляров, а не параметры экземпляра (RAM, диск и т. Д.) В зависимости от того, как работает их масштабирование.

«Amazon EC2 обеспечивает действительно эластичную вычислительную среду. Amazon EC2 позволяет увеличивать или уменьшать емкость за считанные минуты, а не часы или дни. Вы можете вводить в эксплуатацию один, сотни или даже тысячи экземпляров серверов одновременно». http://aws.amazon.com/ec2/faqs/#How_quickly_can_I_scale_my_capacity_both_up_and_down

Итак, опять же, если мой веб-сайт работает на одном экземпляре, и этот экземпляр начинает сталкиваться с некоторым пределом, как второй экземпляр поможет? Работают ли они автоматически: совместно используют один и тот же IP-адрес, выполняют балансировку нагрузки, синхронизируют данные записи?

Или я что-то недопонимаю? Спасибо.

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

Практически ничто не разделяется между экземплярами - они работают со своими собственными операционными системами, имеют собственную память, собственное хранилище и собственные IP-адреса. Относитесь к ним так же, как к любому VPS - только с немного более автоматизированной системой подготовки.

Одно место, где EC2 отличается от большинства решений VPS, - это возможность добавления хранилища. Это можно сделать, не останавливая экземпляр, в форме «добавления новых томов» (например, у вас будет / dev / xvda, а затем добавить / dev / xvdb и т. Д.)

Вы можете перейти к большему экземпляру следующим образом: Остановить (не завершить) экземпляр. Использовать атрибут ec2-modify-instance-attribute i-xxxxxx -t, чтобы изменить тип экземпляра. Запустить экземпляр.

Что касается всех других аспектов масштабируемости, вы сами по себе - вы должны разработать свое приложение, чтобы использовать то, что предоставляет Amazon: эластичные IP-адреса - для предоставления единого постоянного общедоступного IP-адреса, несмотря на изменение базового экземпляра Elastic Load Balancers - для распределения запросов между тома EBS - для постоянного хранилища. Экземпляры EC2 - для вычислительной мощности S3 и Cloudfront - для доставки контента RDS - для баз данных MySQL, управляемых AWS (хотя встроенной масштабируемости нет)

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

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

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

По крайней мере частично, основная причина установки на AWS заключается в том, что каждый «экземпляр» является предопределенной виртуальной машиной. Чтобы изменить спецификации виртуальной машины, вам все равно потребуется ее остановить и запустить. Amazon предоставил широкий ассортимент типов инстансов на выбор, но помимо этого вы не можете настроить ЦП / ОЗУ для типа инстанса. Кроме того, горизонтальное масштабирование преодолевает ограничение одной машины (например, было бы немыслимо для любого большого сайта работать на одном сервере, независимо от его размера) - и позволяет избежать единичных точек отказа. Возможно, если вам потребуется больше мощности, чем предлагают их самые большие инстансы, горизонтальное масштабирование, скорее всего, станет вашим решением, независимо от того, работаете ли вы на AWS или нет.

Работают ли они автоматически: совместно используют один и тот же IP-адрес, выполняют балансировку нагрузки, синхронизируют данные записи?

Краткий ответ: нет, но могут.

С большинством сервисов, где вам нужно добавить емкость, у вас есть два варианта: масштабирование или масштабирование.

Я не буду вдаваться в подробности здесь, поскольку повторяю статью из Википедии по этому поводу (http://en.wikipedia.org/wiki/Scale_out#Scale_horizontally_vs._vertically), но масштабирование происходит так, как вы изначально предлагаете: добавление ЦП / ОЗУ / диска при масштабировании добавляет дополнительные узлы.

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

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

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

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