Интервью с руководителем отдела корпоративных систем хранения данных, IBM Россия и СНГ
Меняется ли отношение заказчиков к построению катастрофоустойчивых решений? Изменялось ли в последние годы само понимание катастрофоустойчивости?
Термин «катастрофоустойчивость» вполне устоялся, и логика организация катастрофоустойчивых решений остается прежней – это дублирование компонентов инфраструктуры на разнесенных площадках. Расстояние, на которое необходимо разносить площадки, зависит от решаемых задач: если для одних достаточно разнесения в пределах, например города, то для других, особо важных, – по разным городам, а возможно, и странам. Другой вопрос – вектор развития требований к ИТ. Все больше данных переводится в цифровой формат, поэтому требования к отказо- и катастрофоустойчивости ИТ-инфраструктуры возрастают. По статистике, две трети компаний малого и среднего бизнеса прекращают свое существование после потери бизнес-данных. А если представить себе такую ситуацию в крупном бизнесе или государственной структуре, то последствия потери данных могут быть самые печальные, вплоть до гуманитарной катастрофы.
Сегодня заказчики подходят к построению катастрофоустойчивых решений все более рационально, исходя из требований SLA, которые бизнес предъявляет к тем или иным ИТ-сервисам. Что случится, если такая важная система, как ЕRP, будет простаивать в течение двух дней, например, на металлургическом предприятии? Ничего фатального. Для такого предприятия более критичны системы управления технологическими процессами. А вот для банковской структуры ситуация прямо противоположная. Поэтому оптимальное решение выбирается путем определения бизнес-процессов, которые не должны прерываться ни в какой ситуации, и процессов, которыми в крайнем случае можно пожертвовать.
На мой взгляд, определение процессов, для которых должна быть обеспечена катастрофоустойчивость, – это полностью прерогатива бизнеса. А ее реализация – уже за «айтишниками».
Появилось ли за последние годы что-то новое в области технологий обеспечения катастрофоустойчивости?
Прежде всего, можно отметить повышение доступности ИТ-систем. С точки зрения минимизации времени простоев мэйнфреймы IBM с системами хранения DS8000 на сегодняшний день не имеют себе равных – они обеспечивают подтвержденную доступность на уровне «шести девяток».
Традиционно катастрофоустойчивость обеспечивают, в первую очередь, дорогие hi-end-решения, тем не менее не стоит забывать и о решениях среднего класса. Скажем, для систем хранения принципиально важны надежность, производительность, функциональность и масштабируемость. Если раньше hi-end-решения лидировали по всем этим характеристикам, то сегодня функционал midrange-систем шире. По производительности они тоже сопоставимы с hi-end благодаря флеш-технологиям. Но по надежности первенство по-прежнему принадлежит hi-end-системам.
Несмотря на то, что заказчики предпочитают hi-end-решения, особенно для ключевых систем, существует тренд перехода к облачным средам и технологии Software Defined Storage. Решения SDS уже доросли до уровня высочайшего быстродействия и огромного функционала. Появляются и весьма интересные решения, обеспечивающие высокую доступность, например, технология IBM Stretched Cluster, когда географически разнесенные площадки работают с одним логическим томом данных. Это очень гибкое решение, легко масштабируемое и с хорошими показателями ТСО.
Готовность заказчиков использовать такое решение – скорее психологический фактор. Технологическая база позволяет создать Software Defined-решение, которое будет на 100% катастрофоустойчивым и при этом строиться на недорогих компонентах. Яркий пример – система IBM XIV, которая построена на недорогих компонентах. Но за счет грид-архитектуры и программного алгоритма отказ дисков или даже целого модуля системы не приводит ни к остановке системы, ни к потере данных. Однако это не полностью программное, а программно-аппаратное решение, использующее специально адаптированные и протестированные аппаратные компоненты. К полной свободе использования компонентов рынок не готов. У IBM тоже есть чисто программное решение Elastic Storage, но, на мой взгляд, реализация таких решений именно для катастрофоустойчивых инфраструктур – все-таки дело будущего. Поэтому другое наше программно определяемое решение, IBM SAN Volume Controller, мы не продаем как софт. Для него используется протестированный сервер, с конкретной прошивкой, с сопроцессором, который отвечает за онлайн-компрессию данных и т. д.
В чем специфика проектов по построению катастрофоустойчивых ИТ-инфраструктур?
В таких проектах важны не столько инновации, сколько тщательность проработки проекта и аккуратное следование методологии. Все системы должны быть продублированы. А на случай отказа должно быть определено время восстановления, которое прописывается в SLA.
Бэкап – обязательная функция в катастрофоустойчивом решении. В зависимости от архитектуры решения резервное копирование может выполняться только на основной площадке. Но лучше – на двух (или более), потому что если одна из площадок вышла из строя, быстро восстановить данные с другой площадки может не позволить канал связи.
Даже если нарушен не самый критичный сервис, разница в скорости восстановления в несколько часов зачастую имеет большое значение для заказчика – люди просто не готовы подолгу оставаться «в неопределенности». Есть технологии для повышения скорости восстановления данных, например, за счет использования виртуальных ленточных библиотек наряду с традиционными лентами (которые остаются стандартом для многих отраслей). Диски исполняют роль кэша для ленточных носителей, за счет этого можно серьезно увеличить скорость восстановления данных при минимальных затратах.
При подготовке проекта по построению катастрофоустойчивого решения пренебрегать нельзя ничем. Поэтому работа должна начинаться с серьезного обследования, в том числе, состояния сопутствующей инженерной инфраструктуры, организации электропитания, сети, выяснения уровня квалификации администраторов. В IBM этим занимается специальная команда архитекторов.
Изначально надо понимать, на защиту от какого рода катастроф рассчитано решение и какие именно системы необходимо сделать катастрофоустойчивыми. Это скорее задача заказчиков, которые подчас задумывают весьма амбициозные проекты, но не стоит забывать о том, что делать катастрофоустойчивым абсолютно все – очень дорогое удовольствие.
Когда задача определена, подключаются наши проектировщики. У IBM есть необходимые компетенции, и мы не боимся брать на себя ответственность за свои решения.
Что можно сказать о состоянии рынка услуг «Disaster Recovery как сервис»? Каковы перспективы этого вида услуг?
Эти услуги пока слабо развиты. В России IBM не предлагает таких услуг на базе собственных ЦОД. Однако облако – очень удобный способ предоставления услуг, и считаю, что у облачных ЦОД, расположенных в России, хорошее будущее. Здесь большое поле для деятельности и для IBM, и для провайдеров, которые предоставляют управляемые сервисы на базе оборудования IBM.
Но провайдерам нужно научиться правильно подходить к продаже «девяток после запятой». Просто продавать емкость хранения на базе оборудования IBM – невыгодно. Все-таки по ТСА (стоимости приобретения) решения IBM не могут конкурировать с решениями менее известных производителей. Но по ТСО (стоимости владения) они не знают себе равных. И если выходить к заказчикам с пакетным предложением плюс использовать технологии IBM (например, Thin Provisioning, позволяющую динамически менять размеры выделяемых заказчикам томов), сервисы будут не просто окупаться, но и приносить провайдеру прибыль. Поэтому мы прикладываем большие усилия к тому, чтобы правильно адресовать рынку существующие технологии и предлагаем провайдерам модели, позволяющие на них зарабатывать.
