Solução ERP interno da Microsoft é o SAP Suite de produtos, incluindo SAP ECC 6.0, SAP BW e SAP SCM. Microsoft testa novo SQL Server versões e Service Packs no teste os sistemas SAP, mas também o sistema de produção de ECC de núcleo que executa o Microsoft em todo o mundo. A instância única ECC 6.0, cliente único sistema é acessado por 95.000 usuários em todo o mundo e transaccione a maioria da $65B USD em receitas a cada ano. SQL Server 7, SQL 2000, 2005, 2008 R2 todos foram testados no núcleo do sistema de produção de ECC antes destes produtos foram lançados.
Microsoft seguirá o mesmo processo com SQL 2012 para que os clientes possam ter a confiança de que nenhuma versão do SQL Server nunca é liberada sem execução da produção da Microsoft sistema SAP durante vários meses. Queremos alcançar com este artigo e dar uma atualização de status sobre nossas implementações internas.
Desde Janeiro de 2011 testamos compilações de 2012 do SQL Server em um modo seguro que representam cerca de metade da capacidade de nossos sistemas SAP ERP produtivos. Além de testar a funcionalidade usada pela SAP, uma das áreas principais testes foram em torno de nossa nova HA/DR funcionalidade oferecida no SQL Server. Estamos combinados este conjunto de funcionalidade sob o nome de Always on em SQL Server 2012 (http://msdn.microsoft.com/en-us/sqlserver/gg490638 ). Todos os métodos antigos como o Windows Clustering, espelhamento de banco de dados e envio de logs ainda são enviados em 2012 do SQL Server.
A nova funcionalidade de Always on que permite maior flexibilidade e funcionalidade como vários secundárias ou on-line de leitura de secundárias, são oferecidos em paralelo com a funcionalidade 'antigo'. No início dos testes em sandbox começamos com espelhamento de banco de dados como método de alta disponibilidade. Uma vez que nós à prova que o espelhamento de banco de dados estava funcionando perfeitamente nos mudamos a configuração de alta disponibilidade para AlwaysOn com 2 réplicas (um principal e outro secundário) basicamente substituindo o espelhamento de banco de dados. Desde de julho que tivemos um 3rd réplica (outro secundário adicional) adicionado à configuração de HA/DR para testar a substituição de envio de logs para nosso Datacenter de recuperação de desastres. Em frente à combinação de espelhamento de banco de dados e envio de logs como usamos até hoje, agora tivemos três servidores usando a mesma funcionalidade de Always on replique as alterações.
Tivemos um lugar para definir a configuração de HA/DR e um lugar para verificar se tudo iria correr bem. Todos os testes em torno de nossa nova tecnologia HA/DR correram bastante bem. Comentários desses testes para desenvolvimento do SQL Server foi usado para melhorar e afinar a tecnologia AlwaysOn. Deste ponto de vista, os testes iniciais que fizemos juntamente com nossa equipe SAP Basis podem considerar como muito bem sucedida por TI da Microsoft, bem como desenvolvimento do SQL Server. Além de Always on também testamos um novo sinalizador de rastreamento já documentado anteriormente. Essa nova funcionalidade também provou para ser um sucesso completo, eliminando alguns problemas conhecidos que às vezes encontramos com consulta plano geração.
Mudamos nosso sistema seguro para uma compilação final CTP3 atualizar em Julho e continuou a executar testes nele verificar funcionalidade e características diferentes.
Em meados de agosto concentramos nossa atenção nossa instância de teste oficial do SAP ERP que situa-se no nosso site de DR e é usada para negócios regressão, carga de trabalho e testes de escalabilidade. Como tal, este sistema é uma cópia exata do nosso sistema produtivo de SAP ERP. Mudamos essa instância do SQL Server 2008 R2 em SQL Server 2012 CTP3 Refresh com e in-loco. Substituímos o espelhamento de banco de dados neste sistema de teste também com Always on em uma configuração de 2-réplica. Testes de escalabilidade com Always on usando nossa Suite de testes de regressão de negócios mais índice recria executada em paralelo revelou que a replicação de dados de log de transação entre primária e secundária é dimensionamento de maneira melhor do que já fiz DBM.
Cenários de carga de trabalho de alto volume poderiam causar efeitos descritos. Considerando que a transferência de log de transação de dados projetado novo não apresentaram qualquer problema. Experiência feita em nosso sistema de teste do SAP foram extremamente positiva e pavimentou o caminho para mover SQL Server 2012 em nosso sistema produtivo como aplainadas meados de novembro.
Como uma última instância nos mudamos nossa instância de SAP ERP produtiva para compilação atualizada SQL Server 2012 CTP3 Refresh em 11/11/2011. Foi durante a nossa manutenção trimestral habitual que normalmente usamos para obter novos kernels SAP e pacotes de suporte SAP aplicados ao nosso sistema de ERP SAP quando realizamos upgrades no local de nossas instâncias do SQL Server 2008 R2 para SQL Server 2012. A seqüência dos passos parecia:
- Atualizado o envio de logs destino no local para o SQL Server 2012 dois dias antes do tempo de inatividade
- Atualizado o espelhamento de banco de dados anterior para o SQL Server 2012 um dia antes do tempo de inatividade
- Desligar o sistema de ERP SAP no início do tempo de inatividade.
- Interromper o espelhamento de banco de dados
- Abrir banco de dados espelho anterior e deixar que ele adaptou para as etapas de atualização do esquema SQL Server 2012.
- Depois criamos um nó Always on (nossa nova funcionalidade HA/DR – haverá uma série de Blogs sobre este seguinte) com uma réplica e um ouvinte nome (virtual).
- Em paralelo a SNAC (SQL Native Client Access) tem implantado para todos os servidores de aplicativos.
- Após estas etapas foram concluídas que precisávamos substituir o nome do servidor e o nome do parceiro de failover em vários locais da configuração do SAP com o novo nome virtual/ouvinte da configuração Always on.
- Depois que isso foi feito, temos o sistema e executar novamente para realizar a manutenção trimestral normal, que geralmente se encarrega sobre como atualizar vários pacotes de suporte SAP, SAP kernel exchange e muitos transportes que normalmente implementam novas funções em nosso sistema de ERP SAP.
Após o SAP ser instalado e ser colocado em produção:
- Nós atualizado o antigo servidor principal para o SQL Server 2012.
- Nós deliberadamente não sincronizar o principal antigo e agora secundário não para a configuração de HA enquanto o pacote de suporte as importações e transporta porque nós normalmente sempre manter o servidor espelho sobre o estado do início do tempo de inatividade para ser capaz de recuperar de uma forma rápida se intransponíveis problemas durante o suporte pacote aplicativo ocorreria
Depois que todos os pacotes de suporte e transportes foram aplicadas ao sistema de ERP SAP, realizamos as seguintes etapas
- Nós então sincronizado esta instância de SQL Server 2012 com os backups de log de transação do objeto atual e adicionado-lo como uma réplica ao grupo de disponibilidade de Always on.
- Realizamos diversos testes de failover com o sistema de ERP SAP ainda em execução. Nós quisemos marcar com esses testes se a configuração de Always on foi boa e correta.
Até agora o sistema comporta-se perfeitamente e mostra o grande desempenho.
Fonte site msdn.com
