Делать чтобы ...

quagga

2011-01-29T20:21:00.000+02:00

Уже некоторое время борюсь со странным поведением ospfd из пакета quagga. При работе в сети построенной с использованием нескольких виртуальных машин на базе kvm (сеть у меня работает в forward mode='route') через время отдельные ноды отваливаются и в логах оspf видно массовое
2011/01/29 19:51:57 OSPF: Packet[DD] [Slave]: Neighbor 10.99.234.102 packet duplicated.
которое заканичается пропажей маршрутов на хромой ноде и пропаже её маршрутов из анонсов. Почему происходит - понять не удалось, гугление не помагает. Лечится только рестартом сервиса на больной голове.

Сегодня увидел что в "виртульных убунтах" вовсе не последняя quagga. Собрал последнюю и поставил. Посмотрим, чем закончится.

Египет и инернет

2011-01-29T19:57:00.000+02:00

Незнаю, что там арабы-революционеры делали со своими роутерами и интернетом, но через зону ответствености Telia.net трафик с 11:00 шел мудрено. Правда где-то часа за два порешали.

Списки пакетов в debian like дистрах

2011-01-23T21:53:00.000+02:00

Если надо список пакетов установленных на одной машине установить на другую делаем так:

root@apps1:~# dpkg --get-selections > file

root@apps0:~# dpkg --set-selections < file
root@apps0:~# apt-get dselect-upgrade

И оПа. Оно всё выкачивает и ставит.

OSPF, фильтр маршрутов

2011-01-06T18:51:00.001+02:00

Если есть vpn сеть в которой маршрутизацией управляет ospf и при этом vpn строится поверх интернет каналов, возникает проблема - без дополнительных танцев ospf будет анонсировать в сеть маршруты связанные с белыми адресами (теми которые нам даёт провайдер). А нам нафиг не надо чтобы нода А считала что белый адрес ноды Б виден через VPN. Для того чтобы оставить то что нам надо я делаю в quagga такой трюк:

ospfd.conf
==============================================
redistribute connected route-map inner
redistribute static route-map inner

ip prefix-list ospf-inner seq 10 permit 10.0.0.0/8 le 32
ip prefix-list ospf-inner seq 40 deny any

route-map inner permit 10
match ip address prefix-list ospf-inner
==============================================
В этом случае будут анонсироваться только маршруты из 10.0.0.0/8 сети. Что и необходимо.

Годная статья по самоподписанным сертификатам

2011-01-05T19:16:00.001+02:00

http://www.akadia.com/services/ssh_test_certificate.html

Безпарольная авторизация - Очень полезная штука

2011-01-05T18:05:00.000+02:00

ssh-copy-id -i ~/.ssh/id_rsa user@example.com

Таким образом можно скопировать свой публичный ключ на удалённую систему.

Естественно что ~/.ssh/id_rsa должен быть в наличии.

Если его нет, создать можно ssh-keygen -t rsa

Если всё пройдёт успешно, то при входе на удалённую систему ssh использует ключ

и не будет запрашивать пароль.

Настраиваю новый сервер...

2011-01-05T15:01:00.000+02:00

... рейда нет естественно. Вот хорошая комманда

sfdisk -d /dev/sda | sfdisk /dev/sdb

копирует таблицу разделов одного диска на другой

Брижка или Бритьё

2010-12-18T14:08:00.000+02:00

Вот откуда пипел узнает что ему нужно брить физиономию 5-ти лезвийным станком (за много денех) если ему об этом не рассказать. Самое смешное в том, что пиплу может и не нужно, но если долго повторять, да еще показывать как круто этой бритвой шорхают по лицу смазливые педерасты (в телевизоре) то только последний кретин не поймёт - что морду надо мазать именно гелем А и бриться станком Б с вибратором и кучей лезвий. А еще станок можно подарить например на новый год (особенно такому задроту как я) и не дорого и сердито. Лично мне станки дарили 5 раз. Их судьба была одинакова - мучался где-то неделю, потом покупал обычный одноразовый, однолезвийный Bic и не ёб себе мозги. В результате как-то так и сложилось - любой одноразовый станок у меня работает куда дольше чем навороченное чудо технологий. И матюков при бритье дешевкой слышится куда меньше.
А уж про пенки и гели - совсем прикольно. Чем мою голову, тем и мажу бороду. Обычный шампуть -
1. Всегда под рукой (в отличии от пенки или геля которые кончаются твари когда попало)
2. Работают, для меня, реально лучше этих гелей и пенок.
3. Цена - еще меньше.

Кстати, вообще думаю купить себе опасную бритву. И морду бреет и в других ситуациях пригодится. :)

А выводы какие? Всё очень просто - сформировался класс ~~специалистов~~ пидорасов которые за мои-же деньги впарят (ну или постараются впарить) ненужную мне поебень. Как страшно жить!

KVM

2010-12-11T18:32:00.001+02:00

ubuntu-vm-builder kvm hardy \
                  --domain vm1 \
                  --dest /vm/1 \
                  --arch i386 \
                  --hostname vm1 \
                  --mem 1024 \
                  --user master \
                  --pass А вот хуюшки! Не скажу \
                  --ip 192.168.122.101 \
                  --mask 255.255.255.0 \
                  --net 192.168.122.0 \
                  --bcast 192.168.122.255 \
                  --gw 192.168.122.1 \
                  --dns 192.168.122.1 \
                  --rootsize=10000 \
                  --swapsize=4000 \
                  --components main,universe \
                  --addpkg openssh-server \
                  --libvirt qemu:///system ;

Создаёт kvm гостя с установленной ubunu 8.04. Однако почемуто попасть на него через openssh-server низя (он оказывается не установлен). Хотя английским по белому написано --addpkg acpid vim openssh-server. Приходится делать

virsh --connect qemu:///system
потом
edit vm1
Прописывать

Заходить туда через "Просмотрщик удалённых столов" и поднимать ssh сервер руками.

up
--addpkg acpid vim openssh-server это неправильно
надо --addpkg openssh-server
тогда всё нормально и сразу входиш.

Мониторинг

2010-11-27T19:45:00.001+02:00

Хороший хозяин должен всегда иметь актуальную информацию о том что там у него на хозяйстве происходит. В этом вопросе никак не обойтись без системы мониторинга. Первый раз о том что мне необходима обратная связь я задумался года так 4ре назад, и тогда-же занялся подбором соответсвующих инструментов. Естествено сначала был создан примерно такой список задач которые подобный инструмент должен решать:
1. Собирать наборы целочисленных и дробных значений, тестовые записи
и предоставлять возможность работы с собранной информацией.
2. Расширяться (набор и типы счётчиков которые сохраняются в системе должен расширяться)
3. Полностью настраиваться через ГУИ
4. Не создавать проблем
5. Уведомлять о интересующих меня событиях.

Финалистами выбора стали nagios и zabbix. Плюсы нагиоса я так и не понял. Выглядело оно как конструктор "сделай сам". Я ленив и не люблю ковыряться массе опенсорсных кубиков, которые вроде что-то делают но насколько хорошо непонятно. И совсем непонятно какие их этих кубиков надо взять чтобы получить искомое. От вида гуйни нагиоса хотелось рыгать, возможно сейчас что-то и поменялось но тогад все было очень грустно. Zabbix в этом случае имел куда больше плюсов просто за счет того что представлял собой комплексное решение - всё в одном. А полная конфигурация обьектов мониторинга через ГУИ меня вообще сразила. В общем я пользуюсь Zabbix уже достаточно давно и более чем доволен результатом. Каждый обьект который подключается в систему заносится в соответствующую категорию в результате чего по данному обьекту накапливается специфичная для категории информация и срабатывают тригера по интересующим меня событиям. В любой момент я могу посмотреть график изменения состояния счётчиков (к примеру среднее время обработки запросов с клиентских АРМ), а текущее состоянии системы я всегда вижу через dashboard. Информация о том что я считаю проблемой приходит мне на почту. При этом доступ к информации я могу предоставить и своим клиентам, выставив им права только на их обьекты (клиентов-то может быть несколько).
В общем я себе не представляю более мене серьёзную систему без мониторинга.

Сетевая инфраструктура предприятия

2010-10-23T20:16:00.001+03:00

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

В описанной стуации были использованы таки принципы построения сетевой инфраструктуры:

Все клиенты и сервера объединены в единую приватную сеть к которой подключаются через интернет.
Рессурс (сервис) который необходим клиентам получает IP адрес в приватной сети (10.0.0.0/24). Естественно на одном сервере (железке) вполне может крутиться N сервисов. На интерфейс lo вешаем нужное количество алиасов на которые биндим сервисы. По заданному адресу клиенты обнаруживают искомый сервис. Вопрос, - "откуда клиенты знают с каким сервисом им надо общаться?", не имеет отношения к данному посту.
Сервера используют OSPF для того чтобы внутри приватной сети анонсировать повешенные на них адреса.
Есть ряд особых серверов - точек входа. Благодаря этим серверам клиент имеющий интернет подключается в приватную сеть. Наличие несольких точек входа повышает живучесть сети. Если одна точка будет снята на техобслуживание клиенты смогут подключиться к приватной сети через другую точку входа.

При использовании такого подхода мы получаем максимально устойчивую, самоорганизовывающуюся сеть. В такой сети клиент не получит сервис только если конечная железка, реализующая требуемую клиентом функциональность, вывалится из сети. Обеспечение живучести поставщика сервиса я уже описывал ранее. Кстати такой уровень живучести не всегда и нужен. :)

Пакет OpenVPN незаменимый помошник в организации сети по таким принципам - он умеет перебирать сервера по списку! Короче моя схема работает так - есть N серверов (точки доступа) принимающих подключения клиентов, причем клиентами в данном случае выступают как люди, так и другие сервера (те которые рессурсы предоставляют). Подключаясь к определённой точке доступа, клиент получает IP адрес в приватной сети. К какой точке подключился - такой адрес и получил. Я пользовался такой схемой - 10.X.YY.ZZ, Где X - номер точки доступа а YY.ZZ фиксированный номер данного клиента. Каждый раз при регистрации в системе нового клиента ему выделялся номер, который по совместительству являлся последними двумя октетами в VPN IP адресе клиента.

OpenVPN сервера с помощью OSPF анонсируют обслуживаемые ими сети (10.X.0.0/16) внутри vpn, что позволяет любому узлу приватной сети иметь ping на любой узел приватной сети (файерволы не считаем). Когда к OpenVPN, сети поключается сервер (провайдер рессуров) он анонсирует все алиасы которые на него повешены, в результате чего все участники Vpn видят его и могут с ним работать ...

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

Есть конечно и один минус - не факт что это оптимально, все информационные потоки проганять через конечное число служебных серверов. Но ведь, для совсем страшных случаев, это можно решить объединив пару серверов прямым туннелем и понизив его cost в OSPF.

Больше всего в этой кухне мне нравится то, что поставщики рессурсов не имеют постоянных белых адресов! Т.е. атаки из интернета на железо хранящее жизненно важную информацию практически исключены. Конечно постоянные адреса точек доступа доступны для DDOS, DOS и прочих атак, но это уже совсем другая история.

Стандарты, мать их....

2010-10-19T20:58:00.000+03:00

Есть еще такая штука называется WSDL - поидее должен помочь пацанам предоставляющим XML ориентированные WEB сервисы в их публикации. Т.е. если я хочу чтобы мой сервис юзали третьи дядьки я разрисовываю WSDL по своему сервису и довольный стригу бабло с его пользователей. Что мы видим здесь - http://www.w3.org/TR/wsdl. Здесь мы видим что первый драфт вышел в 2001 году. И что? И нихуя! Прошло 9ть ёбаных лет! А для того чтобы кто-то начал дёргать меня за Web-сервис, WSDL нахуй не упал. Этож блять его знать надо!

- Вы нам лучше нагенерьте примеров XML запросов и ответов, мы их будем руками.
И если бы это был единичный случай....

PS А люди мучались, придумывали...
PPS А другие писали инструментарий рожали, чтобы типа wsdl2java еблысь, и всё готово....

Serviceability, миграция

2010-10-18T22:20:00.001+03:00

Итак я снова вернулся к настройке кластера, а именно к вопросам миграции сервиса с ноды на ноду в случае каких либо сбоев. Ситуация оставалась прежней - heartbeat отказывался пускать в кластер выздоровевшую голову и ответ на "главный вопрос" (что делать если головы не видят друг друга, но видят внешний мир?) не находился. Чтение документации по pacemaker+heartbeat ответа так и не дало. Как правило вся документация рассказывает как делать (тактика) и маловато внимания уделяет вопросу что и почему делать (стратегия и философия ;) ). Хотя конечно я дочитался до понятия "кворум", но даже сейчас не знаю до конца как оно работает, и делает ли то что мне нужно. Кроме того, поскольку, выздоровевшая голова сама в heartbeat кластер так и не входила, я решил было пересобрать всё с использованием OpenAIS стека, но одумался - времени на эксперименты вовсе не оставалось. В этот момент у меня были сформированы такие принципы работы кластера:

Обе головы обмениваются пакетами каждую секунду.
Каждая голова следит за соседкой с целью обнаружить отвал соседки. (Если от соседки не приходят пакеты N секунд она отвалилась)
Обе головы шлют пакеты не только друг другу но и арбитру
Арбитр тоже следит за "отвалом" голов.
Арбитр размещается так чтобы смотреть на головы кластера с точки зрения его клиентов.
И головы и арбитр ведут карту видимости заполняя её данными на базе принятых пакетов.
Голова считается вышедшей из кластера если её не видит ни арбитр ни соседка. Такая ситация считается достоверным выходом из кластера. Ситуация если проблемную голову видит или арбитр или вторая голова такая ситуация считается недостоверным выходом и не рассматривается.
Есть default master и default slave головы. Default master при прочих равных захватывает master роль в кластере.
Событие достоверного выхода головы из кластера является причиной принимать решение о миграции сервиса

Есть три действия которые могут выполнять головы кластера:

initial_start - начальное состояние
promote - захват мастер роли (запуск сервисов, перевод drbd в primary, установка ip адреса кластера)
demote - выход из мастер роли - (остановка сервиса, перевод drbd в secondary, удаление ip адреса кластера)

Данные действия выполняются по таким правилам:

Если голова только запустилась она выполняет initial_start
После initial_start, голова настроенная как default master должна выполнить promote, если в кластере нет другой головы играющей в данный момент мастер роль, но только тогда когда данная голова стала частью кластера (видит хотя-бы арбитра).
После initial_start, голова настроенная как default slave не будет делать promote.
Любая голова делает promote в случае достоверного выхода из кластера головы играющей мастер роль.
Master голова делает demote в случае если она достоверно установила что вывалилась из кластера (не получает пакеты ни от арбитра ни от соседки).

Данная система правил применима только для варианта кластера состоящего из 2х нод (мастер/слейв) и арбитра. Основные хинты - арбитр повышает достоверность информации о выходе головы из кластера, ранний demote который нода делает сама себе уменьшает цену ресинхронизации при возврате головы в кластер. STONISH уже ненужен.

В результате у меня получилось 5 скриптов:

ecmd.pl - сам демон который запускается на головах и арбитрах. Собственно он и работает.
ecm.pl - утилита получения состояния (чтобы это добро прикрутить к zabbix)
initial_start.sh - скрипт запускающий базовые сервисы (drbd в secondary режиме,...)
promote.sh - скрипт переключающий drbd в primary, монтирующий файловую, запускающий сервисы (БД и Аpps), устанавливающий IP адрес,...
demote.sh - действие обратное promote.sh. Убрать IP, остановить сервисы, отмонтировать файловую, drbd в secondary.

В таком виде это сейчас и крутится.

Перед запуском в продакшин особо доставил провайдер. У него шли какието работы по сети и ДЦ, в следствии чего мониторинг постоянно фиксировал физические перезагрузки железа (средний аптайм - полтора дня) и периодические минутные пропадания пингов на оба сервера. Кластер работал, мониторинг рисовал регулярные headswitch'и, (вплоть до 4-5 в час) при этом Сервис оставался работоспособным. Один раз примерно на 10ть headswitch'ей пришлось вывести drbd на слейв ноде из splitted brain о котором проорал мониторинг. Вход в splitted brain для drbd отвалившегося мастера вполне возможная ситуация (главное что выход из неё прост и ситуация отлично обнаруживается мониторингом).

В общем оно так и будет работать до тех пор пока я не разберусь с понятием quorum, не заставлю ноду входить в heartbeat кластер после офлайна (или не перейду на стек openais), не убежусь что pacemaker реализует те концепции которые мне нужны (или не пойму что я дурак и хочу странного). В общем есть над чем подумать....

Serviceability, дисковая подсистема

2010-10-17T22:31:00.002+03:00

Заморочившись с реализацией миграции сервиса между головами я решил переключиться на выбор технологии синхронизации данных в базе между головами кластера. Выборов было несколько:

Выбор был остановлен на дисковой репликации, а именно пакете drbd. Основной фактор который повлиял на выбор - минимум настроек , минимум адиминистрироваия и как следствие простота решения. (На чтении документации по слонам я скис очень быстро). Минусом drbd является довольно высокий обьём передаваемого трафика (особенно на фазе синхронизации), кроме того, постгрес пишет данные и в transaction log и в таблицы базы данных, потому фактически по сети гоняется двойной обьём. Опять-же и нагрузка на мастер (процессор и дисковая) повышается...

Реплицировать постгресовы WAL'ы. Метод уже пробовали и он меня не устраивает, по условиям задачи.
Использовать один из имеющихся пакетов репликации для Postgresql. Пришлось отказаться в связи с повышением нагрузки на мастер-сервер (как правило все такие пакеты реализуется на тригерах), большей сложностью решения как такового, необходимостью выполнять хитрые трюки в случае модификации структуры базы данных (что приходится делать регулярно), усложнением администрирования, плюс есть такие стрёмные штуки как select в котором вызывается строед процедура. В общем даже если забить на нагрузку и администрирование и всё всё всё прочее, такую репликацию пришлось бы тестировать именно на нашей базе данных.
Использовать репликацию операций записи на диск.

Выбор был остановлен на дисковой репликации, а именно пакете drbd. Основной фактор который повлиял на выбор - минимум настроек , минимум адиминистрироваия и как следствие - простота решения. (На чтении документации по слонам я скис очень быстро). Минусом drbd является довольно высокий обьём передаваемого трафика (особенно на фазе синхронизации), кроме того, постгрес пишет данные и в transaction log и в таблицы базы данных, потому фактически по сети гоняется двойной обьём. Опять-же и нагрузка на мастер (процессор и дисковая) повышается...

Как показали лабораторные опыты дисковая репликация успешно справлялась с поставленной задачей. Кластер устойчиво реагировал на временные отключения слейв ноды, и по мере её подключения в сеть автоматически выполнял её синхронизацию с мастером. Довольно просто так же происходило переключение режима головы из мастера в слейв и обратно без выхода из синхронного состояния. Так-же был протестирован вход кластера в состояние splitted brain и выход из него с перетипанием выбранной ноды. Всё необходимое по данной тематике было прочитано на http://www.drbd.org/. У DRBD действительно хорошая документация, некоторые вопросы были связаны с выбором протокола (A,B,C). В данный момент я остановился на полностью синхронном C (в котором и гонял полигон), может быть в дальнейшем перейду к "более асинхронному" протоколу A, но только если задержка будет создавать мне проблемы.

Serviceability трудности выбора

2010-10-17T18:58:00.000+03:00

Итак, приняв решение организовать кластер ~~с блекджеком и шлюхами~~ я сформировал несколько условий его работы влияющих на выбор решения:

Головы кластера (железки) должны размещаться только в территориально разнесённых дата центрах (в идеале у разных провайдеров). (Минимизируем влияние аварий на подстанциях).
Цена вопроса. Мой заказчик не станет платить за использование промышленных решений кластеризации, потому только опенсорс.
Автоматическое обнаружение "больной" головы
Автоматическая миграция Сервиса с больной головы на здоровую
Автоматический (по возможности) вход головы в кластер в случае её "выздоровления"
Отсутствие потерь данных при миграции

В данный момент под linux существует пакет pacemaker решаюший задачи кластеризации на базе стека hearbeat или стека OpenAIS. Данный пакет, судя по его документации, чудно подходит к решению поставленной задачи, - он предоставляет всё что нужно юному кластеростроителю:

Высокоуровневую абстракцию рессурса, который может представлять собой файловую систему, IP адрес, приложение. Типы рессурсов можно расширять разрабатывая всякие скрипты.
Мониторинг голов. Головы обмениваются между собой пакетами (unicast, мультикаст, broadcast) на основании чего определяют состояние кластера.
Репликацию концигурации кластера между головами. В результате чего администратор настраивает не головы по отдельности, а кластер в целом.
Миграцию рессурса основанную на куче политик.

Вот этот пакет я и взялся исследовать на "проф.пригодность". Из двух вариантов, для начала был выбран pacemaker со стеком heartbeat который завёлся с пол пинка и показал миграцию IP адреса между головами кластера. Я уже начал предчувствовать как всё красиво будет работать дальше, но тут как всегда подкрался северный пушной зверь, а именно:

При достаточно долгом отключении одной из нод (неважно какой, активной или пассивной) она не входит обратно в кластер. Судя по tcpdump обмен пакетами между нодами идёт успешно но в логах я вижу такую муру:
```
: Ignoring HA message (op=vote) from Set: not in our membership list (size=2) 
```
Убедить heartbeat пустить поднявшуюся ноду в кластер можно только передернув сервис (/etc/init.d/heartbeat restart), что нихрена меня не устраивает. Поиск в сети не дал решения данной проблемы, а она продолжала появляться как гейзенбаг - т.е. нода то входила в кластер то оставалась в Offline. Прослеживалась правда некоторая зависимость между входом ноды в кластер и временем её офлайна.
В процессе игры в heartbeat у меня возник вопрос - а что будет если узлы кластера потеряют между собой связь но при этом будут видны своим клиентам?

Основную головную боль вызвал второй вопрос. По условиям задачи железяки лежат на разных техплощадках и я в прошлом сталкивался с ситуацией когда датацентры видны извне но друг друга не видят. Не часто, но... С точки зрения почерпнутой информации о heartbeat нода потерявшая связь с соседкой должна выполнить promote своим рессурсам. Мы-же мастера не видим - значит он здох. Мастер здох а кто сервис выполняет? Никто? Значит будем мы. В результате чего у нас получится так назвываемый splitted brain - синдром разделённого сознания. Клиенты начнут работать с экземплярами сервиса работающего на обоих нодах одновременно, а это простите, - полный пиздец, что и подтвердилось экспериментально.

Круто жить пацанам которые держат все головы кластера в одной комнате и зацепили их отдельным физическим линком, по которому гоняют и синхронизацию данных и keep alive пакеты. При таком раскладе вероятность скатиться в разделённое сознание стремится к 0 (бабу Маню со шваброй не считаем...), потому можно позволить себе делать promote на slave как только связь с master пропала на минимальное время. А у нас-то не так... У нас, если slave не получает пакеты от master это значит одно - slave не получает пакеты от master, чего ему (слейву) вовсе недостаточно для принятия решения, а решение принимать надо причём автоматически и по чётким правилам....

В общем и получилась ситуация: есть проблема которую я не знаю как решать (нода не входит в кластер после офлайна) и еще одна концептуальная проблема по которой я не нашел best practices. Выходом из второй ситуации, для территориально разнесенного кластера, является специальная нода - арбитр, которая смотрит на кластер с точки зрения типового клиента и может дать авторитетный ответ что именно с кластером происходит. Пропала связь между узлами или один из узлов действительно ушел в офлайн. Без реализации принципа арбитража я решил что мой кластер жить не может. Как его реализовать на pacemaker+heartbeat я так и не придумал, плюс нода попрежнему отказывалась входить в heartbeat кластер после восстановления связи с ней, плюс сроки начинали реально поджимать. В общем затык. Последней каплей стала необходимость разработки скрипта управляющего работой нашего Application server и прикручиваение его к heartbeat....

Serviceability начало

2010-10-17T17:42:00.000+03:00

Что делаем?

Не так давно мне понадобилось обеспечить бесперебойную работу Сервиса предоставляемого нами заказчику - сделать работу Сервиса устойчивой к сбоям сети, аппаратуры и электропитания (обеспечить serviceability как говорят буржуины).

Что у нас есть?

Есть у нас куча территориально распределённых филиалов предприятия подключенных к интернету, благодаря которому они выходят в корпоративный VPN. Именно через этот VPN, посредством соответствующих толстых клиентов операторы филиала работают с некоторым Сервисом. Сервис этот, представляет собой Application server использующий PostgreSQL для хранения информации. И Application server и Database Server вертятся под linux на одной железке среднего уровня (4GB,2x4Core 2.4Ghz, etc...). Исторически сложилось так, что у заказчика нет ни своего подразделения способного обеспечить обслуживание серверного комплекса, ни технических условий для его размещения (помещение, питание, каналы), в результате чего эта железяка лежит у провайдера (довольно кстати известного).

Немного истории...

За более чем 5ти летнюю историю предоставления Сервиса был накоплен определённый опыт хождения по детским граблям...

К примеру, провайдеры конечно классные парни, но как бы матёр провайдер ни был, он не обеспечивает 100% онлайна железа лежащего у него на технической площадке. Как известно "в действительности всё совсем не так как на самом деле", потому при отключении питания на техплощадке, ИБП вытягивают её где-то около 30-40 минут (хорошо если...), потом всё тухнет, дизель-генератор оказывается не заправлен, а если заправлен то персонал не может его запустить. Подвод питания с двух подстанций конечно присутствует, но тухнут обе подстанции... Бывает еще, что шнурок из свича выдернут, но это реже.... А самое интересное в том, что когда у провайдера ложится дата-центр дозвониться можно только к роботу который расскажет что -"у нас проблемы и мы их решаем". Будто я сам не вижу.... Правда надо сказать что проблемы подобные описанным возникали у наших провайдеров не чаще чем в раз 5-6 месяцев.

На самом деле Сервис всегда обслуживался двумя серверами и оба лежали на двух техплощадках весьма опытных организаций (что не мешало в обоих случаях получать одинаковые шишки). Оба сервера были задействованы в организации отказоустойчивости, но назвать такую систему кластером язык не поворачивался. Дело тут в чем,- база данных у нас крутится на постгресе у которого до последнего времени было слабовато с репликацией (всяких слоней я рассматривал, но откинул ввиду сложности поддержки). Из всех возможных схем репликации, в результате был использован механизм warm standby - это когда master генерит WAL файлы, они доставляются на slave, который их применяет к своей базе. Данная схема репликации довольно проста в настройке и поддержке, а так-же совсем не нагружает master, однако у неё есть один существенный недостаток - slave сервер отстаёт от master на последний (не применённый) WAL файл. Если master отвалится и будет принято решение о включении slave, в его базе не будет ряда уже закомиченных транзакций данные по которым как-раз и находятся в не переданном WAL файле. Есть способы минимизировать данное кол-во транзакций ценой увеличения трафика, но это окно всё равно останется, а это делает невозможным автоматический promote slave сервера до мастер роли. -- Хрен его знает, может мастер сейчас появится а мы тут пачку транзакций скипнули... В общем от автоматического promote пришлось отказаться. Но и с ручным вышел затык...

-- Как принять решение о переключении, если провайдер не только не говорит сколько будет длится down time, но и в чём его причина? А из-за потерянных, при переключении транзакций вони будет не меньше чем из-за down time.... В общем схема с Warm standby сервером осталась только на случай снятия одной из железок на техобслуживание. Тут уж можно заставить master ноду отдать текущий WAL, обеспечив при этом отсутствие новых транзакций, и по факту применения последнего WAL'а на slave произвести переключение. Хорошо но мало...

Потому было принято решение реализовать полноценный кластер (о двух головах :) ) с автоматическим head switch'ем.

Киплинг. Заповедь.

2009-12-11T15:50:00.001+02:00

Владей собой среди толпы смятенной,
Тебя клянущей за смятенье всех,
Верь сам в себя, наперекор вселенной,
И маловерным отпусти их грех;

Пусть час не пробил - жди, не уставая,
Пусть лгут лжецы - не снисходи до них;
Умей прощать и не кажись, прощая,
Великодушней и мудрей других.

Умей мечтать, не став рабом мечтанья,
И мыслить, мысли не обожествив;
Равно встречай успех и поруганье,
Не забывая, что их голос лжив;

Останься тих, когда твое же слово
Калечит плут, чтоб уловлять глупцов,
Когда вся жизнь разрушена и снова
Ты должен все воссоздавать с основ.

Умей поставить в радостной надежде,
На карту все, что накопил с трудом,
Все проиграть и нищим стать, как прежде,
И никогда не пожалеть о том,

Умей принудить сердце, нервы, тело
Тебе служить, когда в твоей груди
Уже давно все пусто, все сгорело
И только Воля говорит: "Иди!"

Останься прост, беседуя с царями,
Останься честен, говоря с толпой;
Будь прям и тверд с врагами и друзьями,
Пусть все, в свой час, считаются с тобой;

Наполни смыслом каждое мгновенье,
Часов и дней неумолимый бег, -
Тогда весь мир ты примешь во владенье,
Тогда, мой сын, ты будешь Человек!

Для зацепки двух проксей

2009-05-15T11:17:00.000+03:00

acl testproxy dst destination_ip/255.255.255.255
cache_peer localhost parent 3129 0 no-query
never_direct allow testproxy
always_direct deny testproxy
always_direct allow all

Алиас на емейл

2009-03-13T11:28:00.000+02:00

Поскольку я пользуюсь dbmail+postfix для управления почтой
и поскольку я достаточно ленив чтобы заводить новые акаунты под специфические задачи, то я вешаю алиасы на админский акаунт такой коммандой:

dbmail-users -c admin -s user@Новый.домен

Информация о S.M.A.R.T

2008-09-25T16:27:00.000+03:00

Очередной раз забыл как смотреть S.M.A.R.T дисков в рейде.
Чтобы, блин, помнить:

smartctl /dev/cciss/c0d0 -a -d cciss,0
Где 0 - индекс диска в массиве.

И вообще надо это в мониторинг всандалить.