U-Registry

Общий обзор

U—Registry – система, которая позволяет осуществлять полный цикл управления регистрацией .УКР IDN ccTLD. U-Registry состоит из следующих основных компонентов:

Особое внимание было уделено вопросам надёжности и восстановления системы.

Кроме этого, U-Registry обеспечивает биллинг, систему коммуницирования с регистраторами, возможности настройки управления и т.д. Система является полностью настраиваемой и может поддерживать любой язык в стране реализации.

Ядро программного обеспечения U-Registry представляет собой многоуровневую, распределенную систему приложений, которые реализованы на платформе J2EE, с использованием базы данных PostgreSQL.

Заинтересованными сторонами U-Registry являются ccTLD/gTLD Реестры, регистраторы и регистранты.

Мы предлагаем решение «под ключ», которое может быть реализовано полностью на серверах заказчика или заказчик может использовать аутсорсинг уже установленной системы.

Система может одновременно обслуживать неограниченное количество TLD/IDN TLD

Система спроектирована и построена с использованием пятиуровневой архитектуры:

Уровень Функция
Внешний сетевой уровень

 

 Этот уровень обеспечивает безопасный и надёжный обмен данными между регистраторами и уровнем протокола. Внешний сетевой уровень включает в себя межсетевые экраны, балансировку нагрузки и т.д.
Уровень протокола

 

 Этот слой состоит из серверов, обеспечивающих интерфейс взаимодействия регистратора. В настоящее время этот слой включает в себя веб-серверы и EPP-серверы.
Внутренний сетевой уровень

 

 Этот слой обеспечивает связь между уровнем протокола и уровнем сервера приложений. Наличие этого уровня обеспечивает дополнительную безопасность и балансировки нагрузки между серверами приложений.
Уровень сервера приложений Этот уровень служит в качестве промежуточного между уровнем протокола и уровнем базы данных. Он реализует всю бизнес-логику приложений.
Уровень базы данных

 

 Этот уровень обеспечивает надёжное хранение всех данных, используемых в системе реестра, а также служит источником для базы данных, используемой WHOIS и Hidden Primary Master DNS.

Реляционная база данных PostgreSQL (http://www.postgresql.org/) используется в качестве сервера баз данных с помощью транзакций и кластера с синхронной репликацией. Генерация файла зоны для .УКР IDN ccTLD (.xn — j1amh) производится из информации, хранящейся в базе данных.

Система баз данных U-Registry обеспечивает:

  1. Хранение данных
  2. Целостность данных
  3. Параллельный доступ к данным в многопоточной среде
  4. Репликацию данных
  5. Масштабируемость
  6. Безопасность и привилегии доступа

U-Registry поддерживает безопасность многоуровневого контроля доступа. Доступ к системе реестра допускается только с помощью SSL.

Все операции всех пользователей системы регистрируются в режиме реального времени.

DNS

Реализация DNS базируется на проверенном программном обеспечении BIND. DNS кластеры географически распределены и подключены к различным сетям (сетки С и выше). Система готовит обновлённый файл зоны на основе информации из базы данных, и передаёт его на сервер Primary Hidden DNS, который, в свою очередь распределяет данные между серверами Slave DNS. Primary Hidden DNS сервер не обслуживает DNS-резолвинг запросы из Интернета. Заказчик может описать свои требования к системе DNS в документе «Уровень качества обслуживания регистраций доменов ccTLD/gTLD» и ТЦИ, входящий в состав Консорциума, их реализует.

DNS zone  file

Наши расчёты основаны на среднем размере 400 байт на одно имя домена в файле зоны DNS. Таким образом, размер файла зоны для 1000000 доменов будет до 382MB.

RDDS (служба WHOIS)

Служба WHOIS U-Registry поддерживает «толстую» модель реестра. Это означает, что реестр содержит всю контактную информацию о регистранте. Мы считаем, что это реалистичный подход для будущего любого обновления сервиса WHOIS. С другой стороны, это снижает требования к регистраторам и способствует соблюдению целостности данных и формирует ответственность реестра.

Реестр использует распределённую сеть WHOIS-серверов, которые позволяют получать информацию о доменных именах с помощью запросов на порт 43 или веб-интерфейс. WHOIS сервис поддерживает UTF-8 (Unicode) кодировки и предоставляет ответы на запросы как в первоначальном написании на любом языке, так и в ASCII.

SRS

U-Registry обеспечивает взаимодействие с регистраторами через EPP-интерфейс с целью выполнения всех необходимых операций с доменами, хостами и контактами. Описание поддерживаемого EPP-интерфейса поставляется специальным документом. EPP-протокол может использоваться только аккредитованными регистраторами; регистранты не взаимодействуют непосредственно с реестром, они должны действовать только через своего регистратора.

Надёжность

U-Registry может гарантированно выполнять требования к уровню обслуживания не хуже чем со значениями параметров:

Parameter Description SLR
Доступность услуг DNS Возможность ответа на DNS-запросы от пользователей Интернета с публично зарегистрированного полномочного DNS-сервера с «IP-адресом». Все полномочные DNS-серверы с зарегистрированными «IP-адресами» отслеживаются и испытываются по отдельности. Если 51% или более из DNS-тестовых посылок получат неопределённые/безответные результаты «DNS-тестов» на имя сервера с «IP-адресом» в течение определённого времени, DNS-сервер с «IP-адресом» будет считаться недоступным. 0 мин. времени простоя = 100% доступность
Доступность DNS сервера Возможность ответа на DNS-запросы от пользователей Интернета с публично зарегистрированного полномочного DNS-сервера с «IP-адресом». Все полномочные DNS-серверы с зарегистрированными «IP-адресами» отслеживаются и испытываются по отдельности. Если 51% или более из DNS-тестовых посылок получат неопределённые/безответные результаты «DNS-тестов» на имя сервера с «IP-адресом» в течение определённого времени, DNS-сервер с «IP-адресом» будет считаться недоступным =< 300 мин. простоя в месяц (≈ 99,31%)

зависит от SLA центров обработки данных
RTT для TCP DNS RTT последовательности пакетов от начала TCP-соединения до его конца, в том числе получение DNS-ответа только на один DNS-запрос. Если RTT в 5 раз больше, чем время, указанное в соответствующем SLR, то RTT будет считаться неопределённым. =< 1500 мс, по меньшей мере для 95% запросов
 RTT для UDP DNS RTT последовательности пакетов от начала UDP-соединения до его конца, в том числе получение DNS-ответа только на один DNS-запрос. Если RTT в 5 раз больше, чем время, указанное в соответствующем SLR, то RTT будет считаться неопределённым. =< 500 мс, по меньшей мере для 95% запросов
Время обновления для DNS Время, измеренное от приёма EPP-подтверждение команды преобразования доменного имени, пока DNSсерверы родительского домена отвечают на DNS-запросы с данными в соответствии с вносимыми изменениями. Это относится только к изменениям информации о DNS. =< 60 min, for at least 95% of the probes

Резервное копирование и восстановление данных

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

Резервное копирование и восстановление данных будет осуществляться в соответствии с процедурами, описанными в «Плане ликвидации последствий чрезвычайных ситуаций» (отдельный документ входит в комплект).

Резервное копирование данных осуществляется с помощью различных методов:

  • с использованием RAID массивов;
  • периодическое формирование дампов данных;
  • периодическое создание полного образа диска из ключевых компонентов системы;
  • сохранение файла дампа базы данных и файла зоны ежедневно на энергонезависимых носителях.

Для обеспечения отказоустойчивого решения в отношении выхода из строя основных серверов, реестра, DNS, WHOIS серверов и баз данных в режиме реального времени, синхронизированного с «горячей заменой» серверов, а также для обеспечения синхронизации высокой скорости, используются устройства InfiniBand.

В зависимости от уровня инцидента, после чего требуется восстановление данных, существуют несколько сценариев восстановления данных:

  • откат внутренней транзакции;
  • восстановление данных из дампа;
  • восстановление элементов системы из образа диска;
  • восстановление файла базы данных и файла зоны из энергонезависимой памяти и горячих серверов замены;
  • или, в крайнем случае, воссоздание системы на новом оборудовании с использованием ранее сохранённых данных.

Невыполнение какой-либо части системы не останавливает работу других компонентов. Например, если DNS или RDDS (WHOIS) серверы по какой-либо причине потеряли связь с системой регистрации они будут продолжать работать с набором кэшированных данных, полученных до потери соединения. После того, как соединение будет восстановлено, компоненты будут сразу же получат актуальные данные.

Наличие связи между элементами системы постоянно контролируется и каждый сбой связи является предметом анализа и исправления ошибок.

Время для полного обновления локальных данных реестра (Master DB, DNS DB, RDDS DB) в аварийном режиме, сбоев и отказов не более 25 минут. Эти нормативные параметры будут описаны в Плане аварийного восстановления, который будет написан в соответствии с требованиями заказчика.

Поддерживаются следующие решения «избыточности»:

  1. Standby. Резервный сервер представляет собой второй сервер, который находится в том же самом центре обработки данных и работает параллельно с главным сервером и может быть переведён в оперативный в случае выхода из строя основного сервера производства (при сбое сервера). Резервный сервер содержит актуальную копию базы данных на первичном сервере, которая тиражируется в режиме реального времени. Резервный сервер также может быть использован, когда первичный сервер становится недоступным из-за планового ремонта.
  2. Backup database servers. Это, по существу, резервный сервер, который содержит актуальную копию базы данных на первичном сервере, который тиражируется в режиме реального времени и находится в другом центре данных. Система переключается на резервный сервер в случае стихийного бедствия, когда оба первичного сервера и резервный сервер (расположенный в том же центре обработки данных) становятся недоступными.
  3. Spare servers. Запасные серверы одного и того же производителя, такой же аппаратной конфигурации с предварительно установленной и предварительно сконфигурированной копией операционной системы и прикладных программ, которые могут быть использованы, если один из производственных серверов (основной или резервный) терпит аварию.

Сочетание вышеуказанных он-лайн и офф-лайн методов позволяет избежать потери информации и даёт 100% гарантии восстановления текущего состояния системы и базы данных.