1 / 30

Хостинг для Drupal

Хостинг для Drupal. на примере www.forbes.ru. Тарас Савчук taras ( ухо) 1adm.ru http://www.1adm.ru. Генеральный спонсор и организатор конференции DrupalConf 2011. При поддержке:. Спонсоры. Информационные спонсоры. Сайт конференции. Постановка задачи. Задача (2009-й год)

colby-church
Download Presentation

Хостинг для Drupal

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

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

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

  9. 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 – производительность сравнима cBoost • мало опыта

  10. CARP ДЦ 213.145.46.183 carp1 carp2 10.10.10.1 LAN #sysctlnet.inet.carp.preempt=1

  11. CARP ДЦ 213.145.46.183 213.145.46.183 carp1 carp2 10.10.10.1 10.10.10.1 LAN #sysctlnet.inet.carp.preempt=1

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

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

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

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

  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)) db1-bitrix db2-bitrix db-bitrix-rw (IP)) - Подключения к БД - Направление репликации - 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 • профиль производительности (универсально, имеет смысл автоматизировать и пользоваться ежедневно) • помогает понять, где оптимизировать

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

  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

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

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

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

More Related