Déploiement SAP sur Azure à l’aide d’une base de données Oracle

Azure ExpressRoute
SAP HANA sur Azure (grandes instances)
Machines virtuelles Azure
Réseau virtuel Azure
Azure NetApp Files

Cette architecture de référence montre un ensemble de pratiques éprouvées pour l’exécution d’un SAP NetWeaver à haute disponibilité avec Oracle Database sur 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 montre une architecture de référence pour SAP sur Oracle dans Azure. Nous vous recommandons de déployer sur deux zones de disponibilité.

Diagram de l’architecture d’un système SAP de production sur Oracle dans Azure.

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

Note

Pour déployer cette architecture de référence, vous devez disposer des licences appropriées pour les produits SAP et les autres technologies non-Microsoft.

Components

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 pour optimiser 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.

Networking

Réseaux virtuels. Le service Réseau virtuel Azure connecte Azure ressources entre elles avec une sécurité renforcé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 niveau : application (SAP NetWeaver), base de données et 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 mise en réseau en étoile avec plusieurs réseaux virtuels appairés ensemble. Cette topologie fournit une segmentation et une isolation réseau pour les 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 des réseaux distincts, ce qui étend votre réseau local au 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 Azure ExpressRoute ou des passerelles 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éfini par logiciel qui envoie tout le trafic via la même infrastructure 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 NIC 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 Machines virtuelles Azure fournit des détails 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 de SAP pour les types de machines virtuelles Azure et les métriques de débit (SAPS), consultez SAP note 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 des machines virtuelles de base de données au PPG du système SAP doit être effectuée de manière éparse et uniquement si nécessaire. Pour plus d’informations sur les scénarios d’utilisation des PPG, consultez la documentation liée.

Machines virtuelles de génération 2 (Gen2). Lorsque vous déployez des machines virtuelles dans Azure, vous pouvez choisir la génération 1 ou la génération 2. Les machines virtuelles de génération 2 prennent en charge les fonctionnalités qui ne sont pas disponibles dans la génération 1. Ces fonctionnalités sont particulièrement importantes pour les bases de données Oracle volumineuses, car certaines familles de machines virtuelles, telles que Mv2 et Mdsv2, ne sont prises en charge que comme machines virtuelles Gen2. De même, la certification SAP sur Azure pour certaines machines virtuelles plus récentes peut nécessiter qu’elles soient uniquement Génération 2 pour une prise en charge complète, même si Azure permet les deux versions. Pour plus d’informations, consultez SAP Note 1928533 - Applications SAP sur Microsoft Azure : Produits pris en charge et types de machines virtuelles Azure.

É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.

Storage

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. Les instructions relatives au déploiement de stockage avec SAP sur Azure sont détaillées dans le guide Types de stockage Azure pour les charges de travail SAP.

Disponibilité élevée

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 fournit différentes options de déploiement, comme les Virtual Machine Scale Sets avec l’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 seule zone ou dans une région sans zones), consultez High-availability architecture and scenarios for SAP NetWeaver.

Équilibreurs de charge. Un Azure Load Balancer interne est utilisé pour distribuer le trafic vers des machines virtuelles dans les sous-réseaux SAP. Azure Load Balancer prend en charge la distribution redondante interzone pour les déploiements zonaux de SAP.

Tenez compte des facteurs de décision lors du déploiement de machines virtuelles entre des 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.

Note

Les Zones de Disponibilité soutiennent la haute disponibilité intra-région, mais elles ne sont pas efficaces pour la reprise après sinistre (DR). Les distances entre les zones sont trop courtes. En général, il doit y avoir au moins 160 kilomètres entre les régions de récupération d’urgence et la région principale.

Composants spécifiques à Oracle. Dans les régions zonales, les machines virtuelles Oracle Database sont déployées sur différentes zones de disponibilité à l’aide du modèle de déploiement Virtual Machine Scale Sets avec le nombre de domaines d’erreur défini sur 1 (FD=1). Dans les régions sans zones de disponibilité, utilisez des options de déploiement à haute disponibilité régionales, comme décrit dans l’architecture et les scénarios de haute disponibilité pour SAP NetWeaver. 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 via Oracle Data Guard entre les bases de données pour garantir la cohérence et autoriser des temps de service RTO et RPO faibles en cas de défaillances individuelles. 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. La gestion de la réplication de base de données peut être effectuée via Oracle Data Guard Broker pour faciliter l’utilisation.

Pour plus d’informations sur le déploiement d’Oracle Data Guard, consultez la documentation 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) est actuellement not certifié ou 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 de système de fichiers 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 un stockage redondant interzone (ZRS) - SLES et RHEL guides
  • Azure NetApp Files déploiement de volumes NFS - guides SLES et RHEL
  • Cluster NFS basé sur des machines virtuelles : deux machines virtuelles supplémentaires avec stockage local, répliquées entre les machines virtuelles avec DRBD (appareil de bloc répliqué distribué) - 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 une machine virtuelle ou une application non répondre

  • SBD (STONITH Block Device) : pour les déploiements SLES et RHEL, SBD peut être implémenté à l’aide d’une ou trois machines virtuelles supplémentaires qui servent d’exportations iSCSI d’un petit appareil de bloc, accessible régulièrement par les machines virtuelles membres du cluster réelles (les deux machines virtuelles SCS/ERS dans ce pool de clusters). Les machines virtuelles utilisent ces montages SBD pour émettre des votes et ainsi atteindre le quorum pour les décisions de grappe. L’architecture de cette page ne contient pas une ou trois machines virtuelles SBD supplémentaires.

  • Agent de fence Azure. Sans utiliser de machines virtuelles supplémentaires, Azure API de gestion est utilisée pour des vérifications régulières de 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. Des 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 obtenir la haute disponibilité de SAP Web Dispatcher, Azure Load Balancer implémente soit le cluster de basculement, soit la configuration 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 accessibles sur Internet, nous recommandons une solution autonome dans le réseau de périmètre (également appelé DMZ) pour répondre aux préoccupations 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 il n’existe aucune différence architecturale avec Oracle entre Linux et Windows.

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

Considerations

Récupération d’urgence

Le diagramme suivant montre 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é.

Diagram qui montre une architecture d’un système SAP de production sur Oracle dans Azure.

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

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 de récupération d’urgence et l’implémentation, consultez Vue d’ensemble de la récupération d’urgence et instructions d’infrastructure pour la charge de travail SAP et Instructions de récupération d’urgence pour l’application SAP.

Backup

La sauvegarde d’Oracle dans Azure peut être obtenue par plusieurs moyens :

  • Sauvegarde Azure.Scripts fournis et gérés par Azure pour Oracle Database et Sauvegarde Azure pour Oracle répondent aux exigences de sauvegarde.
  • Stockage Azure. À l'aide de sauvegardes de base de données basées sur des fichiers, par exemple planifiées avec les outils BR de SAP, pour être stockées et versionnées en tant que fichiers/répertoires sur les services de stockage Azure Blob NFS, Azure Blob ou Azure Files. Consultez les détails documentés pour obtenir des sauvegardes de données et de journaux Oracle.
  • Solutions de sauvegarde externes. Consultez l’architecture de votre fournisseur de stockage de sauvegarde, prenant en charge Oracle dans Azure.

Pour les machines virtuelles non de base de données, Sauvegarde Azure pour la machine virtuelle est recommandé de protéger les machines virtuelles d’application SAP et d’entourer l’infrastructure telle que SAP Web Dispatcher.

Contributors

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

Auteur principal :

Étapes suivantes

Communities

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

Pour davantage d’informations et des exemples de charges de travail SAP qui utilisent certaines technologies semblables, veuillez consulter l'article suivant :