Partager via


Mise en réseau

Lorsque vous créez et gérez des clusters Azure Service Fabric, vous fournissez une connectivité réseau pour vos nœuds et vos applications. Les ressources de mise en réseau comprennent les plages d'adresses IP, les réseaux virtuels, les équilibreurs de charge et les groupes de sécurité réseau. Dans cet article, vous découvrez les meilleures pratiques liées à ces ressources.

Consultez Modèles de mise en réseau de Service Fabric Azure pour savoir comment créer des clusters utilisant les fonctionnalités suivantes : réseau virtuel ou sous-réseau existant, adresse IP publique statique, équilibreur de charge interne uniquement, ou équilibreur de charge interne et externe.

Mise en réseau de l’infrastructure

Optimisez les performances de votre machine virtuelle avec la mise en réseau accélérée, en déclarant la propriété enableAcceleratedNetworking dans votre modèle Resource Manager. L’extrait suivant fait partie d’un groupe de machines virtuelles identiques NetworkInterfaceConfigurations qui permet la mise en réseau accélérée :

"networkInterfaceConfigurations": [
  {
    "name": "[concat(variables('nicName'), '-0')]",
    "properties": {
      "enableAcceleratedNetworking": true,
      "ipConfigurations": [
        {
        <snip>
        }
      ],
      "primary": true
    }
  }
]

Un cluster Service Fabric peut être configuré sur Linux avec mise en réseau accélérée, et Windows avec mise en réseau accélérée.

La mise en réseau accélérée est prise en charge pour les références SKU de la série de machines virtuelles Azure : D/DSv2, D/DSv3, E/ESv3, F/FS, FSv2 et Ms/Mms. La mise en réseau accélérée a été testée avec succès à l’aide de la référence SKU Standard_DS8_v3 pour un cluster Service Fabric Windows le 23/01/2019 et à l’aide de la référence SKU Standard_DS12_v2 pour un cluster Service Fabric Linux le 29/01/2019. Notez que les performances réseau accélérées nécessite au moins 4 processeurs virtuels.

Si vous souhaitez activer les performances réseau accélérées sur un cluster Service Fabric existant, vous devez d’abord Montez en charge un cluster Service Fabric en ajoutant un groupe de machines virtuelles identiques, afin d’effectuer la procédure suivante :

  1. Approvisionner un type de nœud avec mise en réseau accélérée activée
  2. Migrer vos services et leur état vers le type de nœud approvisionné avec mise en réseau accélérée activée

La mise à l’échelle de l’infrastructure est requise pour activer la mise en réseau accélérée sur un cluster existant. En effet, l'activation de la mise en réseau accélérée peut entraîner un temps d’arrêt, car elle implique que toutes les machines virtuelles d'un groupe à haute disponibilité soient arrêtées et libérées avant d'activer la mise en réseau accélérée sur une carte réseau existante.

Mise en réseau de cluster

  • Pour déployer des clusters Service Fabric dans un réseau virtuel existant, suivez la procédure décrite dans Modèles de mise en réseau de Service Fabric.

  • Les groupes de sécurité réseau (NSG) sont recommandés pour les types de nœuds afin de limiter le trafic entrant et sortant de leur cluster. Assurez-vous que les ports nécessaires sont ouverts dans les groupes de sécurité réseau.

  • Le type de nœud principal, qui contient les services système Service Fabric n'est pas tenu d’être exposé via l’équilibreur de charge externe et peut être exposé par un équilibreur de charge interne

  • Utilisez une adresse IP publique statique pour votre cluster.

Règles de sécurité du réseau

Les règles décrites ci-après sont celles minimales recommandées pour une configuration typique. Nous incluons également les règles qui sont obligatoires pour un cluster opérationnel si des règles facultatives ne sont pas souhaitées. Cela permet un verrouillage complet de la sécurité grâce à des concepts d’appairage de réseaux et de jumpbox comme Azure Bastion. L’absence d’ouverture des ports obligatoires ou d’approbation de l’adresse IP/l’URL empêche le bon fonctionnement du cluster et risque de ne pas être pris en charge.

Entrant

Priority Nom Port Protocole Source Destination Action Obligatoire
3900 Portail Azure 19080 TCP ServiceFabric Quelconque Allow Oui
3910 API client 19000 TCP Internet Quelconque Allow Non
3920 SFX + API client 19080 TCP Internet Quelconque Allow Non
3930 Cluster 1025-1027 TCP VirtualNetwork Quelconque Allow Oui
3940 Éphémère 49152-65534 TCP VirtualNetwork Quelconque Allow Oui
3950 Application 20000-30000 TCP VirtualNetwork Quelconque Allow Oui
3960 RDP 3389 TCP Internet Quelconque Deny Non
3970 SSH 22 TCP Internet Quelconque Deny Non
3980 Point de terminaison personnalisé 443 TCP Internet Quelconque Deny Non

Plus d’informations sur les règles de sécurité de trafic entrant :

  • Portail Azure. Ce port est utilisé par le fournisseur de ressources Service Fabric pour demander des informations sur votre cluster à afficher sur le portail de gestion Azure. Si ce port n’est pas accessible à partir du fournisseur de ressources Service Fabric, vous voyez s’afficher un message tel que « Nœuds introuvables » ou « UpgradeServiceNotReachable » dans le Portail Azure, et votre liste de nœuds et d’applications est vide. Cela signifie que, si vous souhaitez avoir une certaine visibilité de votre cluster dans le portail de gestion Azure, votre équilibreur de charge doit exposer une adresse IP publique et votre groupe de sécurité réseau doit autoriser le trafic 19080 entrant. Ce port est recommandé pour les opérations de gestion étendue à partir du fournisseur de ressources Service Fabric afin de garantir une fiabilité accrue.

  • API client. Point de terminaison de connexion client pour les API utilisées par PowerShell.

  • SFX + API client. Ce port est utilisé par Service Fabric Explorer pour parcourir et gérer votre cluster. Il est également utilisé par les API les plus courantes telles que REST/PowerShell (Microsoft.ServiceFabric.PowerShell.Http)/CLI/.NET de la même manière.

  • Cluster. Utilisé pour la communication entre les nœuds.

  • Éphémère. Service Fabric utilise une partie de ces ports comme ports d’application et le reste est disponible pour le système d’exploitation. Le service mappe également cette plage à la plage existante dans le système d’exploitation. Vous pouvez donc utiliser en toutes circonstances les plages spécifiées dans l’exemple. Assurez-vous que la différence entre les ports de début et de fin est d’au moins 255. Vous pouvez rencontrer des conflits si cette différence est trop faible, étant donné que cette plage est partagée avec le système d’exploitation. Pour afficher la plage de ports dynamiques configurée, exécutez la commande netsh int ipv4 show dynamicport tcp. Ces ports ne sont pas nécessaires pour les clusters Linux.

  • Application. La plage des ports d’application doit suffire à couvrir les exigences en matière de points de terminaison de vos applications. Cette plage doit être exclusive à partir de la plage de ports dynamiques de la machine, c’est-à-dire la plage ephemeralPorts comme défini dans la configuration. Service Fabric utilise ces ports chaque fois que des nouveaux ports sont nécessaires, et prend également en charge l’ouverture du pare-feu pour ces ports sur les nœuds.

  • RDP. Facultatif, si le protocole RDP est requis à partir d’Internet ou de VirtualNetwork pour des scénarios JumpBox.

  • SSH. Facultatif, si le protocole SSH est requis à partir d’Internet ou de VirtualNetwork pour des scénarios JumpBox.

  • Point de terminaison personnalisé. Exemple destiné à votre application pour activer un point de terminaison accessible via Internet.

Notes

Pour la plupart des règles avec Internet comme source, envisagez de limiter votre réseau connu, idéalement défini par un bloc CIDR.

Sortant

Priority Nom Port Protocole Source Destination Action Obligatoire
4010 Fournisseur de ressources 443 TCP Quelconque ServiceFabric Allow Oui
4020 Télécharger des fichiers binaires 443 TCP Quelconque AzureFrontDoor.FirstParty Allow Oui

Pour plus d’informations sur les règles de sécurité du trafic sortant, procédez comme suit :

  • Fournisseur de ressources. Connexion entre UpgradeService et un fournisseur de ressources Service Fabric pour recevoir des opérations de gestion telles que des déploiements ARM ou des opérations obligatoires telles que la sélection de nœud initial ou la mise à niveau du type de nœud principal.

  • Télécharger des fichiers binaires. Le service de mise à niveau utilise l’adresse download.microsoft.com pour obtenir les fichiers binaires. Cette relation est nécessaire pour les mises à niveau de configuration, de recréation d’image et de runtime. Dans le scénario d’un équilibreur de charge « interne uniquement », un équilibreur de charge externe supplémentaire doit être ajouté avec une règle autorisant le trafic sortant pour le port 443. Si vous le souhaitez, vous pouvez bloquer ce port après une installation réussie mais, dans ce cas, le package de mise à niveau doit être distribué aux nœuds, ou le port doit être ouvert pendant une brève période. Une mise à niveau manuelle est ensuite nécessaire.

Utilisez le Pare-feu Azure avec le journal de flux NSG et l’analyse du trafic pour suivre les problèmes de connectivité. Le modèle ARM Service Fabric avec NSG est un bon exemple pour commencer.

Remarque

Les règles de sécurité réseau par défaut ne doivent pas être remplacées car elles veillent à la communication entre les nœuds. Groupe de sécurité réseau – Fonctionnement. Autre exemple, une connectivité sortante sur le port 80 est nécessaire pour vérifier la liste de révocation de certificats.

Scénarios courants nécessitant des règles supplémentaires

Tous les scénarios supplémentaires peuvent être couverts avec les étiquettes de service Azure.

Azure DevOps

Les tâches PowerShell classiques dans Azure DevOps (étiquette de service : AzureCloud) ont besoin d’un accès de l’API Client au cluster, par exemple, dans le cas des déploiements d’applications ou des tâches opérationnelles. Cela ne s’applique pas à l’approche basée uniquement sur les modèles ARM, y compris les ressources d’application ARM.

Priorité Nom Port Protocole Source Destination Action Sens
3915 Azure DevOps 19000 TCP AzureCloud Quelconque Allow Trafic entrant

Mise à jour de Windows

La meilleure pratique pour corriger le système d’exploitation Windows consiste à remplacer le disque du système d’exploitation par des mises à niveau automatiques de l’image du système d’exploitation, aucune règle supplémentaire n’est requise. L’Application d’orchestration des correctifs gère les mises à niveau dans les machines virtuelles où Windows Updates applique les correctifs du système d’exploitation, ce qui nécessite un accès au centre de téléchargement (étiquette de service : AzureUpdateDelivery) pour télécharger les fichiers binaires de mise à jour.

Priority Nom Port Protocole Source Destination Action Sens
4015 Mises à jour Windows 443 TCP Quelconque AzureUpdateDelivery Allow Règle de trafic sortant

Gestion des API

L’intégration d’Azure API Management (étiquette de service : ApiManagement) a besoin d’un accès d’API client pour interroger les informations de point de terminaison à partir du cluster.

Priority Nom Port Protocole Source Destination Action Sens
3920 Gestion des API 19080 TCP ApiManagement Quelconque Allow Trafic entrant

Mise en réseau de l’application

  • Pour exécuter des charges de travail de conteneur Windows, utilisez le mode de mise en réseau ouvert afin de simplifier la communication de service à service.

  • Utilisez un proxy inversé tel que Traefik ou le proxy inversé Service Fabric pour exposer les ports d’application courants tels que 80 ou 443.

  • Pour les conteneurs Windows hébergés sur des machines isolées sous « air gap » qui ne peuvent pas extraire des couches de base du stockage cloud Azure, remplacez le comportement de couche étrangère, en utilisant l’indicateur --allow-nondistributable-artifacts dans le démon Docker.

Étapes suivantes