Cita:
Iniciado por Apolo 
No necesariamente, pues el uso de disco (I/O) sigue siendo compartido, y ese sigue siendo un inconveniente tanto para VPS, como para hosting compartido y semi-dedicado. Además, un VPS con altas cargas, de todas maneras afectará el rendimiento global de las demás cuentas VPS en el mismo nodo... y eso sin mencionar que casi todos los proveedores de VPS sobre-venden recursos (RAM) de manera increible.
No, Apolo no todos, nuestra calidad de servicio se basa en la siguiente fórmula:
Memoria total (10 o 12G) + SWAP standar en UNX (2G)- Memoria real reservada para compartir como busrtable (2 a 4 G) / 256MB = Número VPS máximas por servidor.
A este número se le descuenta un 10% para mantener un margen de seguridad.
Si aplicas esta fórmula la calidad de un servidor VPS trabaja con mucho mejor rendimiento incluso que un dedicado, por ejemplo un sólo servidor VPS con 384Mb puede mantener hasta 100 sitios con base de datos y tráfico medio sin ningún problema en la calidad de servicio.
La fórmula recomendada para bajo precio y sobre vendida como tu dices, es una técnica que nosotros bautizamos como xtremeswap, y es la siguiente.
Memoria total (4G) + SWAP doble de la memoria (8G) / 256MB = Número VPS máximas por servidor. (y encima sobrevenden
)
Como la memoria SWAP en virtuozzo es un recurso compartido más simula que el total real de memoria a compartir es la Principal + SWAP, osea 4 + 8 =12 G, es decir unos 50 VPS con 4 GB reales.
Indudablemente no quere decir que todos lo hacen, pero teniendo en cuenta que en el mismo manual de configuración de Virtuozzo te dicen que puedes poner el SWAP del mismo tamaño que la memoria y la manía de la gente de bajar precios "por que hay que vender barato" saca tus conclusiones.
En cuanto a lo del I/O te puedo asegurar que si utilizas un buen servidor con RAID 10 y la instalación es correcta no te dará muchos problemas, si tienes sitios que tienen gran consumo de DD.BB, que es lo que generalmente produce el I/O, es mejor tener uno o dos servidores sin panel exclusivos para las DD.BB. de alto consumo.
Perdona que de una explicación tan extensa pero creo que va siendo necesario de explicar el porque las diferencias de precio entre unos y otros proveedores
Cita:
Iniciado por Apolo Yo creo que depende del proveedor, pues 1 o 2 días me parece demasiado tiempo. Una restauración completa, incluyendo montaje de nuevo disco y restauración de backups, tardará unas 4 horas, aunque por supuesto hay muchas variables en juego.
Insisto, en el caso de que seas una empresa seria y tengas servidores en reserva o una buena cuenta en tu datacenter si lo harás en unas horas, pero en el 90% de los casos que tienen un solo servidor o 2 deben de esperar que les hagan un "OS reload" que tarda entre 2 (raro) y 24 horas, transferir los datos del servidor de backups, si son unos 50 o 100 GB de datos tambien se toma su tiempo, en el caso de que uses DiskSync o similar todavía te quedarán unas horas, pero si además has utilizado un backup tipo "panel de control" prepara otras muuuchas horas hasta que todo quede restaurado, corrígeme si estoy equivocado...
Cita:
Iniciado por Apolo Por cierto, si una cuenta VPS es la que tiene un problema, ciertamente se puede resolver muy rápidamente, pero si es el nodo VPS el del problema, el asunto puede tomar incluso mucho más, sobre todo porque generalmente en los nodos VPS se ocupa mucho más espacio en disco.
Indudablemente la caida de un nodo indudablemente es más problemática, pero lo habitual es que tengas las copias del día anterior en otro de tus nodos, simplemete las vas levantando en otros nodos que tengas mas desocupados y listo, en unos minutos tienes todos tus VPS funcionando de nuevo, por supuesto asumiendo que todos los nodos estén en el mismo rack y tu manejes tus IP.
Con este sistema podrás ver que se puede llegar a tener una disponibilidad realmente buena y sobre todo mucho mas rápida.
La gran ventaja de un VPS que funciona bien es que es el mismo reseller el que ve claramente cuando necesita crecer y añadir mas espacio en disco o mas memoria a su servidor.