Partager via

Utiliser le redémarrage de la machine virtuelle d’infrastructure Azure pour permettre une plus haute disponibilité d’un système SAP

  • Article

Cette section s’applique à :

Windows logo. Windows et Linux logo. Linux

Si vous décidez de ne pas utiliser des fonctionnalités telles que le clustering de basculement Windows Server (WSFC) ou Pacemaker sur Linux (actuellement prises en charge pour SUSE Linux Enterprise Server [SLES] 12 et versions ultérieures uniquement), le redémarrage de la machine virtuelle Azure est utilisé. Il protège les systèmes SAP contre les temps d’arrêt planifiés ou non de l’infrastructure de serveur physique Azure et de la plateforme Azure sous-jacente globale.

Notes

Le redémarrage de la machine virtuelle Azure protège principalement les machines virtuelles et pas les applications. Bien que le redémarrage de la machine virtuelle n’offre pas une haute disponibilité aux applications SAP, il offre un certain niveau de disponibilité de l’infrastructure. Il offre également un « plus haut niveau de disponibilité » aux systèmes SAP indirectement. Par ailleurs, il n’existe aucun contrat SLA pour la durée du redémarrage d’une machine virtuelle à l’issue d’une panne de l’hôte planifiée ou non, ce qui rend cette méthode de la haute disponibilité inappropriée aux composants critiques d’un système SAP. Par exemple, les composants critiques peuvent être une instance ASCS/SCS ou un système de gestion de base de données (SGBD).

Le stockage est un autre élément important d’infrastructure pour la haute disponibilité. Par exemple, le contrat de niveau de service Stockage Azure assure une disponibilité de 99,9 %. Si vous déployez toutes les machines virtuelles et leurs disques sur un compte Stockage Azure unique, l’indisponibilité potentielle de Stockage Azure entraîne celle de toutes les machines virtuelles placées dans ce compte Stockage Azure et de tous les composants SAP s’exécutant sur ces dernières.

Au lieu de placer toutes les machines virtuelles dans un compte de stockage Azure unique, vous pouvez utiliser des comptes de stockage dédiés pour chaque machine virtuelle. L’utilisation de plusieurs comptes de stockage Azure indépendants vous permet d’augmenter la disponibilité globale des machines virtuelles et des applications SAP.

Les disques managés Azure sont automatiquement placés dans le domaine d’erreur de la machine virtuelle à laquelle ils sont attachés. Si vous placez deux machines virtuelles dans un groupe à haute disponibilité et que vous utilisez des disques managés, la plateforme se charge également de distribuer ces derniers dans différents domaines d’erreur. Si vous envisagez d’utiliser un compte de stockage Premium, nous vous recommandons vivement de recourir à des disques managés.

Voici un exemple de ce à quoi pourrait ressembler une architecture de système SAP NetWeaver utilisant la haute disponibilité d’infrastructure Azure et des comptes de stockage :

Diagram that shows the architecture of an SAP NetWeaver system that uses Azure infrastructure high availability and storage accounts.

Voici un exemple de ce à quoi pourrait ressembler une architecture de système SAP NetWeaver utilisant la haute disponibilité d’infrastructure Azure et des disques managés :

Utilize Azure infrastructure high availability to achieve SAP application “higher availability

Pour les composants SAP critiques, vous avez obtenu jusqu’ici ce qui suit :

  • La haute disponibilité des serveurs d’applications SAP

    Les instances de serveur d’applications SAP sont des composants redondants. Chaque instance de serveur d’applications SAP est déployé sur sa propre machine virtuelle, qui s’exécute dans un domaine d’erreur et de mise à niveau Azure différent. Pour plus d’informations, consultez les sections Domaines d’erreur et Domaines de mise à jour.

    Vous pouvez garantir cette configuration à l’aide de groupes à haute disponibilité Azure. Pour plus d’informations, consultez la section Groupes à haute disponibilité Azure.

    L’indisponibilité planifiée ou non planifiée potentielle d’un domaine de mise à niveau ou d’erreur Azure entraîne l’indisponibilité d’un nombre limité de machines virtuelles avec leurs instances de serveurs d’applications SAP.

    Chaque instance de serveur d’applications SAP est placé dans son propre compte de stockage Azure. L’indisponibilité potentielle d’un seul compte de stockage Azure entraîne celle d’une seule machine virtuelle avec son instance de serveur d’applications SAP. Toutefois, sachez qu’un abonnement Azure est limité quant au nombre de comptes de stockage Azure. Pour garantir le démarrage automatique d’une instance ASCS/SCS après le redémarrage de la machine virtuelle, définissez le paramètre de démarrage automatique dans le profil de démarrage de l’instance ASCS/SCS.

    Pour plus d’informations, consultez Haute disponibilité pour les serveurs d’applications SAP.

    Même si vous utilisez des disques managés, ils sont stockés dans un compte de stockage Azure et peuvent être indisponibles en cas de panne de stockage.

  • Plus haute disponibilité des instances ASCS/SCS SAP

    Dans ce scénario, nous utilisons le redémarrage de la machine virtuelle Azure afin de protéger la machine virtuelle avec l’instance ASCS/SCS SAP installée. En cas d’interruption planifiée ou non de serveurs Azure, les machines virtuelles sont redémarrées sur un autre serveur disponible. Comme mentionné précédemment, le redémarrage de la machine virtuelle Azure protège les machines virtuelles mais pas les applications, qui sont dans ce cas l’instance ASCS/SCS. Ce redémarrage permet d’obtenir indirectement une « plus haute disponibilité » de l’instance ASCS/SCS SAP.

    Pour garantir un démarrage automatique de l’instance ASCS/SCS après le redémarrage de la machine virtuelle, définissez le paramètre de démarrage automatique dans le profil de démarrage de l’instance ASCS/SCS. Ce paramètre signifie que l’instance ASCS/SCS en tant que point de défaillance unique (SPOF) s’exécutant sur une machine virtuelle unique détermine la disponibilité de l’ensemble du paysage SAP.

  • Plus haute disponibilité du serveur du SGBD (système de gestion de base de données)

    Comme dans le cas d’utilisation de l’instance ASCS/SCS SAP précédent, vous utilisez le redémarrage de la machine virtuelle pour protéger la machine virtuelle sur laquelle est installé le logiciel du SGBD (système de gestion de base de données). Ce redémarrage vous permet également d’obtenir une « plus haute disponibilité » du logiciel du SGBD.

    Un SGBD (système de gestion de base de données) s’exécutant sur une seule machine virtuelle est également un point de défaillance unique, qui est le facteur déterminant de disponibilité de l’ensemble du paysage SAP.

Utilisation du démarrage automatique pour les instances SAP

SAP propose un paramètre qui vous permet de démarrer automatiquement des instances SAP immédiatement après le démarrage du système d’exploitation au sein de la machine virtuelle. Les instructions sont documentées dans l’article de base de connaissances SAP 1909114. Toutefois, SAP ne recommande plus d’utiliser le paramètre, car il ne permet pas de contrôler l’ordre des redémarrages d’instances si plusieurs machines virtuelles sont concernées ou si plusieurs instances sont en cours d’exécution par machine virtuelle.

Dans l’hypothèse d’un scénario Azure classique d’une seule instance de serveur d’applications SAP sur une machine virtuelle et dans le cas du redémarrage éventuel d’une seule machine virtuelle, le démarrage automatique n’est pas critique. Mais vous pouvez l’activer en ajoutant le paramètre suivant dans le profil de démarrage de l’instance SAP Advanced Business Application Programming (ABAP) ou Java :

Autostart = 1

Notes

Le paramètre de démarrage automatique comporte aussi quelques défauts. Plus précisément, il déclenche le démarrage d’une instance SAP ABAP ou Java au démarrage du service Windows ou Linux associé de l’instance. Cette séquence se produit lorsque le système d’exploitation démarre. Toutefois, les redémarrages des services SAP sont également courants pour la fonctionnalité de gestion du cycle de vie du logiciel SAP, telle que Software Update Manager (SUM) ou d’autres mises à jour et mises à niveau. Ces fonctionnalités n’attendent pas le redémarrage automatique d’une instance. Par conséquent, le paramètre de démarrage automatique doit être désactivé avant d’exécuter ces tâches. Le paramètre de démarrage automatique ne doit pas être utilisé pour les instances SAP en cluster, comme ASCS/SCS/CI.

Pour plus d’informations sur le démarrage automatique pour les instances SAP, consultez les articles suivants :

Étapes suivantes

Pour plus d’informations sur la haute disponibilité complète de l’application SAP NetWeaver, consultez Haute disponibilité de l’application SAP sur Azure IaaS.