Partage via


Introduction aux hôtes dédiés sur les clusters gérés Service Fabric (préversion)

Un hôte dédié Azure est un service qui fournit des serveurs physiques (capables d’héberger une ou plusieurs machines virtuelles) dédiés à un abonnement Azure. Le serveur est dédié à votre organisation et à vos charges de travail, et la capacité n’est partagée avec personne d’autre. Les hôtes dédiés sont les mêmes serveurs physiques que ceux utilisés dans nos centres de données, fournis en tant que ressource. Vous pouvez provisionner des hôtes dédiés au sein d’une région, d’une zone de disponibilité et d’un domaine d’erreur. Ensuite, vous pouvez placer des machines virtuelles directement dans vos hôtes approvisionnés, dans la configuration qui répond le mieux à vos besoins.

L’utilisation d’Azure Dedicated Host pour les nœuds avec votre cluster managé Service Fabric (SFMC) présente les avantages suivants :

  • Isolation matérielle au niveau de l’hôte au niveau du serveur physique. Aucune autre machine virtuelle ne sera placée sur vos hôtes. Les hôtes dédiés sont déployés dans les mêmes centres de données et partagent le même réseau et la même infrastructure de stockage sous-jacente que les autres hôtes non isolés.
  • Contrôle des événements de maintenance initiés par la plateforme Azure. Alors que la plupart des événements de maintenance n’ont que peu d’impact sur les machines virtuelles, il existe des charges de travail sensibles où chaque seconde de pause peut avoir un impact. Avec les hôtes dédiés, vous pouvez vous abonner à une fenêtre de maintenance pour réduire l’impact sur le service.

Vous pouvez choisir la référence SKU pour les machines virtuelles à hôte dédié en fonction de vos besoins en charge de travail. Pour plus d’informations, consultez Machines virtuelles Dedicated Host.

Le guide suivant vous guide pas à pas pour ajouter un Azure Dedicated Host à un cluster managé Service Fabric avec un modèle Azure Resource Manager.

Prérequis

Ce guide s’appuie sur le guide de démarrage rapide de cluster managé Déployer un cluster managé Service Fabric à l’aide d’Azure Resource Manager

Avant de commencer :

Vérifier le modèle

Le modèle utilisé dans ce guide provient des Exemples Azure - Modèles de cluster Service Fabric.

Créer un certificat client

Les clusters managés Service Fabric utilisent un certificat client comme clé pour le contrôle d’accès. Si vous disposez déjà d’un certificat client que vous souhaitez utiliser pour le contrôle d’accès à votre cluster, vous pouvez ignorer cette étape.

Si vous avez besoin de créer un certificat client, suivez les étapes décrites dans Définir et récupérer un certificat dans Azure Key Vault. Notez l’empreinte numérique du certificat, car cela sera nécessaire pour déployer le modèle à l’étape suivante.

Déployer des ressources hôte dédiées et configurer l’accès au fournisseur de ressources Service Fabric

Créez un groupe hôte dédié et ajoutez une attribution de rôle au groupe hôte avec l’application Fournisseur de ressources Service Fabric en suivant les étapes ci-dessous. Cette attribution de rôle permet au fournisseur de ressources Service Fabric de déployer des machines virtuelles sur les hôtes dédiés à l’intérieur du groupe hôte sur le groupe de machines virtuelles identiques du cluster managé. Cette affectation est une action ponctuelle.

  1. Obtenez l’ID du fournisseur SFRP et le principal du service pour l’application de fournisseur de ressources Service Fabric.

    Login-AzAccount  
    Select-AzSubscription -SubscriptionId <SubId>  
    Get-AzADServicePrincipal -DisplayName "Azure Service Fabric Resource Provider"
    

    Notes

    Vérifiez que vous êtes bien dans le bon abonnement. L’ID du principal ne sera pas le même si l’abonnement se trouve dans un autre locataire.

  2. Créez un groupe hôte dédié épinglé à une zone de disponibilité et cinq domaines d’erreur à l’aide de l’exemple de modèle de déploiement ARM fourni pour le groupe hôte dédié. L’exemple garantit qu’il existe au moins un hôte dédié par domaine d’erreur.

    New-AzResourceGroup -Name $ResourceGroupName -Location $location
    New-AzResourceGroupDeployment -Name "hostgroup-deployment" -ResourceGroupName $ResourceGroupName -TemplateFile ".\HostGroup-And-RoleAssignment.json" -TemplateParameterFile ".\HostGroup-And-RoleAssignment.parameters.json" -Debug -Verbose
    

    Notes

    • Veillez à choisir la bonne famille de références SKU pour l’hôte dédié, à savoir celle correspondant à celle que vous allez utiliser pour la référence SKU de type de nœud sous-jacente. Pour plus d’informations, consultez Machines virtuelles Dedicated Host.
    • Chaque domaine d’erreur a besoin qu’un hôte dédié soit placé dans celui-ci, et les clusters managés Service Fabric nécessitent cinq domaines d’erreur. Par conséquent, au moins cinq hôtes dédiés doivent être présents dans chaque groupe hôte dédié.
  3. L’exemple de modèle de déploiement ARM pour le groupe hôte dédié utilisé à l’étape précédente ajoute également une attribution de rôle au groupe hôte avec un accès contributeur. Pour plus d’informations sur les rôles Azure, consultez Rôles intégrés Azure - Azure RBAC. Cette attribution de rôle est définie dans la section Ressources du modèle avec l’ID principal déterminé à partir de la première étape et un ID de définition de rôle.

       "variables": {  
            "authorizationApiVersion": "2018-01-01-preview",
            "contributorRoleId": "b24988ac-6180-42a0-ab88-20f7382dd24c",
            "SFRPAadServicePrincipalId": " <Service Fabric Resource Provider ID> -"
          },
       "resources": [
       {  
                "apiVersion": "[variables('authorizationApiVersion')]",  
                "type": "Microsoft.Compute/Hostgroups/providers/roleAssignments",  
                "name": "[concat(concat(parameters('dhgNamePrefix'), '0'), '/Microsoft.Authorization/', parameters('hostGroupRoleAssignmentId'))]",  
                "dependsOn": [  
                    "[resourceId('Microsoft.Compute/hostGroups', concat(parameters('dhgNamePrefix'), '0'))]"  
                ],  
                "properties": {  
                    "roleDefinitionId": "[concat('/subscriptions/', subscription().subscriptionId, '/providers/Microsoft.Authorization/roleDefinitions/', variables('contributorRoleId'))]",  
                    "principalId": "[variables('SFRPAadServicePrincipalId')]"  
                }  
              }
              ]
    

    Ou vous pouvez également ajouter une attribution de rôle via PowerShell à l’aide de l’ID principal déterminé à partir de la première étape et du nom de définition de rôle « Contributeur » le cas échéant.

    New-AzRoleAssignment -PrincipalId "<Service Fabric Resource Provider ID>" -RoleDefinitionName "Contributor" -Scope "<Host Group Id>"  
    

Déployer un cluster Service Fabric managé

Créez un cluster managé Azure Service Fabric avec des types de nœuds configurés pour référencer le ResourceId du groupe hôte dédié. Le type de nœud doit être épinglé à la même zone de disponibilité que le groupe hôte.

  1. Choisissez le modèle à partir de l’exemple de modèle de cluster Service Fabric pour l’hôte dédié, qui inclut la spécification de la prise en charge de l’hôte dédié.

  2. Fournissez vos propres valeurs pour les paramètres de modèle suivants :

    • Abonnement : sélectionnez le même abonnement Azure que l’abonnement du groupe hôte.
    • Groupe de ressources : Sélectionnez Créer nouveau. Entrez un nom unique pour le groupe de ressources, tel que myResourceGroup, puis choisissez OK.
    • Emplacement : sélectionnez le même emplacement que l’emplacement du groupe hôte.
    • Nom du cluster : Entrez un nom unique pour votre cluster, par exemple mysfcluster.
    • Nom d’utilisateur administrateur : Entrez un nom pour l’administrateur à utiliser pour le protocole RDP sur les machines virtuelles sous-jacentes dans le cluster.
    • Mot de passe administrateur : Entrez un mot de passe pour l’administrateur à utiliser pour le protocole RDP sur les machines virtuelles sous-jacentes dans le cluster.
    • Empreinte de certificat du client : Indiquez l’empreinte du certificat client que vous souhaitez utiliser pour accéder à votre cluster. Si vous n’avez pas de certificat, suivez les instructions fournies dans Définir et récupérer un certificat pour créer un certificat auto-signé.
    • Nom du type de nœud : Entrez un nom unique pour votre type de nœud, par exemple nt1.
  3. Déployez un modèle ARM via l’une des méthodes ci-dessous :

    • Expérience de modèle personnalisé du portail ARM : Déploiement personnalisé - Microsoft Azure. Sélectionnez l’image suivante pour vous connecter à Azure, fournissez vos propres valeurs pour les paramètres du modèle, puis déployez le modèle.

      Button to deploy the Resource Manager template to Azure.

    • Applets de commande ARM PowerShell : New-AzResourceGroupDeployment (Az.Resources). Stockez le chemin de votre modèle Resource Manager et de vos fichiers de paramètres dans des variables, puis déployez le modèle.

      $templateFilePath = "<full path to azuredeploy.json>" 
      $parameterFilePath = "<full path to azuredeploy.parameters.json>"
      $pass = (ConvertTo-SecureString -AsPlainText -Force "<adminPassword>")
      
      New-AzResourceGroupDeployment ` 
         -Name $DeploymentName ` 
         -ResourceGroupName $resourceGroupName ` 
         -TemplateFile $templateFilePath ` 
         -TemplateParameterFile $parameterFilePath `
         -adminPassword $pass `
         -Debug -Verbose
      

    Attendez que le déploiement se termine avec succès.

Dépannage

  1. L’erreur suivante est levée lorsque SFRP n’a pas accès au groupe hôte. Passez en revue les étapes d’attribution de rôle ci-dessus et vérifiez que l’affectation est effectuée correctement.
         {  
                "code": "LinkedAuthorizationFailed",  
                "message": "The client '[<clientId>]' with object id '[<objectId>]' has permission to perform action 'Microsoft.Compute/virtualMachineScaleSets/write' on scope '/subscriptions/[<Subs-Id>]/resourcegroups/[<ResGrp-Id>]/providers/Microsoft.Compute/virtualMachineScaleSets/pnt'; however, it does not have permission to perform action 'write' on the linked scope(s) '/subscriptions/[<Subs-Id>]/resourceGroups/[<ResGrp-Id>]/providers/Microsoft.Compute/hostGroups/HostGroupscu0' or the linked scope(s) are invalid."
             }
    
  2. Si le groupe hôte se trouve dans un abonnement différent des clusters, l’erreur suivante est signalée. Vérifiez qu’ils se trouvent tous les deux dans le même abonnement.
          {  
                "code": "BadRequest",  
                "message": "Entity subscriptionId in resource reference id /subscriptions/[<Subs-Id>]/resourceGroups/[<ResGrp-Id>]/providers/Microsoft.Compute/hostGroups/[<HostGroup>] is invalid."  
              }
    
  3. Si le quota pour le groupe hôte n’est pas suffisant, l’erreur suivante est levée :
          {  
                "code": "QuotaExceeded",  
                "message": "Operation could not be completed as it results in exceeding approved standardDSv3Family Cores quota.  
          Additional Required: 320, (Minimum) New Limit Required: 320. Submit a request for Quota increase [here](https://aka.ms/ProdportalCRP/#blade/Microsoft_Azure_Capacity/UsageAndQuota.ReactView/Parameters/). Please read more about quota limits [here](/azure/azure-supportability/per-vm-quota-requests)” 
              }
    

Étapes suivantes