Уникредит ще осигури непрекъсвамост на бизнеса през 2008 г.
За предизвикателствата пред ИТ в банковия сектор разговаряме с Кристин Крумов, директор Управление „ИТ операции”/дирекция ИТ в UniCreditBulbank.
Как изглеждаше сливането на трите банки в една от гледна точка на информационните технологии?
Със сливането на трите банки – Булбанк, Биохим и Хеброс, започна интеграцията им. В края на 2005 г. предприехме оценка, уточняване на проекта и избор на решение. Действителната работа стартира през май 2006 и приключи юли 2007 г. В този период изцяло се промениха инфраструктурата, приложенията на банката, комуникацията и т.н. Основното приложение на банката е FlexCube. Разбира се, има и много други приложения, част от които работят във Виена и ние ги ползваме отдалечено.
Двамата ни доставчика на услуги са реализирали мрежи от типа full mesh по MPLS (Multiprotocol Label Switching) технология, която осигурява свързване на всяка точка на банката през двата ни доставчика с двата центъра за данни – основния и резервния. При отпадането на кой да е от тях или на някоя от двете комуникационни линии се запазва връзката между клоновете. Има и оптичен канал между двата центъра, който се използва за връзка при отпадане на някой от центровете за данни, както и вътрешно – за репликиране на данните от единия към другия център. И двата дейтацентъра засега са в София, но това е временно решение, продиктувано от възможността да се използват наличните ресурси от центрове на обединилите се банки. От шест наследени дейтацентрове в момента сме ги намалили на четири. Следващата стъпка е да ги намалим на три, като третият е за така наречените стари системи и е малък по мащаб. Двата най-големи са поели основния и бекъп центъра на обединената банка. Идеята обаче е единият да бъде изместен географски извън София на разстояние, което ще позволи да запазим технологията, която използваме в момента за репликиране на данните, но разстоянието да е над 40 км, т.е. определили сме диапазон от 40-70 км. В момента проучваме възможностите за такава локация, в която просто ще пренесем апаратурата и ще установим дейтацентър с минимум усилия. Това е важно, за да запазим значителните инвестиции в интеграцията.
Какви технологии използвате за възстановяване след бедствия?
За възстановяването след бедствие използваме няколко технологии – основната система има два сториджа в двата центъра. Базата данни на приложението в основния център работи върху Oracle Cluster, който онлайн се репликира с LVM (Logical Volume Management) технология на IBM към центъра за възстановяване, където отново с технологии на IBM (High Availability Cluster Multiprocessing - HACMP) е изграден трети възел на клъстъра на базата данни, така че при нужда тя да може да се „вдигне” веднага. Тоест това е решение от типа High Level Duty. Имахме известен горчив опит, затова допълнително върху това решение за резервиране сме надградили още една технология, реализирана с инструменти на Oracle – това е репликация с Oracle Data Guard. С нея се прави второ копие на базата данни върху същата машина в бекъп центъра, но с други средства. Така че имаме „живи” и в режим на непрекъсната синхронизация с основната база данни две нейни копия, направени с различни средства. Едното е с висока степен на достъп (high availability), а другото с максимална.
Дотук говорихме за базата данни. Следващото ниво са клъстерите на приложенията – то също е резервирано между двата центъра, като тук прилагаме балансьори на натоварвнето между осемте сървъра за приложението. То има клонова и централна част. Това са касовите транзакции. Именно за тях е технологията за автоматично разпределяне на натоварването от потребителите. Респективно в случай на срив се включват други осем сървъра, които са в standby режим. Те се превключват ръчно. При базата данни, въпреки че имаме възможност за автоматично вдигане, също сме избрали ръчното. Преценката ни е, че така процесите се управляват по-добре.
Другите приложения също са в основния център, като за тях имаме отделни системи за съхранение и те също се репликират на втори машини. Тук бекъпът е на ниво сторидж. Това означава, че процесът предполага повече човешка намеса, тъй като сме преценили, че тук времето за вдигане не е толкова критично, докато за основното приложение времето ни за превключване от единия към другия център е половин час. Комуникациите превключват веднага. За вдигане на базата данни са ни необходими 10-15 минути, проверяваме консистентността й, въпреки че механизмът за репликиране я гарантира, следва насочване на сървърите за приложения към работещия център. Тоест за този половин час всичко е възстановено и работи.
Какви са плановете ви за тази година?
Възстановяването след бедствие е сбор от технологии и процедури за превключване от основния към резервния дейтацентър и обратно връщане, както и комплект от договори с доставчиците. Всичко това е част от един по-голям проект на банката за непрекъсваемост на бизнеса (business continiuty), който в момента е в ход. Целта е да се види как бизнесът ще реагира на подобни ситуации. Ние обикновено си говорим в термините на машини - има ли ги, няма ли ги. Какво ще се случи, ако нещо го няма? Много процеси в банката се изпълняват на повече от една система и какво ще се случи, ако част от процеса го има, а друга не. Бизнесът трябва да може да работи включително и в такава ситуация. И затова освен преместването на разстояние на дейтацентъра тази година ще завършим и проекта за непрекъсваемост на бизнеса.
