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

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

Александр ДемидовРуководитель направления арендных решений

«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С-Битрикс»

Спасибо за внимание! Вопросы?

Александр Демидов

demidov@1c-bitrix.ru

+7-926-521-3700

@demidov

http://www.1c-bitrix.ru