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

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

WEB SERVER. Права доступа к файлам и каталогам сайта.

Каждый системный администратор, которому доводилось управлять работой любого web сервера, сталкивался с несколькими проблемами связанными с разграничением доступа к файлам (будь-то скрипты, фотографии, js, css, и т.д.). Для начала рассмотрим типичные ситуации приводящие к проблемам в дальнейшем:
1. Ничего не делание или "я поставил сайт по инструкции производителя". Так, в основном, поступают начинающие администраторы или те, кому лень думать, а тем более, делать что-либо. Тоесть скачали, распаковали, положили сайт со скриптами, скажем, в /var/www/super-site, прописали конфиги web сервера, нового сайта для подключения к БД и все! Работа зделана и http://super-site.com.ua открывается, пользователи регистрируются, картинки и файлики заливаются - все работает!
2. Заливка файлов на сервер или "что-то пользователи не могут залить свои файлы на сервер!?". Ах, ну да, мы же не дочитали до конца, - там ведь написано, что web сервер должен иметь права на запись в папочку upload где-то в файловой структуре сайта. Не долго думая, ставим 0777 на нужную папочку и вот - файлики пишутся - проблема решена!
3. Совместная работа или "что-то программист Вася не может зделать необходимый ребрендинг нашего супер сайта". Да, оказывается Вася не может редактировать файлы в структуре сайта, - нет прав на запись. Не беда, - дадим Васе нужные права. Вот только не ясно, сколько таких Вась будет в дальнейшем, - да не будем заморачиваться и поставим на весь сайт права 0777. Вот - теперь программист Вася и его коллеги (вебмастер Коля, SEO оптимизатор Ваня) смогут безпроблемно поменять файлы в сайте так, как им надо. Вуаля!..

Для мало-мальски соображающих админов описанный сюжет - предверие апокалипсиса с данными сайта, а потенциально и со всем сервером. На выходе мы имеем набор каталогов и файлов которые может модифицировать/удалить любой пользователь системы в т.ч. и злоумышленник, проникший на сайт, от имени web сервера.

Поделюсь своим видением того, как правильно организовать разграничение прав доступа.
1. Самое главное в начале разработки модели доступа полностью описать все "действующие лица". Первое, что приходит в голову: собственно процесс web сервера (httpd/nginx/lighttpd/...) и персонал обслуживающий сайт на уровне прямого доступа к файлам (программисты, дизайнеры и пр.). Все вроде бы правильно, однако не стоит забывать, что есть ещё и системы резервного копирования, системы автоматизированного деплоймента, сторонние сервисы (как то ftp для прямого доступа к контенту сайта), и прочие.
2. Не менее важно правильное определение "узких" мест фаловой структуры сайта. Каталоги для записи пользовательского контента, разнообразных кешей скриптов, статических библтотек и прочего. Все эти места будут имет отличные от основной части права на доступ к своему содержимому.

Предположим в тестовой системе имеется несложный сайт с такой структурой:
/var/www/site
                |->application-core
                |->public-files
                     |->users-content
                |->cache
и имеем web сервер, 2-х программистов, одного дизайнера и систему резервного копирования.
Далее решаем задачу с правами пользуясь знаниями (man chown, man chmod, man usermod, bash scripting) и логикой описанной ниже.
1. Ясно, что для того, чтобы содержимое сайта было отображено клиенту необходимо, чтобы web сервер мог читать все необходимые ему файлы и входить в каталоги. Однако, старайтесь давать web серверу минимум прав и только там, где это нужно. К примеру, если вы после установки сайта запустили скрипт setup.php или install.php, по его завершении, уберите возможность web серверу читать этот файл - так вы обезопасите себя от возможности его повторного запуска. Собственно для того, что бы вев-сервер имел доступ на чтение файлов достаточно установить права на чтение (r) для всех файлов сайта для пользователей отличных от владельца/группы. Установите так же права на исполнение (x) для всех каталогов.
2. Дайте програмистам и дизайнеру почти полную свободу в доступе к файлам сайта, - зделайте для этих людей отдельную группу в системе (скажем, developers) и пропишите её как основную для каждого аккакунта (usermod -g вам в помощь). Назначте владельцем файлов и каталогов сайта кого-то из программистов и задайте им группу developers. Дайте полные права для владельца и группы (rw) для файлов, а для каталогов, - ещё и доступ на вход (x).
3. Не забывайте о том, что атрибут eXecute (x) - совершенно ненужная вещь для файлов сайта (конечно если это не cgi скрипты, которые необходимо запускать), а вот для каталогов - очень даже необходимая.
4. Систему резервного копирования можно по сути в разрезе прав доступа приравнять к веб серверу, - соответственно для её функционирования будет достаточно прав указанных в п.1
5. Есть ещё несколько каталогов в которые веб-сервер должен иметь возможность записывать файлы (загруженный пользователями контент, свои кэши и прочее) для них необходимо поступить с правами так: сделать их владельцем учётную запись от которой работает веб-сервер, группой назначить developers (см. п. 2). Владельцам и группе дать полные права (rw), а  для каталогов ещё и выполение (x), остальным пользователям системы дать доступ только для чтения (для системы резервного копирования).

Соблюдая такие простые правила можно легко обезопасить свой сайт от многих потенциальных угроз. Естественно, во многих случаях модель раздачи прав может быть достаточно более комплексной, но это уже предмет рассмотрения других статей.