Lunanode Hosting Inc. продаёт арендуемые мощности, которые по-прежнему зависят от стоек, транзита и ремонтных окон

Резюме

• Lunanode видимо работает: на текущем сайте предлагаются виртуальные машины и хранилище в Торонто, на странице статуса фиксируются инциденты и обслуживание вплоть до 2026 года, а AS394745 остаётся анонсированной, причём в публичных данных маршрутизации видны IPv4- и IPv6-блоки.
• Активные вычислительные мощности сосредоточены, судя по всему, в Торонто. В 2023 году Lunanode закрыла площадки в Монреале и Рубе из-за существенного роста цен в дата-центрах; при этом некоторые старые примеры API до сих пор перечисляют все три региона, и их не следует читать как описание текущих мощностей.
• Устойчивость предоставляется слоями, а не как автоматическое свойство. Тома, снапшоты, плавающие IP-адреса, балансировщики нагрузки, средства контроля размещения и загружаемые образы помогают клиентам спроектировать восстановление, но большинство этих инструментов остаются в пределах той же зоны отказа — Торонто, если только клиент не хранит независимую копию в другом месте.
• Степень доказательности — средняя. Lunanode публикует необычно подробные описания инцидентов и правдоподобные сетевые записи, но не раскрывает публично число стоек, полезную мощность, общий установленный объём вычислений, текущую топологию хранилища, контрактные цели ремонта, глубину складского запаса запчастей или вторую активную вычислительную площадку.

Панель управления облаком не отменяет машинный зал за ней

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

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

Каждый ремонт зависит от человека, запасной детали и доступа к стойке.

Собственный публичный архив Lunanode делает эту цепочку необычно конкретной. На текущейстранице расположенийназван Торонто, сказано, что развёртывание находится в объекте Cogent в Торонто, и описан канал 10 гигабит в секунду, резервируемые аплинки и системы электропитания. Там указаны два процессора Intel Xeon E5-2690 v2 и SSD-хосты с RAID10 на SSD. На связаннойстранице инфраструктурысказано, что клиенты могут выбирать локальные SSD-диски или распределённое блочное хранилище, а виртуальные машины в одном регионе общаются по частной сети 10 гигабит в секунду.

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

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

Торонто — текущий операционный центр тяжести

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

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

История статусовLunanode снимает видимое противоречие. В начале 2023 года компания сообщила, что закрывает Монреаль и Рубе из-за существенного роста цен, установленных дата-центрами, которыми она там пользовалась. Клиентам было сказано до 31 января 2023 года перенести виртуальные машины и привязанные тома в Торонто, запросить помощь или попросить возврат средств, если Торонто не подходит. В более поздней записи говорилось, что оставшиеся ВМ на двух закрывающихся площадках будут перенесены в Торонто. Нынешние страницы сервиса, где указан только Торонто, согласуются с этой историей; примеры API с тремя регионами лучше считать устаревшей документацией.

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

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

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

Lunanode может продавать и обслуживать клиентов во многих странах, эксплуатируя видимую вычислительную платформу в одном городе. Активные физические мощности, показанные публично, не распределены по миру. Глобальная поверхность продаж и многорегиональная инфраструктура — разные вещи.

Низкие цены — результат утилизации, стандартизации и ограничений

Коммерческая привлекательность Lunanode очевидна. На актуальнойстранице ценуказаны небольшие ВМ общего назначения и с оптимизацией по памяти от нескольких долларов США в месяц, конфигурации большего размера и вычислительные тарифы с выделенными ядрами. Блочное и снапшот-хранилище тарифицируется за гигабайт, дополнительные публичные адреса — помесячно, превышение объёма трафика — за гигабайт. Сервис поэтому подходит для личных проектов, небольших сайтов, систем разработки, скромных бизнес-приложений и нагрузок, для которых контракт с крупным облаком не оправдан.

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

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

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

В кластере хранилища может быть сырое дисковое пространство, недоступное для новых данных клиентов, потому что его съедают резервы репликации и восстановления. Канал 10 гигабит — это скорость порта, а не гарантия, что каждая ВМ сможет поддерживать эту скорость до любого получателя.

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

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

Граница объекта видна, но описана лишь частично

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

Это разделение ответственности важно. Lunanode может обслуживать серверы и собственное сетевое оборудование, но не может самостоятельно предотвратить обновление граничного маршрутизатора объекта или восстановить вышедшее из строя устройство апстрима. В сентябре 2024 года Lunanode сообщила, что её серверы и сетевое оборудование оставались под напряжением и работоспособными, тогда как внешняя связь была недоступна из-за проблемы с электропитанием у Cogent, затронувшей сетевое оборудование. Стойки были живы; сервис был недоступен. Клиент, следивший только за состоянием питания ВМ, не заметил бы реального отказа.

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

Резервирование имеет смысл, только если его компоненты достаточно независимы, чтобы пережить рассматриваемый отказ.

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

Сбой 2020 года в Торонто вскрывает более широкую зону отказа. Lunanode сообщила о скачке напряжения в дата-центре Cogent по адресу 245 Consumers Road, перезагрузках серверов и вышедшем из строя блоке распределения питания в одной стойке. На одном из этапов были недоступны три гипервизора и система тома-хранилища. Компания сказала, что у неё было два резервных сервера, и она не смогла бы быстро поднять все три отказавшие системы, если бы ни одна из затронутых машин не загрузилась. Позже она обсуждала улучшенную группировку серверов Ceph и более широкий сетевой мониторинг.

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

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

AS394745 добавляет реальные сетевые данные, но не полную карту маршрутов

Lunanode — это не только бренд за анонимным адресным пространством другой компании. Записи, производные от ARIN, истраница AS394745 на bgp.toolsидентифицируют Lunanode Hosting Inc. как держателя автономной системы 394745. Регистрация датируется декабрём 2015 года, а запись организации — 2014 годом. Публичные данные маршрутизации, запрошенные на 12 июля 2026 года, показывали, что AS анонсирована.

Вид маршрутов небольшой, но заслуживающий доверия.Ответ announced-prefixes для AS394745от RIPEstat за предыдущие две недели показывал 172.81.176.0/21 и IPv6-префикс 2602:ffb6::/36. Егоответ routing-statusна момент запроса сообщал об одном IPv4-префиксе, одном IPv6-префиксе и девяти наблюдаемых соседях. Данные whois, производные от ARIN, связывают 172.81.176.0/21 с Lunanode, а текущий тестовый адрес Lunanode в Торонто попадает в этот блок.

IPv4-маршрут иллюстрирует и границу провайдера.Обзор префикса для тестового адреса в Торонтоот RIPEstat на момент запроса 12 июля показывал, что с покрывающим блоком 172.81.176.0/21 связаны и AS174 (Cogent), и AS394745 (Lunanode). Проверка авторизации источника маршрута для AS394745 по этому /21 была валидной. Смешанная картина источника согласуется с сетью, у которой есть собственная идентичность, но которая остаётся тесно связана с маршрутизацией Cogent. Это не доказательство того, что весь трафик идёт по одному пути, и не раскрывает частные сессии или коммерческие условия.

Пиринг добавляет ещё один элемент. Взаписи PeeringDBLunanode указана открытая политика пиринга, два IPv4-префикса, один IPv6-префикс и действующее соединение 10 гигабит на Toronto Internet Exchange. Там не раскрываются объёмы трафика или географический охват, и для сетевого профиля не указан объект взаимоподключения. PeeringDB размещает порт TorIX в Cologix TOR1. Такое присутствие на публичной бирже может сокращать пути до участвующих сетей и уменьшать часть зависимости от транзита. Его не следует принимать за вторую вычислительную площадку. До порта пиринга в объекте биржи можно довести транспорт от серверов, расположенных в другом месте города.

Вид на bgp.toolsвокруг даты запроса показывал набор известных пиров, включая Hurricane Electric, OVH, Cloudflare, TekSavvy и других. Такие списки демонстрируют наблюдаемые маршрутные смежности; они не доказывают разнообразия платных апстримов, равной достижимости IPv4 и IPv6, контрактных объёмов или производительности переключения при отказе. На той же странице в одной сводке как непосредственно анонсированное показывалось только выделение IPv6, тогда как в детальном политическом виде были пиры по обоим протоколам. RIPEstat показывал IPv4 /21. Различия между коллекторами маршрутов, временем и классификацией — причина использовать несколько представлений, а не объявлять одно из них полной топологией.

Публичный сетевой вывод поэтому умеренный. У Lunanode есть собственная AS, адресные ресурсы, валидные механизмы авторизации источника маршрута, активный порт TorIX и несколько наблюдаемых соседей. Это более сильное доказательство, чем хостинг-сайт без видимой сетевой идентичности. Тем не менее клиентский сервис в Торонто неоднократно зависел от работ в объекте и у апстрима Cogent, а публичные записи не раскрывают контрактную ёмкость транзита, разнообразие физических путей, резервирование граничных устройств или измеренное переключение при отказе.

Сетевые данные подтверждают текущую работу; они не подтверждают утверждение об устойчивости, независимой от города.

Выбор хранилища меняет и производительность, и зону отказа

Lunanode предлагает два концептуально разных места для диска ВМ: локальное хранилище хоста и отсоединяемые блочные тома. Вдокументации по томамсказано, что том можно подключить или отключить, использовать как загрузочное устройство, сохранить после удаления ВМ, преобразовать в образ или из образа и снять с него снапшот. HDD-тома тарифицируются отдельно, а SSD-тома описаны как доступные только в Торонто. На странице «О компании» сказано, что ВМ на томах могут использовать распределённое хранилище Ceph RADOS и автоматически эвакуироваться после аппаратного сбоя.

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

История инцидентов Lunanode содержит примеры обоих сценариев. Сбой питания в июле 2020 года нарушил работу системы тома-хранилища, пока несколько серверов были офлайн. Отключение в сентябре 2023 года в одной стойке Торонто затронуло блочное хранилище и ВМ в этой стойке. Инциденты с локальными дисками в ноябре 2024 года и июле 2025 года привели к длительным периодам проверки файловой системы и к повреждению или потере данных клиентов на небольшом числе ВМ. Это не доказательство того, что один выбор хранилища всегда лучше. Это показывает, что локальная и распределённая схемы отказывают по-разному.

Запись июля 2025 года особенно важна для ответственности клиента. Lunanode сообщила о простое одного SSD-гипервизора в Торонто, длительной проверке файловой системы без ранней оценки сроков восстановления и в итоге о потере данных на четырёх виртуальных машинах из-за повреждения дисков. Затронутым пользователям был предложен кредит на три месяца за простой и на двенадцать месяцев за потерю данных. В ноябре 2024 года выходящий из строя SSD и повреждение файловой системы после длительного ремонта оставили как минимум пять ВМ с повреждёнными дисками. Кредиты могут признать ущерб; они не восстанавливают данные клиента.

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

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

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

Журнал инцидентов показывает реальные пути отказов

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

Инциденты распадаются на несколько повторяющихся категорий.

Отказ объекта и сети апстрима.В мае 2026 года Lunanode сообщила о потере пакетов в Торонто и сказала, что апстрим установил причину. Плановые работы Cogent в апреле и июне 2026 года несли возможный простой. В сентябре 2024 года проблема с питанием у Cogent на несколько часов оставила работающие серверы Lunanode отключёнными от внешнего мира. В 2023 году одна стойка в Торонто потеряла питание после проблемы с автоматом. Такие события затрагивают сразу многих клиентов и могут сделать здоровые ВМ недоступными.

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

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

Отказ управляющей плоскости и вспомогательных сервисов.Приостановка домена в 2024 году с участиемlndyn.comпрервала сервисы, пока Lunanode не перенесла домены от регистратора. Другое уведомление 2024 года сообщило, что ошибка почтового мониторинга отправила некоторым пользователям уведомления, предназначенные другим. Lunanode также признала, что, когда сеть Торонто была офлайн, email-оповещения не отправлялись, потому что её почтовый сервер находится в Торонто, и рекомендовала SMS, голосовые или HTTP-оповещения. Отключение может поэтому нарушить механизм, который сообщает об отключении.

Повреждение данных и длительный ремонт.Инциденты с SSD-гипервизорами 2024 и 2025 годов показывают, что возврат сервера в онлайн не гарантирует целостность каждого гостевого диска. Проверки файловой системы могут занять много часов, а повреждённые диски ВМ могут потребовать восстановления клиентом. Время восстановления и точка восстановления — разные вещи: питание может вернуться раньше, чем данные станут пригодными, и восстановленный сервис может всё равно потерять недавние записи.

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

Архив не следует превращать в примитивный показатель отказов. В нём нет полного знаменателя — числа активных ВМ, количества затронутых клиентов по большинству событий — или гарантии, что публикуется каждый мелкий инцидент. Старые записи могут удаляться. В некоторых уведомлениях есть противоречивые даты или опечатки. В текущем разделе, например, есть заголовок о сети Торонто от 18 мая 2026 года с обновлениями от 13 мая. Это ослабляет точную хронологию, но не более широкое доказательство того, что в мае происходили потеря пакетов и вмешательство апстрима.

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

Резервирование доступно слоями, в основном в пределах одного города

Lunanode даёт клиентам несколько строительных блоков для устойчивости. Функцияплавающих IP-адресовпозволяет перемещать внешний адрес между ВМ. Сервисбалансировщиков нагрузкиможет распределять TCP-, HTTP- или HTTPS-трафик между несколькими машинами и убирать отказавшего участника после того, как мониторинг обнаружит проблему. Группы безопасности ичастные сетиподдерживают многоуровневые приложения. API ВМ предоставляет опцию группы размещения (affinity), а в ответе есть идентификатор физического хоста, что позволяет клиентам добиваться размещения на разных гипервизорах.

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

Ни одна из них автоматически не переживает потерю Торонто. Две ВМ на разных хостах могут делить одну стойку, распределение питания, кластер хранилища, граничный маршрутизатор, объект и апстрим. Балансировщик в том же регионе может отказать вместе со своими бэкендами. Плавающий IP полезен, только пока региональная сеть его маршрутизирует. Том может пережить удаление ВМ, оставаясь недоступным во время отказа плоскости хранилища или объекта. Группы размещения могут разнести вычислительные ресурсы, не создавая географического разделения.

Клиентам поэтому нужно подбирать схему под тот отказ, который для них важен. Для любительского сайта могут быть достаточны снапшот и возможность пересоздать ВМ. Для бизнес-сайта уместны отдельные инстансы приложения, проверенная резервная копия базы данных и внешнее управление DNS. Для сервиса со строгими требованиями непрерывности вторая копия должна находиться у другого провайдера или на другой независимо управляемой площадке, с достаточным зарезервированным объёмом для запуска нагрузки.

Слово «резервируемый» всегда должно вызывать четыре вопроса: резервирование от чего, где оно расположено, кто им управляет и когда оно тестировалось? Заявление Lunanode о резервируемых аплинках может защищать от отказа одного канала. Оно может не защищать от обслуживания Cogent или проблемы масштаба всего объекта. RAID10 защищает от некоторых отказов дисков. Он не заменяет резервную копию и не предотвратил каждое повреждение в архиве. Репликация Ceph защищает от отказов некоторых узлов. На неё всё равно может повлиять коррелированный отказ питания или участников хранилища.

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

Поддержка, биллинг и состояние аккаунта — тоже инфраструктурные зависимости

При проблемах с инфраструктурой Lunanode просит клиентов открывать тикет в поддержку. Еёсервис мониторингаподдерживает проверки HTTP, истечения TLS-сертификатов, ICMP, TCP и DNS, с уведомлениями по email, SMS, телефону и вебхукам. Это практичные инструменты, особенно когда адрес оповещения находится за пределами сервиса в Торонто. Инцидент с почтой 2024 года показывает, почему независимый канал оповещения важен.

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

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

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

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

Канадская локализация полезна, но это не полный ответ на вопрос о суверенитете данных

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

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

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

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

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

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

Что повысило бы степень доказательности

Публичный след Lunanode не пуст. Он сильнее, чем можно предположить при беглом чтении её скромного маркетингового присутствия. У компании есть действующие страницы продуктов и цен, актуальные инструкции по выделению ресурсов в Торонто, подробные уведомления о статусе вплоть до 2026 года, активное адресное пространство, AS394745, анонсы IPv4 и IPv6, присутствие на TorIX и давно работающая панель управления. Это убедительные признаки действующего небольшого облачного провайдера.

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

Данные, которые повысили бы степень, не обязаны раскрывать чувствительные детали. Lunanode могла бы опубликовать актуальную архитектурную заметку, различающую зоны отказа объекта, стойки, хоста и хранилища; подтвердить, занимают ли рабочие нагрузки клиентов более одной зоны питания; указать классы разнообразия апстримов; описать, как группы размещения соотносятся со стойками; описать текущее поведение репликации томов и эвакуации; и привести агрегированные метрики доступности и инцидентов.

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

Для клиента непосредственные вопросы практические. ВМ находится на локальном диске или на томе? Находятся ли реплики на разных хостах и в разных стойках? Переживёт ли приложение отказ хоста? Находится ли резервная копия вне Lunanode и вне Торонто? Можно ли восстановиться на другом гипервизоре или у другого провайдера? Продолжает ли мониторинг оповещать, когда Торонто не может отправлять почту? Кто следит за кредитом аккаунта? Что произойдёт, если регион будет выведен? Какой объём данных должен пересечь сеть при восстановлении и сколько времени занял последний тест?

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

Центральный инфраструктурный факт прост: Lunanode продаёт гибкий интерфейс к реальным машинам в реальном объекте в Торонто. Её собственная история показывает ремонты, зависевшие от резервных серверов, совместимых блоков питания, проверок файловой системы, кворума хранилища, специалистов апстрима и миграции клиентов. Покупатели могут использовать снапшоты, тома, балансировщики, плавающие адреса и мониторинг платформы, чтобы строить устойчивость.

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