Déploiement SAP sur Azure en utilisant une base de données Oracle

Cette architecture de référence présente un ensemble de pratiques éprouvées pour exécuter une plateforme SAP NetWeaver à haute disponibilité avec Oracle Database dans Azure. Les principes d’architecture sont indépendants du système d’exploitation. Toutefois, sauf indication contraire, l’architecture est supposée être basée sur Linux.

Le premier diagramme illustre une architecture de référence pour SAP sur Oracle dans Azure. L’architecture utilise des groupes à haute disponibilité.

Téléchargez un fichier Visio de cette architecture et des architectures associées.

Composants

Cette architecture de référence décrit un système de production SAP classique s’exécutant sur Oracle Database dans Azure, dans un déploiement hautement disponible afin de maximiser la disponibilité du système. L’architecture et ses composants peuvent être personnalisés en fonction des besoins métier (RTO, RPO, durée de bon fonctionnement exigée, rôle système) et potentiellement réduits à une seule machine virtuelle. La disposition du réseau est simplifiée pour illustrer les principes architecturaux d’un tel environnement SAP et n’est pas destinée à décrire un réseau d’entreprise complet.

Mise en réseau

Réseaux virtuels. Le service Réseau virtuel Azure connecte les ressources Azure entre elles, avec une sécurité améliorée. Dans cette architecture, le réseau virtuel se connecte à un environnement local via une passerelle de réseau privé virtuel (VPN) déployée dans le hub d’une topologie hub-and-spoke. Les applications SAP et la base de données sont contenues dans leur propre réseau virtuel spoke. Les réseaux virtuels sont subdivisés en sous-réseaux distincts pour chaque couche : l’application (SAP NetWeaver), la base de données et les services partagés (comme Azure Bastion).

Cette architecture divise l’espace d’adressage du réseau virtuel en sous-réseaux. Placez les serveurs d’applications sur un sous-réseau et les serveurs de base de données sur un autre. En procédant de la sorte, vous pouvez sécuriser plus facilement vos serveurs en gérant les stratégies de sécurité au niveau du sous-réseau et non au niveau de chaque serveur. De plus, les règles de sécurité applicables aux bases de données et aux serveurs d’applications sont clairement séparées.

Peering de réseaux virtuels. Cette architecture utilise une topologie de réseau hub-and-spoke avec plusieurs réseaux virtuels appairés. Cette topologie assure la segmentation et l’isolement réseau des services déployés sur Azure. Le peering permet une connectivité transparente entre les réseaux virtuels homologués via le réseau principal Microsoft. Elle n’entraîne pas de perte de performances si elle est déployée dans une seule région.

Passerelle redondante interzone. Une passerelle connecte différents réseaux et étend votre réseau local sur le réseau virtuel Azure. Nous vous recommandons d’utiliser ExpressRoute pour créer des connexions privées qui ne passent pas par l’Internet public, mais vous pouvez également utiliser une connexion de site à site . Les passerelles Azure ExpressRoute ou VPN peuvent être déployées sur plusieurs zones pour assurer une protection contre les défaillances de zone. Consultez l’article relatif aux passerelles de réseau virtuel redondantes interzones pour comprendre les différences entre un déploiement zonal et un déploiement redondant interzone. Il convient de mentionner ici que les adresses IP utilisées doivent être de type SKU Standard pour un déploiement zonal des passerelles.

Groupes de sécurité réseau. Pour limiter le trafic entrant, sortant et intra-sous-réseau dans le réseau virtuel, créez des groupes de sécurité réseau qui sont à leur tour affectés à des sous-réseaux spécifiques. Les sous-réseaux de base de donnée et d’application sont sécurisés avec des groupes de sécurité réseau spécifiques à la charge de travail.

Groupes de sécurité d’application. Pour définir des stratégies de sécurité réseau affinées dans vos groupes de sécurité réseau en fonction de charges de travail centrées sur des applications, utilisez des groupes de sécurité d’application plutôt que des adresses IP explicites. Les groupes de sécurité d’application vous permettent de regrouper les machines virtuelles par nom et de sécuriser les applications en filtrant le trafic provenant des segments approuvés de votre réseau.

Cartes d’interface réseau (NIC). Les cartes réseau assurent l’ensemble des communications des machines virtuelles sur un réseau virtuel. Les déploiements SAP locaux traditionnels implémentent plusieurs cartes réseau par machine pour séparer le trafic administratif du trafic opérationnel.

Sur Azure, le réseau virtuel est un réseau à définition logicielle qui envoie tout le trafic via la même structure réseau. Il n’est donc pas nécessaire d’utiliser plusieurs cartes réseau pour des raisons de performances. Toutefois, si votre organisation a besoin de séparer le trafic, vous pouvez déployer plusieurs cartes réseau par machine virtuelle et connecter chaque carte réseau à un sous-réseau différent. Vous pouvez ensuite utiliser des groupes de sécurité réseau pour appliquer différentes stratégies de contrôle d’accès à chaque sous-réseau.

Les cartes d’interface réseau Azure prennent en charge plusieurs adresses IP. Cette prise en charge est conforme à la pratique SAP recommandée pour utiliser des noms d’hôte virtuel pour les installations. Pour obtenir un plan complet, consultez la note SAP 962955. (Pour accéder aux notes SAP, vous devez disposer d’un compte SAP Service Marketplace.)

Machines virtuelles

Cette architecture utilise des machines virtuelles. Pour la couche application SAP, des machines virtuelles sont déployées pour tous les rôles d’instance (répartiteur web et serveurs d’applications), les services centraux SAP (A)SCS et ERS, ainsi que les serveurs d’applications (PAS, AAS). Ajustez le nombre de machines virtuelles en fonction de vos besoins. Le guide de planification et d’implémentation de machines virtuelles Azure inclut des informations sur l’exécution de SAP NetWeaver sur des machines virtuelles.

De même, pour toutes les opérations Oracle, des machines virtuelles sont utilisées pour Oracle Database et Oracle Observer. Dans cette architecture, les machines virtuelles Observer sont plus petites que les serveurs de base de données.

• Machines virtuelles limitées en processeurs virtuels. Pour réduire potentiellement les coûts de licence Oracle, envisagez d’utiliser des machines virtuelles limitées en processeurs virtuels.
• Familles de machines virtuelles certifiées pour SAP. Pour plus d’informations sur la prise en charge SAP en fonction des types de machines virtuelles Azure et des mesures de débit (SAPS), consultez la note SAP 1928533. (Pour accéder aux notes SAP, vous devez disposer d’un compte SAP Service Marketplace.)

Groupes de placement de proximité (PPG). Pour optimiser la latence réseau, vous pouvez utiliser des groupes de placement de proximité. Ceux-ci privilégient la colocation, ce qui signifie que les machines virtuelles se trouvent dans le même centre de centres pour réduire la latence d’application. Ils peuvent grandement améliorer l’expérience utilisateur pour la plupart des applications SAP. En raison des restrictions potentielles liées aux PPG, l’ajout du groupe à haute disponibilité de la base de données au PPG du système SAP doit être réalisé sporadiquement et uniquement en cas de besoin pour réduire la latence du trafic entre les bases de données et les applications SAP. Pour plus d’informations sur les scénarios d’utilisation des PPG, suivez les liens vers la documentation.

Machines virtuelles de génération 2 (Gen2). Lors du déploiement de machines virtuelles, Azure offre le choix entre des machines virtuelles de génération 1 ou 2. Les machines virtuelles de 2e génération prennent en charge des fonctionnalités de clés qui ne sont pas disponibles pour les machines virtuelles de 1ère génération. Cela revêt une importance particulière pour les bases de données Oracle très volumineuses. En effet, certaines familles de machines virtuelles comme Mv2 ou Mdsv2 sont prises en charge uniquement en tant que machines virtuelles Gen2. De même, la certification SAP sur Azure pour certaines machines virtuelles plus récentes peut nécessiter la 2e génération pour une prise en charge complète, même si Azure autorise les deux. Pour plus d’informations, consultez la Note SAP n°1928533 – Applications SAP sur Microsoft Azure : produits et types de machines virtuelles Azure pris en charge.

Étant donné que toutes les autres machines virtuelles prenant en charge SAP autorisent uniquement la 2e génération, voire 1ère + 2e générations, il est recommandé de déployer l’ensemble des machines virtuelles SAP en tant que 2e génération, même si les exigences en mémoire sont très faibles. Même les machines virtuelles les plus petites qui ont été déployées en tant que 2e génération peuvent faire l’objet d’un scale-up jusqu’à la plus grande échelle disponible avec une simple opération de libération et redimensionnement. Les machines virtuelles de 1ère génération peuvent être redimensionnées vers les familles de machines virtuelles autorisées à exécuter des machines virtuelles de 1ère génération.

Stockage

Cette architecture utilise des disques managés Azure pour les machines virtuelles et Azure Files NFS ou Azure NetApp Files pour répondre aux exigences de stockage partagé NFS (comme les volumes NFS de transport SAP et sapmnt). Vous trouverez des instructions détaillées sur le déploiement du stockage avec SAP sur Azure dans le guide des types de stockage Azure pour une charge de travail SAP.

• Stockage certifié pour SAP. Comme pour les types de machine virtuelle certifiés pour une utilisation avec SAP, examinez les détails de la note SAP 2015553 et de la note SAP 2039619.
• Conception du stockage pour SAP sur Oracle. Vous trouverez une conception de stockage recommandée pour SAP sur Oracle dans Azure dans Déploiement de SGBC Oracle sur des machines virtuelles Azure pour une charge de travail SAP. Cet article fournit une aide spécifique sur la disposition du système de fichiers, des recommandations de dimensionnement des disques et d’autres options de stockage.
• Stockage des fichiers Oracle Database. Sur Linux, les systèmes de fichiers ext4 ou xfs doivent être utilisés pour la base de données. NTFS doit être utilisé pour les déploiements Windows. Oracle ASM est également pris en charge pour les déploiements Oracle pour Oracle Database 12c versions 2 et ultérieures.
• Alternatives aux disques managés. Vous pouvez également utiliser Azure NetApp Files pour la base de données Oracle. Pour plus d’informations, consultez la note SAP 2039619 et la documentation Oracle sur Azure. Contrairement à Azure NetApp Files, les volumes Azure Files NFS ne sont pas destinés au stockage des fichiers Oracle Database.
• Azure SSD Premium v2 a été conçu pour les charges de travail critiques en matière de performances telles que SAP. Pour connaître les avantages et les limitations actuelles de cette solution de stockage, consultez Déployer un disque SSD Premium v2.

Haute disponibilité

L’architecture précédente illustre un déploiement hautement disponible, chaque couche d’application étant contenue dans au moins deux machines virtuelles. Les composants suivants sont utilisés.

Sur Azure, le déploiement de la charge de travail SAP peut être régional ou zonal, selon les exigences de disponibilité et de résilience des applications SAP. Azure propose différentes options de déploiement, comme Virtual Machine Scale Sets avec orchestration flexible (FD=1), les zones de disponibilité et les groupes à haute disponibilité, pour améliorer la disponibilité des ressources. Pour obtenir une compréhension complète des options de déploiement et de leur applicabilité dans différentes régions Azure (y compris entre les zones, au sein d’une même zone, ou dans une région sans zones), consultez Architecture et scénarios de haute disponibilité pour SAP NetWeaver.

Équilibreurs de charge.Azure Load Balancer est utilisé pour distribuer le trafic aux machines virtuelles dans les sous-réseaux SAP. Quand vous incorporez Azure Load Balancer dans un déploiement zonal de SAP, veillez à sélectionner l’équilibreur de charge avec la référence SKU Standard. L'équilibreur ayant la référence SKU De base ne prend pas en charge la redondance zonale.

Tenez compte des facteurs de décision quand vous déployez des machines virtuelles entre zones de disponibilité pour SAP. L’utilisation de groupes de placement de proximité avec un déploiement de zone de disponibilité doit être évaluée et autorisée uniquement pour les machines virtuelles de la couche application.

Composants propres à Oracle. Les machines virtuelles Oracle Database sont déployées dans un groupe à haute disponibilité ou dans différentes zones de disponibilité. Chaque machine virtuelle contient sa propre installation du logiciel de base de données et l’espace de stockage de la base de données locale. Configurez la réplication de base de données synchrone avec Oracle Data Guard entre les bases de données pour garantir la cohérence et réduire les temps de service RPO et RTO en cas de défaillance individuelle. Outre les machines virtuelles de base de données, des machines virtuelles supplémentaires avec Oracle Data Guard Observer sont nécessaires pour une configuration Oracle Data Guard Fast-Start Failover. Les machines virtuelles Oracle Observer surveillent la base de données et l’état de réplication, et facilitent le basculement de la base de données de manière automatisée, sans gestionnaire de cluster. Vous pouvez ensuite gérer la réplication de la base de données avec Oracle Data Guard Broker pour plus de facilité.

Pour plus d’informations sur le déploiement d’Oracle Data Guard, consultez :

• Livre blanc SAP - Configuration d’Oracle 12C Data Guard pour les clients SAP
• Documentation Oracle Data Guard sur Azure

Cette architecture utilise des outils Oracle natifs sans nécessiter la configuration du cluster ou le recours à un équilibreur de charge dans la couche base de données. Avec une configuration SAP et Oracle Data Guard Fast-Start Failover, le processus de basculement est automatisé et les applications SAP se reconnectent à la nouvelle base de données primaire en cas de basculement. Vous pouvez également utiliser des solutions de cluster tierces, comme SIOS Protection Suite ou Veritas InfoScale. Pour plus d’informations sur leur déploiement, consultez la documentation de chaque fournisseur tiers.

Oracle RAC. Oracle Real Application Cluster (RAC) n’est ni certifié ni pris en charge par Oracle dans Azure. Toutefois, la haute disponibilité des technologies et de l’architecture d’Oracle Data Guard peut fournir des environnements SAP hautement résilients avec une protection contre les interruptions de service au niveau des racks, des centres de données ou des régions.

Niveau NFS. Pour tous les déploiements SAP hautement disponibles, un niveau NFS résilient doit être utilisé afin de fournir des volumes NFS pour le répertoire de transport SAP, un volume sapmnt pour les binaires SAP ainsi que des volumes supplémentaires pour les instances (A)SCS et ERS. Les options permettant de fournir une couche NFS sont les suivantes :

• Azure Files NFS avec stockage redondant interzone (ZRS) - Guides SLES et RHEL
• Déploiement Azure NetApp Files de volumes NFS - Guides SLES et RHEL
• Cluster NFS basé sur des machines virtuelles - Deux machines virtuelles supplémentaires avec stockage local, avec réplication entre les machines virtuelles avec DRBD (Distributed Replicated Block Device) - Guides SLES et RHEL

Cluster des services centraux SAP. Cette architecture de référence exécute les services centraux sur des machines virtuelles discrètes. Les services centraux constituent un potentiel point de défaillance unique (SPOF) lorsqu’ils sont déployés dans une seule machine virtuelle. Pour implémenter une solution hautement disponible, un logiciel de gestion de cluster est nécessaire pour automatiser le basculement des instances (A)SCS et ERS sur la machine virtuelle appropriée. Ceci est étroitement lié à la solution NFS choisie.

La solution de cluster choisie doit disposer d’un mécanisme pour déterminer, en cas d’indisponibilité du logiciel ou de l’infrastructure, la machine virtuelle devant traiter le ou les services respectifs. Avec SAP sur Azure, deux options sont disponibles pour l’implémentation basée sur Linux de STONITH (comment gérer les machines virtuelles ou les applications qui ne répondent pas).

• SUSE-Linux uniquementSBD (STONITH Block Device) - Utilise une ou trois machines virtuelles supplémentaires faisant office d’exportations iSCSI d’un petit périphérique de traitement par blocs, accessible régulièrement par les machines virtuelles membres du cluster, deux machines virtuelles (A)SCS/ERS dans ce pool de clusters. Les machines virtuelles utilisent ces montages SBD pour caster des votes et ainsi atteindre le quorum pour les décisions de cluster. L’architecture contenue sur cette page ne contient pas les 1 ou 3 machines virtuelles SBD supplémentaires. RedHat ne prenant pas en charge les implémentations SBD dans Azure, cette option n’est disponible que pour le système d’exploitation SUSE Linux Enterprise Server.
• Agent d’isolation Azure. Sans utiliser de machines virtuelles supplémentaires, l’API de gestion Azure est utilisée pour vérifier régulièrement la disponibilité des machines virtuelles.

Les guides dont les liens figurent dans la section de la couche NFS décrivent les étapes nécessaires et la conception pour chaque choix de cluster. Vous pouvez également utiliser des gestionnaires de clusters certifiés Azure tiers pour assurer la haute disponibilité des services centraux SAP.

Pool de serveurs d’applications SAP. Au moins deux serveurs d’applications où la haute disponibilité est obtenue en équilibrant la charge des demandes au moyen de répartiteurs web ou d’un serveur de messages SAP. Chaque serveur d’applications est indépendant et aucun équilibrage de la charge réseau n’est nécessaire pour ce pool de machines virtuelles.

Pool de répartiteurs web SAP. Le composant Web Dispatcher sert d’équilibreur de charge pour le trafic SAP entre les serveurs d’applications SAP. Pour assurer la haute disponibilité du composant SAP Web Dispatcher, Azure Load Balancer implémente le cluster de basculement ou l’installation parallèle de Web Dispatcher.

Un répartiteur web incorporé sur (A)SCS est une option spéciale. Veillez à effectuer un dimensionnement approprié en raison d’une charge de travail supplémentaire sur (A)SCS.

Pour les communications sur Internet, nous recommandons une solution autonome dans le réseau de périmètre (également appelé DMZ) pour répondre aux problèmes de sécurité.

Déploiements Windows. Ce document, comme indiqué en préface, se concentre principalement sur les déploiements basés sur Linux. Pour une utilisation avec Windows, les mêmes principes architecturaux s’appliquent et Oracle ne présente aucune différence architecturale entre Linux et Windows.

Pour la partie concernant les applications SAP, consultez les détails dans le guide d’architecture Exécuter SAP NetWeaver dans Windows sur Azure.

Considérations

Récupération d'urgence

Le diagramme suivant illustre l’architecture d’un système SAP de production sur Oracle dans Azure. L’architecture assure la reprise d’activité après sinistre (DR) et utilise des zones de disponibilité.

Téléchargez un fichier Visio de cette architecture et des architectures associées.

Chaque couche architecturale de la pile d’applications SAP utilise une approche différente pour assurer la protection de la reprise d’activité après sinistre. Pour plus d’informations sur les stratégies et l’implémentation de la reprise d’activité après sinistre, consultez Vue d’ensemble de la reprise d’activité après sinistre et instructions d’infrastructure pour la charge de travail SAP et Instructions de reprise d’activité après sinistre pour l’application SAP.

Sauvegarde

Une sauvegarde pour Oracle dans Azure peut être effectuée de plusieurs façons :

• Sauvegarde Azure.Azure fournit et tient à jour des scripts pour les bases de données Oracle afin de faciliter l’exécution des actions Oracle avant et après la sauvegarde.
• Stockage Azure. En utilisant les sauvegardes de bases de données basées sur les fichiers, planifiées par exemple avec les outils BR de SAP, pour les stocker et les versionner en tant que fichiers/répertoires sur les services de stockage Azure Blob NFS, Azure Blob ou Azure Files. Pour plus d’informations sur la sauvegarde de données et de journaux Oracle, consultez cette documentation.
• Solutions de sauvegarde tierces. Examinez l’architecture de votre fournisseur de stockage de sauvegarde prenant en charge Oracle dans Azure.

Pour les machines virtuelles ne contenant pas de base de données, il est recommandé d’utiliser Sauvegarde Azure pour machines virtuelles afin de protéger les machines virtuelles d’applications SAP et l’infrastructure environnante comme SAP Web Dispatcher.

Contributeurs

Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.

Auteur principal :

• Robert Biro | Architecte senior

Étapes suivantes

• Haute disponibilité pour SAP NetWeaver sur des machines virtuelles Azure
• Planification et implémentation de machines virtuelles Azure pour SAP NetWeaver
• Utiliser Azure pour héberger et exécuter des scénarios de charge de travail SAP

Communautés

Les communautés peuvent répondre aux questions et vous aider à paramétrer un déploiement réussi. Prenez en compte les ressources suivantes :

• Blog Running SAP Applications on the Microsoft Platform (Exécution d’applications SAP sur la plateforme Microsoft)
• Support de la communauté Azure
• Communauté SAP
• Stack Overflow pour SAP

Ressources associées

Pour plus d’informations et des exemples de charges de travail SAP qui utilisent certaines technologies semblables, reportez-vous aux articles suivants :

• SAP NetWeaver sur SQL Server
• Exécuter SAP NetWeaver dans Windows sur Azure
• Environnements de développement/test pour les charges de travail SAP sur Azure