Можно ли использовать AWS Elastic Load Balancer для отправки трафика на второй сервер только в случае отказа первого

Можно ли настроить AWS Elastic Load Balancer таким образом, чтобы он отправлял весь трафик на главный сервер, а в случае сбоя этого сервера отправлял трафик только на второй сервер.

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


amazon-web-services amazon-ec2 aws-elb elastic-load-balancer
person Deej    schedule 22.05.2018    source источник
comment
Вы можете динамически добавлять инстансы EC2 в ELB и удалять из него инстансы. В качестве альтернативы вы можете полностью удалить ELB из картины и просто переключить (общедоступный) EIP с одного хоста на другой, когда вам нужно выполнить отработку отказа.   -  person jarmod    schedule 22.05.2018
comment
Обмен EIP (или) может использовать отказоустойчивый подход R53. Когда ваш вариант использования НЕ балансирует нагрузку между экземплярами, использование ELB не имеет смысла.   -  person INVOKE Cloud    schedule 22.05.2018

Ответы (1)


arrow_upward
3
arrow_downward

Балансировщики нагрузки AWS не поддерживают «резервные» узлы, которые принимают трафик только тогда, когда основной не работает.

Кроме того, вы предлагаете сложный сценарий.

думал настроить второй сервер EC2 с подчиненным сервером MySQL

Если вы сделаете это, вы сможете выполнить отработку отказа только один раз, после чего вы не сможете вернуться назад, потому что база данных master станет устаревшей. Чтобы такая конфигурация работала и была полезной, ваши два сервера MySQL должны быть настроены с репликацией master/master (циклической), чтобы каждый был репликой другого. Это расширенная конфигурация, требующая опыта и осторожности.

Для компонента MySQL экземпляр RDS с поддержкой нескольких зон доступности обеспечит автоматическую отказоустойчивость базы данных.

Конечно, клиент может и не захотеть платить за это.

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

person Michael - sqlbot    schedule 22.05.2018
comment
Я думаю, что наличие DB dns на R53 с настройкой аварийного переключения лучше всего подходит для этого случая (при условии, что OP не ищет автоматическое масштабирование и реальную балансировку нагрузки). - person INVOKE Cloud; 22.05.2018
comment
@INVOKECloud все это кажется немного деликатным. Как вы знаете, сбой в том месте, где поступают запросы, — это лишь малая часть отказоустойчивости. На мой взгляд, без каких-либо исключений, производственная база данных никогда не должна совместно использовать машину с чем-либо еще, но здесь звучит так, как будто у нас есть одна машина, которая делает все. Это по своей природе хрупко. - person Michael - sqlbot; 22.05.2018
comment
Я согласен, что ваше решение - это установка холостого хода, но OP получает то, за что платит. Независимо от того, какой способ выберет OP, им обязательно нужно обеспечить согласованность данных. - person INVOKE Cloud; 22.05.2018
comment
@INVOKECloud точно. Именно это я имел в виду, когда назвал предложенную схему деликатной. Потеря данных или несоответствие могут произойти очень легко. - person Michael - sqlbot; 22.05.2018
comment
Временные исправления часто стоят дороже в долгосрочной перспективе и обеспечивают меньше. Предложение @Michael-sqlbot по переносу MySQL на RDS - это хорошее недорогое улучшение с солидными преимуществами. Внедрение Master/Slave — это непростое решение для самостоятельной реализации и управления (RDS указывает на это и нажимает). - person John Hanley; 24.05.2018