Преимущества стекирования Juniper
Часть 1. Технология виртуального шасси
Одним из основных преимуществ решений Juniper перед конкурентами являются их возможности стекирования. Вариантов довольно много, начиная от базового Virtual Chassis и заканчивая целым рядом датацентровых технологий.
Часть 1. Virtual Chassis
Рассмотрим возможности и особенности базовой технологии Virtual Chassis, которая позволяет объединить до 10 устройств (в зависимости от модели) EX серии и QFX серии в одно логическое устройство, а также способы ее настройки и мониторинга.
Начнем с того, какие модели поддерживают технологию Virtual Chassis:
• EX2200 Ethernet Switch до 4 устройств
• EX3300 Ethernet Switch до 10 устройств
• EX4200 Ethernet Switch до 10 устройств
• EX4300 Ethernet Switch до 10 устройств
• EX4550 Ethernet Switch до 10 устройств
• EX4600 Ethernet Switch до 10 устройств
• QFX5100 Switch до 10 устройств.
Это те модели, которые на момент написания статьи производятся и доступны для заказа, и, соответственно, могут использоватся в виртуальном шасси.
Технологии Virtual Chassis сочетают масштабируемость и компактный форм-фактор отдельностоящих коммутаторов с высокой доступностью, пропускной способностью и плотностью портов традиционных шасси. Virtual Chassis позволяет обеспечить экономичное развертывание коммутаторов и доступность сети в местах, где стоимость установки шассийных устройств может быть слишком высока, или где физически невозможно поставить шассийные коммутаторы.
Благодаря тому, что несколько устройств управляются как единое целое, Virtual Chassis позволяет использовать такие же возможности по резервированию, как и использование нескольких Routing Engine (RE) в шассийных коммутаторах, включая технологию graceful Routing Engine switchover (GRES).
Для подключения в виртуальное шасси могут применяться специализированные интерфейсы, которые находятся на устройствах EX4500, EX4550 и EX4200, а также медные и оптические порты. Порты, которые используются для подключения в виртуальное шасси, называются Virtual Chassis Ports (VCP). Например, в коммутаторе EX2200–24T-4G 24 10/100/1000Base-T и 4 SFP для подключения в виртуальное шасси можно использовать как SFP, так и медные порты. Это позволяет разнести членов одного виртуального шасси на расстояние до 80 км.
Mixed Virtual Chassis дает возможность использовать в рамках одного виртуального шасси коммутаторы разных серий и даже разных линеек, как показано на рисунке ниже.
Варианты стекирования коммутаторов в Mixed Virtual Chassis
В виртуальном шасси есть разделение по ролям: два коммутатора получают роль RE0 и RE1, а остальные используются в качестве линейных карт.
RE0 выполняет роль мастера, задача которого — управление остальными членами виртуального шасси, и именно он отвечает за создание таблиц маршрутизации и распространение их по линейным картам. На нем также хранятся файлы конфигурации. RE1 — backup, на случай выхода RE0 из строя.
Рассмотрим распределение ролей коммутаторов в виртуальном шасси на примере ниже.
Критерии выбора мастера:
— Коммутатор с наивысшим приоритетом. Приоритет может быть от 1 до 255, по умолчанию он 128 на всех коммутаторах;
— Коммутатор, который был мастером до перезагрузки;
— Коммутатор с наибольшим uptime (разница должна быть больше 1 мин);.
— Коммутатор с наименьшим MAC адресом.
Каждый из членов виртуального шасси получает свой ID от 0 до 9. Настроить данный ID можно вручную с мастера (у которого ID 0) (после перезагрузки номер сохраняется и может служить как номер слота в определении интерфейса).
Из-за того, что ID закрепляется за коммутатором, может возникнуть следующая ситуация: когда один коммутатор выходит из строя и вы его меняете, новый член получает не номер вышедшего из строя коммутатора, а следующий свободный или вовсе не подключается к виртуальному шасси, если все ID уже заняты.
Поэтому, чтобы заменить вышедший из строя коммутатор новым, сперва нужно с мастера снять его ID следующим образом:
{master:0}
user@Switch-1> request virtual-chassis recycle member-id
Или можно это сделать с помощью ID команды:
user@host> request virtual-chassis renumber member-id
Единый менеджмент-интерфейс и единая консоль
В рамках виртуального шасси все management-интерфейсы объединяются в один, с единым IP адресом:
{master:0}[edit]
user@switch# show interfaces vme
unit 0 {
family inet {
address 10.210.14.148/27;
}
}
{master:0}[edit]
user@Switch-1# run show interfaces terse vme
Interface Admin Link Proto Local Remote
vme up up
vme.0 up up inet 10.210.14.148/27
То же самое происходит и с консольным портом, в какой бы вы не подключились, вы попадете на RE0.
Совместимость программного обеспечения
Все члены виртуального шасси должны быть с одинаковой версией софта. Когда мы добавляем новый коммутатор в виртуальное шасси, мастер проверяет его версию софта, если софт отличается, то новый коммутатор получит ID, но не станет активным членом виртуального шасси. Для этого нужно обновить на новом коммутаторе программное обеспечение с помощью команды:
request system software add member
Эта команда загружает образ из главного коммутатора через VCPs нового коммутатора, а затем перезагружает его, при этом новый коммутатор может быть не подключен напрямую к главному.
Автоматическое обновление программного обеспечения
С помощью настройки автоматического обновления софта, при подключении каждого нового коммутатора с версией, отличной от мастера, его софт будет автоматически обновляться. set virtual-chassis auto-sw-update package-name
Nonstop Software Upgrade
Технология Nonstop software upgrade (NSSU) позволяет обновлять ПО на всех членах виртуального шасси с минимальными потерями. Для корректной работы данной технологии нужно, чтобы:
— Все члены виртуального шасси были подключены по топологии «кольцо»;
— Master и backup были смежными;
— Линейные карты были настроены в режиме преконфигурации;
— На всех членах виртуального шасси должна быть одна версия софта;
— Должны быть включены NSR и GRES; Опционально можно активировать NSB командой request system snapshot.
Процесс NSSU:
— Скачиваем образ софта. Если используем смешанное виртуальное шасси, то скачиваем оба образа.
— Копируем его на RE0, рекомендовано в папку /var/tmp,
— Из командной строки RE0 запускаем NSSU командой:
request system software nonstop-upgrade /var/tmp/package-name.tgz
или для смешанных виртуальных шасси
request system software nonstop-upgrade set [/var/tmp/package-name.tgz /var/tmp/package-name.tgz]
Рекомендованное расположение коммутаторов Master и Backup
При построении виртуального шасси рекомендуются такие схемы подключения:
Или
Если элементы виртуального шасси разнесены территориально, то стоит использовать схему ниже:
Рекомендованные топологии виртуального шасси
На следующих рисунках показаны топологии виртуального шасси, которые могут быть развернуты на основе конкретных потребностей пользователей. Топология «кольцо» является наиболее часто используемой, но виртуальное шасси также можно развернуть в «Full mesh» топологии или топологии нескольких колец. Топология «кольцо» рекомендуется при развертывании виртуального шасси в смешанном режиме.
Кольцо
Full mesh
Топология нескольких колец
Настройка Virtual Chassis
Настройка виртуального шасси происходит на уровне иерархии [edit virtual-chassis]
{master:0}[edit virtual-chassis]
user@switch# set?
Possible completions:
+ apply-groups Groups from which to inherit configuration data
+ apply-groups-except Don’t inherit configuration data from these groups
> auto-sw-update Auto software update
> fast-failover Fast failover mechanism
id Virtual Chassis identifier, of type ISO system-id
> mac-persistence-timer How long to retain MAC address when member leaves Virtual Chassis
> member Member of Virtual Chassis configuration
no-split-detection Disable split detection. Only recommended in a 2 member setup
preprovisioned Only accept preprovisioned members
> traceoptions Global tracing options for Virtual Chassis
Чтобы свести к минимуму прерывания трафика во время сценария отказоустойчивости RE, нужно включить graceful Routing Engine switchover.
{master:0}[edit chassis]
user@switch# set redundancy graceful-switchover?
Possible completions:
> graceful-switchover Enable graceful switchover on supported hardware
Есть несколько вариантов: динамический и Preprovisioning.
Динамический:
1. Включаем мастер коммутатор и устанавливаем ID 0 и приоритет 255.
2. Подключаем backup коммутатор и устанавливаем ID 0 и приоритет 255.
{master:0}[edit virtual-chassis]
user@Switch-1# set member
3. При использовании только двух коммутаторов рекомендуется отключить split detection.
[edit virtual-chassis]
user@switch# set no-split-detection
4. Включаем питание на остальных коммутаторах.
5. Если мы используем смешанное виртуальное шасси, то добавляем команду:
user@device> request virtual-chassis mode mixed reboot
6. На каждом индивидуальном коммутаторе указываем порты, которые будут в роли VCPs.
Preprovisioning
1. Включаем мастер коммутатор (предварительно собираем все серийные номера коммутаторов, которые будут в кластере).
2. Если у нас будет использоваться смешанное виртуальное шасси:
user@device> request virtual-chassis mode mixed reboot
3. Опционально настраиваем IP адрес на менеджмент интерфейсе:
user@switch# set interfaces vme unit 0 family inet address /ip-address/mask/
4. Ставим Preprovisioning mode:
[edit virtual-chassis]
user@switch# set preprovisioned
5. Прописываем роль, ID для каждого члена виртуального шасси
[edit virtual-chassis]
user@switch# set member 0 serial-number BM0208105168 role routing-engine
user@switch# set member 1 serial-number BM0208124111 role line-card
user@switch# set member 2 serial-number BM0208124231 role routing-engine
user@switch# set member 3 serial-number BM0208124333 role line-card
6. При использовании только двух коммутаторов, рекомендуется отключить split detection.
[edit virtual-chassis]
user@switch# set no-split-detection
7. Включаем остальных членов виртуального шасси.
8. Если используем смешанное виртуальное шасси, то вводим на каждом коммутаторе
user@device> request virtual-chassis mode mixed reboot
9. Указываем какие интерфейсы будем использовать в роли VCPs
user@switch> request virtual-chassis vc-port set pic-slot pic-slot-number port port-number local
Например, чтобы использовать встроенные 40G порты на коммутаторе EX4600
user@switch> request virtual-chassis vc-port set pic-slot 2 port 0 local
Где порт 0 — первый 40G встроенный порт.
user@switch> request virtual-chassis vc-port set pic-slot pic-slot-number port port-number local
Мониторинг Virtual chassis
Для мониторинга виртуального шасси используется команда show virtual-chassis с различными ключами:
{master:0}
user@switch> show virtual-chassis?
Possible completions:
<[Enter]> Execute this command
active-topology Virtual Chassis active topology
device-topology PFE device topology
fast-failover Fast failover status
login
protocol Show Virtual Chassis protocol information
status Virtual Chassis information
vc-path Show virtual-chassis packet path
vc-port Virtual Chassis port information
| Pipe through a command
Проверка состояния портов виртуального шасси:
show virtual-chassis vc-port
{master:0}
user@Switch-1> show virtual-chassis vc-port
fpc0:
— Interface Type Trunk Status Speed Neighbor
or ID (mbps) ID Interface
PIC / Port
vcp-0 Dedicated 2 Up 32000 1 vcp-0
vcp-1 Dedicated 1 Up 32000 1 vcp-1
fpc1:
— Interface Type Trunk Status Speed Neighbor
or ID (mbps) ID Interface
PIC / Port
vcp-0 Dedicated 2 Up 32000 0 vcp-0
vcp-1 Dedicated 1 Up 32000 0 vcp-1
Проверка информации о состоянии:
show virtual-chassis status
{master:0}
user@Switch-1> show configuration virtual-chassis
preprovisioned;
member 0 {
role routing-engine;
serial-number BM0208105168;
}
member 1 {
role line-card;
serial-number BM0208124231;
}
{master:0}
user@Switch-1> show virtual-chassis status
Preprovisioned Virtual Chassis
Virtual Chassis ID: 8d5c.a77f.8de8
Mastership Neighbor List
Member ID Status Serial No Model priority Role ID Interface
0 (FPC 0) Prsnt BM0208105168 ex4200–24t 129 Master* 1 vcp-0
1 vcp-1
1 (FPC 1) Prsnt BM0208124231 ex4200–24t 0 Linecard 0 vcp-0
0 vcp-1
Вот так кратко мы рассмотрели технологию Virtual chassis, варианты настройки и мониторинга.
