WikiDer > Надежный пул серверов - Википедия

Reliable Server Pooling - Wikipedia

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

Вступление

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

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

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

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

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

Возможные политики пула, например, случайный выбор (Random) или наименее загруженный 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 над IP многоадресная передача. Эти объявления могут быть получены PE, PU и другими PR, что позволяет им узнать список PR, доступных в настоящее время в области операции. Преимущество использования многоадресной IP-рассылки вместо широковещательной передачи заключается в том, что этот механизм также будет работать через маршрутизаторы (например, LAN связаны через VPN) и объявления будут - например, в случае коммутируемый Ethernet - слышать и обрабатывать только те станции, которые действительно заинтересованы в этой информации. В случае, если многоадресная IP-рассылка недоступна, конечно, можно статически настроить адреса PR.

Реализации

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

Документы стандартов

RFC

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

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

Другие проекты

внешняя ссылка