Disponibilité de SAP HANA au sein d’une région Azure

Cet article décrit plusieurs scénarios de disponibilité pour SAP HANA dans une région Azure. Azure dispose de plusieurs régions, réparties à travers le monde. Pour obtenir la liste des régions Azure, voir Régions Azure. Pour le déploiement de SAP HANA sur des machines virtuelles au sein d’une région Azure, Microsoft offre le déploiement d’une machine virtuelle unique avec une instance HANA. Pour une disponibilité accrue, vous pouvez déployer deux machines virtuelles avec deux instances HANA à l’aide d’un groupe identique flexible avec FD=1, des zones de disponibilité ou un groupe à haute disponibilité qui utilise la réplication du système HANA pour la disponibilité.

Les régions Azure qui fournissent Zones de disponibilité se composent de plusieurs centres de données, chacun avec sa propre source d’alimentation, son refroidissement et son infrastructure réseau. L’objectif d’offrir différentes zones dans une seule région Azure consiste à permettre le déploiement d’applications sur deux ou trois Zones de disponibilité disponibles. En distribuant votre déploiement d’application entre les zones, tout problème de mise en réseau ou d’alimentation affectant une infrastructure de zone de disponibilité Azure spécifique ne perturberait pas entièrement les fonctionnalités de votre application dans la région Azure. Même s’il peut y avoir une capacité réduite, par exemple la perte potentielle de machines virtuelles dans une zone, les machines virtuelles des zones restantes continuent de fonctionner sans interruption. Pour configurer deux instances HANA dans des machines virtuelles distinctes couvrant différentes zones, vous avez la possibilité de déployer des machines virtuelles à l’aide du groupe identique flexible avec l’option de déploiement FD=1 ou des zones de disponibilité.

Pour une disponibilité accrue au sein d’une région, il est recommandé de déployer deux machines virtuelles avec deux instances HANA à l’aide d’un groupe à haute disponibilité. Un groupe à haute disponibilité Azure est une fonctionnalité de regroupement logique qui garantit que les ressources de machine virtuelle configurées dans le groupe à haute disponibilité sont isolées les unes des autres lorsqu’elles sont déployées dans un centre de données Azure. Azure veille à ce que les machines virtuelles que vous placez dans un groupe à haute disponibilité s’exécutent sur plusieurs serveurs physiques, racks de calcul, unités de stockage et commutateurs réseau. Dans certaines documentations Azure, cette configuration est considérée comme des placements dans différents Mise à jour et domaines d’erreur. En règle générale, ces placements se trouvent dans un centre de données Azure. En supposant que les problèmes de source d’alimentation et de réseau affectent le centre de données que vous déployez, toute votre capacité dans une région Azure est affectée.

Le placement des centres de données représentant les zones de disponibilité Azure est un compromis entre une latence réseau entre des services déployés dans différentes zones et une distance spécifique entre des centres de données. Idéalement, les catastrophes naturelles n’affectent pas l’alimentation, le réseau et l’infrastructure de toutes vos zones de disponibilité dans cette région. Toutefois, comme nous l’avons déjà vu avec des catastrophes naturelles d’envergure, les zones de disponibilité peuvent ne pas fournir autant de disponibilité que vous le souhaitez au sein d’une région. Pensez à l’ouragan Maria qui a touché l’ile de Porto Rico le 20 septembre 2017. L’ouragan a entrainé une coupure de courant de la quasi-totalité de cette ile de 145 kilomètres.

Scénario de machine virtuelle unique

Dans un scénario de machine virtuelle unique, vous créez une machine virtuelle Azure pour l’instance SAP HANA. Vous utilisez le stockage Premium Azure pour héberger le disque du système d’exploitation et tous vos disques de données. Le contrat SLA de disponibilité de 99,9 % d’Azure et les contrats SLA d’autres composants Azure vous suffisent à réaliser vos contrats SLA de disponibilité pour vos clients. Dans ce scénario, vous n’avez pas besoin d’utiliser un groupe à haute disponibilité Azure pour les machines virtuelles qui exécutent la couche SGBD. Dans ce scénario, vous vous appuyez sur deux fonctionnalités :

• Redémarrage automatique de machine virtuelle Azure (également appelé réparation du service Azure)
• Redémarrage automatique DE SAP HANA

Le redémarrage automatique de machine virtuelle Azure, ou Service Healing, est une fonctionnalité Azure qui fonctionne sur deux niveaux :

• L’hôte serveur Azure vérifie l’intégrité d’une machine virtuelle hébergée sur le serveur hôte.
• Le contrôleur de structure Azure surveille l’intégrité et la disponibilité du serveur hôte.

Une fonctionnalité d’analyse de l’intégrité surveille l’intégrité de chaque machine virtuelle hébergée sur un serveur hôte Azure. Si une machine virtuelle passe en état défaillant, un redémarrage peut être initié par l’agent hôte Azure qui vérifie l’intégrité de la machine virtuelle. Le contrôleur de structure vérifie l’intégrité de l’hôte en vérifiant les nombreux paramètres qui peuvent indiquer des problèmes avec le matériel hôte. Il vérifie également l’accessibilité de l’hôte via le réseau. Une indication de problèmes avec l’hôte peut entraîner les événements suivants :

• Si l’hôte signale un état défaillant, un redémarrage de l’hôte et des machines virtuelles exécutées sur l’hôte est déclenché.
• Si l’hôte n’est pas dans un état sain après un redémarrage réussi, un redéploiement des machines virtuelles qui se trouvaient à l’origine sur le nœud devenu non sain sur un serveur hôte sain est lancé. Dans ce cas, l’hôte d’origine est marqué comme défaillant. Il ne sera pas utilisé pour des déploiements ultérieurs jusqu'à ce qu’il soit effacé ou remplacé.
• Si l’hôte non sain rencontre des problèmes pendant le processus de redémarrage, un redémarrage immédiat des machines virtuelles sur un hôte sain est déclenché.

Avec la surveillance d’hôte et de machine virtuelle fournie par Azure, les machines virtuelles Azure qui subissent des problèmes d’hôte sont automatiquement redémarrées sur un hôte Azure intègre.

Important

La réparation des services Azure ne redémarre pas les machines virtuelles Linux où le système d’exploitation invité est affecté par une alerte sur le noyau. Les paramètres par défaut des versions de Linux couramment utilisées n’autorisent pas redémarrer automatiquement les machines virtuelles ou le serveur contenant un noyau Linux en alerte. Le paramétrage par défaut prévoit au contraire de maintenir le système d’exploitation dans un état d’alerte du noyau pour pouvoir y attacher un débogueur du noyau et procéder à des analyses. Azure respecte ce comportement en ne redémarrant pas automatiquement une machine virtuelle avec le système d’exploitation invité dans un tel état. Nous partons de l’hypothèse que de tels événements sont extrêmement rares. Vous pouvez remplacer le comportement par défaut pour permettre un redémarrage de la machine virtuelle. Pour modifier le comportement par défaut, activez le paramètre « kernel.panic » dans /etc/sysctl.conf. La durée pour ce paramètre est en secondes. Les valeurs recommandées courantes sont d’attendre 20 à 30 secondes avant de déclencher le redémarrage via ce paramètre. Pour plus d'informations, consultez sysctl.conf.

La deuxième fonctionnalité sur laquelle vous pouvez vous appuyer dans un tel scénario est le redémarrage automatique du service HANA qui s’exécute dans une machine virtuelle après qu’elle ait été redémarrée. Vous pouvez configurer le redémarrage automatique du service HANA via les services de surveillance des différents services HANA.

Vous pouvez améliorer ce scénario de machine virtuelle unique en ajoutant un nœud de basculement froid à une configuration SAP HANA. Dans la documentation SAP HANA, cette configuration est appelée autofailover hôte. Cette configuration peut avoir un sens dans une situation de déploiement local où le matériel du serveur est limité et que vous dédiez un nœud à serveur unique en tant que nœud d’autofailover hôte pour un ensemble d’hôtes de production. Toutefois, dans Azure, où l’infrastructure sous-jacente d’Azure fournit un serveur cible sain pour un redémarrage réussi de machine virtuelle, il n’est pas judicieux de déployer l’autofailover de l’hôte SAP HANA. En raison de la réparation du service Azure, il n’existe aucune architecture de référence qui prévoit un nœud de secours pour l’autofailover de l’hôte HANA.

Cas spécial des configurations de scale-out SAP HANA dans Azure

Les architectures de haute disponibilité basées sur le nœud de secours ou la réplication du système HANA sont disponibles dans les documents suivants. Dans les cas où les nœuds de secours ou la haute disponibilité de la réplication du système HANA ne sont pas utilisés dans les configurations de scale-out SAP HANA, vous pouvez dépendre des fonctionnalités de réparation du service des machines virtuelles Azure et du redémarrage automatique de l’instance SAP HANA une fois la machine virtuelle opérationnelle de nouveau.

• RedHat Enterprise Linux
  • Haute disponibilité du système de scale-out SAP HANA avec HSR sur RHEL.
  • Déployez un système de scale-out SAP HANA avec un nœud de secours sur des machines virtuelles Azure à l’aide d’Azure NetApp Files sur RHEL.
• SUSE Linux Enterprise Server
  • Haute disponibilité du système de scale-out SAP HANA avec HSR sur SLES.
  • Déployez un système de scale-out SAP HANA avec nœud de secours sur des machines virtuelles Azure à l’aide d’Azure NetApp Files sur SLES.

Scénarios de disponibilité pour deux machines virtuelles différentes

Pour garantir la disponibilité du système HANA dans une région spécifique, vous avez la possibilité de configurer deux machines virtuelles dans les zones de disponibilité de la région ou dans la région. Pour atteindre cet objectif, vous pouvez configurer les machines virtuelles à l’aide d’un groupe identique flexible, de zones de disponibilité ou d’une option de déploiement de groupe à haute disponibilité. L’installation de base dans Azure ressemble à ceci :

Pour illustrer les différents scénarios de disponibilité SAP HANA, quelques-unes des couches du diagramme sont omises. Le diagramme montre uniquement les couches qui décrivent les machines virtuelles, les hôtes, les groupes à haute disponibilité et les régions Azure. Des instances de Azure Virtual Network, des groupes de ressources et des abonnements ne jouent pas un rôle dans les scénarios décrits dans cette section.

Répliquer des sauvegardes vers une seconde machine virtuelle

L’une des configurations les plus rudimentaires consiste à utiliser des sauvegardes. En particulier, vous pouvez avoir des sauvegardes des journaux des transactions depuis une machine virtuelle vers une autre machine virtuelle Azure. Vous pouvez choisir le type de stockage Azure. Dans cette configuration, vous êtes responsable du script de la copie des sauvegardes planifiées effectuées sur la première machine virtuelle sur la deuxième machine virtuelle. Si vous devez utiliser les instances de la seconde machine virtuelle, vous devez restaurer les sauvegardes complètes différentielles/incrémentielles et de fichier journal à l’endroit requis.

L’architecture ressemble à ceci :

Cette configuration n’est pas bien adaptée à l’atteinte d’un excellent objectif de point de récupération (RPO) et d’un objectif de temps de récupération (RTO). Les temps de RTO, plus particulièrement, souffriraient en raison du besoin de restaurer entièrement toute la base de données à l’aide des sauvegardes copiées. Toutefois, cette configuration est utile pour récupérer d’une suppression de données involontaire sur les instances principales. Avec cette configuration, vous êtes en mesure de restaurer à un certain point dans le temps, d’extraire les données et d’importer les données supprimées dans votre instance principale en tout temps. Ainsi, il est peut-être logique d’utiliser une méthode de copie de sauvegarde avec d’autres fonctionnalités de haute disponibilité.

Pendant la copie des sauvegardes, vous serez peut-être en mesure d’utiliser une machine virtuelle plus petite autre que la machine virtuelle principale qui exécute l’instance SAP HANA. Gardez à l’esprit que vous pouvez attacher un plus petit nombre de disques durs virtuels sur les machines virtuelles plus petites. Pour plus d’information sur les limites des types de machines virtuelles individuelles, consultez Tailles des machines virtuelles Linux dans Azure.

Réplication de système SAP HANA sans basculement automatique

Les scénarios décrits dans cette section utilisent la réplication du système SAP HANA. Pour obtenir la documentation de SAP, consultez Réplication du système. Les scénarios sans basculement automatique ne sont pas courants pour les configurations au sein d’une région Azure. Une configuration sans basculement automatique, même si elle vous évite de configurer Pacemaker, vous oblige de procéder à une surveillance et un basculement manuels. Cela prend du temps et de l’énergie, c’est pourquoi la plupart des clients utilisent plutôt la réparation des services Azure. Il existe quelques cas extrêmes où cette configuration peut être utile en termes de scénarios d’échec. Ou, dans certains cas, un client peut souhaiter plus d’efficacité.

Réplication de système SAP HANA sans basculement automatique ni données pré-chargées

Dans ce scénario, vous utilisez la réplication du système SAP HANA pour déplacer des données de façon synchrone pour atteindre un RPO à 0. En revanche, vous disposez d’un RTO suffisamment long pour ne pas avoir besoin du basculement ou du préchargement des données dans le cache d’instance HANA. Dans ce cas, il est possible de réaliser des économies plus importantes dans votre configuration en effectuant les actions suivantes :

• Exécuter une autre instance SAP HANA dans la deuxième machine virtuelle. L’instance SAP HANA dans la deuxième machine virtuelle utilise une grande partie de la mémoire de la machine virtuelle. Dans le cas d’un basculement vers la deuxième machine virtuelle, vous devez arrêter l’instance SAP HANA en cours d’exécution qui charge les données dans la deuxième machine virtuelle, afin que les données répliquées puissent être chargées dans le cache de l’instance HANA ciblée dans la deuxième machine virtuelle.
• Utilisez une taille de machine virtuelle réduite pour la deuxième machine virtuelle. Si un basculement se produit, vous disposez d’une étape supplémentaire avant le basculement manuel. Dans cette étape, vous redimensionnez la machine virtuelle à la taille de la machine virtuelle source.

Le scénario ressemble à ceci :

Remarque

Même si vous n’utilisez pas le préchargement de données dans la cible de réplication du système HANA, vous avez besoin d’au moins 64 Go de mémoire. Vous avez également besoin de suffisamment de mémoire en plus des 64 Go pour conserver les données de stockage de lignes dans la mémoire de l’instance cible.

Réplication de système SAP HANA sans basculement automatique et avec des données pré-chargées

Dans ce scénario, les données répliquées vers l’instance HANA dans la deuxième machine virtuelle sont préchargées. Cela élimine les deux avantages de l’absence de préchargement des données. Dans ce cas, vous ne pouvez pas exécuter d’autres systèmes SAP HANA sur la deuxième machine virtuelle, Vous ne pouvez pas utiliser une taille de machine virtuelle réduite. Par conséquent, les clients implémentent rarement ce scénario.

Réplication de système SAP HANA avec basculement automatique

Dans la configuration de disponibilité standard et la plus courante au sein d’une région Azure, deux machines virtuelles Azure exécutant Linux avec des packages haute disponibilité ont un cluster de basculement défini. Le cluster Linux haute disponibilité est basé sur l’infrastructure à l’aide Pacemakerde SLES ou RHEL avec unfencing device SLES ou RHEL comme exemple.

Côté SAP HANA, le mode de réplication utilisé est synchronisé et un basculement automatique est configuré. Dans la deuxième machine virtuelle, l’instance SAP HANA agit comme un nœud de serveur de secours. Le nœud de serveur de secours reçoit un flux de données synchrone d’enregistrements de modification depuis l’instance de SAP HANA principale. Tandis que les transactions sont acceptées par l’application au nœud HANA principal, ce dernier attend la confirmation de réception de l’enregistrement de la part du nœud SAP HANA secondaire avant de confirmer la réception à l’application. SAP HANA dispose de deux modes de réplication synchrone différents. Pour en savoir plus et pour connaître les différences entre les deux modes de réplication synchrone, consultez l’article SAP Modes de réplication pour la réplication de système SAP HANA.

La configuration générale ressemble à ceci :

Vous pouvez choisir cette solution, car elle vous permet d’obtenir un RPO=0 et un RTO faible. Configurez la connectivité du client SAP HANA de façon à ce que les clients SAP HANA utilisent l’adresse IP virtuelle pour se connecter à la configuration de réplication de système HANA. Cette configuration évite de reconfigurer l’application en cas de basculement sur le nœud secondaire. Dans ce scénario, les références SKU de machine virtuelle Azure pour les machines virtuelles principales et secondaires doivent être identiques.

Étapes suivantes

Pour obtenir des instructions sur la mise en place de ces configurations dans Azure, consultez :

• Installer la réplication de système SAP HANA sur des machines virtuelles Azure
• Haute disponibilité de SAP HANA sur des machines virtuelles Azure

Pour plus d’informations sur la disponibilité SAP HANA dans l’ensemble des régions Azure, consultez :

• Disponibilité de SAP HANA dans l’ensemble des régions Azure