====== vCenter Heartbeat ====== ===== Physical to Physical - ein anderer Weg ===== Wenn man vCenter Heartbeat physisch to physisch installiert, gibt es eine schnelle Variante, die ich hier beschreiben möchte. ==== Hintergrund ==== Mit Windows 2012 gibt's doch einige Probleme mit dem Windows Backup und Restore. (Mehr dazu auch bei Jörg&Christians Blog unter [[http://www.vcoportal.de/2013/12/vmware-vcenter-server-heartbeat-restore-on-a-second-node-a-journey/|http://www.vcoportal.de/2013/12/vmware-vcenter-server-heartbeat-restore-on-a-second-node-a-journey/]] Außerdem dauert der Weg über Backup und Restore der HB Konfiguration eine ganze Weile. Hat man physische vCenter Server, die Festplatten in RAID 1 Konfiguration verwenden, beschreibe ich hier einen schnelleren Weg, der aber mehr Handarbeit benötigt :-) ==== Übersicht ==== Die Idee ist, nach der Installation des primären Knotens einfach den RAID 1 Spiegel aufzubrechen. D.h. die zweite Harddisk des Primären Knoten wird zur ersten Harddisk des Sekundären HeartBeat Knotens. Danach wir sowohl im primären, wie auch im sekundäre Knoten das RAID 1 wiederhergestellt. Während dieser Wiederherstellungszeit kann man bereits den sekundären Knoten weiterkonfigurieren. ==== Was ist zu tun? ==== - Installation des Betriebssystems und der vCenter Umgebung auf dem primären Knoten. Das ist erst einmal unspannend... - Installation von vCenter HeartBeat auf dem primären Knoten nach Installations Doku bis zu dem Schritt "Create Backup" - RAID Konfiguration aufbrechen * Primären Knoten herunterfahren * zweite Platte aus dem RAID 1 Verbund ziehen * diese zweite Platte als primäre Platte in den Sekundären Knoten schieben * neue Platte als zweite Platte in den primären Knoten schieben und Server starten * ggf. muss die neue Platte als "Spare Disk" gekennzeichnet werden, damit diese für das RAID 1 genutzt wird (z.B. bei LSI RAID Controller) * sekundären Server //__ohne Netzwerk__// starten und im RAID BIOS die RAID Konfiguration von der primären Platte einlesen lassen. (bei LSI RAID Controller Option "Read Foreign Config") * im sekundären Server auch die zweite Platte als Spare kennzeichnen, so das RAID 1 wieder neu gebaut wird. - beim sekundären Server ''sysprep'' starten und den Server zum Hostnamen des zweiten Knotens umbenennen. - durch sysprep wird der Knoten neu gestartet, dabei kann dem Server wieder sein Netzwerk zurückgegeben werden - den Rechner in die Domäne aufnehmen und ggf. die Laufwerksbuchstaben neu sortieren - im Neverfail Programm Verzeichnis unter ''\R2\bin'' das Setup mit ''setup -installSecondary'' starten. - Dieses Setup startet die Konfiguration. Am wichtigsten sind dabei in diesem Wizzard die Optionen "... make Secondary" und die public IP Adresse muss manuell gesetzt werden. - danach kann der HB Service auf dem Secondary Node gestartet werden - in der HeartBeat Konfiguration müssen noch einige Dinge konfiguriert werden * SQLServerNFPlugin konfigurieren (KB2061548) * Timeout für SQLServer und vCenter auf 600 Sekunden erhöhen * SQLServer Agent als überwachten Service einrichten * Pingeinstellungen überprüfen * ggf. SetSPN Kommando durch eigenes Script ersetzen (Siehe dazu entsprechenden Artikel) - SQLServer Wartungs&Backup Jobs auf beiden Knoten einrichten (z.B. Lösung von [[http://ola.hallengren.com/|Ola Hallengren]]. Deshalb auch der SQL Agent als überwachter Service... - Failovertests laut Dokumentation absolvieren - fertsch! - Wie man im Sächsischen sagt.... Das sieht auf dem ersten Blick nach mehr Handarbeit aus. Jedoch ist man um Längen schneller und weiß was man konfiguriert hat :-) ====== SetSPN und Domänenaccount ====== ===== Das Problem ===== Seit Jahren zieht sich ein "Bug" durch vCenter Hearbeat. Konfiguriert man den SQLServer so, dass er unter Domänennutzeraccount läuft, gibt es mit ''setSPN.exe'' ein Problem :-( In der HeartBeat Konfiguration setzt man den Account unter dem setSPN aufgerufen wird. Dies muss ein Domänennutzer sein. Jetzt das Problem: setSPN erwartet den Nutzer in der Notation //''Domäne\Nutzername''//. Jedoch egal wie der Nutzer konfiguriert wird, wird dieser von HB __immer__ in der Form //''Nutzername@Domäne''// an setSPN übergeben, was dann natürlich zum Fehler führt. ===== VMwares Workaround ===== Der Workaround von VMware ist eine Wrapper Batchdatei, die setSPN.exe mit den richtigen Parameter aufruft. Dafür muss man den beiden Knoten in der Domäne entsprechende Rechte geben. "...Thank you for your patience with us. We realize that some changes will need to be made to the existing KB 2017530 - Performing a Least Privilege Installation of vCenter Server Heartbeat when protecting SQL Server. Until this gets address in a future release of the vCenter server heartbeat, the workaround for now is as follows: 1. On the Domain Controller, navigate to Active Directory Users and Computers. 2. Under the View menu ensure Advanced Features is ticked. 3. Select the computer account of the server running vCenter Server Heartbeat. 4. On the Primary computer account (Primary Management Name): 1. Navigate to the Security tab and click Advanced. 2. On the Permissions, tab click Add. 3. Select the user to run the SetSPN command (this can be the same user that runs SQL Server ie. 2a-net\sqlservervc). 4. Assign the Allow permission for Write all properties and Apply to this object and all child objects. 5. Click OK. 5. On the Secondary computer account (Secondary Management Name): 1. Navigate to the Security tab and click Advanced. 2. On the Permissions tab, click Add. 3. Select the user to run the SetSPN command (this can be the same user that runs SQL Server ie. 2a-net\sqlservervc). 4. Assign the Allow permission for Write all properties and Apply to this object and all child objects. 5. Click OK." ===== der "korrekte" Weg... ===== Mit Windows 2012 gibt es da noch ein Problem - eine etwas strengere Handhabung mit registered Services. Was heißt das? Wenn man von Knoten A auf Knoten B umschaltet, muss man den SQLService vom Knoten A deregistrieren und bei Knoten B registrieren. Das führt dann zu separaten Scripten für beide Knoten: setspn.exe -D MSSQLSvc/:MSSQLSERVER ping -n 10 0 >NUL setspn.exe -a MSSQLSvc/:MSSQLSERVER setspn.exe -D MSSQLSvc/:MSSQLSERVER ping -n 10 0 >NUL setspn.exe -a MSSQLSvc/:MSSQLSERVER