Запуск и эксплуатация веб-проектов Александр Демидов Руководитель направления арендных решений «1С-Битрикс»

Запуск и эксплуатация веб-проектов
Александр Демидов
Руководитель направления арендных решений
«1С-Битрикс»
«На старт…»
Каким будет новый
проект?
Разные классы сайтов и вебсервисов:
Домашние странички, личные блоги
и т.п.
«Продающие» сайты (интернетмагазины)
Имиджевые сайты (в том числе и
корпоративные)
«Business critical application» - вебсервисы, использующиеся в работе
(CRM, учет, таск-менеджмент, почта
и т.п.)
На старте проекта заказчик и разработчик могут не
знать, каким он станет, но должны заранее определить
«ТЗ на эксплуатацию».
Новый проект – какой он?
Определяют требования заказчика
Если сам заказчик не сумеет определиться с
требованиями, помогите ему.
Количество хитов в сутки
Скорость загрузки главной страницы
при указанном количестве хитов
Скорость загрузки критичных
разделов
Среднее время загрузки всех
страниц в сутки
Процент страниц с временем
загрузки более n сек.
Допустимый процент ошибок
Допустимое время простоя
...
Почему сайт должен быть
всегда доступен?
Клиенты и их лояльность
(сайт недоступен –
потеряны заказы).
Индексация сайта
поисковыми роботами
Финансовые потери во
время рекламных
компаний
Стоимость контекстной
рекламы
Не бывает
«почти круглосуточно»
Технические работы должны
проходить незаметно для
клиентов:
Сервисные работы
Замена оборудования
Обновления системного
ПО
Обновления приложений
Почему сайт должен быть
быстрым?
Замедление загрузки
страницы на 1 секунду
снижает конверсию на 7%, а
количество просмотров - на
11%.
«Внимание…»
Виды хостинга
Виртуальный (shared)
VPS
Dedicated/Colocation
«Облако»
Эксплуатация: выбор инфраструктуры
Риски:
Взять слишком много и переплатить (не можем заранее
спрогнозировать потребление ресурсов)
Взять слишком мало и «просесть» по производительности
Безопасность (если в штате нет толкового системного
администратора)
Надежность (как резервировать доступность на уровне
датацентра?)
Сетевая доступность
Виртуальный (shared) хостинг
Это – всегда «общежитие».
Самый простой вариант
Хороший хостинг снимает
практически всю головную
боль (бэкапы,
резервирование и т.п.)
Мало настроек
Мало ресурсов
Мало «путей отступления»
«Железо» VS. «Облако»
Экономия?
Самый частый посыл к переходу на «облака» вообще
(и IaaS – в частности) – уменьшение затрат, экономия.
Не дешевле?
В прямом сравнении железа и аналогичного по
конфигурации облака – облако почти всегда проигрывает
Почти всегда отдельно рассчитывается стоимость траффика
Сложность расчетов при оплате «по потреблению»
При оплате «по потреблению» при резком росте нагрузки
(DDoS, «хабраэффект», ошибки в разработке) возможны
значительные расходы (в разы больше запланированных)
Где реальная экономия?
Нет инсталляционных платежей (для больших проектов –
если речь идет о покупке собственного оборудования)
Минимальные финансовые риски на старте нового проекта
Обслуживание системы
Экономия времени
Масштабирование в облаке?
Без готовности приложения к
масштабированию – не имеет
практического смысла
Масштабирование
Надежность?
Виртуальные машины ребутятся чаще
физического «железа».
Amazon AWS – как минимум:
апрель 2011, август 2011, июнь 2012, декабрь
2012…
«Лежали» Foursquare, Instagram, Netflix,
Pinterest…
Облако само по себе не дает надежность.
Облако дает возможность построить
надежную инфраструктуру.
Можно побольше ресурсов?
Есть выделенные ресурсы – RAM, CPU, HDD: попросилвыделил-заплатил;
Есть разделяемые ресурсы – кэш процессора, IOPS,... Ни у
одного облака нельзя попросить обеспечить N IOPS в течение
K минут. Можно только понадеяться.
Инфраструктура: «Железо» vs. «Облако»
+ Экономия за счет возможности
планирования ресурсов
+ Экономия и отсутствие рисков,
связанные с вложениями в
инфраструктуру
+ Моментальное вертикальное и
горизонтальное
масштабирование
+ Удобство администрирования
+ Экономия времени
- Затраты (время) на обучение
сотрудников специфике
конкретного сервиса
- Ограничения инфраструктуры
(аппаратная часть, специфичное
ПО)
- Сложность расчетов «по
потреблению»
Инфраструктура: «Железо» vs. «Облако»
- Медленные диски
+ CPU и RAM – по требованию
- Нельзя гарантированно получить
некоторые ресурсы
+ Возможность построить
масштабируемую инфраструктуру
- Ложное ощущение гарантий
безопасности и
отказоустойчивости
+ Возможность построить
отказоустойчивую
инфраструктуру
+ Дополнительные сервисы
Безопасность и надежность
Дополнительные сервисы
(например, Amazon S3)
Доступность – 99.99%
Надежность – 99.999999999%
ACL
Версионность
Шифрование (server-side,
client-side)
Зачем нам нужен cloud storage?
Снижаем стоимость эксплуатации
Можем использовать совместно с CDN
Снижаем нагрузку на web-узлы
«Легкий» сайт – легко переезжать и бэкапить
Синхронизация контента между множественными
web-узлами
Ускоряем рендеринг страниц в браузере
…и другие сервисы:
Автомасштабирование
Мониторинг
Балансировщики
Облачные базы данных
Облачные NoSQL
Облачный кэш
…
Немного нюансов
настройки веб-сервера
Настройки «по умолчанию» – это
далеко не всегда хорошо
Типовые ошибки/проблемы/недостатки конфигурации:
PHP как CGI (не путать с FastCGI)
open_basedir
Не установлен прекомпилятор PHP
Недостаточно памяти прекомпилятору
Медленная файловая система и/или мало дискового кэша
Отсутствует FrontEnd (nginx)
ngnix есть, но всю статику запрашивает у Apache
Не отрегулировано значение MaxClients в Apache
И т.д.
Традиционное устройство
веб-приложения
Веб-приложение
Кэширование
на диск
База данных
Одноуровневая схема
Каждый запрос – обычно отдельный процесс
Любой процесс может обработать любой запрос (статика, скрипт)
Каждый процесс – десятки и сотни Мб
Пока не закончен запрос, процесс не принимает новый
Узкие места
1. Отдача контента – медленные каналы
2. Производительность PHP (в том числе – запросы к внешним ресурсам
и т.п.)
3. Обмен с БД (пропускная способность канала, latency, объем данных в
приложении; использовать ли persistent connection?)
4. Скорость работы БД
5. Отдача статики – много памяти на простую задачу
Если оставить все
«по умолчанию»?
По умолчанию MaxClients в Apache 2.x
– 256
Если PHP может занять 64 Мб (на
самом деле – см. memory_limit в
php.ini) – весь веб-свервер может
занять 16 Гб RAM
256 потенциальных коннектов к MySQL
Память для одного коннекта:
read_buffer_size + read_rnd_buffer_size
+ sort_buffer_size + thread_stack +
join_buffer_size
swap, OOM, деградация
производительности всей системы
Двухуровневая схема
Frontend – чаще всего nginx
Backend – 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
gzip_proxied
gzip_static
gzip_types
gzip_min_length
on;
any;
on;
application/x-javascript text/css;
1100;
А без Apache? PHP-FPM
http://nginx.org/ru/docs/http/ngx_http_fastcgi_module.html
Найти все .htaccess и перенести логику в конфиг nginx
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;
}
А без 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) – самый быстрый… и самый
«непрозрачный»
eAccelerator
APC
extension=apc.so
apc.enabled=1
apc.max_file_size=5M
apc.shm_size=256M
apc.ttl=7200
apc.num_files_hint=55000
apc.php
Итог
Система стабилизирована по памяти
Нет деградации системы при возрастающей нагрузке –
обслуживаем максимум запросов, остальные ожидают в
очереди
Можем попробовать persistent connections для базы – у нас
фиксированное число процессов
Не тратим память на отдачу статики
Не занимаем backend медленными запросами клиентов
Используем сжатие – быстрее отдаем на медленных
каналах
Разгружаем процессор за счет прекомпиляции PHP
Немного нюансов
настройки базы данных
Приоритет
Производительность?
Надежность?
Вместе – не получается…
Что может оказаться
«узким местом»?
CPU?
RAM?
Диск?
Всё!
Как определить конфигурацию
RAID для базы?
Любое решение выбирается, исходя из конкретной
поставленной задачи.
Для работы MySQL используем InnoDB. Следовательно, необходимо
эффективно работать с операциями random read/write на больших
файлах (ibdata).
Тесты sysbench
Работы с одиночным файлом 16 Гб в
режиме random read/write.
При увеличении количества потоков
единичный диск почти сразу
достигает «потолка»,
производительность RAID растет.
Диагностика
top
free
iostat –x 2
Device:
xvde
xvdj
xvdi
xvdh
xvdg
xvda
xvdo
xvdn
xvdm
xvdl
xvdk
md0
rrqm/s
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
wrqm/s
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
r/s
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
w/s
0.00
13.00
13.00
39.50
39.50
0.00
0.00
16.50
16.50
12.50
12.50
73.50
rsec/s
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
wsec/s avgrq-sz avgqu-sz
0.00
0.00
0.00
464.00
35.69
0.07
464.00
35.69
0.09
1436.00
36.35
0.17
1436.00
36.35
0.21
0.00
0.00
0.00
0.00
0.00
0.00
468.00
28.36
0.16
468.00
28.36
0.15
328.00
26.24
0.16
328.00
26.24
0.10
2680.00
36.46
0.00
await
0.00
5.50
7.27
4.39
5.32
0.00
0.00
9.64
8.88
12.68
7.64
0.00
svctm
0.00
1.42
1.50
0.76
0.84
0.00
0.00
0.97
0.88
1.72
1.16
0.00
%util
0.00
1.85
1.95
3.00
3.30
0.00
0.00
1.60
1.45
2.15
1.45
0.00
Диски и tmpfs
# cat /etc/fstab
# <file system> <mount point> <type> <options> <dump> <pass>
tmpfs
/dev/shm
tmpfs
defaults
0
/dev/md0
/mnt/ext4_raid10_8 ext4
defaults,noatime,nodiratime,data=writeback,barrier=0
0
0 0
MySQL?
MySQL
MariaDB
Percona Server
Percona Server
Оптимизирован для работы с медленными дисками
Быстрый рестарт базы (Fast Shut-Down, Buffer Pool Pre-Load)
Множество счетчиков и расширенных отчетов
XtraDB Storage Engine
XtraBackup
Сбалансированность
по памяти
Размер глобальных буферов: key_buffer_size +
tmp_table_size + innodb_buffer_pool_size +
innodb_additional_mem_pool_size + innodb_log_buffer_size +
query_cache_size
Размер буфера для одного коннекта: read_buffer_size +
read_rnd_buffer_size + sort_buffer_size + thread_stack +
join_buffer_size
Максимально возможное использование памяти:
глобальные буферы + буферы подключений *
максимальное число коннектов
Надежность
default-storage-engine
= innodb
# самый надежный
sync_binlog
= 1
# hint: писать на отдельный раздел
log-bin
= /mnt/binlogs/mysql/mysqld-bin
binlog-format
= mixed
# сбрасываем log buffer на каждый commit, flush на диск –
# раз в секунду
innodb-flush-log-at-trx-commit = 2
sync_master_info
= 0
sync_relay_log
= 0
sync_relay_log_info = 0
max-connect-errors
= 10000
Надежность
innodb-file-per-table
# Percona
innodb_lazy_drop_table = 1
Но… Очень ресурсоемкие операции schema changes (ALTER TABLE…,
DROP DATABASE… и т.п.).
Но… Гибкость в обслуживании базы (например, DROP – на самом деле
освобождает место).
Скорость
# временные таблицы – в памяти
tmpdir = /dev/shm
# меньше DNS запросов
skip-name-resolve
# размер временных таблиц в памяти
max-heap-table-size
= 64M
tmp-table-size
= 64M
# зависит от max_connections
# если много – лучше несколько инстансов mysqld
table-cache
= 4096
table_definition_cache
= 4096
# выделяется сразу на запросы без индексов
join-buffer-size
= 32M
Query cache
# много – тоже плохо
query-cache-size
query-cache-limit
= 128M
= 2M
mysql> SHOW STATUS LIKE 'Qc%';
+-------------------------+----------+
| Variable_name
| Value
|
+-------------------------+----------+
| Qcache_free_blocks
| 14739
|
| Qcache_free_memory
| 48267544 |
| Qcache_hits
| 20979825 |
| Qcache_inserts
| 4894095 |
| Qcache_lowmem_prunes
| 1599839 |
| Qcache_not_cached
| 6977833 |
| Qcache_queries_in_cache | 35580
|
| Qcache_total_blocks
| 100075
|
+-------------------------+----------+
8 rows in set (0.00 sec)
InnoDB & buffer pool
# желательно – по объему таблиц
innodb-buffer-pool-size
= 4000M
# если buffer pool > 1Gb
innodb_buffer_pool_instances
= 4
innodb_log_file_size
= 512M
innodb_log_buffer_size = 32M
# на быстрых дисках; можно экспериментировать
innodb_read_io_threads
= 16
innodb_write_io_threads
= 16
innodb_io_capacity
= 800
InnoDB, buffer pool – на что
ориентироваться
mysql> SHOW ENGINE INNODB STATUS\G
---------------------BUFFER POOL AND MEMORY
---------------------Buffer pool hit rate 998 / 1000
-----------TRANSACTIONS
-----------…
mysql> SHOW STATUS\G
mysql> SHOW PROCESSLIST;
Борьба за долгие запросы
log-output
slow-query-log
slow-query-log-file
long-query-time
=
=
=
=
FILE
1
mysql_slow.log
1
#percona
log_slow_verbosity = microtime,query_plan,innodb
# Time: 120712 9:43:47
# User@Host: user[user] @ [10.206.66.207]
# Thread_id: 3513565 Schema: user Last_errno: 0 Killed: 0
# Query_time: 1.279800 Lock_time: 0.000053 Rows_sent: 0 Rows_examined: 1 Rows_affected: 0 Rows_read: 0
# Bytes_sent: 52 Tmp_tables: 0 Tmp_disk_tables: 0 Tmp_table_sizes: 0
# InnoDB_trx_id: 33E7689B
# QC_Hit: No Full_scan: No Full_join: No Tmp_table: No Tmp_table_on_disk: No
# Filesort: No Filesort_on_disk: No Merge_passes: 0
#
InnoDB_IO_r_ops: 0 InnoDB_IO_r_bytes: 0 InnoDB_IO_r_wait: 0.000000
#
InnoDB_rec_lock_wait: 0.000000 InnoDB_queue_wait: 0.000000
#
InnoDB_pages_distinct: 4
UPDATE b_user_option SET `COMMON` = 'N', `VALUE` =
'a:19:{i:1;b:1;i:25;b:1;i:59;b:1;i:63;b:1;i:89;b:1;i:97;b:1;i:103;b:1;i:10
5;b:1;i:117;b:1;i:127;b:1;i:175;b:1;i:213;b:1;i:231;b:1;i:267;b:1;i:293;b:1;i:363;b:1;i:391;b:1;i:401;b:1;i
:427;b:1;}', `NAME
` = 'openTab', `CATEGORY` = 'IM', `USER_ID` = 263 WHERE ID=1719;
Одиночные медленные
запросы
Одиночный медленный запрос всегда работает медленно
Его просто найти (slow.log)
Его просто изучать (EXPLAIN)
Подробная статистика без
Перконы
mysql> SHOW PROFILES;
Empty set (0.02 sec)
mysql> SHOW PROFILE;
Empty set (0.00 sec)
mysql> SET PROFILING=1;
Query OK, 0 rows affected (0.00 sec)
mysql> SELECT COUNT(*) FROM mysql.user;
+----------+
| COUNT(*) |
+----------+
|
3024 |
+----------+
1 row in set (0.09 sec)
Подробная статистика без
Перконы
mysql> SHOW PROFILES;
+----------+------------+---------------------------------+
| Query_ID | Duration
| Query
|
+----------+------------+---------------------------------+
|
1 | 0.09104400 | SELECT COUNT(*) FROM mysql.user |
+----------+------------+---------------------------------+
1 row in set (0.00 sec)
Подробная статистика без
Перконы
mysql> SHOW PROFILE;
+--------------------------------+----------+
| Status
| Duration |
+--------------------------------+----------+
| starting
| 0.000018 |
| Waiting for query cache lock
| 0.000004 |
| Waiting on query cache mutex
| 0.000004 |
| checking query cache for query | 0.000041 |
| checking permissions
| 0.000007 |
| Opening tables
| 0.090854 |
| System lock
| 0.000013 |
| init
| 0.000012 |
| optimizing
| 0.000007 |
| executing
| 0.000010 |
| end
| 0.000005 |
| query end
| 0.000004 |
| closing tables
| 0.000031 |
| freeing items
| 0.000029 |
| logging slow query
| 0.000003 |
| cleaning up
| 0.000004 |
+--------------------------------+----------+
16 rows in set (0.00 sec)
«Живая» система – много
небольших запросов
mysql> SELECT * FROM INFORMATION_SCHEMA.QUERY_RESPONSE_TIME;
+----------------+-------+----------------+
| time
| count | total
|
+----------------+-------+----------------+
|
0.000001 |
0 |
0.000000 |
|
0.000010 | 2011 |
0.007438 |
|
0.000100 | 12706 |
0.513395 |
|
0.001000 | 4624 |
1.636106 |
|
0.010000 | 2994 |
12.395174 |
|
0.100000 |
200 |
6.225339 |
|
1.000000 |
33 |
5.480764 |
|
10.000000 |
1 |
2.374067 |
|
100.000000 |
0 |
0.000000 |
|
1000.000000 |
0 |
0.000000 |
|
10000.000000 |
0 |
0.000000 |
| 100000.000000 |
0 |
0.000000 |
| 1000000.000000 |
0 |
0.000000 |
| TOO LONG
|
0 | TOO LONG
|
+----------------+-------+----------------+
14 rows in set (0.00 sec)
Как жить с большим
количеством баз и таблиц?
Если позволяет логика приложения – разделить один
инстанс mysqld на несколько
Имеет смысл только на достаточном количестве ресурсов
(многоядерные системы, гигабайты RAM)
Несколько инстансов лучше утилизируют ресурсы
Минус – некоторая сложность администрирования
Два теста (sysbench): первым грузим в 100 потоков 1 инстанс;
вторым грузим параллельно 50 потоков на один инстанс, 50
потоков на второй. Во втором тесте в среднем получаем на 15%
больше запросов в секунду.
Что влияет?
Все внутренние ресурсы системы
Локировки (таблицы, строки)
Прочие локировки («waiting for query cache lock»)
Мониторим и находим:
Внешний мониторинг системы (nagios – real time, munin –
аналитика)
slow.log
SHOW PROCESSLIST
SHOW STATUS
SHOW ENGINE INNODB STATUS
Резюме - общие
рекомендации
InnoDB, а не MyISAM
Для дисков – лучше RAID
Больше памяти (в идеале вся база должна помещаться в
buffer pool)
Но – не в ущерб системе в целом (не уходить в swap)
Репликация (чтения – со slave’ов, записи – на master’е)
Быстрый старт…
Возможно?
1С-Битрикс: Виртуальная машина
«1С-Битрикс: Виртуальная машина» – это «1С-Битрикс: Вебокружение Linux» с использованием разных способов
виртуализации.
сконфигурированная операционная система
веб-сервер
база данных
firewall
почтовый сервер
поддержка многосайтовости
поддержка веб-кластера
средства отладки
средства мониторинга
поддержка NTLM авторизации
поддержка push & pull
Все еще «Внимание» 
Нагрузочное тестирование
Нагрузочное тестирование - обязательный
этап сдачи проекта.
Нагрузочное тестирование является
важнейшей процедурой подготовки
крупного проекта к открытию.
Нагрузочное тестирование позволяет
определить предел работоспособности
созданного проекта именно на выбранном
оборудовании.
Зачастую, простые корректировки конфигурации могут ускорить проект в 5-10
раз и сделать его устойчивым к стрессовым нагрузкам.
Нагрузочное тестирование
Риск: «Нагрузка далека от реальности»
Проводите нагрузочное тестирование на реальных
данных с «боевых серверов»
Используйте монитор производительности
Эмулируйте действия пользователей на проекте
Эмулируйте импорты/экспорты/веб-сервисы
Jmeter
WAPT
httperf
ab
Марш!
А нужно ли всегда
знать о «состоянии
здоровья» сайта?
Вроде работает…
Тормозит – «пнем» админа, чтобы
что-то там перезапустил, это всегда
помогает
Если что, можно быстренько что-то
дописать на «бою»
Real Time мониторинг – как
узнавать о проблемах?
Можно – так…
Real Time мониторинг – как
узнавать о проблемах?
Или – так…
Организация системы
мониторинга
Лучше – стандартные решения (Nagios, Zabbix и т.п.), а не
самописные.
Дежурная смена и/или мгновенные уведомления.
Мониторить – всё.
Не только технику (домены, сертификаты, баланс sms).
Но – аккуратно. Тысячи уведомлений будут бесполезны.
Автоматизация типовых реакций.
Мониторить систему мониторинга.
В идеальном мире – распределенная система мониторинга.
Мониторинг «железа»
Рейды
S.M.A.R.T. – диск возможно скоро «умрет»
Утилиты вендора – внутренние аппаратные тесты
Периодическое тестирование железа в оффлайне
Имеем «запчасти» (блоки питания, вентиляторы …) или
знаем где их быстро найти
Мониторинг операционной
системы
Место на дисках
Очередь выполнения
Размер и использование swap
И т.д.
Подробная диагностика
Полезные утилиты: atop, ps, pstree, apachetop, innotop,
netstat, iostat, vmstat…
Если нет админа…
Аутсорс
Внешние системы:
http://host-tracker.com/
Яндекс.Метрика
И т.д.
Аналитика
Аналитика – со стороны
пользователя
Мало знать «среднюю температуру по больнице» и
мониторить только главную страницу сайта
Гистограммы распределения времени хитов, памяти,
кодам ответа и т.п. – из логов (awk-скрипт), pinba или
других инструментов
Поиск «узких» мест
Apache /server-status
Включенные логи медленных запросов php-fpm, nginx,
apache, mysql
Поиск узких мест
Pinba, XDebug, XHProf
Поиск «узких» мест
Xdebug в продакшене – практически невозможно
использовать
Pinba – для аналитики
Xhprof – профилирование
extension=xhprof.so
extension=pinba.so
pinba.enabled=1
pinba.server=192.168.2.3:3307
Подключение – dbconn.php, init.php, но чаще удобнее через
auto_prepend_file
xhprof
xhprof
Хардкор!
Отладка «на бою»:
strace
gdb
«Здоровый» сайт
Сайт всегда доступен для
посетителей
Вы оперативно узнаете о
любых проблемах и имеете
план их решения
Аналитические данные
позволяют прогнозировать,
где могут появиться «узкие»
места
Вы умеете оценивать
комфорт пользователей в
реальных «цифрах»
Резервирование и рост
Отказы инфраструктуры
Интернет-каналы
DNS
Веб-серверы
Кэш
Базы данных
Диски
Датацентр
Отказоустойчивая архитектура приложения
Готовимся, начиная с ТЗ:
Составляем перечень возможных отказов с приоритетами
Прогнозируем объем и характер нагрузки
«Учим» сайт адекватно реагировать на отказы и аварии
Используем веб-кластерные технологии платформы:
>1 серверов web-приложений
>1 баз данных
>1 memcached - серверов
Архитектура веб-кластера в одном ДЦ
DNS серверы
Primary
Secondary
Балансировщик
nginx
(upstream module)
Сервер приложений 1
«1C-Битрикс: Управление сайтом» кластерная редакция
Apache
PHP
Сервер MySQL Master
MySQL (Innodb/XtraDB)
Сервер приложений 2
«1C-Битрикс: Управление сайтом» кластерная редакция
Apache
PHP
Сервер MySQL Slave
MySQL (Innodb/XtraDB)
Резервируем сервер web-приложений
upstream backend {
DNS серверы
Primary
server app1.example.com max_fails=3
Secondary
fail_timeout=30s;
server app2.example.com max_fails=3
fail_timeout=30s;
Балансировщик
}
…
nginx
(upstream module)
proxy_next_upstream error timeout http_500 http_502
http_503 http_504;
Сервер приложений 1
«1C-Битрикс: Управление сайтом» кластерная редакция
Apache
PHP
Сервер MySQL Master
MySQL (Innodb/XtraDB)
Сервер приложений 2
«1C-Битрикс: Управление сайтом» кластерная редакция
Apache
PHP
Сервер MySQL Slave
MySQL (Innodb/XtraDB)
Резервируем базу данных
Отказал/отстал MySQL Slave
DNS серверы
Primary
Secondary
Балансировщик
nginx
(upstream module)
Сервер приложений 1
«1C-Битрикс: Управление сайтом» кластерная редакция
Apache
PHP
Сервер MySQL Master
MySQL (Innodb/XtraDB)
Сервер приложений 2
«1C-Битрикс: Управление сайтом» кластерная редакция
Apache
PHP
Сервер MySQL Slave
MySQL (Innodb/XtraDB)
Резервируем кэш
Резервируем файлы и каналы
Отказоустойчивая архитектура приложения
Через настройки платформы мы сделали эти сервисы надежными:
База данных
Кэш
Файлы и ресурсы
Приложение может полагаться на их высокую доступность.
«Узкие» места
Высокие требования к сети, связность
серверов друг с другом
Веб-сервер
«1С-Битрикс: Веб-кластер»
SQL-балансировщик
1С-Битрикс
База данных MySQL
MASTER
База данных MySQL
SLAVE 1
База данных MySQL
SLAVE …
База данных MySQL
SLAVE N
Ручные операции для восстановления
master’а MySQL
Балансировщик (клиентские запросы
по HTTP)
Веб-сервер 1
memcached 1
MySQL
master
Веб-сервер 2
MySQL
slave
memcached 1
Аварии на уровне целого датацентра или
интернет-канала
Балансировщик (клиентские запросы
по HTTP)
Веб-сервер 1
memcached 1
MySQL
master
Веб-сервер 2
MySQL
slave
memcached 1
Отказоустойчивая архитектура приложения
Учимся выдерживать отказ MASTER-БД:
Локальный мастер-мастер с переключением IP-адреса
(скрипт или Pacemaker)
Локальный мастер + DRBD c переключением
Гео веб-кластер (active-passive) в другом ДЦ
Верстаем 2 красивые страницы-заглушки:
При ошибке соединения apache с БД (dbquery_error.php)
При недоступности apache/php-fpm за nginx
Отказал MySQL Master
DNS серверы
Primary
Secondary
Балансировщик
nginx
(upstream module)
Сервер приложений 1
«1C-Битрикс: Управление сайтом» кластерная редакция
Apache
PHP
Сервер MySQL Master
MySQL (Innodb/XtraDB)
Сервер приложений 2
«1C-Битрикс: Управление сайтом» кластерная редакция
Apache
PHP
Сервер MySQL Slave
MySQL (Innodb/XtraDB)
Используем master-master
репликацию в MySQL
Особенности настройки MySQL:
auto_increment_increment
auto_increment_offset
Базы в разных датацентрах синхронны, при этом независимы друг от
друга: потеря связности между датацентрами может составлять часы,
данные синхронизируются после восстановления.
Необходимо группировать пользователей для работы в одном
датацентре за счет управления балансировщиком.
Если сессии храним в базе, то не реплицируем их между серверами изза большого траффика и возможных «локов»:
SET sql_log_bin = 0 … или …
replicate-wild-ignore-table = %.b_sec_session%
Вывод: резервировать надо все
Static
Static
CDN
js, css
Elastic Load Balancing
Web 1
Web 2
local
cache
local
cache
CloudWatch
+
AutoScaling
…
mysqld
control cache: memcached
js, css
Elastic Load Balancing
Web 2
local
cache
local
cache
local
cache
S3
S3
mysqld
master-master replication
mysqld
master-master replication
control cache: memcached
mysqld
mysqld
mysqld
control cache: memcached
CloudWatch
+
AutoScaling
…
local
cache
mysqld
mysqld
mysqld
mysqld
mysqld
control cache: memcached
management,
monitoring,
backup
Web N
mysqld
mysqld
mysqld
control cache: memcached
CDN
Web 1
master-master replication
mysqld
Dynamic
Web N
mysqld
mysqld
images (clients)
images (clients)
Dynamic
mysqld
control cache: memcached
Если все-таки упали…
Банкротство?
Исследование Strategic Research Institute
30% предпринимателей после утраты
данных прекращают
предпринимательскую деятельность в
течение года.
60% предпринимателей, потерявших ВСЕ
данные, прекращают
предпринимательскую деятельность в
течение 6 месяцев после этого.
Риск потери данных
Бэкапы…
Для разных сценариев восстановления данных
необходимо использовать разные бэкапы!
Снэпшоты дисков, LVM, образы виртуальных машин - для восстановления
целых серверов или дисков.
Логические (mysqldump) и бинарные инкрементальные (Xtrabackup)
бэкапы используются для восстановления отдельных баз или таблиц,
поврежденных в случае некорректных операций в системе или ошибок
пользователей.
Второй тип бэкапов делается на выделенном slave, на который не
распределяется общая нагрузка. Тем самым ресурсоемкие операции
создания бэкапов не влияют на работу пользователей.
Файловые бэкапы – tar.gz, bacula и т.д.
Файловые хранилища бэкапим в файловые хранилища или используем
версионность
Бэкапы
Делайте бэкапы!
Разумно подходите к периодичности создания бэкапов и
времени хранения резервных копий.
Обязательно имейте сценарии восстановления и проводите
«учения».
Используйте «Облачный бэкап» в платформе «1С-Битрикс»
Спасибо за внимание!
Вопросы?
Александр Демидов
demidov@1c-bitrix.ru
+7-926-521-3700
@demidov
http://www.1c-bitrix.ru