Pianificazione della capacità per Active Directory Domain Services
Questo argomento è stato scritto originariamente da Ken Brumfield, Program Manager di Microsoft, e fornisce indicazioni per la Pianificazione della capacità per Active Directory Domain Services (AD DS).
Obiettivi della pianificazione della capacità
La pianificazione della capacità non è la stessa cosa della risoluzione dei problemi di prestazioni. Sono strettamente correlate, ma molto diverse. Gli obiettivi della pianificazione della capacità sono:
- Implementare e gestire correttamente un ambiente
- Ridurre al minimo il tempo dedicato alla risoluzione dei problemi di prestazioni.
Nella pianificazione della capacità, un'organizzazione potrebbe avere un target di riferimento del 40% di utilizzo del processore durante i periodi di picco, al fine di soddisfare i requisiti di prestazione dei client e di tenere conto del tempo necessario per aggiornare l'hardware del data center. Invece, per essere avvisati di eventi di prestazioni anomale, si potrebbe impostare una soglia di monitoraggio degli avvisi al 90% su un intervallo di 5 minuti.
La differenza è che quando una soglia di gestione della capacità viene continuamente superata (un evento una tantum non è un problema), la soluzione potrebbe essere aggiungere capacità (cioè l'aggiunta di processori di più grandi dimensioni o più veloci) o scalare il servizio su più server. Le soglia di monitoraggio delle prestazioni indicano che l'esperienza client è attualmente carente e che è necessario adottare misure immediate per risolvere il problema.
Per fare un'analogia: la gestione della capacità consiste nel prevenire un incidente stradale (guida difensiva, assicurarsi che i freni funzionino correttamente e così via), mentre la risoluzione dei problemi di prestazioni è quello di cui si occupano le forze dell’ordine, i vigili del fuoco e il personale medico di pronto intervento dopo un incidente. Si tratta di "guida difensiva", in stile Active Directory.
Negli ultimi anni, le indicazioni per la pianificazione della capacità dei sistemi a scalabilità verticale sono cambiate radicalmente. I cambiamenti seguenti nelle architetture di sistema hanno messo in discussione i presupposti fondamentali per la progettazione e la scalabilità di un servizio:
- Piattaforme server a 64 bit
- Virtualizzazione
- Maggiore attenzione al consumo di energia elettrica
- Archiviazione SSD
- Scenari cloud
Inoltre, l'approccio si sta spostando da una pianificazione della capacità basata sui server a una pianificazione della capacità basata sui servizi. Active Directory Domain Services (AD DS), servizio distribuito avanzato che molti prodotti Microsoft e di terze parti utilizzano come back-end, diventa uno dei prodotti più critici da pianificare correttamente per garantire la capacità necessaria al funzionamento di altre applicazioni.
Requisiti di base per la guida alla pianificazione della capacità
In questo articolo, i requisiti di base sono i seguenti:
- Il lettore ha letto e conosce le Linee guida per l’ottimizzazione delle prestazioni di Windows Server 2012 R2.
- La piattaforma Windows Server è un'architettura basata su x64. Tuttavia, sebbene l'ambiente Active Directory è installato su Windows Server 2003 x86 (ormai oltre la fine del ciclo di vita del supporto) e dispone di un albero delle informazioni di directory (DIT) di dimensioni inferiori a 1,5 GB e che può essere facilmente mantenuto in memoria, le linee guida di questo articolo sono tuttora applicabili.
- La pianificazione della capacità è un processo continuo e occorre verificare regolarmente se l'ambiente soddisfa le aspettative.
- L'ottimizzazione avverrà nel corso di più cicli di vita dell'hardware, al variare dei costi. Ad esempio, la memoria diventa più conveniente, il costo per core diminuisce o il prezzo delle diverse opzioni di archiviazione varia.
- Pianificare il periodo di massima attività della giornata. Si consiglia di esaminarlo a intervalli di 30 minuti o di un'ora. Qualsiasi valore superiore può nascondere i picchi effettivi e qualsiasi valore inferiore può essere falsato da "picchi transitori".
- Pianificare la crescita nel corso del ciclo di vita dell'hardware per l'azienda. Questo può includere una strategia di aggiornamento o di aggiunta di hardware in modo scaglionato, oppure un aggiornamento completo ogni tre-cinque anni. Ognuno di essi richiede una "supposizione" su quanto crescerà il carico su Active Directory. I dati cronologici, se raccolti, saranno utili per questa valutazione.
- Pianificare la tolleranza di errore. Una volta ottenuta una stima di N, è necessario pianificare scenari che includano N – 1, N – 2, N – x.
Aggiungere altri server in base alle esigenze organizzative per garantire che la perdita di un singolo o di più server non superi le stime della capacità di picco massima.
Considerare inoltre che il piano di crescita e il piano di tolleranza di errore devono essere integrati. Ad esempio, se è necessario un controller di dominio per supportare il carico, ma si stima che il carico raddoppierà nel prossimo anno e richiederà due controller di dominio in totale, non si avrà una capacità sufficiente per supportare la tolleranza di errore. La soluzione potrebbe essere iniziare con tre controller di dominio. Se il budget è limitato si potrebbe anche pianificare di aggiungere il terzo controller di dominio dopo 3 o 6 mesi.
Nota
L'aggiunta di applicazioni compatibili con Active Directory potrebbe avere un impatto notevole sul carico del controller di dominio, indipendentemente dal fatto che il carico provenga dai server dell'applicazione o dai client.
Processo in tre passaggi per il ciclo di pianificazione della capacità
Nella pianificazione della capacità, si deve innanzitutto decidere quale qualità del servizio è necessaria. Ad esempio, un data center core supporta un livello di concorrenza più elevato e richiede un'esperienza più coerente per gli utenti e le applicazioni in uso, con conseguente maggiore attenzione alla ridondanza e alla riduzione al minimo dei colli di bottiglia del sistema e dell'infrastruttura. Al contrario, una sede satellite con pochi utenti non ha bisogno dello stesso livello di concorrenza o di tolleranza di errore. Pertanto, l'ufficio satellite potrebbe non aver bisogno di un'attenzione altrettanto elevata all'ottimizzazione dell'hardware e dell'infrastruttura di base, con conseguenti risparmi sui costi. Tutte le raccomandazioni e le indicazioni contenute nel presente documento si riferiscono a prestazioni ottimali e possono essere selettivamente ridotte per scenari con requisiti meno impegnativi.
La domanda successiva è: virtualizzato o fisico? Dal punto di vista della pianificazione della capacità, non esiste una risposta giusta o sbagliata, ma solo una serie di variabili diverse con cui lavorare. Gli scenari di virtualizzazione si riducono a due opzioni:
- "Mapping diretto" con un guest per host (dove la virtualizzazione sussiste solo per astrarre l'hardware fisico dal server)
- "Host condiviso"
I test e gli scenari di produzione indicano che lo scenario "mapping diretto" può essere trattato in modo identico a un host fisico. L'"host condiviso", tuttavia, introduce una serie di considerazioni illustrate in dettaglio più avanti. Lo scenario di "host condiviso" comporta che anche AD DS sia in competizione per le risorse, con conseguenti penalizzazioni e considerazioni sull’ottimizzazione.
Tenendo conto di queste considerazioni, il ciclo di pianificazione della capacità è un processo iterativo in tre passaggi:
- Misurare l'ambiente esistente, determinare dove si trovano attualmente i colli di bottiglia del sistema e ottenere le informazioni di base sull'ambiente necessarie per pianificare la quantità di capacità necessaria.
- Determinare l'hardware necessario in base ai criteri delineati al passaggio 1.
- Monitorare e verificare che l'infrastruttura implementata funzioni secondo le specifiche. I dati raccolti in questo passaggio rappresentano la base per il ciclo successivo di pianificazione della capacità.
Applicazione del processo
Per ottimizzare le prestazioni, è necessario assicurarsi che i componenti principali siano stati selezionati e ottimizzati correttamente in base ai carichi di applicazione:
- Memoria
- Network
- Archiviazione
- Processore
- Accesso rete
I requisiti di archiviazione di base di AD DS e il comportamento generale di un software client ben congegnato consentono agli ambienti con un numero di utenti compreso tra 10.000 e 20.000 di evitare ingenti investimenti nella pianificazione della capacità per quanto riguarda l'hardware fisico, poiché quasi tutti i moderni sistemi di classe server sono in grado di gestire il carico. Detto questo, la tabella seguente riassume come valutare un ambiente esistente per selezionare l'hardware corretto. Ogni componente viene analizzato in dettaglio nelle sezioni successive per permettere agli amministratori di AD DS di valutare la propria infrastruttura utilizzando le indicazioni di base e i principi specifici dell'ambiente.
In generale:
- Qualsiasi dimensionamento basato sui dati attuali sarà accurato solo per l'ambiente attuale.
- Per qualsiasi stima, si deve prevedere una crescita della domanda nel corso del ciclo di vita dell'hardware.
- Scegliere se sovradimensionare oggi e crescere in un ambiente di dimensioni maggiori o se aggiungere capacità nel corso del ciclo di vita.
- Per la virtualizzazione si applicano gli stessi principi e metodologie di pianificazione della capacità, tranne che per il fatto che l'overhead della virtualizzazione deve essere aggiunto a tutti i componenti del dominio.
- La pianificazione della capacità, come qualsiasi altro tentativo di previsione, NON è una scienza esatta. Non aspettarsi che i calcoli siano perfetti e accurati al 100%. La guida rappresenta l’indicazione più semplice: aggiungere capacità per una maggiore sicurezza e verificare continuamente che l'ambiente rimanga in linea con gli obiettivi.
Tabelle di riepilogo della raccolta dati
Nuovo ambiente
| Componente | Stime |
|---|---|
| Dimensioni dello spazio di archiviazione/database | Da 40 kB a 60 kB per ogni utente |
| RAM | Dimensioni del database Indicazioni relative al sistema operativo di base Applicazioni di terze parti |
| Network | 1 GB |
| CPU | 1.000 utenti simultanei per ogni core |
Criteri di valutazione di alto livello
| Componente | Criteri di valutazione | Considerazioni sulla pianificazione |
|---|---|---|
| Dimensioni dello spazio di archiviazione/database | La sezione intitolata "Per attivare la registrazione dello spazio su disco liberato dalla deframmentazione" in Limiti di archiviazione | |
| Prestazioni di archiviazione/database |
|
|
| RAM |
|
|
| Network |
|
|
| CPU |
|
|
| Accesso rete |
|
|
Pianificazione
Per molto tempo, il consiglio della community per il dimensionamento di AD DS è stato quello di "inserire una quantità di RAM pari alle dimensioni del database". Nella maggior parte dei casi, questo consiglio era l'unica cosa di cui la maggior parte degli ambienti doveva preoccuparsi. Ma l'ecosistema che utilizza AD DS è diventato sempre più grande, così come gli ambienti AD DS stessi, dalla sua introduzione nel 1999. Sebbene l'aumento della potenza di calcolo e il passaggio da architetture x86 ad architetture x64 abbiano reso più secondari gli aspetti del dimensionamento delle prestazioni irrilevanti per un numero maggiore di client che eseguono AD DS su hardware fisico, l’aumento della virtualizzazione ha reintrodotto i problemi di ottimizzazione a un pubblico più vasto come mai prima d'ora.
Le indicazioni che seguono riguardano quindi come determinare e pianificare le esigenze di Active Directory come servizio, indipendentemente dal fatto che sia distribuito in uno scenario fisico, virtuale/fisico o puramente virtualizzato. Per questo motivo, suddivideremo la valutazione in base a ciascuno dei quattro componenti principali: archiviazione, memoria, rete e processore. In breve, per massimizzare le prestazioni su AD DS, l'obiettivo è avvicinarsi il più possibile al limite del processore.
RAM
Semplicemente, maggiore è la quantità di RAM che può essere memorizzata nella cache, minore è la quantità di RAM che deve essere trasferita su disco. Per massimizzare la scalabilità del server, la quantità minima di RAM dovrebbe corrispondere alla somma della dimensione attuale del database, della dimensione totale di SYSVOL, della quantità raccomandata dal sistema operativo e delle indicazioni del fornitore per gli agenti (antivirus, monitoraggio, backup e così via). È necessario aggiungere una quantità supplementare per tenere conto della crescita nel corso del ciclo di vita del server. Questa quantità sarà soggettiva dal punto di vista dell'ambiente e si baserà sulle stime di crescita del database in base alle modifiche dell'ambiente.
Per gli ambienti in cui la massimizzazione della quantità di RAM non è conveniente (ad esempio le sedi satellite) o non è fattibile (il DIT è troppo grande), fare riferimento alla sezione Archiviazione per garantire che l'archiviazione sia progettata correttamente.
Un corollario che emerge nel contesto generale del dimensionamento della memoria è il dimensionamento del file di paging. Nel contesto di tutto ciò che riguarda la memoria, l'obiettivo è ridurre al minimo il passaggio al disco, che è molto più lento. Quindi la domanda dovrebbe passare da "come deve essere dimensionato il file di paging?" a "quanta RAM è necessaria per ridurre al minimo il paging?" La risposta a quest'ultima domanda è illustrata di seguito. La maggior parte della discussione sul dimensionamento del file di paging rimane nell'ambito delle indicazioni generali relative al sistema operativo e della necessità di configurare il sistema per i dump di memoria, non correlati alle prestazioni di AD DS.
Valutazione
La quantità di RAM necessaria a un controller di dominio (DC) è in realtà un esercizio complesso per questi motivi:
- Alto potenziale di errore quando si cerca di usare un sistema esistente per misurare la quantità di RAM necessaria, poiché LSASS taglierà in condizioni di pressione della memoria, riducendo artificialmente il fabbisogno.
- Il fatto soggettivo che un singolo controller di dominio ha bisogno di memorizzare nella cache solo ciò che è "interessante" per i suoi client. Ciò significa che i dati che devono essere memorizzati nella cache su un controller di dominio in un sito con solo un server Exchange saranno molto diversi da quelli che devono essere memorizzati nella cache su un controller di dominio che autentica solo utenti.
- Il lavoro per valutare la RAM per ogni controller di dominio caso per caso è proibitivo e varia a seconda dell'ambiente.
- I criteri alla base del consiglio permetteranno di prendere decisioni informate:
- Maggiore è la quantità di RAM che può essere memorizzata nella cache, minore è la quantità di RAM che deve essere trasferita su disco.
- L'archiviazione è di gran lunga il componente più lento di un computer. L'accesso ai dati su supporti di archiviazione basati su spindle e SSD è più lento di 1.000.000 di volte rispetto all'accesso ai dati nella RAM.
Pertanto, per massimizzare la scalabilità del server, la quantità minima di RAM è la somma della dimensione corrente del database, della dimensione totale di SYSVOL, della quantità consigliata dal sistema operativo e delle indicazioni del fornitore per gli agenti (antivirus, monitoraggio, backup e così via). Aggiungere quantità supplementari per tenere conto della crescita nel corso del ciclo di vita del server. Questa quantità sarà soggettiva dal punto di vista dell'ambiente e si baserà sulle stime di crescita del database. Tuttavia, per le sedi satellite con un numero ridotto di utenti finali, questi requisiti possono essere ridotti, in quanto questi siti non avranno bisogno di una cache così elevata per servire la maggior parte delle richieste.
Per gli ambienti in cui la massimizzazione della quantità di RAM non è economicamente vantaggiosa (ad esempio le sedi satellite) o non è fattibile (il DIT è troppo grande), fare riferimento alla sezione Archiviazione per assicurarsi che l’archiviazione sia dimensionata correttamente.
Nota
Un corollario del dimensionamento della memoria è il dimensionamento del file di paging. Poiché l'obiettivo è ridurre al minimo il passaggio al disco, molto più lento, la domanda passa da "come deve essere dimensionato il file di paging?" a "quanta RAM è necessaria per ridurre al minimo il paging?" La risposta a quest'ultima domanda è illustrata di seguito. La maggior parte della discussione sul dimensionamento del file di paging rimane nell'ambito delle indicazioni generali relative al sistema operativo e della necessità di configurare il sistema per i dump di memoria, non correlati alle prestazioni di AD DS.
Considerazioni sulla virtualizzazione della RAM
Evitare l'overcommit di memoria nell'host. L'obiettivo fondamentale dell'ottimizzazione della quantità di RAM è di ridurre al minimo il tempo trascorso su disco. Negli scenari di virtualizzazione, esiste il concetto di overcommit di memoria, in cui viene allocata ai guest una quantità di RAM superiore a quella presente sul computer fisico. Questo di per sé non rappresenta un problema. Diventa un problema quando la memoria totale utilizzata attivamente da tutti i guest supera la quantità di RAM dell'host e l'host sottostante avvia il paging. Le prestazioni divengono associate al disco nei casi in cui il controller di dominio si rivolge a NTDS.dit per ottenere i dati, o il controller di dominio si rivolge al file di paging per ottenere i dati, o l'host si rivolge al disco per ottenere i dati che il guest pensa siano nella RAM.
Esempio di riepilogo del calcolo
| Componente | Memoria stimata (esempio) |
|---|---|
| RAM consigliata per il sistema operativo di base (Windows Server 2008) | 2 GB |
| Attività interne LSASS | 200 MB |
| Agente di monitoraggio | 100 MB |
| Antivirus | 100 MB |
| Database (Catalogo globale) | 8,5 GB |
| Cuscino per l'esecuzione del backup, accesso degli amministratori senza impatto | 1 GB |
| Totali | 12 GB |
Consigliata: 16 GB
Nel corso del tempo, si può ipotizzare che verranno aggiunti altri dati al database e che il server rimarrà probabilmente in produzione per 3-5 anni. Sulla base di una stima di crescita del 33%, 16 GB sarebbero una quantità ragionevole di RAM da inserire in un server fisico. In una macchina virtuale, data la facilità con cui è possibile modificare le impostazioni e aggiungere RAM alla macchina virtuale, è ragionevole partire da 12 GB con il piano di monitorare e aggiornare in futuro.
Network
Valutazione
In questa sezione non si tratta tanto di valutare i requisiti del traffico di replica, che si concentra sul traffico che attraversa la WAN ed è trattato in modo approfondito in Traffico di replica di Active Directory, quanto di valutare la larghezza di banda totale e la capacità di rete necessaria, comprese le query dei client, le applicazioni dei Criteri di gruppo e così via. Per gli ambienti esistenti, questo dato può essere raccolto utilizzando i contatori delle prestazioni "Interfaccia di rete(*)\Byte ricevuti/sec" e "Interfaccia di rete(*)\Byte inviati/sec". Gli intervalli di campionamento per i contatori Interfaccia di rete sono di 15, 30 o 60 minuti. Qualsiasi valore inferiore sarà generalmente troppo volatile per ottenere buone misurazioni; qualsiasi valore superiore attenuerà eccessivamente i picchi giornalieri.
Nota
In genere, la maggior parte del traffico di rete su un controller di dominio è in uscita, poiché il controller di dominio risponde alle richieste client. Questo è il motivo per cui ci si concentra sul traffico in uscita, anche se si consiglia di valutare ogni ambiente anche per il traffico in entrata. Gli stessi approcci possono essere utilizzati per affrontare e esaminare i requisiti del traffico di rete in entrata. Per ulteriori informazioni, vedere l'articolo 929851 della Knowledge Base: l'intervallo di porte dinamiche predefinite per TCP/IP modificato in Windows Vista e in Windows Server 2008.
Esigenze di larghezza di banda
La pianificazione della scalabilità della rete riguarda due categorie distinte: la quantità di traffico e il carico della CPU dovuto al traffico di rete. Ognuno di questi scenari è semplice rispetto ad altri argomenti trattati in questo articolo.
Per valutare la quantità di traffico da supportare, esistono due categorie uniche di pianificazione della capacità di AD DS in termini di traffico di rete. La prima è il traffico di replica che passa tra i controller di dominio ed è trattata in modo approfondito nel documento Traffico di replica di Active Directory ed è ancora rilevante per le versioni attuali di AD DS. Il secondo è il traffico all'interno di un sito da client a server. Uno degli scenari più semplici da pianificare, il traffico all'interno di un sito riceve prevalentemente piccole richieste dai client rispetto alle grandi quantità di dati inviati ai client. 100 MB sono generalmente sufficienti in ambienti fino a 5.000 utenti per server, in un sito. L'uso di una scheda di rete da 1 GB e il supporto del Receive Side Scaling (RSS) sono consigliati per ambienti con più di 5.000 utenti. Per convalidare questo scenario, in particolare nel caso di scenari di consolidamento dei server, è necessario esaminare l'interfaccia di rete (*)*Byte/sec di tutti i controller di dominio di un sito, sommarli e dividerli per il numero di controller di dominio da raggiungere per assicurarsi che la capacità sia adeguata. Il modo più semplice per farlo è utilizzare la visualizzazione "Area in pila" in Windows Reliability and Performance Monitor (precedentemente noto come Perfmon), assicurandosi che tutti i contatori siano dimensionati allo stesso modo.
Considerare il seguente esempio (noto anche come un modo molto complesso per dimostrare che la regola generale è applicabile a un ambiente specifico). Facciamo le seguenti ipotesi:
- L'obiettivo è ridurre l'ingombro al minor numero possibile di server. Idealmente, un solo server si occuperà del carico e un altro server verrà distribuito per ridondanza (scenario N + 1).
- In questo scenario, l'attuale adattatore di rete supporta solo 100 MB e si trova in un ambiente commutato. In uno scenario N, l'utilizzo massimo della larghezza di banda della rete è del 60% (perdita di un controller di dominio).
- Ogni server è collegato a circa 10.000 client.
Le conoscenze acquisite dai dati del grafico (Interfaccia di rete(*)\Byte inviati/sec):
- La giornata operativa inizia a intensificarsi verso le 5:30 e si conclude alle 19:00.
- Il periodo di massima affluenza va dalle 8:00 alle 8:15, con più di 25 Byte inviati al secondo nel controller di dominio più trafficato.
Nota
Tutti i dati relativi alle prestazioni sono di tipo cronologico. Quindi il punto di picco dei dati alle 8:15 indica il carico dalle 8:00 alle 8:15.
- Si registrano picchi prima delle 4:00 del mattino, con più di 20 byte inviati al secondo sul controller di dominio più trafficato, che potrebbe indicare un carico proveniente da diversi fusi orari o un'attività infrastrutturale in background, come i backup. Poiché il picco alle 8:00 supera questa attività, non è rilevante.
- Nel sito sono presenti cinque controller di dominio.
- Il carico massimo è di circa 5,5 MB/s per controller di dominio, pari al 44% della connessione da 100 MB. Sulla base di questi dati, si può stimare che la larghezza di banda totale necessaria tra le 8:00 e le 8:15 sia di 28 MB/s.
Nota
Fare attenzione al fatto che i contatori dell'interfaccia di rete inviati/ricevuti sono in byte e la larghezza di banda della rete è misurata in bit. 100 MB ÷ 8 = 12.5 MB, 1 GB ÷ 8 = 128 MB.
Conclusioni:
- L'ambiente attuale soddisfa il livello di tolleranza di errore N+1 con un utilizzo di destinazione del 60%. La disattivazione di un sistema sposterà la larghezza di banda per server da circa 5,5 MB/s (44%) a circa 7 MB/s (56%).
- In base all'obiettivo precedentemente dichiarato di consolidare il sistema su un solo server, questo supera sia l'uso massimo previsto sia, in teoria, il possibile uso di una connessione da 100 MB.
- Con una connessione da 1 GB, questo rappresenterà il 22% della capacità totale.
- In condizioni operative normali nello scenario N + 1, il carico dei client sarà distribuito in modo relativamente uniforme a circa 14 MB/s per server o all'11% della capacità totale.
- Per garantire che la capacità sia sufficiente in caso di indisponibilità di un controller di dominio, gli obiettivi operativi normali per server corrispondono a circa il 30% di uso della rete o a 38 MB/s per server. Gli obiettivi di failover corrispondono al 60% di uso della rete o 72 MB/s per server.
In breve, la distribuzione finale dei sistemi deve disporre di una scheda di rete da 1 GB ed essere collegata a un'infrastruttura di rete in grado di supportare tale carico. Un'ulteriore nota è che, data la quantità di traffico di rete generato, il carico della CPU derivante dalle comunicazioni di rete può avere un impatto notevole e limitare la scalabilità massima di AD DS. Lo stesso processo può essere utilizzato per stimare la quantità di comunicazioni in entrata al controller di dominio. Tuttavia, data la predominanza del traffico in uscita rispetto a quello in entrata, si tratta di un esercizio accademico per la maggior parte degli ambienti. Garantire il supporto hardware per RSS è importante in ambienti con più di 5.000 utenti per server. In scenari con un elevato traffico di rete, il bilanciamento del carico di interruzione può rappresentare un problema. Ciò può essere rilevato da Processore(*)% Tempo di interrupt distribuito in modo non uniforme tra le CPU. Le schede di interfaccia di rete abilitate per RSS possono attenuare questa limitazione e aumentare la scalabilità.
Nota
Un approccio simile può essere utilizzato per stimare la capacità aggiuntiva necessaria quando si consolidano i data center o si dismette un controller di dominio in una sede satellite. È sufficiente rilevare il traffico in uscita e in entrata verso i client e questa sarà la quantità di traffico presente sui collegamenti WAN.
In alcuni casi, il traffico potrebbe essere superiore a quello previsto perché il traffico è più lento, ad esempio quando la verifica dei certificati non riesce a rispettare i timeout ripetuti sulla WAN. Per questo motivo, il dimensionamento e l'utilizzo della WAN devono essere effettuati in modo iterativo e continuo.
Considerazioni sulla virtualizzazione per la larghezza di banda della rete
Per un server fisico i consigli sono semplici: 1 GB per i server che supportano più di 5000 utenti. Quando più guest iniziano a condividere un'infrastruttura di switch virtuale sottostante, è necessario prestare maggiore attenzione per garantire che l'host disponga di una larghezza di banda di rete sufficiente per supportare tutti i guest sul sistema, e quindi richiede un ulteriore precisione. Non si tratta di nient’altro che di un'estensione della garanzia dell'infrastruttura di rete alla macchina host. Ciò a prescindere dal fatto che la rete includa il controller di dominio in esecuzione come macchina virtuale guest su un host, con il traffico di rete che passa attraverso uno switch virtuale, o che sia collegata direttamente a uno switch fisico. Lo switch virtuale è solo un altro componente in cui l'uplink deve supportare la quantità di dati trasmessi. Pertanto, la scheda di rete fisica dell'host collegata allo switch deve essere in grado di supportare il carico del controller di dominio più tutti gli altri guest che condividono lo switch virtuale collegato alla scheda di rete fisica.
Esempio di riepilogo del calcolo
| Sistema | Larghezza di banda di picco |
|---|---|
| Controller di dominio 1 | 6,5 MB/s |
| Controller di dominio 2 | 6,25 MB/s |
| Controller di dominio 3 | 6,25 MB/s |
| Controller di dominio 4 | 5,75 MB/s |
| Controller di dominio 5 | 4,75 MB/s |
| Totali | 28,5 MB/s |
Consigliato: 72 MB/s (28,5 MB/s diviso 40%)
| Conteggio dei sistemi di destinazione | Larghezza di banda totale (dall'alto) |
|---|---|
| 2 | 28,5 MB/s |
| Risultato di un comportamento normale | 28,5 ÷ 2 = 14,25 MB/s |
Come sempre, con il passare del tempo si può ipotizzare che il carico dei client aumenterà e questa crescita deve essere pianificata nel miglior modo possibile. La quantità consigliata per la pianificazione prevede una crescita stimata del 50% del traffico di rete.
Archiviazione
La pianificazione dell’archiviazione è costituita da due componenti:
- La capacità o dimensione dell’archiviazione
- Prestazioni
Si spende una grande quantità di tempo e di documentazione per pianificare la capacità, spesso trascurando le prestazioni. Con gli attuali costi dell'hardware, la maggior parte degli ambienti non ha dimensioni tali da costituire un problema, e la raccomandazione di "inserire una quantità di RAM pari alle dimensioni del database" di solito è sufficiente, anche se potrebbe essere eccessiva per le sedi satellite negli ambienti di dimensioni maggiori.
Dimensionamento
Valutazione dell’archiviazione
Rispetto a 13 anni fa, quando è stata introdotta Active Directory e le unità da 4 GB e 9 GB erano le dimensioni più comuni, il dimensionamento per Active Directory è un aspetto che non viene nemmeno preso in considerazione per tutti gli ambienti, tranne quelli di dimensioni maggiori. Con dischi rigidi di dimensioni ridotte, nell'ordine dei 180 GB, l'intero sistema operativo, SYSVOL e NTDS.dit possono stare facilmente su una singola unità. Per questo motivo, si consiglia di non investire molto in quest'area.
L'unica raccomandazione da prendere in considerazione è quella di assicurarsi che sia disponibile il 110% delle dimensioni di NTDS.dit per consentire la deframmentazione. Inoltre, è necessario tenere conto della crescita nel corso del ciclo di vita dell'hardware.
La prima e più importante considerazione è la valutazione delle dimensioni di NTDS.dit e SYSVOL. Queste misure porteranno al dimensionamento dell'allocazione fissa del disco e della RAM. Dato il costo (relativamente) basso di questi componenti, non è necessario che i calcoli siano rigorosi e precisi. Per informazioni su come valutare questo aspetto sia per gli ambienti esistenti che per quelli nuovi sono disponibili, consultare la serie di articoli sull'Archiviazione dati. In particolare, fare riferimento ai seguenti articoli:
Per gli ambienti esistenti – La sezione intitolata "Per attivare la registrazione dello spazio su disco liberato dalla deframmentazione" nell'articolo Limiti di archiviazione.
Per i nuovi ambienti – L'articolo intitolato Stime di crescita per utenti e unità organizzative di Active Directory.
Nota
Gli articoli si basano su stime delle dimensioni dei dati effettuate al momento del rilascio di Active Directory in Windows 2000. Usare oggetti di dimensioni che riflettano le dimensioni effettive degli oggetti nell’ambiente personale.
Quando si esaminano ambienti esistenti con più domini, è possibile che vi siano variazioni nelle dimensioni dei database. In questo caso, utilizzare le dimensioni minime del catalogo globale (GC) e non le dimensioni GC.
Le dimensioni del database possono variare a seconda delle versioni del sistema operativo. I controller di dominio con sistemi operativi precedenti, come Windows Server 2003, hanno dimensioni del database inferiori a quelle di un controller di dominio con sistemi operativi con versioni successive, come Windows Server 2008 R2, soprattutto quando sono abilitate funzioni di Active Directory come cestino o roaming delle credenziali.
Nota
- Per i nuovi ambienti, si noti che le stime in Stime di crescita per utenti e unità organizzative di Active Directory indicano che 100.000 utenti (nello stesso dominio) consumano circa 450 MB di spazio. Si noti che gli attributi popolati possono avere un impatto enorme sulla quantità totale. Gli attributi saranno popolati su molti oggetti sia da prodotti di terze parti che da prodotti Microsoft, tra cui Microsoft Exchange Server e Lync. È preferibile effettuare una valutazione basata sul portafoglio di prodotti presenti nell'ambiente, ma potrebbe non valere la pena fare calcoli ed effettuare test per ottenere stime precise per tutti gli ambienti, tranne quelli di dimensioni maggiori.
- Assicurarsi che il 110% delle dimensioni di NTDS.dit sia disponibile come spazio libero per consentire la deframmentazione offline e pianificate la crescita nell'arco di un ciclo di vita hardware di tre-cinque anni. Considerato il basso costo di archiviazione, valutare una dimensione di archiviazione pari al 300% di quella del DIT come allocazione di archiviazione è sufficiente per gestire la crescita e la potenziale necessità di deframmentazione offline.
Considerazioni sulla virtualizzazione per l’archiviazione
In uno scenario in cui vengono allocati più file Disco rigido virtuale (VHD) su un singolo volume, usare un disco di dimensioni fisse pari ad almeno il 210% (100% del DIT + 110% di spazio libero) delle dimensioni del DIT per garantire che sia riservato uno spazio sufficiente.
Esempio di riepilogo del calcolo
| Dati raccolti in fase di valutazione | Dimensione |
|---|---|
| Dimensione NTDS.dit | 35 GB |
| Modificatore per consentire la deframmentazione offline | 2,1 GB |
| Archiviazione totale necessaria | 73,5 GB |
Nota
Questo spazio di archiviazione si aggiunge a quello necessario per SYSVOL, il sistema operativo, il file di paging, i file temporanei, i dati locali memorizzati nella cache (come i file di installazione) e le applicazioni.
Prestazioni dell'archiviazione
Valutazione delle prestazioni dell’archiviazione
Essendo il componente più lento di qualsiasi computer, l’archiviazione può avere il maggiore impatto negativo sull'esperienza client. Per gli ambienti di dimensioni tali da rendere impossibile il dimensionamento della RAM, le conseguenze di una mancata pianificazione dell’archiviazione possono essere devastanti in termini di prestazioni. Inoltre, le complessità e le varietà della tecnologia di archiviazione aumentano ulteriormente il rischio di errore, in quanto la pertinenza delle procedure consolidate consigliate, ovvero "mettere il sistema operativo, i registri e il database" su dischi fisici separati, è limitata ai scenari utili. Questo perché la procedura consolidata consigliata si basa sul presupposto che un "disco" sia uno spindle dedicato e che questo permetta di isolare l'I/O. I presupposti che lo rendono vero questo presupposto non sono più rilevanti con l'introduzione di:
- RAID
- Nuovi tipi di risorse di archiviazione e scenari di archiviazione virtualizzata e condivisa
- Spindle condivisi su una Rete di archiviazione (SAN)
- File VHD su una SAN o su un’archiviazione collegata alla rete
- Unità a stato solido (SSD)
- Architetture di archiviazione a livelli (ad esempio, livelli di archiviazione SSD con memorizzazione nella cache di archiviazione basata su spindle di dimensioni maggiori)
In particolare, le risorse di archiviazione condivise (RAID, SAN, NAS, JBOD (cioè Spazi di archiviazione), VHD) sono tutte in grado di essere sovrascritte o sovraccariche a causa di altri carichi di lavoro che vengono collocati sull’archiviazione back end. A ciò si aggiunge il fatto che i problemi di SAN/rete/driver (tutto ciò che si trova tra il disco fisico e l'applicazione AD) possono causare strozzature e/o ritardi. Per maggiore chiarezza, non si tratta di configurazioni "errate", ma di configurazioni più complesse che richiedono il corretto funzionamento di tutti i componenti e quindi un'attenzione supplementare per garantire prestazioni accettabili. Per maggiori informazioni, consultare l'Appendice C, sottosezione "Introduzione alle SAN", e l'Appendice D di seguito in questo documento. Inoltre, mentre le unità allo stato solido non hanno i limiti dei dischi tradizionali (dischi rigidi) per quanto riguarda l'elaborazione di un solo IO alla volta, hanno comunque dei limiti di IO e sono possibili sovraccarichi/sovrascritture delle unità SSD. In breve, l'obiettivo finale di tutti gli sforzi per le prestazioni di archiviazione, indipendentemente dall'architettura e dalla progettazione dell’archiviazione di base, è di garantire la disponibilità della quantità necessaria di operazioni di input/output al secondo (IOPS) e che tali IOPS avvengano entro un lasso di tempo accettabile (come specificato in altre parti del presente documento). Per gli scenari con archiviazione collegata a livello locale, si rimanda all'Appendice C per le nozioni di base sulla progettazione di scenari di archiviazione locale di tipo tradizionale. Questi principi sono generalmente applicabili a livelli di archiviazioni più complesse e saranno utili anche nel dialogo con i fornitori con soluzioni di archiviazione back-end.
- Data l'ampia gamma di opzioni di risorse di archiviazione disponibili, si consiglia di rivolgersi ai team di supporto hardware o ai fornitori per assicurarsi che la soluzione specifica soddisfi le esigenze di AD DS. I numeri seguenti costituiscono le informazioni da fornire agli esperti di archiviazione.
Per gli ambienti in cui il database di dimensioni troppo grandi per essere conservato nella RAM, usare i contatori delle prestazioni per determinare la quantità di I/O da supportare:
- Disco logico(*)\Media sec/lettura disco (ad esempio, se NTDS.dit è memorizzato sull'unità D:/, il percorso completo è Disco logico(D:)\Media sec/lettura disco)
- Disco logico(*)\Media sec/scrittura disco
- Disco logico(*)\Media sec/trasferimento disco
- Disco logico(*)\Letture/sec
- Disco logico(*)\Scritture/sec
- Disco logico(*)\Trasferimenti/sec
Questi dovrebbero essere campionati a intervalli di 15/30/60 minuti per valutare le esigenze dell'ambiente corrente.
Valutazione dei risultati
Nota
L'attenzione si concentra sulla lettura del database, che di solito è la componente più impegnativa; la stessa logica può essere applicata alle scritture del file di log, sostituendo Disco logico con (<Log NTDS>)\Avg Disk sec/Write e Disco logico(<Log NTDS>)\Scritture/sec):
- Disco logico(<NTDS>)\Media sec/lettura disco indica se lo spazio di archiviazione corrente è di dimensioni adeguate o meno. Se i risultati sono all'incirca uguali al tempo di accesso al disco per il tipo di disco, Disco logico(<NTDS>)\Letture/sec è una misura valida. Verificare le specifiche del produttore per l’archiviazione sul back-end, tuttavia un buon intervallo per Disco logico(<NTDS>)\Media sec/lettura disco è approssimativamente:
- 7.200 - da 9 a 12,5 millisecondi (ms)
- 10.000 - da 6 a 10 ms
- 15.000 - da 4 a 6 ms
- SSD - da 1 a 3 ms
-
Nota
Le indicazioni che si possono trarre sono che le prestazioni di archiviazione si riducono a 15-20 ms (a seconda dell’origine). La differenza tra i valori sopra indicati e le altre indicazioni è che i valori sopra indicati rappresentano il normale intervallo operativo. Le altre indicazioni rappresentano una guida alla risoluzione dei problemi per individuare quando l'esperienza client si riduce in modo significativo e risulta evidente. Per maggiori informazioni, fare riferimento all'Appendice C.
- Disco logico(<NTDS>)\Letture/sec è la quantità di I/O che viene eseguita.
- Se Disco logico(<NTDS>)\Media sec/lettura disco rientra nell'intervallo ottimale per l’archiviazione back-end, Disco logico(<NTDS>)\Letture/sec può essere usato direttamente per dimensionare l’archiviazione.
- Se Disco logico(<NTDS>)\Media sec/lettura disco non rientra nell'intervallo ottimale per l’archiviazione back-end, è necessario un I/O aggiuntivo secondo la seguente formula: (Disco logico(<NTDS>)\Media sec/lettura disco) ÷ (Tempo di accesso al disco del supporto fisico) × (Disco logico(<NTDS>)\Media sec/lettura disco)
Considerazioni:
- Si noti che se il server è configurato con una quantità di RAM non ottimale, questi valori non saranno accurati ai fini della pianificazione. I valori saranno erroneamente alti ma potranno comunque essere utilizzati come scenario peggiore.
- L'aggiunta/ottimizzazione della RAM, in particolare, determinerà una diminuzione della quantità di I/O in lettura (Disco logico(<NTDS>)\Letture/Sec. Ciò significa che la soluzione di archiviazione potrebbe non essere così affidabile come calcolato inizialmente. Purtroppo, qualsiasi indicazione più specifica di questa affermazione generale dipende dall'ambiente e dal carico del client e non è possibile fornire indicazioni generali. L'opzione migliore è quella di regolare il dimensionamento di archiviazione dopo aver ottimizzato la RAM.
Considerazioni sulla virtualizzazione per le prestazioni
Come in tutte le precedenti discussioni sulla virtualizzazione, è fondamentale garantire che l'infrastruttura condivisa di base sia in grado di supportare il carico del controller di dominio più le altre risorse che utilizzano il supporto condiviso di base e tutti i percorsi verso di esso. Questo vale sia nel caso in cui un controller di dominio fisico condivida lo stesso supporto sottostante su un'infrastruttura SAN, NAS o iSCSI con altri server o applicazioni, sia nel caso in cui un guest utilizzi l'accesso pass-through a un'infrastruttura SAN, NAS o iSCSI che condivide il supporto sottostante, sia nel caso in cui il guest utilizzi un file VHD che risiede su un supporto condiviso a livello locale o su un'infrastruttura SAN, NAS o iSCSI. L'esercizio di pianificazione consiste nell'assicurarsi che il supporto sottostante sia in grado di supportare il carico totale di tutti i consumer.
Inoltre, dal punto di vista del guest, poiché è necessario utilizzare ulteriori percorsi di codice, l'accesso all'archiviazione attraverso un host ha un impatto in termini di prestazioni. Non sorprende che i test sulle prestazioni di archiviazione indichino che la virtualizzazione ha un impatto sulla velocità effettiva che è soggettiva all'utilizzo del processore del sistema host (vedere Appendice A: Criteri di dimensionamento della CPU), che è ovviamente influenzato dalle risorse dell'host richieste dal guest. Ciò contribuisce alle considerazioni sulla virtualizzazione per quanto riguarda le esigenze di elaborazione in uno scenario virtualizzato (vedere Considerazioni sulla virtualizzazione per l'elaborazione).
A complicare la situazione c'è il fatto che sono disponibili diverse opzioni di archiviazione e che tutte hanno un impatto diverso sulle prestazioni. Per una stima affidabile durante la migrazione da fisico a virtuale, usare un moltiplicatore di 1,10 per adattarsi alle diverse opzioni di archiviazione per i guest virtualizzati su Hyper-V, come l'archiviazione pass-through, scheda SCSI o IDE. Le regolazioni da fare quando si passa da uno scenario di archiviazione all'altro sono irrilevanti a seconda che l’archiviazione sia locale, SAN, NAS o iSCSI.
Esempio di riepilogo del calcolo
Determinazione della quantità di I/O necessaria per un sistema efficiente in condizioni operative normali:
- Disco logico(<Unità database NTDS>)\Transfers/sec durante il periodo di picco 15 minuti
- Per determinare la quantità di I/O necessaria per l'archiviazione quando la capacità dell'archiviazione sottostante viene superata:
IOPS necessari = (Disco logico(<Unità database NTDS>)\Media sec/lettura disco ÷ <Media sec/lettura disco di destinazione>) × Disco logico(<Unità database NTDS>)\Lettura/sec
| Contatore | Valore |
|---|---|
| Actual Disco logico(<Unità database NTDS>)\Media sec/trasferimento disco | .02 secondi (20 millisecondi) |
| Target Disco logico(<Unità database NTDS>)\Media sec/trasferimento disco | .01 secondi |
| Moltiplicatore per la variazione dell'OI disponibile | 0,02 ÷ 0,01 = 2 |
| Nome valore | Valore |
|---|---|
| Disco logico(<Unità database NTDS>)\Trasferimenti/sec | 400 |
| Moltiplicatore per la variazione dell'OI disponibile | 2 |
| IOPS totali necessari durante il periodo di picco | 800 |
Per determinare la velocità di riscaldamento della cache:
- Determinare il tempo massimo accettabile per il riscaldamento della cache. Si tratta del tempo necessario per caricare l'intero database dal disco o, nel caso in cui non sia possibile caricare l'intero database nella RAM, del tempo massimo per riempire la RAM.
- Determinare la dimensione del database, escluso lo spazio vuoto. Per ulteriori informazioni, vedere Valutazione dell'archiviazione.
- Dividere la dimensione del database per 8 kB; questo numero sarà il totale degli IO necessari per caricare il database.
- Dividere gli IO totali per il numero di secondi nell'intervallo di tempo definito.
Si noti che la velocità calcolata, pur essendo accurata, non sarà esatta perché le pagine caricate in precedenza vengono eliminate se ESE non è configurato per avere una dimensione fissa della cache e AD DS utilizza per impostazione predefinita una dimensione variabile della cache.
| Punti dati da raccogliere | Valori |
|---|---|
| Tempo massimo accettabile per il riscaldamento | 10 minuti (600 secondi) |
| Dimensione database | 2 GB |
| Fase di calcolo | Formula | Risultato |
|---|---|---|
| Calcolo della dimensione del database in pagine | (2 GB × 1.024 × 1024) = Dimensione del database in KB | 2.097.152 kB |
| Calcolo del numero di pagine nel database | 2.097.152 kB ÷ 8 kB = Numero di pagine | 262.144 pagine |
| Calcolo degli IOPS necessari per riscaldare completamente la cache | 262.144 pagine ÷ 600 secondi = IOPS necessari | 437 IOPS |
Elaborazione
Valutazione dell'uso del processore di Active Directory
Per la maggior parte degli ambienti, dopo che l’archiviazione, la RAM e la rete sono stati adeguatamente regolati come descritto nella sezione Pianificazione, la gestione della capacità di elaborazione sarà il componente che merita maggiore attenzione. La valutazione della capacità di elaborazione necessaria presenta due problemi:
Se le applicazioni dell'ambiente vengono gestite in modo corretto nell’ambito di un'infrastruttura di servizi condivisi, come illustrato nella sezione intitolata "Tracciamento delle ricerche costose e inefficienti" dell'articolo Creare applicazioni abilitate all’uso di Microsoft Active Directory più efficienti o migrare dalle chiamate SAM di basso livello alle chiamate LDAP.
In ambienti di maggiori dimensioni, questo è importante perché le applicazioni mal codificate possono causare una volatilità del carico della CPU, "rubare" una quantità smodata di tempo della CPU ad altre applicazioni, aumentare artificialmente le esigenze di capacità e distribuire in modo non uniforme il carico sui controller di dominio.
Poiché AD DS è un ambiente distribuito con un'ampia varietà di client potenziali, la stima del costo di un "singolo client" è soggettiva in termini di ambiente a causa dei modelli di utilizzo e del tipo o della quantità di applicazioni che sfruttano AD DS. In breve, come nel caso della sezione dedicata alla rete, per ottenere un'ampia applicabilità, è meglio affrontare questo aspetto dal punto di vista della valutazione della capacità totale necessaria nell'ambiente.
Per gli ambienti esistenti, poiché il dimensionamento dell’archiviazione è stato discusso in precedenza, si presume che l’archiviazione sia ora dimensionata correttamente e che quindi i dati relativi al carico del processore siano validi. È fondamentale assicurarsi che il problema del sistema non sia rappresentato dalle prestazioni di archiviazione. Quando si verifica un collo di bottiglia e il processore è in attesa, esistono stati di inattività che si risolvono una volta eliminato il problema. Quando gli stati di attesa del processore vengono rimossi, per definizione, l'utilizzo della CPU aumenta perché non deve più attendere i dati. Raccogliere quindi i contatori delle prestazioni "Disco logico(<Unità database NTDS>)\Media sec/lettura disco" e "Processo(lsass)\% tempo del processore". I dati in "Processo(lsass)\% tempo del processore" saranno artificialmente bassi se "Disco logico(<Unità database NTDS>)\Media sec/lettura disco" supera i 10-15 ms, una soglia generale utilizzata dal supporto tecnico Microsoft per la risoluzione dei problemi di prestazioni legati all’archiviazione. Come detto in precedenza, si consigliano intervalli di campionamento di 15, 30 o 60 minuti. Qualsiasi valore inferiore sarà generalmente troppo volatile per ottenere buone misurazioni; qualsiasi valore superiore attenuerà eccessivamente i picchi giornalieri.
Introduzione
Per pianificare la capacità dei controller di dominio, la potenza di elaborazione richiede la massima attenzione e comprensione. Nel dimensionamento dei sistemi per garantire le massime prestazioni, vi è sempre un componente che rappresenta il collo di bottiglia e in un controller di dominio correttamente dimensionato sarà il processore.
Come per la sezione dedicata alla rete, dove la richiesta dell'ambiente viene esaminata sito per sito, lo stesso deve essere fatto per la capacità di calcolo richiesta. A differenza della sezione dedicata alla rete, dove le tecnologie di rete disponibili superano di gran lunga la normale richiesta, si presti maggiore attenzione al dimensionamento della capacità della CPU. Come in ogni ambiente di dimensioni anche solo moderate, qualsiasi cosa che superi le poche migliaia di utenti simultanei può comportare un carico notevole sulla CPU.
Purtroppo, a causa dell'enorme variabilità delle applicazioni client che sfruttano AD, una stima generale degli utenti per CPU non è purtroppo applicabile a tutti gli ambienti. In particolare, le richieste di calcolo sono soggette al comportamento degli utenti e al profilo delle applicazioni. Pertanto, ogni ambiente deve essere dimensionato individualmente.
Profilo comportamentale del sito di destinazione
Come accennato in precedenza, quando si pianifica la capacità di un intero sito, l'obiettivo è di ottenere una progettazione con capacità N + 1, in modo che l’errore di un sistema durante il periodo di picco consenta di continuare il servizio ad un livello di qualità ragionevole. Ciò significa che in uno scenario "N", il carico di tutti box dovrebbe essere inferiore al 100% (ancora meglio, inferiore all'80%) durante i periodi di picco.
Inoltre, se le applicazioni e i client del sito applicano le procedure consigliate per la localizzazione dei controller di dominio (ossia, usano la funzione DsGetDcName), i client dovrebbero essere distribuiti in modo relativamente uniforme, con piccoli picchi transitori dovuti a diversi fattori.
Nell'esempio successivo, si fanno le seguenti ipotesi:
- Ciascuno dei cinque controller di dominio del sito dispone di quattro CPU.
- L'uso totale della CPU di destinazione durante l'orario di attività è del 40% in condizioni operative normali ("N + 1") e del 60% in caso contrario ("N"). Durante le ore di non attività, l'uso della CPU di destinazione è dell'80% perché si prevede che il software di backup e altri interventi di manutenzione consumino tutte le risorse disponibili.
Analizzando i dati del grafico (Processor Information(_Total)\% Processor Utility) per ciascuno dei controller di dominio:
Per la maggior parte, il carico è distribuito in modo relativamente uniforme, come ci si aspetterebbe quando i client utilizzano il localizzatore del controller di dominio e hanno ricerche ben congegnate.
Vi sono alcuni picchi di cinque minuti del 10%, con alcuni che raggiungono il 20%. In genere, a meno che non causino il superamento dell'obiettivo del piano di capacità, non vale la pena indagare su questi casi.
Il periodo di picco per tutti i sistemi è tra le 8:00 e le 9:15 circa. Con una transizione graduale dalle 5:00 del mattino alle 17:00 circa, questo periodo è generalmente indicativo del ciclo di attività. I picchi più randomizzati di utilizzo della CPU in uno scenario box-by-box tra le 17:00 e le 4:00 del mattino non rientrano nella pianificazione della capacità.
Nota
In un sistema ben gestito, questi picchi potrebbero essere dovuti all'esecuzione del software di backup, alle scansioni antivirus dell'intero sistema, all'inventario dell'hardware o del software, alla distribuzione di software o patch e così via. Poiché non rientrano nei picchi di attività degli utenti, gli obiettivi non vengono superati.
Dato che ogni sistema ha circa il 40% e tutti i sistemi hanno lo stesso numero di CPU, in caso di errore o di messa fuori linea di uno di essi, i sistemi rimanenti funzionerebbero al 53% circa (il carico del 40% del sistema D viene diviso equamente e aggiunto al carico del 40% del sistema A e del sistema C). Per una serie di motivi, questa ipotesi lineare non è del tutto accurata, ma fornisce una precisione sufficiente per effettuare una valutazione.
Scenario alternativo – Due controller di dominio funzionanti al 40%: se in un controller di dominio si verifica un errore, la CPU stimata sul controller rimanente sarebbe dell'80%. Questo supera di gran lunga le soglie descritte in precedenza per il piano di capacità e inizia anche a limitare fortemente la quantità di spazio per il 10%-20% visto nel profilo di carico di cui sopra, il che significa che i picchi porterebbero il controller di dominio al 90%-100% durante lo scenario "N" e degraderebbero sicuramente la reattività.
Calcolo delle richieste della CPU
Il contatore dell'oggetto di prestazione "Processo% tempo processore somma la quantità totale di tempo che tutti i thread di un'applicazione trascorrono sulla CPU e la divide per la quantità totale di tempo del sistema trascorso. L'effetto è che un'applicazione a thread multipli su un sistema con più CPU può superare il 100% del tempo della CPU e verrebbe interpretata in modo MOLTO diverso rispetto a "Informazioni sul processore% Utilità processore". In pratica, "Processo(lsass)´% Tempo processore" può essere considerato come il numero di CPU funzionanti al 100% necessarie per supportare le richieste del processo. Un valore di 200% indica che sono necessarie 2 CPU, ciascuna al 100%, per supportare l'intero carico di AD DS. Sebbene una CPU funzionante al 100% della capacità sia la più efficiente dal punto di vista dei costi per le CPU e del consumo di energia, per una serie di motivi descritti nell'Appendice A, una migliore reattività su un sistema a più thread si verifica quando il sistema non funziona al 100%.
Per far fronte a picchi transitori di carico dei client, si consiglia di puntare a una CPU di picco compresa tra il 40% e il 60% della capacità del sistema. Con l'esempio precedente, ciò indica che per il carico di AD DS (processo lsass) sarebbero necessarie tra 3,33 (obiettivo del 60%) e 5 (obiettivo del 40%) CPU. È necessario aggiungere ulteriore capacità in base alle esigenze del sistema operativo di base e degli altri agenti richiesti (come antivirus, backup, monitoraggio e così via). Sebbene l'impatto degli agenti debba essere valutato per ogni ambiente, si può fare una stima tra il 5% e il 10% di una singola CPU. Nell'esempio attuale, ciò suggerisce che durante i periodi di picco sono necessarie tra 3,43 (obiettivo del 60%) e 5,1 (obiettivo del 40%) CPU.
The easiest way to do this is to use the “Stacked Area” view in Windows Reliability and Performance Monitor (perfmon), making sure all of the counters are scaled the same.
Presupposti:
- L'obiettivo è ridurre l'ingombro al minor numero possibile di server. Idealmente, un server dovrebbe supportare il carico e un altro server aggiunto per la ridondanza (scenario N + 1).
Conoscenza acquisita dai dati del grafico (Processo(lsass)\% tempo processore):
- La giornata operativa inizia a intensificarsi verso le 7:00 e diminuisce alle 17:00.
- Il periodo di massima attività va dalle 9.30 alle 11.00.
Nota
Tutti i dati relativi alle prestazioni sono di tipo cronologico. Il punto di picco alle 9:15 indica il carico dalle 9:00 alle 9:15.
- Si registrano picchi prima delle 7:00 del mattino, che potrebbe indicare un carico proveniente da diversi fusi orari o un'attività infrastrutturale in background, come i backup. Poiché il picco alle 9:30 supera questa attività, non è rilevante.
- Nel sito sono presenti tre controller di dominio.
Al massimo carico, lsass consuma circa il 485% di una CPU, ovvero 4,85 CPU al 100%. Secondo i calcoli precedenti, ciò significa che il sito necessita di circa 12,25 CPU per AD DS. Se si aggiungono le indicazioni di cui sopra, dal 5% al 10% per i processi in background, significa che la sostituzione odierna del server richiederebbe circa 12,30-12,35 CPU per supportare lo stesso carico. Ora è necessario considerare una stima della crescita dal punto di vista dell'ambiente.
Quando ottimizzare LDAP Weights
Esistono diversi scenari in cui è necessario prendere in considerazione la regolazione di LdapSrvWeight. Nell'ambito della pianificazione della capacità, ciò avverrebbe quando i carichi delle applicazioni o degli utenti non sono bilanciati o i sistemi sottostanti non sono bilanciati in termini di capacità. I motivi per eseguire questa operazione, al di là della pianificazione della capacità, esulano dallo scopo di questo articolo.
Sono due le ragioni più comuni per ottimizzare LDAP Weights:
- L'emulatore PDC è un esempio che riguarda tutti gli ambienti in cui il carico degli utenti o delle applicazioni non è uniformemente distribuito. Poiché alcuni strumenti e azioni sono rivolti all'emulatore PDC, come gli strumenti di gestione dei Criteri di gruppo, i secondi tentativi in caso di errore di autenticazione, l'instaurazione di trust e così via, le risorse della CPU sull'emulatore PDC possono essere richieste in misura maggiore rispetto ad altre parti del sito.
- È utile ottimizzare questo aspetto solo se vi è una differenza notevole nell'utilizzo della CPU, in modo da ridurre il carico sull'emulatore PDC e aumentare il carico sugli altri controller di dominio per permettere una distribuzione più uniforme del carico.
- In questo caso, impostare LDAPSrvWeight tra 50 e 75 per l'emulatore PDC.
- Server con un numero diverso di CPU (e velocità) in un sito. Ad esempio, supponiamo che vi siano due server a otto core e un server a quattro core. L'ultimo server ha la metà dei processori degli altri due server. Ciò indica che un carico di client ben distribuito aumenterà il carico medio della CPU sul server a quattro core a circa il doppio di quello dei server a otto core.
- Ad esempio, i due box a otto core funzionerebbero al 40% e il box a quattro core all'80%.
- Si consideri anche l'impatto della perdita di un box a otto core in questo scenario, in particolare il fatto che il box a quattro core sarebbe ora sovraccarico.
Esempio 1 - PDC
| Sistema | Utilizzo con valori predefiniti | Nuovo LdapSrvWeight | Stima del nuovo utilizzo |
|---|---|---|---|
| Controller di dominio 1 (emulatore PDC) | 53% | 57 | 40 % |
| Controller di dominio 2 | 33% | 100 | 40 % |
| Controller di dominio 3 | 33% | 100 | 40 % |
Il problema è che se il ruolo di emulatore PDC viene trasferito o acquisito, in particolare a un altro controller di dominio del sito, il nuovo emulatore PDC subirà un drastico aumento.
Utilizzando l'esempio della sezione Profilo di comportamento del sito di destinazione, si è ipotizzato che tutti e tre i controller di dominio del sito dispongano di quattro CPU. Cosa accadrebbe, in condizioni normali, se uno dei controller di dominio disponesse di otto CPU? Vi sarebbero due controller di dominio al 40% di utilizzo e uno al 20%. Sebbene questo non rappresenti un problema, vi è la possibilità di bilanciare meglio il carico. A tal fine, è possibile sfruttare LDAP Weights. Un esempio di scenario potrebbe essere:
Esempio 2 - Conteggio CPU diverso
| Sistema | Informazioni sul processore % Utilità processore (_Totale) Utilizzo con valori predefiniti |
Nuovo LdapSrvWeight | Stima del nuovo utilizzo |
|---|---|---|---|
| 4-CPU, Controller di dominio 1 | 40 | 100 | 30% |
| 4-CPU, Controller di dominio 2 | 40 | 100 | 30% |
| 8-CPU, Controller di dominio 3 | 20 | 200 | 30% |
Fare però molta attenzione a questi scenari. Come si può vedere qui sopra, il calcolo risulta perfetto sulla carta. Ma in tutto questo articolo, la pianificazione per uno scenario "N + 1" è di fondamentale importanza. L'impatto di un controller di dominio che va offline deve essere calcolato per ogni scenario. Nello scenario immediatamente precedente, in cui la distribuzione del carico è uniforme, per garantire un carico del 60% durante uno scenario "N", con il carico bilanciato in modo uniforme su tutti i server, la distribuzione risulterà corretta poiché i rapporti rimarranno costanti. Osservando lo scenario di ottimizzazione dell'emulatore PDC, e in generale qualsiasi scenario in cui il carico degli utenti o delle applicazioni non è bilanciato, l'effetto è molto diverso:
| Sistema | Uso ottimizzato | Nuovo LdapSrvWeight | Stima del nuovo uso |
|---|---|---|---|
| Controller di dominio 1 (emulatore PDC) | 40 % | 85 | 47% |
| Controller di dominio 2 | 40 % | 100 | 53% |
| Controller di dominio 3 | 40 % | 100 | 53% |
Considerazioni sulla virtualizzazione per l'elaborazione
La pianificazione della capacità in un ambiente virtualizzato deve avvenire su due livelli. A livello di host, analogamente all'individuazione del ciclo operativo delineato in precedenza per l'elaborazione del controller di dominio, è necessario individuare le soglie durante il periodo di picco. Poiché i principi sottostanti sono gli stessi per una macchina host che pianifica i thread guest sulla CPU e per ottenere thread AD DS sulla CPU di una macchina fisica, si consiglia lo stesso obiettivo del 40%-60% sull'host sottostante. Al livello successivo, il livello guest, poiché i principi di pianificazione dei thread non sono variati, l'obiettivo all'interno del guest rimane nell'intervallo 40%-60%.
In uno scenario con mappatura diretta, un guest per host, tutta la pianificazione della capacità effettuata fino a questo punto deve essere aggiunta ai requisiti (RAM, disco, rete) del sistema operativo host sottostante. In uno scenario di host condiviso, i test indicano un impatto del 10% sull'efficienza dei processori sottostanti. Ciò significa che se un sito ha bisogno di 10 CPU con un obiettivo del 40%, la quantità consigliata di CPU virtuali da allocare tra tutti gli "N" guest sarebbe 11. In un sito con una distribuzione mista di server fisici e server virtuali, il modificatore si applica solo alle macchine virtuali. Ad esempio, se un sito presenta uno scenario "N + 1", un server fisico o con mapping diretto con 10 CPU equivarrebbe a un guest con 11 CPU su un host, con 11 CPU riservate al controller di dominio.
Durante l'analisi e il calcolo delle quantità di CPU necessarie per supportare il carico di AD DS, i numeri di CPU che corrispondono a quanto è possibile acquistare in termini di hardware fisico non sono necessariamente chiari. La virtualizzazione elimina la necessità di arrotondamento. La virtualizzazione riduce lo sforzo necessario per aggiungere capacità di calcolo a un sito, data la facilità con cui è possibile aggiungere una CPU a una macchina virtuale. Non elimina però la necessità di valutare accuratamente la potenza di calcolo necessaria, in modo che l'hardware di base sia disponibile quando è necessario aggiungere altre CPU ai guest. Come sempre, ricordare di pianificare e monitorare la crescita della richiesta.
Esempio di riepilogo del calcolo
| Sistema | Picco CPU |
|---|---|
| Controller di dominio 1 | 120% |
| Controller di dominio 2 | 147% |
| Dc 3 | 218% |
| CPU totale utilizzata | 485% |
| Conteggio dei sistemi di destinazione | Larghezza di banda totale (dall'alto) |
|---|---|
| CPU necessarie al 40% della destinazione | 4,85 ÷ .4 = 12,25 |
Ripetendo l'importanza di questo punto, ricordarsi di pianificare la crescita. Ipotizzando una crescita del 50% nei prossimi tre anni, questo ambiente avrà bisogno di 18,375 CPU (12,25 × 1,5) al termine dei tre anni. Un piano alternativo potrebbe essere quello di riesaminare la situazione dopo il primo anno e aggiungere ulteriore capacità, se necessario.
Carico di autenticazione client cross-trust per NTLM
Valutazione del carico di autenticazione client cross-trust
Molti ambienti possono disporre di uno o più domini collegati da un trust. Una richiesta di autenticazione per un'identità in un altro dominio che non usa l'autenticazione Kerberos deve attraversare un trust usando il canale sicuro del controller di dominio verso un altro controller di dominio nel dominio di destinazione o nel dominio successivo nel percorso verso il dominio di destinazione. Il numero di chiamate simultanee al canale sicuro che un controller di dominio può effettuare verso un controller di dominio in un dominio attendibile è controllato da un'impostazione nota come MaxConcurrentAPI. Per i controller di dominio, la garanzia che il canale sicuro sia in grado di gestire la quantità di carico si ottiene con uno dei due approcci: l’ottimizzazione di MaxConcurrentAPI o, all'interno di una foresta, la creazione di trust di collegamento. Per valutare il volume di traffico su un singolo trust, fare riferimento a Come eseguire l’ottimizzazione delle prestazioni per l'autenticazione NTLM utilizzando l'impostazione MaxConcurrentApi.
Durante la raccolta dei dati, questo, come tutti gli altri scenari, deve essere acquisito durante i periodi di massima attività del giorno affinché i dati siano fruibili.
Nota
Gli scenari intraforestali e interforestali possono far sì che l'autenticazione attraversi più trust e ogni fase deve essere oggetto di ottimizzazione.
Pianificazione
Esistono numerose applicazioni che utilizzano l'autenticazione NTLM per impostazione predefinita o in un determinato scenario di configurazione. I server delle applicazioni aumentano di capacità e servono un numero crescente di client attivi. Inoltre, i client mantengono le sessioni aperte per un periodo di tempo limitato e si riconnettono regolarmente (come nel caso della sincronizzazione delle e-mail). Un altro esempio comune di carico elevato di NTLM è rappresentato dai server proxy web che richiedono l'autenticazione per l'accesso a Internet.
Queste applicazioni possono causare un carico notevole per l'autenticazione NTLM, che può mettere sotto stress i controller di dominio, soprattutto quando gli utenti e le risorse si trovano in domini diversi.
Esistono diversi approcci alla gestione del carico cross-trust, che nella pratica vengono utilizzati congiuntamente piuttosto che in uno scenario esclusivo di uno o dell'altro. Di seguito sono elencate le opzioni possibili:
- Ridurre l'autenticazione cross-trust del client localizzando i servizi che un utente consuma nello stesso dominio in cui l'utente risiede.
- Aumentare il numero di canali sicuri disponibili. Questo è importante per il traffico intraforestale e interforestale ed è noto come trust di co.
- Ottimizzare le impostazioni predefinite di MaxConcurrentAPI.
Per ottimizzare MaxConcurrentAPI su un server esistente, l'equazione è:
New_MaxConcurrentApi_setting ≥ (semaphore_acquires + semaphore_time-outs) × average_semaphore_hold_time ÷ time_collection_length
Per ulteriori informazioni, consultare l'articolo KB 2688798: Come eseguire la regolazione delle prestazioni per l'autenticazione NTLM utilizzando l'impostazione MaxConcurrentApi.
Considerazioni sulla virtualizzazione
Nessuna, si tratta di un'impostazione di regolazione del sistema operativo.
Esempio di riepilogo del calcolo
| Tipo di dati | Valore |
|---|---|
| Acquisizioni di Semaphore (minimo) | 6,161 |
| Acquisizioni di Semaphore (massimo) | 6,762 |
| Timeout di Semaphore | 0 |
| Tempo medio di attesa di Semaphore | 0,012 |
| Durata della raccolta (secondi) | 1:11 minuti (71 secondi) |
| Formula (da KB 2688798) | ((6.762 – 6.161) + 0) × 0,012 / |
| Valore minimo per MaxConcurrentAPI | ((6.762 – 6.161) + 0) × 0012 ÷ 71 = .101 |
Per questo sistema e per questo lasso di tempo, i valori predefiniti sono accettabili.
Monitoraggio della conformità agli obiettivi di pianificazione della capacità
In questo articolo, si è discusso del fatto che la pianificazione e il ridimensionamento sono finalizzate al raggiungimento degli obiettivi di uso. Ecco un grafico riassuntivo delle soglie consigliate che devono essere monitorate per garantire che i sistemi operino entro soglie di capacità adeguate. Tenere presente che non si tratta di soglie di prestazioni, ma di soglie di pianificazione della capacità. Un server che opera al di sopra di queste soglie funzionerà, ma è ora di iniziare a verificare che tutte le applicazioni funzionino correttamente. Se le applicazioni funzionano correttamente comportano, è il momento di iniziare a valutare gli aggiornamenti dell'hardware o altre modifiche alla configurazione.
| Categoria | Contatore delle prestazioni | Intervallo/campionamento | Destinazione | Avviso |
|---|---|---|---|---|
| Processore | Informazioni sul processore (_totale)\% Utilità processore | 60 min | 40 % | 60% |
| RAM (Windows Server 2008 R2 o versioni precedenti) | Memoria disponibile MB | < 100 MB | N/D | < 100 MB |
| RAM (Windows Server 2012) | Memoria\Durata media cache standby a lungo termine | 30 min | Deve essere testato | Deve essere testato |
| Network | Interfaccia di rete(*)\Byte inviati/sec Interfaccia di rete(*)\Byte ricevuti/sec |
30 min | 40 % | 60% |
| Archiviazione | Disco logico(<Unità database NTDS>)\Media sec/lettura disco Disco logico(<Unità database NTDS>)\Media sec/scrittura disco |
60 min | 10 ms | 15 ms |
| Servizi AD | Netlogon(*)\Tempo medio di attesa di Semaphore | 60 min | 0 | 1 secondo |
Appendice A: criteri di dimensionamento della CPU
Definizioni
Processore (microprocessore) – un componente che legge ed esegue le istruzioni del programma
CPU – Central Processing Unit
Processore multi-core - più CPU sullo stesso circuito integrato
Multi-CPU più CPU, non sullo stesso circuito integrato
Processore logico – un motore di calcolo logico dalla prospettiva del sistema operativo
Ad esempio, hyperthreading di un core su un processore multi-core o su un processore a singolo core.
Poiché i sistemi server odierni dispongono di più processori, più processori multi-core e hyperthreading, queste informazioni sono generalizzate per coprire entrambi gli scenari. Pertanto, si utilizzerà il termine processore logico in quanto rappresenta la prospettiva del sistema operativo e dell'applicazione dei motori di elaborazione disponibili.
Parallelismo a livello di thread
Ogni thread è un'attività indipendente, poiché ogni thread dispone di proprio stack e di istruzioni proprie. Poiché AD DS è multithread e il numero di thread disponibili può essere ottimizzato utilizzando Come visualizzare e impostare i criteri LDAP in Active Directory utilizzando Ntdsutil.exe, la scalabilità si adatta bene su più processori logici.
Parallelismo a livello di dati
Ciò comporta la condivisione dei dati tra più thread all'interno di un processo (nel caso del solo processo AD DS) e tra più thread in più processi (in generale). Per quanto riguarda l'eccessiva semplificazione del caso, ciò significa che qualsiasi modifica ai dati si riflette su tutti i thread in esecuzione in tutti i vari livelli di cache (L1, L2, L3) su tutti i core che eseguono tali thread, oltre ad aggiornare la memoria condivisa. Le prestazioni possono ridursi durante le operazioni di scrittura, mentre tutte le varie locazioni di memoria vengono rese omogenee prima che l'elaborazione delle istruzioni possa procedere.
Velocità della CPU e considerazioni sui core multipli
La regola generale è che i processori logici più veloci riducono la durata dell'elaborazione di una serie di istruzioni, mentre un numero maggiore di processori logici consente di eseguire più operazioni simultaneamente. Queste regole empiriche vengono meno quando gli scenari divengono intrinsecamente più complessi, considerando il recupero dei dati dalla memoria condivisa, l'attesa sul parallelismo a livello di dati e l'overhead della gestione di thread multipli. È anche per questa ragione che la scalabilità nei sistemi multi-core non è lineare.
Considerare le seguenti analogie: si pensi a un'autostrada, dove ogni filo corrisponde a un'automobile, ogni corsia è un core e il limite di velocità è la velocità di clock.
- Se c'è una sola macchina sull'autostrada, non importa se vi sono due corsie o 12 corsie. Quell'auto andrà solo alla velocità consentita dal limite di velocità.
- Supponiamo che i dati di cui il thread necessita non siano immediatamente disponibili. L'analogia è che un tratto di strada viene chiuso. Se è presente una sola auto sull'autostrada, non importa quale sia il limite di velocità finché la corsia non viene riaperta (i dati vengono recuperati dalla memoria).
- Con l'aumento del numero di auto, aumenta anche l'overhead per la gestione del numero di auto. Paragonare l'esperienza di guida e la quantità di concentrazione necessaria quando la strada è praticamente vuota (ad esempio in tarda serata) rispetto a quando il traffico è intenso (ad esempio a metà pomeriggio, ma non nell'ora di punta). Considerare anche la quantità di concentrazione necessaria quando si guida su un'autostrada a due corsie, dove vi è solo un'altra corsia e ci si deve preoccupare della presenza di altri automobilisti, rispetto a un'autostrada a sei corsie dove ci si deve preoccupare alla presenza di un maggior numero di automobilisti.
Nota
L'analogia sullo scenario dell'ora di punta viene ampliata nella sezione successiva: Tempo di risposta/Come l'attività del sistema influisce sulle prestazioni.
Di conseguenza, le specifiche su processori più o meno veloci diventano altamente soggettive al comportamento dell'applicazione, che nel caso di AD DS è molto specifico per l'ambiente e varia persino da server a server all'interno di un ambiente. Per questo motivo i riferimenti riportati all'inizio dell'articolo non puntano troppo sulla precisione e includono un margine di sicurezza nei calcoli. Quando si prendono decisioni di acquisto basate sul budget, si consiglia di ottimizzare l'uso dei processori al 40% (o al numero desiderato per l'ambiente) prima di considerare l'acquisto di processori più veloci. L'aumento della sincronizzazione tra più processori riduce il reale vantaggio di un maggior numero di processori rispetto alla progressione lineare (un numero di processori 2 volte superiore fornisce meno di 2 volte la potenza di calcolo aggiuntiva disponibile).
Nota
La legge di Amdahl e la legge di Gustafson sono i concetti da applicare in questo caso.
Tempo di risposta/Come l'attività del sistema influisce sulle prestazioni
La teoria delle code è lo studio matematico delle linee di attesa (code). Nella teoria delle code, la legge di utilizzo è rappresentata dall'equazione:
U k = B ÷ T
Dove U k è la percentuale di utilizzo, B è la quantità di tempo occupato e T è il tempo totale di osservazione del sistema. Tradotto nel contesto di Windows, indica il numero di thread con intervallo di 100 nanosecondi (ns) che si trovano in stato di esecuzione diviso per il numero di intervalli di 100 ns disponibili in un determinato intervallo di tempo. Questa è esattamente la formula per calcolare la % di utilità del processore (riferimento a Oggetto processore e PERF_100NSEC_TIMER_INV).
La teoria delle code fornisce anche la formula: N = U k ÷ (1 – U k) per stimare il numero di elementi in attesa in base all'utilizzo (N è la lunghezza della coda). Il grafico relativo a tutti gli intervalli di utilizzo fornisce le seguenti stime sulla lunghezza della coda per accedere al processore in presenza di un determinato carico della CPU.
Si osserva che dopo il 50% di carico della CPU, in media c'è sempre un'attesa di un altro elemento nella coda, con un aumento notevolmente rapido dopo circa il 70% di utilizzo della CPU.
Tornando all'analogia con la guida utilizzata in precedenza in questa sezione:
- L'orario di punta di "metà pomeriggio" si situa ipoteticamente tra il 40% e il 70%. C'è abbastanza traffico da non limitare la possibilità di scegliere una corsia qualsiasi e la possibilità che un altro automobilista si trovi per strada, pur essendo elevata, non richiede il livello di sforzo necessario per "trovare" uno spazio sicuro tra le altre auto sulla strada.
- Si noterà che quando il traffico si avvicina all'ora di punta, la viabilità si avvicina al 100% della capacità. Cambiare corsia può diventare molto impegnativo, perché le auto sono così vicine che occorre prestare maggiore attenzione.
Per questo motivo, la media a lungo termine della capacità, stimata prudenzialmente al 40%, consente di tenere conto di eventuali picchi di carico anomali, siano essi transitori (come ad esempio query mal codificate che vengono eseguite per pochi minuti) o anomali picchi di carico generale (la mattina del primo giorno dopo un fine settimana lungo).
L'affermazione di cui sopra, secondo cui il calcolo della % tempo processore è uguale alla legge di utilizzo, è una semplificazione per facilitare il lettore comune. Per i più rigorosi dal punto di vista matematico:
- Traduzione di PERF_100NSEC_TIMER_INV
- B = il numero di intervalli di 100 ns che il thread "Inattivo" trascorre sul processore logico. La variazione della variabile "X" nel calcolo di PERF_100NSEC_TIMER_INV
- T = il numero totale di intervalli di 100 ns in un determinato intervallo di tempo. La variazione della variabile "Y" nel calcolo di PERF_100NSEC_TIMER_INV.
- U k = percentuale di utilizzo del processore logico da parte del "Thread inattivo" o % di tempo di inattività.
- Elaborazione dei calcoli:
- U k = 1 – % tempo processore
- % tempo processore = 1 – U k
- % tempo processore = 1 – B / T
- %Tempo processore = 1 – X1 – X0 / Y1 – Y0
Applicazione dei concetti alla pianificazione della capacità
I calcoli precedenti possono far sembrare eccessivamente complessa la determinazione del numero di processori logici necessari in un sistema. Per questo motivo, l'approccio al dimensionamento dei sistemi si concentra sulla determinazione dell'utilizzo massimo previsto in base al carico attuale e sul calcolo del numero di processori logici necessari per ottenerlo. Inoltre, mentre la velocità dei processori logici avrà un impatto significativo sulle prestazioni, l'efficienza della cache, i requisiti di coerenza a livello di memoria, la programmazione e la sincronizzazione dei thread e il carico non perfettamente bilanciato dei client avranno tutti un impatto significativo sulle prestazioni, che varieranno da server a server. Con il costo relativamente basso della potenza di calcolo, il tentativo di analizzare e determinare il numero perfetto di CPU necessarie diventa più un esercizio accademico che un valore aziendale.
Il 40% non è un requisito rigido, ma è un inizio ragionevole. I vari utenti di Active Directory richiedono diversi livelli di reattività. Vi possono essere scenari in cui gli ambienti possono funzionare all'80% o al 90% di utilizzo come media sostenuta, in quanto l'aumento dei tempi di attesa per l'accesso al processore non avrà un impatto significativo sulle prestazioni del client. È importante ribadire che vi sono molte aree del sistema molto più lente del processore logico del sistema, tra cui l'accesso alla RAM, l'accesso al disco e la trasmissione della risposta tramite la rete. Tutti questi elementi devono essere ottimizzati congiuntamente. Esempi:
- L'aggiunta di altri processori a un sistema che funziona al 90% su disco probabilmente non migliorerà in modo significativo le prestazioni. Un'analisi più approfondita del sistema probabilmente individuerà la presenza di molti thread che non arrivano nemmeno al processore perché sono in attesa del completamento dell'I/O.
- Risolvere i problemi legati al disco significa potenzialmente che i thread che prima passavano molto tempo in uno stato di attesa non saranno più in uno stato di attesa per l'I/O e vi sarà più competizione per il tempo della CPU, il che significa che l'utilizzo del 90% nell'esempio precedente passerà al 100% (perché non può andare oltre). Entrambi i componenti devono essere ottimizzati congiuntamente.
Nota
Informazioni sul processore(*)\% Utilità processore può superare il 100% con i sistemi dotati di modalità "Turbo". In questo caso la CPU supera la velocità nominale del processore per brevi periodi. Per maggiori informazioni, consultare la documentazione del produttore della CPU e la descrizione del contatore.
Le considerazioni sull'utilizzo dell'intero sistema riguardano anche i controller di dominio come guest virtualizzati. In uno scenario virtualizzato, il tempo di risposta/modo in cui l'occupazione del sistema influisce sulle prestazioni si applicano sia all'host che al guest. Per questo motivo, in un host con un solo guest, un controller di dominio (e in generale qualsiasi sistema) ha quasi le stesse prestazioni che ha sull'hardware fisico. L'aggiunta di altri guest agli host aumenta l'utilizzo dell'host sottostante, aumentando così i tempi di attesa per accedere ai processori, come spiegato in precedenza. In breve, l'utilizzo dei processori logici deve essere gestito sia a livello di host che di guest.
Estendendo le analogie precedenti, lasciando l'autostrada come hardware fisico, la macchina virtuale guest sarà paragonata a un autobus (un autobus espresso che va dritto alla destinazione desiderata dal passeggero). Immaginare i seguenti quattro scenari:
- È quasi orario di fine servizio, un passeggero sale su un autobus quasi vuoto e l'autobus si immette su una strada anch'essa quasi vuota. Poiché non c'è traffico, il passeggero ha la possibilità di viaggiare agevolmente e di arrivare a destinazione con la stessa velocità con cui avrebbe guidato. I tempi di percorrenza sono comunque limitati dal limite di velocità.
- È quasi orario di fine servizio, quindi l'autobus è quasi vuoto, ma la maggior parte delle corsie sono chiuse, quindi l'autostrada è comunque trafficata. Il passeggero si trova su un autobus quasi vuoto su una strada trafficata. Anche se il passeggero ha a disposizione quasi tutto l'autobus per sedersi, il tempo totale del viaggio è comunque dettato dal traffico esterno.
- È l'ora di punta, quindi l'autostrada e l'autobus è pieno e l’autostrada è trafficata. Non solo il viaggio è più lungo, ma salire e scendere dall'autobus è un incubo perché l'auto è affollato e l'autostrada non è molto meglio. L'aggiunta di un maggior numero di autobus (logici processori dell'ospite) non significa che questi possano circolare più facilmente per strada o che il viaggio si accorci.
- L'ultimo scenario, anche se forse è un po' esagerato, è quello in cui l'autobus è affollato, ma la strada non è trafficata. Anche se il passeggero avrà comunque difficoltà a salire e scendere dall'autobus, il viaggio sarà più efficiente una volta che l'autobus sarà per strada. Questo è l'unico scenario in cui l'aggiunta di più autobus (processori logici per l'ospite) migliorerà le prestazioni del passeggero.
Da qui è relativamente facile estrapolare che ci sono diversi scenari tra lo stato di utilizzo dello 0% e del 100% della strada e lo stato di utilizzo dello 0% e del 100% del bus che hanno diversi gradi di impatto.
Applicare i principi di cui sopra del 40% di CPU come obiettivo ragionevole sia per l'host che per il guest è un inizio ragionevole per lo stesso motivo di cui sopra, la quantità di code.
Appendice B: considerazioni sulle diverse velocità dei processori e sull'effetto della gestione dell'alimentazione dei processori sulle velocità degli stessi
In tutte le sezioni sulla selezione dei processori si ipotizza che il processore funzioni al 100% della velocità di clock per tutto il tempo in cui vengono raccolti i dati e che i sistemi sostitutivi abbiano processori della stessa velocità. Nonostante entrambe le ipotesi siano in pratica false, in particolare con Windows Server 2008 R2 e successivi, dove la combinazione per il risparmio di energia predefinita è Bilanciata, la metodologia è ancora applicabile in quanto rappresenta l'approccio conservativo. Sebbene il tasso di errore potenziale possa aumentare, il margine di sicurezza aumenta solo con l'aumentare della velocità dei processori.
- Ad esempio, in uno scenario in cui sono richieste 11,25 CPU, se i processori operavano a metà velocità quando i dati sono stati raccolti, la stima più accurata potrebbe essere 5.125 ÷ 2.
- È impossibile garantire che il raddoppio delle velocità di clock raddoppi la quantità di elaborazione in un determinato lasso di tempo. Ciò è dovuto al fatto che la quantità di tempo che i processori trascorrono in attesa della RAM o di altri componenti del sistema potrebbe rimanere invariata. L'effetto finale è che i processori più veloci potrebbero trascorrere una percentuale maggiore del tempo di inattività in attesa dei dati da recuperare. Anche in questo caso, si consiglia di attenersi al minimo comune denominatore, di essere prudenti e di evitare di cercare di calcolare un livello di precisione potenzialmente falso ipotizzando un confronto lineare tra le velocità dei processori.
In alternativa, se le velocità dei processori nell'hardware sostitutivo sono inferiori a quelle dell'hardware attuale, sarebbe opportuno aumentare la stima dei processori necessari in misura proporzionale. Ad esempio, si calcola che siano necessari 10 processori per sostenere il carico di un sito e che i processori attuali funzionino a 3,3 Ghz, mentre i processori sostitutivi funzioneranno a 2,6 Ghz, con una diminuzione della velocità del 21%. In questo caso, la quantità consigliata è di 12 processori.
Tuttavia, questa variabilità non modificherebbe gli obiettivi di utilizzo del processore di Gestione della capacità. Poiché le velocità di clock del processore saranno regolate dinamicamente in base al carico richiesto, l'esecuzione del sistema con carichi più elevati genererà uno scenario in cui la CPU trascorrerà più tempo in uno stato di velocità di clock più elevata, rendendo l'obiettivo finale di un utilizzo del 40% in uno stato di velocità di clock del 100% al picco. Qualsiasi valore inferiore a questo genererà un risparmio di energia, poiché la velocità della CPU sarà ridotta durante gli scenari di picco.
Nota
Un'opzione potrebbe essere quella di disattivare la gestione dell'energia sui processori (impostando il piano energetico su Prestazioni elevate) durante la raccolta dei dati. In questo modo si otterrebbe una rappresentazione più accurata del consumo di CPU sul server di destinazione.
Per adattare le stime ai diversi processori, in passato era sicuro, escludendo gli altri colli di bottiglia del sistema descritti in precedenza, assumere che il raddoppio della velocità del processore raddoppiasse la quantità di elaborazione che poteva essere eseguita. Oggi l'architettura interna dei processori è talmente diversa da un processore all'altro che un modo più sicuro per valutare gli effetti dell'uso di processori diversi da quelli da cui sono stati presi i dati è quello di utilizzare il benchmark SPECint_rate2006 della Standard Performance Evaluation Corporation.
Trovare i punteggi SPECint_rate2006 per i processori in uso e per quelli che si prevede di utilizzare.
- Sul sito web della Standard Performance Evaluation Corporation, selezionare Risultati, evidenziare CPU2006 e selezionare Cerca tutti i risultati di SPECint_rate2006.
- In Richiesta semplice, inserire i criteri di ricerca per il processore di destinazione, ad esempio Processor Matches E5-2630 (baselinetarget) e Processor Matches E5-2650 (baseline).
- Individuare la configurazione del server e del processore da utilizzare (o qualcosa di simile, se non è disponibile una corrispondenza esatta) e annotare il valore nelle colonne Risultato e Numero di core.
Per determinare il modificatore, utilizzare la seguente equazione:
((Valore del punteggio per-core della piattaforma target) × (MHz per-core della piattaforma di base)) ÷ ((Valore del punteggio per-core della piattaforma di base) × (MHz per-core della piattaforma target))
Utilizzando l'esempio precedente:
(35,83 × 2.000) ÷ (33,75 × 2.300) = 0,92
Moltiplicare il numero stimato di processori per il modificatore. Nel caso precedente, per passare dal processore E5-2650 al processore E5-2630, moltiplicare le 11,25 CPU calcolate × 0,92 = 10,35 processori necessari.
Appendice C: Nozioni fondamentali sul sistema operativo che interagisce con l’archiaviazione
I concetti della teoria delle code illustrati in Tempo di risposta/Come l'occupazione del sistema influisce sulle prestazioni sono applicabili anche all'archiviazione. Per applicare questi concetti è necessario avere una certa familiarità con il modo in cui il sistema operativo gestisce l'I/O. Nel sistema operativo Microsoft Windows, per ogni disco fisico viene creata una coda per accogliere le richieste di I/O. Tuttavia, è necessario fare una precisazione sul disco fisico. I controller di array e le SAN presentano al sistema operativo aggregazioni di spindle come singoli dischi fisici. Inoltre, i controller di array e le SAN possono aggregare più dischi in un set di array e poi dividere questo set di array in più "partizioni", che a loro volta vengono presentate al sistema operativo come dischi fisici multipli (vedi figura).
In questa figura, i due spindle sono in mirroring e suddivisi in aree logiche per l'archiviazione dei dati (Dati 1 e Dati 2). Queste aree logiche sono viste dal sistema operativo come dischi fisici separati.
Sebbene ciò possa creare molta confusione, in questa appendice viene utilizzata la seguente terminologia per identificare le diverse entità:
- Spindle – il dispositivo fisicamente installato nel server.
- Array – un insieme di mandrini aggregati da un controller.
- Partizione dell'array – un partizionamento dell'array aggregato
- LUN – un array, utilizzato quando si fa riferimento alle SAN
- Disco – ciò che il sistema operativo considera un singolo disco fisico.
- Partizione – un partizionamento logico di quello che il sistema operativo percepisce come un disco fisico.
Considerazioni sull'architettura del sistema operativo
Il sistema operativo crea una coda di I/O First In/First Out (FIFO) per ogni disco osservato; questo disco può rappresentare uno spindle, un array o una partizione di array. Dal punto di vista del sistema operativo, per quanto riguarda la gestione dell'I/O, il numero di code attive è maggiore. Una coda FIFO è serializzata, il che significa che tutti gli I/O inviati al sottosistema di archiviazione devono essere elaborati nell'ordine di arrivo della richiesta. Correlando ogni disco osservato dal sistema operativo con uno spindle/array, il sistema operativo mantiene ora una coda di I/O per ogni set unico di dischi, eliminando così la contesa per le scarse risorse di I/O tra i dischi e isolando la richiesta di I/O a un singolo disco. Come eccezione, Windows Server 2008 introduce il concetto di priorità di I/O e le applicazioni progettate per utilizzare la priorità "Bassa" escono dall'ordine normale e passano in secondo piano. Le applicazioni non specificamente codificate per sfruttare la priorità "Bassa" passano di default a "Normale".
Introduzione a semplici sottosistemi di archiviazione
Partendo da un semplice esempio (un singolo disco rigido all'interno di un computer), verrà fornita un'analisi componente per componente. Scomponendolo nei principali componenti del sottosistema di archiviazione, il sistema è costituito da:
- 1 – HD Ultra Fast SCSI da 10.000 RPM (Ultra Fast SCSI ha una velocità di trasferimento di 20 MB/s)
- 1 – Bus SCSI (il cavo)
- 1 – Adattatore Ultra Fast SCSI
- 1 – Bus PCI a 32 bit e 33 MHz
Una volta identificati i componenti, è possibile calcolare la quantità di dati che possono transitare nel sistema o la quantità di I/O che può essere gestita. Si noti che la quantità di I/O e la quantità di dati che possono transitare nel sistema sono correlate, ma non uguali. Questa correlazione dipende dal fatto che l'I/O del disco sia casuale o sequenziale e dalla dimensione del blocco. (Tutti i dati vengono scritti sul disco come blocchi, ma applicazioni diverse utilizzano dimensioni di blocco diverse). In base ai singoli componenti:
Il disco rigido – Un disco rigido medio da 10.000 RPM ha un tempo di ricerca di 7 millisecondi (ms) e un tempo di accesso di 3 ms. Il tempo di ricerca è il tempo medio impiegato dalla testina di lettura/scrittura per spostarsi in una posizione sul piatto. Il tempo di accesso è il tempo medio necessario per leggere o scrivere i dati sul disco, una volta che la testina si trova nella posizione corretta. Pertanto, il tempo medio di lettura di un unico blocco di dati in un disco rigido da 10.000 RPM HD costituisce una ricerca e un accesso, per un totale di circa 10 ms (o .010 secondi) per blocco di dati.
Quando ogni accesso al disco richiede lo spostamento della testina in una nuova posizione del disco, il comportamento di lettura/scrittura viene definito "casuale". Pertanto, quando tutto l'I/O è casuale, un disco da 10.000 RPM HD può gestire circa 100 I/O al secondo (IOPS) (la formula è 1000 ms al secondo diviso 10 ms per I/O o 1000/10=100 IOPS).
In alternativa, quando tutto l'I/O avviene da settori adiacenti dell'HD, si parla di I/O sequenziale. L'I/O sequenziale non ha tempi di ricerca perché al termine del primo I/O la testina di lettura/scrittura si trova all'inizio del blocco di dati successivo sull'HD. Pertanto, un disco da 10.000 RPM HD è in grado di gestire circa 333 I/O al secondo (1000 ms al secondo diviso 3 ms per I/O).
Nota
Questo esempio non riflette la cache del disco, dove in genere vengono conservati i dati di un cilindro. In questo caso, i 10 ms sono necessari per il primo I/O e il disco legge l'intero cilindro. Tutti gli altri I/O sequenziali sono soddisfatti dalla cache. Di conseguenza, le cache su disco potrebbero migliorare le prestazioni dell'I/O sequenziale.
Finora la velocità di trasferimento del disco rigido è stata irrilevante. Che l'unità disco sia Ultra Wide da 20 MB/s o Ultra3 da 160 MB/s, la quantità effettiva di IOPS che può essere gestita da un disco da 10.000 RPM HD è di ~100 I/O casuali o ~300 I/O sequenziali. Poiché le dimensioni dei blocchi cambiano in base all'applicazione che scrive sull'unità, la quantità di dati estratti per ogni I/O è diversa. Ad esempio, se la dimensione del blocco è di 8 kB, 100 operazioni di I/O leggeranno o scriveranno sul disco rigido un totale di 800 kB. Se invece la dimensione del blocco è di 32 kB, 100 I/O leggeranno/scriveranno 3.200 kB (3,2 MB) sul disco rigido. Finché la velocità di trasferimento SCSI è superiore alla quantità totale di dati trasferiti, l'acquisto di un'unità con una velocità di trasferimento più elevata non porta alcun vantaggio. Per un confronto, vedere le tabelle seguenti.
Descrizione 7.200 RPM 9 ms di ricerca, 4 ms di accesso 10.000 RPM 7 ms di ricerca, 3 ms di accesso 15.000 RPM 4 ms di ricerca, 2 ms di accesso I/O casuale 80 100 150 I/O sequenziale 250 300 500 Unità da 10.000 RPM 8 kB di dimensione del blocco (Active Directory Jet) I/O casuale 800 kB/s I/O sequenziale 2.400 kB/s Backplane (bus) SCSI – Per capire in che modo il "backplane (bus) SCSI", o in questo scenario il cavo a nastro, influisce sulla produttività del sottosistema di archiviazione è necessario conoscere la dimensione dei blocchi. In sostanza, la domanda è: quanto I/O può gestire il bus se l'I/O è in blocchi da 8 kB? In questo scenario, il bus SCSI ha una velocità di 20 MB/s, ovvero 20480 kB/s. Dividendo 20.480 kB/s per blocchi da 8 kB si ottiene un massimo di circa 2.500 IOPS supportati dal bus SCSI.
Nota
Le cifre riportate nella tabella seguente rappresentano un esempio. La maggior parte dei dispositivi di archiviazione collegati utilizza attualmente PCI Express, che offre una velocità effettiva molto più elevata.
I/O supportati dal bus SCSI per dimensione del blocco Dimensione del blocco 2 kB 8 kB di dimensione del blocco (AD Jet) (SQL Server 7.0/SQL Server 2000) 20 MB/s 10,000 2500 40 MB/s 20.000 5,000 128 MB/s 65.536 16,384 320 MB/s 160.000 40.000 Come si può determinare da questo grafico, nello scenario presentato, indipendentemente dall'uso, il bus non rappresenterà mai un collo di bottiglia, poiché il massimo dello spindle è di 100 I/O, ben al di sotto di qualsiasi soglia sopra indicata.
Nota
Questo presuppone che il bus SCSI sia efficiente al 100%.
Adattatore SCSI – Per determinare la quantità di I/O che può gestire, è necessario verificare le specifiche del produttore. L'indirizzamento delle richieste di I/O al dispositivo appropriato richiede un'elaborazione di qualche tipo, quindi la quantità di I/O che può essere gestita dipende dal processore dell'adattatore SCSI (o del controller di array).
In questo esempio, si ipotizza che possano essere gestiti 1.000 I/O.
Bus PCI – Si tratta di un componente spesso trascurato. In questo esempio, non sarà il collo di bottiglia; tuttavia, quando i sistemi crescono, può diventare un collo di bottiglia. Come riferimento, un bus PCI a 32 bit che opera a 33 Mhz può teoricamente trasferire 133 MB/s di dati. L'equazione è la seguente:
32 bit ÷ 8 bit per byte × 33 MHz = 133 MB/s.
Si noti che questo è il limite teorico; in realtà si raggiunge solo il 50% circa del massimo, anche se in alcuni scenari di burst si può ottenere un'efficienza del 75% per brevi periodi.
Un bus PCI a 66 Mhz e 64 bit può supportare un massimo teorico di (64 bit ÷ 8 bit per byte × 66 Mhz) = 528 MB/sec. Inoltre, qualsiasi altro dispositivo (come l'adattatore di rete, il secondo controller SCSI e così via) ridurrà la larghezza di banda disponibile, poiché la larghezza di banda è condivisa e i dispositivi si contendono le risorse limitate.
Dopo aver analizzato i componenti di questo sottosistema di archiviazione, lo spindle è il fattore limitante della quantità di I/O che può essere richiesta e, di conseguenza, della quantità di dati che possono transitare nel sistema. In particolare, in uno scenario AD DS, si tratta di 100 I/O casuali al secondo con incrementi di 8 kB, per un totale di 800 kB al secondo quando si accede al database Jet. In alternativa, la velocità effettiva massima per uno spindle allocato esclusivamente ai file di log subirebbe le seguenti limitazioni: 300 I/O sequenziali al secondo con incrementi di 8 kB, per un totale di 2.400 kB (2,4 MB) al secondo.
Dopo aver analizzato una semplice configurazione, la tabella seguente mostra dove si verificherà il collo di bottiglia con la modifica o l'aggiunta dei componenti del sottosistema di archiviazione.
| Note | Analisi dei colli di bottiglia | Disco | Bus | Adapter | Bus PCI |
|---|---|---|---|---|---|
| Questa è la configurazione del controller di dominio dopo l'aggiunta di un secondo disco. La configurazione del disco rappresenta il collo di bottiglia con 800 kB/s. | Aggiungere 1 disco (totale=2) L'I/O è casuale Dimensione blocco 4 kB 10.000 RPM HD |
200 I/O in totale 800 kB/s in totale. |
|||
| Dopo l'aggiunta di 7 dischi, la configurazione dei dischi rappresenta ancora il collo di bottiglia, con 3.200 kB/s. | Aggiungere 7 dischi (totale=8) L'I/O è casuale Dimensione blocco 4 kB 10.000 RPM HD |
800 I/O in totale. 3.200 kB/s in totale |
|||
| Dopo aver modificato l'I/O in sequenziale, la scheda di rete diventa il collo di bottiglia perché è limitata a 1.000 IOPS. | Aggiungere 7 dischi (totale=8) L'I/O è sequenziale Dimensione blocco 4 kB 10.000 RPM HD |
2.400 I/O sec in lettura/scrittura su disco, controller limitato a 1.000 IOPS | |||
| Dopo aver sostituito la scheda di rete con una scheda SCSI che supporta 10.000 IOPS, il collo di bottiglia ritorna alla configurazione del disco. | Aggiungere 7 dischi (totale=8) L'I/O è casuale Dimensione blocco 4 kB 10.000 RPM HD Aggiornamento dell'adattatore SCSI (ora supporta 10.000 I/O) |
800 I/O in totale. 3.200 kB/s in totale |
|||
| Dopo aver aumentato la dimensione del blocco a 32 kB, il bus diventa il collo di bottiglia perché supporta solo 20 MB/s. | Aggiungere 7 dischi (totale=8) L'I/O è casuale Dimensione blocco 32 kB 10.000 RPM HD |
800 I/O in totale. 25.600 kB/s (25 MB/s) possono essere letti/scritti su disco. Il bus supporta solo 20 MB/s |
|||
| Dopo aver aggiornato il bus e aggiunto altri dischi, il disco rimane il collo di bottiglia. | Aggiungere 13 dischi (totale=14) Aggiungere un secondo adattatore SCSI con 14 dischi L'I/O è casuale Dimensione blocco 4 kB 10.000 RPM HD Aggiornamento al bus SCSI da 320 MB/s |
2.800 I/O 11.200 kB/s (10,9 MB/s) |
|||
| Dopo aver modificato l'I/O in sequenziale, il disco rimane il collo di bottiglia. | Aggiungere 13 dischi (totale=14) Aggiungere una seconda scheda SCSI con 14 dischi L'I/O è sequenziale Dimensione blocco 4 kB 10.000 RPM HD Aggiornamento al bus SCSI da 320 MB/s |
8.400 I/O 33.600 kB\s (32,8 MB\s) |
|||
| Dopo aver aggiunto dischi rigidi più veloci, il disco rimane il collo di bottiglia. | Aggiungere 13 dischi (totale=14) Aggiungere un secondo adattatore SCSI con 14 dischi L'I/O è sequenziale Dimensione blocco 4 kB 15.000 RPM HD Aggiornamento al bus SCSI da 320 MB/s |
14.000 I/O 56.000 kB/s (54,7 MB/s) |
|||
| Dopo aver aumentato la dimensione del blocco a 32 kB, il bus PCI diventa il collo di bottiglia. | Aggiungere 13 dischi (totale=14) Aggiungere un secondo adattatore SCSI con 14 dischi L'I/O è sequenziale Dimensione blocco 32 kB 15.000 RPM HD Aggiornamento al bus SCSI da 320 MB/s |
14.000 I/O 448.000 KB/s (437 MB/s) è il limite di lettura/scrittura dello spindle. Il bus PCI supporta un massimo teorico di 133 MB/s (75% di efficienza nel migliore dei casi). |
Introduzione al RAID
La natura di un sottosistema di archiviazione non cambia radicalmente con l'introduzione di un controller array, che sostituisce semplicemente l'adattatore SCSI nei calcoli. Ciò che cambia è il costo di lettura e scrittura dei dati sul disco quando si utilizzano i vari livelli di array (come RAID 0, RAID 1 o RAID 5).
In RAID 0, i dati sono distribuiti su tutti i dischi del set RAID. Ciò significa che durante un'operazione di lettura o scrittura, una parte dei dati viene prelevata o spinta su ciascun disco, aumentando la quantità di dati che possono transitare nel sistema nello stesso lasso di tempo. Pertanto, in un secondo, su ciascuno spindle (sempre ipotizzando unità da 10.000 RPM), possono essere eseguite 100 operazioni di I/O. La quantità totale di I/O che può essere supportata è pari a N fusi per 100 I/O al secondo per fuso (si ottiene 100*N I/O al secondo).
In RAID 1, i dati sono duplicati su una coppia di mandrini per garantire la ridondanza. In questo modo, quando viene eseguita un'operazione di I/O in lettura, i dati possono essere letti da entrambi i spindle del set. In questo modo la capacità di I/O di entrambi i dischi è disponibile durante un'operazione di lettura. L'avvertenza è che le operazioni di scrittura non ottengono alcun vantaggio in termini di prestazioni in un RAID 1. Questo perché gli stessi dati devono essere scritti su entrambe le unità per garantire la ridondanza. Sebbene non richieda più tempo, poiché la scrittura dei dati avviene contemporaneamente su entrambi i mandrini, dato che entrambi i mandrini sono occupati a duplicare i dati, un'operazione di I/O in scrittura impedisce in sostanza l'esecuzione di due operazioni di lettura. Pertanto, ogni I/O di scrittura costa due I/O di lettura. Da queste informazioni è possibile creare una formula per determinare il numero totale di operazioni di I/O che si stanno verificando:
I/O di lettura + 2 × I/O di scrittura = I/O totale disponibile su disco consumato
Quando sono noti il rapporto tra letture e scritture e il numero di mandrini, è possibile ricavare la seguente equazione dall'equazione precedente per identificare l'I/O massimo che può essere supportato dall'array:
IOPS massimi per spindle × 2 spindle × [(%Letture + %Scritture) ÷ (%Letture + 2 × %Scritture)] = IOPS totali
RAID 1+ 0, si comporta esattamente come RAID 1 per quanto riguarda la lettura e la scrittura. Tuttavia, l'I/O viene ora eseguito in striping su ciascun set di mirroring. If
IOPS massimo per spindle × 2 spindle × [(%Letture + %Scritture) ÷ (%Letture + 2 × %Scritture)] = I/O totale
in un set RAID 1, quando una molteplicità (N) di set RAID 1 è sottoposta a striping, l'I/O totale che può essere elaborato diventa N × I/O per set RAID 1:
N × {IOPS massimo per spindle × 2 spindle × [(%Letture + %Scritture) ÷ (%Letture + 2 × %Scritture)] } = IOPS totali
In RAID 5, talvolta indicato come RAID N + 1, i dati sono distribuiti su N spindle e le informazioni di parità sono scritte sullo spindle "+ 1". Tuttavia, RAID 5 è molto più costoso quando si esegue un I/O di scrittura rispetto a RAID 1 o 1 + 0. RAID 5 esegue il seguente processo ogni volta che viene inviato un I/O di scrittura all'array:
- Leggere i dati precedenti
- Leggere le parità precedenti
- Scrivere i nuovi dati
- Scrivere la nuova parità
Poiché ogni richiesta di I/O in scrittura inviata al controller dell'array dal sistema operativo richiede quattro operazioni di I/O per essere completata, le richieste di scrittura inviate richiedono un tempo quattro volte superiore rispetto a un singolo I/O in lettura. Per ricavare una formula per tradurre le richieste di I/O dalla prospettiva del sistema operativo a quella degli spindle:
I/O di lettura + 4 × I/O di scrittura = I/O totale
Analogamente, in un set RAID 1, quando sono noti il rapporto tra letture e scritture e il numero di mandrini, è possibile ricavare la seguente equazione dall'equazione precedente per identificare l'I/O massimo che può essere supportato dall'array (si noti che il numero totale di mandrini non include l’"unità" persa per la parità):
IOPS per spindle × (Spindle – 1) × [(%Letture + %Scritture) ÷ (%Letture + 4 × %Scritture)] = IOPS totali
Introduzione alle SAN
Quando si introduce una SAN nell'ambiente, i principi di base delineati non cambiano, ma occorre tenere conto del comportamento di I/O di tutti i sistemi collegati alla SAN. Poiché uno dei principali vantaggi dell'utilizzo di una SAN è la ridondanza aggiuntiva rispetto all’archiviazione collegata internamente o esternamente, la pianificazione della capacità deve ora tenere conto delle esigenze di tolleranza di errore. Inoltre, sono stati introdotti altri componenti che devono essere valutati. La suddivisione di una SAN nei suoi componenti:
- Disco rigido SCSI o Fibre Channel
- Backplane del canale dell'unità di archiviazione
- Unità di archiviazione
- Modulo controller di archiviazione
- Switch SAN
- HBA
- Il bus PCI
Quando si progetta un sistema per la ridondanza, si includono componenti aggiuntivi per far fronte al potenziale di errore. Nella pianificazione della capacità è molto importante escludere il componente ridondante dalle risorse disponibili. Ad esempio, se la SAN ha due moduli controller, la capacità di I/O di un modulo controller è l'unica che dovrebbe essere utilizzata per la velocità effettiva totale di I/O disponibile per il sistema. Ciò è dovuto al fatto che se in un controller si verifica un errore, l'intero carico di I/O richiesto da tutti i sistemi collegati dovrà essere elaborato dal controller rimanente. Poiché tutta la pianificazione della capacità viene effettuata per i periodi di picco, i componenti ridondanti non devono essere considerati nelle risorse disponibili e l'utilizzo di picco pianificato non deve superare l'80% di saturazione del sistema (al fine di gestire i burst o il comportamento anomalo del sistema). Allo stesso modo, lo switch SAN ridondante, l'unità di archiviazione e gli spindle non devono essere presi in considerazione nei calcoli di I/O.
Quando si analizza il comportamento del disco rigido SCSI o Fibre Channel, il metodo di analisi del comportamento descritto in precedenza non cambia. Sebbene ciascun protocollo presenti alcuni vantaggi e svantaggi, il fattore limitante su base individuale è la limitazione meccanica del disco rigido.
Analizzare il canale sull'unità di archiviazione equivale a calcolare le risorse disponibili sul bus SCSI, ovvero la larghezza di banda (ad esempio 20 MB/s) divisa per la dimensione del blocco (ad esempio 8 kB). L'aspetto che si discosta dal semplice esempio precedente è l'aggregazione di più canali. Ad esempio, se sono presenti 6 canali, ognuno dei quali supporta una velocità di trasferimento massima di 20 MB/s, la quantità totale di I/O e di trasferimento dati disponibile è di 100 MB/s (è corretto, non è 120 MB/s). Ancora una volta, la tolleranza ai guasti è un elemento importante in questo calcolo: in caso di perdita di un intero canale, al sistema rimangono solo 5 canali funzionanti. Pertanto, per continuare a soddisfare le aspettative di prestazioni in caso di errore, la velocità effettiva totale per tutti i canali di archiviazione non dovrebbe superare i 100 MB/s (questo presuppone che il carico e la tolleranza di errore siano distribuiti uniformemente su tutti i canali). La trasformazione di questo dato in un profilo di I/O dipende dal comportamento dell'applicazione. Nel caso dell'I/O di Active Directory Jet, ciò si riferisce a circa 12.500 I/O al secondo (100 MB/s ÷ 8 kB per I/O).
Successivamente, è necessario ottenere le specifiche del produttore dei moduli controller per comprendere la velocità effettiva che ciascun modulo può supportare. In questo esempio, la SAN dispone di due moduli controller che supportano 7.500 I/O ciascuno. La velocità effettiva totale del sistema può essere di 15.000 IOPS se non si desidera la ridondanza. Nel calcolo della velocità effettiva massima in caso di errore, il limite è la velocità effettiva di un controller, ovvero 7.500 IOPS. Questa soglia è ben al di sotto dei 12.500 IOPS (ipotizzando una dimensione del blocco di 4 kB) massimi che possono essere supportati da tutti i canali di archiviazione, e quindi rappresenta attualmente il collo di bottiglia nell'analisi. Sempre ai fini della pianificazione, il massimo I/O desiderato da prevedere è di 10.400 I/O.
Quando i dati escono dal modulo controller, transitano su una connessione Fibre Channel a 1 GB/s (o 1 Gigabit al secondo). Per correlare questo dato con le altre metriche, 1 GB/s diventa 128 MB/s (1 GB/s ÷ 8 bit/byte). Poiché si tratta di un valore superiore alla larghezza di banda totale di tutti i canali dell'unità di archiviazione (100 MB/s), non si tratta di un collo di bottiglia per il sistema. Inoltre, poiché si tratta di uno solo dei due canali (la connessione Fibre Channel aggiuntiva da 1 GB/s è per la ridondanza), se una connessione si guasta, la connessione rimanente ha ancora una capacità sufficiente per gestire tutti i trasferimenti di dati richiesti.
Durante il percorso verso il server, i dati transiteranno molto probabilmente su uno switch SAN. Poiché lo switch SAN deve elaborare la richiesta di I/O in arrivo e inoltrarla alla porta appropriata, lo switch avrà un limite alla quantità di I/O che può essere gestita; tuttavia, per determinare tale limite sono necessarie le specifiche del produttore. Ad esempio, se ci sono due switch e ciascuno di essi può gestire 10.000 IOPS, la velocità effettiva totale sarà di 20.000 IOPS. Anche in questo caso, essendo la tolleranza ai guasti un problema, se uno switch si guasta, la velocità effettiva totale del sistema sarà di 10.000 IOPS. Poiché si desidera non superare l'80% di utilizzo nel funzionamento normale, l'obiettivo dovrebbe essere quello di utilizzare non più di 8.000 I/O.
Infine, anche l'HBA installato nel server ha un limite alla quantità di I/O che può gestire. Di solito viene installato un secondo HBA per la ridondanza, ma proprio come nel caso dello switch SAN, quando si calcola l'I/O massimo che può essere gestito, la velocità effettiva totale di N – 1 HBA rappresenta la massima scalabilità del sistema.
Considerazioni sulla memorizzazione sulla cache
La cache è uno dei componenti che può avere un impatto significativo sulle prestazioni complessive in qualsiasi punto del sistema di storage. Un'analisi dettagliata degli algoritmi di memorizzazione nella cache esula dallo scopo di questo articolo; tuttavia, alcune affermazioni di base sulla cache nei sottosistemi a disco meritano di essere illuminate:
La memorizzazione sulla cache migliora l'I/O sequenziale sostenuto, in quanto può bufferizzare molte operazioni di scrittura più piccole in blocchi di I/O più grandi e distribuirle sull’archiviazione in un numero inferiore di blocchi, ma di dimensioni maggiori. In questo modo si riduce l'I/O casuale totale e l'I/O sequenziale totale, fornendo così una maggiore disponibilità di risorse per altri I/O.
La memorizzazione sulla cache non migliora la velocità effettiva di I/O di scrittura sostenuto del sottosistema di archiviazione. Consente di bufferizzare le scritture solo fino a quando gli spindle sono disponibili per eseguire il commit dei dati. Quando tutto l'I/O disponibile degli spindle del sottosistema di archiviazione viene saturato per lunghi periodi, la cache finirà per riempirsi. Per svuotare la cache, è necessario prevedere un intervallo di tempo sufficiente tra i burst o gli spindle aggiuntivi, in modo da fornire un numero di I/O sufficiente a consentire lo svuotamento della cache.
Le cache di dimensioni maggiori consentono solo di bufferizzare più dati. Ciò significa che è possibile gestire periodi di saturazione più lunghi.
In un sottosistema di archiviazione normalmente funzionante, il sistema operativo sperimenterà prestazioni di scrittura migliori, poiché i dati devono essere scritti solo nella cache. Una volta che il supporto sottostante è saturo di I/O, la cache si riempie e le prestazioni di scrittura tornano alla velocità del disco.
Per quanto riguarda la memorizzazione sulla cache di I/O in lettura, lo scenario in cui la cache è più vantaggiosa è quello in cui i dati sono memorizzati in modo sequenziale sul disco e la cache è in grado di effettuare il read-ahead (presuppone che il settore successivo contenga i dati che saranno richiesti successivamente).
Quando l'I/O in lettura è casuale, è improbabile che la memorizzazione sulla cache del controller dell'unità fornisca un miglioramento della quantità di dati che possono essere letti dal disco. Qualsiasi miglioramento risulta nullo se la dimensione della cache basata sul sistema operativo o sull'applicazione è maggiore della dimensione della cache basata sull'hardware.
Nel caso di Active Directory, la cache è limitata solo dalla quantità di RAM.
Considerazioni sulle SSD
Le unità SSD sono completamente diverse dai dischi rigidi basati su spindle. Tuttavia, i due criteri chiave rimangono: "Quanti IOPS può gestire?" e "Qual è la latenza per questi IOPS?" Rispetto ai dischi rigidi basati su spindle, le unità SSD possono gestire volumi di I/O più elevati e avere latenze più basse. In generale, al momento della stesura di questo articolo, le unità SSD sono ancora costose nel confronto del costo per gigabyte, ma sono molto economiche in termini di costo per I/O e meritano una considerazione significativa in termini di prestazioni di archiviazione.
Considerazioni:
- Sia gli IOPS che le latenze sono molto soggettivi ai progetti dei produttori e in alcuni casi sono state osservate prestazioni inferiori rispetto alle tecnologie basate su spindle. In breve, è più importante esaminare e convalidare le specifiche del produttore unità per unità e non dare per scontate le generalità.
- I tipi di IOPS possono avere numeri molto diversi a seconda che si tratti di lettura o scrittura. I servizi AD DS, in generale, essendo prevalentemente basati sulla lettura, saranno meno colpiti rispetto ad altri scenari applicativi.
- "Resistenza in scrittura" indica il concetto che le celle delle unità SSD finiscono per consumarsi. I vari produttori affrontano questa sfida in modo diverso. Almeno per quanto riguarda l'unità per database, il profilo di I/O prevalentemente in lettura consente di minimizzare l'importanza di questo problema, poiché i dati non sono altamente volatili.
Riepilogo
Un modo per pensare all’archiviazione è di immaginare l'impianto idraulico di una casa. Immaginare che lo IOPS del supporto su cui sono memorizzati i dati sia lo scarico principale della casa. Quando questo è intasato (ad esempio a causa di radici nelle tubazioni) o limitato (è collassato o troppo piccolo), tutti i lavandini della casa si intasano quando viene utilizzata troppa acqua (troppi ospiti). Questo è perfettamente analogo a un ambiente condiviso in cui uno o più sistemi sfruttano l’archiviazione condivisa su una SAN/NAS/iSCSI con lo stesso supporto sottostante. Per risolvere i diversi scenari si possono adottare approcci diversi:
- Un drenaggio intasato o sottodimensionato richiede una sostituzione e una riparazione su larga scala. Questo scenario è simile all'aggiunta di nuovo hardware o alla ridistribuzione dei sistemi che utilizzano l’archiviazione condivisa in tutta l'infrastruttura.
- Una tubazione "intasata" di solito indica l'individuazione di uno o più problemi e la loro risoluzione. In uno scenario di archiviazione, ciò potrebbe essere rappresentato da backup a livello di archiviazione o di sistema, scansioni antivirus sincronizzate su tutti i server e software di deframmentazione sincronizzato in esecuzione durante i periodi di picco.
In qualsiasi impianto idraulico, più scarichi confluiscono nello scarico principale. Se qualcosa si blocca in uno di questi scarichi o in un punto di giunzione, solo i componenti che si trovano dietro quel punto di giunzione tornano a funzionare. In uno scenario di archiviazione, potrebbe trattarsi di uno switch sovraccarico (scenario SAN/NAS/iSCSI), di problemi di compatibilità dei driver (combinazione driver/HBA Firmware/storport.sys errata) o di backup/antivirus/deframmentazione. Per determinare se la "tubazione" di archiviazione è di dimensioni sufficientemente grandi, è necessario misurare le dimensioni IOPS e I/O. A ogni giunzione si sommano per garantire un adeguato "diametro della tubazione".
Appendice D - Discussione sulla risoluzione dei problemi di archiviazione - Ambienti in cui la fornitura di una quantità di RAM almeno pari alle dimensioni del database non è un'opzione praticabile
È utile capire il perché di queste indicazioni, in modo da poter tenere conto delle variazioni nella tecnologia di archiviazione. Queste indicazioni esistono per due motivi. Il primo è l'isolamento dell'IO, in modo che i problemi di prestazioni (cioè il paging) sullo spindle del sistema operativo non abbiano un impatto sulle prestazioni del database e dei profili di I/O. In secondo luogo, i file di registro di AD DS (e della maggior parte dei database) sono di natura sequenziale e i dischi rigidi e le cache basati su fuso hanno un enorme vantaggio in termini di prestazioni quando vengono utilizzati con l'I/O sequenziale rispetto ai modelli di I/O più casuali del sistema operativo e ai modelli di I/O quasi puramente casuali dell'unità del database AD DS. Isolando l'I/O sequenziale su un'unità fisica separata, è possibile aumentare la velocità effettiva. La sfida rappresentata dalle opzioni di archiviazione odierne è che i presupposti fondamentali alla base di queste indicazioni non sono più validi. In molti scenari di storage virtualizzato, come iSCSI, SAN, NAS e file immagine di dischi virtuali, il supporto di archiviazione sottostante è condiviso tra più host, annullando così completamente sia l'aspetto dell'"isolamento dell'I/O" che quello dell'"ottimizzazione dell'I/O sequenziale". In effetti, questi scenari aggiungono un ulteriore livello di complessità, in quanto gli altri host che accedono al supporto condiviso possono peggiorare la reattività del controller di dominio.
Nella pianificazione delle prestazioni di archiviazione, sono tre le categorie da considerare: stato di cache fredda, stato di cache riscaldata e backup/ripristino. Lo stato di cache fredda si verifica in scenari come quando il controller di dominio viene riavviato inizialmente o il servizio Active Directory viene riavviato e non ci sono dati Active Directory nella RAM. Lo stato di cache calda si verifica quando il controller di dominio è in uno stato stabile e il database è memorizzato nella cache. È importante notare che i profili di prestazioni sono molto diversi e che avere abbastanza RAM per memorizzare nella cache l'intero database non aiuta le prestazioni quando la cache è fredda. Si può considerare la progettazione delle prestazioni per questi due scenari con la seguente analogia: il riscaldamento della cache fredda è uno "sprint" e l'esecuzione di un server con una cache calda è una "maratona".
Sia nello scenario di cache fredda che in quello di cache calda, la questione diventa la velocità con cui lo storage può spostare i dati dal disco alla memoria. Il riscaldamento della cache è uno scenario in cui, con il passare del tempo, le prestazioni migliorano, in quanto un maggior numero di query riutilizza i dati, il tasso di risposta della cache aumenta e la frequenza con cui è necessario andare su disco diminuisce. Di conseguenza, l'impatto negativo sulle prestazioni del passaggio al disco diminuisce. L'eventuale diminuzione delle prestazioni è solo transitoria, in attesa che la cache si riscaldi e cresca fino alla dimensione massima consentita dal sistema. Il discorso può essere semplificato alla velocità con cui i dati possono essere scaricati dal disco, ed è una semplice misura degli IOPS disponibili per Active Directory, che sono soggettivi agli IOPS disponibili dall’archiviazione sottostante. Dal punto di vista della pianificazione, poiché gli scenari di riscaldamento della cache e di backup/ripristino si verificano in via eccezionale, di solito in orari non di picco e sono soggetti al carico del controller di dominio, non esistono indicazioni generali, se non quella di programmare queste attività in orari non di punta.
L'AD DS, nella maggior parte degli scenari, è costituito prevalentemente da IO in lettura, di solito con un rapporto di 90% lettura/10% scrittura. L'I/O in lettura tende spesso a essere il collo di bottiglia per l'esperienza dell'utente e, con l'IO in scrittura, provoca un degrado delle prestazioni in scrittura. Poiché l'I/O su NTDS.dit è prevalentemente casuale, le cache tendono a fornire un beneficio minimo all'IO in lettura, rendendo ancora più importante la corretta configurazione dello storage per il profilo di I/O in lettura.
In condizioni operative normali, l'obiettivo della pianificazione dell’archiviazione è ridurre al minimo i tempi di attesa per la restituzione di una richiesta da AD DS al disco. Ciò significa essenzialmente che il numero di I/O in sospeso e in attesa è inferiore o equivalente al numero di percorsi verso il disco. Esistono vari modi per misurare questo aspetto. In uno scenario di monitoraggio delle prestazioni, l’indicazione generale è che Disco logico(<Unità database NTDS>)\Media sec/lettura disco sia inferiore a 20 ms. La soglia operativa desiderata deve essere molto più bassa, preferibilmente il più vicino possibile alla velocità dell’archiviazione, nell'intervallo da 2 a 6 millisecondi (da .002 a .006 secondi), a seconda del tipo di archiviazione.
Esempio
Analizzare il grafico:
- Ovale verde a sinistra – La latenza rimane costante a 10 ms. Il carico aumenta da 800 IOPS a 2.400 IOPS. Questo è il limite assoluto della velocità con cui una richiesta di I/O può essere elaborata dall’archiviazione sottostante. Questo dato è soggetto alle specifiche della soluzione di archiviazione.
- Ovale bordeaux sulla destra – La velocità effettiva rimane piatta dall'uscita del cerchio verde fino alla fine della raccolta dei dati, mentre la latenza continua ad aumentare. Questo dimostra che quando i volumi delle richieste superano i limiti fisici dell’archiviazione sottostante, più a lungo le richieste rimangono in coda in attesa di essere inviate al sottosistema di archiviazione.
Applicazione di queste informazioni:
- Impatto di un utente che interroga l'appartenenza a un gruppo di grandi dimensioni – Supponiamo che questo richieda la lettura di 1 MB di dati dal disco, la quantità di I/O e il tempo necessario possono essere valutati come segue:
- Le pagine del database di Active Directory hanno una dimensione di 8 kB.
- È necessario leggere almeno 128 pagine dal disco.
- Supponendo che non ci sia nulla nella cache, al piano (10 ms) ci vorranno almeno 1,28 secondi per caricare i dati dal disco e restituirli al client. A 20 ms, dove la velocità effettiva dell’archiviazione ha raggiunto il massimo da tempo ed è anche il massimo consigliato, ci vorranno 2,5 secondi per recuperare i dati dal disco e restituirli all'utente finale.
- A quale velocità verrà riscaldata la cache - Partendo dal presupposto che il carico del client massimizzerà la velocità effettiva su questo esempio di archiviazione, la cache si scalderà a una velocità di 2400 IOPS × 8 kB per IO. Ovvero, circa 20 MB/s al secondo, caricando circa 1 GB di database nella RAM ogni 53 secondi.
Nota
È normale osservare per brevi periodi un aumento delle latenze quando i componenti leggono o scrivono aggressivamente sul disco, ad esempio durante il backup del sistema o quando AD DS esegue Garbage Collection. Oltre al fare calcoli è necessario prevedere uno spazio aggiuntivo per far fronte a questi eventi periodici. L'obiettivo è fornire una velocità effettiva sufficiente a gestire questi scenari senza influire sul normale funzionamento.
Come si può notare, la velocità di riscaldamento della cache è limitata dalla struttura dell’archiviazione. Ciò che riscalderà la cache sono le richieste client in arrivo alla velocità che l’archiviazione sottostante è in grado di fornire. L'esecuzione di script per "preriscaldare" la cache durante le ore di punta farà concorrenza al carico determinato dalle richieste reali dei client. Questo può influire negativamente sulla consegna dei dati di cui i client hanno bisogno per primi, perché, per sua stessa natura, genera una competizione per le scarse risorse del disco, in quanto i tentativi artificiali di riscaldare la cache caricheranno dati non rilevanti per i client che contattano il controller di dominio.