Резервирование маршрутизатора

Услуга “Резервирование маршрутизатора” будет интересна в первую очередь тем, кто хотел бы обеспечить постоянную доступность бизнес-значимых интернет-ресурсов, но при этом не обладает для этого достаточными техническими возможности: не имеет ни собственной автономной системы, ни блока IP-адресов, ни подключений к провайдерам по протоколу BGP.

Об особенностях её технической реализации мы подробно расскажем в этой статье.

Выбираем схему резервирования

Представим себе, что у нас есть критически важный для бизнеса интернет-ресурс, который должен всегда доступен большому количеству пользователей. У этого ресурса www.mysite.ru есть IP-адрес 12.34.56.78, выданный провайдером в составе блока 12.34.56.72/29.

Сетевые настройки ресурса (адрес, маска и шлюз по умолчанию) выглядят как:

 

ifconfig eth0 address 12.34.56.78 mask 255.255.255.248 gw 12.34.56.73

 

Если .78 — это адрес хоста, то .73 — адрес шлюза по умолчанию. Этот адрес — зона ответственности оператора, а если хост размещен в дата-центре - то зона ответственности дата-центра.

Графически эту схему можно представить так:

image

На конечном хосте прописывается адрес 12.34.56.78, на маршрутизаторе — .72, и между ними организуется единый L2-домен (как правило, это отдельный VLAN):

image

Чтобы повысить уровень доступности конечного хоста, требуется резервирование сетевой инфраструктуры.  

Для резервирования на уровне L2 в простейшем случае используется Virtual Chassis/Fabric/MC-LAG. Тогда конечный хост подключается сети дата-центра с использованием LAG (Etherchannel):

image

Возможными точками отказа являются сам конечный хост и маршрутизатор.

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

Организовать перенос IP-адреса между основным и резервным хостами можно разными способами.В пределах одного L2-сегмента это можно сделать с помощью протоколов CARP/HSRP/VRRP и их аналогов.

image

О полноценном резервировании на уровне дата-центра  можно вести речь только в случае, если все компоненты сервиса зарезервированы, и у них нет единой точки отказа.

Идеальную схему резервирования можно представить так:

image

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

При возникновении неисправности в одном из дата-центров  конечный хост все равно остаётся доступным. Описанный подход можно использовать для резервирования как по L2-, так и по L3-схемам.

Резервирование маршрутизаторов

Примером резервирования на уровне L3 может служить anycast-маршрутизация и использованием BGP с вышестоящим оператором. Каждый из хостов анонсирует на маршрутизаторы оператора связи сеть 12.34.56.72/29 с разным приоритетом. При этом каждый хост подключается к маршрутизаторам оператора связи отдельной подсетью, отдельным VLAN’ом.

image

В числе преимуществ такой схемы можно выделить следующие:

  • она  широко используется в интернете (BGP);

  • масштабирование осуществляется не на два, а на несколько дата-центров.

Не лишена эта схема и недостатков, в числе которых нужно назвать:

  • низкую скорость работы (по умолчанию скорость сходимости BGP - от 1.5 минут);

  • сложность настройки;

  • необходимость выделения отдельных подсетей для подключения в каждом дата-центре.

Скорость переключения на резервный хост можно ускорить, если использовать не BGP, а другой протокол — OSPF или IS-IS.  Сложность здесь заключается в том, что далеко не каждый оператор связи даст возможность использовать эти протоколы: с их помощью обычно осуществляется передача служебных данных (например, MPLS-меток или служебных адресов), а полноценных возможностей ограничения нет.

При использовании L2-схемы оператор организует единый L2-домен между основным и резервным хостами. Между маршрутизаторами организуется VXLAN или MPLS-туннель.

image

VXLAN / MPLS помогают  организовать резервирование с использованием нескольких каналов связи между маршрутизаторами провайдера.

Конечный и резервный хосты между собой используют VRRP или его аналоги. Таким образом IP-адрес 12.34.56.78 оказывается на активном в текущий момент хосте (если оба хоста активны - то на сконфигурированном master-хосте). Конечный хост получает IP-адрес из этой сети - 12.34.56.77, резервый хост получает адрес из той же сети - 12.34.56.76.  Если на хостах установлена ОС Windows,  то вместо VRRP  можно использовать NLB-кластеризацию.

image

Аналогичная схема строится и со стороны оператора. Оба маршрутизатора участвуют в одном VRRP-домене и разделяют между собой адрес шлюза по умолчанию —12.34.56.73/29. Маршрутизатор 1 является предварительно сконфигурированным мастером с физическим IP-адресом 12.34.56.73, а маршрутизатор 2 - резервным маршрутизатором с физическим адресом 12.34.56.74; адрес 12.34.56.73 для него является виртуальным и активным только в момент недоступности маршрутизатора 1.

image

В числе несомненных преимуществ такой схемы следует назвать:

  • использование стандартных протоколов (VRRP);

  • простоту настройки, как со стороны заказчика, так и со стороны оператора;

  • уменьшение количества “лишних” IP-адресов;

  • высокую  скорость работы.

Недостаток только один: схема неудобно масштабируется для трех и более дата-центров.

Если случится неисправность: как это работает

В нормальной ситуации работают оба маршрутизатора и оба хоста заказчика. Один из маршрутизаторов на этапе построения схемы назначается основным (мастером) и отвечает на адрес 12.34.56.73. Аналогичным образом обстоит дело и с хостами: один из них является основным и отвечает на запросы на адрес 12.34.56.78. Второй маршрутизатор и второй хост являются резервными.

Запросы из Интернета проходят через маршрутизатор 1 и попадают на основной конечный хост. На маршрутизаторах присутствует ARP-запись 12.34.56.78 с МАС-адресом 0000:5E00:01xx, указывающим в сторону основного хоста. Основной хост отвечает хостам в интернете по роутингу через маршрутизатор 1 (для хостов указан default gateway 12.34.56.73). Для сокращения сетевой задержки основной маршрутизатор размещается в том же дата-центре, что и основной хост.

Что происходит, когда один из хостов недоступен? VRRP на резервном хосте определяет, что основной хост перестал отвечать на keep-alive запросы, и на резервном хосте устанавливается IP-адрес 12.34.56.78.

image

Запросы из интернета попадают на маршрутизатор 1; он в своей ARP-таблице видит МАС-адрес, соответствующий IP-адресу 12.34.56.78 со стороны маршрутизатора 2 и отправляет трафик на резервный хост. Резервный хост отправляет ответный трафик на шлюз по умолчанию 12.34.56.73, т.е. через маршрутизатор 1. При использовании этой схемы увеличивается сетевая задержка между хостами в интернете и резервируемым хостом.

После устранения неисправностей IP-адрес 12.34.56.78 снова становится доступен на основном хосте, и схема работает в штатном режиме.

Аналогичным образом эта схема работает в случае неисправности сетевой инфраструктуры между маршрутизатором и конечным хостом.

image

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

Если становится недоступным маршрутизатор 1 или вообще весь дата-центр 1 целиком, то схема работает исключительно через маршрутизатор 2 и резервный хост:

image

После восстановления инфраструктуры схема переходит в работу в штатном режиме. Практически никакие неисправности в дата-центре 2 не влияют на доступность конечного хоста.

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