Planejar a implantação do SAP com o SAP Deployment Automation Framework

SAP Deployment Automation Framework é uma ferramenta de orquestração de software livre que automatiza as implantações sap em Azure usando o Terraform e o Ansible. Antes de implantar, você precisa planejar assinaturas, gerenciamento de credenciais e design de rede virtual.

Este artigo descreve as principais decisões de planejamento que você precisa tomar antes de começar a implantar. Para obter considerações genéricas sobre o design do SAP no Azure, consulte Introdução a um cenário de adoção do SAP.

Planejamento de assinaturas

Implante o plano de controle e as zonas de carga de trabalho em assinaturas diferentes. O plano de controle deve residir em uma assinatura de hub que hospeda os componentes de gerenciamento da estrutura de automação da SAP.

Hospede os sistemas SAP em assinaturas spoke, que são dedicadas aos sistemas SAP. Por exemplo, você pode hospedar sistemas de desenvolvimento em uma assinatura separada com uma rede virtual dedicada. Os sistemas de produção podem residir em sua própria assinatura com uma rede virtual dedicada.

Essa abordagem fornece um limite de segurança e uma separação clara de tarefas e responsabilidades. Por exemplo, a equipe SAP Basis pode implantar sistemas nas zonas de carga de trabalho e a equipe de infraestrutura pode gerenciar o plano de controle.

Planejamento do plano de controle

Execute as atividades de implantação e configuração a partir de Azure Pipelines ou usando os scripts de shell fornecidos diretamente nas máquinas virtuais Linux (VMs) hospedadas no Azure. Esse ambiente é conhecido como o plano de controle. Para configurar Azure DevOps para a estrutura de implantação, consulte Set up Azure DevOps for SAP Deployment Automation Framework. Para configurar VMs do Linux como o implantador, consulte Configurar VMs do Linux para a Estrutura de Automação de Implantação do SAP.

Antes de criar o painel de controle, considere as seguintes perguntas:

• Em quais regiões você precisa implantar sistemas SAP?
• Há uma assinatura dedicada para o painel de controle?
• Há uma credencial de implantação dedicada (entidade de serviço) para o plano de controle?
• Há uma rede virtual existente ou uma nova rede virtual é necessária?
• Como a Internet de saída é fornecida para as VMs?
• Você vai implantar Firewall do Azure para conectividade de saída com a Internet?
• Os pontos de extremidade privados são necessários para contas de armazenamento e cofres de chaves?
• Você usará uma zona de private DNS existente para as VMs ou usará o plano de controle para hospedar DNS privado?
• Você vai usar Azure Bastion para proteger o acesso remoto às VMs?
• Você usará o aplicativo Web de configuração da Estrutura de Automação de Implantação do SAP para executar atividades de configuração e implantação?

Painel de controle

O plano de controle fornece os seguintes serviços:

• As VMs de Deployment, que realizam implantações com Terraform, configuram o Ansible e atuam como agentes auto-hospedados do Azure DevOps.
• Um cofre de chaves, que contém as credenciais de implantação (entidades de serviço) usadas pelo Terraform ao executar as implantações.
• Firewall do Azure para fornecer conectividade com a Internet de saída.
• Azure Bastion para fornecer acesso remoto seguro às VMs implantadas.
• Uma aplicação Web Azure de configuração do SAP Deployment Automation Framework para realizar atividades de configuração e implantação.

O plano de controle é definido usando dois arquivos de configuração, um para o implantador e outro para a Biblioteca SAP.

O arquivo de configuração do implantador define a região, o nome do ambiente e as informações da rede virtual. Por exemplo:

# Deployer Configuration File
environment = "MGMT"
location = "westeurope"

management_network_logical_name = "DEP01"

management_network_address_space = "10.170.20.0/24"
management_subnet_address_prefix = "10.170.20.64/28"

firewall_deployment = true
management_firewall_subnet_address_prefix = "10.170.20.0/26"

bastion_deployment = true
management_bastion_subnet_address_prefix = "10.170.20.128/26"

use_webapp = true

webapp_subnet_address_prefix = "10.170.20.192/27"
deployer_assign_subscription_permissions = true

deployer_count = 2

use_service_endpoint = false
use_private_endpoint = false
public_network_access_enabled = true

Considerações sobre DNS

Ao planejar a configuração de DNS para a estrutura de automação, considere as seguintes perguntas:

• Existe um DNS privado existente com o qual as soluções podem ser integradas ou você precisa usar uma zona DNS privada personalizada para o ambiente de implantação?
• Você usará endereços IP predefinidos para as VMs ou permitirá que Azure atribua-os dinamicamente?

Para se integrar a uma zona DNS privada existente, forneça os seguintes valores em seus tfvars arquivos:

management_dns_subscription_id = "aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e"
#management_dns_resourcegroup_name = "RESOURCEGROUPNAME"
use_custom_dns_a_registration = false

Sem esses valores, uma zona DNS privada é criada no grupo de recursos da biblioteca SAP.

Para obter mais informações, consulte a explicação detalhada de como configurar o implantador.

Configuração da biblioteca SAP

O grupo de recursos da biblioteca SAP fornece armazenamento para mídia de instalação do SAP, arquivos Lista de Materiais, arquivos de estado do Terraform e, opcionalmente, as zonas DNS privadas. O arquivo de configuração define a região e o nome do ambiente para a Biblioteca SAP. Para obter informações e exemplos de parâmetro, consulte Configurar a biblioteca SAP para automação.

Planejar a zona de carga de trabalho

A maioria dos cenários de aplicativos SAP são particionados em diferentes camadas. Na Estrutura de Automação de Implantação do SAP, essas camadas são chamadas de zonas de carga de trabalho. Por exemplo, você pode ter zonas de carga de trabalho diferentes para desenvolvimento, garantia de qualidade e sistemas de produção. Para obter mais informações, consulte Zonas de carga de trabalho.

A zona de carga de trabalho fornece os seguintes serviços compartilhados para os aplicativos SAP:

• Rede Virtual do Azure, para redes virtuais, sub-redes e grupos de segurança de rede.
• Azure Key Vault, para armazenar a máquina virtual e as credenciais do sistema SAP.
• Contas de Armazenamento do Microsoft Azure para diagnóstico de inicialização e Testemunha de Nuvem.
• Armazenamento compartilhado para os sistemas SAP, Arquivos do Azure ou Azure NetApp Files.

Antes de criar o layout da zona de carga de trabalho, considere as seguintes perguntas:

• Em quais regiões você precisa implantar cargas de trabalho?
• Quantas zonas de carga de trabalho seu cenário requer (desenvolvimento, garantia de qualidade e produção)?
• Você está implantando em novas redes virtuais ou está usando redes virtuais existentes?
• De que tipo de armazenamento você precisa para o armazenamento compartilhado (Arquivos do Azure NFS (NFS ou Compartilhamento de Arquivos de Rede) ou Azure NetApp Files)?
• Você vai implantar o Gateway da NAT para conectividade com a Internet de saída?

A convenção de nomenclatura padrão para zonas de carga de trabalho é [ENVIRONMENT]-[REGIONCODE]-[NETWORK]-INFRASTRUCTURE. Por exemplo, DEV-WEEU-SAP01-INFRASTRUCTURE é para um ambiente de desenvolvimento hospedado na região Oeste da Europa usando a rede virtual SAP01. PRD-WEEU-SAP02-INFRASTRUCTURE é para um ambiente de produção hospedado na região Oeste da Europa usando a rede virtual SAP02.

As designações SAP01 e SAP02 definem os nomes lógicos das redes virtuais Azure. Eles podem ser usados para particionar ainda mais os ambientes. Suponha que você precise de duas redes virtuais Azure para a mesma zona de carga de trabalho. Por exemplo, você pode ter um cenário de várias assinaturas em que hospeda ambientes de desenvolvimento em duas assinaturas. Você pode usar os nomes lógicos diferentes para cada rede virtual. Por exemplo, você pode usar DEV-WEEU-SAP01-INFRASTRUCTURE e DEV-WEEU-SAP02-INFRASTRUCTURE.

Para obter mais informações, consulte Configurar uma implantação de zona de carga de trabalho para automação.

implantações baseadas em Windows

Quando você realiza implantações baseadas em Windows, as VMs na rede virtual da zona de carga de trabalho precisam ser capazes de se comunicar com o Active Directory para ingressar as VMs do SAP no domínio do Active Directory. O nome DNS fornecido precisa ser resolvido por Active Directory.

O SAP Deployment Automation Framework não cria contas no Active Directory, portanto, as contas precisam ser pré-criadas e armazenadas no cofre de chaves da zona de carga de trabalho.

Configurações DNS

Para cenários de alta disponibilidade, um registro DNS é necessário no Active Directory para o cluster de serviços centrais do SAP. O registro DNS precisa ser criado na zona DNS Active Directory. O nome do registro DNS é definido como [sid]>scs[scs instance number]cl1. Por exemplo, w01scs00cl1 é usado para o cluster, com W01 para o SID e 00 para o número da instância.

Gerenciamento de credenciais

A estrutura de automação usa principais de serviço para implantação de infraestrutura. É recomendável usar credenciais de implantação diferentes (entidades de serviço) para cada zona de carga de trabalho. A estrutura armazena essas credenciais no cofre de chaves do implantador. Em seguida, a estrutura recupera as credenciais dinamicamente durante o processo de implantação.

Gerenciamento de credenciais de máquinas virtuais e SAP

A estrutura de automação usa o cofre de chaves da zona de carga de trabalho para armazenar as credenciais do usuário de automação e as credenciais do sistema SAP. A tabela a seguir lista os nomes das credenciais da máquina virtual.

Criação do principal de serviço

Para criar a entidade de serviço:

1. Entre na CLI do Azure com uma conta que tenha permissões para criar uma entidade de serviço.

2. Crie uma nova entidade de serviço executando o comando az ad sp create-for-rbac. Use um nome descritivo para --name. Por exemplo:

   az ad sp create-for-rbac --role="Contributor" --scopes="/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e" --name="DEV-Deployment-Account"
   

3. Observe o resultado. Você precisará do identificador do aplicativo (appId), da senha (password) e do identificador do locatário (tenant) para a próxima etapa. Por exemplo:

   {
       "appId": "00001111-aaaa-2222-bbbb-3333cccc4444",
       "displayName": "DEV-Deployment-Account",
       "name": "http://DEV-Deployment-Account",
       "password": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
       "tenant": "aaaabbbb-0000-cccc-1111-dddd2222eeee"
   }
   

4. Atribua a função de Administrador de Acesso de Usuário ao principal de serviço. Por exemplo:

   az role assignment create --assignee <your-application-ID> --role "User Access Administrator" --scope /subscriptions/<your-subscription-ID>/resourceGroups/<your-resource-group-name>
   

Para obter mais informações, veja a documentação da CLI do Azure sobre como criar uma entidade de serviço.

Gerenciamento de permissões

Em um ambiente bloqueado, talvez seja necessário atribuir outra permissão às entidades de serviço. Por exemplo, talvez seja necessário atribuir a função Administrador de Acesso de Usuários à entidade de serviço.

Permissões necessárias

A tabela a seguir mostra as permissões necessárias para os principais do serviço.

Configuração do firewall

Teste a conectividade com as URLs de uma máquina virtual linux em Azure usando um script do PowerShell que usa o recurso run-command em Azure.

O exemplo a seguir mostra como testar a conectividade com as URLs usando um script interativo do PowerShell.

$sdaf_path = Get-Location
if ( $PSVersionTable.Platform -eq "Unix") {
    if ( -Not (Test-Path "SDAF") ) {
      $sdaf_path = New-Item -Path "SDAF" -Type Directory
    }
}
else {
    $sdaf_path = Join-Path -Path $Env:HOMEDRIVE -ChildPath "SDAF"
    if ( -not (Test-Path $sdaf_path)) {
        New-Item -Path $sdaf_path -Type Directory
    }
}

Set-Location -Path $sdaf_path

git clone https://github.com/Azure/sap-automation.git

cd sap-automation
cd deploy
cd scripts

if ( $PSVersionTable.Platform -eq "Unix") {
 ./Test-SDAFURLs.ps1
}
else {
 .\Test-SDAFURLs.ps1
}

Estrutura de Azure DevOps

A estrutura de implantação usa três repositórios separados para os artefatos de implantação. Para seus arquivos de parâmetro, é uma melhor prática manter esses arquivos em um repositório de controle do código-fonte que você gerencia.

Repositório principal

Esse repositório contém os arquivos de parâmetros do Terraform e os arquivos necessários para os playbooks do Ansible em todas as zonas de trabalho e implantações do sistema.

Crie esse repositório clonando o repositório de inicialização do SAP Deployment Automation Framework no repositório de controle do código-fonte.

Estrutura de pastas

A hierarquia de pastas de exemplo a seguir mostra como estruturar seus arquivos de configuração junto com os arquivos da estrutura de automação.

O nome do arquivo de parâmetro se torna o nome do arquivo de estado do Terraform. Por esse motivo, use um nome de arquivo de parâmetro exclusivo.

Repositório de códigos

Esse repositório contém os modelos de automação do Terraform, os guias estratégicos do Ansible e os pipelines e scripts de implantação. Para a maioria dos casos de uso, considere esse repositório como somente leitura e não modifique-o.

Para criar esse repositório, clone o repositório SAP Deployment Automation Framework no repositório de controle do código-fonte.

Nomeie este repositório sap-automation.

Repositório de exemplo

Esse repositório contém os arquivos de exemplo da Bill of Materials e os arquivos de exemplo de configuração do Terraform.

Para criar esse repositório, clone o repositório de exemplos SAP Deployment Automation Framework no repositório de controle do código-fonte.

Nomeie este repositório samples.

Cenários de implantação com suporte

A estrutura de automação dá suporte à implantação em cenários novos e existentes.

Regiões do Azure

Antes de implantar uma solução, é importante considerar quais Azure regiões a serem usadas. Regiões de Azure diferentes podem estar no escopo, dependendo do cenário específico.

A estrutura de automação dá suporte a implantações em várias regiões Azure. Cada região hospeda:

• A infraestrutura de implantação.
• A biblioteca SAP com arquivos de estado e mídia de instalação.
• Zonas de carga de trabalho 1-N.
• Sistemas SAP 1-N nas zonas de carga de trabalho.

Ambientes de implantação

Se você dá suporte a várias zonas de carga de trabalho em uma região, use um identificador exclusivo para o ambiente de implantação e a Biblioteca SAP. Não use o identificador da zona de carga de trabalho. Por exemplo, use MGMT para fins de gerenciamento.

A estrutura de automação também dá suporte a ter o ambiente de implantação e a Biblioteca SAP em assinaturas separadas das zonas de carga de trabalho.

O ambiente de implantação fornece os seguintes serviços:

• Uma ou mais VMs de implantação, que realizam as implantações de infraestrutura usando o Terraform e fazem a configuração do sistema e a instalação do SAP usando os playbooks do Ansible.
• Um cofre de chaves, que contém informações de identidade da entidade de serviço para uso de implantações do Terraform.
• Um componente Firewall do Azure, que fornece conectividade de saída com a Internet.

O arquivo de configuração da implantação define a região, o nome do ambiente e as informações da rede virtual. Por exemplo:

# The environment value is a mandatory field, it is used for partitioning the environments, for example (PROD and NP)
environment = "MGMT"

# The location/region value is a mandatory field, it is used to control where the resources are deployed
location = "westeurope"

# management_network_address_space is the address space for management virtual network
management_network_address_space = "10.10.20.0/25"

# management_subnet_address_prefix is the address prefix for the management subnet
management_subnet_address_prefix = "10.10.20.64/28"

# management_firewall_subnet_address_prefix is the address prefix for the firewall subnet
management_firewall_subnet_address_prefix = "10.10.20.0/26"

# management_bastion_subnet_address_prefix is a mandatory parameter if bastion is deployed and if the subnets are not defined in the workload or if existing subnets are not used
management_bastion_subnet_address_prefix = "10.10.20.128/26"

deployer_enable_public_ip = false

firewall_deployment = true

bastion_deployment = true

Para obter mais informações, consulte a explicação detalhada de como configurar o implantador.

Estrutura da zona de carga de trabalho

A maioria das configurações do SAP tem várias zonas de carga de trabalho para diferentes camadas de aplicativo. Por exemplo, você pode ter diferentes zonas de carga de trabalho para desenvolvimento, garantia de qualidade e produção.

Você cria ou concede acesso aos seguintes serviços em cada zona de carga de trabalho:

• Azure Redes Virtuais, para redes virtuais, sub-redes e grupos de segurança de rede.
• Azure Key Vault, para credenciais do sistema e a entidade de serviço de implantação.
• Contas de Armazenamento do Azure, para diagnóstico de inicialização e Cloud Witness.
• Armazenamento compartilhado para os sistemas SAP, Arquivos do Azure ou Azure NetApp Files.

Antes de criar o layout da zona de carga de trabalho, considere as seguintes perguntas:

• Quantas zonas de carga de trabalho seu cenário exige?
• Em quais regiões você precisa implantar cargas de trabalho?
• Qual é seu cenário de implantação?

Para obter mais informações, consulte Configurar uma implantação de zona de carga de trabalho para automação.

Configuração do sistema SAP

O sistema SAP contém todos os componentes Azure necessários para hospedar o aplicativo SAP.

Antes de configurar o sistema SAP, considere as seguintes perguntas:

• Qual back-end de banco de dados você deseja usar?
• De quantos servidores de banco de dados você precisa?
• Seu cenário requer alta disponibilidade?
• De quantos servidores de aplicativos você precisa?
• De quantos Web dispatchers você precisa, se precisa?
• De quantas instâncias de serviços centrais você precisa?
• De que tamanho de máquina virtual você precisa?
• Qual imagem de máquina virtual você deseja usar? A imagem está em Azure Marketplace ou personalizada?
• Você está implantando em um cenário de implantação novo ou já existente?
• Qual é a sua estratégia de alocação de IP? Você quer que o Azure defina IPs ou usar configurações personalizadas?

Para obter mais informações, consulte Configurar o sistema SAP para automação.

Fluxo de implantação

Quando você planeja uma implantação, é importante considerar o fluxo geral. Há três etapas principais de uma implantação SAP no Azure com o framework de automação.

1. Implantar o painel de controle. Esta etapa implanta componentes para dar suporte à estrutura de automação sap em uma região de Azure especificada.

   1. Crie o ambiente de implantação.
   2. Crie um armazenamento compartilhado para arquivos de estado do Terraform.
   3. Crie um armazenamento compartilhado para a mídia de instalação do SAP.

2. Implantar a zona de carga de trabalho. Esta etapa implanta os componentes da zona de carga de trabalho, como a rede virtual e os cofres de chaves.

3. Implantar o sistema. Esta etapa inclui a infraestrutura para a implantação do sistema SAP e a configuração do SAP e a instalação do SAP.

Convenções de nomenclatura

A estrutura de automação usa uma convenção de nomenclatura padrão. Se você quiser usar uma convenção de nomenclatura personalizada, planeje e defina seus nomes personalizados antes da implantação. Para obter mais informações, consulte Configurar a convenção de nomenclatura.

Dimensionamento do disco

Se quiser configurar tamanhos de disco personalizados, planeje a configuração personalizada antes da implantação.

Conteúdo relacionado

• Visão geral do SAP Deployment Automation Framework
• Configurar o painel de controle
• Configurar uma implantação de zona de carga de trabalho
• Implantação manual da estrutura de automação