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 сервер. (я планирую написать отдельную статью про это)

К одной из неочевидных выгод (выявлены при экплуатации танных техник) относится выявление следов взлома основного сайта по синхронизированным файлам, которые взломщик использовал в ходе проникновения и потом удалил на основном сервере.

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

G-WAN - модно, быстро, интересно!

Сегодня расскажу про G-WAN (http://gwan.ch/) - быстрый web сервер с закрытым кодом. Спасибо, в очередной раз, энтузиастам выпускающим интересные вещи, а именно сию поделку, которая без преувеличения поразила скоростью своей работы. Все администраторы web серверов так или иначе должны знать apache/nginx/lighttpd (не нужное зачеркнуть :) ) для того, чтобы вообще постороить web сервис. Но если эти киты индустрии давно на рынке, хорошо документированы, облизаны на всевозможных форумах и давно стали привычными в обиходе софтинками, то G-WAN представился "темной лошадкой" (проприентарный исходный код, вакуум в документации, минимум упоминаний на форумах и вообще - мало историй внедрений) после тестирования которой, так и захотелось на неё поставить!...

Итак:

• скачали (благо на сайте хоть и не самая свежая версия, но freeware)
• поставили (забудьте про configure/make - уже в бинарнике 32/64)
• настроили (только не теряйте голову сразу - тут нет привычного .conf файла, да и надобности в нем нету тоже)
• запустили (как говорится "из коробки")
• http://localhost:8080/?hello.c - вуаля, - вот вам и Hello World!

 Вся процедура занимает менее 3-х минут.

А теперь магия! Попробуйте проделать не сложный тест (предполагается, что у вас есть apache/nginx/lighttpd настроенный и работающий) - положить статическую картинку весом в 75к байт и запустить apache benchmark (ab):

ab -c 500 -n 10000 http://www.your-site.com/cool-image.png

как думаете что будет (если пренебречь ограничением по tcp сокетам, которые в среднем израсходуются где-то к 6-8к запросам)? Индеец загнется почти сразу остальные побарахтаются, но выдадут до 80% ошибок в ответах. А вот для G-WAN это вообще не проблема! Не спрашивайте как это работает (исходных кодов нету), но это работает!

Интересно? Продолжаем!

Вот как выглядит исходный код скрипта в ссылке (http://localhost:8080/?hello.c):

#include "gwan.h" // G-WAN exported functions

int main(int argc, char *argv[])
{
   xbuf_cat(get_reply(argv), "Hello World (C)");

   return 200; // return an HTTP code (200:'OK')
}

да, именно - это С! Тоесть вместо PHP/Perl и прочих скриптовых языков с медленными обработчиками, Вы можете писать сайт прямо на С/С++ и он будет работать в сотни раз быстрее, добавим к этому технологию edit & play (автоматическая перекомпиляция кода при правках) и получим некое подобие PHP для С-шников :) Вы спросите, а чем собственно это лучше чем CGI/FastCGI? А тем, что при изменении С кода Вам не нужна перекомпиляция (G-WAN делает это атоматом), в скрипте можно использовать массу встроенных в сервер возможностей как то: аналог memcache и прочее (полный перечень можно найти на сайте или в презентации http://gwan.ch/archives/g-wan_prez.pdf)

На данный момент я занимаюсь тестированием и возможностью внедрения сервера в production окружение. Пока только как static content server для других нагруженных проектов, но в дальнейшем в планах есть освоить методику написания сервлетов для этого сервера и использовать его для отдачи динамического контента.

Больше по теме:
http://www.wikivs.com/wiki/G-WAN_vs_Nginx

Ждите продолжения!

NGINX Сервер по-умолчанию.

...дабы не забыть и потом использовать!..

   С точки зрения SEO, для рабочего web проекта с 20к+ посетителей в сутки очень резонно, чтобы не было возможности ходить на ваш любимый сайт по IP-based url. То есть: если есть сайт http://www.goodsite.com, то ссылки вида http://123.123.123.123 (собственно IP адрес сервера где находится ваш сайт) не должны существовать вообще или должны редиректится с кодом 301 на соответствующие разделы вашего сайта.
   Почему это плохо:
1. Много сайтов используют domain name из url для перехода в соответствующие под-домены, разделы и др. и при введении ip адреса в качестве domain name будут вести себя не предсказуемо.
2. Поисковыми машинами ссылки на http://www.goodsite.com и http://123.123.123.123 будут фактически индексироваться как разные сайты.

Как быть? Достаточно просто:
В повседневной работе я использую сервер nginx Игоря Сысоева в качестве фронтэнда для всех своих проектов и на нем реализация схемы с редиректами проходит достаточно легко.



Собственно рассказывать про rewrite в nginx я не буду - писано уже много (google it!). А вот сама суть в директиве server_name: если указать в качестве имени сервера _ (подчёркивание), то при обращении к не существующему виртуальному хосту, будет отрабатывать именно этот сервер. Ну а внутри него можно разрисовать несколько условий в том случае если у вас много виртуальных хостов.