Кратко

  • RFC 5351 описывает business card, с помощью которой Pool Element может посоветовать другого участника для failover, в том числе с учетом нагрузки или предполагаемой свежести состояния. Это рекомендация, а не независимое доказательство готовности или эквивалентности.
  • Разрешение pool handle и политика выбора дают кандидата по текущим сведениям handlespace. Они не устанавливают, завершилась ли старая транзакция, поддерживает ли новый элемент нужную версию и безопасно ли повторять действие.
  • Для восстановления нужны отдельные квитанции: область имени, регистрация, выбор, достижимость, идентичность приложения, commit старой операции, подлинность и свежесть переноса, идемпотентность, долговечный эффект и внешний результат.

«Следующий лучший» скрывал критерий

Business card позволяет элементу передать peer указание, какие другие Pool Elements использовать при отказе. Старый сервер может знать топологию, распределение нагрузки или расположение более свежей копии лучше, чем общий механизм выбора.

Эта локальная информация ценна. Но слово «лучший» не имеет смысла без критерия. Лучший по числу соединений может отставать по данным. Ближайший по сети может находиться в другой зоне доверия. Самая свежая read replica может не принимать запись.

Рекомендация также стареет. Целевой процесс может отказать после выпуска карточки. Репликация может остановиться. Старый элемент может иметь неполную картину или быть скомпрометирован.

Поэтому карточка должна сохраняться с источником, временем и причиной. Она может менять порядок проверки кандидатов, но не отменяет проверку достижимости, идентичности, версии и состояния.

Handle действовал только в своем operational scope

Pool handle в RFC 5351 — уникальная строка байтов в плоском handlespace с ограниченной областью эксплуатации. Администрирование имен не определялось. RFC 3237 требует внешних механизмов для взаимодействия разных пространств.

Успешный ответ означает, что запрошенный ENRP знает handle в своей области. Он не доказывает, что тот же набор байтов имеет такой же смысл в другой организации.

Прикладной протокол между Pool User и Pool Element остается специфичным для приложения. RSerPool предполагает совместимую конфигурацию, но не согласует автоматически версии, схему состояния или модель полномочий.

Если рекомендованный сервер пересекает административную границу, имя не переносит ключи, юрисдикцию и согласие пользователя. Эти факты надо установить заново.

Согласованный handlespace оставался снимком

ENRP-серверы обмениваются изменениями, публикуют Presence, сравнивают checksum и синхронизируют несовпадающие части. После отказа одного сервера остальные договариваются о takeover его Home ENRP роли.

Такой механизм уменьшает устойчивое расхождение реестра. Он не делает знание мгновенным. Pool Element может ответить на keep-alive и прекратить работу до следующего обращения.

RFC 5352 допускает кэш с stale timer. Если запись еще не считается старой, endpoint обычно не делает новый запрос. Если считается, реализация может обновлять ее параллельно с ответом или ждать.

Возраст в пределах порога — свойство политики, а не физическая доступность. Для расследования нужны время разрешения, возраст кэша, порог, ENRP и время реального соединения.

Политика выбора не была проверкой состояния приложения

RFC 5356 задает Round Robin, Weighted, Random, Priority и варианты Least Used. Они позволяют одинаково упорядочивать участников.

Понятие load зависит от приложения и находится вне области RSerPool. Участники одного pool должны использовать одинаковое определение, но оно может означать пользователей, CPU или память.

Ни один из этих показателей не обязан учитывать отставание реплики, блокировку хранилища, ключи клиента или состояние конкретной транзакции. Самая низкая нагрузка не гарантирует лучшую точку восстановления.

Аудит должен хранить политику, определение, момент измерения и весь набор кандидатов. Иначе победивший адрес выглядит результатом объективной проверки, которой не было.

Новый адрес не отвечал на вопрос о старой операции

В примере RFC 5351 приложение использует примитивы, похожие на GETPRIMARYSERVER и GETNEXTSERVER, вместо списка основных и резервных имен. После отказа оно сообщает о прежнем элементе и получает следующий адрес по лучшим доступным сведениям.

Тайм-аут не показывает границу commit. Запрос мог не дойти, быть отклонен, быть зафиксирован без ответа или быть зафиксирован до репликации.

Повтор на новом сервере может восстановить работу или создать дубликат. RFC 5351 прямо говорит: failover, зависящий от состояния приложения или транзакции, нельзя в общем случае определить без специальных знаний.

Приложению нужны operation ID, commit receipt, дедупликация и сверка. Протокол выбора адреса не может вывести их из сетевой ошибки.

Opaque cookie тоже не был доказательством полноты

Pool Element может отправлять cookie, Pool User хранит последнюю полученную и после отказа передает новому элементу. Для пользователя структура непрозрачна.

Последняя полученная версия может быть старше последнего commit. Подписанный объект может быть подлинным, но устаревшим или несовместимым. RFC 5351 рекомендует подпись, а RFC 5352 оставляет детали проверки вне области.

Подпись отвечает за происхождение и целостность при заданной модели ключей. Она не подтверждает полноту, свежесть или право выполнить описанное действие.

Поддержка cookie и business card не одинакова и не везде обязательна. Членство в pool не доказывает способность принять состояние. Версия, срок, семантика, ключ и rollback должны принадлежать приложению.

Graceful deregistration показывал второй набор участников

RFC 3237 требует, чтобы элемент после deregistration продолжал обслуживать ранее подключенных пользователей, а новые соединения шли в другое место.

Следовательно, список доступных для новой селекции элементов не равен списку процессов, где еще выполняется работа. Исчезновение из handlespace не разрешает мгновенную остановку.

И наоборот, зарегистрированный элемент может догонять данные и не быть application-ready. Нужен отдельный gate поверх регистрации.

Операционная модель должна видеть как минимум: registered, ready, draining, no-new-selection, sessions-zero, stopped. Один флаг скрывает переходы, где чаще всего теряется состояние.

SCTP и RSerPool восстанавливали разные объекты

SCTP умеет менять путь к тому же endpoint благодаря multihoming и heartbeat. RFC 9260 заменил RFC 4960 как базовую спецификацию. При таком переключении peer и association могут сохраниться.

RSerPool может выбрать другой Pool Element. Это граница процесса и, возможно, хранилища. Транспортная непрерывность, новая ассоциация и восстановление прикладной сессии — разные события.

Общий статус «failover» не показывает, что именно сохранилось. Наблюдение должно отдельно фиксировать path change, association loss, element reselection, state restore и operation retry.

Exactly-once не возникает из надежности транспорта. Его создают идентификатор, commit и дедупликация приложения.

Аутентификация участника не переносила права пользователя

RFC 5355 рассматривает ложные регистрации, вредоносный ENRP, подмену разрешения, replay и DoS. Для защиты участников нужны аутентификация и авторизация; модель использует TLS и PSK в одном административном домене.

Это защищает карту pool. Узел с правом участвовать в инфраструктуре не получает автоматически право выполнить любую бизнес-операцию.

Новый элемент должен проверить прикладного principal. Старый security context мог истечь, быть отозван или привязан к прежнему процессу. RFC 3237 оставляет совместное использование контекста вне области.

Право членства, право пользователя и право переноса состояния должны приниматься отдельно. Аварийный путь не должен быть слабее обычного.

Десять квитанций превращали совет в восстановление

Handle действителен в нужной области. Элемент зарегистрирован в использованной версии. Разрешение выбрало его по известной политике. Transport достиг endpoint. Приложение совместимо и principal принят. Статус старой операции известен. Переданное состояние подлинно, свежо, полно и совместимо. Retry безопасен. Эффект долговечен. Внешнее наблюдение подтвердило результат.

Business card находится между выбором и проверкой. Она улучшает порядок, но не заменяет последующие квитанции.

IANA ведет типы сообщений, параметров, ошибок и policy RSerPool. Реестр подтверждает координацию символов, но не развертывание и не здоровье сервиса.

Тексты Lu Heng о минимальной спецификации и слоях реальности используются как раскрытые аналитические рамки: общая рекомендация меньше локального решения, а символический реестр не равен исполнению. Факты несут RFC и IANA.