Cumulus Linux для сети в датацентре

    Современный датацентр заметно отличается от традиционной корпоративной сети. Приложения больше ориентируются на L3 коммутацию вместо предположения, что все соединения находятся в одной подсети, больше траффика идет «горизонтально» нежели «вертикально» и т.д. Несомненно, главное отличие — гигантский масштаб.

    Благодаря виртуализации, количество сетевых соединений в датацентре исчисляется от десятков тысяч до миллионов, тогда как в старые добрые времена их было всего несколько тысяч. Масштаб виртуальных сетей давно вышел за возможности традиционных VLAN сетей, скорость переконфигурирования также возросла на порядки. Кроме того, количество серверов в современном ЦоД таково, что сетевого оборудования необходимо на голову больше, чем в традицонной корпоративной сети.

    Эволюция сетевой инфраструктуры шла своим чередом, от монолитных псевдо-ОС через встраиваемые ОС типа QNX и VxWorks до современной стадии, когда ОС делается на основе Linux или BSD, иногда такой образ запускается в виртуальной машине обычного Linux дистрибутива. С другой стороны, способ управления эволюционировать отказывался, это по-прежнему командная строка с многоуровневой структурой. Сложностей добавляет еще и различный синтаксис у разных производителей, а часто и у одного в разных моделях.

    Подытоживая — проблема лежит не в железе, а в сетевых ОС. Подходы к решению разделились, первый путь ушел к northbound и southbound API подходу (наибольшую популярность приобрел OpenFlow), второй — использовать Linux и его экосистему. Другими словами, первый вариант пытается добавить продвинутый API управления к существующим ОС, второй предлагает переключиться на ОС, которая уже обладает всеми необходимыми характеристиками.

    В предыдущем материале мы рассказали о коммутаторах без предустановленной ОС
    и средой для развертывания ONIE.

    Самое время рассказать про одного из представителей второго подхода, который можно установить на наши платформы — Cumulus Linux.





    Cumulus Linux не просто основан на Linux, как многие, это и есть Linux, поэтому работа с ним практически не отличается от обычного
    Linux сервера. Совершенно стандартные приложения устанавливаются прямо на коммутатор, при необходимости новые утилиты разрабатываются
    без ориентации на специфичные API, привычный инструментарий работы с сетью дополнен средствами построения CLOS фабрик и автоматизации.


    Архитектура

    Установка и мониторинг

    Как это выглядит в развертывании? Всем привычен подход «загрузка по PXE, развертывание образа ОС», здесь аналогично.


    Привычный подход

    1. Первая загрузка идет в ONIE, запускается процесс поиска источника образа ОС, в нем определяется нужный образ и развертывается на коммутатор.


      Подготовка
    2. Первая загрузка в Cumulus Linux, определяется наличие скриптов настройки через опцию 239 DHCP. Если в ответ получается URL адрес, то
      по нему запрашивается скрипт, в нем разыскивается CUMULUS-AUTOPROVISIONING и скрипт запускается от root. Поддерживаются Bash, Ruby, Perl, Python.


      Поиск скрипта
    3. Третий шаг — нормальная загрузка в Cumulus Linux



    Рабочий режим

    Первая настройка завершена, прекрасно. Что дальше?

    А дальше можно пользоваться все теми же инструментами, что и для серверов.


    Оркестровка

    Помимо существующих инструментов, можно интегрировать любые разработки, которые уже используются в компании.

    Мониторинг? Ganglia, Graphite, collectd, net-SNMP, Icinga — установите на коммутатор и собирайте данные в реальном времени.

    Прелести автоматизации

    Linux не только обладает отличными возможностями по управлению и понятными API, но и прекрасно подходит к сетевой модели современного ЦоД. Уровень управления находится в пространстве пользователя и отделен от уровня обработки пакетов в ядре. FIB (Forwarding Information Base) находится в ядре, RIB (Routing Information Base) управляется из пользовательской среды соответствующими демонами, поддерживаются основные возможности сетевого оборудования и ряд продвинутых функций, связанных с BGP. Текущий инструментарий позволяет прямо обращаться к интерфейсам, таблицам маршрутизации, есть механизмы уведомлений об изменениях и т.д.

    Такая база позволяет использовать родную консоль Linux, вместо специализированных оболочек JunOS, NX-OS и прочих. Консоль по своей природе отлично подходит для использования цепочек независимых команд и применения скриптов.

    И коммутатор отлично автоматизируется!

    1. Управление пакетами и процессами
    2. Шаблоны конфигураций
    3. Автоматизация мониторинга


    Все это помогает настроить L2/L3 и упростить жизнь администратору.

    Еще один удобный инструмент — Prescriptive Topology Manager (PTM). Когда определена логическая топология ЦоД, привести кабельное хозяйство в соответствие — весьма непростая задача, съедающая немало времени и усилий. PTM позволяет проверить правильность подключения кабелей в реальном времени и указать точное место для устранения ошибки. Он использует план разводки кабелей в формате graphviz-DOT (некоторые компании и так пользуются им для создания плана) и сравнивает его информацией, полученной через LLDP, для проверки правильности подсоединения кабелей.


    Проверка топологии


    Сравнение с данными LLDP

    Примеры интеграции

    Программные решения по оверлеям ограничивают возможность контролировать аппаратную сторону сети, не позволяя автоматизировать настройку и управление, а также усложняют отслеживание неполадок. Linux поддерживает VXLAN, поэтому не составит проблемы разработать агенты для различных решений по виртуализации сети. Cumulus Linux может работать как аппаратный портал L2, позволяя обойти ограничения программных решений и сохранить высокую производительность коммутации (VXLAN tunnel endpoint (VTEP) обрабатывается на скорости канала) при использовании всех преимуществ технологии VXLAN.

    Разработаны агенты для решений PLUMgrid, Nuage Networks, Midokura, VMware NSX.


    Интеграция с VMware


    Интеграция с Midokura

    Архитектуры сети


    Традиционная сеть

    Традиционная архитектура сети включает уровни ядра, агрегации и доступа. Три уровня — выше задержки и имеется ряд наследственных ограничений. Такие решения не подходят для современного ЦоД с высокой плотностью серверов и значительным межсерверным трафиком. Используются протоколы STP/RSTP/PVSTP, VTP, HSRP, MLAG, LACP. В общем, «нас так учили».

    1. Ориентация на L2.
    2. Статична по природе — VLAN, плохо масштабируется при виртуализации.
    3. Опирается на костыли — MLAG, Trill и т.д.
    4. Оптимизация для трафика «север-юг».
    5. Низкая масштабируемость — сотни или тысячи соединений.



    Современная сеть

    1. Она проще.
    2. Меньше проприетарных протоколов.
    3. Предсказуемые задержки.
    4. Горизонтальная масштабируемость.
    5. Ориентация на L3.
    6. Отлично подходит для виртуализации и облачных сред с множеством «владельцев».
    7. Масштабируемость до миллионов соединений.


    Слабые места

    Не бывает идеальных вариантов, в силу ориентации на L3 среду, у Cumulus Linux есть несколько слабых мест.

    1. Желание построить L2 фабрику с использованием MLAG, TRILL, Virtual Chassis, VLT, Chassis Stacking, и т.д.
    2. Работа с Netflow
    3. Коммутаторы доступа провайдеров с VRF, MPLS, VPLS и т.д.
    4. QinQ
    5. Коммутаторы доступа с Port Security, сложными QoS правилами, 802.1x, PoE
    6. Протоколы маршрутизации IS-IS, RIP, EIGRP.
    7. Авторизация по TACAS или Radius AAA (есть альтернатива LDAP).


    Все, что связано с традиционным подходом к построению сети и провайдеры плохо совместимы методами для построения
    сети в современном датацентре.

    Подведение итогов.

    Отвязка аппаратной коммутатора от операционной системы позволяет сделать следующий шаг к программно-конфигурируемому ЦоД. Возможность выбора ОС позволяет ориентироваться на те возможности, которые необходимы и выбирать из нескольких доступных вариантов оптимальный.

    Система становится гораздо прозрачней, все можно проверить с помощью встроенных инструментов Linux без привязки к специфичным командам вендоров. Также становится возможным работать с роутером как с сервером, у которого множество сетевых портов, совсем как в начале становления сетевого оборудования, UNIX сервер с несколькими портами. Только в современном случае все сетевые операции осуществляются с помощью ASIC, а серверная часть осуществляет только управление.

    Как обычно, у нас доступна лаборатория с Cumlus Linux на коммутаторе Eos 220 для бесчеловечных экспериментов и препарирования.

    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 25

      +3
      >Современный датацентр заметно отличается от традиционной корпоративной сети. Приложения больше ориентируются на L3 коммутацию вместо предположения, что все соединения находятся в одной подсети, больше траффика идет «горизонтально» нежели «вертикально» и т.д. Несомненно, главное отличие — гигантский масштаб.
      Я бы не стал обобщать. «Датацентр» — очень растяжимое понятие.

      >Традиционная архитектура сети включает уровни ядра, агрегации и доступа.
      Может, не надо насиловать труп? Никто уже много лет не строит сети ЦОДов по трехуровневой модели, и никто давно уже не предлагает строить сети таким образом. Эта концепция умерла еще до моды на collapsed core.

      Ориентация на L3 — это хорошо, но мало кому доступно (не забывайте, что требования диктуются приложениями, и не все они поддаются модификации — где-то для простейшего резервирования active/standby без потребности в масштабировании проще всего задействовать VRRP, где-то нужен конкретно L2 мультикаст). Потому есть компромиссный вариант — те самые костыли, которые позволяют организовать CLOS фабрику с транспортом L2. У нее все те же преимущества, что и у вашей «современной сети», за исключением п.5 («Ориентация на L3») и п.2 («Меньше проприетарных протоколов», ибо TRILL существует только в powerpoint).

      В недостатках вашего решения упоминается «сложными QoS правилами». Что имеется в виду? DCB к примеру есть? Какой вообще функционал поддерживается или не поддерживается?
      Что не так с netflow? Ему на L3 самое место.
        0
        Про QoS хороший вопрос.
        Когда то заинтересовался этим решением, стал копать, что же у них интегрировано в Линукс. Предполагая их подход, что вы можете пользоваться стандартными утилитами Линукс (а мы уже далее позаботимся о том, чтобы переложить это на язык железа), выяснилось, что с QoS пока (дело было 3-4 месяца назад) плохо. Доступ к документации я не получил, но ответ был такой — QoS есть в железе, можете пользоваться специальным CLI, интеграции с Линукс нет. И мне показалось, что подтекст был такой, что в ДЦ QoS не шибко актуальная тема, проще BW увеличить, чем с QoS морочится.
          +1
          Это в целом так, гораздо проще контролировать QoS в его обычном понимании на эндпойнтах. Тут приведен живой пример, когда TE, то есть форвардинг/маршрутизация, и QoS неразрывно переплетены, при этом классический контроль на эндпойнтах никуда не пропадает.
            +1
            >гораздо проще контролировать QoS в его обычном понимании на эндпойнтах
            Нет, контролировать его на ендпоинтах в общем случае просто невозможно. QoS — это традиционно превращение хаотичной потери пакетов на линках в избирательную. Ендпоинт не может дропать чужие пакеты. И свитч должен принимать решения самостоятельно — он не успеет никого спросить, что делать с пакетами.

            >И мне показалось, что подтекст был такой, что в ДЦ QoS не шибко актуальная тема, проще BW увеличить
            Очень даже актуальная. Самый жесткий пример — если вы строите FCoE, то вам нужно обеспечить 0 потерь. Как механизмами безусловной приоритезации, так и сигнализацией отправителю о перегрузках.
              0
              В теории много чего актуально.
              На практике, проще и эффективнее, и дешевле (если посчитать OPEX и CAPEX) пропускную способность увеличить.
                0
                А где конкретно экономия? Я вижу только один фактор — можно набрать более глупых людей, не умеющих делать QoS на свитчах. В остальном экономии как бы и нет. Сопровождать это, если не переборщить с числом классов, особо не требуется. Настроил и забыл. В капексе тем более как-то разницы нет, уж базовый функционал есть на всем железе.

                BW обычно следует увеличивать не горизонтально, а вертикально, иначе все равно кто-то будет упираться в емкость отдельных каналов. Т.е. 1G => 10G => 40G. Каждый переход обычно стоит приличных денег.

                А дальше у вас есть канал до другого датацентра. Как правило — либо темное волокно, либо, что хуже, провайдерский канал. И тут уж по-любому надо озаботиться приоритезацией, потому что эта емкость стоит чертовски дорого.

                Ну и удачи пускать FCoE без QoS. Один единственный потерянный пакет — и обмен с массивами в лучшем случае надолго замирает. Не уверен, что оно вообще захочет работать без DCBX.

                А еще представьте себе, что сотни мегабит голосового трафика будут гоняться по тем же линкам, по которым бегают сотни TCP соединений. В среднем за полминуты утилизация линка может быть несерьезные 20% к примеру. Но если собрать и проанализировать дамп пакетов, или просто проверить счетчики дропов на интерфейсах… Теряться-то может как трафик между абонентами, так и SPAN трафик. Потеря второго как правило хуже, так как если слова выпали из разговора, то никто никого не переспросит, и у вас будет несколько косячная запись.

                В общем, да, широкие каналы — это круто, но и на них надо бы приоритезацию организовывать. Это вовсе не дорого и не сложно.
                  0
                  Про настроил и забыл это только мечтать. Равно как и о том, чтобы один раз задокументировать классы и т.п., и далее строго их использовать. Люди это основная статья расходов. Нанимать команду высококлассных специалистов никто не будет, всегда будут инженеры средней руки, которые берут на себя большую часть рутины.
                  И как быть в гетерогенных сетях? Вроде бы у всех вендоров QoS одинаковый, но чуть глубже и начинается интересно. А как быть с простым железом на доступе? Там КоС сделан как китайский Бог на душу положит.

                  Запускал пару проектов с узлами во всех федеральных округах. Каналы надо было по 3-5 Мбит/с. Разбирательства с качеством там такая песня была. И это не какой-то один провайдер — за несколько месяцев пилотных тестов перепробовали всех, что смогли, ± у всех одинаково. В проекте ставили оборудование спец., которое требовало каналы с % потерь не более 0.5. Итог: арендовали полосу в 2.5 раза больше, на оборудовании включили режим дублирования (каждый пакет передается в 2-х экземплярах).

                  А голос, ну вот Skype, Viber, Google Talks, Facetime как то нормально уживаются. Все пользуются и нормально, бывает проблемки, но и в традиционной TDM телефонии такое бывало.
                    0
                    >Нанимать команду высококлассных специалистов никто не будет
                    Никто? Никто-никто? Точно?
                    Впрочем, достаточно одного грамотного архитектора и толпы макак, работающих строго по инструкции. Для сопровождения QoS само собой.

                    >Вроде бы у всех вендоров QoS одинаковый
                    Откуда такая глупость? QoS может быть совершенно разным даже в разных моделях одной линейки железа одного вендора. Ну что же, я полагаю, «средней руки инженер» должен уметь читать. Или не должен?

                    >Разбирательства с качеством там такая песня была
                    У меня много сотен несколькомегабитных каналов связи с участием многих десятков провайдеров. Ну что же — где надо, чтобы качественно, там L3VPN (в случае потерь заебем провайдера насмерть, и он устранит потери, проверено). Где только интернет — полоса постоянно мониторится, при проблемах трафик автоматически за секунды переключается на резерв (нет, мониторинг куда серьезнее, чем средствами кипалайвов IGP — на важных каналах любого рода он тоже работает). Вот жду выхода через несколько месяцев NG-PFR, он многое упростит, там обещают фейловер при brownout за 2 секунды, а мониторинг организован в первую очередь наблюдением за data plane TCP трафиком, а кипалайвы пускают только когда трафика нет. Текущая версия PfR на мой взгляд непригодна к использованию в продакшне.

                    Для справки, катастрофическим уровнем потерь я считаю где-то 0,2%. То, что выше, очень сильно бьет по TCP.

                    >А голос, ну вот Skype, Viber, Google Talks, Facetime как то нормально уживаются.
                    Корпоративный голос — это обычно RTP пакеты, а сигнализация — SIP/H.323/SCCP. Скайпы-фейстаймы — фигня. Не фигня — обеспечить качественную передачу тысяч одновременных голосовых соединений как между оператором и клиентом, так и до систем звукозаписи, данные с которых потом и в суде могут слушаться.

                    Но опять же, вопрос в масштабах и требованиях к качеству сервиса.
                      0
                      > Никто? Никто-никто? Точно?
                      Кто-то конечно так делает, но в среднем такого нет.

                      > достаточно одного грамотного архитектора и толпы макак
                      и 95% времени грамотный архитектор смотрит, чтобы макаки делали по инструкции, а не так как им кажется или разбирается в косяках или думает, как сделать так, чтобы макаки накосячить не смогли в принципе.

                      > в случае потерь заебем провайдера насмерть, и он устранит потери, проверено
                      Если не возражаете, то я спрошу у вас совета, как этого добиться. Это не сарказм =)
                      Кстати, 0,2% за какой период? Как часто бывает больше 0.2%? Что делаете, если нарушают? Насколько для вас это критично?

                      За большой голос ничего не скажу, опыта такого не имею.
                      Но инсталляций до 100 устройств видел полностью работающих через инет не мало, и сделаны на всем подряд SIP/H.323/SCCP + Скайп. И нормально, а по деньгам красотища.
                        0
                        >и 95% времени грамотный архитектор смотрит, чтобы макаки делали по инструкции
                        Архитектор не смотрит, как они работают. Если они не способны изучить готовые сжатые инструкции по конфигурации QoS конкретно в их инфраструктуре, то это — профнепригодность. И кстати пары инженеров может быть достаточно для поддержки сети на много сотен устройств… Можно «один умный, другой глупый» (но тогда страшно в отпуск человека отпускать), можно «все умные» (оптимально).

                        >Если не возражаете, то я спрошу у вас совета, как этого добиться.
                        Цепочка эскалации от сервис-менеджера до директора департамента и выше.

                        >Кстати, 0,2% за какой период?
                        Зависит от лени и важности канала. Обычно минуты или часы.

                        >Что делаете, если нарушают?
                        Заявка, пинок менеджеру, дальше по обстоятельствам.

                        >Насколько для вас это критично?
                        Зависит от канала. Где-то проблемой считается 0.2% потерь в течение нескольких секунд — на такое заводятся заявки. Если речь идет о минутах, то тут уже звонок менеджеру.

                        >И нормально, а по деньгам красотища.
                        А как вы мониторите качество сервиса? Мы например в реальном времени отслеживаем RTCP с аппаратов (рядом с моим рабочим местом на мониторах даже красивые графики непрерывно рисуются, обычно полностью зеленые, но при дропах сразу начинающие краснеть), IP SLA и ряд других метрик. А вам известно, насколько качественно работает у вас телефония? Или вы по отзывам пользователей оцениваете сервис? :)
          0
          >Я бы не стал обобщать. «Датацентр» — очень растяжимое понятие.
          Да, можно уточнить, что это под крупные инсталляции одного эксплуатанта. В мире это обобщается в datacenter customer, без деления на подвиды. Крупнейшая инсталляция на текущий момент — свыше 10К коммутаторов у одной компании.

          >никто давно уже не предлагает строить сети таким образом.
          Cisco Virtualized Multi-Tenant Data Center Design Guide Version 2.2, last Updated: March 6, 2013. Труп подозрительно жив и бодр.

          Ориентация на L3 как раз и предназначена для построения свежих решений, наследственные приложения так и обозначены — слабые места.
          Варианты со стекированием, MLAG и прочее как раз добавляют проблем, от которых и предлагается избавиться. Не хотите избавляться — вас же не заставляют :)

          Что работает — есть в даташите.
            0
            >это под крупные инсталляции одного эксплуатанта
            Да и тут тоже не факт, что сказанное вами про, например, преимущественно горизонтальный трафик верно.

            >Cisco Virtualized Multi-Tenant Data Center Design Guide Version 2.2, last Updated: March 6, 2013.
            Выпущено много лет назад. «Updated» может подразумевать «исправлена очепятка».

            Почитайте Virtualized Multiservice Data Center (VMDC) 3.0, существовавший как минимум в декабре 2012.

            Кстати, «multi-tenant» подразумевает подавляющее превосходство вертикального трафика.

            >Не хотите избавляться — вас же не заставляют
            Хотим, но не можем. И мало кто может.
              0
              >VMDC 3.0
              Тоже отлично предлагает три уровня. Скромно упоминает о двухуровневой топологии.

              >Хотим, но не можем. И мало кто может.
              В какой-то момент проще сменить платформу.
                0
                >Тоже отлично предлагает три уровня.
                www.cisco.com/c/en/us/td/docs/solutions/Enterprise/Data_Center/VMDC/3-0/DG/VMDC_3-0_DG.pdf
                Не сказал бы.
                CLOS, кстати, ничем особо не отличается от collapsed core помимо наличия N ядер, где N может быть >2.

                >В какой-то момент проще сменить платформу.
                Платформу? Но корпоративный ЦОД может иметь много сотен разнообразных платформ и приложений. Вы не зацикливайтесь на единичных интернет-компаниях, их мало, и у них, кстати, тоже есть внутренняя инфраструктура с не самыми гибкими сервисами, будь то SAP, ораклиные базы, FC или FCoE хранилища и так далее.
                  0
                  Базовая архитектура в документе — три уровня.

                  Если вы не можете сменить платформу — значит это решение не подходит.
                    0
                    Чем картинки 2-3 и 2-4 отличаются от идеализируемых вами?

                    Или вы про сервисный уровень? А в предложенной вами архитектуре балансировщики, файрволы и т.д. будут работать на уровне leaf, или, и того хуже, spine?

                    И почему на вашей картинке тоже три уровня — core, leaf и spine? Непорядок…
                      0
                      2-3 не отличается, 2-4 добавляет еще один уровень Aggregation-Edge.

                      Балансировщики и прочее работают на нодах, нет необходимости ставить «аппаратный».

                      Разница на нашем варианте и Циски (за исключением 2-3) простая — у них весь spine уровень подключен к следующему.
                      В 2-3 и нашей картинке выход в сеть подключен отдельно.
                        0
                        >В 2-3 и нашей картинке выход в сеть подключен отдельно.
                        Мне лень рисовать, так что попробуем словами.

                        Возьмите картинку. Переместите две левые leaf ноды наверх (не меняя соединений между узлами). Опаньки, у вас на картинке четко прорисовался тот же самый aggregation-edge! И даже есть еще один, четвертый уровень! А как же предсказуемые задержки? Почему так много уровней? Непорядок…
          0
          А у вас случаем нет возможности получить в лабу Pluribus? Среди всех модных стартапов сетевых — это мой фаворит.
          Интересно, посмотреть реальные возможности.
            0
            Они направлены на работу с конечниками, по нашему профилю негде кооперироваться.
            –1
            Я мало что понял, но ты достучался до моего сердца!
              0
              Хм… А чем современная модель проще? Гибче, я еще могу понять…
                0
                Меньше уровней, предсказуемые задержки.
                  0
                  Про какого уровня задержки мы говорим? :)

                  Кстати. Раз уж пиарите Eos 220. Какая у него латентность из порта в порт? Какова архитектура портовых буферов и какой у них размер?
                    0
                    В зависимости от коммутаторов ;)
                    На всех наших моделях есть switching latency в спеке, даже модель матрицы указана (вот почему хорошо использовать merchant silicon).
                    В основном Broadcom, одна модель на Intel. У них всех даташиты выложены.

              Only users with full accounts can post comments. Log in, please.