Resumen
- Lunanode está visiblemente operativa: su sitio actual ofrece máquinas virtuales y almacenamiento en Toronto, su página de estado registra incidentes y mantenimiento hasta 2026, y AS394745 sigue anunciada con espacio IPv4 e IPv6 visible en datos de enrutamiento públicos.
- La huella de cómputo activa parece concentrarse en Toronto. Lunanode cerró Montreal y Roubaix en 2023 tras aumentos sustanciales en los costos del centro de datos, mientras que algunos ejemplos antiguos de API aún listan las tres regiones y no deben interpretarse como capacidad actual.
- La resiliencia está disponible en capas, no como una propiedad automática. Los volúmenes, las instantáneas, las IPs flotantes, los balanceadores de carga, los controles de afinidad y las imágenes descargables ayudan a los clientes a diseñar la recuperación, pero la mayoría de esos controles permanecen dentro del mismo dominio de falla de Toronto a menos que el cliente mantenga una copia independiente en otro lugar.
- El nivel de evidencia es Medio. Lunanode publica detalles de incidentes inusualmente útiles y expone registros de red creíbles, pero no divulga públicamente la cantidad de racks, la potencia utilizable, el cómputo instalado total, la topología de almacenamiento actual, los objetivos de reparación contratados, la profundidad del hardware de repuesto ni una segunda región de cómputo activa.
Un panel de control en la nube no elimina la sala que hay detrás
La oferta de Lunanode es reconociblemente un servicio en la nube en lugar de un servidor alquilado simple con un inicio de sesión. Lapágina de acerca dede la empresa describe una plataforma basada en OpenStack y KVM, con máquinas virtuales, volúmenes en bloque, instantáneas en vivo, direcciones IP flotantes, redes virtuales, scripts de inicio, monitoreo y una API. Supágina de máquinas virtualesdivide el servicio en planes de propósito general, optimizados para memoria y optimizados para cómputo, y dice que las instancias se facturan por hora. Un cliente puede crear, redimensionar, suspender, reimagear, rescatar y eliminar máquinas sin esperar una orden de servidor físico.
Esa abstracción es real y valiosa. Permite a una pequeña empresa de software alquilar una fracción de un servidor, permite a un administrador convertir una compra de capital en un gasto operativo, y permite a un proyecto liberar cómputo cuando ya no es necesario. También hace que la dependencia física sea fácil de pasar por alto. Cada núcleo virtual se asigna a un zócalo de procesador en un chasis particular. Cada disco local se asigna a unidades y un controlador. Cada volumen en bloque depende de nodos de almacenamiento y la red entre ellos.
Cada dirección pública depende de una ruta, un dispositivo de borde, un upstream y la energía de la instalación. Cada reparación depende de una persona, una pieza de repuesto y acceso al rack.
El propio registro público de Lunanode hace que esa cadena sea inusualmente concreta. Lapágina de ubicacionesactual nombra Toronto, dice que el despliegue está en las instalaciones de Cogent Toronto, y describe una red de 10 gigabits por segundo, enlaces redundantes y sistemas de suministro de energía. Nombra procesadores duales Intel Xeon E5-2690 v2 y SSD RAID10 en nodos host SSD. Lapágina de infraestructurarelacionada dice que los clientes pueden elegir discos SSD locales o almacenamiento en bloque distribuido, y que las VM en la misma región se comunican a través de una red privada de 10 gigabits por segundo.
Esas declaraciones identifican el tipo de maquinaria debajo del servicio. No revelan cuánto está instalado, cuánto está libre, cuántos racks ocupa, cuánta energía está reservada, cuántas generaciones de hosts permanecen en servicio, o si cada carga de trabajo recibe la misma ruta de almacenamiento y red. El procesador nombrado en la página de ubicaciones data de una generación de servidores anterior. Eso no lo hace inutilizable; el hardware antiguo confiable puede ser económicamente sensato para alojamiento de bajo costo. Sí significa que un comprador debe distinguir un tipo de host claramente especificado de una flota continuamente renovada.
La nube, en este caso, es una interfaz operativa útil sobre un despliegue finito en Toronto. Lunanode controla su plataforma de clientes, la programación de VM, el servicio de almacenamiento, la configuración de red y las decisiones de soporte. Cogent controla condiciones importantes de la instalación y upstream. Los proveedores de hardware determinan la disponibilidad de piezas. El cliente controla la arquitectura de la aplicación, las copias de seguridad independientes y la decisión de mantener capacidad en otro lugar. La confiabilidad surge de los cuatro límites, no solo del panel de control.
Toronto es el centro de gravedad operativo actual
El hecho más importante en la historia actual de infraestructura de Lunanode es la concentración geográfica. Las páginas de marketing actuales dicen que la plataforma en la nube está en Toronto. De manera más decisiva, ladocumentación de la API de máquinas virtualesdice que el parámetro de región para la creación de VM debe sertoronto. La documentación actual de grupos de seguridad también dice que la región de un nuevo grupo debe ser Toronto. Estas son señales actuales más fuertes que una lista antigua de nombres de lugares porque describen lo que la interfaz de aprovisionamiento acepta ahora.
Otras páginas de Lunanode conservan rastros históricos. Lapágina de API de planes y regionesincluye una respuesta de ejemplo con Montreal, Roubaix y Toronto. Lapágina de API de red virtualtambién muestra esos tres nombres. La página de instantáneas aún describe la replicación entre ubicaciones en la nube. Ninguna de esas páginas, por sí sola, establece que los clientes puedan aprovisionar nueva capacidad de producción en Montreal o Roubaix en julio de 2026.
Elhistorial de estadode Lunanode resuelve el conflicto aparente. A principios de 2023, la empresa dijo que estaba cerrando Montreal y Roubaix debido a aumentos sustanciales de costos impuestos por los centros de datos que utilizaba allí. Se les dijo a los clientes que migraran las máquinas virtuales y los volúmenes adjuntos a Toronto antes del 31 de enero de 2023, solicitaran asistencia o buscaran un reembolso si Toronto no era adecuado. Una entrada posterior dijo que las VM restantes en las dos ubicaciones en cierre serían migradas a Toronto. Las páginas de servicio actuales solo en Toronto son consistentes con esa historia; los ejemplos de API de tres regiones son mejor tratados como documentación obsoleta.
El cierre es más que una nota histórica al pie. Revela una ruta de falla en el contrato del proveedor. Lunanode no necesitó un incendio, inundación o colapso técnico para perder dos regiones. Un insumo comercial cambió: las instalaciones se volvieron sustancialmente más costosas. La empresa respondió retirando capacidad y consolidando cargas de trabajo. Esa es una decisión comercial racional, pero ilustra por qué la infraestructura alquilada nunca es independiente de los arrendamientos, los precios de la energía, los acuerdos de tránsito y la economía de mantener capacidad ligeramente utilizada disponible.
Para los clientes, el efecto depende de la arquitectura. Una aplicación sin estado con automatización de configuración y una copia externa de sus datos puede ser movida. Una VM con disco local de larga duración, una dirección fija, cambios de software no documentados y ninguna restauración probada puede convertirse en un proyecto de migración. Un cliente europeo que seleccionó Roubaix por latencia o localidad no podría tratar a Toronto como un sustituto equivalente. Un cliente de Montreal podría permanecer en Canadá pero aún enfrentar diferente latencia, interconexión y geografía de desastres.
El proveedor ofreció asistencia de migración y créditos, pero el cliente aún asumió el trabajo a nivel de aplicación y la decisión sobre si Toronto cumplía con sus necesidades.
Lunanode puede vender y atender a clientes en muchos países mientras opera la plataforma de cómputo visible en una ciudad. La capacidad física activa mostrada públicamente no está distribuida globalmente. Una superficie de ventas global y una infraestructura multirregional son cosas diferentes.
Los precios bajos se producen por la utilización, estandarización y límites
El atractivo comercial de Lunanode es directo. Supágina de preciosen vivo enumera VM pequeñas de propósito general y orientadas a memoria desde unos pocos dólares estadounidenses por mes, configuraciones más grandes y planes optimizados para cómputo con núcleos dedicados. Precia el almacenamiento en bloque y de instantáneas por gigabyte, las direcciones públicas adicionales por mes y el ancho de banda excedente por gigabyte. El servicio puede por lo tanto ajustarse a proyectos personales, sitios web pequeños, sistemas de desarrollo, aplicaciones comerciales modestas y cargas de trabajo que no justifican un contrato de nube grande.
El precio de entrada bajo no es el costo de una máquina física dedicada. Es el precio de una participación en un grupo administrado. El proveedor compra servidores, espacio en rack, puertos de red, direcciones, medios de almacenamiento y tiempo del personal, luego distribuye esos costos fijos y semifijos entre los clientes. La rentabilidad depende de la ocupación y la utilización: suficientes clientes deben pagar por la flota instalada, mientras que no todos los clientes pueden demandar cada recurso asignado a plena intensidad al mismo instante a menos que el plan y el diseño de capacidad lo permitan.
Lunanode hace visibles algunos de esos controles. Los planes de propósito general y memoria usan núcleos virtuales; los planes optimizados para cómputo anuncian núcleos dedicados. El ancho de banda se agrupa por cuenta y región, contando el tráfico entrante y saliente. Lostérminos de serviciodicen que el ancho de banda excedente se factura y los clientes pueden elegir apagar las VM antes de exceder su grupo. La suspensión libera CPU y memoria mientras retiene almacenamiento y direcciones a un costo menor. Estos no son meros detalles de facturación. Son mecanismos para convertir equipos finitos en capacidad vendible y de apariencia elástica.
La capacidad instalada y la capacidad utilizable no son, por lo tanto, lo mismo. Un rack puede contener una suma nominal de núcleos de procesador y terabytes, pero algunos deben reservarse para sobrecarga del sistema, replicación de almacenamiento, dispositivos fallados, mantenimiento, desequilibrio de hosts y margen para clientes. Un servidor que espera como repuesto está instalado pero no genera ingresos normales. Un rack casi lleno aún puede tener espacio unitario nominal pero carecer de un margen de potencia seguro.
Un clúster de almacenamiento puede tener espacio en disco bruto que no está disponible para nuevos datos de clientes porque las reservas de replicación y recuperación lo consumen. Un enlace de 10 gigabits es una velocidad de puerto, no una garantía de que cada VM pueda mantener esa tasa hacia cualquier destino.
Ninguna página pública de Lunanode cuantifica estos márgenes. La página de precios en vivo proporciona un catálogo, no una declaración de inventario. El panel de control puede mostrar disponibilidad de planes a un usuario autenticado, pero los materiales públicos no dicen cuántas instancias de cada tipo pueden crearse, cómo se distribuye la capacidad entre los hosts, o qué umbral desencadena una compra de hardware. Los compradores deben, por lo tanto, leer los precios como ofertas válidas en el momento del pedido, no como prueba de expansión ilimitada.
Este marco económico también explica la contracción de región en 2023. Un proveedor pequeño puede ofrecer capacidad económica porque evita los gastos generales de un patrimonio de hiperescala. La misma disciplina puede hacer que una ubicación ligeramente utilizada o recientemente costosa sea difícil de mantener. El cómputo barato por hora y la geografía de repuesto permanente tiran en direcciones opuestas. Un cliente que necesita ambos debe pagar por capacidad independiente y probarla, en lugar de asumir que el precio base de la VM incluye un segundo sitio inactivo.
El límite de la instalación es visible pero solo parcialmente descrito
Lunanode dice que su ubicación en Toronto está dentro de una instalación de Cogent. Sus avisos de estado identifican repetidamente a Cogent como el centro de datos o la parte upstream involucrada en el trabajo de red. Un aviso de junio de 2026 advirtió sobre posible tiempo de inactividad de red por actualizaciones de software en enrutadores de borde realizadas por el centro de datos. Un aviso de abril de 2026 describió un mantenimiento similar. Un incidente de enero de 2026 dijo que el upstream parecía estar realizando mantenimiento programado mientras Lunanode investigaba una interrupción en Toronto.
Esta división de responsabilidades importa. Lunanode puede mantener servidores y su propio equipo de red, pero no puede evitar independientemente una actualización del enrutador de borde de la instalación o restaurar un dispositivo upstream fallado. En septiembre de 2024, Lunanode informó que sus servidores y equipo de red permanecían encendidos y funcionales mientras la conectividad externa estaba fuera de línea debido a un problema de energía de Cogent que afectaba al equipo de red. Los racks estaban vivos; el servicio era inalcanzable. Un cliente que observara solo el estado de energía de la VM habría pasado por alto la falla real.
El material público respalda afirmaciones de enlaces ascendentes redundantes y sistemas de suministro de energía a nivel de diseño. No documenta las rutas físicas, los operadores, los dominios de disyuntores, el comportamiento de transferencia automática o la prueba de conmutación por error más reciente. Las fuentes de alimentación redundantes del servidor aún pueden alimentar la misma ruta de distribución fallada. Dos enlaces ascendentes aún pueden terminar en un dispositivo o atravesar un dominio de mantenimiento. Un segundo enrutador aún puede depender de la misma sala o upstream.
La redundancia es significativa solo cuando sus componentes son lo suficientemente independientes para sobrevivir a la falla que se considera.
El historial de estado muestra tanto el valor como los límites de los repuestos. En marzo de 2023, Lunanode dijo que un hipervisor de Toronto sufrió una falla de hardware en el plano de disco y el servicio se restauró después de intercambiar discos en un servidor físico de repuesto. En febrero de 2023, un reemplazo de fuente de alimentación se complicó porque el repuesto almacenado no tenía el firmware compatible, por lo que ambas fuentes tuvieron que cambiarse durante un apagón. Esas entradas son evidencia concreta de capacidad de reparación práctica.
También muestran que poseer una pieza de repuesto no es lo mismo que tener una reparación inmediatamente compatible.
Una interrupción en Toronto en 2020 expone un dominio de falla más amplio. Lunanode informó una sobretensión en el centro de datos de Cogent en 245 Consumers Road, reinicios de servidores y una unidad de distribución de energía fallada en un rack. Tres hipervisores y el sistema de almacenamiento de volúmenes estaban fuera de línea en una etapa. La empresa dijo que tenía dos servidores de repuesto y no habría podido poner en línea rápidamente los tres sistemas fallados si ninguna de las máquinas afectadas hubiera arrancado. Posteriormente discutió una mejor agrupación de servidores Ceph y un monitoreo de red más extenso.
Ese nivel de divulgación es útil porque nombra el recurso finito detrás de la recuperación: dos repuestos, tres máquinas afectadas y un problema de quórum de almacenamiento.
La evidencia pública no establece que el mismo recuento de repuestos, diseño de rack o agrupación de Ceph exista en 2026. Sería incorrecto convertir un informe de incidente de seis años de antigüedad en un inventario actual. La lección duradera es que la recuperación de Lunanode ha dependido de la topología en el sitio, piezas compatibles y la cantidad de máquinas afectadas a la vez. Esas restricciones siguen siendo relevantes para cualquier proveedor, incluso cuando el equipo exacto cambia.
AS394745 agrega evidencia de red real, no un mapa de ruta completo
Lunanode no es solo una marca detrás del espacio de direcciones anónimo de otra empresa. Los registros derivados de ARIN y lapágina de AS394745 en bgp.toolsidentifican a Lunanode Hosting Inc. como el titular del sistema autónomo 394745. El registro data de diciembre de 2015, y el registro de organización data de 2014. Los datos de enrutamiento público consultados para el 12 de julio de 2026 mostraron el AS anunciado.
La vista de ruta es pequeña pero creíble. Larespuesta de prefijos anunciados de RIPEstat para AS394745mostró 172.81.176.0/21 y el prefijo IPv6 2602:ffb6::/36 en las dos semanas anteriores. Surespuesta de estado de enrutamientoinformó un prefijo IPv4, un prefijo IPv6 y nueve vecinos observados en el momento de la consulta. Los datos whois derivados de ARIN asocian 172.81.176.0/21 con Lunanode, y la dirección de prueba actual de Toronto de Lunanode cae dentro de ese bloque.
La ruta IPv4 también ilustra el límite del proveedor. Lavisión general del prefijo de RIPEstat para la dirección de prueba de Torontomostró tanto AS174, Cogent, como AS394745, Lunanode, asociados con el 172.81.176.0/21 que lo cubre en el momento de la consulta del 12 de julio. Una verificación de autorización de origen de ruta para AS394745 en ese /21 era válida. La vista de origen mixto es consistente con una red que tiene su propia identidad mientras permanece estrechamente acoplada al enrutamiento de Cogent. No es prueba de que todo el tráfico siga una ruta, ni revela sesiones privadas o términos comerciales.
La interconexión agrega otra pieza. Elregistro de PeeringDB de Lunanodeenumera una política de interconexión abierta, dos prefijos IPv4, un prefijo IPv6 y una conexión operativa de 10 gigabits en el Toronto Internet Exchange. No divulga niveles de tráfico o alcance geográfico, y no enumera ninguna instalación de interconexión para el perfil de red. PeeringDB coloca el puerto TorIX en Cologix TOR1. Esa presencia de intercambio público puede acortar rutas a redes participantes y reducir parte de la dependencia de tránsito. No debe confundirse con un segundo sitio de cómputo. Se puede llegar a un puerto de interconexión en una instalación de intercambio mediante transporte desde servidores ubicados en otra parte de la ciudad.
Lavista de bgp.toolsmostró un conjunto de pares conocidos que incluían a Hurricane Electric, OVH, Cloudflare, TekSavvy y otros alrededor de la fecha de consulta. Tales listas demuestran adyacencias de enrutamiento observadas; no establecen diversidad de upstream pagado, alcanzabilidad igual de IPv4 e IPv6, capacidad contratada o rendimiento de conmutación por error. La misma página mostró solo la asignación IPv6 como originada directamente en un resumen, mientras que su vista de política detallada incluía pares para ambos protocolos. RIPEstat mostró el IPv4 /21. Las diferencias entre colectores de rutas, tiempos y clasificación son una razón para usar varias vistas, no una razón para declarar una de ellas como una topología completa.
La conclusión de red pública es, por lo tanto, moderada. Lunanode tiene su propio AS, recursos de direcciones, controles de origen de ruta válidos, un puerto TorIX activo y múltiples vecinos observados. Eso es evidencia más fuerte que un sitio de alojamiento sin identidad de red visible. Sin embargo, el servicio orientado al cliente en Toronto ha dependido repetidamente de las instalaciones de Cogent y el trabajo upstream, y los registros públicos no divulgan la capacidad de tránsito contratada, la diversidad de rutas físicas, la redundancia de dispositivos de borde o la conmutación por error medida.
La evidencia de red respalda la operación actual; no respalda una afirmación de resiliencia independiente de la ciudad.
La elección de almacenamiento cambia tanto el rendimiento como el dominio de falla
Lunanode ofrece dos lugares conceptualmente diferentes para el disco de una VM: almacenamiento local del host y volúmenes en bloque desmontables. Ladocumentación de volúmenesdice que un volumen puede adjuntarse o desadjuntarse, usarse como dispositivo de arranque, retenerse después de eliminar una VM, convertirse hacia o desde una imagen, y capturarse en instantáneas. Los volúmenes HDD tienen un precio separado, mientras que los volúmenes SSD se describen como solo en Toronto. La página de acerca de dice que las VM respaldadas por volúmenes pueden usar almacenamiento distribuido Ceph RADOS y pueden evacuarse automáticamente después de una falla de hardware.
La compensación es importante. Un SSD local puede ofrecer una ruta directa y económica, pero la VM depende en gran medida de los discos, el controlador y el sistema de archivos de su host. Mover la carga de trabajo puede requerir copiar o trasplantar el almacenamiento. Un volumen distribuido puede separar los datos de un solo host de cómputo y facilitar el inicio de la VM en otro lugar. También introduce un plano de almacenamiento compartido. Si suficientes nodos de almacenamiento, enlaces de red o dominios de energía fallan juntos, muchas VM respaldadas por volúmenes pueden verse afectadas a la vez.
El historial de incidentes de Lunanode contiene ejemplos de ambos patrones. El evento de energía de julio de 2020 afectó el sistema de almacenamiento de volúmenes mientras varios servidores estaban fuera de línea. Una interrupción de septiembre de 2023 en un rack de Toronto afectó el almacenamiento en bloque y las VM en ese rack. Incidentes de disco local en noviembre de 2024 y julio de 2025 llevaron a largos períodos de reparación del sistema de archivos y corrupción o pérdida de datos del cliente en un pequeño número de VM. Estos no son evidencia de que una opción de almacenamiento sea siempre superior.
Muestran que los diseños locales y distribuidos fallan de manera diferente.
La entrada de julio de 2025 es especialmente relevante para la responsabilidad del cliente. Lunanode informó tiempo de inactividad en un hipervisor SSD de Toronto, reparación extendida del sistema de archivos sin estimación de restauración temprana, y finalmente la pérdida de datos en cuatro máquinas virtuales debido a corrupción de disco. Ofreció a los usuarios afectados tres meses de crédito por el tiempo de inactividad y doce meses de crédito por la pérdida de datos. En noviembre de 2024, un SSD fallido y corrupción del sistema de archivos dejaron al menos cinco VM con discos corruptos después de una reparación extendida.
Los créditos pueden reconocer el daño; no reconstruyen los datos del cliente.
Los términos del proveedor hacen explícito el límite: existe funcionalidad de instantáneas, pero Lunanode no realiza copias de seguridad automáticas de los datos del cliente y rechaza responsabilidad por la pérdida de datos. Lapágina de instantáneasdice que las instantáneas pueden tomarse mientras una VM está en línea, usarse para crear o reimagear VM, y descargarse desde el panel. Esa última capacidad es una de las características de resiliencia más importantes porque una imagen descargada puede salir del dominio de falla inmediato del proveedor.
Una instantánea mantenida solo en el mismo entorno de Toronto sigue expuesta a pérdida de cuenta, falla del plano de control, interrupción de la instalación y contracción del proveedor. La referencia de la página a replicar instantáneas entre ubicaciones en la nube refleja el servicio multirregional anterior y no debe asumirse que proporciona separación geográfica actual. Un comprador necesita verificar qué destino está disponible ahora. Si Toronto es la única región activa, una copia de seguridad independiente necesita otro proveedor de almacenamiento, otro sitio o medios controlados por el cliente.
Las instantáneas también tienen límites de aplicación. Una instantánea de disco tomada mientras una base de datos está ocupada puede ser consistente ante fallos en lugar de consistente a nivel de transacción a menos que la aplicación se ponga en reposo o coordine su propia copia de seguridad. Una imagen descargable puede ser inútil si nadie prueba la restauración, registra las claves de cifrado, captura los servicios externos o sabe cómo adaptar la configuración de red en otro host. El panel de control proporciona primitivas útiles. El cliente debe convertirlas en un diseño de recuperación.
El registro de incidentes muestra las rutas de falla reales
La página de estado de Lunanode es una de las partes más fuertes de su evidencia pública. Identifica el trabajo actual y planificado, nombra los hipervisores afectados, describe algunas causas y a menudo registra el progreso de la restauración. La página dice que las entradas de más de seis meses pueden ser eliminadas, aunque un historial sustancial permanece visible. No es un informe de tiempo de actividad certificado, pero es más informativo que promesas genéricas de confiabilidad.
Los incidentes caen en varias categorías recurrentes.
Falla de la instalación y de la red upstream.En mayo de 2026, Lunanode informó pérdida de paquetes en Toronto y dijo que el upstream había identificado la causa. El trabajo planificado de Cogent en abril y junio de 2026 conllevaba posible tiempo de inactividad. En septiembre de 2024, un problema de energía de Cogent dejó los servidores encendidos de Lunanode desconectados del mundo exterior durante horas. En 2023, un rack de Toronto perdió energía después de un problema con un disyuntor. Estos eventos afectan a muchos clientes a la vez y pueden hacer que las VM saludables sean inalcanzables.
Falla de hardware del hipervisor.El archivo registra discos fallados, controladores RAID, fuentes de alimentación, módulos de memoria y errores anormales del host. Algunas interrupciones duraron minutos; otras requirieron reparación prolongada. Una plataforma de virtualización puede mover o recrear una VM solo si su almacenamiento, programador, cómputo de repuesto y ruta de red permanecen disponibles. Una VM con disco local está especialmente vinculada al host físico a menos que los datos ya hayan sido copiados a otro lugar.
Falla de almacenamiento compartido.El evento de energía de 2020 y la interrupción del rack de 2023 afectaron el almacenamiento en bloque. El almacenamiento distribuido reduce la dependencia de un solo disco o host, pero un problema correlacionado de energía, red o agrupación puede eliminar suficientes miembros como para interrumpir el servicio. Esta es la diferencia entre redundancia de componentes e independencia del sistema.
Falla del plano de control y del servicio auxiliar.Una suspensión de dominio en 2024 que involucró alndyn.cominterrumpió los servicios hasta que Lunanode movió los dominios fuera del registrador. Otro aviso de 2024 dijo que un error de correo electrónico de monitoreo envió a algunos usuarios notificaciones destinadas a otros. Lunanode también reconoció que cuando la red de Toronto estaba fuera de línea, las alertas por correo electrónico no se enviaban porque su servidor de correo estaba en Toronto, y recomendó alertas por SMS, voz o HTTP. Una interrupción puede, por lo tanto, afectar el mecanismo utilizado para informar la interrupción.
Corrupción de datos y reparación extendida.Los incidentes de hipervisor SSD de 2024 y 2025 muestran que un servidor que vuelve a un estado en línea no garantiza que cada disco invitado esté intacto. Las comprobaciones del sistema de archivos pueden llevar muchas horas, y los discos VM dañados pueden requerir restauración por parte del cliente. El tiempo de recuperación y el punto de recuperación son separados: la energía puede volver antes de que los datos sean utilizables, y un servicio restaurado puede haber perdido escrituras recientes.
Falla comercial de ubicación.Montreal y Roubaix cerraron porque los costos de las instalaciones aumentaron. Esto no se muestra normalmente en un gráfico de estado técnico, sin embargo, puede tener el mayor efecto a largo plazo porque una ubicación entera desaparece. Los clientes tuvieron aviso y opciones de migración, pero no pudieron preservar la región simplemente reiniciando.
El archivo no debe convertirse en una tasa simplista de interrupciones. No proporciona un denominador completo, el número de VM activas, el recuento de clientes afectados para la mayoría de los eventos, o una garantía de que cada incidente menor se publica. Las entradas más antiguas pueden ser eliminadas. Algunos avisos contienen fechas inconsistentes o errores tipográficos. La sección actual, por ejemplo, incluye un encabezado de redes de Toronto fechado el 18 de mayo de 2026 con actualizaciones fechadas el 13 de mayo.
Eso debilita la cronología precisa pero no la evidencia más amplia de que ocurrieron pérdida de paquetes e intervención upstream en mayo.
Tampoco debe confundirse la franqueza con una mala operación. Los proveedores pequeños pueden parecer más propensos a fallas que competidores silenciosos simplemente porque describen lo que sucedió. Las entradas de Lunanode muestran técnicos reemplazando piezas, moviendo discos, monitoreando reparaciones y ofreciendo créditos. El uso correcto del registro es identificar mecanismos de falla y preguntar cómo se mitigan ahora, no pretender que los recuentos de incidentes públicos por sí solos predicen la próxima interrupción.
La redundancia está disponible en capas, principalmente dentro de una ciudad
Lunanode proporciona a los clientes varios bloques de construcción para la resiliencia. Lacaracterística de IP flotantepermite que una dirección externa se mueva entre VM. Elservicio de balanceador de cargapuede distribuir tráfico TCP, HTTP o HTTPS entre varias máquinas y eliminar un miembro fallido después de que el monitoreo detecte problemas. Los grupos de seguridad y lasredes privadasadmiten aplicaciones en capas. La API de VM expone una opción de grupo de afinidad, y su respuesta incluye un identificador de host físico, lo que permite a los clientes buscar colocación en hipervisores distintos.
Cada característica aborda una falla particular. Dos servidores de aplicaciones en diferentes hipervisores pueden sobrevivir a un bloqueo de host. Una dirección flotante puede reducir los cambios de red necesarios para activar un reemplazo. Un balanceador de carga puede dejar de enviar solicitudes a un miembro no saludable. El arranque respaldado por volumen puede separar los datos de un host de cómputo fallado. El monitoreo puede notificar a un operador antes de que un usuario informe el problema.
Ninguno sobrevive automáticamente a la pérdida de Toronto. Dos VM en diferentes hosts pueden compartir el mismo rack, distribución de energía, clúster de almacenamiento, enrutador de borde, instalación y upstream. Un balanceador de carga en la misma región puede fallar con sus backends. Una IP flotante es útil solo mientras la red regional aún la enruta. Un volumen puede sobrevivir a la eliminación de una VM mientras permanece no disponible durante una interrupción del plano de almacenamiento o de la instalación. La afinidad puede distribuir la colocación de cómputo sin crear separación geográfica.
Los clientes necesitan, por lo tanto, hacer coincidir el diseño con la falla que les importa. Para un sitio de hobby, una instantánea y la capacidad de recrear una VM pueden ser suficientes. Para un sitio web de negocios, instancias de aplicación separadas, una copia de seguridad de base de datos probada y control de DNS externo pueden ser apropiados. Para un servicio con requisitos estrictos de continuidad, la segunda copia debe estar con otro proveedor o en otro sitio operado independientemente, con suficiente capacidad reservada para iniciar la carga de trabajo.
La palabra "redundante" siempre debería invitar a cuatro preguntas: redundante contra qué, ubicado dónde, controlado por quién, y probado cuándo. La afirmación de Lunanode de enlaces ascendentes redundantes puede proteger contra un enlace fallido. Puede no proteger contra el mantenimiento de Cogent o un problema de red a nivel de instalación. RAID10 protege contra algunas fallas de disco. No reemplaza una copia de seguridad y no previno cada evento de corrupción en el archivo. La replicación de Ceph protege contra algunas fallas de nodo. Aún puede verse afectada cuando la energía correlacionada o los miembros de almacenamiento fallan.
La recuperación también depende de la capacidad utilizable. La evacuación automática requiere un host sobreviviente con suficiente CPU y memoria. Restaurar desde una instantánea requiere suficiente almacenamiento y tiempo. Mover una imagen grande fuera del sitio depende del ancho de banda. Reemplazar un host fallado requiere inventario compatible. El registro público no dice cuánto margen mantiene Lunanode para estas operaciones, por lo que los clientes con objetivos de recuperación firmes deben obtener respuestas específicas en lugar de inferirlas de los nombres de las características.
El soporte, la facturación y el estado de la cuenta también son dependencias de infraestructura
Lunanode dirige a los clientes con problemas de infraestructura a abrir un ticket de soporte. Suservicio de monitoreosoporta comprobaciones HTTP, de caducidad de certificados TLS, ICMP, TCP y DNS, con notificaciones por correo electrónico, SMS, teléfono y webhook. Esas son herramientas prácticas, particularmente cuando el destino de la alerta está fuera del servicio de Toronto. El incidente de correo electrónico de 2024 demuestra por qué importa un canal de alerta independiente.
Las páginas públicas no establecen un compromiso general de tiempo de respuesta o tiempo de restauración para planes de nube ordinarios. La página de estado a menudo muestra trabajo activo, pero no es un programa de nivel de servicio contractual. No hay declaración pública de cobertura de personal las 24 horas, niveles de escalada, acuerdos de manos remotas, clases de prioridad o ventanas de reemplazo garantizadas. Esto no significa que el soporte esté ausente; las actualizaciones detalladas de incidentes demuestran intervención activa. Significa que un comprador no puede derivar un objetivo de soporte firme del material público.
La facturación también puede detener un servicio técnicamente saludable. Lunanode opera con crédito de cuenta. SuAPI de facturaciónexpone el saldo de crédito restante, mientras que los términos dicen que se envía un correo electrónico de saldo bajo al menos 48 horas antes de que el crédito llegue a cero y que los servicios se suspenden después de que el saldo se vuelva negativo, con al menos siete días de aviso antes de la suspensión. Un fallo de pago, dirección de contacto desactualizada o notificación perdida puede convertirse, por lo tanto, en un evento de disponibilidad.
Los términos también reservan derechos amplios de suspensión y terminación, describen el manejo de reembolsos, y establecen que la terminación libera los recursos asignados y elimina los datos asociados. Los clientes deben entender esas disposiciones antes de poner datos irremplazables en una sola cuenta. La separación operativa puede requerir más de dos VM: puede requerir una copia de seguridad fuera del proveedor, DNS y control de dominio independientes, múltiples contactos de facturación, crédito monitoreado, recuperación de acceso documentada y un segundo lugar para ejecutar.
La concentración del soporte es difícil de medir públicamente. Los registros de ARIN y PeeringDB nombran un contacto técnico, pero un contacto de registro no revela el tamaño del equipo o la cobertura de turnos. Ninguna evidencia pública confiable cuantifica la dotación de personal, el personal en el sitio o la cola de soporte de Lunanode. La conclusión honesta no es que el soporte sea necesariamente escaso; es que la redundancia de personal y la profundidad de escalada siguen sin verificar.
La localidad canadiense es útil, pero no es una respuesta completa de soberanía
El alojamiento en Toronto puede ser atractivo para clientes que quieren que sus discos y volúmenes VM principales estén en Canadá. Lunanode es una empresa canadiense en los registros de ARIN, y sus páginas de servicio en vivo identifican a Toronto como la ubicación de cómputo actual. Eso le da a un comprador más información de localidad que un servicio que simplemente etiqueta una región amplia.
Lapolítica de privacidadde la empresa dice que los contenidos de VM, volúmenes e imágenes del cliente se almacenan como datos de usuario y describe límites de acceso y divulgación. Suacuerdo de privacidad de datosdescribe a Lunanode como un procesador o subprocesador en circunstancias relevantes, permite subprocesadores, y dice que los clientes eligen el país donde se almacenan los datos al comprar un servicio. Ambos documentos datan de 2018. Siguen publicados públicamente, pero su antigüedad y referencias a la elección de país deben reconciliarse con la evidencia actual de aprovisionamiento solo en Toronto.
La ubicación de los datos tiene varias capas. El disco principal puede estar en Toronto mientras los mensajes de monitoreo, los registros de pago, las comunicaciones de soporte o las copias de seguridad administradas por el cliente utilizan otros proveedores y jurisdicciones. Un cliente puede acceder a los datos alojados en Toronto desde cualquier lugar. Un subprocesador puede participar en la entrega de parte del servicio. El registro de dominio, el procesamiento de pagos, la entrega de SMS y la conectividad upstream tienen sus propios límites de operador.
El almacenamiento canadiense es, por lo tanto, un hecho significativo, no una conclusión legal u operativa completa.
Los cierres de 2023 también muestran por qué la localidad debe monitorearse a lo largo del tiempo. Roubaix ofrecía una vez una ubicación francesa; Montreal ofrecía una segunda ciudad canadiense. Cuando ambas cerraron, los clientes tuvieron que aceptar Toronto o irse. Un contrato o evaluación de cumplimiento debe identificar la ubicación aprobada, las expectativas de notificación, el proceso de exportación y la respuesta requerida si esa ubicación se retira.
La portabilidad es comparativamente tangible en Lunanode. Las instantáneas pueden descargarse. Los clientes pueden subir sus propias imágenes y medios de instalación. Los volúmenes pueden convertirse en imágenes. Las IPs flotantes pueden desadjuntarse dentro de la plataforma, aunque la dirección generalmente no puede seguir al cliente a un proveedor no relacionado. Estos controles pueden reducir la dependencia del proveedor si el cliente realmente los ejerce.
Un formato de imagen, clave de cifrado, zona DNS, registro de configuración y copia de seguridad de datos independiente reciente son más útiles que un botón de exportación teórico descubierto durante una emergencia.
Una evaluación seria de localidad debería, por lo tanto, preguntar dónde reside cada clase de datos, quién puede acceder a ellos, qué términos legales aplican, cómo las copias de seguridad salen de Toronto, qué tan rápido puede el cliente recuperar una copia completa, y si esa copia se inicia con éxito en otro lugar. Los documentos públicos de Lunanode proporcionan un punto de partida. No responden a toda la evaluación para cada carga de trabajo.
Qué elevaría el nivel de evidencia
La huella pública de Lunanode no está vacía. Es más fuerte de lo que una lectura superficial de su modesta presencia de marketing podría sugerir. La empresa tiene páginas de productos y precios en vivo, instrucciones actuales de aprovisionamiento en Toronto, avisos de estado detallados hasta 2026, espacio de direcciones activo, AS394745, anuncios IPv4 e IPv6, una presencia en TorIX y una superficie de control de larga duración. Estos son signos creíbles de un proveedor de nube pequeño en funcionamiento.
El nivel se detiene en Medio porque los hechos de resiliencia más consecuentes permanecen no divulgados. El material público no indica el número de racks o hipervisores activos, las generaciones actuales de servidores en toda la flota, la potencia contratada, el margen de potencia disponible, el recuento de nodos de almacenamiento, el diseño de replicación, el recuento de hosts de repuesto, el inventario de piezas de reemplazo, los contratos de tránsito, la diversidad de rutas físicas, la dotación de personal de soporte, el número de clientes, la utilización, los objetivos de recuperación o los resultados de pruebas de restauración.
Muestra una ciudad de cómputo activa y ningún segundo sitio verificado para conmutación por error del cliente.
La evidencia que elevaría el nivel no necesita exponer detalles sensibles. Lunanode podría publicar una nota de arquitectura actual que distinga los dominios de falla de instalación, rack, host y almacenamiento; confirmar si las cargas de trabajo de los clientes ocupan más de un dominio de energía; identificar las clases de diversidad upstream; indicar cómo la colocación de afinidad se asigna a los racks; describir el comportamiento actual de replicación y evacuación de volúmenes; y proporcionar métricas agregadas de disponibilidad e incidentes.
Una declaración actual de copia de seguridad y ubicación de datos podría reemplazar la ambigüedad dejada por documentos de 2018 e instrucciones históricas multirregionales.
Para un cliente, las preguntas inmediatas son prácticas. ¿Está la VM en disco local o en un volumen? ¿Están las réplicas en hosts y racks distintos? ¿Sobrevive la aplicación a una falla de host? ¿Está la copia de seguridad fuera de Lunanode y fuera de Toronto? ¿Puede restaurarse en otro hipervisor u otro proveedor? ¿Sigue alertando el monitoreo cuando Toronto no puede enviar correo electrónico? ¿Quién vigila el crédito de la cuenta? ¿Qué sucede si se retira una región? ¿Cuántos datos deben cruzar la red durante la recuperación, y cuánto tiempo tomó la última prueba?
La propuesta de valor de Lunanode no requiere que se asemeje a una nube de hiperescala. Un proveedor canadiense compacto puede ser una buena opción cuando importan el precio, la inmediatez, la facturación por hora y la localidad en Toronto. La evidencia respalda esa propuesta más limitada. No respalda tratar la capacidad alojada de bajo costo como sin ubicación o autocurable por defecto.
El hecho central de infraestructura es simple: Lunanode vende una interfaz flexible a máquinas reales en una instalación real de Toronto. Su propia historia muestra reparaciones que dependían de servidores de repuesto, fuentes de alimentación compatibles, comprobaciones del sistema de archivos, quórum de almacenamiento, técnicos upstream y migración de clientes. Los compradores pueden usar las instantáneas, volúmenes, balanceadores de carga, direcciones flotantes y monitoreo de la plataforma para construir resiliencia.
La última capa aún les pertenece: mantener una copia independiente, reservar otro lugar para ejecutar, y probar la ruta antes de que un rack, ruta, cuenta o contrato comercial fuerce el movimiento.