SlideShare a Scribd company logo

Hosting for forbes.ru_

•Download as PPTX, PDF•
•
D
drupalconf

Related slideshows

Путь от монолита на PHP к микросервисам на Scala / Денис Иванов (2GIS)
Путь от монолита на PHP к микросервисам на Scala / Денис Иванов (2GIS)Путь от монолита на PHP к микросервисам на Scala / Денис Иванов (2GIS)
Путь от монолита на PHP к микросервисам на Scala / Денис Иванов (2GIS)
 
Архитектура HAWQ / Алексей Грищенко (Pivotal)
Архитектура HAWQ / Алексей Грищенко (Pivotal)Архитектура HAWQ / Алексей Грищенко (Pivotal)
Архитектура HAWQ / Алексей Грищенко (Pivotal)
 
MySQL 5.7 - NoSQL - JSON, Protocol X, Document Store / Петр Зайцев (Percona)
MySQL 5.7 - NoSQL - JSON, Protocol X, Document Store / Петр Зайцев (Percona)MySQL 5.7 - NoSQL - JSON, Protocol X, Document Store / Петр Зайцев (Percona)
MySQL 5.7 - NoSQL - JSON, Protocol X, Document Store / Петр Зайцев (Percona)
 
1 of 30
Хостинг для Drupal на примере www.forbes.ru Тарас Савчук taras (ухо)1adm.ru http://www.1adm.ru
Генеральный спонсор и организатор конференции DrupalConf 2011 При поддержке:
Спонсоры Информационные спонсоры Сайт конференции
Постановка задачи Задача (2009-й год) - Drupal 6 - прогноз нагрузки 10M хитов в месяц -два сервера под проект (DL360G6) -производительность, масштабируемость, отказоустойчивость Наследие - 4 сервера (FreeBSD 7/amd64) - web-проекты: - http://www.runewsweek.ru -http://www.ok-magazine.ru -http://www.computerbild.ru -http://www.axelspringer.ru
Текущая ситуация Средние параметры нагрузки (3 месяца) Трафик: 3-4 Тб/месяц, 1.5 Мб/c отдача Front-end: 130 запросов в секунду, 1К активных подключений MySQL: 1.6 Kqps Последний пик посещаемости (15-е апреля) Трафик: отдали 270Гб+, 9Мб/с – упираемся в канал Front-end: 50M+ запросов (включая статику), до 1700 запросов в секунду, до 10К активных подключений Back-ends: 2.2M+и 1.5M+ запросов MySQL: до 20Кqps, 2Kqpsв среднем.
Текущая ситуация Физические параметры www.forbes.ru Объем кода + медиафайлов: 16 Гб Количество файлов (код + медиафайлы): ~ 110К Размер базы: 3 Гб Кол-во записей в базе: 20 М
Принципы построения 1. Хостинг под «стандартные» web-проекты нет гигантских объемов медиафайлов и огромных баз 2. Общая площадка, максимальная утилизация разместить старые проекты, Форбс, будущие проекты 3. Нужно изолировать проекты друг от друга безопасность, разные разработчики/подрядчики, совместимость ПО 4. Shared-nothing, не надеемся на железо не должно быть единой точки отказа 5. Не менять платформу (FreeBSD) без весомых причин 6. KISS, не гнаться за девятками слишком сильно минимум непроверенных технологий
Разделяй и властвуй 1. Front-ends (2 минимум) • балансировка нагрузки между back-ends, failover для back-ends • кэширование, отдача статики • межсетевой экран • расширяемость, отказоустойчивость 2. Back-ends (2 минимум) • код (PHP/Drupal, но может быть что угодно) • расширяемость, отказоустойчивость, режим активный-активный • изоляция web-проектовдруг от друга 3. Сервера БД (2 минимум) • расширяемость, отказоустойчивость • резервное копирование 4. Сеть • отказоустойчивость
Front-ends 1. Общий IP-адрес (или адреса) • на DNS полагаться не можем • CARP (Common Address Redundancy Protocol)во FreeBSD“из коробки” • pf - удобно и функционально • идентичные nginx на обоих front-ends 2. Кэширование/балансировка/отдача статики (nginx) • ngx_http_proxy_module • proxy_store – борьба с новыми и меняющимися файлами • ngx_http_upstream (ip_hash, backup, down) – балансировка, failover • ngx_http_limit_zone_module – ограничение числа подключений • ngx_http_limit_req_module – ограничение числа запросов • удобные логи (профиль производительности сайта) 3. Альтернативы: Varnish, HAProxy • для Varnish нужен Pressflow/патч для Drupal 6/Drupal 7 • Varnish/HAProxy – только proxy/балансировка (пусть и хорошая) • Varnish – производительность сравнима cBoost • мало опыта
CARP ДЦ 213.145.46.183 carp1 carp2 10.10.10.1 LAN #sysctlnet.inet.carp.preempt=1
CARP ДЦ 213.145.46.183 213.145.46.183 carp1 carp2 10.10.10.1 10.10.10.1 LAN #sysctlnet.inet.carp.preempt=1
Back-ends: изоляция проектов 1. Почему FreeBSD jails? • лѐгкие • «из коробки» • ezjail – просто и удобно 2. Альтернативы: Xen, OpenVZ, etc. • Xen – тяжѐлый • OpenVZ, Linux-VServer – патченное ядро, лишний функционал 3. Что такое ezjail? • никаких зависимостей, только shell • быстрое создание • резервное копирование, восстановление • шаблоны • ограничение ресурсов (cpuset)
Как выглядит ezjail?
Back-ends: общий DocRoot 1. Почему csync^2? • shared-nothing, узлы полностью независимы • прост и эффективен • подходит для репликации между ДЦ • триггеры (одно решение для данных и конфигураций) • работаем с локальной ФС, которую мы «умеем готовить» 2. Альтернативы: DRBD, GFS(2), OCFS(2), GlusterFS, etc… • DRBD – только primary-secondary • DRBD + GFS/OCFS2 (primary-primary) – сложно • нет боевого опыта, сложность, пугают потенциальные проблемы производительности, совместимость
Схема работы csync^2 carp1 carp2 web1 web2 fs-1-14 (jail) fs-2-14 (jail) - одностороння синхронизация - двусторонняя синхронизация
Что такое csync^2? • Асинхронная синхронизация :) • Обнаружение и разрешение конфликтов • Репликация удалений • Сложные конфигурации: исключения, группы хостов, slave-режим • librsync • локальная БД (sqlite) • «проталкивает» изменения • SSL + pre-shared-keys • резервное копирование • триггеры
Производительность csync^2 • 10 минут на полную синхронизацию 40K+ файлов общим размером 500Мб • 13 секунд на проверку, что все синхронно • 22 секунды на синхронизацию новых 1400 файлов объемом 13Мб • 8 секунд на проверку, что все синхронно
Back-ends: web-сервер • Apache – совместимость • ПО, поставляемое в виде модулей Apache • модули Drupal, «заточенные» на Apache (Boost) • Apache + Boost с одной машины загружают гигабит • Можем использовать любой web-сервер и набор ПО
MySQL • Postgresql – богат, но много «но», поэтому MySQL • Отказоустойчивость для MySQL • родная репликация (master-slave) • MySQL + DRBD • MySQL Cluster • master-master с родной репликацией (circular replication) • MMM (Multi-Master Replication Manager for MySQL) • Galera – синхронная репликация (на тот момент beta) • Масштабируемость • родная репликация (master-slave) • часть запросов на slave (MySQL Proxy, Pressflow)
MySQL db1 db2 db1-drupal db2-drupal db-drupal-rw (IP)) db-bitrix-rw (IP)) db1-bitrix db2-bitrix - Подключения к БД - Направление репликации - MySQL in jail (master) - MySQL in jail (slave)
Сеть • LACP (Link Aggregation Control Protocol) • просто, но не реализовано • не нужны коммутаторы при схеме из 2-х серверов
Резюме по архитектуре • 2 front-ends (активный-пассивный), 2 back-ends (активный-активный), 2 MySQL (перекрестная репликация master-slave) • FreeBSD 7 • pf –межсетевой экран, подсчет трафика • CARP – общий IP, failover • Nginx – балансировка, кэширование • Jails – легковесная виртуализация (все в jail-ах) • csync^2 – синхронизация Document Root, конфигов • MySQL – стандартная master-slave репликация • LACP – отказоустойчивость сети (не реализовано)
Текущие задачи • Резервное копирование (mysqldump, снапшоты) • Мониторинг (Zabbix), внешний (http) и внутренний • Разработка (git, redmine, jails, нет migraine) • Оптимизация производительности • MySQL slow log, mysqldumpslow/mk-query-digest • смотрим на back-ends из nginx • Xdebug • Instrumentation.php от Percona (TODO) • Обновление ПО/модернизация железа
Профиль производительности • Логи nginx в .csv(в т.ч. $upstream_response_time) импортируем в MySQL и получаем полезные агрегированные данные • самые медленные страницы (в среднем) • самые медленные страницы (суммарно) • отчет по кодам ответа back-ends • сравнение производительности back-ends • профиль производительности (универсально, имеет смысл автоматизировать и пользоваться ежедневно) • помогает понять, где оптимизировать
Профиль производительности 120 99 99.9 100 93.99 81.66 80 % запросов 60 40 20 0 0 0.5 1 1.5 2 2.5 3 3.5 Время обработки запроса, секунды
Instrumentation от Percona • Инструментарий для экспорта полезных счетчиков в переменные Apache • Комментарии к запросам MySQL, после чего mk-query- digest • Переменные ->лог Apache -> SQL ->отчеты • Xdebugтяжелый, нет возможности агрегировать данные, не подходит для поиска редких проблем • Можно ловить проблемы mysql, memcache, чего угодно • Требуется интеграция в код (в хороший код интегрировать просто)
Планы и проблемы • Boost и csync^2– решить проблему или использовать альтернативное решение • Instrumentation от Perconaдля поиска редких проблем • Pressflow, часть запросов на slave • Второй ДЦ • Автоматизировать failover для MySQL (MMM или самостоятельно) • Избавиться или свести к минимуму кэширование Drupal в MySQL • LACP
Спасибо за внимание! Тарас Савчук taras (ухо) 1adm.ru http://www.1adm.ru
Генеральный спонсор и организатор конференции DrupalConf 2011 При поддержке:
Спонсоры Информационные спонсоры Сайт конференции

More Related Content

Hosting for forbes.ru_

  • 1. Хостинг для Drupal на примере www.forbes.ru Тарас Савчук taras (ухо)1adm.ru http://www.1adm.ru
  • 2. Генеральный спонсор и организатор конференции DrupalConf 2011 При поддержке:
  • 3. Спонсоры Информационные спонсоры Сайт конференции
  • 4. Постановка задачи Задача (2009-й год) - Drupal 6 - прогноз нагрузки 10M хитов в месяц -два сервера под проект (DL360G6) -производительность, масштабируемость, отказоустойчивость Наследие - 4 сервера (FreeBSD 7/amd64) - web-проекты: - http://www.runewsweek.ru -http://www.ok-magazine.ru -http://www.computerbild.ru -http://www.axelspringer.ru
  • 5. Текущая ситуация Средние параметры нагрузки (3 месяца) Трафик: 3-4 Тб/месяц, 1.5 Мб/c отдача Front-end: 130 запросов в секунду, 1К активных подключений MySQL: 1.6 Kqps Последний пик посещаемости (15-е апреля) Трафик: отдали 270Гб+, 9Мб/с – упираемся в канал Front-end: 50M+ запросов (включая статику), до 1700 запросов в секунду, до 10К активных подключений Back-ends: 2.2M+и 1.5M+ запросов MySQL: до 20Кqps, 2Kqpsв среднем.
  • 6. Текущая ситуация Физические параметры www.forbes.ru Объем кода + медиафайлов: 16 Гб Количество файлов (код + медиафайлы): ~ 110К Размер базы: 3 Гб Кол-во записей в базе: 20 М
  • 7. Принципы построения 1. Хостинг под «стандартные» web-проекты нет гигантских объемов медиафайлов и огромных баз 2. Общая площадка, максимальная утилизация разместить старые проекты, Форбс, будущие проекты 3. Нужно изолировать проекты друг от друга безопасность, разные разработчики/подрядчики, совместимость ПО 4. Shared-nothing, не надеемся на железо не должно быть единой точки отказа 5. Не менять платформу (FreeBSD) без весомых причин 6. KISS, не гнаться за девятками слишком сильно минимум непроверенных технологий
  • 8. Разделяй и властвуй 1. Front-ends (2 минимум) • балансировка нагрузки между back-ends, failover для back-ends • кэширование, отдача статики • межсетевой экран • расширяемость, отказоустойчивость 2. Back-ends (2 минимум) • код (PHP/Drupal, но может быть что угодно) • расширяемость, отказоустойчивость, режим активный-активный • изоляция web-проектовдруг от друга 3. Сервера БД (2 минимум) • расширяемость, отказоустойчивость • резервное копирование 4. Сеть • отказоустойчивость
  • 9. Front-ends 1. Общий IP-адрес (или адреса) • на DNS полагаться не можем • CARP (Common Address Redundancy Protocol)во FreeBSD“из коробки” • pf - удобно и функционально • идентичные nginx на обоих front-ends 2. Кэширование/балансировка/отдача статики (nginx) • ngx_http_proxy_module • proxy_store – борьба с новыми и меняющимися файлами • ngx_http_upstream (ip_hash, backup, down) – балансировка, failover • ngx_http_limit_zone_module – ограничение числа подключений • ngx_http_limit_req_module – ограничение числа запросов • удобные логи (профиль производительности сайта) 3. Альтернативы: Varnish, HAProxy • для Varnish нужен Pressflow/патч для Drupal 6/Drupal 7 • Varnish/HAProxy – только proxy/балансировка (пусть и хорошая) • Varnish – производительность сравнима cBoost • мало опыта
  • 10. CARP ДЦ 213.145.46.183 carp1 carp2 10.10.10.1 LAN #sysctlnet.inet.carp.preempt=1
  • 11. CARP ДЦ 213.145.46.183 213.145.46.183 carp1 carp2 10.10.10.1 10.10.10.1 LAN #sysctlnet.inet.carp.preempt=1
  • 12. Back-ends: изоляция проектов 1. Почему FreeBSD jails? • лѐгкие • «из коробки» • ezjail – просто и удобно 2. Альтернативы: Xen, OpenVZ, etc. • Xen – тяжѐлый • OpenVZ, Linux-VServer – патченное ядро, лишний функционал 3. Что такое ezjail? • никаких зависимостей, только shell • быстрое создание • резервное копирование, восстановление • шаблоны • ограничение ресурсов (cpuset)
  • 14. Back-ends: общий DocRoot 1. Почему csync^2? • shared-nothing, узлы полностью независимы • прост и эффективен • подходит для репликации между ДЦ • триггеры (одно решение для данных и конфигураций) • работаем с локальной ФС, которую мы «умеем готовить» 2. Альтернативы: DRBD, GFS(2), OCFS(2), GlusterFS, etc… • DRBD – только primary-secondary • DRBD + GFS/OCFS2 (primary-primary) – сложно • нет боевого опыта, сложность, пугают потенциальные проблемы производительности, совместимость
  • 15. Схема работы csync^2 carp1 carp2 web1 web2 fs-1-14 (jail) fs-2-14 (jail) - одностороння синхронизация - двусторонняя синхронизация
  • 16. Что такое csync^2? • Асинхронная синхронизация :) • Обнаружение и разрешение конфликтов • Репликация удалений • Сложные конфигурации: исключения, группы хостов, slave-режим • librsync • локальная БД (sqlite) • «проталкивает» изменения • SSL + pre-shared-keys • резервное копирование • триггеры
  • 17. Производительность csync^2 • 10 минут на полную синхронизацию 40K+ файлов общим размером 500Мб • 13 секунд на проверку, что все синхронно • 22 секунды на синхронизацию новых 1400 файлов объемом 13Мб • 8 секунд на проверку, что все синхронно
  • 18. Back-ends: web-сервер • Apache – совместимость • ПО, поставляемое в виде модулей Apache • модули Drupal, «заточенные» на Apache (Boost) • Apache + Boost с одной машины загружают гигабит • Можем использовать любой web-сервер и набор ПО
  • 19. MySQL • Postgresql – богат, но много «но», поэтому MySQL • Отказоустойчивость для MySQL • родная репликация (master-slave) • MySQL + DRBD • MySQL Cluster • master-master с родной репликацией (circular replication) • MMM (Multi-Master Replication Manager for MySQL) • Galera – синхронная репликация (на тот момент beta) • Масштабируемость • родная репликация (master-slave) • часть запросов на slave (MySQL Proxy, Pressflow)
  • 20. MySQL db1 db2 db1-drupal db2-drupal db-drupal-rw (IP)) db-bitrix-rw (IP)) db1-bitrix db2-bitrix - Подключения к БД - Направление репликации - MySQL in jail (master) - MySQL in jail (slave)
  • 21. Сеть • LACP (Link Aggregation Control Protocol) • просто, но не реализовано • не нужны коммутаторы при схеме из 2-х серверов
  • 22. Резюме по архитектуре • 2 front-ends (активный-пассивный), 2 back-ends (активный-активный), 2 MySQL (перекрестная репликация master-slave) • FreeBSD 7 • pf –межсетевой экран, подсчет трафика • CARP – общий IP, failover • Nginx – балансировка, кэширование • Jails – легковесная виртуализация (все в jail-ах) • csync^2 – синхронизация Document Root, конфигов • MySQL – стандартная master-slave репликация • LACP – отказоустойчивость сети (не реализовано)
  • 23. Текущие задачи • Резервное копирование (mysqldump, снапшоты) • Мониторинг (Zabbix), внешний (http) и внутренний • Разработка (git, redmine, jails, нет migraine) • Оптимизация производительности • MySQL slow log, mysqldumpslow/mk-query-digest • смотрим на back-ends из nginx • Xdebug • Instrumentation.php от Percona (TODO) • Обновление ПО/модернизация железа
  • 24. Профиль производительности • Логи nginx в .csv(в т.ч. $upstream_response_time) импортируем в MySQL и получаем полезные агрегированные данные • самые медленные страницы (в среднем) • самые медленные страницы (суммарно) • отчет по кодам ответа back-ends • сравнение производительности back-ends • профиль производительности (универсально, имеет смысл автоматизировать и пользоваться ежедневно) • помогает понять, где оптимизировать
  • 25. Профиль производительности 120 99 99.9 100 93.99 81.66 80 % запросов 60 40 20 0 0 0.5 1 1.5 2 2.5 3 3.5 Время обработки запроса, секунды
  • 26. Instrumentation от Percona • Инструментарий для экспорта полезных счетчиков в переменные Apache • Комментарии к запросам MySQL, после чего mk-query- digest • Переменные ->лог Apache -> SQL ->отчеты • Xdebugтяжелый, нет возможности агрегировать данные, не подходит для поиска редких проблем • Можно ловить проблемы mysql, memcache, чего угодно • Требуется интеграция в код (в хороший код интегрировать просто)
  • 27. Планы и проблемы • Boost и csync^2– решить проблему или использовать альтернативное решение • Instrumentation от Perconaдля поиска редких проблем • Pressflow, часть запросов на slave • Второй ДЦ • Автоматизировать failover для MySQL (MMM или самостоятельно) • Избавиться или свести к минимуму кэширование Drupal в MySQL • LACP
  • 28. Спасибо за внимание! Тарас Савчук taras (ухо) 1adm.ru http://www.1adm.ru
  • 29. Генеральный спонсор и организатор конференции DrupalConf 2011 При поддержке:
  • 30. Спонсоры Информационные спонсоры Сайт конференции