Scénarios et architecture de haute disponibilité pour SAP NetWeaver

  • Article

Définitions de terminologie

Haute disponibilité : Fait référence à un ensemble de technologies qui réduisent les interruptions des services informatiques en assurant la continuité de leur activité par le biais de composants redondants, tolérants aux pannes ou protégés par basculement au sein du même centre de données. Dans notre cas, le centre de données se trouve dans une région Azure.

Reprise d’activité : Fait également référence à la baisse des interruptions des services informatiques et à leur récupération, mais sur divers centres de données pouvant se trouver à des centaines de kilomètres les uns des autres. Dans notre cas, les centres de données peuvent se trouver dans diverses régions Azure d’une même région géopolitique ou dans des emplacements définis par vous en tant que client.

Vue d’ensemble de la haute disponibilité

La haute disponibilité SAP dans Azure peut être divisée en trois types :

  • Haute disponibilité de l’infrastructure Azure :

    La haute disponibilité peut inclure, par exemple, le calcul (machines virtuelles), le réseau ou le stockage et ses avantages en termes d’augmentation de la disponibilité des applications SAP.

  • Utilisation du redémarrage de machine virtuelle d’infrastructure Azure pour protéger les applications SAP :

    Si vous décidez de ne pas utiliser des fonctionnalités telles que le Clustering de basculement Windows Server (WSFC) ou Pacemaker sur Linux, le redémarrage de machine virtuelle Azure est utilisé. Il restaure les fonctionnalités des systèmes SAP s’il existe des temps d’arrêt planifiés et non planifiés de l’infrastructure de serveur physique Azure et de la plateforme Azure sous-jacente globale.

  • Haute disponibilité de l’application SAP :

    Pour obtenir une haute disponibilité du système SAP complet, vous devez protéger tous les composants critiques du système SAP. Par exemple :

    • Serveurs d’applications SAP redondants.
    • Composants uniques. Un composant à point de défaillance unique (SPOF) tel qu’une instance SAP ASCS/SCS ou un système de gestion de base de données (SGBD) en est un exemple.

La haute disponibilité SAP dans Azure est différente de la haute disponibilité SAP dans un environnement physique local ou virtuel.

Il n’existe aucune configuration de haute disponibilité SAP intégrée à SApinst pour Linux, car il existe pour Windows. Pour plus d’informations sur la haute disponibilité SAP locale pour Linux, consultez Informations des partenaires pour la haute disponibilité.

Haute disponibilité de l’infrastructure Azure

SLA pour les machines virtuelles à instance unique

Il existe actuellement un contrat SLA à une seule machine virtuelle de 99,9 % avec stockage Premium. Pour avoir une idée de ce à quoi peut ressembler la disponibilité d’une machine virtuelle unique, vous pouvez calculer le produit des divers Contrats de niveau de service Azure disponibles.

La base de calcul est de 30 jours par mois, ou 43 200 minutes. Par exemple, un temps d’arrêt de 0,05 % correspond à 21,6 minutes. Comme d’habitude, la disponibilité des divers services est calculée comme suit :

(Service de disponibilité #1/100) x (Service de disponibilité #2/100) x (Service de disponibilité #3/100) *...

Par exemple :

(99.95/100) x (99.9/100) x (99.9/100) = 0,9975 ou une disponibilité globale de 99,75 %.

Plusieurs instances de machines virtuelles dans le même groupe à haute disponibilité

Pour toutes les machines virtuelles qui ont deux instances ou plus déployées dans le même groupe à haute disponibilité, nous vous garantissons que vous disposez d’une connectivité de machine virtuelle à au moins une instance au moins 99,95 % du temps.

Lorsque deux machines virtuelles ou plus font partie du même groupe à haute disponibilité, chaque machine virtuelle du groupe à haute disponibilité se voit attribuer un domaine de mise à jour et un domaine d’erreur par la plateforme Azure sous-jacente.

  • Les domaines de mise à jour garantissent que plusieurs machines virtuelles ne sont pas redémarrés en même temps pendant la maintenance planifiée d’une infrastructure Azure. Une seule machine virtuelle est redémarrée à la fois.
  • Les domaines d’erreur garantissent que les machines virtuelles sont déployées sur des composants matériels qui ne partagent pas de source d’alimentation et de commutateur réseau courants. Lorsqu’un temps d’arrêt non planifié des serveurs, d’un commutateur réseau ou d’une source d’alimentation électrique se produit, une seule machine virtuelle est affectée.

Pour plus d’informations, consultez gérer la disponibilité des machines virtuelles dans Azure à l’aide d’un groupe à haute disponibilité.

Zones de disponibilité Azure

Azure est en train de déployer un concept d’Azure Zones de disponibilité dans différentes régions Azure. Les régions Azure où sont proposées les zones de disponibilité ont plusieurs centres de données, chacun avec sa source d’alimentation, son système de refroidissement et son réseau. Nous offrons différentes zones au sein d’une même région Azure pour vous permettre de déployer des applications sur deux ou trois zones de disponibilité proposées. En imaginant que les problèmes d’alimentation et/ou de réseau n’affectent qu’une seule infrastructure de zone de disponibilité, le déploiement de votre application au sein d’une région Azure devrait toujours entièrement opérationnel. Avec peut-être quelques diminutions des fonctionnalités, car certaines machines virtuelles d’une zone pourraient être perdues. Mais celles des deux autres zones seraient toujours opérationnelles. Les régions Azure qui offrent des zones sont listées dans Zones de disponibilité Azure.

Sur l’utilisation de Zones de disponibilité, il y a certaines choses à prendre en compte. Notamment :

  • Vous ne pouvez pas déployer de groupes à haute disponibilité Azure dans une zone de disponibilité. La seule possibilité de combiner des groupes à haute disponibilité et des zones de disponibilité est via des groupes de placement de proximité. Pour plus d’informations, consultez l’article Combiner des groupes à haute disponibilité et des zones de disponibilité avec des groupes de placement de proximité.
  • Vous ne pouvez pas utiliser l’équilibreur de charge de base pour créer des solutions de cluster de basculement basées sur les services de cluster de basculement Windows ou Linux Pacemaker. Au lieu de cela, vous devez utiliser la référence SKU Azure Standard Load Balancer.
  • Azure Zones de disponibilité ne donne aucune garantie de certaines distances entre les différentes zones d’une région.
  • La latence du réseau entre les différentes zones de disponibilité Azure dans les différentes régions Azure peut varier selon la région. Il existe des cas où vous, en tant que client, pouvez raisonnablement exécuter la couche d’application SAP déployée sur différentes zones, car la latence réseau d’une zone à la machine virtuelle SGBD active est toujours acceptable à partir d’un impact sur le processus métier. Alors qu’il peut y avoir des scénarios clients où la latence entre la machine virtuelle SGBD active dans une zone et une instance d’application SAP dans une machine virtuelle d’une autre zone peut être trop intrusive et non acceptable pour les processus métier SAP. Par conséquent, les architectures de déploiement doivent être différentes avec une architecture active/active pour l’application ou une architecture active/passive si la latence est trop forte.
  • L’utilisation de disques managés Azure est obligatoire pour le déploiement dans Azure Zones de disponibilité.

Groupe de machines virtuelles identiques avec orchestration flexible

Dans Azure, les groupes de machines virtuelles identiques avec orchestration flexible offrent un moyen d’obtenir une haute disponibilité pour les charges de travail SAP, comme d’autres infrastructures de déploiement telles que les groupes à haute disponibilité et les zones de disponibilité. Avec un groupe identique flexible, les machines virtuelles peuvent être réparties entre différentes zones de disponibilité et domaines d’erreur, ce qui lui permet de déployer des charges de travail SAP hautement disponibles.

Le groupe de machines virtuelles identiques avec orchestration flexible offre la possibilité de créer le groupe identique dans une région ou de l’étendre entre les zones de disponibilité. Lors de la création, le groupe identique flexible au sein d’une région avec platformFaultDomainCount>1 (FD>1), les machines virtuelles déployées dans le groupe identique sont réparties entre le nombre spécifié de domaines d’erreur dans la même région. En revanche, la création du groupe identique flexible entre les zones de disponibilité avec platformFaultDomainCount=1 (FD=1) distribuerait les machines virtuelles entre différentes zones et le groupe identique distribuerait également des machines virtuelles entre différents domaines d’erreur au sein de chaque zone. Pour la charge de travail SAP, seul un groupe identique flexible avec FD=1 est pris en charge.

L’avantage d’utiliser des groupes identiques flexibles avec FD=1 pour le déploiement interzone, au lieu du déploiement traditionnel de zone de disponibilité, est que les machines virtuelles déployées avec le groupe identique seraient réparties entre différents domaines d’erreur au sein de la zone de manière optimale. Pour éviter les limitations associées à l’utilisation d’un groupe de placement de proximité pour garantir la disponibilité des machines virtuelles dans tous les centres de données Azure ou sous chaque colonne vertébrale du réseau, il est recommandé de déployer une charge de travail SAP dans des zones de disponibilité à l’aide d’un groupe identique flexible avec FD=1. Cette stratégie de déploiement garantit que les machines virtuelles déployées dans chaque zone ne sont pas limitées à un seul centre de données ou colonne vertébrale réseau, et que tous les composants système SAP, tels que les bases de données, ASCS/ERS et la couche Application, sont limités au niveau zonal.

Par conséquent, pour le nouveau déploiement de charge de travail SAP entre les zones de disponibilité, nous vous conseillons d’utiliser un groupe identique flexible avec FD=1. Pour plus d’informations, consultez le groupe de machines virtuelles identiques pour le document de charge de travail SAP.

Maintenance planifiée et non planifiée des machines virtuelles

Deux types d’événements de la plateforme Azure peuvent affecter la disponibilité de vos machines virtuelles :

  • Les événements de maintenance planifiée sont des mises à jour périodiques appliquées par Microsoft à la plateforme Azure sous-jacente. Les mises à jour améliorent la fiabilité, les performances et la sécurité globales de l’infrastructure de plateforme sur laquelle vos machines virtuelles sont exécutées.
  • Les événements de maintenance non planifiée ont lieu lorsque l’infrastructure physique ou matérielle sous-jacente de votre machine virtuelle connaît une défaillance. Cela peut comprendre les défaillances du réseau local, du disque local ou au niveau du rack. Lorsqu’une défaillance de ce type est détectée, la plateforme Azure migre automatiquement votre machine virtuelle du serveur physique défectueux qui l’héberge vers un serveur physique sain. De tels événements sont rares, mais ils peuvent entraîner un redémarrage de votre machine virtuelle.

Pour plus d’informations, consultez la maintenance des machines virtuelles dans Azure.

Redondance de Stockage Azure

Les données dans votre compte de stockage sont toujours répliquées pour garantir une durabilité, ainsi qu’une haute disponibilité, et répondre ainsi au contrat de niveau de service (SLA) Stockage Azure, y compris face aux défaillances matérielles temporaires.

Stockage Azure conservant trois images des données par défaut, l’utilisation de RAID 5 ou RAID 1 sur plusieurs disques Azure n’est pas nécessaire.

Pour plus d’informations, consultez l’article Réplication de Stockage Azure.

Azure Disques managés

Disques managés est un type de ressource dans Azure Resource Manager, est une option de stockage recommandée au lieu de disques durs virtuels stockés dans des comptes de stockage Azure. Les disques managés s’alignent automatiquement sur un groupe à haute disponibilité Azure de la machine virtuelle auquel ils sont attachés. Ils améliorent la disponibilité de votre machine virtuelle et des services qui sont exécutés sur celle-ci.

Pour plus d’informations, consultez Vue d’ensemble d’Azure Disques managés.

Nous vous recommandons d’utiliser des disques managés, car ils simplifient le déploiement et la gestion de vos machines virtuelles.

Comparaison de différents types de déploiement pour la charge de travail SAP

Voici un résumé rapide des différents types de déploiement disponibles pour les charges de travail SAP.

Fonctionnalités Groupe de machines virtuelles identiques avec orchestration flexible (FD=1) Zone de disponibilité Groupe à haute disponibilité
Comportement de déploiement Les instances atterrissent sur 1, 2 ou 3 zones de disponibilité et réparties sur différents racks au sein de chaque zone en fonction du meilleur effort Les instances atterrissent dans 1, 2 ou 3 zones de disponibilité Les instances atterrissent dans la région et réparties entre différents domaines d’erreur/de mise à jour
Affecter des machines virtuelles et des disques managés à une zone de disponibilité spécifique Oui Oui No
Domaine d’erreur - Propagation maximale (Azure va répartir au maximum les instances) Oui No Oui, en fonction du nombre de domaines d’erreur définis lors de la création.
Alignement du domaine d’erreur de calcul vers le stockage No Non Oui
Réservation de capacité Oui (attribuer une réservation de capacité au niveau de la machine virtuelle) Oui Non

Remarque

Options de déploiement à haute disponibilité pour la charge de travail SAP

Lors du déploiement d’une charge de travail SAP à haute disponibilité sur Azure, il est important de tenir compte des différents types de déploiement disponibles et de la façon dont ils peuvent être appliqués dans différentes régions Azure (par exemple, entre les zones, dans une seule zone ou dans une région sans zone). Le tableau suivant illustre plusieurs options de haute disponibilité pour les systèmes SAP dans les régions Azure.

Type de système Dans différentes zones d’une région Dans une zone singe d’une région Dans une région sans zone
Système SAP haute disponibilité Groupe identique flexible avec FD=1 Groupes à haute disponibilité avec des groupes de placement de proximité Groupes à haute disponibilité
Groupes de disponibilité et Zones de disponibilité avec des groupes de placement de proximité Groupe identique flexible avec FD=1 (sélectionnez une seule zone) Groupe identique flexible avec FD=1 (aucune zone n’est définie)
Zones de disponibilité Groupes à haute disponibilité
  • Déploiement dans différentes zones d’une région : pour la disponibilité la plus élevée, les systèmes SAP doivent être déployés dans différentes zones d’une région. Cela garantit que si une zone n’est pas disponible, le système SAP continue d’être disponible dans une autre zone. Si vous déployez une nouvelle charge de travail SAP dans des zones de disponibilité, il est recommandé d’utiliser un groupe de machines virtuelles identiques flexible avec l’option de déploiement FD=1. Il vous permet de déployer plusieurs machines virtuelles dans différentes zones d’une région sans vous soucier des contraintes de capacité ou des groupes de placement. L’infrastructure du groupe identique s’assure que les machines virtuelles déployées avec le groupe identique sont réparties entre différents domaines d’erreur au sein de la zone de manière optimale. Tous les composants SAP à haute disponibilité tels que SAP ASCS/ERS, les bases de données SAP sont distribuées entre différentes zones, tandis que plusieurs serveurs d’applications de chaque zone sont répartis entre différents domaines d’erreur en fonction du meilleur effort.
  • Déploiement dans une seule zone d’une région : pour déployer votre système SAP à haute disponibilité dans un emplacement avec plusieurs zones de disponibilité, et s’il est essentiel que tous les composants du système se trouvent dans une seule zone, il est recommandé d’utiliser des groupes de disponibilité avec l’option de déploiement des groupes de placement de proximité. Cette approche vous permet de regrouper tous les composants système SAP dans une seule zone de disponibilité, en vous assurant que les machines virtuelles au sein du groupe à haute disponibilité sont réparties entre différents domaines d’erreur et de mise à jour. Bien que ce déploiement aligne le calcul sur les domaines d’erreur de stockage, la proximité n’est pas garantie. Toutefois, comme cette option de déploiement est régionale, elle ne prend pas en charge Azure Site Recovery pour la récupération d’urgence interzone à zone. De plus, cette option limite l’ensemble du déploiement SAP à un centre de données, ce qui peut entraîner des limitations de capacité si vous devez modifier la taille de la référence SKU ou effectuer un scale-out des instances d’application.
  • Déploiement dans une région sans zone : si vous déployez votre système SAP dans une région qui n’a aucune zone, il est recommandé d’utiliser des groupes à haute disponibilité. Cette option fournit une redondance et une tolérance de panne en plaçant des machines virtuelles dans différents domaines d’erreur et domaines de mise à jour.

Important

Il convient de noter que les options de déploiement pour les régions Azure ne sont que des suggestions. La stratégie de déploiement la plus appropriée pour votre système SAP dépend de vos exigences et de votre environnement particuliers.

Utilisation de la haute disponibilité de l’infrastructure Azure pour protéger les applications SAP

Si vous décidez de ne pas utiliser de fonctionnalités telles que WSFC ou Pacemaker sur Linux (pris en charge pour SUSE Linux Enterprise Server 12 et versions ultérieures, et Red Hat Enterprise Linux 7 et versions ultérieures), le redémarrage de la machine virtuelle Azure est utilisé. Il restaure les fonctionnalités des systèmes SAP s’il existe des temps d’arrêt planifiés et non planifiés de l’infrastructure de serveur physique Azure et de la plateforme Azure sous-jacente globale.

Pour plus d’informations sur l’approche, consultez Utiliser le redémarrage des machines virtuelles d’infrastructure Azure pour obtenir une meilleure disponibilité du système SAP.

Haute disponibilité des applications SAP sur Azure IaaS

Pour obtenir une haute disponibilité du système SAP complet, vous devez protéger tous les composants critiques du système SAP. Par exemple :

  • Serveurs d’applications SAP redondants.
  • Composants uniques. Un composant à point de défaillance unique (SPOF) tel qu’une instance SAP ASCS/SCS ou un système de gestion de base de données (SGBD) en est un exemple.

Les sections suivantes expliquent comment obtenir la haute disponibilité pour les trois composants critiques du système SAP.

Architecture de haute disponibilité pour des serveurs d’applications SAP

Windows logo. Windows et Linux logo. Linux

En règle générale, vous n’avez pas besoin d’une solution à haute disponibilité pour le serveur d’applications et les instances de dialogue SAP. La haute disponibilité s’obtient via la redondance, et vous configurez plusieurs instances de dialogue sur diverses instances de machines virtuelles Azure. Vous devez avoir au moins deux instances d’applications SAP installées dans deux instances de machines virtuelles Azure.

Selon le type de déploiement (groupe identique flexible avec FD=1, zone de disponibilité ou groupe à haute disponibilité), vous devez distribuer vos instances de serveur d’applications SAP en conséquence pour obtenir une redondance.

  • Groupe identique flexible avec platformFaultDomainCount=1 (FD=1) : les serveurs d’applications SAP déployés avec un groupe identique flexible (FD=1) distribuent les machines virtuelles entre différentes zones de disponibilité et le groupe identique distribue également les machines virtuelles entre différents domaines d’erreur au sein de chaque zone. Cela garantit que si une zone n’est pas disponible, les serveurs d’applications SAP déployés dans une autre zone continuent d’être disponibles.
  • Zone de disponibilité : les serveurs d’applications SAP déployés dans les zones de disponibilité garantissent que les machines virtuelles sont réparties entre différentes zones pour obtenir une redondance. Cela garantit que si une zone n’est pas disponible, les serveurs d’applications SAP déployés dans une autre zone continuent d’être disponibles. Pour plus d’informations, consultez les configurations de charge de travail SAP avec Azure Zones de disponibilité
  • Groupe à haute disponibilité : les serveurs d’applications SAP déployés dans un groupe à haute disponibilité garantissent que les machines virtuelles sont distribuées entre différents domaines d’erreur et domaines de mise à jour. Lors du placement de machines virtuelles sur différents domaines de mise à jour, assurez-vous que les machines virtuelles ne sont pas mises à jour en même temps pendant le temps d’arrêt de maintenance planifiée. Alors que le placement de machines virtuelles dans un domaine d’erreur différent garantit que la machine virtuelle est protégée contre les défaillances matérielles ou les interruptions d’alimentation au sein d’un centre de données. Toutefois, le nombre de domaines d’erreur et de mise à jour que vous pouvez utiliser dans un groupe à haute disponibilité Azure au sein d’une unité de mise à l’échelle Azure est limité. Si vous continuez à ajouter des machines virtuelles à un seul groupe à haute disponibilité, deux machines virtuelles ou plus finissent par se retrouver dans le même domaine d’erreur ou de mise à jour. Pour plus d’informations, consultez la section Groupes à haute disponibilité Azure du document Planification et implémentation de machines virtuelles Azure pour SAP NetWeaver.

Disques non managés uniquement : lorsque vous utilisez des disques non managés avec un groupe à haute disponibilité, il est important de reconnaître que le compte de stockage Azure devient un point de défaillance unique. Par conséquent, il est impératif de disposer d’un minimum de deux comptes de stockage Azure, dans lesquels au moins deux machines virtuelles sont distribuées. Dans une configuration idéale, les disques de chaque machine virtuelle exécutant une instance de dialogue SAP sont déployés dans un compte de stockage différent.

Important

Nous vous recommandons vivement d’utiliser des disques managés Azure pour vos installations à haute disponibilité SAP. Étant donné que les disques managés s’alignent automatiquement avec le groupe à haute disponibilité de la machine virtuelle à laquelle ils sont joints, ils augmentent la disponibilité de votre machine virtuelle et des services exécutés sur celle-ci.

Architecture de haute disponibilité pour une instance SAP ASCS/SCS sur Windows

Windows logo. Windows

Vous pouvez utiliser une solution WSFC pour protéger l’instance SAP ASCS/SCS. En fonction du type de configuration de partage de cluster (partage de fichiers ou disque partagé), vous pouvez faire référence à la solution appropriée en fonction de votre type de stockage.

Architecture de haute disponibilité pour une instance SAP ASCS/SCS sur Linux

Linux logo. Linux

Sur Linux, la configuration du clustering d’instances SAP ASCS/SCS dépend de la distribution du système d’exploitation et du type de stockage utilisé. Il est recommandé d’implémenter la solution appropriée en fonction de votre infrastructure de cluster de système d’exploitation spécifique.

Configuration multi-SID de SAP NetWeaver pour une instance SAP ASCS/SCS en cluster

Windows logo. Fenêtre

Le multi-SID est pris en charge avec WSFC, à l'aide de partages de fichiers et disques partagés. Pour plus d’informations sur l’architecture de haute disponibilité multi-SID sur Windows, consultez :

Linux logo. Linux

Le clustering multi-SID est pris en charge sur les clusters Linux Pacemaker pour SAP ASCS/ERS, limité à cinq SID SAP sur le même cluster. Pour plus d’informations sur l’architecture de haute disponibilité multi-SID sur Linux, consultez :

Haute disponibilité de l’instance SGBD

Dans un système SAP, les serveurs SGBD constituent également le point de défaillance unique. Il est donc important de protéger la base de données en implémentant une solution de haute disponibilité. La solution de haute disponibilité de SGBD varie en fonction de la base de données utilisée pour le système SAP. En fonction de votre base de données, suivez les instructions pour obtenir une haute disponibilité sur votre base de données.

Base de données Recommandation de récupération d’urgence
SAP HANA Réplication du système HANA (HSR)
Oracle Oracle Data Guard
IBM DB2 Haute disponibilité et reprise d’activité après sinistre (HADR)
Microsoft SQL Microsoft SQL Always On
SAP ASE ASE HADR Always On