Как не провалить аудит в новых условиях?

Время от времени компании проводят аудит. Это комплексный взгляд на ИТ-инфраструктуру и варианты ее развития. Когда чаще всего проводят аудит?

• Непонятна картина реального состояния ИТ-инфраструктуры. Такая ситуация может возникнуть, например, при смене руководства или уходе/замене ключевых сотрудников.

• Общее состояние ИТ-инфраструктуры с точки зрения бизнеса «какое-то не такое». Слишком большие расходы, частые инциденты, нарушение SLA.

• Впереди большой проект (например, назревшая замена CRM) и вопросов пока больше, чем ответов (на что, как, поможет ли).

Аудит должен ответить на главные вопросы:

• Как выглядит реальная картина ИТ?

• Какие есть проблемы и узкие места в инфраструктуре?

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

В этом посте мы пройдемся по ключевым блокам, которые должны быть включены в аудит ИТ-инфраструктуры, и основным доступным сейчас инструментам.

Аудит систем виртуализации

С аудитами систем виртуализации в целом всё осталось как и прежде, но есть негативные моменты. Мы потеряли доступ к действительно хорошим инструментам, к примеру, VMware Health Analyzer. По части Microsoft ничего не изменилось, но и тут не всё так радужно: прямых аналогов удобного RVTools для Windows просто нет. Приходится снимать данные по Hyper-V с помощью сторонних скриптов, которые не обновляются уже несколько лет.

Какие данные мы собираем в ходе аудита?

Тут всё проходит в несколько этапов. Для начала нужно собрать данные из интерфейсов управления физическими серверами — iLo, iDRAC, BMC, IPMI. Хорошо, если у заказчика есть централизованная система управления — OneView, OpenManage или XClarity Administrator. Из нее можно сделать общую выгрузку по всем добавленным железкам. В противном случае придется залезать в управление каждого сервера и снимать данные: модель, серийные номера, процессоры, оперативную память, настройки и версию BMC, модули питания, PCI-устройства, GPU (при наличии), физические и логические настройки RAID-контроллеров, данные о версиях прошивок компонент. В целом это универсальный список снимаемых данных, но он может отличаться в зависимости от производителя сервера и версии BMC. Еще лучше картину дополнят фотографии аудируемых серверов в стойках и технических лейблов на них. Особенно это полезно для региональных площадок, где часто встречаются ошибки установки, коммутации и т. д.

Далее снимаются данные непосредственно из системы виртуализации.

Если речь идет про VMware, то бесспорным лидером по части инвентаризации является RVTools. Он снимает полную картину на момент запуска утилиты. Если же стоит задача оценки производительности на дистанции, то тут мы можем воспользоваться как встроенным мониторингом, так и апплаенсом vROPS (vRealize Operations Manager), который хоть и обходными путями, но можно достать с сайта VMware, а при установке дается 30 дней триального периода. За это время вполне можно собрать недельную статистику по производительности инсталляции vSphere. Все данные будут храниться локально. Еще хотелось бы отметить встроенный инструмент Skyline Health, который в свежих версиях vShpere (7.0 и выше) показывает много полезной информации, в том числе на соответствие критическим CVE, гомогенности настроек хостов в кластерах и т. д.

Что касается Microsoft Hyper-V, то тут ситуация немного другая. В нашем распоряжении есть фактически только самописные скрипты от сообщества, которые обновляются не очень часто, если вообще обновлялись последние несколько лет. Поэтому придется расчехлить старый добрый IE или заниматься парсингом их вывода вручную. С другой стороны, исходный код каждого из скриптов полностью открыт и при желании может быть проверен на скрытые закладки. Из таких скриптов можно отметить следующие:

• Get-HyperVInventory

• Get-HyperVReport

• HV-DASHBOARD-V3.3

Для анализа производительности можно использовать, например, программу PAL, написанную инженером Microsoft, последние обновления датированы 2018 годом.

Аудит системы хранения данных

Для любой СХД классической архитектуры этот список будет выглядеть так:

• Имя системы хранения, IP-адрес управления

• Модель массива, версия прошивки

• Информация о текущих неисправностях и сбоях

• Типы и количество задействованных дисков, уровни отказоустойчивости (RAID)

• Типы и количество интерфейсов ввода-вывода, их скорости

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

• Потребленная емкость

• Количество и типы лицензий на дополнительный функционал

Далее можно более детально посмотреть на каждую СХД с учетом вендорских «фишек» модели и сверить с разделами лучших практик из документации — как организованы логические пулы и тома на них, как они соотносятся с архитектурой контроллеров. К примеру, в отличие от СХД с архитектурой Full Mesh, на СХД с жестко «прибитыми» к контроллеру пулами или архитектурой ALUA нужно максимально равномерно распределять нагрузку между контроллерами, чтобы получить оптимальную производительность. Стоит уточнить, какие информационные системы обслуживает данная СХД и данные каких типов располагаются на томах. Далее соотнести эту информацию с настройками технологий уменьшения объемов данных — дедупликацией и компрессией. Вряд ли в лучших практиках встретится рекомендация располагать журналы СУБД на томах с включенной дедупликацией, но выключенной компрессией. Стоит обязательно взглянуть на заполнение пулов и томов с учетом возможных переподписок и «тонкого» выделения, ведь большинство СХД переходят в режим Read Only при полном заполнении. Это почти всегда сулит серьезные сложности с возобновлением нормальной штатной работы. Нелишним будет взглянуть на коммутацию и организацию мультипассинга до хостов для сравнения с настройками самих хостов, настройки репликаций или метрокластера, а также на настройки мониторинга и уведомлений. Если вендор предоставляет поддержку, стоит выяснить дату End of Support, чтобы обеспечить предсказуемость замены запчастей, обновления и развития инфраструктуры. Обычно производители публикуют эти списки на своих официальных сайтах.

Много полезной информации можно получить из менеджеров управления оборудованием. К сожалению, многие отчеты собираются в зашифрованном виде, информация в них довольно легко теряется. Поиск многих стандартных ошибок автоматизирован скриптами, которые постоянно совершенствуются. Ниже приведены некоторые примеры для основных вендоров СХД, из которых можно получить большую часть данной информации.

HITACHI — Configuration Report

HPE — SMU, SSSU

Dell/EMC — SP Collect

Некоторые СХД, например, Pure Storage и HPE Nimble/Primera, ориентированы на внешнюю телеметрию и алгоритмы искусственного интеллекта. Получение выгрузок с таких СХД является затруднительным и ограничивает возможность для самостоятельного анализа, тем не менее часть информации можно получить через графический интерфейс, интерфейс командной строки и запросы REST API.

Аудит SAN

С аудитом сети хранения данных несколько проще, так как по большому счету существуют всего два вендора, производящих данное оборудование, и доля одного из них ничтожно мала. Речь про Cisco MDS, поэтому оставим его за рамками статьи и сосредоточимся на основном производителе — Brocade (Broadcom), хотя большинство основных параметров будут справедливы для обоих. К сожалению, Brocade отключил возможность пользоваться очень мощным и удобным средством сбора данных — SAN Health. Однако все необходимые данные по-прежнему можно получить непосредственно с коммутаторов с помощью команд supportsave и supportshow, а именно:

• Имя коммутатора, IP-адрес управления

• Модель коммутатора, версия прошивки, имя фабрики

• Информация о текущих неисправностях и сбоях

• Типы и количество интерфейсов ввода-вывода, их скорости

• Переподписка и утилизация транков

• Количество пролицензированных портов

• Количество и типы лицензий на дополнительный функционал

  

Как и в случае с СХД, стоит выяснить дату End of Support и проверить параметры мониторинга и уведомлений. Отдельной работой будет соотнесение портов подключенных хостов с портами коммутаторов, алиасами и настройками зон. При отсутствии SAN Health эта работа становится достаточно сложной, кропотливой и долгой, поэтому мы создаем его аналог на самописных скриптах.

Аудит систем резервного копирования

Ситуация с системами резервного копирования не сильно отличается от ситуации с СХД. Все основные отчеты и выгрузки в большинстве случаев снимаются непосредственно из ПО. Основные моменты при аудите СРК:

• Архитектура инфраструктуры СРК

• Количество площадок, распределение оборудования

• Характеристики управляющих и медиасерверов

• Типы и характеристики устройств хранения резервных копий

• Перечень клиентов

• Версии ПО клиентов и компонентов СРК

• Информация о текущих неисправностях и сбоях

• Информация о частоте и типе бэкапов, глубине хранения

• Настройки политик хранения и расписания

• Настройки репликации вторичных резервных копий

• Объем Frontend и Backend данных

В аудите СРК важную роль играет выявление соответствия системы параметрам SLA, предъявляемым к клиентам или их группам, таким как окна резервного копирования, частота бэкапов, время восстановления и т. д. На это соответствие может влиять практически бесчисленное число факторов, начиная от типа транспортного протокола резервных копий, количества параллельных потоков, типа клиентов и заканчивая настройками политик хранения, расписанием резервного копирования. Каждая СРК в какой-то степени уникальна, поэтому основной задачей становится ее проверка на соответствие лучшим практикам для целого ряда уникальных сочетаний оборудования и настроек используемых решений.

Для получения исходных данных для анализа можно использовать следующие инструменты: Veeam, Veritas NetBackup, Commvault.

Veeam

В Veeam B&R отсутствует развитая система отчетности. Лучшим решением для обладателей этого ПО является установка триальной версии Veeam ONE. Можно получить множество отчетов практически по всем аспектам системы резервного копирования. Также есть возможность централизованного сбора логов со всей инфраструктуры СРК из консоли управления. Однако сложная структура получаемого архива и отсутствие документации по его разбору делает получение интересующих параметров крайне затруднительным.

Veritas NetBackup

Аналогично с Veeam, для удобного получения данных из NetBackup можно воспользоваться функционалом OpsCenter (если повезло, и он есть в компании). Но вполне возможно обойтись и без него — большинство параметров системы можно взять из выгрузки NetBackup Support Utility tool (NBSU).

К сожалению, наглядность вывода NBSU сильно хромает, и надо быть очень внимательным, чтобы заметить возможные проблемы и ошибки.

Commvault

По сравнению с вышеперечисленным ПО, Commvault, пожалуй, обладает самым мощным инструментарием построения отчетности. Отчеты можно генерировать сразу из нескольких консолей, при этом практически любую выгрузку можно кастомизировать, добавив в нее требуемые параметры. В CommCell Console на базе Java содержится фиксированный, но довольно внушительный перечень отчетов. В Web Console, помимо встроенных отчетов, существует возможность загружать самые разнообразные шаблоны с cloud.commvault.com.

Еще можно упомянуть сторонние программные продукты, которые в некоторых случаях способны упростить сбор и анализ данных для аудита. Но про некоторые из них пока нельзя однозначно сказать, доступны они для использования или нет. Например, STOR2RRD и Live Optics в момент написания статьи оставались доступными, что, к сожалению, не гарантирует, что они будут по-прежнему доступны к моменту публикации.

В заключение

Проведение аудита «на всякий случай» избыточно — для этого есть плановые проверки и обследования с расписанными регламентами и действиями в случае тех или иных результатов.

Аудит проводят, когда стандартные проверки не могут выявить проблему или при планировании масштабной модернизации архитектуры, внедрении, замене каких-то глобальных систем.

Если сравнивать с человеком, то ИТ-инфраструктура — это его здоровье, а аудит — «глобальный чекап» перед операцией (чтобы решить, нужна ли она вообще). Но один «домашний врач» (собственная ИТ-команда) его не проведет. Нужна поликлиника (внешний подрядчик), где такое обследование — обычная плановая процедура, где есть оборудование (стенды) и узкопрофильные специалисты. Такая команда ничего не пропустит, а диагноз (отчет) и план лечения (дорожная карта) будут максимально точными и полными. Здоровье — это не игрушки