Хостинг для Drupal презентация

месяц
два сервера под проект (DL360G6)
производительность, масштабируемость, отказоустойчивость

Наследие
4 сервера (FreeBSD 7/amd64)
web-проекты:
http://www.runewsweek.ru
http://www.ok-magazine.ru
http://www.computerbild.ru
http://www.axelspringer.ru

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 в среднем.

+ медиафайлы): ~ 110К
Размер базы: 3 Гб
Кол-во записей в базе: 20 М

площадка, максимальная утилизация
разместить старые проекты, Форбс, будущие проекты
Нужно изолировать проекты друг от друга
безопасность, разные разработчики/подрядчики, совместимость ПО
Shared-nothing, не надеемся на железо
не должно быть единой точки отказа
Не менять платформу (FreeBSD) без весомых причин
KISS, не гнаться за девятками слишком сильно
минимум непроверенных технологий

отдача статики
межсетевой экран
расширяемость, отказоустойчивость
Back-ends (2 минимум)
код (PHP/Drupal, но может быть что угодно)
расширяемость, отказоустойчивость, режим активный-активный
изоляция web-проектов друг от друга
Сервера БД (2 минимум)
расширяемость, отказоустойчивость
резервное копирование
Сеть
отказоустойчивость

Protocol) во FreeBSD “из коробки”
pf - удобно и функционально
идентичные nginx на обоих front-ends
Кэширование/балансировка/отдача статики (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 – ограничение числа запросов
удобные логи (профиль производительности сайта)
Альтернативы: Varnish, HAProxy
для Varnish нужен Pressflow/патч для Drupal 6/Drupal 7
Varnish/HAProxy – только proxy/балансировка (пусть и хорошая)
Varnish – производительность сравнима c Boost
мало опыта

OpenVZ, etc.
Xen – тяжёлый
OpenVZ, Linux-VServer – патченное ядро, лишний функционал
Что такое ezjail?
никаких зависимостей, только shell
быстрое создание
резервное копирование, восстановление
шаблоны
ограничение ресурсов (cpuset)

между ДЦ
триггеры (одно решение для данных и конфигураций)
работаем с локальной ФС, которую мы «умеем готовить»
Альтернативы: DRBD, GFS(2), OCFS(2), GlusterFS, etc…
DRBD – только primary-secondary
DRBD + GFS/OCFS2 (primary-primary) – сложно
нет боевого опыта, сложность, пугают потенциальные проблемы производительности, совместимость

группы хостов, slave-режим
librsync
локальная БД (sqlite)
«проталкивает» изменения
SSL + pre-shared-keys
резервное копирование
триггеры

секунд на проверку, что все синхронно
22 секунды на синхронизацию новых 1400 файлов объемом 13Мб
8 секунд на проверку, что все синхронно

на Apache (Boost)
Apache + Boost с одной машины загружают гигабит

Можем использовать любой web-сервер и набор ПО

(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)

(slave)

db-drupal-rw (IP))

db-bitrix-rw (IP))

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

схеме из 2-х серверов

репликация master-slave)
FreeBSD 7
pf – межсетевой экран, подсчет трафика
CARP – общий IP, failover
Nginx – балансировка, кэширование
Jails – легковесная виртуализация (все в jail-ах)
csync^2 – синхронизация Document Root, конфигов
MySQL – стандартная master-slave репликация
LACP – отказоустойчивость сети (не реализовано)

redmine, jails, нет migraine)
Оптимизация производительности
MySQL slow log, mysqldumpslow/mk-query-digest
смотрим на back-ends из nginx
Xdebug
Instrumentation.php от Percona (TODO)
Обновление ПО/модернизация железа

и получаем полезные агрегированные данные
самые медленные страницы (в среднем)
самые медленные страницы (суммарно)
отчет по кодам ответа back-ends
сравнение производительности back-ends
профиль производительности (универсально, имеет смысл автоматизировать и пользоваться ежедневно)
помогает понять, где оптимизировать

запросам MySQL, после чего mk-query-digest
Переменные -> лог Apache -> SQL -> отчеты
Xdebug тяжелый, нет возможности агрегировать данные, не подходит для поиска редких проблем
Можно ловить проблемы mysql, memcache, чего угодно
Требуется интеграция в код (в хороший код интегрировать просто)

от Percona для поиска редких проблем
Pressflow, часть запросов на slave
Второй ДЦ
Автоматизировать failover для MySQL (MMM или самостоятельно)
Избавиться или свести к минимуму кэширование Drupal в MySQL
LACP