Guía para decidir mejor
Cuándo conviene separar las webs de clientes en distintos servidores
Separa por riesgo y carga comprobados, no por un número fijo de webs por servidor.
Separar las webs de distintos clientes en varios servidores conviene cuando comparten riesgos que no deberían compartir: una caída, un pico de carga, un incidente de seguridad o una obligación de acceso. No existe un número mágico de webs por VPS. La decisión se basa en impacto, aislamiento necesario, recursos medidos y capacidad de operar más máquinas.
Cuatro motivos para separar
- Impacto: una tienda crítica no debe quedar indisponible porque otra web ejecuta una importación o consume espacio.
- Seguridad: si clientes distintos requieren límites de confianza más fuertes, usuarios y bases de datos separados dentro de un mismo sistema quizá no basten.
- Capacidad: picos coincidentes de CPU, memoria o E/S dejan poco margen para todas las aplicaciones.
- Operación: versiones incompatibles de PHP, mantenimiento en horarios diferentes o requisitos contractuales pueden justificar entornos distintos.
Una web con gran tráfico no obliga automáticamente a dividir: primero investiga caché, consultas, tareas y límites. La monitorización aporta datos para decidir.
Qué ganas y qué pagas
Separar reduce el radio de impacto y permite escalar o mantener clientes por separado. A cambio añade servidores, licencias, copias, alertas, parches y coste operativo. Si no tienes responsables para atender esas tareas, repartir webs puede aumentar el riesgo. Un VPS único sigue siendo una opción razonable para proyectos compatibles y poco críticos si existe aislamiento por cuenta y copias independientes; consulta cómo prepararlo.
Ejemplo de decisión
Supón tres webs corporativas y una tienda con campañas. Registra picos, ingresos afectados por caída, accesos de cada equipo y ventanas de actualización. Si la tienda tiene picos que degradan a las demás o necesita cambios urgentes fuera de su calendario, sepárala o establece límites medibles y prueba que funcionan. No traslades una base de datos en producción sin un corte planificado y comprobación de pedidos nuevos.
Plan de separación
Inventaría dominio, correo y DNS; crea copias probadas; prepara el destino; valida rutas, SSL y formularios; coordina el cambio de DNS; conserva el origen durante la comprobación. Define quién responde a cada alerta. La guía de operación de clientes cubre propiedad y accesos. Para presupuestar configuraciones de IDEIHOSTING, compara sus VPS publicados y confirma por contrato el alcance de administración antes de proponerlo al cliente.
Distribuye proyectos por riesgo, no por orden de llegada
Agrupa aplicaciones que compartan propietario, nivel de criticidad, horario de mantenimiento y requisitos técnicos. Separa primero la que pueda afectar a otras por carga, permisos o cambios frecuentes. Antes de repartir, identifica dependencias comunes: DNS, correo, base de datos externa, copias y monitorización pueden seguir siendo puntos únicos de fallo aunque las webs estén en servidores distintos. Mantén un mapa de qué proyecto vive dónde, quién puede acceder y qué se restaura primero. Revisa la distribución cuando cambien las cargas o los contratos; dividir por dividir añade coste y complejidad sin mejorar necesariamente la continuidad.
Para decidir si varias marcas comparten WordPress, compara una instalación frente a varias y evalúa Multisite solo si hay gobierno común. Si la preocupación principal es continuidad, empieza por mapear la dependencia de un único servidor y sus servicios asociados.