Хостинг для Drupal на примере Тарас Савчук taras (ухо) 1adm.ru

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

Спонсоры Информационные спонсоры Сайт конференции

Постановка задачи Задача (2009-й год) - Drupal 6 - прогноз нагрузки 10M хитов в месяц - два сервера под проект (DL360G6) - производительность, масштабируемость, отказоустойчивость Наследие - 4 сервера (FreeBSD 7/amd64) - web-проекты:

Текущая ситуация Средние параметры нагрузки (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 в среднем.

Текущая ситуация Физические параметры Объем кода + медиафайлов: 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из коробкиво 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= LAN

CARP carp2 ДЦ #sysctl net.inet.carp.preempt= 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 carp1carp2 - одностороння синхронизация - двусторонняя синхронизация

Что такое 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 профиль производительности (универсально, имеет смысл автоматизировать и пользоваться ежедневно) помогает понять, где оптимизировать

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

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

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

Спонсоры Информационные спонсоры Сайт конференции