Comments 8
Такой способ шифрования LDAP-соединений на самом деле устарел, и вместо него рекомендуется использовать шифрование STARTTLS.
STARTTLS — это расширение основного протокола
SSL/TLS — это самостоятельный уровень, его можно терминировать не вникая во внутренности протокола
SSL/TLS можно терминировать на балансировщике и дальше уже распределять трафик на внутренние сервисы, сверяясь с их персональными сертификатами. Так что в современных реалиях скорее устарела экономия на портах, которую решали с помощью STARTTLS.
А какие у основных реализаций характеристики по read/write latency, throughtput? Например, у меня есть более иерархические данные, которые выглядят как вполне подходящие под LDAP. И я выбираю, класть их в обычную реляционную БД, или в LDAP. Если для РСУБД есть много бенчмарков и понимания как оно "взлетит", то с LDAP это неочевидно. Например, как атрибуты и объекты хранятся на диске, чтобы можно было оценить, насколько быстрыми будут операции с ними?
Если брать openldap, то используется формат bdb или же lmdb в новых версиях. Ванильный openldap для хайлоад плохо подходит, из форков я знаю только ReOpenLDAP, но он не получил широкой известности.
При этом данный форк проверен телекомом (одним из большой тройки), и покрыт тестами, в т.ч. производительности.
Правильнее было бы сказать — этот форк и пилился Мегафоном под свои нужды, поскольку при их числе запросов в секунду и при их необходимости в master-master репликации они ловили массу граблей в OpenLDAP. Поправили, довели до ума, много что вылизали, и — последние года 2 проект не развивается (вот репа).
(вот)
Проект был инициирован в 2014 году для решения проблем, возникших при эксплуатации исходного OpenLDAP в инфраструктуре одного из крупнейших Российских операторов мобильной связи.
За два года проект выведен «на орбиту» высоконагруженной промышленной эксплуатации. Сейчас ReOpenLDAP успешно работает во всех филиалах ПАО МегаФон по всей России и одновременно доступен как OpenSource.
(вот)
Оригинальная репа здесь. Только мне не очень понятно, что означает в комментарии выше «развитие»: если сервер в полной мере и без ошибок реализует спецификацию, то куда и зачем его «развивать»?
Оригинальная репа была там, но с некоторых пор переехала на указанный выше сервер. Причина на «бывшей оригинальной» репе указана в конце страницы, посмотрите.
Что касается «работает — не трогай», то, вероятно, вы правы в разрезе фич. Но даже в самом идеальной коде нет-нет, да найдутся неидальные решения, отчего код все равно правят, и выпускают обновления. Cамые главные из них, даже при «работает — не трогай» подходе — патчи, закрывающие возможные бреши в безопасности. Для Мегафона это, понимаю, не критично, их LDAP явно работает в непубличном сегменте их же собственной сети, так что могли и закрыть вопрос с полировкой и допиливанием, но актуален ли такой подход ли это для других компаний и вариантов внедрения — нужно смотреть в каждом конкретном случае.
Что касается «работает — не трогай», то, вероятно, вы правы в разрезе фич. Но даже в самом идеальной коде нет-нет, да найдутся неидальные решения, отчего код все равно правят, и выпускают обновления. Cамые главные из них, даже при «работает — не трогай» подходе — патчи, закрывающие возможные бреши в безопасности. Для Мегафона это, понимаю, не критично, их LDAP явно работает в непубличном сегменте их же собственной сети, так что могли и закрыть вопрос с полировкой и допиливанием, но актуален ли такой подход ли это для других компаний и вариантов внедрения — нужно смотреть в каждом конкретном случае.
О причинах я в курсе (у меня же форк есть, посмотрите).
Об единственном оставшемся из более чем пяти тысячах баге Юрий где-то писал — точно не помню, где, но речь шла о сбое репликации при каком-то дико редком сочетании условий, и то — единственный результат той ошибки был сбой конкретной операции репликации, при этом она штатно перезапускалась без сучка и задоринки, а база оставалась в порядке. Собственно, потребные усилия на ликвидацию этого бага реально превышают отдачу — именно поэтому он был оставлен «как есть».
Лично у меня опыт продакшна этого форка с репликацией примерно полтора года. Так вот, по стабильности могу сравнить, пожалуй, только с Nginx.
Об единственном оставшемся из более чем пяти тысячах баге Юрий где-то писал — точно не помню, где, но речь шла о сбое репликации при каком-то дико редком сочетании условий, и то — единственный результат той ошибки был сбой конкретной операции репликации, при этом она штатно перезапускалась без сучка и задоринки, а база оставалась в порядке. Собственно, потребные усилия на ликвидацию этого бага реально превышают отдачу — именно поэтому он был оставлен «как есть».
Лично у меня опыт продакшна этого форка с репликацией примерно полтора года. Так вот, по стабильности могу сравнить, пожалуй, только с Nginx.
Sign up to leave a comment.
Понимание LDAP-протокола, иерархии данных и компонентов записей