Archiv für den Monat: Januar 2017

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