Você está na página 1de 1118

Contents

Descrição geral
Introdução
Certificações
SAP HANA no Azure (Instâncias Grandes)
Descrição geral
O que é SAP HANA nas Instâncias Grandes do Azure?
Conhecer os termos
Certificação
SKUs Disponíveis para HLI
Dimensionamento
Requisitos de integração
Nós de extensão e colocação de dados em camadas do SAP HANA
Modelo e responsabilidades de operações
Sistemas Operativos Compatíveis
Arquitetura
Arquitetura geral
Arquitetura de rede
Arquitetura de armazenamento
Cenários HLI suportados
Infraestrutura e conectividade
Implementação de HLI
Ligar VMs do Azure para Instâncias Grandes do HANA
Ligar uma VNet para ExpressRoute de Instância Grande do HANA
Requisitos de rede adicionais
Instalar o SAP HANA
Validar a configuração
Instalação do HANA de exemplo
Elevada disponibilidade e recuperação após desastre
Opções e considerações
Cópia de segurança e restauro
Princípios e preparação
Procedimento de ativação pós-falha de recuperação após desastre
Resolver problemas e monitorizar
Monitorização HLI
Monitorizar e resolver problemas do lado do HANA
Procedimento
Controlo de Grandes Instâncias do Azure HANA através do portal do Azure
Configuração HA com STONITH
Cópia de segurança de SO para SKUs de Tipo II
Ativar o Kdump para o HANA nas Instâncias Grandes
Atualização do SO para Instâncias Grandes do HANA
Configurar o servidor SMT para SUSE Linux
Migração do HLI para a VM do Azure
SAP HANA nas Máquinas Virtuais do Azure
Instalação de SAP HANA em VMs do Azure
Guia de implementação de S/4 HANA ou de BW/4 HANA SAP CAL
Configurações e operações de infraestrutura do SAP HANA no Azure
Configurações de armazenamento da máquina virtual do Azure do SAP HANA
Disponibilidade do SAP HANA nas Máquinas Virtuais do Azure
SAP HANA na descrição geral da Disponibilidade do Azure
SAP HANA na descrição geral da Disponibilidade do Azure numa região do Azure
SAP HANA na descrição geral da Disponibilidade do Azure pelas regiões do Azure
Configurar a Replicação do Sistema SAP HANA no SLES
Configurar a Replicação do Sistema SAP HANA no RHEL
Resolver problemas de dimensionamento do SAP HANA e do Pacemaker no SLES
Escalamento horizontal do SAP HANA com o nó em modo de espera com o Azure
NetApp Files no SLES
Escalamento horizontal do SAP HANA com o nó em modo de espera com o Azure
NetApp Files no RHEL
Descrição geral da cópia de segurança do SAP HANA
Cópia de segurança ao nível do ficheiro do SAP HANA
SAP NetWeaver e Business One em Máquinas Virtuais do Azure
Lista de verificação de planeamento e implementação de carga de trabalho do SAP
Planear e implementar o SAP NetWeaver no Azure
Carga de trabalho SAP em cenários de máquinas virtuais do Azure suportados
Qual o software SAP suportado para implementações do Azure
Guia de implementação do SAP NetWeaver
Guias de implementação do DBMS para a carga de trabalho SAP
Implementação geral do DBMS para Máquinas Virtuais do Azure para a carga de
trabalho SAP
Implementação em SQL Server do DBMS para Máquinas Virtuais do Azure para a
carga de trabalho SAP
Implementação em Oracle do DBMS para Máquinas Virtuais do Azure para a carga
de trabalho SAP
Implementação em IBM DB2 do DBMS para Máquinas Virtuais do Azure para a
carga de trabalho SAP
Elevada disponibilidade do IBM DB2 LUW nas VMs do Azure no SUSE Linux
Enterprise Server
Elevada disponibilidade do IBM DB2 LUW nas VMs do Azure no Red Hat Enterprise
Linux Server
Implementação em SAP ASE do DBMS para Máquinas Virtuais do Azure para a
carga de trabalho SAP
Implementação do SAP MaxDB, liveCache e Servidor de Conteúdos no Azure
Disponibilidade do SAP HANA nas Máquinas Virtuais do Azure
SAP HANA na descrição geral da Disponibilidade do Azure
SAP HANA na descrição geral da Disponibilidade do Azure numa região do Azure
SAP HANA na descrição geral da Disponibilidade do Azure pelas regiões do Azure
SAP Business One em Máquinas Virtuais do Azure
Guia de implementação de SAP IDES em SAP CAL no Windows/SQL Server
Conector de SAP LaMa para o Azure
Elevada Disponibilidade (HA) no Windows e Linux
Descrição geral
Arquitetura de Elevada Disponibilidade
Arquitetura e Cenários de HA
Arquitetura e Cenários de Elevada Disponibilidade
Configurações de carga de trabalho de SAP com Zonas de Disponibilidade do
Azure
HA no Windows com Disco Partilhado para a Instância (A)SCS
HA no Windows com Partilha de Ficheiros SOFS para a Instância (A)SCS
HA para SAP NetWeaver no Windows com o Azure NetApp Files (SMB)
HA no SUSE Linux para a Instância (A)SCS
HA no SUSE Linux para a Instância (A)SCS com o Azure NetApp Files
HA no Red Hat Enterprise Linux para Instância de (A)SCS
HA no Red Hat Enterprise Linux para Instância de (A)SCS com Azure NetApp Files
Preparação da Infraestrutura do Azure
Windows com Disco Partilhado para a Instância (A)SCS
Windows com Partilha de Ficheiros SOFS para a Instância (A)SCS
Disponibilidade elevada para NFS nas VMs do Azure no SLES
GlusterFS nas VMs do Azure no Red Hat Enterprise Linux para o SAP NetWeaver
Pacemaker no SLES
Pacemaker no RHEL
Conectividade de ponto final público para VMs com o Balanceador de Carga
Standard do Azure em cenários de elevada disponibilidade SAP
Instalação de SAP
Windows com Disco Partilhado para a Instância (A)SCS
Windows com Partilha de Ficheiros SOFS para a Instância (A)SCS
HA para SAP NetWeaver no Windows com o Azure NetApp Files (SMB)
SUSE Linux com NFS para a Instância (A)SCS
SUSE Linux com NFS para a Instância (A)SCS com o Azure NetApp Files
Alta disponibilidade para o SAP NetWeaver em Red Hat Enterprise Linux
Red Hat Enterprise Linux com NFS para Instância de (A)SCS com Azure NetApp
Files
Múltiplos SID SAP
Windows com Disco Partilhado para a Instância (A)SCS
Windows com Partilha de Ficheiros SOFS para a Instância (A)SCS
SLES com múltiplos SIDs Pacemaker para a Instância (A)SCS
RHEL com múltiplos SIDs Pacemaker para a Instância (A)SCS
Azure Site Recovery para Recuperação após Desastre do SAP
Azure Proximity Placement Groups para latência de rede otimizada com aplicações
SAP
Integração de Identidade do AAD SAP e Início de Sessão único
Integração com o SAP Cloud
Integração do AAD com a Autenticação de Identidade da Plataforma Cloud do SAP
Configurar o Início de Sessão Único com a Plataforma Cloud do SAP
Integração do AAD com o SAP NetWeaver
Integração do AAD com o SAP Business ByDesign
Integração do AAD com o SAP HANA DBMS
Início de Sessão Único SAML do SAP Fiori Launchpad com o Azure AD
Integração de Serviços do Azure ao SAP
Utilizar o SAP HANA no Power BI Desktop
DirectQuery e SAP HANA
Utilizar o conector SAP BW no Power BI Desktop
O Azure Data Factory oferece integração de dados do SAP HANA e Business
Warehouse
Referência
CLI do Azure
Recursos
Mapa do Azure
Use o Azure para hospedar e executar cenários de
carga de trabalho SAP
21/06/2020 • 32 minutes to read • Edit Online

Quando utilizar o Microsoft Azure, pode executar de forma fiável as suas cargas de trabalho e cenários DE SAP
críticos de missão numa plataforma escalável, compatível e comprovada pela empresa. Obtém-se a escalabilidade,
flexibilidade e economia de custos do Azure. Com a parceria expandida entre a Microsoft e a SAP, pode executar
aplicações SAP em todos os cenários de desenvolvimento e teste e produção em Azure e ser totalmente suportado.
De SAP NetWeaver a SAP S/4HANA, SAP BI em Linux a Windows, e SAP HANA a SQL, temos-te coberto.
Além de hospedar cenários SAP NetWeaver com os diferentes DBMS em Azure, pode hospedar outros cenários de
carga de trabalho SAP, como o SAP BI em Azure.
A singularidade de Azure para SAP HANA é uma oferta que distingue Azure. Para permitir hospedar mais memória
e cenários SAP exigentes com recursos da CPU que envolvem SAP HANA, a Azure oferece o uso de hardware de
metal desnudido dedicado ao cliente. Utilize esta solução para executar as implementações SAP HANA que
requerem até 24 TB (escala de 120 TB) de memória para S/4HANA ou outra carga de trabalho SAP HANA.
Hospedar cenários de carga de trabalho SAP em Azure também pode criar requisitos de integração de identidade e
um único sign-on. Esta situação pode ocorrer quando utiliza o Azure Ative Directory (Azure AD) para ligar
diferentes componentes SAP e ofertas de software SAP-as-a-service (SaaS) ou plataforma-as-a-service (PaaS).
Uma lista de tais cenários de integração e de um único sign-on com entidades Azure AD e SAP é descrita e
documentada na secção "Integração de identidade AAD SAP e único sign-on".

Alterações na secção de carga de trabalho SAP


As alterações aos documentos na secção de carga de trabalho sapaure são listadas no final deste artigo. As
entradas no registo de alteração são mantidas durante cerca de 180 dias.

Quer saber
Se tiver questões específicas, vamos indicar-lhe documentos ou fluxos específicos nesta secção da página inicial.
Quer saber:
O que a Azure VMs e unidades HANA Large Instance são suportados para os quais o software SAP lança e quais
as versões do sistema operativo. Leia o documento O software SAP é suportado para implementação de Azure
para obter respostas e o processo para encontrar a informação
Quais os cenários de implantação da SAP são suportados com VMs Azure e HANA Large Instances. Informações
sobre os cenários apoiados podem ser encontradas nos documentos:
Carga de trabalho SAP em cenários de máquinas virtuais do Azure suportados
Cenários apoiados para HANA Large Instance
O que os Serviços Azure, os tipos de VM Azure e os serviços de armazenamento Azure estão disponíveis nas
diferentes regiões do Azure, consulte o site Produtos disponíveis por região
Os quadros HA de terceiros são suportados, além do Windows e do Pacemaker? Verifique a parte inferior da
nota de suporte da SAP #1928533

SAP HANA no Azure (Instâncias Grandes)


Uma série de documentos leva-o através da SAP HANA on Azure (Grandes Instâncias), ou, para abreviar, HANA
Large Instances. Para obter informações sobre HANA Large Instances, comece com o documento Visão Geral e
arquitetura da SAP HANA em Azure (Grandes Instâncias) e passe pela documentação relacionada na secção HANA
Large Instance

SAP HANA em máquinas virtuais Azure


Esta secção da documentação abrange diferentes aspetos da SAP HANA. Como pré-requisito, deve estar
familiarizado com os principais serviços da Azure que prestam serviços elementares da Azure IaaS. Então, você
precisa de conhecimento de Azure compute, armazenamento e networking. Muitos destes assuntos são tratados
no guia de planeamento Azurerelacionado com a NETWeaver.
Para obter informações sobre a HANA sobre Azure, consulte os seguintes artigos e seus subartículos:
Configurações e operações de infraestrutura do SAP HANA no Azure
SAP HANA alta disponibilidade para máquinas virtuais Azure
Alta disponibilidade de SAP HANA em máquinas virtuais Azure
Guia de backup para SAP HANA em máquinas virtuais Azure

SAP NetWeaver implantado em máquinas virtuais Azure


Esta secção lista documentação de planeamento e implantação para SAP NetWeaver e Business One on Azure. A
documentação centra-se no básico e na utilização de bases de dados não-HANA com uma carga de trabalho SAP
em Azure. Os documentos e artigos para uma elevada disponibilidade são também a base para a alta
disponibilidade de HANA em Azure, tais como:
Guia de planeamento Azure.
SAP Business One em máquinas virtuais Azure
Proteja uma implementação de aplicação SAP NetWeaver multitier utilizando a Recuperação do Site
Conector de SAP LaMa para o Azure
Para obter informações sobre bases de dados não-HANA sob uma carga de trabalho SAP em Azure, consulte:
Considerações para a implantação de DBMS de máquinas virtuais Azure para a carga de trabalho SAP
Sql Server Azure Virtual Machines DBMS implantação para SAP NetWeaver
Implementação em Oracle do DBMS para Máquinas Virtuais do Azure para a carga de trabalho SAP
Ibm DB2 Azure Virtual Machines DBMS implantação para carga de trabalho SAP
Implementação em SAP ASE do DBMS para Máquinas Virtuais do Azure para a carga de trabalho SAP
Implantação de SAP MaxDB, Live Cache e Servidor de Conteúdo em VMs Azure
Para obter informações sobre as bases de dados SAP HANA em Azure, consulte a secção "SAP HANA em máquinas
virtuais Azure".
Para obter informações sobre a elevada disponibilidade de uma carga de trabalho SAP em Azure, consulte:
Azure Virtual Machines alta disponibilidade para SAP NetWeaver
Este documento aponta para vários outros documentos de arquitetura e cenário. Em documentos de cenário
posteriores, são fornecidas ligações a documentos técnicos detalhados que explicam a implantação e configuração
dos diferentes métodos de alta disponibilidade. Os diferentes documentos que mostram como estabelecer e
configurar alta disponibilidade para uma cobertura de carga de trabalho SAP NetWeaver abrangem os sistemas
operativos Linux e Windows.
Para obter informações sobre a integração entre os serviços Azure Ative (Azure AD) e SAP e um único sign-on,
consulte:
Tutorial: Integração do Azure Ative Directory com a NUVEM SAP para o Cliente
Tutorial: Integração do Diretório Ativo Azure com autenticação de identidade da plataforma de nuvem SAP
Tutorial: Integração do Azure Ative Directory com a Plataforma NUVEM SAP
Tutorial: Integração do Azure Active Directory com SAP NetWeaver
Tutorial: Integração do Azure Active Directory com SAP Business ByDesign
Tutorial: Integração do Diretório Ativo Azure com SAP HANA
O seu ambiente S/4HANA: Fiori Launchpad SAML single sign-on com Azure AD
Para obter informações sobre a integração dos serviços Azure em componentes SAP, consulte:
Utilizar o SAP HANA no Power BI Desktop
DirectQuery and SAP HANA (DirectQuery e SAP HANA)
Utilizar o conector SAP BW no Power BI Desktop
O Azure Data Factory oferece integração de dados do SAP HANA e Business Warehouse

Alterar Registo
06/10/2020: Adicionar novos SKUs HLI em SKUs disponíveis para hli e SAP HANA (Grandes Instâncias)
arquitetura de armazenamento
05/21/2020: Alteração na configuração do Pacemaker no SLES em Azure e criação de Pacemaker no RHEL em
Azure para adicionar uma ligação à conectividade de ponto final público para VMs usando Azure Standard ILB
em cenários SAP HA
05/19/2020: Adicione mensagem importante para não utilizar o grupo de volume de raiz ao utilizar o LVM para
volumes relacionados com HANA em configurações de armazenamento de máquinas virtuais SAP HANA Azure
05/19/2020: Adicione um novo SISTEMA de Grande Instância de HANA para HANA Large Instance Tipo II em
[Sistemas Operativos Compatíveis para Grandes Instâncias HANA].https://docs.microsoft.com/
azure/virtual-machines/workloads/sap/os-compatibilidade-matrix-hana-large-instance)
05/12/2020: Alteração da conectividade de ponto final público para VMs utilizando O Azure Standard ILB em
cenários SAP HA para atualizar links e adicionar informações para a configuração de firewall de terceiros
05/11/2020: Alteração da elevada disponibilidade de SAP HANA em VMs Azure em SLES para definir a fixação
de recursos para 0 para o recurso netcat, uma vez que isso leva a uma falha mais simplificada
05/05/2020: Alterações no planeamento e implementação de Máquinas Virtuais Azure para SAP NetWeaver
para expressar que as implementações da Gen2 estão disponíveis para a família Mv1 VM
04/24/2020: Alterações na escala SAP HANA com nó de standby em Azure VMs com ANF em SLES,em escala
SAP HANA com nó de espera em VMs Azure com ANF em RHEL, Alta disponibilidade para SAP NetWeaver em
VMs Azure em SLES com ANF e Alta disponibilidade para SAP NetWeaver em VMs Azure em RHEL com ANF
para adicionar esclarecimentos de que os endereços IP para volumes ANF são automaticamente atribuídos
04/22/2020: Alteração da alta disponibilidade de SAP HANA em VMs Azure em SLES para remover o meta
atributo das is-managed instruções, uma vez que entra em conflito com a colocação do cluster dentro ou fora
do modo de manutenção
04/21/2020: Adicionado SQL Azure DB como DBMS suportado para SAP (Hybris) Plataforma de Comércio
1811 e mais tarde em artigos O software SAP é suportado para implementações Azure e certificações SAP e
configurações em execução no Microsoft Azure
04/16/2020: Adicionado SAP HANA como DBMS suportado para SAP (Hybris) Plataforma de Comércio em
artigos O software SAP é suportado para implementações Azure e certificações SAP e configurações em
execução no Microsoft Azure
04/13/2020: Correto para exato números de lançamento SAP ASE em instalação DBMS de Máquinas Virtuais
SAP ASE Azure para carga de trabalho SAP
04/07/2020: Alteração da criação do Pacemaker no SLES em Azure para clarificar instruções cloud-netconfig-
azure
04/06/2020: Alterações na escala SAP HANA com nó de standby em VMs Azure netapp em SLES e em escala
SAP HANA com nó de standby em Azure VMs com Ficheiros Azure NetApp em RHEL para remover referências
ao NetApp TR-4435 (substituído por TR-4746)
03/31/2020: Alteração da alta disponibilidade de SAP HANA em VMs Azure em SLES e Alta disponibilidade de
SAP HANA em VMs Azure no RHEL para adicionar instruções sobre como especificar o tamanho das listras ao
criar volumes listrados
03/27/2020: Alteração da alta disponibilidade para SAP NW em VMs Azure em SLES com ANF para aplicações
SAP para alinhar as opções de montagem do sistema de ficheiros para NetApp TR-4746 (remover a opção de
montagem de sincronização)
03/26/2020: Alteração da alta disponibilidade para SAP NetWeaver em VMs Azure no guia SLES multi-SID para
adicionar referência ao NetApp TR-4746
03/26/2020: Alteração da alta disponibilidade para SAP NetWeaver em VMs Azure em SLES para aplicações
SAP, Alta disponibilidade para SAP NetWeaver em VMs Azure em SLES com Ficheiros Azure NetApp para
aplicações SAP, Alta disponibilidade para NFS em VMs Azure em SLES, Alta disponibilidade para SLES , Alta
disponibilidade para SLES , Alta disponibilidade para SLES , Alta disponibilidade para SLES , Alta disponibilidade
para SLES , Alta disponibilidade para SLES , Alta disponibilidade para aplicações Azure NetApp SAP NetWeaver
em VMs Azure no guia multi-SID SLES, Alta disponibilidade para SAP NetWeaver em VMs Azure em RHEL para
aplicações SAP e Alta disponibilidade para SAP NetWeaver em VMs Azure em REL com Ficheiros Azure NetApp
para aplicações SAP para atualizar diagramas e esclarecer instruções para criação de pool backend balancer
Azure Load Balancer
03/19/2020: Grande revisão do documento Quickstart: Instalação manual de sap hana de instância única em
máquinas virtuais Azure à instalação de SAP HANA em Máquinas Virtuais Azure
03/17/2020: Alteração na configuração do Pacemaker no SUSE Linux Enterprise Server em Azure para remover
a definição de configuração SBD que já não é necessária
03/16/2020: Clarificação do cenário de certificação de colunas na plataforma certificada SAP HANA IaaS no que
o software SAP é suportado para implementações do Azure
03/11/2020: Alteração da carga de trabalho do SAP em cenários suportados por máquinas virtuais Azure para
clarificar várias bases de dados por suporte de instância DBMS
03/11/2020: Alteração no planeamento e implementação de Máquinas Virtuais Azure para SAP NetWeaver
explicando a Geração 1 e Geração 2 VMs
03/10/2020: Alteração das configurações de armazenamento de máquinas virtuais SAP HANA Azure para
clarificar os limites reais de produção existentes da ANF
03/09/2020: Alteração da alta disponibilidade do SAP NetWeaver em VMs Azure no SUSE Linux Enterprise
Server para aplicações SAP, Alta disponibilidade para SAP NetWeaver em VMs Azure no SUSE Linux Enterprise
Server com Ficheiros Azure NetApp para aplicações SAP, Alta disponibilidade para NFS em VMs Azure até
Pacemaker no SUSE Linux Enterprise Server em Azure, Alta disponibilidade de IBM Db2 LUW em VMs Azure no
SUSE Linux Enterprise Server com Pacemaker, Alta disponibilidade de SAP HANA em VMs Azure no SUSE Linux
Enterprise Server e Alta disponibilidade para SAP NetWeaver em VMs Azure em guia SLES multi-SID para
atualizar recursos de cluster com recurso azure-lb
03/05/2020: Alterações de estrutura e alterações de conteúdo para Regiões Azure e máquinas virtuais Azure
em planeamento e implementação de Máquinas Virtuais Azure
03/03/2020: Alteração da alta disponibilidade para SAP NW em VMs Azure em SLES com ANF para aplicações
SAP para alterar para layout de volume ANF mais eficiente
03/01/2020: Guia de backup reformulado para SAP HANA em Azure Virtual Machines para incluir o serviço de
Backup Azure. Conteúdo reduzido e condensado em SAP HANA Azure Backup no nível de ficheiro e apagou um
terceiro documento que tratava da cópia de segurança através do instantâneo do disco. O conteúdo é tratado
no guia de backup para SAP HANA em Azure Virtual Machines
02/27/2020: Alteração da alta disponibilidade para SAP NW em VMs Azure em SLES para aplicações SAP,Alta
disponibilidade para SAP NW em VMs Azure em SLES com ANF para aplicações SAP e Alta disponibilidade para
SAP NetWeaver em VMs Azure em guia sles multi-SID para ajustar o parâmetro de cluster "on fail"
02/26/2020: Alteração nas configurações de armazenamento de máquinas virtuais SAP HANA Azure para
clarificar a escolha do sistema de ficheiros para HANA em Azure
02/26/2020: Alteração da arquitetura e cenários de alta disponibilidade para o SAP incluir o link para o HA para
SAP NetWeaver em VMs Azure no guia RHEL multi-SID
02/26/2020: Alteração da elevada disponibilidade para SAP NW em VMs Azure em SLES para aplicações SAP,
Alta disponibilidade para SAP NW em VMs Azure em SLES com ANF para aplicações SAP, Azure VMs alta
disponibilidade para SAP NetWeaver em RHEL e Azure VMs alta disponibilidade para SAP NetWeaver em RHEL
com Azure NetApp Files para remover a afirmação de que o cluster MULTI-SID ASCS/ERS não é suportado
02/26/2020: Lançamento de alta disponibilidade para SAP NetWeaver em VMs Azure no guia RHEL multi-SID
para adicionar uma ligação ao guia de cluster multi-SID SUSE
02/25/2020: Alteração da arquitetura e cenários de alta disponibilidade para a SAP adicionar links a artigos ha
mais recentes
02/25/2020: Alteração na alta disponibilidade da IBM Db2 LUW em VMs Azure no SUSE Linux Enterprise Server
com Pacemaker para apontar para o documento que descreve o acesso ao ponto final público com o balancer
standard Azure Load
02/21/2020: Revisão completa do artigo Instalação DBMS de Máquinas Virtuais SAP ASE Azure para carga de
trabalho SAP
02/21/2020: Alteração na configuração de armazenamento de máquinas virtuais SAP HANA Azure para
representar uma nova recomendação no tamanho das listras para /hana/dados e adição de definição de
programador de E/S
02/21/2020: Alterações nos documentos de grande instância da HANA para representar os NOVOS SKUs
certificados de S224 e S224m
02/21/2020: Alteração na disponibilidade de VMs Azure para SAP NetWeaver em RHEL e VMs Azure alta
disponibilidade para SAP NetWeaver em RHEL com Azure NetApp Files para ajustar os constrangimentos de
cluster para a replicação do servidor de enqueue 2 arquitetura (ENSA2)
02/20/2020: Alteração da alta disponibilidade para SAP NetWeaver em VMs Azure no guia SLES multi-SID para
adicionar uma ligação ao guia de cluster multi-SID SUSE
02/13/2020: Alterações ao planeamento e implementação de Máquinas Virtuais Azure para o SAP NetWeaver
para implementar ligações a novos documentos
02/13/2020: Adicionou novo documento SAP carga de trabalho no cenário suportado pela máquina virtual
Azure
02/13/2020: Novo documento Adicionado O software SAP é suportado para a implementação do Azure
02/13/2020: Alteração na alta disponibilidade da IBM Db2 LUW em VMs Azure no Red Hat Enterprise Linux
Server para apontar para documento que descreve o acesso ao ponto final público com o balanceador standard
Azure Load
02/13/2020: Adicione os novos tipos de VM às certificações e configurações SAP em execução no Microsoft
Azure
02/13/2020: Adicione novas notas de suporte SAP em Azure: lista de verificação de planeamento e implantação
02/13/2020: Alteração na disponibilidade de VMs Azure para SAP NetWeaver em RHEL e VMs Azure alta
disponibilidade para SAP NetWeaver em RHEL com Azure NetApp Files para alinhar os intervalos de tempo dos
recursos de cluster às recomendações de timeout do Chapéu Vermelho
02/11/2020: Lançamento da SAP HANA na migração de Grande Instância Azure para máquinas virtuais Azure
02/07/2020: Alteração da conectividade de ponto final público para VMs utilizando Azure Standard ILB em
cenários SAP HA para atualizar a amostra de screenshot NSG
02/03/2020: Alteração da alta disponibilidade para SAP NW em VMs Azure em SLES para aplicações SAP e Alta
disponibilidade para SAP NW em VMs Azure em SLES com APLICAÇÕES SAP para remover o aviso sobre a
utilização de traços nos nomes de anfitrião de nós de cluster em SLES
28 de janeiro de 2020: Alteração da alta disponibilidade de SAP HANA em VMs Azure em RHEL para alinhar os
intervalos de tempo dos recursos do cluster SAP HANA às recomendações de timeout do Chapéu Vermelho
17 de janeiro de 2020: Alteração em grupos de colocação de proximidade Azure para uma latência ótima da
rede com aplicações SAP para alterar a secção de movimento de VMs existentes em um grupo de colocação de
proximidade
17 de janeiro de 2020: Alteração das configurações de carga de trabalho do SAP com Zonas de Disponibilidade
Azure para apontar para o procedimento que automatiza medições de latência entre zonas de disponibilidade
16 de janeiro de 2020: Alteração na forma de instalar e configurar SAP HANA (Grandes Instâncias) no Azure
para adaptar os lançamentos do SO ao diretório de hardware HANA IaaS
16 de janeiro de 2020: Alterações na alta disponibilidade para SAP NetWeaver em VMs Azure no guia SLES
multi-SID para adicionar instruções para sistemas SAP, utilizando a arquitetura do servidor de enqueue 2
(ENSA2)
10 de janeiro de 2020: Alterações na escala SAP HANA com nó de standby em VMs Azure com Azure NetApp
Files em SLES e em escala SAP HANA com nó de standby em Azure VMs com Ficheiros Azure NetApp no RHEL
para adicionar instruções sobre como tornar nfs4_disable_idmapping as alterações permanentes.
10 de janeiro de 2020: Alterações na alta disponibilidade do SAP NetWeaver em VMs Azure em SLES com
Ficheiros Azure NetApp para aplicações SAP e em Máquinas Virtuais Azure alta disponibilidade para SAP
NetWeaver em RHEL com Ficheiros Azure NetApp para aplicações SAP para adicionar instruções sobre como
montar volumes Azure NetApp Files NFSv4.
23 de dezembro de 2019: Lançamento de Alta Disponibilidade para SAP NetWeaver em VMs Azure no guia
SLES multi-SID
18 de dezembro de 2019: Lançamento da escala SAP HANA com nó de standby em VMs Azure com Ficheiros
Azure NetApp na RHEL
21 de novembro de 2019: Alterações na escala SAP HANA com nó de standby em VMs Azure com Ficheiros
Azure NetApp no SUSE Linux Enterprise Server para simplificar a configuração para mapeamento de ID NFS e
alterar a interface de rede primária recomendada para simplificar o encaminhamento.
15 de novembro de 2019: Pequenas alterações na alta disponibilidade do SAP NetWeaver no SUSE Linux
Enterprise Server com ficheiros Azure NetApp para aplicações SAP e Alta disponibilidade para SAP NetWeaver
no Red Hat Enterprise Linux com ficheiros Azure NetApp para aplicações SAP para clarificar restrições de
tamanho de pool de capacidade e remover a declaração de que apenas a versão NFSv3 é suportada.
12 de novembro de 2019: Lançamento de alta disponibilidade para SAP NetWeaver no Windows com Ficheiros
Azure NetApp (SMB)
8 de novembro, 2019: Alterações na alta disponibilidade de SAP HANA em VMs Azure no SUSE Linux Enterprise
Server, Configurar replicação do sistema SAP HANA em máquinas virtuais Azure (VMs), Azure Virtual Machines
alta disponibilidade para SAP NetWeaver no SUSE Linux Enterprise Server para aplicações SAP, Azure Virtual
Machines alta disponibilidade para SAP NetWeweux Enterprise Server com Azure NetAppaver, Azure Virtual
Machines alta disponibilidade para SAP NetWeaver em Red Hat Enterprise Linux, Azure Virtual Machines alta
disponibilidade para SAP NetWeaver em Red Hat Enterprise Linux com Azure NetApp Files, Alta disponibilidade
para NFS em VMs Azure no SUSE Linux Enterprise Server, GlusterFS em Azure VMs on Red Hat Enterprise Linux
para SAP NetWe
8 de novembro de 2019: Alterações no planeamento e verificação de implementação da carga de trabalho da
SAP para clarificar recomendação de encriptação
4 de novembro de 2019: Alterações na configuração do Pacemaker no SUSE Linux Enterprise Server em Azure
para criar o cluster diretamente com configuração unicast
Certificações e configurações SAP em execução no
Microsoft Azure
29/04/2020 • 7 minutes to read • Edit Online

A SAP e a Microsoft têm um longo historial de trabalhar em conjunto numa parceria forte que tem benefícios
mútuos para os seus clientes. A Microsoft está constantemente a atualizar a sua plataforma e a submeter novos
detalhes de certificação ao SAP de forma a garantir que o Microsoft Azure é a melhor plataforma para executar as
suas cargas de trabalho SAP. As tabelas seguintes descrevem configurações apoiadas pelo Azure e lista de
crescentes certificações SAP. Esta lista é uma lista geral que pode desviar-se aqui e ali das listas oficiais da SAP.
Como chegar aos dados detalhados está documentado no artigo O software SAP é suportado para
implementações do Azure

Certificações SAP HANA


Referências:
As plataformas IaaS certificadas sAP HANA para suporte SAP HANA para VMs azure nativos e GRANDES
Instâncias HANA.

P RO DUTO SA P O S SUP O RTA DO O F ERTA S A Z URE

SAP HANA Developer Edition (incluindo Red Hat Enterprise Linux, SUSE Linux Família VM série D
o software cliente HANA composto por Enterprise
SQLODBC, ODBO-Windows apenas,
ODBC, controladores JDBC, estúdio
HANA e base de dados HANA)

Business One em HANA Empresa SUSE Linux DS14_v2, M32ts, M32ls, M64ls, M64s
Plataformas IaaS Certificadas SAP HANA

SAP S/4 HANA Red Hat Enterprise Linux, SUSE Linux Disponibilidade Controlada para GS5.
Enterprise Suporte total para M64s, M64ms,
M128s, M128ms, M64ls, M32ls, M32ts,
M208s_v2, M208ms_v2, M416s_v2,
M416ms_v2,
SAP HANA em Azure (Grandes
instâncias) Plataformas IaaS Certificadas
SAP HANA

Suíte em HANA, OLTP Red Hat Enterprise Linux, SUSE Linux M64s, M64ms, M128s, M128ms,
Enterprise M64ls, M32ls, M32ts, M208s_v2,
M208ms_v2,
M416s_v2, M416ms_v2, SAP HANA em
Azure (Grandes instâncias) Plataformas
IaaS Certificadas SAP HANA

HANA Enterprise para BW, OLAP Red Hat Enterprise Linux, SUSE Linux GS5, M64s, M64ms, M128s, M128ms,
Enterprise M64ls, M32ls, M32ts, M208s_v2,
M208ms_v2,
M416s_v2, M416ms_v2, SAP HANA em
Azure (Grandes instâncias) Plataformas
IaaS Certificadas SAP HANA
P RO DUTO SA P O S SUP O RTA DO O F ERTA S A Z URE

SAP BW/4 HANA Red Hat Enterprise Linux, SUSE Linux GS5, M64s, M64ms, M128s, M128ms,
Enterprise M64ls, M32ls, M32ts, M208s_v2,
M208ms_v2,
M416s_v2, M416ms_v2, SAP HANA em
Azure (Grandes instâncias)
Plataformas IaaS Certificadas SAP HANA

Esteja ciente de que o SAP utiliza o termo 'clustering' nas Plataformas IaaS certificadas SAP HANA como sinónimo
para 'scale-out' e NÃO para 'clustering' de alta disponibilidade

Certificações SAP NetWeaver


O Microsoft Azure está certificado para os seguintes produtos SAP, com suporte total da Microsoft e SAP.
Referências:
1928533 - Aplicações SAP em Azure: Produtos suportados e tipos de VM Azure para todas as aplicações
baseadas em SAP NetWeaver, incluindo SAP TREX, SAP LiveCache e SAP Content Server. E todas as bases de
dados, excluindo o SAP HANA.

T IP O S DE M Á Q UIN A S
P RO DUTO SA P SO C O N VIDA DO RDB M S VIRT UA IS

Software de suite de Windows, SUSE Linux SQL Server, Oracle (apenas A5 a A11, D11 a D14, DS11
negócios SAP Enterprise, Red Hat Windows e Oracle Linux), a DS14, DS11_v2 a DS15_v2,
Enterprise Linux, Oracle DB2, SAP ASE GS1 a GS5, D2s_v3 a
Linux D64s_v3, D2as_v4 a
D64as_v4, E2s_v3 a E64s_v3,
E2as_v4 a E64as_v4, M64s,
M64ms, M128s, M128ms,
M64ls, M32ls, M32ts,
M208s_v2, M208ms_v2,
M416s_v2, M416ms_v2,

SAP Business All-in-One Windows, SUSE Linux SQL Server, Oracle (apenas A5 a A11, D11 a D14, DS11
Enterprise, Red Hat Windows e Oracle Linux), a DS14, DS11_v2 a DS15_v2,
Enterprise Linux, Oracle DB2, SAP ASE GS1 a GS5, D2s_v3 a
Linux D64s_v3, D2as_v4 a
D64as_v4, E2s_v3 a E64s_v3,
E2as_v4 a E64as_v4, M64s,
M64ms, M128s, M128ms,
M64ls, M32ls, M32ts,
M208s_v2, M208ms_v2,
M416s_v2, M416ms_v2,

SAP BusinessObjects BI Windows N/D A5 a A11, D11 a D14, DS11


a DS14, DS11_v2 a DS15_v2,
GS1 a GS5, D2s_v3 a
D64s_v3, D2as_v4 a
D64as_v4, E2s_v3 a E64s_v3,
E2as_v4 a E64as_v4, M64s,
M64ms, M128s, M128ms,
M64ls, M32ls, M32ts,
M208s_v2, M208ms_v2,
M416s_v2, M416ms_v2,
T IP O S DE M Á Q UIN A S
P RO DUTO SA P SO C O N VIDA DO RDB M S VIRT UA IS

SAP NetWeaver Windows, SUSE Linux SQL Server, Oracle (apenas A5 a A11, D11 a D14, DS11
Enterprise, Red Hat Windows e Oracle Linux), a DS14, DS11_v2 a DS15_v2,
Enterprise Linux, Oracle DB2, SAP ASE GS1 a GS5, D2s_v3 a
Linux D64s_v3, D2as_v4 a
D64as_v4, E2s_v3 a E64s_v3,
E2as_v4 a E64as_v4, M64s,
M64ms, M128s, M128ms,
M64ls, M32ls, M32ts,
M208s_v2, M208ms_v2,
M416s_v2, M416ms_v2,

Outracarga de trabalho SAP suportada no Azure


T IP O S DE M Á Q UIN A S
P RO DUTO SA P SO C O N VIDA DO RDB M S VIRT UA IS

SAP Business One no Windows SQL Server Todos os tipos de VM


Servidor SQL certificados netWeaver
Nota SAP #928839

SAP BPC 10.01 MS SP08 Windows e Linux Todos os tipos de VM


certificados NetWeaver
Nota SAP #2451795

Plataforma BI de Objetos Windows e Linux Nota SAP #2145537


Empresariais SAP

Serviços de Dados SAP 4.2 Nota SAP #2288344

Plataforma de Comércio SAP Windows SQL Server Todos os tipos de VM


Hybris certificados netWeaver
Documentação Hybris

Plataforma de Comércio SAP SLES 12 ou mais recente SAP HANA Todos os tipos de VM
Hybris certificados netWeaver
Documentação Hybris

Plataforma de Comércio SAP RHEL 7 ou mais recente SAP HANA Todos os tipos de VM
Hybris certificados netWeaver
[Documentação
Hybris]https://help.sap.com/
viewer/a74589c3a81a4a95bf
51d87258c0ab15/6.7.0.0/en
-
US/8c71300f866910149b40
c88dfc0de431.html)

Plataforma de Comércio SAP Janelas, SLES ou RHEL SQL Azure DB Todos os tipos de VM
(Hybris) 1811 e mais tarde certificados netWeaver
Documentação Hybris
O que é SAP HANA nas Instâncias Grandes do
Azure?
29/04/2020 • 7 minutes to read • Edit Online

SAP HANA on Azure (Grandes Instâncias) é uma solução única para o Azure. Além de fornecer máquinas virtuais
para a implementação e execução do SAP HANA, o Azure oferece-lhe a possibilidade de executar e implantar o
SAP HANA em servidores de metal nu que lhe são dedicados. A solução SAP HANA on Azure (Grandes Instâncias)
baseia-se em hardware de suporte/servidor não partilhado que lhe é atribuído. O hardware do servidor está
incorporado em selos maiores que contêm computação/servidor, networking e infraestrutura de armazenamento.
Como combinação, é certificada a integração de centros de dados (TDI) à medida da HANA. O SAP HANA no Azure
(Grandes Instâncias) oferece diferentes SKUs ou tamanhos do servidor. As unidades podem ter 36 núcleos intel
CPU e 768 GB de memória e ir até unidades que têm até 480 núcleos de CPU Intel e até 24 TB de memória.
O isolamento do cliente dentro do carimbo de infraestrutura é realizado em inquilinos, que parece:
Networking : Isolamento dos clientes dentro da pilha de infraestruturas através de redes virtuais por cliente
designado inquilino. Um inquilino é designado para um único cliente. Um cliente pode ter vários inquilinos. O
isolamento da rede de inquilinos proíbe a comunicação em rede entre inquilinos ao nível do selo de
infraestrutura, mesmo que os inquilinos pertençam ao mesmo cliente.
Componentes de armazenamento : Isolamento através de máquinas virtuais de armazenamento que
tenham volumes de armazenamento atribuídos a eles. Os volumes de armazenamento só podem ser atribuídos
a uma máquina virtual de armazenamento. Uma máquina virtual de armazenamento é atribuída
exclusivamente a um único inquilino na pilha de infraestrutura certificada SAP HANA TDI. Como resultado, os
volumes de armazenamento atribuídos a uma máquina virtual de armazenamento podem ser acedidos apenas
num inquilino específico e relacionado. Não são visíveis entre os diferentes inquilinos destacados.
Ser vidor ou anfitrião : Um servidor ou unidade de hospedar não é partilhado entre clientes ou inquilinos.
Um servidor ou hospedeiro implantado num cliente, é uma unidade de computação de metal nu atómico que é
atribuída a um único inquilino. Não é utilizada qualquer partilha de hardware ou divisória seletiva que possa
resultar na partilha de um anfitrião ou de um servidor com outro cliente. Os volumes de armazenamento
atribuídos à máquina virtual de armazenamento do inquilino específico são montados a tal servidor. Um
inquilino pode ter uma a muitas unidades de servidorde diferentes SKUs exclusivamente atribuídos.
Dentro de um selo de infraestrutura SAP HANA em Azure (Grandes Instâncias), muitos inquilinos diferentes são
implantados e isolados uns contra os outros através dos conceitos de inquilino em rede, armazenamento e
nível de computação.
Estas unidades de servidores de metal são suportadas apenas para executar SAP HANA. A camada de aplicação
SAP ou a camada de utensílios médios de carga funciona em máquinas virtuais. Os selos de infraestrutura que
gerem as unidades SAP HANA em Azure (Grandes Instâncias) estão ligados às espinhas dos serviços da rede
Azure. Desta forma, é fornecida conectividade de baixa latência entre unidades SAP HANA em Unidades Azure
(Grandes Instâncias) e máquinas virtuais.
A partir de julho de 2019, diferenciamos entre duas revisões diferentes dos selos de grande instância hana e a
localização das implantações:
"Revisão 3" (Rev 3): São os selos que foram disponibilizados para o cliente a implantar antes de julho de 2019
"Revisão 4" (Rev 4): Novo design de selos que é implantado nas proximidades dos anfitriões Azure VM e que
até agora são lançados nas regiões de Azure de:
E.U.A. Oeste 2
E.U.A. Leste
Europa ocidental
Europa do Norte
Este documento é um dos vários documentos que abrangem a SAP HANA em Azure (Grandes Instâncias). Este
documento introduz a arquitetura básica, responsabilidades e serviços prestados pela solução. Também são
discutidas capacidades de alto nível da solução. Para a maioria das outras áreas, como a rede e a conectividade,
quatro outros documentos cobrem detalhes e informações de perfuração. A documentação do SAP HANA sobre o
Azure (Grandes Instâncias) não abrange aspetos da instalação ou implantação da SAP NetWeaver em VMs. O SAP
NetWeaver em Azure está coberto por documentos separados encontrados no mesmo recipiente de
documentação Azure.
Os diferentes documentos de orientação de grandes instâncias hana abrangem as seguintes áreas:
Visão geral e arquitetura SAP HANA (Grandes Instâncias) em Azure
Infraestrutura e conectividade SAP HANA (Grandes Instâncias) em Azure
Instale e configure SAP HANA (Grandes Instâncias) no Azure
SAP HANA (Grandes Instâncias) alta disponibilidade e recuperação de desastres em Azure
SAP HANA (Grandes Instâncias) resolução e monitorização de problemas em Azure
Elevada disponibilidade criada em SUSE utilizando o STONITH
Backup osS e restauro para SKUs tipo II de carimbos de Revisão 3
Passos seguintes
Consulte os termos
Conhecer os termos
29/04/2020 • 8 minutes to read • Edit Online

Várias definições comuns são amplamente utilizadas no Guia de Arquitetura e Implantação Técnica. Note os
seguintes termos e significados:
IaaS : Infraestrutura como serviço.
PaaS : Plataforma como serviço.
SaaS : Software como serviço.
Componente SAP : Uma aplicação SAP individual, como a Componente Central ERP (ECC), O Armazém de
Negócios (BW), O Gestor de Soluções ou o Portal da Empresa (EP). Os componentes SAP podem basear-se
nas tecnologias tradicionais ABAP ou Java ou numa aplicação não baseada em NetWeaver, como Objetos
Empresariais.
Ambiente SAP : Um ou mais componentes SAP agrupados logicamente para desempenhar uma função de
negócio, tais como desenvolvimento, garantia de qualidade, formação, recuperação de desastres ou
produção.
Paisagem SAP : Refere-se a todos os ativos SAP na sua paisagem de TI. A paisagem SAP inclui todos os
ambientes de produção e não produção.
Sistema SAP : A combinação da camada DBMS e da camada de aplicação de, por exemplo, um sistema de
desenvolvimento SAP ERP, um sistema de teste SAP BW e um sistema de produção de CRM SAP. As
implantações azure não suportam dividir estas duas camadas entre as instalações e o Azure. Um sistema
SAP é implantado no local ou está implantado em Azure. Você pode implantar os diferentes sistemas de
uma paisagem SAP em Azure ou no local. Por exemplo, pode implantar os sistemas de desenvolvimento e
teste de CRM SAP em Azure enquanto implementa o sistema de produção de CRM SAP no local. Para o SAP
HANA on Azure (Grandes Instâncias), pretende-se que você acolhe a camada de aplicação SAP de sistemas
SAP em VMs e a instância sAP HANA relacionada em uma unidade no carimbo SAP HANA em Azure
(Grandes Instâncias).
Carimbo de grande instância : Uma pilha de infraestrutura de hardware certificada pela SAP HANA TDI e
dedicada a executar instâncias SAP HANA dentro do Azure.
SAP HANA em Azure (Grandes Instâncias): Nome oficial para a oferta em Azure para executar
instâncias HANA em hardware certificado SAP HANA TDI que é implantado em selos de Grande Instância
em diferentes regiões de Azure. O termo relacionado HANA Large Instance é curto para SAP HANA em
Azure (Grandes Instâncias) e é amplamente utilizado neste guia de implantação técnica.
Cross-premises : Descreve um cenário em que os VMs são implantados para uma subscrição Azure que
tem conectividade local-a-local, multi-site ou Azure ExpressRoute entre centros de dados no local e Azure.
Na documentação comum do Azure, este tipo de implantações também são descritos como cenários
transversais. A razão da ligação é o alargamento dos domínios no local, no local Azure Ative
Directory/OpenLDAP e no local DNS para azure. A paisagem no local é estendida aos ativos azure das
assinaturas Azure. Com esta extensão, os VMs podem fazer parte do domínio no local.
Os utilizadores de domínio do domínio no local podem aceder aos servidores e executar serviços nesses
VMs (como serviços DBMS). A resolução de comunicação e nome entre VMs implantados no local e VMs
implantados em Azure é possível. Este cenário é típico da forma como a maioria dos ativos da SAP são
implantados. Para mais informações, consulte o Azure VPN Gateway e crie uma rede virtual com uma
ligação site-a-site utilizando o portal Azure.
Inquilino : Um cliente implantado no carimbo HANA Large Instance é isolado num inquilino. Um inquilino
está isolado na camada de networking, armazenamento e computação de outros inquilinos. Unidades de
armazenamento e computação atribuídas aos diferentes inquilinos não podem ver-se ou comunicar entre si
no nível de selo hana Large Instance. Um cliente pode optar por ter implantações em diferentes inquilinos.
Mesmo assim, não existe comunicação entre inquilinos no nível de selo hana large instância.
Categoria SKU : Para a HANA Large Instance, são oferecidas as duas categorias seguintes de SKUs:
Classe tipo I : S72, S72m, S96, S144, S144m, S192, S192m, S192xm, S224 e S224m
Classe Tipo II : S384, S384m, S384xxm, S576m, S576xm, S768m, S768xm e S960m
Carimbo : Define o tamanho de implementação interna da Microsoft de grandes instâncias HANA. Antes
que as unidades hana Large Instance possam ser implantadas, um carimbo HANA Large Instance composto
por computação, rede e racks de armazenamento precisa de ser implantado num local de datacenter. Tal
implantação é chamada de carimbo de instância HANA Grande ou da Revisão 4 (ver abaixo) em que
usamos o termo alternativo de Large Instance Row
Revisão : Existem duas revisões diferentes de selos de grande instância HANA. Estes diferem na arquitetura
e proximidade com os anfitriões de máquinas virtuais Azure
"Revisão 3" (Rev 3): é o desenho original que foi implantado a partir de meados do ano de 2016
"Revisão 4" (Rev 4): é um novo design que pode proporcionar uma proximidade mais próxima aos
anfitriões de máquinas virtuais Azure e com essa menor latência de rede entre as Unidades Azure VMs e
HANA Large Instance
Uma variedade de recursos adicionais estão disponíveis sobre como implementar uma carga de trabalho SAP na
nuvem. Se planeia executar uma implantação do SAP HANA em Azure, tem de ser experiente e consciente dos
princípios do Azure IaaS e da implantação de cargas de trabalho SAP no Azure IaaS. Antes de continuar, consulte
soluções SAP use em máquinas virtuais Azure para obter mais informações.
Passos seguintes
Consulte a certificação HLI
Certificação
29/04/2020 • 4 minutes to read • Edit Online

Além da certificação NetWeaver, a SAP requer uma certificação especial para a SAP HANA para apoiar a SAP
HANA em certas infraestruturas, como o Azure IaaS.
A nota principal do SAP na NetWeaver, e em certa medida a certificação SAP HANA, é a SAP Note #1928533 –
Aplicações SAP em Azure: Produtos suportados e tipos de VM Azure.
Os registos de certificação das unidades SAP HANA em Azure (Grandes Instâncias) podem ser encontrados no site
iaaS certificado sAP HANA Platforms.
Os tipos SAP HANA on Azure (Grandes Instâncias), referidos no site iaaS certificado sap HANA Platforms,
fornecem aos clientes da Microsoft e da SAP a capacidade de implementar grandes sap business suite, SAP BW,
S/4 HANA, BW/4HANA, ou outras cargas de trabalho DaAP HANA em Azure. A solução baseia-se no carimbo de
hardware dedicado certificado sAP-HANA ( Integração de centros dedados personalizadoS SAP HANA – TDI). Se
executar uma solução configurada por SAP HANA TDI, todas as aplicações baseadas em SAP HANA (como a SAP
Business Suite em SAP HANA, SAP BW em SAP HANA, S4/HANA e BW4/HANA) funcionam na infraestrutura de
hardware.
Em comparação com a execução do SAP HANA em VMs, esta solução tem um benefício. Fornece volumes de
memória muito maiores. Para permitir esta solução, é necessário compreender os seguintes aspectos-chave:
A camada de aplicação SAP e as aplicações não SAP funcionam em VMs que estão hospedados nos habituais
selos de hardware Azure.
A infraestrutura, centros de dados e implementações de aplicações do cliente no local estão ligados à
plataforma da nuvem através do ExpressRoute (recomendado) ou de uma rede privada virtual (VPN). O
Diretório Ativo e o DNS também são estendidos ao Azure.
A base de dados SAP HANA para a carga de trabalho da HANA funciona no SAP HANA on Azure (Grandes
Instâncias). O carimbo de grande instância está ligado à rede Azure, para que o software que funciona em VMs
possa interagir com a instância HANA em execução em HANA Large Instance.
Hardware da SAP HANA on Azure (Grandes Instâncias) é um hardware dedicado fornecido num IaaS com SUSE
Linux Enterprise Server ou Red Hat Enterprise Linux pré-instalado. Tal como acontece com as máquinas virtuais,
novas atualizações e manutenção do sistema operativo são da sua responsabilidade.
A instalação de HANA ou quaisquer componentes adicionais necessários para executar o SAP HANA em
unidades da HANA Large Instance é da sua responsabilidade. Todas as respetivas operações em curso e
administração da SAP HANA no Azure também são da sua responsabilidade.
Além das soluções aqui descritas, pode instalar outros componentes na sua subscrição Azure que se ligam ao
SAP HANA no Azure (Grandes Instâncias). Exemplos são componentes que permitem a comunicação com ou
diretamente para a base de dados SAP HANA, tais como servidores de salto, servidores RDP, Estúdio SAP
HANA, Serviços de Dados SAP para cenários SAP BI ou soluções de monitorização de rede.
Tal como em Azure, a HANA Large Instance oferece suporte para uma funcionalidade de alta disponibilidade e
recuperação de desastres.
Passos seguintes
Consulte as SKUs disponíveis para hli
SKUs Disponíveis para HLI
21/06/2020 • 19 minutes to read • Edit Online

O serviço SAP HANA on Azure (Grandes Instâncias) baseado apenas na Revisão 3 selos, está disponível em várias
configurações nas regiões Azure de:
Leste da Austrália
Austrália Sudeste
Leste do Japão
Oeste do Japão
O serviço SAP HANA on Azure (Grandes Instâncias) com base na Revisão 4 selos está disponível em várias
configurações nas regiões Azure de:
E.U.A.Oeste 2
E.U.A. Leste
E.U.A. Leste 2
E.U.A. Centro-Sul
Europa Ocidental
Europa do Norte
SAP HANA certificada SKUs da HANA large Instances lista como:

SO L UÇ Ã O SA P M O DELO M EM Ó RIA A RM A Z EN A M EN TO DISP O N IB IL IDA DE

OLAP, OLTP SAP HANA em Azure 768 GB 3.0 TB Disponível


S96
– 2 x Intel® Xeon®
Processador E7-8890
v4
48 núcleos de CPU e
96 fios de CPU

OLAP, OLTP SAP HANA em Azure 3.0 TB 6.3 TB Disponível


S224
– 4 x Processador
Intel® Xeon®
Platinum 8276
112 núcleos de CPU
e 224 fios de CPU

OLTP SAP HANA em Azure 6.0 TB 10.5 TB Disponível


S224m
– 4 x Processador
Intel® Xeon®
Platinum 8276
112 núcleos de CPU
e 224 fios de CPU
SO L UÇ Ã O SA P M O DELO M EM Ó RIA A RM A Z EN A M EN TO DISP O N IB IL IDA DE

OLAP, OLTP SAP HANA em Azure 4.0 TB 16 TB Disponível


S384
– 8 x Intel® Xeon®
Processador E7-8890
v4
192 núcleos de CPU
e 384 fios de CPU

OLTP SAP HANA em Azure 6.0 TB 18 TB Disponível (apenas


S384xm rev 4)
– 8 x Intel® Xeon®
Processador E7-8890
v4
192 núcleos de CPU
e 384 fios de CPU

TDIv5 SAP HANA em Azure 12.0 TB 28 TB Disponível


S384m
– 8 x Intel® Xeon®
Processador E7-8890
v4
192 núcleos de CPU
e 384 fios de CPU

OLAP, OLTP SAP HANA em Azure 8.0 TB 22 TB Disponível


S384xm
– 8 x Intel® Xeon®
Processador E7-8890
v4
192 núcleos de CPU
e 384 fios de CPU

OLTP SAP HANA em Azure 12.0 TB 28 TB Disponível (apenas


S576m rev 4)
– 12 x Intel®
Xeon® Processador
E7-8890 v4
288 núcleos de CPU
e 576 fios de CPU

TDIv5 SAP HANA em Azure 18.0 TB 41 TB Disponível


S576xm
– 12 x Intel®
Xeon® Processador
E7-8890 v4
288 núcleos de CPU
e 576 fios de CPU

OLTP SAP HANA em Azure 16.0 TB 36 TB Disponível (apenas


S768m rev 4)
– 16 x Intel®
Xeon® Processador
E7-8890 v4
384 núcleos de CPU
e 768 fios de CPU
SO L UÇ Ã O SA P M O DELO M EM Ó RIA A RM A Z EN A M EN TO DISP O N IB IL IDA DE

TDIv5 SAP HANA em Azure 24.0 TB 56 TB Disponível


S768xm
– 16 x Intel®
Xeon® Processador
E7-8890 v4
384 núcleos de CPU
e 768 fios de CPU

OLTP SAP HANA em Azure 20.0 TB 46 TB Disponível (apenas


S960m rev 4)
– 20 x Intel®
Xeon® Processador
E7-8890 v4
480 núcleos de CPU
e 960 fios de CPU

OLTP SAP HANA em Azure 24.0 TB 35.8 TB Disponível (apenas


S896m rev 4)
– 16 x Processador
Intel® Xeon®
Platinum 8276
448 núcleos de CPU
e 896 fios de CPU

Núcleos cpu = soma de núcleos de CPU não hiper-roscados da soma dos processadores da unidade do
servidor.
Fios CPU = soma de fios de cálculo fornecidos por núcleos de CPU hiper roscados da soma dos processadores
da unidade do servidor. A maioria das unidades são configuradas por padrão para usar a tecnologia de hiper
rosca.
Com base nas recomendações do fornecedor S768m, S768xm e S960m não estão configurados para utilizar o
Hyper-Threading para executar o SAP HANA.
De acordo com o SAP HANA TDIv5, o SAP permite projetos específicos do cliente e de tamanhos específicos do
cliente, o que pode levar a configurações de servidores, que não estão listados como certificados em:
Aparelhos Certificados SAP HANA
PLATAFORMAS SAP HANA certificadas iaa
Em muitos casos, estas configurações de servidor específicas do cliente transportam mais memória do que as
unidades de servidor certificadas com SAP. Ao trabalhar com o SAP, os clientes têm a possibilidade de obter
suporte SAP e certificar para as suas configurações de servidor de tamanho específico do cliente.
Além disso, os seguintes SKUs standard de Grande Instância, embora ainda não certificados com SAP, estão
disponíveis e na lista de preços da Microsoft para comprar:

DRA M DE O P TA N E A RM A Z EN A M EN DISP O N IB IL IDA D


M O DELO M EM Ó RIA TOTA L M EM Ó RIA M EM Ó RIA TO E

SAP HANA em 4.5 TB 1,5 TB 3.0 TB 8.4 TB Disponível


Azure S224oo
– 4 x Processador
Intel® Xeon®
Platinum 8276
112 núcleos de
CPU e 224 fios
de CPU
DRA M DE O P TA N E A RM A Z EN A M EN DISP O N IB IL IDA D
M O DELO M EM Ó RIA TOTA L M EM Ó RIA M EM Ó RIA TO E

SAP HANA em 6.0 TB 3.0 TB 3.0 TB 10.5 TB Disponível


Azure S224om
– 4 x Processador
Intel® Xeon®
Platinum 8276
112 núcleos de
CPU e 224 fios
de CPU

SAP HANA em 7.5 TB 1,5 TB 6.0 TB 12.7 TB Disponível


Azure S224ooo
– 4 x Processador
Intel® Xeon®
Platinum 8276
112 núcleos de
CPU e 224 fios
de CPU

SAP HANA em 9.0 TB 3.0 TB 6.0 TB 14.8 TB Disponível


Azure S224oom
– 4 x Processador
Intel® Xeon®
Platinum 8276
112 núcleos de
CPU e 224 fios
de CPU

SAP HANA em 6.0 TB 6.0 TB --- 10.5 TB Disponível


Azure S448 (apenas rev 4)
– 8 x Intel®
Xeon®
processador
Platinum 8276
224 núcleos de
CPU e 448 fios
de CPU

SAP HANA em 12.0 TB 12.0 TB --- 18.9 TB Disponível


Azure S448m (apenas rev 4)
– 8 x Intel®
Xeon®
processador
Platinum 8276
224 núcleos de
CPU e 448 fios
de CPU

SAP HANA em 9.0 TB 3.0 TB 6.0 TB 14.8 TB Disponível


Azure S448oo (apenas rev 4)
– 8 x Intel®
Xeon®
processador
Platinum 8276
224 núcleos de
CPU e 448 fios
de CPU
DRA M DE O P TA N E A RM A Z EN A M EN DISP O N IB IL IDA D
M O DELO M EM Ó RIA TOTA L M EM Ó RIA M EM Ó RIA TO E

SAP HANA em 12.0 TB 6.0 TB 6.0 TB 18.9 TB Disponível


Azure S448om (apenas rev 4)
– 8 x Intel®
Xeon®
processador
Platinum 8276
224 núcleos de
CPU e 448 fios
de CPU

SAP HANA em 15.0 TB 3.0 TB 12.0 TB 23.2 TB Disponível


Azure S448ooo (apenas rev 4)
– 8 x Intel®
Xeon®
processador
Platinum 8276
224 núcleos de
CPU e 448 fios
de CPU

SAP HANA em 18.0 TB 6.0 TB 12.0 TB 27.4 TB Disponível


Azure S448oom (apenas rev 4)
– 8 x Intel®
Xeon®
processador
Platinum 8276
224 núcleos de
CPU e 448 fios
de CPU

SAP HANA em 9.0 TB 9.0 TB --- 14.7 TB Disponível


Azure S672 (apenas rev 4)
– 12 x
Processador
Intel® Xeon®
Platinum 8276
336 núcleos de
CPU e 672 fios
de CPU

SAP HANA em 18.0 TB 18.0 TB --- 27.4 TB Disponível


Azure S672m (apenas rev 4)
– 12 x
Processador
Intel® Xeon®
Platinum 8276
336 núcleos de
CPU e 672 fios
de CPU
DRA M DE O P TA N E A RM A Z EN A M EN DISP O N IB IL IDA D
M O DELO M EM Ó RIA TOTA L M EM Ó RIA M EM Ó RIA TO E

SAP HANA em 13.5 TB 4.5 TB 9.0 TB 21.1 TB Disponível


Azure S672oo (apenas rev 4)
– 12 x
Processador
Intel® Xeon®
Platinum 8276
336 núcleos de
CPU e 672 fios
de CPU

SAP HANA em 18.0 TB 9.0 TB 9.0 TB 27.4 TB Disponível


Azure S672om (apenas rev 4)
– 12 x
Processador
Intel® Xeon®
Platinum 8276
336 núcleos de
CPU e 672 fios
de CPU

SAP HANA em 22.5 TB 4.5 TB 18.0 TB 33.7 TB Disponível


Azure S672ooo (apenas rev 4)
– 12 x
Processador
Intel® Xeon®
Platinum 8276
336 núcleos de
CPU e 672 fios
de CPU

SAP HANA em 27.0 TB 9.0 TB 18.0 TB 40.0 TB Disponível


Azure S672oom (apenas rev 4)
– 12 x
Processador
Intel® Xeon®
Platinum 8276
336 núcleos de
CPU e 672 fios
de CPU

SAP HANA em 12.0 TB 12.0 TB --- 18.9 TB Disponível


Azure S896 (apenas rev 4)
– 16 x
Processador
Intel® Xeon®
Platinum 8276
448 núcleos de
CPU e 896 fios
de CPU
DRA M DE O P TA N E A RM A Z EN A M EN DISP O N IB IL IDA D
M O DELO M EM Ó RIA TOTA L M EM Ó RIA M EM Ó RIA TO E

SAP HANA em 18.0 TB 6.0 TB 12.0 TB 27.4 TB Disponível


Azure S896oo (apenas rev 4)
– 16 x
Processador
Intel® Xeon®
Platinum 8276
448 núcleos de
CPU e 896 fios
de CPU

SAP HANA em 24.0 TB 12.0 TB 12.0 TB 35.8 TB Disponível


Azure S896om (apenas rev 4)
– 16 x
Processador
Intel® Xeon®
Platinum 8276
448 núcleos de
CPU e 896 fios
de CPU

SAP HANA em 30.0 TB 6.0 TB 24.0 TB 44.3 TB Disponível


Azure S896ooo (apenas rev 4)
– 16 x
Processador
Intel® Xeon®
Platinum 8276
448 núcleos de
CPU e 896 fios
de CPU

SAP HANA em 36.0 TB 12.0 TB 24.0 TB 52.7 TB Disponível


Azure S896oom (apenas rev 4)
– 16 x
Processador
Intel® Xeon®
Platinum 8276
448 núcleos de
CPU e 896 fios
de CPU

IMPORTANT
Os seguintes SKUs, embora ainda apoiados, já não podem ser comprados: S72, S72m, S144, S144m, S192 e S192m

As configurações específicas escolhidas dependem da carga de trabalho, dos recursos da CPU e da memória
desejada. É possível que a carga de trabalho da OLTP utilize os SKUs otimizados para a carga de trabalho do
OLAP.
A base de hardware para as ofertas, com exceção das unidades para projetos de dimensionamento específicos
para o cliente, é certificada pela SAP HANA TDI. Duas classes diferentes de hardware dividem os SKUs em:
S72, S72m, S96, S144, S144m, S192, S192m, S192xm, S224, e S224m, S224oo, S224om, S224ooo, S224oom
são referidos como a "classe Tipo I" dos SKUs.
Todos os outros SKUs são referidos como a "classe tipo II" das SKUs.
Se estiver interessado em SKUs que ainda não estejam listados no diretório de hardware SAP, contacte a sua
equipa de conta microsoft para obter mais informações.
Um carimbo completo de HANA Large Instance não é atribuído exclusivamente para um único cliente'uso. Este
facto aplica-se aos racks de recursos de computação e armazenamento ligados através de um tecido de rede
implantado também no Azure. A infraestrutura HANA Large Instance, tal como a Azure, implanta diferentes "
inquilinos de clientes " que estão isolados uns dos outros nos seguintes três níveis:
Rede : Isolamento através de redes virtuais dentro do carimbo HANA Large Instance.
Armazenamento : Isolamento através de máquinas virtuais de armazenamento que tenham volumes de
armazenamento atribuídos e isole volumes de armazenamento entre inquilinos.
Cálculo : Atribuição dedicada de unidades de servidor a um único inquilino. Nenhuma divisão dura ou suave
de unidades de servidor. Nenhuma partilha de um único servidor ou unidade de anfitrião entre inquilinos.
As implantações de unidades de grande instância HANA entre diferentes inquilinos não são visíveis entre si. As
unidades de grande instância HANA implantadas em diferentes inquilinos não podem comunicar diretamente uns
com os outros no nível de selo HANA Large Instance. Apenas unidades de HANA Large Instance dentro de um
inquilino podem comunicar entre si no nível de selo HANA Large Instance.
Um inquilino implantado no carimbo de Grande Instância é atribuído a uma subscrição da Azure para efeitos de
faturação. Para uma rede, pode ser acedido a partir de redes virtuais de outras subscrições do Azure dentro da
mesma inscrição do Azure. Se você implementar com outra subscrição Azure na mesma região de Azure, você
também pode optar por pedir um inquilino separado HANA Large Instance.
Existem diferenças significativas entre a execução do SAP HANA na HANA Large Instance e a SAP HANA em VMs
implantadas em Azure:
Não existe uma camada de virtualização para SAP HANA em Azure (Grandes Instâncias). Obtém-se o
desempenho do hardware de metal nu.
Ao contrário do Azure, o servidor SAP HANA on Azure (Large Instances) é dedicado a um cliente específico.
Não existe a possibilidade de uma unidade de servidor ou hospedeiro ser dura ou macia. Como resultado,
uma unidade HANA Large Instance é usada como um todo atribuído a um inquilino e com isso para você. Um
reboot ou encerramento do servidor não leva automaticamente ao sistema operativo e o SAP HANA está a ser
implantado noutro servidor. (Para SKUs da classe Tipo I, a única exceção é se um servidor encontrar problemas
e a reafectação precisar de ser realizada noutro servidor.)
Ao contrário do Azure, onde os tipos de processadores hospedeiros são selecionados para a melhor relação
preço/desempenho, os tipos de processador escolhidos para SAP HANA em Azure (Grandes Instâncias) são os
mais bem-executadas da linha de processador Intel E7v3 e E7v4.
Próximos passos
Consulte o tamanho do HLI
Dimensionamento
29/04/2020 • 2 minutes to read • Edit Online

Dimensionar para HANA Large Instance não é diferente do tamanho para HANA em geral. Para sistemas existentes
e implantados que pretende mover de outros RDBMS para HANA, o SAP fornece uma série de relatórios que
funcionam nos seus sistemas SAP existentes. Se a base de dados for transferida para HANA, estes relatórios
verificam os dados e calculam os requisitos de memória para a instância HANA. Para obter mais informações
sobre como executar estes relatórios e obter os seus patches ou versões mais recentes, leia as seguintes Notas
SAP:
SAP Note #1793345 - Dimensionamento para Suíte SAP em HANA
Nota SAP #1872170 - Suite em HANA e Relatório de tamanho S/4 HANA
Nota SAP #2121330 - FAQ: SAP BW no relatório de tamanhos HANA
SAP Nota #1736976 - Relatório de dimensionamento para a BW sobre HANA
SAP Nota #2296290 - Novo relatório de tamanhos para a BW sobre HANA
Para implementações de campo verde, o SAP Quick Sizer está disponível para calcular os requisitos de memória da
implementação do software SAP em cima da HANA.
Os requisitos de memória para HANA aumentam à medida que o volume de dados aumenta. Esteja atento ao seu
consumo de memória atual para ajudá-lo a prever o que vai ser no futuro. Com base nos requisitos de memória,
pode então mapear a sua procura numa das SKUs de Grande Instância HANA.
Passos seguintes
Consulte os requisitos de embarque
Requisitos de integração
29/04/2020 • 7 minutes to read • Edit Online

Esta lista reúne requisitos para executar SAP HANA em Azure (Instâncias Maiores).
Microsoft Azure
Uma subscrição Azure que pode ser ligada ao SAP HANA em Azure (Grandes Instâncias).
Contrato de suporte da Microsoft Premier. Para obter informações específicas relacionadas com o
funcionamento do SAP em Azure, consulte a Nota de Suporte SAP #2015553 – SAP no Microsoft Azure:
Suporte pré-requisitos. Se utilizar unidades HANA Large Instance com 384 e mais CPUs, também precisa de
alargar o contrato de apoio premier para incluir a Resposta Rápida Azure.
Consciência das SKUs de Grande Instância HANA que você precisa depois de realizar um exercício de tamanho
com SAP.
Conectividade de rede
ExpressRoute entre as instalações do Azure: Para ligar o seu centro de dados no local ao Azure, certifique-se de
encomendar pelo menos uma ligação de 1-Gbps do seu ISP. A conectividade entre as unidades HANA Large
Instance e azure também está a usar a tecnologia ExpressRoute. Esta ligação ExpressRoute entre as unidades
HANA Large Instance e Azure está incluída no preço das unidades HANA Large Instance, incluindo todos os
dados de entrada e taxas de saída para este circuito expressroute específico. Portanto, você, como cliente, não
encontrará custos adicionais para além da sua ligação ExpressRoute entre as instalações e o Azure.
Sistema Operativo
Licenças para SUSE Linux Enterprise Server 12 para Aplicações SAP.

NOTE
O sistema operativo entregue pela Microsoft não está registado na SUSE. Não está ligado a uma instância de
Ferramenta de Gestão de Assinaturas.

Ferramenta de Gestão de Assinaturas SUSE Linux implantada em Azure num VM. Esta ferramenta fornece a
capacidade para que o SAP HANA no Azure (Grandes Instâncias) seja registado e, respectivamente,
atualizado pela SUSE. (Não existe acesso à Internet dentro do centro de dados HANA Large Instance.)
Licenças para Red Hat Enterprise Linux 6.7 ou 7.x para SAP HANA.

NOTE
O sistema operativo entregue pela Microsoft não está registado com a Red Hat. Não está ligado a um gerente de
subscrição de chapéu vermelho.

Gestor de subscrição da Red Hat implantado em Azure num VM. O Red Hat Subscription Manager fornece a
capacidade para que o SAP HANA em Azure (Grandes Instâncias) seja registado e, respectivamente,
atualizado pela Red Hat. (Não existe acesso direto à Internet a partir do interior do inquilino implantado no
carimbo De Grande Instância Azure.)
A SAP exige que tenha um contrato de apoio com o seu fornecedor Linux também. Este requisito não é
removido pela solução da HANA Large Instance ou pelo facto de ter gerido o Linux em Azure. Ao contrário
de algumas das imagens da galeria Linux Azure, a taxa de serviço não está incluída na oferta de solução da
HANA Large Instance. É da sua responsabilidade cumprir os requisitos da SAP relativamente a contratos de
apoio com o distribuidor Linux.
Para o SUSE Linux, procure os requisitos dos contratos de suporte em Nota SAP #1984787 - SUSE Linux
Enterprise Server 12: Notas de instalação e nota SAP #1056161 - Suporte prioritário para aplicações
SAP.
Para o Red Hat Linux, é necessário ter os níveis de subscrição corretos que incluem atualizações de
suporte e serviço aos sistemas operativos da HANA Large Instance. A Red Hat recomenda a subscrição
red hat enterprise linux para a solução SAP. Consulte https://access.redhat.com/solutions/3082481.
Para a matriz de suporte das diferentes versões SAP HANA com as diferentes versões Linux, consulte SAP Note
#2235581.
Para a matriz de compatibilidade do sistema operativo e versões de firmware/controlador HLI, consulte o Os
Upgrade para HLI.

IMPORTANT
Para unidades do tipo II apenas a versão SLES 12 SP2 OS é suportada neste momento.

Base de dados
Licenças e componentes de instalação de software para SAP HANA (plataforma ou edição empresarial).
Aplicações
Licenças e componentes de instalação de software para quaisquer aplicações SAP que se conectem com o SAP
HANA e contratos de suporte sap relacionados.
Licenças e componentes de instalação de software para quaisquer aplicações não SAP utilizadas com sap HANA
em ambientes Azure (Grandes Instâncias) e contratos de suporte relacionados.
Competências
Experiência com e conhecimento do Azure IaaS e seus componentes.
Experiência e conhecimento de como implementar uma carga de trabalho SAP em Azure.
Instalação SAP HANA certificada pessoal.
Competências do arquiteto SAP para projetar alta disponibilidade e recuperação de desastres em torno do SAP
HANA.
SAP
A expectativa é que seja um cliente SAP e tenha um contrato de apoio com a SAP.
Especialmente para implementações da classe Tipo II da HANA Large Instance SKUs, consulte a SAP sobre
versões do SAP HANA e as configurações eventuais em hardware de grande escala.
Passos seguintes
Consulte a arquitetura SAP HANA (Grandes Instâncias) em Azure
Utilize os nódosos de nidismo de dados SAP HANA e
de extensão
29/04/2020 • 3 minutes to read • Edit Online

A SAP suporta um modelo de tiering de dados para SAP BW de diferentes lançamentos SAP NetWeaver e SAP
BW/4HANA. Para obter mais informações sobre o modelo de tiering de dados, consulte o documento SAP
BW/4HANA e SAP BW em HANA com nós de extensão SAP HANA. Com a HANA Large Instance, pode utilizar a
configuração da opção-1 dos nós de extensão SAP HANA, conforme explicado nos documentos do blog FAQ e SAP.
As configurações option-2 podem ser configuradas com as seguintes SKUs de grande instância HANA: S72m, S192,
S192m, S384 e S384m.
Quando se olha para a documentação, a vantagem pode não ser visível imediatamente. Mas quando se olha para
as diretrizes de dimensionamento SAP, pode ver uma vantagem utilizando os nós de extensão Da opção-1 e opção-
2 SAP HANA. Eis alguns exemplos:
As diretrizes de dimensionamento SAP HANA geralmente requerem o dobro da quantidade de volume de
dados como memória. Ao executar a sua instância SAP HANA com os dados quentes, tem apenas 50% ou
menos da memória preenchida com dados. O resto da memória é idealmente realizada para a SAP HANA fazer
o seu trabalho.
Isto significa que numa unidade HANA Large Instance S192 com 2 TB de memória, com uma base de dados SAP
BW, só tem 1 TB como volume de dados.
Se utilizar um nó de extensão SAP HANA adicional de opção-1, também um S192 HANA Large Instance SKU,
dá-lhe uma capacidade adicional de 2 TB para o volume de dados. Na configuração option-2, obtém-se mais 4
TB para volume de dados quentes. Em comparação com o nó quente, a capacidade de memória completa do nó
de extensão "quente" pode ser utilizada para armazenamento de dados para a opção-1. O dobro da memória
pode ser utilizado para o volume de dados na configuração do nó de extensão SAP HANA da opção 2.
Acaba com uma capacidade de 3 TB para os seus dados e uma relação quente-quente de 1:2 para a opção-1.
Tem 5 TB de dados e uma relação 1:4 com a configuração do nó de extensão option-2.
Quanto maior for o volume de dados em comparação com a memória, maior é a probabilidade de os dados
quentes que está a pedir serem armazenados no armazenamento do disco.
Passos seguintes
Consulte a arquitetura SAP HANA (Grandes Instâncias) em Azure
Modelo e responsabilidades de operações
29/04/2020 • 9 minutes to read • Edit Online

O serviço prestado com o SAP HANA on Azure (Grandes Instâncias) está alinhado com os serviços Azure IaaS.
Obtém-se uma instância de uma Grande Instância HANA com um sistema operativo instalado que está otimizado
para o SAP HANA. Tal como acontece com os VMs Azure IaaS, a maioria das tarefas de endurecimento do SISTEMA,
instalação de software adicional, instalação de HANA, operação do OS e HANA, e atualização do OS e HANA é da
sua responsabilidade. A Microsoft não obriga as atualizações do OS ou as atualizações da HANA sobre si.

Como mostrado no diagrama, SAP HANA on Azure (Grandes Instâncias) é uma oferta iaaS multi-inquilino. Na
maior parte das vezes, a divisão de responsabilidade está no limite da infraestrutura do OS. A Microsoft é
responsável por todos os aspetos do serviço abaixo da linha do sistema operativo. Você é responsável por todos os
aspetos do serviço acima da linha. O SO é da sua responsabilidade. Pode continuar a utilizar a maioria dos métodos
atuais no local que pode utilizar para o cumprimento, segurança, gestão de aplicações, base e gestão de OS. Os
sistemas aparecem como se estivessem na sua rede em todos os aspetos.
Este serviço está otimizado para o SAP HANA, por isso existem áreas onde precisa trabalhar com a Microsoft para
utilizar as capacidades de infraestrutura subjacentes para obter melhores resultados.
A lista seguinte fornece mais detalhes sobre cada uma das camadas e as suas responsabilidades:
Rede : Todas as redes internas para o carimbo de grande instância executando SAP HANA. A sua responsabilidade
inclui o acesso ao armazenamento, a conectividade entre as instâncias (para escala-out e outras funções),
conectividade com a paisagem e conectividade com O Azure onde a camada de aplicação SAP está alojada em VMs.
Também inclui conectividade WAN entre Os Centros de Dados Azure para a replicação de fins de recuperação de
desastres. Todas as redes são divididas pelo arrendatário e têm qualidade de serviço aplicada.
Armazenamento : O armazenamento virtualizado dividido para todos os volumes necessários pelos servidores
SAP HANA, bem como para instantâneos.
Ser vidores : Os servidores físicos dedicados para executar os DBs SAP HANA atribuídos aos inquilinos. Os
servidores da classe I de SKUs são abstratos de hardware. Com este tipo de servidores, a configuração do servidor
é recolhida e mantida em perfis, que podem ser movidos de um hardware físico para outro hardware físico. Tal
movimento (manual) de um perfil por operações pode ser comparado um pouco com a cura do serviço Azure. Os
servidores da classe II SKUs não oferecem tal capacidade.
SDDC : O software de gestão que é usado para gerir centros de dados como entidades definidas por software.
Permite à Microsoft reunir recursos para razões de escala, disponibilidade e desempenho.
O/S: O SISTEMA que escolher (SUSE Linux ou Red Hat Linux) que está a funcionar nos servidores. As imagens de
OS com as suas informações foram fornecidas pelo fornecedor linux individual à Microsoft para executar o SAP
HANA. Deve ter uma subscrição com o fornecedor Linux para a imagem específica otimizada pelo SAP HANA. É
responsável pelo registo das imagens com o fornecedor de SO.
A partir do ponto de entrega da Microsoft, é responsável por qualquer nova correção do sistema operativo Linux.
Este patching inclui pacotes adicionais que podem ser necessários para uma instalação bem sucedida do SAP
HANA e que não foram incluídos pelo fornecedor linux específico nas suas imagens sap HANA otimizadas. (Para
mais informações, consulte a documentação de instalação HANA da SAP e as notas SAP.)
É responsável pela correção de OS devido a mau funcionamento ou otimização do SISTEMA e dos seus
controladores em relação ao hardware específico do servidor. Também é responsável pela segurança ou correção
funcional do Sistema Operativo.
A sua responsabilidade também inclui monitorização e planeamento de capacidades de:
Consumo de recursos da CPU.
Consumo de memória.
Volumes de disco relacionados com espaço livre, IOPS e latência.
Tráfego de volume de rede entre hana grande instância e a camada de aplicação SAP.
A infraestrutura subjacente da HANA Large Instance fornece funcionalidade para cópia de segurança e restauro do
volume de SO. Usar esta funcionalidade também é da sua responsabilidade.
Middleware : O Caso SAP HANA, principalmente. Administração, operações e monitorização são da sua
responsabilidade. Pode utilizar a funcionalidade fornecida para utilizar instantâneos de armazenamento para fins
de backup e restauro e recuperação de desastres. Estas capacidades são fornecidas pela infraestrutura. As suas
responsabilidades incluem também a conceção de alta disponibilidade ou recuperação de desastres com estas
capacidades, alavancando-as e monitorizando para determinar se os instantâneos de armazenamento executados
com sucesso.
Dados : Os seus dados geridos pelo SAP HANA e outros dados, tais como ficheiros de backup localizados em
volumes ou partilhas de ficheiros. As suas responsabilidades incluem monitorizar o espaço livre do disco e gerir o
conteúdo nos volumes. Também é responsável pela monitorização da execução bem sucedida de cópias de
segurança de volumes de discos e instantâneos de armazenamento. A execução bem sucedida da replicação de
dados para sites de recuperação de desastres é da responsabilidade da Microsoft.
Candidaturas: As instâncias de aplicação SAP ou, no caso de aplicações não SAP, a camada de aplicação dessas
aplicações. As suas responsabilidades incluem implantação, administração, operações e monitorização dessas
aplicações. É responsável pelo planeamento da capacidade do consumo de recursos cpu, consumo de memória,
consumo de armazenamento de Azure e consumo de largura de banda da rede dentro das redes virtuais. É
também responsável pelo planeamento de capacidade supor o consumo de recursos de redes virtuais para o SAP
HANA em Azure (Grandes Instâncias).
WANs : As ligações que estabelece desde as instalações até às implantações do Azure para cargas de trabalho.
Todos os clientes com HANA Large Instance utilizam o Azure ExpressRoute para conectividade. Esta ligação não faz
parte da solução SAP HANA sobre azure (Grandes Instâncias). É responsável pela instalação desta ligação.
Arquivo : Pode preferir arquivar cópias de dados utilizando os seus próprios métodos em contas de
armazenamento. O arquivamento requer gestão, conformidade, custos e operações. É responsável por gerar cópias
de arquivo e cópias de segurança no Azure e armazená-las de forma compatível.
Consulte o SLA para SAP HANA em Azure (Grandes Instâncias).
Passos seguintes
Consulte a arquitetura SAP HANA (Grandes Instâncias) em Azure
Sistemas operativos compatíveis para grandes
instâncias HANA
20/05/2020 • 2 minutes to read • Edit Online

HANA Grande Instância Tipo I


SIST EM A O P ERAT IVO DISP O N IB IL IDA DE SK US

SLES 12 SP2 Não oferecido mais S72, S72m, S96, S144, S144m, S192,
S192m, S192xm

SLES 12 SP3 Disponível S72, S72m, S96, S144, S144m, S192,


S192m, S192xm

SLES 12 SP4 Disponível S72, S72m, S96, S144, S144m, S192,


S192m, S192xm, S224, S224m

SKUs de memória persistente


SIST EM A O P ERAT IVO DISP O N IB IL IDA DE SK US

SLES 12 SP4 Disponível S224oo, S224om, S224ooo, S224oom

HANA Grande Instância Tipo II


SIST EM A O P ERAT IVO DISP O N IB IL IDA DE SK US

SLES 12 SP2 Não oferecido mais S384, S384m, S384xm, S384xxm,


S576m, S576xm, S768m, S768xm,
S960m

SLES 12 SP3 Disponível S384, S384m, S384xm, S384xxm,


S576m, S576xm, S768m, S768xm,
S960m

SLES 12 SP4 Disponível S384, S384m, S384xm, S384xxm,


S576m, S576xm, S768m, S768xm,
S960m

SLES 12 SP5 Disponível S384, S384m, S384xm, S384xxm,


S576m, S576xm, S768m, S768xm,
S960m

Documentos Relacionados
Para saber mais sobre SKUs disponíveis
Saber sobre a modernização do Sistema Operativo
Arquitetura SAP HANA (Grandes Instâncias) em
Azure
29/04/2020 • 7 minutes to read • Edit Online

A um nível elevado, a solução SAP HANA on Azure (Grandes Instâncias) tem a camada de aplicação SAP residente
em VMs. A camada de base de dados reside em hardware configurado por SAP TDI localizado num carimbo de
grande instância na mesma região do Azure que está ligado ao Azure IaaS.

NOTE
Implante a camada de aplicação SAP na mesma região de Azure que a camada DBMS SAP. Esta regra está bem
documentada em informações publicadas sobre cargas de trabalho sap no Azure.

A arquitetura global do SAP HANA on Azure (Grandes Instâncias) fornece uma configuração de hardware
certificada por SAP TDI, que é um servidor de alto desempenho não virtualizado, de metal nu para a base de
dados SAP HANA. Também fornece a capacidade e flexibilidade do Azure para escalar recursos para a camada de
aplicação SAP para atender às suas necessidades.
A arquitetura mostrada é dividida em três secções:
Direito : Mostra uma infraestrutura no local que executa diferentes aplicações em centros de dados para
que os utilizadores finais possam aceder a aplicações LOB, como o SAP. Idealmente, esta infraestrutura no
local está ligada ao Azure com a ExpressRoute.
Centro : Mostra O Azure IaaS e, neste caso, a utilização de VMs para acolher SAP ou outras aplicações que
utilizam o SAP HANA como sistema DBMS. Casos MENORes de HANA que funcionam com a memória que
os VMs fornecem são implantados em VMs juntamente com a sua camada de aplicação. Para obter mais
informações sobre máquinas virtuais, consulte máquinas virtuais.
Os serviços de rede Azure são utilizados para agrupar sistemas SAP juntamente com outras aplicações em
redes virtuais. Estas redes virtuais ligam-se aos sistemas no local, bem como ao SAP HANA em Azure
(Grandes Instâncias).
Para aplicações e bases de dados SAP NetWeaver suportadas para funcionar em Azure, consulte SAP
Support Note #1928533 – Aplicações SAP no Azure: Produtos suportados e tipos de VM Azure. Para obter
documentação sobre como implementar soluções SAP no Azure, consulte:
Utilizar SAP em máquinas virtuais do Windows
Utilize soluções SAP em máquinas virtuais Azure
Esquerda : Mostra o hardware certificado por SAP HANA TDI no carimbo De Instância Grande Azure. As
unidades HANA Large Instance estão ligadas às redes virtuais da sua subscrição Azure utilizando a mesma
tecnologia que a conectividade das instalações para o Azure. A partir de maio de 2019 foi introduzida uma
otimização que permite comunicar entre as unidades HANA Large Instance e os VMs Azure sem
envolvimento do ExpressRoute Gateway. Esta otimização chamada Caminho Rápido ExpressRoute é exibida
nesta arquitetura (linhas vermelhas).
O carimbo de instância grande azure combina os seguintes componentes:
Computação : Servidores que são baseados em diferentes gerações de processadores Intel Xeon que
fornecem a capacidade de computação necessária e são certificados sAP HANA.
Rede : Um tecido unificado de rede de alta velocidade que interliga os componentes de computação,
armazenamento e LAN.
Armazenamento : Uma infraestrutura de armazenamento que é acedida através de um tecido de rede
unificado. A capacidade de armazenamento específica que é fornecida depende da configuração específica do
SAP HANA sobre o Azure (Grandes Instâncias) que é implantada. Mais capacidade de armazenamento está
disponível a um custo mensal adicional.
Dentro da infraestrutura multi-arrendatária do carimbo de Grande Instância, os clientes são destacados como
inquilinos isolados. Na implantação do inquilino, você nomeia uma assinatura Azure dentro da sua matrícula
Azure. Esta assinatura Azure é aquela contra a qual a Grande Instância HANA é cobrada. Estes inquilinos têm uma
relação 1:1 com a assinatura Azure. Para uma rede, é possível aceder a uma unidade HANA Large Instance
implantada num inquilino numa região do Azure de diferentes redes virtuais que pertencem a diferentes
subscrições do Azure. Estas assinaturas Azure devem pertencer à mesma matrícula do Azure.
Tal como acontece com os VMs, o SAP HANA on Azure (Grandes Instâncias) é oferecido em várias regiões azure.
Para oferecer capacidades de recuperação de desastres, pode optar por optar. Selos de grandes instâncias
diferentes dentro de uma região geopolítica estão ligados uns aos outros. Por exemplo, os selos de grande
instância HANA no Oeste e Leste dos EUA estão ligados através de uma ligação de rede dedicada para a
replicação de recuperação de desastres.
Assim como pode escolher entre diferentes tipos de VM com Máquinas Virtuais Azure, pode escolher entre
diferentes SKUs de HANA Large Instance que são adaptados para diferentes tipos de carga de trabalho de SAP
HANA. O SAP aplica rácios memória-processador-tomada para cargas de trabalho variadas com base nas
gerações do processador Intel. A tabela seguinte mostra os tipos SKU oferecidos.
Pode encontrar SKUs disponíveis disponíveis para HLI.
Passos seguintes
Consulte a arquitetura de rede SAP HANA (Grandes Instâncias)
Arquitetura de rede SAP HANA (Grandes Instâncias)
29/04/2020 • 37 minutes to read • Edit Online

A arquitetura dos serviços de rede Azure é um componente chave da implementação bem sucedida de aplicações
SAP em HANA Large Instance. Tipicamente, as implementações do SAP HANA em Azure (Grandes Instâncias) têm
uma paisagem SAP maior com várias soluções SAP diferentes com diferentes tamanhos de bases de dados,
consumo de recursos CPU e utilização da memória. É provável que nem todos os sistemas informáticos já estejam
localizados em Azure. A sua paisagem SAP é muitas vezes híbrida, bem como de um ponto DBMS e do ponto de
vista de aplicação SAP, utilizando uma mistura de NetWeaver, s/4HANA e SAP HANA e outros DBMS. A Azure
oferece diferentes serviços que lhe permitem executar os diferentes sistemas DBMS, NetWeaver e S/4HANA em
Azure. O Azure também oferece tecnologia de rede para fazer o Azure parecer um centro de dados virtual para as
suas implementações de software no local
A menos que os seus sistemas completos de TI estejam hospedados em Azure. A funcionalidade de networking
Azure é usada para ligar o mundo no local com os seus ativos Azure para fazer com que o Azure pareça um centro
de dados virtual seu. A funcionalidade de rede Azure utilizada é:
As redes virtuais Azure estão ligadas ao circuito ExpressRoute que se liga aos seus ativos de rede no local.
Um circuito ExpressRoute que ligue as instalações ao Azure deve ter uma largura de banda mínima de 1 Gbps
ou superior. Esta largura de banda mínima permite a largura de banda adequada para a transferência de dados
entre sistemas no local e sistemas que funcionam em VMs. Também permite uma largura de banda adequada
para a ligação aos sistemas Azure a partir de utilizadores no local.
Todos os sistemas SAP em Azure estão configurados em redes virtuais para comunicar uns com os outros.
O Diretório Ativo e o DNS alojados no local são estendidos ao Azure através da ExpressRoute a partir do local,
ou estão a funcionar completos em Azure.
Para o caso específico de integração hana grandes instâncias no tecido da rede de data center Azure, a tecnologia
Azure ExpressRoute também é usada

NOTE
Apenas uma subscrição Azure pode ser ligada a apenas um inquilino num carimbo HANA Large Instance numa região
específica de Azure. Inversamente, um único inquilino de selos HANA Large Instance pode ser ligado a apenas uma
assinatura Azure. Este requisito é consistente com outros objetos de faturação em Azure.

Se o SAP HANA em Azure (Grandes Instâncias) for implantado em várias regiões de Azure diferentes, um inquilino
separado é implantado no carimbo hana large instância. Pode executar ambos sob a mesma subscrição Azure,
desde que estes casos façam parte da mesma paisagem SAP.

IMPORTANT
Apenas o método de implementação do Gestor de Recursos Azure é suportado com o SAP HANA em Azure (Grandes
Instâncias).

Informações adicionais sobre a rede virtual


Para ligar uma rede virtual ao ExpressRoute, deve ser criado um portal Azure ExpressRoute. Para mais informações,
consulte os gateways da Expressroute para a ExpressRoute.
Um gateway Azure ExpressRoute é usado com expressroute para uma infraestrutura fora de Azure ou para um
carimbo azure large instância. Pode ligar a porta de entrada Azure ExpressRoute a um máximo de quatro circuitos
ExpressRoute diferentes, desde que essas ligações venham de diferentes routers de borda empresarial da
Microsoft. Para mais informações, consulte a infraestrutura SAP HANA (Grandes Instâncias) e a conectividade no
Azure.

NOTE
A entrada máxima que pode obter com um gateway ExpressRoute é de 10 Gbps utilizando uma ligação ExpressRoute. Copiar
ficheiros entre um VM que reside numa rede virtual e um sistema no local (como um único fluxo de cópia) não alcança a
entrada completa das diferentes SKUs de gateway. Para alavancar a largura de banda completa do gateway ExpressRoute,
utilize vários fluxos. Ou deve copiar ficheiros diferentes em fluxos paralelos de um único ficheiro.

Arquitetura de networking para HANA Grande Instância


A arquitetura de networking para HANA Large Instance pode ser separada em quatro partes diferentes:
Ligação em rede no local e ligação ExpressRoute ao Azure. Esta peça é o domínio do cliente e está ligada ao
Azure através do ExpressRoute. Este circuito Expressroute é totalmente pago por si como cliente. A largura de
banda deve ser suficientemente grande para lidar com o tráfego de rede entre os seus ativos no local e a região
azure contra a qual está a ligar. Consulte a parte inferior direita na figura seguinte.
Os serviços de rede Azure, como já foi discutido, com redes virtuais, que voltam a necessitar de gateways
ExpressRoute adicionados. Esta peça é uma área onde você precisa encontrar os projetos apropriados para os
seus requisitos de aplicação, segurança e requisitos de conformidade. Se utiliza a HANA Large Instance é outro
ponto a ter em conta em termos do número de redes virtuais e de Gateway SKUs azure para escolher. Veja a
parte superior direita na figura.
Conectividade da HANA Large Instance através da tecnologia ExpressRoute para Azure. Esta peça é
implementada e tratada pela Microsoft. Tudo o que precisa de fazer é fornecer algumas gamas de endereços IP
após a implementação dos seus ativos em HANA Large Instance ligar o circuito ExpressRoute às redes virtuais.
Para mais informações, consulte a infraestrutura SAP HANA (Grandes Instâncias) e a conectividade no Azure.
Não existe uma taxa adicional para si como cliente pela conectividade entre o tecido da rede de data center
Azure e as unidades HANA Large Instance.
Networking dentro do carimbo HANA Large Instance, que é maioritariamente transparente para si.
A exigência de que os seus ativos no local devem ligar através da ExpressRoute ao Azure não muda porque utiliza
a HANA Large Instance. A exigência de ter uma ou várias redes virtuais que executam os VMs, que acolhem a
camada de aplicação que se conecta às instâncias HANA alojadas nas unidades hana large instance, também não
muda.
As diferenças para as implantações sap em Azure são:
As unidades HANA Large Instance do seu inquilino cliente estão ligadas através de outro circuito ExpressRoute
nas suas redes virtuais. Para separar as condições de carga, as instalações para os circuitos Da Rede Virtual
Azure ExpressRoute e os circuitos entre redes virtuais Azure e HANA Large Instances não partilham os mesmos
routers.
O perfil de carga de trabalho entre a camada de aplicação SAP e a Grande Instância HANA é de natureza
diferente, com muitos pequenos pedidos e explosões como transferências de dados (conjuntos de resultados)
do SAP HANA para a camada de aplicação.
A arquitetura de aplicação SAP é mais sensível à latência da rede do que cenários típicos onde os dados são
trocados entre as instalações e o Azure.
O portal Azure ExpressRoute tem pelo menos duas ligações ExpressRoute. Um circuito que está ligado a partir
do local e outro que está ligado a partir de Grandes Instâncias HANA. Isto deixa apenas espaço para mais dois
circuitos adicionais de diferentes MSEEs para ligar no ExpressRoute Gateway. Esta restrição é independente do
uso do Caminho Rápido ExpressRoute. Todos os circuitos conectados partilham a largura de banda máxima
para os dados de entrada do gateway ExpressRoute.
Com a Revisão 3 dos selos HANA Large Instance, a latência da rede experimentada entre VMs e unidades HANA
Large Instance pode ser superior a uma latência típica de ida e volta da rede VM-to-VM. Dependendo da região de
Azure, os valores medidos podem exceder a latência de ida e volta de 0,7 ms classificada como abaixo da média
em SAP Note #1100926 - FAQ: Desempenhoda rede . Dependendo da região de Azure e ferramenta para medir a
latência de ida e volta da rede entre uma unidade Azure VM e HANA Large Instance, a latência medida pode chegar
a cerca de 2 milissegundos. No entanto, os clientes implementam aplicações SAP de produção baseadas em SAP
HANA com sucesso na SAP HANA Large Instance. Certifique-se de testar cuidadosamente os seus processos de
negócio em Azure HANA Large Instance. Uma nova funcionalidade, chamada ExpressRoute Fast Path, é capaz de
reduzir substancialmente a latência da rede entre as grandes instâncias hana e os VMs da camada de aplicação em
Azure (ver abaixo).
Com a Revisão 4 dos selos de Grande Instância HANA, a latência da rede entre Os VMs Azure que são implantados
nas proximidades do carimbo HANA Large Instance, é experimentado para cumprir a classificação média ou
melhor do que a média, como documentado na Nota SAP #1100926 - FAQ: Desempenho da rede se o Caminho
Rápido da Rota Rápida azure ExpressRoute estiver configurado (ver abaixo). Para implantar VMs Azure nas
proximidades das unidades HANA Large Instance da Revisão 4, é necessário alavancar os Grupos de Colocação de
Proximidade de Azure. A forma como os grupos de colocação de proximidade podem ser usados para localizar a
camada de aplicação SAP no mesmo centro de dados Azure como a Revisão 4 unidades de grande instância hana
hospedadas é descrita em Grupos de Colocação de Proximidade Azure para uma latência de rede ótima com
aplicações SAP.
Para proporcionar latência de rede determinística entre VMs e HANA Large Instance, a escolha do gateway
ExpressRoute SKU é essencial. Ao contrário dos padrões de tráfego entre as instalações e os VMs, o padrão de
tráfego entre VMs e HANA Large Instance pode desenvolver pequenas, mas elevadas explosões de pedidos e
volumes de dados a transmitir. Para lidar bem com estas explosões, recomendamos vivamente a utilização do
gateway UltraPerformance SKU. Para a classe Tipo II de HANA Large Instance SKUs, a utilização do gateway
UltraPerformance SKU como gateway ExpressRoute é obrigatória.

IMPORTANT
Dado o tráfego global de rede entre a aplicação SAP e as camadas de base de dados, apenas as SKUs de gateway
HighPerformance ou UltraPerformance para redes virtuais são suportadas para a ligação ao SAP HANA em Azure (Grandes
Instâncias). Para HANA Large Instance Type II SKUs, apenas o gateway UltraPerformance SKU é suportado como um gateway
ExpressRoute. As exceções aplicam-se quando se utiliza o Caminho Rápido expressRoute (ver abaixo)

Caminho rápido da Rota Expressa


Para reduzir a latência, o ExpressRoute Fast Path foi introduzido e lançado em maio de 2019 para a conectividade
específica das grandes instâncias HANA às redes virtuais Azure que acolhem os VMs da aplicação SAP. A grande
diferença para a solução lançada até agora, é que os fluxos de dados entre VMs e HANA Grandes Instâncias já não
são encaminhados através da porta de entrada ExpressRoute. Em vez disso, os VMs atribuídos nas subredes da
rede virtual Azure estão a comunicar diretamente com o router de borda empresarial dedicado.
IMPORTANT
A funcionalidade ExpressRoute Fast Path requer que as subredes que executam os VMs da aplicação SAP estejam na mesma
rede virtual Azure que foi ligada às Grandes Instâncias HANA. VMs localizados em redes virtuais Azure que são espreitadas
com a rede virtual Azure ligada diretamente às unidades HANA Large Instance não estão beneficiando do Caminho Rápido
ExpressRoute. Como resultado, os modelos típicos de rede virtual e hub, onde os circuitos ExpressRoute estão a ligar-se
contra uma rede virtual hub e redes virtuais contendo a camada de aplicação SAP (porta-vozes) estão a ser espreitadas, a
otimização pelo Caminho Rápido expressRoute não funcionará. Em adição, o ExpressRoute Fast Path não suporta as regras de
encaminhamento definidas pelo utilizador (UDR) hoje. Para mais informações, consulte o gateway da rede virtual
ExpressRoute e o FastPath.

Para mais detalhes sobre como configurar o Caminho Rápido ExpressRoute, leia o documento Ligue uma rede
virtual a grandes instâncias HANA.

NOTE
Um gateway UltraPerformance ExpressRoute é necessário para ter o Caminho Rápido ExpressRoute funcionando

Sistema SAP único


A infraestrutura no local anteriormente mostrada está ligada através da ExpressRoute para o Azure. O circuito
ExpressRoute liga-se a um router de borda empresarial da Microsoft (MSEE). Para mais informações, consulte a
visão geral técnica do ExpressRoute. Após a criação da rota, liga-se à espinha dorsal Azure.

NOTE
Para executar paisagens SAP em Azure, ligue-se ao router de borda empresarial mais próximo da região de Azure na
paisagem SAP. Os selos HANA Large Instance são ligados através de dispositivos de router de borda empresarial dedicados
para minimizar a latência da rede entre VMs em selos De Grande Instância Azure IaaS e HANA Large Instance.

A porta de entrada ExpressRoute para os VMs que acolhem instâncias de aplicação SAP estão ligadas a um circuito
ExpressRoute que se conecta às instalações. A mesma rede virtual está ligada a um router de borda empresarial
separado dedicado à ligação com selos de Grande Instância. Utilizando o Caminho Rápido ExpressRoute, os dados
fluem de HANA Grandes Instâncias para a camada de aplicação SAP VMs já não são encaminhados através do
gateway ExpressRoute e com isso reduzem a latência de ida e volta da rede.
Este sistema é um exemplo simples de um único sistema SAP. A camada de aplicação SAP está alojada em Azure. A
base de dados SAP HANA funciona no SAP HANA em Azure (Grandes Instâncias). O pressuposto é que a largura
de banda de gateway ExpressRoute de 2 Gbps ou 10 Gbps de entrada não representa um estrangulamento.

Múltiplos sistemas SAP ou grandes sistemas SAP


Se vários sistemas SAP ou grandes sistemas SAP forem implantados para ligar ao SAP HANA em Azure (Grandes
Instâncias), a entrada do gateway ExpressRoute pode tornar-se um estrangulamento. Ou quer isolar sistemas de
produção e não produção em diferentes redes virtuais Azure. Neste caso, divida as camadas de aplicação em
várias redes virtuais. Também pode criar uma rede virtual especial que se conecta à HANA Large Instance para
casos como:
Executando cópias de segurança diretamente dos casos HANA em HANA Large Instance para um VM em Azure
que acolhe ações da NFS.
Copiar grandes cópias de cópias ou outros ficheiros de unidades HANA Large Instance para o espaço de disco
gerido em Azure.
Utilize uma rede virtual separada para hospedar VMs que gerem o armazenamento para transferência em massa
de dados entre as grandes instâncias HANA e o Azure. Este arranjo evita os efeitos de grandes ficheiros ou
transferência de dados da HANA Large Instance para O Azure no gateway ExpressRoute que serve os VMs que
executam a camada de aplicação SAP.
Para uma arquitetura de rede mais escalável:
Aproveite várias redes virtuais para uma única camada de aplicação SAP maior.
Implementar uma rede virtual separada para cada sistema SAP implantado, em comparação com a
combinação destes sistemas SAP em subredes separadas sob a mesma rede virtual.
Uma arquitetura de networking mais escalável para SAP HANA em Azure (Grandes Instâncias):

Dependendo das regras e restrições, pretende aplicar-se entre as diferentes redes virtuais que hospedam VMs de
diferentes sistemas SAP, deve ser o par dessas redes virtuais. Para obter mais informações sobre o epeering da
rede virtual, consulte o peering da rede virtual.
Encaminhamento em Azure
Por predefinição, três considerações de encaminhamento de rede são importantes para o SAP HANA em Azure
(Grandes Instâncias):
O SAP HANA on Azure (Grandes Instâncias) só pode ser acedido através de VMs Azure e da conexão
ExpressRoute dedicada, não diretamente a partir do local. O acesso direto a partir das instalações para as
unidades HANA Large Instance, tal como lhe foi entregue pela Microsoft, não é possível imediatamente. As
restrições transitivas de encaminhamento devem-se à atual arquitetura de rede Azure utilizada para a
Grande Instância SAP HANA. Alguns clientes da administração e quaisquer aplicações que necessitem de
acesso direto, como o SAP Solution Manager que funciona no local, não podem ligar-se à base de dados
SAP HANA. Para exceções, verifique a secção "Encaminhamento direto para as grandes instâncias HANA".
Se tiver unidades HANA Large Instance implantadas em duas regiões azure diferentes para recuperação de
desastres, as mesmas restrições transitórias de encaminhamento aplicadas no passado. Por outras palavras,
os endereços IP de uma unidade HANA Large Instance numa região (por exemplo, US West) não foram
encaminhados para uma unidade HANA Large Instance implantada noutra região (por exemplo, EUA Leste).
Esta restrição era independente da utilização da rede Azure que espreitava por regiões ou ligava os circuitos
ExpressRoute que ligam unidades HANA Large Instance a redes virtuais. Para uma representação gráfica,
consulte a figura na secção "Use unidades HANA Large Instance em várias regiões." Esta restrição, que veio
com a arquitetura implantada, proibiu o uso imediato da Replicação do Sistema HANA como funcionalidade
de recuperação de desastres. Para alterações recentes, procure a secção "Use as unidades HANA Large
Instance em várias regiões".
As unidades SAP HANA on Azure (Grandes Instâncias) têm um endereço IP atribuído a partir da gama de
endereços IP do servidor que submeteu ao solicitar a implementação de Big Instance HANA. Para mais
informações, consulte a infraestrutura SAP HANA (Grandes Instâncias) e a conectividade no Azure. Este
endereço IP é acessível através das assinaturas e circuito sinuosos do Azure que liga as redes virtuais Azure
às Grandes Instâncias HANA. O endereço IP atribuído a partir do intervalo de endereço ip do servidor é
diretamente atribuído à unidade de hardware. Já não está atribuído através do NAT, como foi o caso nas
primeiras implementações desta solução.
Encaminhamento direto para grandes instâncias HANA
Por predefinição, o encaminhamento transitório não funciona nestes cenários:
Entre unidades HANA Large Instance e uma implantação no local.
Entre o encaminhamento de grandes instâncias hana que são implantados em duas regiões diferentes.
Existem três formas de permitir o encaminhamento transitório nesses cenários:
Um representante inverso para direcionar os dados, de e para. Por exemplo, F5 BIG-IP, NGINX com Traffic
Manager implantado na rede virtual Azure que se conecta a HANA Grandes Instâncias e às instalações como
uma solução virtual de encaminhamento de firewall/tráfego.
Utilizando as regras ipTables num VM Linux para permitir o encaminhamento entre as localizações no local e as
unidades HANA Large Instance, ou entre unidades HANA Large Instance em diferentes regiões. O VM que
executa ipTables precisa de ser implantado na rede virtual Azure que se conecta às grandes instâncias HANA e
às instalações. O VM precisa de ser dimensionado em conformidade, de modo a que a entrada da rede do VM
seja suficiente para o tráfego de rede esperado. Para mais detalhes sobre a largura de banda da rede VM,
consulte o artigo Tamanhos de máquinas virtuais Linux em Azure.
A Firewall Azure seria outra solução para permitir o tráfego direto entre as unidades de instância seletiva hana.
Todo o tráfego destas soluções seria encaminhado através de uma rede virtual Azure e, como tal, o tráfego poderia
ser adicionalmente restringido pelos aparelhos macios utilizados ou pelos Grupos de Segurança da Rede Azure, de
modo a que certos endereços IP ou endereços IP a partir do local pudessem ser bloqueados ou autorizados
explicitamente a aceder a Grandes Instâncias HANA.

NOTE
Esteja ciente de que a implementação e suporte para soluções personalizadas que envolvam aparelhos de rede de terceiros
ou IPTables não é fornecido pela Microsoft. O suporte deve ser prestado pelo fornecedor do componente utilizado ou pelo
integrador.

Rota Expressa Global Alcance


A Microsoft introduziu uma nova funcionalidade chamada ExpressRoute Global Reach. Global Reach pode ser
usado para grandes instâncias HANA em dois cenários:
Permitir o acesso direto a partir das instalações para as suas unidades HANA Large Instance implantadas em
diferentes regiões
Permitir a comunicação direta entre as suas unidades HANA Large Instance implantadas em diferentes regiões
A c e sso d i r e t o a p a r t i r d o l o c a l

Nas regiões azure onde o Global Reach é oferecido, pode solicitar a funcionalidade Global Reach para o seu
circuito ExpressRoute que liga a sua rede no local à rede virtual Azure que se conecta também às suas unidades
HANA Large Instance. Existem algumas implicações de custos para o lado no local do seu circuito ExpressRoute.
Para preços, verifique os preços do Global Reach Add-On. Não existem custos adicionais para si relacionados com
o circuito que liga a unidade(s) hana large instance(s) ao Azure.

IMPORTANT
Em caso de utilização do Global Reach para permitir o acesso direto entre as suas unidades HANA Large Instance e os seus
ativos no local, os dados da rede e o fluxo de controlo não são encaminhados através de redes vir tuais Azure, mas
diretamente entre os routers de intercâmbio empresarial da Microsoft. Como resultado, quaisquer regras NSG ou ASG, ou
qualquer tipo de firewall, NVA ou procuração que implementou numa rede virtual Azure, não estão a ser tocadas. Se
utilizar o ExpressRoute Global Reach para permitir o acesso direto a par tir do local para HANA Grandes
unidades de unidades de instância restrições e permissões para aceder a unidades de grandes instâncias
HANA precisam de ser definidas em firewalls do lado no local

L i g a n d o a s g r a n d e s i n st â n c i a s h a n a e m d i fe r e n t e s r e g i õ e s d e A z u r e

Da mesma forma, como o ExpressRoute Global Reach pode ser usado para ligar no local às unidades HANA Large
Instance, pode ser usado para ligar dois inquilinos hana de grande instância que são implantados para você em
duas regiões diferentes. O isolamento são os circuitos ExpressRoute que os seus inquilinos hana large instance
estão usando para ligar a Azure em ambas as regiões. Não existem taxas adicionais para ligar dois inquilinos hana
de grande instância que são implantados em duas regiões diferentes.

IMPORTANT
O fluxo de dados e o fluxo de controlo do tráfego de rede entre os diferentes inquilinos de instância HANA Grande não serão
encaminhados através de redes azure. Como resultado, não pode utilizar a funcionalidade Azure ou nVAs para impor
restrições de comunicação entre os seus dois inquilinos HANA Large Instances.

Para obter mais detalhes sobre como obter o ExpressRoute Global Reach ativado, leia o documento Ligue uma
rede virtual a grandes instâncias HANA.

Conectividade da Internet da GRANDE Instância HANA


Hana Large Instance não tem conectividade direta na Internet. Como exemplo, esta limitação pode restringir a sua
capacidade de registar a imagem de OS diretamente com o fornecedor de SO. Poderá ter de trabalhar com o
servidor local de gestão de ferramentas de gestão de subscrição do Servidor de Subscrição do Servidor
Empresarial SUSE Linux ou com o Gestor de Assinaturas Red Hat Enterprise Linux.

Encriptação de dados entre VMs e HANA Large Instance


Os dados transferidos entre a HANA Large Instance e os VMs não são encriptados. No entanto, exclusivamente
para a troca entre o lado HANA DBMS e as aplicações baseadas em JDBC/ODBC, pode ativar a encriptação do
tráfego. Para mais informações, consulte esta documentação através da SAP.

Utilize unidades HANA Large Instance em várias regiões


Para perceber as instalações de recuperação de desastres, é preciso ter unidades shana large instance em várias
regiões de Azure. Mesmo com a utilização do Azure [Global Vnet Peering], o encaminhamento transitório por
defeito não está a funcionar entre inquilinos da HANA Large Instance em duas regiões diferentes. No entanto, a
Global Reach abre a via de comunicação entre as unidades hana large instance que você disponibilizou em duas
regiões diferentes. Este cenário de utilização do ExpressRoute Global Reach permite:
Replicação do sistema HANA sem quaisquer proxies ou firewalls adicionais
Copiar cópias de cópias entre unidades HANA Large Instance em duas regiões diferentes para executar cópias
do sistema ou atualizações do sistema

O número mostra como as diferentes redes virtuais em ambas as regiões estão ligadas a dois circuitos
expressroute diferentes que são usados para ligar ao SAP HANA em Azure (Grandes Instâncias) em ambas as
regiões de Azure (linhas cinzentas). A razão para estas duas ligações cruzadas é proteger de uma interrupção dos
EEE de ambos os lados. O fluxo de comunicação entre as duas redes virtuais nas duas regiões de Azure deverá ser
tratado sobre o epeering global das duas redes virtuais nas duas regiões diferentes (linha pontilhada azul). A linha
vermelha espessa descreve a conexão ExpressRoute Global Reach, que permite que as unidades hana large
instance dos seus inquilinos em duas regiões diferentes se comuniquem entre si.

IMPORTANT
Se utilizou vários circuitos ExpressRoute, as predespesas do AS Path e as definições de BGP de preferência local devem ser
utilizadas para garantir o encaminhamento adequado do tráfego.

Passos seguintes
Consulte a arquitetura de armazenamento SAP HANA (Grandes Instâncias)
Sap HANA (Grandes Instâncias) arquitetura de
armazenamento
21/06/2020 • 14 minutes to read • Edit Online

O layout de armazenamento para SAP HANA em Azure (Grandes Instâncias) é configurado pela SAP HANA no
modelo clássico de implementação de acordo com as diretrizes recomendadas pela SAP. As diretrizes estão
documentadas nos requisitos de armazenamento SAP HANA.
A HANA Large Instance da classe Tipo I vem com quatro vezes o volume de memória como volume de
armazenamento. Para a classe tipo II das unidades HANA Large Instance, o armazenamento não é quatro vezes
mais. As unidades vêm com um volume destinado a armazenar cópias de segurança de registo de transações
HANA. Para obter mais informações, consulte instalar e configurar o SAP HANA (Grandes Instâncias) no Azure.
Consulte a tabela seguinte em termos de atribuição de armazenamento. A tabela lista a capacidade bruta para os
diferentes volumes fornecidos com as diferentes unidades HANA Large Instance.

H A N A GRA N DE H A N A / C O M PA RT IL H
IN STÂ N C IA SK U H A N A / DA DO S H A N A / LO G A DO H A N A / LO GB A C K UP S

S72 1.280 GB 512 GB 768 GB 512 GB

S72m 3.328 GB 768 GB 1.280 GB 768 GB

S96 1.280 GB 512 GB 768 GB 512 GB

S192 4.608 GB 1.024 GB 1,536 GB 1.024 GB

S192m 11.520 GB 1,536 GB 1.792 GB 1,536 GB

S192xm 11.520 GB 1,536 GB 1.792 GB 1,536 GB

S384 11.520 GB 1,536 GB 1.792 GB 1,536 GB

S384m 12.000 GB 2.050 GB 2.050 GB 2.040 GB

S384xm 16.000 GB 2.050 GB 2.050 GB 2.040 GB

S384xxm 20.000 GB 3.100 GB 2.050 GB 3.100 GB

S576m 20.000 GB 3.100 GB 2.050 GB 3.100 GB

S576xm 31.744 GB 4.096 GB 2.048 GB 4.096 GB

S768m 28.000 GB 3.100 GB 2.050 GB 3.100 GB

S768xm 40.960 GB 6,144 GB 4.096 GB 6,144 GB

S960m 36.000 GB 4.100 GB 2.050 GB 4.100 GB


H A N A GRA N DE H A N A / C O M PA RT IL H
IN STÂ N C IA SK U H A N A / DA DO S H A N A / LO G A DO H A N A / LO GB A C K UP S

S896m 33.792 GB 512 GB 1.024 GB 512 GB

SkUs mais recentes de HANA Large Instances são entregues com configurações de armazenamento como:

H A N A GRA N DE H A N A / C O M PA RT IL H
IN STÂ N C IA SK U H A N A / DA DO S H A N A / LO G A DO H A N A / LO GB A C K UP S

S224 4.224 GB 512 GB 1.024 GB 512 GB

S224oo 6,336 GB 512 GB 1.024 GB 512 GB

S224m 8.448 GB 512 GB 1.024 GB 512 GB

S224om 8.448 GB 512 GB 1.024 GB 512 GB

S224ooo 10.560 GB 512 GB 1.024 GB 512 GB

S224oom 12,672 GB 512 GB 1.024 GB 512 GB

S448 8.448 GB 512 GB 1.024 GB 512 GB

S448oo 12,672 GB 512 GB 1.024 GB 512 GB

S448m 16.896 GB 512 GB 1.024 GB 512 GB

S448om 16.896 GB 512 GB 1.024 GB 512 GB

S448ooo 21,120 GB 512 GB 1.024 GB 512 GB

S448oom 25.344 GB 512 GB 1.024 GB 512 GB

S672 12,672 GB 512 GB 1.024 GB 512 GB

S672oo 19.008 GB 512 GB 1.024 GB 512 GB

S672m 25.344 GB 512 GB 1.024 GB 512 GB

S672om 25.344 GB 512 GB 1.024 GB 512 GB

S672ooo 31.680 GB 512 GB 1.024 GB 512 GB

S672oom 38.016 GB 512 GB 1.024 GB 512 GB

S896 16.896 GB 512 GB 1.024 GB 512 GB

S896oo 25.344 GB 512 GB 1.024 GB 512 GB

S896om 33.792 GB 512 GB 1.024 GB 512 GB

S896ooo 42,240 GB 512 GB 1.024 GB 512 GB


H A N A GRA N DE H A N A / C O M PA RT IL H
IN STÂ N C IA SK U H A N A / DA DO S H A N A / LO G A DO H A N A / LO GB A C K UP S

S896oom 50.688 GB 512 GB 1.024 GB 512 GB

Os volumes implantados reais podem variar em função da implantação e da ferramenta que é usada para mostrar
os tamanhos de volume.
Se subdividir um SKU de Grande Instância HANA, alguns exemplos de possíveis peças de divisão podem parecer:

PA RT IÇ Ã O DE H A N A / C O M PA RT IL H
M EM Ó RIA EM GB H A N A / DA DO S H A N A / LO G A DO H A N A / LO G/ B A C K UP

256 400 GB 160 GB 304 GB 160 GB

512 768 GB 384 GB 512 GB 384 GB

768 1.280 GB 512 GB 768 GB 512 GB

1,024 1.792 GB 640 GB 1.024 GB 640 GB

1,536 3.328 GB 768 GB 1.280 GB 768 GB

Estes tamanhos são números de volume bruto que podem variar ligeiramente com base na implementação e nas
ferramentas usadas para olhar para os volumes. Há também outros tamanhos de partição, tais como 2,5 TB. Estes
tamanhos de armazenamento são calculados com uma fórmula semelhante à utilizada para as divisórias
anteriores. O termo "partições" não significa que o sistema operativo, a memória ou os recursos da CPU sejam de
alguma forma divididos. Indica divisórias de armazenamento para as diferentes instâncias HANA que você pode
querer implementar em uma única unidade HANA Large Instance.
Pode precisar de mais armazenamento. Pode adicionar armazenamento comprando armazenamento adicional em
unidades de 1-TB. Este armazenamento adicional pode ser adicionado como volume adicional. Também pode ser
utilizado para estender um ou mais dos volumes existentes. Não é possível diminuir os tamanhos dos volumes tal
como originalmente implantados e maioritariamente documentados pelas tabelas anteriores. Também não é
possível alterar os nomes dos volumes ou dos nomes de montagem. Os volumes de armazenamento previamente
descritos são anexados às unidades HANA Large Instance como volumes NFS4.
Pode utilizar instantâneos de armazenamento para fins de backup e restauro e recuperação de desastres. Para
obter mais informações, consulte SAP HANA (Grandes Instâncias) alta disponibilidade e recuperação de desastres
em Azure.
Consulte cenários apoiados pelo HLI para obter detalhes do layout de armazenamento para o seu cenário.

Executar vários casos SAP HANA em uma unidade HANA Large


Instance
É possível hospedar mais de uma instância sap hana ativa em unidades de HANA Large Instance. Para fornecer as
capacidades de armazenamento de instantâneos e recuperação de desastres, tal configuração requer um volume
definido por instância. Atualmente, as unidades HANA Large Instance podem ser subdivididas da seguinte forma:
S72, S72m, S96, S144, S192 : Em incrementos de 256 GB, com 256 GB a unidade inicial mais pequena.
Diferentes incrementos tais como 256 GB e 512 GB podem ser combinados ao máximo da memória da
unidade.
S144m e S192m : Em incrementos de 256 GB, com 512 GB a unidade mais pequena. Diferentes incrementos
tais como 512 GB e 768 GB podem ser combinados ao máximo da memória da unidade.
Classe Tipo II : Em incrementos de 512 GB, com a unidade inicial mais pequena de 2 TB. Diferentes
incrementos tais como 512 GB, 1 TB e 1,5 TB podem ser combinados ao máximo da memória da unidade.
Alguns exemplos de execução de várias instâncias SAP HANA podem parecer os seguintes.

TA M A N H O DO TA M A N H O S C O M VÁ RIA S
SK U TA M A N H O DA M EM Ó RIA A RM A Z EN A M EN TO B A SES DE DA DO S

S72 768 GB 3 TB 1x768-GB HANA instância


ou instância de 1x512-GB +
instância de 1x256-GB
ou 3x256-GB instâncias

S72m 1,5 TB 6 TB 3x512GB de HANA


instâncias
ou instância 1x512-GB +
instância 1x1-TB
ou 6x256-GB instâncias
ou 1x1.5-TB instância

S192m 4 TB 16 TB 8x512-GB instâncias


ou 4x1-TB instâncias
ou instâncias 4x512-GB +
instâncias 2x1-TB
ou instâncias 4x768-GB +
instâncias de 2x512-GB
ou 1x4-TB instância

S384xm 8 TB 22 TB 4x2-TB instâncias


ou 2x4-TB instâncias
ou 2x3-TB instâncias + 1x2-
TB instâncias
ou 2x2.5-TB instâncias +
1x3-TB instâncias
ou 1x8-TB instância

Há outras variações também.

Encriptação de dados em repouso


O armazenamento utilizado para a HANA Large Instance utiliza encriptação transparente para os dados, uma vez
que está armazenado nos discos desde finais do ano de 2018. Em implementações anteriores, pode optar por
encriptar os volumes. Se decidir contra essa opção, pode solicitar a encriptação dos volumes. A mudança de
volumes não encriptados para volumes encriptados é transparente e não requer tempo de inatividade.
Com a classe tipo I de SKUs, o volume em que a bota LUN está armazenada é encriptado. Na Revisão 3 selos
HANA Large Instance, utilizando a classe tipo II de SKUs de HANA Large Instance, é necessário encriptar o botão
LUN com métodos DE. Na Revisão 4 selos HANA Large Instance, utilizando unidades do Tipo II o volume da bota
LUN é armazenado e é encriptado em repouso por padrão também.

Definições necessárias para casos de HANA maiores em HANA Grandes


Instâncias
O armazenamento utilizado em HANA Large Instances tem uma limitação do tamanho do ficheiro. A limitação do
tamanho é de 16 TB por ficheiro. Ao contrário das limitações de tamanho de ficheiro nos sistemas de ficheiros
EXT3, a HANA não está consciente implicitamente da limitação de armazenamento imposta pelo armazenamento
HANA Large Instances. Como resultado, a HANA não criará automaticamente um novo ficheiro de dados quando o
limite de tamanho do ficheiro de 16 TB for atingido. À medida que a HANA tenta aumentar o ficheiro para além de
16 TB, a HANA reportará erros e o servidor de índice falhará no final.

IMPORTANT
Para evitar que a HANA tente cultivar ficheiros de dados para além do limite de tamanho de ficheiro de 16 TB do
armazenamento HANA Large Instance, é necessário definir os seguintes parâmetros no ficheiro de configuração global.ini de
HANA
datavolume_striping=verdade
datavolume_striping_size_gb = 15000
Consulte também a nota SAP #2400005
Esteja atento à nota SAP #2631285

Próximos passos
Consulte cenários apoiados para HANA Grandes Instâncias
Cenários suportados para grandes instâncias HANA
29/04/2020 • 53 minutes to read • Edit Online

Este artigo descreve os cenários suportados e detalhes da arquitetura para hana grandes instâncias (HLI).

NOTE
Se o seu cenário exigido não for mencionado neste artigo, contacte a equipa de Gestão de Serviços da Microsoft para
avaliar os seus requisitos. Antes de configurar a unidade HLI, valide o design com o SAP ou o seu parceiro de
implementação de serviço.

Termos e definições
Vamos entender os termos e definições que são usados neste artigo:
SID : Um identificador de sistema para o sistema HANA
HLI : Hana Grandes Instâncias
DR : Recuperação de desastres
DR normal : Uma configuração do sistema com um recurso dedicado apenas para fins de DR
DR multiusos : Um sistema de dr-site configurado para usar um ambiente de não produção ao lado de uma
instância de produção que está configurada para um evento DR
Único SID : Um sistema com uma instância instalada
Multi-SID : Um sistema com múltiplas instâncias configuradas; também chamado de ambiente MCOS
HSR : Replicação do sistema SAP HANA

Descrição geral
A HANA Large Instances apoia uma variedade de arquiteturas para ajudá-lo a realizar os seus requisitos de
negócio. As seguintes secções cobrem os cenários arquitetónicos e os seus detalhes de configuração.
O design de arquitetura derivado é puramente do ponto de vista da infraestrutura, e você deve consultar sAP ou
seus parceiros de implementação para a implementação HANA. Se os seus cenários não estiverem listados neste
artigo, contacte a equipa da conta da Microsoft para rever a arquitetura e obtenha uma solução para si.

NOTE
Estas arquiteturas estão totalmente em conformidade com o design de Integração de Dados Personalizado (TDI) e
apoiadas pela SAP.

Este artigo descreve os detalhes dos dois componentes em cada arquitetura apoiada:
Ethernet
Armazenamento
Ethernet
Cada servidor aprovisionado vem reconfigurado com conjuntos de interfaces Ethernet. As interfaces Ethernet
configuradas em cada unidade HLI são categorizadas em quatro tipos:
R: Utilizado para ou pelo acesso ao cliente.
B: Utilizado para a comunicação nó-ao-nó. Esta interface está configurada em todos os servidores
(independentemente da topologia solicitada), mas usada apenas para cenários de escala.
C: Utilizado para a conectividade nó-a-armazenamento.
D: Utilizado para a ligação do dispositivo nó-a-iSCSI para a configuração STONITH. Esta interface só é
configurada quando é solicitada uma configuração HSR.

IN T ERFA C E LÓ GIC A C A SO DE
N IC T IP O SK U N O M E C O M SUSE O S N O M E C O M RH EL O S UT IL IZ A Ç Ã O

A TIPO I eth0.inquilino eno1.inquilino Cliente-a-HLI

B TIPO I eth2.inquilino eno3.inquilino Nó-a-nó

C TIPO I eth1.inquilino eno2.inquilino Nó-a-


armazenamento

D TIPO I eth4.inquilino eno4.inquilino STONITH

A TIPO II vlan<inquilinoNo> team0.inquilino Cliente-a-HLI

B TIPO II vlan<inquilinoNo+2> team0.tenant+2 Nó-a-nó

C TIPO II vlan<inquilinoNo+1> team0.tenant+1 Nó-a-


armazenamento

D TIPO II vlan<inquilinoNo+3> team0.tenant+3 STONITH

Escolha a interface com base na topologia que está configurada na unidade HLI. Por exemplo, a interface "B" é
configurada para a comunicação nó-ao-nó, o que é útil quando se tem uma topologia de escala configurada. Esta
interface não é usada para configurações de nó simples, escala-up. Para obter mais informações sobre o uso da
interface, reveja os cenários necessários (mais tarde neste artigo).
Se necessário, pode definir cartões NIC adicionais por conta própria. No entanto, as configurações dos NICs
existentes não podem ser alteradas.

NOTE
Pode encontrar interfaces adicionais que sejam interfaces físicas ou ligação. Deve considerar apenas as interfaces
anteriormente mencionadas para o seu caso de utilização. Qualquer outro pode ser ignorado.

A distribuição de unidades com dois endereços IP atribuídos deve parecer:


Ethernet "A" deve ter um endereço IP atribuído dentro da gama de endereços IP do servidor que
submeteu à Microsoft. Este endereço IP deve ser mantido no diretório /etc/anfitriões do SO.
Ethernet "C" deve ter um endereço IP atribuído que é usado para comunicação com NFS. Este endereço
não precisa de ser mantido no diretório etc/hospedeiro supor o tráfego por exemplo no seio do inquilino.
Para a replicação do sistema HANA ou a implementação em escala HANA, não é adequada uma configuração da
lâmina com dois endereços IP atribuídos. Se tiver apenas dois endereços IP atribuídos e pretender implementar
tal configuração, contacte a SAP HANA na Azure Service Management. Podem atribuir-lhe um terceiro endereço
IP num terceiro VLAN. Para as unidades HANA Large Instances com três endereços IP atribuídos em três portas
NIC, aplicam-se as seguintes regras de utilização:
Ethernet "A" deve ter um endereço IP atribuído fora da gama de endereços IP do servidor que submeteu à
Microsoft. Este endereço IP não deve ser mantido no diretório etc/hospedeiro do SO.
A Ethernet "B" deve ser mantida exclusivamente no diretório etc/anfitrião para comunicação entre as
várias instâncias. Estes são os endereços IP a manter nas configurações HANA à escala, uma vez que os
endereços IP que hana utiliza para a configuração do nó inter-nó.
Ethernet "C" deve ter um endereço IP atribuído que é usado para comunicação ao armazenamento NFS.
Este tipo de endereço não deve ser mantido no diretório etc/anfitrião.
A Ethernet "D" deve ser utilizada exclusivamente para acesso a dispositivos STONITH para Pacemaker. Esta
interface é necessária quando configura rés em replicação do sistema HANA e pretende obter falhas
automáticas no sistema operativo utilizando um dispositivo baseado em SBD.
Armazenamento
O armazenamento é reconfigurado com base na topologia solicitada. Os tamanhos de volume e os pontos de
montagem variam consoante o número de servidores, o número de SKUs e a topologia configurada. Para mais
informações, reveja os cenários necessários (mais tarde neste artigo). Se necessitar de mais armazenamento,
pode comprá-lo em incrementos de 1-TB.

NOTE
O ponto de montagem /usr/seiva/<SID> é uma ligação simbólica ao ponto de montagem /hana/compartilhado.

Cenários suportados
Os diagramas de arquitetura nas secções seguintes utilizam as seguintes notações:
Aqui estão os cenários apoiados:
Nó único com um SID
McOS de nó único
Nó único com DR (normal)
Nó único com DR (multiuso)
HSR com STONITH
HSR com DR (normal/multiusos)
Falha automática do anfitrião (1+1)
Escala-out com standby
Escala-out sem espera
Escala com DR

Nó único com um SID


Esta topologia suporta um nó numa configuração de escala-up com um SID.
Diagrama da arquitetura
Ethernet
As seguintes interfaces de rede são reconfiguradas:

IN T ERFA C E LÓ GIC A C A SO DE
N IC T IP O SK U N O M E C O M SUSE O S N O M E C O M RH EL O S UT IL IZ A Ç Ã O

A TIPO I eth0.inquilino eno1.inquilino Cliente-a-HLI

B TIPO I eth2.inquilino eno3.inquilino Configurado, mas


não em uso
IN T ERFA C E LÓ GIC A C A SO DE
N IC T IP O SK U N O M E C O M SUSE O S N O M E C O M RH EL O S UT IL IZ A Ç Ã O

C TIPO I eth1.inquilino eno2.inquilino Nó-a-


armazenamento

D TIPO I eth4.inquilino eno4.inquilino Configurado, mas


não em uso

A TIPO II vlan<inquilinoNo> team0.inquilino Cliente-a-HLI

B TIPO II vlan<inquilinoNo+2> team0.tenant+2 Configurado, mas


não em uso

C TIPO II vlan<inquilinoNo+1> team0.tenant+1 Nó-a-


armazenamento

D TIPO II vlan<inquilinoNo+3> team0.tenant+3 Configurado, mas


não em uso

Armazenamento
Os seguintes pontos de montagem são pré-configurados:

P O N TO DE M O N TA GEM C A SO DE UT IL IZ A Ç Ã O

/hana/shared/SID Instalação HANA

/hana/data/SID/mnt00001 Instalação de ficheiros de dados

/hana/log/SID/mnt00001 Instalação de ficheiros de registo

/hana/logbackups/SID Registos de redo

Considerações principais
/usr/sap/SID é uma ligação simbólica para /hana/shared/SID.

McOS de nó único
Esta topologia suporta um nó numa configuração de escala-up com múltiplos SIDs.
Diagrama da arquitetura
Ethernet
As seguintes interfaces de rede são reconfiguradas:

IN T ERFA C E LÓ GIC A C A SO DE
N IC T IP O SK U N O M E C O M SUSE O S N O M E C O M RH EL O S UT IL IZ A Ç Ã O

A TIPO I eth0.inquilino eno1.inquilino Cliente-a-HLI

B TIPO I eth2.inquilino eno3.inquilino Configurado, mas


não em uso

C TIPO I eth1.inquilino eno2.inquilino Nó-a-


armazenamento

D TIPO I eth4.inquilino eno4.inquilino Configurado, mas


não em uso

A TIPO II vlan<inquilinoNo> team0.inquilino Cliente-a-HLI


IN T ERFA C E LÓ GIC A C A SO DE
N IC T IP O SK U N O M E C O M SUSE O S N O M E C O M RH EL O S UT IL IZ A Ç Ã O

B TIPO II vlan<inquilinoNo+2> team0.tenant+2 Configurado, mas


não em uso

C TIPO II vlan<inquilinoNo+1> team0.tenant+1 Nó-a-


armazenamento

D TIPO II vlan<inquilinoNo+3> team0.tenant+3 Configurado, mas


não em uso

Armazenamento
Os seguintes pontos de montagem são pré-configurados:

P O N TO DE M O N TA GEM C A SO DE UT IL IZ A Ç Ã O

/hana/shared/SID1 Instalação HANA para SID1

/hana/data/SID1/mnt00001 Instalação de ficheiros de dados para SID1

/hana/log/SID1/mnt00001 Instalação de ficheiros de registo para SID1

/hana/logbackups/SID1 Registos de redo para SID1

/hana/shared/SID2 Instalação HANA para SID2

/hana/data/SID2/mnt00001 Instalação de ficheiros de dados para SID2

/hana/log/SID2/mnt00001 Instalação de ficheiros de registo para SID2

/hana/logbackups/SID2 Registos de redo para SID2

Considerações principais
/usr/sap/SID é uma ligação simbólica para /hana/shared/SID.
A distribuição do tamanho do volume baseia-se no tamanho da base de dados na memória. Para saber que
tamanhos de base de dados na memória são suportados num ambiente multi-SID, consulte a visão geral e a
arquitetura.

Nó único com DR usando replicação de armazenamento


Esta topologia suporta um nó numa configuração de escala-up com um ou vários SIDs, com replicação baseada
em armazenamento para o site DR para um SID primário. No diagrama, apenas um sistema de SID único é
representado no local primário, mas os sistemas MCOS também são suportados.
Diagrama da arquitetura
Ethernet
As seguintes interfaces de rede são reconfiguradas:

IN T ERFA C E LÓ GIC A C A SO DE
N IC T IP O SK U N O M E C O M SUSE O S N O M E C O M RH EL O S UT IL IZ A Ç Ã O

A TIPO I eth0.inquilino eno1.inquilino Cliente-a-HLI

B TIPO I eth2.inquilino eno3.inquilino Configurado, mas


não em uso

C TIPO I eth1.inquilino eno2.inquilino Nó-a-


armazenamento

D TIPO I eth4.inquilino eno4.inquilino Configurado, mas


não em uso

A TIPO II vlan<inquilinoNo> team0.inquilino Cliente-a-HLI

B TIPO II vlan<inquilinoNo+2> team0.tenant+2 Configurado, mas


não em uso

C TIPO II vlan<inquilinoNo+1> team0.tenant+1 Nó-a-


armazenamento

D TIPO II vlan<inquilinoNo+3> team0.tenant+3 Configurado, mas


não em uso

Armazenamento
Os seguintes pontos de montagem são pré-configurados:
P O N TO DE M O N TA GEM C A SO DE UT IL IZ A Ç Ã O

/hana/shared/SID Instalação HANA para SID

/hana/data/SID/mnt00001 Instalação de ficheiros de dados para SID

/hana/log/SID/mnt00001 Instalação de ficheiros de registo para SID

/hana/logbackups/SID Registos de redo para SID

Considerações principais
/usr/sap/SID é uma ligação simbólica para /hana/shared/SID.
Para MCOS: A distribuição do tamanho do volume baseia-se no tamanho da base de dados na memória. Para
saber que tamanhos de base de dados na memória são suportados num ambiente multi-SID, consulte a visão
geral e a arquitetura.
No local DR: Os volumes e os pontos de montagem estão configurados (marcados como "Necessários para a
instalação HANA") para a instalação da instância HANA de produção na unidade DR HLI.
No site dr: Os dados, cópias de segurança e volumes partilhados (marcados como "Replicação de
Armazenamento") são replicados através de instantâneos do local de produção. Estes volumes são montados
apenas durante a falha. Para mais informações, consulte o procedimento de falha de recuperação de
desastres.
O volume de arranque da classe SKU Type I é replicado para o nó DR.

Nó único com DR (multiuso) utilizando replicação de armazenamento


Esta topologia suporta um nó numa configuração de escala-up com um ou vários SIDs, com replicação baseada
em armazenamento para o site DR para um SID primário. No diagrama, apenas um sistema de SID único é
representado no local primário, mas os sistemas multi-SID (MCOS) também são suportados. No local dr, a
unidade HLI é utilizada para a instância qA enquanto as operações de produção estão a decorrer a partir do local
principal. Durante a failover DR (ou teste de failover), a instância qA no local dr é retirada.
Diagrama da arquitetura
Ethernet
As seguintes interfaces de rede são reconfiguradas:

IN T ERFA C E LÓ GIC A C A SO DE
N IC T IP O SK U N O M E C O M SUSE O S N O M E C O M RH EL O S UT IL IZ A Ç Ã O

A TIPO I eth0.inquilino eno1.inquilino Cliente-a-HLI

B TIPO I eth2.inquilino eno3.inquilino Configurado, mas


não em uso

C TIPO I eth1.inquilino eno2.inquilino Nó-a-


armazenamento

D TIPO I eth4.inquilino eno4.inquilino Configurado, mas


não em uso

A TIPO II vlan<inquilinoNo> team0.inquilino Cliente-a-HLI

B TIPO II vlan<inquilinoNo+2> team0.tenant+2 Configurado, mas


não em uso

C TIPO II vlan<inquilinoNo+1> team0.tenant+1 Nó-a-


armazenamento

D TIPO II vlan<inquilinoNo+3> team0.tenant+3 Configurado, mas


não em uso

Armazenamento
Os seguintes pontos de montagem são pré-configurados:
P O N TO DE M O N TA GEM C A SO DE UT IL IZ A Ç Ã O

No local principal

/hana/shared/SID Instalação HANA para produção SID

/hana/data/SID/mnt00001 Instalação de ficheiros de dados para produção SID

/hana/log/SID/mnt00001 Instalação de ficheiros de registo para produção SID

/hana/logbackups/SID Registos de redo para produção SID

No site da DR

/hana/shared/SID Instalação HANA para produção SID

/hana/data/SID/mnt00001 Instalação de ficheiros de dados para produção SID

/hana/log/SID/mnt00001 Instalação de ficheiros de registo para produção SID

/hana/shared/QA-SID Instalação HANA para QA SID

/hana/data/QA-SID/mnt00001 Instalação de ficheiros de dados para QA SID

/hana/log/QA-SID/mnt00001 Instalação de ficheiros de registo para QA SID

/hana/logbackups/QA-SID Registos de redo para QA SID

Considerações principais
/usr/sap/SID é uma ligação simbólica para /hana/shared/SID.
Para MCOS: A distribuição do tamanho do volume baseia-se no tamanho da base de dados na memória. Para
saber que tamanhos de base de dados na memória são suportados num ambiente multi-SID, consulte a visão
geral e a arquitetura.
No local DR: Os volumes e os pontos de montagem estão configurados (marcados como "Necessários para a
instalação HANA") para a instalação da instância HANA de produção na unidade DR HLI.
No site dr: Os dados, cópias de segurança e volumes partilhados (marcados como "Replicação de
Armazenamento") são replicados através de instantâneos do local de produção. Estes volumes são montados
apenas durante a falha. Para mais informações, consulte o procedimento de falha de recuperação de
desastres.
No site dr: Os dados, cópias de segurança de registo, registo e volumes partilhados para QA (marcadocomo
"instalação de instância QA") estão configurados para a instalação da instância QA.
O volume de arranque da classe SKU Type I é replicado para o nó DR.

HSR com STONITH para alta disponibilidade


Esta topologia suporta dois nós para a configuração de replicação do sistema HANA. Esta configuração é
suportada apenas para instâncias únicas de HANA num nó. Isto significa que os cenários do MCOS não são
apoiados.
NOTE
A partir de dezembro de 2019, esta arquitetura é suportada apenas para o sistema operativo SUSE.

Diagrama da arquitetura

Ethernet
As seguintes interfaces de rede são reconfiguradas:

IN T ERFA C E LÓ GIC A C A SO DE
N IC T IP O SK U N O M E C O M SUSE O S N O M E C O M RH EL O S UT IL IZ A Ç Ã O

A TIPO I eth0.inquilino eno1.inquilino Cliente-a-HLI

B TIPO I eth2.inquilino eno3.inquilino Configurado, mas


não em uso

C TIPO I eth1.inquilino eno2.inquilino Nó-a-


armazenamento

D TIPO I eth4.inquilino eno4.inquilino Usado para STONITH


IN T ERFA C E LÓ GIC A C A SO DE
N IC T IP O SK U N O M E C O M SUSE O S N O M E C O M RH EL O S UT IL IZ A Ç Ã O

A TIPO II vlan<inquilinoNo> team0.inquilino Cliente-a-HLI

B TIPO II vlan<inquilinoNo+2> team0.tenant+2 Configurado, mas


não em uso

C TIPO II vlan<inquilinoNo+1> team0.tenant+1 Nó-a-


armazenamento

D TIPO II vlan<inquilinoNo+3> team0.tenant+3 Usado para STONITH

Armazenamento
Os seguintes pontos de montagem são pré-configurados:

P O N TO DE M O N TA GEM C A SO DE UT IL IZ A Ç Ã O

No nó principal

/hana/shared/SID Instalação HANA para produção SID

/hana/data/SID/mnt00001 Instalação de ficheiros de dados para produção SID

/hana/log/SID/mnt00001 Instalação de ficheiros de registo para produção SID

/hana/logbackups/SID Registos de redo para produção SID

No nó secundário

/hana/shared/SID Instalação HANA para SID secundário

/hana/data/SID/mnt00001 Instalação de ficheiros de dados para SID secundário

/hana/log/SID/mnt00001 Instalação de ficheiros de registo para SID secundário

/hana/logbackups/SID Registos de redo para SID secundário

Considerações principais
/usr/sap/SID é uma ligação simbólica para /hana/shared/SID.
Para MCOS: A distribuição do tamanho do volume baseia-se no tamanho da base de dados na memória. Para
saber que tamanhos de base de dados na memória são suportados num ambiente multi-SID, consulte a visão
geral e a arquitetura.
Um SBD está configurado para a configuração STONITH. No entanto, a utilização do STONITH é opcional.

Alta disponibilidade com HSR e DR com replicação de armazenamento


Esta topologia suporta dois nós para a configuração de replicação do sistema HANA. Tanto os DRs normais como
multiusos são suportados. Estas configurações são suportadas apenas para instâncias únicas de HANA num nó.
Isto significa que os cenários do MCOS não são suportados com estas configurações.
No diagrama, um cenário multiusos é representado no local dr, onde a unidade HLI é usada para a instância qA
enquanto as operações de produção estão em execução a partir do local principal. Durante a failover DR (ou teste
de failover), a instância qA no local dr é retirada.
Diagrama da arquitetura

Ethernet
As seguintes interfaces de rede são reconfiguradas:

IN T ERFA C E LÓ GIC A C A SO DE
N IC T IP O SK U N O M E C O M SUSE O S N O M E C O M RH EL O S UT IL IZ A Ç Ã O

A TIPO I eth0.inquilino eno1.inquilino Cliente-a-HLI

B TIPO I eth2.inquilino eno3.inquilino Configurado, mas


não em uso

C TIPO I eth1.inquilino eno2.inquilino Nó-a-


armazenamento

D TIPO I eth4.inquilino eno4.inquilino Usado para STONITH

A TIPO II vlan<inquilinoNo> team0.inquilino Cliente-a-HLI

B TIPO II vlan<inquilinoNo+2> team0.tenant+2 Configurado, mas


não em uso

C TIPO II vlan<inquilinoNo+1> team0.tenant+1 Nó-a-


armazenamento

D TIPO II vlan<inquilinoNo+3> team0.tenant+3 Usado para STONITH

Armazenamento
Os seguintes pontos de montagem são pré-configurados:

P O N TO DE M O N TA GEM C A SO DE UT IL IZ A Ç Ã O

No nó principal no local principal


P O N TO DE M O N TA GEM C A SO DE UT IL IZ A Ç Ã O

/hana/shared/SID Instalação HANA para produção SID

/hana/data/SID/mnt00001 Instalação de ficheiros de dados para produção SID

/hana/log/SID/mnt00001 Instalação de ficheiros de registo para produção SID

/hana/logbackups/SID Registos de redo para produção SID

No nó secundário no local primário

/hana/shared/SID Instalação HANA para SID secundário

/hana/data/SID/mnt00001 Instalação de ficheiros de dados para SID secundário

/hana/log/SID/mnt00001 Instalação de ficheiros de registo para SID secundário

/hana/logbackups/SID Registos de redo para SID secundário

No site da DR

/hana/shared/SID Instalação HANA para produção SID

/hana/data/SID/mnt00001 Instalação de ficheiros de dados para produção SID

/hana/log/SID/mnt00001 Instalação de ficheiros de registo para produção SID

/hana/shared/QA-SID Instalação HANA para QA SID

/hana/data/QA-SID/mnt00001 Instalação de ficheiros de dados para QA SID

/hana/log/QA-SID/mnt00001 Instalação de ficheiros de registo para QA SID

/hana/logbackups/QA-SID Registos de redo para QA SID

Considerações principais
/usr/sap/SID é uma ligação simbólica para /hana/shared/SID.
Para MCOS: A distribuição do tamanho do volume baseia-se no tamanho da base de dados na memória. Para
saber que tamanhos de base de dados na memória são suportados num ambiente multi-SID, consulte a visão
geral e a arquitetura.
Um SBD está configurado para a configuração STONITH. No entanto, a utilização do STONITH é opcional.
No local DR: São necessários dois conjuntos de volumes de armazenamento para a replicação do nó primário
e secundário.
No local DR: Os volumes e os pontos de montagem estão configurados (marcados como "Necessários para a
instalação HANA") para a instalação da instância HANA de produção na unidade DR HLI.
No site dr: Os dados, cópias de segurança e volumes partilhados (marcados como "Replicação de
Armazenamento") são replicados através de instantâneos do local de produção. Estes volumes são montados
apenas durante a falha. Para mais informações, consulte o procedimento de falha de recuperação de
desastres.
No site dr: Os dados, cópias de segurança de registo, registo e volumes partilhados para QA (marcadocomo
"instalação de instância QA") estão configurados para a instalação da instância QA.
O volume de arranque da classe SKU Type I é replicado para o nó DR.

Falha automática do anfitrião (1+1)


Esta topologia suporta dois nós numa configuração de falha automática de hospedeiro. Há um nó com um papel
de mestre/trabalhador e outro como um standby. A SAP apoia este cenário apenas para S/4 HANA. Para mais
informações, consulte a nota OSS 2408419 - SAP S/4HANA - Suporte multi-nó.
Diagrama da arquitetura

Ethernet
As seguintes interfaces de rede são reconfiguradas:
IN T ERFA C E LÓ GIC A C A SO DE
N IC T IP O SK U N O M E C O M SUSE O S N O M E C O M RH EL O S UT IL IZ A Ç Ã O

A TIPO I eth0.inquilino eno1.inquilino Cliente-a-HLI

B TIPO I eth2.inquilino eno3.inquilino Comunicação nó-ao-


C TIPO I eth1.inquilino eno2.inquilino Nó-a-


armazenamento

D TIPO I eth4.inquilino eno4.inquilino Configurado, mas


não em uso

A TIPO II vlan<inquilinoNo> team0.inquilino Cliente-a-HLI

B TIPO II vlan<inquilinoNo+2> team0.tenant+2 Comunicação nó-ao-


C TIPO II vlan<inquilinoNo+1> team0.tenant+1 Nó-a-


armazenamento

D TIPO II vlan<inquilinoNo+3> team0.tenant+3 Configurado, mas


não em uso

Armazenamento
Os seguintes pontos de montagem são pré-configurados:

P O N TO DE M O N TA GEM C A SO DE UT IL IZ A Ç Ã O

Nos narizes mestre e de espera

/hana/compartilhado Instalação HANA para produção SID

/hana/data/SID/mnt00001 Instalação de ficheiros de dados para produção SID

/hana/log/SID/mnt00001 Instalação de ficheiros de registo para produção SID

/hana/logbackups/SID Registos de redo para produção SID

Considerações principais
/usr/sap/SID é uma ligação simbólica para /hana/shared/SID.
Em modo de espera: Os volumes e os pontos de montagem estão configurados (marcados como
"Necessários para a instalação HANA") para a instalação da instância HANA na unidade de espera.

Escala-out com standby


Esta topologia suporta vários nós numa configuração de escala para fora. Há um nó com um papel principal, um
ou mais nós com um papel de trabalhador, e um ou mais nós como standby. No entanto, só pode haver um nó
mestre em qualquer ponto do tempo.
Diagrama da arquitetura
Ethernet
As seguintes interfaces de rede são reconfiguradas:

IN T ERFA C E LÓ GIC A C A SO DE
N IC T IP O SK U N O M E C O M SUSE O S N O M E C O M RH EL O S UT IL IZ A Ç Ã O

A TIPO I eth0.inquilino eno1.inquilino Cliente-a-HLI

B TIPO I eth2.inquilino eno3.inquilino Comunicação nó-ao-


C TIPO I eth1.inquilino eno2.inquilino Nó-a-


armazenamento

D TIPO I eth4.inquilino eno4.inquilino Configurado, mas


não em uso

A TIPO II vlan<inquilinoNo> team0.inquilino Cliente-a-HLI

B TIPO II vlan<inquilinoNo+2> team0.tenant+2 Comunicação nó-ao-


C TIPO II vlan<inquilinoNo+1> team0.tenant+1 Nó-a-


armazenamento

D TIPO II vlan<inquilinoNo+3> team0.tenant+3 Configurado, mas


não em uso

Armazenamento
Os seguintes pontos de montagem são pré-configurados:
P O N TO DE M O N TA GEM C A SO DE UT IL IZ A Ç Ã O

No mestre, trabalhador e nós de espera

/hana/compartilhado Instalação HANA para produção SID

/hana/data/SID/mnt00001 Instalação de ficheiros de dados para produção SID

/hana/log/SID/mnt00001 Instalação de ficheiros de registo para produção SID

/hana/logbackups/SID Registos de redo para produção SID

Escala-out sem espera


Esta topologia suporta vários nós numa configuração de escala para fora. Há um nó com um papel principal, e
um ou mais nós com um papel de trabalhador. No entanto, só pode haver um nó mestre em qualquer ponto do
tempo.
Diagrama da arquitetura

Ethernet
As seguintes interfaces de rede são reconfiguradas:

IN T ERFA C E LÓ GIC A C A SO DE
N IC T IP O SK U N O M E C O M SUSE O S N O M E C O M RH EL O S UT IL IZ A Ç Ã O

A TIPO I eth0.inquilino eno1.inquilino Cliente-a-HLI

B TIPO I eth2.inquilino eno3.inquilino Comunicação nó-ao-



IN T ERFA C E LÓ GIC A C A SO DE
N IC T IP O SK U N O M E C O M SUSE O S N O M E C O M RH EL O S UT IL IZ A Ç Ã O

C TIPO I eth1.inquilino eno2.inquilino Nó-a-


armazenamento

D TIPO I eth4.inquilino eno4.inquilino Configurado, mas


não em uso

A TIPO II vlan<inquilinoNo> team0.inquilino Cliente-a-HLI

B TIPO II vlan<inquilinoNo+2> team0.tenant+2 Comunicação nó-ao-


C TIPO II vlan<inquilinoNo+1> team0.tenant+1 Nó-a-


armazenamento

D TIPO II vlan<inquilinoNo+3> team0.tenant+3 Configurado, mas


não em uso

Armazenamento
Os seguintes pontos de montagem são pré-configurados:

P O N TO DE M O N TA GEM C A SO DE UT IL IZ A Ç Ã O

Nos narizes de mestre e operário

/hana/compartilhado Instalação HANA para produção SID

/hana/data/SID/mnt00001 Instalação de ficheiros de dados para produção SID

/hana/log/SID/mnt00001 Instalação de ficheiros de registo para produção SID

/hana/logbackups/SID Registos de redo para produção SID

Considerações principais
/usr/sap/SID é uma ligação simbólica para /hana/shared/SID.

Scale-out com DR usando replicação de armazenamento


Esta topologia suporta vários nós numa escala com um DR. Tanto os DRs normais como multiusos são
suportados. No diagrama, apenas o ÚNICO propósito DR é representado. Você pode solicitar esta topologia com
ou sem o nó de espera.
Diagrama da arquitetura
Ethernet
As seguintes interfaces de rede são reconfiguradas:

IN T ERFA C E LÓ GIC A C A SO DE
N IC T IP O SK U N O M E C O M SUSE O S N O M E C O M RH EL O S UT IL IZ A Ç Ã O

A TIPO I eth0.inquilino eno1.inquilino Cliente-a-HLI

B TIPO I eth2.inquilino eno3.inquilino Comunicação nó-ao-


C TIPO I eth1.inquilino eno2.inquilino Nó-a-


armazenamento

D TIPO I eth4.inquilino eno4.inquilino Configurado, mas


não em uso

A TIPO II vlan<inquilinoNo> team0.inquilino Cliente-a-HLI

B TIPO II vlan<inquilinoNo+2> team0.tenant+2 Comunicação nó-ao-


C TIPO II vlan<inquilinoNo+1> team0.tenant+1 Nó-a-


armazenamento

D TIPO II vlan<inquilinoNo+3> team0.tenant+3 Configurado, mas


não em uso

Armazenamento
Os seguintes pontos de montagem são pré-configurados:

P O N TO DE M O N TA GEM C A SO DE UT IL IZ A Ç Ã O

No nó principal

/hana/compartilhado Instalação HANA para produção SID

/hana/data/SID/mnt00001 Instalação de ficheiros de dados para produção SID


P O N TO DE M O N TA GEM C A SO DE UT IL IZ A Ç Ã O

/hana/log/SID/mnt00001 Instalação de ficheiros de registo para produção SID

/hana/logbackups/SID Registos de redo para produção SID

No nó DR

/hana/compartilhado Instalação HANA para produção SID

/hana/data/SID/mnt00001 Instalação de ficheiros de dados para produção SID

/hana/log/SID/mnt00001 Instalação de ficheiros de registo para produção SID

Considerações principais
/usr/sap/SID é uma ligação simbólica para /hana/shared/SID.
No local DR: Os volumes e os pontos de montagem estão configurados (marcados como "Necessários para a
instalação HANA") para a instalação da instância HANA de produção na unidade DR HLI.
No site dr: Os dados, cópias de segurança e volumes partilhados (marcados como "Replicação de
Armazenamento") são replicados através de instantâneos do local de produção. Estes volumes são montados
apenas durante a falha. Para mais informações, consulte o procedimento de falha de recuperação de
desastres.
O volume de arranque da classe SKU Type I é replicado para o nó DR.

Nó único com DR usando HSR


Esta topologia suporta um nó numa configuração de escala-up com um SID, com replicação do sistema HANA
para o site DR para um SID primário. No diagrama, apenas um sistema de SID único é representado no local
primário, mas os sistemas multi-SID (MCOS) também são suportados.
Diagrama da arquitetura
Ethernet
As seguintes interfaces de rede são reconfiguradas:

IN T ERFA C E LÓ GIC A C A SO DE
N IC T IP O SK U N O M E C O M SUSE O S N O M E C O M RH EL O S UT IL IZ A Ç Ã O

A TIPO I eth0.inquilino eno1.inquilino Cliente-a-HLI/HSR

B TIPO I eth2.inquilino eno3.inquilino Configurado, mas


não em uso

C TIPO I eth1.inquilino eno2.inquilino Nó-a-


armazenamento

D TIPO I eth4.inquilino eno4.inquilino Configurado, mas


não em uso

A TIPO II vlan<inquilinoNo> team0.inquilino Cliente-a-HLI/HSR

B TIPO II vlan<inquilinoNo+2> team0.tenant+2 Configurado, mas


não em uso

C TIPO II vlan<inquilinoNo+1> team0.tenant+1 Nó-a-


armazenamento

D TIPO II vlan<inquilinoNo+3> team0.tenant+3 Configurado, mas


não em uso

Armazenamento
Os seguintes pontos de montagem são pré-configurados em ambas as unidades HLI (Primária e DR):
P O N TO DE M O N TA GEM C A SO DE UT IL IZ A Ç Ã O

/hana/shared/SID Instalação HANA para SID

/hana/data/SID/mnt00001 Instalação de ficheiros de dados para SID

/hana/log/SID/mnt00001 Instalação de ficheiros de registo para SID

/hana/logbackups/SID Registos de redo para SID

Considerações principais
/usr/sap/SID é uma ligação simbólica para /hana/shared/SID.
Para MCOS: A distribuição do tamanho do volume baseia-se no tamanho da base de dados na memória. Para
saber que tamanhos de base de dados na memória são suportados num ambiente multi-SID, consulte a visão
geral e a arquitetura.
O nó primário sincroniza-se com o nó DR utilizando a Replicação do Sistema HANA.
O Global Reach é usado para ligar os circuitos ExpressRoute para fazer uma rede privada entre as suas redes
regionais.

Nó único HSR para DR (custo otimizado)


Esta topologia suporta um nó numa configuração de escala-up com um SID, com replicação do sistema HANA
para o site DR para um SID primário. No diagrama, apenas um sistema de SID único é representado no local
primário, mas os sistemas multi-SID (MCOS) também são suportados. No local dr, uma unidade HLI é usada para
a instância qA enquanto as operações de produção estão em execução a partir do local principal. Durante a
failover DR (ou teste de failover), a instância qA no local dr é retirada.
Diagrama da arquitetura

Ethernet
As seguintes interfaces de rede são reconfiguradas:
IN T ERFA C E LÓ GIC A C A SO DE
N IC T IP O SK U N O M E C O M SUSE O S N O M E C O M RH EL O S UT IL IZ A Ç Ã O

A TIPO I eth0.inquilino eno1.inquilino Cliente-a-HLI/HSR

B TIPO I eth2.inquilino eno3.inquilino Configurado, mas


não em uso

C TIPO I eth1.inquilino eno2.inquilino Nó-a-


armazenamento

D TIPO I eth4.inquilino eno4.inquilino Configurado, mas


não em uso

A TIPO II vlan<inquilinoNo> team0.inquilino Cliente-a-HLI/HSR

B TIPO II vlan<inquilinoNo+2> team0.tenant+2 Configurado, mas


não em uso

C TIPO II vlan<inquilinoNo+1> team0.tenant+1 Nó-a-


armazenamento

D TIPO II vlan<inquilinoNo+3> team0.tenant+3 Configurado, mas


não em uso

Armazenamento
Os seguintes pontos de montagem são pré-configurados:

P O N TO DE M O N TA GEM C A SO DE UT IL IZ A Ç Ã O

No local principal

/hana/shared/SID Instalação HANA para produção SID

/hana/data/SID/mnt00001 Instalação de ficheiros de dados para produção SID

/hana/log/SID/mnt00001 Instalação de ficheiros de registo para produção SID

/hana/logbackups/SID Registos de redo para produção SID

No site da DR

/hana/shared/SID Instalação HANA para produção SID

/hana/data/SID/mnt00001 Instalação de ficheiros de dados para produção SID

/hana/log/SID/mnt00001 Instalação de ficheiros de registo para produção SID

/hana/logbackups/SID Registos de redo para produção SID

/hana/shared/QA-SID Instalação HANA para QA SID

/hana/data/QA-SID/mnt00001 Instalação de ficheiros de dados para QA SID


P O N TO DE M O N TA GEM C A SO DE UT IL IZ A Ç Ã O

/hana/log/QA-SID/mnt00001 Instalação de ficheiros de registo para QA SID

/hana/logbackups/QA-SID Registos de redo para QA SID

Considerações principais
/usr/sap/SID é uma ligação simbólica para /hana/shared/SID.
Para MCOS: A distribuição do tamanho do volume baseia-se no tamanho da base de dados na memória. Para
saber que tamanhos de base de dados na memória são suportados num ambiente multi-SID, consulte a visão
geral e a arquitetura.
No local DR: Os volumes e os pontos de montagem estão configurados (marcados como "PROD Instance at
DR site") para a instalação de instânciaS HANA de produção na unidade DR HLI.
No site dr: Os dados, cópias de segurança de registo, registo e volumes partilhados para QA (marcadocomo
"instalação de instância QA") estão configurados para a instalação da instância QA.
O nó primário sincroniza-se com o nó DR utilizando a Replicação do Sistema HANA.
O Global Reach é usado para ligar os circuitos ExpressRoute para fazer uma rede privada entre as suas redes
regionais.

Elevada disponibilidade e recuperação de desastres com HSR


Esta topologia suporta dois nós para a configuração de replicação do sistema HANA para a elevada
disponibilidade das regiões locais. Para o DR, o terceiro nó na região DR sincroniza-se com o local primário
utilizando HSR (modo assincronia).
Diagrama da arquitetura

Ethernet
As seguintes interfaces de rede são reconfiguradas:

IN T ERFA C E LÓ GIC A C A SO DE
N IC T IP O SK U N O M E C O M SUSE O S N O M E C O M RH EL O S UT IL IZ A Ç Ã O

A TIPO I eth0.inquilino eno1.inquilino Cliente-a-HLI/HSR

B TIPO I eth2.inquilino eno3.inquilino Configurado, mas


não em uso

C TIPO I eth1.inquilino eno2.inquilino Nó-a-


armazenamento

D TIPO I eth4.inquilino eno4.inquilino Configurado, mas


não em uso

A TIPO II vlan<inquilinoNo> team0.inquilino Cliente-a-HLI/HSR

B TIPO II vlan<inquilinoNo+2> team0.tenant+2 Configurado, mas


não em uso

C TIPO II vlan<inquilinoNo+1> team0.tenant+1 Nó-a-


armazenamento

D TIPO II vlan<inquilinoNo+3> team0.tenant+3 Configurado, mas


não em uso

Armazenamento
Os seguintes pontos de montagem são pré-configurados:

P O N TO DE M O N TA GEM C A SO DE UT IL IZ A Ç Ã O

No local principal

/hana/shared/SID Instalação HANA para produção SID

/hana/data/SID/mnt00001 Instalação de ficheiros de dados para produção SID

/hana/log/SID/mnt00001 Instalação de ficheiros de registo para produção SID

/hana/logbackups/SID Registos de redo para produção SID

No site da DR

/hana/shared/SID Instalação HANA para produção SID

/hana/data/SID/mnt00001 Instalação de ficheiros de dados para produção SID

/hana/log/SID/mnt00001 Instalação de ficheiros de registo para produção SID

/hana/logbackups/SID Registos de redo para produção SID

Considerações principais
/usr/sap/SID é uma ligação simbólica para /hana/shared/SID.
No local DR: Os volumes e os pontos de montagem estão configurados (marcados como "instância PROD
DR") para a instalação de instânciaS HANA de produção na unidade DR HLI.
O nó do local primário sincroniza-se com o nó DR utilizando a Replicação do Sistema HANA.
O Global Reach é usado para ligar os circuitos ExpressRoute para fazer uma rede privada entre as suas redes
regionais.

Elevada disponibilidade e recuperação de desastres com HSR (custo


otimizado)
Esta topologia suporta dois nós para a configuração de replicação do sistema HANA para a elevada
disponibilidade das regiões locais. Para o DR, o terceiro nó na região DR sincroniza-se com o local primário
utilizando HSR (modo async), enquanto outra instância (por exemplo, QA) já está a esgotar-se a partir do nó DR.
Diagrama da arquitetura

Ethernet
As seguintes interfaces de rede são reconfiguradas:

IN T ERFA C E LÓ GIC A C A SO DE
N IC T IP O SK U N O M E C O M SUSE O S N O M E C O M RH EL O S UT IL IZ A Ç Ã O

A TIPO I eth0.inquilino eno1.inquilino Cliente-a-HLI/HSR

B TIPO I eth2.inquilino eno3.inquilino Configurado, mas


não em uso

C TIPO I eth1.inquilino eno2.inquilino Nó-a-


armazenamento

D TIPO I eth4.inquilino eno4.inquilino Configurado, mas


não em uso
IN T ERFA C E LÓ GIC A C A SO DE
N IC T IP O SK U N O M E C O M SUSE O S N O M E C O M RH EL O S UT IL IZ A Ç Ã O

A TIPO II vlan<inquilinoNo> team0.inquilino Cliente-a-HLI/HSR

B TIPO II vlan<inquilinoNo+2> team0.tenant+2 Configurado, mas


não em uso

C TIPO II vlan<inquilinoNo+1> team0.tenant+1 Nó-a-


armazenamento

D TIPO II vlan<inquilinoNo+3> team0.tenant+3 Configurado, mas


não em uso

Armazenamento
Os seguintes pontos de montagem são pré-configurados:

P O N TO DE M O N TA GEM C A SO DE UT IL IZ A Ç Ã O

No local principal

/hana/shared/SID Instalação HANA para produção SID

/hana/data/SID/mnt00001 Instalação de ficheiros de dados para produção SID

/hana/log/SID/mnt00001 Instalação de ficheiros de registo para produção SID

/hana/logbackups/SID Registos de redo para produção SID

No site da DR

/hana/shared/SID Instalação HANA para produção SID

/hana/data/SID/mnt00001 Instalação de ficheiros de dados para produção SID

/hana/log/SID/mnt00001 Instalação de ficheiros de registo para produção SID

/hana/logbackups/SID Registos de redo para produção SID

/hana/shared/QA-SID Instalação HANA para QA SID

/hana/data/QA-SID/mnt00001 Instalação de ficheiros de dados para QA SID

/hana/log/QA-SID/mnt00001 Instalação de ficheiros de registo para QA SID

/hana/logbackups/QA-SID Registos de redo para QA SID

Considerações principais
/usr/sap/SID é uma ligação simbólica para /hana/shared/SID.
No local DR: Os volumes e os pontos de montagem estão configurados (marcados como "instância PROD
DR") para a instalação de instânciaS HANA de produção na unidade DR HLI.
No site dr: Os dados, cópias de segurança de registo, registo e volumes partilhados para QA (marcadocomo
"instalação de instância QA") estão configurados para a instalação da instância QA.
O nó do local primário sincroniza-se com o nó DR utilizando a Replicação do Sistema HANA.
O Global Reach é usado para ligar os circuitos ExpressRoute para fazer uma rede privada entre as suas redes
regionais.

Scale-out com DR usando HSR


Esta topologia suporta vários nós numa escala com um DR. Você pode solicitar esta topologia com ou sem o nó
de espera. O nó do local primário sincroniza-se com o nó do site DR utilizando a Replicação do Sistema HANA
(modo async).
Diagrama da arquitetura

Ethernet
As seguintes interfaces de rede são reconfiguradas:

IN T ERFA C E LÓ GIC A C A SO DE
N IC T IP O SK U N O M E C O M SUSE O S N O M E C O M RH EL O S UT IL IZ A Ç Ã O

A TIPO I eth0.inquilino eno1.inquilino Cliente-a-HLI/HSR

B TIPO I eth2.inquilino eno3.inquilino Comunicação nó-ao-


C TIPO I eth1.inquilino eno2.inquilino Nó-a-


armazenamento

D TIPO I eth4.inquilino eno4.inquilino Configurado, mas


não em uso

A TIPO II vlan<inquilinoNo> team0.inquilino Cliente-a-HLI/HSR

B TIPO II vlan<inquilinoNo+2> team0.tenant+2 Comunicação nó-ao-


C TIPO II vlan<inquilinoNo+1> team0.tenant+1 Nó-a-


armazenamento

D TIPO II vlan<inquilinoNo+3> team0.tenant+3 Configurado, mas


não em uso

Armazenamento
Os seguintes pontos de montagem são pré-configurados:

P O N TO DE M O N TA GEM C A SO DE UT IL IZ A Ç Ã O

No nó principal

/hana/compartilhado Instalação HANA para produção SID

/hana/data/SID/mnt00001 Instalação de ficheiros de dados para produção SID

/hana/log/SID/mnt00001 Instalação de ficheiros de registo para produção SID

/hana/logbackups/SID Registos de redo para produção SID

No nó DR

/hana/compartilhado Instalação HANA para produção SID

/hana/data/SID/mnt00001 Instalação de ficheiros de dados para produção SID

/hana/log/SID/mnt00001 Instalação de ficheiros de registo para produção SID

/hana/logbackups/SID Registos de redo para produção SID

Considerações principais
/usr/sap/SID é uma ligação simbólica para /hana/shared/SID.
No local DR: Os volumes e os pontos de montagem estão configurados para a instalação de instânciaHANA
de produção na unidade DR HLI.
O nó do local primário sincroniza-se com o nó DR utilizando a Replicação do Sistema HANA.
O Global Reach é usado para ligar os circuitos ExpressRoute para fazer uma rede privada entre as suas redes
regionais.

Passos seguintes
Infraestrutura e conectividade para grandes instâncias HANA
Elevada disponibilidade e recuperação de desastres para grandes instâncias HANA
Implantação sap HANA (grandes instâncias)
29/04/2020 • 5 minutes to read • Edit Online

Este artigo assume que concluiu a compra do SAP HANA no Azure (grandes instâncias) da Microsoft. Antes de ler
este artigo, para segundo plano geral, consulte os termos comuns de grandes instâncias HANA e as grandes
instâncias HANA SKUs.
A Microsoft necessita das seguintes informações para implementar unidades de grande instância HANA:
Nome do cliente.
Informações de contacto comercial (incluindo endereço de e-mail e número de telefone).
Informações técnicas de contacto (incluindo endereço de e-mail e número de telefone).
Informações técnicas de contacto em rede (incluindo endereço de e-mail e número de telefone).
Região de implantação de Azure (por exemplo, Oeste dos EUA, Austrália Leste ou Norte da Europa).
SAP HANA em Azure (grandes instâncias) SKU (configuração).
Para cada região de implantação de Azure:
Uma gama de endereços IP /29 para ligações ER-P2P que ligam redes virtuais Azure a grandes
instâncias HANA.
Um bloco CIDR /24 usado para o conjunto IP de grandes instâncias HANA.
Opcional ao utilizar o ExpressRoute Global Reach para permitir o encaminhamento direto das
instalações para as unidades HANA Large Instance ou o encaminhamento entre unidades HANA Large
Instance em diferentes regiões do Azure, é necessário reservar outra gama de endereços IP /29. Esta
gama específica pode não se sobrepor a nenhuma das outras gamas de endereços IP que definiu
anteriormente.
Os valores de gama de endereços IP utilizados no espaço de endereço de rede virtual de cada rede virtual
Azure que se conecta às grandes instâncias HANA.
Dados para cada sistema de grandes instâncias HANA:
Nome de anfitrião desejado, idealmente com um nome de domínio totalmente qualificado.
Endereço IP desejado para a unidade de instância de grande instância HANA fora da gama de
endereços ip do servidor. (Os primeiros 30 endereços IP na gama de endereços IP do servidor estão
reservados para uso interno em grandes instâncias HANA.)
Nome SAP HANA SID para a instância SAP HANA (necessário para criar os volumes de disco
relacionados com SAP HANA necessários). A Microsoft precisa do SID HANA para criar as permissões
para sidadm nos volumes NFS. Estes volumes fixam-se à unidade de instância de grande instância
HANA. O HANA SID também é usado como um dos componentes de nome dos volumes de disco que
são montados. Se quiser executar mais de uma instância HANA na unidade, deve listar vários SIDs
HANA. Cada um recebe um conjunto separado de volumes atribuídos.
No Sistema Operativo Linux, o utilizador da sidadm tem uma identificação de grupo. Este ID é
necessário para criar os volumes de disco relacionados com sap HANA necessários. A instalação SAP
HANA geralmente cria o grupo sapsys, com um ID de grupo de 1001. O utilizador da sidadm faz parte
desse grupo.
No Sistema Operativo Linux, o utilizador da sidadm tem um ID de utilizador. Este ID é necessário para
criar os volumes de disco relacionados com sap HANA necessários. Se estiver a executar várias
instâncias hana na unidade, enumere todos os utilizadores do SIDADM.
O ID de subscrição Azure para a subscrição Azure a que o SAP HANA em Azure HANA grandes instâncias vão
estar diretamente ligados. Este ID de subscrição refere a subscrição Azure, que será carregada com a unidade
ou unidades de instância de grande instância HANA.
Depois de fornecer as informações anteriores, a Microsoft fornece SAP HANA no Azure (grandes instâncias). A
Microsoft envia-lhe informações para ligar as suas redes virtuais Azure a grandes instâncias HANA. Também
pode aceder às grandes unidades de instância da HANA.
Utilize a seguinte sequência para se ligar às grandes instâncias HANA depois de a Microsoft a ter implementado:
1. Ligação de VMs Azure a grandes instâncias HANA
2. Ligando uma VNet a grandes instâncias DA HANA ExpressRoute
3. Requisitos adicionais de rede (opcional)
Ligar VMs do Azure para Instâncias Grandes do
HANA
28/04/2020 • 25 minutes to read • Edit Online

O artigo O que é SAP HANA sobre Azure (Grandes Instâncias)? menciona que a implantação mínima de grandes
instâncias HANA com a camada de aplicação SAP em Azure parece ser a seguinte:

Olhando mais de perto para o lado da rede virtual Azure, há uma necessidade de:
A definição de uma rede virtual Azure na qual vai implantar os VMs da camada de aplicação SAP.
A definição de uma sub-rede padrão na rede virtual Azure que é realmente aquela em que os VMs são
implantados.
A rede virtual Azure que foi criada precisa de ter pelo menos uma subnet VM e uma subnet de gateway de rede
virtual Azure ExpressRoute. Estas subredes devem ser atribuídas às gamas de endereços IP especificadas e
discutidas nas seguintes secções.

Criar a rede virtual Azure para grandes instâncias HANA


NOTE
A rede virtual Azure para grandes instâncias HANA deve ser criada utilizando o modelo de implementação do Gestor de
Recursos Azure. O modelo de implantação mais antigo do Azure, vulgarmente conhecido como modelo de implantação
clássico, não é suportado pela solução HANA Large Instance.

Pode utilizar o portal Azure, PowerShell, um modelo Azure ou o Azure CLI para criar a rede virtual. (Para obter mais
informações, consulte Criar uma rede virtual utilizando o portal Azure). No exemplo seguinte, olhamos para uma
rede virtual que é criada através do portal Azure.
Ao referir-se ao espaço de endereço nesta documentação, para o espaço de endereço que a rede virtual Azure
está autorizada a utilizar. Este espaço de endereço é também a gama de endereços que a rede virtual utiliza para a
propagação da rota BGP. Este espaço de endereço pode ser visto aqui:

No exemplo anterior, com 10.16.0.0/16, a rede virtual Azure recebeu uma gama de endereços IP bastante grande e
ampla para utilizar. Portanto, todas as gamas de endereços IP de subredes subsequentes dentro desta rede virtual
podem ter as suas gamas dentro desse espaço de endereço. Normalmente não recomendamos uma gama de
endereços tão grande para uma única rede virtual em Azure. Mas vamos olhar para as subredes que são definidas
na rede virtual Azure:

Olhamos para uma rede virtual com uma primeira subnet VM (aqui chamada "padrão") e uma subnet chamada
"GatewaySubnet".
Nos dois gráficos anteriores, o espaço de endereço de rede vir tual abrange tanto a gama de endereços IP da
sub-rede do VM Azure como a do portal de rede virtual.
Pode restringir o espaço de endereço da rede vir tual às gamas específicas utilizadas por cada sub-rede. Também
pode definir o espaço de endereço de rede vir tual de uma rede virtual como múltiplas gamas específicas, como
mostrado aqui:

Neste caso, o espaço de endereço seleção vir tual tem dois espaços definidos. São os mesmos que as gamas de
endereços IP que são definidas para a gama de endereços IP da sub-rede do VM Azure e o gateway da rede virtual.
Você pode usar qualquer padrão de nomeação que você quiser para estas subredes de inquilino (subnets VM). No
entanto, deve haver sempre uma, e apenas uma, sub-rede de gateway para cada rede vir tual que se
conecta ao circuito SAP HANA no circuito ExpressRoute (Grandes Instâncias). Esta sub-rede de gateway tem de
ser denominada "GatewaySubnet" para se certificar de que o gateway ExpressRoute está devidamente
colocado.

WARNING
É fundamental que a subnet de gateway seja sempre chamada de "GatewaySubnet".

Pode utilizar várias subredes VM e intervalos de endereços não contíguos. Estas gamas de endereços devem ser
abrangidas pelo espaço de endereço seleto da rede vir tual da rede virtual. Podem estar numa forma agregada.
Também podem estar numa lista das gamas exatas das subredes VM e da sub-rede gateway.
Segue-se um resumo dos factos importantes sobre uma rede virtual Azure que se conecta às grandes instâncias
HANA:
Tem de submeter o espaço de endereço de rede vir tual à Microsoft quando estiver a realizar uma
implementação inicial de Grandes Instâncias HANA.
O espaço de endereço de rede vir tual pode ser uma gama maior que abrange as gamas tanto para a gama de
endereços IP da sub-rede do VM Azure como para o gateway da rede virtual.
Ou pode submeter várias gamas que cobrem as diferentes gamas de endereços IP do intervalo de endereços IP
da subnet VM e a gama de endereços IP de gateway de rede virtual.
O espaço de endereço de rede virtual definido é utilizado para propagação de encaminhamento de BGP.
O nome da sub-rede gateway deve ser: "GatewaySubnet".
O espaço de endereço é utilizado como filtro no lado HANA Large Instance para permitir ou proibir o tráfego
para as unidades HANA Large Instance de Azure. As informações de encaminhamento de BGP da rede virtual
Azure e as gamas de endereços IP que estão configuradas para filtragem no lado hana large instance devem
coincidir. Caso contrário, podem ocorrer problemas de conectividade.
Existem alguns detalhes sobre a subnet gateway que são discutidos mais tarde, na secção Connecting a
vir tual network to HANA Large Instance ExpressRoute.

Diferentes gamas de endereços IP a definir


Algumas das gamas de endereços IP que são necessárias para a implementação de GRANDES Instâncias HANA já
foram introduzidas. Mas há mais gamas de endereços IP que também são importantes. Nem todas as seguintes
gamas de endereços IP têm de ser submetidas à Microsoft. No entanto, precisa de defini-los antes de enviar um
pedido de implantação inicial:
Espaço de endereço de rede virtual : O espaço de endereço de rede vir tual é o endereço IP que atribui ao seu
parâmetro de espaço de endereço nas redes virtuais Azure. Estas redes ligam-se ao ambiente de instância sap
HANA. Recomendamos que este parâmetro de espaço de endereço seja um valor de várias linhas. Deve
consistir na gama de sub-redes do VM Azure e na gama de sub-redes do gateway Azure. Esta gama de sub-
redes foi mostrada nos gráficos anteriores. Não deve sobrepor-se ao seu conjunto IP no local ou ao servidor ou
aos intervalos de endereços ER-P2P. Como obtém estes intervalos de endereçoip(s)? A sua equipa de rede
corporativa ou prestador de serviços deve fornecer uma ou várias gamas de endereços IP que não sejam
utilizadas dentro da sua rede. Por exemplo, a sub-rede do seu VM Azure é 10.0.1.0/24, e a sub-rede da sua sub-
rede azure gateway é 10.0.2.0/28. Recomendamos que o seu espaço de endereço de rede virtual Azure seja
definido como: 10.0.1.0/24 e 10.0.2.0/28. Embora os valores do espaço de endereço possam ser agregados,
recomendamos que os combinem com as gamas de sub-rede. Desta forma, pode acidentalmente evitar a
reutilização de gamas de endereços IP não utilizados em espaços de endereço maiores em outros lugares da
sua rede. O espaço de endereço de rede virtual é um intervalo de endereçoIP. Tem de ser submetida à
Microsoft quando pede uma implementação inicial .
Gama de endereços IP da sub-rede Azure VM: Esta gama de endereços IP é a que atribui ao parâmetro de
sub-rede virtual Azure. Este parâmetro encontra-se na sua rede virtual Azure e liga-se ao ambiente SAP HANA
Large Instance. Esta gama de endereços IP é utilizada para atribuir endereços IP aos seus VMs Azure. Os
endereços IP fora desta gama podem ligar-se ao (s) servidor(s) s da Instância Grande SAP HANA. Se necessário,
pode utilizar várias subredes Azure VM. Recomendamos um bloco CIDR /24 para cada subnet Azure VM. Esta
gama de endereços deve fazer parte dos valores utilizados no espaço de endereços da rede virtual Azure. Como
obtém este intervalo de endereçoIP? A sua equipa de rede corporativa ou prestador de serviços deve fornecer
uma gama de endereços IP que não esteja a ser utilizada dentro da sua rede.
Gama de endereços IP de gateway de rede vir tual: Dependendo das funcionalidades que pretende utilizar, o
tamanho recomendado é:
Gateway ExpressRoute ultra-performance: /26 endereço block -- necessário para classe Tipo II de SKUs.
Coexistência com VPN e ExpressRoute utilizando um gateway de rede virtual ExpressRoute de alto
desempenho (ou menor): /27 bloco de endereços.
Todas as outras situações: bloco de endereços /28. Esta gama de endereços deve fazer parte dos valores
utilizados nos valores "VNet address space". Esta gama de endereços deve fazer parte dos valores
utilizados nos valores de espaço de endereço de rede virtual Azure que submete à Microsoft. Como
obtém este intervalo de endereçoIP? A sua equipa de rede corporativa ou prestador de serviços deve
fornecer uma gama de endereços IP que não está a ser utilizada dentro da sua rede.
Inter valo de endereços para conectividade ER-P2P: Esta gama é a gama IP para a sua ligação P2P sap
HANA Large Instance ExpressRoute (ER). Esta gama de endereços IP deve ser uma gama de endereços IP /29
CIDR. Esta gama NÃO deve sobrepor-se às suas áreas de endereços IP ou Azure. Esta gama de endereços IP é
utilizada para configurar a conectividade ER desde a sua porta de entrada virtual ExpressRoute até aos
servidores SAP HANA Large Instance. Como obtém este intervalo de endereçoIP? A sua equipa de rede
corporativa ou prestador de serviços deve fornecer uma gama de endereços IP que não está a ser utilizada
dentro da sua rede. Esta gama é uma gama de endereços IP. Tem de ser submetida à Microsoft quando
pede uma implementação inicial .
Intervalo de endereços ip do servidor: Esta gama de endereços IP é utilizada para atribuir o endereço IP
individual a servidores de grandes instâncias HANA. O tamanho recomendado da sub-rede é um bloco CIDR
/24. Se necessário, pode ser menor, com apenas 64 endereços IP. A partir desta gama, os primeiros 30
endereços IP são reservados para utilização pela Microsoft. Certifique-se de que explica este facto quando
escolher o tamanho do intervalo. Esta gama NÃO deve sobrepor-se às suas instalações ou a outros endereços
IP Azure. Como obtém este intervalo de endereçoIP? A sua equipa de rede corporativa ou prestador de serviços
deve fornecer uma gama de endereços IP que não está a ser utilizada dentro da sua rede. Esta gama é uma
gama de endereços IP, que precisa de ser submetida à Microsoft ao pedir uma implementação
inicial .
Gamas opcionais de endereços IP que eventualmente precisam de ser submetidas à Microsoft:
Se optar por utilizar o ExpressRoute Global Reach para permitir o encaminhamento direto das instalações para
as unidades HANA Large Instance, tem de reservar outra gama de endereços IP /29. Esta gama pode não se
sobrepor a nenhuma das outras gamas de endereços IP que definiu anteriormente.
Se optar por utilizar o ExpressRoute Global Reach para permitir o encaminhamento direto de um inquilino hana
large instance numa região de Azure para outro inquilino HANA Large Instance em outra região de Azure, você
precisa reservar outra gama de endereços IP /29. Esta gama pode não se sobrepor a nenhuma das outras
gamas de endereços IP que definiu anteriormente.
Para obter mais informações sobre o ExpressRoute Global Reach e o uso em torno de grandes instâncias HANA,
consulte os documentos:
Arquitetura de rede SAP HANA (Grandes Instâncias)
Ligue uma rede virtual a grandes instâncias HANA
É necessário definir e planear as gamas de endereços IP que foram descritas anteriormente. No entanto, não é
necessário transmiti-los todos para a Microsoft. As gamas de endereços IP que é obrigado a nomear para a
Microsoft são:
Espaço de endereço s de rede virtual Azure
Intervalo de endereços para conectividade ER-P2P
Intervalo de endereços de piscina IP do servidor
Se adicionar redes virtuais adicionais que precisam de se ligar a HANA Grandes Instâncias, tem de submeter o
novo espaço de endereço seletiva da rede azure que está a adicionar à Microsoft.
Segue-se um exemplo das diferentes gamas e de algumas gamas de exemplo que precisa de configurar e
eventualmente fornecer à Microsoft. O valor para o espaço de endereço seletivo da rede virtual Azure não é
agregado no primeiro exemplo. No entanto, é definido a partir das gamas da primeira gama de endereços IP da
sub-rede Azure VM e da gama de endereços IP da sub-rede virtual.
Pode utilizar várias subredes VM dentro da rede virtual Azure quando configurar e submeter as gamas de
endereços IP adicionais da subrede(s) VM adicional como parte do espaço de endereço s da rede virtual Azure.

O gráfico não mostra as gamas de endereços IP adicionais que são necessárias para a utilização opcional do
ExpressRoute Global Reach.
Também pode agregar os dados que submete à Microsoft. Nesse caso, o espaço de endereço da rede virtual Azure
inclui apenas um espaço. Utilizando os endereços IP desde o exemplo anterior, o espaço de endereços de rede
virtual agregado pode parecer a seguinte imagem:
No exemplo, em vez de duas gamas mais pequenas que definiram o espaço de endereço da rede virtual Azure,
temos uma gama maior que abrange 4096 endereços IP. Uma definição tão grande do espaço de endereço deixa
algumas gamas bastante grandes não utilizadas. Uma vez que o valor espacial de endereço s de endereço de rede
virtual é utilizado para a propagação de rotas BGP, o uso das gamas não utilizadas no local ou em qualquer outro
lugar da sua rede pode causar problemas de encaminhamento. O gráfico não mostra as gamas de endereços IP
adicionais que são necessárias para a utilização opcional do ExpressRoute Global Reach.
Recomendamos que mantenha o espaço de endereço bem alinhado com o espaço de endereço da sub-rede real
que utiliza. Se necessário, sem incorrer em tempo de inatividade na rede virtual, pode sempre adicionar novos
valores de espaço de endereço mais tarde.

IMPORTANT
Cada intervalo de endereçoIP no ER-P2P, no conjunto IP do servidor e no espaço de endereço de rede virtual Azure NÃO
deve sobrepor-se entre si ou com qualquer outra gama que seja utilizada na sua rede. Cada um deve ser discreto. Como os
dois gráficos anteriores mostram, também não podem ser uma sub-rede de qualquer outra gama. Se ocorrerem
sobreposições entre intervalos, a rede virtual Azure pode não se ligar ao circuito ExpressRoute.

Os próximos passos após os intervalos de endereços foram definidos


Após a definição das gamas de endereços IP, as seguintes coisas têm de acontecer:
1. Envie as gamas de endereços IP para o espaço de endereço de rede virtual Azure, a conectividade ER-P2P e a
gama de endereços IP do servidor, juntamente com outros dados que foram listados no início do documento.
Neste ponto, também pode começar a criar a rede virtual e as subredes VM.
2. Um circuito ExpressRoute é criado pela Microsoft entre a sua subscrição Azure e o carimbo HANA Large
Instance.
3. Uma rede de inquilinos é criada no carimbo de Grande Instância pela Microsoft.
4. A Microsoft confunde a rede na infraestrutura SAP HANA on Azure (Grandes Instâncias) para aceitar endereços
IP do seu espaço de endereços de rede virtual Azure que comunica com as Grandes Instâncias HANA.
5. Dependendo do SAP HANA específico no Azure (Grandes Instâncias) SKU que comprou, a Microsoft atribui uma
unidade de computação numa rede de inquilinos. Também aloca e monta o armazenamento, e instala o sistema
operativo (SUSE ou Red Hat Linux). Os endereços IP para estas unidades são retirados da gama de endereços IP
Pool do Servidor que submeteu à Microsoft.
No final do processo de implementação, a Microsoft entrega-lhe os seguintes dados:
Informações necessárias para ligar a sua rede virtual Azure ao circuito ExpressRoute que liga redes virtuais
Azure a grandes instâncias HANA:
Chave de autorização(s)
ExpressRoute PeerID
Dados para aceder a HANA Grandes Instâncias após estabelecer o circuito ExpressRoute e a rede virtual Azure.
Também pode encontrar a sequência de ligação de GRANDES Instâncias HANA no documento SAP HANA on Azure
(Grandes Instâncias) Configuração. Muitos dos seguintes passos são mostrados num exemplo de implantação
nesse documento.

Passos seguintes
Consulte a Ligação de uma rede virtual à HANA Large Instance ExpressRoute.
Ligue uma rede virtual a grandes instâncias HANA
29/04/2020 • 12 minutes to read • Edit Online

Depois de criar uma rede virtual Azure, pode ligar essa rede ao SAP HANA em grandes instâncias do Azure. Crie
um portal Azure ExpressRoute na rede virtual. Este portal permite-lhe ligar a rede virtual ao circuito ExpressRoute
que se liga ao inquilino do cliente no carimbo HANA Large Instance.

NOTE
Este passo pode levar até 30 minutos para ser concluído. O novo portal é criado na subscrição azure designada e, em
seguida, ligado à rede virtual Azure especificada.

NOTE
Este artigo foi atualizado para utilizar o novo módulo AZ do Azure PowerShell. Pode continuar a utilizar o módulo AzureRM,
que continuará a receber correções de erros até, pelo menos, dezembro de 2020. Para obter mais informações sobre o novo
módulo Az e a compatibilidade do AzureRM, veja Apresentação do novo módulo Az do Azure PowerShell. Para obter
instruções de instalação do módulo Az, veja Instalar o Azure PowerShell.

Se já existe um portal, verifique se é ou não um gateway ExpressRoute. Se não for um gateway ExpressRoute,
elimine o portal e recrie-o como um gateway ExpressRoute. Se já estiver estabelecido um gateway ExpressRoute,
consulte a seguinte secção deste artigo, "Link redes virtuais".
Utilize o portal Azure ou o PowerShell para criar um gateway VPN ExpressRoute ligado à sua rede virtual.
Se utilizar o portal Azure, adicione um novo Portal de Rede Vir tual, e, em seguida, selecione
ExpressRoute como o tipo de gateway.
Se utilizar o PowerShell, primeiro descarregue e utilize o mais recente SDK Azure PowerShell.
Os seguintes comandos criam um gateway ExpressRoute. Os textos precedidos por um $ são variáveis definidas
pelo utilizador que devem ser atualizadas com as suas informações específicas.
# These Values should already exist, update to match your environment
$myAzureRegion = "eastus"
$myGroupName = "SAP-East-Coast"
$myVNetName = "VNet01"

# These values are used to create the gateway, update for how you wish the GW components to be named
$myGWName = "VNet01GW"
$myGWConfig = "VNet01GWConfig"
$myGWPIPName = "VNet01GWPIP"
$myGWSku = "HighPerformance" # Supported values for HANA large instances are: HighPerformance or
UltraPerformance

# These Commands create the Public IP and ExpressRoute Gateway


$vnet = Get-AzVirtualNetwork -Name $myVNetName -ResourceGroupName $myGroupName
$subnet = Get-AzVirtualNetworkSubnetConfig -Name 'GatewaySubnet' -VirtualNetwork $vnet
New-AzPublicIpAddress -Name $myGWPIPName -ResourceGroupName $myGroupName `
-Location $myAzureRegion -AllocationMethod Dynamic
$gwpip = Get-AzPublicIpAddress -Name $myGWPIPName -ResourceGroupName $myGroupName
$gwipconfig = New-AzVirtualNetworkGatewayIpConfig -Name $myGWConfig -SubnetId $subnet.Id `
-PublicIpAddressId $gwpip.Id

New-AzVirtualNetworkGateway -Name $myGWName -ResourceGroupName $myGroupName -Location $myAzureRegion `


-IpConfigurations $gwipconfig -GatewayType ExpressRoute `
-GatewaySku $myGWSku -VpnType PolicyBased -EnableBgp $true

Neste exemplo, foi utilizado o gateway HighPerformance SKU. As suas opções são HighPerformance ou
UltraPerformance como o único Portal de Entrada SKUs que são suportados para SAP HANA em Azure (grandes
instâncias).

IMPORTANT
Para grandes instâncias HANA da classe Tipo II SKU, você deve usar o UltraPerformance Gateway SKU.

Ligar redes virtuais


A rede virtual Azure tem agora um portal ExpressRoute. Utilize as informações de autorização fornecidas pela
Microsoft para ligar a porta de entrada ExpressRoute ao circuito SAP HANA Large Instances ExpressRoute. Pode
ligar-se utilizando o portal Azure ou powerShell. As instruções powerShell são as seguintes.
Executar os seguintes comandos para cada gateway ExpressRoute utilizando um AuthGUID diferente para cada
ligação. As duas primeiras entradas mostradas no seguinte script provêm das informações fornecidas pela
Microsoft. Além disso, o AuthGUID é específico para cada rede virtual e sua porta de entrada. Se quiser adicionar
outra rede virtual Azure, precisa de obter outro AuthID para o seu circuito ExpressRoute que ligue grandes
instâncias HANA ao Azure da Microsoft.
# Populate with information provided by Microsoft Onboarding team
$PeerID = "/subscriptions/9cb43037-9195-4420-a798-f87681a0e380/resourceGroups/Customer-USE-
Circuits/providers/Microsoft.Network/expressRouteCircuits/Customer-USE01"
$AuthGUID = "76d40466-c458-4d14-adcf-3d1b56d1cd61"

# Your ExpressRoute Gateway information


$myGroupName = "SAP-East-Coast"
$myGWName = "VNet01GW"
$myGWLocation = "East US"

# Define the name for your connection


$myConnectionName = "VNet01GWConnection"

# Create a new connection between the ER Circuit and your Gateway using the Authorization
$gw = Get-AzVirtualNetworkGateway -Name $myGWName -ResourceGroupName $myGroupName

New-AzVirtualNetworkGatewayConnection -Name $myConnectionName `


-ResourceGroupName $myGroupName -Location $myGWLocation -VirtualNetworkGateway1 $gw `
-PeerId $PeerID -ConnectionType ExpressRoute -AuthorizationKey $AuthGUID -ExpressRouteGatewayBypass

NOTE
O último parâmetro no comando New-AzVirtualNetworkGatewayConnection, ExpressRouteGatewayBypass é um novo
parâmetro que permite o Caminho Rápido ExpressRoute. Uma funcionalidade que reduz a latência da rede entre as suas
unidades HANA Large Instance e Os VMs Azure. A funcionalidade foi adicionada em maio de 2019. Para mais detalhes,
consulte a arquitetura da rede SAP HANA (Grandes Instâncias). Certifique-se de que está a executar a versão mais recente
dos cmdlets PowerShell antes de executar os comandos.

Para ligar a porta de entrada a mais de um circuito ExpressRoute associado à sua subscrição, poderá ter de
executar este passo mais de uma vez. Por exemplo, é provável que ligue a mesma porta de entrada de rede virtual
ao circuito ExpressRoute que liga a rede virtual à sua rede no local.

Aplicação do Caminho Rápido ExpressRoute aos circuitos existentes


hana de grande instância ExpressRoute
A documentação até agora explicacomo ligar um novo circuito ExpressRoute que foi criado com uma
implementação de Hana Large Instance para um portal Azure ExpressRoute de uma das suas redes virtuais Azure.
Mas muitos clientes já têm os seus circuitos ExpressRoute já e já têm as suas redes virtuais ligadas às Grandes
Instâncias HANA. Como o novo Caminho Rápido ExpressRoute está a reduzir a latência da rede, recomenda-se que
aplique a alteração para utilizar esta funcionalidade. Os comandos para ligar um novo circuito ExpreesRoute e
alterar um circuito expressroute existente são os mesmos. Como resultado, você precisa executar esta sequência
de comandos PowerShell para alterar um circuito existente para usar
# Populate with information provided by Microsoft Onboarding team
$PeerID = "/subscriptions/9cb43037-9195-4420-a798-f87681a0e380/resourceGroups/Customer-USE-
Circuits/providers/Microsoft.Network/expressRouteCircuits/Customer-USE01"
$AuthGUID = "76d40466-c458-4d14-adcf-3d1b56d1cd61"

# Your ExpressRoute Gateway information


$myGroupName = "SAP-East-Coast"
$myGWName = "VNet01GW"
$myGWLocation = "East US"

# Define the name for your connection


$myConnectionName = "VNet01GWConnection"

# Create a new connection between the ER Circuit and your Gateway using the Authorization
$gw = Get-AzVirtualNetworkGateway -Name $myGWName -ResourceGroupName $myGroupName

New-AzVirtualNetworkGatewayConnection -Name $myConnectionName `


-ResourceGroupName $myGroupName -Location $myGWLocation -VirtualNetworkGateway1 $gw `
-PeerId $PeerID -ConnectionType ExpressRoute -AuthorizationKey $AuthGUID -ExpressRouteGatewayBypass

É importante que adicione o último parâmetro acima apresentado para ativar a funcionalidade ExpressRoute Fast
Path

Alcance Global do ExpressRoute


Como pretende permitir o Alcance Global para um ou ambos os cenários:
Replicação do sistema HANA sem quaisquer proxies ou firewalls adicionais
Copiar cópias de cópias entre unidades HANA Large Instance em duas regiões diferentes para executar cópias
do sistema ou atualizações do sistema
precisa considerar que:
Você precisa fornecer uma gama de endereços espaço de endereço de um espaço de endereço /29. Essa gama
de endereços pode não se sobrepor a nenhuma das outras gamas de espaço de endereço que usou até agora
ligando as grandes instâncias HANA ao Azure e pode não se sobrepor a nenhuma das suas gamas de
endereços IP que utilizou em outro lugar em Azure ou no local.
Existe uma limitação nas ASNs (Número do Sistema Autónomo) que pode ser usada para anunciar as suas
rotas no local para as Grandes Instâncias HANA. As suas instalações não devem anunciar quaisquer rotas com
ASNs privadas na faixa dos 65000 – 65020 ou 65515.
Para o cenário de ligar o acesso direto às grandes instâncias HANA Large, é necessário calcular uma taxa para o
circuito que o liga ao Azure. Para preços, verifique os preços do Global Reach Add-On.
Para obter um ou ambos os cenários aplicados à sua implementação, abra uma mensagem de apoio com azure
como descrito em Open um pedido de apoio para grandes instâncias HANA
Os dados necessários e as palavras-chave que precisa de utilizar para a Microsoft poderem encaminhar e executar
a seu pedido, parecem:
Serviço: SAP HANA Grande Instância
Tipo de problema: Configuração e Configuração
Subtipo de problema: O meu problema não está listado acima
Assunto 'Modificar a minha Rede - adicionar Alcance Global'
Detalhes: 'Adicione o Alcance Global à HANA Large Instance ao inquilino hana large instance ou 'Adicione o
Alcance Global ao inquilino hana large instância.
Detalhes adicionais para o caso hana grande instância para hana caso de inquilino de grande instância: Você
precisa definir as duas regiões Azure onde os dois inquilinos para se conectar estão localizados E você
precisa submeter a gama de endereços IP /29
Detalhes adicionais para o caso do inquilino HANA Large Instance: Você precisa definir a região de Azure onde
o inquilino hana large instância é implantado você quer se conectar diretamente. Além disso, precisa de
fornecer o Auth GUID e o Circuit Peer ID que recebeu quando estabeleceu o seu circuito ExpressRoute entre
as instalações e o Azure. Além disso, precisa nomear o seu ASN . O último deliverable é uma gama de
endereços IP /29 para ExpressRoute Global Reach.

NOTE
Se quiser ter ambos os casos tratados, precisa de fornecer duas gamas de endereços IP diferentes /29 que não se
sobrepõem a qualquer outra gama de endereços IP utilizada até agora.

Passos seguintes
Requisitos adicionais de rede para o HLI
Requisitos adicionais de rede para grandes instâncias
29/04/2020 • 7 minutes to read • Edit Online

Pode ter requisitos adicionais de rede como parte de uma implementação de grandes instâncias de SAP HANA em
Azure.

Adicione mais endereços IP ou subredes


Utilize o portal Azure, powerShell ou o Azure CLI quando adicionar mais endereços IP ou subredes.
Adicione a nova gama de endereços IP como uma nova gama para o espaço de endereços de rede virtual, em vez
de gerar uma nova gama agregada. Envie esta alteração para a Microsoft. Isto permite-lhe ligar a partir dessa nova
gama de endereços IP às grandes unidades de instância HANA no seu cliente. Pode abrir um pedido de suporte do
Azure para adicionar o novo espaço de endereço de rede virtual. Depois de receber a confirmação, execute os
próximos passos.
Para criar uma subrede adicional do portal Azure, consulte Criar uma rede virtual utilizando o portal Azure. Para
criar um a partir do PowerShell, consulte Criar uma rede virtual utilizando powerShell.

Adicionar redes virtuais


Depois de ligar inicialmente uma ou mais redes virtuais Azure, é melhor ligar outras que acedem ao SAP HANA no
Azure (grandes instâncias). Primeiro, submeta um pedido de apoio azure. Neste pedido, incluem-se as informações
específicas que identificam a implantação específica do Azure. Incluem também a gama de espaços de endereçoIP
ou gamas do espaço de endereços da rede virtual Azure. O SAP HANA na Microsoft Service Management fornece
então as informações necessárias para ligar as redes virtuais adicionais e o Azure ExpressRoute. Para cada rede
virtual, você precisa de uma chave de autorização única para ligar ao circuito ExpressRoute a grandes instâncias
HANA.

Aumentar largura de banda do circuito ExpressRoute


Consulte a SAP HANA sobre a Microsoft Service Management. Se o aconselharem a aumentar a largura de banda
do circuito SAP HANA no Circuito Azure (grandes instâncias), crie um pedido de apoio Azure. (Pode solicitar um
aumento para uma largura de banda de circuito único até um máximo de 10 Gbps.) Em seguida, recebe notificação
após a operação estar concluída; não é preciso fazer mais nada para permitir esta velocidade mais alta em Azure.

Adicione um circuito adicional expressRoute


Consulte a SAP HANA sobre a Microsoft Service Management. Se o aconselharem a adicionar um circuito
expressRoute adicional, crie um pedido de suporte Azure (incluindo um pedido para obter informações de
autorização para ligar ao novo circuito). Antes de fazer o pedido, deve definir o espaço de endereço utilizado nas
redes virtuais. O SAP HANA na Microsoft Service Management pode então fornecer autorização.
Quando o novo circuito é criado e o SAP HANA na configuração de Gestão de Serviços da Microsoft está completo,
recebe uma notificação com as informações que precisa de proceder. Não é possível ligar redes virtuais Azure a
este circuito adicional se já estiverem ligadas a outro circuito SAP HANA no circuito Azure (grande instância)
ExpressRoute na mesma região de Azure.

Eliminar uma sub-rede


Para remover uma subrede de rede virtual, pode utilizar o portal Azure, PowerShell ou o Azure CLI. Se o seu
alcance de endereço IP ou endereço de rede virtual Azure fosse um intervalo agregado, não existe seguimento
para si com a Microsoft. (Note-se, no entanto, que a rede virtual continua a propagar o espaço de endereço de rota
BGP que inclui a sub-rede eliminada.) Pode ter definido a gama de endereços ou endereços da rede virtual Azure
como múltiplas gamas de endereços IP, das quais uma foi atribuída à sua sub-rede eliminada. Certifique-se de que
apaga a partir do seu espaço de endereço de rede virtual. Em seguida, informe o SAP HANA na Microsoft Service
Management para removê-lo das gamas com as quais o SAP HANA no Azure (grandes instâncias) é autorizado a
comunicar.
Para mais informações, consulte Eliminar uma sub-rede.

Eliminar uma rede virtual


Para obter informações, consulte Eliminar uma rede virtual.
SAP HANA na Microsoft Service Management remove as autorizações existentes no circuito SAP HANA no circuito
Azure (grandes instâncias) ExpressRoute. Também remove a gama de endereços IP da rede virtual Azure ou espaço
de endereço para a comunicação com grandes instâncias HANA.
Depois de remover a rede virtual, abra um pedido de suporte Azure para fornecer a gama ou gamas de
endereçoip para remover.
Para garantir que remove tudo, elimine a ligação ExpressRoute, o portal de rede virtual, o IP público de gateway da
rede virtual e a rede virtual.

Eliminar um circuito ExpressRoute


Para remover um circuito Adicional SAP HANA no circuito ExpressRoute (grandes instâncias), abra um pedido de
suporte Azure com o SAP HANA na Microsoft Service Management. Peça que o circuito seja apagado. Dentro da
subscrição do Azure, pode eliminar ou manter a rede virtual, se necessário. No entanto, deve eliminar a ligação
entre o circuito DE grandes instâncias HANA ExpressRoute e o gateway de rede virtual ligado.

Passos seguintes
Como instalar e configurar o SAP HANA (instâncias grandes) no Azure
Como instalar e configurar o SAP HANA (Grandes
Instâncias) no Azure
13/05/2020 • 25 minutes to read • Edit Online

Antes de ler este artigo, conheça os termos comuns da HANA Large Instances e as SKUs de Grandes Instâncias
HANA.
A instalação do SAP HANA é da sua responsabilidade. Pode começar a instalar um novo servidor SAP HANA no
Azure (Grandes Instâncias) depois de estabelecer a conectividade entre as suas redes virtuais Azure e as unidades
HANA Large Instance.

NOTE
De acordo com a política SAP, a instalação do SAP HANA deve ser realizada por uma pessoa que tenha passado no exame
Certificado SAP Technology Associate, no exame de certificação de instalação SAP HANA ou que seja um integrador de
sistema certificado pela SAP (SI).

Quando estiver a planear instalar o HANA 2.0, consulte a nota de suporte SAP #2235581 - SAP HANA: Sistemas
operativos suportados para garantir que o OS é suportado com o SAP HANA que o está a instalar. O Sistema
operativo apoiado para HANA 2.0 é mais restritivo do que o Sistema operativo apoiado para hana 1.0. Também
precisa de verificar se a libertação de SO em que está interessado está listada como suportada para a unidade HLI
específica nesta listapublicada . Clique na unidade para obter todos os detalhes com a lista de SO suportada dessa
unidade.
Valide o seguinte antes de iniciar a instalação HANA:
Unidade(s) HLI(s)
Configuração do sistema operativo
Configuração da rede
Configuração de armazenamento

Validar as unidades de grandes instâncias HANA


Depois de receber a unidade HANA Large Instance da Microsoft, valide as seguintes definições e ajuste-a se
necessário.
O primeiro passo depois de receber a Grande Instância HANA e estabelecer acesso e conectividade às instâncias,
é verificar no portal Azure se a(s) instância(s) está a aparecer com as SKUs e os SISTEMA corretos. Leia o controlo
de grandes instâncias azure HANA através do portal Azure para obter os passos necessários para efetuar as
verificações.
O segundo passo após receber a Grande Instância HANA e estabelecer acesso e conectividade às instâncias, é
registar o Sistema operativo da ocorrência com o seu fornecedor de SO. Este passo inclui o registo do seu SUSE
Linux OS num caso de SUSE SMT que está implantado num VM em Azure.
A unidade HANA Large Instance pode ligar-se a esta instância SMT. (Para obter mais informações, consulte como
configurar o servidor SMT para o SUSE Linux). Em alternativa, o seu Red Hat OS precisa de ser registado no Red
Hat Subscription Manager a que precisa de se ligar. Para mais informações, consulte as observações no What is
SAP HANA on Azure (Grandes Instâncias)?
Este passo é necessário para remendar o Sistema operativo, que é da responsabilidade do cliente. Para suse,
encontre a documentação para instalar e configurar SMT nesta página sobre a instalação de SMT.
O terceiro passo é verificar se há novos patches e correções da versão/versão específica do SISTEMA. Verifique
se o nível de patch da Grande Instância HANA está no estado mais recente. Pode haver casos em que os últimos
patches não estão incluídos. Depois de assumir uma unidade HANA Large Instance, é obrigatório verificar se os
patches precisam de ser aplicados.
O quar to passo é verificar as notas SAP relevantes para a instalação e configuração do SAP HANA na
versão/versão específica do OS. Devido à alteração de recomendações ou alterações nas notas ou configurações
do SAP que dependem de cenários de instalação individuais, a Microsoft nem sempre será capaz de configurar
uma unidade HANA Large Instance na perfeição.
Portanto, é obrigatório para si, como cliente, ler as notas SAP relacionadas com o SAP HANA para a sua versão
exata do Linux. Verifique também as configurações do lançamento/versão DO See e aplique as definições de
configuração se ainda não o fez.
Especificamente, verifique os seguintes parâmetros e eventualmente ajuste-se a:
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.core.rmem_default = 16777216
net.core.wmem_default = 16777216
net.core.optmem_max = 16777216
net.ipv4.tcp_rmem = 65536 1677216 16777216
net.ipv4.tcp_wmem = 65536 1677216 16777216
A partir do SLES12 SP1 e do RHEL 7.2, estes parâmetros devem ser definidos num ficheiro de configuração no
diretório /etc/sysctl.d. Por exemplo, deve ser criado um ficheiro de configuração com o nome 91-NetApp-
HANA.conf. Para as libertações mais antigas de SLES e RHEL, estes parâmetros devem ser definidos
em/etc/sysctl.conf.
Para todos os lançamentos rHEL a partir de RHEL 6.3, lembre-se:
O sunrpc.tcp_slot_table_entries = 128 parâmetros deve ser colocado em/etc/modprobe.d/sunrpc-local.conf. Se
o ficheiro não existir, tem de o criar primeiro adicionando a entrada:
opções sunrpc tcp_max_slot_table_entries=128
O quinto passo é verificar o tempo do sistema da sua unidade HANA Large Instance. As ocorrências são
implantadas com um fuso horário do sistema. Este fuso horário representa a localização da região de Azure na
qual se encontra o carimbo HANA Large Instance. Pode alterar o tempo ou o fuso horário do sistema das
instâncias que possui.
Se encomendar mais instâncias ao seu inquilino, precisa de adaptar o fuso horário dos casos recém-entregues. A
Microsoft não tem informações sobre o fuso horário do sistema que configura com as instâncias após a
transferência. Assim, as instâncias recém-implantadas podem não ser definidas no mesmo fuso horário que
aquele para o qual mudou. É da sua responsabilidade como cliente adaptar o fuso horário da(s) instância que
foram entregues, se necessário.
O sexto passo é verificar etc/anfitriões. À medida que as lâminas são entregues, têm diferentes endereços IP que
são atribuídos para diferentes fins. Verifique o ficheiro etc/anfitriões. Quando as unidades são adicionadas a um
inquilino existente, não espere ter etc/anfitriões dos sistemas recém-implantados mantidos corretamente com os
endereços IP dos sistemas que foram entregues anteriormente. É da sua responsabilidade como cliente garantir
que uma instância recém-implantada possa interagir e resolver os nomes das unidades que implantou
anteriormente no seu inquilino.
Sistema operativo
O espaço de troca da imagem de OS entregue está definido para 2 GB de acordo com a nota de suporte SAP
#1999997 - FAQ: Memória SAP HANA. Como cliente, se quer um ambiente diferente, deve defini-lo por si mesmo.
SUSE Linux Enterprise Server 12 SP1 para aplicações SAP é a distribuição do Linux que está instalado para SAP
HANA em Azure (Grandes Instâncias). Esta distribuição específica fornece capacidades específicas do SAP "fora da
caixa" (incluindo parâmetros pré-definidos para executar o SAP em SLES de forma eficaz).
Consulte a biblioteca de recursos/documentos brancos no site da SUSE e sAP sobre SUSE na Rede Comunitária
SAP (SCN) para obter vários recursos úteis relacionados com a implantação do SAP HANA no SLES (incluindo a
configuração de alta disponibilidade, endurecimento de segurança específico das operações sap, e muito mais).
Segue-se um SAP adicional e útil em ligações relacionadas com o SUSE:
SAP HANA no site SUSE Linux
Boas práticas para SAP: Replicação em fila – SAP NetWeaver na SUSE Linux Enterprise 12
ClamSAP – Proteção contra vírus SLES para SAP (incluindo SLES 12 para aplicações SAP)
Seguem-se as notas de suporte SAP aplicáveis à implementação do SAP HANA no SLES 12:
Nota de suporte SAP #1944799 – Diretrizes SAP HANA para instalação do sistema operativo SLES
Nota de suporte SAP #2205917 – SAP HANA DB recomendadefinições de OS para aplicações SLES 12 para
aplicações SAP
Nota de suporte SAP #1984787 – SUSE Linux Enterprise Server 12: notas de instalação
Nota de suporte SAP #171356 – Software SAP no Linux: Informações gerais
Nota de suporte SAP #1391070 – Soluções Linux UUID
Red Hat Enterprise Linux para SAP HANA é outra oferta para executar SAP HANA em HANA Grandes Instâncias.
Os lançamentos de RHEL 7.2 e 7.3 estão disponíveis e suportados.
Seguem-se sAP útil adicional em ligações relacionadas com o Chapéu Vermelho:
SAP HANA no site red hat linux.
Seguem-se as notas de suporte SAP aplicáveis à implementação do SAP HANA na Cartola Vermelha:
Nota de suporte SAP #2009879 - Diretrizes SAP HANA para o sistema operativo Red Hat Enterprise Linux
(RHEL)
Nota de suporte SAP #2292690 - SAP HANA DB: Definições recomendadas de OS para RHEL 7
Nota de suporte SAP #1391070 – Soluções Linux UUID
Nota de suporte SAP #2228351 - Linux: SAP HANA Database SPS 11 revisão 110 (ou superior) em RHEL 6 ou
SLES 11
Nota de suporte SAP #2397039 - FAQ: SAP no RHEL
Nota de suporte SAP #2002167 - Red Hat Enterprise Linux 7.x: Instalação e upgrade
Sincronização de hora
As aplicações SAP que são construídas sobre a arquitetura SAP NetWeaver são sensíveis às diferenças de tempo
para os vários componentes que compõem o sistema SAP. As lixeiras curtas SAP ABAP com o título de erro de
ZDATE _ LARGE TIME DIFF são _ _ provavelmente familiares. Isso porque estas pequenas lixeiras aparecem quando
o tempo do sistema de diferentes servidores ou VMs está a afastar-se demasiado.
Para o SAP HANA on Azure (Grandes Instâncias), a sincronização temporal que é feita em Azure não se aplica às
unidades computadas nos selos de Grande Instância. Esta sincronização não é aplicável para executar aplicações
SAP em VMs azure nativos, porque Azure garante que o tempo de um sistema é corretamente sincronizado.
Como resultado, deve configurar um servidor de tempo separado que pode ser utilizado por servidores de
aplicações SAP que estão em execução em VMs Azure e pelas instâncias de base de dados SAP HANA que estão
em execução em casos de grandes instâncias HANA. A infraestrutura de armazenamento em selos de Grande
Instância é sincronizada com servidores NTP.

Redes
Assumimos que seguiu as recomendações na conceção das suas redes virtuais Azure e na ligação dessas redes
virtuais às Grandes Instâncias HANA, conforme descrito nos seguintes documentos:
Visão geral e arquitetura SAP HANA (Grande Instância) em Azure
Infraestrutura e conectividade SAP HANA (Grandes Instâncias) em Azure
Há alguns detalhes que vale a pena mencionar sobre o networking das unidades individuais. Cada unidade HANA
Large Instance vem com dois ou três endereços IP que são atribuídos a duas ou três portas NIC. Três endereços IP
são usados em configurações de escala HANA e no cenário de replicação do sistema HANA. Um dos endereços IP
atribuídos ao NIC da unidade está fora do conjunto IP do servidor que é descrito na visão geral do SAP HANA
(Grandes Instâncias) e arquitetura em Azure.
Para obter mais informações sobre os detalhes da Ethernet para a sua arquitetura, consulte os cenários
suportados pelo HLI.

Armazenamento
O layout de armazenamento para SAP HANA on Azure (Grandes Instâncias) é configurado pela SAP HANA on
Azure através de service management diretrizes recomendadas pela SAP. Estas diretrizes estão documentadas no
livro branco de armazenamento SAP HANA.
Os tamanhos ásperos dos diferentes volumes com as diferentes SKUs de grandes instâncias HANA estão
documentados na visão geral e arquitetura sap HANA (Grandes Instâncias) em Azure.
As convenções de nomeação dos volumes de armazenagem estão enumeradas no quadro seguinte:

UT IL IZ A Ç Ã O DE A RM A Z EN A M EN TO N O M E DO M O N T E N O M E DE VO L UM E

Dados hana /hana/data/SID/mnt0000 < m> IP de


armazenamento:/hana_data_SID_mnt00
001_tenant_vol

Diário hana /hana/log/SID/mnt0000 < m> IP de


armazenamento:/hana_log_SID_mnt000
01_tenant_vol

Backup de log HANA /hana/log/backups IP de


armazenamento:/hana_log_backups_SI
D_mnt00001_tenant_vol

HANA compartilhado /hana/shared/SID IP de


armazenamento:/hana_shared_SID_mnt
00001_tenant_vol/partilhado

usr/seiva /usr/sap/SID IP de
armazenamento:/hana_shared_SID_mnt
00001_tenant_vol/usr_sap

SID é o ID do sistema de instância HANA.


O inquilino é uma enumeração interna de operações ao implantar um inquilino.
Hana usr/seiva partilham o mesmo volume. A nomenclatura dos pontos de montagem inclui a identificação do
sistema das instâncias HANA, bem como o número de montagem. Em destacamentos de escala, há apenas um
suporte, como mnt00001. Em destacamentos de escala, por outro lado, vê-se tantos montes como se tem nós
operários e mestres.
Para ambientes de escala, os volumes de dados, registoe e cópia de segurança de registo são partilhados e ligados
a cada nó na configuração de escala-out. Para configurações que são múltiplas instâncias SAP, um conjunto
diferente de volumes é criado e ligado à unidade HANA Large Instance. Para obter detalhes do layout de
armazenamento para o seu cenário, consulte cenários suportados pelo HLI.
Quando se olha para uma unidade HANA Large Instance, percebe-se que as unidades vêm com um volume de
disco generoso para HANA/dados, e que existe um volume HANA/log/backup. A razão pela qual fizemos o
HANA/dados tão grandes é que as fotos de armazenamento que lhe oferecemos como cliente estão usando o
mesmo volume de disco. Quanto mais instantâneos de armazenamento você executa, mais espaço é consumido
por instantâneos nos volumes de armazenamento atribuídos.
O volume HANA/log/backup não deve ser o volume para cópias de dados. É dimensionado para ser usado como o
volume de reserva para as cópias de segurança do registo de transações HANA. Para mais informações, consulte
AF HANA (Grandes Instâncias) alta disponibilidade e recuperação de desastres em Azure.
Além do armazenamento que é fornecido, pode adquirir capacidade de armazenamento adicional em incrementos
de 1-TB. Este armazenamento adicional pode ser adicionado como novos volumes a uma grande instância HANA.
Durante o embarque com o SAP HANA no service management Azure, o cliente especifica um ID de utilizador (UID)
e id de grupo (GID) para o utilizador sidadm e grupo sapsys (por exemplo: 1000.500). Durante a instalação do
sistema SAP HANA, deve utilizar os mesmos valores. Como pretende implementar várias instâncias HANA numa
unidade, obtém vários conjuntos de volumes (um conjunto para cada instância). Como resultado, no momento de
implantação é necessário definir:
O SID das diferentes instâncias HANA (sidadm é derivado dele).
Os tamanhos de memória dos diferentes casos hana. O tamanho da memória por exemplo define o tamanho
dos volumes em cada conjunto de volume individual.
Com base nas recomendações do fornecedor de armazenamento, as seguintes opções de montagem são
configuradas para todos os volumes montados (exclui a bota LUN):
nfs rw, vers=4, hard, timeo=600, rsize=1048576, wsize=1048576, intr, noatime, lock 0 0
Estes pontos de montagem estão configurados em /etc/fstab, como mostrado nos seguintes gráficos:

A saída do comando df-h numa unidade de grande instância S72m HANA parece:
O controlador de armazenamento e os nós nos selos de Grande Instância são sincronizados com servidores NTP.
Quando sincronizar as unidades SAP HANA em Azure (Grandes Instâncias) e VMs Azure contra um servidor NTP,
não deve haver uma deriva de tempo significativa entre a infraestrutura e as unidades computacionais em selos
Azure ou Large Instance.
Para otimizar o SAP HANA ao armazenamento utilizado por baixo, defina os seguintes parâmetros de
configuração SAP HANA:
max_parallel_io_requests 128
async_read_submit
async_write_submit_ative
async_write_submit_blocks todos
Para versões SAP HANA 1.0 até SPS12, estes parâmetros podem ser definidos durante a instalação da base de
dados SAP HANA, conforme descrito na nota SAP #2267798 - Configuração da base de dados SAP HANA.
Também pode configurar os parâmetros após a instalação da base de dados SAP HANA utilizando a estrutura
hdbparam.
O armazenamento utilizado em HANA Grandes Instâncias tem uma limitação de tamanho de ficheiro. A limitação
do tamanho é de 16 TB por ficheiro. Ao contrário das limitações de tamanho de ficheiro nos sistemas de ficheiros
EXT3, a HANA não está ciente implicitamente da limitação de armazenamento imposta pelo armazenamento
HANA Large Instances. Como resultado, a HANA não criará automaticamente um novo ficheiro de dados quando
o limite de tamanho de ficheiro de 16TB for atingido. À medida que a HANA tenta aumentar o ficheiro para além
de 16 TB, a HANA reportará erros e o servidor de índice sairá no final.

IMPORTANT
Para evitar que a HANA tente cultivar ficheiros de dados para além do limite de tamanho de ficheiro de 16 TB do
armazenamento HANA Large Instance, precisa de definir os seguintes parâmetros no ficheiro de configuração global SAP
HANA.ini
datavolume_striping=verdade
datavolume_striping_size_gb = 15000
Consulte também a nota SAP #2400005
Esteja atento à nota da SAP #2631285

Com o SAP HANA 2.0, a estrutura do hdbparam foi depreciada. Como resultado, os parâmetros devem ser
definidos utilizando comandos SQL. Para mais informações, consulte a nota SAP #2399079: Eliminação do
hdbparam em HANA 2.
Consulte cenários apoiados pelo HLI para saber mais sobre o layout de armazenamento para a sua arquitetura.
Passos seguintes
Consulte a instalação HANA no HLI
Instale HANA no SAP HANA em Azure (Grandes
Instâncias)
29/04/2020 • 8 minutes to read • Edit Online

Para instalar hana no SAP HANA no Azure (Grandes Instâncias), deve primeiro fazer o seguinte:
Fornece à Microsoft todos os dados para ser implantado numa Grande Instância SAP HANA.
Recebe o SAP HANA Large Instance da Microsoft.
Cria uma rede virtual Azure que está ligada à sua rede no local.
Liga o circuito ExpressRoute para as Grandes Instâncias HANA à mesma rede virtual Azure.
Instala uma máquina virtual Azure que utiliza como caixa de salto para grandes instâncias HANA.
Certifique-se de que pode ligar-se da caixa de salto à sua unidade HANA Large Instance e vice-versa.
Verifique se estão instalados todos os pacotes e patches necessários.
Leu as notas do SAP e documentação sobre a instalação da HANA no sistema operativo que está a utilizar.
Certifique-se de que a libertação de escolha da HANA é suportada na libertação do sistema operativo.
A secção seguinte mostra um exemplo de descarregamento dos pacotes de instalação HANA para a máquina
virtual jump box. Neste caso, o sistema operativo é o Windows.

Descarregue os bits de instalação SAP HANA


As unidades HANA Large Instance não estão diretamente ligadas à internet. Não é possível descarregar
diretamente os pacotes de instalação do SAP para a máquina virtual HANA Large Instance. Em vez disso,
descarrega os pacotes para a máquina virtual da caixa de salto.
You need an SAP S-user or other user, which allows you to access the SAP Marketplace.
1. Inscreva-se e vá ao SAP Service Marketplace. Selecione descarregue > instalações de softwaree
atualize > por índice alfabético . Em seguida, selecione Under H – SAP HANA Platform Edition >
SAP HANA Platform Edition 2.0 > Instalação . Descarregue os ficheiros apresentados na seguinte
imagem.

2. Neste exemplo, descarregámos pacotes de instalação SAP HANA 2.0. Na máquina virtual da caixa de salto
Azure, expanda os arquivos auto-extractos para o diretório, como mostrado abaixo.
3. À medida que os arquivos são extraídos, copie o diretório criado pela extração (neste caso, 51052030).
Copie o diretório da unidade HANA Large Instance /hana/volume partilhado num diretório que criou.

IMPORTANT
Não copie os pacotes de instalação na raiz ou arranque LUN, porque o espaço é limitado e precisa de ser usado por
outros processos também.

Instale o SAP HANA na unidade HANA Large Instance


Para instalar o SAP HANA, inscreva-se como raiz do utilizador. Só a raiz tem permissões suficientes para instalar o
SAP HANA. Detete permissões no diretório que copiou para /hana/shared.

chmod –R 744 <Installation bits folder>

Se pretender instalar o SAP HANA utilizando a configuração da interface gráfica do utilizador, a embalagem gtk2
tem de ser instalada em HANA Large Instances. Para verificar se está instalado, execute o seguinte comando:

rpm –qa | grep gtk2

(Em etapas posteriores, mostramos a configuração SAP HANA com a interface gráfica do utilizador.)
Entre no diretório de instalação e navegue no sub diretório HDB_LCM_LINUX_X86_64.
Fora desse diretório, comece:

./hdblcmgui

Neste ponto, você progride através de uma sequência de ecrãs em que fornece os dados para a instalação. Neste
exemplo, estamos a instalar o servidor de base de dados SAP HANA e os componentes do cliente SAP HANA.
Portanto, a nossa seleção é base de dados SAP HANA .

No ecrã seguinte, selecione Instalar novo sistema .

Em seguida, selecione entre vários componentes adicionais que pode instalar.


Aqui, escolhemos o Cliente SAP HANA e o Estúdio SAP HANA. Também instalamos uma instância de escala. Em
seguida, escolha o sistema de hospedeiro único .

Em seguida, forneça alguns dados.


IMPORTANT
Como HANA System ID (SID), deve fornecer o mesmo SID que forneceu à Microsoft quando encomendou a implementação
de Hana Large Instance. A escolha de um SID diferente faz com que a instalação falhe, devido a problemas de permissão de
acesso nos diferentes volumes.

Para o percurso de instalação, utilize o diretório /hana/partilhado. No passo seguinte, fornece as localizações dos
ficheiros de dados HANA e dos ficheiros de registo HANA.

NOTE
O SID que especificou quando definiu as propriedades do sistema (há dois ecrãs) deve coincidir com o SID dos pontos de
montagem. Se houver uma incompatibilidade, volte e ajuste o SID ao valor que tem nos pontos de montagem.
No passo seguinte, reveja o nome do anfitrião e, eventualmente, corrija-o.

No passo seguinte, também precisa de recuperar os dados que deu à Microsoft quando ordenou a implementação
da HANA Large Instance.

IMPORTANT
Forneça o mesmo ID e ID do Utilizador do Administrador do Sistema que forneceu à Microsoft, como encomenda a
implementação da unidade. Caso contrário, a instalação do SAP HANA na unidade HANA Large Instance falha.

Os próximos dois ecrãs não são mostrados aqui. Permitem-lhe fornecer a palavra-passe para o utilizador do
SISTEMA da base de dados SAP HANA e a palavra-passe para o utilizador do sapadm. Este último é utilizado para
o Agente hospedeiro SAP que é instalado como parte da instância de base de dados SAP HANA.
Depois de definir a palavra-passe, consulte um ecrã de confirmação. verifique todos os dados listados e continue
com a instalação. Chega-se a um ecrã de progresso que documenta o progresso da instalação, como este:

À medida que a instalação termina, deve ver um ecrã como este:


A instância SAP HANA deve agora estar a funcionar e pronta para ser utilizada. Deves poder ligar-te a ele do
Estúdio SAP HANA. Certifique-se também de que verifica e aplica as últimas atualizações.

Passos seguintes
SAP HANA Grandes Instâncias alta disponibilidade e recuperação de desastres em Azure
SAP HANA Grandes Instâncias alta disponibilidade
e recuperação de desastres em Azure
29/04/2020 • 13 minutes to read • Edit Online

IMPORTANT
Esta documentação não substitui a documentação da administração SAP HANA ou as Notas SAP. Espera-se que o leitor
tenha uma compreensão sólida e experiência na administração e operações da SAP HANA, especialmente com os tópicos
de backup, restauro, alta disponibilidade e recuperação de desastres.

É importante que exerça os passos e processos tomados no seu ambiente e com as suas versões e
lançamentos HANA. Alguns processos descritos nesta documentação são simplificados para uma melhor
compreensão geral e não devem ser usados como passos detalhados para eventuais manuais de operação. Se
pretender criar manualde funcionamento para as suas configurações, precisa de testar e exercitar os seus
processos e documentar os processos relacionados com as suas configurações específicas.
A elevada disponibilidade e recuperação de desastres (DR) são aspetos cruciais para executar o seu sap HANA
crítico da missão no servidor Azure (Grandes Instâncias). É importante trabalhar com o SAP, o seu integrador
de sistemas ou a Microsoft para arquiteto e implementar as estratégias de alta disponibilidade e recuperação
de desastres certas. Também é importante considerar o objetivo do ponto de recuperação (RPO) e o objetivo
de tempo de recuperação, que são específicos do seu ambiente.
A Microsoft suporta algumas capacidades de alta disponibilidade sAP HANA com as grandes instâncias HANA.
Estas funcionalidades incluem:
Replicação de armazenamento : A capacidade do sistema de armazenamento de replicar todos os dados
para outro carimbo HANA Large Instance em outra região de Azure. A SAP HANA opera
independentemente deste método. Esta funcionalidade é o mecanismo padrão de recuperação de desastres
oferecido para as grandes instâncias HANA.
Replicação do sistema HANA : A replicação de todos os dados em SAP HANA para um sistema Separado
SAP HANA. O objetivo do tempo de recuperação é minimizado através da replicação de dados em
intervalos regulares. O SAP HANA suporta modos assíncronos, sincronizados de memória e sincronizados.
O modo sincronizado é utilizado apenas para sistemas SAP HANA que estão dentro do mesmo datacenter
ou com menos de 100 km de distância. Com o design atual de selos HANA Large Instance, a replicação do
sistema HANA pode ser usada para alta disponibilidade dentro de uma região apenas. A replicação do
sistema HANA requer um componente de procuração ou encaminhamento invertido de terceiros para
configurações de recuperação de desastres noutra região do Azure.
Reprovação automática do anfitrião : Uma solução local de recuperação de falhas para o SAP HANA que é
uma alternativa à replicação do sistema HANA. Se o nó principal ficar indisponível, configura rumimos um
ou mais nós de espera SAP HANA em modo de escala e sAP HANA falha automaticamente num nó de
espera.
O SAP HANA on Azure (Grandes Instâncias) é oferecido em duas regiões azure em quatro áreas geopolíticas
(EUA, Austrália, Europa e Japão). Duas regiões dentro de uma área geopolítica que acolhem selos HANA Large
Instance estão ligados a circuitos de rede dedicados separados. Estes são utilizados para replicar instantâneos
de armazenamento para fornecer métodos de recuperação de desastres. A replicação não é estabelecida por
padrão, mas está configurada para clientes que encomendam funcionalidade de recuperação de desastres. A
replicação do armazenamento depende da utilização de instantâneos de armazenamento para as grandes
instâncias HANA. Não é possível escolher uma região azure como uma região de DR que se encontra numa
área geopolítica diferente.
O quadro que se segue mostra os métodos e combinações de elevada disponibilidade e recuperação de
desastres atualmente suportados:

C EN Á RIO A P O IA DO EM
GRA N DES IN STÂ N C IA S O P Ç Ã O DE A LTA O P Ç Ã O DE REC UP ERA Ç Ã O
HANA DISP O N IB IL IDA DE DE DESA ST RES C O M EN TÁ RIO S

Nó único Não disponível. Configuração de DR


dedicada.
Configuração de DR
multiusos.

Auto-failover do anfitrião: Possível com o standby Configuração de DR Os conjuntos de volume


Scale-out (com ou sem assumindo o papel ativo. dedicada. HANA estão ligados a
standby) Hana controla o interruptor Configuração de DR todos os nós.
incluindo 1+1 de funções. multiusos. O site dr deve ter o mesmo
Sincronização DR utilizando número de nós.
a replicação do
armazenamento.

Replicação do sistema Possível com configuração Configuração de DR Um conjunto separado de


HANA primária ou secundária. dedicada. volumes de disco são
Secundário passa para o Configuração de DR ligados a cada nó.
papel principal num caso de multiusos. Apenas volumes de disco
falha. Sincronização DR utilizando de réplica secundária no
A replicação do sistema a replicação do local de produção são
HANA e o controlo do armazenamento. replicados para a localização
SISTEMA falham. Dr usando a replicação do DR.
sistema HANA ainda não é Um conjunto de volumes é
possível sem componentes necessário no local da DR.
de terceiros.

Uma configuração DR dedicada é onde a unidade HANA Large Instance no local DR não é utilizada para
executar qualquer outro sistema de carga de trabalho ou não-produção. A unidade é passiva e só é implantada
se um desastre falhar. No entanto, esta configuração não é uma escolha preferida para muitos clientes.
Consulte cenários apoiados pelo HLI para aprender o layout de armazenamento e detalhes do ethernet para a
sua arquitetura.

NOTE
SAP HANA MCOD implantações (múltiplas instâncias HANA numa unidade) como cenários de sobreposição funcionam
com os métodos HA e DR listados na tabela. Uma exceção é a utilização da Replicação do Sistema HANA com um cluster
de failover automático baseado no Pacemaker. Tal caso só suporta uma instância HANA por unidade. Para as
implementações do SAP HANA MDC, apenas os métodos HA e DR não baseados em armazenamento funcionam se
forem implantados mais de um inquilino. Com um inquilino destacado, todos os métodos listados são válidos.

Uma configuração DR multiusos é onde a unidade HANA Large Instance no site DR executa uma carga de
trabalho não-produção. Em caso de catástrofe, desligue o sistema de não produção, monte os conjuntos de
volume (adicionais) replicados pelo armazenamento e, em seguida, inicie a ocorrência DE HANA de produção.
A maioria dos clientes que utilizam a funcionalidade de recuperação de desastres HANA Large Instance
utilizam esta configuração.
Pode encontrar mais informações sobre a alta disponibilidade do SAP HANA nos seguintes artigos da SAP:
Branco de alta disponibilidade SAP HANA
Guia de Administração SAP HANA
Vídeo da Academia SAP HANA na replicação do sistema SAP HANA
Nota de suporte SAP #1999880 – FAQ na replicação do sistema SAP HANA
Nota de suporte SAP #2165547 – SAP HANA Back up and Restore in SAP HANA System Replication
Environment
Nota de suporte SAP #1984882 – Utilizando replicação do sistema SAP HANA para troca de hardware com
tempo mínimo/zero de paragem

Considerações de rede para recuperação de desastres com grandes


instâncias HANA
Para aproveitar a funcionalidade de recuperação de desastres de HANA Large Instances, você precisa projetar
conectividade de rede para as duas regiões Azure. Você precisa de uma ligação de circuito Azure ExpressRoute
a partir de instalações na sua região principal de Azure, e outra ligação de circuito de instalações para a sua
região de recuperação de desastres. Esta medida cobre uma situação em que há um problema numa região do
Azure, incluindo uma localização do Microsoft Enterprise Edge Router (MSEE).
Como segunda medida, pode ligar todas as redes virtuais Azure que ligam ao SAP HANA em Azure (Grandes
Instâncias) numa região a um circuito ExpressRoute que liga as grandes instâncias da HANA na outra região.
Com esta ligação cruzada, os serviços que estão a funcionar numa rede virtual Azure na Região 1 podem ligar-
se às unidades HANA Large Instance na Região 2, e ao contrário. Esta medida aborda um caso em que apenas
uma das localizações do MSEE que se liga à sua localização no local com o Azure fica offline.
O gráfico seguinte ilustra uma configuração resiliente para casos de recuperação de desastres:
Outros requisitos com a replicação de armazenamento de grandes
instâncias HANA para recuperação de desastres
Para além dos requisitos anteriores para uma instalação de recuperação de desastres com as grandes
instâncias hana, deve:
Encomende SAP HANA em SKUs Azure (Grandes Instâncias) do mesmo tamanho que as suas SKUs de
produção e desemprepreça-as na região de recuperação de desastres. Nas atuais implementações de
clientes, estes casos são utilizados para executar instâncias HANA não-produtivas. Estas configurações
são referidas como configurações DR multiusos.
Encomende armazenamento adicional no site dr para cada um dos seus SAP HANA em Azure (Grandes
Instâncias) SKUs que pretende recuperar no local de recuperação de desastres. Comprar
armazenamento adicional permite-lhe alocar os volumes de armazenamento. Você pode alocar os
volumes que são alvo da replicação de armazenamento da sua produção da região Azure para a região
de recuperação de desastres Azure.
No caso, onde tiver configuração hSR nas primárias, e configurar replicação baseada em
armazenamento no site DR, deve adquirir armazenamento adicional no site dr para que os dados dos
nós primários e secundários sejam replicados para o site DR.
Passos seguintes
Consulte a Cópia de Segurança e restaure.
Cópia de segurança e restauro
08/05/2020 • 53 minutes to read • Edit Online

IMPORTANT
Este artigo não substitui a documentação da administração SAP HANA ou as Notas SAP. Esperamos que tenha uma
compreensão sólida e experiência na administração e operações da SAP HANA, especialmente para backup, restauro, alta
disponibilidade e recuperação de desastres. Neste artigo, são mostradas imagens do Estúdio SAP HANA. Conteúdo,
estrutura e natureza dos ecrãs das ferramentas de administração SAP e das próprias ferramentas podem mudar a partir da
versão SAP HANA para lançar.

É importante que exerça os passos e processos tomados no seu ambiente e com as suas versões e lançamentos
HANA. Alguns processos descritos neste artigo são simplificados para uma melhor compreensão geral. Não
devem ser usados como passos detalhados para uma eventual operação de manuais. Se pretender criar manualde
operação para as suas configurações, testar e exercitar os seus processos e documentar os processos relacionados
com as suas configurações específicas.
Um dos aspetos mais importantes das bases de dados operacionais é protegê-las de eventos catastróficos. A
causa destes eventos pode ser qualquer coisa, desde desastres naturais a erros simples do utilizador.
O backup de uma base de dados, com a capacidade de restaurá-la a qualquer momento, como antes de alguém
apagar dados críticos, permite a restauração a um estado o mais próximo possível da forma como estava antes da
interrupção.
Devem ser realizados dois tipos de cópias de segurança para alcançar a capacidade de restauro:
Backups de base de dados: Backups completos, incrementais ou diferenciais
Backups de registo de transações
Além das cópias de segurança completas realizadas a nível de aplicação, pode efetuar cópias de segurança com
instantâneos de armazenamento. Os instantâneos de armazenamento não substituem as cópias de segurança do
registo de transações. As cópias de segurança do registo de transações continuam a ser importantes para
restaurar a base de dados num determinado momento ou para esvaziar os registos de transações já
comprometidas. Os instantâneos de armazenamento podem acelerar a recuperação fornecendo rapidamente uma
imagem de avanço da base de dados.
O SAP HANA on Azure (Grandes Instâncias) oferece duas opções de backup e restauro:
Faça-o por si mesmo (DIY). Depois de se certificar de que existe espaço suficiente para o disco, execute
a base de dados completa e faça cópias de segurança através de um dos seguintes métodos de backup do
disco. Pode fazer o seu back back diretamente aos volumes ligados às unidades HANA Large Instance ou às
ações da NFS que são configuradas numa máquina virtual Azure (VM). Neste último caso, os clientes
criaram um Linux VM em Azure, anexam o Armazenamento Azure ao VM e partilham o armazenamento
através de um servidor NFS configurado nesse VM. Se executar a cópia de segurança contra volumes que
se ligam diretamente às unidades HANA Large Instance, copie as cópias de cópias de segurança para uma
conta de armazenamento Azure. Faça isto depois de criar um VM Azure que exporta ações da NFS
baseadas no Armazenamento Azure. Também pode utilizar um cofre azure backup ou armazenamento a
frio Azure.
Outra opção é usar uma ferramenta de proteção de dados de terceiros para armazenar as cópias de
segurança depois de serem copiadas para uma conta de armazenamento Azure. A opção de backup DIY
também pode ser necessária para os dados que você precisa armazenar por períodos mais longos de
tempo para finalidades de conformidade e auditoria. Em todos os casos, as cópias de backup são copiadas
em ações da NFS representadas através de um VM e Armazenamento Azure.
Infraestrutura de backup e restaurar funcionalidade. Também pode utilizar a funcionalidade de
backup e restauro que a infraestrutura subjacente do SAP HANA no Azure (Grandes Instâncias) fornece.
Esta opção satisfaz a necessidade de backups e restauros rápidos. O resto desta secção aborda a
funcionalidade de backup e restauro que é oferecida com as Grandes Instâncias HANA. Esta secção
também cobre a relação que o backup e o restauro têm com a funcionalidade de recuperação de desastres
oferecida pela HANA Large Instances.

NOTE
A tecnologia instantânea que é usada pela infraestrutura subjacente de HANA Large Instances tem uma dependência de
instantâneos SAP HANA. Neste ponto, as fotos do SAP HANA não funcionam em conjunto com vários inquilinos de
contentores de base de dados multiarrendatários SAP HANA. Se apenas um inquilino for implantado, as fotos do SAP HANA
funcionam e você pode usar este método.

Utilize instantâneos de armazenamento de SAP HANA em Azure


(Grandes Instâncias)
A infraestrutura de armazenamento subjacente ao SAP HANA no Azure (Grandes Instâncias) suporta instantâneos
de armazenamento de volumes. Tanto a cópia de segurança como a restauração de volumes são suportadas, com
as seguintes considerações:
Em vez de cópias de dados completas, as imagens de volume de armazenamento são tiradas frequentemente.
Quando um instantâneo é acionado sobre /hana/data e /hana/shared, que inclui /usr/seiva, volumes, a
tecnologia snapshot inicia um instantâneo SAP HANA antes de ser executado o instantâneo de
armazenamento. Este instantâneo SAP HANA é o ponto de configuração para eventuais restaurações de log
após a recuperação do instantâneo de armazenamento. Para que uma foto hana tenha sucesso, precisa de um
caso HANA ativo. Num cenário de HSR, um instantâneo de armazenamento não é suportado num nó
secundário atual onde não se pode realizar um instantâneo HANA.
Após o instantâneo de armazenamento ser executado com sucesso, o instantâneo SAP HANA é eliminado.
As cópias de segurança do registo de transações são tomadas frequentemente e armazenadas no volume
/hana/logbackups ou em Azure. Pode ativar o volume de backups /hana/logbackups que contém as cópias de
segurança do registo de transações para tirar uma fotografia separadamente. Nesse caso, não precisas de fazer
uma fotografia da HANA.
Se tiver de restaurar uma base de dados a um determinado ponto do tempo, para uma paragem de produção,
solicite que o Microsoft Azure Support ou o SAP HANA no Azure restaure a um determinado instantâneo de
armazenamento. Um exemplo é a restauração planeada de um sistema de caixa de areia para o seu estado
original.
O instantâneo SAP HANA que está incluído no instantâneo de armazenamento é um ponto de compensação
para a aplicação de cópias de segurança de registo de transações que foram realizadas e foram armazenadas
após a foto de armazenamento ter sido tirada.
Estas cópias de segurança do registo de transações são tomadas para restaurar a base de dados de volta a um
certo ponto do tempo.
Pode executar instantâneos de armazenamento que visam três classes de volumes:
Um instantâneo combinado sobre /hana/data e /hana/shared, que inclui /usr/seiva. Este instantâneo requer a
criação de um instantâneo SAP HANA como preparação para o instantâneo de armazenamento. O instantâneo
SAP HANA garante que a base de dados está num estado consistente do ponto de vista do armazenamento.
Para o processo de restauro, é um ponto para definir.
Uma imagem separada sobre /hana/logbackups.
Uma partição do sistema operativo.
Para obter os mais recentes scripts e documentação instantânea, consulte GitHub. Ao descarregar o pacote de
scripts snapshot do GitHub,obtém três ficheiros. Um dos ficheiros está documentado num PDF para a
funcionalidade fornecida. Depois de descarregar o conjunto de ferramentas, siga as instruções em "Obter as
ferramentas instantâneas".

Considerações de instantâneode armazenamento


NOTE
Os instantâneos de armazenamento consomem espaço de armazenamento que é atribuído às unidades HANA Large
Instance. Considere os seguintes aspetos de agendamento de instantâneos de armazenamento e quantos instantâneos de
armazenamento devem guardar.

As mecânicas específicas dos instantâneos de armazenamento para SAP HANA em Azure (Grandes Instâncias)
incluem:
Uma foto de armazenamento específica no momento em que é tomada consome pouco armazenamento.
À medida que o conteúdo dos dados muda e o conteúdo nos ficheiros de dados do SAP HANA muda no
volume de armazenamento, o instantâneo precisa de armazenar o conteúdo original do bloco e as alterações
de dados.
Como resultado, o instantâneo de armazenamento aumenta de tamanho. Quanto mais tempo o instantâneo
existir, maior se torna o instantâneo de armazenamento.
Quanto mais alterações forem feitas ao volume de base de dados SAP HANA ao longo da vida útil de um
instantâneo de armazenamento, maior é o consumo de espaço do instantâneo de armazenamento.
O SAP HANA em Azure (Grandes Instâncias) vem com tamanhos de volume fixos para os dados e volumes de
registo SAP HANA. Executar instantâneos desses volumes come no seu espaço de volume. Precisa:
Determine quando agendar instantâneos de armazenamento.
Monitorize o consumo espacial dos volumes de armazenamento.
Gerencie o número de instantâneos que armazena.
Pode desativar as imagens de armazenamento quando importar massas de dados ou realizar outras alterações
significativas na base de dados da HANA.
As seguintes secções fornecem informações para a realização destes instantâneos e incluem recomendações
gerais:
Embora o hardware possa sustentar 255 instantâneos por volume, você quer ficar bem abaixo deste número. A
recomendação é de 250 ou menos.
Antes de realizar instantâneos de armazenamento, monitorize e mantenha o registo do espaço livre.
Baixe o número de instantâneos de armazenamento com base no espaço livre. Pode baixar o número de
instantâneos que guarda, ou pode estender os volumes. Pode encomendar armazenamento adicional em
unidades de 1 terabyte.
Durante atividades como a deslocação de dados para SAP HANA com ferramentas de migração da plataforma
SAP (R3load) ou restaurar as bases de dados SAP HANA de cópias de segurança, desative instantâneos de
armazenamento no volume /hana/data.
Durante as maiores reorganizações das tabelas SAP HANA, evite instantâneos de armazenamento, se possível.
Os instantâneos de armazenamento são um pré-requisito para tirar partido das capacidades de recuperação
de desastres da SAP HANA em Azure (Grandes Instâncias).
Pré-requisitos para a utilização de instantâneos de armazenamento de
self-service
Para se certificar de que o script instantâneo funciona com sucesso, certifique-se de que o Perl está instalado no
sistema operativo Linux no servidor HANA Large Instances. Perl vem pré-instalado na sua unidade HANA Large
Instance. Para verificar a versão Perl, utilize o seguinte comando:
perl -v

Configurar instantâneos de armazenamento


Para configurar instantâneos de armazenamento com as grandes instâncias HANA, siga estes passos.
1. Certifique-se de que o Perl está instalado no sistema operativo Linux no servidor HANA Large Instances.
2. Modificar o config /etc/ssh/ssh_para adicionar a linha MACs hmac-sha1.
3. Crie uma conta de utilizador de reserva SAP HANA no nó principal para cada instância SAP HANA que executa,
se aplicável.
4. Instale o cliente SAP HANA HDB em todos os servidores SAP HANA Large Instances.
5. No primeiro servidor SAP HANA Large Instances de cada região, crie uma chave pública para aceder à
infraestrutura de armazenamento subjacente que controla a criação de instantâneos.
6. Copie os scripts e o ficheiro de configuração do GitHub para a localização do hdbsql na instalação SAP HANA.
7. Modifique o ficheiro HANABackupDetails.txt conforme necessário para as especificações apropriadas do
cliente.
Obtenha os mais recentes scripts instantâneos e documentação do GitHub. Para os passos anteriormente listados,
consulte as ferramentas snapshot da Microsoft para SAP HANA no Azure.
Consideração para cenários MCOD
Se executar um cenário MCOD com múltiplas instâncias SAP HANA numa unidade HANA Large Instance, tem
volumes de armazenamento separados previstos para cada uma das instâncias SAP HANA. Para obter mais
informações sobre o MDC e outras considerações, consulte "Coisas importantes a lembrar" nas ferramentas
instantâneas da Microsoft para o SAP HANA no Azure.
Passo 1: Instalar o cliente SAP HANA HDB
O sistema operativo Linux instalado no SAP HANA no Azure (Grandes Instâncias) inclui as pastas e scripts
necessários para executar instantâneos de armazenamento SAP HANA para fins de backup e recuperação de
desastres. Verifique se há lançamentos mais recentes no GitHub.
É da sua responsabilidade instalar o cliente SAP HANA HDB nas unidades HANA Large Instance enquanto instala o
SAP HANA.
Passo 2: Alterar o config /etc/ssh/ssh_
Este passo é descrito em "Enable communication with storage" nas ferramentas instantâneas da Microsoft para
SAP HANA no Azure.
Passo 3: Criar uma chave pública
Para permitir o acesso às interfaces instantâneas de armazenamento do seu inquilino HANA Large Instance,
estabeleça um procedimento de iniciação através de uma chave pública.
No primeiro servidor SAP HANA no Azure (Grandes Instâncias) no seu inquilino, crie uma chave pública para
aceder à infraestrutura de armazenamento. Com uma chave pública, não é necessária uma senha para iniciar
sessão nas interfaces de instantâneo de armazenamento. Também não precisa de manter credenciais de senha
com uma chave pública.
Para gerar uma chave pública, consulte "Enable communication with storage" nas ferramentas instantâneas da
Microsoft para SAP HANA no Azure.
Passo 4: Criar uma conta de utilizador SAP HANA
Para iniciar a criação de instantâneos SAP HANA, crie uma conta de utilizador no SAP HANA que os scripts
instantâneos de armazenamento possam usar. Crie uma conta de utilizador SAP HANA dentro do Estúdio SAP
HANA para este fim. O utilizador deve ser criado sob o SYSTEMDB e não sob a base de dados SID para MDC. No
ambiente de contentor único, o utilizador é criado na base de dados dos inquilinos. Esta conta deve ter privilégios
de Backup Admin e Catalog Read.
Para configurar e utilizar uma conta de utilizador, consulte "Ativar a comunicação com o SAP HANA" no GitHub.
Passo 5: Autorizar a conta de utilizador SAP HANA
Neste passo, autoriza a conta de utilizador SAP HANA que criou para que os scripts não precisem de enviar
senhas no prazo de execução. O comando hdbuserstore SAP HANA permite a criação de uma chave de utilizador
SAP HANA. A chave é armazenada em um ou mais nós SAP HANA. A chave do utilizador permite ao utilizador
aceder ao SAP HANA sem ter de gerir as palavras-passe a partir do processo de script. O processo de escrita é
discutido mais tarde neste artigo.

IMPORTANT
Executar estes comandos de configuração com o mesmo contexto de utilizador em que os comandos instantâneos são
executados. Caso contrário, os comandos instantâneos não funcionarão corretamente.

Passo 6: Obtenha os scripts instantâneos, configure os instantâneos e teste a configuração e conectividade


Descarregue a versão mais recente dos scripts do GitHub. A forma como os scripts são instalados alterou-se com
o lançamento 4.1 dos scripts. Para mais informações, consulte "Enable communication with SAP HANA" nas
ferramentas instantâneas da Microsoft para SAP HANA no Azure.
Para obter a sequência exata de comandos, consulte "Fácil instalação de ferramentas instantâneas (predefinido)"
nas ferramentas instantâneas da Microsoft para SAP HANA no Azure. Recomendamos a utilização da instalação
predefinida.
Para atualizar da versão 3.x para 4.1, consulte "Atualize uma instalação existente" nas ferramentas instantâneas da
Microsoft para SAP HANA no Azure. Para desinstalar o conjunto de ferramentas 4.1, consulte "Desinstalação das
ferramentas instantâneas" nas ferramentas instantâneas da Microsoft para SAP HANA no Azure.
Não se esqueça de executar os passos descritos em "Configuração completa de ferramentas instantâneas" nas
ferramentas instantâneas da Microsoft para SAP HANA no Azure.
O propósito dos diferentes scripts e ficheiros à medida que foram instalados é descrito em "O que são estas
ferramentas instantâneas?" em ferramentas instantâneas da Microsoft para SAP HANA no Azure.
Antes de configurar as ferramentas instantâneas, certifique-se de que também configura corretamente as
localizações e configurações de backup HANA. Para mais informações, consulte "SAP HANA Configuration" nas
ferramentas instantâneas da Microsoft para SAP HANA no Azure.
A configuração do conjunto de ferramentas instantâneas é descrita em "Config file -
HANABackupCustomerDetails.txt" nas ferramentas instantâneas da Microsoft para SAP HANA no Azure.
Testar conectividade com SAP HANA
Depois de colocar todos os dados de configuração no ficheiro HANABackupCustomerDetails.txt, verifique se as
configurações estão corretas para os dados da instância HANA. Utilize o testHANAConnection script , que é
independente de uma configuração de escala SAP HANA ou scale-out.
Para mais informações, consulte "Verifique a conectividade com o SAP HANA - testHANAConnection" nas
ferramentas instantâneas da Microsoft para SAP HANA no Azure.
Testar conectividade de armazenamento
O próximo passo de teste é verificar a conectividade com o armazenamento com base nos dados que colocou no
ficheiro de configuração HANABackupCustomerDetails.txt. Em seguida, executar uma foto de teste. Antes de
azure_hana_backup executar o comando, tem de fazer este teste. Para a sequência de comandos para este teste,
consulte "Verifique a conectividade com o armazenamento - testStorageSnapshotConnection" nas ferramentas
instantâneas da Microsoft para SAP HANA no Azure.
Após um sessão bem-sucedido nas interfaces de máquina virtual de armazenamento, o script continua com a fase
2 e cria um instantâneo de teste. A saída é mostrada aqui para uma configuração de escala de três nós de SAP
HANA.
Se o instantâneo do teste for executado com sucesso com o script, pode agendar as imagens de armazenamento
reais. Se não for bem sucedido, investigue os problemas antes de seguir em frente. O instantâneo do teste deve
ficar por aqui até que as primeiras fotos verdadeiras estejam prontas.
Passo 7: Realizar instantâneos
Quando os passos de preparação estiverem terminados, pode começar a configurar e agendar os instantâneos de
armazenamento reais. O guião a ser programado funciona com configurações de escala e escala SAP HANA. Para
a execução periódica e regular do script de backup, agende o script utilizando o utilitário cron.
Para obter a sintaxe e funcionalidade exatas de comando, consulte "Execute a cópia de segurança instantânea -
azure_hana_backup" nas ferramentas instantâneas da Microsoft para SAP HANA no Azure.
Quando o azure_hana_backup script corre, cria o instantâneo de armazenamento nas três fases seguintes:
1. Tem uma foto da SAP HANA.
2. Tem um instantâneo de armazenamento.
3. Remove o instantâneo SAP HANA que foi criado antes do instantâneo de armazenamento correr.
Para executar o script, chame-o da pasta executável do HDB para a qual foi copiado.
O período de retenção é administrado com o número de instantâneos que são submetidos como parâmetro
quando executa o script. A quantidade de tempo que é coberta pelos instantâneos de armazenamento é uma
função do período de execução, e do número de instantâneos submetidos como parâmetro quando o script corre.
Se o número de instantâneos que são mantidos exceder o número que são nomeados como parâmetro na
chamada do script, o instantâneo de armazenamento mais antigo da mesma etiqueta é eliminado antes de um
novo instantâneo ser executado. O número que dá como último parâmetro da chamada é o número que pode
usar para controlar o número de instantâneos que são mantidos. Com este número, também pode controlar,
indiretamente, o espaço do disco que é usado para instantâneos.

Estratégias instantâneas
A frequência de instantâneos para os diferentes tipos depende se utiliza a funcionalidade de recuperação de
desastres hana large instance. Esta funcionalidade baseia-se em instantâneos de armazenamento, o que pode
exigir recomendações especiais para os períodos de frequência e execução dos instantâneos de armazenamento.
Nas considerações e recomendações que se seguem, o pressuposto é que não utiliza a funcionalidade de
recuperação de desastres que a HANA Large Instances oferece. Em vez disso, utiliza as imagens de
armazenamento para ter cópias de segurança e poderá fornecer uma recuperação pontual nos últimos 30 dias.
Dadas as limitações do número de instantâneos e espaço, considere os seguintes requisitos:
O tempo de recuperação para a recuperação do ponto no tempo.
O espaço usado.
O ponto de recuperação e os objetivos de tempo de recuperação para uma potencial recuperação de uma
catástrofe.
A eventual execução de backups de base de dados completas da HANA contra discos. Sempre que for efetuada
uma cópia de segurança de base de dados completa contra discos ou a interface backint, a execução dos
instantâneos de armazenamento falha. Se planeia executar cópias de segurança em cima de imagens de
armazenamento, certifique-se de que a execução das imagens de armazenamento é desativada durante este
período.
O número de instantâneos por volume, que é limitado a 250.
Se não utilizar a funcionalidade de recuperação de desastres de GRANDES Instâncias HANA, o período de
instantâneo é menos frequente. Nesses casos, efetue os instantâneos combinados em /hana/data e /hana/shared,
que inclui /usr/seiva, em períodos de 12 horas ou 24 horas. Guarde as fotos por um mês. O mesmo se aplica às
imagens do volume de cópiade cópia de bordo. A execução de cópias de segurança de registo de transações SAP
HANA contra o volume de cópia de segurança de registo ocorre em períodos de 5 minutos a 15 minutos.
Os instantâneos de armazenamento programados são melhor realizados usando cron. Use o mesmo guião para
todas as necessidades de recuperação de cópias de segurança e desastres. Modifique as inputs do script para
corresponder aos vários tempos de backup solicitados. Estas fotos são todas programadas de forma diferente em
cron, dependendo do seu tempo de execução. Pode ser de hora em hora, a cada 12 horas, diariamente ou
semanalmente.
O exemplo seguinte mostra uma programação cronememem em /etc/crontab:

00 1-23 * * * ./azure_hana_backup --type=hana --prefix=hourlyhana --frequency=15min --retention=46


10 00 * * * ./azure_hana_backup --type=hana --prefix=dailyhana --frequency=15min --retention=28
00,05,10,15,20,25,30,35,40,45,50,55 * * * * ./azure_hana_backup --type=logs --prefix=regularlogback --
frequency=3min --retention=28
22 12 * * * ./azure_hana_backup --type=logs --prefix=dailylogback --frequncy=3min --retention=28
30 00 * * * ./azure_hana_backup --type=boot --boottype=TypeI --prefix=dailyboot --frequncy=15min --
retention=28

No exemplo anterior, um instantâneo combinado de hora a hora cobre os volumes que contêm o /hana/data e
/hana/shared/SID, que inclui /usr/seiva, locais. Utilize este tipo de instantâneo para uma recuperação pontual mais
rápida nos últimos dois dias. Há também uma foto diária nesses volumes. Então, você tem dois dias de cobertura
por fotos de hora a hora mais quatro semanas de cobertura por fotos diárias. O volume de cópia de segurança do
registo de transações também é apoiado diariamente. Estes reforços são mantidos por quatro semanas.
Como pode ver na terceira linha de crontab, a cópia de segurança do registo de transações da HANA está
programada para ser executada a cada 5 minutos. Os tempos de início dos diferentes trabalhos de compadrio que
executam instantâneos de armazenamento são escalonados. Desta forma, as fotos não funcionam de uma só vez
num determinado momento.
No exemplo seguinte, executa um instantâneo combinado que cobre os volumes que contêm os /hana/data e
/hana/shared/SID, que inclui /usr/seiva, localizações numa base horária. Guarde estas fotos por dois dias. As
imagens dos volumes de cópia de segurança do registo de transações são executadas numa base de 5 minutos e
são mantidas durante quatro horas. Como antes, a cópia de segurança do ficheiro de registo de transações HANA
está programada para ser executada a cada 5 minutos.
O instantâneo do volume de cópia de segurança do registo de transações é realizado com um atraso de 2 minutos
após o início da cópia de segurança do registo de transações. Em circunstâncias normais, o registo de cópias de
segurança da sap HANA termina nesses 2 minutos. Como antes, o volume que contém a bota LUN é apoiado uma
vez por dia por um instantâneo de armazenamento e é mantido durante quatro semanas.
10 0-23 * * * ./azure_hana_backup --type=hana ==prefix=hourlyhana --frequency=15min --retention=48
0,5,10,15,20,25,30,35,40,45,50,55 * * * * ./azure_hana_backup --type=logs --prefix=regularlogback --
frequency=3min --retention=28
2,7,12,17,22,27,32,37,42,47,52,57 * * * * ./azure_hana_backup --type=logs --prefix=logback --frequency=3min
--retention=48
30 00 * * * ./azure_hana_backup --type=boot --boottype=TypeII --prefix=dailyboot --frequency=15min --
retention=28

O gráfico seguinte ilustra as sequências do exemplo anterior. A bota LUN está excluída.

O SAP HANA realiza escritas regulares contra o volume /hana/log para documentar as alterações comprometidas
na base de dados. Regularmente, o SAP HANA escreve um ponto de poupança para o volume /hana/data.
Conforme especificado no crontab, uma cópia de segurança de registo de transações SAP HANA funciona a cada
5 minutos.
Também vê que um instantâneo SAP HANA funciona de hora a hora como resultado de desencadear um
instantâneo de armazenamento combinado sobre os volumes /hana/data e /hana/shared/SID. Após o instantâneo
hana ter sucesso, o instantâneo combinado de armazenamento corre. Conforme instruído no crontab, o
instantâneo de armazenamento no volume /hana/logbackup funciona a cada 5 minutos, cerca de 2 minutos após
a cópia de segurança do registo de transações HANA.

IMPORTANT
A utilização de instantâneos de armazenamento para cópias de segurança SAP HANA só é valiosa quando as imagens são
realizadas em conjunto com cópias de segurança de registo de transações SAP HANA. Estas cópias de segurança do registo
de transações têm de cobrir os períodos de tempo entre os instantâneos de armazenamento.

Se definiu um compromisso com os utilizadores de uma recuperação pontual de 30 dias, precisa de:
Aceda a um instantâneo de armazenamento combinado sobre /hana/data e /hana/shared/SID que tenha 30
dias, em casos extremos.
Distenha cópias de segurança contíguas de registo de transações que cubram o tempo entre qualquer um dos
instantâneos combinados de armazenamento. Assim, o instantâneo mais antigo do volume de cópia de
segurança do registo de transações tem de ter 30 dias. Este não é o caso se copiar as cópias de registo de
transações para outra parte da NFS que está localizada no Armazenamento Azure. Nesse caso, pode retirar
cópias de segurança antigas do registo de transações daquela parte da NFS.
Para beneficiar de instantâneos de armazenamento e da eventual replicação de armazenamento de cópias de
segurança de registo de transações, altere a localização para a qual o SAP HANA escreve as cópias de segurança
do registo de transações. Podes fazer esta mudança no Hana Studio.
Embora o SAP HANA recue automaticamente nos segmentos de registo completos, especifique um intervalo de
cópia de segurança para ser determinista. Isto é especialmente verdade quando se utiliza a opção de recuperação
de desastres, porque normalmente quer executar cópias de segurança de registo com um período determinístico.
No caso seguinte, 15 minutos é definido como intervalo de backup de registo.

Também pode escolher backups mais frequentes do que a cada 15 minutos. Uma configuração mais frequente é
frequentemente usada em conjunto com a funcionalidade de recuperação de desastres de GRANDES Instâncias
HANA. Alguns clientes realizam cópias de segurança de registo de transações a cada 5 minutos.
Se a base de dados nunca tiver sido apoiada, o passo final é executar uma cópia de segurança baseada em
ficheiros para criar uma única entrada de cópia de segurança que deve existir dentro do catálogo de cópias de
segurança. Caso contrário, o SAP HANA não pode iniciar as suas cópias de segurança especificadas.

Após a execução dos seus primeiros instantâneos de armazenamento bem sucedidos, elimine o instantâneo de
teste que correu no passo 6. Para obter mais informações, consulte "Remover instantâneos de teste -
removaTestStorageSnapshot" nas ferramentas instantâneas da Microsoft para SAP HANA no Azure.
Monitorize o número e o tamanho das imagens no volume do disco
Num volume de armazenamento específico, pode monitorizar o número de instantâneos e o consumo de
armazenamento desses instantâneos. O ls comando não mostra o diretório ou ficheiros instantâneos. O
comando du Linux OS mostra detalhes sobre as fotos de armazenamento porque são armazenados nos mesmos
volumes. Utilize o comando com as seguintes opções:
du –sh .snapshot : Esta opção fornece um total de todas as imagens dentro do diretório instantâneo.
du –sh --max-depth=1 : Esta opção lista todos os instantâneos guardados na pasta .snapshot e o tamanho de
cada instantâneo.
du –hc : Esta opção fornece o tamanho total utilizado por todos os instantâneos.

Utilize estes comandos para se certificar de que as imagens que são tiradas e armazenadas não consomem todo o
armazenamento nos volumes.

NOTE
As fotos da bota LUN não são visíveis com os comandos anteriores.

Obter detalhes de fotos


Para obter mais detalhes sobre as azure_hana_snapshot_details fotos, use o script . Pode executar este script em
qualquer local se houver um servidor ativo no local de recuperação de desastres. O script fornece a seguinte
saída, discriminada por cada volume que contém instantâneos:
O tamanho dos instantâneos totais num volume
Os seguintes detalhes em cada instantâneo desse volume:
Nome instantâneo
Criar tempo
Tamanho do instantâneo
Frequência do instantâneo
HANA Backup ID associado a esse instantâneo, se relevante
Para sintaxe do comando e saídas, consulte "List snapshots - azure_hana_snapshot_details" nas ferramentas
instantâneas da Microsoft para SAP HANA no Azure.
Reduzir o número de instantâneos num servidor
Como anteriormente explicado, pode reduzir o número de certos rótulos de instantâneos que armazena. Os dois
últimos parâmetros do comando para iniciar um instantâneo são a etiqueta e o número de instantâneos que
pretende reter.

./azure_hana_backup --type=hana --prefix=dailyhana --frequency=15min --retention=28

No exemplo anterior, o rótulo instantâneo é diáriohana . O número de instantâneos com esta etiqueta a manter é
de 28 . Ao responder ao consumo de espaço em disco, é possível reduzir o número de instantâneos armazenados.
Uma maneira fácil de reduzir o número de instantâneos para 15, por exemplo, é executar o script com o último
parâmetro definido para 15:

./azure_hana_backup --type=hana --prefix=dailyhana --frequency=15min --retention=15

Se executar o script com esta definição, o número de instantâneos, que inclui o novo instantâneo de
armazenamento, é de 15. As 15 fotografias mais recentes são mantidas e as 15 fotografias mais antigas são
apagadas.
NOTE
Este script reduz o número de instantâneos apenas se houver instantâneos com mais de uma hora de idade. O guião não
apaga fotografias com menos de uma hora de idade. Estas restrições estão relacionadas com a funcionalidade opcional de
recuperação de desastres oferecida.

Se já não quiser manter um conjunto de instantâneos com o prefixo de reserva diariamentehana nos exemplos
de sintaxe, execute o script com 0 como número de retenção. Todas as imagens que correspondem à etiqueta são
removidas. Remover todos os instantâneos pode afetar as capacidades da funcionalidade de recuperação de
desastres de grandes instâncias HANA.
Uma segunda opção para eliminar instantâneos azure_hana_snapshot_delete específicos é utilizar o script . Este
script foi concebido para eliminar um instantâneo ou um conjunto de instantâneos, utilizando o ID de backup
HANA, tal como se encontra no HANA Studio, ou através do próprio nome instantâneo. Atualmente, o ID de
reserva está apenas ligado às imagens criadas para o tipo de instantâneo hana. As cópias de segurança
instantâneas dos registos do tipo e da bota não executam uma foto do SAP HANA, por isso não há identificação
de reserva para essas fotos. Se o nome instantâneo for introduzido, procura todos os instantâneos nos diferentes
volumes que correspondam ao nome instantâneo introduzido.
Para obter mais informações sobre o script, consulte "Delete a snapshot - azure_hana_snapshot_delete" nas
ferramentas instantâneas da Microsoft para SAP HANA no Azure.
Executar o script como raiz do utilizador .

IMPORTANT
Se houver dados que existam apenas no instantâneo que planeia eliminar, depois de o instantâneo ser eliminado, esses
dados perdem-se para sempre.

Restauro ao nível de ficheiro a partir de um instantâneo de


armazenamento
Para os tipos de instantâneos hana e registos, pode aceder diretamente às imagens nos volumes do diretório
.snapshot. Há um subdiretório para cada uma das fotos. Copiar cada ficheiro no estado em que estava no ponto
do instantâneo desse subdiretório para a estrutura real do diretório.
Na versão atual do script, não há nenhum script de restauro fornecido para o restauro instantâneo como self-
service. A restauração instantânea pode ser realizada como parte dos scripts de recuperação de desastres de
autosserviço no local de recuperação de desastres durante a failover. Para restaurar um instantâneo desejado a
partir dos instantâneos disponíveis, deve contactar a equipa de operações da Microsoft abrindo um pedido de
serviço.

NOTE
A restauração de ficheiros simples não funciona para fotos da bota LUN independentes do tipo de unidades HANA Large
Instance. O diretório .snapshot não está exposto na bota LUN.

Recupere para o mais recente instantâneo da HANA


Num cenário de produção para baixo, o processo de recuperação de um instantâneo de armazenamento pode ser
iniciado como um incidente com o Microsoft Azure Support. É uma questão de alta urgência se os dados foram
apagados num sistema de produção e a única maneira de recuperá-lo é restaurar a base de dados de produção.
Numa situação diferente, uma recuperação pontual pode ser de baixa urgência e dias previstos com antecedência.
Você pode planear esta recuperação com SAP HANA em Azure em vez de levantar uma bandeira de alta
prioridade. Por exemplo, pode planear atualizar o software SAP aplicando um novo pacote de melhoramento. Em
seguida, você precisa voltar a uma foto que representa o estado antes da atualização do pacote de melhoramento.
Antes de enviar o pedido, precisa se preparar. A equipa SAP HANA da Azure pode então lidar com o pedido e
fornecer os volumes restaurados. Depois, restaure a base de dados HANA com base nas imagens.
Para obter um instantâneo restaurado com o novo conjunto de ferramentas, consulte "Como restaurar um
instantâneo" no guia de recuperação manual para SAP HANA em Azurea partir de um instantâneo de
armazenamento .
Para se preparar para o pedido, siga estes passos.
1. Decida qual instantâneo restaurar. Apenas o volume hana/dados é restaurado a menos que instrua o
contrário.
2. Desligue a instância HANA.

3. Desmonte os volumes de dados em cada nó de base de dados HANA. Se os volumes de dados ainda
estiverem montados no sistema operativo, a restauração do instantâneo falha.

4. Abra um pedido de apoio azure e inclua instruções sobre a restauração de um instantâneo específico:
Durante a restauração: O SAP HANA no Serviço Azure pode pedir-lhe para assistir a uma chamada
de conferência para coordenar, verificar e confirmar que o instantâneo de armazenamento correto é
restaurado.
Após a restauração: O SAP HANA no Serviço Azure notifica-o quando o instantâneo de
armazenamento é restaurado.
5. Depois de concluído o processo de restauração, remonte todos os volumes de dados.

Outra possibilidade para obter, por exemplo, ficheiros de dados SAP HANA recuperados de um instantâneo de
armazenamento, está documentado no passo 7 no guia de recuperação manual para SAP HANA em Azure a partir
de um instantâneo de armazenamento.
Para restaurar a partir de uma cópia de segurança instantânea, consulte o guia de recuperação manual para O
SAP HANA em Azure a partir de um instantâneo de armazenamento.

NOTE
Se o seu instantâneo foi restaurado pelas operações da Microsoft, não precisa de fazer o passo 7.
Recuperar para outro ponto no tempo
Para restaurar um determinado ponto no tempo, consulte "Recuperar a base de dados para o seguinte ponto de
tempo" no guia de recuperação manual para SAP HANA em Azure a partir de um instantâneo de armazenamento.

Passos seguintes
Consulte os princípios e a preparaçãoda recuperação de desastres.
Princípios da recuperação de desastres
28/04/2020 • 15 minutes to read • Edit Online

Hana Large Instances oferecem uma funcionalidade de recuperação de desastres entre selos hana large instância
em diferentes regiões de Azure. Por exemplo, se implantar unidades HANA Large Instance na região oeste dos EUA
de Azure, pode utilizar as unidades HANA Large Instance na região leste dos EUA como unidades de recuperação
de desastres. Como mencionado anteriormente, a recuperação de desastres não é configurada automaticamente,
porque requer que você pague por outra unidade HANA Large Instance na região de DR. A configuração de
recuperação de desastres funciona para a escala-up, bem como configurações de escala para fora.
Nos cenários implementados até agora, os clientes utilizam a unidade na região DR para executar sistemas de não
produção que utilizam uma instância HANA instalada. A unidade HANA Large Instance tem de ser do mesmo SKU
que o SKU utilizado para fins de produção. A imagem que se segue mostra como é a configuração do disco entre a
unidade de servidores na região de produção do Azure e a região de recuperação de desastres:

Como mostrado neste gráfico de visão geral, é necessário encomendar um segundo conjunto de volumes de disco.
Os volumes de disco-alvo são do mesmo tamanho que os volumes de produção para a instância de produção nas
unidades de recuperação de desastres. Estes volumes de disco estão associados à unidade de servidor HANA
Large Instance no local de recuperação de desastres. Os seguintes volumes são replicados da região de produção
para o sítio DR:
/hana/dados
/hana/logbackups
/hana/shared (inclui /usr/seiva)
O volume de /hana/log não é replicado porque o registo de transações SAP HANA não é necessário na forma
como a restauração desses volumes é feita.
A base da funcionalidade de recuperação de desastres oferecida é a funcionalidade de replicação de
armazenamento oferecida pela infraestrutura HANA Large Instance. A funcionalidade que é utilizada no lado do
armazenamento não é um fluxo constante de alterações que se replicam de forma assíncrona à medida que as
alterações acontecem ao volume de armazenamento. Em vez disso, é um mecanismo que se baseia no facto de
que as imagens destes volumes são criadas regularmente. O delta entre um instantâneo já replicado e um novo
instantâneo que ainda não é replicado é então transferido para o local de recuperação de desastres em volumes de
discos-alvo. Estes instantâneos são armazenados nos volumes e, se houver uma falha de recuperação de desastres,
precisam de ser restaurados nesses volumes.
A primeira transferência dos dados completos do volume deve ser antes que a quantidade de dados se torne
menor do que os deltas entre instantâneos. Como resultado, os volumes no site dr contêm cada um dos
instantâneos de volume realizados no local de produção. Eventualmente, pode usar esse sistema DEDr para chegar
a um estado anterior para recuperar dados perdidos, sem reverter o sistema de produção.
Se houver uma implantação MCOD com múltiplas instâncias independentes de SAP HANA numa unidade HANA
Large Instance, espera-se que todos os casos de SAP HANA estejam a ser replicados para o lado DR.
Nos casos em que utiliza a Replicação do Sistema HANA como funcionalidade de alta disponibilidade no seu local
de produção e utiliza replicação baseada em armazenamento para o site DR, os volumes de ambos os nós do local
primário para a instância DR são replicados. Deve adquirir armazenamento adicional (do mesmo tamanho do nó
primário) no local dr para acomodar a replicação tanto do primário como secundário para o DR.

NOTE
A funcionalidade de replicação de armazenamento HANA Large Instance está a espelhar e replicar instantâneos de
armazenamento. Se não executar instantâneos de armazenamento como introduzido na secção Backup e restaurar este
artigo, não pode haver nenhuma replicação para o local de recuperação de desastres. A execução instantânea de
armazenamento é um pré-requisito para a replicação de armazenamento para o local de recuperação de desastres.

Preparação do cenário de recuperação de desastres


Neste cenário, tem um sistema de produção em funcionamento em HANA Large Instances na produção da região
de Azure. Para os passos que se seguem, vamos assumir que o SID desse sistema HANA é "PRD", e que você tem
um sistema de não produção em funcionamento em HANA Grandes Instâncias na região DR Azure. Para este
último, vamos supor que o seu SID é "TST". A imagem seguinte mostra esta configuração:

Se a instância do servidor ainda não tiver sido encomendada com o conjunto adicional de volume de
armazenamento, a SAP HANA na Azure Service Management anexa o conjunto adicional de volumes como alvo
para a réplica de produção da unidade HANA Large Instance em que está a executar a instância TST HANA. Para o
efeito, é necessário fornecer o SID da sua produção HANA. Depois de o SAP HANA na Azure Service Management
confirmar a fixação desses volumes, é necessário montar esses volumes na unidade HANA Large Instance.
O próximo passo é instalar a segunda instância SAP HANA na unidade HANA Large Instance na região DR Azure,
onde executa a instância TST HANA. A instância Recém-instalada SAP HANA precisa de ter o mesmo SID. Os
utilizadores criados precisam de ter o mesmo UID e id de grupo que a instância de produção tem. Leia backup e
restaure para mais detalhes. Se a instalação tiver sucesso, é necessário:
Execute o passo 2 da preparação instantânea de armazenamento descrita em Backup e restaurar.
Crie uma chave pública para a unidade DR da unidade HANA Large Instance se ainda não o tiver feito. Consulte
o passo 3 da preparação instantânea de armazenamento descrita em Backup e restaurar.
Mantenha o HANABackupCustomerDetails.txt com a nova instância HANA e teste se a conectividade no
armazenamento funciona corretamente.
Pare a recém-instalada instância SAP HANA na unidade HANA Large Instance na região DR Azure.
Desmonte estes volumes de PRD e contacte a SAP HANA na Azure Service Management. Os volumes não
podem ficar montados na unidade porque não podem ser acessíveis enquanto funcionam como alvo de
replicação de armazenamento.

A equipa de operações estabelece a relação de replicação entre os volumes de PRD na produção da região azure e
os volumes prd na região DR Azure.
IMPORTANT
O volume de /hana/log não é replicado porque não é necessário restaurar a base de dados SAP HANA replicada para um
estado consistente no local de recuperação de desastres.

Em seguida, configurar ou ajustar o calendário de cópia de segurança do instantâneo de armazenamento para


chegar ao seu RTO e RPO no caso do desastre. Para minimizar o objetivo do ponto de recuperação, detete os
seguintes intervalos de replicação no serviço HANA Large Instance:
Para os volumes cobertos pelo instantâneo combinado (tipo instantâneo hana), definido para replicar a cada
15 minutos os alvos de volume de armazenamento equivalentes no local de recuperação de desastres.
Para o volume de cópia de segurança do registo de transações (registos de tipo instantâneo), decidiu replicar a
cada 3 minutos os objetivos equivalentes de volume de armazenamento no local de recuperação de desastres.
Para minimizar o objetivo do ponto de recuperação, configurar o seguinte:
Execute uma foto de armazenamento do tipo Hana (ver "Passo 7: Executar instantâneos") a cada 30 minutos a 1
hora.
Efetue cópias de segurança de registo de transações SAP HANA a cada 5 minutos.
Efetue uma foto de armazenamento do tipo logs a cada 5-15 minutos. Com este intervalo, obtém-se um RPO
de cerca de 15-25 minutos.
Com esta configuração, a sequência de cópias de segurança de registo de transações, instantâneos de
armazenamento e a replicação do volume de cópia de segurança de registo de transações HANA e /hana/data, e
/hana/shared (inclui /usr/seap) podem parecer os dados mostrados neste gráfico:
Para obter um RPO ainda melhor no caso de recuperação de desastres, pode copiar os backups de registo de
transações HANA da SAP HANA em Azure (Grandes Instâncias) para a outra região de Azure. Para conseguir esta
nova redução de RPO, execute os seguintes passos:
1. Faça o backup do registo de transações HANA com a maior frequência possível para /hana/logbackups.
2. Utilize rsync para copiar as cópias de registo de transações para as máquinas virtuais Azure hospedadas em
ações NFS. Os VMs estão em redes virtuais Azure na região de produção do Azure e nas regiões DR. É
necessário ligar ambas as redes virtuais Azure ao circuito que liga a produção HANA Large Instances ao Azure.
Consulte os gráficos na Rede para a recuperação de desastres com a secção [HANA Large Instances.](#Network-
considerations-for-disaster recovery-with-HANA-Large-Instances)
3. Mantenha as cópias de segurança do registo de transações na região do VM anexadas ao armazenamento
exportado da NFS.
4. Num caso de falha de desastre, complemente as cópias de segurança do registo de transações que encontrar
no volume de backups /hana/logbackups com cópias de segurança de registo de transações mais recentemente
tomadas na parte NFS no site de recuperação de desastres.
5. Inicie uma cópia de segurança de registo de transações para restaurar a mais recente cópia de segurança que
poderá ser guardada para a região de DR.
Quando as operações da HANA Large Instance confirmam a configuração da relação de replicação e inicia as
cópias de segurança do armazenamento de armazenamento de execução, a replicação de dados começa.

À medida que a replicação progride, os instantâneos dos volumes de PRD nas regiões DR Azure não são
restaurados. Só estão armazenadas. Se os volumes forem montados em tal estado, representam o estado em que
desmontou esses volumes após a instalação da instância PRD SAP HANA na unidade de servidores da região DR
Azure. Também representam as cópias de segurança que ainda não foram restauradas.
Se houver uma falha, também pode optar por restaurar um instantâneo de armazenamento mais antigo em vez do
mais recente instantâneo de armazenamento.

Passos seguintes
Consulte o procedimento de falha de recuperação de desastres.
Procedimento de ativação pós-falha de recuperação
após desastre
20/05/2020 • 14 minutes to read • Edit Online

IMPORTANT
Este artigo não substitui a documentação da administração SAP HANA ou as Notas SAP. Esperamos que tenha uma
compreensão sólida e experiência na administração e operações da SAP HANA, especialmente para backup, restauro, alta
disponibilidade e recuperação de desastres (DR). Neste artigo, são mostradas imagens do Estúdio SAP HANA. Conteúdo,
estrutura e natureza dos ecrãs das ferramentas de administração SAP e das próprias ferramentas podem mudar a partir da
versão SAP HANA para lançar.

Há dois casos a considerar quando falha num site de DR:


Precisa da base de dados SAP HANA para voltar ao estado mais recente dos dados. Neste caso, existe um script
de self-service com o qual pode executar a falha sem a necessidade de contactar a Microsoft. Para o failback,
tens de trabalhar com a Microsoft.
Você quer restaurar para um instantâneo de armazenamento que não é o mais recente instantâneo replicado.
Neste caso, tens de trabalhar com a Microsoft.

NOTE
Os seguintes passos devem ser feitos na unidade HANA Large Instance, que representa a unidade DR.

Para restaurar as mais recentes imagens de armazenamento replicadas, siga os passos em "Execute full DR failover
- azure_hana_dr_failover" nas ferramentas instantâneas da Microsoft para SAP HANA no Azure.
Se quiser ter várias instâncias SAP HANA falhadas, corra o comando azure_hana_dr_failover várias vezes. Quando
solicitado, insira o SID SAP HANA que pretende falhar e restaurar.
Pode testar a falha do DR também sem afetar a relação real de replicação. Para efetuar uma falha no teste, siga os
passos em "Execute um teste DR failover - azure_hana_test_dr_failover" nas ferramentas instantâneas da Microsoft
para SAP HANA no Azure.

IMPORTANT
Não ecorra quaisquer transações de produção na instância que criou no site dr através do processo de teste de uma falha .
O comando azure_hana_test_dr_failover cria um conjunto de volumes que não têm relação com o local primário. Como
resultado, a sincronização de volta ao local primário não é possível.

Se quiser ter várias instâncias SAP HANA para testar, faça o guião várias vezes. Quando solicitado, insira o SID SAP
HANA da instância que pretende testar para a falha.

NOTE
Se precisar de falhar no site da DR para resgatar alguns dados que foram apagados há horas e precisar que os volumes de
DR sejam definidos para uma imagem mais precoce, este procedimento aplica-se.
1. Desligue a instância de não produção da HANA na unidade de recuperação de desastres da HANA Large
Instances que está a executar. Uma instância de produção HANA dormente é pré-instalada.
2. Certifique-se de que não estão a decorrer processos SAP HANA. Utilize o seguinte comando para esta
verificação:
/usr/sap/hostctrl/exe/sapcontrol –nr <HANA instance number> - function GetProcessList .
A saída deve mostrar-lhe o processo hdbdaemon em estado de paragem e nenhum outro processo HANA
em estado de corrida ou iniciado.
3. Determine qual o nome instantâneo ou id de backup SAP HANA que pretende restaurar o local de
recuperação de desastres. Em casos reais de recuperação de desastres, este instantâneo é geralmente o
último instantâneo. Se precisar de recuperar os dados perdidos, escolha uma foto mais cedo.
4. Contacte o Suporte Azure através de um pedido de apoio de alta prioridade. Peça a restauração desse
instantâneo com o nome e a data do instantâneo ou o ID de reserva HANA no site dr. A predefinição é que o
lado das operações restaura apenas o volume /hana/dados. Se também quiser ter os volumes de backups
/hana/logbackups, tem de o indicar especificamente. Não restaure o volume /hana/partilhado. Em vez disso,
escolha ficheiros específicos como global.ini do diretório .snapshot e seus subdiretórios depois de
remontar o volume /hana/partilhado para PRD.
Do lado das operações, ocorrem os seguintes passos:
a. A replicação de instantâneos do volume de produção para os volumes de recuperação de desastres é
interrompida. Esta perturbação pode já ter acontecido se uma paragem no local de produção for a razão
pela qual precisa realizar o procedimento de recuperação de desastres.
b. O nome instantâneo de armazenamento ou instantâneo com o ID de reserva que escolheu é restaurado
nos volumes de recuperação de desastres.
c. Após o restauro, os volumes de recuperação de desastres estão disponíveis para serem montados nas
unidades hana large instance na região de recuperação de desastres.
5. Monte os volumes de recuperação de desastres para a unidade HANA Large Instance no local de
recuperação de desastres.
6. Inicie a ocorrência de produção sap HANA dormente.
7. Se optou por copiar registos de cópia de registos de transação para reduzir o tempo de RPO, misture as
cópias de segurança do registo de transações no novo diretório DR/hana/logbackups. Não sobrepense os
reforços existentes. Copie cópias de cópias que não foram replicadas com a mais recente replicação de um
instantâneo de armazenamento.
8. Também pode restaurar ficheiros individuais das imagens que não foram replicadas para o volume
/hana/compartilhado/PRD na região DR Azure.
Os seguintes passos mostram como recuperar a instância de produção do SAP HANA com base no instantâneo de
armazenamento restaurado e nas cópias de segurança do registo de transações disponíveis.
1. Altere a localização de reserva para /hana/logbackups utilizando o Estúdio SAP HANA.
2. SAP HANA digitaliza através dos locais de ficheiros de reserva e sugere a mais recente cópia de segurança
de registo de transações para restaurar. A varredura pode demorar alguns minutos até aparecer um ecrã
como o seguinte:
3. Ajuste algumas das definições predefinidas:
Utilização clara Cópias de Segurança Delta .
Selecione Inicialize a Área de Registo .
4. Selecione Concluir .
Uma janela de progresso, como a mostrada aqui, deve aparecer. Tenha em mente que o exemplo é de uma
recuperação de desastres restaurar uma configuração sap HANA de três nodos.
Se o restauro parar de responder no ecrã 'Acabamento' e não mostrar o ecrã de progresso, confirme que todas
as instâncias sap HANA nos nós dos trabalhadores estão em execução. Se necessário, inicie manualmente as
instâncias SAP HANA.

Failback de um DR para um local de produção


Pode falhar de um DR para um local de produção. Vejamos um cenário em que a falha no local de recuperação de
desastres foi causada por problemas na produção da região de Azure, e não pela sua necessidade de recuperar
dados perdidos.
Tens estado a gerir a tua carga de trabalho de produção da SAP há algum tempo no local de recuperação de
desastres. À medida que os problemas no local de produção são resolvidos, pretende falhar no seu local de
produção. Como não se pode perder dados, o passo de volta ao local de produção envolve várias etapas e estreita
cooperação com a equipa de operações da SAP HANA na equipa de operações da Azure. Cabe-lhe a si desencadear
a equipa de operações para começar a sincronizar de volta ao local de produção depois de os problemas serem
resolvidos.
Siga estes passos.
1. A equipa de operações da SAP HANA sobre o Azure recebe o gatilho para sincronizar os volumes de
armazenamento de produção dos volumes de armazenamento de recuperação de desastres, que representam
agora o estado de produção. Neste estado, a unidade HANA Large Instance no local de produção é encerrada.
2. A equipa de operações da SAP HANA no Azure monitoriza a replicação e certifica-se de que é apanhada antes
de o informarem.
3. Encerra as aplicações que usam a produção HANA Instance no local de recuperação de desastres. Em seguida,
efetue uma cópia de segurança de registo de transações HANA. Em seguida, para si a instância HANA que está
a funcionar nas unidades de grande instância da HANA no local de recuperação de desastres.
4. Após a ocorrência de HANA que está a funcionar na unidade HANA Large Instance no local de recuperação de
desastres, a equipa de operações sincroniza manualmente os volumes do disco novamente.
5. A equipa de operações da SAP HANA sobre o Azure volta a iniciar a unidade HANA Large Instance no local de
produção. Eles entregam-te. Certifique-se de que o caso SAP HANA está em estado de encerramento no
momento de arranque da unidade HANA Large Instance.
6. Executa a mesma base de dados restaurar os passos que fez quando falhou anteriormente no local de
recuperação de desastres.

Monitorizar a replicação da recuperação de desastres


Para monitorizar o estado do progresso da sua replicação de armazenamento, execute o script
azure_hana_replication_status . Este comando deve ser executado a partir de uma unidade que funciona no local
de recuperação de desastres para funcionar como esperado. O comando funciona independentemente de a
replicação estar ativa. O comando pode ser executado para cada unidade hana grande instância do seu inquilino
no local de recuperação de desastres. Não pode ser usado para obter detalhes sobre o volume de botas.
Para obter mais informações sobre o comando e a sua saída, consulte "Obter o estado de replicação de DR -
azure_hana_replication_status" nas ferramentas instantâneas da Microsoft para SAP HANA no Azure.

Passos seguintes
Consulte monitor e resolução de problemas do lado HANA.
Como monitorizar o SAP HANA (grandes instâncias)
no Azure
29/04/2020 • 4 minutes to read • Edit Online

O SAP HANA on Azure (Grandes Instâncias) não é diferente de qualquer outra implantação do IaaS — é necessário
monitorizar o que o SISTEMA e a aplicação estão a fazer e como as aplicações consomem os seguintes recursos:
CPU
Memória
Largura de banda de rede
Espaço em disco
Com as Máquinas Virtuais Azure, você precisa descobrir se as classes de recursos acima referidas são suficientes
ou se ficam esgotadas. Aqui está mais detalhes sobre cada uma das diferentes classes:
Consumo de recursos cpu: O rácio que o SAP definiu para determinada carga de trabalho contra a HANA é
aplicado para garantir que devem existir recursos cpu suficientes disponíveis para trabalhar através dos dados
armazenados na memória. No entanto, pode haver casos em que a HANA consome muitas CPUs executando
consultas devido a índices em falta ou questões semelhantes. Isto significa que deve monitorizar o consumo de
recursos da CPU da unidade de grandes instâncias HANA, bem como os recursos cpu consumidos pelos serviços
específicos da HANA.
Consumo de memória: É importante monitorizar de dentro da HANA, bem como fora de HANA na unidade.
Dentro da HANA, monitorize como os dados estão a consumir a memória atribuída à HANA para se manter dentro
das diretrizes de dimensionamento exigidas do SAP. Também pretende monitorizar o consumo de memória no
nível de Instância Grande para se certificar de que o software adicional não HANA instalado não consome muita
memória e, portanto, competir com hana para memória.
Largura de banda da rede: O gateway Azure VNet é limitado na largura de banda dos dados que se deslocam
para o Azure VNet, pelo que é útil monitorizar os dados recebidos por todos os VMs Azure dentro de um VNet
para descobrir a sua proximidade com os limites do portal Azure SKU selecionado. Na unidade HANA Large
Instance, faz sentido monitorizar também o tráfego de rede de entrada e saída e acompanhar os volumes que são
tratados ao longo do tempo.
Espaço em disco: O consumo de espaço em disco geralmente aumenta com o tempo. As causas mais comuns
são: aumento do volume de dados, execução de cópias de segurança de registo de transações, armazenamento de
ficheiros de vestígios e realização de instantâneos de armazenamento. Por isso, é importante monitorizar o uso do
espaço do disco e gerir o espaço do disco associado à unidade HANA Large Instance.
Para as SKUs tipo II das Grandes Instâncias HANA, o servidor vem com as ferramentas de diagnóstico do sistema
pré-carregada. Pode utilizar estas ferramentas de diagnóstico para efetuar a verificação de saúde do sistema.
Executar o seguinte comando para gerar o ficheiro de registo de verificação de saúde em /var/log/health_check.

/opt/sgi/health_check/microsoft_tdi.sh

Quando trabalha com a equipa de Suporte do Microsoft para resolver um problema, também pode ser solicitado
que forneça os ficheiros de registo utilizando estas ferramentas de diagnóstico. Pode fechar o ficheiro utilizando o
seguinte comando.
tar -czvf health_check_logs.tar.gz /var/log/health_check

Passos seguintes
Consulte como monitorizar o SAP HANA (grandes instâncias) no Azure.
Monitorizar e resolver problemas do lado do HANA
29/04/2020 • 10 minutes to read • Edit Online

A fim de analisar eficazmente os problemas relacionados com o SAP HANA em Azure (Grandes Instâncias), é útil
reduzir a causa principal de um problema. A SAP publicou uma grande quantidade de documentação para o
ajudar.
As FAQ aplicáveis relacionadas com o desempenho do SAP HANA podem ser encontradas nas seguintes notas
SAP:
Nota SAP #2222200 – FAQ: Rede SAP HANA
Nota SAP #2100040 – FAQ: CpU SAP HANA
Nota SAP #199997 – FAQ: Memória SAP HANA
Nota SAP #200000 – FAQ: Otimização de Desempenho SAP HANA
Nota SAP #199930 – FAQ: SAP HANA I/O Análise
Nota SAP #2177064 – FAQ: Reinício e Acidentes de Serviço SAP HANA

Alertas SAP HANA


Como primeiro passo, verifique os registos de alerta SAP HANA atuais. No Estúdio SAP HANA, vá à Consola de
Administração: Aler tas: Mostrar : todos os aler tas . Este separador mostrará todos os alertas SAP HANA para
valores específicos (memória física gratuita, utilização de CPU, etc.) que se situam fora dos limiares mínimos e
máximos definidos. Por padrão, as verificações são renovadas automaticamente a cada 15 minutos.

CPU
Para um alerta desencadeado devido à definição de limiar inadequada, uma resolução é repor o valor predefinido
ou um valor limiar mais razoável.
Os seguintes alertas podem indicar problemas de recursos da CPU:
Utilização do CPU anfitrião (Alerta 5)
Operação de ponto de salvamento mais recente (Alerta 28)
Duração do ponto de salvação (Alerta 54)
Pode notar um elevado consumo de CPU na sua base de dados SAP HANA a partir de uma das seguintes:
O alerta 5 (utilização do CPU hospedeiro) é aumentado para uso de CPU atual ou passado
O uso do CPU exibido no ecrã de visão geral

O gráfico de carga pode mostrar um elevado consumo de CPU, ou um consumo elevado no passado:
Um alerta desencadeado devido à elevada utilização do CPU pode ser causado por várias razões, incluindo, mas
não se limitando a: execução de determinadas transações, carregamento de dados, empregos que não estão a
responder, declarações de SQL de longa duração e mau desempenho da consulta (por exemplo, com BW em cubos
HANA).
Consulte o site SAP HANA Troubleshooting: CPU Related Causes and Solutions para obter passos detalhados de
resolução de problemas.

Sistema Operativo
Um dos controlos mais importantes para o SAP HANA no Linux é certificar-se de que as Páginas Enormes
Transparentes são desativadas, consulte sap note #2131662 – Páginas Enormes Transparentes (THP) nos
Servidores SAP HANA.
Pode verificar se as Páginas Enormes Transparentes estão ativadas através do seguinte comando Linux: cat
/sys/kernel/mm/transparente_hugepage/enabled
Se estiver sempre fechado em parênteses como abaixo, significa que as Páginas Enormes Transparentes estão
ativadas: [sempre] aconselham nunca; se nunca for fechado em parênteses como abaixo, significa que as
Páginas Enormes Transparentes são desativadas: sempre aconselhar [nunca]
O seguinte comando Linux não deve devolver nada: rpm -qa [ grep ulimit. Se parecer que o ulimit está
instalado, desinstale-o imediatamente.

Memória
Pode observar que a quantidade de memória atribuída pela base de dados SAP HANA é superior ao esperado. Os
seguintes alertas indicam problemas com elevado uso da memória:
Utilização da memória física do hospedeiro (Alerta 1)
Utilização da memória do servidor de nome (Alerta 12)
Utilização total da memória das tabelas da Loja de Colunas (Alerta 40)
Utilização da memória dos serviços (Alerta 43)
Utilização da memória do armazenamento principal das tabelas da Loja coluna (Alerta 45)
Ficheiros de despejo de tempo de execução (Alerta 46)
Consulte o site SAP HANA Troubleshooting: Memory Problems para obter passos detalhados de resolução de
problemas.

Rede
Consulte a Nota SAP #2081065 – Resolução de Problemas Da Rede SAP HANA e execute os passos de resolução
de problemas da rede nesta Nota SAP.
1. Analisando o tempo de ida e volta entre o servidor e o cliente. R. Executar o script SQL
HANA_Network_Clients.
2. Analise a comunicação interna. R. Executar script SQL HANA__Network Services.
3. Executar o comando Linux ifconfig (a saída mostra se houver perdas de pacote).
4. Executar o tcpdump de comando Linux.
Além disso, utilize a ferramenta IPERF de código aberto (ou similar) para medir o desempenho real da rede de
aplicações.
Consulte o site SAP HANA Troubleshooting: Networking Performance and Connectivity Problems para obter
passos detalhados de resolução de problemas.

Armazenamento
Do ponto de vista do utilizador final, uma aplicação (ou o sistema como um todo) funciona lentamente, não
responde, ou pode mesmo parecer parar de responder se há problemas com o desempenho de I/S. No separador
Volumes no Estúdio SAP HANA, pode ver os volumes anexados e quais os volumes utilizados por cada serviço.

Volumes anexados na parte inferior do ecrã pode ver detalhes dos volumes, tais como ficheiros e estatísticas de
I/S.

Consulte o site SAP HANA Troubleshooting: I/O Relacionado causas e soluções e resolução de problemas
Relacionados Com o Disco HANA para passos detalhados de resolução de problemas.

Ferramentas de Diagnóstico
Execute uma verificação de saúde__SAP HANA através de Minichecks de Configuração HANA. Esta ferramenta
devolve problemas técnicos potencialmente críticos que já deveriam ter sido levantados como alertas no Estúdio
SAP HANA.
Consulte a recolha de declarações SAP Note #1969700 – SQL para SAP HANA e descarregue o ficheiro SQL
Statements.zip anexado a essa nota. Guarde este ficheiro .zip no disco rígido local.
No Estúdio SAP HANA, no separador Informação do Sistema, clique à direita na coluna Nome e selecione
Impor t SQL Statements .

Selecione o ficheiro SQL Statements.zip armazenado localmente e será importada uma pasta com as
correspondentes declarações SQL. Neste ponto, os muitos controlos de diagnóstico diferentes podem ser
executados com estas declarações SQL.
Por exemplo, para testar os requisitos de largura de largura de banda do sistema SAP HANA, clique na declaração
de largura de banda em replicação: largura de banda e selecione Open na Consola SQL.
A declaração completa do SQL abre permitindo que os parâmetros de entrada (secção de modificação) sejam
alterados e executados.

Outro exemplo é clicar à direita nas declarações em Replication: Over view . Selecione Executar a partir do
menu de contexto:

Isto resulta em informações que ajudam na resolução de problemas:


Faça o mesmo_para_mini-verificações de configuração HANA e verifique se há marcas X na coluna C (Crítica).
Saídas de amostra:
Hana__Configuração_MiniChecks Rev102.01+1 para verificações gerais SAP HANA.

Visão_geral_dos ser viços da HANA para uma visão geral do que os serviços SAP HANA estão atualmente a
funcionar.

Estatísticas_de_ser viços HANA para informações de serviço SAP HANA (CPU, memória, etc.).
Visão_geral__de configuração HANA Rev110+ para informações gerais sobre a instância SAP HANA.

PARÂMETROS__de_configuração HANA Rev70+ para verificar os parâmetros SAP HANA.

Passos seguintes
Consulte a elevada disponibilidade configurada no SUSE utilizando o STONITH.
Controlo de Grandes Instâncias do Azure HANA
através do portal do Azure
28/04/2020 • 20 minutes to read • Edit Online

Este documento cobre a forma como as grandes instâncias hana são apresentadas no portal Azure e que atividades
podem ser realizadas através do portal Azure com unidades HANA Large Instance que são implantadas para si. A
visibilidade das grandes instâncias HANA no portal Azure é fornecida através de um fornecedor de recursos Azure
para as grandes instâncias HANA, que atualmente está em pré-visualização pública

Registe o fornecedor de recursos de grande instância HANA


Normalmente, a sua subscrição Azure que estava a usar para implementações de grandes instâncias HANA está
registada para o Fornecedor de Recursos de Grande Instância HANA. No entanto, se não conseguir ver que
implantou unidades hana large instance, deve registar o Fornecedor de Recursos na sua subscrição Azure. Há duas
maneiras de registar o fornecedor de recursos de grande instância HANA
Registe -se através da interface CLI
Precisa de ser registado na sua subscrição Azure, utilizada para a implementação de Big Instance HANA através da
interface Azure CLI. Pode (re-)registar o Fornecedor de Grandes Instâncias HANA com este comando:

az provider register --namespace Microsoft.HanaOnAzure

Para mais informações, consulte o artigo Fornecedores e tipos de recursos azure


Registe -se através do portal Azure
Pode (re-)registar o Fornecedor de Recursos de Grande Instância HANA através do portal Azure. Você precisa listar
a sua subscrição no portal Azure e clicar duas vezes na subscrição, que foi usada para implementar a sua unidade
de Instância Grande HANA. Um que você está na página geral da sua subscrição, selecione "Fornecedores de
recursos" como mostrado abaixo e escreva "HANA" na janela de pesquisa.

Na imagem mostrada, o fornecedor de recursos já estava registado. Caso o prestador de recursos ainda não esteja
registado, prima "re-registrar" ou "registar-se".
Para mais informações, consulte o artigo Fornecedores e tipos de recursos azure

Exposição de unidades hana large instância no portal Azure


Ao submeter um pedido de implantação de grandes instâncias HANA, é-lhe pedido que especifique a subscrição
Azure que também está a ligar às Grandes Instâncias HANA. Recomenda-se utilizar a mesma subscrição que está a
utilizar para implantar a camada de aplicação SAP que funciona contra as unidades HANA Large Instance. À medida
que os seus primeiros Casos GRANDES HANA estão a ser implantados, um novo grupo de recursos Azure é criado
na subscrição Azure que submeteu no pedido de implantação para a sua HANA Large Instance(s). O novo grupo de
recursos listará todas as suas unidades HANA Large Instance que implementou na subscrição específica.
Para encontrar o novo grupo de recursos Azure, você lista o grupo de recursos na sua subscrição navegando
através do painel de navegação esquerdo do portal Azure

Na lista de grupos de recursos, está a ser listado, pode ser necessário filtrar a subscrição que usou para ter as
Grandes Instâncias HANA implantadas

Depois de filtrar a subscrição correta, ainda pode ter uma longa lista de grupos de recursos. Procure um com uma
pós-fixação de -Txxx onde "xxx" são três dígitos, como -T050 .
Como encontrou o grupo de recursos, enumere os detalhes do mesmo. A lista que recebeu pode parecer:
Todas as unidades listadas representam uma única unidade HANA Large Instance que foi implantada na sua
subscrição. Neste caso, você olha para oito diferentes unidades HANA Large Instance, que foram implantadas na
sua subscrição.
Se você destacou vários inquilinos hana de grande instância sob a mesma subscrição Azure, você encontrará vários
grupos de recursos Azure

Veja os atributos de uma única Unidade HLI


Na lista das unidades HANA Large Instance, pode clicar numa única unidade e obter os detalhes da única unidade
HANA Large Instance.
No ecrã geral, depois de clicar em 'Mostrar mais', está a receber uma apresentação da unidade, que parece:

Olhando para os diferentes atributos mostrados, esses atributos parecem pouco diferentes dos atributos do Azure
VM. No cabeçalho do lado esquerdo, mostra o grupo Resource, a região azure, o nome da subscrição e o ID, bem
como algumas tags que acrescentou. Por predefinição, as unidades HANA Large Instance não têm etiqueta
atribuída. No lado direito do cabeçalho, o nome da unidade está listado como designado quando a colocação foi
feita. O sistema operativo é mostrado, bem como o endereço IP. Tal como acontece com os VMs, o tipo de unidade
de instância de grande instância HANA com o número de fios de CPU e memória também é mostrado. Mais
detalhes sobre as diferentes unidades hana grandes instâncias, são mostrados aqui:
SKUs Disponíveis para HLI
Arquitetura de armazenamento SAP HANA (Grandes Instâncias)
Dados adicionais no lado inferior direito é a revisão do carimbo hana large instância. Os valores possíveis são:
Revisão 3
Revisão 4
A Revisão 4 é a mais recente arquitetura lançada de HANA Grandes Instâncias com grandes melhorias na latência
da rede entre Os VMs Azure e HANA Grandes unidades de instância implantadas em selos ou linhas de revisão 4.
Outra informação muito importante encontra-se no canto inferior direito da visão geral com o nome do Grupo de
Colocação de Proximidade azure que é automaticamente criado para cada unidade DE Instância Grande HANA
implantada. Este Grupo de Colocação de Proximidade precisa de ser referenciado na implementação dos VMs
Azure que acolhem a camada de aplicação SAP. Utilizando o grupo de colocação de proximidade Azure associado à
unidade HANA Large Instance, certifique-se de que os VMs Azure são implantados nas proximidades da unidade
HANA Large Instance. A forma como os grupos de colocação de proximidade podem ser usados para localizar a
camada de aplicação SAP no mesmo centro de dados Azure como a Revisão 4 unidades de grande instância hana
hospedadas é descrita em Grupos de Colocação de Proximidade Azure para uma latência de rede ótima com
aplicações SAP.
Um campo adicional na coluna direita do cabeçalho informa sobre o estado de potência da unidade de instância
grande HANA.
NOTE
O estado de energia descreve se a unidade de hardware está desligada ou desligada. Não dá informações sobre o sistema
operativo estar a funcionar. Ao reiniciar uma unidade HANA Large Instance, sentirá um pequeno período em que o estado da
unidade muda para começar a mudar-se para o estado de Iniciado . Estar no estado de Iniciado significa que o Sistema
operativo está a começar ou que o Sistema operativo foi completamente iniciado. Como resultado, após um reinício da
unidade, não pode esperar entrar imediatamente na unidade assim que o estado mudar para Iniciado .

Se premir "Ver mais", são mostradas informações adicionais. Uma informação adicional é a revisão do carimbo
hana large instance, a unidade foi implantada. Veja o artigo O que é SAP HANA sobre Azure (Grandes Instâncias)
para as diferentes revisões dos selos hana large instância

Verifique as atividades de uma única unidade HANA Large Instance


Além de dar uma visão geral das unidades HANA Large Instance, pode verificar as atividades da unidade em
particular. Um registo de atividade pode parecer:

Uma das principais atividades registadas são o reinício de uma unidade. Os dados listados incluem o estado da
atividade, o carimbo de tempo da atividade foi desencadeado, o ID de subscrição do qual a atividade foi
desencadeada e o utilizador azure que desencadeou a atividade.
Outra atividade que está a ser registada são as alterações na unidade nos meta dados do Azure. Além do reinício
iniciado, pode ver a atividade da Write HANAInstances . Este tipo de atividade não realiza alterações na própria
unidade HANA Large Instance, mas está a documentar alterações nos meta dados da unidade em Azure. No caso
listado, adicionámos e apagamos uma etiqueta (ver secção seguinte).

Adicione e elimine uma etiqueta Azure a uma unidade HANA Large


Instance
Outra possibilidade que você tem é adicionar uma etiqueta a uma unidade HANA Large Instance. A forma como as
etiquetas estão a ser atribuídas não difere da atribuição de etiquetas a VMs. Tal como acontece com os VMs, as
etiquetas existem em meta dados Azure e, para as grandes instâncias HANA, têm as mesmas restrições que as
etiquetas para VMs.
As etiquetas de aparação funcionam da mesma forma que com os VMs. Ambas as atividades, aplicação e abater
uma etiqueta serão listadas no registo de atividade da unidade de grande instância HANA.

Verifique as propriedades de uma unidade HANA Large Instance


A secção Propriedades inclui informações importantes que obtém quando as instâncias são entregues a si. É uma
secção onde obtém toda a informação que pode necessitar em casos de suporte ou que precisa ao configurar a
configuração do instantâneo de armazenamento. Como tal, esta secção é uma recolha de dados em torno da sua
instância, a conectividade da instância com o Azure e o backend de armazenamento. O topo da secção parece:
Os primeiros itens de dados já viram no ecrã geral. Mas uma parte importante dos dados é o ID do Circuito
ExpressRoute, que obteve quando as primeiras unidades implantadas foram entregues. Em alguns casos de apoio,
pode ser-lhe pedido esses dados. Uma entrada de dados importante é mostrada na parte inferior da imagem. Os
dados apresentados são o endereço IP da cabeça de armazenamento NFS que isola o seu armazenamento ao seu
inquilino na pilha de grandes instâncias HANA. Este endereço IP também é necessário quando edita o ficheiro de
configuração para cópias de segurança instantâneasde armazenamento .
À medida que percorre o painel de propriedades, obtém dados adicionais como um ID de recurso único para a sua
unidade HANA Large Instance, ou o ID de subscrição que foi atribuído à implementação.

Reiniciar uma unidade HANA Large Instance através do portal Azure


Iniciando um reinício do sistema operativo Linux, houve várias situações em que o Sistema operativo não
conseguiu terminar um reinício com sucesso. Para forçar um reinício, foi necessário abrir um pedido de serviço
para que as operações da Microsoft realizassem um reinício de energia da unidade HANA Large Instance. A
funcionalidade de um reinício de potência de uma unidade HANA Large Instance está agora integrada no portal
Azure. Como está na parte geral da unidade HANA Large Instance, vê o botão para reiniciar em cima da secção de
dados

Ao premir o botão de reinício, é-lhe perguntado se realmente quer reiniciar a unidade. Como confirmar premindo o
botão "Sim", a unidade reiniciará.

NOTE
No processo de reinício, você vai experimentar um pequeno período em que o estado da unidade muda para começar a
mover-se para o estado de Iniciado . Estar no estado de Iniciado significa que o Sistema operativo está a começar ou que o
Sistema operativo foi completamente iniciado. Como resultado, após um reinício da unidade, não pode esperar entrar
imediatamente na unidade assim que o estado mudar para Iniciado .

IMPORTANT
Dependendo da quantidade de memória na sua unidade HANA Large Instance, um reinício e reinício do hardware e do
sistema operativo pode demorar até uma hora

Abra um pedido de apoio para grandes instâncias HANA


Fora da exposição do portal Azure de unidades HANA Large Instance, você pode criar pedidos de suporte
especificamente para uma unidade de grande instância HANA também. À medida que segue o link Novo pedido
de suporte

Para obter o serviço de SAP HANA Grandes Instâncias listados no próximo ecrã, você pode precisar selecionar 'All
Services' como mostrado abaixo

Na lista de serviços, pode encontrar o serviço SAP HANA Large Instance . Ao escolher esse serviço, pode
selecionar tipos de problemas específicos como mostrado:
Em cada um dos diferentes tipos de problemas, é-lhe oferecida uma seleção de subtipos de problemas que precisa
de selecionar para caracterizar ainda mais o seu problema. Depois de selecionar o subtipo, pode agora nomear o
sujeito. Uma vez terminado o processo de seleção, pode passar para o próximo passo da criação. Na secção
Soluções, é apontado para documentação em torno de HANA Grandes Instâncias, o que pode dar um ponteiro
para uma solução do seu problema. Se não encontrar uma solução para o seu problema na documentação
sugerida, vá para o próximo passo. No próximo passo, ser-lhe-ão questionados se o problema é com VMs ou com
unidades HANA Large Instance. Esta informação ajuda a direcionar o pedido de apoio aos especialistas corretos.
À medida que respondia às perguntas e forneceu detalhes adicionais, pode dar o próximo passo para rever o
pedido de apoio e submetê-lo.

Passos seguintes
Como monitorizar o SAP HANA (grandes instâncias) no Azure
Monitorizar e resolver problemas do lado do HANA
High availability set up in SUSE using the STONITH
(Utilizar STONITH para configurar a elevada
disponibilidade em SUSE)
29/04/2020 • 21 minutes to read • Edit Online

Este documento fornece as instruções detalhadas passo a passo para configurar o sistema operativo De Alta
Disponibilidade no Sistema Operativo SUSE utilizando o dispositivo STONITH.
Isenção de responsabilidade: Este guia é derivado testando a configuração no ambiente Microsoft HANA Large
Instances, que funciona com sucesso. Uma vez que a equipa de Gestão de Serviços da Microsoft para as grandes
instâncias hana não suporta o sistema operativo, poderá ter de contactar a SUSE para mais resolução de
problemas ou esclarecimentos sobre a camada do sistema operativo. A equipa de gestão de serviços da Microsoft
configura o dispositivo STONITH e suporta totalmente e pode estar envolvida para resolução de problemas para
problemas com dispositivos STONITH.

Descrição geral
Para configurar a alta disponibilidade utilizando o agrupamento SUSE, os seguintes pré-requisitos devem
satisfazer.
Pré -requisitos
HANA Grandes Instâncias são provisionadas
Sistema operativo está registado
Os servidores HANA Large Instances estão ligados ao servidor SMT para obter patches/pacotes
O sistema operativo tem as últimas correções instaladas
NTP (servidor de tempo) está configurado
Leia e compreenda a mais recente versão da documentação suse na configuração ha
Detalhes da configuração
Este guia utiliza a seguinte configuração:
Sistema Operativo: SLES 12 SP1 para SAP
GRANDES Instâncias HANA: 2xS192 (quatro tomadas, 2 TB)
Versão HANA: HANA 2.0 SP1
Nomes do servidor: sapprdhdb95 (nó1) e sapprdhdb96 (nó2)
Dispositivo STONITH: dispositivo STONITH baseado em iSCSI
NTP configurado em um dos nódosos de grande instância HANA
Quando configurar as grandes instâncias HANA com hSR, pode solicitar à equipa de Gestão de Serviços da
Microsoft que configurar a STONITH. Se já é um cliente existente que tem as grandes instâncias HANA
aprovisionadas e precisa de dispositivo STONITH configurado para as suas lâminas existentes, precisa fornecer as
seguintes informações à equipa de Gestão de Serviços da Microsoft no formulário de pedido de serviço (SRF).
Pode solicitar o formulário SRF através do Gestor de Conta Técnica ou do seu Contacto Microsoft para o embarque
de big instância HANA. Os novos clientes podem solicitar o dispositivo STONITH no momento do fornecimento. Os
inputs estão disponíveis no formulário de pedido de provisionamento.
Nome do servidor e endereço IP do servidor (por exemplo, myhanaserver1, 10.35.0.1)
Localização (por exemplo, US East)
Nome do Cliente (por exemplo, Microsoft)
SID - Identificador de sistema HANA (por exemplo, H11)
Uma vez configurado o dispositivo STONITH, a equipa de Gestão de Serviços da Microsoft fornece-lhe o nome do
dispositivo SBD e o endereço IP do armazenamento iSCSI, que pode utilizar para configurar a configuração do
STONITH.
Para configurar o fim até ao fim do HA utilizando o STONITH, devem ser seguidos os seguintes passos:
1. Identificar o dispositivo SBD
2. Inicializar o dispositivo SBD
3. Configurar o Cluster
4. Configurar o Cão de Guarda Softdog
5. Junte-se ao nó ao aglomerado
6. Validar o cluster
7. Configure os recursos para o cluster
8. Testar o processo de failover

1. Identificar o dispositivo SBD


Esta secção descreve como determinar o dispositivo SBD para a sua configuração depois de a equipa de gestão de
serviços da Microsoft ter configurado o STONITH. Esta secção aplica-se apenas ao cliente existente. Se for
um novo cliente, a equipa de gestão de serviços da Microsoft fornece-lhe o nome do dispositivo SBD e pode
ignorar esta secção.
1.1 Modificar /etc/iscsi/initiatornae.isci para

iqn.1996-04.de.suse:01:<Tenant><Location><SID><NodeNumber>

A gestão do serviço da Microsoft fornece esta corda. Modifique o ficheiro em ambos os nós, no entanto o número
do nó é diferente em cada nó.

1.2 Modificar /etc/iscsi/iscsid.conf: Definir o nó.session.timeo.replacement_timeout=5 e nó.startup = automático.


Modifique o ficheiro em ambos os nós.
1.3 Execute o comando de descoberta, mostra quatro sessões. Passa-o em ambos os nós.

iscsiadm -m discovery -t st -p <IP address provided by Service Management>:3260


1.4 Execute o comando para iniciar sessão no dispositivo iSCSI, mostra quatro sessões. Passa-o em ambos os nós.

iscsiadm -m node -l

1.5 Executar o guião rescano: rescan-scsi-bus.sh. Este guião mostra-lhe os novos discos criados para si. Passa-o em
ambos os nós. Deve ver um número LUN superior a zero (por exemplo: 1, 2 etc.)

rescan-scsi-bus.sh

1.6 Para que o nome do dispositivo seja executado o disco de comando (l. ). Passa-o em ambos os nós. Escolha o
dispositivo com o tamanho de 178 MiB .

fdisk –l

2. Inicializar o dispositivo SBD


2.1 Inicializar o dispositivo SBD em ambos os nós

sbd -d <SBD Device Name> create


2.2 Verifique o que foi escrito no dispositivo. Faça-o em ambos os nós

sbd -d <SBD Device Name> dump

3. Configurar o Cluster
Esta secção descreve os passos para configurar o cluster SUSE HA.
3.1 Instalação de pacotes
3.1.1 Verifique se estão instalados ha_sles e os padrões SAPHanaSR-doc. Se não estiver instalado, instale-os.
Instale-o em ambos os nós.

zypper in -t pattern ha_sles


zypper in SAPHanaSR SAPHanaSR-doc

3.2 Configuração do cluster


3.2.1 Pode utilizar o comando ha-cluster-init ou utilizar o assistente yast2 para configurar o cluster. Neste caso, o
feiticeiro yast2 é usado. Você executa este passo apenas no nó primário.
Siga yast2> Alta
Clique em cancelar uma vez que o pacote halk2 já está instalado.

Clique em Continuar
Valor esperado=Número de nós implantados (neste

yast-Cluster-Security.png Clique Próximo


Adicione nomes de nó e clique em "Adicionar ficheiros sugeridos"
Clique em "Ligar csync2 ON"
Clique em "Generate Pre-Shared-Keys", mostra abaixo popup

Clique OK
A autenticação é realizada utilizando os endereços IP e as teclas pré-partilhadas em Csync2. O ficheiro chave é
gerado com csync2 -k /etc/csync2/key_hagroup. O ficheiro key_hagroup deve ser copiado para todos os membros
do cluster manualmente após a sua criação. Cer tifique-se de copiar o ficheiro do nó 1 ao nó2 .
Clique em Next

Na opção padrão, o Booting estava desligado, mude-o para "on" para que o pacemaker seja iniciado no arranque.
Pode fazer a escolha com base nos seus requisitos de configuração. Clique em Seguinte e a configuração do
cluster está completa.

4. Configurar o Cão de Guarda Softdog


Esta secção descreve a configuração do cão de guarda (softdog).
4.1 Adicione a seguinte linha a /etc/init.d/boot.local em ambos os nós.

modprobe softdog
4.2 Atualize o ficheiro /etc/sysconfig/sbd em ambos os nós como seguintes:

SBD_DEVICE="<SBD Device Name>"

4.3 Carregue o módulo kernel em ambos os nós, executando o seguinte comando

modprobe softdog

4.4 Verifique e certifique-se de que o softdog está a correr como seguindo em ambos os nós:

lsmod | grep dog

4.5 Inicie o dispositivo SBD em ambos os nós

/usr/share/sbd/sbd.sh start

4.6 Teste o daemon SBD em ambos os nós. Vê-se duas entradas depois de configurá-la em ambos os nós

sbd -d <SBD Device Name> list


4.7 Envie uma mensagem de teste a um dos seus nódosos

sbd -d <SBD Device Name> message <node2> <message>

4.8 No segundo nó (nó2) pode verificar o estado da mensagem

sbd -d <SBD Device Name> list

4.9 Para adotar a config dsíbe, atualize o ficheiro /etc/sysconfig/sbd como seguinte. Atualize o ficheiro em ambos
os nós

SBD_DEVICE=" <SBD Device Name>"


SBD_WATCHDOG="yes"
SBD_PACEMAKER="yes"
SBD_STARTMODE="clean"
SBD_OPTS=""

4.10 Inicie o serviço de pacemaker no nó primário (nó1)

systemctl start pacemaker

Se o serviço pacemaker falhar, consulte o Cenário 5: O serviço Pacemaker falha

5. Aderir ao cluster
Esta secção descreve como juntar o nó ao cluster.
5.1 Adicione o nó
Executar o seguinte comando no nó2 para deixar o nó2 juntar-se ao cluster.

ha-cluster-join

Se receber um erro durante a junção do cluster, consulte o Cenário 6: Nó 2 incapaz de se juntar ao cluster.

6. Validação do cluster
6.1 Inicie o serviço de cluster
Para verificar e iniciar opcionalmente o cluster pela primeira vez em ambos os nós.

systemctl status pacemaker


systemctl start pacemaker

6.2 Monitorizar o estado


Execute o comando crm_mon para garantir que ambos os nós estão on-line. Pode executá-lo em qualquer um
dos nós do cluster

crm_mon

Também pode iniciar sessão no hawk para verificar o estado do cluster https://<nó IP>:7630. O utilizador
predefinido é hacluster e a palavra-passe é linux. Se necessário, pode alterar a palavra-passe utilizando o comando
passwd.

7. Configurar propriedades e recursos de cluster


Esta secção descreve os passos para configurar os recursos do cluster. Neste exemplo, configurar o seguinte
recurso, o resto pode ser configurado (se necessário) fazendo referência ao guia SUSE HA. Execute o config apenas
num dos nódosos. Faça no nó principal.
Armadilha de botas cluster
Dispositivo STONITH
O endereço IP virtual
7.1 Aprisionação de botas cluster e muito mais
Adicione a armadilha de botas de cluster. Crie o ficheiro e adicione o texto como seguinte:

sapprdhdb95:~ # vi crm-bs.txt
# enter the following to crm-bs.txt
property $id="cib-bootstrap-options" \
no-quorum-policy="ignore" \
stonith-enabled="true" \
stonith-action="reboot" \
stonith-timeout="150s"
rsc_defaults $id="rsc-options" \
resource-stickiness="1000" \
migration-threshold="5000"
op_defaults $id="op-options" \
timeout="600"

Adicione a configuração ao cluster.

crm configure load update crm-bs.txt

7.2 Dispositivo STONITH


Adicione recurso STONITH. Crie o ficheiro e adicione o texto como seguinte.

# vi crm-sbd.txt
# enter the following to crm-sbd.txt
primitive stonith-sbd stonith:external/sbd \
params pcmk_delay_max="15"

Adicione a configuração ao cluster.

crm configure load update crm-sbd.txt

7.3 O endereço IP virtual


Adicione o IP virtual de recursos. Crie o ficheiro e adicione o texto como abaixo.

# vi crm-vip.txt
primitive rsc_ip_HA1_HDB10 ocf:heartbeat:IPaddr2 \
operations $id="rsc_ip_HA1_HDB10-operations" \
op monitor interval="10s" timeout="20s" \
params ip="10.35.0.197"

Adicione a configuração ao cluster.

crm configure load update crm-vip.txt

7.4 Validar os recursos


Quando se dirige o comando crm_mon, pode-se ver os dois recursos.
Além disso, pode ver o estado no endereço IP do nó https://<>:7630/cib/live/state

8. Testar o processo de failover


Para testar o processo de failover, pare o serviço de pacemaker no nó1 e os recursos falham no nó2.

Service pacemaker stop

Agora, pare o serviço de pacemaker no nó2 e os recursos falharam no nó1


Antes do fracasso

Depois do fracasso
9. Resolução de problemas
Esta secção descreve os poucos cenários de falha, que podem ser encontrados durante a configuração. Pode não
necessariamente encarar estas questões.
Cenário 1: Nó de cluster não online
Se algum dos nós não aparecer online no cluster manager, pode tentar segui-lo online.
Inicie o serviço iSCSI

service iscsid start

E agora você deve ser capaz de iniciar sessão naquele nó iSCSI

iscsiadm -m node -l

A saída esperada parece seguir

sapprdhdb45:~ # iscsiadm -m node -l


Logging in to [iface: default, target: iqn.1992-08.com.netapp:hanadc11:1:t020, portal: 10.250.22.11,3260]
(multiple)
Logging in to [iface: default, target: iqn.1992-08.com.netapp:hanadc11:1:t020, portal: 10.250.22.12,3260]
(multiple)
Logging in to [iface: default, target: iqn.1992-08.com.netapp:hanadc11:1:t020, portal: 10.250.22.22,3260]
(multiple)
Logging in to [iface: default, target: iqn.1992-08.com.netapp:hanadc11:1:t020, portal: 10.250.22.21,3260]
(multiple)
Login to [iface: default, target: iqn.1992-08.com.netapp:hanadc11:1:t020, portal: 10.250.22.11,3260]
successful.
Login to [iface: default, target: iqn.1992-08.com.netapp:hanadc11:1:t020, portal: 10.250.22.12,3260]
successful.
Login to [iface: default, target: iqn.1992-08.com.netapp:hanadc11:1:t020, portal: 10.250.22.22,3260]
successful.
Login to [iface: default, target: iqn.1992-08.com.netapp:hanadc11:1:t020, portal: 10.250.22.21,3260]
successful.

Cenário 2: yast2 não mostra vista gráfica


O ecrã gráfico yast2 é usado para configurar o cluster de alta disponibilidade neste documento. Se o yast2 não
abrir com a janela gráfica como mostrado e lançar erro Qt, execute os passos como se seguisse. Se abrir com a
janela gráfica, pode saltar os degraus.
Erro

Saída esperada

Se o yast2 não abrir com a vista gráfica, siga os passos seguintes.


Instale os pacotes necessários. Tem de ser registado como "raiz" do utilizador e ter SMT configurado para
descarregar/instalar as embalagens.
Para instalar os pacotes, utilize o yast>Software>Software Management>Dependencies> opção "Instalar pacotes
recomendados...". A imagem que se segue ilustra os ecrãs esperados.

NOTE
Você precisa realizar os passos em ambos os nós, para que você possa aceder à vista gráfica yast2 de ambos os nós.

Sob Dependências, selecione "Instalar pacotes recomendados"


Reveja as alterações e bata OK

A instalação

Clique em Seguinte
Clique em Terminar
Também precisa de instalar os pacotes libqt4 e libyui-qt.

zypper -n install libqt4

zypper -n install libyui-qt

Yast2 deve ser capaz de abrir a vista gráfica agora, como mostrado aqui.
Cenário 3: yast2 não tem opção de Alta Disponibilidade
Para que a opção de Alta Disponibilidade seja visível no centro de controlo yast2, é necessário instalar as
embalagens adicionais.
Utilização do Yast2>software>gestão de software>Selecione os seguintes padrões
Base de servidor SAP HANA
Compilador C/C++
Elevada disponibilidade
Base do servidor de aplicação SAP
O ecrã seguinte mostra os passos para instalar os padrões.
Utilização de yast2 > Software > Software Management
Selecione os padrões

Clique em Aceitar
Clique em Continuar

Clique em seguida quando a instalação estiver concluída


Cenário 4: Instalação HANA falha com erro de conjuntos gcc
A instalação HANA falha com o seguinte erro.

Para corrigir o problema, é necessário instalar bibliotecas (libgcc_sl e libstdc++6) como a seguir.
Cenário 5: Falha no serviço pacemaker
O seguinte problema ocorreu durante o início do serviço do pacemaker.

sapprdhdb95:/ # systemctl start pacemaker


A dependency job for pacemaker.service failed. See 'journalctl -xn' for details.

sapprdhdb95:/ # journalctl -xn


-- Logs begin at Thu 2017-09-28 09:28:14 EDT, end at Thu 2017-09-28 21:48:27 EDT. --
Sep 28 21:48:27 sapprdhdb95 corosync[68812]: [SERV ] Service engine unloaded: corosync configuration map
Sep 28 21:48:27 sapprdhdb95 corosync[68812]: [QB ] withdrawing server sockets
Sep 28 21:48:27 sapprdhdb95 corosync[68812]: [SERV ] Service engine unloaded: corosync configuration ser
Sep 28 21:48:27 sapprdhdb95 corosync[68812]: [QB ] withdrawing server sockets
Sep 28 21:48:27 sapprdhdb95 corosync[68812]: [SERV ] Service engine unloaded: corosync cluster closed pr
Sep 28 21:48:27 sapprdhdb95 corosync[68812]: [QB ] withdrawing server sockets
Sep 28 21:48:27 sapprdhdb95 corosync[68812]: [SERV ] Service engine unloaded: corosync cluster quorum se
Sep 28 21:48:27 sapprdhdb95 corosync[68812]: [SERV ] Service engine unloaded: corosync profile loading s
Sep 28 21:48:27 sapprdhdb95 corosync[68812]: [MAIN ] Corosync Cluster Engine exiting normally
Sep 28 21:48:27 sapprdhdb95 systemd[1]: Dependency failed for Pacemaker High Availability Cluster Manager
-- Subject: Unit pacemaker.service has failed
-- Defined-By: systemd
-- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit pacemaker.service has failed.
--
-- The result is dependency.
sapprdhdb95:/ # tail -f /var/log/messages
2017-09-28T18:44:29.675814-04:00 sapprdhdb95 corosync[57600]: [QB ] withdrawing server sockets
2017-09-28T18:44:29.676023-04:00 sapprdhdb95 corosync[57600]: [SERV ] Service engine unloaded: corosync
cluster closed process group service v1.01
2017-09-28T18:44:29.725885-04:00 sapprdhdb95 corosync[57600]: [QB ] withdrawing server sockets
2017-09-28T18:44:29.726069-04:00 sapprdhdb95 corosync[57600]: [SERV ] Service engine unloaded: corosync
cluster quorum service v0.1
2017-09-28T18:44:29.726164-04:00 sapprdhdb95 corosync[57600]: [SERV ] Service engine unloaded: corosync
profile loading service
2017-09-28T18:44:29.776349-04:00 sapprdhdb95 corosync[57600]: [MAIN ] Corosync Cluster Engine exiting
normally
2017-09-28T18:44:29.778177-04:00 sapprdhdb95 systemd[1]: Dependency failed for Pacemaker High Availability
Cluster Manager.
2017-09-28T18:44:40.141030-04:00 sapprdhdb95 systemd[1]: [/usr/lib/systemd/system/fstrim.timer:8] Unknown
lvalue 'Persistent' in section 'Timer'
2017-09-28T18:45:01.275038-04:00 sapprdhdb95 cron[57995]: pam_unix(crond:session): session opened for user
root by (uid=0)
2017-09-28T18:45:01.308066-04:00 sapprdhdb95 CRON[57995]: pam_unix(crond:session): session closed for user
root

Para corrigi-lo, elimine a seguinte linha do ficheiro /usr/lib/systemd/system/fstrim.timer

Persistent=true

Cenário 6: Nó 2 incapaz de aderir ao cluster


Ao juntar o nó2 ao aglomerado existente utilizando o comando de junção ha-cluster, ocorreu o seguinte erro.

ERROR: Can’t retrieve SSH keys from <Primary Node>

Para corrigir, executar o seguinte em ambos os nós

ssh-keygen -q -f /root/.ssh/id_rsa -C 'Cluster Internal' -N ''


cat /root/.ssh/id_rsa.pub >> /root/.ssh/authorized_keys
Após a correção anterior, o nó2 deve ser adicionado ao cluster

10. Documentação Geral


Pode encontrar mais informações sobre a configuração da SUSE HA nos seguintes artigos:
Cenário otimizado de desempenho sAP HANA SR
Esgrima baseada em armazenamento
Blog - Utilização do Cluster Pacemaker para SAP HANA- Parte 1
Blog - Usando o Cluster Pacemaker para SAP HANA- Parte 2
Backup osS e restauro para SKUs tipo II de carimbos
de Revisão 3
29/04/2020 • 4 minutes to read • Edit Online

Este documento descreve os passos para executar uma cópia de segurança do nível de ficheiro do sistema
operativo e restaurar para as SKUs tipo II das Grandes Instâncias HANA da Revisão 3.

IMPORTANT
Este ar tigo não se aplica às implantações do Tipo II SKU em selos de grande instância HANA. Boot LUNS of
Type II HANA Grandes unidades de instância que são implantadas em carimbos de grande instância HANA revisão podem ser
apoiados com instantâneos de armazenamento, como é o caso das SKUs tipo I já em carimbos de Revisão 3

NOTE
Os scripts de backup DO OS utilizam o software ReaR, que está pré-instalado no servidor.

Após a disponibilização estar Service Management completa da equipa da Microsoft, por padrão, o servidor é
configurado com dois horários de backup para fazer o backup do nível do sistema de ficheiros no detrás do
sistema operativo. Pode verificar os horários dos trabalhos de backup utilizando o seguinte comando:

#crontab –l

Pode alterar o horário de cópia de segurança a qualquer momento utilizando o seguinte comando:

#crontab -e

Como fazer uma cópia manual?


A cópia de segurança do sistema de ficheiros S está agendada usando um trabalho de cron. No entanto, também
pode executar manualmente o nível de cópia de segurança do nível de ficheiro do sistema operativo. Para efetuar
uma cópia de segurança manual, execute o seguinte comando:

#rear -v mkbackup

O seguinte ecrã mostra a cópia de segurança manual da amostra:


Como restaurar uma reserva?
Pode restaurar uma cópia de segurança completa ou um ficheiro individual a partir da cópia de segurança. Para
restaurar, utilize o seguinte comando:

#tar -xvf <backup file> [Optional <file to restore>]

Após a restauração, o ficheiro é recuperado no atual diretório de trabalho.


O comando seguinte mostra a restauração de um ficheiro /etc/fstab da cópia de segurança do ficheiro de
reserva.tar.gz

#tar -xvf /osbackups/hostname/backup.tar.gz etc/fstab

NOTE
Tem de copiar o ficheiro para a localização desejada depois de restaurado a partir da cópia de segurança.

A imagem seguinte mostra a restauração de uma cópia de segurança completa:

Como instalar a ferramenta ReaR e alterar a configuração?


Os pacotes Relax-and-Recover (ReaR) são pré-instalados no Tipo II SKUs de grandes instâncias HANA, e
nenhuma ação necessária de si. Pode começar a utilizar diretamente o ReaR para a cópia de segurança do sistema
operativo. No entanto, nas circunstâncias em que necessita de instalar as embalagens por si só, pode seguir os
passos listados para instalar e configurar a ferramenta ReaR.
Para instalar as embalagens de backup ReaR, utilize os seguintes comandos:
Para o sistema operativo SLES, utilize o seguinte comando:

#zypper install <rear rpm package>

Para o sistema operativo RHEL, utilize o seguinte comando:


#yum install rear -y

Para configurar a ferramenta ReaR, é necessário atualizar os parâmetros OUTPUT_URL e BACKUP_URL no


ficheiro /etc/traseira/local.conf.

OUTPUT=ISO
ISO_MKISOFS_BIN=/usr/bin/ebiso
BACKUP=NETFS
OUTPUT_URL="nfs://nfsip/nfspath/"
BACKUP_URL="nfs://nfsip/nfspath/"
BACKUP_OPTIONS="nfsvers=4,nolock"
NETFS_KEEP_OLD_BACKUP_COPY=
EXCLUDE_VG=( vgHANA-data-HC2 vgHANA-data-HC3 vgHANA-log-HC2 vgHANA-log-HC3 vgHANA-shared-HC2 vgHANA-shared-HC3
)
BACKUP_PROG_EXCLUDE=("${BACKUP_PROG_EXCLUDE[@]}" '/media' '/var/tmp/*' '/var/crash' '/hana' '/usr/sap'
‘/proc’)

A seguinte imagem mostra a restauração de uma cópia de segurança completa:


Ativar o serviço Kdump
21/06/2020 • 4 minutes to read • Edit Online

Este documento descreve os detalhes sobre como ativar o serviço Kdump em Azure HANA Large Instance (Tipo I e
Tipo II).

SKUs apoiados
T IP O H A N A L A RGE
IN STA N C E F O RN EC EDO R DE O S VERSÃ O PA C OT E DE SO SK U

Tipo I Rio Suse SLES 12 SP3 S224m

Tipo I Rio Suse SLES 12 SP4 S224m

Tipo I Rio Suse SLES 12 SP2 S72

Tipo I Rio Suse SLES 12 SP2 S72m

Tipo I Rio Suse SLES 12 SP3 S72m

Tipo I Rio Suse SLES 12 SP2 S96

Tipo I Rio Suse SLES 12 SP3 S96

Tipo I Rio Suse SLES 12 SP2 S192

Tipo I Rio Suse SLES 12 SP3 S192

Tipo I Rio Suse SLES 12 SP4 S192

Tipo I Rio Suse SLES 12 SP2 S192m

Tipo I Rio Suse SLES 12 SP3 S192m

Tipo I Rio Suse SLES 12 SP4 S192m

Tipo I Rio Suse SLES 12 SP2 S144

Tipo I Rio Suse SLES 12 SP3 S144

Tipo I Rio Suse SLES 12 SP2 S144m

Tipo I Rio Suse SLES 12 SP3 S144m

Tipo II Rio Suse SLES 12 SP2 S384

Tipo II Rio Suse SLES 12 SP3 S384


T IP O H A N A L A RGE
IN STA N C E F O RN EC EDO R DE O S VERSÃ O PA C OT E DE SO SK U

Tipo II Rio Suse SLES 12 SP4 S384

Tipo II Rio Suse SLES 12 SP2 S384xm

Tipo II Rio Suse SLES 12 SP3 S384xm

Tipo II Rio Suse SLES 12 SP4 S384xm

Tipo II Rio Suse SLES 12 SP2 S576m

Tipo II Rio Suse SLES 12 SP3 S576m

Tipo II Rio Suse SLES 12 SP4 S576m

Pré-requisitos
O serviço Kdump usa /var/crash diretório para escrever despejos, certifique-se de que a partição corresponde
a este diretório tem espaço suficiente para acomodar despejos.

Detalhes da configuração
O script para ativar kdump pode ser encontrado aqui
Execute este script em HANA Large Instance usando o comando abaixo

NOTE
privilégio sudo necessário para executar este comando.

sudo bash enable-kdump.sh

Se as saídas de comando Kdump estiverem ativadas com sucesso, reinicie o sistema para aplicar a alteração,
então o Kdump está ativado com sucesso. Reinicie o sistema para aplicar alterações.
Se a saída do comando não for conseguida para fazer determinada operação, sair!!!!, então o serviço Kdump
não está ativado. Consulte a questão de suporte dasecção .

Teste Kdump
NOTE
Abaixo da operação irá desencadear uma falha no núcleo e reiniciar o sistema.

Desencadear um acidente de núcleo

echo c > /proc/sysrq-trigger

Depois de o sistema reiniciar com sucesso, verifique se o /var/crash diretório se verifica se há registos de
colisão com o kernel.
Se o /var/crash diretório tiver diretório com a data atual, então o Kdump está habilitado com sucesso.

Questão de apoio
Se o script falhar com um erro ou o Kdump não estiver ativado, aumente o pedido de serviço com a equipa de
suporte da Microsoft com os seguintes detalhes.
ID de assinatura HLI
Nome do servidor
Fornecedor de OS
Versão do SO
Versão de kernel
Atualização do sistema operativo
28/04/2020 • 7 minutes to read • Edit Online

Este documento descreve os detalhes sobre as atualizações do sistema operativo nas Grandes Instâncias HANA.

NOTE
A atualização do OS é da responsabilidade do cliente, o suporte de operações da Microsoft pode guiá-lo para as áreas-
chave para ter cuidado durante a atualização. Deve consultar o fornecedor do seu sistema operativo também antes de
planear uma atualização.

Durante o fornecimento da unidade HLI, a equipa de operações da Microsoft instala o sistema operativo. Ao longo
do tempo, é-lhe exigido que mantenha o sistema operativo (Exemplo: Remendar, afinar, atualizar, etc.) na unidade
HLI.
Antes de fazer grandes alterações no sistema operativo (por exemplo, Upgrade SP1 para SP2), precisa de
contactar a equipa da Microsoft Operations abrindo um bilhete de suporte para consultar.
Inclua no seu bilhete:
O seu ID de subscrição do HLI.
O nome do seu servidor.
O nível de remendo que está a planear aplicar.
A data em que está saciando esta mudança.
Recomendamos que abra este bilhete pelo menos uma semana antes da data de upgrade desejável devido à
verificação da equipa de Operações se será necessária uma atualização de firmware na lâmina do seu servidor.
Para a matriz de suporte das diferentes versões SAP HANA com as diferentes versões Linux, consulte SAP Note
#2235581.

Problemas conhecidos
Seguem-se as poucas questões conhecidas comuns durante a atualização:
Na classe SKU Type II SKU, o software de fundação de software (SFS) é removido após a atualização do OS. É
necessário reinstalar o SFS compatível após a atualização do OS.
Os condutores de cartões Ethernet (ENIC e FNIC) voltaram para a versão mais antiga. É necessário reinstalar a
versão compatível dos controladores após a atualização.

Configuração recomendada por SAP HANA (Tipo I)


A configuração do sistema operativo pode derivar das definições recomendadas ao longo do tempo devido a
remendos, atualizações do sistema e alterações feitas pelos clientes. Além disso, a Microsoft identifica as
atualizações necessárias para os sistemas existentes para garantir que estão idealmente configuradas para o
melhor desempenho e resiliência. Seguindo instruções delineia recomendações que abordam o desempenho da
rede, a estabilidade do sistema e o ótimo desempenho hana.
Versões compatíveis de controlador eNIC/fNIC
Para ter um desempenho adequado da rede e estabilidade do sistema, é aconselhável garantir que a versão
adequada dos controladores eNIC e fNIC específicos do OS são instaladas como descrito na tabela de
compatibilidade sinuosa. Os servidores são entregues aos clientes com versões compatíveis. Note que, em alguns
casos, durante a correção de OS/Kernel, os condutores podem ser reenrolados de volta para as versões padrão do
controlador. Certifique-se de que a versão adequada do condutor está a executar operações de remendo pós
OS/Kernel.

VERSÃ O DO PA C OT E VERSÃ O DO
F O RN EC EDO R DE O S O SSO F IRM WA RE EN IC DRIVER F N IC DRIVER

SuSE SLES 12 SP2 3.1.3h 2.3.0.40 1.6.0.34

SuSE SLES 12 SP3 3.1.3h 2.3.0.44 1.6.0.36

SuSE SLES 12 SP4 3.2.3i 2.3.0.47 2.0.0.54

SuSE SLES 12 SP2 3.2.3i 2.3.0.45 1.6.0.37

SuSE SLES 12 SP3 3.2.3i 2.3.0.45 1.6.0.37

Red Hat RHEL 7.2 3.1.3h 2.3.0.39 1.6.0.34

Comandos para upgrade do condutor e para limpar pacotes antigos da RPM


Comando para verificar os controladores instalados existentes

rpm -qa | grep enic/fnic

Eliminar as rpm eNIC/fNIC existentes

rpm -e <old-rpm-package>

Instale as embalagens recomendadas de controlador eNIC/fNIC

rpm -ivh <enic/fnic.rpm>

Comandos para confirmar a instalação

modinfo enic
modinfo fnic

Falha na atualização suSE HLIs GRUB


SAP em 14 grandes instâncias (Tipo I) pode estar em estado não-sabotável após a atualização. O procedimento
abaixo corrige esta questão.
Passos de Execução
Executar multipath -ll o comando.
Obtenha o ID LUN cujo tamanho seja de aproximadamente 50G ou utilize o comando: fdisk -l | grep mapper
Atualizar /etc/default/grub_installdevice ficheiro /dev/mapper/<LUN ID> com linha . Exemplo:
/dev/mapper/3600a09803830372f483f495242534a56

NOTE
O ID LUN varia de servidor para servidor.

EDAC DEsativado
O módulo de deteção e correção de erros (EDAC) ajuda a detetar e corrigir erros de memória. No entanto, o
hardware subjacente ao SAP HANA em Grandes Instâncias Azure (Tipo I) já está a desempenhar a mesma função.
Ter a mesma funcionalidade ativada nos níveis do hardware e do sistema operativo (OS) pode causar conflitos e
pode levar a paralisações ocasionais e não planeadas do servidor. Por isso, recomenda-se desativar o módulo do
Sistema Operativo.
Passos de Execução
Verifique se o módulo EDAC está ativado. Se uma saída for devolvida abaixo do comando, significa que o
módulo está ativado.

lsmod | grep -i edac

Desative os módulos, afunilando as seguintes linhas ao ficheiro /etc/modprobe.d/blacklist.conf

blacklist sb_edac
blacklist edac_core

É necessário reiniciar para fazer alterações. Execute lsmod o comando e verifique se o módulo não está presente
na saída.
Parâmetros kernel
Certifique-se de transparent_hugepage que numa_balancing processor.max_cstate a ignore_ce
intel_idle.max_cstate regulação correta para, e para a aplicação.

intel_idle.max_cstate=1
processador.max_cstate=1
transparent_hugepage=nunca
numa_balancing=desativar
mcE=ignore_ce
Passos de Execução
Adicione estes parâmetros GRB_CMDLINE_LINUX à linha no ficheiro /etc/default/grub

intel_idle.max_cstate=1 processor.max_cstate=1 transparent_hugepage=never numa_balancing=disable mce=ignore_ce

Crie um novo arquivo de comida.

grub2-mkconfig -o /boot/grub2/grub.cfg

Sistema de reiniciar.

Passos seguintes
Consulte a cópia de segurança e restaure para a classe SKU de backup os.
Consulte a cópia de segurança osso para os selos tipo II sKUs de carimbos de Revisão 3 para classe SKU tipo II.
Configurar o servidor SMT para SUSE Linux
29/04/2020 • 10 minutes to read • Edit Online

Grandes instâncias de SAP HANA não têm conectividade direta com a internet. Não é um processo simples registar
tal unidade com o fornecedor do sistema operativo, e descarregar e aplicar atualizações. Uma solução para o SUSE
Linux é configurar um servidor SMT numa máquina virtual Azure. Hospedar a máquina virtual numa rede virtual
Azure, que está ligada à Grande Instância HANA. Com um servidor SMT deste tipo, a unidade HANA Large Instance
poderia registar e descarregar atualizações.
Para obter mais documentação sobre sUSE, consulte a sua Ferramenta de Gestão de Assinaturas para SLES 12 SP2.
Os pré-requisitos para a instalação de um servidor SMT que cumpre a tarefa para as grandes instâncias hana são:
Uma rede virtual Azure que está ligada ao circuito HANA Large Instance ExpressRoute.
Uma conta SUSE que está associada a uma organização. A organização deve ter uma subscrição SUSE válida.

Instale o servidor SMT numa máquina virtual Azure


Primeiro, inscreva-se no Centro de Clientes SUSE.
Vá paraas credenciais da organização. > Nessa secção, deve encontrar as credenciais necessárias para
configurar o servidor SMT.
Em seguida, instale um VM SUSE Linux na rede virtual Azure. Para implantar a máquina virtual, pegue uma
imagem de galeria SLES 12 SP2 do Azure (selecione byos sUSE image). No processo de implementação, não defina
um nome DNS e não utilize endereços IP estáticos.

A máquina virtual implantada é menor, e obteve o endereço IP interno na rede virtual Azure de 10.34.1.4. O nome
da máquina virtual é smtserver. Após a instalação, verifica-se a conectividade com a unidade ou unidades hana
Large Instance. Dependendo da forma como organizou a resolução de nomes, poderá ser necessário configurar a
resolução das unidades HANA Large Instance em etc/anfitriões da máquina virtual Azure.
Adicione um disco à máquina virtual. Usa este disco para segurar as atualizações e o disco de arranque em si pode
ser muito pequeno. Aqui, o disco foi montado para /srv/www/htdocs, como mostra a seguinte imagem. Um disco
de 100 GB deve ser suficiente.
Inscreva-se na unidade ou unidades HANA Large Instance, mantenha /etc/anfitriões e verifique se pode chegar à
máquina virtual Azure que supostamente executa o servidor SMT sobre a rede.
Depois desta verificação, inscreva-se na máquina virtual Azure que deve executar o servidor SMT. Se estiver a usar
massa para iniciar sessão na máquina virtual, execute esta sequência de comandos na sua janela de festa:

cd ~
echo "export NCURSES_NO_UTF8_ACS=1" >> .bashrc

Reinicie a sua batida para ativar as definições. Então começa o YAST.


Ligue o seu VM (smtserver) ao site SUSE.

smtserver:~ # SUSEConnect -r <registration code> -e s<email address> --url https://scc.suse.com


Registered SLES_SAP 12.2 x86_64
To server: https://scc.suse.com
Using E-Mail: email address
Successfully registered system.

Depois de a máquina virtual estar ligada ao local suse, instale as embalagens de smt. Utilize o seguinte comando
de massa para instalar as embalagens de smt.

smtserver:~ # zypper in smt


Refreshing service 'SUSE_Linux_Enterprise_Server_for_SAP_Applications_12_SP2_x86_64'.
Loading repository data...
Reading installed packages...
Resolving package dependencies...

Também pode utilizar a ferramenta YAST para instalar as embalagens de smt. No YAST, vá à Manutenção de
Software e procure por Smt. Selecione smt , que muda automaticamente para yast2-smt.
Aceite a seleção para instalação no smtserver. Depois de a instalação estar concluída, vá à configuração do servidor
SMT. Introduza as credenciais organizacionais do Centro de Clientes SUSE que recuperou anteriormente. Introduza
também o nome de anfitrião da máquina virtual Azure como URL do Servidor SMT. Nesta demonstração, é
https://smtserver.

Agora teste se a ligação ao Centro de Clientes SUSE funciona. Como pode ver na seguinte imagem, neste caso de
demonstração, resultou.
Depois do início da configuração do SMT, forneça uma senha de base de dados. Como é uma nova instalação, deve
definir essa palavra-passe como mostrado na seguinte imagem.

O próximo passo é criar um certificado.


No final da configuração, pode levar alguns minutos para executar a verificação de sincronização. Após a
instalação e configuração do servidor SMT, deverá encontrar o repo de diretório sob o ponto de montagem
/srv/www/htdocs/. Há também alguns subdiretórios sob repo.
Reinicie o servidor SMT e os seus serviços relacionados com estes comandos.

rcsmt restart
systemctl restart smt.service
systemctl restart apache2

Descarregue os pacotes para o servidor SMT


Depois de todos os serviços serem reiniciados, selecione os pacotes apropriados na Gestão De SMT utilizando o
YAST. A seleção do pacote depende da imagem do sistema operativo do servidor HANA Large Instance. A seleção
do pacote não depende da versão ou versão do SLES que executa o servidor SMT. A imagem que se segue mostra
um exemplo do ecrã de seleção.

Em seguida, inicie a cópia inicial dos pacotes selecionados para o servidor SMT que configura. Esta cópia é ativada
na concha utilizando o espelho de comando.
Os pacotes devem ser copiados para os diretórios criados sob o ponto de montagem /srv/www/htdocs. Este
processo pode demorar uma hora ou mais, dependendo de quantos pacotes você seleciona. À medida que este
processo termina, mude-se para a configuração do cliente SMT.

Configurar o cliente SMT em unidades hana large instance


Os clientes ou clientes neste caso são as unidades HANA Large Instance. A configuração do servidor SMT copiou o
guião clientSetup4SMT.sh para a máquina virtual Azure. Copie esse script para a unidade HANA Large Instance que
pretende ligar ao seu servidor SMT. Inicie o script com a opção -h e dê o nome do seu servidor SMT como
parâmetro. Neste exemplo, o nome é smtserver.

É possível que a carga do certificado do servidor pelo cliente tenha sucesso, mas o registo falha, como mostra a
seguinte imagem.
Se o registo falhar, consulte o documento de suporte SUSEe execute os passos descritos lá.

IMPORTANT
Para o nome do servidor, forneça o nome da máquina virtual (neste caso, smtserver), sem o nome de domínio totalmente
qualificado.

Depois de executar estes passos, execute o seguinte comando na unidade HANA Large Instance:

SUSEConnect –cleanup

NOTE
Espere alguns minutos depois do passo. Se correr clientSetup4SMT.sh imediatamente, pode ter um erro.

Se encontrar um problema que precisa de corrigir com base nos passos do artigo SUSE, reinicie
clientSetup4SMT.sh na unidade HANA Large Instance. Agora deve terminar com sucesso.
Configurou o cliente SMT da unidade HANA Large Instance para se ligar ao servidor SMT instalado na máquina
virtual Azure. Agora pode pegar em 'zypper up' ou 'zypper in' para instalar atualizações do sistema operativo para
as Grandes Instâncias HANA ou instalar pacotes adicionais. Só é possível obter atualizações que tenha
descarregado antes no servidor SMT.

Passos seguintes
Instalação HANA no HLI.
SAP HANA sobre migração de grandes instâncias
azure para máquinas virtuais azure
29/04/2020 • 35 minutes to read • Edit Online

Este artigo descreve possíveis cenários de implantação de grandes instâncias do Azure e oferece abordagem de
planeamento e migração com tempo de transição minimizado

Descrição geral
Desde o anúncio do Azure Large Instances for SAP HANA (HLI) em setembro de 2016, muitos clientes adotaram
este hardware como uma oferta de serviço para a sua plataforma de computação em memória. Nos últimos anos, a
extensão do tamanho do Azure VM, juntamente com o apoio da implantação em escala HANA, excedeu a procura
de capacidade de base de dados ERP da maioria dos clientes empresariais. Começamos a ver clientes expressando o
interesse de migrar a sua carga de trabalho SAP HANA de servidores físicos para VMs Azure. Este guia não é um
documento de configuração passo a passo. Descreve os modelos comuns de implantação e oferece conselhos de
planeamento e migração. A intenção é chamar a atenção necessária para a preparação para minimizar o tempo de
transição.

Pressupostos
Este artigo faz as seguintes suposições:
O único interesse considerado é uma migração homogénea do serviço de computação de base de dados HANA
de Hana Large Instance (HLI) para Azure VM sem atualização ou remendo significativo de software. Estas
pequenas atualizações incluem a utilização de uma versão os mais recente ou versão HANA explicitamente
indicada como suportada por notas SAP relevantes.
Todas as atualizações/atualizações têm de ser feitas antes ou depois da migração. Por exemplo, o SAP HANA
MCOS converte-se na implantação do MDC.
A abordagem migratória que ofereceria menos tempo de inatividade é a Replicação do Sistema SAP HANA.
Outros métodos de migração não fazem parte do âmbito deste documento.
Esta orientação é aplicável tanto para rev3 como para Rev4 SKUs de HLI.
A arquitetura de implantação da HANA permanece principalmente inalterada durante a migração. Ou seja, um
sistema com um DR de instância única permanecerá da mesma forma no destino.
Os clientes analisaram e compreenderam o Acordo de Nível de Serviço (SLA) da arquitetura alvo (a ser).
Os termos comerciais entre as HLIs e os VMs são diferentes. Os clientes devem monitorizar a utilização dos seus
VMs para a gestão de custos.
Os clientes entendem que o HLI é uma plataforma de computação dedicada, enquanto os VMs funcionam em
infraestruturas partilhadas mas isoladas.
Os clientes validaram esse alvo vMs suportam a sua arquitetura pretendida. Para ver todos os VM SKUs
suportados certificados para a implementação do SAP HANA, consulte o diretório de hardware SAP HANA.
Os clientes validaram o plano de conceção e migração.
Plano para recuperação de desastres VM juntamente com o local principal. Os clientes não podem usar o HLI
como o nó DR para o local primário em execução em VMs após a migração.
Os clientes copiaram os ficheiros de backup necessários para os VMs-alvo, com base nos requisitos de
recuperabilidade e conformidade das empresas. Com backups acessíveis a VM, permite a recuperação ponto-a-
tempo durante o período de transição.
Para o HSR HA, os clientes precisam de configurar e configurar o dispositivo STONITH por guias SAP HANA HA
para SLES e RHEL. Não está pré-configurado como o caso hli.
Esta abordagem de migração não cobre o HLI SKUs com a configuração Optane.

Cenários de implementação
Os modelos comuns de implantação com clientes HLI são resumidos na tabela seguinte. A migração para VMs
Azure para todos os cenários de HLI é possível. Para beneficiar dos serviços azure complementares disponíveis,
podem ser necessárias pequenas alterações arquitetónicas.

M IGRA R PA RA VM
ID DO C EN Á RIO C EN Á RIO H L I VERB AT IM ? O B SERVA Ç Ã O

1 Nó único com um SID Sim -

2 Nó único com MCOS Sim -

3 Nó único com DR usando Não A replicação de


replicação de armazenamento não está
armazenamento disponível com plataforma
virtual Azure, altere a atual
solução DR para HSR ou
backup/restauro

4 Nó único com DR (multiuso) Não A replicação de


utilizando replicação de armazenamento não está
armazenamento disponível com plataforma
virtual Azure, altere a atual
solução DR para HSR ou
backup/restauro

5 HSR com STONITH para alta Sim Sem SBD pré-configurado


disponibilidade para VMs alvo. Selecione e
implemente uma solução
STONITH. Opções possíveis:
Agente de Esgrima Azure
(suportado tanto para RHEL,
SLES),SBD

6 HA com HSR, DR com Não Substitua a replicação de


replicação de armazenamento para
armazenamento necessidades de DR por HSR
ou cópia de
segurança/restauro

7 Falha automática do anfitrião Sim Utilize ANF para


(1+1) armazenamento partilhado
com VMs Azure

8 Escala-out com standby Sim BW/4HANA com M128s,


M416s, M416ms VMs
usando ANF apenas para
armazenamento

9 Escala-out sem espera Sim BW/4HANA com M128s,


M416s, M416ms VMs (com
ou sem utilização anf para
armazenamento)
M IGRA R PA RA VM
ID DO C EN Á RIO C EN Á RIO H L I VERB AT IM ? O B SERVA Ç Ã O

10 Scale-out com DR usando Não Substitua a replicação de


replicação de armazenamento para
armazenamento necessidades de DR por HSR
ou cópia de
segurança/restauro

11 Nó único com DR usando Sim -


HSR

12 Nó único HSR para DR Sim -


(custo otimizado)

13 HA e DR com HSR Sim -

14 HA e DR com HSR (custo Sim -


otimizado)

15 Scale-out com DR usando Sim BW/4HANA com M128s.


HSR M416s, M416ms VMs (com
ou sem utilização anf para
armazenamento)

Planeamento de fonte (HLI)


Ao embarcar num servidor HLI, tanto a Microsoft Service Management como os clientes passaram pelo
planeamento da computação, rede, armazenamento e definições específicas do OS para executar a base de dados
SAP HANA. É necessário planear de forma semelhante para a migração para o Azure VM.
Limpeza sap HANA
É uma boa prática operacional arrumar o conteúdo da base de dados para que dados indesejados e desatualizados,
ou registos velhos não sejam migrados para a nova base de dados. A limpeza envolve geralmente a desminagem
ou arquivamento de dados antigos, expirados ou inativos. Estas ações de "higiene de dados" devem ser testadas em
sistemas não produtivos para validar a sua validade de aparas de dados antes da utilização da produção.
Permitir a conectividade da rede para novos VMs e, ou rede virtual
Na implantação do HLI de um cliente, a rede foi criada com base nas informações descritas no artigo SAP HANA
(Grandes Instâncias) arquiteturade rede. Além disso, o encaminhamento de tráfego de rede é feito da forma
descrita na secção 'Encaminhamento em Azure'.
Ao configurar um novo VM como alvo de migração, Se for colocado na rede virtual existente com gamas de
endereços IP já autorizadas a ligar-se ao HLI, não é necessária mais nenhuma atualização de conectividade.
Se o novo Azure VM for colocado numa nova Rede Virtual Microsoft Azure, poderá estar noutra região, e
espreitar com a rede virtual existente, a chave de serviço ExpressRoute e o Id de Recursos do fornecimento
original de HLI são utilizáveis para permitir o acesso a esta nova gama IP da rede virtual. Coordene com a
Microsoft Service Management para permitir a conectividade da rede virtual. Nota: Para minimizar a latência da
rede entre as camadas de aplicação e base de dados, tanto as camadas de aplicação como de base de dados
devem estar na mesma rede virtual.
Conjunto de disponibilidade de camada de aplicativo existente, zonas de disponibilidade e Grupo de Colocação
de Proximidade (PPG )
O atual modelo de implantação é feito para satisfazer determinados objetivos de nível de serviço. Neste
movimento, certifique-se de que a infra-estrutura-alvo irá cumprir ou exceder os objetivos definidos.
Mais provável do que não, os servidores de aplicações SAP dos clientes são colocados num conjunto de
disponibilidade. Se o nível atual de serviço de implantação for satisfatório e
Se o VM alvo assumir o nome de anfitrião do nome lógico HLI, atualizar a resolução de endereços de nome de
domínio (DNS) que indique o IP do VM funcionaria sem atualizar quaisquer perfis SAP
Se não estiver a utilizar o PPG, certifique-se de colocar todos os servidores de aplicação e DB na mesma zona
para minimizar a latência da rede.
Se estiver a utilizar o PPG, consulte a secção deste documento: 'Planeamento de Destino, Conjunto de
Disponibilidade, Zonas de Disponibilidade e Grupo de Colocação de Proximidade (PPG)'.
Processo de descontinuação da replicação de armazenamento (se utilizado )
Se a replicação do armazenamento for utilizada como solução DR, deve ser terminada (não programada) depois de
a aplicação SAP ter sido desligada. Além disso, o último catálogo, ficheiro de registo e dados do SAP HANA foram
replicados nos volumes remotos de armazenamento DR HLI. Fazê-lo por precaução no caso de um desastre
acontecer durante o servidor físico para a transição Azure VM.
Consideração de preservação de backups de dados
Após o corte para SAP HANA no Azure VM, todos os dados baseados em instantâneos ou cópias de segurança no
HLI não são facilmente acessíveis ou restoráveis a um VM, se necessário. No período de transição inicial, antes que
o backup baseado em Azure construa história suficiente para satisfazer os requisitos de recuperação do Ponto no
Tempo, recomendamos que se tome minés de nível de ficheiros para além de instantâneos no HLI, dias ou semanas
antes do corte. Tenha estas cópias de segurança para uma conta de Armazenamento Azure acessível pelo novo SAP
HANA VM. Além de apoiar o conteúdo do HLI, é prudente ter cópias de segurança completas da paisagem SAP
facilmente acessíveis no caso de ser necessário um retrocesso.
Monitorização do sistema de ajuste
Os clientes usam muitas ferramentas diferentes para monitorizar e enviar notificações de alerta para sistemas
dentro da sua paisagem SAP. Este item é apenas uma chamada para medidas adequadas para incorporar alterações
para monitorização e atualização dos destinatários da notificação de alerta, se necessário.
Envolvimento da equipa de Operações da Microsoft
Abra um bilhete a partir do portal Azure com base na instância HLI existente. Após a criação do bilhete de apoio, um
engenheiro de suporte entrará em contacto consigo por e-mail.
Envolver a equipa de conta da Microsoft
Planeie a migração perto do tempo de renovação do contrato de iHL para minimizar desnecessária sanções em
detrimento das despesas com recurso a cálculo. Para desmantelar a lâmina hli, é necessário coordenar a rescisão
do contrato e o encerramento real da unidade.

Planeamento de destino
Erguer uma nova infraestrutura para tomar o lugar de uma existente merece alguma reflexão para garantir que a
nova adição se encaixe no grande esquema das coisas. Abaixo estão alguns pontos-chave para contemplação.
Disponibilidade de recursos na região alvo
A atual região de implementação dos servidores de aplicações SAP está tipicamente próxima dos HLIs associados.
No entanto, os HLIs são oferecidos em menos locais do que as regiões azure disponíveis. Ao migrar o HLI físico para
o Azure VM, é também uma boa altura para "afinar" a distância de proximidade de todos os serviços relacionados
para otimização de desempenho. Ao fazê-lo, uma das principais considerações é garantir que a região escolhida
dispõe de todos os recursos necessários. Por exemplo, a disponibilidade de uma certa família VM ou a oferta de
Zonas Azure para configuração de alta disponibilidade.
Rede virtual
Os clientes precisam de escolher se devem ou não gerir a nova base de dados HANA numa rede virtual existente
ou criar uma nova. O principal fator decisivo é o atual layout de networking para a paisagem SAP. Também quando a
infraestrutura vai de uma zona para implantação de duas zonas e utiliza O PPG, impõe alterações arquitetónicas.
Para mais informações, consulte o artigo Azure PPG para obter uma latência ótima da rede com aplicação SAP.
Segurança
Quer o novo SAP HANA VM aterre numa nova ou existente vnet/subnet, representa um novo serviço crítico de
negócios que requer salvaguarda. O controlo de acesso satisfatório com a política de segurança da empresa deve
ser avaliado e implementado para esta nova classe de serviço.
Recomendação de dimensionamento VM
Esta migração é também uma oportunidade para o tamanho certo do seu motor de computação HANA. Pode-se
usar as vistas do sistema HANA em conjunto com o HANA Studio para entender o consumo de recursos do
sistema, o que permite o dimensionamento certo para impulsionar a eficiência de gastos.
Armazenamento
O desempenho do armazenamento é um dos fatores que impacta a experiência do utilizador da aplicação SAP. Base
num dado VM SKU, existem configurações de armazenamento mínimo publicadas SAP HANA Azure
configuraçõesde armazenamento de máquinas virtuais . Recomendamos rever estas especificações mínimas e
comparar com as estatísticas existentes do sistema HLI para garantir uma capacidade e desempenho adequados
para o novo VM HANA.
Se configurar o PPG para o novo VM HANA e as suas severs associadas, submeta um bilhete de apoio para
inspecionar e garantir a co-localização do armazenamento e do VM. Uma vez que a sua solução de backup poderá
ter de ser alterada, o custo de armazenamento também deve ser revisitado para evitar surpresas de gastos
operacionais.
Replicação de armazenamento para recuperação de desastres
Com o HLI, a replicação do armazenamento foi oferecida como a opção padrão para a recuperação do desastre.
Esta funcionalidade não é a opção padrão para SAP HANA no Azure VM. Considere hSR, backup/restauro ou outras
soluções suportadas que satisfaça as suas necessidades de negócio.
Conjuntos de disponibilidade, zonas de disponibilidade e grupos de colocação de proximidade
Para encurtar a distância entre a camada de aplicação e o SAP HANA para manter a latência da rede no mínimo, a
nova base de dados VM e os atuais servidores de aplicações SAP devem ser colocados num PPG. Consulte o Grupo
de Colocação de Proximidade para saber como as Zonas de Disponibilidade e Disponibilidade do Azure funcionam
com o PPG para implementações sap. Se os membros do sistema HANA alvo forem implantados em mais de uma
Zona Azure, os clientes devem ter uma visão clara do perfil de latência das zonas escolhidas. A colocação de
componentes do sistema SAP é ótima no que diz respeito à distância proximal entre a aplicação SAP e a base de
dados. A ferramenta de teste de latência da zona de disponibilidade do domínio público ajuda a facilitar a medição.
Estratégia de backup
Muitos clientes já estão a usar soluções de backup de terceiros para o SAP HANA no HLI. Nesse caso, apenas uma
base de dados adicional de VM e HANA protegida supor configurar. Os trabalhos de apoio ao HLI em curso podem
agora ser desprogramados se a máquina estiver a ser desativada após a migração. O Azure Backup para SAP HANA
em VM está agora geralmente disponível. Consulte estes links para obter informações detalhadas sobre: Backup,
Restaurar, Gerir cópias de segurança SAP HANA em VMs Azure.
Estratégia DR
Se os seus objetivos de nível de serviço acomodarem um tempo de recuperação mais longo, um simples backup
para o armazenamento de bolhas e restaurar no lugar ou restaurar para um novo VM é a estratégia dr mais
simples e menos dispendiosa.
Como a plataforma de grandes instâncias onde hana DR tipicamente é feito com HSR; No Azure VM, o HSR é
também a solução SAP HANA DR mais natural e nativa. Independentemente de a implantação da fonte ser de
instância única ou agrupada, é necessária uma réplica da infraestrutura de origem na região DR. Esta réplica DR
será configurada após a migração primária de HLI para VM estar completa. O DR HANA DB registar-se-á no SAP
HANA primário em caso vm como um local de replicação secundária.
Mudança de destino de destino de conectividade do servidor de aplicações SAP
A migração hsr resulta num novo hospedeiro HANA DB e, portanto, um novo nome de hospedeiro DB para a
camada de aplicação, os perfis SAP precisam de ser modificados para refletir o novo nome de anfitrião. Se a
comutação for feita por resolução de nome que preserve o nome de anfitrião, não é necessária qualquer alteração
de perfil.
Sistema operativo
As imagens do sistema operativo para HLI e VM, apesar de estarem no mesmo nível de libertação, sles 12 SP4, por
exemplo, não são idênticas. Os clientes devem validar as embalagens, correções quentes, correções quentes,
remendos, núcleos e correções de segurança no HLI para instalar as mesmas embalagens no alvo. É suportado para
usar HSR para replicar de um sistema operativo mais antigo para um VM com uma versão mais recente do SO.
Verifique as versões específicas suportadas revendo a nota SAP 2763388.
Novo pedido de licença SAP
Uma simples chamada para pedir uma nova licença SAP para o novo sistema HANA agora que foi migrado para
VMs.
Diferenças no contrato de nível de serviço (SLA )
Os autores gostam de chamar a atenção para a diferença de disponibilidade sla entre HLI e Azure VM. Por exemplo,
os pares HLIs HA agrupados oferecem 99,99% de disponibilidade. Para conseguir o mesmo SLA, é necessário
implantar VMs em zonas de disponibilidade. Este artigo descreve a disponibilidade com arquiteturas de
implantação associadas para que os clientes possam planear a sua infraestrutura-alvo em conformidade.

Estratégia de migração
Neste documento, cobrimos apenas a abordagem de replicação do sistema HANA para a migração do HLI para o
Azure VM. Depende da solução de armazenamento-alvo implementada, o processo difere ligeiramente. Os passos
de alto nível são descritos abaixo.
VM com premium/ultra-discos para dados
Para VMs que são implantados com premium ou ultra-discos, a configuração padrão de replicação do sistema SAP
HANA é aplicável para a configuração de HSR. O artigo de ajuda SAP fornece uma visão geral dos passos
envolvidos na criação da replicação do sistema, assumindo um sistema secundário, falhando na replicação primária
e incapacitante do sistema. Para efeitos da migração, só precisaremos da configuração, tomada e desativação dos
passos de replicação.
VM com ANF para dados e volumes de registo
A um nível elevado, os mais recentes instantâneos de armazenamento de HLI dos dados completos e volumes de
registo devem ser copiados para o Armazenamento Azure, onde são acessíveis e recuperáveis pelo alvo HANA VM.
O processo de cópia pode ser feito com quaisquer ferramentas de cópia linux nativas.

IMPORTANT
A cópia e a transferência de dados podem demorar horas depende do tamanho da base de dados HANA e da largura de
banda da rede. A maior parte do processo de cópia deve ser feita antes do tempo de inatividade primário do HANA DB.

MCOS para Conversão MDC


O modelo de implementação de Múltiplos Componentes no One System (MCOS) foi utilizado por alguns dos
nossos clientes HLI. A motivação foi contornar a limitação instantânea do armazenamento de várias bases de dados
(MDC) das versões anteriores do SAP HANA. No modelo MCOS, várias instâncias independentes do SAP HANA são
empilhadas numa lâmina HLI. A utilização de HSR para a migração funcionaria bem, mas resultando em múltiplos
VMs HANA com um inquilino DB cada. Este estado final torna uma paisagem mais movimentada do que o que um
cliente poderia estar habituado. Com a implantação padrão SAP HANA 2.0 sendo MDC, uma alternativa viável é
executar movimento de inquilino HANA após a migração do HSR. Este processo "consolida" estas bases de dados
independentes da HANA em coinquilinos num único contentor HANA.
Consideração da camada de aplicação
O servidor DB é visto como o centro de um sistema SAP. Todos os servidores de aplicações devem estar localizados
perto do SAP HANA DB. Em alguns casos, quando é desejada uma nova utilização do PPG, pode ser necessária a
deslocalização dos servidores de aplicações existentes para o PPG onde o VM HANA é necessário. A construção de
novos servidores de aplicações pode ser considerada mais fácil se já tiver modelos de implementação à mão.
Se os servidores de aplicações existentes e o novo VM HANA estiverem na melhor posição, não é necessário
construir novos servidores de aplicações, a menos que seja necessária capacidade adicional.
Se for construída uma nova infraestrutura para melhorar a disponibilidade do serviço, os servidores de aplicações
existentes podem tornar-se desnecessários e devem ser desligados e eliminados. Se o nome de anfitrião do VM
alvo alterado e diferir do nome de anfitrião HLI, os perfis do servidor de aplicação SAP precisam de ser ajustados
para apontar para o novo anfitrião. Se apenas o endereço IP HANA DB tiver mudado, é necessária uma atualização
de registo DNS para liderar as ligações de entrada para o novo HanA VM.
Teste de aceitação
Embora a migração do HLI para vM não faça alterações materiais para o conteúdo da base de dados em
comparação com uma migração heterogénea, recomendamos ainda validar as principais funcionalidades e aspeto
de desempenho da nova configuração.
Plano cutover
Embora esta migração seja direta, no entanto envolve o desmantelamento de um DB existente. Um planeamento
cuidadoso para preservar o sistema de origem com o seu conteúdo associado e as imagens de backup são
fundamentais no caso de ser necessário um recuo. Um bom planeamento oferece uma inversão mais rápida.

Pós-migração
O trabalho de migração não é feito até termos dissociado com segurança quaisquer serviços dependentes do HLI
ou conectividade para garantir a preservação da integridade dos dados. Além disso, encerrar serviços
desnecessários. Esta secção chama alguns itens topo de mente.
Desmantelamento do HLI
Após uma migração bem sucedida do HANA DB para o Azure VM, garanta que não havendo transações comerciais
produtivas no HLI DB. No entanto, manter o HLI em funcionamento por um período de tempo é igual à sua janela
de retenção de cópias de segurança local é uma prática segura que garanta uma recuperação mais rápida, se
necessário. Só então a lâmina HLI deve ser desativada. Os clientes devem concluir contratualmente os seus
compromissos de HLI com a Microsoft contactando os seus representantes da Microsoft.
Remova qualquer procuração (ex: Iptables, BIGIP) configurada para HLI
Se um serviço de procuração como o IPTables for utilizado para direcionar o tráfego no local de e para o HLI, já não
é necessário após a migração bem sucedida para vm. No entanto, este serviço de conectividade deve ser mantido
enquanto a lâmina HLI ainda estiver de prontida. Só desligue o serviço depois de a lâmina HLI estar totalmente
desativada.
Remover o Alcance Global para o HLI
O Global Reach é utilizado para ligar o gateway ExpressRoute dos clientes ao gateway HLI ExpressRoute. Permite
que o tráfego no local dos clientes chegue diretamente ao inquilino do HLI sem recurso a um serviço de
procuração. Esta ligação já não é necessária na ausência da unidade hli após a migração. Tal como o caso do serviço
de procuração IPTables, o GlobalReach também deve ser mantido até que a lâmina HLI esteja totalmente
desativada.
Subscrição do sistema operativo - movimento/reutilização
À medida que os servidores VM são suportados e as lâminas HLI são desativadas, as subscrições de So podem ser
substituídas ou reutilizadas para evitar o dobro do pagamento das licenças de SO.

Passos seguintes
Veja estes artigos:
Configurações e operações de infraestruturas SAP HANA no Azure.
Cargas de trabalho SAP em Azure: lista de verificação de planeamento e implementação.
Instalação de SAP HANA em máquinas virtuais Azure
29/04/2020 • 15 minutes to read • Edit Online

Introdução
Este guia ajuda-o a apontar os recursos certos para implantar hana em máquinas virtuais Azure com sucesso. Este
guia vai indicar-lhe os recursos de documentação que precisa de verificar antes de instalar o SAP HANA num VM
Azure. Para que seja capaz de executar os passos certos para terminar com uma configuração suportada de SAP
HANA em VMs Azure.

NOTE
Este guia descreve as implantações da SAP HANA em VMs Azure. Para obter informações sobre como implantar o SAP HANA
em grandes instâncias HANA, consulte Como instalar e configurar o SAP HANA (Grandes Instâncias) no Azure.

Pré-requisitos
Este guia também assume que está familiarizado com:
SAP HANA e SAP NetWeaver e como instalá-los no local.
Como instalar e operar instâncias de aplicação SAP HANA e SAP no Azure.
Os conceitos e procedimentos documentados em:
Planejamento para implantação de SAP no Azure, que inclui planeamento de rede virtual Azure e
utilização de Armazenamento Azure. Ver SAP NetWeaver em Máquinas Virtuais Azure - Guia de
planeamento e implementação
Princípios e formas de implantação de VMs em Azure. Ver implantação de Máquinas Virtuais Azure para
SAP
Conceitos de alta disponibilidade para SAP HANA como documentado em SAP HANA alta
disponibilidade para máquinas virtuais Azure

Passo a passo antes de implantar


Nesta secção, os diferentes passos são listados que você precisa realizar antes de começar com a instalação de SAP
HANA em uma máquina virtual Azure. A ordem é enumerada e, como tal, deve ser seguida como enumerada:
1. Nem todos os cenários de implantação possíveis são apoiados no Azure. Por isso, deve verificar o documento de
carga de trabalho SAP em cenários suportados por máquinas virtuais Azure para o cenário que tem em mente
com a sua implementação SAP HANA. Se o cenário não estiver listado, tem de assumir que não foi testado e,
consequentemente, não é suportado.
2. Assumindo que tem uma ideia difícil sobre o seu requisito de memória para a sua implantação SAP HANA,
precisa encontrar um Azure VM adequado. Nem todos os VMs certificados para sap NetWeaver, conforme
documentado na nota de suporte SAP #1928533,são certificados pela SAP HANA. A fonte da verdade para a
SAP HANA certificada Azure VMs é o site SAP HANA hardware diretório. As unidades que começam com S são
unidades HANA Large Instances e não VMs Azure.
3. Diferentes tipos de VM Azure têm diferentes lançamentos mínimos de sistema operativo para SUSE Linux ou
Red Hat Linux. No site SAP HANA hardware diretório,você precisa clicar numa entrada na lista de unidades
certificadas SAP HANA para obter dados detalhados desta unidade. Além da carga de trabalho apoiada pela
HANA, os lançamentos de SO que são suportados com essas unidades para sap HANA estão listados
4. A partir das libertações do sistema operativo, é necessário considerar certas libertações mínimas de kernel.
Estas versões mínimas estão documentadas nestas notas de suporte SAP:
Nota de suporte sAP #2814271 SAP HANA Backup falha no Azure com erro de Verificação
Nota de suporte SAP #2753418 potencial degradação do desempenho devido ao recuo do timer
Nota de suporte SAP #2791572 degradação do desempenho devido ao apoio vDSO desaparecido para
hiper-V em Azure
5. Com base na versão OS suportada para o tipo de escolha da máquina virtual, é necessário verificar se a sua
versão SAP HANA desejada é suportada com a libertação do sistema operativo. Leia a nota de suporte SAP
#2235581 para uma matriz de suporte das versões SAP HANA com as diferentes versões do Sistema Operativo.
6. Como pode ter encontrado uma combinação válida do tipo Azure VM, libertação do sistema operativo e
libertação do SAP HANA, precisa de verificar a Matriz de Disponibilidade de Produto SAP. Na Matriz de
Disponibilidade SAP, pode descobrir se o produto SAP que pretende executar contra a sua base de dados SAP
HANA é suportado.

Implantação de VM passo a passo e considerações de osso convidado


Nesta fase, é necessário percorrer os passos de implantação do VM(s) para instalar o HANA e, eventualmente,
otimizar o sistema operativo escolhido após a instalação.
1. Escolheu a imagem base da galeria Azure. Se quiser construir a sua própria imagem de sistema operativo
para o SAP HANA, precisa de conhecer todos os diferentes pacotes necessários para uma instalação bem
sucedida do SAP HANA. Caso contrário, recomenda-se a utilização das imagens SUSE e Red Hat para SAP ou
SAP HANA da galeria de imagens Azure. Estas imagens incluem os pacotes necessários para uma instalação
HANA bem sucedida. Com base no seu contrato de suporte com o fornecedor do sistema operativo, precisa
de escolher uma imagem onde traga a sua própria licença. Ou escolhe uma imagem de OS que inclui
suporte
2. Se escolheu uma imagem de OS de hóspedes que requer que você tenha a sua própria licença, você precisa
registar a imagem de OS com a sua subscrição, para que possa descarregar e aplicar os patches mais
recentes. Este passo vai exigir o acesso público à Internet. A menos que tenha configurado a sua instância
privada de, por exemplo, um servidor SMT em Azure.
3. Decida a configuração da rede do VM. Pode ler mais informações no documento Configurações e operações
de infraestruturas SAP HANA no Azure. Tenha em mente que não existem quotas de produção de rede que
possa atribuir a cartões de rede virtuais em Azure. Como resultado, o único objetivo de direcionar o tráfego
através de diferentes VNICs baseia-se em considerações de segurança. Confiamos em si para encontrar um
compromisso supportável entre a complexidade do tráfego através de múltiplos vNICs e os requisitos
aplicados por aspetos de segurança.
4. Aplique as últimas correções no sistema operativo assim que o VM estiver implantado e registado.
Registrado com a sua própria subscrição. Ou caso escolha uma imagem que inclua suporte ao sistema
operativo, o VM já deve ter acesso aos patches.
5. Aplique as melodias necessárias para o SAP HANA. Estas melodias estão listadas nestas notas de suporte
SAP:
Nota de apoio SAP #2694118 - Red Hat Enterprise Linux HA Add-On on Azure
Nota de suporte SAP #1984787 - SUSE LINUX Enterprise Server 12: Notas de instalação
Nota de suporte SAP #2578899 - SUSE Linux Enterprise Server 15: Nota de instalação
Nota de suporte SAP #2002167 - Red Hat Enterprise Linux 7.x: Instalação e Upgrade
Nota de suporte SAP #2292690 - SAP HANA DB: Definições recomendadas de OS para RHEL 7
Nota de suporte SAP #2772999 - Red Hat Enterprise Linux 8.x: Instalação e Configuração
Nota de suporte SAP #2777782 - SAP HANA DB: Definições recomendadas de OS para RHEL 8
Nota de suporte SAP #2455582 - Linux: Executar aplicações SAP compiladas com GCC 6.x
Nota de suporte SAP #2382421 - Otimização da Configuração da Rede em HANA- e Nível OS
6. Selecione o tipo de armazenamento Azure para SAP HANA. Neste passo, você precisa decidir sobre o layout
de armazenamento para a instalação SAP HANA. Você vai usar discos Azure anexados ou ações nativas
azure NFS. Os tipos de armazenamento Azure que ou suportados e combinações de diferentes tipos de
armazenamento Azure que podem ser usados, estão documentados em configurações de armazenamento
de máquinas virtuais SAP HANA Azure. Tome as configurações documentadas como ponto de partida. Para
sistemas não produtivos, pode ser capaz de configurar a produção mais baixa ou o IOPS. Para fins de
produção, poderá ser necessário configurar um pouco mais de produção e IOPS.
7. Certifique-se de que configurou o Acelerador de Escrita Azure para os seus volumes que contêm os registos
de transações DBMS ou registos de redoe quando estiver a utilizar VMs de Série M ou Mv2. Esteja ciente das
limitações para o Acelerador de Escrita como documentado.
8. Verifique se o Azure Accelerated Networking está ativado nos VM(s) implantados.

NOTE
Nem todos os comandos nos diferentes perfis de sap-tune ou como descrito nas notas podem funcionar com sucesso em
Azure. Os comandos que manipulam o modo de potência dos VMs geralmente regressam com um erro, uma vez que o
modo de potência do hardware de hospedeiro Azure subjacente não pode ser manipulado.

Preparações passo a passo específicas das máquinas virtuais Azure


Uma das especificidades do Azure é a instalação de uma extensão Azure VM que fornece dados de monitorização
para o Agente anfitrião sAP. Os detalhes sobre a instalação desta extensão de monitorização estão documentados
em:
SAP Nota 2191498 discute monitorização reforçada com VMs Linux em Azure
SAP Nota 1102124 discute informação sobre SAPOSCOL no Linux
SAP Nota 2178632 discute métricas de monitorização chave para SAP no Microsoft Azure
Implantação de Máquinas Virtuais Azure para SAP NetWeaver

Instalação SAP HANA


Com as máquinas virtuais Azure implantadas e os sistemas operativos registados e configurados, pode instalar o
SAP HANA de acordo com a instalação do SAP. Como um bom começo para chegar a esta documentação, comece
com este site SAP HANA recursos
Para configurações de escala SAP HANA utilizando discos ligados diretos de Armazenamento Premium Azure ou
disco Ultra, leia as especificidades do documento Configurações e operações de infraestrutura SAP HANA no Azure

Recursos adicionais para backup SAP HANA


Para obter informações sobre como fazer o backup sap HANA bases de dados em VMs Azure, consulte:
Guia de backup para SAP HANA em Máquinas Virtuais Azure
Backup SAP HANA Azure no nível de ficheiro

Passos seguintes
Leia a documentação:
Configurações e operações de infraestrutura do SAP HANA no Azure
Configurações de armazenamento da máquina virtual do Azure do SAP HANA
Implementar SAP S/4HANA ou BW/4HANA em
Azure
29/04/2020 • 11 minutes to read • Edit Online

Este artigo descreve como implantar S/4HANA em Azure utilizando a Biblioteca de Eletrodomésticos SAP Cloud
(SAP CAL) 3.0. Para implementar outras soluções baseadas em SAP HANA, como a BW/4HANA, siga os mesmos
passos.

NOTE
Para mais informações sobre o SAP CAL, vá ao site da Biblioteca de Aparelhos De Nuvem SAP. A SAP também tem um blog
sobre a Biblioteca de Eletrodomésticos SAP Cloud 3.0.

NOTE
A partir de 29 de maio de 2017, pode utilizar o modelo de implementação do Gestor de Recursos Azure, além do modelo de
implantação clássico menos preferido para implementar o SAP CAL. Recomendamos que utilize o novo modelo de
implementação do Gestor de Recursos e ignore o modelo de implementação clássico.

Processo passo a passo para implementar a solução


A seguinte sequência de imagens mostra-lhe como implantar S/4HANA em Azure utilizando o SAP CAL. O
processo funciona da mesma forma para outras soluções, como a BW/4HANA.
A página Solutions mostra algumas das soluções baseadas em SAP CAL HANA disponíveis no Azure. SAP
S/4HANA 1610 FPS01, Aparelho totalmente ativado está na linha média:

Criar uma conta no SAP CAL


1. Para iniciar sessão no SAP CAL pela primeira vez, utilize o seu S-User SAP ou outro utilizador registado no
SAP. Em seguida, defina uma conta SAP CAL que é utilizada pelo SAP CAL para implantar aparelhos no
Azure. Na definição de conta, é necessário:
a. Selecione o modelo de implantação no Azure (Gestor de Recursos ou clássico).
b. Insira a sua assinatura Azure. Uma conta SAP CAL só pode ser atribuída a uma subscrição. Se precisa de
mais do que uma subscrição, precisa de criar outra conta SAP CAL.
c. Dê permissão ao SAP CAL para se instalar na sua subscrição Azure.

NOTE
Os próximos passos mostram como criar uma conta SAP CAL para implementações do Gestor de Recursos. Se já tem
uma conta SAP CAL ligada ao modelo de implementação clássico, precisa seguir estes passos para criar uma nova
conta SAP CAL. A nova conta SAP CAL precisa de ser implementada no modelo de Gestor de Recursos.

2. Crie uma nova conta SAP CAL. A página Contas mostra três opções para Azure:
a. O Microsoft Azure (clássico) é o modelo clássico de implementação e já não é preferido.
b. O Microsoft Azure é o novo modelo de implementação do Gestor de Recursos.
c. O Windows Azure operado pela 21Vianet é uma opção na China que utiliza o modelo de
implementação clássico.
Para implementar no modelo Degestor de Recursos, selecione Microsoft Azure .

3. Introduza o ID de subscrição Azure que pode ser encontrado no portal Azure.

4. Para autorizar o SAP CAL a ser implantado na subscrição Azure que definiu, clique em Autorizar . A página
seguinte aparece no separador do navegador:
5. Se estiver listado mais de um utilizador, escolha a conta Microsoft que está ligada a ser o coadministrador da
subscrição Azure selecionada. A página seguinte aparece no separador do navegador:

6. Clique em Aceitar . Se a autorização for bem sucedida, a definição de conta SAP CAL volta a ser
demonstrada. Após um curto período de tempo, uma mensagem confirma que o processo de autorização
foi bem sucedido.
7. Para atribuir a conta SAP CAL recém-criada ao seu utilizador, introduza o ID do utilizador na caixa de texto à
direita e clique em Adicionar .

8. Para associar a sua conta ao utilizador que utiliza para iniciar sessão no SAP CAL, clique em Rever .
9. Para criar a associação entre o utilizador e a recém-criada conta SAP CAL, clique em Criar .
Criou com sucesso uma conta SAP CAL capaz de:
Utilize o modelo de implementação Resource Manager.
Implemente sistemas SAP na sua subscrição Azure.
Agora pode começar a implementar S/4HANA na subscrição do seu utilizador no Azure.

NOTE
Antes de continuar, determine se tem quotas Azure vCPU para VMs da série H. Neste momento, o SAP CAL utiliza VMs de
Série H do Azure para implementar algumas das soluções baseadas em SAP HANA. A sua subscrição Azure pode não ter
quaisquer quotas vCPU da Série H para série H. Em caso afirmativo, poderá ter de contactar o suporte do Azure para obter
uma quota de, pelo menos, 16 VCPUs da Série H.

NOTE
Quando implementar uma solução em Azure no SAP CAL, poderá descobrir que só pode escolher uma região azure. Para se
implantar em regiões de Azure que não a sugerida pelo SAP CAL, precisa de adquirir uma subscrição CAL da SAP. Também
poderá ter de abrir uma mensagem com o SAP para ter a sua conta CAL habilitada a entregar em regiões Azure que não as
inicialmente sugeridas.

Implementar uma solução


Vamos implementar uma solução a partir da página Soluções do SAP CAL. O SAP CAL tem duas sequências para
implementar:
Uma sequência básica que usa uma página para definir o sistema a ser implantado
Uma sequência avançada que lhe dá certas escolhas em tamanhos VM
Demonstramos o caminho básico para a implantação aqui.
1. Na página dados da Conta, é necessário:
a. Selecione uma conta SAP CAL. (Utilize uma conta associada a implantar com o modelo de implementação
do Gestor de Recursos.)
b. Introduza uma instância Nome .
c. Selecione uma região azure . O SAP CAL sugere uma região. Se precisa de outra região do Azure e não
tem uma subscrição SAP CAL, precisa encomendar uma subscrição CAL com SAP.
d. Introduza uma palavra-passe principal para a solução de oito ou nove caracteres. A palavra-passe é
utilizada para os administradores dos diferentes componentes.

2. Clique em Criar , e na caixa de mensagens que aparece, clique OK .

3. Na caixa de diálogo Private Key, clique em Armazenar para armazenar a chave privada no SAP CAL. Para
utilizar a proteção de palavra-passe para a chave privada, clique em Baixar .
4. Leia a mensagem de aviso SAP CAL e clique ok .

Agora o destacamento acontece. Após algum tempo, dependendo da dimensão e complexidade da solução
(o SAP CAL fornece uma estimativa), o estado é mostrado como ativo e pronto para ser utilizado.
5. Para encontrar as máquinas virtuais recolhidas com os outros recursos associados num grupo de recursos,
vá ao portal Azure:
6. No portal SAP CAL, o estado aparece como Ativo . Para se ligar à solução, clique em Ligar . Diferentes
opções para se conectar aos diferentes componentes são implementadas dentro desta solução.

7. Antes de poder utilizar uma das opções para se ligar aos sistemas implantados, clique no Guia iniciar a
partida .
A documentação dá nomes aos utilizadores para cada um dos métodos de conectividade. As palavras-passe
para esses utilizadores são definidas para a palavra-passe principal que definiu no início do processo de
implementação. Na documentação, outros utilizadores mais funcionais estão listados com as suas palavras-
passe, que pode utilizar para iniciar sessão no sistema implementado.
Por exemplo, se utilizar o SAP GUI pré-instalado na máquina de desktop remoto do Windows, o sistema S/4
pode parecer o seguinte:

Ou se usar o DBACockpit, a instância pode parecer assim:


Dentro de algumas horas, um aparelho SAP S/4 saudável é implantado em Azure.
Se comprou uma subscrição SAP CAL, o SAP suporta totalmente as implementações através do SAP CAL em Azure.
A fila de apoio é BC-VCM-CAL.
Configurações e operações de infraestrutura do SAP
HANA no Azure
21/06/2020 • 42 minutes to read • Edit Online

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

Pré-requisitos
Para utilizar este guia, precisa de conhecimentos básicos dos seguintes componentes Azure:
Máquinas virtuais Azure
Redes de rede Azure e redes virtuais
Armazenamento Azure
Para saber mais sobre o SAP NetWeaver e outros componentes SAP em Azure, consulte a secção SAP on Azure da
documentação Azure.

Considerações básicas de configuração


As secções seguintes descrevem considerações básicas de configuração para a implantação de sistemas SAP HANA
em VMs Azure.
Ligar-se às máquinas virtuais Azure
Conforme documentado no guia de planeamento de máquinas virtuais Azure,existem dois métodos básicos de
ligação aos VMs Azure:
Conecte-se através da internet e dos pontos finais públicos num Jump VM ou no VM que está a executar SAP
HANA.
Ligue-se através de uma VPN ou Azure ExpressRoute.
A conectividade local-a-local via VPN ou ExpressRoute é necessária para cenários de produção. Este tipo de
conexão também é necessário para cenários de não produção que se alimentam de cenários de produção onde o
software SAP está a ser utilizado. A imagem a seguir mostra um exemplo de conectividade entre sites:
Escolha os tipos de VM Azure
Os tipos Azure VM que podem ser utilizados para cenários de produção estão listados na documentação SAP para
a IAAS. Para cenários de não produção, está disponível uma maior variedade de tipos nativos de VM Azure.

NOTE
Para cenários de não produção, utilize os tipos de VM listados na nota SAP #1928533. Para a utilização de VMs Azure para
cenários de produção, verifique se os VMs certificados SAP HANA na lista de plataformas certificadas da SAP .

Implementar os VMs em Azure utilizando:


O portal do Azure.
Cmdlets Azure PowerShell.
O Azure CLI.
Também pode implementar uma plataforma SAP HANA instalada completa nos serviços Azure VM através da
plataforma SAP Cloud. O processo de instalação é descrito em Deploy SAP S/4HANA ou BW/4HANA em Azure ou
com a automatização libertada aqui.

IMPORTANT
Para utilizar M208xx_v2 VMs, é necessário ter cuidado ao selecionar a sua imagem Linux na galeria de imagens Azure VM.
Para ler os detalhes, leia o artigo Memória otimou tamanhos de máquina virtual.

Configuração de armazenamento para SAP HANA


Para configurações de armazenamento e tipos de armazenamento a serem utilizados com SAP HANA em Azure,
leia o documento CONFIGURAÇÕES de armazenamento de máquinas virtuais SAP HANA Azure
Criar redes virtuais Azure
Quando tiver conectividade site-to-site em Azure via VPN ou ExpressRoute, deve ter pelo menos uma rede virtual
Azure que esteja ligada através de um Gateway Virtual para o circuito VPN ou ExpressRoute. Em implementações
simples, o Gateway Virtual pode ser implantado numa sub-rede da rede virtual Azure (VNet) que também acolhe
as instâncias SAP HANA. Para instalar o SAP HANA, cria duas sub-redes adicionais dentro da rede virtual Azure.
Uma sub-rede acolhe os VMs para executar as instâncias SAP HANA. A outra sub-rede executa VMs Jumpbox ou
Management para hospedar o SAP HANA Studio, outro software de gestão ou o seu software de aplicação.

IMPORTANT
Fora da funcionalidade, mas mais importante por razões de desempenho, não é suportado para configurar aparelhos virtuais
da rede Azure na via de comunicação entre a aplicação SAP e a camada DBMS de um sistema SAP NetWeaver, Hybris ou
S/4HANA baseado em SAP. A comunicação entre a camada de aplicação SAP e a camada DBMS tem de ser direta. A restrição
não inclui as regras Azure ASG e NSG, desde que as regras ASG e NSG permitam uma comunicação direta. Outros cenários
em que os NVAs não são suportados estão em vias de comunicação entre VMs Azure que representam os nós de cluster
Linux Pacemaker e dispositivos SBD, conforme descrito em Alta disponibilidade para SAP NetWeaver em VMs Azure no SUSE
Linux Enterprise Server para aplicações SAP. Ou em vias de comunicação entre VMs Azure e Windows Server SOFS
configuradas como descrito no Cluster uma instância SAP ASCS/SCS num cluster de failover do Windows utilizando uma
partilha de ficheiros no Azure. Os NVAs nas vias de comunicação podem facilmente duplicar a latência da rede entre dois
parceiros de comunicação, podendo restringir a produção 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 fazer com que os clusters Pacemaker Linux falhem
nos casos em que as comunicações entre os nós do cluster Linux Pacemaker precisam de comunicar ao seu dispositivo SBD
através de um NVA.

IMPORTANT
Outro design que não é suportado é a segregação da camada de aplicação SAP e a camada DBMS em diferentes redes
virtuais Azure que não são espreitadas umas com as outras. Recomenda-se segregar a camada de aplicação SAP e a camada
DBMS utilizando sub-redes dentro de uma rede virtual Azure em vez de utilizar diferentes redes virtuais Azure. Se decidir
não seguir a recomendação e, em vez disso, segregar as duas camadas em diferentes redes virtuais, as duas redes virtuais
precisam de ser espreitadas. Esteja ciente de que o tráfego de rede entre duas redes virtuais Azure estão sujeitos a custos de
transferência. Com o enorme volume de dados em muitos Terabytes trocados entre a camada de aplicação SAP e a camada
DBMS, podem ser acumulados custos substanciais se a camada de aplicação SAP e a camada DBMS forem segregadas entre
duas redes virtuais Azure.

Quando instala os VMs para executar o SAP HANA, os VMs precisam:


Dois NICs virtuais instalados: um NIC para ligar à sub-rede de gestão, e um NIC para ligar da rede no local ou
outras redes, à instância SAP HANA no VM Azure.
Endereços IP privados estáticos que são implantados para ambos os NICs virtuais.

NOTE
Deve atribuir endereços IP estáticos através de meios Azure a vNICs individuais. Não deve atribuir endereços IP estáticos
dentro do so do hóspede a um vNIC. Alguns serviços da Azure, como o Azure Backup Service, baseiam-se no facto de que
pelo menos o vNIC primário está definido para DHCP e não para endereços IP estáticos. Consulte também o documento
Troubleshoot Azure virtual machine backup. Se precisar de atribuir vários endereços IP estáticos a um VM, tem de atribuir
vários vNICs a um VM.

No entanto, para implementações que são duradouras, é necessário criar uma arquitetura de rede de datacenter
virtual em Azure. Esta arquitetura recomenda a separação do Azure VNet Gateway que se conecta às instalações
num Azure VNet separado. Este VNet separado deve acolher todo o tráfego que deixa no local ou na internet. Esta
abordagem permite-lhe implementar software para auditar e registar tráfego que introduz o datacenter virtual em
Azure neste hub separado VNet. Portanto, tem um VNet que acolhe todo o software e configurações que se
relacionam com o tráfego de entradas e saídas para a sua implementação Azure.
Os artigos Azure Virtual Datacenter: A Network Perspetive e Azure Virtual Datacenter e o Enterprise Control Plane
dão mais informações sobre a abordagem virtual do datacenter e o design relacionado Azure VNet.
NOTE
O tráfego que flui entre um hub VNet e o VNet falado usando o Azure VNet está sujeito a custosadicionais . Com base
nesses custos, poderá ter de considerar fazer compromissos entre executar um hub rigoroso e o design de rede de raios e
executar vários Gateways Azure ExpressRoute que você conecta a 'spokes' para contornar o peering VNet. No entanto, a
Azure ExpressRoute Gateways introduz também custos adicionais. Também pode encontrar custos adicionais para software
de terceiros que utiliza para registo de tráfego de rede, auditoria e monitorização. Dependente dos custos de troca de dados
através do espremomento VNet de um lado e dos custos criados por gateways adicionais da Azure ExpressRoute e licenças
de software adicionais, pode decidir a micro-segmentação dentro de um VNet utilizando sub-redes como unidade de
isolamento em vez de VNets.

Para obter uma visão geral dos diferentes métodos de atribuição de endereços IP, consulte os tipos de endereços IP
e os métodos de atribuição em Azure.
Para VMs que executam SAP HANA, deve trabalhar com endereços IP estáticos atribuídos. A razão é que alguns
atributos de configuração para endereços IP de referência HANA.
Os Grupos de Segurança da Rede Azure (NSGs) são utilizados para direcionar o tráfego que é encaminhado para a
instância SAP HANA ou para a caixa de salto. Os NSGs e, eventualmente, grupos de segurança de aplicações estão
associados à sub-rede SAP HANA e à sub-rede de Gestão.
A imagem a seguir mostra uma visão geral de um esquema de implantação áspera para SAP HANA seguindo um
hub e falou arquitetura VNet:

Para implantar o SAP HANA em Azure sem uma ligação site-to-site, ainda pretende proteger a instância SAP HANA
da internet pública e escondê-la atrás de um representante avançado. Neste cenário básico, a implementação
baseia-se nos serviços DNS incorporados da Azure para resolver os números de anfitriões. Numa implementação
mais complexa onde são utilizados endereços IP virados para o público, os serviços de DNS incorporados são
especialmente importantes. Utilize NSGs Azure e Azure NVAs para controlar, monitorize o encaminhamento da
internet para a sua arquitetura Azure VNet em Azure. A imagem a seguir mostra um esquema áspero para
implantar SAP HANA sem uma ligação site-to-site num hub e falou arquitetura VNet:
Outra descrição sobre como usar Azure NVAs para controlar e monitorizar o acesso a partir da Internet sem o hub
e a arquitetura VNet falada pode ser encontrada no artigo Implementar aparelhos virtuais de rede altamente
disponíveis.

Configuração da infraestrutura Azure para a escala SAP HANA


Para saber os tipos Azure VM certificados para a escala OLAP ou para a escala S/4HANA, consulte o diretório de
hardware SAP HANA. Uma marca de verificação na coluna 'Clustering' indica suporte de escala. O tipo de aplicação
indica se a escala de OLAP ou a escala S/4HANA são suportadas. Para obter mais informações sobre os nós
certificados em escala para cada um dos VMs, verifique os detalhes das entradas no VM SKU particular listado no
diretório de hardware SAP HANA.
Os desbloqueios mínimos de SO para a implementação de configurações de escala em VMs Azure, verifique os
detalhes das entradas no VM SKU particular listado no diretório de hardware SAP HANA. De uma configuração de
escala de escala de N-nó OLAP, um nó funciona como nó principal. Os outros nós até ao limite da lei de certificação
como nó de trabalhador. Os nós de espera adicionais não contam para o número de nós certificados

NOTE
As implementações de escala Azure VM de SAP HANA com nó de espera só são possíveis usando o armazenamento de
Ficheiros Azure NetApp. Nenhum outro armazenamento Azure certificado DA SAP HANA permite a configuração de nó de
espera SAP HANA

Para /hana/compartilhado, recomendamos também a utilização de Ficheiros Azure NetApp.


Um design básico típico para um único nó numa configuração de escala vai parecer:
A configuração básica de um nó VM para a escala SAP HANA parece:
Para /hana/shared, utiliza o serviço NFS nativo fornecido através dos Ficheiros Azure NetApp.
Todos os outros volumes de discos não são partilhados entre os diferentes nós e não são baseados em NFS. As
configurações e etapas de instalação para instalações HANA de escala com /hana/data e /hana/log são
fornecidos mais tarde neste documento. Para o armazenamento certificado HANA que pode ser usado,
verifique o artigo Configurações de armazenamento de máquinas virtuais SAP HANA Azure.
Dimensionando os volumes ou discos, é necessário verificar o documento REQUISITOS de Armazenamento SAP
HANA TDI,para o tamanho exigido, dependendo do número de nós de trabalhadores. O documento lança uma
fórmula que precisa de aplicar para obter a capacidade necessária do volume
Os outros critérios de design que são apresentados nos gráficos da configuração do nó único para um SAP HANA
VM de escala é o VNet, ou melhor a configuração da sub-rede. A SAP recomenda vivamente a separação do
cliente/aplicação face ao tráfego das comunicações entre os nós HANA. Como mostrado nos gráficos, este objetivo
é alcançado por ter dois vNICs diferentes ligados ao VM. Ambos os vNICs estão em sub-redes diferentes, têm dois
endereços IP diferentes. Em seguida, controla o fluxo de tráfego com regras de encaminhamento utilizando NSGs
ou rotas definidas pelo utilizador.
Nomeadamente no Azure, não existem meios e métodos para impor a qualidade do serviço e das quotas em vNICs
específicos. Como resultado, a separação da comunicação cliente/aplicação virada para o cliente e para o nó não
abre quaisquer oportunidades para 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ól das configurações de escala.

NOTE
A SAP recomenda a separação do tráfego de rede para o lado cliente/aplicação e o tráfego intra-nól, conforme descrito neste
documento. Assim, é recomendada a colocação de uma arquitetura como mostrado nos últimos gráficos. Consulte também a
sua equipa de segurança e conformidade para os requisitos que se desviam da recomendação

Do ponto de vista em rede, a arquitetura de rede mínima exigida seria:


Instalação sap hana escala-out n Azure
Instalando uma configuração SAP de escala, é necessário executar passos ásperos de:
Implantação de novas ou adaptação de uma infraestrutura Azure VNet existente
Implantação dos novos VMs utilizando o armazenamento premium gerido Azure, volumes ultra-discos e/ou
volumes NFS com base na ANF
Adaptar o encaminhamento de rede para garantir que, por exemplo, a comunicação intra-nó entre VMs
não seja encaminhada através de uma NVA.
Instale o nó mestre SAP HANA.
Adaptar parâmetros de configuração do nó mestre SAP HANA
Continue com a instalação dos nosdes operários SAP HANA
Instalação de SAP HANA em configuração de escala
À medida que a sua infraestrutura Azure VM é implantada, e todos os outros preparativos são feitos, você precisa
instalar as configurações de escala SAP HANA nestes passos:
Instale o nó principal SAP HANA de acordo com a documentação da SAP
No caso de utilizar o armazenamento Azure Premium ou ultra disco com discos não partilhados de /hana/data
e /hana/log, é necessário alterar o ficheiro global.ini e adicionar o parâmetro 'basepath_shared = não' ao
ficheiro global.ini. Este parâmetro permite que o SAP HANA seja executado em escala sem volumes
'partilhados' /hana/dados e /hana/log volumes entre os nós. Os detalhes são documentados na #2080991
da nota SAP. Se estiver a utilizar volumes NFS com base em ANF para /hana/dados e /hana/log, não precisa de
fazer esta alteração
Após a eventual mudança no parâmetro global.ini, reinicie a instância SAP HANA
Adicione nós de trabalhador adicionais. Consulte também
https://help.sap.com/viewer/6b94445c94ae495c83a19646e7c3fd56/2.0.00/en-
US/0d9fe701e2214e98ad4f8721f6558c34.html. Especificar a rede interna para comunicação inter-nólada SAP
HANA durante a instalação ou posterior utilização, por exemplo, do hdblcm local. Para obter documentação
mais detalhada, consulte também a SAP Note #2183363.
Os detalhes para configurar um sistema de escala SAP HANA com nó de espera no SUSE Linux são descritos em
detalhe no Implementar um sistema de escala SAP HANA com nó de espera nos VMs Azure utilizando ficheiros
Azure NetApp no SUSE Linux Enterprise Server. Documentação equivalente para chapéu vermelho pode ser
encontrada no artigo Implementar um sistema de escala SAP HANA com nó de espera em VMs Azure usando
ficheiros Azure NetApp em Red Hat Enterprise Linux.

SAP HANA Dynamic Tiering 2.0 para máquinas virtuais Azure


Para além das certificações SAP HANA em VMs da série Azure M, o SAP HANA Dynamic Tiering 2.0 também é
suportado no Microsoft Azure (ver SAP HANA Dynamic Tiering documentation links mais abaixo). Embora não
haja diferença na instalação do produto ou no seu funcionamento, por exemplo, através do COCKPIT SAP HANA
dentro de uma Máquina Virtual Azure, existem alguns itens importantes, que são obrigatórios para suporte oficial
no Azure. Estes pontos-chave são descritos abaixo. Ao longo do artigo, a abreviatura "DT 2.0" vai ser usada em vez
do nome completo Dynamic Tiering 2.0.
SAP HANA Dynamic Tiering 2.0 não é suportado por SAP BW ou S4HANA. Os principais casos de uso neste
momento são aplicações HANA nativas.
Descrição geral
A imagem abaixo dá uma visão geral sobre o suporte DT 2.0 no Microsoft Azure. Existe um conjunto de requisitos
obrigatórios, que devem ser seguidos para cumprir a certificação oficial:
O DT 2.0 deve ser instalado num Azure VM dedicado. Não pode funcionar no mesmo VM onde o SAP HANA
corre
OS SAP HANA e DT 2.0 VMs devem ser implantados dentro da mesma Azure Vnet
Os HANA SAP e DT 2.0 VMs devem ser implantados com rede acelerada Azure habilitada
O tipo de armazenamento para os DT 2.0 VMs deve ser Azure Premium Storage
Vários discos Azure devem ser ligados ao DT 2.0 VM
É necessário criar um raid de software / volume listrado (seja via LVM ou mdadm) usando striping através dos
discos Azure
Mais detalhes serão explicados nas seguintes secções.

Dedicado Azure VM para SAP HANA DT 2.0


Em Azure IaaS, DT 2.0 só é suportado num VM dedicado. Não é permitido executar DT 2.0 no mesmo Azure VM
onde está a decorrer a instância HANA. Inicialmente podem ser utilizados dois tipos de VM para executar SAP
HANA DT 2.0:
M64-32ms
E32sv3
Consulte a descrição do tipo VM aqui
Dada a ideia básica de DT 2.0, que tem a ver com a descarga de dados "quentes" para poupar custos, faz sentido
utilizar os tamanhos VM correspondentes. Não há nenhuma regra estrita no que diz respeito às combinações
possíveis. Depende da carga de trabalho específica do cliente.
As configurações recomendadas seriam:

T IP O SA P H A N A VM T IP O DT 2. 0 VM

M128ms M64-32ms

M128s M64-32ms

M64ms E32sv3

M64s E32sv3

Todas as combinações de VMs da série M certificadas pela SAP HANA com DT 2.0 VMs suportados (M64-32ms e
E32sv3) são possíveis.
Rede Azure e SAP HANA DT 2.0
A instalação do DT 2.0 num VM dedicado requer a produção de rede entre o DT 2.0 VM e o SAP HANA VM de 10
Gb mínimo. Portanto, é obrigatório colocar todos os VMs dentro do mesmo Azure Vnet e ativar a rede acelerada
do Azure.
Consulte informações adicionais sobre a rede acelerada do Azure aqui
Armazenamento VM para SAP HANA DT 2.0
De acordo com a orientação de boas práticas DT 2.0, a produção de IO do disco deve ser mínima de 50 MB/seg por
núcleo físico. Olhando para a especificação dos dois tipos Azure VM, que são suportados para DT 2.0, o limite
máximo de produção de IO do disco para o VM parece:
E32sv3 : 768 MB/seg (sem cocó), o que significa uma relação de 48 MB/seg por núcleo físico
M64-32ms: 1000 MB/seg (sem cocó), o que significa uma relação de 62,5 MB/seg por núcleo físico
É necessário anexar vários discos Azure ao DT 2.0 VM e criar uma raid de software (striping) ao nível de SO para
atingir o limite máximo de produção de disco por VM. Um único disco Azure não pode fornecer a produção para
atingir o limite máximo de VM a este respeito. O armazenamento Azure Premium é obrigatório para executar DT
2.0.
Detalhes sobre os tipos de discos Azure disponíveis podem ser encontrados aqui
Detalhes sobre a criação de raid de software via mdadm podem ser encontrados aqui
Detalhes sobre a configuração da LVM para criar um volume listrado para a produção máxima podem ser
encontrados aqui
Dependendo dos requisitos de tamanho, existem diferentes opções para alcançar o rendimento máximo de um
VM. Aqui estão possíveis configurações de disco de volume de dados para cada tipo DT 2.0 VM para atingir o limite
superior de produção de VM. O E32sv3 VM deve ser considerado como um nível de entrada para cargas de
trabalho mais pequenas. No caso de se revelar que não é rápido o suficiente, pode ser necessário redimensionar o
VM para M64-32ms. Como o VM M64-32ms tem muita memória, a carga de IO pode não atingir o limite
especialmente para a leitura de cargas de trabalho intensivas. Portanto, menos discos no conjunto de listras podem
ser suficientes dependendo da carga de trabalho específica do cliente. Mas para estar no lado seguro as
configurações do disco abaixo foram escolhidas para garantir a máxima produção:

SK U DA VM DISC O C O N F IG 1 DISC O C O N F IG 2 DISC O C O N F IG 3 DISC O C O N F IG 4 DISC O C O N F IG 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 de a carga de trabalho ser intensa de leitura, poderia aumentar o desempenho do IO para
ligar a cache do anfitrião Azure "read-only", como recomendado para os volumes de dados do software de base de
dados. Considerando que para o registo de transações a cache do disco de anfitrião Azure deve ser "nenhuma".
No que diz respeito ao tamanho do volume de registo, um ponto de partida recomendado é um heurístico de 15%
do tamanho dos dados. A criação do volume de registo pode ser realizada utilizando diferentes tipos de discos
Azure, dependendo dos requisitos de custo e de produção. Para o volume de registo, é necessária uma produção
de E/S elevada. Em caso de utilização do tipo VM M64-32ms, é obrigatório ativar o Acelerador de Escrita. O
Acelerador Azure Write fornece uma latência de escrita de disco ideal para o registo de transações (apenas
disponível para série M). Existem alguns itens a considerar, embora como o número máximo de discos por tipo VM.
Detalhes sobre o Acelerador de Escrita podem ser encontrados aqui
Aqui estão alguns exemplos sobre o dimensionamento do volume de registo:

TA M A N H O DO VO L UM E DE DA DO S E VO L UM E DE LO G E T IP O DE DISC O VO L UM E DE LO G E T IP O DE DISC O
T IP O DE DISC O C O N F IG 1 C O N F IG 2

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

Tal como para a escala SAP HANA, o diretório /hana/partilhado tem de ser partilhado entre o SAP HANA VM e o
DT 2.0 VM. Recomenda-se a mesma arquitetura que para a escala SAP HANA utilizando VMs dedicados, que
funcionam como um servidor NFS altamente disponível. Para fornecer um volume de backup partilhado, o design
idêntico pode ser usado. Mas cabe ao cliente se ha seria necessário ou se é suficiente apenas usar um VM dedicado
com capacidade de armazenamento suficiente para funcionar como um servidor de backup.
Links para documentação DT 2.0
Sap HANA Dynamic Tiering instalação e guia de atualização
Tutoriais e recursos dinâmicos SAP HANA
POC dinâmico de tiering SAP HANA
SAP HANA 2.0 SPS 02 melhorias dinâmicas do tiering

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


As seguintes secções descrevem algumas das operações relacionadas com a implantação de sistemas SAP HANA
em VMs Azure.
Apoiar e restaurar as operações em VMs Azure
Os seguintes documentos descrevem como fazer o back up e restaurar a sua implantação SAP HANA:
Descrição geral da cópia de segurança do SAP HANA
Backup de nível de ficheiro SAP HANA
Referência de instantâneo de armazenamento SAP HANA
Iniciar e reiniciar VMs que contenham SAP HANA
Uma característica proeminente da nuvem pública Azure é que você é cobrado apenas para os seus minutos de
computação. Por exemplo, quando desligas um VM que está a funcionar o SAP HANA, só és cobrado pelos custos
de armazenamento durante esse tempo. Outra funcionalidade está disponível quando especifica endereços IP
estáticos para os seus VMs na sua implementação inicial. Quando reinicia um VM que tem SAP HANA, o VM
reinicia com os seus endereços IP anteriores.
Utilize SAProuter para suporte remoto SAP
Se tem uma ligação site-to-site entre as suas localizações no local e Azure, e está a executar componentes SAP,
então provavelmente já está a executar SAProuter. Neste caso, preencha os seguintes itens para suporte remoto:
Mantenha o endereço IP privado e estático do VM que acolhe o SAP HANA na configuração SAProuter.
Configure o NSG da sub-rede que acolhe o HANA VM para permitir o tráfego através da porta TCP/IP 3299.
Se estiver a ligar-se ao Azure através da internet, e não tiver um router SAP para o VM com SAP HANA, então tem
de instalar o componente. Instale o SAProuter num VM separado na sub-rede De Gestão. A imagem a seguir
mostra um esquema áspero para a implantação do SAP HANA sem uma ligação site-to-site e com o SAProuter:

Certifique-se de que instala o SAProuter num VM separado e não no seu VM jumpbox. O VM separado deve ter
um endereço IP estático. Para ligar o SAProuter ao SAProuter que é hospedado pela SAP, contacte o SAP para obter
um endereço IP. (O SAProuter que é hospedado pela SAP é a contrapartida da instância SAProuter que instala no
seu VM.) Utilize o endereço IP da SAP para configurar a sua instância SAProuter. Nas definições de configuração, a
única porta necessária é a porta TCP 3299.
Para obter mais informações sobre como configurar e manter ligações de suporte remoto através do SAProuter,
consulte a documentação SAP.
Alta disponibilidade com SAP HANA em VMs nativos Azure
Se estiver a executar o SUSE Linux Enterprise Server ou o Red Hat, pode estabelecer um cluster Pacemaker com
dispositivos STONITH. Pode utilizar os dispositivos para configurar uma configuração SAP HANA que utiliza
replicação sincronizada com replicação do sistema HANA e falha automática. Para mais informações listadas na
secção "próximos passos".

Passos Seguintes
Familiarize-se com os artigos listados
Configurações de armazenamento da máquina virtual do Azure do SAP HANA
Implementar um sistema de escala SAP HANA com nó de espera em VMs Azure utilizando ficheiros Azure
NetApp no SUSE Linux Enterprise Server
Implementar um sistema de escala SAP HANA com nó de espera em VMs Azure utilizando ficheiros Azure
NetApp no Red Hat Enterprise Linux
Alta disponibilidade de SAP HANA em VMs Azure no SUSE Linux Enterprise Server
Alta disponibilidade de SAP HANA em VMs Azure em Red Hat Enterprise Linux
Configurações de armazenamento da máquina
virtual do Azure do SAP HANA
20/05/2020 • 47 minutes to read • Edit Online

O Azure fornece diferentes tipos de armazenamento que são adequados para VMs Azure que estão a executar SAP
HANA. Os tipos de armazenamento Azure cer tificados SAP HANA que podem ser considerados para a lista
de implementações sap HANA como:
Azure Premium SSD
Disco Ultra
Azure NetApp Files
Para saber sobre estes tipos de disco, consulte o artigo Selecione um tipo de disco
O Azure oferece dois métodos de implementação para VHDs em Acabamentos Standard Azure e Armazenamento
Premium. Se o cenário geral permitir, aproveite as implementações de discos geridos pelo Azure.
Para obter uma lista de tipos de armazenamento e os seus SLAs em IOPS e entrada de armazenamento, reveja a
documentação azure para discos geridos.

IMPORTANT
Independentemente do tipo de armazenamento Azure escolhido, o sistema de ficheiros utilizado nesse armazenamento
precisa de ser suportado pela SAP para o sistema operativo específico e dbmS. A nota de suporte sAP #405827 lista os
sistemas de ficheiros suportados para diferentes sistemas operativos e bases de dados, incluindo o SAP HANA. Isto aplica-se
a todos os volumes Que o SAP HANA pode ter acesso para leitura e escrita para qualquer tarefa. Especificamente utilizando
o NFS em Azure para sap HANA, as restrições adicionais das versões NFS aplicam-se, conforme indicado mais tarde neste
artigo

As condições mínimas certificadas sAP HANA para os diferentes tipos de armazenamento são:
Azure Premium SSD - /hana/log é necessário para ser cached com Acelerador de EscritaAzure . O volume
/hana/data pode ser colocado em SSD Premium sem acelerador de escrita Azure ou em disco Ultra
Disco Azure Ultra pelo menos para o volume /hana/log. O volume /hana/data pode ser colocado em SSD
Premium sem acelerador de escrita Azure ou para obter tempos de reinício mais rápidoS disco
Volumes NFS v4.1 em cima dos Ficheiros Azure NetApp para /hana/log e /hana/data. O volume de
/hana/compartilhado pode utilizar o protocolo NFS v3 ou NFS v4.1. O protocolo NFS v4.1 é obrigatório para
/hana/data//hana/log volumes.
Alguns dos tipos de armazenamento podem ser combinados. Por exemplo, é possível colocar /hana/dados no
Armazenamento Premium e /hana/log pode ser colocado no armazenamento de disco Ultra de forma a obter a
baixa latência necessária. No entanto, se utilizar um volume NFS v4.1 baseado em ANF para /hana/dados, é
obrigado a utilizar outro volume NFS v4.1 baseado no ANF para /hana/log. Não é supor tado o uso de NFS em
cima da ANF para um dos volumes (como /hana/data) e armazenamento Premium Azure ou disco Ultra para o
outro volume (como /hana/log).
No mundo das instalações, raramente se preocupava com os subsistemas de I/S e as suas capacidades. A razão era
que o vendedor de aparelhos precisava de se certificar de que os requisitos mínimos de armazenamento são
cumpridos para o SAP HANA. Ao construir a infraestrutura Azure, deve estar ciente de alguns destes requisitos
emitidos pela SAP. Algumas das características mínimas de entrada que são exigidas à SAP, estão a resultar na
necessidade de:
Ativar a leitura/escrever em /hana/log de um 250 MB/seg com tamanhos de 1 MB I/O
Ativar a atividade de leitura de pelo menos 400 MB/seg para /hana/dados para tamanhos de 16 MB e 64 MB
I/O
Ativar a atividade de escrita de pelo menos 250 MB/seg para /hana/dados com tamanhos de 16 MB e 64 MB
I/O
Dado que a baixa latência de armazenamento é fundamental para os sistemas DBMS, mesmo que o DBMS, como o
SAP HANA, mantenha os dados na memória. O caminho crítico no armazenamento é geralmente em torno dos
registos de transações dos sistemas DBMS. Mas também operações como escrever pontos de salvamento ou
carregar dados na memória após a recuperação do acidente podem ser cruciais. Por isso, é obrigatório alavancar
discos Premium Azure para /hana/data e /hana/log volumes. Para obter a entrada mínima de /hana/log e
/hana/data, conforme desejado pelo SAP, é necessário construir um RAID 0 utilizando MDADM ou LVM sobre
vários discos de Armazenamento Premium Azure. E utilize os volumes RAID como /hana/data e volumes
/hana/log.

IMPORTANT
Os três Sistemas de Ficheiros /dados SAP HANA, /log e /shared não devem ser colocados num grupo de volume padrão ou
raiz. É altamente recomendado seguir a orientação dos Fornecedores Linux, que é tipicamente criar grupos de volume
individuais para /dados, /log e /shared.

Recomendação: Como tamanhos de listras para o RAID 0, a recomendação é usar :


256 KB para /hana/dados
32 KB para /hana/log

IMPORTANT
O tamanho da risca para /hana/dados foi alterado de recomendações anteriores, pedindo 64 KB ou 128 KB para 256 KB com
base nas experiências do cliente com versões linux mais recentes. O tamanho de 256 KB está proporcionando um
desempenho ligeiramente melhor

NOTE
Não é necessário configurar qualquer nível de redundância utilizando volumes RAID uma vez que o armazenamento Azure
Premium e Standard mantém três imagens de um VHD. A utilização de um volume RAID é puramente para configurar
volumes que fornecem uma entrada suficiente de I/S.

Acumular uma série de VHDs Azure por baixo de um RAID, é acumulado a partir de um iOPS e do lado de entrada
de armazenamento. Assim, se colocar um RAID 0 sobre discos de armazenamento Premium 3 x P30 Azure, deve
dar-lhe três vezes o IOPS e três vezes a entrada de armazenamento de um único disco Azure Premium Storage
P30.
Tenha também em mente a entrada geral de I/O em vm ao dimensionar ou decidir um VM. A entrada global de
armazenamento vm está documentada no artigo Tamanhos de máquina virtual otimizadospela memória.

Modo Programador Linux I/O


O Linux tem vários modos de agendamento de I/S diferentes. A recomendação comum através dos fornecedores
Linux e do SAP é reconfigurar o modo de programador de I/S para volumes de disco desde o prazo mq ou o
modo kyber até ao noop (não-multifila) ou nenhum para o modo (multifila). Os detalhes são referenciados no
#1984787 de Nota SAP.

Soluções com Armazenamento Premium e Acelerador de Escrita Azure


para máquinas virtuais da Série M Azure
O Acelerador De Escrita Azure é uma funcionalidade que está disponível exclusivamente para VMs da Série M.
Azure. Como o nome indica, o objetivo da funcionalidade é melhorar a latência de I/O de escritas contra o
Armazenamento Premium Azure. Para o SAP HANA, o Acelerador de Escrita deve ser utilizado apenas contra o
volume /hana/log. Portanto, o /hana/data e /hana/log são volumes separados com o Acelerador de Escrita
Azure suportando apenas o volume /hana/log.

IMPORTANT
Ao utilizar o Armazenamento Azure Premium, a utilização do Acelerador de Escrita Azure ou o volume de /hana/log é
obrigatória. Write Accelerator está disponível apenas para Armazenamento premium e Série M e VMs sérieM.

As recomendações de cache abaixo estão assumindo as características de I/O para SAP HANA que lista como:
Quase não há nenhuma carga de trabalho lida contra os ficheiros de dados da HANA. As exceções são de
grandes dimensões em I/Os após o reinício da instância HANA ou quando os dados são carregados em HANA.
Outro caso de I/Os de leitura maior contra ficheiros de dados pode ser backups de base de dados HANA. Como
resultado, a maior parte das vezes não faz sentido, uma vez que na maioria dos casos, todos os volumes de
ficheiros de dados precisam de ser lidos completamente.
Escrever contra os ficheiros de dados é experimentado em explosões baseadas em pontos de salvamento
HANA e recuperação de acidentes HANA. Escrever pontos de poupança é assíncrono e não está a atrasar
quaisquer transações de utilizadores. Escrever dados durante a recuperação do acidente é fundamental para
que o sistema responda rapidamente. No entanto, a recuperação de acidentes deve ser situações bastante
excecionais
Quase não há leituras dos ficheiros hana refazer. As exceções são grandes I/Os ao efetuar backups de registo de
transações, recuperação de acidentes ou na fase de reinício de uma instância HANA.
A carga principal contra o ficheiro de redo do SAP HANA é escrita. Dependendo da natureza da carga de
trabalho, pode ter I/Os tão pequeno como 4 KB ou em outros casos tamanhos de I/O de 1 MB ou mais. Escrever
latência contra o registo de redodo SAP HANA é crítico de desempenho.
Todos os escritos precisam de ser persistidos no disco de uma forma fiável
Recomendação: Como resultado destes padrões de I/S obser vados pela SAP HANA, o cache para os
diferentes volumes utilizando o Armazenamento Premium Azure deve ser definido como:
/hana/dados - sem cache
/hana/log - sem cache - exceção para m-e Mv2-Series onde o Acelerador de Escrita deve ser ativado sem o
cache lido.
/hana/shared - ler cache
Solução de armazenamento recomendada para produção

IMPORTANT
A certificação SAP HANA para máquinas virtuais Azure M-Series é exclusivamente com o Acelerador de Escrita Azure para o
volume /hana/log. Como resultado, espera-se que as implementações do SAP HANA em máquinas virtuais da Série M
Azure sejam configuradas com o Acelerador de Escrita Azure para o volume /hana/log.
NOTE
Para cenários de produção, verifique se um certo tipo de VM é suportado para SAP HANA por SAP na documentação SAP
para IAAS.

As recomendações excedem frequentemente os requisitos mínimos do SAP, tal como referido no início do presente
artigo. As recomendações listadas são um compromisso entre as recomendações de tamanho da SAP e o máximo
de armazenamento que os diferentes tipos de VM fornecem.
Recomendação: As configurações recomendadas para cenários de produção parecem:

UM
M Á XIM O
DE VM /HANA/C
SK U DA I/ O /HANA/D /HANA/L O M PA RT I / VO L UM E / USR/ SEIV H ANA/BA
VM RA M DÉB ITO A DO S OG L H A DO DE RA IZ A C K UP

M32ts 192 GiB 500 MB/s 3 x P20 2 x P20 1 x P20 1 x P6 1 x P6 1 x P20

M32ls 256 GiB 500 MB/s 3 x P20 2 x P20 1 x P20 1 x P6 1 x P6 1 x P20

M64ls 512 GiB 1000 3 x P20 2 x P20 1 x P20 1 x P6 1 x P6 1 x P30


MB/s

M64s 1000 Gib 1000 4 x P20 2 x P20 1 x P30 1 x P6 1 x P6 2 x P30


MB/s

M64ms 1750 Gib 1000 3 x P30 2 x P20 1 x P30 1 x P6 1 x P6 3 x P30


MB/s

M128s GiB de 2000 3 x P30 2 x P20 1 x P30 1 x P10 1 x P6 2 x P40


2000 MB/s

M128ms 3800 GiB 2000 5 x P30 2 x P20 1 x P30 1 x P10 1 x P6 4 x P40


MB/s

M208s_v 2850 GiB 1000 4 x P30 2 x P20 1 x P30 1 x P10 1 x P6 3 x P40


2 MB/s

M208ms_ 5700 GiB 1000 4 x P40 2 x P20 1 x P30 1 x P10 1 x P6 3 x P50


v2 MB/s

M416s_v 5700 GiB 2000 4 x P40 2 x P20 1 x P30 1 x P10 1 x P6 3 x P50


2 MB/s

M416ms_ 11400 2000 8 x P40 2 x P20 1 x P30 1 x P10 1 x P6 4 x P50


v2 GiB MB/s

Verifique se a entrada de armazenamento dos diferentes volumes sugeridos corresponde à carga de trabalho que
pretende executar. Se a carga de trabalho necessitar de volumes mais elevados para /hana/data e /hana/log,
precisa aumentar o número de VHDs de Armazenamento Premium Azure. Dimensionar um volume com mais
VHDs do que listado aumenta a entrada de IOPS e I/S dentro dos limites do tipo de máquina virtual Azure.
O Acelerador De Escrita Azure só funciona em conjunto com discos geridos pela Azure. Assim, pelo menos os
discos de armazenamento Premium Azure que formam o volume /hana/log precisam de ser implantados como
discos geridos.
Existem limites de VHDs de Armazenamento Premium Azure por VM que podem ser suportados pelo Acelerador
de Escrita Azure. Os limites atuais são:
16 VHDs para um M128xx e M416xx VM
8 VHDs para um M64xx e M208xx VM
4 VHDs para um M32xx VM
Instruções mais detalhadas sobre como ativar o acelerador de escrita azure podem ser encontradas no artigo
Write Accelerator.
Detalhes e restrições para o Acelerador de Escrita Azure podem ser encontrados na mesma documentação.
Recomendação: Você precisa usar acelerador de escrita para discos que formem o volume /hana/log
Configuração de armazenamento azure consciente do custo
A tabela seguinte mostra uma configuração de tipos VM que os clientes também usam para hospedar SAP HANA
em VMs Azure. Pode haver alguns tipos de VM que podem não cumprir todos os critérios mínimos de
armazenamento para o SAP HANA ou não são oficialmente suportados com o SAP HANA pela SAP. Mas até agora
esses VMs pareciam ter um bom desempenho para cenários de não produção. Os dados /hana/data e
/hana/log são combinados a um volume. Como resultado, o uso do Acelerador de Escrita Azure pode tornar-se
uma limitação em termos de IOPS.

NOTE
Para cenários suportados pela SAP, verifique se um certo tipo de VM é suportado para SAP HANA por SAP na documentação
SAP para IAAS.

NOTE
Uma mudança das recomendações anteriores para uma solução consciente dos custos, é passar dos discos HDD Padrão
Azure para discos SSD standard mais bem-sucedidos e mais fiáveis

As recomendações excedem frequentemente os requisitos mínimos do SAP, tal como referido no início do presente
artigo. As recomendações listadas são um compromisso entre as recomendações de tamanho da SAP e o máximo
de armazenamento que os diferentes tipos de VM fornecem.

/ H A N A / DA
TA E
/ H A N A / LO
UM G
M Á XIM O L IST RA DO /HANA/CO
DE VM I/ O C O M LVM M PA RT IL H A / VO L UM E H ANA/BAC
SK U DA VM RA M DÉB ITO O U M DA DM DO DE RA IZ / USR/ SEIVA K UP

DS14v2 112 GiB 768 MB/s 3 x P20 1 x E20 1 x E6 1 x E6 1 x E15

E16v3 128 GiB 384 MB/s 3 x P20 1 x E20 1 x E6 1 x E6 1 x E15

E32v3 256 GiB 768 MB/s 3 x P20 1 x E20 1 x E6 1 x E6 1 x E20

E64v3 432 GiB 1.200 MB/s 3 x P20 1 x E20 1 x E6 1 x E6 1 x E30

GS5 448 GiB 2.000 MB/s 3 x P20 1 x E20 1 x E6 1 x E6 1 x E30

M32ts 192 GiB 500 MB/s 3 x P20 1 x E20 1 x E6 1 x E6 1 x E20


/ H A N A / DA
TA E
/ H A N A / LO
UM G
M Á XIM O L IST RA DO /HANA/CO
DE VM I/ O C O M LVM M PA RT IL H A / VO L UM E H ANA/BAC
SK U DA VM RA M DÉB ITO O U M DA DM DO DE RA IZ / USR/ SEIVA K UP

M32ls 256 GiB 500 MB/s 3 x P20 1 x E20 1 x E6 1 x E6 1 x E20

M64ls 512 GiB 1.000 MB/s 3 x P20 1 x E20 1 x E6 1 x E6 1 x E30

M64s 1.000 GiB 1.000 MB/s 2 x P30 1 x E30 1 x E6 1 x E6 2 x E30

M64ms 1.750 GiB 1.000 MB/s 3 x P30 1 x E30 1 x E6 1 x E6 3 x E30

M128s 2.000 GiB 2.000 MB/s 3 x P30 1 x E30 1 x E10 1 x E6 2 x E40

M128ms 3.800 GiB 2.000 MB/s 5 x P30 1 x E30 1 x E10 1 x E6 2 x E50

M208s_v2 2.850 GiB 1.000 MB/s 4 x P30 1 x E30 1 x E10 1 x E6 3 x E40

M208ms_v 5.700 GiB 1.000 MB/s 4 x P40 1 x E30 1 x E10 1 x E6 4 x E40


2

M416s_v2 5.700 GiB 2.000 MB/s 4 x P40 1 x E30 1 x E10 1 x E6 4 x E40

M416ms_v 11400 GiB 2.000 MB/s 8 x P40 1 x E30 1 x E10 1 x E6 4 x E50


2

Os discos recomendados para os tipos de VM mais pequenos com 3 x P20 oversize os volumes relativos às
recomendações espaciais de acordo com o SAP TDI Storage Whitepaper. No entanto, a escolha, tal como
apresentada na tabela, foi feita para fornecer uma entrada de disco suficiente para o SAP HANA. Se necessitar de
alterações no volume /hana/backup, que foi dimensionado para manter cópias de segurança que representam o
dobro do volume de memória, sinta-se à vontade para ajustar.
Verifique se a entrada de armazenamento dos diferentes volumes sugeridos corresponde à carga de trabalho que
pretende executar. Se a carga de trabalho necessitar de volumes mais elevados para /hana/data e /hana/log,
precisa aumentar o número de VHDs de Armazenamento Premium Azure. Dimensionar um volume com mais
VHDs do que listado aumenta a entrada de IOPS e I/S dentro dos limites do tipo de máquina virtual Azure.

NOTE
As configurações acima não beneficiariam da máquina virtual Azure Única VM SLA, uma vez que utiliza uma mistura de
Armazenamento Premium Azure e Armazenamento Padrão Azure. No entanto, a seleção foi escolhida para otimizar os
custos. Você precisaria escolher O Armazenamento Premium para todos os discos acima que listados como Azure Standard
Storage (Sxx) para tornar a configuração VM em conformidade com o VM SLA single Azure.
NOTE
As recomendações de configuração do disco indicadas visam os requisitos mínimos que a SAP expressa para os seus
fornecedores de infraestruturas. Em implementações reais de clientes e cenários de carga de trabalho, foram encontradas
situações em que estas recomendações ainda não forneceram capacidades suficientes. Estas podem ser situações em que um
cliente exigiu uma recarga mais rápida dos dados após um reinício hana ou onde as configurações de backup exigiam maior
largura de banda para o armazenamento. Outros casos incluíam /hana/log onde 5000 IOPS não eram suficientes para a
carga de trabalho específica. Por isso, tome estas recomendações como ponto de partida e adapte-se com base nos
requisitos da carga de trabalho.

Configuração de armazenamento de disco Azure Ultra para SAP HANA


A Microsoft está em processo de lançar um novo tipo de armazenamento Azure chamado disco Azure Ultra. A
diferença significativa entre o armazenamento Azure oferecido até agora e o disco Ultra é que as capacidades do
disco já não estão ligadas ao tamanho do disco. Como cliente pode definir estas capacidades para disco Ultra:
Tamanho de um disco que varia de 4 GiB a 65.536 GiB
Os IOPS variam entre 100 IOPS e 160K IOPS (o máximo depende também dos tipos de VM)
Entrada de armazenamento de 300 MB/seg a 2.000 MB/seg
O disco ultra dá-lhe a possibilidade de definir um único disco que cumpra o seu tamanho, IOPS e intervalo de
entrada de disco. Em vez de utilizar gestores de volumelógicos como o LVM ou o MDADM em cima do
Armazenamento Premium Azure para construir volumes que satisfaçam os requisitos de iopS e de
armazenamento. Pode executar uma mistura de configuração entre o disco Ultra e o Armazenamento Premium.
Como resultado, pode limitar o uso do disco Ultra ao desempenho crítico /hana/data e /hana/log volumes e cobrir
os outros volumes com Armazenamento Premium Azure
Outras vantagens do disco Ultra podem ser a latência mais lida em comparação com o Armazenamento Premium.
A latência mais rápida pode ter vantagens quando pretende reduzir os tempos de arranque da HANA e a carga
subsequente dos dados na memória. Vantagens do armazenamento de discos Ultra também podem ser sentidas
quando a HANA está a escrever pontos de poupança. Uma vez que os discos de armazenamento premium para
/hana/dados geralmente não são cachede Write Accelerator, a latência escrita para /hana/dados no
Armazenamento Premium em comparação com o disco Ultra é maior. Pode esperar-se que a escrita de savepoint
com o disco Ultra esteja a ter um melhor desempenho no disco Ultra.

IMPORTANT
O disco ultra ainda não está presente em todas as regiões do Azure e também ainda não está a apoiar todos os tipos de VM
listados abaixo. Para obter informações detalhadas onde o disco Ultra está disponível e quais as famílias vm que são
apoiadas, verifique o artigo Quais os tipos de discos disponíveis em Azure?

Solução de armazenamento recomendada para produção com configuração de disco Ultra puro
Nesta configuração, mantenha separadamente os volumes /hana/data e /hana/log. Os valores sugeridos são
derivados das KPIs que o SAP tem de certificar os tipos de VM para SAP HANA e configurações de
armazenamento, conforme recomendado no Livro Branco de Armazenamento SAP TDI.
As recomendações excedem frequentemente os requisitos mínimos do SAP, tal como referido no início do presente
artigo. As recomendações listadas são um compromisso entre as recomendações de tamanho da SAP e o máximo
de armazenamento que os diferentes tipos de VM fornecem.
UM
M Á XIM O /HANA/V /HANA/V
DE VM O L UM E O L UM E
SK U DA I/ O DE /HANA/D /HANA/D DE /HANA/L /HANA/L
VM RA M DÉB ITO DA DO S A DO S I/ O ATA IO P S REGISTO O G I/ O O G IO P S

E64s_v3 432 GiB 1.200 600 GB 700 MBps 7.500 512 GB 500 MBps 2.000
MB/s

M32ts 192 GiB 500 MB/s 250 GB 400 MBps 7.500 256 GB 250 MBps 2.000

M32ls 256 GiB 500 MB/s 300 GB 400 MBps 7.500 256 GB 250 MBps 2.000

M64ls 512 GiB 1.000 600 GB 600 MBps 7.500 512 GB 400 MBps 2.500
MB/s

M64s 1.000 GiB 1.000 1.200 GB 600 MBps 7.500 512 GB 400 MBps 2.500
MB/s

M64ms 1.750 GiB 1.000 2.100 GB 600 MBps 7.500 512 GB 400 MBps 2.500
MB/s

M128s 2.000 GiB 2.000 2.400 GB 1.200 9000 512 GB 800 MBps 3.000
MB/s MBps

M128ms 3.800 GiB 2.000 4.800 GB 1200 9000 512 GB 800 MBps 3.000
MB/s MBps

M208s_v 2.850 GiB 1.000 3.500 GB 1.000 9000 512 GB 400 MBps 2.500
2 MB/s MBps

M208ms_ 5.700 GiB 1.000 7.200 GB 1.000 9000 512 GB 400 MBps 2.500
v2 MB/s MBps

M416s_v 5.700 GiB 2.000 7.200 GB 1.500 9000 512 GB 800 MBps 3.000
2 MB/s MBps

M416ms_ 11.400 2.000 14.400 1.500 9000 512 GB 800 MBps 3.000
v2 GiB MB/s GB MBps

Os valores enumerados destinam-se a ser um ponto de partida e precisam de ser avaliados em comparação com
as reais exigências. A vantagem com o disco Azure Ultra é que os valores para iOPS e produção podem ser
adaptados sem a necessidade de desligar o VM ou parar a carga de trabalho aplicada ao sistema.

NOTE
Até ao momento, não estão disponíveis instantâneos de armazenamento com armazenamento de discos Ultra. Isto bloqueia
o uso de instantâneos VM com serviços de backup Azure

Solução de armazenamento consciente de custo com configuração de disco Ultra puro


Nesta configuração, você os volumes /hana/data e /hana/log no mesmo disco. Os valores sugeridos são derivados
das KPIs que o SAP tem de certificar os tipos de VM para SAP HANA e configurações de armazenamento,
conforme recomendado no Livro Branco de Armazenamento SAP TDI.
As recomendações excedem frequentemente os requisitos mínimos do SAP, tal como referido no início do presente
artigo. As recomendações listadas são um compromisso entre as recomendações de tamanho da SAP e o máximo
de armazenamento que os diferentes tipos de VM fornecem.

UM M Á XIM O DE VO L UM E PA RA
VM I/ O / H A N A / DATA E / H A N A / DATA E / H A N A / DATA E
SK U DA VM RA M DÉB ITO / LO G LO G I/ O IO P S DE LO G

E64s_v3 432 GiB 1.200 MB/s 1.200 GB 1.200 MBps 9,500

M32ts 192 GiB 500 MB/s 512 GB 400 MBps 9,500

M32ls 256 GiB 500 MB/s 600 GB 400 MBps 9,500

M64ls 512 GiB 1.000 MB/s 1.100 GB 900 MBps 10,000

M64s 1.000 GiB 1.000 MB/s 1.700 GB 900 MBps 10,000

M64ms 1.750 GiB 1.000 MB/s 2.600 GB 900 MBps 10,000

M128s 2.000 GiB 2.000 MB/s 2.900 GB 1.800 MBps 12.000

M128ms 3.800 GiB 2.000 MB/s 5.300 GB 1.800 MBps 12.000

M208s_v2 2.850 GiB 1.000 MB/s 4.000 GB 900 MBps 10,000

M208ms_v2 5.700 GiB 1.000 MB/s 7.700 GB 900 MBps 10,000

M416s_v2 5.700 GiB 2.000 MB/s 7.700 GB 1.800MBps 12.000

M416ms_v2 11.400 GiB 2.000 MB/s 15.000 GB 1.800 MBps 12.000

Os valores enumerados destinam-se a ser um ponto de partida e precisam de ser avaliados em comparação com
as reais exigências. A vantagem com o disco Azure Ultra é que os valores para iOPS e produção podem ser
adaptados sem a necessidade de desligar o VM ou parar a carga de trabalho aplicada ao sistema.

Volumes NFS v4.1 em Ficheiros Azure NetApp


O Azure NetApp Files fornece ações nativas da NFS que podem ser usadas para /hana/partilhado, /hana/data, e
/hana/log volumes. A utilização de ações nfs baseadas em ANF para os volumes /hana/data e /hana/log requer a
utilização do protocolo V4.1 NFS. O protocolo NFS v3 não é suportado para a utilização de volumes /hana/data e
/hana/log ao basear as ações na ANF.

IMPORTANT
O protocolo NFS v3 implementado nos Ficheiros Azure NetApp não é suportado para ser utilizado para /hana/data e
/hana/log. A utilização do NFS 4.1 é obrigatória para /hana/data e /hana/log volumes de um ponto de vista funcional.
Considerando que, para o volume /hana/partilhado, o NFS v3 ou o protocolo NFS v4.1 podem ser utilizados do ponto de
vista funcional.

Considerações importantes
Ao considerar os Ficheiros Azure NetApp para o SAP Netweaver e SAP HANA, esteja ciente das seguintes
considerações importantes:
A piscina de capacidade mínima é 4 TiB.
O tamanho mínimo do volume é de 100 GiB
Os Ficheiros Azure NetApp e todas as máquinas virtuais, onde serão montados volumes de Ficheiros Azure
NetApp, devem estar na mesma Rede Virtual Azure ou em redes virtuais na mesma região.
A rede virtual selecionada deve ter uma subnet, delegada nos Ficheiros Azure NetApp.
A produção de um volume Azure NetApp é uma função do nível de quota de volume e de serviço, tal como
documentado no nível de Serviço para Ficheiros Azure NetApp. Ao dimensionar os volumes HANA Azure
NetApp, certifique-se de que a entrada resultante satisfaz os requisitos do sistema HANA.
O Azure NetApp Files oferece política de exportação:pode controlar os clientes permitidos, o tipo de acesso
(Ler&Escrever, Ler Apenas, etc.).
A funcionalidade De Ficheiros Azure NetApp ainda não está ciente da zona. Atualmente, a funcionalidade Azure
NetApp Files não está implementada em todas as zonas de disponibilidade de uma região do Azure. Esteja
ciente das potenciais implicações de latência em algumas regiões de Azure.
É importante que as máquinas virtuais se desloque nas proximidades do armazenamento Azure NetApp para
baixa latência.
O ID do utilizador para sid adm e o ID do grupo sapsys para as máquinas virtuais devem coincidir com a
configuração em Ficheiros Azure NetApp.

IMPORTANT
Para as cargas de trabalho da SAP HANA, a baixa latência é crítica. Trabalhe com o seu representante da Microsoft para
garantir que as máquinas virtuais e os volumes de Ficheiros Azure NetApp são implantados nas proximidades.

IMPORTANT
Se houver um desfasamento entre o ID do utilizador para sid adm e o ID do grupo entre sapsys a máquina virtual e a
configuração Azure NetApp, as permissões para ficheiros em volumes Azure NetApp, montados em máquinas virtuais, serão
apresentadas como nobody . Certifique-se de especificar o ID de utilizador correto para sid adm e o ID do grupo sapsys
para, quando embarcar um novo sistema para Ficheiros Azure NetApp.

Dimensionamento para base de dados HANA em Ficheiros Azure NetApp


A entrada de um volume Azure NetApp é uma função do tamanho do volume e nível de serviço, conforme
documentado no nível de Serviço para Ficheiros Azure NetApp.
Ao conceber a infraestrutura para SAP em Azure, deve estar ciente de alguns requisitos mínimos de
armazenamento por Parte Da SAP, que se traduzem em características mínimas de rendimento de:
Ativar a leitura/escrever em /hana/log de um 250 MB/seg com tamanhos de 1 MB I/O
Ativar a atividade de leitura de pelo menos 400 MB/seg para /hana/dados para tamanhos de 16 MB e 64 MB
I/O
Ativar a atividade de escrita de pelo menos 250 MB/seg para /hana/dados com tamanhos de 16 MB e 64 MB
I/O
Os limites de produção dos Ficheiros Azure NetApp por 1 TiB de quota de volume são:
Premium Storage Tier - 64 MiB/s
Ultra Storage Tier - 128 MiB/s
IMPORTANT
Independentemente da capacidade que desloque num único volume NFS, espera-se que o planalto atinja a largura de banda
de 1,2-1,4 GB/seg alavancada por um consumidor numa máquina virtual. Isto tem a ver com a arquitetura subjacente da
oferta da ANF e os limites de sessão linux relacionados em torno do NFS. Os números de desempenho e de desempenho, tal
como documentados no artigo, foram realizados resultados de testes de referência de desempenho para Ficheiros Azure
NetApp contra um volume NFS partilhado com vários VMs de clientes e como resultado com várias sessões. Este cenário é
diferente do cenário que medimos no SAP. Quando medimos a entrada de um único VM contra um volume NFS. hospedado
na ANF.

Para satisfazer os requisitos mínimos de entrada de dados e registo sapeios os dados e registos, e de acordo com
as diretrizes /hana/shared para, os tamanhos recomendados seriam:

TA M A N H O
N ÍVEL DE TA M A N H O
A RM A Z EN A M EN TO N ÍVEL ULT RA P ROTO C O LO N F S
VO L UM E P REM IUM A RM A Z EN A M EN TO SUP O RTA DO

/hana/log/ 4 TiB 2 TiB v4.1

/hana/dados 6.3 Tib 3.2 Tib v4.1

/hana/compartilhado Máx (512 GB, 1xRAM) por 4 Máx (512 GB, 1xRAM) por 4 v3 ou v4.1
nós de trabalhador nós de trabalhador

NOTE
As recomendações de dimensionamento do Azure NetApp, aqui indicadas, visam cumprir os requisitos mínimos que a SAP
expressa para os seus fornecedores de infraestruturas. Em implementações reais de clientes e cenários de carga de trabalho,
isso pode não ser suficiente. Utilize estas recomendações como ponto de partida e adapte-se, com base nos requisitos da
sua carga de trabalho específica.

Por isso, pode considerar a implementação de um misto semelhante para os volumes ANF listados para
armazenamento de discos Ultra já. Considere também os tamanhos dos tamanhos listados para os volumes para
as diferentes VM SKUs já feitas nas tabelas de discos Ultra.

TIP
Pode redimensionar os volumes do Azure NetApp Files de forma dinâmica, sem a necessidade dos unmount volumes, parar
as máquinas virtuais ou parar o SAP HANA. Isso permite flexibilidade para satisfazer a sua aplicação, tanto esperadas como
imprevistas exigências de entrada.

A documentação sobre como implementar uma configuração de escala SAP HANA com nó de standby utilizando
volumes NFS v4.1 que estão hospedados na ANF é publicada em escala SAP HANA com nó de standby em VMs
Azure com Ficheiros Azure NetApp no SUSE Linux Enterprise Server.

Passos seguintes
Para obter mais informações, consulte:
Guia de alta disponibilidade SAP HANA para máquinas virtuais Azure.
SAP HANA alta disponibilidade para máquinas
virtuais Azure
28/04/2020 • 4 minutes to read • Edit Online

Pode utilizar numerosas capacidades Azure para implementar bases de dados críticas de missão, como o SAP
HANA em VMs Azure. Este artigo fornece orientações sobre como alcançar a disponibilidade para os casos sap
HANA que estão hospedados em VMs Azure. O artigo descreve vários cenários que pode implementar utilizando a
infraestrutura Azure para aumentar a disponibilidade do SAP HANA em Azure.

Pré-requisitos
Este artigo assume que está familiarizado com as bases de infraestruturas como um serviço (IaaS) básicos em
Azure, incluindo:
Como implantar máquinas virtuais ou redes virtuais através do portal Azure ou PowerShell.
Utilizando a interface de linha de comando de plataforma cruzada Azure (Azure CLI), incluindo a opção de
utilizar os modelos de Notação de Objetos JavaScript (JSON).
Este artigo também assume que está familiarizado com a instalação de instâncias SAP HANA, e com instâncias sap
HANA de administração e operação. É especialmente importante estar familiarizado com a configuração e
operações da replicação do sistema HANA. Isto inclui tarefas como backup e restauro para bases de dados SAP
HANA.
Estes artigos fornecem uma boa visão geral da utilização do SAP HANA em Azure:
Instalação manual de SAP HANA de instância única em VMs Azure
Configurar a replicação do sistema SAP HANA em VMs Azure
Fazer a cópia de segurança das VMs do SAP HANA no Azure
Também é uma boa ideia estar familiarizado com estes artigos sobre o SAP HANA:
Alta disponibilidade para SAP HANA
FAQ: Alta disponibilidade para SAP HANA
Executar a replicação do sistema para SAP HANA
SAP HANA 2.0 SPS 01 O que há de novo: Alta disponibilidade
Recomendações de rede para replicação do sistema SAP HANA
Replicação do sistema SAP HANA
SAP HANA serviço de reinício automático
Configure a replicação do sistema SAP HANA
Além de estar familiarizado com a implementação de VMs em Azure, antes de definir a sua arquitetura de
disponibilidade em Azure, recomendamos que leia Gerir a disponibilidade de máquinas virtuais windows em Azure.

Acordos de nível de serviço para componentes Azure


O Azure tem diferentes SLAs de disponibilidade para diferentes componentes, como networking, armazenamento e
VMs. Todos os SLAs estão documentados. Para mais informações, consulte os Acordos de Nível de Serviço
microsoft Azure.
SLA para Máquinas Virtuais descreve três SLAs diferentes, para três configurações diferentes:
Um único VM que utiliza SSDs premium Azure para o disco OS e todos os discos de dados. Esta opção
proporciona um tempo de uptime mensal de 99,9 por cento.
Múltiplos (pelo menos dois) VMs que são organizados num conjunto de disponibilidade azure. Esta opção
proporciona um tempo de uptime mensal de 99,95 por cento.
Múltiplos (pelo menos dois) VMs que são organizados numa Zona de Availablidade. Esta opção proporcionou
um tempo de uptime mensal de 99,99 por cento.
Meça o seu requisito de disponibilidade contra os SLAs que os componentes Azure podem fornecer. Em seguida,
escolha os seus cenários para o SAP HANA para alcançar o seu nível de disponibilidade exigido.

Passos seguintes
Conheça a disponibilidade do SAP HANA dentro de uma região do Azure.
Conheça a disponibilidade do SAP HANA em todas as regiões de Azure.
Disponibilidade do SAP HANA dentro de uma região
de Azure
29/04/2020 • 22 minutes to read • Edit Online

Este artigo descreve vários cenários de disponibilidade dentro de uma região de Azure. Azure tem muitas regiões,
espalhadas por todo o mundo. Para a lista das regiões de Azure, consulte as regiões de Azure. Para a
implementação de SAP HANA em VMs dentro de uma região do Azure, a Microsoft oferece a implementação de um
único VM com uma instância HANA. Para uma maior disponibilidade, pode implementar dois VMs com duas
instâncias HANA dentro de um conjunto de disponibilidade Azure que utiliza a replicação do sistema HANA para
disponibilidade.
Atualmente, o Azure está a oferecer Zonas de Disponibilidade Azure. Este artigo não descreve em detalhe as Zonas
de Disponibilidade. Mas inclui uma discussão geral sobre a utilização de Conjuntos de Disponibilidade versus Zonas
de Disponibilidade.
As regiões azure onde são oferecidas Zonas de Disponibilidade têm múltiplos datacenters. Os datacenters são
independentes no fornecimento de fonte de energia, arrefecimento e rede. A razão para oferecer diferentes zonas
dentro de uma única região de Azure é implementar aplicações em duas ou três Zonas de Disponibilidade que são
oferecidas. Implantando em zonas, problemas de energia e networking que afetam apenas uma infraestrutura da
Zona de Disponibilidade Azure, a sua implementação de aplicações dentro de uma região do Azure ainda está
funcional. Pode ocorrer alguma capacidade reduzida. Por exemplo, os VMs numa zona podem perder-se, mas os
VMs nas outras duas zonas ainda estariam a funcionar.
Um Conjunto de Disponibilidade Azure é uma capacidade de agrupamento lógica que ajuda a garantir que os
recursos VM que coloca dentro do Conjunto de Disponibilidade são isolados de falhas uns dos outros quando são
implantados dentro de um datacenter Azure. O Azure garante que as VMs que colocar num Conjunto de
Disponibilidade são executadas em vários servidores físicos, suportes de computação, unidades de armazenamento
e comutadores de rede. Em alguma documentação do Azure, esta configuração é referida como colocações em
diferentes domínios de atualização e falhas. Estas colocações geralmente estão dentro de um datacenter Azure.
Assumindo que a fonte de energia e os problemas de rede afetariam o datacenter que está a implantar, toda a sua
capacidade numa região do Azure seria afetada.
A colocação de datacenters que representam as Zonas de Disponibilidade do Azure é um compromisso entre a
prestação de latência aceitável da rede entre serviços implantados em diferentes zonas e uma distância entre
centros de dados. As catástrofes naturais idealmente não afetariam a energia, o fornecimento de rede e a
infraestrutura para todas as Zonas de Disponibilidade desta região. No entanto, como as catástrofes naturais
monumentais têm demonstrado, as Zonas de Disponibilidade podem nem sempre fornecer a disponibilidade que
você deseja dentro de uma região. Pense no furacão Maria que atingiu a ilha de Porto Rico em 20 de setembro de
2017. O furacão causou um apagão de quase 100% na ilha de 150 km de largura.

Cenário de VM único
Num cenário de VM único, cria-se um VM Azure para a instância SAP HANA. Utiliza o Armazenamento Azure
Premium para alojar o disco do sistema operativo e todos os seus discos de dados. O SLA de uptime Azure de 99,9
por cento e os SLAs de outros componentes Azure é suficiente para que você cumpra a sua disponibilidade SLAs
para os seus clientes. Neste cenário, não é necessário alavancar um Conjunto de Disponibilidade Azure para VMs
que executa a camada DBMS. Neste cenário, você confia em duas características diferentes:
Reinício automático Azure VM (também referido como cura de serviço Azure)
Reinício automático SAP HANA
O reinício automático Azure VM, ou a cura do serviço, é uma funcionalidade no Azure que funciona em dois níveis:
O anfitrião do servidor Azure verifica a saúde de um VM que está hospedado no anfitrião do servidor.
O controlador de tecido Azure monitoriza a saúde e disponibilidade do hospedeiro do servidor.
Uma funcionalidade de verificação de saúde monitoriza a saúde de cada VM que está hospedado num hospedeiro
de servidor estoque Azure. Se um VM cair num estado não saudável, um reboot do VM pode ser iniciado pelo
agente hospedeiro Azure que verifica a saúde do VM. O controlador de tecido verifica a saúde do hospedeiro
verificando muitos parâmetros diferentes que podem indicar problemas com o hardware do hospedeiro. Verifica
também a acessibilidade do hospedeiro através da rede. Uma indicação de problemas com o anfitrião pode levar
aos seguintes eventos:
Se o hospedeiro sinalizar um mau estado de saúde, é desencadeado um reinício do hospedeiro e um reinício
dos VMs que estavam a decorrer no hospedeiro.
Se o hospedeiro não estiver em estado saudável após o reboot bem sucedido, é iniciada uma redistribuição dos
VMs que estavam originalmente no nó agora pouco saudável para um servidor hospedeiro saudável. Neste
caso, o hospedeiro original é marcado como não saudável. Não será usado para mais destacamentos até que
seja limpo ou substituído.
Se o hospedeiro não saudável tiver problemas durante o processo de reinicialização, é desencadeado um
reinício imediato dos VMs num hospedeiro saudável.
Com o hospedeiro e a monitorização VM fornecidas pela Azure, os VMs Azure que experimentam problemas de
hospedar são automaticamente reiniciados num anfitrião Azure saudável.

IMPORTANT
A cura do serviço Azure não reiniciará os VMs linux onde o oss o hóspede está em estado de pânico. As definições
predefinidas das versões Linux comumente utilizadas não estão a reiniciar automaticamente Os VMs ou servidor onde o
kernel Linux está em estado de pânico. Em vez disso, o padrão prevê manter o SO em estado de pânico de kernel para ser
capaz de anexar um debugger kernel para analisar. O Azure está a honrar esse comportamento ao não reiniciar
automaticamente um VM com o oss o de hóspedes num tal estado. Supõe-se que tais ocorrências são extremamente raras.
Pode substituir o comportamento predefinido para permitir o reinício do VM. Para alterar o comportamento predefinido, ative
o parâmetro 'kernel.panic' em /etc/sysctl.conf. O tempo definido para este parâmetro é em segundos. Os valores
recomendados comuns devem esperar 20-30 segundos antes de desencadear o reinício através deste parâmetro. Consulte
também https://gitlab.com/procps-ng/procps/blob/master/sysctl.conf.

A segunda funcionalidade em que confia neste cenário é o facto de o serviço HANA que funciona num VM
reiniciado começar automaticamente após o reboot do VM. Pode configurar o reinício automático do serviço HANA
através dos serviços de vigilância dos vários serviços HANA.
Você pode melhorar este cenário de VM único adicionando um nó de falha fria a uma configuração SAP HANA. Na
documentação SAP HANA, esta configuração chama-se auto-failover do anfitrião. Esta configuração pode fazer
sentido numa situação de implementação no local em que o hardware do servidor é limitado, e dedica um nó de
um único servidor como o nó de falha automática do anfitrião para um conjunto de anfitriões de produção. Mas em
Azure, onde a infraestrutura subjacente do Azure fornece um servidor alvo saudável para um recomeço de VM bem
sucedido, não faz sentido implementar o auto-failover do hospedeiro SAP HANA. Devido à cura do serviço Azure,
não há arquitetura de referência que preveja um nó de espera para o anfitrião HANA auto-failover.
Caso especial de configurações de escala SAP HANA em Azure
A elevada disponibilidade para configurações de escala SAP HANA está a depender da cura de serviços dos VMs
Azure e do reinício da instância SAP HANA, uma vez que o VM está a funcionar novamente. Arquiteturas de alta
disponibilidade baseadas na replicação do sistema HANA serão introduzidas mais tarde.

Cenários de disponibilidade para dois VMs diferentes


Se utilizar dois VMs Azure dentro de um Conjunto de Disponibilidade Azure, pode aumentar o tempo de uptime
entre estes dois VMs se forem colocados num Conjunto de Disponibilidade Azure dentro de uma região azure. A
instalação da base em Azure seria como:

Para ilustrar os diferentes cenários de disponibilidade, algumas das camadas do diagrama são omitidas. O
diagrama mostra apenas camadas que retratam VMs, anfitriões, conjuntos de disponibilidade e regiões azure. As
instâncias da Rede Virtual Azure, grupos de recursos e subscrições não desempenham um papel nos cenários
descritos nesta secção.
Replicar backups para uma segunda máquina virtual
Uma das configurações mais rudimentares é usar cópias de segurança. Em particular, pode ter cópias de segurança
de registo de transações enviadas de um VM para outro VM Azure. Pode escolher o tipo de Armazenamento Azure.
Nesta configuração, é responsável por escrever a cópia dos backups programados que são realizados no primeiro
VM para o segundo VM. Se precisar de utilizar as segundas instâncias vm, tem de restaurar as cópias de segurança
completas, incrementais/diferenciais e de registo de transações ao ponto de que necessita.
A arquitetura parece:
Esta configuração não é adequada para alcançar os grandes tempos objetivos do ponto de recuperação (RPO) e do
Objetivo do Tempo de Recuperação (RTO). Os tempos de RTO sofreriam especialmente devido à necessidade de
restaurar totalmente a base de dados completa utilizando as cópias de segurança. No entanto, esta configuração é
útil para recuperar da eliminação não intencional de dados nas instâncias principais. Com esta configuração, a
qualquer momento, pode restaurar a um determinado ponto do tempo, extrair os dados e importar os dados
eliminados para a sua instância principal. Assim, pode fazer sentido usar um método de cópia de cópia de cópia de
cópia em combinação com outras funcionalidades de alta disponibilidade.
Enquanto as cópias de cópias de cópias, poderá utilizar um VM menor do que o VM principal em que a instância
SAP HANA está a decorrer. Tenha em mente que pode anexar um número menor de VHDs a VMs menores. Para
obter informações sobre os limites dos tipos individuais de VM, consulte tamanhos para máquinas virtuais Linux
em Azure.
Replicação do sistema SAP HANA sem falha automática
Os cenários descritos nesta secção utilizam a replicação do sistema SAP HANA. Para a documentação SAP, consulte
a replicação do Sistema. Cenários sem falha automática não são comuns para configurações dentro de uma região
do Azure. Uma configuração sem falha automática, embora evitando uma configuração pacemaker, obriga-o a
monitorizar e falhar manualmente. Uma vez que isto leva e também os esforços, a maioria dos clientes está a
contar com a cura do serviço Azure. Existem alguns casos de vantagem em que esta configuração pode ajudar em
termos de cenários de falha. Ou, em alguns casos, um cliente pode querer perceber mais eficiência.
Replicação do sistema SAP HANA sem falha automática e sem pré-carga de dados
Neste cenário, você usa a replicação do sistema SAP HANA para mover dados de forma sincronizada para obter um
RPO de 0. Por outro lado, tem um RTO suficientemente comprido para não precisar de falhas ou de pré-
carregamento de dados na cache da instância HANA. Neste caso, é possível alcançar uma economia adicional na
sua configuração tomando as seguintes ações:
Executar outra instância SAP HANA no segundo VM. O caso SAP HANA no segundo VM tira a maior parte da
memória da máquina virtual. No caso de uma falha no segundo VM, é necessário desligar a instância SAP HANA
em execução que tem os dados totalmente carregados no segundo VM, para que os dados replicados possam
ser carregados na cache da instância HANA direcionada no segundo VM.
Utilize um tamanho VM menor no segundo VM. Se ocorrer uma falha, terá um passo adicional antes da falha
manual. Neste passo, redimensiona o VM ao tamanho da fonte VM.
O cenário parece:
NOTE
Mesmo que não utilize a pré-carga de dados no alvo de replicação do sistema HANA, precisa de pelo menos 64 GB de
memória. Também precisa de memória suficiente para além de 64 GB para manter os dados da loja na memória da instância
alvo.

Replicação do sistema SAP HANA sem falha automática e com pré-carga de dados
Neste cenário, os dados que são replicados para a instância HANA no segundo VM estão pré-carregados. Isto
elimina as duas vantagens de não pré-carregar dados. Neste caso, não pode executar outro sistema SAP HANA no
segundo VM. Também não pode usar um tamanho VM menor. Assim, os clientes raramente implementam este
cenário.
Replicação do sistema SAP HANA com falha automática
Na configuração padrão e mais comum de disponibilidade dentro de uma região de Azure, dois VMs Azure que
executam SLES Linux têm um cluster de failover definido. O cluster SLES Linux baseia-se na estrutura do Pacemaker,
em conjunto com um dispositivo STONITH.
Do ponto de vista do SAP HANA, o modo de replicação que é usado é sincronizado e uma falha automática é
configurada. Na segunda VM, o caso SAP HANA atua como um nó de espera quente. O nó de espera recebe um
fluxo sincronizado de registos de mudança saindo da instância principal sAP HANA. Como as transações são
cometidas pelo pedido no nó primário hana, o nó principal HANA aguarda para confirmar o compromisso com o
pedido até que o nó secundário SAP HANA confirme que recebeu o registo de compromisso. O SAP HANA oferece
dois modos de replicação sincronizados. Para mais detalhes e para uma descrição das diferenças entre estes dois
modos de replicação sincronizados, consulte os modos de replicação do artigo SAP para a replicação do sistema
SAP HANA.
A configuração geral parece:
Pode escolher esta solução porque lhe permite obter um RPO=0 e um RTO baixo. Configure a conectividade do
cliente SAP HANA para que os clientes SAP HANA utilizem o endereço IP virtual para se ligarem à configuração de
replicação do sistema HANA. Tal configuração elimina a necessidade de reconfigurar a aplicação se ocorrer uma
falha no nó secundário. Neste cenário, as SKUs VM Azure para as VMprimárias e Secundárias devem ser as
mesmas.

Passos seguintes
Para obter orientações passo a passo sobre a configuração destas configurações em Azure, consulte:
Configurar a replicação do sistema SAP HANA em VMs Azure
Alta disponibilidade para SAP HANA utilizando replicação do sistema
Para mais informações sobre a disponibilidade do SAP HANA em todas as regiões de Azure, consulte:
Disponibilidade do SAP HANA nas regiões de Azure
Disponibilidade do SAP HANA nas regiões de Azure
28/04/2020 • 12 minutes to read • Edit Online

Este artigo descreve cenários relacionados com a disponibilidade do SAP HANA em diferentes regiões do Azure.
Devido à distância entre as regiões de Azure, a criação da disponibilidade do SAP HANA em várias regiões de Azure
envolve considerações especiais.

Por que implantar em várias regiões azure


As regiões de Azure são frequentemente separadas por grandes distâncias. Dependendo da região geopolítica, a
distância entre as regiões de Azure pode ser de centenas de milhas, ou mesmo de milhares de milhas, como nos
Estados Unidos. Devido à distância, o tráfego de rede entre os ativos que são implantados em duas regiões
diferentes do Azure experimentam uma latência significativa de ida e volta em rede. A latência é significativa o
suficiente para excluir a troca de dados sincronizada entre duas instâncias SAP HANA sob cargas de trabalho típicas
do SAP.
Por outro lado, as organizações têm frequentemente um requisito de distância entre a localização do centro de
dados primário e um centro de dados secundário. Um requisito de distância ajuda a fornecer disponibilidade se
uma catástrofe natural ocorrer em uma localização geográfica mais ampla. Exemplos incluem os furacões que
atingiram as Caraíbas e a Florida em setembro e outubro de 2017. A sua organização pode ter pelo menos um
requisito mínimo de distância. Para a maioria dos clientes Azure, uma definição de distância mínima requer que
você desenhe para disponibilidade em todas as regiões de Azure. Como a distância entre duas regiões azure é
demasiado grande para usar o modo de replicação sincronizada HANA, os requisitos de RTO e RPO podem forçá-lo
a implementar configurações de disponibilidade numa região, e depois complementar com implantações adicionais
numa segunda região.
Outro aspeto a ter em conta neste cenário é o failover e o redirecionamento do cliente. O pressuposto é que uma
falha entre os casos do SAP HANA em duas regiões azure diferentes é sempre uma falha manual. Como o modo de
replicação da replicação do sistema SAP HANA está definido como assíncrono, há um potencial que os dados
cometidos na instância primária de HANA ainda não chegaram à instância secundária de HANA. Portanto, a falha
automática não é uma opção para configurações onde a replicação é assíncrona. Mesmo com uma falha controlada
manualmente, como num exercício de failover, é necessário tomar medidas para garantir que todos os dados
comprometidos do lado primário chegaram à instância secundária antes de se deslocar manualmente para a outra
região do Azure.
A Rede Virtual Azure utiliza uma gama de endereços IP diferente. Os endereços IP são implantados na segunda
região de Azure. Por isso, ou precisa de alterar a configuração do cliente SAP HANA, ou de preferência, precisa de
criar passos para alterar a resolução de nomes. Desta forma, os clientes são redirecionados para o endereço IP do
novo site secundário. Para mais informações, consulte o artigo SAP recuperação de ligação ao cliente após
aquisição.

Disponibilidade simples entre duas regiões azure


Você pode optar por não colocar qualquer configuração de disponibilidade em lugar dentro de uma única região,
mas ainda tem a exigência de ter a carga de trabalho servida se um desastre ocorrer. Casos típicos para tais
cenários são sistemas de não produção. Embora ter o sistema para baixo durante meio dia ou mesmo um dia seja
sustentável, não pode permitir que o sistema esteja indisponível por 48 horas ou mais. Para tornar a configuração
menos dispendiosa, gerenum outro sistema que seja ainda menos importante no VM. O outro sistema funciona
como um destino. Também pode dimensionar o VM na região secundária para ser menor, e optar por não pré-
carregar os dados. Como a falha é manual e implica muitos mais passos para falhar sobre a pilha completa de
aplicações, o tempo adicional para desligar o VM, redimensioná-lo e, em seguida, reiniciar o VM é aceitável.
Se estiver a usar o cenário de partilhar o alvo DR com um sistema QA num VM, tem de ter em conta estas
considerações:
Existem dois modos de funcionamento com delta_datashipping e logreplay, que estão disponíveis para tal
cenário
Ambos os modos de funcionamento têm diferentes requisitos de memória sem dados de pré-carregamento
Delta_datashipping pode exigir uma memória drasticamente menor sem a opção de pré-carga do que a
repetição de logreplay poderia exigir. Ver capítulo 4.3 do documento SAP Como Executar Replicação do Sistema
para SAP HANA
O requisito de memória do modo de funcionamento da reprodução de logreplay sem pré-carga não é
determinístico e depende das estruturas de loja de colunas carregadas. Em casos extremos, pode exigir 50% da
memória da instância primária. A memória do modo de funcionamento de reprodução de logreplay é
independente sobre se optou por ter ou não os dados pré-carregados.

NOTE
Nesta configuração, não é possível fornecer um RPO=0 porque o seu modo de replicação do sistema HANA é assíncrono. Se
precisar de fornecer um RPO=0, esta configuração não é a configuração de escolha.

Uma pequena alteração que pode fazer na configuração pode ser configurar dados como pré-carregamento. No
entanto, dada a natureza manual da falha e o facto de as camadas de aplicação também precisarem de se deslocar
para a segunda região, pode não fazer sentido pré-carregar dados.

Combine disponibilidade numa região e em todas as regiões


Uma combinação de disponibilidade dentro e em todas as regiões pode ser impulsionada por estes fatores:
Uma exigência de RPO=0 dentro de uma região de Azure.
A organização não está disposta ou capaz de ter operações globais afetadas por uma grande catástrofe natural
que afeta uma região maior. Foi o caso de alguns furacões que atingiram as Caraíbas nos últimos anos.
Regulamentos que exigem distâncias entre locais primários e secundários que estão claramente para além do
que as zonas de disponibilidade do Azure podem fornecer.
Nestes casos, pode configurar o que o SAP chama de uma configuração de replicação multimais do sistema SAP
HANA utilizando a replicação do sistema HANA. A arquitetura seria como:

O SAP introduziu a replicação do sistema multi-alvo com HANA 2.0 SPS3. A replicação do sistema multi-alvo traz
algumas vantagens em cenários de atualização. Por exemplo, o sítio DR (Região 2) não é afetado quando o local
secundário de HA está em baixo para manutenção ou atualizações. Pode saber mais sobre a replicação do sistema
multi-alvo DA HANA aqui. Uma possível arquitetura com replicação multi-alvo seria como:

Se a organização tiver requisitos para uma prontidão de elevada disponibilidade na segunda região (DR) Azure,
então a arquitetura seria como:
Utilizando a repetição de logreplay como modo de funcionamento, esta configuração fornece um RPO=0, com RTO
baixo, dentro da região primária. A configuração também fornece RPO decente se uma mudança para a segunda
região estiver envolvida. Os tempos de RTO na segunda região dependem da pré-carga dos dados. Muitos clientes
usam o VM na região secundária para executar um sistema de teste. Nesse caso, os dados não podem ser pré-
carregados.

IMPORTANT
Os modos de funcionamento entre os diferentes níveis têm de ser homogéneos. Não é possível utilizar o logreply como
modo de funcionamento entre o nível 1 e o nível 2 e delta_datashipping para fornecer o nível 3. Só é possível escolher o
modo de funcionamento de um ou outro modo de funcionamento que tem de ser consistente para todos os níveis. Uma vez
que delta_datashipping não é adequado para lhe dar um RPO=0, o único modo de funcionamento razoável para uma
configuração de vários níveis permanece a repetição de logreplay. Para mais detalhes sobre os modos de funcionamento e
algumas restrições, consulte os modos de funcionamento do artigo SAP HANA para a replicação do sistema SAP HANA.

Passos seguintes
Para obter orientações passo a passo sobre a configuração destas configurações em Azure, consulte:
Configurar a replicação do sistema SAP HANA em VMs Azure
Alta disponibilidade para SAP HANA utilizando replicação do sistema
Alta disponibilidade de SAP HANA em VMs Azure
no SUSE Linux Enterprise Server
13/05/2020 • 56 minutes to read • Edit Online

Para o desenvolvimento no local, pode utilizar a Replicação do Sistema HANA ou utilizar o armazenamento
partilhado para estabelecer uma elevada disponibilidade para o SAP HANA. Nas máquinas virtuais Azure
(VMs), a replicação do sistema HANA no Azure é atualmente a única função de alta disponibilidade
suportada. A replicação do SAP HANA consiste num nó primário e pelo menos num nó secundário. As
alterações aos dados do nó primário são replicadas ao nó secundário sincronicamente ou assíncronamente.
Este artigo descreve como implementar e configurar as máquinas virtuais, instalar a estrutura do cluster e
instalar e configurar a Replicação do Sistema SAP HANA. Nas configurações de exemplo, são utilizados
comandos de instalação, instância número 03 e ID HN1 do sistema HANA.
Leia primeiro as seguintes Notas e papéis SAP:
Nota SAP [1928533,]que tem:
A lista dos tamanhos de VM Azure que são suportados para a implementação de software SAP.
Informações importantes sobre a capacidade para tamanhos de VM Azure.
O software SAP suportado e o sistema operativo (OS) e as combinações de bases de dados.
A versão necessária para o kernel SAP necessário para Windows e Linux no Microsoft Azure.
O SAP Note 2015553 lista os pré-requisitos para implementações de software SAP suportadas pelo SAP
em Azure.
O SAP Note 2205917 recomendou as definições de OS para o Servidor Empresarial SUSE Linux para
aplicações SAP.
SAP Nota 1944799 tem Diretrizes SAP HANA para SUSE Linux Enterprise Server para Aplicações SAP.
O SAP Note 2178632 tem informações detalhadas sobre todas as métricas de monitorização que são
reportadas para o SAP em Azure.
O SAP Note 2191498 tem a versão necessária do Agente anfitrião SAP para o Linux em Azure.
SAP Nota 2243692 tem informações sobre licenciamento SAP em Linux em Azure.
SAP Note 1984787 tem informações gerais sobre o SUSE Linux Enterprise Server 12.
A Nota [SAP 1999351] tem informações adicionais de resolução de problemas para a extensão de
monitorização avançada do Azure para sAP.
O SAP Note 401162 tem informações sobre como evitar "endereço já em uso" ao configurar a Replicação
do Sistema HANA.
A SAP Community WIKI tem todas as notas SAP necessárias para linux.
Plataformas IaaS Certificadas SAP HANA
Planeamento e implementação de Máquinas Virtuais Azure para SAP no guia Linux.
Implantação de Máquinas Virtuais Azure para SAP em Linux (este artigo).
Implantação DE DBMS de Máquinas Virtuais Azure para SAP no guia Linux.
SUSE Linux Enterprise Server para Aplicações SAP 12 Guias de boas práticas SP3
Criação de uma Infraestrutura Otimizada de Desempenho SAP HANA SR (SLES para Aplicações
SAP 12 SP1). O guia contém todas as informações necessárias para configurar a replicação do
sistema SAP HANA para o desenvolvimento no local. Utilize este guia como base.
Criação de uma Infraestrutura Otimizada de Custos SAP HANA SR (SLES para Aplicações SAP 12
SP1)
Descrição geral
Para obter uma elevada disponibilidade, o SAP HANA está instalado em duas máquinas virtuais. Os dados
são replicados utilizando a replicação do sistema HANA.

A configuração de replicação do sistema SAP HANA utiliza um nome de anfitrião virtual dedicado e
endereços IP virtuais. No Azure, é necessário utilizar um endereço IP virtual. A lista que se segue mostra a
configuração do equilibrista de carga:
Configuração frontal: Endereço IP 10.0.0.13 para hn1-db
Configuração de back-end: Ligada às interfaces de rede primária de todas as máquinas virtuais que
devem fazer parte da Replicação do Sistema HANA
Porta da sonda: Porto 62503
Regras de equilíbrio de carga: 30313 TCP, 30315 TCP, 30317 TCP

Implantação para Linux


O agente de recursos para o SAP HANA está incluído no SUSE Linux Enterprise Server para aplicações SAP. O
Azure Marketplace contém uma imagem para o SUSE Linux Enterprise Server para aplicações SAP 12 que
pode utilizar para implementar novas máquinas virtuais.
Implementar com um modelo
Você pode usar um dos modelos de arranque rápido que estão no GitHub para implementar todos os
recursos necessários. O modelo implanta as máquinas virtuais, o equilibrador de carga, o conjunto de
disponibilidade, e assim por diante. Para implementar o modelo, siga estes passos:
1. Abra o modelo de base de dados ou o modelo convergente no portal Azure. O modelo de base de
dados cria as regras de equilíbrio de carga apenas para uma base de dados. O modelo convergente
também cria as regras de equilíbrio de carga para uma instância ASCS/SCS e ERS (apenas Linux). Se
planeia instalar um sistema baseado em SAP NetWeaver e pretende instalar a instância ASCS/SCS nas
mesmas máquinas, utilize o modelo convergente.
2. Introduza os seguintes parâmetros:
ID do sistema Sap : Introduza o ID do sistema SAP do sistema SAP que pretende instalar. O ID é
usado como prefixo para os recursos que são implantados.
Tipo de pilha:(Este parâmetro só é aplicável se utilizar o modelo convergente.) Selecione o tipo de
pilha SAP NetWeaver.
Tipo Os : Selecione uma das distribuições linux. Para este exemplo, selecione SLES 12 .
Tipo db : Selecione HANA .
Tamanho do sistema sap : Introduza o número de SAPS que o novo sistema vai fornecer. Se não
tem a certeza de quantos SAPS o sistema necessita, pergunte ao seu Parceiro de Tecnologia SAP ou
ao Integrador de Sistemas.
Disponibilidade do Sistema : Selecione HA .
Nome de utilizador e senha de administrador : É criado um novo utilizador que pode ser utilizado
para iniciar sessão na máquina.
Subnet nova ou existente : Determina se deve ser criada uma nova rede virtual e uma sub-rede
ou uma sub-rede existente. Se já tiver uma rede virtual ligada à sua rede no local, selecione
Existino .
ID sub-rede : Se pretender implantar o VM numa VNet existente onde tenha uma sub-rede
definida a VM deve ser atribuída, diga o nome da identificação dessa sub-rede específica. O ID
geralmente se parece com /subscrições/ < ID de subscrição>/recursosGroups/ nome de <
grupo de recursos>/fornecedores/Microsoft.Network/vir tualNetworks/ nome de <
rede vir tual>/subnets/ nome de < sub-rede> .
Implementação manual

IMPORTANT
Certifique-se de que o SISTEMA selecionado é certificado sAP para SAP HANA nos tipos de VM específicos que está a
utilizar. A lista dos tipos vM certificados sAP HANA e os lançamentos de SOs para aqueles podem ser analisados nas
Plataformas IaaS Certificadas SAP HANA. Certifique-se de clicar nos detalhes do tipo VM listado para obter a lista
completa de lançamentos sap HANA suportados para o tipo de VM específico

1. Crie um grupo de recursos.


2. Crie uma rede virtual
3. Crie um conjunto de disponibilidade.
Detete o domínio da atualização máxima.
4. Criar um equilibrador de carga (interno). Recomendamos um equilíbrio de carga padrão.
Selecione a rede virtual criada no passo 2.
5. Criar a máquina virtual 1.
Utilize uma imagem SLES4SAP na galeria Azure que é suportada para SAP HANA no tipo VM que
selecionou.
Selecione o conjunto de disponibilidade criado no passo 3.
6. Criar a máquina virtual 2.
Utilize uma imagem SLES4SAP na galeria Azure que é suportada para SAP HANA no tipo VM que
selecionou.
Selecione o conjunto de disponibilidade criado no passo 3.
7. Adicione discos de dados.
8. Se utilizar um equilibrador de carga padrão, siga estes passos de configuração:
a. Primeiro, crie uma piscina IP frontal:
a. Abra o equilibrador de carga, selecione pool IP frontend, e selecione Adicionar .
b. Introduza o nome da nova piscina IP frontal (por exemplo, hana-frontend).
c. Defino a Atribuição à Estática e introduza o endereço IP (por exemplo, 10.0.0.13 ).
d. Selecione OK .
e. Depois de criado o novo pool IP frontal, note o endereço IP do pool.
b. Em seguida, crie uma piscina de back-end:
a. Abra o equilibrador de carga, selecione piscinas de backend, e selecione Adicionar .
b. Introduza o nome da nova piscina traseira (por exemplo, hana-backend).
c. Selecione Rede Vir tual .
d. Selecione Adicionar uma máquina vir tual .
e. Selecione ** Máquina virtual**.
f. Selecione as máquinas virtuais do cluster SAP HANA e os seus endereços IP.
g. Selecione Adicionar .
c. Em seguida, crie uma sonda de saúde:
a. Abra o equilibrador de carga, selecione sondas de saúde, e selecione Adicionar .
b. Introduza o nome da nova sonda de saúde (por exemplo, hana-hp).
c. Selecione TCP como protocolo e porta 62503 . Mantenha o valor de inter valo definido
para 5 e o valor limiar não saudável definido para 2.
d. Selecione OK .
d. Em seguida, crie as regras de equilíbrio de carga:
a. Abra o equilibrador de carga, selecione regras de equilíbrio de carga, e selecione
Adicionar .
b. Introduza o nome da nova regra do equilibrador de carga (por exemplo, hana-lb ).
c. Selecione o endereço IP frontal, a piscina traseira e a sonda de saúde que criou
anteriormente (por exemplo, hana-frontend, hana-backend e hana-hp).
d. Selecione Por tas HA .
e. Aumente o tempo de inatividade para 30 minutos.
f. Certifique-se de ativar o IP flutuante .
g. Selecione OK .

NOTE
Quando os VMs sem endereços IP públicos forem colocados no conjunto de backend do interno (sem
endereço IP público) O equilíbrio de carga Standard Azure não haverá conectividade de saída na Internet, a
menos que seja realizada uma configuração adicional para permitir o encaminhamento para pontos finais
públicos. Para mais detalhes sobre como alcançar a conectividade de saída, consulte a conectividade do ponto
final público para máquinas virtuais utilizando o Equilíbrio de Carga Padrão Azure em cenários de alta
disponibilidade SAP.

9. Alternativamente, se o seu cenário ditar a utilização de um equilíbrio básico de carga, siga estes
passos de configuração:
a. Primeiro, crie uma piscina IP frontal:
a. Abra o equilibrador de carga, selecione pool IP frontend, e selecione Adicionar .
b. Introduza o nome da nova piscina IP frontal (por exemplo, hana-frontend).
c. Defino a Atribuição à Estática e introduza o endereço IP (por exemplo, 10.0.0.13 ).
d. Selecione OK .
e. Depois de criado o novo pool IP frontal, note o endereço IP do pool.
b. Em seguida, crie uma piscina de back-end:
a. Abra o equilibrador de carga, selecione piscinas de backend, e selecione Adicionar .
b. Introduza o nome da nova piscina traseira (por exemplo, hana-backend).
c. Selecione Adicionar uma máquina vir tual .
d. Selecione o conjunto de disponibilidade criado no passo 3.
e. Selecione as máquinas virtuais do cluster SAP HANA.
f. Selecione OK .
c. Em seguida, crie uma sonda de saúde:
a. Abra o equilibrador de carga, selecione sondas de saúde, e selecione Adicionar .
b. Introduza o nome da nova sonda de saúde (por exemplo, hana-hp).
c. Selecione TCP como protocolo e porta 62503 . Mantenha o valor de inter valo definido
para 5 e o valor limiar não saudável definido para 2.
d. Selecione OK .
d. Para o SAP HANA 1.0, crie as regras de equilíbrio de carga:
a. Abra o equilibrador de carga, selecione regras de equilíbrio de carga, e selecione
Adicionar .
b. Introduza o nome da nova regra do equilibrador de carga (por exemplo, hana-lb-303 15).
c. Selecione o endereço IP frontal, a piscina traseira e a sonda de saúde que criou
anteriormente (por exemplo, hana-frontend ).
d. Mantenha o Protocolo definido para a TCP e entre na porta 303 15.
e. Aumente o tempo de inatividade para 30 minutos.
f. Certifique-se de ativar o IP flutuante .
g. Selecione OK .
h. Repita estes passos para a porta 303 17.
e. Para o SAP HANA 2.0, crie as regras de equilíbrio de carga para a base de dados do sistema:
a. Abra o equilibrador de carga, selecione regras de equilíbrio de carga, e selecione
Adicionar .
b. Introduza o nome da nova regra do equilibrador de carga (por exemplo, hana-lb-303 13).
c. Selecione o endereço IP frontal, a piscina traseira e a sonda de saúde que criou
anteriormente (por exemplo, hana-frontend ).
d. Mantenha o Protocolo definido para a TCP e entre na porta 303 13.
e. Aumente o tempo de inatividade para 30 minutos.
f. Certifique-se de ativar o IP flutuante .
g. Selecione OK .
h. Repita estes passos para a porta 303 14.
f. Para o SAP HANA 2.0, crie primeiro as regras de equilíbrio de carga para a base de dados dos
inquilinos:
a. Abra o equilibrador de carga, selecione regras de equilíbrio de carga, e selecione
Adicionar .
b. Introduza o nome da nova regra do equilibrador de carga (por exemplo, hana-lb-303 40).
c. Selecione o endereço IP frontal, a piscina de backend e a sonda de saúde que criou
anteriormente (por exemplo, hana-frontend ).
d. Mantenha o Protocolo definido para a TCP e entre na porta 303 40.
e. Aumente o tempo de inatividade para 30 minutos.
f. Certifique-se de ativar o IP flutuante .
g. Selecione OK .
h. Repita estes passos para as portas 303 41 e 303 42.
Para obter mais informações sobre as portas necessárias para o SAP HANA, leia o capítulo Ligações às
Bases de Dados de Inquilinos no guia SAP HANA Tenant Databases ou SAP Nota 2388694.

IMPORTANT
Não permita os carimbos de tempo da TCP em VMs Azure colocados atrás do Equilíbrio de Carga Azure. Permitir os
selos temporais da TCP fará com que as sondas de saúde falhem. Definir parâmetro net.ipv4.tcp_timestamps a 0 .
Para mais detalhes consulte as sondas de saúde load Balancer. Consulte também a nota SAP 2382421.

Criar um cluster Pacemaker


Siga os passos na configuração do Pacemaker no SUSE Linux Enterprise Server em Azure para criar um
cluster pacemaker básico para este servidor HANA. Pode utilizar o mesmo cluster Pacemaker para SAP HANA
e SAP NetWeaver (A)SCS.

Instalar o SAP HANA


Os passos nesta secção utilizam os seguintes prefixos:
[A] : O passo aplica-se a todos os nós.
[1] : O passo aplica-se apenas ao nó 1.
[2] : O passo aplica-se apenas ao nó 2 do cluster Pacemaker.
1. [A] Configurar o layout do disco: Logical Volume Manager (LVM) .
Recomendamos que utilize o LVM para volumes que armazenem dados e ficheiros de registo. O
exemplo seguinte pressupõe que as máquinas virtuais têm quatro discos de dados ligados que são
usados para criar dois volumes.
Enumerar todos os discos disponíveis:

ls /dev/disk/azure/scsi1/lun*

Exemplo de saída:

/dev/disk/azure/scsi1/lun0 /dev/disk/azure/scsi1/lun1 /dev/disk/azure/scsi1/lun2


/dev/disk/azure/scsi1/lun3

Crie volumes físicos para todos os discos que pretende utilizar:

sudo pvcreate /dev/disk/azure/scsi1/lun0


sudo pvcreate /dev/disk/azure/scsi1/lun1
sudo pvcreate /dev/disk/azure/scsi1/lun2
sudo pvcreate /dev/disk/azure/scsi1/lun3

Crie um grupo de volume para os ficheiros de dados. Utilize um grupo de volume para os ficheiros de
registo e um para o diretório partilhado do SAP HANA:
sudo vgcreate vg_hana_data_HN1 /dev/disk/azure/scsi1/lun0 /dev/disk/azure/scsi1/lun1
sudo vgcreate vg_hana_log_HN1 /dev/disk/azure/scsi1/lun2
sudo vgcreate vg_hana_shared_HN1 /dev/disk/azure/scsi1/lun3

Criar os volumes lógicos. Um volume linear é criado quando se utiliza lvcreate sem o -i
interruptor. Sugerimos que crie um volume listrado para um melhor desempenho em I/S e alinhe os
tamanhos das riscas com os valores documentados nas configurações de armazenamento VM SAP
HANA. O -i argumento deve ser o número dos volumes físicos subjacentes e o argumento é o
tamanho das -I riscas. Neste documento, são utilizados dois volumes físicos para o volume de
dados, pelo que o argumento da -i comutação está definido para 2 . O tamanho das riscas para o
volume de dados é de 256KiB . Um volume físico é utilizado para o volume de registo, pelo que
nenhum -i ou -I interruptor é explicitamente utilizado para os comandos de volume de registo.

IMPORTANT
Utilize o -i interruptor e detetetete-o para o número do volume físico subjacente quando utilizar mais de
um volume físico para cada dados, registo ou volumes partilhados. Utilize o -I interruptor para especificar o
tamanho das riscas, quando criar um volume listrado.
Consulte as configurações de armazenamento VM SAP HANA para configurações de armazenamento
recomendadas, incluindo tamanhos de listras e número de discos.

sudo lvcreate -i 2 -I 256 -l 100%FREE -n hana_data vg_hana_data_HN1


sudo lvcreate -l 100%FREE -n hana_log vg_hana_log_HN1
sudo lvcreate -l 100%FREE -n hana_shared vg_hana_shared_HN1
sudo mkfs.xfs /dev/vg_hana_data_HN1/hana_data
sudo mkfs.xfs /dev/vg_hana_log_HN1/hana_log
sudo mkfs.xfs /dev/vg_hana_shared_HN1/hana_shared

Crie os diretórios de montagem e copie o UUID de todos os volumes lógicos:

sudo mkdir -p /hana/data/HN1


sudo mkdir -p /hana/log/HN1
sudo mkdir -p /hana/shared/HN1
# Write down the ID of /dev/vg_hana_data_HN1/hana_data, /dev/vg_hana_log_HN1/hana_log, and
/dev/vg_hana_shared_HN1/hana_shared
sudo blkid

Criar fstab entradas para os três volumes lógicos:

sudo vi /etc/fstab

Insira a seguinte linha no /etc/fstab ficheiro:

/dev/disk/by-uuid/<UUID of /dev/mapper/vg_hana_data_HN1-hana_data> /hana/data/HN1 xfs


defaults,nofail 0 2
/dev/disk/by-uuid/<UUID of /dev/mapper/vg_hana_log_HN1-hana_log> /hana/log/HN1 xfs
defaults,nofail 0 2
/dev/disk/by-uuid/<UUID of /dev/mapper/vg_hana_shared_HN1-hana_shared> /hana/shared/HN1 xfs
defaults,nofail 0 2

Monte os novos volumes:


sudo mount -a

2. [A] Configurar o layout do disco: Discos simples .


Para sistemas de demonstração, pode colocar os seus dados HANA e ficheiros de registo num disco.
Criar uma partição em /dev/disk/azure/scsi1/lun0 e forme-a com xfs:

sudo sh -c 'echo -e "n\n\n\n\n\nw\n" | fdisk /dev/disk/azure/scsi1/lun0'


sudo mkfs.xfs /dev/disk/azure/scsi1/lun0-part1

# Write down the ID of /dev/disk/azure/scsi1/lun0-part1


sudo /sbin/blkid
sudo vi /etc/fstab

Insira esta linha no ficheiro /etc/fstab:

/dev/disk/by-uuid/<UUID> /hana xfs defaults,nofail 0 2

Crie o diretório-alvo e monte o disco:

sudo mkdir /hana


sudo mount -a

3. [A] Configurar a resolução de nomes de anfitrião para todos os anfitriões.


Pode utilizar um servidor DNS ou modificar o ficheiro /etc/anfitriões em todos os nós. Este exemplo
mostra-lhe como usar o ficheiro /etc/anfitriões. Substitua o endereço IP e o nome de anfitrião nos
seguintes comandos:

sudo vi /etc/hosts

Insira as seguintes linhas no ficheiro /etc/anfitriões. Altere o endereço IP e o nome de anfitrião para
combinar com o seu ambiente:

10.0.0.5 hn1-db-0
10.0.0.6 hn1-db-1

4. [A] Instale os pacotes de alta disponibilidade SAP HANA:

sudo zypper install SAPHanaSR

Para instalar a Replicação do Sistema SAP HANA, siga o capítulo 4 do guia de cenário otimizado de
desempenho SAP HANA SR.
1. [A] Executar o programa hdblcm do DVD HANA. Introduza os seguintes valores no momento:
Escolha a instalação: Insira 1 .
Selecione componentes adicionais para instalação: Insira 1 .
Introduza o Caminho de Instalação [/hana/partilhado]: Selecione Entrar.
Introduza o nome do anfitrião local [..]: Selecione Entrar.
Deseja adicionar mais anfitriões ao sistema? (y/n) [n]: Selecione Entrar.
Introduza o ID do sistema SAP HANA: Introduza o SID de HANA, por exemplo: HN1 .
Insira o número da instância [00]: Introduza o número da instância HANA. Introduza 03 se usou o
modelo Azure ou seguiu a secção de implantação manual deste artigo.
Selecione Modo base de dados / Introduza o Índice [1]: Selecione Introduzir.
Selecione a utilização do sistema / Insira o Índice [4]: Selecione o valor de utilização do sistema.
Introduza a localização dos volumes de dados [/hana/data/HN1]: Selecione Entrar.
Introduza a localização dos volumes de registo [/hana/log/HN1]: Selecione Entrar.
Restringir a atribuição máxima de memória? [n]: Selecione Entrar.
Insira o nome do anfitrião do certificado para o anfitrião '...' [...]: Selecione Entrar.
Introduza o Utilizador do Agente anfitrião SAP (sapadm) Palavra-passe: Introduza a palavra-passe
do utilizador do agente anfitrião.
Confirme o Utilizador do Agente anfitrião SAP (sapadm) Palavra-passe: Introduza novamente a
palavra-passe do utilizador do agente anfitrião para confirmar.
Introduza o Administrador do Sistema (hdbadm) Palavra-passe: Introduza a palavra-passe do
administrador do sistema.
Confirmar Administrador do Sistema (hdbadm) Palavra-passe: Introduza novamente a palavra-
passe do administrador do sistema para confirmar.
Insira o Diretório Inicial do Administrador do Sistema [/usr/sap/HN1/home]: Selecione Entrar.
Introduza a concha de login do administrador do sistema [/bin/sh]: Selecione Entrar.
Introduza o ID do utilizador do administrador do sistema [1001]: Selecione Entrar.
Introduza id do Grupo utilizador (sapsys) [79]: Selecione Entrar.
Introduza a palavra-passe do utilizador (SISTEMA) da base de dados: Introduza a palavra-passe do
utilizador da base de dados.
Confirmar Palavra-passe do Utilizador da Base de Dados (SISTEMA): Introduza novamente a
palavra-passe do utilizador da base de dados para confirmar.
Reiniciar o sistema após a reinicialização da máquina? [n]: Selecione Entrar.
Quer continuar? (y/n): Validar o resumo. Insira y para continuar.
2. [A] Atualizar o Agente Hospedeiro SAP.
Descarregue o mais recente arquivo do Agente Anfitrião SAP do Centro de Software SAP e execute o
seguinte comando para atualizar o agente. Substitua o caminho para o arquivo para apontar para o
ficheiro que descarregou:

sudo /usr/sap/hostctrl/exe/saphostexec -upgrade -archive <path to SAP Host Agent SAR>

Configure A Replicação do Sistema SAP HANA 2.0


Os passos nesta secção utilizam os seguintes prefixos:
[A] : O passo aplica-se a todos os nós.
[1] : O passo aplica-se apenas ao nó 1.
[2] : O passo aplica-se apenas ao nó 2 do cluster Pacemaker.
1. [1] Criar a base de dados dos inquilinos.
Se estiver a utilizar o SAP HANA 2.0 ou o MDC, crie uma base de dados de inquilinos para o seu
sistema SAP NetWeaver. Substitua o NW1 pelo SID do seu sistema SAP.
Execute o seguinte comando como <> hanasid adm:
hdbsql -u SYSTEM -p "passwd" -i 03 -d SYSTEMDB 'CREATE DATABASE NW1 SYSTEM USER PASSWORD "passwd"'

2. [1] Configurar a replicação do sistema no primeiro nó:


Volte a fazer as bases de dados como <> hanasid adm:

hdbsql -d SYSTEMDB -u SYSTEM -p "passwd" -i 03 "BACKUP DATA USING FILE ('initialbackupSYS')"


hdbsql -d HN1 -u SYSTEM -p "passwd" -i 03 "BACKUP DATA USING FILE ('initialbackupHN1')"
hdbsql -d NW1 -u SYSTEM -p "passwd" -i 03 "BACKUP DATA USING FILE ('initialbackupNW1')"

Copie os ficheiros PKI do sistema para o local secundário:

scp /usr/sap/HN1/SYS/global/security/rsecssfs/data/SSFS_HN1.DAT hn1-db-


1:/usr/sap/HN1/SYS/global/security/rsecssfs/data/
scp /usr/sap/HN1/SYS/global/security/rsecssfs/key/SSFS_HN1.KEY hn1-db-
1:/usr/sap/HN1/SYS/global/security/rsecssfs/key/

Criar o local principal:

hdbnsutil -sr_enable --name=SITE1

3. [2] Configurar a replicação do sistema no segundo nó:


Registe o segundo nó para iniciar a replicação do sistema. Executar o seguinte comando como
<hanasid > adm:

sapcontrol -nr 03 -function StopWait 600 10


hdbnsutil -sr_register --remoteHost=hn1-db-0 --remoteInstance=03 --replicationMode=sync --
name=SITE2

Configure A Replicação do Sistema SAP HANA 1.0


Os passos nesta secção utilizam os seguintes prefixos:
[A] : O passo aplica-se a todos os nós.
[1] : O passo aplica-se apenas ao nó 1.
[2] : O passo aplica-se apenas ao nó 2 do cluster Pacemaker.
1. [1] Criar os utilizadores necessários.
Executar o seguinte comando como raiz. Certifique-se de substituir as cordas arrojadas (HANA System
ID HN1 e a instância número 03 ) com os valores da sua instalação SAP HANA:

PATH="$PATH:/usr/sap/HN1/HDB03/exe"
hdbsql -u system -i 03 'CREATE USER hdbhasync PASSWORD "passwd"'
hdbsql -u system -i 03 'GRANT DATA ADMIN TO hdbhasync'
hdbsql -u system -i 03 'ALTER USER hdbhasync DISABLE PASSWORD LIFETIME'

2. [A] Criar a entrada na loja de chaves.


Executar o seguinte comando como raiz para criar uma nova entrada na keystore:
PATH="$PATH:/usr/sap/HN1/HDB03/exe"
hdbuserstore SET hdbhaloc localhost:30315 hdbhasync passwd

3. [1] Volte a subir na base de dados.


Volte a fazer as bases de dados como raiz:

PATH="$PATH:/usr/sap/HN1/HDB03/exe"
hdbsql -d SYSTEMDB -u system -i 03 "BACKUP DATA USING FILE ('initialbackup')"

Se utilizar uma instalação multi-arrendatária, também faça o back up da base de dados de inquilinos:

hdbsql -d HN1 -u system -i 03 "BACKUP DATA USING FILE ('initialbackup')"

4. [1] Configurar a replicação do sistema no primeiro nó.


Crie o local primário como <> hanasid adm:

su - hdbadm
hdbnsutil -sr_enable –-name=SITE1

5. [2] Configurar a replicação do sistema no nó secundário.


Registe o local secundário como <> hanasid adm:

sapcontrol -nr 03 -function StopWait 600 10


hdbnsutil -sr_register --remoteHost=hn1-db-0 --remoteInstance=03 --replicationMode=sync --
name=SITE2

Criar recursos de cluster SAP HANA


Primeiro, crie a topologia HANA. Executar os seguintes comandos num dos nós do cluster Pacemaker:

sudo crm configure property maintenance-mode=true

# Replace the bold string with your instance number and HANA system ID

sudo crm configure primitive rsc_SAPHanaTopology_HN1_HDB03 ocf:suse:SAPHanaTopology \


operations \$id="rsc_sap2_HN1_HDB03-operations" \
op monitor interval="10" timeout="600" \
op start interval="0" timeout="600" \
op stop interval="0" timeout="300" \
params SID="HN1" InstanceNumber="03"

sudo crm configure clone cln_SAPHanaTopology_HN1_HDB03 rsc_SAPHanaTopology_HN1_HDB03 \


meta clone-node-max="1" target-role="Started" interleave="true"

Em seguida, crie os recursos HANA:


IMPORTANT
Testes recentes revelaram situações, em que o netcat deixa de responder aos pedidos devido a atrasos e à sua
limitação de manuseamento apenas uma ligação. O recurso netcat para de ouvir os pedidos do balanceador de carga
Azure e o IP flutuante fica indisponível.
Para os aglomerados Pacemaker existentes, recomendamos no passado substituir o netcat por socat. Atualmente
recomendamos a utilização de um agente de recursos azure-lb, que faz parte dos agentes de recursos do pacote, com
os seguintes requisitos de versão de pacote:
Para o SLES 12 SP4/SP5, a versão deve ser pelo menos agentes de recursos-4.3.018.a7fb5035-3.30.1.
Para o SLES 15/15 SP1, a versão deve ser pelo menos agentes de recursos-4.3.0184.6ee15eb2-4.13.1.
Note que a alteração exigirá um breve tempo de inatividade.
Para os clusters Pacemaker existentes, se a configuração já foi alterada para utilizar o socat conforme descrito no
Endurecimento de Deteção de Equilíbrio de Carga azure,não há necessidade de mudar imediatamente para o agente
de recursos azure-lb.

# Replace the bold string with your instance number, HANA system ID, and the front-end IP address of the
Azure load balancer.

sudo crm configure primitive rsc_SAPHana_HN1_HDB03 ocf:suse:SAPHana \


operations \$id="rsc_sap_HN1_HDB03-operations" \
op start interval="0" timeout="3600" \
op stop interval="0" timeout="3600" \
op promote interval="0" timeout="3600" \
op monitor interval="60" role="Master" timeout="700" \
op monitor interval="61" role="Slave" timeout="700" \
params SID="HN1" InstanceNumber="03" PREFER_SITE_TAKEOVER="true" \
DUPLICATE_PRIMARY_TIMEOUT="7200" AUTOMATED_REGISTER="false"

sudo crm configure ms msl_SAPHana_HN1_HDB03 rsc_SAPHana_HN1_HDB03 \


meta notify="true" clone-max="2" clone-node-max="1" \
target-role="Started" interleave="true"

sudo crm configure primitive rsc_ip_HN1_HDB03 ocf:heartbeat:IPaddr2 \


meta target-role="Started" \
operations \$id="rsc_ip_HN1_HDB03-operations" \
op monitor interval="10s" timeout="20s" \
params ip="10.0.0.13"

sudo crm configure primitive rsc_nc_HN1_HDB03 azure-lb port=62503 \


meta resource-stickiness=0

sudo crm configure group g_ip_HN1_HDB03 rsc_ip_HN1_HDB03 rsc_nc_HN1_HDB03

sudo crm configure colocation col_saphana_ip_HN1_HDB03 4000: g_ip_HN1_HDB03:Started \


msl_SAPHana_HN1_HDB03:Master

sudo crm configure order ord_SAPHana_HN1_HDB03 Optional: cln_SAPHanaTopology_HN1_HDB03 \


msl_SAPHana_HN1_HDB03

# Clean up the HANA resources. The HANA resources might have failed because of a known issue.
sudo crm resource cleanup rsc_SAPHana_HN1_HDB03

sudo crm configure property maintenance-mode=false


sudo crm configure rsc_defaults resource-stickiness=1000
sudo crm configure rsc_defaults migration-threshold=5000

Certifique-se de que o estado do cluster está ok e que todos os recursos são iniciados. Não é importante em
que nó dos recursos estão a funcionar.
sudo crm_mon -r

# Online: [ hn1-db-0 hn1-db-1 ]


#
# Full list of resources:
#
# stonith-sbd (stonith:external/sbd): Started hn1-db-0
# rsc_st_azure (stonith:fence_azure_arm): Started hn1-db-1
# Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
# Started: [ hn1-db-0 hn1-db-1 ]
# Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
# Masters: [ hn1-db-0 ]
# Slaves: [ hn1-db-1 ]
# Resource Group: g_ip_HN1_HDB03
# rsc_ip_HN1_HDB03 (ocf::heartbeat:IPaddr2): Started hn1-db-0
# rsc_nc_HN1_HDB03 (ocf::heartbeat:azure-lb): Started hn1-db-0

Testar a configuração do cluster


Esta secção descreve como pode testar a sua configuração. Todos os testes assumem que você é raiz e o
mestre SAP HANA está correndo na máquina virtual hn1-db-0.
Testar a migração
Antes de iniciar o teste, certifique-se de que o Pacemaker não tem qualquer ação falhada (via crm_mon -r),
não existem restrições de localização inesperadas (por exemplo, restos de um teste de migração) e que hana
é estado de sincronização, por exemplo com SAPHanaSR-showAttr:

hn1-db-0:~ # SAPHanaSR-showAttr

Global cib-time
--------------------------------
global Mon Aug 13 11:26:04 2018

Hosts clone_state lpa_hn1_lpt node_state op_mode remoteHost roles


score site srmode sync_state version vhost
---------------------------------------------------------------------------------------------------------
--------------------------------------------------------------------
hn1-db-0 PROMOTED 1534159564 online logreplay nws-hana-vm-1 4:P:master1:master:worker:master 150
SITE1 sync PRIM 2.00.030.00.1522209842 nws-hana-vm-0
hn1-db-1 DEMOTED 30 online logreplay nws-hana-vm-0 4:S:master1:master:worker:master 100
SITE2 sync SOK 2.00.030.00.1522209842 nws-hana-vm-1

Pode migrar o nó mestre SAP HANA executando o seguinte comando:

crm resource migrate msl_SAPHana_HN1_HDB03 hn1-db-1

Se AUTOMATED_REGISTER="false" definir, esta sequência de comandos deve migrar o nó principal SAP HANA e
o grupo que contém o endereço IP virtual para hn1-db-1.
Uma vez que a migração é feita, a saída crm_mon -r parece-se com esta
Online: [ hn1-db-0 hn1-db-1 ]

Full list of resources:

stonith-sbd (stonith:external/sbd): Started hn1-db-1


Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
Masters: [ hn1-db-1 ]
Stopped: [ hn1-db-0 ]
Resource Group: g_ip_HN1_HDB03
rsc_ip_HN1_HDB03 (ocf::heartbeat:IPaddr2): Started hn1-db-1
rsc_nc_HN1_HDB03 (ocf::heartbeat:azure-lb): Started hn1-db-1

Failed Actions:
* rsc_SAPHana_HN1_HDB03_start_0 on hn1-db-0 'not running' (7): call=84, status=complete,
exitreason='none',
last-rc-change='Mon Aug 13 11:31:37 2018', queued=0ms, exec=2095ms

O recurso SAP HANA no hn1-db-0 não começa como secundário. Neste caso, configure a instância HANA
como secundária executando este comando:

su - hn1adm

# Stop the HANA instance just in case it is running


hn1adm@hn1-db-0:/usr/sap/HN1/HDB03> sapcontrol -nr 03 -function StopWait 600 10
hn1adm@hn1-db-0:/usr/sap/HN1/HDB03> hdbnsutil -sr_register --remoteHost=hn1-db-1 --remoteInstance=03 --
replicationMode=sync --name=SITE1

A migração cria constrangimentos de localização que precisam de ser novamente eliminados:

# Switch back to root and clean up the failed state


exit
hn1-db-0:~ # crm resource unmigrate msl_SAPHana_HN1_HDB03

Você também precisa limpar o estado do recurso do nó secundário:

hn1-db-0:~ # crm resource cleanup msl_SAPHana_HN1_HDB03 hn1-db-0

Monitorize o estado do recurso HANA utilizando crm_mon-r. Uma vez que HANA é iniciado em hn1-db-0, a
saída deve ser assim

Online: [ hn1-db-0 hn1-db-1 ]

Full list of resources:

stonith-sbd (stonith:external/sbd): Started hn1-db-1


Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
Masters: [ hn1-db-1 ]
Slaves: [ hn1-db-0 ]
Resource Group: g_ip_HN1_HDB03
rsc_ip_HN1_HDB03 (ocf::heartbeat:IPaddr2): Started hn1-db-1
rsc_nc_HN1_HDB03 (ocf::heartbeat:azure-lb): Started hn1-db-1

Teste o agente de esgrima Azure (não SBD)


Pode testar a configuração do agente de esgrima Azure desativando a interface de rede no nó hn1-db-0:
sudo ifdown eth0

A máquina virtual deve agora reiniciar ou parar dependendo da configuração do seu cluster. Se definir a
stonith-action configuração para o desligado, a máquina virtual é parada e os recursos são migrados para
a máquina virtual em execução.
Depois de relançar a máquina virtual, o recurso SAP HANA não começa como secundário se definir
AUTOMATED_REGISTER="false" . Neste caso, configure a instância HANA como secundária executando este
comando:

su - hn1adm

# Stop the HANA instance just in case it is running


sapcontrol -nr 03 -function StopWait 600 10
hdbnsutil -sr_register --remoteHost=hn1-db-1 --remoteInstance=03 --replicationMode=sync --name=SITE1

# Switch back to root and clean up the failed state


exit
crm resource cleanup msl_SAPHana_HN1_HDB03 hn1-db-0

Esgrima SBD de teste


Pode testar a configuração da DSB matando o processo do inquisidor.

hn1-db-0:~ # ps aux | grep sbd


root 1912 0.0 0.0 85420 11740 ? SL 12:25 0:00 sbd: inquisitor
root 1929 0.0 0.0 85456 11776 ? SL 12:25 0:00 sbd: watcher: /dev/disk/by-id/scsi-
360014056f268462316e4681b704a9f73 - slot: 0 - uuid: 7b862dba-e7f7-4800-92ed-f76a4e3978c8
root 1930 0.0 0.0 85456 11776 ? SL 12:25 0:00 sbd: watcher: /dev/disk/by-id/scsi-
360014059bc9ea4e4bac4b18808299aaf - slot: 0 - uuid: 5813ee04-b75c-482e-805e-3b1e22ba16cd
root 1931 0.0 0.0 85456 11776 ? SL 12:25 0:00 sbd: watcher: /dev/disk/by-id/scsi-
36001405b8dddd44eb3647908def6621c - slot: 0 - uuid: 986ed8f8-947d-4396-8aec-b933b75e904c
root 1932 0.0 0.0 90524 16656 ? SL 12:25 0:00 sbd: watcher: Pacemaker
root 1933 0.0 0.0 102708 28260 ? SL 12:25 0:00 sbd: watcher: Cluster
root 13877 0.0 0.0 9292 1572 pts/0 S+ 12:27 0:00 grep sbd

hn1-db-0:~ # kill -9 1912

O nó de aglomerado hn1-db-0 deve ser reiniciado. O serviço Pacemaker pode não começar depois.
Certifique-se de começar de novo.
Teste uma falha manual
Pode testar uma falha manual interrompendo o pacemaker serviço no nó hn1-db-0:

service pacemaker stop

Depois da falha, pode recomeçar o serviço. Se AUTOMATED_REGISTER="false" definir, o recurso SAP HANA no
nó hn1-db-0 não começa como secundário. Neste caso, configure a instância HANA como secundária
executando este comando:
service pacemaker start
su - hn1adm

# Stop the HANA instance just in case it is running


sapcontrol -nr 03 -function StopWait 600 10
hdbnsutil -sr_register --remoteHost=hn1-db-1 --remoteInstance=03 --replicationMode=sync --name=SITE1

# Switch back to root and clean up the failed state


exit
crm resource cleanup msl_SAPHana_HN1_HDB03 hn1-db-0

Testes de sUSE

IMPORTANT
Certifique-se de que o SISTEMA selecionado é certificado sAP para SAP HANA nos tipos de VM específicos que está a
utilizar. A lista dos tipos vM certificados sAP HANA e os lançamentos de SOs para aqueles podem ser analisados nas
Plataformas IaaS Certificadas SAP HANA. Certifique-se de clicar nos detalhes do tipo VM listado para obter a lista
completa de lançamentos sap HANA suportados para o tipo de VM específico

Execute todos os casos de teste listados no Cenário Otimizado de Desempenho SAP HANA SR ou no guia
SAP HANA SR Custo Optimized Scenario, dependendo do seu caso de utilização. Pode encontrar os guias na
página SLES para as melhores práticas do SAP.
Os seguintes testes são uma cópia das descrições do teste do sap HANA SR Performance Optimized Scenario
SUSE Linux Enterprise Server para aplicações SAP 12 SP1 guia. Para uma versão atualizada, leia sempre o
guia em si. Certifique-se sempre de que a HANA está sincronizada antes de iniciar o teste e certifique-se
também de que a configuração do Pacemaker está correta.
Nas seguintes descrições do teste assumimos PREFER_SITE_TAKEOVER="verdade" e
AUTOMATED_REGISTER="falso". NOTA: Os seguintes ensaios foram concebidos para serem executados em
sequência e dependem do estado de saída dos testes anteriores.
1. TESTE 1: PARAR BASE DE DADOS PRIMÁRIA NO NÓ 1
Estado de recurso antes de iniciar o teste:

Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]


Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
Masters: [ hn1-db-0 ]
Slaves: [ hn1-db-1 ]
Resource Group: g_ip_HN1_HDB03
rsc_ip_HN1_HDB03 (ocf::heartbeat:IPaddr2): Started hn1-db-0
rsc_nc_HN1_HDB03 (ocf::heartbeat:azure-lb): Started hn1-db-0

Executar os seguintes comandos como <> hanasid adm no nó hn1-db-0:

hn1adm@hn1-db-0:/usr/sap/HN1/HDB03> HDB stop

O pacemaker deve detetar a instância HANA parada e falhar com o outro nó. Uma vez que a falha é
feita, a instância HANA no nó hn1-db-0 é interrompida porque pacemaker não regista
automaticamente o nó como hana secundário.
Executar os seguintes comandos para registar o nó hn1-db-0 como secundário e limpar o recurso
falhado.
hn1adm@hn1-db-0:/usr/sap/HN1/HDB03> hdbnsutil -sr_register --remoteHost=hn1-db-1 --
remoteInstance=03 --replicationMode=sync --name=SITE1

# run as root
hn1-db-0:~ # crm resource cleanup msl_SAPHana_HN1_HDB03 hn1-db-0

Estado de recurso após o teste:

Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]


Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
Masters: [ hn1-db-1 ]
Slaves: [ hn1-db-0 ]
Resource Group: g_ip_HN1_HDB03
rsc_ip_HN1_HDB03 (ocf::heartbeat:IPaddr2): Started hn1-db-1
rsc_nc_HN1_HDB03 (ocf::heartbeat:azure-lb): Started hn1-db-1

2. TESTE 2: PARAR BASE DE DADOS PRIMÁRIA NO NÓ 2


Estado de recurso antes de iniciar o teste:

Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]


Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
Masters: [ hn1-db-1 ]
Slaves: [ hn1-db-0 ]
Resource Group: g_ip_HN1_HDB03
rsc_ip_HN1_HDB03 (ocf::heartbeat:IPaddr2): Started hn1-db-1
rsc_nc_HN1_HDB03 (ocf::heartbeat:azure-lb): Started hn1-db-1

Executar os seguintes comandos como <> hanasid adm no nó hn1-db-1:

hn1adm@hn1-db-1:/usr/sap/HN1/HDB03> HDB stop

O pacemaker deve detetar a instância HANA parada e falhar com o outro nó. Uma vez que a falha é
feita, a instância HANA no nó hn1-db-1 é interrompida porque o Pacemaker não regista
automaticamente o nó como hana secundário.
Executar os seguintes comandos para registar o nó hn1-db-1 como secundário e limpar o recurso
falhado.

hn1adm@hn1-db-1:/usr/sap/HN1/HDB03> hdbnsutil -sr_register --remoteHost=hn1-db-0 --


remoteInstance=03 --replicationMode=sync --name=SITE2

# run as root
hn1-db-1:~ # crm resource cleanup msl_SAPHana_HN1_HDB03 hn1-db-1

Estado de recurso após o teste:


Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
Masters: [ hn1-db-0 ]
Slaves: [ hn1-db-1 ]
Resource Group: g_ip_HN1_HDB03
rsc_ip_HN1_HDB03 (ocf::heartbeat:IPaddr2): Started hn1-db-0
rsc_nc_HN1_HDB03 (ocf::heartbeat:azure-lb): Started hn1-db-0

3. TESTE 3: BASE DE DADOS PRIMÁRIA DE ACIDENTE NO NÓ


Estado de recurso antes de iniciar o teste:

Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]


Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
Masters: [ hn1-db-0 ]
Slaves: [ hn1-db-1 ]
Resource Group: g_ip_HN1_HDB03
rsc_ip_HN1_HDB03 (ocf::heartbeat:IPaddr2): Started hn1-db-0
rsc_nc_HN1_HDB03 (ocf::heartbeat:azure-lb): Started hn1-db-0

Executar os seguintes comandos como <> hanasid adm no nó hn1-db-0:

hn1adm@hn1-db-0:/usr/sap/HN1/HDB03> HDB kill-9

O pacemaker deve detetar a instância hana morta e falhar com o outro nó. Uma vez que a falha é feita,
a instância HANA no nó hn1-db-0 é interrompida porque pacemaker não regista automaticamente o
nó como hana secundário.
Executar os seguintes comandos para registar o nó hn1-db-0 como secundário e limpar o recurso
falhado.

hn1adm@hn1-db-0:/usr/sap/HN1/HDB03> hdbnsutil -sr_register --remoteHost=hn1-db-1 --


remoteInstance=03 --replicationMode=sync --name=SITE1

# run as root
hn1-db-0:~ # crm resource cleanup msl_SAPHana_HN1_HDB03 hn1-db-0

Estado de recurso após o teste:

Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]


Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
Masters: [ hn1-db-1 ]
Slaves: [ hn1-db-0 ]
Resource Group: g_ip_HN1_HDB03
rsc_ip_HN1_HDB03 (ocf::heartbeat:IPaddr2): Started hn1-db-1
rsc_nc_HN1_HDB03 (ocf::heartbeat:azure-lb): Started hn1-db-1

4. TESTE 4: BASE DE DADOS PRIMÁRIA DE ACIDENTE NO NÓ 2


Estado de recurso antes de iniciar o teste:
Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
Masters: [ hn1-db-1 ]
Slaves: [ hn1-db-0 ]
Resource Group: g_ip_HN1_HDB03
rsc_ip_HN1_HDB03 (ocf::heartbeat:IPaddr2): Started hn1-db-1
rsc_nc_HN1_HDB03 (ocf::heartbeat:azure-lb): Started hn1-db-1

Executar os seguintes comandos como <> hanasid adm no nó hn1-db-1:

hn1adm@hn1-db-1:/usr/sap/HN1/HDB03> HDB kill-9

O pacemaker deve detetar a instância hana morta e falhar com o outro nó. Uma vez que a falha é feita,
a instância HANA no nó hn1-db-1 é interrompida porque o Pacemaker não regista automaticamente o
nó como hana secundário.
Executar os seguintes comandos para registar o nó hn1-db-1 como secundário e limpar o recurso
falhado.

hn1adm@hn1-db-1:/usr/sap/HN1/HDB03> hdbnsutil -sr_register --remoteHost=hn1-db-0 --


remoteInstance=03 --replicationMode=sync --name=SITE2

# run as root
hn1-db-1:~ # crm resource cleanup msl_SAPHana_HN1_HDB03 hn1-db-1

Estado de recurso após o teste:

Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]


Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
Masters: [ hn1-db-0 ]
Slaves: [ hn1-db-1 ]
Resource Group: g_ip_HN1_HDB03
rsc_ip_HN1_HDB03 (ocf::heartbeat:IPaddr2): Started hn1-db-0
rsc_nc_HN1_HDB03 (ocf::heartbeat:azure-lb): Started hn1-db-0

5. TESTE 5: NÓ DO LOCAL PRIMÁRIO DE ACIDENTE (NÓ 1)


Estado de recurso antes de iniciar o teste:

Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]


Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
Masters: [ hn1-db-0 ]
Slaves: [ hn1-db-1 ]
Resource Group: g_ip_HN1_HDB03
rsc_ip_HN1_HDB03 (ocf::heartbeat:IPaddr2): Started hn1-db-0
rsc_nc_HN1_HDB03 (ocf::heartbeat:azure-lb): Started hn1-db-0

Executar os seguintes comandos como raiz no nó hn1-db-0:

hn1-db-0:~ # echo 'b' > /proc/sysrq-trigger

O pacemaker deve detetar o nó de aglomerado morto e cercar o nó. Assim que o nó estiver vedado, o
Pacemaker irá desencadear uma aquisição da instância HANA. Quando o nó vedado for reiniciado, o
Pacemaker não iniciará automaticamente.
Executar os seguintes comandos para iniciar o Pacemaker, limpar as mensagens SBD para o nó hn1-
db-0, registar o nó hn1-db-0 como secundário, e limpar o recurso falhado.

# run as root
# list the SBD device(s)
hn1-db-0:~ # cat /etc/sysconfig/sbd | grep SBD_DEVICE=
# SBD_DEVICE="/dev/disk/by-id/scsi-36001405772fe8401e6240c985857e116;/dev/disk/by-id/scsi-
36001405034a84428af24ddd8c3a3e9e1;/dev/disk/by-id/scsi-36001405cdd5ac8d40e548449318510c3"

hn1-db-0:~ # sbd -d /dev/disk/by-id/scsi-36001405772fe8401e6240c985857e116 -d /dev/disk/by-


id/scsi-36001405034a84428af24ddd8c3a3e9e1 -d /dev/disk/by-id/scsi-
36001405cdd5ac8d40e548449318510c3 message hn1-db-0 clear

hn1-db-0:~ # systemctl start pacemaker

# run as <hanasid>adm
hn1adm@hn1-db-0:/usr/sap/HN1/HDB03> hdbnsutil -sr_register --remoteHost=hn1-db-1 --
remoteInstance=03 --replicationMode=sync --name=SITE1

# run as root
hn1-db-0:~ # crm resource cleanup msl_SAPHana_HN1_HDB03 hn1-db-0

Estado de recurso após o teste:

Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]


Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
Masters: [ hn1-db-1 ]
Slaves: [ hn1-db-0 ]
Resource Group: g_ip_HN1_HDB03
rsc_ip_HN1_HDB03 (ocf::heartbeat:IPaddr2): Started hn1-db-1
rsc_nc_HN1_HDB03 (ocf::heartbeat:azure-lb): Started hn1-db-1

6. TESTE 6: NÓ SECUNDÁRIO DO LOCAL DO ACIDENTE (NÓ 2)


Estado de recurso antes de iniciar o teste:

Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]


Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
Masters: [ hn1-db-1 ]
Slaves: [ hn1-db-0 ]
Resource Group: g_ip_HN1_HDB03
rsc_ip_HN1_HDB03 (ocf::heartbeat:IPaddr2): Started hn1-db-1
rsc_nc_HN1_HDB03 (ocf::heartbeat:azure-lb): Started hn1-db-1

Executar os seguintes comandos como raiz no nó hn1-db-1:

hn1-db-1:~ # echo 'b' > /proc/sysrq-trigger

O pacemaker deve detetar o nó de aglomerado morto e cercar o nó. Assim que o nó estiver vedado, o
Pacemaker irá desencadear uma aquisição da instância HANA. Quando o nó vedado for reiniciado, o
Pacemaker não iniciará automaticamente.
Executar os seguintes comandos para iniciar o Pacemaker, limpar as mensagens SBD para o nó hn1-
db-1, registar o nó hn1-db-1 como secundário e limpar o recurso falhado.
# run as root
# list the SBD device(s)
hn1-db-1:~ # cat /etc/sysconfig/sbd | grep SBD_DEVICE=
# SBD_DEVICE="/dev/disk/by-id/scsi-36001405772fe8401e6240c985857e116;/dev/disk/by-id/scsi-
36001405034a84428af24ddd8c3a3e9e1;/dev/disk/by-id/scsi-36001405cdd5ac8d40e548449318510c3"

hn1-db-1:~ # sbd -d /dev/disk/by-id/scsi-36001405772fe8401e6240c985857e116 -d /dev/disk/by-


id/scsi-36001405034a84428af24ddd8c3a3e9e1 -d /dev/disk/by-id/scsi-
36001405cdd5ac8d40e548449318510c3 message hn1-db-1 clear

hn1-db-1:~ # systemctl start pacemaker

# run as <hanasid>adm
hn1adm@hn1-db-1:/usr/sap/HN1/HDB03> hdbnsutil -sr_register --remoteHost=hn1-db-0 --
remoteInstance=03 --replicationMode=sync --name=SITE2

# run as root
hn1-db-1:~ # crm resource cleanup msl_SAPHana_HN1_HDB03 hn1-db-1

Estado de recurso após o teste:

Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]


Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
Masters: [ hn1-db-0 ]
Slaves: [ hn1-db-1 ]
Resource Group: g_ip_HN1_HDB03
rsc_ip_HN1_HDB03 (ocf::heartbeat:IPaddr2): Started hn1-db-0
rsc_nc_HN1_HDB03 (ocf::heartbeat:azure-lb): Started hn1-db-0

7. TESTE 7: PARAR A BASE DE DADOS SECUNDÁRIA NO NÓ 2


Estado de recurso antes de iniciar o teste:

Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]


Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
Masters: [ hn1-db-0 ]
Slaves: [ hn1-db-1 ]
Resource Group: g_ip_HN1_HDB03
rsc_ip_HN1_HDB03 (ocf::heartbeat:IPaddr2): Started hn1-db-0
rsc_nc_HN1_HDB03 (ocf::heartbeat:azure-lb): Started hn1-db-0

Executar os seguintes comandos como <> hanasid adm no nó hn1-db-1:

hn1adm@hn1-db-1:/usr/sap/HN1/HDB03> HDB stop

O pacemaker detetará a instância HANA parada e marcará o recurso como falhado no nó hn1-db-1. O
pacemaker deve reiniciar automaticamente a instância HANA. Executar o seguinte comando para
limpar o estado falhado.

# run as root
hn1-db-1:~ # crm resource cleanup msl_SAPHana_HN1_HDB03 hn1-db-1

Estado de recurso após o teste:


Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
Masters: [ hn1-db-0 ]
Slaves: [ hn1-db-1 ]
Resource Group: g_ip_HN1_HDB03
rsc_ip_HN1_HDB03 (ocf::heartbeat:IPaddr2): Started hn1-db-0
rsc_nc_HN1_HDB03 (ocf::heartbeat:azure-lb): Started hn1-db-0

8. TESTE 8: BATER A BASE DE DADOS SECUNDÁRIA NO NÓ 2


Estado de recurso antes de iniciar o teste:

Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]


Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
Masters: [ hn1-db-0 ]
Slaves: [ hn1-db-1 ]
Resource Group: g_ip_HN1_HDB03
rsc_ip_HN1_HDB03 (ocf::heartbeat:IPaddr2): Started hn1-db-0
rsc_nc_HN1_HDB03 (ocf::heartbeat:azure-lb): Started hn1-db-0

Executar os seguintes comandos como <> hanasid adm no nó hn1-db-1:

hn1adm@hn1-db-1:/usr/sap/HN1/HDB03> HDB kill-9

O pacemaker detetará a instância HANA morta e marcará o recurso como falhado no nó hn1-db-1.
Executar o seguinte comando para limpar o estado falhado. O pacemaker deve então reiniciar
automaticamente a instância HANA.

# run as root
hn1-db-1:~ # crm resource cleanup msl_SAPHana_HN1_HDB03 hn1-db-1

Estado de recurso após o teste:

Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]


Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
Masters: [ hn1-db-0 ]
Slaves: [ hn1-db-1 ]
Resource Group: g_ip_HN1_HDB03
rsc_ip_HN1_HDB03 (ocf::heartbeat:IPaddr2): Started hn1-db-0
rsc_nc_HN1_HDB03 (ocf::heartbeat:azure-lb): Started hn1-db-0

9. TESTE 9: CRASH SecondARY SITE NÓDE (NÓ 2) EXECUÇÃO SEGUNDA BASE DE DADOS HANA
Estado de recurso antes de iniciar o teste:

Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]


Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
Masters: [ hn1-db-0 ]
Slaves: [ hn1-db-1 ]
Resource Group: g_ip_HN1_HDB03
rsc_ip_HN1_HDB03 (ocf::heartbeat:IPaddr2): Started hn1-db-0
rsc_nc_HN1_HDB03 (ocf::heartbeat:azure-lb): Started hn1-db-0
Executar os seguintes comandos como raiz no nó hn1-db-1:

hn1-db-1:~ # echo b > /proc/sysrq-trigger

O pacemaker deve detetar o nó de aglomerado morto e cercar o nó. Quando o nó vedado for
reiniciado, o Pacemaker não iniciará automaticamente.
Executar os seguintes comandos para iniciar o Pacemaker, limpe as mensagens SBD para o nó hn1-db-
1 e limpe o recurso falhado.

# run as root
# list the SBD device(s)
hn1-db-1:~ # cat /etc/sysconfig/sbd | grep SBD_DEVICE=
# SBD_DEVICE="/dev/disk/by-id/scsi-36001405772fe8401e6240c985857e116;/dev/disk/by-id/scsi-
36001405034a84428af24ddd8c3a3e9e1;/dev/disk/by-id/scsi-36001405cdd5ac8d40e548449318510c3"

hn1-db-1:~ # sbd -d /dev/disk/by-id/scsi-36001405772fe8401e6240c985857e116 -d /dev/disk/by-


id/scsi-36001405034a84428af24ddd8c3a3e9e1 -d /dev/disk/by-id/scsi-
36001405cdd5ac8d40e548449318510c3 message hn1-db-1 clear

hn1-db-1:~ # systemctl start pacemaker

hn1-db-1:~ # crm resource cleanup msl_SAPHana_HN1_HDB03 hn1-db-1

Estado de recurso após o teste:

Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]


Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
Masters: [ hn1-db-0 ]
Slaves: [ hn1-db-1 ]
Resource Group: g_ip_HN1_HDB03
rsc_ip_HN1_HDB03 (ocf::heartbeat:IPaddr2): Started hn1-db-0
rsc_nc_HN1_HDB03 (ocf::heartbeat:azure-lb): Started hn1-db-0

Passos seguintes
Planeamento e implementação de Máquinas Virtuais Azure para SAP
Implantação de Máquinas Virtuais Azure para SAP
Implantação de DBMS de Máquinas Virtuais Azure para SAP
Alta disponibilidade de SAP HANA em VMs Azure
em Red Hat Enterprise Linux
21/06/2020 • 43 minutes to read • Edit Online

Para o desenvolvimento no local, pode utilizar a Replicação do Sistema HANA ou utilizar o armazenamento
partilhado para estabelecer uma elevada disponibilidade para o SAP HANA. Nas máquinas virtuais Azure (VMs),
a replicação do sistema HANA no Azure é atualmente a única função de alta disponibilidade suportada. A
replicação do SAP HANA consiste num nó primário e pelo menos num nó secundário. As alterações aos dados
do nó primário são replicadas ao nó secundário sincronicamente ou assíncronamente.
Este artigo descreve como implementar e configurar as máquinas virtuais, instalar a estrutura do cluster e
instalar e configurar a Replicação do Sistema SAP HANA. Nas configurações de exemplo, são utilizados
comandos de instalação, instância número 03 e ID HN1 do sistema HANA.
Leia primeiro as seguintes Notas e papéis SAP:
Nota SAP [1928533,]que tem:
A lista dos tamanhos de VM Azure que são suportados para a implementação de software SAP.
Informações importantes sobre a capacidade para tamanhos de VM Azure.
O software SAP suportado e o sistema operativo (OS) e as combinações de bases de dados.
A versão necessária para o kernel SAP necessário para Windows e Linux no Microsoft Azure.
O SAP Note 2015553 lista os pré-requisitos para implementações de software SAP suportadas pela SAP em
Azure.
SAP Note 2002167 recomendou definições de OS para Red Hat Enterprise Linux
SAP Nota 2009879 tem Diretrizes SAP HANA para Red Hat Enterprise Linux
O SAP Note 2178632 tem informações detalhadas sobre todas as métricas de monitorização reportadas
para o SAP em Azure.
O SAP Note 2191498 tem a versão necessária do Agente anfitrião SAP para o Linux em Azure.
SAP Nota 2243692 tem informações sobre licenciamento SAP em Linux em Azure.
A Nota [SAP 1999351] tem informações adicionais de resolução de problemas para a extensão de
monitorização avançada do Azure para sAP.
A SAP Community WIKI exigiu todas as notas SAP para linux.
Planeamento e implementação de Máquinas Virtuais Azure para SAP em Linux
Implantação de Máquinas Virtuais Azure para SAP em Linux (este artigo)
Implantação de DBMS de Máquinas Virtuais Azure para SAP em Linux
Replicação do sistema SAP HANA em cluster pacemaker
Documentação Geral RHEL
Visão geral de complemento de alta disponibilidade
Administração add-on de alta disponibilidade
Referência addon de alta disponibilidade
Documentação RHEL específica do Azure:
Políticas de suporte para clusters de alta disponibilidade RHEL - Máquinas Virtuais Microsoft Azure
como Membros do Cluster
Instalação e Configuração de um Cluster de Alta Disponibilidade do Red Hat Enterprise Linux 7.4 (e
mais tarde) no Microsoft Azure
Instale SAP HANA no Red Hat Enterprise Linux para utilização no Microsoft Azure
Descrição geral
Para obter uma elevada disponibilidade, o SAP HANA está instalado em duas máquinas virtuais. Os dados são
replicados utilizando a replicação do sistema HANA.

A configuração de replicação do sistema SAP HANA utiliza um nome de anfitrião virtual dedicado e endereços
IP virtuais. No Azure, é necessário utilizar um endereço IP virtual. A lista que se segue mostra a configuração do
equilibrista de carga:
Configuração frontal: Endereço IP 10.0.0.13 para hn1-db
Configuração de back-end: Ligada às interfaces de rede primária de todas as máquinas virtuais que devem
fazer parte da Replicação do Sistema HANA
Porta da sonda: Porto 62503
Regras de equilíbrio de carga: 30313 TCP, 30315 TCP, 30317 TCP, 30340 TCP, 30341 TCP, 30342 TCP, 30342
TCP

Implantação para Linux


O Azure Marketplace contém uma imagem para Red Hat Enterprise Linux 7.4 para SAP HANA que pode usar
para implementar novas máquinas virtuais.
Implementar com um modelo
Você pode usar um dos modelos de arranque rápido que estão no GitHub para implementar todos os recursos
necessários. O modelo implanta as máquinas virtuais, o equilibrador de carga, o conjunto de disponibilidade, e
assim por diante. Para implementar o modelo, siga estes passos:
1. Abra o modelo de base de dados no portal Azure.
2. Introduza os seguintes parâmetros:
ID do sistema Sap : Introduza o ID do sistema SAP do sistema SAP que pretende instalar. O ID é
usado como prefixo para os recursos que são implantados.
Tipo Os : Selecione uma das distribuições linux. Para este exemplo, selecione RHEL 7 .
Tipo db : Selecione HANA .
Tamanho do sistema sap : Introduza o número de SAPS que o novo sistema vai fornecer. Se não tem
a certeza de quantos SAPS o sistema necessita, pergunte ao seu Parceiro de Tecnologia SAP ou ao
Integrador de Sistemas.
Disponibilidade do Sistema : Selecione HA .
Nome de utilizador, palavra-passe de administrador ou chave SSH : É criado um novo
utilizador que pode ser utilizado para iniciar sessão na máquina.
ID sub-rede : Se pretender implantar o VM numa VNet existente onde tenha uma sub-rede definida a
VM deve ser atribuída, diga o nome da identificação dessa sub-rede específica. O ID geralmente se
parece com /subscrições/ < ID de subscrição>/recursosGroups/ nome de < grupo de
recursos>/fornecedores/Microsoft.Network/vir tualNetworks/ nome de < rede
vir tual>/subnets/ nome de < sub-rede> . Deixe vazio, se quiser criar uma nova rede virtual
Implementação manual
1. Crie um grupo de recursos.
2. Crie uma rede virtual
3. Crie um conjunto de disponibilidade.
Detete o domínio da atualização máxima.
4. Criar um equilibrador de carga (interno). Recomendamos um equilíbrio de carga padrão.
Selecione a rede virtual criada no passo 2.
5. Criar a máquina virtual 1.
Utilize pelo menos a Red Hat Enterprise Linux 7.4 para sap HANA. Este exemplo utiliza o Red Hat
Enterprise Linux 7.4 para a imagem SAP HANA
https://portal.azure.com/#create/RedHat.RedHatEnterpriseLinux75forSAP-ARM Selecione o conjunto de
disponibilidade criado no passo 3.
6. Criar a máquina virtual 2.
Utilize pelo menos a Red Hat Enterprise Linux 7.4 para sap HANA. Este exemplo utiliza o Red Hat
Enterprise Linux 7.4 para a imagem SAP HANA
https://portal.azure.com/#create/RedHat.RedHatEnterpriseLinux75forSAP-ARM Selecione o conjunto de
disponibilidade criado no passo 3.
7. Adicione discos de dados.
8. Se utilizar um equilibrador de carga padrão, siga estes passos de configuração:
a. Primeiro, crie uma piscina IP frontal:
a. Abra o equilibrador de carga, selecione pool IP frontend, e selecione Adicionar .
b. Introduza o nome da nova piscina IP frontal (por exemplo, hana-frontend).
c. Defino a Atribuição à Estática e introduza o endereço IP (por exemplo, 10.0.0.13 ).
d. Selecione OK .
e. Depois de criado o novo pool IP frontal, note o endereço IP do pool.
b. Em seguida, crie uma piscina de back-end:
a. Abra o equilibrador de carga, selecione piscinas de backend, e selecione Adicionar .
b. Introduza o nome da nova piscina traseira (por exemplo, hana-backend).
c. Selecione Adicionar uma máquina vir tual .
d. Selecione ** Máquina virtual**.
e. Selecione as máquinas virtuais do cluster SAP HANA e os seus endereços IP.
f. Selecione Adicionar .
c. Em seguida, crie uma sonda de saúde:
a. Abra o equilibrador de carga, selecione sondas de saúde, e selecione Adicionar .
b. Introduza o nome da nova sonda de saúde (por exemplo, hana-hp).
c. Selecione TCP como protocolo e porta 62503 . Mantenha o valor de inter valo definido para 5
e o valor limiar não saudável definido para 2.
d. Selecione OK .
d. Em seguida, crie as regras de equilíbrio de carga:
a. Abra o equilibrador de carga, selecione regras de equilíbrio de carga, e selecione Adicionar .
b. Introduza o nome da nova regra do equilibrador de carga (por exemplo, hana-lb ).
c. Selecione o endereço IP frontal, a piscina traseira e a sonda de saúde que criou anteriormente
(por exemplo, hana-frontend, hana-backend e hana-hp).
d. Selecione Por tas HA .
e. Aumente o tempo de inatividade para 30 minutos.
f. Certifique-se de ativar o IP flutuante .
g. Selecione OK .

NOTE
Quando os VMs sem endereços IP públicos forem colocados no conjunto de backend do interno (sem endereço IP
público) O equilíbrio de carga Standard Azure não haverá conectividade de saída na Internet, a menos que seja
realizada uma configuração adicional para permitir o encaminhamento para pontos finais públicos. Para mais
detalhes sobre como alcançar a conectividade de saída, consulte a conectividade do ponto final público para
máquinas virtuais utilizando o Equilíbrio de Carga Padrão Azure em cenários de alta disponibilidade SAP.

9. Alternativamente, se o seu cenário ditar a utilização de um equilíbrio básico de carga, siga estes passos
de configuração:
a. Configure o equilibrador de carga. Primeiro, crie uma piscina IP frontal:
a. Abra o equilibrador de carga, selecione pool IP frontend, e selecione Adicionar .
b. Introduza o nome da nova piscina IP frontal (por exemplo, hana-frontend).
c. Defino a Atribuição à Estática e introduza o endereço IP (por exemplo, 10.0.0.13 ).
d. Selecione OK .
e. Depois de criado o novo pool IP frontal, note o endereço IP do pool.
b. Em seguida, crie uma piscina de back-end:
a. Abra o equilibrador de carga, selecione piscinas de backend, e selecione Adicionar .
b. Introduza o nome da nova piscina traseira (por exemplo, hana-backend).
c. Selecione Adicionar uma máquina vir tual .
d. Selecione o conjunto de disponibilidade criado no passo 3.
e. Selecione as máquinas virtuais do cluster SAP HANA.
f. Selecione OK .
c. Em seguida, crie uma sonda de saúde:
a. Abra o equilibrador de carga, selecione sondas de saúde, e selecione Adicionar .
b. Introduza o nome da nova sonda de saúde (por exemplo, hana-hp).
c. Selecione TCP como protocolo e porta 62503 . Mantenha o valor de inter valo definido para 5
e o valor limiar não saudável definido para 2.
d. Selecione OK .
d. Para o SAP HANA 1.0, crie as regras de equilíbrio de carga:
a. Abra o equilibrador de carga, selecione regras de equilíbrio de carga, e selecione Adicionar .
b. Introduza o nome da nova regra do equilibrador de carga (por exemplo, hana-lb-303 15).
c. Selecione o endereço IP frontal, a piscina traseira e a sonda de saúde que criou anteriormente
(por exemplo, hana-frontend ).
d. Mantenha o Protocolo definido para a TCP e entre na porta 303 15.
e. Aumente o tempo de inatividade para 30 minutos.
f. Certifique-se de ativar o IP flutuante .
g. Selecione OK .
h. Repita estes passos para a porta 303 17.
e. Para o SAP HANA 2.0, crie as regras de equilíbrio de carga para a base de dados do sistema:
a. Abra o equilibrador de carga, selecione regras de equilíbrio de carga, e selecione Adicionar .
b. Introduza o nome da nova regra do equilibrador de carga (por exemplo, hana-lb-303 13).
c. Selecione o endereço IP frontal, a piscina traseira e a sonda de saúde que criou anteriormente
(por exemplo, hana-frontend ).
d. Mantenha o Protocolo definido para a TCP e entre na porta 303 13.
e. Aumente o tempo de inatividade para 30 minutos.
f. Certifique-se de ativar o IP flutuante .
g. Selecione OK .
h. Repita estes passos para a porta 303 14.
f. Para o SAP HANA 2.0, crie primeiro as regras de equilíbrio de carga para a base de dados dos
inquilinos:
a. Abra o equilibrador de carga, selecione regras de equilíbrio de carga, e selecione Adicionar .
b. Introduza o nome da nova regra do equilibrador de carga (por exemplo, hana-lb-303 40).
c. Selecione o endereço IP frontal, a piscina de backend e a sonda de saúde que criou
anteriormente (por exemplo, hana-frontend ).
d. Mantenha o Protocolo definido para a TCP e entre na porta 303 40.
e. Aumente o tempo de inatividade para 30 minutos.
f. Certifique-se de ativar o IP flutuante .
g. Selecione OK .
h. Repita estes passos para as portas 303 41 e 303 42.
Para obter mais informações sobre as portas necessárias para o SAP HANA, leia o capítulo Ligações às Bases de
Dados de Inquilinos no guia SAP HANA Tenant Databases ou SAP Nota 2388694.

IMPORTANT
Não permita os carimbos de tempo da TCP em VMs Azure colocados atrás do Equilíbrio de Carga Azure. Permitir os selos
temporais da TCP fará com que as sondas de saúde falhem. Definir parâmetro net.ipv4.tcp_timestamps a 0 . Para mais
detalhes consulte as sondas de saúde load Balancer. Consulte também a nota SAP 2382421.

Instalar o SAP HANA


Os passos nesta secção utilizam os seguintes prefixos:
[A] : O passo aplica-se a todos os nós.
[1] : O passo aplica-se apenas ao nó 1.
[2] : O passo aplica-se apenas ao nó 2 do cluster Pacemaker.
1. [A] Configurar o layout do disco: Logical Volume Manager (LVM) .
Recomendamos que utilize o LVM para volumes que armazenem dados e ficheiros de registo. O exemplo
seguinte pressupõe que as máquinas virtuais têm quatro discos de dados ligados que são usados para
criar dois volumes.
Enumerar todos os discos disponíveis:

ls /dev/disk/azure/scsi1/lun*

Exemplo de saída:

/dev/disk/azure/scsi1/lun0 /dev/disk/azure/scsi1/lun1 /dev/disk/azure/scsi1/lun2


/dev/disk/azure/scsi1/lun3

Crie volumes físicos para todos os discos que pretende utilizar:

sudo pvcreate /dev/disk/azure/scsi1/lun0


sudo pvcreate /dev/disk/azure/scsi1/lun1
sudo pvcreate /dev/disk/azure/scsi1/lun2
sudo pvcreate /dev/disk/azure/scsi1/lun3

Crie um grupo de volume para os ficheiros de dados. Utilize um grupo de volume para os ficheiros de
registo e um para o diretório partilhado do SAP HANA:

sudo vgcreate vg_hana_data_HN1 /dev/disk/azure/scsi1/lun0 /dev/disk/azure/scsi1/lun1


sudo vgcreate vg_hana_log_HN1 /dev/disk/azure/scsi1/lun2
sudo vgcreate vg_hana_shared_HN1 /dev/disk/azure/scsi1/lun3

Criar os volumes lógicos. Um volume linear é criado quando se utiliza lvcreate sem o -i interruptor.
Sugerimos que crie um volume listrado para um melhor desempenho em I/S e alinhe os tamanhos das
riscas com os valores documentados nas configurações de armazenamento VM SAP HANA. O -i
argumento deve ser o número dos volumes físicos subjacentes e o argumento é o tamanho das -I
riscas. Neste documento, são utilizados dois volumes físicos para o volume de dados, pelo que o
argumento da -i comutação está definido para 2 . O tamanho das riscas para o volume de dados é de
256KiB . Um volume físico é utilizado para o volume de registo, pelo que nenhum -i ou -I interruptor
é explicitamente utilizado para os comandos de volume de registo.

IMPORTANT
Utilize o -i interruptor e detetetete-o para o número do volume físico subjacente quando utilizar mais de um
volume físico para cada dados, registo ou volumes partilhados. Utilize o -I interruptor para especificar o
tamanho das riscas, quando criar um volume listrado.
Consulte as configurações de armazenamento VM SAP HANA para configurações de armazenamento
recomendadas, incluindo tamanhos de listras e número de discos.

sudo lvcreate -i 2 -I 256 -l 100%FREE -n hana_data vg_hana_data_HN1


sudo lvcreate -l 100%FREE -n hana_log vg_hana_log_HN1
sudo lvcreate -l 100%FREE -n hana_shared vg_hana_shared_HN1
sudo mkfs.xfs /dev/vg_hana_data_HN1/hana_data
sudo mkfs.xfs /dev/vg_hana_log_HN1/hana_log
sudo mkfs.xfs /dev/vg_hana_shared_HN1/hana_shared

Crie os diretórios de montagem e copie o UUID de todos os volumes lógicos:


sudo mkdir -p /hana/data/HN1
sudo mkdir -p /hana/log/HN1
sudo mkdir -p /hana/shared/HN1
# Write down the ID of /dev/vg_hana_data_HN1/hana_data, /dev/vg_hana_log_HN1/hana_log, and
/dev/vg_hana_shared_HN1/hana_shared
sudo blkid

Criar fstab entradas para os três volumes lógicos:

sudo vi /etc/fstab

Insira a seguinte linha no /etc/fstab ficheiro:

/dev/disk/by-uuid/<UUID of /dev/mapper/vg_hana_data_HN1-hana_data> /hana/data/HN1 xfs


defaults,nofail 0 2
/dev/disk/by-uuid/<UUID of /dev/mapper/vg_hana_log_HN1-hana_log> /hana/log/HN1 xfs defaults,nofail
0 2
/dev/disk/by-uuid/<UUID of /dev/mapper/vg_hana_shared_HN1-hana_shared> /hana/shared/HN1 xfs
defaults,nofail 0 2

Monte os novos volumes:

sudo mount -a

2. [A] Configurar o layout do disco: Discos simples .


Para sistemas de demonstração, pode colocar os seus dados HANA e ficheiros de registo num disco. Criar
uma partição em /dev/disk/azure/scsi1/lun0 e forme-a com xfs:

sudo sh -c 'echo -e "n\n\n\n\n\nw\n" | fdisk /dev/disk/azure/scsi1/lun0'


sudo mkfs.xfs /dev/disk/azure/scsi1/lun0-part1

# Write down the ID of /dev/disk/azure/scsi1/lun0-part1


sudo /sbin/blkid
sudo vi /etc/fstab

Insira esta linha no ficheiro /etc/fstab:

/dev/disk/by-uuid/<UUID> /hana xfs defaults,nofail 0 2

Crie o diretório-alvo e monte o disco:

sudo mkdir /hana


sudo mount -a

3. [A] Configurar a resolução de nomes de anfitrião para todos os anfitriões.


Pode utilizar um servidor DNS ou modificar o ficheiro /etc/anfitriões em todos os nós. Este exemplo
mostra-lhe como usar o ficheiro /etc/anfitriões. Substitua o endereço IP e o nome de anfitrião nos
seguintes comandos:

sudo vi /etc/hosts
Insira as seguintes linhas no ficheiro /etc/anfitriões. Altere o endereço IP e o nome de anfitrião para
combinar com o seu ambiente:

10.0.0.5 hn1-db-0
10.0.0.6 hn1-db-1

4. [A] RHEL para configuração HANA


Configure o RHEL conforme descrito na Nota SAP 2292690 e 2455582 e
https://access.redhat.com/solutions/2447641 .
5. [A] Instalar o SAP HANA
Para instalar a replicação do sistema SAP HANA, siga https://access.redhat.com/articles/3004101 .
Execute o programa hdblcm do DVD HANA. Introduza os seguintes valores no momento:
Escolha a instalação: Insira 1 .
Selecione componentes adicionais para instalação: Insira 1 .
Introduza o Caminho de Instalação [/hana/partilhado]: Selecione Entrar.
Introduza o nome do anfitrião local [..]: Selecione Entrar.
Deseja adicionar mais anfitriões ao sistema? (y/n) [n]: Selecione Entrar.
Introduza o ID do sistema SAP HANA: Introduza o SID de HANA, por exemplo: HN1 .
Insira o número da instância [00]: Introduza o número da instância HANA. Introduza 03 se usou o
modelo Azure ou seguiu a secção de implantação manual deste artigo.
Selecione Modo base de dados / Introduza o Índice [1]: Selecione Introduzir.
Selecione a utilização do sistema / Insira o Índice [4]: Selecione o valor de utilização do sistema.
Introduza a localização dos volumes de dados [/hana/data/HN1]: Selecione Entrar.
Introduza a localização dos volumes de registo [/hana/log/HN1]: Selecione Entrar.
Restringir a atribuição máxima de memória? [n]: Selecione Entrar.
Insira o nome do anfitrião do certificado para o anfitrião '...' [...]: Selecione Entrar.
Introduza o Utilizador do Agente anfitrião SAP (sapadm) Palavra-passe: Introduza a palavra-passe do
utilizador do agente anfitrião.
Confirme o Utilizador do Agente anfitrião SAP (sapadm) Palavra-passe: Introduza novamente a
palavra-passe do utilizador do agente anfitrião para confirmar.
Introduza o Administrador do Sistema (hdbadm) Palavra-passe: Introduza a palavra-passe do
administrador do sistema.
Confirmar Administrador do Sistema (hdbadm) Palavra-passe: Introduza novamente a palavra-passe
do administrador do sistema para confirmar.
Insira o Diretório Inicial do Administrador do Sistema [/usr/sap/HN1/home]: Selecione Entrar.
Introduza a concha de login do administrador do sistema [/bin/sh]: Selecione Entrar.
Introduza o ID do utilizador do administrador do sistema [1001]: Selecione Entrar.
Introduza id do Grupo utilizador (sapsys) [79]: Selecione Entrar.
Introduza a palavra-passe do utilizador (SISTEMA) da base de dados: Introduza a palavra-passe do
utilizador da base de dados.
Confirmar Palavra-passe do Utilizador da Base de Dados (SISTEMA): Introduza novamente a palavra-
passe do utilizador da base de dados para confirmar.
Reiniciar o sistema após a reinicialização da máquina? [n]: Selecione Entrar.
Quer continuar? (y/n): Validar o resumo. Insira y para continuar.
6. [A] Atualizar o Agente Hospedeiro SAP.
Descarregue o mais recente arquivo do Agente Anfitrião SAP do Centro de Software SAP e execute o
seguinte comando para atualizar o agente. Substitua o caminho para o arquivo para apontar para o
ficheiro que descarregou:

sudo /usr/sap/hostctrl/exe/saphostexec -upgrade -archive <path to SAP Host Agent SAR>

7. [A] Configurar firewall


Crie a regra da firewall para a porta de sonda de balanço de carga Azure.

sudo firewall-cmd --zone=public --add-port=62503/tcp


sudo firewall-cmd --zone=public --add-port=62503/tcp --permanent

Configure A Replicação do Sistema SAP HANA 2.0


Os passos nesta secção utilizam os seguintes prefixos:
[A] : O passo aplica-se a todos os nós.
[1] : O passo aplica-se apenas ao nó 1.
[2] : O passo aplica-se apenas ao nó 2 do cluster Pacemaker.
1. [A] Configurar firewall
Crie regras de firewall para permitir a replicação do sistema HANA e o tráfego do cliente. As portas
necessárias estão listadas nas portas TCP/IP de todos os produtos SAP. Os seguintes comandos são
apenas um exemplo para permitir a replicação do sistema HANA 2.0 e o tráfego do cliente para a base de
dados SYSTEMDB, HN1 e NW1.

sudo firewall-cmd --zone=public --add-port=40302/tcp --permanent


sudo firewall-cmd --zone=public --add-port=40302/tcp
sudo firewall-cmd --zone=public --add-port=40301/tcp --permanent
sudo firewall-cmd --zone=public --add-port=40301/tcp
sudo firewall-cmd --zone=public --add-port=40307/tcp --permanent
sudo firewall-cmd --zone=public --add-port=40307/tcp
sudo firewall-cmd --zone=public --add-port=40303/tcp --permanent
sudo firewall-cmd --zone=public --add-port=40303/tcp
sudo firewall-cmd --zone=public --add-port=40340/tcp --permanent
sudo firewall-cmd --zone=public --add-port=40340/tcp
sudo firewall-cmd --zone=public --add-port=30340/tcp --permanent
sudo firewall-cmd --zone=public --add-port=30340/tcp
sudo firewall-cmd --zone=public --add-port=30341/tcp --permanent
sudo firewall-cmd --zone=public --add-port=30341/tcp
sudo firewall-cmd --zone=public --add-port=30342/tcp --permanent
sudo firewall-cmd --zone=public --add-port=30342/tcp

2. [1] Criar a base de dados dos inquilinos.


Se estiver a utilizar o SAP HANA 2.0 ou o MDC, crie uma base de dados de inquilinos para o seu sistema
SAP NetWeaver. Substitua o NW1 pelo SID do seu sistema SAP.
Execute como <> hanasid adm o seguinte comando:

hdbsql -u SYSTEM -p "passwd" -i 03 -d SYSTEMDB 'CREATE DATABASE NW1 SYSTEM USER PASSWORD "passwd"'

3. [1] Configurar a replicação do sistema no primeiro nó:


Faça backup das bases de dados como <> hanasid adm:
hdbsql -d SYSTEMDB -u SYSTEM -p "passwd" -i 03 "BACKUP DATA USING FILE ('initialbackupSYS')"
hdbsql -d HN1 -u SYSTEM -p "passwd" -i 03 "BACKUP DATA USING FILE ('initialbackupHN1')"
hdbsql -d NW1 -u SYSTEM -p "passwd" -i 03 "BACKUP DATA USING FILE ('initialbackupNW1')"

Copie os ficheiros PKI do sistema para o local secundário:

scp /usr/sap/HN1/SYS/global/security/rsecssfs/data/SSFS_HN1.DAT hn1-db-


1:/usr/sap/HN1/SYS/global/security/rsecssfs/data/
scp /usr/sap/HN1/SYS/global/security/rsecssfs/key/SSFS_HN1.KEY hn1-db-
1:/usr/sap/HN1/SYS/global/security/rsecssfs/key/

Criar o local principal:

hdbnsutil -sr_enable --name=SITE1

4. [2] Configurar a replicação do sistema no segundo nó:


Registe o segundo nó para iniciar a replicação do sistema. Executar o seguinte comando como <>
hanasid adm:

sapcontrol -nr 03 -function StopWait 600 10


hdbnsutil -sr_register --remoteHost=hn1-db-0 --remoteInstance=03 --replicationMode=sync --name=SITE2

5. [1] Verificar o estado da replicação


Verifique o estado da replicação e aguarde até que todas as bases de dados estejam sincronizadas. Se o
estado permanecer DESCONHECIDO, verifique as definições da firewall.

sudo su - hn1adm -c "python /usr/sap/HN1/HDB03/exe/python_support/systemReplicationStatus.py"


# | Database | Host | Port | Service Name | Volume ID | Site ID | Site Name | Secondary |
Secondary | Secondary | Secondary | Secondary | Replication | Replication | Replication |
# | | | | | | | | Host | Port
| Site ID | Site Name | Active Status | Mode | Status | Status Details |
# | -------- | -------- | ----- | ------------ | --------- | ------- | --------- | --------- | ------
--- | --------- | --------- | ------------- | ----------- | ----------- | -------------- |
# | SYSTEMDB | hn1-db-0 | 30301 | nameserver | 1 | 1 | SITE1 | hn1-db-1 |
30301 | 2 | SITE2 | YES | SYNC | ACTIVE | |
# | HN1 | hn1-db-0 | 30307 | xsengine | 2 | 1 | SITE1 | hn1-db-1 |
30307 | 2 | SITE2 | YES | SYNC | ACTIVE | |
# | NW1 | hn1-db-0 | 30340 | indexserver | 2 | 1 | SITE1 | hn1-db-1 |
30340 | 2 | SITE2 | YES | SYNC | ACTIVE | |
# | HN1 | hn1-db-0 | 30303 | indexserver | 3 | 1 | SITE1 | hn1-db-1 |
30303 | 2 | SITE2 | YES | SYNC | ACTIVE | |
#
# status system replication site "2": ACTIVE
# overall system replication status: ACTIVE
#
# Local System Replication State
# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#
# mode: PRIMARY
# site id: 1
# site name: SITE1

Configure A Replicação do Sistema SAP HANA 1.0


Os passos nesta secção utilizam os seguintes prefixos:
[A] : O passo aplica-se a todos os nós.
[1] : O passo aplica-se apenas ao nó 1.
[2] : O passo aplica-se apenas ao nó 2 do cluster Pacemaker.
1. [A] Configurar firewall
Crie regras de firewall para permitir a replicação do sistema HANA e o tráfego do cliente. As portas
necessárias estão listadas nas portas TCP/IP de todos os produtos SAP. Os seguintes comandos são
apenas um exemplo para permitir a replicação do sistema HANA 2.0. Adapte-o à sua instalação SAP
HANA 1.0.

sudo firewall-cmd --zone=public --add-port=40302/tcp --permanent


sudo firewall-cmd --zone=public --add-port=40302/tcp

2. [1] Criar os utilizadores necessários.


Executar o seguinte comando como raiz. Certifique-se de substituir as cordas arrojadas (HANA System ID
HN1 e a instância número 03 ) com os valores da sua instalação SAP HANA:

PATH="$PATH:/usr/sap/HN1/HDB03/exe"
hdbsql -u system -i 03 'CREATE USER hdbhasync PASSWORD "passwd"'
hdbsql -u system -i 03 'GRANT DATA ADMIN TO hdbhasync'
hdbsql -u system -i 03 'ALTER USER hdbhasync DISABLE PASSWORD LIFETIME'

3. [A] Criar a entrada na loja de chaves.


Executar o seguinte comando como raiz para criar uma nova entrada na keystore:

PATH="$PATH:/usr/sap/HN1/HDB03/exe"
hdbuserstore SET hdbhaloc localhost:30315 hdbhasync passwd

4. [1] Volte a subir na base de dados.


Volte a fazer as bases de dados como raiz:

PATH="$PATH:/usr/sap/HN1/HDB03/exe"
hdbsql -d SYSTEMDB -u system -i 03 "BACKUP DATA USING FILE ('initialbackup')"

Se utilizar uma instalação multi-arrendatária, também faça o back up da base de dados de inquilinos:

hdbsql -d HN1 -u system -i 03 "BACKUP DATA USING FILE ('initialbackup')"

5. [1] Configurar a replicação do sistema no primeiro nó.


Crie o local principal como <> hanasid adm:

su - hdbadm
hdbnsutil -sr_enable –-name=SITE1

6. [2] Configurar a replicação do sistema no nó secundário.


Registe o local secundário como <> hanasid adm:
HDB stop
hdbnsutil -sr_register --remoteHost=hn1-db-0 --remoteInstance=03 --replicationMode=sync --name=SITE2
HDB start

Criar um cluster Pacemaker


Siga os passos na configuração do Pacemaker no Red Hat Enterprise Linux em Azure para criar um cluster
pacemaker básico para este servidor HANA.

Criar recursos de cluster SAP HANA


Instale os agentes de recursos SAP HANA em todos os nós . Certifique-se de que ativa um repositório que
contenha a embalagem.

# Enable repository that contains SAP HANA resource agents


sudo subscription-manager repos --enable="rhel-sap-hana-for-rhel-7-server-rpms"

sudo yum install -y resource-agents-sap-hana

Em seguida, crie a topologia HANA. Executar os seguintes comandos num dos nós do cluster Pacemaker:

sudo pcs property set maintenance-mode=true

# Replace the bold string with your instance number and HANA system ID
sudo pcs resource create SAPHanaTopology_HN1_03 SAPHanaTopology SID=HN1 InstanceNumber=03 \
op start timeout=600 op stop timeout=300 op monitor interval=10 timeout=600 \
--clone clone-max=2 clone-node-max=1 interleave=true

Em seguida, crie os recursos HANA:

# Replace the bold string with your instance number, HANA system ID, and the front-end IP address of the
Azure load balancer.

sudo pcs resource create SAPHana_HN1_03 SAPHana SID=HN1 InstanceNumber=03 PREFER_SITE_TAKEOVER=true


DUPLICATE_PRIMARY_TIMEOUT=7200 AUTOMATED_REGISTER=false \
op start timeout=3600 op stop timeout=3600 \
op monitor interval=61 role="Slave" timeout=700 \
op monitor interval=59 role="Master" timeout=700 \
op promote timeout=3600 op demote timeout=3600 \
master notify=true clone-max=2 clone-node-max=1 interleave=true

sudo pcs resource create vip_HN1_03 IPaddr2 ip="10.0.0.13"

sudo pcs resource create nc_HN1_03 azure-lb port=62503

sudo pcs resource group add g_ip_HN1_03 nc_HN1_03 vip_HN1_03

sudo pcs constraint order SAPHanaTopology_HN1_03-clone then SAPHana_HN1_03-master symmetrical=false

sudo pcs constraint colocation add g_ip_HN1_03 with master SAPHana_HN1_03-master 4000

sudo pcs property set maintenance-mode=false

Certifique-se de que o estado do cluster está ok e que todos os recursos são iniciados. Não é importante em
que nó dos recursos estão a funcionar.
NOTE
Os intervalos na configuração acima são apenas exemplos e podem ter de ser adaptados à configuração específica da
HANA. Por exemplo, pode ser necessário aumentar o tempo de início, se demorar mais tempo a iniciar a base de dados
SAP HANA.

sudo pcs status

# Online: [ hn1-db-0 hn1-db-1 ]


#
# Full list of resources:
#
# azure_fence (stonith:fence_azure_arm): Started hn1-db-0
# Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03]
# Started: [ hn1-db-0 hn1-db-1 ]
# Master/Slave Set: SAPHana_HN1_03-master [SAPHana_HN1_03]
# Masters: [ hn1-db-0 ]
# Slaves: [ hn1-db-1 ]
# Resource Group: g_ip_HN1_03
# nc_HN1_03 (ocf::heartbeat:azure-lb): Started hn1-db-0
# vip_HN1_03 (ocf::heartbeat:IPaddr2): Started hn1-db-0

Testar a configuração do cluster


Esta secção descreve como pode testar a sua configuração. Antes de iniciar um teste, certifique-se de que o
Pacemaker não tem qualquer ação falhada (via estado do PC), não existem restrições de localização inesperadas
(por exemplo, restos de um teste de migração) e que hana é estado de sincronização, por exemplo com
sistemaReplicationStatus:

[root@hn1-db-0 ~]# sudo su - hn1adm -c "python


/usr/sap/HN1/HDB03/exe/python_support/systemReplicationStatus.py"

Testar a migração
Estado de recurso antes de iniciar o teste:

Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03]


Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: SAPHana_HN1_03-master [SAPHana_HN1_03]
Masters: [ hn1-db-0 ]
Slaves: [ hn1-db-1 ]
Resource Group: g_ip_HN1_03
nc_HN1_03 (ocf::heartbeat:azure-lb): Started hn1-db-0
vip_HN1_03 (ocf::heartbeat:IPaddr2): Started hn1-db-0

Pode migrar o nó mestre SAP HANA executando o seguinte comando:

[root@hn1-db-0 ~]# pcs resource move SAPHana_HN1_03-master

Se AUTOMATED_REGISTER="false" definir, este comando deve migrar o nó mestre SAP HANA e o grupo que
contém o endereço IP virtual para hn1-db-1.
Uma vez que a migração é feita, a saída 'sudo pcs status' parece-se com esta
Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03]
Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: SAPHana_HN1_03-master [SAPHana_HN1_03]
Masters: [ hn1-db-1 ]
Stopped: [ hn1-db-0 ]
Resource Group: g_ip_HN1_03
nc_HN1_03 (ocf::heartbeat:azure-lb): Started hn1-db-1
vip_HN1_03 (ocf::heartbeat:IPaddr2): Started hn1-db-1

O recurso SAP HANA no hn1-db-0 está parado. Neste caso, configure a instância HANA como secundária
executando este comando:

[root@hn1-db-0 ~]# su - hn1adm

# Stop the HANA instance just in case it is running


hn1adm@hn1-db-0:/usr/sap/HN1/HDB03> sapcontrol -nr 03 -function StopWait 600 10
hn1adm@hn1-db-0:/usr/sap/HN1/HDB03> hdbnsutil -sr_register --remoteHost=hn1-db-1 --remoteInstance=03 --
replicationMod
e=sync --name=SITE1

A migração cria constrangimentos de localização que precisam de ser novamente eliminados:

# Switch back to root


exit
[root@hn1-db-0 ~]# pcs resource clear SAPHana_HN1_03-master

Monitorize o estado do recurso HANA utilizando o 'estado do pcs'. Uma vez que HANA é iniciado em hn1-db-0,
a saída deve ser assim

Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03]


Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: SAPHana_HN1_03-master [SAPHana_HN1_03]
Masters: [ hn1-db-1 ]
Slaves: [ hn1-db-0 ]
Resource Group: g_ip_HN1_03
nc_HN1_03 (ocf::heartbeat:azure-lb): Started hn1-db-1
vip_HN1_03 (ocf::heartbeat:IPaddr2): Started hn1-db-1

Teste o agente de esgrima Azure


Estado de recurso antes de iniciar o teste:

Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03]


Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: SAPHana_HN1_03-master [SAPHana_HN1_03]
Masters: [ hn1-db-1 ]
Slaves: [ hn1-db-0 ]
Resource Group: g_ip_HN1_03
nc_HN1_03 (ocf::heartbeat:azure-lb): Started hn1-db-1
vip_HN1_03 (ocf::heartbeat:IPaddr2): Started hn1-db-1

Pode testar a configuração do agente de esgrima Azure desativando a interface de rede no nó onde o SAP
HANA está a funcionar como Mestre. Consulte o artigo 79523 da Base de Conhecimento do Chapéu Vermelho
para obter uma descrição sobre como simular uma falha de rede. Neste exemplo usamos o roteiro net_breaker
para bloquear todos os acessos à rede.
[root@hn1-db-1 ~]# sh ./net_breaker.sh BreakCommCmd 10.0.0.6

A máquina virtual deve agora reiniciar ou parar dependendo da configuração do seu cluster. Se definir a
stonith-action configuração para o desligado, a máquina virtual é parada e os recursos são migrados para a
máquina virtual em execução.
Depois de relançar a máquina virtual, o recurso SAP HANA não começa como secundário se definir
AUTOMATED_REGISTER="false" . Neste caso, configure a instância HANA como secundária executando este
comando:

su - hn1adm

# Stop the HANA instance just in case it is running


hn1adm@hn1-db-1:/usr/sap/HN1/HDB03> sapcontrol -nr 03 -function StopWait 600 10
hn1adm@hn1-db-1:/usr/sap/HN1/HDB03> hdbnsutil -sr_register --remoteHost=hn1-db-0 --remoteInstance=03 --
replicationMode=sync --name=SITE2

# Switch back to root and clean up the failed state


exit
[root@hn1-db-1 ~]# pcs resource cleanup SAPHana_HN1_03-master

Estado de recurso após o teste:

Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03]


Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: SAPHana_HN1_03-master [SAPHana_HN1_03]
Masters: [ hn1-db-0 ]
Slaves: [ hn1-db-1 ]
Resource Group: g_ip_HN1_03
nc_HN1_03 (ocf::heartbeat:azure-lb): Started hn1-db-0
vip_HN1_03 (ocf::heartbeat:IPaddr2): Started hn1-db-0

Teste uma falha manual


Estado de recurso antes de iniciar o teste:

Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03]


Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: SAPHana_HN1_03-master [SAPHana_HN1_03]
Masters: [ hn1-db-0 ]
Slaves: [ hn1-db-1 ]
Resource Group: g_ip_HN1_03
nc_HN1_03 (ocf::heartbeat:azure-lb): Started hn1-db-0
vip_HN1_03 (ocf::heartbeat:IPaddr2): Started hn1-db-0

Pode testar uma falha manual parando o cluster no nó hn1-db-0:

[root@hn1-db-0 ~]# pcs cluster stop

Depois da falha, podes recomeçar o agrupamento. Se AUTOMATED_REGISTER="false" definir, o recurso SAP HANA
no nó hn1-db-0 não começa como secundário. Neste caso, configure a instância HANA como secundária
executando este comando:
[root@hn1-db-0 ~]# pcs cluster start
[root@hn1-db-0 ~]# su - hn1adm

# Stop the HANA instance just in case it is running


hn1adm@hn1-db-0:/usr/sap/HN1/HDB03> sapcontrol -nr 03 -function StopWait 600 10
hn1adm@hn1-db-0:/usr/sap/HN1/HDB03> hdbnsutil -sr_register --remoteHost=hn1-db-1 --remoteInstance=03 --
replicationMode=sync --name=SITE1

# Switch back to root and clean up the failed state


hn1adm@hn1-db-0:/usr/sap/HN1/HDB03> exit
[root@hn1-db-1 ~]# pcs resource cleanup SAPHana_HN1_03-master

Estado de recurso após o teste:

Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03]


Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: SAPHana_HN1_03-master [SAPHana_HN1_03]
Masters: [ hn1-db-1 ]
Slaves: [ hn1-db-0 ]
Resource Group: g_ip_HN1_03
nc_HN1_03 (ocf::heartbeat:azure-lb): Started hn1-db-1
vip_HN1_03 (ocf::heartbeat:IPaddr2): Started hn1-db-1

Teste uma falha manual


Estado de recurso antes de iniciar o teste:

Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03]


Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: SAPHana_HN1_03-master [SAPHana_HN1_03]
Masters: [ hn1-db-0 ]
Slaves: [ hn1-db-1 ]
Resource Group: g_ip_HN1_03
nc_HN1_03 (ocf::heartbeat:azure-lb): Started hn1-db-0
vip_HN1_03 (ocf::heartbeat:IPaddr2): Started hn1-db-0

Pode testar uma falha manual parando o cluster no nó hn1-db-0:

[root@hn1-db-0 ~]# pcs cluster stop

Passos seguintes
Planeamento e implementação de Máquinas Virtuais Azure para SAP
Implantação de Máquinas Virtuais Azure para SAP
Implantação de DBMS de Máquinas Virtuais Azure para SAP
Configurações de armazenamento VM SAP HANA
Verifique e coloque problemas na configuração de
alta disponibilidade da SAP HANA no SLES 12 SP3
29/04/2020 • 46 minutes to read • Edit Online

Este artigo ajuda-o a verificar a configuração do cluster Pacemaker para a escala SAP HANA que funciona em
máquinas virtuais Azure (VMs). A configuração do cluster foi realizada em combinação com a Replicação do
Sistema SAP HANA (HSR) e o pacote SUSE RPM SAPHanaSR-ScaleOut. Todos os testes foram feitos apenas em
SUSE SLES 12 SP3. As secções do artigo abrangem diferentes áreas e incluem comandos de amostra e excertos de
ficheiros config. Recomendamos estas amostras como um método para verificar e verificar toda a configuração do
cluster.

Notas importantes
Todos os testes para sap HANA scale-out em combinação com a Replicação do Sistema SAP HANA e Pacemaker foi
feito apenas com SAP HANA 2.0. A versão do sistema operativo foi SUSE Linux Enterprise Server 12 SP3 para
aplicações SAP. O mais recente pacote RPM, SAPHanaSR-ScaleOut da SUSE, foi usado para configurar o cluster
Pacemaker. A SUSE publicou uma descrição detalhada desta configuração otimizadapelo desempenho.
Para tipos de máquinas virtuais suportados para escala SAP HANA, consulte o diretório IaaS certificado sAP HANA.
Houve um problema técnico com a escala SAP HANA em combinação com várias subredes e vNICs e a criação de
HSR. É obrigatório usar os mais recentes patches SAP HANA 2.0 onde este problema foi corrigido. As seguintes
versões SAP HANA são suportadas:
rev2.00.024.04 ou superior
rev2.00.032 ou superior
Se precisar de apoio da SUSE, siga este guia. Recolher todas as informações sobre o cluster de alta disponibilidade
(HA) da SAP HANA, conforme descrito no artigo. O suporte da SUSE necessita desta informação para uma análise
mais aprofundada.
Durante os testes internos, a configuração do cluster ficou confusa com uma paragem normal e graciosa de VM
através do portal Azure. Por isso, recomendamos que teste um cluster falhapor outros métodos. Use métodos
como forçar o pânico do núcleo, ou desligar as redes ou migrar o recurso msl. Consulte os detalhes nas seguintes
secções. O pressuposto é que uma paralisação padrão acontece com intenção. O melhor exemplo de uma paragem
intencional é a manutenção. Consulte os detalhes na manutenção planeada.
Além disso, durante os testes internos, a configuração do cluster ficou confusa após uma aquisição manual do SAP
HANA enquanto o cluster estava em modo de manutenção. Recomendamos que volte a ligá-lo manualmente antes
de terminar o modo de manutenção do cluster. Outra opção é desencadear uma falha antes de colocar o cluster no
modo de manutenção. Para mais informações, consulte a manutenção planeada. A documentação da SUSE
descreve como pode redefinir o cluster desta forma utilizando o comando crm. Mas a abordagem mencionada
anteriormente foi robusta durante os testes internos e nunca mostrou quaisquer efeitos colaterais inesperados.
Quando utilizar o comando de migração de crm, certifique-se de limpar a configuração do cluster. Acrescenta
constrangimentos de localização que pode não ter conhecimento. Estes constrangimentos afetam o
comportamento do cluster. Veja mais detalhes na manutenção planeada.

Descrição do sistema de teste


Para a verificação e certificação de HA em escala SAP HANA, foi utilizada uma configuração. Consistia em dois
sistemas com três nós SAP HANA cada: um mestre e dois trabalhadores. A tabela seguinte lista os nomes vm e
endereços IP internos. Todas as amostras de verificação que se seguem foram feitas nestes VMs. Ao utilizar estes
nomes vm e endereços IP nas amostras de comando, pode compreender melhor os comandos e as suas saídas:

T IP O DE N Ó O N O M E DA VM EN DEREÇ O IP

Nó mestre no local 1 hso-hana-vm-s1-0 10.0.0.30

Nó operário 1 no local 1 hso-hana-vm-s1-1 10.0.0.31

Nó de trabalhador 2 no local 1 hso-hana-vm-s1-2 10.0.0.32

Nó mestre no local 2 hso-hana-vm-s2-0 10.0.0.40

Nó operário 1 no local 2 hso-hana-vm-s2-1 10.0.0.41

Nó de trabalhador 2 no local 2 hso-hana-vm-s2-2 10.0.0.42

Nó de fabricante maioritário hso-hana-dm 10.0.0.13

Servidor de dispositivo SBD hso-hana-sbd 10.0.0.19

Servidor NFS 1 hso-nfs-vm-0 10.0.0.15

Servidor NFS 2 hso-nfs-vm-1 10.0.0.14

Múltiplas subredes e vNICs


Seguindo as recomendações da rede SAP HANA, três subnets foram criadas dentro de uma rede virtual Azure. A
escala SAP HANA no Azure tem de ser instalada em modo não partilhado. Isto significa que cada nó utiliza volumes
de disco locais para /hana/data e /hana/log . Como os nós usam apenas volumes de disco locais, não é
necessário definir uma subnet separada para armazenamento:
10.0.2.0/24 para comunicação interna da SAP HANA
10.0.1.0/24 para a replicação do sistema SAP HANA (HSR)
10.0.0.0.0/24 para tudo o resto
Para obter informações sobre a configuração do SAP HANA relacionada com a utilização de várias redes, consulte o
SAP HANA global.ini.
Cada VM do cluster tem três vNICs que correspondem ao número de subredes. Como criar uma máquina virtual
Linux em Azure com vários cartões de interface de rede descreve um potencial problema de encaminhamento no
Azure ao implementar um VM Linux. Este artigo de encaminhamento específico aplica-se apenas para utilização de
múltiplos vNICs. O problema é resolvido pela SUSE por padrão no SLES 12 SP3. Para mais informações, consulte
Multi-NIC com cloud-netconfig em EC2 e Azure.
Para verificar se o SAP HANA está configurado corretamente para utilizar várias redes, execute os seguintes
comandos. Primeiro verifique no nível de Os que os três endereços IP internos para as três subredes estão ativos.
Se definiu as subredes com diferentes gamas de endereços IP, tem de adaptar os comandos:
ifconfig | grep "inet addr:10\."

A saída da amostra que se segue é do segundo nó de trabalhador no local 2. Você pode ver três diferentes
endereços IP internos de eth0, eth1 e eth2:

inet addr:10.0.0.42 Bcast:10.0.0.255 Mask:255.255.255.0


inet addr:10.0.1.42 Bcast:10.0.1.255 Mask:255.255.255.0
inet addr:10.0.2.42 Bcast:10.0.2.255 Mask:255.255.255.0

Em seguida, verifique as portas SAP HANA para o servidor de nome e HSR. O SAP HANA deve ouvir as subredes
correspondentes. Dependendo do número da instância SAP HANA, tem de adaptar os comandos. Para o sistema de
teste, o número da instância era 00 . Existem diferentes formas de descobrir quais os portos utilizados.
A seguinte declaração sQL devolve a instância ID, número de instância e outras informações:

select * from "SYS"."M_SYSTEM_OVERVIEW"

Para encontrar os números de porta corretos, pode procurar, por exemplo, no Estúdio HANA sob Configuração ou
através de uma declaração SQL:

select * from M_INIFILE_CONTENTS WHERE KEY LIKE 'listen%'

Para encontrar todas as portas utilizadas na pilha de software SAP, incluindo SAP HANA, procure portas TCP/IP de
todos os produtos SAP.
Dada a instância número 00 no sistema de teste SAP HANA 2.0, o número de porta do servidor de nome é 30001 .
O número da porta para a comunicação de metadados HSR é 40002 . Uma opção é iniciar sessão com um nó de
trabalhador e, em seguida, verificar os serviços de nó do mestre. Para este artigo, verificamos o nó de trabalhador 2
no local 2 tentando ligar-se ao nó principal no local 2.
Verifique a porta do servidor de nomes:

nc -vz 10.0.0.40 30001


nc -vz 10.0.1.40 30001
nc -vz 10.0.2.40 30001

Para provar que a comunicação internode utiliza a sub-rede 10.0.2.0/24, o resultado deve parecer a seguinte
saída de amostra. Só a ligação através da sub-rede 10.0.2.0/24 deve ter êxito:

nc: connect to 10.0.0.40 port 30001 (tcp) failed: Connection refused


nc: connect to 10.0.1.40 port 30001 (tcp) failed: Connection refused
Connection to 10.0.2.40 30001 port [tcp/pago-services1] succeeded!

Verifique agora a porta HSR 40002:


nc -vz 10.0.0.40 40002
nc -vz 10.0.1.40 40002
nc -vz 10.0.2.40 40002

Para provar que a comunicação HSR utiliza a sub-rede 10.0.1.0/24, o resultado deve parecer a seguinte saída da
amostra. Só a ligação através da sub-rede 10.0.1.0/24 deve ter êxito:

nc: connect to 10.0.0.40 port 40002 (tcp) failed: Connection refused


Connection to 10.0.1.40 40002 port [tcp/*] succeeded!
nc: connect to 10.0.2.40 port 40002 (tcp) failed: Connection refused

Corosinso
O ficheiro de config corosinso tem de estar correto em todos os nós do cluster, incluindo o nó de fabricante
maioritário. Se a adesão do cluster a um nó não funcionar como esperado, crie ou copie
/etc/corosync/corosync.conf manualmente sobre todos os nós e reinicie o serviço.
O conteúdo de corosync.conf do sistema de teste é um exemplo.
A primeira secção é totem , como descrito na instalação do Cluster, passo 11. Pode ignorar o valor para o
mcastaddr. Basta manter a entrada existente. As inscrições para ficha e consenso devem ser definidas de acordo
com a documentação microsoft Azure SAP HANA.

totem {
version: 2
secauth: on
crypto_hash: sha1
crypto_cipher: aes256
cluster_name: hacluster
clear_node_high_bit: yes

token: 30000
token_retransmits_before_loss_const: 10
join: 60
consensus: 36000
max_messages: 20

interface {
ringnumber: 0
bindnetaddr: 10.0.0.0
mcastaddr: 239.170.19.232
mcastport: 5405

ttl: 1
}
transport: udpu

A segunda secção, a exploração madeireira, não foi alterada dos defeitos dado:
logging {
fileline: off
to_stderr: no
to_logfile: no
logfile: /var/log/cluster/corosync.log
to_syslog: yes
debug: off
timestamp: on
logger_subsys {
subsys: QUORUM
debug: off
}
}

A terceira secção mostra a lista de nodelistas. Todos os nós do aglomerado têm que aparecer com o seu
nódeideide:

nodelist {
node {
ring0_addr:hso-hana-vm-s1-0
nodeid: 1
}
node {
ring0_addr:hso-hana-vm-s1-1
nodeid: 2
}
node {
ring0_addr:hso-hana-vm-s1-2
nodeid: 3
}
node {
ring0_addr:hso-hana-vm-s2-0
nodeid: 4
}
node {
ring0_addr:hso-hana-vm-s2-1
nodeid: 5
}
node {
ring0_addr:hso-hana-vm-s2-2
nodeid: 6
}
node {
ring0_addr:hso-hana-dm
nodeid: 7
}
}

Na última secção, quórum, é importante definir o valor para expected_votes corretamente. Deve ser o número
de nós, incluindo o nó da maioria. E o valor para two_node tem de ser 0. Não retire completamente a entrada.
Basta definir o valor para 0 .

quorum {
# Enable and configure quorum subsystem (default: off)
# see also corosync.conf.5 and votequorum.5
provider: corosync_votequorum
expected_votes: 7
two_node: 0
}
Reiniciar o serviço via systemctl:

systemctl restart corosync

Dispositivo SBD
Como configurar um dispositivo SBD num VM Azure é descrito em esgrima SBD.
Primeiro, verifique o VM do servidor SBD se houver entradas ACL para cada nó do cluster. Executar o seguinte
comando no VM do servidor SBD:

targetcli ls

No sistema de teste, a saída do comando parece a seguinte amostra. Os nomes da ACL como iqn.2006-04.hso-
db-0.local:hso-db-0 devem ser inscritos como os nomes de iniciador correspondentes nos VMs. Cada VM
precisa de um diferente.
| | o- sbddbhso ................................................................... [/sbd/sbddbhso (50.0MiB)
write-thru activated]
| | o- alua
................................................................................................... [ALUA
Groups: 1]
| | o- default_tg_pt_gp ....................................................................... [ALUA
state: Active/optimized]
| o- pscsi ..................................................................................................
[Storage Objects: 0]
| o- ramdisk ................................................................................................
[Storage Objects: 0]
o- iscsi
............................................................................................................
[Targets: 1]
| o- iqn.2006-04.dbhso.local:dbhso
..................................................................................... [TPGs: 1]
| o- tpg1 ...............................................................................................
[no-gen-acls, no-auth]
| o- acls
..........................................................................................................
[ACLs: 7]
| | o- iqn.2006-04.hso-db-0.local:hso-db-0
.................................................................. [Mapped LUNs: 1]
| | | o- mapped_lun0 ............................................................................. [lun0
fileio/sbddbhso (rw)]
| | o- iqn.2006-04.hso-db-1.local:hso-db-1
.................................................................. [Mapped LUNs: 1]
| | | o- mapped_lun0 ............................................................................. [lun0
fileio/sbddbhso (rw)]
| | o- iqn.2006-04.hso-db-2.local:hso-db-2
.................................................................. [Mapped LUNs: 1]
| | | o- mapped_lun0 ............................................................................. [lun0
fileio/sbddbhso (rw)]
| | o- iqn.2006-04.hso-db-3.local:hso-db-3
.................................................................. [Mapped LUNs: 1]
| | | o- mapped_lun0 ............................................................................. [lun0
fileio/sbddbhso (rw)]
| | o- iqn.2006-04.hso-db-4.local:hso-db-4
.................................................................. [Mapped LUNs: 1]
| | | o- mapped_lun0 ............................................................................. [lun0
fileio/sbddbhso (rw)]
| | o- iqn.2006-04.hso-db-5.local:hso-db-5
.................................................................. [Mapped LUNs: 1]
| | | o- mapped_lun0 ............................................................................. [lun0
fileio/sbddbhso (rw)]
| | o- iqn.2006-04.hso-db-6.local:hso-db-6
.................................................................. [Mapped LUNs: 1]

Em seguida, verifique se os nomes do iniciador em todos os VMs são diferentes e correspondem às entradas
anteriormente mostradas. Este exemplo é do nó 1 do trabalhador no local 1:

cat /etc/iscsi/initiatorname.iscsi

A saída parece a seguinte amostra:


##
## /etc/iscsi/iscsi.initiatorname
##
## Default iSCSI Initiatorname.
##
## DO NOT EDIT OR REMOVE THIS FILE!
## If you remove this file, the iSCSI daemon will not start.
## If you change the InitiatorName, existing access control lists
## may reject this initiator. The InitiatorName must be unique
## for each iSCSI initiator. Do NOT duplicate iSCSI InitiatorNames.
InitiatorName=iqn.2006-04.hso-db-1.local:hso-db-1

Em seguida, verifique se a descober ta funciona corretamente. Executar o seguinte comando em cada nó de cluster
utilizando o endereço IP do VM do servidor SBD:

iscsiadm -m discovery --type=st --portal=10.0.0.19:3260

A saída deve parecer a seguinte amostra:

10.0.0.19:3260,1 iqn.2006-04.dbhso.local:dbhso

O próximo ponto de prova é verificar se o nó vê o dispositivo SDB. Verifique em cada nó, incluindo o nó de
fabricante maioritário:

lsscsi | grep dbhso

A saída deve parecer a seguinte amostra. No entanto, os nomes podem diferir. O nome do dispositivo também
pode mudar após o vM reiniciar:

[6:0:0:0] disk LIO-ORG sbddbhso 4.0 /dev/sdm

Dependendo do estado do sistema, por vezes ajuda a reiniciar os serviços iSCSI para resolver problemas. Em
seguida, execute os seguintes comandos:

systemctl restart iscsi


systemctl restart iscsid

De qualquer nó, pode verificar se todos os nós estão limpos. Certifique-se de que utiliza o nome do dispositivo
correto num nó específico:

sbd -d /dev/sdm list

A saída deve ser clara para cada nó do cluster:


0 hso-hana-vm-s1-0 clear
1 hso-hana-vm-s2-2 clear
2 hso-hana-vm-s2-1 clear
3 hso-hana-dm clear
4 hso-hana-vm-s1-1 clear
5 hso-hana-vm-s2-0 clear
6 hso-hana-vm-s1-2 clear

Outra verificação SBD é a opção de despejo do comando sbd. Nesta amostra de comando e saída do nó de
fabricante maioritário, o nome do dispositivo foi sdd , não sdm :

sbd -d /dev/sdd dump

A saída, para além do nome do dispositivo, deve ser a mesma em todos os nós:

==Dumping header on disk /dev/sdd


Header version : 2.1
UUID : 9fa6cc49-c294-4f1e-9527-c973f4d5a5b0
Number of slots : 255
Sector size : 512
Timeout (watchdog) : 60
Timeout (allocate) : 2
Timeout (loop) : 1
Timeout (msgwait) : 120
==Header on disk /dev/sdd is dumped

Mais uma verificação para o SBD é a possibilidade de enviar uma mensagem para outro nó. Para enviar uma
mensagem ao nó 2 do trabalhador no local 2, execute o seguinte comando no nó 1 do trabalhador no local 2:

sbd -d /dev/sdm message hso-hana-vm-s2-2 test

No lado vm alvo, hso-hana-vm-s2-2 neste exemplo, pode encontrar a seguinte entrada em /var/log/messages:

/dev/disk/by-id/scsi-36001405e614138d4ec64da09e91aea68: notice: servant: Received command test from hso-hana-


vm-s2-1 on disk /dev/disk/by-id/scsi-36001405e614138d4ec64da09e91aea68

Verifique se as entradas em /etc/sysconfig/sbd correspondem à descrição na configuração do Pacemaker no


SUSE Linux Enterprise Server em Azure. Verifique se a configuração de arranque em /etc/iscsid.conf está definida
como automática.
As seguintes entradas são importantes em /etc/sysconfig/sbd . Adaptar o valor da id se necessário:

SBD_DEVICE="/dev/disk/by-id/scsi-36001405e614138d4ec64da09e91aea68;"
SBD_PACEMAKER=yes
SBD_STARTMODE=always
SBD_WATCHDOG=yes

Verifique a definição de arranque em /etc/iscsid.conf . A definição necessária deveria ter acontecido com o
seguinte comando IScsiadm, descrito na documentação. Verifique e adapte manualmente com vi se é diferente.
Este comando define o comportamento da startup:

iscsiadm -m node --op=update --name=node.startup --value=automatic

Faça esta inscrição em /etc/iscsid.conf :

node.startup = automatic

Durante os testes e verificação, após o reinício de um VM, o dispositivo SBD já não era visível em alguns casos.
Houve uma discrepância entre o cenário de arranque e o que o YaST2 mostrou. Para verificar as definições, tome
estas medidas:
1. Começa o YaST2.
2. Selecione Ser viços de Rede no lado esquerdo.
3. Desloque-se para baixo no lado direito para o ISCSI Initiator e selecione-o.
4. No ecrã seguinte sob o separador Ser viço, você vê o nome único do iniciador para o nó.
5. Acima do nome do iniciador, certifique-se de que o valor de início de ser viço está definido para Quando
Iniciar .
6. Se não for, coloque-o no "When Booting" em vez de Manualmente .
7. Em seguida, mude o separador superior para Alvos Conectados .
8. No ecrã 'Alvos Conectados', deve ver uma entrada para o dispositivo SBD como esta amostra:
10.0.0.19:3260 iqn.2006-04.dbhso.local:dbhso .
9. Verifique se o valor de arranque está definido no arranque .
10. Caso contrário, escolha Editar e troque-o.
11. Guarde as alterações e saia yaST2.

Pacemaker
Depois de tudo estar configurado corretamente, pode executar o seguinte comando em cada nó para verificar o
estado do serviço Pacemaker:

systemctl status pacemaker

A parte superior da saída deve parecer a seguinte amostra. É importante que o estado após o Ative seja mostrado
como carregado e ativo (em execução) . O estado após o Loaded deve ser mostrado como ativado .
pacemaker.service - Pacemaker High Availability Cluster Manager
Loaded: loaded (/usr/lib/systemd/system/pacemaker.service; enabled; vendor preset: disabled)
Active: active (running) since Fri 2018-09-07 05:56:27 UTC; 4 days ago
Docs: man:pacemakerd
http://clusterlabs.org/doc/en-US/Pacemaker/1.1-pcs/html/Pacemaker_Explained/index.html
Main PID: 4496 (pacemakerd)
Tasks: 7 (limit: 4915)
CGroup: /system.slice/pacemaker.service
├─4496 /usr/sbin/pacemakerd -f
├─4499 /usr/lib/pacemaker/cib
├─4500 /usr/lib/pacemaker/stonithd
├─4501 /usr/lib/pacemaker/lrmd
├─4502 /usr/lib/pacemaker/attrd
├─4503 /usr/lib/pacemaker/pengine
└─4504 /usr/lib/pacemaker/crmd

Se a regulação ainda estiver desativada, execute o seguinte comando:

systemctl enable pacemaker

Para ver todos os recursos configurados no Pacemaker, executar o seguinte comando:

crm status

A saída deve parecer a seguinte amostra. É bom que os recursos cln e msl sejam mostrados como parados na
maioria do fabricante VM, hso-hana-dm . Não há instalação SAP HANA no nó da maioria. Assim, os recursos da
CLN e da MSL são mostrados como parados. É importante que mostre o número total correto de VMs, 7 . Todos os
VMs que fazem parte do cluster devem ser listados com o estado Online . O atual nó principal deve ser
reconhecido corretamente. Neste exemplo, é hso-hana-vm-s1-0:

Stack: corosync
Current DC: hso-hana-dm (version 1.1.16-4.8-77ea74d) - partition with quorum
Last updated: Tue Sep 11 15:56:40 2018
Last change: Tue Sep 11 15:56:23 2018 by root via crm_attribute on hso-hana-vm-s1-0

7 nodes configured
17 resources configured

Online: [ hso-hana-dm hso-hana-vm-s1-0 hso-hana-vm-s1-1 hso-hana-vm-s1-2 hso-hana-vm-s2-0 hso-hana-vm-s2-1 hso-


hana-vm-s2-2 ]

Full list of resources:

stonith-sbd (stonith:external/sbd): Started hso-hana-dm


Clone Set: cln_SAPHanaTop_HSO_HDB00 [rsc_SAPHanaTop_HSO_HDB00]
Started: [ hso-hana-vm-s1-0 hso-hana-vm-s1-1 hso-hana-vm-s1-2 hso-hana-vm-s2-0 hso-hana-vm-s2-1 hso-hana-
vm-s2-2 ]
Stopped: [ hso-hana-dm ]
Master/Slave Set: msl_SAPHanaCon_HSO_HDB00 [rsc_SAPHanaCon_HSO_HDB00]
Masters: [ hso-hana-vm-s1-0 ]
Slaves: [ hso-hana-vm-s1-1 hso-hana-vm-s1-2 hso-hana-vm-s2-0 hso-hana-vm-s2-1 hso-hana-vm-s2-2 ]
Stopped: [ hso-hana-dm ]
Resource Group: g_ip_HSO_HDB00
rsc_ip_HSO_HDB00 (ocf::heartbeat:IPaddr2): Started hso-hana-vm-s1-0
rsc_nc_HSO_HDB00 (ocf::heartbeat:anything): Started hso-hana-vm-s1-0
Uma característica importante do Pacemaker é o modo de manutenção. Neste modo, pode fazer modificações sem
provocar uma ação imediata do cluster. Um exemplo é um reboot vm. Um caso de utilização típica seria planejado
manutenção de infraestruturas DE Os ou Azure. Ver Manutenção Planeada. Utilize o seguinte comando para colocar
o Pacemaker no modo de manutenção:

crm configure property maintenance-mode=true

Quando verificar com o estado do CRM, nota na saída que todos os recursos estão marcados como não
geridos . Neste estado, o cluster não reage a quaisquer mudanças como iniciar ou parar o SAP HANA. A amostra
seguinte mostra a saída do comando de estado crm enquanto o cluster está no modo de manutenção:

Stack: corosync
Current DC: hso-hana-dm (version 1.1.16-4.8-77ea74d) - partition with quorum
Last updated: Wed Sep 12 07:48:10 2018
Last change: Wed Sep 12 07:46:54 2018 by root via cibadmin on hso-hana-vm-s2-1

7 nodes configured
17 resources configured

*** Resource management is DISABLED ***


The cluster will not attempt to start, stop or recover services

Online: [ hso-hana-dm hso-hana-vm-s1-0 hso-hana-vm-s1-1 hso-hana-vm-s1-2 hso-hana-vm-s2-0 hso-hana-vm-s2-1 hso-


hana-vm-s2-2 ]

Full list of resources:

stonith-sbd (stonith:external/sbd): Started hso-hana-dm (unmanaged)


Clone Set: cln_SAPHanaTop_HSO_HDB00 [rsc_SAPHanaTop_HSO_HDB00] (unmanaged)
rsc_SAPHanaTop_HSO_HDB00 (ocf::suse:SAPHanaTopology): Started hso-hana-vm-s1-1 (unmanaged)
rsc_SAPHanaTop_HSO_HDB00 (ocf::suse:SAPHanaTopology): Started hso-hana-vm-s1-0 (unmanaged)
rsc_SAPHanaTop_HSO_HDB00 (ocf::suse:SAPHanaTopology): Started hso-hana-vm-s1-2 (unmanaged)
rsc_SAPHanaTop_HSO_HDB00 (ocf::suse:SAPHanaTopology): Started hso-hana-vm-s2-1 (unmanaged)
rsc_SAPHanaTop_HSO_HDB00 (ocf::suse:SAPHanaTopology): Started hso-hana-vm-s2-2 (unmanaged)
rsc_SAPHanaTop_HSO_HDB00 (ocf::suse:SAPHanaTopology): Started hso-hana-vm-s2-0 (unmanaged)
Stopped: [ hso-hana-dm ]
Master/Slave Set: msl_SAPHanaCon_HSO_HDB00 [rsc_SAPHanaCon_HSO_HDB00] (unmanaged)
rsc_SAPHanaCon_HSO_HDB00 (ocf::suse:SAPHanaController): Slave hso-hana-vm-s1-1 (unmanaged)
rsc_SAPHanaCon_HSO_HDB00 (ocf::suse:SAPHanaController): Slave hso-hana-vm-s1-2 (unmanaged)
rsc_SAPHanaCon_HSO_HDB00 (ocf::suse:SAPHanaController): Slave hso-hana-vm-s2-1 (unmanaged)
rsc_SAPHanaCon_HSO_HDB00 (ocf::suse:SAPHanaController): Slave hso-hana-vm-s2-2 (unmanaged)
rsc_SAPHanaCon_HSO_HDB00 (ocf::suse:SAPHanaController): Master hso-hana-vm-s2-0 (unmanaged)
Stopped: [ hso-hana-dm hso-hana-vm-s1-0 ]
Resource Group: g_ip_HSO_HDB00
rsc_ip_HSO_HDB00 (ocf::heartbeat:IPaddr2): Started hso-hana-vm-s2-0 (unmanaged)
rsc_nc_HSO_HDB00 (ocf::heartbeat:anything): Started hso-hana-vm-s2-0 (unmanaged)

Esta amostra de comando mostra como terminar o modo de manutenção do cluster:

crm configure property maintenance-mode=false

Outro comando crm obtém a configuração completa do cluster em um editor, para que você possa editá-lo. Depois
de poupar as alterações, o cluster inicia as ações apropriadas:

crm configure edit


Para ver a configuração completa do cluster, use a opção crm show:

crm configure show

Após falhas nos recursos de cluster, o comando do estado do CRM mostra uma lista de Ações Falhadas .
Consulte a seguinte amostra desta saída:

Stack: corosync
Current DC: hso-hana-dm (version 1.1.16-4.8-77ea74d) - partition with quorum
Last updated: Thu Sep 13 07:30:44 2018
Last change: Thu Sep 13 07:30:20 2018 by root via crm_attribute on hso-hana-vm-s1-0

7 nodes configured
17 resources configured

Online: [ hso-hana-dm hso-hana-vm-s1-0 hso-hana-vm-s1-1 hso-hana-vm-s1-2 hso-hana-vm-s2-0 hso-hana-vm-s2-1 hso-


hana-vm-s2-2 ]

Full list of resources:

stonith-sbd (stonith:external/sbd): Started hso-hana-dm


Clone Set: cln_SAPHanaTop_HSO_HDB00 [rsc_SAPHanaTop_HSO_HDB00]
Started: [ hso-hana-vm-s1-0 hso-hana-vm-s1-1 hso-hana-vm-s1-2 hso-hana-vm-s2-0 hso-hana-vm-s2-1 hso-hana-
vm-s2-2 ]
Stopped: [ hso-hana-dm ]
Master/Slave Set: msl_SAPHanaCon_HSO_HDB00 [rsc_SAPHanaCon_HSO_HDB00]
Masters: [ hso-hana-vm-s1-0 ]
Slaves: [ hso-hana-vm-s1-1 hso-hana-vm-s1-2 hso-hana-vm-s2-1 hso-hana-vm-s2-2 ]
Stopped: [ hso-hana-dm hso-hana-vm-s2-0 ]
Resource Group: g_ip_HSO_HDB00
rsc_ip_HSO_HDB00 (ocf::heartbeat:IPaddr2): Started hso-hana-vm-s1-0
rsc_nc_HSO_HDB00 (ocf::heartbeat:anything): Started hso-hana-vm-s1-0

Failed Actions:
* rsc_SAPHanaCon_HSO_HDB00_monitor_60000 on hso-hana-vm-s2-0 'unknown error' (1): call=86, status=complete,
exitreason='none',
last-rc-change='Wed Sep 12 17:01:28 2018', queued=0ms, exec=277663ms

É necessário fazer uma limpeza de cluster depois de falhas. Use novamente o comando crm e utilize a limpeza da
opção de comando para se livrar destas entradas de ação falhadas. Nomeie o recurso de cluster correspondente da
seguinte forma:

crm resource cleanup rsc_SAPHanaCon_HSO_HDB00

O comando deve devolver a saída como a seguinte amostra:

Cleaned up rsc_SAPHanaCon_HSO_HDB00:0 on hso-hana-dm


Cleaned up rsc_SAPHanaCon_HSO_HDB00:0 on hso-hana-vm-s1-0
Cleaned up rsc_SAPHanaCon_HSO_HDB00:0 on hso-hana-vm-s1-1
Cleaned up rsc_SAPHanaCon_HSO_HDB00:0 on hso-hana-vm-s1-2
Cleaned up rsc_SAPHanaCon_HSO_HDB00:0 on hso-hana-vm-s2-0
Cleaned up rsc_SAPHanaCon_HSO_HDB00:0 on hso-hana-vm-s2-1
Cleaned up rsc_SAPHanaCon_HSO_HDB00:0 on hso-hana-vm-s2-2
Waiting for 7 replies from the CRMd....... OK
Falha ou aquisição
Como discutido em notas importantes,não deve utilizar uma paragem graciosa padrão para testar o failover do
cluster ou a aquisição de SAP HANA HSR. Em vez disso, recomendamos que desencadeie um pânico de kernel,
force uma migração de recursos, ou possivelmente desligue todas as redes no nível de SO de um VM. Outro
método é o comando de ** <> nímio de nímio de crm.** Consulte o documento SUSE.
Os seguintes três comandos de amostra podem forçar uma falha de aglomerado:

echo c > /proc/sysrq-trigger

crm resource migrate msl_SAPHanaCon_HSO_HDB00 hso-hana-vm-s2-0 force

wicked ifdown eth0


wicked ifdown eth1
wicked ifdown eth2
......
wicked ifdown eth<n>

Como descrito na manutenção planeada,uma boa maneira de monitorizar as atividades de cluster é executar
SAPHanaSR-showAttr com o comando do relógio:

watch SAPHanaSR-showAttr

Também ajuda a olhar para o estado da paisagem SAP HANA vindo de um script SAP Python. A configuração do
cluster está à procura deste valor de estado. Torna-se claro quando se pensa numa falha no nó dos trabalhadores.
Se um nó de trabalhador cair, o SAP HANA não devolve imediatamente um erro para a saúde de todo o sistema de
escala.
Há algumas tentativas para evitar falhas desnecessárias. O cluster só reage se o estado mudar de Ok , valor de
retorno 4, a erro, valor de retorno 1 . Portanto, é correto se a saída do SAPHanaSR-showAttr mostrar um VM
com o estado offline . Mas ainda não há atividade para mudar o primário e o secundário. Nenhuma atividade de
cluster é desencadeada desde que o SAP HANA não devolva um erro.
Pode monitorizar o estado de saúde da paisagem SAP HANA como utilizador ** <HANA>SID adm,** chamando o
script SAP Python da seguinte forma. Talvez tenha supor adaptar o caminho:

watch python
/hana/shared/HSO/exe/linuxx86_64/HDB_2.00.032.00.1533114046_eeaf4723ec52ed3935ae0dc9769c9411ed73fec5/python_sup
port/landscapeHostConfiguration.py

A saída deste comando deve parecer a seguinte amostra. A coluna estado do anfitrião e o estatuto de
hospedeiro geral são importantes. A saída real é mais larga, com colunas adicionais. Para tornar a tabela de saída
mais legível dentro deste documento, a maioria das colunas do lado direito foram despojadas:
| Host | Host | Host | Failover | Remove |
| | Active | Status | Status | Status |
| | | | | |
| ---------------- | ------ | ------ | -------- | ------ | .......
| hso-hana-vm-s2-0 | yes | ok | | |
| hso-hana-vm-s2-1 | yes | ok | | |
| hso-hana-vm-s2-2 | yes | ok | | |

overall host status: ok

Há outro comando para verificar as atividades atuais do cluster. Veja o seguinte comando e a cauda de saída depois
do nó principal do local primário ter sido morto. Pode ver a lista de ações de transição como a promoção do
antigo nó principal secundário, hso-hana-vm-s2-0, como o novo mestre primário. Se está tudo bem, e todas as
atividades estiverem terminadas, esta lista de resumo de transição tem de estar vazia.

crm_simulate -Ls

...........

Transition Summary:
* Fence hso-hana-vm-s1-0
* Stop rsc_SAPHanaTop_HSO_HDB00:1 (hso-hana-vm-s1-0)
* Demote rsc_SAPHanaCon_HSO_HDB00:1 (Master -> Stopped hso-hana-vm-s1-0)
* Promote rsc_SAPHanaCon_HSO_HDB00:5 (Slave -> Master hso-hana-vm-s2-0)
* Move rsc_ip_HSO_HDB00 (Started hso-hana-vm-s1-0 -> hso-hana-vm-s2-0)
* Move rsc_nc_HSO_HDB00 (Started hso-hana-vm-s1-0 -> hso-hana-vm-s2-0)

Manutenção planeada
Existem casos de uso diferentes quando se trata de manutenção planeada. Uma questão é se é apenas manutenção
de infraestruturas como alterações no nível de OS e configuração do disco ou um upgrade HANA. Pode encontrar
informações adicionais em documentos da SUSE como Towards Zero Downtime ou SAP HANA SR Performance
Optimized Scenario. Estes documentos também incluem amostras que mostram como migrar manualmente uma
primária.
Foram efetuados testes internos intensos para verificar o caso de utilização da manutenção da infraestrutura. Para
evitar quaisquer problemas relacionados com a migração das primárias, decidimos migrar sempre uma primária
antes de colocar um cluster em modo de manutenção. Desta forma, não é necessário fazer o aglomerado esquecer
a situação anterior: que lado era primário e que era secundário.
Há duas situações diferentes a este respeito:
Manutenção planeada no secundário atual. Neste caso, pode colocar o cluster em modo de
manutenção e fazer o trabalho no secundário sem afetar o cluster.
Manutenção planeada nas primárias atuais. Para que os utilizadores possam continuar a trabalhar
durante a manutenção, é necessário forçar uma falha. Com esta abordagem, deve desencadear a falha do
cluster pelo Pacemaker e não apenas no nível SAP HANA HSR. A configuração do Pacemaker aciona
automaticamente a aquisição do SAP HANA. Também precisa de realizar a falha antes de colocar o cluster no
modo de manutenção.
O procedimento de manutenção no local secundário atual é o seguinte:
1. Coloque o cluster no modo de manutenção.
2. Realizar o trabalho no local secundário.
3. Termine o modo de manutenção do cluster.
O procedimento de manutenção no local primário atual é mais complexo:
1. Desencadeie manualmente uma aquisição de failover ou SAP HANA através de uma migração de recursos
Pacemaker. Veja os detalhes que se seguem.
2. SAP HANA no antigo local primário é encerrado pela configuração do cluster.
3. Coloque o cluster no modo de manutenção.
4. Depois de concluído o trabalho de manutenção, registe o primeiro primário como novo local secundário.
5. Limpe a configuração do cluster. Veja os detalhes que se seguem.
6. Termine o modo de manutenção do cluster.
Migrar um recurso adiciona uma entrada na configuração do cluster. Um exemplo é forçar uma falha. Tem de
limpar estas entradas antes de terminar o modo de manutenção. Consulte a seguinte amostra.
Primeiro, forçar um aglomerado falhar migrando o recurso msl para o atual nó principal secundário. Este comando
dá um aviso de que foi criada uma restrição de movimento:

crm resource migrate msl_SAPHanaCon_HSO_HDB00 force

INFO: Move constraint created for msl_SAPHanaCon_HSO_HDB00

Verifique o processo de failover através do comando SAPHanaSR-showAttr . Para monitorizar o estado do cluster,
abra uma janela de concha dedicada e inicie o comando com o relógio:

watch SAPHanaSR-showAttr

A saída deve mostrar a falha manual. O antigo nó de mestre secundário foi promovido , nesta amostra, hso-
hana-vm-s2-0 . O antigo local primário foi parado, lss valor 1 para o antigo mestre principal nó hso-hana-vm-
s1-0 :

Global cib-time prim sec srHook sync_state


------------------------------------------------------------
global Wed Sep 12 07:40:02 2018 HSOS2 - SFAIL SFAIL

Sites lpt lss mns srr


------------------------------------------
HSOS1 10 1 hso-hana-vm-s1-0 P
HSOS2 1536738002 4 hso-hana-vm-s2-0 P

Hosts clone_state node_state roles score site


----------------------------------------------------------------------------------
hso-hana-dm online
hso-hana-vm-s1-0 UNDEFINED online master1::worker: 150 HSOS1
hso-hana-vm-s1-1 DEMOTED online slave::worker: -10000 HSOS1
hso-hana-vm-s1-2 DEMOTED online slave::worker: -10000 HSOS1
hso-hana-vm-s2-0 PROMOTED online master1:master:worker:master 150 HSOS2
hso-hana-vm-s2-1 DEMOTED online slave:slave:worker:slave -10000 HSOS2
hso-hana-vm-s2-2 DEMOTED online slave:slave:worker:slave -10000 HSOS2

Após a falha do cluster e a aquisição da SAP HANA, coloque o cluster no modo de manutenção, conforme descrito
no Pacemaker.
Os comandos SAPHanaSR-showAttr e crm status não indicam nada sobre os constrangimentos criados pela
migração de recursos. Uma opção para tornar estes constrangimentos visíveis é mostrar a configuração completa
do recurso de cluster com o seguinte comando:

crm configure show

Dentro da configuração do cluster, encontra-se uma nova restrição de localização causada pela migração de
recursos manuais anteriores. Esta entrada de exemplo começa com a localização cli:

location cli-ban-msl_SAPHanaCon_HSO_HDB00-on-hso-hana-vm-s1-0 msl_SAPHanaCon_HSO_HDB00 role=Started -inf: hso-


hana-vm-s1-0

Infelizmente, tais constrangimentos podem ter impacto no comportamento geral do cluster. Por isso, é obrigatório
removê-los de novo antes de trazer todo o sistema de volta. Com o comando não migrado, é possível limpar os
constrangimentos de localização que foram criados antes. O nome pode ser um pouco confuso. Não tenta migrar o
recurso de volta para o VM original do qual foi migrado. Apenas remove os constrangimentos de localização e
também devolve as informações correspondentes quando executa o comando:

crm resource unmigrate msl_SAPHanaCon_HSO_HDB00

INFO: Removed migration constraints for msl_SAPHanaCon_HSO_HDB00

No final dos trabalhos de manutenção, pare o modo de manutenção do cluster como mostrado no Pacemaker.

hb_report recolher ficheiros de registo


Para analisar os problemas do cluster Pacemaker, é útil e também solicitado pelo suporte da SUSE para executar o
utilitário hb_repor t. Recolhe todos os ficheiros de registo importantes que precisa para analisar o que aconteceu.
Esta chamada de amostra utiliza um tempo de início e fim onde ocorreu um incidente específico. Ver Também notas
importantes:

hb_report -f "2018/09/13 07:36" -t "2018/09/13 08:00" /tmp/hb_report_log

O comando diz-lhe onde colocou os ficheiros de registo comprimidos:

The report is saved in /tmp/hb_report_log.tar.bz2


Report timespan: 09/13/18 07:36:00 - 09/13/18 08:00:00

Em seguida, pode extrair os ficheiros individuais através do comando padrão de alcatrão:

tar -xvf hb_report_log.tar.bz2

Quando olhas para os ficheiros extraídos, encontras todos os ficheiros de registo. A maioria deles foram colocados
em diretórios separados para cada nó do cluster:
-rw-r--r-- 1 root root 13655 Sep 13 09:01 analysis.txt
-rw-r--r-- 1 root root 14422 Sep 13 09:01 description.txt
-rw-r--r-- 1 root root 0 Sep 13 09:01 events.txt
-rw-r--r-- 1 root root 275560 Sep 13 09:00 ha-log.txt
-rw-r--r-- 1 root root 26 Sep 13 09:00 ha-log.txt.info
drwxr-xr-x 4 root root 4096 Sep 13 09:01 hso-hana-dm
drwxr-xr-x 3 root root 4096 Sep 13 09:01 hso-hana-vm-s1-0
drwxr-xr-x 3 root root 4096 Sep 13 09:01 hso-hana-vm-s1-1
drwxr-xr-x 3 root root 4096 Sep 13 09:01 hso-hana-vm-s1-2
drwxr-xr-x 3 root root 4096 Sep 13 09:01 hso-hana-vm-s2-0
drwxr-xr-x 3 root root 4096 Sep 13 09:01 hso-hana-vm-s2-1
drwxr-xr-x 3 root root 4096 Sep 13 09:01 hso-hana-vm-s2-2
-rw-r--r-- 1 root root 264726 Sep 13 09:00 journal.log

Dentro do intervalo de tempo especificado, o atual nó mestre hso-hana-vm-s1-0 foi morto. Pode encontrar
entradas relacionadas com este evento no diário.log:

2018-09-13T07:38:01+0000 hso-hana-vm-s2-1 su[93494]: (to hsoadm) root on none


2018-09-13T07:38:01+0000 hso-hana-vm-s2-1 su[93494]: pam_unix(su-l:session): session opened for user hsoadm by
(uid=0)
2018-09-13T07:38:01+0000 hso-hana-vm-s2-1 systemd[1]: Started Session c44290 of user hsoadm.
2018-09-13T07:38:02+0000 hso-hana-vm-s2-1 corosync[28302]: [TOTEM ] A new membership (10.0.0.13:120996) was
formed. Members left: 1
2018-09-13T07:38:02+0000 hso-hana-vm-s2-1 corosync[28302]: [TOTEM ] Failed to receive the leave message.
failed: 1
2018-09-13T07:38:02+0000 hso-hana-vm-s2-1 attrd[28313]: notice: Node hso-hana-vm-s1-0 state is now lost
2018-09-13T07:38:02+0000 hso-hana-vm-s2-1 attrd[28313]: notice: Removing all hso-hana-vm-s1-0 attributes for
peer loss
2018-09-13T07:38:02+0000 hso-hana-vm-s2-1 attrd[28313]: notice: Purged 1 peer with id=1 and/or uname=hso-
hana-vm-s1-0 from the membership cache
2018-09-13T07:38:02+0000 hso-hana-vm-s2-1 stonith-ng[28311]: notice: Node hso-hana-vm-s1-0 state is now lost
2018-09-13T07:38:02+0000 hso-hana-vm-s2-1 stonith-ng[28311]: notice: Purged 1 peer with id=1 and/or
uname=hso-hana-vm-s1-0 from the membership cache
2018-09-13T07:38:02+0000 hso-hana-vm-s2-1 cib[28310]: notice: Node hso-hana-vm-s1-0 state is now lost
2018-09-13T07:38:02+0000 hso-hana-vm-s2-1 corosync[28302]: [QUORUM] Members[6]: 7 2 3 4 5 6
2018-09-13T07:38:02+0000 hso-hana-vm-s2-1 corosync[28302]: [MAIN ] Completed service synchronization, ready
to provide service.
2018-09-13T07:38:02+0000 hso-hana-vm-s2-1 crmd[28315]: notice: Node hso-hana-vm-s1-0 state is now lost
2018-09-13T07:38:02+0000 hso-hana-vm-s2-1 pacemakerd[28308]: notice: Node hso-hana-vm-s1-0 state is now lost
2018-09-13T07:38:02+0000 hso-hana-vm-s2-1 cib[28310]: notice: Purged 1 peer with id=1 and/or uname=hso-hana-
vm-s1-0 from the membership cache
2018-09-13T07:38:03+0000 hso-hana-vm-s2-1 su[93494]: pam_unix(su-l:session): session closed for user hsoadm

Outro exemplo é o ficheiro de registo pacemaker do mestre secundário, que se tornou o novo mestre primário.
Este excerto mostra que o estado do nó principal morto foi definido para offline:
Sep 13 07:38:02 [4178] hso-hana-vm-s2-0 stonith-ng: info: pcmk_cpg_membership: Node 3 still member of
group stonith-ng (peer=hso-hana-vm-s1-2, counter=5.1)
Sep 13 07:38:02 [4178] hso-hana-vm-s2-0 stonith-ng: info: pcmk_cpg_membership: Node 4 still member of
group stonith-ng (peer=hso-hana-vm-s2-0, counter=5.2)
Sep 13 07:38:02 [4178] hso-hana-vm-s2-0 stonith-ng: info: pcmk_cpg_membership: Node 5 still member of
group stonith-ng (peer=hso-hana-vm-s2-1, counter=5.3)
Sep 13 07:38:02 [4178] hso-hana-vm-s2-0 stonith-ng: info: pcmk_cpg_membership: Node 6 still member of
group stonith-ng (peer=hso-hana-vm-s2-2, counter=5.4)
Sep 13 07:38:02 [4178] hso-hana-vm-s2-0 stonith-ng: info: pcmk_cpg_membership: Node 7 still member of
group stonith-ng (peer=hso-hana-dm, counter=5.5)
Sep 13 07:38:02 [4184] hso-hana-vm-s2-0 crmd: info: pcmk_cpg_membership: Node 1 left group crmd
(peer=hso-hana-vm-s1-0, counter=5.0)
Sep 13 07:38:02 [4184] hso-hana-vm-s2-0 crmd: info: crm_update_peer_proc: pcmk_cpg_membership:
Node hso-hana-vm-s1-0[1] - corosync-cpg is now offline
Sep 13 07:38:02 [4184] hso-hana-vm-s2-0 crmd: info: peer_update_callback: Client hso-hana-vm-s1-
0/peer now has status [offline] (DC=hso-hana-dm, changed=4000000)
Sep 13 07:38:02 [4184] hso-hana-vm-s2-0 crmd: info: pcmk_cpg_membership: Node 2 still member of
group crmd (peer=hso-hana-vm-s1-1, counter=5.0)

SAP HANA global.ini


Os seguintes excertos são do ficheiro global.ini da SAP HANA no site do cluster 2. Este exemplo mostra as
entradas de resolução de nome de anfitrião para a utilização de diferentes redes para a comunicação interna de
SAP HANA e HSR:

[communication]
tcp_keepalive_interval = 20
internal_network = 10.0.2/24
listeninterface = .internal

[internal_hostname_resolution]
10.0.2.40 = hso-hana-vm-s2-0
10.0.2.42 = hso-hana-vm-s2-2
10.0.2.41 = hso-hana-vm-s2-1

[ha_dr_provider_SAPHanaSR]
provider = SAPHanaSR
path = /hana/shared/myHooks
execution_order = 1

[system_replication_communication]
listeninterface = .internal

[system_replication_hostname_resolution]
10.0.1.30 = hso-hana-vm-s1-0
10.0.1.31 = hso-hana-vm-s1-1
10.0.1.32 = hso-hana-vm-s1-2
10.0.1.40 = hso-hana-vm-s2-0
10.0.1.41 = hso-hana-vm-s2-1
10.0.1.42 = hso-hana-vm-s2-2
Falcão
A solução cluster fornece uma interface de navegador que oferece um GUI para os utilizadores que preferem
menus e gráficos a ter todos os comandos no nível da concha. Para utilizar a interface ** <> ** do navegador,
substitua o nó por um nó SAP HANA real no seguinte URL. Em seguida, introduza as credenciais do cluster
(cluster do utilizador):

https://<node>:7630

Esta imagem mostra o painel de fragmentação:

Este exemplo mostra os constrangimentos de localização causados por uma migração de recursos de cluster, tal
como explicado na manutenção planeada:
Também pode fazer o upload da saída hb_repor t em Hawk under Histor y , mostrada da seguinte forma. Consulte
hb_report para recolher ficheiros de registo:

Com o Histor y Explorer, pode então passar por todas as transições de cluster incluídas na saída hb_repor t:
Esta imagem final mostra a secção Detalhes de uma única transição. O aglomerado reagiu num acidente no nó
principal, nó hso-hana-vm-s1-0 . Está agora a promover o nó secundário como o novo mestre, hso-hana-vm-
s2-0:

Passos seguintes
Este guia de resolução de problemas descreve a alta disponibilidade para o SAP HANA numa configuração de
escala- out. Além da base de dados, outro componente importante numa paisagem SAP é a pilha SAP NetWeaver.
Saiba mais sobre a elevada disponibilidade para SAP NetWeaver em máquinas virtuais Azure que usam o Servidor
Linux Da Empresa SUSE.
Implemente um sistema de escala SAP HANA com
nó de standby em VMs Azure utilizando ficheiros
Azure NetApp no SUSE Linux Enterprise Server
30/04/2020 • 54 minutes to read • Edit Online

Este artigo descreve como implementar um sistema SAP HANA altamente disponível numa configuração de escala
com standby em máquinas virtuais Azure (VMs) utilizando ficheiros Azure NetApp para os volumes de
armazenamento partilhados.
Nas configurações de exemplo, comandos de instalação, e assim por diante, a instância HANA é 03 e o ID do
sistema HANA é HN1 . Os exemplos são baseados em HANA 2.0 SP4 e SUSE Linux Enterprise Server para SAP 12
SP4.
Antes de começar, consulte as seguintes notas e documentos SAP:
Documentação de Ficheiros Azure NetApp
Nota SAP 1928533 inclui:
Uma lista de tamanhos De VM Azure que são suportados para a implementação de software SAP
Informações importantes sobre a capacidade para tamanhos de VM Azure
Software SAP suportado e sistema operativo (OS) e combinações de bases de dados
A versão necessária para o kernel SAP necessário para Windows e Linux no Microsoft Azure
Nota [SAP 2015553]: Lista os pré-requisitos para implementações de software SAP suportadas pelo SAP em
Azure
Nota [SAP 2205917]: Contém definições de OS recomendadas para o Servidor Empresarial SUSE Linux para
Aplicações SAP
Nota SAP 1944799: Contém diretrizes sAP para servidor empresarial SUSE Linux para aplicações SAP
Nota [SAP 2178632]: Contém informações detalhadas sobre todas as métricas de monitorização reportadas
para o SAP em Azure
Nota [SAP 2191498]: Contém a versão necessária do Agente anfitrião SAP para linux em Azure
Nota [SAP 2243692]: Contém informações sobre licenciamento SAP em Linux em Azure
Nota [SAP 1984787]: Contém informações gerais sobre o SUSE Linux Enterprise Server 12
Nota [SAP 1999351]: Contém informações adicionais de resolução de problemas para a extensão de
monitorização melhorada do Azure para o SAP
Nota [SAP 1900823]: Contém informações sobre os requisitos de armazenamento do SAP HANA
SAP Community Wiki: Contém todas as notas SAP necessárias para Linux
Planeamento e implementação de Máquinas Virtuais Azure para SAP em Linux
Implantação de Máquinas Virtuais Azure para SAP em Linux
Implantação de DBMS de Máquinas Virtuais Azure para SAP em Linux
Guias de boas práticas SUSE SAP HA: Contém todas as informações necessárias para configurar a Alta
Disponibilidade do NetWeaver e a Replicação do Sistema SAP HANA no local (a ser usado como base geral;
fornecem informações muito mais detalhadas)
Extensão de alta disponibilidade sUSE 12 Notas de lançamento SP3
Aplicações NetApp SAP no Microsoft Azure utilizando ficheiros Azure NetApp

Descrição geral
Um método para alcançar a alta disponibilidade da HANA é configurando a falha automática do anfitrião. Para
configurar a falha automática do anfitrião, adicione uma ou mais máquinas virtuais ao sistema HANA e configure-
as como nós de espera. Quando o nó ativo falha, um nó de espera assume automaticamente. Na configuração
apresentada com máquinas virtuais Azure, obtém-se falhas automáticas utilizando o NFS em Ficheiros Azure
NetApp.

NOTE
O nó de espera precisa de acesso a todos os volumes de base de dados. Os volumes HANA devem ser montados como
volumes NFSv4. O mecanismo de bloqueio melhorado baseado no aluguer de ficheiros I/O no protocolo NFSv4 é utilizado
para esgrima.

IMPORTANT
Para construir a configuração suportada, deve implantar os dados hana e os volumes de registo como volumes NFSv4.1 e
montá-los utilizando o protocolo NFSv4.1. A configuração de falha automática do hospedeiro HANA com nó de standby não
é suportada com NFSv3.

No diagrama anterior, que segue as recomendações da rede SAP HANA, três subredes estão representadas dentro
de uma rede virtual Azure:
Para comunicação com clientes
Para comunicação com o sistema de armazenamento
Para comunicação interna hana inter-nó
Os volumes Azure NetApp estão em subnet separada, delegada em Ficheiros Azure NetApp.
Para esta configuração de exemplo, as subredes são:
client 10.23.0.0/24
storage 10.23.2.0/24
hana 10.23.3.0/24
anf 10.23.1.0/26

Configurar a infraestrutura de ficheiros Azure NetApp


Antes de avançar com a configuração da infraestrutura de Ficheiros Azure NetApp, familiarize-se com a
documentação dos Ficheiros Azure NetApp.
Os Ficheiros Azure NetApp estão disponíveis em várias regiões do Azure. Verifique se a sua região azure
selecionada oferece ficheiros Azure NetApp.
Para obter informações sobre a disponibilidade de Ficheiros Azure NetApp pela região do Azure, consulte a
disponibilidade de ficheiros Azure NetApp pela região do Azure.
Antes de implementar ficheiros Azure NetApp, solicite o embarque nos Ficheiros Azure NetApp, indo ao Registo de
Instruções de Ficheiros Azure NetApp.
Implementar recursos de Ficheiros Azure NetApp
As seguintes instruções pressupõem que já implementou a sua rede virtual Azure. Os recursos e VMs do Azure
NetApp, onde serão montados os recursos dos Ficheiros Azure NetApp, devem ser implantados na mesma rede
virtual Azure ou em redes virtuais Azure.
1. Se ainda não disponibilizou os recursos, solicite o embarque nos Ficheiros AzurAppdo Azure .
2. Crie uma conta NetApp na sua região Azure selecionada seguindo as instruções em Criar uma conta
NetApp.
3. Criar um conjunto de capacidades de Ficheiros Azure NetApp seguindo as instruções em Configurar um
conjunto de capacidades de Ficheiros Azure NetApp.
A arquitetura HANA apresentada neste artigo utiliza um único conjunto de capacidades azure NetApp Files
ao nível do Ultra Service. Para cargas de trabalho HANA no Azure, recomendamos a utilização de um
Nívelde serviço Azure NetApp Files Ultra ou Premium .
4. Delege uma sub-rede para ficheiros Azure NetApp, conforme descrito nas instruções em Delegar uma sub-
rede para ficheiros Azure NetApp.
5. Implemente volumes de Ficheiros Azure NetApp seguindo as instruções em Criar um volume NFS para
Ficheiros Azure NetApp.
À medida que está a implementar os volumes, certifique-se de selecionar a versão NFSv4.1. Atualmente, o
acesso ao NFSv4.1 requer uma lista geminada adicional. Implementar os volumes na sub-redede Ficheiros
Azure NetApp designados . Os endereços IP dos volumes Azure NetApp são atribuídos automaticamente.
Tenha em mente que os recursos do Azure NetApp Files e os VMs Azure devem estar na mesma rede virtual
Azure ou em redes virtuais Azure. Por exemplo, HN1 -data-mnt00001, HN1 -log-mnt00001, e assim por
diante, são os nomes de volume e nfs://10.23.1.5/HN1 -data-mnt00001, nfs://10.23.1.4/HN1 -log-mnt00001,
e assim por diante, são os caminhos de arquivo para os volumes de Ficheiros Azure NetApp.
volume HN1 -data-mnt00001 (nfs://10.23.1.5/HN1 -data-mnt00001)
volume HN1 -data-mnt00002 (nfs://10.23.1.6/HN1 -data-mnt00002)
volume HN1 -log-mnt00001 (nfs://10.23.1.4/HN1 -log-mnt00001)
volume HN1 -log-mnt00002 (nfs://10.23.1.6/HN1 -log-mnt00002)
volume HN1 -partilhado (nfs://10.23.1.4/HN1 -partilhado)
Neste exemplo, usamos um volume de Ficheiros Azure NetApp separado para cada dados hana e volume de
registo. Para uma configuração mais otimizada em sistemas mais pequenos ou não produtivos, é possível
colocar todos os suportes de dados e todos os registos montados num único volume.
Considerações importantes
Enquanto está a criar os seus Ficheiros Azure NetApp para SAP NetWeaver na arquitetura de alta disponibilidade
da SUSE, esteja ciente das seguintes considerações importantes:
A piscina de capacidade mínima é de 4 tebibytes (TiB).
O tamanho mínimo do volume é de 100 gibibytes (GiB).
Os Ficheiros Azure NetApp e todas as máquinas virtuais onde serão montados os volumes dos Ficheiros Azure
NetApp devem estar na mesma rede virtual Azure ou em redes virtuais na mesma região.
A rede virtual selecionada deve ter uma subrede delegada nos Ficheiros Azure NetApp.
A produção de um volume de Ficheiros Azure NetApp é uma função do nível de quota de volume e de serviço,
tal como documentado no nível de Serviço para Ficheiros Azure NetApp. Ao dimensionar os volumes HANA
Azure NetApp, certifique-se de que a entrada resultante satisfaz os requisitos do sistema HANA.
Com a política de exportaçãode Ficheiros Azure NetApp, pode controlar os clientes permitidos, o tipo de acesso
(ler, ler apenas, e assim por diante).
A funcionalidade De Ficheiros Azure NetApp ainda não está ciente da zona. Atualmente, a funcionalidade não é
implantada em todas as zonas de disponibilidade de uma região do Azure. Esteja ciente das potenciais
implicações de latência em algumas regiões de Azure.

IMPORTANT
Para as cargas de trabalho da SAP HANA, a baixa latência é crítica. Trabalhe com o seu representante da Microsoft para
garantir que as máquinas virtuais e os volumes de Ficheiros Azure NetApp são implantados nas proximidades.

Dimensionamento para base de dados HANA em Ficheiros Azure NetApp


A entrada de um volume de Ficheiros Azure NetApp é uma função do tamanho do volume e nível de serviço,
conforme documentado no nível de Serviço para Ficheiros Azure NetApp.
Ao conceber a infraestrutura para SAP em Azure, esteja ciente de alguns requisitos mínimos de armazenamento
pela SAP, que se traduzem em características mínimas de rendimento:
Ativar a leitura-escrita em /hana/log de 250 megabytes por segundo (MB/s) com tamanhos de 1-MB I/O.
Ativar a atividade de leitura de pelo menos 400 MB/s para /hana/dados para tamanhos de 16 MB e 64-MB I/O.
Ativar a atividade de escrita de pelo menos 250 MB/s para /hana/dados com tamanhos de 16 MB e 64-MB I/O.
Os limites de produção dos Ficheiros Azure NetApp por 1 TiB de quota de volume são:
Premium Nível de Armazenamento - 64 MiB/s
Nível de Ultra Armazenamento - 128 MiB/s
Para satisfazer os requisitos mínimos de entrada de dados e registos saps, e as diretrizes para /hana/partilhado, os
tamanhos recomendados seriam:

TA M A N H O DE
N ÍVEL DE TA M A N H O DE
A RM A Z EN A M EN TO N ÍVEL ULT RA P ROTO C O LO N F S
VO L UM E P REM IUM A RM A Z EN A M EN TO SUP O RTA DO

/hana/log/ 4 TiB 2 TiB v4.1

/hana/dados 6.3 Tib 3.2 Tib v4.1

/hana/compartilhado Máx (512 GB, 1xRAM) por 4 Máx (512 GB, 1xRAM) por 4 v3 ou v4.1
nós de trabalhador nós de trabalhador

A configuração SAP HANA para o layout que é apresentado neste artigo, utilizando o nível de Ultra
Armazenamento de Ficheiros Azure NetApp, seria:

TA M A N H O DE
VO L UM E N ÍVEL ULT RA A RM A Z EN A M EN TO P ROTO C O LO N F S SUP O RTA DO

/hana/log/mnt000001 2 TiB v4.1

/hana/log/mnt000002 2 TiB v4.1

/hana/data/mnt000001 3.2 Tib v4.1

/hana/data/mnt000002 3.2 Tib v4.1

/hana/compartilhado 2 TiB v3 ou v4.1

NOTE
As recomendações de dimensionamento do Azure NetApp, aqui indicadas, destinam-se a cumprir os requisitos mínimos que
a SAP recomenda para os seus fornecedores de infraestruturas. Em implementações reais de clientes e cenários de carga de
trabalho, estes tamanhos podem não ser suficientes. Utilize estas recomendações como ponto de partida e adapte-se, com
base nos requisitos da sua carga de trabalho específica.

TIP
Pode redimensionar os volumes do Azure NetApp De forma dinâmica, sem ter de desmontar os volumes, parar as máquinas
virtuais ou parar o SAP HANA. Esta abordagem permite flexibilidade para satisfazer as exigências de entrada esperadas e
imprevistas da sua aplicação.

Implementar máquinas virtuais Linux através do portal Azure


Primeiro, é necessário criar os volumes de Ficheiros Azure NetApp. Em seguida, faça os seguintes passos:
1. Crie as subredes de rede virtual Azure na sua rede virtual Azure.
2. Implante os VMs.
3. Crie as interfaces de rede adicionais e fixe as interfaces de rede aos VMs correspondentes.
Cada máquina virtual tem três interfaces de rede, que correspondem storage hana às três redes virtuais
Azure (e). client
Para mais informações, consulte Criar uma máquina virtual Linux em Azure com vários cartõesde interface
de rede .

IMPORTANT
Para as cargas de trabalho da SAP HANA, a baixa latência é crítica. Para obter baixa latência, trabalhe com o seu representante
da Microsoft para garantir que as máquinas virtuais e os volumes de Ficheiros Azure NetApp são implantados nas
proximidades. Quando estiver a embarcar no novo sistema SAP HANA que está a utilizar ficheiros SAP HANA Azure NetApp,
submeta as informações necessárias.

As próximas instruções assumem que já criou o grupo de recursos, a rede virtual client storage Azure e as três
redes virtuais Azure: e hana . Quando implementar os VMs, selecione a subnet do cliente, de modo a que a
interface de rede do cliente seja a interface principal nos VMs. Também terá de configurar uma rota explícita para a
sub-rede delegada dos Ficheiros Azure Net através do portal de sub-rede de armazenamento.

IMPORTANT
Certifique-se de que o SISTEMA selecionado é certificado por SAP HANA nos tipos de VM específicos que está a utilizar. Para
obter uma lista de tipos vM certificados SAP HANA e lançamentos de SO para esses tipos, vá ao site de plataformas IaaS
certificadas sAP HANA. Clique nos detalhes do tipo VM listado para obter a lista completa de lançamentos de SAP HANA
suportados por SAP HANA para esse tipo.

1. Crie um conjunto de disponibilidade para o SAP HANA. Certifique-se de que define o domínio da atualização
máxima.
2. Criar três máquinas virtuais (hanadb1, hanadb2, hanadb3 ) fazendo os seguintes passos:
a. Use uma imagem SLES4SAP na galeria Azure que é suportada para SAP HANA. Usamos uma imagem
SLES4SAP 12 SP4 neste exemplo.
b. Selecione o conjunto de disponibilidade que criou anteriormente para o SAP HANA.
c. Selecione a subnet de rede virtual do cliente Azure. Selecione Rede Acelerada.
Quando se implanta as máquinas virtuais, o nome da interface de rede é gerado automaticamente. Nestas
instruções de simplicidade, referimo-nos às interfaces de rede geradas automaticamente, que estão ligadas à
subnet de rede virtual do cliente Azure, como hanadb1-cliente , hanadb2-client, e hanadb3-client .
3. Crie três interfaces de rede, uma storage para cada máquina virtual, para a subnet de rede virtual (neste
exemplo, hanadb1-storage, hanadb2-storage, e hanadb3-storage).
4. Crie três interfaces de rede, uma hana para cada máquina virtual, para a subnet de rede virtual (neste
exemplo, hanadb1-hana, hanadb2-hana , e hanadb3-hana).
5. Fixe as interfaces de rede virtual recém-criadas às máquinas virtuais correspondentes, fazendo os seguintes
passos:
a. Vá à máquina virtual no portal Azure.
b. No painel esquerdo, selecione Máquinas Vir tuais . Filtre no nome da máquina virtual (por exemplo,
hanadb1 ), e, em seguida, selecione a máquina virtual.
c. No painel de visão geral, selecione Parar para desalojar a máquina virtual.
d. Selecione Networking e, em seguida, fixe a interface de rede. Na lista de drop-down da interface da rede
Attach, selecione as interfaces de rede já criadas para as storage redes e hana subnets.
e. Selecione Guardar .
f. Repita os passos b através e para as restantes máquinas virtuais (no nosso exemplo, hanadb2 e
hanadb3 ).
g. Deixe as máquinas virtuais em estado de parada por enquanto. Em seguida, permitiremos uma rede
acelerada para todas as interfaces de rede recém-anexadas.
6. Ativar a ligação acelerada de rede storage hana para as interfaces de rede adicionais para as e subnets
adicionais, fazendo os seguintes passos:
a. Abra a Nuvem Azure no portal Azure.
b. Execute os seguintes comandos para permitir a ligação de rede storage acelerada para as interfaces de
rede adicionais, que estão ligadas às e hana subredes.

az network nic update --id /subscriptions/your subscription/resourceGroups/your resource


group/providers/Microsoft.Network/networkInterfaces/hanadb1-storage --accelerated-networking true
az network nic update --id /subscriptions/your subscription/resourceGroups/your resource
group/providers/Microsoft.Network/networkInterfaces/hanadb2-storage --accelerated-networking true
az network nic update --id /subscriptions/your subscription/resourceGroups/your resource
group/providers/Microsoft.Network/networkInterfaces/hanadb3-storage --accelerated-networking true

az network nic update --id /subscriptions/your subscription/resourceGroups/your resource


group/providers/Microsoft.Network/networkInterfaces/hanadb1-hana --accelerated-networking true
az network nic update --id /subscriptions/your subscription/resourceGroups/your resource
group/providers/Microsoft.Network/networkInterfaces/hanadb2-hana --accelerated-networking true
az network nic update --id /subscriptions/your subscription/resourceGroups/your resource
group/providers/Microsoft.Network/networkInterfaces/hanadb3-hana --accelerated-networking true

7. Inicie as máquinas virtuais fazendo os seguintes passos:


a. No painel esquerdo, selecione Máquinas Vir tuais . Filtre no nome da máquina virtual (por exemplo,
hanadb1 ), e, em seguida, selecione-o.
b. No painel de visão geral, selecione Iniciar .

Configuração e preparação do sistema operativo


As instruções nas secções seguintes são pré-fixadas com uma das seguintes:
[A] : Aplicável a todos os nós
[1] : Aplicável apenas ao nó 1
[2] : Aplicável apenas ao nó 2
[3] : Aplicável apenas ao nó 3
Configure e prepare o seu SISTEMA fazendo os seguintes passos:
1. [A] Mantenha os ficheiros do anfitrião nas máquinas virtuais. Incluir entradas para todas as subredes. Para
este exemplo, /etc/hosts foram adicionadas as seguintes entradas.
# Storage
10.23.2.4 hanadb1-storage
10.23.2.5 hanadb2-storage
10.23.2.6 hanadb3-storage
# Client
10.23.0.5 hanadb1
10.23.0.6 hanadb2
10.23.0.7 hanadb3
# Hana
10.23.3.4 hanadb1-hana
10.23.3.5 hanadb2-hana
10.23.3.6 hanadb3-hana

2. [A] Alterar as definições de DHCP e cloud config para a interface de rede para armazenamento para evitar
alterações não intencionais do nome de anfitrião.
As seguintes instruções pressupõem eth1 que a interface da rede de armazenamento é .

vi /etc/sysconfig/network/dhcp
# Change the following DHCP setting to "no"
DHCLIENT_SET_HOSTNAME="no"
vi /etc/sysconfig/network/ifcfg-eth1
# Edit ifcfg-eth1
#Change CLOUD_NETCONFIG_MANAGE='yes' to "no"
CLOUD_NETCONFIG_MANAGE='no'

3. [A] Adicione uma rota de rede, de modo que a comunicação aos Ficheiros Azure NetApp vá através da
interface da rede de armazenamento.
As seguintes instruções pressupõem eth1 que a interface da rede de armazenamento é .

vi /etc/sysconfig/network/ifroute-eth1
# Add the following routes
# RouterIPforStorageNetwork - - -
# ANFNetwork/cidr RouterIPforStorageNetwork - -
10.23.2.1 - - -
10.23.1.0/26 10.23.2.1 - -

Reiniciar o VM para ativar as alterações.


4. [A] Prepare o SISTEMA para executar SAP HANA em Sistemas NetApp com NFS, conforme descrito nas
aplicações NetApp SAP no Microsoft Azure utilizando ficheiros Azure NetApp. Crie ficheirode configuração
/etc/sysctl.d/netapp-hana.conf para as definições de configuração do NetApp.
vi /etc/sysctl.d/netapp-hana.conf
# Add the following entries in the configuration file
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.core.rmem_default = 16777216
net.core.wmem_default = 16777216
net.core.optmem_max = 16777216
net.ipv4.tcp_rmem = 65536 16777216 16777216
net.ipv4.tcp_wmem = 65536 16777216 16777216
net.core.netdev_max_backlog = 300000
net.ipv4.tcp_slow_start_after_idle=0
net.ipv4.tcp_no_metrics_save = 1
net.ipv4.tcp_moderate_rcvbuf = 1
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_timestamps = 1
net.ipv4.tcp_sack = 1

5. [A] Criar ficheiro de configuração /etc/sysctl.d/ms-az.conf com a Microsoft para configurações de


configuração Azure.

vi /etc/sysctl.d/ms-az.conf
# Add the following entries in the configuration file
ipv6.conf.all.disable_ipv6 = 1
net.ipv4.tcp_max_syn_backlog = 16348
net.ipv4.ip_local_port_range = 40000 65300
net.ipv4.conf.all.rp_filter = 0
sunrpc.tcp_slot_table_entries = 128
vm.swappiness=10

6. [A] Ajuste as definições sunrpc, conforme recomendado nas aplicações NetApp SAP no Microsoft Azure
utilizando ficheiros Azure NetApp.

vi /etc/modprobe.d/sunrpc.conf
# Insert the following line
options sunrpc tcp_max_slot_table_entries=128

Monte os volumes de ficheiros Azure NetApp


1. [A] Criar pontos de montagem para os volumes de base de dados HANA.

mkdir -p /hana/data/HN1/mnt00001
mkdir -p /hana/data/HN1/mnt00002
mkdir -p /hana/log/HN1/mnt00001
mkdir -p /hana/log/HN1/mnt00002
mkdir -p /hana/shared
mkdir -p /usr/sap/HN1

2. [1] Criar diretórios específicos para /usr/seiva em HN1 -partilhados.


# Create a temporary directory to mount HN1-shared
mkdir /mnt/tmp
# if using NFSv3 for this volume, mount with the following command
mount 10.23.1.4:/HN1-shared /mnt/tmp
# if using NFSv4.1 for this volume, mount with the following command
mount -t nfs -o sec=sys,vers=4.1 10.23.1.4:/HN1-shared /mnt/tmp
cd /mnt/tmp
mkdir shared usr-sap-hanadb1 usr-sap-hanadb2 usr-sap-hanadb3
# unmount /hana/shared
cd
umount /mnt/tmp

3. [A] Verifique a definição de domínio NFS. Certifique-se de que o domínio está configurado como o domínio
defaultv4iddomain.com padrão dos Ficheiros Azure NetApp, ou seja, e o mapeamento não está definido para
ninguém .

IMPORTANT
Certifique-se de que configura /etc/idmapd.conf o domínio NFS no VM para corresponder
defaultv4iddomain.com à configuração de domínio predefinido nos Ficheiros Azure NetApp: . Se houver uma
incompatibilidade entre a configuração de domínio no cliente NFS (isto é, o VM) e o servidor NFS, ou seja, a
configuração Azure NetApp, então nobody as permissões para ficheiros em volumes Azure NetApp que são
montados nos VMs serão apresentadas como .

sudo cat /etc/idmapd.conf


# Example
[General]
Verbosity = 0
Pipefs-Directory = /var/lib/nfs/rpc_pipefs
Domain = defaultv4iddomain.com
[Mapping]
Nobody-User = nobody
Nobody-Group = nobody

4. [A] Verificar . Deve ser definido para Y. Para criar a estrutura


nfs4_disable_idmapping
nfs4_disable_idmapping do diretório onde está localizada, execute o comando do suporte. Não poderá criar
manualmente o diretório em /sys/módulos, porque o acesso é reservado para o núcleo/controladores.

# Check nfs4_disable_idmapping
cat /sys/module/nfs/parameters/nfs4_disable_idmapping
# If you need to set nfs4_disable_idmapping to Y
mkdir /mnt/tmp
mount 10.23.1.4:/HN1-shared /mnt/tmp
umount /mnt/tmp
echo "Y" > /sys/module/nfs/parameters/nfs4_disable_idmapping
# Make the configuration permanent
echo "options nfs nfs4_disable_idmapping=Y" >> /etc/modprobe.d/nfs.conf

5. [A] Criar manualmente o grupo SAP HANA e o utilizador. Os IDs para sapsys de grupo e o utilizador
hn1 adm devem ser definidos para os mesmos IDs, que são fornecidos durante o embarque. (Neste
exemplo, as iDs são fixadas para 1001 .) Se as identificações não estiverem corretamente definidas, não
conseguirá aceder aos volumes. Os IDs para sapsys de grupo e contas de utilizador hn1 adm e sapadm
devem ser os mesmos em todas as máquinas virtuais.

# Create user group


sudo groupadd -g 1001 sapsys
# Create users
sudo useradd hn1adm -u 1001 -g 1001 -d /usr/sap/HN1/home -c "SAP HANA Database System" -s /bin/sh
sudo useradd sapadm -u 1002 -g 1001 -d /home/sapadm -c "SAP Local Administrator" -s /bin/sh
# Set the password for both user ids
sudo passwd hn1adm
sudo passwd sapadm

6. [A] Monte os volumes de ficheiros Azure NetApp partilhados.

sudo vi /etc/fstab
# Add the following entries
10.23.1.5:/HN1-data-mnt00001 /hana/data/HN1/mnt00001 nfs
rw,vers=4,minorversion=1,hard,timeo=600,rsize=262144,wsize=262144,intr,noatime,lock,_netdev,sec=sys 0
0
10.23.1.6:/HN1-data-mnt00002 /hana/data/HN1/mnt00002 nfs
rw,vers=4,minorversion=1,hard,timeo=600,rsize=262144,wsize=262144,intr,noatime,lock,_netdev,sec=sys 0
0
10.23.1.4:/HN1-log-mnt00001 /hana/log/HN1/mnt00001 nfs
rw,vers=4,minorversion=1,hard,timeo=600,rsize=262144,wsize=262144,intr,noatime,lock,_netdev,sec=sys 0
0
10.23.1.6:/HN1-log-mnt00002 /hana/log/HN1/mnt00002 nfs
rw,vers=4,minorversion=1,hard,timeo=600,rsize=262144,wsize=262144,intr,noatime,lock,_netdev,sec=sys 0
0
10.23.1.4:/HN1-shared/shared /hana/shared nfs
rw,vers=4,minorversion=1,hard,timeo=600,rsize=262144,wsize=262144,intr,noatime,lock,_netdev,sec=sys 0
0
# Mount all volumes
sudo mount -a

7. [1] Monte os volumes específicos do nó em hanadb1 .

sudo vi /etc/fstab
# Add the following entries
10.23.1.4:/HN1-shared/usr-sap-hanadb1 /usr/sap/HN1 nfs
rw,vers=4,minorversion=1,hard,timeo=600,rsize=262144,wsize=262144,intr,noatime,lock,_netdev,sec=sys 0
0
# Mount the volume
sudo mount -a

8. [2] Monte os volumes específicos do nó em hanadb2 .

sudo vi /etc/fstab
# Add the following entries
10.23.1.4:/HN1-shared/usr-sap-hanadb2 /usr/sap/HN1 nfs
rw,vers=4,minorversion=1,hard,timeo=600,rsize=262144,wsize=262144,intr,noatime,lock,_netdev,sec=sys 0
0
# Mount the volume
sudo mount -a
9. [3] Monte os volumes específicos do nó em hanadb3 .

sudo vi /etc/fstab
# Add the following entries
10.23.1.4:/HN1-shared/usr-sap-hanadb3 /usr/sap/HN1 nfs
rw,vers=4,minorversion=1,hard,timeo=600,rsize=262144,wsize=262144,intr,noatime,lock,_netdev,sec=sys 0
0
# Mount the volume
sudo mount -a

10. [A] Verifique se todos os volumes HANA são montados com a versão nFS protocol nFSv4 .

sudo nfsstat -m
# Verify that flag vers is set to 4.1
# Example from hanadb1
/hana/data/HN1/mnt00001 from 10.23.1.5:/HN1-data-mnt00001
Flags:
rw,noatime,vers=4.1,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clie
ntaddr=10.23.2.4,local_lock=none,addr=10.23.1.5
/hana/log/HN1/mnt00002 from 10.23.1.6:/HN1-log-mnt00002
Flags:
rw,noatime,vers=4.1,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clie
ntaddr=10.23.2.4,local_lock=none,addr=10.23.1.6
/hana/data/HN1/mnt00002 from 10.23.1.6:/HN1-data-mnt00002
Flags:
rw,noatime,vers=4.1,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clie
ntaddr=10.23.2.4,local_lock=none,addr=10.23.1.6
/hana/log/HN1/mnt00001 from 10.23.1.4:/HN1-log-mnt00001
Flags:
rw,noatime,vers=4.1,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clie
ntaddr=10.23.2.4,local_lock=none,addr=10.23.1.4
/usr/sap/HN1 from 10.23.1.4:/HN1-shared/usr-sap-hanadb1
Flags:
rw,noatime,vers=4.1,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clie
ntaddr=10.23.2.4,local_lock=none,addr=10.23.1.4
/hana/shared from 10.23.1.4:/HN1-shared/shared
Flags:
rw,noatime,vers=4.1,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clie
ntaddr=10.23.2.4,local_lock=none,addr=10.23.1.4

Instalação
Neste exemplo para a implementação do SAP HANA em configuração de escala-out com nó de espera com Azure,
usamos HANA 2.0 SP4.
Preparar para a instalação HANA
1. [A] Antes da instalação da HANA, desloque a palavra-passe de raiz. Pode desativar a palavra-passe da raiz
depois de concluída a instalação. Executar root como passwd comando .
2. [1] Verifique se pode fazer login via SSH para hanadb2 e hanadb3 , sem ser solicitado por uma senha.

ssh root@hanadb2
ssh root@hanadb3

3. [A] Instale pacotes adicionais, que são necessários para HANA 2.0 SP4. Para mais informações, consulte A
Nota SAP 2593824.

sudo zypper install libgcc_s1 libstdc++6 libatomic1

4. [2], [3] Mude a propriedade da data log SAP HANA e os diretórios para hn1 adm.

# Execute as root
sudo chown hn1adm:sapsys /hana/data/HN1
sudo chown hn1adm:sapsys /hana/log/HN1

Instalação HANA
1. [1] Instale o SAP HANA seguindo as instruções no guia de instalação e atualização SAP HANA 2.0. Neste
exemplo, instalamos sap HANA scale-out com mestre, um trabalhador, e um nó de espera.
a. Inicie o programa hdblcm a partir do diretório de software de instalação HANA. Utilize internal_network
o parâmetro e passe o espaço de endereço para a sub-rede, que é utilizado para a comunicação inter-nó
interna HANA.

./hdblcm --internal_network=10.23.3.0/24

b. A pedido, introduza os seguintes valores:


Para escolher uma ação : insira 1 (para instalação)
Para componentes adicionais para instalação: insira 2, 3
Para o caminho de instalação: prima Enter (predefinições para /hana/partilhado)
Para nome do anfitrião local : prima Introduza para aceitar o padrão
Sob o seu deseja adicionar anfitriões ao sistema? y
Para nomes de anfitriões separados com vírina a adicionar : insira hanadb2, hanadb3
Para o nome do utilizador raiz [raiz]: prima Introduza para aceitar o padrão
Para palavra-passe do utilizador raiz : introduza a palavra-passe do utilizador-raiz
Para funções para o anfitrião hanadb2: insira 1 (para trabalhador)
Para o Grupo de Failover do Anfitrião para o anfitrião hanadb2 [padrão]: prima Entrar para aceitar o
padrão
Para o número de par tição de armazenamento para o anfitrião hanadb2 [<>]: prima Introduza para
aceitar o padrão
Para o Grupo de Trabalhadores para o anfitrião hanadb2 [padrão]: prima Entrar para aceitar o padrão
Para selecionar funções para o anfitrião hanadb3: insira 2 (para standby)
Para o Grupo de Failover do Anfitrião para o anfitrião hanadb3 [padrão]: prima Entrar para aceitar o
padrão
Para o Grupo de Trabalhadores para o anfitrião hanadb3 [padrão]: prima Entrar para aceitar o padrão
Para Identificação do Sistema SAP HANA : insira HN1
Por exemplo número [00]: insira 03
Para o Grupo local de trabalho anfitrião [padrão]: prima Entrar para aceitar o padrão
Para selecionar a utilização do sistema / Entrar no índice [4] : introduzir 4 (para personalizado)
Para a localização dos volumes de dados [/hana/data/HN1]: prima Introduza para aceitar o padrão
Para a localização dos volumes de registo [/hana/log/HN1]: prima Introduza para aceitar o padrão
Para restringir a atribuição máxima de memória? [n]: inserir n
Para o nome do anfitrião do cer tificado para o anfitrião hanadb1 [hanadb1]: prima Introduza para
aceitar o padrão
Para o nome do anfitrião do cer tificado para o anfitrião hanadb2 [hanadb2]: prima Introduza para
aceitar o padrão
Para o nome do anfitrião do cer tificado para o anfitrião hanadb3 [hanadb3]: prima Introduza para
aceitar o padrão
Para administrador de sistema (hn1adm) Palavra-passe : insira a palavra-passe
Para o utilizador (sistema) utilizador (sistema) utilizador do sistema : introduza a palavra-passe do
sistema
Para confirmar a palavra-passe do utilizador (sistema) do utilizador do sistema : introduzir a
palavra-passe do sistema
Para reiniciar o sistema após a reinicialização da máquina? [n]: inserir n
Pois você quer continuar (y/n) : validar o resumo e se tudo parecer bom, insira y
2. [1] Verificar global.ini
Exiba global.ini e certifique-se de que a configuração para a comunicação inter-nó interna SAP HANA está
em vigor. Verifique a secção de comunicação. Deve ter o espaço hana de endereço listeninterface para a
.internal sub-rede e deve ser definido para . Verifique a secção internal_hostname_resolution. Deve ter
os endereços IP das máquinas virtuais hana HANA que pertencem à sub-rede.

sudo cat /usr/sap/HN1/SYS/global/hdb/custom/config/global.ini


# Example
#global.ini last modified 2019-09-10 00:12:45.192808 by hdbnameserve
[communication]
internal_network = 10.23.3/24
listeninterface = .internal
[internal_hostname_resolution]
10.23.3.4 = hanadb1
10.23.3.5 = hanadb2
10.23.3.6 = hanadb3

3. [1] Adicione o mapeamento do anfitrião para garantir que os endereços IP do cliente são usados para a
comunicação do cliente. Adicione public_host_resolution a secção e adicione os endereços IP
correspondentes da subnet do cliente.

sudo vi /usr/sap/HN1/SYS/global/hdb/custom/config/global.ini
#Add the section
[public_hostname_resolution]
map_hanadb1 = 10.23.0.5
map_hanadb2 = 10.23.0.6
map_hanadb3 = 10.23.0.7

4. [1] Reiniciar o SAP HANA para ativar as alterações.

sudo -u hn1adm /usr/sap/hostctrl/exe/sapcontrol -nr 03 -function StopSystem HDB


sudo -u hn1adm /usr/sap/hostctrl/exe/sapcontrol -nr 03 -function StartSystem HDB

5. [1] Verifique se a interface do cliente utilizará os endereços IP da client subnet para comunicação.
sudo -u hn1adm /usr/sap/HN1/HDB03/exe/hdbsql -u SYSTEM -p "password" -i 03 -d SYSTEMDB 'select * from
SYS.M_HOST_INFORMATION'|grep net_publicname
# Expected result
"hanadb3","net_publicname","10.23.0.7"
"hanadb2","net_publicname","10.23.0.6"
"hanadb1","net_publicname","10.23.0.5"

Para obter informações sobre como verificar a configuração, consulte o SAP Note 2183363 - Configuração
da rede interna SAP HANA.
6. Para otimizar o SAP HANA para o armazenamento subjacente aos Ficheiros Azure NetApp, defina os
seguintes parâmetros SAP HANA:
max_parallel_io_requests 128
async_read_submit em
async_write_submit_activeem
async_write_submit_blocks todos os
Para mais informações, consulte as aplicações NetApp SAP no Microsoft Azure utilizando ficheiros Azure
NetApp.
A partir dos sistemas SAP HANA 2.0, global.ini pode definir os parâmetros em . Para mais informações,
consulte SAP Nota 1999930.
Para versões de sistemas SAP HANA 1.0 SPS12 e anteriores, estes parâmetros podem ser definidos durante
a instalação, conforme descrito na Nota SAP 2267798.
7. O armazenamento utilizado pelos Ficheiros Azure NetApp tem uma limitação de tamanho de ficheiro de 16
terabytes (TB). O SAP HANA não está implicitamente ciente da limitação de armazenamento, e não criará
automaticamente um novo ficheiro de dados quando o limite de tamanho de ficheiro de 16 TB for atingido.
À medida que o SAP HANA tenta aumentar o ficheiro para além de 16 TB, essa tentativa resultará em erros
e, eventualmente, num crash de servidor de índice.

IMPORTANT
Para evitar que o SAP HANA tente cultivar ficheiros de dados para além do global.ini limite de 16 TB do
subsistema de armazenamento, defina os seguintes parâmetros em .
datavolume_striping = verdadeiro
datavolume_striping_size_gb = 15000 Para mais informações, consulte a Nota SAP 2400005. Esteja atento à Nota
2631285.

Teste SAP HANA falha


1. Simular um acidente de nó num nó de trabalhador da SAP HANA. Faça o seguinte:
a. Antes de simular a queda do nó, execute os seguintes comandos como hn1 adm para capturar o estado do
ambiente:
# Check the landscape status
python /usr/sap/HN1/HDB03/exe/python_support/landscapeHostConfiguration.py
| Host | Host | Host | Failover | Remove | Storage | Storage | Failover | Failover |
NameServer | NameServer | IndexServer | IndexServer | Host | Host | Worker | Worker |
| | Active | Status | Status | Status | Config | Actual | Config | Actual | Config
| Actual | Config | Actual | Config | Actual | Config | Actual |
| | | | | | Partition | Partition | Group | Group | Role
| Role | Role | Role | Roles | Roles | Groups | Groups |
| ------- | ------ | ------ | -------- | ------ | --------- | --------- | -------- | -------- | -------
--- | ---------- | ----------- | ----------- | ------- | ------- | ------- | ------- |
| hanadb1 | yes | ok | | | 1 | 1 | default | default | master
1 | master | worker | master | worker | worker | default | default |
| hanadb2 | yes | ok | | | 2 | 2 | default | default | master
2 | slave | worker | slave | worker | worker | default | default |
| hanadb3 | yes | ignore | | | 0 | 0 | default | default | master
3 | slave | standby | standby | standby | standby | default | - |
# Check the instance status
sapcontrol -nr 03 -function GetSystemInstanceList
GetSystemInstanceList
OK
hostname, instanceNr, httpPort, httpsPort, startPriority, features, dispstatus
hanadb2, 3, 50313, 50314, 0.3, HDB|HDB_WORKER, GREEN
hanadb1, 3, 50313, 50314, 0.3, HDB|HDB_WORKER, GREEN
hanadb3, 3, 50313, 50314, 0.3, HDB|HDB_STANDBY, GREEN

b. Para simular uma queda no nó, corra o seguinte comando como raiz no nó do trabalhador, que é
hanadb2 neste caso:

echo b > /proc/sysrq-trigger

c. Monitorize o sistema para a conclusão da falha. Quando a falha estiver concluída, capture o estado, que
deve parecer o seguinte:

# Check the instance status


sapcontrol -nr 03 -function GetSystemInstanceList
GetSystemInstanceList
OK
hostname, instanceNr, httpPort, httpsPort, startPriority, features, dispstatus
hanadb1, 3, 50313, 50314, 0.3, HDB|HDB_WORKER, GREEN
hanadb3, 3, 50313, 50314, 0.3, HDB|HDB_STANDBY, GREEN
hanadb2, 3, 50313, 50314, 0.3, HDB|HDB_WORKER, GRAY
# Check the landscape status
/usr/sap/HN1/HDB03/exe/python_support> python landscapeHostConfiguration.py
| Host | Host | Host | Failover | Remove | Storage | Storage | Failover | Failover |
NameServer | NameServer | IndexServer | IndexServer | Host | Host | Worker | Worker |
| | Active | Status | Status | Status | Config | Actual | Config | Actual | Config
| Actual | Config | Actual | Config | Actual | Config | Actual |
| | | | | | Partition | Partition | Group | Group | Role
| Role | Role | Role | Roles | Roles | Groups | Groups |
| ------- | ------ | ------ | -------- | ------ | --------- | --------- | -------- | -------- | -------
--- | ---------- | ----------- | ----------- | ------- | ------- | ------- | ------- |
| hanadb1 | yes | ok | | | 1 | 1 | default | default | master
1 | master | worker | master | worker | worker | default | default |
| hanadb2 | no | info | | | 2 | 0 | default | default | master
2 | slave | worker | standby | worker | standby | default | - |
| hanadb3 | yes | info | | | 0 | 2 | default | default | master
3 | slave | standby | slave | standby | worker | default | default |
IMPORTANT
Quando um nó experimenta o pânico do kernel, evite atrasos com a falha do SAP HANA, fixando-se kernel.panic
em 20 segundos em todas as máquinas virtuais HANA. A configuração /etc/sysctl é feita em . Reinicie as máquinas
virtuais para ativar a mudança. Se esta mudança não for realizada, a falha pode demorar 10 ou mais minutos quando
um nó está a sentir pânico no núcleo.

2. Mate o servidor de nomes fazendo o seguinte:


a. Antes do teste, verifique o estado do ambiente executando os seguintes comandos como hn1 adm:

#Landscape status
python /usr/sap/HN1/HDB03/exe/python_support/landscapeHostConfiguration.py
| Host | Host | Host | Failover | Remove | Storage | Storage | Failover | Failover |
NameServer | NameServer | IndexServer | IndexServer | Host | Host | Worker | Worker |
| | Active | Status | Status | Status | Config | Actual | Config | Actual | Config
| Actual | Config | Actual | Config | Actual | Config | Actual |
| | | | | | Partition | Partition | Group | Group | Role
| Role | Role | Role | Roles | Roles | Groups | Groups |
| ------- | ------ | ------ | -------- | ------ | --------- | --------- | -------- | -------- | -------
--- | ---------- | ----------- | ----------- | ------- | ------- | ------- | ------- |
| hanadb1 | yes | ok | | | 1 | 1 | default | default | master
1 | master | worker | master | worker | worker | default | default |
| hanadb2 | yes | ok | | | 2 | 2 | default | default | master
2 | slave | worker | slave | worker | worker | default | default |
| hanadb3 | no | ignore | | | 0 | 0 | default | default | master
3 | slave | standby | standby | standby | standby | default | - |
# Check the instance status
sapcontrol -nr 03 -function GetSystemInstanceList
GetSystemInstanceList
OK
hostname, instanceNr, httpPort, httpsPort, startPriority, features, dispstatus
hanadb2, 3, 50313, 50314, 0.3, HDB|HDB_WORKER, GREEN
hanadb1, 3, 50313, 50314, 0.3, HDB|HDB_WORKER, GREEN
hanadb3, 3, 50313, 50314, 0.3, HDB|HDB_STANDBY, GRAY

b. Execute os seguintes comandos como hn1 adm no nó principal ativo, que é hanadb1 neste caso:

hn1adm@hanadb1:/usr/sap/HN1/HDB03> HDB kill

O nó de espera hanadb3 assumirá o lugar de mestre nó. Aqui está o estado de recursos após o teste de
failover ser concluído:
# Check the instance status
sapcontrol -nr 03 -function GetSystemInstanceList
GetSystemInstanceList
OK
hostname, instanceNr, httpPort, httpsPort, startPriority, features, dispstatus
hanadb2, 3, 50313, 50314, 0.3, HDB|HDB_WORKER, GREEN
hanadb1, 3, 50313, 50314, 0.3, HDB|HDB_WORKER, GRAY
hanadb3, 3, 50313, 50314, 0.3, HDB|HDB_STANDBY, GREEN
# Check the landscape status
python /usr/sap/HN1/HDB03/exe/python_support/landscapeHostConfiguration.py
| Host | Host | Host | Failover | Remove | Storage | Storage | Failover | Failover |
NameServer | NameServer | IndexServer | IndexServer | Host | Host | Worker | Worker |
| | Active | Status | Status | Status | Config | Actual | Config | Actual |
Config | Actual | Config | Actual | Config | Actual | Config | Actual |
| | | | | | Partition | Partition | Group | Group |
Role | Role | Role | Role | Roles | Roles | Groups | Groups |
| ------- | ------ | ------ | -------- | ------ | --------- | --------- | -------- | -------- | ---
------- | ---------- | ----------- | ----------- | ------- | ------- | ------- | ------- |
| hanadb1 | no | info | | | 1 | 0 | default | default |
master 1 | slave | worker | standby | worker | standby | default | - |
| hanadb2 | yes | ok | | | 2 | 2 | default | default |
master 2 | slave | worker | slave | worker | worker | default | default |
| hanadb3 | yes | info | | | 0 | 1 | default | default |
master 3 | master | standby | master | standby | worker | default | default |

c. Reinicie a instância HANA no hanadb1 (isto é, na mesma máquina virtual, onde o servidor de nome foi
morto). O nó hanadb1 voltará a juntar-se ao ambiente e manterá o seu papel de standby.

hn1adm@hanadb1:/usr/sap/HN1/HDB03> HDB start

Depois de o SAP HANA ter começado em hanadb1, espere o seguinte estatuto:

# Check the instance status


sapcontrol -nr 03 -function GetSystemInstanceList
GetSystemInstanceList
OK
hostname, instanceNr, httpPort, httpsPort, startPriority, features, dispstatus
hanadb1, 3, 50313, 50314, 0.3, HDB|HDB_WORKER, GREEN
hanadb2, 3, 50313, 50314, 0.3, HDB|HDB_WORKER, GREEN
hanadb3, 3, 50313, 50314, 0.3, HDB|HDB_STANDBY, GREEN
# Check the landscape status
python /usr/sap/HN1/HDB03/exe/python_support/landscapeHostConfiguration.py
| Host | Host | Host | Failover | Remove | Storage | Storage | Failover | Failover |
NameServer | NameServer | IndexServer | IndexServer | Host | Host | Worker | Worker |
| | Active | Status | Status | Status | Config | Actual | Config | Actual | Config
| Actual | Config | Actual | Config | Actual | Config | Actual |
| | | | | | Partition | Partition | Group | Group | Role
| Role | Role | Role | Roles | Roles | Groups | Groups |
| ------- | ------ | ------ | -------- | ------ | --------- | --------- | -------- | -------- | -------
--- | ---------- | ----------- | ----------- | ------- | ------- | ------- | ------- |
| hanadb1 | yes | info | | | 1 | 0 | default | default | master
1 | slave | worker | standby | worker | standby | default | - |
| hanadb2 | yes | ok | | | 2 | 2 | default | default | master
2 | slave | worker | slave | worker | worker | default | default |
| hanadb3 | yes | info | | | 0 | 1 | default | default | master
3 | master | standby | master | standby | worker | default | default |

d. Mais uma vez, mate o servidor de nome sintetizado no nó principal atualmente ativo (isto é, no nó
hanadb3 ).

hn1adm@hanadb3:/usr/sap/HN1/HDB03> HDB kill

O nó hanadb1 retomará o papel de mestre nó. Após a conclusão do teste de failover, o estado será assim:

# Check the instance status


sapcontrol -nr 03 -function GetSystemInstanceList & python
/usr/sap/HN1/HDB03/exe/python_support/landscapeHostConfiguration.py
GetSystemInstanceList
OK
hostname, instanceNr, httpPort, httpsPort, startPriority, features, dispstatus
GetSystemInstanceList
OK
hostname, instanceNr, httpPort, httpsPort, startPriority, features, dispstatus
hanadb1, 3, 50313, 50314, 0.3, HDB|HDB_WORKER, GREEN
hanadb2, 3, 50313, 50314, 0.3, HDB|HDB_WORKER, GREEN
hanadb3, 3, 50313, 50314, 0.3, HDB|HDB_STANDBY, GRAY
# Check the landscape status
python /usr/sap/HN1/HDB03/exe/python_support/landscapeHostConfiguration.py
| Host | Host | Host | Failover | Remove | Storage | Storage | Failover | Failover |
NameServer | NameServer | IndexServer | IndexServer | Host | Host | Worker | Worker |
| | Active | Status | Status | Status | Config | Actual | Config | Actual | Config
| Actual | Config | Actual | Config | Actual | Config | Actual |
| | | | | | Partition | Partition | Group | Group | Role
| Role | Role | Role | Roles | Roles | Groups | Groups |
| ------- | ------ | ------ | -------- | ------ | --------- | --------- | -------- | -------- | -------
--- | ---------- | ----------- | ----------- | ------- | ------- | ------- | ------- |
| hanadb1 | yes | ok | | | 1 | 1 | default | default | master
1 | master | worker | master | worker | worker | default | default |
| hanadb2 | yes | ok | | | 2 | 2 | default | default | master
2 | slave | worker | slave | worker | worker | default | default |
| hanadb3 | no | ignore | | | 0 | 0 | default | default | master
3 | slave | standby | standby | standby | standby | default | - |

e. Inicie o SAP HANA em hanadb3, que estará pronto para servir como um nó de espera.

hn1adm@hanadb3:/usr/sap/HN1/HDB03> HDB start

Depois de o SAP HANA ter começado em hanadb3, o estado parece ser o seguinte:
# Check the instance status
sapcontrol -nr 03 -function GetSystemInstanceList & python
/usr/sap/HN1/HDB03/exe/python_support/landscapeHostConfiguration.py
GetSystemInstanceList
OK
hostname, instanceNr, httpPort, httpsPort, startPriority, features, dispstatus
GetSystemInstanceList
OK
hostname, instanceNr, httpPort, httpsPort, startPriority, features, dispstatus
hanadb1, 3, 50313, 50314, 0.3, HDB|HDB_WORKER, GREEN
hanadb2, 3, 50313, 50314, 0.3, HDB|HDB_WORKER, GREEN
hanadb3, 3, 50313, 50314, 0.3, HDB|HDB_STANDBY, GRAY
# Check the landscape status
python /usr/sap/HN1/HDB03/exe/python_support/landscapeHostConfiguration.py
| Host | Host | Host | Failover | Remove | Storage | Storage | Failover | Failover |
NameServer | NameServer | IndexServer | IndexServer | Host | Host | Worker | Worker |
| | Active | Status | Status | Status | Config | Actual | Config | Actual | Config
| Actual | Config | Actual | Config | Actual | Config | Actual |
| | | | | | Partition | Partition | Group | Group | Role
| Role | Role | Role | Roles | Roles | Groups | Groups |
| ------- | ------ | ------ | -------- | ------ | --------- | --------- | -------- | -------- | -------
--- | ---------- | ----------- | ----------- | ------- | ------- | ------- | ------- |
| hanadb1 | yes | ok | | | 1 | 1 | default | default | master
1 | master | worker | master | worker | worker | default | default |
| hanadb2 | yes | ok | | | 2 | 2 | default | default | master
2 | slave | worker | slave | worker | worker | default | default |
| hanadb3 | no | ignore | | | 0 | 0 | default | default | master
3 | slave | standby | standby | standby | standby | default | - |

Passos seguintes
Planeamento e implementação de Máquinas Virtuais Azure para SAP
Implantação de Máquinas Virtuais Azure para SAP
Implantação de DBMS de Máquinas Virtuais Azure para SAP
Para aprender como estabelecer alta disponibilidade e plano para a recuperação de desastres de SAP HANA em
VMs Azure, consulte Alta Disponibilidade de SAP HANA em Máquinas Virtuais Azure (VMs).
Implemente um sistema de escala SAP HANA com
nó de standby em VMs Azure utilizando ficheiros
Azure NetApp em Red Hat Enterprise Linux
30/04/2020 • 55 minutes to read • Edit Online

Este artigo descreve como implementar um sistema SAP HANA altamente disponível numa configuração de escala
com standby em máquinas virtuais Azure Red Hat Enterprise Linux (VMs), utilizando ficheiros Azure NetApp para
os volumes de armazenamento partilhados.
Nas configurações de exemplo, comandos de instalação, e assim por diante, a instância HANA é 03 e o ID do
sistema HANA é HN1 . Os exemplos são baseados em HANA 2.0 SP4 e Red Hat Enterprise Linux para SAP 7.6.
Antes de começar, consulte as seguintes notas e documentos SAP:
Documentação de Ficheiros Azure NetApp
Nota SAP 1928533 inclui:
Uma lista de tamanhos De VM Azure que são suportados para a implementação de software SAP
Informações importantes sobre a capacidade para tamanhos de VM Azure
Software SAP suportado e sistema operativo (OS) e combinações de bases de dados
A versão necessária para o kernel SAP necessário para Windows e Linux no Microsoft Azure
Nota [SAP 2015553]: Lista os pré-requisitos para implementações de software SAP suportadas pelo SAP em
Azure
SAP Note [2002167] recomendou definições de SO para Red Hat Enterprise Linux
SAP Nota 2009879 tem Diretrizes SAP HANA para Red Hat Enterprise Linux
Nota [SAP 2178632]: Contém informações detalhadas sobre todas as métricas de monitorização reportadas
para o SAP em Azure
Nota [SAP 2191498]: Contém a versão necessária do Agente anfitrião SAP para linux em Azure
Nota [SAP 2243692]: Contém informações sobre licenciamento SAP em Linux em Azure
Nota [SAP 1999351]: Contém informações adicionais de resolução de problemas para a extensão de
monitorização melhorada do Azure para o SAP
Nota [SAP 1900823]: Contém informações sobre os requisitos de armazenamento do SAP HANA
SAP Community Wiki: Contém todas as notas SAP necessárias para Linux
Planeamento e implementação de Máquinas Virtuais Azure para SAP em Linux
Implantação de Máquinas Virtuais Azure para SAP em Linux
Implantação de DBMS de Máquinas Virtuais Azure para SAP em Linux
Documentação Geral RHEL
Visão geral de complemento de alta disponibilidade
Administração add-on de alta disponibilidade
Referência addon de alta disponibilidade
Guia de rede red hat enterprise Linux
Documentação RHEL específica do Azure:
Instale SAP HANA no Red Hat Enterprise Linux para utilização no Microsoft Azure
Aplicações NetApp SAP no Microsoft Azure utilizando ficheiros Azure NetApp

Descrição geral
Um método para alcançar a alta disponibilidade da HANA é configurando a falha automática do anfitrião. Para
configurar a falha automática do anfitrião, adicione uma ou mais máquinas virtuais ao sistema HANA e configure-
as como nós de espera. Quando o nó ativo falha, um nó de espera assume automaticamente. Na configuração
apresentada com máquinas virtuais Azure, obtém-se falhas automáticas utilizando o NFS em Ficheiros Azure
NetApp.

NOTE
O nó de espera precisa de acesso a todos os volumes de base de dados. Os volumes HANA devem ser montados como
volumes NFSv4. O mecanismo de bloqueio melhorado baseado no aluguer de ficheiros I/O no protocolo NFSv4 é utilizado
para esgrima.

IMPORTANT
Para construir a configuração suportada, deve implantar os dados hana e os volumes de registo como volumes NFSv4.1 e
montá-los utilizando o protocolo NFSv4.1. A configuração de falha automática do hospedeiro HANA com nó de standby não
é suportada com NFSv3.

No diagrama anterior, que segue as recomendações da rede SAP HANA, três subredes estão representadas dentro
de uma rede virtual Azure:
Para comunicação com clientes
Para comunicação com o sistema de armazenamento
Para comunicação interna hana inter-nó
Os volumes Azure NetApp estão em subnet separada, delegada em Ficheiros Azure NetApp.
Para esta configuração de exemplo, as subredes são:
client 10.9.1.0/26
storage 10.9.3.0/26
hana 10.9.2.0/26
anf 10.9.0.0.0/26 (subnet delegada aos Ficheiros Azure NetApp)

Configurar a infraestrutura de ficheiros Azure NetApp


Antes de avançar com a configuração da infraestrutura de Ficheiros Azure NetApp, familiarize-se com a
documentação dos Ficheiros Azure NetApp.
Os Ficheiros Azure NetApp estão disponíveis em várias regiões do Azure. Verifique se a sua região azure
selecionada oferece ficheiros Azure NetApp.
Para obter informações sobre a disponibilidade de Ficheiros Azure NetApp pela região do Azure, consulte a
disponibilidade de ficheiros Azure NetApp pela região do Azure.
Antes de implementar ficheiros Azure NetApp, solicite o embarque nos Ficheiros Azure NetApp, indo ao Registo de
Instruções de Ficheiros Azure NetApp.
Implementar recursos de Ficheiros Azure NetApp
As seguintes instruções pressupõem que já implementou a sua rede virtual Azure. Os recursos e VMs do Azure
NetApp, onde serão montados os recursos dos Ficheiros Azure NetApp, devem ser implantados na mesma rede
virtual Azure ou em redes virtuais Azure.
1. Se ainda não disponibilizou os recursos, solicite o embarque nos Ficheiros AzurAppdo Azure .
2. Crie uma conta NetApp na sua região Azure selecionada seguindo as instruções em Criar uma conta
NetApp.
3. Criar um conjunto de capacidades de Ficheiros Azure NetApp seguindo as instruções em Configurar um
conjunto de capacidades de Ficheiros Azure NetApp.
A arquitetura HANA apresentada neste artigo utiliza um único conjunto de capacidades azure NetApp Files
ao nível do Ultra Service. Para cargas de trabalho HANA no Azure, recomendamos a utilização de um
Nívelde serviço Azure NetApp Files Ultra ou Premium .
4. Delege uma sub-rede para ficheiros Azure NetApp, conforme descrito nas instruções em Delegar uma sub-
rede para ficheiros Azure NetApp.
5. Implemente volumes de Ficheiros Azure NetApp seguindo as instruções em Criar um volume NFS para
Ficheiros Azure NetApp.
À medida que está a implementar os volumes, certifique-se de selecionar a versão NFSv4.1. Implementar
os volumes na sub-redede Ficheiros Azure NetApp designados . Os endereços IP dos volumes Azure NetApp
são atribuídos automaticamente.
Tenha em mente que os recursos do Azure NetApp Files e os VMs Azure devem estar na mesma rede virtual
Azure ou em redes virtuais Azure. Por exemplo, HN1 -data-mnt00001, HN1 -log-mnt00001, e assim por
diante, são os nomes de volume e nfs://10.9.0.4/HN1 -data-mnt00001, nfs://10.9.0.4/HN1 -log-mnt00001, e
assim por diante, são os caminhos de arquivo para os volumes de Ficheiros Azure NetApp.
volume HN1 -data-mnt00001 (nfs://10.9.0.4/HN1 -data-mnt00001)
volume HN1 -data-mnt00002 (nfs://10.9.0.4/HN1 -data-mnt00002)
volume HN1 -log-mnt00001 (nfs://10.9.0.4/HN1 -log-mnt00001)
volume HN1 -log-mnt00002 (nfs://10.9.0.4/HN1 -log-mnt00002)
volume HN1 -partilhado (nfs://10.9.0.4/HN1 -partilhado)
Neste exemplo, usamos um volume de Ficheiros Azure NetApp separado para cada dados hana e volume de
registo. Para uma configuração mais otimizada em custos em sistemas menores ou não produtivos, é
possível colocar todos os suportes de dados num único volume e todos os troncos montados num volume
único diferente.
Considerações importantes
Enquanto está a criar os seus Ficheiros Azure NetApp para sap HANA scale-out com cenário de stand by nós, esteja
ciente das seguintes considerações importantes:
A piscina de capacidade mínima é de 4 tebibytes (TiB).
O tamanho mínimo do volume é de 100 gibibytes (GiB).
Os Ficheiros Azure NetApp e todas as máquinas virtuais onde serão montados os volumes dos Ficheiros Azure
NetApp devem estar na mesma rede virtual Azure ou em redes virtuais na mesma região.
A rede virtual selecionada deve ter uma subrede delegada nos Ficheiros Azure NetApp.
A produção de um volume de Ficheiros Azure NetApp é uma função do nível de quota de volume e de serviço,
tal como documentado no nível de Serviço para Ficheiros Azure NetApp. Ao dimensionar os volumes HANA
Azure NetApp, certifique-se de que a entrada resultante satisfaz os requisitos do sistema HANA.
Com a política de exportaçãode Ficheiros Azure NetApp, pode controlar os clientes permitidos, o tipo de acesso
(ler, ler apenas, e assim por diante).
A funcionalidade De Ficheiros Azure NetApp ainda não está ciente da zona. Atualmente, a funcionalidade não é
implantada em todas as zonas de disponibilidade de uma região do Azure. Esteja ciente das potenciais
implicações de latência em algumas regiões de Azure.

IMPORTANT
Para as cargas de trabalho da SAP HANA, a baixa latência é crítica. Trabalhe com o seu representante da Microsoft para
garantir que as máquinas virtuais e os volumes de Ficheiros Azure NetApp são implantados nas proximidades.

Dimensionamento para base de dados HANA em Ficheiros Azure NetApp


A entrada de um volume de Ficheiros Azure NetApp é uma função do tamanho do volume e nível de serviço,
conforme documentado no nível de Serviço para Ficheiros Azure NetApp.
Ao conceber a infraestrutura para SAP em Azure, esteja ciente de alguns requisitos mínimos de armazenamento
pela SAP, que se traduzem em características mínimas de rendimento:
Leia a escrita em /hana/log de 250 megabytes por segundo (MB/s) com tamanhos de 1-MB I/O.
Leia a atividade de pelo menos 400 MB/s para /hana/dados para tamanhos de 16 MB e 64-MB I/O.
Escreva atividade de pelo menos 250 MB/s para /hana/dados com tamanhos de 16 MB e 64-MB I/O.
Os limites de produção dos Ficheiros Azure NetApp por 1 TiB de quota de volume são:
Premium Nível de Armazenamento - 64 MiB/s
Nível de Ultra Armazenamento - 128 MiB/s
Para satisfazer os requisitos mínimos de entrada de dados e registos saps, e as diretrizes para /hana/partilhado, os
tamanhos recomendados seriam:

TA M A N H O DE
N ÍVEL DE TA M A N H O DE
A RM A Z EN A M EN TO N ÍVEL ULT RA P ROTO C O LO N F S
VO L UM E P REM IUM A RM A Z EN A M EN TO SUP O RTA DO

/hana/log/ 4 TiB 2 TiB v4.1

/hana/dados 6.3 Tib 3.2 Tib v4.1

/hana/compartilhado 1xRAM por 4 nódeos de 1xRAM por 4 nódeos de v3 ou v4.1


trabalhador trabalhador

A configuração SAP HANA para o layout que é apresentado neste artigo, utilizando o nível de Ultra
Armazenamento de Ficheiros Azure NetApp, seria:

TA M A N H O DE
VO L UM E N ÍVEL ULT RA A RM A Z EN A M EN TO P ROTO C O LO N F S SUP O RTA DO

/hana/log/mnt000001 2 TiB v4.1

/hana/log/mnt000002 2 TiB v4.1

/hana/data/mnt000001 3.2 Tib v4.1

/hana/data/mnt000002 3.2 Tib v4.1

/hana/compartilhado 2 TiB v3 ou v4.1

NOTE
As recomendações de dimensionamento do Azure NetApp, aqui indicadas, destinam-se a cumprir os requisitos mínimos que
a SAP recomenda para os seus fornecedores de infraestruturas. Em implementações reais de clientes e cenários de carga de
trabalho, estes tamanhos podem não ser suficientes. Utilize estas recomendações como ponto de partida e adapte-se, com
base nos requisitos da sua carga de trabalho específica.

TIP
Pode redimensionar os volumes do Azure NetApp De forma dinâmica, sem ter de desmontar os volumes, parar as máquinas
virtuais ou parar o SAP HANA. Esta abordagem permite flexibilidade para satisfazer as exigências de entrada esperadas e
imprevistas da sua aplicação.

Implementar máquinas virtuais Linux através do portal Azure


Primeiro, é necessário criar os volumes de Ficheiros Azure NetApp. Em seguida, faça os seguintes passos:
1. Crie as subredes de rede virtual Azure na sua rede virtual Azure.
2. Implante os VMs.
3. Crie as interfaces de rede adicionais e fixe as interfaces de rede aos VMs correspondentes.
Cada máquina virtual tem três interfaces de rede, que correspondem storage hana às três redes virtuais
Azure (e). client
Para mais informações, consulte Criar uma máquina virtual Linux em Azure com vários cartõesde interface
de rede .

IMPORTANT
Para as cargas de trabalho da SAP HANA, a baixa latência é crítica. Para obter baixa latência, trabalhe com o seu representante
da Microsoft para garantir que as máquinas virtuais e os volumes de Ficheiros Azure NetApp são implantados nas
proximidades. Quando estiver a embarcar no novo sistema SAP HANA que está a utilizar ficheiros SAP HANA Azure NetApp,
submeta as informações necessárias.

As próximas instruções assumem que já criou o grupo de recursos, a rede virtual client storage Azure e as três
redes virtuais Azure: e hana . Quando implementar os VMs, selecione a subnet do cliente, de modo a que a
interface de rede do cliente seja a interface principal nos VMs. Também terá de configurar uma rota explícita para a
sub-rede delegada dos Ficheiros Azure Net através do portal de sub-rede de armazenamento.

IMPORTANT
Certifique-se de que o SISTEMA selecionado é certificado por SAP HANA nos tipos de VM específicos que está a utilizar. Para
obter uma lista de tipos vM certificados SAP HANA e lançamentos de SO para esses tipos, vá ao site de plataformas IaaS
certificadas sAP HANA. Clique nos detalhes do tipo VM listado para obter a lista completa de lançamentos de SAP HANA
suportados por SAP HANA para esse tipo.

1. Crie um conjunto de disponibilidade para o SAP HANA. Certifique-se de que define o domínio da atualização
máxima.
2. Criar três máquinas virtuais (hanadb1, hanadb2, hanadb3 ) fazendo os seguintes passos:
a. Use uma imagem de Linux da Red Hat Enterprise na galeria Azure que é suportada para sap HANA.
Usamos uma imagem RHEL-SAP-HA 7.6 neste exemplo.
b. Selecione o conjunto de disponibilidade que criou anteriormente para o SAP HANA.
c. Selecione a subnet de rede virtual do cliente Azure. Selecione Rede Acelerada.
Quando se implanta as máquinas virtuais, o nome da interface de rede é gerado automaticamente. Nestas
instruções de simplicidade, referimo-nos às interfaces de rede geradas automaticamente, que estão ligadas à
subnet de rede virtual do cliente Azure, como hanadb1-cliente , hanadb2-client, e hanadb3-client .
3. Crie três interfaces de rede, uma storage para cada máquina virtual, para a subnet de rede virtual (neste
exemplo, hanadb1-storage, hanadb2-storage, e hanadb3-storage).
4. Crie três interfaces de rede, uma hana para cada máquina virtual, para a subnet de rede virtual (neste
exemplo, hanadb1-hana, hanadb2-hana , e hanadb3-hana).
5. Fixe as interfaces de rede virtual recém-criadas às máquinas virtuais correspondentes, fazendo os seguintes
passos:
a. Vá à máquina virtual no portal Azure.
b. No painel esquerdo, selecione Máquinas Vir tuais . Filtre no nome da máquina virtual (por exemplo,
hanadb1 ), e, em seguida, selecione a máquina virtual.
c. No painel de visão geral, selecione Parar para desalojar a máquina virtual.
d. Selecione Networking e, em seguida, fixe a interface de rede. Na lista de drop-down da interface da rede
Attach, selecione as interfaces de rede já criadas para as storage redes e hana subnets.
e. Selecione Guardar .
f. Repita os passos b através e para as restantes máquinas virtuais (no nosso exemplo, hanadb2 e
hanadb3 ).
g. Deixe as máquinas virtuais em estado de parada por enquanto. Em seguida, permitiremos uma rede
acelerada para todas as interfaces de rede recém-anexadas.
6. Ativar a ligação acelerada de rede storage hana para as interfaces de rede adicionais para as e subnets
adicionais, fazendo os seguintes passos:
a. Abra a Nuvem Azure no portal Azure.
b. Execute os seguintes comandos para permitir a ligação de rede storage acelerada para as interfaces de
rede adicionais, que estão ligadas às e hana subredes.

az network nic update --id /subscriptions/your subscription/resourceGroups/your resource


group/providers/Microsoft.Network/networkInterfaces/hanadb1-storage --accelerated-networking true
az network nic update --id /subscriptions/your subscription/resourceGroups/your resource
group/providers/Microsoft.Network/networkInterfaces/hanadb2-storage --accelerated-networking true
az network nic update --id /subscriptions/your subscription/resourceGroups/your resource
group/providers/Microsoft.Network/networkInterfaces/hanadb3-storage --accelerated-networking true

az network nic update --id /subscriptions/your subscription/resourceGroups/your resource


group/providers/Microsoft.Network/networkInterfaces/hanadb1-hana --accelerated-networking true
az network nic update --id /subscriptions/your subscription/resourceGroups/your resource
group/providers/Microsoft.Network/networkInterfaces/hanadb2-hana --accelerated-networking true
az network nic update --id /subscriptions/your subscription/resourceGroups/your resource
group/providers/Microsoft.Network/networkInterfaces/hanadb3-hana --accelerated-networking true

7. Inicie as máquinas virtuais fazendo os seguintes passos:


a. No painel esquerdo, selecione Máquinas Vir tuais . Filtre no nome da máquina virtual (por exemplo,
hanadb1 ), e, em seguida, selecione-o.
b. No painel de visão geral, selecione Iniciar .

Configuração e preparação do sistema operativo


As instruções nas secções seguintes são pré-fixadas com uma das seguintes:
[A] : Aplicável a todos os nós
[1] : Aplicável apenas ao nó 1
[2] : Aplicável apenas ao nó 2
[3] : Aplicável apenas ao nó 3
Configure e prepare o seu SISTEMA fazendo os seguintes passos:
1. [A] Mantenha os ficheiros do anfitrião nas máquinas virtuais. Incluir entradas para todas as subredes. Para
este exemplo, /etc/hosts foram adicionadas as seguintes entradas.
# Storage
10.9.3.4 hanadb1-storage
10.9.3.5 hanadb2-storage
10.9.3.6 hanadb3-storage
# Client
10.9.1.5 hanadb1
10.9.1.6 hanadb2
10.9.1.7 hanadb3
# Hana
10.9.2.4 hanadb1-hana
10.9.2.5 hanadb2-hana
10.9.2.6 hanadb3-hana

2. [A] Adicione uma rota de rede, de modo que a comunicação aos Ficheiros Azure NetApp vá através da
interface da rede de armazenamento.
Neste exemplo utilizará Networkmanager para configurar a rota de rede adicional. As seguintes instruções
pressupõem eth1 que a interface da rede de armazenamento é .
Primeiro, determine o nome eth1 de ligação do dispositivo . Neste exemplo, o nome eth1
Wired connection 1 de ligação para dispositivo é .

# Execute as root
nmcli connection
# Result
#NAME UUID TYPE DEVICE
#System eth0 5fb06bd0-0bb0-7ffb-45f1-d6edd65f3e03 ethernet eth0
#Wired connection 1 4b0789d1-6146-32eb-83a1-94d61f8d60a7 ethernet eth1

Em seguida, configure a rota adicional para eth1 a rede delegada de Ficheiros Azure NetApp através de .

# Add the following route


# ANFDelegatedSubnet/cidr via StorageSubnetGW dev StorageNetworkInterfaceDevice
nmcli connection modify "Wired connection 1" +ipv4.routes "10.9.0.0/26 10.9.3.1"

Reiniciar o VM para ativar as alterações.


3. [A] Instale o pacote de clientes nFS.

yum install nfs-utils

4. [A] Prepare o SISTEMA para executar SAP HANA no Azure NetApp com NFS, conforme descrito nas
aplicações NetApp SAP no Microsoft Azure utilizando ficheiros Azure NetApp. Crie ficheirode configuração
/etc/sysctl.d/netapp-hana.conf para as definições de configuração do NetApp.
vi /etc/sysctl.d/netapp-hana.conf
# Add the following entries in the configuration file
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.core.rmem_default = 16777216
net.core.wmem_default = 16777216
net.core.optmem_max = 16777216
net.ipv4.tcp_rmem = 65536 16777216 16777216
net.ipv4.tcp_wmem = 65536 16777216 16777216
net.core.netdev_max_backlog = 300000 net.ipv4.tcp_slow_start_after_idle=0 net.ipv4.tcp_no_metrics_save
= 1
net.ipv4.tcp_moderate_rcvbuf = 1
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_timestamps = 1
net.ipv4.tcp_sack = 1

5. [A] Criar ficheiro de configuração /etc/sysctl.d/ms-az.conf com configurações adicionais de otimização.

vi /etc/sysctl.d/ms-az.conf
# Add the following entries in the configuration file
ipv6.conf.all.disable_ipv6 = 1
net.ipv4.tcp_max_syn_backlog = 16348
net.ipv4.ip_local_port_range = 40000 65300
net.ipv4.conf.all.rp_filter = 0
sunrpc.tcp_slot_table_entries = 128
vm.swappiness=10

6. [A] Ajuste as definições sunrpc, conforme recomendado nas aplicações NetApp SAP no Microsoft Azure
utilizando ficheiros Azure NetApp.

vi /etc/modprobe.d/sunrpc.conf
# Insert the following line
options sunrpc tcp_max_slot_table_entries=128

7. [A] Chapéu Vermelho para configuração HANA.<