Planeie a sua implementação SAP com o SAP Deployment Automation Framework

SAP Deployment Automation Framework é uma ferramenta de orquestração open-source que automatiza implementações SAP em Azure utilizando Terraform e Ansible. Antes de implementar, precisa de planear subscrições, gestão de credenciais e design de redes virtuais.

Este artigo descreve as principais decisões de planeamento que precisa de tomar antes de começar a implementação. Para considerações de design genéricas para SAP no Azure, veja Introdução a um cenário de adoção de SAP.

Planeamento de subscrições

Implementa o plano de controlo e as zonas de carga de trabalho em diferentes subscrições. O plano de controlo deve residir numa subscrição de hub que aloja os componentes de gestão do framework de automação SAP.

Aloje os sistemas SAP em subscrições "spoke", que são dedicadas aos sistemas SAP. Por exemplo, pode alojar sistemas de desenvolvimento numa subscrição separada com uma rede virtual dedicada. Os sistemas de produção podem residir na sua própria subscrição com uma rede virtual dedicada.

Esta abordagem estabelece tanto uma fronteira de segurança como uma separação clara de deveres e responsabilidades. Por exemplo, a equipe do SAP Basis pode implantar sistemas nas zonas de carga de trabalho e a equipe de infraestrutura pode gerenciar o plano de controle.

Planeamento do plano de controlo

Realize as atividades de implementação e configuração a partir do Azure Pipelines ou utilizando os scripts de shell fornecidos diretamente das máquinas virtuais Linux (VMs) hospedadas no Azure. Este ambiente é conhecido como plano de controlo. Para configurar Azure DevOps para o framework de implementação, consulte Configurar Azure DevOps para SAP Deployment Automation Framework. Para configurar VMs Linux como deployer, consulte Configurar VMs Linux para SAP Deployment Automation Framework.

Antes de projetar seu plano de controle, considere as seguintes perguntas:

• Em quais regiões você precisa implantar sistemas SAP?
• Existe uma subscrição dedicada para o plano de controle?
• Existe uma credencial de implantação dedicada (serviço principal) para o plano de controle?
• Existe uma rede virtual existente ou é necessária uma nova rede virtual?
• Como é que a internet de saída é fornecida para as VMs?
• Vais implementar o Azure Firewall para conectividade à internet de saída?
• Os endpoints privados são necessários para contas de armazenamento e o cofre de chaves?
• Vais usar uma zona private DNS existente para as VMs ou usar o plano de controlo para alojar DNS Privado?
• Vais usar o Azure Bastion para acesso remoto seguro às VMs?
• Você vai usar o aplicativo Web de configuração do SAP Deployment Automation Framework para executar atividades de configuração e implantação?

Plano de controlo

O plano de controlo presta os seguintes serviços:

• VMs de implementação, que realizam implementações do Terraform e configuração do Ansible e atuam como agentes auto-hospedados do Azure DevOps.
• Um cofre de chaves, que contém as credenciais de implementação (entidades de serviço) utilizadas pelo Terraform quando realiza as implementações.
• Azure Firewall para fornecer conectividade à internet de saída.
• Azure Bastion por fornecer acesso remoto seguro às VMs implementadas.
• Uma aplicação web de configuração do SAP Deployment Automation Framework no Azure para realizar atividades de configuração e implementação.

O plano de controle é definido usando dois arquivos de configuração, um para o implementador 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 se integrar ou você precisa usar uma zona DNS privada personalizada para o ambiente de implantação?
• Vais usar endereços IP pré-definidos para as VMs ou deixar o Azure atribuí-los dinamicamente?

Para integrar com uma zona DNS privada existente, forneça os seguintes valores nos seus tfvars ficheiros:

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 SAP, arquivos de lista de materiais, arquivos de estado Terraform e, opcionalmente, as zonas DNS privadas. O arquivo de configuração define o nome da região e do ambiente para a biblioteca SAP. Para obter informações sobre parâmetros e exemplos, consulte Configurar a biblioteca SAP para automação.

Planejamento da zona de carga de trabalho

A maioria dos cenários de aplicativos SAP são particionados em diferentes camadas. No SAP Deployment Automation Framework, essas camadas são chamadas de zonas de carga de trabalho. Por exemplo, você pode ter diferentes zonas de carga de trabalho para sistemas de desenvolvimento, garantia de qualidade e 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, subredes e grupos de segurança de rede.
• Azure Key Vault, para armazenar a máquina virtual e as credenciais do sistema SAP.
• Armazenamento do Azure conta para diagnósticos de arranque e Cloud Witness.
• Armazenamento partilhado para os sistemas SAP, seja Ficheiros do Azure ou Azure NetApp Files.

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

• Em que regiões precisas distribuir 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?
• Que tipo de armazenamento precisas para o armazenamento partilhado (Ficheiros do Azure Network File Share (NFS) ou Azure NetApp Files)?
• Você vai implantar o NAT Gateway para conectividade de saída com a Internet?

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 da Europa Ocidental usando a rede virtual SAP01. PRD-WEEU-SAP02-INFRASTRUCTURE destina-se a um ambiente de produção alojado na região da Europa Ocidental utilizando a rede virtual SAP02.

As designações SAP01 e SAP02 definem os nomes lógicos para as redes virtuais Azure. Eles podem ser usados para particionar ainda mais os ambientes. Suponha que precisas 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 diferentes nomes lógicos 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.

Implementações baseadas em Windows

Quando realiza implementações baseadas em Windows, as VMs na rede virtual da zona de carga de trabalho precisam de conseguir comunicar com o Active Directory para ligar as VMs SAP ao domínio Active Directory. O nome DNS fornecido precisa de ser resolvível pelo Active Directory.

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

Definições de DNS

Para cenários de alta disponibilidade, é necessário um registo DNS no Active Directory para o cluster de serviços centrais SAP. O registo DNS precisa de ser criado na zona DNS do Active Directory. O nome do registo 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.

Gestão de credenciais

A estrutura de automação usa entidades de serviço para implantação de infraestrutura. Recomendamos o uso de credenciais de implantação diferentes (principais 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 essas credenciais dinamicamente durante o processo de implantação.

Gerenciamento de credenciais SAP e de máquinas virtuais

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 o principal de serviço:

1. Inicie sessão no CLI do Azure com uma conta que tenha permissões para criar um principal de serviço.

2. Crie um novo principal de serviço executando o comando az ad sp create-for-rbac. Certifique-se de usar 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 a saída. Você precisa do identificador de aplicativo (appId), senha (password) e identificador de 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 do Utilizador ao seu 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 mais informações, consulte a documentação CLI do Azure para criar um principal de serviço.

Gestão 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 de Administrador de Acesso de Usuário à entidade de serviço.

Permissões necessárias

A tabela seguinte mostra as permissões necessárias para os principais de serviço.

Configuração do firewall

Teste a conectividade às URLs a partir de uma máquina virtual Linux em Azure usando um script PowerShell que utiliza a funcionalidade 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 DevOps

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

Repositório principal

Este repositório contém os ficheiros de parâmetros Terraform e os ficheiros necessários para os playbooks do Ansible para todas as zonas de carga de trabalho e implementações do sistema.

Crie este repositório clonando o repositório bootstrap SAP Deployment Automation Framework no seu repositório de controlo de versão.

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âmetros torna-se o nome do arquivo de estado Terraform. Certifique-se de usar um nome de arquivo de parâmetro exclusivo por esse motivo.

Repositório de código

Este repositório contém os modelos de automação Terraform, os playbooks 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 o modifique.

Para criar este repositório, clone o repositório SAP Deployment Automation Framework no seu repositório de controlo de versão.

Nomeie este repositório sap-automation.

Repositório de exemplo

Este repositório contém os arquivos de lista de materiais de exemplo e os arquivos de configuração Terraform de exemplo.

Para criar este repositório, clone o repositório de exemplos SAP Deployment Automation Framework no seu repositório de controlo de versão.

Nomeie este repositório samples.

Cenários de implantação suportados

A estrutura de automação suporta a implantação em cenários novos e existentes.

Regiões Azure

Antes de implementares uma solução, é importante considerar que regiões do Azure usar. Diferentes regiões do Azure podem estar dentro do âmbito dependendo do teu cenário específico.

O framework de automação suporta implementações em múltiplas regiões do Azure. Cada região acolhe:

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

Ambientes de implementação

Se você estiver oferecendo suporte a várias zonas de carga de trabalho em uma região, use um identificador exclusivo para seu ambiente de implantação e biblioteca SAP. Não use o identificador para a zona de carga de trabalho. Por exemplo, use MGMT para fins de gestão.

A estrutura de automação também suporta 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 implementação, que realizam as implementações da infraestrutura usando Terraform e realizam a configuração do sistema e a instalação SAP usando playbooks do Ansible.
• Um cofre de chaves, que contém informações de identidade da entidade de serviço principal para uso por implantações do Terraform.
• Um componente do Azure Firewall, que fornece conectividade à internet de saída.

O arquivo de configuração de 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 SAP tem várias zonas de carga de trabalho para diferentes níveis de aplicativos. 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 Virtual Networks, para redes virtuais, sub-redes e grupos de segurança de rede.
• Azure Key Vault, para credenciais do sistema e o principal do serviço de implementação.
• Contas de Armazenamento Azure, para diagnóstico de arranque e Cloud Witness.
• Armazenamento partilhado para os sistemas SAP, seja Ficheiros do Azure ou Azure NetApp Files.

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

• Quantas zonas de carga de trabalho seu cenário exige?
• Em que regiões precisas distribuir cargas de trabalho?
• Qual é o 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 a aplicação 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?
• O seu cenário requer alta disponibilidade?
• De quantos servidores de aplicativos você precisa?
• De quantos despachantes da Web você precisa, se houver?
• 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á no Azure Marketplace ou é personalizada?
• Você está implantando em um cenário de implantação novo ou existente?
• Qual é a sua estratégia de alocação de IP? Queres que o Azure defina IPs ou use definições personalizadas?

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

Fluxo de implantação

Ao planejar uma implantação, é importante considerar o fluxo geral. Existem três passos principais numa implementação SAP no Azure com o framework de automação.

1. Implante o plano de controle. Esta etapa implementa componentes para suportar o framework de automação SAP numa região Azure especificada.

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

2. Implante 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. Implante o sistema. Esta etapa inclui a infraestrutura para a implantação do sistema SAP e a configuração e 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 de disco

Se você quiser configurar tamanhos de disco personalizados, certifique-se de planejar sua configuração personalizada antes da implantação.

Conteúdo relacionado

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