В большинстве серверов HPE имеется встроенный контроллер управления Integrated Lights Out (iLO). Его первоначальное назначение – удаленное управление сервером:
включение/выключение, перехват графической консоли, подключение медиа-устройств – что и иллюстрирует название «Lights-Out» – «Свет выключен» – в ЦОД, где трудятся серверы HPE, администратору нет необходимости быть рядом. Все действия с серверами можно выполнить из любой точки мира. Функционал iLO постоянно расширялся и сейчас его можно назвать центром управления полетом сервера, фактически это мини-компьютер внутри большого компьютера. У iLO есть процессор, оперативная и флэш-память, Ethernet порт и, естественно, интерфейс управления: веб-браузер, командная строка, скрипты и программируемые интерфейсы REST API. Через REST API и осуществляется автоматизированное управление серверами HPE в соответствии со стандартом Redfish, пришедшим на смену устаревшему IPMI.

Следующий уровень управления инфраструктурой HPE – программный продукт HPE OneView. Для стоечных и блейд-серверов c-Class – это виртуальная машина (поддерживаются все основные гипервизоры), для платформы HPE Synergy – это аппаратный модуль – Composer. Управляется HPE OneView аналогично iLO: веб-интерфейс, скрипты и команды RESTful API / Redfish.

HPE OneView обеспечивает полное «низкоуровневое» управление серверной инфраструктурой: настройка BIOS, конфигурирование сетевых интерфейсов, подключение к SAN, создание томов на внешних системах хранения (HPE Primera, HPE Nimble, HPE 3PAR), контроль и обновление драйверов и микропрограмм. Все эти действия можно выполнять для одного или нескольких серверов, как используя консоль браузера, так и с помощью скриптов PowerShell или Python. Но самых интересных результатов можно достичь путем интеграции OneView со средствами развертывания операционных систем и приложений. В этом случае администратору вообще не нужно обращаться к OneView, все необходимые действия выполняются в вышестоящей консоли управления. Например, для среды VMware единой консолью служит vCenter, для Microsoft – Windows Admin Center.

REST и Redfish

Если говорить о REST (Representational State Transfer), то он представляет собой обычный HTTP(s) запрос, передавая необходимые данные в качестве параметров запроса. В отличие от Redfish (более современной версии REST), REST никак не стандартизирован, он лишь является архитектурным стилем, позволяющим придерживаться определенных последовательностей, таких как запрос, тело запроса и параметры запроса. При этом какое дерево запроса, по какому стандарту передается тело запроса (JSON, XML или другой), каждый производитель решает на свое усмотрение. В итоге это привело к тому, что если пользователь работал с REST-интерфейсами от нескольких вендоров, то к ним требовался разный подход, а часто и разный набор кода, что не позволяло масштабировать решения основанные на REST-запросах.

В отличие от REST, Redfish является стандартизированным интерфейсом и позволяет работать пользователю с разными производителями с одинаковым подходом и тем самым, обеспечивать масштабируемость решения. В решениях HPE стандарт Redfish появился в ILO4 (v2.30) и более поздних продуктах.

Решение HPE по автоматизации (Deployment Automation Solution)

При преодолении определенной численности информационных систем и нарастании запросов со стороны бизнеса, сотрудники отдела сопровождения часто приходят к целесообразности автоматизации ежедневных, рутинных операций. Это помогает вводить и обслуживать информационные системы быстрее, а сотрудникам сконцентрироваться на более важных задачах. Обычно администраторы пытаются автоматизировать задачи собственными силами и привычными им средствами. В этом им помогает широкий набор инструментов (https://github.com/hewlettpackard/), таких как Ansible, Python, Puppet и других. При этом, как правило самостоятельно написанные скрипты приходится часто править, особенно при масштабировании решения в условиях продуктивной среды.

Deployment Automation Solution представляет собой услугу по настройке решения автоматизации ежедневных операций, построенного на открытом исходном коде, либо их коммерческих аналогов, которые уже используются на предприятии. Таким образом потребители решения смогут вносить правки, как в само решение, делая его более заточенным под конкретную организацию, так и добавлять в решение собственные наработки, тем самым расширяя функционал базового решения. Deployment Automation Solution основан на стандартных программных компонентах, таких как Ansible, для автоматизации и оркестрации, Nginx для предоставления библиотеки образов микрокодов, операционных систем и файлов конфигураций и GitLab как способ централизованной доставки скриптов и Ansible playbooks. Таким образом, использование стандартных отраслевых инструментов с помощью сценариев Ansible, связанных с базовым репозиторием кода и инфраструктурным конвейером DevOps с помощью GitLab делает подход системным, а масштабирование удобным. Большинство компонент работает в контейнерах, что дает возможность быстро развертывать и обновлять само решение.

Весь процесс взаимодействия построен на программно-определяемой инфраструктуре посредством использования существующих богатых функций OneView Ansible collection / REST API, предназначенных для среды управления HPE OneView, или Redfish / iLO для управляемых сред, без OneView, а также API-интерфейсов хранилищ данных. Также используются API конкретного программного производителя, например:

• Ansible Playbooks от RHEL могут связываться с серверами Linux через SSH;

• Подключение к VMware может осуществляться через REST API или SSH;

• Связь с Windows может быть через WinRM.

Для удобства оркестрации решения и построения сложных рабочих процессов автоматизации используется AWX (https://github.com/ansible/awx, upstream project для Ansible Tower) или Ansible Automation Platform (https://www.ansible.com/integrations/infrastructure/hpe), для объединения и инкапсуляции атомарной инфраструктуры в виде базовых операций кода в рабочие процессы автоматизации для реализации задач выделения ресурсов и управления жизненным циклом. Этот модульный подход позволяет гибко настраивать интеграцию аппаратных и программных элементов решения. При этом AWX, или Ansible Automation Platform не является обязательным атрибутом. Все рабочие процессы доступны через REST API и могут быть вызваны из любого существующего решения, такого как HPE ServiceNow или Morpheus. решение достаточно гибкое, чтобы интегрироваться с порталом управления, выбранным каждым клиентом, и обеспечивает интеграцию с любым сторонним решением.

В базовом варианте решения HPE предоставляет два основных сценария использования:

• Установка операционных систем, включая настройку аппаратных компонент: презентация томов СХД, настройка зонинга для SAN и т.д, а также программных компонент, включая настройки безопасности и манипуляции с ПО;

• Обновление микрокодов, в том числе и без прерывания работы серверов.

При этом заказчик получит доступ к репозиторию с обновлениями playbooks для поддержки новых сценариев и компонент. Из коробки решение заточено под аппаратную платформу HPE, включая новейшие аппаратные ресурсы: DL Gen10, Synergy, Apollo и 3PAR / Primera / Nimble, однако открытый исходный код и поддержка разнообразных API позволит пользователям интегрировать решения сторонних производителей.

Заключение

Инфраструктура Hewlett Packard Enterprise предоставляет широкие возможности по автоматизации ежедневных ИТ-операций: подготовка и развертывание новых серверов, подключение к сетям передачи данных и системам хранения, установка операционных систем, контроль и обновление драйверов и firmware, реконфигурирование систем под изменяющиеся требования приложений. Заказчики сами выбирают уровень автоматизации: от простых сценариев групповых операций с iLO до решений «Инфраструктура как код» с HPE OneView и Ansible AWX / Automation Platform.