Руководство по Cisco ACI

Что такое Cisco ACI?

Инфраструктура, ориентированная на приложения (ACI)

Инфраструктура Cisco Application Centric Infrastructure (ACI) позволяет определять сеть на основе требований приложений. Эта архитектура упрощает, оптимизирует и ускоряет весь жизненный цикл развертывания приложений.

Контроллер политики приложений (APIC)

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

APIC позволяет администраторам сети легко определять оптимальную сеть для приложений. Администраторы дата-центров могут четко видеть, как приложения потребляют сетевые ресурсы, легко изолировать и устранять неполадки приложений и инфраструктуры, а также отслеживать и профилировать закономерности использования ресурсов.

API Cisco Application Policy Infrastructure Controller (APIC) позволяет приложениям напрямую подключаться к защищенному, общедоступному и высокопроизводительному пулу ресурсов, включающему сеть, вычислительные ресурсы и хранилище.

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

Масштабируемая сеть Cisco Application Centric Infrastructure (ACI) включает коммутаторы Cisco Nexus 9000 серии с APIC для работы в режиме сети ACI (leaf/spine). Эти коммутаторы образуют сеть «fat-tree» путем подключения каждого узла leaf к каждому узлу spine; все остальные устройства подключаются к узлам leaf. APIC управляет масштабируемой сетью ACI.

Сеть ACI обеспечивает согласованную низкую задержку переадресации по высокоскоростным каналам связи (40 Гбит/с, с будущей возможностью 100 Гбит/с). Трафик с источником и получателем на одном коммутаторе leaf обрабатывается локально, а весь другой трафик проходит от входного коммутатора leaf к выходному коммутатору leaf через коммутатор spine. Хотя с физической точки зрения эта архитектура кажется двухходовой, на самом деле это один хоп уровня 3, поскольку сеть работает как один коммутатор уровня 3.

Объектно-ориентированная операционная система (ОС) сети ACI работает на каждом узле Cisco Nexus 9000 серии. Она позволяет программировать объекты для каждого настраиваемого элемента системы. ОС сети ACI преобразует политики из APIC в конкретную модель, которая выполняется в физической инфраструктуре. Конкретная модель аналогична скомпилированному программному обеспечению; это форма модели, которую может выполнить операционная система коммутатора.

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

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

Дополнительная информация

Существует множество ресурсов для изучения ACI, вот список интересных статей из сообщества.

• Adam Raffe: Обучение ACI
• Luca Relandini: ACI для начинающих
• Cisco DevNet Learning Labs о ACI

Использование модулей ACI

Модули Ansible ACI предоставляют удобный интерфейс для управления вашей средой ACI с помощью Ansible-playbook.

Например, для обеспечения существования определенного арендатора используется следующая Ansible-задача с модулем aci_tenant <aci_tenant_module>.

- name: Ensure tenant customer-xyz exists
  aci_tenant:
    host: my-apic-1
    username: admin
    password: my-password

    tenant: customer-xyz
    description: Customer XYZ
    state: present

Полный список существующих модулей ACI для последней стабильной версии доступен на странице список сетевых модулей. Также вы можете ознакомиться с текущей версией разработки.

Запрос конфигурации ACI

Модуль также может использоваться для запроса определенного объекта.

- name: Query tenant customer-xyz
  aci_tenant:
    host: my-apic-1
    username: admin
    password: my-password

    tenant: customer-xyz
    state: query

Или запроса всех объектов.

- name: Query all tenants
  aci_tenant:
    host: my-apic-1
    username: admin
    password: my-password

    state: query
  register: all_tenants

После регистрации возвращаемых значений задачи aci_tenant <aci_tenant_module>, как показано выше, вы можете получить доступ ко всей информации об арендаторах из переменной all_tenants.

Общие параметры

Каждый модуль Ansible ACI принимает следующие параметры, которые влияют на общение модуля с REST API APIC:

host

Имя хоста или IP-адрес APIC.

port

Порт для связи. (По умолчанию 443 для HTTPS и 80 для HTTP)

username

Имя пользователя для входа в APIC. (По умолчанию admin)

password

Пароль для username входа в APIC с использованием аутентификации по паролю.

private_key

Приватный ключ для username входа в APIC с использованием аутентификации на основе подписи. Новое в версии 2.5

certificate_name

Имя сертификата в веб-интерфейсе ACI. (По умолчанию имя файла private_key) Новое в версии 2.5

timeout

Значение таймаута для связи на уровне сокетов.

use_proxy

Использовать системные настройки прокси. (По умолчанию yes)

use_ssl

Использовать HTTPS или HTTP для REST-связи с APIC. (По умолчанию yes)

validate_certs

Проверять сертификат при использовании HTTPS-связи. (По умолчанию yes)

output_level

Влияет на уровень детализации, который возвращают модули ACI пользователю. (Одно из normal, info или debug) Новое в версии 2.5

Поддержка прокси

По умолчанию, если на целевом хосте установлена переменная окружения <protocol>_proxy, запросы будут отправляться через этот прокси. Это поведение можно переопределить, задав переменную для этой задачи (см. Настройка среды (и работа с прокси)), или используя параметр модуля use_proxy.

HTTP-редиректы могут перенаправлять с HTTP на HTTPS, поэтому вы должны убедиться, что настройки прокси для обоих протоколов верны.

Если вам не нужна поддержка прокси, но система может быть настроена на её использование, вы можете добавить этот параметр: use_proxy: no, чтобы избежать случайного использования прокси.

Возвращаемые значения

Следующие значения всегда возвращаются:

current

Результирующее состояние управляемого объекта или результаты запроса.

Следующие значения возвращаются, когда output_level: info:

previous

Исходное состояние управляемого объекта (до внесения изменений).

proposed

Предлагаемый пакет конфигурации, основанный на предоставленных пользователем значениях.

sent

Отправленный пакет конфигурации, основанный на предоставленных пользователем значениях и существующей конфигурации.

Следующие значения возвращаются, когда output_level: debug или ANSIBLE_DEBUG=1:

filter_string

Фильтр, используемый для специфических запросов APIC.

method

Используемый HTTP-метод для отправленного пакета. (либо GET для запросов, DELETE или POST для изменений)

response

HTTP-ответ от APIC.

status

Код HTTP-статуса для запроса.

url

Используемый URL для запроса.

Дополнительная информация

Существуют различные ресурсы, чтобы узнать больше о программировании ACI. Мы рекомендуем следующие ссылки:

• Jacob McGill: Автоматизация Cisco ACI с помощью Ansible
• Cisco DevNet Learning Labs об ACI и Ansible

Аутентификация ACI

Аутентификация по паролю

Если вы хотите войти в систему с именем пользователя и паролем, вы можете использовать следующие параметры со своими модулями ACI:

username: admin
password: my-password

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

Функция «Vault» в Ansible позволяет хранить конфиденциальные данные, такие как пароли или ключи, в зашифрованных файлах вместо открытого текста в ваших playbooks или ролях. Эти файлы Vault можно затем распространять или размещать в системе контроля версий. Дополнительную информацию см. в разделе Использование Vault в playbooks.

Аутентификация на основе подписи с использованием сертификатов

Использование аутентификации на основе подписи более эффективно и надежно, чем аутентификация по паролю.

Генерация сертификата и закрытого ключа

Аутентификация на основе подписи требует (самозаверяемого) сертификата X.509 с закрытым ключом и шага конфигурации для вашего пользователя AAA в ACI. Для генерации работоспособного сертификата X.509 и закрытого ключа используйте следующую процедуру:

$ openssl req -new -newkey rsa:1024 -days 36500 -nodes -x509 -keyout admin.key -out admin.crt -subj '/CN=Admin/O=Your Company/C=US'

Настройка вашего локального пользователя

Выполните следующие шаги:

• Добавьте сертификат X.509 в локального пользователя AAA ACI по адресу ADMIN » AAA
• Нажмите AAA Authentication
• Проверьте, что в поле Authentication поле Realm отображает значение Local
• Разверните Security Management » Local Users
• Щелкните имя пользователя, которому нужно добавить сертификат, в области User Certificates
• Нажмите знак + и введите имя сертификата в поле Name в разделе Create X509 Certificate
  • Если вы используете базовое имя вашего закрытого ключа здесь, вам не нужно вводить certificate_name в Ansible
• Скопируйте и вставьте свой сертификат X.509 в поле Data.

Вы можете автоматизировать это с помощью следующей задачи Ansible:

- name: Ensure we have a certificate installed
  aci_aaa_user_certificate:
    host: my-apic-1
    username: admin
    password: my-password

    aaa_user: admin
    certificate_name: admin
    certificate: "{{ lookup('file', 'pki/admin.crt') }}"  # This wil read the certificate data from a local file

Использование аутентификации на основе подписи с Ansible

Для работы вам потребуются следующие параметры с вашими модулями ACI:

username: admin
private_key: pki/admin.key
certificate_name: admin  # This could be left out !

Дополнительная информация

Подробная информация об аутентификации на основе подписи доступна на странице Cisco APIC Signature-Based Transactions.

Использование ACI REST с Ansible

Хотя в дистрибутиве Ansible уже существует множество модулей ACI, и наиболее распространенные действия можно выполнить с помощью этих существующих модулей, всегда может быть что-то, что нельзя сделать с готовыми модулями.

Модуль aci_rest предоставляет прямой доступ к API REST APIC и позволяет выполнять любые задачи, не покрытые существующими модулями. Это может показаться сложной задачей, но вы можете легко сгенерировать необходимую нагрузку REST для любого действия, выполненного в веб-интерфейсе ACI.

Встроенная идемпотентность

Поскольку API REST APIC по своей природе идемпотентен и может сообщать, было ли внесено изменение, модуль aci_rest автоматически наследует обе возможности и является первоклассным решением для автоматизации вашей инфраструктуры ACI. В результате пользователи, которым требуется более мощный доступ на низком уровне к своей инфраструктуре ACI, не должны отказываться от идемпотентности и не должны угадывать, было ли выполнено изменение при использовании модуля aci_rest.

Использование модуля aci_rest

Модуль aci_rest принимает собственные XML и JSON данные, но также принимает данные в формате YAML (структурированные как JSON). Для XML данных требуется использование пути, заканчивающегося на .xml, а для JSON или YAML – пути, заканчивающегося на .json.

При выполнении изменений можно использовать методы POST или DELETE, а при выполнении запросов – метод GET.

Например, если вы хотите убедиться, что определенный арендатор существует в ACI, эти четыре примера функционально идентичны:

XML (Нативный ACI REST)

- aci_rest:
    host: my-apic-1
    private_key: pki/admin.key

    method: post
    path: /api/mo/uni.xml
    content: |
      <fvTenant name="customer-xyz" descr="Customer XYZ"/>

JSON (Нативный ACI REST)

- aci_rest:
    host: my-apic-1
    private_key: pki/admin.key

    method: post
    path: /api/mo/uni.json
    content:
      {
        "fvTenant": {
          "attributes": {
            "name": "customer-xyz",
            "descr": "Customer XYZ"
          }
        }
      }

YAML (REST в стиле Ansible)

- aci_rest:
    host: my-apic-1
    private_key: pki/admin.key

    method: post
    path: /api/mo/uni.json
    content:
      fvTenant:
        attributes:
          name: customer-xyz
          descr: Customer XYZ

Задача Ansible (Специализированный модуль)

- aci_tenant:
    host: my-apic-1
    private_key: pki/admin.key

    tenant: customer-xyz
    description: Customer XYZ
    state: present

Дополнительная информация

Существует множество ресурсов для изучения интерфейса APIC REST API ACI, мы рекомендуем следующие ссылки:

• Документация модуля aci_rest
• APIC REST API Configuration Guide – Подробное руководство по разработке и использованию API REST APIC, включая многочисленные примеры
• APIC Management Information Model reference – Полное описание модели объектов APIC
• Cisco DevNet Learning Labs о ACI и REST

Примеры использования

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

Не стесняйтесь добавлять больше полезных фрагментов.

Ожидание готовности всех контроллеров

Вы можете использовать приведенную ниже задачу после начала создания APIC и настройки кластера, чтобы подождать, пока все APIC-ы войдут в онлайн-режим. Она будет ждать, пока количество контроллеров не сравняется с количеством, указанным в группе инвентаризации apic.

- name: Waiting for all controllers to be ready
  aci_rest:
    host: '{{ apic_ip }}'
    private_key: pki/admin.key
    method: get
    path: /api/node/class/topSystem.json?query-target-filter=eq(topSystem.role,"controller")
  register: topsystem
  until: topsystem|success and topsystem.totalCount|int >= groups['apic']|count >= 3
  retries: 20
  delay: 30

Ожидание полного соответствия кластера

Нижеприведенный пример ожидает полного соответствия кластера. В этом примере вы знаете количество APIC-ов в кластере и проверяете, что каждый APIC сообщает статус «полного соответствия».

- name: Waiting for cluster to be fully-fit
  aci_rest:
    host: '{{ apic_ip }}'
    private_key: pki/admin.key
    method: get
    path: /api/node/class/infraWiNode.json?query-target-filter=wcard(infraWiNode.dn,"topology/pod-1/node-1/av")
  register: infrawinode
  until: >
    infrawinode|success and
    infrawinode.totalCount|int >= groups['apic']|count >= 3 and
    infrawinode.imdata[0].infraWiNode.attributes.health == 'fully-fit' and
    infrawinode.imdata[1].infraWiNode.attributes.health == 'fully-fit' and
    infrawinode.imdata[2].infraWiNode.attributes.health == 'fully-fit'
#    all(apic.infraWiNode.attributes.health == 'fully-fit' for apic in infrawinode.imdata)
  retries: 30
  delay: 30

Сообщения об ошибках APIC

Могут возникнуть следующие сообщения об ошибках, и этот раздел поможет вам понять, что происходит, и как их исправить/избежать.

Ошибка APIC 122: неизвестный класс управляемого объекта ‘polUni’

В случае, если вы получаете эту ошибку, будучи уверенным в правильности своей загрузки aci_rest и классах объектов, проблема может заключаться в том, что данные, по факту, не являются корректным JSON (например, в отправляемых данных используются одинарные кавычки вместо двойных), и в результате APIC не правильно анализирует ваши классы объектов из загруженных данных. Один из способов избежать этого – использовать формат YAML или XML, которые легче правильно составить и изменить в дальнейшем.

Ошибка APIC 400: некорректные данные в строке ‘1’. Отсутствуют атрибуты, тег ‘attributes’ должен быть указан первым, перед любым другим тегом

Хотя спецификация JSON допускает неупорядоченные элементы, API REST APIC требует, чтобы элемент JSON attributes предшествовал массиву children или другим элементам. Таким образом, необходимо убедиться, что ваши данные соответствуют этому требованию. Сортировка ключей словаря поможет.

Ошибка APIC 801: свойство descr uni/tn-TENANT/ap-AP не прошло проверку на валидность для значения ‘A “legacy” network’

Некоторые значения в APIC имеют строгие правила формата, и встроенная проверка APIC на валидность предоставленного значения не прошла. В приведенном выше случае, параметр description (внутренне известный как descr) принимает только значения, соответствующие Regex: [a-zA-Z0-9\!#$%()*,-./:;@ _{|}~?&+]+, как правило, он не должен содержать кавычки или квадратные скобки.

Известные проблемы

Модуль aci_rest является обёрткой вокруг APIC REST API. В результате любые проблемы, связанные с APIC, будут отражаться при использовании этого модуля.

Все проблемы, перечисленные ниже, либо были сообщены поставщику, либо их можно просто избежать.

Слишком много последовательных вызовов API может привести к ограничению соединения

Начиная с ACI v3.1, APIC будет активно ограничивать скорость подключения с аутентификацией по паролю, превышающую определенный порог. Это делается в рамках мер защиты от DDoS-атак, но может создавать проблемы при использовании Ansible с ACI при аутентификации по паролю. В настоящее время одним из решений является увеличение этого порога в конфигурации nginx, но рекомендуется использовать аутентификацию на основе подписи.

ПРИМЕЧАНИЕ: Рекомендуется использовать аутентификацию на основе подписи с ACI, так как она не только предотвращает ограничение подключения, но также улучшает общую производительность при использовании модулей ACI.

Некоторые запросы могут не отражать изменения должным образом (#35401)

Существует известная проблема, когда некоторые запросы к APIC не правильно отражают внесенные изменения в результирующем выводе, даже если мы явно запрашиваем эти изменения у APIC. В одном случае с использованием пути api/node/mo/uni/infra.xml происходит ошибка, тогда как api/node/mo/uni/infra/.xml работает корректно.

ПРИМЕЧАНИЕ: Обходным решением является регистрация значений возвращаемых задачей (например, register: this) и управление тем, когда задача должна сообщить о изменении, добавив: changed_when: this.imdata != [].

Некоторые запросы, как известно, не являются идемпотентными (#35050)

Поведение APIC несогласованно с использованием status="created" и status="deleted". В результате, когда вы используете status="created" в своей полезной нагрузке, результирующие задачи не являются идемпотентными и создание объекта завершится неудачей, если объект уже существует. Однако это не относится к status="deleted", где подобный вызов несуществующего объекта не вызывает никаких ошибок.

ПРИМЕЧАНИЕ: Для обеспечения идемпотентности в вашем рабочем процессе следует избегать использования status="created" и использовать status="modified".

Установка пароля пользователя не является идемпотентной (#35544)

Из-за несоответствия в REST API APIC, задача, которая устанавливает пароль локально аутентифицированного пользователя, не является идемпотентной. APIC выведет сообщение Password history check: user dag should not use previous 5 passwords.

ПРИМЕЧАНИЕ: Для этой проблемы нет обходного решения.

ACI Ansible сообщество

Если у вас есть конкретные проблемы с модулями ACI, заявки на новые функции или вы хотите внести свой вклад в проект ACI, предложив изменения или обновления документации, обратитесь к странице вики Ansible Community ACI по адресу: https://github.com/ansible/community/wiki/Network:-ACI

Вы найдете наш план, обзор открытых проблем и запросов на включение в ACI, а также дополнительную информацию о нас. Если вы заинтересованы в использовании ACI с Ansible, присоединяйтесь! Мы время от времени проводим онлайн-встречи, чтобы отслеживать прогресс и готовиться к новым выпускам Ansible.