Системный администратор Vkontakte. Как? / Антон Кирюшкин (Vkontakte)Ontico
Достаточно давно уже был какой-то доклад о том, что собой представляет Вконтакте изнутри. В своем докладе я хотел быть отчасти обновить те знания и рассказать, какие из общедоступных инструментов есть в руках системных администраторов социальной сети. Разумеется, кроме чистой головы и прямых рук (лишнее зачеркнуть).
Я намереваюсь коснуться таких вопросов, как:
- Управление конфигурацией на очень большом числе серверов.
- Разграничение доступа.
- Развертывание кода на рабочей площадке.
- Мониторинг.
- Как мы, вообще, справляемся с таким гигантом малым числом людей?
Архитектура растущего проекта на примере ВКонтакте / Алексей Акулович (ВКонт...Ontico
В докладе я расскажу о проблемах роста, с которыми сталкивался проект как в плане доступа к БД, так и в целом. Как решали, что получалось, как (общетеоретически или практически) можно решать подобные проблемы в других проектах.
Разберем несколько реальных случаев, когда что-то шло не так.
Доклад можно рассматривать и как небольшой экскурс в развитие технической платформы ВК, и как собрание нескольких практических способов для проекта вырасти и стать надежнее.
5 способов деплоя PHP-кода в условиях хайлоада / Юрий Насретдинов (Badoo)Ontico
В дата-центрах нашей компании несколько тысяч серверов, и примерно на половине из них нужно выкладывать PHP-код 2 раза в день. Помимо раскладки на production также не стоит забывать о том, что код нужен на стейджинге, и в стейджинг-кластер у нас входит около 50 машин, код на которых обновляется раз в несколько минут. Также есть «хотфиксы» — небольшие (1-5) наборы файлов, которые выкладываются во внеочередном порядке на все или на выделенную часть серверов, чтобы устранить существующие проблемы на продакшне, не дожидаясь полной выкладки.
В этом докладе я расскажу о том, как мы деплоились в течение 10 лет, о том, какую новую систему для деплоя PHP-кода мы разработали и внедрили в production, а также проведу обзор решений для масштабного деплоя кода на PHP и анализ их производительности.
План доклада:
— Наша старая система деплоя, достоинства и недостатки.
— Существующие решения:
* "svn up" / "git pull".
* rsync.
* phar, hhbc (HHVM-specific), "loop".
* rsync + 2 директории + realpath_root (Rasmus-style).
— Требования для новой системы деплоя.
* быстрый деплой на стейджинг (5-10 секунд на 50 серверов).
* возможность атомарно патчить несколько файлов и быстро их выкладывать (10 секунд на весь кластер).
* совместимость с docker.
* поддержка «долгоиграющих» CLI-скриптов (несколько часов).
* низкое потребление ресурсов на принимающей стороне.
* отсутствие необходимости сбрасывать opcache.
* высокая скорость деплоя на продакшн (1-2 минуты на 1500 серверов).
— MDK — multiversion deployment kit.
— Анализ применимости и производительности способов деплоя.
— Выводы.
Внедрение Docker в процесс разработки демонов. Доклад Константина Карпова на ...Badoo Development
Рассказываем о том, как мы жили без Docker'а и зачем его решили использовать. А также описываем процесс внедрения в CI и, в частности, в тесты, плюс с какими проблемами столкнулись и как их побороли.
Системный администратор Vkontakte. Как? / Антон Кирюшкин (Vkontakte)Ontico
Достаточно давно уже был какой-то доклад о том, что собой представляет Вконтакте изнутри. В своем докладе я хотел быть отчасти обновить те знания и рассказать, какие из общедоступных инструментов есть в руках системных администраторов социальной сети. Разумеется, кроме чистой головы и прямых рук (лишнее зачеркнуть).
Я намереваюсь коснуться таких вопросов, как:
- Управление конфигурацией на очень большом числе серверов.
- Разграничение доступа.
- Развертывание кода на рабочей площадке.
- Мониторинг.
- Как мы, вообще, справляемся с таким гигантом малым числом людей?
Архитектура растущего проекта на примере ВКонтакте / Алексей Акулович (ВКонт...Ontico
В докладе я расскажу о проблемах роста, с которыми сталкивался проект как в плане доступа к БД, так и в целом. Как решали, что получалось, как (общетеоретически или практически) можно решать подобные проблемы в других проектах.
Разберем несколько реальных случаев, когда что-то шло не так.
Доклад можно рассматривать и как небольшой экскурс в развитие технической платформы ВК, и как собрание нескольких практических способов для проекта вырасти и стать надежнее.
5 способов деплоя PHP-кода в условиях хайлоада / Юрий Насретдинов (Badoo)Ontico
В дата-центрах нашей компании несколько тысяч серверов, и примерно на половине из них нужно выкладывать PHP-код 2 раза в день. Помимо раскладки на production также не стоит забывать о том, что код нужен на стейджинге, и в стейджинг-кластер у нас входит около 50 машин, код на которых обновляется раз в несколько минут. Также есть «хотфиксы» — небольшие (1-5) наборы файлов, которые выкладываются во внеочередном порядке на все или на выделенную часть серверов, чтобы устранить существующие проблемы на продакшне, не дожидаясь полной выкладки.
В этом докладе я расскажу о том, как мы деплоились в течение 10 лет, о том, какую новую систему для деплоя PHP-кода мы разработали и внедрили в production, а также проведу обзор решений для масштабного деплоя кода на PHP и анализ их производительности.
План доклада:
— Наша старая система деплоя, достоинства и недостатки.
— Существующие решения:
* "svn up" / "git pull".
* rsync.
* phar, hhbc (HHVM-specific), "loop".
* rsync + 2 директории + realpath_root (Rasmus-style).
— Требования для новой системы деплоя.
* быстрый деплой на стейджинг (5-10 секунд на 50 серверов).
* возможность атомарно патчить несколько файлов и быстро их выкладывать (10 секунд на весь кластер).
* совместимость с docker.
* поддержка «долгоиграющих» CLI-скриптов (несколько часов).
* низкое потребление ресурсов на принимающей стороне.
* отсутствие необходимости сбрасывать opcache.
* высокая скорость деплоя на продакшн (1-2 минуты на 1500 серверов).
— MDK — multiversion deployment kit.
— Анализ применимости и производительности способов деплоя.
— Выводы.
Внедрение Docker в процесс разработки демонов. Доклад Константина Карпова на ...Badoo Development
Рассказываем о том, как мы жили без Docker'а и зачем его решили использовать. А также описываем процесс внедрения в CI и, в частности, в тесты, плюс с какими проблемами столкнулись и как их побороли.
За счет чего Tarantool такой оптимальный / Денис Аникин (Mail.Ru)Ontico
Многие из вас, наверное, видели результаты тестов сравнения Tarantool с остальными СУБД, которые показывают, что Tarantool быстрее всех, оптимальней по памяти, обрабатывает наибольшее количество транзакций в секунду.
И, несмотря на то, что исходные коды всех тестов полностью открыты и хорошо откомментированы, позволяя всем желающим повторить тесты, все равно остаются вопросы - за счет чего Tarantool такой быстрый и оптимальный?
Я решил суммировать мои ответы на эти вопросы в докладе на Highload++.
Итак, почему Tarantool такой быстрый?
Краткий ответ: потому что он с самого начала разрабатывался и до сих пор разрабатывается во главе угла с производительностью/оптимальностью/минимальным потреблением всех ресурсов системы.
Более полный ответ я раскрою в своем выступлении. Приходите, будет интересно! :)
Что нового в nginx? / Максим Дунин (Nginx, Inc.)Ontico
Что нового появилось в nginx за последнее время и для чего всё это нужно?
В докладе - рассказ про основные новые функции в nginx 1.9.x (1.10.x) и 1.11.x. HTTP/2, модуль stream, динамическая загрузка модулей и так далее - зачем всё это нужно и как это использовать.
Читаем CHANGES вместе и разбираем на примерах.
DPDK в виртуальном коммутаторе Open vSwitch / Александр Джуринский (Selectel)Ontico
Intel DPDK (Data Plane Development Kit) — набор драйверов и библиотек, позволяющих приложениям взаимодействовать с сетевым устройством напрямую, минуя сетевой стек Linux. Это значительно увеличивает скорость обработки пакетов. DPDK интегрируется с рядом популярных программных решений, например, c виртуальным коммутатором Open vSwitch.
Возможностям и перспективам использования связи Open vSwitch + DPDK в облачных проектах и будет посвящен наш доклад. Мы подробно остановимся на проведённых тестах производительности и интерпретируем их результаты. Отдельное внимание будет уделено анализу трудностей и ограничений, с которыми пришлось столкнуться в ходе экспериментов.
JS Lab2017_Виталий Лебедев_Практические сложности при разработке на node.js GeeksLab Odessa
JS Lab2017, 25 марта, Одесса
Виталий Лебедев (Software Developer at DataArt)
Практические сложности при разработке на node.js
В этом докладе я расскажу, с какими непосредственными практическими сложностями можно встретиться при разработке на node.js, в силу тех или иных ограничений самого node.js, и какие для этих задач существуют возможные решения.
Все материалы: http://jslab.in.ua/
Организаторы: http://geekslab.org.ua/
DC/OS – больше чем PAAS, Никита Борзых (Express 42)Ontico
Доклад про ближайшее будущее в эксплуатации распределённых систем.
Компания Mesosphere весной 2016 сделала свою платформу DC/OS (data center operation system) бесплатной и открытой. Платформа DC/OS унифицирует и упрощает процесс поставки и эксплуатации систем.
Основными особенностями платформы являются:
– переход от host centric к resource centric подходу для всех компонентов вашего проекта за счёт представления серверов как ресурсов для приложения (с помощью mesos и marathon);
– наличие инструментов автоматического восстановления вашего проекта после аварии;
– marketplace для приложений. Например, можно развернуть MySQL, Elasticsearch, Kafka или mongodb кластер, используя готовые скрипты развертывания. Процесс развертывания кастомизируется, в случае необходимости можно описать кастомные приложения и поправить скрипты существующих;
– наличие API для интеграции в ваши системы CI/CD, мониторинга, и т.д.
Основные компоненты DC/OS:
– Apache Mesos — абстракция над датацентром, которая представляет сервера (физические и виртуальные) как ресурсы и распределяет эти ресурсы на основании данных о потребностях приложения;
– Marathon — система распределённого запуска приложений (в т.ч. docker контейнеров), основной фишкой является возможность декларативного описания вашей системы. Вы можете описать, сколько ресурсов нужно вашему приложению, зависимости между приложениями, и в каком порядке производить деплой.
Доклад разбит на три части:
– Интро про DC/OS, сравнение с kubernetes и coreos стеком;
– Рассказ про компоненты mesos и marathon, как их можно использовать с докером (и без!) уже сейчас;
– Опыт Express 42. Мы построили CI/CD платформу для приложений, с использованием Mesos, Marathon, Docker и Jenkins 2.0.
Горизонтальное масштабирование: что, зачем, когда и как /Александр Макаров (Y...Ontico
Масштабирование — способность наращивать систему для обработки большего количества трафика, не теряя при этом пользовательские качества: скорость и отзывчивость.
Масштабирование различают двух типов: вертикальное (больше памяти, диска, лучше процессор) и горизонтальное (больше серверов в кластере).
- Зачем оно нужно, если и так всё работает?
- Когда? Мониторинг, необдуманные решения, оптимизация и жизнь с одним сервером.
- Типичная схема.
- Балансировка нагрузки.
- Какие, вообще, проблемы на стороне приложения?
- Почему PHP так хорош для масштабирования.
- Сессии.
- База данных.
- Файлы.
- Как быть со статистикой?
Депрокрастинируем Docker: контейнеры здесь и сейчасRuslan Sharipov
Депрокрастинируем Docker: контейнеры здесь и сейчас (мастер-класс). Руслан Шарипов (7bits), Денис Нелюбин (Avelix).
При подходе к любому важному делу или к изучению интересной технологии очень важно сделать первый шаг. Этот шаг может быть совсем шажочком, небольшим движением вперёд, но, часто бывает, что именно такие шаги позволяют добиваться завершения дел до конца.
В последнее время часто наши коллеги и знакомые грозятся погуглить, изучить, разобраться, исследовать, ознакомиться, попробовать, начать использовать Docker, и постоянно откладывают это дело в долгий ящик. Кто-то боится новизны технологии, кто-то хочет задать тонну вопросов, а кто-то просто не понимает, нужна ли технология для него.
В рамках этого мастер класса мы сделаем первый шаг к тому, чтобы попробовать на практике то, что есть сейчас Docker. Мы рассмотрим, что у него под капотом: какие технологии стоят за популярным названием, как работает Docker изнутри, обсудим и научимся использовать на практике контейнеры, registry и инструменты, упрощающие процесс доставки и запуска контейнеров на серверах, обсудим и найдём решения для возникающих проблем, напишем тесты и научимся тестировать инфраструктуру в контейнерах.
Presented: 6th June, 2015
Лучшие практики Continuous Delivery с Docker / Дмитрий Столяров (Флант)Ontico
Потребность в отстроенном процессе Continuous Delivery встает перед каждым развивающимся highload-проектом. Чем больше серверов и составных приложений, чем выше динамика релизов, тем раньше проект сталкивается с данной потребностью, и тем острее она стоит.
Многие команды эксплуатации смогли отстроить этот процесс, некоторые добились впечатляющих результатов, а некоторые — потерпели неудачу. Но все из них знают, что их процесс можно улучшить: сделать быстрее, надежнее, предсказуемее и удобнее.
В этом докладе я хочу обобщить и систематизировать лучшие практики построения процесса Continuous Delivery с использованием актуальных Open Source технологий (Docker, Chef, Gitlab, Kubernetes), а также обозначить известные проблемы и потенциальные пути их решения.
Будет предпринята попытка однозначно ответить на следующие практические вопросы:
- Почему пора всем переходить на Docker? Как лучше собирать Docker-образы? Как лучше доставлять и хранить Docker-образы?
- Как правильно построить процесс разработки Infrastructure as Code (IaC)?
- Как оптимально интегрировать автоматическое и ручное тестирование в процесс Continuous Delivery?
- Как перестать бояться регулярных выкатов новых версий и сделать этот процесс надежным?
- Почему Continuous Delivery не заканчивается релизом новой версии и зачем нужен Kubernetes?
LuaJIT как основа для сервера приложений - проблемы и решения / Игорь Эрлих (...Ontico
С того момента, как было принято решение использовать язык Lua в качестве языка описания бизнес-логики в нашей платформе, прошло уже больше восьми лет. Проекты росли, данных становилось больше, возрастала нагрузка на сервера приложений. Со временем у нас накопился солидный багаж знаний о том, как устроен LuaJIT, с какими проблемами можно столкнуться при его использовании и как эти проблемы можно решать.
Я расскажу про то...
* Почему при миграции с x86 на x64 доступной памяти в LuaJIT становится меньше, и как мы с этим боролись.
* Как загрузить в LuaJIT несколько миллионов объектов и не умереть в тормозах от сборщика мусора.
* Насколько ужасна встроенная функция хеширования строк и почему иногда надо жертвовать производительностью в пользу качества.
Платформа для видео сроком в квартал. Александр Тоболь.odnoklassniki.ru
A talk from jokerconf.com conference. "Video Platform in 3 months. Delivered." by Alexander Tobol.
Доклад не затронет какую-то особенную технологию или волшебный алгоритм. Речь пойдет о том, как чуть больше чем за квартал совсем небольшая команда перезапустила работающий в режиме 24/7 совсем немаленький видео-сервис на Одноклассниках на написанной с нуля платформе, развернутой на парке из свыше 200 серверов, распределенных между несколькими центрами обмена данными.
Я бы хотел поделиться успехами и неудачами в ходе решения задачи по обеспечению бесперебойных загрузки, трансформации, хранения, раздачи видео и мониторинга, а также остановиться на особенностях, связанных с нагрузкой в 1000 просмотров в секунду, размером ежедневной аудитории в 8 миллионов географически распределенных в и за пределами РФ. Я также остановлюсь на некоторых использованных нами технологиях.
Балансировка нагрузки и отказоустойчивость в ОдноклассникахOntico
Главная → Тезисы и презентации
Балансировка нагрузки и отказоустойчивость в Одноклассниках Системное администрирование
Доклад принят в Программу конференции
Никита Духовный
Одноклассники
Ведущий системный администратор в Одноклассниках. Начинал IT-карьеру разработчиком, занимался релиз инженерией, выбрал системное администрирование.
Возглавляет одну из команд. Занимается задачами, обеспечивающими работу портала - автоматизацией, запуском новых решений, поддержкой инфраструктуры. Ведёт несколько хардкорных проектов, в том числе - по повышению отказоустойчивости портала.
Тезисы
Проект Одноклассники начинал свою жизнь в одном датацентре.
С ростом популярности растёт и нагрузка. С ростом нагрузки открываются проблемы:
- Ни один, даже самый мощный, сервер больше не справляется в одиночку.
- Нагрузка растёт, а в датацентре нет места для нового оборудования.
- Падение датацентра безоговорочно приводит к даунтайму.
- Сетевой сбой выводит портал из строя.
- Пользователи в удалённых регионах страдают от низкой скорости.
Я без прикрас расскажу вам, как мы в Одноклассниках решаем эти проблемы. Поговорим о следующем:
- CDN - каким пользователям важен, его архитектура, устройство наших CDN-приложений, что происходит при авариях.
- Датацентры - почему мы используем три основных датацентра, где они расположены (и почему именно там), распределение пользовательского трафика между ними.
- Сеть - как и до чего мы балансируем трафик.
- Балансировщики - как мы используем LVS, почему (и в каких случаях) используем и другие решения. Что делаем с приложениями, которые нельзя ставить за балансировщик.
- Модули портала - о балансировке в нашем RPC протоколе, о том, что происходит с Одноклассниками при падении датацентра.
Кит на службе у человека microPaaS Deis / Алексей Медведчиков (2ГИС)Ontico
Всем, кто сталкивался с запуском веб-сервисов, хорошо знакомы вопросы, возникающие при выпуске нового продукта:
- нужно создать вируталки/залить сервера;
- нужно обеспечить мониторинг сервиса;
- обеспечить zero-downtime обновление приложения;
- ... ещё 100500 разных задач.
Зачастую эти задачи решаются либо руками, либо различными связками систем управления конфигурацией и деплойментом.
Мы нашли способ, значительно сокративший время на запуск новых приложений — веб-платформа Deis. Она построена на Docker и CoreOS и представляет собой легковесный PaaS, похожий на Heroku. Подходы, используемые при работе с Deis, облегчают внедрение CD/CI, уменьшают разрыв между dev/stage и production окружениями, уменьшают время на поддержку приложений.
Мы поговорим о проблемах, перечисленных выше, о том, какой путь пройден нами до продакшна, и о том, какие проблемы Deis не решает.
Доклад будет полезен как для Ops, которым хочется автоматизировать типичные задачи вокруг деплоя/обновления веб-сервиса, так и для Dev, которые могут увидеть потенциальную возможность ускорения доставки багфиксов/фич на бой.
Я хочу рассказать о том, как хостятся веб-приложения, в т.ч. друпал, об индустрии хостинга в целом и о последних трендах в этой сфере, в частности - это контейнерная виртуализация приложений Docker, которая в настоящее время изменяет всю индустрию хостинга.
Подписывайтесь на нас!
VK: https://vk.com/drupalsib
FB: https://facebook.com/groups/drupalsib
Twitter:
https://twitter.com/SibDrupalCamp
https://twitter.com/DrupalSib
Instagram: https://instagram.com/drupalsib
За счет чего Tarantool такой оптимальный / Денис Аникин (Mail.Ru)Ontico
Многие из вас, наверное, видели результаты тестов сравнения Tarantool с остальными СУБД, которые показывают, что Tarantool быстрее всех, оптимальней по памяти, обрабатывает наибольшее количество транзакций в секунду.
И, несмотря на то, что исходные коды всех тестов полностью открыты и хорошо откомментированы, позволяя всем желающим повторить тесты, все равно остаются вопросы - за счет чего Tarantool такой быстрый и оптимальный?
Я решил суммировать мои ответы на эти вопросы в докладе на Highload++.
Итак, почему Tarantool такой быстрый?
Краткий ответ: потому что он с самого начала разрабатывался и до сих пор разрабатывается во главе угла с производительностью/оптимальностью/минимальным потреблением всех ресурсов системы.
Более полный ответ я раскрою в своем выступлении. Приходите, будет интересно! :)
Что нового в nginx? / Максим Дунин (Nginx, Inc.)Ontico
Что нового появилось в nginx за последнее время и для чего всё это нужно?
В докладе - рассказ про основные новые функции в nginx 1.9.x (1.10.x) и 1.11.x. HTTP/2, модуль stream, динамическая загрузка модулей и так далее - зачем всё это нужно и как это использовать.
Читаем CHANGES вместе и разбираем на примерах.
DPDK в виртуальном коммутаторе Open vSwitch / Александр Джуринский (Selectel)Ontico
Intel DPDK (Data Plane Development Kit) — набор драйверов и библиотек, позволяющих приложениям взаимодействовать с сетевым устройством напрямую, минуя сетевой стек Linux. Это значительно увеличивает скорость обработки пакетов. DPDK интегрируется с рядом популярных программных решений, например, c виртуальным коммутатором Open vSwitch.
Возможностям и перспективам использования связи Open vSwitch + DPDK в облачных проектах и будет посвящен наш доклад. Мы подробно остановимся на проведённых тестах производительности и интерпретируем их результаты. Отдельное внимание будет уделено анализу трудностей и ограничений, с которыми пришлось столкнуться в ходе экспериментов.
JS Lab2017_Виталий Лебедев_Практические сложности при разработке на node.js GeeksLab Odessa
JS Lab2017, 25 марта, Одесса
Виталий Лебедев (Software Developer at DataArt)
Практические сложности при разработке на node.js
В этом докладе я расскажу, с какими непосредственными практическими сложностями можно встретиться при разработке на node.js, в силу тех или иных ограничений самого node.js, и какие для этих задач существуют возможные решения.
Все материалы: http://jslab.in.ua/
Организаторы: http://geekslab.org.ua/
DC/OS – больше чем PAAS, Никита Борзых (Express 42)Ontico
Доклад про ближайшее будущее в эксплуатации распределённых систем.
Компания Mesosphere весной 2016 сделала свою платформу DC/OS (data center operation system) бесплатной и открытой. Платформа DC/OS унифицирует и упрощает процесс поставки и эксплуатации систем.
Основными особенностями платформы являются:
– переход от host centric к resource centric подходу для всех компонентов вашего проекта за счёт представления серверов как ресурсов для приложения (с помощью mesos и marathon);
– наличие инструментов автоматического восстановления вашего проекта после аварии;
– marketplace для приложений. Например, можно развернуть MySQL, Elasticsearch, Kafka или mongodb кластер, используя готовые скрипты развертывания. Процесс развертывания кастомизируется, в случае необходимости можно описать кастомные приложения и поправить скрипты существующих;
– наличие API для интеграции в ваши системы CI/CD, мониторинга, и т.д.
Основные компоненты DC/OS:
– Apache Mesos — абстракция над датацентром, которая представляет сервера (физические и виртуальные) как ресурсы и распределяет эти ресурсы на основании данных о потребностях приложения;
– Marathon — система распределённого запуска приложений (в т.ч. docker контейнеров), основной фишкой является возможность декларативного описания вашей системы. Вы можете описать, сколько ресурсов нужно вашему приложению, зависимости между приложениями, и в каком порядке производить деплой.
Доклад разбит на три части:
– Интро про DC/OS, сравнение с kubernetes и coreos стеком;
– Рассказ про компоненты mesos и marathon, как их можно использовать с докером (и без!) уже сейчас;
– Опыт Express 42. Мы построили CI/CD платформу для приложений, с использованием Mesos, Marathon, Docker и Jenkins 2.0.
Горизонтальное масштабирование: что, зачем, когда и как /Александр Макаров (Y...Ontico
Масштабирование — способность наращивать систему для обработки большего количества трафика, не теряя при этом пользовательские качества: скорость и отзывчивость.
Масштабирование различают двух типов: вертикальное (больше памяти, диска, лучше процессор) и горизонтальное (больше серверов в кластере).
- Зачем оно нужно, если и так всё работает?
- Когда? Мониторинг, необдуманные решения, оптимизация и жизнь с одним сервером.
- Типичная схема.
- Балансировка нагрузки.
- Какие, вообще, проблемы на стороне приложения?
- Почему PHP так хорош для масштабирования.
- Сессии.
- База данных.
- Файлы.
- Как быть со статистикой?
Депрокрастинируем Docker: контейнеры здесь и сейчасRuslan Sharipov
Депрокрастинируем Docker: контейнеры здесь и сейчас (мастер-класс). Руслан Шарипов (7bits), Денис Нелюбин (Avelix).
При подходе к любому важному делу или к изучению интересной технологии очень важно сделать первый шаг. Этот шаг может быть совсем шажочком, небольшим движением вперёд, но, часто бывает, что именно такие шаги позволяют добиваться завершения дел до конца.
В последнее время часто наши коллеги и знакомые грозятся погуглить, изучить, разобраться, исследовать, ознакомиться, попробовать, начать использовать Docker, и постоянно откладывают это дело в долгий ящик. Кто-то боится новизны технологии, кто-то хочет задать тонну вопросов, а кто-то просто не понимает, нужна ли технология для него.
В рамках этого мастер класса мы сделаем первый шаг к тому, чтобы попробовать на практике то, что есть сейчас Docker. Мы рассмотрим, что у него под капотом: какие технологии стоят за популярным названием, как работает Docker изнутри, обсудим и научимся использовать на практике контейнеры, registry и инструменты, упрощающие процесс доставки и запуска контейнеров на серверах, обсудим и найдём решения для возникающих проблем, напишем тесты и научимся тестировать инфраструктуру в контейнерах.
Presented: 6th June, 2015
Лучшие практики Continuous Delivery с Docker / Дмитрий Столяров (Флант)Ontico
Потребность в отстроенном процессе Continuous Delivery встает перед каждым развивающимся highload-проектом. Чем больше серверов и составных приложений, чем выше динамика релизов, тем раньше проект сталкивается с данной потребностью, и тем острее она стоит.
Многие команды эксплуатации смогли отстроить этот процесс, некоторые добились впечатляющих результатов, а некоторые — потерпели неудачу. Но все из них знают, что их процесс можно улучшить: сделать быстрее, надежнее, предсказуемее и удобнее.
В этом докладе я хочу обобщить и систематизировать лучшие практики построения процесса Continuous Delivery с использованием актуальных Open Source технологий (Docker, Chef, Gitlab, Kubernetes), а также обозначить известные проблемы и потенциальные пути их решения.
Будет предпринята попытка однозначно ответить на следующие практические вопросы:
- Почему пора всем переходить на Docker? Как лучше собирать Docker-образы? Как лучше доставлять и хранить Docker-образы?
- Как правильно построить процесс разработки Infrastructure as Code (IaC)?
- Как оптимально интегрировать автоматическое и ручное тестирование в процесс Continuous Delivery?
- Как перестать бояться регулярных выкатов новых версий и сделать этот процесс надежным?
- Почему Continuous Delivery не заканчивается релизом новой версии и зачем нужен Kubernetes?
LuaJIT как основа для сервера приложений - проблемы и решения / Игорь Эрлих (...Ontico
С того момента, как было принято решение использовать язык Lua в качестве языка описания бизнес-логики в нашей платформе, прошло уже больше восьми лет. Проекты росли, данных становилось больше, возрастала нагрузка на сервера приложений. Со временем у нас накопился солидный багаж знаний о том, как устроен LuaJIT, с какими проблемами можно столкнуться при его использовании и как эти проблемы можно решать.
Я расскажу про то...
* Почему при миграции с x86 на x64 доступной памяти в LuaJIT становится меньше, и как мы с этим боролись.
* Как загрузить в LuaJIT несколько миллионов объектов и не умереть в тормозах от сборщика мусора.
* Насколько ужасна встроенная функция хеширования строк и почему иногда надо жертвовать производительностью в пользу качества.
Платформа для видео сроком в квартал. Александр Тоболь.odnoklassniki.ru
A talk from jokerconf.com conference. "Video Platform in 3 months. Delivered." by Alexander Tobol.
Доклад не затронет какую-то особенную технологию или волшебный алгоритм. Речь пойдет о том, как чуть больше чем за квартал совсем небольшая команда перезапустила работающий в режиме 24/7 совсем немаленький видео-сервис на Одноклассниках на написанной с нуля платформе, развернутой на парке из свыше 200 серверов, распределенных между несколькими центрами обмена данными.
Я бы хотел поделиться успехами и неудачами в ходе решения задачи по обеспечению бесперебойных загрузки, трансформации, хранения, раздачи видео и мониторинга, а также остановиться на особенностях, связанных с нагрузкой в 1000 просмотров в секунду, размером ежедневной аудитории в 8 миллионов географически распределенных в и за пределами РФ. Я также остановлюсь на некоторых использованных нами технологиях.
Балансировка нагрузки и отказоустойчивость в ОдноклассникахOntico
Главная → Тезисы и презентации
Балансировка нагрузки и отказоустойчивость в Одноклассниках Системное администрирование
Доклад принят в Программу конференции
Никита Духовный
Одноклассники
Ведущий системный администратор в Одноклассниках. Начинал IT-карьеру разработчиком, занимался релиз инженерией, выбрал системное администрирование.
Возглавляет одну из команд. Занимается задачами, обеспечивающими работу портала - автоматизацией, запуском новых решений, поддержкой инфраструктуры. Ведёт несколько хардкорных проектов, в том числе - по повышению отказоустойчивости портала.
Тезисы
Проект Одноклассники начинал свою жизнь в одном датацентре.
С ростом популярности растёт и нагрузка. С ростом нагрузки открываются проблемы:
- Ни один, даже самый мощный, сервер больше не справляется в одиночку.
- Нагрузка растёт, а в датацентре нет места для нового оборудования.
- Падение датацентра безоговорочно приводит к даунтайму.
- Сетевой сбой выводит портал из строя.
- Пользователи в удалённых регионах страдают от низкой скорости.
Я без прикрас расскажу вам, как мы в Одноклассниках решаем эти проблемы. Поговорим о следующем:
- CDN - каким пользователям важен, его архитектура, устройство наших CDN-приложений, что происходит при авариях.
- Датацентры - почему мы используем три основных датацентра, где они расположены (и почему именно там), распределение пользовательского трафика между ними.
- Сеть - как и до чего мы балансируем трафик.
- Балансировщики - как мы используем LVS, почему (и в каких случаях) используем и другие решения. Что делаем с приложениями, которые нельзя ставить за балансировщик.
- Модули портала - о балансировке в нашем RPC протоколе, о том, что происходит с Одноклассниками при падении датацентра.
Кит на службе у человека microPaaS Deis / Алексей Медведчиков (2ГИС)Ontico
Всем, кто сталкивался с запуском веб-сервисов, хорошо знакомы вопросы, возникающие при выпуске нового продукта:
- нужно создать вируталки/залить сервера;
- нужно обеспечить мониторинг сервиса;
- обеспечить zero-downtime обновление приложения;
- ... ещё 100500 разных задач.
Зачастую эти задачи решаются либо руками, либо различными связками систем управления конфигурацией и деплойментом.
Мы нашли способ, значительно сокративший время на запуск новых приложений — веб-платформа Deis. Она построена на Docker и CoreOS и представляет собой легковесный PaaS, похожий на Heroku. Подходы, используемые при работе с Deis, облегчают внедрение CD/CI, уменьшают разрыв между dev/stage и production окружениями, уменьшают время на поддержку приложений.
Мы поговорим о проблемах, перечисленных выше, о том, какой путь пройден нами до продакшна, и о том, какие проблемы Deis не решает.
Доклад будет полезен как для Ops, которым хочется автоматизировать типичные задачи вокруг деплоя/обновления веб-сервиса, так и для Dev, которые могут увидеть потенциальную возможность ускорения доставки багфиксов/фич на бой.
Я хочу рассказать о том, как хостятся веб-приложения, в т.ч. друпал, об индустрии хостинга в целом и о последних трендах в этой сфере, в частности - это контейнерная виртуализация приложений Docker, которая в настоящее время изменяет всю индустрию хостинга.
Подписывайтесь на нас!
VK: https://vk.com/drupalsib
FB: https://facebook.com/groups/drupalsib
Twitter:
https://twitter.com/SibDrupalCamp
https://twitter.com/DrupalSib
Instagram: https://instagram.com/drupalsib
Docker on a local machine and Docker in production — are two big differences. It's easy to play with technology but it's hard to do something real for many customers.
Half a year ago inside of Alpha Laboratory (division of Alfa-Bank) we've started building new microservices architecture for one of our pilot projects. We've almost completely changed a stack of the used technologies on a frontend and significantly changed it on a middle layer. For package and distribution we have choosen Docker. Two months ago we've deployed project to production and have opened service for clients.
In the report the following topics will be covered:
- reasons of a choice Docker;
- why Docker without other tools is not enough for a production;
- what stack of technologies we used in our solution;
- what advantages we've got;
- what problems have been faced and how we've solved them.
— Краткий экскурс в предыдущие доклады;
- Описание нашей системы сбора статистики с контейнеров и рассказ почему мы решили отказаться от cadvisord;
- Автоматическая система сборки контейнеров и интеграция с teamcity;
— Наброс о системе генерации и хранения конфигураций.
Virtual machines are generally considered secure. At least, secure enough to power highly multi-tenant, large-scale public clouds, where a single physical machine can host a large number of virtual instances belonging to different customers. Containers have many advantages over virtual machines: they boot faster, have less performance overhead, and use less resources. However, those advantages also stem from the fact that containers share the kernel of their host, instead of abstracting a new independent environment. This sharing has significant security implications, as kernel exploits can now lead to host-wide escalations.
We will show techniques to harden Linux Containers; including kernel capabilities, mandatory access control, hardened kernels, user namespaces, and more, and discuss the remaining attack surface.
Управление ресурсами в Linux и OpenVZ Кирилл Колышкин kir@openvz.org http://openvz.org/
Отчет - http://yourcmc.ru/wiki/RootConf_2009:_%D0%9E%D1%82%D1%87%D1%91%D1%82_%D0%92%D0%B8%D1%82%D0%B0%D0%BB%D0%B8%D1%8F_%D0%A4%D0%B8%D0%BB%D0%B8%D0%BF%D0%BF%D0%BE%D0%B2%D0%B0#.D0.A3.D0.BF.D1.80.D0.B0.D0.B2.D0.BB.D0.B5.D0.BD.D0.B8.D0.B5_.D1.80.D0.B5.D1.81.D1.83.D1.80.D1.81.D0.B0.D0.BC.D0.B8_.D0.B2_Linux_.D0.B8_OpenVZ_.28.D0.B7.D0.B0.D1.87.D1.91.D1.82.21.29
Дмитрий Лазаренко-«Живая миграция и отказоустойчивость контейнеров в гибридно...Tanya Denisyuk
"Контейнеры могут динамически появляться и исчезать, являются легковесными, не резервируют все необходимые ресурсы при старте, потому их оркестрация дается не простой ценой. Каждый из виртуальных контейнеров в один момент времени может потребовать максимум доступных ему ресурсов и это может привести к тому, что закончатся все ресурсы на физическом сервере, на котором они размещаются. В докладе мы поговорим о механизме, который решает эту непростую задачу, и умеет проводить непрерывную балансировку нагрузки, перемещать контейнеры с одного физического сервера на другие для проведения технических работ без простоя приложений - умная живая миграция (Smart Live Migration).
Многие считают, что контейнеры не подходят для хранения важных данных, т.к. в любой момент они могут упасть и все данные пропадут навсегда. Мы расскажем как этого избежать с помощью технологии Software-defined-storage."
Корпоративный Linux: осваиваем с нуля Red Hat Enterprise LinuxSkillFactory
Никита Войтов – ведущий инструктор SkillFactory по направлению Linux – об особенностях и преимуществах корпоративного стандарта ОС Linux – Red Hat Enterprise.
В нашей большой компании мы столкнулись с задачей выкладывания релизов наших проектов на несколько групп серверов по нескольким сотням машин.
Мы решили разработать свой софт для удобного деплоя, поскольку задача, на мой взгляд, достаточно сложная, потому что каждая секунда при выкатке решает очень многое.
Почему именно разработать что-то свое, а не использовать что-то готовое, например, Fabric или Capistrano?
Все просто:
1. Система должна быть написана на языке, на котором принято разрабатывать в компании.
2. Все возникающие трудности и проблемы должны быть решены в кратчайшие сроки, нет времени ждать пока чья-то техподдержка прилетит на помощь на голубом вертолете :)
3. Система должна быть безопасна, полностью с открытыми кодами для безопасников.
4. Минимизированы зависимости от внешних модулей.
Вкратце расскажу о том, как мы раскладываем front-end для наших проектов в Mail.ru Group в продакшн и на тестовые сервера.
В частности, расскажу, как мы собираем версточный релиз.
Расскажу о том, как его запаковать и как аккуратно раздать на несколько сотен серверов.
Расскажу об архитектуре мониторинга системы обновлений, а также покажу, как выглядит наш дашборд, по которому мы понимаем, что все хорошо.
Отвечу на все интересующие вас вопросы и дам несколько рекомендаций, которые помогут вам обойти подводные грабли, на которые наступали мы.
Модным ныне словом «виртуализация» сейчас называют различные обёртки аппаратной виртуализации, однако этот термин намного старше и более всеохватывающий. На уровне ознакомления с технологией мы поговорим о виртуализации ресурсов в кластере и на примере pacemaker.
Занятие в Школе Сисадмина.
Основано на http://www.slideshare.net/IlyaAlekseyev/openstack-12003939
Событие: https://vk.com/shkola_sysadm
Лектор: https://vk.com/vse_v_moei_golove
Вадим Мадисон "Опыт разработки через микросервисы"Tanya Denisyuk
Мы начали разработку через микросервисы когда это еще не было трендом, было не ясно - это реально работающий подход или просто очередная модная штука. Не было понимания как это делать правильно, где подводные камни и что за одним словом “микросервисы” по факту стоит куча всего, что придется узнать, изучить и понять.
Сейчас у нас большой парк микросервисов, но оперировать ими становится все проще - сказывается опыт.
В ходе доклада я поделюсь основными моментами в разработке микросервисов, расскажу как это делаем мы и что для этого используем.
Rapid Deployment of Hadoop Development EnvironmentsAndrei Nikolaenko
Development of Hadoop-related project in DevOps culture with Hadoop distributions, management and configuration tools and modern container virtualization capabatilites
Slides about DDoS detection tool. IPFIX, sFlow, Netflow support. Instant detection. Complete API and command line tools.
Free trial: https://fastnetmon.com/trial/
Flowspec contre les attaques DDoS : l'expérience danoisePavel Odintsov
RÉSUMÉ
Au sein de DeiC, le réseau de recherche au Danemark, nous avons développé un service de protection contre les attaques DDoS qui est basé sur la distribution des règles firewall vers les routeurs de bordure par le biais de BGP FlowSpec.
Par rapport aux solutions alternatives, cette méthode a un coût très réduit puisqu'elle est basée sur des composants open source uniquement.
Dans cette phase du projet la détection des attaques est faite au moyen de FastNetMon, mais grâce aux interfaces ouvertes, d'autres outils IDS peuvent être utilisés.
Nous présenterons un retour d'expérience pour ce service qui est actuellement en cours de déploiement au sein de DeIC.
1. Использование контейнеризации
в среде массового хостинга
Павел Одинцов
Технический директор FastVPS
pavel.odintsov@gmail.com
fastvps.ru
pavel.odintsov@gmail.com
2. Схема контейнеры
Из чего состоят контейнеры?
Управляющее ПО
Ядро
fastvps.ru
pavel.odintsov@gmail.com
3. Ядро
Ядерная составляющая
PID namespace
Network namespace
Memory cgroup
Mount namespace
User namespace
CPU cgroup
IPC namespace
UTS namespace
Blkio cgroup (disk)
fastvps.ru
pavel.odintsov@gmail.com
7. Изоляция
В чем особенности задачи изоляции?
Известно, какое ПО у нас работает в контейнере
!
Есть возможность оценки, какие типы ресурсов и в каком количестве требует ПО
!
Имеется доступ к конфигурации для оптимизации ПО
!
Имеется возможность регулярного обновления ПО
!
Использование заведомо более-менее адекватного ПО
fastvps.ru
pavel.odintsov@gmail.com
8. VPS/VDS
В чем особенности VPS/VDS?
• Мы не знаем ничего о типе нагрузки и требуемых ресурсах
• Мы не имеем доступа к конфигурации
• Безопасность на очень низком уровне - велика вероятность полной компрометации
• Возможна спланированная «атака» на ресурсы (исчерпание памяти, дисковых ресурсов)
• Возможна спланированная «атака» на безопасность / устойчивость сервиса
• Высокая вероятность входящих DoS/DDoS атак
• Высокая вероятность исходящих DoS/DDoS атак, а также иной зловредной активности
• Необходимость предоставить полноценную Linux среду, а не только «частичную»
изоляцию
fastvps.ru
pavel.odintsov@gmail.com
9. Проблемы
Проблемы Linux Upstream Containers
• Проблемы в изоляции ресурсов, например, ioctl и многие опасные syscall не изолированы
• Нет полной изоляции proc fs
• Нет возможности гранулированного контроля за расходом ресурсов IPC, памяти, сокетов, буферов
ядра. Как следствие - возможность достижения лимита для хост-сервера.
• Отсутствие удобной в эксплуатации реализации файловых систем для контейнеров
• Отсутствие Live Migration (Update от 23 января 2013: рабочий прототип: https://github.com/xemul/
p.haul)
• Нет возможности ограничить число процессов (process counter cgroup так и не принята в ядро)
fastvps.ru
pavel.odintsov@gmail.com
10. OpenVZ
OpenVZ - отсутствие проблем
•Нет проблем в изоляции ресурсов, напимер, ioctl и многие опасные syscall изолированы
•Есть полная изоляция proc fs
•Есть возможности гранулированного контроля за расходом ресурсов IPC, памяти,
сокетов, буферов ядра
•Есть удобная в эксплуатации реализации файловая система для контейнеров - ploop
•Есть Live Migration
•Есть возможности ограничить число процессов
fastvps.ru
pavel.odintsov@gmail.com
11. Наши будни
Атаки на контейнеризацию
• Входящие DDoS атаки (от 10 kpps до1 Mpps, до 3-5 Gbps и более). От деградции сети на хост-сервере до перегрузки
оборудования Дата Центра
• Исходящие DDoS атаки (от 50 000 пакетов/секунду и более). Приводит к сильной деградации производительности
сети
• Попытки размещения командных центров ботнетов. Деградация сети где-то на 50-100 серверах сторонних компаний
• Форк бомбы или сбои ПО приводящие к аналогичному эффекту.
• Перегрузка iptables conntrack сервера при некорректной конфигурации фаерволла либо при очень высоком трафике
на сервис. Приводит к полной недоступности всего сервера
• Баги ядра
fastvps.ru
pavel.odintsov@gmail.com
12. OpenVZ FastVPS
OpenVZ в FastVPS - цифры
• 2 Дата Центра
• Около 200 хост-серверов
• Десятки тысяч контейнеров
• 30 различных дистрибутивов ОС
• 60 фич риквестов и баг репортов в проект OpenVZ
fastvps.ru
pavel.odintsov@gmail.com
13. OpenVZ FastVPS
OpenVZ в FastVPS - технологии
• Дистрибутив: CentOS 5/CentOS 6
• Ядро: OpenVZ 2.6.32 актуальной версии (если у вас 2.6.18 - срочно обновитесь!)
• Файловая система: ext4 (и местами ext3)
• Тип OpenVZ дисков: simfs, ploop
• Тип используемого контроллера ресурсов: UBC совместно с vSWAP
• VzAPI - собственное решение на Go для управления контейнерами OpenVZ по
сети с использованием REST/JSON/SSL
fastvps.ru
pavel.odintsov@gmail.com
14. Будущее
Что мы хотим от контейнеров в будущем?
•Большего уровня изоляции и возможность максимально гранулированного контроля всех ресурсов
•Дружбы между всеми контейнеризациями! :)
•Общего формата шаблонов ОС для контейнеризации: https://github.com/containers/container-rfc
•Эффективной системы хранения для контейнеров (даже ploop из OpenVZ имеет ряд проблем)
•Динамического распределения ресурсов
•Более крутого user space средства для управления и мониторинга
•Отсутствия полноценного Linux дистрибутива на хост-сервере, возможно, загрузка по сети или упрощенный root fs, см. CoreOs
•Проблемы с файловыми системами и централизованным хранением
•Контейнеров работающих не нескольких севрерах
•Сетевых (и распределенных) файловых систем (кто внимательный приглашаем на тест: https://openvz.org/Pstorage)
fastvps.ru
pavel.odintsov@gmail.com
15. Информация
Что можно почитать еще?
•http://OpenVZ.org - официальный сайт проекта
•http://www.slideshare.net/kolyshkin/ - Презентации от Кирилла Колышкина
•Контейнеры — это будущее облаков: http://habrahabr.ru/company/FastVPS/blog/208650/
•Контейнеризация на Linux в деталях — LXC и OpenVZ. Часть 1: http://habrahabr.ru/company/FastVPS/
blog/209072/
•Контейнеризация на Linux в деталях — LXC и OpenVZ Часть 2: http://habrahabr.ru/company/FastVPS/
blog/209084/
•http://LWN.net - общие новости из мира ядра Linux
fastvps.ru
pavel.odintsov@gmail.com