Red Hat, Novell и патенты на ПО.

В сентябрьском номере LinuxFormat (LXF 109) меня, мягко говоря, удивила заметка некой Сьюзен Линтон. Эта дама (в разделе "Distrowatch", колонка "Сделайте одолжение") пишет о том, что патентное соглашение Red Hat c Firestar и DataTern очень сильно похоже на сделку Novell и Microsoft. Подробностей урегулирования конфликта Red Hat с Firestar и DataTern не так уж много, но давайте попробуем разобраться в том, что известно. Далее несколько цитат из вышеупомянутой заметки и мои комментарии к ним.

Сьюзен пишет:

"Часть соглашения, касающаяся сообщества - то место, где Red Hat берет под крыло своих ведущих разработчиков и пользователей. О защите других дистрибутивов, их разработчиков или пользователей речи нет."

Стоп. А что, Red Hat должна защищать другие коммерческие компании? Которые, строго говоря, конкуренты к тому же. Непонятно что-то, на каком основании именно Red Hat должна отдуваться за всех? А о защите своих клиентов Red Hat заявила ещё два года назад, почему именно сейчас это так встревожило госпожу Линтон? Защита своих разработчиков и пользователей - это вполне нормальные и даже необходимые действия для любой компании. Кстати, вот Canonical тоже предлагает защиту своим пользователям. Интересно, почему Сьюзен Линтон не возмущается действиями Canonical?

"Очевидно, что RedHat и Fedora содержат множество ведущих проектов, но каковы шансы что они нарушают законодательство?"

Софтверные патенты? Я думаю, что ответ очевиден. Сегодня даже самый небольшой программный продукт нарушает десятки, а то и сотни чужих патентов. Да, это угроза свободному ПО. Да, с этим нужно что-то делать. И да, RedHat насколько может, пытается изменить эту ситуацию. Как? В первую очередь, участием в Open Invention Network (OIN) и помощью OSDL в создании каталога патентов для Open Source. Но это не главное. Главное это то, что Red Hat и проект ESP (End Software Patents) фонда Free Software Foundation участвуют в судебной борьбе против патентования алгоритмов. Да-да, я имею ввиду то самое дело Бильски, которое журналисты уже назвали "сокрушительным ударом по софтверным патентам".

"Что купила Red Hat и чем поступилась DataTern?"

- спрашивает Сьюзен. Давайте подумаем. С DataTern просто - компания поступилась возможностью погрязнуть в судебных разбирательствах и нажить себе огромное количество врагов в IT-сообществе. Вспомните SCO, и вы поймете о чем я говорю. ;-) А вот с Red Hat интереснее. Red Hat купила время. Время, необходимое для реформирования патентной системы (см выше "дело Бильски"). Red Hat купила спокойствие и уверенность в правильном выборе для своих клиентов. Red Hat купила пример для сообщества, что безусловно есть возможность следовать букве и духу GPL-лицензирования в ходе разрешения патентных тяжб.

"Да и не совершила ли Red Hat тот же смертный грех, в котором два года назад обвинялась Novell?"

Нет, не совершила. Сделка RH не противоречит GPL3 и вообще духу свободного ПО. Мне кажется очень важным умение найти компромисс между интересами сообщества и финансовыми интересами своих акционеров. Напомню, что именно несоответствие сделки Novell-MS принципам Open Source вызвало бурю негодования в сообществе и даже побудило внести определённые правки в GPL3. Red Hat же "освободила" необходимые патенты на условиях, наиболее благоприятных для разработчиков свободного ПО и это, на мой взгляд, самое важное.

"Если Red Hat отвергла любые обвинения, но обошлась без суда, следует ли думать, что они виновны? ... Из-за этой кулуарной сделки о виновности задумается любой, как в случае с Novell, узаконевшей претензии Microsoft."

Ну виновность, по-моему устанавливает суд. А раз не было суда, значит нет и вины. Все логично. Novell узаконила претензии, подписав договор с MS, т.е. она фактически признались в "использовании интеллектуальной собственности MS". А Red Hat не признала нарушение патентов, по крайней мере ни о каких документах, хотябы намекающих на нарушение патентов, не известно. В этом ключевое отличие.

"Радуйся, коли охота, дорогое сообщество, но я разочарована. Выигрыш в суде был бы победой всего Открытого Кода, а не только кода Red Hat"

И проигрыш тоже, был бы не только для Red Hat. Я понимаю, что очень многие, в числе которых, видимо и Линтон, "жаждут крови" и хотят преподать урок "патентным троллям". Но во-первых, Red Hat хочет тратить деньги на разработку свободного ПО, а не на адвокатов. А во-вторых воевать на чужой территории было бы сейчас глупо. Не нужно забывать, что создатели коммерческого ПО уже не раз становились жертвами в судебных делах по нарушению патентного законодательства. Где гарантия того, что разработчикам свободного ПО удастся избежать похожего развития событий?

В последнее время есть ряд положительных сдвигов в области законов о патентовании ПО, в частности недавнее Изменение трактовки патентного законодательства США ставит вопрос о правомерности патентов на ПО. Да и в Европе к этому вопросу стали подходить намного оcмотрительнее. Так давайте же будем судиться, когда станем уверены в победе - а сейчас нужно сделать все, чтобы изменить законы. Бороться нужно с причиной, а не со следствием.

О чем вообще я тут писал? Да просто о том, что у Red Hat и Novell есть отличия во взглядах на патентование ПО, а вот какой из этих взглядов принесет больше пользы - пускай решает сообщество. Но, нужно признаться, что в конечном счете и Novell и Red Hat способствуют распространению свободного ПО, а значит все мы останемся в выигрыше.

ps: О сделке Novell-Microsoft и её последствиях мы уже писали тут и тут.

Готов ли linux для HPC?

Вопрос в заголовке, конечно же, риторический. Linux для HPC (High Performance Computing) готов однозначно, стопроцентно и уже давно. Если вы посмотрите на TOP500 (проект по составлению рейтинга и описаний 500 самых мощных общественно известных компьютерных систем мира) то заметите, что linux там уверенно и заслуженно занимает лидирующие позиции.

Но ... подождите ка, если нишу HPC практически безоговорочно занимает линукс .... где компании, которое это обеспечивают? Где многочисленные предложения местных поставщиков и производителей софта? Почему очередной дистрибутив linux появляется для десктопов, где доля линукса 1-2%, а не для кластеров,, на 98% которых устанавливают Linux и Unix? Я знаю, что вы ответите: "Это слишком узкая и слишком специализированная область, там не заработаешь денег!"

И у меня уже готовы возражения. Рынок HPC действительно значительно меньше, чем, к примеру, рынок десктопов. И заработать там намного труднее. Но разве кто-то обещал, что будет легко? Бизнес на свободном ПО - это бизнес на сервисе, ну так и предложите то, что будет востребовано. Да, это сложнее, чем просто штамповать коробки. И я не уверен, что на HPC можно заработать миллионы, но всетаки заработать "на хлеб с маслом" можно и, что на мой взгляд намного ценнее, сделать себе имя! Кстати, в последнее время Microsoft все чаще поглядывает в сторону высокопроизводительных вычислений - а это верный признак того, что там запахло деньгами. ;-)

Вы скажете: "Хе, да кластера делают IBM, SGI, HP! Куда нам до них?!". И будете правы. Но есть нюансы. IBM, SGI и HP делают очень большие и очень дорогие кластера, не каждая организация может позволить себе быть клиентом IBM. Вот как раз эта ниша, ниша средних предприятий, ВУЗов и научных центров, практически и не охвачена. Кроме того, в том что крупные компании заинтересованы в HPC есть и положительные стороны - у вас есть возможность "встать на плечи гигантов". Например, недавно IBM представила HPC Open Software Stack - пакет программного обеспечения с открытым исходным кодом для суперкомпьютеров под управлением ОС Linux.

Вот и HPC Solution от Red Hat - готовое решение, предназначенное именно для быстрого развёртывания HPC-систем. Напишу об этом немного подробнее. Чуть меньше месяца назад Red Hat представила то, что она называет первой полностью интегрированной платформой высокопроизводительных вычислений на основе Linux. В Red Hat уверяют, что эту платформу можно развернуть меньше чем за час. Система Red Hat HPC построена на Red Hat Enterprise Linux 5.2 и содержит, кластерную программную среду Platform Open Cluster Stack (OCS) 5 от Platform Computing. Она включает драйверы устройств, инсталлятор, инструменты управления, монитор выделяемых приложениям ресурсов, поддержку интерфейса и планировщик заданий Platform Lava. Ну и остается добавить, что по цене, Red Hat HPC конечно-же выгодней, чем предложения конкурентов.

Итак, рыночная ниша есть. Готовая программная платформа есть. Дешёвые x86 сервера - предложений более чем достаточно. Так когда же ждать Вашу HPC-систему, ну если не в TOP500, то в Российском TOP50 хотя бы? ;-)

Почему биржи используют линукс?

Недавно Чикагская товарная биржа (The Chicago Mercantile Exchange, CME) объявила о присоединении к Linux Foundation. В настоящее время CME Group является крупнейшей в США биржей по торговле валютными фьючерсами и опционами и одной из самых больших организаций, оказывающих финансовые услуги на базе операционной системы Linux. Так вот, что интересно ... в комментариях к этой новости обсуждали не столько CME Group и Linux Fundation, сколько Лондонскую биржу и Get The Facts от Microsoft.

Если кто-то не в курсе, вот краткое содержание предыдущих серий:
1) На сайте Get The Facts публикуют информацию, о том что Лондонская биржа (LSE) выбрала Windows.
2) Во многих бумажных журналах, связанных с IT, печатают про это красивую рекламу на всю страницу.
3) На основных новостных IT-сайтах вешают большой баннер.
4) Появляется новость о том, что на Лондонской фондовой бирже произошёл сбой в компьютерной системе.
Эта новость отлично смотрится на сайтах рядом с баннером "лондонская биржа выбирает windows". Занавес. :-)

На самом деле, радость Microsoft по поводу того, что хотя бы на Лондонской бирже выбрали Windows понять можно. За последнее время, например, Дубайская международная финансовая биржа (DIFX) и Новозеландская фондовая биржа (NZX) перешли на Linux. Но особенно хотелось бы отметить холдинг NYSE Euronext, он объединяет крупные биржевые площадки в США и Евросоюзе, включая Нью-йоркскую фондовую биржу (NYSE), европейскую Euronext, международную биржу финансовых фьючерсов и опционов Liffe и др. Там в качестве базового дистрибутива для серверов, по итогам всестороннего тестирования, включающего тестирование технической поддержки, был выбран Red Hat Enterprise Linux.

Так почему биржи используют Linux? Я думаю, что ответ все мы знаем. Финансовые службы очень требовательны к надёжности и отказоустойчивости используемых ОС, ведь каждая минута простоя в таких компаниях обходится в миллионы долларов.

Кстати, наши чиновники собирались сделать из Москвы крупный финансовый центр, но похоже, что это преждевременно ... представители российских бирж, опрошенные CNews, пока не видят необходимости в миграции на Linux. Видимо, для того, чтобы эту необходимость увидеть им нужно разок-другой "засветиться", аналогично Лондонской бирже, в новостях...

UPD: продолжение истории лондонской биржи.

Fedora в России

Сегодня появился достойный повод для оживления блога. На СПО-Саммите (www.ross-ru.ru) объявлено о программе Russian Fedora. Итак, официальный пресс-релиз и человеческие комментарии к нему.

Пресс-релиз

VDEL и ВНИИНС им. В.В. Соломатина объявляют о начале совместно с Red Hat программы Russian Fedora, направленной на поддержку СПО-сообщества.

Цели программы Russian Fedora:

• Объединить российских разработчиков и пользователей СПО, сформировать «центр притяжения» для новых пользователей СПО.

• Сделать Fedora дистрибутивом, подходящим для российских пользователей «из коробки».

• Помочь российским разработчикам более активно влиять на мировую разработку СПО.

• Формировать имидж российского сообщества разработки СПО как одного из ведущих в мире.

Red Hat в рамках проекта Russian Fedora предоставит необходимую базу, передаст свои технологии и наработки по организации разработки СПО и интеграции разработки в мировое сообщество. Также Red Hat обеспечит взаимодействие российских разработчиков со своими центрами разработки.

VDEL будет отвечать за взаимодействие с российским сообществом и за организацию проекта.

На базе ВНИИНС им. Соломатина будет создан центр разработки, которых станет технологическим ядром проекта.

Так как программа Russian Fedora является не столько техническим, сколько организационным проектом, то говорить о полномасштабном ее запуске можно будет только после возникновения обратной связи от российского сообщества пользователей и разработчиков СПО. В связи с этим официальный запуск программы намечен на начало декабря 2008 года.

А теперь о том же, но простыми словами

Есть:

• Желание и политическая воля VDEL, ВНИИНС, Red Hat вложиться в развитие и популяризацию СПО в России
  
• Договоренность выделить на это ресурсы
  
• Понимание того, что такие задачи нельзя решать методами "сверху". Большие компании могут поддержать процесс и стать "точкой кристаллизации", но основная роль принадлежит сообществу.

Мы (VDEL) хотим:

• Сделать популярнее идею СПО как таковую. Да, это маркетинг пополам с просветительской деятельностью. Ориентированы они в первую очередь на тех, кто в свете всех последних событий и заявлений "сверху" о свободном ПО начал смотреть и пробовать понять для себя, что же такое на самом деле СПО и Linux.
  
• Сделать Linux проще для пользователей. Чтобы человеку, которые впервые взял в руки диск с Linux, не требовались советы ближайшего гуру при первых же шагах в новой системе. Да, такая цель декларируется далеко не впервые. Да, очень многое уже сделано. Но на сегодняшний день задача еще не решена. Значит надо по возможности вносить свой вклад в нее.
• Помочь российскому сообществу влиять на апстрим, используя каналы Fedora / Red Hat. И речь здесь в первую очередь даже не о разработчиках, хотя в официальном пресс-релизе акцент сделан именно на них. Речь о сообществе в целом, о всех тех, кто использует СПО в России. Цель - постараться направить развитие апстрима с учетом их интересов. Простой пример - чтобы не приходилось раз за разом делать одни и те же кастомизации в каждом новом пришедшем из апстрима релизе.
  

Упреждая вопросы и комментарии - мы НЕ собираемся:

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

Конкретные шаги и действия:

Главное, что нам нужно сейчас, - получить обратную связь от сообщества. Чтобы скорректировать наши действия, направления работы и точки приложения силы. Чтобы понять, какая помощь с нашей стороны будет востребована сообществом, а что совершенно не интересно. Чтобы, в конечном итоге, инициатива не осталась просто заявлениями на бумаге, а действительно немного изменила мир в лучшую сторону.

Черновик программы действий будет опубликован в ближайшее время, как только мы осмыслим первые комментарии, полученные в разговорах на СПО-Саммите и в сети.

Управление разделами при использовании Xen.

Виртуализация с помощью Xen - крайне удобный способ консолидации серверов и упрощения управления ими. Тем не менее, для оптимального (или близкого к оптимальному) управления виртуальными системами необходимо грамотно подходить к архитектуре решения. Рассмотрим управление дисками и разделами для виртуальных серверов.

Варианты использования

На первый взгляд, существует по крайней мере четыре способа управления храением данных.

1. Выделение отдельного диска или массива под каждую виртуальную машину.
2. Выделение одной или нескольких партиций диска под виртуальную машину.
3. Выделение одного или нескольких логических томов (LVM) под каждую виртуальную машину.
4. Хранение фалов-образов виртуальных машин на файловой системе Dom0.

При этом, конечно, хочется добиться максимальной гибкости, а также не потерять в производительности. В качестве типовых будем рассматривать три типичные задачи:

1. Увеличение количества виртуальных машин.
   
2. Резервное копирование виртуальных машин.
3. Расширение дискового пространства виртуальных машин.
4. Перемещение работающей виртуальной машины между дисками.

Отдельный диск под каждую виртуальную машину

Хотя этот способ многим покажется оптимальным, в реальной жизни не все получается гладко. Недостаток номер один - во многих существующих системах просто невозможно выделить отдельный массив (скажем Raid1) под каждую виртуальную машину. Причем невозможно просто физически, например в 2U корпус просто зачастую не влезает более 6 HDD. В этом случае количество виртуальных систем было бы ограничено тремя.
При проведении резервного копирования виртуальных систем мы можем получить доступ к LVM гостевой системы, причем этот доступ мы будем получать каждый раз при загрузке Dom0. При резервном копировании нам придется использовать эксключивную блокировку snapshot логического тома.
Расширение дискового пространства виртуальных машин, по описанным выше причинам, не позволит вам сохранить парадигму уравления хранением данных. Потребности виртуальных систем в дисковом пространстве могут сильно отличаться, в то время как объемы и количество дисков остаются неизменными.
Перемещение работающей виртуальной машины между дисками - операция достаточно рутинная, заключающаяся в подсоединении нового жесткого диска коммандой

[root@dom0 ~]# xm block-attach domu phy:/dev/sdXY xvdb w

После чего перемещением Расширением LVM и переносом physical extents на новый физический том.

[root@domu ~]# pvcreate /dev/xvdb
[root@domu ~]# vgextend vg00 /dev/xvdb
[root@domu ~]# pvmove vgo0 /dev/xvda /dev/xvdb
[root@domu ~]# vgreduce vgo0 /dev/xvda

За чем следут отсоединение старого блочного устройства из Dom0.

[root@dom0 ~]# xm block-list domu
xm Vdev  BE handle state evt-ch ring-ref BE-path
51712    0    0     4      8      8     /local/domain/0/backend/tap/5/51712
....
[root@dom0 ~]# xm block-detach domu 51712

Выделение одной или нескольких партиций диска под DomU

Этот способ по сути повторяет предыдущий. Исключение:

1. Партиций можно завести гораздо больше, чем физических дисков.

Из этого напрямую следуют недостатки этого метода:

1. После нескольких переразметок дискового пространства может случиться так, что партиции будут фрагментированы по диску, так что вы не всегда сможете создать партицию необходимого размера.
2. DomU во время установки все равно "захочет" разметить то блочное устройство, которое ему отдадут. Получим "вложенные" таблицы разделов.

Выделение нескольких LV под DomU

В этом сценарии при установке DomU создается LVM. Несколько LV из этого LVM экспортируются в DomU. DomU размечает предоставленные ему устройства и создает на них свой LVM. Для того, чтобы их различать, далее будет обозначать LVM0 - LVM в Dom0, а LVMU - LVM в DomU.
В случае увеличения объема дискового простанства, мы не можем просто увеличить объем логического тома в LVM0. В DomU не будет сгенерировано событие Hotplug, и DomU будет по прежнему использовать старую геометрию виртуального диска. Вместо этого мы выделим еще один логический том в Domo, экспортируем его в DomU и "растянем" LVMU.

[root@dom0 ~]# lvcreate -n domu-newlv -L 10G hostvg
[root@dom0 ~]# xm block-attach domu  phy:/dev/hostvg/domu-newlv xvdb w

Создадим на диске единственную партицию (можно обойтись и без этого) и "растянем" vg00, логический том и фаловую систему. Напомним, что уже довольно давно ext3 поддерживает online-resize.

[root@dom0 ~]# pvcreate /dev/xvdb1
[root@dom0 ~]# vgextend vg00 /dev/xvdb1
[root@dom0 ~]# lvextend -l+100%FREE /dev/vg00/lv
[root@dom0 ~]# resize2fs /dev/vg00/lv

Для резервного копирования виртуальных машин можно сделать snapshot логических томов LVM0, на которых распогалаются данные domu. После чего можно получить средствами device-mapper доступ к вложенным партициям, собрать из них в Dom0 копию LVM гостевой машины и получить доступ к "снимку" данных виртуальной системы без боязни его повредить.
Делается следующим образом.

[root@dom0 ~]# lvcreate -s -n domulv-snapshot -L 5G /dev/hostlv/domulv
[root@dom0 ~]# kpartx /dev/hostlv/domulv-snapshot
[root@dom0 ~]# pvs; vgs; vgchange -ay

При этом мы получаем моментальный снимок даных, формируем из него копию LVMU, делаем с ней что хотим, после чего уничтожаем snapshot.
Осуществление перемещения между дисками осуществляется аналогично расширению пространства, за исключением того, что мы отключаем старый LV от DomU. При этом мы можем уничтожить LV в LVM0, не чтрадая при этом от фрагментирования.
Количество логических томов, которые мы можем выделить виртуальным машинам ограничено только здравым смыслом. =)

Файлы-образы

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

Резюме

В любом случае найдется достаточно людей с разнями воззрениями, чтобы реализовать все описанные методы. Тем не менее, о результатам лично я буду польоваться способом №3, когда содается "двухслойный" LVM.

Производительность открытых LDAP серверов

В январе этого года состоялся релиз Fedora Directory Server 1.1. Буквально на следующий день был выпущен аналогичный поддерживаемый продукт Red Hat Directory Server 8.0. Это, а также реакция на наши завления о том, что Red Hat Directory Server производительнее OpenLDAP сподвигли нас на проведение теста.

Методика тестирования

Мы сосредоточились на задачах, которые занимают 90+% всех операций, выполняемых с LDAP-серверами, а именно - операциях одиночного чтения. Под одиночным чтением подразумевается соединение клиента и сервера, аутентификация клиента на сервере, считывание одной записи о отсоединение.
Для этого были сгенерировано плоское дерево, моделирующее простую структуру с большим количеством "пользователей" Иначе говоря, мы сделали N записей вида

dn: uid=user00000,ou=People,dc=example,dc=com
objectClass: account
objectClass: posixAccount
uid: user00000
cn:User User
loginShell: /bin/bash
uidNumber: 100000
gidNumber: 100000
homeDirectory: /home/user00000
gecos: User Userovich 00000

После этого мы измеряли на одной и той же системе, в которой запущен только LDAP-сервер время выполнения 1000 последовательных единичных чтений. При этом мы использовали чтения по RDN (аналог primary key в DBMS), по атрибуту, по которому построен индекс, а также по атрибуту, по которому индекс не построен. При этом оба сервера были настроены использовать одинаковую структуру индексов и одинаковый backend (LDBM).

Для произведения 1000 случайных чтений мы предварительно генерировали последовательность псевдослучайных чисел в необходимом диапазоне, после чего утилитой time измеряли время произведения 1000 вызовов ldapsearch по заданному файлу с последовательностью.

Поскольку мы меняли сервера на одной системе, а также для увеличения репрезантативности тестов, тесты прогонялись 20 раз подряд на разных последовательностях, после чего усреднялись результаты последних 10. Первые 10 прогонов симулировали "разогрев" сервера после перезапуска.

Результаты тестов приведены ниже.

Результаты тестов

Итак, результаты тестов. для начала 1000 четний по RDN и по индексу. Мы представляем результаты единым графиком и таблицей потому, что они все равно получились очень близкие, что неудивительно. Расхождение между этими двумя тестами не превышает погрешности наших измерений.

1000 чтений по RDN/индексу
## записей	FDS	OpenLDAP
1000	4,39	4,8
5000	4,46	4,85
10000	4,54	4,89
50000	4,65	4,91

Теперб результаты 1000 чтений по атрибуту, индекс по которому не построен. В нашем случае мы использовали атрибут homeDirectory. Предвидя скептические возгласы, скажу, что подобные вещи (поиск по атрибуту без индекса) не должны встречаться в хорошо спланированном LDAP-дереве. Тем не менее результаты вполне имеют право на жизнь, а также наглядно иллюстрируют пользу индексов.

1000 чтений без индекса
## записей	FDS	OpenLDAP
1000	11,82	25,25
5000	92,99	124,63
10000	232	303
50000	340	1047

Ну и наконец, тест времени заполнения базы. Это есть непосредственно время выполнения ldapadd для файла, содержавшего нашу базу переменного размера. Если помните, LDAP не гарантирует транзакционности, а также неэффективен при операциях на запись. Некоторые люди поэтому предпочитают иметь DBMS (например PostgreSQL) для хранения данных, а LDAP используют для создания копии, которая работает только на чтение.

Добавление записей
## записей	FDS	OpenLDAP
1000	2,09	20,96
5000	10,9	216,08
10000	23,56	440
50000	183	1181

Ну и наконец мы провели еще один тест. Дождавшись таки пока OpenLDAP импортирует базу в 100 000 записей, мы провели тест на 1000 произвольных чтений по индексу при 200 параллеьно работающих потоках. Для этого мы запустили 200 потоков предыдущих тестов, измеряя прохождение одного из них. Результаты получились следующие:
Red Hat Directory Server - 772 секунды
OpenLDAP - 996 секунд

Выводы

Выводы из этих тестов достаточно очевидны. На небольших базах (до 50 000 записей) и при небольшом количестве параллельных запросов FDS/RHDS и OpenLDAP ведут себя очень схоже. Разница в производительности не дает о себе знать, если грамотно использовать индексы. Однако, OpenLDAP начинает серьезно отставать от конкурента по времени добавления записей, при неструктурированном поиске, а также при увеличении параллелизма. Именно поэтому мы остановились на 50 000 записей - OpenLDAP о-о-очень долго их импортировал.

В качестве вывода можно сказать следующее - для простых и небольших баз OpenLDAP хорошо справляется со своей работой. Тем не менее, для более масштабных и загруженных LDAP серверов FDS подходит лучше, особенно учитывая его богатый функционал, отсутствующий у OpenLDAP, а именно

• Возможность поддержания нескольких партиций LDAP-каталога на одном сервере
• Мультимастеринг (говорят, в devel ветке openldap он тоже есть, тем не менее мы используем стабильную версию)
• Более гибкие возможности репликации
• Репликацию с AD
  

Вышел Red Hat Directory Server 8.0

Вскоре после приобретения Netscape Directory Server в 2005 году Red Hat открыл весь его исходный код, который было возможно открыть, не нарушив лицензий, и выпустил его под маркой Red Hat Directory Server. Одновременно с этим под эгидой Red Hat стартовал проект Fedora Directory Server, направленный на то, чтобы переписать все компоненты, который нельзя было открыть, и таким образом создать полностью открытый Directory Server корпоративного уровня. Также Fedora Directory Server стал основой проекта freeIPA (www.freeipa.org), цель которого — создать решение для централизованного управления информацией о пользователях, политиками и аудитом.

На настоящий момент проект Fedora Directory Server достиг своей первоначальной цели — весь код, который было невозможно открыть, заменен. Вышедший сегодня Red Hat Directory Server 8.0 собран полностью из открытых исходных текстов. В RHDS 8.0 вошли все улучшения, разработанные в рамках проекта Fedora Directory Server.

Многие организации на сегодняшний день используют Red Hat Directory Server как ключевой компонент инфраструктуры для управления аутентификацией и авторизацией. Примеры внедрений можно найти на http://customers.press.redhat.com/category/solutions/red-hat-directory-server/. Одним из них является университет Базеля, которому было необходимо создать надежное решение для более чем 15000 студентов и сотрудников университета.

Red Hat Directory Server 8.0 предоставляет ряд новых возможностей, в том числе:

• Поддержка платформ: Red Hat Enterprise Linux 4 и 5 (32-bit и 64-bit), HP-UX 11i (Itanium, 64-bit) и Solaris 9 SPARC 64 bit.

• Безопасность: улучшенные политики паролей, наличие профиля SELinux по умолчанию, поддержка SHA-256, SHA-384, SHA-512 и MD5 для хеширования паролей, улучшение поддержки SASL/Kerberos.

• Поддержка протоколов: возможность подключений IPv6-клиентов и поддержка IPv6 в SDK. На данный момент не поддерживается IPv6 в ACL и IPv6-соединения для таких операций как репликация и делегирование.

Работа над проектом продолжается, так что оставайтесь на связи!