Partager via

Options de déploiement pour SAP dans Azure

  • Article

Les principes du Cloud Adoption Framework pour Azure peuvent vous aider à automatiser SAP dans Azure. Lorsque vous réfléchissez à votre stratégie d’automatisation et à l’approche que vous devez utiliser, il est important d’identifier les composants clés d’une application SAP car ce sont eux qui guideront le choix de votre stratégie. En particulier dans les environnements d’entreprise, l’option de déploiement doit prendre en compte la configuration manuelle, l’automatisation de la plateforme et les approches de DevOps utilisées pour prendre en charge la plateforme SAP.

Les applications SAP constituent une structure technologique essentielle pour de nombreuses entreprises à travers le monde. Azure fournit des conseils qui vous permettront de vérifier que vos solutions sont certifiées, prises en charge et correctement implémentées. Les organisations peuvent optimiser l’agilité d’Azure pour déployer des applications SAP, automatiser les activités de déploiement, configurer des systèmes et effectuer d’autres tâches complexes afin de garantir une efficacité opérationnelle ainsi que des déploiements d’infrastructure contrôlés et au code malléable.

Le référentiel SAP Automation de Microsoft prend en charge les clients Azure SAP de manière à intégrer des scripts aux pratiques DevOps actuelles ou à utiliser le code dans son état actuel et directement à partir d’un référentiel cloné.

Architecture SAP

Une patrimoine d’applications SAP est constitué de systèmes, de zones de charge de travail et de paysages.

Système

Un système SAP est une instance d’une application SAP qui possède les ressources nécessaires à l’exécution de l’application, comme les machines virtuelles, les disques, les équilibrages de charge, les groupes de placement de proximité, les groupes à haute disponibilité, les sous-réseaux et les groupes de sécurité réseau. L’application est identifiée par un SID, qui est un identificateur unique à 3 lettres. Dans un cycle de vie, chaque système doit être déployé au sein d’un groupe de ressources Azure distinct.

Zone de charge de travail

Une zone de charge de travail est également appelée « environnement de déploiement ». Celle-ci divise l’application SAP en différents environnements (production ou non production, par exemple) et peut segmenter un paysage en différents niveaux comme le développement, l’assurance qualité ou la production. Un environnement de déploiement fournit des ressources partagées, comme des réseaux virtuels ou des coffres de clés, à tous les systèmes de la zone de charge de travail.

Paysage

Un paysage est un ensemble de systèmes dans différents environnements dans une application SAP. Le schéma présenté à titre d’exemple illustre trois paysages SAP : SAP ERP Central Component (ECC), SAP Customer Relationship Management (CRM) et SAP Business Warehouse (BW).

Le schéma suivant illustre les dépendances entre les systèmes, les zones de charge de travail et les paysages SAP. Dans l’illustration suivante, le client dispose de trois paysages : SAP ERP Central Component (ECC), SAP Customer Relationship Management (CRM) et SAP Business Warehouse (BW). Chaque paysage comporte quatre zones de charge de travail : bac à sable (sandbox), développement, assurance qualité et production. Chaque zone de charge de travail peut contenir un ou plusieurs systèmes.

Un patrimoine d’applications SAP.

Composants supplémentaires

Outre les composants SAP, la solution d’automatisation a besoin des éléments suivants :

  • Un environnement d’exécution à partir duquel les activités de déploiement peuvent être effectuées
  • Un stockage persistant pour le support d’installation et, si Terraform est utilisé, pour le stockage des fichiers d’état Terraform

Recommandations relatives à la conception :

  • Utilisez une machine virtuelle qui dispose d’une connectivité réseau vers les réseaux virtuels cibles afin d’activer la configuration et l’installation de l’application.
  • Utilisez les comptes de stockage Azure pour gérer les fichiers d’état, et comme sources d’installation pour le support d’installation SAP.

Activités de préparation

Choix d’une stratégie DevOps

L’automatisation du déploiement SAP doit être implémentée sous la forme d’un workflow qui commence par le déploiement de l’infrastructure, et qui est suivi de la configuration du système d’exploitation et de l’installation de l’application.

Remarques relatives à la conception :

  • Définissez l’étendue de l’automatisation nécessaire :

    • Infrastructure
    • Configuration du système d’exploitation
    • Installation de l’application
    • Opérations en cours (opérations d’état d’exécution)

  • Définir la stratégie de stockage des fichiers de paramètres

Recommandations relatives à la conception :

  • Stockez tous les fichiers de paramètres dans un dépôt de contrôle de code source.
  • Sauvegardez les fichiers d’état et les fichiers de paramètres pour empêcher leur endommagement. Par exemple, vous pouvez stocker les fichiers d’état Terraform dans des comptes de stockage chaud basés sur un stockage géoredondant avec accès en lecture.

Planification de la région

Le framework d’automatisation du déploiement SAP prend en charge les déploiements dans plusieurs régions Azure. Chaque région héberge les éléments suivants :

  • Infrastructure de déploiement
  • Une bibliothèque SAP pour l’état et le support d’installation SAP
  • Zones de charge de travail 1-n
  • Systèmes SAP 1-n déployés dans les zones de charge de travail

L’illustration suivante montre la stratégie de déploiement pour deux régions Azure.

Diagramme d’une stratégie SAP DevOps.

Remarques relatives à la conception :

  • Régions Azure prises en charge
  • Récupération d'urgence

Planification de la zone de charge de travail

Une zone de charge de travail, également appelée « environnement de déploiement », associe le réseau virtuel de la charge de travail, les informations d’identification des systèmes de cette charge de travail ainsi que le principal de service utilisé pour le déploiement de ces systèmes. Les zones de charge de travail sont régionales, car elles dépendent du réseau virtuel dans Azure. Pour l’automatisation, la convention de nommage prend en charge la présence de zones de charge de travail dans plusieurs régions Azure, chacune avec leur propre réseau virtuel.

Voici quelques modèles courants de zones de charge de travail :

Production et non production

Dans ce modèle, les environnements SAP sont regroupés en zones de production et de non production.

Bac à sable (sandbox), développement, assurance qualité, production

Dans ce modèle, les environnements SAP sont regroupés selon quatre zones : bac à sable (sandbox), développement, assurance qualité et production.

Considérations relatives à la conception :

  • Combien de zones de charge de travail sont nécessaires ?
  • Concernant la conception d’abonnement, un abonnement contient-il plusieurs zones de charge de travail ?
  • Dans quelles régions les charges de travail sont-elles déployées ?
  • Connectivité Internet sortante
  • Connectivité réseau pour un réseau local
  • S’agit-il d’un déploiement greenfield (sans infrastructure Azure pour la charge de travail) ou d’un déploiement brownfield (où tous les artefacts ou certains d’entre eux prennent en charge la zone de charge de travail) ?
  • Chaque zone de charge de travail a-t-elle besoin d’informations d’identification de déploiement uniques ?

Recommandations relatives à la conception :

  • La connectivité Internet sortante doit être fournie par l’équipe réseau.
  • La connectivité à un réseau local doit être fournie par l’équipe réseau.
  • Utilisez des informations d’identification de déploiement uniques pour chaque zone de charge de travail. Si une zone de charge de travail existe dans plusieurs régions, celle-ci doit utiliser les mêmes informations d’identification de déploiement dans toutes les régions.
  • Pour simplifier la planification réseau, essayez de réduire au maximum le nombre de zones de charge de travail.

Planification des applications SAP

Le système SAP correspond à l’application SAP qui contient tous les artefacts Azure nécessaires à l’hébergement de l’application SAP. Reportez-vous à SAP sur Azure pour vous lancer, planifier et prendre en compte les facteurs de déploiement en détail.

Considérations relatives à la conception :

  • La base de données back-end à utiliser
  • Le nombre de serveurs de base de données
  • Si la haute disponibilité est nécessaire
  • Le nombre de serveurs d’applications
  • Le nombre de répartiteurs web (le cas échéant)
  • Le nombre d’instances de services centraux
  • Tailles de machine virtuelle
  • Décidez s’il faut utiliser une image de la Place de marché Azure ou une image personnalisée. Les images personnalisées présentent plusieurs avantages, tels que la configuration du système d’exploitation propre au client, le durcissement de la sécurité et les outils de conformité. Les images personnalisées peuvent également vous aider à rationaliser le cycle de vie de l’image.
  • S’agit-il d’un déploiement greenfield (sans infrastructure Azure pour la charge de travail) ou d’un déploiement brownfield (où tous les artefacts ou certains d’entre eux prennent en charge la zone de charge de travail) ?
  • La stratégie d’allocation d’IP (Azure ou fournie par le client)
  • Nommage des ressources Azure
  • Définition des exigences pour la gestion des informations d’identification : les systèmes d’une zone de charge de travail peuvent-ils utiliser les mêmes informations d’identification pour accéder aux machines virtuelles ?

Recommandations relatives à la conception :

Framework d’automatisation du déploiement SAP

Le framework d’automatisation du déploiement SAP fournit des modèles Terraform et des playbooks Ansible qui peuvent être utilisés pour créer et configurer les environnements d’exécution SAP dans Azure. Les artefacts sont hébergés dans le référentiel sap-hana d’Azure, et Azure prend en charge les scripts de déploiement open source (le code n’est pas personnalisé) pour SAP dans Azure.

Fonctionnalités Automation

Plateformes prises en charge

Azure prend en charge l’automatisation des déploiements SAP dans Linux et Windows.

Topologies prises en charge

Le modèle par défaut pour l’automatisation des déploiements SAP est un modèle distribué avec une couche Base de données et une couche Application. La couche Application est divisée en trois niveaux : les serveurs d’applications, les serveurs de services centraux et les répartiteurs web. L’automatisation peut également être déployée sur un serveur autonome avec une configuration sans couche Application.

Fonctionnalités incluses

Tableau des fonctionnalités du framework d’automatisation des déploiements SAP :

Fonctionnalité Inclus Notes
Mise en réseau accélérée O Les performances réseau accélérées sont activées sur les machines virtuelles.
Groupes de sécurité d’application N Ceux-ci figurent dans la feuille de route.
Machine virtuelle d’ancrage O Machine virtuelle qui ancre le groupe de placement de proximité dans une zone de disponibilité.
Configuration de l’application N Configuration basée sur Ansible. Bientôt disponible.
Installation d’application N Installation basée sur Ansible. Bientôt disponible.
Authentification O L’authentification prend en charge l’authentification SSH basée sur le nom d’utilisateur et le mot de passe.
Zones de disponibilité O L’automatisation peut déployer des machines virtuelles dans des zones ou sur plusieurs zones de disponibilité.
Azure Files pour les systèmes de fichiers réseau N Ceux-ci figurent dans la feuille de route.
Pare-feu Azure O L’automatisation peut déployer un Pare-feu Azure dans le réseau du déployeur.
Azure Load Balancer O L’automatisation utilise les équilibreurs de charge standard d’Azure Load Balancer.
Azure NetApp Files N Ceux-ci figurent dans la feuille de route.
Compte de stockage des diagnostics de démarrage O Le compte de stockage des diagnostics de démarrage est partagé entre tous les systèmes d’une zone de charge de travail.
Coffres de clés Azure O Coffres de clés nouveaux ou actuels dans Azure.
Images client O Ces images personnalisées doivent être répliquées dans la région.
Clés de chiffrement de disque gérées par le client O Ces clés doivent être créées à l’avance et stockées dans Azure Key Vault.
Environnement de déploiement O Il s’agit d’une machine virtuelle située dans un réseau appairé aux réseaux SAP.
Dimensionnement du disque O Le dimensionnement de disque par défaut est spécifié et peut être configuré.
Adressage IP O Les adresses IP sont fournies par le client et par Azure.
Conventions d’affectation de noms O Il s’agit de la convention de nommage par défaut. Celle-ci peut être personnalisée.
Groupes de sécurité réseau O Il s’agit de groupes de sécurité réseau nouveaux ou actuels.
Configuration du système d’exploitation N Configuration basée sur Ansible. Bientôt disponible.
Groupes de placements de proximité O Il s’agit de groupes de placement de proximité nouveaux ou actuels.
Resource group O Il s’agit de groupes de ressources nouveaux ou actuels.
Sous-réseaux O Il s’agit de sous-réseaux nouveaux ou actuels.
Stockage pour le support d’installation SAP O Il s’agit d’un compte de stockage nouveau ou actuel.
Stockage pour l’état Terraform O Il s’agit d’un compte de stockage nouveau ou actuel.
Référence de la machine virtuelle O Toutes les références SKU de machine virtuelle sont configurables.
Réseaux virtuels O Il s’agit d’un réseau virtuel nouveau ou actuel.
Compte de stockage témoin O Le compte de stockage témoin est partagé entre tous les systèmes d’une zone de charge de travail. Il est utilisé pour les scénarios de haute disponibilité dans Windows.

Planification des fichiers de paramètres

L’automatisation des déploiements SAP utilise des fichiers de paramètres JSON pour configurer l’environnement Azure avec différents fichiers de paramètres pour les différents artefacts. L’environnement de développement doit cloner le dépôt SAP HANA et le dépôt client dans le même dossier racine. En définissant une structure de dossiers et en conservant les fichiers de paramètres dans des dossiers dédiés, vous simplifierez les opérations de déploiement automatisées.

Recommandations relatives à la conception :

Tous les fichiers de paramètres doivent être stockés dans un environnement de contrôle de code source.