Миграция систем SAP в рекордные сроки. Оптимизация затрат на хостинг и сопровождение

Дмитрий Сурилов. По статистике интерес к услуге SAP-хостинга обусловлен следующими факторами:

1. Аутсорсинг непрофильной деятельности. Молодым компаниям, которые выбирают SAP-хостинг, необходима миграция системы на хостинговую платформу. Благодаря аутсорсингу реализация таких проектов не требует больших вычислительных мощностей, обеспечивает масштабируемость услуги и оплату в соответствии с текущими потребностями, а также возможность не тратить ресурсы на развитие непрофильных компетенций.
2. Вынужденное делегирование ответственности (CIO управляет отношениями с партнером, партнер отвечает за SLA) крупными компаниями, которые не хотят нести ответственность за работоспособность системы. В таком случае партнер предоставляет юридические гарантии целостности системы и данных.
3. Реализация сценариев высокой доступности и аварийного восстановления в отношении значимых бизнес-систем, к которым предъявляются повышенные требования. Самостоятельная реализация такого сценария стоитнеоправданно дорого. Кроме того, использование стороннего облачного сервиса позволяет обеспечить необходимую безопасность на приемлемых условиях.
4. Фактор 2027 — отказ вендора от поддержки старой версии системы, в результате чего компании вынуждены обновлять оборудование или приобретать услугу.

В настоящее время на российском рынке компаниям предлагается широкий выбор партнеров SAP-хостинга, которые могут осуществить миграцию в облако.

Дмитрий Сурилов. «Фармстандарт» — крупнейшая компания в российской фармацевтической отрасли, которая производит более 300 наименований препаратов.

«Фармстандарт» внедрила систему SAP в 2015 г. Размещение и сопровождение систем обеспечивала компания itelligence. К 2019 году на рынке SAP-хостинга появились новые игроки, повысилась конкуренция и снизилась стоимость услуги, и «Фармстандарт» приняла решение выбрать нового подрядчика и перенести системы в облако.

Александр Хайдуков. В середине 2019 года «Фармстандарт» инициировала процедуру выбора нового заказчика.

Перед новым подрядчиком ставились следующие задачи:

• Предоставление инфраструктуры для хостинга.
• Миграция систем.
• Пятилетний контракт на сопровождение.

На аутсорсинг были переданы 4 информационные системы — ключевые бизнес-приложения заказчика, содержащие все окружение, т. е. среды разработки, предпроизводственную среду, производственную среду и среду тестирования.

Потенциальный исполнитель должен был выполнить работы по переносу систем, иметь собственный ЦОД в России уровне TIER III по шкале Uptime Institute. Заказчик предоставлял инфраструктуру в аренду, за ее поддержку должен был отвечать исполнитель. Время восстановления системы не должно превышать 4 часа, а восстановление потерянных данных — 1 час. Общий SLA зафиксирован на уровне 99,95%, т.е. около 22 минут простоя в месяц. Сервис технической поддержки должен был предоставляться на русском языке из единого окна.

Требования к исполнителю: обладание техническими компетенциями, соответствие требованиям службы качества заказчика и обязанность нести финансовую ответственность. Особое внимание заказчик уделял проверке фактической организации процессов компании-исполнителя, регламентов и т. д., включая работу сервисной службы, дата-центра и службы безопасности.

Техническая архитектура решения включала не только вычислительные мощности, но и средства и механизмы защиты от сбоев и потери данных.

Для решения SAP HANA DB рассматривалось два варианта отказоустойчивой конфигурации:

1. классическая референсная архитектура — 2-узловой кластер и хранение данных на локальных дисках. В такой системе репликация между узлами обеспечивается средствами СУБД, и доступность СУБД обеспечивается средствами HANA; кластер на уровне операционной системы с общей системой хранения данных.

Мы выбрали целевую инфраструктуру с общей системой хранения данных и кластером на уровне операционной системы.

Преимущества выбранного решения:

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

Серверы приложений размещались в среде виртуализации, которая обеспечивает доступность приложений. Инфраструктура также включала выделенную систему мониторинга, систему резервного копирования и другие сервисы.

Дмитрий Сурилов. Проект миграции — только первый этап. Необходимо определить, как будет реализована поддержка системы и что является зоной ответственности исполнителя. Техническое задание заказчика часто содержит много «серых зон».

Мы предложили заказчику набор услуг в формате RACI-матрицы, которая позволяет четко определить зоны ответственности.

Александр Хайдуков. Заключение контракта и поставка оборудования — также комплексный процесс, в котором участвуют не только заказчик и исполнитель.

Проект «Фармстандарт» предполагал миграцию в частное облако, что подразумевает приобретение оборудования. Оборудование под SAP HANA условно-уникальное и заказывается под конкретного заказчика.

В процессе заказа, поставки и оплаты оборудования, как правило, участвуют производитель или поставщик оборудования, банк/лизинговая или факторинговая компания, а также подрядчик, который будет сопровождать миграцию. Поэтому при планировании необходимо учитывать время на согласования условий со всеми участниками проекта. Кроме того, важно учитывать время года. Это может повлиять на логистику и своевременность поставки.

Кроме того, оборудование под SAP HANA поставляется, как правило, на две-три недели дольше, чем аналогичное оборудование без сертификации. Поэтому необходимо предусмотреть возможности замены. Например, для проекта «Фармстандарт» производитель предоставил замену, которая была использована для тестовой миграции.⁠

Подготовка к миграции — основная часть проекта миграции. Цель этапа подготовки — доказать реализуемость проекта в установленные сроки и подготовить детальный план миграции системы.

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

Основная сложность — синхронизация действий всех участников. Поэтому заказчик должен создать команду специалистов и назначить ответственное за проект лицо.

В проекте «Фармстандарт» команда заказчика работала с предыдущим поставщиком услуги и решала задачи интеграции в рамках нового проекта.

Дмитрий Сурилов. Системы заказчика — это всегда «черный ящик». Аудит, как правило, выявляет возможные конфликты совместимости и позволяет определить требования к конфигурации систем в целевой инфраструктуре.

Александр Хайдуков. На этапе аудита проекта «Фармстандарт» мы выявили проблемы с DNS-адресацией, и нам пришлось оперативно менять конфигурацию системы.

На этапе миграции после переноса части системы в ЦОД часть оставалась в инфраструктуре предыдущего поставщика. Если бы проблемы не были решены, миграция могла закончиться неудачно из-за плохого взаимодействия систем.

Мы сформулировали минимальный набор документов, обязательных на этапе проектирования:

• описание архитектуры — фактически пояснительная записка к техническому проекту;
• концепция миграции — описание методологии миграции;
• детальный план миграции (cutover-план);
• программа испытаний с описанием набора тестов для проверки соответствия состояния целевой архитектуры проектным решениям.

До поставки оборудования для отработки миграции и подготовки конфигурации целевого ландшафта было использовано Облако КРОК. Мы воссоздали рабочий клон целевой системы для проведения тестов, проверки совместимости программного обеспечения, предварительной настройки виртуальных машин для серверов приложений и выбора настроек систем управления баз данных.

Результатом этого этапа стали:

• готовые шаблоны виртуальных машин для серверов приложения, которые мы просто импортировали в готовую инфраструктуру;
• отработанный метод переноса данных;
• целевые параметры конфигурации СУБД.

Такой инструмент, позволяющий создать целевой ландшафт в облаке, доступен без оборудования. Мы планируем получить сертификацию на наше публичное облако, в котором сможем размещать производственные или непроизводственные системы заказчиков.

Александр Хайдуков. К началу этапа тестовой миграции целевая инфраструктура (в том числе на временном оборудовании), согласованные проектные решения и черновик cutover-плана должны быть готовы. Необходимо не просто воспроизвести целевую системную среду, но и подтвердить все требования относительно времени простоя систем и отработать работу всех служб заказчика и исполнителя. В процессе тестовой миграции необходимо проверять и дополнять процедуры, корректировать план миграции, проверять интеграционные связи и фиксировать необходимое для каждого этапа время.

До фактической миграции необходимо сделать как минимум две тестовые миграции.

Дмитрий Сурилов. В cutover-плане прописаны все шаги миграции, которые проверены посекундно. Задача этого плана — убедиться, что боевая миграция уложится в сроки простоя, предусмотренные заказчиком.

Из-за большого количества систем и участников миграция в целом плохо синхронизирована. Большую роль играет и человеческий фактор. В плане указываются шаги миграции, ответственные за них лица и документы, чтобы каждый участник знал свою роль. Кроме того, закладывается резервное время для устранения возможных проблем и прописываются пост-миграционные шаги, тестирование операционных систем, сетевой связанности и т. д.

Только после подготовки и проверки такого плана можно переходить к боевой миграции. 

Александр Хайдуков. Итак, основной этап миграции — подготовка к ней. В случае качественной подготовки миграция носит чисто технический характер.

Продуктивная миграция — фактически просто выполнение шагов cutover-плана.

В нашем проекте боевая миграция проводилась посистемно, по 2-3 системы на каждом этапе (волне). Итогом трехмесячного спринта стали системы заказчика, функционирующие в новом ЦОДе.

Финальным аккордом миграции стала передача систем заказчика на сопровождение. В проекте «Фармстандарта» сервис предоставляется в рамках единого окна, т. е. сервисная служба КРОК принимает все обращения. Вопросы по SAP-базису решает компания itelligence. За полгода работы не было ни одного внештатного простоя системы, и все инциденты урегулированы в рамках уровня обслуживания. Негативных отзывов от заказчика не поступало.

Результаты миграции:

• бесперебойная работа бизнес-приложений SAP;
• существенное снижение затрат на поддержку;
• прирост производительности инфраструктуры;
• высокий уровень сервиса.

Дмитрий Сурилов. Для нашей компании проекты миграции являются типовыми. Но проект «Фармстандарта» — исключение. Он отличается масштабностью и сжатыми сроками реализации. Поэтому нам пришлось использовать новые подходы и новые инструменты. Такой опыт может быть полезен и для других компаний, планирующих миграцию.

Вопрос. Почему была выбрана технология виртуализации, а не контейнеры?

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

Вопрос. Как реализована единая SKD с использованием HANA DB?

Александр Хайдуков. Схема реализована по принципу «актив-пассив». Установлены два узла в кластере для HANA, к каждому узлу подключен один ресурс системы хранения (дисковый ресурс).

Соответственно, на активном узле функционирует HANA в режиме чтение/запись, на резервном узле диски в режиме «только чтение». В случае возникновения каких-то проблем на основном узле, кластер на уровне операционной системы переключает HANA на резервный узел. Масштабирование такой системы осуществляется путем добавления дисков без остановки сервисов для добавления дисковой емкости.

Вопрос. Проводилось ли нагрузочное тестирование в рамках проекта?

Александр Хайдуков. В данном проекте нагрузочное тестирование было неактуально. Размер системы заказчика был известен. Мы добавили дополнительные мощности и запас ресурсов. В целом для уже функционирующей системы нагрузочное тестирование не проводилось с одобрения заказчика, учитывая крайне сжатые сроки.

Вопрос. Кто выступает инициатором обновлений? В случае появления нового Service Pack подрядчик дает рекомендации заказчику или план обновления на согласование или сам выполняет обновления?

Дмитрий Сурилов. Порядок обновлений оговаривается с заказчиком, например, в RACI-матрице или политике компании. Но все зависит от предварительной договоренности.

Вопрос. Как реализована система резервного копирования SAP HANA? Копирование из тестовой системы выполняется заказчиком или эти операции также переданы на аутсорсинг?

Александр Хайдуков. В качестве системы резервного копирования мы используем Veritas NetBackup — внешнюю систему копирования. Система себя хорошо зарекомендовала как решение, которое максимально корректно интегрируется с системами управления базами данных.

Копирование также передано на аутсорсинг. Частота копирования, зоны ответственности и т. д. регулируются контрактом с поставщиком услуги.

Вопрос. Какие существуют варианты подключения к ЦОД: выделенные каналы, IPSec и т.д.?

Александр Хайдуков. Мы предлагаем любые варианты: от простых VPN-каналов до MPLS и темной оптики. Возможно соединение через любого оператора связи. Взаимодействие инфраструктуры — чисто технический вопрос, который решается в зависимости от потребностей заказчика.

Вопрос. Как разграничивается ландшафт разных пользователей? Как обеспечивается доступ администраторов ЦОД к ландшафтам разных клиентов?

Александр Хайдуков. Заказчик получает доступ в инфраструктуру ЦОД как сервис. За все вопросы, связанные с администрированием операционных систем и SAP-базиса, отвечает исполнитель. Заказчик не имеет доступа к операционной системе или сервисам SAP и отвечает только за задачи, связанные с функциональной частью решения, т. е. бизнес-логикой и т. п. Инфраструктура является выделенной и используется исключительно под конкретного заказчика, в нашем случае — «Фармстандарта».

Дмитрий Сурилов. В проекте использовано частное облако. Заказчики редко согласны делить с кем-то оборудование, хотя такие случаи и услуги встречаются. Но чаще всего используются частные облака и серверы под конкретные системы.

Спасибо за внимание!