PREGUNTAS FRECUENTES

La migración sólo puede realizarse manualmente. Para realizar la migración es necesario preparar las VM: cambiar el SO invitado al modo de arranque UEFI, exportar las VM a ova/ovf, enviarnos el ova/ovf resultante para que podamos importarlo. Un poco más adelante estará lista una herramienta para que el usuario pueda realizar esta tarea.

En una nube pública, como en vCloud, sólo es visible la capa virtual. En su instalación, también puede ver la capa física, como en vSphere.

En primer lugar, se añade un nodo al clúster. A continuación, las máquinas virtuales se migran a los pools recreados utilizando los nuevos discos. En la versión 2.1, se implementará un mecanismo para aumentar el espacio sin migrar las máquinas virtuales, que permitirá ampliar el pool en 1 disco.

Puedes añadir recursos a hosts existentes. Una opción más pesada es añadir hosts a un cluster.

Las cuotas de vDC son gestionadas por el propietario del sistema y la solicitud de recursos se realiza mediante procesos externos.

Una unidad SSD de 1 GB cuesta más que un HDD, lo que compensa la economía del cálculo de la topología. Por el momento, ofrecemos vStack en discos SSD, ya que consideramos que los HDD no están actualizados. Sin embargo, estamos preparados para añadir rápidamente soporte HDD si fuera necesario.

En cada nodo, el número mínimo de discos es igual al número de nodos. Este postulado se deriva matemáticamente, de lo contrario el principio de hiperconvergencia y la función de conmutación por error carecen de sentido y el fallo de al menos un disco será fatal.

Presentar una VM a un datastore externo es un enfoque convergente. En este caso, se violan los principios de la hiperconvergencia.

Puede realizar copias de seguridad mediante el sistema operativo invitado. Para ello, es necesario instalar un agente de copia de seguridad para la solución de copia de seguridad seleccionada, conectarlo al servidor de copia de seguridad, elegir las políticas de copia de seguridad/conservación y programarlas.

Sí, es necesario fijar la ubicación de los discos en las ranuras del servidor, trasladar los discos al nuevo servidor y, a continuación, cablear el nuevo servidor al hardware de red. Todo esto es una ventaja de la hiperconvergencia.

Por el momento no existe la posibilidad de añadir nodos adicionales al clúster, pero está previsto hacerlo en un futuro próximo. Ahora mismo, esta capacidad está disponible sin interfaz de gestión en el servicio Managed vStack.

Emitimos mensualmente un informe de utilización de los recursos del clúster. Si es necesario, podemos implementar estos informes con discreción a las máquinas virtuales.

Recomendamos 10Gbe. Si el rendimiento de E/S es importante, 25Gbe es una prioridad.

Sí, es posible, pero preferiblemente con al menos 8 núcleos. Por regla general, una parte de las ranuras PCI no estarán disponibles en las placas base modernas.

No existe ninguna relación entre el número de nodos y el número de puertos de red. Nuestro mínimo recomendado es de 4 puertos por nodo en dos NIC diferentes.

Los nodos del cluster vStack pueden ser cualquier servidor x86 moderno con al menos 4 procesadores Intel. He aquí un ejemplo de configuración de nodo:

• Plataforma de servidor Intel 2U
• 2 x Xeon 6226R de 16 núcleos (2,90 GHz)
• Kit de 8 RDIMM de doble rango de 32 GB a 3200 MHz
• 4 x 960TB SSD SAS de lectura intensiva 12Gbps 512e 2.5in Drive PM5-R
• 2 x Intel 10/25Gbe Intel doble puerto SFP+ PCIe
• 2 x Fuente de alimentación (1 PSU) 750W Hot Plug

La sobrecarga ya es una gran diferencia. Aparte de eso, podemos destacar la semántica de la sincronicidad de capas. En una API discreta esto tendría que implementarse «manualmente», de ahí la necesidad de crear mecanismos para dicha sincronización en la capa de usuario.