Конфигурация Amazon Cloud для веб-приложения Java EE с MySQL

В моей работе мне нужно перенести некоторые существующие приложения Enterprise Java на AWS. Я просмотрел много страниц на aws.amazon.com, а также достаточно погуглил. Кроме того, я попытался ответить на все связанные вопросы в stackoverflow. Все это многое прояснило, однако у меня все еще есть некоторая путаница. Вот наша структура приложения:

  1. Это приложение на основе Spring, которое использует Spring MVC в качестве уровня представления и простые интерфейсы и классы Java для обработки бизнес-логики и логики данных.
  2. MySQL используется для настойчивости.

Итак, архитектура приложения достаточно проста. Однако загвоздка в том, что нам нужно развернуть множество экземпляров этого приложения. В настоящее время это число составляет 15 и может превышать 30. Еще один момент заключается в том, что все эти экземпляры используют общую базу данных.

Вот чего нам нужно достичь, перейдя на AWS:

  1. Повышенная отказоустойчивость приложения. Недавно мы столкнулись с отказом сервера / питания на выделенном хостинге, что привело к простоям на несколько часов.
  2. Более высокая производительность для всех экземпляров приложения с точки зрения времени отклика и пропускной способности.
  3. Повышенная отказоустойчивость MySQL. Экземпляры приложений недавно вышли из строя на одном из наших серверов из-за некоторого оборудования (жесткого диска), что в основном привело к неожиданной остановке MySQL. Вся файловая система на жестком диске стала доступной только для чтения, что привело к сбоям в работе экземпляров приложения, размещенных на этом сервере.
  4. Очевидно сокращение общих затрат и накладных расходов на управление инфраструктурой.

Насколько я могу понять инфраструктуру AWS до сих пор, вот что нам понадобится в AWS для нашей настройки:

  1. 4 экземпляра LINUX AMI на базе EBS с установленными на нем Tomcat и MySQL, каждый из которых содержит около 10 экземпляров приложений.
  2. Я предполагаю, что нам также понадобится 1 экземпляр для обеспечения отказоустойчивости для каждого из этих 4 экземпляров, всего 8 экземпляров.
  3. На всех экземплярах сервера будет около 160 ГБ EBS.
  4. 4 эластичных IP-адреса
  5. 4 эластичных балансира нагрузки
  6. Другие вещи, такие как снимок и т. Д.

А теперь вот мои вопросы:

  1. Действительно ли мне нужно иметь этот дополнительный экземпляр сервера (для обеспечения отказоустойчивости) для каждого экземпляра основного сервера, учитывая то, что EBS автоматически поддерживает резервное копирование AWS, и они будут предоставлять новые EBS с теми же данными в случае отказа оборудования?

  2. Как мне поделиться базой данных между всеми экземплярами сервера (4x2) в приведенном выше сценарии? Один из вариантов, который я вижу, - это реализовать кластеризацию MySQL среди этих экземпляров сервера. Допустим, кластер MySQL будет содержать 1 узел управления, 3 узла SQL и 4 узла данных. Однако в этом случае обслуживание кластера будет для нас дополнительными накладными расходами, и это может быть неприемлемо, поскольку мы хотели бы избавиться от управления инфраструктурой.

  3. Нужно ли мне вместо этого использовать RDS для базы данных и удалять экземпляры MySQL со всех серверов (4x2)? Если да, нужно ли мне покупать экземпляры RDS в дополнение к экземплярам EC2 (я думаю, если мне нужно покупать отдельные экземпляры для RDS, тогда стоимость всей инфраструктуры увеличится как минимум на 75%.) Или экземпляры RDS также предоставляют вычислительные единицы для разработки приложений, таким образом уменьшая общее количество экземпляров для развертывания приложений?

  4. В случае внедрения RDS, действительно ли нужны инстансы EC2 на базе EBS? Если мы сможем каким-либо образом удалить требование EBS из экземпляров EC2 с установленными экземплярами RDS, мы сможем снизить общую стоимость.

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


person vikas    schedule 28.08.2011    source источник


Ответы (1)


Я не специалист по инфраструктуре, но у меня есть некоторый опыт работы с AWS, и я надеюсь, что смогу помочь по крайней мере с некоторыми из ваших вопросов. Мой опыт не позволяет мне дать вам какие-либо советы по определению размера вашей инфраструктуры, но я могу помочь советом по типу инфраструктуры.
Прежде всего, я бы определенно выбрал EBS. Помимо того, что он физически отделен от вашего сервера приложений, он также обладает высокой надежностью и высокой доступностью. Могу сказать, что это меня пару раз спасало. Хотя я сказал, что не буду ничего вам рассказывать о калибровке, я не думаю, что вам понадобятся дополнительные 4 экземпляра «отказоустойчивости», но, возможно, вы могли бы на всякий случай оставить около 2 экземпляров готовыми для снятия трафика.

Что касается вашей БД, вам обязательно следует использовать RDS для MySQL (http://aws.amazon.com/rds/mysql/). Они предоставляют вам предварительно настроенные узлы, автоматическое исправление, автоматическое резервное копирование, автоматическую репликацию и масштабирование в один клик по (IMHO) небольшой цене. Все эти функции готовы к работе с MySQL. Вы также можете использовать метрики и мониторинг, это все включено. RDS не предоставляет вам вычислительных единиц, но рекомендуется хранить их отдельно в AWS. У вас также может быть установка с 4 узлами EC2 Tomcat + 2 узлами RDS. Это просто вопрос размера :)

Если вы уже читали об Amazon Elastic Load Balancing, он идеально подходит для вашего решения. Вы можете подключить несколько узлов EC2 к каждому из ваших узлов ELB и забыть о балансировке нагрузки. Это просто работает, и вы также можете настроить липкие сеансы, если хотите. Однако я не знаю, сколько узлов ELB вам следует выбрать, но помните об одной проблеме: вы можете добавлять узлы EC2 только из одного географического региона (например, восточного побережья США) в один и тот же ELB. Невозможно сбалансировать трафик, например, между Tomcat на Западном побережье и другим на Восточном побережье. Если вы решите распределить свои узлы по нескольким регионам, вам потребуется другое решение LB за пределами Amazon.

Мой последний совет: используйте EC2 + RDS на базе ELB + EBS. Это значительно упростит ваш мониторинг, развертывание и обслуживание, а стоимость, как правило, будет намного ниже. Вы, вероятно, лучше осведомлены о том, сколько узлов каждого типа вам понадобится, но не бойтесь пропустить, потому что масштабировать инфраструктуру на AWS очень легко.

person Viccari    schedule 28.08.2011
comment
Мне понадобится как минимум 4 сервера для обеспечения отказоустойчивости, потому что у нас будет 4 разных IP-адреса для 4 основных серверов, поскольку на них будут размещаться разные экземпляры приложения, и тогда каждому серверу потребуется хотя бы один экземпляр для отказоустойчивости или вообще без отказоустойчивости . И для RDS я также рассматриваю 2 небольших экземпляра с развертыванием в нескольких зонах доступности. - person vikas; 29.08.2011
comment
Это нормально. Поскольку кажется, что у вас 4 внешних IP-адреса, вы можете настроить 4 экземпляра ELB (эластичная балансировка нагрузки), в одном из которых размещается каждый IP-адрес, а затем добавить отказоустойчивость по запросу, добавив более одного вычислительного узла EC2 к каждому. ELB по мере необходимости. Что касается RDS, такая настройка выглядит хорошо, и Multi-AZ, безусловно, лучший вариант. Если ваше приложение имеет слишком много чтений из БД, вы также можете дополнительно настроить некоторые реплики чтения. - person Viccari; 29.08.2011