LINUX.ORG.RU

Сообщения ly

 

ReOpenLDAP 1.1.6

Новости — Open Source
Группа Open Source

12 августа вышла новая версия ReOpenLDAP — форка общеизвестного OpenLDAP, с устранением массы ошибок и ряда доработок для стабильной работы репликации.

Эта версия, в некотором смысле, является юбилейной — 3 года с момента инициации проекта (публичный форк появился чуть позже). Всё это время ReOpenLDAP работает 24x7 в инфраструктуре ПАО МегаФон, обеспечивая высоконагруженную обработку запросов в multi-master кластере с full-mesh репликацией.

( читать дальше... )

>>> Релиз на github

 , , , ,

ly
()

ReOpenLDAP 1.1.4

Новости — Open Source
Группа Open Source

30 ноября состоялся релиз ReOpenLDAP 1.1.4.

( читать дальше... )

Сейчас ReOpenLDAP работает в инфраструктуре всех филиалов ПАО МегаФон в России.

>>> Подробности

 , ,

ly
()

давно не мерялись хэш-функциями, есть повод :)

Форум — Development

Быстрее чем City64, xxHash, metrohash, mum-hash и т.д.

Однако, разыскивается комбинация cpu+gcc, где t1ha медленнее чем metrohash, xxHash, City64, mum, fasthash.

https://github.com/leo-yuriev/t1ha

$ ./SMHasher t1ha
--- Testing t1ha "Fast Positive Hash (The 1Hippeus project)"
...
Bulk speed test - 262144-byte keys
Alignment  7 -  4.733 bytes/cycle - 13540.24 MiB/sec @ 3 ghz
Alignment  6 -  4.731 bytes/cycle - 13536.62 MiB/sec @ 3 ghz
Alignment  5 -  4.732 bytes/cycle - 13538.12 MiB/sec @ 3 ghz
Alignment  4 -  4.732 bytes/cycle - 13537.49 MiB/sec @ 3 ghz
Alignment  3 -  4.731 bytes/cycle - 13534.95 MiB/sec @ 3 ghz
Alignment  2 -  4.732 bytes/cycle - 13538.86 MiB/sec @ 3 ghz
Alignment  1 -  4.730 bytes/cycle - 13532.10 MiB/sec @ 3 ghz
Alignment  0 -  4.931 bytes/cycle - 14108.62 MiB/sec @ 3 ghz
Average      -  4.756 bytes/cycle - 13608.38 MiB/sec @ 3 ghz
...
$ ./SMHasher metrohash64_1
--- Testing metrohash64_1 "MetroHash64_1 for 64-bit"
...
Bulk speed test - 262144-byte keys
Alignment  7 -  4.190 bytes/cycle - 11987.40 MiB/sec @ 3 ghz
Alignment  6 -  4.186 bytes/cycle - 11977.52 MiB/sec @ 3 ghz
Alignment  5 -  4.188 bytes/cycle - 11981.03 MiB/sec @ 3 ghz
Alignment  4 -  4.186 bytes/cycle - 11976.78 MiB/sec @ 3 ghz
Alignment  3 -  4.190 bytes/cycle - 11987.54 MiB/sec @ 3 ghz
Alignment  2 -  4.188 bytes/cycle - 11982.82 MiB/sec @ 3 ghz
Alignment  1 -  4.187 bytes/cycle - 11979.17 MiB/sec @ 3 ghz
Alignment  0 -  4.344 bytes/cycle - 12427.48 MiB/sec @ 3 ghz
Average      -  4.207 bytes/cycle - 12037.47 MiB/sec @ 3 ghz
...
$ cat /proc/cpuinfo | grep model
model		: 69
model name	: Intel(R) Core(TM) i7-4600U CPU @ 2.10GHz

$ gcc -v
...
gcc version 5.4.0

 , , ,

ly
()

ReOpenLDAP 1.1.2

Новости — Open Source
Группа Open Source

30 июля вышла очередная стабильная версия 1.1.2 проекта ReOpenLDAP. Основные изменения:

  • Исправлена масса ошибок и недочетов, внесенных ранее при переходе на актуальные версии autoconf и automake. Этим завершен ряд доработок, необходимых для эффективного формирования пакетов «без костылей».
  • Обнаружена и устранена ошибка в механизме репликации.
  • Сборка дополнительных (contributed) модулей интегрирована и включается посредством configure-опции --enable-contrib.
  • В configure также добавлены опции --enable-check, --enable-hipagut, --enable-valgrind и --enable-experimental.
  • Переработана система логирования. Опции configure --enable-debug и --enable-syslog теперь полностью независимы.

ReOpenLDAP, также известный как «TelcoLDAP» — это форк OpenLDAP для применения в телекоммуникационной индустрии, с исправлением массы ошибок и работающей репликацией в мульти-мастер топологии.

Проект реализован для применения в инфраструктуре ОАО МегаФон — крупнейшего в России оператора мобильной связи. Сейчас ReOpenLDAP работает по всей России и доступен для всех как OpenSource с лицензией AGPL.

Осенью о проекте ReOpenLDAP планируются доклады на Highload++2016 и 13-й конференции разработчиков свободных программ.

Новости проекта можно отслеживать в Facebook, а статус Continuous Integration — в Twitter.

>>> Подробности

 , ,

ly
()

В ReOpenLDAP репликация в multi-master топологии полностью работает

Новости — Open Source
Группа Open Source

ReOpenLDAP — форк общеизвестного OpenLDAP, созданный в начале 2015 года с целью получения функциональной работоспособности и стабильности, достаточных для высоконагруженной промышленной (коммерческой) эксплуатации.

Одним из важнейших требований при этом является возможность построения кластера из 4 (2+2) или более узлов. В свою очередь это требует стабильной работы механизма синхронизации (репликации) по RFC4533 в режиме multi-master для full mesh топологии.

Однако, оригинальный OpenLDAP неработоспособен в такой конфигурации, механизм репликации просто теряет часть изменений, а в некоторых случаях может удалить все данные. Более того, неизвестно ни одного другого сервера LDAP, который бы корректно реализовывал RFC4533 с поддержкой multi-master и с приемлемой для эксплуатации производительностью.

Проблемы в исходной реализации синхронизации/репликации были замечены в августе 2015, и почти 9 месяцев было потрачено на их устранение.

Теперь все известные проблемы устранены, а драконовские тесты уже несколько дней показывают только стабильные результаты.

Поэтому мы готовы заявить, что в нашем ReOpenLDAP репликация/синхронизация для multi-master полностью работает как положено. И похоже, что это единственный сервер, пригодный для высоконагруженной промышленной (коммерческой) эксплуатации, причём с открытым исходным кодом.

>>> Исходный код (статус beta) на github

 , , , ,

ly
()

kernel, sound/alsa использовать для данных - потыкайте мне

Форум — Development

Камрады, вот никогда sound в ядре не программировал... А тут попросили помочь, и понеслось.

Короче, есть идея использовать alsa-драйвер в ядре для обмена данными, т.е. сделать поверх него свой протокол и т.д.

Ткните мне как это проще, а то все доки про написания драйверов, но из их не складывается картины как проще/минимальнее использовать sound-инфраструктуру в ядре для кастомного ввода-вывода.

Спасибо.

 , , ,

ly
()

Майское обновление ReOpenLDAP — теперь multimaster-кластер требует в разы меньше RAM

Новости — Linux в России
Группа Linux в России

В ReOpenLDAP добавлена поддержка «кворума» при репликации и возможность ограничения syncrepl-сеансов, находящихся в стадии первоначальной синхронизации. В итоге это уменьшает время синхронизации multimaster-кластера при старте, одновременно существенно уменьшая пиковое потребление ресурсов (оперативной памяти и процессорного времени).

Такая синхронизации, или иначе говоря сверка записей в локальной базе с удаленной стороной, происходит всегда для refreshOnly режима и вначале refreshAndPersist. При этом механизм репликации syncrepl формирует и сверяет в памяти списки записей c удаленной стороны (через поставщика syncprov) и записей в локальной базе. Соответственно, именно в этот момент времени можно наблюдать пиковое потребление памяти и процессорного времени.

В кластере, состоящим из нескольких серверов работающих в режиме multi-master репликации, первоначальная синхронизация может одновременно выполняться несколькими экземплярами syncrepl. В этом случае потребление памяти и нагрузка на CPU могут быть в разы (10 и более раз) больше чем при штатной работе.

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

Наши нагрузочные тесты показывают уменьшение потребление памяти в 2-5 раз и одновременно уменьшение времени синхронизации multimaster-кластера от 3 до 25 раз.

--

ReOpenLDAP — потомок общеизвестного OpenLDAP, но ориентирован на промышленную эксплуатацию в сфере телекоммуникаций (высокие нагрузки, высокая доступность, 24x7). Появился в результате консервативности целей родительского проекта, что выразилось в отказе меинтейнеров Symas Corp принимать изменения улучшающие качество кода и добавление новых возможностей.

Проект реализован силами компании Петер-Сервис R&D, резидента Сколково, для применения в телеком-проектах федерального масштаба.

Актуальная стабильная версия в ветке master на https://github.com/ReOpen/ReOpenLDAP.

Новая «фича» и опции её настройки описаны в русскоязычных man-страницах (пока только в русскоязычных), см. https://github.com/ReOpen/ReOpenLDAP/commit/4d9505532f8ac6f294ae780e33c4f495f...

>>> Проект на github

 , , ,

ly
()

Ишем тестировшика в Питере (HA, HL, ReOpenLDAP)

Форум — Job

Linux, кластер ReOpenLDAP, плюс проприетарный софт на С++.

http://www.billing.ru/job/738

 , , , ,

ly
()

ReOpenLDAP: продолжаем развитие/ассенизацию, решаем что можно отрезать...

Форум — Development

Комрады, снова приветствую.

По-немного мы продолжаем процесс и вот пришло время решить «что отрезать» от оригинала, чтобы обеспечить реальную (не на словах) тестирование и поддержку.

Как и ранее, дабы не увеличивать энтропию - ниже ссылка на более «профильный» форум с топик-мастером.

http://pro-ldap.ru/forum/index.php?topic=286.msg711#msg711

 , , , ,

ly
()

re-openldap iddqd idkfa

Форум — Development

Комрады, приветствую.

Мы тут по-немного продолжаем битву с ассенизацию OpenLDAP.

Хотелось бы обсудить пару моментов. Дабы не увеличивать энтропию впустую - ниже ссылка на более «профильный» форум с топик-мастером.

http://pro-ldap.ru/forum/index.php?topic=286.msg693#msg693

 , , ,

ly
()

memory barriers для _всяческих_ компиляторов и архитектур

Форум — Development

Комрады, мне вот приспичило memory barriers для кучи компиляторов, в том числе старых и тех что я даже не знаю где взять.

Посмотрите глазками, может что подскажите https://gist.github.com/leo-yuriev/ba186a6bf5cf3a27bae7.

Ну и share it по-возможности.

 , , , ,

ly
()

Выпущен релиз-кандидат ReOpenLDAP 2.4.41 «Christmas»

Новости — Open Source
Группа Open Source

ReOpenLDAP — это форк OpenLDAP, который стал ответом на отказ принимать исправления, улучшающие качество кода (было убрано порядка 5000 предупреждений), и добавления новых функций. Причиной отказа являлась консервативность разработчиков исходного проекта при постановке целей.

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

Главное качество этой версии — работа без падений и без отказов сервиса под высокой нагрузкой с репликацией в кластере, что ранее было невозможно. В частности, исправлено 8 heisenbugs, которые существовали годами, особенно в коде репликации и LMDB-движке http://en.wikipedia.org/wiki/Lightning_Memory-Mapped_Database. Одному из багов официально почти 7 лет ;)

Добавленные функции позволяют держать нагрузку по изменениям в 2—10 раз больше оригинального OpenLDAP и до 50 — при наличии у системы хранения write-back кэша (проще говоря, RAID с батарейкой). Для точности следует отметить, что «без батарейки» производительность повышается в результате компромисса, за счет более редкой фиксации данных на диск.

>>> Подробности на github: Описание исправлений и новых фич, исходные тексты.

 , , , ,

ly
()

Да, в 10-100 раз быстрее по записи: OpenLDAP + LMDB

Форум — Development

Комрады, речь о готовом рецепте увеличения производительности по записи для OpenLDAP (когда LMDB используется как бакенд хранения) и для самой «Lightning Memory-Mapped Database» (http://symas.com/mdb/). Не хотелось-бы углубляться в сравнения, но LMDB один из немногих вариантов позволяющий обслужить под миллион read-запросов и порядка 1-100К write-запросов (с этими правками).

Никаких чудес и бесплатного сыра, платить приходиться более редкой фиксацией данных на диске, либо ставить «RAID с батарейкой» (теперь в этом есть смысл). Грубо говоря, на диске фиксируется не каждая транзакция, а как настроите (периодически или по объему изменений). Если же будет write-back кэш «с батарейкой», то ускорение будет и при фиксации каждой транзакции.

Чтобы это работало пришлось допилить LMDB и немного OpenLDAP (aka slapd):

  • правка багов для консистентности периодических чекпоинтов.
  • LIFO-реклайминг (90% правок).
  • прочие мелочи, включая замену «минут» на «секунды» в чекпоинтах.

Из slapd.conf рецепт выглядит например так:

backend mdb
envflags writemap nosync lifo
checkpoint 0 1
Что в переводе: сквозная запись (которая теперь без глюков), сразу ничего не записывать, делать чекпоинты каждую секунду (БД консистентна на диске).

Фишка LIFO-реклайминга в гораздо большей вероятности записи одних и тех же секторов на диске, что дает возможность объединять такие операции если фиксируется не каждая транзакция или есть «RAID с батарейкой». В результате write perfomance действительно растет в обещанные 10-100 раз.

Правки относительно протестированы парой недель тестов и несколькими миллиардами транзакций. Багов, думаю, не больше чем исходно в LMDB и OpenLDAP.

Всё сделанное заслано в http://www.openldap.org/its/index.cgi/Incoming?id=7958, от того и пишу. Мой интерес протолкнуть это в mainstream, чтобы не поддерживать патчи локально. А у Symas Corp видимо сомнения проистекающие из стиля кодирования LMDB. Грубо говоря, и так не всегда понятно как оно работает, а теперь еще веселее (к гусарам просьба - не предлагать переписать LMDB).

Короче, если у кого есть интерес отпишите челобитную по последнему урлу, авось поможет.

p.s. Дабы не уличили в замалчивании: некую первую версию lifo-патча сделал dmitrii.fonariuk@gmail.com, я повторил с «чистого листа» поскольку были баги и в местах контакта код LMDB существенно изменился.

 , , ,

ly
()

Deep Packet Inspection — Большой Брат и Национальный Firewall

Форум — Talks

Event по обозначенной теме http://www.billing.ru/events/560

ly
()

Блин, внезапно - в Андроид захардкодили BEAST еще в 2010

Форум — Security

С натяжкой, но можно так сказать.

Android is using the combination of horribly broken RC4 and MD5 as the first default cipher on all SSL connections... ... it replaced better ciphers which were in use prior to the Android 2.3 release in December 2010.

http://op-co.de/blog/posts/android_ssl_downgrade/

 , beast,

ly
()

kernel & futex = подстава от Ingo Molnár и Thomas Gleixner?

Форум — Development

Ну или поясните мне...

Для FUTEX_LOCK_PI захардкодили ERESTARTNOINTR и CLOCK_REALTIME.

Использование CLOCK_REALTIME без возможности CLOCK_MONOTIME еще можно понять.

Но почему жестко ERESTARTNOINTR, и никогда EINTR?

Почему нельзя прервать ожидание на pi-фьютексе сигналом? Только потому что glibc дизайнят загадочные люди?

Как веслом по морде, всплыло на юнит-тестах :(

 , , ,

ly
()

Поставьте мне мозг на место: GPLv3 + shared memory

Форум — Development

Было:
- есть код под GPLv3 (например вычисления);
- есть еще код под GPLv3 (различный транспорт);
- к этому добавлен main-модуль под GPLv3;
= тут все ясно и понятно, имеем проект под GPLv3.

Стало:
- к указанному GPLv3 проекту добавили код, реализующий транспорт через разделяемую память;
- координаты и формат данных в разделяемой памяти задаются в настройках/опциях, можно считать что работает интерпретатор или компилятор;
- все изменения исходников доступны;
= ну тоже понятно, имеем проект под GPLv3, в который внесены изменения, нарушений нет.

Туплю:
- есть проприетарная прога, которая создает именованный регион разделяемой памяти и производит с ним обмен;
- настройками двух проектов их можно «подружить», таким образом GPLv3 и не-GPL в каком-то смысле объединяются;
- обмен производится массивами (длина плюс линейно данные);
= вопрос, это нарушение GPLv3 или нет?

 , ,

ly
()

[git] План слияния + WebUI

Форум — Development

Предположим:

  • У вас есть 3-10 репозиториев/проектов git, возможно даже всё живет в gerrit.
  • В каждом репозитории 5-50 веток, организованных примерно как http://habrahabr.ru/blogs/Git/106912/
  • В ветках идет работа, итерации, фичи, исправления и т.д.
  • Совсем в другой стороне есть план, со сроками и задачами.
  • Соответственно этот план имеет некую проекцию на структуру веток и их слияния.
  • Но сроки не всегда соблюдаются, коммиты идут постоянно и «невовремя», а ветки нужно мержить, да еще и видеть картину в целом чтобы как-бы чего не забыть...

Хочется иметь некую LAMPочку с помощью которой:

  • вводить изначальный план слияния веток, что и куда, к какой дате;
  • видеть treeview плана слияния со сроками;
  • видеть коммиты, особенно в побочные ветки после вливания последних в главные;

Готового не нашел. Кто знает про такое счастье?

 

ly
()

cmake - зависимости для сборки инструмента, как?

Форум — Development

В проекте используется свой язык (оправдано). Соответственно, для этого языка в составе того-же проекта есть компилятор, в виде исходников.

Как cmake (@#$%!) объяснить, что сначала нужно собрать компилятор, а потом им компилировать другие сорцы.

Пока тупо внес путь к получаемому компилятору в зависимости custom-command.

Работает костыльно - cmake генерит часть make-файлов, но обламывается на поиске компилятора, считая его исходным текстом. Но запущенный make уже все разруливает, так как построение компилятора уже определено.

ly
()

[вакансия, москва] нужен помощник - инженер конфигурационного управления

Форум — Job

Ведущий инженер конфигурационного управления (разработчик средств внутренней автоматизации)

git + gerrit + teamcity + сборки + hasher + тесты + ...

http://hh.ru/vacancy/3801680

ly
()

RSS подписка на новые темы