Модернизация ядра сети передачи данных

Опубликовано – 24.11.2011

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

 Вратце опишу состояние дел на начало проекта. Ядро площадки было представлено четырьмя коммутаторами, совмещавшими в себе так же функции уровня распределения, Cisco Catalyst 6509E, по два коммутатора на пользовательский и серверный сегмент. Один из коммутаторов серверного сегмена не был обеспечен платами для подключения коммутаторов доступа. Часть коммутаторов пользовательского сегмента было подключено только к одному из коммутаторов ядра, на остальных, имевших два линка, один из линков был заблокирован по STP. Пользовательских VLAN очень много, часть из них представляет историческое наследие. К серверному ядру так же подключено два больших сегмента, обеспечивающих связь с филиалами и доступ к сети Интернет (оба сегмента на стыке с ЛВС имеют межсетевые экраны).

 В общем, посмотрите на Рис.1:


 В начале проекта, компания уже имела частично собственную, частично арендованную темную оптику, которая образовывала полукольцо, обслуживаемое мультиплексорами ADVA FSP3000. Полукольцо, по сути своей, объединяло только ЦОД и РЦОД, второе полукольцо проходило через еще одну крупную площадку, но была подключена через «дальнобойные» SFP ZX напрямую, через коммутаторы ядра.

 Первым этапом проекта были закуплены дополнительные мультиплексоры, фильтры и SFP к ним, после чего кольцо было полностью сформировано через мультиплекcоры. Но оставалась еще одна проблема — все площадки были связаны собой через L3, что не позволяло получить такие преимущества, как единый серверный сегмент в ЦОД и РЦОД, разнесение компонентов систем пакетной фильтрации сегментов подключения филиалов и доступа к сети Интернет. Так же, очень хотелось сократить количество пользовательских Vlan для Центрального офиса, привести их к единой схеме адресации, обеспечить пакетную фильтрацию.

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

 При неоценимой помощи Николая Дроздова был разработан проект, основными постулатами которого было:

  • вывести из работы резервный пользовательский коммутатор ядра, переключив все поэтажные линки на одно ядро, и объединить поэтажные линки в Portchannel.
  • вывести из работы резервный серверный коммутатор, поскольку пользы от него, без портовой ёмкости, немного
  • добавить уровень ядра, обеспечивающего подключение к другим площадкам по L3
  • связать ЦОД и РЦОД по L2, обеспечив возможность единого VTP-домена, перейти на использование GLBP
  • на уровне пользовательских и серверных коммутаторов распределения использовать плату пакетной фильтрации FWSM

Такое решение дало бы увеличение пропускной способности между поэтажными коммутаторами и пользовательским уровнем распределения, при незначительном снижении надежности, обеспечило бы защиту пользовательских и серверных сегментов, позволило бы подключить непосредственно на ядро сегменты доступа к филиалам и сети Инетрнет, дало возможность объединить серверные сегменты ЦОД и РЦОД.

 Схема проводимых изменений представлена на Рис.2:


 Приведу краткие пояснения схемы.

 Я попытался сделать классическую трехуровневую модель — доступ, распределение, ядро. При этом ядро разнесено территориально. Настраивать на нем VSS не предполагается.

 Установка коммутаторов, условно названных «backbone» вызвана необходимостью обеспечения полной связности серверных коммутаторов доступа с серверными коммутаторами распределения, при этом под эту задачу полностью отдан линк 10G. Еще два линка по 1G объединены в Portchannel и по нему ходят Vlan разнесенных сегментов подключения филиалов и Интернет (L3 сети, Active/Standby ASA и т.д.). Таким образом, на этих коммутаторах есть только транковые порты и набор Vlan, маршрутизацией они не занимаются. Для удовлетворения потребностей в пропускной способности используется Per-Port-Per-Vlan QoS. Данный функционал поддерживается на коммутаторах, начиная с 45хх серии, я использую 4948.

 Приведу пример стендового коммутатора, на котором настроен Per-Port-Per-Vlan QoS:

!
version 12.2
no service pad
!
hostname kitezh-backbone
!
boot-start-marker
boot-end-marker
!
!
no aaa new-model
!-------------------------------------------------------------------------
! Без qos работать не будет
!-------------------------------------------------------------------------
qos
ip subnet-zero
no ip rcmd domain-lookup
ip rcmd rcp-enable
ip rcmd rsh-enable
ip rcmd remote-host cisco 10.77.1.75 cisco enable
ip rcmd remote-host cisco 10.77.1.99 cisco enable
!
!
no file verify auto
!
!-------------------------------------------------------------------------
! Используем rapid-pvst
!-------------------------------------------------------------------------
spanning-tree mode rapid-pvst
spanning-tree extend system-id
!-------------------------------------------------------------------------
! Этот коммутатор root STP
!-------------------------------------------------------------------------
spanning-tree vlan 10,20,30 priority 0
power redundancy-mode redundant
!
!
!
vlan internal allocation policy ascending
!
!-------------------------------------------------------------------------
! Привязываем к class-map ACL для трафика
!-------------------------------------------------------------------------
class-map match-all vlan10
match access-group name Vlan10
class-map match-all vlan30
match access-group name Vlan30
class-map match-all vlan20
match access-group name Vlan20
!
!
!-------------------------------------------------------------------------
! Нарезаем полосу
!-------------------------------------------------------------------------
policy-map Vlan30_QoS
class vlan30
police 1024000 bps 115200 byte conform-action transmit exceed-action drop
policy-map Vlan20_QoS
class vlan20
police 2048000 bps 115200 byte conform-action transmit exceed-action drop
policy-map Vlan10_QoS
class vlan10
police 50000000 bps 115200 byte conform-action transmit exceed-action drop
policy-map Vlan10_QoS_Emergency
class vlan10
police 1024000 bps 115200 byte conform-action transmit exceed-action drop
!
!
interface Port-channel10
description --- To m1-backbone Server Trunk ---
switchport
switchport trunk encapsulation dot1q
!-------------------------------------------------------------------------
! Задаем, какие Vlan ходят через транк
!-------------------------------------------------------------------------
switchport trunk allowed vlan 1,10-30
switchport mode trunk
!-------------------------------------------------------------------------
! Задаем QoS для Vlan
!-------------------------------------------------------------------------
vlan-range 10
service-policy input Vlan10_QoS
service-policy output Vlan10_QoS
vlan-range 20
service-policy input Vlan20_QoS
service-policy output Vlan20_QoS
vlan-range 30
service-policy input Vlan30_QoS
service-policy output Vlan30_QoS
!-------------------------------------------------------------------------
! Устанавливаем приоритет SPT для Vlan (Vlan 10 должен использовать интерфейс Po10)
!-------------------------------------------------------------------------
spanning-tree vlan 10 port-priority 16
spanning-tree vlan 20,30 port-priority 32
!-------------------------------------------------------------------------
! Устанавливаем Cost (в моем случае одинаковый для Po10 и Gi1/48, это
! необходимо для работы port-priority на несимметричных линках)
!-------------------------------------------------------------------------
spanning-tree cost 10
!
interface GigabitEthernet1/1
description --- Vlan 10 ---
switchport access vlan 10
switchport mode access
!
interface GigabitEthernet1/2
description --- Vlan 20 ---
switchport access vlan 20
switchport mode access
!
interface GigabitEthernet1/3
description --- Vlan 30 ---
switchport access vlan 30
switchport mode access
!
!
!-------------------------------------------------------------------------
! Коммутатор уровня доступа.
!-------------------------------------------------------------------------
interface GigabitEthernet1/10
description --- To kitezh-access ---
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 10-30
switchport mode trunk
!
!
!-------------------------------------------------------------------------
! Два физических интерфейса для Po10.
!-------------------------------------------------------------------------
interface GigabitEthernet1/46
description --- To m1-backbone Server Trunk ---
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 1,10-30
switchport mode trunk
media-type rj45
channel-group 10 mode desirable
!
interface GigabitEthernet1/47
description --- To m1-backbone Server Trunk ---
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 1,10-30
switchport mode trunk
media-type rj45
channel-group 10 mode desirable
!
interface GigabitEthernet1/48
description --- To m1-backbone Other Trunk ---
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 1,10-30
switchport mode trunk
!-------------------------------------------------------------------------
! При работе через этот интерфейс, скорость Vlan 10 должна понижаться.
!-------------------------------------------------------------------------
vlan-range 10
service-policy input Vlan10_QoS_Emergency
service-policy output Vlan10_QoS_Emergency
vlan-range 20
service-policy input Vlan20_QoS
service-policy output Vlan20_QoS
vlan-range 30
service-policy input Vlan30_QoS
service-policy output Vlan30_QoS
!-------------------------------------------------------------------------
! Устанавливаем приоритет SPT для Vlan (Vlan 20,30 должны использовать интерфейс Gi1/48)
!-------------------------------------------------------------------------
spanning-tree vlan 10 port-priority 32
spanning-tree vlan 20,30 port-priority 16
spanning-tree cost 10
!
interface Vlan1
ip address 192.168.1.100 255.255.255.0
!
no ip http server
!
!
!
ip access-list extended Vlan10
permit ip any any
ip access-list extended Vlan20
permit ip any any
ip access-list extended Vlan30
permit ip any any
!
snmp-server community ROciscoWoRkS RO
snmp-server ifindex persist
!
!
line con 0
stopbits 1
line vty 0 4
!
!
end

 На серверных коммутаторах доступа настроен GLBP, так как при использовании VRRP/HSRP возникает лишняя загрузка канала между ЦОД-РЦОД, вследствие наличия Active/Standby.

 Вот как-то так. Возможно, что-то забыл или неполно описал, буду дополнять. Спрашивайте, если что.




 Уважайте труд автора, сохраняйте копирайты.
Реклама на сайте висит не просто так и если статья Вам понравилась, с ее помощью Вы можете отблагодарить автора за проделанную работу. Спасибо!

4 комментария в Модернизация ядра сети передачи данных

  1. gray:

    Спасибо за интересный пост!

    Несколько вопросов на которые отвечать не обязательно:
    1. Зачем в данных схемах ADVA? 1х10 + 2х1 по-моему, в Москве, можно без них.
    2. Почему не планируется VSS? Он настолько плох?
    3. По третьему абзацу создалось впечатление, что сейчас схема без резервирования по полосе. Так ли это? Если да, то почему целенаправленно именно она?

    Локации на втором рисунке и в конфигах — это специально для объяснения, что есть ЦОД, а что РЦОД? 🙂

    P.S. рекламы на сайте не вижу, специально отключал адблок 🙁

  2. Mixa:

    Добрый день!
    Adva выполняет следующие функции: всего есть четыре площадки — ЦОД, РЦОД, точка присутствия на М9 и площадка Контакт-Центра(условно). Организованы каналы: ЦОД-РЦОД 10g по двум полукольцам(канал один, но отказоустойчивый средствами Adva) — потому что не нашлось 6000 баксов на 2 xenpak для Cisco, 2 по 1g(каждый по своему полукольцу) и 8 каналов 4g FC для SAN(по 4 по полукольцу). Далее, ЦОД и РЦОД связаны с остальными площадками линками по 1g. Так как есть темное волокно, считаю что лучше вложиться в мультиплексоры, чем связываться с провайдерами.
    VSS — хорошая штука, но требует замены SUP и приводит к катастрофе п отказе master. Зачем покупать два устройства для отказоустойчивости, если мы сами потом объединил их в одно с помощью VSS?
    Насчет резервирования по полосе немного не понял.
    Сейчас, имея в наличии ограниченные силы и средства, я пытаюсь выстроить скелет правильной, на мой взгляд, сети, которую в дальнейшем я буду наращивать мясом отказоустойчивости и, при необходимости, расширением каналов.

  3. Mixa:

    На первом рисунке старая схема ЦОД, а на втором — новая ема ЦОД и схема соединения с РЦОД 🙂

  4. […] «Решение проблем при использовании «1c предприятие» 8.2 в Linux» «Модернизация ядра сети передачи данных«; […]

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *


*