Надежное объединение серверов

Надежное объединение серверов ( RSerPool ) — это компьютерных протоколов платформа для управления и доступа к нескольким скоординированным (объединенным в пул) серверам . RSerPool — это стандарт IETF , разработанный рабочей группой IETF RSerPool. ^[1] и описано в RFC 5351, RFC 5352, RFC 5353, RFC 5354, RFC 5355 и RFC 5356.

Введение

В терминологии RSerPool сервер обозначается как элемент пула (PE). В своем пуле он идентифицируется идентификатором элемента пула (PE ID), 32-битным числом. Идентификатор PE выбирается случайным образом при регистрации PE в его пуле. Набор всех пулов обозначается как Handlespace. В более старой литературе это может обозначаться как Пространство имен. Это наименование было исключено, чтобы избежать путаницы с системой доменных имен (DNS). Каждый пул в пространстве дескрипторов идентифицируется уникальным дескриптором пула (PH), который представлен произвольным вектором байтов. Обычно это имя пула в формате ASCII или Unicode, например «DownloadPool» или «WebServerPool».

Каждое пространство дескрипторов имеет определенную область действия (например, организацию или компанию), называемую областью действия. Целью RSerPool явно не является управление глобальными пулами Интернета в рамках единого дескрипторного пространства. Благодаря локализации областей операций можно сохранить пространство дескрипторов «плоским». То есть PH не имеют никакой иерархии в отличие от системы доменных имен с ее верхним уровнем и поддоменами. Это ограничение приводит к значительному упрощению управления пространством дескрипторов.

В рамках операции пространство дескрипторов управляется резервными регистраторами пулов (PR), также называемыми серверами ENRP или серверами имен (NS). PR должны быть избыточными, чтобы избежать превращения PR в единую точку отказа (SPoF). Каждый PR области операции идентифицируется своим идентификатором регистратора (PR ID), который представляет собой 32-битное случайное число. Нет необходимости обеспечивать уникальность PR ID. PR содержит полную копию пространства дескрипторов области операции. PR области операции синхронизируют свое представление пространства дескрипторов с помощью протокола избыточности пространства дескрипторов конечной точки (ENRP). В более старых версиях этого протокола используется термин «Протокол избыточности пространства имен конечной точки»; это имя было заменено, чтобы избежать путаницы с системой доменных имен | DNS, но аббревиатура сохранилась. Благодаря синхронизации пространства дескрипторов с помощью ENRP PR области операции функционально равны. То есть, если какой-либо из PR выйдет из строя, каждый другой PR сможет его беспрепятственно заменить.

Используя протокол доступа к совокупному серверу (ASAP), PE может добавить себя в пул или удалить его, запросив регистрацию или отмену регистрации у произвольного PR в области операции. В случае успешной регистрации PR, выбранный для регистрации, становится домашним PR PE (PR-H). PR-H не только информирует другие PR области действия о регистрации или отмене регистрации своих PE, но также контролирует доступность своих PE с помощью сообщений ASAP Keep-Alive. Сообщение поддержания активности от PR-H должно быть подтверждено PE в течение определенного интервала времени. Если PE не отвечает в течение определенного времени ожидания, он считается неработающим и немедленно удаляется из дескрипторного пространства. Кроме того, ожидается, что ЧП будет регулярно перерегистрироваться. При перерегистрации PE также может изменить свой список транспортных адресов или информацию о своей политике.

Чтобы использовать службу пула, клиент — называемый пользователем пула (PU) в терминологии RSerPool — сначала должен запросить разрешение PH пула в список идентификаторов PE по произвольному PR области операции. Эта процедура выбора обозначается как разрешение дескриптора. В случае, если запрошенный пул существует, PR выберет список идентификаторов PE в соответствии с Политикой выбора участников пула, также называемой просто Политикой пула.

Возможными политиками пула являются, например, случайный выбор (Случайный) или наименее загруженный PE (Наименее используемый). Хотя в первом случае нет необходимости иметь какую-либо информацию о выборе (PE выбираются случайным образом), во втором случае требуется поддерживать актуальную информацию о нагрузке, во втором случае выбирают наименее загруженный PE. Используя соответствующую политику выбора, можно, например, равномерно распределить нагрузку запросов на PE пула.

После получения списка идентификаторов PE от PR, PU запишет информацию PE в свой локальный кэш. Этот кеш обозначается как кеш на стороне PU. Из своего кэша PU выберет ровно один PE — опять же используя политику выбора пула — и установит соединение с ним с использованием протокола приложения, например HTTP через SCTP или TCP в случае веб-сервера. При этом соединении используется услуга, предоставляемая сервером. В случае, если установить соединение не удается или соединение прерывается во время использования услуги, новый PE может быть выбран путем повторения описанной процедуры выбора. Если информация в кэше на стороне PU не устарела, идентификатор PE можно выбрать напрямую из кэша, минуя необходимость запроса PR для разрешения дескриптора. После повторного установления соединения с новым PE состояние сеанса приложения должно быть повторно создано на новом PE. Процедура, необходимая для возобновления сеанса, называется процедурой аварийного переключения и, конечно же, зависит от приложения. Для Например, при загрузке по FTP процедура аварийного переключения может означать сообщение новому FTP-серверу имени файла и позиции последних полученных данных. При этом FTP-сервер сможет возобновить сеанс загрузки. Поскольку процедура переключения при отказе сильно зависит от приложения, она не является частью самого RSerPool, хотя RSerPool обеспечивает далеко идущую поддержку реализации произвольных схем переключения при отказе с помощью своих механизмов сеансового уровня.

Чтобы обеспечить автоматическую настройку компонентов RSerPool, PR могут объявлять о себе через UDP over IP многоадресную рассылку . Эти объявления могут получать PE, PU и другие PR, что позволяет им узнать список PR, доступных в настоящее время в рамках операции. Преимущество использования многоадресной IP-рассылки вместо широковещательной передачи заключается в том, что этот механизм также будет работать через маршрутизаторы (например, локальные сети, соединенные между собой через VPN ), и объявления — в случае, например, коммутируемого Ethernet — будут услышаны и обработаны только станциями. заинтересована в этой информации. В случае, если многоадресная IP-адресация недоступна, конечно, можно статически настроить PR-адреса.

Реализации

Известны следующие реализации:

Проект RSPLIB (с открытым исходным кодом; также является эталонной реализацией рабочей группы IETF RSerPool).
Моторола
Циско
Мюнстерский университет прикладных наук

Стандартные документы

RFC

RFC 3237 — Требования к надежному объединению серверов в пул
RFC 5351 — Обзор надежных протоколов объединения серверов
RFC 5352 — протокол совокупного доступа к серверу (ASAP)
RFC 5353 — Протокол избыточности пространства дескрипторов конечной точки (ENRP)
RFC 5354 - Параметры протокола совокупного доступа к серверу (ASAP) и протокола избыточности пространства дескрипторов конечных точек (ENRP)
RFC 5355 - Угрозы, связанные с объединением надежных серверов (RSerPool) и требования к безопасности в ответ на угрозы
RFC 5356 — Политика объединения надежных серверов в пул
RFC 5525 - Определение модуля MIB надежного пула серверов

Проекты рабочей группы

Другие черновики

Ссылки

^ RSerPool

Внешние ссылки

[1] RSerPool

[1]