(1 часть) 1С-Битрикс. Как настроить двухуровневую...
-
Upload
forkconf -
Category
Technology
-
view
162 -
download
0
description
Transcript of (1 часть) 1С-Битрикс. Как настроить двухуровневую...
Как настроить двухуровневую конфигурацию веб-приложения
Сергей РыжиковДиректор
«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%