Многие глобальные компании ушли с российского рынка, но российские подразделения остались. «Дочкам» пришлось искать замену ресурсам, которыми раньше обеспечивало головное предприятие. За последние два года в Linx обратилось несколько таких заказчиков, перед которыми встала задача самостоятельно развернуть сервисы в сжатые сроки. Делимся интересным кейсом о миграции из западного частного облака в наше публичное. Клиент ― российское представительство международной промышленной компании, имеет в РФ несколько производственных площадок. Раньше заказчик пользовался централизованной ИТ-инфраструктурой, которая располагалась в цифровом частном облаке в ЦОДе на территории Европы. После геополитических событий 2022 года головная компания покинула российский рынок. Местное представительство лишилось доступа к серверам глобального центра в частном облаке: требовалось заново развернуть ИТ-сервисы, без которых производство бы остановилось. Заказчик стал искать подрядчиков, и ему рекомендовали нас.  Прежде всего нужно было обеспечить офисных сотрудников привычными инструментами работы, так как все лицензии ПО ранее были оформлены на головную компанию. Мы предоставили заказчику офисное ПО по модели SaaS и выполнили интеграцию с Active Directory.   В процессе дальнейшего диалога поступил запрос на разработку комплексного IaaS-решения.  Проанализировав текущие потребности заказчика в ИТ-ресурсах, мы пришли к выводу, что оптимальным решением для его задач с точки зрения как скорости развертывания и масштабирования, так и гибкости управления затратами является публичное облако.  В публичном облаке, в отличие от частного, можно гибко и оперативно подстраиваться под меняющиеся бизнес-требования, выделяя нужные объемы ресурсов. С частным облаком такую гибкость обеспечить нельзя – его нужно сразу строить с серьезным запасом по мощности.  Безопасность обеспечивалась стандартными средствами нашего облака. По согласованию с заказчиком в качестве дополнительного элемента мы использовали виртуальный межсетевой экран следующего поколения UserGate (одно из самых зрелых решений на российском рынке, с нашей точки зрения).  Работы нужно было выполнить под ключ. У клиента не хватало ресурсов, а у специалистов на его стороне ― опыта реализации подобных масштабных нестандартных проектов. Мы могли делегировать отдельные задачи, но вся ответственность была на нас. Основные компоненты облака мы развернули на базе VMware. Изначально обсуждали внедрение SAP, однако затем клиент решил переходить на платформу 1C.  Ориентироваться на архитектуру частного облака головного предприятия мы не могли: она уже была неактуальна. Разрабатывали все с нуля, опираясь на потребности заказчика и возможности их реализации. Первоначальное решение в процессе трансформировалось: менялась и архитектура, и список используемых сервисов.  В итоге пришли к такой схеме: В первом сегменте vDC01 (main) размещены основные сервисы, которыми пользуется клиент и которые не относятся к базам данных: AD ― Active Directory, FS ― файловый сервер,  WSUS ― сервер обновлений Windows,  Terminal ― сервер терминального доступа.  Затем мы развернули два дополнительных vDC:  vDC02 под 1С. Эта система чувствительна к тактовой частоте ядра, так что для нее выделили отдельный vDC, в который добавили ресурсы из кластера, построенного на ядрах 3,4 ГГц. vDC03 под SAP. Сначала решение выступало в качестве продуктивной системы, поэтому в модуле полностью отключили переподписку и включили стопроцентное резервирование ресурсов. Сейчас SAP работает только для доступа к архивной информации, а для управленческого учета уже не используется. Соответственно, объем потребляемых ресурсов кардинально снизился. Такой подход, с разнесением стандартных и нагруженных систем по различным сегментам, позволил оптимизировать издержки клиента. Клиент не переплачивает за размещение стандартных систем в кластере с более дорогими производительными ресурсами. В качестве маршрутизатора установлено решение UserGate NGFW. Обычно в облаке эту функцию выполняет NSX Edge, но он не обладает нужным заказчику функционалом.  Клиент хотел: Настроить reverse proxy для сотрудников, работающих через UserGate. Ограничить доступ для удаленных пользователей, чтобы они могли подключаться к облаку только с корпоративных устройств. В рамках проекта был реализован BGP-туннель между офисом клиента и облаком Linx, в котором клиент разместил свою серверную инфраструктуру. Это решение позволило клиенту реализовать подключение пользователей к интернету через NGFW, тем самым обеспечив безопасную работу пользователей в интернете и контроль интернет-трафика. Авторизация пользователей на NGFW осуществляется через AD DS средствами LDAP-коннектора. Для опубликованных сервисов была реализована защита от сетевых атак средствами модуля СОВ (IPS) NGFW. Для снижения нагрузки на вычислительные ресурсы NGFW были настроены правила, применимые только к опубликованным сервисам, и для каждого уровня критичности определено свое действие по обработке события. С основной площадки заказчика можно подключаться к облаку как по VPN, так и по L2-каналу. Для удаленных пользователей путь один: через VPN-соединение.  Для резервного хранения данных используется наш сервис BaaS, который мы настроили согласно политике резервного копирования, исходя из бизнес-требований заказчика. При разработке решения не возникло особых сложностей. Но они поджидали нас при реализации и были связаны скорее с бизнесовой частью.  Чтобы бизнес-процессы заказчика не страдали из-за ухода головной компании из России, инфраструктуру нужно было развернуть как можно быстрее. Мы уложились в два месяца, с выделения ресурсов до завершения пилотного проекта: В начале первого месяца клиент приступил к активному тестированию. В конце месяца мы развернули сервисы в демо-режиме и далее активно настраивали инфраструктуру. К середине второго месяца мы уже фактически закончили реализацию проекта, а мелкие доработки производились уже в процессе эксплуатации. Понимая сложность положения заказчика, мы пошли ему навстречу: Разбили работы на несколько этапов, чтобы процесс согласования договора на весь объем работ не помешал нам стартовать. Таким образом, удалось начать выполнение работ в рамках пилотного проекта, пока юристы согласовывали детали. Помогали подрядчикам, которые разворачивали 1С и SAP. Синхронизировали с ними      работы и делали все необходимое, чтобы системы эффективно функционировали: создавали виртуальные машины, настраивали в них сеть и сетевую связность в целом, разворачивали операционные системы. Специалисты на стороне заказчика до миграции не сталкивались с такими задачами. Периодически у них возникали вопросы, связанные с настройкой сервисов, которые не входили в зону ответственности Linx. Мы постоянно поддерживали контакт, консультировали и помогали решать проблемы. Мы построили для заказчика ИТ-инфраструктуру, которая поддерживает 300 внутренних пользователей ERP-системы и около 10 внешних ― для них развернут терминальный сервер.  Главное, что выиграл заказчик от реализации решения: гибкость в управлении ресурсами. Благодаря размещению в публичном облаке возможно как динамическое расширение, так и сокращение объемов потребляемых ресурсов по запросу. Это актуально, например, в свете планов заказчика перенести впоследствии данные из SAP в холодный архив, для размещения которого уже не потребуется высокопроизводительный облачный кластер. Основная задача при реализации подобных проектов для внезапно «осиротевших» компаний ― не допустить простоев в их бизнесе и оперативно разобраться с «узкими местами» в процессах, а это чаще всего вопросы, связанные с техподдержкой и подбором альтернативных решений. По нашему опыту, такие задачи успешно решаются только при условии плотного взаимодействия с командой заказчика и достаточно глубокого погружения в его работу. Именно благодаря такому подходу в этом проекте мы смогли быстро и практически незаметно для конечных пользователей развернуть решение, закрывающее текущие потребности компании и легко масштабируемое в перспективе. Виталий Гололобов  Менеджер по продуктам и решениям Linx Cloud   Провайдер облачных решений и услуг ЦОД для бизнеса