Уже более 10 лет назад в Microsoft объявили о доступности платформы Azure для широкой аудитории пользователей. За это время преимуществами облачной инфраструктуры для решения текущих задач ИТ захотели воспользоваться многие компании. Некоторые из них обращались к нам за консультацией по разворачиванию систем в облаке. Но время шло и вот уже бизнес рассматривает возможность размещения в облаках таких ресурсоемких систем, как SAP HANA. Мы в свою очередь, уже реализовали несколько аналогичных проектов и готовы поделиться теми наблюдениями, которые могут обеспечить более успешное размещение системы SAP в облаке MS Azure. Некоторые наблюдения не будут открытием, но нам хотелось показать применимость некоторых подходов именно в условиях облачной платформы. Основными усвоенными уроками хотим поделиться с вами.
№1: Последовательная оптимизация ИТ архитектуры при использовании облака
В рамках миграции продуктивной системы мы столкнулись с проблемой высокого потребления ресурсов в рамках процессов тестирования и разработки, что в конечном итоге заставило задуматься о том зачем нам нужно столько ресурсов для Test и Dev среды и как оптимизировать потребление инфраструктурных ресурсов продуктивной системой.
Рекомендованный подход к построению системы SAP строится на базе оценки необходимых мощностей средствами калькулятора SAP Quick Sizer. До сих пор методологии SAP базируются на стандартных подходах, не учитывающих особенности облачных технологий. Мы получили требования от Заказчика, ввели исходные данные в эстиматоры SAP и получили предварительную конфигурацию ландшафта. В случае обычной инфраструктуры можно было на этом остановиться и перейти к покупке оборудования, но в нашем случае было возможно воспользоваться преимуществами облака. В облаке ресурсы можно нарастить в любой момент и поэтому мы отказались от излишнего запаса по ресурсам, заложенного в эстиматор и развернули машины меньшей производительности. Это позволило сократить затраты, а по мере возрастания нагрузки мы всегда можем увеличить производительность виртуальных машин SAP за считанные минуты.
Microsoft обеспечивает поддержку SAP только на ВМ серии М. Использование тестовых ресурсов аналогичных продуктивной среде по уровню поддержки на этапе первоначальной разработки нам показалось избыточным.
В тоже время машины E-серии обладают схожими характеристиками с M-серией, но их стоимость существенно меньше. В итоге мы заменили тестовые машины на серию E. Обратной стороной этой замены является переход ответственности за работу системы в тестовых средах с провайдера на интегратора. Это налагает на интегратора необходимость иметь экспертные компетенции в области SAP.
№2: Как сэкономить на потреблении ресурсов
MS Azure позволяет существенно экономить при резервировании ресурсов с одновременным предоплатой на один или 3 года.
Зачастую на начальном этапе заказчик не может точно оценить дату запуска продуктивной системы, так как ее разработка и тестирование зачастую связаны со многими переменными, находящимися на стороне бизнеса или подрядных разработчиков.
Например, на момент запуска одного из проектов мы планировали одновременное развертывание всех сред на основе текущих планов Заказчика. Как это часто бывает, разработка потребовала более длительных согласований с бизнесом, что привело к задержке продуктивного запуска на несколько месяцев.
В этом примере при резервации ресурсов с предоплатой Заказчик потерял бы существенный объем средств. Резервировать ресурсы, конечно, нужно, но эффективнее это делать на более поздних этапах проекта, когда основной объем продуктивной системы стабилизировался, а разработка станла предсказуемой в плане потребления ресурсов. Зачастую при резервации вычислительных ресурсов на 3 года можно получить около 70% экономии средств по сравнению с Pay-As-You-Go методом оплаты.
№3: Как выбрать регион Azure
Azure обладает широким списком регионов для размещения ресурсов. Один из основных критериев выбора региона — удаленность вашей инфраструктуры от конечных пользователей, что влияет на отклик системы и работу интеграций и конечных пользователей.
Вторым, не менее важным, критерием является список сервисов в том или ином регионе.
Некоторые сервисы доступны в зависимости от региона. Очень часто сервисы перед официальным выходом предоставляются в виде preview. Некоторые регионы быстрее внедряют новые технологии и дают опробовать тот или иной появившийся сервис. Не все регионы предоставляют возможность использования всего ассортимента серий виртуальных машин.
В нашей практике сравнение скорости доступа зачастую показывает преимущество региона “Западная Европа”. Особенно это заметно для компаний чьи сервера и клиенты расположены в европейской части России. В каждом конкретном случае, и особенно если ваши ЦОД и клиенты расположены на Дальнем Востоке, имеет смысл проверить задержки из своего ЦОД (либо из того географического региона, где расположены ваши клиенты) для выбора лучшего региона Azure.
Такие сервисы как Azure Latency Test позволяют заранее проверить задержки до каждого из регионов Azure из сети вашего ЦОД. Пример результатов измерения задержке при помощи упомянутого сервиса при тестировании из нашего московского офиса:
№4: Как применять к облачным инсталляциям методы, проверенные «на земле»
В каждой миграции мы задаемся вопросом о том, каким обазом использовать в облаке традиционные решения, проверенные классической инфраструктурой. В частности, при подготовке решения мы опираемся на рекомендации вендора для разработки технически верного решения. Проекты на SAP HANA не являются исключением и тоже проходят через призму рекомендаций и лучших практик.
На одном из проектов при реализации первого этапа решения, был развернут Jump сервер на базе Windows. Для оптимизации затрат начального этапа разработки на том же сервере был развернут и NFS сервер для нужд непродуктивных сред, что закрывало текущие потребности разработчиков и позволяло существенно сэкономить на ресурсах.
Время шло, среды и потребности в ресурсах росли, а NFS сервер справлялся со всеми поставленными задачами. Постепенно в рамках проекта мы приблизились к исчерпанию ресурсов начальной ВМ. Ресурсы ВМ в MS Azure можно увеличить за минуты, но параллельно повысились требования к отказоустойчивости сервера, что заставило рассмотреть более масштабную реконфигурацию.
Для реализации был использован Linux сервер, сервис DRBD и функционал Availability set, которые закрыли вопрос репликации данных между нодами кластера NFS и повысили доступность на случай выхода из строя одной из двух нод кластера.
К слову сказать: через пару месяцев после внедрения кластерного решения в Azure добавили сервис NetApp Files, который позволяет воспользоваться преимуществами массивов NetApp, но оплачиваемыми по модели Pay-As-You-Go.
№5: Как автоматизировать график работы ВМ
При использовании любой облачной инфраструктуры всегда имеет смысл проанализировать какие дополнительные механизмы могут быть использованы для максимальной экономии средств.
В нашем случае тестирование систем происходит в рабочее время. Если в обычной инфраструктуре простаивание серверов выливается преимущественно в увеличеные счета за электроэнергию, то в облаке не приносящие пользу сервера потребляют финансы за аренду мощностей. Мы оценили графики нагрузок на серверах тестирования и разработки и обратили внимание что подавляющая часть разработчиков и тестировщиков используют систему по рабочим дням с 8-00 до 20-00.
В тех случаях, когда график нагрузки на непродуктивные системы предсказуем и цикличен мы стараемся применять скрипты автоматизации включения-выключения ВМ. В Azure есть несколько инструментов: Auto-Shutdown, Automation Accounts и Cloud Shell. Нам подошли не все. Auto-shutdown исключили потому что он умеет только выключать ВМ. Cloud Shell тоже не задействовали так как для него нужно готовить дополнительные скрипты, разрабатывать графики и где-то всё это безопасно хранить с наличием резервирования, что сводило экономию до минимума.
В нашем случае используется более гибкий механизм. Automation Accounts предлагает уже готовое и рабочее решение в виде Runbooks, позволяющие по расписанию включать и выключать виртуальные машины.
Мы подготовили графики для соответствующих ресурсов, загрузили Runbooks и сформировали связи между графиками и ресурсами.
Как итог мы дополнительно сократили итоговую стоимость владения. Первоначально эти инструменты не были запланированы для реализации, но уже на стадии предварительной эксплуатации реализовали их.
Изменение графика производится за несколько минут. Вначале производится формирование нового графика, потом ассоциация сформированного графика с необходимым ресурсом. При необходимости и наличии большого числа изменений есть возможность использовать Cloud Shell для автоматизации данного процесса.
№6: Мониторинг потребления ресурсов
Если для обычных ЦОД мониторинг работоспособности и потребления ресурсов к сожалению обычно отходит на второй план, то в рамках Azure этого допускать нежелательно. Информация об истории потребления ресурсов напрямую влияет на возможности по оптимизации затрат. А в случае с заблаговременным резервированием ресурсов может служить сигналом к доработкам архитектуры.
№7: Подстраховка на случай форс-мажоров
Многие компании опасаются размещать свои ИТ системы на облачных ресурсах из-за боязни блокировок, которые ранее точечно проводились регуляторами. Как и любой другой риск этот тоже может быть учтен при проектировании системы. В проектах мы, как правило, реализуем еженедельную выгрузку бекапов системы из облака в ЦОД Заказчика. Это позволяет быть уверенными в том, что система может быть восстановлена при любом развитии событий. В дополнении к этому мы применяем стратегию мультиоблачной инсталляции, которая позволит в случае ограничения доступа не остаться без доступа к ресурсам. В данном сценарии альтернативные облачные провайдеры используются как DR сайты основного облака, что позволяет восстановить доступность системы в случае масштабных блокировок.
№7+ Обработка персональных данных
За время работы мы сформировали подход к тому, как хранить и обрабатывать персональные данные в системах, включающих зарубежные облачные ресурсы. Отметим что реализация такого подхода должна выполняться с учетом требований регуляторов. Тема эта довольна обширна, и мы постараемся осветить ее в следующих статьях если заметим соответствующий интерес в комментариях.
Итоги
В статье мы рассмотрели несколько практических уроков по размещению SAP в облаке MS Azure. Очевидно, тема крайне обширна и мы смогли затронуть лишь часть возможных оптимизаций при миграции в облако.
А с какими нюансами приходилось сталкиваться вам? Будем благодарны, если вы поделитесь своим опытом в комментариях.