Размещение собственного сервера в ЦОД обычно начинается не с доставки оборудования, а с запроса коммерческого предложения. Клиент сообщает дата-центру параметры машины, оператор рассчитывает место в стойке, электрическую мощность, сетевое подключение и дополнительные услуги, после чего предлагает конкретные условия. Именно на этом этапе проще всего понять реальную стоимость colocation и избежать ситуации, когда после установки сервера к первоначальной цене начинают добавляться новые платежи.
Запрос вроде сколько стоит разместить сервер 1U даёт слишком мало информации. Два сервера одинаковой высоты могут отличаться по энергопотреблению в несколько раз. Один использует один блок питания и один сетевой интерфейс, другому нужны две независимые линии питания, отдельный management-порт, несколько IPv4 и повышенная скорость сети. Формально обе машины занимают 1U, но фактически дата-центр предоставляет им разный набор ресурсов.
Поэтому для получения нормального расчёта лучше сразу отправить оператору небольшую техническую спецификацию. Для этого не требуется самостоятельно проектировать инфраструктуру ЦОД. Большинство необходимых характеристик можно найти в документации сервера или посмотреть непосредственно на оборудовании.
Хорошее коммерческое предложение тоже должно быть прозрачным. Из него должно быть понятно, сколько места выделяется, какая электрическая мощность включена, сколько подключений питания предусмотрено, какой сетевой порт получает сервер, как учитывается трафик и какие дополнительные действия оплачиваются отдельно.
Если клиент получает только итоговую сумму за размещение сервера без расшифровки условий, сравнивать несколько дата-центров становится практически невозможно.
Какие данные нужно сообщить ЦОД для расчёта размещения сервера
Первое, что потребуется оператору, — форм-фактор оборудования. Для стандартного стоечного сервера указывается высота 1U, 2U, 4U или другое значение. Если это готовая машина Dell, HPE, Lenovo, Supermicro или другого производителя, полезно сразу сообщить точную модель.
Для самостоятельно собранного сервера желательно дополнительно указать глубину корпуса. Не каждое нестандартное шасси одинаково удобно устанавливается в обычную 19-дюймовую стойку. Особенно это касается коротких корпусов, Tower-серверов и специализированного оборудования.
Если используются штатные направляющие, нужно убедиться, что они сохранились и будут переданы вместе с сервером. Тяжёлую машину нельзя просто положить на соседнее оборудование. При отсутствии rails дата-центр может предложить полку или другое решение, но условия лучше узнать до доставки.
Энергопотребление лучше указывать реальное
Следующий параметр — мощность. Именно здесь часто возникает первая ошибка. Клиент видит два блока питания по 800 Вт и сообщает оператору потребление 1600 Вт. В действительности это максимальная мощность самих PSU, а не постоянное потребление сервера.
Намного полезнее сообщить реальное значение под рабочей нагрузкой и максимальный показатель, который наблюдался во время тестирования. У многих серверов эти данные доступны через IPMI, iDRAC, iLO или другой контроллер аппаратного управления. Для самосборной машины можно использовать внешний ваттметр.
Дата-центру нужен такой показатель не ради формальности. В стойке ограничено не только количество свободных U, но и допустимая электрическая и тепловая нагрузка. Поэтому компактный GPU-сервер иногда оказывается сложнее разместить, чем более крупную, но экономичную машину.
Если сервер ещё только планируется купить, оператору можно передать предполагаемую конфигурацию и техническую документацию производителя. Для стандартной серверной платформы этого обычно достаточно для предварительного расчёта.
Следом нужно указать количество блоков питания. Если PSU два, стоит сразу решить, требуется ли подключение к независимым линиям A и B.
Для некритичной машины можно использовать более простую схему. Для основного коммерческого сервера чаще интереснее вариант, где первый блок получает питание от одной ветви, а второй от другой. Тогда проблема одной линии не обязательно выключает всю систему.
Важно написать это непосредственно в запросе. Формулировка сервер имеет два БП не гарантирует, что менеджер автоматически рассчитает два независимых подключения. В одном ЦОД они уже входят в тариф, в другом вторая линия оплачивается отдельно.
После питания описывается сеть. Для обычного веб-сервера часто достаточно одного Ethernet-порта. Можно указать требуемую скорость, например 100 Мбит/с или 1 Гбит/с, и ожидаемый объём трафика, если он уже известен.
Здесь тоже полезна конкретика. Запрос нужен быстрый интернет почти ничего не говорит оператору. Гораздо лучше написать, что требуется порт 1 Гбит/с, сервер обслуживает публичный сайт, а большие кратковременные потоки возможны во время резервного копирования или передачи файлов.
Если проект новый и статистики ещё нет, можно попросить рассчитать два варианта. Например, сравнить постоянную полосу 100 Мбит/с и порт 1 Гбит/с с определённой месячной квотой.
Следующий пункт — IP-адреса. Для обычного сервера с несколькими сайтами чаще всего достаточно одного публичного IPv4. Дополнительный адрес каждому домену не требуется.
Если планируются виртуальные машины, собственная почта, VPN или сервисы, которым действительно нужны отдельные адреса, количество IPv4 лучше сообщить заранее. Одновременно можно уточнить условия IPv6.
Отдельно указывается аппаратное управление. Если на сервере есть IPMI, iDRAC или iLO с выделенным сетевым портом, нужно понять, как он будет подключён в новом ЦОД.
Хорошая схема не предполагает бесконтрольного доступа к BMC из публичного интернета. Оператор может предложить management-сеть, VPN или другой защищённый способ подключения.
Если собственного аппаратного контроллера нет, стоит узнать, предоставляется ли IP-KVM по запросу и входит ли эта услуга в размещение.
Для сервера, к которому физически сложно приехать, такая возможность особенно полезна. После ошибки в сетевой конфигурации или загрузчике обычный SSH уже не поможет, а удалённая консоль позволяет восстановить систему без поездки в дата-центр.
Если оборудование необычное, лучше сразу описать его особенности. Несколько GPU, большое количество HDD, нестандартные сетевые карты, высокая масса или специальные силовые разъёмы должны быть известны оператору до доставки.
То же относится к дополнительному оборудованию. Если рядом с сервером планируется установить коммутатор, firewall или другое устройство, оно тоже занимает место и потребляет электричество.
После такой спецификации дата-центр уже способен рассчитать не абстрактное размещение 1U, а именно вашу конфигурацию.
Что ещё стоит спросить до получения счёта
Даже подробного описания сервера недостаточно, если не уточнить дополнительные условия эксплуатации. Один из первых вопросов — как организованы физические работы с оборудованием.
Если ночью выходит из строя hot-swap диск, кто его заменит? Можно ли передать инженеру запасной накопитель заранее? Сколько стоит такая операция и как быстро она выполняется?
Для компании, расположенной рядом с ЦОД, это менее критично. Администратор при необходимости может приехать самостоятельно. Если сервер находится в другом городе, Remote Hands становится значительно важнее.
Полезно сразу узнать и правила физического доступа клиента. Можно ли приехать круглосуточно, требуется ли заранее оформить заявку, кто имеет право войти в машинный зал и сколько времени занимает оформление пропуска.
Следующий вопрос касается защиты от DDoS. Если сервер предоставляет публичный сервис, стоит понять, какая фильтрация входит в обычное сетевое подключение и где начинается платная расширенная защита.
Фраза базовая защита включена малоинформативна без понимания того, что произойдёт во время реальной атаки. Лучше узнать, включается ли фильтрация автоматически и может ли атакуемый IP быть временно заблокирован при превышении определённых лимитов.
Если сервер содержит критичные данные, имеет смысл спросить и о дополнительных возможностях резервного копирования. Сам colocation обычно не означает, что дата-центр копирует содержимое ваших дисков. Backup остаётся ответственностью владельца, если отдельная услуга не заказана.
Поэтому наличие профессионального ЦОД не отменяет внешнюю резервную копию.
Как читать коммерческое предложение и сравнивать несколько ЦОД
После получения расчёта самое важное — не смотреть только на итоговую месячную сумму. Сначала нужно убедиться, что несколько предложений действительно относятся к одинаковой конфигурации.
Представим, что один дата-центр предлагает размещение за условно меньшую сумму. Но в неё входит одна линия питания, ограниченная мощность и 100 Мбит/с. Второй оператор стоит дороже, зато сразу включает две независимые линии, больший энергетический лимит и гигабитный порт.
Сравнивать эти две суммы напрямую нельзя. Это разные услуги.
Удобнее разложить предложение на несколько компонентов: физическое место, мощность, питание, сеть, трафик, IP, управление и инженерные работы. Тогда становится понятно, за что именно платит клиент.
В первую очередь проверяется количество U. Если сервер занимает 1U, в договоре должно быть понятно, сколько физического пространства предоставляется и можно ли позже добавить соседний юнит.
Затем смотрим электрическую мощность. Важно понять не только включённое количество ватт, но и возможность увеличить лимит позже. Если через год в сервер добавят GPU или другое энергоёмкое оборудование, сможет ли ЦОД предоставить больше мощности без физического переноса машины?
Для двух блоков питания проверяется схема A/B. Две розетки сами по себе не гарантируют независимость. Желательно получить подтверждение, что они относятся к разным ветвям электроснабжения.
По сети нужно увидеть скорость порта и правила трафика. Если указано 1 Гбит/с, стоит проверить, является ли это просто физической скоростью интерфейса или клиент действительно может использовать такую полосу в рамках тарифа.
Если есть месячная квота, необходимо знать стоимость превышения. Для файлового сервера этот параметр может оказаться важнее базовой цены всего размещения.
Полезно уточнить и возможность изменения сетевого тарифа. Новый проект может сегодня использовать несколько мегабит в секунду, а через год вырасти в несколько раз. Если перейти на более быстрый канал можно без миграции, нет необходимости сразу покупать максимальный вариант.
Отдельно проверяем IP. Один IPv4 может входить в стоимость, остальные оплачиваться дополнительно. Если нужна собственная подсеть, условия лучше обсуждать сразу.
Management-доступ тоже должен быть понятен. Если IPMI входит в отдельную внутреннюю сеть, хорошо. Если для него требуется платный порт или отдельный IP, это должно быть отражено в расчёте.
Дальше начинается то, что легко пропустить в рекламном тарифе: разовые платежи. Установка сервера, подключение дополнительного порта, cross-connect, выдача дополнительной линии питания или первоначальная настройка могут иметь отдельную стоимость.
Разовый платёж сам по себе не является недостатком. Если сервер будет стоять в ЦОД несколько лет, его влияние на общую экономику невелико. Важно только знать о нём заранее.
Похожая ситуация с Remote Hands. В одном предложении несколько минут инженерных работ могут входить в тариф, в другом действует почасовая оплата. Для исправного сервера разница почти незаметна, но после аппаратной неисправности становится вполне практической.
При оценке стоимости размещения сервера поэтому имеет смысл смотреть не только на обязательный ежемесячный платёж, но и на стоимость наиболее вероятных дополнительных действий.
Например, сколько будет стоить заменить диск, добавить сетевой порт, подключить второй блок питания или увеличить мощность.
Следующий пункт — минимальный срок договора. Некоторые тарифы выгоднее при оплате на длительный период. Для production-сервера, который будет работать в одном ЦОД несколько лет, это может быть разумно. Для временного проекта гибкий помесячный договор ценнее небольшой скидки.
Необходимо проверить и порядок прекращения услуги. Как оборудование отключается и передаётся владельцу? Нужно ли заранее подавать заявку? Может ли сервер забрать курьер или только уполномоченный сотрудник?
Эти вопросы кажутся далёкими во время первого заказа, но colocation предполагает физическое размещение имущества клиента, поэтому процедура вывоза важнее, чем при обычном виртуальном хостинге.
Если коммерческое предложение выглядит подходящим, полезно задать оператору несколько сценарных вопросов вместо просьбы ещё раз рассказать о надёжности ЦОД.
Например: что произойдёт, если перестанет работать линия A? Сможет ли сервер продолжить работу по B? Что произойдёт при отказе сетевого коммутатора? Кто ночью заменит диск? Можно ли увеличить мощность через полгода? Как получить доступ к IPMI, если основная операционная система не загружается?
Конкретные ответы дают о площадке намного больше информации, чем общие обещания высокой доступности.
Если сервер коммерчески важен, стоит отдельно выяснить границы ответственности. ЦОД отвечает за свою инфраструктуру, но сама машина принадлежит клиенту.
При отказе вашего SSD оператор может выполнить физическую замену, но не обязан бесплатно предоставить новый накопитель. При ошибке Linux питание и сеть могут быть полностью исправны, а сайт всё равно останется недоступным.
Поэтому colocation не отменяет необходимость системного администратора, мониторинга и резервных копий.
Для одного стандартного сервера итоговый запрос оператору может быть довольно коротким. Достаточно сообщить модель, форм-фактор, реальное энергопотребление, количество БП, требуемый сетевой порт, IP и необходимость management-доступа.
После этого попросить расчёт с расшифровкой всех обязательных и дополнительных платежей.
Если сравниваются несколько дата-центров, всем лучше отправлять одинаковую спецификацию. Тогда первый оператор не посчитает минимальный тариф, второй резервированную конфигурацию, а третий пакет с расширенной защитой, после чего их цены окажутся несопоставимыми.
Хорошее коммерческое предложение должно позволять понять будущий счёт ещё до того, как сервер оказался в стойке.
В этом и заключается нормальный процесс заказа colocation. Сначала описывается конкретное оборудование и требования проекта, затем оператор предлагает подходящую инфраструктуру, после чего клиент сравнивает не рекламные цены за один U, а полный набор условий.
Так размещение собственного сервера перестаёт быть услугой с непонятными дополнительными расходами и превращается в вполне предсказуемую ежемесячную статью затрат.
