Главная » Хабрахабр » Объединение проектов в разных дата-центрах

Объединение проектов в разных дата-центрах

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

Обычная L2 схема

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

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

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

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

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

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

Так что для каждого дата-центра приходится использовать свой набор VLAN, что сокращает количество возможных идентификаторов, которые можно использовать между дата-центрами.
Но идентификационное пространство VLAN весьма ограничено (4095 VLAN ID).

Проблемы L2

При использовании схемы на уровне L2 с использованием VLAN некорректная работа одного из серверов в дата-центре может привести к перебоям в предоставлении услуги по другим серверам. Из наиболее частых проблем можно отметить:

  • Проблемы с STP (Spanning-Tree Protocol)
  • Проблемы с широковещательными штормами (Broadcast Storm)
  • Проблемы с некорректной обработкой мультикаста
  • Человеческий фактор (перенос линков, перенос VLAN)
  • Проблемы с организацией резервирования по L2
  • Проблемы с unknown-unicast трафиком
  • Проблемы с количеством МАС-адресов

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

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

Broadcast

Сеть в дата-центре может быть построена на устройствах разных производителей. Порой достаточно даже отличий в версии ПО коммутаторов, чтобы коммутаторы по-разному обрабатывали STP. Так, например, в дата-центре «Дубровка 3» расположено 280 стоек, что превышает максимально возможное количество коммутаторов в одном STP-домене.

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

Мы стараемся нивелировать возможные проблемы с количеством broadcast-трафика, попадающего к нам в сеть. Проблемы с broadcast-трафиком часто возникают как по причине неверных действий на сервере (например, создание одного bridge между несколькими портами сервера), так и из-за неправильной настройки ПО на серверах. Из собственной практики, проблемы с широковещательным штормом со стороны сервера могут быть вызваны специфическим выходом из строя сетевой карты сервера. Но мы это можем делать на одном порту подключения сервера, а если в один коммутатор включено 5 серверов, каждый из которых не превышает установленные пороги, то вместе они могут сгенерировать достаточно трафика, чтобы сработал уже контроль на коммутаторе агрегации.

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

Multicast

Проблемы с некорректной обработкой multicast-трафика — очень специфичные проблемы, возникающие в комплексе из-за некорректной работы ПО на сервере и ПО на коммутаторе. Например, между несколькими серверами настроен Corosync в multicast-режиме. Штатно обмен Hello-пакетами осуществляется небольшими объемами. Но в ряде случаев серверы с установленным Corosync могут пересылать достаточно много пакетов. Этот объем уже требует или специальной настройки коммутаторов, или использования корректных механизмов обработки (IGMP join и другие). При неправильном срабатывании механизмов или при срабатывании порогов могут быть перерывы сервиса, которые затронут других клиентов. Конечно, чем меньше клиентов на коммутаторе, тем меньше вероятность возникновения проблем от другого клиента.

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

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

Ошибиться можно и при настройке коммутатора или маршрутизатора. Никакая автоматическая патч-панель не проложит новый кабель, если он потребуется. При указании каких-то дополнительных настроек не учесть их влияние на существующую конфигурацию. Указать неправильный номер порта, номер VLAN, опечататься при вводе числового значения. Человеческая ошибка может быть у любого, независимо от того, что за устройство находится в стадии конфигурирования, сервер, коммутатор, маршрутизатор или какое-то транзитное устройство. При увеличении сложности схемы, усложнении схемы резервирования (например, по причине достижения текущей схемой предела масштабирования) вероятность человеческих ошибок возрастает.

В курсе Cisco ICND проходят основы использования STP в качестве протокола, как раз изначально предназначенного для организации резервирования по L2. Организация резервирования по L2, на первый взгляд, кажется простой задачей для небольших сетей. Надо не забывать, что любой STP-домен имеет очень ограниченную «ширину», то есть количество устройств в одном STP-домене, довольно мало по сравнению с количеством стоек в дата-центре. STP имеет массу ограничений, которые в этом протоколе, что называется, «by design». Протокол STP в своей изначальной версии разделяет линки на используемый и резервный, что не обеспечивает полной утилизации аплинков при нормальной эксплуатации.

Например, ERPS (Ethernet Ring Protection Switching) — на используемую физическую топологию, на количество колец на одном устройстве, на утилизацию всех линков. Использование других протоколов резервирования по L2 налагает свои ограничения. Использование других протоколов, как правило, сопряжено с проприетарными изменениями у разных производителей или ограничивает построение сети одной выбранной технологией (например, TRILL/SPBm-фабрика при использовании оборудования Avaya).

Unknown-unicast

Особо хочется выделить подтип проблем с unknown-unicast трафиком. Что это такое? Трафик, который по L3 предназначен на какой-то конкретный IP-адрес, но по L2 широковещается в сети, то есть, передается на все порты, принадлежащие данному VLAN. Данная ситуация может возникать по ряду причин, например, при получении DDoS на незанятый IP-адрес. Или если при опечатке в конфигурации сервера был указан несуществующий в сети адрес в качестве резервного, а на сервере исторически существует статическая ARP-запись по этому адресу. Unknown-unicast появляется в случаях наличия всех записей в ARP-таблицах, но при отсутствии МАС-адреса получателя в таблицах коммутации транзитных коммутаторов.

Подобный вид трафика лимитируется транзитными коммутаторами и обслуживается зачастую так же, как и broadcast или multicast. Например, порт, за которым расположен сетевой хост с данным адресом, очень часто переходит в выключенное состояние. Особенно велик риск возникновения unknown-unicast трафика в случаях, когда правила фильтрации на пограничных маршрутизаторах позволяют подмену IP-адресов снаружи. Но в отличие от них, unknown-unicast трафик может быть инициирован «из интернета», а не только из сети клиента.

Казалось бы, при размере дата-центра в 200 стоек, по 40 серверов в стойке, вряд ли количество МАС-адресов сильно превысит количество серверов в дата-центре. Даже само количество МАС-адресов может иногда быть проблемой. Итого мы можем получить с одной стойки в 40 серверов больше нескольких тысяч легитимных МАС-адресов. Но это уже не соответствующее действительности утверждение, так как на серверах может быть запущена одна из систем виртуализации, и каждая виртуальная машина может быть представлена своим МАС-адресом, а то и несколькими (при эмуляции нескольких сетевых карт на виртуальной машине, например).

Кроме того, для определенных моделей коммутаторов при заполнении таблицы коммутации применяется хеширование, и какие-то МАС-адреса могут вызвать хеш-коллизии, ведущие к появлению unknown-unicast трафика. Такое количество МАС-адресов может повлиять на заполненность таблицы коммутации на некоторых моделях коммутаторов. Естественно, на коммутаторах применяются ограничения по количеству МАС-адресов, которые могут быть изучены на портах коммутатора, но в зависимости от конкретной реализации данного механизма, данные могут трактоваться по-разному. Случайный перебор МАС-адресов на арендованном сервере со скоростью, скажем, 4,000 адресов в секунду, может вызвать переполнение таблицы коммутации на коммутаторе доступа.

Самое неприятное в данной ситуации, что коммутаторы редко тестируются у производителя на самовосстановление после случаев с переполнением таблицы коммутации. Опять же, отправка трафика на МАС-адрес, зафильтрованный данным механизмом, ведет к появлению unknown-unicast трафика. Если же такое переполнение случается на коммутаторе уровня агрегации, то перезагрузка коммутатора может привести к 15-минутному простою всей локальной сети дата-центра. Разовое переполнение таблицы, вызванное, скажем, ошибкой одного клиента в параметрах hping или в написании скрипта, обеспечивающего мониторинг его инфраструктуры, может вести к перезагрузке коммутатора и перерыву связи для всех серверов, расположенных в стойке.

Размер сегмента, количество L2 сегментов — это все параметры, которые необходимо оценивать каждый раз при добавлении нового VLAN с L2 связностью. Хочется донести, что использование L2 оправдано только для ограниченных случаев и накладывает много ограничений. И чем меньше L2 сегментов, тем проще и, как следствие, надежнее сеть в обслуживании.

Типовые случаи использования L2

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

Связь front и back-end, резервное копирование

Как правило, использование локальной сети начинается с разделения функционала front и back-end сервисов, выделения СУБД на отдельный сервер (для повышения производительности, для разделения типа ОС на сервере приложений и СУБД). Поначалу использование L2 для данных целей выглядит оправданным, в сегменте всего несколько серверов, часто они даже расположены в одной стойке.

По мере увеличения количества оборудования, все новые и новые серверы включаются в коммутаторы новых стоек в дата-центре, от чего L2-домен начинает расти в ширину.
Серверы включаются в один VLAN, в один или несколько коммутаторов.

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

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

Но что стоит за этим простым действием?
Казалось бы, надо всего лишь соединить одним VLAN два коммутатора агрегации в ДЦ1 и ДЦ2.

Резервирование ресурсов

Во-первых, мы увеличиваем ширину L2 домена, таким образом все потенциальные проблемы локальной сети ДЦ1 могут возникнуть в ДЦ2. Кому понравится, что его серверы расположены в ДЦ2, а инцидент, связанный с недоступностью локальной сети, произойдет по причине некорректных действий внутри ДЦ1?

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

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

И надо отметить то, что MPLS-коммутатор в 1U, обладающий хорошей степенью масштабируемости, реализацией полноценного функционала MPLS в Control-plane, на практике, не существовал до последнего времени. Но MPLS-устройства, как правило, в два раза дороже, чем не-MPLS. В итоге хочется избавиться или минимизировать влияние проблем L2 на существующую сеть, но при этом сохранить возможность резервирования ресурсов.

Переход на L3

Если каждый линк в сети представить как отдельный IP-сегмент, а каждое устройство — как отдельный маршрутизатор, то нам не требуется резервирование на уровне L2. Резервирование линков и маршрутизаторов обеспечивается за счет протоколов динамической маршрутизации и избыточности маршрутизации в сети.

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

То есть эмулируется, что между дата-центрами установлен маршрутизатор (на самом деле, несколько, для резервирования).
Таким образом, дата-центры связаны между собой L3-связностью. Для каждого из клиентов можно использовать повторяющиеся диапазоны IP-адресов, сети полностью изолированы друг от друга, и из сети одного клиента не попасть в сеть другого клиента (кроме случаев, когда оба клиенты согласны на такое соединение). Это позволяет разделить L2-домены между дата-центрами, использовать в каждом дата-центре свое собственное пространство VLAN, осуществлять между ними связь.

0. Мы рекомендуем использовать для локальных сетей IP-сегменты из адресации 10. 0/8. 0. 0. Для первого дата-центра сеть будет, например, 10. 0/24, для второго — 10. 1. 2. 0. Selectel на маршрутизаторе прописывает IP-адрес из этой подсети. 0/24. 250-. Как правило, адреса . 254 служит шлюзом для попадания в другие локальные сети. 254 резервируются для сетевых устройств Selectel, а адрес . На все устройства во всех дата-центрах прописывается маршрут:

0. route add 10. 0 mask 255. 0. 0. 0. 0.x. 0 gw 10. 254

За счет этого маршрута серверы в дата-центрах «видят» друг друга по маршрутизации. Где x — номер дата-центра.

Тогда для серверов в третьем дата-центре прописываются IP-адреса из следующего диапазона, 10.
Наличие такого маршрута упрощает масштабирование схемы в случае, например, появления третьего дата-центра. 3. 0. 0. 0/24, на маршрутизаторе — адрес 10. 254. 3.

Так, например, при отказе дата-центра 1 целиком сохраняется связь между дата-центром 2 и дата-центром 3, а при реализации схемы с подачей L2 между дата-центрами через какой-то один из них, как на рисунке:
Отличительной особенностью реализации такой схемы является то, что она не требует дополнительного резервирования на случай отказа дата-центра или внешних каналов связи.

Или требуется организация дополнительных линков и использование сложных схем L2 резервирования.
От работоспособности дата-центра 1 зависит связь дата-центра 2 и дата-центра 3. И при сохранении L2 схемы все равно вся сеть целиком очень чувствительна к некорректной коммутации, образованию петель коммутации, различным штормам трафика и иным неприятностям.

L3-сегменты внутри проектов

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

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

Это все впечатляюще, но между проектами получается единая точка отказа — это маршрутизатор. Как быть в этом случае? На самом же деле, маршрутизатор не один. На каждый дата-центр выделяется два маршрутизатора, а для каждого заказчика они формируют Virtual IP .254 с использованием протокола VRRP.

Для дата-центров, разнесенных территориально, используются разные маршрутизаторы, а между ними организуется MPLS. Использование VRRP между двумя рядом стоящими устройствами, имеющими общий L2 сегмент, оправдано. И схема, в приближении к реальности, выглядит так: Таким образом, каждый клиент, подключающийся к локальной сети по такой схеме, подключается в отдельный L3VPN, сделанный для него на этих MPLS-маршрутизаторах.

254 резервируется по VRRP между двумя маршрутизаторами.
Адрес шлюза для каждого сегмента .

Заключение

Обобщая все вышесказанное — изменение типа локальной сети с уровня L2 на уровень L3 позволило нам сохранить возможность масштабирования, увеличило уровень надежности и отказоустойчивости, а также позволило реализовать схемы дополнительного резервирования. Более того это позволило обойти существующие ограничения и «подводные камни» L2.

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

Ждем вас в комментариях. Расскажите нам — применяете ли вы уже L3VPN?


Оставить комментарий

Ваш email нигде не будет показан
Обязательные для заполнения поля помечены *

*

x

Ещё Hi-Tech Интересное!

Ложные срабатывания в PVS-Studio: как глубока кроличья нора

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

Онлайн контест по решению задачи из теории игр

Привет, Хабр! На факультативе по теории игр мы решаем различные интересные задачи, и я хотел бы поделиться с вами одной из таких. Меня зовут Миша, и я студент. Описание игры «Я люблю вархаммер, поэтому решил адаптировать условие» Играют двое. 1. ...