Wir haben eine Anwendung, die auf ein paar (5 oder so) Boxen läuft und wachsen wird. Die Hardware ist in allen Maschinen identisch, idealerweise auch die Software. Ich habe sie bis jetzt von Hand verwaltet und möchte nicht mehr (statische IP-Adressen, Deaktivieren aller erforderlichen Dienste, Installieren erforderlicher Pakete ...). Kann jemand die Vor- und Nachteile der folgenden Optionen abwägen oder etwas Intelligenteres vorschlagen?

1: Installieren Sie Centos einzeln auf allen Boxen und verwalten Sie die Konfigurationen mit chef / cfengine / puppet. Dies wäre gut, da ich mir eine Ausrede gewünscht habe, um die Verwendung einer der Anwendungen zu erlernen, aber ich weiß nicht, ob dies tatsächlich die beste Lösung ist.

2: Machen Sie eine Schachtel perfekt und stellen Sie sie sich vor. Liefern Sie das Image über PXE, und wenn ich Änderungen vornehmen möchte, kann ich die Boxen einfach von einem neuen Image aus neu starten. Wie gehen Cluster-Leute normalerweise damit um, Mac-Adressen in den Dateien / etc / sysconfig / network-scripts / ifcfg * zu haben? Wir verwenden auch Infiniband und es weigert sich auch zu starten, wenn der hwaddr falsch ist. Können diese beim Booten korrekt generiert werden?

Ich neige zur PXE-Lösung, denke aber, dass die Überwachung mit Munin oder Nagios etwas komplizierter sein wird. Hat jemand Erfahrung mit dieser Art von Problem?

Alle Server verfügen über SSDs und sind schnell und leistungsstark.

Danke, Matt.

Ihr Cluster klingt eher nach einem HPC-Cluster als nach einem OLTP-Cluster, aber ich denke, das Setup, das ich verwende, würde auch für Sie funktionieren. Ich nenne es das "mpdehaan trifecta", weil das der ircnick des Typen ist, der die drei beteiligten Werkzeuge geschrieben oder verwaltet.

1.) Cobbler für die Basis-Build-Bereitstellung. Cobbler ist ein Projekt, dessen Ziel es ist, die Schnittstelle zwischen Ihren Kickstart-, PXE-, YUM-Repo-, DHCP-, DNS- usw. Systemen zu bilden. Dies ist bei weitem der einfachste Weg, um ein Kickstart-Setup zum Laufen zu bringen, und Sie können bei Bedarf die anderen Funktionen erweitern.

2.) Marionette für das Konfigurationsmanagement. Idealerweise handelt es sich bei Ihren von Cobbler gebauten Hosts um Barebones-Konfigurationen, die gerade genug wissen , um beim Start zu Ihrem Puppenserver zu telefonieren. Puppet wendet dann Ihre Konfigurationseinstellungen an und hält sie in Ihrer Umgebung auf Dauer konsistent.

3.) Funktion für Ad-hoc-Befehle an mehrere Computer gleichzeitig. Zum Beispiel "Stellen Sie eine neue svn-Prüfung des Codes bereit und starten Sie Apache neu". Es ist ziemlich einfach, func zu verwenden, um denselben Bash-Befehl auf einer Gruppe von Servern wie cluster-ssh aufzurufen. Wenn Sie wirklich darauf eingehen wollen, können Sie Ihre eigenen Module dafür mit etwas wirklich einfachem Python schreiben.

Alle drei Tools haben gute Wikis und aktive IRC-Kanäle für Hilfe bei Freenode.

Überblick

In gewisser Weise haben Sie hier zwei Fragen.

• Wie erstelle und verwalte ich Standardserver?
• Wie kann ich die Standardkonfiguration beibehalten und später Änderungen vornehmen?

Ich habe meine Antwort unten aufgeteilt und diese beiden Dinge getrennt behandelt, aber sie hängen sehr eng zusammen. Ich spreche hier die Technologielösungen an und nicht die Best Practices, die damit zusammenhängen, wie z. B. die Änderungskontrolle.

Wenn dies nicht den Umfang Ihrer Frage abdeckt, klären Sie dies bitte, und ich werde es Ihnen gerne erläutern. Dies ist eine notwendige Grundlage, die für eine gut geführte technologische Infrastruktur von entscheidender Bedeutung ist.

Server aufbauen

Ich mag keine Bilder in der UNIX-Welt. das ist eher ein Windows-Ansatz. Sogar einige Windows-Benutzer scheinen sich jetzt wieder auf Skripte für Standardbuilds zu konzentrieren.

Satellite scheint in der RHEL-Welt etwas populärer zu werden. Spacewalk ist das Open Source-Gegenstück. Sie müssen sich definitiv auf den RHEL-Ansatz einlassen, um diesen nutzen zu können. Dies dient sowohl zur Servererstellung als auch zur Konfigurationsverwaltung.

Idealerweise möchten Sie lokale Spiegel und Repositorys auf einem Dateiserver für die gesamte erforderliche Software einrichten.

Nutzen Sie zunächst Ihre Automatisierung der Distributionserstellung, z. B. Kickstart in RHEL / CentOS. Der Kickstart wäre eine Basis mit Variationen, die von Ihren Bedürfnissen abhängen. Die Kickstart-Builds können von einem PXE-Server initiiert werden.

Für den fortgeschritteneren Teil des Builds und für alles, was für eine Kickstart-Datei nicht geeignet ist, können Sie Ihre eigenen benutzerdefinierten Skripte schreiben. Möglicherweise funktioniert Puppet oder Cfengine jedoch auch für Sie anstelle von benutzerdefinierten Skripten. Ich habe festgestellt, dass benutzerdefinierte Skripte am flexibelsten sind und nicht auf einen einzelnen Ansatz beschränkt sind.

Wenn Sie eigene Skripte schreiben möchten, empfehle ich ein Kernskript für die universelle Konfiguration. Dies wäre Sicherheitskonfiguration, Härten und alles, was für alle Builds gilt. Dann ein abschließendes Skript, um die Serverrolle abzuschließen. Zum Beispiel ein Webserver oder ein Datenbankserver.

Standards einhalten

Was Sie beschreiben, fällt auch unter die Pflege von Konfigurationen. Build-Standards, Software-Updates und andere Dinge hängen mit Builds zusammen, sind jedoch in vielerlei Hinsicht voneinander getrennt.

Wenn Sie sich auf Systempakete verlassen, anstatt Ihre eigenen quellbasierten Builds für Ihre wichtigsten Serverrollen zu erstellen, kann ein Großteil davon mit systemeigenen Dienstprogrammen verwaltet werden. Dies kann ein einfaches Skript sein, mit dem Sie eine forSchleife für Ihre Serverliste ausführen und eine yum -y update package.

Bei der Konfigurationsverwaltung kommen hier Puppet-, Cfengine- und andere Konfigurationsverwaltungsprogramme zum Einsatz. Dies sind sehr nützliche Dienstprogramme, die die notwendige Grundlage bieten, ohne Ihre eigenen Skripte von Grund auf neu zu schreiben.

Wenn Sie Ihre Konfigurationsstandards für Ihre Server aktualisieren, ist es wichtig, diese in Ihre Standardserver-Builds zu übernehmen.

Ich habe kürzlich ein großes Projekt abgeschlossen, um ein zentrales Build- / Bereitstellungs- und Konfigurationsmanagementsystem bei $ WORK einzuführen. Wir führen CentOS aus.

Mein Design, das mir sehr gut gefällt, ermöglicht uns einen Build-Prozess mit nur einem Klick (also einer Web-GUI-Seite), bei dem einige benutzerdefinierte PHP-Skripte verwendet werden, um alles über eine einfache, aber effektive Web-Benutzeroberfläche miteinander zu verknüpfen.

Die allgemeine Theorie lautet:

1. Führen Sie alle Installationen von einer einzigen, einheitlichen, minimalistischen KickStart-Datei aus (OK, eine für x86 und eine für x86-64, aber immer noch praktisch identische Dateien mit minimaler Paketauswahl).
2. Das KickStat-Nachinstallationsskript bootstraps Puppet.
3. Puppet wendet alle knoten- / hostspezifischen Konfigurationen, Paketinstallationen usw. an.

Ich bin damit einverstanden, dass Images keine Unix-Art sind, Dinge zu tun. Sie eignen sich eher für die Windows-Welt, in der die skriptgesteuerte / automatisierte Installation und Konfiguration nicht so einfach ist.

Sie können Puppet durch ein beliebiges anderes Konfigurationsverwaltungssystem ersetzen, das Ihren Anforderungen entspricht, aber ich mag zufällig die deklarative Natur von Puppet und das Konzept der Konvergenz.

Dieses System bietet eine Reihe von Vorteilen:

• Marionette handhabt alles über eine allgemeine Basisinstallation hinaus, so dass sich alle erforderlichen Pakete und Konfigurationen an einem Ort befinden.
• Die Puppet-Manifeste dienen als zusätzliche Quelle für Dokumentation auf niedriger Ebene.
• Solange Sie bei Puppet bleiben (dh keine lokalen Konfigurationsänderungen vornehmen oder sie wieder in Puppet zusammenführen), ist es trivial, ein Duplikat einer Maschine zu erstellen.
• Da alle Hosts auf einer gemeinsamen Basis aufgebaut sind, können Sie Hardware oder VMs mit dem Basispaket (KickStart) vorinstallieren und sie dann in funktionale Knoten verwandeln, indem Sie nach Bedarf Klassen hinzufügen.
• Puppet ermöglicht das "Markieren" von Hosts für die Produktion oder Entwicklung, sodass es unglaublich einfach ist, eine Entwicklungs- / Testkopie eines Hosts zu erstellen, Pakete zu aktualisieren oder Konfigurationsänderungen nach Bedarf vorzunehmen, zu testen und dann wieder in die Produktion einzubinden.

Wenn Sie die pxe-Route abfahren, sollten Sie unbedingt einen Blick darauf werfen

http://etherboot.org/wiki/index.php

Mit Gpxe erhalten Sie mehr Flexibilität bei den Startzielen. Es ist ganz einfach, ein Aoe Blade zu booten, und es gibt nichts Schöneres, als einen Kernel von einem entfernten http-Server zu booten !!!!!!!!!! :-).

Welche Server-Betriebszeiten benötigen Sie?

Es ist unmöglich, ein perfektes Image zu erstellen, da Sie immer Sicherheitspatches und Software-Upgrades installieren müssen. Wenn sie mit dem Internet verbunden sind, können Sie das Patchen nicht einfach ignorieren.

Auf der PXE-Seite stehen Ihnen je nach Datei-E / A Ihres Clusters einige Optionen zur Verfügung. Booten Sie einfach einen Kernel und mounten Sie die Festplatte remote über aoe oder iscsi.

Sie können auch einige sehr clevere Dinge mit dem Kopieren von Schreibbildern tun. Es ist ideal für Upgrades und das Zurücksetzen von Änderungen, die möglicherweise problematisch sind.

Ich hatte auch Erfolg mit NFS-Root, mit einer Clustered-NFS-Lösung. Sie können verschiedene Dateien angeben, die abhängig von ihren Clientadressen bereitgestellt werden sollen.

Auch hier müssen Sie überprüfen, ob Ihre Anwendung (en) gerne nfs ausführen. Es ist nicht für jede Arbeitsbelastung geeignet.

Der gruppierte NFS-Server kann 192.168.0.1:/etc/hostname 192.168.0.2:/etc/hostname enthalten

Daher verweist jeder Client auf dieselbe Datei, erhält jedoch die Datei, die für den Client relevant ist. Es ist ziemlich beeindruckend, aber es ist nicht einfach!

All dies führt zu schnelleren Rollout-Zeiten, wenn Sie das Dateisystem im Netzwerkspeicher zentralisieren. Das Imaging eines Betriebssystems über ein Netzwerk auf eine Remote-Festplatte nimmt Zeit in Anspruch !!!!

Wenn Sie eine dieser Lösungen verwenden, stellen Sie sicher, dass Sie über eine gut konzipierte und fehlertolerante Netzwerkschicht verfügen und Ihr nfs / SAN-Server gut konzipiert und sicher ist!

Wenn Sie die Verbindung zu Ihrem NFS / SAN verlieren, kann dies die Serverintegrität beeinträchtigen. :-(

Es ist ganz einfach, einige Skripte für tftp / pxe zu erstellen, um den Startvorgang zu steuern.

Wenn ich mehr darüber wüsste, was Sie tatsächlich versuchen, zu gruppieren, könnte ich mir vielleicht eine Lösung vorstellen, die besser zu Ihnen passt.