Коллеги, добрый день!

Подскажите, если стоит задача создания резервной копии инстанции SAP, продуктив которой крутится на IBM P-Series (ОС AIX), на оборудовании x86 (ОС Win), то возможна ли такая связка?

Дано:
Основная инстанция SAP - IBM P-Series c ОС AIX
Целевая инстанция РЦОД - x86 (ОС Win)

Необходимо:
Сделать резервную копию в РЦОД, чтобы в случае отказа основной системы, можно было поднять резервную в течении 4 часов, при условии, что это другая архитектура "железа".

Причины:
Экономия средств на оборудовании в РЦОД, чтобы не покупать еще один P-Series. А также желание разместить РЦОД в облаке у подрядчика, а как известно в облачных ЦОД очень редко встречаются P-Series сервера.

Интересует:
Возможна ли реализация такого решения? Если возможна, то каковы особенности? Если нет, то какие причины? Что вы могли бы посоветовать в этой ситуации?
Заранее спасибо

давайте сперва разделим опции и понятия...
1 часть это БД
2 часть это сервер приложений SAP AS: ASCS, PAS, AAS либо CI+DIA в зависимости от версии

Как я понял Вашу структуру:
AIX/POWER - БД + SAP AS

При таком раскладе вторая часть - SAP AS, может быть любой unix-операционкой (насколько я помню, windows в таком формате не поддерживается).
Т.е. с точки зрения архитектуры возможен такой вариант БД-AIX + SAP AS - x86...например linux SLES/REDHat

Теперь же посмотрим на вопрос с БД (буду отталкиваться от оракла):
согласно ноты 552464 - What is Big Endian / Little Endian? What Endian do I have?, Ваша БД относится к 4102 Big Endian, а выбранная Вами целевая инфраструктура x86 относится к 4103 Little Endian, т.е. для перехода потребуется обязательная миграция БД посредством экспорта\импорта данных.
Таким образом мы получаем невозможность доката БД железными средствами, например репликацией полок.
А вот возможность доката БД средствами ее самой, при условии разницы начальной и конечной кодовых страниц, это стоит узнавать у вендора БД. НО, почти наверняка, SAP такую самодеятельность поддерживать не будет и откажется от всяких гарантий.

Ну и краткое резюме по вопросу: разделение архитектур возможно, НО БД должна оставаться, как минимум, в пределах одной ОС.
конкретно по Вашему вопросу, на мой взгляд, архитектура не жизнеспособна по многим техническим аспектам.

Ну почему же SAP не поддерживает.
BRTools уже вполне штатно поддерживают transportable tablespace, в том числе с перекодированием между разными ендианами. Ноты есть на эту тему.
Кроме того, никуда не делось традиционное гетерогенное копирование (R3Load)
Ну и даже с помощью expdp и impdp можно вполне получить работоспособную систему на другой платформе, проверялось когда-то. Правда вот этот вариант сап да, не поддерживает. Кроме того тут надо определенные композиции на бубне исполнять.

Другое дело что все эти процедуры больше подходят для разового копирования, а не для регулярного штатного бэкапа. И за 4 часа очень затруднительно будет поднять систему на новом месте.

Но вот я, например, как раз для похожего случая хочу исследовать схему разового поднятия копии базы на другой платформе, а потом синхронизировать их с помощью Oracle CDC.
Соответственно в какой-то момент будет онлайн две копии одной базы на разных платформах. Потом можно будет переключиться.

adem
собственно это я и написал - разовая процедура возможна, а вот в формате disaster recovery врядли.

А Вы не смотрели ноты по поводу поддержки сапом инструментов oracle cdc? И еще вопрос - проблем с конвертацией на лету не будет?
Эти вопросы относятся как раз к поддержке сапом решения по переезду на другую платформу на лету.

Кстати, вопрос к ТС-у - а какие требования к RPO?
С RTO, вроде как, понятно.

Мда, облом.

Я говорил, что только собираюсь исследовать вопрос. И вот посмотрел. Действительно, есть нота 105047, в которой говориться что CDC можно использовать только для BO. Для других типов систем нельзя.
Надо что-то дальше думать. У меня задача перенести большую базу на другую платформу, с другим ендианом, с минимальным даунтаймом.

А у вас и сервера БД и сервера приложений под IBM P-Series c ОС AIX?
Если да. Не думали сделать основной и резервный сервера БД под IBM P-Series c ОС AIX на имеющемся железе. А сервера приложений вынести на x86 Linux?

я бы порекомендовал обратить внимание на функционал SWPM в части эскпорта/импорта (split, параллельный экспорт/импорт и т.д.)
время можно сократить довольно кардинально.

+ "выкусывание" вторичных индексов на экспорте

Действительно интересовал именно disaster recovery на отличной от основной платформе.

RPO зависит от периодичности бэкапирования. Предполагалось 24 часа назад.

Я так понимаю, что наиболее рабочая версия лежит скорее всего в конвертации БД - кстати у нас рассматривается Oracle - и последующей ее синхронизацией. Учитывая, что SAP не на поддержке, то остаются только обходные пути, которые, на мой взгляд, будут высокорискованными и не гарантируют 100% отказоустойчивость в обозначенные RTO и RPO.

Может быть у кого-то все же есть проверенный вариант такой архитектуры?

У нас БД, в отличие от ТС, на HP-UX, а целевая платформа Linux. Но суть это не меняет. Сервера приложений HP-UX + Linux. С ними-то как раз нет никаких проблем. Перенос и всякая тусовка между серверами саповских аппликух дело тривиальное.
Проблема-то именно в базе. Когда ее размер в много терабайт простое переписывание этих файлов на другой сервер (по сети) уже может занимать от нескольких часов до нескольких суток.
Не говоря уже о конвертации либо экспорте/импорте.
А возможности синхронизации/доката дельт между разными платформами, которая бы сняла проблему, я пока не нашел. CDC для саповских систем, оказывается, использовать нельзя

То, что я говорю - называется изменить подход к решению задачи. И решать не проблему, а ее причину.
HP-UX или AIX это не принципиально.
Сносите все HP-UX сервера приложений. Оставляете только инстанцию БД и совсем маленькую центральную инстанцию ну 2 диалога, 1 фон, MessageServer и т.п.
Создаете диалоговые инстанции на x86 Linux. На высвободившемся RISK/HP-UX железе поднимаете StandBy на инстанцию БД и центральную.
Не решаете проблему разных платформ, а исключаете ее.

я так понял у человека один риск сервер. А игры с доменами для основной и резервной БД на одной железяке - слабое утешение для нервной системы.

Вообще есть железное правило - если покупаете железяку, всегда берите две.


пару копеек:
- подумать о выведении в RO части данных чтобы в час Х хотя бы на это не тратить время.
- конвертацию делать не по сети ,а на подключенный локально массив. после окончания переключить его к новому серверу.

HP-UX серверов много. И на линуксы перевести сервера приложений - это тоже тривиальная задача, тут вообще никаких проблем. 100 раз делано.
Проблема в другом - как перевести БД на другую платформу. Чтобы избавится совсем от хпюксных железок и выбросить их совсем.
Ибо старые, не тянут по производительности и дорогие в поддержке..


А вот как это на практике сделать? На какую файловую систему или структуру хранения можно записать файлы на hpux чтобы потом прочитать их на линуксе? Есть опыт?

Я не нашел даже теоретического решения. Форматы LVM у них разные. Файловые системы у них разные. Нашел драйвер vxfs для линукса, но и он не смог прочитать
отформатированный в HP-UX раздел. Скорее всего из-за разных endian.


А вот об этом можно поподробнее? Я про подобный succces story слышал, но как это технически было реализовано - непонятно.
Особенно с учетом что исходная система живая продуктивная и пока на целевом сервере разворачивается слепок базы, на исходной будут работать пользователи.

Внешняя дисковая полка с поддержкой NFS по каналу 10G

ну совет был сильно абстрактный.

если ваши самые большие таблицы секционированы и часть секций не используется для записи. То их можно вынести в отдельное ТП и сделать его RO. ну и переносить соответственно не в час Х, а заранее.