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

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.

• Utiliser le 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 en cas de 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 à haute disponibilité SAP intégrée pour Linux comme celle de 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 de 99,9 % pour machine virtuelle unique avec le 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 comportant au moins deux instances déployées dans le même groupe de disponibilité, nous garantissons une connectivité à une instance minimum pendant 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 les diverses machines virtuelles ne sont pas redémarrées en même temps lors de 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 une source d’alimentation électrique ni un commutateur réseau communs. 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 Gestion de la disponibilité des machines virtuelles dans Azure à l’aide des groupes de disponibilité.

Zones de disponibilité Azure

Azure est en train de déployer un concept de Zones de disponibilité Azure 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.

Lorsque vous utilisez les Zones de disponibilité, vous devez tenir compte de certains éléments. 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 de 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. Vous devez plutôt utiliser la Référence SKU Azure Standard Load Balancer.
• Les Zones de disponibilité Azure ne donnent aucune garantie d’une certaine distance entre les différentes zones dans 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 est tout à fait possible que vous, en tant que client, puissiez raisonnablement exécuter la couche d’application SAP déployée dans différentes zones, car la latence du réseau d’une zone vers la machine virtuelle SGBD active est encore acceptable du point de vue de l’impact sur les processus métier. En revanche, il est également possible que la latence entre la machine virtuelle SGBD active dans une zone et une instance d’application SAP sur une machine virtuelle dans une autre zone soit trop intrusive et inacceptable 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 les Zones de disponibilité Azure.

Groupe de machines virtuelles identiques avec une orchestration flexible

Dans Azure, les groupes de machines virtuelles identiques avec orchestration flexible fournissent un moyen d’obtenir une haute disponibilité pour les charges de travail SAP, comme d’autres infrastructures de déploiement telles que les groupes de 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 d’un 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 d’un 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 les machines virtuelles entre différents domaines d’erreur au sein de chaque zone de manière optimale. 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 branche centrale 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 à un seul réseau, et que tous les composants du système SAP, tels que les bases de données, ASCS/ERS et le niveau d’application, sont répartis au niveau de la zone.

Par conséquent, pour un 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, voir le jeu d’échelle de la machine virtuelle pour le document sur la 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 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

Les disques managés sont des ressources dans Azure Resource Manager et constituent une option de stockage recommandée à la place des disques durs virtuels (VHD) stockés dans les comptes de stockage Azure. Les disques managés sont automatiquement alignés sur un groupe de disponibilité de la machine virtuelle à laquelle 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 les charges de travail SAP

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

Options de déploiement à haute disponibilité pour les charges 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.

• 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. Vous avez alors la certitude que si une zone n’est pas disponible, le système SAP d’une autre zone reste disponible. 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 hautement disponibles tels que SAP ASCS/ERS et les bases de données SAP sont distribués entre différentes zones, tandis que plusieurs serveurs d’applications de chaque zone sont répartis entre différents domaines d’erreur de manière optimale.
• 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 de 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. 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 de 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.

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

Si vous décidez de ne pas utiliser des fonctionnalités telles que WSFC ou Pacemaker sur Linux (prises en charge par 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 en cas de 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 de l’infrastructure Azure pour une plus haute 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 et 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 de 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’application SAP déployés avec un groupe identique (FD=1) distribuent les machines virtuelles entre différentes zones de disponibilité et le groupe identique distribuerait également les machines virtuelles entre différents domaines d’erreur au sein de chaque zone de manière optimale. Vous avez alors la certitude que si une zone n’est pas disponible, les serveurs d’application SAP d’une autre zone restent 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. Vous avez alors la certitude que si une zone n’est pas disponible, les serveurs d’application SAP d’une autre zone restent disponibles. Pour plus d’informations, consultez Configurations des charges de travail SAP avec des Zones de disponibilité Azure.
• Groupe de disponibilité : les serveurs d’applications SAP déployés dans un groupe de disponibilité garantissent que les machines virtuelles sont distribuées entre différents domaines d’erreur et domaines de mise à jour. Lorsque vous placez des machines virtuelles sur différents domaines de mise à jour, cela garantit que les machines virtuelles ne sont pas mises à jour en même temps pendant le temps d’arrêt de maintenance planifiée. Tandis que si vous placez des machines virtuelles dans un domaine d’erreur différent, cela 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 de disponibilité Azure au sein d’une unité de mise à l’échelle Azure est limité. Si vous continuez d’ajouter des machines virtuelles à un groupe de disponibilité, deux machines virtuelles ou plus pourraient 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 de 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.

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

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.

• Partage de cluster : partage de fichiers

  • Haute disponibilité de l’instance SAP ASCS/SCS à l’aide de SMB sur Azure Files.
  • Haute disponibilité de l’instance SAP ASCS/SCS à l’aide de SMB sur Azure NetApp Files.
  • Haute disponibilité de l’instance SAP ASCS/SCS à l’aide du serveur de fichiers Scale Out (SOFS).

• Partage de cluster : disque partagé

  • Haute disponibilité de l’instance SAP ASCS/SCS à l’aide d’un disque partagé Azure.
  • Haute disponibilité de l’instance SAP ASCS/SCS à l’aide de SIOS.

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

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.

• SUSE Linux Enterprise Server (SLES)

  • Haute disponibilité de l’instance SAP ASCS/SCS à l’aide de NFS avec montage simple.
  • Haute disponibilité de l’instance SAP ASCS/SCS à l’aide de NFS sur Azure Files.
  • Haute disponibilité de l’instance SAP ASCS/SCS à l’aide de NFS sur Azure NetApp Files.
  • Haute disponibilité de l’instance SAP ASCS/SCS à l’aide du serveur NFS.

• Red Hat Enterprise Linux (RHEL)

  • Haute disponibilité de l’instance SAP ASCS/SCS à l’aide de NFS sur Azure Files.
  • Haute disponibilité de l’instance SAP ASCS/SCS à l’aide de NFS sur Azure NetApp Files.

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

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 :

• Partage de fichiers : haute disponibilité multi-SID de l’instance SAP ASCS/SCS pour le clustering de basculement Windows Server et le partage de fichiers.
• Disque partagé : haute disponibilité multi-SID de l’instance SAP ASCS/SCS pour le clustering de basculement Windows Server et un disque partagé

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 :

• SUSE Linux Enterprise Server (SLES) : haute disponibilité pour SAP NW sur des machines virtuelles Azure sur SLES pour les applications SAP multi-SID.
• Red Hat Linux Enterprise (RHEL) : haute disponibilité pour SAP NW sur des machines virtuelles Azure sur RHEL pour les applications SAP multi-SID.

Instance SGBD à haute disponibilité

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.