Комментарии 11
Да, про подход к выполнению требований регуляторов по персональным данным было бы очень интересно узнать. Это в некоторых проектах сдерживает от использования облачных решений от Azure и AWS.
Спасибо за интерес к статье. Действительно, многие компании, планирующие заказывать ресурсы в облаке, сталкиваются с необходимостью обрабатывать и хранить персональную информацию о заказчиках и сотрудниках. Попробуем раскрыть эту тему подробнее в очередных статьях.
Сэкономить получилось?
Сокращение затрат и времени были одним из основных приоритетов проекта. С учетом оптимизации ресурсов ощутимо сэкономили по финансовым затратам по сравнению с on-premise набором железа, заказанным по эстиматору SAP. Плюс выиграли несколько месяцев и стартовали разработку раньше чем если бы дожидались стандартных процедур закупки оборудования, принятых у заказчика.
В облако перевили только разработку или продуктив тоже? Осталась ли у заказчика на "земле" инфраструктура? Как связывали одно со вторым?
Разработка и тестовая среда SAP были первоначально целиком развернуты в облаке. В облаке также был развернут и продуктив. Надо отметить что на начальном этапе продуктив сразу после разворачивания и начальных тестов «поставили на паузу». Это позволило одновременно сэкономить на потреблении ресурсов и обеспечить возможность немедленного старта по окончании разработки. Инфраструктура «на земле» осталась. Сетевая связь с ней осуществлялась посредством Site-to-Site VPN, предоставляемого в Azure.
Добрый день.
По №7 пару вопросов:
1. При еженедельном копировании бекапов хАны получается в худшем случае RPO порядка 7 дней. Заказчик с этим согласен? При восстановлении этих бекапов на «земле» у заказчика есть необхдимое железо?
2. Если правильно понял, то для DR используете другое облако. Реплики ханы делаете HSR'ом? А серверы приложений чем и как реплицируете из Azure в «другое» облако?
Из нюансов с которыми столкнулись (не в части хАны) — Azure Site Recovery при репликации в Azure не поддерживает VMware-машинки со включенным Fault Tolerance и об этом нигде не написано в документации.
По №7 пару вопросов:
1. При еженедельном копировании бекапов хАны получается в худшем случае RPO порядка 7 дней. Заказчик с этим согласен? При восстановлении этих бекапов на «земле» у заказчика есть необхдимое железо?
2. Если правильно понял, то для DR используете другое облако. Реплики ханы делаете HSR'ом? А серверы приложений чем и как реплицируете из Azure в «другое» облако?
Из нюансов с которыми столкнулись (не в части хАны) — Azure Site Recovery при репликации в Azure не поддерживает VMware-машинки со включенным Fault Tolerance и об этом нигде не написано в документации.
Добрый день, спасибо за вопрос. Классификация системы по необходимым уровням RTO и RPO было существенной частью проекта и разные риски закрываются различными мерами.
1. Еженедельное копирование системы «на землю» является страховкой от такого риска как отключение Azure в целом. Система также продублирована внутри облака и там RPO значительно более жёсткий. При восстановлении системы вне облака у Заказчика есть возможность оперативно предоставить временное оборудование.
2. Основной механизм отказоустойчивости базируется на размещении ресурсов в разных availability zone. В качестве дополнительного метода по снижению рисков идёт выгрузка бекапов в 2 ЦОД «на земле». Реплики HANA в другое облако в данном проекте не пригодились.
1. Еженедельное копирование системы «на землю» является страховкой от такого риска как отключение Azure в целом. Система также продублирована внутри облака и там RPO значительно более жёсткий. При восстановлении системы вне облака у Заказчика есть возможность оперативно предоставить временное оборудование.
2. Основной механизм отказоустойчивости базируется на размещении ресурсов в разных availability zone. В качестве дополнительного метода по снижению рисков идёт выгрузка бекапов в 2 ЦОД «на земле». Реплики HANA в другое облако в данном проекте не пригодились.
Спасибо за ответы. Уж простите за занудство (как говорится, у кого чего болит, да и кейс интересный), но я правильно понял, что DR внутри Azure cделан через HSR-реплики БД и ASR-реплики серверов приложений в другую AZ (т.е. как по ажуровским SAP DR best practice) или нет :)?
И еще вопрос (если NDA позволяет) — что используете в Azure для бекапов БД? Местный Azure Backup for SAP HANA или изготоваливали свою CРК?
Заказик не рассмативал варинт с multitarget-репликацией хАны ( + вторая асинхроная реплика в свой ЦОД) раз есть некоторое подменное железо?
И еще вопрос (если NDA позволяет) — что используете в Azure для бекапов БД? Местный Azure Backup for SAP HANA или изготоваливали свою CРК?
Заказик не рассмативал варинт с multitarget-репликацией хАны ( + вторая асинхроная реплика в свой ЦОД) раз есть некоторое подменное железо?
Для БД выбрали репликацию средствами HSR. Для сред в которых требовалось более одного ASR cервера приложений разместили их по разным availability zone, что даже превысило требуемые бизнесом параметры доступности.
Что касается бекапов, то на момент внедрения системы Azure Backup еще не поддерживал бекап ханы и пришлось строить конструкцию ввиде бекапа средствами sql + cron с использованием Azure Backup только для сбора уже готовых архивов с данными.
Multitarget не использовали. Это было бы избыточно исходя из утвержденных уровней доступности.
Что касается бекапов, то на момент внедрения системы Azure Backup еще не поддерживал бекап ханы и пришлось строить конструкцию ввиде бекапа средствами sql + cron с использованием Azure Backup только для сбора уже готовых архивов с данными.
Multitarget не использовали. Это было бы избыточно исходя из утвержденных уровней доступности.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
7 уроков по итогам разворачивания SAP HANA на базе MS Azure для российской компании