[Technik] wieder mal HW-Planung
Paul Hink
email at p-hink.de
Tue Oct 31 12:12:34 CET 2006
Michael Hoennig <michael at hostsharing.net> wrote:
>> > - 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.
Auf der Website habe ich das jetzt gar nicht nachgesehen.
| pima:~# fdisk -l /dev/hda /dev/sd[abc] | egrep '^Disk '
| Disk /dev/hda: 120.0 GB, 120034123776 bytes
| Disk /dev/sda: 36.9 GB, 36954402304 bytes
| Disk /dev/sdb: 73.5 GB, 73557090304 bytes
| Disk /dev/sdc: 73.5 GB, 73557090304 bytes
| pima:~#
>> > *** 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.
Das setzt aber voraus, dass die User Zugriff auf ihre
Scanner-Konfigurationen auf dem zentralen Server haben, bedeutet also
relativ viel Aufwand für uns. Die neue Hardware für die Hives verpackt
die Last IMO ganz gut, so dass dieser Aufwand mir nicht gerechtfertigt
erscheint.
>> > - 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
okay
> - 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)
sollte mit DRBD obsolet sein
> - der vorherige Punkt wird nach Einführung von hsadmin noch kritischer!
Warum?
> - mehr Plattenplatz und Performance in h01 für Kundensites
In meiner schon erwähnten Mail von September habe ich beschrieben,
warum das IMO nicht die Nachteile aufwiegt.
>> > 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.
Moment mal. Die anderen zentralen Dienste _müssen_ wir außerhalb eines
08/15-Hives laufen lassen, einfach weil man sie nicht gescheit in einem
Hostsharing-Paket betreiben kann. Als da wären: SMTP-Out, Syslog, DNS
1, inn, DNS-Resolver (so wir einen eigenen wollen) und NTP-Server für
die anderen Hosts. Einzig hsdb ließe sich in einem Hostsharing-Paket
betreiben, weil es einfach eine PostgreSQL-Datenbank ist. Das eine
pg_dump-Kommando mehr sollte uns nicht in den Ruin treiben.
> [...]
>> > 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?
Eventuell von Kundenanwendungen. Und sie stören ja auch nicht, oder?
> [...]
>> 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.
Wenn wir im Normalbetrieb (d.h. pima und pomo benutzbar) der
Mail-Out-domU einen physischen Server alleine geben, beschränkt sich
das Lastprobleme auf Failover-Situationen, in denen wir ohnehin mit
weniger Performance werden leben müssen.
> 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.
Bist du jetzt schon bei hsadmin oder noch bei der hsdb, wie wir sie
heute haben? Wofür brauchst du da einen Tomcat?
> --- cut --- cut --- cut --- cut --- cut --- cut --- cut --- cut ---
>
> Also neuer Vorschlag für virtuelle Server mit zugeordneten Hosts:
> [...]
Auf den Rest deiner E-Mail kann ich leider aus Zeitmangel erst heute
abend oder morgen eingehen. Sorry.
Paul
More information about the Technik
mailing list