Upload
philip-clements
View
57
Download
5
Embed Size (px)
DESCRIPTION
Запуск и эксплуатация веб-проектов. Александр Демидов Руководитель направления арендных решений «1С-Битрикс». «На старт…». Каким будет новый проект?. Разные классы сайтов и веб-сервисов: Домашние странички, личные блоги и т.п. «Продающие» сайты (интернет-магазины) - PowerPoint PPT Presentation
Citation preview
Запуск и эксплуатация веб-проектов
Александр ДемидовРуководитель направления арендных решений
«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 Гб 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.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 %utilxvde 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00xvdj 0.00 0.00 0.00 13.00 0.00 464.00 35.69 0.07 5.50 1.42 1.85xvdi 0.00 0.00 0.00 13.00 0.00 464.00 35.69 0.09 7.27 1.50 1.95xvdh 0.00 0.00 0.00 39.50 0.00 1436.00 36.35 0.17 4.39 0.76 3.00xvdg 0.00 0.00 0.00 39.50 0.00 1436.00 36.35 0.21 5.32 0.84 3.30xvda 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00xvdo 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00xvdn 0.00 0.00 0.00 16.50 0.00 468.00 28.36 0.16 9.64 0.97 1.60xvdm 0.00 0.00 0.00 16.50 0.00 468.00 28.36 0.15 8.88 0.88 1.45xvdl 0.00 0.00 0.00 12.50 0.00 328.00 26.24 0.16 12.68 1.72 2.15xvdk 0.00 0.00 0.00 12.50 0.00 328.00 26.24 0.10 7.64 1.16 1.45md0 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
# <file system> <mount point> <type> <options> <dump> <pass>
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 = 0sync_relay_log = 0sync_relay_log_info = 0
max-connect-errors = 10000
Надежность
innodb-file-per-table
# Perconainnodb_lazy_drop_table = 1
Но… Очень ресурсоемкие операции schema changes (ALTER TABLE…, DROP DATABASE… и т.п.).
Но… Гибкость в обслуживании базы (например, DROP – на самом деле освобождает место).
Скорость
# временные таблицы – в памятиtmpdir = /dev/shm
# меньше DNS запросовskip-name-resolve
# размер временных таблиц в памятиmax-heap-table-size = 64Mtmp-table-size = 64M
# зависит от max_connections# если много – лучше несколько инстансов mysqldtable-cache = 4096table_definition_cache = 4096
# выделяется сразу на запросы без индексовjoin-buffer-size = 32M
Query cache
# много – тоже плохоquery-cache-size = 128Mquery-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 > 1Gbinnodb_buffer_pool_instances = 4
innodb_log_file_size = 512M innodb_log_buffer_size = 32M
# на быстрых дисках; можно экспериментироватьinnodb_read_io_threads = 16innodb_write_io_threads = 16innodb_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 = FILEslow-query-log = 1slow-query-log-file = mysql_slow.loglong-query-time = 1
#perconalog_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: 4UPDATE 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:105;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
Резервируем кэш
Резервируем файлы и каналы
Отказоустойчивая архитектура приложения
Через настройки платформы мы сделали эти сервисы -
надежными:
База данных
Кэш
Файлы и ресурсы
Приложение может полагаться на их высокую доступность.
«Узкие» места
Веб-сервер
База данных MySQLMASTER
«1С-Битрикс: Веб-кластер»
База данных MySQLSLAVE 1
База данных MySQLSLAVE N
База данных MySQLSLAVE …
SQL-балансировщик1С-Битрикс
Высокие требования к сети, связность серверов друг с другом
Балансировщик (клиентские запросы по HTTP)
Веб-сервер 1
memcached 1
Веб-сервер 2
memcached 1MySQLmaster
MySQLslave
Ручные операции для восстановления master’а MySQL
Балансировщик (клиентские запросы по HTTP)
Веб-сервер 1
memcached 1
Веб-сервер 2
memcached 1MySQLmaster
MySQLslave
Аварии на уровне целого датацентра или интернет-канала
Отказоустойчивая архитектура приложения
Учимся выдерживать отказ 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_incrementauto_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
DynamicStatic
CDN
js, css
imag
es (c
lient
s)
imag
es (c
lient
s)
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 replicationmysqld
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С-Битрикс»
Спасибо за внимание! Вопросы?
Александр Демидов
+7-926-521-3700
@demidov
http://www.1c-bitrix.ru