Как известно, основные направления развития бизнеса любого банка – это расширение филиальной сети, предложение потребителям новых банковских продуктов и сокращение операционных расходов. Так или иначе, все это связано либо с автоматизацией каких-то бизнес-процессов, либо с уменьшением стоимости автоматизации уже существующих, а также снижением эксплуатационных расходов. В течение нескольких лет в Собинбанке проводились проекты, направленные на сокращение затрат на инфраструктуру, и одним из них стал проект по консолидации систем резервного копирования данных.
До выполнения проекта каждая автоматизированная система была развернута на отдельных серверах со своими собственными системами резервирования, предусматривающими копирование данных на компакт-диски, ленточные носители, либо просто на жесткие диски. Рост бизнеса, сопровождаемый увеличением объемов баз данных, привел к значительному повышению расходов на хранение необходимого числа копий. Кроме того, управление децентрализованной инфраструктурой само по себе дело сложное и недешевое.
Основу системы хранения ИТ-инф-раструктуры банка образуют два модульных высокопроизводительных массива EMC Clariion CX3-40, объединенных в сеть хранения с помощью коммутаторов Fibre Channel производства Brocade. На базе этих массивов реализовано «горячее» резервирование данных на жесткие диски (D2D, Disk-to-Disk), что позволяет достаточно быстро восстанавливать данные в случае сбоя. Резервные копии создаются с помощью функций самого приложения (Oracle, Microsoft SQL Server), однако рост объемов данных, а следовательно, и размеров архивных копий сводит на нет достоинства этого экстенсивного способа.
Ежедневный объем резервирования на тот момент составлял около 3 Тбайт, а с учетом роста объемов данных система должна была обеспечивать копирование до 5 Тбайт данных в день. В целом, с учетом перспектив развития банка на ближайшие пять лет, требовалось обеспечивать защиту от потери порядка 200 Тбайт информации. Система резервного копирования должна была осуществлять копирование данных с 28 серверов на базе Microsoft Windows Server, Sun Solaris и Linux, в том числе двух Microsoft Exchange Server, 12 файловых серверов и 14 серверов c базами данных Oracle
и Microsoft SQL Server. Соответственно, восстанавливать система должна была 84 сервера (28х3, то есть основной, резервный и тестовый варианты для каждого сервера; при этом резервный и тестовый варианты восстанавливаются не с резервных копий, а с основного варианта – с продуктивного диска).
В марте 2008 года был объявлен конкурс по выбору поставщика новой централизованной системы хранения данных для головного офиса Собинбанка. Реализовывать эту систему было решено на недорогих ленточных библиотеках. Критериями выбора конкретного решения должны были стать сроки внедрения и суммарная стоимость системы, включающая затраты на оборудование, расходные материалы, программное обеспечение, а также на работы по внедрению системы, ее поддержке в течение трех лет эксплуатации и обучению ИТ-персонала банка.
Выбор
Прежде чем сделать окончательный выбор, в банке изучали решения от компаний EMC, Fujitsu, CA и HP, причем, помимо технических требований, дополнительным условием было наличие
в портфеле поставщика не менее четырех успешных проектов аналогичного масштаба, выполненных на предлагаемом Собинбанку оборудовании и программном обеспечении. Одним из требований к программному обеспечению была возможность работы с оборудованием различных поставщиков, поскольку в Собинбанке эксплуатируется серверная техника компаний HP и EMC.
Победившее предложение предусматривало использование программного обеспечения HP Data Protector 6.0, поддерживающего все серверные платформы и приложения, эксплуатируемые в ИТ-департаменте банка, в том числе различные версии операционных систем Windows Server, Solaris и Linux и различные релизы СУБД Oracle и Microsoft SQL Server. В Data Protector многие настройки могут быть гибко выполнены из командной строки, что позволяет выполнять многие «спорные» операции при помощи специально разработанных сценариев. «Мы предлагали свое решение, исходя из соотношения цены и производительности как для оборудования, так и для ПО. Но помимо этого анализировались еще и вопросы технического обслуживания, – отмечает Андрей Альтергот, директор по развитию бизнеса компании «Инлайн Груп», выбранной в качестве исполнителя проекта. – Мы предложили также клиенту услуги по круглосуточному техническому обслуживанию, с гарантированным временем восстановления системы после сбоя. Эта услуга предоставляется местным центром поддержки HP и распространяется как на оборудование, так и на программное обеспечение». «Наша ИТ-служба только выдвигала требования к проекту, реализация которого полностью легла на плечи интегратора, – отмечает Рябочкин. – Это позволило не только сэкономить время, но и самостоятельно обучить наших сотрудников».
Решение
В состав новой системы хранения данных входят два сервера HP Proliant DL360 G5 и две ленточные библиотеки серии HP MSL 6000 – на 150 слотов и на 120 слотов (см. рисунок). Каждая из библиотек, в свою очередь, состоит из нескольких библиотек, объединенных в стек посредством механизма Pass-Through, который предназначен для передачи кассеты между библиотеками, входящими в стек. Система использует ленточные приводы LTO-4 Ultrium 1840, контроллеры E1200-320 FC Router, а также контроллеры библиотек Library Controller Card.
Непрерывность функционирования системы обеспечивает кластер, созданный на базе двух серверов Microsoft Cluster Server (MSCS), с установленным на нем ПО HP Data Protector Cell Manager.
Данные на лентах одного пула (всего их 21) имеют одинаковое время хранения, а ленты, входящие в пул, не переходят границ физической библиотеки. Четыре пула с недельным сроком хранения данных состоят из 30 лент, четыре пула со сроком хранения данных в один месяц – из 18, два пула со сроком хранения данных в полгода – из трех, четыре годовых пула – также из 18 лент, и два пятилетних пула – из 8. Кроме того, имеются 4 резервных пула из 48 лент. Еще один, специальный пул был создан для резервного копирования внутренней базы данных HP Data Protector, он занимает две первые ленты в библиотеке MSL1_1. Такая виртуализация ресурсов библиотек позволила выделить каждому критически важному приложению по несколько пулов лент как для оперативного, так и для долговременного хранения резервных копий, и в то же время обеспечила высокую эффективность использования ленточных приводов LTO-4, каждый из которых обслуживает несколько пулов и самих физических библиотек.
Для интеграции программного обеспечения HP Data Protector на клиентские машины были установлены соответствующие интеграционные агенты, позволяющие проводить процедуры резервного копирования в режиме онлайн. Установка интеграционных агентов производилась одновременно с подключением к системе клиентских машин. Всего используется три типа интеграционных агентов: для СУБД Oracle, для СУБД Microsoft SQL Server и для Microsoft Exchange Server.
Для резервного копирования данных с серверов, находящихся на удаленной площадке, используется внешний ленточный привод HP StorageWorks LTO-4 Ultrium 1840, подключенный к серверу по SCSI-интерфейсу. Повышение уровня безопасности на данном ленточном приводе достигается за счет включения режима аппаратного шифрования данных. Агенты Data Protector инсталлированы на 80 серверах, включая продуктивные, тестовые и резервные серверы: несмотря на то что для тестовых и резервных серверов резервное копирование не производится, для них нужно обеспечить возможность восстановления данных продуктивных серверов с резервной копии.
Политики
Проработкой политик хранения данных в Собинбанке начали серьезно заниматься более двух лет назад, когда в банке появилась первая система хранения и пришло время задуматься о стоимости хранения данных, о скорости доступа к данным и способах их перемещения. Резервируемые данные стали делить на разделы в зависимости от регламентированной скорости восстановления.
Сейчас в большинстве систем банка на восстановление данных после логических сбоев уходит около часа, а для самых крупных объемов копируемых данных порядка 1 Тбайт время восстановления может быть увеличено до четырех часов. Например, для аналитического хранилища (его объем сейчас порядка 1,3 Тбайт) нормативное время восстановления из любой ситуации составляет восемь часов, но обычно оно существенно меньше. В любом случае, за восемь часов созданная инфраструктура позволяет полностью справиться практически с любым сбоем, что не намного меньше, чем в прежней системе хранения, однако в новом решении обеспечивается большая глубина восстановления. Например, для аналитического хранилища в прежнем варианте делалась только одна копия, на сутки назад.
С самого начала проекта было очевидно, что глубина хранимого архива будет зависеть от конкретных требований к системе, определяемых ее политикой резервирования. Приступая к проекту, технические специалисты банка не имели навыков формирования политик, поэтому в тендер были включены также предложения по типовым вариантам подобных регламентов резервного копирования.
Для каждой системы определяющими являются требуемая скорость восстановления и его желаемая глубина. Исходя из этого может быть рассчитан период, за который могут накапливаться журналы логов, которые потом будут «накатываться» на соответствующую архивную копию. Как правило, в течение недели хранятся полные копии базы с интервалом в один или два дня. Однако некоторые системы практически не испытывают пользовательской активности, например справочные системы, и для них полную копию («снимок») достаточно делать раз в неделю. Что касается глубины архива, то считается, что достаточно хранить архивы за последнюю неделю – подавляющее большинство логических ошибок успевает обнаруживаться за это время.
Отдельной задачей является хранение исторической информации. В банковской сфере принято хранить ежемесячные копии базы (на момент завершения всех операций по «закрытию» месяца), а также годовую копию.
Важным моментом определения политики резервирования является так называемое «окно резервирования» – время, в течение которого активность работы в системе наиболее низкая или полностью отсутствует и операции копирования могут быть выполнены максимально быстро. В Собинбанке одного такого технологического «окна» для всех систем нет – имеются банковские системы круглосуточного доступа, и есть целая сеть филиалов, которые разбросаны по всей стране, в разных часовых поясах. Первый, самый восточный филиал банка начинает работать в 3 часа ночи, когда в центральном офисе в Москве еще не закрыта операционная касса. Поэтому можно сказать, что копирование продолжается круглые сутки. Для каждой системы определяются свои пики и спады нагрузок, но в любом случае основная часть операций копирования выполняется в ночное время. Такое разнесение операций во времени позволяет разгрузить сеть и повысить ее производительность.
Специалисты «Инлайн Груп» разработали для разных ситуаций и задач защиты данных более 100 сценариев резервного копирования и восстановления для баз данных Oracle и Microsoft SQL Server, почтовых серверов Microsoft Exchange и файловых серверов. В расписании прописываются различные типы заданий: ежедневные, еженедельные, ежемесячные и ежегодные. Ежедневные выполняются каждый день, кроме ночи с субботы на воскресенье; еженедельные выполняются раз в неделю в ночь с субботы на воскресенье; ежемесячные выполняются первого числа каждого месяца. Для того чтобы исключить выполнение ежедневных и еженедельных заданий первого числа каждого месяца, в настройках эти дни объявлены как праздничные. Для спецификаций, которые должны выполняться раз в год, время выполнения в автоматическом режиме не задано – эти задания выполняются администратором.
Тестирование
Обычно при приобретении нового оборудования заказчики стремятся предварительно его протестировать, чтобы убедиться в соответствии поставленным задачам, однако в Собинбанке испытывать оборудование не стали. По мнению Рябочкина, брать оборудование на тестирование имеет смысл, когда надо измерить производительность приобретаемой техники на конкретной прикладной системе и когда такое сочетание оборудования и ПО уникально. В этом случае проведение предварительных нагрузочных тестов позволит убедиться в том, что необходимые бизнес-задачи могут быть действительно решены. В отношении ленточной библиотеки Собинбанка уникальных операций и требований не было, и для операций копирования производительность определялась достаточно просто. Все оборудование, согласно представленным спецификациям, удовлетворяло заявленным характеристикам, а совместимость техники и программного обеспечения уже была доказана производителями и зафиксирована документально. Производительность системы хранения заведомо превышала заданные параметры – при необходимости копировать ежедневно по 5 Тбайт данных реально система могла справиться с копированием 8 Тбайт.
Экономия и детали
Сегодня много говорится о возможности сэкономить, используя ПО или оборудование на условиях аренды, однако в банковской сфере, как утверждает Рябочкин, такое решение неприемлемо. Во-первых, чужую инфраструктуру очень сложно контролировать, и это учитывается при прохождении банковского аудита. В частности, Собинбанк одним из первых в Москве прошел международный аудит по PCI DSS (сертификация информационной системы на соответствие международному стандарту защиты информации в индустрии платежных карт Payment Card Industry Data Security Standard). Это достаточно сложная проверка, содержащая порядка 200 требований по безопасности и, в частности, включающая в себя параметры, касающиеся хранения данных. Если банк берет в аренду чужую инфраструктуру, то этим требованиям он удовлетворить не может. В ближайшее время эти требования станут обязательными для всех банков в России, и за их нарушение предусмотрены серьезные штрафы, вплоть до лишения статуса принципала в процессинговых системах. Во-вторых, по словам Рябочкина, в России пока нет провайдера, готового предоставлять подобные услуги достаточно высокого качества, а вывод банковских данных за границу не может быть одобрен российскими регулирующими органами.
Несмотря на тщательную проработку всех деталей, редкий проект обходится без сюрпризов и непредвиденных проблем. В Собинбанке одновременно выполнялось несколько проектов консолидации, в частности параллельно шел проект консолидации серверов приложений с использованием технологий виртуализации, в масштабе примерно 1 к 8 (из восьми серверов собирали один). Эти серверы также необходимо резервировать, что потребовало дополнительной интеграции с инфраструктурой VMware, однако в первоначальных требованиях к системе хранения эта возможность не была оговорена, и, чтобы эти условия выполнить, пришлось перестраиваться «на ходу».
Резервирование и восстановление серверов приложений имеет свои особенности. Такие серверы не содержат данных, их основная ценность – настройки. В самой среде VMware предусмотрено восстановление настроек с инфраструктурного сервера, где хранятся копии серверов приложений. Однако на случай возникновения серьезной логической ошибки или выхода из строя самого инфраструктурного сервера необходимо предусмотреть возможность восстановить эти настройки с резервных копий, которые тоже хранятся на ленте. Изначально такая возможность не предусматривалась – по условиям тендера речь шла только о базах данных и файловых серверах, то есть о бизнес-данных. Однако Собинбанку удалось решить эту проблему.
Интеграция HP Data Protector с VMware производится с использованием системы VMware Consolidated Backup (VCB) и proxy-сервера под управлением Windows, на которой запускаются сценарии, управляющие работой VCB. Для этого на proxy-сервер устанавливается специальное программное обеспечение VMware Consolidated Framework. Процесс резервного копирования виртуальных серверов выполняется в три этапа: создание моментальных снимков виртуальных машин; копирование снимков виртуальных машин на proxy-сервер; сохранение снимков виртуальных машин с proxy-сервера на ленту.
За рамки проекта по модернизации системы хранения была вынесена и задача криптозащиты данных. Согласно международным банковским требованиям безопасности, все данные, хранящиеся на лентах, должны быть зашифрованы, хранение в «открытом» виде не допускается. В рамках тендера требования по шифрованию данных не выдвигались, и поскольку поставщики ориентировались на минимальные требования, то лицензии на модуль шифрования предложены не были. Их пришлось приобретать отдельно.
Результаты
Сегодня в Собинбанке все критичные бизнес-системы резервируются на единую систему хранения. На дисковых массивах хранится только последняя резервная копия данных, что позволило высвободить емкости для оперативных данных приложений. В ближайшее время в банке завершится очередной проект по консолидации, и все региональные филиалы начнут работать в централизованных информационных системах. Таким образом, все значимые для банка транзакционные данные будут размещаться в единой системе хранения данных. Расчетное время эксплуатации новой системы – пять лет.
Собинбанк был основан в декабре 1990 года, и сегодня это универсальный финансовый институт, предлагающий широкий спектр банковских услуг частным и корпоративным клиентам. Сеть обслуживания банка состоит из 24 филиалов и 81 обособленного подразделения, включая дополнительные офисы и операционные кассы более чем в 30 городах страны. Клиентами Собинбанка являются более 200 крупнейших российских компаний, свыше 25 тыс. субъектов малого и среднего бизнеса и около 1 млн частных клиентов в Москве и 23 регионах Российской Федерации, Казахстане и на Украине. С октября 2008 года Собинбанк входит в группу компаний Газпром.
Ленты против дисков
Дисковые системы резервирования имеют высокую производительность и обеспечивают более оперативное, чем ленты, восстановление и копирование данных, однако, по мнению Максима Рябочкина, начальника управления эксплуатации банковских систем ИТ-департамента Собинбанка, сейчас на рынке практически не представлены дисковые подсистемы необходимой емкости и производительности, совместимые с сетью хранения, и в ценовом диапазоне, сопоставимом с ленточными системами. Мало того, на рынке нет сетевых систем хранения (Network Attached Storage, NAS) объемом в 200 Тбайт, а согласно результатам тестирования, копирование на NAS-серверы 1 Тбайт данных в нагруженной сети занимает около суток, что было неприемлемо. Чтобы обеспечить достаточную скорость доступа, Собинбанку требовалась система, построенная по технологии SAN.
С другой стороны, на рынке имеются высокопроизводительные решения старшего класса, например от Hitachi, предназначенные для крупных корпораций и процессинговых площадок вроде Visa, однако стоимость таких систем отличается в разы, даже с учетом того, что для них применяются другие схемы лицензирования. Кроме того, нелегко найти специалистов, способных обслуживать системы такого уровня.
Исходя из этих соображений, для Собинбанка имело смысл искать решение лишь из числа дисковых массивов среднего уровня, однако, согласно произведенным оценкам, стоимость только одной такой дисковой системы емкостью в 200 Тбайт была бы в несколько раз выше, чем стоимость всей ленточной библиотеки «под ключ», с учетом ее сопровождения в течение трех лет.
Помимо меньшей прямой стоимости, ленточные системы имеют и другие преимущества. Для примера можно сравнить параметры дисковой и ленточной систем резервирования на некоей условной базе данных объемом Х Гбайт. Дисковой системе, для того чтобы обеспечить достаточный для банка уровень защиты от логических ошибок, нужен, во-первых, «горячий» резерв (stand-by) размером еще Х Гбайт. Необходимо также место для создания резервной копии и хранения еще хотя бы трех копий для обеспечения недельной глубины резервирования (если полные копии делать через день, а каждые два дня накапливать инкрементальный резерв, то есть журналы (логи), по которым можно с какой-то из этих копий за разумный период времени восстановить базу на тот момент, когда пользователь совершил ошибку). Таким образом, необходимо иметь на диске объем, примерно в шесть раз превышающий объем самой базы данных.
Когда имеется ленточная система резервного копирования, достаточно иметь на диске основную базу, «горячий» резерв и место для хранения одной резервной копии (затем эта копия сбрасывается на ленту). Таким образом, требуется вдвое меньше объема, чем у дисковой системы.
