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

О тенденциях развития систем хранения главный редактор журнала «Открытые системы» Дмитрий Волков и научный редактор Наталья Дубова беседуют с Леонидом Винокуровым, руководителем ИТ-департамента «ТехноСерв А/С», одной из немногих отечественных компаний, занимающихся развертыванием систем хранения с середины 90-х годов. Компанию отличает уровень экспертизы, проводимой при реализации проектов, связанных с консолидацией данных и построением катастрофоустойчивых центров, а также понимание проблемы интеграции в новые системы унаследованных приложений.

Данные ведущих производителей и независимых исследовательских компаний показывают, что рынок систем хранения стремительно растет. Чем вы это объясняете?

Прежде всего уточню: понятие системы хранения (storage) — предельно широкое, от дискеты до многотерабайтного дискового массива. Я буду говорить только о системах хранения уровня предприятия. Первый фактор роста рынка таких систем — увеличение объемов хранения. До определенного времени работа велась в основном с фактографическими объектами, с примитивными файлами. Но когда появились СУБД, а затем и технологии обработки изображений, когда сложилась целая цифровая медиа-индустрия, объемы хранимой информации начали расти экспоненциально.

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

В России этот процесс тоже начался. Когда в 1994-1996 годах на рынке для мэйнфреймов появились массивы RAID, было трудно объяснить заказчику, какой выигрыш ему даст эта технология, почему стоит платить существенно больше за равную или даже меньшую емкость хранения. В 1998 году объяснять приходилось уже меньше. Здесь все, на мой взгляд, очень просто. Масштабы информационных систем на предприятиях, работающих в условиях новой российской экономики, непрерывно растут. И сегодня российский рынок консолидированных корпоративных систем хранения существует и, более того, активно растет, причем по законам, схожим с западными.

Что отличает систему хранения масштаба предприятия?

Ключевая характеристика такой системы — консолидированность. Сейчас в крупных компаниях происходит консолидация серверного хозяйства, прикладной инфраструктуры. Что при этом выступает интегрирующим центром? Сегодня крупный вычислительный центр объединяет разнородные платформы, их количество растет, увеличивается и число серверов. Даже в традиционно очень требовательных к вычислительным ресурсам областях, таких как экспериментальная физика, постепенно происходит переход от суперкомпьютеров к вычислительным фермам — набору дешевых Linux-серверов. В известной степени то же самое наблюдается и в обработке бизнес-информации. Много файловых серверов, много почтовых серверов, много приложений ERP, OLAP и т.д. Естественно, рядом могут работать и унаследованные приложения. Что может собрать все это воедино? В роли интегратора выступает сеть, но она не затрагивает проблем хранения данных, поэтому единственным фактором интеграции изнутри является система хранения данных.

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

Третья черта — масштабируемость и универсальность. Систему хранения в десятки терабайт практически невозможно подвергнуть радикальной перестройке. Как развивать такую систему? Очень важная роль здесь принадлежит технологиям SAN/NAS. Изначально SAN была ответом на неэффективность классического SCSI-интерфейса с ограничением расстояния подключения 25 метрами и невозможностью наращивания системы с интерфейсными связями «точка-точка». Но по мере совершенствования эта технология позволила найти ответ на вопрос, как подключить к централизованной системе хранения сегодня десять, а завтра тысячу серверов, не меняя при этом архитектуры. Естественным развитием технологии являются работы по переводу сетей хранения с Fibre Channel на IP. В результате их можно будет реализовать на базе выделенной, но при этом обычной сетевой инфраструктуры. NAS — выход в той ситуации, когда необходимо управлять из единой точки множеством серверов. В целом сегодня решение, в котором в том или ином виде не заложена реализация сетевой системы хранения, ущербно.

Можете ли вы оценить масштабы и перспективы рынка систем хранения в России?

Мне трудно оценить размеры отечественного рынка SAN. Могу лишь сказать, что количество проектов на базе SAN, которые мы реализовали за последние два года, перевалило за полсотни.

Что представляет собой проектирование и внедрение систем хранения с точки зрения российского системного интегратора? В каком соотношении находятся поставка оборудования и сервис?

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

Дальше систему нужно запустить. Но запустить не означает просто подключить серверы к дисковому массиву через Fibre Channel. Заказчик хочет, чтобы ему помогли перенести данные, просит учесть такие моменты, как наличие нескольких операционных систем, особенности определенных версий ПО, взаимодействие СУБД, хранилищ данных, обеспечение работы унаследованных приложений и т.д. Значит, вновь понадобится профессиональная экспертиза. Большинство заказчиков, внедряющих системы хранения корпоративного уровня, требуют наличия горячей линии и гарантий, что специалисты приедут в течение определенного времени. Заказчик будет работать с интегратором, если только тот в состоянии выполнить все эти условия. Сервисная составляющая бизнеса, связанного с системами хранения, составляет сегодня 10-15%.

Как оценить эффект от внедрения системы хранения?

Прежде всего необходимо оценить совокупную стоимость владения (total cost of ownership — ТСО). Порой трудно оценить прямой экономический эффект от внедрения того или иного ИТ-решения, но у менеджеров должна быть некая несмещенная оценка качества работы. Такой оценкой и стала ТСО. Как ее вычислять? Предположим, предприятию необходимо 10 Тбайт на три года. Стоимость различных вариантов решения известна, но это еще не все. Нужно оценить расходы на управление, сопровождение и поддержку разнесенных структур и те же расходы в случае централизованной архитектуры. Нужно продумать, как поступить, если спустя год дополнительно к этим 10 Тбайт понадобится еще 2 Тбайт.

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

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

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

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

Предположим, бухгалтерия предприятия со штатом в 25 тыс. человек вполне удовлетворена системой расчета заработной платы на мэйнфрейме. Но финансового директора, которому необходимы инструменты анализа показателей, интерфейс мэйнфрейма не устраивает. Означает ли это, что надо внедрять новую систему расчета зарплаты? Нет. Необходимо построить OLAP-решение, обеспечив технологию регулярного переноса в него унаследованных данных. А система хранения сыграет роль ускорителя проекта, защитит это решение, обеспечит более высокое качество управления.

За десять лет многие небольшие компании превратились в крупные предприятия. И уже через два-три года у них неизбежно появится своя программа интеграции унаследованных приложений. Компании, использующие такие платформы, как AS/400 или Unisys, в 2002 году окажутся перед проблемой сохранения приложений для них. Самый перспективный путь ее решения — подвести под все имеющиеся платформы и приложения базу новой инфраструктуры хранения. Так что проблема интеграции унаследованных приложений не сводится только к поиску ответа на вопрос, как подключить ЕС ЭВМ к новой платформе.

Отрасль SAN/NAS очень динамична. Как вы относитесь к внедрению новинок?

Менеджеры, которые определяют стратегию реализации ИТ-проектов, должны быть, с одной стороны, в меру консервативными, с другой — в меру увлекающимися людьми. Если они не интересуются новыми идеями, они их «проспят», но и недостаточно прагматичные люди могут рекомендовать нечто, о чем очень красочно написано в буклете, но чего еще на самом деле на рынке нет. Профессиональный системный интегратор должен постоянно читать, размышлять, следить за тенденциями. Это особенно важно для того, чтобы вовремя включить в свой портфель решений то, что еще существует на уровне идеи. Это необходимо чтобы начинать маркетинг заранее. С другой стороны, необходимо четко следовать жестким регламентирующим процедурам, в которых говорится: «Да, это уже готовое решение, это разрешено к поставке». Здесь важную роль играет взаимодействие с сервисными структурами вендоров. В 1998 году мы реализовали первый SAN-проект в России, устанавливая оборудование — коммутаторы и мосты Fibre Channel — буквально «со стапелей».

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

Каковы перспективы рынка систем хранения?

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

Главное, что на рынке сегодня устоялся стандарт на системы хранения масштаба предприятия, и соревнование между лидерами отрасли идет не столько на уровне идей, сколько на уровне эффективности реализации этого стандарта. Основные составляющие стандарта следующие: RAID, подключение посредством SAN, минимальный набор технологий, включающий в себя интегрированное управление из единой точки, быстрое копирование и резервный центр. Большинство производителей предлагают открытые интерфейсы, а это значит, что, помимо производителей базовых архитектур систем хранения, такие технологии смогут использовать все разработчики ERP-систем, хранилищ данных и т.д.

Поделитесь материалом с коллегами и друзьями