Red Hat Summit8.6. Einrichten von redundanten (zusätzlich vorhandenen) Satellites mit eigenständiger DB
In Übereinstimmung mit der verfügbaren Klon-Option für Satellites mit der Embedded Database können Sie Ausfälle auf Satellites mit der Stand-Alone Database durch die Vorbereitung reduntanter Satellites begrenzen. Im Gegensatz zum Klonen eines Satellites mit Embedded Database können redundante Satellites mit Stand-Alone Database entweder aktiv ablaufen oder sich auch in Bereitschaft (Standby) befinden. Dies hängt völlig von Ihrer Netzwerk-Topologie ab und ist unabhängig von den hier aufgelisteten Schritten:
Um diese Redundanz zu errichten, installieren Sie zuerst den primären Satellite ganz normal, mit Ausnahme des Wert im Feld 'Common Name' für das SSL-Zertifikat, der in diesem Fall Ihre hochverfügbare Konfiguration repräsentiert und nicht den Hostnamen des einzelnen Servers. Danach:
- Bereiten Sie die Stand-Alone Database zur Ausfallsicherung vor, indem Sie Oracle's Empfehlungen zum Bau einer fehlertoleranten Datenbank befolgen. Beratschlagen Sie sich dahingehend mit Ihrem Datenbankadministrator.
- Installieren Sie RHN Satellite mit Stand-Alone Database (und einer Basisinstallation von Red Hat Enterprise Linux AS) auf einem separaten Rechner, überspringen dabei die Datenbankeinrichtungs- und Tabellenraumschritte sowie auch die Schritte zur Erstellung des SSL-Zertifikats und Bootstrap-Skripts. Fügen Sie dieselben Informationen zum RHN-Account und zur Datenbankverbindung wie bei der Satellite-Erstinstallation ein, und registrieren Sie den neuen Satellite.Wenn Ihr originales SSL-Zertifikat Ihre Hochverfügbarkeitslösung nicht berücksichtigt, können Sie ein neues Zertifikat mit einem angemesseneren 'Common Name'-Wert erzeugen. In diesem Fall können Sie auch ein neues Bootstrap-Skript erstellten, welches diesen Wert erfasst.
- Kopieren Sie nach der Installation die folgenden Dateien vom primären Satellite zum sekundären Satellite:
/etc/rhn/rhn.conf/etc/tnsnames.ora/var/www/rhns/server/secret/rhnSecret.py
- Kopieren und installieren Sie die serverseitigen SSL-Zertifikat-RPMs vom primären zum sekundären Satellite. Siehe den Abschnitt 'Gemeinsame Verwendung von Zertifikaten' im RHN Client-Konfigurationshandbuch für detailliertere Anweisungen. Bitte vergessen Sie dabei nicht, dass der 'Common Name'-Wert nicht den Hostnamen eines einzigen Rechners darstellt, sondern für die gesamte Satellite-Lösung steht.Wenn Sie während der Satellite-Installation ein neues SSL-Zertifikat generiert haben, das einen neuen 'Common Name'-Wert beinhaltet, kopieren Sie die SSL-Zertifikat-RPMs vom sekundären zum primären Satellite und verteilen das clientseitige Zertifikat neu. Wenn Sie ebenfalls ein neues Bootstrap-Skript erzeugt haben, können Sie dieses dazu verwenden, das Zertifikat auf Client-Systemen zu installieren.
- Wenn Sie kein neues Bootstrap-Skript erzeugt haben, kopieren Sie die Inhalte von
/var/www/html/pub/bootstrap/vom primären zum sekundären Satellite. Wenn Sie ein neues Skript erzeugt haben, kopieren Sie die Inhalte des Verzeichnisses zum primären Satellite. - Schalten Sie RHN Task Engine auf dem sekundären Satellite mit folgendem Befehl ab:
/sbin/service taskomatic stop
/sbin/service taskomatic stopCopy to Clipboard Copied! Toggle word wrap Toggle overflow Sie können selbst ein Skript erstellen oder auch andere Hilfsmittel dazu verwenden, um den automatischen Start der RHN Task Engine auf dem sekundären Satellite einzurichten. In jedem Fall muss der Satellite im Falle eines Ausfalls gestartet werden. - Verwenden Sie Channel-Paketdaten (standardmäßig in
/var/satellite) gemeinsam auf beiden Satellites über eine Art vernetztes Speichergerät. Dies eliminiert Datenreplikation und gewährleistet ein konsistentes Speichern von Daten für jeden Satellite. - Verwenden Sie die Cache-Daten (standardmäßig in
/var/cache/rhn) gemeinsam auf beiden Satellites über eine Art vernetztes Speichergerät. Dies eliminiert Datenreplikation und gewährleistet ein konsistentes Speichern von Cache-Daten für jeden Satellite. - Stellen Sie die verschiedenen Satellites in Ihrem Netzwerk via Common Name und einer Methode, die zu Ihrer Infrastruktur passt, zur Verfügung. Optionen sind unter anderem round-robin DNS, ein Netzwerklastverteiler und ein Reverse-Proxy-Setup.
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}