REGRU «Domain names registrar REG.RU», Ltd продаёт размещённые мощности, которые по-прежнему зависят от стоек, транзита и окон обслуживания

Кратко

• REG.RU действительно имеет операционную поверхность: IANA числит регистратора аккредитованным, наблюдаемая RIPE маршрутизация показывает сотни анонсов IPv4 и IPv6 за AS197695, а фирменный каталог продаёт виртуальный хостинг, виртуальные машины, bare metal, хранилища, базы данных, Kubernetes и колокацию. Это больше, чем витрина, но это не доказывает, что названная компания-регистратор владеет каждой площадкой или сама эксплуатирует каждый продуктовый слой.
• Отказоустойчивость не наследуется от размера портфеля. REG.RU публикует несколько российских площадок, инструменты резервного копирования и миграции, плавающие адреса, частные сети и целевой показатель облачного сервиса 99,95%, однако выбор площадки, разделение бэкапов, исключения при обслуживании, замена оборудования, эскалация поддержки и проектирование приложений между площадками определяют восстановление, которое клиенты реально получают.
• Поэтому самый чёткий операционный вывод носит условный характер. Сеть и активный продуктовый каталог позволяют считать REG.RU действующим инфраструктурным провайдером. Право собственности на площадки, мощность по каждой услуге, кросс-региональная репликация и исторические показатели инцидентов остаются лишь частично видимыми, поэтому клиенту стоит проверить точное юридическое лицо по договору, площадку, цель восстановления, схему маршрутизации и процедуру экспорта для каждой услуги, прежде чем считать развёртывание на REG.RU резервным.

Аккаунт регистратора стал контуром управления инфраструктурой

REG.RU по-прежнему узнаваем как регистратор доменных имён.Реестр идентификаторов регистраторов IANAуказывает «Registrar of Domain Names REG.RU LLC» как аккредитованного регистратора под идентификатором 1606 и ссылается на его RDAP-сервис. На собственнойстранице с реквизитамиуказано российское общество с ограниченной ответственностью, чьё англоязычное наименование приведено в записи реестра, ИНН 7733568767 и юридический адрес в Москве. Эти факты определяют предмет профиля надёжнее, чем один только бренд.

Однако предложение клиентам выходит далеко за рамки регистрации. Настранице компанииREG.RU описаны облачные сервисы на базе OpenStack и VMware, выделенные серверы и колокация. В текущемкаталоге REG.Cloudперечислены виртуальные машины, физические bare-metal-серверы, управляемые базы данных, Kubernetes, S3-совместимое хранилище, приватные среды OpenStack и VMware, сетевые услуги и место в стойке. Небольшая организация может купить имя, авторитативный DNS, хостинг сайта и серверные мощности через связанные поверхности REG.RU. Крупный клиент может арендовать физическое оборудование или сочетать его с виртуальными ресурсами и управляемыми сервисами.

Такое объединение имеет операционное значение. Аккаунт регистратора — это уже не просто место, где хранится дата продления. Он может стать точкой, где сходятся публичные имена, адресные записи, заказы вычислительных ресурсов, политики резервного копирования, тикеты поддержки и платёжные балансы. Удобство снижает стоимость запуска сервиса, но одновременно концентрирует административные полномочия. Потеря доступа, ошибка в платеже, неверное изменение DNS или инцидент безопасности на уровне аккаунта могут затронуть несколько слоёв сразу, даже если сами машины остаются исправными.

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

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

Один бренд не означает одного оператора или одной модели собственности

Юридическая граница здесь особенно важна, потому что в публичных поверхностях REG.RU одно имя используется для нескольких видов услуг.Правила сайтаназывают «REG.RU Domains Hosting» LLC администратором веб-ресурсов, а «Domain names registrar REG.RU» Ltd — партнёром, оказывающим услуги по собственным клиентским договорам. Отдельноправила поддержкирегистратора описывают поддержку, которую компания-регистратор предоставляет по регистрации, хостингу и другим услугам. В действующихусловиях акции на облачные GPUорганизатором также названа компания-регистратор. Документы показывают тесную операционную интеграцию, но не позволяют считать два юридических лица взаимозаменяемыми.

Та же осторожность нужна и в отношении зданий. REG.RU заявляет, что использует сочетание собственных и подключённых мощностей дата-центров. На страницах продуктов названы коммерческие площадки, а также площадки под брендом REG.RU. Настранице VPSуказаны локации: KIAEHOUSE на площадке Института Курчатова, SafeData, Медведково-2, DataPro, объект на Варшавском шоссе, Дата-центр № 1 в Санкт-Петербурге и «Жигулёвская долина» в Тольятти. В анонсе июня 2026 года сообщается, что третий московский облачный регион открыт на площадке Magistralny-1 компании Datahouse. Эти названия указывают на аренду, договоры размещения или иные зависимости от площадок в дополнение к зданиям, которыми группа может владеть напрямую.

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

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

Поэтому практический вопрос при закупке точнее, чем «Владеет ли REG.RU своими дата-центрами?». Он звучит так: для этой заказанной услуги на этой выбранной площадке кто владеет сервером, кто предоставляет remote hands, кто контролирует сетевую границу, кто сопровождает гипервизор и хранилище и какая компания несёт договорную ответственность? Bare-metal-машина, заявленная как физически доступная, — это не то же самое, что виртуальная машина на общем кластере, и оба варианта отличаются от сервера клиента, размещённого в колокации.

Документация REG.RU полезна, потому что раскрывает часть этого разделения, но не публикует полную матрицу владения и ответственности для каждого продукта и площадки. Пока такую матрицу не даст договор или техническое приложение, заявления о владении всем портфелем следует считать непроверенными. Сервис может быть реальным и действующим, даже если не каждая стойка является корпоративным активом юридического лица, указанного в реестре.

Физическая инфраструктура — российская, распределённая и описанная неравномерно

Вруководстве по размещению хостингаREG.RU указаны пять основных адресов: три в Москве, один в Санкт-Петербурге и один в Тольятти. Там сказано, что общий виртуальный хостинг находится на площадке на площади Курчатова в Москве, и что площадки имеют резервное электропитание, охлаждение и многоуровневую безопасность. Это полезное доказательство на уровне услуги: оно привязывает общий хостинг к конкретному месту, а не просто говорит «Россия».

Более широкий каталог провайдера ещё шире. Страница VPS приводит названия площадок, показатели мощности, число стоек и виды услуг. Дата-центр № 1 на Предпортовой улице в Санкт-Петербурге описан как площадка, спроектированная по уровню Tier III, мощностью 2 МВт и 260 стойками, а «Жигулёвская долина» в Самарской области — как площадка, сертифицированная по стандартам Uptime Institute Tier Design и Tier Facility. На странице также перечислены московские площадки с разными сочетаниями bare metal и публичного облака. По крайней мере для одной из этих зависимостей возможна независимая проверка:страница контактов самого Дата-центра № 1указывает тот же адрес на Предпортовой улице, что подтверждает: петербургская площадка REG.RU соответствует отдельно управляемому объекту.

Последнее заявление REG.RU о портфеле ещё масштабнее. Анонсируя в июне 2026 года инстансы на NVIDIA Blackwell, компания сообщила, что фирменное облако включает десять дата-центров, совокупную мощность 85,5 МВт и пропускную способность оптических каналов 300 Гбит/с. Новый регион Москва-3 наплощадке Datahouse Magistralny-1описан как независимый инфраструктурный контур с собственным кластером OpenStack и гипервизорами. Этой площадке приписываются 1100 стоек, до 15 кВт на стойку и целевой показатель 99,99%.

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

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

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

Установленная мощность — это не доступная мощность

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

Для bare metal доступная мощность видна как готовые конфигурации. Настранице выделенных серверовзаявлены AMD EPYC, Intel Xeon, NVMe, жёсткие диски и GPU, оборудование указано как находящееся в наличии. В отдельных предложениях показана конкретная машина и указано, что для многих серверов поставка начинается от 45 минут. Это сильнее, чем концептуальная страница продукта: здесь виден активный склад и механизм заказа. Однако склад меняется, и наличие похожей машины в каталоге не гарантирует замену детали. Клиентам со строгими целями восстановления нужно знать, есть ли на выбранной площадке запасные части для вышедших из строя дисков, блоков питания, материнских плат и ускорителей и какая замена разрешена.

Для виртуальных машин доступная мощность зависит от запаса кластера, производительности хранилища, ограничений планировщика и доступности сети. Вруководстве по заказу облачных серверовпоказаны стандартные, высокочастотные конфигурации и конфигурации для регулируемых данных, а также образы с GPU. Аппаратный анонс июня 2026 года идёт дальше: для региона Москва-3 названы системы Supermicro, процессоры AMD EPYC 9554 и ускорители RTX 6000 Pro Blackwell Server Edition. Такая конкретика подтверждает наличие реального нового пула оборудования, но по-прежнему не раскрывает оверсабскрипшн, свободный запас или число установленных хостов.

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

Даже электрическая мощность площадки условна. Здание на 36 МВт может иметь сильную инфраструктуру, тогда как арендуемая площадь провайдера, договорная мощность и установленные сетевые порты могут быть значительно меньше. Проектный лимит 15 кВт на стойку не означает, что каждой стойке выделена такая нагрузка. Полезная единица для клиента — не рейтинг кампуса, а договор мощности, привязанный к выбранной услуге, и способность провайдера предоставить больше мощности при отказе в другом месте.

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

AS197695 — самый ясный независимый признак реальной эксплуатации

Сетевые записи дают самое сильное доказательство того, что указанное в реестре юридическое лицо эксплуатирует инфраструктуру, а не просто продаёт сервисы другой компании. Регистрация в RIPE и публичные наблюдения маршрутизации связывают AS197695, AS-REGRU, с «Domain names registrar REG.RU», Ltd.Снимок BGP.Toolsописывает сеть как активную и ориентированную на контент и показывает сотни анонсируемых префиксов IPv4 плюс анонсы IPv6.Ответ RIPEstat по анонсируемым префиксамзафиксировал 12 июля 2026 года 477 анонсов: 453 префикса IPv4 и 24 префикса IPv6, без учёта маршрутов с очень низкой видимостью в коллекторах.

Широта этой поверхности существенна. Она соответствует хостинг-провайдеру, обслуживающему множество клиентских блоков адресов и сервисов. Один пример префикса —176.99.13.0/24— анонсируется AS197695 и содержит адреса, используемые DNS-серверами REG.RU. Основной веб-домен компании также резолвится в ту же автономную систему, согласноDNS-представлению Hurricane Electric. Эти наблюдения связывают корпоративную, DNS- и хостинговую поверхности с эксплуатируемым доменом маршрутизации.

Ответ RIPE по соседям ASпоказал многочисленные соседние номера AS в наблюдаемых путях на ту же дату, включая TransTeleCom, EDINAYA SET, Hurricane Electric, OBIT, RETN и ER-Telecom среди прочих. Это указывает на разнообразную внешнюю связность в глобальной картине маршрутизации. Это не доказывает, что каждая площадка REG.RU имеет физически различные вводы, что каждая названная сеть является платным апстримом или что два канала не проходят в одной канализации. Классификация путей left/right у RIPE — это наблюдение о позиции в AS-пути, а не коммерческая метка.

Есть и два предостережения. Во-первых, AS43146 зарегистрирован на ту же организацию, ноBGP.Tools сообщает, что его нет в текущей глобальной таблице. Зарегистрированная автономная система — не доказательство действующего сервиса; рабочим операционным сигналом является AS197695. Во-вторых, запрос ксетевой конечной точке PeeringDBне вернул публичной записи о сети для AS197695. Участие в PeeringDB добровольное, поэтому отсутствие записи не говорит о плохой связности. Но это означает, что в открытых данных нет поддерживаемой провайдером матрицы площадок и точек обмена, которая могла бы помочь проверить, где именно пирится REG.RU.

Масштаб сети не отменяет концентрации. Сотни префиксов могут проходить через одну автономную систему и использовать общую политику маршрутизации, системы защиты или операционный персонал. Клиенты, использующие REG.RU для авторитативного DNS, хостинга и исходного сервера приложения, могут оставаться зависимыми от одного аккаунта и сети, даже если IP-адреса различаются. Настоящее разнообразие маршрутов требует тестирования путей из релевантных пользовательских сетей и подтверждения физических каналов на каждой выбранной площадке.

Обещание уровня сервиса оставляет место для окон обслуживания

Соглашение об уровне облачного сервиса REG.RU необычно откровенно показывает разницу между целевым показателем доступности и бесперебойным обслуживанием.Соглашение, действующее с 14 апреля 2026 года, устанавливает месячные целевые показатели 99,95% для инфраструктурных, сетевых и сервисных услуг дата-центра, таких как электропитание, отопление, вентиляция и охлаждение. В месяце из 730 часов 0,05% соответствует примерно 21,9 минуты — до учёта исключений.

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

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

На страницах продуктов иногда встречаются другие цифры. Руководство по размещению общего хостинга рекламирует аптайм 99,9%, а в анонсе Москва-3 площадке приписывается 99,99%. Эти проценты относятся к разным областям, и смешивать их не следует. Проект площадки или целевой показатель площадки — это не доступность приложения. Сервер может оставаться под напряжением, когда отказывают хранилище, гипервизор, маршрут, DNS или клиентское ПО. И наоборот, платформа может удерживать приложение в сети при отказе хоста, если нагрузка распределена правильно.

Публичная прозрачность по инцидентам слабая. В ходе этого обзора не найден явно разрешимый публичный статусный хост REG.RU, а архив новостей компании не является структурированной историей инцидентов. Сторонние мониторы дают лишь слабые сигналы. Например,страница аптайма Hosters.ruсообщает о проверках публичного сайта REG.RU, а не клиентской облачной инфраструктуры, иWho.isточно так же измеряет корпоративную конечную точку. Неудачный запрос может отражать фильтрацию, проблему с редиректом или сам сайт; успешный запрос ничего не говорит о клиентской виртуальной машине в другом регионе. Эти наблюдения не могут ни подтвердить, ни опровергнуть выполнение облачного SLA.

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

Отказ оборудования возвращает облачную абстракцию к складским запасам и труду

Виртуальная машина кажется независимой от конкретного сервера, пока не откажет физический компонент. Bare-metal-сервис никогда не скрывает этой зависимости. Документация REG.RU показывает и преимущества, и ограничения её операционной модели оборудования.

Каталог выделенных серверов включает удалённое управление, защиту от DDoS, сетевой порт, установку операционной системы и «операционную замену» неисправностей. Вруководстве по IPMIобъясняется, что некоторые серверы предоставляют независимое out-of-band управление, а где IPMI нет, доступен KVM. Клиент может использовать этот канал для диагностики проблем с загрузкой, перезагрузки машины или установки операционной системы, даже когда основная ОС недоступна. Это уменьшает зависимость от поддержки при ряде неисправностей.

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

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

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

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

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

Резервные копии — это продукты, а не доказательство восстанавливаемости

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

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

У выделенных серверов возможностей больше. Настранице продукта резервного копированияREG.RU описаны ежедневные копии на уровне файлов для Linux, варианты Veeam, FTP-хранилище, S3 и индивидуальные схемы. Там сказано, что резервные копии хранятся отдельно от сервера, а стандартное описание для Linux сохраняет предыдущие семь дней. Более сложные схемы могут размещать свежие копии на диске, а более длинные архивы — на ленте. Однако «отдельно от сервера» не обязательно означает «в отдельном здании» или «вне провайдера». Клиентам нужно знать точное расположение и административное разделение.

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

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

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

Выбор нескольких площадок — это не автоматический мультисайтовый сервис

REG.RU добавил реальный выбор локаций. Ванонсе 2023 годаописывалась облачная площадка в Санкт-Петербурге наряду с тремя московскими дата-центрами. В операционном обновлении 2024 года сообщалось, что компания подключила новую площадку в Тольятти, расширяя облачные продукты. В марте 2026 года REG.Cloud анонсировалвторую московскую локацию для управляемых баз данных, позволяя клиентам разворачивать DBaaS в Москве-1 или Москве-2 и восстанавливаться в новый кластер. В июне Москва-3 добавила отдельный контур OpenStack.

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

Обновление DBaaS — хороший пример точного, но ограниченного прогресса. В нём сказано, что клиенты могут выбрать одну из двух московских локаций, восстановить резервную копию в новый кластер без остановки исходного и использовать восстановление на момент времени для PostgreSQL. Эти возможности снижают стоимость тестирования восстановления и перехода на чистый инстанс. В анонсе сказано, что вторая локация улучшает распределение нагрузки и отказоустойчивую архитектуру; но не сказано, что базы данных по умолчанию синхронно реплицируются между обеими локациями.

Плавающие публичные адреса тоже имеют ограниченную область действия. Вруководстве REG.RU по плавающим IPсказано, что адрес можно привязать к устройству в пределах одной частной подсети. Это полезно для переключения между инстансами в этой сети. Но это не доказательство того, что тот же адрес может переехать в другой регион или пережить потерю контура управления сетью. Аналогично частные сети объединяют ресурсы, но требуют от клиента проектирования маршрутов, адресов и безопасности.

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

Клиентам стоит также спрашивать, можно ли выбрать целевой регион при заказе для каждого компонента. Виртуальная машина в Москве-2 в паре с хранилищем, доступным только в Москве-1, может сохранять скрытую межплощадочную зависимость. Управляемая база данных может поддерживать две локации, тогда как репозиторий резервных копий остаётся общим. Публичная документация подтверждает наличие выбора; она не даёт полной карты зависимостей.

Разнообразие транзита нужно доказывать на границе сервиса

Наблюдаемые соседи AS197695 и сотни префиксов делают сеть с единственным оператором маловероятной на уровне автономной системы. REG.RU также рекламирует на странице VPS ёмкость частной сети примерно 200 Гбит/с и дублированные каналы доступа 40 Гбит/с, а в более новом заявлении о портфеле фигурируют оптические каналы на 300 Гбит/с. Эти цифры указывают на существенную сеть, но не заменяют доказательств маршрутов по каждой площадке.

Сеть может отказать на нескольких уровнях. Коммутатор верхнего уровня стойки может изолировать группу серверов. Кросс-коннект на площадке может выйти из строя, пока более широкая автономная система остаётся видимой. Утечка маршрута или ошибка фильтрации могут сделать отдельные префиксы недостижимыми из некоторых сетей. Средства защиты от DDoS могут сохранять мощность, но давать ложные срабатывания. Файрвол на стороне клиента или смена адреса могут выглядеть как сбой провайдера. DNS может продолжать отвечать, когда исходный сервер недоступен, или исходный сервер работает, а аккаунт REG.RU, через который меняется DNS, недоступен.

Для клиента релевантный тест начинается с адреса приложения, а не с заголовочного ASN провайдера. Наблюдения за маршрутами нужно собирать из пользовательских сетей и более чем из одной внешней сети. Traceroute не доказывает физическое разнообразие, но повторные измерения могут показать, сходятся ли пути у одного оператора. Договорная документация или сетевые схемы должны указывать отдельные кросс-коннекты, meet-me-румы и вводы в здание, когда эти детали важны.

Отсутствие публичной записи в PeeringDB затрудняет такую проверку. В PeeringDB могли быть перечислены точки обмена, площадки, ёмкость и политика, но добровольный характер базы означает, что REG.RU может просто использовать частные договорённости или не публиковать данные. Данные RIPE подтверждают доступность в интернете и разнообразие соседей, но не позволяют определить местоположение каждой точки соединения. Поэтому правильная оценка доказательств — сильная для активной и крупной сети и средняя или слабая для разнообразия маршрутов на конкретных площадках.

Это различие влияет и на «мультисайтовые» схемы внутри одного провайдера. Два региона REG.RU могут использовать отдельные хосты и хранилища, но разделять AS197695, сервисы защиты, управление адресами или политику внешнего транзита. Это может быть приемлемым компромиссом: он защищает от многих локальных отказов, сохраняя невысокую операционную сложность. Но это не эквивалент использования независимого DNS-провайдера, второй автономной системы и второго облака для самого критичного пути.

Оплата, поддержка и управление аккаунтом — это зависимости инфраструктуры

Отказ инфраструктуры не ограничивается сломанным оборудованием. Условия облачных услуг REG.RU описывают баланс, который списывается по мере использования ресурсов, а SLA исключает перерывы, связанные с невыполнением условий оплаты. Сервис может стать недоступным из-за коммерческого состояния, даже когда стойка, маршрут и гипервизор исправны. Организациям стоит относиться к уведомлениям о балансе, правам на продление и способам оплаты как к производственным элементам управления.

Аккаунт имеет аналогичное значение. Хостинговые услуги в России требуют идентификации клиента, ируководство REG.RU по идентификации в облакераспространяет это требование на виртуальные машины, базы данных, Kubernetes, S3 и физические выделенные серверы. Идентификация может усилить подотчётность, но создаёт зависимости от документации и доступа. Корпоративному клиенту стоит убедиться, что аккаунтом могут управлять несколько авторизованных сотрудников и что записи о владельце остаются актуальными при смене персонала.

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

Поддержка также пересекает границы ответственности. На неуправляемом bare-metal или облачном сервере провайдер может восстановить питание, сеть или оборудование, пока клиент чинит операционную систему и приложение. Управляемые сервисы переносят часть ответственности на провайдера, но клиенты по-прежнему отвечают за классификацию данных, поведение приложений и настройку доступа. На странице S3 ответственность разделена явно: провайдер обеспечивает репликацию и физическую инфраструктуру, клиент управляет разрешениями, жизненным циклом, версионированием, интеграциями и ключами.

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

Самая опасная концентрация — аккаунт, который управляет регистрацией домена, DNS и инфраструктурой с одним набором учётных данных и одним платёжным путём. Более безопасная схема разделяет роли, защищает действия с высоким влиянием, хранит офлайн-запись идентификаторов ресурсов и имеет второй способ связи. Это обычная операционная гигиена, но широта каталога REG.RU делает её особенно значимой.

Переносимость есть, но миграция имеет цену и последовательность

REG.RU предоставляет несколько открытых или привычных интерфейсов, снижающих зависимость от провайдера. Виртуальные машины могут работать на распространённых системах Linux и Windows. Выделенные серверы предоставляют IPMI или KVM и позволяют использовать собственные образы операционных систем. Объектное хранилище использует S3-совместимый интерфейс. Для части облачных операций поддерживается Terraform. Данные можно копировать стандартными инструментами, а DNS остаётся основанным на переносимых записях.

Руководство провайдера по миграции с cPanel на ispmanagerценно тем, что показывает реальную последовательность: определить файлы и базы данных, сделать архив и дамп базы, зафиксировать версию ПО, создать целевую среду, загрузить файлы, импортировать данные, протестировать до изменений DNS, обновить записи и отдельно перенести почту. Это миграция в REG.RU, но те же компоненты нужно понимать и при миграции наружу.

Поэтому переносимость — это не признак «да или нет». Небольшой статический сайт можно скопировать быстро. Крупной базе данных нужна репликация или окно обслуживания. Управляемая база данных может предоставлять стандартные инструменты движка, но всё равно требовать совместимых версий и расширений. Объектное хранилище масштаба терабайт может использовать стандартный API, но передача по доступному каналу займёт значительное время. Публичные IP-адреса обычно не переезжают к другому провайдеру, поэтому придётся менять DNS, сертификаты и списки разрешений.

Комбинация сервисов REG.RU может помочь поэтапному переезду. Клиент может построить новый сервер, восстановить данные, протестировать его через запись в локальном hosts-файле или временное имя и переключить публичную запись только когда готов. Руководство по миграции прямо рекомендует тестирование до переключения. Однако использование DNS REG.RU и для старого, и для нового сервиса означает, что переключение по-прежнему зависит от того же контура управления. Для критичных миграций может быть оправдана независимая вторичная DNS-схема и заблаговременное сокращение времени жизни записей.

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

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

Локализация данных ясна на уровне страны и менее ясна внутри продуктов

REG.RU последовательно размещает рекламируемую инфраструктуру в России. В руководстве по хостингу названы российские города и адреса. В облачном каталоге сказано, что объекты уровня Tier III находятся в Москве, Санкт-Петербурге и Самарской области. Страница S3 делает то же заявление на уровне страны. Для организаций, обязанных хранить персональные данные российских граждан в России, это значимая основа.

Провайдер также предлагает облачные серверы, предназначенные для требований Федерального закона 152-ФЗ. Вдокументации по серверам для регулируемых данныхуказана московская локация и описаны ответственность провайдера за инфраструктуру, сертифицированная площадка и технические меры защиты. Это конкретнее, чем общее обещание «локального облака». Но это не переносит всю ответственность за соответствие требованиям на провайдера: клиент остаётся оператором персональных данных и должен соответствующим образом настраивать и управлять своей системой.

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

География продуктов также может меняться. Маркетинговая страница S3 упоминает Москву, Санкт-Петербург и Самару, тогда как отдельные облачные функции могут быть доступны только в одном или двух регионах. В анонсе DBaaS описаны две московские локации, а запуск Blackwell привязан к Москве-3. Клиент не может вывести варианты размещения продукта из общей корпоративной карты. Интерфейс заказа и приложение к договору должны указывать выбранный регион.

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

Как выглядит отказ для разных клиентов

Небольшой бизнес, использующий REG.RU для домена, общего хостинга и почты, больше всего подвержен отказам аккаунта, DNS и общей платформы. Ежедневные резервные копии могут восстановить сайт, но изменения, сделанные после последней копии, могут быть потеряны. Если один и тот же аккаунт управляет доменом и хостингом, проблема с доступом может заблокировать и диагностику, и перенаправление. Часто достаточно скромных улучшений: независимое восстановление аккаунта, внешняя копия данных сайта и почты и задокументированный способ перевода DNS.

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

Клиент на bare metal несёт больше эксплуатационной ответственности. IPMI может восстановить консольный доступ, а REG.RU может заменить неисправное оборудование, но приложение может оставаться привязанным к локальным дискам и конкретной машине. Зеркалированные диски защищают от некоторых отказов устройств, но не от потери площадки или повреждения данных. Для критичной нагрузки минимальные достоверные меры отказоустойчивости — второй сервер и копия данных вне машины.

У клиента с регулируемыми данными другое ограничение: цель восстановления должна соответствовать тем же требованиям к месту хранения и безопасности, что и продуктив. Резервная копия в неуказанном месте или поспешно выбранное альтернативное облако могут оказаться непригодными с точки зрения соответствия требованиям. Несколько российских площадок REG.RU могут быть полезны, но точное размещение и меры контроля нужно подтверждать письменно.

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

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

Операционный вывод: реальная сеть, частичная прозрачность, отказоустойчивость, которую строит клиент

REG.RU проходит порог, отделяющий действующего инфраструктурного провайдера. Названная компания-регистратор актуально присутствует в реестре IANA, владеет сетевыми ресурсами RIPE и анонсирует большую живую поверхность маршрутизации через AS197695. В фирменном сервисном портфеле есть заказываемые bare-metal-позиции, виртуальные машины, хранилища и управляемые продукты. Документация раскрывает физические адреса, методы удалённого управления, поведение резервного копирования и договорной целевой показатель доступности. Это содержательные операционные сигналы.

На границах доказательства менее полны. Публичные материалы смешивают бренд группы и несколько юридических лиц. Цифры портфеля объединяют площадки, которые, судя по всему, имеют разных владельцев и роли. Рейтинги площадок и совокупные мегаватты не раскрывают занятую или свободную мощность REG.RU. Глобальная картина маршрутизации не доказывает разнообразие каналов на каждой площадке. Страницы продуктов не дают общей карты доменов репликации и восстановления. Структурированная публичная история инцидентов для сравнения с SLA отсутствовала.

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

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

Для мультисайтовых схем покупателю также стоит подтвердить, зарезервирована ли мощность на альтернативной площадке и остаются ли DNS, идентификация и управление работоспособными при отказе основной площадки.

Ценностное предложение REG.RU — снижение трения. Клиент может начать с домена и добавлять всё более физические формы инфраструктуры, не покидая той же коммерческой среды. Реальность движется в противоположную сторону: каждая добавленная услуга приносит серверы, диски, сетевые каналы, договоры с площадками, команды поддержки и решения о восстановлении. Облачный интерфейс упрощает покупку этих зависимостей. Он не заставляет их исчезнуть.