Предметом нашего разговора с вице-президентом, начальником отдела базовой инфраструктуры управления ИТ Райффайзенбанка Сергеем Квашуком стали результаты недавно завершенного проекта по модернизации и оптимизации систем хранения данных (СХД) корпоративного уровня.

Intelligent Enterprise: Что представляла собой подсистема хранения данных в Райффайзенбанке до начала работ по вашему проекту? Чем она перестала устраивать вас?

Сергей Квашук: У нас довольно мощная инфраструктура хранения данных. При ее создании применялось оборудование EMC, IBM, Hitachi Data Systems (HDS). Оно разделено на четыре класса по уровню критичности данных и приложений. Наиболее критичные данные хранятся в системах первого уровня, построенных на оборудовании IBM. Это связано с тем, что нам необходимо предоставлять ресурсы для платформы AS400, а применение для этой цели СХД других производителей сопряжено с массой сложностей и неудобств. Следующий уровень построен на оборудовании EMC и HDS. Третий уровень, где размещаются платформы виртуализации, базируется на системах среднего уровня от EMC. И четвертый уровень, собранный из оборудования выведенного из продуктива в результате модернизаций, используется для систем тестирования и разработки. Все эти системы находятся в трех центрах обработки данных — в двух из них размещены основные и резервные инсталляции продуктивных систем, а третий используется для сред тестирования и разработки. При этом один из ЦОДов для продуктивных систем представляет собой colocation от компании КРОК.

Мы используем практически все технологии, применяемые при построении систем хранения данных, включая виртуализацию различных уровней, автоматическое перемещение информации по уровню хранения, применение SSD-носителей в качестве кэша. Наша сеть хранения данных основана на технологии FC с использованием маршрутизируемого backbone для связи всех ЦОДов и построена на оборудовании Brocade класса DCX.

Ключевым потребителем сервисов СХД являются хранилища данных, с помощью которых формируется отчетность для банковской группы RBI. Они генерируют основные объемы, как по нагрузке, так и по хранению. Требования наши непростые, особенно в свете необходимости полного резервирования данных, что еще больше повышает нагрузку на СХД. В итоге приходится одномоментно обрабатывать более 40 Тбайт меняющихся данных. Скорость обмена между СХД и серверами достигает 2,4 Гбайт/с при том, что требования к задержкам со стороны СХД крайне велики (не более 5 мс). Наше хранилище является одним из самых больших и сложных во всей группе RBI.

До недавнего времени основной СХД, которую использовали наши хранилища данных, была EMC Symmetrix VMAX. Но постепенно, когда нагрузки существенно выросли, она перестала справляться с ними. Росли задержки в подготовке отчетов. При этом система занимала половину площади арендованного ЦОДа, показатели энергоэффективности также оставляли желать лучшего. Созрело решение о замене.

Как выбиралось решение для замены?

Идею модернизации Symmetrix VMAX мы сразу отклонили. Это потребовало бы или наращивания площадей в арендованном ЦОДе, или строительства нового. Ни тот, ни другой варианты не устраивали по финансовым показателям и вряд ли встретили бы одобрение со стороны менеджмента банка. Продление поддержки у EMC уже в ближайшей перспективе означало бы существенный рост затрат.

В итоге было принято решение о замене СХД. По совокупности показателей в качестве замены была выбрана система HUS VM компании HDS. У нас уже был опыт использования оборудования корпоративного уровня из линейки HDS VSP/HUS VM, да и на уровне группы RBI это фактически стандарт. Сейчас в ряде банков группы или уже завершен, или идет процесс внедрения подобных систем.

HUS VM — на сегодняшний день единственная на рынке система высшего уровня на базе PCI-E v.3 и микроархитектуры Intel Sundy Bridge, которая сочетает высокую производительность с энергоэффективностью. Всё это позволяет при компактных размерах получить такую производительность, какая нам нужна. Применение новейших процессоров и высокоскоростной системной шины практически полностью снимает ситуацию перегрузки контроллеров при активном использовании SSD-дисков. И этот набор дополняется весьма полезным ПО, в частности для тонкой настройки систем, виртуализации и перемещения данных по уровням хранения. В нашем случае Hitachi Dynamic Tearing очень помогла при выявлении и устранении всяческого рода узких мест и обеспечения необходимого уровня задержек. Это очень часто является проблемой, особенно с ПО подготовки отчетности и аналитики, у которого серьезные требования не только к СХД, но и к серверной мощности. Цена решения в не самой слабой конфигурации с оплатой полного объема всех опций в фирменном ПО не превысила расходов на поддержку имеющейся системы от EMC.

Так что найти альтернативу было сложно. Да, сейчас поставщики СХД пытаются занять необходимую нам нишу усиленными младшими системами из линейки продуктов среднего уровня, но пока там очень много ограничений, которые нас не устраивают. Например, у конкурирующих решений недостаёт возможностей масштабирования. А более младшие модели из линейки массивов HDS например HUS 150 нас не устраивали по многим параметрам. К примеру, по ограничению объема кэш-памяти, производительности контроллеров, а также отсутствию важных для нас средств, ориентированных на использование SSD.

Каковы результаты проекта?

Система в требуемой конфигурации заняла 32 юнита в стойке — более чем вчетверо меньше в сравнении с Symmetrix VMAX. Это позволило нам освободить место в арендованном ЦОДе, что тоже является результатом, ведь сэкономленные деньги – это заработанные деньги.

После переноса всех данных утилизация контроллеров не превышала 15%. Задержки снизились в пять-шесть раз. Время подготовки отчетов сократилось на 4 часа, и это ещё не предел т.к. мы уперлись в возможноти серверного оборудования и архитектуры.

Тем не менее у нас остаются резервы для модернизации, и мы их обязательно используем. Уже ясно, что мы будем наращивать объем FMD-модулей на базе технологии SSD. Это, естественно, даст возможность еще больше увеличить производительность систем, когда возникнет такая необходимость.