Этот банк объединяет более десятка региональных отделений, а также региональные отделения других банков, выступающих под другой торговой маркой, но работающих в рамках одной финансовой организации. Сейчас перед банком встала очень важная задача - создать единый центр обработки данных, чтобы все транзакции обрабатывались в одном месте. Существовавший ранее ЦОД брал на себя обработку данных только одного банка с его региональными подразделениями, а транзакции с другими банками выполнялись в "полуручном" режиме. Такая схема работы не устраивала банк. Необходимо было сформировать единый центр обработки данных в Москве, в который стекалась бы информация обо всех финансовых транзакциях. Основные требования к новому центру обработки данных - повышенная надежность и отсутствие единой точки отказа. Требуемый объем хранимой информации составлял около 3 ТБ, с увеличением в четыре-пять раз в течение пяти лет.

Решение

Реализация данного проекта была доверена компании "Аквариус" и одному из российских системных интеграторов. "По договоренности с системным интегратором основную часть по созданию центра обработки данных, касающуюся оборудования, взяла на себя наша компания. У нас уже было готовое решение, обкатанное на других проектах", - говорит директор НТЦ группы компаний "Аквариус" Владимир Ткачев.

Решение в первую очередь включало NLB-кластер на двух четырехпроцессорных серверах Aquarius AquaServer P404 с round-robin DNS-сервером AquaServer T114. Эти серверы отвечают текущим требованиям по запросам к базе данных (порядка 20-40 тысяч запросов в день). "Мы провели серию тестов. Взяли базу данных и нагрузили ее соответственно требованиям, - рассказывает Владимир Ткачев. - В результате было решено, что на текущий момент банку достаточно двух узлов в NLB-кластере, и ориентировочно до середины следующего года этих серверов заказчику хватит".

Но кластер - это только одна часть, касающаяся управления запросами к базе данных. Помимо этого стояла задача создания надежного хранилища данных. Соответственно в банке была развернута система SAN, которая базировалась на тех же двух серверах AquaServer P404. Эта система отвечала основному требованию - отсутствию единой точки отказа. Основой системы хранения данных стала система AquaArray A14FCR (две полки). В настоящий момент эта система набита 28 жесткими дисками, общий объем хранимых данных составляет 4 ТБ (эффективный объем 3,2 ТБ). Такое количество дисков обусловлено требованиями зеркалирования RAID 1 для отдельных томов хранимых данных, для других - RAID 5. Кроме того, два диска были выделены для режима горячей замены. При дальнейшем увеличении емкости хранилища потребуется лишь добавлять дополнительные полки AquaArray. При планировании на следующие пять лет объем хранимых данных в банке может вырасти до 12-14 ТБ информации.

Все соединения в ЦОД продублированы. С учетом планируемого расширения кластера (добавления NLB-узлов) установлены два 16-портовых Switch Brocade. "Этот проект отличается не только надежностью, но в первую очередь балансировкой загрузки серверов, - говорит Владимир Ткачев. - А это значит, что ресурсы не простаивают. И одно из основных отличий - хорошая расширяемость. Не имеет значения, какая загрузка будет в будущем, система хранения расширяема до 33,6 ТБ и может поддерживать до 128 хостов, которые можно подключать, а это даже избыточное для текущих задач количество".

Планы

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

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