Эволюция технологий сетевой фабрики ЦОД
1 like1,306 views
Документ описывает эволюцию технологий сетевой фабрики для центров обработки данных (ЦОД), обсуждая историю термина и основные особенности архитектуры, такие как простота, масштабируемость и надежность. Приводится информация о различных моделях, например, spine-leaf, и подчеркивается растущая популярность сетевых фабрик из-за повышения производительности и устойчивости к отказам. Также упоминается концепция динамической автоматизации сети и интеграция с облачными решениями, а также принципы работы Cisco Application Centric Infrastructure (ACI).
Эволюция технологий сетевой фабрики ЦОД
- 1. Эволюция технологий сетевой фабрики ЦОД Скороходов Александр Системный инженер-консультант [email protected]
- 2. Что такое сетевая фабрика ЦОД? И что на ней производят? ;) • История термина • • • • Типовая архитектура коммутатора: матрица коммутации (“crossbar”) Похожа на структуру ткани (fabric) Отсюда термин «switching fabric» применительно к коммутационному элементу Network fabric – подчеркивает, что сеть «ведёт себя как коммутатор» • • Первоначально появилось применительно к сетям хранения данных Позднее – и применительно к сетям передачи данных (не обязательно в контексте конвергентного транспорта!)
- 3. Что такое сетевая фабрика ЦОД? В поисках определения • Нет одного формального определения • • • «Выглядит как коммутатор» Направление развития индустрии, а не конкретная технология Типичные свойства: • • • • • Простота – «плоская» архитектура с простой логикой коммутации, упрощение управления Масштабируемость – горизонтальное масштабирование, высокая производительность Надёжность – модель резерирования N+1, быстрая сходимость Гибкость – «любая нагрузка в любом месте»: растягивание сегментов Управляемость/программируемость – возможность гибко выстраивать («оркестировать») сетевой транспорт под потребности приложений
- 4. Модель «spine-leaf» (сеть Клоза) • Популярный подход для построения фабрик в ЦОД • Преимущества • Высокая устойчивость к отказам (N:1) • Высокая производительность Рисунок из статьи Чарльза Клоза, 1952 г. • Масштабируемость производительности и числа портов • Сокращение числа уровней и модулей • Почему набирает популярность? Уровень Spine («хребет») • Уход от STP! • Дальнейшее развитие… • Развитие масштабируемости и ускорение сходимости управляющих протоколов Уровень Leaf («листья») • Повышение эффективности балансировки трафика • Ограничение доменов отказов 4
- 5. Продолжение развития инфраструктуры ЦОД Многоуровневый дизайн Сетевые фабрики 26,000 заказчиков UCS Самая популярная платформа в индустрии Автоматизация фабрик Application Centric Infrastructure Fabric Path, DFA Федерированные облака Гибридные облака Инновации ACI 52,000 заказчиков NXOS Cisco ONE, Open Source Nexus, UCS Catalyst 6500, MDS Связность Виртуализация Упрощение Гибкость Federation
- 7. Распределённый коммутатор доступа «Фабрика доступа» • Не является полноценной «фабрикой» • • Нет горизонтального масштабирования Spine уровня Резервирование 1+1 с помощью LACP (или на уровне хоста) • Тем не менее, решает часть её традиционных задач • • Уход от опоры на Spanning Tree Единая точка управления • Модель управления – «один большой коммутатор» • Удобно для «сетевиков», но не помогает «прикладникам» • Подходит для небольших внедрений
- 8. Виртуальное модульное шасси с FEX Nexus 5500/6000/7000 + Nexus 2000 Cisco Nexus® 5500/6000 + Cisco Nexus® 2000 FEX Cisco Nexus® 7000/7700 + Распределённый виртуальный модульный коммутатор (3000+ портов Ethernet) Cisco Nexus® 2000 FEX Nexus 2000 FEX выполняет роль виртуальной карты для Nexus 5500/7000 Единый конфигурационный файл Между FEX и Nexus 5500/7000 не используется STP 8
- 9. Fabric Extender(FEX) унификация уровня доступа • • • • • • Поддержка Nexus 5000/5500, 7000 и UCS 6100 как «материнских устройств» Сочетание моделей внедрения EoR, MoR, ToR Миграция к 10GE и FCoE подключениям серверов Сочетание типов кабелей (оптика и медь) Гибкость выбора головных устройств, типов FEX, способа размещения и соединения Поддержка модулей для блейд-систем HP, Dell, Fujitsu, IBM Nexus 2000 Fabric Extender VSS/vPC Nexus 6000 FET/Twinax Медь/ Twinax Серверы Уровень доступа
- 10. Cisco FabricPath
- 11. Горизональное масштабирование производительности Spanning-Tree vPC FabricPath 16 коммутаторов Активных путей Производительность блока Один Два 16 До 15 Тбит/с До 30 Тбит/с До 240 Тбит/с Масштабируемость Layer 2 Виртуализация инфраструктуры и производительность
- 12. Cisco FabricPath: ключевые возможности • Маршрутизация на втором уровне – «лучшее из двух миров»: «надмножество» возможностей IETF TRILL • • Устранение Spanning-Tree Protocol внутри сети • • Быстрая сходимость, оптимальные пути Стабильность, сходимость, производительность Использование до 16 альтернативных путей (ECMP) – до 256 соединений! • • • горизональное масштабирование производительности снижение чувствительности к отказам Выучивание MAC «по диалогам» • • Совместимость с «классическим» Ethernet • • • эффективное использование таблиц VPC+ обеспечивает VPC в L2MP сеть Поддержка FEX для ещё большей масштабируемости Простота настройки
- 13. Принцип коммутации в FabricPath DSID→20 SSID→10 DMAC→B SMAC→A Payload S10 DSID→20 SSID→10 DMAC→B SMAC→A Payload Ingress FabricPath Switch DMAC→B SMAC→A Payload MAC A • • • • → CE interface S20 Egress FabricPath Switch Payload SMAC→A DMAC→B FabricPath Core STP DMAC→B SMAC→A Payload → FabricPath interface STP Payload SMAC→A DMAC→B MAC B Входной FabricPath коммутатор определяет Switch ID выходного и добавляет заголовок FabricPath Switch ID выходного коммутатора используется для маршрутизации в ядре FabricPath Не нужно выучивание или просмотр MAC адресов в ядре Выходной FabricPath коммутатор снимает заголовок FabricPath и передаёт фрейм в CE порт
- 14. Диалоговое выучивание MAC адресов в FabricPath (conversational MAC Learning) • Используется для экономии места в таблицах на пограничных коммутаторах • • Локальный – MAC, подключенный к коммутационному блоку CE портом Удалённый – MAC, подключенный к другому коммутатору или коммутационному блоку Удалённые MAC выучивается только если между ним и локальным MAC возникает «диалог» MAC IF/SID B S200 (remote) C e7/10 (local) Коммутаторы ядра FabricPath вообще не выучивают MAC адреса Коммутатор различает два типа MAC адресов: FabricPath MAC Table on S300 Выучивание MAC не вызывается широковещательными пакетам S300 S100 FabricPath Core S200 MAC B MAC A FabricPath MAC Table on S100 FabricPath MAC Table on S200 MAC IF/SID MAC IF/SID A e1/1 (local) A S100 (remote) B S200 (remote) B e12/1(local) C S300 (remote)
- 15. VPC+ для сопряжения с традиционными сетями • VPC+ обеспечивает PortChannelподключение к пограничным коммутаторам FabricPath домена внешних не-FabricPath устройств • • S3 L1 FP FP VPC+ FP S1 FP FP CE коммутатор, маршрутизатор, сервер и т.д. VPC+ создаёт «виртуальный FabricPath коммутатор» чтобы обеспечить балансировку нагрузки в FabricPath домене При настройке HSRP на VPC+ домене HSRP MAC адрес ассоциируется с виртуальным коммутатором – все пути и оба устройства активны L2 S2 FP po3 Физически Host A Логически S3 L1 FP S1 Host A→S4→L1,L2 L2 FP VPC+ FP FP FP S2 FP S4 Виртуальный “Switch 4” становится next-hop коммутатором для хоста A в FabricPath домене po3 Host A
- 16. Маршрутизация L3 в сети FabricPath VPC+ и Anycast HSRP VPC+ L3 L2 • • Anycast HSRP L3 L2 vPC+ использует Emulated Switch ID (ESID) как «источник» vMAC шлюза по умолчанию. Маршрутизация на паре коммутаторов – Spine или выделенная пара Leaf Anycast HSRP (поддерживается с NX-OS 6.2.2): использует Anycast Emulated Switch ID (A-ESID) как «источник» vMAC шлюза по умолчанию. Маршрутизацию осуществляют до 4 коммутаторов (на данном этапе, потенциально – до 16) с распределением нагрузки между ними
- 17. FabricPath в корпоративном ЦОД Альтернатива традиционной архитектуре с STP • Существенное повышение производительности • Сокращение числа устройств • Повышение надёжности • Упрощение эксплуатации меньше устройств проще настройка Традиционная сеть со Spanning Tree Сеть на базе FabricPath 2:1 Fully Non-Blocking FabricPath 4 Pods 8:1 Oversubscription 16:1 Blocked Links 64 Access Switches 2, 048 Servers 8 Access Switches 2, 048 Servers
- 19. Архитектура Dynamic Fabric Automation • Анонсирована на CiscoLive Orlando в июне 2013, доступность планируется на начало 2014 года • Включает в себя: • • • Оптимизированный распределённый транспорт: L2+L3, физические и виртуальные узлы Виртуальные «сетевые контейнеры» на основе виртуальных сегментов до уровня физических серверов и VM Программируемость, автоматизация, открытые API • Опирается на существующие семейства оборудования: Nexus 6000/7000/7700 • Строится на существующих технологиях Nexus/NX-OS с дополнительными улучшениями и единым управлением с возможностями программирования и автоматизации • Подобнее услышать и увидеть можно на демосессии 21 ноября
- 20. Архитектура Dynamic Fabric Automation • Анонсирована Cisco в июне 2013 • Возможности: • • • Оптимизированный распределённый транспорт: L2+L3, физические и виртуальные узлы Виртуальные «сетевые контейнеры» на основе виртуальных сегментов до уровня физических серверов и VM Программируемость, автоматизация, открытые API • Опирается на существующие семейства оборудования: Nexus 6000/7000/7700 • Существующие технологиях Nexus с дополнительными улучшениями и единым управлением с возможностями программирования и автоматизации
- 21. Архитектура Dynamic Fabric Automation …Оптимизированная сеть Network Config Profile Network Services Profile n1000v# show port-profile name WebProfile port-profile WebServer-PP description: status: enabled system vlans: port-group: WebServers config attributes: switchport mode access switchport access vlan 110 no shutdown security-profile Protected-Web-Srv evaluated config attributes: switchport mode access switchport access vlan 110 no shutdown assigned interfaces: Veth10 Достоинства Любая подсеть в любом месте по потребности Сокращение доменов отказов Масштабируемость и отказоустойчивость Управление конфигурациями по шаблонам Network Manager Network Services Controller N Spines/Paths + scale-out model Any/all leaf distributed default gateways Any/all subnets on any leaf
- 22. Архитектура Dynamic Fabric Automation Сеть: распределённый «шлюз по умолчанию» Распределённый «шлюз по умолчанию» L3 L2 IP: 11.1.1.1 GW IP: 10.1.1.1 GW MAC: 0011:2222:3333 • Любая подсеть на любом узле Все узлы могут разделять IP и MAC адрес шлюза – без HSRP ARPы терминируются на входе в сеть – нет фладинга • Упрощает мобильность VM Mobility, распределение нагрузок, организацию кластеров Облегчает масштабирование
- 23. Архитектура Dynamic Fabric Automation Сеть: служебные протоколы фабрики Распространение информации о хостах Используются iBGP RRs Мультикаст группы также распространяются через iBGP ISIS для связности внутри фабрики Достижимость коммутаторов внутри фабрики Поддержание альтернативных маршрутов (ECMP) Быстрая реакция на отказ линков/узлов Не распространяет информацию о хостах/ подсетях и управляющий трафик Четкое разделение уровней управления R R R R WAN/Core
- 24. Архитектура Dynamic Fabric Automation …Виртуальные фабрики (vFabric) Достоинства Сегментация маршрутизации и коммутации Масштабируемые и безопасные «Видимость» для трафика клиентов Любая нагрузка – и клиент – в любом месте HR Finance Manufacturing Sales
- 25. Архитектура Dynamic Fabric Automation Виртуальные фабрики и сегменты Orgs Partition1 Network1 Network2 VRF1 Partition2 Network1 Network2 Локальные номера VLAN-IDs на узлах | Segment1 VRF2 Segment2 24-бит сегмент | Segment1 Segment2 VRF • Фрейм приходит от VM • Узел на входе: местный VLAN => 24bit SegID • Ядро: транспорт на основе SegmentID • Узел на выходе : 24bit SegID => местный VLAN • Передача фрейма VM-получателю WAN/Core
- 26. Архитектура Dynamic Fabric Automation …Управление и мониторинг Достоинства Автоконфигурация устройств Проверка плана коммутации СКС Единая точка доступа к фабрике Автоматическое развертывание Видимость на уровне сети, vFabric и хостов TFTP Services DHCP Services XMPP Server LDAP Message Broker
- 27. Архитектура Dynamic Fabric Automation Функции управления Central point of Management Discover Fabric Topology Image & Config Repository Monitor Fabric Common Point of Access Switch# show vlan Vlan ---------------------------------------------------------------------------Ethernet VLAN Type Mode Status D) -- WAN/Core Open APIs Топология фабрики: обнаружение топологии, проверка соответствия плану коммутации Образы ПО и конфигурации: автоконфигурация узлов версиями ПО и шаблонами настроек Мониторинг: сбор статистики, информация о хостах и VM Единая «точка входа»:доступ ко всем устройствам, упрощение диагностики Открытые API: расширение возможностей, изменение поведения, замена управляющих компонентов
- 28. Архитектура Dynamic Fabric Automation Простота развёртывания CPOM b vCD UCS Director Configuration Profiles Vrf x Interface bdi OpenStack a b Tenant Network Orchestration 1 Cisco N1kV OVS a Автоматически 2 Create Tenant Network Communicate Tenant Network to Fabric New VM gets created in Red Network Instantiates Red network 1 a 2 b
- 29. Архитектура Dynamic Fabric Automation Поддержка физических серверов Integrated Management Pane ARP-ND DHCP Server Configuration Profiles • С использованием DHCP, ARP, ARP-ND • • Прослушивание DHCP/ARP/GARP/RARP – или использование профилей DCNM бандла Узлы создают сегменты, VRF, SVI и связанные с ними политики Любой сервер модет подключиться к любому узлу – не нужна предварительная конфигурация Конфигурационные профили Заранее настроенноые шаблоны на узлах Загружаются с помощью открытых протоколов (LDAP, XMPP)
- 30. Архитектура Dynamic Fabric Automation …Автоматизация и открытая среда Достоинства Любая вычислительная нагрузка в любом месте Открытая интеграция с системами оркестрации Автоматическое масштабируемое развёртывание Фабрика с «пониманием» нагрузок Cloud Stacks Compute & Storage Policies Network & Network Services Policies Open APIs Fabric Mgmt Provisioning Network Services Controller Flow Controller Published Schemas
- 31. Архитектура Dynamic Fabric Automation …Поддержка оборудования Nexus 7X00 (F2/F2e/F3) Cloud Stacks & Orchestration Tools High Density Spine Nexus 6004 Medium Density Spine Compute & Storage Nexus 7X00 (F3) Network DCNM/CPoM Nexus 6001/6002 Network Services High Density Leafs ToR Leafs Nexus 6004 Border Leafs Fabric Extenders Nexus 2x00 Services Controller Fabric Extenders Nexus 2x00
- 33. Cisco Application Centric Infrastucture (ACI) • Новая идеология организации инфраструктуры ЦОД • Представлена в ноябре 2013 г • Разработана компанией Insieme, вошедшей в состав Cisco • Ключевые возможности: • • • • • • • Оперирует терминами инфраструктуры, а не устройств; приложений, а не сети Единый подход к физическим и виртуальным серверам на разных платформах Телеметрия – задержки, потери, общее «состояние здоровья» Встроенная программируемость на уровне инфраструктуры в целом с открытым API Встраивание сервисов – как Cisco, так и третьих компаний Высокая производительность и масштабируемость Низкий CapEx и OpEx: открывает путь к миграции 1G->1/10G, 10G->40G
- 34. Cisco Application Centric Infrastucture (ACI) • Базовые технологические компоненты: • • • Новые коммутаторы семейства Nexus 9000 – доступны уже сейчас Контроллер Cisco APIC (Application Policy Integrated Controller) – ожидается в 2014 г Application Virtual Switch (AVS) – продолжение технологии Nexus 1000V для интеграции с ACI • Открытость и широкая экосистема • • • Открытые интерфейсы «вверх» для систем управления и оркестрации и «вниз» для виртуальных коммутаторов Средства безопасности и другие L4-7 сервисы от Cisco и других производителей В числе анонсе 6 ноября участвовали – IBM, Citrix, Microsoft, F5, EMC, Redhat, NetApp, SAP, VCE, Symantec… • Подробнее – в выступлении Максима Хаванкина «Сетевая инфраструктура ЦОД, ориентированная на приложения и коммутаторы Nexus 9000» 21 ноября
- 35. Основной принцип ACI - логическая конфигурация сети, не привязанная к оборудованию App Web Внешняя сеть передачи данных DB QoS QoS QoS МСЭ, LB LB ACL APIC ACI фабрика Application Policy Infrastructure Controller Неблокируемая фабрика на базе оверлеев 11.12.2013 © 2013 Cisco and/or its affiliates. All rights reserved. 35
- 36. Любое приложение в любой среде – физической или виртуальной Сетевой профиль приложения WEB F/W L/B APP L/B DB SLA APIC ПОЛИТИКА ВЗАИМОДЕЙСТВИЯ QoS ПОЛИТИКА БЕЗОПАСНОСТИ QOS Security Load Balancing APP PROFILE HYPERVISOR HYPERVISOR HYPERVISOR СЕРВИСЫ L4..7 ХРАНЕНИЕ И ВЫЧИСЛЕНИЯ
- 37. ACI сетевой профиль Управление фабрикой на основе политик/профилей Приложение • Расширение принципов сервисных профилей Cisco UCS® Manager на всю фабрику • Сетевой профиль: определение требований приложения без привязки к оборудованию (stateless принцип) ̶ Уровни приложений (tiers) ̶ Политики регламентирующие взаимодействие ̶ Сервисы 4 – 7 уровня ̶ XML/JSON схема • Полная абстракция от физической инфраструктуры ̶ устранение зависимости от инфраструктуры ̶ переносимость между фабриками различных ЦОД Storage Web Tier Storage App Tier DB Tier Сетевой профиль полностью описывает сетевые и сервисные потребности приложения ## 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> ...
- 38. Профиль приложения и его применение к сети Клиент приложения Профиль приложения: определяет сетевые требования приложения (сетевой профиль приложения) Storage Storage App Tier Web Tier DB Tier Применение профиля: каждое сетевое устройство динамически производит изменения настройки, требуемые профилем APIC VM VM 10.2.4.7 VM 10.9.3.37 VM VM VM VM 10.32.3.7 Вся передача данных в фабрике управляется при помощи профилей приложений • IP адреса полностью переносимы и могут использоваться где угодно внутри фабрики • Безопасность и передача данных не зависят от любых физических и логических сетевых атрибутов • Коммутаторы автономно обновляют свои настройки на основе правил, определенных профилем приложения, в случае переезда/миграции приложения или его компонент
- 39. Свойства ACI фабрики ACI Spine устройства Application Policy Infrastructure Controller ACI Leaf устройства • ACI фабрика обеспечивает: ‒ Отделение функций идентификации (адресации конечных хостов) от точки их подключения к фабрике ‒ Независимость политик (правил фильтрации и т.д.) от адресации, топологии/аппаратуры ‒ Полную нормализацию инкапсуляции входящих в фабрику потоков: 802.1Q VLAN, IETF VXLAN, IETF NVGRE ‒ Распределенный шлюз на 3-м уровне для организации оптимальной передачи данных на 3-м и 2-м уровне ‒ Поддержку стандартной семантики коммутации и маршрутизации без ограничений (любой IP адрес в любом месте) ‒ Вставку сервисов и перенаправление трафика на сервисные узлы ‒ Устранение необходимости широковещательной рассылки (ARP, GARP) в IP-сегментах APIC
- 40. Передача данных независимо от расположения На 2-м и 3-м уровне APIC 10.1.1.10 10.1.3.1 1 10.6.3.2 Распределенный шлюз по умолчанию 10.1.3.35 APIC 10.1.1.10 10.1.3.1 10.6.3.2 1 Прямая передача ARP • ACI фабрика поддерживает семантику 2-го и 3-го уровня - никаких изменений в приложении не требуется • ACI фабрика обеспечивает оптимальную передачу трафика 2-го и 3-го уровня ‒ SVI распространяется по всем узлам где требуется, обеспечивая маршрутизацию ‒ Трафик 2-го и 3-го уровней напрямую передается на leaf с хостом назначения • IP ARP и GARP пакеты передаются напрямую узлу назначения без широковещательной рассылки 10.1.3.35
- 41. Полная «видимость» приложений Единый источник данных о приложении в распределённой среде «ЗДОРОВЬЕ» 96% ЗАДЕРЖКА APIC 5 Microsecond(s) ПОТЕРИ 25 Packets Dropped РЕСУРСЫ 7 VMs 3 Physical Load Balancer Firewall 41
- 42. Мониторинг приложения Видимость на уровне приложения и его компонент ACI фабрика предоставляет аналитические возможности следующего поколения PetStore Событие Триггерное событие Действия: Не добавлять хосты или VM Отключить хост гипервизора Перебалансировать кластер Приложение, потребитель (tenant) и инфраструктура: • Показатели здоровья (health scores) • Задержка PetStore Dev PetStore Prod PetStore QA • Leaf 1 и 2 • Spine 1 – 3 • Atomic counters • Leaf 2 и 3 • Spine 1 – 2 • Atomic counters • Leaf 3 и 4 • Spine 2 – 3 • Atomic counters • Atomic counters • Потребление ресурсов APIC Интеграция с управлением нагрузкой – первичное размещение и миграция VXLAN статистика для каждого узла Физическая и виртуальная нагрузка
- 43. #CiscoConnectRu Спасибо Пожалуйста, заполните анкеты. Ваше мнение очень важно для нас. Contacts: Name Phone E-mail Александр Скороходов +7(495)961-1410 [email protected] CiscoRu Cisco CiscoRussia