Table of contents
TOC
De inhoudsopgave samenvouwen
De inhoudsopgave uitvouwen

Ontwerpoverwegingen voor SQL Server

Matt Goedtel|Laatst bijgewerkt: 2-3-2017
|
1 Inzender

Van toepassing op: System Center 2016 - Operations Manager

System Center 2016 - Operations Manager vereist toegang tot een exemplaar van een server met Microsoft SQL Server 2012, 2014 of SQL Server 2016 ter ondersteuning van de operationele database, de datawarehouse-database en de ACS-controledatabase. De operationele database en datawarehouse-database zijn vereist en worden gemaakt wanneer u de eerste beheerserver in uw beheergroep implementeert. De ACS-database wordt echter gemaakt wanneer u een ACS-collector in uw beheergroep implementeert.

In een testomgeving of kleinschalige implementatie van Operations Manager kan SQL Server ook op de eerste beheerserver in de beheergroep worden geplaatst. In een middelgrote tot grote gedistribueerde implementatie moet het SQL Server-exemplaar op een specifieke zelfstandige server of in een SQL Server-configuratie voor maximale beschikbaarheid worden geplaatst. In beide gevallen moet SQL Server al aanwezig en toegankelijk zijn voordat u aan de installatie van de eerste beheerserver of de ACS-collector begint.

Vereisten voor SQL Server

De volgende versies van SQL Server worden ondersteund voor een nieuwe of bestaande installatie van Operations Manager.

ComponentSQL Server 2012, SP3 Enterprise/Standard (x64)SQL Server 2014, SP2 Enterprise/Standard (x64)SQL Server 2016 Enterprise/Standard (x64)
Operations Manager: operationele databasejajaja
Operations Manager: datawarehouse-databasejajaja
Operations Manager ACS-databasejajaja
Operations Manager: rapportserverjajaja
Opmerking

System Center 2016 – Operations Manager-databases moeten dezelfde versie van SQL Server gebruiken, de instelling voor SQL Server-sortering moet een van de ondersteunde typen zijn zoals wordt beschreven in die sectie, en de functie Zoekopdracht in volledige tekst van SQL Server is vereist voor de operationele en datawarehouse-databases. De Windows Server 2016-installatieopties (Server Core, Server met Bureaubladervaring en Nano Server) die worden ondersteund voor de onderdelen van Operations Manager-databaseonderdelen, zijn gebaseerd op de installatieopties van Windows Server die worden ondersteund voor SQL Server.

Opmerking

System Center 2016 – Operations Manager-rapportage kan niet 'zij aan zij' worden geïnstalleerd met de System Center Operations Manager 2012 R2-rapportage en mag alleen in de native modus worden geïnstalleerd. (De SharePoint-integratiemodus wordt niet ondersteund.)

Houd bij het plannen van uw ontwerp rekening met deze aanvullende overwegingen voor hardware en software:

  • U wordt aangeraden SQL Server 2012, 2014 en 2016 uit te voeren op computers met de NTFS-bestandsindeling.
  • Er moet ten minste 1024 MB vrije schijfruimte zijn voor de operationele database en datawarehouse-database. Dit wordt afgedwongen op het moment dat de database wordt gemaakt en de vereiste schijfruimte neemt na de installatie waarschijnlijk aanzienlijk toe.
  • .NET Framework 4 is vereist.
  • Reporting Server wordt niet ondersteund voor Windows Server Core.

Raadpleeg Hardware and Software Requirements for Installing SQL Server 2014 (Hardware- en softwarevereisten voor de installatie van SQL Server 2014) of Hardware and Software Requirements for Installing SQL Server 2016 (Hardware- en softwarevereisten voor de installatie van SQL Server 2016) voor meer informatie.

Opmerking

Gebruik tijdens de eerste installatie van de operationele database alleen Windows-verificatie op de SQL Server met de operationele database van Operations Manager. Gebruik niet de gemende modus (Windows-verificatie en SQL Server-verificatie). Het gebruik van de modus SQL Server-verificatie tijdens de eerste installatie van de operationele database kan namelijk problemen veroorzaken. Hoewel het inschakelen van de gemengde beveiligingsmodus mogelijk is op de SQL-server met de operationele database van Operations Manager, wordt dit niet ondersteund omdat elke vorm van contact met de database uitsluitend via Windows-accounts verloopt.

Instelling voor SQL Server-sortering

De volgende SQL Server- en Windows-sorteringen worden ondersteund door System Center 2016 - Operations Manager.

SQL Server-sortering

  • SQL_Latin1_General_CP1_CI_AS

Windows-sortering

  • Latin1_General_100_CI_AS
  • French_CI_AS
  • French_100_CI_AS
  • Cyrillic_General_CI_AS
  • Chinese_PRC_CI_AS
  • Chinese_Simplified_Pinyin_100_CI_AS
  • Chinese_Traditional_Stroke_Count_100_CI_AS
  • Japanese_CI_AS
  • Japanese_XJIS_100_CI_AS
  • Traditional_Spanish_CI_AS
  • Modern_Spanish_100_CI_AS
  • Latin1_General_CI_AS
  • Cyrillic_General_100_CI_AS
  • Korean_100_CI_AS
  • Czech_100_CI_AS
  • Hungarian_100_CI_AS
  • Polish_100_CI_AS
  • Finnish_Swedish_100_CI_AS

Houd er rekening mee dat als uw SQL Server-exemplaar niet is geconfigureerd met een van de eerder vermelde ondersteunde sorteringen, een nieuwe installatie met Operations Manager Setup mislukt. Een in-place upgrade wordt echter wel voltooid.

Firewallconfiguratie

Operations Manager is afhankelijk van SQL Server voor het hosten van databases en van een rapportageplatform voor het analyseren en weergeven van historische operationele gegevens. De rollen Beheerserver, Operations en Webconsole moeten met SQL Server kunnen communiceren. Het is ook belangrijk dat u het communicatiepad en de poorten weet om uw omgeving correct te configureren.

Als u een gedistribueerde implementatie ontwerpt waarvoor SQL Always On-beschikbaarheidsgroepen vereist om failoverfunctionaliteit voor de Operations Manager-databases te kunnen bieden, moeten in de beveiligingsstrategie van uw firewall extra firewallconfiguratie-instellingen worden opgenomen.

Met de volgende tabel kunt u de firewallpoorten identificeren die voor SQL Server vereist zijn en minimaal moeten worden toegestaan om serverrollen in uw Operations Manager-beheergroep te laten communiceren.

ScenarioPoortRichtingOperations Manager-rol
SQL Server-hosting van Operations Manager-databasesTCP 1433 *InkomendBeheerserver en Webconsole (voor Application Advisor en Application Diagnostics)
SQL Server Browser-serviceUDP 1434Inkomendmanagementserver
SQL Server Dedicated Admin Connection (exclusieve beheerdersverbinding)TCP 1434Inkomendmanagementserver
SQL Server Always On-listener voor beschikbaarheidsgroepDoor beheerder geconfigureerde poortInkomendmanagementserver
SQL Server Reporting Services die als host fungeert voor Operations Manager-rapportserverTCP 80 (standaard)/443 (SSL)Inkomendbeheerserver en Operations-console

* Als u een benoemd exemplaar op een zelfstandige SQL Server maakt of een SQL Always On-beschikbaarheidsgroep hebt geïmplementeerd, wordt een aangepaste poort gedefinieerd, hoewel TCP 1433 de standaardpoort is voor het standaardexemplaar van de Database Engine. Deze aangepaste poort moet voor referentiedoeleinden worden gedocumenteerd, zodat u uw firewalls correct kunt configureren en deze informatie tijdens de installatie kunt invoeren.

Zie Configure the Windows Firewall to Allow SQL Server Access (Windows Firewall configureren om SQL Server-toegang toe te staan) voor een gedetailleerd overzicht van de firewallvereisten voor SQL Server.

Overwegingen voor capaciteit en opslag

Operations Manager-database

De Operations Manager-database is een SQL Server-database die alle gegevens bevat die Operations Manager nodig heeft voor dagelijkse bewakingsactiviteiten. De grootte en configuratie van de databaseserver zijn essentieel voor de algehele prestaties van de beheergroep. De meest kritieke resource die door de Operations Manager-database wordt gebruikt, is het opslagsubsysteem, maar ook de CPU en het RAM-geheugen zijn van belang.

Factoren die de belasting op de Operations Manager-database beïnvloeden, zijn:

  • De frequentie waarmee operationele gegevens worden verzameld. Operationele gegevens bestaan uit alle gebeurtenissen, waarschuwingen, statuswijzigingen en prestatiegegevens die door agents worden verzameld. De meeste resources die door de Operations Manager-database worden gebruikt, worden ingezet om deze gegevens naar de schijf te schrijven zoals ze in het systeem worden aangeleverd. De frequentie waarmee operationele gegevens worden verzameld, wordt doorgaans hoger naarmate er meer management packs worden geïmporteerd en extra agents worden toegevoegd. Het type computer dat door een agent wordt bewaakt, speelt ook een belangrijke rol bij het bepalen van de algemene frequentie waarmee operationele gegevens worden verzameld. Van een agent die bijvoorbeeld een bedrijfskritieke desktopcomputer bewaakt, wordt verwacht dat deze minder gegevens verzamelt dan een agent die een server bewaakt waarop een exemplaar van SQL Server met een groot aantal databases wordt uitgevoerd.
  • De snelheid waarmee de exemplaarruimte verandert. Het bijwerken van deze gegevens in de Operations Manager-database is duur in vergelijking met het schrijven van nieuwe operationele gegevens. Wanneer gegevens in de exemplaarruimte worden gewijzigd, moeten de beheerservers bovendien extra query's naar de Operations Manager-database sturen om configuratie- en groepswijzigingen te berekenen. De frequentie waarmee de exemplaarruimte verandert, neemt toe naarmate u extra management packs in een beheergroep importeert. Wanneer nieuwe agents aan een beheergroep worden toegevoegd, verhoogt ook tijdelijk de snelheid waarmee de exemplaarruimte verandert.
  • Het aantal Operations-consoles en andere SDK-verbindingen dat tegelijk wordt uitgevoerd. Elke Operations-console leest gegevens uit de Operations Manager-database. Het uitvoeren van query's op deze gegevens verbruikt mogelijk veel I/O-opslagbronnen, CPU-tijd en RAM-geheugen. Operations-consoles die in de weergave Gebeurtenis, Status, Waarschuwing en Prestatiegegevens grote hoeveelheden operationele gegevens weergeven, zorgen doorgaans voor de grootste belasting op de database.

De Operations Manager-database is één foutenbron voor de beheergroep. Deze kan dus maximaal beschikbaar worden gemaakt met behulp van ondersteunde failoverconfiguraties zoals SQL Server Always On-beschikbaarheidsgroepen of failover-clusterexemplaren.

Operations Manager-datawarehouse-database

System Center 2016 – Operations Manager voegt gegevens in bijna realtime in het Rapportagedatawarehouse in. Daarom is het belangrijk dat deze server over voldoende capaciteit beschikt om alle verzamelde gegevens naar het Rapportagedatawarehouse te schrijven. Net als voor de Operations Manager-database is ook in het Rapportagedatawarehouse het I/O-subsysteem voor opslag de meest kritieke resource. Op de meeste systemen is de werkbelasting op het Rapportagedatawarehouse vergelijkbaar met die op de Operations Manager-database, maar ze kunnen verschillen. Bovendien is de werkbelasting die door rapportage op het Rapportagedatawarehouse wordt geplaatst anders dan de werkbelasting die door het gebruik van de Operations-console op de Operations Manager-database wordt geplaatst.

Dit zijn enkele factoren die de werkbelasting van het Rapportagedatawarehouse beïnvloeden:

  • De frequentie waarmee operationele gegevens worden verzameld. Voor een efficiëntere rapportage worden door het Rapportagedatawarehouse niet alleen geaggregeerde gegevens berekend en opgeslagen, maar ook een beperkte hoeveelheid ruwe gegevens. Door dit extra werk is het verzamelen van operationele gegevens in het Rapportagedatawarehouse mogelijk iets duurder dan in de Operations Manager-database. Deze extra kosten worden doorgaans gecompenseerd door de lagere kosten van het verwerken van detectiegegevens door het Rapportagedatawarehouse in vergelijking met die van de Operations Manager-database.
  • Het aantal gelijktijdige rapportagegebruikers of het aantal geplande rapporten dat gelijktijdig wordt gegenereerd. Aangezien rapporten vaak grote hoeveelheden gegevens samenvatten, kan elke rapportagegebruiker het systeem aanzienlijk extra belasten. Het aantal rapporten dat gelijktijdig wordt uitgevoerd en het type rapporten dat wordt uitgevoerd, hebben allebei invloed op de totale behoeften aan capaciteit. Over het algemeen vereisen rapporten die query's uitvoeren op grote datumbereiken of op een groot aantal objecten meer systeemresources.

Op basis van deze factoren kunt u bij het bepalen van de grootte van het Rapportagedatawarehouse meerdere aanbevolen procedures overwegen:

  • Kies een geschikt opslagsubsysteem. Aangezien het Rapportagedatawarehouse een integraal onderdeel is van de algehele gegevensstroom via de beheergroep, is de keuze van een geschikt opslagsubsysteem voor het Rapportagedatawarehouse van groot belang. Net als bij de Operations Manager-database is RAID 0 + 1 vaak de beste keuze. In het algemeen moet het opslagsubsysteem voor het Rapportagedatawarehouse vergelijkbaar zijn met het opslagsubsysteem voor de Operations Manager-database en is de richtlijn die voor de Operations Manager-database geldt, ook van toepassing op het Rapportagedatawarehouse.
  • Overweeg de juiste plaatsing van gegevenslogboeken en transactielogboeken. Wat de Operations Manager-database betreft, het scheiden van SQL-gegevens en transactielogboeken is vaak de juiste keuze wanneer het aantal agents toeneemt. Als de Operations Manager-database en het Rapportagedatawarehouse zich op dezelfde server bevinden en u gegevens en transactielogboeken van elkaar wilt scheiden, moet u de transactielogboeken voor de Operations Manager-database op een afzonderlijk fysiek volume en afzonderlijke schijfaandrijfassen plaatsen opdat het Rapportagedatawarehouse hier enig voordeel uit haalt. De gegevensbestanden voor de Operations Manager-database en het Rapportagedatawarehouse kunnen hetzelfde fysieke volume delen aangezien het volume voldoende capaciteit biedt en de bewakings- en rapportagefunctionaliteit niet worden belemmerd door de I/O-prestaties van de schijf.
  • Overweeg om het Rapportagedatawarehouse op een andere server te plaatsen dan die van de Operations Manager-database. Hoewel bij kleinschaligere implementaties de Operations Manager-database en het Rapportagedatawarehouse vaak op dezelfde server kunnen worden geconsolideerd, is het voordelig om ze te scheiden omdat dan het aantal agents en het volume van binnenkomende operationele gegevens kunnen worden verhoogd. Dat komt omdat u betere prestaties krijgt wanneer het Rapportagedatawarehouse en de rapportserver zich op een andere server bevinden dan die van de Operations Manager-database.

De Operations Manager-datawarehouse-database is één foutenbron voor de beheergroep. Deze kan dus maximaal beschikbaar worden gemaakt met behulp van ondersteunde failoverconfiguraties zoals SQL Server Always On-beschikbaarheidsgroepen of failover-clusterexemplaren.

SQL Server Always On

Always On-beschikbaarheidsgroepen voor SQL Server ondersteunen failoveromgevingen voor een afzonderlijke set met gebruikersdatabases (beschikbaarheidsdatabases). Elke set met beschikbaarheidsdatabases wordt gehost door een beschikbaarheidsreplica.

In System Center 2016 - Operations Manager heeft SQL Always On de voorkeur boven failoverclustering om maximale beschikbaarheid voor databases te bieden. Alle databases, met uitzondering van de native modus van de Reporting Services-installatie, die gebruikmaakt van twee databases om permanente gegevensopslag te scheiden van de vereisten voor tijdelijke opslag, kunnen in een Always On-beschikbaarheidsgroep worden gehost.

Als u een beschikbaarheidsgroep wilt instellen, moet u een WSFC-cluster (Windows Server Failover Clustering) implementeren dat als host van de beschikbaarheidsreplica fungeert en moet u Always On op de clusterknooppunten inschakelen. Vervolgens kunt u de Operations Manager SQL Server-database als een beschikbaarheidsdatabase toevoegen.

SQL Server optimaliseren

In het algemeen blijkt uit eerdere implementatie-ervaring bij klanten dat prestatieproblemen doorgaans niet worden veroorzaakt door hoog resourcegebruik (dat wil zeggen processor of geheugen) bij SQL Server zelf. In plaats daarvan is het rechtstreeks gerelateerd aan de configuratie van het opslagsubsysteem. Dit wordt meestal toegeschreven aan het niet-volgen van aanbevolen configuratierichtlijnen voor de opslag die is ingericht voor het exemplaar van de SQL Server-database.
Enkele voorbeelden hiervan zijn:

  • Er zijn onvoldoende aandrijfassen toegewezen opdat de I/O-vereisten van Operations Manager door de LUN's kunnen worden ondersteund.
  • Transactielogboeken en databasebestanden worden op hetzelfde volume gehost. Deze twee werkbelastingen hebben heel verschillende I/O- en latentiekenmerken.
  • TempDB is verkeerd geconfigureerd op het gebied van plaatsing, schaling, e.d.
  • Onjuiste uitlijning van schijfpartities van volumes die als host fungeren voor de databasetransactielogboeken, databasebestanden en TempDB.
  • De basisconfiguratie van SQL Server over het hoofd zien, zoals: het gebruik van AUTOGROW voor de database en transactielogboekbestanden, de MAXDOP-instelling voor parallelle uitvoering van query's, het maken van meerdere TempDB-gegevensbestanden per CPU-core, e.d.

Opslagconfiguratie is een van de essentiële onderdelen voor een SQL Server-implementatie voor Operations Manager. Databaseservers zijn meestal sterk I/O-gebonden vanwege strengere lees- en schrijfactiviteiten in databases en de verwerking van transactielogboeken. Het I/O-gedragspatroon van Operations Manager bestaat doorgaans voor 80% uit schrijfbewerkingen en 20% uit leesbewerkingen. Hierdoor kan een onjuiste configuratie van I/O-subsystemen ertoe leiden dat SQL Server-systemen slecht presteren en werken, en dat valt sterk op in Operations Manager.

Het is van groot belang dat het SQL Server-ontwerp wordt getest door de doorvoer van het I/O-subsysteem te testen vóór de implementatie van SQL Server. Zorg ervoor dat bij deze tests uw I/O-vereisten kunnen worden behaald met een aanvaardbare latentie. Gebruik het hulpprogramma voor het benchmarken van SQLIO-schijfsubsystemen om de I/O-capaciteit te bepalen van het opslagsubsysteem dat ondersteuning biedt voor SQL Server. Het volgende blogartikel, geschreven door een medewerker van het File Server-team in de productgroep, biedt gedetailleerde richtlijnen en aanbevelingen voor het uitvoeren van stresstests met behulp van dit hulpprogramma en enige PowerShell-code, en voor het vastleggen van de resultaten met PerfMon. Voor initiële richtlijnen kunt u ook Operations Manager Sizing Helper (het hulpprogramma voor Operations Manager-schaling) raadplegen.

Grootte van NTFS-toewijzingseenheid

Volume-uitlijning, ook wel sectoruitlijning genoemd, moet worden uitgevoerd op het bestandssysteem (NTFS) wanneer een volume op een RAID-apparaat wordt gemaakt. Als dit niet gebeurt, kunnen prestaties sterk afnemen. Dit is meestal het resultaat van een onjuiste uitlijning van de partitie met stripe-eenheidsgrenzen. Dit kan ook leiden tot een onjuiste uitlijning van de hardwarecache, wat resulteert in inefficiënt gebruik van de matrixcache. Bij het formatteren van de partitie die voor SQL Server-gegevensbestanden wordt gebruikt, is het raadzaam een toewijzingseenheidgrootte (clustergrootte) van 64 kB (65.536 bytes) te gebruiken voor gegevens, logboeken en tempdb. Bedenk echter wel dat bij het gebruik van grotere toewijzingseenheden dan 4 kB de NTFS-compressie op het volume niet kan worden gebruikt. Hoewel SQL Server ondersteuning biedt voor alleen-lezen gegevens op gecomprimeerde volumes, wordt dit niet aanbevolen.

Geheugen reserveren

Hoe identificeert u de juiste hoeveelheid fysiek geheugen en het aantal processors dat u moet toewijzen aan de Windows-server voor SQL Server 2014 en 2016 ter ondersteuning van System Center 2016 - Operations Manager? Dat is een lastige vraag om te beantwoorden (zelfs voor andere werkbelastingen buiten dit product). De schalingsberekening die door de productgroep wordt geleverd, en die gebaseerd is op tests in een testomgeving die mogelijk niet overeenkomen met de typische werkbelasting en configuratie in de praktijk, biedt richtlijnen op basis van een schaal voor werkbelasting (500 systemen, 1000 systemen, enz.). Niettemin worden vaak vraagtekens gezet bij de integriteit van het resultaat. Het resultaat wordt gebruikt als een eerste aanbeveling, maar is niet de uiteindelijke configuratie en kan ook niet als zodanig worden beschouwd.

SQL Server kan de geheugenvereisten standaard dynamisch wijzigen op basis van beschikbare systeemresources. De standaardinstelling voor het minimale servergeheugen is 0 en de standaardinstelling voor het maximale servergeheugen is 2.147.483.647. De minimale hoeveelheid geheugen die u voor het maximale servergeheugen kunt opgeven, is 16 MB (megabyte). Een aantal prestatie- en geheugengerelateerde problemen treden op omdat klanten geen waarde instellen voor het maximale servergeheugen en dat doen ze niet omdat ze niet weten wat ze moeten instellen. Een aantal andere factoren is van invloed op de maximale hoeveelheid geheugen die u aan SQL toewijst om ervoor te zorgen dat het besturingssysteem voldoende geheugen heeft voor de ondersteuning van de andere processen die op dat systeem worden uitgevoerd, zoals HBA-kaart, beheeragenten, antivirusscans in realtime, e.d. Anders gebruiken het besturingssysteem en SQL de schijf als wisselbestand en neemt de schijf-I/O toe, waardoor prestaties verder afnemen en een 'domino'-effect ontstaat, dat merkbaar is in Operations Manager.

In SQL Server kunt u de minimale en maximale hoeveelheid geheugen configureren die moet worden gereserveerd en gebruikt door het SQL Server-proces. Het verdient aanbeveling om als minimumwaarde 4 GB RAM-geheugen op te geven. Dit zou moeten gebeuren voor elk SQL-knooppunt waarop een van de Operations Manager-databases (operationele database, datawarehouse-database, ACS-database) wordt gehost.

Het is raadzaam om eerst 1 GB RAM-geheugen te reserveren voor het besturingssysteem, 1 GB voor elke 4 GB RAM-geheugen die wordt geïnstalleerd in het bereik van 4 tot 16 GB, en 1 GB voor elke 8 GB RAM-geheugen bovenop de 16 GB RAM-geheugen. Controleer vervolgens de prestatiemeter Geheugen\Beschikbare megabytes (MB) in Windows om te bepalen of u het geheugen dat voor SQL Server beschikbaar is, hoger kunt instellen dan de beginwaarde. (Opmerking: deze waarde mag nooit lager zijn dan 150-300 MB. Aangezien Windows bij 96 MB meldt dat de resource over onvoldoende geheugen beschikt, kunt u het best een buffer aanhouden. Overweeg echter een minimumwaarde van 1 GB op grotere servers met 256 GB RAM-geheugen of meer). Dit werkt doorgaans uitstekend voor servers die aan SQL Server zijn toegewezen. U kunt het maximumgeheugen waarop u de server instelt ook op een veel technischere manier bepalen door de specifieke geheugenvereisten te berekenen voor het besturingssysteem, andere toepassingen, de thread-stack van SQL Server en andere multipage allocators (toewijzers van meerdere geheugenpagina's). Doorgaans is dit ((Totale systeemgeheugen) – (geheugen voor thread-stack) – (geheugenvereisten voor besturingssysteem ~ 2-4 GB) – (geheugen voor andere toepassingen) – (geheugen voor toewijzingen van meerdere geheugenpagina's; SQLCLR, gekoppelde servers, enz.)), waarbij het geheugen voor de thread-stack = ((maximum aantal werkthreads) *(stackgrootte)) en de stackgrootte 512 kB voor x86-systemen, 2 MB voor x64-systemen en 4 MB voor IA64-systemen is. De waarde voor het maximum aantal werkthreads kunt u vinden in de kolom max_worker_count van sys.dm_os_sys_info. Bij elk van deze methoden wordt echter verondersteld dat u SQL Server alles wilt laten gebruiken dat beschikbaar is op de machine, tenzij u in de berekeningen reserveringen voor andere toepassingen hebt ingevoerd.

Nu steeds meer klanten kiezen voor de virtualisatie van SQL Server in hun omgeving, is deze vraag alsmaar relevanter bij het bepalen van de minimale hoeveelheid geheugen die een SQL Server nodig heeft om in een virtuele machine te worden uitgevoerd. Er is helaas geen enkele manier om te bepalen wat de ideale hoeveelheid geheugen voor een bepaald exemplaar van SQL Server daadwerkelijk is, omdat SQL Server is ontworpen om gegevens in de buffergroep in een cache te plaatsen, en SQL Server doorgaans net zo veel geheugen zal gebruiken als u eraan kunt toewijzen. Een van de zaken waarmee u rekening moet houden wanneer u het geheugen wilt verminderen dat aan een SQL Server-exemplaar wordt toegewezen, is dat u uiteindelijk op een punt komt waar minder geheugen ten koste gaat van hogere I/O-toegang van schijven.

Als u de ideale configuratie voor SQL Server-geheugen moet berekenen in een omgeving waar te veel is ingericht, kunt u het beste beginnen met een basislijn van de omgeving en de huidige maatstaven voor prestaties. Waarden waarmee u de bewaking kunt starten, zijn:

  • SQL Server:Bufferbeheer\Levensverwachting voor pagina's
  • SQL Server:Bufferbeheer\Gelezen pagina's per seconde
  • Fysieke schijf\Schijfleesbewerkingen per seconde

Als de omgeving te veel geheugen voor de buffergroep heeft, zal de waarde van de levensverwachting voor pagina's doorgaans blijven toenemen met één waarde per seconde en zal deze waarde niet teruglopen tot onder de werkbelasting omdat alle gegevenspagina's uiteindelijk in de cache worden geplaatst. Tegelijkertijd zal de waarde van SQL Server:Bufferbeheer\Gelezen pagina's per seconde laag zijn nadat de cacheverhoging plaatsvindt. Dit leidt ook tot een lage waarde voor Fysieke schijf\Schijfleesbewerkingen per seconde.

Zodra u de basislijn voor de omgeving hebt bepaald, wijzigt u de optie sp_configure 'max server memory' om de buffergroep met 1 GB te verkleinen. Controleer vervolgens hoe de prestatiemeteritems reageren als alles weer stabiel verloopt nadat de cache voor het eerst is leeggemaakt, iets wat doorgaans gebeurt wanneer in de omgeving RECONFIGURE wordt uitgevoerd. Als het niveau van Levensverwachting voor pagina's voor uw omgeving aanvaardbaar blijft (waarbij u onthoudt dat een vaste waarde van >= 300 belachelijk is voor servers met een grote hoeveelheid RAM-geheugen), en de waarde voor SQL Server:Bufferbeheer\Gelezen pagina's per seconde valt binnen het bereik van wat het I/O-subsysteem van de schijf zonder prestatievermindering kan ondersteunen, vermindert u de waarde van sp_configure 'max server memory' telkens opnieuw met 1 GB en blijft u de invloed hiervan op de omgeving controleren.

U kunt ook het advies voor SQL 2014 op MSDN raadplegen.

TempDB optimaliseren

De grootte en de fysieke plaatsing van de tempdb-database kunnen invloed hebben op de prestaties van Operations Manager. Als bijvoorbeeld de grootte die voor tempdb is gedefinieerd te klein is, kan een deel van de werkbelasting van de systeemverwerking worden verwerkt door tempdb met automatische groei (AutoGrow) uit te breiden tot de grootte die vereist is om de werkbelasting te ondersteunen telkens wanneer u het exemplaar van SQL Server opnieuw opstart. Als u tempdb optimaal wilt laten presteren, kunt u het best de volgende configuratie voor tempdb in een productieomgeving gebruiken:

  • Stel het herstelmodel van tempdb in op EENVOUDIG. Dit model maakt logboekruimte automatisch weer vrij om de benodigde ruimte klein te houden.
  • Wijs vooraf ruimte voor alle tempdb-bestanden toe door de bestandsgrootte in te stellen op een waarde die groot genoeg is voor de typische werkbelasting in de omgeving. Zo voorkomt u dat tempdb te vaak wordt uitgebreid, wat nadelig kan zijn voor de prestaties. De tempdb-database kan worden ingesteld op automatische groei, maar die mogelijkheid moet worden gebruikt om de schijfruimte te verhogen voor niet-geplande uitzonderingen.
  • Maak net zo veel bestanden als nodig om de bandbreedte van de schijf te maximaliseren. Door meerdere bestanden te gebruiken, reduceert tempdb opslagconflicten en levert dit veel betere schaalbaarheid op. Maak echter niet te veel bestanden omdat dit de prestaties kan verlagen en de beheer-overhead kan verhogen. Als algemene richtlijn maakt u één gegevensbestand voor elke logische processor op de server (rekening houdend met instellingen voor het affiniteitsmasker) en verhoogt of verlaagt u vervolgens zo nodig het aantal bestanden. Wanneer het aantal logische processors kleiner dan of gelijk aan 8 is, gebruikt u over het algemeen net zoveel gegevensbestanden als logische processors. Als het aantal logische processors groter is dan 8, gebruikt u 8 gegevensbestanden. Wanneer er conflicten blijven optreden, verhoogt u het aantal gegevensbestanden met veelvouden van 4 (tot maximaal het aantal logische processors) tot het aantal conflicten beperkt blijft tot een aanvaardbaar niveau, of wijzigt u de werkbelasting per code. Wanneer het aantal conflicten niet vermindert, moet u mogelijk het aantal gegevensbestanden verhogen.
  • Maak alle gegevensbestanden even groot; dit optimaliseert de prestaties van de evenredige opvulling. Het is essentieel dat de gegevensbestanden even groot worden gemaakt omdat het algoritme voor evenredige opvulling gebaseerd is op de grootte van de bestanden. Als gegevensbestanden worden gemaakt die niet even groot zijn, probeert het algoritme voor evenredige opvulling het grootste bestand meer te gebruiken voor GAM-toewijzingen in plaats van de toewijzingen te spreiden tussen alle bestanden, waardoor het weinig nut heeft meerdere gegevensbestanden te maken.
  • Plaats de tempdb-database op een snel I/O-subsysteem dat SSD (Solid-State Drives) gebruikt voor optimale prestaties. Gebruik schijfsegmentering (disk striping) als er veel rechtstreeks aangesloten schijven zijn.
  • Plaats de tempdb-database op andere schijven dan degene die door gebruikersdatabases worden gebruikt.

Als u tempdb wilt configureren, kunt u de volgende query uitvoeren of de eigenschappen ervan wijzigen in Management Studio.

    USE [tempdb]
    GO
    DBCC SHRINKFILE (N'tempdev' , 8)
    GO
    USE [master]
    GO
    ALTER DATABASE [tempdb] MODIFY FILE ( NAME = N'tempdev', NEWNAME = N'tempdb', SIZE = 2097152KB , FILEGROWTH = 512MB )
    GO
    ALTER DATABASE [tempdb] ADD FILE ( NAME = N'tempdb2', FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\DATA\tempdb2.mdf' , SIZE = 2097152KB , FILEGROWTH = 512MB )
    GO

Voer de T-SQL-query SELECT * van sys.sysprocesses uit om conflicten bij het toewijzen van pagina's te detecteren voor de tempdb-database. In de uitvoer van de systeemtabel is de waarde van waitresource mogelijk '2:1:1' (PFS-pagina) of '2:1:3' (Shared Global Allocation Map Page). Afhankelijk van de graad van conflicten kan dit er ook toe leiden dat SQL Server even niet lijkt te reageren. Een andere benadering is het onderzoeken van de dynamische beheerweergaven [sys.dm_exec_request of sys.dm_os_waiting_tasks]. Deze resultaten zullen aantonen dat deze aanvragen of taken wachten op tempdb-resources en, zoals eerder is aangegeven, vergelijkbare waarden hebben wanneer u de query sys.sysprocesses uitvoert.
Als de toewijzingsconflicten na de bovenstaande aanbevelingen niet sterk verminderen en het conflict bevindt zich in SGAM-pagina's, implementeert u de traceringsvlag -T1118 in de opstartparameters voor SQL Server, zodat de traceringsvlag van kracht blijft zelfs nadat SQL Server wordt gerecycled. Onder deze traceringsvlag wijst SQL Server volledige gebieden toe aan elk databaseobject, waardoor de conflicten op SGAM's worden verholpen. Houd er rekening mee dat deze traceringsvlag invloed heeft op alle databases op het SQL Server-exemplaar.

Maximale graad van parallelle uitvoering

De standaardconfiguratie van SQL Server voor kleine tot middelgrote implementaties van Operations Manager volstaat voor de meeste behoeften. Wanneer echter de werkbelasting van de beheergroep wordt verhoogd zoals bij een bedrijfsscenario (doorgaans meer dan 2000 door agent beheerde systemen en een geavanceerde bewakingsconfiguratie, inclusief serviceniveaubewaking met geavanceerde synthetische transacties, netwerkapparaatbewaking, platformoverschrijding, enz.), moet de configuratie van SQL Server die in deze sectie van het document is beschreven, worden geoptimaliseerd. Eén configuratieoptie die in de vorige richtlijnen niet is besproken, is MAXDOP.

De Microsoft SQL Server-configuratieoptie voor maximale graad van parallelle uitvoering (MAXDOP) bepaalt het aantal processors dat wordt gebruikt om een query in een parallel plan uit te voeren. Deze optie bepaalt het aantal reken- en threadresources dat wordt gebruikt voor de operators van het queryplan, die het werk parallel uitvoeren. Afhankelijk van de vraag of SQL Server is ingesteld op een SMP-computer (symmetrische multiprocessing), een NUMA-computer (non-uniform memory access) of met processors die voor hyperthreading zijn ingeschakeld, moet u de optie voor maximale graad van parallelle uitvoering juist configureren.
Wanneer SQL Server wordt uitgevoerd op een computer met meer dan één microprocessor of CPU, detecteert de computer de beste graad van parallelle uitvoering (het aantal processors dat wordt ingezet om één instructie uit te voeren, voor de uitvoering van elk parallel plan). De waarde voor deze optie is standaard 0, waardoor SQL Server de maximale graad van parallelle uitvoering kan bepalen.

De opgeslagen procedures en query's die vooraf zijn gedefinieerd in Operations Manager en die gekoppeld zijn aan operationele databases, datawarehouse-databases en zelfs controledatabases, bevatten niet de optie MAXDOP, omdat er tijdens de installatie geen enkele manier is om dynamisch op te vragen hoeveel processors aan het besturingssysteem worden aangeboden, en er ook niet wordt geprobeerd de waarde voor deze instelling in code vast te leggen, hetgeen negatieve gevolgen zou kunnen hebben bij het uitvoeren van de query.

Opmerking

De configuratieoptie voor maximale graad van parallelle uitvoering stelt geen beperking aan het aantal processors dat door SQL Server wordt gebruikt. Gebruik de configuratieoptie voor het affiniteitsmasker om het aantal processors dat door SQL Server wordt gebruikt te configureren.

  • Voor servers die gebruikmaken van meer dan acht processors, gebruikt u deze configuratie: MAXDOP=8
  • Voor servers die gebruikmaken van acht of minder processors, gebruikt u deze configuratie: MAXDOP=0 tot N. Opmerking: in deze configuratie geeft N het aantal processors aan.
  • Voor servers waarvoor NUMA is geconfigureerd, mag MAXDOP niet groter zijn dan het aantal CPU's dat aan elk NUMA-knooppunt is toegewezen.
  • Voor servers waarop hyperthreading is ingeschakeld, mag de waarde van MAXDOP niet hoger zijn dan het aantal fysieke processors.
  • Voor servers waarvoor NUMA is geconfigureerd en hyperthreading is ingeschakeld, mag de waarde van MAXDOP niet groter zijn dan het aantal fysieke processors per NUMA-knooppunt.

U kunt het aantal parallelle werkthreads bewaken door een query uit te voeren naar sys.dm_os_tasks.
In één bepaalde implementatie van Operations Manager 2012 bij een klant, waarbij meerdere werkbelastingen in een datacenterinfrastructuur werden bewaakt op meer dan 5000 door een Windows-agent beheerde systemen, vertoonde het SQL Server-exemplaar waarop de operationele database werd gehost aanzienlijk slechtere prestaties. De hardwareconfiguratie van deze server is een HP Blade G6 met 24-core processors en 196 GB RAM-geheugen. Voor het exemplaar dat de Operations Manager-database host, is een MAXMEM-waarde van 64 GB ingesteld. Na het uitvoeren van de voorgestelde optimaliseringen in deze sectie verbeterden de prestaties, maar bleef er een knelpunt voor de parallelle uitvoering van query's bestaan. Na het testen van verschillende waarden waren de prestaties optimaal bij de instelling MAXDOP=4.

Grootte bepalen van de initiële database

Het is niet eenvoudig om in te schatten hoe sterk Operations Manager-databases, en met name operationele databases en datawarehouse-databases, binnen enkele maanden na hun implementatie zullen groeien. Hoewel de Operations Manager Sizing Helper (Helper voor Operations Manager-schaling) de potentiële groei nog redelijkerwijs kan inschatten op basis van de formule die de productgroep heeft afgeleid uit tests in de testomgeving, houdt deze geen rekening met verschillende factoren die van invloed kunnen zijn op de groei op korte termijn in plaats van op de lange termijn.

De grootte van de initiële database, zoals voorgesteld door de Sizing Helper (Helper voor schaling), moet, om fragmentatie en bijbehorende overhead te reduceren, worden toegewezen op basis van de verwachte grootte die bij de installatie kan worden opgegeven voor de operationele databases en datawarehouse-databases. Als tijdens de installatie onvoldoende opslagruimte beschikbaar is, kunnen de databases later worden uitgebreid met behulp van SQL Management Studio en daarna opnieuw geïndexeerd om dienovereenkomstig te defragmenteren en te optimaliseren. Deze aanbeveling geldt ook voor de ACS-database.

De proactieve controle van de groei van de operationele database en datawarehouse-database moet dagelijks of wekelijks worden uitgevoerd. Dit is noodzakelijk om onverwachte en aanzienlijke groeisprongen te identificeren en te beginnen met de oplossing van het probleem om te bepalen of het wordt veroorzaakt door een fout in de werkstroom van een management pack (een detectieregel, een verzamelingsregel voor prestaties of gebeurtenissen, of een controle- of waarschuwingsregel) of door een ander symptoom van een management pack dat niet werd geïdentificeerd tijdens de testfase en kwaliteitscontrole van het Releasebeheerproces.

Automatische groei van database

Wanneer de bestandsgrootte voor databases die op de schijf is gereserveerd vol is, kan SQL Server automatisch de grootte verhogen met een bepaald percentage of een vaste grootte. Bovendien kan ook een maximale databasegrootte worden ingesteld, om te voorkomen dat alle beschikbare ruimte op de schijf wordt ingenomen. Automatische groei is standaard niet ingeschakeld voor de OperationsManager-database , maar wel voor de datawarehouse- en ACS-database.

Vertrouw alleen op automatische groei als noodplan voor onverwachte groei. Automatische groei impliceert echter ook prestatienadelen waarmee rekening moet worden gehouden bij het gebruik van een database met veel transacties. Dit zijn enkele van die prestatienadelen:

  • Fragmentatie van het logboekbestand of de database als u geen geschikte toenameverhoging opgeeft.
  • Als u een transactie uitvoert waarvoor meer logboekruimte is vereist dan beschikbaar is, en u hebt de optie voor automatische groei ingeschakeld voor het transactielogboek van de database, dan wordt aan de tijd die nodig is om de transactie te voltooien ook de tijd toegevoegd die nodig is om het transactielogboek te laten groeien met de ingestelde toenameverhoging.
  • Als u een grote transactie uitvoert waarvoor het logboek moet worden vergroot, zullen andere transacties waarvoor een schrijfbewerking naar het transactielogboek vereist is, ook moeten wachten tot de groeibewerking is voltooid.

Als u de opties voor automatische groei en automatische verkleining combineert, creëert u mogelijk onnodige overhead. Zorg ervoor dat de drempelwaarden die de groei- en verkleiningsbewerkingen activeren, niet leiden tot frequente vergrotingen en verkleiningen. U kunt bijvoorbeeld een transactie uitvoeren die ervoor zorgt dat het transactielogboek met 100 MB wordt vergroot op het moment dat deze transactie wordt doorgevoerd. Enige tijd later treedt de automatische verkleining in werking en wordt het transactielogboek met 100 MB verkleind. Daarna voert u dezelfde transactie uit en wordt het transactielogboek opnieuw met 100 MB vergroot. In dit voorbeeld creëert u onnodige overhead en wordt het logboekbestand mogelijk gefragmenteerd. Beide factoren zijn nadelig voor prestaties.

Het is raadzaam deze twee instellingen zorgvuldig te configureren. De daadwerkelijke configuratie is echt afhankelijk van uw omgeving. In het algemeen is het raadzaam om de databasegrootte met een vaste grootte te verhogen om schijffragmentatie te reduceren. In de volgende afbeelding is bijvoorbeeld aangegeven dat de database is ingesteld om met 1024 MB te worden vergroot telkens wanneer automatische groei vereist is.

Beleid voor clusterfailover

Windows Server Failover Clustering (WSFC) is een platform met maximale beschikbaarheid dat de netwerkverbindingen en de status van de knooppunten in een cluster permanent bewaakt. Als een knooppunt niet bereikbaar is via het netwerk, wordt een herstelactie uitgevoerd om toepassingen en services te herstellen en ze online te brengen op een ander knooppunt in het cluster. De standaardinstellingen zijn geoptimaliseerd voor hardwarefouten waarbij een server volledig uitvalt (een zogeheten 'hard failure'). Dit zijn scenario's met onherstelbare fouten zoals de uitval van niet-redundante hardware of stroomuitval. In die situaties gaat de server verloren. Het doel is het verlies van de server heel snel te detecteren met Failoverclustering en snel een herstel uit te voeren op een andere server in het cluster. Om dit snel herstel van hard failures te kunnen uitvoeren, zijn de standaardinstellingen voor clusterstatuscontrole vrij agressief. Ze zijn echter volledig te configureren om flexibiliteit voor uiteenlopende scenario's mogelijk te maken.

Voor de meeste klanten bieden deze standaardinstellingen de beste werking. Wanneer clusters echter niet enkele centimeters, maar mogelijk enkele kilometers van elkaar zijn verwijderd, kan het risico ontstaan van extra en mogelijk onbetrouwbare netwerkonderdelen tussen de knooppunten. Een andere factor die meetelt, is dat de kwaliteit van basisservers voortdurend toeneemt. In combinatie met verhoogde tolerantie via redundante onderdelen (zoals dubbele voedingen, NIC-koppeling en Multipath I/O) kunnen niet-redundante hardwarefouten vrij zeldzaam zijn. Omdat hard failures mogelijk minder frequent optreden, kan het voor sommige klanten beter zijn om het cluster af te stemmen op tijdelijke fouten, waarbij het cluster meer bestand is tegen kortstondige netwerkfouten tussen de knooppunten. Door de standaarddrempelwaarden voor fouten te verhogen, kunt u de gevoeligheid voor netwerkproblemen van korte duur verkleinen.

Het is belangrijk dat u onthoudt dat er hier geen juist antwoord is en dat de geoptimaliseerde instelling kan variëren afhankelijk van uw specifieke zakelijke vereisten en serviceovereenkomsten.

Virtualisatie van SQL Server

In virtuele omgevingen is het voor prestatiedoeleinden aanbevolen om de operationele database en datawarehouse-database op te slaan op een direct gekoppelde opslag (DAS) en niet op een virtuele schijf. Gebruik altijd Operations Manager Sizing Helper (Helper voor Operations Manager-schaling) om de vereiste IOPS-waarde te ramen en voer een stresstest met uw gegevensschijven uit om dit te verifiëren. U kunt voor deze taak gebruikmaken van het hulpprogramma SQLIO. Zie ook Ondersteuning voor Operations Manager-virtualisatie voor meer informatie over een gevirtualiseerde Operations Manager-omgeving.

Model voor Always On en herstel

Hoewel een Always On-beschikbaarheidsgroep strikt genomen geen optimalisatie is, is het wel belangrijk dat u weet dat voor deze functie de databases standaard op het herstelmodel 'Volledig' moeten zijn ingesteld. Dat betekent dat de transactielogboeken pas worden verwijderd nadat een volledige back-up of een back-up van alleen het transactielogboek is uitgevoerd. Daarom is een back-upstrategie niet optioneel, maar een vereist onderdeel van het Always On-ontwerp voor Operations Manager-databases. Anders zullen schijven die transactielogboeken bevatten na verloop van tijd vol geraken.

Een back-upstrategie moet rekening houden met de details van uw omgeving. De volgende tabel bevat een voorbeeld van een typische back-upplanning.

Type back-upPlanning
Alleen transactielogboekElk uur
VolledigWekelijks, zondag om 03:00 uur

Microsoft SQL Server Reporting Services

Het Reporting Services-exemplaar fungeert als een proxy voor toegang tot gegevens in de datawarehouse-database. Het genereert en toont rapporten op basis van sjablonen die in de management packs zijn opgeslagen.

Achter de schermen van Reporting Services bevindt zich een exemplaar van een SQL Server-Database waarop de databases ReportServer en ReportServerTempDB worden gehost. Algemene aanbevelingen voor het afstemmen van de prestaties van dit exemplaar zijn van toepassing.

© 2017 Microsoft