Один из непременных атрибутов цифровой экономики — большие данные, для хранения и обработки которых необходимы все более производительные и емкие системы хранения. Для управления ими требуются квалифицированные администраторы, способные мгновенно реагировать на малейшие признаки нарушения работоспособности системы. Однако человек всегда будет оставаться слабым звеном, поэтому одним из выходов может стать применение адаптивных систем управления, использующих данные удаленной телеметрии для прогнозирования сбоев и снижения производительности.
Первые системы удаленного сбора телеметрии и ее анализа для выполнения корректирующих действий появились еще на заре развития вычислительной техники — при управлении бортовыми ЭВМ. Известный пример — обновление программного обеспечения космических аппаратов «Вояджер-1» и «Вояджер-2», запущенных еще в 1977 году и до сих пор продолжающих функционировать. Благодаря анализу данных телеметрии и обновлению программы бортового компьютера, разработчикам удавалось обходить отказы памяти, решать проблемы, связанные с падением мощности радиоизотопных источников питания и ослаблением радиосигнала по мере удаления от Земли.
Конечно, такие решения до недавнего времени были недоступны обычным пользователям, однако производители оборудования всегда старались не отдавать работу своей продукции на волю случая. Суммарная стоимость технической поддержки за время эксплуатации аппаратуры часто превосходит сумму начальной покупки, что побуждает поставщика заботиться о безотказной работе установленных у заказчика систем, оперативно реагируя на инциденты или заранее их исключая.
Распространение Интернета расширило возможности удаленной диагностики и позволило увеличить объем и частоту телеметрии, а совершенствование методов машинного обучения, анализа больших данных и хранение в облаке открыли пути для дальнейшего развития инструментов, предназначенных для выявления и предсказания отказов. Типичная ситуация, в которой, например, может помочь прогнозная аналитика — анализ результатов неудачных обновлений встроенного программного обеспечения системы хранения. Если хотя бы у одного заказчика были зарегистрированы проблемы после перехода на новую версию, то можно выявить возможные сочетания версий операционных систем и приложений, профилей нагрузок и текущих настроек, приводящих к деградации производительности или нарушению доступности данных, а затем временно заблокировать саму возможность обновления ПО на всех аналогичных системах. Однако в этом случае урон конкретному заказчику мог быть нанесен — сбой все равно уже произошел, хотя и был локализован.
Основной элемент «разума» Pure1 META компании Pure Storage — система искусственного интеллекта META, анализирующая «озеро» данных телеметрии от 10 тыс. систем хранения Pure Storage, расположенных по всему миру. Данные о работе каждой установленной системы дважды в минуту передаются в облачное хранилище объемом более 7 Пбайт для дальнейшей классификации «отпечатков пальцев» и построения «ДНК рабочей нагрузки» каждого конкретного массива. Затем «мозг» META сканирует входящую телеметрию для проверки на соответствие с уже имеющимися описаниями инцидентов, чтобы в реальном времени выдавать рекомендации по их разрешению или предотвращению (см. рисунок).
.png "Компоненты Pure1 META") |
| Компоненты Pure1 META |
Наряду с тем, что ведется мониторинг состояния флеш-массива в реальном времени через браузер или мобильное приложение оповещения администратора о критических событиях, происходит обучение нейронной сети META, к которой обращается подсистема Workload Planner, позволяющая, в частности, предсказывать пиковую нагрузку на оборудовании и классифицировать признаки его возможного отказа или износа.
Одна из полезных особенностей системы — способность моделировать рабочие нагрузки в разных конфигурациях и поддерживать сценарии «что будет, если». Например, что произойдет, если нагрузка на все контроллеры составит 70% или будут отключены несколько из них? Как изменится показатель IOPS, если добавить еще один контроллер? Система Pure1 META, применяя методы классификации временных рядов [1], проверяет, будет ли текущей платформе по силам новая нагрузка и смогут ли все компоненты конфигурации безболезненно взаимодействовать друг с другом. После этого можно оптимизировать рабочие нагрузки, используя опыт уже имеющихся развертываний и выдавать рекомендации по выбору наиболее подходящей конфигурации. Детали архитектуры нейросети META производитель не раскрывает, однако ясно, что без искусственного интеллекта, обладающего способностью к самообучению, анализ почти 2 трлн точек телеметрии данных в сутки просто невозможен.
Обратная сторона такой автоматизации — сокращение инструментов непосредственного ручного контроля за функционированием системы хранения. Например, при работе с логическими томами у пользователя имеется только функция создания и удаления, а просмотр диагностической информации возможен в усеченном объеме. Решения, критичные для обеспечения работоспособности системы хранения, принимаются производителем или специалистами сервисного партнера. Кроме того, у пользователя нет возможности управлять средствами оптимизации хранения данных, дедупликацией и компрессией — все эти инструменты подключены всегда, а производитель берет на себя риски того, что параметры SLA будут отличаться от предварительно согласованных.
Следует отметить еще один важный момент, который пока не учитывается системами искусственного интеллекта: процессы настройки производительности базы данных и системы хранения обычно тесно связаны, но традиционно выполняются независимо и разными специалистами. В результате проблемы с производительностью зачастую возникают именно на стыке системы хранения и СУБД, а одни и те же показатели с точки зрения администраторов баз данных и администраторов системы хранения могут интерпретироваться совершенно по-разному. В таких ситуациях возможностей Pure1 META может оказаться недостаточно и потребуется взаимодействие с поставщиком СУБД. Например, в Oracle Exadata предусмотрено комплексное управление всем стеком решений, от оборудования до программных средств оптимизации SQL-запросов. Аналогичные решения предлагаются и в SAP HANA.
Не следует также забывать о том, что при принятии любого решения на основе рекомендаций системы искусственного интеллекта может быть допущена ошибка, вызванная как недостоверными входными данными, так и несовершенством методики принятия решения. При реализации обратной связи от систем мониторинга и предсказания неисправностей может возникнуть ошибочный автоматический поворот в неверном направлении. Он может проявляться в неверных настройках оптимизации производительности, которые «в среднем» правильны, но в конкретном случае приводят к обратному результату, вплоть до потери данных. Например, анализ статистики отказов и гарантийных замен накопителей на фоне роста числа корректируемых ошибок показал, что следует объявить модуль неисправным, вывести из эксплуатации и заменить. В целом подобная рекомендация повышает степень надежности, но, если применить ее в системе, где требуется заменить сразу несколько накопителей, может возникнуть ситуация, когда единовременно из эксплуатации выводится больше накопителей, чем необходимо для соблюдения принятой схемы отказоустойчивости, что приведет к потере данных.
***
Системы хранения традиционно поставляются в виде уникального закрытого программно-аппаратного комплекса, в котором под контролем разработчика находятся аппаратное обеспечение, собственная ОС и реализованные на ней сервисы: блочный доступ, моментальные снимки, репликация, интерфейс управления и т. д. Для управления этим, с точки зрения заказчика, «черным ящиком» применяются системы типа Pure1 META, которые способны распознавать неисправности, предотвращать проблемы с производительностью и устранять негативное влияние человеческого фактора, однако для построения комплексной адаптивной надежной конфигурации требуется обеспечить тесное взаимодействие всех «умных» систем управления ее компонентами: СУБД, системы хранения, коммуникационной инфраструктуры.
Литература
- Виктор Китов. Практические аспекты машинного обучения // Открытые системы. СУБД. — 2016. — № 1. — С. 14–17. URL: www.osp.ru/os/2016/01/13048648 (дата обращения: 05.12.2017).
Виктор Липин (lipinv@ot.ru) — руководитель отдела вычислительных платформ и систем хранения данных, «Открытые Технологии» (Москва).
