Системное администрирование

индекс
199,96

Отказоустойчивая система из мусора

Собственно история была такова.
Для одной фирмы N необходимо было разработать дешевую и надежную систему хранения и обработки данных. Вкратце про данные. Необходимо принимать с клиентов информацию (упущу какую именно, что-то вроде налоговой отчетности) и хранить ее долгие годы. Достаточно часто требовался поиск по этой информации и еще более часто модификация данных, внесенных за последние пару часов. Потеря информации недопустима ни в каких случаях. В том числе при пожаре или землетрясении. Раньше все это делалось на бумаге и хранилось в боооольших папках. Для разбора папок существовал целый отдел бессмысленных и беспощадных людей.

Все это предстояло перенести на автоматизированную основу. Самое интересное – разработку оплачивали вполне пристойно, а вот на железо денег не выделили вовсе – попросили чтобы все это подняли на имеющемся железе. Парк машин состоял из десятка морально мертвых монстров и именно на них надо было поднять БД-сервер и бэкап сервер.


Машины представляли собой в основном P3, 128mb оперативной, 16mb видео, 10гб винт. То есть не эталон сервера, мягко говоря.

Бэкапить предлагалось каждую запись – то есть зеркалить БД-сервер и бэкап-сервер. Учитывая объемы данных и неповоротливость машин при первых же тестах это показало неприятно долгие результаты при выборке из БД. Сама база, кстати, не сильно способствовала скорости работы, ибо была полностью нормализирована и компактна.
Так как редактирование записей в БД было достаточно частым, это вызывало неудобство.

После мозгового штурма было решено несколько извратиться.
Итого в итоге:
Сервер А. Основной рабочий сервер системы, хранит Базу за текущие сутки и выполняет всю основную логику.
Сервер В. Второй сервер, хранит базу за все время, не считая текущих суток. В полночь данные из А переливались в В. Тут лежат скрипты составления отчетов по периодам.
Сервер С. Бекап сервер. После перелива в полночь бекапил В, стирал стары й бекап. И зеркалил А во все время работы.

Итого: при потере любого из серверов у нас оставалась вся информация. То есть А+В или С.

Сервер С поселили отдельно на случай ЧП(заказщик тот еще параноик)

На всех серверах стоял линукс, апач и мускул. Основной код написан на PHP, бэкапы на Питоне.

Пожара не случилось, землетрясения тоже. Все прекрасно работает второй год. Позже была дописана «красная кнопка» — возможность работы на свой страх и риск при потери одной из машин. Вроде не пригодилась)

Думаю это велосипед или излишняя паранойя, но все работало, выдержало все краштесты и все остались довольны.

%username%, а как бы ты улучшил эту систему?

UPD: посоветуйте, в какой блог перенести.
+18
18 марта 2010, 13:34
31

комментарии (27)

+16
Hemul #
ситуация знакомая. Я в подобных случаях шел к начальнику, брал его за рукав и доверительно глядя в глаза объяснял, что, да, в принципе можно все поднять и на этом железе и оно даже будет как-то работать. Но! Железо старое, запчастей на него нет и не будет уже никогда. Любая самая малая поломка все равно приведет к необходимости покупки новой техники, но уже в авральном режиме, без выделенного заранее финансирования и под непрерывные вопли пользователей. Оно надо? А если не надо, то вот, пожалуйста, смета и счет, вот тут распишитесь, да. Как это зачем? Это запасные кулеры, память, процессор и диски. А то ведь и новая техника рано или поздно устареет…
+1
WildWolf #
Полностью с вами согласен)
Примерно так же мы все это и описывали клиенту, но, однако, эффекта не возымело.
К тому же заказывали именно разработку ПО для этого всего. Так что требовать другое железо было несколько не актуально…
0
charon #
то есть вы при разработке ПО никогда не ставите ограничений на железо и готовы создавать софт хоть под 80286?
–4
romx #
Вот! Слова не мальчика — но мужа. :)

Творчество «из говна и палок» оставим «мальчикам». :)
НЛО прилетело и опубликовало эту надпись здесь
+3
Crankoman #
было бы круто если бы вы еще хранили избыточные бекапы на комьпютерах пользователей в зашифрованном виде и все это по p2p распространялось
НЛО прилетело и опубликовало эту надпись здесь
0
WildWolf #
Ну отдельно ручкам где-то раз в месяц и снимался бекап на внешний хард и запирался в сейф. Подозреваю что после пары месяцев тамошнему админу стало лениво, но пока я это сопровождал — бекапили)
0
Speakus #
Разговор ведь про автоматизацию. Ручками, ясно дело, можно и по бумажным папкам раскладывать ;)
0
Fi1osof #
Сервер А. Основной рабочий сервер системы, хранит Базу за текущие сутки и выполняет всю основную логику.
Сервер В. Второй сервер, хранит базу за все время, не считая текущих суток. В полночь данные из А переливались в В. Тут лежат скрипты составления отчетов по периодам.
Сервер С. Бекап сервер. После перелива в полночь бекапил В, стирал стары й бекап. И зеркалил А во все время работы

Честно сказать крайне сомнительная система получилась. А где бэкап на текущий момент? Без пяти минут день закончился, а тут хард летит к чертям. Что тогда? где резерв данных на текущие сутки? Standby-сервак надо поднимать.
+1
WildWolf #
Бекап на текущий момент лежит на С.
То есть бекап до полуночи + бекап А.
0
Fi1osof #
в режиме риал-тайм зеркалит? То есть прошла транзакция и тут же она отражена на серваке С?
+1
WildWolf #
Да. Запрос отправлялся одновременно на оба сервера и с обоих ожидался ответ о завершении транзакции.
На удивление не сильно мешало работе.
0
Fi1osof #
на самом деле не совсем правильно… сбои вероятны как на сервере А, так и на С.
Реально покапайте о Standby-серверах. Даже Мускул сейчас поддерживает. Геморно поставить (под Мускул точно не скажу, под Оракл поднимал), но это стоит того. Вероятность ошибок стремительно близится к нулю. В случае выхода основного сервера, Стэндбай переводим в режим мастера и продолжаем с ним работать, поднимая при необходимости параллельно новый стендбай.
0
eugenets #
А почему не с помощью репликации? Или хотелось 100% синхронности?
0
WildWolf #
Не понравилась асинхронность. Возможно это и паранойя, но хотелось иметь полностью актуальный бекап в момент попадания шваброй по серверу )
+1
eugenets #
Звучит разумно :) Хотя странно, что репликация не может предоставить такой возможности сама. С другой стороны, наверное проще написать функцию дублирующую запрос чем настраивать репликацию. Но зато репликация уже отлажена, а эту систему пришлось отлаживать и проверять, что она всегда генерирует идентичные базы, самостоятельно.
+2
Denisio #
Если заказчик не готов потратить хотя бы одну месячную з-п программиста на железо — такой заказчик сам себе злобный буратино. Потом будет еще продолжительно время трахать мозг на предмет проблем и нюансов, обусловленных старым железом.
+1
DIegoR #
www.taobackup.com/
хозяйке на заметку
–1
kapers #
не совсем понятна тема бекапа на python
чем mysqldump не устроил?
0
WildWolf #
Скриптами выполнялась проверка целостности поле бекапа и построение логов на день.
Ну а в общем они были оболочкой к тому же mysqldump )
0
kapers #
а расскажите, пожалуйста, что имеется в виду под целостностью бекапа?
0
WildWolf #
Прошу прощения, отпечатался — «целостности поCле бекапа»
Ведь мы сшиваем два базы в одну, фактически — вот на всякий случай и проверяем равен ли результат сумме слагаемых.
P.S. Сразу оговорюсь что питоновскую часть писал не я — ток что возможно там был еще какой нибудь функционал.
+1
NetS #
Купите хотя бы несколько новых винтов…
0
WildWolf #
Учитывая что нагрузка не критична — поставили несколько недорогих новых IDE дисков из имеющихся в продаже на тот момент. На этом апгрейд железа и кончился…
–1
imil #
«Пожара не случилось, землетрясения тоже. Все прекрасно работает второй год» — а искусственно ЧП вы хоть раз организовывали?
Если нет, то как знать, вдруг до сих пор все работает только по стечению обстоятельств.
0
WildWolf #
«выдержало все краштесты»
Естественно, дергали швабрами все что можно, вырубали на горячую сервера в произвольном порядке, подсовывали подбитые бекапы, в конце концов гоняли во время работы несколько фильмов по сети во всех направлениях и загружали процессоры на максимум чем нибудь бессмысленным. Ни одного нештатного сбоя и не прогнозируемой ошибки. Система держалась молодцом)

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.