Colocation начинается не в тот момент, когда инженер дата-центра задвигает сервер в стойку. Основная подготовка происходит раньше. Нужно понять, подходит ли корпус под стандартную стойку, сколько электроэнергии потребляет машина, какие сетевые интерфейсы будут использоваться, как администратор получит доступ после установки и что произойдёт при отказе диска или другого компонента.
Если привезти в ЦОД просто собранный сервер и рассчитывать разобраться со всем на месте, даже простая установка способна растянуться. Выясняется, что не хватает направляющих, второй блок питания невозможно подключить по ожидаемой схеме, IPMI не настроен, нужный сетевой модуль отсутствует, а операционная система вообще ждёт другой режим RAID.
Поэтому перед размещением собственного оборудования полезно пройти всю будущую эксплуатацию мысленно: как сервер установят, как он загрузится, каким способом выйдет в интернет, как вы подключитесь к нему удалённо и кто будет менять физические компоненты после первой аппаратной неисправности.
Что проверить в самом сервере до отправки в ЦОД
Начать стоит с корпуса. Большинство дата-центров работают со стандартным стоечным оборудованием шириной 19 дюймов. Высота измеряется в юнитах: 1U, 2U, 4U и так далее. Если используется обычный rackmount-сервер Dell, HPE, Lenovo, Supermicro или стандартное серверное шасси, проблем обычно не возникает.
С нестандартным корпусом лучше заранее согласовать установку. Tower-сервер теоретически тоже можно разместить в ЦОД, но условия отличаются. Он занимает больше полезного пространства, может потребовать полку и не всегда удобно вписывается в стандартную схему охлаждения.
Не менее важны направляющие. Сервер не должен просто лежать на соседнем оборудовании. Для тяжёлой машины используются соответствующие рельсы или полка. Если оригинальные rails потеряны, покупать их лучше до доставки оборудования, а не искать совместимый комплект после того, как сервер уже приехал на площадку.
Питание лучше проверить под реальной нагрузкой
Дата-центру понадобится информация об энергопотреблении. Здесь часто допускают простую ошибку: смотрят на мощность блока питания. Если на нём написано 800 Вт, сообщают ЦОД, что сервер потребляет 800 Вт.
На самом деле блок питания рассчитан на определённую максимальную мощность, а реальное потребление зависит от конфигурации и нагрузки. Сервер с двумя блоками по 800 Вт также не обязательно потребляет 1600 Вт.
Перед размещением полезно измерить фактическое энергопотребление во время нормальной работы и под высокой нагрузкой. Для стандартного заводского сервера можно ориентироваться на данные производителя и собственные измерения через BMC, iDRAC или iLO, если контроллер показывает потребление.
Если в машине два блока питания, заранее нужно решить, требуется ли независимое подключение обоих. Для коммерческого проекта обычно есть смысл использовать оба БП и подключать их к разным линиям питания, если такую возможность предоставляет площадка.
Стоит проверить и состояние самих блоков. Привозить в ЦОД старый сервер, где второй БП годами не использовался и никогда нормально не тестировался, не лучшая идея. Лучше обнаружить неисправность на столе до установки в стойку.
Следующий этап — охлаждение. В стоечном сервере воздушный поток обычно идёт спереди назад. Все вентиляторы должны работать, радиаторы должны быть очищены от пыли, а температурные датчики не должны показывать подозрительные значения.
Особенно внимательно стоит проверить самостоятельно собранную машину. Домашний сервер мог нормально работать в открытом помещении, а в плотной стойке требования к воздушному потоку меняются. Большая видеокарта, нестандартный кулер или хаотично уложенные кабели способны мешать охлаждению других компонентов.
Перед colocation я бы обязательно провела длительный стресс-тест. Нужно загрузить процессор, память и диски и посмотреть, остаются ли температуры в норме, не появляются ли ошибки ECC, не отключается ли сервер и не фиксируются ли аппаратные предупреждения.
Диски и RAID лучше настроить до установки
Накопители стоит проверить отдельно. Для HDD и SSD полезно посмотреть SMART и убедиться, что нет растущего количества ошибок. У серверных SSD и NVMe важно оценить оставшийся ресурс записи.
Если используется RAID, массив лучше полностью собрать и протестировать заранее. Не стоит приезжать в ЦОД с четырьмя дисками и идеей решить на месте, будет это RAID 1, RAID 10 или что-то ещё.
После создания массива полезно проверить не только чтение и запись, но и поведение при отказе. Если конструкция поддерживает hot-swap, администратор должен понимать, как определить нужный диск, как выглядит деградированный массив и как начинается rebuild после замены.
Нужно подготовить и резервные копии. Colocation даёт серверу профессиональное питание, сеть и охлаждение, но не превращает RAID в бэкап. Перед физической перевозкой оборудования актуальная внешняя копия особенно важна.
Сервер может повредиться при транспортировке, накопитель способен отказать после выключения и повторного запуска, а ошибка при изменении конфигурации иногда оказывается опаснее самого переезда.
Если на машине уже находятся рабочие данные, резервная копия должна храниться отдельно от перевозимого сервера.
Затем стоит проверить память. Для серьёзной серверной платформы полезен полноценный memory test или встроенная аппаратная диагностика. Ошибки RAM имеют неприятное свойство проявляться нерегулярно, поэтому лучше обнаружить нестабильный модуль до того, как машина окажется за закрытой дверью дата-центра.
То же относится к системному журналу BMC. Если iDRAC, iLO или IPMI уже месяцами фиксирует ошибки вентиляторов, питания или памяти, colocation не сделает эти предупреждения менее важными.
Что настроить до подключения сервера к сети дата-центра
После аппаратной подготовки начинается сеть. До установки необходимо получить у провайдера параметры подключения: IPv4, маску или префикс, шлюз, IPv6 при наличии, DNS и информацию о VLAN, если она используется.
Не стоит рассчитывать, что сервер просто получит адрес по DHCP, как домашний компьютер. У colocation часто используется статическая конфигурация, хотя конкретная схема зависит от оператора.
Хорошая практика — подготовить сетевые настройки заранее, но оставить возможность быстро их изменить через аппаратную консоль. Если IP указан неправильно и после установки SSH не работает, доступ через IPMI или KVM становится единственным нормальным способом исправить конфигурацию без участия инженера площадки.
Поэтому удалённое управление нужно проверить особенно тщательно.
Если сервер имеет отдельный BMC, убедитесь, что известны логин и пароль, контроллер сброшен от учётных данных предыдущего владельца, его firmware обновлён и интерфейс действительно открывается.
Старые стандартные пароли на IPMI оставлять нельзя. Контроллер даёт почти физический контроль над машиной: можно перезапустить сервер, увидеть консоль и иногда подключить виртуальный ISO.
Если ЦОД предоставляет отдельную management-сеть, лучше использовать её. Открывать IPMI напрямую в публичный интернет без ограничений не стоит.
При отсутствии собственного аппаратного контроллера заранее узнайте, как предоставляется IP-KVM. Иногда он подключается временно по заявке, иногда доступна постоянная консоль.
После сети нужно решить вопрос операционной системы. Если Linux или Windows уже установлены, перед переездом стоит обновить систему, проверить загрузчик и убедиться, что она запускается после полного отключения питания.
Это звучит очевидно, но сервер, который месяцами не выключался, иногда после первого cold boot обнаруживает проблему с RAID, загрузчиком или файловой системой.
Полезно буквально полностью выключить машину, оставить её на несколько минут и выполнить обычный холодный запуск. Если после этого система самостоятельно поднимается и сервисы стартуют, вероятность неприятного сюрприза после установки в стойку становится меньше.
Удалённые службы тоже нужно проверить заранее. SSH должен запускаться автоматически. Для Windows необходимо убедиться, что RDP и firewall настроены правильно. Если используется VPN для административного доступа, он тоже должен восстанавливаться после перезагрузки без ручного вмешательства.
Не стоит оставлять единственным способом входа пользователя с паролем, который записан только на локальном компьютере одного администратора. Доступ к критичной инфраструктуре должен быть документирован и безопасно сохранён.
Если сервер переносится из офиса или другого ЦОД вместе с действующим сайтом, заранее продумайте DNS. После установки IP, скорее всего, изменится. Значит, записи домена нужно будет переключить.
Перед миграцией можно уменьшить TTL DNS, чтобы после смены адреса пользователи быстрее начали обращаться к новой площадке. Делать это нужно заранее, а не за минуту до отключения старого сервера.
Если переезжает база или другой постоянно изменяющийся сервис, простого копирования файлов недостаточно. Нужно выбрать схему миграции, чтобы данные, появившиеся между созданием копии и физическим отключением машины, не потерялись.
При переносе самого физического сервера задача несколько проще, потому что диски едут вместе с машиной, но период недоступности всё равно нужно планировать. Пока сервер выключен, находится в дороге и устанавливается в стойку, сайт работать с него не сможет.
Для критичного проекта лучше заранее поднять временный резервный сервер или переключить сервис на другой узел.
Если colocation используется для нового сервера, а не переезда существующего, момент проще. Машину можно полностью настроить локально, установить в ЦОД, выполнить финальную проверку и только потом направить на неё домен.
Перед отправкой оборудования нужно также подготовить информацию для самого дата-центра. Обычно потребуются модель сервера, форм-фактор, количество блоков питания, энергопотребление, набор сетевых подключений и иногда серийный номер.
Если оборудование отправляется транспортной компанией, стоит заранее согласовать процедуру приёмки. Не каждый ЦОД автоматически принимает любую посылку, пришедшую на адрес здания.
Сервер нужно нормально упаковать. Для тяжёлой машины предпочтительна оригинальная коробка с формованными вставками или профессиональная транспортная упаковка. Накопители в hot-swap корзинах должны быть зафиксированы, а тяжёлые внутренние компоненты не должны свободно перемещаться.
Особенно осторожно стоит перевозить машину с крупными GPU. Тяжёлая видеокарта создаёт большую нагрузку на слот PCI Express при ударах. Для транспортировки её иногда разумнее снять и упаковать отдельно, если конструкция сервера это допускает.
После установки сервер не стоит сразу считать готовым к эксплуатации. Сначала нужно проверить оба блока питания, сетевые интерфейсы, IPMI и доступность операционной системы.
Затем проверяется мониторинг. Если машина будет работать без физического присутствия владельца, необходимо получать уведомления о высокой температуре, деградации RAID, ошибках накопителей и недоступности сервисов.
Для собственного оборудования особенно полезен аппаратный мониторинг через BMC. Операционная система может сообщить о проблемах диска или памяти, но отдельный контроллер видит и другие компоненты: вентиляторы, блоки питания, температуры и аппаратный журнал событий.
После запуска желательно проверить и внешнюю доступность сайта из нескольких сетей, а не только с компьютера администратора. DNS должен указывать на правильный адрес, сертификаты должны выпускаться или обновляться без ошибок, а firewall не должен случайно блокировать часть пользователей.
Если используется IPv6, проверять его нужно отдельно. Сайт способен прекрасно работать по IPv4 и одновременно быть недоступным по AAAA-записи из-за неправильной маршрутизации или firewall.
Наконец, нужно заранее решить, что произойдёт после аппаратного отказа.
Если сломается hot-swap диск, есть ли запасной накопитель на площадке? Если откажет блок питания, имеется ли замена? Если выйдет из строя материнская плата, кто доставит новую? Может ли дата-центр временно хранить комплект ЗИП?
При Remote Hands инженер способен выполнить физическую замену вместо администратора, но только если нужный компонент уже есть и инструкция понятна.
Для одного стандартного сервера не нужно держать в ЦОД половину второго компьютера. Но запасной SSD или специфический блок питания может сократить восстановление с суток до нескольких минут.
Особенно это важно для оборудования, которое уже снято с производства. Совместимая деталь для старой массовой серверной платформы обычно находится легко, а редкий контроллер или нестандартный PSU способен стать настоящей проблемой.
После запуска полезно сохранить документацию по физической конфигурации: какие диски стоят в каких корзинах, какие сетевые порты используются, куда подключены блоки питания, какой IP имеет management-интерфейс и какие компоненты хранятся в ЗИП.
Эта информация кажется избыточной, пока сервер один и его собирал тот же человек, который сейчас администрирует систему. Через два года оборудование может обслуживать другой специалист, а в стойке уже будет несколько почти одинаковых машин.
Хорошая маркировка и документация особенно важны для удалённых физических работ. Инженеру ЦОД намного безопаснее получить инструкцию заменить диск в сервере SRV-WEB-01, корзина 3, индикатор включён, чем предложение найти неисправный SSD.
Именно поэтому подготовка к colocation является не столько процедурой доставки железа в дата-центр, сколько переходом к удалённой эксплуатации собственного оборудования.
После установки вы больше не можете в любой момент открыть корпус, переставить кабель или посмотреть на экран. Поэтому всё, что можно проверить, настроить и документировать заранее, лучше сделать до отправки сервера.
Хорошо подготовленная машина после установки должна вести себя довольно скучно: включиться, получить сеть, автоматически запустить систему, стать доступной через удалённое управление и начать работать под мониторингом. Чем меньше неожиданностей происходит в первые часы после colocation, тем лучше была проведена подготовка.
