DNS service in Azure Service Fabric

Il servizio DNS è un servizio di sistema facoltativo che è possibile abilitare nel cluster per individuare altri servizi usando il protocollo DNS.

Molti servizi, in particolare quelli in contenitore, sono indirizzabili tramite un URL preesistente. È preferibile poterli risolvere mediante il protocollo DNS standard, anziché mediante il protocollo Service Fabric Naming Service. Il servizio DNS consente di eseguire il mapping dei nomi DNS a un nome di servizio e quindi risolvere gli indirizzi IP dell'endpoint. Tali funzionalità mantengono la portabilità dei servizi in contenitori in piattaforme diverse e possono semplificare gli scenari di trasferimento in modalità lift-and-shift, consentendo di usare gli URL del servizio esistenti anziché riscrivere il codice per usare il servizio di denominazione.

Il servizio DNS esegue il mapping dei nomi DNS ai nomi dei servizi, che a sua volta vengono risolti dal servizio di denominazione per restituire l'endpoint del servizio. Il nome DNS per il servizio viene fornito al momento della creazione. Il diagramma seguente illustra il funzionamento del servizio DNS per i servizi senza stato. Per brevità, i diagrammi mostrano un solo endpoint per i servizi, anche se ogni servizio può avere più endpoint.

Diagramma che mostra come viene eseguito il mapping dei nomi DNS ai nomi dei servizi in base al servizio DNS per i servizi senza stato.

A partire da Service Fabric versione 6.3, il protocollo DNS di Service Fabric è stato esteso per includere uno schema di indirizzamento dei servizi con stato partizionati. Queste estensioni consentono di risolvere specifici indirizzi IP delle partizioni usando una combinazione del nome DNS del servizio con stato e il nome della partizione. Sono supportati tutti e tre gli schemi di partizione:

  • Partizionamento denominato
  • Partizionamento per intervalli
  • Partizionamento singleton

Il diagramma seguente illustra il funzionamento del servizio DNS per i servizi con stato partizionato.

Diagramma che mostra il mapping dei nomi DNS ai nomi dei servizi in base al servizio DNS per i servizi con stato partizionato.

Per altre informazioni sulle query partizionate, vedere la sezione seguente.

Sistemi operativi supportati

Il servizio DNS è supportato sia nei cluster Windows che in Linux, anche se il supporto per Linux è attualmente limitato ai servizi in contenitori e non può essere abilitato tramite portale di Azure. Windows, tuttavia, supporta tutti i tipi di servizio e i modelli di distribuzione.

Abilitazione del servizio DNS

Nota

L'abilitazione del servizio DNS sostituirà alcune impostazioni DNS nei nodi. Se si verificano problemi di connessione a Internet, controllare le impostazioni DNS.

Nuovi cluster

Cluster che usano modelli di Resource Manager

Per distribuire un nuovo cluster con i modelli di Resource Manager, è possibile usare i modelli di esempio o scrivere i propri. Se non è già stato fatto, il servizio DNS può essere abilitato nei modelli usando le versioni API minime supportate e aggiungendo le impostazioni appropriate. I dettagli su come eseguire questa operazione possono essere visualizzati di seguito nei punti 1 e 2 dell'elenco numerato.

Cluster che usano portale di Azure

Se si crea un cluster standard nel portale, il servizio DNS è abilitato per impostazione predefinita nell'opzione Includi servizio DNS nella sezione Aggiungi funzionalità .

Screenshot dell'abilitazione del servizio DNS per un cluster standard tramite il portale.

Se si crea un cluster gestito nel portale, il servizio DNS è abilitato per impostazione predefinita nell'opzione servizio DNS nella sezione Aggiungi funzionalità .

Screenshot dell'abilitazione del servizio DNS per un cluster gestito tramite il portale.

Cluster esistenti

Se si aggiorna un cluster gestito esistente per abilitare il servizio DNS, è possibile farlo dal portale visitando la pagina Servizi aggiuntivi dalla pagina delle risorse cluster. In caso contrario, è possibile abilitare il servizio DNS usando metodi alternativi a cui si fa riferimento di seguito:

  • Usare il modello di Resource Manager usato per distribuire il cluster, se applicabile.
  • Passare al cluster in Esplora risorse di Azure e aggiornare la risorsa cluster, come illustrato nei passaggi successivi (dal passaggio 2 e versioni successive).
  • Passare al cluster nel portale e fare clic su Esporta modello. Per maggiori informazioni, vedere Esportare il modello da un gruppo di risorse.

Dopo aver creato un modello, è possibile abilitare il servizio DNS seguendo questa procedura:

  1. Per i cluster standard, verificare che sia apiVersion impostato su 2017-07-01-preview o versione successiva per la Microsoft.ServiceFabric/clusters risorsa e, in caso contrario, aggiornarlo come illustrato nell'esempio seguente:

    {
        "apiVersion": "2017-07-01-preview",
        "type": "Microsoft.ServiceFabric/clusters",
        "name": "[parameters('clusterName')]",
        "location": "[parameters('clusterLocation')]",
        ...
    }
    

    Per i cluster gestiti, verificare che sia apiVersion impostato su 2020-01-01-preview o versione successiva per la Microsoft.ServiceFabric/managedClusters risorsa e, in caso contrario, aggiornarlo come illustrato nell'esempio seguente:

    {
        "apiVersion": "2020-01-01-preview",
        "type": "Microsoft.ServiceFabric/managedClusters",
        "name": "[parameters('clusterName')]",
        "location": "[parameters('clusterLocation')]",
        ...
    }
    
  2. Abilitare ora il servizio DNS in uno dei modi seguenti:

    • Per abilitare il servizio DNS con le impostazioni predefinite, aggiungerlo alla addonFeatures sezione all'interno della properties sezione come illustrato nell'esempio seguente:

      "properties": {
        ...
        "addonFeatures": [
          "DnsService"
          ],
        ...
      }
      
    • Per abilitare il servizio con impostazioni diverse da quelle predefinite, aggiungere una sezione DnsService alla sezione fabricSettings all'interno della sezione properties. In questo caso, non è necessario aggiungere DnsService a addonFeatures. Per altre informazioni sulle proprietà che possono essere impostate per il servizio DNS, vedere Impostazioni del servizio DNS.

      "properties": {
       ...
       "fabricSettings": [
         ...
         {
           "name": "DnsService",
           "parameters": [
             {
               "name": "IsEnabled",
               "value": "true"
             },
             {
               "name": "<key>",
               "value": "<value>"
             }
           ]
         },
         ...
       ]
      }
      
  3. Dopo avere aggiornato il modello di cluster con le modifiche, applicarle e consentire il completamento dell'aggiornamento. Al termine dell'aggiornamento, il servizio di sistema DNS viene avviato nel cluster. Il nome del servizio è fabric:/System/DnsService, e sarà possibile trovarlo nella sezione Sistema del servizio in Service Fabric Explorer.

Nota

Quando si aggiorna DNS da disabilitato a abilitato, Service Fabric Explorer potrebbe non riflettere il nuovo stato. Per risolvere il problema, riavviare i nodi modificando i criteri di aggiornamento nel modello.

Impostazione del nome DNS del servizio

È possibile impostare i nomi DNS per i servizi con i modelli di Resource Manager, con i servizi predefiniti nel file ApplicationManifest.xml o con i comandi di PowerShell.

Il nome DNS per il servizio è risolvibile in tutto il cluster, quindi è importante garantire l'univocità del nome DNS nel cluster.

È consigliabile utilizzare uno schema di denominazione <ServiceName>.<AppName>, ad esempio service1.application1. Se un'applicazione viene distribuita usando Docker Compose, i nomi DNS vengono automaticamente assegnati ai servizi utilizzando questo schema di denominazione.

Impostazione del nome DNS con il modello di Resource Manager

Se si usano modelli di Resource Manager per distribuire i servizi, è possibile aggiungere la serviceDnsName proprietà alla sezione appropriata e assegnarvi un valore. Di seguito sono riportati esempi:

Cluster standard

Per i cluster standard, verificare che sia apiVersion impostato su 2019-11-01-preview o versione successiva per la Microsoft.ServiceFabric/clusters/applications/services risorsa e, in caso contrario, aggiornarlo come illustrato nell'esempio seguente:

{
  "apiVersion": "2019-11-01-preview",
  "type": "Microsoft.ServiceFabric/clusters/applications/services",
  "name": "[concat(parameters('clusterName'), '/', parameters('applicationName'), '/', parameters('serviceName'))]",
  "location": "[variables('clusterLocation')]",
  "dependsOn": [
    "[concat('Microsoft.ServiceFabric/clusters/', parameters('clusterName'), '/applications/', parameters('applicationName'))]"
  ],
  "properties": {
    "provisioningState": "Default",
    "serviceKind": "Stateless",
    "serviceTypeName": "[parameters('serviceTypeName')]",
    "instanceCount": "-1",
    "partitionDescription": {
      "partitionScheme": "Singleton"
    },
    "correlationScheme": [],
    "serviceLoadMetrics": [],
    "servicePlacementPolicies": [],
    "serviceDnsName": "[parameters('serviceDnsName')]"
  }
}

Cluster gestiti

Per i cluster gestiti, verificare che sia apiVersion impostato su 2022-10-01-preview o versione successiva per la Microsoft.ServiceFabric/managedclusters/applications/services risorsa e, in caso contrario, aggiornarlo come illustrato nell'esempio seguente:

{
  "apiVersion": "2022-10-01-preview",
  "type": "Microsoft.ServiceFabric/managedclusters/applications/services",
  "name": "[concat(parameters('clusterName'), '/', parameters('applicationName'), '/', parameters('serviceName'))]",
  "location": "[variables('clusterLocation')]",
  "dependsOn": [
    "[concat('Microsoft.ServiceFabric/managedclusters/', parameters('clusterName'), '/applications/', parameters('applicationName'))]"
  ],
  "properties": {
    "serviceKind": "Stateless",
    "serviceTypeName": "[parameters('serviceTypeName')]",
    "instanceCount": "-1",
    "partitionDescription": {
      "partitionScheme": "Singleton"
    },
    "correlationScheme": [],
    "serviceLoadMetrics": [],
    "servicePlacementPolicies": [],
    "serviceDnsName": "[parameters('serviceDnsName')]"
  }
}

Impostazione del nome DNS per un servizio predefinito nel file ApplicationManifest.xml

Aprire il progetto in Visual Studio o nell'editor preferito, quindi aprire il file ApplicationManifest.xml. Passare alla sezione relativa ai servizi predefiniti e per ciascuno di esso aggiungere l'attributo ServiceDnsName. Nell'esempio seguente viene mostrato come impostare il nome DNS del servizio su stateless1.application1

<Service Name="Stateless1" ServiceDnsName="stateless1.application1">
  <StatelessService ServiceTypeName="Stateless1Type" InstanceCount="[Stateless1_InstanceCount]">
    <SingletonPartition />
  </StatelessService>
</Service>

Nell'esempio seguente il nome DNS per un servizio con stato viene impostato su stateful1.application1. Il servizio usa uno schema di partizionamento denominato. Si noti che i nomi di partizioni sono in minuscolo. Questo è un requisito per le partizioni che verranno usate come destinazione nelle query DNS; per altre informazioni, vedere Effettuare query DNS su una partizione del servizio con stato.

<Service Name="Stateful1" ServiceDnsName="stateful1.application1" />
  <StatefulService ServiceTypeName="Stateful1Type" TargetReplicaSetSize="2" MinReplicaSetSize="2">
    <NamedPartition>
      <Partition Name="partition1" />
      <Partition Name="partition2" />
    </NamedPartition>
  </StatefulService>
</Service>

Impostazione del nome DNS per un servizio con PowerShell

È possibile impostare il nome DNS per un servizio durante la creazione tramite il New-ServiceFabricService comando di PowerShell. L'esempio seguente crea un nuovo servizio senza stato con il nome stateless1.application1DNS :

New-ServiceFabricService `
    -Stateless `
    -PartitionSchemeSingleton `
    -ApplicationName fabric:/application1 `
    -ServiceName fabric:/application1/stateless1 `
    -ServiceTypeName Stateless1Type `
    -InstanceCount 1 `
    -ServiceDnsName stateless1.application1

È anche possibile aggiornare un servizio esistente usando il Update-ServiceFabricService comando di PowerShell. Nell'esempio seguente viene aggiornato un servizio senza stato esistente per aggiungere il nome stateless1.application1DNS :

Update-ServiceFabricService `
    -Stateless `
    -ServiceName fabric:/application1/stateless1 `
    -ServiceDnsName stateless1.application1

Verificare che un nome DNS sia impostato in Service Fabric Explorer

Dopo aver distribuito il servizio con il nome DNS, Service Fabric Explorer mostrerà il nome DNS per il servizio, come illustrato nella figura seguente:

Screenshot del nome DNS in Service Fabric Explorer.

Nota

Questa visualizzazione può essere diversa a seconda della versione di Service Fabric Explorer usata, ma il campo del nome DNS deve essere visibile in qualche modulo nella pagina del servizio.

Effettuare query DNS su una partizione del servizio con stato

A partire dalla versione 6.3 di Service Fabric, il servizio DNS supporta le query per le partizioni del servizio. Per abilitare il supporto per le query del servizio partizionato, è necessario aggiornare le impostazioni del servizio DNS per impostare l'opzione EnablePartitionedQuery su true.

Per le partizioni che verranno usate nelle query DNS, si applicano le restrizioni di denominazione seguenti:

  • I nomi di partizioni devono essere compatibili con il servizio DNS.
  • I nomi di partizione con più etichette, tra cui punto o '.' non devono essere usati.
  • I nomi di partizioni devono essere in minuscolo.

Le query DNS che usano come destinazione una partizione vengono formattate come indicato di seguito:

    <First-Label-Of-Partitioned-Service-DNSName><PartitionPrefix><Target-Partition-Name><PartitionSuffix>.<Remaining-Partitioned-Service-DNSName>

Dove:

  • First-Label-Of-Partitioned-Service-DNSName è la prima parte del nome DNS del servizio.
  • PartitionPrefix è un valore che può essere impostato nella sezione DnsService del manifesto del cluster o tramite il modello arm del cluster. Il valore predefinito è "--". Per altre informazioni, vedere Impostazioni del servizio DNS.
  • Target-Partition-Name è il nome della partizione.
  • PartitionSuffix è un valore che può essere impostato nella sezione DnsService del manifesto del cluster o tramite il modello arm del cluster. Il valore predefinito è una stringa vuota. Per altre informazioni, vedere Impostazioni del servizio DNS.
  • Remaining-Partitioned-Service-DNSName è la parte rimanente del nome DNS del servizio.

Gli esempi seguenti illustrano le query DNS per i servizi partizionati in esecuzione in un cluster con impostazioni predefinite per PartitionPrefix e PartitionSuffix:

  • Per risolvere la partizione "0" di un servizio con nome backendrangedschemesvc.application DNS che usa uno schema di partizionamento a intervalli, usare backendrangedschemesvc--0.application.
  • Per risolvere la partizione "first" di un servizio con nome backendnamedschemesvc.application DNS che usa uno schema di partizionamento denominato, usare backendnamedschemesvc--first.application.

Il servizio DNS restituisce l'indirizzo IP dell'endpoint associato alla replica primaria della partizione. Se non viene specificata alcuna partizione, il servizio DNS selezionerà in modo casuale una partizione.

Uso dei nomi DNS nei servizi

Se si distribuiscono servizi con nomi DNS, è possibile trovare l'indirizzo IP degli endpoint esposti facendo riferimento al nome DNS. Il servizio DNS funziona per i servizi senza stato e, in Service Fabric versione 6.3 e versioni successive, per i servizi con stato. Per i servizi con stato in esecuzione nelle versioni di Service Fabric precedenti alla versione 6.3, è possibile usare il servizio proxy inverso predefinito per le chiamate HTTP per chiamare una determinata partizione del servizio.

Le porte dinamiche non sono supportate dal servizio DNS. Per risolvere i servizi su porte dinamiche, è possibile usare il servizio proxy inverso.

Il codice seguente illustra come chiamare un servizio senza stato tramite DNS. È semplicemente una normale chiamata HTTP in cui si specifica il nome DNS, la porta e qualsiasi percorso facoltativo come parte dell'URL.

public class ValuesController : Controller
{
    // GET api
    [HttpGet]
    public async Task<string> Get()
    {
        string result = "";
        try
        {
            Uri uri = new Uri("http://stateless1.application1:8080/api/values");
            HttpClient client = new HttpClient();
            var response = await client.GetAsync(uri);
            result = await response.Content.ReadAsStringAsync();

        }
        catch (Exception e)
        {
            Console.Write(e.Message);
        }

        return result;
    }
}

Il codice seguente mostra una chiamata su una partizione specifica di un servizio con stato. In questo caso, il nome DNS contiene il nome della partizione (partition1). La chiamata presuppone un cluster con i valori predefiniti per PartitionPrefix e PartitionSuffix.

public class ValuesController : Controller
{
    // GET api
    [HttpGet]
    public async Task<string> Get()
    {
        string result = "";
        try
        {
            Uri uri = new Uri("http://stateful1--partition1.application1:8080/api/values");
            HttpClient client = new HttpClient();
            var response = await client.GetAsync(uri);
            result = await response.Content.ReadAsStringAsync();

        }
        catch (Exception e)
        {
            Console.Write(e.Message);
        }

        return result;
    }
}

Query ricorsive

Per i nomi DNS che il servizio DNS non può risolvere autonomamente (ad esempio, un nome DNS pubblico), la query verrà inoltrata ai server DNS ricorsivi preesistenti nei nodi.

Diagramma che mostra come vengono risolte le query DNS per i nomi pubblici.

Prima di Service Fabric 9.0, questi server sono stati sottoposti a query serialmente fino a quando non è stata ricevuta una risposta, con un periodo di timeout fisso di 5 secondi tra. Se un server non ha risposto entro il periodo di timeout, il server successivo (se disponibile) verrà sottoposto a query. Nel caso in cui questi server DNS riscontrassero problemi, il completamento delle query DNS richiederebbe più di 5 secondi, che non è ideale.

A partire da Service Fabric 9.0, è stato aggiunto il supporto per le query ricorsive parallele. Con le query parallele, tutti i server DNS ricorsivi possono essere contattati contemporaneamente, in cui la prima risposta vince. Ciò comporta risposte più rapide nello scenario indicato in precedenza. Questa opzione non è abilitata per impostazione predefinita.

Le opzioni con granularità fine vengono introdotte anche in Service Fabric 9.0 per controllare il comportamento delle query ricorsive, inclusi i periodi di timeout e i tentativi di query. Queste opzioni possono essere impostate nelle impostazioni del servizio DNS:

  • RicorsivoQuerySerialMaxAttempts - Numero di query seriali che verranno tentate, al massimo. Se questo numero è superiore al numero di server DNS di inoltro, l'esecuzione di query si arresterà una volta che tutti i server sono stati tentati esattamente una volta.
  • RecursiveQuerySerialTimeout : valore di timeout in secondi per ogni query seriale tentata.
  • RicorsivoQueryParallelMaxAttempts : il numero di volte in cui verranno tentate query parallele. Le query parallele vengono eseguite dopo l'esaurimento dei tentativi massimi per le query seriali.
  • RicorsivoQueryParallelTimeout : valore di timeout in secondi per ogni query parallela tentata.

Limitazioni e problemi noti

  • Le porte dinamiche non sono supportate dal servizio DNS. Per risolvere i servizi esposti su porte dinamiche, usare il servizio proxy inverso.
  • Il supporto per Linux è attualmente limitato ai servizi in contenitori. I servizi basati sul processo in Linux attualmente non possono usare il servizio DNS.
  • Il servizio DNS per i cluster Linux non può essere abilitato tramite portale di Azure.
  • Se un nome DNS viene modificato per un servizio, gli aggiornamenti dei nomi potrebbero non essere immediatamente visibili in alcuni scenari. Per risolvere il problema, è necessario riavviare le istanze del servizio DNS nel cluster.

Passaggi successivi

Altre informazioni sulla comunicazione del servizio all'interno del cluster con connessione e comunicazione con i servizi