Больше 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.
Как выглядит переезд:
Пока сеть работала в старом месте: все видели адрес 10.100.1.25/32 via 10.50.0.13 (старый адрес в msk1).
Потом в старом месте сеть выключили, в новом включили. По сети прошел апдейт.
Все видят адрес в новом месте: 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).
Начинаем перенос сетей и сервисов в них - освобождаем одну железку в старом датацентре и заполняем одну в новом. Далее переносим освободившуюся железку между датацентрами. Повторяем фокус столько раз, сколько нам нужно.
Со старого датацентра коммутаторы уезжают на склад.
На уровне сети - всё очень просто и логично. На самом деле на уровне виртуальных серверов и сервисов, всё так же просто и логично, но об этом чуть-чуть позже.
Итоги
Это первая статья из цикла "Гарантии работоспособности", в следующих статьях хочу рассказать о том, как устроены серверные и сервисные части. Как обеспечивается отказоустойчивость и переезды, как выполняется мониторинг и реагирование на различные ситуации
