Для БД выбрали репликацию средствами HSR. Для сред в которых требовалось более одного ASR cервера приложений разместили их по разным availability zone, что даже превысило требуемые бизнесом параметры доступности.
Что касается бекапов, то на момент внедрения системы Azure Backup еще не поддерживал бекап ханы и пришлось строить конструкцию ввиде бекапа средствами sql + cron с использованием Azure Backup только для сбора уже готовых архивов с данными.
Multitarget не использовали. Это было бы избыточно исходя из утвержденных уровней доступности.
Добрый день, спасибо за вопрос. Классификация системы по необходимым уровням RTO и RPO было существенной частью проекта и разные риски закрываются различными мерами.
1. Еженедельное копирование системы «на землю» является страховкой от такого риска как отключение Azure в целом. Система также продублирована внутри облака и там RPO значительно более жёсткий. При восстановлении системы вне облака у Заказчика есть возможность оперативно предоставить временное оборудование.
2. Основной механизм отказоустойчивости базируется на размещении ресурсов в разных availability zone. В качестве дополнительного метода по снижению рисков идёт выгрузка бекапов в 2 ЦОД «на земле». Реплики HANA в другое облако в данном проекте не пригодились.
Разработка и тестовая среда SAP были первоначально целиком развернуты в облаке. В облаке также был развернут и продуктив. Надо отметить что на начальном этапе продуктив сразу после разворачивания и начальных тестов «поставили на паузу». Это позволило одновременно сэкономить на потреблении ресурсов и обеспечить возможность немедленного старта по окончании разработки. Инфраструктура «на земле» осталась. Сетевая связь с ней осуществлялась посредством Site-to-Site VPN, предоставляемого в Azure.
Сокращение затрат и времени были одним из основных приоритетов проекта. С учетом оптимизации ресурсов ощутимо сэкономили по финансовым затратам по сравнению с on-premise набором железа, заказанным по эстиматору SAP. Плюс выиграли несколько месяцев и стартовали разработку раньше чем если бы дожидались стандартных процедур закупки оборудования, принятых у заказчика.
Спасибо за интерес к статье. Действительно, многие компании, планирующие заказывать ресурсы в облаке, сталкиваются с необходимостью обрабатывать и хранить персональную информацию о заказчиках и сотрудниках. Попробуем раскрыть эту тему подробнее в очередных статьях.
Что касается бекапов, то на момент внедрения системы Azure Backup еще не поддерживал бекап ханы и пришлось строить конструкцию ввиде бекапа средствами sql + cron с использованием Azure Backup только для сбора уже готовых архивов с данными.
Multitarget не использовали. Это было бы избыточно исходя из утвержденных уровней доступности.
1. Еженедельное копирование системы «на землю» является страховкой от такого риска как отключение Azure в целом. Система также продублирована внутри облака и там RPO значительно более жёсткий. При восстановлении системы вне облака у Заказчика есть возможность оперативно предоставить временное оборудование.
2. Основной механизм отказоустойчивости базируется на размещении ресурсов в разных availability zone. В качестве дополнительного метода по снижению рисков идёт выгрузка бекапов в 2 ЦОД «на земле». Реплики HANA в другое облако в данном проекте не пригодились.