Parallels Cloud Server 6

Tienen experiencias en esta plataforma?
He leído en Parallels que ofrece la possibilidad de crear un Cloud usando máquinas estándard con almacenamiento local. Sabiendo que no podrá tener la flexibilidad de los sistemas de disco centralizados, seguro que permite costes menores.
No se cómo gestionará las ampliaciones y migraciones de nodo de los VPS.
Alguien lo ha usado?

 

Si tiene la flexibilidad de los sistemas de disco centralizados, incluso mayor, depende de como lo configures.

Trata el espacio consolidado como si fuera un cluster de discos estándar, la gestión es via panel de control y linea de comandos, relativamente sencillo para expertos.

Precio carillo, es dependiente de la capacidad en GB que utilices, las licencias son así.

Lo probamos en la fase Beta y estamos por montar una plataforma local para pruebas más exhaustivas, espero en uno o dos meses poder publicar un análisis completo de como va el tema.

Teoricamente es mas seguro que un cluster de discos estándar, ya que los segmentos que puedan fallar físicamente (incluidos nodos enteros) están redundados en n sitios (Tu lo configuras)

 

Yo lo he probado a fondo en un entorno de laboratorio.

En "resumido" te diría que la parte del storage funciona siempre que montes una red dedicada a storage sobre 10G y utilices discos SSD al menos para las cachés. Ni se te ocurra planificarlo en producción con una red 1G para el storage porque tendrás cuellos de botella insalvables.

Pero tiene todavía muchos bugs. Es como si fuera una alpha-beta-yamelotestearánlosclientes. De hecho está prevista una "mega actualización" para el mes de marzo-abril.

Una de las cosas que no me gustan hace por ejemplo es levantar instancias en caso de que se te caiga un nodo. La información (los datos) en teoría están "ahí", pero tienes que "migrar" y levantar las máquinas virtuales a mano en otro nodo no sin previamente "tunear" sus archivos de configuración. Con los contenedores es peor porque los archivos de configuración de los contenedores no se guardan en la parte del almacenamiento (storage), como en las VM, sino en la parte no compartida del mismo nodo, por lo que si el nodo se cae tienes que tirar de backup aunque tengas los datos porque no tienes los archivos de configuración que dicen dónde están esos datos (solucionable metiendo mano y haciendo copias de seguridad de los conf, pero es algo que el sistema no gestiona por sí mismo). En las VM no pasa y sus conf se guardan en la parte de storage compartida, pero aún así hay que meterles mano en caso de crash total de un nodo.

El tema de las réplicas no afecta demasiado al rendimiento de los discos (chunks) siempre y cuando no pierdas una proporción muy gran de de la
parte ocupada de storage, porque una vez te ocurre eso (por ejemplo cortando a saco la potencia a un nodo de storage) si sacas el chunk afectado del cluster o lo reemplazas por otro, el sistema se pone a replicar los datos que "faltan" y si tienes discos lentos o una red mal dimensionada ralentiza todo bastante.

Luego tienes el tema de las tarjetas de red emuladas. En la que utiliza por defecto en los despliegues de instancias (VMs, no contenedores), utiliza el driver e1000 que da bastantes problemas con el checksuming. Puedes cambiarlo por el rlt, pero a manivela y cualquier cambio que hagas desde el PVA se lo carga, por lo que el Power Panel se vuelve inutilizable por parte del cliente usuario final dado que cualquier reinicio de una VM hace que ésta pierda la configuración de la red que has tenido que modificar desde la shell (desde el PVA no se puede).

Esto último es precisamente una lata. Te metes en un nodo, cambias características de una VM desde la shell (por ejemplo el iolimit, iopslimit o lo que sea) y si posteriormente haces algún cambio desde el PVA por ejemplo, se carga la configuración del VM que hayas hecho desde la shell.

Vamos, que ni la guarda ni tienes opcíon de guardarla (no existe la opcíon --save como en los Virtuozzo).

Hay bastantes más cosillas. El tema de gestión de los backups es otra cosa que no funciona muy bien. De hecho hay comandos que no funcionan en absoluto si los lanzas desde la shel (bug reconocido por Parallels). Las aplicaciónes de migración no funcionan en absoluto y en Parallels no

saben decirte por qué, etc, etc, etc.

En mi opinión todavía no es un producto para ser utilizado en producción. Ya veremos con la próxima actualización, que según Parallels solucionará cientos de bugs, pero de momento da demasiados quebraderos de cabeza y hay que hacer muchas ñapas para que funcione decentemente, amén de la documentación que se pasa muchas cosas importantes por alto y tienes que descubrirlas consultando al soporte de Parallels (que ya sabéis lo rápido y ágil que es...).

Prometedor, pero fieles a su estilo, Parallels sigue utilizando al usuario como betatester.

 

El tema de "utilizar máquinás estándar" para el almacenamiento es en mi opinión una quimera. Tienes que utilizar discos rápidos sí o sí. Eso de usar servidores viejos o switches que tengas tirados por ahí.... Ya sé que Parallels lo vende así, pero eso no funciona. Si quieres montar algo decente la red tiene que ser 10G y los discos tienen que ser rápidos y - llevando la contraria a Parallels - en RAID 10. Como montes los discos en RAID0 lo vas a flipar el día que se te vayan 2 ó 3 nodos enteros al garete por culpa de un disco "defectuoso" (y sí: estas cosas pasan con más frecuencia de lo que uno pueda pensar).

Hay por ahí un proveedor español que se ha atrevido a montar un cloud de esos con Parallels Cloud Server y lo vende como tal. Conociéndole, conociendo el estátus de la actual version del PCS y viendo el precio de venta que ha sacado ese proveedor, miedo me da lo que ha montado porque estoy seguro de que no usa ni 10G, ni switches en alta disponibilidad ni discos rápidos.

 

cincinnati, En eso estoy de acuerdo contigo, será buen producto, pero es beta y no es para montarlo "aprovechando restos de otras máquinas", necesita configurarse sobre nodos dedicados con RAID10, como cualquier configuración que tenga que funcionar las 24 horas, pero lo que si te permite es "reconvertir" máquinas que ya tengas y no tener que comprar una array de discos nuevo y tirarlas...

Lo que te permite es ir añadiendo nuevos nodos para aumentar el tamaño y la redundancia de forma sencilla y muy segura, en cuanto a la velocidad, lo ideal es 10G, pero como la información es "distribuida entre los nodos", el trafico se reparte bastante bien con una red de 1G.

La idea es buena, la implementación también, la fiabilidad (pendiente de versiones) buena, es decir es una base para montar un buen cloud, el precio es otro cantar....

Veo que te lo has currado a fondo, yo hice una pruebas rápidas, porque con la estructura que necesitas, no está para pagarlo en softlayer para pruebas, por eso vamos a montar un laboratorio en local, con servers de generaciones anteriores para hacer las pruebas, que veo que tu ya has hecho

Así que se agradece el análisis, te debo una cerveza con tapa y esperamos a la próxima revisión para retomarlo...
Se agradece el informe...

 

Sip. Así es.

Lo de la red 10G me refería sólo a la red independiente para el storage y es que el problema es que el sistema mantene al menos 2 réplicas de todo y por tanto hay nodos que actúa como "clients" que tiran del almacenamiento de los nodos que actúan como "chunks". Poniendo un simil, es como si tienes un cluster con varios nodos de frontend tirando de varias cabinas que además se sincronizan entre ellas.

Esto es: tienes 3 tipos de flujo de datos entre los servidores que actúan como "chunk" (storage):

1.- La lectura de datos de disco desde chunk al client
2.- La escritura de datos de disco desde el client al chunk
3.- La réplica de datos entre los chunks (entre todos los chunks)

Si montas pongamos 20 servidores, 10 de ellos que actúen como clients y otros 10 que actúen como chunk (storage) y metes pongamos 30 máquinas virtuales con 3 GB de RAM cada una en cada client, el tráfico de storage no lo puede absorver una red 1G (lo he probado y las latencias se disparan).

Si quieres utilizar una red 1G en lugar de 10G, hay dos posibles "ñapas" intermedias: una es montar una caché local en cada cliente de forma que en dicha caché se almacenen los datos que son accesibles con mayor frecuencia. La otra es que cada client actúe a la vez como chunk local reduciendo la separación máxima entre chunks y permitiendo que escriba en los chunks locales los datos relativos a las VM que crees en ese client de forma que as lecturas tengan lugar en local sin tirar de la red de almacenamiento, si bien ten en cuenta que las escrituras sí harán uso de la red de almacenamiento para el tema de las réplicas y que si haces esto no puedes mover las VMs en caliente de forma rápida porque te tendrás que llevar los datos de la VM a migrar de un client a otro (cosa que no ocurre si el client es sólo client y no chunk).

En fin. Hay que seguir probando.

Me apunto a esa tapa

 

Les dejo mi experiencia de usuario.

He estado probando el sistema como usuario/administrador y puedo confirmar rendimientos superiores a los de un VPS con características similares en el mismo proveedor.

Desconozco con qué máquinas lo han implementado, la diferencia de potencia entre las máquinas de los dos sistemas, ni las diferencias de carga que soportan los sistemas. Evidentemente al ser el producto PCS6 nuevo deben estar muy vacías las máquinas.

Sin más quería anotar que el sistema se ha mostrado estable durante los días de mis pruebas.

Saludos