Проблема стара как мир и сегодня мы ее решим :)
Дано: 2 провайдера (ISP1 и ISP2), внутренняя сеть и между ними маршрутизатор.
Задача: настроить один основной (ISP1) и один резервный канал (ISP2), при падении первого переключится на второй, при поднятии первого переключится обратно.

UPD: Обновил, дописал ip sla, пока без объяснений.

Чем же заняться админу в новогодние праздники, как не настройкой серверов!

В этой статье описан общий подход как можно:
— сделать кластер на iptables
— настроить кластер через GUI fwbuilder
— сохранить коннекты пользователей при failover при помощи conntrack-tools

Общее окружение в котором у меня работает такой кластер:
— Внутренняя сеть из backend и frontend серверов
— Блок внешних IP-адресов
— 2 сервера под кластер на базе linux (в моем случае Fedora 13 x64_86): fw1 и fw2 в режиме Master/Backup

Задачи кластера:
— шлюз для локальной сети
— публикация сервисов на внешнем блоке ip-адресов

В общем виде это работает так:
— за состоянием кластера следит служба ucarp и дергает нужные скрипты в случае failover
— служба conntrackd синхронизирует информацию о коннектах между серверами
— fwbuilder компилирует нужные скрипты для iptables

Под катом инструкция для сборки с напильником

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

Возможно очередной велосипед, но раньше не попадалось. Если идея окажтся жизнеспособной, может кто и реализует — тогда не пропадёт впустую, самому, к сожалению, некогда, хоть и очень хочется попробовать. Если это уже где-то реализовано — прошу строго не судить: сам на вскидку не нашёл, а на долгие поиски сейчас ну совсем времени нету.

Итак, в кратце:

Приветствую, хаброжители.

После того, как на моем любимом стареньком «сервере» сгорел БП, что привело к простою в полдня, я в очередной раз задумался об отказоустойчивом DHCP.
Конечно, многие сейчас скажут, что кластер рулит. Я даже соглашусь с тем фактом, что сейчас организация кластера проще, т.к. нет необходимости в САНе или закупке какого-то внешнего винчестера, вполне подойдет обычный НАС, построенный, например на FreeNAS с настроенным iSCSI-конектором… Но:
1. У меня нет платформы под НАС (как и потребности в нем).
2. У меня нет желания подымать кластер исключительно под DHCP, а для других нужд кластер мне пока не нужен.

Приветствую. Сегодня я хотел бы поговорить о такой неприятной ситуации, как отказ мастера в случае применения нативной репликации в PostgreSQL 9.x. Итак, предположим, что у вас есть кластер из двух и более PostgreSQL-серверов и на мастер внезапно упал метеорит. Логично предположить, что вам придётся сделать мастером одну из реплик. Сделать это можно двумя способами.

О технологии

Caché Database Mirroring появилась в продуктах InterSystems Caché и Ensemble в 2010 году.
Технология позволяет снабдить информационные системы(ИС), построенные на Caché и Ensemble, опцией FAILOVER — возможностью преодоления некоторых неисправных состояний СУБД, операционной системы или аппаратного обеспечения.
Для чего информационной системе необходим failover — вопрос давно изученный, но в двух словах failover позволяет минимизировать время простоя пользователей в случае неисправностей, приводящих к отказу обслуживания сервера с информационной системой.

В предыдущей части рассматривалась настройка зеркала — технологии высокой доступности InterSystems Database Mirroring СУБД Caché.
В этой статье будут рассмотрены сценарии перерывов (отказов) и реакция зеркала на них.

Перерывы могут быть как плановые, так и внеплановые.
Плановые — это когда нам нужно остановить сервер для обновления операционной системы, версии СУБД, версии прикладной системы и мы контролируем процесс.

Примеры плановых перерывов:

• перезагрузка ОС, например для установки обновлений;
• перезагрузка СУБД;
• обновление hardware сервера.

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

• зависание СУБД;
• зависание операционной системы;
• экстренные (Reset, Power Off);
• выход из строя оборудования сервера;
• выход из строя сетевого оборудования;
• война, эпидемия, снежный буран, космоса чёрные дыры.

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

Под отказоустойчивостью подразумевалась мгновенная замена оборудования в случае выхода из строя. Я остановил выбор на Mikrotik RouterOS, так как имел положительный опыт эксплуатации данной ОС. Так же на выбор повлияло удобство настройки и администрирования благодаря утилите Winbox.

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

«Быстро поднятое не считается упавшим!» (народная мудрость)

Понятие «FailOver» должно быть знакомо любому грамотному системному администратору. Резервные серверы, каналы, сценарии быстрого переключения на запасное оборудование… Одним словом – отказоустойчивость.

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

Про многосерверные конфигурации, гео-распределенные кластеры много пишется на том же Хабре, проводятся специализированные конференции (тот же HighLoad++, например).

А как быть средним и маленьким проектам? Для них все это может быть слишком сложно и дорого, а обеспечение отказоустойчивости — не менее важная задача. «Упавший» интернет-магазин потеряет клиентов и реальные деньги.

Хотите знать, как не «падать» (или — по крайней мере — быстро подниматься :)) — приходите или участвуйте онлайн в FailOver Conference 4 апреля!

Подробности — под катом.

FailOver Conference состоится уже завтра, 4 апреля! Мы сами ждем это мероприятие с огромным нетерпением, потому что работа над программой уже завершена и в нее попало только все самое «вкусное»! :-)

Самое «горячее» специальное предложение для тех, кто не сможет присутствовать лично — бесплатная онлайн трансляция всего мероприятия!

Можно будет не только посмотреть все доклады, но и задать интересующие вопросы через твиттер с хэштегом #failoverconf.

Для этого требуется самая малость — зарегистрироваться на онлайн трансляцию.

А под катом мы расскажем о наиболее интересных, на наш взгляд, докладах!

4 апреля мы провели первую FailOver Conference — конференцию, целиком и полностью посвященную отказоустойчивости сайтов и их бесперебойной работе.

Целый день, более 7 часов, мы слушали доклады от разработчиков и архитекторов облачных сервисов, системных администраторов хостинг-провайдеров, опытных DBA, обсуждали их, спорили…

Тема оказалась очень важной и востребованной — более 1200 человек зарегистрировались на онлайн-трансляцию.

Конечно, сложно сразу «переварить» такой большой объем информации. К чему-то хочется вернуться позже, попробовать применить к конкретному проекту. Именно поэтому один из самых часто звучащих вопросов как из зала, так и в онлайне (в твиттере): «А будут ли опубликованы материалы?»

Да, конечно! Мы публикуем и презентации, и видео докладов, и с удовольствием делимся ими с вами!

Внутри одно дата-центра организовать отказоустойчивость легко — есть масса инструментов и техник.
А как быть если надо организовать отказоустойчивость на базе нескольких дата-центров?

Ниже я приведу, на мой взгляд элегантное и очень дешевое решение, не лишенное конечно же недостатков.

Смысл заключается в том чтоб в каждом дата-центре был свой NS сервер который отдает IP своего дата-центра.

Привет, друзья!

Совсем недавно вышла статья astlock о фейловере DNS. Фича, конечно классная и удобная, но те, кто хостил в AWS большие проекты с ELB совсем не почувствовали нового. Если фейловер не работает с ELB, то мне лично эта функция абсолютно бесполезна.

Но вот настал тот день, когда стало возможным использовать блага Route53 вместе с ELB. Настраивая запись в режиме Failover и соединяя её с ELB мы тем самым включаем возможность автоматического мониторинга ELB. Переключение записи с Primary на Secondary произойдёт автоматически в следующих ситауциях:

• отказ и недоступность ELB
• отсутствие здоровых инстансов под ELB

Route53 теперь даёт возможность автоматически переехать в случае отказа всего региона,

В этой статье я расскажу, как я протестировал новый функционал.

Предыстория

Года два назад, руководство решило вложиться в проект виртуализации нашего датацентра. Задача стояла достаточно простая, около 50 серверов, в основном Windows, пара линукс машин, ничего нестандартного. Датацентр хоть и небольшой но очень гордый важный, являемся европейской штаб-квартирой крупной организации – хостим сервисы для 30 стран (Европа+СНГ). Два датацентра, связь надежная и дублированная, по определенным причинам выбрали связку VMWare ESXi (4 затем 5) и HP Lefthand P4000(первый транш) и P4500 (второй транш). Причины чисто субъективные, VMWare и HP являются стратегическими партнерами и т.д.

Около трёх лет я занимался интеграцией продуктов компании Инфотекс. За это время я близко познакомился с большинством её продуктов и в целом, считаю, что они заслуженно получили столь широкое распространение в России. Среди основных их преимуществ можно отметить наличие сертификатов ФСБ и ФСТЭК, широкий ассортимент продуктов, включающий как программные, так и программно-аппаратные решения, легкое и удобное масштабирование и администрирование сети, хорошую техподдержку, удобное лицензирование, простоту установки и настройки, ну и конечно же цена по сравнению с аналогами. Есть, конечно, и недостатки, но у кого их нет? Однако, самый, на мой взгляд, неудачный продукт из всей линейки это отказоустойчивый кластер ViPNet Failover и далее я объясню почему.

Шановні пані та панове! Рады сообщить вам, что специализированная технологическая конференция «FailOver Conference Украина» состоится 3 октября 2013 года в Киеве!

В начале апреля этого года мы провели первую «FailOver Conference» в Москве. Опыт ее проведения оказался очень удачным — в офф-лайне и он-лайне присутствовали около 800 участников (материалы прошедшей конференции выложены на Хабре).

Практически сразу мы с директором нашего украинского офиса, Дмитрием Сусловым, начали вынашивать идею о том, что неплохо бы провести подобное мероприятие и в Украине, где технологических конференций, к сожалению, проходит гораздо меньше, чем в России.

Наверное, кто-то из вас уже знает, что специализированная технологическая конференция «FailOver Conference Украина» состоится 3 октября 2013 года в Киеве.

Несмотря на то, что до мероприятия еще остался целый месяц, счет участников уже идет на сотни!

Сегодня мы делаем небольшой обзор самых «вкусных» докладов — развеять сомнения тех, кто уже подумывает об участии, но еще не зарегистрировался, а также рассказать всем, кто про «FailOver Conference Украина» еще не слышал: 3-го октября надо быть в Киеве! :)

До первой технологической конференции «FailOver Conference Украина», которая состоится 3 октября 2013 года в Киеве, осталось ровно две недели!

Мы уже знакомили вас с анонсами ключевых презентаций и докладчиков (Sphinx, Percona, DOU.ua, Badoo, Google и т.д.)

Сегодня мы рады сообщить вам, что программа конференции полностью сформирована! И продолжаем знакомить вас с наиболее интересными докладами.

В последние годы требования к приложениям значительно изменились. Десятки серверов, время отклика в несколько секунд, оффлайновое обслуживание, которое могло длиться часами, гигабайты данных — такими были большие приложения буквально несколько лет назад. Сегодня же приложения работают абсолютно на всём, начиная с простых мобильников и заканчивая кластерами из тысячи процессоров. Пользователи ожидают миллисекундного времени отклика и стопроцентного аптайма, в то время как данные выросли до петабайтов.

Первоначально эту нишу занимали крупные инновационные интернет-компании типа Google или Twitter, однако такие требования к приложениям начали всплывать во многих областях индустрии. Финансовые и телекоммуникационные компании первыми начали внедрять новые практики, чтобы удовлетворить новым требованиям, а теперь подтягиваются и остальные.

Новые требования требуют новых технологий. Предыдущие решения делали упор на управляемые сервера и контейнеры. Масштабирование достигалось засчёт покупки более крутых серверов и использования многопоточности. Для добавления новых серверов приходилось применять комплексные, неэффективные и дорогие проприетарные решения.

Однако прогресс не стоит на месте. Архитектура приложений эволюционировала в соответствии с изменившимися требованиями. Приложения, разработанные на основе этой архитектуры, мы называем Реактивными Приложениями. Такая архитектура позволяет программистам создавать событийно-ориентированные, масштабируемые, отказоустойчивые и отзывчивые приложения — приложения, работающие в реальном времени и обеспечивающие хорошее время реакции, основанные на масштабируемом и отказоустойчивом стеке и которые легко развернуть на многоядерных и облачных архитектурах. Эти особенности критически важны для реактивности.

Прежде, чем регистрироваться на 3-ю конференцию «FailOver Conference», которая пройдет 23-го мая в Москве, ответьте, пожалуйста, на несколько очень коротких вопросов.

1. Вам приходилось слышать: «Заставь работать это в два раза быстрее! Да, на том же сервере!»?
2. Вас приводит в дрожь фраза: «Так, за какое число у нас последний бэкап базы?»?
3. Вы переносили проект на другой хостинг после фразы начальства: «Хостер сказал, что нас DDoS'ят, перенеси быстренько сайт на другой хостинг...»?
4. Вас приводила в уныние перспектива развернуть и настроить новый сервер базы данных? Да, чтобы к утру уже был с настроенной репликой.
5. Вы страдаете, когда страницы сайтов грузятся по 10 секунд, а на бэкграунде, оказывается, картинка в 15 Мб?
6. Вы знаете, чем git отличается от PHP, а awk от Unix-shell'а?
7. Вы считаете предыдущий вопрос глупым?
8. Вы бывали на конференциях, знания с которых потом не могли применить на практике?

Если есть хотя бы три «да» — добро пожаловать под кат! Там информация для вас. :)