Pianificare e preparare la distribuzione del cluster autonomo di Service Fabric

Eseguire i passaggi seguenti prima di creare il cluster.

Pianificare l'infrastruttura del cluster

Si sta per creare un cluster di Service Fabric nei computer di cui si è proprietari, quindi è possibile decidere quali tipi di errori si vuole che il cluster superi. Ad esempio, sono necessarie linee di alimentazione separate o connessioni Internet fornite a questi computer? Si consideri anche la sicurezza fisica di questi computer. Dove si trovano i computer e chi deve accedervi? Dopo aver prese queste decisioni, è possibile eseguire il mapping logico dei computer a vari domini di errore (vedere il passaggio successivo). La pianificazione dell'infrastruttura per i cluster di produzione è più complessa rispetto a quella per i cluster di test.

Determinare il numero di domini di errore e domini di aggiornamento

Un dominio di errore (FD) è un'unità fisica di errore ed è direttamente correlata all'infrastruttura fisica nei data center. Un dominio di errore è costituito da componenti hardware (computer, commutatori, reti e altro ancora) che condividono un singolo punto di guasto. Anche se non esiste alcun mapping 1:1 tra domini di errore e rack, in termini generali, ogni rack può essere considerato un dominio di errore.

Quando si specificano i domini di dominio in ClusterConfig.json, è possibile scegliere il nome per ogni fd. Service Fabric supporta i domini di dominio gerarchici, in modo da poter riflettere la topologia dell'infrastruttura. Di seguito sono riportati esempi di domini di errore validi:

  • "faultDomain": "fd:/Room1/Rack1/Machine1"
  • "faultDomain": "fd:/FD1"
  • "faultDomain": "fd:/Room1/Rack1/PDU1/M1"

Un dominio di aggiornamento è un'unità logica di nodi. Durante gli aggiornamenti orchestrati di Service Fabric (sia un aggiornamento di un'applicazione che un aggiornamento del cluster), tutti i nodi in un dominio di aggiornamento vengono disattivati per eseguire l'aggiornamento, mentre i nodi in altri domini di aggiornamento rimangono disponibili per la gestione delle richieste. Gli aggiornamenti del firmware eseguiti sulle macchine non rispettano gli UD, quindi è necessario eseguirli una alla volta.

Il modo più semplice per considerare questi concetti è pensare agli FD come unità di guasto non pianificato e agli UD come unità di manutenzione pianificata.

Quando si specificano gli ID in ClusterConfig.json, è possibile scegliere il nome per ogni UD. Ad esempio, i nomi seguenti sono validi:

  • "upgradeDomain": "UD0"
  • "upgradeDomain": "UD1A"
  • "upgradeDomain": "DomainRed"
  • "upgradeDomain": "Blue"

Per informazioni più dettagliate su domini di dominio e id utente, vedere Descrizione di un cluster di Service Fabric.

Un cluster nell'ambiente di produzione deve estendersi su almeno tre domini di dominio per essere supportato in un ambiente di produzione, se si ha il controllo completo sulla manutenzione e sulla gestione dei nodi, ovvero si è responsabili dell'aggiornamento e della sostituzione dei computer. Per i cluster in esecuzione in ambienti (ad esempio istanze di macchine virtuali di Amazon Web Services) in cui non si ha il pieno controllo sui computer, è necessario avere almeno cinque domini di errore nel cluster. Ogni fd può avere uno o più nodi. Ciò consente di evitare problemi causati da aggiornamenti e aggiornamenti del computer, che a seconda dei tempi, possono interferire con l'esecuzione di applicazioni e servizi nei cluster.

Determinare le dimensioni iniziali del cluster

In genere, il numero di nodi nel cluster viene determinato in base alle esigenze aziendali, ovvero il numero di servizi e contenitori in esecuzione nel cluster e il numero di risorse necessarie per sostenere i carichi di lavoro. Nei cluster di produzione è consigliabile configurare almeno cinque nodi, estesi su cinque domini di errore. Tuttavia, come descritto prima, se si ha il controllo completo sui nodi e un'estensione su almeno tre domini di errore, tre nodi possono essere sufficienti.

I cluster di test che eseguono carichi di lavoro con stato devono avere tre nodi, mentre i cluster di test che eseguono solo carichi di lavoro senza stato necessitano di un solo nodo. Si noti anche che a scopo di sviluppo è possibile avere più di un nodo in un determinato computer. In un ambiente di produzione, tuttavia, Service Fabric supporta un solo nodo per macchina fisica o virtuale.

Preparare i computer che fungeranno da nodi

Di seguito sono riportate le specifiche consigliate per i computer in un cluster di Service Fabric:

  • Almeno 16 GB di RAM
  • Almeno 40 GB di spazio disponibile su disco
  • Cpu a 4 core o superiore
  • Connettività a una rete o a reti sicure per tutti i computer
  • Sistema operativo Windows Server installato (versioni valide: 2012 R2, 2016, 1709 o 1803). Service Fabric versione 6.4.654.9590 e successive supporta anche Server 2019 e 1809.
  • .NET Framework 4.5.1 o versione successiva, installazione completa
  • Windows PowerShell 3.0
  • Il servizio RemoteRegistry deve essere in esecuzione in tutti i computer
  • L'unità di installazione di Service Fabric deve essere NTFS File System
  • I log delle prestazioni e gli avvisi dei servizi windows e il registro eventi di Windows devono essere abilitati.
  • Il controllo dell'account utente remoto deve essere disabilitato

Importante

L'amministratore del cluster che distribuisce e configura il cluster deve disporre dei privilegi di amministratore per ogni computer. Non è possibile installare Service Fabric in un controller di dominio.

Scaricare il pacchetto autonomo di Service Fabric per Windows Server

Collegamento per il download - Pacchetto autonomo di Service Fabric - Windows Server e decompressione del pacchetto, sia su un server di distribuzione che non fa parte del cluster, sia su uno dei server che saranno parte del tuo cluster.

Modificare la configurazione del cluster

Per creare un cluster autonomo è necessario creare un file di configurazione del cluster autonomo ClusterConfig.json, che descrive la specifica del cluster. È possibile basare il file di configurazione sui modelli disponibili nel collegamento seguente.
Configurazioni del cluster autonomo

Per informazioni dettagliate sulle sezioni di questo file, vedere Impostazioni di configurazione per il cluster Windows autonomo.

Aprire uno dei file ClusterConfig.json dal pacchetto scaricato e modificare le impostazioni seguenti:

Impostazione di configurazione Descrizione
NodeTypes I tipi di nodo consentono di separare i nodi del cluster in vari gruppi. Un cluster deve avere almeno un NodeType. Tutti i nodi di un gruppo presentano le caratteristiche comuni seguenti:
Name : nome del tipo di nodo.
Porte di endpoint: endpoint denominati (porte) associati a questo tipo di nodo. È possibile usare qualsiasi numero di porta desiderato, purché non siano in conflitto con altri elementi in questo manifesto e non siano già in uso da altre applicazioni in esecuzione nel computer o nella macchina virtuale.
Proprietà di posizionamento : descrivono le proprietà per questo tipo di nodo usato come vincoli di posizionamento per i servizi di sistema o i servizi. Queste proprietà sono coppie chiave/valore definite dall'utente che forniscono metadati aggiuntivi per un determinato nodo. Esempi di proprietà dei nodi sono se il nodo ha un disco rigido o una scheda grafica, il numero di spindle nel disco rigido, nei core e in altre proprietà fisiche.
Capacità: le capacità del nodo definiscono il nome e la quantità di una determinata risorsa disponibile per l'utilizzo di un determinato nodo. Ad esempio, un nodo può definire che ha capacità per una metrica denominata "MemoryInMb" e che dispone di 2048 MB disponibili per impostazione predefinita. Queste capacità vengono usate in fase di esecuzione per garantire che i servizi che richiedono particolari quantità di risorse vengano posizionati nei nodi con tali risorse disponibili negli importi necessari.
IsPrimary : se sono stati definiti più nodi NodeType, assicurarsi che solo uno sia impostato su primario con il valore true, ovvero dove vengono eseguiti i servizi di sistema. Tutti gli altri tipi di nodo devono essere impostati sul valore false
Nodes Questi sono i dettagli per ognuno dei nodi che fanno parte del cluster (tipo di nodo, nome del nodo, indirizzo IP, dominio di errore e dominio di aggiornamento del nodo). I computer in cui si vuole creare il cluster devono essere elencati qui con i relativi indirizzi IP.
Se si usa lo stesso indirizzo IP per tutti i nodi, viene creato un cluster con una casella, che è possibile usare per scopi di test. Non usare cluster di una casella per la distribuzione dei carichi di lavoro di produzione.

Dopo aver configurato tutte le impostazioni per l'ambiente, la configurazione del cluster può essere testata nell'ambiente cluster (passaggio 7).

Configurazione dell'ambiente

Quando un amministratore del cluster configura un cluster autonomo di Service Fabric, l'ambiente deve essere configurato con i criteri seguenti:

  1. L'utente che crea il cluster deve disporre dei privilegi di sicurezza a livello di amministratore per tutti i computer elencati come nodi nel file di configurazione del cluster.

  2. Il computer da cui viene creato il cluster e ogni computer del nodo del cluster devono rispettare i requisiti seguenti:

    • Avere disinstallato Service Fabric SDK
    • Avere disinstallato il runtime di Service Fabric
    • Abilitare il servizio Windows Firewall (mpssvc)
    • Abilitare il servizio Registro di sistema remoto (Registro di sistema remoto)
    • Abilitare la condivisione file (SMB)
    • Aprire le porte necessarie, in base alle porte di configurazione del cluster
    • Disporre delle porte necessarie aperte per il servizio Registro di sistema remoto e SMB di Windows: 135, 137, 138, 139 e 445
    • Essere connessi in rete tra loro

  3. Nessuno dei computer dei nodi del cluster deve essere un controller di dominio.

  4. Se il cluster da distribuire è un cluster sicuro, verificare che siano soddisfatti i prerequisiti di sicurezza necessari e che siano configurati correttamente in base alla configurazione.

  5. Se i computer del cluster non sono accessibili da Internet, impostare quanto segue nella configurazione del cluster:

    • Disabilitare la telemetria: in properties impostare "enableTelemetry": false
    • Disabilitare il download automatico della versione di Fabric e le notifiche che la versione corrente del cluster sta per raggiungere la fine del supporto: in Proprietà impostare "fabricClusterAutoupgradeEnabled": false
    • In alternativa, se l'accesso a Internet di rete è limitato ai domini elencati, i domini seguenti sono necessari per l'aggiornamento automatico: go.microsoft.com download.microsoft.com

  6. Impostare le esclusioni appropriate per l'antivirus nel Service Fabric:

Directory escluse dalle scansioni dell'antivirus
Program Files\Microsoft Service Fabric
FabricDataRoot (dalla configurazione del cluster)
FabricLogRoot (dalla configurazione del cluster)
Processi esclusi dall'antivirus
Fabric.exe
FabricHost.exe
FabricInstallerService.exe
FabricSetup.exe
FabricDeployer.exe
ImageBuilder.exe
FabricGateway.exe
FabricDCA.exe
FabricFAS.exe
FabricUOS.exe
FabricRM.exe
FileStoreService.exe

Convalidare l'ambiente usando lo script TestConfiguration

Lo script TestConfiguration.ps1 è disponibile nel pacchetto autonomo. Viene usato come Best Practices Analyzer per convalidare alcuni dei criteri precedenti e deve essere usato come controllo della integrità per verificare se un cluster può essere distribuito in un determinato ambiente. In caso di errore, fare riferimento all'elenco in Configurazione dell'ambiente per la risoluzione dei problemi.

Questo script può essere eseguito in qualsiasi computer con accesso amministratore a tutti i computer elencati come nodi nel file di configurazione del cluster. Il computer in cui viene eseguito questo script non deve far parte del cluster.

PS C:\temp\Microsoft.Azure.ServiceFabric.WindowsServer> .\TestConfiguration.ps1 -ClusterConfigFilePath .\ClusterConfig.Unsecure.DevCluster.json
Trace folder already exists. Traces will be written to existing trace folder: C:\temp\Microsoft.Azure.ServiceFabric.WindowsServer\DeploymentTraces
Running Best Practices Analyzer...
Best Practices Analyzer completed successfully.


LocalAdminPrivilege        : True
IsJsonValid                : True
IsCabValid                 : True
RequiredPortsOpen          : True
RemoteRegistryAvailable    : True
FirewallAvailable          : True
RpcCheckPassed             : True
NoConflictingInstallations : True
FabricInstallable          : True
Passed                     : True

Attualmente questo modulo di test della configurazione non convalida la configurazione di sicurezza, pertanto è necessario eseguire questa operazione in modo indipendente.

Annotazioni

Microsoft sta continuamente apportando miglioramenti per rendere questo modulo più affidabile, quindi se si verifica un caso difettoso o mancante che si ritiene non sia attualmente rilevato da TestConfiguration, segnalarlo tramite i canali di supporto.

Passaggi successivi

  • Last updated on