SAN Replicação Síncrona e SQL Server - O RPO de 0 é possível?

Question

Estou trabalhando em uma solução que está usando o SQL Server 2012 SP2, mas sem o uso de grupos de disponibilidade AlwaysOn. Isso ocorre devido a transações entre bancos de dados, que não funcionam para esse cenário.

Note: This is being addressed as we speak, but added as background information to my problem.

Estamos usando uma solução HP 3PAR StoreServ para obter replicação síncrona de site para site por meio de uma SAN. Isso permite que os cenários de DR funcionem em vários sites, para que possamos fazer failover em nosso secundário.

Minha preocupação é com o RPO de 0 porque existem cenários nos quais os dados podem ser perdidos e a corrupção ocorrerá. Por exemplo, o link é separado entre sites e, em seguida, o principal fica inativo.

Minhas perguntas são as seguintes:

1. A SAN nega dados gravados na E / S até que a sincronização seja concluída?

OR

1. Se um link for separado, o buffer da SAN muda até que a conexão seja restaurada?

2. Se um link for interrompido durante uma gravação de log TL e ocorrer um DR, isso não significa que teremos um TL potencialmente corrompido gravado no site secundário e, portanto, incorrer em perda de dados? A perda de dados é apenas porque o primário foi capaz de confirmar, mas o secundário não conseguiu sincronizar.

3. O RPO de zero é sempre uma garantia em toda a pilha (SQL Server / Memória / Rede / SAN / IO)?

No white paper HP 3PAR StorageServ: Soluções de replicação para ambientes exigentes em tolerância a desastres , página 6:

For synchronous replication solutions the RPO of the solution is always zero. For asynchronous replication solutions however the RPO will always be something greater than zero. Asynchronous Periodic mode is asynchronous replication. As a result, when designing a solution that uses Asynchronous Periodic replication, RPO becomes a concern.

A SAN garante um RPO de tolerância de 0, então é o caso de quando a rede morre, a SAN não permite que a alteração permeie a E / S?

Atualização:

Encontrei esta informação na página 12 da referência acima:

Synchronous Long Distance topology

The Remote Copy Synchronous Long Distance (SLD) topology is the only topology supported today that allows volumes in a Remote Copy Volume Group to be replicated from one source StoreServ array to two different target StoreServ arrays. It does this by replicating data synchronously between two StoreServ arrays (the “Source” and “Sync Target” arrays) while simultaneously replicating the same data via Periodic Asynchronous mode to a third StoreServ array, the disaster recovery or “Async Target” array. The user has the option of treating the two sync arrays in an active-active manner, failing over between them if/when a failure in a data center dictates a failover is necessary and resuming operations on the “Sync Target” array. This provides a failover solution that delivers an RPO equal to zero due to the synchronous nature of the replication that occurs between the sync arrays.

On failover to a Sync Target array, the passive Asynchronous Periodic link between that array and the Async Target array becomes active and any data that was replicated to the Sync Target but that had not yet made it to the Async Target array is sent from the Sync Target array to the Async Target bringing the Async Target array up to date with the last write that occurred to the Sync Target. Operations then continue in the Sync Target data center and it continues to replicate data to the Async Target array.

A partir dessas informações, você precisa de um terceiro endpoint para participar da replicação assíncrona, para que o site secundário possa ser informado sobre alterações quando o link de rede for interrompido.

    

Answer 1

Não posso comentar especificamente sobre a 3PAR, mas tenho muita experiência com os arrays EMC Symmetrix.

Meu conselho seria: encontrar outro caminho. A replicação síncrona é uma dessas tecnologias que parecem ótimas no papel e, em circunstâncias ideais, mas no mundo real causam grandes quantidades de dor.

A maneira como funciona é:

• gravação recebida insere o cache na matriz.
• gravação é copiada em um link síncrono para um site remoto.
• a gravação está comprometida com o cache no array remoto.
• o reconhecimento é enviado de volta ao primário.
• o sucesso do IO de gravação é reconhecido como host.

É 'RPO 0' no sentido de que, SE FOR EM DISCO, está no site remoto. A maioria dos aplicativos usa cache de memória, que será perdido em um DR. No entanto, isso tem um preço significativo:

• Você precisa de largura de banda total suficiente para o seu site remoto e sempre terá o suficiente para atender aos requisitos de replicação - se não o fizer, seus sistemas primários sofrerão muito, porque a latência do disco aumentará drasticamente. Se você alguma vez saturar este link, você sofrerá e seu serviço principal poderá falhar.

• Você sempre terá uma carga de latência e seu desempenho sofrerá como resultado.

Agora, pode ser que ambas as coisas estejam "bem". Na minha experiência, porém, o RPO0 e a 'replicação de sincronização' são geralmente discutidos apenas quando você tem coisas realmente importantes.

Para responder às suas perguntas diretamente:

Does the SAN deny data writes to the I/O until synchronisation has completed?

Não - ele vai "pegar" em assíncrono, antes de entrar no modo de sincronização. Isso pode demorar um pouco dependendo do bandwdith, e até que ele seja sincronizado, você não tem o seu '0 RPO'.

If a link is severed, does the SAN buffer the block changes until the connection is restored?

Depende um pouco da sua configuração. Geralmente, ele tratará o link suspenso / retomado como um evento que precisa ser sincronizado novamente. Embora o link esteja "fora", seu RPO não é mais zero. Você pode "bloquear" o IO em uma falha de link, mas isso provavelmente causará falha no seu aplicativo.

If a link is severed during a TL log write, and a DR occurs, doesn't this mean that we will have a potentially corrupt TL written to the secondary site, and therefore incur data loss? The data loss is only because the primary was able to commit, but the secondary was not able to synchronise.

Não - sincronia significa sincronização. Se você estiver em sincronia, o IO no disco também estará no controle remoto. Qualquer IO não no disco é perdido, assim você pode perder seus últimos translogs.

Is RPO of zero ever a guarantee across the stack (SQL Server / Memory / Network / SAN / IO)?

O RPO é o objetivo do ponto de recuperação. Se o seu objetivo é (verdadeiramente) zero, então ... você precisa pensar muito sobre sua arquitetura. É alcançável, mas é incrivelmente caro.

Pessoalmente, sugiro que, em vez de sincronizar:

Execute seus datastores primários como assíncronos e confie em seus registros para fornecer o bit "sync". Seu 'RPO0' - praticamente falando - será apenas 'seu commitog' de qualquer maneira. Portanto, o NFS (CIFS?) Monta uma unidade remota e grava você na rede, bem como no armazenamento 'local', e os reproduz no seu banco de dados - alguns minutos fora de sincronia.

Você obterá praticamente o mesmo ponto de recuperação - porque duvido muito que queira usar dados que não estejam registrados no diário - e fará isso sem precisar de operações de sincronização caras.