Rete

Quando si creano e si gestiscono cluster di Azure Service Fabric, si fornisce la connettività di rete per i nodi e le applicazioni. Le risorse di rete includono gli intervalli di indirizzi IP, le reti virtuali, i bilanciamenti del carico e i gruppi di sicurezza di rete. In questo articolo vengono illustrate le procedure consigliate per queste risorse.

Vedere Modelli di rete di Azure Service Fabric per informazioni su come creare cluster che usano le funzionalità seguenti: rete virtuale o subnet esistente, indirizzo IP pubblico statico, servizio di bilanciamento del carico solo interno o servizio di bilanciamento del carico interno ed esterno.

Distribuzione in rete dell'infrastruttura

Ottimizzare le prestazioni della macchina virtuale con la rete accelerata dichiarando la proprietà enableAcceleratedNetworking nel modello di Resource Manager, il frammento di codice seguente è di una rete NetworkInterfaceConfigurations del set di scalabilità di macchine virtuali che abilita la rete accelerata:

"networkInterfaceConfigurations": [
  {
    "name": "[concat(variables('nicName'), '-0')]",
    "properties": {
      "enableAcceleratedNetworking": true,
      "ipConfigurations": [
        {
        <snip>
        }
      ],
      "primary": true
    }
  }
]

È possibile effettuare il provisioning di un cluster di Service Fabric in Linux con rete la accelerata e in Windows con la rete accelerata.

La rete accelerata è supportata per gli SKU della serie di macchine virtuali di Azure: D/DSv2, D/DSv3, E/ESv3, F/FS, FSv2 e Ms/Mms. La rete accelerata è stata testata correttamente usando lo SKU di Standard_DS8_v3 il 23/01/2019 per un cluster Windows di Service Fabric e usando Standard_DS12_v2 il 29/01/2019 per un cluster Linux di Service Fabric. Si noti che la rete accelerata richiede almeno 4 vCPU.

Per abilitare la rete accelerata in un cluster di Service Fabric esistente, è necessario prima ridimensionare un cluster di Service Fabric aggiungendo un set di scalabilità di macchine virtuali per eseguire la procedura seguente:

1. Effettuare il provisioning di un tipo di nodo con la rete accelerata abilitata
2. Eseguire la migrazione dei servizi e del relativo stato nel tipo di nodo sottoposto a provisioning con la rete accelerata abilitata

Per abilitare la rete accelerata in un cluster esistente è necessario ridimensionare l'infrastruttura perché l'abilitazione della rete accelerata genera tempi di inattività, in quanto è necessario arrestare e deallocare tutte le macchine virtuali presenti in un set di disponibilità prima di abilitare la rete accelerata in qualsiasi interfaccia di rete esistente.

Distribuzione in rete dei cluster

• Per distribuire cluster di Service Fabric in una rete virtuale esistente è possibile seguire la procedura descritta in Modelli di rete di Service Fabric.

• I gruppi di sicurezza di rete (NSG) sono consigliati per i tipi di nodo per limitare il traffico in ingresso e in uscita al cluster. Assicurarsi che nel gruppo di sicurezza di rete siano aperte tutte le porte necessarie.

• Il tipo di nodo primario, che contiene i servizi di sistema di Service Fabric non deve essere esposto tramite il servizio di bilanciamento del carico esterno e può essere esposto da un servizio di bilanciamento del carico interno

• Usare un indirizzo IP pubblico statico per il cluster.

Regole di sicurezza di rete

Le regole descritte di seguito sono il minimo consigliato per una configurazione tipica. Sono incluse anche le regole obbligatorie per un cluster operativo se le regole facoltative non sono desiderate. Consente un blocco di sicurezza completo con peering di rete e concetti jumpbox come Azure Bastion. Il mancato apertura delle porte obbligatorie o l'approvazione dell'IP/URL impedirà il corretto funzionamento del cluster e potrebbe non essere supportato.

In entrata

Altre informazioni sulle regole di sicurezza in ingresso:

• Portale di Azure. Questa porta viene usata dal provider di risorse di Service Fabric per eseguire query sulle informazioni sul cluster per visualizzare nel portale di gestione di Azure. Se questa porta non è accessibile dal provider di risorse di Service Fabric, viene visualizzato un messaggio come "Nodi non trovati" o "UpgradeServiceNotReachable" nel portale di Azure e l'elenco di nodi e applicazioni viene visualizzato vuoto. Ciò significa che se si vuole avere visibilità del cluster nel portale di gestione di Azure, il servizio di bilanciamento del carico deve esporre un indirizzo IP pubblico e il gruppo di sicurezza di rete deve consentire il traffico in ingresso 19080. Questa porta è consigliata per le operazioni di gestione estese del provider di risorse di Service Fabric per garantire un'affidabilità maggiore.

• API client. Endpoint di connessione client per le API usate da PowerShell.

• API SFX + Client. Questa porta viene usata da Service Fabric Explorer per esplorare e gestire il cluster. Viene usato dalle API più comuni, ad esempio REST/PowerShell (Microsoft.ServiceFabric.PowerShell.Http)/CLI/.NET nello stesso modo.

• Cluster. Usato per la comunicazione tra nodi.

• Effimero. Service Fabric usa una parte di queste porte dell'applicazione, mentre le rimanenti sono a disposizione del sistema operativo. Esegue anche il mapping di questo intervallo all'intervallo esistente presente nel sistema operativo, quindi per tutti gli scopi, è possibile usare gli intervalli indicati nell'esempio qui. È necessario assicurarsi che la differenza tra la porta iniziale e la porta finale sia almeno 255. Questo intervallo è condiviso con il sistema operativo e possono quindi verificarsi dei conflitti se la differenza è troppo bassa. Per visualizzare l'intervallo di porte dinamiche configurato, eseguire netsh int ipv4 show dynamicport tcp. Queste porte non sono necessarie per i cluster Linux.

• Applicazione. L'intervallo di porte dell'applicazione deve essere abbastanza grande da soddisfare il requisito di endpoint delle applicazioni. Questo intervallo deve essere esclusivo dall'intervallo di porte dinamico del computer, ad esempio l'intervallo ephemeralPorts impostato nella configurazione. Service Fabric usa queste porte ogni volta che sono necessarie nuove porte e si occupa dell'apertura del firewall per queste porte nei nodi.

• RDP. Facoltativo, se RDP è necessario da Internet o VirtualNetwork per gli scenari jumpbox.

• SSH. Facoltativo, se SSH è necessario da Internet o VirtualNetwork per scenari jumpbox.

• Endpoint personalizzato. Un esempio per l'applicazione per abilitare un endpoint accessibile da Internet.

In uscita

Altre informazioni sulle regole di sicurezza in uscita:

• Provider di risorse. Connessione tra UpgradeService e il provider di risorse di Service Fabric per ricevere operazioni di gestione, ad esempio distribuzioni arm o operazioni obbligatorie, ad esempio la selezione del nodo di inizializzazione o l'aggiornamento del tipo di nodo primario.

• Scaricare i file binari. Il servizio di aggiornamento usa l'indirizzo download.microsoft.com per ottenere i file binari, questa relazione è necessaria per l'installazione, la ricreazione dell'immagine e gli aggiornamenti di runtime. Nello scenario di un servizio di bilanciamento del carico "solo interno", è necessario aggiungere un servizio di bilanciamento del carico esterno aggiuntivo con una regola che consente il traffico in uscita per la porta 443. Facoltativamente, questa porta può essere bloccata dopo un'installazione corretta, ma in questo caso il pacchetto di aggiornamento deve essere distribuito ai nodi o la porta deve essere aperta per un breve periodo di tempo, in seguito è necessario un aggiornamento manuale.

Usare Firewall di Azure con il log del flusso del gruppo di sicurezza di rete e il traffico analitica per tenere traccia dei problemi di connettività. Il modello di Resource Manager Service Fabric con un gruppo di sicurezza di rete è un buon esempio per iniziare.

Scenari comuni che richiedono regole aggiuntive

Tutti gli scenari aggiuntivi possono essere trattati con i tag del servizio di Azure.

Azure DevOps

Le attività classiche di PowerShell in Azure DevOps (tag di servizio: AzureCloud) richiedono l'accesso api client al cluster, ad esempio distribuzioni di applicazioni o attività operative. Questo approccio non si applica solo ai modelli arm, incluse le risorse dell'applicazione ARM.

Aggiornamento di Windows

La procedura consigliata per applicare patch al sistema operativo Windows consiste nel sostituire il disco del sistema operativo con aggiornamenti automatici dell'immagine del sistema operativo, non è necessaria alcuna regola aggiuntiva. Patch Orchestration Application gestisce gli aggiornamenti in-VM in cui gli aggiornamenti di Windows applicano le patch del sistema operativo, questo richiede l'accesso all'Area download (tag di servizio: AzureUpdateDelivery) per scaricare i file binari di aggiornamento.

Gestione API

L'integrazione di Azure Gestione API (tag del servizio: ApiManagement) richiede l'accesso all'API client per eseguire query sulle informazioni sull'endpoint dal cluster.

Distribuzione in rete delle applicazioni

• Per eseguire carichi di lavoro di contenitori Windows, usare la modalità di rete aperta per semplificare le comunicazioni tra i servizi.

• Usare un proxy inverso come Traefik o il proxy inverso di Service Fabric per esporre le porte delle applicazioni comuni, ad esempio 80 o 443.

• Per i contenitori Di Windows ospitati in computer con disponibilità a disponibilità limitata che non possono eseguire il pull dei livelli di base dall'archiviazione cloud di Azure, eseguire l'override del comportamento del livello esterno usando il flag --allow-nondistributable-artifacts nel daemon Docker.

Passaggi successivi

• Creare un cluster nelle VM o nei computer che eseguono Windows Server: Creazione di cluster di Service Fabric per Windows Server
• Creare un cluster nelle VM o nei computer che eseguono Linux: Creare un cluster Linux
• Informazioni sulle opzioni di supporto di Service Fabric