Guia

Selecionar uma VM para um banco de dados SAP HANA em produção.

→Use VMs das séries Mv2 ou M para bancos de dados grandes (>4TB). Use VMs da série Edsv5, certificadas pela SAP, para bancos de dados HANA de produção menores (<4TB).

Por quê: As séries M/Mv2 são certificadas pela SAP para cargas de trabalho de grande memória. A série Edsv5 oferece uma opção certificada e econômica para instâncias HANA menores. Outras séries (D, F, L) não são certificadas para bancos de dados HANA em produção.

Referência↗

Selecionar uma VM para um servidor de aplicação SAP NetWeaver.

→Use VMs das séries Edsv5 ou Ddsv5. Dimensionar com base nos requisitos de SAPS dos relatórios SAP EarlyWatch Alert ou SAP Quick Sizer.

Por quê: As VMs das séries E e D fornecem uma proporção equilibrada de CPU para memória, adequada para cargas de trabalho de servidores de aplicação SAP e são certificadas pela SAP para NetWeaver.

Garantir latência mínima de rede entre os servidores de aplicação SAP e o servidor de banco de dados.

→Implantar todas as VMs relacionadas (servidores de aplicação, ASCS/ERS, banco de dados) dentro de um único Grupo de Posicionamento por Proximidade (PPG).

Por quê: PPGs co-localizam fisicamente VMs no mesmo datacenter, minimizando o tempo de ida e volta da rede para atender ao requisito de latência sub-milissegundo da SAP entre as camadas de aplicação e banco de dados.

Fornecer um sistema de arquivos compartilhado para o volume /hana/shared em uma implantação SAP HANA scale-out.

→Use o Azure NetApp Files (ANF) com o protocolo NFS.

Por quê: O ANF é a solução de armazenamento NFS compartilhada, de alto desempenho e certificada pela SAP, necessária para configurações HANA scale-out. Armazenamento em bloco, como Managed Disks, não pode ser usado para esse fim.

Fornecer um sistema de arquivos compartilhado de alta disponibilidade para /sapmnt e o diretório global de transporte (/usr/sap/trans).

→Use Azure NetApp Files (NFS) ou Azure Files Premium (NFS). Para Windows, use Azure Files Premium (SMB) ou cluster SOFS.

Por quê: Esses serviços fornecem compartilhamentos de arquivos gerenciados e de alta disponibilidade com o desempenho e o suporte de protocolo necessários (NFS para Linux, SMB para Windows), eliminando a necessidade de construir e gerenciar um cluster de servidor de arquivos separado.

Projetar armazenamento para volumes de produção SAP HANA /hana/data e /hana/log que exigem alto IOPS e latência sub-milissegundo.

→Use Azure Ultra Disk ou Managed Disks Premium SSD v2. Para /hana/log em VMs da série M, Premium SSD com Write Accelerator também é uma opção válida.

Por quê: Ultra Disk e Premium SSD v2 atendem aos rigorosos KPIs de IOPS, throughput e latência sub-milissegundo definidos pela SAP para cargas de trabalho HANA em produção. Tiers de armazenamento padrão não são suportados.

Projetar uma arquitetura de rede segura para cargas de trabalho SAP, isolando ambientes de produção de não-produção.

→Use uma topologia hub-spoke. Implante sistemas SAP em VNets spoke dedicadas para cada ambiente (Prod, QA, Dev). Use Grupos de Segurança de Rede (NSGs) para impor regras de tráfego rigorosas entre sub-redes.

Por quê: Isso fornece forte isolamento de rede no nível da VNet e controle de tráfego granular com NSGs, seguindo as melhores práticas de segurança e o conceito de Azure Landing Zone.

Implantar landscapes SAP no Azure usando uma abordagem de Infraestrutura como Código (IaC) para consistência e automação.

→Use o Framework de Automação de Implantação oficial do SAP on Azure, que utiliza Terraform e Ansible. Alternativamente, construa módulos Bicep ou Terraform personalizados.

Por quê: O framework fornece templates pré-construídos e validados pela SAP para implantar todo o landscape (plano de controle, zonas de carga de trabalho, sistemas SAP), reduzindo o esforço manual e garantindo a adesão às melhores práticas.

Publicar com segurança SAP Fiori ou outras aplicações SAP baseadas na web para usuários externos pela internet.

→Use o Azure Application Gateway com o Web Application Firewall (WAF) habilitado.

Por quê: O Application Gateway fornece balanceamento de carga de Camada 7, terminação SSL e proteção WAF contra vulnerabilidades web comuns, tornando-o o ponto de entrada ideal e seguro para aplicações SAP baseadas na web.

Implantar um banco de dados SAP HANA extremamente grande (>12 TB de memória) que excede a capacidade da VM do Azure.

→Use o SAP HANA on Azure Large Instances (HLI). A conectividade requer um circuito ExpressRoute conectando o stamp HLI a uma VNet do Azure via um gateway ExpressRoute.

Por quê: HLI são servidores bare-metal construídos para um propósito específico, fornecendo a enorme memória e desempenho necessários para as maiores cargas de trabalho HANA, que estão além da escala da infraestrutura virtualizada atual.

Implantar um sistema SAP em Zonas de Disponibilidade, minimizando a latência dentro de cada zona.

→Crie um Grupo de Posicionamento por Proximidade (PPG) separado para os recursos em cada Zona de Disponibilidade. Fixe cada PPG à sua respectiva zona.

Por quê: Um único PPG não pode abranger zonas. Esta abordagem garante co-localização de recursos com baixa latência *dentro* de uma zona, enquanto ainda alcança alta disponibilidade *entre* zonas.

Criar e distribuir imagens de VM padronizadas, com patches e pré-configuradas para implantações SAP em múltiplas regiões.

→Use o Azure Image Builder para definir um processo repetível de criação de imagens. Armazene e replique as imagens gerenciadas resultantes usando o Azure Compute Gallery.

Por quê: Isso fornece uma fábrica de "golden images" automatizada e com controle de versão, garantindo consistência e reduzindo o tempo de implantação em comparação com a configuração manual de cada nova VM.

Fornecer acesso administrativo seguro via RDP/SSH a VMs SAP sem expô-las à internet pública.

→Implante o Azure Bastion (SKU Standard) em uma sub-rede dedicada dentro da rede virtual SAP. Use o Bastion para conectar-se a VMs via portal do Azure ou clientes nativos.

Por quê: O Bastion atua como uma jump box segura e gerenciada, eliminando a necessidade de endereços IP públicos em VMs SAP ou configurações complexas de VPN para acesso administrativo, reduzindo assim a superfície de ataque.

Criptografar volumes de dados SAP usando chaves de criptografia gerenciadas pelo cliente.

→Use o Azure Disk Encryption com uma chave gerenciada pelo cliente (CMK) armazenada no Azure Key Vault. Isso pode ser combinado com a criptografia nativa do SAP HANA para defesa em profundidade.

Por quê: Esta configuração dá ao cliente controle total sobre as chaves de criptografia de dados, atendendo a rigorosos requisitos de conformidade e segurança para o gerenciamento do ciclo de vida das chaves.

Migrar um sistema SAP on-premises com um banco de dados não-HANA (por exemplo, Oracle, Db2) para SAP HANA no Azure.

→Use o SAP Software Update Manager (SUM) com a Opção de Migração de Banco de Dados (DMO). Para um tempo de inatividade mínimo, use as opções "DMO with System Move" ou near-Zero Downtime (nZDT).

Por quê: O DMO combina conversão de banco de dados, atualização de sistema e migração de dados em um único processo otimizado. É a ferramenta SAP padrão para esta tarefa, minimizando o tempo de inatividade em comparação com o export/import clássico.

Migrar um sistema SAP HANA on-premises para o Azure com o menor tempo de inatividade possível.

→Use a Replicação de Sistema SAP HANA (HSR) para replicar continuamente os dados para a VM de destino do Azure. Realize um cutover final e breve (takeover) durante a janela de manutenção.

Por quê: O HSR minimiza a janela de tempo de inatividade para minutos, pois apenas a sincronização final e o takeover são necessários. Métodos de backup/restauração ou export/import resultam em horas de tempo de inatividade para bancos de dados grandes.

Transferir um grande volume de dados SAP (>10 TB) de on-premises para o Azure para a carga de migração inicial quando a largura de banda da rede for insuficiente.

→Use o Azure Data Box para a transferência inicial de dados em massa. Use ExpressRoute ou VPN para a sincronização delta subsequente.

Por quê: O Data Box fornece um método de transferência offline mais rápido do que as transferências baseadas em rede com largura de banda limitada, reduzindo significativamente o tempo de carga inicial.

Implantar e gerenciar sistemas SAP S/4HANA no Azure usando uma experiência simplificada e guiada.

→Use o Azure Center for SAP solutions (ACSS). Os pré-requisitos incluem registrar o provedor `Microsoft.Workloads` e criar uma identidade gerenciada atribuída pelo usuário com as permissões necessárias.

Por quê: O ACSS simplifica a implantação, agrupando as melhores práticas e fornecendo um painel único no portal do Azure para gerenciamento básico (iniciar/parar, monitoramento) e verificações de qualidade.

Determinar os tamanhos corretos de VM do Azure para um sistema SAP novo ou migrado.

→Use a ferramenta SAP Quick Sizer para novas implementações. Para migrações, analise os relatórios SAP EarlyWatch Alert do sistema existente para obter o uso atual de SAPS e memória. Mapeie-os para VMs do Azure certificadas pela SAP.

Por quê: Essas ferramentas nativas da SAP fornecem a caracterização mais precisa da carga de trabalho (SAPS, memória, I/O), o que é essencial para selecionar corretamente os recursos do Azure e garantir desempenho e suporte.

Integrar um ambiente Azure gerenciado pelo cliente com um sistema SAP S/4HANA implantado via RISE with SAP.

→A SAP gerencia a infraestrutura subjacente do Azure em uma assinatura separada. Estabeleça conectividade de sua VNet do Azure para a VNet gerenciada pela SAP usando VNet Peering.

Por quê: RISE é uma oferta de serviço gerenciado da SAP. O VNet Peering fornece o caminho de integração de rede padrão, seguro e privado entre o ambiente RISE e outras cargas de trabalho do cliente no Azure.

Impor padrões corporativos e melhores práticas de segurança em todas as implantações SAP no Azure.

→Use o Azure Policy para impor regras, como exigir SKUs de VM específicos, criptografia de Managed Disk, associação de NSG ou marcação obrigatória. Use o efeito `DeployIfNotExists` para instalar automaticamente a Extensão de VM para SAP.

Por quê: O Azure Policy fornece governança automatizada em larga escala, garantindo que todas as implantações estejam em conformidade sem depender de verificações manuais ou configurações individuais de template.

Validar se a infraestrutura do Azure implantada está configurada corretamente e atende aos requisitos de suporte da SAP antes do go-live.

→Instale e habilite a Extensão de VM do Azure para SAP (Monitoramento Aprimorado). Execute a ferramenta SAP on Azure Quality Check do GitHub.

Por quê: A extensão da VM é obrigatória para o suporte SAP. A ferramenta Quality Check valida proativamente as configurações (armazenamento, rede, configurações de SO) contra uma lista de melhores práticas e requisitos conhecidos.

Implementar uma solução de backup automatizada e consistente com a aplicação para bancos de dados SAP HANA em VMs do Azure.

→Use o Azure Backup for SAP HANA, que se integra através da interface Backint certificada pela SAP. Configure uma política com backups completos/diferenciais e frequentes de log para recuperação pontual.

Por quê: O Azure Backup fornece uma solução nativa, integrada e certificada que automatiza o agendamento, retenção e gerenciamento de backups sem exigir scripts personalizados ou infraestrutura de backup separada.

Implementar monitoramento abrangente e centralizado para um landscape SAP executando no Azure.

→Implante o Azure Monitor for SAP Solutions. Configure provedores para telemetria de SAP HANA, NetWeaver, OS (Linux) e Cluster de Alta Disponibilidade.

Por quê: Este é um serviço nativo do Azure projetado para SAP. Ele fornece telemetria e visualizações ricas e cientes do SAP, centralizando o monitoramento de toda a pilha SAP, da infraestrutura à aplicação.

Aplicar patches de OS ou de kernel SAP a um cluster SAP de alta disponibilidade com tempo de inatividade mínimo.

→Use uma abordagem de atualização contínua. Coloque o nó secundário em modo de manutenção, aplique o patch e reinicie. Realize um failover de cluster controlado para tornar o nó corrigido o primário. Finalmente, aplique o patch no antigo nó primário.

Por quê: Esta abordagem contínua garante que o serviço SAP permaneça disponível em um nó durante todo o processo de manutenção, minimizando a interrupção do serviço de negócio.

Automatizar o processo de criação de cópias ou atualização de sistemas SAP (por exemplo, atualizar um sistema QAS a partir de PRD).

→Use o SAP Landscape Management (LaMa) com o Azure Connector.

Por quê: O LaMa orquestra o processo de ponta a ponta, incluindo tarefas de infraestrutura do Azure (parar/iniciar VM, snapshots de disco) e automação pós-cópia específica do SAP (BDLS), reduzindo significativamente o esforço manual.

Validar o plano de recuperação de desastres SAP sem impactar o ambiente de produção.

→Use o recurso "Test Failover" do Azure Site Recovery, que levanta VMs replicadas em uma VNet isolada. Para HSR, use restaurações baseadas em snapshot para um sistema isolado ou um alvo de replicação terciário dedicado.

Por quê: Testar em uma rede isolada previne conflitos de IP e qualquer interferência com sistemas de produção ou replicação em andamento, permitindo uma validação segura e completa do runbook de DR.

Planejar os requisitos futuros de recursos (CPU, memória, armazenamento) para um sistema SAP em crescimento no Azure.

→Use métricas do Azure Monitor e Log Analytics para analisar tendências de uso históricas. Use esses dados para previsão. Para armazenamento, aproveite a capacidade de redimensionar dinamicamente os Azure Managed Disks online.

Por quê: O gerenciamento proativo de capacidade baseado em dados históricos previne a degradação do desempenho e permite o provisionamento just-in-time, otimizando custos em comparação com o sobreprovisionamento inicial significativo.

Minimizar os custos do Azure para executar um landscape SAP completo.

→Para cargas de trabalho de produção, use Instâncias Reservadas do Azure de 1 ou 3 anos. Para sistemas não-produção, implemente agendamentos automáticos de início/parada via Azure Automation. Use o Azure Hybrid Benefit para licenças onde elegível.

Por quê: As Instâncias Reservadas oferecem grandes descontos para cargas de trabalho previsíveis 24/7. O desligamento automático elimina os custos de computação durante períodos ociosos para não-produção. Esta combinação aborda os dois principais impulsionadores de custos.

Rastrear e alocar custos do Azure para cargas de trabalho SAP a unidades de negócios, projetos ou sistemas SAP (SIDs) específicos.

→Implemente uma estratégia de marcação obrigatória para todos os recursos do Azure. Use tags como `CostCenter`, `Environment`, `SAP-SID` e `BusinessOwner`. Analise os custos usando o Azure Cost Management.

Por quê: A marcação é o mecanismo nativo do Azure para categorizar recursos. A marcação consistente permite uma análise de custos detalhada e chargeback, fornecendo visibilidade financeira essencial.

Diagnosticar problemas intermitentes de conectividade de rede ou latência entre VMs SAP no Azure.

→Use as ferramentas do Azure Network Watcher, especificamente o Connection Monitor para testar caminhos e latência, e os NSG Flow Logs para analisar e identificar tráfego bloqueado.

Por quê: O Network Watcher fornece ferramentas proativas e reativas para identificar problemas de rede no nível da plataforma Azure, o que é frequentemente difícil de diagnosticar apenas a partir do SO convidado.

Automatizar a aplicação de patches de OS para VMs SAP, garantindo que as aplicações sejam desligadas de forma graciosa.

→Use o Azure Update Manager com scripts pré/pós. O pré-script para a aplicação e o banco de dados SAP, e o pós-script os reinicia após a conclusão da aplicação de patches.

Por quê: Isso combina a automação do gerenciamento de patches do Azure com a consciência da aplicação necessária para SAP, prevenindo inconsistências de dados que poderiam ocorrer ao aplicar patches em um sistema em execução.

Implementar alta disponibilidade para SAP Central Services (ASCS/ERS) ou SAP HANA em VMs Linux SUSE/RHEL.

→Configure um cluster Pacemaker. Use o agente `fence_azure_arm` para STONITH (fencing) para prevenir cenários de split-brain, autenticado via uma identidade gerenciada.

Por quê: O Pacemaker é a solução de clusterização suportada pela SAP no Linux. O `fence_azure_arm` é o mecanismo nativo do Azure para isolar de forma confiável um nó com falha via APIs do Azure, o que é obrigatório para um cluster estável.

Implementar alta disponibilidade para SAP Central Services (ASCS/ERS) em VMs Windows Server.

→Configure um Windows Server Failover Cluster (WSFC). Para armazenamento compartilhado em cluster, use Azure Shared Disks ou uma solução de replicação de terceiros como SIOS DataKeeper.

Por quê: O WSFC é o padrão para clusterização Windows. O Azure Shared Disks fornece armazenamento de bloco compartilhado nativo, enquanto o SIOS cria um cluster "shared-nothing", ambos substituindo a necessidade de SANs tradicionais na nuvem.

Projetar uma estratégia de alta disponibilidade (HA) e recuperação de desastres (DR) para SAP HANA.

→Para HA (na região), implante VMs em Zonas de Disponibilidade e use a Replicação de Sistema SAP HANA (HSR) síncrona (SYNC). Para DR (entre regiões), use HSR assíncrona (ASYNC).

Por quê: A replicação síncrona oferece um RPO zero, mas requer baixa latência (<2ms), tornando-a ideal para HA entre zonas. A replicação assíncrona tolera maior latência entre regiões, tornando-a a escolha para DR.

Configurar um Azure Load Balancer para gerenciar o endereço IP virtual de um cluster SAP HA (ASCS/ERS ou HANA).

→Use um Azure Standard Load Balancer. Habilite o Floating IP (Direct Server Return) na regra de balanceamento de carga. Configure um health probe na porta específica monitorada pelo cluster (por exemplo, 620xx para ASCS).

Por quê: O SKU Standard é necessário para redundância de zona. O Floating IP é essencial para que o IP virtual do cluster funcione corretamente. O health probe específico garante que o tráfego seja enviado apenas para o nó ativo.

Entender o propósito do Enqueue Replication Server (ERS) em um cluster de alta disponibilidade SAP ASCS.

→A instância ERS mantém uma réplica da tabela de bloqueio SAP da instância ASCS ativa.

Por quê: Se a instância ASCS falhar, a instância ASCS recém-iniciada recupera a tabela de bloqueio replicada do ERS. Isso preserva os bloqueios de transação e permite que os usuários continuem trabalhando sem interrupção.

Projetar uma solução completa de recuperação de desastres para um landscape SAP de múltiplas camadas.

→Use replicação de banco de dados nativa para a camada de banco de dados (por exemplo, HSR assíncrono para HANA). Use o Azure Site Recovery (ASR) para a camada de aplicação (ASCS/ERS e servidores de aplicação).

Por quê: Esta abordagem "best-of-breed" garante a consistência da aplicação para o banco de dados via sua replicação nativa, enquanto o ASR fornece uma maneira econômica e automatizada de replicar e fazer failover das VMs do servidor de aplicação.

Implementar alta disponibilidade para um banco de dados SAP executando no Microsoft SQL Server em VMs do Azure.

→Use SQL Server Always On Availability Groups, tipicamente com modo de commit síncrono para HA dentro de uma região, combinado com um WSFC.

Por quê: Always On AG é a solução de HA/DR recomendada e totalmente suportada para SQL Server, fornecendo replicação no nível do banco de dados e capacidades de failover automático.

Implementar SBD (STONITH Block Device) como um mecanismo de quorum para um cluster Pacemaker de dois nós.

→Configure um pequeno Azure Shared Disk e anexe-o a ambos os nós do cluster. Alternativamente, configure um servidor iSCSI target dedicado em uma terceira VM.

Por quê: Embora `fence_azure_arm` seja o agente de fencing principal, o SBD fornece um mecanismo adicional de testemunha/quorum para prevenir o split-brain, especialmente em clusters sem um terceiro nó de votação.