Привет, Хабр! Сегодня я расскажу об одном реальном переезде с проприетарного ПО на opensource-аналоги. Миграция на СПО — тема, конечно, избитая до безобразия. Но этот кейс интересен тем, что задача решалась в комплексе: под замену пошла вся экосистема инфраструктурного и прикладного ПО заказчика. Проект завершили в конце прошлого года, и поэтому в тексте вы найдете много отсылок к экономическим соображениям. Но пока я собирался рассказать обо всем подробно, ситуация сильно поменялась и бизнес-показатели ушли на второй план. Однако сам опыт масштабной миграции стал еще более актуальным — по крайней мере, когда я заканчивал текст этого поста, Коммерсантъ сообщил о росте спроса на отечественное ПО (в основном, работающее на базе открытых технологий) на 600% только за неделю. И если вам тоже теперь нужно переезжать на СПО, надеюсь, опыт нашей команды окажется действительно полезным, а экономические выкладки, которые я делал для данной миграции, пусть остаются приятным бонусом.
Предыстория проекта, о котором я расскажу сегодня, была очень прагматичной. Кто-то из менеджмента сел и посчитал, сколько денег тратится на различные лицензионные отчисления…и пришел к выводу, что с этим что-то нужно делать. За аудитом ИТ-экосистемы они обратились в КРОК, и после этого была запланирована многошаговая миграция. В результате моя команда собрала фактически новую инфраструктуру на замену 13 корпоративным сервисам, и сегодня я расскажу о тех проблемах, которые нам приходилось решать на этом пути.
UPD. Вторая часть поста с разбором интересных технических моментов — здесь.
Готовимся к миграции
Перед тем как запускать процесс миграции, нужно оценить его бюджет. Во-первых, на сам переезд требуется круглая сумма. А, во-вторых, дальше вам придется самостоятельно развивать и поддерживать опенсорсные решения, а может быть передавать эту задачу на аутсорсинг специалистам из той или иной ИТ-компании. К тому же крайне желательно сделать все с минимальным дискомфортом для сотрудников (особенно высокопоставленных).
Если как следует закопаться в инфраструктуру, нередко в ней можно обнаружить какие-то артефакты (которые по-любому нужно обновлять и слава богу они еще не дали трещину), выявить устаревшие версии различного ПО, а также наиболее затратные с точки зрения поддержки и стоимости лицензий элементы инфраструктуры. Поэтому перед началом основного проекта был запущен аудит — чтобы точно определить объемы предстоящих работ.
Как и следовало ожидать, кроме уточнения общих сведений (используемые решения, объем данных, число серверов и т.д.), мои коллеги выявили и последствия долгого стихийного развития ИТ-инфраструктуры. Часть систем оказалась устаревшей: ее кто-то внедрял достаточно давно, стабильность вызывает вопросы и очевидно требуется модернизация. Часть решений была развернута на разных версиях ПО в нескольких филиалах. Это касалось как проприетарных решений, так и используемых Open Source решений (OpenVPN, Zabbix). Например, корпоративная сеть базировалась на устаревших версиях OpenVPN, работала нестабильно и не дотягивала по функционалу до текущих требований. Дополнительно, одним из желаний заказчика был перенос части нагрузок в облако КРОК, и новая корпоративная сеть должна была обеспечить достаточную серверную мощность. Это также потребовало перенастройки сети.
В результате под замену были определены сами рабочие места сотрудников, виртуализация, служба каталога и сетевые сервисы, электронная почта, терминальный доступ, серверы печати и хранения файлов, мониторинг и управление, site to site VPN, система видеоконференций, публикация ресурсов в интернет и корпоративный портал. Всего 12 компонентов, для которых нужно было подобрать и внедрить аналоги на СПО и 2 компонента на СПО для обновления и перенастройки.
Отдельная история - аудит рабочих мест для подготовки их к переводу на Linux. Для этого было решено использовать специально подготовленные скрипты.
Почему скрипты? Потому что наивно надеяться, что установленные средства мониторинга и логирования покажут реальную картину вещей (по факту они дают информацию только об установленном ПО). Наша задача была собрать больше данных, например:
использование программ, не требующих установки и веб приложений (ярлыки на рабочем столе, вкладки в браузере, последние запущенные исполняемые файлы);
локальные почтовые архивы (есть ли и какой объем);
какие каталоги и сетевые принтеры подключены;
тип BIOS и наличие защиты загрузки (Secure boot), которая помешает удаленно обновить СПО ОС;
объем данных профиля и свободная емкость на локальном диске;
сохраненные в ОС персональные сертификаты; учетные данные для автозаполнения (которые пользователь мог давно забыть);
наличие файлов, зашифрованные EFS, которые будут потеряны, если их не расшифровать до миграции.
Скрипты распространяли на рабочие места через групповые политики и выкладывали результаты на сетевую шару. В результате были получены подробные данные, необходимые для подготовки к миграции рабочих мест на СПО.
Часть собранных данных (подключенные ресурсы, вкладки в браузере) в дальнейшем использовали для настройки системы управления рабочими местами, часть (сохраненные учетные данные, почтовые архивы, сертификаты, зашифрованные файлы) - для снижения рисков миграции.
Проблемы и сложности
Конечно, такой проект не мог пройти без проблем. В частности, одним из камней преткновения на пути тотальной миграции в СПО стала служба каталога, которая изначально работала на базе Microsoft Active Directory. Из вариантов для ее замены были рассмотрены FreeIPA (Free Identity, Policy and Audit), как более стабильное. Но оно, увы, рассчитано исключительно на линуксовое окружение. В результате было решено использовать SambaDC, хотя и менее стабильное, но совместимое с Microsoft (ведь фактически SambaDC является продуктом реверс-инжиниринга AD под Linux), и сервисы каталога вполне переводятся на этот продукт…но не без возможных сложностей. Я тогда предупредил заказчика, что попробуем пройти красивым и легким путем…но в случае неудачи придется дольше повозиться с миграцией объектов службы каталога. Однако нам удалось подружить SambaDC и установленную версию AD для постепенной миграции.
Чтобы пользователи не потеряли доступ к своим системам команда сначала интегрировала SambaDC в службу каталогов заказчика, а потом вывела серверы с Microsoft Active Directory из эксплуатации. Такой подход позволял избежать наиболее трудоемкой задачи: миграции учетных записей и компьютеров между службами каталога.
Второй вопрос — это замена портала SharePoint. В случае с Linux для него есть сразу несколько альтернатив, но не каждая из них способна заменить весь функционал портала. Так было успешно реализовано файловое хранилище с поддержкой совместной работы пользователей в режиме онлайн на базе NextCloud и OnlyOffice. Однако уже к завершению проекта заказчик понял, что ему нужна и база знаний…нам оставалось только порекомендовать использовать подходящее решение, например, BlueSpice.
Кстати, Nexcloud встроил в свое решение Collabora Online Development Edition в виде модуля под брендом NextCloud Office. В будущем, видимо, будем использовать этот модуль.
Когда концепция была разработана, от нас требовалось поэтапно перевести на опенсорсные решения сервера в филиалах. И сложность заключалась в том, что в каждом городе фактически был установлен один сервер с несколькими ВМ, которые обеспечивали как маршрутизацию трафика, так и реализацию функций ИТ — сервис хранения файлов, сервис, печать, служба каталога и т.д. И тут тоже пришлось повозиться.
Вся инфраструктура на СПО
Итого моя команда перенесла целый ряд инфраструктурных элементов на опенсорсные решения, сохранив все процессы и сервисы, которыми пользуются сотрудники в 7 филиалах компании. Так, на серверах была установлена ОС Ubuntu. Сетевые сервисы переехали на BIND, NTP и isc-dhcp-server. В качестве службы терминального доступа внедрили X2GO. Видеоконференцсвязь после миграции начала работать через Jitsi meet, корпоративная электронная почта — на Kopano, а все развернутые облачные решения были опубликованы в Интернете с использованием Nginx, файловое хранилище переехало на Samba, служба печати — на CUPS. Управление рабочими станциями построили с использованием ПО Foreman и Puppet.
К новому ИТ-хозяйству были прописаны скрипты автоматизации, чтобы обеспечить автоматическое переключение коммуникации между основным каналом и резервным соединением провайдером. Также потребовалось автоматизировать назначение пользователям сетевых общих папок и принтеров по определенным критериям, чтобы сохранить те политики, которые применялись ранее на базе сервисов Microsoft.
После всего этого оставалось только провести миграцию рабочих мест пользователей, и для этого потребовалось разработать шаблон рабочего места и автоматизировать установку. В нашем случае это был Linux Mint 20 Cinnamon вместе с программным пакетом LibreOffice и другими приложениями. Шаблон (золотой образ) тиражируется с помощью доработанной Clonezilla, а после донастраивается и вводится в домен с помощью puppet. Сами же работы по постепенному переводу рабочих мест, в целях экономии (не забываем, что проект был затеян именно с этой целью) взял на себя заказчик и продолжает перевод рабочих мест постепенно, пока еще не истекли сроки лицензий на пользовательское ПО. Тем более, что нюансы миграции выявлены аудитом и учтены в заранее переданных инструкциях и в инструментах тиражирования.
Как лучше мигрировать на СПО
Выполненный проект позволил сделать несколько выводов, которые помогают сделать процесс миграции на СПО более комфортным.
Во-первых, стоит учитывать, что перенос некоторых сервисов вообще незаметен и прозрачен для пользователей — это касается сетевых служб, инфраструктуры и так далее. Их можно переносить в любом порядке и в любом режиме.
Во-вторых, существуют зависимые друг от друга службы. Например, сначала нужно перенести на СПО электронную почту, а уже потом мигрировать службу каталогов. Иначе все сломается. В зависимости от того, что именно запущено в вашей инфраструктуре, таких связок может быть несколько.
В-третьих, есть моменты, которые заметны сотрудникам. На нашем проекте это была электронная почта, портал SharePoint и миграция самих рабочих мест. Если удастся совместить хотя бы два из этих трех процессов, то уровень стресса для конечных пользователей будет ниже. Впрочем, если в компании много рабочих мест — а это характерно для целого ряда отраслей: государственных органов, представителей розничной торговли (ритейла), банков, сбытовых компаний и так далее — можно оставлять миграцию терминалов на новую платформу по отработанной шаблонной схеме на последний этап. Это действительно выходит целесообразно с экономической точки зрения.
Так сколько получилось сэкономить?
Действительно, каков экономический эффект от ведения подобных проектов. В нашем конкретном случае затраты на лицензии Microsoft удалось сократить на 90%. То есть добиться экономии в 10 раз! Но тут нельзя забывать и о том, что СПО нужно поддерживать и обслуживать. Если у компании есть для этого свои собственные ИТ-кадры, то вопрос решается сам собой. Если же нет, то поддержка подобного СПО-шного семейства продуктов, как правило, обходится примерно в 20-30% стоимости изначальных лицензий.
Однако внедрение СПО, его адаптация и переход на новые сервисы требует времени. Поэтому миграцию целесообразно затевать, например, за полгода до времени оплаты очередных лицензий. Учитывая, что затраты на миграцию сопоставимы с очередным лицензионным платежом, то в первый год подобный проект просто выходит “в ноль”, а уже со следующего года начинает давать экономию.
Нюансы, которые стоит учесть
Конечно, после миграции требования к штату ИТ-шников заказчика выросли. На общей встрече мы даже обговорили необходимые курсы повышения квалификации, которые пришлось дополнительно пройти ИТ-специалистам. Для конечных пользователей были подготовлены руководства по эксплуатации персональных рабочих мест на Linux Mint, а для администраторов — серверных решений.
При этом нужно понимать, что СПО, каким бы оно ни было, менее удобно для администраторов, особенно в крупных компаниях. Различные комьюнити и разработчики СПО отдают приоритет функциям, а не удобству сопровождения. Многие вещи приходится прорабатывать “на ходу”, а порой — мириться с командной строкой вместо красивых галочек.
В подобном проекте можно потерять часть связности сервисов. Например, карточка контактов в Outlook интегрируется во все сервисы Microsoft. Вы можете перейти в чат, позвонить, открыть документ для совместной работы и так далее. В опенсорсных проектах таких связок меньше, и при необходимости их нужно дорабатывать. Но при этом возможностей создания связок больше. К тому же сделать это можно силами своей команды разработчиков или заказать у кого-нибудь.
Заключение
Подводя небольшой итог, могу сказать, что опенсорсные решения подходят не всем. Если компания выбирает СПО, переложить ответственность на вендора уже не получится. Опенсорс требует своей экспертизы и подобный проект не подойдет для компании с недостаточной ИТ-компетенцией. Но те организации, которые прекрасно умеют оптимизировать затраты и могут наращивать внутреннюю экспертизу, все чаще успешно переезжают на СПО. Особенно это заметно в сфере банковской отрасли и розничной торговли. Учитывая большое количество рабочих мест в этих отраслях развитие собственной экспертизы оказывается выгоднее, чем оплата проприетарных лицензий.
Кстати, для тех, кто уже планирует подобный проект или находится в процессе замены проприетарных решений на СПО, в следующем посте я рассказываю о технических аспектах самых проблемных зон проекта — миграции службы каталогов и замене сетевой инфраструктуры вместе с системой виртуализации. А если вы уже внедряли опенсорсные решения в качестве замены инфраструктурным сервисам, поделитесь своим опытом в комментариях, расскажите, какие именно продукты выбирали и почему.
