IBM Cloud Docs
Mise en œuvre de la haute disponibilité pour les applications SAP sur IBM Power Virtual Server

Mise en œuvre de la haute disponibilité pour les applications SAP sur IBM Power Virtual Server

L'exécution d' SAP s sur IBM® Power® Virtual Server offre une plate-forme cohérente pour les applications traditionnelles et basées sur l' SAP HANA, des performances de classe mondiale, une résilience pour les charges de travail critiques et une infrastructure flexible.

Utilisez les informations suivantes pour comprendre comment mettre en œuvre des solutions à haute disponibilité pour les systèmes d' SAP, en utilisant des instances d' Power Virtual Server.

SAP architecture système

Les principaux composants d'un système SAP sont les suivants.

Système SAP HANA

Le système d'exploitation Linux ( SAP HANA ) fournit la base de données des locataires pour les serveurs d'applications d' SAP.

SAP serveur d'application

SAP les serveurs d'applications fournissent la partie fonctionnelle d'une solution d' SAP S/4HANA, ou autre application. Toutes les données de personnalisation et d'application d'un système d' SAP s sont stockées dans une base de données locataire d'un système d' SAP HANA s.

Un système d'application d' SAP s est installé et configuré en tant qu'unité unique et se compose des instances d'application suivantes.

  • Une instance ABAP System Central Services (instance ASCS) Chaque système d'application d' SAP s possède exactement une instance ASCS, qui se compose d'un serveur de messages et d'un serveur de mise en file d'attente.

  • Une ou plusieurs instances de serveur d'application (instances AS)

    • Le serveur d'application principal (PAS) est la première instance AS installée pour un système ABAP.
    • Les autres instances AS installées pour un système ABAP sont appelées serveurs d'applications supplémentaires (AAS).

Les instances du serveur d'applications et de l'ASCS dépendent toutes deux d'un système de fichiers partagé et nécessitent un accès en lecture/écriture à celui-ci.

Système de fichiers partagé : En règle générale, le système de fichiers partagé est exporté sur un serveur d' NFS s et monté sur toutes les instances.

La figure 1 illustre les composants techniques d'un système d' SAP.

Figure 1. Composants techniques pour systèmes d' SAP s
Composants techniques pour systèmes d' SAP s

Considérations pour la mise en œuvre d'une solution de haute disponibilité ( SAP )

Pour une protection à haute disponibilité, il est recommandé d'installer les serveurs d'applications de manière redondante. Installez au moins deux serveurs d'applications (PAS et AAS) et utilisez des groupes de connexion pour équilibrer la charge. En cas de défaillance d'un serveur d'applications, toutes les sessions utilisateur connectées à cette instance sont interrompues. L'utilisateur se connecte à nouveau et l'équilibrage de charge redirige l'utilisateur vers un autre serveur d'applications qui est toujours en cours d'exécution.

Les autres composants techniques, tels que l'instance ASCS, la base de données d' SAP HANA s et le système de fichiers partagé, sont des points de défaillance uniques et doivent être protégés.

  • Instance ASCS

    La meilleure façon de protéger l'instance ASCS est de déployer une instance Enqueue Replication Server (ERS) sur un serveur virtuel supplémentaire et d'utiliser un logiciel de clustering HA pour automatiser le basculement.

    Installez ASCS et ERS soit sur un disque partagé qui est attaché aux deux instances de serveur virtuel, soit sur un système de fichiers d' NFS.

    Le serveur de mise en file d'attente de l'instance ASCS gère la table de verrouillage et l'ERS crée une copie répliquée de la table de verrouillage dans sa mémoire principale. Si le serveur de mise en file d'attente doit être redémarré, la table de verrouillage est reconstruite en utilisant la copie sur l'ERS, et tous les verrous sont conservés.

    Un simple redémarrage du serveur de messagerie suffit car aucune donnée ne doit être conservée.

    Suivez les étapes de la section Configuration de la haute disponibilité pour SAP S/4HANA(ASCS et ERS)dans un cluster Red Hat Enterprise Linux High Availability Add-On pour configurer un cluster HA pour l'instance ABAP System Central Services.

  • Système de fichiers partagé

    La méthode recommandée pour protéger le serveur d' NFS s consiste à mettre en place une instance de serveur virtuel supplémentaire. Ensuite, créez les systèmes de fichiers exportés d' NFS s sur des disques partagés qui sont attachés aux deux instances de serveur virtuel et automatisez le basculement en utilisant le logiciel de cluster HA.

    Suivez les étapes de la section Configuration d'un serveur NFS actif-passif dans un cluster Red Hat Enterprise Linux High Availability Add-On pour configurer un cluster HA pour le système de fichiers partagé.

  • Système SAP HANA

    SAP HANA fournit deux approches pour faire évoluer un système : la montée en charge et l'extension horizontale. Avec l'ensemble complet et hautement évolutif de profils certifiés IBM Power Virtual Server pour SAP HANA disponibles dans IBM Power Virtual Server, l'accent est mis sur les solutions évolutives SAP HANA.

    La meilleure façon de protéger un système d' SAP HANA s est de mettre en place un système d' SAP HANA s secondaire sur une instance de serveur virtuel distincte. Ensuite, configurez la réplication du système d' SAP HANA, et automatisez le basculement avec le logiciel de cluster HA.

La figure suivante présente une vue d'ensemble de l'architecture d'un système d' SAP s à haute disponibilité implémenté sur Power Virtual Server.

Figure 2. SAP sur Power Virtual Server Présentation de l'architecture HA
SAP sur Power Virtual Server Présentation de l'architecture HA

SAP HANA scénarios de solutions à haute disponibilité

La solution varie en fonction de l'objectif de temps de récupération (RTO).

Variantes pour les solutions à haute disponibilité pour SAP HANA
Scénario RTO typique Commentaire
Performances optimisées Quelques minutes Sauf si vous avez des exigences spécifiques, ce scénario est celui par défaut.
Actif/Actif (lecture activée) Quelques minutes Dans une configuration Active/Active (lecture activée), la réplication de système d' SAP HANA s permet un accès en lecture au contenu de la base de données sur le système secondaire.
Coût optimisé Quelques dizaines de minutes Dans une configuration optimisée en termes de coûts, un système d' SAP HANA s hors production fonctionne sur le nœud secondaire pendant le fonctionnement normal. Les ressources matérielles du nœud secondaire sont partagées entre le système hors production et le système secondaire de réplication d' SAP HANA. La consommation de mémoire du système de réplication secondaire d' SAP HANA s de production est réduite en désactivant le préchargement des données dans les tables de colonnes. Lorsqu'un basculement se produit, l'instance hors production est automatiquement arrêtée avant que le nœud ne prenne en charge la charge de travail de production. Le temps de prise en main est plus long par rapport à une configuration optimisée pour la performance.

En fonction de vos besoins, sélectionnez la documentation correspondant à l'un des scénarios.

SAP HANA scénarios de solution de reprise après sinistre

Pour une protection supplémentaire du système de base de données, répliquez le système d' SAP HANA s sur un troisième système situé dans une région différente en utilisant la réplication de système d' SAP HANA s. En fonction de vos besoins, sélectionnez l'une des deux topologies disponibles.

SAP HANA solution à haute disponibilité dans un environnement multizone

Un sous-réseau dans IBM Power Virtual Server ne peut pas s'étendre sur plusieurs espaces de travail. Il n'est pas possible de déplacer une adresse IP de service vers un deuxième espace de travail et de continuer à l'utiliser depuis VPC ou d'autres espaces de travail pour accéder aux services fournis. Cependant, cette capacité est nécessaire pour mettre en place un scénario de réplication de système d' SAP HANA s hautement disponible dans un environnement multizone.

L'agent de ressources d' powervs-subnet s répond à cette limitation. Lors d'un événement de prise de contrôle, l'agent de ressources déplace l'intégralité du sous-réseau, y compris l'adresse IP, d'un espace de travail à un autre.

Les chiffres suivants illustrent ce scénario.

Deux instances de serveur virtuel sont déployées dans des espaces de travail distincts avec des sous-réseaux différents.

  • SAP HANA est installé sur les deux instances de serveur virtuel et la réplication de système d' SAP HANA est configurée.
  • Les deux instances de serveur virtuel sont configurées en tant que cluster haute disponibilité à deux nœuds avec leurs propres sous-réseaux.
  • Une ressource de cluster qui utilise l'agent de ressources d' powervs-subnet s est configurée pour Subnet 3 et IP address 3. Choisissez une petite plage pour le Classless Inter-Domain Routing (CIDR), seules l' IP address 3 et une adresse IP pour la passerelle sont attribuées dans l' Subnet 3.
  • SAP HANA les clients de la base de données utilisent IP address 3 pour se connecter à la base de données.

En fonctionnement normal

  • Le sous-réseau 3 est créé dans l'espace de travail 1.
  • Le sous-réseau 3 est rattaché à l'instance de serveur virtuel 1.
  • L'adresse IP 3 est configurée sur l'instance de serveur virtuel 1.
  • L' SAP HANA, primaire, est actif sur l'instance de serveur virtuel 1, l' SAP HANA, secondaire, est actif sur l'instance de serveur virtuel 2.

Figure 3. SAP HANA sur Power Virtual Server dans la région multizone Présentation de HA
SAP HANA sur Power Virtual Server dans la région multizone Présentation de HA

Après une reprise de groupe

  • Le sous-réseau 3 est créé dans l'espace de travail 2.
  • Le sous-réseau 3 est rattaché à l'instance de serveur virtuel 2.
  • L'adresse IP 3 est configurée sur l'instance de serveur virtuel 2.
  • La primaire d' SAP HANA s est active sur l'instance de serveur virtuel 2.

Figure 4. SAP HANA sur Power Virtual Server dans la région multizone Reprise HA
SAP HANA sur Power Virtual Server dans la région multizone Reprise HA

Pour savoir comment préparer et configurer un cluster de haute disponibilité (HA) Red Hat Enterprise Linux (RHEL) pour l'agent de ressources powervs-subnet, reportez-vous aux informations de la section Mise en œuvre d'un cluster Red Hat Enterprise Linux High Availability Add-On dans un environnement de régions multizones.