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

Что такое Cisco ACI?

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

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

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

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

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

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

ACI Fabric

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

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

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

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

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

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

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

• Adam Raffe: Обучение ACI
• Luca Relandini: ACI для чайников
• Cisco DevNet Learning Labs о ACI

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

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

Например, для обеспечения существования определенного арендатора используется следующая задача 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 принимает следующие параметры, которые влияют на взаимодействие модуля с API REST 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.