Modifier

Partager via

Exécuter SAP HANA pour machines virtuelles Linux dans une architecture de scale-up sur Azure

Azure
Machines virtuelles Azure

Cette architecture de référence présente un ensemble de pratiques éprouvées pour l’exécution de SAP HANA dans un environnement de scale-up hautement disponible prenant en charge la récupération d’urgence sur Azure. Cette implémentation se concentre uniquement sur la couche de base de données.

Architecture

Cette architecture de référence décrit un système de production courant. Vous pouvez choisir la taille des machines virtuelles pour répondre aux besoins de votre organisation. Cette configuration peut aussi être réduite à une seule machine virtuelle, en fonction des besoins de l’entreprise.

Le diagramme suivant montre une architecture de référence pour SAP HANA sur Azure :

Diagramme illustrant une architecture de déploiement régional.

Téléchargez un fichier Visio qui contient les diagrammes de cet article.

Notes

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.

Workflow

Cette architecture de référence décrit une base de données SAP HANA classique exécutée 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 par le biais d’une passerelle ExpressRoute déployée dans le hub d’une topologie hub-and-spoke. La base de données SAP HANA est contenue dans son propre réseau virtuel spoke. Les réseaux virtuels spoke contiennent un sous-réseau pour les machines virtuelles de base de données.

Si des applications se connectant à SAP HANA sont exécutées sur des machines virtuelles, les machines virtuelles d’application doivent se trouver dans le même réseau virtuel, mais dans un sous-réseau d’application dédié. Si la connexion SAP HANA n’est pas la base de données primaire, les machines virtuelles d’application peuvent également se trouver dans d’autres réseaux virtuels. La séparation en sous-réseaux par charge de travail permet une activation plus facile des groupes de sécurité réseau (NSG) pour définir des règles de sécurité applicables aux machines virtuelles SAP HANA uniquement.

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 (NSG). Pour limiter le trafic réseau entrant et sortant du réseau virtuel, créez des groupes de sécurité réseau qui sont à leur tour attribué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 (ASG). Pour définir des stratégies de sécurité réseau affinées dans vos groupes de sécurité réseau selon les charges de travail et centrées sur les 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 interfaces réseau de machines virtuelles par nom et de sécuriser les applications en filtrant le trafic issu des segments approuvés de votre réseau.

Cartes d’interface réseau (NICs). 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, il n’est pas nécessaire d’utiliser plusieurs cartes réseau pour des raisons de performances. Plusieurs cartes réseau partagent la même limite de débit réseau d’une machine virtuelle. 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.)

Notes

Comme spécifié dans la Note SAP 2731110, ne placez pas d’appliance virtuelle réseau (NVA) entre les couches d’application et de base de données pour n’importe quelle pile d’applications SAP. Cela entraîne un temps de traitement significatif des paquets de données et une lenteur inacceptable des performances de l’application.

Machines virtuelles

Cette architecture utilise des machines virtuelles. Azure offre un scale-up à nœud unique jusqu’à 32 Tebibytes (Tio) de mémoire sur des machines virtuelles. Le répertoire SAP Certified and Supported SAP HANA Hardware (Matériel SAP HANA certifié et pris en charge par SAP) répertorie les machines virtuelles certifiées pour la base de données SAP HANA. 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 - SAP Applications on Microsoft Azure: Supported Products and Azure VM Types (Applications SAP sur Microsoft Azure : produits et types de machines virtuelles Azure pris en charge). (Pour accéder à cette note de SAP et à d’autres, vous devez disposer d’un compte SAP Service Marketplace.)

Microsoft et SAP certifient conjointement une plage de tailles de machine virtuelle pour les charges de travail SAP HANA. Par exemple, les petits déploiements peuvent s’exécuter sur une machine virtuelle Edsv4 ou Edsv5 à partir de 160 Gio de RAM. Pour prendre en charge les plus grandes tailles de mémoire SAP HANA sur les machines virtuelles, jusqu’à 30 Tio, vous pouvez utiliser des machines virtuelles de série Mv3.

Machines virtuelles de génération 2 (Gen2). Lorsque vous déployez des VM, vous pouvez utiliser des VM de génération 1 ou de génération 2. Les machines virtuelles de 2e génération prennent en charge des fonctionnalités clés qui ne sont pas disponibles pour les machines virtuelles de 1ère génération. Pour SAP HANA, cela est particulièrement important, car certaines familles de machines virtuelles, comme Mv2, Mdsv2, Msv3 et Mdsv3 sont prises en charge uniquement en tant que machines virtuelles Gen2. De même, la certification SAP sur Azure peut nécessiter des machines virtuelles plus récentes pour gen2, même si Azure autorise à la fois Gen1 et Gen2. Pour plus d’informations, consultez note SAP 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 HANA permettent de choisir entre Gen2 uniquement et Gen1+2, nous vous recommandons de déployer toutes les VM SAP en tant que Gen2 uniquement. Cela s’applique également aux machines virtuelles dont les besoins en mémoire sont faibles. Même la plus petite machine virtuelle SAP HANA peut s’exécuter en tant que machine virtuelle Gen2 et peut être, lorsqu’elle est libérée, être redimensionnée sur la plus grande machine virtuelle disponible dans votre région.

Groupes de placement de proximité. Pour optimiser la latence du réseau, vous pouvez utiliser groupes de placement de proximité, qui hiérarchisent la colocalisation. Les machines virtuelles se trouvent dans le même centre de données pour réduire la latence entre SAP HANA et connecter des machines virtuelles d’application. Pour l’architecture SAP HANA elle-même, les groupes de placement de proximité ne sont pas nécessaires, mais ils peuvent vous aider à optimiser vos performances. En raison de restrictions potentielles avec les groupes de placement de proximité, vous devez ajouter le groupe de disponibilité de base de données au groupe de placement de proximité du système SAP uniquement lorsque cela est nécessaire pour la latence entre l’application SAP et le trafic de base de données. Pour plus d’informations sur les scénarios d’utilisation des groupes de placement de proximité, consultez options de configuration pour réduire la latence réseau avec les applications SAP. Étant donné que les groupes de placement de proximité limitent les charges de travail à un seul centre de données, un groupe de placement de proximité ne peut pas s’étendre sur plusieurs zones de disponibilité. Les déploiements à volume élevé qui référencent des groupes de placement de proximité peuvent être soumis à des limitations d’allocation de ressources.

Composants

Considérations

Cette section décrit les éléments clés à prendre en compte pour l'exécution de SAP HANA sur Azure.

Extensibilité

Cette architecture exécute SAP HANA sur des machines virtuelles qui peuvent effectuer un scale-up jusqu’à 32 Tio dans une instance.

Si votre charge de travail dépasse la taille maximale de la machine virtuelle, utilisez des configurations de scale-out à plusieurs nœuds HANA. Pour les applications OLTP (Online Transaction Processing), la capacité totale de mémoire de scale-out peut être aussi élevée que 4 x 23 Tio. Pour les applications de traitement analytique en ligne (OLAP), la capacité de mémoire avec montée en puissance scale-out peut être aussi élevée que 16 x 7,6 Tio. Par exemple, vous pouvez déployer SAP HANA dans une configuration avec montée en puissance parallèle sur des machines virtuelles exécutant Red Hat Enterprise Linux ou SUSE Linux Enterprise Server et utiliser Azure NetApp Files pour les volumes de stockage partagé. Pour identifier les références SKU de machine virtuelle certifiées qui prennent en charge les configurations de scale-out, consultez la Répertoire matériel SAP HANA certifié et pris en charge. Passez en revue les détails du certificat pour chaque référence SKU de machine virtuelle pour garantir la prise en charge de votre configuration.

Stockage

Cette architecture utilise des disques managés Azure pour le stockage sur les machines virtuelles ou Azure NetApp Files. Les instructions relatives au déploiement du stockage avec des disques managés sont détaillées dans le document Configurations du stockage des machines virtuelles SAP HANA Azure. À la place des disques managés, vous pouvez également utiliser des volumes NFS Azure NetApp Files comme solution de stockage pour SAP HANA.

Pour des opérations d’entrée/sortie par seconde (IOPS) et un débit de stockage sur disque élevés, les pratiques courantes en matière d’optimisation des performances du volume de stockage s’appliquent aussi à la disposition du stockage Azure. Par exemple, la combinaison de plusieurs disques avec LVM pour créer un volume de disques agrégés par bandes améliore les performances d’E/S. La mise en cache sur disque Azure joue également un rôle important en termes d’obtention des performances d’E/S requises.

Pour les disques de journal SAP HANA qui s’exécutent sur Azure SSD Premium v1, utilisez l’une des technologies suivantes dans les emplacements qui contiennent /hana/log pour la production :

Ces technologies sont nécessaires pour répondre de manière cohérente à l'exigence d'une latence de stockage inférieure à 1 ms.

Azure SSD Premium v2 est conçu pour les charges de travail critiques en matière de performances telles que SAP. L’accélérateur d’écriture n’est pas nécessaire lorsque /hana/log s’exécute sur SSD Premium v2. Pour plus d’informations sur les avantages et les limitations actuelles de cette solution de stockage, consultez Déployer un disque SSD Premium v2.

Pour plus d’informations sur les exigences en termes de performances de SAP HANA, consultez la Note SAP 1943937 - Hardware Configuration Check Tool (Outil de vérification de la configuration matérielle).

  • Conception d'un système de stockage économique pour les systèmes de non-production. Pour les environnements SAP HANA qui ne nécessitent pas des performances de stockage maximales dans toutes les situations, vous pouvez utiliser une architecture de stockage optimisée en termes de coûts. Ce choix d’optimisation du stockage peut s’appliquer à des systèmes de production peu utilisés ou à certains environnements SAP HANA hors production. L'option de stockage à coût optimisé utilise une combinaison de disques SSD standard au lieu des disques SSD Premium ou Ultra utilisés dans les environnements de production. Elle combine également les systèmes de fichiers /hana/data et /hana/log sur un ensemble unique de disques. Des instructions et bonnes pratiques sont disponibles pour la plupart des tailles de machines virtuelles. Si vous utilisez Azure NetApp Files pour SAP HANA, des volumes à taille réduite peuvent être utilisés pour atteindre le même objectif.

  • Redimensionnement du stockage lors d’une mise à l’échelle. Lorsque vous redimensionnez une machine virtuelle en raison de l'évolution des besoins de l'entreprise ou de l'augmentation de la taille de la base de données, la configuration du stockage peut changer. Azure prend en charge l’extension des disques en ligne, sans aucune interruption de service. Avec une configuration de disques agrégés par bandes, comme celle utilisée pour SAP HANA, une opération de redimensionnement doit être équitablement effectuée sur tous les disques du groupe de volumes. L’ajout de disques supplémentaires à un groupe de volumes peut potentiellement déséquilibrer les données agrégées par bandes. Si vous ajoutez d’autres disques à une configuration de stockage, il est nettement préférable de créer un nouveau volume de stockage sur de nouveaux disques. Ensuite, copiez le contenu pendant le temps d’arrêt et modifiez les points de montage. Enfin, éliminez l'ancien groupe de volumes et les disques sous-jacents.

  • Groupes de volumes d’application Azure NetApp Files. Pour les déploiements avec fichiers SAP HANA contenus sur des volumes NFS Azure NetApp Files, les groupes de volumes d’application vous permettent de déployer tous les volumes en fonction des meilleures pratiques. Ce processus garantit également des performances optimales pour votre base de données SAP HANA. Vous trouverez des détails sur la façon de procéder. Nécessite une intervention manuelle. Prévoyez un peu de temps pour la création.

Haute disponibilité

L'architecture précédente illustre un déploiement hautement disponible, avec SAP HANA contenu dans deux machines virtuelles ou plus. Les composants suivants sont utilisés.

Équilibreurs de charge.Azure Load Balancer est utilisé pour distribuer le trafic vers la machine virtuelle SAP HANA. 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 de référence SKU de base ne prend pas en charge la redondance zonale et déconseillée. Dans cette architecture, l’équilibreur de charge agit en tant qu’adresse IP virtuelle pour SAP HANA. Le trafic réseau est envoyé à la machine virtuelle active avec l’instance de base de données principale. L’architecture active/lecture SAP HANA est éventuellement disponible (SLES/RHEL) où une deuxième adresse IP virtuelle adressée sur l’équilibreur de charge est utilisée pour diriger le trafic réseau vers l’instance SAP HANA secondaire sur une autre machine virtuelle pour les charges de travail intenses en lecture.

Le Standard Load Balancer fournit un haut niveau de sécurité par défaut. Les machines virtuelles qui se trouvent derrière le Standard Load Balancer n'ont pas de connectivité internet sortante. Pour activer l'internet sortant dans ces machines virtuelles, vous devez mettre à jour la configuration de votre Standard Load Balancer. En outre, vous pouvez également utiliser une passerelle Azure NAT Gateway pour obtenir une connectivité sortante.

Pour les clusters de base de données SAP HANA, vous devez activer le retour direct du serveur (DSR), également appelé IP flottante. Cette fonctionnalité permet au serveur de répondre avec l’adresse IP du serveur frontal de l’équilibreur de charge.

Options de déploiement. Sur Azure, le déploiement de la charge de travail SAP peut être régional ou zonal, en fonction des exigences de disponibilité et de résilience des applications SAP. Azure fournit 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 disponibles 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 Architecture et scénarios de haute disponibilité pour SAP NetWeaver.

SAP HANA. Pour la haute disponibilité, SAP HANA s’exécute sur deux machines virtuelles Linux ou plus. La réplication de système HANA (HSR) SAP est utilisée pour répliquer les données entre les systèmes SAP HANA principal et secondaire (réplica). HSR est également utilisé pour la récupération d’urgence entre les régions ou entre les zones. En fonction de la latence de la communication entre vos machines virtuelles, la réplication synchrone peut être utilisée au sein d’une région. Dans la plupart des cas, la réplication HSR entre les régions pour la récupération d’urgence sera asynchrone.

Pour le cluster Linux Pacemaker, vous devez décider du mécanisme de clôture du cluster à utiliser. Pour le cluster Linux Pacemaker, vous devez décider du mécanisme de clôture du cluster à utiliser. Pour RedHat Enterprise Linux (RHEL), le seul mécanisme de clôturage pris en charge pour Pacemaker sur Azure est l’agent de clôturage Azure. Pour SUSE Linux Enterprise Server (SLES), vous pouvez utiliser l'agent Azure fence ou STONITH Block Device (SBD). Comparez les temps de basculement de chaque solution et, s'il y a une différence, choisissez une solution en fonction des exigences de votre entreprise en matière d'objectif de temps de reprise (RTO).

Agent de clôture Azure. Cette méthode d’escrime s’appuie sur l’API Azure ARM, avec Pacemaker interrogeant l’API ARM sur l’état des deux machines virtuelles SAP HANA dans le cluster. Si une machine virtuelle échoue, par exemple un blocage du système d’exploitation ou un incident de machine virtuelle, le gestionnaire de cluster utilise à nouveau l’API ARM pour redémarrer la machine virtuelle et, si nécessaire, l’échec de la base de données SAP HANA vers l’autre nœud actif. À cet effet, un principal de nom de service (SPN) avec un rôle personnalisé pour interroger et redémarrer des machines virtuelles est utilisé pour autoriser sur l’API ARM. Aucune autre infrastructure n’est nécessaire. Les machines virtuelles SBD dans les diagrammes d’architecture ne sont pas déployées si l’agent de clôture Azure est utilisé.

SBD. Le périphérique de traitement par blocs STONITH (SBD) utilise un disque auquel le gestionnaire de cluster accède en tant que périphérique de traitement par blocs (brut, sans système de fichiers). Ce disque, ou ces disques s’il y en a plusieurs, font office de vote. Chacun des deux nœuds de cluster exécutant SAP HANA accède aux disques SDB et y lit/écrit périodiquement de petits éléments d’informations sur l’état. Ainsi, chaque nœud de cluster connaît l’état de l’autre sans dépendre uniquement de la mise en réseau entre les machines virtuelles.

De préférence, trois petites machines virtuelles sont déployées dans un groupe à haute disponibilité ou une zone de disponibilité. Chaque machine virtuelle exporte de petites parties d’un disque en tant que périphérique de traitement par blocs auquel accèdent les deux nœuds de cluster SAP HANA. Trois machines virtuelles SBD garantissent la disponibilité d’un nombre suffisant de membres votants en cas d’arrêt planifié ou non de l’une des machines virtuelles SBD.

Au lieu d'utiliser des machines virtuelles SBD, vous pouvez utiliser un disque partagé Azure. Les nœuds de cluster SAP HANA accèdent alors au disque partagé. Le disque partagé peut être localement redondant (LRS) ou redondant interzone (ZRS), si l’option ZRS est disponible dans votre région Azure.

Récupération d'urgence

L'architecture suivante présente un environnement HANA de production sur Azure qui permet la reprise après sinistre. L’architecture intègre des zones de disponibilité.

Diagramme montrant une architecture avec récupération d'urgence.

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.

Notes

En cas de sinistre régional provoquant un événement de basculement en masse pour un nombre important de clients Azure dans une région, la capacité de ressources de la région cible n’est pas garantie. Comme tous les services Azure, Azure Site Recovery continue à ajouter des fonctionnalités. Pour obtenir les informations les plus récentes sur la réplication Azure vers Azure, consultez la matrice de prise en charge.

En plus d’une implémentation locale de haute disponibilité à deux nœuds, HSR prend en charge la réplication multicouche et multicible. HSR prend donc en charge la réplication inter-zone et inter-région. La réplication multi-cibles est disponible pour SAP HANA 2.0 SPS 03 et les versions ultérieures.

Veillez à vérifier la capacité des ressources de votre région cible.

Fichiers Azure NetApp. En guise d’option, Azure NetApp Files peut être utilisé pour fournir une solution de stockage scalable et haute performance pour les données et les fichiers journaux SAP HANA. Azure NetApp Files prend en charge les instantanés pour la sauvegarde, la récupération et la réplication locale rapides. Pour la réplication de contenu entre régions, la fonctionnalité Réplication inter-régions Azure NetApp Files peut être utilisée pour répliquer les données des instantanés entre deux régions. Des informations détaillées sur la réplication inter-régions et un livre blanc décrivant tous les aspects de la récupération d’urgence avec Azure NetApp Files sont disponibles.

Sauvegarde

Il existe plusieurs façons de sauvegarder les données SAP HANA. Après la migration vers Azure, vous pouvez continuer à utiliser les solutions de sauvegarde partenaires existantes que vous possédez déjà. Azure offre deux approches natives : la sauvegarde au niveau du fichier SAP HANA et Sauvegarde Azure pour SAP HANA via l’interface Backint.

Pour la sauvegarde au niveau du fichier SAP HANA, vous pouvez utiliser l’outil de votre choix, comme hdbsql ou SAP HANA Studio, et stocker les fichiers de sauvegarde sur un volume de disque local. Un point de montage courant pour ce volume de sauvegarde est /hana/backup. Vos stratégies de sauvegarde définissent la période de rétention des données sur le volume. Dès que la sauvegarde est effectuée, une tâche planifiée doit copier les fichiers de sauvegarde dans le stockage Blob Azure à des fins de conservation. Les fichiers de sauvegarde locaux sont conservés pour une récupération rapide.

Sauvegarde Azure offre une solution d’entreprise simple pour les charges de travail exécutées sur des machines virtuelles. Sauvegarde Azure pour SAP HANA offre une intégration complète avec le catalogue de sauvegarde SAP HANA et garantit des récupérations complètes ou ponctuelles, cohérentes au niveau de la base de données. Sauvegarde Azure bénéficie de la certification BackInt par SAP. Consultez également le Forum aux questions sur le service Sauvegarde Azure et la matrice de prise en charge.

Azure NetApp Files prend en charge les sauvegardes basées sur des instantanés. L’intégration à SAP HANA pour les instantanés de cohérence des applications se fait par le biais de l’outil Azure Application Consistent Snapshot (AzAcSnap). Les instantanés créés peuvent être utilisés pour la restauration sur un nouveau volume, pour la restauration du système ou pour la copie de la base de données SAP HANA. Les instantanés créés peuvent être utilisés pour la récupération d’urgence. Ils servent alors de point de restauration avec les journaux SAP HANA enregistrés sur un autre volume NFS.

Supervision

Pour surveiller vos charges de travail sur Azure, Azure Monitor vous permet de collecter, d’analyser et d’agir entièrement sur la télémétrie à partir de vos environnements cloud et locaux.

Pour les applications SAP qui s'exécutent sur SAP HANA et d'autres solutions de base de données majeures, voir Azure Monitor pour les solutions SAP pour savoir comment Azure Monitor pour SAP peut vous aider à gérer la disponibilité et les performances des services SAP.

Sécurité

De nombreuses mesures de sécurité sont utilisées pour protéger la confidentialité, l’intégrité et la disponibilité d’un paysage SAP. Pour sécuriser l’accès utilisateur, par exemple, SAP possède son propre moteur de gestion des utilisateurs (UME) pour contrôler l’autorisation et l’accès en fonction du rôle dans l’application et les bases de données SAP. Pour plus d’informations, consultez SAP HANA Security - An Overview (Sécurité SAP HANA - Vue d'ensemble).

Pour les données au repos, différentes fonctionnalités de chiffrement assurent la sécurité comme suit :

  • En plus de la technologie de chiffrement native SAP HANA, envisagez d’utiliser une solution de chiffrement d’un partenaire qui prend en charge les clés managées par le client.

  • Pour chiffrer les disques des machines virtuelles, vous pouvez utiliser les fonctionnalités décrites dans Présentation du chiffrement des disques.

  • Serveurs de base de données SAP : Utilisez la technologie Transparent Data Encryption du fournisseur SGBD (par exemple, la technologie de chiffrement native SAP HANA) pour sécuriser vos données et vos fichiers journaux, et pour garantir que les sauvegardes seront également chiffrées.

  • Les données du stockage physique Azure (chiffrement côté serveur) sont automatiquement chiffrées au repos à l’aide d’une clé gérée par Azure. Vous pouvez également choisir une clé gérée par le client (CMK) plutôt que la clé gérée par Azure.

  • Pour plus d'informations sur la prise en charge d'Azure Disk Encryption sur des distros, versions et images Linux particulières, voir Azure Disk Encryption for Linux VMs.

Notes

Ne combinez pas la technologie de chiffrement native de SAP HANA avec Azure Disk Encryption ou un mode de chiffrement basé sur l’hôte sur le même volume de stockage. Par ailleurs, les disques de démarrage du système d’exploitation des machines virtuelles Linux ne prennent pas en charge Azure Disk Encryption. Lorsque vous utilisez la technologie de chiffrement native de SAP HANA, combinez-la plutôt avec le mode de chiffrement côté serveur qui est automatiquement activé. N’oubliez pas que l’utilisation de clés gérées par le client peut avoir un impact sur le débit de stockage.

Pour la sécurité réseau, utilisez les groupes de sécurité réseau et le Pare-feu Azure (ou une appliance virtuelle réseau) de la façon suivante :

  • Utilisez des groupes de sécurité réseau pour protéger et contrôler le trafic entre les sous-réseaux et les couches application/base de données. N’appliquez des groupes de sécurité réseau qu’aux sous-réseaux. Les groupes de sécurité réseau appliqués à la fois à la carte réseau et au sous-réseau entraînent très souvent des problèmes au moment de la résolution des problèmes et ne doivent être utilisés que rarement, voire jamais.

  • Utilisez le Pare-feu Azure ou une appliance virtuelle réseau Azure pour inspecter et contrôler le routage du trafic allant du réseau virtuel hub vers le réseau virtuel spoke où se trouvent vos applications SAP, ainsi que pour contrôler votre connectivité Internet sortante.

Pour l’utilisateur et l’autorisation, implémentez le contrôle d’accès en fonction du rôle (RBAC) et les verrous de ressources de la façon suivante :

  • Suivez le principe des privilèges minimum, en utilisant le contrôle RBAC pour attribuer des privilèges d’administrateur aux ressources de niveau IaaS qui hébergent votre solution SAP dans Azure. L'objectif fondamental de la RBAC est la séparation et le contrôle des tâches pour vos utilisateurs/groupes. Le RBAC est conçu pour n’accorder que le volume d’accès aux ressources nécessaires aux utilisateurs pour effectuer leur travail.

  • Utiliser des verrous de ressources pour éviter les modifications accidentelles ou malveillantes. Les verrous de ressources permettent d'empêcher les administrateurs de supprimer ou de modifier les ressources Azure critiques où se trouve votre solution SAP.

Pour plus d’informations sur les recommandations de sécurité, consultez ces articles Microsoft et SAP.

Communautés

Les communautés peuvent répondre aux questions et vous aider à paramétrer un déploiement réussi. Tenez compte des communautés suivantes :

Contributeurs

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

Auteur principal :

Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.

Étapes suivantes

En savoir plus sur les technologies de composants :

Explorer les architectures connexes :