Больше 700 NATов, около 1000 маршрутизаторов. Зачем это всё нужно, как это администрировать и какие профиты от такой организации сети. Спойлер: экономия в миллионы рублей при кратном росте надежности и простоты переездов.

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

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

Организация сети

На организации сети стоит вся идея многократных переездов без простоя. Если описать поверхностно, то каждый проект живет в закрытом контуре (своей локальной сети) и находиться за NAT-ом. Внутрь контура можно попасть используя VPN или проброшенный внутрь NAT-а порт (http/https - для пользователей). На границе контура установлен выделенный маршрутизатор (виртуальный), с тремя портами - WAN, LAN и ADMIN-LAN. По названиям можно легко догадаться, что LAN и ADMIN-LAN отличаются своим назначением: LAN для трафика и работы сервисов, а ADMIN-LAN для админов, бекапов, мониторинга и всего остального. Такая вот локалка, торчащая, наружу одним WAN портом - это очень похоже на клиента большой провайдерской сети. Именно от этого и образовалась дальнейшая архитектура системы.

Плюсы таких отдельный локалок per-project:

• Легко делегировать сетку за маршрутизатором администратору, который есть в конкретном проекта. (Тут рождается масштабирование каждого отдельного проекта)

• Можно и не делегировать, а брать в централизованное обслуживание, там где нет на это потребности. Сети однотипные, администрировать их можно сотнями (тут рождается экономия)

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

Итого, что у нас получилось: возможность переезжать между датацентрами исходя из требований бизнеса (пределы роста в одном датацентре, экономия денег, тендер требующий сменить ЦОД, децентрализация или централизация инфраструктуры), экономить деньги, делегировать и масштабировать сети проектов.

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

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

Модель виртуального провайдера

На уровне сети, к которой подключены эти локалки задача становиться простой и типичной. Каждой такой "абонентской сети" выдать способ подключения (физический, IPSec, виртуальная локальная сеть в рамках виртуализации) и IP-адрес. Когда каждый "абонент" такой сети имеет свою адресацию и реквизиты доступа - всё остается только за тем, чтобы любая другая точка нашей сети имела маршрут до этого абонента.

Понятное дело, что IP-адрес, по которому обращаются другие сервисы в других локальных сетях не должен меняться при переезде: он может быть вписан в сотню файрволлов, настройки разных nginx/haproxy и еще чего угодно.

Так же понятно, что на каждой физической площадке есть какая-то своя адресация, которая отличается от адресации в другом датацентре.

Решение задачи становиться простым: использование пиринговой сети. На WAN порту маршрутизатор прописывается 2 IP адреса:

• IP-адрес в пиринговой сети (например в датацентре msk1: 10.50.0.0/24, в msk4: 10.99.0.0/24 и так далее).

• IP-адрес, по которому другие сервисы и пользователи ходят в локалку (например 10.100.1.25).

Маршрутизатор должен уметь динамическую маршрутизацию и рассказать соседям по пиринговой сети о том, что через его адрес 10.99.0.31 можно достучаться до 10.100.1.25/32.

Как выглядит переезд:

1. Пока сеть работала в старом месте: все видели адрес 10.100.1.25/32 via 10.50.0.13 (старый адрес в msk1).

2. Потом в старом месте сеть выключили, в новом включили. По сети прошел апдейт.

3. Все видят адрес в новом месте: 10.100.1.25/32 via 10.99.0.31, весь трафик завернулся в новое физическое расположение в msk3. Фаерволы менять не нужно, адреса те же, поменялся только маршрут.

Архитектура

Сеть, как и любая провайдерская сеть состоит из узлов связи (в датацентрах) и каналов. К узлам связи подключаются абоненты используя местный адреса для пиринга и по протоколу динамической маршрутизации рассказывают о своих Intranet адресах. Было выбрано два протокола: OSPF и RIPv2. OSPF используется в 99.99% случаев, потому что устраивает всем.

RIPv2 применяется только в ситуациях, где OSPF работать не будет (размещение прокета отдельно от подконтрольных площадок, где связь с площадкой центральной инфраструктуры осуществляется по IPsec и не имеет физических локальных соединений).

Узлы связи непосредственно между собой связаны разными способами, предпочтительно это IPsec либо выделенные VLAN между датацентрами. Площадки между собой обмениваются маршрутами с помощью BGP (серые AS).

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

Маршрутизаторы и коммутаторы

Поскольку используемые протоколы простые и популярные (NAT, OSPF/RIP и более ничего) сеть пестрит разными вариантами виртуальных маршрутизаторов: виртуальные Mirkotik, s-terra gate, Quagga, виртуальные Cisco. Выбор зависит от предпочтений администраторов локальных сетей и специальных требований (например наличия ГОСТ-шифрования).

Все эти виртуальные маршрутизаторы подключены в виртуальные локальные сети, которые обратной стороной смотрят уже в железные маршрутизаторы. К ним требования тоже простые - уметь IPSec, Vlan и BGP. Собственно это Cisco, местами есть juniper и Quagga.

Часть площадок представляют из себя офисные площадки, где всё выглядит несколько проще, но суть схемы от этого не изменяется, меняется только цена в меньшую сторону.

Под виртуальной сетью и виртуальными машинами есть физическое железо: мы предпочитаем Supermicro (за надежность и цену), а коммутаторы используем практически любые. Имея OSPF и возможности резервирования маршрута /32 на его уровне, нет требований даже к стекируемости коммутаторов.

Обслуживание

Сама сеть, как и любая провайдерская сеть требует небольшого коллектива профессионалов, качественной документации (вообще провайдер без документации не работает от слова совсем) и инженеров remote-hands (кстати на качестве их работы и рейтинге косячности строиться наш выбор датацентра). Системы мониторинга самой сети - стандартные инструменты провайдеров: ping и snmp для мониторинга узлов и трафика. Этого достаточно для того, чтобы при наличии резервов на базе OSPF на каждом узле поддерживать формальный 99.999% uptime и фактический 100% в течение последних лет.

Профиты

• Миграция и масштабирование в любую сторону: Подешевле в офис, понадежнее в датацентр, побольше места во соседний датацентр, по-распределеннее - в два/три ДЦ. Возможность отдельные проекты унести на VPSхостинги и "пристегнуть" к основной инфраструктуре с помощью IPsec+RIPv2.

• Дешевые резервы на каждой площадке, дешевые машрутизаторы и условно бесплатные закрытые контуры (условно, потому что за оверхеды всё равно платим ресурсами).

• Быстрые переезды проектов: сети стандартные и одинаковые во всех точках присутствия. Перенос из точки A в точку B не осложнен сетью.

• Быстрая развертка новой точки присутствия: при наличии оборудования и пустой стойки в течение нескольких дней разворачивается стандартная площадка, готовая к заезду на неё проектов.

• Разделение администрирования провайдерской части сети и сетей локальных: огромный профит и в управлении и в найме специалистов и в обособлении проектов от центральной инфраструктуры, когда это требуется.

• Экономия и заработок: на оборудовании, на размещении, на количестве кадров, на простоях (не падать всегда дешевле). Одна из таких инфраструктур сделана под наши же нужны и год от года экономит несколько миллионов рублей, а так же позволяет запускать на них ответственные по Uptime проекты и зарабатывать этим деньги бизнесу.

Как осуществляется миграция железа

Мы просто берем один свободный сервер (обычно освобождаем его, путем перемещения виртуалок на другие серверы), берем запасные коммутаторы и притаскиваем это в новый датацентр, настраиваем там vlan/ipsec до соседних площадок, BGP, пиринговую сеть, ospf, rip (для старта площадки можно вообще на Quagga).

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

Со старого датацентра коммутаторы уезжают на склад.

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

Итоги

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