• IPoE
• привязка порт-ip
• выдача адресов по DHCP (опция 82)
• маршрутизирующий сервер на Linux (CentOS)

На frontend мы будем использоваться связку из двух службы:

keepalived — реализации протокола VRRP (Virtual Router Redundancy Protocol) для Linux. Демон keepalived следит за работоспособностью машин и в случае обнаружения сбоя — исключает сбойный сервер из списка активных серверов, делегируя его адреса другому серверу.

Другими словами, у нас 2 сервера на которых прописано по одному публичному адресу. Если любой из этих серверов падает, то адрес упавшего подхватывается вторым.
Демоны keepalived общаются по протоколу VRRP, посылая друг другу сообщения на адрес 224.0.0.18.
Если сосед не прислал свое сообщение, то по истечению периода он считается умершим и оба адреса обслуживает оставшаяся нода. Как только упавший сервер начинает слать свои сообщения в сеть, все возвращается на свои места

nginx [engine x] — это HTTP-сервер и обратный прокси-сервер, а также почтовый прокси-сервер, написанный Игорем Сысоевым. Уже длительное время он обслуживает серверы многих высоконагруженных российских сайтов, таких как Яндекс, Mail.Ru, ВКонтакте и Рамблер. Согласно статистике Netcraft nginx обслуживал или проксировал 15.08% самых нагруженных сайтов в октябре 2013 года.

Основная функциональность HTTP-сервера

• Обслуживание статических запросов, индексных файлов, автоматическое создание списка файлов, кэш дескрипторов открытых файлов;
• Акселерированное обратное проксирование с кэшированием, простое распределение нагрузки и отказоустойчивость;
• Акселерированная поддержка FastCGI, uwsgi, SCGI и memcached серверов с кэшированием, простое распределение нагрузки и отказоустойчивость;
• Модульность, фильтры, в том числе сжатие (gzip), byte-ranges (докачка), chunked ответы, XSLT-фильтр, SSI-фильтр, преобразование изображений; несколько подзапросов на одной странице, обрабатываемые в SSI-фильтре через прокси или FastCGI, выполняются параллельно;
• Поддержка SSL и расширения TLS SNI.

Другие возможности HTTP-сервера

• Виртуальные серверы, определяемые по IP-адресу и имени;
• Поддержка keep-alive и pipelined соединений;
• Гибкость конфигурации;
• Изменение настроек и обновление исполняемого файла без перерыва в обслуживании клиентов;
• Настройка форматов логов, буферизованная запись в лог, быстрая ротация логов;
• Специальные страницы для ошибок 3xx-5xx;
• rewrite-модуль: изменение URI с помощью регулярных выражений;
• Выполнение разных функций в зависимости от адреса клиента;
• Ограничение доступа в зависимости от адреса клиента, по паролю (HTTP Basic аутентификация) и по результату подзапроса;
• Проверка HTTP referer;
• Методы PUT, DELETE, MKCOL, COPY и MOVE;
• FLV и MP4 стриминг;
• Ограничение скорости отдачи ответов;
• Ограничение числа одновременных соединений и запросов с одного адреса;
• Встроенный Perl.

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

1. master нода vrrp получает поток данных по http(s);
2. gobetween раскидывает весь трафик на себя же и backup ноду vrrp;
3. radosgw в свою очередь пишут непосредственно в ceph;
4. в случае падения master ноды vrrp, backup нода берёт всю нагрузку на себя до тех пор, пока мастер не поднимется

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

Что такое “FHRP asymmetric routing”?

Состояние маршрутизации, при котором трафик в пределах одной сессии уходит через один маршрутизатор FHRP(VRRP/HSRP) master, а возвращается — через второй.

Что в этом плохого?

Ключевые проекты

• Debian 8, ядро 4.19
• FRRouting (в версии 1.1 и более древних использовался Quagga)
• ISC-DHCP
• Keepalived
• StrongSwan
• OpenVPN
• PowerDNS
• Wireguard
• OpenNHRP
• Accel-ppp
• xL2tpd
• Squid
• mDNS-repeater
• IGMP-Proxy
• iPerf
• более детальный список в Release notes

• 2 SIM-карты и автоматическое переключение между операторами — роутер должен автоматически определять потерю связи на одном операторе и переключаться на резервного. Это особенно важно для подвижных систем, когда покрытие сотовой сети не идеально.
• Подключение по Ethernet — основная система должна видеть только шлюз по умолчанию, и не должна знать о модемной подсистеме на стороне роутера и переключениях каналов, поэтому никаких USB.
• Поддержка современных протоколов VPN: IKEv2 и OpenVPN — для удобства администрирования, и чтобы не зависеть от реальных IP-адресов, роутеры должны уметь VPN. При этом поддерживать не только устаревшие PPTP и L2TP, но и современные протоколы.
• (Опционально) поддержка GPS, наличие GPIO, serial интерфейсов RS-232/485 — эти функции не обязательны для наших задач, но мы рассмотрим их тоже, как бонус, который, возможно, будет кому-то полезен.

• Мощный процессор ARM Cortex-A8
• 256МБ Flash-памяти
• 512МБ оперативной памяти
• Два модема LTE Cat.3 с обратной совместимостью с HSPA+ и GPRS/EDGE
• Поддержка карт MicroSD и наличие USB Host
• GPS для геолокации и синхронизации времени
• Wi-Fi (опционально)
• Программируемые порты ввода-вывода
• Открытая платформа, root-доступ по SSH
• Напряжение питания от 10 до 60V, поддержка PoE
• Температурный режим от -40 до +75 °C

Основная цель статьи – показать процесс установки и настройки виртуальных маршрутизаторов VyOS на кластере oVirt, для организации связи на уровне L3 между внутренними и внешними сетями.

Также в статье будут рассмотрены вопросы, связанные с особенностями настройки выхода в Интернет через двух провайдеров, и повышения отказоустойчивости межсетевой маршрутизации.

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

Сегодня я расскажу о том, как быстро собрать отказоустойчивый кластер с балансировкой нагрузки с помощью keepalived на примере DNS-серверов.

В прошлой статье мы внедрили домашний сервер DoH с использованием Pi-Hole, чем не только пофильтровали большое количество рекламы, но и инкапсулировали наши DNS-запросы в HTTPS, что вывело их из поля фильтрации запросов оператором связи.

Всем замечательно это решение, но у него есть один нюанс. Если вдруг у нас закончились деньги на счету у оператора связи или по каким-то другим причинам пропал канал связи до внешнего мира, мы даже не сможем пополнить счет, чтобы восстановить сервис, потому что не будет работать DNS. Или, например, если наш Pi-Hole по каким-то причинам перестал работать - вот вроде и вся сеть работает, и гугл пингуется, а пока не пропишешь другой DNS-сервер - не будет счастья. А если вы еще в этот момент заняты чем-то другим и не можете приступить к восстановлению незамедлительно - домашние негодуют, портят радостное существование своими жалобами и даже котики, чуя общую нервозность, стремятся нагадить вам в тапки.

Огорчать котиков - дело последнее, поэтому в этой статье я опишу, как вы можете внедрить автоматическое переключение с использования Pi-Hole на использование операторских (как, впрочем, и любых других) DNS при проблемах на Pi-Hole.

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

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

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

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

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

А есть ли способы, защитить ваш интернет-магазин или другой сервис от таких проблем?

Да, конечно, есть, и не один, но также есть и множество нюансов.

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

Эта статья поможет вам настроить доступный вариант отказоустойчивости, созданный на базе технологии VRRP (Virtual Router Redundancy Protocol) и сервиса keepalived.

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