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