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. Nous vous recommandons de déployer sur deux zones de 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 exigences de l'entreprise (objectif de temps de récupération (RTO), objectif de point de récupération (RPO), attentes en matière de temps de fonctionnement, rôle du 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 réseau local via une passerelle de réseau privé virtuel (VPN) déployée dans le hub d’une topologie hub-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.

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 . Utilisez des passerelles Azure ExpressRoute ou VPN redondantes interzone pour vous protéger 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 (NSG) 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 avez besoin d’un compte SAP Service Marketplace.)

Machines virtuelles

Cette architecture utilise des machines virtuelles. Pour la couche Application SAP, les machines virtuelles sont déployées pour tous les rôles d’instance - Web Dispatcher 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 avez besoin d’un compte SAP Service Marketplace.)

Groupes de placement de proximité (PPG). Lorsque des machines virtuelles sont déployées dans des zones de disponibilité, la latence au sein de la zone est généralement idéale pour les applications SAP. Dans de rares cas où la latence entre la base de données et les machines virtuelles d’application doit être réduite, vous pouvez utiliser des groupes de placement de proximité. Pour ces situations, les PPG garantissent la colocation, ce qui signifie que les machines virtuelles se trouvent dans le même centre de données pour réduire la latence des applications. En raison de restrictions potentielles avec des PPG, l’ajout de la base de données AvSet au PPG du système SAP doit être effectué de manière éparse et uniquement si nécessaire. 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 une fois déployées en tant que Gen2 peuvent être mises à l’échelle jusqu’à la plus grande disponible avec une opération de désallocation et de redimensionnement simple. 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 les disques gérés Azure pour les machines virtuelles et les partages de fichiers Azure ou Azure NetApp Files pour tous les besoins de stockage partagé NFS (Network File System) comme sapmnt et les volumes NFS de transport SAP. 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 Machines virtuelles Azure Déploiement du système de gestion de base de données (SGBD) Oracle pour la charge de travail SAP. L’article fournit des conseils spécifiques sur la disposition du système de fichiers, les recommandations de dimensionnement de disque 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 Automatic Storage Management (ASM) est également pris en charge pour les déploiements Oracle pour Oracle Database 12c Release 2 et plus.
• 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.
• 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.

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 charge de travail SAP peut être régional ou zonal, en fonction des exigences de disponibilité et de résilience des applications SAP et de la région sélectionnée. 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 de détails sur le déploiement d’Oracle Data Guard, veuillez consulter la section Documentation d’Oracle Data Guard sur Azure.

Cette architecture utilise des outils Oracle natifs sans logiciel de cluster réel ou la nécessité d’un équilibreur de charge dans le niveau base de données. Avec la configuration Oracle Data Guard Fast-Start Failover et SAP, le processus de basculement est automatisé et les applications SAP se reconnectent à la nouvelle base de données principale en cas de basculement. Diverses solutions de cluster tierces existent en tant qu’alternatives, telles que SIOS Protection Suite ou Veritas InfoScale, dont les détails de déploiement sont disponibles dans la documentation respective des fournisseurs tiers.

Oracle RAC. Oracle Real Application Cluster (RAC) n’est ni certifié ni pris en charge par Oracle dans Azure. Cependant, les technologies et l’architecture d’Oracle Data Guard pour la haute disponibilité peuvent offrir 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 nécessite un mécanisme pour décider, en cas d’indisponibilité logicielle ou infrastructurelle, quelle VM doit fournir 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 uniquement SBD (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.
• 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. Les gestionnaires de cluster certifiés Azure tiers peuvent également être utilisés pour fournir une 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. Les scripts fournis et gérés par Azure pour Oracle Database et Sauvegarde Azure pour Oracle répondent aux exigences de 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. Veuillez consulter la section Détails documentés pour savoir comment réaliser à la fois les sauvegardes de données et de journaux Oracle.
• 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 davantage d’informations et des exemples de charges de travail SAP qui utilisent certaines technologies semblables, veuillez consulter l'article suivant :

• Exécuter SAP NetWeaver dans Windows sur Azure