Cервисы
Managed IT
Решения
Security
Импортозамещение
О компании

Metrocluster для АКБ Алефбанк. Интервью с Валерием Бородиным

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

Валерий, расскажите, какая задача стояла перед банком?

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

Какие варианты оборудования вы рассматривали?

Рассматривались разные варианты. Это были EMC, IBM Storwize 8000, NetApp и еще несколько более-менее известных железок.

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

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

Валерий, данные каких приложений Вы планировали защитить?

Основная задача – это CIFS хранилище.

Почему для Вас важна отказоустойчивость хранилища файлов? И каким образом она была достигнута?

Данные всех приложений, в том числе чисто банковских, являются файлами. Отчетность перед ЦБ, написанная в клико, банковская программа, другие служебные данные — это все набор файлов, хранящихся на общем файловом сервере. Вообще без общего файлового сервера сложно представить работу современного предприятия. Тиражирование файлов для каждого компьютера – это прошлый век. Использование общего файлового сервера — удобная альтернатива. А общий файловый сервер должен быть надёжным.

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

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

Нет. Открытие второй площадки было моей личной инициативой. Использование только одной площадки – неоправданный риск для банковской сферы. Потому что даже от банального «залили водой» сложно подстраховаться, если в вашем единственном дата-центре пожарные тушат пожар. Также никогда нельзя исключать нежелательные действия третьих лиц, когда по какой-либо причине к вам приходят и физически начинают что-то уничтожать. Такого класса простои недопустимы для бизнеса!

Ваши дата—центры отделены от рабочих мест пользователей?

Нет. ЦОДы находятся в пределах офисов, в двух соседних зданиях. Вероятность крушения двух зданий все же меньше J. Стоит отметить, что NetApp Metrocluster поддерживает расстояние до 300 км. Так что это решение подходить для глобальных компаний.

Какой максимальный простой допустим в работе поддерживаемых приложений?

У нас существует отдельный SLA на выполняемые задачи. Прежде всего, это выдача банковских карт и отправка отчетности в ЦБ. По выдаче карт допустимая задержка составляет примерно 30 минут, по отчетности в ЦБ — 2 часа.

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

Валерий, скажите, сколько пользователей сейчас работает с приложениями и файлами?

Чуть меньше 200 пользователей. И данное количество для выбранной модели смехотворное.

Какую конфигурацию оборудования вы выбрали в конечном итоге?

Нами было выбрано решение NetApp FAS 3220. Это минимальный уровень оборудования, которое поддерживает Metrocluster. Исходя из существующих задач и нагрузки, создаваемой пользователями, производительности данной модели точно хватит года на 4. Хочу отметить, что мы сразу установили 10-гигабитные адаптеры, благо машина это позволяет.

А какая система хранения данных у Вас была раньше?

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

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

Во-первых, это архитектура решения, предлагаемая производителем. У IBM и EMC – это блочное хранилище, поверх которого прикручен файловый сервер и на это блочное хранилище смотрит. В таком решении есть свои плюсы и минусы. Говорить об идентичности данных на двух площадках тут нельзя. Да, данные будут синхронизированы, но говорить, что данные будут одинаковы нельзя. Файловый сервер при приеме ваших данных записывает их на блочную часть. Эта блочная часть будет полностью синхронна, но существует временной разрыв между моментом, когда сервер получил данные, и когда эти данные действительно приняты к записи.

Такие системы достаточно надёжны! Ничего плохого про них сказать не могу, но вот этот разрыв есть.

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

Нет. Это дополнительная удобная фича, которая снимает нагрузку с администратора. Пользователь не обращается к системному администратору, а может самостоятельно восстановить данные.

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

А как настроен график снапшотов, как часто вы их делаете?

График снапшотов озвучить возможно. Делаются они в рабочее время, с 10:00 до 19:00. Соответственно, 4 снимка: в 10, в 12, в 16 и в 18. Кроме того, снимок делается в полночь. Дневные снапшоты хранятся за три последних дня. Ночные снимки хранятся за две последние недели. Воскресные полуночные снимки хранятся за восемь недель. То есть пользователь может найти данные восьминедельной давности.

Используете ли вы ещё какое-то программное обеспечение NetApp?

При выборе системы хранения я внимательно изучал политику ценообразования. У NetApp единственная лицензия, которую можно получить бесплатно, это любая лицензия. Но только одна! Соответственно, так как у меня основная лицензия CIFS, выбор пал на неё. А с недавнего времени, начиная с восьмой версии Metroclusterа, лицензия Metroclusterа бесплатна. Я использовал единственную лицензию CIFS, к которой прилагаются бесплатные снепшоты, бесплатная лицензия Metrocluster, NFS и другие хорошие функции.

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

Есть ли у Вас зарезервированные сервера на данных площадках? Можете поподробней рассказать про архитектуру вашего отказоустойчивого решения?

Файловое хранилище представляет собой NetApp. Один контроллер NetApp на одной площадке. Второй контроллер NetApp на второй площадке. Наборы полок в ЦОДах идентичны. Если мы говорим в целом о банковской системе, то на каждой из площадок есть свои сервера, есть свои блочные хранилища, которые их обеспечивают. И между этими блочными хранилищами есть синхронная репликация критично важных данных.

А пользователи напрямую за файлами обращаются?

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

Валерий, вы сказали, что у вас внедрена двухконтроллерная конфигурация, по контроллеру на каждой площадке. NetApp 3220, 10 гигабитные порты, адаптеры. А сколько полок вы выбрали?

Классически количество винчестеров на одной стороне площадки должно соответствовать их количеству на другой стороне площадки. И можно было обойтись одной полкой на каждой стороне: одна полка с одной стороны, одна полка с другой стороны. Половина дисков первой полки в первом ЦОДе была бы продублирована половиной дисков на другой, и, соответственно, зеркально в противоположную сторону. Но есть при таком варианте одна уязвимость — отказ полки.

Поэтому мы выбрали вариант, при котором  в каждой голове установлено по 2 дисковые полки, по 16 дисков с одной и с другой стороны. Соответственно, первая и вторая полки в первом ЦОДе дублируются первой и второй полками во втором ЦОДе.

Присутствует некая параноидальность, тем не менее, сохранность данных гарантирована в большей степени.

А какие полки используются?

SAS 10000 RPM. Крайне высокая производительность не требуется, а используемый вариант предоставляет высокую надежность.

Валерий, используете ли вы дедубликацию и компрессию. Какие результаты даёт эта функциональность?

Дедубликацию следует использовать всегда. Технология, предложенная NetApp, позволяет дедублицировать данные в объёме 4 килобайтного блока. Выглядит незначительным числом. Но когда таких блоков набирается много, получается заметный прирост. То есть 20% экономии в самом худшем случае вы однозначно получите!

Какой у Вас на текущий момент процент дедубликации?

По одному хранилищу дедубликация 11%, компрессия 9%, итого сохранено 18%. По другому хранилищу дедубликация 32%, компрессия 69%, сохранено 73%. И по ещё одному 24% дедубликации, 14% компрессии, итого 32%!

А вот использовать компрессию следует не всегда. Есть удобные таблицы от NetApp, которые показывают, когда ее лучше использовать. Например, если вы храните потоковое видео, компрессировать его абсолютно бессмысленно.

Величины компрессии для разных видов данных, %

Файловые сервисы и инфраструктура
50%
Виртуальные сервера и десктопы
55%
Базы данных Oracle OLTP
65%
Oracle DW
70%
MS Exchange 2003/2007
35%
MS Exchange 2010
35%
Инженерные данные
55%
Геосейсмические данные
40%
Архивные данные
различная
Данные резервных копий
различная

Величины дедубликации для разных видов данных, % 

Файловые сервисы и инфраструктура
35%
Виртуальные сервера и десктопы
70%
Базы данных Oracle OLTP
0%
Oracle DW
15%
SQL Server
20%
MS Exchange 2003/2007
3%
MS Exchange 2010
15%
Инженерные данные
30%
Геосейсмические данные
3%
Архивные данные
25%
Данные резервных копий
95%

Валерий, как происходила инсталляция решения, как планировался и как реализовывался этот процесс?

Интересные моменты всегда появляются, если не почитаешь документацию! Если почитаешь, все пройдет гладко J Был один нюанс. Недочет в документации самого NetApp. NetApp допустил ошибку в документации по настройке Metrocluster при отказе плеч на разных VLAN в разных сетях. Но специалист по настройке NetApp помог нам устранить этот недочет.

Сколько по времени заняла настройка?

Где-то 3 дня.

После установки вы смигрировали данные с текущей системы данных?

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

Довольны ли Вы сделанным выбором?

После установки FAS 3220 прошел уже год. Нареканий нет. Решение полностью справляется с нашими задачами.

Могли бы Вы рекомендовать решение либо NetApp либо Metrocluster вашим коллегам, работающим в других банках?

Рекомендовать я его могу! Более того, если вы используете VMware, то VMware и NetApp отлично дружат. При использовании протокола NFS при работе виртуальных машин достигаются определённые плюсы.

Проводили ли Вы тестирование хранилища?

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

Если у вас тысяча человек персонала, и всё достаточно компактно организовано, то придумать нагрузку и что-то на ней протестировать, это просто себя обмануть! Тестирование – вещь нужная! Но только на него опираться не стоит.

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

Критерий выбора один – это чёткое понимание того, чего вы действительно хотите! И во главу нужно ставить не объем хранимых данных, а архитектуру и принцип работы решения. Емкость всегда можно сделать больше! А к анализу задержек и скорости обработки данных нужно подходить более обдуманно. Нужно посмотреть, проанализировать текущую нагрузку. Какие очереди она порождает, какие очереди впереди на запись, на чтение? Как это всё выглядит?