Комментарии 7
Для эффективного использования хранилищ под продуктивные HANA использовали общие диски без системной репликации БД средствами SAP. Все это завернули в Active-Standby кластер SUSE HAE на базе Pacemaker. Да, время восстановления немного дольше, чем с репликацией, зато получаем экономию пространства СХД в два раза и как следствие экономию бюджета заказчика.
«немного дольше» ??? При HANA-репликации время восстановления фактически равно времени отработки takeover-команды на секондари-БД и обычно это минуты. В вашем варианте когда/если вдруг продуктивная CХД ляжет и не встанет вы будете восстанвливать дата-бекап(ы) и лог-бекапы (и хорошо если будет куда) и это точно не минуты для больших БД (о каких обьемах, кстати, речь?). Какое RTO прописано в SLA c заказчиком? Он в курсе такой «особенности» реализации продуктивного ландшафта?
Спасибо за пост. Интересный кейс.
Такая архитектура выбрана как наиболее оптимальная по соотношению «цена-качество». В данном случае RTO для прод-систем — 4 часа. Объемы небольшие. Самая ресурсоемкая БД — до 10ТБ. Время ее переключения на резервный узел занимает 15-20 минут. Время восстановления из резервной копии – не более 40 минут. Естественно, заказчик в курсе.
Время ее переключения на резервный узел занимает 15-20 минут. Время восстановления из резервной копии – не более 40 минут.
Вашими специалистами? Или специалистами заказчика?
Если вашими — то в стоимость простоя сверху включены штрафные санкции на простой всей организации и упущенную прибыль? Или как обычно — «мы дадим скидку на следующий месяц»?
Не увидел уникальных сложностей, достойных статьи. Вы расписали типовой процесс миграции. И даже хуже — вы по всей видимости мигрировали через полные бэкапы (судя по скриншоту cutover-плана), без миграции через standby (нет упоминаний), что позволяло бы осуществить миграцию не за часы, а за минуты. Привет от коллеги, участвовавшего в миграции одной из крупнейшей ERP из Европу в Россию размером в 130 Tb. Даунтайм составил около 15 минут со всеми делами при этом канал был 10 гбит с задержкой в 70-100 мс
Безусловно, реализация миграции через standby – это способ оптимальный и менее затратный по времени. Но только для случая, когда есть возможность использовать такую опцию. По независящим от нас причинам у нас не было возможности организовать каналы связи, поэтому пришлось упражняться с миграцией через полные бекапы. Что касается самого процесса миграции в части техники – все верно, тут особо ничего не придумаешь. Особенность именно этого кейса – это сроки. Так что статья больше не про технику миграции, а про нюансы и сложности, с которыми мы столкнулись, и которые успешно решили.
Третий из наиболее часто встречаемых аргументов – высокая стоимость построения инфраструктуры для реализации сценариев высокой доступности и DR.
Обычно топ менеджмент строит планы на 1-2 года. Потом хоть трава не расти. KPI же годовой, а капитальные затраты просадят показатели.
Собственная инфраструктура полностью отбивается за 2-3 года. Потом стоимость обслуживания снижается.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Опыт смены SAP-хостинга: как мигрировать системы, чтобы не было мучительно больно