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

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

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

Обеспечение высокой доступности облачных банковских приложений PlatoBlockchain Data Intelligence. Вертикальный поиск. Ай.Обеспечение высокой доступности облачных банковских приложений PlatoBlockchain Data Intelligence. Вертикальный поиск. Ай.
Тодд Доан, архитектор решений, SIOS Technology

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

Но внимательно посмотрите на соглашение об уровне обслуживания (SLA), описывающее высокую доступность: SLA гарантирует, что по крайней мере одна из виртуальных машин в вашей системе будет доступна как минимум 99.9 % или даже 99.99 % времени. Но это не гарантия наличия приложения или данных. Если оставшаяся виртуальная машина не может получить доступ к инфраструктуре хранения, в которой находятся ваши банковские приложения и данные, ваши важные приложения фактически отключены.

Обеспечение доступности облака

Как вы можете гарантировать, что ваши критически важные банковские приложения и данные останутся высокодоступными в облаке или в гибридной локальной/облачной конфигурации, если недостаточно настроить базовую технологию для автоматического аварийного переключения в нескольких зонах доступности?

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

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

Настройка для облака

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

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

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

Решения для репликации данных

У вас есть несколько вариантов решений для репликации данных.

Если ваш кластер основан на Windows и вы используете Microsoft SQL Server, вы можете использовать встроенную в SQL Server функцию групп доступности (AG), которая будет автоматически реплицировать базы данных SQL с именами пользователей на каждый из узлов в вашем кластере. Недостатком этого подхода является то, что он реплицирует только базы данных SQL, а не каждый блок данных в хранилище. Репликация нескольких баз данных SQL Server на несколько резервных виртуальных машин может обойтись очень дорого, поскольку вам придется использовать SQL Server Enterprise Edition для репликации нескольких баз данных или для репликации баз данных на несколько виртуальных машин, даже если ваши приложения отлично работают с использованием SQL Server Standard Edition. .

В качестве альтернативы вы можете использовать кластерное решение без SAN, которое обеспечивает автоматическую репликацию данных на уровне блоков с активной основной ВМ на каждую из вторичных ВМ в кластере. Преимущество использования решения кластеризации без SAN заключается в том, что оно не зависит от приложений и баз данных; он просто реплицирует блоки данных из одной системы хранения в другую, гарантируя, что все данные в вашей основной системе хранения будут реплицированы на каждую из других виртуальных машин. Недостатком подхода кластеризации без SAN является то, что вашей ИТ-команде нужно лицензировать и изучать еще одну часть программного обеспечения, что может показаться обременительным, если вы можете использовать функциональность AG SQL Server без дополнительных затрат.

Репликация данных является ключом к обеспечению высокой доступности для облачных банковских систем, независимо от того, используете ли вы функциональные возможности, встроенные в такое решение, как SQL Server, или функциональные возможности, предоставляемые независимым кластерным решением без SAN.

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

Тодд Доан — архитектор решений в SIOS Technology. Он провел более 20 лет, в основном в мире финансовых услуг, создавая эталонные архитектуры высокой доступности и шаблоны и принципы проектирования для конкретных приложений.

Отметка времени:

Больше от Банковские инновации