Condividi tramite

Procedure consigliate per la scalabilità automatica

  • Articolo

La scalabilità automatica di Monitoraggio di Azure si applica solo ai set di scalabilità di macchine virtuali di Azure, Servizi cloud di Azure, la funzionalità app Web del servizio app di Azure e Gestione API di Azure.

Concetti di scalabilità automatica

  • Una risorsa può avere una sola impostazione di scalabilità automatica.
  • Un'impostazione di scalabilità automatica può avere uno o più profili e ogni profilo può avere una o più regole di scalabilità automatica.
  • Un'impostazione di scalabilità automatica scala le istanze orizzontalmente, ovvero aumenta e riduce il numero delle istanze.
  • Un'impostazione di scalabilità automatica prevede un numero massimo, un numero minimo e un numero predefinito di istanze.
  • Un processo di scalabilità automatica legge sempre la metrica associata in base a cui eseguire il ridimensionamento, controllando se è stata superata la soglia configurata per l'aumento o la riduzione del numero di istanze. Per un elenco delle metriche in base alle quali può essere applicata la scalabilità automatica, vedere Metriche comuni per la scalabilità automatica di Monitoraggio di Azure.
  • Tutte le soglie vengono calcolate a livello di istanza. Un esempio è "aumentare il numero di istanze di un'istanza quando la CPU > media è 80% quando il numero di istanze è 2". Significa aumentare il numero di istanze quando la CPU media in tutte le istanze è maggiore dell'80%.
  • Tutti gli errori di scalabilità automatica vengono registrati nel log attività. È quindi possibile configurare un avviso di log attività in modo da ricevere una notifica tramite posta elettronica, SMS o webhook ogni volta che si verifica un errore di scalabilità automatica.
  • Analogamente, tutte le azioni di scalabilità riuscite vengono registrate nel log attività. È quindi possibile configurare un avviso del log attività in modo da ricevere una notifica tramite posta elettronica, SMS o webhook ogni volta che l'azione riesce. È anche possibile configurare le notifiche tramite posta elettronica o webhook nella scheda Notifiche dell'impostazione della scalabilità automatica per ricevere un avviso per le azioni riuscite.

Procedure consigliate per la scalabilità automatica

Usare le procedure consigliate seguenti quando si usa la scalabilità automatica.

Assicurarsi che i valori massimo e minimo siano diversi e che tra di loro ci sia un margine adeguato

Se il valore minimo di un'impostazione è 2, il valore massimo è 2 e il conteggio di istanze correnti è 2, non può verificarsi alcuna azione di scalabilità. Mantenere un margine adeguato tra i conteggi massimo e minimo delle istanze, che sono valori inclusivi. La scalabilità automatica viene sempre applicata entro questi limiti.

La scalabilità manuale viene reimpostata in base alla scalabilità automatica minima e massima

Se si aggiorna manualmente il numero di istanze su un valore superiore o inferiore al valore massimo, il motore di scalabilità automatica ripristina automaticamente il valore minimo (se inferiore) o il valore massimo (se superiore). Si supponga ad esempio di impostare l'intervallo compreso tra 3 e 6. Se è in esecuzione un'unica istanza, il motore di scalabilità automatica aumenta il numero a tre istanze alla successiva esecuzione. Analogamente, se si imposta manualmente la scala su otto istanze, nell'esecuzione successiva la scalabilità automatica rieseguirà il ridimensionamento a sei istanze. La scalabilità manuale è temporanea, a meno che non vengano anche reimpostate le regole di scalabilità automatica.

Usare sempre una combinazione di regole di aumento e riduzione del numero di istanze

Se si usa solo una parte della combinazione, la scalabilità automatica esegue solo azioni in un'unica direzione (aumento o diminuzione) fino a quando non raggiunge il conteggio di istanze massimo o minimo, come definito nel profilo. Questa situazione non è ottimale. Idealmente, si vuole che la risorsa venga ridimensionata in momenti di utilizzo elevato per garantire la disponibilità. Allo stesso modo, nei casi di uso limitato, è utile che le risorse vengano ridotte in modo da poter risparmiare sui costi.

Quando si usa una regola di scalabilità orizzontale e di scalabilità verticale, usare idealmente la stessa metrica per controllare entrambi. In caso contrario, è possibile che le condizioni di scalabilità orizzontale e scalabilità verticale possano essere soddisfatte contemporaneamente e comportino un certo livello di flapping. Ad esempio, non è consigliabile usare la combinazione di regole seguente perché non esiste una regola di scalabilità orizzontale per l'utilizzo della memoria:

  • Se la CPU > 90%, aumentare il numero di istanze di 1
  • Se la memoria > 90%, aumentare il numero di istanze di 1
  • Se la CPU < 45%, ridurre il numero di istanze di 1

In questo esempio è possibile avere una situazione in cui l'utilizzo della memoria è superiore al 90%, ma l'utilizzo della CPU è inferiore al 45%. Questo scenario può causare il flapping finché vengono soddisfatte entrambe le condizioni.

Scegliere la statistica appropriata per la metrica di diagnostica

Per le metriche di diagnostica, è possibile scegliere tra Medio, Minimo, Massimo e Totale come metrica per il ridimensionamento. La statistica più comune è Medio.

Considerazioni sul ridimensionamento dei valori di soglia per le metriche speciali

Per le metriche speciali, ad esempio la metrica di archiviazione di Azure o la metrica di lunghezza della coda del bus di servizio di Azure, la soglia è il numero medio di messaggi disponibile per il numero corrente di istanze. Scegliere con attenzione il valore di soglia per questa metrica.

Per far comprendere meglio il comportamento, verrà illustrato con esempio:

  • Aumentare le istanze di 1 quando il conteggio dei messaggi della coda di archiviazione è >= 50
  • Ridurre le istanze di 1 quando il conteggio dei messaggi della coda di archiviazione è <= 10

Considerare la sequenza seguente:

  1. Esistono due istanze di coda di archiviazione.
  2. Continuano ad arrivare messaggi e, quando si controlla la coda di archiviazione, il conteggio totale è pari a 50. Si potrebbe pensare che la scalabilità automatica debba avviare un'azione di aumento del numero di istanze. Si noti tuttavia che si tratta comunque di 50/2 = 25 messaggi per ogni istanza. Quindi, la scalabilità orizzontale non si verifica. Perché venga eseguita la prima azione di aumento del numero di istanze, il conteggio totale dei messaggi nella coda di archiviazione deve essere pari a 100.
  3. Si supponga ora che il conteggio totale dei messaggi raggiunga i 100.
  4. Viene aggiunta una terza istanza della coda di archiviazione a causa di un'azione di scalabilità orizzontale. L'azione successiva di aumento del numero di istanze verrà eseguita solo dopo che il conteggio totale dei messaggi nella coda avrà raggiunto il numero di 150, poiché 150/3 = 50.
  5. Ora il numero di messaggi nella coda si riduce. Con tre istanze, la prima azione di riduzione del numero di istanze viene eseguita quando i messaggi totali in tutte le code raggiungono il numero di 30, ovvero 30/3 = 10 messaggi per istanza, che corrisponde alla soglia di riduzione del numero di istanze.

Considerazioni sul ridimensionamento quando vengono configurate più regole in un profilo

In alcuni casi potrebbe essere necessario impostare più regole in un profilo. Le regole di scalabilità automatica seguenti vengono usate dal motore di scalabilità automatica quando vengono impostate più regole:

  • In caso di aumento del numero di istanze, la scalabilità automatica viene eseguita se risulta soddisfatta una regola qualsiasi.
  • In caso di riduzione del numero di istanze, la scalabilità automatica richiede che tutte le regole siano soddisfatte.

Per illustrare, si supponga di avere quattro regole di scalabilità automatica:

  • Se la CPU è < 30%, ridurre il numero di istanze di 1
  • Se la memoria è < 50%, ridurre il numero di istanze di 1
  • Se la CPU è > 75%, aumentare il numero di istanze di 1
  • Se la memoria è > 75%, aumentare il numero di istanze di 1

Si verifica quindi l'azione seguente:

  • Se la CPU è pari al 76% e la memoria è pari al 50%, il numero di istanze verrà aumentato.
  • Se la CPU è pari al 50% e la memoria è pari al 76%, il numero di istanze viene aumentato.

Ma, se la CPU è pari al 25% e la memoria è pari al 51%, la scalabilità automatica non riduce il numero di istanze. Per ridurre il numero di istanze, la CPU deve essere al 29% e la memoria al 49%.

Selezionare sempre un numero di istanze predefinito sicuro

Il numero di istanze predefinito è importante poiché la scalabilità automatica dimensiona il servizio a quel numero quando le metriche non sono disponibili. Di conseguenza, selezionare un numero di istanze predefinito sicuro per i carichi di lavoro.

Configurare le notifiche relative alla scalabilità automatica

La scalabilità automatica esegue la registrazione sul log attività se si verifica una delle condizioni seguenti:

  • La scalabilità automatica esegue un'operazione di scalabilità.
  • Il servizio di scalabilità automatica esegue correttamente un'azione di scalabilità.
  • Il servizio di scalabilità automatica non riesce a eseguire un'azione di scalabilità.
  • Non sono disponibili metriche che consentono al servizio di scalabilità automatica di prendere una decisione sul ridimensionamento.
  • Sono di nuovo disponibili metriche (ripristino) che consentono di prendere una decisione sulla scalabilità.
  • La scalabilità automatica rileva l'instabilità e interrompe il tentativo di ridimensionamento. In questa situazione viene visualizzato un tipo di log di Flapping. Se viene visualizzato questo tipo di log, valutare se le soglie sono troppo strette.
  • La scalabilità automatica rileva l'instabilità, ma è comunque in grado di eseguire correttamente il ridimensionamento. In questa situazione viene visualizzato un tipo di log di FlappingOccurred. Se viene visualizzato questo tipo di log, il motore di scalabilità automatica ha tentato di ridimensionare (ad esempio, da quattro istanze a due) ma ha determinato che questa modifica causerebbe il flapping. Al contrario, il motore di scalabilità automatica è stato ridimensionato a un numero diverso di istanze (ad esempio, usando tre istanze anziché due), che non causa più il flapping, quindi è stato ridimensionato fino a questo numero di istanze.

Per monitorare l'integrità del motore di scalabilità automatica si può anche usare un avviso di log attività. Un esempio mostra come creare un avviso del log attività per monitorare tutte le operazioni del motore di scalabilità automatica della sottoscrizione. Un altro esempio mostra come creare un avviso di log attività per monitorare tutte le operazioni di scalabilità automatica in riduzione e in aumento non riuscite per la sottoscrizione.

Oltre a usare gli avvisi di log attività, è possibile configurare le notifiche tramite posta elettronica o webhook per ricevere una notifica delle azioni di scalabilità tramite la scheda delle notifiche dell'impostazione di scalabilità automatica.

Inviare i dati in modo sicuro usando TLS 1.2

Per garantire la sicurezza dei dati in transito verso Monitoraggio di Azure, è consigliabile configurare l'agente in modo da usare almeno il protocollo Transport Layer Security (TLS) 1.2. Le versioni precedenti di TLS/Secure Sockets Layer (SSL) sono state trovate vulnerabili. Anche se attualmente funzionano per consentire la compatibilità con le versioni precedenti, non è consigliabile. Il settore sta rapidamente passando all'abbandono del supporto per questi protocolli meno recenti.

Il PCI Security Standards Council ha imposto il 30 giugno 30, 2018 come scadenza per disabilitare le versioni precedenti di TLS/SSL ed eseguire l'aggiornamento a protocolli più sicuri. Al termine del supporto legacy di Azure, non sarà possibile inviare dati a Log di Monitoraggio di Azure se gli agenti non possono comunicare almeno tramite TLS 1.2.

È consigliabile non impostare in modo esplicito l'agente in modo che usi SOLO TLS 1.2, a meno che non sia necessario. È preferibile consentire all'agente di rilevare, negoziare e sfruttare automaticamente gli standard di sicurezza futuri. In caso contrario, si potrebbe perdere la sicurezza aggiunta degli standard più recenti ed eventualmente riscontrare problemi se TLS 1.2 è mai deprecato a favore di tali standard più recenti.

Passaggi successivi