Kapacitetsplanering för Active Directory Domain Services

Den här artikeln innehåller rekommendationer för kapacitetsplanering för Active Directory Domain Services (AD DS).

Mål för kapacitetsplanering

Kapacitetsplanering är inte detsamma som att felsöka prestandaincidenter. Målen med kapacitetsplanering är:

• Implementera och hantera en miljö korrekt.
• Minimera den tid som ägnas åt att felsöka prestandaproblem.

I kapacitetsplaneringen kan en organisation ha ett baslinjemål på 40% processoranvändning under perioder med hög belastning för att uppfylla klientens prestandakrav och ge tillräckligt med tid för att uppgradera maskinvaran i datacentret. Samtidigt anger de sitt gränsvärde för övervakningslarm för prestandaproblem till 90%, över ett femminutersintervall.

När du kontinuerligt överskrider tröskelvärdet för kapacitetshantering skulle det vara en lösning att antingen lägga till fler eller snabbare processorer för att öka kapaciteten eller skala tjänsten över flera servrar. Tröskelvärden för prestandaaviseringar meddelar dig när du behöver vidta omedelbara åtgärder när prestandaproblem påverkar klientupplevelsen negativt. Däremot skulle en felsökningslösning vara mer inriktad på att hantera engångshändelser.

Kapacitetshantering är proaktivt: design, storlek och övervakning av miljön så att användningstrender ligger inom definierade tröskelvärden och skalningsåtgärder kan inträffa innan användaren påverkas. Prestandaproblem är reaktiva: åtgärda akuta tillstånd som redan försämrar användarupplevelsen.

Kapacitetsplanering för uppskalningssystem handlar om att se till att maskinvaran och tjänsten kan hantera den belastning du förväntar dig. I båda fallen är målet att se till att systemet kan hantera den förväntade belastningen samtidigt som det ger en bra användarupplevelse. Följande arkitekturval kan hjälpa dig att uppnå det målet:

• Virtualization
• Lagring med hög hastighet, till exempel SSD (Solid State Drives) och NVMe (nonvolatile memory express)
• Molnscenarier

Active Directory Domain Services (AD DS) är en mogen distribuerad tjänst som många Microsoft- och tredjepartsprodukter använder som serverdel. Det är en av de viktigaste komponenterna för att se till att andra program har den kapacitet de behöver.

Viktig information att tänka på innan du börjar planera

För att få ut mesta möjliga av den här artikeln bör du göra följande:

• Kontrollera att du har läst och förstått riktlinjerna för prestandajustering för Windows Server.
• Windows Server-plattformen är en x64-baserad arkitektur som ger större minnesadressutrymme jämfört med x86-system. Den här artikelns riktlinjer gäller för din Active Directory-miljö oavsett Windows Server-version. För aktuella versioner möjliggör de utökade x64-minnesfunktionerna cachelagring av större databaser i minnet, även om principerna för kapacitetsplanering förblir desamma. Riktlinjerna gäller även om din miljö har ett kataloginformationsträd (DIT) som helt får plats i det tillgängliga systemminnet.
• Förstå att kapacitetsplanering är en kontinuerlig process, så du bör regelbundet granska hur väl miljön du skapar uppfyller dina förväntningar.
• Förstå att optimering sker under flera maskinvarulivscykler när maskinvarukostnaderna ändras. Om minnet till exempel blir billigare minskar kostnaden per kärna eller priset på olika lagringsalternativ ändras.
• Planera för den dagliga högbelastningsperioden. Vi rekommenderar att du gör dina planer baserat på intervallen 30 minuter eller timme. Tänk på följande information när du väljer ditt intervall:
  • Intervall som är större än en timme kan döljas när tjänsten faktiskt når den högsta kapaciteten.
  • Intervall som är mindre än 30 minuter kan göra att tillfälliga ökningar ser viktigare ut än de faktiskt är.
• Planera för tillväxt under företagets maskinvarulivscykel. Den här tillväxtplaneringen kan omfatta strategier för att uppgradera eller lägga till maskinvara på ett förskjutet sätt, eller en fullständig uppdatering vart tredje till femte år. Varje tillväxtplan kräver att du uppskattar hur mycket belastningen på Active Directory växer. Historiska data kan hjälpa dig att göra en mer exakt bedömning.
• Feltolerans är möjligheten för ett system att fortsätta fungera korrekt när vissa komponenter misslyckas. När du har fastställt vilken kapacitet du behöver (kallas n) bör du planera för feltolerans. Överväg n + 1, n + 2 eller till och med n + x scenarier. Om du till exempel behöver två domänkontrollanter (DCs) planerar du för tre så att du kan hantera ett DC-fel.

  • Baserat på din tillväxtplan lägger du till extra servrar enligt organisationens behov för att säkerställa att förlust av en eller flera servrar inte gör att systemet överskrider maximala uppskattningar av maximal kapacitet.

  • Kom ihåg att integrera dina planer för tillväxt och feltolerans. Till exempel hanterar en domänkontrollant (DC) dagens belastning. Prognoser visar att belastningen fördubblas inom ett år och att det kommer att behövas två datacenter för att kunna möta efterfrågan fullt ut. Det lämnar ingen outnyttjad kapacitet för feltolerans. För att förhindra den här bristen på kapacitet bör du i stället planera att börja med tre domänkontrollanter. Om din budget inte tillåter tre domänkontrollanter kan du också börja med två domänkontrollanter och sedan planera att lägga till en tredje efter tre eller sex månader.

    Note

    Att lägga till Active Directory-medvetna program kan ha en märkbar inverkan på DC-belastningen, oavsett om belastningen kommer från programservrarna eller klienterna.

Kapacitetsplaneringscykeln i tre delar

Innan du påbörjar planeringscykeln måste du bestämma vilken tjänstkvalitet din organisation behöver. Alla rekommendationer och riktlinjer i den här artikeln är för optimala prestandamiljöer. Du kan dock selektivt koppla av dem i fall där du inte behöver optimering. Om din organisation till exempel behöver en högre nivå av samtidighet och mer konsekvent användarupplevelse bör du titta på hur du konfigurerar ett datacenter. Med datacenter kan du ägna större uppmärksamhet åt redundans och minimera flaskhalsar i system och infrastruktur. Om du däremot planerar en distribution för ett satellitkontor med bara några få användare behöver du inte bekymra dig lika mycket om maskinvaru- och infrastrukturoptimering, vilket gör att du kan välja alternativ med lägre kostnad.

Därefter bör du bestämma om du vill använda virtuella eller fysiska datorer. Ur kapacitetsplaneringssynpunkt finns det inget rätt eller fel svar. Du måste dock komma ihåg att varje scenario ger dig en annan uppsättning variabler att arbeta med.

Virtualiseringsscenarier ger dig två alternativ:

• Direktmappning, där du bara har en gäst per värd.
• Scenarier med delad värd , där du har flera gäster per värd.

Du kan behandla direktmappningsscenarier identiskt med fysiska värdar. Om du väljer ett scenario med delad värd introducerar det andra variabler som du bör ta hänsyn till i senare avsnitt. Delade värdar konkurrerar också om resurser med Active Directory Domain Services (AD DS), vilket kan påverka systemets prestanda och användarupplevelse.

När du har besvarat de tidigare planeringsfrågorna ska vi titta på själva kapacitetsplaneringscykeln. Varje kapacitetsplaneringscykel omfattar en process i tre steg:

1. Mät den befintliga miljön, ta reda på var flaskhalsarna i systemet för närvarande finns och få de miljögrundläggande mätvärden som krävs för att planera den kapacitet ditt system behöver.
2. Ta reda på vilken maskinvara du behöver baserat på dina kapacitetskrav.
3. Övervaka och verifiera att infrastrukturen som du har konfigurerat fungerar inom specifikationerna. Data som du samlar in i det här steget blir baslinjen för nästa cykel av kapacitetsplanering.

Att tillämpa processen

För att optimera prestanda, kontrollera att följande huvudkomponenter är korrekt valda och justerade för programbelastningarna.

• Memory
• Network
• Storage
• Processor
• Netlogon

Grundläggande lagringskrav för AD DS och det allmänna beteendet för kompatibel klientprogramvara innebär att modern maskinvara i serverklass enkelt uppfyller kapacitetsplaneringsbehoven i miljöer med så många som 10 000 till 20 000 användare. Kapacitetsplanering är fortfarande viktigt för alla distributioner, men mindre miljöer har i allmänhet större flexibilitet i sina maskinvaruval eftersom de flesta nuvarande serversystem kan hantera dessa belastningar utan att kräva särskild optimering.

Tabellerna i Sammanfattningstabeller för datainsamling förklarar hur du utvärderar din befintliga miljö för att välja rätt maskinvara. Avsnitten efter det går in mer detaljerat om baslinjerekommendationer och miljöspecifika principer för maskinvara för att hjälpa AD DS-administratörer att utvärdera sin infrastruktur.

Annan information som du bör tänka på när du planerar:

• Alla storleksändringar baserat på aktuella data är bara korrekta för den aktuella miljön.
• När du gör uppskattningar kan du förvänta dig att efterfrågan kommer att öka under maskinvarans livscykel.
• Hantera framtida tillväxt genom att avgöra om du bör överdimensionera din miljö idag eller gradvis lägga till kapacitet under livscykeln.
• Alla principer och metoder för kapacitetsplanering som du tillämpar på en fysisk distribution gäller även för en virtualiserad distribution. Men när du planerar en virtualiserad miljö måste du komma ihåg att lägga till virtualiseringskostnaderna i alla domänrelaterade planeringar eller uppskattningar.
• Kapacitetsplanering är en förutsägelse, inte ett helt korrekt värde, så förvänta dig inte att det är helt korrekt. Kom alltid ihåg att justera kapaciteten efter behov och verifiera hela tiden att din miljö fungerar som den ska.

Sammanfattningstabeller för datainsamling

I följande tabeller listas och förklaras kriterier för att fastställa dina maskinvaruuppskattningar.

Arbetsmiljö

Utvärderingskriterier på hög nivå

Planning

Under lång tid var den typiska rekommendationen för AD DS-storlek att lägga in så mycket RAM-minne som databasens storlek. Även om ökad beräkningskraft och byte från x86-arkitektur till x64 gjorde subtilare aspekter av storleksändring för prestanda mindre viktiga för AD DS som finns på fysiska datorer, betonade virtualisering vikten av prestandajustering.

För att åtgärda dessa problem beskriver följande avsnitt hur du fastställer och planerar för kraven för Active Directory som en tjänst. Du kan tillämpa dessa riktlinjer på alla miljöer oavsett om din miljö är fysisk, virtualiserad eller blandad. För att maximera prestandan bör målet vara att få din AD DS-miljö så nära processorbunden som möjligt.

RAM

Ju mer lagringsutrymme du kan cachelagma i RAM-minnet, desto mindre behöver du gå till disken.

För att maximera serverns skalbarhet beräknar du dina minsta RAM-krav genom att summera dessa komponenter:

• Aktuell databasstorlek
• Rekommenderat belopp för operativsystemet
• Leverantörsrekommendationer för agenter, till exempel:
  • Antivirusprogram
  • Övervakning av programvara
  • Säkerhetskopieringsprogram

Du bör också inkludera extra RAM-minne för att hantera framtida tillväxt under serverns livslängd. Den här uppskattningen ändras baserat på databastillväxt och miljöförändringar.

För miljöer där det inte är kostnadseffektivt eller möjligt att maximera RAM-minnet kan du läsa avsnittet Lagring för att konfigurera lagringen korrekt. Dessa scenarier omfattar:

• Satellitplatser med budgetbegränsningar
• Distributioner där KATALOGinformationsträdet (DIT) är för stort för att få plats i minnet

En annan viktig sak att tänka på när det gäller storleksändring av minne är sidfilens storlek. I diskstorlek, precis som allt annat som rör minne, är målet att minimera diskanvändningen. I synnerhet, hur mycket RAM-minne behöver du för att minimera sidväxling? De kommande avsnitten bör ge dig den information du behöver för att besvara den här frågan. Andra överväganden för sidstorlek som inte nödvändigtvis påverkar AD DS-prestanda är operativsystemrekommendationer (OS) och konfiguration av systemet för minnesdumpar.

Det kan vara svårt att avgöra hur mycket RAM-minne en domänkontrollant (DC) behöver på grund av många komplexa faktorer:

• Befintliga system är inte alltid tillförlitliga indikatorer på RAM-krav eftersom LSASS (Local Security Authority Subsystem Service) trimmar RAM-minnet under minnestryck och artificiellt deflaterar kraven.
• Enskilda domänkontrollanter behöver bara cachelagrade data som deras klienter är intresserade av. Det innebär att data som cachelagras i olika miljöer ändras beroende på vilka typer av klienter de innehåller. En domänkontrollant i en miljö med en Exchange Server samlar till exempel in andra data än en domänkontrollant som endast autentiserar användare.
• Den mängd arbete du behöver för att utvärdera RAM-minne för varje domänkontrollant från fall till fall är ofta överdriven och ändras när miljön förändras.

Kriterierna bakom rekommendationerna kan hjälpa dig att fatta mer välgrundade beslut:

• Ju mer du cachelagr i RAM-minnet, desto mindre behöver du gå till disken.
• Lagring är en dators långsammaste komponent. Dataåtkomst på spindelbaserade lagringsmedier och SSD-lagringsmedia är en miljon gånger långsammare än dataåtkomsten i RAM-minnet.

Virtualiseringsöverväganden för RAM

Målet med att optimera RAM-minnet är att minimera tiden som ägnas åt att gå till disken. Undvik överbelastning av minne på värdsystemet (allokera mer RAM-minne till gäster än vad den fysiska maskinen har). Enbart över incheckning är inte ett problem, men om den totala gästanvändningen överskrider värd-RAM-minnet, värdsidorna. Växling gör att prestandan blir diskberoende när domänkontrollanten går till NTDS.dit eller sidfilen, eller när värden byter från RAM-minnet. Det här beteendet minskar avsevärt prestanda och användarupplevelse.

Exempel på beräkningssammanfattning

Rekommenderas: 16 GB

Med tiden läggs mer data till i databasen och den genomsnittliga serverlivslängden är ungefär tre till fem år. Baserat på en tillväxtuppskattning på 33%är 18 GB en rimlig mängd RAM-minne för att sätta in en fysisk server.

Network

Det här avsnittet handlar om att utvärdera hur mycket total bandbredd och nätverkskapacitet distributionen behöver, inklusive klientfrågor, grupprincipinställningar och så vidare. Du kan samla in data för att göra din uppskattning med hjälp av Network Interface(*)\Bytes Received/sec och Network Interface(*)\Bytes Sent/sec prestandaräknarna. Exempelintervallen för nätverksgränssnittsräknare ska vara antingen 15, 30 eller 60 minuter. Allt mindre är för flyktigt för bra mätningar, och allt större jämnar ut dagliga toppar.

Bandbreddsbehov

Planeringen för nätverksskalbarhet omfattar två olika kategorier: mängden trafik och CPU-belastningen från nätverkstrafiken.

Det finns två saker du måste ta hänsyn till när du planerar kapacitet för trafiksupport. Först behöver du ta reda på hur mycket Active Directory-replikeringstrafik som går mellan dina DC:er. För det andra måste du utvärdera din intrasite-klient-till-server-trafik. Intrasite-trafik tar främst emot små begäranden från klienter i förhållande till de stora mängder data som skickas tillbaka till klienter. 100 MB räcker vanligtvis för miljöer med upp till 5 000 användare per server. För miljöer med över 5 000 användare rekommenderar vi att du använder ett 1 GB nätverkskort och RSS-stöd (Receive Side Scaling) i stället.

Om du vill utvärdera trafikkapaciteten inom en plats, särskilt i scenarier med serverkonsolidering, bör du titta på Network Interface(*)\Bytes/sec prestandaräknaren för alla domänkontrollanter på en plats, lägga till dem tillsammans och sedan dividera summan med målantalet domänkontrollanter. Ett enkelt sätt att beräkna det här talet är att öppna tillförlitlighets- och prestandaövervakaren för Windows och titta på vyn Staplat område . Kontrollera att alla räknare skalas på samma sätt.

Låt oss ta en titt på ett exempel på ett mer komplext sätt att verifiera att den här allmänna regeln gäller för en specifik miljö. I det här exemplet gör vi följande antaganden:

• Målet är att minska fotavtrycket till så få servrar som möjligt. Helst bär en server belastningen och sedan distribuerar du en annan server för redundans (n + 1 scenario).
• I det här scenariot stöder det aktuella nätverkskortet endast 100 MB och är i en växlad miljö.
• Den maximala nätverksbandbreddsanvändningen är 60% i ett n-scenario (förlust av en domänkontrollant).
• Varje server har cirka 10 000 klienter anslutna till den.

Nu ska vi titta på vad diagrammet i räknaren Network Interface(*)\Bytes Sent/sec visar för det här exempelscenariot:

1. Arbetsdagen börjar öka runt 05:30 och varvar ner klockan 19:00.
2. Den mest hektiska perioden är från 08:00 till 08:15, med mer än 25 byte som skickas per sekund på det mest belastade datacentret.

   Note

   Alla prestandadata är historiska, så den högsta datapunkten kl. 08:15 anger belastningen från 08:00 till 08:15.

3. Det finns toppar före 04:00, med mer än 20 byte som skickas per sekund på det mest trafikerade datacentret, vilket kan tyda på belastning från olika tidszoner eller bakgrundsinfrastrukturaktivitet, till exempel säkerhetskopior. Eftersom toppen kl. 08:00 överskrider den här aktiviteten är den inte relevant.
4. Det finns fem domänkontrollanter på webbplatsen.
5. Den maximala belastningen är cirka 5,5 MB/s per datacenter, vilket motsvarar 44% av 100 MB-anslutningen. Med hjälp av dessa data kan vi uppskatta att den totala bandbredden som behövs mellan 08:00 och 08:15 är 28 Mbit/s.

   Note

   Nätverksgränssnittets sänd/ta emot-räknare är i bytes, men nätverksbandbredden mäts i bitar. För att beräkna den totala bandbredden behöver du därför göra 100 MB ÷ 8 = 12,5 MB och 1 GB ÷ 8 = 128 MB.

Vilka slutsatser kan du dra av nätverksanvändningsexemplet när du har granskat data?

• Den aktuella miljön uppfyller feltoleransnivån n + 1 vid 60% målanvändning. Om du tar ett system offline flyttas bandbredden per server från cirka 5,5 Mbit/s (44%) till cirka 7 Mbit/s (56%).
• Baserat på det tidigare angivna målet att konsolidera till en server överskrider den här konsolideringsändringen den maximala målanvändningen och den möjliga användningen av en anslutning på 100 MB.
• Med en anslutning på 1 GB representerar det här bandbreddsvärdet per server 22% av den totala kapaciteten.
• Under normala driftsförhållanden i scenariot n + 1 är klientbelastningen relativt fördelad på cirka 14 MBIT/s per server eller 11% av den totala kapaciteten.
• För att se till att du har tillräckligt med kapacitet när en domänkontrollant inte är tillgänglig, skulle de normala driftmålen per server vara cirka 30% nätverksanvändning eller 38 Mbit/s per server. Failover-målen skulle vara 60% nätverksanvändning eller 72 MB/s per server.

Den slutliga systemdistributionen måste ha ett nätverkskort på 1 GB och en anslutning till nätverksinfrastrukturen som kan stödja den nödvändiga belastningen. På grund av mängden nätverkstrafik kan CPU-belastningen från nätverkskommunikation potentiellt begränsa den maximala skalbarheten för AD DS. Du kan använda samma process för att uppskatta inkommande kommunikation till datacentret. I de flesta fall behöver du dock inte beräkna inkommande trafik eftersom den är mindre än utgående trafik.

Det är viktigt att se till att maskinvaran stöder RSS i miljöer med över 5 000 användare per server. I scenarier med hög nätverkstrafik kan det bli en flaskhals att balansera avbrottsbelastningen. Du kan identifiera potentiella flaskhalsar genom att kontrollera räknaren Processor(*)\% Interrupt Time för att se om avbrottstiden är ojämnt fördelad mellan processorer. RSS-aktiverade nätverksgränssnittsstyrenheter (NIC) kan minska dessa begränsningar och öka skalbarheten.

Virtualiseringsöverväganden för nätverksbandbredd

Den typiska rekommendationen för en fysisk server är ett 1 GB kort för servrar som stöder över 5 000 användare. När flera gäster börjar dela en underliggande infrastruktur för virtuell växel kontrollerar du att värden har tillräcklig aggregerad nätverksbandbredd för att stödja alla gäster. Ta hänsyn till bandbredd i båda scenarierna: när domänkontrollanten körs som en virtuell dator på en värd med nätverkstrafik via en virtuell brytare och när den ansluter direkt till en fysisk brytare. Virtuella växlar kräver noggrann bandbreddsplanering. Överordnad länk måste ha stöd för de aggregerade data som skickas genom den. Det fysiska värdnätverkskortet som är länkat till växeln måste ha stöd för DC-belastningen och alla andra gäster som delar den virtuella växeln och ansluter via det fysiska kortet.

Exempel på sammanfattning av nätverksberäkning

Följande tabell innehåller värden från ett exempelscenario som vi kan använda för att beräkna nätverkskapacitet:

Baserat på den här tabellen skulle den rekommenderade bandbredden vara 72 Mbit/s (28,5 Mbit/s ÷ 40%).

Som alltid bör du anta att klientbelastningen ökar med tiden, så du bör planera för den här tillväxten så tidigt som möjligt. Vi rekommenderar att du planerar för minst 50% uppskattad nätverkstrafiktillväxt.

Storage

Det finns två saker du bör tänka på när du planerar kapacitet för lagring:

• Kapacitet eller lagringsstorlek
• Performance

Även om kapaciteten är viktig är det viktigt att inte försumma prestanda. Med aktuella maskinvarukostnader är de flesta miljöer inte tillräckligt stora för att någon av faktorerna ska vara ett stort problem. Därför är den vanliga rekommendationen att bara lägga in så mycket RAM-minne som databasens storlek. Den här rekommendationen kan dock vara överdriven för satellitplatser i större miljöer.

Sizing

Utvärdera för lagring

Jämfört med när Active Directory först kom vid en tidpunkt då 4 GB och 9 GB enheter var de vanligaste enhetsstorlekarna, är storleksändring för Active Directory inte ens ett övervägande för alla utom de största miljöerna. Med de minsta tillgängliga hårddiskstorlekarna i intervallet 180 GB kan hela operativsystemet och SYSVOLNTDS.dit enkelt få plats på en enhet. Därför rekommenderar vi att du undviker att investera för mycket i lagringsstorlek.

Vi rekommenderar att 110% av den NTDS.dit storleken är tillgänglig så att du kan defragmentera ditt lagringsutrymme.

Utöver den här rekommendationen bör du ta de vanliga övervägandena för att ta hänsyn till framtida tillväxt.

Om du ska utvärdera lagringen måste du först utvärdera hur stor NTDS.dit och SYSVOL måste vara. De här måtten hjälper dig att storleksanpassa både den fasta disken och RAM-allokeringarna. Eftersom komponenterna är relativt låg kostnad behöver du inte vara super exakt när du gör matematiken. Mer information om lagringsutvärdering finns i Lagringsgränser och tillväxtuppskattningar för Active Directory-användare och organisationsenheter.

När du granskar befintliga miljöer med flera domäner kan du märka variationer i databasstorlekar. När du upptäcker dessa varianter använder du den minsta globala katalogen (GC) och icke-GC-storlekar.

Databasstorlekarna kan variera mellan operativsystemversioner. Domänkontrollanter som kör tidigare OS-versioner har mindre databaser än en som kör en senare version. Domänkontrollanten med funktioner som Active Directory Recycle Bin eller Roaming för behörighetshantering aktiverat kan också påverka databasens storlek.

Virtualiseringsöverväganden för lagring

I scenarier där du allokerar flera VHD-filer (Virtual Hard Disk) till en enda volym bör du använda en disk med fast tillstånd. Disken bör vara minst 210% storleken på DIT för att säkerställa att du har tillräckligt med utrymme reserverat för dina behov. Den här fasta VHD-storleken innehåller 100% av DIT-storleken plus 110% ledigt utrymme.

Exempel på sammanfattning av lagringsberäkning

I följande tabell visas de värden som du använder för att uppskatta utrymmeskraven för ett hypotetiskt lagringsscenario.

Lagringsuppskattningen bör också innehålla fler lagringskomponenter utöver databasen. Dessa komponenter omfattar:

• SYSVOL
• Operativsystemfiler
• Sidfil
• Temporära filer
• Lokala cachelagrade data, till exempel installationsfiler
• Ansökningar

Lagringsprestanda

Som den långsammaste komponenten i alla datorer kan lagring ha störst negativ inverkan på klientupplevelsen. För miljöer som är så stora att RAM-storleksrekommendationerna i den här artikeln inte är möjliga kan konsekvenserna av att förbise kapacitetsplanering för lagring vara förödande för systemets prestanda. Komplexiteten och sorterna av tillgänglig lagringsteknik ökar risken ytterligare, eftersom den typiska rekommendationen att placera operativsystemet, loggarna och databasen på separata fysiska diskar inte gäller universellt i alla scenarier.

De gamla rekommendationerna om diskar antog att en disk var en dedikerad spindel som tillät isolerad I/O. Det här antagandet för dedikerad spindel är inte längre sant på grund av introduktionen av följande lagringstyper:

• RAID
• Nya lagringstyper och virtualiserade och delade lagringsscenarier
• Delade spindlar i ett san-nätverk (Storage Area Network)
• VHD-fil på en SAN- eller nätverksansluten lagring
• Solid State Drives (SSD)
• NVMe-enheter (Nonvolatile Memory Express)
• Nivåindelade lagringsarkitekturer, såsom SSD-cachelagring för större spindelbaserad lagring

Andra arbetsbelastningar som placeras på backend-lagringen kan överbelasta delad lagring, till exempel RAID, SAN, NAS, JBOD, Storage Spaces och VHD. Dessa typer av lagringsenheter kan innebära ett extra övervägande. Till exempel kan problem med SAN, nätverk eller drivrutin mellan den fysiska disken och Active Directory-programmet orsaka strypningar och fördröjningar. För att förtydliga är dessa typer av lagringsarkitekturer inte ett dåligt val, men de är mer komplexa, vilket innebär att du måste vara extra uppmärksam för att se till att varje komponent fungerar som avsett. Mer detaljerade förklaringar finns i bilaga C och bilaga D senare i den här artikeln.

Den här solid state-lagringstekniken (NVMe och SSD) har inte samma mekaniska begränsningar som traditionella hårddiskar. De har dock fortfarande I/O-begränsningar. När du överskrider dessa gränser kan systemet överbelastas.

Målet med planeringen av lagringsprestanda är att säkerställa att det nödvändiga antalet I/Os alltid är tillgängligt och att de sker inom en acceptabel tidsram. Mer information om scenarier med lokalt ansluten lagring finns i Bilaga C. Du kan tillämpa principerna i bilagan på mer komplexa lagringsscenarier och konversationer med leverantörer som stöder dina serverdelslagringslösningar.

På grund av hur många lagringsalternativ som är tillgängliga idag rekommenderar vi att du kontaktar maskinvarusupportteamen eller leverantörerna samtidigt som du planerar att se till att lösningen uppfyller behoven för ad DS-distributionen. Under de här konversationerna kan följande prestandaräknare vara användbara, särskilt när databasen är för stor för RAM-minnet:

• LogicalDisk(*)\Avg Disk sec/Read (om NTDS.dit till exempel lagras på enhet D, skulle den fullständiga sökvägen vara LogicalDisk(D:)\Avg Disk sec/Read)
• LogicalDisk(*)\Avg Disk sec/Write
• LogicalDisk(*)\Avg Disk sec/Transfer
• LogicalDisk(*)\Reads/sec
• LogicalDisk(*)\Writes/sec
• LogicalDisk(*)\Transfers/sec

När du anger data bör du se till att urvalsintervallen är 15, 30 eller 60 minuter för att ge en så exakt bild av din aktuella miljö som möjligt.

Utvärdera resultaten

Det här avsnittet fokuserar på läsningar från databasen, eftersom databasen vanligtvis är den mest krävande komponenten. Du kan använda samma logik för skrivningar till loggfilen genom att <NTDS Log>)\Avg Disk sec/Write ersätta och LogicalDisk(<NTDS Log>)\Writes/sec).

Räknaren LogicalDisk(<NTDS>)\Avg Disk sec/Read visar om den aktuella lagringen är tillräckligt stor. Om värdet är ungefär lika med den förväntade diskåtkomsttiden för disktypen är räknaren LogicalDisk(<NTDS>)\Reads/sec ett giltigt mått. Om resultatet är ungefär lika med diskåtkomsttiden för disktypen är räknaren LogicalDisk(<NTDS>)\Reads/sec ett giltigt mått. Även om acceptabel svarstid varierar beroende på lagringsleverantör, är bra intervall för LogicalDisk(<NTDS>)\Avg Disk sec/Read :

• 7 200 rpm: 9 millisekunder till 12,5 millisekunder (ms)
• 10 000 rpm: 6 ms till 10 ms
• 15 000 rpm: 4 ms till 6 ms
• SSD – 1 ms till 3 ms

Du kan höra från andra källor att lagringsprestandan försämras vid 15 ms till 20 ms. Skillnaden mellan dessa värden och värdena i föregående lista är att listvärdena visar det normala driftsintervallet. De andra värdena är för felsökningsändamål, som hjälper dig att identifiera när klientupplevelsen har försämrats tillräckligt för att det ska bli märkbart. Mer information finns i Bilaga C.

• LogicalDisk(<NTDS>)\Reads/sec är mängden I/O som systemet för närvarande utför.
  • Om LogicalDisk(<NTDS>)\Avg Disk sec/Read är inom det optimala intervallet för serverdelslagringen kan du använda LogicalDisk(<NTDS>)\Reads/sec direkt för att storleksanpassa lagringen.
  • Om LogicalDisk(<NTDS>)\Avg Disk sec/Read inte ligger inom det optimala intervallet för serverdelslagringen krävs mer I/O enligt följande formel: LogicalDisk(<NTDS>)\Avg Disk sec/Read ÷ åtkomsttid för fysiska medier × LogicalDisk(<NTDS>)\Avg Disk sec/Read

När du gör de här beräkningarna bör du tänka på följande:

• Om servern har en mindre mängd RAM-minne kan de resulterande värdena vara för höga och inte tillräckligt exakta för att vara användbara för planeringen. Du kan dock fortfarande använda dem för att förutsäga värsta tänkbara scenarier.
• Om du lägger till eller optimerar RAM-minne minskar du också mängden läs-I/O LogicalDisk(<NTDS>)\Reads/Sec. Den minskningen kan göra att lagringslösningen blir mindre robust än de ursprungliga beräkningar som föreslogs. Tyvärr kan vi inte ge mer detaljer om vad den här instruktionen innebär, eftersom beräkningarna varierar kraftigt beroende på enskilda miljöer, särskilt klientbelastning. Vi rekommenderar dock att du justerar lagringsstorleken när du har optimerat RAM-minnet.

Virtualiseringsöverväganden för prestanda

Precis som i föregående avsnitt är målet för virtualiseringsprestanda att säkerställa att den delade infrastrukturen kan stödja den totala belastningen för alla konsumenter. Tänk på det här målet när du planerar för följande scenarier:

• En fysisk CD som delar samma media på en SAN-, NAS- eller iSCSI-infrastruktur som andra servrar eller program.
• En användare som använder direktåtkomst till en SAN-, NAS- eller iSCSI-infrastruktur som delar mediet.
• En användare som använder en VHD-fil på delade medier lokalt eller en SAN-, NAS- eller iSCSI-infrastruktur.

Från en gästanvändares perspektiv påverkas prestandan av att behöva gå igenom en värd för att få tillgång till någon lagring, eftersom användaren måste gå igenom fler kodvägar för att få åtkomst. Prestandatestning indikerar att virtualisering påverkar dataflödet baserat på hur mycket av processorn som värdsystemet använder. Processoranvändningen påverkar hur många resurser gästanvändaren kräver av värden. Detta krav bidrar till virtualiseringsöverväganden för bearbetning som du bör ta för bearbetningsbehov i virtualiserade scenarier. Mer information finns i Bilaga A.

Ytterligare komplicerande frågor är hur många lagringsalternativ som för närvarande är tillgängliga, var och en med mycket olika prestandapåverkan. De här alternativen omfattar direktlagring, SCSI-kort och IDE. När du migrerar från en fysisk till en virtuell miljö bör du justera för olika lagringsalternativ för virtualiserade gästanvändare med hjälp av en multiplikator på 1,10. Du behöver dock inte överväga justeringar när du överför mellan olika lagringsscenarier, eftersom lagringen är lokal, SAN, NAS eller iSCSI är viktigare.

Exempel på virtualiseringsberäkning

Fastställa mängden I/O som behövs för ett felfritt system under normala driftsförhållanden:

• LogicalDisk(<NTDS Database Drive>) ÷ överföringar per sekund under den högsta perioden på 15 minuter
• Så här avgör du hur mycket I/O som behövs för lagring där kapaciteten för den underliggande lagringen överskrids:

  Nödvändig IOPS = (LogicalDisk(<NTDS Database Drive>)) ÷ Genomsnittlig diskläsning/sek ÷ <Target Avg Disk Read/sec>) × LogicalDisk(<NTDS Database Drive>)\Read/s

Så här avgör du med vilken hastighet du ska värma cachen:

• Fastställ den maximala tid som du tycker är acceptabel för att spendera på cacheuppvärmning. I vanliga scenarier skulle en acceptabel tid vara hur lång tid det ska ta att läsa in hela databasen från en disk. I scenarier där RAM-minnet inte kan läsa in hela databasen använder du den tid det tar att fylla hela RAM-minnet.
• Fastställ databasens storlek, exklusive utrymme som du inte planerar att använda. Mer information finns i Utvärdera för lagring.
• Dela upp databasens storlek med 8 KB för att få det totala antalet I/Os som du behöver för att läsa in databasen.
• Dividera det totala I/Os med antalet sekunder inom den definierade tidsramen.

Talet du beräknar är en uppskattning. Det är inte exakt eftersom storleken på extensible Storage Engine (ESE)-cacheminnet inte är fast. Som standard växer cachen och krymper, så AD DS kan ta bort sidor som den läste in tidigare. En fast cachestorlek skulle göra uppskattningen mer exakt.

Processing

Utvärdera Användning av Active Directory-processor

För de flesta miljöer är hantering av bearbetningskapacitet den komponent som förtjänar mest uppmärksamhet. När du utvärderar hur mycket processorkapacitet distributionen behöver bör du tänka på följande två saker:

• Fungerar programmen i din miljö som avsedda i en infrastruktur för delade tjänster baserat på de kriterier som beskrivs i Spåra dyra och ineffektiva sökningar? I större miljöer kan dåligt kodade program göra cpu-belastningen instabil, ta en orimlig mängd CPU-tid på bekostnad av andra program, öka kapacitetsbehoven och fördela belastningen ojämnt mot domänkontrollanterna.
• AD DS är en distribuerad miljö med många potentiella klienter vars bearbetningsbehov varierar kraftigt. Uppskattade kostnader för varje klient kan variera på grund av användningsmönster och hur många program som använder AD DS. Precis som i Nätverk bör du använda beräkning som en utvärdering av den totala kapacitet som behövs i miljön i stället för att titta på varje klient en i taget.

Slutför din lagringsuppskattning innan du börjar uppskatta processoranvändningen. Du kan inte göra en korrekt gissning utan giltiga data om processorbelastningen. Det är också viktigt att se till att lagringen inte skapar några flaskhalsar innan du felsöker processorn. När du tar bort processorväntetillstånd ökar processoranvändningen eftersom den inte längre behöver vänta på data. Därför är de prestandaräknare som du bör ägna mest uppmärksamhet åt:

• Logical Disk(<NTDS Database Drive>)\Avg Disk sec/Read
• Process(lsass)\ Processor Time

Om räknaren Logical Disk(<NTDS Database Drive>)\Avg Disk sec/Read är över 10 millisekunder eller 15 millisekunder är data i Process(lsass)\ Processor Time artificiellt låga och problemet gäller lagringsprestanda. Vi rekommenderar att du anger exempelintervall till 15, 30 eller 60 minuter för så exakta data som möjligt.

Översikt över bearbetning

För att planera kapacitetsplanering för domänkontrollanter kräver bearbetningskraft mest uppmärksamhet och förståelse. När du storleksanpassar system för att säkerställa maximal prestanda finns det alltid en komponent som är flaskhalsen, och i en domänkontrollant med rätt storlek är den här komponenten processorn.

På samma sätt som i nätverksavsnittet där miljöefterfrågan granskas på plats-för-plats-basis måste samma sak göras för den beräkningskapacitet som krävs. Till skillnad från nätverksavsnittet, där de tillgängliga nätverksteknikerna vida överskrider den normala efterfrågan, bör du ägna mer uppmärksamhet åt att storleksanpassa processorkapaciteten. Som alla miljöer av även måttlig storlek, kan allt över några tusen samtidiga användare lägga signifikant belastning på processorn.

På grund av den enorma variationen av klientprogram som använder AD är tyvärr en allmän uppskattning av användare per CPU bedrövligt otillämpbar för alla miljöer. Mer specifikt omfattas beräkningskraven av användarbeteende och programprofil. Därför måste varje miljö vara individuellt storleksanpassad.

Beteendeprofil för målwebbplats

När du planerar kapacitet för en hel webbplats bör ditt mål vara en kapacitetsdesign för N + 1. I den här designen, även om ett system misslyckas under hög belastningsperioden, kan tjänsten fortfarande fortsätta på acceptabla kvalitetsnivåer. I ett N-scenario bör inläsningen i alla rutor vara mindre än 80%-100% under perioder med hög belastning.

Dessutom använder webbplatsens program och klienter den rekommenderade DsGetDcName-funktionsmetoden för att hitta domänkontrollanter. De bör redan vara jämnt fördelade med endast mindre tillfälliga toppar.

Nu ska vi titta på två exempel på miljöer som är i linje med målet och inte i linje med målet. Först ska vi ta en titt på ett exempel på en miljö som fungerar som avsett och inte överskrider kapacitetsplaneringsmålet.

I det första exemplet gör vi följande antaganden:

• Var och en av de fem domänkontrollanterna i miljön har fyra processorer.
• Den totala cpu-målanvändningen under kontorstid är 40% under normala driftsförhållanden (N + 1) och 60% annars (N). Under icke-arbetstid är målets CPU-användning 80% eftersom vi förväntar oss att säkerhetskopieringsprogramvaran och andra underhållsprocesser ska förbruka alla tillgängliga resurser.

Nu ska vi ta en titt på (Processor Information(_Total)\% Processor Utility) diagrammet för varje av DC:erna som visas i följande bild.

• Belastningen är jämnt fördelad, vilket är vad vi förväntar oss när klienter använder DC-positioneraren och välskrivna sökningar.

• I flera femminutersintervall finns det toppar på 10%, ibland till och med 20%. Men om dessa toppar inte leder till att CPU-användningen överskrider kapacitetsplanens mål behöver du inte undersöka dem.

• Den högsta perioden för alla system är mellan 08:00 och 09:15. Den genomsnittliga arbetsdagen varar från 05:00 till 17:00. Därför ligger alla slumpmässiga toppar av CPU-användningen som inträffar mellan 17:00 och 04:00 utanför kontorstid, och därför behöver du inte inkludera dem i dina kapacitetsplaneringsproblem.

  Under lågtrafik uppstår korta toppar i ett välhanterat system vanligtvis på grund av:

  • Säkerhetskopieringsjobb
  • Fullständiga antivirusgenomsökningar
  • Genomsökningar av maskinvaruinventering
  • Genomsökningar av programvaruinventering
  • Distribution av programvara eller korrigeringar

  Spikar utanför dessa uppdrag kan indikera en onormal belastning och motivera en undersökning. Eftersom dessa toppar inträffar utanför kontorstid räknas de inte för att överskrida kapacitetsplaneringsmålen.

• Eftersom varje system är cirka 40% och alla har samma antal processorer, körs de återstående systemen på uppskattningsvis 53%om någon av dem går offline. System D:s 40% belastning delas sedan jämnt mellan de återstående systemen och läggs till i deras befintliga 40% belastning. Det här linjära omdistributionsantagandet är inte helt korrekt, men det ger tillräckligt med noggrannhet för uppskattning.

Nu ska vi titta på ett exempel på en miljö som inte har bra CPU-användning och som överskrider kapacitetsplaneringsmålet.

I det här exemplet drivs två domänkontrollanter vid 40% kapacitet. En går offline och den återstående domänkontrollanten ökar till uppskattningsvis 80 %. Under övergång till reservdrift överskrider den här belastningen tröskelvärdet för kapacitetsplanen och krymper marginalen till 10%–20% vid toppar. Varje topp kan nu driva datacentret till 90% eller till och med 100%, vilket minskar responsen.

Beräkna cpu-krav

Prestandaräknaren Process\% Processor Time spårar den totala tid som alla programtrådar lägger på processorn och delar sedan den summan med den totala mängden systemtid som skickas. Ett flertrådat program i ett system med flera processorer kan överskrida 100% CPU-tid och du tolkar dess data på ett annat sätt än räknaren Processor Information\% Processor Utility . I praktiken spårar räknaren Process(lsass)\% Processor Time hur många processorer som körs på 100% systemet kräver för att stödja en processs krav. Om räknaren till exempel har värdet 200%innebär det att systemet behöver två processorer som körs på 100% för att stödja den fullständiga AD DS-belastningen. Även om en processor som körs på 100% kapacitet är den mest kostnadseffektiva när det gäller energianvändning, är ett flertrådat system mer dynamiskt när systemet inte körs på 100%. Orsakerna till denna effektivitet beskrivs i bilaga A.

För att hantera tillfälliga toppar i klientbelastningen rekommenderar vi att fokusera på en CPU under hög belastning mellan 40% och 60% av systemkapaciteten. I det första exemplet i målwebbplatsens beteendeprofil behöver du till exempel mellan 3,33 processorer (60% mål) och 5 processorer (40% mål) för att stödja AD DS-belastningen. Du bör lägga till extra kapacitet enligt kraven i operativsystemet och andra nödvändiga agenter, till exempel antivirusprogram, säkerhetskopiering, övervakning och så vidare. Planera att reservera 5–10% av en processorkapacitet för infrastrukturagenter (antivirus, säkerhetskopiering, övervakning). Mät den faktiska agentanvändningen i din miljö och justera efter behov. För att gå tillbaka till vårt exempel behöver vi mellan 3,43 (60% mål) och 5,1 (40% mål) processorer för att stödja belastning under perioder med hög belastning.

Nu ska vi ta en titt på ett exempel på beräkning för en specifik process. I det här fallet tittar vi på LSASS-processen.

Beräkna CPU-användning för LSASS-processen

I det här exemplet är systemet ett N + 1-scenario där en server utför AD DS-belastningen medan en extra server finns där för redundans.

Följande diagram visar processortiden för LSASS-processen för alla processorer i det här exempelscenariot. Dessa datapunkter kommer från prestandaräknaren Process(lsass)\% Processor Time .

Här är vad tidsdiagrammet för LSASS-processorn visar om scenariomiljön:

• Det finns tre domänkontrollanter på webbplatsen.
• Arbetsdagen börjar rampa upp runt 07:00 och ramper sedan ner klockan 17:00.
• Den mest trafikerade perioden på dagen är från 09:30 till 11:00.

  Note

  Alla prestandadata är historiska. Den högsta datapunkten klockan 09:15 anger belastningen från 09:00 till 09:15.

• Toppar före 07:00 kan tyda på extra belastning från olika tidszoner eller bakgrundsaktivitet i infrastrukturen, till exempel säkerhetskopiering. Men eftersom denna topp är lägre än toppaktiviteten kl. 09:30 är det inte en anledning till oro.

Vid maximal belastning förbrukar LSASS-processen cirka 4,85 processorer som körs vid 100%, vilket skulle vara 485% på en enda PROCESSOR. Dessa resultat tyder på att scenarioplatsen behöver cirka 12/25 processorer för att hantera AD DS. När du tar in de rekommenderade 5% till 10% extra kapacitet för bakgrundsprocesser behöver servern 12,30 till 12,25 processorer för att stödja den aktuella belastningen. Uppskattningar som förutser framtida tillväxt gör detta antal ännu högre.

När LDAP-vikter ska justeras

Det finns vissa scenarier där du bör överväga att justera LdapSrvWeight. När det gäller kapacitetsplanering justerar du det när dina program, användarbelastningar eller underliggande systemfunktioner inte är jämnt balanserade.

I följande avsnitt beskrivs två exempelscenarier där du bör justera vikterna för Lightweight Directory Access Protocol (LDAP).

Exempel 1: PDC-emulatormiljö

Om du använder en PDC-emulator (Primary Domain Controller) kan ojämnt distribuerat användar- eller programbeteende påverka flera miljöer samtidigt. PDC-emulatorn har vanligtvis högre CPU-belastning än andra domänkontrollanter. Många verksamheter föredrar eller kontaktar den alltid, exempel inkluderar:

• Hanteringsverktyg för gruppolicy (skapande, redigering, länkning, GPMC-uppdatering)
• Verifiering av lösenordsändring/andra autentiseringsförsök (fallback-lösenordskontroll)
• Förtroendeskapande och underhållsåtgärder
• Tidstjänsthierarki (auktoritativ tidskälla i domänen/skogen)
• Kontoutelåsningsbearbetning
• Äldre eller felkonfigurerade program som fortfarande riktar in sig på PDC-emulatorn

Övervaka processorn separat och planera extra utrymme om dessa aktiviteter är vanliga.

Du bör endast justera PDC-emulatorn om det finns en märkbar skillnad i CPU-användning. Anpassningen bör minska belastningen på PDC-emulatorn och öka belastningen på andra domänkontrollanter, vilket möjliggör en jämnare fördelning av belastningen.

I dessa fall anger du värdet för LDAPSrvWeight mellan 50 och 75 för PDC-emulatorn.

Fångsten är att om PDC-emulatorrollen överförs eller beslagtas, särskilt till en annan domänkontrollant på platsen, ökar processoranvändningen dramatiskt på den nya PDC-emulatorn.

I det här exempelscenariot förutsätter vi att alla tre domänkontrollanterna på den här webbplatsen har fyra processorer baserat på målwebbplatsens beteendeprofil . Under normala förhållanden, vad skulle hända om en av dessa domänkontrollanter hade åtta processorer? Det skulle finnas två domänkontrollanter vid 40% användning och en vid 20% användning. Även om den här konfigurationen inte nödvändigtvis är dålig finns det här en möjlighet att använda LDAP-viktjustering för att balansera belastningen bättre.

Exempel 2: miljö med olika cpu-antal

När du har servrar med olika cpu-antal och hastigheter på samma plats måste du se till att de är jämnt fördelade. Om din webbplats till exempel har två servrar med åtta kärnor och en server med fyra kärnor har fyrakärnsservern bara hälften av bearbetningskraften för de andra två servrarna. Om klientbelastningen är jämnt fördelad innebär det att servern med fyra kärnor måste arbeta dubbelt så hårt som de två servrarna med åtta kärnor för att hantera processorbelastningen. Dessutom blir fyrakärnsservern överbelastad om en av servrarna med åtta kärnor går offline.

Det är viktigt att planera för ett N + 1-scenario. Effekten av ett datacenter som blir otillgängligt måste beräknas för varje scenario. I föregående exempel delas belastningen jämnt mellan alla servrar. I ett N-scenario (en server förlorade) ligger varje återstående server kvar på cirka 60%. Den aktuella fördelningen är acceptabel eftersom förhållandet förblir konsekvent. När du tittar på PDC-emulatorns justeringsscenario, eller ett allmänt scenario där användar- eller programbelastningen är obalanserad, är effekten annorlunda:

Virtualiseringsöverväganden för bearbetning

När du planerar kapacitet för en virtualiserad miljö finns det två nivåer som du måste tänka på: värdnivån och gästnivån. På värdnivå måste du identifiera toppperioderna i din affärscykel. Eftersom schemaläggning av gästtrådar på processorn för en virtuell dator liknar att få AD DS-trådar på processorn för en fysisk dator, rekommenderar vi ändå att du använder 40% till 60% av den underliggande värden. På gästnivå, eftersom principerna för underliggande trådschemaläggning är oförändrade, rekommenderar vi fortfarande att du behåller CPU-användningen inom intervallet 40% till 60%.

För en direktmappad installation (en gäst per värd) återanvänder du kapacitetsplaneringsnumren som samlats in tidigare. Använd dem direkt för att storleksanpassa den här distributionen.

I ett scenario med delad värd kan du anta ungefär 10% processorbelastning till följd av virtualisering. Om webbplatsen behöver 10 CPU:er med 40% målanvändning på fysisk hårdvara, lägg till ytterligare en CPU för den här overheaden. Allokera totalt 11 virtuella processorer (vCPU:er) över N-gästdomänkontrollanterna.

På platser med blandade distributioner av fysiska och virtuella servrar gäller den här virtualiseringskostnaden endast för de virtuella datorerna (VM). I en N + 1-design motsvarar en fysisk server med 10 processorer (eller direktmappad) ungefär ett virtuellt datacenter med 11 vCPU:er (virtuella CPU:er). Värden behöver också ytterligare 11 processorer reserverade för den virtuella datorn.

Medan du analyserar och beräknar hur många processorer du behöver för att stödja AD DS-belastning. Tänk på att om du planerar att köpa fysisk maskinvara kanske inte de typer av maskinvara som är tillgängliga på marknaden mappas exakt till dina uppskattningar. Du har dock inte det problemet när du använder virtualisering. Att använda virtuella datorer minskar den ansträngning som krävs för att lägga till beräkningskapacitet på en plats, eftersom du kan lägga till så många processorer med de exakta specifikationer som du vill ha för en virtuell dator. Virtualisering eliminerar dock inte ditt ansvar för att korrekt utvärdera hur mycket beräkningskraft du behöver för att garantera att den underliggande maskinvaran är tillgänglig när gäster behöver mer CPU-resurser. Planera alltid framåt för tillväxt.

Sammanfattningsexempel för virtualiseringsberäkning

Om du beräknar 50% efterfrågetillväxt under tre år planerar du för 18,375 processorer (12,25 × 1,5) vid den tidpunkten. Du kan också granska efterfrågan efter det första året och sedan lägga till extra kapacitet baserat på vad resultatet visar.

Klientautentiseringslast för övergripande förtroende för NTLM

Utvärdera belastningen för klientautentisering mellan betrodda klienter

Många miljöer kan ha en eller flera domäner som är anslutna via ett förtroende. Autentiseringsbegäranden för identiteter i andra domäner som inte använder Kerberos måste passera ett förtroende med hjälp av en säker kanal mellan två domänkontrollanter. Användarens domänkontrollant kontaktar en domänkontrollant i måldomänen eller nästa längs förtroendevägen mot domänen. Inställningen *MaxConcurrentAPI styr hur många anrop domänkontrollanten kan göra till den andra domänkontrollanten i den betrodda domänen. För att säkerställa att den säkra kanalen kan hantera den belastning som krävs för att domänkontrollanterna ska kunna kommunicera med varandra kan du antingen finjustera MaxConcurrentAPI eller, om du befinner dig i en skog, skapa genvägsförtroenden. Läs mer om hur du avgör trafikvolym mellan förtroenden i Så här gör du prestandajustering för NTLM-autentisering med hjälp av inställningen MaxConcurrentApi.

Precis som i tidigare scenarier måste du samla in data under de mest upptagna perioderna på dagen för att det ska vara användbart.

Virtualiseringsplanering

Det finns några saker du bör tänka på när du planerar kapacitet för virtualisering:

• Många program använder NTLM-autentisering som standard eller i vissa konfigurationer.
• I takt med att antalet aktiva klienter ökar så ökar även behovet av att programservrar har mer kapacitet.
• Klienter håller ibland sessioner öppna under en begränsad tid och återansluter i stället regelbundet för tjänster som synkronisering av e-posthämtning.
• Webbproxyservrar som kräver autentisering för Internetåtkomst kan orsaka hög NTLM-belastning.

Dessa program kan skapa en stor belastning för NTLM-autentisering, vilket belastar domänkontrollanterna avsevärt, särskilt när användare och resurser finns i olika domäner.

Det finns många metoder som du kan använda för att hantera belastning mellan förtroenden, som du ofta kan och bör använda tillsammans på samma gång:

• Minska klientautentisering över domängränser genom att lokalisera de tjänster som en användare förbrukar inom den domän där de befinner sig.
• Öka antalet tillgängliga säkra kanaler. Dessa kanaler kallas genvägsförtroenden och är relevanta för trafik mellan skogar och skogar.
• Justera standardinställningarna för MaxConcurrentAPI.

Om du vill finjustera MaxConcurrentAPI på en befintlig server använder du följande ekvation:

New_MaxConcurrentApi_setting ≥ (semaphore_acquires + semaphore_time) × average_semaphore_hold_time ÷ time_collection_length

Mer information finns i KB-artikeln 2688798: Så här gör du prestandajustering för NTLM-autentisering med inställningen MaxConcurrentApi.

Virtualiseringsöverväganden

Det finns inga särskilda överväganden som du behöver göra, eftersom virtualisering är en inställning för operativsystemets justering.

Exempel på beräkning av virtualiseringsjustering

För det här systemet för den här tidsperioden är standardvärdena acceptabla.

Övervakning för efterlevnad av kapacitetsplaneringsmål

I den här artikeln diskuterade vi hur planering och skalning går mot användningsmål. I följande tabell sammanfattas de rekommenderade tröskelvärdena som du måste övervaka för att säkerställa att systemen fungerar som avsett. Tänk på att detta inte är prestandatrösklar, bara trösklar för kapacitetsplanering. En server som arbetar över dessa tröskelvärden fungerar fortfarande, men du måste verifiera att dina program fungerar som de ska innan du börjar se prestandaproblem när användarefterfrågan ökar. Om programmen är okej bör du börja utvärdera maskinvaruuppgraderingar eller andra konfigurationsändringar.

Bilaga A: Kriterier för cpu-storleksändring

I den här bilagan beskrivs användbara termer och begrepp som kan hjälpa dig att uppskatta miljöns behov av CPU-storlek.

Definitioner: CPU-storleksändring

• En processor (mikroprocessor) är en komponent som läser och kör programinstruktioner.

• En processor med flera kärnor har flera processorer på samma integrerade krets.

• Ett system med flera processorer har flera processorer som inte finns på samma integrerade krets.

• En logisk processor är en processor som bara har en logisk beräkningsmotor ur operativsystemets perspektiv.

Dessa definitioner omfattar hypertrådad, en kärna på processor med flera kärnor eller en processor med en enda kärna.

Eftersom dagens serversystem har flera processorer, flera processorer med flera kärnor och hypertrådning generaliseras dessa definitioner för att täcka båda scenarierna. Vi använder termen logisk processor eftersom den representerar operativsystemet och programperspektivet för de tillgängliga beräkningsmotorerna.

Parallellitet på trådnivå

Varje tråd är en oberoende uppgift eftersom varje tråd har en egen stack och instruktioner. AD DS kan skalas bra över flera logiska processorer eftersom det är flertrådat och kan justeras antalet tillgängliga trådar. Om du vill veta mer om att justera tillgängliga trådar följer du anvisningarna i Visa och ange LDAP-princip i Active Directory med hjälp av Ntdsutil.exe.

Parallellitet på datanivå

Parallellitet på datanivå är när en tjänst delar data i många trådar för samma process och delar många trådar i flera processer. Enbart AD DS-processen skulle räknas som en tjänst som delar data över flera trådar för en enda process. Alla ändringar av data återspeglas i alla trådar som körs på alla nivåer i cacheminnet, varje kärna och eventuella uppdateringar av det delade minnet. Prestanda kan försämras under skrivåtgärder eftersom alla minnesplatser justeras till ändringarna innan instruktionsbearbetningen kan fortsätta.

Cpu-hastighet jämfört med överväganden med flera kärnor

Snabbare logiska processorer förkortar den tid som en enskild tråd behöver för att slutföra sitt arbete. Om du lägger till fler logiska processorer ökar antalet trådar som kan köras parallellt. Skalning är dock icke-linjär på grund av minnesfördröjning, delad resurskonkurring, synkronisering/låsning, seriekodsökvägar och schemaläggningskostnader. Därför är skalbarheten i system med flera kärnor inte linjär.

Användningen skalas icke-linjärt eftersom flera begränsningar interagerar:

• En enda körbar tråd slutförs snabbare på en snabbare kärna. Att lägga till fler inaktiva kärnor ger ingen fördel om det inte finns en körbar parallell arbetsbelastning.
• När en tråd stannar på en cachemiss eller behöver data från huvudminnet kan den inte gå framåt förrän data returneras. Snabbare kärnor eliminerar inte minnesfördröjning. de kan vänta längre i förhållande till sin cykelfrekvens.
• I takt med att samtidigheten (körningsbara trådar) ökar, förbrukar synkronisering, cachekoherenstrafik, låskonkurrens och schemaläggningskostnader en större procentandel av de totala cyklerna.
• Bredare system (fler socketar/kärnor) förstärker latenseffekter för operationer som kräver global ordningsföljd (till exempel modifikation av delade data, TLB-shootdowns, avbrott mellan processorer).
• Vissa kodsökvägar är seriella (Amdahls lag). När parallella regioner är mättade bidrar extra kärnor med minskande avkastning.

Att lägga till kärnor eller frekvensen förbättrar därför bara AD DS-dataflödet när arbetsbelastningen har tillräckligt med körbart, parallelliserbart arbete och inte huvudsakligen stoppas på grund av minnes-, lagrings- eller låskonkurrens.

Sammanfattningsvis blir frågor om huruvida du bör lägga till fler eller snabbare processorer mycket subjektiva och bör övervägas från fall till fall. I synnerhet för AD DS beror bearbetningsbehoven på miljöfaktorer och kan variera från server till server i en enda miljö. Därför investerade de tidigare avsnitten i den här artikeln inte särskilt mycket på att göra super exakta beräkningar. När du fattar budgetdrivna köpbeslut rekommenderar vi att du först optimerar processoranvändningen på antingen 40% eller det nummer som din specifika miljö kräver. Om systemet inte är optimerat drar du inte lika mycket nytta av att köpa fler processorer.

Svarstid och hur systemaktivitetsnivåer påverkar prestanda

Köteori är en matematisk studie av köer eller köer. I köteorin för databehandling representeras användningslagen av t-ekvationen:

U k = B ÷ T

Där U k är användningsprocenten är B den tid som ägnas åt att vara upptagen och T är den totala tid som ägnas åt att observera systemet. I en Microsoft-kontext innebär detta antalet intervalltrådar på 100 nanosekunder (ns) som är i ett körningstillstånd dividerat med hur många intervall på 100 ns som var tillgängliga under det angivna tidsintervallet. Det här är samma formel som beräknar procentandelen processoranvändning som visas i processorobjektet och PERF_100NSEC_TIMER_INV.

Köteorin innehåller också formeln: N = U k ÷ (1 – U k) för att uppskatta antalet väntande objekt baserat på användning, där N är köns längd. När du kartlägger den här ekvationen över alla användningsintervall får du följande uppskattningar av hur länge kön som ska komma på processorn är vid en given CPU-belastning.

Baserat på den här uppskattningen kan vi observera att efter 50% CPU-last brukar den genomsnittliga väntetiden omfatta ytterligare ett objekt i kön och ökar snabbt till en CPU-användning på 70%.

För att förstå hur köteorin gäller för din AD DS-distribution ska vi gå tillbaka till huvudvägsmetaforen som vi använde i cpu-hastighet jämfört med överväganden med flera kärnor.

Livligare tider i mitten av eftermiddagen skulle falla någonstans i 40% till 70% kapacitetsintervall. Det finns tillräckligt med utrymme i trafiken så att din förmåga att välja körfält inte är allvarligt begränsad. Även om chansen för en annan förare att komma i vägen är hög, kräver det inte samma ansträngningsnivå som du skulle behöva för att hitta en säker lucka mellan andra bilar i körfältet som under rusningstid.

När rusningstrafik närmar sig närmar sig vägsystemet 100% kapacitet. Att byta körfält under rusningstid blir mycket utmanande eftersom bilar är så nära varandra att du inte har lika mycket utrymme att manövrera när du byter körfält. Köbeteendet förklarar det långsiktiga genomsnittliga kapacitetsmålet på 40%. Att hålla den genomsnittliga användningen nära 40% lämnar utrymme för korta toppar (till exempel långsamma eller dåligt kodade frågor) och större burst-händelser (till exempel ökningen morgonen efter en semester).

I föregående uttalande anses procentandelen processortidsberäkning vara densamma som användningslagsekvationen. Den här förenklade versionen är avsedd att introducera konceptet för nya användare. För mer avancerad matematik kan du dock använda följande referenser som en guide:

• Översätta PERF_100NSEC_TIMER_INV
  • B = Antalet intervall på 100 ns som inaktiv tråd spenderar på den logiska processorn. Ändringen i X-variabeln i PERF_100NSEC_TIMER_INV-beräkningen
  • T = det totala antalet intervall på 100 ns inom ett angivet tidsintervall. Ändringen i Y-variabeln i PERF_100NSEC_TIMER_INV-beräkningen .
  • U k = Användningsprocenten för den logiska processorn av den inaktiva tråden eller % inaktiv tid.
• Räkna ut matematiken:
  • U k = 1 – %Processor tid
  • %Processoranvändning = 1 – U k
  • %Processor Time = 1 – B / T
  • %Processor Time = 1 – X1 – X0 / Y1 – Y0

Tillämpa dessa begrepp på kapacitetsplanering

Matematiken i föregående avsnitt gör förmodligen att det verkar komplext att avgöra hur många logiska processorer du behöver i ett system. Därför bör din metod för att storleksanpassa systemet fokusera på att fastställa maximal målanvändning baserat på aktuell belastning och sedan beräkna antalet logiska processorer som du behöver för att nå det målet. Dessutom behöver din uppskattning inte vara helt exakt. Även om logiska processorhastigheter har en betydande inverkan på synkroniseringen kan andra områden också påverka prestanda, till exempel:

• Cacheeffektivitet
• Krav på minnessammanhållning
• Trådschemaläggning och synkronisering
• Ofullständigt balanserade klientbelastningar

Eftersom beräkningskraften är relativt låg är det inte värt att investera för mycket tid för att beräkna det helt exakta antalet processorer som du behöver.

Det är också viktigt att komma ihåg att rekommendationen 40% i det här fallet inte är ett obligatoriskt krav. Vi använder det som en rimlig start för att göra beräkningar. Olika typer av AD-användare behöver olika nivåer av svarstider. Vissa miljöer kan i genomsnitt ha 80%–90% CPU och fortfarande uppfylla användarnas förväntningar om köväntetiderna inte ökar märkbart. Behandla detta som ett undantag, validera med svarstidsdata och övervaka noggrant för framväxande konkurrens.

Andra delar av systemet är långsammare än processorn. Finjustera dem också. Fokusera på RAM-åtkomst, diskåtkomst och svarstid för nätverk. Till exempel:

• Om du lägger till processorer i ett system som körs med 90% användning, som är diskbunden, kommer det förmodligen inte att förbättra prestandan nämnvärt. Om du tittar närmare på systemet finns det många trådar som inte ens kommer åt processorn eftersom de väntar på att I/O-åtgärder ska slutföras.

• Att lösa diskbundna problem kan innebära att trådar som tidigare fastnat i väntetillstånd slutar fastna, vilket skapar mer konkurrens om CPU-tid. Därför går 90-%-användningen till 100%. Du måste justera båda komponenterna för att få tillbaka användningen till hanterbara nivåer.

  Note

  Räknaren Processor Information(*)\% Processor Utility kan överskrida 100% med system som har Turbo-läge. Med turboläge kan processorn överskrida den nominella processorhastigheten under korta perioder. Om du behöver mer information bör du titta på CPU-tillverkarnas dokumentation och räknebeskrivningar.

Att diskutera överväganden för användning i hela systemet omfattar även domänkontrollanter som virtualiserade gäster. Svarstid och hur systemaktivitetsnivåer påverkar prestanda gäller för både värd och gäst i ett virtualiserat scenario. I en värd med endast en gäst har en domänkontrollant eller ett system nästan samma prestanda som det har på fysisk hårdvara. När man lägger till fler gäster till värdarna ökar användningen av den grundläggande värden, vilket också ökar väntetiderna för att få tillgång till processorerna. Därför måste du hantera logisk processoranvändning på både värd- och gästnivå.

Låt oss gå tillbaka till motorvägsmetaforen från föregående avsnitt, men den här gången föreställer vi oss den virtuella gästdatorn som en expressbuss. Expressbussar, i motsats till kollektivtrafik eller skolbussar, går direkt till ryttarens destination utan att göra några stopp.

Nu ska vi tänka oss fyra scenarier:

• Ett systems lågtrafiktimmar är som att åka expressbuss sent på natten. När cyklisten sätter sig på finns det nästan inga andra passagerare och vägen är nästan tom. Eftersom det inte finns någon trafik för bussen att kämpa med, är resan lätt och lika snabb som om ryttaren hade kört dit i sin egen bil. Den lokala hastighetsgränsen kan dock begränsa förarens restid.
• I lågtrafiktider, när användningen av ett systems CPU är för hög, är det som en sen nattur när de flesta körfälten på motorvägen är stängda. Även om bussen själv är mestadels tom är vägen fortfarande överbelastad på grund av kvarvarande trafik som hanterar de begränsade körfälten. Medan ryttaren är fri att sitta var de vill, bestäms deras faktiska restid av trafiken utanför bussen.
• Ett system med hög CPU-användning under hög belastning är som en fullsatt buss under rusningstid. Resan tar inte bara längre tid, utan det är svårare att komma på och av bussen eftersom bussen är full av andra passagerare. Att lägga till fler logiska processorer i gästsystemet för att försöka påskynda väntetiderna skulle vara som att försöka lösa trafikproblemet genom att lägga till fler bussar. Problemet är inte antalet bussar, utan hur lång tid resan tar.
• Ett system med hög CPU-användning under lågtrafik är som samma trånga buss på en mestadels tom väg på natten. Även om cyklister kan ha problem med att hitta platser eller komma på och av bussen, är resan ganska smidig när bussen plockar upp alla sina passagerare. Det här scenariot är det enda där prestandan skulle förbättras genom att lägga till fler bussar.

Baserat på föregående exempel kan du se att det finns många scenarier mellan 0% och 100% användning som har varierande prestandapåverkan. Att lägga till fler logiska processorer förbättrar inte nödvändigtvis prestandan utanför specifika scenarier. Det bör vara ganska enkelt att tillämpa dessa principer på det rekommenderade målet för 40% CPU-användning för värdar och gäster.

Bilaga B: Överväganden gällande olika processorhastigheter

I Bearbetning antog vi att processorn körs med 100% klockfrekvens medan du samlar in data och att eventuella ersättningssystem har samma bearbetningshastighet. Trots att dessa antaganden inte är korrekta, särskilt för Windows Server 2008 R2 och senare, där standardkraftplanen är Balanserad, fungerar dessa antaganden fortfarande för konservativa uppskattningar. Även om potentiella fel kan öka ökar det bara säkerhetsmarginalen när processorhastigheterna ökar.

• I ett scenario som till exempel kräver 11,25 processorer, skulle den mer exakta uppskattningen av deras efterfrågan vara 5,125 ÷ 2 om processorerna kördes i halv hastighet när du samlade in dina data.
• Det är omöjligt att garantera att en fördubbling av klockhastigheten fördubblar mängden bearbetning som sker inom den registrerade tidsperioden. Den tid som processorer lägger på att vänta på RAM-minne eller andra komponenter förblir ungefär densamma. Därför kan snabbare processorer ägna mer tid åt att vara inaktiva medan de väntar på att systemet ska hämta data. Vi rekommenderar att du håller dig till den lägsta gemensamma nämnaren, håller dina uppskattningar konservativa och undviker att anta en linjär jämförelse mellan processorhastigheter som kan göra dina resultat felaktiga.

Om processorhastigheterna i ersättningsmaskinvaran är lägre än den aktuella maskinvaran bör du proportionellt öka uppskattningen av hur många processorer du behöver. Låt oss till exempel titta på ett scenario där du beräknar att du behöver 10 processorer för att upprätthålla webbplatsens belastning. De aktuella processorerna körs på 3,3 GHz och de processorer som du planerar att ersätta dem med körs på 2,6 GHz. Om du bara ersätter de 10 ursprungliga processorerna får du 21% hastighetsminskning. För att öka hastigheten måste du skaffa minst 12 processorer i stället för 10.

Den här variabiliteten ändrar dock inte kapacitetshanteringsprocessorns användningsmål. Hastigheterna för processorklockan justeras dynamiskt baserat på belastningsefterfrågan, så om systemet körs under högre belastning kan processorn tillbringa mer tid i ett högre klockhastighetstillstånd. Det ultimata målet är att processorn ska vara på 40 %% användning i ett 100% klockhastighetstillstånd under arbetsdagens högst belastade timmar. Allt mindre genererar energibesparingar genom att begränsa processorhastigheter under låg belastningsscenarier.

Om du vill justera uppskattningar för olika processorer rekommenderar vi att du använder SPECint_rate2006 benchmark från Standard Performance Evaluation Corporation. Så här använder du det här riktmärket:

1. Gå till Standard Performance Evaluation Corporation (SPEC) webbplatsen.

2. Välj Resultat.

3. Ange CPU2006 och välj Sök.

4. I den nedrullningsbara menyn för Tillgängliga konfigurationer väljer du Alla SPEC-CPU2006.

5. I fältet Sökformulärbegäran väljer du Enkelt och sedan Go!.

6. Under Enkel begäran anger du sökvillkoren för målprocessorn. Om du till exempel letar efter en E5-2630-processor går du till den nedrullningsbara menyn och väljer Processor och anger sedan processornamnet i sökfältet. När du är klar väljer du Kör enkel hämtning.

7. Leta efter server- och processorkonfigurationen i sökresultaten. Om sökmotorn inte returnerar en exakt matchning letar du efter den närmaste möjliga matchningen.

8. Registrera värdena i kolumnerna Resultat och # Kärnor .

9. Fastställ modifieraren med hjälp av den här ekvationen:

   ((Poängvärde per kärna på målplattformen) × (MHz per kärna på baslinjeplattformen)) ÷ ((Poängvärde per kärna på baslinjeplattformen) × (MHz per kärna på målplattformen))

   Så här hittar du till exempel modifieraren för en E5-2630-processor:

   (35,83 × 2000) ÷ (33,75 × 2300) = 0,92

10. Multiplicera antalet processorer som du uppskattar att du behöver med den här modifieraren.

    I exemplet med E5-2630-processorn 0,92 × 10,3 = 10,35 processorer.

Bilaga C: Hur operativsystemet interagerar med lagring

De begrepp för köteori som vi diskuterade i Svarstid och hur systemaktivitetsnivåer påverkar prestanda gäller även för lagring. Du måste känna till hur operativsystemet hanterar I/O för att kunna tillämpa dessa begrepp på ett effektivt sätt. I Windows-operativsystem skapar systemet en kö som innehåller I/O-begäranden för varje fysisk disk. En fysisk disk är dock inte nödvändigtvis en enda disk. Operativsystemet kan också registrera en aggregering av spindlar på en matrisstyrenhet eller SAN som en fysisk disk. Matriskontrollanter och SAN kan också aggregera flera diskar i en enskild matrisuppsättning, dela upp den i flera partitioner och sedan använda varje partition som en fysisk disk, enligt följande bild.

I den här bilden speglas de två spindlarna och delas upp i logiska områden för datalagring, märkta Data 1 och Data 2. Operativsystemet registrerar var och en av dessa logiska områden som separata fysiska diskar.

Nu har vi förtydligat vad som definierar en fysisk disk. Följande termer kan hjälpa dig att bättre förstå informationen i den här bilagan.

• En spindel är den enhet som är fysiskt installerad på servern.
• En matris är en samling spindlar aggregerade av kontrollanten.
• En matrispartition är en partitionering av den aggregerade matrisen.
• Ett LUN (Logical Unit Number) är en matris med SCSI-enheter som är anslutna till en dator. Den här artikeln använder dessa termer när du pratar om SAN.
• En disk innehåller alla spindle eller partitioner som operativsystemet registrerar som en enda fysisk disk.
• En partition är en logisk partitionering av vad operativsystemet registrerar som en fysisk disk.

Arkitekturöverväganden för operativsystem

Operativsystemet skapar en I/O-kö (First In, First Out) för varje disk som registreras. Dessa diskar kan vara spindlar, matriser eller matrispartitioner. När det gäller hur operativsystemet hanterar I/O, desto mer aktiva köer, desto bättre. När operativsystemet serialiserar FIFO-kön måste det bearbeta alla FIFO I/O-begäranden som utfärdats till lagringsundersystemet i ankomstordning. Genom att behålla en separat I/O-kö för varje spindel eller matris förhindrar operativsystemet diskar från att konkurrera om samma knappa I/O-resurser och håller aktiviteten isolerad till endast de diskar som är inblandade. Windows Server 2008 introducerade dock ett undantag i form av I/O-prioritering. Applikationer som är utformade för att använda I/O med låg prioritet flyttas till baksidan av kön oavsett när operativsystemet tog emot dem. Program som inte är kodade för att använda inställningen låg prioritet kommer istället att använda normal prioritet som standard.

Introduktion till enkla lagringsundersystem

I det här avsnittet pratar vi om enkla lagringsundersystem. Låt oss börja med ett exempel: en enda hårddisk inuti en dator. Om vi delar upp det här systemet i de viktigaste komponenterna i undersystemet för lagring får vi följande:

• En ultrasnabb SCSI HD på 10 000 RPM (Ultrasnabb SCSI har en överföringshastighet på 20 Mbit/s)
• En SCSI-buss (själva kabeln)
• En ultrasnabb SCSI-adapter
• En 32-bit 33 MHz PCI-buss

När du har identifierat komponenterna kan du börja få en uppfattning om hur mycket data systemet kan överföra och hur mycket I/O det kan hantera. Mängden I/O och mängden data som kan överföra systemet är relaterade till varandra, men inte samma värde. Den här korrelationen beror på blockstorleken och om diskens I/O är slumpmässig eller sekventiell. Systemet skriver alla data till disken som ett block, men olika program kan använda olika blockstorlekar.

Nu ska vi analysera dessa objekt på komponent-för-komponent-basis.

Åtkomsttider för hårddiskar

Den genomsnittliga hårddisken på 10 000 RPM har en söktid på 7 ms och en åtkomsttid på 3 ms. Söktiden är den genomsnittliga tid det tar för läs- eller skrivhuvudet att flytta till en plats på tallriken. Åtkomsttiden är den genomsnittliga tid det tar för huvudet att läsa eller skriva data till disken när det är på rätt plats. Den genomsnittliga tiden för att läsa ett unikt datablock i en HD med 10 000 RPM inkluderar därför både sök- och åtkomsttider för totalt cirka 10 ms, eller 0,010 sekunder, per datablock.

När varje diskåtkomst kräver att huvudet flyttas till en ny plats på disken kallas läs- eller skrivbeteendet slumpmässigt. När all I/O är slumpmässig kan en HD på 10 000 RPM hantera cirka 100 I/O per sekund (IOPS).

När alla I/O inträffar från angränsande sektorer på hårddisken kallar vi det sekventiell I/O. Sekventiell I/O lägger inte till någon extra söktid. När den första I/O har slutförts är läs-/skrivhuvudet redan placerat vid nästa datablock. Till exempel kan en HD med 10 000 RPM hantera cirka 333 I/O per sekund, baserat på följande ekvation:

1 000 ms per sekund ÷ 3 ms per I/O

Hittills har överföringshastigheten för hårddisken inte varit relevant för vårt exempel. Oavsett hårddiskstorleken är den faktiska mängden IOPS som 10 000 RPM HD kan hantera alltid cirka 100 slumpmässiga eller 300 sekventiella I/Os. När blockstorlekarna ändras baserat på vilket program som skrivs till enheten ändras även mängden data som hämtas per I/O. Om blockstorleken till exempel är 8 KB läser 100 I/O-åtgärder från eller skriver till hårddisken totalt 800 KB. Men om blockstorleken är 32 KB läser eller skriver 100 I/O 3 200 KB (3,2 MB) till hårddisken. Om SCSI-överföringshastigheten överskrider den totala mängden överförda data ändras ingenting om du får en snabbare överföringshastighet. Mer information finns i följande tabeller:

SCSI-bakplanen

Hur SCSI-backplanen, som i det här exemplet är bandkabeln, påverkar dataflödet för lagringsundersystemet beror på blockstorleken. Hur mycket I/O kan bussen hantera om I/O är i block på 8KB? I det här scenariot är SCSI-bussen 20 Mbit/s eller 20480 KB/s. 20480KB/s dividerat med 8 KB-block ger högst cirka 2 500 IOPS som stöds av SCSI-bussen.

Som föregående tabell visar är bussen aldrig en flaskhals i vårt exempelscenario eftersom spindelns maxvärde är 100 I/O, långt under något av de angivna tröskelvärdena.

SCSI-adaptern

För att avgöra hur mycket I/O systemet kan hantera måste du kontrollera tillverkarens specifikationer. Att dirigera I/O-begäranden till rätt enhet kräver bearbetningskraft, så hur mycket I/O systemet kan hantera beror på SCSI-adaptern eller matrisstyrenhetsprocessorn.

I det här exempelscenariot antar vi att systemet kan hantera 1 000 I/O.

PCI-bussen

PCI-bussen är en ofta förbisedd komponent. I det här exempelscenariot är PCI-bussen inte flaskhalsen. Men när systemen skalas upp kan det potentiellt bli en flaskhals i framtiden.

Vi kan se hur mycket en PCI-buss kan överföra data i vårt exempelscenario med hjälp av den här ekvationen:

32 bitar ÷ 8 bitar per byte × 33 MHz = 133 MBIT/s

Därför kan vi anta att en 32-bitars PCI-buss som körs på 33 Mhz kan överföra 133 Mbit/s data.

En 66 MHz 64-bitars PCI-buss kan stödja ett teoretiskt maxvärde på 528 MBIT/s baserat på den här ekvationen:

64 bitar ÷ 8 bitar per byte × 66 Mhz = 528 MBIT/s

Om du lägger till en annan enhet (till exempel ett nätverkskort eller en andra SCSI-styrenhet) minskar den tillgängliga bandbredden för systemet. Alla enheter på bussen delar den bandbredden och varje ny enhet konkurrerar om begränsade bearbetningsresurser.

Analysera lagringsundersystem för att hitta flaskhalsar

I det här scenariot är spindeln den begränsande faktorn för hur mycket I/O du kan begära. Det innebär att den här flaskhalsen också begränsar hur mycket data systemet kan överföra. Eftersom vårt exempel är ett AD DS-scenario är mängden överförbara data 100 slumpmässiga I/O per sekund i steg om 8 KB, totalt 800 KB per sekund när du kommer åt Jet-databasen. Som jämförelse kan en spindel som endast är dedikerad till loggfiler leverera upp till 300 sekventiella 8 KB I/O per sekund. Det motsvarar 2 400 KB (2,4 MB) per sekund.

Nu när vi har analyserat komponenterna i vår exempelkonfiguration ska vi titta på en tabell som visar var flaskhalsar kan inträffa när vi lägger till och ändrar komponenter i lagringsundersystemet.

Introduktion till RAID

När du introducerar en matriskontrollant för ditt lagringsundersystem ändrar den inte dess karaktär dramatiskt. Matrisstyrenheten ersätter bara SCSI-adaptern i beräkningarna. Kostnaden för att läsa och skriva data till disken när du använder de olika matrisnivåerna ändras dock.

I RAID 0 går det att skriva data på alla diskar i RAID-uppsättningen. Under en läs- eller skrivåtgärd hämtar systemet data från eller push-överför dem till varje disk, vilket ökar mängden data som systemet kan överföra under den här tidsperioden. I det här exemplet där vi använder 10 000RPM-enheter kan du därför utföra 100 I/O-åtgärder med RAID 0. Den totala mängden I/O som systemet stöder är N-spindlar gånger 100 1/O per sekund per spindel eller N-spindlar × 100 I/O per sekund per spindel.

I RAID 1 speglar eller duplicerar systemet data över ett par spindlar för redundans. När systemet utför en läs-I/O-åtgärd kan det läsa data från båda spindlarna i uppsättningen. Den här speglingen gör I/O-kapacitet för båda diskarna tillgänglig under en läsåtgärd. RAID 1 ger dock inte skrivåtgärder några prestandafördelar, eftersom systemet också behöver spegla skrivna data på paret av spindlar. Även om spegling inte gör att skrivåtgärder tar längre tid, hindrar det systemet från att utföra mer än en läsåtgärd samtidigt. Därför kostar varje skriv-I/O-åtgärd två läs-I/O-åtgärder.

Följande ekvation beräknar hur många I/O-åtgärder som sker i det här scenariot:

Läs I/O + 2 × Skriv I/O = Totalt tillgängligt disk-I/O förbrukat

När du vet förhållandet mellan läsningar och skrivningar och antalet spindlar i distributionen kan du använda den här ekvationen för att beräkna hur mycket I/O-matrisen kan stödja:

Maximalt antal IOPS per spindel × 2 spindlar × [(% Reads + % Writes) ÷ (% Reads + 2 ×% Writes)] = Total IOPS

Ett scenario med både RAID 1 och RAID 0 fungerar precis som RAID 1 när det gäller läs- och skrivåtgärder. I/O är dock nu randig över varje speglad uppsättning. Det innebär att ekvationen ändras till:

Maximalt antal IOPS per spindel × 2 spindlar × [(% Reads + % Writes) ÷ (% Reads + 2 ×% Writes)] = Total I/O

I en RAID 1-uppsättning blir den totala I/O som matrisen kan bearbeta N × I/O per RAID 1-uppsättning när du stripe N antal RAID 1-uppsättningar:

N × {Maximum IOPS per spindel × 2 spindles × [(% Reads + % Writes) ÷ (% Reads + 2 × % Writes)]} = Total IOPS

sv-SE: Vi kallar ibland RAID 5 N + 1 RAID eftersom systemet sprider data över N spindlar och skriver paritetsinformation till den +1 spindeln. RAID 5 använder dock fler resurser när du utför ett skriv-I/O än RAID 1 eller RAID 1 + 0. RAID 5 utför följande process varje gång operativsystemet skickar en skriv-I/O till matrisen:

1. Läs gamla data.
2. Läs den gamla pariteten.
3. Skriv nya data.
4. Skriv den nya pariteten.

Varje skriv-I/O-begäran som operativsystemet skickar till matrisstyrenheten kräver fyra I/O-åtgärder för att slutföras. Därför tar N + 1 RAID-skrivbegäranden fyra gånger så lång tid som läs-I/O slutförs. För att avgöra hur många I/O-begäranden från operativsystemet som översätts till hur många begäranden spindlarna får använder du den här ekvationen:

Läs I/O + 4 × Skriva I/O = Totalt I/O

För RAID 1, när du känner till förhållandet mellan läsning och skrivning och antalet spindlar, kan du använda följande ekvation för att uppskatta den totala I/O som stöds för matrisen:

IOPS per spindel × (Spindles – 1) × [(% Reads + % Writes) ÷ (% Reads + 4 × % Writes)] = Total IOPS

Introduktion till SAN

När du introducerar ett san-nätverk (Storage Area Network) i din miljö påverkar det inte de planeringsprinciper som vi har beskrivit i de tidigare avsnitten. Du bör dock ta hänsyn till att SAN kan ändra I/O-beteendet för alla system som är anslutna till det. Ett SAN lägger till redundans jämfört med intern eller direktansluten lagring. Du måste fortfarande planera för feltolerans. Utgå ifrån att en eller flera sökvägar, styrenheter eller hyllor kan misslyckas utan att påverka resten över den avsedda nyttjandegraden. När du introducerar fler komponenter i systemet måste du också ta med dessa nya delar i dina beräkningar.

Nu ska vi dela upp ett SAN i dess komponenter:

• SCSI- eller Fibre Channel-hårddisken
• Backplan för lagringsenhetskanalen
• Själva lagringsenheterna
• Modulen för lagringsstyrenhet
• En eller flera SAN-växlar
• En eller flera värdbusskort (HBAs)
• PCI-bussen

När du utformar ett system för redundans måste du inkludera extra komponenter för att säkerställa att systemet fortsätter att fungera under ett krisscenario där en eller flera av de ursprungliga komponenterna slutar fungera. Men när du planerar kapaciteten måste du undanta redundanta komponenter från tillgängliga resurser för att få en korrekt uppskattning av systemets baslinjekapacitet, eftersom dessa komponenter vanligtvis inte är online om det inte uppstår en nödsituation. Om ditt SAN till exempel har två styrenhetsmoduler behöver du bara använda en när du beräknar totalt tillgängligt I/O-dataflöde, eftersom den andra inte aktiveras om inte den ursprungliga modulen slutar fungera. Du bör inte heller ta med den redundanta SAN-växeln, lagringsenheten eller spindlarna i I/O-beräkningar.

Eftersom kapacitetsplaneringen endast tar hänsyn till perioder med hög användning bör du inte heller dela in redundanta komponenter i dina tillgängliga resurser. Den högsta användningen får inte överstiga 80% gränsvärde för systemets kapacitet för att möjliggöra plötsliga ökningar eller annorlunda systembeteende.

När du analyserar beteendet för SCSI- eller Fibre Channel-hårddisken bör du analysera den enligt de principer som vi beskrev i föregående avsnitt. Trots att varje protokoll har sina egna fördelar och nackdelar är det viktigaste som begränsar prestanda per disk de mekaniska begränsningarna på hårddisken.

När du analyserar kanalen på lagringsenheten bör du använda samma metod. Du gjorde det när du beräknade hur många resurser som var tillgängliga på SCSI-bussen: dividera bandbredden med blockstorleken. Om lagringsenheten till exempel har sex kanaler som var och en har stöd för en maximal överföringshastighet på 20 Mbit/s är den totala mängden tillgänglig I/O och dataöverföring 100 Mbit/s. Sex kanaler på 20MBps ger varsin teoretisk 120 Mbit/s. Vi har ett tak för planerat dataflöde på 100 Mbit/s (N+1-design). Om en kanal misslyckas levererar de återstående fem (5 × 20 Mbit/s) fortfarande de nödvändiga 100 Mbit/s. Det här exemplet förutsätter också att systemet distribuerar belastnings- och feltolerans jämnt i alla kanaler.

Om du kan omvandla föregående exempel till en I/O-profil beror på programmets beteende. För Active Directory Jet I/O skulle det maximala värdet vara cirka 12 500 I/O per sekund eller 100 MBIT/s ÷ 8 KB per I/O.

För att förstå hur mycket dataflöde dina styrenhetsmoduler stöder måste du också hämta tillverkarens specifikationer. I det här exemplet har SAN två styrenhetsmoduler som stöder 7 500 I/O vardera. Om du inte använder redundans skulle det totala systemets dataflöde vara 15 000 IOPS. Men i ett scenario där redundans krävs beräknar du det maximala dataflödet baserat på gränserna för endast en av kontrollanterna, vilket är 7 500 IOPS. Förutsatt att blockstorleken är 4 KB är det här tröskelvärdet långt under det maximala IOPS-värdet på 12 500 som lagringskanalerna kan stödja och är därför flaskhalsen i analysen. I planeringssyfte är dock det önskade maximala I/O som du bör planera för 10 400 I/O.

När data lämnar styrenhetsmodulen överför den en Fibre Channel-anslutning som är klassificerad till 1GBps eller 128 MBIT/s. Eftersom den här mängden överskrider den totala bandbredden på 100 Mbit/s i alla lagringsenhetskanaler kommer det inte att flaskhalsa systemet. Endast en av de två Fibre Channel-sökvägarna transporterar trafik under normal drift. den andra sökvägen är reserverad för redundans. Om den aktiva sökvägen misslyckas tar väntelägessökvägen över. Den har tillräckligt med kapacitet för att hantera den fullständiga databelastningen.

Data passerar sedan genom en SAN-växel på väg till servern. Växeln begränsar mängden I/O som den kan hantera eftersom den behöver bearbeta den inkommande begäran och sedan vidarebefordra den till lämplig port. Du kan dock bara veta vad switchgränsen är om du tittar på tillverkarens specifikationer. Om systemet till exempel har två växlar och varje växel kan hantera 10 000 IOPS är det totala dataflödet 20 000 IOPS. Baserat på reglerna för feltolerans är det totala systemets dataflöde 10 000 IOPS om en växel slutar fungera. Under normala omständigheter bör du därför inte överskrida 80% utnyttjande, eller 8 000 I/O.

Slutligen begränsar även den HBA som du installerar på servern hur mycket I/O den kan hantera. Installera fler HBA:er för redundans. När du beräknar kapacitet undantar du det redundanta HBA:et. Planera som om en HBA är offline (N – 1) och dimensionera den totala tillgängliga I/O på en eller flera av de återstående aktiva HBA.

Överväganden för cachelagring

Cacher är en av de komponenter som avsevärt kan påverka den övergripande prestandan inom lagringssystemet. En detaljerad analys av cachelagringsalgoritmer ligger dock utanför omfånget för den här artikeln. Här är i stället en snabb lista över saker du bör känna till om cachelagring på diskundersystem.

• Cachelagring förbättrar I/O för kontinuerlig sekventiell skrivning eftersom den buffrar många mindre skrivåtgärder i större I/O-block. Den arkiverar också processer till lagring i några stora block i stället för många små. Den här optimeringen minskar antalet slumpmässiga och sekventiella I/O-åtgärder, vilket gör fler resurser tillgängliga för andra I/O-åtgärder.
• Cachelagring förbättrar inte kontinuerligt skriv-I/O genomflöde i lagringssystemet eftersom det bara buffrar skrivningar tills spindlar är tillgängliga för att skriva data. När alla tillgängliga I/O från spindlar är mättade av data under långa tidsperioder, fylls cachen upp så småningom. Om du vill tömma cacheminnet måste du ange tillräckligt med I/O för att cachen ska rensas genom att ge extra spindlar eller ge tillräckligt med tid mellan bursts för att systemet ska komma ikapp.
• Större cacheminnen tillåter att mer data buffrar, vilket innebär att cachen kan hantera längre perioder av mättnad.
• I vanliga lagringsundersystem får operativsystemet bättre skrivprestanda med cacheminnen, eftersom systemet bara behöver skriva data till cachen. Men när det underliggande mediet är mättat med I/O-åtgärder fylls cacheminnet upp och skrivprestanda återgår till normal diskhastighet.
• När du cachelagrar läsoperationer är cachen mest användbar när du lagrar data sekventiellt på disken och tillåter att cachen läser i förväg. Att läsa framåt är när cachen omedelbart kan flyttas till nästa sektor som om nästa sektor innehåller de data som systemet begär härnäst.
• När läsningen av I/O är slumpmässig ökar cachelagring på enhetsstyrenheten inte hur mycket data disken kan läsa. Om operativsystemet eller den programbaserade cachestorleken är större än den maskinvarubaserade cachestorleken ändrar inte alla försök att förbättra diskens läshastighet något.
• I Active Directory begränsas cachen endast av mängden RAM-minne som systemet innehåller.

SSD-överväganden

Solid State-enheter (SSD) skiljer sig i grunden från spindlebaserade hårddiskar. SSD:er kan hantera högre volymer av I/O med lägre svarstid. Även om SSD:er kan vara dyra på kostnadsbasis per Gigabyte är de billiga enligt kostnads-per-I/O-basis. Kapacitetsplanering med SSD ställer fortfarande samma grundläggande frågor som med spindlar: hur många IOPS kan de hantera och vilken svarstid har dessa IOPS?

Här följer några saker du bör tänka på när du planerar för SSD:er:

• Både IOPS och svarstid omfattas av tillverkarens design. I vissa fall kan vissa SSD-designer prestera sämre än spindlebaserade tekniker. Verifiera leverantörsspecifikationerna för varje SSD- eller spindelmodell. prestanda och svarstid varierar beroende på design. Behandla inte alla SSD:er eller alla spindlar som lika. Jämför funktioner för IOPS, svarstid, uthållighet, ködjup och funktioner för inbyggd programvara per modell.
• IOPS-typer kan ha olika värden beroende på om de läser eller skriver. AD DS-tjänster är främst läsbaserade och påverkas därför mindre av vilken skrivteknik du använder jämfört med andra programscenarier.
• Skriv uthållighet är antagandet att SSD-celler har en begränsad livslängd och kommer så småningom att slitas ut när du använder dem mycket. För databasenheter bidrar en övervägande läs-I/O-profil till att utöka cellernas skrivtålighet till den punkt där du inte behöver oroa dig särskilt mycket för skrivtåligheten.

Summary

Konkurrens om delad lagring uppstår när flera oberoende arbetsbelastningar konkurrerar om begränsade I/O-åtgärder per sekund (IOPS) och bandbredd på samma underliggande media eller sammanlänkning. Vanliga konfliktkällor är:

• Flera servrar som använder samma SAN LUN
• Flera virtuella datorer vars virtuella diskar finns på samma NAS-volym
• Värdar som har åtkomst till vanliga iSCSI-mål via en delad infrastrukturresurs

När en arbetsbelastning genererar ihållande hög I/O– till exempel säkerhetskopior, fullständiga antivirusgenomsökningar, stora kataloguppräkningar eller massexport- eller importuppgifter – ökar den genomsnittliga svarstiden och svarstiden för läs- och skrivåtgärder för alla konsumenter av den delade resursen. Förhöjd latens minskar direkt AD DS-responsen om NTDS.dit eller logg-I/O måste vänta i enhetsköer.

Rekommenderat reparationsarbetsflöde:

1. Mått: Samla in LogicalDisk(<NTDS Database Drive>)\Avg Disk sec/Read, Avg Disk sec/Write, Reads/sec, Writes/secoch lagringsmatrisstatistik (ködjup, kontrollantanvändning) med 15–60 minuters intervall som täcker topp- och underhållsperioder.

2. Attribut: Identifiera vilken arbetsbelastning som orsakar svarstidstoppar (korrelera med säkerhetskopieringsfönster, antivirusgenomsökningar, batchjobb eller vm-grannaktivitet). Använd mått per LUN/per virtuell dator där det är tillgängligt.

3. Klassificera problemtyp:

   • Kapacitetssaturation (IOPS eller genomströmning konsekvent nära enhets-/kontrollantspecifikationen och svarstiden ökar).
   • Burstinterferens (korta högintensiva uppgifter som ökar svarstidens eftersläpning men inte genomsnittlig resursanvändning).
   • Infrastruktur-chokepoint (överprenumererad HBA, växel, sökvägsredundans som minskar tillgängliga körfält, inaktuell drivrutin/inbyggd programvara, feljusterad flervägsprincip).

4. Akt:

   • Balansera om eller isolera tunga arbetsbelastningar till separata LUN/volymer/lagringsnivåer.
   • Flytta eller schemalägg om säkerhetskopior, fullständiga antivirusgenomsökningar och defragmentering till tider utanför AD DS:s högbelastningstider för autentisering och frågning.
   • Lägg till eller uppgradera lagringskomponenter när den varaktiga användningen förblir hög.
   • Se till att drivrutiner/inbyggd programvara och programvara för flera banor är aktuella och korrekt konfigurerade.
   • Ram med rätt storlek så ofta använda data finns i minnet, vilket minskar läsbelastningen på lagringen.

5. Verifiera: Bekräfta att svarstiden efter ändringen återgår till målet (till exempel 2–6 ms SSD/NVMe, 4–12 ms spindle) och att högsta ködjup förblir inom acceptabla gränser.

Potentiella flaskhalsar som liknar eller förvärrar lagringskonflikten inkluderar överbelastade växlar eller värdbussadaptrar som delar körfält.

Kontrollera och uteslut dessa innan du lägger till fler diskar eller flytta till snabbare media.

Koppla alltid ihop svarstidsdata med kölängd och användning av enhet/kontrollant för att avgöra om du vill optimera, schemalägga om eller skala ut.

Viktiga framgångskriterier:

• Varaktigt Avg Disk sec/Read och Avg Disk sec/Write inom målsvarstidsintervallet under ad DS-belastningen.
• Det finns inga längre perioder där IOPS-platån och svarstiden stiger. Om detta observeras kan det tyda på mättnad.
• Krävande underhållsuppgifter utförs under definierade underhållsperioder utan att överskrida produktionsfördröjningar över tröskelvärdena.

Om målen inte uppfylls efter schemaläggning och konfigurationsjusteringar fortsätter du till kapacitetsexpansion eller migrering till lagringsnivåer med högre prestanda.

Bilaga D: felsökning av lagring i miljöer där mer RAM-minne inte är ett alternativ

Många lagringsrekommendationer innan virtualiserad lagring tjänade två syften:

• Isolera I/O för att förhindra prestandaproblem på OS-spindeln från att påverka prestanda för databasen och I/O-profiler.
• Att dra nytta av den prestandaförbättring som traditionella mekaniska hårddiskar och cacheminne kan ge ditt system när de används med sekventiell I/O av AD DS-loggfiler. Att isolera sekventiell I/O till en separat fysisk enhet kan också öka dataflödet.

Med nya lagringsalternativ är många grundläggande antaganden bakom tidigare lagringsrekommendationer inte längre sanna. Virtualiserade lagringsscenarier, till exempel iSCSI-, SAN-, NAS- och Virtual Disk-avbildningsfiler, delar ofta underliggande lagringsmedia mellan flera värdar. Delad lagring negerar antagandena om att du måste isolera I/O och optimera sekventiell I/O. Nu kan andra värdar som har åtkomst till det delade mediet minska svarstiden för domänkontrollanten.

Du bör tänka på följande när du gör kapacitetsplaneringen för lagringsprestanda:

• Tillstånd för kall cache
• Tillstånd för varm cache
• Säkerhetskopiering och återställning

Det kalla cachetillståndet är när du startar om domänkontrollanten eller startar om Active Directory-tjänsten, så det finns inga Active Directory-data i RAM-minnet. Ett varmt cachetillstånd är när domänkontrollanten arbetar i ett stabilt tillstånd och har cachelagrat databasen. När det gäller prestandadesign är uppvärmning av en kall cache som en sprint, medan körning av en server med en helt varm cache är som ett maraton. Det är viktigt att definiera dessa tillstånd och de olika prestandaprofiler som de kör, eftersom du måste tänka på dem båda när du beräknar kapaciteten. Bara för att du till exempel har tillräckligt med RAM-minne för att cachelagra hela databasen under ett varmt cachetillstånd hjälper det dig inte att optimera prestanda under kallt cachetillstånd.

För båda cachescenarierna är det viktigaste hur snabbt lagring kan flytta data från disk till minne. När du värmer cachen förbättras prestandan med tiden när frågor återanvänder data, cachefrekvensen ökar och frekvensen för att gå till disken för att hämta data minskar. Därför minskar även negativa prestandaeffekter från att behöva gå till disken. Eventuella prestandaförsämringar är tillfälliga och försvinner vanligtvis när cacheminnet når sitt varma tillstånd och den maximala storlek systemet tillåter.

Du kan mäta hur snabbt systemet kan hämta data från disken genom att mäta tillgänglig IOPS i Active Directory. Hur många tillgängliga IOPS det finns beror också på hur många IOPS som är tillgängliga i den underliggande lagringen. Du bör också överväga att planera för vissa exceptionella tillstånd, till exempel:

• Cacheuppvärmning efter omstart
• Säkerhetskopieringsåtgärder
• Återställ operationer

Behandla dessa som exceptionella tillstånd. Kör dem under lågtrafiktider. Deras varaktighet och inverkan beror på den aktuella domänkontrollantens belastning, så ingen universell storleksregel gäller utöver att schemalägga dem utanför hög belastningsperioder.

I de flesta scenarier är AD DS främst läs-I/O med ett förhållande av 90% läsa till 10% skriva. Läs-I/O är den typiska flaskhalsen för användarupplevelsen, medan skriv-I/O är flaskhalsen som försämrar skrivprestandan. Cacheminnen brukar ge minimala fördelar med att läsa I/O eftersom I/O-åtgärder för NTDS.dit filen främst är slumpmässiga. Därför är din huvudprioritet att se till att du konfigurerar läs-I/O-profillagringen korrekt.

Under normala driftsförhållanden är målet med lagringsplaneringen att minimera väntetiderna för systemet att returnera begäranden från AD DS till disken. Antalet utestående och väntande I/O-åtgärder bör vara mindre än eller lika med antalet vägar i disken. För scenarier med prestandaövervakning rekommenderar vi vanligtvis att räknaren LogicalDisk((<NTDS Database Drive>))\Avg Disk sec/Read är mindre än 20 ms. Ange drifttröskelvärdet nära den interna lagringsfördröjningen. Mål 2–6 ms, välj den nedre änden för snabbare media (NVMe/SSD) och den högre änden för långsammare nivåer.

Följande linjediagram visar mätning av diskfördröjning i ett lagringssystem.

Nu ska vi analysera det här linjediagrammet:

• Området till vänster om diagrammet som är inringat i grönt visar att svarstiden är konsekvent på 10 ms när belastningen ökar från 800 IOPS till 2 400 IOPS. Den här svarstidsbaslinjen påverkas av vilken typ av lagringslösning du använder.
• Området till höger i diagrammet som är inringat i rödbrunt visar systemets dataflöde mellan baslinjen och slutet av datainsamlingen. Själva dataflödet ändras inte, men svarstiden ökar. Det här området visar vad som händer när begärandevolymen passerar lagringssystemets fysiska gräns. Begäranden ligger längre i kön innan hårddisken hanterar dem.

Nu ska vi tänka på vad dessa data säger oss.

Först antar vi att en användare som frågar medlemskap i en stor grupp kräver att systemet läser 1 MB data från disken. Du kan utvärdera mängden I/O som krävs och hur lång tid åtgärderna tar med dessa värden:

• Storleken på varje Active Directory-databassida är 8 KB.
• Det minsta antalet sidor som systemet behöver läsa är 128.
• I baslinjeområdet i diagrammet bör det därför ta minst 1,28 sekunder att läsa in data från disken och returnera dem till klienten. Vid 20 ms-märket, där dataflödet går långt över den rekommenderade maxgränsen, tar processen 2,5 sekunder.

Baserat på dessa siffror kan du beräkna hur snabbt cacheminnet värms upp med hjälp av den här ekvationen:

2 400 IOPS × 8 KB per I/O

När du har kört den här beräkningen kan vi säga att den varma cachehastigheten i det här scenariot är 20 Mbit/s. Systemet läser med andra ord in cirka 1 GB databas i RAM-minnet var 53:e sekund.

Det finns en fysisk gräns för hur snabbt cacheminnet värms upp baserat på hur du utformar lagringssystemet. Det enda som kan värma cachen upp till den hastighet som den underliggande lagringen kan hantera är inkommande klientbegäranden. Skript som körs för att försöka förvärma cacheminnet under tider med hög belastning konkurrerar med verkliga klientbegäranden, ökar den totala belastningen, läser in data som inte är relevanta för klientbegäranden och försämrar prestanda. Vi rekommenderar att du undviker att använda artificiella mått för att värma cacheminnet.