Когда собственный сервер уже куплен и решение разместить его в дата-центре принято, остаётся выбрать тариф colocation. Именно на этом этапе легко переплатить за возможности, которые машине никогда не понадобятся, или, наоборот, взять слишком простой вариант и обнаружить ограничения уже после установки оборудования в стойку.
Тарифы colocation выглядят сложнее обычного хостинга. Здесь недостаточно сравнить объём диска или количество сайтов. Сервер уже принадлежит клиенту, поэтому дата-центр продаёт инфраструктуру вокруг него: место в стойке, электрическую мощность, сетевое подключение, IP-адреса, физический доступ и дополнительные услуги.
Для одного сервера выбор обычно можно свести к нескольким параметрам. Нужно знать размер корпуса, реальное энергопотребление, количество блоков питания, требования к интернет-каналу, необходимость отдельного IPMI и то, насколько критичен простой.
Если эти характеристики известны, самый дорогой тариф почти никогда не требуется. Лучше подобрать конфигурацию под существующую машину и оставить небольшой запас на нормальное развитие.
Сначала определите что действительно требуется вашему серверу
Первый параметр — количество юнитов. Если сервер имеет стандартный форм-фактор 1U, оплачивать 2U только ради запаса обычно бессмысленно. Для машины 2U, наоборот, нельзя рассчитывать на тариф для одного юнита только потому, что внутри установлено немного компонентов.
Размер стоит проверить заранее по документации шасси. Кроме высоты иногда имеет значение глубина корпуса и наличие подходящих направляющих. Для стандартных серверов Dell, HPE, Lenovo или Supermicro с этим обычно нет проблем, но необычную самосборную машину лучше согласовать с ЦОД до доставки.
Следующий параметр намного важнее — электрическая мощность.
У тарифов colocation может быть одинаковая цена за один юнит, но совершенно разный включённый лимит по ваттам. Для современного однопроцессорного сервера без GPU одной конфигурации будет достаточно, а мощная двухпроцессорная машина уже потребует расширенного варианта.
Ориентироваться только на наклейку блока питания нельзя. Если установлен БП на 800 Вт, сервер не обязательно потребляет 800 Вт постоянно. Реальную нагрузку лучше измерить через BMC, iDRAC, iLO, IPMI или внешний ваттметр.
Полезно знать обычное потребление и максимум под нагрузкой. Если сервер обычно использует около 200 Вт, а во время стресс-теста достигает 320 Вт, тариф с лимитом ровно 200 Вт очевидно слишком мал.
Но оплачивать киловатт ради такого сервера тоже нет необходимости.
Количество блоков питания влияет на тариф
Если у сервера один PSU, вопрос довольно простой: требуется одна линия питания.
При наличии двух резервных блоков стоит решить, нужно ли полноценное A/B-подключение. В такой схеме первый PSU получает питание от линии A, второй — от линии B. Отказ одной ветви не должен выключать машину.
В некоторых тарифах две розетки уже предусмотрены, в других второе питание является отдельной услугой.
Для тестового или резервного сервера можно осознанно отказаться от такой схемы и подключить один БП. Для основного коммерческого проекта небольшая экономия может быть менее важна, чем возможность пережить проблему одной линии.
Поэтому при сравнении тарифов нужно смотреть не просто на количество розеток, а на то, являются ли они действительно независимыми.
Следующий пункт — интернет-порт.
Для большинства обычных сайтов 1 Гбит/с является огромным запасом. Даже довольно посещаемый интернет-магазин редко постоянно использует такой канал полностью.
Поэтому выбирать дорогой тариф только ради 10 Гбит/с обычно нет смысла, если проект не раздаёт большие файлы, видео, резервные копии или другой тяжёлый контент.
Намного важнее правила учёта трафика.
Один оператор предоставляет определённую скорость без лимита объёма. Другой предлагает гигабитный порт, но включает ограниченное количество терабайт в месяц. Третий тарифицирует канал по среднему или пиковому использованию.
Для обычного сайта разница может вообще не проявиться. Для файлового проекта она способна существенно изменить ежемесячный счёт.
Поэтому перед выбором тарифа полезно посмотреть реальную статистику текущего сервера. Если за месяц он передаёт несколько сотен гигабайт, огромный пакет трафика не нужен.
Если статистики пока нет, лучше выбрать тариф с понятной возможностью увеличить полосу позже.
Не покупайте дополнительные IP без задачи
Ещё одна строка в тарифах colocation — публичные IP-адреса.
Для одного веб-сервера обычно достаточно одного IPv4. На нём можно разместить несколько сайтов с HTTPS, поскольку современные веб-серверы и браузеры поддерживают SNI.
Дополнительные IPv4 нужны тогда, когда существует конкретная архитектурная задача: виртуальные машины, почтовый сервер, VPN, отдельные сервисы или интеграции с фильтрацией по IP.
Покупать блок адресов на будущее нет особого смысла. IPv4 является дефицитным ресурсом и обычно оплачивается отдельно.
IPv6 полезно подключить, если ЦОД предоставляет его без сложностей. Но сам по себе IPv6 тоже не является причиной выбирать более дорогой тариф.
Следующий вопрос — аппаратный удалённый доступ.
Если сервер имеет IPMI, iDRAC или iLO, желательно иметь возможность подключаться к нему независимо от основной операционной системы. Через такой интерфейс можно увидеть консоль загрузки, перезагрузить машину и иногда подключить ISO для восстановления системы.
В одном ЦОД management-порт может подключаться бесплатно, в другом потребуется отдельный Ethernet и IP или VPN-доступ.
Для production-сервера я бы не экономила именно на возможности удалённой аварийной консоли. Она требуется редко, но после неудачного изменения сети или загрузчика позволяет решить проблему без физического визита.
Если собственной BMC-консоли нет, стоит узнать стоимость временного IP-KVM.
Какие дополнительные услуги нужны не каждому серверу
Remote Hands — один из самых полезных примеров. Инженер дата-центра может физически заменить накопитель, переставить кабель, проверить индикатор или выполнить другую простую операцию вместо клиента.
Но если дата-центр находится рядом и администратор готов приезжать сам, включать большой пакет инженерных часов в тариф не обязательно.
Для компании из другого города ситуация противоположная. Здесь стоимость и скорость Remote Hands становятся одной из ключевых характеристик тарифа.
Лучше заранее узнать минимальный оплачиваемый интервал. Если любое обращение тарифицируется как целый час, даже пятиминутная замена диска способна быть относительно дорогой.
Некоторые операторы включают небольшой объём таких работ в ежемесячный тариф. Для одного сервера этого может хватать с большим запасом.
Похожая логика относится к хранению ЗИП. Если сервер использует стандартные компоненты и находится рядом, отдельное место для запасных деталей может не требоваться.
Если машина стоит в другом регионе или использует редкие блоки питания и контроллеры, небольшой комплект запасных компонентов на площадке уже становится полезным.
Отдельный мониторинг ЦОД тоже нужен не всегда. Дата-центр и так следит за собственной инженерной инфраструктурой, но состояние клиентской операционной системы и RAID обычно остаётся ответственностью владельца.
Если у компании уже есть Zabbix, Prometheus или другая система мониторинга, оплачивать аналогичную базовую услугу оператора может быть избыточно.
Другое дело, если сервер вообще никто не контролирует круглосуточно. Тогда managed monitoring способен быть полезным дополнением.
То же относится к системному администрированию.
Colocation сам по себе не включает настройку Linux, обновление PHP, базы данных и резервных копий. Если в компании есть собственный администратор, покупать managed-обслуживание не требуется.
Если такого специалиста нет, самый дешёвый unmanaged colocation способен оказаться не лучшим вариантом.
Сервер физически будет работать в идеальном ЦОД, но при программной проблеме никто не восстановит сервис автоматически.
Защита от DDoS — ещё одна характеристика, которую нужно выбирать по риску проекта.
Для небольшого корпоративного сайта базовой фильтрации провайдера часто достаточно. Для игрового сервера, публичного API или ресурса, который уже подвергался атакам, условия защиты становятся намного важнее.
Нужно выяснить, что включено в обычный тариф и в какой момент появляется дополнительная плата.
Если защита тарифицируется отдельно, покупать максимальный пакет только ради спокойствия не всегда рационально. Но и ждать первой крупной атаки для изучения условий тоже не стоит.
При выборе услуги colocation вообще полезно сразу разделить обязательные и опциональные компоненты. Тогда тариф становится гораздо проще читать.
Для типичного одного веб-сервера обязательная часть может выглядеть так: один или два юнита по фактическому размеру, достаточная электрическая мощность, основной сетевой порт, один публичный IPv4 и удалённый management-доступ.
Если сервер критичен к простою, добавляются A/B-питание и, возможно, резервное сетевое подключение.
Если ЦОД находится далеко, становится важнее Remote Hands.
Остальные возможности подключаются только при реальной необходимости.
Очень полезный критерий тарифа — возможность его изменить после установки.
Точно предсказать нагрузку на годы вперёд невозможно. Через несколько месяцев сервер может получить дополнительный накопитель, начать передавать больше трафика или потребовать второй сетевой интерфейс.
Поэтому я бы предпочла чуть более простой тариф у ЦОД, где мощность и сеть можно увеличить без переезда, чем дорогой пакет со всеми возможностями заранее.
Особенно важно уточнить увеличение электрического лимита. Если стойка уже работает возле предела, оператор физически не сможет добавить мощность конкретному серверу без его переноса.
Для обычной 1U-машины это редко становится проблемой, но для GPU и других энергоёмких систем стоит проверить заранее.
То же относится к расширению пространства. Сегодня сервер занимает 1U, а через год компания привозит ещё две машины. Хорошо, если рядом можно получить дополнительные юниты и соединить оборудование внутренней сетью.
Если свободного места нет, инфраструктура окажется разбросана по разным стойкам.
Это не критично, но иногда создаёт дополнительные кабельные и сетевые расходы.
При сравнении тарифов стоит также посмотреть разовые платежи. Некоторые услуги имеют не только ежемесячную стоимость, но и плату за подключение.
Монтаж сервера, cross-connect, дополнительный сетевой порт или изменение схемы питания могут оплачиваться отдельно.
Если сервер будет стоять несколько лет, небольшой разовый платёж почти не влияет на экономику. При размещении на несколько месяцев он становится заметнее.
Минимальный срок договора тоже важен.
Для постоянного production-сервера годовой контракт может давать хорошую цену. Для временной машины лучше сохранить возможность отказаться от услуги через несколько месяцев.
Не стоит забывать и о порядке изменения тарифа в меньшую сторону. Иногда увеличить мощность легко, а уменьшить оплачиваемый лимит можно только после окончания периода договора.
Лучше узнать это до размещения.
Самый простой способ выбрать тариф — составить маленькую таблицу требований для конкретного сервера ещё до запроса цены.
Запишите форм-фактор, глубину, реальную пиковую мощность, количество PSU, число необходимых сетевых портов, ожидаемый трафик, количество IPv4, наличие IPMI и необходимость Remote Hands.
Этот же список можно отправить нескольким дата-центрам.
Тогда вы получите расчёты одной и той же конфигурации и сможете нормально сравнить предложения.
Без такого списка один менеджер посчитает вам минимальное размещение, второй сразу включит резервное питание, а третий добавит расширенную сеть и обслуживание. Цены будут разными, хотя фактически сравниваются разные услуги.
Для большинства владельцев одного стандартного сервера выбор оказывается проще, чем выглядит в прайс-листе.
Не нужен максимальный тариф. Не нужны десятки IP. Не нужен канал 10 Гбит/с, если машина размещает обычный сайт. Не нужно покупать целую стойку ради одного 1U.
Нужно достаточно места, питания и сети для текущей конфигурации плюс возможность без сложного переезда добавить необходимые ресурсы позже.
Именно такой тариф обычно оказывается самым выгодным: он не ограничивает работу сервера сегодня, но и не заставляет каждый месяц оплачивать инфраструктуру, которая существует только на случай гипотетического роста когда-нибудь в будущем.
