Archiv der Kategorie: SQLServer

#PSBlogWeek – free PDF with my „SQL Server Migration with PowerShell dbatools“ now available

Veröffentlicht am von
Antworten

Hello,

a compilation of all the PowerShell articles of the #PSBlogWeek 2017 is now available.
Included is my article about „SQL Server Migration with PowerShell dbatools“.

This is the PDF: PSBlogWeek eBook PowerShell-Server-Management

And here is the link to the original announcement from Adam Bertram (t | b)): http://www.adamtheautomator.com/psblogweek-powershell-blogging-entire-week/

You’ll find Links to the original six blog articles on the activity Page from #PSBlogWeek.

http://psblogweek.com/psblogweek-activity

Thanks go out to all contributors and for Adam for hosting the event and for compiling the eBook.

Thanks for reading!
Volekr

 

Project SQL on VMware – Migration from Physical to Virtual

Veröffentlicht am von
Antworten

Migration of physical SQL Server to a new VMware Environment.

As announced in my last post about Migration of SQL Server with PowerShell dbatools #PSBlogWeek I’ll write a recap of the first three parts of the project – and here we come.

Index:

  1. Why (do we need to do this project?)
  2. Ordering the hardware
  3. Configuration of the VMware environment
  4. Detail configuration of the individual virtual machines
  5. Migration of SQL Server with PowerShell dbatools (separate article)

It all begun with the idea of reducing the amount of seven physical server we use for our SQL Server databases.

Why?

  • old servers are running out of support and have to be replaced.
  • the amount of SQL Server Core licenses can be reduced.
  • better High Availability and shorter restore times in case of a Desaster Recovery.
  • fewer unused ressources of the physical server.

To analyze and select the hardware, we used a Dell tool (DPack) to record the performance data of the seven physical servers for over a week. We saw a peek there of 11.000 IOPS that needs to be fulfilled by the VMware Environment.

IOPS of the physical SQL Server Environment

But that’s only a peek and therefore considered as the maximum value. The mean at 95% is 2475 IOPS.

Here is the (german) summary for the 7 servers with the determined data.DPack summary

It says we need 661 MB/s, or 11074 IOPS (2475 by mean 95%) for the seven server with 22 CPUs and 116 Cores.

Therefore a selection of 3 Dell Poweredge servers (R730), two Dell 10G switches (S4048T) and two SANs (Compellent SC4020 with SSDs) was proposed as a central storage.

For the VMware version, the Essentials Plus version is enough for us, as this will be a completely independent environment. Windows 2016 Datacenter with the correct core number serves as the operating system in the VMs.
The SQL Server are licensed with SQL Server 2016 Standard incl. SA in the Core variant, a single one is raised to Enterprise 2016 for a Mobile Reports Reporting Server (SSRS).

The Order

Unfortunately, one of the two SANs was canceled for the order due to financial reasons, which reduced the total price by about 50K. The lack of the SAN does not affect the topic of HA to any great extent, but is crucial for disaster recovery.
In the event of a complete failure of the SAN, the mission-critical productive databases are no longer available on another SAN in a very short time, but must be restored from the backup. Here the goal of the shorter Disaster Recovery times is in my opinion again far off.

This section will discuss how to configure the VMware environment that was run during the initial installation by a Dell Remote engineer.
The technology behind the implementation:
The three servers (Dell PowerEdge R730) each contain 2 CPUs with 12 cores, that is a total of 72 cores and 512 GB RAM each. There are two micro SD cards for the operating system in the servers (VMware 6.0 – 6.5 is not yet supported by the SAN). The Compellent SC4020 SAN has 9 SSDs of 3.82 TB each, one of which is configured as a HotSpare. The volumes are available as RAID 6 or 10.
Server and SAN are connected via the Dell S4048T switches with 4 x 10G each.
First, the physical installation of the environment was done in the data center. The problem arose that the switches were delivered without OS. So it was necessary for the switches and then the two controllers of the SAN to provide serial ports to the device. My colleague provided me with a 4-way serial to USB / network adapter based on a Raspberry. At the same time, FTP, TFTP and several other servers proved to be very helpful for the setup.
At the same time, the servers and the SAN could still be reached via their management ports (Dell iDRAC), which was also necessary for the basic installation.
On the basis of the basic structure (picture below) you can see the architecture of the area well. At the top the two servers, including the two switches to which then the SAN is connected. Of course, everything is wired twice to achieve the greatest possible reliability.
Installation structure server, switch and SAN
URL from the Dell Installation Guide for the Compellent SAN SC 4020
(The source and copyright of the artwork are with Dell.)
The environment shown in the picture differs from ours only that two servers are used here, but three servers are used in our environment as hosts. Of course, there are other internal connections between servers, switches and the SAN to separate, for example, VMware, VMotion, iSCSI and other traffic from the actual traffic to the rest of the network. Its connection is then made via two breakout cables with 4 x 10G which are connected directly to our central core switches.
The basic installation was then carried out by the mentioned Dell Remote technician.
• Server firmware updates
• VMware basic installation on the SD cards
• Switch OS installation and configuration
• SAN setup, creation of volumes
• iSCSI setup in VMware and connection of SAN volumes
During the subsequent tests of the various failure scenarios (switch, server, SAN controller) an error occurred during the reboot of one of the switches. Dell support has then replaced the switch directly.

This section is now about the detail configuration of the individual virtual machines.

This SQL Server VMware environment is now the third stand-alone VMware environment. Each environment consists of three ESXi hosts connected to one or two SANs.
So far, in the second or „Application-VMware“ called environment, we have not thought so much about the VMs and their possible performance requirements.
But that changed with the introduction of this SQL Server on VMware environment, as we wanted to turn high performance productive servers from physics to virtual without sacrificing speed.

Basically it was, as described in the beginning of the article, of course, the replacement of existing hardware with new – in the form of VMware Hosts. Behind it was, of course, in the implementation and the requirement that it should not slow down in any case.
That’s why I’ve studied the requirements of SQL Server in such an environment and read various guides and best practices. These are available from Microsoft, VMware and several other sources (I have linked a part of them below). Particularly helpful was a series of articles by David Klee on the page sqlservercentral.com called „Stairway to SQL Server Virtualization“ (1).
The majority of the following settings / configurations is taken from this article because there, unlike the other sources, directly and understandably the most important points are highlighted and shown by example.

1. Storage / Disk Partitioning
Basically the same applies here as for physical hardware: distribution of access to as many disks as possible, or here SAN paths (LUNs). Since this is often the same target on the SAN, only distinguished by different RAIDs (6 or 10), the only noticeable difference is the buffer of each individual path (LUN).
This also means that the correct RAIDs have to be passed through the different LUNs to the VM. Accordingly, hard disk configuration and allocation is as complex as in „physical life“.
It looks like this, for example – closely following the recommendations of David Klee (1):

Disk Configuration for the SQL Server VM

As mentioned in the article, it is also of particular importance to use the correct hard disk adapter, ie controller (see SCSI ID), not the standard but the Paravirtualized Adapters (Paravirtual SCSI Driver – PVSCSI). For partitions C: (OS) and Y: (Pagefile) in the table above, this can be left with the default LSI SAS Controller.
The other should be set up on the mentioned PVSCSI. However, the corresponding controller and thus the drives are only present in the VM when the VMware Tools are installed.
Unfortunately, the assignment of the hard disks to the appropriate controller now only works in the vSphere web client.

Disk Configuration in the vSpere Web Client

The hard disk type used is fixed disk sizes (thick provision lazy-zeroed or eager-zeroed) as static VHDs. Although thin provision may be more economical in the beginning when consuming disk space, it will consume additional resources when the VMDK files are enlarged in the background because the space is needed. This is – similar to the autogrowth of a database – most often exactly the wrong time and then possibly causes problems in the VM.

Disk Drive characteristics

2. CPU
The CPU settings are also a bit more complicated.
For the whole topic, note how many physical CPUs the ESX Host has the VMs on. This should be considered as the maximum that should be allocated in the VMs – an overbooking of the CPU resources, assigning more CPU than the host has available does not make sense for SQL Server.
In addition, one could still consider in connection with the size of the memory (point 3) the subject NUMA (Non Uniform Memory Access). This means that accessing the memory directly allocated to a CPU is faster than accessing „remote“ memory. To what extent this has an impact on the performance of the VMs, I can only estimate so far, as I have not received any information from Dell, which tells me the correct configuration of our servers used.
The basic CPU settings are simply distributed between the virtual sockets (processors) and cores per socket (cores per processor).
In the screenshot you can see that there are 12 cores associated with this VM, which then have to be licensed under current license conditions for the SQL Server (no guarantee!).

CPU configuration

3. RAM
The allocation of the necessary memory for a VM mainly depends on the size of the databases, which should be as completely as possible in the main memory for performance reasons. To add is still a share for OS and SQL Server itself. The screenshot above currently has 192 GB allocated.
As already indicated in the case of CPU there are still missing technical details missing for the configuration.
4. Network
For the network, you should use VMXNET3 adapters, which also do not arrive in the VM until the VMware Tools are installed. Basically, there is still room for teaming two network adapters in the VM – not necessarily as a redundancy topic, but again with two additional buffers Speed ​​advantage – though probably minimal. That still needs to be tested. This point was later added by another document from Idera „Moving SQL Server to a virtual Platform“ (6). For this reason, this is also not included in the original configuration.

The entire configuration refers to the settings of one VM. Of course, the complete installation incl. SQL Server was finally migrated to a template to quickly create another SQL Server.

More settings:
• Set Powerplan to highest performance – in the VM as well as the ESXi hosts.
The configuration for the VM goes, in addition to the way through the energy settings, also with the Powershell dbatools with the command Test-DbaPowerPlan (https://dbatools.io/functions/test-dbapowerplan)

More about the dbatools in the 4th article of this article series „Migration“:
https://blog.volkerbachmann.de/2017/10/19/migration-of-sql-server-with-powershell-dbatools/

Sources:
1. Stairway to SQL Server Virtualization by David Klee on sqlservercentral.com
http://www.sqlservercentral.com/stairway/112551/
2. Understanding NUMA – https://technet.microsoft.com/en-us/library/ms178144(v=sql.105).aspx
3. VMware Best Practices SQL Server – http://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/solutions/sql-server-on-vmware-best-practices-guide.pdf
4. VMware Performances Best Practices – https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/techpaper/vmware-perfbest-practices-vsphere6-0-white-paper.pdf
5. Moving SQL Server to a Virtual Platform from Idera (registration required) – https://www.idera.com/resourcecentral/whitepapers/movingsqlservertoavirtualplatform
6. Brent Ozar’s page on Virtualization Best Practices: https://www.brentozar.com/sql/virtualization-best-practices/ (the page does not seem to exist anymore)

Topics for the other distributions of the project
• Describe migration of a SQL Server with dbatools, W2K16, SQL 2016 SP1 – done in this article: https://blog.volkerbachmann.de/2017/10/19/migration-of-sql-server-with-powershell-dbatools/
• Performance comparison physical <-> virtual – to be done!

Any comments are welcome!

Thanks for reading,
Volker

Migration of SQL Server with PowerShell dbatools #PSBlogWeek

Veröffentlicht am von
5

This article is about server management with PowerShell and is part of the #PSBlogWeek series (http://psblogweek.com) , created by Adam Bertram.

Index:

  1. Introduction to dbatools
  2. Migration Prerequisites
  3. Best Practices
  4. Migration
  5. References

It is also part of my blog series about migrating our physical SQL Server to a VMware Environment. For now, all of these articles are in German only – sorry. The first three articles describe the basic server configuration, installation, and VM guest configuration of the VMware Environment. This article describes the migration itself.
I’ll write a recap of the whole series in English later on. 🙂

  1. Introduction to dbatools

I got in contact with PowerShell some years ago, but I wasn’t satisfied with what needed to be done to maintain SQL Server.

However, Microsoft has made a lot of improvements since then, and with contributions from several PowerShell Experts and MVPs – such as Chrissy LeMaire, Claudio Silva, Rob Sewell, Constantine Kokkinos and many more, there is now a module that helps to maintain SQL Server 2005+. It’s called dbatools, and you can find it here https://dbatools.io. The project is hosted on GitHub and the module is available totally free of charge!

The dbatools community has grown to over 50 contributors with more than 300 SQL Server best practice, administration and migration commands. An overview of the commands can be found here: https://dbatools.io/functions/.

2. Migration Prerequisites

Now, let’s turn our attention to the prerequisites for the migration of a physical SQL Server 2008 to a VMware-based SQL Server 2016 on Windows Server 2016. The positive thing here was that there was no need to reinstall everything  on the same physical hardware over the weekend. Instead, we bought a totally new VMware Environment with three Dell servers, two network switches, and new storage. There was enough time to test the new SQL Server, the SAN, and build a good configuration for the virtual machines. Most of the VM configuration is based on the blog series „Stairway to Server Virtualization“ by David Klee, which can be found on SQL Server Central.

For migration purposes, we installed an additional Windows Server 2016 with PowerShell 5, with SQL Server 2016 as an admin workstation. On the SQL Server, we installed the dbatools by using the easy install-module command:

# allow execution of scripts that are signed from a trusted author, if not already set
Set-ExecutionPolicy RemoteSigned 

# install 
install-module dbatools

During installation, you may get a confirmation dialog prompting you to accept installation of the NuGet Package Manager. You should accept; otherwise, you’ll need another installation option. These options are described on the dbatools website: https://dbatools.io/download.

The dbatools module is in permanent development – meanwhile, they are near the first major release 1.0 – so you should check for the latest version and update often. Updating is as easy as the installation:

Update-dbatools
# Get version number
Get-Module -Name dbatools
# Get all available versions that are installed
Get-Module dbatools -ListAvailable

dbatools available versions

 

 

On the screenshot we see five versions of the tools installed, so we have to activate the latest version with the comand import-module.

#Import specific version - here 0.9.39
import-module 
"c:\Program Files\WindowsPowerShell\Modules\dbatools\0.9.39\dbatools.psd1"

# List all available commands of the loaded module version
Get-Command –module dbatools

With the last command above you get a quick overview of all the dbatools commands.

After installation of the base SQL Server VM we need to check some basic configuration options first. dbatools can help us with this as well. 🙂

All commands are created by experts with references to the corresponding articles where the code comes from.

3. Best Practices

  • Max Memory
    • Test-DbaMaxMemory
    • This tests the actual max memory setting against the recommended setting.
    • Test-DbaMaxMemory -SqlServer sqlserver01
# command to set the max memory to the recommended
Set-DbaMaxMemory -SqlServer sqlserver01
# or to a fixed value of 2 GB
Set-DbaMaxMemory -SqlInstance sqlserver01 -MaxMb 2048
  •  TempDB
    • Test-DbaTempDbConfiguration
    • With SQL Server 2016, you get the option to configure the tempdb configuration during installation, but not with older versions. With this command, you can control and later adjust it.
    • Evaluates tempdb against a set of rules to match best practices. The rules are:
      – TF 1118 Enabled: Is Trace Flag 1118 enabled? (See KB328551)
      – File Count: Does the count of data files in tempdb match the number of logical cores, up to 8?
      – File Growth: Are any files set to have percentage growth? Best practice is that all files have an explicit growth value.
      – File Location: Is tempdb located on the C:\ drive? Best practice says to locate it elsewhere.
      – File MaxSize Set (optional): Do any files have a max size value? Max size could cause tempdb problems if it isn’t allowed to grow.
    • Test-DbaTempDbConfiguration
    • The right configuration can be set by using the corresponding Set- command
      A service restart is necessary after reconfiguration, see following screenshot:
    • Set-DbaTempDbConfiguration
  • Disk
    • Test-DbaDiskAlignment
      • This command verifies that your non-dynamic disks are aligned according to physical requirements.
      • Test-DbaDiskAlignment -ComputerName sqlserver01| Format-Table
      • Test-DbaDiskAlignment
    • Test-DbaDiskAllocation
      • Checks all disks on a computer to see if they are formatted to 64k block size, the best practice for SQL Server disks.
      • Test-DbaDiskAllocation -ComputerName sqlserver01 | Format-Table
      • Test-DbaDiskAllocation
  • PowerPlan
    • Test-DbaPowerPlan
      • The Power Plan should be set to High Performance on every SQL Server.
      • Test-DbaPowerPlan -ComputerName sqlserver01
      • Test-DbaPowerPlan

 

  • SPN
    • We use DNS CNAMEs for referring to our SQL Server (See the article „Using Friendly Names for SQL Servers via DNS“ below). We need to adjust the SPN settings manually. That is easy with these commands:
      Get-DbaSpn and Set-DbaSPN
  • SQL Server Name
    • We created a Single VM template where all SQL Server are created from. With CPU, Memory and Disk Layout as described in the Stairway I mentioned above (1).
    • After creating a new VM out of the template the server name changes but the internal SQL Server name does not. Help comes again with dbatools command Repair-DbaServerName
      Works fine for me!

4. Migration

  • Now for the best part – the migration itself. You normally only need a single command to migrate everything from one SQL Server to another. As described in the Help documentation, this is a „one-button click“.
    Start-DbaMigration -Source sql2014 -Destination sql2016 -BackupRestore -NetworkShare \nas\sql\migration
  • This migrates the follwing parts as listed below. Every part can be skipped with a -no*** parameter as described in the Help documentation – for example, use -NoLogins if you don’t want to transfer the logins.
    • SQL Server configuration
    • Custom errors (user-defined messages)
    • SQL credentials
    • Database mail
    • User objects in system databases
    • Central Management Server
    • Backup devices
    • Linked server
    • System triggers
    • Databases
    • Logins
    • Data collector collection sets
    • Audits
    • Server audit specifications
    • Endpoints
    • Policy management
    • Resource Governor
    • Extended Events
    • JobServer = SQL Server Agent
  • If any error comes up, use the functions, that are called out of the Start-DbaMigration commands step by step.
  • Keep in mind that the server configuration is also part of the migration, so min and max memory and all other parameter in sp_configure are transferred. If you want to keep this settings as set by the best practices commands, you should skip the configuration during transfer. Use -NoSpConfigure!
  • So what is missing in the moment?
    • Most of the special parts of the additional services:
      • SSIS
      • SSAS
      • SSRS
  • You can test the whole migration with the -WhatIf parameter, which shows what’s working and what isn’t. Sometimes the connection to the target computer isn’t working because PowerShell remoting is not enabled (see above).
    There is a command to test the connection to the server, and you can find that here:
    https://dbatools.io/functions/test-dbacmconnection
    There is no need for updating the new server to the latest version of PowerShell, Version 3.0 is enough.
  • The whole command looks like this for me:
    • Start-SqlMigration -Verbose -Source desbsql1 -Destination desbaw2 -BackupRestore -NetworkShare \\DESBAW2\Transfer -DisableJobsOnDestination -Force
  • The parameter DisableJobsOnDestination is extremly helpful when you go to the next step and test the migration itself. When you do this more than once, you also need the parameter –Force, which overwrites the target objects (logins, databases and so on) if they exist from a previous test.
  • The parameter -Verbose is useful when an error comes up and you need to dig deeper into the problem.
  • Before we wrap up, her’s a link to a YouTube video that shows how fast the migration works. Of course it’s all going to depend on the size of your databases:
    https://youtu.be/PciYdDEBiDM

5. References:

  1. Stairway to SQL Server Virtualization by David Klee
  2. Using Friendly Names for SQL Servers via DNS

Thanks for reading,
Volker Bachmann

TSQL2sday #94 – SQL Server Best Practices Test with PowerShell dbatools #tsql2sday

Veröffentlicht am von
2

T-SQL Tuesday #94 – Lets get all Posh!

Rob Sewell aka sqldbawithabeard (b|t) hosts this month T-SQL Tuesday and surprisingly his subject is PowerShell.

I will describe what I’ll use for testing against Best Practices Commands for SQL Server.

I got in contact with PowerShell some years ago, but was not satisfied with what needs to be done before maintaining SQL Server.

Meanwhile Microsoft has done a lot more and with the contribution from several PowerShell Experts and MVPs as Chrissy LeMaire, Claudio Silva, Rob Sewell, Constantine Kokkinos and many more, there is a module created that helps to maintain SQL Server 2005+. This is called dbatools and the website can be reached at https://dbatools.io. The Project is hosted on Github and using the commands is totally free of charge!

The community has grown to over 50 contributors and over 200 SQL Server best practices, administration and migration commands. An Overview of the commands can be found here: https://dbatools.io/functions/

Now I will describe some of the dbatools commands to Test our SQL Server against Best Practices mentioned by SQL Server Experts. You can find all of the information and Links in the description to the commands.

  • Max Memory
    • This tests the actual max memory setting against the recommended setting.
    • Test-DbaMaxMemory -SqlServer sqlserver01
# command to set the max memory to the recommended
Set-DbaMaxMemory -SqlServer sqlserver01
# or to a fix value of 2 GB
Set-DbaMaxMemory -SqlInstance sqlserver01 -MaxMb 2048
      ​
  • TempDB
    • with SQL Server 2016 you get the option to configure the TempDB Configuration during installation, with this commands you can control and fix it.
    • Test-DbaTempDbConfiguration
    • Evaluates tempdb against a set of rules to match best practices.
      The rules are:
      – Is Trace Flag 1118 enabled (See KB328551).
      – File Count: Does the count of data files in tempdb match the number of logical cores, up to 8.
      – File Growth: Are any files set to have percentage growth, as best practice is all files have an explicit growth value.
      – File Location: Is tempdb located on the C:\? Best practice says to locate it elsewhere.
      – File MaxSize Set(optional): Do any files have a max size value? Max size could cause tempdb problems if it isn’t allowed to grow.
    • Test-DbaTempDbConfiguration(Screenshot from dbatools.io – my configurations are all fine 🙂 )
    • The right configuration can be set by using the corresponding Set- command
  • Disk-Configuration
    • Test-DbaDiskAlignment
      • This command verifies that your non-dynamic disks are aligned according to physical requirements.
      • Test-DbaDiskAlignment -ComputerName sqlserver01| Format-Table
      • Test-DbaDiskAlignment
    • Test-DbaDiskAllocation
      • Checks all disks on a computer to see if they are formatted to 64k, the best practice for SQL Server disks
      • Test-DbaDiskAllocation -ComputerName sqlserver01 | Format-Table
      • Test-DbaDiskAllocation
  • PowerPlan
    • Test-DbaPowerPlan
      • The Servers Powerplan should be set to High Performance on every SQL Server
      • Test-DbaPowerPlan -ComputerName sqlserver01
      • Test-DbaPowerPlan

 

  • SPN
    • We use DNS CNAMEs for referring to our SQL Server (2). We need to adjust the SPN Settings manually. That is easy with these commands:
      Get-DbaSpn / Set-DbaSPN
  • SQL Server Name
    • We created a Single VM template where all SQL Server are created from. With CPU, Memory and Disk Layout.
    • After creating a new VM out of the template the Server Name changes but not the SQL Server Name internally. Help comes again with dbatools command: Repair-DbaServerName
      Works fine for me!

Theses are the commands we use often in our environment, there are many more to choose from on the dbatools website.

Thanks to Rob for hosting this month T-SQL Tuesday and thanks to all other attendees to convince me writing a blog post. Thanks also to Adam Bertram who chooses me writing for #PSBlogWeek. You all can attend until this friday (2017-09-15). http://psblogweek.com/

Thanks for Reading,
Volker

Projekt SQL auf VMware Teil 3 – VMware Guest Konfiguration

Veröffentlicht am von
Antworten

Im dritten Teil meiner Projektbeschreibung geht es nun um die Detail Konfiguration der einzelnen virtuellen Maschinen.

Teil 1: Einführung oder das „Warum?“
Teil 2: Konfiguration VMware Umgebung

Diese SQL Server VMware Umgebung ist nun die dritte eigenständige VMware-Umgebung. Alle Umgebungen bestehen jeweils aus drei ESXi Hosts die an ein oder zwei SANs angeschlossen sind.

Bisher haben wir uns in der zweiten oder auch „Anwendungs-VMware“ genannten Umgebung noch nicht so detaillierte Gedanken zu den VMs und deren möglichen Performance Anforderungen gemacht.
Das hat sich aber mit der Einführung dieser SQL Server on VMware Umgebung geändert, da wir nun Hochleistungs-Produktivserver von Physik in Virtuell umwandeln wollten ohne Geschwindgkeitseinbußen.
Grundsätzlich ging es, wie im ersten Teil beschrieben, natürlich um die Ablösung vorhandener Hardware durch neue – in Form von VMware Hosts. Dahinter stand dann aber natürlich bei der Umsetzung auch die Anforderung dass es auf keinen Fall langsamer werden sollte. 🙂

Aus diesem Grund habe ich mich intensiv mit den Anforderungen von SQL Servern auf einer solchen Umgebung beschäftigt und diverse Anleitungen bzw. Best Practices gelesen. Diese gibt es von Microsoft, VMware und noch diversen anderen Quellen (einen Teil davon habe ich unten verlinkt). Besonders hilfreich war dabei eine Artikelserie von David Klee auf der Seite sqlservercentral.com der sich „Stairway to SQL Server Virtualization“ (1) nennt.
Der Großteil meiner nun folgenden Einstellungen / Konfigurationen ist diesem Artikel entnommen da dort, anders als bei den anderen Quellen, direkt beispielhaft und nachvollziehbar die wichtigsten Punkte hervorgehoben sind.

  1. Storage / Festplattenaufteilung
    Hier gilt im Prinzip das gleiche was auch für die physikalische Hardware zählt: Aufteilung der Zugriffe auf möglichst viele Platten bzw. hier SAN Pfade (LUNs). Da es sich hier oftmals immer wieder um das gleiche Ziel auf dem SAN handelt, nur unterschieden durch unterschiedliche RAIDs (6 oder 10), ist als entscheidender Unterschied nur der Puffer jedes einzelnen Pfades (LUN) zu nennen.
    Das bedeutet auch, die richtigen RAIDs müssen über die unterschiedlichen LUNs an die VM durchgereicht werden. Dementsprechend ist die Festplattenkonfiguration und -zuweisung genauso komplex wie im „physikalischen Leben“.
    Das sieht dann zum Beispiel so aus – eng angelehnt an die Empfehlungen von David Klee (1):
    VM Guest Drive Konfiguration
    Wie im dem Artikel erwähnt, ist es auch von besonderer Wichtigkeit die richtigen Festplattenadapter, sprich Controller (vgl. SCSI ID) zu verwenden, also nicht die Standard sondern die Paravirtualisierten Adapter (Paravirtual SCSI Driver – PVSCSI). Für die Partitionen C: (OS) und Y: (Pagefile) in der Tabelle oben kann das bei dem Standard LSI SAS Controller bleiben.
    Der Rest sollte auf den erwähnten PVSCSI eingerichtet werden. Der entsprechende Controller und damit die Laufwerke sind allerdings erst in der VM vorhanden wenn die VMware Tools installiert sind.
    Die Zuordnung der Festplatten zum passenden Controller funktioniert mittlerweile leider nur noch in dem vSphere Webclient.

    Als Festplattentyp sind feste Diskgrößen (Thick-Provision Lazy-Zeroed bzw. Eager-Zeroed) als statische VHDs zu verwenden – Thin-Provision sind zwar am Anfang sparsamer beim Verbrauch des Plattenplatzes, verbrauchen dafür aber zusätzliche Ressourcen beim vergrößern der VMDK Dateien im Hintergrund wenn der Platz gebraucht wird. Das ist ähnlich wie beim Autogrowth einer Datenbank meistens der genau falsche Zeitpunkt und verursacht dann ggf. Probleme in der VM.
  2. CPU
    Die CPU Einstellungen gestalten sich ebenfalls etwas komplizierter.
    Es gilt bei dem ganzen Thema zu beachten, wie viele physikalische CPUs der ESX Host hat auf dem die VMs laufen sollen. Das sollte als Maximum angesehen werden was in den VMs vergeben werden sollte – ein Überbuchen der CPU Ressourcen, d.h. zuweisen von mehr CPU als der Host zur Verfügung hat, ist für SQL Server nicht sinnvoll.
    Zusätzlich könnte man noch im Zusammenhang mit der Größe des Speichers (Punkt 3) das Thema NUMA (Non Uniform Memory Access) betrachten. Das bedeutet, der Zugriff auf den einer CPU direkt zugeordneten Speicher geht schneller als wenn auf „weiter entferneten“ Speicher zugegriffen werden muss. In wiefern das Auswirkungen auf die Leistung der VMs hat, kann ich bisher nur abschätzen, da ich bisher keine Informationen von Dell bekommen habe, die mir die richtige Konfiguration bei unseren verwendeten Servern verrät.

    Die grundsätzlichen CPU Einstellungen verteilen sich einfach auf die virtuellen Sockets (Prozessoren) sowie Cores pro Socket (Kerne je Prozessor).
    Im Screenshot sieht man, dass damit bei dieser VM 12 Kerne zugeordnet sind, die dann auch nach aktuellen Lizenzbedingungen für den SQL Server zu lizenzieren sind (keine Garantie!).

  3. RAM
    Die Zuordnung des notwendigen Arbeitsspeichers für eine VM hängt hauptsächlich von der Größe der Datenbanken ab, die sich aus Performance Gründen möglichst vollständig im Arbeitsspeicher befinden sollten. Zu addieren ist dann noch ein Anteil für OS und SQL Server selber. In dem Screenshot oben sind aktuell 192 GB zugeordnet.
    Wie bei CPU schon angedeutet gibt es beim Thema NUMA noch fehlende technische Details die für die Konfiguration fehlen.
  4. Netzwerk
    Für das Netzwerk sind Adapter des Typs VMXNET3 zu verwenden, die ebenfalls erst nach Installation der VMware Tools in der VM ankommen.Grunsätzlich ist noch über ein Teaming von zwei Netzwerkkarten in der VM nachzudenken –  nicht unbedingt als Redundanz Thema aber wieder mit zwei Puffern als zusätzlicher Geschwindigkeitsvorteil – wenn auch wahrscheinlich minimal. Das gilt es noch zu testen. Dieser Punkt kam erst später durch ein weiteres Dokument von Idera „Moving SQL Server to a virtual Platform“ (6)  hinzu. Aus diesem Grund ist das auch nicht in der ursprünglichen Konfiguration mit enthalten.

Die gesamte Konfiguration bezieht sich auf die Einstellungen einer VM. Natürlich ist die komplette Installation inkl. SQL Server zum Schluss in eine Vorlage gewandert um daraus schnell einen weiteren SQL Server erstellen zu können.

Weitere Einstellungen:

  • Powerplan auf höchste Performance – in der VM als auch bei den ESXi Hosts.
    Die Kontrolle für die VM geht, neben dem Weg über die Energieeinstellungen, auch mit den Powershell dbatools mit dem Kommando Test-DbaPowerPlan (https://dbatools.io/functions/test-dbapowerplan )
    Weiteres zu den dbatools im nächsten Artikel „Migration“.

Quellen:

  1. Stairway to SQL Server Virtualization von David Klee auf sqlservercentral.com
    http://www.sqlservercentral.com/stairway/112551/
  2. Grundlegendes zu NUMA – https://technet.microsoft.com/de-de/library/ms178144(v=sql.105).aspx
  3. VMware Best Practices SQL Server – http://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/solutions/sql-server-on-vmware-best-practices-guide.pdf
  4. VMware Performances Best Practices
  5. Moving SQL Server to a virtual Platform von Idera (Registrierung erforderlich)
  6. Brent Ozars Seite zu Virtualization Best Practices: https://www.brentozar.com/sql/virtualization-best-practices/ (die Seite scheint an dieser Stelle nicht mehr zu existieren)

Themen für die noch folgenden Beiträge zum Projekt

  • Migration eines SQL Servers mit dbatools beschreiben, W2K16, SQL 2016 SP1
  • Performance Vergleich physikalisch <-> virtuell

Danke fürs Lesen,
Volker

Projekt SQL auf VMware Teil 2 – Konfiguration VMware

Veröffentlicht am von
1

Projekt SQL auf VMware – Teil 2 – Konfiguration VMware

Wir ersetzten sieben Hardware SQL Server durch eine neue VMware Umgebung.

Im Teil 1 ging es um das Warum, die Auswahl und die darauf folgende Bestellung.

In diesem Teil soll es um die Konfiguration der VMware Umgebung gehen, die während der Grundinstallation durch einen Dell Remote Techniker ausgeführt wurde.
Das war eine Premiere da wir ansonsten bisher eine Vor Ort Installation mit gebucht hatten.

Die Technik hinter der Umsetzung:

Die drei Server (Dell PowerEdge R730) enthalten jeweils 2 CPUs mit 12 Cores, das sind insgesamt 72 Cores und jeweils 512 GB RAM. In den Servern stecken zwei micro SD Karten für das Betriebssystem (VMware 6.0 – 6.5 wird vom SAN noch nicht unterstützt). In dem Compellent SC4020 SAN sind 9 SSD mit jeweils 3,82 TB, davon eine als HotSpare konfiguriert. Die Volumes sind als RAID 6 oder 10 verfügbar.
Server und SAN sind über die Dell S4048T Switche mit je 4 x10G angebunden.

Zuerst erfolgte die physikalische Installation der Umgebung im Rechenzentrum. Dabei ergab sich das Problem, dass die Switche ohne OS geliefert wurden. Es war also notwendig für die Switche und dann auch die beiden Controller des SAN serielle Anschlüsse zur Einrichtung zur Verfügung zu stellen. Dafür stellte mein Kollege mir einen 4-fach seriellen auf USB/Netzwerk Adapter auf Basis eines Raspberry zur Verfügung. Auf diesem waren dann gleichzeitig noch FTP, TFTP und diverse andere Server die sich für die Einrichtung als sehr hilfreich erwiesen.
Die Server und  das SAN waren gleichzeitig noch über ihre Management Ports (Dell iDRAC) erreichbar, was ebenfalls für die Grundinstallation notwendig war.

Anhand des prinzipiellen Aufbaus (Bild unten) kann man die Architektur der Umgebung gut erkennen. Oben zwei Server, darunter die beiden Switche woran dann auch das SAN angeschlossen ist. Natürlich wird alles doppelt verkabelt um eine größtmögliche Ausfallsicherheit zu erreichen.

 

URL aus dem Installationsguide von Dell für das Compellent SAN SC 4020
(Quelle und Copyright der Grafik liegen bei Dell.)

Die im Bild dargestellte Umgebung unterscheidet sich nur dadurch von unserer, dass hier nur zwei Server verwendet werden, bei uns aber drei Server als Hosts. Natürlich existieren noch weitere interne Verbindungen zwischen Servern, Switchen und dem SAN um zum Beispiel VMware, VMotion, iSCSI und sonstigen Traffic vom eigentlichen Traffic zum restlichen Netzwerk zu trennen. Dessen Verbindung geschieht dann über zwei Breakout Cable mit 4 x 10G welche direkt an unseren zentralen Core Switchen angeschlossen sind.

Die Grundinstallation erfolgte dann durch den erwähnten Dell Remote Techniker.

  • Server Firmware Updates
  • VMware Grundinstallation auf den SD Karten
  • Switch OS Installation und Konfiguration
  • SAN Einrichtung, Erstellung Volumes
  • iSCSI Einrichtung in der VMware und Verbindung der SAN Volumes

Während der darauffolgenden Tests der verschiedenen Ausfallszenarien (Switch, Server, SAN Controller) stellte sich ein Fehler beim Reboot eines der Switche heraus. Der Support von Dell hat den Switch dann direkt ausgetauscht.

Im nächsten Teil 3 gehe ich dann auf die die Detail-Konfiguration der VMs ein.

Danke fürs Lesen,
Volker

Migration SSRS 2008R2 -> 2016 – Renderformat für Excel hat sich geändert

Veröffentlicht am von
Antworten

Migration SSRS 2008R2 -> 2016 – Renderformat für Excel hat sich geändert

Bei der Migration unseres SQL Server Reporting Servers von 2008 R2 auf 2016 ergab sich gerade die Schwierigkeit, dass die zu versenden Excel Dateianhänge nicht erstellt werden können.
Die Reports und die Abos bleiben grundsätzlich erhalten wenn die Datenbanken ReportServer und ReportServerTempDB einfach mit umgezogen werden. Die Jobs werden nach Aktivierung des alten Berichtsserver-Schlüssels automatisch wieder erstellt.

Hintergrund der Fehlermeldung zu Excel ist dann das Renderformat. Das stand bei 2008R2 noch auf Excel 2003. Das Format gibt es nun aber nicht mehr.
Das bedeutet es muss in allen Reportabos das Format des Dateianhangs umgestellt werden.

Entweder manuell für jeden Report einzeln oder für alle Reports gleichzeitig per Skript.
Die Basis des Skripts ist für die Änderung von Email Adressen der Empfängern innerhalb der Reports (Quelle s.u.).
Ich habe das für mich angepasst so dass nun das Renderformat geändert werden kann.
Es muss dann anstatt EXCEL einfach EXCELOPENXML heißen:

DECLARE  @OldParameter      VARCHAR(100) = '<Value>EXCEL</Value>'
DECLARE  @NewParameter    VARCHAR(100) ='<Value>EXCELOPENXML</Value>'

BEGIN TRANSACTION
      UPDATE Subscriptions
            SET ExtensionSettings = CONVERT(NTEXT,REPLACE(CONVERT(VARCHAR(MAX),ExtensionSettings),@OldParameter,@NewParameter))
        FROM ReportServer.dbo.Subscriptions
        WHERE CONVERT(VARCHAR(MAX),ExtensionSettings) LIKE '%' + CONVERT(VARCHAR(100),@OldParameter) + '%'
COMMIT TRANSACTION

So hat es bei uns geklappt.

Danke fürs Lesen,
Volker

Quelle: http://www.sqlservercentral.com/blogs/briankmcdonald/2010/07/19/updating-email-addresses-in-ssrs-subscriptions/

Projekt SQL auf VMware Teil 1 – Einführung oder das „Warum“

Veröffentlicht am von
2

Projekt SQL auf VMware – Teil 1 – Einführung oder das „Warum“?

Wir ersetzten die sieben Hardware SQL Server durch eine neue VMware Umgebung.

Dieses Projekt möchte ich hier in einigen Schritten beschreiben vom Warum über die Auswahl bis hin zur (hoffentlich) erfolgreichen Umsetzung.
Das Projekt läuft seit November 2016 mit der Auswahl, die Bestellung ist Ende Januar 2017 erfolgt und jetzt ab März erfolgt die Umsetzung. Geplantes Projektende ist Ende Juli 2017. Bis dahin sollen die Server auf die VMware umgezogen sein.

Zum Anfang aber noch einmal zurück zum
Warum:

  • die physikalischen Server laufen nach und nach aus dem Support und müssten ersetzt werden.
  • Reduzierung der Kosten für den Neukauf aller physikalischen Server
  • Reduzierung der SQL Server 2016 Core Lizenzen – weniger Cores zu lizenzieren
  • bessere Hochverfügbarkeit (HA).
  • kürzere Wiederherstellungszeiten im Fall eines Disasters (Disaster Recovery – DR)
    – wir werden das noch genauer betrachten müssen.
  • weniger ungenützte Ressourcen auf den physikalischen Servern

Auswahl:

  • Zur Analyse und zur Auswahl der Hardware haben wir mit einem Dell Tool (DPack ) die Leistungsdaten der physikalischen Server über eine Woche aufgezeichnet.
  • Als ersten Eckpfeiler sahen wir dort ein Maximum von rund 11.000 IOPS welches wir auch entsprechend in der VMware umgesetzt bekommen müssten.

  • IOPS pro Sekunde

    IOPS pro Sekunde

  • Das ist nur ein Peak und deshalb als Maximalwert zu betrachten. Der Mittelwert bei 95% liegt bei 2475 IOPS
  • Hier zu sehen ist die Zusammenfassung für die 7 Server mit den ermittelten Daten:DPack Zusammenfassung der betroffenen Server
  • Das ist ebenfalls aus dem DPack-Report, was zwar hauptsächlich für Dell Server gedacht ist, aber meines Wissens durchaus auch für andere Hardware funktioniert.

Darufhin wurde dann eine Auswahl von 3 Dell Poweredge Servern (R730), zwei Dell 10G-Switchen (S4048T) sowie zwei SANs (Compellent SC4020) als zentralem Storage vorgeschlagen.

Für die VMware Version reicht uns an der Stelle die Essentials Plus Variante, da dieses eine komplett eigenständige Umgebung werden soll. Als Betriebssystem in den VMs dient uns Windows 2016 Datacenter mit der richtigen Core Anzahl.
Die SQL Server sind mit SQL Server 2016 Standard inkl. SA in der Core Variante lizenziert, ein einzelner wird auf Enterprise 2016 angehoben für einen Mobile Reports Reporting Server (SSRS).

Bestellung

Leider wurde für die Bestellung aus finanziellen Gründen eines der beiden SANs gestrichen was den Gesamtpreis um ca. 50K reduzierte. Das fehlende SAN beeinträchtigt das Thema HA in nur geringem Maß, ist allerdings für das Disaster Recovery entscheidend.
Bei einem kompletten Ausfall des SANs sind die unternehmenskritischen Produktiv-Datenbanken nun nicht mehr in kürzester Zeit auf dem zweiten SAN verfügbar sondern müssen aus dem Backup wiederhergestellt werden. Hier ist das Ziel der kürzeren Disaster Recovery Zeiten meines Erachtens wieder in weite Ferne gerückt.

Fortsetzung in Teil 2.

Danke fürs Lesen,
Volker

dbWarden – Monitoring – Änderung für SQL Server > 2012 notwendig

Veröffentlicht am von
Antworten

Ich bin immer noch ein Fan von dem SQL Skript „dbWarden“ welches ich nach wie vor zum Monitoring meiner SQL Server verwende.
Ich hatte das ja auch in den PASS Regionalgruppen Rheinland und Ruhrgebiet vorgestellt.
Die Weiterentwicklung ist leider zum Stillstand gekommen, die ursprünglichen Autoren haben schon länger keine Erweiterung mehr vorgestellt.

Seit Version 2012 des SQL Server gibt es Fehlermeldungen in dem täglichen Health Report:

Msg 213, Level 16, State 7, Procedure sp_replmonitorhelppublication, Line 322
Column name or number of supplied values does not match table definition.

Ein User in dem „Supportforum“ von SqlServerCentral für das Projekt hat das Problem erkannt und gelöst.

https://www.sqlservercentral.com/Forums/1441532/dbWarden-A-Free-SQL-Server-Monitoring-Package?PageIndex=18

After some digging I found that the problem is on section
/* Replication Publisher */   of the rpt_HealthReport stored procedure.

More specifically, the TEMP table #PUBINFO is populated with the output of sp_replmonitorhelppublication (on the distribution db) but it lacks the last column named publisher.
I added the missing column with a single line
,publisher NVARCHAR(128) — due to inconsistency with sp_replmonitorhelppublication’s outut right after line 998 on rpt_HealthReport and the Health Report was generated without any issue!
* DON’T FORGET THE COMMA AT THE BEGINNING

Auch wenn die Zeile in der Stored Procedure bei mir etwas anders ist, die Stelle ist zu finden.

Mit dieser Änderung funktioniert das Monitoring auch mit SQL 2012 und 2014 – 2016 steht in kürze an – ich werde dazu weiter berichten.

Danke fürs Lesen,
Volker

PS: Ältere Artikel dazu finden sich auch hier im Blog unter dem Schlagwort dbWarden

Optimierung Reporting Server MS SQL 2008 R2 Teil 2

Veröffentlicht am von
Antworten

Nach der Optimierung des Reporting Servers aus Teil 1 https://blog.volkerbachmann.de/2015/01/31/optimierung-reporting-server/ war es nur wenige Monate ruhig um den Reporting Server.
Die Anzahl der Reports steigt nahezu täglich und die Reports können nicht weit genug auseinander gezogen werden damit diese sich nicht in die Quere kommen.

Deshalb haben wir die Analyse mit der Unterstützung von Dell – als Lieferant des SQL Servers – noch einmal durchgeführt.

Ausgangslage: Reports brauchen bis zu 2 Stunden bis sie versendet werden

Analyse durch Dell mit DPack Tool
Flaschenhals:
1. Festplatten IOPS
2. RAM

Lösungsmöglichkeiten
1. Mehr IOPS zur Verfügung stellen
a. Vorhandene 6 Festplatten durch SSD ersetzen
b. Zwei SSD zusätzlich im RAID 1 und Verlagerung der meist frequentierten DBs auf diese SSD
c. Eine oder zwei SSD als CacheCade (erweiterter Cache des RAID Controllers) einrichten
2. Mehr Arbeitsspeicher zur Verfügung stellen
a. Zusätzlicher Speicher inkl. Enterprise Lizenz und ggf. Neuinstallation des Servers.

Das waren die Lösungsansätze bezüglich Hardware.

Weitere Möglichkeit:
3. Optimierung der Abfragen mit Unterstützung eines SQL Server Spezialisten

Kosten für die Umbauten:Kosten Optimierung Reporting Server 2008 R2

Durchgeführte Maßnahmen

1. Arbeitsspeicher +32GB / Windows Server Enterprise Edition
2. Eine SSD im RAID 0 für ReportServerTempDB
3. Optimierungen der Reports
durch Snapshot Technologie

Der Performance Monitor zeigt die Antwortzeiten für die TempDB Dateien sowie die 100% Aktivität der entsprechenden Festplatten im RAID 10.

Vor dem Umbau:

Performance Monitor vorher

Nach dem Umbau:

Performance Monitor nachher

Deutlich zu sehen ist dass die Antwortzeiten für die TempDB-Dateien (nun auf der SSD) auf „0“ runter gegangen und auch die Aktivität auf der SSD (Partition S:) ist auf 3% runter gegangen ist.

Als abschließender Vergleich nun noch die Laufzeiten ausgewählter Reports: Laufzeiten der Reports im Vergleich

Ergebnis: Seit Einbau der SSD sind die Laufzeiten der Reports deutlich runter gegangen. Auch die Snapshot Technologie hat für einige Reports deutliche Verbesserungen gebracht.

Der Einbau des Arbeitsspeichers alleine hat nicht dafür gesorgt dass die Reports schneller ausgeliefert werden konnten, hat aber dafür gesorgt, dass der Server im Ganzen nicht mehr so eng an den Grenzen des vorhandenen Arbeitsspeichers arbeitet, sondern noch ein wenig Luft hat.

Bisher ist das Ergebnis soweit ausreichend, dass keine weiteren Maßnahmen mehr notwendig sind.

Weitere Möglichkeiten wären:

  1. Umsetzung der Snapshot Techniken für weitere Reports
    2. Verlagerung weiterer (temporärer) Datenbanken auf die SSD
    1. ReportServer TempDB
    2. ReportCodes DB
    3. Sonstiges
    1. Optimierung von Abfragen, Indizes
    2. Ggf. In-Memory / Columnstore Index

Danke fürs Lesen.
Über Kommentare würde ich mich sehr freuen.

Viele Grüße
Volker