Франкенштейнизация Voldemort или key-value данные в Одноклассниках. Роман Ан...odnoklassniki.ru
A talk from jokerconf.com conference.
"Frankenstaining of Voldemort" or "key-value storage evolution at Odnoklassniki"
В докладе освещены Java-технологии хранения данных, обслуживающие десятки миллионов пользователей и работающие на сотнях серверов.
На примере социальной сети "Одноклассники" мы рассмотрим эволюцию хранилищ данных с высоким уровнем конкурентного доступа и с соблюдением требования постоянной доступности.
Мы разберём сильные и слабые стороны каждого из решений, начиная от технологии master-slave репликации на основе Berkeley DB и заканчивая симбиозом распределенных хранилищ Voldemort и Cassandra.
Франкенштейнизация Voldemort или key-value данные в Одноклассниках. Роман Ан...odnoklassniki.ru
A talk from jokerconf.com conference.
"Frankenstaining of Voldemort" or "key-value storage evolution at Odnoklassniki"
В докладе освещены Java-технологии хранения данных, обслуживающие десятки миллионов пользователей и работающие на сотнях серверов.
На примере социальной сети "Одноклассники" мы рассмотрим эволюцию хранилищ данных с высоким уровнем конкурентного доступа и с соблюдением требования постоянной доступности.
Мы разберём сильные и слабые стороны каждого из решений, начиная от технологии master-slave репликации на основе Berkeley DB и заканчивая симбиозом распределенных хранилищ Voldemort и Cassandra.
За счет чего Tarantool такой оптимальный / Денис Аникин (Mail.Ru)Ontico
Многие из вас, наверное, видели результаты тестов сравнения Tarantool с остальными СУБД, которые показывают, что Tarantool быстрее всех, оптимальней по памяти, обрабатывает наибольшее количество транзакций в секунду.
И, несмотря на то, что исходные коды всех тестов полностью открыты и хорошо откомментированы, позволяя всем желающим повторить тесты, все равно остаются вопросы - за счет чего Tarantool такой быстрый и оптимальный?
Я решил суммировать мои ответы на эти вопросы в докладе на Highload++.
Итак, почему Tarantool такой быстрый?
Краткий ответ: потому что он с самого начала разрабатывался и до сих пор разрабатывается во главе угла с производительностью/оптимальностью/минимальным потреблением всех ресурсов системы.
Более полный ответ я раскрою в своем выступлении. Приходите, будет интересно! :)
Как мы в Почте@Mail.Ru выдерживаем высокие нагрузкиtfmailru
Почта@Mail.Ru и главная страница Mail.Ru — очень высоконагруженные сервисы. Суточная аудитория — 20 млн человек, количество хитов в день на динамику — более 500 млн. Я хочу рассказать вам о том, как мы выдерживаем такие нагрузки, посредством каких технологий, как мы к ним пришли и что получили в результате.
Юрий Насретдинов-«Сбор логов в «облаке» в Badoo»Tanya Denisyuk
В нашей компании есть система для запуска PHP-скриптов по расписанию, которая позволяет распределять нагрузку на множество узлов и обеспечивать отказоустойвость. И в этой системе необходимо уметь собирать логи скриптов с сотен (и даже тысяч) машин, желательно в режиме реального времени. У нас раньше была система сбора логов, собранная «на коленке», и выдающая относительно невысокую производительность. Производительности стало не хватать, и мы переписали систему на Go. Новая система не использует scribe и обладает некоторыми уникальными фичами, например «вытесняющей многозадачностью» при доставке - если один из скриптов пишет столько логов, что мы не успеваем их всех доставить, логи всех остальных скриптов продолжают доставляться, с небольшой фиксированной задержкой. Система легко забивает гигабитную сетевую карту на нашем сервере-приемнике логов и не слишком «тормозит» доставку в случае, когда пропускной способности всё же не хваетает. В докладе я расскажу о том, как мы делали эту систему и про то, как она работает изнутри. Исходные тексты доступны на github: https://github.com/badoo/thunder
Современная операционная система: что надо знать разработчику / Александр Кри...Ontico
Мы проговорим про связь приложения и ОС, какие компоненты есть в современной ОС на примере Linux, как настройки этих компонент могут повлиять на приложение.
Я расскажу про планировщик процессов, дисковый и сетевой ввод-вывод и соответствующие планировщики, управление памятью - как это все в общих чертах работает и как его потюнить.
Движок LMDB — особенный чемпион / Юрьев Леонид (Петер-Сервис R&D)Ontico
Lightning Memory-Mapped Database (LMDB) представляет собой интересный, во многом уникальный движок базы данных класса Berkeley DB и Level DB с ребус-подобным исходным кодом. Будучи относительно малоизвестным, LMDB показывает ЧЕМПИОНСКУЮ производительность по чтению. Однако при интенсивной записи всё не так радужно…
Было ещё несколько проблем и недостатков, которые нам пришлось устранить, разбираясь в ребусах исходного кода. Доклад точно будет интересен разработчикам, интересующимся внутренностями баз данных или характеристиками отдельных движков.
Проект реализуется силами компании Петер-Сервис R&D, резидента Сколково, для применения в телеком-проектах федерального масштаба.
Информация о нашем проекте https://github.com/ReOpen/ReOpenLDAP/wiki, об исходной версии LMDB http://symas.com/mdb/.
Checkpoint and Restore In Userspace: Готово или нет?OpenVZ
Доклад рассказывает о проекте CRIU (Checkpoint/Restore in Userspace) — сохранения (checkpoint) полного состояния работающих процессов с последующим их восстановлением (restore), реализованном по большей части как пользовательская (userspace) программа. Начинается он с истории о том, почему в ванильном ядре Linux до сих пор нет реализации checkpoint/restore, и как мы это побороли. В основной части доклада рассматриваются механизмы работы CRIU, в частности как сохраняются и восстанавливаются процессы, открытые файлы, память, сетевые соединения, терминалы и т.п. В заключении рассказывается о том, для чего можно использовать такой механизм (а это не только "живая" миграция), даётся текущий статус проекта и творческие планы разработчиков, и, конечно, демонстрация основных возможностей CRIU на живой системе.
https://events.yandex.ru/lib/talks/352/
Docker в работе: взгляд на использование в Badoo через годBadoo Development
Мы в Badoo используем Docker больше года и на нашем примере попробуем поговорить о возможных моделях его применения.
- 85% наших сервисов работают в контейнерах: для чего и почему мы перенесли свои сервисы в контейнеры.
- Как мы подходим к сборке образов? Базовый образ: используем слои, следим за системными обновлениями.
- Автоматизация процесса сборки образов с нашими сервисами: Jira flow, Teamcity и другие страшные для админа слова.
- Лучшее ли место для тестирования production? Путь образа от сборки до Production.
- baDocker: webUI своими руками: зачем и почему?
- Как дать возможность управлять запущенными сервисами и их версиями разработчику.
- Docker: мониторинг и анализ работающих контейнеров.
Доклад Антона Турецкого на Highload 2015.
https://youtu.be/UgUuF_qZmWc
Реализация восстановления после аварий / Сергей Бурладян (Avito)Ontico
Базы данных PostgreSQL занимают одно из центральных мест в Авито. Они являются разделяемой платформой, вокруг которой построено множество дополнительных сервисов. Одной из основных задач при их администрировании является задача восстановления после аварий как самих баз, так и связанной с ними инфраструктуры.
В своём докладе я постараюсь рассказать про:
+ общую схему связей баз данных между собой и с другими компонентами;
+ точки отказа и виды аварий, затрагиваемые связи;
+ бинарную репликацию и архив;
+ логическую репликацию, pgq, londiste, UNDO (REDO), пересоздание репки;
+ скрипт и процедуру переключения при аварии;
+ планы: развитие «восстановлений» по всем связям, автоматика на основе системы zookeeper (etcd и т.п.).
За счет чего Tarantool такой оптимальный / Денис Аникин (Mail.Ru)Ontico
Многие из вас, наверное, видели результаты тестов сравнения Tarantool с остальными СУБД, которые показывают, что Tarantool быстрее всех, оптимальней по памяти, обрабатывает наибольшее количество транзакций в секунду.
И, несмотря на то, что исходные коды всех тестов полностью открыты и хорошо откомментированы, позволяя всем желающим повторить тесты, все равно остаются вопросы - за счет чего Tarantool такой быстрый и оптимальный?
Я решил суммировать мои ответы на эти вопросы в докладе на Highload++.
Итак, почему Tarantool такой быстрый?
Краткий ответ: потому что он с самого начала разрабатывался и до сих пор разрабатывается во главе угла с производительностью/оптимальностью/минимальным потреблением всех ресурсов системы.
Более полный ответ я раскрою в своем выступлении. Приходите, будет интересно! :)
Как мы в Почте@Mail.Ru выдерживаем высокие нагрузкиtfmailru
Почта@Mail.Ru и главная страница Mail.Ru — очень высоконагруженные сервисы. Суточная аудитория — 20 млн человек, количество хитов в день на динамику — более 500 млн. Я хочу рассказать вам о том, как мы выдерживаем такие нагрузки, посредством каких технологий, как мы к ним пришли и что получили в результате.
Юрий Насретдинов-«Сбор логов в «облаке» в Badoo»Tanya Denisyuk
В нашей компании есть система для запуска PHP-скриптов по расписанию, которая позволяет распределять нагрузку на множество узлов и обеспечивать отказоустойвость. И в этой системе необходимо уметь собирать логи скриптов с сотен (и даже тысяч) машин, желательно в режиме реального времени. У нас раньше была система сбора логов, собранная «на коленке», и выдающая относительно невысокую производительность. Производительности стало не хватать, и мы переписали систему на Go. Новая система не использует scribe и обладает некоторыми уникальными фичами, например «вытесняющей многозадачностью» при доставке - если один из скриптов пишет столько логов, что мы не успеваем их всех доставить, логи всех остальных скриптов продолжают доставляться, с небольшой фиксированной задержкой. Система легко забивает гигабитную сетевую карту на нашем сервере-приемнике логов и не слишком «тормозит» доставку в случае, когда пропускной способности всё же не хваетает. В докладе я расскажу о том, как мы делали эту систему и про то, как она работает изнутри. Исходные тексты доступны на github: https://github.com/badoo/thunder
Современная операционная система: что надо знать разработчику / Александр Кри...Ontico
Мы проговорим про связь приложения и ОС, какие компоненты есть в современной ОС на примере Linux, как настройки этих компонент могут повлиять на приложение.
Я расскажу про планировщик процессов, дисковый и сетевой ввод-вывод и соответствующие планировщики, управление памятью - как это все в общих чертах работает и как его потюнить.
Движок LMDB — особенный чемпион / Юрьев Леонид (Петер-Сервис R&D)Ontico
Lightning Memory-Mapped Database (LMDB) представляет собой интересный, во многом уникальный движок базы данных класса Berkeley DB и Level DB с ребус-подобным исходным кодом. Будучи относительно малоизвестным, LMDB показывает ЧЕМПИОНСКУЮ производительность по чтению. Однако при интенсивной записи всё не так радужно…
Было ещё несколько проблем и недостатков, которые нам пришлось устранить, разбираясь в ребусах исходного кода. Доклад точно будет интересен разработчикам, интересующимся внутренностями баз данных или характеристиками отдельных движков.
Проект реализуется силами компании Петер-Сервис R&D, резидента Сколково, для применения в телеком-проектах федерального масштаба.
Информация о нашем проекте https://github.com/ReOpen/ReOpenLDAP/wiki, об исходной версии LMDB http://symas.com/mdb/.
Checkpoint and Restore In Userspace: Готово или нет?OpenVZ
Доклад рассказывает о проекте CRIU (Checkpoint/Restore in Userspace) — сохранения (checkpoint) полного состояния работающих процессов с последующим их восстановлением (restore), реализованном по большей части как пользовательская (userspace) программа. Начинается он с истории о том, почему в ванильном ядре Linux до сих пор нет реализации checkpoint/restore, и как мы это побороли. В основной части доклада рассматриваются механизмы работы CRIU, в частности как сохраняются и восстанавливаются процессы, открытые файлы, память, сетевые соединения, терминалы и т.п. В заключении рассказывается о том, для чего можно использовать такой механизм (а это не только "живая" миграция), даётся текущий статус проекта и творческие планы разработчиков, и, конечно, демонстрация основных возможностей CRIU на живой системе.
https://events.yandex.ru/lib/talks/352/
Docker в работе: взгляд на использование в Badoo через годBadoo Development
Мы в Badoo используем Docker больше года и на нашем примере попробуем поговорить о возможных моделях его применения.
- 85% наших сервисов работают в контейнерах: для чего и почему мы перенесли свои сервисы в контейнеры.
- Как мы подходим к сборке образов? Базовый образ: используем слои, следим за системными обновлениями.
- Автоматизация процесса сборки образов с нашими сервисами: Jira flow, Teamcity и другие страшные для админа слова.
- Лучшее ли место для тестирования production? Путь образа от сборки до Production.
- baDocker: webUI своими руками: зачем и почему?
- Как дать возможность управлять запущенными сервисами и их версиями разработчику.
- Docker: мониторинг и анализ работающих контейнеров.
Доклад Антона Турецкого на Highload 2015.
https://youtu.be/UgUuF_qZmWc
Реализация восстановления после аварий / Сергей Бурладян (Avito)Ontico
Базы данных PostgreSQL занимают одно из центральных мест в Авито. Они являются разделяемой платформой, вокруг которой построено множество дополнительных сервисов. Одной из основных задач при их администрировании является задача восстановления после аварий как самих баз, так и связанной с ними инфраструктуры.
В своём докладе я постараюсь рассказать про:
+ общую схему связей баз данных между собой и с другими компонентами;
+ точки отказа и виды аварий, затрагиваемые связи;
+ бинарную репликацию и архив;
+ логическую репликацию, pgq, londiste, UNDO (REDO), пересоздание репки;
+ скрипт и процедуру переключения при аварии;
+ планы: развитие «восстановлений» по всем связям, автоматика на основе системы zookeeper (etcd и т.п.).
Управление данными и защита от сбоев. Решения КРОК на основе продуктов COMMVAULTКРОК
Веб-семинар «Управление данными и защита от сбоев. Решения КРОК на основе продуктов CommVault».
Подробнее о мероприятии http://www.croc.ru/action/detail/1466/
Презентация Дениса Мурунова, Эксперта группы системных инженеров департамента информационных технологий КРОК
2. Изменение ценности данных различных типов со временем. Ценность данных/ частота обращений 7 Дней 14 21 28 3 Мес. 6 9 1 Год 5 Лет 10 Лет Дней День Дней Мес. Мес. Источник : Enterprise Storage Group 0 20 40 60 80 100 MPEG Документы email Коды программ Базы данных
3. Иерархическая организация хранилищ данных Наиболее часто используемые данные Данные требуются время от времени Данные, возможно, никогда не потребуются, но хранить их нужно Стоимость за Mb Быстродействие
4. Схема работы TSM for Space Management Ценность данных/ частота обращений 7 Дней 14 21 28 3 Мес. 6 9 1 Год 5 Лет 10 Лет Дней День Дней Мес. Мес. Источник : Enterprise Storage Group Возврат файлов Миграция файлов . . . Сервер с установленным TSM клиентом Заполненность хранилища данных Пользователи TSM сервер Хранилище данных 0 20 40 60 80 100
5. Компоненты TSM Ценность данных/ частота обращений Мес. 6 9 1 Год 5 Лет 10 Лет Мес. Источник : Enterprise Storage Group Демон сканирования (dsmscoutd) Демон привилегированного доступа ( dsmrootd ) Демон возврата ( dsmrecalld ) Реконциляция (dsmreconcile) Миграция ( dsmmigrate, dsmautomig ) Восстановление после удаления ( dsmmigundelete ) Следит за событиями чтения/записи файлов на управляемой файловой системе. Осуществляет возврат файлов с сервера Осуществляет сканирование файловой системы для поиска наиболее подходящих кандидатов для миграции Демон мониторинга ( dsmmonitord ) Предоставляет привелигированный доступ к некоторым сервисам файловой системы для компонент TSM , вызываемых обычными пользователями Осуществляет контроль уровня свободного пространства на файловой системе. При необходимости запускает процедуру автоматической миграции. Выполняет пересылку файлов на сервер. Вместо посланного на сервер файла помещает ярлык на локальную файловую систему. Выполняет синхронизацию данных, находящихся на сервере, с текущим состоянием данных на локальной файловой системе Восстанавливает ошибочно удаленные ярлыки к мигрированным файлам
6. Автоматическая миграция при росте объема данных 60 70 80 90 100 110 120 130 140 150 160 170 180 190 200 210 50 40 30 верхний порог нижний порог При достижении верхнего порога занятости, запускается автоматическая миграция данных, пока уровень занятости файловой системы не станет равным заданному нижнему порогу Уровень занятости локальной файловой системы в % от ее объема время Данные на локальном хранилище Данные на TSM сервере Верхний порог занятости установлен в 90%, нижний в 70%
7. Механизм миграции файла Файл до миграции Файл после миграции TSM сервер dsmmigrate/dsmautomig ярлык ( ~4K ) пустая область (sparse) атрибуты DMAPI данные данные ID … … …
8. Использование DMAPI в TSM 10 Лет Приложение пользователя TSM for Space Management Извлечение файла из сервера read() Возврат из read() User - пространство Kernel - пространство Инициализация DMAPI Ожидание события Запись отсутствующих блоков файла Пользовательский процесс приостановлен Генерация события DMAPI Ответ на событие
9. Логическая структура Juelich Storage Cluster (JUST) 4 TSM Server P5-55A Force 10 E1200 208 Ports (10GigE) /work /a rch /home 8 x 36 TB 96 TB 96 TB 288 TB Management Server P5-520
11. Управление свободным пространством на файловой системе в UNIX и L inux Дмитрий Трубач р.т. : +375 17 2173384 e-mail : dtrubach@iba.by спасибо за внимание
Editor's Notes
Данная презентация описывает применение IBM Tivoli Storage Manager for Space Management для целей автоматического управления свободным пространством на файловой системе в среде UNIX и Linux .