[Technik] wieder mal HW-Planung

[Michael Hoennig]

Hallo Paul,

> Ich habe im September schonmal was zum Thema "zentrale Dienste"
> geschrieben, auf das es damals leider keine Reaktion gab:
> http://lists.hostsharing.net/archiv/technik/2006-September/036528.html
> Zu dem Vorschlag stehe ich abgesehen von einer kleinen Änderung nach
> wie vor. Vielleicht lassen sich dein und mein Vorschlag ja irgendwie
> verbinden.

dazu weiter unten hinter der --- cut --- Linie, da ich dafür erstmal ein
paar andere Dinge erläutern muss.

> > - pima (2 Intel PIII 1200 MHz, 3 GB RAM, 90 GB SCSI + 120 GB IDE)
> > - pomo (2 Intel PIII 1200 MHz, 2 GB RAM, 90 GB SCSI + 120 GB IDE
> 
> Korrektur: pima und pomo: je 2 * 73 GB SCSI + 36 GB SCSI + 120 GB IDE

Das steht auf der Website für Pima+Pomo ziemlich mehrdeutig, wie ich
finde.  Bei den anderen ist es klar.

> > *** Und folgende Aufgaben geplant:
> >
> > - Prio 1: Testhive für hsadmin (braucht 1 Host, später 2)
> > - Prio 2: DRBD Tests (baucht 2 identische Hosts)
> > - Prio 3: Mail-in - braucht 2 Hosts (Produktiv+Standby)
> 
> Du meinst Mail-Out, oder?

Geplant war ja mal, beides auszulagern. Mail-in, um die Spam- und Viren-
Scannerei von den Webservern wegzubekommen.

> > - Prio 3: hsh auslagern (-> h00 oder sowas)
> 
> Bei hsh## sehe ich keine wirkliche Notwendigkeit, wichtiger sind IMO
> hsdb (abgekoppelt von den hsh##-Paketen), DNS 1, Newsserver, NTP,
> Syslog und ein Build-Environment (für Xen, DRBD etc.).

Klar, die hsh* Pakete müssen nicht notwendigerweise ausgelagert werden,
hat aber auch Vorteile:

- bei Änderungen: ein erster Test in echter Produktivumgebung, 
	ohne direkt die Kundensites zu beeinträchtigen
- bessere Verfügbarkeit zentraler Funktionen wie Webmail, php..admin etc.
	(insbesondere auch bei Umzügen, da h01 immer alleine für den 
	offline rsync ewig braucht und zentrale Dienste solange FÜR ALLE
	tot sind)
- der vorherige Punkt wird nach Einführung von hsadmin noch kritischer!
- mehr Plattenplatz und Performance in h01 für Kundensites

> > Können wir h00 so nennen, oder gibt das mit den 73##er Ports für die
> > stunnel Probleme?
> 
> Brauchen wir denn überhaupt noch einen Hive h00?

Ich befüchte, dass es eine Menge Arbeit ist, wenn wir hsdb etc. nicht in
einem Hive laufen lassen. Z.B. müssen wir sämtliche Backup-Skripte dann
Hive-unabhängig ausführen. Was wir nicht haben, ist Geld, und was wir gar
nicht haben, ist Manpower :-(

> > Brauchen wir nicht eigentlich eh stunnel nur nach h00 (also jetzt
> > nach h01) statt von überall nach überall? Irgendwie kommt mir das
> > seltsam vor, so wie es jetzt ist.
> 
> Das kommt darauf an, wofür wir die stunnel nutzen wollen.

Wofür werden sie denn überhaupt genutzt, außer für phpmyadmin? 

> Laut deiner Auflistung oben braucht ihr für hsadmin-Tests "später 2"
> Hosts (wofür?). Welchen Server willst du dann dazunehmen?

Vermutlich brauchen wir eigentlich nur 2 Hives (weil hsadmin ja
eigentlich ein verteiltes System ist), und nicht wirklich zwei hosts. Der
eine Host müsste nur genug RAM haben, um in beiden problemlos
Tomcat-Anwendungen laufen zu lassen.

> > 2. crow (Produktiv) + cree (Standby) als Mailserver
> > 	reicht die Leistung? Oder lieber erstmal auf Pima+Pomo?
> >
> > 3. Pima (Produktiv) + Pomo (Standby) mit Xen Umgebung ausstatten,
> > 	dann zentrale Dienste und hsh* Pakete umziehen
> 
> Ich würde die hsh##-Pakete in den Hives lassen, in denen sie jetzt
> sind, die o.g. zentralen Dienste und Mail-Out in mehrere Xen-domUs auf
> pima/pomo packen 

Das ginge sicherlich problemlos. Der Nachteil meiner Lösung (hsh* mit
zentralen Dienste nach h00 umziehen) wäre wohl, dass Mail-in da dann
nicht auch noch rein könnte, weil das bei Spam-Attacken zu sehr bremsen
würde und uns wohlmöglich hsdb lahmlegt - das gilt aber wohl auch für
Mail-out, wenn wir es durch einen Spamfilter laufen lassen wollen.

Aus den in der o.g. Aufzählungsliste genannten Punkten, favorisiere ich
aber immer noch meine Variante, da hsdb eine zentrale Web-Anwendung mit
Tomcat benötigt, die ich ungerne außerhalb eines Hives betreiben würde.

> Vielleicht auch nur cree außer Betrieb nehmen und crow später als
> zweiten hsadmin-Testserver, sofern der dazu geeignet ist.

cree könnten wir auch für Testzwecke (mit Hinweis auf die abenteuerliche
Konstruktion) meistbietend als Root-Server versteigern ;-)

crow ist mit 1 GB RAM ja relativ gut ausgestattet und reicht evlt. sogar
für 2 Hives mit hsadmin Tests - evtl. weiss Peter Hormanns dazu mehr, was
den Speicherbedarf betrifft.

--- cut --- cut --- cut --- cut --- cut --- cut --- cut --- cut --- 

Also neuer Vorschlag für virtuelle Server mit zugeordneten Hosts:

hsh00/Pima (Pomo als Standby):
	- hsh00 (Member-Accounts)
	- hsh01 (Funktions-Accounts, Option auf httpd.conf und WebDAV)
	- hsh04 (www.hostsharing.net)
	- hsh0# (www.web-panel.net: hsadmin Web-Anwendung)
	- evtl. später weitere hsh## Pakete
	- mailman	
	- hsdb (zumindest ERSTMAL in hsh00_hsdb1 belassen)

services/Pima (Pomo als Standby)
	(zentrale Dienste ohne besondere Anforderungen)
	- DNS 1
	- Newsserver inklusive Mail->News-Gateway
	- DNS-Resolver für die anderen Server
	- NTP-Server für die anderen Server
	- später evtl.: hsdb
	(ACHTUNG: Backups müssen dann Hive-unabhängig organisiert werden!)

(otional später) syslog/?:
	(besondere Sicherheitsanforderungen, derzeit auf Acoma|Yuki)
	- Syslog-Server für die anderen Server
	- logcheck für das zentrale Syslog

	Das remote Syslog dient u.a. dazu, es eventuellen Angreifern zu
	erschweren, ihre Spuren aus den Logfiles zu entfernen. Daher
	sollte es selbst auf einem dedizierten (virtuellen) Server
	betrieben werden.

(otional später) Mail:
	(wobei ich dazu tendiere, dies mit in services zu nehmen)
	- SMTP-In-Relay mit Spam+Viren-Filter
	- SMTP-Out-Relay für die Hives

build/Pima (Pomo als Standby):
	- Build-chroots für Xen, DRBD und co.

	Kann meistens heruntergefahren sein, wird nur selten benötigt.

Evlt. macht es Sinn, erstmal die ersten beiden in h00 umzuziehen und erst
danach die services abzusplitten. Kritierium ist, ob das evlt. dann zwei
kleinere Schritte als ein Monster-Umbau wäre, den wir gar nicht auf
einmal wuppen können. Evlt. ist es aber auch gar nicht mehr Arbeit, das
gleichzeitig zu machen.

Desweiteren:

1. yuma mit Xen Umgebung ausstatten
2. h04 von cusa nach yuma umziehen
3. h90 (für hsadmin) in cusa einrichten (nur 1/3 vom Platz verwenden!)

Es wäre genial, wenn das bis zum 10.11. passiert sein könnte, damit wir
auf dem hsadmin-Treffen vom 10.11.-12.11.  in h90 hsadmin installieren
können. Ggf. erstmal h90 (Platz nach obiger Liste kalkuliert) in yuma
einrichten, wenn's nicht anders zu schaffen ist.

Alles Gute wünscht
	Michael


-- 
Hostsharing eG | c/o Stilflut | Friedensallee 120 | D-22763 Hamburg
phone+fax: +49 700 HOSTSHARING (= +49 700 46787427)
Homepage: http://www.hostsharing.net
Networking: http://www.openbc.com/go/invuid/Michael_Hoennig