Aparte storage voor virtualisatie of niet?

[wallum]

Wij gaan binnenkort onze terminalservers vervangen en dan ook voor het eerst met virtualisatie van servers werken. Ons automatiseringsbedrijf adviseert ons om daarbij een storage (MSA) aan te schaffen maar ik heb twijfels of de voordelen opwegen tegen de kosten. Weet iemand daar iets meer over?

Het betreft een instelling met 60 medewerkers die veel op afstand werken. Daarom gaan we gebruik maken van Citrix Xenapp. Citrix gaat draaien op 3 (later uit te breiden naar 4) Win2008-servers. Dit zijn de applicatieservers waarop de gebruikers inloggen en waar Office, Outlook, Exact-client en IE draaien. Domaincontroller, printserver/backup, Exchange en Exact draaien allemaal op aparte fysieke servers die niet zijn gevirtualiseerd en recent vervangen, dus voorlopig ook niet gevirtualiseerd zullen worden.

Voor de terminalservers kopen we HP DL360’s. Met virtualisatie hoeven we er maar 2 te kopen in plaats van 4. In principe kan 1 DL360 zelfs 4 virtuele terminalservers draaien, maar vanwege redundantie willen we er 2 en dan hebben we bovendien genoeg ruimte om later eventueel eenvoudig een extra server toe te voegen. De virtualisatie doen we op Citrix Xenserver.

De vraag is nu hoe we de schijfruimte voor de terminalservers aanschaffen: gewoon harddisks in de HP DL360’s of een aparte MSA (dan zijn harddisks in de DL360’s niet nodig). Een aparte MSA kost zo’n E 8000,- extra, bijna een verdubbeling van de hardware-investering. Wat krijg je daarvoor? De MSA is niet nodig voor data-opslag, die staat al op de fileserver. Het gaat alleen om besturingsprogramma en applicaties van de virtuele terminalservers.

Volgens onze automatiseerder zijn er een aantal onderhoudswerkzaamheden, met name aan de hardware, die zonder MSA tot downtime leiden en met MSA niet. Bij uitval van een van de 2 servers kunnen de gevirtualiseerde terminalservers makkelijk worden overgezet op de andere fysieke server als je een MSA hebt, zonder MSA zal je meer downtime hebben. Ik geloof dat wel, maar hoe vaak komen dit soort werkzaamheden nou voor? En kun je dan niet beter een 3e DL360 kopen voor de helft van de aanschafprijs van een MSA? Stabiliteit en beperking downtime zijn voor ons belangrijk, maar niet tegen elke prijs.

Volgens onze automatiseerder heeft een aparte storage ook als voordeel meer schaalbaarheid, snelheid en flexibiliteit maar is dat overtuigend?
- Schaalbaarheid: je kunt ook in een DL360 extra schijfruimte zetten.
- Snelheid: lijkt me eerder lager dan hoger als de schijfruimte niet in de DL360 zit, maar in een apart apparaat.
- Flexibiliteit: je hebt vast iets meer mogelijkheden met een aparte storage, maar ik zie daar nu geen toepassingen voor.

Zie ik nu nog voordelen van een MSA over het hoofd?

[DGTL_Magician]

Nu zou ik zelf niet zo snel voor een MSA kiezen maar Shared Storage levert wel degelijk toegevoegde waarde aan je Virtuele omgeving.

1) Schaalbaarheid, je VM's zijn opgeslagen op 1 centrale plek, hierdoor kunnen ze op elke machine draaien en live verplaatst worden. Als je capaciteit te weinig hebt plug je een nieuwe server in en je machines hebben meer processor kracht en geheugen te verdelen. Dit kan evt. ook dynamisch aan de hand van de resources die VM's vragen en tegenwoordig ook om stroom te besparen door het automatisch uit en inschakelen van de VMWare servers als deze nodig of niet nodig zijn.

2) Besparing, sommige Shared Storage oplossingen (zoals die van NetApp) bieden DeDuplicatie. Dit is een techniek die dubbele blokken uit de storage vist en in plaats daarvan de nieuwe verwijzing linked naar de oude. Als je dan bijv. 4 Windows 2003 servers hebt draaien zijn deze voor 80% hetzelfde en zullen dus een stuk minder ruimte in beslag nemen.

3) Veiligheid, de meeste Shared Storage oplossingen zijn meer redundant uitgevoerd dan een RAID5 setje in je server. Ik heb het dan over RAID, double parity disks, CRC checks, etc. Je data is op een Shared Storage appliance waarschijnlijk veiliger dan in je servers.

[Gomez12]

Tja, moeilijk. Wat is de groeiverwachting voor de komende 3 jaar?

Want shared storage of MSA biedt zeker wel voordelen, maar of het het geld waard is om dit te doen voor 2 fysieke servers?

Persoonlijk zou ik eerder kijken naar waar ik die MSA op de lange termijn nog meer voor zou kunnen inzetten. Ik zou bijv ( op termijn ) je print-server ook virtualiseren en je files naar je shared storage verplaatsen. Maar als je dit niet wenst en de MSA enkel dienst zou doen als boot-schijf voor 2 fysieke servers zou ik er de investering niet voor overhebben

[Ethirty]

In de situatie zoals je hem omschrijft waarbij de DL360's alleen als Citrix servers gaan fungeren zie ik shared storage niet echt als toegevoegde waarde. Er is immers geen centrale data en vMotion of HA achtige zaken is niet relevant. De servers hebben waarschijnlijk identieke functionaliteit en zijn op zich al een soort "cluster".

Het wordt pas interessant als je, zoals Gomez12 zegt, meer met je storage gaat doen. Of je nu meer met virtualisatie gaat doen, of gewoon al je data wilt centraliseren dan zou ik het wel overwegen. En of je dan een MSA moet kopen of dat er ook betere oplossingen voor hetzelfde geld zijn, daarvoor zou je dan bij je leverancier moeten kunnen aankloppen.

[Question Mark]

Waarom ga je virtualiseren? Je hebt twee DL360's die waar je enkel Xenserver op gaat zetten om in totaal 4 Xenapp servers te virtualiseren.

Is het dan niet veel handiger om twee xenapp servers fysiek uit te voeren?

[SpamLame]

Bedenk je ook dat je storage oplossing een SPOF is als je er maar één van hebt.
Daarnaast is tijdens onderhoud (bv firmware) van je storage aan te raden dat offline te doen, resultaat beide Xen servers plat.
Wat voor een MSA is aangeraden (type & interface)?

Persoonlijk zou ik de TS servers niet op shared storage doen omdat, het te duur is voor wat je ervoor terug krijgt. Daarnaast staat er bijna geen data op je TS (althans hier), profiel homedrives etc komen van andere servers of. Of dat bij jou ook zou werken moet je zelf bepalen.

[Verwijderd]

Als ik je openingsbericht zo lees geef je naar mijn idee zelf al antwoord op je eigen vraag.

Ik denk dat je het beste een PoC (Proof of Concept) kan opstellen waarbij je de nieuwe omgeving in het klein gaat opzetten.
Vanuit daar zou ik de omgeving bouwen en dan een soort pilot starten waarbij je lekker veel gaat meten om te zien of de gevraagde performance geleverd kan worden in je PoC.
Op basis van die bevindingen kun je uitspraken doen m.b.t. de juiste hardwarekeuze...

misschien beetje offtopic, bedoel je met de MSA een fiberchannel oplossing en heb je misschien nagedacht over de mogelijkheden van iSCSI o.i.d.?

[MADG0BLIN]

Verwijderd schreef op maandag 28 juni 2010 @ 14:20:
Als ik je openingsbericht zo lees geef je naar mijn idee zelf al antwoord op je eigen vraag.

Ik denk dat je het beste een PoC (Proof of Concept) kan opstellen waarbij je de nieuwe omgeving in het klein gaat opzetten.
Vanuit daar zou ik de omgeving bouwen en dan een soort pilot starten waarbij je lekker veel gaat meten om te zien of de gevraagde performance geleverd kan worden in je PoC.
Op basis van die bevindingen kun je uitspraken doen m.b.t. de juiste hardwarekeuze...

misschien beetje offtopic, bedoel je met de MSA een fiberchannel oplossing en heb je misschien nagedacht over de mogelijkheden van iSCSI o.i.d.?

De nieuwe MSA's heeft zowieso beide volgens mij en iSCSI en Fiberchannel.

[SpamLame]

MADG0BLIN schreef op maandag 28 juni 2010 @ 14:42:
[...]


De nieuwe MSA's heeft zowieso beide volgens mij en iSCSI en Fiberchannel.

Er is ook een SAS variant.
In de G3 is iSCSi niet gesupport voor XenServer.
Blijven over de FC(met ISCSI kan ook voor bv Windiws) en de SAS versie.
Wil je perse iSCSI icm HP MSA doen, dan kan je de MSA2300i kopen.
ZIe http://www.hp.com/storage/spock voor meer info.

[WhizzCat]

Volgens onze automatiseerder heeft een aparte storage ook als voordeel meer schaalbaarheid, snelheid en flexibiliteit maar is dat overtuigend?
- Schaalbaarheid: je kunt ook in een DL360 extra schijfruimte zetten.
- Snelheid: lijkt me eerder lager dan hoger als de schijfruimte niet in de DL360 zit, maar in een apart apparaat.
- Flexibiliteit: je hebt vast iets meer mogelijkheden met een aparte storage, maar ik zie daar nu geen toepassingen voor.

Zie ik nu nog voordelen van een MSA over het hoofd?

Schaalbaarheid is relatief. Met 2 DL machines is er gewoonweg niet veel te schalen.

Snelheid: een TS op een lokale raid 5 set is snel zat en bied in principe voldoende snelheid voor de pakketten die jij noemt. Dat zijn namelijk echt geen I/O verslinders (overigens is een MSA zo snel ook niet, vooral de extra schijven in de raid set doen het em).

Misschien in de toekomst zoals genoemd...? Wellicht een file server op een wat meer betrouwbare manier van storage voorzien?

Als ik zo eens lees wat je wil (2x fysiek, 4x XenApp) lijkt me een MSA overkill. Overigens zou ik i.p.v. de MSA gewoon de derde DL aanschaffen en dan 3x fysiek een XenApp bouwen (staat hierboven ook al ergens). Dan kan je 3x 50(?) users kwijt. Lijkt mij ruim voldoende. Dan heb je ook genoeg ruimte voor onderhouds windows etc.

Enfin, ik denk dat je leverancier gewoon wil verkopen op dit moment. Kosten/baten wegen volgens mij niet op tegen 3x een lokale Xen, danwel gevirtualiseerde omgeving op

[MADG0BLIN]

SpamLame schreef op maandag 28 juni 2010 @ 14:52:
[...]

Er is ook een SAS variant.
In de G3 is iSCSi niet gesupport voor XenServer.
Blijven over de FC(met ISCSI kan ook voor bv Windiws) en de SAS versie.
Wil je perse iSCSI icm HP MSA doen, dan kan je de MSA2300i kopen.
ZIe http://www.hp.com/storage/spock voor meer info.

Lijkt me een beetje vreemd, lijkt het alsof het zou moeten werken:

[SpamLame]

MADG0BLIN schreef op maandag 28 juni 2010 @ 15:25:
[...]


Lijkt me een beetje vreemd, lijkt het alsof het zou moeten werken:

[afbeelding]

Nee hoor niet vreemd, je plaatje geeft het immers goed aan (2 maal) met (FC Connect)

Zie ook de quick specs + 'n stukje naar boven scrollen.
Of de laatste firmware release notes > paragraaf operating systems

[ Voor 31% gewijzigd door SpamLame op 28-06-2010 16:38 . Reden: Nog een docje gevonden ]

[the-edge]

DGTL_Magician schreef op vrijdag 25 juni 2010 @ 18:56:
Nu zou ik zelf niet zo snel voor een MSA kiezen maar Shared Storage levert wel degelijk toegevoegde waarde aan je Virtuele omgeving.

1) Schaalbaarheid, je VM's zijn opgeslagen op 1 centrale plek, hierdoor kunnen ze op elke machine draaien en live verplaatst worden. Als je capaciteit te weinig hebt plug je een nieuwe server in en je machines hebben meer processor kracht en geheugen te verdelen. Dit kan evt. ook dynamisch aan de hand van de resources die VM's vragen en tegenwoordig ook om stroom te besparen door het automatisch uit en inschakelen van de VMWare servers als deze nodig of niet nodig zijn.

2) Besparing, sommige Shared Storage oplossingen (zoals die van NetApp) bieden DeDuplicatie. Dit is een techniek die dubbele blokken uit de storage vist en in plaats daarvan de nieuwe verwijzing linked naar de oude. Als je dan bijv. 4 Windows 2003 servers hebt draaien zijn deze voor 80% hetzelfde en zullen dus een stuk minder ruimte in beslag nemen.

3) Veiligheid, de meeste Shared Storage oplossingen zijn meer redundant uitgevoerd dan een RAID5 setje in je server. Ik heb het dan over RAID, double parity disks, CRC checks, etc. Je data is op een Shared Storage appliance waarschijnlijk veiliger dan in je servers.

Dat zijn wel 3 dikke speerpunten. Aanvulling op puntje 3: bij het aanschaffen van shared storage moet je zoveel mogelijk redundantie nemen. De meeste hebben ook zelfs dubbele controllers, dus mocht er 1 falen kun je nog (gedeeltelijk) door.

[MADG0BLIN]

SpamLame schreef op maandag 28 juni 2010 @ 16:30:
[...]

Nee hoor niet vreemd, je plaatje geeft het immers goed aan (2 maal) met (FC Connect)

Zie ook de quick specs + 'n stukje naar boven scrollen.
Of de laatste firmware release notes > paragraaf operating systems

Je hebt gelijk, ik dacht te lezen iSCSI... Niet goed gezien.

[Jazzy]

Voor een Terminal Server heb je vrijwel geen storage nodig, dus lokale storage (lees 2 schijfjes in mirror) is veruit de goedkoopste optie. Het ligt niet voor de hand dat je aantal gebruikers ineens zal verviervoudigen, dus schaalbaarheid is hier geen argument.

Omwille van redundancy heb je al de dubbele capaciteit gekozen, dus bij uitval van één server kun je de totale belasting kwijt op de 2 VMs op de overgebleven server.

Kortom, ik zie totaal geen toegevoegde waarde in shared storage voor deze 2 ESX servers.

[SpamLame]

the-edge schreef op dinsdag 29 juni 2010 @ 08:55:
[...]


Dat zijn wel 3 dikke speerpunten. Aanvulling op puntje 3: bij het aanschaffen van shared storage moet je zoveel mogelijk redundantie nemen. De meeste hebben ook zelfs dubbele controllers, dus mocht er 1 falen kun je nog (gedeeltelijk) door.

Dubbele controllers is leuk, maar dan heb ik nog steeds 1 shared storage oplossing, dus een SPOF.
Dus heb ik er twee nodig met replicatie voor (bijna) volledige redundantie.

Overigens zou ik het met local storage oplossen zoals ik al eerder aangaf en ook door Jazzy hierboven.

[ Voor 5% gewijzigd door SpamLame op 29-06-2010 09:51 ]

[Li0nHeart]

Je zegt dat je voor de redundantie 2 servers neemt. Wat gebeurt er als een van deze servers uitvalt?
Dan heb je nog maar 2 Terminal Servers.

Tenzij je 2 slapende TSen op beide servers hebt staan, zul je toch richting Shared Storage moeten gaan.
Anders heb je geen redundantie.

Je moet niet alleen naar het geld kijken, je moet je afvragen wat je wilt. Als je redundantie wilt, zul je daarvoor de benodigde stappen moeten zetten.

[Jazzy]

Li0nHeart schreef op dinsdag 29 juni 2010 @ 09:59:
Je zegt dat je voor de redundantie 2 servers neemt. Wat gebeurt er als een van deze servers uitvalt?
Dan heb je nog maar 2 Terminal Servers.

Tenzij je 2 slapende TSen op beide servers hebt staan, zul je toch richting Shared Storage moeten gaan.
Anders heb je geen redundantie.

Je moet niet alleen naar het geld kijken, je moet je afvragen wat je wilt. Als je redundantie wilt, zul je daarvoor de benodigde stappen moeten zetten.

De TS geeft toch aan dat hij vier Terminal Servers in zal zetten terwijl hij aan twee genoeg heeft? Dan maakt het niet uit hoe de belasting verdeeld is, bij uitval van één fysieke host (waarmee je dus twee Terminal Servers kwijt bent) kunnen de gebruikers die hun connectie kwijt zijn gewoon connecten met de overgebleven servers.

[Question Mark]

Li0nHeart schreef op dinsdag 29 juni 2010 @ 09:59:
Je moet niet alleen naar het geld kijken, je moet je afvragen wat je wilt. Als je redundantie wilt, zul je daarvoor de benodigde stappen moeten zetten.

Het gaat in totaal om 60 gebruikers. Een beetje DL360 met genoeg geheugen en cpu-capaciteit (en de door TS aangedragen applicatieset) kan met gemak deze userload aan (64 bits FTW).

Aangezien Xenapp loadbalancing kent heb je al redudancy vanuit je Xenapp farm.

Gewoon fysiek gaan draaien dus.

[Johnny E]

Question Mark schreef op dinsdag 29 juni 2010 @ 10:32:
[...]
Het gaat in totaal om 60 gebruikers. Een beetje DL360 met genoeg geheugen en cpu-capaciteit (en de door TS aangedragen applicatieset) kan met gemak deze userload aan (64 bits FTW).

Aangezien Xenapp loadbalancing kent heb je al redudancy vanuit je Xenapp farm.

Gewoon fysiek gaan draaien dus.

Het gaat er imho niet om of de server fysiek de load aan kan. De flexibiliteit die je krijgt door te virtualiseren is veel belangrijker en dat is naar mijn mening een reden om dit zeker in te zetten.

Een snapshot kunnen maken en eventueel terug zetten is al zo handig dat ik niet anders meer wil dan virtuele servers. Geen risico meer dat een update, slecht software pakket of dergelijke de Xenapp installatie verknalt en je de fysieke server opnieuw moet inrichten of restoren.

Ik zou niet zelf niet gaan voor een shared storage oplossing. Laat XenApp de loadbalancing doen.
Een TS omgeving is daarnaast veelal statisch, de gewijzigde data wordt elders op het netwerk opgeslagen.
Met regelmaat een backup of clone maken van de VM zou voldoende betrouwbaarheid moeten bieden.

Zorg dat er wel voor dat de backup of clone op snelle media staan zodat je deze snel kan terug zetten (dus geen tape).

Verder de resources goed eerlijk verdelen en geen overcommit laten toepassen.
Zie ook www.projectvrc.com en lees de whitepapers.

[ Voor 17% gewijzigd door Johnny E op 29-06-2010 16:07 ]

[Jazzy]

Johnny E schreef op dinsdag 29 juni 2010 @ 15:26:
Het gaat er imho niet om of de server fysiek de load aan kan. De flexibiliteit die je krijgt door te virtualiseren is veel belangrijker en dat is naar mijn mening een reden om dit zeker in te zetten.

Virtualiseren of niet virtualiseren is de vraag niet hier, de vraag is of de VMs op gedeelde storage moeten staan.

[Johnny E]

Jazzy schreef op dinsdag 29 juni 2010 @ 15:29:
[...]
Virtualiseren of niet virtualiseren is de vraag niet hier, de vraag is of de VMs op gedeelde storage moeten staan.

Wellicht dat de post na het toevoegen van een quote wat duidelijker is.

[Jazzy]

Johnny E schreef op dinsdag 29 juni 2010 @ 16:07:
[...]


Wellicht dat de post na het toevoegen van een quote wat duidelijker is.

Ja, dat is duidelijker.

[SpamLame]

Zoveel mensen zoveel meningen.
Het zou mooi zijn als TS zich ook weer meldt.

[Question Mark]

Johnny E schreef op dinsdag 29 juni 2010 @ 15:26:
[...]
Het gaat er imho niet om of de server fysiek de load aan kan. De flexibiliteit die je krijgt door te virtualiseren is veel belangrijker en dat is naar mijn mening een reden om dit zeker in te zetten.

Serverbasedcompting is zo ongeveer mijn vakgebied, en ik ken dan ook zeker de voordelen die het bied. Ik merk alleen in de praktijk vaak dat men gaat vitualiseren om het virtualiseren. Vergeet niet, virtualisatie is een middel en geen doel.

Een snapshot kunnen maken en eventueel terug zetten is al zo handig dat ik niet anders meer wil dan virtuele servers.

Een TS omgeving is daarnaast veelal statisch, de gewijzigde data wordt elders op het netwerk opgeslagen.

gewetensvraag: heb je echt snapshots en clonetecnieken nodig voor een omgeving die veelal statisch is en weegt dit op tegen de performancepenalty die je krijgt bij virtualisatie?

Ik wil er overigens niet een wellus nietus discussie van maken hoor. Als TS wil virtualiseren is daar niets verkeerds aan, mits het maar een weloverwogen keuze is.

32 bits terminal servers virtualiseer ik overigens ook gewoon vanwege consolidatievoordelen die dit bied. Bij 64 bits Xenapp Servers gaat mijn voorkeur uit naar bare-metal.

[Gomez12]

Question Mark schreef op dinsdag 29 juni 2010 @ 18:53:
[...]
gewetensvraag: heb je echt snapshots en clonetecnieken nodig voor een omgeving die veelal statisch is en weegt dit op tegen de performancepenalty die je krijgt bij virtualisatie?

Als je over 40 of meer fysieke servers praat wmb wel...

De performance penalty wordt dan opgevangen door het aantal servers ( of door een klein aantal heavy use servers, zo hebben wij standaard 5 servers staan waar tijd op ingeschaald kan worden en waar men dan ongestraft de opdrachten die langer dan 2 weken duren op kunnen draaien )

Mits goed geconfigureerd ( bijv alle telefonistes etc op 1 server, dat ding kan er dan wel 80 tegelijk aan ) en voldoende budget ( je hebt wel een aantal reserve servers nodig ) merk je helemaal niets meer van de performance penalty en houd je enkel de voordelen over. Enkel heb je dan ietwat meer fysiek ijzer nodig dan 2 servers...

[Question Mark]

Eigenlijk zeg je dus dat er wel degelijk een performance penalty is, maar dat je die oplost door meer systemen in te zetten.

Bij meerdere Xenapp servers, zou ik eerder adviseren om gebruik te gaan maken van Citrix Provisioning server. Dit is een Citrix produkt, wat niet de server virtualiseert maar enkel de OS-disk. Via streaming technieken wordt dan de OS-disk gestreamed naar naar de Xenapp servers. Een standard vdisk kan door meerdere systemen tegelijk worden gebruikt in een één op veel relatie. Afhankelijk van de versie Xenapp die je hebt beschik je "standaard" al over een licentie voor dit produkt.

Je houdt dan de voordelen van virtualisatie, maar kunt Xenapp vanaf bare-metal blijven aanbieden.

[/offtopic]

[kwiebus]

Question Mark schreef op dinsdag 29 juni 2010 @ 19:43:
Bij meerdere Xenapp servers, zou ik eerder adviseren om gebruik te gaan maken van Citrix Provisioning server.

Is dat ook niet een beetje overkill voor een handjevol Citrix servers?

[Jazzy]

Gaat het eigenlijk om 32-bits of 64-bits Terminal Servers?

[Zwelgje]

Jazzy schreef op dinsdag 29 juni 2010 @ 19:57:
Gaat het eigenlijk om 32-bits of 64-bits Terminal Servers?

ik neem aan 64bit aangezien XenApp 6 alleen voor R2 te krijg is

ik zeg: 2x DL360 neerzetten met genoeg ram en cpu en local disks gebruiken. redundancy heb je wel in de vorm van die 2 (of later meer) servers

voor een omgeving van 60 man zou ik niet de complexiteit van PVS willen gaan gebruiken. bij zon bedrijf loopt vaak niet eens een eigen sysadmin rond dus om een administratief medewerker met standard/private images te laten klooien

zon SAN is stoer om te hebben maar om een SAN te nemen 'voor de heb' dan spoor je mijns inziens niet helemaal net als virtualiseren om het virtualiseren zoals QuestionMark ook al aangeeft

QuestionMark

[ Voor 15% gewijzigd door Zwelgje op 29-06-2010 20:04 ]

[Question Mark]

Nieuwste versie Xenapp (6) is enkel geschikt voor 2008R2 en dus 64 bits only. Aangezien het om een nieuwe implementatie ga, ga ik er vanuit dat het dus 64 bits is.

te laat... had het kunnen weten

kwiebus schreef op dinsdag 29 juni 2010 @ 19:48:
[...]


Is dat ook niet een beetje overkill voor een handjevol Citrix servers?

Powershell schreef op dinsdag 29 juni 2010 @ 20:03:
[...]
voor een omgeving van 60 man zou ik niet de complexiteit van PVS willen gaan gebruiken. bij zon bedrijf loopt vaak niet eens een eigen sysadmin rond dus om een administratief medewerker met standard/private images te laten klooien

Dat ging even in op het voorbeeld van Gomez12 met 40 servers. Dan is CPS wel erg lekker...

[ Voor 72% gewijzigd door Question Mark op 29-06-2010 20:07 ]

[Jazzy]

Powershell schreef op dinsdag 29 juni 2010 @ 20:03:
[...]


ik neem aan 64bit aangezien XenApp 6 alleen voor R2 te krijg is

Ik haal die '6' niet uit de startpost, jij wel?

ik zeg: 2x DL360 neerzetten met genoeg ram en cpu en local disks gebruiken. redundancy heb je wel in de vorm van die 2 (of later meer) servers

Mee eens, iin geval van 64-bits Terminal Servers. Indien 32-bits, dan absoluut virtualiseren en liefst met XenServer.

[Verwijderd]

Mijn kennis gaat maar tot een bepaald niveau wat dit onderwerp betreft, maar heb je ook al eens gekeken naar HP P4000 series bijvoorbeeld? De voormalige LeftHand oplossingen, met name voor virtuele omgevingen volgens mij heel interessant. Als dit kant nog wel raakt in deze situatie hoor ik het trouwens graag

[kwiebus]

Jazzy schreef op dinsdag 29 juni 2010 @ 20:07:
[...]
Ik haal die '6' niet uit de startpost, jij wel?

Als je gaat beginnen met Citrix op Windows 2008 dan pak je toch geen oude versie?

[ Voor 3% gewijzigd door kwiebus op 29-06-2010 20:08 ]

[Jazzy]

Verwijderd schreef op dinsdag 29 juni 2010 @ 20:07:
Mijn kennis gaat maar tot een bepaald niveau wat dit onderwerp betreft, maar heb je ook al eens gekeken naar HP P4000 series bijvoorbeeld? De voormalige LeftHand oplossingen, met name voor virtuele omgevingen volgens mij heel interessant. Als dit kant nog wel raakt in deze situatie hoor ik het trouwens graag

De vraag is of shared storage überhaubt toegevoegde waarde heeft. En de vraag is inmiddels ook of virtualiseren überhaubt toegevoegde waarde heeft.

Volgens mij is de consensus dat shared storage niets toevoegt, en virtualisatie alleen bij een 32-bits workload. Toch?

kwiebus schreef op dinsdag 29 juni 2010 @ 20:08:Als je gaat beginnen met Citrix op Windows 2008 dan pak je toch geen oude versie?

Het is MKB, zou mij niets verbazen als daar weer het één en ander tussen zit wat niet ondersteund wordt op een 64-bits OS. Vandaar dat ik het vraag.

[ Voor 19% gewijzigd door Jazzy op 29-06-2010 20:10 ]

[Gomez12]

Question Mark schreef op dinsdag 29 juni 2010 @ 19:43:
Eigenlijk zeg je dus dat er wel degelijk een performance penalty is, maar dat je die oplost door meer systemen in te zetten.

Ach, die systemen heb je toch nodig vanwege redundancy etc.

Zoals wij het zien kunnen we of x servers ongetest op de plank laten liggen en in geval van nood maar hopen dat die nog werken, of we kunnen ze niet-mission critical inzetten en weten dat ze getest zijn en werken.
En wij hebben aan directie en leidinggevenden aangegeven dat op die machines wel langdurige taken gedraaid kunnen worden, maar in geval van nood dat deze dan als 1e gekilled worden ( en ik gok net zogoed als iedereen dat dit een shit-storm vanuit directie gaat opleveren mocht het nodig zijn, maar daar heb je een paper-trail voor ).

Jazzy schreef op dinsdag 29 juni 2010 @ 20:09:
[...]
Het is MKB, zou mij niets verbazen als daar weer het één en ander tussen zit wat niet ondersteund wordt op een 64-bits OS. Vandaar dat ik het vraag.

Het is niet enkel MKB, het is ook nog eens MKB met een minimaal aantal fysieke servers, ik gok zomaar dat het alletwee redelijke rommelservers zijn, je moet je rotzooipakketjes ( as in 32-bit etc ) etc toch ergens op kwijt. Verhef 1 server tot rommelserver en je halveert de helft van het serverpark...

[ Voor 24% gewijzigd door Gomez12 op 29-06-2010 20:45 ]

[Zwelgje]

Jazzy schreef op dinsdag 29 juni 2010 @ 20:07:
[...]
Ik haal die '6' niet uit de startpost, jij wel?
[...]
Mee eens, iin geval van 64-bits Terminal Servers. Indien 32-bits, dan absoluut virtualiseren en liefst met XenServer.

Xen,VMware, Hyper-V maakt qua performance geen drol meer uit tegenwoordig. voor TS loads is Hyper-V zelfs aan te raden volgens dat whitepaper wat jouw bedrijf uitgeeft

[Jazzy]

Powershell schreef op dinsdag 29 juni 2010 @ 21:10:
[...]


Xen,VMware, Hyper-V maakt qua performance geen drol meer uit tegenwoordig. voor TS loads is Hyper-V zelfs aan te raden volgens dat whitepaper wat jouw bedrijf uitgeeft

Dan lees ik niet goed. Voor wie het zelf uit wil zoeken de link nog maar een keer: http://www.projectvrc.nl/