Cuando configuré por primera vez un clúster Hyper-V 2012 de 2 nodos, la conmutación por error fue prácticamente instantánea. Tenía una máquina virtual Sql Server 2012 (en Win2012) con 8 GB de RAM asignados. Podría hacer rebotar el nodo en el que estaba viviendo y saltaría al otro nodo sin perder mi conexión Sql.
Luego agregué una segunda VM al cluster (clon de la primera VM), también con 8GB. Ahora la conmutación por error tarda un par de segundos y mi conexión Sql se restablece. ¿Es un factor de la cantidad de RAM que se debe mover? ¿Se ve afectado por la red? ¿Es la velocidad del disco de quórum?
En mi caso, ambos nodos están conectados al mismo DAS y los archivos VM se encuentran en CSV. Yo esperaría que los discos no sean un factor, ya que no es necesario mover nada. Todo debería ser RAM, ¿verdad? Entonces, ¿a medida que aumenta la RAM, disminuye el rendimiento de la conmutación por error?
Respuesta1
En retrospectiva, supongo que debería haberlo sabido. La respuesta se divide en dos partes, porque, en mi opinión, existe una conmutación por error planificada y una conmutación por error "real"/no planificada, y la conmutación por error planificada no cuenta.
Conmutación por error planificada
La conmutación por error planificada es en realidad solo el sistema de agrupación en clústeres que drena el nodo y luego lo reinicia por usted. Entonces, cuando reinicia directamente el nodo a través de RDP o "Detener servicio de clúster" en la GUI de la aplicación de agrupación en clústeres, lo primero que sucede es que las máquinas virtuales se desactivan en Live Migrated. Debido a que en realidad solo estás migrando en vivo las máquinas virtuales, el tiempo que lleva depende de lo que se debe transferir y de la conexión de red. Si tiene una NIC de 1 Gb, tardará un poco (~118 MB/seg). Cuanta más RAM tengan sus máquinas virtuales, másLas NIC más rápidas le servirán mejor.
Conmutación por error real
La conmutación por error no planificada/"real" se produce cuando se desconecta la máquina. En ese caso, el sistema de clúster inicia automáticamente la VM en otro nodo. El comportamiento hacia el mundo exterior es el mismo que si hubiera reiniciado la VM. Para la máquina virtual, es lo mismo que si la hubiera "apagado" y luego la hubiera reiniciado. Por lo tanto, una conmutación por error "real" siempre dependerá del tiempo que tarden las máquinas virtuales en iniciarse.
Tangente
Esto es una decepción para mí, conceptualmente, porque siento que toda la charla sobre clustering en la Red sugiere que el sistema de clustering oculta una falla ("dura") del nodo; se supone que es como si los servicios nunca bajó. Probablemente se propague por el hecho de que todas las páginas web que recuerdo haber leído probaron la conmutación por error de su clúster en software (conmutación por error planificada). Entonces, todo lo que realmente están haciendo es demostrar que Live Migration funciona como se anuncia (sin tiempo de inactividad desde la perspectiva del cliente).
Mi principal error fue no entender bien la conmutación por error. Además del concepto de tener un servidor de respaldo caliente/tibio/frío, donde se produce una conmutación por error automática en un servidor caliente, también existe una conmutación por error caliente/tibio/frío. Como se mencionóaquí, la conmutación por error en caliente es instantánea, la conmutación por error en caliente se mide en segundos y la conmutación por error en frío se mide en minutos. Fui ingenuo al suponer que todo fallo automático es "caliente". Supongo que esperaba algún tipo de magia con la RAM donde el clúster actualizaría una copia de la RAM de la VM en otro nodo, algo así como el envío de registros de transacciones con Sql Server. Pero eso requeriría un canal de comunicación entre máquinas que sea al menos tan rápido como la RAM para garantizar que funcione.