Cisco UCS Blade: новый подход к построению дата-центра

    Почти каждый год в мире IT наступает некий новый тренд. Например, в 2007 году это была консолидация данных на СХД, в 2008-2009 – блейд-системы, 2010 год был годом виртуализации, а начиная с 2011 года активно развивается идея консолидации сетей передачи данных. UCS включает в себе все вышеперечисленные возможности, а так же обладает улучшенными функциями отказоустойчивости и масштабируемости.

    Масштабируемость



    Во-первых, давайте рассмотрим архитектуру блейд-систем от Cisco:


    Выделим основные компоненты:
    1) Fabric Interconnect – коммутаторы на основе Nexus 5000 со встроенным функционалом UCS Manager, позволяющим управлять всеми серверами, настройками BIOS, прошивками компонентов, коммутаторами, маршрутизацией, виртуализацией и автоматизацией. Также позволяют работать с Ethernet и SAN сетями и полноценно поддерживают протокол FCoE.

    2) UCS 5108 Blade Chassis – шасси, в которое устанавливаются серверы-лезвия (блейд-серверы). Используется, как централизованная система охлаждения серверов и подвода питания к серверам.

    3) Fabric Extender (FEX) – расширяет Fabric Interconnect в блейд-шасси, прокладывая множественные 10 Гбит/с соединения между блейд-серверами и Fabric Interconnect. Не является коммутатором. Управляется как расширитель к коммутатору Fabric Interconnect. Управляет блоками питания и вентиляторами. Устанавливается в заднюю часть блейд-шасси.


    Исходя из архитектуры, мы можем подключить к одной паре Fabric Interconnect коммутаторов до 40 блейд-шасси, управляя всеми ними из единой точки (UCS Manager). Также нам не требуется докупать отдельные коммутаторы для каждого блейд-шасси, что позволяет экономить при расширении парка блейд-серверов.

    4) Virtual Interface Card (VIC) — специализированные сетевые адаптеры от Cisco. Позволяют пропускать несколько сетевых линков через единый канал связи. При этом обработка всего сетевого трафика производится самим адаптером. Детальная схема отображена на рисунке:


    Каждый адаптер, будь он 10, 20 или 40 Гбит/с, может делиться на 128 виртуальных. В основе технологии лежит стандарт IEEE 802.1bn. Создавая новый сетевой адаптер, можно указать его:
    — скорость, с ходом в 1Мбит/с.
    — приоритетность QoS.
    — тип: Ethernet или FCoE.
    — механизм работы Failover.
    — VLAN/VSAN.

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

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

    Отказоустойчивость


    Для понимания принципов отказоустойчивости Cisco UCS давайте разберем базовую структуру передачи серверного трафика. UCS состоит из блейд-шасси и Fabric Interconnect (FI). Блейд-шасси вмещает в себе блейд-серверы, а FI выполняет коммутацию LAN, SAN и управляет шасси/серверами.


    Цифрой 1 обозначены соединения между FEX и FI, которых может быть от одного до восьми. Каждое соединение имеет скорость 10Гбит/с. Таким образом, к восьми серверам, находящимся внутри каждого шасси, может быть подведено от 20 до 160 Гбит от центральных коммутаторов Fabric Interconnect.

    Соединения можно настроить на работу в режиме EtherChannel или выделить для каждого сервера отдельный интерфейс. В зависимости от типа задачи, в сервер можно установить сетевые адаптеры со скоростями 20, 40 или 80 Гбит/с. В любом случае, при выхождении из строя одного из линков, его трафик будет распределен между соседними линками. Скорость каждого виртуального адаптера может быть ограничена механизмами Quality of Service (QoS) и Enhanced Transmission Selection (ETS).

    UCS имеет уникальную функцию, доступную на некоторых VIC-адаптерах, позволяющую определить вышедший из строя участок сети и выполнить “failover” на соседний Fabric Interconnect. Некоторые mezzanine карты (VIC) имеют встроенный мини-свитч, позволяющий переключить передачу с пути A на путь B и обратно. Схематически это изображено на рисунке:


    Аппаратный UCS failover предоставляет лучшую отказоустойчивость, чем традиционный NIC-teaming, благодаря интеллектуальной системе переключения, встроенной в FI. На картинке выше HW Failover определяет: поломку в шасси, в FEX или интерфейсе сетевого адаптера. В дополнении ко всему, если FI теряет внешнее подключение к LAN сети, он отправит сообщение VIC-адаптеру и позволит выполнить переключение на резервный путь. На картинке любой сбой в местах, обозначенных X, приведет к переключению Ethernet-трафика на путь B. Аппаратный UCS failover применяется только для сетей Ethernet, так как SAN-сети обладают собственным механизмом failover, благодаря механизму multipath.



    МУК-Сервис — все виды ИТ ремонта: гарантийный, не гарантийный ремонт, продажа запасных частей, контрактное обслуживание
    МУК
    65,00
    Компания
    Поделиться публикацией

    Комментарии 14

      0
      Читая этот топик понял, что треть приводимых терминов мне вовсе не знакома (и все это о новом тренде 2012!!). Понимаю, что это несколько специализированная область, но хотелось бы иметь об этом представление на уровне терминологии, прошу подкинуть свеженьких, годных ссылок на описание приводимых в статье технологий и решений.
        0
        blog.ioshints.info/
        У него сейчас «месячник облаков», там ОЧЕНЬ много информации по перспективным сетевым технологиям, связанным с виртуализацией. Плюс вебинары.
        И да, за последний год появилось крайне много всего нового в этой области.
          0
          Пояснение основных терминов, которые не были детально описаны в статье:
          — в 2007 году это была консолидация данных на СХД:
          Переход от хранения данных на каждом сервере отдельно, к хранению данных на общем хранилище.
          СХД — система хранения данных

          — в 2008-2009 – блейд-системы:
          Переход от использования Rack-серверов к использованию Blade-серверов. Тем самым уменьшая занимаемую серверами площадь, потребление электроэнергии и другие полезные стороны использования Blade.

          — 2010 год был годом виртуализации:
          Взрыв популярности компании VMWare. Массовые внедрения виртуализации серверов и рабочих станций. Появление Hyper-V от Microsoft.

          — консолидация сетей передачи данных:
          Передача данных Ethernet и Fibre Channel по единому кабелю. Появление FCoE, Converged адаптеров и других компонентов объединения сетей.

          Еще одним трендом в 2011 году были облака.
          Облачные (рассеяные) вычисления (англ. cloud computing, также используется термин Облачная (рассеянная) обработка данных) — технология обработки данных, в которой компьютерные ресурсы и мощности предоставляются пользователю как Интернет-сервис. Пользователь имеет доступ к собственным данным, но не может управлять и не должен заботиться об инфраструктуре, операционной системе и собственно программном обеспечении, с которым он работает. Термин «Облако» используется как метафора, основанная на изображении Интернета на диаграмме компьютерной сети, или как образ сложной инфраструктуры, за которой скрываются все технические детали. Согласно документу IEEE, опубликованному в 2008 году, «Облачная обработка данных — это парадигма, в рамках которой информация постоянно хранится на серверах в интернет и временно кэшируется на клиентской стороне, например, на персональных компьютерах, игровых приставках, ноутбуках, смартфонах и т. д.».

          Если еще что-то непонятно — спрашивайте.
            0
            Я не совсем это имел в виду, эти термины общие и широко применяемые, я видимо не совсем правильно выразился, в тексте встречаются предложения навроде: «Fabric Extender (FEX) – расширяет Fabric Interconnect в блейд-шасси», «Соединения можно настроить на работу в режиме EtherChannel или выделить для каждого сервера отдельный интерфейс», «Некоторые mezzanine карты (VIC)», «тип: Ethernet или FCoE.», «доступную на некоторых VIC-адаптерах», в пояснительном комментарии " Появление FCoE, Converged адаптеров и других компонентов объединения сетей". Здесь смесь терминов, касающихся железа и технологий, применяемых в больших системах, с которыми не часто удается поработать. Понимаю, что это технологии, и их уместить в термин не просто, поэтому не стал гуглить по отдельности, а попросил накидать актуальных ссылок с обобщением этих технологий:
              +1
              Теперь ясно.

              1) Fabric Extender (FEX) просто добавляет порты в Fabric Interconnect(FI)-коммутатор. То есть это карта расширения для FI, которая соединяет его с блейд-серверами. При этом FEX не выполняет никакой коммутации, а просто передает трафик в FI. Всей коммутацией занимается FI.

              2) EtherChannel — технология, позволяющая объединить несколько физических линий передачи данных в единую логическую линию. Позволяет увеличить пропускную способность соединения, а так же увеличивает отказоустойчивость. При выходе из строя одного из физических соединений, логическое соединение продолжает работать, просто с уменьшеной скоростью.

              3) Mezzanine — общее название карт расширения для блейд-систем. Аналогия в обычных серверах — PCI-карты. Тоесть Mezzanine VIC — это все равно что PCI-адаптер VIC. Его описание можете прочитать в пункте 4 статьи.

              4) Ethernet — среда передачи IP-трафика.
              FCoE и FC — среды для передачи блочных данных. Применяются подключения систем хранения данных. Имеют значительно уменьшенные задержки в передаче пакетов, по сравнению с Ethernet, а так же характерны безпотерьной передачей данных.

              5) Converged-адаптеры — адаптеры, позволяющие работать с унифицированными средами передачи данных. То есть с теми, по которым сразу можно передавать и Ethernet и FC-трафик.
              0
              возможно я Вас удивлю, но блейды широко использовались намного раньше 2008. СХД намного раньше 2007, а виртуализация начала серьезно набирать популярность с ESX3.0, что никак не 2010.

              Hyper-V у нас внедряли (впрочем это был полнейший провал) еще в 2008.

              А облака, по настоящему, начинают раскручиваться как раз сейчас, когда народ начал понемногу понимать что это вообще такое, и начал отличать маркетинговый bs от конкретных предлагаемых технологий.
                0
                Конечно же Вы правы.
                В данной статье подразумевается популяризация и повсеместное внедрение не только зарубежом, но и в СНГ.
                  0
                  ну разве что если _только_ в СНГ, и то я немного сомневаюсь в том что СНГ настолько позади всей остальной планеты
            0
            Тренды последних лет очень забавны.
            Элементы резервирования, о которых вы рассказываете в том или ином виде уже давно существует у производителей которые занимаются производством серверов чуть дольше чем Cisco.
            Чего стоят разработки Tandem, которую в свое время купил HP и теперь на этих технологиях строится серия Integrity.
            Вот технология резервирования сетевых интерфейсов, которой около 10 лет.
            ftp.hp.com/pub/nonstop/ccc/feb0410.pdf — объясните чем вы лучше.

            У NEC серия FT www.nec-itplatform.com/IMG/pdf/ftseries-jp.pdf — тут вообще софт не заметит что процессор вылетел… Впрочем как и на НонСтопах.

            DELL — не работал с ними, но тут недавно пост был.

            Расскажите пожалуйста в сравнении чем вы лучше. И какие у этого решения конкурентные преимущества.
            По мне это выглядит как все яйца в одну корзину.
              0
              Strib, спасибо за вопрос.

              На сколько я понял, технология, которую Вы привели от HP, работает только на линейке серверов HP Non-stop. Это системы на EPIC-процессорах Intel Itanium, не являющейся x86-архитектурой, и просто не сможет выполнять большинство задач, решаемых Intel Xeon-процессорами. У них другое предназначение и другие сферы применения.

              По поводу NEC. Действительно у NEC есть 2 сервера, на устаревших процессорах X5600-серии:
              www.nec.com/en/global/prod/express/fault_tolerant/index.html
              Технология очень интересная, правда NEC не выкладывает характеристики их производительности на spec.org, что заставляет задуматься о производительности такой системы. К тому же, если бы технология от NEC была бы действительно популярной, то они бы не делали настолько маленький модельный ряд Fault Tolerant серверов.

              Я же пытался показать особенности сетевой интеграции блейд-систем от Cisco, ибо она в корни отличается от всех существующих решений. Легкость в масштабируемости, благодаря центральным коммутаторам Fabric Interconnect. Легкость создания и изменения сетевых интерфейсов на Blade-серверах. Такой масштабируемой и гибкой схемы, пока что, нет ни у одного из конкурирующих Blade-решений.

              Кстати, в скором времени я планирую выпуск следующей статьи посвященной углубленным аспектам отказоустойчивости Blade-систем от Cisco.
              0
              А можно для виртуальной машины зарезервировать пропускную способность дисковой подсистемы?
                0
                В принципе, все зависит от настроек.
                Если подключать к каждой виртуальной машине свой LUN (раздел на системе хранения данных), то можно выдать чёткую пропускную способность.
                А вот если делать общий раздел для гипервизора и на нем создавать файлы виртуальных машин, то выделить какую-то одну виртуальную машину не получится.

                Все очень зависит от системы виртуализации и способа подключения.
                0
                В принципе, все зависит от настроек.
                Если подключать к каждой виртуальной машине свой LUN (раздел на системе хранения данных), то можно выдать чёткую пропускную способность.
                А вот если делать общий раздел для гипервизора и на нем создавать файлы виртуальных машин, то выделить какую-то одну виртуальную машину не получится.

                Все очень зависит от системы виртуализации и способа подключения.
                  0
                  Как раз заканчиваю писать интеграцию vmfex с нашим продуктом, так что я немного в теме.

                  Вы забыли упомянуть о том что FEX для виртуальных машин возможен только при покупке Palo, а это не стандартная комплектация, хоть и самая распространенная.

                  Еще было бы интересно почитать о плюсах и минусах подхода 802.1Qbh по сравнению с VEPA и вообще с использованием SRIOV

                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                  Самое читаемое