Запуск и эксплуатация веб-проектов презентация

«На старт…»

Разные классы сайтов и веб-сервисов:
Домашние странички, личные блоги и т.п.
«Продающие» сайты (интернет-магазины)
Имиджевые сайты (в том числе и корпоративные)
«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
И т.д.
Настройки «по умолчанию» – это далеко не всегда хорошо

Веб-приложение
Кэширование
на диск
База данных
Традиционное устройство
веб-приложения

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

Узкие места
Отдача контента – медленные каналы
Производительность PHP (в том числе – запросы к внешним ресурсам и т.п.)
Обмен с БД (пропускная способность канала, latency, объем данных в приложении; использовать ли persistent connection?)
Скорость работы БД
Отдача статики – много памяти на простую задачу

Если оставить все
«по умолчанию»?
По умолчанию 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 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) – самый быстрый… и самый «непрозрачный»
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?
Диск?
Всё!

Любое решение выбирается, исходя из конкретной поставленной задачи.
Для работы MySQL используем InnoDB. Следовательно, необходимо эффективно работать с операциями random read/write на больших файлах (ibdata).
Тесты sysbench
Работы с одиночным файлом 16 Гб в режиме random read/write.
При увеличении количества потоков единичный диск почти сразу достигает «потолка», производительность RAID растет.
Как определить конфигурацию RAID для базы?

Диагностика
top
free
iostat –x 2
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util
xvde 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
xvdj 0.00 0.00 0.00 13.00 0.00 464.00 35.69 0.07 5.50 1.42 1.85
xvdi 0.00 0.00 0.00 13.00 0.00 464.00 35.69 0.09 7.27 1.50 1.95
xvdh 0.00 0.00 0.00 39.50 0.00 1436.00 36.35 0.17 4.39 0.76 3.00
xvdg 0.00 0.00 0.00 39.50 0.00 1436.00 36.35 0.21 5.32 0.84 3.30
xvda 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
xvdo 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
xvdn 0.00 0.00 0.00 16.50 0.00 468.00 28.36 0.16 9.64 0.97 1.60
xvdm 0.00 0.00 0.00 16.50 0.00 468.00 28.36 0.15 8.88 0.88 1.45
xvdl 0.00 0.00 0.00 12.50 0.00 328.00 26.24 0.16 12.68 1.72 2.15
xvdk 0.00 0.00 0.00 12.50 0.00 328.00 26.24 0.10 7.64 1.16 1.45
md0 0.00 0.00 0.00 73.50 0.00 2680.00 36.46 0.00 0.00 0.00 0.00

Диски и tmpfs
# cat /etc/fstab
#
tmpfs /dev/shm tmpfs defaults 0 0
/dev/md0 /mnt/ext4_raid10_8 ext4 defaults,noatime,nodiratime,data=writeback,barrier=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 = 128M
query-cache-limit = 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 = FILE
slow-query-log = 1
slow-query-log-file = mysql_slow.log
long-query-time = 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С-Битрикс: Веб-окружение Linux» с использованием разных способов виртуализации.
сконфигурированная операционная система
веб-сервер
база данных
firewall
почтовый сервер
поддержка многосайтовости
поддержка веб-кластера
средства отладки
средства мониторинга
поддержка NTLM авторизации
поддержка push & pull
1С-Битрикс: Виртуальная машина

Все еще «Внимание» ☺

Нагрузочное тестирование
Нагрузочное тестирование - обязательный этап сдачи проекта.
Нагрузочное тестирование является важнейшей процедурой подготовки крупного проекта к открытию.
Нагрузочное тестирование позволяет определить предел работоспособности созданного проекта именно на выбранном оборудовании.
Зачастую, простые корректировки конфигурации могут ускорить проект в 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 - серверов

Архитектура веб-кластера в одном ДЦ
Apache
PHP
«1C-Битрикс: Управление сайтом» - кластерная редакция
Балансировщик
nginx
(upstream module)
Сервер приложений 1
Apache
Primary
«1C-Битрикс: Управление сайтом» - кластерная редакция
Сервер приложений 2
Сервер MySQL Master
Сервер MySQL Slave
MySQL (Innodb/XtraDB)
MySQL (Innodb/XtraDB)
DNS серверы
Secondary
PHP

Резервируем сервер web-приложений
Apache
PHP
«1C-Битрикс: Управление сайтом» - кластерная редакция
Балансировщик
nginx
(upstream module)
Сервер приложений 1
Apache
Primary
«1C-Битрикс: Управление сайтом» - кластерная редакция
Сервер приложений 2
Сервер MySQL Master
Сервер MySQL Slave
MySQL (Innodb/XtraDB)
MySQL (Innodb/XtraDB)
DNS серверы
Secondary
PHP
upstream backend {
server app1.example.com max_fails=3 fail_timeout=30s;
server app2.example.com max_fails=3 fail_timeout=30s;
}
…
proxy_next_upstream error timeout http_500 http_502 http_503 http_504;

Резервируем базу данных

Отказал/отстал MySQL Slave
Apache
PHP
«1C-Битрикс: Управление сайтом» - кластерная редакция
Балансировщик
nginx
(upstream module)
Сервер приложений 1
Apache
Primary
«1C-Битрикс: Управление сайтом» - кластерная редакция
Сервер приложений 2
Сервер MySQL Master
Сервер MySQL Slave
MySQL (Innodb/XtraDB)
MySQL (Innodb/XtraDB)
DNS серверы
Secondary
PHP

Резервируем кэш

Резервируем файлы и каналы

Отказоустойчивая архитектура приложения
Через настройки платформы мы сделали эти сервисы - надежными:
База данных
Кэш
Файлы и ресурсы
Приложение может полагаться на их высокую доступность.

«Узкие» места

Веб-сервер
База данных MySQL
MASTER
«1С-Битрикс: Веб-кластер»
База данных MySQL
SLAVE 1
База данных MySQL
SLAVE N
База данных MySQL
SLAVE …
SQL-балансировщик
1С-Битрикс
Высокие требования к сети, связность серверов друг с другом

Балансировщик (клиентские запросы по HTTP)
Веб-сервер 1
memcached 1
Веб-сервер 2
memcached 1
MySQL
master
MySQL
slave
Ручные операции для восстановления master’а MySQL

Балансировщик (клиентские запросы по HTTP)
Веб-сервер 1
memcached 1
Веб-сервер 2
memcached 1
MySQL
master
MySQL
slave
Аварии на уровне целого датацентра или интернет-канала

Отказоустойчивая архитектура приложения
Учимся выдерживать отказ MASTER-БД:
Локальный мастер-мастер с переключением IP-адреса (скрипт или Pacemaker)
Локальный мастер + DRBD c переключением
Гео веб-кластер (active-passive) в другом ДЦ
Верстаем 2 красивые страницы-заглушки:
При ошибке соединения apache с БД (dbquery_error.php)
При недоступности apache/php-fpm за nginx

Отказал MySQL Master
Apache
PHP
«1C-Битрикс: Управление сайтом» - кластерная редакция
Балансировщик
nginx
(upstream module)
Сервер приложений 1
Apache
Primary
«1C-Битрикс: Управление сайтом» - кластерная редакция
Сервер приложений 2
Сервер MySQL Master
Сервер MySQL Slave
MySQL (Innodb/XtraDB)
MySQL (Innodb/XtraDB)
DNS серверы
Secondary
PHP

Особенности настройки MySQL:
auto_increment_increment
auto_increment_offset
Базы в разных датацентрах синхронны, при этом независимы друг от друга: потеря связности между датацентрами может составлять часы, данные синхронизируются после восстановления.
Необходимо группировать пользователей для работы в одном датацентре за счет управления балансировщиком.
Если сессии храним в базе, то не реплицируем их между серверами из-за большого траффика и возможных «локов»:
SET sql_log_bin = 0 … или …
replicate-wild-ignore-table = %.b_sec_session%
Используем master-master репликацию в MySQL

S3
Elastic Load Balancing
Web 1
Elastic Load Balancing
Dynamic
Web N
…
CloudWatch + AutoScaling
Web 1
Web 2
Web N
…
CloudWatch + AutoScaling
Вывод: резервировать надо все
S3
management, monitoring,
backup
Static
CDN
js, css
Dynamic
Static
CDN
js, css
images (clients)
images (clients)
local cache
local cache
local cache
local cache
local cache
control cache: memcached
mysqld
mysqld
mysqld
mysqld
mysqld
mysqld
master-master replication
master-master replication
master-master replication
mysqld
mysqld
mysqld
mysqld
mysqld
mysqld
mysqld
mysqld
mysqld
mysqld
mysqld
mysqld
control cache: memcached
control cache: memcached
control cache: memcached
control cache: memcached
control cache: memcached
Web 2
local cache

Если все-таки упали…

Исследование Strategic Research Institute
30% предпринимателей после утраты данных прекращают предпринимательскую деятельность в течение года.
60% предпринимателей, потерявших ВСЕ данные, прекращают предпринимательскую деятельность в течение 6 месяцев после этого.
Банкротство?
Риск потери данных

Бэкапы…
Для разных сценариев восстановления данных необходимо использовать разные бэкапы!
Снэпшоты дисков, LVM, образы виртуальных машин - для восстановления целых серверов или дисков.
Логические (mysqldump) и бинарные инкрементальные (Xtrabackup) бэкапы используются для восстановления отдельных баз или таблиц, поврежденных в случае некорректных операций в системе или ошибок пользователей.
Второй тип бэкапов делается на выделенном slave, на который не распределяется общая нагрузка. Тем самым ресурсоемкие операции создания бэкапов не влияют на работу пользователей.
Файловые бэкапы – tar.gz, bacula и т.д.
Файловые хранилища бэкапим в файловые хранилища или используем версионность

Бэкапы
Делайте бэкапы!
Разумно подходите к периодичности создания бэкапов и времени хранения резервных копий.
Обязательно имейте сценарии восстановления и проводите «учения».
Используйте «Облачный бэкап» в платформе «1С-Битрикс»