Comments 48
А как ведет себя ELB с точки зрения отказоустойчивости? Что будет, если одна из зон датацентра ляжет, не затронет ли это ELB?
Официальное мнение амазона: нехрен все яйца в одной корзине держать и мучать их дурацкими вопросами.
>Incoming traffic is load balanced equally across all Availability Zones enabled for your load balancer, so it is important to have approximately equivalent numbers of instances in each zone. For example, if you have ten instances in Availability Zone us-east-1a and two instances in us-east-1b, the traffic will still be equally distributed between the two Availability Zones. As a result, the two instances in us-east-1b will have to serve the same amount of traffic as the ten instances in us-east-1a. As a best practice, we recommend you keep an equivalent or nearly equivalent number of instances in each of your Availability Zones. So in the example, rather than having ten instances in us-east-1a and two in us-east-1b, you could distribute your instances so that you have six instances in each Availability Zone.
docs.amazonwebservices.com/ElasticLoadBalancing/latest/DeveloperGuide/arch-loadbalancing.html
Это нормально, для примера, мне они просто не смогли ответить на вопрос, что будет если я уберу таймауты у политик масштабирования и в заказе повиснет больше спотов, чем может влезть в группу, а потом заказы выполнятся.
Ответ был: просто не делайте этого и проставьте таймауты.
>Incoming traffic is load balanced equally across all Availability Zones enabled for your load balancer, so it is important to have approximately equivalent numbers of instances in each zone. For example, if you have ten instances in Availability Zone us-east-1a and two instances in us-east-1b, the traffic will still be equally distributed between the two Availability Zones. As a result, the two instances in us-east-1b will have to serve the same amount of traffic as the ten instances in us-east-1a. As a best practice, we recommend you keep an equivalent or nearly equivalent number of instances in each of your Availability Zones. So in the example, rather than having ten instances in us-east-1a and two in us-east-1b, you could distribute your instances so that you have six instances in each Availability Zone.
docs.amazonwebservices.com/ElasticLoadBalancing/latest/DeveloperGuide/arch-loadbalancing.html
Это нормально, для примера, мне они просто не смогли ответить на вопрос, что будет если я уберу таймауты у политик масштабирования и в заказе повиснет больше спотов, чем может влезть в группу, а потом заказы выполнятся.
Ответ был: просто не делайте этого и проставьте таймауты.
За отказоустойивостью ELB стоит AWS. Они сами перевезут в другую зону, если под ним стоят инстансы из живой зоны.
А где ни будь гарантируют такое письменно?
Как долго ELB будет переезжать из одной зоны в другую, каков будет downtime? Будет ли это seamless или придется менять DNS'ы вручную?
Адреса у ELB всегда одинаковые. Поменяются IP. По поводу времени, не считал. Но опыт последних даунтаймов в us-east-1 говорит о том, что всё очень быстро. HA конфигурации, с зональным распределением отработали отлично.
ИМХО самая предсказуемая и спокойная часть AWS.
Время масштабирования завязано на старт инстансов, так как новый, судя по всему, поднимается с нуля и пола поднятых инстансов не держится.
Старт инстанса в амазоне есть великое таинство. Конечно у них есть приоритеты ondemand>reserved>spot (по коммерческим соображениям), но разброс их времени старта перекрывается и сильно завязаны на типы. У меня и деменды стартовали по 15 минут и споты вспыхивали моментально, после приобретения. Фактически амазон не предоставляет никаких гарантий. Только гарантии насчет принадлежности к группе приоритетов.
Плюс, насколько я понял из своих экспериментов, резервирование EBS (больше — дольше) тоже лочит процесс старта. ELB по хорошему диск толком не нужен.
Время масштабирования завязано на старт инстансов, так как новый, судя по всему, поднимается с нуля и пола поднятых инстансов не держится.
Старт инстанса в амазоне есть великое таинство. Конечно у них есть приоритеты ondemand>reserved>spot (по коммерческим соображениям), но разброс их времени старта перекрывается и сильно завязаны на типы. У меня и деменды стартовали по 15 минут и споты вспыхивали моментально, после приобретения. Фактически амазон не предоставляет никаких гарантий. Только гарантии насчет принадлежности к группе приоритетов.
Плюс, насколько я понял из своих экспериментов, резервирование EBS (больше — дольше) тоже лочит процесс старта. ELB по хорошему диск толком не нужен.
А где, простите, сама информация о том, как работает ELB? Все, что вы написали, можно легко найти в документации за несколько минут. Я, например, ждал инфы о технологии проксирования, о том, как происходит терминация SSL, задействован ли NAT… статья ни о чем.
Это информация под NDA у них. Мне редко говорят что-то такое, и то перед релизами. К сожалению, это закрытая информация.
По некоторым неофициальным данным — для проксирования HTTP и терминации SSL ранее использовалось проприетарное решение их разработки, а сейчас сильно модифицированный NGINX.
Чего в их балансире не работает:
— баланирование на портах менее чем 1024 (т.е. зарезервированные порты) — не позволят
— UDP как только не пытайтесь
— «волшебные» TCP пакеты тоже не балансируются — поэтому если ВДРУГ Вы решили сделать игровой сервис с несовсем стандартной структурой пакетов — то Вам неповезло.
По поводу терминации SSL ничего интересного нету — есть почти везде и для всех серверов.
Чего в их балансире не работает:
— баланирование на портах менее чем 1024 (т.е. зарезервированные порты) — не позволят
— UDP как только не пытайтесь
— «волшебные» TCP пакеты тоже не балансируются — поэтому если ВДРУГ Вы решили сделать игровой сервис с несовсем стандартной структурой пакетов — то Вам неповезло.
По поводу терминации SSL ничего интересного нету — есть почти везде и для всех серверов.
Зачем вы меня обманули? В начале статьи пообещали рассказать о внутренностях, а на самом деле статья — пересказ документации. Зря потерял время.
UFO just landed and posted this here
Масштабирование происходит автоматически. Если инстанс не выдерживает, то масштабируется дальше. Разогрев это для отдельного случая, например первый запуск продакшна — чтоб инфраструктура сразу была готова к хайлоаду.
Кмк, если хочешь быть уверен — делай все сам.
Ротацию nginx настроить дело незайтейливое. С AS конечно сложнее будет, так как нужно будет ловить в том или ином виде сигналы о подъеме инстансов и обновлять конфигурацию.
Ротацию nginx настроить дело незайтейливое. С AS конечно сложнее будет, так как нужно будет ловить в том или ином виде сигналы о подъеме инстансов и обновлять конфигурацию.
UFO just landed and posted this here
А как балансируете вебсокеты?
ELB же не умеет делать sticky balancing для TCP/SSL (i.e. ws/wss).
ELB же не умеет делать sticky balancing для TCP/SSL (i.e. ws/wss).
UFO just landed and posted this here
Ага, знакомая картина. Тогда часто возникает другой вопрос.
Вот допустим у нас стоит ферма апп-серверов, которые держат tcp (ws, etc) соединения с клиентами через ELB. И дальше где-то на бекенде возникает необходимость послать сообщение клиенту X. Как определяете сервер, который нужно пнуть чтобы сообщение ушло этому клиенту?
Сам апп-сервер может роутить месиджи любым клиентам, которые сейчас к нему приконекчены — держит in-memory ConcurrentMap и нет проблем.
А какие best-practices вы знаете, чтобы роутить месиджы к самим апп-серверам?
На моем конкретном проекте этих краевых серверов мало, и я делаю broadcast запрос по ним в рамках одного региона Amazon. Но наверняка есть варианты лучше.
Вот допустим у нас стоит ферма апп-серверов, которые держат tcp (ws, etc) соединения с клиентами через ELB. И дальше где-то на бекенде возникает необходимость послать сообщение клиенту X. Как определяете сервер, который нужно пнуть чтобы сообщение ушло этому клиенту?
Сам апп-сервер может роутить месиджи любым клиентам, которые сейчас к нему приконекчены — держит in-memory ConcurrentMap и нет проблем.
А какие best-practices вы знаете, чтобы роутить месиджы к самим апп-серверам?
На моем конкретном проекте этих краевых серверов мало, и я делаю broadcast запрос по ним в рамках одного региона Amazon. Но наверняка есть варианты лучше.
UFO just landed and posted this here
Можно придумать многов вариантов. Я бы остановлися на каком-то который использует по максимуму существующие сервисы AWS: DynamoDB, SNS, SQS и т.д.
UFO just landed and posted this here
Иногда, самым главным преимуществом является то, что это не нужно настраивать. Оно уже есть и стоит не дорого.
UFO just landed and posted this here
Кстати, по поводу сервисов, облачных и своих: habrahabr.ru/company/epam_systems/blog/161787/
Есть сервис SNS, подпишите на топик все апп серверы. Все апп серверы получат сообщение, а если к ним приконнекчен искомый юзер, то сообщение будет ему послано.
Сейчас SQS интегрирован с SNS. Стало легко комбинировать очереди и подписки.
Сейчас SQS интегрирован с SNS. Стало легко комбинировать очереди и подписки.
По словам представителей техподдержки Amazon Web Services при увеличении нагрузки на ELB проходит от одной до семи минут перед тем, как произойдёт масштабирование сервера. IP адрес может быть поменян, поэтому не рекомендуется использовать IP адреса для доменов (я описал выше выход из ситуации).
У Амазона TTL для зоны 3-5 минут? Поменяют они адрес, но в кеше DNS серверов останутся старые записи.
UFO just landed and posted this here
Сейчас как раз используем ELB и AS в одном проекте. К сожалению до сих пор AWS не позволяет настроить гибридный AS при котором по возможности создаются spot instances, а при невозможности — ondemand. Есть правда вот такой путь, но времени попробовать пока не было. Была еще мысль написать свой собственный монитор, но как я понял Cloudwatch умеет только либо выполнять AS policy, либо послать notify на email. Остается вариант написать свой ping, который будет долбить во все инстансы каждые 30 секунд и проверять метрики через Cloudwatch API
А вообще штука хорошая — серьезно пока не подводила
А вообще штука хорошая — серьезно пока не подводила
А как обеспечиваете HA на уровне самого ELB? В случае, если сам ELB упал.
Сами инстансы, которые стояли за ним, могут быть или живы, или мертвы (допустим, отрубился весь регион и мы хотим переключить его клиентов на другие континенты).
Сами инстансы, которые стояли за ним, могут быть или живы, или мертвы (допустим, отрубился весь регион и мы хотим переключить его клиентов на другие континенты).
UFO just landed and posted this here
Sign up to leave a comment.
AWS Insight: Как работает ELB