2012 R2 RDS Farm opzetten,

[gse]

Mijn vraag:
Hoe zet ik efficiënt een 2012 R2 server Farm op. Huidige situatie is een 2008 R2 farm met 2 fysieke servers specifiek bedoeld voor 1 applicatie die via Remote App gebruikt wordt. Alle benodigde licenties staan op een andere server.

Met een nieuwe server wil met 2012 R2 de RDS farm beginnen. Als die in de lucht is krijgt deze de naam van de oude farm zodat alle gebruikers via deze server werken. Dan worden de oudere servers opnieuw ingericht en toegevoegd aan de farm.

Toegang kan alleen vanaf het interne netwerk, daarom had ik de gedachte dat de Web Services Role niet nodig zou zijn. Echter in alle documentatie zou dit wel moeten. Daarbij kan ik in de farm slechts 1 server met de RD Connection Broker installeren. Klopt dit?
De andere servers die ik later toevoeg kunnen de RD Session Host rol krijgen, maar dat kan toch ook al op de eerste server?

Kan ik beter een extra virtuele server gaan gebruiken voor de RD Connection Broker (en misschien ook de RD WEB Access) en de 3 "zware" fysieke servers voor de RD Session host?

Op een testomgeving, met alles geïnstalleerd voor RDS heb ik alles met succes aan de praat, maar met het Farm verhaal ben ik er nog niet helemaal uit.

Ik weet, het zijn vele vragen, maar wie kan mij hiermee adviseren

Alvast bedankt,
Geert

[ Voor 87% gewijzigd door gse op 19-10-2017 16:27 . Reden: had nog niets ingevuld ]

[Craven]

Ik neem aan dat je per ongeluk op "plaats" hebt geklikt?

[mortal]

Geen idee wat de specificaties zijn van beide servers. Maar ik zou de fysieke servers inzetten als hyper-v host (zonder grafische shell) en losse vm's aanmaken, waaronder een losse vm als broker. Als je voor beide fysieke servers een windows 2012 r2 licentie hebt mag je op beide servers 2 vm's draaien.

Als extra redundantie zou je de vm's tussen de hyper-v hosts kunnen repliceren als disaster-recovery. Dit kost alleen extra storage, geen andere resources of licenties.

[ Voor 7% gewijzigd door mortal op 19-10-2017 16:59 ]

[gse]

De oude farm heeft 2 servers met 1 CPU 12 Core and 128 Gb geheugen. De nieuw server heeft 2 CPU's 16 Core en ook 128 Gb geheugen.
Hyper-V wordt hier niet gebruikt en zal dus geen optie zijn. Ik ben me nog heel druk aan het inlezen. Wat ik nog niet gevonden heb is zijn de "requirements".
Ik ga er vanuit dat de RD Session host de meeste capaciteit nodig zal hebben om de Remote App te faciliteren, hiervoor zijn deze 3 zware servers dan ook bedoeld.
De RD Connection Broker zou dan virtueel kunnen zijn (samen met de Web Server of kan ik af zonder Web Server?) op een VMware omgeving.

[Craven]

Volgens mij moet je prima af kunnen zonder web access. Het enige wat dat regelt is een website van waar je de remoteapp kan starten. Als jij een alternatieve manier hebt om de rdp file bij je gebruikers te krijgen ben je er ook.

De connection brokers size je met name op het aantal gebruikers, resources (remoteapp en remote desktop) en het aantal session hosts. Ik zie alleen het aantal users niet terug. Maar voor alles onder de 1000 moet je wel af kunnen met een simpele vm. Deze kan je nog dubbel uitvoeren maar dan moet je er wel een database achter zetten om het HA te krijgen.

Ik weet niet hoe het zit met overcapaciteit aan je session host kant. Maar als dat goed zit zou ik ze gewoon lekker fysiek gebruiken zonder hypervisor. Minder overhead en minder complexiteit. Waar ik wel zou zorgen dan is een geautomatiseerde deployment van die machines. Je wilt niet dagen een machine aan het her configureren zijn in geval van disaster recovery oid.

Is er een reden dat je niet direct over gaat naar server 2016 trouwens? Mainstream support van 2012 kapt er binnen een jaar alweer mee.

[MAX3400]

Is er een valide reden dat je je scaling CPU vs. RAM niet hetzelfde houdt t.o.v. de oude situatie? Hierdoor ga je binnen je farm dus mensen andere resources per sessie geven waardoor je klachten kan verwachten dat de performance minder goed is dan voorheen.

Oud: totaal 24 cores / 256GB RAM
Nieuw: totaal 32 cores / 128GB RAM

Verder lees ik niet of/waarom HT in gebruik is en in hoeverre dat wel/niet de performance van de betreffende applicatie kan beinvloeden.

Aangezien je fysieke servers hebt, zal je je nieuwe machine wel moeten voorzien van voldoende spindles (aanname) om het aantal spindles van de 2 oude machines te evenaren; ook hier doe ik voorlopig de uitspraak dat je performance-vermindering aan het aanbrengen bent op de omgeving.

Werk je trouwens met profile disks of roaming profiles? Heb je eventueel aanvullende software/hardware in gebruik om je loadbalancing / load-reporting correct aan het farm te koppelen?

Heb je de thin-clients uit Groot performance verschil RDP en RemoteApp nog in gebruikt? Hou je dan rekening dat sommige Kerberos/NTLM mogelijk niet meer gaat werken?

Gaarne termen 100% correct gebruiken; leest wat slordig van een systeembeheerder.

[ Voor 23% gewijzigd door MAX3400 op 21-10-2017 23:04 ]

[gse]

@MAX3400
In mijn eerste stukje staat dat als de nieuwe server in gebruik is de "oude" (2 jaar oud) opnieuw geïnstalleerd worden en toegevoegd aan de farm, dus de farm zal dan uit 3 fysieke servers bestaan.

In een testomgeving (zonder farm) had ik al een goed werkende situatie met de inderdaad thin-clients van mijn andere post. De meeste van deze 50 thin-clients zitten nog in de doos en zullen vanaf 2 maanden meer en meer in gebruik worden genomen.

Er wordt niet met profile disks of roaming profiles gewerkt. Zoals gezegd, deze terminal servers zijn specifiek voor 1 applicatie, waarvan bij het uitloggen ook de sessie niet opnieuw gebruikt mag worden voor de gebruiker.
Dit is omdat de terminal de locatie van een productielijn bepaald en daarmee dus ook de benodigde schermen en elektronische handtekening (MES). Als een gebruiker op meerdere lijnen werkzaam is moet dit voorkomen dat de verkeerde schermen getoond worden.

HT is in gebruik.

@Craven
Deze applicatie wordt door de leverancier nog niet ondersteund op 2016.
Voor de toekomst wordt rekening gehouden met nog 2 extra fysieke servers. Het totaal aantal gebruikers voor de applicatie zal rond de 100 liggen. Afhankelijk van hoe de applicatie draait met meerdere gebruikers zullen deze extra servers worden aangeschaft.
disaster recovery is een vereiste om aan te tonen, dus hier wordt nog aan gewerkt.
In ieder geval bedankt voor je informatie.

Op dit moment heb ik een virtuele omgeving opgezet om toch even wat meer te testen voor de farm. Ik hoop voldoende te hebben aan jullie input, maar dat laat ik weten.

[Question Mark]

gse schreef op maandag 23 oktober 2017 @ 13:32:
@MAX3400
In mijn eerste stukje staat dat als de nieuwe server in gebruik is de "oude" (2 jaar oud) opnieuw geïnstalleerd worden en toegevoegd aan de farm, dus de farm zal dan uit 3 fysieke servers bestaan.

Let even op je loadbalancing dan. Lastig loadbalancen als je RDS-hosts niet identiek gesized zijn.

[Craven]

Dat word idd ook nog een uitdaging. Ik weet in xendesktop de opties te vinden om dit soort load balancing te regelen. In Rds heb ik geen idee of het überhaupt bestaat.

[Question Mark]

Craven schreef op maandag 23 oktober 2017 @ 19:12:
Dat word idd ook nog een uitdaging. Ik weet in xendesktop de opties te vinden om dit soort load balancing te regelen. In Rds heb ik geen idee of het überhaupt bestaat.

Dat doet hij niet. De broker loadbalanced enkel op basis active en pending sessions. Advanced Loadbalancing zoals Citrix dat kent is niet aanwezig....

[MAX3400]

@Question Mark En dan vallen we mogelijk toch terug in virtualiseren. Zeker als er hele dikke hosts gaan worden ingezet, zou het voor de availability net zo slim zijn om alles op Hyper-V of VMware te gaan draaien, per host 4 tot 8 RDS-hosts in te richten (licentie-technisch wel duurder).

Voordelen:
- stopt een RDS-host, dan is er nog voldoende capaciteit over / minder sessies stuk
- loadbalancing "kan" op VM-metrics en inderdaad niet "native" RDS
- consolideren op basis van templating / makkelijker updates testen

Nadelen:
- licenties
- DNS / (meerdere) RDS Web; beheer & monitoring
- mogelijk geen hardware-passthrough voor GPU/disks indien benodigd

[Craven]

@MAX3400 je kan naar alle waarschijnlijkheid ook minder users per host kwijt. Of het kost je een stukje responsiviteit voor de users.

[Question Mark]

Craven schreef op maandag 23 oktober 2017 @ 21:58:
@MAX3400 je kan naar alle waarschijnlijkheid ook minder users per host kwijt. Of het kost je een stukje responsiviteit voor de users.

Dat hoeft niet, en is sterk afhankelijk van de schaalbaarheid van OS en gebruikte applicatie.

Ik heb in het verleden wel stresstesten met Citrix Edgesight gedaan met een bare-metal RDS host. Tot ongeveer 59 users ging prima, daarna liep de doorlooptijd van de test enorm op. Met het bijplaatsen van extra cpu, memory en spindles kregen wij dit niet verbeterd.

We hebben daarna een aantal virtuele Xenapp servers op dezelfde host geplaatst, en toen gekeken hoeveel users we kwijt konden op deze host. Dat aantal lag behoorlijk hoger. Wij liepen toen gewoon aan tegen een OS beperking icm de gebruike applicatie.

Door de hardware te segmenteren in verschillende RDS-hosts konden we dit probleem omzeilen.

Overigens is dit wel een tijdje terug. OS was de 64 bits versie van Windows 2008.

[Metalfreak]

Ik heb jarenlang met een cluster gedraaid waarbij een van de hosts ook connection broker was, werkt in principe ook als je wat krap in resources zit, maar is natuurlijk niet best practice. De connection broker doet verder niet zoveel behalve de sessies verdelen, zeker niet met slechts 100 users.

[Dennism]

Question Mark schreef op maandag 23 oktober 2017 @ 20:08:
[...]

Dat doet hij niet. De broker loadbalanced enkel op basis active en pending sessions. Advanced Loadbalancing zoals Citrix dat kent is niet aanwezig....

Met relative weight kan je natuurlijk wel een beetje sturen. Maar ideaal is het inderdaad niet. Een echte loadbalancer is altijd beter. Ik weet natuurlijk niet hoeveel users het hier betreft en hoeveel bandbreedte ze zullen trekken, maar kleine deployments met 2-3 RDS servers heb ik zelfs wel eens achter een Kemp Free Loadmaster draaiende gehad zonder issues. Terwijl je dan wel een fully featured loadbalancer hebt. Heb je uiteindelijk toch een zwaardere loadbalancer nodig kan je eenvoudig upgraden naar het volle product (alleen de license vervangen).