Контакты
Подписка
МЕНЮ
Контакты
Подписка

Поддержка Big Data

В рубрику "ИТ-интеграция" | К списку рубрик  |  К списку авторов  |  К списку публикаций

Поддержка Big Data

Говоря о больших данных, или Big Data, как правило, сразу же начинаешь думать про специализированные СХД, программно-аппаратные средства, вспоминать именитых вендоров, представляешь, что все это наконец-то "взлетело", заработало… И за всем этим технологическим великолепием как-то забываешь, что не только архитектурой живет решение, но и поддержкой. Вот о ней и поговорим
Александр Башкиров
ИТ-эксперт

Обычное заблуждение пользователей: поддержка нужна тогда, когда что-то ломается. На самом деле, когда речь идет об Enterprise – это немного не так. Точнее, совсем не так. Потому что в промышленной среде поддержка направлена в первую очередь на то, чтобы ничего не ломалось. Своевременно предвосхищать, работать на опережение, обеспечивать отсутствие проблем. Особенно актуально это в мире больших данных. Потому что большие данные обычно предъявляют особые требования к их доступности, времени доступа, безопасности и непрерывности. А это те качества, которые, с одной стороны, обеспечиваются архитектурой, а с другой – замыкаются на поддержку. Попробую объяснить.

Мифы о типичном ЦОД

Существует миф, что хорошо отлаженный механизм работает сам собой. Отчасти это так, но только отчасти. Рассмотрим типичный ЦОД (пока не говорим ни о "больших", ни о "маленьких" данных). В ЦОД находятся данные, средства их обработки и анализа. Все это работает от электрической сети. Представим себе классический бич электросетей – скачок напряжения. Если он пройдет до конечных серверов, то, скорее всего, часть данных будет уничтожена (выйдет из строя жесткий диск, сгорит память, контроллер – причин может быть множество). Казалось бы, при чем тут поддержка? А при том, что хороший ЦОД имеет процедуры резервного копирования, а очень хороший ЦОД может иметь автоматически запускаемую процедуру восстановления, например на другой сервер взамен вышедшего из строя. Правда, в подавляющем большинстве случаев подобные процедуры запускаются вручную и выполняются автоматизированно. То есть решение о запуске процедуры принимает человек. В более простых ЦОД ситуация еще более наглядна: заменить вышедший из строя жесткий диск, "планку памяти" может только и исключительно человек – сотрудник поддержки.

Если рассуждать подобным образом, может сложиться впечатление, что к большим данным описанная ситуация относится лишь косвенно, потому что это в общем обычная "третья линия" с точки зрения поддержки пользователей. Ну или первая – с точки зрения обеспечения работоспособности ЦОД. Если же вернуться на шаг назад, на уровень бизнес-требований, то становится понятно, что такая "низовая" поддержка – важный элемент в общей структуре обеспечения заданных параметров сервисов, связанных в том числе и с большими данными.

Уровни поддержки данных

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

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


Говоря об аппаратных средствах, стоит отметить, что большие данные почти всегда требуют высокопроизводительных вычислительных средств. Обработка больших объемов данных – задача нетривиальная даже на современной вычислительной базе. (Для примера – попробуйте сделать простое удаление или обновление по широкому условию на таблице в десяток гигабайт со сложными связями; я видел подобные запросы, которые "висели" по несколько суток.)

2. Уровень поддержки ОС и ее компонент
На этом уровне производится настройка операционной системы и ее компонент. И тут все не так просто. Во-первых, специфическая, оптимизированная для большой пропускной способности архитектура сети накладывает свой отпечаток и на архитектуру серверного оборудования (как пример подобных решений: 4 сетевых карты с параллельным приемом-передачей, их настройка в ОС). На этом уровне также может функционировать система резервного копирования данных.

3. Уровень поддержки БД
На этом уровне производится настройка БД. Скажу честно, мероприятие это нетривиальное: большие данные требуют особой тщательности при настройке и тюнинге. При этом, если речь идет не о БД, а о, например, большом файловом массиве, то такой уровень поддержки отсутствует.

4. Уровень поддержки данных
На этом уровне производится поддержка на уровне логики данных, их связанности, целостности и т.д. Уровень непростой, потому что требует высокой квалификации и компетенции именно в прикладной области плюс в программном обеспечении, которое эту область автоматизирует. И если по остальным уровням поддержки можно найти узкоспециализированных, но относительно унифицированных специалистов, то на уровне поддержки самих данных таких специалистов возможно только вырастить (логика распределения данных в каждой организации своя, софт, даже один и тот же, может и должен работать с разными структурами данных, зависящими от характера деятельности организации).

Инструменты поддержки данных

Поддержка не существует сама по себе: на каждом уровне поддержки есть свои инструменты.

Система мониторинга
Чаще всего это сквозная (между несколькими уровнями) система мониторинга, которая работает как минимум на уровне поддержки ОС и БД. Часто она же работает на уровне поддержки инфраструктуры – как сетевой, так и серверной. В ряде случаев в мониторинг "заводят" в том числе и электропитание, как один из важнейших для функционирования системы параметров (тем более что современные системы мониторинга способны взаимодействовать со значительным количеством оборудования, в том числе электросетевого).

Система регистрации инцидентов
Второй важный инструмент поддержки. Причем инциденты – это не столько заведенные вручную события, сколько автоматические инциденты, поступающие из системы мониторинга на основании интеллектуального анализа событий. От того, насколько грамотно и точно прописан алгоритм формирования инцидентов, а также реакция на них, во многом зависит качество поддержки. Поясню. Например, по определенным событиям в системе мониторинга могут формироваться управляющие воздействия на систему хранения данных, о чем также автоматически может формироваться инцидент (для контроля со стороны персонала). Автоматически могут формироваться и инциденты, требующие вмешательства персонала.

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

Активатор сервисов
Третий важный инструмент поддержки. Это программное обеспечение, которое позволяет по заданным сценариям выполнять различного рода изменения: подключать и отключать массивы дисков, управлять оборудованием, инсталлировать программное обеспечение и т.д. Активатор, как правило, работает в паре с системой мониторинга, обеспечивая обратную связь с ландшафтом на генерируемые ею события. Современные активаторы – мощные средства, позволяющие реализовать определенные сценарии активации. Например, при установке нового диска его необходимо отформатировать, проверить на сбойные сектора, при их отсутствии – завести диск в массив и обеспечить синхронизацию. Это все в автоматизированном режиме вполне способен выполнить современный активатор. Таким образом, роль человека сводится лишь к замене диска и контролю выполняемых активатором операций – все остальные операции возьмет на себя активатор.


Отдельно стоит сказать, что связка "активатор – система мониторинга" может весьма эффективно выступать в роли одного из звеньев обеспечения контура информационной безопасности. В частности, правильно настроенная система мониторинга может поставлять информацию о возможных инцидентах ИБ, на основании которой активатор выполняет определенные действия (блокирует данные, пользователя, порт и т.д. в зависимости от степени риска и класса угрозы), а также оповещает сотрудника поддержки (как вариант – офицера ИБ, включенного в контур поддержки) для принятия решения. Вопрос опять-таки в настройке и в том, какие события какой реакции требуют.

База знаний и система поддержки принятия решений
Последний инструмент поддержки – база знаний и выстроенная и отлаженная система поддержки принятия решений. При кажущейся простоте – очень важный компонент в момент, когда речь идет об участии человека. Причем база знаний тоже может быть разбита на уровни, быть сквозной между уровнями… Но самое главное – она должна обладать полнотой и достаточностью информации, в противном случае нет никакого смысла в ее создании. На этом моменте стоит остановиться особо.

База знаний как книга рецептов
Там, где данные действительно большие, обязана быть хоть какая-то документация на программно-аппаратные средства (давайте будем честными – зачастую документация именно "хоть какая-то", поскольку она имеет свойство теряться, а ее архивирование обычно не предусмотрено). И в ряде случаев она выручает, но… далеко не всегда. Почему? Да потому, что обычно документация не дает готовых рецептов, в ней описываются составляющие решения. А поддержка связана с необходимостью быстро решить ту или иную ситуацию, и тут уже требуются знания "на пересечении", то есть по разным компонентам решения, причем применительно к конкретным связкам конкретных компонент. Фактически, база знаний в данном случае выступает в роли некой книги рецептов, в которой содержится как "выжимка" из документации, так и квинтэссенция опыта. Причем базу знаний стоит строить таким образом, чтобы обеспечить в ней постоянную актуализацию информации. Но за этим вроде бы простым тезисом стоят как минимум зачатки серьезных процессов: управления изменениями и конфигурациями. При этом организация процесса управления изменениями гарантирует, что при публикации изменения оно будет отражено в том числе и в базе знаний, а организация процесса управления конфигурациями гарантирует, что все связи между элементами инфраструктуры (на всех уровнях) будут учтены и задокументированы.

CMDB и хранение знаний
Следует проводить четкую грань между CMDB (конфигурационная база данных) и базой знаний, хотя зачастую эти понятия и смешивают. CMDB в "классическом" случае все же имеет целью хранение связей, а база знаний – хранение знаний. Хотя, как известно, жизнь богаче наших о ней представлений, и мне встречалась ситуация, когда CMDB использовалась в том числе и для хранения знаний, для чего в ней был выделен конфигурационный элемент Knowledge, к которому были прикреплены статьи-"рецепты", которые касались работы комплекса в целом. Кроме того, у каждого элемента конфигурации было выделено три элемента: Docs (официально поставляемая документация), Tips (статьи по конфигурации) и Install (руководство по инсталляции/деинсталляции элемента). Таким образом, получалось решение, которое, с одной стороны, консолидировало всю информацию об элементе, а с другой – описывало систему в целом. Отдельно стоит отметить, что наполнение этой "базы знаний" было весьма качественным: в компании был выстроен и неукоснительно соблюдался процесс управления изменениями. И ни одно изменение не могло быть принято без изменения соответствующих статей в потомках элемента конфигурации. Итоговое решение получилось немного громоздким, но весьма действенным именно с точки зрения поддержки: в одном месте, в довольно удобном интерфейсе была консолидирована информация не только об инфраструктуре, но и о том, как с ней работать. В итоге "на выходе" скорость реагирования была довольно высокой (правда, с учетом того, что более 80% операций выполнялись автоматически, но и "ручные" операции выполнялись в рекордно короткие сроки).

Поддержка любогоЦОД

Почти все рассуждения выше применимы не только к Big Data. Любой мало-мальски уважающий себя ЦОД вынужден в той или иной степени выстраивать поддержку, основанную на схожих принципах. Разница только в том, что ЦОД обычно заточен на сравнительно небольшие объемы собственно данных и, соответственно, обладает меньшей дисковой емкостью и меньшей вычислительной мощностью по сравнению с ЦОД, где хранятся большие данные. И да, безусловно, поддержку больших данных правильно строить при помощи ITIL (об этом косвенно сказано выше в случае с CMDB), но с поправкой на специфику, а именно – фокусом на объемы данных и необходимую скорость их обработки.

Опубликовано: Журнал "Системы безопасности" #2, 2015
Посещений: 8009

  Автор

Александр Башкиров

Александр Башкиров

Независимый ИТ-эксперт

Всего статей:  2

В рубрику "ИТ-интеграция" | К списку рубрик  |  К списку авторов  |  К списку публикаций