Подоспела новость: MONT и Avanpost договорились о партнёрстве.
На первый взгляд - обычная дистрибьюторская новость. Но для компаний, которые работают с MONT и рассматривают миграцию с Microsoft AD на Linux-каталог, появляется интересный вариант службы каталога — Avanpost DS. Сейчас многие возразят: на рынке же полно российских решений-аналогов MS Active Directory — ALD Pro, РЕД АДМ, Роса Dynamic Directory, Альт Домен и другие. Зачем нам ещё один? Копнём поглубже, чтобы понять, а действительно нужен ли нам этот "ещё один".
Российские Linux-каталоги собраны по-разному: одни вокруг FreeIPA, другие на Samba DC. Вместе с каталогом заказчик выбирает его архитектуру, зависимости и инструменты администрирования. Поэтому два продукта с одной задачей в эксплуатации ведут себя по-разному.
Avanpost пошёл другим путём
Ядро Avanpost DS — LDAP-сервер и Kerberos — написано на Go с нуля, без использования open-source-компонентов. По заявлению вендора, их служба каталога протестирована под нагрузкой до 30 млн объектов.
Что это даёт?
Типичный Linux-каталог собран из нескольких компонентов. Каждый зрелый и проверенный, но со своей архитектурой и зависимостями. Вендору приходится развивать свой продукт и одновременно считаться с чужим кодом.
Своя собственная разработка даёт больше контроля над ключевыми компонентами. Их можно менять, искать узкие места и оптимизировать под нагрузку, а не подстраиваться под архитектурные решения, которые принимали без тебя. Avanpost среди плюсов своего подхода называет производительность и масштабируемость.
Но производительность важна не только в штатном режиме
Проблема начинается, когда нужно быстро исправить ошибку в каталоге. Неудачный скрипт, сбой интеграции или массовое изменение могут затронуть множество объектов. Контроллеры при этом доступны, пользователи аутентифицируются, мониторинг зелёный – но у части сотрудников уже изменены атрибуты, членство в группах или права доступа. Формально всё работает, а данные внутри — уже нет.
Мало обслуживать миллионы объектов в штатном режиме. Нужно ещё быстро понять, что именно сломалось, и исправить это, не откатывая миллионы корректных данных вместе с ошибочными.
При больших объёмах узким местом может стать уже сам каталог. В компании, где я работаю (другой ИТ-вендор), был похожий опыт при нагрузочном тестировании одного из Linux-каталогов, построенных на open-source-компонентах: массовые операции на сотнях тысяч объектов выполнялись критически медленно, а удаление нескольких тысяч учётных записей заняло несколько дней. Во время нагрузки возникали ошибки, а репликация между контроллерами некоторое время не восстанавливалась.
Поэтому производительность каталога при больших объёмах – это не вопрос комфорта администратора. От неё напрямую зависит, сколько времени займёт исправление массовой ошибки.
И здесь у Avanpost есть ещё одна полезная связка
С августа Avanpost DS Pro совместим с Granulex Recovery. Granulex сравнивает текущее состояние каталога с резервной копией, показывает, что изменилось не туда, и позволяет выборочно вернуть нужные объекты и атрибуты — без полного отката каталога.
Так что при выборе замены Microsoft AD важен не только список функций. Сколько объектов реально выдерживает каталог? Как ведёт себя под нагрузкой? И насколько быстро можно найти и исправить ошибку, если она затронула тысячу объектов из миллиона?
Когда от каталога зависят доступы всей компании, это уже не мелочи.