Обеспечение непрерывности бизнесаASE 15.5 cluster edition

ПОНЯТИЕ «НЕПРЕРЫВНОСТИ БИЗНЕСА» (BUSINESS CONTINUITY)
Кампус-кластер – все сервера находятся в одном ЦОДе
Метро-кластер – сервера разнесены по разным зданиям
Гео-кластер – сервера разнесены по разным городам (странам)
Выбор оптимальной BC/DR архитектуры – это обычно компромисс между:
задержкой по времени между основой и резервной системой (расстояния)
масштабом возможных потерь в случае аварии
Также следует учитывать, какого типа аварии для вас наиболее типичны
High-Availability
Disaster Recovery
Disaster Recovery

РЕШЕНИЯ ДЛЯ НЕПРЕРЫВНОСТИ БИЗНЕСА
Технологии непрерывности бизнеса для создания
территориально распределенных DR-решений
Технологии непрерывности бизнеса для обеспечения
High Availability в пределах одного ЦОДа
ASE High Availability (HA) option
ASE Cluster Edition
Отказоустойчивость для ВСЕХ серверов
и много чего еще!
Replication Server/WarmSB
Репликация транзакций БД
Mirror Activator
Объединение дисковой репликации с репликацией БД
Отказоустойчивость для 1 сервера

SYBASE REPLICATION SERVER WARM STANDBY
РЕШЕНИЕ DISASTER RECOVERY (МЕТРО-КЛАСТЕР)
РЕШЕНИЕ
Организация «Зеркальной» базы данных, непрерывно реплицируемой средствами Sybase Replication Server
“АКТИВНЫЙ” сервер БД
ASE
“STANDBY” сервер БД
Replication Server
ASE
ДОСТОИНСТВА РЕШЕНИЯ
Наличие второй копии данных – что бы не случилось с активным сервером или с его базой данных, всегда есть «запасная» база данных, сразу готовая к работе
Репликация работает в режиме реального времени – STANDBY-база всегда содержит актуальные данные (задержка – несколько секунд)
STANDBY-база является «логической» копией (т.к. передаются SQL-команды, а не данные), а значит является 100% корректной. Поврежденные блоки данных на резервную базу просто не передаются.
STANDBY-база доступна для работы – например как сервер оперативной отчетности
Возможность значительного территориального разнесения активного и отчётного серверов
ОТКАЗОУСТОЙЧИВАЯ ПАРА

SYBASE REPLICATION SERVER
НЕМНОГО О ПРОДУКТЕ
Sybase является Пионером в технологии Репликации.
Sybase имеет более чем 18 лет опыт поставок своим клиентам решений для Интеграции Данных и Распределенной обработки данных
Более 2,600 корпоративных заказчиков во всем мире используют Replication Server, у многих в репликации задействованы тысячи серверов
Исключительная надежность многократно проверена и подтверждается успешной работой в самых сложных и жестких условиях (компании Wall Street всегда требовали безостановочной работы 24х7)

SYBASE REPLICATION SERVER
НЕМНОГО О ПРОДУКТЕ
Москва, головной офис
Система
управления
заказами
ASE
Rep Server
Rep Option
for Microsoft
Microsoft
Система корпоративной отчетности
Oracle
ERP система
Москва, склад
Москва, филиал №1
Санкт-Петербург, филиал №2
Rep Option
for IBM
IBM
CRM-система
WAN
Гетерогенная среда:
Sybase, IBM, Microsoft, Oracle
Скорость – в режиме реального времени
Работает на основе Журнала Транзакций
- не нагружает СУБД-источник
Возможные топологии:
1:Много, Много:1, Много:Много
Однонаправленная и двунаправленная репликация
Модель репликации: «публикации-подписки»
Гибкие возможности маршрутизации и трансформации данных
Rep Option
for Oracle
WAN
Пример архитектуры:
LAN

SYBASE MIRROR ACTIVATOR
РЕШЕНИЕ DISASTER RECOVERY (МЕТРО-КЛАСТЕР)
Sybase Mirror Activator – это DR-решение нового поколения для обеспечения катастрофоустойчивости серверов баз данных Sybase ASE
Sybase Mirror Activator повышает эффективность существующих
DR-систем и гарантирует:
Потери данных исключены (Zero Data Loss!)
Полная транзакционная целостность резервной БД
Готовность резервной БД – секунды (вместо часов)
Возможность «активного» использования резервной БД
Sybase Mirror Activator является симбиозом двух технологий:
Асинхронной репликации транзакций баз данных Replication Server
Синхронной репликации физических дисковых блоков на уровне
Системы Хранения Данных (примеры: EMC SRDF или MirrorView, IBM PPRC, Veritas Volume Replicator, NetApp SnapMirror, Hitachi TrueCopy и т.п.)

SYBASE MIRROR ACTIVATOR
РЕШЕНИЕ DISASTER RECOVERY (МЕТРО-КЛАСТЕР)
Sybase ASE
Sybase Mirror Activator Агент
Sybase Replication Server
Sybase Open Switch
Sybase ASE
Дисковая Репликация
MIRROR
Log
ОСНОВНАЯ СИСТЕМА
ЗЕРКАЛЬНАЯ КОПИЯ (DR/Reporting)
«Клиентские» места

РЕШЕНИЕ HIGH AVAILABILITY (КАМПУС-КЛАСТЕР)
SYBASE ASE CLUSTER EDITION

ASE CLUSTER EDITION - ЧТО ЭТО ТАКОЕ?
Специальная кластерная редакция ASE (Shared Disk Cluster)
Архитектура поддерживает до 32 узлов ASE
Интеллектуальное управление виртуализированными ресурсами для максимизации доступности
и производительности
Для клиентов выглядит как
единый логический сервер
Содержит в себе все необходимое
кластерное ПО

НЕМНОГО ИСТОРИИ
Декабрь 2007: ASE CE 15.0.1
первая версия ASE Cluster Edition
Solaris & Linux
First SDC workload manager
SDC virtualization introduced
Декабрь, 2008: ASE CE 15.0.1
новые платформы: HPUX & IBM AIX
Июнь 2009: ASE CE 15.0.3
Объединение кода с линией ASE SMP
Размещение $SYBASE локально
Несколько Backup Server
Интеграция с Veritas VSF
Производительность CIPC
Март 2010: ASE/CE 15.5
Поддержка опций ASE
Защита от множественных отказов
Улучшенный CIPС
Март 2011
Актуальная версия:
ASE CE 15.5 esd #3

ASE CLUSTER EDITION – ДЛЯ ЧЕГО ОН?
Бесперебойность работы критичных систем
Защита систем от простоев, вызванных отказом отдельных серверов. Система продолжает работать, пока работает кластер (хотя бы один узел)
Способность справляться с пиковой нагрузкой , выдерживая требуемый SLA,
за счет перераспределения нагрузки между всеми узлами кластера
Максимизация использования ресурсов
Консолидация несколько приложений в кластер помогает более полно использовать имеющиеся аппаратные ресурсы и сократить парк избыточного полунагруженного оборудования
Использовать резервное оборудования для перераспределения
нагрузки по всем узлам в кластере
Снижение затрат на инфраструктуру
Развертывание кластера на недорогих массовых серверах позволяет сэкономить как при покупке , так и при их дальнейшем сопровождении
Наборная архитектура кластера позволяет легко расширять ее, добавляя в кластер по мере необходимости новые узлы, либо отключая их

СЦЕНАРИЙ ИСПОЛЬЗОВАНИЯ №1:
БЕСПЕРЕБОЙНОСТЬ РАБОТЫ ДЛЯ КРИТИЧНЫХ СИСТЕМ
Для кого:
для тех, кто отвечает за жизненно-важные бизнес-приложения
для владельцев ASE/HA
Что дает вам ASE Cluster Edition:
защиту от отказов серверов
защиту от пиковых нагрузок
сокращение плановых отключений
Конфигурация
отдельные приложения, отдельные БД
актив–пассив (N:1 или N:2)
актив–актив (как на картинке)
Технологические особенности
перераспределение нагрузки прозрачно для пользователей

ПРЕИМУЩЕСТВО ASE CLUSTER EDITION ПО СРАВНЕНИЮ С ОБЫЧНЫМ ASE/HA

ПростаивающиеStand-by
сервера
Более полное использование имеющего оборудования
Слабо загруженные сервера департаментов
Мощности Standby-серверов не используются
Больше приложений, серверов, РЕЗЕРВНЫХ серверов – больше расходов на площади, электричество, кондиционирование …
Простой перенос депаратаментных серверов в помещение дата-центра приводит к проблеме свободного места
Чем больше отдельных серверов, тем сложнее обеспечивать для всех требуемый уровень Сервиса (SLA)
Развитие серверных технологий позволяет консолидировать множество баз данных на небольшом количестве серверов (кластер), без ущерба для требуемого уровня сервиса (SLA)
СЦЕНАРИЙ ИСПОЛЬЗОВАНИЯ №2
КОНСОЛИДАЦИЯ ПРИЛОЖЕНИЙ

СЦЕНАРИЙ ИСПОЛЬЗОВАНИЯ №2
КОНСОЛИДАЦИЯ ПРИЛОЖЕНИЙ
Для кого:
для тех, у кого в организации есть множество ASE-систем, занимающих десятки (сотни?)
полунагруженных серверов
Что дает вам ASE Cluster Edition:
консолидацию множества СУБД :
освобождение оборудования
сокращение затрат на Администрирование
динамическое управление нагрузкой
в кластере на отдельные приложения
гибкость управления
Конфигурация
консолидация Standby-пар (1:1 -> N:1)
консолидация отдельных серверов
отдельные приложения, отдельные БД
Технологические особенности
управление виртуализированной нагрузкой (логичесие кластеры)

Для кого:
для тех, кто использует дорогостоящие
Hi-End –сервера для ASE-приложений
Что дает вам ASE Cluster Edition:
экономию на расходах на супер-сервер.
заменив hi-end ($1M) на бюджетный
4x кластер ($100K) вы сокращаете свои
ежегодные расходы на сопровождение
масштабируемую архитектуру (возможность
горизонтального масштабирования)
Конфигурация
несколько приложений с отдельными БД
одно приложение с одной БД, разделенной
на несколько отдельных сегментов
Технологические особенности
возможно использование недорогой платформы Intel x64
логические кластеры, балансировка нагрузки между логическими приложениями
Оптимизация H/W инфраструктуры
для хорошо сегментируемых приложений
СЦЕНАРИЙ ИСПОЛЬЗОВАНИЯ №3
.

КЛИЕНТЫ

ASE 15.5 CLUSTER EDITION
УСТРОЙСТВО КЛАСТЕРА

ASE CE: ВСЕ КОМПОНЕНТЫ
Public Network
Private
Interconnects
$SYBASE
.cfg
CFS
(или NFS)
Кворум
(raw - диск)
Дисковые Устройства БД
(raw- диски)
Узлы
Экземпляры ASE
SAN Storage
Errorlog

ПОДДЕРЖИВАЕМЫЕ ПЛАТФОРМЫ
Поддерживаются только 64-битные платформы
RISC UNIX архитектура
Solaris SPARC 64-bit
Solaris 9
Solaris10
IBM AIX (pSeries)
AIX 6.1
HP-UX (Itanium)
HP-UX 11.31
Intel/AMD архитектура
Linux 64-bit
RHEL 4.5
RHEL 5.1
SLES 9.3
SLES 10.1
Solaris x64
Solaris 10

ТРЕБОВАНИЯ К H/W
Оборудование и ОС
Все узлы должны иметь одну платформу и ОС
Наполнение может отличаться (ОЗУ, процессоры)
Процессор: желательно не менее 4 ядер
ОЗУ: не менее 4ГБ / 1 ядро
Сеть – не менее 3 интерфейсов
2 внутренних - для самого кластера
Основной и резервный, не менее 1ГБит, лучше 10 Гбит
Коммутация через Switch (не router!)
1 или более внешних – для пользователей
Дисковая система – SAN с общим доступом
Для данных и кворума - RAW
Д.б. SCSI-3 PGR для IO fencing
Для $SYBASE - можно CFS или NFS
Если NFS, то д.б. отказоустойчивым
Возможно локальное размещение (файловая система)
Использование Volume Manager
Veritas Storage Foundation for Sybase ASE CE
НЕТ
ДА
ДА

СХЕМА ПОДКЛЮЧЕНИЯ
Primary Private
Secondary Private
Public Network
Storage Network

БАЗЫ ДАННЫХ В КЛАСТЕРЕ
Системные базы данных
Одна(1) совместно используемая копия: master, model, sybsystemprocs, etc
Временные базы (TEMPDB)
Одна (1) глобальная “tempdb”
У каждого ASE есть также не менее
1 локальной системной tempdb
Имя по-умолчанию - “lstdb_#”
(local system temp db)
DBA может создать дополнительные глобальные и
локальные tempdb (как пользовательские tempdb)
Пользовательские базы
Едина копия всех пользовательских баз,
доступная всем узлам ASE
Привязка логического кластера к той или иной базе осуществляется на уровне пользователя/приложения
tempdb
lstdb_1
appX_tempdb
lstdb_2
appY_tempdb
appZ_tempdb

АРХИТЕКТУРА КЛАСТЕРА ASE CE
An Instance
Kernel
Data Service
Cluster Lock
Management
Buffer Cache
Coherency
Object Coherency
Cluster Space /
Threshold
Cluster Logging
Recovery
Connection/Context
Management
Cluster RPC,
Replication Agent
Reliable
Cluster Interconnect
Workload
Management
Interconnect I/O Abstraction
UDP
TCP
SDP*
VERBS*
Basis I/O and Platform Abstraction
Cluster Membership
Service
Cluster Meta-Data /
DDL / Statistics
Peer Coordination
Local/Global Temp DB
Cluster Event
Service
Quorum Management,
IO Fencing
Cluster SPID, DBCC,
Monitor, Config, etc

ASE 15.5 CLUSTER EDITION
РАБОТА КЛАСТЕРА

VIRTUALIZED RESOURCE MANAGEMENT™
Логические
кластеры
Приложения
Физические
кластеры
Workload
Manager

WORKLOAD MANAGER
Workload Manager(менеджер нагрузки) – одна из важнейших подсистем ASE Сluster Edition
Позволяет управлять нагрузкой в кластере,
используя абстракцию логических «приложений»
Перенаправлять пользовательские соединения в кластере на то или иное «приложение»
Определять правила балансировки нагрузки в зависимости от «приложения»
Определять для разных «приложений» разные схемы для отказоустойчивости
Отрабатывать операции failover, failback, offline и online на уровне «приложения»
Выделять обособленный пул ресурсы – отдельные экземпляры ASE могут быть закреплены за определенными приложениями

ЛОГИЧЕСКИЕ КЛАСТЕРЫ
Логические кластеры – это ключевой элемент в системе управления нагрузкой (workload manager subsystem)
Служат для выделения «приложений» или «прикладных сегментов»
Логические кластеры и ASE-сервера кластера (Instances) относятся как M:N
Логический кластер может размещаться на нескольких физических ASE-серверах,
Несколько логических кластеров могут работать на одном и том же ASE сервере.
“базовые” ASE-сервера – где логический кластер работает по-умолчанию
“резервные” ASE-сервера – куда логический кластер может мигрировать в случае аварии
Могут объединяться в группы, иметь приоритеты
Поведение логического кластера определяется его настраиваемыми атрибутами

КОМПОНЕНТЫ WORKLOAD MANAGER
CUSTSVC
SALES
SHIPPING
Правила перенаправления клиентов
(приложение,
имя сервера, логин)
Профили нагрузки
ЛОГИЧЕСКИЕ КЛАСТЕРЫ
Interfaces/
sql.ini
Interfaces/
sql.ini
Interfaces/
sql.ini
MYCLUSTER_SDC

ПРОФИЛИ НАГРУЗКИ
Менеджер нагрузки также отвечает за распределение нагрузки по серверам кластера
Следит, чтобы не происходил перекос нагрузки, когда один сервер нагружен на 95%, а другие на 30%
Профиль нагрузки определяет, насколько нагружен узел кластера
Стандартно есть 2 профиля: для OLTP и для DSS
Каждый логический кластер имеет 1 профиль нагрузки
Но у отдельного узла (сервера ASE) может быть несколько профилей
Пользователи могут также создавать свои профили
Профиль нагрузки учитывает 5 метрик
Сумма взвешенных значений этих метрик дает суммарную
оценку нагруженности
Более важным (для вас) метрикам обычно назначают более высокие веса

ЛОГИЧЕСКИЙ КЛАСТЕР ? ПРОФИЛЬ НАГРУЗКИ:
МЕТРИКИ НАГРУЗКИ И ВЕСА

ЛОГИЧЕСКИЙ КЛАСТЕР ? ПРОФИЛЬ НАГРУЗКИ:
ПОРОГОВЫЕ ЗНАЧЕНИЯ

ЛОГИЧЕСКИЙ КЛАСТЕР & ПРОФИЛЬ НАГРУЗКИ

МЕТРИКИ ПРОФИЛЯ НАГРУЗКИ
В стандартном профиле нагрузки sybase_profile_oltp самый высокий вес имеет метрика Run Queue. В результате, как только начинает возрастать конкуренция за процессор, суммарная оценка «загруженности» также возрастает, и это приводит к миграции пользовательских соединений.
В профиле demo_profile_dld наибольший вес стоит у метрики user connections. Это приводит к тому, что профиль старается в первую очередь сбалансировать число пользователей на разных узлах . Во вторую очередь, он учитывает также и загрузку ЦП на каждом узле.

МОНИТОРИНГ НАГРУЗКИ
Решение о необходимости миграции соединений менеджер нагрузки принимает, основываясь на суммарной оценке (Load Score)Connection, для каждого логического кластера по отдельности. Суммарная оценка складывается из всех входящих в нее отдельных метрик.
В нашем случае для логического кластера CatalogLC сервер HOTROD_1 имеет показатель загруженности (Load Score) в 2 раза больше, чем сервер HOTROD_2 . В основном, по причине в 10 раз более высокой загрузки CPU (CPU Busy). Хотя с другой стороны, показатель «число пользователей» (User Connections) больше у сервера HOTROD_2).
(примечание: User Connections означает не фактическое число подключений, а некую нормированную «оценку» их количества)

ЛОГИЧЕСКИЕ КЛАСТЕРЫ
И АВАРИЙНОЕ ПЕРЕКЛЮЧЕНИЕ (FAILOVER)
Ресурсы для FAILOVER
Список ASE-серверов или групп ASE-серверов, на которые может осуществляться переключение
Режим FAILOVER
Определяет, будет ли работать переключение для отдельных ASE-серверов логического кластера или только всего кластера целиком
Режимы:
Instance ? если на каком-то из ASE-серверов произошел сбой, он немедленно заменяется другим ASE-сервером из списка серверов для FAILOVER
Group ? пока не умрут ВСЕ базовые ASE-сервера логического кластера, переключение на FAILOVER-сервера не будет
fail_to_any attribute
Определяет, можно ли в случае аварии переключать только на заранее выделенные FAILOVER-сервера или на любые доступные, если FAILOVER-сервера недоступны

ЛОГИЧЕСКИЙ КЛАСТЕР: ОБРАБОТКА АВАРИИ
CUSTSVC
Базовые ASE-сервера:
SYBASE_1
SYBASE_2
Резервные ASE-сервера:
SYBASE_3
SYBASE_4
Режим: GROUP
SALES
Базовые ASE-сервера:
SYBASE_1
SYBASE_2
SYBASE_3
Резервные ASE-сервера:
SYBASE_4
Режим: INSTANCE
SHIPPING
Базовые ASE-сервера:
SYBASE_3
SYBASE_4
Резервные ASE-сервера:
SYBASE_1
Режим: GROUP
CUSTSVC
SALES
SHIPPING

ЛОГИЧЕСКИЙ КЛАСТЕР. ОБРАБОТКА АВАРИИ:
АВАРИЯ СЕРВЕРА #3
CUSTSVC
Не затронут
SALES
Аварийная замена Сервера:
Т.к. Failover-режим = “Instance”, то вместо умершего сервера SYBASE_3 в кластер включается резервный сервер SYBASE_4
Соединения умершего SYBASE_3 переводятся на SYBASE_4
SHIPPING
Аварийный перевод соединений:
Т.к. Failover-режим = “group” и часть базовых серверов кластера еще жива (SYBASE_4),
аварийной замены умершего сервера резервным сервером не происходит
Однако, соединения вышедшего из строя сервера SYBASE_3 переводятся на оставшийся сервер кластера - SYBASE_4
CUSTSVC
SALES
SHIPPING

ЛОГИЧЕСКИЙ КЛАСТЕР. ОБРАБОТКА АВАРИИ:
АВАРИЯ СЕРВЕРА #4 (СЕРВЕР #4 ОТКЛЮЧЕН)
CUSTSVC
Не затронут
SALES
Аварийный перевод соединений:
Т.к. живых северов из списка «резервных» для этого кластера больше нет, соединения с SYBASE_3 переводятся на SYBASE_1
или SYBASE_2 (сервера, входящие в кластер SALES)
SHIPPING
Аварийная замена Сервера:
Т.к. режим failover = “group” и живых базовых серверов у этого кластера больше не осталось,
происходит аварийный переход на резервный сервер для этого кластера (SYBASE_1)
CUSTSVC
SALES
SHIPPING

ЛОГИЧЕСКИЙ КЛАСТЕР. ОБРАБОТКА АВАРИИ:
АВАРИЯ СЕРВЕРА #1 (#3 И #4 ОТКЛЮЧЕНЫ)
CUSTSVC
Аварийный перевод соединений
SALES
Аварийный перевод соединений
SHIPPING
Аварийная замена Сервера:
Зависит от значения
атрибута fail_to_any
Если true,
происходит instance failover
на любой
оставшийся ASE-сервер,
даже если он и не входил в данный логический кластер
и не был в его списке
серверов для failover.
Если false, то логический кластер SHIPPING
становится недоступным.
CUSTSVC
SALES
SHIPPING

НОВЫЕ КЛИЕНТСКИЕ ТЕХНОЛОГИИ
Новые клиентские технологии
Позволяют клиенту иметь логическое соединение с кластером, оставаясь при этом физически подключенным к определенным ASE-серверам этого кластера.
Такое логическое соединение позволяет Adaptive Server перенаправлять клиента на различные ASE-сервера кластера и динамически информировать клиента об актуальных списках доступных FAILOVER-серверов.
Новые клиентские технологии включают:
Перенаправление логинов – когда клиент в момент установления соединения переводится на другой ASE-сервер кластера. OCS версии 15.0
Миграцию соединений – когда уже установленное соединение переносится на другой ASE-сервер в кластере. OCS version 15.0 ESD #3
Расширенные возможности по аварийному переключению – позволяет соединению выполнять аварийное переключение несколько раз подряд

ПЕРЕНАПРАВЛЕНИЕ ЛОГИНОВ
Происходит в момент подключения
Если данный ASE-сервер перегружен работой, он говорит клиенту подключиться на соседний ASE-сервер
ASE Workload Manager
Использует login redirection чтобы переслать входящее соединение на другой ASE-сервер, основываясь на параметрах конфигурации логического кластера и текущего уровня загрузки
Никакой дополнительной настройки со стороны клиентов не требуется
CUSTSVC

МИГРАЦИЯ СОЕДИНЕНИЙ
Перенос существующих клиентских соединения с одного ASE-сервера на другой
Позволяет Workload Manager корректно переводить пользовательские соединения с одного ASE-сервера на другой
Для балансирования нагрузки
Для выполнения административных операций: failover, failback или выключения Логического кластера
Миграция соединений доступна автоматически, если используется Open Client 15.0.
Никаких изменений в приложении не требуется
Соединения должны быть неактивны (‘quiescent’)
Не должен выполнять никакой batch
Не должно быть открытой транзакции
Не должно быть #table
Не должно быть открытых курсоров
И т.п.
CUSTSVC

ОТЛИЧИЕ МИГРАЦИИ СОЕДИНЕНИЯ ОТ
АВАРИЙНОГО ПЕРЕКЛЮЧЕНИЯ СОЕДИНЕНИЯ
Миграция или аварийное переключение (Failover)
Миграция это плановое контролируемое действие, инициированное самим ASE
Аварийное переключение это незапланированное действие, которое происходит в случае аварии ASE или разрывом сети
Миграция происходит прозрачно для клиентских приложений и никаких изменений в приложении не нужно
Для более интеллектуальной обработки аварийного переключения может потребоваться написание в приложении специально кода.
Миграция на новый ASE-сервер полностью восстанавливает на нем контекст клиентской сессии
Аварийное переключение контекст не восстанавливает
Потребуется заново инициировать подключение к кластеру
ИЛИ, чтобы сделать аварийное переключение прозрачным для пользователей, нужно написать код обработки для CS_RET_HAFAILOVER и заново инициировать
последнюю транзакцию (или команду)

ЗАКЛЮЧЕНИЕ – ASE CLUSTER EDITION …
Способен защитить от нескольких одновременных аварий, обеспечивая быстрое переключение клиентов
Поддерживает виртуальные нагрузки,
чем упрощает запуск на кластере новых приложений
Создание и настройка профилей нагрузок для облегчения оптимизации производительности и сегментирования системы
Использует все узлы кластера, распределяя по ним клиентов в автоматическом режиме (согласно правилам)
Распределяет нагрузку по ресурсам кластера - автоматически и прозрачно для приложений
Все операции по обслуживанию можно проводить на Stand-By узлах
Минимизирует влияние операций по обслуживанию СУБД на работу критичных бизнес-приложений
Обеспечивает приложениям непрерывную готовность