Vraag Wat zijn de nadelen van het runnen van een database in een virtuele machine? Hoe kan ik ze overwinnen? [Gesloten]


Als iets in een virtuele machine wordt uitgevoerd, heeft dit enige prestatieniveau, maar hoeveel kost het werkelijk invloed hebben op de prestaties van een databasesysteem?

ik vond dit academisch referentiedocument met enkele interessante benchmarks, maar het was een beperkte test met alleen Xen en PostgreSQL. De conclusie was dat het gebruik van een VM "niet duur" is (hoewel je misschien denkt dat de werkelijke gegevens anders zijn).

Wat zijn de technische, administratieve en andere nadelen verbonden aan het uitvoeren van een database binnen een virtuele machine?

Plaats antwoorden die kunnen worden ondersteund door objectieve feiten, ik ben niet geïnteresseerd in speculatie of enig ander semi-religieus argument (geek passie is goed in veel opzichten, maar dat zal ons hier niet helpen).

Dat gezegd hebbende,

  • Welke problemen komen op bij het uitvoeren van een database in een virtuele machine? (plaats alstublieft referenties)
  • Zijn deze kwesties belangrijk?      
    • Zijn ze alleen significant onder bepaalde scenario's?
  • Wat zijn de tijdelijke oplossingen?

64
2017-09-01 14:03


oorsprong


+1 Ik ben vooral geïnteresseerd in feedback over scenario's van SQL Server en Windows 2008 R2 - random65537
@Shane Madden - Kun je de sluiting een beetje uitleggen? Ik verwacht dat de motivatie werd aangedreven door een niet-specifieke antwoord (die vervolgens ontspoorde in de opmerkingen), niet de vraag zelf. Wat de vraag betreft, impliceren 44 stemmen en 12 favorieten binnen ruwweg één dag na het sluiten van de voorsluiting dat het een goede vraag was met nuttige antwoorden / informatie (vooral vergeleken met wat typisch lijkt te zijn voor ServerFault-vraagverkeer). Dit is waar de verschillende SE-sites op mikken. Had je liever een meer specifieke vraagstelling, versus het losse "hoe slecht is het?". - Russ
@ErikA, Shane, Womble, mikeyb, Ben - Ik heb een communitybewerking gemaakt die deze vraag wellicht constructiever maakt. Overweeg dit opnieuw te openen of een vergelijkbare vraag te stellen over een nieuwe / opschoningsvraag. - random65537


antwoorden:


Hoewel veel DB-leveranciers dit traag deden, ondersteunen bijna alle nu officieel hun software die in een gevirtualiseerde omgeving draait.

We voeren veel Oracle 11g-instanties in Linux op de top van ESXi, en het is zeker mogelijk om zeer goede prestaties te krijgen. Zoals met alle hardware-schalen, moet je gewoon zorgen dat de virtualisatie gastheer beschikt over voldoende bronnen (RAM, CPU) en uw schijflaag is in staat om elke gewenste IO-prestatie te leveren.


41
2017-09-01 14:35



+1 Zoals opgemerkt, Kritiek dat middelen aan de taak zijn. Disk is de grote bottleneck voor ons geweest en er is een zorgvuldige planning nodig. - Dave M
+1 U moet uw huiswerk maken in de database gebruik van tevoren. Als je fysieke doos wordt gehamerd boven 40% benutting dan beginnen je voordelen voor het oplossen. Dat gezegd hebbende, we hebben heel veel kleine applicatiespecifieke geïsoleerde sql's die draaien op vm's zonder probleem. Maar onze grote machines voor zwaar gebruik hebben speciale hardware vanwege het gebrek aan voordeel. - Nate
Zeker, Disk IO is de grote boosdoener, en welke gevirtualiseerde omgevingen de neiging hebben schilferig te zijn. - lynxman
@lynxman - Overeengekomen. We voeren al onze Oracle-instanties uit op onze tier 1 SAN-schijven, die 15 k SAS zijn. Van wat ik kan vertellen, krijgen we heel dicht bij de inheemse prestaties. - EEAA
"Een ounce van de test is een pond gissen waard." - Chris B. Behrens


Zoals ErikA zegt, wordt dit steeds gebruikelijker. Ik zit in het SQL Server-kamp en heb persoonlijk geen productiesystemen in VM's, maar ik zou niet aarzelen om (na een beetje meer studie over het onderwerp). Er zijn echter zeker enkele dingen waar je rekening mee moet houden voordat je op die weg gaat (althans voor SQL Server). Disk IO (zoals anderen al hebben vermeld) en geheugentoewijzing zijn slechts 2 voorbeelden. Het zal ook anders zijn tussen verschillende hypervisors.

Brent Ozar is een erkend expert in het virtualiseren van SQL Server, met name in VMWare. Ik zou het ten zeerste aanbevelen om zijn materiaal te lezen.

http://www.brentozar.com/community/virtualization-best-practices/


21
2017-09-01 15:00





Er bestaat kan en dan is er moeten. Een korvet kan 150 mph varen, maar moet je op openbare snelwegen? Je kunt jezelf onnodig pijn doen.

Databases zijn gastbesturingssystemen. Als ze beginnen, pakken ze blokken van een resource en beheren ze deze direct om prestatieredenen. Zodra u van het kernbesturingssysteem van de databaseserver een gast maakt in een gevirtualiseerde hostingomgeving, plaatst u een arbitragelaag met de hypervisor tussen het blok toegewezen element van schijf en RAM en de databaseserver. Het zal langzamer gaan. Hoe inefficiënter uw zoekopdrachten, hoe meer het zal vertragen. Deze inefficiënties kunnen vandaag op speciale hardware worden gemaskeerd, maar zodra u arbitrage op uw afhankelijke bron introduceert, zult u er snel achter komen.

Wat veel bean-counters die virtualisatie eisen niet herkennen, is dat databaseservers als gastbesturingssystemen hun eigen consolidatielaag bieden. Er is geen reden waarom u niet meerdere logische database-instanties op één fysieke server kunt consolideren, zelfs tot het punt van het verplaatsen van IP-adressen, het opzetten van extra hostnamen, enz ..., om deze natuurlijke coalescentie van services mogelijk te maken. En met dit model behoudt u niet alleen de kostenbesparingen die het management afdwingt voor een verminderd aantal fysieke hosts, maar behoudt u de blokkentoegang tot fysieke resources zonder de aanvalsmanoeuvre van de willekeurige hypervisor, die soms nuttige beslissingen kan nemen en niet anderen.

Hetzelfde geldt voor andere gastbesturingssystemen, zoals Java. Virtualisatie-oplossingen zijn meestal drukke omgevingen en de hypervisor moet veel beslissingen nemen over wie "het token" op een hulpbron krijgt. Elke keer dat je die laag kunt elimineren, ben je beter af.

Breng meerdere exemplaren samen met eerst de natuurlijke laag van het gastbesturingssysteem. De kansen zijn dat u gemakkelijker uw platformconsolidatie en prestatiedoelstellingen kunt bereiken.


11
2017-09-01 18:01



Interessante definitie van "gastbesturingssysteem." Terwijl je punt wordt genomen met betrekking tot pure, onvervalste prestaties, hoe vaak zijn je databases echt een knelpunt bij de CPU? I / O is veel waarschijnlijker, en voor toepassingen met hogere prestaties deelt u al I / O-tijd op een SAN. Ik zou hopen dat je je virtualisatie-filosofie zou heroverwegen wanneer een beveiligingsprobleem met één applicatie alle wachtwoord-hashes van je geconsolideerde databases compromitteert, of wanneer een proces dat in je JVM wordt uitgevoerd, elke byte aan beschikbare heapruimte verbruikt. - Shane Madden♦
Voor alle duidelijkheid, ik ben het er volledig mee eens dat een fijn afgestemde, enorm drukke, krachtige databaseserver zijn eigen fysieke hardware moet hebben. Maar dat is niet de norm, en de andere voordelen van virtualisatie zijn meestal groter dan de prestatieshit, die niet te onderscheiden is van de meeste workloads. - Shane Madden♦
Ik ben het niet eens met je punt om altijd eerst naar de bestaande consolidatielagen te gaan. Soms is dat logisch. Maar kijk bijvoorbeeld naar de kostencompensatie bij het opnieuw in evenwicht brengen van resources tussen het consolideren van meerdere databases op een enkel besturingssysteem en het consolideren van meerdere database / OS-combinaties bovenop een hypervisor. De eerste is efficiënter. De tweede is veel gemakkelijker om opnieuw in balans te brengen. Migratie en OS / database naar een nieuwe host is veel minder storend dan het migreren van een database naar een nieuw besturingssysteem. - Jake Oshins
Mijn opmerkingen komen van directe observaties in het veld van succesvolle en mislukte migraties naar virtualisatieoplossingen in het afgelopen decennium als een performance-engineer. Er zijn heel veel slechte database-apps waarvan het promiscueuze gebruik van hardware prestatieproblemen maskeert. Voeg virtualisatie toe en die problemen komen aan het licht. Als je een app hebt die een precieze klok vereist voor timing- of auditdoeleinden, ben je met de klok zweven in softwarevirtualisatie uit de buurt. - James Pulley
Wauw, wow gewoon James. Ik heb niet de tijd noch het geduld om alle punten die je hebt gemaakt in je antwoord en de daaropvolgende opmerkingen te verwoesten, maar ik voelde gewoon dat ik hier een opmerking moest plaatsen voor iemand die dit antwoord zou kunnen tegenkomen. De opvattingen van James zijn, zijn eigen, en weerspiegelen niet wat echt mogelijk is. Als je dan overingeschreven bent natuurlijk je gaat slechte prestaties leveren. Dus niet overdrijven. Het is perfect mogelijk om een ​​zeer goed presterende virtualisatieomgeving te hebben. Het is dwaas om een ​​algemene aanbeveling te formuleren omdat het "slecht presteert". - EEAA


Er zijn twee dingen om te realiseren:

  • De eenheid van DB-prestaties per eenheid hardware is iets lager voor een gevirtualiseerde db. Dit betekent dat je iets meer hardware moet kopen om hetzelfde prestatieniveau te krijgen.
  • Dat betekent niet dat hetzelfde niveau of een gewenst prestatieniveau onbereikbaar is. De winst die u behaalt met verbeterd beheer en andere voordelen (zoals gemakkelijker HA) vaak manier meer dan gecompenseerd de marginaal toegenomen hardware kosten.

Dat gezegd hebbende, waar ik werk, is onze Sql Server-installatie een van slechts twee servers die ik niet van plan ben snel te virtualiseren (de andere is de primaire DC).


6
2017-09-01 15:11





Het uitvoeren van SQL Server is een VM is prima, op voorwaarde dat u voldoende bronnen aan de VM kunt geven om uw toepassing uit te voeren. Als je in de fysieke wereld 24 cores en 256 Gigs RAM nodig hebt, dan moet je 24 vCPU's en 256 Gigs RAM in de virtuele wereld bieden.

Ik gewoon schreef een artikel in de afgelopen maanden SQL Server-magazine alles over het uitvoeren van SQL Server onder vSphere van VMware.


4
2017-09-02 00:26





Ik run twee databases, de ene PostgreSQL en de andere MySQL, in een virtuele omgeving (Xen) waar de dom0's zeer beschikbaar zijn. DomU-bestandssystemen bevinden zich allemaal op een iSCSI SAN LUN, uitgesneden met LVM2 logische volumes. De MySQL-database is uitsluitend voor Cacti en ziet dus helemaal niet veel gebruik, en bevindt zich ook op de iSCSI LUN.

De PostgreSQL-database is de database voor onze staging-omgeving en ziet daarom een ​​hogere benutting dan de MySQL db. Om deze reden bevindt de database zich op een lokale RAID10-set en wordt DRBD gerepliceerd naar het tweede clusterknooppunt. Echter, in termen van echte belasting ziet deze faseringsdatabase helemaal geen erg hoge belasting. Wat het naar mijn mening een goede / geweldige kandidaat maakt om te virtualiseren.

Enkele van de voordelen voor onze organisatie waren het lagere stroomverbruik, bespaarde rackruimte en minder hardware administratieve overhead.

Onze belangrijkste productiedatabase, aan de andere kant, ik kan me niet voorstellen dat ik virtueel ga ....


2
2017-09-01 19:00





Ik werk met MSSQL- en MySQL-servers op verschillende servers. Een paar jaar geleden was ik terughoudend om te beginnen met het instellen van SQL-servers op VM's omdat ik had gehoord over de prestatieproblemen van het uitvoeren van een SQL-server op een VM. Ik was echter verrast nadat ik mijn eerste paar SQL-servers had opgezet en geen verandering in de prestaties zag. Meer en meer van de servers waar ik aan werk zijn op VM en bijna alle grotere enterprise-clients waar ik voor werk hebben SQL-servers virtuuld.

Ja, de VM voegt wel wat overheadkosten toe en als je meerdere VM's op een enkele doos gaat hosten, heb je een goede server nodig. Een veel voorkomend probleem met bronnen is het toevoegen van extra VM's en het versmallen van de beschikbare bronnen. Het is gebruikelijk om wat groei te plannen, maar als je je server hebt gekocht voor het hosten van 2 of 3 VM's en nu zijn er 10 VM's draaien, dan zie je waarschijnlijk een prestatiehit.

Ik zou liegen als ik zou zeggen dat ik nog nooit prestatieproblemen heb gehad bij het draaien van een SQL-server op een VM. Maar ik heb geleerd dat als je slechte prestaties ziet, er waarschijnlijk iets mis is met de omgeving.


2
2017-09-02 03:26