Федерация  — это бета-функция, предлагаемая всем клиентам OVH Private Cloud с vCenter 6.5 . Если вы хотите принять участие в бета-тестировании, обратитесь в нашу службу поддержки. Это позволяет использовать внешний Microsoft Active Directory в качестве источника аутентификации для доступа к серверу VMware vCenter . Реализация этой функции стало возможным благодаря OvH в команде DevOps , которые разработали инновационный и уникальный API , который добавляет дополнительные возможности для тех , предлагаемых VMware. Действительно, в настоящий момент невозможно настроить источники идентификаторов через собственный API vCenter.



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

Зачем?

По умолчанию права доступа к vCenter в частном облаке управляются непосредственно этим vCenter. Пользователи создаются локально (localos или домен SSO), и все механизмы управления доступом ( RBAC ) управляются службой SSO . Включение федерации делегирует управление пользователями Microsoft Active Directory (AD). В результате сервер vCenter будет взаимодействовать с контроллером домена, чтобы гарантировать, что пользователь, пытающийся подключиться, является тем, кем он себя называет. VCenter сохраняет управление ролями и привилегиями для объектов, которыми он управляет. После настройки федерации можно связать пользователей AD с ролями vCenter, чтобы они могли получать доступ и / или управлять определенными объектами в инфраструктуре (виртуальными машинами, сетями, папками и т. Д.).


Одним из основных применений этого будет облегчение доступа к vCenter для администраторов за счет уменьшения количества учетных записей, необходимых для обслуживания различных элементов инфраструктуры. Кроме того, появится возможность расширить и унифицировать политику управления паролями между Active Directory и vCenter Private Cloud.

Тот факт, что федерацией можно управлять через API OVH, позволяет автоматизировать настройку, а также поддерживать ее в рабочем состоянии. Наконец, очень просто добавить проверки в любой инструмент мониторинга (Nagios, Zabbix, Sensu и т. Д.) Для мониторинга состояния Федерации и прав, назначенных пользователям.

Вот пример простого сценария PowerShell, который будет периодически проверять, находится ли конфигурация федерации в желаемом состоянии:

Архитектура и предпосылки

Поскольку vCenter должен будет взаимодействовать с контроллерами домена, первым шагом будет разрешение потоков между этими элементами. Есть несколько способов достичь этой цели, например, объединить OVHCloud Connectс частным шлюзом . Для изучения всех различных возможностей потребуется целая статья, поэтому мы советуем вам связаться с OVH или одним из наших партнеров, чтобы помочь вам в выборе наиболее подходящей архитектуры. Следующая диаграмма дает вам упрощенный обзор того, как это может выглядеть:



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

• Ваши учетные данные OVH (ник и пароль)
• Имя вашего частного облака (в форме 

  pcc-X-X-X-X

  )
• Необходимая информация об инфраструктуре Active Directory, а именно:
  
  • Краткое и длинное имя домена Active Directory (например,

    contoso

    и 

    contoso.com

    )
  • IP-адрес контроллера домена
  • Имя пользователя и пароль учетной записи AD с достаточными правами для просмотра каталога
  • Расположение групп и пользователей в иерархии AD как «базовое DN» (пример:) 

    OU = Users, DC = contoso, DC = com

    . Следует отметить, что хотя информация о группе является обязательной, в настоящее время ее невозможно использовать для управления аутентификацией.
  • Список пользователей Active Directory, которых вы хотите привязать к vCenter. Необходимо будет указать имена пользователей в виде username@FQDN.domain (например,

    federation@contoso.com

    )

Обратите внимание, что в настоящее время невозможно иметь несколько пользователей с одним и тем же коротким именем, независимо от того, управляются ли они локально или с помощью Active Directory.

Активация и настройка

После того, как вы соберете всю необходимую информацию, можно будет активировать и настроить Федерацию. Операция будет проходить в три этапа:

1. Активация связи между Active Directory и частным облаком
2. Привязка одного или нескольких пользователей AD к частному облаку
3. Назначение прав пользователям

На данный момент конфигурация доступна только через OVH API, но в среднесрочной перспективе это будет возможно сделать через панель управления OVH.  API предлагает все необходимые параметры для активации, настройки или даже удаления федерации частного облака:

Включение соединения между AD и частным облаком

Перейдите на сайт проводника API и выполните аутентификацию, используя свои учетные данные OVH. Если у вас его еще нет, получите имя (также называемое serviceName в API) своего частного облака, так как оно будет обязательным для всех остальных шагов настройки. Вы можете получить доступ к этой информации, выполнив GET для URI / SpecialCloud:



Включите федерацию, предоставив всю информацию об Active Directory с помощью POST в URI- адресе / SpecialCloud / {serviceName} / federation / activeDirectory . Вся запрашиваемая информация обязательна:



Активация Федерации займет некоторое время и будет происходить в фоновом режиме. Вы можете следить за ходом операции через панель управления OVH:



После завершения вы можете получить идентификатор федерации, отправив запрос GET на URI- адрес / SpecialCloud / {serviceName} / federation / activeDirectory :

Привязка одного или нескольких пользователей AD

Теперь, когда ваш AD объявлен в vCenter Private Cloud, мы сможем привязать к нему пользователей Active Directory. Обратите внимание, что даже если ваши пользователи связаны, с ними не будет связанных ролей vCenter, поэтому они не смогут войти в систему.

Чтобы привязать пользователя, вам нужно будет отправить запрос POST на /dedicatedCloud/{serviceName}/federation/activeDirectory/{activeDirectory}/grantActiveDirectoryUser URI, указав полное имя пользователя:



Убедитесь, что пользователь присутствует в поисковом подразделении, которое вы указали при связывании AD с vCenter. Еще раз, вы можете проверить, что задача импорта выполнена через API или через панель управления:



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

Назначение прав доступа

Последним шагом будет предоставление пользователям прав доступа к различным объектам виртуальной инфраструктуры. Этот шаг не отличается от обычного способа управления правами пользователей частного облака. Это можно сделать через API или панель управления OVH.



Теперь вы должны иметь возможность войти в свой vCenter с пользователями вашего AD и начать управлять своим частным облаком!

В этом посте мы увидели, как активировать опцию «Федерация» и какие преимущества она дает пользователям частного облака OVH. В следующей публикации мы поговорим о еще одной новой функции: Granular Rights. Так что следите за новостями в блоге OVH!

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

С OVH Private Cloud мы избавляем вас от этой сложности. Мы управляем этим трудоемким и стрессовым аспектом, чтобы вы могли сосредоточиться на своем бизнесе и производстве.

Но это не значит, что это не проблема для нас.

Обновление сотен vSphere 5.5 до 6.0

vSphere — это ведущий продукт предложения Private Cloud, он является частью пакета SDDC, предоставляемого VMware. vSphere — это программное обеспечение, позволяющее пользователю управлять своими хостами, хранилищем, сетью… Через клиента он может создавать кластеры с этими активами для надежного, стабильного и высокодоступного размещения производственной среды.

С сентября 2018 года поддержка vSphere (vCenter, ESXi…) версии 5.5 со стороны VMware прекращается. Обладая безопасностью и стабильностью инфраструктуры частного облака, мы начали процессы обновления для всех vCenter.



У нас было около 850 vCenter в версии 5.5 в производстве, что представляет собой значительную работу по обновлению всего, если она выполняется вручную. Но в OVH у нас есть общий лейтмотив: автоматизировать все человеческие действия  для повышения эффективности и избегать ошибок.

Так нам удалось обновить 850 vCenter с версии 5.5 до версии 6.0 за 4 недели. Другими словами, более 210 vCenter в неделю, 30 vCenter в день , с командой из 10 человек, выполняющих это обслуживание в фоновом режиме, без какого-либо влияния на производительность клиентов.

Наша команда разработчиков разработала и создала набор скриптов (которые мы внутри себя называем «роботом») для автоматизации обновлений vCenter несколько лет назад. Этот робот сильно изменился с момента появления продукта Private Cloud и следует за нами с версии 4.1 до 6.5, работа над которой еще продолжается.

Мы столкнулись с множеством проблем при настройке автоматических действий, таких как повреждение базы данных, службы, не интегрированные в систему единого входа (было очень сложно управлять им в версиях 5.0 и 5.1), а также отпечаток, который не обновлялся для всех служб., очень сложно устранить неисправность и воспроизвести ее. У нас даже были некоторые операционные системы, которые блокировали обновления программного обеспечения, из-за чего все было жестко остановлено.

Наши операционные группы много работали с группой поддержки VMware, чтобы найти обходные пути для возникающих проблем и автоматизировать их с помощью команды разработчиков. Это привело к созданию базы знаний VMware для уведомления клиентов о проблемах, с которыми мы столкнулись и которые были признаны VMware ошибками. Команды провели много ночей, чтобы обеспечить минимальное влияние доступности vSphere для клиентов.

Обновление апгрейдера: новая версия робота

Все эти проблемы убеждают нас действовать по двум причинам. Во-первых, запустите новую версию робота обновления , создавая меньше ошибок, имея более быстрое выполнение с точки зрения клиента, более надежное и надежное. Во-вторых, мы отказались от процесса обновления по умолчанию с использованием обновления программного обеспечения VMware для решения, в котором мы начинаем со только что установленного обновленного стека vCenter на обновленной виртуальной машине, а затем повторно подключаем все компоненты (базу данных, NSX…) к этому новому vCenter. .

Это значительно повысило стабильность наших услуг, поскольку мы обеспечиваем новую работоспособную и обновленную основу для vCenter. Все это резко сократило количество вмешательств наших SRE в инфраструктуры частного облака.

Если суммировать наши действия: мы проверяем, что служба работает, прежде чем что-либо делать, затем мы готовим все наши сохранения и снимки для подготовки к обновлению. Как только это будет сделано, мы развернем нашу автоматизацию, чтобы запустить обновление. Каждый шаг включает автоматическую проверку, чтобы убедиться, что все действия выполнены.

Мы создали этого робота для обновления в роботе-оркестраторе, который, в соответствии с введенными параметрами, будет создавать задачи обновления для каждого частного облака, связанного с обслуживанием, и будет планировать его в автоматические даты в течение как минимум 72 часов с учетом рассмотрения клиента. но также количество запускаемых обновлений по часам и критическим периодам (например, Черная пятница или Зимние распродажи). Клиенты могут изменить расписание своих обновлений с помощью диспетчера в части «Операции», чтобы выполнить обслуживание в более удобное для их производства время.



Наши команды SRE следят за роботами и следят за тем, чтобы техобслуживание выполнялось должным образом и в запланированное время.






Подводя итоги, мы перешли от необходимости автоматизировать операцию обновления vCenter, которая должна занимать не менее 12 часов на каждый vCenter, к первой версии автоматизации, которая позволяет выполнить эту операцию за 4 часа, но с слишком высокий уровень ошибок (20%) из-за повторяющихся ошибок, которые SRE приходилось исправлять вручную. Теперь вторая версия является прочной, надежной и стабильной , позволяющей избежать известных проблем и создавать только редкие и уникальные проблемы, которые будут исправлены в процессе автоматизации на тщательно подобранном этапе.

Что дальше?

В ближайшие месяцы последуют другие мероприятия по техническому обслуживанию, обновление хоста с версии 5.5 до версии 6.0, обновление нашей опции Veeam Backup с 8.0 до версии 9.5, обновление нашей опции Zerto с 5.0 до 5.5 и множество других обновлений наших внутренних машин. для обеспечения регулярного аудита PCI-DSS.

Мы сохраним ту же прозрачность и коммуникацию , пока мы прислушиваемся к вашим отзывам и улучшаем нашу систему обслуживания.