Visão geral para automatizar a implementação de HA de carga de trabalho do SAP no IBM Cloud® Virtual Private Cloud (VPC) (Terraform e Ansible )
Você pode usar o Terraform para automatizar o provisionamento do IBM Cloud VPC. A VPC fornecida inclui instâncias de servidor virtual com alto desempenho de rede. A infraestrutura VPC contém várias ofertas de Infrastructure-as-a-Service (IaaS), incluindo Virtual Servers. Depois que a VPC é provisionada, os scripts usam o Ansible Playbook para instalar o sistema SAP.
IBM Cloud® Introdução à VPC
Uma VPC é uma oferta de nuvem pública que uma empresa usa para estabelecer seu próprio ambiente de computação em forma de nuvem privada na infraestrutura de nuvem pública compartilhada. As VPCs dão a uma empresa a capacidade de definir e controlar uma rede virtual logicamente isolada de todos os outros locatários de nuvem pública, criando um lugar privado e seguro na nuvem pública.
Imagine que a infraestrutura de um provedor de nuvem é um prédio de apartamentos residenciais com várias famílias vivendo nele. Ser um locatário de nuvem pública é como dividir um apartamento com alguns colegas. Por outro lado, ter uma VPC é como ter seu próprio condomínio privado; ninguém mais tem a chave e ninguém pode entrar no espaço sem sua permissão.
O isolamento lógico de uma VPC é implementado usando funções de rede virtual e recursos de segurança que dão um controle granular de cliente corporativo sobre quais endereços IP ou aplicativos podem acessar determinados recursos. É como os controles "apenas-amigos" ou "públicos/privados" nas contas de mídia social usados para restringir quem pode ou não ver seus posts antes públicos.
Com o IBM Cloud VPC, você pode usar a interface do usuário, a CLI e a API para provisionar manualmente instâncias de servidor virtual para VPC com alto desempenho de rede. A infraestrutura VPC contém várias ofertas de infraestrutura como serviço ( IaaS ), incluindo Virtual Servers for VPC. Use as informações a seguir para entender um caso de uso simples para planejamento, criação e configuração de recursos para a VPC e conheça mais visões gerais e tutoriais de VPC. Para obter mais informações sobre VPC, consulte Introdução ao Virtual Private Cloud (VPC).
SAP arquitetura de produtos em IBM Cloud VPC
Uma nuvem privada virtual(VPC) contém um dos ambientes de nuvem mais seguros e confiáveis para aplicativos SAP em sua própria VPC com suas instâncias de servidor virtual incluídas. Isso representa uma Infraestrutura como Serviço ( IaaS ){: external} dentro de IBM Cloud que oferece todos os benefícios da infraestrutura de nuvem virtual isolada, segura e flexível de IBM. Em comparação, a oferta de servidores virtuais de infraestrutura clássica da IBM Cloud usa instâncias virtuais com rede nativa e VLAN para se comunicarem entre si em um data center; no entanto, as instâncias são restritas em um pod que funciona bem, usando rede de sub-rede e VLAN, já que um aumento de escala de recursos virtuais deve depender de uma lacuna entre os pods. O que há de novo no IBM Cloud VPC é um conceito de camada de orquestrador de rede que elimina os limites e as restrições dos pods, de modo que esse novo conceito lida com toda a rede de cada instância virtual em execução na VPC entre regiões e zonas.
Sistema altamente disponível para SAP NetWeaver em IBM Cloud VPC
Em um sistema altamente disponível (HA), cada instância pode ser executada em uma instância separada do servidor virtual IBM Cloud. A configuração de HA do cluster para o servidor de aplicativos SAP consiste em duas instâncias de servidor virtual, cada uma delas localizada na mesma zona para zona única ou em zonas diferentes para zona múltipla dentro da mesma região, usando grupos de posicionamento. Os grupos de posicionamento garantem que os recursos do cluster e os recursos da nuvem também estejam localizados em nós de computação diferentes, conforme especificado na seção de grupos de posicionamento a seguir.
Grupos de posicionamento no IBM Cloud VPC para a arquitetura SAP HA
Os grupos de posicionamento (PG) para VPC têm duas estratégias diferentes de antiafinidade para alta disponibilidade. Ao usar estratégias de posicionamento, você minimiza a chance de interrupção do serviço com instâncias de servidores virtuais que são colocadas em hosts diferentes ou em uma infraestrutura com fontes de alimentação e de rede separadas.
O design de grupos de colocação para os servidores virtuais do IBM Cloud soluciona esse problema. Os grupos de colocação fornecem uma medida de controle sobre o host no qual um novo servidor virtual público é colocado. Com esta versão, uma regra de "propagação" é implementada, o que significa que os servidores virtuais em um grupo de posicionamento são todos distribuídos em hosts diferentes. Você pode criar um aplicativo altamente disponível em um data center e saber que seus servidores virtuais estão isolados uns dos outros.
Os grupos de colocação com a regra de "difusão" estão disponíveis para criar em data centers do IBM Cloud selecionados. Depois que uma regra de "propagação" for criada, você poderá provisionar um servidor virtual nesse grupo e garantir que ele não esteja no mesmo host que nenhum dos outros servidores virtuais. E o melhor de tudo? Não há absolutamente nenhum encargo para usar esse recurso.
Você pode criar seu grupo de posicionamento e, em seguida, atribuir até quatro novas instâncias de servidor virtual. Com a regra de "difusão", cada um de seus servidores virtuais é provisionado em hosts físicos diferentes. Nos exemplos de configuração a seguir, a opção "Power Spread" é usada.
Essas são as seguintes instâncias do SAP que são necessárias para um cenário de HA:
- Instância de serviços centrais ABAP (instância ASCS)- contém o servidor de mensagens ABAP e o servidor de filas ABAP
- Enfileirar a instância do servidor de replicação (instância ERS) para a instância ASCS
- Instância de banco de dados
- Instância primária do aplicativo (PAS) no nó 1
- Instância de aplicativo adicional (AAS) no nó 2
Recomenda-se que você execute a instância do ASCS e a instância do ERS em uma infraestrutura de cluster de alternância.
IBM Cloud File Storage for VPC para a arquitetura SAP HA
IBM Cloud File Storage for VPC é usada para tornar os diretórios SAP disponíveis para o sistema SAP. As tecnologias escolhidas são NFS, discos compartilhados e sistema de arquivos em cluster. Se você decidiu usar uma solução de alta disponibilidade (HA) para o seu sistema SAP, certifique-se de atender adequadamente aos requisitos de HA dos sistemas de arquivos SAP no seu ambiente SAP.
- Compartilhamentos de arquivos que são montados como sistemas de arquivos permanentes NFS em ambos os nós do cluster para SAP apps HA:
/usr/sap/<SAPSID>/SYS/sapmnt<SAPSID>/usr/sap/trans
- Sistemas de arquivos gerenciados por cluster para SAP Apps HA: ASCS si ERS
/usr/sap/<SAPSID>/ASCS00/usr/sap/<SAPSID>/ERS01
- Montagem permanente em NFS na instância PAS do nó 1 do SAP Apps HA:
/usr/sap/<SAPSID>/Dxx
- Montagem permanente em NFS na instância de diálogo SAP Apps HA node 2:
/usr/sap/<SAPSID>/Dyy
Pré-requisitos
Você precisa instalar o hardware (hosts, discos e rede) e decidir como distribuir o banco de dados, as instâncias do SAP e, se necessário, o servidor do Network File System ( NFS ) nos nós do cluster.
Contexto
Do ponto de vista de um aplicativo SAP, esses são os tipos de diretórios SAP:
- Diretórios fisicamente compartilhados:
/<sapmnt>/<SAPSID>e/usr/sap/trans - Diretórios logicamente compartilhados que estão vinculados a um nó, como
/usr/sap, com os seguintes diretórios locais:/usr/sap/<SAPSID>/usr/sap/<SAPSID>/SYS/usr/sap/hostctrl
- Diretórios locais que contêm as instâncias do SAP, como
/usr/sap/<SAPSID>/ASCS<Instance_Number> - O diretório de transporte global pode residir em um host de transporte SAP separado como uma configuração padrão da camada de transporte de três sistemas.
Você precisa de pelo menos dois nós e um sistema de arquivos compartilhado para instâncias distribuídas do ASCS e do ERS, e supõe-se que o restante dos componentes seja distribuído em outros nós.
Instalação do ASCS e do ERS
Para que as instâncias do ASCS e do ERS possam ser movidas de um nó para o outro, elas precisam ser instaladas em um sistema de arquivos compartilhado e usar nomes de host virtuais com base no IP virtual.
Nessa solução de SAP HA baseada em VPC, o sistema de arquivos compartilhado exigido pelo cluster é substituído pelo armazenamento de arquivos montado em NFS e o IP virtual é substituído pelo Application Load Balancer for VPC (ALB).
Nesse cenário, são usados três ALBs, um para cada componente de ponto único de falha (SPOF), a fim de substituir o requisito de IP virtual: ALB para ASCS, ALB para ERS e ALB para HANA. Cada ALB é configurado como um backend para os servidores de cluster correspondentes e redireciona toda a comunicação recebida nas portas de front-end para o servidor ativo no pool de back-end.
Balanceador de carga do aplicativo privado
Um balanceador de carga de aplicativo privado pode ser acessado por meio das sub-redes privadas que você configurou para criar o balanceador de carga.
Semelhante a um balanceador de carga de aplicativo público, sua instância de serviço de balanceador de carga de aplicativo privado recebe um FQDN; no entanto, esse nome de domínio é registrado com um ou mais endereços IP privados.
As operações do IBM Cloud podem mudar o número e o valor de seus endereços IP privados designados ao longo do tempo, com base nas atividades de manutenção e ajuste de escala. As instâncias de servidor virtual de back-end que hospedam seu aplicativo devem ser executadas na mesma região e na mesma VPC.
Use o FQDN do ALB atribuído para enviar tráfego para o balanceador de carga de aplicativos privados a fim de evitar problemas de conectividade com seus aplicativos durante a manutenção do sistema ou atividades de redução de escala.
Cada ALB envia tráfego para o nó do cluster em que o aplicativo (ASCS, ERS, HANA DB) está sendo executado. Durante o failover do cluster, o ALB redireciona todo o tráfego para o novo nó em que os recursos estão funcionando.
DNSaaS (DNS as a Service) é o serviço de gerenciamento IBM Cloud VPC DNS do mecanismo HA e FQDN (IPs).
O ALB tem um padrão de 50 segundos para o tempo limite do cliente e do servidor, portanto, após 50 segundos de inatividade, as conexões são fechadas. Para oferecer suporte a conexões SAP por meio do ALB e não perder a conexão após 50 segundos, você precisa solicitar uma alteração desse valor para um mínimo de 300 segundos (conexão ociosa do lado do cliente = mínimo 300s e conexão ociosa do lado do servidor = mínimo 300s ). Para solicitar essa alteração, abra um tíquete de suporte. Essa é uma alteração em toda a conta que afeta todos os ALBs em sua conta. Para obter mais informações, consulte Tempo limite de conexão.
DNS Services com VPC
IBM Cloud DNS Services fornece DNS privado aos usuários da VPC. As zonas de DNS privado podem ser resolvidas apenas no IBM Cloud e apenas por meio de redes permitidas explicitamente em uma conta. Para iniciar, crie uma instância do DNS Services usando o console do IBM Cloud.
O DNS Services permite:
- Criar zonas de DNS privado que são coleções para manter nomes de domínio.
- Criar registros de recurso de DNS sob essas zonas de DNS.
- Especificar controles de acesso usados para a resolução de DNS de registros de recurso em um nível de toda a zona.
O DNS Services também mantém o seu próprio conjunto mundial de resolvedores de DNS. As instâncias provisionadas sob o IBM Cloud em uma rede do IBM Cloud podem usar registros de recurso configurados por meio do IBM Cloud DNS Services, consultando resolvedores de DNS Services.
Os registros de recursos e as zonas que são configurados por meio do DNS Services são:
- Separados do DNS público mais amplo e de seus registros publicamente acessíveis.
- Ocultos de máquinas fora da rede privada do IBM Cloud e que não fazem parte dela.
- Acessíveis apenas por meio de máquinas autorizadas na rede privada do IBM Cloud.
- Resolvíveis apenas por meio de resolvedores fornecidos pelo serviço.
O serviço DNS mapeia o FQDN de cada ALB para os nomes de host virtuais do ASCS, ERS e HANA que são usados pelos aplicativos SAP.
Latência de rede entre zonas e regiões da VPC
Para obter informações sobre a latência da rede entre zonas e regiões VPC, consulte o tópico Painéis de latência da rede VPC e execute sua própria medição de acordo com a nota SAP "500235 - Network Diagnosis with NIPING" para realizar uma verificação de latência usando a ferramenta SAP niping.
Os resultados relatados são os medidos. Não há garantias de desempenho implícitas nessas medições. Essas estatísticas fornecem visibilidade da latência entre todas as regiões e zonas para ajudá-lo a planejar a seleção ideal para sua implementação na nuvem e planejar cenários, como residência de dados e desempenho.
Sistema altamente disponível para o banco de dados SAP HANA
No nível mais básico, um cluster HA HANA padrão em uma configuração ativo-passivo tem dois nós: um é o nó primário e o outro é o nó de espera. Isso significa simplesmente que o nó primário está servindo ativamente as instâncias ativas do SAP (PAS e AAS), enquanto o nó de espera está aguardando para entrar em ação se houver uma falha.
Sistema altamente disponível para a instância do aplicativo SAP
O cluster é definido com um IP de nome de host virtual (o nome de host é mapeado para o FQDN do HANA ALB por meio do DNS, que é o mesmo explicado anteriormente para as instâncias do SAP ASCS e do ERS). Instâncias de aplicativos (PAS e AAS), esses são os detalhes a serem usados nos perfis SAP para chamar esse componente específico. O cluster atribui esse IP virtual ao nó ativo e usa um monitor de heartbeat para confirmar a disponibilidade dos componentes. Se o nó primário parar de responder, ele aciona o mecanismo de failover automático que chama o nó de espera para se tornar o nó primário. O ALB detecta a alteração, redireciona o tráfego para o novo nó ativo e atribui o IP virtual a ele, restaurando a disponibilidade do componente. Depois que o nó com falha é corrigido, ele fica on-line como um nó de espera.
Mecanismo de replicação de banco de dados HANA síncrono no disco (sync) suportado por SAP
O sistema primário aguarda para confirmar a transação até receber uma resposta de que o registro está armazenado no sistema secundário. Essa opção garante consistência imediata entre os dois sistemas, com o custo de atrasar a transação pelo tempo de transmissão e persistência dos dados no sistema secundário.
Quando a conexão com o sistema secundário é perdida, o sistema primário continua o processamento da transação e grava as alterações somente no disco local. Não ocorrerá perda de dados nesse cenário se o sistema secundário estiver conectado. Pode ocorrer perda de dados quando um takeover é executado enquanto o sistema secundário está desconectado.
Além disso, esse modo de replicação pode ser executado com uma opção de sincronização completa. Isso significa que a gravação de log foi bem-sucedida quando o buffer de log foi gravado no arquivo de log do sistema primário e secundário. Quando
o sistema secundário é desconectado (por exemplo, devido a uma falha na rede), o sistema primário suspende o processamento da transação até que a conexão com o sistema secundário seja restabelecida. Não ocorre perda de dados nesse cenário.
Você pode definir a opção de sincronização total para a replicação do sistema com o parâmetro [system_replication]/enable_full_sync.
Se a replicação do sistema SAP HANA for executada no modo de replicação de sincronização com a opção de sincronização completa ativada e se a conexão com o site secundário for interrompida, não será possível realizar operações de gravação no site primário. A operação de criação de um banco de dados de locatário, por exemplo, aguarda até que a conexão com o secundário seja restabelecida ou o tempo limite da instrução SQL.
Essa automação é oferecida sem custo; no entanto, a infraestrutura provisionada tem um custo.