Probe di Service Fabric

  • Articolo

Prima di procedere con questo articolo, acquisire familiarità con il modello di applicazione di Service Fabric e il modello di hosting di Service Fabric. Questo articolo offre una panoramica di come definire un probe di attività e idoneità usando i file manifesto.

Probe di attività

A partire dalla versione 7.1, Azure Service Fabric supporta un meccanismo di probe di attività per le applicazioni in contenitori e non in contenitori. Un probe di attività consente di segnalare la dinamica di un pacchetto di codice, che verrà riavviato se non risponde rapidamente.

Probe di idoneità

A partire dalla versione 8.2, è supportato anche il probe di idoneità. Un probe di idoneità viene usato per decidere se un pacchetto di codice è pronto per accettare il traffico. Ad esempio, se il contenitore richiede molto tempo per elaborare la richiesta o se la coda delle richieste è piena, il pacchetto di codice non può più accettare traffico e quindi gli endpoint per raggiungere il pacchetto di codice verranno rimossi.

Il comportamento del probe di idoneità è:

  1. Viene avviata l'istanza del pacchetto contenitore/codice
  2. Gli endpoint vengono pubblicati immediatamente
  3. Probe di idoneità avvia l'esecuzione
  4. Probe di conformità raggiunge infine la soglia di errore e l'endpoint viene rimosso rendendolo non disponibile
  5. L'istanza diventa infine pronta
  6. Probe di idoneità nota che l'istanza è pronta e pubblica di nuovo l'endpoint
  7. Le richieste vengono indirizzate di nuovo e hanno esito positivo perché è pronto per gestire le richieste

Nota

Per il probe di idoneità, il pacchetto di codice non viene riavviato, solo gli endpoint non vengono pubblicati in modo che il set di repliche/partizione non sia interessato.

semantica

È possibile specificare una sola attività e un probe di idoneità per ogni pacchetto di codice e controllarne il comportamento usando questi campi:

  • type: usato per specificare se il tipo di probe è Liveness o Readiness. I valori supportati sono Liveness o Readiness

  • initialDelaySeconds: ritardo iniziale in secondi per avviare l'esecuzione del probe dopo l'avvio del contenitore. Il valore supportato è int. Il valore predefinito è 0 e il valore minimo è 0.

  • timeoutSeconds: periodo in secondi dopo il quale si considera il probe come non riuscito, se non è stato completato correttamente. Il valore supportato è int. Il valore predefinito è 1 e il valore minimo è 1.

  • periodSeconds: periodo in secondi per specificare la frequenza del probe. Il valore supportato è int. Il valore predefinito è 10 e il valore minimo è 1.

  • failureThreshold: quando si raggiunge questo valore, il contenitore verrà riavviato. Il valore supportato è int. Il valore predefinito è 3 e il valore minimo è 1.

  • successThreshold: in caso di errore, affinché il probe venga considerato riuscito, deve essere eseguito correttamente per questo valore. Il valore supportato è int. Il valore predefinito è 1 e il valore minimo è 1.

Al massimo può essere presente un probe a un contenitore in qualsiasi momento. Se il probe non termina nel tempo impostato in timeoutSeconds, attendere e contare il tempo verso failureThreshold.

Service Fabric genererà anche i report di integrità del probe seguenti in DeployServicePackage:

  • OK: il probe ha esito positivo per il valore impostato in successThreshold.

  • Error: errore probeCount == failureThreshold, prima del riavvio del contenitore.

  • Warning:

    • Il probe ha esito negativo e failureCount<failureThreshold. Questo report sull'integrità rimane finché failureCount non raggiunge il valore impostato in failureThreshold o successThreshold.
    • In caso di esito positivo dopo l'esito negativo, l'avviso rimane ma con risultati consecutivi aggiornati.

Specifica di un probe

È possibile specificare un probe nel file ApplicationManifest.xml in ServiceManifestImport.

Il probe può essere per uno dei seguenti:

  • HTTP
  • TCP
  • Exec

Probe HTTP

Per un probe HTTP, Service Fabric invierà una richiesta HTTP alla porta e al percorso specificato. Un codice restituito maggiore o uguale a 200 e minore di 400 indica l'esito positivo.

Di seguito è riportato un esempio di come specificare un probe http liveness:

  <ServiceManifestImport>
    <ServiceManifestRef ServiceManifestName="Stateless1Pkg" ServiceManifestVersion="1.0.0" />
    <ConfigOverrides />
    <Policies>
      <CodePackagePolicy CodePackageRef="Code">
        <Probes>
          <Probe Type="Liveness" FailureThreshold="5" SuccessThreshold="2" InitialDelaySeconds="10" PeriodSeconds="30" TimeoutSeconds="20">
            <HttpGet Path="/" Port="8081" Scheme="http">
              <HttpHeader Name="Foo" Value="Val"/>
              <HttpHeader Name="Bar" Value="val1"/>
            </HttpGet>
          </Probe>
        </Probes>
      </CodePackagePolicy>
    </Policies>
  </ServiceManifestImport>

Il probe HTTP include proprietà aggiuntive che è possibile impostare:

  • path: percorso da usare nella richiesta HTTP.

  • port: porta da usare per i probe. Questa proprietà è obbligatoria. L'intervallo è compreso tra 1 e 65535.

  • scheme: schema da usare per la connessione al pacchetto di codice. Se questa proprietà è impostata su HTTPS, la verifica del certificato viene ignorata. L'impostazione predefinita è HTTP.

  • httpHeader: intestazioni da impostare nella richiesta. È possibile specificare più intestazioni.

  • host: indirizzo IP host a cui connettersi.

Nota

La porta e lo schema non sono supportati per le applicazioni non incluse in contenitori. Per questo scenario, usare l'attributo EndpointRef="EndpointName". Sostituire 'EndpointName' con il nome dell'endpoint definito in ServiceManifest.xml.

Probe TCP

Per un probe TCP, Service Fabric tenterà di aprire un socket nel contenitore usando la porta specificata. Se è in grado di stabilire una connessione, il probe viene considerato riuscito. Ecco un esempio di come specificare un probe che usa un socket TCP:

  <ServiceManifestImport>
    <ServiceManifestRef ServiceManifestName="Stateless1Pkg" ServiceManifestVersion="1.0.0" />
    <ConfigOverrides />
    <Policies>
      <CodePackagePolicy CodePackageRef="Code">
        <Probes>
          <Probe Type="Liveness" FailureThreshold="5" SuccessThreshold="2" InitialDelaySeconds="10" PeriodSeconds="30" TimeoutSeconds="20">
            <TcpSocket Port="8081"/>
          </Probe>
        </Probes>
      </CodePackagePolicy>
    </Policies>
  </ServiceManifestImport>

Probe Exec

Questo probe eseguirà un comando exec nel contenitore e attenderà il completamento del comando.

Nota

Il comando Exec accetta una stringa delimitata da virgole. Il comando nell'esempio seguente funzionerà per un contenitore Linux. Se si sta provando a eseguire il probe di un contenitore di Windows, usare cmd.

  <ServiceManifestImport>
    <ServiceManifestRef ServiceManifestName="Stateless1Pkg" ServiceManifestVersion="1.0.0" />
    <ConfigOverrides />
    <Policies>
      <CodePackagePolicy CodePackageRef="Code">
        <Probes>
          <Probe Type="Liveness" FailureThreshold="5" SuccessThreshold="2" InitialDelaySeconds="10" PeriodSeconds="30" TimeoutSeconds="20">
            <Exec>
              <Command>ping,-c,2,localhost</Command>
            </Exec>
          </Probe>        
       </Probes>
      </CodePackagePolicy>
    </Policies>
  </ServiceManifestImport>

Passaggi successivi

Per informazioni correlate, vedere l'articolo seguente: