Привет, Хабр! Продолжаю рассказ о нашей практике перевода крупной организации на открытое ПО.
Если последний раз Поскольку я рассматривал перенос всех 13 сервисов в целом, то сегодня остановлюсь на трех аспектах, которые оказались наиболее интересными и поучительными с технической точки зрения.
Давайте поговорим о перемещении системы виртуализации, замене сетевых служб и переходе со службы каталогов Active Directory на SambaDC. Приглашаю всех, кто планирует или уже реализовал подобные преобразования, присоединиться к обсуждению.
Читайте о том, почему в 7 филиалах крупной компании был запущен масштабный проект миграции 13 систем в последнем посте .
Теперь расскажу подробнее о нашем опыте работы с разными компонентами.
Скажу сразу, что возможно сегодня уже есть лучшие решения тех же вопросов, но рассказ будет о том, какие трудности (и их решения) были найдены на момент реализации проекта.
Система виртуализации
При массовом переходе на программное обеспечение с открытым исходным кодом, естественно, хочется избавиться от Hyper-V. В нашем случае замена произошла на Proxmox. Миграция виртуальных машин — довольно стандартная история.Но мы обновили программное обеспечение не только в центральном офисе.
Миграция произошла и в филиалах.
А это было сложно, потому что все сетевые службы работали на одном сервере в каждом офисе.
через который осуществлялся доступ к корпоративной сети.
В каждом случае сервер приходилось заменять удаленно, причем чтобы ничего не падало и пользователи не теряли доступ к ресурсам.
Для этого мы привлекли местных администраторов.
Вернее, администраторы головного офиса, потому что в филиалах не было своих ИТ-специалистов.
В каждом городе на площадку приходил ответственный из головного офиса с небольшим сервером, на который временно переносились все ВМ.
Наши инженеры выполнили резервное копирование виртуальных машин, заменили систему виртуализации на Proxmox Virtual Environment (PVE), выполнили миграцию виртуальных машин из Hyper-V и запустили новые сервисы.
Когда все было готово, трафик переключился обратно на основной сервер, а пользователи продолжили работу, но уже на базе opensource-инфраструктуры.
Однако не обошлось без трудностей.
Сервер отправили в один из филиалов с водителем, который наотрез отрицал свою причастность к ИТ (может, и хорошо, что он честно признался).
К счастью, на сайте был адекватный менеджер, который переключал интерфейсы на серверах, получая задания по телефону! Теперь несколько слов о самой схеме миграции.
Сначала мы полностью скопировали основной сервер на вновь прибывший резервный сервер и перенесли на него все коммуникации.
После этого Proxmox заливался на сервер заказчика, а виртуальные машины загружались обратно на него.
При этом мы обновили версии Linux и довели их до единообразия (а там был большой зоопарк - в каждой ветке была своя ОС - CentOS, Debian, Ubuntu и так далее), ВМ с Windows просто обновились до первой включить все сервисы «как есть».
Поскольку в филиалах были четкие правила приема пищи, с 12 до 13 все шли на обед. Это был шанс протестировать новый сервер.
Мы перебрасывали на него трафик.
и если что-то не работало, то соединение через OpenVPN просто терялось.
Был какой-то элемент «отрезать ветку, на которой сидишь».
К счастью, можно было подключиться удаленно либо к белому IP-серверу, либо через ноутбук, на который раздавался интернет с телефона.
Проблемы были в основном связаны с различными настройками подключения - в одной ветке был даже ADSL-модем.
Так что кое-где пришлось повозиться с настройками сети.
Трудностей с заливкой ВМ практически не возникло.
Все взятое из Hyper-V легко помещается на Proxmox. А заодно мы обновили версии OpenVPN и исправили некоторые ошибки в конфигурации сети, тем самым добившись более стабильного соединения между филиалами.
Служба каталогов
Изначально заказчик использовал службу каталогов Active Directory, и было принято решение от нее отказаться.Как мы уже писали в предыдущем посте (ссылка), в качестве альтернативы был выбран SambaDC. Мы развернули сервер в нашем облаке и интегрировали его в существующую службу каталогов AD. Уже на этом этапе было обнаружено и исправлено несколько ошибок в конфигурации Active Directory и ошибка в SambaDC. Мы немного подправили код вручную и Самба запустилась, а сам баг был описан и отправлен в bugzilla.samba.org .
Завершить миграцию мы планировали позже, когда вся инфраструктура будет перенесена, а главное, почта переедет с MS Exchange (который с неродным каталогом просто не будет работать).
Но когда пришло время полного перехода на службу каталогов Linux, подключить новые серверы 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), другие появляются с нуля и оказываются очень успешными.
В этом вопросе главное набраться терпения и относиться к тем сборкам, которые имеются на рынке, как к конструкторам с большими возможностями.
В любом случае, курс на открытое ПО сейчас становится практически предопределённым, а значит, будет появляться всё больше и больше проверенных решений.
Кстати, если у вас есть опыт успешного решения подобных вопросов перехода на открытое ПО, поделитесь им в комментариях.
Ведь переход на системы с открытым исходным кодом сегодня ждет многие компании, а уже полученный опыт может спасти жизнь сотням системных администраторов, которым не придется сидеть на работе по ночам и устранять несоответствия между компонентами программного обеспечения с открытым исходным кодом.
Теги: #миграция #Системное администрирование #открытый код #openvpn #КРОК #ubuntu #Samba #proxmox #Открытое программное обеспечение
-
Простое Резервное Копирование Игр Wii
19 Oct, 24 -
Mediatek Mt6595: Впечатления От... Чипсета
19 Oct, 24