ЦОД - панацея? Одного ЦОД недостаточно

В последние годы идет бурный рост объема и спектра услуг, оказываемых банками как юридическим, так и физическим лицам, повышается качество сервиса. В частности, развивается кредитное направление, формируются различные фонды (в том числе ПИФы), совершенствуются системы "Банк—Клиент" (электронный банкинг) и т. п.

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

Все это приводит к тому, что информационные системы финансовых организаций выходят на предел своих возможностей.

Кажется логичным следующий выход из положения:

1. установить в одном помещении необходимое количество серверов с соответствующим ПО и устройств хранения, предусмотрев резервирование критически важных узлов;
2. объединить все это оборудование в единый центр обработки данных (ЦОД), предусмотрев дублирование каналов передачи данных и обеспечив необходимую защиту от несанкционированного доступа извне.

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

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

После решения всех текущих технических проблем (определение объема основного хранилища, производительности серверов, способов и каналов подключения к провайдерам) и определения перспектив их роста на первое место выходят проблемы обеспечения непрерывности бизнеса, совместимости нового оборудования и закупленного в 1990-е годы, преемственности ПО, квалификации персонала, эксплуатационных расходов и т. д.

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

Таким образом, при проектировании ЦОД необходимо принять во внимание следующие моменты:

• используемое ПО, перспективы его модернизации, его требования к аппаратному обеспечению и к каналам, количество внутренних пользователей, наличие возможности работы внешних пользователей;
• количество клиентов банка, требуемые объемы хранимой информации, перспективы их роста, сроки и объемы долговременного хранения архивной информации;
• наличие сети филиалов, необходимость совместной работы с единой БД, удаленность филиалов, характеристики каналов связи;
• допустимое время простоя при авариях, допустимые потери данных, наличие планов ВСР (Business Continuity Plan, план обеспечения бизнеса) и DRP (Disaster Recovery Plan, план восстановления после аварий); способы решения проблем, предусмотренные в планах;
• текущий уровень информационной безопасности (ИБ), возможность и необходимость его повышения, требования к шифрованию данных (как передаваемых по каналам связи, так и хранящихся в БД и архивах), требования к антивирусной защите;
• наличие старого и/или устаревшего оборудования, необходимость его использования, возможность модернизации и/или утилизации;
• наличие и квалификация персонала как самого ЦОД, так и удаленных филиалов, возможности набора нового персонала и обучения имеющегося;
• наличие помещений под оборудование, степень их готовности, наличие "правильного электропитания, кондиционирования, средств безопасности;
• текущие эксплуатационные расходы (аренда помещений, заработная плата персонала, плата за энергопотребление, водоснабжение), возможность их роста.

Рассмотрим подробнее некоторые из перечисленных выше моментов и практические способы их решения.

Высокие эксплуатационные расходы

Плотность застройки в городах, ограничения по подводимой мощности, сложности с подбором помещений — все это приводит к увеличению как разовых расходов (например, построение системы электропитания с ДГУ), так и долговременных (рост арендной платы).

Решением проблемы может стать применение при построении ЦОД серверов с новыми процессорами, выпущенными с использованием энергосберегающих технологий, а также уменьшение числа физических серверов за счет технологий виртуализации и blade-серверов, применение дисков Solid-state drive (SSD) вместо традиционных НЖМД.

В качестве примера можно привести следующее сравнение.

В настоящее время компания HP выпускает два типа серверов с процессорами Quad-Core Intel Xeon X5460 (3,16 ГГц, 1333 МГц, 120 Вт): ProLiant BL460c Server Blade и ProLiant DL360 Generation 5 (G5). Серверы BL460c устанавливаются в шасси, занимающее 10 юнитов и вмещающее до 16 серверов. В максимальной комплектации шасси весит 236 кг, потребляет около 6400 Вт, тепловыделение составляет приблизительно 22 000 БТЕ. Аналогичное по производительности число серверов DL360 G5 весит 288 кг, потребляет около 13 700 Вт и имеет тепловыделение около 46 000 БТЕ.

В декабре 2002 г. компания HP прекратила выпуск одного из самых массовых в свое время серверов Compaq ProLiant DL360 с процессорами Intel Pentium III

1,26 ГГц. Условно примем, что для обеспечения аналогичной серверу BL460c производительности необходимо использовать четыре сервера DL360. В этом случае потребовалось бы 4 х 16 = 64 сервера, которые весили бы 832 кг, потребляли около 18 700 Вт, тепловыделение составляло бы около 63 800 БТЕ и занимали бы они примерно 1,5 стойки.

Разница, как говорится, налицо.

Таким образом, применение новых технологий позволяет заменить 1,5 стойки оборудования, потребляющие около 20 кВт, на блок, занимающий 10 юнитов в стойке и потребляющий около 7 кВт. При этом в состав блока уже входят коммутаторы для организации связи как с локальной сетью, так и с сетью хранения данных.

Отказоустойчивость, катастрофы

Одна из проблем обеспечения непрерывности бизнеса — обеспечение отказоустойчивости сервисов, повышение их способности сопротивляться масштабным катастрофам. Если локальные катастрофы (протечка воды, заморозки, землетрясение) можно решить техническими средствами, то глобальные решаются сочетанием технических и организационных мер.

В мае 2005 г. из-за сбоя на подстанции и резкого скачка нагрузок в Москве и ряде других энергосистем страны произошло веерное отключение электроэнергии. Общий материальный ущерб столицы от этой аварии составил 1,7 млрд руб. Избежать этого можно было бы с помощью удаленного резервного ЦОД (РЦОД), находящегося, например, на другом конце города и получающего электроэнергию от другой подстанции. Тем не менее при подобном веерном отключении питания имеется вероятность остановки и резервного ЦОД.

Необходимо тщательно проанализировать возможность катастроф, их влияние на доступность предоставляемых сервисов и предполагаемые убытки. В том случае, если убытки могут быть значительными, имеет смысл построения РЦОД даже в другом городе.

В частности, в практике компании Открытые Технологии осуществлено несколько проектов резервных ЦОД для обеспечения требуемой защищенности сервисов и сохранности данных. Кроме реализации отказоустойчивого решения в основных центрах обработки данных, были разработаны и созданы резервные на расстояниях в 60 и 250 км. В соответствии с задачами, поставленными заказчиками, были определены критичные сервисы, проработаны процедуры как удаленной синхронизации баз данных, так и переключения пользователей.

И самое главное, для скорейшего восстановления работы сервисов необходимо иметь четко продуманный план действий — план ВСР и DRP. При отсутствии этих планов, без проведения тренировочных мероприятий восстановление работоспособности бизнеса может занять неоправданно длительное время и оказаться критичным для предприятия.

Информационная безопасность

Проблемы, связанные с информационной безопасностью (ИБ), являются отдельной "головной болью". К ним относятся и несанкционированный доступ к информации, и ее искажение, и утечка данных. В данной статье эти проблемы подробно не рассматриваются, тем не менее необходимо отметить их важность для уверенного ведения бизнеса.

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

Согласно статье В. Ульянова "Непрерывность бизнеса по-новому", "по данным российской компании Perimetrix, существенная доля утечек информации происходит в результате утери или кражи мобильных накопителей" (Электроника экспресс. 2008. № 158 (03). С. 14-21). Применение "тонких клиентов" (например, SUN Ray, HP t5000 или Neoware) позволяет значительно снизить возможность копирования информации на эти самые катастрофически теряемые накопители.

Немаловажной составной частью общей политики ИБ является криптографическая защита данных, как архивных, так и передаваемых по каналам связи. В отношении последних особое внимание необходимо уделить информационному обмену по общедоступным каналам связи. Интерес к ним обусловлен высокой стоимостью, а порой и отсутствием физической возможности реализации защищенных выделенных трактов передачи банковской информации. Шифрование данных в этом случае выступает как обязательное требование. На данный момент существует несколько государственных стандартов РФ в области криптографической защиты информации (ГОСТ 28147-89, ГОСТ Р 34.10-2001, ГОСТ Р 34.11-2001), активно функционирует система сертификации средств криптографической защиты информации под руководством ФСБ России. На рынке имеются сертифицированные решения, позволяющие реализовать защищенный информационный обмен через открытые каналы. Ведутся разработки новых продуктов и совершенствуются стандарты и алгоритмы.

Системы управления

Большое количество разного оборудования требует либо соответствующего числа системных администраторов, либо — при постоянном дефиците кадров и ФЗП — мощной системы централизованного управления (СУ).

В качестве примеров подобных СУ можно привести Big Brother, HP Open-View, IBM Tivoly, Micromuse NetCool, CA SPECTRUM, комплекс EMC SMARTS. Перечень можно продолжать, но в любом случае все зависит от размеров ИС и потребностей предприятия.

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

Предыдущая новость:
Суперкомпьютеры в России Следующая новость:
Новый игрок на рынке контакт-центров в России