Перенос физического сервера в дата-центр часто кажется простой задачей: выключить оборудование, перевезти его, установить в стойку и снова включить.
На практике большая часть рисков связана не с транспортировкой сервера, а с тем, что происходит до и после нее.
На сервере могут работать 1С, базы данных, CRM, файловые сервисы, сайты или внутренние приложения. К нему привязаны IP-адреса, DNS, VPN, сетевые маршруты, лицензии и другие системы. Даже если сам сервер после переезда исправно включится, это ещё не означает, что все сервисы сразу станут доступны пользователям.
Поэтому перенос сервера из офиса в дата-центр стоит рассматривать как небольшую миграцию IT-инфраструктуры, а не просто перевозку оборудования.
Разберем, что нужно учесть, чтобы сократить время простоя и не столкнуться с неожиданными проблемами уже после переезда.
Сервер может годами работать в офисе без серьезных проблем. Но по мере роста бизнеса требования к инфраструктуре меняются.
Поводом задуматься о переносе обычно становятся не сами серверы, а условия вокруг них:
Если сервер уже куплен и устраивает по производительности, менять его на другой необязательно. Можно изменить только место размещения оборудования.
Но перед этим важно понять, что именно зависит от сервера.
Одна из самых опасных ошибок - планировать переезд исключительно вокруг физического оборудования.
Сам сервер может быть лишь одним элементом целой цепочки.
Например:
пользователь → VPN → корпоративная сеть → приложение → база данных → файловое хранилище.
Если перенести только сервер приложения, но не учесть его связь с базой данных или сетевым хранилищем, сервис может перестать работать.
Поэтому первый этап миграции - составить карту зависимостей.
Стоит выяснить:
Чем больше связей обнаружено до переезда, тем меньше сюрпризов будет после запуска оборудования на новой площадке.
Физический сервер невозможно одновременно оставить в офисе и установить в стойку дата-центра.
Поэтому для классического переезда единственного сервера практически всегда существует хотя бы небольшое окно недоступности.
Вопрос не в том, будет ли простой вообще, а в том, сколько времени он может продолжаться и как его сократить.
Для внутреннего файлового сервера перенос можно провести ночью или в выходной день. Для интернет-сервиса, производственной системы или корпоративной базы данных даже несколько часов могут быть критичны.
До начала работ желательно определить:
допустимое время недоступности сервиса;
максимально допустимую потерю данных.
От этих двух параметров зависит вся дальнейшая схема миграции.
Если несколько часов простоя допустимы, можно использовать простой сценарий: корректно остановить сервисы, выключить оборудование, перевезти его и запустить на новой площадке.
Если простой должен быть минимальным, может потребоваться временная копия сервиса, репликация данных или дополнительный сервер, который будет обслуживать пользователей на время физического переезда.
Иногда да. Но не потому, что сам физический сервер каким-то образом перевозят работающим.
Нулевой или почти нулевой простой достигается за счет архитектуры вокруг него.
Например, перед переносом можно создать временную виртуальную или физическую копию сервиса на другой площадке, синхронизировать данные и переключить пользователей на нее. После установки основного сервера выполнить обратное переключение.
Другой вариант - использовать уже существующий кластер или репликацию.
Но если у компании один физический сервер без резервного узла, обещать полностью бесшовный переезд неправильно.
В такой ситуации разумная цель - заранее согласованное и контролируемое окно работ, а не формальный «нулевой простой».
Даже если сервер исправен и до дата-центра ехать десять минут, перед физическим перемещением оборудования должна существовать актуальная резервная копия.
Причем важно не просто проверить, что задача резервного копирования завершилась без ошибки.
Нужно понимать:
Хранить единственную резервную копию на диске внутри переносимого сервера бессмысленно.
Хороший вопрос перед началом миграции:
Что мы будем делать, если после перевозки сервер вообще не включится?
Если на него есть понятный ответ и рабочая резервная копия — один из главных рисков уже контролируется.
Перевозка — дополнительная механическая нагрузка на сервер.
Перед переносом полезно проверить состояние дисков, блоков питания, вентиляторов и других компонентов.
Особое внимание требуется старому оборудованию, которое несколько лет практически не выключалось.
Иногда сервер стабильно работает годами, но проблема проявляется именно после полного отключения питания и повторного холодного запуска.
Это не означает, что оборудование нельзя переносить. Просто подобный риск стоит учитывать заранее и не назначать переезд критичной системы без резервного сценария.
Один из важнейших вопросов миграции это сеть.
В офисе сервер может использовать локальный адрес, например 192.168.x.x, а доступ из интернета обеспечивается через маршрутизатор и NAT.
После переноса в дата-центр схема подключения обычно меняется.
У сервера может появиться новый публичный IP-адрес или новая адресация внутри инфраструктуры площадки.
Поэтому заранее необходимо проверить, где старый адрес используется напрямую.
Он может быть указан:
Часть таких зависимостей легко обнаружить. Другие всплывают только после смены IP.
Поэтому сетевую часть желательно документировать ещё до физического переезда.
Если пользователи обращаются к сервису по доменному имени, при смене IP-адреса потребуется обновить DNS-запись.
Но изменения DNS распространяются не мгновенно.
На время распространения влияет TTL — срок, в течение которого DNS-ответ может храниться в кеше.
Если заранее известно, что IP изменится, TTL соответствующих записей обычно уменьшают до миграции. Тогда после переключения старые данные будут быстрее вытесняться из кешей.
После завершения переезда TTL можно вернуть к обычному значению.
Это небольшая деталь, но именно такие детали часто определяют, будет ли сервис доступен через несколько минут после запуска или часть пользователей продолжит обращаться к старому адресу.
С IP-адресом связана только часть возможных проблем.
Перед миграцией стоит проверить несколько менее очевидных зависимостей.
Некоторые приложения или лицензии могут быть привязаны к IP-адресу, MAC-адресу, аппаратной конфигурации или другой характеристике среды.
Физический перенос обычно не меняет аппаратную конфигурацию сервера, но изменение сети уже может иметь значение.
Если офис и сервер раньше находились в одной локальной сети, после переноса они окажутся на разных площадках.
Для части внутренних систем может потребоваться VPN или другой защищённый канал между офисом и дата-центром.
Партнеры, API и внешние сервисы могут разрешать подключения только с определённых IP-адресов.
После смены адреса интеграция перестанет работать, пока новый IP не будет добавлен в список разрешённых.
Система мониторинга должна знать новый адрес сервера и продолжать получать необходимые данные после миграции.
Если backup ранее сохранялся на устройство в офисе, после переезда необходимо проверить, сможет ли сервер по-прежнему обращаться к нему с новой площадки.
И наоборот: иногда перенос сервера — хороший момент, чтобы вынести резервные копии из той же физической локации.
После установки сервера в дата-центре привычного варианта «подойти к нему с клавиатурой и монитором» уже не будет.
Поэтому особенно полезно наличие отдельного интерфейса удалённого управления:
Такой доступ позволяет работать с сервером независимо от состояния основной операционной системы: перезагружать его, просматривать аппаратные события, использовать удаленную консоль и выполнять диагностику.
Перед переездом стоит убедиться, что интерфейс работает и известны актуальные данные доступа.
Если сервер не поддерживает удалённое управление, необходимо заранее понимать, как будет выполняться физическое обслуживание оборудования на площадке.
Не стоит сначала привозить оборудование, а уже потом выяснять, куда его установить и как подключить.
До перевозки необходимо согласовать хотя бы основные параметры:
|
Что проверить |
Зачем |
|
Высота сервера в U |
Чтобы заранее выделить место в стойке |
|
Глубина корпуса |
Не все серверы одинаково подходят под любую стойку |
|
Салазки и крепления |
Сервер должен быть корректно установлен |
|
Реальное энергопотребление |
Для расчета требуемой мощности |
|
Количество блоков питания |
Для схемы подключения |
|
Сетевые интерфейсы |
Для подготовки портов и кабелей |
|
Требуемая скорость подключения |
1/10 Гбит/с и другие варианты |
|
IP-адресация |
Чтобы сеть была готова до запуска |
|
Удалённое управление |
Для дальнейшей эксплуатации |
Если все это согласовано заранее, после доставки сервер можно сразу монтировать и переходить к запуску сервисов.
Последовательность остановки зависит от работающих приложений.
Просто выключить питание сервера не лучший вариант.
Сначала корректно завершают работу сервисов, особенно баз данных и систем, выполняющих активную запись. После этого останавливают операционную систему и только затем полностью обесточивают оборудование.
Перед выключением полезно зафиксировать текущее состояние:
Если после переезда что-то будет вести себя иначе, появится точка сравнения.
Стоечные серверы рассчитаны на эксплуатацию в стойке, а не на транспортировку без упаковки.
Особенно аккуратно необходимо обращаться с тяжелым оборудованием, системами хранения и серверами с большим количеством накопителей.
Во время перевозки важно защитить оборудование от ударов, вибрации, влаги и сильных перепадов температуры.
Салазки, кабели и другие снимаемые элементы лучше перевозить так, чтобы они не могли повредить корпус или компоненты.
Если речь идет о нескольких серверах, желательно заранее промаркировать оборудование и кабели. На площадке это значительно ускорит монтаж.
Успешно включившийся сервер еще не означает успешную миграцию.
После запуска стоит проверять инфраструктуру от нижнего уровня к верхнему.
Сначала:
питание → аппаратное состояние → RAID и диски → сеть.
Затем:
операционная система → базы данных → приложения → внешние интеграции.
И только после этого:
доступ реальных пользователей.
Так проще понять причину проблемы, если что-то не заработало.
Например, приложение может быть исправно, но не видеть базу данных. Или сервер доступен внутри дата-центра, но внешний firewall не пропускает необходимые подключения.
Проверять лучше не просто открытие сайта или вход в систему, а основные бизнес-сценарии: создание документа, запись данных, работу интеграций, доступ филиалов и резервное копирование.
Даже хорошо подготовленная миграция может пойти не по плану.
Поэтому до начала работ необходимо определить момент, после которого команда принимает решение не продолжать поиск проблемы, а возвращаться к резервному сценарию.
Это и есть план отката.
Например:
Если в течение согласованного окна сервис не удается полноценно восстановить на новой площадке, пользователи временно переключаются на резервный экземпляр системы.
Конкретный сценарий зависит от архитектуры.
Главное решить этот вопрос до аварийной ситуации, а не во время нее.
Большинство проблем связано не с самой перевозкой, а с недостаточной подготовкой.
Чаще всего возникают такие ситуации:
По отдельности каждая проблема кажется небольшой.
Но если обнаруживать их уже после выключения основной системы, окно миграции быстро превращается в незапланированный простой.
Перед переносом физического сервера стоит убедиться, что:
Если эти вопросы решены заранее, физическая перевозка обычно становится самой простой частью всего процесса.
После миграции оборудование остается тем же самым.
Меняется инфраструктура вокруг него.
Компания по-прежнему контролирует собственный сервер, его конфигурацию, операционную систему и данные, но больше не обязана размещать оборудование непосредственно в офисе.
Это особенно актуально, если сервер уже отвечает требованиям бизнеса и менять оборудование нет необходимости.
Вместо строительства или расширения собственной серверной можно использовать colocation, размещение принадлежащего компании сервера в подготовленной инфраструктуре дата-центра.
Если вы планируете перенести собственный сервер из офиса или другой площадки, его можно разместить в дата-центре XDataPlus в Уфе.
Перед переездом поможем определить необходимое место в стойке, энергопотребление, схему питания, сетевое подключение и другие параметры размещения.
Это позволяет заранее подготовить площадку и сократить количество работ, которые придется выполнять уже после доставки оборудования.
Рассчитаем условия размещения вашего сервера и поможем подготовиться к переносу в дата-центр.
