15

Like it now

Im Artikel „Pleasant Password Server“ wurde der Password Server initial installiert, sowie ein paar wichtige Grundeinstellungen vorgenommen. Anhand dieser Anleitung wird nun ein weiterer Server („PWS02“) installiert und auf die bestehende Datenbank konfiguriert, zudem wird ein Windows Failover Cluster mit „PWS01“ & „PWS02“ als Nodes eingerichtet, sodass der vorgelagerte DNS-Eintrag („pws.demolabor.intern“) zwischen den beiden Nodes geschwenkt werden kann und somit eine höhere Verfügbarkeit entsteht.

Vorgehensweise

Es wird der „Pleasant Password Server“ in der Grundinstallation installiert, danach wird der Port umgestellt, sowie das Zertifikat vom PWS01 zum PWS02 übertragen und dort dann bei „Service Configuration“ eingetragen. Anschließend wird die Datenbank-Anbindung geändert, sodass auf die SQL-Datenbank zugegriffen werden kann, danach wird die Lizenz eingetragen. Es folgt noch die Einrichtung eines Windows-Failoverclusters für den Schwenk des DNS-Namens, über den beide Passwordserver erreichbar sein sollen.

SSL-Zertifikat übertragen

Das bestehende Zertifikat vom PWS01 wird dort exportiert und auf dem PWS02 importiert, sowie dann im „Pleasant Password Server“ hinterlegt.

Sicherung der bestehenden Konfiguration

Um sicher zu gehen, dass im Falle eines Fehlers die aktuelle Konfiguration wiederhergestellt werden kann, sollten folgende Dinge kurz kontrolliert/durchgeführt werden:

1. Prüfung der Password-Server eigenen Backups
2. Prüfung der SQL-Backups bzw. Erstellen eines Backups
3. Backup der Virtuellen Maschine
4. Snapshot der Virtuellen Maschine erstellen

Prüfung der Password-Server eigenen Backups

Auf der Seite „https://pws.demolabor.intern/Admin/ManageDb/Backup“ („pws.demolabor.intern“ ist meine Testumgebung und muss durch die den eigenen Hostnamen ersetzt werden) sieht man den Pfad, den man für die automatischen Backups angegeben hat. Hier kann man sowohl kontrollieren, ob diese sauber angelegt werden, sowie mit Klick auf den Button <Backup now> noch ein schnell eines erstellen.

Prüfung der SQL-Backups bzw. Erstellen eines Backups

Auf dem SQL-Server prüfen, ob die Datenbank regelmäßig gesichert wird. Am besten hier auch noch schnell ein manuelles Backup erstellen. In meiner Demo-Umgebung gab es noch keine automatische Sicherung der SQL-DB, weshalb ich manuell eine erstellt habe; dazu habe ich diesen SQL-Befehl ausgeführt:

BACKUP DATABASE [PWS] TO  DISK = N'S:\SQL\Microsoft SQL Server\MSSQL16.MSSQLSERVER\MSSQL\Backup\PWS_2023-04-01_before_snd_PPS.bak' WITH NOFORMAT, NOINIT,  NAME = N'PWS-Full Database Backup', SKIP, NOREWIND, NOUNLOAD, COMPRESSION,  STATS = 10, CHECKSUM
GO
declare @backupSetId as int
select @backupSetId = position from msdb..backupset where database_name=N'PWS' and backup_set_id=(select max(backup_set_id) from msdb..backupset where database_name=N'PWS' )
if @backupSetId is null begin raiserror(N'Verify failed. Backup information for database ''PWS'' not found.', 16, 1) end
RESTORE VERIFYONLY FROM  DISK = N'S:\SQL\Microsoft SQL Server\MSSQL16.MSSQLSERVER\MSSQL\Backup\PWS_2023-04-01_before_snd_PPS.bak' WITH  FILE = @backupSetId,  NOUNLOAD,  NOREWIND
GO

Backup der Virtuellen Maschine

Wenn man die Virtuelle Maschine produktiv betreibt, solle hier ohnehin schon ein regelmäßiges Backup erfolgen. Auf meiner Demo-Umgebung habe ich (noch) kein Backup-Verfahren, weshalb ich dieses nicht prüfen kann bzw. jetzt auch kein manuelles erstellen kann.

Snapshot der Virtuellen Maschine erstellen

Der Vorteil eines Snapshots ist, dass dies ganz einfach auf dem Hypervisor erstellt werden kann und man (wie in vielen Unternehmen) keine Unterstützung durch das Backup-Team benötigt.

In meiner Demo-Umgebung erstelle ich im „Hyper-V Manager“ ganz einfach den Snapshot (bzw. hier heißt die Funktion „Checkpoint“).

Ändern der Datenbank-Anbindung auf dem PWS02

Der Wechsel erfolgt im Grund genommen genauso, wie das Kapitel „Datenbank wechseln“ im ersten Artikel (Pleasant Password Server).

Also:

1. Dienst „Pleasant Password Server“ stoppen
2. In die Diensteigenschaften gehen und dort im Reiter „Log On“ von „Local System account“ auf „This account“ umstellen und die Anmeldedaten des Serviceaccounts „SA-PWS“ eintragen
3. Im „PasswordManager Service Configuration“ (Im Startmenü als „Service Configuration“ zu finden) über den Button <Database Configuration> den „Database Provider“ von „SQLite“ auf „MSSQL“ umstellen und den passenden „Connection String“ eintragen.
   Tipp: Einfach beim PWS01 nachschauen 😉
4. Dann den Dienst „Pleasant Password Server“ wieder starten

Der originale „Connection String“ auf dem PWS02 sah bei mir so aus:

Data Source=[DataFolder]\PleasantPassServer.db;Key=aes256:Cy8qSEX72YIy18vRchpzyP3Tm8knLoKCvhp4eitiYnM

Der passende „Connection String“ für die SQL-Datenbank ist bei mir:

Server=SQL-AG1;Database=PWS;Encrypt=False;Integrated Security=SSPI;TrustServerCertificate=False;

Hinweis:
Sollte die Fehlermeldung kommen, dass der Dienst nicht gestartet werden kann (Error-Code 1064), dann den Service-Account in die lokalen Administratoren aufnehmen. Danach nochmal probieren den Dienst zu starten.

Server aktivieren

Im Webportal auf den Menüpunkt „License“ klicken, dort den Key eintragen und auf den Button „Activate“ klicken.

Windows Failover-Cluster

Ein Windows-Failover-Cluster wird hierbei verwendet, um als Rolle den DNS-Namen „pws.demolabor.intern“ zwischen beiden „Password Server“ zu schwenken. Auf beiden Servern läuft zwar aktiv der Dienst „Pleasant Password Server“, aber nur einer wird aktiv verwendet. Der Hintergrund ist, dass Webdienste nicht failoverclusterfähig sind, alternativ könnte man natürlich einen Loadbalancer vornedran stellen, welcher beide Server 50:50 bedient, solange beide verfügbar sind.

Auf beiden Servern wird das Feature „Failover Clustering“ installiert, anschließend im „Failover Cluster Manager“ das Cluster „pws-foc.demolabor.intern“ erstellt. Danach wird eine neue Rolle konfiguriert. Für den aktuellen Anwendungsfall wird als Rollentyp „Other Server“ gewählt. Bei der Wahl des DNS-Namens ist zu beachten, dass der im Artikel „Pleasant Password Server“ angelegte DNS-A-Record „pws.demolabor.intern“ gelöscht werden muss, sodass das Cluster diesen anlegen kann – andernfalls erscheint die Fehlermeldung „The networkname ‚pws.network.intern‘ is already used in the network“.