Когда компания вырастает до определенного размера и одного дата-центра становится недостаточно, сразу возникает масса вопросов о том, как дальше развивать сетевую инфраструктуру.
Действительно, как мы можем расширить границы существующего дата-центра, чтобы он прозрачно предоставлял существующие услуги на удаленных площадках? Стоит ли создавать большой домен L2, чтобы не было проблем с виртуализацией, или объединять сайты на третьем уровне? Если сделать инфраструктуру иерархической, то как обойти ограничения существующих стандартов (802.1q) и что в этом случае будет с безопасностью? И как при этом обеспечить надежную передачу конвергентного трафика (например, FCoE) между площадками? И всем этим еще нужно слаженно управлять.
Недавний устойчивый «тренд» на виртуализацию и построение облачных инфраструктур наглядно показывает, что вариант объединения площадок ЦОД на втором (L2) уровне предпочтительнее других по многим причинам.
Однако сразу возникает вопрос: какую технологию для этого использовать? Очевидно, что построение распределенного домена L2 на базе STP сейчас, как минимум, не рационально.
Из существующих альтернатив - TRILL, PBB/SPB, FabricPath (собственный!), MPLS/VPLS, dark волоконно - вариант с использованием технологии VPLS для DCI является, с одной стороны, наиболее зрелым и проверенным на практике, с другой - гибкий и богатый функционал.
Мы поговорим об этом подробно позже.
Для простоты примера возьмем два географически разделенных сайта.
Сети мы будем строить на оборудовании компании Hewlett-Packard, которая в последнее время активно развивает сети в дата-центрах.
Итак, задача состоит в том, чтобы прозрачно для виртуальной среды (читай – ВМ) объединить две площадки в дата-центр, чтобы:
- прозрачно передавать трафик уровня 2 (L2) по сети центра обработки данных;
- избегать заблокированных каналов и неэффективного использования полосы пропускания;
- максимально упростить управление сетью;
- обеспечить необходимую отказоустойчивость и защиту от различного рода сбоев;
- обеспечить простоту расширения емкости портов и в целом масштабируемость сети;
- возможность постепенного увеличения пропускной способности портов путем добавления в стек коммутаторов по мере необходимости;
Делается это просто, свитчи подключаются через стандартные порты 10G, далее стек IRF настраивается так: 
Далее площадки физически подключаются к интерфейсам 10G (мы предполагаем, что между площадками дата-центра есть оптика) и интерфейсы собираются в блок LACP, вот так: 
На второй площадке виртуальный свитч настраивается аналогичным образом.
При этом отметим, что соединяющая площадки оптика «садится» на физически разные свитчи.
Это делается в случае сбоя одного из коммутаторов в стеке, поэтому трафик автоматически перемещается на второй коммутатор/канал.
То есть получаем следующую картину: 
Затем, чтобы прозрачно «пробрасывать» VLAN (трафик второго уровня) между площадками, мы поднимаем на этих коммутаторах сервис VPLS. Для этого мы сначала настраиваем сервисы MPLS и LDP так, чтобы LSP (Label Switched Path) «сигнализировал» автоматически, вот так: 
Поднимает OSPF в ядре MPLS, чтобы не морочиться со статическими маршрутами и свитчи на площадках могли видеть друг друга по IP (и «ставить» LoopBacks в OSPF), вот так: 
После этого настроили VPLS сигнализацию на обеих площадках.
При этом вопрос о том, использовать ли версию Компеллы или Мартини, скорее вопрос религии.
Варианты работают на оборудовании HP. L2 MPLS VPN настраивается на LDP (Martini), затем создается экземпляр VPLS (VSI) и подключается к интерфейсу, вот так: 
С BGP немного сложнее, плюс еще нужно поднять BGP Peering между сайтами, настроить в нем семейство VPLS и задать параметры для VPLS VSI (vpn-target иroute-distinguisher), вот так: 
Результат примерно такой: 
В этой схеме трафик второго уровня прозрачно пересылается в VLAN между площадками, а виртуальные ресурсы и приложения могут беспрепятственно мигрировать с одной площадки на другую, как если бы они находились в одном месте.
В этом упрощенном примере не совсем очевидно, зачем поднимать VPLS между двумя площадками? Кажется, что можно просто пробросить транк и VLAN станут доступны на обеих площадках.
Однако помимо задач управления трафиком, сетевой безопасности и качества обслуживания, которые обеспечивает MPLS/VPLS, как только в сети появится еще одна площадка домена L2 (или другого резервного соединения), возникнет необходимость контролировать доступ к среде и защищать от петель.
А делать это с STP сейчас, как минимум, дурной тон.
Теги: #сервер #центр обработки данных #инфраструктура #Системное администрирование #оборудование #расширение #HP #VM #sysadmin #switch #site #stp #domain #System #l2 #vpls #fabricpath #fabricpath #trill #trill #DCI #PBB/SPB # MPLS/VPLS #темное волокно
-
Apple Защищает Свой Логотип
19 Oct, 24 -
Корейцы Создали Надувную Компьютерную Мышь
19 Oct, 24 -
Простая Служба Поддержки
19 Oct, 24
