16 ноября 2012 г.

FALLBACK сервис для WEB портала - спасаемся от проблем!

В этом посте я постараюсь описать одну из техник применяемых мною в повседневной работе при администрировании web серверов. Быть может кому-либо будет полезным такой метод.
Итак, дано:
  • есть web портал (php scripts/mysql databases/static files)
  • необходимость минимального простоя в случае сбоев
  • надобность иметь резервные копии содержимого портала
Вроде бы и так все понятно - резервные попии делаются по расписанию (день, месяц, год, ...), правильно (инкрементный бэкап, сбросы на ленту/DVD,...)- данные не потеряются! Чего ещё надо?
А вот вам ситуация, при чем далеко не гипотетическая: Ваш замечательный сайт http://www.mysupersite.com уже в первой десятке поисковой выдачи, народ валит к Вам на ресурс, реклама дает прибыль, - вобщем ляпота! Вы заглядывая в аналитикс не можете нарадоваться, и все у Вас правильно, и резервные попии и девелопмент сервер для программистов есть и вооще, - все как должно быть. Но тут, внезапно, сайт не отвечает, доступа к серверу нету, а саппорт хостера сообщает, что у них потоп/перегрев/вырубилась хост машина VPS/пропали каналы связи (нужное подчеркнуть) или в сервере сгорели винчестера (сразу 4 в RAID10 :) ) или ещё 100 причин по которым конечные пользователи портала его не видят. Кошмар! Надо что-то срочно сделать, - резервные копии есть, - разворачиваем новый сервак и понеслась...
Знакомо? Многим - наверняка да. Сколько времени потратили? от 1-го ... 2-х часов до нескольких суток (если физически вышли из строя комплектующие сервера, а нового нету).

Как я спасаюсь от этого? все просто - fallback web server! Идея была позаимствована (и немного модифицирована) из практик использованя fallback MTA (вторичный почтовый сервер который занимается отложенной отправкой писем электронной почты).

В общих чертах шаги которые надо проделать таковы:
  1. Заводим второй сервер (физический, если Вы хотите в случае аварии на основном в полном объеме поднять сервис или VPS в случае если необходимо просто "перебится" пока восстанавливается основной сервер) желательно, конечно же не на одной хост площадке, дабы и резервный сервер не накрылся "медным тазом" при проблемах у хостера.
  2. Делаем первичну полную синхронизацию сервисов (ставим такие же версии php/mysql/apache и т.д.), файлов (переносим конфигурации сервисов, статику сайта, скрипты сайта, user uploads и т.д.), баз данных (дампим/ресторим) - в общем делаем почти полностью зеркало сайта - отличатся они будут только адресами.
  3. Включаем master-slave репликацию для MySQL (в моем случае. подробнее: http://dev.mysql.com/doc/refman/5.0/en/replication.html) или подобные техники в любом другом любимом Вами сервере баз данных. Важно, чтобы в результате данные в базах в любой момент времени были синхронны.
  4. Пишем простецкие скрипты на bash с использованием rsync (подробнее: http://rsync.samba.org/) для синхронизации файлов на fallback сервер. Но, не забудьте грамотно выстроить процедуру синхронизации, так как  для очень большего количества файлов в проекте эта процедура может занять много времени, - стоит синхронизировать сайт частями в разное время (редко изменяющиеся скрипты сайта - раз в сутки ночью, файлы пользователей - раз в 1-2 часа.). Подскажу, сразу волшебную опцию для rsync: --bwlimit=<N> Kb/S - без неё вы просто "уложите" основной сайт при синхронизации данных!
Я умышленно не привожу готовых скриптов, примеров конфигураций и пр., для того, чтобы отсеять "linux эникейщиков" молодых администраторов не очень любящих думать своей головой.

После всего Вы получите сервер готовый в любой момент заненить вышедший из строя боевой. Как это сделать? Либо в мануальном режиме (заменить DNS/поменять IP на сервере если можно), либо в полуавтоматическом режиме (watchdog скрипт для мониторинговой системы), либо в полностью автоматическом (Keepalived/Heartbeat и прочие техники)

Каковы ещё выгоды от наличия такого сервера? Из очевидных:
  • Возможность делать резервные копии с fallback сервера не нагружая при этом основной боевой, что очень критично при дампах баз, которые могут блокировать таблицы
  • Быстрое восстановление работоспособности портала в случае серьёзных проблем на основном сервере.
  • Возможность проводить тестирование новых сервисов портала в боевых условиях (с оглядкой на проблемы с репликацией баз данных, подробнее: http://dev.mysql.com/doc/refman/5.0/en/replication-features.html)
  • Возможность при запредельной нагрузке на основной сервер, перераспределить нагрузку на fallback сервер. (я планирую написать отдельную статью про это)
К одной из неочевидных выгод (выявлены при экплуатации танных техник) относится выявление следов взлома основного сайта по синхронизированным файлам, которые взломщик использовал в ходе проникновения и потом удалил на основном сервере.

В любом случае - резервные копии  никогда не мешали! Удачи, - берегите сервера.

Комментариев нет:

Отправить комментарий