[linux-l] Virtualisierung

[Steffen Dettmer]

* Peter Ross wrote on Fri, May 19, 2006 at 11:01 +1000:
> On Thu, 18 May 2006, Steffen Dettmer wrote:
> 
> >> Bei "vernuenftigen" Datenbanken gibt es Kommandos, die sie zwar
> >> weiterarbeiten lassen, im Hauptspeicher, aber waehrend eines Syncs 
> >> nicht auf die Platte schreiben.
> 
> Oracle kann's.

CooL. Aber auch gefährlich, oder werden Transaktionen dann offen
gehalten (für clients sichtbar)?

> So uebel ist MS SQL meines Erachtens nicht. Sie laeuft nur auf einer 
> Plattform, mit der ich mich nicht anfreunden kann..

Na, vielleicht Geschmackssache... Ich kenn das auch nicht wirklich, nur
ein paar Probleme damit gehabt, kann natürlich Zufall sein, dass ich
gerade die schlechten Stellen getroffen hab.

> Ich bin nicht der DBA, so dass ich das Ganze nicht im Detail kenne, kann 
> aber sagen, angesichts der Last unserer Applikation, die vorallem die DB 
> haemmert, ist die recht gutmuetig. Wesentlich gutmuetiger als MySQL und 
> Postgres im Jahre 2003. 

Was heisst das? MS ist schneller als die anderen beiden?

> > Man will ja geradae nicht frisch installieren, oder? Ich hab jedenfalls
> > früher öfter man SuSE-Linux router mit rsync geclont, sparte einfach
> > viel Zeit und Du brauchst die CD nur zum booten, nicht zum Wechseln.
> 
> Ja. Das kopiert das Rootkit gleich mit;-)

Jo, spart viel Installationszeit, sag ich doch :)

> > Man kann prima /auf/ ein laufendes System rsyncen - schnelles
> > Systemupdate kann man so machen. Aber das sind advanced-topics :)
> 
> Ja. Aber ohne Reboot sollte man sich nicht wundern, dass es ein bisschen 
> hakt. Ein paar alte Libs habe ich noch im Hauptspeicher, jetzt muss ich 
> noch eine neue nehmen, von der Platte, die neue Version also.. autsch!

Na, ohne reboot kann man ja kein binary mehr starten, nur noch die schon
offene sash zum reboot nehmen :)

> BTW: Es ist hier gerade letzte Woche passiert, dass jemand ein rsync 
> eingesetzt hat, um das /etc eines Red Hat-Rechners zu klonen. Inklusive 
> /etc/sysconfig/network-scripts/ifcfg-eth0.. rat mal, was das naechste 
> Reboot aussah?

ja, so ist das. auch SSH Keys sollte man dann neumachen und so weiter.
Das schöne ist, dass man eine Sache mindestens vergisst :)

> Ich halte davon nicht viel, lieber dokumentiere ich, was ich in einem
> /etc nach einer Installation veraendere (und mache daraus Skripts, die
> auf neue Rechner losgelassen werden).
> 
> Erstens _weiss_ ich dann, was ein Rechner tut, zweitens ueberlebt es auch 
> wesentlich besser neue Releases oder gar OS-Wechsel (abseits Windows;-)

Wenn diese Doku in einem TWiki ist (und nicht nur inline in den
Configfiles), find ich das Klasse. Dann weiss man auch, was so ne
Maschine eigentlich gemacht hat, wenn sie ausfällt (ist schon peinlich,
wenn z.B. ein Kunde gar nicht so genau weiss, was dieser und jener
Server eigentlich /genau/ gemacht haben, hatte ich schon öfter sowas
:)).

> Man muss zum Installieren ja nicht CDs wechseln, es gibt ja Bootserver..

Ja klar. Man kann sich dann RPMs bauen bzw. diese anpassen und sicher
automatisch installieren lassen und so. Viel sauberer, da gebe ich Dir
Recht (dauert aber einen Tick länger ;)).

oki,

Steffen

-- 
Dieses Schreiben wurde maschinell erstellt,
es trägt daher weder Unterschrift noch Siegel.