СТЕПАН МОСКАЛЕВ, инженер ИТ-систем, MCSE, MCSE:S, MCSE:M, MCITP EA, MCITP EMA, HP AIS, msv121@mail.ru

 ЛЕОНИД ШАПИРО, архитектор ИТ-систем, MVP, MCT, MCSE, MCITP:EA, MCSE:S, MCSE:M, shapiro_leonid@yahoo.com

Инфраструктура открытых ключей
в Windows Server 2016. Часть 6. Distribution Points

Как обеспечить надежную отказоустойчивую работу центров сертификации, мы уже разобрались [1]. Но этого недостаточно для полноценного решения отказоустойчивой инфраструктуры открытых ключей. Что же делать?

Конечно, это точки распространения (Distribution Points). При их недоступности оказываемся в ситуации неработающего решения, поскольку пользователь не может проверить сертификаты удостоверяющих центров, а значит, нет доверия к инфраструктуре и спискам отзыва сертификатов, и, стало быть, он не может доверять конкретному сертификату.

В статьях [2], [3] и [4] мы уже упоминали наиболее используемые варианты точек распространения – это веб-серверы (используется протокол http [5]) и сервер каталога (LDAP [6]).

Если о доступности ресурсов по протоколу LDAP, опубликованных в Active Directory, мы можем не заботиться – в конце концов это задача службы каталога, и она с этим отлично справится, – то веб-сервер потребует нашего внимания.

Самый распространенный способ проверки иерархии доверия (проверка сертификатов удостоверяющих центров) и списка отзыва сертификатов – именно использование веб-серверов и протокола http, что вполне объяснимо ввиду универсальности этого решения и удобства использования как внутрикорпоративными клиентами, так и внешними пользователями. Отказ сервера веб приводит к невозможности проверки сертификатов центров сертификации и списков отзыва. Получается, у нас в системе есть потенциальный риск, который надо минимизировать.

Решение здесь на поверхности – это использование двух и более веб-серверов с одним и тем же содержимым. В этом случае отказ одного веб-сервера не должен приводить к краху всю систему, то есть необходимо построить веб-ферму.

Важный момент, который надо подчеркнуть, – содержимое должно быть идентичным. Получается, нам нужен отказоустойчивый кластер? Вовсе нет. Это стоит решить иначе, более простым способом. Нет нужды обеспечивать дублирование системы хранения из-за нескольких файлов. Можно поступить проще, обеспечить отказоустойчивость самого сервиса и только его, а синхронизацию данных реализовать другими способами, при этом было бы неплохо реализовать возможность одновременного использования всех наших веб-серверов для ответа на запросы пользователей.

У Microsoft есть вариант, чтобы добиться этой цели, и это кластер NLB (Network Load Balancing) [7]. NLB представляет собой группу серверов – узлов кластера. На каждом выполняется собственная копия приложения. Входящие запросы распределяются между узлами динамически, при этом обращение происходит по единому IP-адресу. Используются механизмы проверки отказа узла кластера и перенаправления трафика на работающие. В сущности, что это ровно то, что нам нужно. Остается только вопрос синхронизации содержимого, но к нему мы вернемся чуть позже.

На самом деле применение NLB – это достаточно бюджетное решение, поскольку не потребуется никакого дополнительного программного или аппаратного обеспечения и использование NLB входит в обычную схему лицензирования. Этот функционал есть в составе самой операционной системы. Но, с другой стороны, это не универсальный вариант, поскольку обладает весьма ограниченными возможностями (вы можете познакомиться с возможностями NLB по приведенной ссылке более детально [8]). Важно понимать, что для нашего промышленного использования и решения нашей задачи в NLB не подойдет.

Лучше использовать специальный балансировщик нагрузки, или как его еще называют контроллер доставки приложений (Application Delivery Controller). Здесь схема решения изменяется, то есть балансировщик нагрузки является точкой входа для клиентов.

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

Существуют разные стратегии балансировки нагрузки, позволяющие учесть уровень загруженности серверов, прежде чем направить на него трафик, обеспечить работу с определенным сервером для определенного пользователя и многое другое.

Конечно же, прежде чем перенаправить трафик на наш сервер, балансировщик проверит работоспособность сервиса, причем сделать это можно не просто обращением на сам сервер, например отправив icmp-проверку, по сути, простой ping, но и куда более продвинутыми способами. Скажем, мы можем удостовериться в работоспособности требуемой нам службы и проверить наличие определенных файлов. Базовый сервис NLB не даст нам настолько широких возможностей.

Казалось бы, вот теперь все стало гораздо лучше, но снова у нас возникает единая точка сбоя – сам контроллер доставки приложений. Теперь уже его отказ приводит к невозможности работы нашей системы. Ведь все запросы пересылаются на него. Получается, что и его отказоустойчивость, и доступность нам надо обеспечить. Здесь это может быть достигнуто разными способами. Одна из наиболее общих технологий – VRRP [9]. Ее поддерживают все производители балансировщиков, кроме этого варианта есть и другие специфичные для каждого из производителей. Один из вариантов мы рассмотрели в статье о доставке приложений [10].

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

Таким образом, во многих ситуациях выход из строя основного устройства оказывается незаметным для клиента. Эта функциональность является серьезным преимуществом по сравнению с базовым NLB.

Структурная схема решения представлена на рис. 1.

Рисунок 1. Структурная схема решения

Вместе с тем ситуация может быть сложнее, например, когда речь идет о работе с несколькими ЦОДами. Решить эту проблему недоступности HTTP поможет глобальная балансировка, то есть мы можем проверять не только работоспособность конкретного сервера в центре обработки данных, но и доступность самого ЦОД, и перенаправить запросы на другой. Все эти тонкости уже выходят за рамки этой статьи. Познакомиться с вопросами глобальной балансировки можно по приведенной ниже ссылке [11].

Ну и наконец вы, вероятно, давно заметили слабое место во всем нашем решении, а именно: у нас остался вопрос обеспечения синхронизации данных между нашими точками распространения, Distribution Points. Как наши сертификаты и списки отзыва будут попадать на наши серверы веб?

Здесь нам поможет сервис Microsoft DFS [12], обеспечивающий решение вопроса синхронизации данных на серверах.

Продолжение следует…

1. Москалев С., Шапиро Л. Инфраструктура открытых ключей в Windows Server 2016. Часть 5. Отказоустойчивость. // «Системный администратор», № 12, 2018 г. – С. 29-31. URL: http://samag.ru/archive/article/3775.
2. Шапиро Л. Инфраструктура открытых ключей в Windows Server 2016. Часть 1. Предварительный этап. // «Системный администратор», № 1-2, 2018 г. – С. 23-27. URL: http://samag.ru/archive/article/3576.
3. Москалев С., Шапиро Л. Инфраструктура открытых ключей в Windows Server 2016. Часть 2. RootCA. // «Системный администратор», № 3, 2018 г. – С. 16-19. URL: http://samag.ru/archive/article/3605.
4. Москалев С., Шапиро Л. Инфраструктура открытых ключей в Windows Server 2016. Часть 3. Issuing CA. // «Системный администратор», № 7-8, 2018 г. – С. 26-28. URL: http://samag.ru/archive/article/3685.
5. HTTP – Hypertext Transfer Protocol – https://www.w3.org/Protocols/.
6. Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map – https://tools.ietf.org/html/rfc4510.
7. Балансировка сетевой нагрузки – https://docs.microsoft.com/ru-ru/windows-server/networking/technologies/network-load-balancing.
8. Network Load Balancing Deployment Guide – https://docs.microsoft.com/ru-ru/windows-server/networking/technologies/network-load-balancing.
9. Virtual Router Redundancy Protocol – https://tools.ietf.org/html/rfc5798.
10. Шапиро Л. Доставка приложений в корпоративном ЦОДе и облачных средах. Часть 3. Отказоустойчивость ADC. // «Системный администратор», № 1-2, 2017 г. – С. 46-50. URL: http://samag.ru/archive/article/3360.
11. Prakash Sinha Global Server Load Balancing (GSLB) Use Cases – https://blog.radware.com/applicationdelivery/2018/05/global-server-load-balancing-gslb-use-cases/.
12. Обзор пространств имен DFS – https://docs.microsoft.com/ru-ru/windows-server/storage/dfs-namespaces/dfs-overview.

Ключевые слова: отказоустойчивость, доступность, центры распространения.

Комментарии могут оставлять только зарегистрированные пользователи