Warenkorb – SQL Server standartisieren
This post might contain affiliate links. We may earn a commission if you click and make a purchase. Your support is appreciated!
In großen Unternehmen – wie meinem Arbeitgeber – werden immer mehr Server/Services standardisiert, um einen günstigen Preis anbieten zu können.
Nun stehe auch ich vor der Aufgabe und möchte einen SQL-Server-Warenkorb erstellen, damit wir für alle Kunden einen standardisierten Service anbieten können.
Über Pro und Contra möchte ich mich hier nicht unterhalten, darüber kann man streiten… es gibt verschiedene Ausrichtungen.
Nach welchen Aspekten soll ich nun einen solchen Warenkorb konzipieren?
Welche Einflussgrößen sind entscheidend für die Größe eines Servers?
Wie unterscheiden sich die einzelnen Server?
Nur in CPUs / Cores?
Nur in RAM?
Welche Unterscheidungen muss ich treffen? Soll ich nur Virtuelle Server anbieten oder nur Hardware, ab einer bestimmten SQL Server Größe nur Hardware? Soll ein Feature der ausschlaggebende Punkt sein, ab wann man Hardware anbietet?
Also fangen wir mal vorne an…
Wer soll diesen Warenkorb konfigurieren können? Wer soll sich seinen Server selber zusammenstellen dürfen?
Bei uns sind das in der Regel Solution Architekten oder Service Delivery Manager (oder Service Manager), die nicht so wirklich in der Materie stecken und dem Kunden „schnell“ eine Lösung / ein Angebot präsentieren sollen.
Wenn diese aber nun für jeden Server / für jede Anfrage erst Rücksprache mit der Fachgruppe halten sollen und immer wieder nachfragen müssen, vergeht viel Zeit in der der Kunde wartet und kein Angebot erhält – für den Kunden sehr unbefriedigend.
Also muss ein Formular, am liebsten eine Online basierte Lösung – kein Excel / Access oder ähnliches.
Sharepoint wäre super bzw ideal, aber da sich unser Sharepoint aktuell in der Migration befindet (wir können bisher keine individuellen Formulare einbinden)… scheidet der Sharepoint erstmal aus. Mit Webseiten (PHP, JQuery und mySQL) kenne ich mich unweigerlich aus, das geht relativ zügig von der Hand und sieht auch nach „was“ aus.
Grobe Planung:
erstes Auswahl-Feld muss eine Hersteller-Auswahl sein => MS SQL, mySQL, DB2, Oracle, Informix und so weiter.
Je nach Hersteller wird eine andere Maske eingeblendet, da ich mich erstmal nur mit MS SQL auseinsetzen will… gibt es nur ein Formular.
Ok, was benötigen wir für die Bestellung eines MS SQL-Servers?
- Betriebssystem
- SQL Version / Edition
- Feature-Auswahl
- erwartete Datenbank-Größe
- Verwendungszweck (OLTP, OLAP, WebDB)
- Failover
- Replikation
- ???
Natürlich empfehlen wir immer die aktuellsten Versionen zu nehmen, daher werden die ersten Punkte relativ einfach. Die (Haupt-)Feature-Auswahl ist auch recht übersichtlich, Themen wie SSDT oder MDS bleiben erstmal aussen vor, da unsere Kunden dies bis auf wenige Ausnahmen nicht angefragt haben.
Soll die zu erwartende Datenbank-Größe als Textfeld oder als vorgebene Auswahl erfolgen?
Sollen die Features wie SSAS, SSIS, SSRS nur einzelnd angewählt werden können (Radiobutton) oder als Checkbox?
Welche Auswirkung auf die SQL Server Größen haben solche Aspekte wie mehrere Instanzen auf einem Server?
Was soll als Ergebnis herauskommen, wenn ein Failover Cluster benötigt wird?
Lauter Fragen, viele Ideen aber keine Lösung… also erstmal drauflos programmiert und den Kollegen vorgestellt zum gemeinsamen Brainstorming.
Wie beeinflussen die jeweilig getroffene Auswahl den angebotenen SQL Server? Eine Matrix muss her, anhand derer ein abschließendes Ergebnis präsentiert wird.
Falls Analysis Services benötigt wird und die Datenbanken größer x werden, soll eine Hardware mit DAS (Direct Attached Storage) angeboten werden, vorher kann dies auch mittels einer virtuellen Maschine geschehen. Integration- und Reporting-Services haben einen nicht so schwerwiegenenden Einfluss auf Cores/RAM wie Analysis-Services, wenn SSAS ausgewählt wird, kann es sich nicht gleichzeitig um einen Datenbank-Server für eine Webanwendung sein, genauso wenig können dann mehrere Instanzen (DB-Engine) installiert werden.
Für den Fall, dass ein Failover-Cluster benötigt wird, so soll dies nicht als Virtueller Server angeboten werden sondern als Hardware mit entsprechender Ausstattung.
Letztendlich bin ich zu 6 verschiedenen Servergrößen gekommen:
- 4 Cores , 8 GB RAM
- 4 Cores , 32 GB RAM
- 4 Cores , 64 GB RAM
- 4 Cores , 128 GB RAM
- 20 Cores , 256 GB RAM (Hardware)
- 24 Cores , 512 GB RAM (Hardware)
Damit kann ich die hier nahezu alle vorkommenden Szenarien abdecken und die Rechenleistung reicht auch völlig aus.
Bei den Datenbank-Größen mache ich jetzt folgende Vorgaben:
- < 50 GB
- 50 – 100 GB
- 100 – 250 GB
- 250 – 500 GB
- 500 – 1000 GB
- > 1000 GB
Für jedes 250GB-Datenfile gibt es eine neue Datenplatte um den IO-Stream nicht zu groß (zu langsam) werden zu lassen.
Am Ende kommt dann eine Empfehlung raus, mit der man dem Kunden eine entsprechende Kalkulation zukommen lassen kann.
Habe ich vielleicht einen Punkt übersehen?
Welche Punkte sollte ich eurer/Ihrer Meinung nach noch zusätzlich beachten und wie sollen diese in die Berechnung mit einfliessen?
Ich würde mich über eine rege Diskussion freuen.
This post might contain affiliate links. We may earn a commission if you click and make a purchase. Your support is appreciated!
Björn arbeitet auch weiterhin aus Mexiko als Senior Consultant – Microsoft Data Platform und Cloud für die Kramer&Crew in Köln. Auch der Community bleibt er aus der neuen Heimat treu, er engagiert sich auf Data Saturdays oder in unterschiedlichen Foren. Er interessiert sich neben den Themen rund um den SQL Server, Powershell und Azure SQL für Science-Fiction, Backen 😉 und Radfahren.
Amazon.com Empfehlungen
Damit ich auch meine Kosten für den Blog ein wenig senken kann, verwende ich auf diese Seite das Amazon.com Affiliate Programm, so bekomme ich - falls ihr ein Produkt über meinen Link kauft, eine kleine Provision (ohne zusätzliche Kosten für euch!).
Auto Amazon Links: Keine Produkte gefunden.