Configurações e operações de infraestrutura do SAP HANA no Azure

  • Artigo

Este documento fornece orientação para configurar a infraestrutura do Azure e operar sistemas SAP HANA que são implantados em máquinas virtuais nativas (VMs) do Azure. O documento também inclui informações de configuração de expansão para a SKU de VM M128s do SAP HANA. Este documento não pretende substituir a documentação padrão do SAP, que inclui o seguinte conteúdo:

Pré-requisitos

Para usar este guia, você precisa ter um conhecimento básico dos seguintes componentes do Azure:

Para saber mais sobre o SAP NetWeaver e outros componentes SAP no Azure, consulte a seção SAP no Azure na documentação do Azure.

Considerações básicas sobre a instalação

As seções a seguir descrevem considerações de configuração básica para implantar sistemas SAP HANA em máquinas virtuais do Azure.

Conecte-se em máquinas virtuais do Azure

Conforme documentado no guia de planejamento de máquinas virtuais do Azure, há dois métodos básicos para se conectar em máquinas virtuais do Azure:

  • Conexão pela Internet e por pontos de extremidade públicos em uma VM de atalho ou na VM que executa o SAP HANA.
  • Conexão por meio de uma VPN ou do Azure ExpressRoute.

Uma conectividade site a site por meio de VPN ou rota expressa é necessária para cenários de produção. Esse tipo de conexão também é necessário para cenários de não produção que alimentam em cenários de produção em que o software SAP está sendo usado. A imagem a seguir mostra um exemplo de conectividade entre sites:

Cross-site connectivity

Escolha os tipos de VM do Azure

A SAP lista quais tipos de VM do Azure você pode usar para cenários de produção. Para cenários de não produção, você pode escolher uma variedade maior de VMs nativas do Azure.

Observação

Para cenários de não produção, use os tipos de VM que são listados na nota da SAP nº 1928533. Para o uso de VMs do Azure para cenários de produção, verifique as VMs certificadas para SAP HANA na lista de plataformas de IaaS certificadas.

Implante as VMs no Azure usando:

  • O portal do Azure.
  • Cmdlets do Azure PowerShell.
  • A CLI do Azure.

Você também pode implantar uma plataforma completa de SAP HANA instalada nos serviços de VM do Azure por meio da plataforma SAP Cloud. O processo de instalação é descrito em Implantar SAP 4HANA/S ou BW/4HANA no Azure.

Importante

Para usar as VMs M208xx_v2, você precisa ter cuidado ao selecionar a imagem do Linux. Para obter mais informações, consulte Tamanhos de máquinas virtuais otimizados para memória.

Configuração de armazenamento para SAP HANA

Para obter as configurações de armazenamento e os tipos de armazenamento a serem usados com SAP HANA no Azure, leia o documento Configurações de armazenamento de máquina virtual do SAP HANA no Azure.

Configurar redes virtuais do Azure

Quando você tiver conectividade site a site no Azure por meio de VPN ou ExpressRoute, você deve ter pelo menos uma rede virtual do Azure que está conectada por meio de um Gateway Virtual ao circuito de ExpressRoute ou VPN. Em implantações simples, o Gateway Virtual pode ser implantado em uma sub-rede de rede virtual do Azure (VNet) que hospeda as instâncias do SAP HANA também. Para instalar o SAP HANA, você cria duas sub-redes adicionais dentro da rede virtual do Azure. Uma sub-rede hospeda as VMs para executar as instâncias do SAP HANA. A outra sub-rede executa o Jumpbox ou as VMs de gerenciamento para hospedar o SAP HANA Studio, outros softwares de gerenciamento ou o software do aplicativo.

Importante

Fora de funcionalidade, mas mais importante por motivos de desempenho, não há suporte para configurar Dispositivos virtuais de rede do Azure no caminho de comunicação entre o aplicativo SAP e a camada DBMS de um SAP NetWeaver, Hybris ou S / 4HANA baseado no sistema SAP. É necessário a comunicação entre a camada de aplicativo SAP e a camada DBMS seja direta. A restrição não inclui Regras de NSG e ASG do Azure, desde que as regras de NSG e ASG permitam uma comunicação direta. Outros cenários em que não há suporte para NVAs estão em caminhos de comunicação entre VMs do Azure que representam nós de cluster do Linux Pacemaker e dispositivos SBD, conforme descrito em Alta disponibilidade do SAP NetWeaver em VMs do Azure no SUSE Linux Enterprise Server para aplicativos SAP. Ou em caminhos de comunicação entre as VMs do Azure e o SOFS do Windows Server, conforme descrito em Cluster de uma instância do SAP ASCS/SCS em um cluster de failover do Windows usando um compartilhamento de arquivos no Azure. Os NVAs em caminhos de comunicação podem facilmente duplicar a latência de rede entre dois parceiros de comunicação, podendo restringir o rendimento em caminhos críticos entre a camada de aplicação SAP e a camada DBMS. Em alguns cenários observados com os clientes, os NVAs podem causar falhas nos clusters do Pacemaker Linux nos casos em que as comunicações entre os nós do cluster do Linux Pacemaker precisam se comunicar com o dispositivo SBD por meio de um NVA.

Importante

Outro design que NÃO tem suporte é a segregação da camada de aplicativo SAP e da camada DBMS em diferentes redes virtuais do Azure que não estejam emparelhadas entre si. É recomendável separar a camada de aplicativo SAP e a camada DBMS usando sub-redes em uma rede virtual do Azure, em vez de usar redes virtuais diferentes do Azure. Se você decidir não seguir a recomendação e, em vez disso, segregar as duas camadas em uma rede virtual diferente, as duas redes virtuais deverão ser emparelhadas. Esteja ciente de que o tráfego entre duas redes virtuais emparelhadas do Azure está sujeito a custos de transferência. Com o enorme volume de dados em muitos Terabytes trocados entre a camada de aplicativo SAP e a camada DBMS, custos substanciais poderão ser acumulados se a camada de aplicativo SAP e a camada DBMS forem segregadas entre duas redes virtuais do Azure.

Se você implantou Jumpbox ou VMs de gerenciamento em uma sub-rede separada, poderá definir várias vNICs (placas de interface de rede virtual) para a VM HANA, com cada vNIC atribuída a uma sub-rede diferente. Com a capacidade de ter vários vNICs, você pode configurar a separação de tráfego de rede, se necessário. Por exemplo, o tráfego do cliente pode ser roteado através da vNIC principal e o tráfego de administrador é roteado através de uma segunda vNIC.
Você também atribui endereços IP privados estáticos que são implantados para ambas as NICs virtuais.

Observação

Você deve atribuir endereços IP estáticos por meio do Azure para vNICs individuais. Você não deve atribuir endereços IP estáticos dentro do SO convidado para um vNIC. Alguns serviços do Azure, como o serviço de Backup do Azure, dependem do fato de que pelo menos o vNIC primário esteja definido como DHCP, e não para endereços IP estáticos. Veja também o documento Solucionar problemas de backup da máquina virtual do Azure. Se você precisar atribuir vários endereços IP estáticos a uma VM, precisará atribuir vários vNICs a uma VM.

No entanto, para implantações que são permanentes, você precisará criar uma arquitetura de rede do datacenter virtual no Azure. Essa arquitetura recomenda a separação de Gateway de VNet do Azure que se conecta localmente em uma VNet separada do Azure. Essa VNet separada deve hospedar todo o tráfego que sai para o local ou na Internet. Essa abordagem permite que você implantar o software para auditoria e registro em log o tráfego que entra o datacenter virtual no Azure neste hub separado de rede virtual. Portanto, você tem uma VNet que hospeda todo o software e as configurações relacionadas ao tráfego de entrada e saída para sua implantação do Azure.

Os artigos do Virtual Datacenter do Azure: uma perspectiva de rede e o Virtual Datacenter do Azure e o Enterprise Control Plane fornecem mais informações sobre a abordagem do datacenter virtual e o design relacionado do VNet do Azure.

Observação

O tráfego que flui entre uma VNet do hub e spoke VNet usando emparelhamento de rede virtual do Azure é o assunto adicionais custos. Com base nesses custos, você talvez precise considerar o risco de comprometimento entre executar um projeto de rede de hub e spoke estrito e executar várias Gateways de ExpressRoute do Azure que você se conectar a 'spokes' para ignorar o emparelhamento de rede virtual. No entanto, os Gateways de ExpressRoute do Azure introduz adicionais custos também. Você também pode encontrar custos adicionais para softwares de terceiros usados para registro, auditoria e monitoramento de tráfego de rede. Dependendo dos custos para troca de dados por meio do emparelhamento de rede virtual no um lado e os custos criados por licenças de software adicionais e Gateways de ExpressRoute do Azure adicionais, você pode decidir para microssegmentação dentro de uma rede virtual usando sub-redes como unidade de isolamento em vez de redes virtuais.

Para obter uma visão geral dos diferentes métodos para atribuir endereços IP, consulte Tipos de endereços IP e métodos de alocação no Azure.

Para VMs em execução no SAP HANA, é necessário trabalhar com endereços IP estáticos atribuídos. A razão é que alguns atributos de configuração para o HANA referenciam endereços IP.

Os Grupos de segurança de rede (NSGs) do Azure são usados para direcionar tráfego roteado para a instância do SAP HANA ou para a caixa de depósito. Os NSGs e, por fim, os grupos de segurança de aplicativos estão associados à sub-rede SAP HANA e à sub-rede de gerenciamento.

Para implantar o SAP HANA no Azure sem uma conexão site a site, você ainda deseja proteger a instância do SAP HANA da internet pública e ocultá-lo por trás de um proxy de encaminhamento. Neste cenário básico, a implantação se baseia em serviços DNS internos do Azure para resolver nomes de host. Em uma implantação mais complexa, em que endereços IP públicos são usados, os serviços DNS internos do Azure são especialmente importantes. Use os NSGs do Azure e NVAs Azure para controlar, monitorar o roteamento da internet em sua arquitetura de rede virtual do Azure no Azure. A imagem a seguir mostra um esquema aproximado para implantar o SAP HANA sem uma conexão site a site em uma arquitetura VNet hub e spoke:

Rough deployment schema for SAP HANA without a site-to-site connection

Outra descrição sobre como usar os NVAs do Azure para controlar e monitorar o acesso da Internet sem a arquitetura VNet hub e spoke pode ser encontrada no artigo Implantar dispositivos virtuais de rede altamente disponíveis.

Configurando a infraestrutura do Azure para escalonamento do SAP HANA

Para descobrir os tipos de VM do Azure que são certificados para expansão de OLAP ou de S/4HANA, verifique o Diretório de hardware do SAP HANA. Uma marca de verificação na coluna “Cluster” indica suporte à expansão. O tipo de aplicativo indica se há suporte para expansão de OLAP ou de S/4HANA. Para obter detalhes sobre nós certificados em expansão, examine a entrada de uma SKU de VM específica listada no diretório de hardware do SAP HANA.

Para obter as versões mínimas do sistema operacional para implantar configurações de expansão em VMs do Azure, verifique os detalhes das entradas na SKU de VM específica listada no diretório de hardware do SAP HANA. A partir de uma configuração de expansão OLAP de n nós, um nó funciona como nó principal. Os outros nós até o limite da certificação atuam como nó de trabalho. Mais nós em espera não contam para o número de nós certificados

Observação

As implantações de expansão de VM do Azure em SAP HANA com o nó em espera somente são possíveis usando o armazenamento do Azure NetApp Files. Nenhum outro armazenamento certificado do SAP HANA no Azure permite a configuração de nós em espera do SAP HANA.

Para /hana/shared, recomendamos o uso do Azure NetApp Files ou do Azure Files.

Um design básico típico para um único nó em uma configuração de expansão, com implantado nos Arquivos NetApp do Azure, se parece com /hana/shared :

Diagram that shows a typical basic design for a single node in a scale-out configuration.

A configuração básica de um nó de VM para scale-out do SAP HANA é semelhante a:

  • Para /hana/shared, use o serviço NFS nativo fornecido por meio dos Arquivos do Azure NetApp ou dos Arquivos do Azure.
  • Todos os outros volumes de disco não são compartilhados entre os diferentes nós e não são baseados em NFS. As configurações de instalação e as etapas para instalações HANA de expansão com /hana/data e /hana/log não compartilhados são fornecidas mais abaixo neste documento. Para o armazenamento certificado do HANA que pode ser usado, confira o artigo Configurações de armazenamento de máquina virtual SAP HANA no Azure.

Ao dimensionar os volumes ou discos, você precisa verificar o documento Requisitos de armazenamento de TDI do SAP HANA quanto ao tamanho necessário, dependendo do número de nós de trabalho. O documento libera uma fórmula que você precisa aplicar para obter a capacidade necessária do volume.

O outro design importante que é exibido nos gráficos da configuração de nó único para uma VM SAP HANA de expansão é a VNet, ou melhor, a configuração de sub-rede. A SAP recomenda uma separação do tráfego de cliente / aplicativo das comunicações entre os nós do HANA. Como mostrado nos gráficos, essa meta é obtida com dois vNICs diferentes conectados à VM. Ambos os vNICs estão em sub-redes diferentes, possuem dois endereços IP diferentes. Você controla o fluxo de tráfego com regras de roteamento usando NSGs ou rotas definidas pelo usuário.

Particularmente no Azure, não há meios e métodos para impor a qualidade do serviço e cotas em vNICs específicos. Como resultado, a separação entre o cliente/aplicativo e a comunicação entre nós não abre nenhuma oportunidade de priorizar um fluxo de tráfego sobre o outro. Em vez disso, a separação continua a ser uma medida de segurança na proteção das comunicações intra-nó das configurações de scale-out.

Observação

A SAP recomenda a separação do tráfego de rede para o lado do cliente/aplicativo e o tráfego entre nós, conforme descrito neste documento. Portanto, é recomendável colocar uma arquitetura no lugar, como mostrado nos últimos gráficos. Consulte também sua equipe de segurança e conformidade para obter os requisitos que se desviam da recomendação.

Do ponto de vista da rede, a arquitetura de rede mínima necessária seria semelhante a:

Scale-out basics of a single node

Instalando a expansão do SAP HANA n Azure

Instalando uma configuração SAP scale-out, você precisa executar etapas aproximadas de:

  • Implementar novas infraestruturas de VNet do Azure ou adaptar uma infraestrutura existente
  • Implementar novas VMs usando o Armazenamento Premium gerenciado do Azure, volumes de disco Ultra e/ou volumes de NFS com base em ANF
    • Adapte o roteamento de rede para garantir que, por exemplo, a comunicação entre nós entre as VMs não seja roteada por meio de um NVA.
  • Instale o nó principal do SAP HANA.
  • Adaptar parâmetros de configuração do nó principal do SAP HANA
  • Continue com a instalação dos nós de trabalho do SAP HANA

Instalação do SAP HANA na configuração de scale-out

À medida que sua infraestrutura de VM do Azure é implantada e todas as outras preparações são feitas, é necessário instalar as configurações de escalabilidade de saída do SAP HANA nas seguintes etapas:

  • Instale o nó principal do SAP HANA de acordo com a documentação da SAP
  • Ao usar o Armazenamento Premium do Azure ou o armazenamento de disco Ultra com discos não compartilhados de /hana/data e /hana/log, adicione o parâmetro basepath_shared = no ao arquivo global.ini. Esse parâmetro permitirá que o SAP HANA seja executado de modo de expansão sem os volumes compartilhados /hana/data e /hana/log entre os nós. Detalhes são documentados em Nota SAP # 2080991. Se você estiver usando volumes de NFS com base em ANF para /hana/data e /hana/log, não será necessário fazer essa alteração
  • Após a alteração eventual no parâmetro global.ini, reinicie a instância de SAP HANA.
  • Adicionar mais nós de trabalho. Para obter mais informações, consulte Adicionar hosts usando a Interface de Linha de Comando. Especifique a rede interna para a comunicação entre nós durante a instalação do SAP HANA ou posteriormente, usando, por exemplo, o hdblcm local. Para obter mais documentação, consulte a Nota SAP #2183363.

Para configurar um sistema de expansão do SAP HANA com um nó em espera, consulte as Instruções de implantação do SUSE Linux ou as Instruções de implantação do Red Hat.

SAP HANA Dynamic Tiering 2.0 para as máquinas virtuais do Azure

Além das certificações de SAP HANA em VMs da série M do Azure, o SAP HANA Dynamic Tiering 2.0 também tem suporte no Microsoft Azure. Para obter mais informações, consulte a Documentação de Links para DT 2.0. Não há diferença na instalação ou operação do produto. Por exemplo, você pode instalar o Cockpit do SAP HANA dentro de uma VM do Azure. No entanto, há alguns requisitos obrigatórios, conforme descrito na seção a seguir, para suporte oficial no Azure. Em todo o artigo, a abreviação de "DT 2.0" será usada em vez do nome completo Dynamic Tiering 2.0.

SAP HANA Dynamic Tiering 2.0 não tem suporte pelo SAP BW ou S4HANA. Casos de uso principal agora são aplicativos nativos do HANA.

Visão geral

A figura abaixo fornece uma visão geral sobre o suporte de DT 2.0 no Microsoft Azure. Há um conjunto de requisitos obrigatórios que devem ser seguidos para cumprir a certificação oficial:

  • DT 2.0 deve ser instalado em uma VM do Azure dedicada. Pode não ser executada na mesma VM em que o SAP HANA é executado
  • O SAP HANA e DT 2.0 VMs devem ser implantados na mesma rede virtual do Azure
  • O SAP HANA e DT 2.0 VMs devem ser implantados com a rede acelerada do Azure habilitada
  • Tipo de armazenamento para VMs DT 2.0 deve ser o Armazenamento Premium
  • Vários discos do Azure devem ser anexados à VM DT 2.0
  • É necessário criar um volume distribuído/raid de software (via lvm ou mdadm) usando a distribuição nos discos do Azure

Mais detalhes serão explicados nas seções a seguir.

SAP HANA DT 2.0 Architecture Overview

VM do Azure dedicada para SAP HANA DT 2.0

No Azure IaaS, DT 2.0 tem suporte apenas em uma VM dedicada. Não é permitido executar DT 2.0 na mesma VM do Azure onde a instância do HANA está em execução. Inicialmente, dois tipos de VMs podem ser usados para executar o SAP HANA DT 2.0:

  • M64-32ms
  • E32sv3

Para obter mais informações sobre a descrição do tipo de VM, consulte Tamanhos de VM do Azure – Memória

Dada a ideia básica do 2.0 DT, que aborda o descarregamento de dados "passivos" para economizar custos, faz sentido usar tamanhos de VM correspondentes. Embora não haja nenhuma regra rígida sobre as combinações possíveis. Isso depende da carga de trabalho de cliente específico.

As configurações recomendadas seriam:

Tipo de VM do SAP HANA Tipo de VM do DT 2.0
M128ms M64-32ms
M128s M64-32ms
M64ms E32sv3
M64s E32sv3

Todas as combinações de VMs da série M certificadas para SAP HANA com VMs de 2.0 com suporte DT (M64-32ms e E32sv3) são possíveis.

Rede do Azure e SAP HANA DT 2.0

Instalar DT 2.0 em uma VM dedicada requer a taxa de transferência de rede entre a VM de 2.0 DT e VM do SAP HANA de 10 Gb no mínimo. Portanto, é obrigatório colocar todas as VMs na mesma rede virtual do Azure e habilitar a rede acelerada do Azure.

Confira informações adicionais sobre a rede acelerada do Azure em Criar uma VM do Azure com Rede Acelerada usando o CLI do Azure

Armazenamento VM para SAP HANA DT 2.0

Acordo com diretrizes de práticas recomendadas de DT 2.0, a taxa de transferência de e/s de disco deve ser mínimo 50 MB/s por núcleo físico.

De acordo com as especificações para os dois tipos de VM do Azure, que têm suporte para 2.0 DT, o limite de taxa de transferência de E/S para a VM de disco máximo será:

  • E32sv3: 768 MB/s (sem cache), o que significa uma razão de 48 MB/s por núcleo físico
  • M64-32ms: 1000 MB/s (sem cache), o que significa uma taxa de 62,5 MB/s por núcleo físico

É necessário anexar vários discos do Azure para a VM de 2.0 DT e criar um raid de software (distribuição) no nível do sistema operacional para atingir o limite máximo de taxa de transferência de disco por VM. Um único disco do Azure não pode fornecer a taxa de transferência para alcançar o limite máximo de VM em relação a isso. Armazenamento Premium do Azure é obrigatório para executar o DT 2.0.

Dependendo dos requisitos de tamanho, há opções diferentes para alcançar a taxa de transferência máxima de uma VM. Aqui estão as configurações de disco de volume de dados possíveis para cada tipo de VM de 2.0 DT atingir o limite de taxa de transferência da VM. A VM E32sv3 deve ser considerada como um nível de entrada para cargas de trabalho menores. Caso isso resulte em não ser rápido o suficiente, pode ser necessário redimensionar a VM para M64-32ms. Assim como a VM M64 32ms tem a quantidade de memória, a carga de e/s pode não alcançar o limite, especialmente para cargas de trabalho com uso intensivo de leitura. Portanto, menos discos no conjunto de distribuição podem ser suficientes, dependendo da carga de trabalho específica do cliente. Mas, por segurança, as configurações de disco abaixo foram escolhidas para garantir a máxima taxa de transferência:

SKU da VM Configuração de disco 1 Configuração de disco 2 Configuração de disco 3 Configuração de disco 4 Configuração de disco 5
M64-32ms 4 x P50 –> 16 TB 4 x P40 –> 8 TB 5 x P30 –> 5 TB 7 x P20 –> 3,5 TB 8 x P15 –> 2 TB
E32sv3 3 x P50 –> 12 TB 3 x P40 –> 6 TB 4 x P30 –> 4 TB 5 x P20 –> 2,5 TB 6 x P15 –> 1,5 TB

Especialmente no caso da carga de trabalho intensas de leitura ele poderia melhorar o desempenho de e/s para ativar o cache de host do Azure "somente leitura" conforme recomendado para os volumes de dados do software de banco de dados. Enquanto a transação de log de cache de disco do host do Azure deve ser "nenhum".

Sobre o tamanho do volume de log de um ponto de partida recomendado está uma heurística de 15% do tamanho dos dados. A criação do volume de log pode ser feita usando tipos de disco diferentes do Azure, dependendo dos requisitos de custo e da taxa de transferência. Para o volume do log, é necessária uma alta taxa de transferência de E/S.

Quando o tipo de VM M64-32ms for usado, é obrigatório habilitar o Acelerador de Gravação. O Acelerador de Gravação do Azure fornece latência de gravação de disco ideal para o log de transações (disponível apenas para a série M). Há alguns itens a considerar, embora, como o número máximo de discos por tipo de VM. Detalhes sobre o Acelerador de Gravação podem ser encontrados na página do Acelerador de Gravação do Azure

A seguir, são apresentados alguns exemplos sobre dimensionamento de volume do log:

tipo de disco e tamanho do volume de dados configuração 1 de tipo de disco e volume de log configuração 2 de tipo de disco e volume de log
4 x P50 –> 16 TB 5 x P20 –> 2,5 TB 3 x P30 –> 3 TB
6 x P15 –> 1,5 TB 4 x P6 –> 256 GB 1 x P15 –> 256 GB

Como para escalabilidade horizontal de SAP HANA, o diretório /hana/shared deve ser compartilhado entre a VM do SAP HANA e VM DT 2.0. A mesma arquitetura quanto ao uso de expansão do SAP HANA dedicado VMs que atuam como um servidor NFS altamente disponível é recomendado. Para fornecer um volume compartilhado de backup, o design idêntico pode ser usado. Mas, cabe ao cliente se HA será necessária ou se é suficiente usar apenas uma VM dedicada com capacidade de armazenamento suficiente para atuar como um servidor de backup.

Operações de implantação do SAP HANA em VMs do Azure

As seções a seguir descrevem algumas das operações relacionadas à implantação de sistemas SAP HANA em VMs do Azure.

Operações de backup e restauração em VMs do Azure

Os documentos a seguir descrevem como fazer backup e restaurar a sua implantação do SAP HANA:

Inicie e reinicie as VMs que contêm o SAP HANA

Uma característica importante da nuvem pública do Azure é que você será cobrado somente pelos seus minutos de computação. Por exemplo, quando você desligar uma VM que executa o SAP HANA, você será cobrado somente pelos custos de armazenamento durante aquele período. Outro recurso fica disponível quando você especificar endereços IP estáticos para as VMs na sua implantação inicial. Quando você reiniciar uma VM que contém o SAP HANA, a VM é reiniciada com seus endereços IP anteriores.

Use o SAProuter para suporte remoto SAP

Se você tem uma conexão site a site entre suas localizações locais e o Azure, e estiver executando componentes SAP, você provavelmente já está executando o SAProuter. Nesse caso, complete os seguintes itens para suporte remoto:

  • Manter o endereço IP estático e privado da VM que hospeda o SAP HANA na configuração do SAProuter.
  • Configure o NSG da sub-rede que hospeda a VM do HANA para permitir o tráfego pela porta TCP/IP 3299.

Se estiver conectando ao Azure através da Internet e não tiver um roteador SAP para a VM com SAP HANA, será necessário instalar o componente. Instale o SAProuter em uma VM separada na sub-rede de gerenciamento. A imagem a seguir mostra um esquema aproximado para a implantação do SAP HANA sem uma conexão site a site:

Rough deployment schema for SAP HANA without a site-to-site connection and SAProuter

Certifique-se de instalar o SAProuter em uma VM separada e não em sua VM Jumpbox. A VM separada precisa de um endereço IP estático. Para conectar o SAProuter ao SAProuter que é hospedado pela SAP, entre em contato com o SAP para um endereço IP. (O SAProuter que é hospedado pela SAP é a contraparte da instância do SAProuter que você instala em sua VM.) Use o endereço IP da SAP para configurar sua instância do SAProuter. Nas definições de configuração, a única porta necessária é a porta TCP 3299.

Para saber mais sobre como configurar e manter conexões de suporte remoto por meio do SAPRouter, confira a documentação do SAP.

Alta disponibilidade com o SAP HANA em VMs nativas do Azure

Se você estiver executando o SUSE Linux Enterprise Server ou o Red Hat, será possível estabelecer um cluster do Pacemaker com dispositivos de isolamento. Você pode usar os dispositivos para definir a configuração do SAP HANA que usa replicação síncrona com a Replicação de sistema do HANA e failover automático. Mais informações estão listadas na seção “próximas etapas”.

Próximas etapas

Conheça os artigos listados