Come funzionano le policy di soglia delle performance definite dall'utente
-
PDF del sito di questa documentazione
-
Installare Unified Manager su sistemi Linux
-
Eseguire attività amministrative e di configurazione
-
Monitorare e gestire lo storage
-
Monitorare e gestire le performance del cluster
-
Monitorare e gestire lo stato dei cluster
-
Flussi di lavoro e attività comuni per lo stato di salute di Unified Manager
-
-
![](https://docs.netapp.com/common/images/pdf-zip.png)
Raccolta di documenti PDF separati
Creating your file...
È possibile impostare criteri di soglia delle performance sugli oggetti storage (ad esempio, su aggregati e volumi) in modo che un evento possa essere inviato all'amministratore dello storage per informare l'amministratore che il cluster sta riscontrando un problema di performance.
È possibile creare un criterio di soglia delle performance per un oggetto di storage:
-
Selezione di un oggetto di storage
-
Selezione di un contatore di performance associato a quell'oggetto
-
Specificare i valori che definiscono i limiti superiori del contatore delle prestazioni considerati situazioni critiche e di avviso
-
Specificare un periodo di tempo che definisce il tempo per il quale il contatore deve superare il limite massimo
Ad esempio, è possibile impostare un criterio di soglia delle performance su un volume in modo da ricevere una notifica di eventi critici ogni volta che gli IOPS per quel volume superano le 750 operazioni al secondo per 10 minuti consecutivi. Questo stesso criterio di soglia può anche specificare che un evento di avviso deve essere inviato quando IOPS supera 500 operazioni al secondo per 10 minuti.
|
La release corrente fornisce soglie che inviano eventi quando un valore del contatore supera l'impostazione della soglia. Non è possibile impostare soglie che inviino eventi quando un valore del contatore scende al di sotto di un'impostazione di soglia. |
Viene visualizzato un esempio di tabella dei contatori, che indica che una soglia di avviso (icona gialla) è stata violata alle 1:00 e che una soglia critica (icona rossa) è stata violata alle 12:10, 12:30 e 1:10:
![violazione della soglia opm2](../media/opm2_threshold_breach.gif)
Una violazione di soglia deve verificarsi continuamente per la durata specificata. Se la soglia scende al di sotto dei valori limite per qualsiasi motivo, una successiva violazione viene considerata l'inizio di una nuova durata.
Alcuni oggetti cluster e contatori delle performance consentono di creare una policy di soglia combinata che richiede che due contatori delle performance superino i limiti massimi prima che venga generato un evento. Ad esempio, è possibile creare un criterio di soglia utilizzando i seguenti criteri:
Oggetto cluster | Contatore delle performance | Soglia di avviso | Soglia critica | Durata |
---|---|---|---|---|
Volume |
Latenza |
10 millisecondi |
20 millisecondi |
15 minuti |
Aggregato |
Utilizzo |
65% |
85% |
I criteri di soglia che utilizzano due oggetti cluster generano un evento solo quando entrambe le condizioni vengono violate. Ad esempio, utilizzando il criterio di soglia definito nella tabella:
Se la latenza del volume è in media… | E l'utilizzo dei dischi aggregati è… | Quindi… |
---|---|---|
15 millisecondi |
50% |
Nessun evento segnalato. |
15 millisecondi |
75% |
Viene segnalato un evento di avviso. |
25 millisecondi |
75% |
Viene segnalato un evento di avviso. |
25 millisecondi |
90% |
Viene segnalato un evento critico. |