Хостинг для Drupal                     на примере www.forbes.ruТарас Савчукtaras (ухо)1adm.ruhttp://www.1adm.ru
Генеральный спонсор и организатор      конференции DrupalConf 2011При поддержке:
Спонсоры                      Информационные спонсорыСайт конференции
Постановка задачиЗадача (2009-й год)- Drupal 6- прогноз нагрузки 10M хитов в месяц-два сервера под проект (DL360G6)-произв...
Текущая ситуацияСредние параметры нагрузки (3 месяца)Трафик: 3-4 Тб/месяц, 1.5 Мб/c отдачаFront-end: 130 запросов в секунд...
Текущая ситуацияФизические параметры www.forbes.ruОбъем кода + медиафайлов: 16 ГбКоличество файлов (код + медиафайлы): ~ 1...
Принципы построения1. Хостинг под «стандартные» web-проекты      нет гигантских объемов медиафайлов и огромных баз2. Общая...
Разделяй и властвуй1. Front-ends (2 минимум)   •   балансировка нагрузки между back-ends, failover для back-ends   •   кэш...
Front-ends1. Общий IP-адрес (или адреса)   •   на DNS полагаться не можем   •   CARP (Common Address Redundancy Protocol)в...
CARP                         ДЦ213.145.46.183                  carp1            carp2     10.10.10.1                      ...
CARP                         ДЦ213.145.46.183                         213.145.46.183                  carp1            car...
Back-ends: изоляция проектов1. Почему FreeBSD jails?   •   лѐгкие   •   «из коробки»   •   ezjail – просто и удобно2. Альт...
Как выглядит ezjail?
Back-ends: общий DocRoot1. Почему csync^2?  •   shared-nothing, узлы полностью независимы  •   прост и эффективен  •   под...
Схема работы csync^2 carp1                     carp2 web1                      web2   fs-1-14 (jail)              fs-2-14 ...
Что такое csync^2?•   Асинхронная синхронизация :)•   Обнаружение и разрешение конфликтов•   Репликация удалений•   Сложны...
Производительность csync^2•   10 минут на полную синхронизацию 40K+ файлов    общим размером 500Мб•   13 секунд на проверк...
Back-ends: web-сервер•   Apache – совместимость    •   ПО, поставляемое в виде модулей Apache    •   модули Drupal, «заточ...
MySQL•   Postgresql – богат, но много «но», поэтому MySQL•   Отказоустойчивость для MySQL    •   родная репликация (master...
MySQL                     db1                   db2                       db1-drupal                db2-drupal   db-drupal...
Сеть•   LACP (Link Aggregation Control Protocol)    • просто, но не реализовано    • не нужны коммутаторы при схеме из 2-х...
Резюме по архитектуре•   2 front-ends (активный-пассивный), 2 back-ends    (активный-активный), 2 MySQL (перекрестная    р...
Текущие задачи•   Резервное копирование (mysqldump, снапшоты)•   Мониторинг (Zabbix), внешний (http) и внутренний•   Разра...
Профиль производительности•   Логи nginx в .csv(в т.ч. $upstream_response_time)    импортируем в MySQL и получаем полезные...
Профиль производительности             120                               99                                            99....
Instrumentation от Percona•   Инструментарий для экспорта полезных счетчиков в    переменные Apache•   Комментарии к запро...
Планы и проблемы•   Boost и csync^2– решить проблему или использовать    альтернативное решение•   Instrumentation от Perc...
Спасибо за внимание!Тарас Савчукtaras (ухо) 1adm.ruhttp://www.1adm.ru
Генеральный спонсор и организатор      конференции DrupalConf 2011При поддержке:
Спонсоры                      Информационные спонсорыСайт конференции
Upcoming SlideShare
Loading in …5
×

Hosting for forbes.ru_

1,008 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,008
On SlideShare
0
From Embeds
0
Number of Embeds
47
Actions
Shares
0
Downloads
6
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Hosting for forbes.ru_

  1. 1. Хостинг для Drupal на примере www.forbes.ruТарас Савчукtaras (ухо)1adm.ruhttp://www.1adm.ru
  2. 2. Генеральный спонсор и организатор конференции DrupalConf 2011При поддержке:
  3. 3. Спонсоры Информационные спонсорыСайт конференции
  4. 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. 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. 6. Текущая ситуацияФизические параметры www.forbes.ruОбъем кода + медиафайлов: 16 ГбКоличество файлов (код + медиафайлы): ~ 110КРазмер базы: 3 ГбКол-во записей в базе: 20 М
  7. 7. Принципы построения1. Хостинг под «стандартные» web-проекты нет гигантских объемов медиафайлов и огромных баз2. Общая площадка, максимальная утилизация разместить старые проекты, Форбс, будущие проекты3. Нужно изолировать проекты друг от друга безопасность, разные разработчики/подрядчики, совместимость ПО4. Shared-nothing, не надеемся на железо не должно быть единой точки отказа5. Не менять платформу (FreeBSD) без весомых причин6. KISS, не гнаться за девятками слишком сильно минимум непроверенных технологий
  8. 8. Разделяй и властвуй1. Front-ends (2 минимум) • балансировка нагрузки между back-ends, failover для back-ends • кэширование, отдача статики • межсетевой экран • расширяемость, отказоустойчивость2. Back-ends (2 минимум) • код (PHP/Drupal, но может быть что угодно) • расширяемость, отказоустойчивость, режим активный-активный • изоляция web-проектовдруг от друга3. Сервера БД (2 минимум) • расширяемость, отказоустойчивость • резервное копирование4. Сеть • отказоустойчивость
  9. 9. Front-ends1. Общий IP-адрес (или адреса) • на DNS полагаться не можем • CARP (Common Address Redundancy Protocol)во FreeBSD“из коробки” • pf - удобно и функционально • идентичные nginx на обоих front-ends2. Кэширование/балансировка/отдача статики (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. 10. CARP ДЦ213.145.46.183 carp1 carp2 10.10.10.1 LAN#sysctlnet.inet.carp.preempt=1
  11. 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. 12. Back-ends: изоляция проектов1. Почему FreeBSD jails? • лѐгкие • «из коробки» • ezjail – просто и удобно2. Альтернативы: Xen, OpenVZ, etc. • Xen – тяжѐлый • OpenVZ, Linux-VServer – патченное ядро, лишний функционал3. Что такое ezjail? • никаких зависимостей, только shell • быстрое создание • резервное копирование, восстановление • шаблоны • ограничение ресурсов (cpuset)
  13. 13. Как выглядит ezjail?
  14. 14. Back-ends: общий DocRoot1. Почему csync^2? • shared-nothing, узлы полностью независимы • прост и эффективен • подходит для репликации между ДЦ • триггеры (одно решение для данных и конфигураций) • работаем с локальной ФС, которую мы «умеем готовить»2. Альтернативы: DRBD, GFS(2), OCFS(2), GlusterFS, etc… • DRBD – только primary-secondary • DRBD + GFS/OCFS2 (primary-primary) – сложно • нет боевого опыта, сложность, пугают потенциальные проблемы производительности, совместимость
  15. 15. Схема работы csync^2 carp1 carp2 web1 web2 fs-1-14 (jail) fs-2-14 (jail)- одностороння синхронизация- двусторонняя синхронизация
  16. 16. Что такое csync^2?• Асинхронная синхронизация :)• Обнаружение и разрешение конфликтов• Репликация удалений• Сложные конфигурации: исключения, группы хостов, slave-режим• librsync• локальная БД (sqlite)• «проталкивает» изменения• SSL + pre-shared-keys• резервное копирование• триггеры
  17. 17. Производительность csync^2• 10 минут на полную синхронизацию 40K+ файлов общим размером 500Мб• 13 секунд на проверку, что все синхронно• 22 секунды на синхронизацию новых 1400 файлов объемом 13Мб• 8 секунд на проверку, что все синхронно
  18. 18. Back-ends: web-сервер• Apache – совместимость • ПО, поставляемое в виде модулей Apache • модули Drupal, «заточенные» на Apache (Boost) • Apache + Boost с одной машины загружают гигабит• Можем использовать любой web-сервер и набор ПО
  19. 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. 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. 21. Сеть• LACP (Link Aggregation Control Protocol) • просто, но не реализовано • не нужны коммутаторы при схеме из 2-х серверов
  22. 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. 23. Текущие задачи• Резервное копирование (mysqldump, снапшоты)• Мониторинг (Zabbix), внешний (http) и внутренний• Разработка (git, redmine, jails, нет migraine)• Оптимизация производительности • MySQL slow log, mysqldumpslow/mk-query-digest • смотрим на back-ends из nginx • Xdebug • Instrumentation.php от Percona (TODO)• Обновление ПО/модернизация железа
  24. 24. Профиль производительности• Логи nginx в .csv(в т.ч. $upstream_response_time) импортируем в MySQL и получаем полезные агрегированные данные • самые медленные страницы (в среднем) • самые медленные страницы (суммарно) • отчет по кодам ответа back-ends • сравнение производительности back-ends • профиль производительности (универсально, имеет смысл автоматизировать и пользоваться ежедневно) • помогает понять, где оптимизировать
  25. 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. 26. Instrumentation от Percona• Инструментарий для экспорта полезных счетчиков в переменные Apache• Комментарии к запросам MySQL, после чего mk-query- digest• Переменные ->лог Apache -> SQL ->отчеты• Xdebugтяжелый, нет возможности агрегировать данные, не подходит для поиска редких проблем• Можно ловить проблемы mysql, memcache, чего угодно• Требуется интеграция в код (в хороший код интегрировать просто)
  27. 27. Планы и проблемы• Boost и csync^2– решить проблему или использовать альтернативное решение• Instrumentation от Perconaдля поиска редких проблем• Pressflow, часть запросов на slave• Второй ДЦ• Автоматизировать failover для MySQL (MMM или самостоятельно)• Избавиться или свести к минимуму кэширование Drupal в MySQL• LACP
  28. 28. Спасибо за внимание!Тарас Савчукtaras (ухо) 1adm.ruhttp://www.1adm.ru
  29. 29. Генеральный спонсор и организатор конференции DrupalConf 2011При поддержке:
  30. 30. Спонсоры Информационные спонсорыСайт конференции

×