Fui designado para um projeto em que temos um ambiente secundário ativo que tenho certeza de que os Grupos de Disponibilidade abordariam, mas tenho algumas perguntas que espero que alguém possa responder para mim.
A situação :
O que estou tentando resolver não é a continuidade de negócios padrão ou a recuperação de desastres, mas para acelerar o lançamento de um ambiente atualizado (esquema alterado).
Atualmente, os bancos de dados/UI/cubos que suportam nossos sistemas voltados para o cliente obtêm uma nova versão a cada 8 semanas e, nesse fim de semana de lançamento, levará 24 horas para aplicar o novo esquema, aplicar preenchimentos de dados e fazer a manutenção do sistema, como reconstruir o índice e reiniciar os servidores .
A esperança é ter um ambiente duplicado que possamos atualizar antes da data de lançamento e 'trocar' minimizando o tempo de inatividade para nossos clientes. Estou principalmente preocupado em ter uma forma de bancos de dados replicados que permaneçam atualizados em relação aos dados, mas que o secundário possa ter modificações de esquema feitas nele e não tenho certeza se os Grupos de Disponibilidade são a melhor resposta para isso.
Além de reprojetar o ambiente, há outra tecnologia que devo considerar para atender à minha necessidade de ter um ambiente secundário 'hot swap' que possa ser atualizado?
Como você mencionou os Grupos de Disponibilidade, isso significa que você está usando o SQL Server Enterprise Edition (e possivelmente o SQL Server 2012 ou 2014).
Você pode usar instantâneos de banco de dados , mas, em nosso caso, havia muitas dependências de diferentes componentes e, portanto, o uso de instantâneos de banco de dados foi descartado.
Abaixo exigirá um pouco mais de planejamento e teste.
Conceito Azul-Verde:
A essência do Blue-Green Concept é dividir sua produção em 2 ambientes e eles são sempre idênticos (sincronização de dados) em que
O Azul (Atual) terá a versão atual do esquema/build ou produto e será seu ambiente "LIVE".
Ao mesmo tempo, o Green será seu ambiente de preparação/teste no qual você atualizará seu esquema/construção ou produto para a PRÓXIMA versão, fará um teste de regressão completo e será aprovado por seus usuários de negócios. Uma vez feliz, durante um período de corte, você promoverá o Green para ser seu ambiente "LIVE" e rebaixará o Blue para ser um pré-prod/encenação ou teste para o próximo lançamento.
Dessa forma, você terá muito menos tempo de inatividade e o risco de falha na implantação em um sistema ativo (que está em janela de manutenção, já que você está fazendo upgrade) será altamente minimizado. Além disso, seguindo a abordagem Azul-Verde, você estará oscilando entre a versão AO VIVO e ANTERIOR, que será preparada para a próxima versão.
Novamente, isso exigirá mais hardware/licenciamento, bem como planejamento e teste.
A maioria das etapas pode ser automatizada usando DACPACs e PowerShell. Além disso, se você estiver instalando várias instâncias em um servidor, certifique-se de reequilibrar as configurações de memória ao alternar entre azul e verde. O ambiente LIVE obtém mais memória do que o ambiente Passivo.
Em meu ambiente atual, implementamos o modelo azul/verde para implantação de código ágil que nos permite promover o código a cada 2 semanas com bastante tempo para testes e aprovação de negócios. Além disso, é muito fácil reverter, caso algo dê terrivelmente errado. Automatizamos a maioria do material de implantação usando Dacpacs e PowerShell.
Consulte também o artigo de Grant Fritchey sobre solução de problemas de reversão e recuperação; Desafios e Estratégias