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

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

Не относится к исключениям и Ингосстрах. На рубеже 2007—2008гг. там была масштабная замена серверов и систем хранения данных. С прежней системы хранения, основу которой составляли массивы среднего класса EMC Clariion CX500, перешли на новую, на базе платформы высшего уровня EMC Symmetrix DMX-3. Тогда же были заменены серверы IBM p690 на IBM sytem p5595. Работы по установке оборудования вела компания КРОК.

Этому способствовало появление обязательного страхования гражданской ответственности владельцев транспортных средств (ОСАГО) в 2003г. Количество автомобилистов, а значит, клиентов страховых компаний, в том числе и Ингосстраха, также увеличивалось быстрыми темпами, что, в свою очередь, вело к лавинообразному росту объемов данных.

Кроме увеличения производительности вычислительных систем и емкости хранения, данная модернизация способствует обеспечению непрерывности бизнеса. Вот что об этом рассказал начальник управления системно-технического обеспечения департамента информационных технологий Ингосстраха Михаил Свистунов: «Принципиальное отличие ЦОД, созданного в 2007—2008гг., от других существующих в нашей компании серверных площадок было в том, что он ориентирован на лучшие мировые практики в области хранения, защиты и оптимизации использования информации. ЦОД спроектирован исходя из условия, что все архитектурные и инфраструктурные составляющие должны сохранять свою актуальность на протяжении длительного времени и быть адаптируемы к появлению новых поколений систем и устройств, относящихся к основному оборудованию. В результате появилась возможность удаленно управлять всем оборудованием, расположенным внутри ЦОД, проводить 80% работ без непосредственного присутствия инженеров и администраторов, обеспечивать постоянный доступ к приложениям, критичным для нашего бизнеса».

Это оборудование в 2009г. подвергалось модернизации, в чем активно участвовали специалисты КРОК. Так, постоянно наращивались емкости систем хранения. Как отметил Михаил Свистунов, при переносе данных и реконфигурации SAN происходила остановка части ИС компании. Но эти работы были спланированы таким образом, что учитывалось время наименьшего использования данных ресурсов: в праздничные и выходные дни, ночное время. В результате приостановка работоспособности практически не отразилась ни на оперативных подразделениях компании, ни тем более на клиентах. На серверах были заменены процессоры с POWER 5+ на POWER 6. Первоначально эту процедуру провели с резервной системой, а затем и с основной.

В результате системы получили по 32 ядра каждая. Михаил Свистунов подчеркнул следующее: «Безусловно, расходы на построение ЦОД, закупку оборудования и прикладного ПО — затратная часть бюджета. Но руководство компании понимало, что именно своевременная модернизация IT-инфраструктуры даст конкурентное преимущество и позволит пережить кризис с минимальными потерями».

Вместе с тем, только модернизация серверов и систем хранения не решила всех задач, связанных с функционированием информационных систем, критичных для Ингосстраха. Вот как оценил ситуацию Владимир Тихомиров, директор департамента информационных технологий компании: «Наша автоматизированная информационная система является бизнес-критичной, ее используют все офисы по всем направлениям бизнеса компании. Жизненной необходимостью стал переход на новую версию СУБД, поскольку старая версия Oracle Database 9i уже не справлялась с рабочей нагрузкой. Ежедневно фиксировались системные ошибки, происходили сбои. А простои даже в несколько минут для компании неприемлемы. Недопустима и ситуация, когда становится сложно получить по запросу необходимую информацию: скажем, если в ответ на запрос фотографий повреждений конкретного автомобиля получают черный квадрат». Причем положение осложнялось тем, что подобного рода миграции в принципе уникальны и в каждом конкретном случае необходимо разрабатывать детальный план перехода и тестирования новой версии.

Совместными усилиями была создана резервная копия данных автоматизированной информационной системы, проведена синхронизация баз данных и составлен поминутный план миграции, предусматривающий восстановление миграции АИС на любой момент времени, если не возникло ошибок и непредвиденных ситуаций. Далее тестировали новую базу данных и подключали к ней всех пользователей Ингосстраха.

Информационную систему перенесли на новую базу данных в течение восьми часов, за одну ночь, незаметно для бизнеса Ингосстраха. После миграции компании потребовался лишь один день опытной эксплуатации и еще сутки по тонкой настройке, чтобы принять решение о полноценном переходе на новую базу данных. Что касается донастройки, то понадобилось заменить клиентские драйверы. И еще, как отметил Михаил Свистунов, была проведена определенная адаптация серверного ПО, что заняло две недели вместе с тестированием.

«В результате миграции мы получили все новые возможности СУБД по поддержке больших баз данных, что фактически сняло любые ограничения на максимальный размер нашей консолидированной базы данных. Обеспечено секционирование, и, таким образом, повысились производительность, доступность и управляемость больших таблиц. При этом не требуется переписывать приложения, оптимизировать распределенные запросы. Сокращается время восстановления при сбоях, а обновление программного обеспечения и приложений не требует остановки работы системы. Но главное — это существенное повышение надежности самой СУБД по сравнению с предыдущей версией. Здесь надо учитывать специфику нашей системы: толстый слой серверного ПО, значительная доля данных в оперативном доступе, одновременная работа пользователей с одними и теми же записями, использование практически всех возможностей СУБД. Дополнительно мы получили в руки мощный механизм динамических приоритетов, что дает возможность успешно совмещать на одном инстансе работу OLTP-приложений с оперативной отчетностью. Понятно, что путем только одной замены оборудования мы не добились бы таких возможностей. Более того, требования к производительности оборудования снизились на 25—30% при той же рабочей нагрузке», — так оценил итоги данного этапа проекта Михаил Свистунов.