Terraformer votre infrastructure SAP sur AWS

Les systèmes SAP de nos clients sont essentiels pour le bon fonctionnement de leur entreprise. Par conséquent, lorsque les architectes et les administrateurs planifient leurs déploiements et leurs opérations, le respect des meilleures pratiques SAP est essentiel. De plus, à mesure que les exigences en termes de performance, disponibilité ou résilience changent, les équipes doivent itérer et s’adapter rapidement pour fournir l’infrastructure requise en gardant à l’esprit tous les principes de sécurité, les meilleures pratiques en matière de performance et les autres exigences non-fonctionnelles.

Les ressources minimales requises pour un déploiement de SAP comprennent généralement :

Un ou plusieurs Virtual Private Cloud (Amazon VPC) et des sous réseaux
Des configurations du groupe de sécurité spécifique à l’application SAP et à la base de données
Des instances Amazon EC2
Des volumes EBS
Des système de fichiers Amazon EFS pour les dossiers sapmnt et DIR_TRANS
Des clés Amazon KMS pour le chiffrement au repos
Des buckets Amazon S3 pour les fichiers d’installation, les sauvegardes SAP et l’archivage de fichiers
Des rôles AWS IAM pour les instances, les administrateurs d’applications, les auditeurs et autres

Architecture cible pour un déploiement de SAP HANA sur AWS

Fig 1 – Architecture recommandée pour un déploiement de SAP HANA

En outre, pour optimiser l’efficacité, améliorer l’excellence opérationnelle et tirer parti des autres services AWS pour les opérations SAP, les clients configurent également :

Les métriques, alarmes et événements Amazon CloudWatch
Les outils de sauvegarde (par exemple AWS Backint Agent)
Les playbooks AWS Systems Manager pour les automatisations opérationnelles
- Démarrer/Arrêter des instances Amazon EC2
- Gestion des correctifs et des patchs
- Gestion des profils SAP
Les règles AWS Config pour la surveillance de la conformité
Les applications serverless pour étendre les fonctionnalités SAP

Et cette liste n’est en aucun cas complète. À mesure que les systèmes SAP dans les environnements clients augmentent, le nombre de ressources et de services qui doivent être créés et gérés au sein d’AWS augmente également. Désormais, toutes ces ressources peuvent être facilement créées via la console AWS, ce qui constitue une première étape évidente pour mettre rapidement en service votre premier système SAP dans le cloud.

Cependant, les clients ont rarement besoin d’un seul système isolé. Les clients recherchent un moyen simple d’automatiser et d’accélerer leurs déploiements.

C’est dans ce contexte que rentre en jeu l’ « Infrastructure as Code ».

L’ « Infrastructure as Code » est une pratique dans laquelle l’infrastructure est provisionnée et gérée à l’aide de techniques de développement logiciel, telles que le contrôle de version et l’intégration continue. Le cloud AWS offre un modèle piloté par API qui permet aux développeurs et aux administrateurs système d’interagir avec l’infrastructure de façon programmatique, à grande échelle, au lieu de déployer et de configurer manuellement les ressources. Étant donné que les ressources et les services sont définis comme du code, l’infrastructure et les serveurs peuvent être rapidement déployés à l’aide de modèles standardisés, mis à jour avec les derniers patchs/versions et dupliqués de manière répétable.

Ce concept vous permet de définir les ressources cloud AWS en tant que fichiers de configuration texte et permet à vos équipes de :

Collaborez et partagez des configurations,
Faites évoluer et modernisez votre infrastructure,
Automatisez le déploiement de ressources.

AWS CloudFormation et AWS Cloud Development Kit sont des outils AWS natifs que vous pouvez utiliser pour décrire les ressources requises avec du JSON, YAML, TypeScript, Python ou Java.

Cela permet aux clients de déployer rapidement leur infrastructure SAP sur AWS en utilisant SAP QuickStart et AWS Launch Wizard. Grâce à AWS Launch Wizard, les équipes clients peuvent créer des systèmes SAP qui s’alignent rapidement sur les meilleures pratiques AWS à partir de la console AWS, à la suite d’une expérience guidée conçue pour les administrateurs SAP.

Les pratiques DevOps pour les environnements SAP

Fig 2 – Model DevOps

Avoir votre infrastructure définie comme code apporte un autre avantage. Cela vous permet d’implémenter un modèle DevOps dans le monde SAP.

L’automatisation du provisioning SAP dans toutes les couches présente les avantages suivants :

Déploiement accéléré,
Mise à l’échelle,
Fiabilité,
Collaboration améliorée,
Sécurité.

Vous pouvez trouver des informations supplémentaires sur ce sujet en cliquant ici.

Hashicorp Terraform

Terraform, développé par Hashicorp est l’un des outils d’infrastructure as code les plus populaires dans le domaine du cloud: 68 % des développeurs qui l’utilisent adorent.

Il y a plusieurs raisons à cela :

Un langage de configuration facile à apprendre et à lire,
Plus de 200 fournisseurs qui vous permettent de configurer plusieurs parties de votre système dans une seule configuration,
Une communauté forte avec plus de 300 modules.

Nous aidons les clients qui préfèrent Terraform comme outil de choix pour l’automatisation.

Étant concentrés sur l’expérience et les commentaires de nos clients, nous avons décidé de construire des systèmes SAP qui tiennent compte des meilleures pratiques SAP et des meilleures pratiques AWS. Nous souhaitons partager certains des modules que nous avons développés en interne en Open Source et nous les avons publiés sur GitHub.

Nous avons également enregistré nos modules auprès du Registre Terraform afin que vous puissiez les utiliser nativement dans la suite d’outils Hashicorp.

Ces modules sont faciles à ajouter à votre configuration terraform existante ou si vous débutez avec Terraform, vous pouvez simplement cloner le dépôt et commencer avec une nouvelle configuration terraform.

Par exemple, voici à quoi ressemblerait le provisionnement d’une infrastructure SAP HANA :

```hcl
module hana_host {
  source = "./../../../../modules/sap-netweaver-instances/hana-host"

  # Si vous souhaitez mettre en place une infrastructure hautement disponible
  instance_count = 2
  # Type d'instance (certifiée HANA)
  instance_type = "r5.4xlarge"
  enabled                           = true
  ami_id                            = "ami-xyz123"

  # General

  # Clé KMS pour le chiffrement des volumes EBS
  kms_key_arn = "arn:aws:kms:us-east-1:12345678910:key/xyz12345-xyz1-xyz1-xyz12-xyz12345678910"

  # Networking
  vpc_id                            = "vpc-xyz123"

  # Liste des subnets où déployer des instances
  subnet_ids                 = ["subnet-xyz123", "subnet-xyz789"]
  # La Private Zone Route53 
  dns_zone_name                 = "customer.com"
  # Le bloc CIDR pour le réseau on premise
  customer_cidr_blocks                = ["10.0.0.0/16"]
  # Le groupe de sécurité par défault à ajouter
  customer_default_sg_id = "default"
  
  # Instance Role
  iam_instance_role = "sap-instance-role"

  # Tags
  app_code = "S4H"
  environment = "prod"
  application_name = "ECC"
  
  # SAP
  sid = "DWE"
}
```

Création conditionnelle

Il arrive que vous ayez besoin de créer des instances conditionnellement. Cependant Terraform ne nous permet pas d’utiliser count dans le bloc module. La solution consiste alors à spécifier l’argument enabled.

Cet argument est disponible avec tous les modules :

```hcl
# Ce VPC ne sera pas créé
module hana_host {
  source = "./../../../../modules/sap-netweaver-instances/hana-host"

  enabled = false
  # ...
}
```

Haute disponibilité

Si vous configurez un système hautement disponible, vous pouvez spécifier le nombre d’instances du module SAP Hana dont vous avez besoin en utilisant le paramètre instance_count.

Dans le cas d’une mise à l’échelle horizontale de SAP HANA, vous pouvez doubler le nombre de nœuds :

```hcl
# Deux copies d'instances HANA seront provisionnées
module hana_host {
  source = "./../../../../modules/sap-netweaver-instances/hana-host"

  instance_count = 2
  # ...
}
```

Roles AWS IAM

Les instances peuvent être fournies avec le rôle par défaut comprenant les autorisations AWS Systems Manager en configurant default_iam_role sur true

Si vous souhaitez fournir un rôle personnalisé pour les instances, fournissez à l’ARN le rôle requis en tant que paramètre iam_role

```hcl
# Le rôle fourni sera associé 
module hana_host {
  source = "./../../../../modules/sap-netweaver-instances/hana-host"

  iam_role = <instance_role_arn>
  # ...
}
```

```hcl
# Le rôle par défault sera créé et associé
module hana_host {
  source = "./../../../../modules/sap-netweaver-instances/hana-host"

  default_iam_role = true
  # ...
}
```

Chiffrement des données stockées

Si vous souhaitez activer le chiffrement pour les volumes Amazon EFS ou Amazon EBS, indiquez l’ARN de la clé Amazon KMS comme paramètre d’entrée. Sinon, laissez-le vide et le chiffrement restera inactif.

```hcl
# Le rôle par défault sera créé et associé
module hana_host {
  source = "./../../../../modules/sap-netweaver-instances/hana-host"

  kms_key_arn = <kms_key_arn>
  # ...
}
```

Restauration automatique d’instance Amazon EC2

Avec AWS, vous pouvez organiser la restauration automatique d’une instance Amazon EC2 en cas d’échec d’une vérification de l’état du système du matériel sous-jacent. L’instance sera redémarrée (sur un nouveau matériel si nécessaire) mais conservera son ID d’instance, son adresse IP, ses adresses IP élastiques, ses volume Amazon EBS associés et d’autres détails de configuration. Pour que la restauration soit terminée, vous devez vous assurer que l’instance démarre automatiquement tous les services ou applications dans le cadre de son processus d’initialisation.

La récupération automatique de l’instance est intégrée dans les modules.

Données utilisateur de l’instance

Les instances peuvent être fournies avec le script d’initialisation par défaut. Ce script installera l’AWS CLI, l’agent AWS SSM et l’agent Amazon CloudWatch.

Si vous souhaitez modifier ce comportement, veuillez fournir les données utilisateur dans l’entrée de module correspondante.

```hcl
# Les données utilisateur fournies seront associées
module hana_host {
  source = "./../../../../modules/sap-netweaver-instances/hana-host"

  user_data = <user_data_script>
  # ...
}
```

Conclusion

Comme nous l’avons démontré avec nos modules Terraform disponibles sur GitHub et sur le Registre Terraform, nous définissons l’architecture d’un système SAP comme du code. L’infrastructure et les serveurs peuvent alors être déployés rapidement à l’aide de modèles standardisés, mis à jour avec les derniers patchs/versions, et dupliqués de manière répétable.

Terraform et le modèle basé sur les API du cloud AWS permettent aux développeurs et aux administrateurs système d’interagir avec l’infrastructure de manière programmatique, à grande échelle, au lieu de déployer et de configurer manuellement les ressources.

Cette solution peut être facilement ajoutée à une configuration Terraform existante. Elle peut également servir de base à une nouvelle configuration en clonant le dépôt GitHub précédemment mentionné.

Vous souhaitez en apprendre davantage ou peut-être aimeriez-vous mieux comprendre comment étendre cette solution à votre projet ?
Pour plus d’informations, contactez-nous à sap-on-aws@amazon.com.

Article original par Chris Williams et Glenn Mendonca. Traduit de l’anglais par Jean-Robin Foehn, Solutions Architect accompagnant les clients français dans leur transformation digitale et leur adoption du cloud.

Le Blog Amazon Web Services