Redactie - 16 januari 2015

Uw SQL Server-database virtualiseren in drie stappen

Toen virtualisatie voor het eerst zijn intrede deed in datacenters, waren veel opslagbeheerders sceptisch over de mogelijkheid om bedrijfskritische servers, zoals Microsoft SQL, te virtualiseren zonder een fors prestatieverlies ten opzichte van fysieke implementaties. Virtualisatietechnologie is in de loop der jaren echter een stuk volwassener geworden. Het is nu zelfs mogelijk om bedrijfskritische servers op veilige wijze op virtuele machines te laten draaien, mits u beschikt over een volledig ingerichte virtuele infrastructuur met een hoog beschikbaarheidgehalte.

Stap 1: I/Kenmerken van een SQL Server-database

Microsoft SQL Server is een relationele database-oplossing die zowel mogelijkheden biedt voor de beheer en analyse van dagelijkse activiteiten als voor data warehousing. De toepassing kent twee typen database-workloads: OLAP en OLTP. Als deze op bedrijfskritische servers draaien, is het belangrijk om inzicht te hebben in de uiteenlopende I/O-toegangspatronen die door elke workload worden gegenereerd.

OLTP-databases genereren een groot aantal gelijktijdige transacties die gepaard gaan met willekeurige lees- en schrijfbewerkingen (IOPS).

Typische kenmerken van workloads van OLTP-databases zijn:

  • De lees- als schrijfbewerkingen die op databestanden worden losgelaten, hebben over het algemeen een willekeurig karakter
  • Er is sprake van constante leesactiviteit
  • Het wegschrijven van informatie naar databestanden vindt plaats tijdens controlebewerkingen
  • De lees- en schrijfbewerkingen die op logbestanden betrekking hebben, hebben een sequentieel karakter

OLAP-databases en datawarehousing-systemen produceren doorgaans sequentiële leesbewerkingen in combinatie met een geringe mate van schrijfactiviteit, behalve wanneer er batch-updates plaatsvinden. De bandbreedte is in dat geval van veel groter belang dan de IOPS.

Typische kenmerken van workloads van OLAP-databases zijn:

  • Sequentiële lees- en schrijfbewerkingen – bulksgewijs invoegen van data en index-scans
  • Intensief gebruik van de TempDB
  • Een wisselende I/O-omvang die doorgaans groter is dan 8K
  • De I/O-omvang van de columnstore-index is meestal groter dan 256 KB

Stap 2: Best practices zijn niet altijd het beste

Wanneer u virtuele machines met Microsoft SQL Server gebruikt, is het belangrijk om u te houden aan de ‘best practices’ van de leverancier voor wie u heeft gekozen. Dit waarborgt optimale prestaties. Het is echter minstens zo belangrijk om te onthouden dat ‘best practices’ altijd worden gegeneraliseerd om aansluiting te vinden bij de meest voorkomende gebruiksscenario’s. Ze houden dus geen rekening met de unieke variaties binnen uw specifieke omgeving.

Als u optimale prestaties uit uw SQL Server-implementatie wilt halen, moet u rekening houden met het volgende:

  • De huidige workload van de virtuele CPU moet volledig transparant, geoptimaliseerd en beheerd zijn
  • Het virtuele geheugen mag niet zijn overbelast, en er mogen geen beperkingen worden opgelegd aan geheugenintensieve toepassingen.
  • De richtlijnen voor het netwerkontwerp moeten worden opgevolgd, en de management traffic en de VM-traffic moeten van elkaar worden gescheiden.

Stap drie: De configuratie – alles draait om de details

Het succes van een bedrijfskritisch systeem was traditioneel afhankelijk van de manier waarop het van meet af aan was ontwikkeld. Dat gold ook voor de hardwareconfiguratie. Bij virtuele instances van bedrijfskritische servers, zoals Microsoft SQL Database-servers, zijn veel van de best practices die we uit de wereld van fysieke servers kennen, onveranderd van toepassing.

De instellingen van virtuele machines kunnen een belangrijk verschil maken voor de prestaties en schaalbaarheid van SQL-servers. De VM-configuratie wordt door het besturingssysteem als fysieke server ervaren — het ziet RAM, CPU’s, NIC’s enzovoort. Wat SQL-servers betreft (fysiek dan wel virtueel) is de algemeen geaccepteerde mening dat schijven op basis van hun rol van elkaar moeten worden gescheiden. Elke schijf kent zijn eigen I/O-gedrag, prestatiebehoeften en vereiste niveau van isolatie. Al deze aspecten zijn van belang voor het waarborgen van adequate en voorspelbare responstijden.

De onderliggende opslag wordt normaliter gepresenteerd in de vorm van verschillende LUN’s, die stuk voor stuk zijn geconfigureerd met unieke RAID-types, prestatiebeleidsregels en toewijzingen aan fysieke schijven. Bij een virtuele machine wordt elke virtuele schijf die verband houdt met een bepaald type data in verschillende data stores ondergebracht. Een virtuele machine omspant daarmee doorgaans een groot aantal data stores (en soms zelfs meerdere storage arrays).

Bij traditionele opslag zijn er verschillende data stores nodig die stuk voor stuk zijn ingericht op basis van het specifieke I/O-patroon:

  • Data: Elke database voert ofwel willekeurige, of sequentiële I/O-bewerkingen uit.
  • Logbestanden: De toegang tot logbestanden heeft in de meeste gevallen een sequentieel karakter. De database schrijft data weg naar het logbestand, en vervolgens naar de database.
  • Temporary Database (TempDB): Deze database wordt gebruikt wanneer het systeem tijdelijke databasebewerkingen moet uitvoeren. De toegang tot TempDB heeft meestal een uiterst willekeurig karakter.
  • Back-ups: Back-ups van de database worden naar de speciale vDisk voor back-ups weggeschreven. Vaak is er sprake van één bestand per database. Databases worden vaak geëxporteerd naar een .BAK-bestand, dat vervolgens wordt gekopieerd naar een development- of testsysteem, zodat de meest actuele productiegegevens kunnen worden geïmporteerd. De toegang tot back-upvoorzieningen is sequentieel van aard.

Als u wijzigingen wilt aanbrengen om de prestaties te verbeteren, is het belangrijk om deze te testen. Zo kunt u nagaan of de werkelijke resultaten overeenkomen met de verwachtingen voordat ze hun weg naar de productieomgeving vinden. Een van de vele voordelen van virtualisatie is de mogelijkheid om snel virtuele machines te klonen en ze in een geïsoleerde omgeving te laten draaien. Opslagbeheerders zouden van deze mogelijkheid gebruik moeten maken door pre-productieomgevingen in te richten voor het testen van configuratiewijzigingen voor virtuele machines. Als ze tevreden zijn met de resultaten, kunnen ze de wijzigingen in productie nemen. Verrassingen kunnen zo tot een minimum worden beperkt.

Virtualisatie is inmiddels veel meer dan een modewoord. Opslagbeheerders hoeven niet langer sceptisch te zijn over het vermogen van deze technologie om bedrijfskritische servers te ondersteunen en optimaliseren. Bedrijven die deze simpele drie stappen doorlopen, zullen in staat zijn om hun servers te virtualiseren zonder daar de snelheid of prestaties aan op te offeren. Waar opslagbeheerders vroeger alleen maar van konden dromen, is nu een realiteit geworden die meetbare zakelijke voordelen biedt.

Door: Per Solvager, regionaal manager Benelux bij Tintri

Wil jij dagelijkse updates?

Schrijf je dan in voor onze nieuwsbrief!