Implantação de DBMS de máquinas virtuais do SQL Server Azure para SAP NetWeaver

Esse documento abrange diversas áreas diferentes a serem consideradas ao implantar o SQL Server para carga de trabalho SAP no Azure IaaS. Como pré-condição para esse documento, leia o documento Considerações para implantação de DBMS de máquinas virtuais do Azure para carga de trabalho SAP e outros guias na documentação de carga de trabalho SAP no Azure.

Em geral, você deve considerar usar as versões mais recentes do SQL Server para executar a carga de trabalho do SAP no Azure IaaS. As versões mais recentes do SQL Server oferecem melhor integração com alguns serviços e funcionalidades do Azure. Ou tenha alterações que otimizem as operações em uma infraestrutura IaaS do Azure.

A documentação geral sobre o SQL Server em execução em Máquinas Virtuais (VMs) do Azure pode ser encontrada nesses artigos:

• SQL Server em Máquinas Virtuais do Azure (Windows)
• Automatize o gerenciamento com a extensão do agente IaaS do Windows SQL Server
• Configurar a integração do Azure Key Vault para SQL Server em VMs do Azure (Resource Manager)
• Lista de verificação: práticas recomendadas para SQL Server em VMs do Azure
• Armazenamento: práticas recomendadas de desempenho para SQL Server em VMs do Azure
• Práticas recomendadas de configuração de HADR (SQL Server em VMs do Azure)

Nem todo o conteúdo e as declarações feitas na documentação geral do SQL Server na VM do Azure se aplicam à carga de trabalho do SAP. Mas a documentação dá uma boa impressão sobre os princípios. Um exemplo de funcionalidade não suportada pela carga de trabalho SAP é o uso do clustering FCI.

Há algumas informações específicas do SQL Server em IaaS que você deve saber antes de continuar:

• Suporte à versão SQL: mesmo com a Nota SAP #1928533 afirmando que a versão mínima suportada do SQL Server é o SQL Server 2008 R2, a janela de versões suportadas do SQL Server no Azure também é determinada pelo ciclo de vida do SQL Server. A manutenção estendida do SQL Server 2012 terminou em meados de 2022. Como resultado, a versão mínima atual para sistemas recém-implantados deve ser o SQL Server 2014. Quanto mais recente, melhor. As versões mais recentes do SQL Server oferecem melhor integração com alguns serviços e funcionalidades do Azure. Ou tenha alterações que otimizem as operações em uma infraestrutura IaaS do Azure.
• Usando imagens do Azure Marketplace: a maneira mais rápida de implantar uma nova VM do Microsoft Azure é usar uma imagem do Azure Marketplace. Há imagens no Azure Marketplace que contêm as versões mais recentes do SQL Server. As imagens onde o SQL Server já está instalado não podem ser usadas imediatamente para aplicativos SAP NetWeaver. O motivo é que a ordenação padrão do SQL Server é instalada nessas imagens e não a ordenação necessária para sistemas SAP NetWeaver. Para utilizar essas imagens, consulte os passos documentados no capítulo Usando uma imagem do SQL Server do Microsoft Azure Marketplace.
• Suporte a várias instâncias do SQL Server em uma única VM do Azure: esse método de implantação é suportado. No entanto, esteja ciente das limitações de recursos, especialmente em relação à largura de banda de rede e armazenamento do tipo de VM que você está usando. Informações detalhadas estão disponíveis no artigo Tamanhos para máquinas virtuais no Azure. Essas limitações de cota podem impedir que você implemente a mesma arquitetura de várias instâncias que você pode implementar no local. Quanto à configuração e interferência do compartilhamento dos recursos disponíveis em uma única VM, as mesmas considerações do ambiente local precisam ser levadas em conta.
• Vários bancos de dados SAP em uma única instância do SQL Server em uma única VM: configurações como essas são suportadas. As considerações sobre vários bancos de dados SAP compartilhando os recursos de uma única instância do SQL Server são as mesmas das implantações locais. Tenha em mente outros limites, como o número de discos que podem ser anexados a um tipo específico de VM. Ou limites de cota de rede e armazenamento de tipos específicos de VM, como tamanhos detalhados para máquinas virtuais no Azure.

Novas VMs da série M e SQL Server

O Azure lançou algumas novas famílias de SKUs da série M na família Mv3. Alguns dos tipos de VM nessa família não devem ser usados para o SQL Server, incluindo o SQL Server 2022 sem desabilitar o SMT (Hyperthreading) no sistema operacional convidado do Windows Server. O motivo é o número de nós NUMA presentes no sistema operacional convidado do Windows Server, que, com mais de 64 vCPUs, é grande demais para o SQL Server acomodar. Ao desabilitar o SMT no sistema operacional convidado do Windows Server, o número de vCPUs é reduzido. Assim, o número de vCPUs é inferior a 64 em cada nó NUMA. A forma de desabilitar o SMT é descrita aqui. Os tipos de VM específicos são:

• M176(d)s_3_v3 – desabilite o SMT ou use M176bds_4_v3 ou M176bds_4_v3 como alternativa
• M176(d)s_4_v3 – desabilite o SMT ou use M176bds_4_v3 como alternativa
• M624(d)s_12_v3 – desabilite o SMT ou use M416ms_v2 como alternativa
• M832(d)s_12_v3 – desabilite o SMT ou use M416ms_v2 como alternativa
• M832i(d)s_16_v3 - desabilitar SMT ou usar M416ms_v2 como alternativa

Recomendações sobre estrutura de VM/VHD para implantações do SQL Server relacionadas ao SAP

De acordo com a descrição geral, Sistema operacional, executáveis ​​do SQL Server, os executáveis ​​do SAP devem estar localizados ou instalados em discos separados do Azure. Normalmente, a maioria dos bancos de dados do sistema SQL Server não são utilizados em alto nível com a carga de trabalho do SAP NetWeaver. No entanto, os bancos de dados do sistema do SQL Server devem estar, juntamente com os outros diretórios do SQL Server, em um disco separado do Azure. O tempdb do SQL Server deve estar localizado na unidade D:\ não persistida ou em um disco separado.

• Com todos os tipos de VM certificados pela SAP (consulte a Nota SAP nº 1928533), os dados tempdb e os arquivos de log podem ser colocados na unidade D:\ não persistente.
• Com versões do SQL Server, em que o SQL Server instala o tempdb com apenas um arquivo de dados, é recomendável usar vários arquivos de dados tempdb. Esteja ciente de que os volumes da unidade D:\ são diferentes em tamanho e capacidades com base no tipo de VM. Para tamanhos exatos da unidade D:\ das diferentes VMs, consulte o artigo Tamanhos para máquinas virtuais Windows no Azure.

Essas configurações permitem que o tempdb consuma mais espaço e, mais importante, mais operações de E/S por segundo (IOPS) e largura de banda de armazenamento do que a unidade do sistema é capaz de fornecer. A unidade D:\ não persistente também oferece melhor latência de E/S e taxa de transferência. Para determinar o tamanho adequado do tempdb, você pode verificar os tamanhos dos tempdb nos sistemas existentes.

Uma configuração de VM, que executa o SQL Server com um banco de dados SAP e onde os dados tempdb e o arquivo de log tempdb são colocados na unidade D:\ e no armazenamento premium do Azure v1 ou v2, ficaria assim:

O diagrama mostra um caso simples. Conforme mencionado no artigo Considerações sobre a implantação de DBMS de máquinas virtuais do Azure para carga de trabalho SAP, o tipo de armazenamento do Azure, o número e o tamanho dos discos dependem de diferentes fatores. Mas, em geral, recomendamos:

• Para implantações menores e de médio porte, use um volume grande, que contém os arquivos de dados do SQL Server. O motivo por trás dessa configuração é que é mais fácil lidar com diferentes cargas de trabalho de E/S caso os arquivos de dados do SQL Server não tenham o mesmo espaço livre. Enquanto em implantações grandes, especialmente em implantações em que o cliente se moveu com uma migração heterogênea de banco de dados para o SQL Server no Azure, usamos discos separados e distribuímos os arquivos de dados por esses discos. Essa arquitetura só é bem-sucedida quando cada disco tem o mesmo número de arquivos de dados, todos os arquivos de dados têm o mesmo tamanho e aproximadamente o mesmo espaço livre.
• Use a unidade D: para tempdb, desde que o desempenho seja bom o suficiente. Se a carga de trabalho geral for limitada no desempenho do tempdb localizado na unidade D:\, você precisará mover o tempdb para o armazenamento premium do Azure v1 ou v2, ou para o disco Ultra, conforme recomendado nesse artigo..

O mecanismo de preenchimento proporcional do SQL Server distribui leituras e gravações para todos os arquivos de dados uniformemente, desde que todos os arquivos de dados do SQL Server tenham o mesmo tamanho e o mesmo ritmo de gravação. O SAP no SQL Server oferece o melhor desempenho quando as leituras e gravações são distribuídas uniformemente entre todos os arquivos de dados disponíveis. Se um banco de dados tiver poucos arquivos de dados ou se os arquivos de dados existentes estiverem muito desbalanceados, o melhor método para corrigir é uma exportação e importação do R3load. Uma exportação e importação do R3load envolve tempo de inatividade e só deve ser feita se houver um problema de desempenho óbvio que precise ser resolvido. Se os arquivos de dados tiverem tamanhos apenas moderadamente diferentes, aumente todos os arquivos de dados para o mesmo tamanho, e o SQL Server irá rebalancear os dados ao longo do tempo. O SQL Server aumenta automaticamente os arquivos de dados uniformemente se o sinalizador de rastreamento 1117 estiver definido ou se o SQL Server 2016 ou superior for usado sem sinalizador de rastreamento.

Especial para VMs da série M

Para VMs da Série M do Azure, a latência de gravação no log de transações pode ser reduzida, em comparação ao desempenho de armazenamento premium do Azure v1, ao usar o Azure Acelerador de Gravação. Se a latência fornecida pelo armazenamento premium v1 estiver limitando a escalabilidade da carga de trabalho do SAP, o disco que armazena o arquivo de log de transações do SQL Server poderá ser habilitado para o Acelerador de Gravação. Detalhes podem ser lidos no documento Acelerador de Gravação. O Azure Acelerador de Gravação não funciona com o armazenamento premium v2 do Azure e o disco Ultra. Em ambos os casos, a latência é melhor do que a oferecida pelo armazenamento premium do Azure v1. O Acelerador de Gravação não oferece suporte ao SSD Premium v2.

Formatação dos discos

Para o SQL Server, o tamanho do bloco NTFS para discos contendo dados e arquivos de log do SQL Server deve ser 64 KB. Não é necessário formatar a unidade D:\. Essa unidade vem pré-formatada.

Para evitar que a restauração ou criação de bancos de dados inicialize os arquivos de dados zerando o conteúdo dos arquivos, certifique-se de que o contexto do usuário no qual o serviço do SQL Server está sendo executado tenha o direito de usuário Executar tarefas de manutenção de volume. Para obter mais informações, veja Inicialização instantânea de arquivo de banco de dados.

SQL Server 2014 e versões mais recentes do SQL Server - Armazenando arquivos de banco de dados diretamente no Armazenamento de Blobs do Azure

O SQL Server 2014 e versões posteriores oferecem a possibilidade de armazenar arquivos de banco de dados diretamente no Azure Blob Store sem o "wrapper" de um VHD ao redor deles. Essa funcionalidade foi criada para resolver deficiências do armazenamento em bloco do Azure anos atrás. No momento, não é recomendável usar esse método de implantação. Escolha o armazenamento Premium do Azure v1, o armazenamento Premium v2 ou o Disco Ultra. Dependendo dos requisitos.

Considerações sobre backup/recuperação para SQL Server

Ao implantar o SQL Server no Azure, você precisa revisar sua arquitetura de backup. Mesmo que o sistema não seja de produção, o banco de dados SAP do SQL Server deve ter backup feito periodicamente. Como o Armazenamento do Azure mantém três imagens, um backup agora é menos importante para compensar uma falha de armazenamento. O motivo prioritário para manter um plano adequado de backup e recuperação é importante para a funcionalidade de recuperação pontual para compensar erros lógicos/manuais. O objetivo é usar backups para restaurar o banco de dados até um determinado momento. Ou usar os backups no Azure para iniciar outro sistema com a cópia do backup do banco de dados existente.

Há várias maneiras de fazer backup e restaurar bancos de dados do SQL Server no Azure. Para obter a melhor visão geral e detalhes, leia o documento Backup e restauração para SQL Server em VMs do Azure. O artigo aborda várias possibilidades diferentes.

Usando uma imagem do SQL Server do Microsoft Azure Marketplace

A Microsoft oferece VMs no Azure Marketplace, que já contém versões do SQL Server. Para clientes SAP que precisam de licenças para SQL Server e Windows, usar essas imagens pode ser uma oportunidade de cobrir a necessidade de licenças ao criar VMs com o SQL Server já instalado. Para usar essas imagens para SAP, as seguintes considerações precisam ser feitas:

• As versões do SQL Server que não são de avaliação acarretam em custos mais elevados do que uma VM ‘Somente Windows’ implantada do Azure Marketplace. Para comparar preços, veja Preços de Máquinas Virtuais do Windows e Preços de máquinas virtuais do SQL Server Enterprise.
• Você só pode usar versões do SQL Server que são suportadas pela SAP para seu software.
• A ordenação da instância do SQL Server, que é instalada nas VMs oferecidas no Azure Marketplace, não é a ordenação que o SAP NetWeaver exige que a instância do SQL Server seja executada. Você pode alterar a ordenação seguindo as instruções na seção a seguir.

Alterando a ordenação do SQL Server de uma VM Microsoft Windows/SQL Server

Como as imagens do SQL Server no Azure Marketplace não estão configuradas para usar a ordenação, que é necessária para aplicativos SAP NetWeaver, ela precisa ser alterada imediatamente após a implantação. Para o SQL Server, essa alteração de ordenação pode ser feita com as seguintes etapas assim que a VM for implantada e um administrador puder efetuar logon na VM implantada:

• Abra uma janela de comando do Windows como administrador.
• Altere o diretório para C:\Arquivos de Programas\Microsoft SQL Server\110\Setup Bootstrap\SQLServer2012.
• Execute o comando: Setup.exe /QUIET /ACTION=REBUILDDATABASE /INSTANCENAME=MSSQLSERVER /SQLSYSADMINACCOUNTS=<local_admin_account_name> /SQLCOLLATION=SQL_Latin1_General_Cp850_BIN2
  • <local_admin_account_name> é a conta, definida como a conta de administrador ao implantar a VM pela primeira vez por meio da galeria.

O processo deve levar apenas alguns minutos. Para ter certeza de que a etapa terminou com o resultado correto, execute os seguintes passos:

• Abra o SQL Server Management Studio.
• Abra uma janela de consulta.
• Execute o comando sp_helpsort no banco de dados mestre do SQL Server.

O resultado desejado deve ser algo como:

Latin1-General, binary code point comparison sort for Unicode Data, SQL Server Sort Order 40 on Code Page 850 for non-Unicode Data

Se o resultado for diferente, STOP qualquer implantação e investigue por que o comando de configuração não funcionou como esperado. A implantação de aplicativos SAP NetWeaver em uma instância do SQL Server com páginas de código do SQL Server diferentes daquela mencionada NOT é suportada para implantações do NetWeaver.

Alta disponibilidade do SQL Server para SAP no Azure

Usando o SQL Server em implantações do Azure IaaS para SAP, você tem diversas possibilidades diferentes para adicionar para implantar a camada de banco de dados altamente disponível. O Azure fornece diferentes SLAs de tempo de atividade para uma única VM usando diferentes armazenamentos em bloco do Azure, um par de VMs implantadas em um conjunto de disponibilidade do Azure ou um par de VMs implantadas em Zonas de Disponibilidade do Azure. Para sistemas de produção, esperamos que você implante um par de VMs em um conjunto de escala de máquina virtual com orquestração flexível em duas zonas de disponibilidade. Veja a comparação de diferentes tipos de implantação para carga de trabalho SAP para obter mais informações. Uma VM executa a instância ativa do SQL Server. A outra VM executa a instância passiva

Clusterização do SQL Server usando o Windows Scale-out File Server ou o disco compartilhado do Azure

Com o Windows Server 2016, a Microsoft introduziu o Espaços de Armazenamento Diretos. Com base na implantação dos Espaços de Armazenamento Diretos, de maneira geral, há suporte para o clustering de FCI do SQL Server. O Azure também oferece discos compartilhados do Azure que podem ser usados ​​para clustering do Windows. Para carga de trabalho SAP, não oferecemos suporte a essas opções de HA.

Envio de logs do SQL Server

Uma funcionalidade de alta disponibilidade é o envio de logs do SQL Server. Se as VMs que participam da configuração de HA tiverem resolução de nomes funcional, não há problema. A configuração no Azure não difere de nenhuma configuração feita no local relacionada à configuração do envio de logs e aos princípios em torno do envio de logs. Detalhes sobre o envio de logs do SQL Server podem ser encontrados no artigo Sobre o envio de logs (SQL Server).

A funcionalidade de envio de log do SQL Server dificilmente era usada no Azure para atingir alta disponibilidade em uma região do Azure. No entanto nos seguintes cenários clientes SAP estavam usando o envio de logs com êxito com o Azure:

• Cenários de recuperação de desastres de uma região do Azure para outra região do Azure
• Configuração de uma Recuperação de Desastre local para uma região do Azure
• Cenários de transição do local para o Azure. Nesses casos, o envio de logs é usado para sincronizar a implantação do novo banco de dados no Azure com o sistema de produção local em andamento. No momento do corte, a produção é desligada e garante que os últimos backups de log de transações sejam transferidos para a implantação do banco de dados do Azure. Em seguida, a implantação do banco de dados do Azure é aberta para produção.

SQL Server sempre ativo

Como o Always On é compatível com o SAP local (consulte a Nota SAP nº 1772688), ele é compatível em combinação com o SAP no Azure. Há algumas considerações especiais sobre a implementação do ouvinte do grupo de disponibilidade do SQL Server (não confundir com o conjunto de disponibilidade do Azure). Portanto, algumas etapas diferentes de instalação são necessárias.

Algumas considerações sobre o uso de um Listener de Grupo de Disponibilidade são:

• Usar um Listener de Grupo de Disponibilidade só é possível com o Windows Server 2012 ou superior como sistema operacional convidado da VM. Para o Windows Server 2012, certifique-se de que a atualização para habilitar os ouvintes do grupo de disponibilidade do SQL Server em máquinas virtuais do Microsoft Azure baseadas no Windows Server 2008 R2 e no Windows Server 2012 tenha sido aplicada.
• Para o Windows Server 2008 R2, esse patch não existe. Nesse caso, o Always On precisaria ser usado da mesma forma que o espelhamento de banco de dados. Ao especificar um parceiro de failover na cadeia de conexões (feito por meio do parâmetro default.pfl do SAP dbs/mss/server – Confira a Nota da SAP nº 965908).
• Ao usar um ouvinte do grupo de disponibilidade, as VMs de banco de dados precisam ser conectadas a um balanceador de carga dedicado. Você precisa atribuir endereços IP estáticos aos adaptadores de rede dessas VMs na configuração do Always On (a definição de um endereço IP estático está descrita neste artigo). Endereço IP estático comparados ao DHCP estão impedindo a atribuição de novos endereços IP em casos em que ambas as VMs podem ser paradas.
• Há etapas especiais necessárias ao criar a configuração do cluster WSFC, em que o cluster precisa de um endereço IP especial atribuído, porque o Azure, com sua funcionalidade atual, atribuiria ao nome do cluster o mesmo endereço IP do nó no qual o cluster foi criado. Esse comportamento indica que uma etapa manual deve ser executada para atribuir um endereço IP diferente ao cluster.
• O Listener do Grupo de Disponibilidade será criado no Azure com pontos de extremidade TCP/IP, que são atribuídos às VMs que executam as réplicas primárias e secundárias do grupo de Disponibilidade.
• Pode ser necessário proteger esses pontos de extremidade com ACLs.

Documentação detalhada sobre a implantação do Always On com SQL Server em VMs do Azure lista como:

• Apresentando grupos de disponibilidade Always On do SQL Server em máquinas virtuais do Azure.
• Configurar um grupo de disponibilidade Always On em máquinas virtuais do Azure em diferentes regiões.
• Configurar um balanceador de carga para um grupo de disponibilidade Always On no Azure.
• Práticas recomendadas de configuração de HADR (SQL Server em VMs do Azure)

O SQL Server Always On é a funcionalidade de alta disponibilidade e recuperação de desastres mais comumente usada no Azure para implantações de carga de trabalho SAP. A maioria dos clientes usa o Always On para alta disponibilidade em uma única região do Azure. Se a implantação for restrita a apenas dois nós, você terá duas opções de conectividade:

• Usando o ouvinte do grupo de disponibilidade. Com o Availability Group Listener, você precisa implantar um balanceador de carga do Azure.
• Com o SQL Server 2016 SP3, SQL Server 2017 CU 25 ou SQL Server 2019 CU8 ou versões mais recentes do SQL Server no Windows Server 2016 ou posterior, você pode usar o ouvinte de Nome de Rede Direto (DNN) em vez de um balanceador de carga do Azure. O DNN está eliminando a necessidade de usar um balanceador de carga do Azure.

O uso dos parâmetros de conectividade do espelhamento de banco de dados do SQL Server deve ser considerado apenas para a rodada de investigação de problemas com os outros dois métodos. Nesse caso, você precisa configurar a conectividade dos aplicativos SAP de forma que ambos os nomes dos nós sejam nomeados. Os detalhes exatos dessa configuração do lado SAP estão documentados na Nota SAP #965908. Ao usar essa opção, você não precisará configurar um ouvinte de Grupo de Disponibilidade. E com isso não há balanceador de carga do Azure e com isso não é possível investigar problemas desses componentes. Mas lembre-se, essa opção só funciona se você restringir seu Grupo de Disponibilidade para abranger duas instâncias.

A maioria dos clientes está usando a funcionalidade Always On do SQL Server para recuperação de desastres entre regiões do Azure. Vários clientes também usam a capacidade de realizar backups de uma réplica secundária.

Transparent Data Encryption SQL Server

Muitos clientes estão usando a TDE (Transparent Data Encryption) do SQL Server ao implantar os bancos de dados SAP do SQL Server no Azure. A funcionalidade TDE do SQL Server é totalmente suportada pela SAP (veja a Nota SAP #1380493).

Aplicação de TDE do SQL Server

Nos casos em que você executa uma migração heterogênea de outro banco de dados, em execução local, para o Windows/SQL Server em execução no Azure, você deve criar seu banco de dados de destino vazio no SQL Server com antecedência. O próximo passo é aplicar a funcionalidade TDE do SQL Server nesse banco de dados vazio. O motivo pelo qual você deseja executar essa sequência é que o processo de criptografia do banco de dados vazio pode levar um bom tempo. Os processos de importação do SAP importariam os dados para o banco de dados criptografado durante a fase de inatividade. A sobrecarga de importação para um banco de dados criptografado tem um impacto de tempo muito menor do que criptografar o banco de dados após a fase de exportação na fase de tempo de inatividade. Houve experiências negativas ao tentar aplicar o TDE com a carga de trabalho SAP em execução no banco de dados. Portanto, a recomendação é tratar a implantação do TDE como uma atividade que precisa ser realizada com pouca ou nenhuma carga de trabalho SAP no banco de dados específico. Do SQL Server 2016 em diante, você pode parar e retomar a verificação de TDE que executa a criptografia inicial. O documento Criptografia Transparente de Dados (TDE) descreve o comando e os detalhes.

Nos casos em que você move bancos de dados SAP SQL Server locais para o Azure, recomendamos testar em qual infraestrutura você pode aplicar a criptografia mais rapidamente. Para este caso, tenha em mente esses fatos:

• Você não pode definir quantos threads são usados ​​para aplicar a criptografia de dados ao banco de dados. O número de threads depende principalmente do número de volumes de disco nos quais os dados e arquivos de log do SQL Server são distribuídos. Significa que quanto mais volumes distintos (letras de unidade), mais threads são envolvidos em paralelo para executar a criptografia. Essa configuração contradiz um pouco a sugestão anterior de configuração de disco sobre a criação de um ou um número menor de espaços de armazenamento para os arquivos de banco de dados do SQL Server em VMs do Azure. Uma configuração com alguns volumes fará com que alguns threads executem a criptografia. Uma criptografia de thread única lê extensões de 64 KB, criptografa-as e então grava um registro no arquivo de log de transações, informando que a extensão foi criptografada. Como resultado, a carga no log de transações é moderada.
• Nas versões mais antigas do SQL Server, a compactação de backup não obteve mais eficiência quando você criptografou o banco de dados do SQL Server. Esse comportamento pode se tornar um problema quando seu plano é criptografar seu banco de dados SQL Server localmente e depois copiar um backup no Azure para restaurar o banco de dados no Azure. A compactação de backup do SQL Server pode atingir uma taxa de compactação de fator 4.
• Com o SQL Server 2016, o SQL Server introduziu uma nova funcionalidade que permite compactar o backup de bancos de dados criptografados de maneira eficiente. Veja esse blog para mais detalhes.

Como usar o Azure Key Vault

O Azure oferece o serviço de um Key Vault para armazenar chaves de criptografia. SQL Server no outro lado oferece um conector para usar o Azure Key Vault como repositório para os certificados TDE.

Mais detalhes sobre como usar o Azure Key Vault para listas de TDE do SQL Server, como:

• Configurar a integração do Azure Key Vault para SQL Server em VMs do Azure (Resource Manager).
• Mais perguntas de clientes sobre criptografia transparente de dados do SQL Server – TDE + Azure Key Vault.

Configurações mínimas de implantação

Nesta seção, sugerimos um conjunto mínimo de configurações para diferentes tamanhos de bancos de dados na carga de trabalho SAP. É muito difícil avaliar se esses tamanhos se encaixam na sua carga de trabalho específica. Em alguns casos, podemos ser generosos na memória em comparação com o tamanho do banco de dados. Por outro lado, o dimensionamento do disco pode ser muito baixo para algumas das cargas de trabalho. Portanto, essas configurações devem ser tratadas como realmente são. Elas são configurações iniciais. Configurações para ajustar a carga de trabalho específica e os requisitos de eficiência de custo.

Um exemplo de configuração para uma pequena instância do SQL Server com um tamanho de banco de dados entre 50 GB e 250 GB poderia ser semelhante a

Um exemplo de uma configuração ou uma pequena instância do SQL Server com um tamanho de banco de dados entre 250 GB e 750 GB, como um sistema SAP Business Suite menor, poderia ser semelhante a

Um exemplo de configuração para uma instância média do SQL Server com um tamanho de banco de dados entre 750 GB e 2.000 GB, como um sistema SAP Business Suite médio, poderia ser semelhante a

Um exemplo de configuração para uma instância maior do SQL Server com um tamanho de banco de dados entre 2.000 GB e 4.000 GB, como um sistema SAP Business Suite maior, poderia ser semelhante a

Um exemplo de configuração para uma grande instância do SQL Server com um tamanho de banco de dados de 4 TB+, como um grande sistema SAP Business Suite usado globalmente, poderia ser semelhante a

Como exemplo, essa configuração é a configuração da VM do banco de dados de um SAP Business Suite no SQL Server. Essa VM hospeda o banco de dados de 30TB da única instância global do SAP Business Suite de uma empresa global com mais de US$200 bilhões de receita anual e mais de 200 mil funcionários em tempo integral. O sistema executa todo o processamento financeiro, de vendas e distribuição, além de muitos outros processos comerciais de diferentes áreas, incluindo a folha de pagamento norte-americana. O sistema está em execução no Azure desde o início de 2018 usando VMs da série M do Azure como VMs de banco de dados. Como alta disponibilidade, o sistema está usando Always On com uma réplica síncrona em outra Zona de Disponibilidade da mesma região do Azure. E outra réplica assíncrona em outra região do Azure. A camada de aplicativo NetWeaver é implantada nas famílias de VMs D(a)/E(a) mais recentes.

Resumo geral do SQL Server para SAP no Azure

Há muitas recomendações nesse guia e recomendamos que você o leia mais de uma vez antes de planejar sua implantação do Azure. Em geral, porém, certifique-se de seguir as principais recomendações específicas do SQL Server no Azure:

1. Use a versão mais recente do SQLServer, como o SQL Server 2022, que tem mais vantagens no Azure.
2. Planeje cuidadosamente o cenário do seu sistema SAP no Azure para equilibrar o layout do arquivo de dados e as restrições do Azure:
   • Não tenha muitos discos, mas tenha o suficiente para garantir que você possa atingir o IOPS necessário.
     • Faça a segmentação entre discos somente se você precisar atingir uma taxa de transferência maior.
3. Nunca instale software nem coloque arquivos que exijam persistência na unidade D:\, pois ela não é permanente. Qualquer coisa nessa unidade pode ser perdida em uma reinicialização do Windows ou na reinicialização da VM.
4. Use sua solução SQL Server Always On para replicar dados do banco de dados.
5. Sempre use Resolução de Nomes, não confie em endereços IP.
6. Usando o SQL Server TDE, aplique os patches mais recentes do SQL Server.
7. Tenha cuidado ao usar imagens do SQL Server do Azure Marketplace. Se você usar o SQL Server, deverá alterar a ordenação da instância antes de instalar qualquer sistema SAP NetWeaver nele.
8. Instalar e configurar o SAP Host Monitoring para Azure conforme descrito no Guia de Implantação.

Próximas etapas

Leia o artigo

• Considerações sobre a implantação de DBMS de máquinas virtuais do Azure para carga de trabalho SAP