Microsoft SQL Server Alias & Instanz-Installation

Hallo Freunde der Sonne,

in diesem Beitrag geht es darum auf einem Windows-Server mehrere SQL-Instanzen mit verschiedenen Netzwerk-Ports (TCP: 1433, 1434, 1435,1436…) zu installieren und auf dem Ziel als Standard-Instanz zu konfigurieren.

Vorteile: einfachere Migration der Datenbank später, besseres Ressourcen-Management durch zentralen SQL-Server/Cluster

Microsoft SQL Server Alias & Instanz-Installation

Übersicht:

  1. Installation der SQL-Management-Tools auf dem späteren Client der SQL-Instanz (Beispiel: ein Sharepoint-Server)
  2. Installation der SQL-Instanz auf dem SQL-Server passen für den Client-Server

1. Installation der SQL-Management-Tools auf dem späteren Client der SQL-Instanz (Beispiel: ein Sharepoint-Server)

Wie normal bei Server-Installation wird zuerst das SQL-Server-Medium beim Zielsystem eingehangen und die Installation des SQL-Server gestartet.

Vorkonfigurierter Lizenzschlüssel und EULA bitte bestätigen und die Installation nach Komponenten auswählen, welche Komponenten installiert werden sollen sieht man in Abbildung 1.

Abbildung 1: SQL-Server Clienttools
Abbildung 1: SQL-Server Clienttools

Hiermit sind wir nun in der Lage den SQL-Native-Client zu konfigurieren und ggf. per SQL Management Studio die Datenbank vom Client aus zu verwalten.

Nun konfigurieren wir die Verbindung zum SQL-Server in dem wir ein Alias auf dem Client anlegen. Sinn dahinter ist, dass das Alias auf andere Server zeigen und anderen Netzwerkports verwenden kann – die später aber nicht in der eigentlichen Anwendung konfiguriert werden müssen. (Beispiel: Sharepoint)

Im Beispiel verwendet unsere SQL-Instanz für Sharepoint den TCP-Port 1436, die Konfiguration sieht man in Abbildung 2.

Abbildung 2: SQL-Clienttools Alias-Konfiguration
Abbildung 2: SQL-Clienttools Alias-Konfiguration

Ich empfehle sicherheitshalber immer auch ein Alias für 32-Bitanwendungen hinzuzufügen, so dass das selbe Ziel immer auf beiden Seiten definiert ist.

Als Namen des Alias empfehle ich den Instanz-Namen. (für die spätere Übersichtlichkeit praktisch)

Im Client kann nun eine SQL-Datenbank auf den Server „SHAREPOINT2013“ ohne weitere Port- bzw. Instanzangabe erfolgen.

 

2. Installation der SQL-Instanz auf dem SQL-Server passen für den Client-Server

Nun zur Installation des passenden Datenbank-Moduls des SQL-Servers auf dem SQL-Server/Cluster für dei eneu Instanz.

Wie beim Client bitte das Medium für den gewünschten SQL-Server einlegen und die Installation starten, dann bitte den Abbildungen für den Installations-Assistenten folgen.

Tipp: Es ist möglich auf dem Client die SQL-Server Clienttools 2014 zu installieren auf dem späteren Server aber den SQL-Server 2012 zu verwenden um die Instanz zu hosten!

Abbildung 3: SQL-Server Funktionsinstallation
Abbildung 3: SQL-Server Funktionsinstallation

Abbildung 4: SQL-Server Datenbankdienste für eine neue Instanz
Abbildung 4: SQL-Server Datenbankdienste für eine neue Instanz

Es empfiehlt sich aus meiner Sicht die Installationspfade für die Binardaten des SQL-Server in dem Standard-Installations-Pfad zu belassen.

Abbildung 5: SQL-Server Benennung der Instanz
Abbildung 5: SQL-Server Benennung der Instanz

Im der Abbildung wird für die Installation der Instanz-Name „SHAREPOINT“ verwendet, da die Instanz „SHAREPOINT2013“ bereits zu diesem Zeitpunkt installiert war.

Abbildung 6: SQL-Server Gemischter Modus
Abbildung 6: SQL-Server Gemischter Modus

Zur Erinnerung , es empfiehlt sich den gemischten Modus zu verwenden um im Notfall den SA-Account als letzte Zugriffsebene verwenden zu können.

Für die Installation von Sharepoint empfiehlt es sich neben dem normalen Domänen-Administrator auch den Sharepoint-Installations-Benutzer als Admin der Instanz hinzuzufügen.

Abbildung 7: SQL-Server Installationspfade
Abbildung 7: SQL-Server Installationspfade

Wie üblich empfiehlt es sich die Datenbanken auf eine eigene Festplatte beim SQL-Server zu verlegen um den reinen SQL-Datenverbracuh besser kontrollieren zu können.
Bei mehreren Instanzen empfehle ich einen Ordner für Datenbanken und darunter für die entsprechenden Instanzen zu konfigurieren – so dass die Datenbankdateien pro Instanz abgelegt werden können.

Zusätzlich würde ich die Struktur auf der Datenpartition dann für einen Backup-Bereich extra anlegen, so dass pro Instanz ein Wartungsplan konfiguriert werden könnte der pro Instanz die BAK-Dateien der Datenbanken ablegen kann. (für das externe Backup könnte dann der Ordner „Backup“ freigegeben werden)

Abbildung 8: SQL-Server Netzwerkkonfiguration der Instanz
Abbildung 8: SQL-Server Netzwerkkonfiguration der Instanz

Info: Bitte sicherstellen, dass TCP für die Instanz aktiviert ist und ggf. der spätere SQL-Port in der Firewall freigegeben ist.

Abbildung 9: SQL-Server Portkonfiguration
Abbildung 9: SQL-Server Portkonfiguration

In diesem Beispiel werden keine Einzelkonfiguration pro Netzwerkadapter zugelassen – daher steht bei jeder Bindung (IP1-6) der Status auf Aktiviert: nein.

Für die zentrale Konfiguration der Instanz die für alle Adapter gilt empfehle ich nun den dynamischen Port zu entfernen und den neuen SQL-Server TCP-Port statisch festzulegen.

Erklärung: Sollten mehrere Instanzen auf dem SQL-Server mit nur dynamischen Ports installiert worden seien – so kann per <Server>\<Instanz> auf diese zugegriffen werden – wird jedoch bei einer Instanz (meist der Standard-Instanz) der statische Port 1433 konfiguriert, so wird diese Funktion verhindert. (daher verwendet die Unterinstanz gleich einen festen Port der im Alias hinterlegt wird)

TIPP: Im SQL-Management-Studio wird der Port mit einem Komma angegeben, zur manuellen Verbindung direkt auf den Server heißt es dann ohne Alias: <Server>, <Port>.

Das war es auch schon wieder, viel Spaß.