Re: RAID Spiegelung mit Woody trivial oder schwierig?
Ulrich Mietke wrote:
> Christian Schulte schrieb:
>
>
>>Joerg Rieger wrote:
>>
>>>... es gibt eben nicht DIE Lösung.
>>
>>Ich hatte mich schon dafür interessiert wie Leute, die ein Hardware-RAID
>>betreiben, sich darauf vorbereiten wie zu Verfahren ist, wenn der
>>Controller einen Defekt aufweist.
>>
>
> Im einfachsten Fall genau, so wie man vorgeht wenn ein Controller abraucht
> der kein Raid kann! Neue Hardware einbauen und Datensicherung einspielen.
Ok. Das wäre dann erstmal keine Alternative. Irgendetwas ausschalten
will ich gerade vermeiden, wenn nichts anderes dieselbe Aufgabe
erledigen könnte.
>
>
>>Die Antwort darauf war dann, dass man,
>>wenn man ein sofortiges Weiterarbeiten gewährleisten muss, schon die
>>gesamte Hardware redundant auslegen sollte.
>>
>
> Man kann auch durch organisatorische Mittel ein Weiterarbeiten
> gewährleisten. Dazu müßte aber ein genaues Zenario vorgegeben werden.
> Lösungen, die in anderen Unternehmen eingesetzt werden, sind in den
> wenigsten Fällen auf das eigene Problem übertragbar. Auch wird nicht jeder
> DV-Verantwortliche bereit sein seine Lösung zu publizieren.
Genau da liegt das Problem. Irgendwelche Hochverfügbarkeits-Lösungen
sind meist speziell angepasste Kombinationen aus Hard- und Software.
>
> Und/Oder man legt die Software redundant aus. Wird eine Prozeßkette von
> mehreren Rechnern abgearbeitet, kann man auf jedem Rechner zusätzlich die
> Software installieren, die für die Prozeßschritte vorher oder/und hinterher
> notwendig ist. Fällt dann ein Rechner aus, kann der benachbarte Rechner die
> Aufgabe übernehmen.
Soweit so gut. Damit sprichst Du jetzt nur dummerweise genau die
Alternative an, wofür ich mich einfach nicht entscheiden kann. Redundanz
auf Applikationsebene. Hätte ich also einen Cluster von mehreren
Servern. Dieser Cluster bleibt solange funktionsfähig bis alle Server
gleichzeitig ausfallen. Solange auch nur eine Maschine weiterarbeitet
bleibt die Anwendung verfügbar. Aus Sicht von Skalierbarkeit etc. alles
eigentlich vom Konzept her optimal (auch wenn die Praxis da mit so
Dingen wie dem internen Traffic im Cluster für Überraschungen sorgt).
Nur: Wozu sollte man dann überhaupt noch RAID benutzen ? Breche ich also
die einzelnen Ausfall-Szenarien nicht auf einzelne Komponenten herunter,
sondern sehe eine Maschine einfach als Blackbox die entweder läuft, oder
nicht. Warum eine Maschine jetzt gerade nicht läuft (z.B. defekte
Platte) interessiert dann erstmal nicht mehr. Bringe ich also allen
Applikationen, die ich benötige, auf Applikationsebene Redundanz bei,
dann kann ich mit billigster Hardware einen Cluster aufbauen und mich
interessiert schonmal keinerlei Spezial-Hardware mehr. Ich kann mir hier
sogar noch das entsprechende Personal einsparen. Geht eine Maschine
kaputt, ersetzt man sie gleich komplett. Die defekte Maschine schicke
ich zurück zum Hersteller oder ähnlich. Niemand braucht sich mit RAID,
Kernel-Kompilation und was auch immer auskennen. Der Cluster kann von
einer einzelnen Person gewartet werden (Software-Updates etc.). Ich
behaupte mal, dass jemand, der ein Debian mit einigen Paketen
installieren kann, nicht unbedingt auch einen Kernel kompilieren bzw.
ein SW-RAID administrieren kann. Muss er so aber auch garnicht. Die
Miete für eine halbwegs vernünftige Maschine dürfte so um die 150-300€
monatlich liegen. Für dasselbe Geld kann man jetzt auch gleich 7
Maschinen für 39€ im Monat mieten. Qualitativ ist das dann zwar auch
minderwertige Hardware, aber ich behaupte trotzdem, dass man damit
besser fährt, da auch eine gute Maschine immer ein single point of
failure ist. Hat man also Geld gespart und der ganze Kram ist auch noch
besser gegen Ausfälle abgesichert. Alles ohne RAID! Ich habe zur Zeit
noch die eine gute Maschine, mache mir aber auch massiv Gedanken
darüber, wie man mit billiger Hardware trotzdem besser fahren könnte,
sind die Ersatzteile nämlich immer gleich eine richtige Investition.
Rückschlüsse vom Preis einer Komponente auf die zu erwartende
Lebensdauer sind zumindest nicht möglich. Teuer muss nicht immer auch
gut sein. Das einzige Problem bei Hochverfügbarkeit auf
Applikationsebene ist, dass es so gut wie keine entsprechende (Open
Source) Software gibt. Darüber haben sich aber auch schon andere
Gedanken gemacht und einen generellen Lösungansatz "versucht" (z.B.
<http://www.drbd.org> oder z.B. die J2EE Spezifikation mittels
<http://www.jboss.org>). Diese ganzen allgemeinen Ansätze haben meiner
Meinung nach ein Problem. Sie sind zu allgemein. Um Hochverfügbarkeit
auf Applikationsebene in der entsprechenden Applikation implementiert
kommt man also nicht herum. Muss man also entweder lange warten, oder
die Wunschsoftware gleich selber anpassen. Diese Anpassung kostet dann
nur einmalig Geld bzw. Zeit, kaputtgehen kann ja nichts.
>
> Man sollte auch ein Referenzsystem haben, an dem man Änderungen testen kann
> bevor man sie in den Echtbetrieb übernimmt. Bei einem Ausfall kann dann das
> Referenzsystem die Aufgaben des ausgefallenen Rechners übernehmen.
Im Cluster sind alle Maschinen gleichwertig. Der Cluster selber ist nach
aussen auch wieder nur eine Blackbox. Das Problem den Cluster zu testen
kann man mit virtuellen Maschinen umgehen. Für eine Testinstallation
reicht dann ein Notebook mit z.B. 5 VMs, die je nur 32MB RAM benötigen
etc. Vor z.B. einem Softwareupdate im produktiven Cluster kann man damit
bereits alles durchtesten.
>
>
>>Das Argument mit dem zerschossenen Boot-Bereich ist ebenfalls gut.
>>Nur das mir hier der Unterschied, warum Hardware-RAID hier Vorteile
>>haben soll, nicht klar wird.
>>
>
> HW-Raid einstecken und fertig.
Maschine tauschen und fertig. Egal was für eine Maschine. Kann eine
andere CPU drinstecken, kann S-ATA gegen IDE wechseln, kann Linux auf
x86 gegen Solaris auf Sparc tauschen etc. Kein Zeitdruck. Völlige
Hardware-Unabhängigkeit. Einfach nur einen neuen RAID-Controller
einbauen kann zu üblen Überraschungen führen, wenn der 5 Jahre jüngere
Controller dann das 5 Jahre alte RAID nicht mag. Hier jetzt einfach
immer gleich zwei Controller kaufen löst das Problem nicht. Baut man den
zweiten Controller ein, hat man beim nächsten Ausfall dasselbe Problem.
Hier kann ich zwar berichten, dass ein Kollege mit seinem OnBoard-RAID
unter Windows beim Tausch des Mainboards tatsächlich das Glück hatte,
dass das neue Board einen kompatiblen Controller mitbrachte, aber diese
OnBoard-Sache ist eh aussen vor. Wenn ich mir einen
Hardware-RAID-Controller zulege, dann ja nicht mit dem Hintergedanken,
dass der eh nur ein paar Monate halten wird und es dann auch noch
entsprechende "Ersatzteile" gibt. Das ist ja gerade das Problem. Das
Ding soll ewig halten und wenn es dann nach vielen Jahren den Geist
aufgibt, dann habe ich vom RAID nichts gehabt, wenn ich trotzdem die
Datensicherung bemühen muss. Dann könnte ich auch gleich auf das RAID
verzichten und jedesmal bei einer defekten Platte ein Backup einspielen.
> SW-Raid muß auf jeden OS das auf dem Rechner läuft installiert werden, und
> bei jedem Release/OSwechsel.
> Und in dem Fall, in dem man die Boot-Platte nicht auswählen kann, hat man
> ein Problem wenn vor der Initialisierung des SW-Raid ein Fehler auftritt.
> Der Briefkastenschlüssel ist kaputt und der Ersatzschlüssel ist im
> Briefkasten.
>
> Gruß Uli
>
>
Also ist die Redundanz auf Applikationsebene eigentlich der
Generalschlüssel. Bin zumindest mitlerweile bei Software-RAID angelangt
und habe meinen Hardware-RAID Controller verbannt. Bereut habe ich das
bisher nicht. Die wirklichen Probleme löst das Software-RAID aber auch
nicht. Was bringt mir RAID, wenn die CPU aufgibt ? Also muss ein Cluster
her und keine Spezial-Hardware.
Es geht in diesem Thread ja nur um einen Server und eine Platte, die dem
Besitzer zu unsicher ist. Hier kann ich aus Erfahrung sagen, dass ich in
derselben Situation zuerst einen Hardware-RAID-Controller für viel Geld
gekauft hatte und mitlerweile aber bei Software-RAID gelandet bin, da
mir die Kosten für einen neuen Controller im Falle eines Falles einfach
zu hoch waren. Zusätzlich liegt im Server noch eine völlig langsame IDE
Platte auf die ein daily Backup geht und dann noch zusätzlich läuft über
rsync ein daily Backup auf meine Maschine zu Hause. Alles das ändert
nichts daran, dass mir das ganze nach wie vor zu unsicher ist und ich
mir Gedanken über Clustering mache...
Aber die Frage ist doch schon interessant. Vernünftige Software, die die
schwächen der Hardware ausbügeln kann, oder vernünftige Hardware, die
die Schwächen der Software ausbügeln kann. Ideal wäre natürlich
vernünftige Hard- und Software. Open Source kostet aber nix und die
vernünftige Hardware gleich ein Vermögen. Zusätzlich ist auch die
teuerste Hardware kein Garant für einen reibungslosen Betrieb, wenn die
Applikation, die auf dieser Hardware läuft, einfach ihre Daten nicht
sauber wegspeichert.
Da der Original-Autor von einem Server redet, in dem bisher nur eine
Platte lief, kann man davon ausgehen, dass einfach nicht genug
finanzielle Mittel vorhanden sind, um alles in trockene Tücher zu
bekommen. Ein RAID ersetzt auch nicht die Datensicherung. Das sicherste
ist wohl nach wie vor noch der Tresor mit den Backup-Bändern. Also an
Stelle von in eine RAID-Lösung zu investieren, wäre es wohl am
sinnvollsten einen geeigneten Streamer zu kaufen und vernünftige Backups
zu machen.
--
Christian Schulte
Reply to: