Inntil Windows Server 2012 ble utgitt Microsoft alltid anbefalte organisasjoner har minst én domenekontroller utplassert på fysisk maskinvare. Med andre ord, mens muligheten til å virtualdomenekontrollere (kjører dem til virtuelle maskiner på Microsoft Hyper-V eller VMware ESX verter) har blitt et stadig mer attraktivt ide for mange organisasjoner, har den "offisielle" veiledning fra Microsoft vært å sikre at du holde minst én fysisk domenekontroller i ditt miljø. For eksempel, sier Microsoft Knowledge Base-artikkel KB888794:
". Merk: Ha alltid minst en DC som er på fysisk maskinvare, slik at failover klynger og annen infrastruktur kan starte" Denne anbefalingen var i utgangspunktet fordi virtualdomenekontrollere som kjører Windows Server 2003 eller Windows Server 2008 hadde en viss risiko, særlig risikoen for USN tilbakeføring oppstår. USN tilbakeføring skjer når den normale oppdateringer av oppdateringen sekvensnummer (USNS), som brukes til å holde styr på replikering av data mellom domenekontrollere, er et uhell eller utilsiktet omgått. Når dette skjer, prøver domenekontroller for å bruke en USN som er lavere enn sin nyeste oppdatering som kan resultere i Active Directory-replikering feil oppstår. En måte å forhindre USN rollback med virtuelle domenekontrollere er å unngå å ta eller bruke bilder av slike virtuelle maskiner. Dette er en av de viktigste grunnene til Microsoft tradisjonelt har frarådet å bruke Hyper-V snapshots i produksjonsmiljøer. En annen måte å hindre USN rollback er å unngå å eksportere kjøre virtuelle domenekontrollere, for eksempel ved å forsøke å klone dem til å lage nye virtuelle domenekontrollere for å distribuere i ditt miljø. Windows Server 2012 var ment å løse dette problemet med inkludering av nye sikkerhetstiltak som vil bidra til å forhindre USN rollback på virtuelle domenekontrollere og gi muligheten til å trygt klone virtuelle domenekontrollere. Disse forbedringene for Windows Server 2012 er beskrevet fullt ut i en serie av TechNet-artiklene tittelen Active Directory Domain Services (AD DS) Virtualization, og hvis du er ny til ideen om å virtualdomenekontrollere Jeg anbefaler at du starter med å lese disse artiklene som bakgrunn informasjon. Hva de oven TechNet artiklene unnlater å avklare derimot er om Microsoft fortsatt anbefaler å ha minst en fysisk domenekontroller til stede i infrastrukturen selv om alle dine domenekontrollere kjører Windows Server 2012 eller Windows Server 2012 R2 . Den "offisielle" veiledning om denne saken fortsatt synes å være den som finnes i TechNet artikkel med tittelen Running Domain Controllers i Hyper-V, som sist ble oppdatert i april 2008, og som spesifikt gjelder for Windows Server 2008 og Windows Server 2008 R2 og som legger " dette emnet vil bli oppdatert for å gjøre veiledning gjelder for Windows Server 2012 ", men dessverre har vi ikke vet når dette vil skje. Anyways, avsnittet "Unngå å lage ett poeng for feil" i denne artikkelen spesifikt sier at du bør:. "Opprettholde fysiske domenekontrollere i hvert av domenene Dette reduserer risiko for feil på virtualiseringsplattform som påvirker alle vertssystemer som bruker denne plattformen. " Så inntil Microsoft oppdaterer denne artikkelen for Windows Server 2012 dette er fortsatt deres" offisielle "veiledning på spørsmål om hvorvidt du bør holde noen av domenekontrollere fysiske i stedet for virtual dem alle. Men selv om virtual alle dine Windows Server 2012-domenekontrollere er helt trygt fra et teknisk synspunkt, er det trygt fra et forretningsmessig perspektiv? Og hvis så, er det noen spesielle hensyn du bør se etter eller beste praksis du bør følge? Vi vil undersøke saker som er involvert i denne artikkelen og den neste, og særlig spørsmålet om det kan være noen katastrofegjenoppretting eller kontinuitet konsekvensene av å ha alt av organisasjonens domenekontrollere virtualiserte. Som IT-administratorer vi vanligvis innser den avgjørende betydningen av å ha redundans og unngå en single point of failure for sine omgivelser. Men vi kan ikke alltid være klar over nøyaktig hva en single point of failure kan være i enkelte scenarier. La oss starte med å vurdere noen åpenbare eksempler. 1. Contoso Ltd har et enkelt domene nettverk med bare en domenekontroller. Har ovennevnte scenario indikerer at det er en single point of failure? Selvfølgelig! Contoso har bare en domenekontroller, så hvis det mislykkes det vil være store problemer for brukerne av bedriftens nettverk. Hva er løsningen her? Ha minst to domenekontrollere per domene å skape litt redundans. 2. Contoso Ltd har et enkelt domene med to virtuelle domenekontrollere begge kjører på samme fysiske Hyper-V host maskin. Er det en single point of failure her? Ja, fordi hvis Hyper-V host boks dør da ingen av de to virtualiserte domenekontrollere vil være til stede og nok en gang brukerne kan ha problemer med å få tilgang til ressurser på nettet. Hva er løsningen? Hvis du kommer til å ha bare virtuelle domenekontrollere i miljøet så sørg for at du har minst to av dem, og at de kjører på forskjellige virtualiserings verter. For eksempel kan du ha den virtuelle maskinen VDC-01 kjører på fysisk server HOST-01 og virtuell maskin VDC-02 kjører på HOST-02 Den neste scenario er mer komplisert. 3. Contoso Ltd har et enkelt domene med to virtuelle domenekontrollere hvert kjører på separate fysiske vertsmaskiner som begge kjører Windows Server 2012 R2 Hyper-V. Begge vertsmaskiner er Dell Poweredge R320 Rack servere med identisk maskinvare og kjøpte samtidig. Det er to problemer med ovennevnte scenario fra perspektivet til single point of failure. Først både fysiske vertssystemer har identisk hardware dvs. samme prosessor, lagring og nettverk hardware. Dette kan peke på flere potensielle problemer. For eksempel, siden begge vertssystemer ble kjøpt på samme tid fra Dell, harddisker (eller solid state drives) for disse maskinene er trolig fra samme parti. Hvis det var problemer med produksjonen av denne gruppen som kan øke sannsynligheten for plutselige svikt i diskene fra batch så du kan forvente en økt risiko for diskene i begge vertssystemer sviktende nesten samtidig (selv om at risikoen er sannsynligvis svært liten). Enda viktigere men siden både av vertssystemer har identisk lagring maskinvare de ville derfor nesten helt sikkert ha identiske lagrings drivere installert på dem. Nå forestille seg for et øyeblikk at leverandøren (Dell i dette tilfellet, men i virkeligheten den samme risikoen kan være til stede med noen systemleverandør) fulgte disse driverne med en feil i dem og under visse betingelser som bug kan utløse korrupsjon av data lagret på diskene driverne er assosiert med. Hva som kan skje i dette tilfellet er at lagring på begge dine virtualiserings vertene kunne bli ødelagt på samme tid. Og hvis dette skjer så de virtuelle maskinene (de virtuelle domenekontrollere) som kjører på disse vertene ville trolig krasje, slik at infrastrukturen uten arbeidsdomenekontrollere. Jeg har faktisk hørt om dette skjer til ett selskap der de mistet nesten alle sine domenekontrollere og nesten måtte gjenoppbygge deres domene fra bunnen av. Heldigvis hadde de et par domenekontrollere som kjørte på ulike system maskinvare og lagring på disse domenekontrollere ikke blir ødelagt, slik at de var i stand til å redde domenet ved å få maskinvareleverandøren for å gi dem en oppdatert driver som fikset lagring problem etter som de gjenoppbygd alle de mislykkede domenekontrollere fra grunnen av. I dette spesielle tilfellet domenekontrollere involvert var alle de fysiske og ikke virtuelle, men det samme prinsippet gjelder for både fysiske eller virtuelle domenekontrollere. Dette prinsippet er dette: Kontroller at du har maskinvare mangfold på tvers av domenekontrollere. Så hvis vi endret scenario 3 til å lyde: 3A. Contoso Ltd har et enkelt domene med to virtuelle domenekontrollere hvert kjører på separate fysiske vertsmaskiner som begge kjører Windows Server 2012 R2 Hyper-V. En av vertsmaskiner er en Dell Poweredge R320 Rackservere mens den andre er en HP ProLiant DL580 Gen9 rackserver. Vil det hindre slike problemer skjer? Betyr scenario 3A holde mangfoldet kravet er nødvendig for å unngå å ha en single point of failure? Ikke helt, for mens vi har nå forsikret hardware mangfold for våre virtuelle domenekontrollere, vi har ikke forsikret programvare mangfold for begge våre domenekontrollere er virtualisert innenfor Microsofts Hyper-V virtualiseringsmiljø. Dette kan virke som overkill for noen lesere, og Microsoft kan innvende at vi blir paranoid når jeg sier dette, men for å oppnå sann mangfold - det vil si, mangfold av både maskinvare og programvare - du kan endre situasjonen til noe sånt som dette : 3B. Contoso Ltd har et enkelt domene med to virtuelle domenekontrollere hvert kjører på separate fysiske vertsmaskiner. En av vertsmaskiner er en Dell Poweredge R320 Rack servere som kjører Windows Server 2012 R2 Hyper-V. Den andre vertsmaskinen er en HP ProLiant DL580 Gen9 rackserver kjører VMware ESXi 6. Begrunnelsen for ovenfor valget er å unngå et problem som hvor Microsoft utgir en oppdatering for Windows Server 2012 R2 som forårsaker et problem for Hyper-V server rolle. Hvis dette skulle skje (og det har vært noen tilfeller i det siste der Microsoft har gitt ut problematiske patcher som har forårsaket store problemer for enkelte kunder) og alle dine virtualiserings vertene kjører samme versjon av Hyper-V så alle dine virtualiserte domene kontrollerne kan bli satt ut av spill slik at du med store problemer på hendene. Selvfølgelig la oss håpe det aldri skjer, men hva de ovennevnte scenarier egentlig stiller er følgende spørsmål som IT-ledelse bør overveie nøye: Hvor mye risiko er du villig til å tolerere at Active Directory infrastruktur makt mislykkes? Siden større hardware /software mangfold betyr også større ledelse overhead, vi har rett og slett den gamle kompromisset å vurdere mellom administrasjon og pålitelighet /sikkerhet. Og det er opp til deg hvordan du velger å balansere de to sider av denne ligningen. Vi skal i neste artikkel i denne serien Hvis du har spørsmål om domenekontroller maskinvare planlegging, best sted å spørre dem er Active Directory Domain Services forum på TechNet. Hvis du ikke får hjelpen du trenger det, kan du prøve å sende spørsmålet ditt til [email protected] slik at vi kan publisere den i English våre lesere delen av vårt nyhetsbrev og se om noen av de nesten 100 000 IT pro abonnenter av vårt nyhetsbrev har noen forslag angående problemet. Anmeldelser
Forstå hva single point svikt kan bety
Likevel fikk spørsmål om Active Directory fortsette vår diskusjon av virtuelle domenekontrollere.?