Mida antes de repatriar, dimensionando una salida del cloud a partir del uso real

El error más caro al dejar el public cloud es copiar la infraestructura tal como está. Los entornos cloud crecen aprovisionando, y aprovisionado no es usado: tamaños de instancia elegidos con prisas, volúmenes dimensionados para un pico que nunca llegó, servicios que nadie recuerda haber arrancado. Muévalo uno a uno y arrastra el desperdicio a un contrato fijo. Así se mide lo que realmente funciona antes de que nadie dibuje un nuevo diseño.

El problema: la factura describe lo que alquila, no lo que usa

Una factura del cloud enumera tipos de instancia, tamaños de volumen y niveles de servicio. Nada de eso le dice cuánta CPU consumió su aplicación en su hora más ocupada, cuántas IOPS realizó realmente la base de datos, o cuánta memoria contiene de verdad la caché. Esos son los números que necesita un diseño físico o de private cloud, y el proveedor cloud lleva todo este tiempo registrando la mayoría de ellos por usted.

Paso uno: inventaríe todo, no solo los servidores

Empiece con una lista completa de recursos en cada región que haya usado alguna vez. Las etiquetas ayudan, pero los recursos sin etiquetar son exactamente los que necesita encontrar:

for r in $(aws ec2 describe-regions --query 'Regions[].RegionName' --output text); do
  aws resourcegroupstaggingapi get-resources --region "$r" \
    --query 'ResourceTagMappingList[].ResourceARN' --output text
done | tr '\t' '\n' | sort > inventory.txt

Después agrupe por servicio. Los servidores suelen ser la parte fácil. El trabajo está en lo que los rodea: bases de datos gestionadas, cachés, balanceadores, zonas DNS, colas, buckets de objetos, certificados, funciones programadas, y los roles IAM y grupos de seguridad que lo unen todo. Cada uno necesita un propietario y una decisión: mover, sustituir, mantener o retirar.

Paso dos: lea percentiles, no medias

Para cada recurso de cómputo, extraiga al menos un mes de utilización, y lea el percentil 95 y el máximo en lugar de la media. Una media de una noche tranquila y una tarde ocupada no describe ninguna de las dos.

aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 --metric-name CPUUtilization \
  --dimensions Name=InstanceId,Value=<instance-id> \
  --start-time "$(date -u -d '-30 days' +%FT%TZ)" --end-time "$(date -u +%FT%TZ)" \
  --period 3600 --extended-statistics p95 \
  --query 'Datapoints[].ExtendedStatistics.p95' --output text \
  | tr '\t' '\n' | sort -n | tail -1

La memoria es el hueco: las métricas del hipervisor no ven dentro del guest. Si el agente de CloudWatch está instalado, sus métricas de memoria están en el namespace CWAgent. Si no, recoja desde dentro de las instancias durante un par de semanas con sar o con su monitorización existente antes de dimensionar nada. Adivinar la memoria es como los diseños acaban hambrientos o derrochadores.

Haga lo mismo con el storage: VolumeReadOps y VolumeWriteOps por volumen le dan las IOPS reales, y VolumeReadBytes y VolumeWriteBytes el caudal. Para las bases de datos gestionadas, lea CPUUtilization, FreeableMemory, ReadIOPS y WriteIOPS. Para las cachés, la memoria realmente usada y el número de conexiones. Para el tráfico, NetworkOut por instancia muestra de dónde sale realmente el egress, lo que importa para diseñar la red, no solo para la factura.

Paso tres: construya la hoja de dimensionamiento

Ponga las mediciones en una hoja, una fila por carga de trabajo:

Carga de trabajo	CPU p95	Memoria usada p95	IOPS p95	Cuota de egress	Crecimiento esperado

Después dimensione cada una a su pico medido con un margen que pueda justificar, no a la instancia en la que funciona hoy. Dos reglas que aplicamos a cada diseño:

• Nunca dé a una máquina virtual más vCPU que núcleos físicos tiene un socket de CPU, ni más memoria de la que sirve un nodo NUMA. Una VM repartida entre sockets paga una penalización de memoria remota en cada acceso y a menudo funciona más despacio que una más pequeña. Si una carga de trabajo necesita más de un socket, necesita escalar horizontalmente o pasar a bare metal.
• Dimensione bien, y después pare. Las infraestructuras cloud están sobredimensionadas de forma rutinaria porque redimensionar era arriesgado. En infraestructura dedicada el tamaño correcto es más barato y, con frecuencia, más rápido.

Paso cuatro: mapee cada servicio gestionado a algo de su propiedad

Para cada servicio gestionado, escriba qué lo sustituye y qué cambia para la aplicación:

Servicio gestionado	Sustituto de su propiedad	Qué nota la aplicación
MySQL o MariaDB gestionado	Percona XtraDB Cluster o MariaDB replicado, detrás de ProxySQL	un nuevo endpoint; nada más
Redis gestionado	Valkey o Redis con Sentinel	conectar a través de Sentinel
Application load balancer	Par de HAProxy con direcciones flotantes	nada
DNS gestionado	su propia infraestructura PowerDNS	nada, si el movimiento se secuencia
Kubernetes gestionado	OpenShift u OKD sobre bare metal	los mismos manifests, con las storage classes revisadas

Algunos servicios no tienen un equivalente razonable en su nuevo hogar, o son baratos y cómodos donde están. Lo híbrido es una respuesta legítima: manténgalos en el cloud y conecte los dos de forma privada. Un plan de repatriación que intenta moverlo todo suele ser el que se atasca.

Paso cinco: diseñe para los dominios de fallo que deja atrás

Las availability zones hicieron un trabajo real por usted, así que el nuevo diseño debe hacer el mismo trabajo de forma explícita. Mapee cada capa a hosts separados, cabinas de storage separadas y, donde importe, sedes separadas. Los servicios con quórum (bases de datos, cachés, coordinadores) necesitan tres miembros en tres dominios de fallo. Escríbalo capa por capa; «era multi AZ» no es un diseño.

Paso seis: planifique el movimiento del DNS como la ruta crítica que es

El DNS suele ser lo último en moverse y lo único que puede romperlo todo de golpe. Si la zona está firmada con DNSSEC, secuencie el cambio de claves y del registro DS para que los resolvers validadores nunca vean una cadena rota. Describimos el movimiento completo de un cliente fuera del DNS de AWS en nuestra página de managed DNS.

Su lista de comprobación

• Un inventario completo en todas las regiones, con un propietario y una decisión por recurso.
• Al menos un mes de utilización p95 y de pico para CPU, memoria, IOPS y egress.
• Memoria medida desde dentro de los guests, no adivinada.
• Una hoja de dimensionamiento que dimensiona a picos medidos, con las VM dentro de un solo socket.
• Cada servicio gestionado mapeado a un sustituto, o mantenido deliberadamente.
• Dominios de fallo diseñados explícitamente, y el movimiento del DNS secuenciado.

Si está sopesando volver a infraestructura de su propiedad, con gusto empezamos por las mediciones.

CTA

Hable con un ingeniero

Related

Relacionado: Repatriación del cloud (cloud repatriation) y salidas de colocation · Migraciones de datacenter gestionadas, ensayadas · Construcción de plataformas de alta disponibilidad