Connectivité de point de terminaison public pour les machines virtuelles avec Azure Standard Load Balancer dans les scénarios de haute disponibilité SAP

  • Article

L’objectif de cet article est de décrire les configurations qui permettront une connectivité sortante vers les points de terminaison publics. Les configurations sont principalement dans le contexte de la haute disponibilité avec Pacemaker pour SUSE/RHEL.

Si vous utilisez Pacemaker avec l’agent d’isolation Azure dans votre solution de haute disponibilité, les machines virtuelles doivent disposer d’une connectivité sortante à l’API de gestion Azure. L’article présente plusieurs options pour vous permettre de sélectionner l’option qui convient le mieux à votre scénario.

Vue d’ensemble

Lors de l’implémentation de la haute disponibilité pour les solutions SAP via le clustering, l’un des composants nécessaires est Azure Load Balancer. Azure propose deux références SKU d’équilibrage de charge : Standard et De base.

L’équilibrage de charge Azure Standard offre des avantages par rapport à celui De base. Par exemple, il fonctionne sur les zones de disponibilité Azure, il offre de meilleures fonctions de surveillance et de journalisation pour faciliter la résolution des problèmes, et une latence réduite. La fonctionnalité « Ports haute disponibilité » couvre tous les ports, autrement dit, il n’est plus nécessaire de répertorier tous les ports individuels.

Il existe quelques différences importantes entre la référence De base et la référence Standard d’Azure Load Balancer. L’une d’entre elles est la gestion du trafic sortant vers le point de terminaison public. Pour en savoir plus sur la comparaison entre les équilibrages de charge Standard et De base, consultez Comparaison des références SKU d’équilibrage de charge.

Lorsque des machines virtuelles sans adresse IP publique sont placées dans le pool principal d’Azure Standard Load Balancer interne (aucune adresse IP publique), il n’y a pas de connectivité sortante aux points de terminaison publics, sauf si une configuration supplémentaire est effectuée.

Si une machine virtuelle est affectée à une adresse IP publique ou que celle-ci se trouve dans le pool principal d’un équilibreur de charge avec une adresse IP publique, elle aura une connectivité sortante aux points de terminaison publics.

Les systèmes SAP contiennent souvent des données d’entreprise sensibles. Il est rarement acceptable que des machines virtuelles hébergeant des systèmes SAP soient accessibles via des adresses IP publiques. Dans le même temps, il existe des scénarios qui nécessitent une connectivité sortante entre la machine virtuelle et les points de terminaison publics.

Voici quelques exemples de scénarios nécessitant l’accès au point de terminaison public Azure :

  • Azure Fence Agent requiert l’accès à management.azure.com et à login.microsoftonline.com
  • Azure Backup
  • Azure Site Recovery
  • Utilisation d’un référentiel public pour la mise à jour corrective du système d’exploitation
  • Le trafic de données de l’application SAP peut nécessiter une connectivité sortante vers le point de terminaison public

Si votre déploiement SAP ne nécessite pas de connectivité sortante vers les points de terminaison publics, vous n’avez pas besoin d’implémenter la configuration supplémentaire. Il suffit de créer une référence SKU Azure Load Balancer Standard interne pour votre scénario de haute disponibilité, en supposant qu’il n’y a pas non plus besoin de connectivité entrante à partir de points de terminaison publics.

Notes

Lorsque des machines virtuelles sans adresse IP publique sont placées dans le pool principal d’Azure Standard Load Balancer interne (aucune adresse IP publique), il n’y a pas de connectivité Internet sortante, sauf si une configuration supplémentaire est effectuée pour autoriser le routage vers des points de terminaison publics.
Si les machines virtuelles ont des adresses IP publiques ou se trouvent déjà dans le pool principal d’Azure Load Balancer avec une adresse IP publique, la machine virtuelle dispose déjà d’une connectivité sortante aux points de terminaison publics.

Lisez tout d’abord les documents suivants :

Option 1 : Un Azure Standard Load Balancer supplémentaire pour les connexions sortantes vers Internet

Une option pour obtenir une connectivité sortante aux points de terminaison publics, et ce sans autoriser la connectivité entrante à la machine virtuelle à partir du point de terminaison public, consiste à créer un second équilibreur de charge avec une adresse IP publique, à ajouter les machines virtuelles au pool principal du deuxième équilibreur de charge et à définir uniquement les règles sortantes.
Utilisez les groupes de sécurité réseau pour contrôler les points de terminaison publics, qui sont accessibles pour les appels sortants à partir de la machine virtuelle.
Pour plus d’informations, consultez le scénario 2 dans le document Connexions sortantes.
La configuration ressemblerait à ceci :

Contrôler la connectivité aux points de terminaison publics avec les groupes de sécurité réseau

Points importants à prendre en compte

  • Vous pouvez utiliser un Load Balancer public supplémentaire pour plusieurs machines virtuelles dans le même sous-réseau pour obtenir une connectivité sortante vers le point de terminaison public et optimiser les coûts
  • Utilisez les groupes de sécurité réseau pour contrôler les points de terminaison publics accessibles pour les machines virtuelles. Vous pouvez affecter le groupe de sécurité réseau au sous-réseau ou à chaque machine virtuelle. Dans la mesure du possible, utilisez des balises de service pour réduire la complexité des règles de sécurité.
  • L’équilibrage de charge Standard Azure avec une adresse IP publique et des règles de trafic sortant permet l’accès direct au point de terminaison public. Si vous avez des exigences de sécurité d’entreprise pour que tout le trafic sortant passe par une solution d’entreprise centralisée pour audit et journalisation, vous ne pourrez peut-être pas répondre aux exigences avec ce scénario.

Conseil

Dans la mesure du possible, utilisez des balises de service pour réduire la complexité du groupe de sécurité réseau.

Étapes du déploiement

  1. Créer un équilibreur de charge

    1. Dans le portail Azure, cliquez sur Toutes les ressources, Ajouter, puis sur Équilibreur de charge
    2. Cliquez sur Créer
    3. Nom de l’équilibreur de charge MyPublicILB
    4. Sélectionnez Public en tant que type, Standard comme référence SKU
    5. Sélectionnez Créer une adresse IP publique et spécifiez en tant que nom MyPublicILBFrondEndIP
    6. Sélectionnez Redondant interzone pour Zone de disponibilité
    7. Cliquez sur Vérifier et créer, puis sur Créer

  2. Créez un pool principal MyBackendPoolOfPublicILB et ajoutez les machines virtuelles.

    1. Sélectionnez le réseau virtuel
    2. Sélectionnez les machines virtuelles et leurs adresses IP et ajoutez-les au pool principal

  3. Créez des règles de trafic sortant.

     az network lb outbound-rule create --address-pool MyBackendPoolOfPublicILB --frontend-ip-configs MyPublicILBFrondEndIP --idle-timeout 30 --lb-name MyPublicILB --name MyOutBoundRules  --outbound-ports 10000 --enable-tcp-reset true --protocol All --resource-group MyResourceGroup

  4. Créez des règles de groupe de sécurité réseau pour restreindre l’accès à des points de terminaison publics spécifiques. S’il existe un groupe de sécurité réseau, vous pouvez l’ajuster. L’exemple ci-dessous montre comment activer l’accès à l’API de gestion Azure :

    1. Accéder au groupe de sécurité réseau
    2. Cliquez sur Règles de sécurité de trafic entrant
    3. Ajoutez une règle pour Refuser tout accès sortant à Internet.
    4. Ajoutez une règle à Autoriser l’accès à AzureCloud, avec une priorité inférieure à la priorité de la règle pour refuser tout accès à Internet.

    Les règles de sécurité de trafic sortant ressembleraient alors à ceci :

    Connexion sortante avec le deuxième équilibreur de charge avec une adresse IP publique

    Pour plus d’informations sur les groupes de sécurité réseau Azure, consultez Groupes de sécurité.

Option n°2 : Pare-feu Azure pour les connexions sortantes vers Internet

Une autre option pour obtenir une connectivité sortante aux points de terminaison publics, sans autoriser la connectivité entrante à la machine virtuelle à partir de points de terminaison publics, est le pare-feu Azure. Le pare-feu Azure est un service géré avec une haute disponibilité intégrée qui peut s’étendre sur plusieurs zones de disponibilité.
Vous devez également déployer un Itinéraire défini par l’utilisateur, associé au sous-réseau dans lequel les machines virtuelles et l’équilibreur de charge Azure sont déployés, pointant vers le pare-feu Azure, pour acheminer le trafic via le pare-feu Azure.
Pour plus d’informations sur le déploiement du pare-feu Azure, consultez Déployer et configurer un pare-feu Azure.

L’architecture ressemblerait à :

Connexion sortante avec le pare-feu Azure

Points importants à prendre en compte

  • Le pare-feu Azure est un service cloud natif, avec une haute disponibilité intégrée et prenant en charge le déploiement zonal.
  • Nécessite un sous-réseau supplémentaire qui doit être nommé AzureFirewallSubnet.
  • Si vous transférez des jeux de données volumineux sortants du réseau virtuel, sur lequel se trouvent les machines virtuelles SAP, vers une machine virtuelle dans un autre réseau virtuel ou vers un point de terminaison public, il pourrait ne pas s’agir d’une solution économique. Par exemple en cas de copie de sauvegardes volumineuses sur des réseaux virtuels. Pour plus de détails, consultez la tarification du pare-feu Azure.
  • Si la solution de pare-feu d’entreprise n’est pas un pare-feu Azure et que vous avez des exigences de sécurité pour que tout le trafic sortant passe par une solution d’entreprise centralisée, cette solution peut ne pas être pratique.

Conseil

Dans la mesure du possible, utilisez des balises de service pour réduire la complexité des règles du pare-feu Azure.

Étapes du déploiement

  1. Les étapes de déploiement supposent que vous avez déjà défini un réseau virtuel et un sous-réseau pour vos machines virtuelles.

  2. Créez un sous-réseau AzureFirewallSubnet dans le même réseau virtuel, où les machines virtuelles et les Standard Load Balancer sont déployés.

    1. Dans le portail Azure, accédez au réseau virtuel : Cliquez sur Toutes les ressources, recherchez le réseau virtuel, cliquez sur le réseau virtuel, puis sur Sous-réseaux.
    2. Cliquez sur Ajouter un sous-réseau. Entrez AzureFirewallSubnet comme nom. Entrez la plage d’adresses appropriée. Enregistrez.

  3. Créez un pare-feu Azure.

    1. Dans le portail Azure, sélectionnez Toutes les ressources, cliquez sur Ajouter, Pare-feu, Créer. Sélectionnez Groupe de ressources (sélectionnez le même groupe de ressources que celui sur lequel se trouve le réseau virtuel).
    2. Entrez le nom de la ressource de pare-feu Azure. Par exemple, MyAzureFirewall.
    3. Sélectionnez Région et sélectionnez au moins deux zones de disponibilité, alignées avec les zones de disponibilité dans lesquelles vos machines virtuelles sont déployées.
    4. Sélectionnez votre réseau virtuel, dans lequel les machines virtuelles SAP et l’équilibreur de charge standard Azure sont déployés.
    5. Adresse IP publique : Cliquez sur Créer et entrez un nom. Par exemple MyFirewallPublicIP.

  4. Créez une règle de pare-feu Azure pour autoriser la connectivité sortante vers les points de terminaison publics spécifiés. L’exemple montre comment autoriser l’accès au point de terminaison public de l’API de gestion Azure.

    1. Sélectionnez Règles, Collection de règles de réseau, puis cliquez sur Ajouter une collection de règles de réseau.
    2. Nom : MyOutboundRule, entrez la Priorité, et sélectionnez l’action Autoriser.
    3. Service : Nom ToAzureAPI. Protocole : Sélectionnez N’importe laquelle. Adresse source : entrez la plage de votre sous-réseau, où les machines virtuelles et les Standard Load Balancer sont déployés pour l’instance : 11.97.0.0/24. Ports de destination : saisissez *.
    4. Enregistrer
    5. Comme vous êtes toujours positionné sur le pare-feu Azure, sélectionnez Vue d’ensemble. Notez l’adresse IP privée du pare-feu Azure.

  5. Créer un itinéraire vers le pare-feu Azure

    1. Dans le portail Azure sélectionnez Toutes les ressources, puis cliquez sur Ajouter, Table de routage, Créer.
    2. Entrez le nom MyRouteTable, sélectionnez l’abonnement, le groupe de ressources et l’emplacement (correspondant à l’emplacement de votre réseau virtuel et de votre pare-feu).
    3. Enregistrer

    La règle de pare-feu devrait ressembler à ceci : Diagramme montrant à quoi ressemble le pare-feu.

  6. Créez un itinéraire défini par l’utilisateur à partir du sous-réseau de vos machines virtuelles vers l’adresse IP privée de MyAzureFirewall.

    1. Comme vous êtes positionné sur la table de routage, cliquez sur Itinéraires. Sélectionnez Ajouter.
    2. Nom de l’itinéraire : ToMyAzureFirewall, préfixe d’adresse : 0.0.0.0/0. Type de tronçon suivant : Sélectionnez Appliance virtuelle. Adresse du tronçon suivant : entrez l’adresse IP privée du pare-feu que vous avez configuré : 11.97.1.4.
    3. Enregistrer

Option 3 : Utilisation du proxy pour les appels de Pacemaker à l’API de gestion Azure

Vous pouvez utiliser le proxy pour autoriser les appels de Pacemaker au point de terminaison public de l’API de gestion Azure.

Points importants à prendre en compte

  • Si un proxy d’entreprise est déjà en place, vous pouvez acheminer les appels sortants vers des points de terminaison publics. Les appels sortants vers des points de terminaison publics passent par le point de contrôle de l’entreprise.
  • Assurez-vous que la configuration du proxy autorise la connectivité sortante vers l’API de gestion Azure : https://management.azure.com et https://login.microsoftonline.com
  • Vérifiez qu’il existe un itinéraire entre les machines virtuelles et le proxy
  • Le proxy gère uniquement les appels HTTP/HTTPS. S’il est nécessaire d’effectuer des appels sortants vers le point de terminaison public sur différents protocoles (par exemple, RFC), une solution alternative sera nécessaire
  • La solution de proxy doit être hautement disponible, afin d’éviter l’instabilité dans le cluster Pacemaker
  • En fonction de l’emplacement du proxy, cela peut ajouter de la latence supplémentaire dans les appels de l’agent d’isolation Azure à l’API de gestion Azure. Si votre proxy d’entreprise est toujours sur site alors que votre cluster Pacemaker est dans Azure, mesurez la latence et déterminez si cette solution est adaptée à vos besoins
  • Si le proxy d’entreprise n’est pas déjà en place, nous ne recommandons pas cette option, car le client aurait des coûts et une complexité supplémentaires. Néanmoins, si vous décidez de déployer une solution proxy supplémentaire, afin d’autoriser la connectivité sortante de Pacemaker à l’API publique de gestion Azure, vérifiez que le proxy est hautement disponible et que la latence entre les machines virtuelles et le proxy est faible.

Configuration Pacemaker avec proxy

Il existe de nombreuses options de proxy disponibles dans le secteur. Les instructions pas à pas pour le déploiement du proxy n’entrent pas dans le cadre de ce document. Dans l’exemple ci-dessous, nous supposons que votre proxy répond à MyProxyService et qu’il écoute le port MyProxyPort.
Pour autoriser Pacemaker à communiquer avec l’API de gestion Azure, procédez comme suit sur tous les nœuds de cluster :

  1. Modifiez le fichier de configuration de Pacemaker /etc/sysconfig/pacemaker et ajoutez les lignes suivantes (tous les nœuds de cluster) :

    sudo vi /etc/sysconfig/pacemaker
# Add the following lines
http_proxy=http://MyProxyService:MyProxyPort
https_proxy=http://MyProxyService:MyProxyPort

  2. Redémarrez le service Pacemaker sur tous les nœuds de cluster.

  • SUSE

    # Place the cluster in maintenance mode
sudo crm configure property maintenance-mode=true
#Restart on all nodes
sudo systemctl restart pacemaker
# Take the cluster out of maintenance mode
sudo crm configure property maintenance-mode=false

  • Red Hat

    # Place the cluster in maintenance mode
sudo pcs property set maintenance-mode=true
#Restart on all nodes
sudo systemctl restart pacemaker
# Take the cluster out of maintenance mode
sudo pcs property set maintenance-mode=false

Autres options

Si le trafic sortant est routé via un proxy de pare-feu tiers basé sur une URL :

  • Si vous utilisez l’agent de clôture Azure, assurez-vous que la configuration du pare-feu autorise la connectivité sortante vers l’API de gestion Azure : https://management.azure.com et https://login.microsoftonline.com.
  • Si vous utilisez l’infrastructure de mise à jour du cloud public Azure de SUSE pour appliquer les mises à jour et les correctifs, consultez Infrastructure de mise à jour de cloud public Azure 101

Étapes suivantes