CLOUD Asre Dadeha Asiatech продаёт арендуемые мощности, которые по-прежнему зависят от стоек, транзита и ремонтных окон

Кратко

• Cloud.ir даёт CLOUD Asre Dadeha Asiatech реальную розничную витрину: на сайте есть облачные серверы, тарифы VPS, облачное хранилище, CDN, облачный коммутатор, услуги облачного дата-центра, панель клиента, опубликованные цены и SLA, а в подвале сайта указано, что сайт принадлежит Asre Dadeha Asiatech.
• Физическая привязка уже, чем язык продуктов. Cloud.ir сообщает, что его инфраструктура размещена в дата-центрах ASIATECH в Иране, а страница «О нас» говорит, что Cloud.ir работает с 1399 года иранского календаря и предлагает более 20 облачных продуктов, но публичные страницы не раскрывают, в какой именно стойке, в каких городах, по какой схеме электропитания и с какими результатами тестов восстановления размещена каждая рабочая нагрузка клиента.
• Сетевая доказательная база сильна на уровне плоскости управления. RIPE RDAP называет AS60077 как AT-CLOUD для Asre Dadeha Asiatech, RIPEstat показал 18 префиксов IPv4 и 14 080 адресов IPv4, анонсируемых AS60077 на 12 июля 2026 года, а DNS дляcloud.irуказывает на префикс AS60077. В том же представлении RIPE виден один наблюдаемый сосед слева у AS60077 — AS43754, ASIATECH Asiatech Data Transmission company.
• Поэтому вопрос покупателя не в том, существует ли облачный продукт. Вопрос в том, может ли конкретный клиент проверить размещение, запас мощности, независимые маршруты, локальность резервных копий, эскалацию поддержки, исключения из обслуживания, непрерывность биллинга и права на выход до того, как событие со стойкой, апстримом, складом оборудования или аккаунтом превратит виртуальный сервер в физическую зависимость.

Витрина публична, но обещание инфраструктуры остаётся многослойным

Cloud.ir — это не заглушка бренда.Главная страница Cloud.irпредлагает облачные серверы, услуги облачного дата-центра, облачный коммутатор, CDN, облачное хранилище, управление облачными доменами, страницу цен на услуги, страницы поддержки и вход для клиентов. На той же странице указаны телефон, электронная почта, адрес офиса в Тегеране и подвал с заявлением, что материальные и интеллектуальные права на сайт принадлежат Asre Dadeha Asiatech. Для этого профиля важно, что идентичность компании связана с живой витриной услуг, а не только с записью о маршрутизации.

Страница «О нас»добавляет историю услуг. Там сказано, что Cloud.ir начал работу в 1399 году иранского календаря и стал одним из ведущих облачных провайдеров Ирана с более чем 20 облачными продуктами. Перечисленные там продуктовые группы включают распространение контента, облачные вычисления, облачную безопасность, облачное хранилище, облачные сети и облачный маркетплейс. Это заявления компании, а не независимые измерения мощности, но они проясняют базовую коммерческую позицию: CLOUD Asre Dadeha Asiatech продаёт арендуемые мощности клиентам, которые не хотят покупать и эксплуатировать собственную физическую инфраструктуру.

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

Страница ценCloud.ir делает продукт ещё более проверяемым. На ней перечислены названия пакетов VPS, например AT-VPS-B2, AT-VPS-G1 и AT-VPS-A2, с памятью, процессором, диском, одним бесплатным IP-адресом, базовым трафиком, поддержкой дополнительных IP, пересборкой и IPv6 на карточках пакетов. Там же показана почасовая тарификация ресурсов облачного сервера: память, процессор, диск, IP, входящий трафик и уровни резервного копирования. Страницы цен — это не инженерные схемы, но они показывают, как упакована услуга: клиент покупает конечные единицы вычислений, хранения, адресов и трафика, которые должны где-то существовать, прежде чем панель управления сможет их выделить.

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

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

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

Физическая привязка — мощности дата-центров ASIATECH в Иране

Самое сильное физическое заявление Cloud.ir сформулировано явно: его облачная инфраструктура размещена в дата-центрах ASIATECH.Страница облачного сервераговорит, что инфраструктура облачных сервисов Cloud.ir развёрнута в дата-центрах ASIATECH, которые она называет крупнейшей сетью дата-центров в Иране. Там перечислены современные технологии, заявления об ISO27001 и TIA-942 уровня Tier 2 и Tier 3, системы безопасности, стабильная сетевая связность, высокое потребление полосы в Иране, поддержка питания AC и DC.Страница облачного дата-центраповторяет ту же рамку дата-центров ASIATECH и говорит, что дата-центры Cloud.ir по всему Ирану предоставляют инфраструктуру клиентам, начинающим облачную миграцию.

Страница «О нас»аналогична. Там сказано, что дата-центры Cloud.ir распределены по Ирану и что инфраструктура опирается на дата-центры ASIATECH — крупные и мощные объекты мирового уровня. Также перечислена поддержка AC и DC. Эти заявления важны, потому что переводят сервис из чистой розничной абстракции к названной границе оператора объекта: облачный бренд зависит от парка дата-центров и сети ASIATECH, а не от безымянного зарубежного гиперскейл-региона.

Вне корпоративных страниц публичный след даёт более старый, но полезный контекст. Дата-центр Dynamics сообщила в июле 2017 года, что AsiaTech открылдата-центр площадью 700 квадратных метров в башне Милад на западе Тегерана. В отчёте AsiaTech назван частной компанией, основанной в 2003 году; сказано, что в 2013 году компания получила лицензию на хостинг, выделенные и общие серверы и колокацию, а также управляла пятью дата-центрами и соединяла более 430 городов Ирана. DataCenterMap сейчас перечисляетдата-центр Asiatech в башне Миладидата-центр Asiatech Azadeganв Тегеране, а страница характеристик башни Милад говорит, что Asiatech не предоставила данных о мощности, электропитании, соответствии, безопасности или здании.

С этими внешними ссылками нужно обращаться осторожно. Они подтверждают, что ASIATECH связана с названными объектами в Тегеране и более широким бизнесом дата-центров. Они не доказывают, какой объект обслуживает конкретную виртуальную машину Cloud.ir, CDN-узел, хранилище или резервную копию в июле 2026 года. Они также не доказывают, что состояние объекта 2017 года, число стоек, схема питания или число клиентов не изменились. История объектов — полезное свидетельство существования реальной инфраструктурной компании; это не карта текущего размещения.

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

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

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

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

AS60077 виден, и родительская сеть — очевидная зависимость

Сетевая запись даёт CLOUD Asre Dadeha Asiatech второй конкретный якорь. RIPE RDAP идентифицируетAS60077как AT-CLOUD и связывает его с Asre Dadeha Asiatech через ORG-ADA42-RIPE. Тот же ответ RDAP включает административные и технические контакты NOC Asiatech по адресу на улице Миремад в Тегеране, а также роль злоупотреблений Asiatech. Это реестровое свидетельство реальной автономной системы и действующей цепочки контактов. Оно не описывает отдельные серверы, клиентов или аптайм, но подтверждает, что облачный сервис имеет собственный сетевой идентификатор.

Обзор AS60077 в RIPEstatсообщает держателя как «AT-CLOUD Asre Dadeha Asiatech» и показывает, что сеть была видна на момент запроса 12 июля 2026 года.Вид routing-statusпоказал 18 префиксов IPv4 и 14 080 адресов IPv4, видимых от AS60077, при этом первое наблюдение префикса датировано 2014 годом, а последнее — моментом запроса. Тот же вид RIPE показал высокую видимость в коллекторах IPv4 и отсутствие видимого пространства IPv6 в этом конкретном ответе о статусе.

Активный сервис также указывает обратно в AS60077.Вид DNS-chain в RIPEstat дляcloud.irвернул193.151.157.174для корневого имени, авид network-info для этого адресасопоставил его с193.151.157.0/24и AS60077. Это не доказывает, что каждая рабочая нагрузка клиента работает в том же префиксе; это показывает, что собственное публичное веб-присутствие компании обслуживается из облачного ASN.

Зависимость видна в данных о соседях.Вид ASN-neighbors для AS60077показал одного наблюдаемого соседа слева: AS43754.Обзор AS43754 в RIPEstatназывает эту сеть «ASIATECH Asiatech Data Transmission company». Еговид routing-statusпоказал гораздо более крупный сетевой след в тот же момент: 316 префиксов IPv4, 209 920 адресов IPv4 и 86 наблюдаемых соседей. Картина прямая: облачный ASN виден, но его публичная восходящая граница, судя по всему, — более крупная сеть ASIATECH.

Примеры из looking-glass делают связь видимой в реальных путях.Данные looking-glass для193.151.128.0/22, одного из анонсируемых префиксов AS60077, включали пути, заканчивающиеся на AS43754 AS60077. Некоторые глобальные выборки также показывали более ранние апстримы перед AS43754, но устойчивая зависимость у источника оставалась AS43754. Это неудивительно для облачного бизнеса, прикреплённого к той же корпоративной инфраструктурной группе, но это важно, потому что сбой на этой границе может затронуть сразу многие сервисы.

Это не значит, что AS60077 хрупка. Одно видимое восходящее отношение может быть вполне разумным, когда родительская сеть имеет операторскую связность, операционную дисциплину и достаточную избыточность за кулисами. Это также не значит, что у AS43754 только один внешний путь; RIPEstat показал много соседей у AS43754. Важный момент уже: публичные данные BGP не доказывают, что у самой AS60077 есть несколько независимых апстримов, отдельные физические входы, отдельные граничные маршрутизаторы или независимый фейловер вне AS43754.

Клиентам следует рассматривать AS43754 как видимую операционную границу апстрима, если Cloud.ir не предоставит продуктовых доказательств дальнейшего разделения.

RPKI отвечает на другой вопрос.Проверка RPKI для193.151.128.0/22, исходящего от AS60077, вернула статус valid с разрешениями на объявление маршрута (ROA), покрывающими AS60077. Это позитивная гигиена маршрутизации: она поддерживает легитимность источника маршрута. Она не доказывает пропускную способность трафика, разнообразие маршрутов, непрерывность питания, качество изоляции клиентов, восстанавливаемость резервных копий или скорость реакции поддержки. RPKI-валидный маршрут всё равно может быть случайно отозван, отфильтрован апстримом, изолирован сбоем кросс-коннекта или обесценен сбоем на стороне сервера.

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

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

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

Сетевые цифры дают внешнюю границу, а не число серверов.Список анонсируемых префиксов AS60077показал 18 префиксов IPv4 за недавний период запросов, включая несколько диапазонов/22,/23и/24. 14 080 адресов IPv4, видимых в обзоре routing-status, — реальная ёмкость публичных адресов, но адреса не равны виртуальным машинам. Некоторые адреса обслуживают маршрутизаторы, балансировщики нагрузки, файрволы, серверы имён, клиентские инстансы, управленческие функции или резервные пулы. Один сервер может использовать несколько адресов; за одним адресом может стоять много сервисов; неиспользуемые адреса могут сосуществовать с полностью загруженным кластером вычислений.

Та же осторожность относится к упоминаниям IPv6 у Cloud.ir. Страница цен показывает IPv6 на карточках пакетов VPS. Использованный здесь запрос routing-status RIPE не показал видимого пространства IPv6 у AS60077 на момент запроса. Это не доказывает, что IPv6 отсутствует в продукте: IPv6 может предоставляться через другую схему, быть доступен только в определённых тарифах, быть виден в других коллекторах или иначе отображаться на сторонних сайтах маршрутизации.

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

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

Два дата-центра используются по умолчанию или только если их настроит клиент? Резервная копия горячая, тёплая или холодная? Есть ли протестированное время восстановления? Предусмотрены ли кредиты, если автоматика не сработает?

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

Они не раскрывают достаточно, чтобы превратить это в резерв мощности.

SLA сужает обещание ровно в тех точках, которые проверит сбой

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

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

Рассмотрим сбой ПО. Если гостевая операционная система сломается после обновления клиента, текст SLA предполагает, что проблема находится за пределами гарантии аптайма провайдера, даже если клиент испытывает полную потерю сервиса. Это разумно, если Cloud.ir продаёт неуправляемые вычисления, но это значит, что покупателю нужны отдельные права на восстановление: консольный доступ, аварийная загрузка, снапшоты, экспорт образов, откат, пересборка и чёткие границы поддержки. «Облачный сервер» — это не управляемая непрерывность приложений, если иное не сказано в контракте.

Рассмотрим событие отказа в обслуживании. Страница облачного сервера продвигает облачный файрвол и сообщения об атаках. Страница SLA исключает атаки типа «отказ в обслуживании» против облачного сервера из гарантии аптайма. Продукт может помогать смягчать трафик, но клиенту не стоит предполагать, что каждый сбой, вызванный атакой, создаёт компенсацию. Вопрос становится практическим: какой объём трафика выдерживает файрвол, что фильтруется на облачной границе, что доходит до инстанса, кто может менять фильтры во время атаки и когда Cloud.ir может приостановить или ограничить цель, чтобы защитить других клиентов?

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

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

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

Поэтому SLA обостряет вопросы покупателя. Оно не делает Cloud.ir слабее; оно делает форму сервиса более познаваемой. Клиенту стоит различать доступность сети, доступность хоста, здоровье гостевой системы, целостность хранилища, восстанавливаемость резервных копий, поведение CDN, статус аккаунта и правовые ограничения. Публичное SLA не сжимает эти слои в одно обещание. Не должен и производственный покупатель.

CDN, хранилище и облачный коммутатор расширяют и набор функций, и радиус поражения

Сервисы Cloud.ir — CDN, хранилище и виртуальные сети — полезны, потому что могут снизить нагрузку на один исходный сервер и дать клиентам больше архитектурных вариантов. Они также делают карту зависимостей шире.Страница CDNговорит, что внутреннее распространение может отвечать на запросы через местные дата-центры и создавать полутрафик для внутренних пользователей; там также описаны направление пользователей на более близкие серверы, сжатие и кэширование контента, мониторинг запросов и ответов, ограничения доступа по странам и защита от атак. Это настоящая продуктовая история, но она превращает сайт в цепочку: DNS, CDN-узел, состояние кэша, доступность источника, работа с сертификатами, конфигурация аккаунта и поддержка должны работать вместе.

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

Клиенту нужны контроль очистки кэша, поведение origin shield, логи, правила fail-open или fail-closed, видимость продления сертификатов и способ увести DNS, если CDN-сервис станет точкой отказа.

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

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

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

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

Локализация — это атрибут продукта, а не лозунг

Локализация данных — одна из самых сильных причин покупать у Cloud.ir. Корпоративные страницы размещают облачную инфраструктуру в дата-центрах ASIATECH в Иране, страница CDN подчёркивает внутренние режимы распространения, а сетевые данные показывают публичный облачный сайт в AS60077 с иранской родительской сетью ASIATECH. Для иранских пользователей и компаний это может означать меньшую задержку, внутренние платёжные процессы, привычный язык поддержки, местную экономику трафика и провайдера, чьи физические объекты близки к целевой аудитории.

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

Собственный регион Cloud.ir для клиентского профиля может быть глобальным, потому что IP-доступность глобальна и облачные клиенты могут находиться где угодно при работающем аккаунте и сетевом пути. Это не то же самое, что заявление о глобальных регионах компании. Публичные продуктовые данные, рассмотренные здесь, наиболее сильно указывают на иранскую инфраструктуру и внутренний парк дата-центров ASIATECH. Если клиенту нужен сервис только в Иране, стоит запросить письменное заявление о локализации вычислений, хранилища, резервных копий, логов и доступа поддержки.

Если клиенту нужна непрерывность в нескольких странах, стоит спросить, обеспечивает ли это сам Cloud.ir или клиенту придётся строить её с другим провайдером.

Локализация также меняет реагирование на инциденты. Внутренний иранский контентный сайт может предпочесть внутреннее поведение CDN Cloud.ir и объекты ASIATECH, потому что большинство пользователей находится рядом с этими путями. Международный SaaS-вендор может беспокоиться о доступе к платежам, санкционных рисках, задержках для зарубежных пользователей, фильтрации маршрутов, разрешении споров и возможности экспортировать данные под давлением.

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

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

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

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

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

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

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

Недостаточно сказать, что у родительской сети много соседей; релевантный вопрос — что происходит на облачной границе.

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

Путь поддержки касается времени и полномочий. Cloud.ir говорит, что клиенты облачных серверов могут отправлять тикеты в любой час. Это лучше, чем узкий канал в рабочие часы, но клиенту всё равно нужны цели эскалации. Кто может изменить маршрут BGP? Кто может разрешить визит к стойке? Кто может восстановить удалённую резервную копию? Кто может отменить приостановку аккаунта? Кто может объяснить юридическое или силовое распоряжение? Если первая линия поддержки может только пересылать запрос, время ремонта включает каждый переход.

Путь миграции — последняя страховочная сеть. Клиент может терпеть более слабые доказательства, если может быстро уйти. Для этого нужны актуальные резервные копии, экспортируемые образы или файлы, документированные процедуры смены IP и DNS, известные TTL, доступ к аккаунту, который сохраняется при биллинговых спорах, и достаточная полоса для перемещения данных. Также нужно избегать скрытого лок-ина: адреса частной сети, которые нельзя воспроизвести, функции хранилища без пути экспорта, правила CDN, которые нельзя воссоздать в другом месте, или снапшоты, которые нельзя скачать.

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

Что покупателю стоит проверить, прежде чем полагаться на Cloud.ir

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

Вторая задача — разнообразие сети. AS60077 видна и легитимна, а AS43754 — существенная родительская сеть. Это хорошая отправная точка. Это не то же самое, что доказательство того, что клиентский трафик переживёт событие на границе AS43754. Спросите об обычном пути, резервном пути, конструкции граничных маршрутизаторов, границе обработки DDoS, практике RPKI и фильтрации маршрутов и о том, может ли Cloud.ir временно анонсировать клиентский префикс или переместить публичный адрес во время инцидента. Для большинства клиентов VPS ответ будет «нет», но вопрос проясняет зависимость.

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

Четвёртая задача — обслуживание и исключения. SLA исключает заранее объявленное обслуживание и критические исправления из расчёта аптайма. Спросите, как объявляется обслуживание, сколько даётся уведомления, может ли аварийная работа происходить без обычного уведомления, может ли клиент выбрать окно и обслуживаются ли несколько ресурсов клиента вместе. Окно обслуживания — это не плохо; неясное окно — плохо.

Пятая задача — непрерывность аккаунта. Поскольку неуплата находится за пределами системы штрафов SLA, производственным покупателям стоит понимать пополнение кошелька, сроки выставления счетов, пороги приостановки, пути обжалования и сохранение данных после приостановки. Это особенно важно для команд за пределами Ирана, команд с задержками закупок и команд, чей доступ к платежам зависит от одного человека. Сбой биллинга может стать предотвратимым даунтаймом.

Шестая задача — выход. Экспортируйте один небольшой образ сервера, восстановите одну резервную копию в чистый инстанс, переведите одну DNS-запись с CDN, воссоздайте в другом месте одну политику файрвола и зафиксируйте время. Эти тесты не обязаны быть большими, чтобы быть показательными. Они показывают, помогают ли абстракции провайдера клиенту восстанавливаться или в основном помогают клиенту оставаться.

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

CLOUD Asre Dadeha Asiatech заслуживает более высокой уверенности, чем компания только с устаревшей записью о маршрутизации. Cloud.ir активен, каталог услуг конкретен, страница цен раскрывает конкретные пакеты ресурсов, SLA публичен, а записи RIPE размещают AS60077 в публичной таблице маршрутизации как AT-CLOUD Asre Dadeha Asiatech. DNS сайта компании указывает в AS60077. У AS60077 видимый адресный парк, и её зависимость от родительской сети AS43754 наблюдаема, а не скрыта.

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

Поэтому правильное прочтение взвешенное. Продукт существует. Сеть видна. Физическая зависимость реальна. Покупатель может разумно рассмотреть Cloud.ir для рабочих нагрузок, которым выгодна близость к иранским дата-центрам, внутренняя инфраструктура ASIATECH и локальная облачная панель управления. Тот же покупатель не должен считать, что ярлык «облако» доказывает мультисайтовую отказоустойчивость, разнообразие маршрутов или бесшовный выход. Это инженерные и контрактные факты, которые нужно получить, проверить и зафиксировать письменно.

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