Справочный центр ALD Pro 3.1.0
Планирование ресурсов¶
От работы доменных служб зависит надежность работы всей ИТ инфраструктуры, поэтому при планировании домена администраторы должны действовать проактивно и применять различные способы вертикального и горизонтального масштабирования, чтобы исключить проблемы недостаточной производительности. Ниже представлены рекомендации, которые помогут в решении указанной задачи.
Вертикальное масштабирование¶
Вертикальным масштабированием называют повышение производительности системы за счет повышения производительности отдельного узла путем выделения серверу дополнительных вычислительных ресурсов — оперативной памяти, потоков центрального процессора и т.п.
Объем памяти¶
В работе службы каталога преобладают операции чтения, поэтому в производительности контроллера решающую роль играет достаточный объем оперативной памяти, чтобы контроллер мог обрабатывать запросы без обращения к медленным дискам.
Файлы каталога расположены в папке /var/lib/dirsrv, после развертывания первого контроллера размер базы составляет не менее 45 Мб и увеличивается по мере создания объектов, в среднем по 50 КБ на каждую дополнительную учетную запись пользователя. Таким образом, объем памяти диска рассчитывается: для нужд самой операционной системы контроллеру следует выделить не менее 50 ГБ, а под хранение каталога для упрощения расчетов выделяется по 1 ГБ на каждые 20 тысяч объектов. Расчетное значение должно составлять не более 40% от доступного пространства.
Внимание
Производительность файловой подсистемы влияет на скорость записи, поэтому рекомендуется использовать SSD или RAID с высокой производительностью чтения/записи. Скорость произвольного чтения у современных твердотельных дисков составляет порядка 50-100 тысяч операций в секунду (IOPS).
Ещё одним вариантом увеличения производительности LDAP может быть использование разных устройств для корня файловой системы (/) и каталога с БД (/var/lib/dirsrv/).
Для загрузки каталога требуется больше оперативной памяти, т.к. для ускорения операций поиска служба ns-slapd индексирует данные каталога. Пустая база данных занимает в памяти не менее 65 Мб, и это значение растет по мере увеличения числа объектов, на каждую дополнительную учетную запись в среднем добавляется 50 КБ. Таким образом, минимально необходимый объем оперативной памяти можно рассчитать математически: для нужд самой операционной системы контроллеру следует выделить порядка 2-3 ГБ, а для работы с каталогом в целях упрощения возьмем по 1ГБ на каждые 20 тысяч объектов:
Ниже приведено несколько примеров:
Для работы с каталогом, в котором содержится 10 000 пользователей и 100 групп, контроллеру нужно выделить порядка 4 ГБ ОЗУ:
Для работы с каталогом, в котором 100 000 пользователей и 30 000 групп, контроллеру нужно выделить до 10 ГБ ОЗУ:
Примечание
При создании учетных записей контроллер домена потребляет в два раза больше оперативной памяти, т.е. примерно 100 КБ на каждую новую запись, которая высвобождается после перезапуска службы dirsrv. Эта особенность работы не проявляется в сценарии репликации, но ее следует учитывать при планировании начальной миграции.
Несмотря на возможность работы с ограниченным объёмом оперативной памяти (см. пример расчёта выше) на контроллере домена, это может вызвать высокую интенсивность чтения данных с диска, что приведёт к общему замедлению системы и сервиса LDAP (ns-slapd) в частности. Для обеспечения надёжной работы контроллера домена и сопутствующих сервисов, а также для исключения увеличения времени репликации из-за дополнительных операций чтения данных с диска, рекомендуется на контроллерах домена не уменьшать объём оперативной памяти ниже 8 ГБ.
Примечание
Рекомендуемый минимальный размер оперативной памяти одного контроллера домена — 8 ГБ.
Количество потоков центрального процессора¶
Если требуемый объем оперативной памяти зависит от размера базы данных, то количество ресурсов центрального процессора определяется тем, сколько пользователей должен обслуживать конкретный контроллер. Например, в базе может быть 100 тысяч пользователей, но нагрузка по их обслуживанию может распределяться между 20 репликами, тогда на каждый контроллер будет приходиться не более 5 тысяч обслуживаемых пользователей.
Приложения имеют разный сценарий взаимодействия с каталогом, что влияет на его нагрузку. Таким образом, у каждой организации получается свой уникальный профиль использования ресурсов этой службы. Поэтому администраторам следует рассчитать данный показатель для своей организации самостоятельно, достигая использования ЦПУ на уровне 40% от максимума в пиковые периоды, а отправной точкой может быть выделение одного потока для работы операционной системы и еще по одному потоку на каждую тысячу пользователей.
Ниже приведено несколько примеров:
Для обслуживания 2-3 тысяч пользователей контроллеру домена нужно выделить не менее 4 потоков.
Примечание
Компания RedHat в своей документации рекомендует использовать контроллеры домена именно такой производительности, но эта рекомендация не подойдет крупным организациям, в штате которых работает несколько сотен тысяч сотрудников, т.к. контроллер, обслуживающий 10 тысяч сотрудников, будет в три раза эффективнее использовать оперативную память в пересчете на активного пользователя, чем контроллер, обслуживающий 3 тысячи сотрудников.
Для обслуживания 10 тысяч пользователей на КД нужно выделить 11 потоков.
Следует отметить, что данные оценки сильно зависят от сценария использования службы каталога, поэтому на такое количество пользователей рекомендуется выделять порядка 8-12 потоков.
Если под контроллер домена выделить физический сервер с двумя процессорами Xeon Silver (48 потоков), то теоретически он сможет обслуживать 47 тысяч пользователей.
При планировании таких контроллеров следует принимать во внимание ограничения по пропускной способности сети. Для обслуживания такого числа пользователей потребуется использование сетевого интерфейса со скоростью передачи данных не менее 1 Гбит/с.
При выборе процессора следует учитывать, что LDAP-запросы в большей степени зависят от скорости дисковой подсистемы, а Kerberos-аутентификация использует сложные криптографические алгоритмы, поэтому в большей степени зависит от вычислительной производительности контроллера. Увеличивать вычислительные мощности контроллера можно как за счет добавления дополнительных ядер, так и за счет увеличения их частоты, при этом следует учитывать, что, если нагрузка на ядра не превышает 40%, то дополнительный прирост производительности можно получить только за счет увеличения частоты ядер.
Не рекомендуется использовать процессоры с базовой тактовой частотой ниже 1,8 ГГц. Это может негативно сказаться на скорости работы КД, как части системы.
Примечание
При изменении количества потоков процессора (замена процессора или изменение настроек виртуальной машины) необходимо обновить переменную DAEMON_ARGS в файле /etc/default/krb5-kdc и перезапустить службу krb5-kdc.
Пропускная способность сети¶
При планировании домена следует учитывать два основных вида трафика:
трафик клиентских запросов (Kerberos и LDAP запросы к каталогу);
трафик репликации (по стандартному LDAPS протоколу).
Клиентский трафик¶
В процессе обслуживания клиентов контроллеры домена, как правило, получают небольшие входящие запросы на предоставление относительно больших объемов данных, поэтому на контроллерах обычно преобладает исходящий трафик.
Любые оценки являются субъективными, однако, в качестве общих рекомендаций следует исходить из того, что при количестве пользователей до 5 000 будет достаточно интерфейса с пропускной способностью в 100 Мбит/с, а если предполагается обслуживать больше пользователей, нужно установить на контроллере интерфейс с пропускной способностью в 1 Гбит/с. В результате оптимизации нужно добиться, чтобы показатель использования сети не выходил за пределы 40% от максимума в пиковые периоды.
Учитывая то, что внешние каналы связи редко достигают гигабитных скоростей и активно используются пользователями для выхода в интернет, в каждом офисе рекомендуется создавать отдельный сайт и размещать в нем один-два контроллера для локальной обработки клиентских запросов. Такой подход к организации домена позволит разгрузить VPN туннели между офисами и использовать эти каналы связи только для репликации.
Трафик репликации¶
В ходе репликации контроллеры обмениваются только новыми и измененными данными, поэтому объем трафика оказывается небольшим, и его довольно просто прогнозировать, например:
при добавлении 1000 пользователей трафик репликации окажется в два раза больше, чем при добавлении 500 пользователей;
если устанавливается новый контроллер в удаленном офисе с подключением в 5 Мбит/с, то ожидается, что на репликацию базы данных размером 1,5 ГБ потребуется не менее часа.
Внимание
Крайне важно исключить долгую работу контроллера в автономном режиме, т.к. после этого может потребоваться повторная инициализация контроллера с загрузкой всего каталога.
Сервис Глобального каталога¶
Глобальный каталог представляет из себя ещё одну базу данных (экземпляр dirsrv), который содержит частичную копию (часть атрибутов) некоторых объектов службы каталога. Он необходим для корректной работы доверительных отношений и устанавливается на контроллере домена, выделенном под него. На контроллер домена, где будет установлен глобальный каталог, необходимо выделить дополнительно 15-20% дискового пространства и такой же объем ОЗУ. Дополнительным потреблением процессорного времени можно пренебречь, т.к. чтение объектов из памяти достаточно малозатратная операция для ЦПУ.
Модуль синхронизации¶
Основные ресурсы, потребляемые при работе модуля синхронизации — это дисковое пространство, размер которого будет прямо пропорционален количеству синхронизируемых объектов. Дисковое пространство потребляется БД PostgreSQL, где хранятся метаданные всех синхронизированных объектов. Для корректной работы модуля синхронизации необходимо выделить дополнительно 15-20% дискового пространства от расчётного.
С настройками по умолчанию PostgreSQL хранит кеш объектов в оперативной памяти. Учитывая, что около 80% обрабатываемых запросов являются запросами на чтение, будет достаточно выделить дополнительно 10-15% от расчетного объёма ОЗУ.
Планирование ресурсов RabbitMQ¶
Начиная с версии ALD Pro 2.3.0, для RabbitMQ отключена кластеризация между контроллерами домена, поэтому брокер сообщений обеспечивает только транзакционность Портала управления ALD Pro и его накладными расходами можно пренебречь, отнеся их к базовым потребностям операционной системы.
Планирование ресурсов Salt¶
Начиная с версии ALD Pro 2.4.0, для управления хостами используется только автономная служба Salt Minion, которой не требуется Salt Master на сервере, поэтому на контроллерах домена дополнительные ресурсы для работы системы конфигурирования выделять не требуется.
Горизонтальное масштабирование¶
Горизонтальным масштабированием называют повышение производительности системы за счет увеличения количества вычислительных узлов, обслуживающих клиентов, без изменения их производительности. Например, если предполагается использовать контроллеры с 8-12 потоками ЦПУ, которые могут обслуживать по 10 тысяч пользователей, то в организации со штатом в 30 тысяч сотрудников потребуется не менее 3 контроллеров такой производительности:
Синхронизация данных между контроллерами обеспечивается процессом репликации, во FreeIPA она происходит в мультимастер-режиме, т.е. изменения можно вносить на любом контроллере. Балансировка нагрузки и отказоустойчивость обеспечивается через DNS — клиентам выдается до трех DNS-серверов, каждый из которых может принадлежать определенному сайту и выдавать SRV-записи в соответствии принадлежностью служб к соответствующим сайтам.
Топология соглашений о репликации¶
В качестве примера обычно приводят топологию из четырех сайтов, см. Топология из четырех сайтов, в каждом из которых по четыре контроллера, в результате чего полученная схема вводит администраторов в заблуждение, что в сайте может быть не более четырех контроллеров.
Рисунок 5 Топология из четырех сайтов¶
В реальной жизни редко бывает, чтобы численность сотрудников в каждой локации была одинаковой, поэтому количество контроллеров может быть, как больше, так и меньше. Ниже приведен пример с тремя сайтами численностью 20, 30 и 80 тысяч человек, см. Топология из трех сайтов.
Рисунок 6 Топология из трех сайтов¶
Рекомендации по построению топологии¶
При планировании топологии следует учитывать несколько рекомендаций:
Для обеспечения надежности на уровне 0,99 следует установить в каждом сайте не менее двух контроллеров домена. Если предположить, что сервер работает с надежностью в 90%, тогда при добавлении еще одного такого сервера получается, что в 90% случаев от оставшихся 10% система будет оставаться все так же работоспособной. Итоговая надежность повысится до 0.9 + 0.1 * 0.9 = 0.99. Максимальное количество контроллеров на сайт не лимитируется, но в настройках рабочих станций можно задать только три DNS-сервера, поэтому стандартными средствами можно обеспечить надежность до 0,999, а дополнительные контроллеры будут использоваться только для распределения нагрузки.
Для обеспечения надежности репликации контроллеров домена на уровне 0,99 у каждого из них должно быть не менее 2 соглашений о репликации с другими контроллерами домена. Для обеспечения надежности межсайтовой репликации на том же уровне у каждого сайта должно быть не менее 2 соглашений о репликации с контроллерами из других сайтов.
Не рекомендуется создавать более четырех соглашений о репликации на одном контроллере домена, т.к. при недоступности каких-то из серверов алгоритм репликации будет останавливаться на каждом из них, ожидая ответа, что будет приводить к значительному снижению скорости репликации. По этой же причине рекомендуется удалять из домена контроллеры, которые более не используются, а число временно выключенных серверов сводить к минимуму.
При планировании топологии нужно стремиться к тому, чтобы между любыми двумя контроллерами в домене было не более 5-10 промежуточных узлов, но при этом количество контроллеров, у которых сразу более 4 соглашений о репликации, нужно стараться сводить к минимуму. Такая оптимизация необходима для уменьшения количества прыжков (hops), за которые изменения могут быть распространены в домене. При этом вне зависимости от топологии домена работу ИТ-службы нужно организовать таким образом, чтобы изменения в домен вносились как можно ближе к потребителю. Например, если потребуется сбросить пароль сотруднику из Новосибирска, то эти изменения должен внести местный администратор с контроллера из своего сегмента сети. В этом случае такие изменения будут максимально быстро реплицированы на все контроллеры, которые обслуживают сотрудника непосредственно, а когда изменения станут доступны на серверах московского региона — это уже не принципиально.
Для максимальной производительности репликации под эту функцию можно выделить отдельные контроллеры и снять с них обслуживание обычных пользователей путем переключения в режим скрытой реплики (hidden replica).
Результаты нагрузочного тестирования¶
В части горизонтального масштабирования:
В один домен можно ввести >400 контроллеров, и это не нарушит работу механизма репликации. Не наблюдается технических ограничений для создания доменов на 2-3 тысячи контроллеров, а с выходом функции доверительных отношений между доменами ALD Pro в версии 2.3.0 большую ИТ-инфраструктуру можно разбить на несколько КД и вопрос горизонтального масштабирования снимается полностью.
Согласно лабораторным испытаниям, на одном контроллере домена может быть создано более 150 соглашений о репликации сразу, но при планировании топологии домена на практике рекомендуется создавать не более четырех. Важно учитывать, что при недоступности партнера по репликации КД будет пытаться установить с ним связь несколько раз, что может приводить к значительным задержкам, если таких серверов окажется много. Поэтому для обеспечения надежной репликации на КД рекомендуется создавать не менее двух соглашений, а для исключения задержек в работе этого механизма избегать более четырех.
В части вертикального масштабирования контроллер может держать нагрузку >10 тысяч рабочих станций. При увеличении количества ядер производительность возрастает линейно с коэффициентом 0.9 в широком диапазоне, т.е. увеличение числа ядер в 2 раза повышает производительность на 80%. Использование технологии гиперпоточности добавляет 50-75%, но ее эффективность снижается, если нагрузка на ядра становится выше 80%. В дополнение к сказанному текущая архитектура групповых политик ALD Pro переносит всю нагрузку по суммированию параметров на рабочие станции, поэтому обслуживание тысяч хостов не создает ощутимой нагрузки на сервер.
В домене можно создать >30 млн. объектов, и это не нарушит работу контроллеров. Увеличение количества объектов приведет к увеличению размера базы данных и объема потребляемой оперативной памяти. В больших инфраструктурах настоятельно рекомендуется отключать плагин Schema Compatibility, т.к. построение виртуального дерева объектов каталога создает существенную задержку в запуске служб (на базе в 30 млн. объектов задержка составляла чуть более 30 минут).
Пример производительности в пересчете на один контроллер домена, полученный на каталоге размером 30 млн. объектов (более 100 ГБ на диске). Характеристики каждого контроллера 16 ЦПУ, 128 ГБ ОЗУ.
LDAP Search - 5 040 чтений в секунду
LDAP Bind - 126 аутентификаций в секунду
LDAP Modify - 126 изменений в секунду
Kerberos TGT - 180 аутентификаций в секунду
Рисунок 7 Результаты нагрузочного тестирования¶
Рисунок 8 Результаты нагрузочного тестирования¶
Рисунок 9 Результаты нагрузочного тестирования¶
Практический кейс по планированию ресурсов¶
Исходные требования:
Объектов в каталоге: 1 млн. (650 тыс. пользователей, 350 тыс. групп).
Обслуживаемых пользователей: 2 тыс.
Расчеты:
Для размещения файлов операционной системы и каталога на жестком диске потребуется не менее 60 ГБ HDD:
Для того, чтобы контроллер домена (КД) смог разместить каталог с 1 млн. объектов в оперативной памяти, ему потребуется не менее 100 ГБ ОЗУ:
Если к контроллеру будут обращаться 2 тысячи пользователей, то ему потребуется не менее 3 потоков:
Конкретно к этому серверу будет обращаться 2 тыс. пользователей, поэтому достаточно одной виртуальной машины. Но если нужно будет обеспечить единовременную работу всех 600 тысяч пользователей, то потребуется не менее 300 таких контроллеров и более целесообразным будет увеличить производительности контроллеров до 10 тысяч пользователей (8-12 потоков ЦПУ), тогда количество контроллеров можно будет сократить до 60 единиц.
Следует учесть, что объекты в каталоге создаются в среднем со скоростью один объект в секунду и это значение растет по мере увеличения количества объектов в каталоге, поэтому на создание 1 млн. объектов уйдет не менее 11 дней. Ускорить процесс можно увеличением числа потоков, но зависимость будет нелинейной, т.к. потоки будут конкурировать за общие ресурсы.
Дополнительного ускорения процедуры можно достичь путем создания пользователей на нескольких контроллерах одновременно, т.к. при репликации вычислительных ресурсов требуется меньше, чем при создании объектов.
Для тестирования остальных подсистем в соответствии с типовой схемой, см. Типовая схема инфраструктуры, нужно дополнительно 8 виртуальных машин: 2 ЦПУ, 4 ГБ ОЗУ, 100 ГБ HDD (DHCP, установка ОС по сети, сервер печати, сервер общего доступа к файлам, сервер аудита, сервер мониторинга, сервер репозиториев, клиентская машина).
Рисунок 10 Типовая схема инфраструктуры¶
Для упрощения предварительного расчёта ресурсов можно воспользоваться таблицами:
На один КД |
RAM |
HDD |
|---|---|---|
Базовые требования |
3 |
50 |
Кол-во объектов |
||
3 000 |
8,0 |
50,2 |
5 000 |
8,0 |
50,3 |
10 000 |
8,0 |
50,5 |
50 000 |
8,0 |
52,5 |
100 000 |
8,0 |
55,0 |
150 000 |
10,5 |
57,5 |
200 000 |
13,0 |
60,0 |
250 000 |
15,5 |
62,5 |
300 000 |
18,0 |
65,0 |
400 000 |
23,0 |
70,0 |
500 000 |
28,0 |
75,0 |
700 000 |
38,0 |
85,0 |
800 000 |
43,0 |
90,0 |
1 000 000 |
53,0 |
100,0 |
1 500 000 |
78,0 |
125,0 |
2 000 000 |
103,0 |
150,0 |
На домен, сайт |
CPU |
Кол-во КД |
|---|---|---|
Базовые требования |
1 |
|
коэффициент |
1000 |
32 |
Активные объекты |
||
3 000 |
8,0 |
1,0 |
5 000 |
8,0 |
1,0 |
10 000 |
11,0 |
1,0 |
50 000 |
51,0 |
2,0 |
100 000 |
101,0 |
4,0 |
150 000 |
151,0 |
5,0 |
200 000 |
201,0 |
7,0 |
250 000 |
251,0 |
8,0 |
300 000 |
301,0 |
10,0 |
400 000 |
401,0 |
13,0 |
500 000 |
501,0 |
16,0 |
700 000 |
701,0 |
22,0 |
800 000 |
801,0 |
26,0 |
1 000 000 |
1001,0 |
32,0 |
1 500 000 |
1501,0 |
47,0 |
2 000 000 |
2001,0 |
63,0 |