Executar o SAP HANA no Azure (Instâncias Grandes)

Esta arquitetura de referência mostra um conjunto de práticas comprovadas para executar o SAP HANA no Azure (instâncias grandes) com alta disponibilidade (HA) e recuperação de desastres (DR). Chamada de HANA Large Instances (HLI), essa oferta é implantada em servidores físicos em regiões do Azure. Esta solução descreve um cenário de expansão simples para demonstrar os principais conceitos na implantação e operação de um sistema SAP HANA no Azure. Para obter opções, consulte outros cenários de instalação para instâncias grandes do HANA.

Arquitetura

Transfira um ficheiro do Visio desta arquitetura.

Fluxo de trabalho

Essa arquitetura consiste nos seguintes componentes de infraestrutura.

• Rede virtual. O serviço Rede Virtual do Azure (VNet) conecta com segurança os recursos do Azure entre si e é subdividido em sub-redes separadas para cada camada. As camadas de aplicativo SAP são implantadas em VMs (Máquinas Virtuais) do Azure para se conectar à camada de banco de dados HANA residente em instâncias grandes.

• Rede HLI Revisão 4.5. A partir de julho de 2021, a revisão atualizada do HLI Rev 4 está disponível. Essa implementação atualizada [rev4.5] inclui muitas melhorias na infraestrutura, como rede de 100 Gb/s para o armazenamento NFS e melhor redundância de rede do servidor de banco de dados. Neste design, os servidores HLI são implantados em datacenters do Azure próximos às VMs do Azure onde os servidores de aplicativos SAP estão sendo executados. Quando usado em conjunto com uma configuração [ExpressRoute FastPath][fastpath], a Rev 4.5 eleva o desempenho do aplicativo. Esses recursos de rede também suportam as implantações Rev 3 e Rev 4.

• Máquinas virtuais (VMs) . As VMs são usadas na camada de aplicativos SAP e na camada de serviços compartilhados. Este último inclui uma caixa de salto usada pelos administradores para configurar instâncias grandes do HANA e fornecer acesso a outras VMs. Para colocalizar os servidores de aplicativos SAP no mesmo datacenter com as unidades HANA Large Instance, use grupos de posicionamento de proximidade.

• HANA Grande Instância. Este servidor físico é certificado para atender aos padrões TDI (Tailored Datacenter Integration) do SAP HANA para executar o SAP HANA. Essa arquitetura usa duas instâncias grandes do HANA: uma unidade de computação primária e uma secundária. A alta disponibilidade na camada de dados é fornecida por meio da replicação do sistema HANA (HSR).

• Par de Alta Disponibilidade. Um grupo de lâminas HANA Large Instances é gerenciado em conjunto para fornecer redundância e confiabilidade de banco de dados.

• Microsoft Enterprise Edge (MSEE). MSEE é um ponto de conexão de um provedor de conectividade ou sua borda de rede através de um circuito de Rota Expressa.

• Placas de interface de rede (NICs). Para habilitar a comunicação, o servidor HANA Large Instance fornece quatro NICs virtuais por padrão. Essa arquitetura requer uma NIC para comunicação com o cliente, uma segunda NIC para a conectividade nó a nó necessária para HSR, uma terceira NIC para armazenamento de instância grande HANA e uma quarta para iSCSI usado em clusters de alta disponibilidade.

• Armazenamento NFS (Network File System). O servidor NFS suporta o compartilhamento de arquivos de rede que fornece persistência segura de dados para HANA Large Instance.

• Rota Expressa. ExpressRoute é o serviço de rede do Azure recomendado para criar conexões privadas entre uma rede local e VNets do Azure que não passam pela Internet pública. As VMs do Azure se conectam às Instâncias Grandes do HANA usando outra conexão de Rota Expressa. A conexão ExpressRoute entre a VNet do Azure e as Instâncias Grandes do HANA é configurada como parte da oferta da Microsoft.

• Gateway. O ExpressRoute Gateway é usado para conectar a VNet do Azure usada para a camada de aplicativo SAP à rede HANA Large Instance. Use o SKU de Alto Desempenho ou Ultra Desempenho .

• Recuperação de desastres (DR). As opções de DR incluem HSR (HANA System Replication), backup e restauração de arquivos HANA ou replicação de armazenamento. Mediante solicitação, a equipe de Gerenciamento de Serviços da Microsoft pode configurar os servidores e volumes de armazenamento. Você é responsável por agendar o snapshot de armazenamento, testar o sistema e se familiarizar com o processo de recuperação. Outras considerações se aplicam à camada de aplicativo para SAP NetWeaver e SAP S/4HANA no Azure.

Recomendações

Os requisitos podem variar, por isso utilize estas recomendações como ponto de partida.

Computação de instâncias grandes do HANA

As instâncias grandes do HANA são servidores físicos baseados na arquitetura de CPU Intel Broadwell e Cascade Lake e configurados em um carimbo de instância grande, ou seja, um conjunto específico de servidores ou blades. Uma unidade de computação é igual a um servidor ou lâmina, e um carimbo é composto por vários servidores ou lâminas. Dentro de um carimbo de instância grande, os servidores não são compartilhados e são dedicados a executar a implantação do SAP HANA por um cliente.

Uma variedade de SKUs está disponível para instâncias grandes do HANA, suportando até 24 TB de instância única (expansão de 120 TB) de memória para BW/4HANA ou outras cargas de trabalho do SAP HANA.

Escolha uma SKU que atenda aos requisitos de dimensionamento determinados em suas sessões de arquitetura e design. Certifique-se sempre de que o seu dimensionamento se aplica ao SKU correto. Os recursos e os requisitos de implantação variam de acordo com o tipo, e a disponibilidade varia de acordo com a região. Você também pode passar de um SKU para um SKU maior.

A Microsoft ajuda a estabelecer a configuração de instância grande, mas é sua responsabilidade verificar as definições de configuração do sistema operacional. Certifique-se de revisar as notas SAP mais atuais para sua versão exata do Linux.

Armazenamento

O layout de armazenamento é implementado de acordo com a recomendação do TDI para SAP HANA. As instâncias grandes do HANA vêm com uma configuração de armazenamento específica para as especificações TDI padrão. No entanto, você pode comprar armazenamento adicional em incrementos de 1 TB.

Para dar suporte aos requisitos de ambientes de missão crítica, incluindo recuperação rápida, o NFS é usado e não o armazenamento com conexão direta. O servidor de armazenamento NFS para instâncias grandes HANA é hospedado em um ambiente multilocatário, onde os locatários são segregados e protegidos usando computação, rede e isolamento de armazenamento.

Para oferecer suporte à alta disponibilidade no local principal, use layouts de armazenamento diferentes. Por exemplo, em uma expansão de vários hosts, o armazenamento é compartilhado. Outra opção de alta disponibilidade é a replicação baseada em aplicativos, como HSR. Para DR, no entanto, uma replicação de armazenamento baseada em snapshot é usada.

Rede

Essa arquitetura usa redes virtuais e físicas. A rede virtual faz parte da infraestrutura como serviço (IaaS) do Azure e se conecta a uma rede física HANA Large Instances discreta por meio de circuitos ExpressRoute . Um gateway entre locais conecta suas cargas de trabalho na VNet do Azure aos seus sites locais.

Todas as implantações de Instância Grande do HANA desde julho de 2019 usam selos Rev 4, que são implantados na proximidade dos hosts de VM do Azure usados para os servidores de aplicativos SAP. Como resultado, a implantação do Rev 4 minimiza a latência da rede entre as camadas do aplicativo e do banco de dados.

As redes HANA Large Instances são isoladas umas das outras por segurança. As instâncias que residem em regiões diferentes não se comunicam entre si, exceto para a replicação de armazenamento dedicada. No entanto, para utilizar o transporte ferroviário de alta velocidade, são necessárias comunicações entre regiões. [Azure Global Reach] [globalreach], tabelas de roteamento IP ou proxies podem ser usados para habilitar o HSR entre regiões.

Todas as VNets do Azure que se conectam a Instâncias Grandes do HANA em uma região podem ser conectadas via Rota Expressa para Instâncias Grandes do HANA em uma região secundária.

O circuito ExpressRoute para instâncias grandes do HANA é incluído por padrão durante o provisionamento. Para a configuração, é necessário um layout de rede específico, incluindo intervalos de endereços CIDR (Classless Inter-Domain Routing) e roteamento de domínio necessários. Para obter detalhes, consulte Infraestrutura e conectividade do SAP HANA (instâncias grandes) no Azure.

Para reduzir a latência da rede e melhorar o desempenho, considere habilitar o FastPath (também conhecido como MSEE v2). Essa configuração de rede permite que o tráfego do local para a VNet do Azure e da VNet para as Instâncias Grandes do HANA ignorem o gateway do Azure.

Considerações

Escalabilidade

Para aumentar ou diminuir a escala, você pode escolher entre vários tamanhos de servidores disponíveis para instâncias grandes do HANA. Eles são categorizados como Tipo I e Tipo II e adaptados para diferentes cargas de trabalho. Escolha um tamanho que possa crescer com sua carga de trabalho pelos próximos três anos. Estão igualmente disponíveis compromissos para um ano.

Uma implantação escalável de vários hosts é geralmente usada para implantações BW/4HANA como um tipo de estratégia de particionamento de banco de dados. No momento em que este artigo foi escrito, o BW/4HANA em instâncias grandes HANA pode ser expandido para 120 TB. Para dimensionar, planeje o posicionamento das tabelas HANA antes da instalação. Do ponto de vista da infraestrutura, vários hosts são conectados a um volume de armazenamento compartilhado, permitindo a rápida tomada de controle por hosts em espera caso um dos nós de trabalho de computação no sistema HANA falhe.

O S/4HANA e o SAP Business Suite em HANA em uma única lâmina podem ser dimensionados até 24 TB com um nó de instância única. As Grandes Instâncias HANA e a infraestrutura de armazenamento do Azure também suportam implantações em expansão S/4HANA e BW/4HANA. Para SKUs específicas certificadas para expansão, consulte o diretório [SAP certified hardware][directory].

Os requisitos de memória para HANA aumentam à medida que o volume de dados cresce. Use o consumo de memória atual do seu sistema como base para prever o consumo futuro e, em seguida, mapeie sua demanda em um dos tamanhos de instâncias grandes do HANA.

Se você já tiver implantações SAP, o SAP fornecerá relatórios que você pode usar para verificar os dados usados pelos sistemas existentes e calcular os requisitos de memória para uma instância HANA. Por exemplo, consulte as seguintes notas SAP (o acesso requer uma conta do SAP Service Marketplace):

• SAP Note 1793345 - Dimensionamento do SAP Suite no HANA
• SAP Note 1872170 - Suite no relatório de dimensionamento HANA e S/4 HANA
• SAP Note 2121330 - FAQ: SAP BW on HANA Sizing Report
• SAP Note 1736976 - Relatório de dimensionamento para BW no HANA
• SAP Note 2296290 - Novo relatório de dimensionamento para BW no HANA

Disponibilidade

A redundância de recursos é o tema geral em soluções de infraestrutura altamente disponíveis. Trabalhe com a SAP, seu integrador de sistemas ou a Microsoft para arquitetar e implementar adequadamente uma estratégia de alta disponibilidade e recuperação de desastres. Essa arquitetura segue o contrato de nível de serviço (SLA) do Azure para HANA no Azure (Instâncias Grandes). Para avaliar seus requisitos de disponibilidade, considere quaisquer pontos únicos de falha, o nível desejado de tempo de atividade para serviços e estas métricas comuns:

• RTO (Recovery Time Objetive, objetivo de tempo de recuperação) significa a duração do tempo em que o servidor HANA Large Instances não está disponível.

• RPO (Recovery Point Objetive, objetivo de ponto de recuperação) significa o período máximo tolerável no qual os dados do cliente podem ser perdidos devido a uma falha.

Para alta disponibilidade, implante mais de uma instância em um par HA e use HSR em modo síncrono para minimizar a perda de dados e o tempo de inatividade. Além de uma configuração local de alta disponibilidade de dois nós, o HSR dá suporte à replicação de várias camadas, onde um terceiro nó em uma região separada do Azure se registra na réplica secundária do par HSR clusterizado como seu destino de replicação. Isso forma uma cadeia de margarida de replicação.

O failover para o nó DR é um processo manual sem clustering Linux. Para deteção automática de falhas e failover, você pode configurar o Pacemaker para reduzir ainda mais o tempo de inatividade causado por falhas de software ou hardware. A partir do HANA 2.0 SPS 04, o HSR também oferece suporte à replicação de vários destinos. Em vez de uma cadeia de margaridas, essa forma de replicação tem um assinante principal e vários assinantes secundários.

Ao configurar o HANA Large Instances HSR com failover automático, você pode solicitar à equipe de Gerenciamento de Serviços da Microsoft para configurar um dispositivo STONITH para seus servidores HANA Large Instances.

Recuperação após desastre

Essa arquitetura dá suporte à recuperação de desastres entre instâncias grandes do HANA em diferentes regiões do Azure. Há duas maneiras de dar suporte à DR com instâncias grandes do HANA:

• Replicação de armazenamento. O conteúdo do armazenamento principal é constantemente replicado para os sistemas de armazenamento de DR remotos disponíveis no servidor de instâncias grandes DR HANA designado. Na replicação de armazenamento, o banco de dados HANA não é carregado na memória. Esta opção de DR é mais simples do ponto de vista da administração. Para determinar se essa é uma estratégia adequada, considere o tempo de carregamento do banco de dados em relação ao SLA de disponibilidade. A replicação de armazenamento também permite executar a recuperação point-in-time. Se a DR multiuso (custo otimizado) estiver configurada, você deverá adquirir armazenamento adicional do mesmo tamanho no local de DR. A Microsoft fornece instantâneo de armazenamento de autoatendimento e scripts de failover para failover do HANA como parte da oferta de Instâncias Grandes do HANA.

• HSR de várias camadas ou de vários destinos com uma terceira réplica na região DR (onde o banco de dados HANA é carregado na memória). Esta opção suporta um tempo de recuperação mais rápido, mas não suporta uma recuperação point-in-time. O transporte ferroviário de alta velocidade requer um sistema secundário. O tráfego de replicação do sistema HANA destinado ao site de DR pode ser roteado através de proxies, como nginx ou tabelas IP. Como alternativa, o Global Reach pode ser usado para conectar os circuitos da Rota Expressa, permitindo que os usuários permitidos se conectem diretamente à unidade HANA Large Instances.

Otimização de custos

Utilize a calculadora de preços do Azure para prever os custos.

Para obter mais informações, veja a secção de custos Well-Architected Framework do Microsoft Azure.

As SKUs podem afetar o modelo de faturamento. Aqui estão algumas considerações de custo.

Máquinas virtuais

Nessa arquitetura de referência, as máquinas virtuais são usadas para hospedar aplicativos SAP, serviços SAP e serviços compartilhados, como caixas de salto de gerenciamento. Existem certas SKUs certificadas de HANA Large Instances. As configurações dependem da carga de trabalho, dos recursos da CPU, da memória desejada e do orçamento.

As SKUs de instâncias grandes do HANA estão disponíveis como instâncias de VM reservadas. As Reservas do Azure podem reduzir seu custo se você puder se comprometer com um ou três anos de prazo. As reservas de VM podem reduzir os custos em até 72% quando comparadas com os preços pré-pagos. Você obtém uma infraestrutura SAP HANA desenvolvida especificamente com computação, armazenamento e rede. O HANA Large Instances é acoplado ao armazenamento e à rede NFS e fornece suporte integrado para backups por meio de snapshots de armazenamento, alta disponibilidade e recuperação de desastres e configurações de scale-out. Se a sua carga de trabalho não tiver um tempo previsível de conclusão ou consumo de recursos, considere a opção de pagamento conforme o uso.

Use a visão geral do plano de economia do Azure e combine com as Reservas do Azure. O plano de poupança do Azure é um plano de poupança de custos flexível que gera poupanças significativas nos preços pré-pagos. Você concorda com um contrato de um ou três anos e recebe descontos em serviços de computação qualificados. As economias se aplicam a esses serviços de computação, independentemente da região, tamanho da instância ou sistema operacional. Para obter mais informações, consulte a documentação do plano de poupança do Azure.

Use VMs spot do Azure para executar cargas de trabalho que podem ser interrompidas e não exigem conclusão dentro de um período de tempo predeterminado ou um SLA.

Para obter mais informações, consulte a seção "SAP HANA on Azure Large Instances" em HLI for SAP HANA Virtual Machines Pricing.

Azure ExpressRoute

Para essa arquitetura, o Azure ExpressRoute é usado como o serviço de rede para criar conexões privadas entre uma rede local e redes virtuais do Azure. As VMs do Azure se conectam a instâncias grandes do HANA usando outra conexão de Rota Expressa e um Gateway de Rota Expressa. High Performance ou Ultra Performance é o SKU recomendado.

Toda a transferência de dados de entrada é gratuita. Toda a transferência de dados de saída é cobrada com base em uma taxa pré-determinada. Para obter mais informações, consulte Preços do Azure ExpressRoute.

Backup

Com base nos requisitos do seu negócio, escolha entre várias opções disponíveis.

Para obter detalhes sobre uma abordagem "faça você mesmo" para backup e mais opções fornecidas com instâncias grandes do HANA, consulte o artigo [Backup e restauração][backup-restauração].

Capacidade de gestão

Monitore os recursos de instâncias grandes do HANA — como CPU, memória, largura de banda de rede e espaço de armazenamento — usando o SAP HANA Studio, o SAP HANA Cockpit, o SAP Solution Manager e outras ferramentas Linux nativas. Os SKUs HANA Large Instances Tipo I não vêm com ferramentas de monitoramento integradas. Os SKUs Tipo II oferecem ferramentas de diagnóstico pré-construídas para registro de atividades do sistema e solução de problemas.

A Microsoft oferece ferramentas e recursos básicos para ajudá-lo a monitorar instâncias grandes do HANA no Azure. A equipe de suporte da Microsoft também pode ajudá-lo na solução de problemas técnicos.

Segurança

• Desde o final de 2018, o armazenamento de instâncias grandes do HANA é criptografado por padrão.

• Os dados em trânsito entre as instâncias grandes do HANA e as VMs não são criptografados. Para criptografar a transferência de dados, habilite a criptografia específica do aplicativo. Consulte SAP Note 2159014 - FAQ: SAP HANA Security.

• O isolamento fornece segurança entre os locatários no ambiente de instância grande HANA multilocatário. Os locatários são isolados usando sua própria VLAN.

• As práticas recomendadas de segurança de rede do Azure fornecem orientações úteis.

• Como em qualquer implantação, a proteção do sistema operacional é recomendada, incluindo a proteção da imagem do SUSE Linux para SAP no Azure.

• Para segurança física, o acesso aos datacenters do Azure é limitado apenas a pessoal autorizado. Nenhum cliente pode acessar os servidores físicos.

Para obter mais informações, consulte Segurança do SAP HANA — uma visão geral. (Uma conta do SAP Service Marketplace é necessária para o acesso.)

Comunidades

As comunidades podem responder às suas perguntas e ajudá-lo a configurar uma implementação com êxito. Considere o seguinte:

• Executando aplicativos SAP no blog da plataforma Microsoft
• SAP de estouro de pilha

Contribuidores

Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.

Autor principal:

• Ben Trinh - Brasil | Arquiteto Principal

Para ver perfis não públicos do LinkedIn, inicie sessão no LinkedIn.

Recursos relacionados

Talvez você queira revisar os seguintes cenários de exemplo do Azure que demonstram soluções específicas usando algumas das mesmas tecnologias:

• Executando cargas de trabalho de produção SAP usando um banco de dados Oracle no Azure
• Ambientes de desenvolvimento/teste para cargas de trabalho SAP no Azure