Ola Habr!
Despois das vacacións de Ano Novo, relanzamos unha nube a proba de desastres baseada en dous sitios. Hoxe contarémosche como funciona e mostraremos o que ocorre coas máquinas virtuais cliente cando fallan elementos individuais do clúster e falla todo o sitio (spoiler: todo está ben con eles).
Sistema de almacenamento na nube resistente a desastres no sitio OST.
Que hai dentro
Baixo o capó, o clúster ten servidores Cisco UCS cun hipervisor VMware ESXi, dous sistemas de almacenamento INFINIDAT InfiniBox F2240, equipos de rede Cisco Nexus, así como conmutadores Brocade SAN. O clúster está dividido en dous sitios: OST e NORD, é dicir, cada centro de datos ten un conxunto idéntico de equipos. En realidade, isto é o que o fai a proba de desastres.
Dentro dun sitio, tamén se duplican os elementos principais (hosts, conmutadores SAN, redes).
Os dous sitios están conectados por rutas de fibra óptica dedicadas, tamén reservadas.
Algunhas palabras sobre os sistemas de almacenamento. Creamos a primeira versión dunha nube a proba de desastres en NetApp. Aquí escollemos INFINIDAT, e aquí tes por que:
- Opción de replicación Active-Active. Permite que a máquina virtual siga operativa aínda que un dos sistemas de almacenamento falle por completo. Vouche dicir máis sobre a replicación máis tarde.
- Tres controladores de disco para aumentar a tolerancia a fallos do sistema. Normalmente hai dous.
- Solución lista. Recibimos un rack premontado que só precisa estar conectado á rede e configurado.
- Soporte técnico atento. Os enxeñeiros de INFINIDAT analizan constantemente os rexistros e eventos do sistema de almacenamento, instalan novas versións de firmware e axudan coa configuración.
Aquí tes algunhas fotos de desempaquetar:
Como funciona
A nube xa é tolerante a fallas dentro de si mesma. Protexe o cliente de fallos únicos de hardware e software. A resistencia a desastres axudará a protexerse contra fallos masivos nun sitio: por exemplo, fallos dun sistema de almacenamento (ou dun clúster SDS, o que ocorre con bastante frecuencia 🙂), erros masivos nunha rede de almacenamento, etc. Ben, e o máis importante: unha nube deste tipo aforra cando un sitio enteiro se fai inaccesible debido a un incendio, un apagón, a toma de posesión dun raider ou o desembarco alieníxena.
En todos estes casos, as máquinas virtuais cliente seguen funcionando, e aquí tes por que.
O deseño do clúster está deseñado para que calquera host ESXi con máquinas virtuais cliente poida acceder a calquera dos dous sistemas de almacenamento. Se o sistema de almacenamento do sitio OST falla, as máquinas virtuais seguirán funcionando: os hosts nos que se están executando accederán ao sistema de almacenamento en NORD para obter datos.
Así é o diagrama de conexión nun clúster.
Isto é posible debido ao feito de que se configura un enlace entre conmutadores entre os tecidos SAN dos dous sitios: o conmutador Fabric A OST SAN está conectado ao conmutador Fabric A NORD SAN e, de xeito similar, para os conmutadores SAN Fabric B.
Ben, para que todas estas complexidades das fábricas SAN teñan sentido, a replicación Active-Active configúrase entre os dous sistemas de almacenamento: a información escríbese case simultáneamente nos sistemas de almacenamento local e remoto, RPO = 0. Resulta que os datos orixinais almacénanse nun sistema de almacenamento e a súa réplica gárdase no outro. Os datos replícanse a nivel de volumes de almacenamento e os datos da máquina virtual (os seus discos, ficheiro de configuración, ficheiro de intercambio, etc.) almacénanse neles.
O host ESXi ve o volume principal e a súa réplica como un dispositivo de disco (dispositivo de almacenamento). Hai 24 camiños desde o host ESXi a cada dispositivo de disco:
12 rutas conéctano ao sistema de almacenamento local (rutas óptimas) e as 12 restantes ao sistema de almacenamento remoto (rutas non óptimas). Nunha situación normal, ESXi accede aos datos do sistema de almacenamento local mediante rutas "óptimas". Cando este sistema de almacenamento falla, ESXi perde camiños óptimos e cambia a outros "non óptimos". Así se ve no diagrama.
Esquema dun clúster a proba de desastres.
Todas as redes de clientes están conectadas a ambos sitios mediante un tecido de rede común. Cada sitio executa un Provider Edge (PE), no que as redes do cliente están finalizadas. Os PE están unidos nun clúster común. Se un PE falla nun sitio, todo o tráfico é redirixido ao segundo sitio. Grazas a isto, as máquinas virtuais do sitio que quedan sen PE permanecen accesibles a través da rede para o cliente.
Vexamos agora que pasará coas máquinas virtuais cliente durante varios fallos. Comecemos coas opcións máis lixeiras e rematemos coa máis grave: o fallo de todo o sitio. Nos exemplos, a plataforma principal será OST e a plataforma de copia de seguridade, con réplicas de datos, será NORD.
Que pasa coa máquina virtual cliente se...
A ligazón de replicación falla. Detense a replicación entre os sistemas de almacenamento dos dous sitios.
ESXi só funcionará con dispositivos de disco locais (a través de camiños óptimos).
As máquinas virtuais seguen funcionando.
O ISL (Inter-Switch Link) rompe. O caso é improbable. A non ser que algunha escavadora tola desenterra varias rutas ópticas á vez, que percorren rutas independentes e son levadas aos lugares a través de diferentes entradas. Pero de todos os xeitos. Neste caso, os hosts ESXi perden a metade das rutas e só poden acceder aos seus sistemas de almacenamento locais. Recóllense réplicas, pero os hosts non poderán acceder a elas.
As máquinas virtuais funcionan normalmente.
O interruptor SAN falla nun dos sitios. Os hosts ESXi perden algunhas das rutas ao sistema de almacenamento. Neste caso, os hosts do sitio onde fallou o cambio só funcionarán a través dun dos seus HBA.
As máquinas virtuais seguen funcionando normalmente.
Todos os interruptores SAN nun dos sitios fallan. Digamos que tal desastre ocorreu no sitio OST. Neste caso, os hosts ESXi deste sitio perderán todas as rutas aos seus dispositivos de disco. Entra en xogo o mecanismo estándar de VMware vSphere HA: reiniciará todas as máquinas virtuais do sitio OST en NORD nun máximo de 140 segundos.
As máquinas virtuais que se executan en hosts do sitio NORD funcionan normalmente.
O servidor ESXi falla nun sitio. Aquí o mecanismo de vSphere HA funciona de novo: as máquinas virtuais do host fallido reinician noutros hosts, no mesmo sitio ou no sitio remoto. O tempo de reinicio da máquina virtual é de ata 1 minuto.
Se todos os hosts ESXi do sitio OST fallan, non hai opcións: as máquinas virtuales reinician noutra. O tempo de reinicio é o mesmo.
O sistema de almacenamento falla nun sitio. Digamos que o sistema de almacenamento falla no sitio OST. A continuación, os servidores ESXi do sitio OST cambian a traballar con réplicas de almacenamento en NORD. Despois de que o sistema de almacenamento fallou volva ao servizo, producirase a replicación forzada e os hosts ESXi OST comezarán de novo a acceder ao sistema de almacenamento local.
As máquinas virtuais estiveron funcionando normalmente durante todo este tempo.
Un dos sitios falla. Neste caso, todas as máquinas virtuais reiniciaranse no sitio de copia de seguridade a través do mecanismo vSphere HA. O tempo de reinicio da máquina virtual é de 140 segundos. Neste caso, gardaranse todas as configuracións de rede da máquina virtual e permanecerán accesibles para o cliente a través da rede.
Para garantir que o reinicio das máquinas no sitio de copia de seguranza vaia sen problemas, cada sitio só está a metade. A segunda metade é unha reserva no caso de que todas as máquinas virtuais se movan do segundo sitio danado.
Unha nube resistente a desastres baseada en dous centros de datos protexe contra estes fallos.
Este pracer non é barato, xa que, ademais dos principais recursos, é necesaria unha reserva no segundo sitio. Polo tanto, os servizos críticos para a empresa colócanse nunha nube deste tipo, cuxo tempo de inactividade a longo prazo provoca grandes perdas financeiras e de reputación, ou se o sistema de información está suxeito aos requisitos de resistencia ante desastres dos reguladores ou das normativas internas da empresa.
Fontes:
Fonte: www.habr.com