У меня есть веб-сайт, на котором мы балансируем нагрузку на несколько машин. Балансировщик нагрузки (Brocade ServerIron ADX) находится в локальной сети. Я знаю, что у него есть возможность настроить «резервный» IP-адрес для использования в качестве «настоящего», но он должен быть в локальной сети. Как я могу предоставить моим пользователям сообщение об ошибке и сообщение об обновлении статуса, когда вся моя среда может быть отключена из-за сбоя FW, LB или нескольких серверов? Поскольку DNS не может предоставить взвешенную резервную копию A-Record (например, записи SRV), каковы мои варианты?
В идеале решение должно иметь возможность автоматически вмешиваться, как только мой сайт становится недоступным, и информировать моих пользователей о том, что наши группы реагирования работают над проблемой.
Fail Whale в Twitter сложнее, чем кажется. Стеки приложений Twitter (стеки - в инфраструктуре Twitter много уровней), как известно, довольно сложны. В Твиттере тысячи машин, годы написанного кода на разных языках, десятки различных вариантов и сотни (если не тысячи) мест, где приложение может сломаться. Ваши требования (два сервера и страница сбоя) намного проще.
Я просто смотрю на аналогичную функцию - я хочу использовать резервный веб-сервер, если все основные веб-серверы выйдут из строя. Обратите внимание, что это поможет только в некоторых сценариях сбоя и не поможет, если в общедоступной сети к балансировщику нагрузки возникнут проблемы.
Руководство по балансировке нагрузки сервера ServerIron ADX, Глава 2: раздел «Основные и резервные серверы» говорит:
Первичный и резервный серверы
Настоящий сервер является либо основным, либо резервным, в зависимости от того, как вы его добавили:
• Первичный сервер используется ServerIron ADX при балансировке нагрузки клиентских запросов для приложения. Это локально подключенный сервер, добавляемый с помощью команды server real-name-or-ip или веб-эквивалента.
• Сервер резервного копирования используется ServerIron ADX только в том случае, если все основные серверы недоступны для запрошенного приложения. Он добавляется удаленно с помощью команды server remote-name или веб-эквивалента
Вы заставляете веб-дизайнера создать документ, который выглядит так, как вы хотите.
Затем вы настраиваете балансировщик нагрузки для обслуживания этого документа при ошибках HTTP 500, 502, 503 и 504. То, как вы это делаете, варьируется; проверьте свою документацию.
Некоторые балансировщики нагрузки - это просто «тупые» балансировщики TCP, которые пересылают TCP-соединения и ничего не делают на уровне 7. Другие могут действовать как полные обратные прокси (например, nginx), и они способны делать то, что вам нужно.
Из быстрого сканирования Документация Brocade ServerIron ADX, похоже, он не может обслуживать документы об ошибках по HTTP-запросам. Хотя он определенно умнее, чем ваш типичный «тупой» TCP-сервер пересылки, он, вероятно, не будет делать здесь то, что вы хотите.
Обратный прокси, такой как nginx, будет способен на это, хотя, если вы его настроите, вы также можете просто заменить балансировщик нагрузки (поскольку nginx также может выполнять балансировку нагрузки HTTP / HTTPS).
«Кит-провал» Твиттера не указывает на какие-либо из этих катастрофических сбоев, и их было бы совсем нетривиально создать. Лучшее, что я могу придумать, - это низкий TTL DNS для вашего домена, дополнительное интернет-соединение с отдельным IP-пространством, которое обслуживает только отказавший кит, и какой-то инструмент мониторинга, который обновляет ваши записи A в случае сбоя.
Если вы не планируете очень часто иметь катастрофические сбои, это было бы излишним. И если вы планируете получать их часто, вероятно, вы делаете это неправильно :)
CDN, такие как CloudFront или Akamai, могут заменять сообщения об ошибках ошибочными сообщениями, или у вас может быть локальный облегченный прокси-уровень, который делает то же самое. Локальное решение не поможет вам, если ваше сетевое соединение прервется, с этим могут справиться только CDN или удаленный DNS-сервер + Healthchecker.