Colocation обычно ассоциируется с физическими серверами, но в стойках дата-центров размещают далеко не только их. Коммутаторы, маршрутизаторы, межсетевые экраны, аппаратные балансировщики, VPN-шлюзы и другое сетевое оборудование тоже может принадлежать клиенту и работать на площадке ЦОД.
Для бизнеса такой вариант особенно интересен, когда собственная инфраструктура уже вышла за пределы одного сервера. Появляется несколько физических машин, отдельная система хранения, резервные каналы связи, собственный firewall или необходимость объединить оборудование в приватную сеть. В этот момент дата-центр предоставляет уже не просто место для сервера, а площадку, где можно собрать полноценный сетевой узел компании.
При этом заказать размещение коммутатора не всегда так же просто, как добавить ещё один сервер 1U. Сетевое устройство может занимать мало места и потреблять десятки ватт, но именно через него будет проходить весь трафик инфраструктуры. Поэтому при выборе colocation важны не только размер корпуса и электричество, но и схема подключения, резервирование, количество портов, типы интерфейсов, возможность cross-connect и доступ к консоли управления.
Особенно внимательно стоит относиться к оборудованию, отказ которого способен одновременно отключить несколько серверов. Если один коммутатор является единственной точкой подключения всей стойки, его размещение и питание должны быть продуманы не менее тщательно, чем параметры самих серверов.
Какое сетевое оборудование имеет смысл размещать в дата-центре
Самый очевидный вариант — собственный Ethernet-коммутатор. Он становится полезен, когда в ЦОД размещается несколько серверов клиента и между ними требуется отдельная локальная сеть.
Без собственного коммутатора каждый сервер можно подключить непосредственно к инфраструктуре оператора. Для двух или трёх машин это вполне рабочая схема. Но по мере роста количество соединений увеличивается, появляется внутренний трафик между серверами, а управление сетью становится зависимым от возможностей дата-центра.
Собственный коммутатор позволяет построить приватную сеть внутри своей инфраструктуры. Веб-серверы могут обращаться к базе данных через внутренние адреса, система резервного копирования получает отдельный сегмент, а служебный трафик не обязательно проходит через публичные интерфейсы.
Для нескольких серверов это не только вопрос удобства. Внутреннее соединение может работать быстрее внешнего канала и не расходовать включённый интернет-трафик, если такая схема поддерживается оператором.
Второй распространённый тип оборудования — маршрутизатор. Он нужен компаниям, которые самостоятельно управляют сетевой архитектурой, используют несколько подсетей, VPN, собственные маршруты или подключаются к нескольким операторам связи.
Для одного обычного сайта отдельный маршрутизатор чаще всего избыточен. Сетевые функции предоставляет ЦОД, а сервер получает готовое подключение и IP-адрес.
Но при размещении нескольких стоек, собственной адресной сети или сложной корпоративной инфраструктуры маршрутизатор становится полноценной частью colocation.
Firewall в ЦОД нужен не каждому серверу
Отдельный аппаратный firewall используют, когда фильтрацию требуется вынести за пределы самих серверов. Через такое устройство можно пропустить трафик нескольких машин, настроить единые правила доступа, VPN и сегментацию сети.
Для небольшой инфраструктуры ту же задачу часто решает программный firewall на сервере или виртуальная машина. Покупать отдельный аппаратный комплекс только ради того, чтобы он стоял перед одним сайтом, обычно нет необходимости.
Смысл появляется там, где устройство защищает сразу несколько систем или выполняет функции, которые компания не хочет переносить на серверы приложений.
В ЦОД также размещают аппаратные балансировщики нагрузки, VPN-концентраторы, сетевые шлюзы, устройства мониторинга и специализированные security appliance. Принцип для них тот же: оборудование принадлежит клиенту, а дата-центр предоставляет физическую и сетевую инфраструктуру вокруг него.
Иногда рядом с серверами устанавливают небольшой коммутатор исключительно для management-сети. Через него объединяются IPMI, iDRAC, iLO, управляемые PDU и другие служебные интерфейсы.
Такой подход позволяет отделить управление оборудованием от пользовательского трафика. Для инфраструктуры из десятков устройств это намного аккуратнее, чем подключать каждый BMC отдельным публичным адресом.
При этом не любое офисное сетевое устройство одинаково удобно для дата-центра. Маленький настольный коммутатор может прекрасно работать технически, но не иметь крепления для 19-дюймовой стойки, резервных блоков питания или нормального фронтального воздушного потока.
Если устройство предполагается использовать годами, серверный или операторский форм-фактор обычно удобнее.
Особое внимание стоит обратить на глубину корпуса. Сетевое оборудование часто значительно короче серверов, но встречаются крупные маршрутизаторы и модульные шасси, которые предъявляют совершенно другие требования к стойке.
Для стандартного устройства 1U проблем обычно нет. Если корпус нестандартный, его размеры лучше передать оператору ещё до заказа.
То же относится к массе. Небольшой коммутатор весит мало, а крупное операторское шасси с блоками питания, вентиляторами и интерфейсными картами может оказаться очень тяжёлым.
Для такого оборудования нужно заранее согласовать способ монтажа и допустимую нагрузку.
У сетевого оборудования бывает другой воздушный поток
У серверов стандартная схема довольно понятна: холодный воздух поступает спереди, горячий выходит сзади. Именно под это организованы холодные и горячие коридоры современных ЦОД.
У коммутаторов и маршрутизаторов ситуация сложнее. Производители выпускают модели с направлением воздуха спереди назад, сзади вперёд и даже с боковой вентиляцией.
Если устройство выбрасывает горячий воздух в холодный коридор, оно нарушает нормальную схему охлаждения стойки. Для одного маломощного коммутатора эффект может быть небольшим, но плотное сетевое оборудование выделяет заметное количество тепла.
Поэтому перед покупкой или переносом сетевого устройства полезно посмотреть направление airflow. У некоторых моделей оно определяется конкретной версией вентиляторов и блоков питания.
Это особенно важно, если в одной стойке находятся серверы и сетевое оборудование разных производителей.
Следующий параметр — количество блоков питания. Для вспомогательного коммутатора один PSU может быть приемлем. Для устройства, через которое подключена вся инфраструктура компании, отказ единственного блока питания становится значительно серьёзнее.
Если модель поддерживает два PSU, при colocation имеет смысл подключить их к независимым линиям A и B. Тогда проблема одной ветви электроснабжения не обязательно отключит коммутатор вместе со всеми подключёнными к нему серверами.
Но два блока питания нужно не просто физически вставить в корпус. Они должны действительно получать энергию от независимых источников внутри схемы ЦОД.
Такие условия лучше включить в коммерческий запрос заранее.
Что проверить в тарифе перед размещением сетевого оборудования
Первое, что необходимо определить, — сколько физического пространства занимает устройство. Для стандартного коммутатора это часто 1U, однако оператор может считать оборудование отдельно или включать его в арендованную часть стойки.
Если у компании уже размещается несколько серверов, полезно сравнить два варианта. В первом коммутатор добавляется как ещё одно отдельное устройство. Во втором инфраструктура переводится на часть стойки, внутри которой клиент самостоятельно распределяет свободные U.
При большом количестве собственного оборудования второй подход иногда удобнее, поскольку каждый новый коммутатор или firewall не превращается в отдельную позицию тарифа.
Но одного свободного U мало. Необходимо определить электрическую мощность устройства. У обычного коммутатора она может быть небольшой, однако высокопроизводительные модели, устройства с большим количеством оптических портов и особенно PoE-коммутаторы способны потреблять значительно больше.
Для PoE есть важный нюанс: максимальная мощность блока питания может включать энергию, предназначенную для подключённых устройств. Если в ЦОД PoE фактически не используется, реальное потребление самого коммутатора может быть намного ниже номинала.
Для расчёта лучше передать оператору паспортные данные и ожидаемую конфигурацию.
Затем нужно перейти к самому важному — сетевым подключениям.
Если коммутатор установлен просто для объединения собственных серверов, ему может понадобиться один или два uplink к сети дата-центра. Для отказоустойчивой схемы используют несколько соединений, однако способ их работы зависит от оборудования и возможностей оператора.
Нельзя исходить из того, что два кабеля автоматически дадут в два раза больше скорости или полное резервирование. Нужно заранее обсудить LACP, VLAN, возможные петли, резервирование портов и схему переключения.
Если компания не занимается сетевой инженерией самостоятельно, лучше попросить технических специалистов ЦОД предложить поддерживаемую конфигурацию.
Важны и физические интерфейсы. Медный RJ-45 и оптический SFP или SFP+ требуют разного подключения. При 10, 25, 40 или 100 Гбит/с появляются дополнительные требования к трансиверам, типу волокна и совместимости модулей.
Перед доставкой дорогих трансиверов стоит уточнить, какие именно модули принимает оборудование оператора.
Совместимость SFP не всегда сводится к одинаковой форме разъёма. Различаются скорость, длина волны, тип волокна, дальность и иногда программные ограничения конкретных производителей.
Если ЦОД предоставляет свой модуль, нужно узнать, входит ли он в подключение или оплачивается отдельно.
При собственной сетевой инфраструктуре быстро появляется понятие cross-connect. Это физическое соединение оборудования клиента с другим участником площадки, оператором связи или другой стойкой.
Например, компания арендует стойко-место и хочет подключить собственный маршрутизатор непосредственно к выбранному телеком-оператору. Для этого между ними организуется отдельная кроссировка.
Cross-connect обычно является самостоятельной услугой. Может взиматься разовая плата за организацию соединения и ежемесячная плата за его использование.
Поэтому если сетевой проект предполагает несколько операторов, стоимость кроссировок нужно включать в расчёт colocation с самого начала.
Для инфраструктуры, которая пока состоит из нескольких машин, такой уровень сложности может вообще не понадобиться. В этом случае проще получить готовый интернет от самого дата-центра.
Если же компания хочет выбирать операторов связи самостоятельно, наличие подходящей телекоммуникационной инфраструктуры становится одним из критериев площадки.
В коммерческом предложении также следует проверить количество сетевых портов. Один физический сервер обычно получает одно подключение, но собственный коммутатор способен изменить схему.
Дата-центр может передать один uplink, а все серверы клиента уже подключаются к его собственному оборудованию. Это удобно, но означает, что коммутатор становится критической точкой инфраструктуры.
Если он выйдет из строя, одновременно исчезнет связь у всех подключённых машин.
Поэтому для действительно важной системы стоит рассмотреть два коммутатора.
Серверы с несколькими сетевыми интерфейсами подключаются к разным устройствам, а сами коммутаторы получают независимые uplink. Такая архитектура дороже и сложнее, зато единичный отказ сетевого устройства перестаёт выключать всю стойку.
Для одного или двух некритичных серверов подобное резервирование часто избыточно. Здесь снова важен не максимальный уровень сложности, а соответствие стоимости реальным последствиям отказа.
Следующий вопрос — IP-адреса и VLAN.
Если дата-центр выдаёт клиенту несколько публичных IPv4, нужно понять, как именно они будут маршрутизироваться через собственный коммутатор или firewall.
Для простой L2-схемы всё может работать довольно прозрачно. При использовании собственных маршрутизаторов, нескольких VLAN или адресных подсетей потребуется заранее согласовать конфигурацию.
Если компания имеет собственную автономную систему и IP-префикс, условия уже относятся к более сложному уровню сетевой услуги с BGP. Не каждый стандартный тариф colocation автоматически включает такую возможность.
Для большинства небольших проектов собственная автономная система не нужна, поэтому приобретать сложный маршрутизатор только ради BGP не имеет смысла.
Намного чаще полезна простая сегментация сети.
Например, публичные серверы работают в одном VLAN, база данных в другом, management-интерфейсы в третьем. Если собственный коммутатор поддерживает VLAN, клиент получает больше контроля над внутренней архитектурой.
При этом желательно понимать границу ответственности. Дата-центр отвечает за предоставленный uplink, питание и свою сеть. Конфигурация собственного Cisco, Juniper, MikroTik, Arista или другого устройства обычно остаётся задачей клиента.
Если после ошибки в настройках маршрутизации серверы перестали быть доступны, это не означает неисправность площадки.
Поэтому перед переносом сетевого оборудования в ЦОД особенно полезен out-of-band доступ.
У многих профессиональных коммутаторов и маршрутизаторов есть отдельный management-порт и консольный интерфейс. Нужно продумать, как администратор доберётся до них, если основная сеть перестала работать.
Размещать management исключительно внутри той же сети, которую устройство должно обслуживать, рискованно. После неудачной конфигурации можно буквально отрезать себе путь к её исправлению.
Вариантом становится отдельная management-сеть, консольный сервер или помощь инженера ЦОД через Remote Hands.
Если оборудование находится в другом городе, последний вариант особенно важен. Иногда для восстановления достаточно подключить консольный кабель, сообщить вывод администратору или заменить неисправный блок питания.
Поэтому до заключения договора стоит узнать, какие операции инженеры площадки готовы выполнять с сетевым оборудованием и как они тарифицируются.
Полезно уточнить возможность хранения запасных компонентов. Для критичного коммутатора можно заранее оставить совместимый PSU, вентилятор, трансивер или даже резервное устройство.
Это значительно ускоряет восстановление после аппаратной неисправности.
Особенно важно иметь план для оборудования, снятого производителем с поддержки. Если старый коммутатор работает исправно, это ещё не означает, что через несколько лет для него легко найдётся подходящий блок питания.
Перед colocation стоит проверить и обновления прошивки. Перенос в ЦОД удобен как точка, где можно привести конфигурацию в порядок, сохранить резервную копию настроек и задокументировать схему портов.
Но обновлять firmware непосредственно во время миграции без необходимости рискованно. Лучше не объединять в один день перевозку оборудования, полную перестройку сети и крупное программное обновление.
Если что-то пойдёт не так, определить причину будет значительно сложнее.
Отдельно нужно подписать кабели и порты. В собственной серверной администратор может помнить, что синий кабель ведёт к базе данных. Через несколько месяцев в ЦОД такая система превращается в проблему.
Понятная маркировка ускоряет Remote Hands и снижает вероятность того, что инженер отключит не тот интерфейс.
Для нескольких устройств полезно заранее подготовить схему: какой порт коммутатора подключён к какому серверу, где uplink, где management и где резервное соединение.
Это особенно важно при двух коммутаторах и резервированной сети.
При заказе размещения оборудования в ЦОД сетевые устройства лучше сразу включить в общую техническую спецификацию. Тогда оператор увидит полную картину: сколько требуется U, какая общая мощность, сколько uplink, какие интерфейсы используются и понадобятся ли дополнительные кроссировки.
Такой подход намного лучше, чем сначала заказать место только для серверов, а после установки обнаружить, что собственному коммутатору нужен ещё один U и дополнительное подключение.
В итоговом коммерческом предложении стоит отдельно увидеть стоимость места, питания, uplink, интернет-канала, cross-connect, дополнительных портов и инженерных работ.
Если оборудование размещается в арендованной части стойки, сами U могут уже входить в пакет, но сетевые соединения всё равно тарифицируются отдельно.
Для небольшого проекта собственный коммутатор не всегда снижает расходы. Иногда несколько прямых подключений от ЦОД обходятся проще и дешевле.
Экономический смысл появляется вместе с ростом инфраструктуры и необходимостью самостоятельно управлять внутренней сетью.
Поэтому главный вопрос перед покупкой нового сетевого оборудования для colocation заключается не в том, можно ли поставить его в стойку. Почти всегда можно подобрать техническое решение.
Гораздо важнее понять, какую задачу оно будет выполнять.
Если собственный коммутатор нужен только потому, что так выглядит профессиональнее, он добавляет стоимость, энергопотребление и ещё одну точку отказа. Если же через него строится приватная сеть десятка серверов, разделяются VLAN и организуется резервирование, устройство становится важной частью инфраструктуры.
То же касается маршрутизаторов и firewall. Чем больше контроля компания забирает себе, тем больше возможностей получает, но одновременно возрастает ответственность за конфигурацию и отказоустойчивость.
Правильно спроектированное размещение сетевого оборудования позволяет использовать дата-центр не просто как место для нескольких серверов, а как полноценную площадку для собственной инфраструктуры. Для этого ещё до заказа нужно определить форм-фактор устройств, питание, направление воздушного потока, количество uplink, типы интерфейсов, необходимость VLAN, management-доступа, резервирования и cross-connect.
Тогда коммерческое предложение можно оценивать не по цене одного дополнительного U, а по тому, насколько удобно и безопасно на этой площадке будет работать вся сеть компании.
