Architecture de référence : SAP S/4HANA sur Google Cloud Platform

Présentation

Ce document est destiné aux personnes qui évaluent Google Cloud en tant que plate-forme de déploiement de SAP S/4HANA, en particulier pour les types de tâches suivants :

  • Architecte technique SAP
  • Architecte cloud
  • Administrateur SAP Basis
  • Architecte d'entreprise

Ce document répertorie également les problèmes à prendre en compte avant l'installation, ainsi que des liens vers des notes SAP et d'autres documents pour faciliter le déploiement.

Google Cloud fournit une infrastructure certifiée SAP rentable, fiable, sécurisée et hautes performances pour l'exécution de SAP S/4HANA sur SAP HANA. Pour obtenir la liste complète des solutions SAP compatibles avec Google Cloud, consultez la page SAP sur Google Cloud.

Licences

Si vous êtes client de SAP, vous pouvez utiliser votre licence existante pour déployer SAP Business Suite sur Google Cloud dans le cadre d'un modèle BYOL (Bring Your Own License, utilisation de votre propre licence). Google Cloud est compatible avec le modèle BYOL pour les cas d'utilisation en production et hors production. Les licences de système d'exploitation sont incluses dans les tarifs Compute Engine. Vous pouvez également apporter votre propre image d'OS et vos propres licences.

Dimensionnement

Plusieurs options de dimensionnement sont disponibles en fonction du type de mise en œuvre. Pour les mises en œuvre de type Greenfield, nous vous recommandons d'utiliser l'outil SAP Quick Sizer. Pour plus d'informations, accédez à la page Sizing du site Web de SAP. SAP fournit également des guides similaires aux "guides des tailles" que propose l'industrie textile, détaillant les solutions et outils spécifiques permettant de migrer des solutions sur site actuelles vers Google Cloud. (Par exemple, consultez les pages répertoire matériel SAP HANA certifié et compatible et Applications on Google Cloud: Supported Products and Google VM types.) SAP et Google Cloud utilisent différentes unités pour mesurer les IOPS (opérations d'entrée/sortie par seconde). Consultez votre partenaire intégrateur de systèmes pour convertir les exigences de dimensionnement SAP en une infrastructure Google Cloud de taille appropriée.

Avant de migrer des systèmes existants de SAP ECC vers S/4HANA, SAP vous recommande d'exécuter le rapport /SDF/HDB_SIZING, comme décrit dans la note SAP 1872170, Rapport de dimensionnement Business Suite sur HANA et S/4HANA. Ce rapport de dimensionnement analyse les besoins actuels en mémoire et en traitement de votre système source, et fournit des informations sur les conditions requises pour passer à S/4HANA.

Types de machines compatibles

Google Cloud propose des types d'instances Compute Engine certifiés par SAP pour répondre aux exigences de dimensionnement lors du déploiement de S/4HANA. Pour en savoir plus sur le dimensionnement sur Google Cloud et les types de machines compatibles, consultez les sections suivantes :

Les types de machines personnalisés pour SAP HANA sur Google Cloud sont également certifiés par SAP. Vous pouvez exécuter des instances SAP HANA avec moins de 64 processeurs virtuels tant que vous conservez un ratio processeur virtuel/mémoire d'au moins 6,5.

Pour afficher les numéros SAPS des machines virtuelles Compute Engine certifiées pour les applications SAP, consultez la page Types de machines Compute Engine certifiés.

SAP fournit également une liste certifiée des configurations Google Cloud pour SAP HANA sur son site Web. Pour plus d'informations, consultez la page Répertoire matériel SAP HANA certifié et compatible.

Disques et systèmes de fichiers pour S/4HANA

Google Cloud propose les types de stockage suivants :

  • Disques persistants pour le stockage de blocs
    • Standard (pd-standard) : stockage de blocs efficace et économique sauvegardé par des disques durs standards (HDD) pour gérer les opérations de lecture/écriture séquentielles, mais pas optimisé pour gérer des taux élevés d'opérations d'entrée/sortie aléatoires par seconde (IOPS).
    • SSD (pd-ssd) : fournit un stockage de blocs fiable, à hautes performances et sauvegardé par des disques durs SSD.
    • Équilibré (pd-balanced) : fournit un stockage de blocs économique et fiable basé sur SSD.
    • Extrême (pd-extreme) : basé sur SSD, offre des options d'IOPS et de débit maximales plus élevées que pd-ssd pour les types de machines Compute Engine plus volumineux. Pour en savoir plus, consultez la page Disques persistants extrêmes.
    • Disques SSD locaux : stockage de blocs local hautes performances
  • Buckets Cloud Storage : stockage d'objets à prix abordable.
  • Instances Filestore : serveurs de fichiers NFS entièrement gérés sur Google Cloud.

Pour en savoir plus, consultez la page Options de stockage.

Les disques persistants Google Cloud sont conçus pour offrir une grande durabilité. Ils stockent les données de manière redondante afin de garantir leur intégrité. Chaque disque persistant peut stocker jusqu'à 64 To, ce qui vous permet de créer des volumes logiques volumineux sans gérer de groupes de disques. L'une des principales caractéristiques des disques persistants est leur chiffrement automatique pour protéger les données.

Lors de sa création, une instance Compute Engine attribue par défaut un seul disque persistant racine contenant le système d'exploitation. Vous pouvez ajouter d'autres options de stockage à l'instance selon vos besoins. Pour les mises en œuvre SAP, nous vous recommandons d'utiliser des disques persistants, car ils sont conçus pour offrir une grande durabilité ; les instances de calcul peuvent y accéder comme des disques physiques sur une machine locale.

Les tableaux suivants décrivent les structures de répertoires Linux pour SAP HANA et ABAP sur Google Cloud.

Structure de répertoires SAP HANA Type de stockage
/usr/sap Disque persistant basé sur SSD
/hana/data Disque persistant basé sur SSD
/hana/log Disque persistant basé sur SSD
/hana/shared Disque persistant basé sur SSD
/hanabackup Disque persistant standard (HDD)
Structure du répertoire ABAP Type de stockage
/sapmnt Disque persistant standard (HDD)
/usr/sap/ Disque persistant standard (HDD)

Déploiement

SAP S/4HANA comprend les composants techniques suivants :

  • SAP HANA.
  • PAS : serveur d'applications principal.
    • Le premier ou le seul serveur d'applications pour le système SAP.
  • AAS : serveur d'applications supplémentaire.
    • Généralement déployé pour l'équilibrage de charge au niveau de l'application. Vous pouvez installer plusieurs systèmes AAS pour obtenir une disponibilité plus élevée du point de vue de la couche d'application. Si l'un des serveurs d'applications tombe en panne, toutes les sessions utilisateur connectées à ce serveur d'applications sont arrêtées, mais les utilisateurs peuvent se reconnecter à l'autre serveur AAS associé de l'environnement.
  • Passerelle SAP NetWeaver.
  • Interface Fiori.
  • WD : coordinateur Web (facultatif).
    • Équilibreur de charge logiciel intelligent qui répartit les requêtes HTTP et HTTPS, en fonction du type d'application, sur PAS et AAS.

Modèles de déploiement

Vous pouvez déployer S/4HANA sur Google Cloud selon l'un des deux modèles suivants : déploiement centralisé ou déploiement distribué.

Pour installer SAP HANA dans un déploiement centralisé ou distribué, utilisez le script de déploiement. Pour en savoir plus, consultez le guide de déploiement de SAP HANA.

Déploiement centralisé

Dans un déploiement centralisé, vous pouvez installer S/4HANA et la base de données SAP HANA sur la même instance Compute Engine. Nous recommandons cette approche pour les environnements hors production tels que les environnements de bac à sable et de développement.

Le schéma suivant illustre une architecture de référence pour S/4HANA dans un modèle de déploiement centralisé. Notez que SAP ASCS, PAS, WD et HANA sont tous installés sur la même instance.

Schéma illustrant ASCS, PAS, Web Dispatcher et HANA sur une seule machine virtuelle

Déploiement distribué

Dans un déploiement distribué, vous pouvez installer les différents composants sur différentes instances Compute Engine. Nous recommandons cette approche pour les environnements de production ou les environnements qui nécessitent une grande puissance de calcul pour gérer une charge de transaction élevée.

Le schéma suivant montre une architecture de référence pour S/4HANA dans un modèle de déploiement distribué. Notez que SAP ASCS, PAS, WD et HANA sont tous installés sur des instances différentes.

Schéma montrant Web Dispatcher, Fiori, S/4 PAS, ASCS et HANA sur des machines virtuelles distinctes

Remarque sur l'équilibrage de charge

Dans un environnement S/4HANA distribué, l'équilibrage de charge est requis. Vous pouvez configurer l'équilibrage de charge de l'application à l'aide de la couche d'application SAP.

Haute disponibilité et reprise après sinistre

La haute disponibilité et la reprise après sinistre sont des ensembles de techniques, de pratiques d'ingénierie et de principes de conception qui permettent d'assurer la continuité des activités en cas d'échec. Ces approches fonctionnent en éliminant les points de défaillance isolés et en offrant la possibilité de reprendre rapidement les opérations après une panne du système ou des composants avec un minimum de perturbation des activités. La reprise après sinistre correspond au processus de récupération et de reprise des opérations après une panne due à un composant défaillant.

Par exemple, voici quelques outils de haute disponibilité et de reprise après sinistre :

Informations supplémentaires sur certains de ces éléments :

Clustering Linux sur plusieurs zones : la configuration de votre cluster Linux sur plusieurs zones permet d'éviter les défaillances de composants dans une région donnée. Vous pouvez déployer un cluster Linux sur plusieurs zones à l'aide d'une configuration en mode actif/passif ou d'une configuration en mode actif/actif. Dans les deux cas, vous commencez par configurer deux instances Compute Engine dans des zones distinctes, chacune avec sa propre base de données SAP HANA.

  • Configuration en mode actif/passif : configurez une instance en tant que nœud principal du cluster (actif) et l'autre en tant que nœud secondaire (passif). Utilisez la réplication du système SAP HANA pour configurer le nœud secondaire en tant que serveur principal en cas d'échec du serveur principal, comme indiqué dans le schéma suivant. Pour en savoir plus sur la configuration de la réplication du système HANA, consultez la page sur la réplication du système HANA.

Un cluster SAP HANA à haute disponibilité se trouve dans une région GCP. La réplication asynchrone conserve un système HANA unique dans une autre région.

Migration à chaud : Compute Engine propose une migration à chaud pour que vos instances Compute Engine s'exécutent même en cas d'événement du système hôte, tel qu'une mise à jour logicielle ou matérielle. Dans ce cas, Compute Engine migre à chaud votre instance en cours d'exécution vers un autre hôte de la même zone, au lieu de nécessiter un redémarrage de votre instance en cours d'exécution. Ce mécanisme réplique l'état de la VM de l'instance d'origine. Ainsi, lorsque la nouvelle instance s'affiche, la mémoire de l'instance d'origine est déjà préchargée.

Dans les rares cas où la migration à chaud ne se produit pas, la machine virtuelle défaillante est automatiquement redémarrée sur le nouveau matériel dans la même zone.

Pour en savoir plus, consultez la page Migration à chaud.

Sauvegarde et récupération

Effectuez des sauvegardes régulières de votre serveur d'applications et de votre base de données afin de pouvoir les récupérer en cas de panne du système, de corruption de données ou d'autres problèmes.

Sauvegardes

Vous disposez de plusieurs options pour sauvegarder vos données SAP HANA sur Google Cloud, à savoir :

  • Sauvegarde directe sur Cloud Storage à l'aide de l'agent Backint de Cloud Storage pour SAP HANA (agent Backint) certifié SAP
  • Sauvegarde sur un disque persistant, puis téléchargement des sauvegardes sur Cloud Storage
  • Réalisation d'instantanés du disque entier contenant le répertoire /hanabackup à l'aide de la fonction d'instantané de Compute Engine

Agent Backint de Cloud Storage pour SAP HANA

L'agent Backint s'intègre aux fonctions natives de sauvegarde et de restauration SAP HANA et vous permet ainsi de sauvegarder et de récupérer vos données directement dans/à partir de Cloud Storage sans nécessiter de stockage sur disque persistant. Pour en savoir plus, consultez le guide d'utilisation de SAP HANA.

Pour plus d'informations sur la certification SAP de l'agent Backint de Cloud Storage pour SAP HANA, accédez à la note SAP 2031547.

Le schéma suivant illustre le déroulement des sauvegardes lorsque vous utilisez l'agent Backint.

Le schéma illustre SAP HANA avec l'agent Backint effectuant une sauvegarde directement dans Cloud Storage.

Effectuer une sauvegarde sur des disques persistants

Vous pouvez utiliser la fonction de sauvegarde et de récupération SAP HANA native avec des disques persistants Compute Engine et utiliser un bucket Cloud Storage pour le stockage à long terme des sauvegardes.

En cours de fonctionnement normal, SAP HANA enregistre automatiquement les données de la mémoire sur le disque à des points de sauvegarde réguliers. En outre, toutes les modifications de données sont enregistrées dans les entrées du journal de rétablissement. Une entrée de journal de rétablissement est écrite sur le disque après chaque transaction de base de données validée.

À partir de SAP HANA 2.0, vous devez utiliser SAP HANA Cockpit pour sauvegarder la base de données SAP HANA.

Le schéma suivant illustre le déroulement de la fonctionnalité de sauvegarde pour SAP HANA.

Les sauvegardes sont créées sur un disque persistant, puis stockées dans Cloud Storage.

Sauvegarde des disques persistants à l'aide d'instantanés

Une autre option que vous pouvez ajouter à votre stratégie de sauvegarde consiste à réaliser des instantanés de disques entiers à l'aide de la fonctionnalité d'instantané de disque persistant de Compute Engine. Par exemple, vous pouvez réaliser des instantanés planifiés de votre disque de répertoire de sauvegarde pour les utiliser dans des scénarios de reprise après sinistre. Pour assurer la cohérence des applications, réalisez des instantanés lorsqu'aucune modification n'est apportée au volume cible. Les instantanés sont réalisés au niveau du bloc.

Après le premier instantané, chaque instantané suivant est incrémentiel et ne stocke que les modifications de bloc incrémentielles, comme illustré dans le schéma suivant.

Ce schéma illustre des instantanés complets et incrémentiels des données HANA sur un disque persistant.

Récupération

Les outils de récupération dans SAP HANA peuvent récupérer les données au dernier moment possible ou à un moment précis. Vous pouvez utiliser ces outils pour restaurer un nouveau système ou créer une copie de la base de données. Contrairement aux sauvegardes que vous pouvez exécuter lorsque la base de données est opérationnelle, vous ne pouvez utiliser les outils de récupération que lorsque la base de données est fermée. Les options de récupération sont répertoriées ci-dessous. Choisissez celle qui correspond le mieux à votre situation.

  • Restauration des données vers l'état le plus récent à l'aide de l'une des ressources suivantes :
    • Sauvegarde complète ou instantané
    • Sauvegardes de journaux.
    • Entrées du journal de rétablissement encore disponibles
  • Restauration des données vers un moment donné dans le passé
  • Restauration des données vers une sauvegarde complète spécifiée

Notes SAP importantes concernant le prédéploiement

Lisez les notes SAP suivantes avant de commencer à déployer SAP S/4HANA sur Google Cloud. Avant de procéder à la mise en œuvre d'un produit SAP, consultez régulièrement SAP Marketplace pour obtenir des notes et des guides d'installation du produit mis à jour.