Opslag voor Windows 212R2 domein en Hyper-V 2012R2 omgeving

[ArcticTiger]

Ik weet niet of ik dit onder WSS of OM moet plaatsen, maar aangezien het om opslag gaat toch maar onder OM

Even wat achtergrond informatie:
Wij zijn bezig met het ontwerp voor ene nieuwe netwerkomgeving, voorzien van 2 stuks Hyper-V 2012R2 (hosts) in failover en 1 Windows 2012R2 server (storage)
De Windows 2012R2 server zal dienen als AD/DC, maar ook als fileserver voor alle netwerkshares en ook voor de VM's.
De storage en hosts worden onderling verbonden DMV een 10GBit netwerk

Het plan is om:

• de VM's op een eigen RAID 10 te plaatsen: 4x 1 TB SSD
• de shares op een eigen RAID 10 te plaatsen: 4x 1 of 2 TB HDD, eventueel met 2x kleine SSD voor cache
• scanarchieven op een eigen RAID 10 te plaatsen: 4x 2 TB HDD

Nu loop ik tegen een vraagstuk aan hoe ik de opslag op ga zetten.
Ga ik alles via een RAID controller opzetten (Hardware RAID), of ga ik gebruik maken van Windows Storage Spaces (Software RAID)

Zijn er mensen die hier ervaring mee hebben en zouden willen delen?

[hans_lenze]

Opslag:
Door meer schijven in een pool / RAID set te stoppen krijg je een hogere doorvoersnelheid. Ik zou, onafhankelijk van de keuze, alle schijven in één logische opstelling zetten. Ik vind RAID groepen iets van vroeger. Read cache en write buffering helpt enorm in de snelheid van de opslag. Door de write buffer op een SSD te plaatsen is deze ook
Ik lees niet precies wat je eisen zijn aan de opslag. Zo zou ik me voor kunnen stellen dat het scanarchief niet persee op snelle opslag hoeft te staan. Wat zijn de eisen precies?

In het geval van Storage Spaces denk ik aan de volgende opzet: 1 pool met acht identieke schijven en vier SSDs. Vier SSDs en acht schijven maken vier column volumes mogelijk. Dit is fijn voor de schijfdoorvoer. Voor de VMs en de shares een mirror volume, voor de scanarchieven is parity ook te overwegen, eventueel met data deduplication (parity volumes zijn duidelijk trager dan mirror of simple volumes).

Andere opmerkingen:
De combinatie van domain controller en fileserver/VM storage is een slecht idee. Om de integriteit van de AD database te bewaken schakelt deze rol alle mogelijke write caching uit op de opslag. Terwijl deze caching juist fijn is voor de VMs en de file shares die op dezelfde machine staan.

Je hebt twee Hyper-V hosts voor VMs (redundant) maar slechts één opslag server. Met dit ontwerp heb je alsnog een SPOF in je omgeving. Dan kun je ook geld besparen door een enkele Hyper-V host neer te zetten met meer geheugen.
Alternatief: Koop twee lichte servers en een SAS JBOD enclosure voor de schijven en richt een Scale Out File Server in. http://blogs.technet.com/...that-is-the-question.aspx Deze opstelling is hoog beschikbaar, volledig ondersteund door Microsoft en schaalbaar.

[ArcticTiger]

@hans_lenze
Allereerst mijn dank voor de verhelderende post.

Misschien is het handig dat ik wat meer uitleg geef betreffende de huidige omgeving en wat ons idee wasbetreffende de nieuwe omgeving.
(Wellicht zorgt dit ervoor dat dit topic maar naar SWS moet omdat het verder gaat dan enkel storage?)

Misschien ben ik nog van de oude stempel (en zo oud ben ik nog niet ) dat ik denk in afzonderlijke RAID groepen dus ben benieuwd wat daar aan performance winst te behalen zou zijn mocht ik de RAID controller laten voor wat hij is (moet bijvoorbeeld voor RAID 5/50/6/60 upgrades aanschaffen) en alls softwarematig te gaan doen d.m.v. Storage Spaces

Wat betreft de AD/DC en fileserver combinatie wist ik niet dat dit geen goede combinatie zou zijn, wellicht de AD/DC op een lichte(re) server planten dan (had voor het geheel toch een behoorlijke hardware configuratie in gedachten)

De huidige omgeving bestaat op dit moment uit 5 servers

• Server1 (SBS 2008) - AD/DC/Fileserver
• Server2 (2008 std) - SQL server
• Server3 (dual CPU) (2012R2 Std) - Terminal Server
• Server4 (Oracle Linux) - TMS pakket
• Server5 (Oracle Linux) - Oracle Database

Onze idee voor de nieuwe omgeving

• Server1 (dual CPU) (2012R2 Std) - AD/DC/FS
• Server2 (dual CPU) (Hyper-V 2012R2)
• Server3 (dual CPU) (Hyper-V 2012R2)
  • Virtueel:
  • (2012R2 Std) SQL Server
  • (Oracle Linux) - TMS pakket
  • 1 of meerdere MV's voor onderhoud en configuratie voor Telefooncentrale, toegangscontrole van het bedrijfspand, etc
• Server4 (dual CPU) (2012R2 Std) - Terminal Server
• Server5 (Oracle Linux) - Oracle Database

Waar ik in jouw post nog wel tegen aan loop is dat, in gevan van een SOFS met een gedeelde SAS JOBD enclosure er alsnog een SPOF in de omgeving zit, ik denk dat ik daar moeilijk omheen kan zonder dat er een enorm budget aan vast moet zitten...

Het hele project om een Hyper-V cluster op te zetten is ontstaan bij het idee om (voornamelijk) onze TMS applicatie high available te houden (draait nu op 1 server) en om ruimte te besparen door diverse andere machines voor beheertaken te virtualizeren, en zodoende dus met minder hardware af te kunnen.
Dit is ook de reden geweest om de AD/DC en Filserver samen te voegen.

[hans_lenze]

Waarschijnlijk is een move naar WSS niet zo'n slecht idee.

Disclaimer: Het onderstaande verhaal kan hier en daar aanvoelen als een reclamepraatje. Ik vermijd bewust de bekende weg en richt me op nieuwe spullen en technologie. Dit om een interessant alternatief te laten zien. Later kunnen we het nog een keer hebben over bekende en bewezen spullen.
Zonder harde getallen doe ik een aantal aannames.

• Kostenbesparend dus geen N+1 maar 1+1 (dus geen redundantie tijdens onderhoud/updates/werkzaamheden) <- deze telt zwaar in het onderstaande verhaal!
• Hoog beschikbaar is een eis, dus alles dubbel (active-active) of redundant (active-passive) uitgevoerd met zo min mogelijk hardware (en dus kosten).
• Uitbreidbaar is fijn maar niet veel groei in rekencapaciteit verwacht
• Ik houd geen rekening met licentie kosten, alleen met performance en beschikbaarheid.
• De getallen qua schijf formaten zuig ik uit mijn duim. Je geeft aan ongeveer 2TB aan VMs, 2TB aan data en 4TB aan archief te hebben.
• Back-up neem ik niet mee

Nodig voor een nieuwe omgeving:
100% gevirtualiseerd

• Fileserver (2vCPU, 2GB RAM, 2TB opslag)
• Scanarchief (2vCPU, 2GB RAM, 4TB opslag)
• DC01 (1vCPU, 2GB RAM, 80GB opslag) (RD License server)
• DC02 (1vCPU, 2GB RAM, 80GB opslag) (Want één domain controller is geen domain controller)
• SQL(4vCPU, 16GB RAM, 180GB opslag)
• Oracle (4vCPU, 16GB RAM, 180GB opslag)
• TMS (2vCPU, 4GB RAM, 80GB opslag)
• Telefooncentrale (1vCPU, 2GB RAM, 80GB opslag)
• Toegangscontrole (1vCPU, 2GB RAM, 80GB opslag)
• Applicatie 1 (1vCPU, 2GB RAM, 80 GB opslag)
• Applicatie 2 (1vCPU, 2GB RAM, 80 GB opslag)
• Terminal Server1 (4vCPU, 16GB RAM, 80GB opslag)
• Terminal Server2 (4vCPU, 16GB RAM, 80GB opslag) (Geeft de mogelijkheid om tijdens werktijd updates te draaien van client software, een leverancier zijn nieuwe pakketje te laten testen enz)
• Management (1vCPU, 2GB RAM, 80GB opslag) (Alle beheer tools voor de hele omgeving bij elkaar en verantwoordelijk voor scheduled tasks, rapportages en ander nachtelijk gespuis. Mogelijkheid voor externe leveranciers om verbinding te maken met de omgeving)
• RemoteDesktop broker (1vCPU, 2GB RAM, 80GB opslag) (Loadbalancing van sessies over beide terminal servers)
• RemoteDesktop gateway (1vCPU, 2GB RAM, 80GB opslag) (Bereikbaar vanaf internet in een DMZ. Toegang tot de broker, de terminal servers en de management server voor thuiswerkplek, extern kantoor, remote troubleshooting)

Totaal:
31 vCPU
90GB RAM
7500GB opslag

Disclaimer: Ik heb nog nooit van DataON gehoord, maar ze hebben de duidelijkste plaatjes die het concept het beste beschrijven.
Als hardware kiezen we voor een Cluster-in-a-Box. Dit is een chassis van 2u met een aantal HDDs en SSDs aan de voorkant en een tweetal dual CPU servers en voedingen aan de achterkant. Meer info over Cluster-in-a-box. Deze 2u doos is de complete productie omgeving.
DataON heeft een unit met de volgende specificaties:
Per Hyper-V server (twee van deze zitten er dus in het 2u chassis)
2x Xeon E5-2650v2 8core (32 threads per Hyper-V server)
128GB RAM
128GB SSD RAID1 voor Server 2012R2

De twee Hyper-V servers hebben samen toegang tot het backplane in het chassis. Aan het backplane zijn de schijven verbonden zodat elke server elke schijf kan aanspreken. In totaal is er 14TB netto opslag beschikbaar (4x 200GB SSD, 8x 4TB HDD). De SSDs worden op drie manieren ingezet

• Voor snelle volumes/bestanden die volledig op SSD RAID10 opslag staan.
• Als tiered storage: een percentage van een volume staat op SSD waarbij de meestgebruikte blokken/bestanden automatisch naar SSD opslag worden verplaatst.
• Als write back cache voor volumes die niet op SSD staan. Een schrijfopdracht naar een HDD volume wordt eerst opgevangen op SSD om op een later, rustiger, moment te worden verplaatst naar de HDD.

De twee Hyper-V servers zijn geclusterd zodat VMs ook live gemigreerd kunnen worden tussen de Hyper-V servers. De opslag wordt aangesproken via een SAS bus met een hogere doorvoer en een lagere latency dan mogelijk is over een netwerk verbinding (voor deze prijs).
Als er geen storing is, kunnen de domain controllers, terminal servers, database servers en andere VMs verdeeld worden over de twee Hyper-V servers. De complete virtuele omgeving kan tijdens een storing draaien op één van de Hyper-V servers omdat er voldoende geheugen beschikbaar is om alle VMs op te starten.

Een paar plaatjes voor het idee:
Voorkant en achterkant van zo'n doos


Schema met de aansluitingen en zo


In dit schema staat onderaan een JBOD voor extra opslag naast de schijven in het chassis zelf. Zoals te zien is, is de JBOD zelf voorzien van dubbele voeding, dubbele controller en vanaf elke controller een verbinding naar beide Hyper-V servers.

Linkje naar een leuke howto om zelf met weinig spullen toch te spelen en testen met tiered Storage Spaces: http://blogs.technet.com/...ndows-server-2012-r2.aspx
Goede uitleg over tiered Storage Spaces en de verschillende features
http://channel9.msdn.com/...rica/2014/DCIM-B346#fbid=

Goed, bedtijd.

[br00ky]

Op verzoek, move naar WSS.

[ArcticTiger]

@br00ky
Dankjewel

@hans
Ik ben om een of andere reden toch wat huiverig wat betreft de cluster-in-a-box, dan gaat mijn voorkeur alsnog naar losse hosts en een enkele fileserver.
Nu moet ik eerlijk zijn da tik geen idee heb wat de impact zal zijn als ik de AD/DC/DHCP virtueel maak, ik ben altijd van het standpunt uitgegaan: fysiek = beter
(Zelfde geldt voor de terminal server)

Ik las dat je wat harde cijfers miste, deze heb ik inderdaad niet opgegeven.
De SBS2008 en SQL server zullen dus komen te vervallen en worden vervangen door nieuwe hardware

De TMS server wordt virtueel.
De huidige fysieke configuratie is 2x Intel Xeon E5620 met 16GB RAM en 300GB opslag

De Oracle server virtualiseren we niet omwille van licentiekosten (tja... Oracle...)
De huidige configuratie is 1x Intel Xeon E5620 met 16GB RAM en 300GB opslag

De terminal server zouden we kunnen virtualiseren, dan zou de bestaande terminal server eventueel omgebouwd kunnen worden tot fileserver met een externe storage enclosure.
De huidige configuratie is 2x Intel Xeon E5-2420 met 32GB RAM en 300GB opslag

Nog even terugkomend op een eerder opmerking van je:

De combinatie van domain controller en fileserver/VM storage is een slecht idee. Om de integriteit van de AD database te bewaken schakelt deze rol alle mogelijke write caching uit op de opslag. Terwijl deze caching juist fijn is voor de VMs en de file shares die op dezelfde machine staan.

Ik ben hier even over aan het googlen geweest en kwam het volgende tegen:
http://serverfault.com/qu...y-dc-role-or-with-the-rds

Active Directory will only disable write caching on volumes where the database files are located. Adding a dedicated volume for file service would be fine in that respect.

Lijk mij dat ik dit best kan combineren zolang ik de volumes waar alles op staat maar goed gescheiden houd?

Al met al blijft het een mooie puzzel voor mij

[Linke Loe]

Een virtuele domain controller kan op zich prima, maar in geval van een failover cluster zou ik er zeker voor zorgen dat je de FSMO rollen draait op een domain controller die niet op je cluster draait. Een Windows cluster is namelijk afhankelijk van Active Directory en als je (enige) domain controller op het cluster draait, heb je een uitdaging om je cluster in de lucht te krijgen op het moment dat deze om wat reden dan ook down is.

Wat uiteraard wel kan, is dat je de server die je als domain controller / file server had bedacht, uit te rusten met Hyper-V om op die manier toch AD en een file server aan te bieden op één fysieke bak.

Ik zou ook zeker denken aan een tweede domain controller in je omgeving. Niet alleen omwille van redundantie, maar ook om de load bij aanmeldprocessen te verdelen.

[ArcticTiger]

Wat uiteraard wel kan, is dat je de server die je als domain controller / file server had bedacht, uit te rusten met Hyper-V om op die manier toch AD en een file server aan te bieden op één fysieke bak.

Dus naast de 2 Hyper-V hosts (Microsoft Hyper-V Server), de 3 server voorzien van de Hyper-V rol en dan de file-server virtueel maken of de AD/DC virtueel maken?

Gezien de omvang van de fileserver ben ik ietwat huiverig om dat allemaal virtueel te maken
Dan kan ik denk ik beter nog de file-server afsplitsen naar een nieuwe fysieke server?

Zit momenteel nog in het bedenk-en-puzzel stadium, er is nog niets angeschaft o.i.d.
Er ligt wel een slordige schatting voor het budget, en wil proberen om daar binnen te blijven

[hans_lenze]

Linke Loe schreef op vrijdag 16 januari 2015 @ 12:04:
Een virtuele domain controller kan op zich prima, maar in geval van een failover cluster zou ik er zeker voor zorgen dat je de FSMO rollen draait op een domain controller die niet op je cluster draait. Een Windows cluster is namelijk afhankelijk van Active Directory en als je (enige) domain controller op het cluster draait, heb je een uitdaging om je cluster in de lucht te krijgen op het moment dat deze om wat reden dan ook down is.

Dit is inderdaad het geval bij een Server 2008R2 cluster. Sinds Server 2012 start een cluster ook op zonder dat een domain controller beschikbaar is.

Ability of the cluster to start with no AD DS dependencies. Enables certain virtualized data center scenarios.
bron: http://technet.microsoft....ary/dn265972.aspx#BKMK_AD

Wat uiteraard wel kan, is dat je de server die je als domain controller / file server had bedacht, uit te rusten met Hyper-V om op die manier toch AD en een file server aan te bieden op één fysieke bak.

Ik zou ook zeker denken aan een tweede domain controller in je omgeving. Niet alleen omwille van redundantie, maar ook om de load bij aanmeldprocessen te verdelen.

[Linke Loe]

hans_lenze schreef op vrijdag 16 januari 2015 @ 13:50:
[...]

Dit is inderdaad het geval bij een Server 2008R2 cluster. Sinds Server 2012 start een cluster ook op zonder dat een domain controller beschikbaar is.

Ability of the cluster to start with no AD DS dependencies. Enables certain virtualized data center scenarios.
bron: http://technet.microsoft....ary/dn265972.aspx#BKMK_AD


[...]

http://technet.microsoft.com/nl-nl/library/dn265970.aspx

Het wordt weliswaar ondersteund, maar voor Hyper-V niet aangeraden. Dit is omdat live migration gebruik maakt van Kerberos authenticatie tussen de nodes. Kerberos kan alleen gebruikt worden in een Active Directory domein. Aangezien je bij het bouwen van het cluster al aan moet geven of hij AD integrated moet zijn, is dit niet iets wat je later aan kan passen. Het is dan ook niet zo dat een cluster die AD integrated is, toch kan starten zonder AD.

[ArcticTiger]

Het wordt allemaal erg interessant nu

Even samenvattend
- De AD/DC moet dus fysiek naast de HV hosts beschikbaar zijn
- Het is niet mogelijk om de file server rol toe te wijzen aan de AD/DC (of in ieder geval niet aan te raden ivm caching?)

Dus al met al, vwb mijn vraagstuk, is het enige foute punt dat ik de AD/DC ook als file server wilde gebruiken?

Dat er een SPOF in de situatie zit kan ik mee leven (uiteindelijk is er altijd wel ergens een SPOF te vinden)
Daarnaast is het plan om de nu bestaande hardware niet meteen af te schrijven maar om deze uit te breiden en in te zetten als offsite replicatie.
Tevens wordt er wekelijks een full backup, en dagelijks een differential backup gemaakt, waardoor ik voor mijn data wel een veilig gevoel heb

[ Voor 10% gewijzigd door ArcticTiger op 16-01-2015 15:22 ]

[Jazzy]

Maar we hebben het hier toch niet over clusters maar stand-alone servers? Je kunt domain controllers gewoon virtueel houden, niet nodig om er nog eentje fysiek te hebben.

[ArcticTiger]

Omdat de hyper-v hosts als failover geconfigureerd moeten worden moeten ze in een cluster worden opgenomen / zal er een cluster worden gemaakt.

[Linke Loe]

Jazzy schreef op vrijdag 16 januari 2015 @ 15:27:
Maar we hebben het hier toch niet over clusters maar stand-alone servers? Je kunt domain controllers gewoon virtueel houden, niet nodig om er nog eentje fysiek te hebben.

In de openingspost wordt al gesproken over failover. Dat betekent een cluster met shared storage en dus ook een domain controller die niet op het cluster draait. Of die domain controller nou virtueel is of niet, maakt niet uit, als je maar een domain controller buiten je cluster laat draaien.

Ik zou die server die je voorzien had als file server / domain controller voorzien van Hyper-V en zowel de fileserver als de domain controller daar virtueel op draaien. Wellicht een beetje ten koste van een stukje performance, maar Hyper-V op Windows 2012 R2 kan prima omgaan met VHD files groter dan 2 TB. Ik denk dat het kleine beetje performance wat je misschien verliest, niet opweegt tegen de voordelen van virtualisatie.

Ik weet niet hoe je je backups maakt, maar je zou eens kunnen kijken naar Veeam Backup & Replication. Met forever incremental backups, maak je iedere dag een incrementele backup van de complete VM (behalve de eerste keer natuurlijk), terwijl je wel heel makkelijk halverwege de backup chain, op bestandsnivo kan restoren, zonder eerst de full backup te hoeven restoren.

Zo zijn er nog legio voordelen van virtualisatie ten opzichte van een fysieke doos...

[hans_lenze]

Linke Loe schreef op vrijdag 16 januari 2015 @ 14:46:
[...]

http://technet.microsoft.com/nl-nl/library/dn265970.aspx

Het wordt weliswaar ondersteund, maar voor Hyper-V niet aangeraden. Dit is omdat live migration gebruik maakt van Kerberos authenticatie tussen de nodes. Kerberos kan alleen gebruikt worden in een Active Directory domein. Aangezien je bij het bouwen van het cluster al aan moet geven of hij AD integrated moet zijn, is dit niet iets wat je later aan kan passen.

Even een verschil aanduiden: Een Active-Directory Detached cluster is een oplossing voor het bouwen van een failover cluster zonder tijdens de bouw computer objecten in AD aan te maken. Belangrijk voor een omgeving waar een cluster administrator geen beheertoegang heeft tot AD maar lijkt me in dit geval niet van toepassing. Zie ook http://blogs.technet.com/...irectory-integration.aspx

Het is dan ook niet zo dat een cluster die AD integrated is, toch kan starten zonder AD.

Dat kan dus eindelijk sinds Server 2012. AD is niet meer nodig om te bepalen welke clusternode eigenaar wordt van de cluster rollen tijdens het starten van het cluster. Er komt netjes een warning in het eventlog van de host te staan maar het cluster (inclusief VMs) start gewoon op.

In WS2012, we have solved this situation by allowing an existing cluster to boot without AD. In other words, now node that boots up first can create the cluster & can try to gain quorum without authenticating with DC. Now since other nodes can also start without contacting the DC (unless there are other technical issues blocking those nodes to start), first node gains quorum & whole cluster can start.
bron: http://blogs.technet.com/...-active-directory-ad.aspx

Ik vind het jammer om een tweetal Hyper-V servers te hebben voor hogere beschikbaarheid maar slechts een enkele fileserver waar alle VMs op staan. Is een SAS SAN binnen budget? Dan denk ik aan een HP MSA, Dell MD3 of één van de andere hardware stickers met een aantal schijven, dubbele voeding en dubbele SAS controllers.

[ Voor 7% gewijzigd door hans_lenze op 16-01-2015 17:01 . Reden: Meer info ]

[arjants]

Gezien het type servers die je wilt gaan draaien lijken IOPS mij niet onbelangrijk in je storage keuze

Fileserver
Scanarchief
DC01
DC02
SQL
Oracle
TMS
Telefooncentrale
Toegangscontrole
Applicatie 11
Applicatie 2 2
Terminal Server1
Terminal Server2
Management
RemoteDesktop broker
RemoteDesktop gateway

Ik zie allemaal iops vreters in je lijstje die ik zelf op een behoorlijk SAS SAN zou plaatsen.

[ArcticTiger]

arjants schreef op maandag 19 januari 2015 @ 09:54:
Gezien het type servers die je wilt gaan draaien lijken IOPS mij niet onbelangrijk in je storage keuze

Fileserver
Scanarchief
DC01
DC02
SQL
Oracle
TMS
Telefooncentrale
Toegangscontrole
Applicatie 11
Applicatie 2 2
Terminal Server1
Terminal Server2
Management
RemoteDesktop broker
RemoteDesktop gateway

Ik zie allemaal iops vreters in je lijstje die ik zelf op een behoorlijk SAS SAN zou plaatsen.

Even ter verduidelijking: Dit lijstje heb ik niet zelf opgesteld, dit is een opzet geweest van hans_lenze als voorbeeld

Wat wij uiteindelijk echt gevirtualiseerd willen hebben:

• Ons TMS pakket
• Webportal van ons TMS pakket (verre van heavy use)
• Onze SQL server (is zelf SQL express, daar wij deze momenteel alleen gebruiken voor een sales pakket en ons backup pakket), geen heavy use dus
• e.e.a. aan management tools voor telefooncentrale, toegangsbeheer tot het pand etc
• e.e.a. aan klein grut wat niet bedrijfskritisch is

Wat komt er op de fileserver te staan?

• VM's
• Diverse shares
• Userfolders (folder redirections my documents, desktop en favorites, wordt gelimiteerd tot 5GB per persoon)
• Archief bestanden TMS systeem
• Scan archief
• Wat ik nog vergeten ben

Wat shares en archieven betreft zal het niet veel IOPS vreten, wellicht de VM's wel

Ben nu toch aan het kijken wat eventueel de mogelijkheden zijn voor 2 Hyper-V servers, en 2 lichtgewicht file servers met een gedeelde SAS JOBD (wat ook werd aangedragen door hans_lenze)

Wellicht kan ik wat kosten besparen door terug te vallen van SSD's naar 15K schijven voor de VM opslag

[Question Mark]

Linke Loe schreef op vrijdag 16 januari 2015 @ 14:46:
[...]
Dit is omdat live migration gebruik maakt van Kerberos authenticatie tussen de nodes.

Nope... Je kunt ook kiezen voor CredSSP als authenticatie methode voor live migration. Nadeel is dan wel dat je aangelogged moet zijn op de host om een live-migration te kunnen uitvoeren.

[/]licht offtopic

[ArcticTiger]

Even een aanvulling op mijn vorige post
Aangezien wij momenteel gebruik maken van IBM servers, is mijn uitgangspunjt ook geweest om IBM als nieuwe hardware te gebruiken.
Na wat zoeken ben ik terecht gekomen op een mooie "IBM Redbook":
Windows Storage Server 2012 on IBM System x

Ben me nu even aan het inlezen, maar het heeft wel alle schijn dat een SOFS toch even een slordige 20k euro extra gaat kosten...

[hans_lenze]

Een SOFS is een vervanging voor een SAN (tenminste, zo ziet Microsoft het graag).

Ik ben niet zo thuis in de IBM spullen maar als het om Dell spullenboel gaat zou ik denken aan:
2x PowerEdge R430, dual CPU E5-2620v3, 128GB RAM, 2x 300GB SAS, 12Gb SAS HBA als Hyper-V host (list: 7000 euro met 3yr NBD support)
1x PowerVault MD1420, 4x 200GB mixed use SSD, 20x 1TB NL-SAS HDD (list: 19.000 euro met 3yr NBD support)

De MD1420 staat ook op de Storage Spaces HCL.

En hiermee iets bouwen in de richting van http://technet.microsoft.com/en-us/library/hh831829.aspx

Ik kies er dus voor om de fileserver virtueel te maken en de Hyper-V hosts direct toegang te geven tot de opslag in plaats van een fileserver er tussen te plaatsen. Dit scheelt geld en levert meer perfomance op (SAS latency en 12Gbit per kanaal, 4 kanalen per host naar de opslag). Nadeel is beperkte groeimogelijkheden (maximaal 4 hosts aan te sluiten aan de MD1420)

[Question Mark]

Heeft de topicstarter al eens het huidige aantal IOPS gemeten? Zaken als total iops, blocksize en de verhouding read/write is erg intressant.

Niks mis mee om alvast met een schuin oog te kijken naar mogelijke hardware oplossingen, maar ik zou zeker eerst gaan bepalen wat nodig is.

Afgezien van iops requirement ben ik ook even benieuwd in welke mate je beschikbaarheid wilt gaan bereiken (en of je uberhaubt HA wilt aanbieden). Leuk en aardig dat je twee hosts neer wilt zetten, maar je ene SQL-server of DC is nog steeds eens spof.

En wat zijn de eisen en wensen omtrent backup, en hoe ga je dat inregelen?

[hans_lenze]

Question Mark schreef op maandag 19 januari 2015 @ 15:46:
Heeft de topicstarter al eens het huidige aantal IOPS gemeten? Zaken als total iops, blocksize en de verhouding read/write is erg intressant.

Niks mis mee om alvast met een schuin oog te kijken naar mogelijke hardware oplossingen, maar ik zou zeker eerst gaan bepalen wat nodig is.

Afgezien van iops requirement ben ik ook even benieuwd in welke mate je beschikbaarheid wilt gaan bereiken (en of je uberhaubt HA wilt aanbieden). Leuk en aardig dat je twee hosts neer wilt zetten, maar je ene SQL-server of DC is nog steeds eens spof.

En wat zijn de eisen en wensen omtrent backup, en hoe ga je dat inregelen?

ArcticTiger schreef op vrijdag 16 januari 2015 @ 11:31:
[knip]
Ik las dat je wat harde cijfers miste, deze heb ik inderdaad niet opgegeven.
[knip]

Of ze gemeten zijn weet ik niet, ze zijn zeker interessant!

[ArcticTiger]

Meteen een vraagje +)
Heeft iemand tips om de IOPS op ene redelijke manier te meten met perfmon zodat ze ook redelijk uit te lezen zijn?

[Question Mark]

Yup, die vraag komt nl. wel vaker langs...

Question Mark in "Hyper-V server met iSCSI"

[ArcticTiger]

Zal het een paar dagen laten lopen en zien wat er uit komt
Zal wel niet bepaald schokkend zijn, helemaal nu ik van iedereen de PST bestanden van de server af heb gehaald

Heb ze meteen gestart, neemt ie meteen de metingen mee tijdens de backup
Heb hem ingesteld op +/- 48 uur

Wat betreft de backup (backup naar 2TB USB schijf):
Wij hebben nu 5 fysieke servers staan
[list]
• Server1 [SBWS 2008 64bit] - AD/DC en shares
• Server2 [Server 2008 Standard 32bit] - SQL server (SQL 2005 Express) en testomgeving voor salespakket
• Server3 [Server 2012R2 Standard] - Terminal server
• Server4 [Oracle Linux] - TMS Software
• Server5 [Oracle Linux] - Oracle database

Server 4 en 5 maken elke nacht een dump naar Server1 (is ingeregeld door de leverancier van het TMS pakket)
Deze worden dagelijks naar de dan aangesloten USB backup schijf
Server3 wordt niet gebackupped, draait geen speciale software op en alles wordt toch op het netwerk gedaan (folder redirection)

Op Server1 draait Symantec BackupExec 12 (welke versie exact weet ik niet 1-2-3) welke wekelijks (start op zaterdag) een volledige backup draait van Server1 en een aantal folders op Server2, evenals van de SQL server op Server2 (SQL Server Agent?)
Doordeweeks (ma-do) wordt een differentiele backup gedraaid
Maandelijks (start einde van de laatste dag van de maand) wordt ook een volledige backup gedraaid

Dit alles heeft tot op heden goed gewerkt

In de nieuwe omgeving zal de backup strategie wellicht moeten worden herzien, maar ben nu goed te spreken over de huidige cyclus.

[ Voor 82% gewijzigd door ArcticTiger op 19-01-2015 17:38 ]

[Question Mark]

ArcticTiger schreef op maandag 19 januari 2015 @ 17:28:
In de nieuwe omgeving zal de backup strategie wellicht moeten worden herzien, maar ben nu goed te spreken over de huidige cyclus.

Het moment om je backup te herzien is dus nu.... Je zit nu in je ontwerpfase van je project. De mogelijkheden om virtuele machines te backuppen zijn behoorlijk uitgebreider dan fysieke machines. Daar zou je gebruik van kunnen maken.

En je maakt geen backup van je terminal server omdat daar geen actieve data op staat. Je weet dat je dan bij failure een herinstallatie moet gaan uitvoeren (inclusief aangeboden apps), in plaats van een simpele restore die max een kwartiertje duurt? Dat zou ik zeker gaan aanpassen...

Datzelfde geld voor server 2 overigens, ook van die server is de keuze gemaakt om die niet volledig te backuppen.

[ArcticTiger]

Question Mark schreef op dinsdag 20 januari 2015 @ 08:53:
[...]

Het moment om je backup te herzien is dus nu.... Je zit nu in je ontwerpfase van je project. De mogelijkheden om virtuele machines te backuppen zijn behoorlijk uitgebreider dan fysieke machines. Daar zou je gebruik van kunnen maken.

En je maakt geen backup van je terminal server omdat daar geen actieve data op staat. Je weet dat je dan bij failure een herinstallatie moet gaan uitvoeren (inclusief aangeboden apps), in plaats van een simpele restore die max een kwartiertje duurt? Dat zou ik zeker gaan aanpassen...

Datzelfde geld voor server 2 overigens, ook van die server is de keuze gemaakt om die niet volledig te backuppen.

Daar heb je zeker gelijk in, iets waar ik ook goed over moet nadenken.
Maar dan zal ik ook eerst voor mezelf duidelijk moeten hebben hoe ik de data opslag ga regelen, wat ik wel en niet virtueel ga draaien etc. etc.

Ik begin nu toch te denken, als het inderdaad onder de mogelijkheden valt en niet te veel complicaties meebrengt, om dan ook de AD/DC virtueel te gaan draaien, en dan voor 2 lichte fileservers te kiezen, en zal ik storage spaces moeten laten vallen ten faveure van een shared storage voor de fileservers.

[Question Mark]

Als dat soort technische zaken vloeien voort uit je eisen en wensen met betrekking tot je gewenste beschikbaarheid. (ik vroeg er niet voor niets naar )

Bepaal dus eerst welke diensten je HA wilt aanbieden, en pas je technische oplossing daar op aan.

[ArcticTiger]

Terug naar de "tekentafel" dan zoals ze dat zeggen

Had al wel een IOPS meting opgezet maar heb er momenteel weinig aan gezien er een aantal zieken zijn en dus ook een aantal archiverings werkzaamheden stil liggen, dus echt representatief is de meting dan niet

Ik zal niet de hele geschiedenis van onze omgeving oprakelen, maar de oorsprong van dit HA idee ligt bij ons TMS pakket.
Dit draaide voorheen (een aantal jaar geleden) op een oude server, welke via een geïmproviseerde heartbeat werd gespiegeld naar een 2e server.
Helaas was de monitoring nooit echt goed gedaan, en bleek achteraf dat de 2e server na het booten crashte op juist die heartbeat.
Toen uiteindelijk na een stroomstoring (dipje op het 220 netwerk, alles bleef draaien, behalve de servers die op de UPS waren aangesloten...) de 1e server de geest gaf waren we 4 uur aan data kwijt, een kleine ramp zeg maar
We hadden al wel een nieuwe versie van het TMS op een andere server draaien en dus die versneld in productie gegooid (er waren gelukkig al wel trainingen gegeven dus de overgang was gelukkig geen ramp)

Anyway, om dit in de toekomst te voorkomen is dus bedacht om virtueel te gaan met failover.
Het TMS systeem is het belangrijkste, same met de Oracle database.
Helaas is er zo enorm veel onduidelijkheid over de licensering van Oracle producten dat ik het niet aandruf om deze te virtualiseren vanwege eventueel te verwachten torenhoge licentiekosten (ik moet elke host in mijn omgeving licenseren? wtf?)

Echter om voor enkel 1 pakket ene complete HA omgeving op te tuigen vind ik overkill en dus wil ik zo veel mogelijk hier in meenemen en zo min mogelijk fysiek overhouden.
(Onze terminal server is net 2 jaar oud dus die zal vooralsnog fysiek blijven)

En zo kom ik op het lijstje dat ik dus eerder al plaatste:

• Ons TMS pakket
• Webportal van ons TMS pakket (verre van heavy use)
• Onze SQL server (is zelf SQL express, daar wij deze momenteel alleen gebruiken voor een sales pakket en ons backup pakket), geen heavy use dus
• e.e.a. aan management tools voor telefooncentrale, toegangsbeheer tot het pand etc
• e.e.a. aan klein grut wat niet bedrijfskritisch is

Wat betreft de AD/DC ben ik er nog niet over uit of die nu wel of niet virtueel kan

En meteen stel ik mezelf de vraag: heb ik echt SSD nodig voor de VM opslag of zijn 15k schijfjes ook voldoende...

[ Voor 4% gewijzigd door ArcticTiger op 20-01-2015 15:34 ]

[ArcticTiger]

Even een vraag tussendoor:
Heeft iemand ervaring met de JBOD enclosures van DataOn Storage?

Ik kan hier totaal niets over vinden qua leveranciers etc.

[Dennism]

Oracle en virtualisatie zou ik niet aan beginnen, tenzij je echt een go hebt van je oracle license boer. Oracle doet nogal lastig met failover en resources waardoor je (in ieder geval de laatste keer dat ik er mee te maken had) je alle cores in alle hosts e.d. moet afdekken met licenties voor Oracle omdat Oracle soft-partitioning niet als een valide vorm van het verdelen van resources ziet.

Je kan er voor kiezen m.b.t. je AD om een van je DC's fysiek te houden, dit zou echter tegenwoordig niet meer nodig moeten zijn, qua hardware is AD echter zeker in kleine omgevingen niet al te kritisch en draait het vaak prima op een zeer lichte machine, je 2de DC zou ik altijd virtueel uitvoeren (ik zou i.i.g. niet maar 1 DC willen hebben in een productie omgeving), virtuele DC's kun je in mijn ervaring prima uitrollen in Windows Core modus met 1 core en 512MB/1GB ram.

[hans_lenze]

ArcticTiger schreef op donderdag 29 januari 2015 @ 15:54:
Even een vraag tussendoor:
Heeft iemand ervaring met de JBOD enclosures van DataOn Storage?

Ik kan hier totaal niets over vinden qua leveranciers etc.

Je gaf aan een voorkeur te hebben voor IBM, Lenovo heeft de 'kleine' server spullen van IBM overgenomen en ze maken als voorbeeld de SA120.

Stiekum komen de meeste JBODs bij Quanta, Supermicro of een andere OEM vandaan. Grootste verschil is de support organisatie die er achter zit.

[ArcticTiger]

hans_lenze schreef op vrijdag 30 januari 2015 @ 08:43:
[...]


Je gaf aan een voorkeur te hebben voor IBM, Lenovo heeft de 'kleine' server spullen van IBM overgenomen en ze maken als voorbeeld de SA120.

Stiekum komen de meeste JBODs bij Quanta, Supermicro of een andere OEM vandaan. Grootste verschil is de support organisatie die er achter zit.

De Thinkserver SA120 heb ik inderdaad gezien, maar ben daar niet helemaal van overtuigd.
Daarnaast is deze enkel te verkrijgen in 3,5 inch uitvoering, ga ik er toch een aantal van nodig hebben dan.

Tevens gaatmijn voorkeur naar IBM (op dit moment) omdat:
a) Wij gebruiken al jaren IBM en daar hebben wij geen noemenswaardige problemen mee gehad
b) Vooralsnog heeft IBM als enige een tool (SSCT) waarmee ik offline heel simpel een server (of zelfs complete racks) kan configureren inclusief een "IBM Estimated Price" en alle mogelijke opties en configuraties zijn bijna volledig aan te passen.

Ik heb geprobeerd om e.e.a. voor elkaar te krijgen op zowel de HP als Dell sites, maar verdwaal daar letterlijk in een doolhof aan verschillende modellen

~~~~~~~~~~~~~~~~~~~~

Even verder wat betreft de storage
Heb nu een schema opgezet voor de IOPS metingen, welke aanstaande maandag in zal gaan
Dus zal nog een weekje geduld moeten hebben

Wat betreft verdere virtualisatie
@Dennis
Oracle zal inderdaad niet gevirtualiseerd worden, ik vergelijk het maar met het porren met een stok in een wespennest wat betreft licenties...

Wellicht zal ik de AD/DC in zijn geheel virtueel gooien, met eventueel een 2e erbij als backup, als dit inderdaad volledig virtueel kan zonder nadelige gevolgen voor zowel de Hyper-V als de File Server clusters.

Het betreft een redelijk kleine omgeving, +/- 50 gebruikers op fysieke werkstations, stuk of 4 op een terminal server.
We draaien nu ook op een enkele AD/DC, welke tevens ook alle file hares host, met een enkele SQL Express 2005 server

Wat betreft backup
Ik heb me wat in zitten lezen op VEEAM, maar heb nog steeds geen flauw benul hoe dit nu daadwerkelijk aangepakt wordt.
Waar draait de "Main" applicatie?
Draaien er agents op de Hyper-V hosts, of een agent per VM?

[ Voor 5% gewijzigd door ArcticTiger op 30-01-2015 09:37 ]

[hans_lenze]

Als je fan bent van IBM, moet je tegenwoordig bij Lenovo aankloppen. Zie ook de site van IBM zelf:



Of de IBM tools nog werken met een Lenovo sticker op de doos weet ik niet, dat kan support je vast vertellen.

De JBOD Dell storage serie heet PowerVault. De modellen:
MD1200 - 12x 3,5" oud model
MD1220 - 24x 2,5" oud model
MD1400 - 12x 3,5" nieuw model
MD1420 - 24x 2,5" nieuw model
MD3060e - 60x 3,5"

De JBOD HP storage serie heet D3000. De modellen:
D3600 SAS LFF
D3700 SAS SFF - 25x 2,5"
D6000 SAS LFF - 35x 3,5"
En vast nog een aantal die ik niet ken.
Geen van de HP apparaten staat op de Storage Spaces HCL.

Veeam:
Bij een Veeam installatie heb je een aantal rollen.
Database - bevat de taken en de resultaten van de taken voor het overzicht in de GUI.
Console - GUI en scheduler. Hier beheer je de Veeam installatie en taken. Ook is deze rol verantwoordelijk voor het starten en coördineren van de taken.
Repository - Plek om back-ups op te slaan. Als dit een Windows of Linux server is, draait hier een datamover proces.
Proxy - De datamover die bij de bron de VM back-up regelt

Een kleine installatie bestaat uit een enkele fysieke server met een hoop lokale opslag. Op deze back-up server komt een SQL express database, de console en de repository. De Hyper-V hosts krijgen elk een proxy. Er wordt nooit een agent in de VM zelf geïnstalleerd maar er wordt vanaf de host en via het netwerk gebruik gemaakt van de VSS providers en writers in de VM.
Zie ook http://helpcenter.veeam.com/backup/80/hyperv/simple.html

[ Voor 9% gewijzigd door hans_lenze op 30-01-2015 11:24 . Reden: Mooie link naar de Storage Spaces HCL ]

[ArcticTiger]

Zo op het eerste gezicht ziet er met VEEAM toch een beetje tricky uit.
Helemaal als ik het vergelijk met de huidige backup situatie, waarbij we gebruik maken van rotating removable media:
- weekend: full backup (doet er 19 uur over)
- doordeweeks: differential backup (doet er 5 uur over)
-- op het moment van een wekelijkse full backup zijn altijd de vorige full backup + de laatste differential backup aanwezig in de kluis
- elke 1e dag van de maand: full backup, welke vervolgens in de kluis komt te liggen voor 12 maanden
-- de backup die op 1 januari draait zal meerdere (7) jaren in de kluis blijven liggen (gezien de verplichting om data voor deze termijn te bewaren)

Zoals ik de informatie nu heb gevonden maakt VEEAM de backup naar een lokale repository (dus waardeloos als het pand bijvoorbeeld totaal afbrand), en zal er in diverse bochten gewrongen moeten worden om toch rotating removable media te kunnen gebruiken.

Backups lijken dus nog wat extra aandacht te vragen om dit goed geregeld te krijgen.

[Jazzy]

Die diverse bochten vallen wel mee denk ik, VEEAM backup & Restore kan gewoon naar tape schrijven namelijk.

[arjants]

Ik sta qua vervanging op hetzelfde punt at TS, mijn keuze is minder gericht op HA

2x HP Host met 128Gb RAM
Netapp E2724 SAS met 12x600Gb SAS (7.2T bruto)
vSphere 5.5 Essentials PLUS
Veeam Backup and Replication Small Business
Synology DS2015xs met 8x 3Tb WD red

Hosts worden met 10Gb FC aangesloten op switch en via glas naar pand hiernaast gebackupped naar NAS.
Binnen VEEAM word na de dagelijkse reverse incremental backup een 2e copyslag gedaan naar een 2e offsite synology die er de hele dag over mag doen met 100Mbit.

In het offertetraject kwamen diverse SAN's naar voren maar deze zit ruim onder de 10k en is uitbreidbaar en levert voor nu genoeg iops.

[ Voor 5% gewijzigd door arjants op 30-01-2015 12:26 ]

[ArcticTiger]

Jazzy schreef op vrijdag 30 januari 2015 @ 12:02:
Die diverse bochten vallen wel mee denk ik, VEEAM backup & Restore kan gewoon naar tape schrijven namelijk.

Momenteel schrijven wij naar USB schijven van 2TB.
Een tape oplossing hebben wij al vele jaren niet meer...

Het belangrijkste voor mij is:
Stel ik doe dit met VEEAM, en weet en externe copy te regelen (hou ik te veel vast aan removable media?) kan ik bijvoorbeeld na 5 jaar nog steeds een bestand restoren naar de staat waarin deze in den beginne was?

Ik zit voornamelijk met deze vraag doordat met VEEAM slechts éénmaal full backup wordt gedaan en daarna forever incrementals.
(Of ik moet dit verkeerd begrepen hebben)

[arjants]

Weekend job zal in mijn geval full zijn en daarna per dag een reverse incremental.
De jobs kunnen in stages weggeschreven worden naar primair en secundaire storage/tape.
met verschillende jobs kun je ook een full naar tape schrijven.
(ga ik eens per week doen om in de kluis te bewaren offsite, alle type libraries zijn aan te sturen.)

[ Voor 19% gewijzigd door arjants op 30-01-2015 13:15 ]

[ArcticTiger]

Hmm wat backup betreft zal ik me dan toch nog mar wat meer in moeten lezen

Wat de daadwerkelijke virtualisatie betreft zit ik er over te denken om uiteindelijk de RDS server ook te vritualiseren.
Deze wordt nu gebruikt door maximaal 6 mensen tegelijk.
De huidige fysieke versie is redelijk overkill met 2x 6-core Xeon en 32GB RAM
Wat voor specs moet ik de virtuele machine geven?
Ik zat de denken aan 4x vCPU met 16GB RAM o.i.d.

Zit er ook aan te denken om, zoals eerder al aangegeven dat het mogelijk is, de AD/DC virtueel te draaien.
1 zal zat zijn voor het aantal gebruikers hier (+/- 50 gebruikers)
Ik neem aan dat 4x vCPU en 16GB RAM ook hiervoor afdoende zal zijn?

Dit alles maakt dat ik de huidige RDS server kan gaan gebruiken voor andere zaken, zoals bijvoorbeeld de backup, en misschien de Hyper-V rol installeren om backups te testen.

[hans_lenze]

Een RDS server met 4x vCPU en 16GB RAM is best okee voor zo'n 20 gelijktijdige sessies.
Een DC rust ik meestal uit met 1 vCPU en 1GB RAM. Als het een wat grotere omgeving is wil ik er nog wel eens 2GB RAM van maken (boven de 250 gelijktijdige gebruikers).

Een tweede DC richt je niet in voor grotere capaciteit maar voor grotere beschikbaarheid.

[Question Mark]

ArcticTiger schreef op maandag 02 februari 2015 @ 14:32:
Wat voor specs moet ik de virtuele machine geven?
Ik zat de denken aan 4x vCPU met 16GB RAM o.i.d.

Daar is geen vuistregel voor en hangt sterk af van de gebruikte applicaties en het type gebruiker.

Ik heb wel eens 60 man laten werken op een dualcore machine met 4 GB geheugen wat prima ging. Ik ben ook wel eens een situatie tegengekomen waarin het voor 10 mensen nog niet vooruit te branden was met 24 GB memory en 4 cores.

Uitdelen van cpu-cores moet je overigens wat voorzichtig mee zijn op een virtuele RDS server. De kans dat fysieke cpu's overcommit worden speelt dan mee, met wat nadelen als gevolg. Meer cores op een vm levert niet altijd een performance verbetering op.

[ArcticTiger]

@Queston Mark
Wat cores/logische processors betreft zal ik uitgaan van een 1:1 verdeling (+ wat extra bewegingsvrijheid voor eventuele uitreiding)
Dus 1 vCPU per thread (of 2 per core, ligt eraan hoe je er tegen aan kijkt )
(Als ik 32 vCPU nodig heb zal elke hyper-v host 2x 10-core bevatten)

Wat RDS gebruik betreft is het puur gebruik van internet explorer en office (word/excel/powerpoint/outlook), geen zware bewerkingen.

@hans_lenze is met die specificaties een DC nog wel vooruit te branden?

Vergeef me mijn onwetendheid, maar wat betreft een 2e DC voor de beschikbaarheid.
Gaat dit ook op als de primaire DC ook virtueel is?
Hoe zit het met de AD rol dan?
Wordt deze dan gerepliceerd naar de 2e DC?

edit:
Tevens ben ik wel benieuwd naar wat voor specificaties ik de SOFS nodes moet geven wat betreft CPU en RAM

ALs ik hier en daar op internet speur kan ik niet echt iets concreets hierover vinden.
Bij Dell ben ik wel e.e.a. aan voorbeelden tegengekomen, waar ze een dual octacore Xeon met 96GB intern toepassen (google search 2e hit, PPT)

Mijn idee was eigenlijk meer een (dual) quadcore met 32GB intern aangezien het toch een redelijk kleine omgeving betreft.

Tevens zit ik toch te denken om de kosten te drukken de SSD's te vervangen voor 15k schijven (2000+ euro voor een 400GB SSD vind ik toch een beetje te...)

[ Voor 35% gewijzigd door ArcticTiger op 03-02-2015 11:29 ]

[hans_lenze]

ArcticTiger schreef op dinsdag 03 februari 2015 @ 10:11:
@hans_lenze is met die specificaties een DC nog wel vooruit te branden?

Vergeef me mijn onwetendheid, maar wat betreft een 2e DC voor de beschikbaarheid.
Gaat dit ook op als de primaire DC ook virtueel is?
Hoe zit het met de AD rol dan?
Wordt deze dan gerepliceerd naar de 2e DC?

Wat moet een domain controller allemaal doen?
Zeker in een kleine omgeving is het niet meer dan een mini database server. De NTDS.dit (de database van AD zelf) is enkele tientallen MBs groot. Dat past makkelijk in het geheugen. De DNS zone is domain integrated en zit in dezelfde database.
Als extra rollen zet men er nog wel eens DHCP en RADIUS op. Ook deze rollen hebben niet veel performance of geheugen nodig om hun werk prima te doen.
Server 2012R2 (met GUI) heeft kaal zo'n 300MB nodig om te draaien. Tel daar wat losse MBs bij op voor de verschillende rollen en het past prima in 1GB. Het wordt waarschijnlijk traag als je rond gaat klikken in een RDP sessie met alle management consoles open maar dat is niet de bedoeling: beheren doe je vanaf je eigen werkplek of een management server.

De tweede DC krijgt precies dezelfde rollen als de eerste: AD/DNS, DHCP en eventueel RADIUS. Door de tweede DC op een andere fysieke host te laten draaien kun je nog steeds inloggen en werken als de eerste DC niet beschikbaar is (Door Windows Updates, uitval van hardware of wat voor reden dan ook). Doordat alle rollen voor authenticatie dubbel aanwezig zijn, heb je een kleinere kans dat men niet meer in kan loggen. Replicatie zorgt voor het gelijk houden van de AD database op de beide domain controllers. Normaal wordt er gerepliceerd met een vaste interval maar als het belangrijk is (een wachtwoord reset bijvoorbeeld) vindt de replicatie onmiddellijk plaats.
De beide DHCP rollen werken samen om IP adressen in één scope uit te delen. https://technet.microsoft.com/en-us/library/hh831385.aspx

edit:
Tevens ben ik wel benieuwd naar wat voor specificaties ik de SOFS nodes moet geven wat betreft CPU en RAM

Mijn idee was eigenlijk meer een (dual) quadcore met 32GB intern aangezien het toch een redelijk kleine omgeving betreft.

Tevens zit ik toch te denken om de kosten te drukken de SSD's te vervangen voor 15k schijven (2000+ euro voor een 400GB SSD vind ik toch een beetje te...)

Je voorgestelde specificaties zijn prima voor de SOFS nodes.
Bij een SSD gaat het om de IOps per euro verhouding en dat winnen ze toch makkelijk van een 15k schijf.

[ Voor 3% gewijzigd door hans_lenze op 05-02-2015 00:02 . Reden: spelling ]

[ArcticTiger]

@hans_lenze mijn dank voor deze zeer waardevolle input.

Dit geeft me genoeg stof om een kleine testomgeving in te richten
(2 Hyper-V hosts en een enkele machine voor shared storage, aangezien het toch een testomgeving is )

De opzet zal simpel zijn

• 2x AD/DC/DHCP (elk voorzien van 1 vCPU, 1GB intern en 40GB HDD)
• 1x Print / License server (1x vCPU, 1 GB intern en 40GB HDD)
• 1x Management voor telefooncentrale etc (2x vCPU, 4GB intern en 40GB HDD)
• 1x RDS (4x vCPU, 8GB intern en 180GB HDD)

Ik ga er van uit dat 40GB HDD voldoende is voor een kale Server 2012R2 installatie met slechts enkele roles in gebruik

De WSUS role, kan ik die op een DC stampen of beter een afzonderlijke VM aanmaken? (heb geen flauw benul van de vereisten)

In de testomgeving laat ik de SQL server en onze TMS server achterwege, daar de testhardware niet echt voldoende is om dit ook te supporten

Ik ga voor de produtcie omgeving toch kiezen voor 15k schijven in plaats van SSD's voornamelijk gezien de kosten.
om 800 GB in RAID 10 te krijgen ins SSD heb ik toch 4 SSD's nodig van 400GB elk, totaal plaatje +/- 8000 euro
Ik kan me niet voorstellen dat het niet soepel draait op ene goede RAID 10 van 15k schijven

[Jazzy]

ArcticTiger schreef op donderdag 05 februari 2015 @ 10:15:
Ik ga er van uit dat 40GB HDD voldoende is voor een kale Server 2012R2 installatie met slechts enkele roles in gebruik

Minimaal vereist is 32 GB en ruimte voor je pagefile, dus voor een kale installatie is 40 GB inderdaad genoeg. Vervolgens gaat de Windows directory gestaag groeien en wordt bij iedere update iets groter. Je kunt dus beter werken met 50 GB of zelfs iets meer.

De WSUS role, kan ik die op een DC stampen of beter een afzonderlijke VM aanmaken? (heb geen flauw benul van de vereisten)

Google -> wsus domain controller
Google -> wsus system requirements