Хостинг для Drupalна примере www.forbes.ru

Тарас Савчукtaras (ухо) 1adm.ruhttp://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, 2 Kqps в среднем.

Текущая ситуация

Физические параметры 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 – производительность сравнима c Boost• мало опыта

CARP

carp2carp1

ДЦ

#sysctl net.inet.carp.preempt=1

213.145.46.183

10.10.10.1

LAN

CARP

carp2

ДЦ

#sysctl net.inet.carp.preempt=1

213.145.46.183

10.10.10.1

213.145.46.183

10.10.10.1

carp1

LAN

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

fs-1-14 (jail)

web1

fs-2-14 (jail)

web2

carp1 carp2

- одностороння синхронизация

- двусторонняя синхронизация

Что такое 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-drupal

db1

db2-drupal

db2

- Направление репликации

- MySQL in jail (master)

db1-bitrix db2-bitrix

- MySQL in jail (slave)

db-drupal-rw (IP))

db-bitrix-rw (IP))

- Подключения к БД

Сеть

• 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• профиль производительности (универсально, имеет

смысл автоматизировать и пользоваться ежедневно)• помогает понять, где оптимизировать

Профиль производительности

0 0.5 1 1.5 2 2.5 3 3.50

20

40

60

80

100

120

81.66

93.9999 99.9

Время обработки запроса, секунды

% з

апро

сов

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.ruhttp://www.1adm.ru

Генеральный спонсор и организатор конференции DrupalConf 2011

При поддержке:

Спонсоры

Информационные спонсоры

Сайт конференции