2016-08-07 3 views
-1

Посмотрите, сможет ли кто-нибудь помочь мне в создании веб-сайта VIA AWS и о том, как эффективно обрабатывать трафик.Веб-сервер/сервер приложений несколько AZ для трафика AWS и общие вопросы

(EC2) 16 кластеров Web/App Сервер - (Хотеть разделить между США и зоны доступности Европы (AZ) по AWS) США - 8 кластеров ЕС - 8 кластеров

(RDS) - 4 DB Серверы - 1 активен, 1 пассивный, 2 ведомых устройства - настройка для мульти-AZ

(S3) - 1TB. Хранение - US AZ

(Cloudfront) - 8TB.

(Route 53) - DNS

Рассуждения, почему я хочу веб-сервер и сервер приложений в ЕС, потому что большинство из базы пользователей в ЕС (50%), но трафик по-прежнему поступает из США (30 %), и компания также базируется в США.

Вопрос: Я также задаюсь вопросом, как будет работать управление балансировкой и балансировкой нагрузки? Как он будет знать, чтобы направить ЕС на веб-сервер ЕС и пользователя США на веб-сервер США? При эластичной балансировке нагрузки. Обеспечение эффективной работы двух АЗ по управлению вводом-выводом и пропускной способностью?

Есть ли что-нибудь, что я могу сделать лучше? Кроме того, это должно быть строго для служб AWS.

Спасибо!

+2

Вы используете неправильную терминологию, поэтому, вероятно, ваши поисковые запросы еще не получили ответы на вопросы. «Желая разделиться между зоной доступности США и Европы», которая фактически разделяет между AWS ** Регионами **, а не только AZ. Кроме того, нет такой вещи, как «US AZ», в настоящее время есть 3 региона США, каждый из которых имеет несколько АЗ, входящих в этот регион. Разделение трафика по AZ в одном и том же регионе является тривиальным, но как только вы начинаете разделение между регионами, он становится очень сложным (и какие AZ, которые вы используете в каждом регионе, становятся совершенно нерелевантными). –

+0

Кроме того, в зависимости от того, какой тип приложения это, CDN, например CloudFront, может оказаться достаточным для обслуживания вашего приложения в нескольких регионах без необходимости распространять фактические серверы в разных регионах. Информация, подобная типу приложения, сколько может быть кэширована CDN и объем чтения базы данных или записи, необходима, чтобы определить, действительно ли имеет смысл разделить серверы приложений по регионам. –

ответ

0

Как отметил Марк Б., ваша терминология неверна. Послушайте его комментарии и получите правильную терминологию. Как только вы это сделаете, поисковые запросы Google начнут давать вам ответы.

я обращусь несколько моментов здесь:

вопрос, который я также представляю, как будут направление и балансировки нагрузки? Как он будет знать, чтобы направить ЕС на веб-сервер ЕС и пользователя США на веб-сервер США? При эластичной балансировке нагрузки. Обеспечение эффективной работы двух АЗ по управлению вводом-выводом и пропускной способностью?

Вы собираетесь разделить эти две отдельные вещи:

  1. Режиссура клиентов ЕС в ЕС регионе и направляя США клиентов в США регионе.

Вы собираетесь сделать это, чтобы уменьшить латентность для каждого из этих пользователей. Для этого вы будете использовать Route 53 «Маршрутизация с задержкой».

  1. Загрузите баланс каждой области независимо друг от друга.

Для этого вы собираетесь использовать эластичные балансировочные нагрузки и экземпляры EC2 в нескольких зонах доступности.

Вы не будете «балансировать баланс» между США и ЕС. В регионе США будет сбалансирован груз, а регион ЕС будет сбалансирован по нагрузке.

(RDS) - 4 DB Серверы - 1 Активный, 1 Пассивная, 2 Рабы - установки для мульти-AZ

Вы собираетесь настроить ваш главный сервер БД в США или ЕС. Это будет Multi-AZ, и вам нужно будет использовать этот сервер для выполнения всех записей, даже из другого региона.

Затем вы можете настроить 1 read-replica в каждом из регионов, чтобы уменьшить время чтения.

(S3) - 1TB. Хранение - US AZ

В зависимости от того, как будет использоваться хранилище, вы можете использовать 2 ведра по одному в каждом регионе. Объекты могут быть реплицированы между ведрами.