'

Хостинг для Drupal

Понравилась презентация – покажи это...





Слайд 0

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


Слайд 1

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


Слайд 2

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


Слайд 3

Постановка задачи Задача (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


Слайд 4

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


Слайд 5

Текущая ситуация Физические параметры www.forbes.ru Объем кода + медиафайлов: 16 Гб Количество файлов (код + медиафайлы): ~ 110К Размер базы: 3 Гб Кол-во записей в базе: 20 М


Слайд 6

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


Слайд 7

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


Слайд 8

Front-ends Общий IP-адрес (или адреса) на DNS полагаться не можем CARP (Common Address Redundancy 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 мало опыта


Слайд 9

CARP carp2 carp1 ДЦ #sysctl net.inet.carp.preempt=1 213.145.46.183 10.10.10.1 LAN


Слайд 10

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


Слайд 11

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


Слайд 12

Как выглядит ezjail?


Слайд 13

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


Слайд 14

Схема работы csync^2 fs-1-14 (jail) web1 fs-2-14 (jail) web2 carp1 carp2 - одностороння синхронизация - двусторонняя синхронизация


Слайд 15

Что такое csync^2? Асинхронная синхронизация :) Обнаружение и разрешение конфликтов Репликация удалений Сложные конфигурации: исключения, группы хостов, slave-режим librsync локальная БД (sqlite) «проталкивает» изменения SSL + pre-shared-keys резервное копирование триггеры


Слайд 16

Производительность csync^2 10 минут на полную синхронизацию 40K+ файлов общим размером 500Мб 13 секунд на проверку, что все синхронно 22 секунды на синхронизацию новых 1400 файлов объемом 13Мб 8 секунд на проверку, что все синхронно


Слайд 17

Back-ends: web-сервер Apache – совместимость ПО, поставляемое в виде модулей Apache модули Drupal, «заточенные» на Apache (Boost) Apache + Boost с одной машины загружают гигабит Можем использовать любой web-сервер и набор ПО


Слайд 18

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)


Слайд 19

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)) - Подключения к БД


Слайд 20

Сеть LACP (Link Aggregation Control Protocol) просто, но не реализовано не нужны коммутаторы при схеме из 2-х серверов


Слайд 21

Резюме по архитектуре 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 – отказоустойчивость сети (не реализовано)


Слайд 22

Текущие задачи Резервное копирование (mysqldump, снапшоты) Мониторинг (Zabbix), внешний (http) и внутренний Разработка (git, redmine, jails, нет migraine) Оптимизация производительности MySQL slow log, mysqldumpslow/mk-query-digest смотрим на back-ends из nginx Xdebug Instrumentation.php от Percona (TODO) Обновление ПО/модернизация железа


Слайд 23

Профиль производительности Логи nginx в .csv (в т.ч. $upstream_response_time) импортируем в MySQL и получаем полезные агрегированные данные самые медленные страницы (в среднем) самые медленные страницы (суммарно) отчет по кодам ответа back-ends сравнение производительности back-ends профиль производительности (универсально, имеет смысл автоматизировать и пользоваться ежедневно) помогает понять, где оптимизировать


Слайд 24

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


Слайд 25

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


Слайд 26

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


Слайд 27

Спасибо за внимание! Тарас Савчук taras (ухо) 1adm.ru http://www.1adm.ru


Слайд 28

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


Слайд 29

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


×

HTML:





Ссылка: