Veel geheugen of SSD?

[geerttttt]

Hallo,

Wij zijn bezig met een project om ons softwareproduct te virtualiseren, dit om kosten te besparen en alles op 1 centrale plek te kunnen hebben draaien. Wij lopen echter alleen nu tegen een lastig punt aan.

Voorheen was bij ons de situatie zo: de software draait op een server waar aanbevolen werd 4 gig geheugen in te stoppen, de software maakt hier ook aardig gebruik van omdat hij daarmee veelgebruikte databestanden ging cachen. Dit met als oogpunt dat memory sneller is dan data i/o en de data i/o meestal nog wel is de bottleneck is/was.
Eigenlijk zijn het meestal documenten (van een 100tal kb tot soms een aantal MB) die in de cache gegooid worden, zodat als deze opgevraagd moeten worden, ze klaar staan in het geheugen.

Nu we gaan virtualiseren is geheugen een wat lastiger punt. Als ik 4 gig per VM instel ben ik zo door mijn geheugen heen en mag ik veel bankjes in mijn server proppen. De vraag is nu, wat is slimmer (snel genoeg en voordeliger), veel geheugen erin stoppen? Of is tegenwoordig SSD een goede optie? (Of meerdere SSD in raid bijv?)

Ik heb wel rondgezocht, maar echt concrete antwoorden op mijn situatie kan ik niet vinden.

Ik moet zeggen dat ik ook niet heel erg thuis ben in de serverhardware wereld, eigenlijk zorgden we voorheen gewoon voor degelijke dell servers met 4gb geheugen minimaal en dat werktte prima.

Heeft iemand een tip of idee hoe hij het zou aanpakken?

[loewie1984]

Wat zeggen de whitepapers, best practices van het product dat je wilt gaan virtualiseren? Microsoft heeft bijv. prima beschreven of en hoe je een SQL server kunt virtualizeren. Ik raad je aan dit ook bij de vendor van je product te informeren. Dan krijg je ook meteen inzicht in de gewenste configuratie als virtualisatie ondersteund wordt.

[jotheman]

Wat je kunt doen is (als je de licentie ervoor hebt...) ESXi draaien en daar een SSD instoppen. Die kun jeinstellen zodat wanneer het geheugen van de machine vol is er automatisch naar de SSD wordt "geswapt". Een optie die VMware biedt en wat het beste van 2 werelden lijkt. Hoe de performance is weet ik zo niet tho...

[geerttttt]

loewie1984 schreef op dinsdag 01 mei 2012 @ 11:08:
Wat zeggen de whitepapers, best practices van het product dat je wilt gaan virtualiseren? Microsoft heeft bijv. prima beschreven of en hoe je een SQL server kunt virtualizeren. Ik raad je aan dit ook bij de vendor van je product te informeren. Dan krijg je ook meteen inzicht in de gewenste configuratie als virtualisatie ondersteund wordt.

Wij zijn de vendor, wij ontwikkelen het product

[Jazzy]

Jullie zijn de vendor dus weten alles van het caching mechanisme, jullie zijn dan ook de eerste partij die kan aangeven hoeveel IOPs je genereert als je de cache verkleint. Als je dat niet beredeneren kunt dan kun je misschien beter gaan meten. Zorg voor een herproduceerbare belasting van jullei applicatie en meet de IOPs, geheugengebruik en het effect op de gebruikerservaring. Halveer nu de cache en kijk wat er gebeurt met IOPs. Vervolgens kun je onderzoeken wat je aan snelheid kunt winnen door voor andere storage te kiezen.

Nu we gaan virtualiseren is geheugen een wat lastiger punt. Als ik 4 gig per VM instel ben ik zo door mijn geheugen heen en mag ik veel bankjes in mijn server proppen. De vraag is nu, wat is slimmer (snel genoeg en voordeliger), veel geheugen erin stoppen? Of is tegenwoordig SSD een goede optie? (Of meerdere SSD in raid bijv?)

Ik zie het probleem niet zo, een typische virtualisatiehost heeft tegenwoordig 96 GB. Dat betekent dat je op één host ongeveer 23 virtuele servers kunt draaien, je maakt mij niet wijs dat je een grotere VM density wilt bereiken.

En andere kun je nog eens kijken naar de mogelijkheden die de hypervisor biedt om het geheugen voor je VM's te managen. De meeste hypervisors kunnen het geheugen efficiënt verdelen op basis van de hoeveelheid geheugen die de VM daadwerkelijk nodig heeft op een bepaald moment. Misschien dan je dan wel naar 40 VM's per host kunt.

[fds]

Ben het eens met Jazzy. Ga eerst eens meten, bepaal de bottlenecks en de benodigde specificaties. Daarna kan je pas aan oplossingen denken.

Mogelijk is er al heel erg veel te bereiken met optimalisatie van de software zelf. Eventueel via gescheiden services, zodat het e.e.a. schaalbaarder wordt. Vervolgens kan je kijken naar caching (per service). Als laatste ga je pas de hardware aanpakken, omdat dit de verspreiding en het gebruik van de software zal beperken.

Veel geheugen is nooit fout, maar dan moet je wel zeker weten dat het ook echt nuttig gebruikt wordt (zeker onder Windows). Als betrouwbaarheid een rol speelt gebruik je SSD's liever niet, tenzij het voornamelijk lezen betreft. Tuning van het OS kan ook nog wat extra's opleveren (vooral op Linux).

Verder heb je het over virtualiseren. Waarom als je nu al perfomance problemen hebt?
Als het op een dedicated server niet goed werkt, komt je er met virtualisatie op een enkele server ook niet.
Qua performance lijkt iedereen te vergeten dat je met virtualisatie een dedicated server deelt met anderen en dat je daar geen enkele invloed op hebt.

Jouw beschrijving mist informatie over de opbouw van de software. Zonder dat valt er geen optimaal hardware systeem te ontwerpen.

[PerfectPC]

Geheugen is tegenwoordig spotgoedkoop, fysiek althans. Maar, dat wil niet zeggen dat je al dit geheugen poerse goedkoop kan aanspreken op een virtualisatiehost. In vSphere 5 bijvoorbeeld is geheugen een heel pak duurder geworden per licentie. In dat opzicht lijkt een SSD dus goedkoper te worden.
Je moet uiteraard ook de vraag stellen hoe vaak dezelfde gegevens worden opgevraagd, maw: is het nuttig om te cachen in geheugen of is het zinvoller disk IO te versnellen?
En tenslotte: waarom kiezen en niet voor beide oplossingen gaan?

[HTT-Thalan]

Kijk eens naar FusionIO. Dat is flash op PCI-E, maar niet met traditionele SSD-style toegang: het gebruik DMA-toegang, net zoals geheugen.

Het is echt ongelooflijk snel (heb er al enkele weken eentje in mijn lab voor testdoeleinden) en de instapkaarten beginnen al vanaf 6000 dollar voor enkele honderden gigabyte. Heb resultaten gezien van 0.035ms toegangstijd op een opslagcapaciteit van in mijn geval 640gb, en doorvoer tot 800 megabyte/sec.

Je kunt het dus als local storage gebruiken, maar ook als cache inzetten, de meegeleverde software staat beide toe. 100% ondersteund onder ESXi en dus ook als datastore in te zetten.

Overigens doet VMware vSphere (versie 5 in ieder geval) ook aan geheugendeduplicatie: als je meerdere VM's hebt draaien met gemeenschappelijke data in het geheugen, neemt die maar één keer de ruimte in.

[ Voor 24% gewijzigd door HTT-Thalan op 08-05-2012 14:42 ]