Сегодня в российском ИТ-сообществе хорошо знакомы с Федеральным Законом ФЗ-152. Этот документ регулирует обработку персональных данных и предъявляет к системам, которые работают с ними, ряд жестких требований. Будем честны —  закон не только защищает данные, но и серьезно осложняет использование зарубежных сервисов, ряд из которых пока сложно заменить отечественными аналогами в настоящий момент. SAP HCM одна из таких систем.  

Ещё в 2014-м году мы поставили амбициозную задачу перенести все системы SAP в облако при построении гибридной инфраструктуры хранения данных. В 2020-м мы смогли её реализовать. С одной стороны, это позволяло обновить наше собственное технологическое ядро, планировать ресурсы и управлять бизнесом realtime. С другой — исключить риск роста расходов на инфраструктуру и поддержку SAP, как для нашей компании, так и для клиентов. В этом посте несколько слов об опыте миграции SAP HCM в Yandex Cloud, причинах выбранных решений и некоторых юридических нюансах. 

Критерии выбора облачного провайдера для миграции 

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

• соответствие 152-ФЗ;

• экономическая эффективность — существенное снижение стоимости владения;

• гарантия функциональности систем SAP и SLA с доступностью выше 99,5%.

Доступность

Обеспечение функциональности SLA с высокой доступностью (99,5%) предоставлялось Yandex Cloud, оно гарантировалось условиями договора, где упоминались уровни качества предоставляемого сервиса. На 0,05% приходились разнообразные сбои оборудования, отказ электропитания, перезагрузки виртуальных машин, регламентные работы и прочий форс мажор непреодолимой силы.  

В подобных случаях Yandex Cloud предлагает перенести систему выключив и включив её, чтобы запустить с другого сервера. Таких ситуаций можно избежать при помощи классических отказоустойчивых решений, например 2 сервера баз данных. Но в нашей ситуации это было не столь рационально, так как несопоставимо с рисками увеличивало стоимость владения.  

Есть бизнесы, в котором даже небольшой простой - катастрофа. Например, крупные ритейлеры, где час простоя будет стоить как пол сервера, пол стойки или полноценный ЦОД. Им нужно чтобы система безотказно работала 24/7. В компаниях, где цикл производства не круглосуточный, отказ SAP на 1 — 2 часа не станет сколько-нибудь существенной проблемой.  

Минимизация затрат и юридические аспекты

Для определения затрат на различные варианты мы провели сравнительный анализ различных вариантов, результаты которого представлены в таблице:

Грубый анализ показывает, что наиболее экономичным решением является Yandex Cloud. При этом в стоимость владения также входит лицензирование оборудования по ФЗ-152, которое не учитывалось в анализе.  

Яндекс Облако сертифицировано по ФЗ-152 для размещения систем определенных классов, под которые как раз подпадает SAP. Но сертификация облака не всегда означает автоматическую сертификацию ИСПДн, которой в данном случае является кадровая система.  

Если взять классическую схему построения информационной системы (физическое оборудование, ОС, гипервизор, виртуальные компьютеры, приложения т.п.), то сертификация требуется всему этому комплексу, т.е. он должен соответствовать принятым требованиям. При работе с Yandex Cloud можно считать, что процесс сертификации оборудования, облака, помещений, где расположено оборудование, гипервизор, т.е. уровня до виртуальных машин, уже выполнен.  

Соответственно мы можем использовать их готовый сертификат, ощутимо снизив для себя объем работ по сертификации, как для оператора системы персональных данных по сравнению с тем, который нужен для частного ЦОДа. Именно поэтому применение сертифицированных облаков как юридически рационально, так и финансово прагматично. Это сразу уменьшает колоссальный пул документов, который в ином случае нужно оформлять, а значит ещё больше уменьшает стоимость владения.  

Приказы ФСТЭК

Помимо ФЗ-152 существуют приказы ФСТЭК 21 и 17. Они могут предполагать шифрование, антивирусы, аудит действий пользователей и т.д. В нашем случае требования были минимальны, нам необходим был антивирус, обеспечение учета действий пользователей и контроль действий в системе. SAP и Яндекс Облако в полной мере обеспечивали эти требования. SAP блокирует действия пользователей, а на уровне Yandex Cloud ограничивает действия администраторов. 

Безопасность данных и уровень ответственности

Важно понять, что на техническом уровне утечки возможны вне зависимости от факта сертификации. Однако ответственность в полной мере наступит лишь тогда, когда не были приняты все меры для её предотвращения. В нашем случае речь идёт в первую очередь про сертификацию. Появление внезапной критической уязвимости в сертифицированной системе — это вопрос не к компании, которая использует или внедряет систему, но к самим критериям сертификации. Если компания, использующая систему, не могла её предвидеть, речь идёт об обстоятельствах непреодолимой силы. Соответственно, можно ожидать снижения размера штрафа. Другое дело, если по старой русской традиции жесткость закона компенсировалась “обязательностью” его исполнения, в этом случае гарантирована рябь в глазах от количества нулей в сумме штрафа.  

Процесс миграции  

Мы начали миграцию в Яндекс Облако 1 января 2020 года. Она включала 4 этапа, которые осуществлялись последовательно на протяжении 5 месяцев. В процессе была задействована команда из 7 человек.  

1. На первом этапе мы готовили проект:

   • оценили возможности и ограничения Yandex Cloud для размещения SAP HCM в облаке;

   • проанализировали возможности администрирования;

   • разработали модель размещения данных и подходы к миграции;

   • провели тестовую миграцию и адаптировали модели развертывания;

   • развернули SAP в Яндекс Облаке;

   • создали roadmap по миграции.

2. На втором этапе осуществили тестовый прогон миграции SAP HCM в Yandex Cloud и проработали “узкие места”. Интегрировали SAP c внешними системами, такими как SAPS/4HANA, размещенной в облаке MS Azure. Затем протестировали функции SAP HCM, провели тестовое архивирование и удаление при помощи SARA, а также разработали подробный план миграции.

3. На третьем этапе перенесли данные  SAP HCM в Yandex Cloud в полном объёме, всего за 3 дня. Пользователи ничего не заметили. Отказов системы в процессе миграции не возникало. В июле 2020 года наша компания была сертифицирована SAP HANA Operations и SAP Hosting Operations, что подтверждает полную функциональность систем SAP в Yandex Cloud.

Узкие места и их преодоление

SUSE Linux

Единственная проблема, которая у нас возникла в процессе миграции - подготовка специального образа SUSE Linux для Yandex Cloud. На тот момент в Yandex Cloud не было готового образа SUSE и для развертывания SAP мы подготовили свой. Мы проработали этот вопрос с коллегами из Yandex Cloud и протестировали их вариант. А затем выполнили небольшую миграцию на их образ. У SAP HCM есть требования к параметрам в операционной системе. Команда миграции транслировала эти  требования коллегам из Yandex Cloud и они довели используемый образ до необходимых параметров. В итоге, образ SUSE Linux Enterprise Server for SAP Applications добавили в маркетплейс Yandex Cloud.

 Ограничения виртуальной ОЗУ

Ещё одним узким местом является размер систем. Мы не коснулись этой проблемы, но её возникновение возможно для крупной компании. SAP бывает разного размера, он может быть небольшим, как у нас, всего 322 ядра и 256 ГБ виртуальной оперативной памяти. Для SAP-систем - это немного. Но у нас небольшое предприятие и соответственно небольшая система.  

У некоторых наших клиентов огромный SAP,  в связи с колоссальным количеством пользователей и соответствующим объемом данных. У интернет-ритейлеров, например, на SAP построены огромные системы аналитики, они покупают гигантские аппаратные комплексы, чтобы перемалывать чудовищные объёмы данных в приемлемое время. Даже минимально-жизнеспособные для компании сроки обработки информации требуют терабайты виртуальной памяти. 

В момент нашей миграции в Yandex Cloud максимальный объём виртуальной ОЗУ был 512 ГБ. Наш SAP, естественно, туда помещался, но когда мы начали обсуждение с клиентами, которым нужно было по 2,6 или даже 8ТБ виртуальной памяти, начали возникать проблемы. Создавать множество хостов для горизонтального масштабирования системы экономически не рационально, т.к. дорого.  

Несколько позже, для нас, как для партнёра, Yandex Cloud, увеличили лимит виртуальной памяти сначала до 1, а потом до 2 ТБ и теперь в их публичном облаке такие объёмы доступны. Но это предел их возможностей, в силу ограничений их оборудования используемого в облаке. Высока вероятность, хотя мы не знаем этого наверняка, что  в будущем Yandex Cloud ещё раз увеличит лимиты, учитывая массовую миграцию российских крупных компаний в их облака. Но пока у нас нет информации о таких планах вендора.  

VPN

Когда мы мигрировали в Яндекс Облако,  VPN там не было. Предстояла самостоятельная разработка. Наша команда создала VPN uplines на Linux. Теперь ситуация немного изменилась и у Yandex Cloud появились варианты, которые можно использовать. Например, есть инструкция, как создать свой uplines на базе Linux.

Когда появится полноценный VPN, глубоко интегрированный в инфраструктуру облака, можно будет проще обеспечить отказоустойчивость (поднять 2 ноды).  

Сейчас есть возможность арендовать линию с гарантированной пропускной способностью, благодаря которой происходит биллинг между серверами. Стабильность канала гарантируется участниками процесса на аппаратном уровне. Когда используется внутренний uplines c резервированием, возникают проблемы, так как внутри Яндекс Облака есть только статическая маршрутизация. Если развернуть два uplines`a, то в случае отказа одного из них, нет возможности динамически перенаправить трафик.  

Аппаратная возможность таких решений существует, но на уровне пользователей оно пока недоступно. В планах коллег из Yandex Cloud есть создание сервиса для организации VPN-соединений. Но в силу узкой специфики это не является приоритетной задачей.  

Итог — достигнутые цели 

• Сократили ИТ-инфраструктурные операционные расходы на 70%.

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

• Реализовали концепцию гибридного облака с гибкими возможностями, которую можно предложить клиентам.

• Добились соблюдения требований ФЗ «О персональных данных»

• Обеспечили защиту от катастроф и сбоев.

• Обеспечили возможность дистанционной работы для сотрудников, работающих с SAP HCM.

• Изучили сервисы Yandex Cloud и наработали базу знаний, которая позволит точно прогнозировать сроки внедрений и миграции SAP в Yandex Cloud у клиентов.

• Совместно с командой Yandex Cloud сократили количество “узких мест”, помогли партнёрам определить перспективные направления развития сервисов.