Procedure consigliate per la scalabilità automatica

La scalabilità automatica di Monitoraggio di Azure si applica solo alle set di scalabilità di macchine virtuali di Azure, alle Servizi cloud di Azure, alla funzionalità di App Web di Servizio app di Azure e ad Azure Gestione API.

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 ha un valore massimo, uno minimo e uno predefinito di istanze.
  • Un processo di scalabilità automatica legge sempre la metrica associata alla scala controllando se ha superato 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 per un'istanza quando il valore medio della CPU > è 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 del log attività in modo che sia possibile 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 pubblicate 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. È inoltre possibile configurare le notifiche tramite posta elettronica o webhook per ricevere una notifica delle azioni di scalabilità riuscite tramite la scheda delle notifiche dell'impostazione di scalabilità automatica.

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 essi ci sia un margine adeguato

Se si dispone di un'impostazione con minimum=2, maximum=2 e il conteggio delle istanze corrente è 2, non è possibile eseguire 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.

Il ridimensionamento manuale viene reimpostato con la scalabilità automatica minima e massima

Se si aggiorna manualmente il conteggio delle istanze impostandolo su un valore al di sopra o al di sotto di quello massimo, il motore di scalabilità automatica utilizza automaticamente il valore minimo (se al di sotto) o il valore massimo (se al di sopra). Ad esempio, se l'utente imposta l'intervallo tra i valori e 3 e 6, in presenza di un'istanza in esecuzione, il motore di scalabilità automatica esegue il ridimensionamento 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. Il ridimensionamento manuale è temporaneo, a meno che non si reimpostano anche le regole di scalabilità automatica.

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

Se si usa una sola parte della combinazione, la scalabilità automatica esegue l'azione solo in una sola direzione (aumento o in uscita) fino a raggiungere il numero massimo o minimo di istanze, 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à. Analogamente, a volte di basso utilizzo, si vuole che la risorsa venga ridimensionata in modo da poter realizzare risparmi sui costi.

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

  • Se la CPU > è 90%, aumentare il numero di istanze di 1
  • Se memoria > 90%, aumentare il numero di istanze di 1
  • Se LA CPU < è 45%, scalare entro 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 un'instabilità fino a quando vengono soddisfatte entrambe le condizioni.

Scegliere la statistica appropriata per la metrica di diagnostica

Per le metriche di diagnostica, è possibile scegliere tra Media, Minimo, Massimo e Totale come metrica da ridimensionare. La statistica più comune è Media.

Considerazioni sul ridimensionamento dei valori di soglia per le metriche speciali

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

Di seguito viene illustrato un esempio per assicurarsi di comprendere meglio il comportamento:

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

Considerare la sequenza seguente:

  1. Sono disponibili due istanze della coda di archiviazione.
  2. I messaggi continuano a venire e quando si esamina la coda di archiviazione, il conteggio totale legge 50. Si potrebbe pensare che la scalabilità automatica debba avviare un'azione di aumento del numero di istanze. Si noti tuttavia che è ancora 50/2 = 25 messaggi per istanza. Quindi, la scalabilità orizzontale non si verifica. Per la prima azione di aumento del numero di istanze, il numero totale di messaggi nella coda di archiviazione deve essere 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 aumento del numero di istanze. L'azione di scalabilità orizzontale successiva non verrà eseguita fino a quando il numero totale di messaggi nella coda raggiunge 150 perché 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.
  • 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%, scalare in base a 1
  • Se la memoria < è 50%, scalare in base a 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 è del 50% e la memoria è pari al 76%, si aumenta il numero di istanze.

D'altra parte, se la CPU è del 25% e La memoria è pari al 51%, la scalabilità automatica non viene ridimensionata. Per aumentare le prestazioni, la CPU deve essere del 29% e della memoria 49%.

Selezionare sempre un conteggio 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 il post nel 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 Flapping log. 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 FlappingOccurred log. 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 l'instabilità. Al contrario, il motore di scalabilità automatica è stato ridimensionato a un numero diverso di istanze (ad esempio, usando tre istanze invece di due), che non causa più il flapping, quindi è stato ridimensionato a questo numero di istanze.

È anche possibile usare un avviso del log attività per monitorare l'integrità del motore di scalabilità automatica. Un esempio illustra come creare un avviso del log attività per monitorare tutte le operazioni del motore di scalabilità automatica nella sottoscrizione. Un altro esempio mostra come creare un avviso del log attività per monitorare tutte le operazioni di scalabilità automatica/scalabilità orizzontale non riuscite nella sottoscrizione.

Oltre a usare gli avvisi del log attività, è anche possibile configurare notifiche tramite posta elettronica o webhook per ricevere notifiche per le azioni di scalabilità tramite la scheda Notifiche nell'impostazione di scalabilità automatica.

Inviare i dati in modo sicuro usando TLS 1.2

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

Il Pci Security Standards Council ha stabilito una scadenza del 30 giugno 2018, per disabilitare le versioni precedenti di TLS/SSL e l'aggiornamento a protocolli più sicuri. Dopo che Azure elimina il supporto legacy, se gli agenti non possono comunicare almeno TLS 1.2, non sarà possibile inviare dati ai log di Monitoraggio di Azure.

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

Passaggi successivi