Карта сайта
Версия для печати

Правда о SAP HANA, высокой доступности и аварийном восстановлении

4 сентября 2013 Вопросы отказоустойчивости в HANA традиционно являются особенно интересными и заслуживающими отдельного обсуждения. Однако в широкое освещение эта тема попадает возможно не так часто, как того требует скорость развития самой HANA как современной технологии и повышающиеся требования к уровню поддержки производительности ИТ-инфраструктуры. В этой связи я привожу перевод статью Девида Халла, посвященную обзору возможностей SAP HANA в отношении DR и HA.
В современном мире ИТ фирмы борются за клиента. У SAP HANA есть конкуренты на рынке, которые позиционируют свой продукт как аналог нашего продукта. Когда наши конкуренты чувствуют, что с появлением нашего продукта им становится трудно дышать, они часто прибегают к публичным сравнениям, в которых пытаются представить свой продукт в более выигрышном свете. Это давно ни для кого не новость; это просто бизнес. Иногда сравнения представляют собой грубое искажение правды о возможностях их продуктов в сравнении с нашими. Это тоже не новость, но такое случается.

Но одно то, что кто-то делает громкое заявление, не означает, что это заявление правдиво. И уж тем более неоправданны сознательные, а иногда даже злонамеренные попытки дезинформировать потенциальных клиентов. Этично ли это? Нет. Но случается ли такое? Да. Вот почему клиентам следует верить тому, что они видят, а не тому, что они слышат. SAP HANA – это продукт, сильные стороны и достоинства которого можно увидеть. Для того чтобы продемонстрировать достоинства нашего продукта, нам не нужно пускать пыль в глаза (или заваливать клиента технической документацией со вкусом сладкой ваты).

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

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

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

Технические подробности во всей их полноте вы можете найти в превосходной документации, только что опубликованной моим коллегой Хаймом Бенделаком (Chaim Bendelac); в них внесены изменения для SAP HANA SP6:

Введение в "высокую степень доступности" SAP HANA

SAP HANA – часто задаваемые вопросы по "высокой степени доступности"


Кроме того, вот моя точка зрения по некоторым фактам о некоторых способах, которыми проектируется и поставляется SAP HANA, чтобы отвечать требованиям, предъявляемым к критически важным приложениям.

Масштабируемость:

SAP HANA поддерживает как вертикальное (scale-up), так и горизонтальное (scale-out) масштабирование. Если клиенты еще не довели использование сервера до предельных значений, то базы данных на этому сервере можно наращивать до предельных для данного аппаратного решения уровней.

Кроме того, у партнеров по аппаратным средствам есть различные конфигурации кластеров, которые могут удовлетворить практически любую потребность клиентов, 56 узлов и  56TB оперативной памяти, которые могут с легкостью хранить сотни терабайт данных в единой базе данных. Присущий SAP HANA параллелизм допускает почти линейную масштабируемость узлов, что было продемонстрировано в рамках крупномасштабного тестирования, например, в рамках петабайтного теста на 100 узлов.

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

Резервное копирование и восстановление:


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

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

Высокая степень доступности (HA):

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

Аварийное восстановление:

Включая последние изменения в SP6, у SAP HANA есть широкий диапазон возможных конфигураций для сред аварийного восстановления, управляемых как аппаратно,так и программно. Используя существующие на сегодня возможности решений, а также осуществив некоторые инвестиции, клиенты могут добиться соответствия времени восстановления (RTO) и точки возврата (RPO) своим требованиям. К числу имеющихся на сегодня решений относятся:
  • Решения в области хранения данных с синхронной репликацией – HP, IBM, Hitachi, Cisco и Fujitsu. Это те же самые решения уровня всего предприятия, которыми клиенты пользуются в конфигурациях, построенных не на SAP HANA, но эти решения также сертифицированы для использования клиентами совместно с SAP HANA.
  • Конфигурации синхронной репликации системы (также известной как "репликация программного обеспечения"), которыми управляет ядро SAP HANA. Использование этих конфигураций гарантирует, что любое изменение, которое сделано в продуктивной системе, будет немедленно сделано и в вашей среде аварийного восстановления, и этим процессом от начала до конца будет руководить база данных SAP HANA. В результате получается конфигурация с нулевой точкой возврата (zero-RPO). Если в продуктивной системе произошло какое-то изменение, то вы можете быть уверены в том, что оно отражено и в среде аварийного восстановления. (Обратите внимание на то, что данные с диска всегда отправляются асинхронно, так же асинхронно, как данные записываются на диск во внутренней системе. И тем не менее, это синхронная опция, поскольку данные обновляются в памяти в среде аварийного восстановления и записываются в журнал синхронно).
  • Полностью асинхронная репликация под управлением SAP HANA. Она позволяет размещать продуктивную систему и среду аварийного восстановления на огромных расстояниях друг от друга (все изменения асинхронно направляются в среду аварийного восстановления). Кроме того, она позволяет выполнять требования клиентов о более высоких показателях точки возврата, предусмотренных в соглашениях об уровне обслуживания, и тем самым сократить затраты и / или увеличить расстояние между центрами обработки данных. То, что ею управляет ядро SAP HANA, позволит конфигурациям аппаратных средств в среде аварийного восстановления обладать некоторой степенью асимметрии, даже быть составленными из средств разных поставщиков, чтобы выполнять дополнительные требования клиентов.
  • Передача резервных копий / журнала. В качестве наименее затратного метода поддержания среды аварийного восстановления клиенты могут регулярно передавать резервные копии и журналы, чтобы в случае отказа иметь возможность восстановить продуктивную среду в другом местоположении. Часто это мероприятие оказывается недорогим и легко реализуемым  (это зависит от потребностей клиента).
Когда мне нужна техническая информация, я предпочитаю обращаться к первоисточнику. SAP предлагает массу источников информации по HANA. Вы можете посетить конференции, обратиться к форумам и блогам в сети SCN или даже к академии SAP HANA Academy или руководствам по внедрению на saphana.com. Что я не рекомендую делать для изучения принципов работы HANA, так это обращаться за информацией к конкурирующим поставщикам. Другие поставщики, скорее всего, скажут вам: "У них все работает неправильно, а правильно – у нас!" Но мы предпочли бы открыто рассказать о себе и позволить клиентам самостоятельно решать, отвечают ли наши решения их требованиям или нет.


Источник: sapland.ru

Дополнительно

Introduction to High Availability for SAP HANAОфициальный сайт компании SAP
SAP HANA: Operations, High Availability and Data Center ReadinessОфициальный сайт компании SAP
Introduction - SAP HANA in Data CentersОфициальный сайт компании SAP
Scalability - SAP HANAОфициальный сайт компании SAP