Кратко
- Если и основная, и резервная записи переключения связаны с проверками состояния и обе признаны нездоровыми, Route 53 возвращает основную запись.
- AWS сохраняет шанс подключения при ошибочной проверке или цепочке перегрузок. Какие операции ещё можно выполнять за этим адресом, должен решить сам клиент.
Резерв без последнего решения
У резервного сервера замечательная роль в презентации: он появляется в тот момент, когда основной перестаёт работать. После успешного переключения демонстрацию обычно можно закончить. Но у резерва есть неприятная привычка тоже зависеть от оборудования, приложений и сети. Что выдавать пользователю, когда красными стали оба индикатора?
В документации Route 53 этот случай описан прямо. Для пары записей переключения, каждая из которых связана с проверкой состояния, действует последовательность: здоровая основная — вернуть основную; нездоровая основная и здоровая резервная — вернуть резервную; обе нездоровые — вернуть основную. Первый кандидат возвращается в список без пересдачи экзамена. Правила выбора записей
Возвращается адрес в ответе DNS. Оценка состояния от этого не становится положительной, а приложению ещё предстоит обработать пришедший запрос. Возможность назвать место назначения и возможность правильно закончить работу — разные способности. В смете их легко объединить словом «доступность» и потерять важную разницу.
Последний выбор AWS выражает конкретный приоритет: когда наблюдение исключило всех, оставить хотя бы возможность попытки. Покупатель мог ожидать от красного индикатора автоматического запрета на вход. Этот разрыв ожиданий лучше обнаружить по документации, чем по результату клиентской операции.
Почему последний адрес имеет смысл
AWS объясняет, что неверно настроенная проверка может не проходить, хотя приложение продолжает обслуживать пользователей. Исключение всех адресов тогда превращает ошибку измерения в реальное прекращение доступа. Последний ответ оставляет шанс запросу, который ещё мог бы завершиться. Объяснение проблем переключения
В той же документации есть пример перегрузки. Из трёх целей исключают одну, нагрузка на две другие растёт, и они тоже перестают проходить проверки. Возвращение распределения между всеми тремя может дать больше возможностей, чем полное исключение. Это пример, которым AWS поясняет устройство сервиса, а не измеренная здесь авария конкретного клиента.
Такой подход признаёт право измерительного прибора ошибаться. Если дать ему безусловное право закрыть все входы, точность проверки станет ещё одной зависимостью доступности. Иногда адрес, оставшийся в ответе вопреки красному состоянию, действительно спасает полезную попытку.
Цена этой попытки определяется работой, которую выполняют. Повторное чтение справочной страницы и окончательное подтверждение труднообратимой операции имеют разные последствия. Приложение может разрешать часть чтений и останавливать часть подтверждений при деградации. Для этого нужен владелец решения и механизм, исполняющий его внутри бизнеса.
Резервная площадка покупает дополнительный ресурс и путь. Полномочие продолжать принимать обязательства вместе с сервером не поставляется. Если его никто не определил, техническое предпочтение поставщика незаметно становится политикой компании.
Что именно проверили
При проверке конечной точки клиент задаёт протокол, интервал и порог последовательных неудач, среди прочих параметров. Достижение порога переводит состояние в нездоровое; успех до его достижения сбрасывает счётчик неудач. Можно настроить уведомления через CloudWatch и SNS. У сообщения оператору и у выбора записи свои функции. Как работают проверки
Проверки конечных точек выполняются с интервалом десять или тридцать секунд, проверяющие узлы действуют независимо. Каждый запрос DNS не запускает новую полную репетицию пользовательской операции. При выборе используются периодические наблюдения. Условия определения состояния
Ответ HTTP или HTTPS, соответствующий условиям теста, даёт полезное свидетельство о соединении и ответе. Для покупки с проверкой наличия, подтверждением и сохранением результата нужны другие свидетельства. AWS отдельно указывает, что проверки HTTPS не проверяют сертификаты SSL/TLS. Широкое слово «здоров» покрывает вполне определённый экзамен.
Отсутствие проверки у резервной записи тоже меняет выбор. Запись без проверки считается здоровой. При нездоровой основной Route 53 может вернуть резервную, даже если её цель в действительности имеет проблемы. Удалённое наблюдение уменьшает число причин для исключения, а не увеличивает мощность сервера.
Поэтому в закупке стоит отдельно оценивать альтернативные ресурсы, способность замечать сбои и способность получать правильный результат в ухудшенных условиях. Два адреса, которым для завершения работы необходим один и тот же компонент, могут оставаться двумя входами в одну зависимость. Количество входов эту зависимость не измеряет.
В акте приёмки нужна вторая красная лампа
Испытание с отказавшим основным и исправным резервным узлом показывает важный переход. К нему следует добавить контролируемый сценарий, в котором обе связанные проверки дают нездоровое состояние. Тогда сопоставляются решения проверок, фактические ответы DNS и действия, которые приложение разрешило завершить.
Консоль предоставляет состояние, причину последней неудачи, адрес проверяющего узла и время для соответствующих проверок; у вычисляемых проверок есть исключения. Эти сведения позволяют строить временную последовательность, а не ограничиваться фотографией индикаторов. Просмотр состояния
Место наблюдения также важно. AWS предупреждает, что разделение сети может привести к разным представлениям о состоянии в разных точках Route 53, в том числе отличным от CloudWatch. Центральная картинка не заменяет ответы, полученные в конкретных местах.
Официальные документы не дают долю успешных операций отдельного клиента при двух нездоровых целях; для оценки реального инцидента нужны ответы DNS и результаты приложения за одно и то же время.
Для покупки, однако, уже есть проверяемый вопрос. AWS написала, какой адрес останется последним. Компания должна написать, какие обещания она готова принимать за ним. Только вместе эти решения превращают резерв из строки расходов в рабочий вариант поведения.
Обзор для участников
Подробный контекст профиля
Войдите с подходящим уровнем подписки, чтобы открыть полный обзор и примечания к источникам.
Только для Стратегического сообщества
Стратегическое сообщество
Открыто всем читателям. Вступите и войдите, чтобы открыть обзоры профилей.
Вступить в Стратегическое сообществоТолько для Альянса лидеров
Альянс лидеров
Для проверенных владельцев IP-активов и руководителей. Войдите, чтобы открыть обзоры Альянса.
Вступить в Альянс лидеров





