Arista. Знакомство

в 9:09, , рубрики: eos, Сетевое оборудование, метки:

Arista. Знакомство

На Хабре нет ни одного поста про коммутаторы компании Arista Networks. При этом есть несколько комментариев, по-моему, достаточно положительных по смысловой окраске.

Мне захотелось написать про эту компанию, их оборудование, операционную систему EOS и CLI.

Отмазки

Я не являюсь представителем вендора и у меня нет глубоких познаний по всей линейке. Топик носит обзорный характер и отражает моё личное мнение. Для мнений читателей есть комментарии и новые топики.

История Arista

Как сообщает книга Arista Warrior и соответствующий раздел сайта, в появлении Arista Networks виновны три ключевые фигуры:

  • Andy Bechtolsheim
    Один из основателей Sun Microsystems. В 1995 он покидает Sun и создает Granite Systems, целью которой является производство высокоскоростных сетевых коммутаторов. В 1996 компания Cisco покупает Granite Systems. Под его руководством в Cisco создается серия коммутаторов Catalyst 4500. Andy покидает Cisco в 2003 и создает Kealia — компания по производству серверов нового поколения, которую в 2004 покупает Sun.
    В 2005 он становится одним из основателем Arasta, впоследствии сменившей название на Arista Networks.
  • David Cheriton
    Один из основателей Granite Systems. Главный архитектор микросхем ASIC для линейки Catalyst 4X00 в Cisco. Так же был техническим консультантом для Google, VMware, Tibco, Cisco, Sun и нескольких стартапов.
  • Kenneth Duda
    Первопроходец в высокопроизводительном сетевом ПО и ведущий архитектор EOS в Arista. Он один из авторов спецификаций нескольких сетевых протоколов, например: VXLAN и NVGRE. Был первым наемным сотрудником в Granite Systems и вел разработку ПО для линейки Catalyst 4X00.

Jayshree Ullal занимает должность CEO. Она была старшим вице-президентом в Cisco и несла ответственность за линейки Cisco Nexus 7000, Catalyst 4500, и Catalyst 6500. В 2005 года журнал «Network World Magazine» включил её в список «50 самых властных людей» («50 Most Powerful People»).

Продуктовая линейка.

Arista Networks предлагает только коммутаторы и конечно же сопутствующие товары (кабели питания, трансиверы, сервис и т.п.). Свои свитчи Arista позиционирует для применения в Центрах Обработки Данных (ЦОД).

Краткая свободная таблица (кликабельно) по некоторым параметрам из Arista Products Quick Reference Guide (параметров больше, например, есть аппаратная поддержка VXLAN):
Arista. Знакомство

Компания не производит маршрутизаторы, Wi-Fi AP, устройства SOHO, межсетевые экраны и прочие сетевые устройства.

Merchant Silicon

Data Plane («плоскость передачи данных») в коммутаторах Arista построен с использованием интегральных схем специального назначения — ASIC.

По типу происхождения ASIC делятся на:

  • Custom Silicon — микросхемы, которые обычно разработаны и произведены компанией, которая производит на этих чипах коммутаторы.
  • Merchant Silicon — «коммерчески» доступные микросхемы, разработанные и произведенные компанией, которая не производит на них коммутаторы.

Простой пример для аналогии из мира смартфонов:

  • Компания HTC не производит CPU для своих смартфонов, но смартфоны собирает и продает на, например, микросхемах Qualcomm. Это пример Merchant Silicon.
  • Компания Samsung выпускает как набор микросхем Exynos, так и смартфоны на них. В случае с Samsung — это пример Custom Silicon.

Arista не разрабатывает собственные ASIC, а использует в своих коммутаторах Merchant Silicon от Intel и Broadcom.

С одной стороны, в этом нет ничего уникального. Например, на ASIC StrataXGS Trident II фирмы Broadcom построены следующие коммутаторы некоторых вендоров (вендоры в алфавитном порядке):

  • Arista 7050X
  • Cisco Nexus 9000
  • Extreme Networks Summit X770
  • Juniper QFX5100

С другой стороны, при таком подходе на первое место выходят такие параметры коммутатора, как:

  • Качество программирования и использования ресурсов ASIC. ASIC — это не просто plug and play, их ресурсами можно программно управлять (в этом заключается гибкость (в некотором диапазоне) использования этих микросхем). От качества алгоритмов и кода зависит поведение коммутатора на трафике.
  • Конструкция как внутренняя (выбор (например, вариант CPU, количество и тип ОЗУ) и компоновка элементов на платах, вентиляторы, блоки питания), так и внешняя (количество юнитов, удобство расположения портов и т.д.)
  • Качество и удобство ОС и CLI коммутатора.
  • Наличие нужных и удобных дополнительных возможностей, реализованные как на основе ASIC, так и программно на RE. При этом необходимо не забывать, что некая функция может поддерживаться в ASIC, но не поддерживаться ОС коммутатора. В этом случае, она просто не будет доступна к использованию. Хуже, когда функция, выполняющая функции Data Plane, реализована не в ASIC, а программно.

Про такие характеристики коммутаторов Arista Networks, как задержки и работа с буфером, ходят презентации, слухи и еще раз комментарии на Хабре.

EOS

EOS — это модульная операционная система, которая обеспечивает работу коммутаторов Arista. Она одна для всей линейки свитчей не только по названию. Кто обновлял хотя бы раз IOS на коммутаторах Cisco знает, что IOS c3550*.bin не подойдет в тот коммутатор, где используется c3750*.bin. А кто работал с Juniper знает, что jinstall-ex-4500*.tgz не заменит jinstall-ex-4200*.tgz. У Arista пока получается делать единый файл с ОС для всей линейки. Не главный плюс EOS, но удобный.

EOS базируется на Fedora. ОС работает на отдельном CPU (в данный момент — x86), что позволяет разделить Control Plane («плоскость управления» — CPU, EOS) и Data Plane («плоскость передачи данных» — ASIC). Всё это не ново, но есть и архитектурные особенности в EOS, которых нет в ОС других вендоров. Так, например, компоненты, необходимые для работы коммутатора, не обмениваются данными друг с другом напрямую, а делают это только через специальный менеджер-базу — Sysdb. Sysdb является как общей шиной для коммуникации между процессами, так и базой данных для рабочей информации этих процессов. Например, маршрут, пришедший по IGP, перед тем, как попасть в ASIC, передается процессом, отвечающим за IGP, в Sysdb; Sysdb сохраняет его у себя в закромах и передает в процесс, отвечающий за взаимодействие с ASIC.

С помощью работы через Sysdb получается обеспечить большую выживаемость и стабильность. Например, что-то произошло с сервисом, отвечающим за SNMP (например, сложносформированные данные в запросе вызвали сбой), и он умер. Менеджер процессов (ProcMgr) автоматически перезапускает сервис SNMP. После запуска все сервисы обращаются к Sysdb и, если там уже есть их данные, то они их восстанавливают и продолжают с ними работать.

При традиционном построении ОС (в том числе для сетевых устройств) компоненты, службы и сервисы передают данные между собой напрямую. Перезапуск или «падение» процесса-сервиса влечет за собой потерю всех его рабочих данных (маршрутов, статистики и прочего), а так же может сказаться на других сервисах, с которыми невезучий процесс работал и обменивался данными: они могут тоже «упасть» или потерять состояния, необходимые для работы.

Схематичная структура «традиционной ОС» и Arista EOS:

Arista. Знакомство Arista. Знакомство

(картинки из «EOS Architecture Whitepaper».)

Подобное устройство EOS не гарантирует полную устойчивость и безотказность, но все же это лучше, чем ничего. А еще с помощью функционирования через Sysdb реализован ISSU сервисов.

CLI

Cli (в EOS у всех запускаемых приложений от Arista имена с заглавной буквы) тоже работает через Sysdb.

Команды CLI написаны на Python:

[admin@localhost ~]$ cd /usr/lib/python2.7/site-packages/CliPlugin/
[admin@localhost CliPlugin]$ ls -a *Cli*py
AaaCli.py	     CliSchedulerCli.py      FaultInjectionCli.py	 IraIpCli.py		     MlagShowCli.py	   PimCli.py		   RipShowTechCli.py	TapAggIntfCli.py
AclCli.py	     ClockCli.py	     FhrpCli.py			 IraIpIntfCli.py	     MlagTunnelCli.py	   PimShowTechCli.py	   RouteEventMonCli.py	TcpdumpCli.py
AclCliRules.py	     CpuFabricCli.py	     FileCli.py			 IraShowTechCli.py	     MlagWarningCli.py	   PmbusCli.py		   RouteMapCli.py	TechSupportCli.py
AgentCli.py	     DcbxCli.py		     FruCli.py			 IraVrfCli.py		     ModuleCli.py	   PortSecCli.py	   RoutingBgpCli.py	TrackingCli.py
AgentPingCli.py      DebugMessageCli.py      IgmpCli.py			 LagCli.py		     ModuleIntfCli.py	   PowerCli.py		   RoutingIsisCli.py	UplinkFailureDetectionCli.py
AgentResourceCli.py  DebuggingCli.py	     IgmpProfileCli.py		 LagIntfCli.py		     MoreCli.py		   PowerDiagsCli.py	   RoutingOspf3Cli.py	VersionCli.py
AgentShutdownCli.py  DhcpRelayHelperCli.py   IgmpShowTechCli.py		 LagIntfMlagCli.py	     MrouteCli.py	   PsmiCli.py		   RoutingOspfCli.py	VlanCli.py
ArpEventMonCli.py    DiagCli.py		     IgmpSnoopingCli.py		 LagShowTechCli.py	     MrouteEtbaCli.py	   PtpCli.py		   RoutingRipCli.py	VlanIntfCli.py
ArpIp6Cli.py	     DonkeyCli.py	     IgmpSnoopingDebugCli.py	 LanzCli.py		     MrouteEventMonCli.py  QosCli.py		   SectionCliLib.py	VmTracerCli.py
ArpIpCli.py	     EbraEthIntfCli.py	     IgmpSnoopingEtbaCli.py	 LanzIntfCli.py		     MrouteShowTechCli.py  RadiusCli.py		   SendCli.py		VmTracerIntfCli.py
ArpIpIntfCli.py      EbraEthIntfCliModel.py  IgmpSnoopingEventMonCli.py  LauncherDaemonCli.py	     MsdpCli.py		   RedSupCli.py		   SflowCli.py		VxlanCli.py
BackupIntfCli.py     EbraShowTechCli.py      IgmpSnoopingShowTechCli.py  LinkFlapCli.py		     NetworkCli.py	   RedSupCliFormatSpec.py  ShellCli.py		WaitForWarmupCli.py
BeaconLedCli.py      EbraSnmpCli.py	     InstallCli.py		 LldpConfigCli.py	     NetworkToolsCli.py    RedSupFileCli.py	   SnmpCli.py		WatchCli.py
BfdCli.py	     EmailCli.py	     IntfCli.py			 LldpStatusCli.py	     NetworkUrlCli.py	   ReloadCauseCli.py	   StormControlCli.py	XcvrCli.py
BootCli.py	     EnvironmentCli.py	     IntfRangeCli.py		 LoggingCli.py		     OldDhcpRelayCli.py    ReloadCli.py		   StpCli.py		XcvrConfigCli.py
BridgingCli.py	     ErrdisableCli.py	     IntfSnmpCli.py		 LoopbackIntfCli.py	     OpenFlowCli.py	   ReloadConfigSaveCli.py  StpCliLib.py
BridgingCliModel.py  EthIntfCli.py	     Ip6NdCli.py		 MacEventMonCli.py	     PciCli.py		   ReloadElectionCli.py    StpIntfCli.py
BridgingEtbaCli.py   EthShowTechCli.py	     IraCommonCli.py		 MacFlapCli.py		     PeerIntfCli.py	   ReloadFileSyncCli.py    SupeSessionCli.py
CliCli.py	     EventCli.py	     IraEtbaCli.py		 ManagementActiveIntfCli.py  PfcCli.py		   RibIp6Cli.py		   SwitchIntfCli.py
CliCliModel.py	     EventMonCli.py	     IraIp6Cli.py		 MirroringCli.py	     PhyCli.py		   RibIpCli.py		   SysMgrCliLib.py
CliError.py	     ExtensionMgrCli.py      IraIp6IntfCli.py		 MlagConfigCli.py	     PhyConfigCli.py	   RibShowTechCli.py	   TacacsCli.py
[admin@localhost CliPlugin]$ head VlanCli.py
==> VlanCli.py <==
# Copyright (c) 2006-2011 Arista Networks, Inc.  All rights reserved.
# Arista Networks, Inc. Confidential and Proprietary.

#-------------------------------------------------------------------------------
# This module implements VLAN configuration.  In particular, it provides:
# -  the Vlan class
# -  the VlanSet class
# -  the "config-vlan" mode
# -  the "[no] vlan <vlan_set>" command
# -  the "[no] name <vlan_name>" command

Пользователям можно изменять как встроенные команды, так и писать свои.

Сама же работа в CLI похожа на работу в CLI Cisco IOS. Первое время кажется, что это копия (не как у Huawei, а именно копия). Но потом становятся видны доработки, которых очень не хватало в IOS.

Например, при изменении параметров группы интерфейсов не нужно слово «range», а номера интерфейсов отображаются слева:

localhost(config)#int e1,3,5
localhost(config-if-Et1,3,5)#
localhost(config-if-Et1,3,5)#load-interval 10

Или можно посмотреть утилизацию интерфейсов и группы интерфейсов:

localhost#sh int e3,e48 | i rate
  10 seconds input rate 5.26 Gbps (53.3% with framing overhead), 433507 packets/sec
  10 seconds output rate 12.2 Mbps (0.2% with framing overhead), 21824 packets/sec
  10 seconds input rate 12.2 Mbps (0.2% with framing overhead), 21826 packets/sec
  10 seconds output rate 5.26 Gbps (53.3% with framing overhead), 433546 packets/sec

И совершенно не нужно курсором выделять по 3 знака в скорости порта, чтобы понять, с мегабитами или гигабитами мы имеем дело. Но и это не все. EOS отображает утилизацию интерфейса в %.

А еще в EOS можно делать множественные пайпы и использовать программы GNU/Linux:

sho run | grep X | grep -v Y | more

Не нужно в режиме конфигурации перед командой добавлять «do».

Можно посмотреть diff активной и сохраненной конфигурации:

localhost#sh run diffs 
--- flash:/startup-config
+++ system:/running-config
@@ -190,9 +190,10 @@
 !
 interface Loopback0
    ipv6 enable
+   ipv6 address 2001:db8:ffff::ffff/128
    ipv6 address 2001:db8::1/128
    ip address 10.10.10.1/32
-   ip address 10.255.255.1/32 secondary
+   ipv6 ospf priority 20
    ipv6 ospf 1 area 0.0.0.0
 !
 interface Management1
@@ -200,7 +201,6 @@
 !
 interface Vlan10
    description test
-   shutdown
    mtu 9000
    ip address 10.1.1.1/24
 !

Можно выйти в bash и осмотреться:

localhost#bash

Arista Networks EOS shell

[admin@localhost ~]$ ls /
bin   dev  export  lib    mnt      opt      proc  sbin     srv  tmp  var
boot  etc  home    media  monitor  persist  root  selinux  sys  usr
[admin@localhost ~]$ sudo -s
bash-4.1# cat /proc/cpuinfo | grep name
model name: AMD Turion(tm) II Neo N41H Dual-Core Processor
model name: AMD Turion(tm) II Neo N41H Dual-Core Processor

Все ACL задаются именами. Не нужно помнить и путаться в номерах. Для приверженцев старого подхода есть возможность в качестве имен использовать цифры.

И так далее и тому подобное. CLI в EOS не просто копия, это самодостаточная оболочка с удобными возможностями и далеко ушедшая от прародителя.

Extensible OS

Слово «Extensible» в «Extensible Operating System» по задумке говорит о расширяемости функционала ОС. Достигается это за счет возможности установки своих программ, демонов, скриптов на коммутатор. Можно, например, установить и запустить клиент OpenVPN. Или, запустить скрипт на Python, или, даже ExaBGP. Можно свои поделки подружить с Sysdb, а потом, собрав в RPM пакеты, разнести по сети.

Некоторые другие возможности EOS

  • CloudVision позволяет подключать коммутаторы Arista к XMPP серверу в роли клиентов. В «чаты» с ними можно писать команды CLI, и свитчи будут отвечать результатами их выполнения. Можно добавить несколько устройств в групповой чат и выполнять команды на всех участниках группы одновременно.
  • Advanced Event Management — это что-то вроде Cisco EEM или Junos Event Scripts: можно запрограммировать действия (команды CLI, выполнение скриптов) на определенные события (например: упал порт). Подробнее на сайте.
  • Event Monitor ведет логирование изменений MAC, ARP и таблицы маршрутизации на встроенной флеш памяти в виде базы SQLite.
  • eAPI (External API) позволяет работать с коммутатором по JSON-RPC: ввод и вывод данных в виде JSON объектов.
  • С помощью Zero Touch Provisioning (ZTP) можно автоматизировать настройку нового коммутатора. Свитч с настройками по умолчанию грузится в режиме ZTP и пытается получить сетевые настройки по DHCP. Используя option bootfile-name, которую тоже можно передать по DHCP, коммутатору можно указать URL для загрузки скрипта (на shell, или, например, на языке встроенного CLI, т.к. он является одним из вариантов shell). Если скрипт скачается успешно, то устройство его выполнит. При этом автоматизация ограничивается, наверное, только фантазией.
  • DirectFlow позволяет задавать правила (такие, как зеркалирование; изменение приоритета, VLAN, SRC/DST и т.д.), применяемые к трафику (на основе, например, SRC/DST (IP, MAC, port) или номера протокола, или номера VLAN и т.д.) из CLI (и eAPI тоже пойдет). С помощью таких правил можно, например, более выборочно зеркалировать трафик для анализа, в отличии от SPAN. Или отправлять на систему очистки только трафик для нужного IP, а не ставить эту систему в разрыв. Подобный функционал обычно описывают как преимущество при переключении коммутаторов в режим OpenFlow. DirectFlow позволяет применять правила в ASIC без OpenFlow.

Aboot

Aboot — это не часть EOS, а загрузчик EOS, что-то вроде Cisco ROMmon.

Хочу о нем рассказать, потому что он очень прост и понятен. Aboot представляет из себя ни что иное, как BusyBox. Все данные, включая образы EOS и логи, хранятся на встроенной флешке. Aboot позволяет получить к ней доступ (а так же доступ к внешним USB накопителям, подключенным к USB портам) и восстановить работоспособность устройства в случае проблем. Вход в Aboot тоже простой: без танцев с бубном, без зажиманий кнопок и посылок странных кодов в консоль — CRTL+C.

Думаю, это поможет представить простоту и возможности Aboot:

Aboot 2.0.5-430838


Press Control-C now to enter Aboot shell
^CWelcome to Aboot.
Aboot# echo $SHELL
/bin/sh
Aboot# 
arp            devmem         initblockdev   overcast-lcd   swiinfo
ash            df             initnetdev     ping           switch_root
autoboot       dirname        insmod         ping6          switchroot
base64         dmesg          iostat         pmap           sync
basename       dosfsck        ip             poweroff       sysinit
blockdev       dropbearmulti  ipcalc         powertop       tail
boardinit      du             kexec          ps             tar
boot           echo           kill           pwd            tee
bootchartd     egrep          ln             readlink       telnet
bunzip2        env            login          realpath       tftp
burnK7         expr           losetup        reboot         time
burnMMX        false          ls             recover        touch
burnP6         fdisk          lsmod          reset          tr
busybox        fgconsole      lspci          rev            traceroute
bzcat          fgrep          lsusb          rm             traceroute6
cat            find           md5sum         rmdir          true
checkpass      flashrom       mdev           rmmod          udhcpc
chgrp          flock          mkdir          route          umount
chmod          free           mkdosfs        rx             uname
chown          fsck.msdos     mkfs.vfat      scp            unxz
chroot         fsck.vfat      mknod          sed            unzip
clear          fullrecover    mktemp         setpci         vi
cmp            grep           modinfo        sh             vmcore-dmesg
cp             gunzip         more           sha1sum        wget
cpio           halt           mount          sleep          which
cut            head           mpstat         smemcap        xz
date           help           mv             ssh            xzcat
dbclient       hexdump        nbd-client     stat           yes
dd             ifconfig       netconf        stty           zcat
devio          init           nvramtool      sum
Aboot# exit
Restarting system.

Даже ipcalc есть для удобства.

Применение

Как было сказано ранее, Arista Networks целится своим оборудованием в ЦОДы и предлагает следующие варианты схем для оптимального использования:
Arista. Знакомство

  • Single-Tier «Spline» — гибрид Leaf («лист») и Spine («корень») — «Spline». Предлагается ставить два резервирующих друг друга коммутатора в центр ряда. Используя, например, коммутаторы типа 7316X, из его 512 портов по 40 Гбит/с можно сделать 2048 портов скорость 10 Гбит/с с помощью специального разветвителя QSFP-SFP+ (переходник с QSFP на 4 SFP+). Из 7250QX-64 получится 256 интерфейсов SFP+ всего в 2 U. Как видно из таблицы характеристик свитчей, коммутация будет без переподписки. Название — чистой воды маркетинг, но при правильном расчете и подходе реализация может быть очень выгодная по цене, простая в построении и обслуживании. Например, раньше для подключения 240 медных портов без резервирования нужно было 5 плат по 48 портов в Cisco Catalyst 6506.
  • Layer 2 / MLAG — уже ставший «классическим» Leaf and Spine, построенный на MLAG (известен и как MC-LAG). MC-LAG — это Multi-Chassis Link Aggregation Group, то есть LAG, построенный от двух устройств (в данном случае коммутаторов) к третьему устройству (коммутатору или серверу), при этом третье устройство считает, что подключено к одному устройству. Таким образом можно обойтись без STP и, что немаловажно, оба канала будут активными (active/active).
  • Layer 3 / ECMP — вариация «классического» Leaf and Spine, но при этом все линки между всеми устройствами на L3 (IPv4 и/или IPv6). Благодаря отсутствию ограничения на более двух устройств в узлах, эта схема обладает лучшей масштабируемостью, чем предыдущая. Все соединения тоже работают в активном режиме, нет STP. Защита от кольцевания трафика осуществляется на основе протоколов маршрутизации. Балансируется трафик с помощью ECMP.

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

Автор: router

Источник


* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js