Построение распределенного ЦОД (DC Interconnect, DCI)

Когда компания дорастает до определенного размера и одного ЦОД ей становится мало, сразу возникает масса вопросов, как дальше развивать сетевую инфраструктуру. Действительно, как расширить границы существующего ЦОД, чтобы он прозрачно обеспечивал существующие сервисы на удаленных площадках? Делать большой L2 домен, чтобы не было проблем с виртуализацией или объединять площадки по третьему уровню? Если делать инфраструктуру иерархической, то как обойти ограничения существующих стандартов (802.1q) и что будет в этом случае с безопасностью? А как, при этом, обеспечить надежную передачу конвергентного трафика (e.g. FCoE) между площадками? И всем этим еще необходимо слаженно управлять…

Устойчивый «трэнд» последнего времени на виртуализацию и построение облачных инфраструктур однозначно показывает, что предпочтительнее остальных по многим причинам является вариант с объединением площадок ЦОД по второму (L2) уровню. Однако сразу возникает вопрос, какую технологию для этого использовать? Очевидно, что строить сейчас распределенный L2 домен на основе STP, как минимум, не рационально. Из существующих альтернатив — TRILL, PBB/SPB, FabricPath (proprietary!), MPLS/VPLS, dark fiber – вариант с использованием для DCI технологии VPLS является, с одной стороны, самым зрелым и проверенным на практике, с другой — гибким и богатым по функциональности. Про него дальше и поговорим подробно.

Чтобы не усложнять пример, возьмем две географически разнесенных площадки. Сети будем строить на оборудовании Hewlett-Packard, которая последнее время активно развивает сетевое направления в ЦОД. Итак, задача – прозрачно для виртуальной среды (читай — VM) объединить в ЦОД две площадки, чтобы при этом:

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

Для решения этой задачи на каждой площадке устанавливаем по два коммутатора HP серии 5800 и объединяем их в один виртуальный коммутатор (для надежности, если не критично, то можно этот шаг пропустить). Делается это просто, коммутаторы объединяются через стандартные 10G порты, дальше IRF-стэк настраивается вот так:

Затем площадки физически соединяются 10G интерфейсам (полагаем, что между площадками ЦОД лежит оптика) и интерфейсы собираются в LACP-агрегат, вот так:

На второй площадке виртуальный коммутатор настраивается аналогично. При этом отметим, что оптика, соединяющая площадки, «приземляется» на физически разные коммутаторы. Это делается на случай падения одного из коммутаторов в стэке, чтобы трафик автоматически переходил на второй коммутатор/канал. Т.е., получаем такую картину:

Затем, чтобы прозрачно «пробрасывать» между площадками VLAN-ы (трафик второго уровня), поднимаем на этих коммутаторах VPLS сервис. Для этого сначала настраиваем MPLS и LDP сервисы так, чтобы LSP (Label Switched Path) «сигналились» автоматически, вот так:

Поднимает в MPLS-ядре OSPF, чтобы не морочиться со статическими маршрутами и коммутаторы на площадках видели друг друга по IP (и «кладем» в OSPF LoopBack-и), вот так:

После этого, настраиваем на обеих площадках сигнализацию VPLS. При этом вопрос, использовать вариант Компелла или Мартини – это больше вопрос религии. На оборудовании HP работают варианта. На LDP (Мартини) настраивается L2 MPLS VPN, затем создается VPLS Instance (VSI) и присоединяется к интерфейсу, вот так:

С BGP чуть посложнее, плюс ко всему нужно еще поднять BGP Peering между площадками, настроить в нем VPLS family и установить параметры для VPLS VSI (vpn-target и route-distinguisher), вот так:

В итоге получается примерно такая картина:

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

В этом упрощенном примере не совсем очевидно, зачем поднимать VPLS между двумя площадками? Кажется, можно просто пробросить trunk и VLAN-ы станут доступны на обеих площадках… Однако, помимо задач управления трафиком, сетевой безопасностью и качеством сервиса, которые обеспечивает MPLS/VPLS, как только в L2 домене появится еще одна площадка, (или еще одно redundant соединение), возникнет необходимость управлять доступом к среде и защищаться от петель. И делать это с STP сейчас, как минимум, плохой тон.

Автор: akkay12