Esporta (0) Stampa
Espandi tutto
Il presente articolo è stato tradotto automaticamente. Passare il puntatore sulle frasi nell'articolo per visualizzare il testo originale. Ulteriori informazioni.
Traduzione
Originale
Questo argomento non è stato ancora valutato - Valuta questo argomento

Pianificazione della capacità per servizi di dominio Active Directory

In questo argomento vengono fornite indicazioni per la pianificazione della capacità per servizi di dominio Active Directory (AD DS).

Per il lettore, è importante chiarire che la pianificazione della capacità è non la stessa risoluzione dei problemi di incidenti di prestazioni. Mentre essi sono strettamente correlati, le attività sono molto diverse. L'obiettivo della pianificazione della capacità è correttamente implementare e gestire un ambiente e ridurre al minimo il tempo speso sulla risoluzione dei problemi problemi di prestazioni. Nella pianificazione della capacità, un'organizzazione potrebbe avere un obiettivo di base del 40% l'utilizzo del processore durante i periodi di picco per soddisfare esigenze di prestazioni del client e ospitare il tempo necessario per aggiornare l'hardware nel datacenter. Considerando che, per ricevere la notifica di incidenti di funzionamento anomalo, una soglia di allarme monitoraggio potrebbe essere impostata al 90% in un intervallo di 5 minuti. La differenza è che quando una soglia di gestione capacità viene continuamente superata (un evento una tantum non è un problema), aggiungendo in capacità aggiuntiva (che è, l'aggiunta di processori più veloci o più) sarebbe la soluzione o scalare il servizio tra più server sarebbe una soluzione. Soglia di allarme delle prestazioni sono progettati per indicare che esperienza cliente attualmente sta soffrendo e provvedimenti immediati devono essere prese per affrontare la questione. Per analogia: gestione della capacità è circa gli sforzi necessari per prevenire un incidente d'auto (guida difensiva, assicurandosi che i freni funzionino correttamente, e così via) considerando che la risoluzione dei problemi di prestazioni è cosa fanno dopo un incidente la polizia, vigili del fuoco e i medici d'emergenza. Si tratta di "guida difensiva", Active Directory-stile.

Negli ultimi anni, è cambiato drammaticamente capacity planning guidance per sistemi di scale-up in generale. Cambiamenti nelle architetture di sistema, come il cambiamento da piattaforme a 32-bit a 64 bit di server, virtualizzazione contro gli scenari non virtualizzati, drammaticamente maggiore attenzione al consumo di energia, l'industria in movimento dal mandrino basata di archiviazione SSD, e nube scenari hanno contestato i presupposti fondamentali sulla progettazione e ridimensionamento di un servizio. Inoltre, l'approccio si sta spostando da una pianificazione esercizio, per una capacità di servizio basato su pianificazione esercizio della capacità basate su server. Active Directory Domain Services (AD DS), un servizio distribuito molto maturo contro cui molti Microsoft e prodotti di terze parti usano come un backend, diventa uno dei prodotti più critici di pianificare correttamente affinché ci è capacità necessaria per tutto il resto delle applicazioni per eseguire.

Nella pianificazione della capacità, la prima decisione da prendere è la qualità dei servizi necessari. Ad esempio, generalmente un datacenter core sosterrà un più elevato livello di concorrenza e richiedono un'esperienza più coerenza attraverso tutti gli utenti e utilizzo di applicazioni, che richiedono una maggiore attenzione alla ridondanza e riducendo al minimo i colli di bottiglia del sistema e le infrastrutture. Al contrario, una posizione satellitare con una manciata di utenti sarà necessario né il livello di concorrenza e possa avere requisiti più bassi per la tolleranza di errore. Pertanto, l'ufficio satellite potrebbe non essere necessario tanta attenzione all'ottimizzazione hardware e infrastrutture, che possono portare a risparmi sui costi sottostanti. Tutte le raccomandazioni e linee guida nel presente documento sono per ottenere prestazioni ottimali e possono essere selettivamente rilassati per scenari con meno esigenti.

La domanda successiva che viene subito in mente è: virtualizzato o fisico? Da una prospettiva di pianificazione di capacità, non non c'è nessuna risposta giusta o sbagliata;c'è solo un diverso set di variabili per lavorare con. Scenari di virtualizzazione scendono a una delle due opzioni: "direct mapping" con un ospite per ogni host (dove la virtualizzazione esiste unicamente per astrarre hardware fisico dal server) e "host condivise". Gli scenari di test e produzione indicano che lo scenario "mapping diretto" può essere trattato in modo identico a un host fisico. "Shared host," tuttavia, introduce una serie di considerazioni compitato più dettagliatamente in seguito. Lo scenario "host condiviso" significa che AD DS è anche competizione per le risorse, e ci sono sanzioni e considerazioni tuning per farlo.

In questo articolo di seguito sono i requisiti di base che ci si aspetta:

  • I lettori hanno letto e hanno familiari con Performance Tuning Guidelines per Windows Server 2012.

  • La piattaforma Windows Server è un'architettura basato su x64. Ma anche se l'ambiente Active Directory è installato su Windows Server 2003 x86 (ormai quasi alla fine del ciclo di vita del supporto) e ha un DIT meno 1,5 GB nel formato che può essere facilmente tenuto in memoria, le linee guida da questo articolo sono ancora applicabili.

  • La pianificazione delle capacità è un processo continuo e si dovrebbe riesaminare periodicamente quanto bene l'ambiente è soddisfare le aspettative.

  • Ottimizzazione avverrà sopra più cicli di hardware come modifica i costi dell'hardware. Ad esempio, memoria diventa più conveniente, il costo per nucleo diminuisce o al prezzo di archiviazione diverse opzioni di modifica.

  • Piano per il periodo di picco occupato del giorno. Si consiglia di guardare a questo a intervalli di 30 minuti o ore. Qualcosa più grande può nascondere i picchi effettivi e nulla che meno possa essere distorti da "picchi transitori".

  • Piano per la crescita nel corso del ciclo di vita del hardware per l'impresa. Questo può includere una strategia di aggiornamento o l'aggiunta di hardware in maniera sfalsata, o un aggiornamento completo ogni 3-5 anni. Ciascuno richiederà una "congettura" di come si svilupperà molto il carico su Active Directory. Dati storici, se raccolti, verranno aiuterà con questa valutazione.

  • Piano per la tolleranza di errore. Una volta che è derivata una stima N , piano per gli scenari che includono N-1, N-2, N-x.

    • Aggiungere ulteriori server secondo le necessità organizzative per garantire che la perdita di un server singolo o multiplo non superi le stime di capacità massima di picco.

    • Anche considerare che il piano di crescita e piano di tolleranza di errore devono essere integrati. Ad esempio, se un controller di dominio è necessario per supportare il carico, ma la stima è che il carico sarà raddoppiata nel prossimo anno e richiedono due controller di dominio totale, non ci sarà abbastanza capacità per sostenere la tolleranza di errore. La soluzione sarebbe quella di iniziare con tre DCs. Uno potrebbe anche intenzione di aggiungere il terzo DC dopo 3 o 6 mesi se i bilanci sono stretti.

      JJ651019.note(it-it,WS.11).gif Nota
      Aggiunta di applicazioni compatibili con Active Directory potrebbe avere un notevole impatto sul carico DC, se il carico è venuta dall'application server o client.

Con queste considerazioni in mente, un processo in tre fasi verrà utilizzato come parte del ciclo di pianificazione della capacità.

  1. Misurare l'ambiente esistente, determinare dove i colli di bottiglia del sistema attualmente sono ed ottenere basi ambientali necessarie per pianificare la quantità di capacità necessarie.

  2. Determinare l'hardware necessario secondo i criteri delineati nel passaggio 1.

  3. Monitorare e validare che è in funzione l'infrastruttura come implementato all'interno di specifiche. Si noti che alcuni dei dati raccolti nel monitoraggio e convalida fase diventa la misura del prossimo ciclo di pianificazione della capacità.

In tutti i sistemi informatici, ottimizzando le prestazioni viene giù a garantire quattro componenti principali sono correttamente selezionati e ottimizzati per l'applicazione di carichi:

  1. Memoria

  2. Rete

  3. Archiviazione

  4. Processore

Dovuto i requisiti di archiviazione di base di Active Directory e il comportamento generale di software client ben scritto, anche ambienti con oltre 10.000 a 20.000 utenti realmente non è necessario investire molto nella capacità di pianificazione per quanto riguarda l'hardware fisico, come quasi ogni classe server moderno sistema gestirà il carico. Detto questo, le seguenti sezioni coprono come valutare un nuovo o un ambiente esistente al fine di selezionare l'hardware giusto. Ogni componente sarà analizzata nel dettaglio per garantire che gli amministratori AD DS possono valutare la loro infrastruttura utilizzando le raccomandazioni baseline e presidi specifici dell'ambiente.

JJ651019.collapse(it-it,WS.11).gif Valutazione di Active Directory Server RAM

Valutare la quantità di RAM che ha bisogno di un controller di dominio (DC) è in realtà piuttosto un esercizio complesso. C'è un alto potenziale di errore quando si tenta di utilizzare un sistema esistente per misurare quanta RAM è necessaria come LSASS sarà tagliare in condizioni di pressione memoria, artificialmente deflazionare la necessità. Inoltre, c'è il fatto piuttosto soggettivo che un individuo DC ha solo bisogno di memorizzare nella cache che cosa è "interessante" per i suoi clienti. Questo significa che i dati che deve essere memorizzato in un controller di dominio di un sito con solo un server di Exchange sarà molto diversi rispetto ai dati che deve essere memorizzato in un controller di dominio che solo l'autenticazione degli utenti.

In generale, come il lavoro per valutare la RAM per ogni controller di dominio su un caso per caso è proibitivo, la raccomandazione è fare riferimento i requisiti hardware di sistema operativo di base, oltre a raccomandazioni per software di terze parti (antivirus, gestione dei sistemi e così via) e il file NTDS.Dimensioni DIT e SYSVOL. Nella sezione pianificazione sarà discutere in modo più approfondito come questo può essere regolato in senso generale secondo le aspettative di livello di servizio.

JJ651019.collapse(it-it,WS.11).gif Valutazione di Active Directory della banda di rete

Questa sezione è meno di valutare le esigenze per quanto riguarda il traffico di replica, che si concentra sul traffico di attraversamento della WAN e completamente è coperto in Traffico di replica di Active Directory, piuttosto che per valutare la capacità totale della larghezza di banda e di rete necessari, comprensivi di query client, applicazioni di criteri di gruppo, e così via. Per ambienti esistenti, questo può essere raccolte tramite performance counters "rete interfaccia () \Bytes ricevuti/sec" e "Rete interfaccia () \Bytes Sent/sec." Per i contatori di interfaccia di rete, è consigliabile che intervalli di campionamento essere 15, 30 o 60 minuti. Nulla meno sarà generalmente troppo volatile per buona misura;niente maggiore sarà appianare le Sbirciatine quotidiane eccessivamente.

Per nuovi ambienti, non ci sono alcuna stima come con l'hardware corrente (100++ Mb) questo è generalmente un sacco e 1 Gb è comunemente distribuito. Nella nostra pratica, non abbiamo visto strozzature della rete con controller di dominio avendo un 1 Gb o meglio rete allegato.

JJ651019.note(it-it,WS.11).gif Nota
Generalmente, la maggior parte del traffico di rete su un controller di dominio sta per essere in uscita come la DC risponde alle query client. Questo è il motivo per cui l'attenzione per il traffico in uscita, anche se ogni ambiente dovrebbe essere valutati per entrambi. Gli approcci stessi possono essere utilizzati per affrontare e rivedere i requisiti di traffico di rete in ingresso. Riferimento:

JJ651019.collapse(it-it,WS.11).gif Valutazione di archiviazione dati Active Directory

Il prima e più importante considerazione sta valutando come grandi file NTDS.Sarà DIT e SYSVOL. Queste misure porteranno in disco di ridimensionamento sia fissata e allocazione della RAM. A causa della (relativamente) basso costo di questi componenti, la matematica non è necessario essere rigorosi e precisi. Contenuti su come valutare questo per ambienti nuovi ed esistenti possono essere trovati nella seguente serie di articoli: Archiviazione dei dati. In particolare, fare riferimento ai seguenti articoli:

JJ651019.note(it-it,WS.11).gif Nota
Gli articoli sono basato su stime di dimensione dei dati precedenti. Utilizzare dimensioni oggetto che riflettono le dimensioni effettive di oggetti nel proprio ambiente.

Quando si esaminano gli ambienti esistenti con più domini, ci possono essere variazioni nelle dimensioni dei database. Se questo è vero, usando il più piccolo catalogo globale (GC) e dimensioni non GC sarà accettabile.

La dimensione del database può variare tra versioni del sistema operativo. Controller di dominio che eseguono sistemi operativi precedenti, come Windows Server 2003 hanno una dimensione del database più piccola rispetto a un controller di dominio che esegue un sistema operativo più tardi come Windows Server 2008 R2, soprattutto quando tali Active Directory Cestino o credenziali comuni sono attivate le funzionalità.

Oltre al dimensionamento per capacità, è anche importante dimensione per le prestazioni in scenari dove AD DS sarà disco associato, ad esempio avvio e dove il database è troppo grande per essere tenuto in RAM. La performance counters disco logico (*) \Avg disco/sec, disco logico (*) \Avg disco/sec, disco logico (*) \Avg Disk sec/Transfer, disco logico (*) \Reads/sec, disco logico (*) \Writes/sec, disco logico (*) \Transfers/sec, disco logico (*) \Avg. Lettura coda del disco, disco logico (*) \Avg. Scrittura coda del disco, disco logico (*) \Avg. Coda del disco deve essere campionata in intervalli di 15/30/60 minuti per le esigenze dell'ambiente corrente del benchmark. Essa ha bisogno di essere notato che se il server è configurato con una quantità di RAM non ottimale, questi valori saranno di poco o nessun valore.

Nota su sfruttando questa informazione: per nuovi ambienti, si noti che le stime in Stime di crescita per Active Directory utenti e unità organizzative indicano che 100.000 utenti (nello stesso dominio) consumano circa 450 MB di spazio. Si prega di notare che gli attributi popolati possono avere un impatto enorme sull'importo totale. Attributi verranno popolati su molti oggetti dai prodotti Microsoft, tra cui Server di Exchange e Lync. Una valutazione basata sul portafoglio di prodotti nell'ambiente sarebbe preferita. In assenza di tale valutazione, una migliore stima per un ambiente che sfrutta o farà leva AD DS pesantemente può effettivamente essere tanto quanto 40 o 60 KB per ogni utente. Questo porta ad una stima di tra 4 GB a 6 GB per 100.000 utenti. Mentre questo approccio può sembrare impreciso, si prega di notare che le opzioni di storage attualmente disponibili, è realmente difficile trovare qualcosa che non conserverà questo e il sistema operativo. L'esercizio di dettagli fuori la matematica e test per stime precise per tutti, ma gli ambienti più grandi non può essere in realtà vale la pena investire sforzo e tempo significativo.

JJ651019.collapse(it-it,WS.11).gif Valutazione di Active Directory di utilizzo del processore

Per la maggior parte degli ambienti, dopo archiviazione, RAM e networking sono sintonizzati correttamente come descritto nella sezione pianificazione , gestione della quantità di necessarie capacità di elaborazione sarà il componente che merita più attenzione. Ci sono due sfide nella valutazione capacità CPU necessarie. La prima è se o non le applicazioni nell'ambiente vengono educate in un'infrastruttura di servizi condivisi e viene discusso nella sezione intitolata "Tracking costoso e inefficiente ricerche" nell'articolo Creating More Efficient Microsoft Active Directory-Enabled applicazioni o la migrazione dalla Legacy SAM chiama alle chiamate LDAP. In ambienti di grandi dimensioni, il motivo per che questo è importante è che applicazioni mal codificate possono guidare la volatilità nel carico della CPU, "rubare" una quantità eccessiva di tempo CPU da altre applicazioni, artificialmente guidare fino alle esigenze di capacità e irregolarmente distribuire il carico contro il DCs. La seconda è che, come Active Directory è un ambiente distribuito con una grande varietà di clienti potenziali, stimando che la spesa di un "unico cliente" è soggettiva molto l'ambiente a causa di modelli di utilizzo e il tipo o la quantità di applicazioni sfruttando AD DS. In breve, molto come il pezzo di rete, per ampia applicabilità, questo è meglio avvicinato dalla prospettiva di valutare la capacità totale necessaria nell'ambiente. Per gli ambienti esistenti, al fine di garantire buoni dati per quanto riguarda il carico del processore, è importante assicurare che il collo di bottiglia nel sistema non è la performance di stoccaggio. Così, raccogliere i contatori delle prestazioni "Disco logico (<Unità del Database NTDS>) \Avg Disk sec/Read" e "processo (lsass) \ % Processor Time". I dati nel "processo (lsass) \ % Processor Time" sarà artificialmente basso se "Disco logico (<Unità del Database NTDS>) \Avg Disk sec/Read" supera i 20 ms. Come prima, si raccomanda che intervalli di campionamento sia 15, 30 o 60 minuti. Nulla meno sarà generalmente troppo volatile per buona misura;niente maggiore sarà appianare le Sbirciatine quotidiane eccessivamente. Per i nuovi ambienti, con velocità del processore di oggi (circa 3 Ghz), una stima di 1000 utenti per core fisico è un sicuro punto di partenza, ma solo un punto di partenza.

JJ651019.collapse(it-it,WS.11).gif Valutazione carico di autenticazione del Client Cross-Trust

Molti ambienti possono avere uno o più domini collegati da un trust. Se una richiesta di autenticazione non è utilizzando l'autenticazione Kerberos e di un'identità in un altro dominio, la richiesta sarà necessario attraversare i trust, che si tratti di un trust esterno, trust tra foreste, o anche tra i domini della foresta stessa, utilizzando il canale protetto del controller di dominio a un controller di dominio nel dominio di destinazione o il dominio successivo nel percorso al dominio di destinazione. Il numero di chiamate contemporanee utilizzando il canale sicuro che un DC può rendere a controller di dominio in un dominio trusted è controllato da un ambiente noto come MaxConcurrentAPI. Per i controller di dominio, assicurando che il canale sicuro in grado di gestire la quantità di carico è compiuta da uno dei due approcci: tuning MaxConcurrentAPI o, all'interno di una foresta, creazione di trust di collegamento. Per misurare il volume di traffico in un singolo trust, si riferiscono a come fare per l'autenticazione NTLM utilizzando l'impostazione MaxConcurrentApi di ottimizzazione delle prestazioni.

Durante la raccolta dei dati, questo, come con tutti gli altri scenari, dovrà essere raccolti durante i periodi di picco del giorno. Questa data deve essere assunto durante i periodi di picco l'autenticazione.

JJ651019.note(it-it,WS.11).gif Nota
Intraforest e foreste scenari possono causare l'autenticazione attraversare più Trust e ogni fase avrebbe bisogno di essere sintonizzato.

JJ651019.collapse(it-it,WS.11).gif Tabelle riassuntive di raccolta dati

Nuovo ambiente

Componente

Stime

Dimensioni di archiviazione e Database

40 KB per 60 KB per ogni utente

RAM

Dimensione del database

Raccomandazioni del sistema operativo di base

Applicazioni di terze parti

Rete

1 Gb

CPU

1000 utenti simultanei per ogni core

Ambiente esistente

Componente

Valutare l'ambiente esistente

Dimensioni di archiviazione e Database

La sezione intitolata "per attivare la registrazione di spazio su disco che viene liberata dalla deframmentazione" in Limiti di archiviazione

Archiviazione / Database Performance

  • Disco logico (< unità del Database NTDS >) \Avg Disk sec/Read, LogicalDisk (< unità del Database NTDS >) \Avg disco/sec, disco logico (< unità del Database NTDS >) \Avg Disk sec/Transfer

  • Disco logico (< unità del Database NTDS >) \Reads/sec, LogicalDisk (< unità del Database NTDS >) \Writes/sec, \Transfers/sec Disco logico (< unità del Database NTDS >)

  • Disco logico (< unità del Database NTDS >) \Avg. Lettura coda del disco, disco logico (< unità del Database NTDS >) \Avg. Scrittura coda del disco, disco logico (< unità del Database NTDS >) \Avg. Lunghezza coda del disco

RAM

Dimensione del database

Raccomandazioni del sistema operativo di base

Applicazioni di terze parti

Rete

"Rete interfaccia () \Bytes ricevuti/sec"

"Rete interfaccia () \Bytes inviati/sec"

CPU

"Disco logico (< unità del Database NTDS >) \Avg Disk sec/Read"

"Processo (lsass) \ % Processor Time"

NETLOGON

"Acquisisce Netlogon (*) \Semaphore"

"Netlogon (*) \Semaphore timeout"

"Netlogon (*) \Average semaforo tenere il tempo"

Per lungo tempo, raccomandazione della Comunità per il dimensionamento AD DS è stato quello di "mettere in quanta più RAM come la dimensione del database". Per la maggior parte, che la raccomandazione è tutto ciò che la maggior parte dei ambienti necessari per essere preoccupati. Ma l'ecosistema consumando AD DS ha ottenuto molto più grande, come hanno gli ambienti Active Directory se stessi, sin dalla sua introduzione nel 1999. Anche se l'aumento di potenza di calcolo e l'interruttore da x x86 architetture a 64 architetture ha reso irrilevante per un più ampio insieme di clienti che esegue Active Directory su hardware fisico gli aspetti più sottili di ridimensionamento per le prestazioni, la crescita di virtualizzazione ha reintrodotto il tuning preoccupazioni per un pubblico più vasto rispetto a prima.

La seguente guida è così su come determinare e piano per le richieste di Active Directory come servizio indipendentemente dal fatto se è stata distribuita in un fisico, un mix virtuale fisico o uno scenario puramente virtualizzato. Come tale, si rompe la valutazione a ciascuno dei quattro componenti principali: storage, memoria, rete e processore. In breve, al fine di massimizzare le prestazioni su Active Directory, l'obiettivo è arrivare più vicino al processore associato come possibile.

JJ651019.collapse(it-it,WS.11).gif RAM

Semplicemente, più che può essere memorizzato nella cache in RAM, meno è necessario andare in disco. Per ottimizzare la scalabilità del server la quantità minima di RAM deve essere la somma delle dimensioni del database corrente, le dimensioni totali di SYSVOL, il sistema operativo raccomandata quantità e le raccomandazioni del fornitore per gli agenti (antivirus, monitoraggio, backup e così via). Un importo supplementare deve essere aggiunto per accogliere la crescita per tutta la durata del server. Questo sarà l'ambiente soggettivo sulla base delle stime di crescita del database basato su cambiamenti ambientali.

Per gli ambienti dove massimizzando la quantità di RAM non è costo effettivo (ad esempio le posizioni un satellite) o non è fattibile (DIT è troppo grande), riferimento la sezione Storage per garantire tale deposito è progettata correttamente.

Un corollario che esce nel contesto generale in memoria di ridimensionamento è ridimensionamento del file della pagina. Nello stesso contesto come tutto il resto memoria correlati, l'obiettivo è di ridurre al minimo andando molto più lento disco. Quindi la domanda dovrebbe andare da, "come dovrebbe il file di paging essere ridimensionato?" a "Quanta RAM è necessario ridurre al minimo lo spostamento?" La risposta alla domanda di quest'ultimo è delineata nel resto di questa sezione. Questo lascia la maggior parte della discussione per il dimensionamento della pagina del file al Regno delle raccomandazioni generali del sistema operativo e la necessità di configurare il sistema per il dump di memoria, che non sono correlate alle prestazioni di AD DS.

JJ651019.collapse(it-it,WS.11).gif Considerazioni sulla virtualizzazione per RAM

Evitare memory overcommit dell'host. L'obiettivo fondamentale dietro ottimizzando la quantità di RAM è di ridurre al minimo la quantità di tempo trascorso andando a disco. Negli scenari di virtualizzazione, il concetto di memoria overcommit esiste dove più RAM allocato agli ospiti allora esiste sulla macchina fisica. Questo di per sé non è un problema. Diventa un problema quando la memoria totale utilizzata attivamente da tutti gli ospiti supera la quantità di RAM sull'host e host sottostante inizia lo spostamento. Prestazioni diventa disco associato nei casi in cui il controller di dominio sta per file NTDS.DIT per ottenere dati o il controller di dominio sta per il file di pagina per ottenere i dati, o l'host sta per disco per ottenere i dati che il cliente pensa è in RAM.

JJ651019.collapse(it-it,WS.11).gif Esempio di calcolo Sommario

Componente

Stimata di memoria (esempio)

Sistema operativo di base consigliata RAM (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 il backup da eseguire, agli amministratori di accedere senza impatto

1 GB

Totale

12 GB

CONSIGLIATO: 16 GB

Nel corso del tempo, l'assunzione può essere fatta che più dati verranno aggiunti al database e server sarà probabilmente in produzione per 3 a 5 anni. Basato su una stima di crescita del 33%, da 16 GB sarebbe una quantità ragionevole di RAM a mettere in un server fisico. In una macchina virtuale, data la facilità con cui le impostazioni possono essere modificate e RAM possono essere aggiunti alla VM, a partire da 12 GB con il piano di monitoraggio e aggiornamento in futuro è ragionevole.

JJ651019.collapse(it-it,WS.11).gif Rete

JJ651019.collapse(it-it,WS.11).gif Esigenze di larghezza di banda

Pianificazione per la scalabilità della rete comprende due categorie distinte: la CPU e la quantità di traffico carico da traffico di rete. Ognuno di questi scenari è straight-forward rispetto ad alcuni degli altri argomenti in questo articolo.

Nel valutare la quantità di traffico deve essere sostenuto, ci sono due categorie uniche di pianificazione della capacità di AD DS in termini di traffico di rete. Il primo è il traffico di replica che attraversa tra controller di dominio e viene accuratamente coperto in riferimento a Traffico di replica di Active Directory ed è ancora rilevante per le versioni correnti di AD DS. Il secondo è il traffico client-server all'interno del sito. Uno degli scenari più semplici per pianificare, all'interno del sito traffico prevalentemente riceve le richieste di piccole da parte dei clienti rispetto a grandi quantità di dati inviati al client. 100 Mb in genere sarà adeguato in ambienti fino a 5.000 utenti al server, in un sito. Supporto utilizzando una scheda di rete di 1 Gb e ricevere Side Scaling (RSS) è consigliato per nulla di sopra di 5.000 utenti. Per convalidare questo scenario, soprattutto nel caso di scenari di consolidamento server, guardate alla rete interfaccia () \Bytes/sec attraverso tutti i controller di dominio in un sito, aggiungerli insieme e dividere per il numero di destinazione del controller di dominio per assicurarsi che ci sia un'adeguata capacità. Il modo più semplice per farlo è usare la visualizzazione "Area in pila" in Monitoraggio affidabilità e Performance Monitor (precedentemente noto come Perfmon), assicurandosi che tutti i contatori sono in scala lo stesso.

Si consideri il seguente esempio (noto anche come un davvero, davvero complesso modo di confermare che la regola generale è applicabile a un ambiente specifico). I seguenti presupposti:

  • L'obiettivo è di ridurre l'impronta ai server come pochi come possibile. Idealmente, un server porterà il carico e viene distribuito un server aggiuntivo per ridondanza (N + 1 scenario).

  • In questo scenario, la scheda di rete corrente supporta solo 100 Mb ed è in un ambiente di commutazione.

    L'utilizzo della larghezza di banda di rete destinazione massima è 60% in uno scenario di N (perdita di un DC).

  • Ogni server dispone di circa 10.000 clienti ad esso collegati.

Conoscenza acquisita dai dati nel grafico (NetworkInterface (*) \Bytes Sent/sec):

  1. Il giorno di affari si avvia ramping intorno 05.30 e si snoda alle 19:0

  2. Il periodo più trafficato di picco è 8:0-08.15, con maggiore di 25 byte inviati/sec sul controller di dominio più trafficate. (Nota: tutti i dati sulle prestazioni è storico. Così il picco dati punto 08.15 indica il carico dalle 08.00 08.15).

  3. Ci sono picchi prima 4:0, con più di 20 byte inviati/sec su DC più trafficata, che potrebbe indicare sia carico da diversi fusi o attività, infrastrutture, come i backup di sfondo. Poiché il picco a 8:0 supera questa attività, non è rilevante.

  4. Ci sono 5 controller di dominio nel sito.

  5. Il carico max è di circa 5,5 MB/s per la DC, che rappresenta il 44% della connessione 100 Mb. Utilizzando questi dati, stima che il totale della larghezza di banda necessaria tra 8:0 e 8:15 è 28 MB/s.

    JJ651019.note(it-it,WS.11).gif Nota
    Prestare attenzione al fatto che i contatori di inviare/ricevere di interfaccia di rete sono in byte e banda di larghezza è misurata in bit. 100 Mb / 8 = 12,5 MB, 1 Gb / 8 = 128 MB.

Conclusioni:

  1. Questo ambiente corrente incontra il livello N + 1 di tolleranza d'errore al 60% dell'utilizzo della destinazione. Prendendo un sistema offline si sposterà la larghezza di banda per ogni server da circa 5,5 MB/s (44%) a circa 7 MB/s (56%).

  2. Basato sull'obiettivo precedentemente dichiarato di consolidare in un server, questo sia supera l'utilizzazione massima del bersaglio e teoricamente il possibile utilizzo di una connessione a 100 Mb.

  3. Con una connessione di 1 Gb, questo rappresenterà il 22% della capacità totale.

  4. In condizioni operative normali nello scenario N + 1, carico del client sarà relativamente uniformemente distribuito a circa 14 MB/s per server o 11% della capacità totale.

  5. Per garantire capacità è adeguata durante l'indisponibilità di un DC, gli obiettivi operativi normali per server sarebbe circa 30% della rete utilizzo o 38 MB/s per ogni server. Failover obiettivi sarebbe 60% dell'utilizzo della rete o 72 MB/s per ogni server.

In breve, la distribuzione finale dei sistemi dovrà avere un adattatore di rete 1 Gb ed essere collegata ad un'infrastruttura di rete che sosterrà il carico ha detto. Una nota ulteriore è che data la quantità di traffico di rete generato, il carico della CPU da comunicazioni di rete può avere un impatto significativo e da limitare la massima scalabilità di AD DS. Questo stesso processo può essere utilizzato per stimare la quantità di comunicazione in entrata per la DC. Ma dato il predominio del traffico in uscita rispetto al traffico in entrata, è un esercizio accademico per la maggior parte degli ambienti. Garantendo il supporto hardware per RSS è importante in ambienti con maggiore di 5.000 utenti al server. Per gli scenari con elevato traffico di rete, bilanciamento del carico di interrupt può essere un collo di bottiglia. Questo può essere rilevato dal processore (*) \ % tempo di Interrupt inegualmente distribuiti in CPU. RSS abilitato NIC può attenuare questa limitazione e aumentare la scalabilità.

JJ651019.note(it-it,WS.11).gif Nota
Un simile approccio può essere utilizzato per stimare la capacità aggiuntiva necessaria quando il consolidamento dei data center, o andare in pensione un controller di dominio in una posizione satellitare. Semplicemente raccogliere il traffico in entrata e in uscita per i clienti e che sarà la quantità di traffico che ora sarà presente sui collegamenti WAN.

In alcuni casi, potrebbero verificarsi più traffico del previsto perché il traffico è più lento, come il controllo dei certificati quando non riesce a soddisfare i timeout aggressivi sulla WAN. Per questo motivo, l'utilizzo e dimensionamento WAN dovrebbe essere un processo iterativo, in corso.

JJ651019.collapse(it-it,WS.11).gif Considerazioni sulla virtualizzazione per larghezza di banda

È facile fare raccomandazioni per un server fisico: 1 Gb per i server di supporto maggiore di 5000 utenti. Una volta ospiti più avviare la condivisione di un'infrastruttura di switch virtuale sottostante, attenzione supplementare è necessario garantire che l'host ha sufficiente larghezza banda per supportare tutti gli ospiti del sistema e quindi richiede il rigore supplementare. Questo non è altro che un'estensione di garantire l'infrastruttura di rete nella macchina host. Questo è a prescindere se la rete è comprensivo di controller di dominio in esecuzione come macchina virtuale guest su un host con il traffico di rete andando oltre uno switch virtuale, oppure se collegato direttamente ad un interruttore fisico. Lo switch virtuale è solo una componente più dove l'uplink deve supportare la quantità di dati da trasmettere. Così la scheda di rete fisica host fisico collegata allo switch dovrebbe essere in grado di supportare il carico DC plus tutti gli altri ospiti condivisione switch virtuale collegato alla scheda di rete fisica.

JJ651019.collapse(it-it,WS.11).gif Esempio di calcolo Sommario

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

Totale

28.5 MB/s

Consigliato: 72 MB/s (28,5 MB/s diviso per 40%)

Target sistemi di conteggio

Larghezza di banda totale (dall'alto)

2

28.5 MB/s

Comportamento normale risultante

28,5 / 2 = 14.25 MB/s

Come sempre, nel corso del tempo il presupposto può essere fatto che aumenterà il carico del client e questa crescita dovrebbe essere progettata per la migliore possibile. La quantità consigliata per pianificare consentirebbe una crescita stimata nel traffico di rete di 50%.

JJ651019.collapse(it-it,WS.11).gif Archiviazione

JJ651019.collapse(it-it,WS.11).gif Dimensionamento

Rispetto a 13 anni fa quando Active Directory è stato introdotto, un tempo quando le unità 4 e 9 GB erano le dimensioni più comuni unità, ridimensionamento per Active Directory non è nemmeno una considerazione per tutti, ma gli ambienti più grandi. Con le dimensioni del più piccolo disco rigido disponibile nella gamma 180 GB, l'intero sistema operativo, SYSVOL e NTDS.DIT può facilmente montare su un disco. Come tale, si raccomanda di deprecare pesanti investimenti in questo settore.

L'unica raccomandazione per l'esame è quello di garantire che il 110% del file NTDS.Dimensione DIT è disponibile al fine di consentire la deframmentazione. Inoltre, alloggi per la crescita durante la vita dell'hardware dovrebbero essere fatta.

JJ651019.collapse(it-it,WS.11).gif Considerazioni sulla virtualizzazione per Storage

In uno scenario in cui più file di disco virtuale sono essere allocati su un singolo volume uso un fisso di dimensioni su disco di almeno 210% (100% del DIT + 110% di spazio libero) le dimensioni del DIT per assicurarsi che sia riservato uno spazio adeguato.

JJ651019.collapse(it-it,WS.11).gif Esempio di calcolo Sommario

Dati raccolti dalla fase di valutazione

NTDS.Dimensione DIT

35 GB

Modificatore per consentire in linea defrag

2.1

Archiviazione totale necessaria

73,5 GB

JJ651019.note(it-it,WS.11).gif Nota
Questa archiviazione necessaria è oltre l'archiviazione necessario per SYSVOL, sistema operativo, file di pagina, file temporanei, i dati memorizzati nella cache locali (ad esempio i file di installazione) e applicazioni.

JJ651019.collapse(it-it,WS.11).gif Prestazioni

Come la componente più lento all'interno di qualsiasi computer, archiviazione può avere il maggiore impatto negativo sull'esperienza del cliente. Pianificazione archiviazione costituisce due componenti: capacità e prestazioni. Una grande quantità di tempo e di documentazione è trascorso sulla capacità di pianificazione, lasciando le prestazioni spesso completamente trascurata. La prima cosa da notare su questo, però, è che gran parte degli ambienti non sono abbastanza grande che questo è in realtà una preoccupazione, e la raccomandazione "messo in quanta più RAM come la dimensione del database" solitamente copre il resto, anche se potrebbe essere eccessivo per le posizioni satellitari. Per coloro che sono abbastanza grandi che le raccomandazioni di dimensionamento RAM non sono fattibili, le conseguenze di affacciato sulla pianificazione di archiviazione per le prestazioni possono essere devastanti. Con l'introduzione di nuovi tipi di archiviazione e scenari di storage virtualizzato e condiviso, condiviso fusi in una SAN Storage Area Network (), file di disco virtuale su una SAN o network attached storage e l'introduzione di solida unità allo stato, le migliori pratiche generali di "mettere il sistema operativo, i registri e di database" su dischi fisici distinti inizia a perdere la sua importanza per una varietà di motivi;il più significativo è che il "disco" non è più garantito per essere un mandrino dedicato.

L'obiettivo finale di tutti gli sforzi di prestazioni di archiviazione è di garantire la necessaria quantità di operazioni di Input/Output al secondo (IOPS) sono disponibili e che quelli IOPS accadere entro un lasso di tempo accettabile. Questo copre come valutare quali richieste di Active Directory di archiviazione sottostante. Mentre alcune indicazioni generali sono dato nell'appendice riguardo alle modalità di progettazione scenari di archiviazione locale, data l'ampiezza ampia di opzioni di deposito disponibili, si consiglia di coinvolgere il team di supporto hardware o fornitori per assicurare che la specifica soluzione soddisfa le esigenze di AD DS. I seguenti numeri sono le informazioni che sarebbero state fornite agli specialisti di archiviazione.

JJ651019.collapse(it-it,WS.11).gif Ambienti dove fornendo almeno tanto RAM come la dimensione del database non è una valida opzione

È utile capire perché queste raccomandazioni esistono in modo che i cambiamenti nella tecnologia di archiviazione possono essere accomodati. Queste raccomandazioni esistono per due motivi. Il primo è l'isolamento dell'IO, tale che problemi di prestazioni (che è, paging) sul mandrino sistema operativo non influire sulle prestazioni del database e profili IO. La seconda è che i file di registro di Active Directory (e la maggior parte dei database) sono sequenziale in natura e basata su mandrino hard drives e cache hanno un vantaggio enorme prestazioni quando utilizzato con sequenza IO rispetto i modelli IO più casuali del sistema operativo e modelli IO quasi puramente casuale di Active Directory del database di auto. Isolando il IO sequenza di un disco fisico separato, velocità effettiva può essere aumentato. La sfida presentata da opzioni di archiviazione di oggi è che le ipotesi fondamentali dietro queste raccomandazioni non sono più vera. In molti virtualizzati scenari di archiviazione, ad esempio iSCSI, SAN, NAS e Virtual Disk file di immagine, il sottostante storage media è condivisa tra più host, così completamente negando l'aspetti di "ottimizzazione sequenziale IO" e "l'isolamento dell'IO". In realtà questi scenari di aggiungere un ulteriore livello di complessità in quanto altri host l'accesso ai media condivisi può degradare reattività al controller di dominio.

Nella pianificazione delle prestazioni di storage, ci sono tre categorie di considerare: stato della cache freddo, stato riscaldato cache e backup e ripristino. Lo stato della cache freddo si verifica in scenari, ad esempio quando il controller di dominio è inizialmente riavviato o viene riavviato il servizio Active Directory e non non c'è alcun dati di Active Directory in RAM. Stato della cache caldo è dove il controller di dominio è in uno stato stazionario e il database viene memorizzato nella cache. Queste sono importante notare come essi guiderà profili di prestazioni molto diverse, e avendo abbastanza RAM per memorizzare nella cache l'intero database non aiuta le prestazioni quando la cache è fredda. Si può considerare prestazioni design per questi due scenari con la seguente analogia, la cache fredda il riscaldamento è uno "sprint" e che esegue un server con una cache di calda è una "maratona".

Sia per il fredda della cache e scenario caldo cache, la questione diventa quanto velocemente l'archiviazione può spostare i dati dal disco in memoria. Riscaldamento della cache è uno scenario dove, nel corso del tempo, le prestazioni migliorano come query più riutilizzare dati, cache hit rate aumenta e diminuisce la frequenza della necessità di andare in disco. Di conseguenza diminuisce l'impatto sulle prestazioni negative di andare in disco. Alcun degrado delle prestazioni è solo transitorio durante l'attesa per la cache a caldo e a crescere per la dimensione consentita massima, dipendente dal sistema. La conversazione può essere semplificata di quanto velocemente i dati possono essere ottenuti fuori del disco ed è una semplice misura dell'IOPS disponibili in Active Directory, che è soggettiva di IOPS disponibili dall'archivio sottostante. Dal punto di vista progettuale, perché riscaldamento gli scenari di cache e backup e ripristino accadere in via eccezionale, normalmente si verificano fuori delle ore e sono soggettivo per il carico della DC, raccomandazioni generali non esistono tranne che queste attività devono essere pianificate per ore non di punta.

AD DS, nella maggior parte degli scenari, è letto prevalentemente IO, di solito un rapporto del 90% read/10% scrivere. Lettura IO spesso tende ad essere il collo di bottiglia per l'esperienza utente e con scrittura IO, cause scrivere prestazioni a degradare. Come IO a NTDS.DIT è prevalentemente casuale, cache tendono a fornire il minimo beneficio per leggere IO, rendendolo che molto più importante per configurare l'archiviazione per legge profilo IO correttamente.

Per condizioni di funzionamento normale, l'obiettivo di pianificazione di archiviazione è ridurre al minimo i tempi di attesa per una richiesta da Active Directory devono essere restituiti dal disco. Questo significa essenzialmente che il numero di eccezionale e in attesa di IO è inferiore o equivalente al numero di percorsi per il disco. Ci sono vari modi per misurare questo. In una scenario di monitoraggio delle prestazioni, la raccomandazione generale è che LogicalDisk (<Unità del Database NTDS>) \Avg Disk sec/Read essere meno di 20 ms. La soglia di funzionamento desiderata dovrebbe essere molto inferiore, preferibilmente come vicino alla velocità di archiviazione come possibile, nella gamma di millisecondo 2 a 6 (secondo 002 a.006) a seconda del tipo di archiviazione.

Esempio:

Storage Latency Chart

Analizzando il grafico:

  • Ovale di colore verde a sinistra – la latenza rimane coerenza a 10 ms. Il carico aumenta 800 IOPS-2400 IOPS. Questo è il piano assoluto per quanto rapidamente una richiesta IO può essere elaborata da archiviazione sottostante. Questo è soggetto a specifiche della soluzione di archiviazione.

  • Borgogna ovale a destra – il throughput rimane piatto dall'uscita del cerchio verde attraverso alla fine dell'insieme di dati mentre la latenza continua ad aumentare. Questa è la dimostrazione che, quando i volumi di richiesta superano i limiti fisici di archiviazione sottostante, il più a lungo le richieste trascorrono seduti in coda in attesa di essere inviato al sottosistema di archiviazione.

Applicando questa conoscenza:

  1. Impatto a un utente l'interrogazione l'appartenenza al gruppo - Active Directory pagine del database sono 8 KB di dimensione. Fare un'ipotesi semplicistica che un gruppo contenente 1000 membri rappresenta circa 1 MB di dati, ciò significa che un minimo di 128 pagine devono essere letti dal disco. Supponendo che nulla viene memorizzato nella cache, al piano (10 ms) questo sta andando a prendere un minimo 1,28 secondi per caricare i dati dal disco al fine di restituirlo al client. A 20 ms, dove la velocità effettiva di archiviazione ha tempo maxed ed è anche la massima consigliata, ci vorranno 2,5 secondi per ottenere i dati dal disco per ritornare all'utente finale.

  2. A che cosa Vota la cache sarà riscaldato – facendo l'ipotesi che il client di caricare sta andando a massimizzare il throughput su questo esempio di archiviazione, la cache sarà caldo a una velocità di 2400 IOPS * 8 KB per IO. O, circa 20 MB/s per secondo, caricamento circa 1 GB di database nella RAM ogni 53 secondi.

JJ651019.note(it-it,WS.11).gif Nota
È normale che per brevi periodi a osservare la salita latenze quando componenti aggressivamente leggere o scrivere sul disco, come quando il sistema di backup o quando Active Directory è in esecuzione la procedura di garbage collection. Ulteriore camera testa sopra i calcoli dovrebbe essere fornita per ospitare questi eventi periodici. L'obiettivo è di fornire abbastanza throughput per accogliere questi scenari senza influire sul normale funzionamento.

Come si può vedere, c'è un limite fisico basato sul design di archiviazione a quanto velocemente la cache può possibilmente calde. Che cosa scalderà la cache sono in arrivo le richieste dei client fino al tasso che può fornire l'archiviazione sottostante. Esecuzione di script per "Preriscaldare" cache durante le ore di picco fornirà concorrenza a carico guidato da richieste client reale. Che può influenzare negativamente la consegna dei dati che i client devono in primo luogo perché, da design, genererà la concorrenza per le risorse scarse disco come tentativi artificiali per scaldare la cache si caricheranno i dati che non sono rilevanti per i clienti contattando la DC.

JJ651019.collapse(it-it,WS.11).gif Considerazioni sulla virtualizzazione per prestazioni

Simile a tutte le precedenti discussioni di virtualizzazione, la chiave qui è di garantire che l'infrastruttura condivisa sottostante in grado di supportare il carico DC plus le altre risorse utilizzando il sottostante shared media e tutte le vie ad esso. Questo è vero se un controller di dominio fisico è condividendo lo stesso supporto sottostante su una SAN, NAS o infrastruttura iSCSI come altri server o applicazioni, sia che si tratti di un ospite utilizzando passa attraverso l'accesso a una SAN, NAS o infrastruttura iSCSI che condivide il supporto sottostante, o se l'ospite è utilizzando un file di disco virtuale che risiede su mezzi condivisi localmente o una SANNAS, o infrastruttura iSCSI. L'esercizio progettuale è tutto assicurandosi che il supporto sottostante in grado di supportare il carico totale di tutti i consumatori.

Inoltre, da una prospettiva di ospite, come ci sono percorsi di codice aggiuntivo che devono essere attraversati, c'è un impatto sulle prestazioni di dover passare attraverso un host per accedere a qualsiasi deposito. Non sorprendentemente, storage performance test indica che la virtualizzazione ha un impatto sulla velocità effettiva che è soggettivo per l'utilizzo del processore del sistema host (vedere Appendice a: criteri di dimensionamento CPU), che è ovviamente influenzata dalle risorse dell'host richiesto dall'ospite. Ciò contribuisce a delle considerazioni di virtualizzazione per quanto riguarda le esigenze di elaborazione in uno scenario virtualizzato (vedere Considerazioni sulla virtualizzazione per l'elaborazione).

Rendendo questo più complessi è che ci sono una varietà di opzioni di archiviazione differenti che sono disponibili che hanno tutti gli impatti delle diverse prestazioni. Utilizzare un moltiplicatore di 1.10 per regolare per le opzioni di archiviazione differenti per virtualizzati su Hyper-V, ad esempio archiviazione pass-through, adattatore SCSI o IDE. Le regolazioni che devono essere fatte durante il trasferimento tra gli scenari di archiviazione differenti sono irrilevanti per quanto riguarda l'archiviazione sia locale, SAN, NAS o iSCSI.

JJ651019.collapse(it-it,WS.11).gif Esempio di calcolo Sommario

Determinazione della quantità di IO necessario per un sistema sano in normali condizioni di funzionamento:

  • Disco logico (< unità del Database NTDS >) \Transfers/sec durante il periodo di picco 15 minuti periodo

  • Per determinare la quantità di IO necessari per lo stoccaggio dove viene superata la capacità di archiviazione sottostante:

    • (Disco logico (<Unità del Database NTDS>) \Avg Disk sec/Transfer / < Target Avg Disk sec/Read >) * LogicalDisk (<Unità del Database NTDS>) \Transfers/sec = IOPS necessari

    • Mentre un < Target Avg Disk sec/trasferimento >può essere sotto i limiti fisici o elettronici del disco, la latenza desiderata non può essere ottenuta. Impostazione destinazione inferiore possibile fornirà una quantità di IOPS necessari artificialmente elevata.

Contatore

Valore

Effettivo LogicalDisk (<Unità del Database NTDS>) \Avg Disk sec/Transfer

02 secondi

Destinazione LogicalDisk (<Unità del Database NTDS>) \Avg Disk sec/Transfer

secondi,01

Moltiplicatore per il cambiamento in disponibile IO

0,02 / 0.01 = 2

Nome del valore

Valore

Disco logico (<Unità del Database NTDS>) \Transfers/sec

400

Moltiplicatore per il cambiamento in disponibile IO

2

IOPS totali necessarie durante il periodo di picco

800

Per determinare la frequenza con cui la cache è desiderato per essere riscaldato:

  • Determinare il tempo massimo accettabile per scaldare la cache. È sia la quantità di tempo che si dovrebbe prendere per caricare l'intero database dal disco, o per gli scenari dove l'intero database non può essere caricato in RAM, questo sarebbe il tempo massimo per riempire la RAM.

  • Determinare la dimensione del database, escluso lo spazio bianco. Per ulteriori informazioni, vedere Valutazione di archiviazione dei dati di Active Directory.

  • Dividere la dimensione del database da 8 KB;che sarà l'IOs totale necessario per caricare il database.

  • Dividere il totale IOs per il numero di secondi in cui l'intervallo di tempo definito.

Si noti che il tasso che è determinare, mentre accurata, non essere esatto perché le pagine precedentemente caricate vengono sfrattate se ESE non è configurato per avere una dimensione fissa della cache e Active Directory per impostazione predefinita utilizza la dimensione della cache variabile.

Punti dati da raccogliere

Valori

Tempo massimo accettabile a caldo

10 minuti (600 secondi)

Dimensione del database

2 GB

Fase di calcolo

Formula

Risultato

Calcolare la dimensione del database in pagine

(2 GB * 1024 * 1024) = dimensione del database in KB

2.097.152 KB

Calcolare il numero di pagine nel database

2.097.152 KB/8 KB = numero di pagine

262.144 pagine

Calcolare IOPS necessario riscaldare completamente la cache

262.144 pagine 600 secondi = IOPS necessari

437 IOPS

JJ651019.collapse(it-it,WS.11).gif Elaborazione

JJ651019.collapse(it-it,WS.11).gif Introduzione

Al fine di pianificare la pianificazione della capacità per i controller di dominio, potenza di elaborazione probabilmente richiede più attenzione e comprensione. Quando dimensionamento sistemi per garantire le massime prestazioni, c'è sempre un componente che è il collo di bottiglia. Da un punto di vista hardware, se è seguito in questo articolo, l'unico componente residua che può essere un collo di bottiglia è la CPU. Anche se si può argomentare che cambiamenti nelle architetture hardware possono avere un effetto enorme sulle prestazioni complessive e di comportamento, la capacità di prevedere in modo affidabile un effetto pratico di tutti i miglioramenti ha detti è quasi inesistente. Come tale, devono verificarsi generalizzazioni, e questo è circa generalizzando e bilanciamento tra un ragionevolmente sicuro e un acquisto ragionevole costo effettivo delle infrastrutture necessarie per sostenere il carico del client.

Simile alla sezione networking dove la richiesta dell'ambiente è recensita su un sito di base, lo stesso deve essere fatto per la capacità di calcolo richiesta. In molti casi AD DS, come le tecnologie di rete disponibili superano di gran lunga la domanda, il componente di rete richiede molto meno rigore per garantire un'offerta adeguata. Dimensionamento capacità CPU non può essere come casualmente gestita in qualsiasi ambiente di dimensioni anche moderata;nulla sopra alcune migliaia di utenti simultanei.

Una stima generale di utenti per ogni CPU è tristemente inapplicabile per tutti gli ambienti. Le richieste di calcolo sono soggetti a profilo utente di comportamento e di applicazione. Ma ogni infrastruttura di Active Directory deve iniziare da qualche parte. Come tale, il suggerimento di 1000 utenti simultanei per CPU (in precedenza in questo articolo) è una stima provvisoria per una nuova infrastruttura. Tuttavia, la maggior parte delle infrastrutture non sono nuove di zecca. Nell'ultimo decennio della loro distribuzione, essi hanno accumulato sempre più applicazioni che dipendono da Active Directory. Come dovrebbe essere calcolata la capacità necessaria?

JJ651019.collapse(it-it,WS.11).gif Profilo di destinazione sito comportamento

Come accennato in precedenza, quando si pianifica la capacità per un intero sito, l'obiettivo è di indirizzare un disegno con un design N + 1 capacità tali che il fallimento di un sistema durante il periodo di picco permetterà per la continuazione del servizio ad un livello ragionevole di qualità. Ciò significa che in uno scenario di "N", carico attraverso tutte le caselle deve essere inferiore al 100% (meglio ancora, meno di 80%) durante i periodi di picco.

Inoltre, se le applicazioni e client nel sito utilizza procedure consigliate per l'individuazione dei controller di dominio (che è, utilizzando la funzione DsGetDcName), il client dovrebbe essere relativamente uniformemente distribuito con picchi transitori minori a causa di qualsiasi numero di fattori.

Foe il prossimo esempio, i seguenti presupposti:

  • Ognuno dei cinque controller di dominio nel sito ha la stessa quantità (4) della CPU.

  • Obiettivo totale utilizzo della CPU durante l'orario lavorativo è in condizioni di funzionamento normale ("N + 1") il 40% e 60% in caso contrario ("N"). Durante l'orario non di ufficio, l'utilizzo della CPU di destinazione è 80% perché il software di backup e manutenzione sono tenuti a consumare tutte le risorse disponibili.

CPU Chart

Analyzing the data in the chart (Process o (_Total)\% Processor Time) for each of the DCs:

  • Per la maggior parte, il carico è relativamente uniformemente distribuito che è quello che ci si aspetterebbe quando i client utilizzano DC locator e hanno ben scritto ricerche.

  • Ci sono un certo numero di picchi di 5 minuti del 10%, con alcuni come grande come il 20%. In genere, a meno che non provocano la destinazione di piano capacità deve essere superata, indagando queste non è utile.

  • Il periodo di picco per tutti i sistemi è tra circa 8:0 e 9:15. Con la transizione da circa 5:0 attraverso circa 17:0, questo è generalmente indicativo del ciclo economico. Le punte più randomizzate di utilizzo della CPU su uno scenario di casella tra 17:0 e 4:0 sarebbe fuori le preoccupazioni di pianificazione della capacità. Nota:

    JJ651019.note(it-it,WS.11).gif Nota
    Su un sistema ben gestito, picchi ha detti sono in esecuzione software di backup probabilmente, scansioni antivirus completo del sistema, inventario hardware o software, distribuzione software o patch e così via. Perché cadono di fuori del ciclo picco utente business, gli obiettivi non siano superati.

  • Come ogni sistema è circa il 40% e tutti i sistemi hanno lo stesso numero di CPU, dovrebbe uno fallire o essere disconnesso, i restanti sistemi funzionerebbe a circa il 60% (del sistema C 40% del carico è uniformemente divise e aggiunto al sistema A e sistema B esistenti 40% del carico). Per una serie di ragioni, questa ipotesi lineare non è perfettamente esatto, ma fornisce sufficiente precisione di calibro.

    Scenario – si alternano due controller di dominio in esecuzione al 40%: un domain controller fallisce, stimato CPU su quello restante sarebbe stima che l'80%. Questo lontano supera le soglie di piano capacità delineate e inizia anche a limitare severamente la quantità di testa camera per 10% al 20%, visto nel profilo di carico sopra, ciò significa che le punte sarebbero guidare la DC al 90% al 100% durante lo scenario "N" e sicuramente degradare la reattività.

JJ651019.collapse(it-it,WS.11).gif Calcolare CPU richieste

Il contatore dell'oggetto prestazioni "Process\% tempo processore" riassume la quantità totale di tempo che tutti i thread di un'applicazione spendere sulla CPU e si divide per l'ammontare totale del sistema di tempo che ha passato. The effect of this is that a multi-threaded application on a multi-CPU system can exceed 100% CPU time, and would be interpreted VERY differently than “Process o \% Processor Time”. In pratica il "processo (lsass) \ % Processor Time" può essere visto come il numero di CPU in esecuzione al 100% che sono necessarie per supportare le esigenze del processo. Un valore di 200% significa che 2 CPU, ognuno al 100%, sono necessari per sostenere il pieno carico di Active Directory. Anche se è una CPU in esecuzione al 100% della sua capacità più costo efficiente dal punto di vista dei soldi spesi su CPU e potenza e consumi energetici, per una serie di motivi, reattività migliore su un sistema multi-threaded si verifica quando il sistema non è in esecuzione al 100%.

Per soddisfare i picchi transitori a carico del client, è consigliabile una CPU periodo di picco di tra 40% e il 60% della capacità del sistema di destinazione. Lavorando con l'esempio precedente, ciò significherebbe che tra 3,33 (60% target) e 5 (40% target) CPU sarebbe necessaria per il carico di AD DS (processo lsass). Capacità aggiuntiva deve essere aggiunto nel secondo le esigenze del sistema operativo di base e di altri agenti richiesti (ad esempio antivirus, backup, monitoraggio e così via). Anche se l'impatto degli agenti deve essere valutata in base all'ambiente, può essere fatta una stima di tra 5 e 10% di una singola CPU. Nell'esempio corrente, questo suggerisce che tra 3.43 (60% target) e 5.1 (40% target) CPU sono necessarie durante i periodi di picco.

Il modo più semplice per farlo è usare la visualizzazione "Stacked Area" Monitoraggio affidabilità e Performance Monitor, assicurandosi che tutti i contatori sono in scala lo stesso.

Presupposti:

  • Obiettivo è di ridurre l'impronta ai server come pochi come possibile. Idealmente, 1 server vuoi trasportare il carico e un ulteriore server aggiunto per ridondanza (N + 1 scenario).

Proc Time Chart

Conoscenza acquisita dai dati nel grafico (processo (lsass) \ % tempo processore):

  • Il giorno di affari si avvia ramping intorno 07.00 e diminuisce a 17:0.

  • Il periodo più trafficato di picco è dalle 9:30 a 11:0. (Nota: tutti i dati sulle prestazioni è storico. Il punto di picco dei dati alle 09.15 indica il carico dalle 09.00 a 09.15).

  • Ci sono picchi prima 7:0 che potrebbe indicare sia carico da diversi fusi o attività dell'infrastruttura in background, ad esempio backup. Perché il picco a 9:30 supera questa attività, non è rilevante.

  • Ci sono 3 controller di dominio nel sito.

Al massimo carico, lsass consuma circa 485% 1 CPU, o 4,85 CPU in esecuzione al 100%. Secondo la matematica prima, questo significa che il sito ha bisogno di circa 12,25 CPU per Active Directory. Aggiungere i suggerimenti sopra riportati di 5-10% per i processi in background e che si intende sostituire il server oggi avrebbe bisogno di circa 12.30-12.35 CPU di supportare il carico stesso. Una stima dell'ambiente per la crescita ora deve essere scomposto.

JJ651019.collapse(it-it,WS.11).gif Quando ottimizzare pesi LDAP

Ci sono diversi scenari dove il tuning LdapSrvWeight dovrebbe essere considerato. Nell'ambito della pianificazione della capacità, questo avrebbe fatto quando l'applicazione o utente carichi non sono equilibrati uniformemente, o i sistemi sottostanti non sono equamente bilanciati in termini di capacità. Motivi di fuori della pianificazione della capacità sono di fuori della portata di questo articolo.

Mentre non tutti gli ambienti devono essere preoccupati, l'emulatore PDC è un esempio che colpisce ogni ambiente per l'utente o applicazione comportamento di caricamento non è uniformemente distribuita. Come certi strumenti e azioni target l'emulatore PDC, quali strumenti di gestione criteri di gruppo, secondo tentativi in caso di errori di autenticazione, istituzione di fiducia e così via, di risorse della CPU su emulatore PDC possono essere richieste più pesante rispetto altrove nel sito. Tuning LdapSrvWeight per ridurre il carico sull'emulatore PDC e aumentare il carico su altri controller di dominio permetterà una più uniforme distribuzione del carico. In questo caso, impostare LDAPSrvWeight tra 50 a 75 per l'emulatore PDC.

Esempio:

Utilizzo con impostazioni predefinite

Nuovo LdapSrvWeight

Stimato nuovo

Utilizzo della

DC1 (emulatore PDC)

53 %

57

40 %

DC2

33 %

100

40 %

DC3

33 %

100

40 %

La cattura è che se il ruolo di emulatore PDC è trasferito o sequestrato, particolarmente a un altro controller di dominio nel sito, ci sarà un aumento drammatico il nuovo emulatore PDC.

Utilizzando l'esempio della sezione Profilo comportamento del sito di destinazione, è stata fatta un'ipotesi che tutti i controller di dominio 3 nel sito avevano 4 CPU. Che cosa dovrebbe accadere, in condizioni normali, se uno dei controller di dominio ha avuto 8 CPU? Ci sarebbero due controller di dominio al 40% di utilizzo e una al 20% di utilizzo. Mentre questo non è male, c'è la possibilità di bilanciare il carico un po ' meglio. Questo potrebbe essere fatto sfruttando pesi LDAP. Sarebbe uno scenario di esempio:

Processore ( Total) \ % tempo processore

Utilizzo con impostazioni predefinite

Nuovo LdapSrvWeight

Utilizzo della nuova stima

4 CPU DC1

40

100

30 %

4 CPU DC2

40

100

30 %

8 CPU DC3

20

200

30 %

Essere molto attenti con questi scenari però. Come può essere visto sopra, la matematica sembra veramente bello e grazioso sulla carta. Ma tutto questo articolo, pianificazione per un "N + 1" scenario è di fondamentale importanza. L'impatto di una DC andando offline deve essere calcolato per ogni scenario. Nello scenario immediatamente precedente dove la distribuzione del carico è anche, al fine di garantire un 60% di carico durante uno scenario di "N", con il carico bilanciato in modo uniforme tra tutti i server, la distribuzione sarà bene come i rapporti di rimanere coerenti. Guardando l'emulatore PDC tuning scenario e in generale qualsiasi scenario dove carico utente o applicazione è sbilanciato, l'effetto è molto diverso:

Utilizzazione sintonizzati

Nuovo LdapSrvWeight

Stimato nuovo

Utilizzo della

DC1 (emulatore PDC)

40 %

85

47 %

DC2

40 %

100

53 %

DC3

40 %

100

53 %

JJ651019.collapse(it-it,WS.11).gif Considerazioni sulla virtualizzazione per l'elaborazione

Ci sono due livelli di pianificazione della capacità che devono essere fatte in un ambiente virtualizzato. A livello di host, simile per l'identificazione del ciclo di business delineato per il controller di dominio di elaborazione in precedenza, devono essere identificati soglie durante il periodo di picco. Perché l'entità sottostante sono le stesse per una macchina host programmazione thread ospite sulla CPU come per ottenere fili di AD DS sulla CPU su una macchina fisica, si applicano le stesse raccomandazioni per capacità di destinazione. Soglie di 40-60% sull'host sottostante sono raccomandate. Al livello successivo, lo strato di ospite, poiché i principi della pianificazione di thread non sono cambiati, la raccomandazione all'interno i resti di ospite nella gamma di 40-60%.

In uno scenario mappato diretto, un ospite per ospite, tutta la pianificazione della capacità fatto a questo punto deve essere aggiunto ai requisiti (RAM, disco, rete) del sistema operativo host sottostante. In uno scenario di host condivisi, test indica che non c'è 10% impatto sull'efficienza dei processori sottostanti. Ciò significa che se un sito ha bisogno di 10 CPU in un obiettivo del 40%, la quantità consigliata di CPU virtuali per allocare attraverso tutti gli ospiti di "N" sarebbe 11. In un sito con una distribuzione mista di server fisici e virtuali, il modificatore si applica solo per le macchine virtuali. Per esempio, se un sito ha un "N + 1" scenario, 1 server fisici o direct-mapped con 10 CPU sarebbe circa equivalente a 1 ospite con 11 CPU su un host, con 11 CPU riservata per il controller di dominio.

Durante l'analisi e il calcolo delle quantità di CPU necessarie per supportare il carico di AD DS, il numero di CPU che mappa di ciò che può essere acquistato in hardware fisico termini non necessariamente mappa in modo pulito. Virtualizzazione elimina la necessità di arrotondare. Virtualizzazione riduce lo sforzo necessario per aggiungere capacità di calcolo a un sito, data la facilità con cui una CPU può essere aggiunto a una macchina virtuale. Lo fa non eliminano la necessità di valutare con precisione la potenza di calcolo necessaria affinché l'hardware sottostante è disponibile quando ulteriori CPU devono essere aggiunti agli ospiti.

JJ651019.collapse(it-it,WS.11).gif Esempio di calcolo Sommario

Sistema

Picco CPU

Controller di dominio 1

120 %

Controller di dominio 2

147 %

Controller di dominio 3

218 %

Totale CPU utilizzato

485 %

Target sistemi di conteggio

Larghezza di banda totale (dall'alto)

CPU necessarie all'obiettivo del 40 %

4,85/4 = 12.25

Come sempre, ricordatevi di piano per la crescita. Supponendo che la crescita del 50% nei prossimi 3 anni, questo ambiente avrà bisogno 18,375 CPU (12,25 * 1.5) presso il marchio di tre anni. Un piano alternativo sarebbe quello di rivedere dopo il primo anno e aggiungere in capacità aggiuntiva come necessario.

JJ651019.collapse(it-it,WS.11).gif Carico di autenticazione del Client Cross-Trust per NTLM

Ci sono un certo numero di applicazioni che utilizzano il NTLM per impostazione predefinita, o utilizzarlo in un certo scenario di configurazione. Application Server crescere in capacità e un numero crescente di clienti attivi del servizio. C'è anche una tendenza che i clienti tenere sessioni aperte per un tempo limitato e riconnettersi piuttosto regolarmente (come la sincronizzazione di e-mail pull). Un altro esempio comune per carico elevato NTLM è server proxy web che richiedono l'autenticazione per l'accesso a Internet.

Queste applicazioni possono causare un carico significativo per l'autenticazione NTLM, che può mettere notevole stress sul controller di dominio, soprattutto quando gli utenti e le risorse sono in domini diversi.

Ci sono più approcci di gestione carico trasversale-fiducia, che in pratica sono utilizzati insieme, piuttosto che in un'esclusiva o / o scenario. Le opzioni possibili sono:

  • Ridurre l'autenticazione client cross-trust individuando i servizi che un utente consuma nello stesso dominio che l'utente sia residente in.

  • Aumentare il numero di secure-canali disponibili. Questo è pertinente al intraforest e al traffico tra foreste e sono conosciuti come trust di collegamento.

  • Regolare le impostazioni di default per MaxConcurrentAPI.

Per la sintonizzazione 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, vedere articolo KB 2688798: come fare l'ottimizzazione delle prestazioni per l'autenticazione NTLM utilizzando l'impostazione MaxConcurrentApi.

JJ651019.collapse(it-it,WS.11).gif Considerazioni sulla virtualizzazione

Nessuno, questo è un sistema operativo tuning impostazione.

JJ651019.collapse(it-it,WS.11).gif Esempio di calcolo Sommario

Tipo di dati

Valore

Semaforo acquisisce (minimo)

6.161

Semaforo acquisisce (massimo)

6.762

Timeout del semaforo

0

Tempo medio di attesa semaforo

0,012

Collezione durata (secondi)

01.11 minuti (71 secondi)

Formula (2688798 KB)

((6762-6161) + 0) * 0,012 /

Valore minimo per MaxConcurrentAPI

((6762-6161) + 0) * 0,012 / 71 =.101

Per questo sistema per questo periodo di tempo, i valori predefiniti sono accettabili.

In questo articolo, è stato discusso che pianificazione e scaling vanno verso gli obiettivi di utilizzo. Ecco un riepilogo grafico delle soglie consigliate che deve essere monitorato per assicurare che i sistemi sono operativi entro soglie di capacità adeguata. Tenere presente che questi non sono valori limite delle prestazioni, ma le soglie di pianificazione della capacità. Un server di funzionamento superiori a queste soglie funzioneranno, tuttavia è probabilmente il momento di iniziare a convalida che tutte le applicazioni sono ben educate. Se le applicazioni sono ben educate, ha detto, è il momento di iniziare a valutare gli aggiornamenti hardware o altre modifiche alla configurazione.

Categoria

Contatore di prestazioni

Intervallo/campionamento

Destinazione

Avviso

Processore

Processore ( Total) \ % tempo processore

60 min

40 %

60 %

RAM (Windows Server 2008 R2 o versione precedente)

Memoria\Mbyte MB

<100 MB

N/A

<100 MB

RAM (Windows Server 2012)

Memory\Long-termine medio Standby Cache Lifetime(s)

30 min

Deve essere testato

Deve essere testato

Rete

TCPv4\Connections stabilito

5 min/6 campioni consecutivi

60% della gamma consumato

80% della gamma consumato

Rete

Rete interfaccia () \Bytes inviati/sec

Rete interfaccia () \Bytes ricevuti/sec

30 min

40 %

60 %

Archiviazione

Disco logico (< unità del Database NTDS >) \Avg disco/sec

Disco logico (< unità del Database NTDS >) \Avg disco/sec

60 min

10 ms

15 ms

Annunci servizi

Tempo di attesa del semaforo \Average NETLOGON (*)

60 min

0

1 secondo

JJ651019.collapse(it-it,WS.11).gif Concetti importanti

JJ651019.collapse(it-it,WS.11).gif Definizioni

Processore (microprocessore) – un componente che legge ed esegue le istruzioni dei programmi

CPU -Central Processing Unit

Processore multi-core – CPU multiple sullo stesso circuito integrato

Multi-CPU -CPU multiple, non sullo stesso circuito integrato

Processore logico – un motore di calcolo logico dal punto di vista del sistema operativo. Questo include hyper-threading, un core di processore multi-core, o un processore single-core.

Come sistemi di server gli attuali dispongono di più processori, più processori multi-core e hyper-threading, questa informazione è generalizzata per coprire entrambi gli scenari. Come tale, verrà utilizzato il processore logico del termine come rappresenta il sistema operativo e prospettive di applicazione dei motori di calcolo disponibili.

JJ651019.collapse(it-it,WS.11).gif Parallelismo a livello di thread

Ogni thread è un'attività indipendente, come ogni thread ha il proprio stack e istruzioni. Perché AD DS è multi-threaded e il numero di thread disponibili può essere sintonizzato usando come visualizzare e impostare i criteri LDAP in Active Directory utilizzando Ntdsutil.exe, scala bene tra più processori logici.

JJ651019.collapse(it-it,WS.11).gif Parallelismo a livello di dati

Questo comporta la condivisione dei dati tra più thread all'interno di un processo (nel caso il processo di Active Directory da solo) e tra più thread in più processi (in generale). Con la preoccupazione per il caso di semplicismo, ciò significa che eventuali modifiche apportate ai dati vengono riflesse in tutti i thread in esecuzione in tutti i vari livelli di cache (L1, L2, L3) attraverso tutti i core in esecuzione ha detto thread così come l'aggiornamento di memoria condivisa. Prestazioni possono degradare durante le operazioni di scrittura, mentre tutte le varie locazioni di memoria sono portati coerente prima elaborazione di istruzioni può continuare.

JJ651019.collapse(it-it,WS.11).gif Velocità CPU vs. Considerazioni di Multi-Core

La regola generale è più veloce processori logici riducono la durata, impiegato per elaborare una serie di istruzioni, mentre mezzi di processori più logici che è possibile eseguire più attività contemporaneamente. Queste regole pratiche abbattere come gli scenari diventano intrinsecamente più complessi con le considerazioni di recupero di dati dalla memoria condivisa, in attesa sul parallelismo a livello di dati e l'overhead di gestione di più thread. Questo è anche perché la scalabilità in sistemi multi-core non è lineare.

Considerare le seguenti analogie in queste considerazioni: pensate a una strada, con ogni thread essendo un'auto individuale, ogni corsia essendo un core e il limite di velocità è la velocità di clock.

  1. Se c'è solo una macchina sull'autostrada, non importa se ci sono due corsie o 12 corsie. Auto che si sta solo per andare veloce come il limite di velocità vi permetterà.

  2. Si supponga che i dati che il thread ha bisogno siano non immediatamente disponibili. L'analogia sarebbe che un segmento di strada viene arrestato. Se c'è solo una macchina sull'autostrada, non importa quello che è il limite di velocità fino a quando non viene riaperta la corsia (i dati vengono recuperati dalla memoria).

  3. Come aumenta il numero delle autovetture, l'overhead per gestire il numero di automobili aumenta. Confrontare l'esperienza di guida e la quantità di attenzione necessaria quando la strada è praticamente vuoto (ad esempio come tarda sera) rispetto a quando il traffico è pesante (ad esempio a metà pomeriggio, ma ora non di punta). Inoltre, considerare la quantità di attenzione necessari quando si guida su una strada a due corsie, dove c'è un solo altro lane a preoccuparsi di che cosa stanno facendo i driver, contro un 6 corsie dove si deve preoccupare di ciò che un sacco di altri piloti stanno facendo.

    JJ651019.note(it-it,WS.11).gif Nota
    L'analogia sullo scenario rush hour è esteso nella sezione successiva: Risposta Time/How la frenesia degli impatti prestazioni del sistema.

Di conseguenza, specifiche su processori più veloci o più diventano altamente soggettive al comportamento dell'applicazione, che nel caso di AD DS è molto l'ambiente specifico e anche varia da server a server all'interno di un ambiente. Ecco perché i riferimenti precedentemente in questo articolo non investono pesantemente nell'essere troppo precisi, e un margine di sicurezza è incluso nei calcoli. Decisioni basate su budget d'acquisto, è consigliabile che ottimizzare l'utilizzo dei processori al 40% (o il numero desiderato per l'ambiente) avviene in primo luogo, prima di considerare l'acquisto di processori più veloci. La maggiore sincronizzazione tra più processori riduce il vero beneficio di più processori dalla progressione lineare (2 x il numero di processori fornisce meno di 2 x disponibili ulteriori calcolare potenza).

JJ651019.note(it-it,WS.11).gif Nota
Legge di Amdahl e legge di Gustafson sono rilevanti concetti qui.

JJ651019.collapse(it-it,WS.11).gif Tempo di risposta/come le prestazioni di sistema Busyness impatti

Accodamento teoria è lo studio matematico delle linee di attesa (code). ). In teoria accodamento, il diritto di utilizzazione è rappresentato dall'equazione:

U k = B/T

Dove Uk è la percentuale di utilizzo, B è la quantità di tempo occupato, e T è il tempo totale che del sistema è stato osservato. Tradotto in contesto di Windows, questo significa il numero di 100 nanosecondi (ns) thread intervallo che sono in uno stato di esecuzione diviso 100 quanti intervalli ns erano disponibili nel dato intervallo di tempo. Questa è esattamente la formula per il calcolo della % tempo processore (riferimento Oggetto processore e PERF_100NSEC_TIMER_INV).

Accodamento teoria fornisce anche la formula: N = Uk/1-Uk per stimare il numero di elementi d'attesa basato sull'utilizzazione (N è la lunghezza della coda). Grafici questo sopra tutti gli intervalli di utilizzo fornisce le seguenti stime per quanto tempo la coda per ottenere il processore è a qualsiasi dato carico di CPU.

Queue Length

È stato osservato che dopo 50% carico della CPU, in media c'è sempre un'attesa di 1 altro elemento nella coda, con una rapida notevolmente aumentare dopo circa il 70% di utilizzo della CPU.

Tornando all'analogia guida usato in precedenza in questa sezione:

  • Le volte occupati di "pomeriggio", ipoteticamente, cadrebbe da qualche parte nella gamma di 40-70%. Non c'è abbastanza traffico tale che la capacità di scegliere qualsiasi corsia non è majorly limitata, e la possibilità di un altro conducente sia nel modo, mentre alta, non richiedono il livello di sforzo per "trovare" un sicuro divario tra altre vetture su strada.

  • Si noterà che il traffico si avvicina ora di punta, il sistema della strada si avvicina 100% della capacità. Ipotesi di reato può diventare molto impegnativo perché le automobili sono così vicine insieme che maggiore attenzione deve essere esercitata per farlo.

Questo è il motivo delle medie di lungo termine per capacità sono prudenzialmente stimate al 40%. Questo permette per la testa di stanza per i picchi anomali a carico, se detto picchi transitori (ad esempio le query mal codificate eseguite per pochi minuti) o anormale scoppia in generale carico (la mattina del primo giorno dopo un lungo week-end).

La dichiarazione di cui sopra riguarda il calcolo di tempo processore % essendo lo stesso il diritto di utilizzazione è un po ' di una semplificazione per la facilità del lettore. Per quelli più matematicamente rigoroso:

  • Tradurre PERF_100NSEC_TIMER_INV

    • B = il numero di 100 intervalli di ns "Idle" thread passa sul processore logico. Il cambiamento nella variabile "X" nel calcolo PERF_100NSEC_TIMER_INV

    • T = numero totale di 100 ns intervalli in un intervallo di tempo specificato. Il cambiamento di variabile nel calcolo PERF_100NSEC_TIMER_INV "Y".

    • U k = la percentuale di utilizzo del processore logico "Idle Thread" o % tempo di inattività.

  • Lavorando fuori la matematica:

    • U k = 1- % tempo processore

    • % Tempo processore = 1 - Uk

    • % Tempo processore = 1 - B/T

    • % Tempo processore = 1 –1 X – X 0/Y0-Y1

JJ651019.collapse(it-it,WS.11).gif Applicare i concetti di pianificazione della capacità

La matematica precedente può rendere determinazioni circa il numero di processori logici necessari in un sistema sembrano straordinariamente complesse. È per questo motivo l'approccio al dimensionamento dei sistemi è focalizzata sulla determinazione di utilizzazione massima destinazione basato su corrente carico e calcolando il numero di processori logici necessari per arrivarci. Inoltre, mentre, velocità del processore logico avrà un impatto significativo sulle prestazioni, efficienza della cache, requisiti di memoria di coerenza, thread scheduling e sincronizzazione e client imperfettamente equilibrato carico tutti avrà impatti significativi sulla performance che varia su base server dal server. Con il costo relativamente a buon mercato della potenza di calcolo, cercando di analizzare e determinare il numero perfetto di CPU necessarie diventa più un esercizio accademico che fornisce valore aziendale.

40% non è un requisito duro e veloce, ma è consigliato come punto di partenza ragionevole. Diversi consumatori di Active Directory richiedono vari livelli di reattività. Ci possono essere gli scenari dove ambienti possono essere eseguito presso l'utilizzo 80% o 90% come media sostenuta, come i tempi di attesa maggiori per l'accesso al processore non influenzeranno notevolmente le prestazioni del client. È importante ribadire che ci sono molte aree del sistema che sono molto più lento rispetto i processori logici nel sistema, incluso l'accesso alla RAM, l'accesso al disco e trasmettere la risposta attraverso la rete. Tutti questi elementi devono essere sintonizzati in congiunzione. Esempi:

  • Aggiunta di più processori in un sistema che esegue il 90% che è associato a disco probabilmente non sta andando a migliorare significativamente le prestazioni. Un'analisi più approfondita del sistema identificherà probabilmente che ci sono un sacco di discussioni che non sono nemmeno sempre sul processore perché sono in attesa su IO per completare.

  • Risolvere i problemi associati a disco significa che thread che in precedenza erano spendere un sacco di tempo in stato di attesa non sarà più essere potenzialmente in stato di attesa per IO e non ci sarà più concorrenza per tempo di CPU, significa che il 90% di utilizzo nell'esempio precedente andrà al 100%. Entrambi i componenti devono essere sintonizzati in congiunzione.

Discutendo considerazioni utilizzo intero sistema porta anche nei controller di dominio di conversazione come virtualizzati. Risposta Time/How il sistema Busyness impatti Performance si applica sia l'ospite e l'ospite in un scenario virtualizzato. Questo è il motivo in un host con un solo ospite, dispone di un controller di dominio (e in generale qualsiasi sistema) vicino alle stesse prestazioni che fa su hardware fisico. Aggiungendo gli ospiti supplementari per i padroni di casa aumenta l'utilizzazione dell'host sottostante, aumentando così i tempi di attesa per ottenere l'accesso ai processori come spiegato in precedenza. In breve, l'utilizzo del processore logico deve essere gestito sia sull'host e ai livelli di ospite.

Estendendo le analogie precedente, lasciando l'autostrada come l'hardware fisico, l'ospite VM sarà paragonato con un autobus (un autobus espresso che va dritto a destinazione il pilota vuole). Immaginate i seguenti quattro scenari:

  • È spento ore, ottiene un pilota su un autobus che è quasi vuoto, e ottiene l'autobus su una strada che è quasi vuota. Come non non c'è nessun traffico a contendere con, il pilota ha un bel giro facile e si ottiene solo come veloce come se il pilota aveva guidato invece. Tempi di percorrenza del pilota sono ancora vincolati dal limite di velocità.

  • È spento ore così il bus è quasi vuoto, ma la maggior parte dei vicoli sulla strada sono chiusi, quindi l'autostrada è ancora congestionato. Il pilota è su un autobus quasi vuoto su una strada congestionata. Mentre il pilota non hanno un sacco di concorrenza nel bus per dove sedervi, il tempo di viaggio totale ancora è dettato dal resto del traffico all'esterno.

  • È ora di punta così l'autostrada e il bus sono congestionati. Non solo il viaggio impiega più tempo, ma sempre su e scendere dall'autobus è un incubo, perché le persone sono spalla a spalla e l'autostrada non è molto meglio. Aggiungendo più autobus (processori logici per l'ospite) non significa che può adattarsi sulla strada a qualsiasi più facilmente, o che il viaggio sarà ridotta.

  • Lo scenario finale, anche se esso può essere stretching l'analogia un po', è dove il bus è pieno, ma la strada non è congestionato. Mentre il pilota avrà ancora la difficoltà a raggiungere e spegnere il bus, il viaggio sarà efficace dopo il bus è sulla strada. Questo è lo scenario dove aggiungendo più autobus (processori logici per l'ospite) migliorerà le prestazioni del guest.

Da lì dovrebbe essere relativamente facile estrapolare che ci sono un certo numero di scenari tra il 0% utilizzato e il 100% impiegati dello stato della strada e il 0% e 100% utilizzato stato del bus che hanno diversi gradi di impatto.

Applicando i principi di sopra del 40% CPU come obiettivo ragionevole per l'host, come pure l'ospite è un inizio ragionevole per lo stesso ragionamento come sopra, la quantità di Accodamento messaggi.

In tutto le sezioni su selezione processore assunzione fatta che il processore è in esecuzione al 100% della velocità di clock dei dati viene raccolto tutto il tempo e che i sistemi di sostituzione avrà lo stessa processori veloci. Nonostante entrambi presupposti in pratica essere false, specialmente con Windows Server 2008 R2 e versioni successive, dove il piano di alimentazione predefinito è equilibrata, la metodologia si trova ancora. Mentre il tasso di errore potenziale può aumentare, aumenta solo il margine di sicurezza come aumento di velocità del processore.

Ad esempio, in uno scenario dove sono richiesti 11,25 CPU, se i processori erano in esecuzione a metà velocità quando i dati sono stati raccolti, la stima più accurata potrebbe essere 5,125/2. Detto questo, è impossibile garantire che raddoppiando la velocità di clock sarebbe il doppio della quantità di elaborazione che accade per un determinato periodo di tempo. Questo è dovuto al fatto la quantità di tempo che i processori spendono in attesa su RAM o altri componenti del sistema potrebbero rimanere lo stesso. L'effetto netto è che i più veloci processori potrebbero spendere una percentuale maggiore del tempo inattivo in attesa sui dati di essere recuperato. Pertanto, si consiglia di attaccare con il minimo comune denominatore ed evitare cercando di calcolare un livello di accuratezza potenzialmente falso assumendo un lineare confronto tra velocità del processore.

D'altra parte, se la velocità del processore in hardware in sostituzione sono inferiori a hardware corrente, sarebbe sicuro aumentare la stima di processori necessari per un importo proporzionato. Ad esempio, si calcola che 10 processori sono necessari per sostenere il carico in un sito e gli attuali processori sono in esecuzione a 3,3 Ghz e processori di sostituzione verranno eseguito a 2,6 Ghz, questo è un calo del 21% in velocità. In questo caso, 12 processori sarebbe la quantità consigliata.

Detto questo, questa variabilità non cambierebbe le destinazioni di utilizzo processore Capacity Management. Come clock processore velocità verrà regolata in modo dinamico basato sul carico richiesto, in esecuzione che il sistema sotto carichi superiori genererà uno scenario dove la CPU passa più tempo in uno stato di velocità di clock superiore, rendendo l'obiettivo finale di essere al 40% di utilizzo in uno stato di velocità di clock di 100% al picco. Niente meno che genera risparmio energetico come velocità di CPU sarà strozzato indietro durante fuori scenari di picco.

JJ651019.note(it-it,WS.11).gif Nota
Un'opzione sarebbe per disattivare la gestione della potenza sui processori (impostando il piano di alimentazione Ad alte prestazioni) mentre dati viene raccolta. Che vuoi dare una rappresentazione più accurata del consumo CPU sul server di destinazione.

I concetti di teoria Accodamento delineati nella Risposta Time/How la frenesia degli impatti prestazioni del sistema sono inoltre applicabili all'archiviazione. Avendo una familiarità di come sia necessario applicare questi concetti l'handle del sistema operativo I/O. Nel sistema operativo Microsoft Windows, viene creata una coda per contenere le richieste dei / o per ogni disco fisico. Tuttavia, un chiarimento sul disco fisico deve essere fatto. Controller di array e SANs presenti aggregazioni di mandrini per il sistema operativo come singoli dischi fisici. Inoltre, Controller array e SANs possono aggregare più dischi in una matrice insieme e poi dividere questa matrice impostato in più "partizioni", che è a sua volta presentato al sistema operativo come più dischi fisici (Rif. nella figura).

Block Spindles In questa figura i due mandrini sono specchio e suddiviso in aree logiche per la memorizzazione dei dati (dati 1 e 2 di dati). Queste aree logiche sono visti dal sistema operativo come dischi fisici distinti.

Anche se questo può essere molto confuso, la seguente terminologia è utilizzata in tutta questa appendice per identificare le diverse entità:

  • Mandrino – il dispositivo che è fisicamente installato nel server.

  • Matrice – una collezione di fuselli aggregati dal controllore.

  • Partizione di matrice – un partizionamento della matrice aggregata

  • LUN – matrice, utilizzato quando rinvio a SANs

  • Disco – che il sistema operativo rileva di essere un singolo disco fisico.

  • Partizione – un partizionamento logico di ciò che percepisce il sistema operativo come un disco fisico.

JJ651019.collapse(it-it,WS.11).gif Considerazioni di architettura del sistema operativo

Il sistema operativo crea una coda di primo In/First Out (FIFO) I/O per ogni disco che è osservato;Questo disco può rappresentare un mandrino, una matrice o una partizione di matrice. Dal punto di vista del sistema operativo, per quanto riguarda la gestione dei / o, la più attiva code meglio. Come una coda FIFO è serializzata, significa che tutti gli / o rilasciati per il sottosistema di archiviazione deve essere elaborato nell'ordine la richiesta è arrivato. Correlando ogni disco osservato dal sistema operativo con un mandrino/matrice, il sistema operativo mantiene ora una coda I/O per ogni set unico di dischi, quindi eliminando la contesa per la scarsità di risorse I/O su dischi e isolando la domanda I/O di un singolo disco. Come eccezione, Windows Server 2008 introduce il concetto di priorità IO, e le applicazioni progettate per utilizzare la priorità di "Bassa" cadono fuori questo ordine normale e prendono un sedile posteriore. Applicazioni non specificamente codificate per sfruttare il predefinito di priorità "Basso" a "Normale".

JJ651019.collapse(it-it,WS.11).gif L'introduzione di sottosistemi di archiviazione semplice

A partire con un semplice esempio (un singolo disco rigido all'interno di un computer) saranno dato un analisi di componenti. Questa scomposizione nei componenti di sottosistema di archiviazione maggiore, il sistema consiste di:

  1. 1 – HD SCSI Ultra veloce 10.000 RPM (Ultra Fast SCSI ha un tasso di trasferimento 20 MB/s)

  2. 1 – SCSI Bus (cavo)

  3. 1 – Ultra Fast SCSI Adapter

  4. 1 – 32 bit 33 MHz PCI bus

Una volta che i componenti sono identificati, un'idea di quanti dati possono transitare il sistema, o quanto I/O può essere gestito, può essere calcolata. Si noti che la quantità dei / o e la quantità di dati che possono transitare il sistema è correlati, ma non è la stessa. Questa correlazione dipende se il disco i/o è sequenziale o casuale e la dimensione del blocco. (Tutti i dati vengono scritti sul disco come un blocco, ma diverse applicazioni utilizzando diversi bloccano formati). Su una base di componenti:

  • Il disco rigido – la media 10.000 RPM hard disk ha un 7 millisecondi (ms) cercano il tempo e un tempo di accesso di 3 ms. Cercare il tempo è la quantità media di tempo che impiega la testina di lettura/scrittura per spostare in una posizione sul piatto. Tempo di accesso è la quantità media di tempo per leggere o scrivere i dati su disco, una volta che la testa è in posizione corretta. Così, il tempo medio per la lettura di un unico blocco di dati in un HD 10.000 RPM costituisce una ricerca e un accesso, per un totale di circa 10 ms (o.010 secondi) per ogni blocco di dati.

    Quando ogni accesso al disco richiede un movimento della testa in una nuova posizione sul disco, il comportamento di lettura/scrittura è indicato come "casuale". Così, quando tutti gli / o è casuale, un HD 10.000 RPM può gestire circa 100/o per secondo (IOPS) (la formula è 1000 ms al secondo diviso per 10 ms per i/o o 1000/10 = 100 IOPS).

    In alternativa, quando si verifica i/o da settori adiacenti sul HD, questo è definito come i/o sequenziale. I/O sequenziale non ha tempo di seek, perché quando il / o prima è completa, la testina di lettura/scrittura è all'inizio di dove il successivo blocco di dati viene memorizzato su HD. Così un 10.000 RPM HD è in grado di gestire circa 333/o per secondo (1000 ms al secondo diviso per 3 ms al I/O).

    JJ651019.note(it-it,WS.11).gif Nota
    In questo esempio non riflette la cache del disco, dove i dati di un cilindro sono in genere mantenuti. In questo caso, la sig. ra 10 è necessari sul primo IO e il disco legge l'intero cilindro. Tutti gli altri IO sequenza è soddisfatta dalla cache. Di conseguenza, nel disco cache potrebbero migliorare le prestazioni sequenziali IO.

    Finora, il tasso di trasferimento del disco rigido è stato irrilevante. Se il disco rigido è di 20 MB/s Ultra Wide o un Ultra3 160 MB/s, la quantità effettiva di IOPS il può essere gestito da 10.000 RPM HD è ~ 100 casuale o i/o sequenziale di ~ 300. Come modificare dimensioni blocco basato sull'applicazione di scrittura sul disco, la quantità di dati che viene tirati a I/O è diversa. Ad esempio, se la dimensione del blocco è di 8 KB, 100 operazioni dei / o saranno leggere o scrivere sul disco rigido un totale di 800 KB. Tuttavia, se la dimensione del blocco è di 32 KB, 100 I/O sarà lettura/scrittura 3.200 KB (3,2 MB) per il disco rigido. Fintanto che la velocità di trasferimento SCSI è superiore all'ammontare totale dei dati trasferiti, ottenendo un trasferimento "più veloce" auto tasso guadagnerà nulla. Vedere le seguenti tabelle per il confronto.

    7200 RPM

    cercare 9ms, 4ms accesso

    10.000 RPM

    cercare di 7ms, 3ms accesso

    15.000 RPM

    cercano di 4 ms, 2 ms access

    / O casuale

    80

    100

    150

    / O sequenziale

    250

    300

    500

    Unità da 10.000 RPM

    Dimensione del blocco di 8 KB (Jet Active Directory)

    / O casuale

    800 KB/s

    / O sequenziale

    2400 KB/s

  • Comprendere come il "Backplane SCSI (bus)", o in questo scenario il cavo a nastro, velocità effettiva degli impatti del sottosistema di archiviazione dipende dalla conoscenza della dimensione del blocco. Essenzialmente la questione sarebbe, quanto I/O può la maniglia dell'autobus se il / o è in blocchi di 8 KB? In questo scenario, il bus SCSI è 20 MB/s, o 20480 KB/s. 20480 KB/s diviso in blocchi di 8 KB produce un massimo di circa 2500 IOPS supportato da bus SCSI.

    JJ651019.note(it-it,WS.11).gif Nota
    Le cifre nella tabella riportata di seguito rappresentano un esempio. Più periferiche di archiviazione collegate attualmente usano PCI Express, che fornisce una velocità molto superiore.

    I/O supportato da bus SCSI per dimensione del blocco

    Dimensione del blocco 2 KB

    Dimensione del blocco di 8 KB

    (Annuncio Jet)

    (SQL 7.0/2000)

    20 MB/s

    10.000

    2.500

    40 MB/s

    20.000

    5.000

    128 MB/s

    65.536

    16.384

    320 MB/s

    160.000

    40.000

    Come può essere determinata da questo grafico, nello scenario presentato, non importa ciò che l'uso, il bus non sarà mai un collo di bottiglia, come il mandrino massimo è 100 i/o, ben di sotto di qualsiasi delle soglie di cui sopra.

    JJ651019.note(it-it,WS.11).gif Nota
    Questo presuppone che il bus SCSI è efficiente al 100%.

    Adattatore SCSI – per determinare la quantità dei / o che si può gestire, le specifiche del costruttore devono essere controllato. Indirizzare richieste dei / o per il dispositivo appropriato richiede un'elaborazione di qualche tipo, quindi la quantità dei / o che possono essere gestiti dipende l'adattatore SCSI (o controller dell'array) processore.

    In questo esempio, il presupposto che può I/O 1.000 trattati sarà reso.

  • Bus PCI – questo è un componente spesso sottovalutato. In questo esempio, questo non sarà il collo di bottiglia;Tuttavia come sistemi di scalabilità verticale, può diventare un collo di bottiglia. Per riferimento, un 32 bit PCI bus operante a can 33 Mhz in teoria trasferimento 133 MB/s di dati. Di seguito è riportato l'equazione: 32 bit/8 bit per byte * 33 MHz = 133 MB/s. Si noti che è il limite teorico;in realtà solo circa il 50% del massimo è raggiunto in realtà, anche se in determinati scenari di burst, 75% di efficienza può essere ottenuto per brevi periodi.

  • Un bus di 66 Mhz 64 bit PCI può supportare un massimo teorico di (64 bit/8 bit per byte * 66 Mhz =) 528 MB/sec. Inoltre, qualsiasi altro dispositivo (ad esempio la scheda di rete, secondo controller SCSI e così via) ridurrà la larghezza di banda disponibile, come la larghezza di banda è condivisa e i dispositivi si contenderanno le limitate risorse.

Dopo l'analisi delle componenti di questo sottosistema di archiviazione, il mandrino è il fattore limitante nella quantità dei / o che può essere richiesta e di conseguenza la quantità di dati che possono transitare il sistema. In particolare, in uno scenario di AD DS, questo è il 100/o casuale per secondo con incrementi di 8 KB, per un totale di 800 KB al secondo quando l'accesso al database Jet. In alternativa, la velocità effettiva massima per un mandrino che viene allocato esclusivamente per i file di registro subirebbe le seguenti limitazioni: 300/o sequenziale per secondo con incrementi di 8 KB, per un totale di 2400 KB (2.4 MB) al secondo.

Ora, dopo aver analizzato una configurazione semplice, di seguito viene illustrato dove il collo di bottiglia si verificherà come componenti del sottosistema di archiviazione sono modificati o aggiunte.

Note

ANALISI DI COLLO DI BOTTIGLIA

Disco

Autobus

Adattatore

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 a 800 KB/s.

Aggiungere 1 disco (totale = 2)

I/o è casuale

Dimensione del blocco di 4 KB

10.000 RPM HD

200/O totale. 800 Totale KB/s.

Dopo l'aggiunta di 7 dischi, la configurazione del disco rappresenta ancora il collo di bottiglia a 3200 KB/s.

Aggiungere 7 dischi (totale = 8)

I/o è casuale

Dimensione del blocco di 4 KB

10.000 RPM HD

800/O totale. Totale di 3200 KB/s

Dopo aver cambiato I/O a sequenziale, la scheda di rete diventa il collo di bottiglia perché si è limitata a 1000 IOPS.

Aggiungere 7 dischi (totale = 8)

I/o è sequenziale

Dimensione del blocco di 4 KB

10.000 RPM HD

2400 I/O sec possono essere letti/scritti su disco, limitata a 1000 IOPS controller

Dopo la sostituzione della scheda di rete con un adattatore SCSI che supporta 10.000 IOPS, il collo di bottiglia restituisce la configurazione del disco.

Aggiungere 7 dischi (totale = 8)

/ O casuale

Dimensione del blocco di 4 KB

10.000 RPM HD

Aggiornamento scheda SCSI (ora supporta 10.000 i/o)

800/O totale. Totale di 3.200 KB/s

Dopo aumentando la dimensione del blocco di 32 KB, il bus diventa il collo di bottiglia, perché supporta solo 20 MB/s.

Aggiungere 7 dischi (totale = 8)

/ O casuale

Dimensione del blocco di 32 KB

10.000 RPM HD

800/O totale. 25.600 KB/s (25 MB/s) possono essere letti/scritti su disco.

Il bus supporta solo 20 MB/s

Dopo l'aggiornamento il bus e l'aggiunta di più dischi, il disco rimane il collo di bottiglia.

Aggiungere 13 dischi (totale = 14)

Aggiungere 2 dischi di w/14 adattatore SCSInd

/ O casuale

Dimensione del blocco di 4 KB

10.000 RPM HD

Aggiornamento al bus SCSI MB/s 320

2800 I/o

11.200 KB/s (10,9 Mb/s)

Dopo aver cambiato I/O a sequenziale, il disco rimane il collo di bottiglia.

Aggiungere 13 dischi (totale = 14)

Aggiungere 2 dischi di w/14 adattatore SCSInd

/ O sequenziale

Dimensione del blocco di 4 KB

10.000 RPM HD

Aggiornamento al bus SCSI MB/s 320

/ 8.400 o

33.600 KB\s

(32,8 MB\s)

Dopo l'aggiunta di più veloce hard disk, il disco rimane il collo di bottiglia.

Aggiungere 13 dischi (totale = 14)

Aggiungere 2 dischi di w/14 adattatore SCSInd

/ O sequenziale

Dimensione del blocco di 4 KB

15.000 RPM HD

Aggiornamento al bus SCSI MB/s 320

/ 14.000 o

56.000 KB/s

(54,7 MB/s)

Dopo aumentando la dimensione del blocco di 32 KB, il bus PCI diventa il collo di bottiglia.

Aggiungere 13 dischi (totale = 14)

Aggiungere 2 dischi di w/14 adattatore SCSInd

/ O sequenziale

Dimensione del blocco di 32 KB

15.000 RPM HD

Aggiornamento al bus SCSI MB/s 320

/ 14.000 o

448.000 KB/s

(437 MB/s) è il limite di lettura/scrittura del mandrino.

Il bus PCI supporta un massimo teorico di 133 MB/s (75% efficiente al meglio).

JJ651019.collapse(it-it,WS.11).gif L'introduzione di RAID

La natura di un sottosistema di archiviazione non cambia drasticamente quando un controller di array è stato introdotto;esso sostituisce solo l'adattatore SCSI nei calcoli. Quello che cambia è il costo di lettura e scrittura dei dati sul disco quando si utilizzano i vari livelli di matrice (ad esempio RAID 0, RAID 1 o RAID 5).

In RAID 0, i dati sono striati attraverso tutti i dischi in RAID set. Questo significa che durante una lettura o un'operazione di scrittura, una parte dei dati è tirata da o spinto per ogni disco, aumentando la quantità di dati che possono transitare il sistema durante lo stesso periodo di tempo. Così, in un secondo, su ogni asse (assumendo nuovamente unità 10.000 RPM), 100 operazioni dei / o possono essere eseguite. La quantità totale dei / o che può essere supportato è mandrini N volte 100/o per secondo al mandrino (rendimenti 100 N i/o al secondo).

Logical Drives

In RAID 1, i dati si specchia (duplicati) attraverso una coppia di assi per la ridondanza. Così, quando viene eseguita una lettura operazioni dei / o, i dati possono essere letti da entrambi i mandrini nel set. Questo effettivamente rende la capacità di I/O da entrambi i dischi disponibili durante un'operazione di lettura. L'avvertimento è che non scrivere le operazioni guadagno alcun vantaggio di prestazioni in un RAID 1. Questo è perché gli stessi dati devono essere scritto in entrambi i dischi per motivi di ridondanza. Anche se non prende affatto più lungamente, come la scrittura dei dati avviene simultaneamente su due assi, perché entrambi fusi sono occupati a duplicare i dati, operazioni dei / o una scrittura in sostanza impedisce 2 operazioni di lettura che si verifichi. Così, i costi di I/O ogni scrittura 2 leggere I/O. Una formula può essere creata da tali informazioni per determinare il numero totale di operazioni dei / o che si stanno verificando: lettura i/o + 2 * scrivere i = totale disponibile disco i file-Secure /. o consumato. Quando il rapporto di letture a scrive e il numero di assi sono noti, la seguente equazione può essere derivata dall'equazione qui sopra per identificare il / o massimo che può essere sostenuta da matrice: massimo IOPS per mandrino * 2 mandrini * [(% lettura + % scrive) / (% letture + 2 * % scrive)] = totale IOPS.

RAID 1++ 0, si comporta esattamente come RAID 1 per quanto riguarda le spese di lettura e scrittura. Tuttavia, il / o è ora striato attraverso ogni set con mirroring. Se massimo IOPS per mandrino * 2 mandrini * [(% lettura + % scrive) / (% letture + 2 * % scrive)] = i/o totale in una serie di RAID 1, quando diventa una molteplicità (N) di RAID 1 set sono a strisce, il / o totale che può essere elaborato N * / o per set RAID 1: N * {massimo IOPS per mandrino * 2 mandrini * [(% lettura + % scrive) / (% letture + 2 * % scrive)]} = totale IOPS

In RAID 5, a volte indicato come N + 1 RAID, i dati sono striati attraverso N mandrini e informazioni di parità sono scritto al mandrino "+ 1". Tuttavia, il RAID 5 è molto più costoso quando si esegue una scrittura i/o RAID 1 o 1++ 0. RAID 5 esegue il seguente processo ogni volta che una scrittura i/o è sottoposto a matrice:

  1. Leggere i vecchi dati

  2. Leggere la vecchia parità

  3. Scrivere i nuovi dati

  4. Scrivere la nuova parità

Ogni richiesta dei / o di scrittura che viene inviato al controller dell'array con il sistema operativo richiede 4 operazioni dei / o per completare, scrivere le richieste presentate prendono 4 volte più a lungo per completare come un singolo letto I/O. Per ricavare una formula per tradurre le richieste dei / o dal punto di vista sistema operativo a quello sperimentato da mandrini: lettura i/o + 4 * scrivere i = i/o totale. Similmente in una serie di RAID 1, quando il rapporto di letture a scrive e il numero di assi sono noti, la seguente equazione può essere derivata dall'equazione di cui sopra per identificare il / o massimo che può essere supportato dalla matrice (nota che il numero totale di mandrini non include il "unità" ha perduto a parità): IOPS per mandrino * (mandrini – 1) * [(% lettura + % scrive) / (% letture + 4 * % scrive)] = totale IOPS

JJ651019.collapse(it-it,WS.11).gif L'introduzione di SANs

Espandendo la complessità del sottosistema di archiviazione, quando una SAN è stato introdotto nell'ambiente, non cambiano i principi delineati, tuttavia il comportamento I/O per tutti i sistemi collegati a SAN deve essere preso in considerazione. Come uno dei principali vantaggi nell'utilizzo di una SAN è un importo supplementare di ridondanza su storage collegati internamente o esternamente, pianificazione della capacità deve ora tener conto delle esigenze fault tolerance. Inoltre, vengono introdotte ulteriori componenti che devono essere valutati. Abbattere una SAN nelle parti componenti:

  1. Disco rigido SCSI o Fibre Channel

  2. Archiviazione unità canale backplane

  3. Unità di storage

  4. Modulo controller di archiviazione

  5. Tatori di SAN

  6. HBA

  7. Il bus PCI

Durante la progettazione di qualsiasi sistema per la ridondanza, componenti aggiuntivi sono inclusi per accogliere il potenziale di guasto. È molto importante, quando capacity planning, per escludere la componente ridondante da risorse disponibili . Ad esempio, se il SAN ha due moduli controller, la capacità di I/O del modulo un controller è tutto ciò che deve essere utilizzato per la velocità effettiva di I/O totale disponibile per il sistema. Questo è dovuto al fatto che se un controller non riesce, l'intero carico dei / o richiesto da tutti i sistemi connessi dovranno essere elaborati dal controller rimanente. Come tutte le capacità di pianificazione è fatto per i periodi di maggiore utilizzo, componenti ridondanti non dovrebbero essere presi in considerazione nelle risorse disponibili e l'utilizzo di picco previsto non deve superare 80% di saturazione del sistema (al fine di ospitare scoppi o comportamento anomalo del sistema). Analogamente, l'interruttore SAN ridondanti, unità di memorizzazione e mandrini non dovrebbero essere scomposto nei calcoli I/O.

Analizzando il comportamento di SCSI o Fibre Channel Hard disk, il metodo di analizzare il comportamento come indicato in precedenza non cambia. Anche se ci sono alcuni vantaggi e svantaggi di ogni protocollo, il fattore limitante in base al disco è la limitazione meccanica del disco rigido.

Analizzando il canale sull'unità di archiviazione è esattamente lo stesso come calcolare le risorse disponibili sul bus SCSI o larghezza di banda (ad esempio 20 MB/s) diviso per la dimensione del blocco (ad esempio 8 KB). Dove questo si discosta dalla semplice esempio precedente è l'aggregazione di più canali. Ad esempio, se ci sono 6 canali, ognuno supporta velocità di trasferimento massima di 20 MB/s, l'importo totale del trasferimento dei dati e i/o, che è disponibile è 100 MB/s (questo è corretto, è non 120 MB/s). Ancora una volta, fault tolerance è un giocatore importante in questo calcolo, in caso di perdita di un intero canale, il sistema è solo a sinistra con 5 canali funzionanti. Così, per garantire la continua a soddisfare le aspettative di prestazioni in caso di guasto, throughput totale per tutti i canali di stoccaggio non deve superare 100 MB/s (ciò presuppone carico e fault tolerance è distribuito uniformemente in tutti i canali). Trasformare questo in un profilo I/O dipende il comportamento dell'applicazione. Nel caso di Active Directory Jet i/o, questo sarebbe correlare a circa 12.500/o per secondo (100 MB/s / 8 KB per I/O).

Successivamente, ottenendo le specifiche del costruttore per i moduli di controllo è necessaria al fine di acquisire una comprensione di ogni modulo in grado di supportare velocità di trasmissione. In questo esempio, il SAN ha due moduli controllore quel supporto 7.500 I/O ogni. Il rendimento totale del sistema può essere 15.000 IOPS se la ridondanza non è desiderato. Nel calcolare la velocità effettiva massima in caso di fallimento, la limitazione è la velocità effettiva di un controller o 7.500 IOPS. Questa soglia è ben di sotto i 12.500 massimo IOPS (supponendo che la dimensione del blocco di 4 KB) che può essere sostenuta da tutti i canali di stoccaggio e così, è attualmente il collo di bottiglia nell'analisi. Ancora per scopi di pianificazione, il / o massimo desiderato deve essere pianificata per sarebbe 10.400 I/O.

When the data exits the controller module, it transits a Fibre Channel connection rated at 1 Gb/s (or 1 Giga bit per second). Per correlare questo con le altre metriche, 1 Gb/s si trasforma in 128 MB/s (1 Gb/s diviso 8 bit/byte). Come questo è supera la larghezza di banda totale su tutti i canali nell'unità di archiviazione (100 MB/s), questo sarà non collo di bottiglia del sistema. Inoltre, questo è solo uno dei due canali (il supplementare 1 Gb/s Fibre Channel connessione sta per ridondanza), se una connessione non riesce, il restante collegamento ha ancora capacità sufficiente per gestire tutto il trasferimento dei dati richiesto.

In rotta verso il server, i dati transiteranno molto probabilmente un interruttore SAN. Come lo switch SAN ha elaborare la richiesta dei / o in arrivo e in avanti fuori la porta appropriata, l'interruttore avrà un limite alla quantità dei / o che possono essere gestiti, tuttavia, specifiche del costruttore sarà necessarie per determinare che cosa è quel limite. Ad esempio, se ci sono due interruttori e ogni switch in grado di gestire 10.000 IOPS, il throughput totale sarà 20.000 IOPS. Ancora una volta, colpa tolleranza essendo una preoccupazione, se uno switch fallisce, il rendimento totale del sistema saranno 10.000 IOPS. Come si desidera non superare l'80% di utilizzo nel normale funzionamento, utilizzando non più di 8000 i/o dovrebbe essere il bersaglio.

Infine, l'HBA installato nel server avrebbe anche un limite alla quantità dei / o che può gestire. Di solito, un secondo HBA è installato per la ridondanza, ma proprio come con l'interruttore SAN, calcolo I/O massima che può essere gestita, la velocità effettiva totale di HBA N-1 è ciò che è la massima scalabilità del sistema.

JJ651019.collapse(it-it,WS.11).gif Considerazioni di memorizzazione nella cache

Le cache sono uno dei componenti che possono influire in modo significativo le prestazioni complessive in qualsiasi punto nel sistema di archiviazione. Analisi dettagliata sugli algoritmi di caching è oltre la portata di questo articolo;Tuttavia, alcune istruzioni di base sulla memorizzazione nella cache su sottosistemi disco meritano illuminante:

  • Caching does improved sustained Scrittura sequenziale I/O as it can buffer many smaller write operations into larger I/O blocks and de-stage to storage in fewer, but larger block sizes. Questo ridurrà i/i/o casuale totale totale sequenziale o e, fornendo così ulteriori disponibilità delle risorse per altri i/o.

  • Memorizzazione nella cache non migliora la scrittura sostenuta I/O rendimento del sottosistema di archiviazione. Esso consente solo scrive la memorizzazione nel buffer fino a quando i mandrini sono disponibili per eseguire il commit dei dati. Quando tutti gli i/o disponibili di fusi nel sottosistema di archiviazione è saturo per lunghi periodi, la cache alla fine riempirà. Per svuotare la cache, abbastanza tempo tra scoppi, o extra mandrini, devono essere assegnati al fine di fornire abbastanza i/o per consentire il flush della cache.

    Le cache più grandi consentono solo per i dati di più di essere tamponato. Questo significa più lunghi periodi di saturazione possono essere accomodati.

    In un sottosistema di archiviazione normalmente operative, il sistema operativo sperimenteranno le prestazioni in scrittura migliorato come solo i dati devono essere scritti nella cache. Una volta che il supporto sottostante è saturato con i/o, si riempirà la cache e le prestazioni in scrittura tornerà alla velocità del disco.

  • Quando la memorizzazione nella cache di lettura I/O, lo scenario dove la cache è più vantaggiosa è quando i dati vengono memorizzati in sequenza sul disco, e la cache può read-ahead (si fa l'ipotesi che il settore successivo contiene i dati che verranno richiesti successivamente).

  • Quando leggono i/o è casuale, presso il controller dell'unità di memorizzazione nella cache è improbabile per fornire qualsiasi accessorio per la quantità di dati che possono essere letti dal disco. Qualsiasi accessorio è inesistente se il sistema operativo o la dimensione della cache basata sull'applicazione è maggiore della dimensione della cache basata su hardware.

    Nel caso di Active Directory, la cache è limitata solo dalla quantità di RAM.

JJ651019.collapse(it-it,WS.11).gif Considerazioni sulla SSD

Gli SSD sono un animale completamente diverso che mandrino basato su hard disk. Eppure i due criteri chiavi rimangono: "Quanti IOPS può esso gestire?" e "Che cosa è la latenza per quelli IOPS?" In confronto al mandrino basato su Hard disk, SSD in grado di gestire maggiori volumi di IO e può avere delle latenze inferiori. In generale e a partire da questa scrittura, mentre gli SSD sono ancora costosi in un confronto di costo per Gigabyte, sono molto a buon mercati in termini di costo-per-IO e meritano notevole considerazione in termini di prestazioni di archiviazione.

Considerazioni:

  • IOPS sia le latenze sono molto soggettive per i disegni di produttore e in alcuni casi sono state osservate per essere più povere prestazioni rispetto a mandrino basato su tecnologie. In breve, è più importante esaminare e convalidare le specifiche del produttore di unità e non si assume alcuna generalità.

  • Tipi di IOPS possono avere numeri molto diversi a seconda che esso è leggere o scrivere. Servizi di AD DS, in generale, essendo prevalentemente basato su lettura, sarà meno interessati di altri scenari di applicazione.

  • "Write endurance" – questo è il concetto che le cellule SSD si esaurisce. Vari produttori di affrontare questa sfida Mode differenti. Almeno per le unità del database, il profilo IO principalmente letto permette per sminuire il significato di questa preoccupazione, poiché i dati non sono altamente volatili.

JJ651019.collapse(it-it,WS.11).gif Riassunto

Un modo per pensare di archiviazione è immaginando impianto idraulico domestico. Immaginate IOPS dei media che i dati vengono memorizzati su è la casa principale di scarico. Quando questo è ostruito (ad esempio le radici nel tubo) o limitata (è crollato o troppo piccoli), tutti i sink nella famiglia back up quando troppa acqua viene utilizzato (anche molti ospiti). Questo è perfettamente analogo a un ambiente condiviso, dove uno o più sistemi sono sfruttando l'archiviazione condivisa su un SAN/NAS/iSCSI con lo stesso supporto sottostante. Diversi approcci possono essere adottati per risolvere i diversi scenari:

  • Un drenaggio crollato o sottodimensionato richiede una scala completa sostituzione e correzione. Questo sarebbe simile all'aggiunta di nuovo hardware o redistribuire i sistemi che utilizzano l'archiviazione condivisa in tutta l'infrastruttura.

  • Un tubo "intasato" di solito significa identificazione di uno o più problemi di offendere e la rimozione di tali problemi. In uno scenario di archiviazione potrebbe essere livello backup di archiviazione o sistema, scansioni antivirus sincronizzati su tutti i server e in esecuzione software di deframmentazione sincronizzato durante i periodi di picco.

In ogni progettazione impianti idraulici, scarichi più feed nello scarico principale. Se nulla si ferma su uno di quei canali di scolo o un punto di giunzione, solo le cose dietro quello svincolo punto di back-up. In uno scenario di stoccaggio, questo potrebbe essere un interruttore di sovraccarico (scenario di SAN/NAS/iSCSI), problemi di compatibilità driver (driver sbagliato/HBA Firmware/storport.sys combinazione) o backup/antivirus/deframmentazione. Per determinare se l'archiviazione "tubo" è abbastanza grande, dimensioni IOPS e IO deve essere misurata. A ogni giunzione aggiungerli insieme per garantire un'adeguata "diametro del tubo".

Il documento è risultato utile?
(1500 caratteri rimanenti)
Grazie per i commenti inviati.

Aggiunte alla community

Mostra:
© 2014 Microsoft. Tutti i diritti riservati.