Planen Sie die SAP-Bereitstellung mit dem SAP Deployment Automation Framework

SAP Deployment Automation Framework ist ein Open-Source-Orchestrierungstool, das SAP-Bereitstellungen auf Azure mithilfe von Terraform und Ansible automatisiert. Bevor Sie implementieren, müssen Sie Abonnements, die Verwaltung von Anmeldeinformationen und das Design von virtuellen Netzwerken planen.

In diesem Artikel werden die wichtigsten Planungsentscheidungen beschrieben, die Sie treffen müssen, bevor Sie mit der Bereitstellung beginnen. Allgemeine Überlegungen zu SAP auf Azure Design finden Sie unter Einführung in ein SAP-Adoptionsszenario.

Abonnementplanung

Stellen Sie die Steuerebene und die Arbeitslastzonen in verschiedenen Abonnements bereit. Die Steuerungsebene sollte sich in einem Hubabonnement befinden, in dem die Verwaltungskomponenten des SAP-Automatisierungsframeworks gehostet werden.

Hosten Sie die SAP-Systeme in Sprachabonnements, die den SAP-Systemen gewidmet sind. Sie können z. B. Entwicklungssysteme in einem separaten Abonnement mit einem dedizierten virtuellen Netzwerk hosten. Produktionssysteme können sich in ihrem eigenen Abonnement mit einem dedizierten virtuellen Netzwerk befinden.

Dieser Ansatz bietet sowohl eine Sicherheitsgrenze als auch eine klare Trennung von Aufgaben und Zuständigkeiten. Beispielsweise kann das SAP Basis-Team Systeme in den Workloadzonen bereitstellen, und das Infrastrukturteam kann die Steuerungsebene verwalten.

Planung der Steuerungsebene

Führen Sie die Bereitstellungs- und Konfigurationsaktivitäten entweder aus Azure Pipelines oder mithilfe der bereitgestellten Shellskripts direkt von Azure gehosteten virtuellen Linux-Computern (VMs) aus. Diese Umgebung wird als Steuerungsebene bezeichnet. Informationen zum Einrichten von Azure DevOps für das Bereitstellungsframework finden Sie unter Set up Azure DevOps for SAP Deployment Automation Framework. Um Linux-VMs als Bereitsteller einzurichten, siehe Einrichten von Linux-VMs für SAP Deployment Automation Framework.

Bevor Sie Ihre Steuerungsebene entwerfen, sollten Sie sich die folgenden Fragen stellen:

• In welchen Regionen müssen Sie SAP-Systeme bereitstellen?
• Gibt es ein dediziertes Abonnement für die Steuerungsebene?
• Gibt es dedizierte Bereitstellungs-Anmeldeinformationen (Dienstprinzipal) für die Kontrollebene?
• Gibt es ein vorhandenes virtuelles Netzwerk oder ist ein neues virtuelles Netzwerk erforderlich?
• Wie wird ausgehendes Internet für die virtuellen Computer bereitgestellt?
• Werden Sie Azure Firewall für ausgehende Internetverbindung bereitstellen?
• Sind private Endpunkte für Speicherkonten und den Schlüsseltresor erforderlich?
• Verwenden Sie eine vorhandene private DNS Zone für die virtuellen Computer oder die Steuerebene zum Hosten von Privates DNS?
• Werden Sie Azure Bastion für den sicheren Remotezugriff auf die virtuellen Computer verwenden?
• Verwenden Sie die Webanwendung für die Konfiguration des SAP Deployment Automation Framework für die Durchführung von Konfigurations- und Bereitstellungsaktivitäten?

Steuerungsebene

Die Steuerungsebene bietet die folgenden Dienste:

• Bereitstellungs-VMs, die Terraform-Bereitstellungen und Ansible-Konfiguration ausführen und als selbstgehostete Azure DevOps-Agents fungieren.
• Ein Schlüsseltresor, der die Bereitstellungsanmeldeinformationen (Dienstprinzipale) enthält, die von Terraform beim Ausführen der Bereitstellungen verwendet werden.
• Azure Firewall für die Bereitstellung ausgehender Internetverbindung.
• Azure Bastion, um sicheren Remotezugriff auf die bereitgestellten virtuellen Computer bereitzustellen.
• Eine SAP Deployment Automation Framework-Konfiguration Azure Webanwendung zum Ausführen von Konfigurations- und Bereitstellungsaktivitäten.

Die Steuerungsebene wird mithilfe von zwei Konfigurationsdateien definiert, eine für die Bereitstellung und eine für die SAP-Bibliothek.

Die Bereitstellerkonfigurationsdatei definiert die Region, den Umgebungsnamen und die Informationen zum virtuellen Netzwerk. Zum Beispiel:

# 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

DNS Überlegungen

Berücksichtigen Sie beim Planen der DNS-Konfiguration für das Automatisierungsframework die folgenden Fragen:

• Gibt es ein vorhandenes privates DNS, in das die Lösungen integriert werden können, oder müssen Sie eine benutzerdefinierte private DNS-Zone für die Bereitstellungsumgebung verwenden?
• Verwenden Sie vordefinierte IP-Adressen für die virtuellen Computer, oder lassen Sie Azure sie dynamisch zuweisen?

Um in eine vorhandene private DNS-Zone zu integrieren, geben Sie die folgenden Werte in Ihren tfvars Dateien an:

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

Ohne diese Werte wird in der SAP-Bibliotheksressourcengruppe eine private DNS-Zone erstellt.

Weitere Informationen finden Sie in der ausführlichen Erläuterung zum Konfigurieren des Bereitstellers.

SAP-Bibliothekskonfiguration

Die SAP-Bibliothekenressourcengruppe stellt Speicher für SAP-Installationsmedien, BOM-Dateien (Bill of Material, Stückliste), Terraform-Zustandsdateien und optional eine private DNS-Zone bereit. Die Konfigurationsdatei definiert die Region und den Umgebungsnamen für die SAP-Bibliothek. Parameterinformationen und Beispiele finden Sie unter Konfigurieren der SAP-Bibliothek für die Automatisierung.

Planen von Workloadzonen

Die meisten SAP-Anwendungslandschaften sind in verschiedenen Ebenen partitioniert. In SAP Deployment Automation Framework werden diese Ebenen als Workloadzonen bezeichnet. Beispielsweise verfügen Sie möglicherweise über unterschiedliche Workloadzonen für Entwicklung, Qualitätssicherung und Produktionssysteme. Weitere Informationen finden Sie unter Workloadzonen.

Die Workloadzone stellt die folgenden freigegebenen Dienste für die SAP-Anwendungen bereit:

• Azure Virtual Network für virtuelle Netzwerke, Subnetze und Netzwerksicherheitsgruppen.
• Azure Key Vault zum Speichern der Anmeldeinformationen des virtuellen Computers und des SAP-Systems.
• Azure Storage-Konten für die Startdiagnose und Cloud-Zeuge.
• Gemeinsam genutzter Speicher für die SAP-Systeme, entweder Azure Files oder Azure NetApp Files.

Bevor Sie Ihr Workloadzonenlayout entwerfen, sollten Sie sich die folgenden Fragen stellen:

• In welchen Regionen müssen Sie Workloads bereitstellen?
• Wie viele Workloadzonen sind für Ihr Szenario erforderlich (Entwicklung, Qualitätssicherung und Produktion usw.)?
• Erfolgt die Bereitstellung in neuen virtuellen Netzwerken, oder verwenden Sie vorhandene virtuelle Netzwerke?
• Welchen Speichertyp benötigen Sie für den freigegebenen Speicher (Azure Files Network File Share (NFS) oder Azure NetApp Files)?
• Stellen Sie das NAT Gateway für ausgehende Internetkonnektivität bereit?

Die Standardbenennungskonvention für Workloadzonen lautet [ENVIRONMENT]-[REGIONCODE]-[NETWORK]-INFRASTRUCTURE. DEV-WEEU-SAP01-INFRASTRUCTURE gilt beispielsweise für eine Entwicklungsumgebung, die in der Region Europa, Westen mit dem virtuellen SAP01-Netzwerk gehostet wird. PRD-WEEU-SAP02-INFRASTRUCTURE ist für eine Produktionsumgebung in der Region Westeuropa, die im virtuellen Netzwerk SAP02 gehostet wird.

Die Bezeichnungen SAP01 und SAP02 definieren die logischen Namen für die Azure virtuellen Netzwerke. Sie können verwendet werden, um die Umgebungen weiter zu partitionieren. Angenommen, Sie benötigen zwei Azure virtuellen Netzwerke für dieselbe Workloadzone. Sie können beispielsweise ein Szenario mit mehreren Abonnements haben, in dem Sie Entwicklungsumgebungen in zwei Abonnements hosten. Sie können die verschiedenen logischen Namen für jedes virtuelle Netzwerk verwenden. Sie können z. B. DEV-WEEU-SAP01-INFRASTRUCTURE und DEV-WEEU-SAP02-INFRASTRUCTURE verwenden.

Weitere Informationen finden Sie unter Konfigurieren einer Workloadzonenbereitstellung für die Automatisierung.

Windows basierte Bereitstellungen

Wenn Sie Windows-basierte Bereitstellungen ausführen, müssen die virtuellen Computer im virtuellen Netzwerk der Workloadzone in der Lage sein, mit Active Directory zu kommunizieren, um die SAP-VMs mit der Active Directory Domäne zu verbinden. Der angegebene DNS-Name muss durch Active Directory aufgelöst werden können.

Das SAP Deployment Automation Framework erstellt keine Konten in Active Directory, sodass die Konten im Key Vault der Workloadzone vorkonfiguriert und gespeichert werden müssen.

DNS-Einstellungen

Für Hochverfügbarkeitsszenarien wird im Active Directory für den SAP Central Services Cluster ein DNS-Eintrag benötigt. Der DNS-Eintrag muss in der dns-Zone Active Directory erstellt werden. Der Name des DNS-Eintrags ist definiert als [sid]>scs[scs instance number]cl1. w01scs00cl1 wird beispielsweise für das Cluster verwendet, mit W01 als SID und 00 als Instanznummer.

Verwaltung von Anmeldeinformationen

Das Automatisierungsframework verwendet Dienstprinzipale für die Infrastrukturbereitstellung. Wir empfehlen die Verwendung unterschiedlicher Bereitstellungsanmeldeinformationen (Dienstprinzipale) für jede Workloadzone. Das Framework speichert diese Anmeldeinformationen im Schlüsseltresor des Bereitstellers. Anschließend ruft das Framework diese Anmeldeinformationen während des Bereitstellungsprozesses dynamisch ab.

Verwaltung der Anmeldeinformationen für SAP und virtuelle Maschinen

Das Automatisierungsframework verwendet den Schlüsseltresor der Workloadzone, um sowohl die Anmeldeinformationen der Automation-Benutzer als auch die Anmeldeinformationen des SAP-Systems zu speichern. In der folgenden Tabelle sind die Namen der Anmeldeinformationen des virtuellen Computers aufgeführt.

Erstellung eines Dienstprinzipals

So erstellen Sie Ihren Dienstprinzipal:

1. Melden Sie sich bei der Azure CLI mit einem Konto an, das über Berechtigungen zum Erstellen eines Dienstprinzipal verfügt.

2. Erstellen Sie einen neuen Dienstprinzipal, indem Sie den Befehl az ad sp create-for-rbac ausführen. Stellen Sie sicher, dass Sie einen beschreibenden Namen für --name verwenden. Zum Beispiel:

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

3. Notieren Sie sich die Ausgabe. Sie benötigen den Anwendungsbezeichner (appId), das Kennwort (password) und den Mandantenbezeichner (tenant) für den nächsten Schritt. Zum Beispiel:

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

4. Weisen Sie dem Dienstprinzipal die Rolle „Benutzerzugriffsadministrator“ zu. Zum Beispiel:

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

Weitere Informationen finden Sie in der dokumentation Azure CLI zum Erstellen eines Dienstprinzipals.

Verwaltung von Berechtigungen

In einer gesperrten Umgebung müssen Sie den Dienstprinzipalen u. U. eine weitere Berechtigung zuweisen. Möglicherweise müssen Sie dem Dienstprinzipal z. B. die Rolle „Benutzerzugriffsadministrator“ zuweisen.

Erforderliche Berechtigungen

In der folgenden Tabelle sind die erforderlichen Berechtigungen für die Dienstprincipals aufgeführt.

Firewallkonfiguration

Testen Sie die Verbindung mit den URLs von einem virtuellen Linux-Computer in Azure mithilfe eines PowerShell-Skripts, das das Feature run-command in Azure verwendet.

Das folgende Beispiel zeigt, wie Sie die Verbindung mit den URLs mithilfe eines interaktiven PowerShell-Skripts testen.

$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
}

DevOps-Struktur

Das Bereitstellungsframework verwendet drei separate Repositorys für die Bereitstellungsartefakte. Für Ihre eigenen Parameterdateien empfiehlt es sich, diese Dateien in einem von Ihnen verwalteten Quellcodeverwaltungs-Repository zu speichern.

Hauptrepository

Dieses Repository enthält die Terraform-Parameterdateien und die Dateien, die für die Ansible Playbooks für alle Workloadzonen und Systembereitstellungen erforderlich sind.

Erstellen Sie dieses Repository, indem Sie das Repository SAP Deployment Automation Framework bootstrap in Ihr Quellcodeverwaltungs-Repository klonen.

Ordnerstruktur

Die folgende Beispielordnerhierarchie zeigt, wie Sie Ihre Konfigurationsdateien zusammen mit den Automatisierungsframeworkdateien strukturieren.

Der Name Ihrer Parameterdatei wird zum Namen der Terraform-Statusdatei. Stellen Sie aus diesem Grund sicher, dass Sie einen eindeutigen Parameterdateinamen verwenden.

Code-Repository

Dieses Repository enthält die Terraform-Automatisierungsvorlagen, die Ansible-Playbooks sowie die Bereitstellungspipelines und -skripts. In den meisten Anwendungsfällen sollten Sie dieses Repository als schreibgeschützt betrachten und es nicht ändern.

Um dieses Repository zu erstellen, klonen Sie das Repository SAP Deployment Automation Framework in Ihr Quellcodeverwaltungs-Repository.

Nennen Sie dieses Repository sap-automation.

Beispiel-Repository

Dieses Repository enthält die Beispiel-Materiallisten-Dateien und die Terraform-Beispielkonfigurationsdateien.

Um dieses Repository zu erstellen, klonen Sie das SAP Deployment Automation Framework-Beispiele-Repository in Ihr Versionskontroll-Repository.

Nennen Sie dieses Repository samples.

Unterstützte Bereitstellungsszenarien

Das Automatisierungsframework unterstützt die Bereitstellung in neuen und vorhandenen Szenarien.

Azure Regionen

Bevor Sie eine Lösung bereitstellen, ist es wichtig zu berücksichtigen, welche Azure Regionen verwendet werden sollen. Je nach Szenario können unterschiedliche Azure Regionen im Gültigkeitsbereich stehen.

Das Automatisierungsframework unterstützt Bereitstellungen in mehreren Azure Regionen. Jede Region hostet:

• Die Bereitstellungsinfrastruktur.
• Die SAP-Bibliothek mit Zustandsdateien und Installationsmedien.
• 1-N-Lastzonen.
• 1-n SAP-Systeme in den Workloadzonen.

Bereitstellungsumgebungen

Wenn Sie mehrere Workloadzonen in einer Region unterstützen, verwenden Sie einen eindeutigen Bezeichner für Ihre Bereitstellungsumgebung und SAP-Bibliothek. Verwenden Sie nicht den Bezeichner für die Workloadzone. Verwenden Sie beispielsweise MGMT zu Verwaltungszwecken.

Das Automatisierungsframework unterstützt auch, die Bereitstellungsumgebung und die SAP-Bibliothek in separaten Abonnements zu führen, die sich von den Workloadzonen unterscheiden.

Die Bereitstellungsumgebung stellt die folgenden Dienste bereit:

• Eine oder mehrere Bereitstellungs-VMs, die die Infrastrukturbereitstellungen mithilfe von Terraform durchführen und die Systemkonfiguration und DIE SAP-Installation mithilfe von Ansible Playbooks durchführen.
• Ein Key Vault, der Informationen zur Dienstprinzipalidentität für die Verwendung durch Terraform-Bereitstellungen enthält.
• Eine Azure Firewall Komponente, die ausgehende Internetverbindung bereitstellt.

Die Bereitstellungskonfigurationsdatei definiert die Region, den Umgebungsnamen und die Informationen zum virtuellen Netzwerk. Zum Beispiel:

# 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

Weitere Informationen finden Sie in der ausführlichen Erläuterung zum Konfigurieren des Bereitstellers.

Struktur der Workloadzone

Die meisten SAP-Konfigurationen verfügen über mehrere Workloadzonen für verschiedene Anwendungsebenen. Beispielsweise verfügen Sie möglicherweise über unterschiedliche Workloadzonen für Entwicklung, Qualitätssicherung und Produktion.

Sie erstellen oder gewähren Zugriff auf die folgenden Dienste in jeder Workloadzone:

• Azure virtuelle Netzwerke für virtuelle Netzwerke, Subnetze und Netzwerksicherheitsgruppen.
• Azure Key Vault für Systemberechtigungen und den Dienstprinzipal für die Bereitstellung.
• Azure Storage Konten für Boot-Diagnose und Cloud Witness.
• Gemeinsam genutzter Speicher für die SAP-Systeme, entweder Azure Files oder Azure NetApp Files.

Bevor Sie Ihr Workloadzonenlayout entwerfen, sollten Sie sich die folgenden Fragen stellen:

• Wie viele Workloadzonen sind für Ihr Szenario erforderlich?
• In welchen Regionen müssen Sie Workloads bereitstellen?
• Wie sieht Ihr Bereitstellungsszenario aus?

Weitere Informationen finden Sie unter Konfigurieren einer Workloadzonenbereitstellung für die Automatisierung.

Einrichtung des SAP-Systems

Das SAP-System enthält alle Azure Komponenten, die zum Hosten der SAP-Anwendung erforderlich sind.

Stellen Sie sich vor dem Konfigurieren des SAP-Systems die folgenden Fragen:

• Welches Datenbank-Back-End möchten Sie verwenden?
• Wie viele Datenbankserver benötigen Sie?
• Erfordert Ihr Szenario Hochverfügbarkeit?
• Wie viele Anwendungsserver benötigen Sie?
• Wie viele Web Dispatcher benötigen Sie, falls vorhanden?
• Wie viele zentrale Dienstinstanzen benötigen Sie?
• Welche Größe benötigen Sie für die VM?
• Welches VM-Image möchten Sie verwenden? Ist das Bild auf Azure Marketplace oder benutzerdefiniert?
• Erfolgt die Bereitstellung in einem neuen oder einem vorhandenen Szenario?
• Wie lautet Ihre IP-Zuordnungsstrategie? Soll Azure IPs festlegen oder benutzerdefinierte Einstellungen verwenden?

Weitere Informationen finden Sie unter Konfigurieren des SAP-Systems für die Automatisierung.

Bereitstellungsablauf

Wenn Sie eine Bereitstellung planen, ist es wichtig, den gesamten Ablauf zu berücksichtigen. Es gibt drei Hauptschritte einer SAP-Bereitstellung auf Azure mit dem Automatisierungsframework.

1. Bereitstellen der Steuerungsebene. In diesem Schritt werden Komponenten bereitgestellt, um das SAP-Automatisierungsframework in einer angegebenen Azure Region zu unterstützen.

   1. Sie erstellen die Bereitstellungsumgebung.
   2. Erstellen Sie einen freigegebenen Speicher für Terraform-Zustandsdateien.
   3. Erstellen Sie einen freigegebenen Speicher für die SAP-Installationsmedien.

2. Bereitstellung der Workload-Zone. In diesem Schritt werden die Workloadzonenkomponenten bereitgestellt, z. B. das virtuelle Netzwerk und Key Vaults.

3. Bereitstellen des Systems. Dieser Schritt umfasst die Infrastruktur für die SAP-Systembereitstellung und die SAP-Konfiguration und SAP-Installation.

Benennungskonventionen

Das Automatisierungsframework verwendet eine Standardbenennungskonvention. Wenn Sie eine benutzerdefinierte Namenskonvention verwenden möchten, planen und definieren Sie Ihre benutzerdefinierten Namen vor der Bereitstellung. Weitere Informationen finden Sie unter Konfigurieren der Benennungskonvention.

Dimensionierung von Datenträgern

Wenn Sie benutzerdefinierte Datenträgergrößen konfigurieren möchten, sollten Sie ihr benutzerdefiniertes Setup vor der Bereitstellung planen.

Verwandte Inhalte

• Übersicht über SAP Deployment Automation Framework
• Konfigurieren der Steuerebene
• Konfigurieren der Bereitstellung einer Workload-Zone
• Manuelle Bereitstellung des Automatisierungsframeworks