Cisco ACI: новая модель организации работы для приложений ЦОД

Cisco ACI: новая модель организации работы для приложений ЦОД

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

В этой статье мы поговорим об особенностях и концепции Cisco ACI, рассмотрим основные элементы инфраструктуры, расскажем о растягивании ACI-фабрики и выполним лабораторную работу.

Концепция и особенности Cisco ACI

Как известно, на протяжении многих лет центры обработки данных (ЦОД) являются одним из приоритетных и ключевых направлений деятельности Cisco. Компания уделяла и продолжает уделять особое внимание информационной инфраструктуре ЦОД, представляя новые решения, учитывающие тенденцию циклично меняющегося подхода и растущих требований. Примером тому выступает ориентированная на приложения технология Cisco ACI.

Данная технология была предложена в конце 2013 года, суть ее заключается в обеспечении поддержки сквозной виртуализации с возможностью управления и автоматизации, где логика взаимодействия приложений основывается на настраиваемых политиках. Cisco ACI позволяет полностью автоматизировать развертывание приложений в пределах центра обработки данных. А благодаря сочетанию аппаратных и программных средств можно получить преимущества, которые не дает никакая другая модель.

Основные элементы инфраструктуры Cisco ACI

Контроллер Cisco APIC

Cетевые профили приложений

Коммутационная структура Cisco ACI
Является основным архитектурным элементом. Выступает в качестве единой точки автоматизации и управления матричной структуры Cisco ACI, реализации политик и контроля работоспособности всей системы. Это логическое представление всех элементов приложения и их отношений между собой в структуре коммутации приложения. Обеспечивается благодаря линейке коммутаторов Cisco Nexus серии 9000, которые способны удовлетворить быстро меняющиеся потребности сетей ЦОД и используются как основа транспортной системы.

Кроме того, идея Cisco ACI заключается еще и в том, чтобы предоставить приложениям возможность программировать сеть под себя. Именно для этого создается профиль, в нем указываются необходимые параметры, а затем профиль загружается в контроллер Cisco APIC, который, в свою очередь, программирует коммутаторы Cisco.

Схема работы ACI

Схема работы ACI

Рисунок 1. Схема работы ACI

Как отмечалось ранее, Cisco ACI состоит из коммутаторов линейки Cisco Nexus серии 9000 и аппаратных контроллеров. Сами коммутаторы могут работать в нескольких режимах: стационарном либо в режиме ACI под управлением контроллера.

В режиме ACI (фабрики) контроллер оперирует понятиями приложения. И что это дает? Указав, какие серверы или виртуальные машины относятся к той или иной группе серверов и как эти группы должны взаимодействовать, администратор снимает с себя обязанности, передавая оставшуюся часть задач на откуп контроллеру. Последний, в свою очередь, выполняет динамическое перенаправление трафика на межсетевые экраны и балансировщик нагрузки.

То, чего так давно ждали: растягивание ACI-фабрики

Растягивание ACI-фабрики — это действительно то, чего многие так давно ждали, и сегодня она способна растягиваться на большие расстояния и на несколько дата-центров. Согласитесь, функциональность достаточно востребованная, ведь компании не раз отмечали необходимость разнести узлы архитектуры leaf and spine, участвующие в фабрике на определенное расстояние. Как же все это организуется и работает?

Вначале, как обычно, немного теории. Для простоты понимания растянутую ACI-фабрику необходимо представить как единую структуру, ведь по сути так оно и есть. Основное ее преимущество заключается в переносимости рабочих задач и мобильности виртуальных машин, где растянутая ACI-фабрика ведет себя так же, как и обычная, и полностью поддерживает мобильность виртуальных станций. К примеру, одна платформа VMware vCenter может использоваться всеми площадками растянутой ACI-фабрики, а хосты ESXi обеих площадок управляться одним и тем же решением vCenter и сервером DVS, которые «растянуты» между двумя локациями.

Для наглядности рассмотрим пример использования VMware vMotion растянутой ACI-фабрики между двумя дата-центрами, расположенными на расстоянии 800 км, и попробуем выполнить live migration виртуальных машин.

Графическая топология используемого сценария

Рисунок 2. Графическая топология используемого сценария

Исходные данные или то, что мы имеем в рамках рассматриваемого сценария: два дата-центра, растянутая между ними ACI-фабрика, 8 lifs в каждом дата-центре. ACI-фабрика использует взаимосвязанные лифы. В первом дата-центре расположены две виртуальные машины, которые находятся на одном ESX-хосте.

Для просмотра имеющейся топологии, что озвучивалась выше в сценарии, обратимся к веб-консоли Cisco APIC и перейдем в закладку «Топологии» (Topology).

Топология сценария в консоли Cisco APIC

Рисунок 3. Топология сценария в консоли Cisco APIC

Для выполнения live migration обратимся к консоли vSphere Web Client. Как видно на рисунке ниже, две виртуальные машины L-Web-Server1-T4 и L-Web-Server2-T4 расположены на одном и том же хосте.

Обзор виртуальных машин в vSphere Web Client

Рисунок 4. Обзор виртуальных машин в vSphere Web Client

Прежде чем выполнять миграцию, сделаем небольшую проверку: убедимся, что обе виртуальные машины «видят» друг друга и отвечают на запросы при обращении. Логично, что любая проблема с сетевой конфигурацией сделает невозможным выполнение намеченной операции. Для этого подключимся к одной из виртуальных машин, например к L-Web-Server1-T4, и выполним ping второй виртуальной машины. Как видно на рисунке ниже, узел отвечает на запросы, то же самое происходит и со второй машиной.

Проверка connectivity между виртуальными машинами

Рисунок 5. Проверка connectivity между виртуальными машинами

Все, что осталось сделать, — запустить live migration. Для этого переходим в свойства виртуальной машины L-Web-Server2-T4 консоли vSphere Web Client и нажимаем кнопку Migrate.

Запуск live миграции виртуальной машины

Рисунок 6. Запуск live миграции виртуальной машины

Уделим особое внимание второму пункту окна мастера миграции — выбору ресурса назначения, где укажем хост во втором дата-центре.

Выбор ресурса назначения при live миграции

Рисунок 7. Выбор ресурса назначения при live миграции

По завершении live migration виртуальная машина L-Web-Server2-T4 оказывается во втором дата-центре на хосте 1.2.9.21, как видно на картинке ниже.

Результат live миграции виртуальной машины

Рисунок 8. Результат live миграции виртуальной машины

При этом результаты ping показывают, что связь с виртуалками не прерывалась, несмотря на то что они расположены на двух физических серверах различных дата-центров.

Результаты ping при live migration виртуальной машины

Рисунок 9. Результаты ping при live migration виртуальной машины

Заключение

Подводя итог, отметим, что с помощью Cisco ACI можно решать многие задачи, которые сегодня стоят перед различными организациями, а благодаря функции «растягивание фабрики» — получать преимущества в виде переносимости рабочих задач и мобильности виртуальных машин. Все это, безусловно, позволяет сделать бизнес более гибким, удобным и конкурентоспособным.

Технологии, которые вас заинтересовали, вы можете протестировать в центре компетенции ИТ-ГРАД.