Как настроить двухуровневую конфигурацию веб-приложения

Сергей РыжиковДиректор

«1С-Битрикс»

Веб-приложение

Кэшированиена диск

База данных

Традиционное устройствовеб-приложения

Одноуровневая схема

Каждый запрос – обычно отдельный процессЛюбой процесс может обработать любой запрос (статика, скрипт)Каждый процесс – десятки и сотни МбПока не закончен запрос, процесс не принимает новый

Узкие места

1. Отдача контента – медленные каналы2. Производительность PHP (в том числе – запросы к внешним ресурсам

и т.п.)3. Обмен с БД (пропускная способность канала, latency, объем данных в

приложении; использовать ли persistent connection?)4. Скорость работы БД5. Отдача статики – много памяти на простую задачу

Если оставить все«по умолчанию»?

По умолчанию MaxClients в Apache 2.x – 256Если PHP может занять 64 Мб (на самом деле – см. memory_limit в php.ini) – весь веб-свервер может занять 16 Гб RAM256 потенциальных коннектов к MySQLПамять для одного коннекта: read_buffer_size + read_rnd_buffer_size + sort_buffer_size + thread_stack + join_buffer_size

swap, OOM, деградация производительности всей системы

Двухуровневая схема

Frontend – чаще всего nginxBackend – Apache, PHP-FPM

Некоторые ключевыемоменты настройки

Backend

192.168.1.1:8888+ Можно обращаться снаружи мимо фронтенда- Могут возникнуть лишние редиректы

127.0.0.2:80- Нельзя обращаться снаружи мимо фронтенда+ Нет проблем с неправильным портом

Backend

StartServers 10

MinSpareServers 10

MaxSpareServers 20

MaxClients 20

MaxRequestsPerChild 500

Проверить лог – нет попаданий статики

Frontend

# cat /proc/cpuinfo | grep "processor" | wc -l

worker_processes 8;

# max_clients = worker_processes * worker_connections

events {

use epoll;

worker_connections 10240;

}

http {

# по умолчанию - 1m

client_max_body_size 1024m;

Frontend

# больше - больше памяти, меньше - чаще пишем на диск

client_body_buffer_size 4m;

# максимально быстро получаем ответ от бэкенда

proxy_buffering on;

gzip on;

gzip_proxied any;

gzip_static on;

gzip_types application/x-javascript text/css;

gzip_min_length 1100;

А без Apache? PHP-FPM

upstream backend {

server unix:/opt/php/var/run/php1.sock;

server unix:/opt/php/var/run/php2.sock;

server unix:/opt/php/var/run/php3.sock;

}

http://nginx.org/ru/docs/http/ngx_http_fastcgi_module.html

Найти все .htaccess и перенести логику в конфиг nginx

А без Apache? PHP-FPM

location ~ \.php$ {

root /var/www/chroot/var/www/html;

fastcgi_intercept_errors on;

fastcgi_pass backend;

fastcgi_index index.php;

include fastcgi_params;

fastcgi_param DOCUMENT_ROOT /var/www/html;

fastcgi_param SCRIPT_FILENAME /var/www/html/$fastcgi_script_name;

fastcgi_param SERVER_NAME $host;

fastcgi_split_path_info ^(.+\.php)(.*)$;

fastcgi_param PATH_INFO $fastcgi_path_info;

}

php-fpm.conf

; рестартовать при ошибках

emergency_restart_threshold = 1

emergency_restart_interval = 10

[www1]

listen=/opt/php/var/run/php1.sock

# echo 10240 > /proc/sys/net/core/somaxconn

listen.backlog = 10240

pm = static

pm.max_children = 5

pm.start_servers = 5

pm.min_spare_servers = 5

pm.max_spare_servers = 5

php-fpm.conf

request_slowlog_timeout = 5

slowlog = /opt/php/var/log/www.slow_access.log

; не open_basedir в php.ini !!!

chroot = /var/www/chroot

php_admin_value[memory_limit] = 256M

security.limit_extensions = .php

[www2]

; ---------- // ----------------

; разные chroot для виртхостов

; разные лимиты

Прекомпиляторы

Zend Optimizer+ (Zend Server) – самый быстрый… и самый «непрозрачный»eAcceleratorAPC

extension=apc.so

apc.enabled=1

apc.max_file_size=5M

apc.shm_size=256M

apc.ttl=7200

apc.num_files_hint=55000

apc.stat=0 ; аккуратно!

apc.php

Итог

Система стабилизирована по памятиНет деградации системы при возрастающей нагрузке – обслуживаем максимум запросов, остальные ожидают в очередиМожем попробовать persistent connections для базы – у нас фиксированное число процессовНе тратим память на отдачу статикиНе занимаем backend медленными запросами клиентовИспользуем сжатие – быстрее отдаем на медленных каналахРазгружаем процессор за счет прекомпиляции PHP

Двухуровневая схема

Frontend – чаще всего nginxBackend – Apache, PHP-FPM

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

Варианты масштабирования до 10.0

1. Разделение на два сервера: веб-сервер + база данных.

2. Увеличение мощности оборудования (чем мощнее – тем дороже; рост стоимости не пропорционален).

3. Выделение кеша на один внешний сервер через memcached.

4. Переход на Oracle (минимальная лицензия +5000$ за процессор).

5. Создание Oracle RAC (Real Application Cluster). Проект – около 150 000$ (оборудование + лицензия + «общая полка»). Очень мало специалистов.

Для большинства клиентов производительности достаточно, но не решены проблемы отказоустойчивости, резервирования, сетевой доступности.

1С-Битрикс: Веб-кластер

«1С-Битрикс: Веб-кластер» - это комбинация технологий:

Вертикальный шардинг (вынесение модулей на отдельные серверы MySQL)Репликация MySQL (Oracle и MS SQL в дальнейшем) и балансирование нагрузки

между серверамиРаспределенный кеш данных (memcached)

Непрерывность сессий между веб-серверами (хранение сессий в базе данных)Кластеризация веб-сервера:

Синхронизация файловБалансирование нагрузки между серверами

1С-Битрикс: Веб-кластер

Тестовый веб-кластер – в «облаке» Amazon

База данных MySQL

База данных MySQL 1

База данных MySQL 2

Вертикальный шардинг Горизонтальный шардинг

База данных MySQL

База данных MySQL 1

База данных MySQL 2

Аккаунты a-m

Аккаунты n-z

Шардинг

Разделение одной базы данных веб-приложения на две и более базы данных за счет выделения отдельных модулей, без изменения логики работы веб-приложения:

• Веб-аналитика

• Поиск

1. Эффективное распределение нагрузки.

2. Масштабирование.

3. Разделение больших объемов данных.

Вертикальный шардинг

• Гибкая балансировка нагрузки SQL

• Простота администрирования

• Дешевое и быстрое неограниченное масштабирование

• Он-лайн бэкап

• Не требуется доработка логики веб-приложения

Репликация и балансировка нагрузки MySQL

Веб-сервер

База данных MySQLMASTER

«1С-Битрикс: Веб-кластер»

База данных MySQLSLAVE 1

База данных MySQLSLAVE N

База данных MySQLSLAVE …

MySQL replication, mixed-mode

SQL-балансировщик1С-Битрикс

Масштабирование при росте нагрузки MySQL

Репликация и балансировка нагрузки MySQL

• Высокая эффективность - за счет централизованного использования кэша веб-приложением

• Надежность - за счет устойчивости подсистемы кешировния к выходу из строя отдельных компонентов

• Неограниченная масштабируемость - за счет добавления новых memcached-серверов.

memcached1

memcached2

memcached3

Веб-кластер «1С-Битрикс»

40% 30%30%

Веб-сервер Веб-сервер Веб-сервер

Распределенный кеш данных (memcached)

Распределенный кеш данных (memcached)

Непрерывность сессий между веб-серверами

Пользовательская сессия должна быть "прозрачной" для всех серверов веб-кластера.

1. После авторизации на одном из серверов пользователь должен считаться авторизованных и для всех других серверов.

2. И наоборот - окончание сессии на любом сервере должно означать ее окончание на всех серверах сразу.

Веб-сервер

База данных MySQL

Нода 1 «1С-Битрикс: Веб-кластер»

Высокая посещаемость

Веб-сервер

Нода 2 «1С-Битрикс: Веб-кластер»

Балансировщик нагрузки

Нагрузка на CPU <50%

1) Нагрузка равномерно распределяется между нодами веб-кластера

2) Сервера приложений не перегружены и работают в устойчивом штатном режиме

Авто-синхронизация

Задача: масштабирование при росте нагрузки

База данных MySQL

Нода 1 «1С-Битрикс:Веб-кластер»

Очень высокая посещаемость

Балансировщик нагрузки

Нода 2 «1С-Битрикс:Веб-кластер»

Нода N «1С-Битрикс:Веб-кластер»…

Задача: масштабирование при росте нагрузки

Веб-сервер 1

/var/www

Веб-сервер 2

?

Задача синхронизации файлов

Два типа:

1. Синхронный:• Общая «дисковая полка» (дорого,

не резервирует данные)• Сетевые средства – NFS (очень

медленно)• OCFS2• DRDB

2. Асинхронный (синхронизация локальных дисков)• rsync• csync2

Синхронизация дисковых систем

Почему мы выбрали csync2?

• Быстрый доступ к файлам приложения за счет использования локальных хранилищ.

• Высокая скорость работы.

• Низкое потребление ресурсов (CPU, дисковые операции). Два этих фактора позволяют запускать процесс синхронизации максимально часто, поэтому данные на серверах становятся идентичными практически в "реальном времени".

• Простота настройки для обмена данными между любым количеством серверов.

• Возможность синхронизации удаления файлов.

• Защищенный обмен данными между хостами (SSL).

Нода 2 «1С-Битрикс: Веб-кластер»

Csync2

Нода 1 «1С-Битрикс: Веб-кластер»

Csync2

/var/www /var/www

Нода 3«1С-Битрикс: Веб-кластер»

Csync2

/var/www

Тип 2: синхронизация локальных дисков

Способы балансирование нагрузки

• DNS сервер с несколькими записями типа A и разными IP адресами и коротким TTL

• NGINX на отдельном оборудовании

• Аппаратный маршрутизатор с балансированием нагрузки

• Балансировка силами дата центра (Amazon EC2)

Балансировщик (клиентские запросы по HTTP)

Веб-сервер 1

memcached 1

Веб-сервер 2

memcached 1MySQLmaster

MySQLslave

За три года – на 430% быстрее!

"Старт" "Бизнес"0

2000000

4000000

6000000

8000000

10000000

12000000

14000000

2007 год2010 год

+110% +430%