Сетевая инфраструктура ЦОД, ориентированная на приложения и коммутаторы Nexus 9000

Сетевая инфраструктура ЦОД, ориентированная на приложения и коммутаторы Nexus 9000

Максим Хаванкин cистемный архитектор [email protected]

12/9/13 © 2013 Cisco and/or its affiliates. All rights reserved.

Содержание

•  Развитие сетевой и сервисной архитектуры ЦОД •  Введение в инфраструктуру ЦОД, ориентированную на приложения •  Детали архитектуры ACI фабрики •  Интеграция сервисов и гипервизоров •  Контроллер APIC •  Коммутаторы Nexus 9000

12/9/13 © 2013 Cisco and/or its affiliates. All rights reserved. 2

Развитие сетевой и сервисной архитектуры ЦОД


Многоуровневая архитектура ЦОД

•  Управление на уровне отдельных устройств

•  Сложности при масштабировании (сервисная граница)

•  Ограниченная мобильность виртуальных машин на уровне стойки

Ядро

Распределение

Доступ

Эволюция сети ЦОД: настоящее и ближайшее будущее

 Управление ресурсами ЦОД при помощи политик

 Высокая масштабируемость

 Мобильность виртуальных машин внутри и между ЦОД

Проблемы решаемые архитектурой ЦОД следующего поколения

•  Приложения •  Сложность •  Масштабируемость •  Производительность •  Поддержка и обслуживание

•  Безопасность


Введение в инфраструктуру ЦОД, ориентированную на приложения


Основные тенденции

ПРИЛОЖЕНИЯ

Физические + Виртуальные

60-80% нагрузки виртуализировано

HADOOP, BIG DATA и аналитические приложения

~21% будет виртуализировано к 2016 году

ФРАГМЕНТАЦИЯ ГИПЕРВИЗОРОВ

42% организаций используют один и более гипервизоров

2 из 3 компаний среднего размера, находящихся в США планируют использовать облачные сервисы

ПУБЛИЧНЫЕ И ЧАСТНЫЕ ОБЛАКА

Основной принцип ACI - логическая конфигурация сети, не привязанная оборудованию


ACI фабрика

Неблокируемая фабрика на базе оверлеев

App DB Web

Внешняя сеть передачи данных

(Tenant VRF)

QoS

Filter

QoS

Service

QoS

Filter

Application Policy Infrastructure

Controller

APIC

ACI модель политик – концепция End-Point Group (EPG)

HTTPS Service

HTTPS Service

HTTPS Service

HTTPS Service

HTTP Service

HTTP Service

HTTP Service

HTTP Service

EPG - Web

EPG – логическая группа конечных хостов представляющих приложение целиком или компоненты

приложения, которая не зависит от сети

Примеры конечных хостов

•  Устройства, подключенные к сети напрямую или косвенно

•  Имеют адрес (identity), расположение (location), атрибуты (version, patch level)

•  Могут быть физическими или виртуальными

•  Примеры: -  Сервер -  Виртуальная машина -  СХД -  NIC, vNIC -  DNS

End Points = EP

Сервер

VM

Виртуальная машина

СХД

Клиент

EPG, подсети и политики

EPG не привязана к адресации в сети. Например при смене IP адреса на EP политика будет продолжать

применяться.

10.10.10.x

10.10.11.x Применение политики/правил

безопасности происходит на уровне EPG

HTTPS Service

HTTPS Service

HTTPS Service

HTTPS Service

HTTP Service

HTTP Service

HTTP Service

HTTP Service

EPG Web

Сетевой профиль приложения Application Network Profiles (ANP)

Входящие/ Исходящие политики

Сетевой профиль приложения

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

=

Входящие/ Исходящие политики

Определение контракта

Subject -‐ это комбинация следующих

действий-‐ filter, acDon и label

Контракты определяют правила

взаимодействия между EPG

Filter | Action | Label Subject

TCP Port 80 Фильтр

Permit Действие

Web Access Метка

Контракт 1 Subject 1

Subject 2 Subject 3

Опции политик: действия

Permit

Deny

Redirect

Log … …

Copy Packet

Mark Packet DSCP

Поддерживается 6 опций   Permit -‐ разрешить трафик   Block – заблокировать трафик   Redirect – перенаправить трафик   Log – логировать трафик   Copy – копировать трафик   Mark -‐ маркировать трафик (DSCP/CoS)

Контрактная модель Сетевой профиль приложения

C Контракт

Контракт определяет какую услугу один EPG предоставляет

другому EPG

Можно использовать шаблоны контрактов

(повторное использование = упрощение)

C

C

EPG NFS

EPG MGMT

EPG DB EPG App EPG Web C C C

ACI сетевой профиль Управление фабрикой на основе политик/профилей

•  Расширение принципов сервисного профиля Cisco UCS® Manager на всю фабрику

•  Сетевой профиль: определение требований приложения без привязки к оборудованию (stateless принцип)   Уровни приложений (tiers)

  Политики регламентирующие взаимодействие

  Сервисы 4 – 7 уровня

  XML/JSON схема

•  Полная абстракция от физической инфраструктуры   устранение зависимости от инфраструктуры

  переносимость между фабриками различных ЦОД

## Network Profile: Defines Application Level Metadata (Pseudo Code Example) <Network-Profile = Production_Web> <App-Tier = Web> <Connected-To = Application_Client> <Connection-Policy = Secure_Firewall_External> <Connected-To = Application_Tier> <Connection-Policy = Secure_Firewall_Internal & High_Priority> . . . <App-Tier = DataBase> <Connected-To = Storage> <Connection-Policy = NFS_TCP & High_BW_Low_Latency> . . .

App Tier DB Tier

Storage Storage

Web Tier

Приложение

Сетевой профиль полностью описывает сетевые и сервисные потребности

приложения

Профиль приложения и его применение к сети

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

•  Коммутаторы автономно обновляют свои настройки на основе правил, определенных профилем приложения, в случае переезда/миграции приложения или его компонент

DB Tier

Storage Storage

Клиент приложения

Web Tier

App Tier

Профиль приложения: определяет сетевые требования приложения (сетевой профиль приложения)

Применение профиля: каждое сетевое устройство динамически производит изменения настройки, требуемые профилем

VM VM VM

10.2.4.7

VM

10.9.3.37

VM

10.32.3.7

VM VM

APIC

Мониторинг приложения Видимость на уровне приложения и его компонент

Действия: Не добавлять хосты или VM Отключить хост гипервизора Перебалансировать кластер

PetStore Событие

PetStore Dev •  Leaf 1 и 2 •  Spine 1 – 3 •  Atomic counters

PetStore Prod •  Leaf 2 и 3 •  Spine 1 – 2 •  Atomic counters

PetStore QA •  Leaf 3 и 4 •  Spine 2 – 3 •  Atomic counters

VXLAN

статистика для каждого узла

Физическая и виртуальная нагрузка

ACI фабрика предоставляет аналитические возможности следующего поколения

Приложение, потребитель (tenant) и инфраструктура: •  Показатели здоровья (health scores) •  Задержка •  Atomic counters •  Потребление ресурсов

Интеграция с управлением нагрузкой – первичное размещение и миграция

Триггерное событие

APIC

ACI: интеграция с сервисами 4 - 7 уровня Централизация, автоматизация и поддержка существующей модели

•  Эластичность вставки сервиса физического или виртуального

•  Помощь в административном разделении между уровнями приложения и сервиса

•  APIC – центральная точка контроля сети и согласовании политик

•  Автоматизация процесса развертывания/свертывания сервиса посредством программируемого интерфейса

•  Поддержка текущей операционной модели эксплуатации

•  Применение сервиса вне зависимости от места нахождения приложения

Web Server

App Tier A

Web сервер

Web Server

App Tier B

App сервер

Сервисная послед-ть “Security 5”

Политика перенаправления

Администратор приложения

Администратор сервиса

Серв.

граф

begin end Stage 1 …..

Stage N

Pro

vide

rs inst

inst

…

МСЭ

inst

inst

…

Балансировка

……..

Сервисный

профиль

Определение “Security 5”

Фабрика с поддержкой нескольких гипервизоров

•  Интегрированный шлюз для VLAN, VxLAN, NVGRE сетей

•  Нормализация для NVGRE, VXLAN и VLAN сетей

•  Заказчик не ограничен в выборе гипервизора

•  Фабрика готова к поддержке нескольких гипервизоров из коробки

Интеграция с виртуальным миром

Сетевой администратор


ФИЗИЧЕСКИЙ СЕРВЕР

VLAN VXLAN

VLAN NVGRE

VLAN VXLAN

VLAN

ESX Hyper-V KVM

Управление гипервизором

ACI фабрика

APIC

APIC

Открытая экосистема Все возможности доступны при помощи открытого API и модели данных

Объектно-ориентированная Автоматизация

RESTful XML / JSON

Открытая экосистема

Программируемость Полный доступ к системе

посредством API

Northbound API •  Быстрая интеграция с существующими средствами управления

•  OpenStack

•  Поддержка приложений и орг. cтруктуры (tenant)

Southbound API •  Опубликованная модель данных •  Open source •  Обеспечение переносимости приложений

*На момент FCS есть ограничения, обращайтесь за уточнениями

Системное управление

Управление гипервизорами

Средства автоматизации

Средства оркестрации

Детали архитектуры ACI фабрики


Обзор ACI фабрики

•  Наиболее эффективная фабрика в индустрии: ‒  1/10 Gb граница – высокая плотность 40 Gb spine

(возможность 100 Gb) ‒  1 миллион+ IPv4 и IPv6 хостов ‒  64,000+ логических организаций (tenants) ‒  220K+ 1/10 Gb хостов на одном уровне с переподпиской 3:1 на уровне фабрики

•  Маршрутизируемая фабрика – оптимальная передача IP трафика ‒  Масштабируемая коммутация (L2) и маршрутизация (L3) для VXLAN, NVGRE, VLAN

‒  Не требуются x86 шлюзы – физич. или вирт. ‒  Быстрота развертывания приложения – нет лимитов при выборе точки размещения в фабрике

•  Полная прозрачность – физическая или виртуальная нагрузка

•  Общие принципы управления от гипервизора до сервера, от фабрики до WAN

Spine Inline overlay hardware database 288 x 40 Gb ports Высокая плотность за умеренную стоимость

Оптимизация фабрики Использование протокола1588 для измерения задержки Применение ECMP

Масштабирование Интеллектуальное кеширование Поддержка терминации оверлеев Улучшенная аналитика

APIC

Application Policy

Infrastructure Controller

Обзор ACI фабрики

ACI Spine устройства

ACI Leaf устройства

•  ACI фабрика обеспечивает: ‒  Отделение функций идентификации (адресации конечных хостов) от точки их подключения к фабрике

‒  Независимость политик (правил фильтрации и т.д.) от адресации, топологии/аппаратуры

‒  Полную нормализацию инкапсуляции входящих в фабрику потоков: 802.1Q VLAN, IETF VXLAN, IETF NVGRE

‒  Распределенный шлюз на 3-м уровне для организации оптимальной передачи данных на 3-м и 2-м уровне

‒  Поддержку стандартной семантики коммутации и маршрутизации без ограничений (любой IP адрес в любом месте)

‒  Вставку сервисов и перенаправление трафика на сервисные узлы

‒  Устранение необходимости широковещательной рассылки (ARP, GARP) в IP-сегментах

APIC

ACI фабрика IP сеть с интегрированным оверлеями

•  ACI фабрика базируется на IP фабрике, обеспечивающей маршрутизацию во внешние сети и интегрированных оверлеях для маршрутизации/коммутации между хостами фабрики ‒  весь трафик между конечными хостами внутри фабрики передается при помощи оверлеев

•  Почему интегрированные оверлеи? ‒  Мобильность, масштабируемость, поддержка multi-tenancy и интеграция с гипервизорами

‒  Вместе с трафиком данных можно передавать мета-данных необходимые для реализации распределенных политик

IP фабрика с оверлеями Каждому узлу

назначается IP loopback, который анонсируется IS-IS

IP un-numbered 40 Gb линки

APIC

ACI фабрика Разъединение функций идентификации, расположения и политики

•  ACI фабрика производит разъединение функций адресации конечного хоста “identifier = IP-адрес” от расположения хоста, для которого используется точка терминации VXLAN “locator = VTEP-адрес”

•  Передача внутри фабрики между VTEP используется преимущества “улучшенного VXLAN” •  Отображение MAC адреса или IP адреса в место расположения производится при помощи

VTEP и распределенной базы (mapping database)

VTEP VTEP VTEP VTEP VTEP VTEP

Payload IP eVXLAN VTEP

APIC

ACI фабрика Нормализация инкапсуляции

VXLAN VNID = 5789

VXLAN VNID = 11348

NVGRE VSID = 7456

Any to Any

802.1Q VLAN 50

Нормализация инкапсуляции

Локализация инкапсуляции

IP фабрика использует eVXLAN тег

Данные IP eVXLAN VTEP

•  Весь трафик инкапсулируется при помощи extended VXLAN (eVXLAN) заголовка

•  Внешний тег VLAN, VXLAN, NVGRE на входящем порту отображается во внутренний eVXLAN тег

•  Внешние идентификаторы локализуются на уровне Leaf устройства или Leaf порта

•  Возможность переиспользования, если требуется

Данные

Данные

Данные

Данные

Данные

Eth IP VXLAN Outer

IP

IP NVGRE Outer IP

IP 802.1Q

Eth IP

Eth MAC

Нормализация входящей инкапсуляции

APIC

Передача данных независимо от расположения На 2-м и 3-м уровне

10.1.1.10 10.1.3.11 10.6.3.2 10.1.3.35 10.1.1.10 10.1.3.11 10.6.3.2 10.1.3.35

•  ACI фабрика поддерживает семантику 2-го и 3-го уровня -  никаких изменений в приложении не требуется

•  ACI фабрика обеспечивает оптимальную передачу трафика 2-го и 3-го уровня ‒  SVI распространяется по всем узлам где требуется, обеспечивая маршрутизацию ‒  Трафик 2-го и 3-го уровней напрямую передается на leaf с хостом назначения

•  IP ARP и GARP пакеты передаются напрямую узлу назначения без широковещательной рассылки

Распределенный шлюз по умолчанию Прямая передача ARP

APIC APIC

ACI фабрика – балансировка нагрузки Фокус на времени отклика приложения

•  ACI фабрика отслеживает перегрузки на всем пути передачи входящим и исходящим leaf (измерения в реальном времени) ‒  Перегрузка между внешними портами коммутаторов (external wires)

‒  Перегрузка между соединениями ASIC-to-ASIC (internal wires)

•  Фабрика балансирует потоки трафика по принципу ‘flowlet’ ‒  Динамическое перенаправление активных потоков с загруженного пути на менее загруженный путь передачи трафика

•  Фабрика приоритезирует небольшие потоки ‒  Обеспечение поведения как DC-TCP без модификации на конечном хосте

‒  Увеличение скорости передачи больших TCP потоков

APIC

Улучшение производительности приложений Эффективная фабрика

•  Увеличение емкости фабрики (в результате увеличение числа VM на порт)

•  Уменьшение времени отклика приложения по сравнению со стандартным ECMP

Динамическая балансировка и динамическая приоритезация

0

0.2

0.4

0.6

0.8

1

0.12 0.21 0.20

Нормализованное среднее

Flow

Com

plet

ion

Tim

e

На 80% улучшение параметра flow completion time у приложения На 60% улучшение утилизации емкости фабрики

Короткие потоки (0,100KB)

Средние потоки (100KB, 5MB)

Большие потоки (5MB, Inf)

ACI динамическая балансировка + приоритезация потоков

Стандартная ECMP сеть

Телеметрия Atomic Counters

Path 1 Path 2 Path 3 Path 4

Пакеты отправленные с Leaf 2 на Leaf 5

Path 1 2068

Path 2 2963

Path 3 2866

Path 4 2506

Разница

Path 1 2

Path 2 0

Path 3 -3

Path 4 0

Пакеты полученные на Leaf 5 отправленные с Leaf 2

Path 1 2066

Path 2 2963

Path 3 2869

Path 4 2506

APIC

Телеметрия Измерение задержки в фабрике

•  Матрица задержки между Leaf создается и поддерживается в актуальном состоянии на каждом Leaf

•  Средняя задержка на порт и вариация задержки в сторону других коммутаторов доступа (Leaf)

•  Измерение задержки для 99% пакетов

Пограничные часы

Синхронизация времени при помощи PTP

Внешний источник точного времени (Pulse Per Second [PPS]) на каждом супервизоре

шасси с ролью Spine

ACI фабрика 64,000+ Dedicated, One-Hop Tenant Networks

•  1 миллион+ IPv4 и IPv6 конечных хостов внутри одной фабрики •  64,000+ логических организаций (tenants) внутри одной фабрики •  200,000+ 10 Gb портов •  Нормализация инкапсуляции VXLAN, VLAN, NVGRE ‒  Нет необходимости в специальных шлюзах для объединения физических и виртуальных сегментов

‒  Без влияния на задержку и производительность

VM VM DB VM VM DB VM VM DB VM VM DB

QFP QFP QFP QFP

APIC

Интеграция сервисов и гипервизоров


ACI: автоматизации вставки сервиса

•  Для автоматизации управления сервисов требуется device package. Это zip файл:

•  Спецификация устройства (XML файл)

•  Скрипт устройства (Python)

•  APIC взаимодействует с устройством при помощи Python скрипта

•  APIC использует модель устройства, описанную в XML файле для настройки устройства при помощи скрипта

•  Для коммуникации с устройством скрипт использует REST или CLI

Device Package Device Specification <dev type= “f5”> <service type= “slb”> <param name= “vip”> <dev ident=“210.1.1.1” <validator=“ip” <hidden=“no”> <locked=“yes”>

APIC – Policy Element Модель устройства

Специфичный для устройства Python скрипт

Скриптовый интерфейс APIC

Script Engine

Узел APIC

Интерфейс устройства: REST/CLI

Устройство предоставляющее сервис

(FW, SLB)

APIC

•  Сервисный граф настраивается в APIC

•  Определяет модель взаимодействия между EPG

•  В сервисной цепочке доступны следующие операции - split, join, tap и т.д.*

•  Общие сервисы: -  Firewall -  IPS -  TAP/Packet mirror -  ADC/SLB

Cервисная архитектура Определение сервисного графа

IPS EPG Outside EPG Web

TAP EPG App EPG DB

ADC EPG Web

EPG Desktop

EPG Mobile

ADC

EPG Web2

EPG AppA

EPG Web1

FW EPG App ADC EPG DB

*Straight Graph only at FCS

Tenant X

Автоматизация сервисных цепочек Роли и обязанности


•  Создание сервисного графа •  Применение сервисного графа

•  Загружает device package •  Подключает оборудование •  Регистрирует сервисные устройства и назначает их группам пользователей (tenants)

•  Публикует сервисный граф

Device Package A Device Package B Device Package C

Объекты управления: •  Сервисный граф

•  Конфигурация устройства и сервиса

Device A Device B Device C Device C Device A Device A


APIC

Фабрика с поддержкой нескольких гипервизоров

•  Интегрированный шлюз для VLAN, VxLAN, NVGRE сетей

•  Нормализация для NVGRE, VXLAN и VLAN сетей

•  Заказчик не ограничен в выборе гипервизора

•  Фабрика готова к поддержке нескольких гипервизоров из коробки




ФИЗИЧЕСКИЙ СЕРВЕР

VLAN VXLAN

VLAN NVGRE

VLAN VXLAN

VLAN

ESX Hyper-V KVM

Управление гипервизором

ACI фабрика

APIC

APIC

Координация политик с администраторами гипервизоров

•  Координация сетевых политик с администраторами систем виртуализации

•  Автоматическое детектирование виртуальных машин и применение политик

•  Политики применяют к физическим и виртуализированным ресурсам

•  Политика следует за VM


Управление гипервизорами

Web App DB

Профиль приложения

Координация сетевых политик

Web App DB

Нотификация о добавлении/удалении VM PortGroup

нотификация о перемещении VM

PortGroups VM Networks

APIC

APIC

Один EPG охватывает несколько VMM доменов

Фабрика нормализует (локализует) VLAN-ы что позволяет переиспользовать их номера между VMM доменами

Поддержка VXLAN со стороны гипервизора не требуется чтобы решить проблему 4K VLAN

EPG может охватывать несколько VMM доменов (общая политика)

VMM Домен 1

Hosts

vCenter

Web EPG App EPG

VM VM VM VM

VMM Домен 2

Hosts

DB EPG App EPG

VM VM VM VM VM

SCVMM

Контроллер APIC


Application Policy Infrastructure Controller Централизованная автоматизация и управление фабрикой

•  Унифицированная точка управления сетью ЦОД:

  Унифицированные профили для приложений

  Открытая модель данных для управления фабрикой при помощи внешних средств оркестрации

  Мониторинг приложений, поиск и устранение неисправностей фабрики целиком

  Интеграция с сервисами (Уровень 4 - 7, СХД, вычислит. ресурсы, WAN и т.д.)

  Управление образами (Spine / Leaf)

•  Кластер APIC поддерживает более миллиона конечных хостов, 200,000+ портов, 64,000+ логических организаций (tenant)

•  В планах управление вычислит. ресурсами и СХД

Сервисы 4..7 Управление системой

Управление СХД

Оркестрация

Storage SME Server SME Network SME

Security SME App. SME OS SME

Открытый RESTful API

Управление при помощи политик

APIC

Application Policy Infrastructure Controller Доступность и масштабирование кластера

•  Кластеризованный контроллер (N+1, N+2 и т.д.)

•  Любой узел может предоставить любой сервис любому пользователю

•  Бесшовное добавление и удаление узлов APIC в кластер

•  Полностью автоматизированный процесс обновления кластера с поддержкой отказоустойчивости даже во время обновления

•  Размер кластера зависит от количества транзакций

•  APIC не принимает непосредственное участие в передаче данных

Единая точка управления Но не единая точка отказа

APIC кластер Распределенный, Синхронизированный,

Реплицированный

APIC

ACI фабрика – единый объект управления

Root

MO •  class •  dn •  prop1 •  prop2 •  …

dMIT

Полное, унифицированное описание сущностей

Нет искусственного разделения между конфигурацией, состоянием и данными реального времени

Все сущности внутри ACI фабрики являются объектами

Объекты иерархически организованы

Классы определяют типы объектов Карты, порты, path, EPG и т.д.

Наследие классов •  access port является подклассом port •  leaf node является подклассом fabric node

Наборы атрибутов

Идентификаторы Состояния Описания

Ссылки Lifecycle

Distributed Managed Information Tree (dMIT) содержит исчерпывающую системную информацию

•  Обнаруженные компоненты •  Системная конфигурация •  Текущий статус, включая статистку и информацию о сбоях

ACI фабрика – организация управления Аутентификация, Авторизация, RBAC

Доступ ко всем объектам управления после аутентификации и по защищенному каналу

Каждый объект имеет уникальный набор RBAC атрибутов на ЧТЕНИЕ и ЗАПИСЬ

APIC и фабрика спроектированы изначально с поддержкой multi-tenant

Локальный и внешний сервис AAA (TACACS+, RADIUS, LDAP) для авторизации и аутентификации

Universe

Tenant: Pepsi

App Profile

EPGs

Layer 3 Networks

Tenant: Coke

App Profile

EPGs

Layer 3 Networks

Фабрика

Коммутаторы

Линейные карты

Порты

APIC

Коммутаторы Nexus 9000


  Стратегия Merchant+ ASIC   Современный и совершенный механический дизайн

  Следующее поколение операционной системы -  Автоматизация тестирования

  Два режима работы -  Standalone (NX-OS) -  Fabric Mode (требуется контроллер)

Представляем коммутаторы Nexus 9000

Nexus 9500 – конфигурация шасси

2 модуля супервизора

8 слотов для карт

6 модулей фабрики (за вентиляторами)

3 вентиляторных модуля

2 системных контроллера

4 блока питания (3000W AC)

Front to Back Airflow Линейные карты и модули фабрики

включаются друг в друга (без midplane)

Front Back

Nexus 9500 – конструкция шасси

 Эффективность питания и охлаждения

 Надежность  Будущие расширения

Коммутаторы Cisco Nexus 9000

Разные форм-факторы дают возможность применять устройства в ЦОД разного масштаба

Nexus® 9300 Nexus 9500

48 1/10G SFP+ & 12 QSFP+

Масштабирование

1

GE

/10

Gbp

s/40

Gbp

s/10

0 G

E Производительность

Производительность Порты Цена Программируемость Питание

FCS Q4

2013

96 1/10G-T & 8 QSFP+ FCS Q1

2014

12-port QSFP+ GEM FCS Q1

2014

ACI Ready Leaf Line Card 48 1/10G-T & 4 QSFP+

FCS Q1

2014

ACI-ready Leaf line card 48 1/10G SFP+ & 4 QSFP+

FCS Q1

2014

Aggregation line card 36 40G QSFP+

FCS Q4

2013

C9500 8-слотов FCS Q4

2013

Инновации в оптике: Устранение барьеров на пути к 40 Gb

Проблема

•  Стоимость трансиверов 40 Gb составляет существенную долю затрат (CAPEX)

•  40 Gb интерфейсы требуют новую каб. проводку

•  Использовать существ. 10 Gb MMF инфраструктуру •  Использовать существ. патч-корды (LC коннектор)

Решение

•  QSFP, MSA-compliant •  Dual LC коннектор •  Поддержка 100 m на OM3 и до 150m на OM4 •  TX/RX на двух длинах волн 20 Gb каждая

Cisco® 40 Gb SR-BiDi QSFP

Доступно в конце CY13 и поддерживается на всех Cisco QSFP портах

12/9/13 © 2013 Cisco and/or its affiliates. All rights reserved.

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

Спасибо

Contacts: Name: Maxim Khavankin Phone: +74999295710 E-mail : [email protected]

CiscoRu Cisco CiscoRussia

#CiscoConnectRu

Technology

Сетевая инфраструктура ЦОД, ориентированная на приложения и коммутаторы Nexus 9000