Re: Webserver von 0 auf 100]

From: Oliver Fromme <olli(at)secnetix.de>
Date: Fri, 21 Feb 2003 22:31:55 +0100 (CET)

Robert Barten <robert(at)barok.de> wrote:
> On Thu, Feb 20, 2003 at 08:52:31PM +0100, Andreas Braukmann wrote:
> Wir hängen reduntanterweise an zwei Switches.

Ihr habt bei Eurem Hoster zwei Switchports gemietet, aber
keinen Remote-Console-Zugang? Da ¶aßt etwas nicht ganz
zusammen, würde ich sagen ...

Übrigens wette ich, daß die beiden tollen »redundanten«
Switche hinten wieder zusammengeführt auf einem größeren
Switch oder Router auflaufen. Wenn da irgendwo etwas aus-
fällt, wird es vermutlich nicht gerade einer der kleinen
Switche sein, d.h. es sind dann vermutlich beide Links ab-
geschnitten.

Darüberhinaus müßt Ihr auch die Default-Route auf eines
der beiden Interfaces setzen. Man könnte natürlich ein
Skript bauen, das regelmäßig den Link prüft und im Fehler-
falle ein Fail-over macht (muß man aber ziemlich aufßpas-
sen; man kann sich dabei hervorragend in den Fuß schießen).

> Ist Onboard-LAN überhaupt etwas für den Serverbetrieb?

Aber sicher, das spart Slots und somit Bauhöhe (und somit
Geld).

> Bei Defekt kann
> man nur hoffen, dass sich der Adapter noch deaktivieren lässt,

Server, wie Du sie hast, werden normalerweise eher nicht
privat eingesetzt, sondern kommerziell, und dann hat man
einen Servicevertrag, der dafür sorgt, daß im Falle eines
Defekts das Teil innerhalb von 24 (oder 4) Stunden ersetzt
wird.

> und gibt
> es auch aktive?

Diese Frage habe ich nicht verstanden.

> Mach' einen neuen Thread auf mit dem Titel: Optimaler Server.

Den »optimalen« Server gibt es nat[rlich nicht. Aber man
kann schon Hardware zusammenstellen, die der geplanten
Anwendung halbwegs angemessen und ökonomisch ist.

Aber ich denke, dieses Thema können wir jetzt erstmal zu
den Akten legen. Das führt uns jetzt ja doch nicht mehr
weiter.

> @boards = qw(SMP1 SMP2 SMP3 SMP4 SMP5);
> printf "Ich kaufe %s", $boards[int(rand(@boards))];
> # ab Perl 5.004, geht aber auch mit Eneenemopelwerfrisstpopel :)

Das geht auch mit FreeBSD-Bordmitteln, ganz ohne perl. ;-)

jot -r -w SMP 1 1 5

(SCNR ...)

> [RAID-1/0]
> Jemand hat hier (sicherlich nicht ganz ernst
> gemeint) vorgeschlagen, einen zusätzlichen SCSI-Controller + eigene
> Platte für Swap einzubauen. Nun habe ich hier tatsächlich eine 4GB IBM
> nebst Controller liegen. Ist es sinnvoll, die einzubauen (ist schon
> etwas älter, durchschnittliche Haltbarkeit jedoch noch ein paar Hundert
> Jahre)?

Für den Swap? Nein, denn damit würdest Du denn Sinn des
Mirroring (RAID-1) ad absurdum führen. Sinn von RAID-1
ist Redundanz zum Zwecke der Hochverfügbarkeit. Das heißt,
daß im Falle eines Ausfalls nicht erst jemand hinfahren,
die Platte wechseln und das Backup zurückspielen muß, son-
der die Kiste läuft einfach weiter.

Wenn Du nun den Swap nicht in den Mirror mit einbeziehst,
und die Platte stirbt, dann stirbt Dir auch die ganze Ma-
schine. Das ganze RAID-Gelumpe nützt Dir dann gar nichts.
Daher solltest Du auch den Swap unbedingt mit auf ein
RAID-Volume mit drauftun. Bei den von Dir genannten Plat-
tengrößen ist das ja locker drin.

Apropos -- Womit macht Ihr Backup? Ein RAID ist _kein_
Ersatz für ein Backup. Dieser Fehler wird leider häufig
gemacht, und dann gibt es irgendwann ein ganz böses Er-
wachen ...

> Außer Paritätscheck ohne ExtraLW gibt es doch keinen Unterschied zu
> Level 10?

Der entscheidende Unterschied ist die Nutzkapazität. Bei
RAID-1 (den RAID-0 Teil lassen wir mal außen vor) vergibst
Du für die Redundanz genau 50% der Kapazität. Bei RAID-5
mit 4 Platten dagegen vergibst Du nur 25% der Kapazität für
die Paritätsdaten. In beiden Fällen kann Dir eine belie-
bige Platten ausfallen, ohne daß etwas passiert. (Bei
RAID-1 dürfen sogar zwei Platten ausfallen, sofern es nicht
die gleichen Spiegelteile sind.)

Wenn Du einen RAID-Controller hast, der das ganze in Hard-
ware macht (und noch dazu ordentlich viel eigenen Cache
hat), dann dürfte es von der Performance her keinen allzu
großen Unterschied machen. Sofern die Hardware vernünftig
ist, natürlich (das Adaptec-Teil nicht, das Ihr habt, kenne
ich nicht, daher kann ich das nicht beurteilen; mit diver-
sen anderen Hardware-RAID-Controllern habe ich aber sehr
gute Erfahrungen gemacht, z.B. Compaq-CISS/SmartRAID5*).

> SOWAS ist absolut hilfreich! Für /var/spool/mail also kein eigene(r|s)
> Slice nötig?

Du meinst Partition (oder Filesystem). Slices sind etwas
anderes.

Es gibt viele Gründe, Daten auf getrennte oder eigene Da-
teisysteme zu tun, z.B. Backup, Quotas, NFS, Datensicher-
heit, viele oder wenige (oder gar keine) Schreibzugriffe,
Verschnitt, etc.pp.

Grundsätzlich sollte man Dateisysteme voneinander trennen,
in denen viel oder wenig geschrieben wird. Darum sollten
/var, /tmp und /home getrennt sein (/tmp wird sowieso häu-
fig als MFS bzw. swap-backed MD-disk angelegt).

Desweiteren sollte man solche Daten in ein eigenes Datei-
system tun, die dazu neigen, unbegrenzt zu wachsen, ganz
besonders dann, wenn man von außen darauf Einfluß nehmen
kann. Daher würde ich /var/spool/mail auf einem Mailserver
separat machen, evtl. auch /var/mail (oder wo auch immer
die Mailfolder/Maildirs der Benutzer liegen).

Falls Ihr NFS-Exports habt: Die Export-Parameter sind im-
mer für ein ganzes Filesystem wirksam, daher sollte man
auch dies bei der Aufteilung berücksichtigen. Das gleiche
gilt für Quotas.

Falls Ihr mit dump Backups machen wollt: dump arbeitet im-
mer auf ganzen Filesystemen. Auch diese Tatsache mag einen
Einfluß auf die Aufteilung haben.

Nachteil bei einer feinen Aufteilung ist natürlich, daß man
einen großen Verschnitt hat, und daß möglicherweise eine
Menge Plattenplatz brachliegt. Das kann vor allem dann
passieren, wenn man ein neues System aufsetzt, ohne daß man
bereits Erfahrungswerte für den konkreten Nutzungsfall hat.

Ich persönlich bin inzwischen teilweise dazu übergegangen,
für /usr keine eigene Partition mehr zu nehmen, sondern es
ins root-Filesystem mit hineinzunehmen. Für mich gibt es
strukturell keinen großen Unterschied mehr zwischen Dingen,
die in /bin und in /usr/bin liegen. Man könnte sogar
/usr/local dort mit hineinnehmen, sofern man nicht allzu
oft neue Software installiert bzw. schon im voraus weiß,
was man ungefähr brauchen wird. Ansonsten /usr/local ge-
trennt machen. /home, /var und /tmp sollten auf einem Ser-
ver definitiv getrennt sein. /tmp kann ein MFS sein (siehe
oben), oder auch ein Link nach /var/tmp. Eine separate
Partition (mit Soft-updates) ist auch OK. Aber in das
root-Filesystem gehört es definitiv nicht.

Gruß
   Olli

-- 
Oliver Fromme, secnetix GmbH & Co KG, Oettingenstr. 2, 80538 München
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.
"All that we see or seem is just a dream within a dream" (E. A. Poe)
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Fri 21 Feb 2003 - 22:31:59 CET

search this site