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