Комментарии по теме

«Ре­ко­ме­нда­ции по обе­спе­че­нию бе­зо­па­сно­сти и контроля SAP HANA»
Дмитрий Буслов:
(1) Автор начинает с того, что HANA — это СУБД, позволяющая хранить записи в колонках и работающая в оперативной памяти. Я бы, хотел сделать акцент на том, что HANA — не просто СУБД,...
«Различие между двумя текущими версиями HANA»
Олег Точенюк:
Спасибо конечно... я вот не понимаю как консалт выживает в этом мире, когда есть такой чудесный традиционный сайт help.sap.com/ :-)
«Испо­льзо­ва­ние SAP S/4 HANA Migration Cockpit для загрузки ма­те­ри­а­ло­в. Пра­кти­че­ское ру­ко­во­дство»
Марат Мухаметзянов:
Добрый день!   Спасибо статью!   P.S.: Есть еще транзакции DMC и DMCMOM, как решение для загрузки данных в S4H. DMC в большей степени для загрузки данных из Excel, а DMCMOM для...

База знаний

Вы можете подписаться на эту колонки этого автора, если авторизируетесь или зарегистрируетесь

Введение в High Availability SAP HANA

25 июня 2014, 20:23

ГОСТ Р 53647.2-2009 определяет непрерывность бизнеса (business continuity) как «стратегическую и тактическую способность организации планировать свою работу в случае инцидентов и нарушения её деятельности, …. непрерывность деловых операций на установленном приемлемом уровне.»

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

1.     Введение в High Availability SAP HANA

1.1. Восстановление – ключевые показатели

В качестве ключевых показателей эффективности восстановления используются показатели Recovery Period Objective (RPO) и Recovery Time Objective (RTO).

RPO является максимально допустимым периодом, в течение которого данные могут быть потеряны без возможности восстановления (время между созданием последней резервной копии и аварией), RTO представляет собой максимально допустимое время, необходимое для восстановления системы.

Как in-memory СУБД, HANA должна не только обеспечивать надежность данных в случае сбоев системы и быстрое восстановление данных (в памяти).

На Рис. 1 показаны фазы высокой готовности HANA.

Рис.1 Фазы высокой готовности HANA

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

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

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

1.2  Уровень певрый. Резервное копирование (Backups)

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

  • журнальные файлы транзакций (redo logs),
  • изменения данных, используя контрольные точки сохранения (savepoints).

Журналы используются для записи изменений. Для обеспечения восстановления тразакции нет необходимости сохранять ее результаты в момент фиксации ее завершения (при выполнении commit), достаточно сохранить журнал. После сбоя, наиболее актуальное состояние БД может быть восстановлено путем применения (наката) журнала, перевыполнив завершенные транзакции и откатив незавершенные.

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

Более новые контрольные точки перезаписывают старые, при этом существует возможность «заморозить» любую контрольную точку для дальнейшего использования, и создать снимок данных (snapshot). Снимки могут быть воспроизведены в виде полных резервных копий БД, котороые могут быть ипользованы для восстановления БД на определнный момент времени. В дополнение к этому сокращение периодов резервирования журналов обеспечивает возможность восстановления после фатальных сбоев с минимальными потерями данных.

На Рис. 2 показаны контрольные точки, сохраненные в локальном дисковом хранилище, и дополнительные резервные копии, сохраненные в резервном хранилище. Локальное восстановление после сбоя использует последнюю контрольную точку, а затем применяет последние журналы, для восстановления базы данных без потери данных. Если локальное хранилище было повреждено, все еще возможно восстановить БД из резервной копии данных (или последнего снимка), и резервных копий журналов, но уже с некоторой потерей данных.

Рис. 2 Контрольные точки сохранения

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

Рис. 3 Резервное копирование БД в удаленное хранилище

1.3. Уровень второй. Репликация хранения (Storage Replication)

Одиним из недостатков резервных копий БД является потенциальная потеря данных с момента создания последней резервной копии до момента сбоя. Предпочтительным решением, в этом случае, является возможность обеспечить непрерывную репликацию всех сохраненных данных. Аппаратные партнеры SAP предлагают решения для репликации данных, обеспечивая резервное копирование на уровне файловой системы с использованием удаленной сетевой системы хранения (более подробно о предлождении аппаратных партнеров SAP в цикле вебинаров SAP HANA Online). В этом случае транзакция SAP HANA завершается только тогда, когда локально сохраненный журнал транзакций будет реплицирован в уделнное хранилище. Такой подход называется синхронная репликация (synchronous storage replication). Синхронная репликация может эффективно использоваться при условии, что расстояние между основной и резервной БД составляет до 100 километров (см. Рис.4).

Рис. 4 Синхронная репликация в SAP HANA

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

В случае сбоя, администратор переподключает систему к резервному хранилищу и перезапускает HANA.

1.4. Уровень третий. Системная репликация (System Replication)

Системная репликация – это алтьтернатива High Availability решениям, обеспечивающая наиболее короткий RTO, и совместимая с решениями всех аппартных партнеров SAP. Эта репликация использует подход N+N, с использованием резервной системы, состоящей из того же числа узлов, что и основная система. Каждая служба и экземпляр основной системы HANA работают синхронно со службой и экземпляром резервной системы (см. Рис.5).

Рис. 5 Системная репликация в SAP HANA

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

Экземпляры резервной системы работают в режиме «живой репликации» (live replication mode). В этом режиме все службы резервной системы постоянно синхронизируются со службами основной системы, включая репликацию и сохранение данных и журналов транзакций, а также загрузку данных в память. В этом режиме резервная система не обрабатывает запросы.

В альтернативной конфигурации, называемой репликацией без предварительной загрузки (replication without data-preload), резервная система не загружает данные в память, соответсвенно, использует сранительно небольшой объем ресурсов оперативной памяти. Это позволяет резервной системе использоваться в качестве тестового контура или контура разработки. При этом RTO в случае отказа в такой конфигурации, разумеется, будет больше.

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

Поддерживаются следющие режимы системной репликации:

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

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

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

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

2.     Поддержка переключения управления при сбое (Failover)

2.1. Переадресация IP

Переадресация IP является методом поддержки end-to-end подключения, поскольку позволяет поддерживать восстановление SQL и HTTP клиентов с крайне малым периодом восстановления и без специальных клиентских настроек. Принципом IP переадресации (также известным как VIP6) является определение дополнительного логического имени хоста  с отдельным логическим IP адресом (10.68.104.51), и последующей идентификацией его с МАС адресом оригинального хоста в основной системе путем привязки его к одному из интерфейсов хоста (см. Рис.6). В рамках failover процедуры выполняется скрипт, который переопределяет логический IP адрес соотвествующего failover хоста в резервной системе.

Рис. 6 IP переадресация в SAP HANA

Переадресация IP может быть реализована с помощью ряда методов, к примеру, с ипользованием Linux команд, управляющих сетевыми ARP таблицами, непосредственным конфигурированием сетевых свичей L2 канала или с использованием кластерного ПО. После конфигурации IP, ARP кеши следует очистить, чтобы обеспечить мгновенное востановление работы.

Переадресайия IP требует, чтобы рабочие и failover узлы работали в пределах одного сетевого сегмента – L2. Это зависит от конфигурации пользовательской сети, но чаще всего используются L2 и L3 схемы (такие как Ethernet over MPLS), что делает такой вариант жизнеспособным во многих случаях. Если резервная система полностью отделена от от L3, то в этом случае альтернативным вариантом является DNS переадресация.

2.2. DNS переадресация

Клиенты обращаются в DNS сервер для получения IP адреса требуемого HANA хоста. Многие DNS решения проддерживают failover конфигурацию используя короткие (несколько минут или менее) TTL поля и поддерживают автоматическое переключение.

В процессе процедуры failver переключения, выполняется скрипт, который заменяет IP основного сервера на IP резервного для всех хостов сисемы, и в далеьнейшем все клиентсике подключения перенаправляются на резервный сервер (см. Рис.7).

Рис. 7 DNS переадресация в SAP HANA

Преимущества DNS и IP переадресации заключаются в том, что для их реализации не требуется специальных клиентских настроек или конфигураций. Кроме того, поддерживаются disaster recovery конфигурации, когда основная и резервная системы могут находиться в двух разных сетевых доменах. Один из недостатков такого подхода заключается в том, что кеширование DNS занимает определенное время.

2.3. Служба автоматическго перезапуска (Service Auto-Restart)

В случае выхода из строя ПО (или преднамеренного вмешательства администратора) и отключении одного из настроенных HANA сервисов, сервис будет перезапущен службой SAP HANA Service Auto-Restart, которая автоматически обнаружит сбой и перезапустит остановленный сервис. После перезапуска этот сервис загрузит данные в память и таким образом восстановит работу. Несмотря на то, что все данные остаются в безопасности (RPO=0), работа сервиса восстановления занимает определнное время.

2.4. Автоматическое переключение при сбое (Host Auto-Failover)

Host Auto-Failover – это локальное N+m решение (m чаще всего = 1), которое может быть использовано в качестве дополнительной или альтернативной меры к репликации системы, описанной выше. Один или более резервных серверов добавляются к основной системе и настраиваются на работу в режиме ожидания. В этом режиме они не содержат никаких данных и не принимают запросы (см. Рис.8).

Рис. 8 Реализация Host Auto-Failover с резервным узлом

Когда основной сервер выходит из строя, резервный автоматически «занимает» его место. Поскольку резервный узел может принимать на себя управление с любого рабочего узла, он должен иметь доступ к всей БД. Этого можно достичь путём использования разделяемого серверного хранилища с распределенной файловой системы, либо специализированного ПО, которое использует программный интерфейс SAP HANA – Storage Connector API – для динамического монтирования сетевого хранилища, к примеру, с помощью Fiber Channel (см. Рис.9).

Рис. 9  Динамическое монтирование сетевого хранилища

Одним из важных вопросов восстановления является вопрос о том, как восстановить клиентские подключения SAP HANA, которые были сконфигурированы для работы с определнных хостом, и должны будут перенаправиться на резернвный узел в процессе Host Auto-Failover.

Один из подходов заключается в использовании IP и DNS, как это описано выше. Кроме того SQL/MDX клиенты могут быть сконфигурированы с учетом возможности подключениия к нескольким хостам в случае необходимости, включая резервный узел (список мульти-узлов содержится в строке подключения). Код подключения (ODBC/JDBC) использует циклический подход для восстановления и гарантирует, что клиеты будут подкючены к БД HANA даже в случае failover. Для поддержки HTTP клиентов, использующих сервис HANA XS, рекомендуется установить внешний балансировщик нагрузки HTTP load balancer (HLB), к примеру, SAP Web Dispatcher. Такой балансировщик предназначен для мониторинга веб-сервисов на всех хостах основной и резервной систем (см. Рис.10).

Рис. 10 Поддержка переключения управления при сбое с помощью балансировщика нагрузки HTTP load balancer

HLB, который служит в качестве обратного веб-прокси, перенапраявляет HTTP на нужный сервер в случае отказа экземпляра HANA. HTTP клиенты сконфигуриророваны для использования IP адресов HLB (полученных через DNS).

Один из наиболее опасных сценариев, который может произойти с host auto-failover, это split-brain. Это может произойти в случае, если узел основной системы в действительности не вышел из строя, а только потерял сетевое подключение, и в результате резервный сервер прнимает управление на себя. В этом случае работа узлов будет несинхронизировна, и каждый узел будет обращаться в БД, что может привести к повреждению согласованооти данных. Подобную ситуацию можно разрешить с ипользованием вышеупомянутого API, подключив «потерянный» узел как резервный.

В дополнение к вышеупомянутым методам поддержки High Availability в SAP HANA может применяться еще один подход, подразумевающий репликацию с использованием инструмента SAP Landscape Transformation (SLT). В этом случае High Availability может быть достигнута путем создания параллельных потоков репликации SLT из общего источника данных в распределенные HANA системы. При этом обе системы могут активно работать независимо друг от друга, и в случае сбоя одной из них другая будет доступна.

Дополнительные источники:

  1. Цикл вебинаров SAP HANA Online - http://events.sap.com/ru-sap-hana-online-series/ru/rd_agendaglance?bc=2%251%250
  2. Introduction to High Availability for SAP HANA http://www.saphana.com/docs/DOC-2775
  3. SAP HANA Administration Guide http://help.sap.com/hana/SAP_HANA_Administration_Guide_en.pdf
  4. SAP Note 1730932 - Using backup tools with Backint for HANA
  5. SAP Note 1913302 - Suspend DB connections for short maintenance tasks
  6. SAP HANA Master Guide: http://help.sap.com/hana/SAP_HANA_Master_Guide_en.pdf
  7. Scalability - SAP HANA: http://www.saphana.com/docs/DOC-2022.
  8. More information about SAP HANA can be found on http://help.sap.com/hana_platform/