'

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

Понравилась презентация – покажи это...





Слайд 0

Обеспечение непрерывности бизнеса ASE 15.5 cluster edition конференция «корпоратиВные базы данных -2011» 14 апреля 2011 Андрей хромов, ведущий ТЕХНИЧЕСКИЙ консультант, Sybase cis


Слайд 1

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


Слайд 2

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


Слайд 3

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


Слайд 4

Sybase replication server немного о продукте Sybase является Пионером в технологии Репликации. Sybase имеет более чем 18 лет опыт поставок своим клиентам решений для Интеграции Данных и Распределенной обработки данных Более 2,600 корпоративных заказчиков во всем мире используют Replication Server, у многих в репликации задействованы тысячи серверов Исключительная надежность многократно проверена и подтверждается успешной работой в самых сложных и жестких условиях (компании Wall Street всегда требовали безостановочной работы 24х7)


Слайд 5

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


Слайд 6

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 и т.п.)


Слайд 7

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


Слайд 8

Решение high availability (кампус-кластер) sybase ASE cluster edition


Слайд 9

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


Слайд 10

Немного Истории Декабрь 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


Слайд 11

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


Слайд 12

Сценарий использования №1: бесперебойность работы для критичных систем Для кого: для тех, кто отвечает за жизненно-важные бизнес-приложения для владельцев ASE/HA Что дает вам ASE Cluster Edition: защиту от отказов серверов защиту от пиковых нагрузок сокращение плановых отключений Конфигурация отдельные приложения, отдельные БД актив–пассив (N:1 или N:2) актив–актив (как на картинке) Технологические особенности перераспределение нагрузки прозрачно для пользователей


Слайд 13

Преимущество ASE cluster edition по сравнению с обычным ase/HA


Слайд 14

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


Слайд 15

Сценарий использования №2 Консолидация приложений Для кого: для тех, у кого в организации есть множество ASE-систем, занимающих десятки (сотни?) полунагруженных серверов Что дает вам ASE Cluster Edition: консолидацию множества СУБД : освобождение оборудования сокращение затрат на Администрирование динамическое управление нагрузкой в кластере на отдельные приложения гибкость управления Конфигурация консолидация Standby-пар (1:1 -> N:1) консолидация отдельных серверов отдельные приложения, отдельные БД Технологические особенности управление виртуализированной нагрузкой (логичесие кластеры)


Слайд 16

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


Слайд 17

клиенты


Слайд 18

ASE 15.5 cluster edition Устройство кластера


Слайд 19

ASE CE: все компоненты Public Network Private Interconnects $SYBASE <ASE_SDC>.cfg CFS (или NFS) Кворум (raw - диск) Дисковые Устройства БД (raw- диски) Узлы Экземпляры ASE SAN Storage Errorlog


Слайд 20

Поддерживаемые платформы Поддерживаются только 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


Слайд 21

Требования к 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 НЕТ ДА ДА


Слайд 22

Схема подключения Primary Private Secondary Private Public Network Storage Network


Слайд 23

Базы данных В кластере Системные базы данных Одна(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


Слайд 24

Архитектура кластера 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


Слайд 25

ASE 15.5 cluster edition работа кластера


Слайд 26

Virtualized Resource Management™ Логические кластеры Приложения Физические кластеры Workload Manager


Слайд 27

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


Слайд 28

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


Слайд 29

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


Слайд 30

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


Слайд 31

логический кластер ? профиль нагрузки: Метрики нагрузки и веса


Слайд 32

логический кластер ? профиль нагрузки: пороговые значения


Слайд 33

Логический кластер & профиль нагрузки


Слайд 34

Метрики профиля нагрузки В стандартном профиле нагрузки sybase_profile_oltp самый высокий вес имеет метрика Run Queue. В результате, как только начинает возрастать конкуренция за процессор, суммарная оценка «загруженности» также возрастает, и это приводит к миграции пользовательских соединений. В профиле demo_profile_dld наибольший вес стоит у метрики user connections. Это приводит к тому, что профиль старается в первую очередь сбалансировать число пользователей на разных узлах . Во вторую очередь, он учитывает также и загрузку ЦП на каждом узле.


Слайд 35

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


Слайд 36

Логические кластеры и аварийное переключение (failover) Ресурсы для FAILOVER Список ASE-серверов или групп ASE-серверов, на которые может осуществляться переключение Режим FAILOVER Определяет, будет ли работать переключение для отдельных ASE-серверов логического кластера или только всего кластера целиком Режимы: Instance ? если на каком-то из ASE-серверов произошел сбой, он немедленно заменяется другим ASE-сервером из списка серверов для FAILOVER Group ? пока не умрут ВСЕ базовые ASE-сервера логического кластера, переключение на FAILOVER-сервера не будет fail_to_any attribute Определяет, можно ли в случае аварии переключать только на заранее выделенные FAILOVER-сервера или на любые доступные, если FAILOVER-сервера недоступны


Слайд 37

Логический кластер: обработка аварии 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


Слайд 38

Логический кластер. Обработка аварии: авария сервера #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


Слайд 39

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


Слайд 40

Логический кластер. Обработка аварии: авария сервера #1 (#3 и #4 отключены) CUSTSVC Аварийный перевод соединений SALES Аварийный перевод соединений SHIPPING Аварийная замена Сервера: Зависит от значения атрибута fail_to_any Если true, происходит instance failover на любой оставшийся ASE-сервер, даже если он и не входил в данный логический кластер и не был в его списке серверов для failover. Если false, то логический кластер SHIPPING становится недоступным. CUSTSVC SALES SHIPPING


Слайд 41

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


Слайд 42

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


Слайд 43

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


Слайд 44

Отличие миграции соединения от аварийного переключения соединения Миграция или аварийное переключение (Failover) Миграция это плановое контролируемое действие, инициированное самим ASE Аварийное переключение это незапланированное действие, которое происходит в случае аварии ASE или разрывом сети Миграция происходит прозрачно для клиентских приложений и никаких изменений в приложении не нужно Для более интеллектуальной обработки аварийного переключения может потребоваться написание в приложении специально кода. Миграция на новый ASE-сервер полностью восстанавливает на нем контекст клиентской сессии Аварийное переключение контекст не восстанавливает Потребуется заново инициировать подключение к кластеру ИЛИ, чтобы сделать аварийное переключение прозрачным для пользователей, нужно написать код обработки для CS_RET_HAFAILOVER и заново инициировать последнюю транзакцию (или команду)


Слайд 45

Заключение – ase cluster edition … Способен защитить от нескольких одновременных аварий, обеспечивая быстрое переключение клиентов Поддерживает виртуальные нагрузки, чем упрощает запуск на кластере новых приложений Создание и настройка профилей нагрузок для облегчения оптимизации производительности и сегментирования системы Использует все узлы кластера, распределяя по ним клиентов в автоматическом режиме (согласно правилам) Распределяет нагрузку по ресурсам кластера - автоматически и прозрачно для приложений Все операции по обслуживанию можно проводить на Stand-By узлах Минимизирует влияние операций по обслуживанию СУБД на работу критичных бизнес-приложений Обеспечивает приложениям непрерывную готовность


Слайд 46


×

HTML:





Ссылка: