Comments 44
В MD всё логичнее: здесь используется единая база данных. Это упрощает администрирование системы, поскольку отсутствуют проблемы с конфликтующими версиями данных и ошибками, возникающими вследствие некорректной репликации.
Геораспределенную систему или систему работающую под большой нагрузкой в с таким подходом точно не построите, впрочем у вас питон, поэтому тут про нагрузки и говорить не приходится.
Не, ну да, постгрес, конечно, не подвергается нормальному геораспределению, лол.
Дело не только в постгресе - вы же не будете из Москвы делать запросы в Омск или наоборот. Коли приложение рассчитано на работу с реляционной БД, это всегда расчет на то, что база где-то рядом. Репликация данных должна быть на уровне приложения и тогда особого толку от использования РСУБД нет никакого, коли у каждого узла она будет своя.
Геораспределенную систему или систему работающую под большой нагрузкой в с таким подходом точно не построите, впрочем у вас питон, поэтому тут про нагрузки и говорить не приходится.
Геораспределённый кластер на PostgreSQL прекрасно строится с помощью Patroni со схемой master–replica.
Для удалённых филиалов можно использовать реплику в режиме read-only для аутентификации и авторизации, а master — для операций записи. Даже при обрыве связи с master филиал остаётся полностью работоспособен в локальных сценариях.
Что касается нагрузок и Python — здесь важно понимать масштаб.
Даже у крупнейших компаний в России количество активных пользователей не превышает сотен тысяч. Например, если взять инфраструктуру компании с численностью порядка 400 000 пользователей, — такая нагрузка без проблем обслуживается Python-сервисами при правильной архитектуре.
Python давно используется в высоконагруженных системах — от брокеров сообщений до крупных web-сервисов. Его легко масштабировать горизонтально: микросервисная архитектура, асинхронные фреймворки, балансировка через Nginx/Traefik, worker-пулы для фоновых задач и т.п.
Ну то есть получается что все это переложили на плечи СУБД, как вариант наверно можно, но сопровождение такой системы так себе занятие, особенно когда начинаются проблемы, и уж они точно не будут проще, чем вариант с честным AD
Геораспределённый кластер на PostgreSQL прекрасно строится с помощью Patroni со схемой master–replica.
А AD - мультимастер. И это не просто так.
Для удалённых филиалов можно использовать реплику в режиме read-only для аутентификации и авторизации, а master — для операций записи.
То есть вы предлагаете реализовать крайне специфичный и редко используемый в реальности сценарий RODC, но игнорируете наиболее распространенный. Так себе замена.
Геораспределённый кластер на PostgreSQL прекрасно строится с помощью Patroni со схемой master–replica.
Для удалённых филиалов можно использовать реплику в режиме read-only для аутентификации и авторизации, а master — для операций записи.
Но ведь при master-replica точка записи у вас только одна, а в остальных "местах" только чтение, и я не очень понимаю, как это решает проблему геораспределённости ваших пользователей. Изменения всё равно нужно сначала доставить на мастер, а потом докатить до ближайшей реплики. Те. какое-либо обновление будет довольно продолжительным. Вы исходите из предположения, что активная запись в БД происходит значительно реже чем массовое чтение?
Вообще, конечно, назвать решение multimaster, но использовать master-replica БД мне кажется хитрым маркетинговым ходом.
Правильно написали, географически распределенность и устойчивость к разделению. Условно, если у вас разоралась связь между филиалами, то контроллер в Новоосибе не сможет обслуживать пользователей, если его БД в Москве.
Да и гонять запросы между кд в Новосибе и бд в Москве через узкий канал между филиалами - такая себе идея, это очень большие потери пакетов = ошибки в бд и низкая производительность. Хотя у postgresql, в принципе, низкая производительность в задачах ldap (низкая частота записи, высокая чтения, и поиска)
В MD всё логичнее: здесь используется единая база данных.
Из разряда "как попытаться выдать недостаток за достоинство". Искренне надеюсь, что ваши специалисты на самом деле не думают, что мультимастер структура AD - это потому, что ребята не знали, как "логично" сделать.
Там я выше написал, что можно сделать единую геораспределённую базу, да, это пипец непривычно, но по сути классное решение, ведь вы разделяете зону хранения и зону обработки данных на разные инстансы, а не так, как сделано в АД: один инстанс - одно хранилище, которое еще надо научить нормально синхронизироваться
Из разряда "как попытаться выдать недостаток за достоинство". Искренне надеюсь, что ваши специалисты на самом деле не думают, что мультимастер структура AD - это потому, что ребята не знали, как "логично" сделать.
Multimaster‑структура AD — это историческая особенность архитектуры. Она была разработана в 2000 году под специфические задачи: работу с непостоянными каналами связи (спутниковые линии, филиалы с ограниченной связью) с так называемыми окнами доступности.
Отсюда и функционал репликации по расписанию в течение суток, который кажется избыточным в современных реалиях.
В современном мире, при стабильных постоянных каналах связи, схема master → multireplica полностью покрывает все сценарии: аутентификация, авторизация. Никакой особой логики здесь нет — просто исторический дизайн учитывал условия и ограничения того времени.
В современном мире, при стабильных постоянных каналах связи
вот это фундаментальное заблуждение - каналы связи между регионами были и есть ненадежны по определению, и далеко не всегда они быстрые
В современном мире, при стабильных постоянных каналах связи
Мы тут как раз недавно с коллегами обсуждали, как бы нам реализовать работу офиса клиента в одной маленькой северной деревеньке, куда проводной интернет всё проводят и проводят уже несколько лет в режиме "через четыре года здесь будет город-сад". Причем как раз с AD-то как раз проблем ровно ноль из-за "исторических особенностей архитектуры", а вот со всем остальным... Так что спасибо, что просветили насчет "современного мира".
А скажите - много ли изменений вносится в AD в таком офисе ? Ну кроме служебных атрибутов whenchanged, lastlogon и прочее.
"Много" - это оценочное понятие, каждый под ним что-то свое может понимать. Обычно в таких случаях в первую очередь играют не количественные характеристики, а качественные (сама возможность беспроблемной работы повседневных процессов без стабильной скоростной связи с "большой землёй").
Вот вопрос что называть "беспроблемной работой". В отсутствие связи с "большой землей" большинство ИС предприятия недоступны, остаются только локальные, это рабочие станции, файловый сервер и печать как правило. Аутентификацию и выдачу авторизационной информации может осуществлять RO реплика. Массированные внесения изменений это удел ИС предприятия, которые уже тяготеют к централизации.
Массированные внесения изменений
Вы снова оперируете какими-то непонятными терминами. Логон полусотни человек с соответствующим изменением атрибутов - это "массовое" изменение? А заведение пользователя/изменение информации о нем? А десятков-сотен (приехавшая вахта)?
В отсутствие связи с "большой землей" большинство ИС предприятия недоступны
Это, разумеется, не так. К счастью, обычно разработчики корпоративных систем не столь недальновидны, что в принципе не учитывают подобные сценарии. Хотя так просто, как с AD, вопрос обычно не решается, но все-таки способы решения есть.
В AD lastlogon и whenchanged это нереплицируемые атрибуты как раз для того, чтобы логон пользователей не вызывал репликации. С заведением пользователей уже сложнее, но я давно уже не видел чтобы пользователей заводили руками на местах, это централизовано IDM делает как правило.
lastlogon и whenchanged это нереплицируемые атрибуты
И поэтому их вообще не надо записывать, или в чем ваша мысль заключается?
В том, что репликация порождается управлением пользователями, а не их логоном.
Ну и что? В первую-то очередь речь идет о возможности записи на локальный КД, а необходимость репликации (полной или частичной) - всего лишь следствие возможности записи. Изменения (любые!) есть? Да. Писать их надо? Да. А куда, если у локального КД база ридонли?
Ключевой вопрос - а что нужно записывать в филиалах ?
Да вот всё вышеперечисленное и нужно. Нет, можно пойти и другим путем. Не писать в каталог информацию о входах вообще, запретить изменения пароля, любые изменения пользователей и групп без связи с центром. Но это, повторяюсь, недостатки, а не преимущества продукта. Отсутствие возможности, а не наличие.
Ну я еще раз скажу - информация о логонах записывается в нереплицируемую область, которая на каждой реплике индивидуальна. Управление же пользователями, включая сброс пароля, тяготеет к централизации из-за требований безопасности. Давать филиалам право заводить пользователей нынче так себе затея из-за сложности контроля.
Интересно, а какие санкционные риски у .net и Go по сравнению с Python?
Кстати, хороший вопрос. Формально .net - под санкциями, но .net core - нет ) Так что, чую, это чисто дело времени, когда его подбанят. Насчёт Го не в курсе, если честно
Интересно, а какие санкционные риски у .net и Go по сравнению с Python?
Санкционные риски напрямую зависят не только от языка, а от экосистемы и юрисдикции. .NET — продукт Microsoft, целиком под контролем американской корпорации. Даже при наличии .NET Core с открытым исходным кодом, зависимость от инфраструктуры (NuGet, tooling, Visual Studio, лицензии) остаётся высокой.
Go — развивается под управлением Google, что тоже создаёт риски.
Python — полностью открытый, развивается международным сообществом под управлением Python Software Foundation, зарегистрированной как некоммерческая организация. В нём нет корпоративного вендора, способного одномоментно ограничить использование или распространение.
Samba-DC: По умолчанию при инициализации домена используется база данных TDB.
- TDB: Максимальный размер составляет 4 ГБ, поскольку базы данных используют 32-разрядные структуры. Поэтому в крупной организации с 100 тысяч объектов и больше стоит сменить базу данных на LMDB.
- LMDB: Начиная с Samba 4.9, контроллер домена можно настроить для хранения своих данных в формате LMDB вместо формата TDB. Поскольку LMDB является настоящей 64-разрядной базой данных, максимальный размер ограничен только объемом памяти, доступной в системе.
Я видел внедрения до 5000 пользователей и не видел проблем с производительностью.
LMDB действительно снимает ограничение по размеру базы, но не решает главные проблемы Samba — архитектурные.
Проект исторически создавался как реализация протоколов Windows NT в Linux-среде. Со временем в него “дописывали” поддержку AD, Kerberos и LDAP, но эти компоненты остались слабо связанными и разношерстными по архитектуре.
Репликация и обработка политик реализованы в однопоточном режиме, а кэширование и индексация данных крайне ограничены. На десятках тысяч объектов наблюдаются задержки репликации и рост времени отклика LDAP. Это подтверждается тестами крупных организаций и интеграторов.
Samba — проект, глубоко осевший в эпохе Windows NT, чьи корни уходят во времена ранних версий Windows Server.
Samba 4.23 поддерживает SMB по протоколу QUICK. Это показывает, что проект SAMBA развивается и идет в ногу со временем.
Да можно заменить AD , прикольно)
По старой доброй традиции на сайте стоимость продукта спрятана?
Коллеги, всеми руками за ваше начинание и желаю вам только успехов. А теперь немного критики:
1) Можете спросить у коллег из Avanpost, они тоже начинали с бэкенда в виде postgres и перешли в итоге к специализированной БД. Postgres не подходит для задач ldap. Он не способен выполнять чтение и поиск данных с необходимой производительностью, сколько в него не влей ресурсов. Реляционные БД здесь не подходят.
2) Репликация и устойчивость к разделению - это главное требование к домену. Это не кластер. С точки зрения пользователя он не должен получить отказ в обслуживании, если интернет пропал. Поэтому БД должна быть под боком, в той же сети.
3) Python - это хорошо, когда это верхнеуровневое конфигурирование. Когда вы пытаетесь делать низкоуровневые операции на python - вы неизбежно наткнетесь на ограничения производительности. Одна и та же операция на go и на python отличается по времени на порядок.
Кстати, freeipa здесь хороший пример. Она тоже написана на python, но при этом низкоуровневые ldap-операции и работа с БД - это 389ds и c.
4) Структура данных, совместимая с MS AD - это главная ошибка тех, кто начинает писать свой каталог. Тут главный вопрос в том, а для чего вы пишите каталог?
Если для Linux, то почему берете структуру данных, не учитывающую posix и особенности Linux?
Если для Windows, то зачем вы ее пишите, если там есть MS AD?
Коллеги из Avanpost пошли тем же путем, а теперь у них всплывают последствия подобных решений. Например, их структура данных не учитывает модель доступа UGO (стандартную для posix). Все пользователи домена у них не имеют приватных групп, но имеют primary group (Domain Users) по аналогии с MS AD. Таким образом, после логина на рабочие станции все пользователи становятся членами одной приватный группы Domain Users и получают доступ ко всем конфиденциальным данным друг-друга
Python - это хорошо, когда это верхнеуровневое конфигурирование
У нас есть отечественные вендоры, где средства виртуализации и контейнеризации на Python написаны
Запустить виртуальную машину в kvm или дать команду ядру на создание неймспейса - это и есть "высокоуровневое конфигурировпние".
Лопатить тысячи запросов в секунду с преобразованием их в запросы к бд и отдавать их за адекватное время - тут уже есть инструменты получше питона.
Одна сессия общения по ldap - это около 10 последовательных ldap-запрсов. И критически важно, выполняется один запрос за 10 мс или за 100. Потому, что в одном случае это 100 мс на ответ (считай мгновенно), а в другом 1 с (это уже ощутимые задержки).
Я не говорю уже про фоновые задания в БД. Обеспечение связности ldap-записей, например, по атрибуту member, здесь python прямо сильно хуже себя показывает по сравнению с плагинами непосредственно к БД.
Коллеги из Avanpost пошли тем же путем, а теперь у них всплывают последствия подобных решений. Например, их структура данных не учитывает модель доступа UGO (стандартную для posix). Все пользователи домена у них не имеют приватных групп, но имеют primary group (Domain Users) по аналогии с MS AD. Таким образом, после логина на рабочие станции все пользователи становятся членами одной приватный группы Domain Users и получают доступ ко всем конфиденциальным данным друг-друга
Про постгрю выше Вы правильно написали, POC у нас был сделан на ней, однако, мы исходно не планировали на ней оставаться. А вот тут конкурентная разведка не доработала, либо умышленно исказили факт. Мы действительно не «мусорим» в каталоге приватными группами, дублирующими пользователей, но, поскольку, в отличии от остальных, самостоятельно реализовали протоколы LDAP и Kerberos, возвращаем их клиентам в соответствии с ожиданиями.
Универсальность: приложения работают на стандартной операционной системе Linux Debian
Уже не Debian. Release/v2.5.2
https://raw.githubusercontent.com/MultiDirectoryLab/MultiDirectory/refs/heads/main/.docker/Dockerfile
"...Выполнен переход на новую базовую ОС в Docker-контейнерах (функция также доступна в Community-версии 2.5.0)
Мы успешно мигрировали нашу инфраструктуру контейнеризации Docker с Debian на Alpine Linux..."
Почитал доки: Установка и настройка MULTIDIRECTORY
Взяли обо….ли С, FreeIPA …, сказали что в 90е это это было чуть ли не единственным вариантом … и с архитектурой типа жопа …. Все не правильно, а у вас все правильно …. Время конечно покажет как и на каким объемах работает Ваше решение с обратной связью от тех кто использует решение с опытом ранее использования AD/FreeIPA - пока же технического сравнения в статье нет, только говорите как хорошо….
А еще с чего вы взяли, что запаковав все в docker - вы упростили жизнь администраторам ? Да вы кучу технологий засунули вместо 1-2х клиенту и ему что бы это обслуживать , нужен не один Ваня, а штуки 3 Вани или 1 Ваня за over для компании.
у читателей Хабра не забалУешь :) взяли и всё опОшлили.
Ребятам из Мультифактор - респект! всё правильно, развивайте своё.
Не слушайте всякие "коллеги из .. . так уже пробовали и им не понравилось", не факт, что первые (чужие) попытки были корректны и использовали все возможные варианты.
Хотя с замечаниями про структуру данных - согласен, особенности Linux надо учитывать, всё таки основная цель - плавно перевести страну на отечественное ПО.
ildarz еще упоминал "крайне специфичный и редко используемый в реальности сценарий RODC, но игнорируете наиболее распространенный. Так себе замена"
- подобные высказывания не истина в последней инстанции, не верьте!
- дерзайте, у вас всё получится!
Почему мы отказались от AD и FreeIPA и создали свою службу каталогов