Москва остаётся одним из самых очевидных вариантов для colocation, если компания работает с российской аудиторией и хочет разместить собственные серверы в профессиональном дата-центре. Здесь много операторов связи, несколько крупных площадок, развитая сетевая инфраструктура и достаточно большой выбор услуг от размещения одного сервера 1U до аренды отдельной стойки или изолированной серверной зоны.
Но большое количество предложений одновременно усложняет выбор. У двух московских ЦОД может быть похожая стоимость размещения и одинаковая заявленная скорость подключения, а реальная эксплуатация сервера окажется совершенно разной. Где-то проще получить дополнительную мощность, где-то лучше организован физический доступ, где-то удобнее Remote Hands, а другой дата-центр может оказаться привлекательнее по сетевой связности.
Для colocation особенно важно помнить, что оборудование принадлежит клиенту. Если после нескольких месяцев выяснится, что площадка не подходит, сервер нельзя перенести в другой ЦОД одной кнопкой. Его придётся отключить, забрать, физически перевезти и снова установить. Поэтому выбрать площадку правильно с первого раза значительно проще, чем потом организовывать миграцию работающей инфраструктуры.
На что смотреть при выборе colocation в Москве
Начинать я бы стала не с района Москвы и не с цены за один юнит, а с требований самого оборудования. Нужно определить форм-фактор сервера, реальное энергопотребление, количество блоков питания, число сетевых подключений, необходимую пропускную способность и предполагаемый рост инфраструктуры.
Один обычный сервер 1U с двумя SSD и умеренным энергопотреблением предъявляет к дата-центру совсем другие требования, чем 2U-машина с двумя процессорами или GPU. Ещё сильнее отличается сервер хранения с большим количеством накопителей.
Мощность особенно важна. Условия colocation обычно предполагают определённый энергетический лимит. Если сервер потребляет больше, стоимость размещения может измениться. Поэтому сравнивать два предложения только по цене юнита бессмысленно, пока неизвестно, сколько электрической мощности включено.
Для машины с двумя блоками питания нужно выяснить, можно ли подключить их к независимым линиям. Два блока имеют смысл именно тогда, когда отказ одного элемента электропитания не отключает весь сервер. Если оба подключены к одной и той же точке распределения, резервирование получается неполным.
Не менее важна система электроснабжения самого ЦОД. В профессиональной площадке используются ИБП, резервные вводы и дизель-генераторные установки, позволяющие продолжать работу при проблемах с городской электросетью. Для клиента важно не столько количество оборудования в техническом помещении, сколько понятная архитектура резервирования и регламент обслуживания.
Расположение в Москве важно не только из-за задержки
При выборе московского дата-центра часто первым делом смотрят на его адрес. Для сетевой задержки несколько дополнительных километров внутри одного региона обычно имеют меньшее значение, чем маршрутизация между операторами. Намного важнее, насколько хорошо сеть конкретной площадки связана с российскими провайдерами и точками обмена трафиком.
Но география становится важной с другой стороны. Собственное оборудование иногда всё-таки приходится посещать физически. Нужно установить память, привезти новый диск, поменять нестандартный компонент, провести модернизацию или забрать сервер. Если до ЦОД можно сравнительно быстро добраться из офиса, такие работы организовать проще.
Поэтому дата-центр на другом конце Московского региона может быть технически прекрасным, но для компании, которая собирается часто работать со своим оборудованием самостоятельно, дорога превращается в дополнительный эксплуатационный фактор.
Если физические визиты практически не планируются, важность адреса снижается, а на первое место выходит Remote Hands. Тогда инженеры дата-центра выполняют необходимые действия с оборудованием по инструкции клиента.
Перед заключением договора стоит узнать, работает ли такая услуга круглосуточно, какие операции входят в базовое обслуживание, а какие оплачиваются отдельно. Простая замена горячего диска и сложная разборка сервера для установки нового контроллера — совершенно разные задачи.
Полезно заранее проверить и порядок собственного доступа. Можно ли приехать ночью? Требуется ли заявка за несколько часов? Кто оформляет пропуск? Можно ли пройти в машинный зал самостоятельно или только с сотрудником? Для одного сервера эти детали кажутся мелочами ровно до первого срочного ремонта.
Сеть московского ЦОД нужно оценивать по реальной задаче
Для обычного сайта гигабитный порт часто предоставляет огромный запас. Поэтому при сравнении colocation не стоит автоматически выбирать предложение с максимальной цифрой пропускной способности.
Намного полезнее посмотреть, сколько трафика включено, как оплачивается превышение, какая скорость гарантируется и можно ли увеличить канал без физического переноса оборудования.
Если сервер используется для интернет-магазина или корпоративного сайта, сетевой порт может большую часть времени загружаться всего на несколько процентов. Файловое хранилище, собственный CDN, видеосервис или система резервного копирования создают совершенно другой профиль нагрузки.
Хорошо, если дата-центр предоставляет тестовый IP. До размещения оборудования можно проверить задержку и маршруты из сетей нескольких операторов, которыми пользуется основная аудитория. Один красивый ping из офиса мало о чём говорит. Полезнее посмотреть ситуацию из разных регионов и сетей.
Если серверов будет несколько, стоит уточнить возможность организации приватной сети между ними. Внутреннее соединение удобно для базы данных, резервного копирования, репликации и других задач, которые нет необходимости отправлять через публичный интернет.
Для инфраструктуры с повышенными требованиями к отказоустойчивости интересны два независимых подключения. Но наличие двух Ethernet-портов у сервера ещё ничего не гарантирует. Важно понять, подключаются ли они к разным коммутаторам и способна ли сеть пережить отказ одного из них.
Нужно заранее спросить и про IP-адреса. Для обычного веб-сервера часто достаточно одного IPv4 и IPv6. Если планируются виртуальные машины, почтовая инфраструктура, VPN или отдельные сетевые сервисы, адресов может понадобиться больше.
Выдача дополнительных IPv4 сегодня является отдельной услугой, поэтому лучше выяснить условия до того, как инфраструктура уже установлена.
Отдельного внимания заслуживает защита от DDoS. Сервер с гигабитным портом не защищён от атаки просто потому, что его сетевой интерфейс быстрый. Вредоносный поток должен фильтроваться выше, внутри сети провайдера, прежде чем забьёт канал конкретной машины.
Если сайт коммерческий и вероятность атак для него не теоретическая, стоит узнать, какая базовая фильтрация входит в colocation и какие расширенные варианты доступны.
Как сравнить несколько московских ЦОД между собой
Самая распространённая ошибка — открыть сайты нескольких провайдеров и сравнить только цену размещения 1U. Такой подход почти гарантирует неправильный результат, потому что комплектация базового тарифа отличается.
Гораздо полезнее составить одну конкретную конфигурацию и запросить расчёт у нескольких площадок. Например: сервер 1U, определённая потребляемая мощность, два блока питания, два сетевых подключения, один IPv4, постоянный IPMI и определённая полоса интернета.
После этого цены уже можно сравнивать между собой.
В расчёт стоит включить не только ежемесячную плату. Посмотрите стоимость установки, дополнительной розетки, Remote Hands, постоянного KVM или management-порта, дополнительного трафика и IP-адресов. Если предполагается расширение, сразу узнайте стоимость второго сервера и части стойки.
Структура тарифа может оказаться важнее базовой суммы. Дешёвое размещение иногда становится дорогим после подключения всех необходимых опций. Более высокий первоначальный тариф может уже включать большую часть того, что другому оператору приходится докупать отдельно.
При оценке стоимости colocation поэтому имеет смысл считать всю конфигурацию, а не только аренду физического места в стойке.
Дальше стоит посмотреть на инженерную инфраструктуру. Уровень Tier полезен как ориентир, но я бы не превращала его в единственный критерий. Два дата-центра одного класса способны значительно отличаться по сетевой инфраструктуре, организации поддержки, доступу клиентов и фактическому удобству работы.
Если площадка заявляет Tier III, имеет смысл понимать, относится ли это к проекту, построенному объекту или сертификации эксплуатации. Для обычного владельца одного сервера подробности стандартов могут быть избыточны, но громкая цифра в рекламе не должна заменять конкретные вопросы о резервировании.
Практически полезнее узнать, что произойдёт после отказа одного источника питания, одного сетевого коммутатора или внешнего оператора связи.
Следующий критерий — физическая безопасность. Московские дата-центры работают с оборудованием многих клиентов, и доступ к машинным залам должен контролироваться. Системы пропусков, видеонаблюдение, охрана и разграничение доступа являются нормальной частью профессионального ЦОД.
Для одного сервера нет необходимости требовать собственный закрытый зал. Но должно быть понятно, кто физически способен подойти к стойке и как фиксируются подобные действия.
Если оборудование содержит чувствительные корпоративные данные, требования к физической защите могут быть выше. Тогда рассматривают отдельный шкаф, изолированную зону или дополнительные процедуры доступа.
Полезно обратить внимание и на пожарную безопасность. Серверный зал отличается от обычного офиса высокой концентрацией электрического оборудования, поэтому системы раннего обнаружения и пожаротушения имеют большое значение. Клиенту не обязательно самостоятельно разбираться во всех инженерных решениях, но наличие профессиональной системы должно быть обязательным.
Отдельный вопрос — склад запасных компонентов. Если сервер принадлежит вам, дата-центр не обязан иметь совместимый блок питания, RAID-контроллер или специфический SSD. Для стандартных hot-swap накопителей проблема решается проще, а редкие детали лучше хранить в собственном ЗИП.
Стоит спросить, можно ли оставить комплект запасных компонентов непосредственно на площадке. Для компании из другого города такая возможность особенно ценна.
Представим отказ накопителя ночью. Если запасной диск уже находится в ЦОД, инженер получает заявку и меняет его. Если нужная деталь лежит в офисе на другом конце Москвы, сначала нужно организовать доставку. Если она вообще находится в другом регионе, время восстановления растёт ещё сильнее.
Нужно заранее понимать и ответственность дата-центра за оборудование. При colocation сервер принадлежит клиенту. Если выходит из строя материнская плата, ЦОД обычно не обязан бесплатно предоставить новую машину. Он обеспечивает инфраструктуру размещения и выполняет согласованные физические работы.
Это принципиальное отличие от аренды выделенного сервера, где неисправное оборудование является проблемой самого хостинг-провайдера.
Поэтому для критического собственного сервера может иметь смысл резервная машина. Она необязательно должна постоянно работать под полной нагрузкой. Иногда достаточно иметь оборудование, на которое можно восстановить сервис после серьёзной аппаратной аварии.
Следующий критерий — возможность роста. Если сегодня требуется один 1U, а через год планируется несколько серверов, желательно заранее понимать, сможет ли дата-центр разместить их рядом и выделить дополнительную мощность.
Свободный юнит физически ещё не означает возможность установить очередную машину. Стойка может уже находиться возле энергетического лимита. Особенно это важно для GPU и других энергоёмких серверов.
При заметном росте инфраструктуры экономически выгоднее может стать часть стойки или целый шкаф. Поэтому полезно заранее посмотреть, какие варианты предлагает оператор при масштабировании.
Для нескольких серверов важна и возможность связать их друг с другом на высокой скорости. Если позже потребуется отдельный кластер базы данных или система хранения, инфраструктура ЦОД должна позволять организовать необходимые соединения без странных обходных решений.
Не стоит забывать и о связности с облаками. Современная инфраструктура часто становится гибридной: собственные серверы работают в colocation, а часть временной нагрузки переносится в облачные ресурсы. Если оператор позволяет удобно объединить эти среды приватной сетью, у проекта появляется больше вариантов масштабирования.
Но покупать такую возможность заранее только ради красивой архитектуры тоже не нужно. Если весь проект спокойно работает на одной физической машине, дополнительная сложность не приносит пользы.
При финальном выборе я бы оставила три-четыре подходящих московских площадки и отправила им одинаковое описание оборудования и требований. Ответы отдела продаж тоже многое показывают.
Если на конкретные технические вопросы приходят конкретные ответы, это хороший признак. Если вместо схемы резервирования и условий доступа постоянно звучат только общие фразы о максимальной надёжности, стоит запросить больше деталей.
Для colocation особенно полезен разговор не только с менеджером, но и с техническим специалистом. Вопросы про питание, LACP, IPMI, резервные линии и внутреннюю сеть намного быстрее решаются с человеком, который реально понимает инфраструктуру площадки.
Если есть возможность посетить ЦОД до заключения договора, для серьёзной инфраструктуры этим стоит воспользоваться. Не ради того, чтобы оценить красоту стоек, а чтобы посмотреть организацию доступа, порядок работы с клиентами и обсудить будущую конфигурацию на месте.
Для размещения одного недорогого сервера такая экскурсия может быть излишней. В этом случае достаточно нормальной репутации оператора, прозрачных условий и понятной технической документации.
Отдельного рейтинга лучший colocation Москвы, который подошёл бы каждому, не существует. Одной компании важнее минимальная цена 1U, другой нужен большой запас мощности, третьей критично находиться рядом с офисом, а четвёртой требуется круглосуточный Remote Hands, потому что собственные администраторы находятся в другом регионе.
Поэтому хороший московский ЦОД — не обязательно самый большой, самый дорогой или расположенный ближе всего к центру. Это площадка, где условия питания, сети, доступа и технической поддержки соответствуют конкретному серверу и планам проекта.
Если инфраструктура подобрана правильно, местонахождение собственного сервера довольно быстро перестаёт ощущаться. Он просто работает в стойке, получает стабильное питание и связь, а владелец вспоминает о физическом дата-центре лишь во время редкой модернизации. Для colocation это и есть один из лучших признаков удачного выбора.
