Cómo probar un servidor cloud en una prueba: lista práctica

Cómo probar un servidor cloud en una prueba: lista práctica

Un servidor cloud es fácil de pedir y difícil de juzgar por una lista de precios. Una prueba corta muestra si la CPU, el disco, la red y el soporte encajan con tu carga, pero solo si llegas con un plan. DCXV no ofrece una prueba gratuita de autoservicio. Se puede solicitar una prueba corta, de unos 3 días, escribiendo a sales@dcxv.com. Concederla queda a criterio de DCXV, así que aquí no hay promesa de aprobación; confirma por escrito la duración, el tamaño, la ubicación y los posibles cargos antes de empezar. Una imagen de evaluación de Windows Server es un medio de Microsoft, no una prueba de DCXV, y no incluye licencias RDS de usuario.

Tres días dan un primer veredicto, no una evaluación completa. Imprime esta página, marca las casillas y anota el número junto a cada resultado.

Antes de empezar: define qué significa bien

• Describe la carga en una frase.
• Elige dos o tres cifras para aceptar o rechazar: tiempo de respuesta, tiempo de consulta, tiempo de restauración.
• Escoge la ubicación más cercana a tus usuarios, Praga o Covilhã; la guía de ubicación explica el equilibrio.
• Pide un tamaño cercano al que comprarías. La guía de dimensionado ayuda; los presets de la página de servidores cloud parten de EUR 15.00/mes por 2 vCPU, 4 GB de RAM y 40 GB NVMe (comprobado 2026-10).
• Lee la política de uso aceptable en /policy.

Día 1: desplegar y verificar el acceso

• Anota el tiempo desde el pedido hasta un acceso funcional; el sitio indica que suele ser de unos 10 minutos.
• Entra como root por SSH (Linux) o RDP (Windows): conectarse por SSH.
• Abre una vez la consola de recuperación KVM, antes de necesitarla.
• Ejecuta lscpu, free -h, df -h y compara con tu pedido.
• Actualiza el sistema y comprueba que la IPv4 pública responde desde fuera.

Día 2: líneas base de CPU, memoria, disco y red

Pon los hilos igual al número de vCPU y mantén cada ejecución corta.

sysbench cpu --threads=2 --time=30 run
sysbench memory --threads=2 --time=30 run
fio --name=rand4k --filename=/root/fio.tmp --size=1G --rw=randrw --bs=4k --iodepth=16 --ioengine=libaio --direct=1 --runtime=30 --time_based
mtr -rwc 100 YOUR_SERVER_IP

• Ejecuta la prueba de CPU dos veces a horas distintas y anota ambos resultados.
• Anota IOPS y latencia del disco y luego borra /root/fio.tmp.
• Lanza mtr desde tu oficina hacia el servidor; cómo leer la salida de mtr explica las columnas.
• Descarga un archivo conocido y anota la velocidad. Un archivo, no una prueba de saturación.

Día 3: carga real, restauración, veredicto

• Despliega la aplicación real y reproduce tráfico normal, no una avalancha.
• Crea una instantánea, cambia un archivo, pulsa Restore y comprueba que el cambio desapareció. Restaurar detiene el servidor y descarta su estado actual. Las instantáneas son un complemento de pago: pregunta al soporte si se cobran en una prueba y elimina la tuya después.
• Abre la ventana Backups (fecha y tamaño de cada copia; guía de restauración). Restaura solo datos desechables y pregunta si habrá una primera copia dentro de 3 días.
• Hazle al soporte una pregunta real y mide el tiempo hasta la primera respuesta útil.
• Rellena la tabla de evaluación y decide.

Área	Qué anotar	Aprobado si
CPU y memoria	sysbench, dos ejecuciones	Estable y suficiente para tu pico
Disco	fio IOPS, latencia	Nada espera al disco
Red	mtr pérdida, media	Limpia para tus usuarios
Recuperación, soporte	tiempo, primera respuesta	Puedes recuperarte y recibir ayuda

Si consigues una evaluación más larga

• Semana 1: repite las pruebas del día 2 por la mañana, por la tarde y de noche.
• Semana 2: lleva tráfico real, vigila memoria y swap, reinicia una vez a propósito.
• Semana 2: prueba un cambio de plan; el disco no se puede reducir sin formatear.
• Semana 3: ensaya la migración, una restauración completa y la factura según la guía de costes.

Prácticas seguras de benchmark

• Prueba poco y breve: de 30 a 60 segundos, un archivo de 1 GB, y limpia después.
• La AUP prohíbe inundación, denegación de servicio, escáneres de puertos e IP, fuerza bruta y ataques. No los ejecutes nunca, ni contra tu propio servidor.
• Pregunta al soporte antes de algo pesado: horas de CPU al máximo, grandes transferencias, muchas conexiones. No pongas datos reales de clientes en un servidor de prueba.
• Una prueba corta es una muestra, no una garantía; los vecinos, la hora del día y la carga cambian los resultados.

Pide tu prueba

Escribe a sales@dcxv.com con la carga, el tamaño, la ubicación y la duración, y pregunta si cumples los requisitos. Para empezar ya, elige un tamaño en la página de servidores cloud.