Resumen de la solución
Stratus everRun® SplitSite®
Protección de disponibilidad en todo el metro
Los desastres, ya sean causados por la naturaleza o por error humano, pueden resultar en la pérdida total de un data center físico, dejando potencialmente su negocio incapaz de funcionar durante días o incluso semanas. En las industrias reguladas, un problema en todo el sitio puede llevar a la pérdida de datos que pone en riesgo el cumplimiento de las normas, añadiendo significativamente a sus costos de tiempo de inactividad. Por ello, las empresas de industrias reguladas como la farmacéutica, la manufacturera y la de servicios financieros utilizan la protección de everRun SplitSite para garantizar que todos los datos se repliquen de forma segura y estén disponibles en todo momento. Aunque muchas organizaciones siguen posponiendo la implementación de una solución de recuperación por temor a los altos costos y a las demandas de recursos, no hay necesidad de que usted siga soportando el riesgo.
everRun SplitSite amplía la protección de su negocio de fallos de energía localizados y problemas en todo el edificio a máquinas físicas ubicadas en diferentes edificios o centros de datos. Con everRun SplitSite, si se produce un desastre en una ubicación, las aplicaciones y los datos están disponibles de inmediato, actualizados y totalmente operativos en la otra ubicación sin necesidad de personal de TI en la segunda ubicación. Una configuración de SplitSite conecta dos máquinas físicas (PM) en dos sitios geográficamente separados. SplitSite proporciona disponibilidad de las aplicaciones mediante la replicación síncrona. La capacidad de SplitSite de everRunpermite a un cliente ejecutar sus aplicaciones de manera eficiente, aunque con mayores latencias cuando los servidores de everRun están separados geográficamente o mediante conmutadores de red. Se pueden utilizar tanto niveles de protección de alta disponibilidad (HA) como de FT (tolerante a fallos), sin que haya cambios en las características o la disponibilidad. Al igual que en una configuración de un solo sitio, everRun detecta automáticamente las fallas de disco y de red y se configura alrededor de ellas. Y para las máquinas virtuales (VMs) con protección FT, everRun mantendrá las VMs funcionando sin tiempo de inactividad, incluso a través de una falla del PM o del sitio. Cuando un sitio o PM fallido se vuelve a poner en servicio, everRun resincronizará automáticamente las unidades de disco y la memoria de la VM.
everRun's SplitSite soporta despliegues tolerantes a los desastres que mantienen la redundancia del hardware, así como la redundancia de las salas de computación física y los edificios que las contienen. Al admitir la separación geográfica, esta potente solución tolerante a los desastres protege aún más a su empresa del tiempo de inactividad importante debido a eventos potencialmente catastróficos como inundaciones y cortes de energía. everRun SplitSite elimina el coste y el caos asociados a los productos típicos de recuperación reactiva. Stratus ve a menudo el uso de SplitSite en campus más grandes o en entornos metropolitanos como una alternativa en tiempo real a la recuperación de desastres en varios sitios.
Requisitos de la división del sitio y licencias
No existe una limitación de distancia universal para SplitSite, ya que entran en juego varios factores. Cualquier interruptor de red que intervenga aumenta la latencia y aumenta la posibilidad de que se pierda la conexión entre los nodos, lo que da lugar a un "cerebro dividido", una situación en la que ninguno de los dos servidores puede verificar que el otro sigue funcionando, lo que da lugar a que dos copias del mismo VM funcionen de forma independiente. Para todas las configuraciones de SplitSite, Stratus requiere que también se utilice el servicio de quórum porque una configuración de SplitSite aumenta la probabilidad de que se produzcan más escenarios de fallo de "split-brain".
Las configuraciones de SplitSite están sujetas a las especificaciones de máxima latencia: No más de 10ms de latencia de ida y vuelta del A-Link para VMs de HA y 2ms de latencia de ida y vuelta del A-Link para VMs de FT. La separación de hasta 10km (usando fibra de 1 Gbps) es una topología de red A-Link común que puede cumplir con los requisitos de latencia. El rendimiento de cada aplicación, incluso dentro de estas especificaciones de latencia, puede depender de la aplicación específica.
Sólo se necesita una licencia de uso de quórum y el cumplimiento de los requisitos de latencia para el apoyo de Stratus. De lo contrario, cualquier equipo de red y topología se acomodan. En una red corriente típica, una buena distancia entre los servidores es de 5 a 10 km. Sin embargo, Stratus tiene clientes que utilizan con éxito SplitSite hoy en día en escenarios en los que los PM están separados por una distancia de 50 km o más entre sí.
Una configuración de SplitSite requiere una cuidadosa planificación de la colocación de los componentes, para minimizar o eliminar las fallas que requieren el cierre de los VM. Es muy probable que sea necesario un entrenamiento específico o asistencia de servicios profesionales para desplegar SplitSite correctamente. Si un cliente utiliza SplitSite, está obligado a adquirir una licencia; sin embargo, Stratus no impone el uso de SplitSite a través de la activación de características. Sin embargo, se requiere una licencia de SplitSite para recibir soporte técnico en una configuración de SplitSite. Stratus ha elegido una separación física de 10 m como punto de demarcación de distancia razonable en el que exigir la licencia de SplitSite.
Servidores de Quórum y de SplitSite
Se requiere el uso de quórum para las configuraciones del SplitSite para protegerse contra la pérdida de datos (debido al cerebro dividido) y para permitir con seguridad que las máquinas virtuales se inicien automáticamente si un segundo everRun PM o sitio ha fallado. En una configuración SplitSite, se utilizará al menos uno, y óptimamente dos, servidores de quórum. Estos servidores se utilizan para protegerse de los fallos de la red que podrían hacer que los dos nodos de everRun perdieran la comunicación entre sí y operaran con split-brain. La disponibilidad de quórum es mejorada, y los escenarios de cierre obligatorio de VM son minimizados si el quórum es colocado en un tercer lugar y se implementa un diseño de red de quórum apropiado.
Si no hay servidores de quórum configurados, una falla en la red podría causar que los dos servidores de everRun perdieran toda la comunicación entre ellos. En la misma situación con servidores de quórum configurados, los VM redundantes en ambos nodos preguntarían al servidor de quórum por el estado de su par y tomarían las medidas apropiadas en base a la respuesta. Si el servidor de quórum no responde, una VM aislada se apagará. Siempre que la máquina virtual paritaria del otro servidor permanezca en contacto con el servidor de quórum, seguirá funcionando. Ambas instancias de la VM acuerdan qué servidor de quórum se está usando (eligiendo) antes de cualquier falla. Si el servidor de quórum primario falla, los nodos acuerdan elegir el servidor de quórum alternativo hasta que el primario vuelva al servicio. Durante la gestión activa de una falla, los nodos no pueden cambiar de servidor de quórum.
Los servidores de quórum son particularmente importantes en las configuraciones de SplitSite. La mejor práctica para SplitSite es colocar un servidor de quórum preferido en una tercera instalación y un servidor de quórum alternativo en una cuarta instalación. Sin embargo, también puede colocar el servidor de quórum alternativo con el servidor de quórum preferido y aún así obtener un servicio satisfactorio. Los servidores de quórum aseguran la integridad de las máquinas virtuales contra la división del cerebro, y permiten el arranque desatendido de las máquinas virtuales después de fallas específicas. La comunicación entre los servidores de quórum se realiza a través de la red de gestión.
Los servidores de quórum no requieren hardware dedicado ni tienen requisitos específicos de latencia de red. Funcionan como un servicio de Windows que puede ser instalado en casi cualquier estación de trabajo o servidor de Windows que se utilice para otros fines, siempre y cuando la computadora se deje funcionando las 24 horas del día. Sin embargo, nunca se debe ejecutar el servicio de quórum en un VM del mismo sistema everRun que lo utiliza.
Más sobre servidores de quórum
Un servicio de quórum es un servicio basado en el sistema operativo Windows desplegado en una máquina Windows distinta del sistema everRun . Los servidores de quórum proporcionan garantías de integridad de los datos y capacidades de reinicio automático para fallos específicos en un entorno everRun . Se puede configurar un par de PM everRun con 0, 1 o 2 servidores de quórum. Stratus recomienda encarecidamente la configuración de dos servidores de quórum: un servidor de quórum preferido y uno alternativo, especialmente para el funcionamiento del SplitSite. Si sólo hay dos sitios disponibles, se puede colocar quórum en uno de ellos sin riesgo de "split-brain". Sin embargo, si un PM se cae y el PM sobreviviente no puede comunicarse con el servidor de quórum (por ejemplo, porque es inaccesible en el mismo sitio que el PM caído), los VM del sitio sobreviviente se apagan automáticamente para evitar un posible escenario de "split-brain".
En una configuración SplitSite las mejores prácticas para el despliegue de quórum incluyen:
- Un servidor de quórum preferido ubicado en una tercera instalación, y un suplente ubicado en una cuarta instalación (o colocado cuidadosamente en la tercera)
- Los servidores de quórum deben estar lo más aislados posible. Si ambos deben colocarse en un sitio común (tercero), asegúrese de que no dependan de fuentes de energía o interruptores de red comunes
- La conectividad física entre un PM everRun y los servidores de quórum no debe pasar por el sitio del otro PM
- Colocar un servidor de quórum en el mismo sitio que uno de los PM de everRun asegura la integridad de los datos. Sin embargo, las fallas de ese sitio requieren que los PMs se apaguen (para asegurarse contra el "split-brain") hasta que se recupere manualmente
- La red de gestión conecta físicamente a los PM y a los servidores de quórum. Configure cada PM de everRun para usar una puerta de enlace diferente para llegar a los servidores de quórum para una mejor disponibilidad de los VM. Si los dos PM utilizan la misma puerta de enlace para llegar a los servidores de quórum, algunas fallas del sitio causarán que la puerta de enlace falle y requerirá que las VM se apaguen hasta que se recuperen manualmente.
Consideraciones sobre los servidores de quórum
- El software de servicio de quórum, puede instalarse en cualquier computadora de uso general o portátil con Windows Server 2016, Server 2012, Server 2008, Windows 10 o Windows 7; siempre encendido y con un mínimo de 100MB de espacio en disco y una tarjeta de interfaz de red con conectividad a la configuración everRun a través de la red de gestión
- Los servidores de quórum no deben residir en el mismo sitio que cualquiera de los PM cuando se despliegan en un SplitSite. Si tanto el servidor de quórum preferido como el alternativo fallan por una razón común, los VMs reducirán la redundancia con gracia, y luego continuarán operando usando un PM, hasta que se recupere un servidor de quórum. Cuando un PM y el servidor de quórum elegido fallan por una razón común, las instancias de VM que se ejecutan en el PM sobreviviente deben cerrarse...
- Si los servidores de quórum preferidos y alternativos deben residir en un sitio común, aliméntelos con fuentes de energía de CA (fases) separadas o configúrelos en dispositivos UPS separados, y minimice la red común necesaria para que el sistema everRun pueda acceder a ellos.
Requisitos de la red A-Link
- Los NIC deben ser al menos 1 Gb y full-duplex; use 10 Gb, si es posible.
- Los conmutadores y/o convertidores de fibra a cobre conectados a la red privada deben estar sin enrutar, sin bloquear y soportar IPv6
- Para los sistemas que ejecutan VMs protegidos por FT, los A-Links requieren:
- Un ancho de banda mínimo de 1 Gbps por VM
- Una latencia máxima entre sitios* de 2 ms, tiempo de ida y vuelta
- Para los sistemas que funcionan sólo con VMs protegidos con HA, los Enlaces A requieren:
- Un ancho de banda mínimo de 155 Mbps por VM
- Una latencia máxima entre sitios* de 10 ms, tiempo de ida y vuelta
- No utilice una tarjeta común (NIC multipuerto) para múltiples enlaces A
- Los A-Links pueden ser conexiones de fibra punto a punto o en una VLAN. Las VLANs usadas para conectar los puertos de los A-Links no deben filtrar ninguna comunicación entre los dos nodos de everRun
Requisitos de la red privada
- Los NICs deben ser al menos 1 Gb y full-duplex
- La red privada no debe ser compartida con un A-Link cuando se despliega una configuración de SplitSite
- La red privada puede ser una conexión dedicada de fibra punto a punto. Si no lo es, debe ser configurada en una VLAN privada. Las VLANs usadas para conectar los puertos de la red privada deben soportar IPv6 y no filtrar ninguna comunicación entre los dos nodos de everRun
Requisitos de la red de negocios
- Un sistema everRun requiere al menos una red de negocios. Configurar la red empresarial para ambos nodos en la misma VLAN
- Los nodos deben estar en el mismo dominio multicast de capa 2
- Conecta las redes de negocios de cada nodo a un interruptor separado del interruptor del otro nodo. Las VLANs usadas para conectar los puertos de la red empresarial deben soportar IPv6 y no filtrar ninguna comunicación entre los dos nodos de everRun
Requisitos de la red de gestión
- Por defecto, la red de gestión se comparte con una red empresarial. Si no se comparte, se siguen aplicando todos los requisitos de una red empresarial
- Configurar las puertas de enlace a una LAN de negocios para la gestión remota
* Calcular la latencia a 1 ms por cada 100 millas de fibra, más cualquier latencia añadida por interruptores o convertidores de fibra no enrutados y sin bloqueo.
