AW: AW: Plattenspiegelung?

-----Ursprüngliche Nachricht-----
Von: Greg Lehey [SMTP:grog(at)lemis.com]
Gesendet am: Dienstag, 30. März 1999 00:54
An: Samer, Michael, IN
Cc: de-bsd-questions(at)DE.FreeBSD.ORG
Betreff: Re: AW: Plattenspiegelung?

On Monday, 29 March 1999 at 11:41:41 +0200, Samer, Michael, IN wrote:
> Michael Samer, DV-Support Bertrandt GmbH IN
>
>> Wenn Du richtige RAID-Controller meinst, unterstützt FreeBSD keinen
>> davon, sondern nur DPT. Ob man dabei eine Performanceverbesserung
>> gegenüber Vinum bekommt, ist mindestens fraglich (siehe ebenfalls
>> meine Zahlen von heute (sehr) früh. Wir wissen nicht, warum das
>> Schreibverhalten des DPTs in diesem Beispiel so schlecht war.
>
> (ich habe mir erlaubt den ersten Teil zu schnipsseln...)

Ich habe mir erlaubt, Deine Antwort umzusiedeln... :-)

> Der CMD bzw. AHA 13xy ist ein Plattformunabhängiger RAID Kontroller auf HW
> Basis, sprich LUN's werden zu ID's vernetzt und verwaltet.

Also eben nicht das, was ich einen richtigen RAID-Controller meine.

> Adaptec blendet sich als BIOS überblender in einen anderen Adaptec
> ein (so über Bus handshaking, und INT13 Masquering), CMD macht alles
> extern; einfach einstecken über integr. Display RAID
> konfigurieren-fertig!)

Und wie erscheinen diese Karten dem System?
MS: Wie der SCSI Hostadapter eben. Für den Hostadapter erscheint der Viper
wie eine ID, welche LUN's (jeweils ein RAID Bündel) in sich hat. Er
beherrscht JBOD, RAID 0,1,4,5 und kann ein halbes GB Cache aufnehmen (ein
paar Mails vorher habe ich von dem Nachfolger Viper2 gelesen, welcher in FRG
von addit vertrieben wird). Der Adaptec blendet sich in das BIOS des Adaptec
Controllers ein und fungiert direkt über diesen. Ich persönlich finde es
sehr praktisch keine Zusatzsoftware zu benötigen und beide Kontroller sind
über serielles Telnet (oder der Nachfolger über IP) anzusprechen und
konfigurieren. Der Megavorteil von echtem RAID ist eben die RAID Redundanz:
eine HD hinüber (inkl. Bootplatte -partition) er erkennt es und wechselt
selbstständig um.
  
> Ich selbst habe einen "großen" Viper 5500 laufen und es ist genial
> wie simpel RAID sein kann und wie unabhängig vom OS, hauptsache
> Kontroller wird unterstützt... Der dd ist simpel und funktioniert
> eben simpel ohne sync. Viunum ist ein externes Programm

Vinum ist ein Treiber wie jeder andere. Na gut, nicht wie jeder
andere, aber mindestens Teil des Kerns.

> und ich bevorzuge doch Lösungen, welche gerade davon unabhängig sind
> (ähnlich dem vi, welcher überall läuft, von komfortabilität
> höchstens mal die Schreibweise kennt und trotzdem funktioniert es
> eben ab frühestem level und installationsgrad). Klar es gibt
> funktionablere Lösungen..... (gerade hierfür gut geeignet, wegen der
> sync Funktion).

Na, wenn Du auf alles verzichtest, was das System verbessert, ist das
natürlich Dein Recht.
MS: Recht hin, recht her, dd erfüllt die Anfrage einer Datenreplizierung auf
zweite HD, was er nicht kann ist background oder realtimerepl. wie es vinum
anbietet oder eben eine Art SoftRAID. War aber auch nicht die Frage...
> Wie Du schon heute morgen gepostet hast ist der DPT etwas langsam
> als RAID (vor der i960 Serie!).

Was ich gestern gepostet habe war ein Einzelergebnis. Ich weiß nicht,
ob es typisch ist. Mich hat's jedenfalls überrascht.

Es ist leider sehr typisch für die älteren DPT oder ICP. Mylex ist relativ
früh auf Intel umgestiegen und ihren HochleistungsRISC namens i960. Bei
gerade mal 33MHz kann er meinen 80MHz MIPS3000 (uC meines Vipers) alt
aussehen lassen. (eines der wenigen Produkte, welche intel wirklich bekannt
machen hätten können ;-} )
> Der eingebaute ASIC ist gerademal ein viertel so performant wie der
> nun eingesetzte i960.

Hat der sonst keine CPU?

siehe oben
> Der DPT unterscheidet sich in dem Feld auch nicht von der ICP Vortex
> Serie(vor i960!). Läuft aber genau wie DPT unter FBSD, da der selbe
> Controller drauf sitzt (und genauso unperformant unter RAID
> 4/5). Wenn du mal RAID 4 (fixed parity) ausprobierst

Ich sehe keinen Grund dafür. Die einzige Begründung für eine
RAID-4-Implementierung ist um eine Strichliste voll zu bekommen.
MS: Die Begründung RAID 4 liegt in seinem enormen Rechenbedarf um die
Leistungsfähigkeit von RAID Controllern/Software zu testen... Ansonsten ist
RAID 5 durch die Bank besser als 4.

> kriegt du bei I/O schwachen Mainboards (alte P60 als Beispiel) und
> schnellen HD's schnell mit, daß nicht mehr viel übrig bleibt. Bei
> langsamen HD's ist klar, daß die CPU schnell genug dafür ist (so
> P100 mit HX Chipsatz).

Gut, meine Platten sind nicht die schnellsten, aber mit RAID-5 reichen
sie im Lesebetrieb gerade für 4,5% einer P54/133:
MS: Hier geht es ja gerade um den Vorteil von schneller CPU zu langsamen
HD's. Vergleiche mal vor gut sechs Jahren gab es Kompressionssoftware für
DOS REchner. Hattest du einen langsamen Transfer zur Platte oder ein
langsame HD selbst, aber eine schnelle CPU , wurde durch die Kompression
(RAID schluckt auch CPU Zeit) der "scheinbare" Zugriff und Transfer
beschleunigt. Und das obwohl Kompressionsalgorhythmen viel Power schlucken.

            -------Sequential Output-------- ---Sequential Input--
--Random--
            -Per Char- --Block--- -Rewrite-- -Per Char- --Block---
--Seeks---
        MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU
DPT 256 541 7.5 491 1.7 458 2.3 4293 59.1 4335 16.2 193.6 6.8
Vinum 100 379 14.9 385 8.9 360 4.5 1122 24.7 1258 7.4 80.9 6.7

Das ist nicht viel anders als die Belastung beim Lesen. Fazit: es
macht fast gar nichts aus.
MS: RAID ist durch die Reihe gut (ich benutze es selbst auf HW Basis), darum
geht es auch nicht. Viele Platten, sind wie Teamwork: Zusammengeschalten
gut, alleine naja Einzelkämpfer...
Um zum Thema zurückzukommen RAID 5 ist doch für die Fragestellung
Plattenspiegelung uninteressant (aus Sicherheits oder Performancegründen
dann ja schon), denn sie sind ja nicht einzeln lauffähig, sondern nur im
RAID 5 Cluster.

Greg

--
See complete headers for address, home page and phone numbers
finger grog(at)lemis.com for PGP public key
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message