Проблема систем хранения – цена и совместимость

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

Андрей Веневцев,
начальник управления вычислительных систем и телекоммуникаций банка «Союз»

— Какое оборудование для хранения данных используется в вашем банке? Чем определялся его выбор? Приходилось ли его дорабатывать с учетом специфики требований банка?

— В нашем банке системы хранения данных применяются уже давно и успешно. Корпоративным стандартом банка является оборудование производства компании EMC. Сейчас в связи с возросшими потребностями у нас идет внедрение решения Hi-end уровня EMC V-MAX.

Основным критерием выбора данного производителя являлось соотношение цена/качество. Кроме того, привлекательно выглядит стратегия, объявленная этим поставщиком, — ориентация всей деятельности компании на сектор хранения, резервирования и обработки данных, обеспечение эффективности решения этих вопросов.

Главными преимуществами, которые позволяет реализовать любая система хранения, является гибкость в управлении ресурсами хранения и обеспечение основы для использования таких отказоустойчивых технологий, как Microsoft Cluster Service, VMware vMotion, High Availability, Fault Tole­rance и др.

Кроме того, у нас средствами систем хранения реализовано онлайновое копирование данных между основным и резервным ЦОД банка. В случае EMC V-MAX эти преимущества дополняются исключительно высокой производительностью и надежностью оборудования.

Теперь расскажу немного о хранилище данных банка. Оно было принято в промышленную эксплуатацию в 2008 году. Основная задача, решаемая этим проектом, состояла в поддержке формировании управленческой отчетности банка и построения единого хранилища данных банка. Это заказная разработка на базе Oracle Financial Services. В качестве платформы централизованного хранилища финансово-аналитических данных в этом решении используется Oracle Financial Data Manager — ключевой компонент OFSA, обеспечивающий создание и ведение хранилища данных. В нем содержатся как агрегированные финансовые данные, так и детальные данные по всем выданным кредитам, привлеченным депозитам и другим финансовым инструментам банка.

Выбор OFSA производился по результатам анализа в рамках разработки системной архитектуры с привлечением одной из ведущих компаний-интеграторов. Основными критериями были функциональность и стоимость решения.

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

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

— Какие наиболее типичные проблемы с внедрением или сопровождением хранилища данных и систем хранения данных существуют сейчас у банков, на ваш взгляд?

— Как мне кажется, на этапе внедрения любого хранилища данных есть две основные проблемы. Первая — это постановка задачи по аналитике и отчетам. Так как внедрение хранилища — процесс, который может длиться довольно долго, зачастую бывает, что коренным образом меняется не только постановка задачи, но и собственно люди, которые ее ставят и формулируют. А на практике структура и состав результирующих документов, получаемых из системы, оказывает серьезное влияние на набор требуемых данных и структуру витрин данных. Поэтому в процессе внедрения изменение этих параметров весьма нежелательно — это приводит к удорожанию проекта и срыву сроков

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

Проблем с внедрением систем хранения при грамотном проектировании быть не должно. Конечно, есть различные технические трудности, но они преодолеваются на этапе проектирования. Однако есть несколько ключевых моментов, на которые следует обращать внимание.

Для достижения эффекта от системы хранения необходимо сразу проектировать всю инфраструктуру хранения данных, а не пытаться внедрить отдельно взятый экземпляр. Если отсутствуют средства, внедрение можно проводить этапами.

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

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

— Как бы вы определили основные претензии банков к разработчикам существующего на рынке оборудования для хранения данных?

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

Нередко можно оказаться в ситуации, когда система хранения и коммутатор не работают вместе — везде, кроме сетей хранения. Это нонсенс.

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

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

— Заметны ли какие-то интересные изменения на рынке этих систем?

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

— Ваша рекомендация коллегам — что обязательно нужно учесть при поддержке функционирования системы хранения данных и хранилища в случае, когда идет перестройка всей IT-инфраструктуры банка?

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

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

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

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

Для хранилищ данных очень важны следующие действия. Проверяйте корректность загруженных в хранилище данных — наличие ошибок в данных приведет к ошибкам в отчетности и подорвет доверие бизнес-пользователей к этой технологии.

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

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

Жестко отфильтровывайте отчеты и задания на разработку — необходимо сформулировать критерии отбора задач для хранилища данных и реализовывать задания, не подходящие под эти критерии, в локальных учетных системах.