Resumen
- LIVEHOSTING centros de datos SRL se identifica públicamente como el operador de un centro de datos en Timisoara y como titular de AS41635. Sus páginas de venta actuales ofrecen alojamiento web, servidores virtuales y dedicados, gestión de servidores y colocación 1U-3U.
- El perímetro de red público está activo, no solo registrado. RIPEstat observó 89.38.208.0/22 desde AS41635 el 12 de julio de 2026, visible por los 326 pares IPv4 declarantes en su instantánea de estado de enrutamiento, con AS12302 y AS39737 como redes adyacentes observadas.
- Las evidencias físicas son menos recientes. Una guía sectorial rumana de 2012 reportaba una sala de datos de 30 metros cuadrados, dos alimentaciones trifásicas de 50 kW, un grupo electrógeno diésel de 100 kW y cuatro SAI de 40 kW. Estas cifras constituyen un historial útil, pero no establecen el equipamiento, la carga, la autonomía o la redundancia disponibles en 2026.
- La página de colocación enumera dos alimentaciones, un SAI, un grupo electrógeno, protección DDoS y un puerto de Internet de 1 Gbps. No publica la separación de circuitos A/B, la autonomía de combustible del generador, la redundancia de refrigeración, las entradas de fibra, los compromisos de los operadores, los resultados de las pruebas de mantenimiento ni un segundo sitio de recuperación.
- El nivel de evidencia de red es Medio. Existen pruebas convincentes de un servicio actual y de una superficie de explotación enrutada, pero no hay suficientes pruebas actuales e independientes para considerar que la capacidad comercializada sea mantenible simultáneamente o demostrablemente recuperable tras un fallo de la instalación o de un operador.
La afirmación es suficientemente específica para ser comprobada
LIVEHOSTING centros de datos SRL no se esconde tras una vaga etiqueta de nube. Supágina de contacto actualnombra a la sociedad legal rumana, da el número de registro J35/815/2010 y el código fiscal RO26963713, identifica AS41635 e indica que la empresa opera su propio centro de datos en Timisoara. Suoferta de colocaciónsitúa los equipos de los clientes en esa instalación y enumera la protección mediante SAI y grupo electrógeno. Esto es más concreto que un revendedor que nunca identifica un sitio o una red.
La especificidad crea una carga de prueba útil. Si un proveedor declara operar la infraestructura a nivel de edificio tras las cargas de trabajo de los clientes, la unidad relevante no es el servidor virtual mostrado en una página de precios. Es la cadena completa desde la entrada de la red eléctrica hasta el SAI, el generador, la distribución eléctrica, la refrigeración, el rack, el conmutador, el enrutador de borde, la ruta del operador y el técnico. Cada eslabón puede reducir la capacidad que los clientes pueden realmente utilizar en caso de fallo.
El dominio público de la empresa abarca varios tipos de dependencias. Supágina de inicioofrece alojamiento Windows y Linux, servidores virtuales, servidores dedicados, colocación y gestión de servidores. Los clientes de alojamiento compartido dependen de una plataforma controlada por el proveedor. Los clientes de servidores virtuales dependen del diseño del host y del almacenamiento que no pueden inspeccionar directamente. Los clientes de servidores dedicados dependen del hardware, la conmutación y el acceso remoto. Los clientes de colocación son propietarios del servidor en mayor medida, pero aún dependen de la instalación y la red. Así, un fallo en el nivel común de la alimentación o del operador puede afectar a productos que parecen distintos a efectos de facturación.
La distinción clave es entre la evidencia de explotación y la evidencia de resiliencia. AS41635 y el catálogo de productos actual constituyen una prueba convincente de que LiveHosting está en activo. Pero no muestran, por sí mismos, qué carga sobrevive a la pérdida de una vía de alimentación, de una cadena SAI, de una unidad de refrigeración, de un enrutador de borde o de una entrada de fibra. Esta segunda cuestión determina si un pequeño centro de datos de Timisoara está meramente disponible en un día normal o es recuperable en un día difícil.
Un servicio actual tras una pequeña huella pública
Las pruebas públicas avalan una actividad comercial real. LiveHosting publica precios para servidores virtuales, servidores dedicados y colocación, mantiene páginas de cuenta de cliente y de pedido, y expone un contacto para abusos de red. Supágina de servidores virtuales SSDenumera seis configuraciones, mientras que supágina NVMeenumera otras seis. Sus páginas de servidores dedicados anuncian sistemasHP ProLiant DL360 G7yG8con fuentes de alimentación redundantes reemplazables en caliente y múltiples interfaces de red.
Estas páginas establecen una superficie de venta, no un inventario. No dicen cuántos hosts físicos hay instalados, cuántos están disponibles para entrega inmediata, qué proporción de CPU y memoria está comprometida, o si se guardan en el sitio sistemas y discos de repuesto. Una configuración puede seguir siendo pedible cuando el último chasis adecuado está en uso, una pieza de repuesto está en reparación o no se pueden asignar nuevas fuentes de alimentación a un rack. Por tanto, los compradores deben tratar las configuraciones listadas como clases de servicio comercializadas y no como capacidad instalada auditada.
La huella pública de la empresa también parece pequeña.El perfil empresarial de Termene.ro, un agregador de información de empresas rumanas, reporta una facturación en 2024 de RON736.213, un beneficio neto de RON286.410 y una media de un empleado. LinkedIn, por su parte, clasifica a la empresa en la franja de dos a diez empleados e indica que ha atendido a más de 4.000 clientes desde 2006. Ninguna de estas fuentes prueba el número actual de ingenieros disponibles para un incidente nocturno. Los subcontratistas, el personal afiliado, los técnicos de los operadores y el personal del edificio pueden quedar fuera de una media legal o de una franja de redes sociales.
Esta incertidumbre es relevante sin implicar que un equipo pequeño sea incapaz. Los operadores pequeños pueden ser técnicamente disciplinados y reactivos. Pero también pueden depender en gran medida del conocimiento de un único administrador y de proveedores cuyos plazos de respuesta escapan al contrato del cliente. Las pruebas pertinentes son un registro de servicio actual, un dispositivo de escalado, una lista de acceso y un derecho de soporte de los proveedores. Las señales de plantilla públicas simplemente hacen más importantes estas preguntas.
Timisoara es la ubicación del servicio, pero no un plano completo del sitio
LiveHosting declara reiteradamente que explota su propio centro de datos en Timisoara. Sus datos legales de contacto sitúan la sede social en Dumbravita, justo a las afueras de la ciudad, mientras que la página de colocación indica que la ubicación del servicio es «LiveHosting centros de datos Timisoara». Son declaraciones compatibles, pero no prueban que la sede social, la sala de datos y cada servidor anunciado se encuentren en la misma dirección.
La entrada de instalación de centros de datos Mapdescribe una instalación de LiveHosting a menos de dos kilómetros del centro de Timisoara e indica que la ubicación exacta no es pública. Su página de ecosistema no señala datos de red ni de proveedor de servicios para el sitio. centros de datos Map es un directorio comercial, no una auditoría de ingeniería, pero la ausencia de una dirección exacta pública refuerza una frontera importante: la ciudad está cubierta; la identidad del edificio y la estructura de propiedad no lo están.
«Centro de datos propio» puede describir varios esquemas. La empresa puede ser propietaria del inmueble y de todas las instalaciones mecánicas y eléctricas. Puede poseer la sala informática dentro de un edificio alquilado. Puede explotar racks y conmutación mientras que un propietario controla la entrada eléctrica, los sistemas de incendios o la refrigeración. Puede subcontratar el mantenimiento del generador o la seguridad remota. Ninguno de estos modelos es intrínsecamente deficiente. Crean diferentes derechos de restablecimiento y diferentes proveedores de plazos.
Un cliente que evalúe la colocación debería solicitar una matriz de responsabilidades. Debería identificar quién posee el edificio, quién opera cada etapa eléctrica, quién mantiene la refrigeración, quién controla el acceso físico, quién tiene el contrato de combustible del generador, quién posee la fibra externa y quién puede autorizar un trabajo de emergencia. También debería distinguir la sede social legal de la dirección de la instalación y de cualquier ubicación de respaldo. Sin ese mapa, la expresión «centro de datos propio» es útil pero incompleta.
El área de servicio es más clara a nivel de red. AS41635 está registrado en Rumanía, el producto se vende en rumano, y un traceroute de IPinfo alcanzó una dirección en el bloque de origen a través de Prime Telecom hasta un destino etiquetado Timisoara en junio de 2026. Esto respalda una entrega rumana. No prueba que cada copia de seguridad, servicio de control, sonda de monitorización o copia de cliente permanezca en Rumanía.
Una instantánea detallada de 2012 no puede certificar la instalación de 2026
La descripción pública más específica de la instalación física aparece en la guíacentros de datos 2012de Market Watch. La guía indicaba una sala de datos de 30 metros cuadrados, dos alimentaciones de transformador trifásico de 50 kW cada una (una descrita como procedente de Electrica y la otra de CET), un grupo electrógeno diésel de 100 kW y cuatro SAI de 40 kW cada uno. También enumeraba comunicaciones a 1 Gbps, servidores Dell, almacenamiento y red, monitorización mediante PRTG y DRAC, y certificaciones ISO 9001 e ISO 27001.
Es una evidencia histórica valiosa porque proporciona escalas y topologías que el sitio web actual no ofrece. Pero también tiene catorce años. Los equipos envejecen, las baterías se reemplazan, la refrigeración se amplía, el cableado se rehace, los contratos de los operadores cambian y las instalaciones se trasladan. La guía pudo haber capturado con precisión la descripción del proveedor en aquel momento sin decir mucho sobre la instalación que ahora atiende a los clientes.
Las cifras también requieren interpretación. Dos alimentaciones nominales de 50 kW no significan necesariamente 100 kW de carga informática resiliente. Si una u otra alimentación debe poder soportar toda la sala, la capacidad útil resiliente puede estar más cerca de la potencia utilizable del camino más pequeño tras pérdidas y cargas no informáticas. Un grupo electrógeno de 100 kW no establece la carga informática que puede soportar una vez incluidos la refrigeración, las pérdidas del SAI, la iluminación, las bombas y las corrientes de arranque.
Cuatro SAI de 40 kW no revelan si fueron configurados en N, N+1, 2N o como sistemas separados soportando cargas diferentes.
Por lo tanto, el sitio web actual debe leerse en paralelo, y no fusionado, con la guía de 2012. Las páginas actuales prueban que los productos de colocación y de servidor siguen comercializándose. La antigua guía muestra lo que la empresa divulgó en su día. Ningún documento público examinado aquí conecta los datos históricos con un esquema unifilar actual, un informe de puesta en servicio, una prueba de carga, un informe de estado de baterías o una prueba de autonomía de combustible. Hasta que aparezcan, las cifras históricas son una base para preguntas, no un certificado de capacidad actual.
Dos alimentaciones de servidor no prueban dos caminos de alimentación independientes
La tabla de colocación actual enumera «2» bajo alimentaciones para sus planes 1U, 2U y 3U. Las páginas de servidores dedicados también anuncian fuentes de alimentación dobles reemplazables en caliente de 750 W. Es un buen diseño a nivel de componente: un servidor puede continuar tras el fallo de un módulo de alimentación si el otro módulo y su entrada permanecen sanos. Pero la resiliencia depende de adónde conducen los dos cables.
Si las dos alimentaciones del servidor se conectan a la misma PDU del rack, la PDU sigue siendo un punto único de fallo. Si dos PDU se conectan a la misma salida SAI o al mismo cuadro de distribución, el camino eléctrico aguas arriba sigue siendo compartido. Si sistemas SAI separados dependen de un solo conmutador de transferencia o de un solo generador, un fallo en ese punto puede anular ambas alimentaciones aparentes. Incluso conexiones eléctricas físicamente separadas pueden compartir una subestación, un tendido de cable o un esquema de protección fuera del edificio.
Por eso laexplicación del sistema de clasificación Tier del Uptime Institutedistingue entre componentes redundantes y la mantenibilidad simultánea y la tolerancia a fallos. Un segundo componente no es lo mismo que un segundo camino de entrega. El artículo no atribuye ningún nivel Tier a LiveHosting; la página de empresa examinada aquí no reivindica ninguno, y la guía de 2012 no proporcionó explícitamente una clasificación Uptime. El marco solo es útil para aclarar qué evidencias respaldarían un lenguaje más contundente.
Para cada rack vendido como de doble alimentación, LiveHosting debería poder mostrar los caminos A y B desde la red o el generador a través del cuadro de distribución, el SAI, la distribución y la PDU. Debería indicar qué dispositivos quedan con un solo cable y si se utilizan conmutadores de transferencia. Debería publicar la potencia máxima del rack, el calibre del disyuntor, la carga estable permitida y el método de medición. La página de colocación indica que el consumo eléctrico está incluido, pero no cuantifica ninguna asignación eléctrica.
Esta omisión dificulta traducir un espacio 1U, 2U o 3U en un compromiso eléctrico seguro y comercialmente exigible.
La prueba más importante no es un esquema por sí solo. Es una transferencia controlada a carga realista mientras el equipo del cliente permanece en línea, seguida de la prueba de que las baterías, el generador, la refrigeración y el equipo de red se comportaron como se esperaba.
La presencia de un generador no es lo mismo que su autonomía
La página de venta actual enumera un generador, y la guía de 2012 reportaba una unidad diésel de 100 kW. Un generador puede cubrir una interrupción larga de la red, pero solo cuando todo el sistema de soporte funciona: detección automática, baterías de arranque, equipo de transferencia, combustible, refrigeración, escape, mantenimiento, aceptación de carga y acceso para reabastecimiento. La palabra «generador» no divulga ninguna de estas condiciones.
La autonomía es el primer número faltante. Un depósito puede soportar horas a carga parcial pero mucho menos a carga nominal. El consumo de combustible cambia con la demanda eléctrica, y la demanda de la instalación incluye más que los servidores. La refrigeración debe continuar durante una pérdida de red; de lo contrario, el generador puede mantener los equipos informáticos encendidos mientras la temperatura de la sala aumenta hacia una parada forzada. Así, una autonomía pública debería indicar la carga crítica soportada, el combustible mínimo en el sitio, el contrato de reabastecimiento y las hipótesis sobre la refrigeración.
Lasdirectrices sobre sistemas de combustible del Uptime Institutedescriben una expectativa de almacenamiento mínimo de doce horas para topologías Tier a la carga N declarada de la instalación. Es un punto de referencia, no una prueba de que LiveHosting lo cumpla o necesite adoptar este diseño exacto. Un pequeño proveedor puede elegir un objetivo de riesgo diferente. Lo que importa es que los clientes conozcan el objetivo y puedan compararlo con sus necesidades de recuperación.
Las pruebas importan tanto como el tamaño del depósito. Un arranque mensual sin carga no prueba que el generador y el sistema de transferencia soportarán la sala en un día caluroso. Un registro significativo incluiría pruebas de transferencia en carga, la duración, el porcentaje de carga, la calidad del combustible, las alarmas, los arranques fallidos y las acciones correctivas. También mostraría si los dos caminos de tránsito actuales y la monitorización externa permanecen disponibles cuando la alimentación de red se corta.
La consecuencia para el cliente es directa. Una interrupción corta puede ser absorbida por las baterías del SAI. Un corte más largo se convierte en un evento de generador y combustible. Si el generador falla o no puede soportar la refrigeración, todos los productos en la sala pueden converger hacia el mismo plazo de parada, sin importar cuántas máquinas virtuales, conjuntos RAID o fuentes de alimentación de servidor haya por encima.
La refrigeración determina cuánta capacidad eléctrica es utilizable
El material público examinado aquí no proporciona un diseño de refrigeración actual, capacidad de refrigeración instalada, nivel de redundancia, disposición de contención o rango de funcionamiento ambiental. Esta ausencia impide al lector convertir los datos eléctricos históricos en capacidad informática utilizable. Casi cada vatio consumido por el equipo informático se convierte en calor que debe ser evacuado, y la sala puede estar limitada por la refrigeración antes de alcanzar un límite eléctrico nominal.
La cifra de 30 metros cuadrados reportada en 2012 tampoco dice nada sobre la densidad actual de los racks. Una sala pequeña con racks ligeramente cargados puede ser estable. La misma sala llena de servidores de doble procesador, almacenamiento denso o conmutación de alta velocidad puede desarrollar puntos calientes incluso si la potencia total del edificio permanece dentro de un límite nominal. El catálogo de servidores dedicados incluye sistemas con múltiples discos y doble procesador, mientras que el equipo de colocación de los clientes es menos predecible.
La asignación de capacidad debe tener en cuenta tanto el calor medio como la concentración local.
La redundancia de refrigeración tiene varias capas: la unidad de refrigeración, el compresor o la fuente de agua helada, las bombas y ventiladores, el sistema de control, la alimentación eléctrica y la vía de rechazo de calor. Una refrigeración «N+1» puede aún ocultar tuberías comunes, dependencias de control o eléctricas. El mantenimiento puede ser más revelador que un fallo. Si una unidad de refrigeración no puede ser aislada y mantenida en un día caluroso sin reducir la sala por debajo de su carga comprometida, la capacidad instalada supera la capacidad utilizable simultáneamente.
Un comprador debería solicitar los rangos de temperatura y humedad en las entradas del servidor, la ubicación de los sensores, los umbrales de alarma, los registros históricos, el margen en tiempo caluroso y el resultado de una prueba de pérdida de unidad de refrigeración. La respuesta debería explicar la política de parada automática y el aviso al cliente si la temperatura aumenta. También debería indicar si la capacidad del generador incluye toda la refrigeración necesaria para la carga informática comprometida.
Las implicaciones en materia de incendio y agua son las siguientes. Los condensados, las fugas de tejado o de fontanería pueden afectar rápidamente a una sala compacta. La detección y extinción de incendios deben ser compatibles con espacios ocupados y equipos eléctricos bajo tensión. El material público menciona la seguridad física y la vigilancia históricas, pero no proporciona evidencias actuales sobre sectorización de incendios, detección de fugas, extinción o zona inundable. Los clientes no deben deducir estos controles únicamente de la etiqueta de centro de datos.
Capacidad instalada, vendible y recuperable son cifras diferentes
El proveedor puede honestamente tener equipos instalados y aun así tener menos capacidad disponible para nuevos clientes y menos aún disponible durante un fallo. La capacidad instalada es la suma de las potencias nominales y los recursos configurados. La capacidad vendible es lo que las reglas comerciales y técnicas permiten tras reservas y sobrecontratación. La capacidad recuperable es lo que queda, o puede restaurarse en los plazos previstos, tras el fallo de un componente definido.
Las páginas públicas de LiveHosting anuncian CPU, memoria, almacenamiento SSD o NVMe y tráfico «ilimitado» del servidor. Estas especificaciones describen una prestación o configuración de producto. No muestran la ocupación del host, la replicación del almacenamiento, la contención del enlace ascendente ni el rendimiento de la copia de seguridad. El tráfico «ilimitado» es particularmente fácil de malinterpretar: puede significar una ausencia de facturación por volumen mientras que cada paquete sigue compartiendo un puerto, una periferia y un compromiso de tránsito finitos.
El espacio de colocación también está incompleto sin la potencia y el margen de red. Tres clientes 1U pueden consumir menos energía que un cliente 3U, o mucho más, según el hardware. Un puerto de 1 Gbps es una velocidad de interfaz, no una velocidad de Internet garantizada bajo ataque o tras el fallo de un operador. La potencia nominal de un generador no es un compromiso de capacidad para el cliente. La potencia de un SAI no es una garantía de autonomía.
La medida operativa que importa es el presupuesto en estado de fallo. ¿Cuántos kilovatios quedan si se aísla un camino de alimentación? ¿Qué temperatura de sala puede mantenerse tras la pérdida de una unidad de refrigeración? ¿Cuánta capacidad de Internet permanece si Prime Telecom o Vodafone dejan de estar disponibles? ¿Cuántos servidores virtuales pueden reiniciarse simultáneamente desde la copia de seguridad? ¿Cuántos ingenieros pueden gestionar simultáneamente incidencias de hardware, red y clientes?
Estas cifras deberían vincularse a las clases de clientes. El alojamiento compartido puede tolerar un tiempo de recuperación diferente al de un sitio web del sector público, una aplicación transaccional, un servidor de correo o un sistema empresarial en colocación. Una instalación pequeña no necesita una capacidad hiperescalar para ser útil. Necesita compromisos adaptados a su redundancia real y una negativa clara a vender más allá de la envolvente en estado de fallo.
AS41635 está activo y es visible globalmente
Las evidencias de red son la parte más sólida del expediente público.RIPE RDAPenumera AS41635 como activo y lo nombra LIVEHOSTING-AS.La vista general de AS de RIPEstatidentifica al titular como LIVEHOSTING centros de datos SRL y marca el ASN como anunciado. Esto concuerda con la propia página de contacto de la empresa.
El 12 de julio de 2026,el estado de enrutamiento de RIPEstatmostraba un prefijo IPv4 originado con 1.024 direcciones y ningún prefijo IPv6 originado. La ruta IPv4 era visible por los 326 pares IPv4 declarantes en esa instantánea.La vista de prefijos anunciados de RIPEstatidentificaba 89.38.208.0/22 como el anuncio actual. La vista del historial de enrutamiento rastrea el espacio de direcciones originado por LiveHosting hasta 2006, aunque el agregado pasó de un /21 al /22 actual con el tiempo.
Esta es una evidencia de explotación significativa. Una ruta ampliamente visible mantenida durante años es incompatible con un registro de ASN puramente decorativo. El prefijo aloja el propio sitio web de la empresa y nombres de servidores públicos, y agregadores independientes también lo identifican.El BGP Toolkit de Hurricane Electricreportaba un prefijo IPv4, 1.024 direcciones IPv4 originadas, dos pares IPv4 observados y ningún origen IPv6.IPinfoclasifica el ASN como alojamiento y muestra una ruta de junio de 2026 alcanzando el bloque a través de AS39737.
La ruta también es válida según RPKI.La validación RIPEstatencontró una autorización válida para que AS41635 origine 89.38.208.0/22 con una longitud máxima de /22. Comoexplica el RIPE NCC, la validación de origen responde si el titular legítimo del recurso ha autorizado una combinación prefijo-origen particular. No valida el resto del camino AS ni prueba la resiliencia física.
La conclusión debe ser limitada: LiveHosting tiene un origen IPv4 actual, válido y altamente visible. Esto es más fuerte que una tarjeta de marketing. Pero aún no puede mostrar si los enrutadores están duplicados, si los operadores entran por conductos separados, o si el camino superviviente puede soportar la demanda del cliente tras un fallo.
Los dos caminos de operador visibles aún necesitan evidencias físicas
La vista de AS vecinos de RIPEstatobservó dos redes adyacentes el 12 de julio de 2026: AS12302, Vodafone Rumanía, y AS39737, Prime Telecom. La instantánea de estado BGP mostraba la gran mayoría de los caminos muestreados a través de Prime Telecom y un número menor a través de Vodafone. Hurricane Electric listaba independientemente los mismos dos pares.
Dos adyacencias observadas son mejores que una porque ofrecen alternativas de ruta potenciales. No deberían llamarse dos operadores independientes probados sin contrato y evidencias de sitio. Un colector de rutas observa los caminos AS, no la propiedad de la fibra, las entradas al edificio, las interconexiones o la capacidad pagada. Un operador puede revender a otro. Dos circuitos pueden compartir un conducto metropolitano, una arqueta, un cruce de calle, un panel de parcheo o el mismo equipo externo bajo tensión.
El objeto de registro RIPE añade otra razón para la cautela. Su política de importación, modificada por última vez en 2021, nombra AS6830 y AS34279, mientras que los colectores actuales ven AS12302 y AS39737. Esta diferencia puede simplemente reflejar una política de registro obsoleta tras cambios de operadores ordinarios. Demuestra por qué una declaración de registro no debería sustituir una observación actual o un calendario de operadores actual.
La capacidad tras fallo es el siguiente problema. Si el camino principal transporta la mayor parte del tráfico, el secundario debe tener suficiente capacidad comprometida y en ráfaga para absorberlo. BGP puede reconverger con éxito mientras las aplicaciones se vuelven inutilizables porque el circuito restante está congestionado. La protección DDoS añade otra dependencia: el proveedor debería explicar dónde ocurre el filtrado, si ambos ascendentes lo soportan, cómo se desvían las rutas y si un evento de protección reduce la capacidad propia.
Las evidencias requeridas son prácticas. LiveHosting debería identificar los dos proveedores contratados, los tamaños de puerto y compromiso, las demarcaciones físicas, los caminos de entrada, los enrutadores de borde y los dominios de alimentación. Debería mostrar una prueba reciente en la que cada ascendente fue retirado por separado con carga ocupada, registrar la convergencia y la pérdida de paquetes, y confirmar que la monitorización y las comunicaciones con los clientes permanecían accesibles.
La ausencia de perfil en PeeringDB reduce lo que se puede verificar públicamente
Una consulta a laAPI de PeeringDBno devolvió ninguna entidad de red para AS41635 durante esta revisión. Esto no es una prueba de fallo de red. La participación en PeeringDB es voluntaria, y una pequeña red de alojamiento puede comprar tránsito sin mantener un perfil de interconexión público. La ausencia reduce la visibilidad pública sobre las instalaciones, los intercambios, los niveles de tráfico, la política de peering y los contactos de red.
La forma actual parece más orientada al tránsito que al intercambio. Los colectores públicos exponen dos redes adyacentes, pero ningún registro público de PeeringDB identifica un punto de intercambio de Internet o una conexión de instalación. Por lo tanto, los clientes deben evitar suponer que la red tiene peering directo, rutas de intercambio diversificadas o una sala de encuentro neutral. Estas características pueden existir; el expediente público examinado aquí no las establece.
Esto importa para el aislamiento de fallos. Si todos los caminos externos dependen de un pequeño conjunto de entregas de tránsito en un solo edificio, el punto de encuentro local del operador puede ser un punto común de fallo incluso cuando la tabla de rutas mundial muestra dos ASN ascendentes. Si un circuito termina fuera del sitio y alcanza la sala de datos a través de una cola local compartida, la diversidad lógica puede desaparecer en el último kilómetro.
El proveedor puede resolver gran parte de esta incertidumbre sin exponer detalles sensibles. Puede publicar un diagrama de red neutro para la instalación mostrando entradas separadas, equipos de borde separados, las identidades de los operadores, las capacidades de los puertos y la política de conmutación por error. Puede mantener un perfil actualizado en PeeringDB si procede. Puede ofrecer un looking glass o un servicio de estado alojado externamente. Ninguna de estas medidas prueba cada conducto, pero juntas hacen que el modelo de explotación de la red sea más fácil de verificar.
La ausencia de origen IPv6 merece una respuesta directa
La página de colocación de LiveHosting indica que se incluye una subred IPv6 /56 con cada plan. Sin embargo, RIPEstat y Hurricane Electric mostraban cero prefijos IPv6 originados por AS41635 en las instantáneas de julio de 2026. El regulador francés de telecomunicaciones, ARCEP, también listaba AS41635 con una exposición IPv6 nula en sus mediciones de 2025 sobre proveedores de alojamiento. Estas observaciones no prueban que los clientes no reciban ningún servicio IPv6.
El /56 anunciado puede provenir del espacio de direcciones de un proveedor ascendente y ser enrutado hacia LiveHosting sin que AS41635 origine un prefijo IPv6. Puede estar disponible solo bajo demanda. Puede estar configurado dentro de la instalación sin ser visible en los datos públicos muestreados. Cada explicación tiene una consecuencia de resiliencia diferente.
El IPv6 asignado por el proveedor puede funcionar bien, pero la conmutación por error puede depender del proveedor que lo asigna. Si el /56 pertenece a un operador y ese operador cae, LiveHosting podría no ser capaz de anunciar la misma subred de cliente a través del otro camino. Renumerar un parque de servidores durante un incidente no equivale a una conmutación por error BGP. Los DNS, las reglas de cortafuegos, las listas de acceso y el software cliente pueden todos conservar las direcciones antiguas.
El comprador debería preguntar qué agregado contiene el /56, qué ASN lo origina, si es accesible a través de ambos ascendentes visibles y si la autorización de origen de ruta cubre el origen previsto. También debería preguntar si el puerto de 1 Gbps y la protección DDoS se aplican por igual a IPv4 e IPv6. Un servicio de doble pila es tan resiliente como la pila menos probada cuando las aplicaciones y el DNS publican ambas.
La brecha es importante porque IPv6 no es una funcionalidad decorativa. La página de colocación lo presenta como una capacidad incluida. Las evidencias de ruta públicas hacen clara la superficie de explotación IPv4; unas evidencias IPv6 equivalentes transformarían el /56 de una línea de venta en un servicio de red verificable.
El compromiso de calidad es más limitado que una garantía de instalación
Elcompromiso de calidadde LiveHosting se aplica a los planes de alojamiento web Windows o Linux Estándar, Business y Revendedor. Define la disponibilidad como la proporción mensual durante la cual el sitio web de un cliente es accesible a través de HTTP desde una ubicación neutra. La página indica que LiveHosting utiliza sistemas PRTG en su centro de datos y en otros centros de datos rumanos y extranjeros para medir la disponibilidad.
El baremo de crédito reembolsa el 50% cuando la disponibilidad se sitúa entre el 98% y el 99,5%, el 75% entre el 95% y el 97,9%, y el 100% al 94,9% o menos. Un crédito de servicio es comercialmente útil, pero no es una compensación por ventas perdidas, datos o reputación. Más importante aún, el alcance declarado no cubre automáticamente los servidores virtuales, los servidores dedicados o la colocación. Los compradores de esas categorías necesitan sus propias condiciones de servicio.
Las exclusiones son amplias. La página excluye, entre otras cosas, la interrupción de las comunicaciones, el incendio, la inundación, los desastres naturales, los virus, los atacantes, el software de terceros, el mantenimiento anunciado o crítico, las actualizaciones de servidor, los DNS fuera del control de LiveHosting y varios protocolos de acceso. Algunas exclusiones describen exactamente los caminos de fallo que un cliente de centro de datos más necesita comprender. Excluirlas de los créditos no las hace improbables; traslada su coste económico al cliente.
La definición de medición también se centra en la accesibilidad HTTP. Un sitio web puede responder mientras el correo, las conexiones a bases de datos, el almacenamiento, los paneles de control, el acceso VPN o un camino de operador están degradados. A la inversa, un fallo de aplicación puede hacer fallar HTTP mientras la alimentación y la red de la instalación permanecen sanas. Los clientes necesitan métricas a nivel de componente y un historial de incidencias que separe las causas de instalación, red, computación, almacenamiento y aplicación.
Un conjunto de garantía más sólido publicaría el rendimiento histórico del servicio por producto, los minutos de mantenimiento, las causas de las incidencias y los tiempos de recuperación. Indicaría qué ubicaciones de monitorización son independientes de AS41635 y si el canal de estado permanece accesible durante un fallo total de instalación o de ruta.
El tiempo de respuesta no es el tiempo de restablecimiento
La página de calidad promete un tiempo máximo de respuesta del soporte técnico de 24 horas durante el horario de lunes a viernes de 10 a 18 horas. La página de contacto actual lista el soporte técnico de lunes a viernes de 10 a 17 horas. Estas páginas pueden describir canales diferentes o simplemente estar desalineadas. En cualquier caso, ninguna de las dos declaraciones es una promesa de restablecer el servicio en 24 horas.
Lapágina de gestión de servidoresañade una distinción comercial más granular. La gestión básica incluye dos horas al mes y disponibilidad en días laborables. La gestión Premium incluye cuatro horas al mes e indica disponibilidad de lunes a domingo, 24 horas. Elcontrato de serviciospúblico indica que el trabajo de gestión está limitado a las horas de la suscripción adquirida, que el trabajo adicional es facturable y que la disponibilidad o el rendimiento de las aplicaciones no están garantizados por el servicio de gestión.
Esto deja varias preguntas para los clientes de dedicados no gestionados y de colocación. ¿La intervención de emergencia en la instalación es continua incluso cuando la gestión del servidor no lo es? ¿Quién atiende una alarma de alimentación, refrigeración o red a las 3 de la madrugada? ¿Están disponibles manos remotas en todo momento, y cuál es el objetivo de llegada? La página de colocación tarifa las manos remotas a 25 EUR por hora pero no publica un compromiso de respuesta 24/7.
La distinción es crítica en una operación pequeña. La detección puede ser automática, pero el diagnóstico y la autorización pueden depender de una persona. Un operador puede requerir el contacto designado del cliente. Un edificio puede restringir el acceso fuera del horario laboral. Un servidor averiado puede tener doble alimentación pero aún necesitar una sustitución local de disco o cable. Cada transferencia añade tiempo antes de que comience el restablecimiento.
Los clientes deberían solicitar cuatro relojes separados: alarma-acuse de recibo, acuse de recibo-diagnóstico cualificado, diagnóstico-intervención in situ e intervención-restablecimiento. Deberían preguntar quién es responsable de cada reloj y qué sucede cuando dos incidencias ocurren simultáneamente. Un número de teléfono y una promesa de ticket son puntos de entrada útiles; no son un plan de recuperación.
El mantenimiento puede exponer más riesgos que un fallo repentino
La redundancia suele parecer más fuerte cuando todo está sano y más débil cuando un componente se retira deliberadamente para mantenimiento. Las baterías de los SAI deben reemplazarse, los generadores deben probarse en carga, el equipo de refrigeración debe limpiarse, los conmutadores deben actualizarse y los operadores necesitan ventanas de mantenimiento. Durante esos períodos, el camino restante puede soportar la carga total sin reserva.
El compromiso de calidad excluye de sus créditos el mantenimiento anunciado, los trabajos críticos y las actualizaciones de servidor. Esto es habitual en los contratos de alojamiento, pero el riesgo práctico depende de cómo se diseñe el mantenimiento. Un cliente necesita saber si la instalación puede mantener cada componente crítico sin detener la carga informática, si varios proveedores pueden trabajar al mismo tiempo y cómo se gestiona la marcha atrás.
Para la alimentación, las evidencias de mantenimiento deberían incluir caminos de bypass y procedimientos que no pongan toda la sala en la red eléctrica bruta. Para la refrigeración, deberían indicar la carga máxima segura con una unidad aislada. Para el trabajo de red, deberían mostrar que las rutas de los clientes permanecen estables a través del otro enrutador y operador. Para el almacenamiento o la virtualización, deberían cuantificar cuánta carga de trabajo puede trasladarse antes del mantenimiento y cuánto tiempo lleva ese traslado.
La concentración de cambios es otra preocupación. Un pequeño proveedor puede planificar varias tareas en una misma ventana para reducir las interrupciones, pero acoplar cambios de alimentación, red y host elimina las opciones de recuperación independientes. Los clientes deberían preguntar si las aprobaciones de cambios tienen en cuenta las dependencias comunes y si se mantiene un canal de comunicación accesible desde el exterior fuera de los sistemas afectados.
Las evidencias que resolverían la cuestión son documentos operativos ordinarios: un calendario de mantenimiento anual expurgado, avisos de ventanas recientes, informes posteriores al mantenimiento, acciones en caso de fallo de prueba y un impacto visible por el cliente. Esto es más convincente que un objetivo general de disponibilidad porque muestra cómo el operador gestiona los períodos en los que la redundancia se reduce intencionadamente.
El incendio, la inundación y la pérdida de red convergen en los datos del cliente
El compromiso de calidad menciona explícitamente el incendio y la inundación entre las exclusiones de fuerza mayor. Es una asignación contractual, no una prueba de que la instalación esté expuesta o desprotegida. Las páginas públicas examinadas aquí no detallan el sistema actual de detección y extinción de incendios, la clasificación de los compartimentos, la detección de fugas, la evaluación del riesgo de inundación o la distancia a riesgos de agua y combustible.
Estas cuestiones importan más cuando muchas capas de servicio ocupan un único sitio. El alojamiento compartido, los VPS, los servidores dedicados, la colocación, el DNS, el correo y los portales de clientes pueden depender todos de la misma sala. Si los datos primarios, las copias de seguridad y los sistemas de control comparten la instalación, un evento en el edificio puede eliminar el servicio de producción y los medios para restaurarlo.
El contrato de servicio público pone una responsabilidad significativa en los clientes y limita las garantías. También permite la suspensión o eliminación del servicio por impago y se reserva amplios derechos para modificar o interrumpir los servicios. Estas condiciones hacen que las copias de seguridad independientes y los procedimientos de exportación probados sean comercialmente importantes incluso sin un incidente físico.
Un cliente debería identificar dónde reside cada copia, quién controla sus credenciales, con qué frecuencia se prueba y cómo funciona la restauración si el propio portal de cuenta o la red de LiveHosting no están disponibles. Una copia de seguridad en otro servidor de la misma sala protege contra algunos fallos de hardware pero no contra eventos de alimentación, refrigeración, incendio o inundación a escala de sala. Una copia en otro edificio pero administrada a través del mismo sistema de identidad inaccesible también puede ser difícil de usar.
Para los clientes de colocación, la cuestión se extiende a la recuperación del equipo. ¿Quién puede entrar después de un incidente? ¿El hardware del cliente está asegurado por el proveedor, el operador del edificio o el cliente? ¿Puede un cliente recuperar su equipo durante un cierre prolongado del servicio público o de acceso? Las respuestas pueden estar en los contratos individuales, pero no están establecidas por la página de planificación pública.
El fallo afecta a diferentes clientes de diferentes maneras
Los clientes de alojamiento compartido probablemente experimenten primero un fallo de plataforma común como sitios web, correo o paneles de control inaccesibles. Pueden tener poca visibilidad sobre qué servidor físico, conmutador o sistema de almacenamiento ha fallado. Los revendedores pueden amplificar el impacto, ya que una cuenta puede representar muchos sitios descendentes y obligaciones de soporte.
Los clientes de servidores virtuales tienen más control sobre los sistemas operativos pero siguen dependiendo de la capacidad del hipervisor, el almacenamiento y la red local del proveedor. Un fallo de host puede ser recuperable si las cargas de trabajo pueden reiniciarse en otro lugar, pero la página pública del producto no promete migración en vivo, almacenamiento replicado o clúster de recuperación. La presencia de SSD o NVMe no dice nada sobre el número y la ubicación de las copias.
Los clientes de servidores dedicados evitan algunos riesgos de computación compartida. Siguen dependiendo del rack, los dos caminos de alimentación, la conmutación, el tránsito de operadores y las manos remotas. Las fuentes de alimentación dobles y el RAID pueden absorber algunos fallos de componentes seleccionados, pero no pueden sobrevivir a un fallo a escala de sala o a un fallo del borde de red compartido. Las listas de servidores dedicados públicos también muestran generaciones G7 y G8 más antiguas; esto puede ser una oferta económica, pero los compradores deberían preguntar por la disponibilidad de sistemas y componentes de repuesto.
Los clientes de colocación poseen su propio equipo y pueden anunciar su propio espacio de direccionamiento, como la página de producto lo permite para los anuncios BGP. Sin embargo, su dependencia de LiveHosting es física. Necesitan acceso, alimentación, refrigeración, interconexiones, enrutamiento y ayuda para la reparación. Un fallo de la instalación puede detener un equipo por lo demás completamente gestionado por el cliente.
Los usuarios del sector público, la sanidad, las finanzas o la industria también pueden enfrentarse a obligaciones más allá de la disponibilidad. La ubicación, la notificación de incidencias, la preservación de evidencias y la continuidad de los proveedores pueden importar. El artículo no identifica ningún cliente de LiveHosting de este tipo. Subraya por qué la misma afirmación de instalación puede tener consecuencias muy diferentes según la carga de trabajo que se le ponga.
Por lo tanto, el proveedor debería resistirse a una declaración universal de resiliencia. Debería divulgar qué protecciones se aplican a cada servicio, lo que el cliente debe proporcionar y qué dependencias compartidas atraviesan todas las gamas de productos.
Una demostración significativa de conmutación por error debe eliminar las dependencias reales
La mejor manera de establecer la resiliencia actual es probar fallos definidos en lugar de acumular etiquetas. Para LiveHosting, cinco ejercicios responderían a la mayoría de las preguntas abiertas.
En primer lugar, eliminar la alimentación normal de la red a una carga de producción representativa. Registrar la transferencia del SAI, el arranque del generador, la continuidad de la refrigeración, el consumo de combustible, las alarmas y el impacto en el cliente. Continuar el tiempo suficiente para demostrar el objetivo de autonomía publicado y, a continuación, restablecer la red sin perder la carga.
En segundo lugar, aislar cada camino de distribución eléctrica y sección SAI por turnos. Confirmar que los dispositivos de cliente con doble cable permanecen en línea e identificar el equipo con un solo cable que requiere un conmutador de transferencia. Una prueba de generador exitosa no sustituye esta prueba de distribución interna.
En tercer lugar, retirar una unidad de refrigeración o un camino de refrigeración durante un período ambiental exigente. Seguir las temperaturas de entrada del servidor y confirmar qué carga permanece dentro del límite ambiental declarado de la instalación. Esto convierte una afirmación de redundancia de refrigeración en evidencia de capacidad utilizable.
En cuarto lugar, retirar Vodafone y Prime Telecom por separado mientras la red está ocupada. Medir la convergencia BGP, la pérdida de paquetes, la latencia y el rendimiento superviviente tanto en IPv4 como en el servicio IPv6 anunciado. Confirmar que la protección DDoS, la monitorización, el DNS y la comunicación con el cliente funcionan en el camino restante.
En quinto lugar, restaurar una cuenta de alojamiento compartido representativa, un servidor virtual y un servicio de control a partir de una copia fuera del dominio de fallo principal. Medir el tiempo de recuperación y la pérdida de datos, e incluir el caso en que el portal de cliente normal no esté disponible.
Los resultados no necesitan ser perfectos para ser valiosos. Una debilidad divulgada seguida de una acción correctiva es una evidencia más fuerte que una afirmación no probada de disponibilidad completa. Los clientes pueden entonces juzgar si la recuperación demostrada se ajusta a su propia tolerancia y si necesitan un segundo sitio independiente.
El crecimiento de la alimentación y los permisos deben tratarse como restricciones, no como hipótesis
El mercado europeo de centros de datos trata cada vez más la disponibilidad de electricidad como una restricción al desarrollo. Lapágina sobre el rendimiento energético de la Comisión Europeadescribe la creciente demanda de electricidad, los impactos en la refrigeración y el agua, y las obligaciones de información para las instalaciones que superen el umbral pertinente. Nada en las evidencias públicas examinadas aquí establece que LiveHosting supere el umbral de notificación de 500 kW; las cifras históricas sugieren una instalación mucho más pequeña.
La pequeña escala no elimina la necesidad de gestionar la alimentación. Cambia el problema. Un sitio compacto puede tener una demanda total menor pero menos espacio para añadir cuadros eléctricos, refrigeración, baterías, escape o almacenamiento de combustible. Un edificio urbano o periurbano puede enfrentarse a restricciones de ruido, emisiones, seguridad contra incendios y construcción. Una conexión eléctrica puede ser suficiente para la carga actual mientras que la expansión es lenta o costosa.
El sitio actual no publica ninguna expansión planificada, nuevo edificio o solicitud de potencia. Los compradores no deben inferir una. Si LiveHosting comercializa nueva capacidad de alta densidad, las evidencias deberían identificar si proviene de una mayor eficiencia, de equipos más antiguos retirados, de una mayor asignación eléctrica, de nueva refrigeración o de otro sitio. La palabra «disponible» debería significar que la alimentación, la refrigeración y la red están todas en servicio, no simplemente que el espacio en rack está vacío.
Los permisos también afectan a la recuperación. Reemplazar un generador, añadir almacenamiento de combustible, modificar el servicio eléctrico o alterar los sistemas de incendios puede requerir aprobaciones y plazos de proveedores. El cliente no necesita cada número de permiso en público. Necesita la garantía de que el equipo instalado está autorizado, mantenido y respaldado, y que el crecimiento planificado no pondrá la sala existente en un estado prolongado de redundancia reducida.
La medida comercial apropiada es la capacidad lista para un fallo definido, no el espacio teórico para otro servidor.
Lo que aumentaría la confianza
LiveHosting puede elevar el nivel de evidencia con un conjunto de divulgaciones compacto. Debería comenzar con una ficha técnica actual de la instalación fechada y versionada por el operador. La ficha debería indicar la dirección de servicio a un nivel apropiado, los límites del operador y del propietario, la superficie de la sala de datos, la carga informática puesta en servicio, el pico medido actual, los límites de potencia de los racks, la topología de refrigeración y los controles de incendios.
La sección de alimentación debería mostrar las entradas eléctricas, la topología de los SAI, la potencia del generador, la autonomía mínima a la carga crítica comprometida, los acuerdos de combustible y la fecha y el resultado de la última prueba de transferencia en carga. Debería distinguir las potencias nominales totales instaladas de la capacidad N útil, la capacidad en estado de mantenimiento y en estado de fallo.
La sección de red debería conciliar las observaciones actuales de Vodafone y Prime Telecom con el objeto de política RIPE más antiguo. Debería divulgar la capacidad contratada de puertos y de compromiso, la diversidad de enrutadores de borde, la separación de las entradas físicas, los acuerdos DDoS y el origen del /56 IPv6 anunciado. Una entrada en PeeringDB o un looking glass actual mejorarían la visibilidad externa pero no sustituirían la documentación física.
La sección de operaciones debería indicar la propiedad continua de las alarmas, los objetivos de respuesta de la instalación, la cobertura de manos remotas, las existencias de piezas de repuesto y la escalada de proveedores. Debería conciliar las declaraciones de soporte de 10 a 17 horas y de 10 a 18 horas y aclarar qué significa la disponibilidad Premium 24/7 para la respuesta y el restablecimiento.
Por último, el operador debería publicar evidencias anonimizadas de pruebas e incidencias: transferencia eléctrica, pérdida de unidad de refrigeración, conmutación por error de operador, ejercicios de restauración, mantenimiento significativo y lecciones aplicadas. La certificación independiente puede reforzar el conjunto cuando el alcance y la validez actual estén claros. Los nombres de certificación de 2012 no deberían tratarse como actuales sin certificados, sitios, normas y fechas de expiración.
Este nivel de divulgación no expondría los datos de los clientes ni planos sensibles. Permitiría a los compradores distinguir un pequeño centro de datos funcional con límites probados de uno cuya resiliencia se infiere principalmente de las etiquetas de los productos.
El nivel de evidencia es Medio
LIVEHOSTING centros de datos SRL obtiene un nivel de evidencia de red e infraestructura Medio. Las evidencias de explotación específicas de la empresa son sustanciales: un sitio de venta rumano actual, una entidad legal nombrada, una oferta de colocación explícita en Timisoara, AS41635, una ruta IPv4 visible globalmente, dos redes adyacentes observadas, una autorización de origen de ruta válida y años de historial de enrutamiento. No es un caso en que la existencia del proveedor o el funcionamiento básico de la red dependan de una única entrada de directorio.
El nivel se detiene en Medio porque las afirmaciones de resiliencia no están respaldadas por evidencias físicas actuales. El SAI y el generador se enumeran, pero la topología y la autonomía están ausentes. Se enumeran dos alimentaciones de servidor, pero la separación A/B no lo está. Una guía de 2012 ofrece datos detallados, pero ninguna evidencia de puesta en servicio o de carga actual conecta esas cifras con la instalación de 2026.
La refrigeración, los incendios, las inundaciones, las entradas de fibra, los compromisos de los operadores, el rendimiento del mantenimiento, la recuperación externa y los resultados de conmutación por error del cliente permanecen sin divulgar en las fuentes examinadas.
Las dos adyacencias BGP actuales respaldan una diversidad de caminos lógicos, mientras que la ausencia de evidencia física de ruta impide una conclusión más contundente. La ruta IPv4 válida reduce el riesgo de origen, mientras que la ausencia de origen IPv6 de AS41635 deja sin resolver el acuerdo del /56 anunciado. El compromiso de calidad proporciona a los clientes un mecanismo de medición y crédito, aunque su alcance de producto y sus exclusiones limitan lo que dice sobre la recuperación a escala de instalación.
Este nivel no es un veredicto sobre la calidad del servicio. Es una declaración sobre la distancia entre lo que puede observarse y lo que aún debe demostrarse. LiveHosting puede poseer registros de ingeniería actuales más sólidos de lo que publica. Un comprador debería solicitar verlos antes de colocar una carga de trabajo cuyo coste de fallo supere el valor de los créditos de servicio.
La conclusión concreta es que la capacidad comercializada es creíble como servicio en vivo, pero aún no está probada como capacidad en estado de fallo. La próxima evidencia útil no es otra configuración de servidor. Es una prueba actual de alimentación, refrigeración y transporte que muestre lo que permanece en línea cuando una de las dependencias comunes se retira deliberadamente.