Привет, Хабр! Я продолжаю рассказ о нашей практике перевода крупной организации на СПО. Если в прошлый раз я рассматривал переезд всех 13 сервисов в общем, то сегодня сосредоточусь на трех аспектах, которые оказались наиболее интересными и поучительными с технической точки зрения. Поговорим о переносе системы виртуализации, о замене сетевых сервисов и о переходе со службы каталогов Active Directory на SambaDC. Всех, кто планирует или уже реализовал подобные трансформации, приглашаю присоединиться к обсуждению.

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

Система виртуализации

При массовом переходе на СПО, естественным образом, хочется избавиться от Hyper-V. В нашем случае замена происходила на Proxmox. Миграции виртуальных машин — история достаточно стандартная. Но мы обновляли ПО не только в центральном офисе. Миграция шла и в филиалах. А это было сложно, потому что на единственном сервере в каждом офисе крутились все сетевые сервисы…через которые предоставлялся доступ к корпоративной сети. 

В каждом случае сервер нужно было подменить удаленно, причем так, чтобы ничего не упало, и чтобы пользователи не потеряли доступ к ресурсам. Для этого мы привлекли локальных администраторов. Вернее администраторов головного офиса, потому, что в филиалах своих ИТ-специалистов не было. В каждом городе ответственный из головного офиса приезжал на площадку с небольшим сервером, на который временно переносили все ВМ. Наши инженеры бэкапили виртуалки, заменяли систему виртуализации на Proxmox Virtual Environment (PVE), мигрировали виртуалки с Hyper-V и запускали новые сервисы. Когда все было готово, трафик переключался обратно на основной сервер, и пользователи продолжали работать, но уже на базе opensource-инфраструктуры.

Впрочем, и тут не обошлось без сложностей. В один из филиалов сервер отправили с водителем, который наотрез отрицал причастность к ИТ (может и хорошо, что честно сознался). К счастью, на площадке нашелся адекватный менеджер, который выполнял переключение интерфейсов на серверах, получая задачи по телефону!

Теперь несколько слов о самой схеме миграции. Мы сначала полностью копировали основной сервер на вновь прибывший резервный, перебрасывали на него все коммуникации. После этого на сервер заказчика заливался Proxmox, а уже на него обратно загружались виртуальные машины. Линуксовые версии мы заодно обновляли и приводили к единообразию (а зоопарк наблюдался солидный — в каждом филиале своя ОС — CentOS, Debian, Ubuntu и так далее), ВМ с Windows просто поднимались обратно, чтобы сначала включить все сервисы “как есть”.

Поскольку в филиалах был четкий регламент приема пищи, с 12 до 13 все уходили на обед. Это был шанс протестировать новый сервер. Мы перебрасывали трафик на него…и если что-то не работало, то связь через OpenVPN просто терялась. Тут был некоторый элемент “подрубания сука, на котором сидишь”. К счастью удаленно подключиться можно было либо на белый IP сервера либо через ноутбук, на который Интернет раздавался с телефона.

В основном проблемы были связаны с различными настройками подключений — в одном филиале это был даже ADSL-модем. Так что кое-где пришлось покопаться с настройками сети. С заливкой ВМ практически никаких сложностей не возникло. Все, снятое с Hyper-V, легко легло на Proxmox. А параллельно с этим мы обновили версии OpenVPN и поправили некоторые ошибки в конфигурации сети, чем добились более стабильной связи между филиалами.

Служба каталогов

Изначально заказчик использовал службу каталога Active Directory, и от нее было решено уходить. Как мы уже писали в прошлом посте (ссылка), в качестве альтернативы была выбрана SambaDC. Мы развернули сервер на в нашем облаке и интегрировали его в существующую службу каталога AD. Уже на этом этапе было обнаружено и исправлено несколько ошибок в конфигурации Active Directory и баг в SambaDC. Мы немного поправили код руками и Samba завелась, а сам баг описали и отправили на bugzilla.samba.org. Планировали завершить миграцию позже, когда будет перенесена вся инфраструктура, а главное — почта переедет с MS Exchange (который просто не станет работать с неродным каталогом). 

Но когда пришло время полного перехода на линуксовую службу каталога, новые серверы SambaDC подключить к Active Directory уже не получилось. Мопед не заводился. 

Начали разбираться. Для этого скопировали контроллеры домена заказчика в свою тестовую среду. После ряда тестов, выяснилось, что для решения проблем нужно очистить AD от всех контроллеров домена, кроме самого нового (у Заказчика был зоопарк от Windows Server 2008 до Windows server 2012 R2). А перед этим перенести на него все роли, включая эмулятор PDC. Причем эмулятор PDC пришлось переключать через “Захват роли”. По другому старый владелец ее отдавать не захотел.

Так мы и сделали в реальной среде, дождавшись выходных и подготовив резервные копии. После этого сразу развернули нужное число серверов SambaDC и дали им IP-адреса старых серверов, чтоб не перенастраивать клиенты DNS.

Но и это было еще не все. Неожиданно подкинул проблем сервер DHCP, который изначально работал на контроллере домена Active Directory. Замена для него была очевидной — это isc-dhcp-server. А большое количество зарезервированных IP-адресов  были выгружены, распарсены и аккуратно перенесены в конфиг нового DHCP-сервера.

Казалось бы, все аккуратно сделано, но  при работе заказчик стал жаловаться, что зарезервированные адреса периодически кем-то занимаются и возникают проблемы в работе сети.

Мы просмотрели логи и убедились сами в наличии такой проблемы. Дело в том, что isc-dhcp-server работает с резервированием адресов не совсем как DHCP из пакета Windows. Для него резервация в файле — это рекомендация к действию, а не жесткое условие. Поэтому, если адресов в пуле еще много, вы не заметите никакой разницы. Но если их уже не хватает, а адрес из числа зарезервированных свободен, то isc-dhcp-server выдаст его клиенту, не задумываясь. Вот такой вот «не баг, а фича», который тоже нужно учитывать. Впрочем, решается проблема не сложно — достаточно исключить адреса резерваций из пула выдаваемых адресов, что и было сделано. 

Облако добавляет эффекта

Еще один интересный момент, который оказался крайне полезным — это использование в миграции на СПО облачных ресурсов. Пока мы оптимизировали OpenVPN, то сами активно эксплуатировали собственное облако КРОК. Оказалось, что и заказчику удобнее задублировать некоторые сервисы на старом ПО и на новом СПО, запуская дополнительные ВМ в облаке вместо покупки нового железа. Ведь после миграции новые серверы окажутся невостребованными. 

Первым делом в облако переехала инсталляция 1С (уже на Linux), а потом туда же мигрировали еще часть сервисов. Что интересно, по завершении проекта их оказалось выгоднее оставить в облаке, потому что для дальнейшего развития некоторых компонентов уже не хватало ресурса имеющихся серверов. В то же время возможность прямого доступа из филиалов к системам в облаке КРОКа разгрузило каналы OpenVPN между центральным офисом и региональными. Как результат — повышение пропускной способности корпоративной сети без дополнительных затрат.

Заключение

В завершение хочется сказать, что наш путь наверняка в чем-то был неидеальным. Ведь в мире СПО постоянно что-то меняется. Одни проекты перестают быть бесплатными (как почтовая система Zimbra), другие появляются с нуля и оказываются очень удачными. В этом деле главное запастись терпением и относиться к тем сборками, которые доступны на рынке, как к конструкторам с большими возможностями. В любом случае курс на СПО теперь становится практически предопределенным, а значит проверенных решений будет появляться все больше и больше.

Кстати, если у вас есть практика удачного решения аналогичных вопросов переезда на СПО, поделитесь ими в комментариях, пожалуйста. Ведь миграция на опенсорсные системы ждет сегодня многие компании, и уже наработанный опыт может оказаться спасительным для сотен системных администраторов, которым не придется ночами сидеть на работе и склеивать нестыковки между компонентами СПО.