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

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

Необходимость определения архитектуры постоянной доступности

Финансовое учреждение, с которым мы работали, хотело, чтобы сервисы его цифрового канала были постоянно доступными ( всегда включенными, то есть функционирующими на постоянной основе ). Мы проанализировали возможности приложений и платформ, которые образуют сервисы доступа к каналу, и бизнес-сервисы, которые поддерживают критически важные функции обслуживания заказчиков (вход в систему, просмотр баланса счетов, просмотр недавних транзакций, осуществление платежей и магазин услуг). На рис. 1 показано высокоуровневое представление прикладных систем и связанных системных компонентов для существующих в банке категорий цифровых сервисов. Мы констатировали, что приложения разрабатываются, развертываются и применяются в соответствии с вертикальной моделью (изолированные зоны), а хранилище данных и сетевые компоненты являются совместно используемыми ресурсами в масштабе всего предприятия.

Рисунок 1. Система мобильного и Интернет-банкинга

Мы рассмотрели следующую группу обращенных к заказчику приложений.

• Комплекс веб-серверов, на которых исполняются сервисы Интернет-банка
• Серверы приложений, на которых исполняются мобильные сервисы
• Корпоративные информационные сервисы
• Унаследованные средства безопасности с технологией единого входа в систему
• Корпоративные интеграционные сервисы

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

Ключевые характеристики архитектуры приложений существующей системы:

• Многоуровневая архитектура на основе слабо связанного подхода.
• Использование шаблонов компонентной архитектуры на основе открытых стандартов (Java™ Enterprise Edition и связанные технологии).
• Использование коммуникационных механизмов и протоколов на основе отраслевых стандартов (HTTP, JDBC [Java Database Connectivity], SOAP [Simple Object Access Protocol] и т.д.).
• Следование наилучшим отраслевым методикам в основанной на стандартах среде, реализующей подход на базе сервис-ориентированной архитектуры (SOA) для интеграции и маршрутизации между основными подсистемами посредством интеграционных корпоративных сервисов.

На рис. 2 показан обзор ИТ-архитектуры существующего банковского решения.

Рисунок 2. ИТ-среда, поддерживающая существующую систему мобильного и Интернет-банкинга

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

Основанный на облаке архитектурный подход для постоянно доступных сервисов

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

В случае рассматриваемого нами банка стандартизация, виртуализация и автоматизация играют ведущую роль в предоставлении клиентам постоянно действующих цифровых сервисов на основе следующих принципов:

• Всеобъемлющие системы высокой готовности, все компоненты которых спроектированы с механизмами переключения при отказах, срабатывающими в случае отказа
• Высокая степень целостности данных/информации благодаря устойчивым системным компонентам, которые гарантируют выполнение транзакций клиента
• Отсутствие плановых и неплановых простоев для технического обслуживания любой системы или компонентов приложения

Подход IBM cloud-enabled data center (CEDC) обеспечивает устойчивость на нескольких уровнях архитектурной конструкции:

• IaaS (Infrastructure as a Service - инфраструктура как сервис),
• PaaS (Platform as a Service - платформа как сервис)
• SaaS (Software as a Service - программное обеспечение как сервис).
• BpaaS (Business Process as a Service - бизнес-процесс как сервис)

На рис. 3 показана схема архитектурной модели CEDC.

Рисунок 3. Эталонная модель CEDC и ключевые компоненты, повышающие устойчивость

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

Уровни платформы OSS (Сервисы поддержки операционной деятельности) и BSS (Сервисы поддержки бизнеса) платформы CCMP (Общая платформа управления облаком) помогают поддерживать автоматизацию. Стандартизация инфраструктуры и элементов платформы с помощью BSS/OSS обеспечивает максимальную степень использования ресурсов платформы и уменьшает ошибки развертывания, обуславливая высокую степень готовности. Платформа CCMP с OSS-системами - это ключевой компонент для мероприятий по автоматизации. Автоматизация - в сочетании с интегрированными средствами мониторинга и виртуализированной инфраструктурой - помогает динамически настраивать и масштабировать компьютерные ресурсы. Для избавления от изолированных зон вполне достаточно динамически расширяемого и гибкого набора виртуализированных технологических компонентов для вычислений, для хранения данных и реализации сетевых функций. Автоматизация с помощью OSS и BSS помогает преобразовать традиционную ИТ-среду банка в надежную и высокоустойчивую постоянно доступную среду.

На основе этой эталонной модели CEDC мы разработали для банка постоянно доступнее решение. На рис. 4 показана облачная архитектура этого решения.

Рисунок 4. Основанная на облачных технологиях системная архитектура постоянно доступного решения для мобильного и Интернет-банкинга

Ключевые архитектурные аспекты инфраструктурного уровня

Решение базируется на IaaS-уровне IBM SoftLayer с вычислительными компонентами, компонентами для хранения данных и сетевыми компонентами, которые совместно используются несколькими группами важнейших приложений - в частности, внешними обращенными к потребителю системами (статическая поддержка, функции маршрутизации Интернет-сервисов и приложения мобильного банка). Критический характер бизнес-потребностей в сегменте финансовых услуг потребовал, чтобы архитектура решения была основана на выделенном предложении SoftLayer категории "голое железо" в хорошо защищенной среде на основе модели с единственным арендатором. Перейдем к рассмотрению некоторых существенных аспектов интегрированных IaaS-компонентов - вычислительных, сетевых и предназначенных для хранения данных - в архитектуре нашего решения, призванного воплотить в реальность концепцию постоянно доступной системы.

Вычислительные компоненты

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

Компоненты для хранения данных

Для обеспечения постоянной доступности с локальным хранением данных нам потребовалось бы избыточное локальное хранилище в глобально распределенных конфигурациях категории "голое железо", поэтому была выбрана конфигурация среды хранения на основе сети хранения данных (SAN). Архитектура SAN улучшает управляемость и повышает гибкость экземпляров "голого железа", поскольку в ней легко реализуются конфигурации RAID 5 и выше в целях синхронизации данных.

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

Сетевые компоненты и компоненты сетевой безопасности

Сетевая архитектура платформы SoftLayer - с высокоскоростными соединениями внутри центра обработки данных и механизмом выравнивания нагрузки - обеспечивает необходимую степень избыточности и гибкости для заказчиков со строгими требованиями к показателям RPO (целевая точка восстановления) и RTO (целевое время восстановления). Базовые возможности SoftLayer в части глобального развертывания распределенных бизнес-приложений в географически рассредоточенных, но при этом интегрированных центрах обработки данных удовлетворяют потребность в высокой готовности (с коэффициентом работоспособности на уровне 99,999%). Организациям, нуждающимся в высокой производительности для систем, обслуживающих клиентов, SoftLayer предлагает сетевую опцию POP (point of presence - точка присутствия), которая предоставляет прямые или укороченные соединения со сниженной задержкой.

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

Компоненты для мониторинга и управления

Аспекты мониторинга и управления первоначальной системы были улучшены за счет автоматизации на основе функций поддержки BSS/OSS и применения устойчивых компонентов. Эти компоненты в сочетании с уровнем IaaS API гарантируют эластичность системы и соответственно повышение ее устойчивости.

IaaS-уровень поддерживается средствами SoftLayer API (примерно 2000 API-интерфейсов для мониторинга системы и управления ее эластичностью). Эта API-архитектура служит основой для автоматического масштабирования, которое необходимо банку для интеграции с его локальными системами мониторинга. Управление постоянно доступной инфраструктурой поддерживается программными средствами на нескольких уровнях модели управления SoftLayer API, которая предоставляет программируемые интерфейсы. Управление приложениями осуществляется без какого-либо участия человека, что рационализирует управление серверами и уменьшает расходы на эксплуатацию постоянно доступной ИТ-инфраструктуры.

PureSystems

В дополнение к IaaS-уровню на основе SoftLayer ключевым компонентом постоянно доступной архитектуры является система IBM PureSystems®. Сервисы корпоративной интеграции - критически важная функция стека описываемого банковского решения - поддерживают не только системы для работы с клиентами, но и другие сферы. Сложности миграции модуля для реализации конкретной бизнес-функции за пределы организации весьма высоки по сравнению с достигаемым выигрышем. Эти сложности обуславливаются в первую очередь необходимостью интеграции локальных систем с огромным количеством других внутренних приложений в облаке - т. е. при высоком уровне угроз безопасности. Возможность быстрого и эффективного создания локального частного облака с высокой степенью готовности для реализации постоянно доступной инфраструктуры была ключевым доводом в пользу включения системы PureSystems в нашу архитектуру. Система PureSystems объединяет вычислительные средства, хранилище данных, сетевые средства и управляющее программное обеспечение в рамках заранее сконфигурированной платформы, оптимизированной под потребности определенных рабочих нагрузок и сред.

Еще одним мотивом для включения системы PureSystems стало то, что на такой системе можно сконфигурировать PaaS-компонент, который в нашем решении необходим платформе для корпоративных интеграционных сервисов. Архитектура с системой PureSystems содержит проверенную модель сетевой избыточности, которая удовлетворяет потребности во взаимосвязанности и в глобальной балансировке нагрузки с целью поддержания устойчивости с функционально независимыми различными и избыточными ресурсами. Гибкая конфигурация безопасности поддерживает идентификацию, доступ, шифрование, мониторинг и аудит для выполнения нормативных требований. В комплект поставки системы PureSystems входит управляющий продукт SmartCloud Orchestration, который помогает пользователям создавать образы, инициализировать среды и выполнять развертывание в частном облаке, а также предоставляет основу для межоблачной интеграции.

 

• Этап 1. Реализация IaaS-уровня, а также некоторых элементов для поддержки автоматизации на основе уровня CCMP/BSS/OSS.
• Этап 2. Консолидация компонентов платформы с элементами платформы данных и элементами платформы интеграции.

На этапе 2 поддержку архитектуры решения также осуществляет PaaS-уровень, на котором консолидированы некоторые базовые компоненты платформы. На уровне платформы:

• Уровень данных консолидирован с платформой данных, состоящей из InfoSphere® и СУБД DB2® с InfoSphere Streams. Функциональность множественной аренды InfoSphere позволяет нескольким приложениям совместно использовать платформу данных, а функции InfoSphere Streams поддерживают анализ большого объема транзакций.
• Базовая платформа интеграции на основе программного обеспечения WebSphere® позволяет распределять интеграционные сервисы между приложениями.

Заключение

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

• Обратится в "Интерфейс" за дополнительной информацией/по вопросу приобретения продуктов