Обзор ориентированной на приложения инфраструктуры Cisco

Введение

Несколько недель назад я начал новый путь в своей карьере. Сейчас я работаю в Cisco в качестве евангелиста технологий. В частности, я концентрируюсь на инфраструктуре, ориентированной на приложения (ACI), и коммутаторах серии Nexus 9000. Поскольку программно определяемые сети становятся все более популярными и даже необходимыми, я буду писать о своем путешествии по изучению ACI и других решений.

ACI меняет наше традиционное представление о сети. Традиционная сеть использует императивную модель, которая в основном означает, что мы контролируем то, что делают сетевые устройства. Мы даем им команды и ожидаем, что они будут следовать им, как «написано». ACI использует декларативную систему управления, в которой мы указываем, каким должен быть конечный результат, а сетевые устройства интерпретируют его и делают то, что им нужно, чтобы вернуть этот результат. Это подводит нас к теории обещаний, на которой основан ACI, но мы оставим ее для другой статьи.

Структура позвоночника и листа

ACI построен на Closnetwork. Существуют узлы позвоночника и конечные узлы, как показано на рисунке ниже. Каждый лист соединен с шипами в виде сетки. Этот дизайн учитывает увеличение трафика Восток-Запад в большинстве современных центров обработки данных из-за увеличения количества виртуальных серверов поверх физических хостов.

Рисунок 1: Взято с сайта cisco.com

Между магистральными и конечными устройствами находится IP-сеть (уровень 3), которая использует оптимизированный протокол маршрутизации IS-IS, начиная с первого выпуска. Другие протоколы маршрутизации могут быть добавлены в будущих выпусках, но это не то, с чем администратору действительно нужно будет что-то делать, поскольку все это происходит за кулисами. Поскольку все это уровень 3, нет необходимости в протоколе связующего дерева, с которым у всех нас были проблемы за последние несколько лет. Хотя STP решает проблемы с широковещательными штормами, он также может замедлять работу сети и требует много времени для правильного планирования. Добавление или удаление сетевых коммутаторов также может создать проблемы с STP. Эти проблемы больше не существуют с ACI.

Хосты или EndPoints всех типов (сетевые устройства, физические серверы, виртуальные серверы и т. д.) затем подключаются к конечным портам, а не к портам ствола. И магистральный, и конечный узлы состоят из коммутаторов Cisco Nexus серии 9000, хотя существуют способы интеграции других коммутаторов Nexus для перехода от вашей текущей сети к этой новой модели ACI.

Контроллер инфраструктуры политик приложений

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

Модель политики

ACI использует модель политики белого списка, что означает, что никакие пакеты не могут передаваться между приложениями до тех пор, пока им не будет специально разрешен доступ. В ACI мы можем настроить группы конечных точек практически для любой конструкции, такой как приложения, группы виртуальных портов, виртуальные локальные сети и т. д. Как правило, мы настраиваем их для соответствия трехуровневой модели приложений, которая используется во многих центрах обработки данных. Трехуровневое приложение обычно представляет собой веб-уровень, уровень приложения и уровень базы данных. У нас может быть много виртуальных машин и физических машин на каждом из этих уровней для каждого приложения. После того, как EPG настроены, мы можем создать политики, позволяющие пропускать между ними определенные виды трафика. Например, если мы хотим разрешить двунаправленный доступ между базой данных и уровнями приложений для определенного трафика, мы можем это сделать, в отличие от списков управления доступом, которые предлагают только однонаправленные разрешения. Конечно, однонаправленный доступ также может быть разрешен.

Рисунок 2: Взято с сайта Cisco.com

Графики обслуживания

Иногда в потоке трафика все еще существует потребность в более традиционном сетевом оборудовании и программном обеспечении. Например, нам могут понадобиться балансировщики нагрузки, брандмауэры или даже какой-то антивирус или другое решение для обеспечения безопасности между нашими уровнями. Используя новый протокол под названием OpFlex (а также пакеты устройств), мы можем воспользоваться преимуществами этой декларативной модели, упомянутой выше, со всеми видами приложений и устройств Cisco и сторонних производителей. Это позволяет очень легко вставлять средства безопасности между уровнями, а также создавать конструкции, которые можно копировать и изменять, что делает автоматизацию еще более возможной.

Сетевой профиль приложения

После того, как мы настроили EPG, политики и графы услуг, мы создаем контракты между уровнями. EPG будут действовать либо как поставщики, либо как потребители этих контрактов, которые по существу связывают политики с уровнями, с которыми они должны быть связаны. Все это объединяется, чтобы стать профилем сети приложений. Этот сетевой профиль приложения может предоставить нам не только многоуровневую защиту, но и многократно используемые конструкции, которые администраторы могут применять в любом месте сети.

Рис. 3. Взято с сайта Cisco.com.

Арендаторы

Чтобы обеспечить еще большую микросегментацию в рамках модели ACI, мы можем назначать EPG арендаторам, если захотим. Мультиарендность обеспечивает полную изоляцию между арендаторами. Это может быть разделено, как вы считаете нужным. Например, вы можете иметь dev/qa в совершенно отдельном клиенте, чем производственный. Самое замечательное в этом то, что вы можете полностью сопоставить арендаторов, чтобы они выглядели одинаково. На самом деле мы можем скопировать профили сети приложений из нашего арендатора разработки и применить их к нашему производственному арендатору за пару кликов. Конечно, мы также можем отделить отделы, клиентов и т. д.

Вывод

На самом деле это только верхушка айсберга, когда речь заходит об ACI и о том, как он работает. Адреса ACI не только удовлетворяют потребность в виртуализации сети, но и обеспечивают аппаратную абстракцию для создания сети без сохранения состояния во всем центре обработки данных. Эта сеть позволит сетевым администраторам не только лучше общаться с администраторами приложений, но и создавать мощные сети, которые обеспечивают высокую производительность за меньшее время, чем традиционные сети, благодаря таким вещам, как автоматизация и повторяемость процессов. Для получения дополнительной информации есть несколько видео YouTube, найденных здесь. Есть также несколько обзоров, таких как этот. Коммутаторы Nexus серии 9000, составляющие опорную и оконечную инфраструктуру, доступны уже сегодня, а устройство APIC стало доступно для покупки в начале августа.