Blog Tecnológico

Blog everyWAN

Tecnología, ciberseguridad y tendencias IT que importan

Análisis Profundo
Ciberseguridad
Tendencias IT
Filtrar por:
Armario de cableado de red con latiguillos de pares trenzados y paneles de parcheo
8 min lectura

Caída de Azure: cuatro puertas y el sitio donde guardabas el plan B

El 30 de septiembre de 2026, cinco horas y cuarenta y cinco minutos de incidente en Azure. De los cinco servicios que Microsoft lista como afectados, cuatro son el camino hasta tu infraestructura y el quinto es Azure VMware Solution. Dentro: qué dice y qué no dice el parte oficial 7Q30-010, el reloj real de la detección, por qué la cifra de regiones que circula no está en la fuente, y qué pasa con tu procedimiento de contingencia cuando lo que falla es la consola.

Pasillo entre armarios de servidores en penumbra, con centenares de indicadores luminosos encendidos a la vez
7 min lectura

Tormenta de reintentos: la segunda caída la provocas tú

El 12 de junio de 2025 Google Cloud se cayó a lo grande. A los 40 minutos la mitigación estaba desplegada y las regiones empezaron a recuperarse, las pequeñas primero; us-central1 no quedó resuelta del todo hasta 2 h 40 min después de empezar el incidente. Lo que alargó esa región no fue el bug: fueron los reintentos. El informe público lo dice con todas las letras —«Service Control no tenía implementado el backoff exponencial aleatorizado apropiado para evitar esto»— y describe un efecto manada sobre la tabla de Spanner de la que dependía todo. Aquí contamos dónde vive ese mismo mecanismo en una empresa normal (el cron que tarda más que su intervalo, el backup que se solapa, los sesenta equipos que arrancan a la vez cuando vuelve la luz, la monitorización que aprieta justo cuando duele), por qué tres reintentos en tres capas son 64 intentos contra tu base de datos, los cuatro números que hay que tener escritos y cuándo NO tocar nada.

Técnico agachado detrás de un rack, con el portátil apoyado en el suelo técnico y un manojo de cables sueltos al lado
10 min lectura

Migrar a Proxmox no toca tus licencias; el failover sí

En toda reunión de migración sale la pregunta de las licencias de Windows, y la respuesta corta decepciona: cambiar de hipervisor no recalcula nada. La cuenta la cambia otra cosa, y Microsoft la tiene escrita en una sola frase: «License Mobility across Server Farms is not available for Windows Server, so each server must be licensed for peak capacity at all times». Cada servidor, capacidad punta, siempre. La licencia no sigue a la máquina virtual, así que el número depende de en cuántos nodos puede llegar a arrancar: 32 licencias de núcleo o 96, para exactamente la misma instalación. Qué cambió en SQL Server 2022, por qué el mito de AVMA no te afecta si vienes de vSphere y por qué una regla de afinidad de Proxmox es un control útil pero no una frontera contractual.

Nodos idénticos apilados en un rack, cada uno con su pantalla y su etiqueta
9 min lectura

Tu Ceph de tres nodos no se cura solo: aguanta

Un disco muerto en un clúster de tres nodos se arregla solo si queda otro disco en ese mismo servidor: la regla de CRUSH baja a otro OSD del mismo host. Un HOST muerto, no. Con réplica 3 y el dominio de fallo en «host» —lo que pone Proxmox por defecto— no existe un cuarto sitio donde dejar la tercera copia, así que los grupos de colocación se quedan en active+undersized+degraded hasta que vuelva el nodo. Y el clúster sigue sirviendo, que es justo por lo que nadie lo mira. Los temporizadores reales de Ceph (20 segundos, 10 minutos, 15 minutos), lo que no puedes tocar mientras dure la ventana degradada, por qué la recuperación puede costarte el quórum de corosync y por qué el número que importa no es cuántos nodos tienes sino cuántos sitios distintos.

Pasillo de un centro de datos con dos filas de armarios de rack idénticos
9 min lectura

El cluster elige nodo contando invitados: anti-afinidad en Proxmox VE 9 y la regla que nadie declara

Cuando cae un nodo, el planificador de Proxmox VE elige dónde arrancan tus máquinas dadas de alta en HA. En un cluster recién instalado lo hace contando invitados activos: no sabe que la 101 es la segunda pata de la 100. Proxmox VE 9.0 trajo las reglas de afinidad para poder decírselo, con una asimetría que conviene conocer —la regla que fija a un nodo es una preferencia, la que separa dos máquinas es una orden— y una aritmética que decide si tu VM arranca degradada o no arranca.

Pasillo estrecho de un centro de datos, con un rack abierto de paneles de parcheo de fibra en primer plano y latiguillos aguamarina y amarillos recogidos en las guías de cable
10 min lectura

La redundancia no sobrevive al procedimiento

El 1 de septiembre, una actualización de capacidad programada desconectó de forma secuencial el 100% de los caminos de fibra de una parte de la zona us-central1-b de Google Cloud, en trece minutos. El informe describe justo antes una arquitectura correcta: caminos físicamente separados, alimentación diversa, tolerancia a fallos dobles y triples. Un estudio de Berkeley de 2003 ya explicaba por qué no sirvió: el error de operador no es más frecuente que el de hardware, es que se enmascara peor.

Servidores de rack idénticos apilados en un carro metálico, pendientes de montar, delante de un rack a medio poblar
5 min lectura

Corosync suma 650 milisegundos por cada nodo: el reloj que tu clúster actualizado sigue arrastrando

El tiempo que tarda un clúster Proxmox en rehacer la membresía tras perder un nodo no es fijo: crece 650 ms por cada nodo que añades, y con los valores de fábrica un clúster de 29 nodos llega a 45,21 segundos, justo donde la propia documentación pide corregirlo antes de que el watchdog de 60 segundos reinicie nodos sanos. Proxmox VE 9.2 lo bajó a 125 ms, pero solo al crear el clúster: los actualizados de la 8 a la 9 siguen con el valor viejo.

Servidor de almacenamiento abierto en un rack con las bahías de discos a la vista y una unidad extraída de su carro
9 min lectura

En Ceph la capacidad no la marca el clúster: la marca el disco más lleno

Un OSD por encima del 95 % detiene las escrituras de todo el clúster aunque «ceph df» siga enseñando decenas de teras libres. Los tres umbrales por defecto (0,85 / 0,90 / 0,95), por qué el mecanismo que repara se apaga cinco puntos antes que el que sirve, y la cuenta de capacidad con un nodo menos que casi nadie hace: con cuatro nodos el techo son 71 puntos, y 67 si quieres que la reconstrucción llegue a terminar.

Portal de un edificio antiguo con una única puerta acristalada, el portero automático y los buzones metálicos
5 min lectura

Tu proveedor de identidad no es una aplicación: es infraestructura

El lunes 24 de agosto, a las 03:38, empezó un ataque de denegación de servicio contra la plataforma digital compartida del Estado noruego. Cayeron diez servicios públicos y varios no tenían nada roto: se había atascado la puerta por la que se entra a todos. Digdir escribe en su página de estado que <code>eSignering</code> estaba inaccesible «a causa de las limitaciones en ID-porten», y también que las soluciones estaban «estables con las limitaciones que se han puesto» — parte de la caída la pusieron los propios defensores. Por qué el inicio de sesión único sigue siendo la decisión correcta, qué cambia cuando la puerta pasa a ser infraestructura y las tres preguntas que la reclasifican.

Pulsador de parada de emergencia en una pared: el nodo que se apaga a sí mismo para que el clúster pueda seguir
7 min lectura

La HA de Proxmox no evita la caída: la acorta (y a veces la provoca)

La propia documentación de Proxmox VE pone el techo: unos 2 minutos de detección y failover, y de ahí no se pasa del 99,999 %. Qué ocurre de verdad cuando muere un nodo (arranque en frío, no migración en vivo), por qué un nodo sano se reinicia solo a los 60 segundos de perder el quórum, los requisitos que se salta todo el mundo y cuándo no montamos HA.

Suscríbete a nuestra newsletter

Para recibir historias del mundo IT, novedades de everyWAN y ofertas exclusivas para suscriptores, date de alta a nuestra lista de correo

everyWAN
everyWAN