Partager via

Révision d’Azure Well-Architected Framework - Azure Service Fabric

  • Article

Azure Service Fabric est une plateforme de systèmes distribués qui facilite la création de packages pour déployer et gérer des microservices et des conteneurs fiables et évolutifs. Ces ressources sont déployées sur un ensemble de machines virtuelles ou physiques connectées au réseau, appelé cluster.

Il existe deux modèles de clusters dans Azure Service Fabric : les clusters standard et les clusters managés.

Les clusters standard nécessitent que vous définissiez une ressource de cluster en même temps qu’un certain nombre de ressources de prise en charge. Ces ressources doivent être correctement configurées lors du déploiement et gérées correctement tout au long du cycle de vie du cluster. Sinon, le cluster et vos services ne fonctionneront pas correctement.

Les clusters managés simplifient vos opérations de déploiement et de gestion. Le modèle de cluster managé se compose d’une seule ressource de cluster managé Service Fabric qui encapsule et extrait les ressources sous-jacentes.

Cet article traite principalement du modèle de cluster managé par souci de simplicité. Toutefois, des rappels sont effectués pour toutes les considérations spéciales qui s’appliquent au modèle de cluster standard .

Dans cet article, vous allez découvrir les meilleures pratiques architecturales pour Azure Service Fabric. L’orientation repose sur les cinq piliers de l’excellence architecturale :

  • Fiabilité
  • Sécurité
  • Optimisation des coûts
  • Excellence opérationnelle
  • Efficacité des performances

Prérequis

Fiabilité

Les sections suivantes couvrent les considérations relatives à la conception et les recommandations de configuration, spécifiques à Azure Service Fabric et à la fiabilité.

Lorsque vous discutez de la fiabilité avec Azure Service Fabric, il est important de faire la distinction entre la fiabilité du cluster et la fiabilité de la charge de travail. La fiabilité du cluster est une responsabilité partagée entre l’administrateur de cluster Service Fabric et son fournisseur de ressources, tandis que la fiabilité de la charge de travail est le domaine d’un développeur. Azure Service Fabric contient des considérations et des recommandations pour ces deux rôles.

Dans la liste de contrôle de conception et la liste de recommandations ci-dessous, des rappels sont effectués pour indiquer si chaque choix s’applique à l’architecture de cluster, à l’architecture de charge de travail ou aux deux.

Pour plus d’informations sur la fiabilité des clusters Azure Service Fabric, case activée la documentation de planification de la capacité.

Pour plus d’informations sur la fiabilité des charges de travail Azure Service Fabric, reportez-vous au sous-système de fiabilité inclus dans l’architecture Service Fabric.

Check-list pour la conception

Lorsque vous effectuez des choix de conception pour Azure Service Fabric, passez en revue les principes de conception pour ajouter de la fiabilité à l’architecture.

  • Architecture du cluster : Utilisez la référence SKU Standard pour les scénarios de production. Cluster standard : Utilisez le niveau de durabilité Silver (5 machines virtuelles) ou supérieur pour les scénarios de production.
  • Architecture du cluster : Pour les charges de travail critiques, envisagez d’utiliser Zones de disponibilité pour vos clusters Service Fabric.
  • Architecture du cluster : Pour les scénarios de production, utilisez l’équilibreur de charge de niveau Standard. Les clusters gérés créent un Azure Load Balancer public Standard Load Balancer et un nom de domaine complet avec une adresse IP publique statique pour les types de nœuds principal et secondaires. Vous pouvez également apporter votre propre équilibreur de charge, qui prend en charge les équilibreurs de charge de référence SKU De base et Standard.
  • Architecture du cluster : Créez des types de nœuds secondaires supplémentaires pour vos charges de travail.

Recommandations

Explorez le tableau de recommandations suivant pour optimiser votre configuration d’Azure Service Fabric pour la fiabilité du service :

Recommandation pour Azure Service Fabric Avantage
Architecture du cluster : Utilisez la référence SKU Standard pour les scénarios de production. Ce niveau garantit que le fournisseur de ressources maintient la fiabilité du cluster. Cluster standard : Un cluster managé de référence SKU Standard fournit l’équivalent du niveau de durabilité Silver. Pour ce faire, vous devez utiliser 5 machines virtuelles (ou plus) à l’aide du modèle de cluster standard.
Architecture du cluster : Envisagez d’utiliser Zones de disponibilité pour vos clusters Service Fabric. Un cluster managé Service Fabric prend en charge les déploiements qui s’étendent sur plusieurs zones de disponibilité pour assurer la résilience des zones. Cette configuration garantit la haute disponibilité des services système critiques et de vos applications afin de les protéger contre les points de défaillance uniques.
Architecture du cluster : Envisagez d’utiliser Azure Gestion des API pour exposer et décharger des fonctionnalités transversales pour les API hébergées sur le cluster. Gestion des API peut s’intégrer directement à Service Fabric.
Architecture de charge de travail : Pour les scénarios de charge de travail avec état, envisagez d’utiliser Reliable Services. Le modèle Reliable Services permet à vos services de rester opérationnels même dans des environnements peu fiables où vos machines échouent ou rencontrent des problèmes réseau, ou dans les cas où les services eux-mêmes rencontrent des erreurs et se bloquent ou échouent. Pour les services avec état, l’état est conservé même en cas de panne du réseau ou d’autres incidents.

Pour obtenir d’autres suggestions, consultez Principes du pilier de fiabilité.

Sécurité

Les sections suivantes couvrent les considérations de conception et les recommandations de configuration, spécifiques à Azure Service Fabric et à la sécurité.

Lorsque vous discutez de la sécurité avec Azure Service Fabric, il est important de faire la distinction entre la sécurité du cluster et la sécurité de la charge de travail. La sécurité du cluster est une responsabilité partagée entre l’administrateur de cluster Service Fabric et son fournisseur de ressources, tandis que la sécurité de la charge de travail est le domaine d’un développeur. Azure Service Fabric contient des considérations et des recommandations pour ces deux rôles.

Dans la liste de contrôle de conception et la liste de recommandations ci-dessous, des rappels sont effectués pour indiquer si chaque choix s’applique à l’architecture de cluster, à l’architecture de charge de travail ou aux deux.

Pour plus d’informations sur la sécurité du cluster Azure Service Fabric, case activée scénarios de sécurité de cluster Service Fabric.

Pour plus d’informations sur la sécurité des charges de travail Azure Service Fabric, consultez Sécurité des applications et des services Service Fabric.

Check-list pour la conception

Lorsque vous effectuez des choix de conception pour Azure Service Fabric, passez en revue les principes de conception pour ajouter la sécurité à l’architecture.

  • Architecture du cluster : Vérifiez que les groupes de sécurité réseau (NSG) sont configurés pour limiter le flux de trafic entre les sous-réseaux et les types de nœuds. Vérifiez que les ports appropriés sont ouverts pour le déploiement d’applications et les charges de travail.
  • Architecture du cluster : Lorsque vous utilisez le magasin de secrets Service Fabric pour distribuer des secrets, utilisez un certificat de chiffrement de données distinct pour chiffrer les valeurs.
  • Architecture de cluster :déployez des certificats clients en les ajoutant à Azure Key Vault et en référençant l’URI dans votre déploiement.
  • Architecture du cluster : Activez l’intégration Microsoft Entra pour votre cluster afin que les utilisateurs puissent accéder à Service Fabric Explorer à l’aide de leurs informations d’identification Microsoft Entra. Ne distribuez pas les certificats clients de cluster entre les utilisateurs pour accéder à Explorer.
  • Architecture du cluster : Pour l’authentification du client, utilisez des certificats clients d’administration et en lecture seule et/ou Microsoft Entra l’authentification.
  • Architectures de cluster et de charge de travail : Créez un processus pour surveiller la date d’expiration des certificats clients.
  • Architectures de cluster et de charge de travail : Conservez des clusters distincts pour le développement, la préproduction et la production.

Recommandations

Tenez compte des recommandations suivantes pour optimiser votre configuration Azure Service Fabric pour la sécurité :

Recommandation pour Azure Service Fabric Avantage
Architecture du cluster : Vérifiez que les groupes de sécurité réseau (NSG) sont configurés pour limiter le flux de trafic entre les sous-réseaux et les types de nœuds. Par exemple, vous pouvez avoir un Gestion des API instance (un sous-réseau), un sous-réseau frontal (exposant directement un site web) et un sous-réseau principal (accessible uniquement au serveur frontal).
Architecture du cluster : Déployez Key Vault certificats sur des groupes de machines virtuelles identiques de cluster Service Fabric. La centralisation du stockage des secrets d’application dans Azure Key Vault vous permet de contrôler la distribution de ces secrets. Key Vault réduit considérablement les risques de fuite accidentelle des secrets.
Architecture du cluster : Appliquez une liste de Access Control (ACL) à votre certificat client pour votre cluster Service Fabric. L’utilisation d’une liste de contrôle d’accès fournit un niveau d’authentification supplémentaire.
Architecture du cluster : Utilisez les demandes de ressources et les limites pour régir l’utilisation des ressources sur les nœuds de votre cluster. L’application de limites de ressources permet de s’assurer qu’un service ne consomme pas trop de ressources et prive d’autres services.
Architecture de charge de travail : Chiffrer les valeurs secrètes du package Service Fabric. Le chiffrement de vos valeurs secrètes fournit un niveau de sécurité supplémentaire.
Architecture de charge de travail : Inclure des certificats clients dans les applications Service Fabric. Le fait que vos applications utilisent des certificats clients pour l’authentification offre des opportunités de sécurité au niveau du cluster et de la charge de travail.
Architecture de charge de travail : Authentifier les applications Service Fabric auprès des ressources Azure à l’aide de l’identité managée. L’utilisation de l’identité managée vous permet de gérer en toute sécurité les informations d’identification dans votre code pour l’authentification auprès de différents services sans les enregistrer localement sur une station de travail de développeur ou dans le contrôle de code source.
Architectures de cluster et de charge de travail : Suivez les meilleures pratiques de Service Fabric lors de l’hébergement d’applications non approuvées. Le respect des meilleures pratiques fournit une norme de sécurité à suivre.

Pour plus de suggestions, consultez Principes du pilier de sécurité.

Azure Advisor vous aide à garantir et à améliorer la sécurité d’Azure Service Fabric. Vous pouvez passer en revue les recommandations dans la section Azure Advisor de cet article.

Définitions de stratégies

Azure Policy permet de maintenir les normes organisationnelles et d’évaluer la conformité de vos ressources. Gardez à l’esprit les stratégies intégrées suivantes lorsque vous configurez Azure Service Fabric :

  • La propriété ClusterProtectionLevel doit être définie sur EncryptAndSignles clusters Service Fabric. Il s’agit de la valeur par défaut pour les clusters managés et n’est pas modifiable. Cluster standard : Veillez à définir ClusterProtectionLevel sur EncryptAndSign.
  • Les clusters Service Fabric doivent utiliser uniquement l’ID Microsoft Entra pour l’authentification du client.

Toutes les définitions de stratégie intégrées liées à Azure Service Fabric sont répertoriées dans Stratégies intégrées - Service Fabric.

Optimisation des coûts

Les sections suivantes couvrent les considérations relatives à la conception et les recommandations de configuration, spécifiques à Azure Service Fabric et à l’optimisation des coûts.

Lorsque vous discutez de l’optimisation des coûts avec Azure Service Fabric, il est important de faire la distinction entre le coût des ressources de cluster et le coût des ressources de charge de travail. Les ressources de cluster sont une responsabilité partagée entre l’administrateur de cluster Service Fabric et leur fournisseur de ressources, tandis que les ressources de charge de travail sont le domaine d’un développeur. Azure Service Fabric contient des considérations et des recommandations pour ces deux rôles.

Dans la liste de contrôle de conception et la liste de recommandations ci-dessous, des rappels sont effectués pour indiquer si chaque choix s’applique à l’architecture de cluster, à l’architecture de charge de travail ou aux deux.

Pour l’optimisation des coûts du cluster, accédez à la calculatrice de prix Azure et sélectionnez Azure Service Fabric parmi les produits disponibles. Vous pouvez tester différents plans de configuration et de paiement dans la calculatrice.

Pour plus d’informations sur la tarification de la charge de travail Azure Service Fabric, case activée l’exemple de processus de calcul des coûts pour la planification des applications.

Check-list pour la conception

Lorsque vous effectuez des choix de conception pour Azure Service Fabric, passez en revue les principes de conception pour optimiser le coût de votre architecture.

  • Architecture du cluster : Sélectionnez la référence SKU de machine virtuelle appropriée.
  • Architecture du cluster : Utilisez le type et la taille de nœud appropriés.
  • Architectures de cluster et de charge de travail : Utilisez le niveau et la taille de disque managé appropriés.

Recommandations

Explorez le tableau de recommandations suivant pour optimiser votre configuration Azure Service Fabric pour les coûts :

Recommandation pour Azure Service Fabric Avantage
Architecture du cluster : Évitez les références SKU de machine virtuelle avec des offres de disques temporaires. Service Fabric utilise des disques managés par défaut. Par conséquent, en évitant les offres de disques temporaires, vous ne payez pas pour les ressources inutiles.
Architecture du cluster : Si vous devez sélectionner une certaine référence SKU de machine virtuelle pour des raisons de capacité et qu’il arrive à proposer un disque temporaire, envisagez d’utiliser la prise en charge des disques temporaires pour vos charges de travail sans état. Tirer le meilleur parti des ressources que vous payez. L’utilisation d’un disque temporaire au lieu d’un disque managé peut réduire les coûts des charges de travail sans état.
Architectures de cluster et de charge de travail : Alignez la sélection de la référence SKU et la taille du disque managé avec les exigences de charge de travail. Si vous faites correspondre votre sélection à vos demandes de charge de travail, vous ne payez pas pour les ressources inutiles.

Pour obtenir d’autres suggestions, consultez Principes du pilier d’optimisation des coûts.

Excellence opérationnelle

Les sections suivantes couvrent les considérations relatives à la conception et les recommandations de configuration, spécifiques à Azure Service Fabric et à l’excellence opérationnelle.

Lorsque vous discutez de la sécurité avec Azure Service Fabric, il est important de faire la distinction entre l’opération de cluster et l’opération de charge de travail. L’opération de cluster est une responsabilité partagée entre l’administrateur de cluster Service Fabric et son fournisseur de ressources, tandis que l’opération de charge de travail est le domaine d’un développeur. Azure Service Fabric contient des considérations et des recommandations pour ces deux rôles.

Dans la liste de contrôle de conception et la liste de recommandations ci-dessous, des rappels sont effectués pour indiquer si chaque choix s’applique à l’architecture de cluster, à l’architecture de charge de travail ou aux deux.

Check-list pour la conception

Lorsque vous effectuez des choix de conception pour Azure Service Fabric, passez en revue les principes de conception pour l’excellence opérationnelle.

Recommandations

Explorez le tableau de recommandations suivant pour optimiser votre configuration d’Azure Service Fabric pour l’excellence opérationnelle :

Recommandation pour Azure Service Fabric Avantage
Architecture de charge de travail : Utilisez Application Insights pour surveiller vos charges de travail. Application Insights s’intègre à la plateforme Azure, y compris Service Fabric.
Architectures de cluster et de charge de travail : Créez un processus pour surveiller la date d’expiration des certificats clients. Par exemple, Key Vault propose une fonctionnalité qui envoie un e-mail lorsque x% de la durée de vie du certificat s’est écoulée.
Architectures de cluster et de charge de travail : Pour les clusters de préproduction, utilisez Azure Chaos Studio pour explorer l’interruption de service sur un groupe de machines virtuelles identiques instance défaillance. La pratique de scénarios d’interruption de service vous aidera à comprendre ce qui est à risque dans votre infrastructure et comment atténuer au mieux les problèmes s’ils se produisent.
Architectures de cluster et de charge de travail : Utilisez Azure Monitor pour surveiller les événements d’infrastructure de cluster et de conteneur. Azure Monitor s’intègre bien à la plateforme Azure, y compris Service Fabric.
Architectures de cluster et de charge de travail : Utilisez Azure Pipelines pour votre solution d’intégration et de déploiement continus. Azure Pipelines s’intègre bien à la plateforme Azure, y compris Service Fabric.

Pour obtenir d’autres suggestions, consultez Principes du pilier de l’excellence opérationnelle.

Efficacité des performances

La section suivante décrit les recommandations de configuration spécifiques à Azure Service Fabric et à l’efficacité des performances.

Lorsque vous discutez de la sécurité avec Azure Service Fabric, il est important de faire la distinction entre l’opération de cluster et l’opération de charge de travail. Les performances du cluster sont une responsabilité partagée entre l’administrateur de cluster Service Fabric et leur fournisseur de ressources, tandis que les performances de charge de travail sont le domaine d’un développeur. Azure Service Fabric contient des considérations et des recommandations pour ces deux rôles.

Dans la liste de contrôle de conception et la liste de recommandations ci-dessous, des rappels sont effectués pour indiquer si chaque choix s’applique à l’architecture de cluster, à l’architecture de charge de travail ou aux deux.

Pour plus d’informations sur la façon dont Azure Service Fabric peut réduire les problèmes de performances de votre charge de travail avec les compteurs de performances Service Fabric, consultez Meilleures pratiques en matière de surveillance et de diagnostic pour Azure Service Fabric.

Check-list pour la conception

  • Architecture du cluster :Excluez les processus Service Fabric de Windows Defender pour améliorer les performances.
  • Architecture du cluster : Sélectionnez la référence SKU de machine virtuelle appropriée.
  • Architecture de charge de travail : Déterminez le modèle de programmation que vous utiliserez pour vos services.
  • Architectures de cluster et de charge de travail : Utilisez le niveau et la taille de disque managé appropriés.

Recommandations

Tenez compte des recommandations suivantes pour optimiser votre configuration Azure Service Fabric pour optimiser les performances :

Recommandation pour Azure Service Fabric Avantage
Architecture du cluster : Excluez les processus Service Fabric de Windows Defender pour améliorer les performances. Par défaut, l’antivirus Windows Defender est installé sur Windows Server 2016 et 2019. Pour réduire l’impact sur les performances et la consommation des ressources engendrés par Windows Defender, et si vos stratégies de sécurité vous permettent d’exclure les processus et les chemins d’accès pour les logiciels open source, vous pouvez exclure.
Architecture du cluster : Envisagez d’utiliser la mise à l’échelle automatique pour votre cluster. La mise à l’échelle automatique offre une grande élasticité et permet l’ajout ou la réduction des nœuds à la demande sur un type de nœud secondaire. Ce comportement automatisé et élastique réduit les frais généraux dus à la gestion et l’impact potentiel sur l’entreprise en surveillant et en optimisant le nombre de nœuds traitant votre charge de travail.
Architecture du cluster : Envisagez d’utiliser la mise en réseau accélérée. La mise en réseau accélérée permet un chemin d’accès hautes performances qui contourne l’hôte du chemin des données, ce qui réduit la latence, la gigue et l’utilisation du processeur pour les charges de travail réseau les plus exigeantes.
Architecture du cluster : Envisagez d’utiliser le chiffrement sur l’hôte au lieu d’Azure Disk Encryption (ADE). Cette méthode de chiffrement s’améliore sur ADE en prenant en charge tous les types et images de système d’exploitation, y compris les images personnalisées, pour vos machines virtuelles en chiffrant les données dans le service Stockage Azure.
Architecture de charge de travail : Passez en revue les modèles de programmation Service Fabric pour déterminer le modèle le mieux adapté à vos services. Service Fabric prend en charge plusieurs modèles de programmation. Chacun est accompagné de ses propres avantages et inconvénients. Connaître les modèles de programmation disponibles peut vous aider à faire les meilleurs choix pour concevoir vos services.
Architecture de charge de travail : Tirez parti des microservices faiblement couplés pour vos charges de travail, le cas échéant. L’utilisation de microservices vous permet de tirer le meilleur parti des fonctionnalités de Service Fabric.
Architecture de charge de travail : Tirez parti de l’architecture pilotée par les événements pour vos charges de travail, le cas échéant. L’utilisation d’une architecture pilotée par les événements vous permet de tirer le meilleur parti des fonctionnalités de Service Fabric.
Architecture de charge de travail : Tirez parti du traitement en arrière-plan pour vos charges de travail, le cas échéant. L’utilisation du traitement en arrière-plan vous permet de tirer le meilleur parti des fonctionnalités de Service Fabric.
Architectures de cluster et de charge de travail : Passez en revue les différentes façons dont vous pouvez mettre à l’échelle votre solution dans Service Fabric. Vous pouvez utiliser la mise à l’échelle pour activer l’utilisation maximale des ressources pour votre solution.

Pour plus de suggestions, consultez Principes du pilier d’efficacité des performances.

Recommandations Azure Advisor

Azure Advisor est un conseiller cloud personnalisé qui vous aide à suivre les bonnes pratiques pour optimiser vos déploiements Azure. Voici quelques recommandations qui peuvent vous aider à améliorer la fiabilité, la sécurité, la rentabilité, les performances et l’excellence opérationnelle lors de l’utilisation d’Azure Service Fabric.

Sécurité

  • La propriété ClusterProtectionLevel des clusters Service Fabric doit avoir la EncryptAndSignvaleur . Il s’agit de la valeur par défaut pour les clusters managés et n’est pas modifiable. Cluster standard : Veillez à définir ClusterProtectionLevel sur EncryptAndSign.
  • Les clusters Service Fabric doivent utiliser uniquement Microsoft Entra ID pour l’authentification du client.

Ressources supplémentaires

Consultez l’article Options de configuration de cluster managé Azure Service Fabric pour obtenir la liste de toutes les options dont vous disposez lors de la création et de la maintenance de votre cluster.

Consultez les principes de base de l’architecture des applications Azure pour obtenir des conseils sur la façon de développer vos charges de travail. Bien que Service Fabric puisse être utilisé uniquement en tant que plateforme d’hébergement de conteneur, l’utilisation de charges de travail bien conçues tire parti des fonctionnalités complètes de Service Fabric.

Étapes suivantes

Utilisez ces recommandations lorsque vous créez votre cluster managé Service Fabric à l’aide d’un modèle ARM ou via le Portail Azure :