LIVEHOSTING Дата-центр SRL должна доказать, что заявленная мощность дата-центра переживёт ограничения энергоснабжения и операторов связи

Резюме

• LIVEHOSTING Дата-центр SRL публично называет себя оператором дата-центра в Тимишоаре и держателем AS41635. На текущих страницах продаж предлагаются веб-хостинг, виртуальные и выделенные серверы, управление серверами и колокация 1U–3U.
• Публичная сетевая граница активна, а не просто зарегистрирована. RIPEstat наблюдал 89.38.208.0/22 от AS41635 12 июля 2026 года — префикс был виден всем 326 сообщающим IPv4-пирам в снимке статуса маршрутизации; соседними сетями наблюдались AS12302 и AS39737.
• Физические доказательства менее актуальны. Румынский отраслевой справочник 2012 года сообщал о серверном зале площадью 30 м², двух трёхфазных вводах по 50 кВт, дизельном генераторе мощностью 100 кВт и четырёх ИБП по 40 кВт. Эти цифры — полезная история, но они не устанавливают состав оборудования, нагрузку, время автономной работы или резервирование, доступные в 2026 году.
• На странице колокации перечислены два источника питания, ИБП, генератор, защита от DDoS и интернет-порт 1 Гбит/с. На ней не публикуются разделение цепей A/B, запас топлива генератора, резервирование охлаждения, вводы оптоволокна, обязательства операторов связи, результаты испытаний при обслуживании или вторая площадка восстановления.
• Степень доказательности сетевых данных — средняя. Есть убедительные доказательства действующего сервиса и маршрутизируемой операционной поверхности, но недостаточно актуальных независимых данных, чтобы считать заявленную мощность одновременно обслуживаемой или доказуемо восстанавливаемой после отказа площадки или оператора связи.

Заявление достаточно конкретно, чтобы его проверить

LIVEHOSTING Дата-центр SRL не прячется за расплывчатым облачным ярлыком. Натекущей странице контактовназвано румынское юридическое лицо, указаны регистрационный номер J35/815/2010 и налоговый код RO26963713, идентификатор AS41635, а также сказано, что компания управляет собственным дата-центром в Тимишоаре. Впредложении колокацииоборудование клиента размещается в этой площадке и перечислены защита ИБП и генератором. Это конкретнее, чем реселлер, который никогда не называет площадку или сеть.

Конкретность создаёт полезное бремя доказывания. Если провайдер заявляет, что управляет инфраструктурой уровня здания, на которой работают нагрузки клиентов, значимой единицей является не виртуальный сервер с прайс-страницы, а вся цепочка: от ввода электросети до ИБП, генератора, распределения питания, охлаждения, стойки, коммутатора, граничного маршрутизатора, канала оператора связи и инженера. Каждое звено может снизить мощность, которую клиенты реально используют при сбое.

Публичные ресурсы компании охватывают несколько типов зависимостей. Наглавной страницепродаются хостинг Windows и Linux, виртуальные серверы, выделенные серверы, колокация и управление серверами. Клиенты общего хостинга зависят от платформы, которой управляет провайдер. Клиенты виртуальных серверов зависят от архитектуры хоста и хранилища, которую они не могут проверить напрямую. Клиенты выделенных серверов зависят от оборудования, коммутации и удалённого доступа. Клиенты колокации владеют большей частью сервера, но всё равно зависят от площадки и сети. Поэтому отказ на общем уровне питания или оператора связи может затронуть продукты, которые на уровне счетов выглядят независимыми.

Ключевое различие — между доказательством работы и доказательством устойчивости. AS41635 и текущий каталог продуктов убедительно показывают, что LiveHosting работает. Но сами по себе они не показывают, какая часть нагрузки переживёт потерю одного ввода электросети, одной линии ИБП, одного охлаждающего агрегата, одного граничного маршрутизатора или одного ввода оптоволокна. Второй вопрос определяет, будет ли небольшой дата-центр в Тимишоаре просто доступен в обычный день или восстановим в трудный.

За небольшим публичным следом стоит действующий сервис

Публичные данные подтверждают реально действующий бизнес. LiveHosting публикует цены на виртуальные серверы, выделенные серверы и колокацию, поддерживает страницы учётных записей и заказов клиентов и указывает контакт по злоупотреблениям в сети. Настранице SSD-виртуальных серверовперечислены шесть конфигураций, настранице NVMe— ещё шесть. На страницах выделенных серверов рекламируются системыHP ProLiant DL360 G7иG8с двумя горячезаменяемыми блоками питания и несколькими сетевыми интерфейсами.

Эти страницы создают витрину продаж, а не инвентаризацию. На них не сказано, сколько физических хостов установлено, сколько доступно к немедленной поставке, какая доля CPU и памяти зарезервирована и хранятся ли на площадке запасные системы и диски. Конфигурация может оставаться доступной для заказа, пока последний подходящий корпус используется, запасной экземпляр ремонтируется или на стойку нельзя выделить новое питание. Покупателям следует рассматривать перечисленные конфигурации как классы услуг, а не как проверенную установленную мощность.

Публичный корпоративный след тоже выглядит небольшим.Профиль компании на Termene.ro, агрегаторе данных о румынских компаниях, сообщает о выручке 736 213 RON за 2024 год, чистой прибыли 286 410 RON и средней численности в один сотрудник. LinkedIn, напротив, относит компанию к диапазону двух–десяти сотрудников и говорит, что с 2006 года она обслужила более 4 000 клиентов. Ни один источник не доказывает текущее число инженеров, доступных при ночном инциденте. Подрядчики, аффилированный персонал, техники операторов связи и персонал здания могут не попадать ни в статистическую среднюю, ни в диапазон соцсети.

Эта неопределённость важна, но из неё не следует, что небольшая команда некомпетентна. Небольшие операторы могут быть технически дисциплинированными и отзывчивыми. Они также могут сильно зависеть от знаний одного администратора и от поставщиков, чьё время реакции не покрывается договором клиента. Значимые данные — это актуальный график дежурств, порядок эскалации, список доступа и условия технической поддержки поставщиков. Публичные сигналы о численности просто делают эти вопросы важнее.

Тимишоара — место оказания услуг, но не полная карта площадки

LiveHosting неоднократно заявляет, что управляет собственным дата-центром в Тимишоаре. В юридических контактных данных зарегистрированный офис указан в Думбравице, сразу за городом, а страница колокации сообщает, что местом оказания услуг является «LiveHosting Дата-центр Timisoara». Это совместимые заявления, но они не доказывают, что зарегистрированный офис, серверный зал и каждый рекламируемый сервер находятся по одному адресу.

Запись о площадке в Дата-центр Mapописывает один объект LiveHosting в пределах двух километров от центра Тимишоары и сообщает, что точный адрес не публикуется. На странице экосистемы для этой площадки нет данных о сети или поставщиках услуг. Дата-центр Map — коммерческий каталог, а не инженерный аудит, но отсутствие публичного точного адреса подчёркивает важную границу: город подтверждён; идентичность здания и структура собственности — нет.

«Собственный дата-центр» может описывать разные схемы. Компания может владеть зданием и всем инженерным оборудованием. Может владеть ИТ-залом внутри арендованного здания. Может эксплуатировать стойки и коммутацию, пока арендодатель управляет вводом электросети, пожарными системами или охлаждением. Может заказывать обслуживание генератора или удалённую охрану по договору. Ни одна из этих моделей не является заведомо неполноценной. Они создают разные права на восстановление и разных поставщиков с разными сроками реакции.

Клиенту, оценивающему колокацию, стоит запросить матрицу ответственности. В ней должно быть указано, кто владеет зданием, кто эксплуатирует каждую ступень электроснабжения, кто обслуживает охлаждение, кто контролирует физический доступ, у кого заключён договор на топливо для генератора, кто владеет внешним оптоволокном и кто может санкционировать аварийные работы. Следует также различать юридический зарегистрированный офис, адрес площадки и любую резервную локацию. Без такой карты фраза «собственный дата-центр» полезна, но неполна.

География услуги яснее всего на сетевом уровне. AS41635 зарегистрирована в Румынии, продукт продаётся на румынском языке, а трассировка IPinfo в июне 2026 года достигла адреса в анонсированном блоке через Prime Telecom до пункта назначения с меткой Тимишоары. Это подтверждает оказание услуг в Румынии, но не доказывает, что все резервные копии, сервисы управления, точки мониторинга или копии данных клиентов остаются в Румынии.

Подробный снимок 2012 года не может подтвердить состояние инфраструктуры 2026 года

Самое конкретное публичное описание физической инфраструктуры содержится в справочнике Отрасли и рынки WatchДата-центр 2012. В нём сообщалось о серверном зале площадью 30 м², двух трёхфазных трансформаторных вводах по 50 кВт — один от Electrica, другой от CET, дизельном генераторе мощностью 100 кВт и четырёх ИБП по 40 кВт. Также были перечислены канал связи 1 Гбит/с, серверы Dell, хранилища и сетевое оборудование, мониторинг через PRTG и DRAC, сертификаты ISO 9001 и ISO 27001.

Это ценное историческое свидетельство, поскольку оно даёт данные о масштабе и топологии, которых нет на текущем сайте. Но ему четырнадцать лет. Оборудование стареет, батареи заменяются, охлаждение расширяется, распределение перемонтируется, договоры с операторами меняются, площадки переезжают. Справочник мог точно зафиксировать описание провайдера на тот момент, но почти ничего не говорит об инфраструктуре, которая обслуживает клиентов сейчас.

Цифры тоже требуют интерпретации. Два номинальных ввода по 50 кВт не обязательно равны 100 кВт устойчивой ИТ-нагрузки. Если каждый ввод должен выдерживать весь зал, устойчивая мощность электросети может быть ближе к полезной мощности меньшего пути с учётом потерь и не-ИТ нагрузок. Генератор на 100 кВт не устанавливает, какую ИТ-нагрузку он сможет поддерживать с учётом охлаждения, потерь в ИБП, освещения, насосов и пусковых токов. Четыре ИБП по 40 кВт не показывают, были ли они сконфигурированы как N, N+1, 2N или как отдельные системы для разных нагрузок.

Поэтому текущий сайт следует читать вместе со справочником 2012 года, а не сливать с ним. Текущие страницы доказывают, что колокация и серверные продукты по-прежнему продаются. Старый справочник показывает, что компания когда-то раскрывала. Ни один из рассмотренных публичных документов не связывает исторические номиналы с актуальной однолинейной схемой электроснабжения, актом пусконаладки, испытанием под нагрузкой, отчётом о состоянии батарей или тестом запаса топлива. Пока таких документов нет, исторические цифры — это основа для вопросов, а не действующий сертификат мощности.

Два блока питания сервера не доказывают два независимых пути питания

В текущей таблице колокации для планов 1U, 2U и 3U в графе «блоки питания» указано «2». На страницах выделенных серверов аналогично рекламируются два горячезаменяемых блока питания по 750 Вт. Это хорошая конструкция на уровне компонентов: сервер продолжит работу после отказа одного блока, если второй блок и его ввод останутся исправны. Но устойчивость зависит от того, куда ведут два кабеля.

Если оба блока питания сервера подключены к одному стоечному PDU, этот PDU остаётся единой точкой отказа. Если два PDU подключены к одному выходу ИБП или одному распределительному щиту, вышестоящий путь питания остаётся общим. Если раздельные системы ИБП зависят от одного переключателя ввода резерва или одного генератора, отказ там может убрать оба видимых ввода. Даже физически раздельные подключения к сети могут делить подстанцию, трассу кабеля или схему защиты вне здания.

Именно поэтомуобъяснение Uptime Institute о топологии Tierразличает резервирование компонентов, одновременную обслуживаемость и отказоустойчивость. Второй компонент — это не то же самое, что второй путь доставки. Материал не присваивает LiveHosting никакой уровень Tier; рассмотренная страница компании его не заявляет, а справочник 2012 года прямо не давал классификации Uptime. Эта модель полезна только для того, чтобы прояснить, какие доказательства поддержали бы более сильные формулировки.

Для каждой стойки, продаваемой с двойным питанием, LiveHosting должна уметь показать путь A и B от электросети или генератора через распределительные устройства, ИБП, распределение и PDU. Нужно указывать, какие устройства остаются с одним кабелем питания и используются ли переключатели ввода резерва. Стоит публиковать максимальную нагрузку стойки, номинал автоматов, допустимую установившуюся нагрузку и способ учёта. На странице колокации сказано, что потребление электроэнергии включено, но лимит мощности не указан. Это упущение затрудняет перевод места 1U, 2U или 3U в безопасное и коммерчески обеспеченное обязательство по мощности.

Самый важный тест — не только схема. Это управляемое переключение при реалистичной нагрузке, пока оборудование клиента остаётся в работе, с последующим подтверждением, что батареи, генератор, охлаждение и сетевое оборудование вели себя как задумано.

Наличие генератора — это не то же самое, что запас его автономной работы

На текущей странице продаж указан генератор, а справочник 2012 года сообщал о дизельном агрегате на 100 кВт. Генератор может перекрыть длительное отключение электросети, но только если работает вся система обеспечения: автоматическое обнаружение, стартовые батареи, переключающее оборудование, топливо, охлаждение, выхлоп, обслуживание, приём нагрузки и доступ для дозаправки. Слово «генератор» не раскрывает ни одно из этих условий.

Время автономной работы — первая недостающая цифра. Бака может хватить на часы при частичной нагрузке и на значительно меньшее время при расчётной. Расход топлива меняется вместе с потреблением электроэнергии, а потребление площадки включает не только серверы. Охлаждение должно продолжать работать при потере сети; иначе генератор будет держать ИТ-оборудование под напряжением, пока температура в зале не поднимется до принудительного отключения. Поэтому публично заявленное время автономии должно указывать поддерживаемую критическую нагрузку, минимальный запас топлива на площадке, договор на дозаправку и допущения об охлаждении.

Вруководстве Uptime Institute по системам топливаописывается ожидание минимум двенадцатичасового запаса топлива для топологий Tier при заявленной нагрузке N площадки. Это ориентир, а не доказательство того, что LiveHosting ему соответствует или обязана принять именно такую схему. Небольшой провайдер может выбрать другой целевой уровень риска. Важно, чтобы клиенты знали этот целевой уровень и могли сравнить его со своими потребностями в восстановлении.

Испытания важны не меньше размера бака. Ежемесячный запуск без нагрузки не доказывает, что генератор и система переключения выдержат зал в жаркий день. Содержательный протокол включал бы испытания переключения под нагрузкой, длительность, процент нагрузки, качество топлива, аварийные сигналы, неудачные запуски и корректирующие действия. Он также показал бы, остаются ли доступными оба текущих канала операторов связи и внешний мониторинг при отключении электросети.

Последствия для клиента прямы. Короткое отключение могут поглотить батареи ИБП. Более длительная авария становится событием генератора и топлива. Если генератор откажет или не сможет обеспечить охлаждение, все продукты в зале могут упереться в один и тот же срок отключения, независимо от того, сколько виртуальных машин, RAID-массивов или блоков питания серверов находится выше.

Охлаждение определяет, сколько электрической мощности реально доступно

Рассмотренные публичные материалы не дают актуальной схемы охлаждения, установленной мощности охлаждения, уровня резервирования, планировки с каналами холодного и горячего воздуха или рабочего диапазона температуры. Из-за этого читатель не может пересчитать исторические номиналы электроэнергии в полезную ИТ-мощность. Почти каждый ватт, потребляемый ИТ-оборудованием, превращается в тепло, которое нужно отводить, и зал может упереться в ограничение по охлаждению раньше, чем достигнет паспортного электрического предела.

Цифра 30 м² из 2012 года также ничего не говорит о текущей плотности стоек. Небольшой зал со слабо нагруженными стойками может быть стабильным. Тот же зал, заполненный двухпроцессорными серверами, плотными хранилищами или высокоскоростной коммутацией, может давать горячие зоны, даже когда суммарная мощность здания остаётся в пределах номинала. В каталоге выделенных серверов есть системы с несколькими дисками и двумя процессорами, а клиентское оборудование колокации менее предсказуемо. Выделение мощности должно учитывать и среднее тепловыделение, и локальную концентрацию.

Резервирование охлаждения состоит из нескольких уровней: охлаждающий агрегат, компрессор или источник холодной воды, насосы и вентиляторы, система управления, электропитание и путь отвода тепла. «Охлаждение N+1» всё равно может скрывать общие трубопроводы, общую систему управления или общее электропитание. Обслуживание может рассказать больше, чем отказ. Если охлаждающий агрегат нельзя изолировать и обслужить в жаркий день, не снизив зал ниже заявленной нагрузки, установленная мощность превышает одновременно используемую.

Покупателю стоит запросить диапазоны температуры и влажности на входах серверов, расположение датчиков, пороги аварийных сигналов, журналы трендов, запас по жаре и результаты теста потери охлаждающего агрегата. В ответе должны быть объяснены политика автоматического отключения и уведомление клиента при росте температуры. Также должно быть указано, включает ли мощность генератора всё охлаждение, необходимое для заявленной ИТ-нагрузки.

Отсюда следуют вопросы пожарной безопасности и воды. Конденсат, протечки кровли или труб могут быстро сказаться на компактном зале. Системы обнаружения и тушения пожара должны быть совместимы с помещениями, где находятся люди, и с работающим электрооборудованием. В публичных материалах упоминаются исторические меры физической безопасности и мониторинг, но нет актуальных данных о противопожарных отсеках, датчиках протечек, системах тушения или зонах затопления. Клиентам не следует выводить эти средства защиты из одного только ярлыка «дата-центр».

Установленная, продаваемая и восстанавливаемая мощность — это разные цифры

Провайдер может честно иметь установленное оборудование, но располагать меньшей мощностью для новых клиентов и ещё меньшей — во время сбоя. Установленная мощность — это сумма паспортных данных и сконфигурированных ресурсов. Продаваемая мощность — то, что разрешают коммерческие и инженерные правила после резервирования и переподписки. Восстанавливаемая мощность — то, что остаётся или может быть восстановлено вовремя после отказа определённого компонента.

На публичных страницах LiveHosting рекламируются процессор сервера, память, SSD- или NVMe-хранилище и «безлимитный» трафик. Эти характеристики описывают право на услугу или конфигурацию продукта. Они не показывают заполненность хостов, репликацию хранилищ, перегрузку аплинков или пропускную способность резервного копирования. «Безлимитный» трафик особенно легко прочитать неверно: он может означать отсутствие поминутной тарификации по объёму, тогда как каждый пакет всё равно делит конечный порт, границу сети и обязательства по транзиту.

Место под колокацию столь же неполно без запаса по мощности и сети. Три клиента 1U могут потреблять меньше энергии, чем один клиент 3U, или значительно больше — в зависимости от оборудования. Порт 1 Гбит/с — это скорость интерфейса, а не гарантированная пропускная способность интернета при атаке или после отказа одного оператора. Паспортная мощность генератора — не обязательство по мощности перед клиентом. Номинал ИБП — не гарантия времени автономной работы.

Операционная метрика, которая действительно важна, — это бюджет в аварийном состоянии. Сколько киловатт останется, если один путь питания будет изолирован? Какая температура в зале сохранится после потери одного охлаждающего агрегата? Какая пропускная способность интернета останется, если Prime Telecom или Vodafone станет недоступен? Сколько виртуальных серверов можно одновременно перезапустить из резервных копий? Сколько инженеров смогут одновременно обрабатывать инциденты с оборудованием, сетью и клиентами?

Эти цифры следует привязать к классам клиентов. Общий хостинг может допускать другое время восстановления, чем сайт госсектора, транзакционное приложение, почтовый сервер или корпоративная система в колокации. Небольшой площадке не нужна гипермасштабная мощность, чтобы быть полезной. Ей нужны обязательства, соответствующие реальному резервированию, и чёткий отказ продавать сверх аварийного конверта.

AS41635 активна и видна по всему миру

Сетевые доказательства — самая сильная часть публичного материала.RIPE RDAPуказывает AS41635 как активную и называет её LIVEHOSTING-AS.Обзор AS в RIPEstatидентифицирует держателя как LIVEHOSTING Дата-центр SRL и отмечает, что номер AS анонсируется. Это совпадает с собственной страницей контактов компании.

12 июля 2026 годастатус маршрутизации в RIPEstatпоказал один анонсированный IPv4-префикс, содержащий 1 024 адреса, и ни одного анонсированного IPv6-префикса. IPv4-маршрут был виден всем 326 сообщающим IPv4-пирам в этом снимке.Представление анонсированных префиксов в RIPEstatопределило 89.38.208.0/22 как текущий анонс. История маршрутизации прослеживает адресное пространство LiveHosting до 2006 года, хотя с течением времени агрегат менялся с /21 на текущий /22.

Это содержательное доказательство работы. Широко видимый маршрут, поддерживаемый годами, несовместим с чисто декоративной регистрацией ASN. В префиксе размещены собственный сайт компании и публичные серверные имена; его также идентифицируют независимые агрегаторы.BGP Toolkit компании Hurricane Electricсообщил об одном IPv4-префиксе, 1 024 исходных IPv4-адресах, двух наблюдаемых IPv4-пирах и отсутствии IPv6-анонса.IPinfoклассифицирует автономную систему как хостинговую и показывает путь июня 2026 года, достигающий блока через AS39737.

Маршрут также валиден по RPKI.Проверка в RIPEstatнашла действующую авторизацию для AS41635 на анонсирование 89.38.208.0/22 с максимальной длиной /22. Какобъясняет RIPE NCC, проверка происхождения отвечает на вопрос, авторизовал ли законный держатель ресурса данную пару «префикс — происхождение». Она не проверяет остальную часть пути AS и не доказывает физическую устойчивость.

Вывод должен быть узким: у LiveHosting есть актуальное, валидное и хорошо видимое IPv4-происхождение. Это сильнее маркетинговой карты. Но это по-прежнему не показывает, продублированы ли маршрутизаторы, входят ли операторы связи через отдельные канализации и сможет ли выживший путь выдержать клиентскую нагрузку после отказа.

Для двух видимых путей операторов связи всё ещё нужны физические доказательства

Представление соседей ASN в RIPEstat12 июля 2026 года наблюдало две соседние сети: AS12302 (Vodafone Romania) и AS39737 (Prime Telecom). Снимок состояния BGP показал, что подавляющее большинство выбранных путей идёт через Prime Telecom и меньшая часть — через Vodafone. Hurricane Electric независимо перечислил тех же двух пиров.

Два наблюдаемых соседства лучше одного, потому что дают потенциальную альтернативу маршрутов. Но их нельзя называть двумя подтверждёнными независимыми операторами без договорных и площадочных доказательств. Коллектор маршрутов наблюдает пути AS, а не владение оптоволокном, вводы в здание, кросс-соединения или оплаченную ёмкость. Один оператор может перепродавать услуги другого. Две цепи могут делить городскую канализацию, колодец, пересечение улицы, патч-панель или одно и то же внешнее оборудование с питанием.

Объект реестра RIPE добавляет ещё одну причину для осторожности. Его импортная политика, последний раз изменённая в 2021 году, называет AS6830 и AS34279, тогда как текущие коллекторы видят AS12302 и AS39737. Это различие может просто отражать устаревшую политику реестра после обычных смен операторов. Оно демонстрирует, почему запись в реестре не должна заменять текущие наблюдения или актуальный перечень операторов связи.

Мощность после отказа — следующий вопрос. Если основной путь несёт большую часть трафика, у второго должно быть достаточно гарантированной и пиковой ёмкости, чтобы его поглотить. BGP может успешно перенастроиться, пока приложения становятся непригодными из-за перегрузки оставшейся цепи. Защита от DDoS добавляет ещё одну зависимость: провайдер должен объяснить, где происходит фильтрация, поддерживают ли её оба апстрима, как переводятся маршруты и снижает ли событие защиты «чистую» ёмкость.

Требуемые доказательства практичны. LiveHosting должна назвать двух контрактных провайдеров, размеры портов и гарантированной ёмкости, физические точки разграничения, пути ввода, граничные маршрутизаторы и домены питания. Стоит показать недавний тест, в котором каждый апстрим отключался отдельно при пиковой нагрузке, зафиксировать сходимость и потери пакетов и подтвердить, что мониторинг и каналы связи с клиентами оставались доступны.

Отсутствие профиля в PeeringDB сужает то, что можно проверить публично

Запрос кAPI PeeringDBво время этой проверки не вернул сетевого субъекта для AS41635. Это не доказательство неисправности сети. Участие в PeeringDB добровольно, и небольшая хостинговая сеть может покупать транзит, не ведя публичный профиль межсоединений. Но отсутствие профиля снижает публичную видимость площадок, точек обмена, уровней трафика, политики пиринга и сетевых контактов.

Текущая схема выглядит транзитной, а не ориентированной на точки обмена. Публичные коллекторы показывают две соседние сети, но ни одна публичная запись PeeringDB не идентифицирует интернет-обмен или подключение к площадке. Поэтому клиентам не стоит предполагать, что у сети есть прямой пиринг, разнообразные пути через точки обмена или нейтральная комната встреч операторов. Эти элементы могут существовать; рассмотренные публичные данные их не устанавливают.

Это важно для изоляции сбоев. Если все внешние пути зависят от небольшого набора транзитных точек сдачи в одном здании, локальная точка встречи операторов может стать общей точкой отказа, даже когда глобальная таблица маршрутов показывает два апстрим-ASN. Если одна цепь заканчивается за пределами площадки и доходит до серверной по общему местному участку, логическое разнообразие может исчезнуть на последнем километре.

Провайдер может снять значительную часть этой неопределённости, не раскрывая чувствительных деталей. Можно опубликовать нейтральную схему сети без деталей площадки: отдельные вводы, отдельные граничные устройства, операторов связи, ёмкости портов и политику переключения. Можно поддерживать актуальный профиль в PeeringDB, если это уместно. Можно предоставить looking glass или внешний сервис статуса. Ни один из этих шагов не доказывает каждую канализацию, но вместе они делают операционную модель сети более проверяемой.

Отсутствие IPv6-анонса заслуживает прямого ответа

На странице колокации LiveHosting сказано, что в каждый пакет включена IPv6-подсеть /56. Однако RIPEstat и Hurricane Electric в снимках июля 2026 года показали ноль IPv6-префиксов, анонсированных AS41635. Французский регулятор связи ARCEP также указал AS41635 с нулевым присутствием IPv6 в замерах хостинг-провайдеров за 2025 год. Эти наблюдения не доказывают, что клиенты не получают услугу IPv6.

Рекламируемая /56 может происходить из адресного пространства вышестоящего провайдера и маршрутизироваться к LiveHosting без анонсирования IPv6-префикса от AS41635. Она может предоставляться только по запросу. Может быть настроена внутри площадки, но не видна в выборочных публичных данных. У каждого объяснения разные последствия для устойчивости.

IPv6, назначенный провайдером, может работать хорошо, но переключение при отказе может зависеть от назначившего апстрима. Если /56 принадлежит одному оператору и он выходит из строя, LiveHosting может не суметь анонсировать ту же клиентскую подсеть через другой путь. Перенумерация серверного парка во время инцидента — это не то же самое, что переключение BGP. DNS, правила межсетевого экрана, списки доступа и клиентское ПО могут сохранять старые адреса.

Покупателю стоит спросить, в каком агрегате находится /56, какой номер AS её анонсирует, достижима ли она через оба видимых апстрима и покрывает ли авторизация происхождения маршрута планируемое происхождение. Также стоит спросить, одинаково ли порт 1 Гбит/с и защита от DDoS применяются к IPv4 и IPv6. Двухстековый сервис настолько же устойчив, насколько устойчив менее проверенный стек, когда приложения и DNS публикуют оба протокола.

Этот пробел важен, потому что IPv6 — не декоративная функция. Страница колокации представляет его как включённую ёмкость. Публичные данные о маршрутах делают операционную поверхность IPv4 ясной; аналогичные данные об IPv6 превратили бы /56 из строчки в прайсе в проверяемый сетевой сервис.

Обязательство о качестве уже, чем гарантия площадки

Обязательство о качествеLiveHosting распространяется на пакеты веб-хостинга Windows или Linux Standard, Business и Reseller. В нём аптайм определяется как месячная доля времени, в течение которой сайт клиента доступен по HTTP из нейтральной точки. На странице сказано, что LiveHosting использует системы PRTG внутри своего дата-центра, а также в других румынских и зарубежных дата-центрах для измерения доступности.

Шкала компенсаций возвращает 50 % при аптайме от 98 % до 99,5 %, 75 % — от 95 % до 97,9 % и 100 % при 94,9 % и ниже. Сервисный кредит коммерчески полезен, но это не компенсация за потерянные продажи, данные или репутацию. Важнее, что заявленный объём автоматически не покрывает виртуальные серверы, выделенные серверы или колокацию. Покупателям этих категорий нужны собственные условия обслуживания.

Исключения широки. На странице исключаются, среди прочего, перерывы связи, пожар, наводнение, стихийные бедствия, вирусы, атакующие, стороннее ПО, плановое или критическое обслуживание, обновления серверов, DNS вне контроля LiveHosting и несколько протоколов доступа. Некоторые исключения описывают именно те пути отказа, которые клиенту дата-центра важнее всего понимать. Исключение их из компенсаций не делает их маловероятными; оно переносит их экономическую стоимость на клиента.

Определение измерения также сосредоточено на доступности HTTP. Сайт может отвечать, пока деградированы почта, подключения к базе данных, хранилище, панели управления, VPN-доступ или один путь оператора. И наоборот, сбой приложения может положить HTTP, пока питание площадки и сеть здоровы. Клиентам нужны измерения на уровне компонентов и журнал инцидентов, разделяющий причины: площадка, сеть, вычисления, хранилище, приложение.

Более сильный пакет гарантий публиковал бы исторические показатели услуги по продуктам, минуты обслуживания, причины инцидентов и время восстановления. В нём было бы указано, какие точки мониторинга независимы от AS41635 и остаётся ли доступным канал статуса при полном отказе площадки или маршрута.

Время ответа — это не время восстановления

На странице качества обещано максимальное время ответа технической поддержки 24 часа в рабочие дни с понедельника по пятницу с 10:00 до 18:00. На текущей странице контактов техподдержка указана с понедельника по пятницу с 10:00 до 17:00. Эти страницы могут описывать разные каналы или просто рассинхронизированы. В любом случае ни одно из заявлений не является обещанием восстановить сервис в течение 24 часов.

Страница управления серверамидобавляет более детальное коммерческое различие. Базовое управление включает два часа в месяц и доступность в будние дни. Премиум включает четыре часа в месяц и указывает доступность 24 часа в сутки с понедельника по воскресенье. В публичномдоговоре на оказание услугсказано, что работы по управлению ограничены часами купленной подписки, дополнительные работы оплачиваются отдельно, а доступность или производительность приложений не гарантируется услугой управления.

Это оставляет несколько вопросов клиентам выделенных серверов и колокации без управления. Круглосуточна ли аварийная реакция площадки, даже когда управление серверами не входит в услугу? Кто принимает сигнал тревоги по питанию, охлаждению или сети в 03:00? Доступны ли «удалённые руки» в любое время и какой целевой срок прибытия? На странице колокации тариф «удалённых рук» указан как 25 евро в час, но круглосуточное обязательство реакции не опубликовано.

Это различие критично в небольшой операции. Обнаружение может быть автоматическим, но диагностика и авторизация могут зависеть от человека. Оператор связи может требовать назначенного контакта клиента. Здание может ограничивать доступ в нерабочее время. У отказавшего сервера может быть двойное питание, но всё равно понадобится замена локального диска или кабеля. Каждая передача добавляет время до начала восстановления.

Клиентам стоит запросить четыре отдельных интервала: от сигнала до подтверждения, от подтверждения до квалифицированной диагностики, от диагностики до вмешательства на площадке и от вмешательства до восстановления. Стоит спросить, кто отвечает за каждый интервал и что происходит при двух одновременных инцидентах. Номер телефона и обещание тикета — полезные точки входа; но это не план восстановления.

Обслуживание может вскрыть больше рисков, чем внезапный отказ

Резервирование часто выглядит сильнее всего, когда всё здорово, и слабее всего, когда один компонент намеренно выведен на обслуживание. Батареи ИБП нужно заменять, генераторы — испытывать под нагрузкой, охлаждающее оборудование — чистить, коммутаторы — модернизировать, операторам связи — нужны окна обслуживания. В эти периоды оставшийся путь может нести полную нагрузку без резерва.

Обязательство о качестве исключает из компенсаций плановое обслуживание, критические работы и обновления серверов. Это обычно для хостинговых договоров, но практический риск зависит от того, как спроектировано обслуживание. Клиенту нужно знать, может ли площадка обслуживать каждый критический компонент без отключения ИТ-нагрузки, могут ли одновременно работать несколько подрядчиков и как выполняется откат.

Для питания доказательства обслуживания должны включать пути байпаса и процедуры, которые не ставят весь зал на «сырую» сеть. Для охлаждения следует указать максимальную безопасную нагрузку при изолированном одном агрегате. Для сетевых работ нужно показать, что маршруты клиентов остаются стабильными через другой маршрутизатор и оператора. Для хранилищ и виртуализации следует количественно определить, какой объём нагрузки можно перенести до обслуживания и сколько времени занимает перенос.

Концентрация изменений — ещё одна проблема. Небольшой провайдер может разумно запланировать несколько задач в одно окно, чтобы снизить количество прерываний, но связывание изменений питания, сети и хостов лишает независимых вариантов восстановления. Клиентам стоит спросить, учитывают ли согласования изменений общие зависимости и остаётся ли внешний канал связи вне затрагиваемых систем.

Доказательством, которое закрыло бы вопрос, служит обычный операционный материал: обезличенный годовой календарь обслуживания, уведомления о недавних окнах, отчёты после обслуживания, действия по неудавшимся тестам и видимое клиентам влияние. Это убедительнее общего целевого аптайма, потому что показывает, как оператор управляет периодами, когда резервирование намеренно снижено.

Пожар, наводнение и потеря электроснабжения бьют по клиентским данным

В обязательстве о качестве пожар и наводнение прямо упомянуты среди исключений форс-мажора. Это договорное распределение ответственности, а не доказательство того, что площадка подвержена риску или не защищена. Рассмотренные публичные страницы не указывают текущую систему обнаружения и тушения пожара, класс огнестойкости отсеков, датчики протечек, оценку риска наводнения или удалённость от источников воды и топлива.

Эти вопросы важнее, когда на одной площадке умещается много сервисных уровней. Общий хостинг, VPS, выделенные серверы, колокация, DNS, почта и клиентские порталы могут зависеть от одного зала. Если основные данные, резервные копии и системы управления находятся в одной площадке, событие здания может уничтожить и производственный сервис, и средства его восстановления.

Публичный договор на оказание услуг возлагает значительную ответственность на клиентов и ограничивает гарантии. Он также допускает приостановку или удаление услуги за неоплату и оставляет за собой широкие права изменять или прерывать услуги. Эти условия делают независимые резервные копии и проверенные процедуры выгрузки коммерчески важными даже при отсутствии физического инцидента.

Клиенту стоит определить, где находится каждая копия, кто контролирует её учётные данные, как часто она тестируется и как работает восстановление, если собственный портал учётной записи или сеть LiveHosting недоступны. Резервная копия на другом сервере в том же зале защищает от некоторых отказов оборудования, но не от событий уровня зала: питание, охлаждение, пожар или наводнение. Копия в другом здании, но управляемая через ту же недоступную систему идентификации, также может оказаться непригодной.

Для клиентов колокации вопрос доходит до восстановления оборудования. Кто может войти после инцидента? Застраховано ли оборудование клиента провайдером, оператором здания или самим клиентом? Может ли клиент забрать оборудование при длительном отключении электроснабжения или ограничении доступа? Ответы могут быть в индивидуальных договорах, но их нет на публичной странице тарифов.

Отказ влияет на разных клиентов по-разному

Клиенты общего хостинга, скорее всего, почувствуют общий отказ платформы в первую очередь как недоступные сайты, почту или панели управления. У них может быть мало видимости того, какой физический сервер, коммутатор или система хранения отказали. Реселлеры могут усилить последствия, потому что один аккаунт может представлять множество нижестоящих сайтов и обязательств по поддержке.

Клиенты виртуальных серверов больше контролируют операционные системы, но остаются зависимы от ёмкости гипервизора, хранилища и локальной сети провайдера. Отказ хоста может быть преодолён, если нагрузки можно перезапустить в другом месте, но публичная страница продукта не обещает живую миграцию, реплицируемое хранилище или кластер восстановления. Наличие SSD или NVMe ничего не говорит о количестве и расположении копий.

Клиенты выделенных серверов избегают части рисков общего вычисления. Но они всё равно зависят от стойки, обоих путей питания, коммутации, транзита операторов и «удалённых рук». Двойные блоки питания и RAID поглощают отдельные отказы компонентов, но не переживут отключение уровня зала или отказ общей сетевой границы. В публичных списках выделенных серверов также показаны более старые поколения G7 и G8; это может быть экономичное предложение, но покупателям стоит спросить о доступности запасных систем и комплектующих.

Клиенты колокации владеют оборудованием и могут анонсировать собственное адресное пространство: страница продукта разрешает анонсы BGP. Тем не менее их зависимость от LiveHosting физическая. Им нужны доступ, питание, охлаждение, кросс-соединения, маршрутизация и помощь в ремонте. Отказ площадки может остановить оборудование, которое во всём остальном полностью управляется клиентом.

Пользователи госсектора, здравоохранения, финансов или промышленности могут также нести обязательства сверх аптайма. Могут иметь значение местоположение, уведомление об инцидентах, хранение доказательств и непрерывность поставщика. В материале не назван ни один такой клиент LiveHosting. Здесь подчёркивается, почему одно и то же заявление о площадке может иметь очень разные последствия в зависимости от размещённой нагрузки.

Поэтому провайдеру следует избегать одного универсального заявления об устойчивости. Нужно раскрывать, какие средства защиты относятся к каждой услуге, что должен обеспечить клиент и какие общие зависимости пересекают все продуктовые линейки.

Содержательная демонстрация переключения должна устранять реальные зависимости

Лучший способ установить текущую устойчивость — испытывать определённые отказы, а не накапливать ярлыки. Для LiveHosting пять упражнений ответили бы на большинство открытых вопросов.

Первое: отключить обычное питание от электросети при репрезентативной производственной нагрузке. Зафиксировать переключение ИБП, запуск генератора, непрерывность охлаждения, расход топлива, сигналы тревоги и влияние на клиентов. Продержаться достаточно долго, чтобы продемонстрировать заявленный целевой срок автономии, затем вернуть сеть без сброса нагрузки.

Второе: поочерёдно изолировать каждый путь распределения питания и секцию ИБП. Подтвердить, что устройства клиентов с двумя кабелями питания остаются в работе, и выявить оборудование с одним кабелем, которому требуется переключающее устройство. Успешный тест генератора не заменяет этот тест внутреннего распределения.

Третье: отключить один охлаждающий агрегат или один путь охлаждения в сложный по температуре период. Отслеживать температуру на входах серверов и подтвердить, какая нагрузка остаётся в пределах заявленного экологического диапазона площадки. Это превращает заявление о резервировании охлаждения в доказательство полезной мощности.

Четвёртое: по отдельности вывести Vodafone и Prime Telecom, пока сеть загружена. Измерить сходимость BGP, потери пакетов, задержку и выжившую пропускную способность по IPv4 и заявленной IPv6-услуге. Подтвердить, что защита от DDoS, мониторинг, DNS и связь с клиентами работают на оставшемся пути.

Пятое: восстановить репрезентативный аккаунт общего хостинга, виртуальный сервер и сервис управления из копии за пределами основного домена отказа. Измерить время восстановления и потерю данных, включая сценарий, когда обычный клиентский портал недоступен.

Результаты не обязаны быть идеальными, чтобы быть ценными. Раскрытая слабость с последующими корректирующими действиями — более сильное доказательство, чем непроверенное заявление о полной доступности. Тогда клиенты смогут оценить, соответствует ли продемонстрированное восстановление их собственной терпимости к риску и нужна ли им независимая вторая площадка.

Рост энергопотребления и разрешения следует считать ограничениями, а не допущениями

Европейский рынок дата-центров всё чаще рассматривает доступность электроэнергии как ограничение развития. Настранице Европейской комиссии об энергоэффективности дата-центровописаны растущий спрос на электроэнергию, воздействие охлаждения и воды, а также обязательства по отчётности для объектов выше соответствующего порога. Ничто в рассмотренных публичных данных не устанавливает, что LiveHosting пересекает порог отчётности 500 кВт; исторические цифры указывают на значительно меньший объект.

Малый масштаб не снимает необходимость управлять энергоснабжением. Он меняет задачу. Компактная площадка может иметь меньшее суммарное потребление, но и меньше места для добавления распределительных устройств, охлаждения, батарей, выхлопа или хранения топлива. Городское или пригородное здание может сталкиваться с ограничениями по шуму, выбросам, пожарной безопасности и строительству. Подключение к сети может хватать для текущей нагрузки, но делать расширение медленным или дорогим.

На текущем сайте не публикуются планы расширения, новое здание или заявка на мощность. Покупателям не следует этого предполагать. Если LiveHosting продаёт новую высокоплотную мощность, доказательства должны показывать, откуда она берётся: повышенная эффективность, вывод старого оборудования, больший лимит от сети, новое охлаждение или другая площадка. Слово «доступно» должно означать, что питание, охлаждение и сеть введены в эксплуатацию, а не просто что в стойке есть свободное место.

Разрешения также влияют на восстановление. Замена генератора, добавление топливного хранилища, изменение электрического ввода или модификация пожарных систем могут требовать согласований и сроков поставщиков. Клиенту не нужны все номера разрешений в открытом доступе. Ему нужна уверенность, что установленное оборудование санкционировано, обслуживается и поддерживается, и что запланированный рост не переведёт существующий зал в длительное состояние сниженного резервирования.

Правильная коммерческая метрика — мощность, готовая к определённому отказу, а не теоретическое место ещё для одного сервера.

Что повысит доверие

LiveHosting может поднять оценку доказательной базы компактным пакетом раскрытий. Начать стоит с актуального паспорта площадки с датой и версией от оператора. В паспорте должны быть указаны адрес услуги на соответствующем уровне детализации, границы ответственности оператора и арендодателя, площадь серверного зала, введённая в эксплуатацию ИТ-нагрузка, текущий измеренный пик, лимиты мощности стойки, схема охлаждения и противопожарные средства.

В разделе энергоснабжения нужно показать вводы сети, топологию ИБП, мощность генератора, минимальное время автономии при заявленной критической нагрузке, схему топлива, а также дату и результат последнего испытания переключения под нагрузкой. Следует различать суммарные установленные номиналы и полезную мощность в состоянии N, при обслуживании и при отказе.

В сетевом разделе нужно согласовать текущие наблюдения Vodafone и Prime Telecom со старым объектом политики RIPE. Стоит раскрыть контрактные порты и гарантированную ёмкость, разнообразие граничных маршрутизаторов, раздельные физические вводы, схему защиты от DDoS и происхождение рекламируемой IPv6-подсети /56. Актуальная запись в PeeringDB или looking glass улучшили бы внешнюю видимость, но не заменили бы физическую документацию.

В операционном разделе нужно указать, кто отвечает за аварийные сигналы круглосуточно, целевые сроки реакции площадки, покрытие «удалённых рук», запас комплектующих и эскалацию поставщиков. Следует согласовать заявления о поддержке 10:00–17:00 и 10:00–18:00 и пояснить, что доступность Premium 24/7 означает для ответа и восстановления.

Наконец, оператору стоит публиковать обезличенные доказательства испытаний и инцидентов: переключение с сети, потерю охлаждающего агрегата, переключение операторов, упражнения по восстановлению, значимое обслуживание и извлечённые уроки. Независимая сертификация может усилить пакет там, где ясны область действия и актуальность. Названия сертификатов 2012 года не следует считать действующими без сертификатов, площадок, стандартов и сроков действия.

Такой уровень раскрытия не откроет данные клиентов или чувствительные планы помещений. Он позволит покупателям отличить работающий небольшой дата-центр с проверенными пределами от того, чья устойчивость выводится в основном из ярлыков продуктов.

Оценка доказательной базы — средняя

LIVEHOSTING Дата-центр SRL получает среднюю оценку доказательной базы по сети и инфраструктуре. Факты о деятельности компании существенны: действующий румынский сайт продаж, названное юридическое лицо, явное предложение колокации в Тимишоаре, AS41635, глобально видимый IPv4-маршрут, две наблюдаемые соседние сети, действующая авторизация происхождения маршрута и многолетняя история маршрутизации. Это не тот случай, когда существование провайдера или базовая работа сети опирается на единственную запись в каталоге.

Оценка останавливается на средней, потому что заявления об устойчивости не подкреплены актуальными физическими доказательствами. ИБП и генератор указаны, но топология и время автономии отсутствуют. Два блока питания сервера указаны, но разделение A/B — нет. Справочник 2012 года даёт подробные номиналы, но никакие актуальные акты пусконаладки или испытаний под нагрузкой не связывают эти цифры с инфраструктурой 2026 года.

Охлаждение, пожарная безопасность, наводнение, вводы оптоволокна, обязательства операторов, результаты обслуживания, внешнее восстановление и результаты переключений для клиентов остаются нераскрытыми в рассмотренных источниках.

Два текущих соседства BGP поддерживают логическое разнообразие путей, но отсутствие физических доказательств маршрутов не позволяет сделать более сильный вывод. Валидный IPv4-маршрут снижает риск происхождения, тогда как отсутствие IPv6-анонса от AS41635 оставляет вопрос о рекламируемой /56 открытым. Обязательство о качестве даёт клиентам механизм измерения и компенсаций, но его продуктовый охват и исключения ограничивают то, что оно говорит о восстановлении всей площадки.

Эта оценка — не приговор качеству услуг. Это заявление о разрыве между тем, что можно наблюдать, и тем, что ещё предстоит продемонстрировать. У LiveHosting могут быть более сильные актуальные инженерные документы, чем те, что публикуются. Покупателю стоит запросить их до размещения нагрузки, стоимость простоя которой превышает ценность сервисных компенсаций.

Узкий вывод таков: заявленная мощность правдоподобна как действующий сервис, но ещё не доказана как мощность в аварийном состоянии. Следующее полезное доказательство — не ещё одна конфигурация сервера. Это актуальное испытание питания, охлаждения и операторов связи, показывающее, что остаётся в работе, когда одна из общих зависимостей намеренно отключается.