Главная Networks, Security, Windows, Без рубрики Отказоустойчивость и доступность центров распространения (Distribution Points)
  • Отказоустойчивость и доступность центров распространения (Distribution Points)

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

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

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

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

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

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

    У 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.

     

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

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

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

     

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

    Статья опубликована в журнале “Системный Администратор”.

    Литература

    [1] Москалев С., Шапиро Л. Инфраструктура открытых ключей в Windows Server 2016. Часть 5. Отказоустойчивость № 12, 2018 г. – С. 29-31.

    [2] Шапиро Л. Предварительный этап. / «Системный администратор», № 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/more/184

    [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[6]

    [7] Балансировка сетевой нагрузки https://docs.microsoft.com/ru-ru/windows-server/networking/technologies/network-load-balancing