Екатеринбург может быть хорошим местом для colocation, если компания работает на Урале, обслуживает пользователей из нескольких российских регионов или просто хочет разместить собственное оборудование в профессиональном дата-центре без постоянной зависимости от Москвы. Для бизнеса из Екатеринбурга и соседних городов есть ещё одно преимущество: при необходимости до своего сервера проще добраться физически, чем до оборудования, установленного за тысячи километров.
Но близость дата-центра сама по себе ничего не гарантирует. Сервер может находиться в двадцати минутах от офиса и при этом иметь неудобные условия по мощности, слабые возможности расширения или дорогое обслуживание. Другой ЦОД расположен дальше, зато предлагает резервное питание, хорошую сетевую связность, круглосуточных инженеров и понятные условия для роста инфраструктуры.
Поэтому colocation в Екатеринбурге стоит выбирать примерно так же, как серьёзную часть собственной IT-инфраструктуры. Нужно оценивать не место для металлического корпуса, а всё окружение сервера: питание, охлаждение, сеть, физический доступ, техническую поддержку и возможность быстро решить проблему с оборудованием.
Что важно проверить перед размещением сервера в Екатеринбурге
Первый вопрос довольно приземлённый: сколько электроэнергии действительно требуется серверу. Стоимость colocation зависит не только от высоты корпуса в юнитах. Компактная машина 1U с мощным процессором или GPU способна потреблять больше, чем значительно более крупный сервер хранения.
Поэтому перед запросом коммерческого предложения желательно знать хотя бы приблизительное рабочее потребление оборудования. Мощность блока питания на наклейке для этого недостаточна. Блок на 1000 Вт не означает постоянное потребление одного киловатта, но дата-центру всё равно необходимо понимать реальную нагрузку на стойку.
Если в сервере два блока питания, стоит сразу выяснить возможность подключения к независимым линиям. Иначе аппаратное резервирование используется только частично. Два блока, получающих электричество из одной точки, защищают от неисправности отдельного БП, но общая проблема линии способна выключить оба.
Для небольшого проекта подобная схема может быть достаточной. Для коммерческого сервиса, где простой приводит к потерям, требования к резервированию разумно повысить.
Не менее важно понять, какой энергетический запас останется после установки оборудования. Сегодня сервер потребляет умеренно, а через год в него добавляют накопители, более производительный процессор или GPU. Если стойка уже находится возле своего энергетического предела, простая модернизация неожиданно превращается в переезд.
Уральское расположение имеет смысл только при хорошей сети
Для проекта с пользователями из Екатеринбурга, Челябинска, Перми, Тюмени и других регионов Урала местный ЦОД выглядит логичным выбором. Но географическая близость ещё не означает автоматически лучшую скорость.
Трафик идёт не по прямой линии между компьютером пользователя и сервером, а через сети операторов и точки обмена. Поэтому качество маршрутизации иногда важнее дополнительных сотен километров расстояния.
Перед размещением полезно запросить у дата-центра тестовый IP и проверить соединение из разных сетей. Одного ping из офиса недостаточно. Если сайт работает для широкой российской аудитории, имеет смысл посмотреть маршруты из Москвы, Санкт-Петербурга, городов Урала и других важных для проекта регионов.
Для обычного сайта различие между условными 20 и 35 миллисекундами редко будет заметно посетителю. Гораздо неприятнее нестабильный маршрут, потеря пакетов или периодические проблемы со связностью.
Следом нужно разобраться со скоростью порта и трафиком. Гигабитное подключение выглядит привлекательнее 100 Мбит/с, но обычный корпоративный сайт способен годами не приближаться даже к пределу более медленного канала.
Совсем иначе ведёт себя файловое хранилище, видеосервис или сервер резервного копирования. Там пропускная способность может непосредственно ограничивать работу проекта.
Поэтому полезно узнать не только скорость порта, но и условия использования трафика. Есть ли месячный лимит, что происходит после его превышения, можно ли увеличить полосу и сколько это будет стоить.
Если планируется несколько физических серверов, стоит заранее спросить о внутренней сети. Веб-сервер, база данных и резервное хранилище могут обмениваться большими объёмами информации, которую незачем пропускать через публичный интернет.
Для критичной инфраструктуры имеет значение резервирование сетевых подключений. Два кабеля особенно полезны тогда, когда ведут не просто в соседние порты одного коммутатора, а по действительно независимым путям.
Необязательно строить такую схему для первого небольшого сервера. Но возможность получить второй сетевой интерфейс без переезда полезно проверить заранее.
Собственный сервер когда-нибудь придётся обслуживать руками
При нормальной работе физический доступ к оборудованию почти не требуется. Linux управляется через SSH, аппаратная консоль доступна через IPMI, а мониторинг сообщает о большинстве проблем дистанционно.
Но colocation отличается от аренды готового выделенного сервера тем, что оборудование принадлежит клиенту. Если выходит из строя нестандартный компонент, ответственность за его замену в конечном счёте остаётся на владельце.
Поэтому для компании из Екатеринбурга локальная площадка удобна ещё и логистикой. При необходимости можно самостоятельно привезти новый диск, контроллер, блок питания или другое оборудование.
Но строить эксплуатацию исключительно на личных поездках администратора тоже не стоит. В хорошем ЦОД должна быть услуга Remote Hands, позволяющая выполнить простую физическую операцию без присутствия клиента.
Например, мониторинг обнаружил отказ одного диска RAID. Администратор дистанционно определил неисправный накопитель и передал точную инструкцию инженеру площадки. Тот заменил hot-swap диск, а сервер продолжил работать.
Такая схема намного удобнее, чем отправлять системного администратора через весь город ради пяти минут физической работы.
Перед заключением договора стоит узнать, какие операции инженеры выполняют круглосуточно, сколько стоят Remote Hands и какое время реакции предусмотрено. Поддержка 24/7 может означать как реально присутствующего дежурного инженера, так и круглосуточный приём обращений с выполнением части работ только позднее.
Полезна и возможность хранить небольшой ЗИП непосредственно на площадке. Запасной накопитель или блок питания занимает мало места, зато после аппаратного отказа не нужно сначала искать нужную деталь и организовывать доставку.
Когда colocation в Екатеринбурге выгоднее размещения сервера в Москве
Для бизнеса из Екатеринбурга главный аргумент в пользу местного ЦОД довольно очевиден: собственное оборудование остаётся рядом. Это упрощает первоначальную доставку, модернизацию и редкие аварийные работы.
Но выбирать Екатеринбург только ради удобной поездки тоже не стоит. Если основная аудитория проекта находится в Москве и весь бизнес технически связан с московской инфраструктурой, столичная площадка может оказаться логичнее.
Нужно смотреть на архитектуру проекта целиком.
Например, компания работает в Екатеринбурге, сотрудники находятся здесь же, большинство клиентов живёт на Урале, а сервер периодически модернизируется собственным IT-отделом. Локальный colocation выглядит очень естественно.
Другой бизнес зарегистрирован в Екатеринбурге, но почти все пользователи и партнёры находятся в Москве, там же размещены остальные серверы и облачные ресурсы. В такой ситуации географическая близость ЦОД к офису может оказаться менее важной, чем близость к остальной инфраструктуре.
Есть и третий сценарий: Екатеринбург используется как отдельная резервная площадка. Основная инфраструктура находится в другой части страны, а на Урале размещается копия критичных данных или резервный сервер. Географическое разнесение позволяет защититься не только от неисправности одного физического сервера, но и от более крупной проблемы на основной площадке.
Подобная схема уже заметно дороже обычного colocation, поэтому для небольшого сайта она чаще всего не нужна. Но для бизнеса с жёсткими требованиями к доступности географический резерв может быть вполне оправдан.
При сравнении нескольких екатеринбургских ЦОД я бы не начинала с вопроса где дешевле 1U. Сначала нужно составить одну конфигурацию: размер сервера, реальная мощность, количество подключений питания, скорость сети, IP-адреса, доступ к IPMI и необходимые инженерные услуги.
После этого одинаковое техническое задание отправляется нескольким операторам.
Так быстро выясняется, что одна и та же формулировка размещение сервера может включать разный набор услуг. У одного оператора в стоимость уже входит необходимый порт и подходящий энергетический лимит. У другого первоначальная цена ниже, но часть возможностей оплачивается отдельно.
При расчёте стоимости colocation поэтому нужно учитывать всю рабочую конфигурацию, а не только место в стойке.
Стоит заранее посмотреть и условия масштабирования. Если сегодня нужен один сервер, а через год планируется второй, удобно получить соседние юниты и объединить машины внутренней сетью. Если свободного места или мощности уже нет, расширение получится сложнее.
Для компании с планами роста полезно сразу спросить о размещении нескольких серверов, части стойки и целого шкафа. На определённом количестве оборудования индивидуальная оплата каждого отдельного юнита перестаёт быть самой удобной моделью.
Отдельный критерий — доступная мощность на стойку. Для обычных серверов это может долго не иметь значения, но инфраструктура с GPU или большим количеством дисков быстро становится энергоёмкой.
Нельзя забывать и о физической безопасности. Сервер остаётся собственностью клиента, поэтому важно понимать, кто имеет возможность попасть в машинный зал и получить доступ к оборудованию.
Пропускной режим, видеонаблюдение, охрана и ограничение доступа являются нормальными элементами профессионального дата-центра. Для небольшого сервера обычно достаточно стандартных мер площадки, а крупной инфраструктуре может потребоваться собственный закрываемый шкаф.
Пожарная безопасность и охлаждение тоже стоит оценивать на уровне здравого смысла. Клиенту не нужно становиться инженером ЦОД, но площадка должна иметь профессиональные системы обнаружения и тушения пожара, а температурный режим в машинном зале должен контролироваться постоянно.
Рекламное обозначение Tier полезно как дополнительный ориентир, но не заменяет конкретные вопросы. Намного важнее понять, что произойдёт при отказе внешнего электропитания, сетевого оператора или отдельного элемента инженерной системы.
Сам по себе высокий класс дата-центра не защищает от неисправности клиентского SSD или ошибки администратора. Ответственность всё равно разделена: ЦОД обеспечивает среду вокруг оборудования, а клиент отвечает за собственный сервер и его программную часть, если договор не предусматривает дополнительное обслуживание.
Это особенно важно при аппаратной аварии. Если у арендованного выделенного сервера ломается материнская плата, хостинг-провайдер обычно решает проблему со своим оборудованием. При colocation неисправная материнская плата принадлежит вам.
Поэтому для критичной машины стоит заранее иметь план восстановления. Иногда достаточно запасных дисков. Для более серьёзной инфраструктуры имеет смысл резервный сервер или хотя бы понятная процедура быстрой замены всей платформы.
Хорошо, если дата-центр позволяет разместить такую резервную машину на той же или другой площадке. Но считать два сервера в одном помещении полноценным географическим резервом нельзя.
Стоит учитывать и возможность подключения дополнительных сервисов. Иногда вместе с colocation удобно использовать облачные ресурсы, арендуемый сервер или отдельное хранилище того же оператора. Это позволяет не покупать собственное железо для каждой временной задачи.
Например, основной сервер принадлежит компании и размещён в стойке, а дополнительная вычислительная нагрузка периодически запускается в облаке. Если между ресурсами доступна нормальная внутренняя связность, инфраструктура получается довольно гибкой.
Но дополнительные сервисы имеют смысл только там, где они действительно решают задачу. Хороший colocation не обязан быть частью огромной сложной экосистемы.
Для одного сервера иногда важнее простые вещи: стабильное питание, хорошая сеть, быстрый доступ к инженеру и прозрачный счёт в конце месяца.
Если компания находится в Екатеринбурге, я бы также оценила реальное время дороги до нескольких подходящих площадок. Не ради ежедневных визитов, а ради понимания худшего сценария. Если внезапно понадобится лично привезти специфическую деталь, насколько это сложно сделать вечером или ночью?
При этом местоположение не должно перевешивать все остальные характеристики. ЦОД в десяти минутах от офиса с неподходящей сетью или недостаточной мощностью хуже площадки в сорока минутах, где сервер способен спокойно работать несколько лет.
В итоге выбор colocation в Екатеринбурге стоит свести к довольно простому принципу. Сначала определяется, что требуется самому серверу и проекту. Затем сравниваются несколько площадок по одинаковому техническому заданию. И только после этого имеет смысл смотреть, какая из подходящих конфигураций стоит дешевле и удобнее расположена.
Такой порядок хорошо защищает от ситуации, когда сервер уже перевезён и установлен, а затем выясняется, что второй ввод питания стоит неожиданно дорого, дополнительной мощности нет, Remote Hands работает не так, как предполагалось, или для следующей машины в стойке просто не осталось места.
Хорошая площадка для colocation обычно становится почти невидимой. Сервер стоит в Екатеринбурге, исправно получает электричество и сеть, а администратор месяцами работает с ним исключительно удалённо. Если дата-центр вспоминается только при плановой модернизации оборудования, значит инфраструктура вокруг сервера, скорее всего, организована правильно.
