Вопрос в заголовке, конечно же, риторический. 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 хотя бы? ;-)
20.10.2008
11.10.2008
Почему биржи используют линукс?
Недавно Чикагская товарная биржа (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: продолжение истории лондонской биржи.
Если кто-то не в курсе, вот краткое содержание предыдущих серий:
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: продолжение истории лондонской биржи.
08.10.2008
Fedora в России
Сегодня появился достойный повод для оживления блога. На СПО-Саммите (www.ross-ru.ru) объявлено о программе Russian Fedora. Итак, официальный пресс-релиз и человеческие комментарии к нему.
VDEL и ВНИИНС им. В.В. Соломатина объявляют о начале совместно с Red Hat программы Russian Fedora, направленной на поддержку СПО-сообщества.
Пресс-релиз
VDEL и ВНИИНС им. В.В. Соломатина объявляют о начале совместно с Red Hat программы Russian Fedora, направленной на поддержку СПО-сообщества.
Цели программы Russian Fedora:
Объединить российских разработчиков и пользователей СПО, сформировать «центр притяжения» для новых пользователей СПО.
Сделать Fedora дистрибутивом, подходящим для российских пользователей «из коробки».
Помочь российским разработчикам более активно влиять на мировую разработку СПО.
Формировать имидж российского сообщества разработки СПО как одного из ведущих в мире.
Red Hat в рамках проекта Russian Fedora предоставит необходимую базу, передаст свои технологии и наработки по организации разработки СПО и интеграции разработки в мировое сообщество. Также Red Hat обеспечит взаимодействие российских разработчиков со своими центрами разработки.
VDEL будет отвечать за взаимодействие с российским сообществом и за организацию проекта.
На базе ВНИИНС им. Соломатина будет создан центр разработки, которых станет технологическим ядром проекта.
Так как программа Russian Fedora является не столько техническим, сколько организационным проектом, то говорить о полномасштабном ее запуске можно будет только после возникновения обратной связи от российского сообщества пользователей и разработчиков СПО. В связи с этим официальный запуск программы намечен на начало декабря 2008 года.
А теперь о том же, но простыми словами
Есть:- Желание и политическая воля VDEL, ВНИИНС, Red Hat вложиться в развитие и популяризацию СПО в России
- Договоренность выделить на это ресурсы
- Понимание того, что такие задачи нельзя решать методами "сверху". Большие компании могут поддержать процесс и стать "точкой кристаллизации", но основная роль принадлежит сообществу.
- Сделать популярнее идею СПО как таковую. Да, это маркетинг пополам с просветительской деятельностью. Ориентированы они в первую очередь на тех, кто в свете всех последних событий и заявлений "сверху" о свободном ПО начал смотреть и пробовать понять для себя, что же такое на самом деле СПО и Linux.
- Сделать Linux проще для пользователей. Чтобы человеку, которые впервые взял в руки диск с Linux, не требовались советы ближайшего гуру при первых же шагах в новой системе. Да, такая цель декларируется далеко не впервые. Да, очень многое уже сделано. Но на сегодняшний день задача еще не решена. Значит надо по возможности вносить свой вклад в нее.
- Помочь российскому сообществу влиять на апстрим, используя каналы Fedora / Red Hat. И речь здесь в первую очередь даже не о разработчиках, хотя в официальном пресс-релизе акцент сделан именно на них. Речь о сообществе в целом, о всех тех, кто использует СПО в России. Цель - постараться направить развитие апстрима с учетом их интересов. Простой пример - чтобы не приходилось раз за разом делать одни и те же кастомизации в каждом новом пришедшем из апстрима релизе.
- Делать форк или еще одну кастомную сборку на основе Fedora. Это напрасное растрачивание сил и ресурсов. Наша цель - взаимодействие и интеграция с апстримом.
- Пытаться направить сообщество. Мы просто хотим попытаться помочь тем, кому близки наши идеи, в их продвижении.
Конкретные шаги и действия:
Главное, что нам нужно сейчас, - получить обратную связь от сообщества. Чтобы скорректировать наши действия, направления работы и точки приложения силы. Чтобы понять, какая помощь с нашей стороны будет востребована сообществом, а что совершенно не интересно. Чтобы, в конечном итоге, инициатива не осталась просто заявлениями на бумаге, а действительно немного изменила мир в лучшую сторону.
Черновик программы действий будет опубликован в ближайшее время, как только мы осмыслим первые комментарии, полученные в разговорах на СПО-Саммите и в сети.
18.02.2008
Управление разделами при использовании Xen.
Виртуализация с помощью Xen - крайне удобный способ консолидации серверов и упрощения управления ими. Тем не менее, для оптимального (или близкого к оптимальному) управления виртуальными системами необходимо грамотно подходить к архитектуре решения. Рассмотрим управление дисками и разделами для виртуальных серверов.
На первый взгляд, существует по крайней мере четыре способа управления храением данных.
Хотя этот способ многим покажется оптимальным, в реальной жизни не все получается гладко. Недостаток номер один - во многих существующих системах просто невозможно выделить отдельный массив (скажем Raid1) под каждую виртуальную машину. Причем невозможно просто физически, например в 2U корпус просто зачастую не влезает более 6 HDD. В этом случае количество виртуальных систем было бы ограничено тремя.
При проведении резервного копирования виртуальных систем мы можем получить доступ к LVM гостевой системы, причем этот доступ мы будем получать каждый раз при загрузке Dom0. При резервном копировании нам придется использовать эксключивную блокировку snapshot логического тома.
Расширение дискового пространства виртуальных машин, по описанным выше причинам, не позволит вам сохранить парадигму уравления хранением данных. Потребности виртуальных систем в дисковом пространстве могут сильно отличаться, в то время как объемы и количество дисков остаются неизменными.
Перемещение работающей виртуальной машины между дисками - операция достаточно рутинная, заключающаяся в подсоединении нового жесткого диска коммандой
После чего перемещением Расширением LVM и переносом physical extents на новый физический том.
За чем следут отсоединение старого блочного устройства из Dom0.
Этот способ по сути повторяет предыдущий. Исключение:
В этом сценарии при установке DomU создается LVM. Несколько LV из этого LVM экспортируются в DomU. DomU размечает предоставленные ему устройства и создает на них свой LVM. Для того, чтобы их различать, далее будет обозначать LVM0 - LVM в Dom0, а LVMU - LVM в DomU.
В случае увеличения объема дискового простанства, мы не можем просто увеличить объем логического тома в LVM0. В DomU не будет сгенерировано событие Hotplug, и DomU будет по прежнему использовать старую геометрию виртуального диска. Вместо этого мы выделим еще один логический том в Domo, экспортируем его в DomU и "растянем" LVMU.
Создадим на диске единственную партицию (можно обойтись и без этого) и "растянем" vg00, логический том и фаловую систему. Напомним, что уже довольно давно ext3 поддерживает online-resize.
Для резервного копирования виртуальных машин можно сделать snapshot логических томов LVM0, на которых распогалаются данные domu. После чего можно получить средствами device-mapper доступ к вложенным партициям, собрать из них в Dom0 копию LVM гостевой машины и получить доступ к "снимку" данных виртуальной системы без боязни его повредить.
Делается следующим образом.
При этом мы получаем моментальный снимок даных, формируем из него копию LVMU, делаем с ней что хотим, после чего уничтожаем snapshot.
Осуществление перемещения между дисками осуществляется аналогично расширению пространства, за исключением того, что мы отключаем старый LV от DomU. При этом мы можем уничтожить LV в LVM0, не чтрадая при этом от фрагментирования.
Количество логических томов, которые мы можем выделить виртуальным машинам ограничено только здравым смыслом. =)
Все операции здесь абсолютно аналогичны операциям с партициями кроме того, что мы экспортируем не блочное устройство через петлевой драйвер, а файл в режиме эмуляции блочного устройства.
В любом случае найдется достаточно людей с разнями воззрениями, чтобы реализовать все описанные методы. Тем не менее, о результатам лично я буду польоваться способом №3, когда содается "двухслойный" LVM.
Варианты использования
На первый взгляд, существует по крайней мере четыре способа управления храением данных.
- Выделение отдельного диска или массива под каждую виртуальную машину.
- Выделение одной или нескольких партиций диска под виртуальную машину.
- Выделение одного или нескольких логических томов (LVM) под каждую виртуальную машину.
- Хранение фалов-образов виртуальных машин на файловой системе Dom0.
- Увеличение количества виртуальных машин.
- Резервное копирование виртуальных машин.
- Расширение дискового пространства виртуальных машин.
- Перемещение работающей виртуальной машины между дисками.
Отдельный диск под каждую виртуальную машину
Хотя этот способ многим покажется оптимальным, в реальной жизни не все получается гладко. Недостаток номер один - во многих существующих системах просто невозможно выделить отдельный массив (скажем 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
Этот способ по сути повторяет предыдущий. Исключение:
- Партиций можно завести гораздо больше, чем физических дисков.
- После нескольких переразметок дискового пространства может случиться так, что партиции будут фрагментированы по диску, так что вы не всегда сможете создать партицию необходимого размера.
- 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.
05.02.2008
Производительность открытых 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 чтений по атрибуту, индекс по которому не построен. В нашем случае мы использовали атрибут homeDirectory. Предвидя скептические возгласы, скажу, что подобные вещи (поиск по атрибуту без индекса) не должны встречаться в хорошо спланированном LDAP-дереве. Тем не менее результаты вполне имеют право на жизнь, а также наглядно иллюстрируют пользу индексов.
Ну и наконец, тест времени заполнения базы. Это есть непосредственно время выполнения ldapadd для файла, содержавшего нашу базу переменного размера. Если помните, LDAP не гарантирует транзакционности, а также неэффективен при операциях на запись. Некоторые люди поэтому предпочитают иметь DBMS (например PostgreSQL) для хранения данных, а LDAP используют для создания копии, которая работает только на чтение.
Ну и наконец мы провели еще один тест. Дождавшись таки пока 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, а именно
Методика тестирования
Мы сосредоточились на задачах, которые занимают 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
Подписаться на:
Сообщения (Atom)
