Резервное копирование (РК) данных IBM SAP HANA средствами IBM Tivoli Storage Manager

  • Tutorial
Что такое IBM SAP HANA

SAP HANA — High Performance Analytic Appliance. Это современная платформа для бизнес-приложений и аналитики в реальном времени с исполнением запросов в оперативной памяти.

IBM подготовило сбалансированную платформу для решения задач реализуемых SAP при помощи технологии вычислений In-memory. Комплекс IBM SAP HANA состоит из вычислительных блоков, которые гибко масштабируются и содержат ПО GPFS — высокопроизводительную файловую систему с общим доступом к дискам, обеспечивающим высокую отказоустойчивость.

Как организовано резервное копирование SAP HANA штатными средствами

Резервное копирование применяется для защиты данных от ошибок при работе с дисками.

Резервное копирование SAP HANA включает:
  • РК на файловую систему (внешние смонтированные диски)
  • РК содержащих реплику данных из ERP, данные моделирования
  • РК осуществляется с помощью «SAP in-memory computing studio» или при помощи SQL скриптов через командную строку
  • Для РК файлов конфигураций выполняется ручное копирование их на другое устройство хранения
  • РК логов для версии SAP HANA 1.0 недоступно

Расчёт пространства на дисках для РК ведётся исходя из используемой оперативной памяти для SAP HANA + 10-50% резерв. Только используемое пространство будет зарезервировано.

Рассмотрим реализацию системы резервного копирования для SAP HANA объёмом в 3,5 ТБ

Как показано на рисунке 1, рассматриваемый комплекс SAP HANA состоит из 8 нод. 7 нод продуктивных, одна из которых выделена в качестве мастер ноды, а 8-ая Standby нода для реализации функции высокой доступности в рамках одного кластера.

Рисунок 1 – Кластер SAP HANA



Стоит обратить внимание, что решение IBM SAP HANA построено с использование GPRS кластера, и не требует обслуживания и наличия дискового массива для работы самого комплекса.

На мастер ноду устанавливается клиент резервного копирования Tivoli Storage Manager и Tivoli Storage manager for SAN, также рекомендуется установить их на Standby ноду для исключения единой точки отказа.

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

Для организации длительного хранения резервных и архивных копий к комплексу IBM SAP HANA подключаем дисковую систему. В итоге средствами DataStudio на дисковом хранилище получаем «плоские» файлы для дальнейшего копирования средствами Tivoli.

Клиент резервного копирования забирает данные с дисковой системы и инициирует запись данных на ленту. Для снижения нагрузки с продуктивного сервера от процесса резервного копирования предлагается использовать Lan- Free клиента. Для этого в Мастер ноду и Standby ноду кластера добавлены FC адаптеры. В качестве дисковой системы, которая сможет удовлетворить требования заказчика к объёмам хранимых данных и обеспечить высокую скорость доступа к ним, была предложена дисковая система IBM Storwize V7000

Компоненты решения:
  • Ленточная библиотека
  • Дисковая система – Storwize V7000
  • Сервер резервного копирования
  • SAN свичи
  • ПО — Tivoli Storage manager Extended Edition
  • ПО — Tivoli Storage manager for SAN

Пример расчёта

Рассмотрим реализацию системы со следующими требованиями:
  • Размер продуктивной базы – 3,5 ТБ
  • Допустимое окно резервного копирования — 5 часов
  • Кол-во ежедневных копий – 1
  • Срок хранения ежедневных копий — 90 дней
  • Хранить на протяжении года ежемесячные копии
  • RPO – 24 часа
  • RTO — 5 часов

Произведем расчёт объёма данных в планируемом хранилище согласно требованиям.
Размер набора файлов для одного узла HANA 512ГБ х 1.5 = 750ГБ (документация к SAP HANA коэффициент увеличения объёма при РК от 10% до 50 %).



Сделаем расчёт ленточной библиотеки с учетом требований по скорости



Итого с учётом начальных требований
Объём данных РК за год для хранения на лентах — 617 ТБ
Кол-во лент – 412 картриджей LTO5
Число драйвов в библиотеке не менее 4-х

Рисунок 2 — Коммутация кластера SAP HANA для реализации Lan- Free Backup



  1. Сеть для подключения пользователей к приложению(SAP HANA Client Network)- 1 Gb Ethernet – 2 Порта на каждый сервер
  2. Сеть для организации GPFS кластера- 10 Gb Ethernet – 2 Порта на каждый сервер
  3. Сеть для репликации данных (SAP Replication) –1 Gb Ethernet 2 Порта в каждой ноде
  4. Сеть подключения HANA к Storwize — 8GB FC По 2 порта На мастер и Standby Ноды
  5. Сеть подключения к ленточной библиотеке по 2 FC Порта для мастер и Standby ноды
  6. Сеть для управления серверами (IMM net) управление оборудованием – 1 Gb Ethernet – 1 Порт на сервер
  7. Высокоскоростная сеть для обмена данными между узлами SAP HANA на уровне приложения(SAP HANA net) — 10 Gb Ethernet – 2 Порта на кадждый сервер
  8. Cеть управления приложением SAP(SAP Appliance Management net). Система мониторинга 1GB Ethernet

Заключение

Разработанное решение позволит компании реализовывать требование по хранению резервных и архивных копий данных на ленточных носителях, тем самым обеспечить их длительное и экономически эффективное хранение (с точки зрения стоимости за 1ТБ хранимых данных), и реализовать различные политики хранения данных в соответствии с законодательными и отраслевыми требованиями.

Предложенная система позволяет интегрировать данные SAP HANA в централизованную систему резервного копирования на базе IBM Tivoli Storage manager.

В версии IBM Tivoli Storage Manager for ERP 6.4 анонсирована поддержка SAP HANA.
IBM
120.19
Company
Share post

Comments 5

    0
    Интересно, а почему политики резервного копирования и сроки хранения указаны в «оторванном» от философии TSM виде? Без использования механизма версий? Уже не первый раз вижу проекты СРК в которых чисто NetBackup-ную логику реализуют на TSM, не обращаясь к «флософии» системы.
      +1
      «Философия» TSM — это гибкость в управлении и хранении данных.
      Поддержка механизма версий и Progressive incremental backup (incremental
      forever) есть для файлового копирования и для копирования виртуальных машин
      VMWare.
      При осуществлении резервного копирования SAP или Oracle интеграция идет со
      стороны штатных средств (утилит) резервного копирования этих продуктов:
      BR*Tools и RMAN соответственно. Управление версиями и методами копирования
      целиком лежит на этих утилитах. TSM в этом случае является для них ресурсом
      хранения.
      При этом (на примере Oracle/RMAN) TSM может управлять размещением данных
      при помощи managementclass. Например резервные копии БД направляются сразу
      на ленты, а redo logs сначала в дисковый Storage pool с последующей
      обязательной миграцией на ленты.
      Ну и далее дополнительные меры по защите данных: создание копии данных на
      второй ленточной библиотеке, репликация на резервную площадку, создание
      отторгаемых копий, etc
      0
      Неплохо бы увидеть продолжение статьи с деталями TSM (политики/расписания/клиенты). На курсах по TSM задавал прямой вопрос инструктору — бизнес требования такие ( размер продуктивной базы, окно резервного копирования, eжедневные копии, еженедельные копии, сроки хранения копий), как настроить TSM для выполнения данных требований? Инструктор отказался ответить на данный вопрос, при том, что свободного времени было предостаточно. Самый бесполезный курс, который я когда-либо посещал.
        0
        Для каждого курса есть описание, что будет изучаться на данном курсе и
        какие skills Вы получите после его завершения. Исходя из этой информации
        необходимо строить свои ожидания от курса.
        На практике впечатления от курса сильно зависят от инструктора. Зачастую,
        инструктор может лишь вскользь коснуться тем, не предусмотренных данным
        курсом, но при этом «зажечь» желание изучить их самостоятельно. Но бывают
        ситуации, когда инструктор плавает в «теме» или продукт ему не интересен.

        Для самостоятельного изучения рекомендую ознакомится с RedBook по TSM — IBM
        Tivoli Storage Management Concepts
        www.redbooks.ibm.com/abstracts/sg244877.html?Open

        Данный RedBook по версии TSM 5.3, но написан очень просто, правильно и
        доступно.
        В нем описаны базовые понятия, которые актуальны и для TSM V6.

        После ознакомления с основными понятиями можно читать документацию TSM V6.
        Будет понятен смысл нововведений и улучшений в TSM V6

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

        Так же хочу прокомментировать отказ инструктора дать Вам готовое решение
        для Ваших бизнес задач, на это есть несколько причин:
        1. Вы просите от инструктора решить Ваши (Бизнес) Задачи, а это не входит в
        рамки курса по продукту. Обычно за подобные услуги берут деньги;
        2. Инструктор не будет точно вникать в Ваше окружение и Задачи, а возможно
        просто даст несколько рекомендаций. Может так случится, что по каким-то
        причинам, эти рекомендации Вам не помогут (Инструктор банально не обладал
        всей информацией). Но Вы можете это истолковать как неграмотность
        Инструктора и недостатки Продукта (и начнете оставлять негативные отзывы).
        Инструктор не хочет (да и не будет) брать на себя такую ответственность +
        см. пункт №1.
          0
          Спасибо за подробный ответ!
          К сожалению, мои ожидания от этого курса не оправдались.
          Я не просил инструктора решать мои конкретные бизнес задачи, а просил его научить меня решать эти задачи. На абстрактном, возможно сильно упрощённом, типовом примере, который он же и сам возьмёт из головы. И, дабы не нагружать его голову, взял абстрактный пример задачи, которые я решаю регулярно, но при помощи других систем резервного копирования.

          По другим курсам, которые были прослушаны в УЦ IBM, у меня нет претензий ни к инструкторам ни к продуктам, всё проходило на достаточно высоком уровне.

      Only users with full accounts can post comments. Log in, please.