Drobo und ...?
Patrick M. Hausen
Hallo, zusammen,
vorgestern ist meine Time Capsule verstorben. Thomas, kauf Dir keine.
Ich mu� morgen im B�ro mal gucken, ob ich noch in der Gew�hrleistungs-
Frist liege, aber generell sind die Tage des Teils bei mir gez�hlt.
Nun lassen wir den finanziellen Aspekt mal ganz beiseite, ich lieb�ugele
mit einem Drobo. Die M�glichkeit, 16 TB virtuell anzulegen und dann
einfach Platten nachzuschieben ist schon ziemlich cool. Die Gr��e
scheint auch gerade noch so im heimkompatiblen Rahmen zu liegen.
Wie schlie�e ich das Teil nun an? Ich habe:
- ein MacBook Pro, meine Haupt-Arbeitsmaschine
- einen iMac, die private Kiste, die meine Frau und ich nutzen;
private Korrespondenz, iTunes, iPhoto, ...
- ein Netbook (Dell Mini 9) mit Snow Leopard drauf f�r den Urlaub
- Netzwerk in der ganzen Wohnung
- geplant: irgendwann mal was im Wohnzimmer an der Glotze;
Apple TV 2.0 so es kommt, Mac Mini, keine Ahnung und dringend ist
das nun wirklich nicht
Die Alternativen, die ich sehe:
- Drobo am vorhandenen iMac
- gro�e Kiste auf/neben dem Schreibtisch
? ist das Teil wirklich *leise*?
? wie stelle ich die Kapazit�t dem Rest der Maschinen f�r TM
zur Verf�gung?
- Drobo im Schrank beim restlichen zentralen Geraffel mit Droboshare
+ L�sung aus einem Gu�
+ Kiste ist da wo sie hingeh�rt
- USB
- nur SMB
- TM daher nur mit Hacks
- Drobo am zu beschaffenden Mac Mini ebenfalls im Schrank
+ Anschlu� per Firewire
+ AFP und TM
? brauche ich sinnvollerweise OS X Server? Siehe iMac, wie "sharen"?
? ist der Mini wenigtens "Sommer in Karlsruhe"-fest oder auch so
ein thermisches Fehldesign?
+ man k�nnte noch weitere nette Dinge damit tun, wie die iTunes-
Library da drauf legen und ins Wohnzimmer streamen etc. pp.
Wobei die letzte L�sung mit dem Mini schon derart ins Geld geht,
da� man auch an was ganz anderes denken k�nnte. Wir setzen in
der Firma inzwischen FreeBSD mit ZFS ein. Die Storage-Boxen
sind JBODs und der Server mit dem SAS/SATA-Controller daher im
Fehlerfall ruck-zuck ausgetauscht. Und ZFS rockt nur noch.
Plattendefekt haben wir schon gehabt, auch nachtr�glich Platten
hinzugef�gt, ohne Daten durch die Gegend kopieren zu m�ssen,
funktioniert einfach. Double-Parity ist vorhanden und vor allem
die Robustheit gegen�ber neuen Lesefehlern w�hrend eines Rebuilds
ist deutlich h�her als bei zumindest den billigen "Hardware"-RAIDs.
ZFS wirft eine Platte nicht gleich komplett raus sondern holt sich
die korrekten Bl�cke daher, wo es sie eben her bekommt.
Kennt jemand ein bezahlbares Geh�use f�r 4-6 Festplatten und ein
m�glichst VIA oder Atom-basiertes Mainboard, das thermisch
ordentlich und leise ist. Und nicht gr��er als unbedingt n�tig?
2 GB RAM w�ren das Minimum f�r den Rechner darin, besser 4.
Und: kann ich mit Netatalk einen TM-kompatiblen Server bauen?
Datenaustausch per SMB steht nicht auf dem Programm - es w�rden
ausschlie�lich Macs zugreifen.
Nein, Noses, Eonstor oder �hnlich geht nicht. Ich habe keinen
Keller oder Server-Raum. Das mu� sich alles eine Nummer kleiner
und leiser in der Wohnung abspielen ;-) Daher scheiden auch die
netten JBODs aus der Firma aus. (Fibrecat SX40 von Fujitsu)
Gru�, danke f�r alle Anregungen,
Patrick
--
punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe
Tel. 0721 9109 0 * Fax 0721 9109 100
in...@punkt.de http://www.punkt.de
Gf: J�rgen Egeling AG Mannheim 108285
Patrick Kormann
ist vor allem per iSCSI brauchbar schnell.
Ich geh jetzt per iSCSI auf meinen iMac und reshare die Volumes von dort
aus.
F�r TimeMachine habe ich f�r jeden zu sichernden Rechner ein eigenes
Volume gemacht (damit sich die Sicherungen nicht konkurrenzieren...)
H�tte ich nun nur den Drobo, w�rde ich das genau so machen, allerdings
einfach per Firewire.
Man kann den Drobo auch an eine Airport Extreme anschliessen und ist
dann wieder etwa gleich weit wie mit der TimeCapsule.
Wirklich *leise* sind weder Drobo (hat ein Kollege) noch (schon gar
nicht) Drobo Pro. Schon nur 8 Festplatten machen ganz sch�n krach,
besonders im Zugriff.
Droboshare habe ich nicht versucht, ich denke da w�rde ich eher die
Airport verwenden. Selbst nen Server basteln w�rde ich nicht. Was ich
mir schon �berlegt habe ist den alten Mini aus dem G�stehaus zu holen
und daf�r zu verwenden, aber (sch�m) dann fehlt mir wieder ein
Ethernetport an der Airport, m�sste ich also noch nen Gigabit Switch
besorgen (mist, beim Umzug aus der Schweiz hab ich etliche
weggeschmissen/verschenkt).
Patrick M. Hausen
Patrick Kormann <sir...@hotmail.com> wrote:
> Ich hab vorgestern meinen Drobo Pro gekriegt. Macht noch echt Freude,
> ist vor allem per iSCSI brauchbar schnell.
> Ich geh jetzt per iSCSI auf meinen iMac und reshare die Volumes von dort
> aus.
Stimmt, iSCSI hatte ich f�r zuhause irgendwie �bersehen.
Was f�r einen Initiator benutzt Du?
Gru�,
Patrick Kormann
> Stimmt, iSCSI hatte ich f�r zuhause irgendwie �bersehen.
> Was f�r einen Initiator benutzt Du?
Den, der mitgeliefert wird (im Moment nur 32bit). Aber Achtung, der
Drobo hat kein iSCSI, nur der Drobo Pro.
Stefan
> Aber Achtung, der Drobo hat kein iSCSI, nur der Drobo Pro.
Leicht vom Thema abweichend, aber weils gerade angesprochen wurde: Wie
gross, wenn �berhaupt, ist eigentlich der Performance-Vorteil von iSCSI
zu ganz kommunem AFP-Filesharing? (Mal abgesehen davon, dass Drobo
letzeres vermutlich nicht unterst�tzt.)
Patrick M. Hausen
ich antworte mir gerade mal selbst:
> Wobei die letzte L�sung mit dem Mini schon derart ins Geld geht,
> da� man auch an was ganz anderes denken k�nnte. Wir setzen in
> der Firma inzwischen FreeBSD mit ZFS ein.
Haupt-Grund, warum wir darauf setzen: man ist nicht von
dem St�ck Hardware abh�ngig, in dem die Platten stecken.
Oder von Marke und Modell des RAID-Controllers, was auf
dasselbe Problem hinaus l�uft, wenn so eine Kiste mal
ein paar Jahre in Betrieb ist.
Alle Daten sind _auf_ den Platten und das Filesystem
l��t sich an einem beliebigen Rechner, an den man die
Platten physisch anschlie�en kann, wieder hochfahren.
Fujitsu SX 40 abgek�ndigt - schraubt man die Scheiben
zur Not eben um und steckt sie in eine beliebgie Box
von HP, IBM, ...
Von wegen Rechner f�r sowas f�r den Hausgebrauch: was halten
die hier mitlesenden denn von einem gebrauchten Mac Pro?
Da gehen 4 Platten rein. Die sind leise, zumindest die, die
ich bisher bei Kunden gesehen habe. FreeBSD sollte man auch
ans Fliegen kriegen. Bleibt die Thematik Time Machine <> Netatalk.
Und was "kleines" ist das nat�rlich nicht.
Oder ein Thecus 5200 oder 5500 und iSCSI ... aber dann sind
wieder die Daten futsch, wenn das Geh�use futsch ist.
Ist beim Drobo nicht anders, klar.
Gru�,
Markus Elsken
Patrick Kormann schrieb:
> Ich hab vorgestern meinen Drobo Pro gekriegt. Macht noch echt Freude,
> ist vor allem per iSCSI brauchbar schnell.
K�nntest Du mal ausmetern, wie schnell das Teil via Netz liest und
schreibt, z.B. mit Helios LanTest? Merci :-)
mfg Markus
Patrick Kormann
> Moin!
>
> Patrick Kormann schrieb:
>> Ich hab vorgestern meinen Drobo Pro gekriegt. Macht noch echt Freude,
>> ist vor allem per iSCSI brauchbar schnell.
>
Das geht nicht, der Drobo connected ja per iSCSI und das sieht f�r den
Mac dann aus wie ein lokales Volume.
Ich muss auch sagen ich habe zur Zeit eine etwas doofe Konfiguration,
bis die 2 TB Platten ankommen habe ich noch einige 300er (!) drin
AJA System Test sagt bei 1 GB Filegr�sse folgendes:
Schreiben ~20 MB/s
Lesen: ~34 MB/s
Ich bin der Meinung bei meinen ersten Tests habe das besser ausgesehen,
Schreibrate geht auch erst mal auf 70 MB/s hoch, wohl bis der Cache des
Drobo voll ist...
Vielleicht l�uft ja noch irgend ein Task...
XBench sagt folgendes:
Results 43.52
System Info
Xbench Version 1.3
System Version 10.6.1 (10B504)
Physical RAM 4096 MB
Model iMac9,1
Drive Type DROBO DroboPro
Disk Test 43.52
Sequential 37.77
Uncached Write 84.21 51.70 MB/sec [4K blocks]
Uncached Write 30.62 17.32 MB/sec [256K blocks]
Uncached Read 20.86 6.10 MB/sec [4K blocks]
Uncached Read 74.51 37.45 MB/sec [256K blocks]
Random 51.32
Uncached Write 69.39 7.35 MB/sec [4K blocks]
Uncached Write 34.33 10.99 MB/sec [256K blocks]
Uncached Read 67.35 0.48 MB/sec [4K blocks]
Uncached Read 51.14 9.49 MB/sec [256K blocks]
Im Vergleich dazu die TimeCapsule:
Disk Test 19.07
Sequential 13.10
Uncached Write 6.02 3.69 MB/sec [4K blocks]
Uncached Write 17.31 9.79 MB/sec [256K blocks]
Uncached Read 15.88 4.65 MB/sec [4K blocks]
Uncached Read 53.91 27.10 MB/sec [256K blocks]
Random 35.04
Uncached Write 15.22 1.61 MB/sec [4K blocks]
Uncached Write 44.06 14.11 MB/sec [256K blocks]
Uncached Read 59.13 0.42 MB/sec [4K blocks]
Uncached Read 112.99 20.97 MB/sec [256K blocks]
Frag mich nicht, warum die Lesewerte so grottig sind, wer misst misst
wohl Mist. Hm, die Werte scheinen ganz sch�n zu schwanken, hier nochmal
ein Druchgang:
Results 45.49
Disk Test 45.49
Sequential 42.45
Uncached Write 65.51 40.23 MB/sec [4K blocks]
Uncached Write 54.98 31.11 MB/sec [256K blocks]
Uncached Read 19.92 5.83 MB/sec [4K blocks]
Uncached Read 94.46 47.47 MB/sec [256K blocks]
Random 49.01
Uncached Write 77.13 8.17 MB/sec [4K blocks]
Uncached Write 38.31 12.26 MB/sec [256K blocks]
Uncached Read 47.34 0.34 MB/sec [4K blocks]
Uncached Read 46.69 8.66 MB/sec [256K blocks]
Ach, frag mich in ner Woche nochmal. Bisher erschien mir das Ding
jedenfalls noch recht schnell zu sein ;)
Thomas Kaiser
> Markus Elsken schrieb:
>>
>> Könntest Du mal ausmetern, wie schnell das Teil via Netz liest und
>
Und? Gibt nur 'ne Warnmeldung, die man wegklicken muß. Mich würde auch
das Ergebnis des kompletten Testparcours interessieren.
Gruss,
Thomas
Thomas Kaiser
> Und: kann ich mit Netatalk einen TM-kompatiblen Server bauen?
Yep, ab 2.0.5 ist alles, was es braucht, die Volume-Option "tm", der
FPSyncDir-Kram ist aber schon länger existent. Siehe
<http://downloads.sourceforge.net/project/netatalk/netatalk/2.0.5-rc1/release-notes.txt>
<http://marc.info/?l=netatalk-devel&m=125224189613123&w=2>
In FreeNAS bspw. ist das AFAIK schon alles drin. Wenn Du es also
einfacher haben wolltest...
Andererseits kannst Du Netatalk 2.0.5 natürlich auch direkt auf dem
Drobo laufen lassen:
<http://lookfirst.com/2008/11/timemachine-via-afp-netatalk-to.html>
Gruss,
Thomas
Markus Elsken
Patrick Kormann schrieb:
> Das geht nicht, der Drobo connected ja per iSCSI und das sieht f�r den
> Mac dann aus wie ein lokales Volume.
Was das Programm nicht weiter st�rt, das testet auch auf lokalen Volumes.
> Ich muss auch sagen ich habe zur Zeit eine etwas doofe Konfiguration,
> bis die 2 TB Platten ankommen habe ich noch einige 300er (!) drin
> AJA System Test sagt bei 1 GB Filegr�sse folgendes:
> Schreiben ~20 MB/s
> Lesen: ~34 MB/s
Das ist etwas wenig, ich hatte auf h�here Werte gehofft. Aber warten wir
mal, bis die "dicken" Platten drin sind...
> Ach, frag mich in ner Woche nochmal. Bisher erschien mir das Ding
> jedenfalls noch recht schnell zu sein ;)
Aber sicher doch. Hier laufen n�mlich auch zwei Drobos, ich will aber
eine Speicherkiste f�r alle Rechner haben...
mfg Markus
Patrick M. Hausen
Thomas Kaiser <Thomas...@phg-online.de> wrote:
> Patrick M. Hausen schrieb am 04.10.2009 in <news:haafhr$b3u$1...@subnet.sub.net>
> > Und: kann ich mit Netatalk einen TM-kompatiblen Server bauen?
> Yep, ab 2.0.5 ist alles, was es braucht, die Volume-Option "tm", der
> FPSyncDir-Kram ist aber schon l�nger existent.
Nett, danke.
> Andererseits kannst Du Netatalk 2.0.5 nat�rlich auch direkt auf dem
> Drobo laufen lassen:
>
> <http://lookfirst.com/2008/11/timemachine-via-afp-netatalk-to.html>
Pest oder Cholera? Entweder dieser Hack oder der TM beibiegen,
auf einem SMB-Share zu sichern. Beides nicht der Kn�ller ;-)
Gru�,
Goetz Hoffart
> Entweder dieser Hack oder der TM beibiegen, auf einem SMB-Share zu
> sichern. Beides nicht der Kn�ller ;-)
Wenn du eh schon compilierst und bastelst -- dann w�rd ich gleich ein
Ion/Atom-Board nehmen, FreeBSD+ZFS drauf. Denn dann hast du den
Hardware-Faktor wieder ausgeschaltet, der beim Drobo ja als Unsicherheit
leider dazukommt.
Gr��e
G�tz
--
http://www.knubbelmac.de/
Thomas Kaiser
> Thomas Kaiser <Thomas...@phg-online.de> wrote:
>
>> Andererseits kannst Du Netatalk 2.0.5 natürlich auch direkt auf dem
>>
>> <http://lookfirst.com/2008/11/timemachine-via-afp-netatalk-to.html>
>
> Pest oder Cholera? Entweder dieser Hack
Das Hack ist bereits küchenfertig ;-)
<http://code.google.com/p/backmyfruitup/wiki/SetupGuideVersion2>
> oder der TM beibiegen, auf einem SMB-Share zu sichern. Beides nicht
> der Knüller ;-)
Naja, ich verstehe ja eh nicht, wie man bei Deiner "Vorbelastung" sowas
wie Drobos [1] überhaupt in die engere Wahl nehmen kann.
Gruss,
Thomas
[1] Dem Geschwafel von wegen BeyondRAID dürftest Du ja nicht auf den
Leim gehen. De facto ist das aber halt auch nur einfach "broken by
design": <http://www.suitetake.com/2009/08/21/the-dark-side-of-drobo/>
Patrick M. Hausen
Thomas Kaiser <Thomas...@phg-online.de> wrote:
> Naja, ich verstehe ja eh nicht, wie man bei Deiner "Vorbelastung" sowas
> wie Drobos [1] �berhaupt in die engere Wahl nehmen kann.
Das Ding ist einfach bequem. Und ich hab's gern mechanisch "h�bsch".
> [1] Dem Geschwafel von wegen BeyondRAID d�rftest Du ja nicht auf den
> Leim gehen. De facto ist das aber halt auch nur einfach "broken by
> design": <http://www.suitetake.com/2009/08/21/the-dark-side-of-drobo/>
Kenne ich. Was ist der Punkt? Das Problem habe ich bei jeder Art
von Over-Provisioning. Ob es das RAM von virtuellen Maschinen
ist, da� die Kiste physisch in der Summe nicht hat, oder der
Plattenplatz von VMware "thin" Images, oder von Sparse Images
des Mac ... man mu� eben drauf achten, wann so ein Drobo "voll"
ist und beizeiten nachlegen. Auch mein zentraler Backup-Server
baut darauf, von jedem Filesystem nur einmal pro Woche einen
Full-Dump zu machen, und hofft, da� die Incrementals der
Kunden im Mittel nicht zu gro� werden.
Aber mal gucken, ob ich einen Minitower finde, in den ein paar
Platten reingehen ...
Gru�, danke,
Thomas Kaiser
>
> Thomas Kaiser <Thomas...@phg-online.de> wrote:
>> Naja, ich verstehe ja eh nicht, wie man bei Deiner "Vorbelastung"
>
> Das Ding ist einfach bequem. Und ich hab's gern mechanisch "hübsch".
Trifft beides denn wirklich auf die Dinger zu? Für mich gehört beim
Konzept bzw. Einsatzzweck des Ganzen zur Bequemlichkeit auch dazu, daß
das Ding von selbst meldet, wenn es in einen wie auch immer gearteten
kritischen Zustand gerät. Geht das abseits Installation irgendwelcher
Tools, die man wieder auf einem Desktop-Rechner installieren muß (Drobo
Dashboard?)
>> [1] Dem Geschwafel von wegen BeyondRAID dürftest Du ja nicht auf den
>> Leim gehen. De facto ist das aber halt auch nur einfach "broken by
>> design": <http://www.suitetake.com/2009/08/21/the-dark-side-of-drobo/>
>
> Kenne ich. Was ist der Punkt?
Nicht-Funktionieren vs. Datenverlust? Ist schon noch mal was anderes,
IMO.
> Aber mal gucken, ob ich einen Minitower finde, in den ein paar
> Platten reingehen ...
Bspw. silentMaxx ITA-2767 nebst passend dimensioniertem EcoSilent-
Netzteil. Da passen 8 entkoppelte/gedämmte Platten rein, weil 8 x 5,25"
nutzbar.
Gruss,
Thomas
Frank Reutter
> > Aber mal gucken, ob ich einen Minitower finde, in den ein paar
> > Platten reingehen ...
>
> Bspw. silentMaxx ITA-2767 nebst passend dimensioniertem EcoSilent-
> Netzteil. Da passen 8 entkoppelte/ged�mmte Platten rein, weil 8 x 5,25"
> nutzbar.
8 x 5,25 h�rt sich aber nicht nach Mini an.
cu
f
--
...ausserdem halte ich verdunkelte Heckscheiben f�r antisozial und dumm.
Thomas Kaiser
> Thomas Kaiser <Thomas...@phg-online.de> wrote:
>
>> Bspw. silentMaxx ITA-2767 nebst passend dimensioniertem EcoSilent-
>> nutzbar.
>
> 8 x 5,25 hört sich aber nicht nach Mini an.
Äh, ja, klar. Midi-Tower. Irgendeinen Kompromiß muß man immer eingehen,
wenn man Kapazität, Performance, Temperatur und Lautstärke unter einen
Hut bringen will. Wenn das Ding aber eh in den Schrank soll, dann würde
ich bei der Größe als Erstem Abstriche machen...
Mit 8 WD Caviar Green oder Samsungs F1 Ecogreen, passendes Board/CPU und
FreeBSD/ZFS/FreeNAS ist das dann im Gegensatz zum Drobo-Gefrickel eine
wirklich runde, robuste, performante und gleichzeitig leise Lösung und
kostet vermutlich allenfalls die Hälfte. Schaut dafür halt auch Sch***e
aus. Wie so oft eine Frage der Prioritäten...
Gruss,
Thomas
Patrick Kormann
> Trifft beides denn wirklich auf die Dinger zu? Für mich gehört beim
> Konzept bzw. Einsatzzweck des Ganzen zur Bequemlichkeit auch dazu, daß
> das Ding von selbst meldet, wenn es in einen wie auch immer gearteten
> kritischen Zustand gerät. Geht das abseits Installation irgendwelcher
> Tools, die man wieder auf einem Desktop-Rechner installieren muß (Drobo
> Dashboard?)
Nun, irgendwie musst du ja an die Daten ran kommen, sei es per USB,
iSCSI oder Firewire. Also hast du auch einen Rechner, auf dem du die
Software installieren kannst ;)
Patrick Kormann
> Moin!
>
> Patrick Kormann schrieb:
>> Das geht nicht, der Drobo connected ja per iSCSI und das sieht f�r den
>> Mac dann aus wie ein lokales Volume.
>
> Was das Programm nicht weiter st�rt, das testet auch auf lokalen Volumes.
Stimmt. War zu faul ;)
Nun, ich komme mit dem Ding nicht so ganz zurecht. Zeigt mir oben (fast)
immer die lokale HD des iMac als zu testendes Volume an, hat dann aber
doch ein Drobo Volume getestet. Allerdings nur auf der Einstellung 100
MBit/s. bei 1000 Mbit/s (also 10xgr�ssere Dateien) bricht es immer
wieder mit der Fehlermeldung, die Testdateien seien schon vorhanden nach
dem ersten Durchgang ab.
Hier mal die Werte:
Testing on volume local drive: Macintosh HD
Number of small Files: 300, Size of small Files [kB]: 20, Size of big
File [MB]: 30, Number of Locks: 16000, Number of Files/Folder: 640, Size
of Printfile [MB]: 30
Date Time # Users Create [sec] Open [sec] Remove [sec] Write [MB/sec]
Read [MB/sec] Lock/Unlock [sec] Read Catalog [sec] Test Printer [kb/sec]
05.10.2009 12:14:16 1 0.10 0.00 0.06 100.00 9.57 0.11 0.00 0.00
05.10.2009 12:14:21 1 0.11 0.01 0.05 75.00 8.69 0.11 0.01 0.00
05.10.2009 12:14:25 1 0.11 0.01 0.08 85.71 8.41 0.13 0.01 0.00
05.10.2009 12:14:30 1 0.11 0.00 0.05 94.73 8.29 0.11 0.01 0.00
05.10.2009 12:14:34 1 0.10 0.00 0.06 72.00 9.37 0.11 0.01 0.00
05.10.2009 12:14:38 1 0.11 0.00 0.06 69.23 9.32 0.11 0.00 0.00
05.10.2009 12:14:43 1 0.11 0.00 0.06 94.73 7.22 0.11 0.01 0.00
05.10.2009 12:14:48 1 0.13 0.01 0.06 18.00 12.67 0.13 0.00 0.00
05.10.2009 12:14:52 1 0.11 0.01 0.08 94.73 9.67 0.13 0.03 0.00
05.10.2009 12:14:55 1 0.11 0.01 0.06 100.00 11.92 0.11 0.01 0.00
Tja, sorry f�r die Formatierung. Die Lesewerte sind ja gerade unter
aller Sau. Ich werde dem noch nachgehen. Das Ding h�ngt an einer
TimeCapsule, f�r dessen Gigabit Ports ich auch nicht die Hand in's Feuer
legen m�chte. Aber ich habe auch schon Tests gemacht, die IMHO bei
direktem Anschluss �hnliche Werte ergeben haben wie �ber die TC.
Vielleicht kriegt das Ding ein Problem wenn die Platten relativ voll
sind (dass es ein Problem kriegt, wenn sie ganz voll sind weiss ich
schon ;) )
> Aber sicher doch. Hier laufen n�mlich auch zwei Drobos, ich will aber
> eine Speicherkiste f�r alle Rechner haben...
Hmm, fall aber nicht drauf rein wie ich. iSCSI l�uft da nur als
Punkt-Punkt Verbindung, d.h. nur auf einen Rechner. D.h. du musst dann
genau so von nem Rechner aus weitersharen. Da geht's eigentlich genau so
gut mit Firewire.
Markus Elsken
Goetz Hoffart schrieb:
> Wenn du eh schon compilierst und bastelst -- dann w�rd ich gleich ein
> Ion/Atom-Board nehmen, FreeBSD+ZFS drauf. Denn dann hast du den
> Hardware-Faktor wieder ausgeschaltet, der beim Drobo ja als Unsicherheit
> leider dazukommt.
Ach, Ion/Atom-Boards k�nnen nicht die Hufe hochreissen?
mfg Markus
Thomas Kaiser
> Goetz Hoffart schrieb:
>> Wenn du eh schon compilierst und bastelst -- dann würd ich gleich ein
>> Hardware-Faktor wieder ausgeschaltet, der beim Drobo ja als
>> Unsicherheit leider dazukommt.
>
*Seufz*. Du wirst es wohl nie kapieren, daß _ein_ Drobo insgesamt nix
weiter als ein Single Point of Failure ist. D.h. ohne Ersatz-Drobo (Pro)
im Schrank bzw. sensationell gutem Draht zum Händler das ganze
Versprechen von Datenverfügbarkeit halt schlichtweg nicht zu halten ist.
Patrick hat das Ganze schon mehrfach erklärt. Insofern echt müßig...
Gruss,
Thomas
Thomas Kaiser
> Markus Elsken schrieb:
>>
>> Patrick Kormann schrieb:
>>> Das geht nicht, der Drobo connected ja per iSCSI und das sieht für
>>
>
> Stimmt. War zu faul ;)
> Nun, ich komme mit dem Ding nicht so ganz zurecht. Zeigt mir oben (fast)
> immer die lokale HD des iMac als zu testendes Volume an, hat dann aber
> doch ein Drobo Volume getestet.
Ist ein Bug. Das ganze Tool ist ja eh nicht so ganz das, was man unter
GUI versteht (also Useability im Hinterkopf habend)
> Allerdings nur auf der Einstellung 100 MBit/s. bei 1000 Mbit/s (also
> 10xgrössere Dateien) bricht es immer wieder mit der Fehlermeldung, die
> Testdateien seien schon vorhanden nach dem ersten Durchgang ab.
Fein, mal interessehalber: Was sagt denn Helios' Filesystem Test zum via
iSCSI eingebundenen Drobo? Runterzuladen bei http://webshare.helios.de
(User: tools, Paßwort: tools) oder kurzfristig hier:
<http://kaiser-edv.de/tmp/hdbGDL/>
> iSCSI läuft da nur als Punkt-Punkt Verbindung, d.h. nur auf einen
> Rechner. D.h. du musst dann genau so von nem Rechner aus weitersharen.
> Da geht's eigentlich genau so gut mit Firewire.
Ah, nach BeyondRAID die nächste sensationelle "Erfindung" von Drobo.
BeyondiSCSI? :-)
Gruss,
Thomas
Patrick Kormann
> Fein, mal interessehalber: Was sagt denn Helios' Filesystem Test zum via
> iSCSI eingebundenen Drobo?
HELIOS File System Test
Version : 4.0.0u0560
Test started at 5.10.2009, 13:35:55 Uhr
Selected Folder: Shared (local directory!)
Test writing to data/resource fork: passed.
Test changing file permissions: passed.
Test setting type/creator: passed.
Test file dates: passed.
Test find file:
expected 1, found 1 item in less than 1 seconds
expected >=1, found 17 items in less than 1 seconds
expected 0, found 0 items in less than 1 seconds
passed.
Test file/directory id consistency: passed.
Test file name with unicode chars: passed.
Test long file name: passed.
Testing save existing file: passed.
Test large file support (4.1 GB): passed.
... allerdings staune ich, der Test hat ca. 1 Sekunde gedauert. Ich hab
den schon vor ein paar Tagen mal laufen lassen und da hing er..
Dasselbe nun beim 2. Druchgang, beim large file Support steht N/A und
das Ding hängt.
> Ah, nach BeyondRAID die nächste sensationelle "Erfindung" von Drobo.
> BeyondiSCSI? :-)
Hmm, k.A. ich kenne mich mit iSCSI nicht aus. Ob das nun eine
Einschränkung des Geräts ist, des Mac-Treibers oder von iSCSI - da bin
ich überfragt.
Übrigens, was ich vielleicht noch erwähnen muss: Ich habe die doppelte
Ausfallsicherheit eingeschaltet (so dass 2 Platten ausfallen können).
Thomas Kaiser
> Thomas Kaiser schrieb:
>
>> Fein, mal interessehalber: Was sagt denn Helios' Filesystem Test zum
>> via iSCSI eingebundenen Drobo?
> HELIOS File System Test
> Version : 4.0.0u0560
>
> Test started at 5.10.2009, 13:35:55 Uhr
> Selected Folder: Shared (local directory!)
Das Volume ist als HFS+ initialisiert, oder?
> Test writing to data/resource fork: passed.
> Test changing file permissions: passed.
> Test setting type/creator: passed.
> Test file dates: passed.
> Test find file:
> expected 1, found 1 item in less than 1 seconds
> expected >=1, found 17 items in less than 1 seconds
> expected 0, found 0 items in less than 1 seconds
> passed.
> Test file/directory id consistency: passed.
> Test file name with unicode chars: passed.
> Test long file name: passed.
> Testing save existing file: passed.
> Test large file support (4.1 GB): passed.
>
> ... allerdings staune ich, der Test hat ca. 1 Sekunde gedauert.
Da staune ich auch, ja. Irgendwas stimmt da nicht so ganz...
Magst Du mal in /var/log/system.log schauen, ob da parallel Meldungen
aufschlagen, die bisserl detaillierter auf ein Problem hinweisen?
> Ich hab den schon vor ein paar Tagen mal laufen lassen und da hing
> er.. Dasselbe nun beim 2. Druchgang, beim large file Support steht N/A
> und das Ding hängt.
Welchen iSCSI-Initiator nutzt Du? Den von globalSAN?
>> Ah, nach BeyondRAID die nächste sensationelle "Erfindung" von Drobo.
>> BeyondiSCSI? :-)
>
> Hmm, k.A. ich kenne mich mit iSCSI nicht aus. Ob das nun eine
> Einschränkung des Geräts ist, des Mac-Treibers oder von iSCSI - da bin
> ich überfragt.
Weder noch ;-)
Nee, das paßt grundsätzlich schon. Bei iSCSI geht's ja nur darum, daß
SCSI-Daten via TCP/IP verpackt werden. Damit "Shared Storage"
umzusetzen, bedeutet, daß man entweder ein SAN-fähiges Dateisystem
braucht (bspw. das StoreNextFS, am Mac als XSan bekannt) oder halt einen
FileSharing-Daemon ins Spiel bringt, der als einziger aufs Dateisystem
zugreift und über ein Netzwerk-Dateisystem (bspw. AFP oder SMB/CIFS) die
konkurrierenden Zugriffe anderer Clients koordiniert (NAS).
Jemand, der sich mit dem Storage-Kram auskennt, weiß das natürlich, daß
er mit iSCSI und vielen Maschinen entweder beim Dateisystem oder einem
NAS-Head ansetzen muß. Das dürfte Data Robotics allerdings nicht zu sehr
betonen (man marketing) sondern halt einfach dem Kunden das Gefühl
mitgeben, iSCSI hätte halt auch so ein bisschen was mit "viele Rechner,
ein Drobo, kein Problem" zu tun. Genauso wie das Marketing rund um RAID
bzw. der Kalauer BeyondRAID, der der Kundenschaft Datenverfügbarkeit
vorgaukelt, wo gar keine ist, weil das Drobo selbst ein SPoF ist.
> Übrigens, was ich vielleicht noch erwähnen muss: Ich habe die doppelte
> Ausfallsicherheit eingeschaltet (so dass 2 Platten ausfallen können).
Also RAID-6 oder wie auch immer man den Level mit doppelter Redundanz
nennen will (bei Drobo vielleicht WayBeyondRAID? :-)
Gruss,
Thomas
Patrick M. Hausen
Thomas Kaiser <Thomas...@phg-online.de> wrote:
> > �brigens, was ich vielleicht noch erw�hnen muss: Ich habe die doppelte
> > Ausfallsicherheit eingeschaltet (so dass 2 Platten ausfallen k�nnen).
>
> Also RAID-6 oder wie auch immer man den Level mit doppelter Redundanz
> nennen will (bei Drobo vielleicht WayBeyondRAID? :-)
ZFS hat inzwischen Triple-Parity, allerdings noch nicht in FreeBSD:
http://blogs.sun.com/ahl/entry/triple_parity_raid_z
Warum man das brauchen wird? Deshalb:
http://blogs.zdnet.com/storage/?p=162
Nat�rlich ist es Schwachsinn, bei einem einzelnen Lesefehler
gleich die ganze Platte als defekt rauszuschmei�en. Schon
das macht ZFS wesentlich intelligenter. Aber im allgemeinen
kann man damit rechnen, da� die Anzahl der ben�tigten
Parity-Platten logarithmisch mit den Plattengr��en wachsen wird.
Mein pers�nliches Storage-Problem w�rde ich gerne so l�sen,
wenn die Kiste nur nicht so teuer w�re ...
http://de.ts.fujitsu.com/products/standard_servers/tower/primergy_tx120s2.html
4 Platten schluckt das kleine Ding, maximal 320 GB zur Zeit
pro Platte, aber das wird ja mit der Zeit besser werden ;-)
Gru�,
Patrick Kormann
> Da staune ich auch, ja. Irgendwas stimmt da nicht so ganz...
>
> Magst Du mal in /var/log/system.log schauen, ob da parallel Meldungen
> aufschlagen, die bisserl detaillierter auf ein Problem hinweisen?
Nein, keine Meldungen. Hab's nochmal laufen lassen. Erster Versuch:
Sofort erfolgreich, zweiter Durchgang hängt wieder beim large File Support.
> Welchen iSCSI-Initiator nutzt Du? Den von globalSAN?
Äh, den den Drobo mitliefert. Ist was ich gelesen habe selsbtgestrickt?
> Weder noch ;-)
>
> Nee, das paßt grundsätzlich schon. Bei iSCSI geht's ja nur darum, daß
> SCSI-Daten via TCP/IP verpackt werden. Damit "Shared Storage"
> umzusetzen, bedeutet, daß man entweder ein SAN-fähiges Dateisystem
> braucht (bspw. das StoreNextFS, am Mac als XSan bekannt) oder halt einen
> FileSharing-Daemon ins Spiel bringt, der als einziger aufs Dateisystem
> zugreift und über ein Netzwerk-Dateisystem (bspw. AFP oder SMB/CIFS) die
> konkurrierenden Zugriffe anderer Clients koordiniert (NAS).
>
> Jemand, der sich mit dem Storage-Kram auskennt, weiß das natürlich, daß
> er mit iSCSI und vielen Maschinen entweder beim Dateisystem oder einem
> NAS-Head ansetzen muß. Das dürfte Data Robotics allerdings nicht zu sehr
> betonen (man marketing) sondern halt einfach dem Kunden das Gefühl
> mitgeben, iSCSI hätte halt auch so ein bisschen was mit "viele Rechner,
> ein Drobo, kein Problem" zu tun. Genauso wie das Marketing rund um RAID
> bzw. der Kalauer BeyondRAID, der der Kundenschaft Datenverfügbarkeit
> vorgaukelt, wo gar keine ist, weil das Drobo selbst ein SPoF ist.
Ehm, ich meine auch irgendwo gelesen zu haben, dass man auf verschiedene
Volumes durchaus von verschiedenen Rechern aus zugreifen dürfe (per
iSCSI). Ich wüsste allerdings nicht wirklich, wie ich das sinnvoll
konfigurieren sollte, das Dashboard bietet dafür keine Option.
Vielleicht krallt sich der 2. Rechner einfach die Volumes, die beim 1.
nicht gemountet sind. Aber auch das würde mich nicht wirklich glücklich
machen ;)
> Also RAID-6 oder wie auch immer man den Level mit doppelter Redundanz
> nennen will (bei Drobo vielleicht WayBeyondRAID? :-)
Wie auch immer, ja. Nun gut, eigentlich nennen sie es ganz einfach 'Dual
Disk Redundancy' Ach ja, mitlerweilen ist der 2. Durchgang doch auch
erfolgreich durchgelaufen ;)
Das mit dem SPoF ist natürlich ein Argument. Noch schlimmer ist, dass
man da dann Datenmengen draufpappen kann, die sich auch nicht mehr so
leicht irgendwohin backuppen lassen.
Thomas Kaiser
> Thomas Kaiser schrieb:
>
>> Welchen iSCSI-Initiator nutzt Du? Den von globalSAN?
>
> Äh, den den Drobo mitliefert. Ist was ich gelesen habe
> selsbtgestrickt?
Hmm... man könnte auch mal testweise den von globalSAN benutzen.
> Ehm, ich meine auch irgendwo gelesen zu haben, dass man auf
> verschiedene Volumes durchaus von verschiedenen Rechern aus zugreifen
> dürfe (per iSCSI).
Klar, es geht halt immer nur darum, Situationen mit unkontrollierten
parallelen Schreibvorgängen innerhalb eines Volumes vorzubeugen.
>> Also RAID-6 oder wie auch immer man den Level mit doppelter Redundanz
>> nennen will (bei Drobo vielleicht WayBeyondRAID? :-)
>
> Wie auch immer, ja. Nun gut, eigentlich nennen sie es ganz einfach
> 'Dual Disk Redundancy'
Bei den heutigen Plattengrößen _darf_ man gar nicht weniger nehmen. Bzw.
kann man's dann auch gleich mit der Redundanz sein lassen, weil de facto
einfach keine da ist.
> Ach ja, mitlerweilen ist der 2. Durchgang doch auch erfolgreich
> durchgelaufen ;)
Naja, der Filesystem-Test pappt da halt 'ne 4 GByte große Datei drauf.
Artet also zwangsweise in einen Schreib-Benchmark aus. Irritierend ist
aber, daß dieser Test beim ersten mal als sofort erfolgreich gemeldet
wird.
> Das mit dem SPoF ist natürlich ein Argument.
Ebend. Da ist man mit Standard-PC-Schraddel-Hardware bzw. Standard-SATA-
Controller und Software-RAID eingermaßen aus dem Schneider bzw. Ersatz
flink besorgt und ohne Probleme ausgetauscht.
> Noch schlimmer ist, dass man da dann Datenmengen draufpappen kann, die
> sich auch nicht mehr so leicht irgendwohin backuppen lassen.
Ja. Und viele Leute machen sich diesbzgl. gar keine Gedanken. Zudem auch
die Zeitfenster für ein Restore heftig ausfallen können. IMO kommt man
um sowas wie Datenmanagement nicht herum, wenn man sich schon TByte-weise
Daten ans Bein bindet.
Gruss,
Thomas
Patrick Kormann
> Hmm... man könnte auch mal testweise den von globalSAN benutzen.
Mal sehen.
> Klar, es geht halt immer nur darum, Situationen mit unkontrollierten
> parallelen Schreibvorgängen innerhalb eines Volumes vorzubeugen.
Ja, was mir nur nicht ganz klar war ist, ob das Gerät sich selbst
dagegen wehr (indem es nur eine Verbindung zulässt) oder nicht.
> Bei den heutigen Plattengrößen _darf_ man gar nicht weniger nehmen. Bzw.
> kann man's dann auch gleich mit der Redundanz sein lassen, weil de facto
> einfach keine da ist.
Hmm, so ganz kann ich das nicht nachvollziehen. Wenn die Lesefehler so
häufig wären, könnte man ja nie so ne Platte lesen.
> Naja, der Filesystem-Test pappt da halt 'ne 4 GByte große Datei drauf.
> Artet also zwangsweise in einen Schreib-Benchmark aus. Irritierend ist
> aber, daß dieser Test beim ersten mal als sofort erfolgreich gemeldet
> wird.
Genau, die erste Datei wird etwas unverschämt schnell erstellt...
> Ebend. Da ist man mit Standard-PC-Schraddel-Hardware bzw. Standard-SATA-
> Controller und Software-RAID eingermaßen aus dem Schneider bzw. Ersatz
> flink besorgt und ohne Probleme ausgetauscht.
Ja. Aber da hatte ich bisher immer etwas Hemmungen wegen afp. Ausserdem
war, als ich das letzte mal sowas gemacht habe noch md das höchste der
Gefühle und damit wurde ich auch nicht so richtig warm.
Drobo ist halt schon verlockend einfach.
> Ja. Und viele Leute machen sich diesbzgl. gar keine Gedanken. Zudem auch
> die Zeitfenster für ein Restore heftig ausfallen können. IMO kommt man
> um sowas wie Datenmanagement nicht herum, wenn man sich schon TByte-weise
> Daten ans Bein bindet.
Naja, um mir keine Gedanken zu machen habe ich schon zu viel erlebt ;)
Auf den Drobo kommen im Moment TimeMachine Daten von 4 Macs und die
Daten, die ich bisher auf der TimeCapsule hatte (wobei die Timecapsule
als Backupmedium (ich weiss, nicht ideal, aber für den Heimbetrieb
besser als nix) herhalten muss. Nur, was passiert, wenn die Datenmengen
soweit wachsen, dass die TC nicht mehr reicht? Naja, ich habe ein paar
externe Gehäuse mit Platteneinschüben geschlachtet für den Drobo, da
kann ich ja dann auch irgendwann wieder eine 2 TB Platte reinstecken.
Wirklich lebenswichtige Daten habe ich wohl nicht mehr ;)
Patrick M. Hausen
Thomas Kaiser <Thomas...@phg-online.de> wrote:
> Markus Elsken schrieb in <news:4ac9d382$0$3287$8e6e...@newsreader.ewetel.de>
> > Goetz Hoffart schrieb:
> >> Wenn du eh schon compilierst und bastelst -- dann w�rd ich gleich ein
> >> Ion/Atom-Board nehmen, FreeBSD+ZFS drauf. Denn dann hast du den
> >> Hardware-Faktor wieder ausgeschaltet, der beim Drobo ja als
> >> Unsicherheit leider dazukommt.
> >
> > Ach, Ion/Atom-Boards k�nnen nicht die Hufe hochreissen?
>
> *Seufz*. Du wirst es wohl nie kapieren, da� _ein_ Drobo insgesamt nix
> weiter als ein Single Point of Failure ist. D.h. ohne Ersatz-Drobo (Pro)
> im Schrank bzw. sensationell gutem Draht zum H�ndler das ganze
> Versprechen von Datenverf�gbarkeit halt schlichtweg nicht zu halten ist.
Nach Gespr�ch mit meinem lokalen Mac-Systemhaus habe ich wohl
was, was den Anspruch "halbwegs h�bsch und leise" erf�llt.
Ein Sonnet Fusion D500P - JBOD f�r 5 Platten mit eSATA Portmultiplier.
Hat zwar auch RAID an Bord, das mu� man aber nicht benutzen.
Das an einen geeigneten Rechner mit dem erw�hnten FreeBSD + ZFS,
Thema durch. Da kann ich mir, wenn es partout sein mu�, sogar ein
zweites daneben stellen und die Daten nochmal kopieren. Die
Controller haben �blicherweise mindestens zwei Anschl�sse.
Danke f�r die Diskussion, weitere Meinungen sind nat�rlich immer
noch willkommen. Jetzt mu� ich nur noch einen leisen Rechner
mit EMT64 und 4 GB RAM finden, das braucht's f�r ZFS n�mlich schon.
Das Betriebssystem selbst kann auf ein USB-Drive, davon zieht man
dann auch einfachst wieder eine Sicherheitskopie. man NanoBSD ;-)
Markus Elsken
Thomas Kaiser schrieb:
> *Seufz*. Du wirst es wohl nie kapieren, daß _ein_ Drobo insgesamt nix
> weiter als ein Single Point of Failure ist. D.h. ohne Ersatz-Drobo (Pro)
> im Schrank bzw. sensationell gutem Draht zum Händler das ganze
> Versprechen von Datenverfügbarkeit halt schlichtweg nicht zu halten ist.
Das weiss ich schon, aber das gilt dann halt auch für die
Atom/Ion-Lösung. Auch das kann ausfallen und ohne Ersatzgerät sitzt man
dann genau so da. Ein Ersatz-Drobo(pro) ist innerhalb von einem, max.
zwei Werktagen da, das ist vertretbar. Wer vertreibt diese
Atom/Ion-Lösung, was kostet sie und wie schnell steht im Fall der Fälle
in neues Gerät da? Kann der Endkunde (User) da genau so schnell wie
Platten entfernen?
Bisher laufen die beiden Drobos hier sauber im Fast-Dauerbetrieb,
während Platten öfter mal die Hufe hochreissen. Auch in den Drobos sind
schon zwei abgestorben, der Wechsel dauerte Sekunden und seitdem ist
wieder Ruhe. Bei Einzelplatten wären die Daten erstmal weg gewesen und
ich hätte sie vom Backup zurückspielen müssen.
mfg Markus
Patrick M. Hausen
Markus Elsken <m.el...@ewetel.net> wrote:
> Thomas Kaiser schrieb:
> > *Seufz*. Du wirst es wohl nie kapieren, da� _ein_ Drobo insgesamt nix
> > weiter als ein Single Point of Failure ist. D.h. ohne Ersatz-Drobo (Pro)
> > im Schrank bzw. sensationell gutem Draht zum H�ndler das ganze
> > Versprechen von Datenverf�gbarkeit halt schlichtweg nicht zu halten ist.
>
> Das weiss ich schon, aber das gilt dann halt auch f�r die
> Atom/Ion-L�sung. Auch das kann ausfallen und ohne Ersatzger�t sitzt man
> dann genau so da. Ein Ersatz-Drobo(pro) ist innerhalb von einem, max.
> zwei Werktagen da, das ist vertretbar.
Bei einem Drobo, Thecus oder auch nur einem RAID-Hostadapter
ist ggf. in 2 Jahren aber gar kein Ger�t dieser Firma mehr
beschaffbar und die Daten komplett weg.
Mit ZFS brauchst Du nur irgendeinen Rechner, an den Du N
SATA-Platten anschlie�en und ein FreeBSD oder OpenSolaris
booten kannst. Darum geht es in Thomas und meiner Diskussion.
Detlev Bartsch
> Ein Ersatz-Drobo(pro) ist innerhalb von einem, max.
> zwei Werktagen da, das ist vertretbar.
Ich hatte Thomas jetzt so verstanden, dass man ruhig mal
überlegen soll, was passieren könnte, wenn das Raid-Gehäuse -
egal von welchem Hersteller - so nicht mehr lieferbar ist
und es - warum auch immer - keine kompatible Alternative gibt
Eine handelsübliche SATA-Platte mit Standard-FS bekommt man immer
irgendwie angeschlossen und gelesen.
> Wer vertreibt diese
> Atom/Ion-Lösung, was kostet sie und wie schnell steht im Fall der Fälle
> in neues Gerät da?
Selberbasteln und beim Kistenschieber an der Ecke kaufen.
> Kann der Endkunde (User) da genau so schnell wie
> Platten entfernen?
Der Plattentod ist hier nicht das Problem, da mag eine propietäre
Lösung wie Drobo und Co unerreicht sein, aber letztendlich sind die
Daten auch nicht sicher.
Wobei man natürlich abwägen muss zwischen relativ häufigem Platten-
verlust und seltenerem Controler- oder Gehäuseausfall. Aber man sollte
sich eben im Klaren sein, dass Murphy auch hier zuschlagen kann und man
nur den SPoF von den Platten an eine andere Stelle verschoben hat.
Tschüss
db
Thomas Kaiser
> Thomas Kaiser schrieb:
> [doppelte Redundanz bzw. "RAID-5 ist tot"]
>> Bei den heutigen Plattengrößen _darf_ man gar nicht weniger nehmen.
>> Bzw. kann man's dann auch gleich mit der Redundanz sein lassen, weil
>> de facto einfach keine da ist.
>
> Hmm, so ganz kann ich das nicht nachvollziehen. Wenn die Lesefehler so
> häufig wären, könnte man ja nie so ne Platte lesen.
Simple Mathematik: <http://blogs.zdnet.com/storage/?p=162>
>> Da ist man mit Standard-PC-Schraddel-Hardware bzw. Standard-SATA-
>> Controller und Software-RAID eingermaßen aus dem Schneider bzw.
>> Ersatz flink besorgt und ohne Probleme ausgetauscht.
>
> Ja. Aber da hatte ich bisher immer etwas Hemmungen wegen afp.
Solange nur Macs bedient werden, kann man guten Gewissens Netatalk
einsetzen (man rennt da nur dann in Probleme, wenn andere Filesharing-
Daemons wie Samba oder NFS oder auch lokale User auf dem Server
innerhalb Netatalk-Shares herumwurschteln). Und Netatalk in beklickbar
gibt es in Form von bspw. FreeNAS.
FreeNAS 0.7 bringt Support für ZFS mit. Und wie unaufwändig das Ganze
ist, davon kann man sich simpel überzeugen, indem man den Kram mal
innerhalb einer VM installiert und bisserl beklickt (ist ja komplett per
Webbrowser "administrierbar"):
<http://www.freenas.org/index.php?option=com_versions&Itemid=51>
> Ausserdem war, als ich das letzte mal sowas gemacht habe noch md das
> höchste der Gefühle und damit wurde ich auch nicht so richtig warm.
Allerdings. Ich bin ja auch kein Freund von postmateriellem Gebastel
(bzw. reicht mir eben jenes schon beruflich -- das will man sich dann
nicht auch noch für den eigenen Betrieb antun). Aber es hat sich da
schon zwischenzeitlich bisserl was getan.
> Drobo ist halt schon verlockend einfach.
Tja, wären da nicht ziemlich finstere Schattenseiten, dann hätte ich
auch schon sowas rumstehen.
Gruss,
Thomas
Thomas Kaiser
> Markus Elsken wrote:
>
>> Ein Ersatz-Drobo(pro) ist innerhalb von einem, max. zwei Werktagen
>> da, das ist vertretbar.
>
> Ich hatte Thomas jetzt so verstanden, dass man ruhig mal überlegen
> soll, was passieren könnte, wenn das Raid-Gehäuse - egal von welchem
> Hersteller - so nicht mehr lieferbar ist und es - warum auch immer -
> keine kompatible Alternative gibt
Naja, es reicht schon, wenn das Ding oder ein triviales Teil wie dessen
Netzteil ausfällt. Und man dann feststellt, daß der Hersteller dieses
Teil gar nicht mehr auf Lager hat, weil "end of live" oder grad
Lieferengpaß oder was-auch-immer. Die angepeilte Zielgruppe der Drobos
checkt doch überhaupt nicht, daß sowas wie eine garantierte Ersatzteil-
versorgung in einem solch kritischen Bereich auch 'ne nähere Betrachtung
wert wäre.
> Eine handelsübliche SATA-Platte mit Standard-FS bekommt man immer
> irgendwie angeschlossen und gelesen.
Exakt.
> Wobei man natürlich abwägen muss zwischen relativ häufigem Platten-
> verlust und seltenerem Controler- oder Gehäuseausfall. Aber man sollte
> sich eben im Klaren sein, dass Murphy auch hier zuschlagen kann und
> man nur den SPoF von den Platten an eine andere Stelle verschoben hat.
Das kann ich speziell nach den Erlebnissen diesen Sommer bei diversen
Kunden nur mehrfach unterstreichen. Da sind zigfach RAID-Controller
hopps gegangen. Und das nicht spektakulär und mit 'nem Knall sondern
schleichend. Fiese Sache, weil man nicht wirklich draufkommt. Und dann
eben feststellt, daß es gar nicht so einfach ist, ein Enclosure oder
auch nur einen passenden Ersatz-Controller aufzutreiben. Und sich dann
eben bewußt wird, welche Sorte SPoF man sich damit ans Bein bindet.
Gruss,
Thomas
Markus Elsken
Patrick M. Hausen schrieb:
> Bei einem Drobo, Thecus oder auch nur einem RAID-Hostadapter
> ist ggf. in 2 Jahren aber gar kein Ger�t dieser Firma mehr
> beschaffbar und die Daten komplett weg.
Das ist dann zwar �rgerlich, aber dann werden die Platten halt in ein
anderes NAS geschraubt, dort neu eingerichtet und die Daten vom Backup
zur�ckgespielt. Datenverlust: maximal zwischen letztem Backup und
Ausfallzeitpunkt. Das ist verschmerzbar...
mfg Markus
Goetz Hoffart
> Ein Sonnet Fusion D500P - JBOD f�r 5 Platten mit eSATA Portmultiplier.
> Hat zwar auch RAID an Bord, das mu� man aber nicht benutzen.
�h, aber warum ~500 EUR f�r ein "dummes" eSATA-5-Tray-Geh�use ausgeben?
�Da gibt's doch auch was von Stardom.�
Goetz Hoffart
> Da passen 8 entkoppelte/ged�mmte Platten rein, weil 8 x 5,25"
> nutzbar.
In 8x 5,25" bekommt man ohne gr��ere Schmerzen auch 11x 3,5" Platten im
Wechselrahmen:
2x Icydock MB-454SPF f�r je 4 Platten
1x Icydock MB-453SPF f�r 3 Platten
Oder man nimmt 2x MB-454SPF f�r insgesamt 8 Platten plus ein
LTO4-Laufwerk volle H�he, macht auch wieder 8x 5,25".
Marc Stibane
> ich lieb�ugele mit einem Drobo.
Da klingelt bei mir was...
> Die M�glichkeit, 16 TB virtuell anzulegen und dann
> einfach Platten nachzuschieben ist schon ziemlich cool.
War das nicht die Kiste, die sich unrettbar aufh�ngt mit Totalverlust
der Daten, wenn man eben nicht rechtzeitig eine Platte nachschiebt und
der existierende Plattenplatz �berl�uft?
Ah ja, Thomas hat den Link:
<http://www.suitetake.com/2009/08/21/the-dark-side-of-drobo/>
IMHO sollte das Teil bei �berlauf gerne die Arbeit einstellen bzw. auf
Read-Only umschalten (f�r Userdaten) - aber kompletter Datenverlust?
W�rde ich NIE kaufen. NIE!
--
In a world without walls and fences,
who needs windows and gates?
Patrick Kormann
> IMHO sollte das Teil bei �berlauf gerne die Arbeit einstellen bzw. auf
> Read-Only umschalten (f�r Userdaten) - aber kompletter Datenverlust?
>
> W�rde ich NIE kaufen. NIE!
Was bringt euch eigentlich zur �berzeugung, dass das Problem sich nicht
beheben l�sst?
Patrick Kormann
> Simple Mathematik: <http://blogs.zdnet.com/storage/?p=162>
Ja ich habe den Artikel gelesen. Indess ist das kein Beweis dafür, dass
die Prämisse stimmt. Woher will der Autor 2007 wissen, wie die
Fehlerwahrscheinlichkeit bei 2009er Platten ist?
Wenn wirklich pro 12 TB ein nicht korrigierbarer Fehler auftritt,
müssten wir ja 'dauernd' in einen reinlaufen und nicht nur beim
wiederherstellen eines RAIDs.
> Solange nur Macs bedient werden, kann man guten Gewissens Netatalk
> einsetzen (man rennt da nur dann in Probleme, wenn andere Filesharing-
> Daemons wie Samba oder NFS oder auch lokale User auf dem Server
> innerhalb Netatalk-Shares herumwurschteln). Und Netatalk in beklickbar
> gibt es in Form von bspw. FreeNAS.
>
> FreeNAS 0.7 bringt Support für ZFS mit. Und wie unaufwändig das Ganze
> ist, davon kann man sich simpel überzeugen, indem man den Kram mal
> innerhalb einer VM installiert und bisserl beklickt (ist ja komplett per
> Webbrowser "administrierbar"):
>
> <http://www.freenas.org/index.php?option=com_versions&Itemid=51>
In der Tat, vielleicht hätte man sich das mal anschauen können.
Andererseits, eigentlich bin ich vom PC- zum Macuser geworden, weil ich
mein Leben nicht mehr mit Computerbasteleien 'verschwenden' will... Nun
gut, manchmal juckt es immer noch ;)
> Allerdings. Ich bin ja auch kein Freund von postmateriellem Gebastel
> (bzw. reicht mir eben jenes schon beruflich -- das will man sich dann
> nicht auch noch für den eigenen Betrieb antun). Aber es hat sich da
> schon zwischenzeitlich bisserl was getan.
Naja, damit hätte ich rechnen müssen ;)
> Tja, wären da nicht ziemlich finstere Schattenseiten, dann hätte ich
> auch schon sowas rumstehen.
Tja, ich hoff mal auf das Beste ;)
Patrick M. Hausen
In meinem Heim-Szenario *ist* die Kiste das Backup-Medium.
Oder worauf sicherst Du den Inhalt Deines Drobo wenn nicht
auf ein zweites solches oder �hnliches Ger�t? Mit den Datenmengen
kommt doch keine Bandtechnik mehr mit.
Patrick M. Hausen
> Patrick M. Hausen <hau...@nospam.de> wrote:
>
> > Ein Sonnet Fusion D500P - JBOD f�r 5 Platten mit eSATA Portmultiplier.
> > Hat zwar auch RAID an Bord, das mu� man aber nicht benutzen.
>
> �h, aber warum ~500 EUR f�r ein "dummes" eSATA-5-Tray-Geh�use ausgeben?
> �Da gibt's doch auch was von Stardom.�
Weil es leise ist. Wenn nicht, kriegt es der H�ndler gleich zur�ck.
Das von Stardom kenne ich. Das l�rmt. Abgesehen davon: 420 netto.
Thomas Kaiser
> Thomas Kaiser schrieb:
>
>> Simple Mathematik: <http://blogs.zdnet.com/storage/?p=162>
>
> Ja ich habe den Artikel gelesen. Indess ist das kein Beweis dafür,
> dass die Prämisse stimmt. Woher will der Autor 2007 wissen, wie die
> Fehlerwahrscheinlichkeit bei 2009er Platten ist?
Äh, weil die Entwicklung offensichtlich ist? Weil man Desktop-SATA-
Platten quasi nachgeschmissen bekommt und man gar nicht erwarten _darf_,
daß sich an diesen Parametern allzu viel ändert? Und mit steigender
Kapazität je nach Implementierung des Rebuild-Prozesses im Fehlerfall
eine konstante URE eben immer "tödlicher" wird ganz unabhängig davon,
daß wir heute Platten mit Fehlerraten _laut Datenblatt_ kaufen können,
die sich um mehr als eine Zehnerpotenz unterscheiden.
Hier ist noch ein Artikel von 2007, der das Ganze mit Mathematik
unterfüttert:
<http://blogs.sun.com/relling/entry/a_story_of_two_mttdl>
Wohlgemerkt: Das Ganze ist nur Stochastik, die zudem auf Werten aus
Datenblättern basiert. Man kann damit nur Wahrscheinlichkeiten
berechnen. Aber diese Rechnungen fallen halt nunmal eindeutig aus:
RAID-5 in dummen Implementierungen taugt heute, d.h. auf Basis aktueller
Plattenkapazitäten im Verbund, nicht mehr. Fertig, aus, Ende.
> Wenn wirklich pro 12 TB ein nicht korrigierbarer Fehler auftritt,
> müssten wir ja 'dauernd' in einen reinlaufen und nicht nur beim
> wiederherstellen eines RAIDs.
Ja, Moment. Es geht nicht um irgendwie "12 TB" sondern um die zu
errechnende Größe einer Gesamtkapazität *innerhalb eines geschlossenen*
*Systems*, das per einfacher Parity auf Redundanz setzt und dieser
Redundanz eben verlustig gegangen ist (ein RAID, das noch in redundantem
Zustand ist, macht ja so ein gekipptes Bit "eigentlich" nix aus -- genau
dafür ist ja die ganze Parity-Berechnerei gut). Abermals: Stochastik.
Gruss,
Thomas
Markus Elsken
Patrick M. Hausen schrieb:
> In meinem Heim-Szenario *ist* die Kiste das Backup-Medium.
> Oder worauf sicherst Du den Inhalt Deines Drobo wenn nicht
> auf ein zweites solches oder �hnliches Ger�t? Mit den Datenmengen
> kommt doch keine Bandtechnik mehr mit.
Die Daten auf dem Drobo sind haupts�chlich Mediendaten, d.h. Musik,
Fotos, Filme, aber auch Disk-Images - halt alles, was Platz braucht. Der
Kram ist so in Ordnern sortiert, dass so ein Ordner bequem auf eine
Platte (ich habe so ein Dock, wo "nackte" Platten reingestellt werden)
passt und immer, wenn sich etwas wesentliches �ndert wird gesichert.
Diese Platten lagern dann in ihren Transportverpackungen (diese netten
Trays von Samsung) im Schrank.
mfg Markus
Patrick M. Hausen
Patrick M. Hausen <hau...@nospam.de> wrote:
> Goetz Hoffart <use...@hoffart.de> wrote:
> > �h, aber warum ~500 EUR f�r ein "dummes" eSATA-5-Tray-Geh�use ausgeben?
> > �Da gibt's doch auch was von Stardom.�
>
> Weil es leise ist. Wenn nicht, kriegt es der H�ndler gleich zur�ck.
> Das von Stardom kenne ich. Das l�rmt. Abgesehen davon: 420 netto.
Das war aber trotzdem ein guter Hinweis von Dir.
Warum nicht ein Icy Dock f�r 5 Platten in einen kleinen Tower?
Ich schau mal weiter.
Patrick Kormann
> Äh, weil die Entwicklung offensichtlich ist? Weil man Desktop-SATA-
> Platten quasi nachgeschmissen bekommt und man gar nicht erwarten _darf_,
> daß sich an diesen Parametern allzu viel ändert? Und mit steigender
> Kapazität je nach Implementierung des Rebuild-Prozesses im Fehlerfall
> eine konstante URE eben immer "tödlicher" wird ganz unabhängig davon,
> daß wir heute Platten mit Fehlerraten _laut Datenblatt_ kaufen können,
> die sich um mehr als eine Zehnerpotenz unterscheiden.
Was ist offensichtlich? Wenn die Technik alle 18 Monate die Kapazität
verdoppeln kann, heisst das doch nicht, dass die
Fehlerwahrscheinlichkeit gleich bleiben muss. DRAM war früher auch
wesentlich fehleranfälliger, obwohl die Kapazität Faktor x tausend
kleiner war.
> Wohlgemerkt: Das Ganze ist nur Stochastik, die zudem auf Werten aus
> Datenblättern basiert. Man kann damit nur Wahrscheinlichkeiten
> berechnen. Aber diese Rechnungen fallen halt nunmal eindeutig aus:
> RAID-5 in dummen Implementierungen taugt heute, d.h. auf Basis aktueller
> Plattenkapazitäten im Verbund, nicht mehr. Fertig, aus, Ende.
Ja, dann liegt aber die Betonung auf dumme Implementierung. Wie weit
Datenblättern in der Beziehung zu trauen ist weiss ich halt auch nicht,
da geht man vielleicht auch von 'absolut worst case' aus.
> Ja, Moment. Es geht nicht um irgendwie "12 TB" sondern um die zu
> errechnende Größe einer Gesamtkapazität *innerhalb eines geschlossenen*
> *Systems*, das per einfacher Parity auf Redundanz setzt und dieser
> Redundanz eben verlustig gegangen ist (ein RAID, das noch in redundantem
> Zustand ist, macht ja so ein gekipptes Bit "eigentlich" nix aus -- genau
> dafür ist ja die ganze Parity-Berechnerei gut). Abermals: Stochastik.
Ne, einem RAID nicht, aber jeder anderen Anwendung schon. Selbst wenn du
die Fehlerwahrscheinlichkeit durch 10 Teilst, weil nur eine Platte im
Spiel ist, müssten wir ja wöchentlich verfälschte Daten haben, wenn in
einem RAID beim Recover 'mit grosser Wahrscheinlichkeit' ein Lesefehler
auftritt. Ich kenne genug Leute, die speichern ihre Daten auf RAID-0.
Thomas Kosch
> In meinem Heim-Szenario *ist* die Kiste das Backup-Medium.
> Oder worauf sicherst Du den Inhalt Deines Drobo wenn nicht
> auf ein zweites solches oder �hnliches Ger�t? Mit den Datenmengen
> kommt doch keine Bandtechnik mehr mit.
Das halte ich f�r ein Ger�cht.
Ob dem typischen Heimanwender dagegen seine Daten ein Ultrium 4/5
Laufwerk wert sind steht auf einem anderen Blatt.
ttyl8er, t.k.
--
Life is Xerox, and you're just a copy
Goetz Hoffart
> Ob dem typischen Heimanwender dagegen seine Daten ein Ultrium 4/5
> Laufwerk wert sind steht auf einem anderen Blatt.
Die Leute sind ja auch bereit 800-1000 EUR f�r den Speicher auszugeben
-- die 1400 f�r ein LTO4 sind auch nicht gro� anders.
Thomas Kaiser
> Thomas Kaiser schrieb:
>
>> Äh, weil die Entwicklung offensichtlich ist? Weil man Desktop-SATA-
>> Platten quasi nachgeschmissen bekommt und man gar nicht erwarten
>> _darf_, daß sich an diesen Parametern allzu viel ändert? Und mit
>> steigender Kapazität je nach Implementierung des Rebuild-Prozesses im
>> Fehlerfall eine konstante URE eben immer "tödlicher" wird ganz
>> unabhängig davon, daß wir heute Platten mit Fehlerraten _laut
>> Datenblatt_ kaufen können, die sich um mehr als eine Zehnerpotenz
>> unterscheiden.
>
> Was ist offensichtlich? Wenn die Technik alle 18 Monate die Kapazität
> verdoppeln kann, heisst das doch nicht, dass die
> Fehlerwahrscheinlichkeit gleich bleiben muss.
Tut sie aber, was ja nur logisch ist, weil sich bei Desktop-Platten
keine Sau drum schert. Bzw. bewegt sich in exakt dem selben Rahmen, d.h.
zwischen 1 auf 10^14 Bit und 1 auf 10^15 Bit, solange es um billige
SATA-Platten geht. Die Hersteller könnten diese Fehlerrate spielend
heruntersetzen, indem sie die Kapazität verringern und intern mehr Daten
für Parity respektive ECC "opfern" (ist hoffentlich klar, daß der
Controller der Platten entsprechende 1-Bit-Fehler schon autark erkennen
bzw. sogar korrigieren kann? D.h. wenn 'ne Desktop-Platte überhaupt
meint "Lesefehler", dann sind's schon mindestens 2 Bit, die gekippt
sind)
Nur ein Beispiel für Vergleiche zwischen den Herstellern:
<http://permabit.wordpress.com/2008/08/20/are-fibre-channel-and-scsi-drives-more-reliable/>
>> Wohlgemerkt: Das Ganze ist nur Stochastik, die zudem auf Werten aus
>> Datenblättern basiert. Man kann damit nur Wahrscheinlichkeiten
>> berechnen. Aber diese Rechnungen fallen halt nunmal eindeutig aus:
>> RAID-5 in dummen Implementierungen taugt heute, d.h. auf Basis
>> aktueller Plattenkapazitäten im Verbund, nicht mehr. Fertig, aus,
>> Ende.
>
> Ja, dann liegt aber die Betonung auf dumme Implementierung.
Dumme Implementierung meint die Notwendigkeit, bei einem RAID-5, das neu
aufgebaut werden muß, eben jedes verdammte Bit auf allen Platten lesen
zu *müssen*, weil der Rebuild andernfalls nicht stattfinden kann.
> Wie weit Datenblättern in der Beziehung zu trauen ist weiss ich halt
> auch nicht, da geht man vielleicht auch von 'absolut worst case' aus.
LOL, naja siehe die berühmte "Mean time to failure" -- MTFF. Da zeichnet
die Praxis ein anderes bzw. etwas drastischeres Bild als die
Datenblätter der Hersteller:
<http://www.cs.cmu.edu/~bianca/fast/index.html>
>> Ja, Moment. Es geht nicht um irgendwie "12 TB" sondern um die zu
>> errechnende Größe einer Gesamtkapazität *innerhalb eines
>> geschlossenen* *Systems*, das per einfacher Parity auf Redundanz
>> setzt und dieser Redundanz eben verlustig gegangen ist (ein RAID, das
>> noch in redundantem Zustand ist, macht ja so ein gekipptes Bit
>> "eigentlich" nix aus -- genau dafür ist ja die ganze
>> Parity-Berechnerei gut). Abermals: Stochastik.
>
> Ne, einem RAID nicht, aber jeder anderen Anwendung schon. Selbst wenn du
> die Fehlerwahrscheinlichkeit durch 10 Teilst, weil nur eine Platte im
> Spiel ist, müssten wir ja wöchentlich verfälschte Daten haben, wenn in
> einem RAID beim Recover 'mit grosser Wahrscheinlichkeit' ein Lesefehler
> auftritt.
Also nochmal. Alles nur Stochastik: Du weißt laut Datenblatt wie hoch
die Wahrscheinlichkeit dafür ist, daß auf x gelesene Bits ein defektes
kommt (bspw. 1 auf 10^14). Du weißt, daß Du bei einem RAID-5 im Falle
des Falles (Controller schmeißt eine Platte raus) jeden einzelnen Block
aller Platten lesen *mußt*, um das Ganze wieder sinnig rekonstruieren zu
können.
Jetzt kannst Du ganz simpel ausrechnen, wie hoch die Wahrscheinlichkeit
ist, bei einer Gesamtkapazität von X Byte einen Lesefehler zu bekommen
bzw. kannst andererseits wiederum ganz simpel eine Gesamtkapazität
berechnen, ab der statistisch gesehen (basierend auf ebensolchen
statistischen Angaben aus Datenblättern) die Wahrscheinlichkeit eines
solchen Lesefehlers 1 übersteigt, d.h. dieser dann einfach mal so eben
auftritt... und dann den Rebuild-Prozeß stoppen lassen würde --> alles
futsch.
Die ganze RAID-Chose ist nur Stochastik. Man errechnet und gewichtet
verschiedene Wahrscheinlichkeiten (die, daß eine Platte hopps geht oder
die, daß ein Controller hopps geht), setzt diese mit Kosten und
Zeitfenstern in Relation und stellt sich ein System hin, mit dem man die
diversen Ausfallwahrscheinlichkeiten passend abfedert (natürlich nur in
einer idealen Welt -- in der Praxis und gerade im Privat- bzw.
SOHO-Bereich denkt niemand über sowas nach -- da geht's immer nur um's
gute Gefühl bzw. eine trügerische/falsche Pseudo-Sicherheit "mit RAID
kann ja nix mehr passieren")
Was bedeuten Stochastik/Statistik für den konkreten Einzelfall? Genau,
gar nix. Oder andersrum, wenn ich eine 2 TByte-Platte mit einer vom
Hersteller spezifizierten Lesefehlerrate von 1 auf 10^14 gelesenen Bits
habe (das macht dann diese zu erwartenden 12,5 TByte Datenmenge, ab der
die Wahrscheinlichkeit eines Lesefehlers über 1,0 krabbelt), dann
bedeutet das, daß statistisch gesehen ein Lesefehler auftreten _sollte_
(laut Datenblatt), wenn ich die Platte das siebte mal komplett
vollgeschrieben habe und wieder am Auslesen bin. Aber nicht, wenn ich
diese eine Platte betrachte sondern nur die Gesamtheit aller Platten
dieser Baureihe. Statistik eben.
Wenn man die Daten solcher Platten sammelt bzw. sammeln könnte (manche
haben das ja getan -- siehe die Google-Untersuchung oder die obige der
Carnegie Mellon University), dann könnte man im Nachhinein auf Basis
realer Datenfehlerraten vielleicht eine konkretere Wahrscheinlichkeit
für einen Lesefehler ermitteln. Die abermals genau nichts bzgl.
konkreter Einzelfälle aussagt.
Nochmal zu Deinem obigen "müssten wir ja wöchentlich verfälschte Daten
haben" im Zusammenhang mit Statistik. Auch Du wirst schon mal erlebt
haben, daß Festplatten ausfallen (ich erlebe das recht häufig bei
Kunden, die die Dinger aus ihren RAIDs reißen und durch Frischware
ersetzen). Genau so ein Ausfall ist gekennzeichnet von einer besonders
drastischen Art von Lesefehler: Nix geht mehr. Und davor ist es meist
so, daß die Lesefehler sich schon bemerkbar machen, obwohl die Platte an
sich noch läuft. Auch diese "Ausreißer" sind wesentlicher Teil der
Statistik.
Oder Beispiel Oktoberfest: Wenn 5,7 Mio. Besucher jetzt 6,5 Mio. Maß
Bier gesoffen haben, dann bedeutet das nicht, daß man auf der Wiesn
exorbitant viele betrunkene 3-Jährige hätte sehen "müssen" (denen fast
ein Liter Wiesn-Bier [1] sicher fataler einfährt als dem typischen
Bierzeltbesucher)
> Ich kenne genug Leute, die speichern ihre Daten auf RAID-0.
Na denn...
Gruss,
Thomas
[1] Die statistischen 1,14 Maß Bier je Besucher gelten aufgrund
statistisch wohl nur zu 80%-90% gefüllten Maßkrügen nicht viel ;-)
Thomas Kosch
> Thomas Kosch <no_...@schuckeduster.org> wrote:
>
> > Ob dem typischen Heimanwender dagegen seine Daten ein Ultrium 4/5
> > Laufwerk wert sind steht auf einem anderen Blatt.
>
> Die Leute sind ja auch bereit 800-1000 EUR f�r den Speicher auszugeben
Ja.
> -- die 1400 f�r ein LTO4 sind auch nicht gro� anders.
Doch. Ist es
Das eben jedesmahl eine Heidenarbeit ist den Leuten klar zu machen das
das eben soviel kostet und die beiden 79 Euro Festplatten eben keine
Datensicherung sind.
Der letzte Budgetplan den ich gesehen habe sah f�r 2 Server 7kEur vor,
und 500 Euro f�r die Backupl�sung (Windows Server-Sicherung + 2x2TB
Platte vom Kistenschieber um die Ecke)
Und privat sieht das im Prinzip genau so aus.
Heiner Veelken
> Jetzt kannst Du ganz simpel ausrechnen, wie hoch die Wahrscheinlichkeit
> ist, bei einer Gesamtkapazit�t von X Byte einen Lesefehler zu bekommen
> bzw. kannst andererseits wiederum ganz simpel eine Gesamtkapazit�t
> berechnen, ab der statistisch gesehen (basierend auf ebensolchen
> statistischen Angaben aus Datenbl�ttern) die Wahrscheinlichkeit eines
> solchen Lesefehlers 1 �bersteigt, d.h. dieser dann einfach mal so eben
> auftritt... und dann den Rebuild-Proze� stoppen lassen w�rde --> alles
> futsch.
Na, die Wahrscheinlichkeit wird "1" wohl nich �bersteigen, oder? Ich
denke, dass man das so ermittelt:
p:=Wahrscheinlichkeit eines falsch gelesenen Bits (sei hier 1/1000)
(1-p): Wahrscheinlichkeit eines richtig gelesenen Bits (hier also 0,999)
A:= Anzahl der Ereignisse (Bits lesen, sei hier 500)
(1-p)^�: Wahrscheinlichkeit, alle bits richtig zu lesen (wird hier 61%)
1-(1-p)^�: Wahrscheinlichkeit, nicht alle bits richtig zu lesen (wird
hier 39%. Das ist nat�rlich schon "relativ wahrscheinlich".
Wenn wir jetzt die "Festplatte" so bauen,/kaufen, dass p nur noch
1/10000 ist, sinkt die Wahrscheinlichkeit, nicht alle bits richtig zu
lesen auf 5%.
--
Gruss Heiner
Joe Kotroczo
"Goetz Hoffart" <use...@hoffart.de> wrote:
> Thomas Kosch <no_...@schuckeduster.org> wrote:
>
>> Ob dem typischen Heimanwender dagegen seine Daten ein Ultrium 4/5
>> Laufwerk wert sind steht auf einem anderen Blatt.
>
> Die Leute sind ja auch bereit 800-1000 EUR f�r den Speicher auszugeben
> -- die 1400 f�r ein LTO4 sind auch nicht gro� anders.
Und die Preise f�r die Tapes? So um die $100 pro Tape (800 GB bei LTO4),
oder?. Und Tape einmal komplett f�llen dauert 1,8 Stunden, oder? Und danach
h�ndisch das n�chste Tape ins Laufwerk. Wer tut sich das freiwillig an?
--
Joe Kotroczo kotr...@mac.com
Marc Stibane
Einen solch kritischen Bug sollte der Hersteller innerhalb weniger Tage
beheben. Kompletter Datenverlust ist doch der Super-GAU, um mal in der
Sprache unserer Massenmedien zu reden...
Und das h�tten die schon beim Entwickeln merken m�ssen, bevor ein
einziges Ger�t selbst beim Beta-Tester gelandet w�re. Sowas h�tte NIE
beim echten Kunden auftreten d�rfen.
Sorry, aber da habe ich null Verst�ndnis. Echt nicht.
Thomas Kaiser
> Thomas Kaiser <Thomas...@phg-online.de> wrote:
>
>> Jetzt kannst Du ganz simpel ausrechnen, wie hoch die
>> auf ebensolchen statistischen Angaben aus Datenblättern) die
>> Wahrscheinlichkeit eines solchen Lesefehlers 1 übersteigt, d.h.
>
> Na, die Wahrscheinlichkeit wird "1" wohl nich übersteigen, oder?
Ach, Statistik/Stochastik kapiert doch eh keiner, v.a. was man daraus
einerseits ableiten _kann_ und andererseits _sollte_. :-)
Nenn' die 1 da oben einfach die "Anzahl von Lesefehlern". Und die
statistische Erwartung für einen Lesefehler bei einer Fehlerrate von 1
auf 1^14 (ein Fehler auf 100.000.000.000.000 gelesene Bits) beträgt eben
1 auf ca. 12 Tbyte oder 2 auf 24 TByte oder 0,5 auf 6 TByte oder 0,16
auf 2 TByte.
Ja, 0,16 _statistische_ Lesefehler, wenn man eine stinknormale
handelsübliche 2 TByte-Platte einmal komplett vollschreibt und wieder
ausliest. Nein, das bedeutet eben nicht, daß 0,16 Bits kaputt sind.
Gruss,
Thomas, noch anmerkend, daß die aktuellen dicken Platten von WD und
Samsung alle Fehlerraten *laut Datenblatt* haben, die 'ne Zehnerpotenz
kleiner ausfallen...
Goetz Hoffart
> Und die Preise f�r die Tapes? So um die $100 pro Tape (800 GB bei LTO4),
> oder?.
Oder. Eher so bei 43 EUR brutto pro Band.
> Und Tape einmal komplett f�llen dauert 1,8 Stunden, oder?
Etwas �ber 2.
Wie lange braucht denn eine Festplatte? Ein Ultrium 4 schafft locker 100
MB/s. Das kann l�ngst nicht jede Platte (wahlfrei) liefern.
> Und danach h�ndisch das n�chste Tape ins Laufwerk. Wer tut sich das
> freiwillig an?
Jeder, der ein Backup will? Und sich keinen Autoloader leisten will?
Ich kann das "B�nder sind langsam und teuer" nicht mehr h�ren. Nur weil
die Vorurteile die selben bleiben, bleibt die Entwicklung ja nicht
stehen. Klar kostet das alles Geld und es gibt F�lle, bei denen andere
L�sungen als B�nder gewinnen. Allzu h�ufig sind die hier aber nicht,
v.a. nicht bei gr��eren Datenmengen.
Thomas Kosch
> On 06/10/2009 15:04, in article 1j769xs.a4pn3j1itnh6aN%use...@hoffart.de,
> "Goetz Hoffart" <use...@hoffart.de> wrote:
> > Die Leute sind ja auch bereit 800-1000 EUR f�r den Speicher auszugeben
> > -- die 1400 f�r ein LTO4 sind auch nicht gro� anders.
>
> Und die Preise f�r die Tapes? So um die $100 pro Tape (800 GB bei LTO4),
Ich weis ja nicht bei welcher apotheke du kaufst, aber hier liegt der
�bliche Preis bei 40$
> oder?. Und Tape einmal komplett f�llen dauert 1,8 Stunden, oder? Und danach
> h�ndisch das n�chste Tape ins Laufwerk. Wer tut sich das freiwillig an?
Wer als Homeuser t�glich 800 GB Daten sichert, sollt vielleicht mal
seine Sicherungsstrategie �berdenken.
Detlev Bartsch
> Was bringt euch eigentlich zur �berzeugung, dass das Problem sich nicht
> beheben l�sst?
Vielleicht die in dem Artikel geschilderte Antwort der Hotline?
Die scheinen diese Funktion ja eher als Feature denn als Bug anzusehen.
Klar kann man die Verantwortung f�r einen Speicher�berlauf auf den
Anwender abw�lzen, der soll halt rechtzeitig neue Platten einschieben,
aber wenn man sich schon "Datensicherheit" so auf die Fahnen schreibt,
dann ist eine Software, die nicht mal trivial auf freien Speicher pr�ft,
sondern die Daten ins Nirwana schreibt, schon so etwas wie der
Super-GAU.
Tsch�ss
db
Patrick Kormann
> Patrick Kormann wrote:
>
>> Was bringt euch eigentlich zur �berzeugung, dass das Problem sich
>> nicht beheben l�sst?
>
> Vielleicht die in dem Artikel geschilderte Antwort der Hotline?
Sorry, aber die Hotline ist f�r mich nicht massgebend. Ich weiss auch
nicht, ob der Fehler gefixt wird oder nicht (ich nehme an: ja), ob ja
oder nein wird aber sicher nicht von der Hotline abh�ngen.
Robert Welz
Herzlichen Dank f�r diesen wunderbaren Test und diesen Thread!
gr�sse,
Robert
Patrick Kormann
> Patrick Kormann <sir...@hotmail.com> wrote:
>
> Herzlichen Dank f�r diesen wunderbaren Test und diesen Thread!
Gern geschehen (Ernst gemeint?) - ein wunderbarer Test sieht IMHO anders
aus und ich habe auch vor noch weitere Tests machen. Ich bin n�mlich der
Meinung bei meinen ersten Tests sei der Drobo echt schnell gewesen und
jetzt nur noch 'naja', aber ich habe zur Zeit nicht wirklich die Zeit
dem auf den Grund zu gehen. Gut, so wirklich kann ich das auch gar
nicht, denn eine der ersten Taten f�r einen aussagekr�ftigen Test w�re
wohl 'alles nochmal l�schen und gucken ob das einen Einfluss auf die
Geschwindigkeit hat'...
Robert Welz
Ich habe in den letzten Tagen intensiv in englischsprachigen Foren
recherchiert und folgenden Eindruck gewonnen: Der Drobo schaufelt die
Daten intern im laufenden Betrieb so hin , dass immer doppelte oder
dreifache Redundanz besteht. In dieser Zeit sind die Daten nicht
redundant. Ausserdem ist in dieser Zeit die Netzwerkgeschwindigkeit
herangesetzt.
Zur iSCSI Geschwindigkeit unter Macs gibt es keine Aussage, aber unter
Windows wobei es dort Probleme gibt, die mit irgendwelchen Fremdtreibern
gel�st werden (m�ssen). Ob es auch ein Linux Treiber gibt habe ich nicht
in Erfahrung bringen k�nnen. Der w�re f�r viele das Ei des Kolumbus,
denn dann kann man das Teil �ber Sharing unter Linux ansprechen, auf
Servern, die sowieso st�ndig laufen.
Die Partitionsgr�sse des Drobos wird beim Formatieren eingegeben, dabei
ist das die Gr�sse die erreicht werden soll, wenn dass Teil voll
best�ckt ist. �berschreiten die hochgeladenen Daten aber die Grenze der
vorhandenen Festplatten, dann f�llt das Ding aus und alle Daten sind
weg. Der physikalisch frei Festplattenspeicher wird nicht im Finder
angezeigt, es gibt keine Warnung und nichts, nur ein Programm von
data-robotics, dass man beachten muss.
Desweiteren ist das Teil nicht wirklich netzwerkf�hig, nur �ber Sharing,
wobei dann immer ein Computer mitlaufen muss.
SPoF: Dann, wenn der Drobo kaputt ist, kommt man gar nicht mehr an seine
Daten, man muss sich auf die Verarbeitungsqualit�t des Herstellers
verlassen k�nnen.
Allerdings scheint sich das Teil mit �ber 60000 Einheiten bisher gut
verkauft zu haben, sodass man sich �ber den Support keine Gedanken
machen muss.
-> Drobo: Wir sehen uns Weihnachten.
Gr�sse,
Robert
Patrick Kormann
> Ich habe in den letzten Tagen intensiv in englischsprachigen Foren
> recherchiert und folgenden Eindruck gewonnen: Der Drobo schaufelt die
> Daten intern im laufenden Betrieb so hin , dass immer doppelte oder
> dreifache Redundanz besteht. In dieser Zeit sind die Daten nicht
> redundant. Ausserdem ist in dieser Zeit die Netzwerkgeschwindigkeit
> herangesetzt.
Diesen Zustand zeigt die Applikation allerdings an. Ist bei mir zur Zeit
nicht der Fall.
> Zur iSCSI Geschwindigkeit unter Macs gibt es keine Aussage, aber unter
> Windows wobei es dort Probleme gibt, die mit irgendwelchen Fremdtreibern
> gel�st werden (m�ssen). Ob es auch ein Linux Treiber gibt habe ich nicht
> in Erfahrung bringen k�nnen. Der w�re f�r viele das Ei des Kolumbus,
> denn dann kann man das Teil �ber Sharing unter Linux ansprechen, auf
> Servern, die sowieso st�ndig laufen.
W�rde mich sehr wundern, wenn es keinen iSCSI Treiber f�r Linux g�be.
Ein kurzer Test mit einem alternativen iSCSI treiber f�r OS X war bei
mir allerdings nicht erfolgreich, ich habe allerdings auch nicht im Netz
gesucht wie der zu konfigurieren ist. So wie ich's versucht habe ging's
jedenfalls nicht. Was die Geschwindigkeit angeht, ich erreiche
kurzzeitig zwischen 70 und 80 MB/s beim Schreiben, das wird also wohl
das sein, was iSCSI schaffen w�rde. Mit Firewire 800 waren's �brigens
irgendwo zwischen 60 und 70 MB/s.
> Die Partitionsgr�sse des Drobos wird beim Formatieren eingegeben, dabei
> ist das die Gr�sse die erreicht werden soll, wenn dass Teil voll
> best�ckt ist. �berschreiten die hochgeladenen Daten aber die Grenze der
> vorhandenen Festplatten, dann f�llt das Ding aus und alle Daten sind
> weg. Der physikalisch frei Festplattenspeicher wird nicht im Finder
> angezeigt, es gibt keine Warnung und nichts, nur ein Programm von
> data-robotics, dass man beachten muss.
Ja. Wobei das Programm auch Mails verschickt. Das mit dem f�llt aus und
Daten sind weg - da hoffe ich noch darauf, dass sich das mal �ndert.
Was vielleicht noch interessant ist (und ein unterschied zum kleinen
Drobo) ist, dass man bis zu 16 Volumes erstellen kann, wobei jedes
wieder bis zu 16 TB gross sein kann. So habe ich z.B. f�r jeden Rechner
ein eigenes 1 TB Time Machine Volume gemacht. So konkurrenzieren sich
die Backups nicht gegenseitig.
Beim 'commiten' der �nderungen startet der Drobo neu, ansonsten ist das
sehr angenehm. Man kann so jederzeit z.B. schnell eine Testpartition
machen, ich nehm an mit Firewire w�re die dann auch bootbar. Nach dem
Test schmeisst man sie einfach wieder weg...
Etwas �rgerlicher ist, dass der Mac erst mit dem Drobo (�ber iSCSI
zumindest) kontakt aufnimmt, wenn die Droboapplikation l�uft. d.h. auch
es muss immer ein User angemeldet sein, wenn man das Ding sharen will.
> Desweiteren ist das Teil nicht wirklich netzwerkf�hig, nur �ber Sharing,
> wobei dann immer ein Computer mitlaufen muss.
Oder �ber DroboSahre, da allerdings leider nur per USB.
> SPoF: Dann, wenn der Drobo kaputt ist, kommt man gar nicht mehr an seine
> Daten, man muss sich auf die Verarbeitungsqualit�t des Herstellers
> verlassen k�nnen.
Ja, leider.
> Allerdings scheint sich das Teil mit �ber 60000 Einheiten bisher gut
> verkauft zu haben, sodass man sich �ber den Support keine Gedanken
> machen muss.
Wir werden sehen ;)
Detlev Bartsch
> Sorry, aber die Hotline ist f�r mich nicht massgebend.
Die Hotline als solche nicht, klar, aber mir scheint da eine
gewisse Grundeinstellung bei der Firma durchzuschimmern.
Wenn ich gerade mit einem System f�r Datensicherung Daten
verloren habe und mir die Hotline zu verstehen gibt, dass das
h�ufiger vorkommt, dann ... hmmm.
Tsch�ss
db
Patrick Kormann
> Wenn ich gerade mit einem System f�r Datensicherung Daten
> verloren habe und mir die Hotline zu verstehen gibt, dass das
> h�ufiger vorkommt, dann ... hmmm.
... hoffe ich, dass sie f�higere Programmierer als 1st Level Supporter
haben - was gemeinhin auch so ist.
Thomas Kaiser
> Detlev Bartsch schrieb:
>
>> Wenn ich gerade mit einem System für Datensicherung Daten verloren
>> habe und mir die Hotline zu verstehen gibt, dass das häufiger
>> vorkommt, dann ... hmmm.
>
> ... hoffe ich, dass sie fähigere Programmierer als 1st Level Supporter
Und gemeinhin völlig egal ist, denn wie fit auch immer der Coder sein
mag... die richtigen Stellen sind Marketing und Produktmanagement, die
sich (schmerzhaft) an die Nase fassen lassen müssten. Die Drobos sind ja
nicht "broken by accident" sondern broken by design :-)
Gruss,
Thomas
Patrick Kormann
> Und gemeinhin völlig egal ist, denn wie fit auch immer der Coder sein
> mag... die richtigen Stellen sind Marketing und Produktmanagement, die
> sich (schmerzhaft) an die Nase fassen lassen müssten. Die Drobos sind ja
> nicht "broken by accident" sondern broken by design :-)
Und woher hast du diese Information?
Thomas Kaiser
Entschuldige mal, was sonst als eine "Design-Entscheidung" soll es denn
sein, beim Erschöpfen von physischen Resourcen (man overprovisioning)
alles in den Müll zu treten anstatt das System auf read-only zu schalten
oder runterzufahren oder irgendwas anderes non-Desktruktives zu tun?
Wenn man so ein System plant, ist das einer der zentralen Punkte, was in
genau dieser Situation zu geschehen hat.
Die Drobos legten dieses Verhalten vom Start weg an den Tag, es kommt
anscheinend auch beinahe täglich zu derlei Datenverlust-GAUs [1] und
niemand in dem Laden interessierte sich je dafür. Broken by design,
oder? Oder alles nur eine Verkettung unglücklicher Umstände,
"suboptimaler" firmeninternen Kommunikationsstrukturen, erschöpfter
"human resources" und anderes Blabla, mit dem man einen solchen Design-
Fehler kaschieren wollte?
Gruss,
Thomas
[1] <http://www.suitetake.com/2009/08/21/the-dark-side-of-drobo/>:
I was on the phone with Tech Support for about 20 minutes as we
walked through the situation and finally he informed me that if I
was sure that the drive had been filled beyond its capacity then
there was nothing to do other then to start over and reformat the
drives.
Wow! The drive system that’s touted as the safe way to store all of
your most important files has one major flaw, and most people are
not even aware of it!
While on my tech support call I asked the engineer how frequently he
received calls about this particular problem. After a big sigh he
admitted that it was nearly every day.
Patrick Kormann
> Die Drobos legten dieses Verhalten vom Start weg an den Tag, es kommt
> anscheinend auch beinahe täglich zu derlei Datenverlust-GAUs [1] und
> niemand in dem Laden interessierte sich je dafür. Broken by design,
> oder? Oder alles nur eine Verkettung unglücklicher Umstände,
> "suboptimaler" firmeninternen Kommunikationsstrukturen, erschöpfter
> "human resources" und anderes Blabla, mit dem man einen solchen Design-
> Fehler kaschieren wollte?
Naja, ich weiss es nicht, es könnte ja einfach ein Bug sein, der bisher
noch nicht korrigiert wurde. Wieso, darüber will ich nicht spekulieren,
andere Firmen haben schon ähnliche Böcke geschossen uns trotzdem war das
nicht 'by design'...
Marc Stibane
> Thomas Kaiser schrieb:
>
>
> > Die Drobos legten dieses Verhalten vom Start weg an den Tag, es kommt
> > anscheinend auch beinahe tīŋŊglich zu derlei Datenverlust-GAUs [1] und
> > niemand in dem Laden interessierte sich je dafīŋŊr. Broken by design,
> > oder? Oder alles nur eine Verkettung unglīŋŊcklicher UmstīŋŊnde,
> > "suboptimaler" firmeninternen Kommunikationsstrukturen, erschīŋŊpfter
> > "human resources" und anderes Blabla, mit dem man einen solchen Design-
> > Fehler kaschieren wollte?
>
> Naja, ich weiss es nicht, es kīŋŊnnte ja einfach ein Bug sein, der bisher
> noch nicht korrigiert wurde. Wieso, darīŋŊber will ich nicht spekulieren,
> andere Firmen haben schon īŋŊhnliche BīŋŊcke geschossen uns trotzdem war das
> nicht 'by design'...
Ich wiederhole mich eigentlich nur ungern, aber so ein katastrophaler
Bug gehīŋŊrt bemerkt und gefixt, *bevor* der erste hausfremde Betatester
das in die Hand kriegt. Vor allem, da es 100% reproduzierbar ist -
einschalten, immer mehr Daten drauf, BUMM!
*Sowas* darf einfach nicht beim Kunden passieren. Niemals.
Patrick Kormann
> Ich wiederhole mich eigentlich nur ungern, aber so ein katastrophaler
> Bug geh�rt bemerkt und gefixt, *bevor* der erste hausfremde Betatester
> das in die Hand kriegt. Vor allem, da es 100% reproduzierbar ist -
> einschalten, immer mehr Daten drauf, BUMM!
>
> *Sowas* darf einfach nicht beim Kunden passieren. Niemals.
Schon. Andererseits kann ich mit dem letzten Rest an Eigenverantwortung
f�r meine Daten durchaus umgehen.
Oliver N. Kuehlwein
Och, Patrick... Den Link hat Thomas doch schon gepostet und �fter drauf
verwiesen. War IMHO auch sehr verst�ndlich.
Trotzdem glaube ich, dass ihr aneinander vorbei redet.
Den meisten Anwendern (Sch�tzung 99,6 der Privaten, 75% der Profis)
sind ihre Daten erstmal egal. Die haben fr�her kein Backup gemacht und
heute eben auch nicht. Mit der Einf�hrung von (Billig)NAS-Ger�ten wurde
aber deren Forderung nach mehr Platz (Musiksammlung, Fotos, Filme,
irgendwelche uralten Projektdaten mit Dateiformaten, die kein Programm
mehr lesen kann) und st�ndiger �berallverf�gbarkeit erf�llt.
F�llt jetzt so ein Teil aus, so wird das manchmal sogar als Hilfe
empfunden: Endlich kann man mal die Spreu vom Weizen trennen und nur
das wichtigste zu restaurieren versuchen (Kopien von Freunden und aus
dem Internet ziehen, Ausdrucke scannen) und dem verlorenen Rest
nachweinen. Eine Trennung zwischen lebenden und toten Daten (Backup/
Archiv) hat ja sowieso nicht stattgefunden.
Und dass diese NAS-K�bel schneller den Geist aufgeben als einzelne
Festplatten merkt der Anwender eh nicht, da die meisten Daten eh nur
einmal geschrieben und nie mehr gelesen werden (aber man k�nnte ja...).
Nat�rlich hat Thomas Recht, dass sinnvolle Datenhaltung was anderes ist,
aber ein Umgang mit Computern muss ja nicht notwendigerweise produktiv
sein.
--
Oliver
Detlev Bartsch
> Schon. Andererseits kann ich mit dem letzten Rest an Eigenverantwortung
> f�r meine Daten durchaus umgehen.
Ja, wenn ich weiss, dass ich in einem Auto ohne Bremsen sitze, kann ich
mich entscheiden, wie weit ich damit fahren will.
Tsch�ss
db
Stefan
> Ja, wenn ich weiss, dass ich in einem Auto ohne Bremsen sitze, kann ich
> mich entscheiden, wie weit ich damit fahren will.
Und genau das ist der springende Punkt. Dass ein System, f�r das mit
"RAID 6" geworben wird, bei einem einfachen Platten�berlauf s�mtliche
Daten in den M�ll tritt, damit muss man schlicht nicht rechnen. Ich
denke, Drobo lebt da ziemlich gef�hrlich.
Andererseits machen's andere ja auch nicht besser: Dass z.B. Raid 5 nach
einem Plattenausfall schon bei einzigen Bitfehler nicht nur die
betroffene Datei sondern gleich die komplette Platte nicht mehr
rekonstruieren kann, ist ja ebenso skandal�s. Die Mitglieder jenes
Normungsgremiums geh�ren f�r dieses Verbrechen eigentlich schon lange
geteert und gefedert und nackt �ber den Marktplatz getrieben.
Thomas Kaiser
> Natürlich hat Thomas Recht, dass sinnvolle Datenhaltung was anderes
> ist,
So weit geh' ich ja noch gar nicht mal (in dieser konkreten Diskussion).
Es reicht ja schon, wenn Leute glauben, Billig-RAID oder Drobos hätten
was mit Datensicherheit zu tun (was erstaunlich viele eben _doch_ tun).
Und das haben diese Kistchen halt nunmal nicht. Und noch nicht mal was
mit erhöhter Datenverfügbarkeit, wie die Erfahrung lehrt.
Gruss,
Thomas
Thomas Kaiser
> Andererseits machen's andere ja auch nicht besser: Dass z.B. Raid 5
> nach einem Plattenausfall schon bei einzigen Bitfehler nicht nur die
> betroffene Datei sondern gleich die komplette Platte nicht mehr
> Normungsgremiums gehören für dieses Verbrechen eigentlich schon lange
> geteert und gefedert und nackt über den Marktplatz getrieben.
Bitte was?
RAID 5 hat(te) durchaus seine historische Berechtigung. Wie schon zigmal
geschrieben: RAID hat nix aber auch gar nix mit Datensicherheit zu tun.
Sondern (zumindest bei den redundanten Leveln) ausschließlich mit
Datenverfügbarkeit. Und da ist alles schlichtweg eine Frage der
Stochastik. Wie wahrscheinlich ist der Ausfall von was? Und was hat das
für Konsequenzen?
Bedingt durch stagnierende Fehlerraten der verwendeten Platten und
Explosion der Kapazitäten ist RAID 5 _heute_ eben keine gute Idee mehr.
Weil es die Idee mit der Datenverfügbarkeit ad absurdum führt. Und das
gilt für andere Systeme, die auf "single parity" setzen, in ähnlichem
Maße (auch wenn dort bedingt durch die Art der Parity-Berechnungen, v.a.
im Rebuild-Fall die Wahrscheinlichkeiten anders aussehen. Zum Subjekt
zurück: Hier schlägt sich Drobos BeyondRAID bspw. deutlich besser als
eine "herkömmliche" RAID 5 Implementierung. Aber auch da ist es bei
heutigen Plattenkapazitäten nur doof, auf single Parity zu setzen)
Gruss,
Thomas
Andreas Berger
> Nun lassen wir den finanziellen Aspekt mal ganz beiseite, ich lieb�ugele
> mit einem Drobo. Die M�glichkeit, 16 TB virtuell anzulegen und dann
> einfach Platten nachzuschieben ist schon ziemlich cool.
Ich habe zwar den thread �berflogen, aber noch nicht richtig
mitbekommen, was das Teil besser/sch�ner macht, als ein popeliges NAS
ala <http://www.qnap.com/de/pro_detail_feature.asp?p_id=127> (~480
Tacken und dezente heimtaugliche Netzwerk-speed).
Bei dem Tail kann man auch im laufenden Betrieb (je nach NAS-level)
gr��ere Platten nachschieben, oder bin ich gedanklich komplett daneben?
Dirk Kring
>
> Andererseits machen's andere ja auch nicht besser: Dass z.B. Raid 5 nach
> einem Plattenausfall schon bei einzigen Bitfehler nicht nur die
> betroffene Datei sondern gleich die komplette Platte nicht mehr
> rekonstruieren kann, ist ja ebenso skandal�s. Die Mitglieder jenes
> Normungsgremiums geh�ren f�r dieses Verbrechen eigentlich schon lange
> geteert und gefedert und nackt �ber den Marktplatz getrieben.
Kann ich nachf�hlen, hatten wir gerade auch.
Eine Platte aus dem RAID war kaputt und als wir sie austauschten, brach
das Mirroring ab, weil angeblich irgendwo auf den Sourceplatten ein
Sektorfehler war. Den hatten wir bis dato nicht bemerkt. Nach einem
kompletten Neustart hat der Controller zum Gl�ck fertiggespiegelt.
Logisch das die (Quell-) Platte(n) noch getauscht wird.
--
Dirk Kring
Patrick Kormann
N�, in einem Auto, das bei leerem Tank kaputt geht. W�re mir egal, mein
Tank war noch nie leer.
Patrick M. Hausen
Patrick M. Hausen <hau...@nospam.de> wrote:
> Goetz Hoffart <use...@hoffart.de> wrote:
> > Patrick M. Hausen <hau...@nospam.de> wrote:
> >
> > > Ein Sonnet Fusion D500P - JBOD f�r 5 Platten mit eSATA Portmultiplier.
> > > Hat zwar auch RAID an Bord, das mu� man aber nicht benutzen.
> >
> > �h, aber warum ~500 EUR f�r ein "dummes" eSATA-5-Tray-Geh�use ausgeben?
> > �Da gibt's doch auch was von Stardom.�
>
> Weil es leise ist. Wenn nicht, kriegt es der H�ndler gleich zur�ck.
> Das von Stardom kenne ich. Das l�rmt. Abgesehen davon: 420 netto.
Der neue Mac Mini Server w�re ja ein nettes Teil. Da dran
ein JBOD mit Firewire und ... wo war noch gleich das ZFS
f�r Snow Leo Server?
Mist!
Gru�,
Patrick
--
punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe
Tel. 0721 9109 0 * Fax 0721 9109 100
in...@punkt.de http://www.punkt.de
Gf: J�rgen Egeling AG Mannheim 108285
Andreas Berger
> Moin,
>
> Patrick M. Hausen<hau...@nospam.de> wrote:
>> Goetz Hoffart<use...@hoffart.de> wrote:
>>> Patrick M. Hausen<hau...@nospam.de> wrote:
>>>
>>>> Ein Sonnet Fusion D500P - JBOD f�r 5 Platten mit eSATA Portmultiplier.
>>>> Hat zwar auch RAID an Bord, das mu� man aber nicht benutzen.
>>>
>>> �h, aber warum ~500 EUR f�r ein "dummes" eSATA-5-Tray-Geh�use ausgeben?
>>> �Da gibt's doch auch was von Stardom.�
>>
>> Weil es leise ist. Wenn nicht, kriegt es der H�ndler gleich zur�ck.
>> Das von Stardom kenne ich. Das l�rmt. Abgesehen davon: 420 netto.
>
> Der neue Mac Mini Server w�re ja ein nettes Teil.
das alleine schon ~900 Flocken...
> Da dran
> ein JBOD mit Firewire und ... wo war noch gleich das ZFS
> f�r Snow Leo Server?
>
> Mist!
...um daraus ein NAS zu basteln? Da kann man ja wirklich vom feinsten
was richtiges kaufen.
Patrick M. Hausen
Andreas Berger <a_be...@spamfence.net> wrote:
> > Der neue Mac Mini Server w�re ja ein nettes Teil.
>
> das alleine schon ~900 Flocken...
>
> > Da dran
> > ein JBOD mit Firewire und ... wo war noch gleich das ZFS
> > f�r Snow Leo Server?
> >
> > Mist!
>
> ...um daraus ein NAS zu basteln? Da kann man ja wirklich vom feinsten
> was richtiges kaufen.
Yep. Ich hab' jetzt was gefunden. Nicht gerade klein aber
leise und mit 8 Einsch�bern f�r 3,5"-Platten:
SuperMicro - 5046A-XB
515 Euro netto, der Barebone. Zzgl. CPU, RAM, Platten nach Wunsch.
FreeBSD drauf, oder gleich OpenSolaris wegen RAIDZ3 - mal sehen.
Hat jemand Erfahrung mit Samba und/oder Netatalk auf OpenSolaris?
Nicht im Mischbetrieb ;-) Ich hab' einen Windows benutzenden
Kollegen, bei dem w�re Samba der Server der Wahl, bei mir Netatalk.
Ralph Böhme
> Hi!
> Andreas Berger <a_be...@spamfence.net> wrote:
>> > Der neue Mac Mini Server wäre ja ein nettes Teil.
>>
>> das alleine schon ~900 Flocken...
>>
>> > Da dran
>> > ein JBOD mit Firewire und ... wo war noch gleich das ZFS
>> > für Snow Leo Server?
>> >
>> > Mist!
>>
>> ...um daraus ein NAS zu basteln? Da kann man ja wirklich vom feinsten
>> was richtiges kaufen.
>
> ...
> Hat jemand Erfahrung mit Samba und/oder Netatalk auf OpenSolaris?
Zweiteres. Die Erfahrungen unterscheiden sich nicht von anderen
Plattformen.
Gruß
-Ralph
--
s/-nsp// for mail
Goetz Hoffart
> SuperMicro - 5046A-XB
Hm. Hat jemand mal ausprobiert, wieviel Aufwand es ist, da MOSX
draufzupacken? Ich brauche f�r eine Freundin einen stabilen
(AFP-)Fileserver mit viiiel Platz und wenig CPU-Bumms. Das Budget ist
klein, Freelancer-Fotografen die nicht Paparazzi sind haben es wohl
schwer im Moment.
Das Ger�t bietet �brigens zwar 8 Slots f�r 3,5" Platten - davon sind
aber zwei als �spare� markiert, wohl weil das Mainboard nur 6x SATA
bietet.
Gr��e
G�tz
--
http://www.knubbelmac.de/
Goetz Hoffart
> > Hm. Hat jemand mal ausprobiert, wieviel Aufwand es ist, da MOSX
> > draufzupacken?
>
> Ist Open Solaris Dir nicht gut genug ;-)
Oh, das ist sehr nett. Nur gibt's daf�r nur entweder irre teure
AFP-Server (Helios) oder welche, die ich nicht im Produktivbetrieb
nutzen mag (Netatalk).
Patrick M. Hausen
Goetz Hoffart <use...@hoffart.de> wrote:
> Das Ger�t bietet �brigens zwar 8 Slots f�r 3,5" Platten - davon sind
> aber zwei als �spare� markiert, wohl weil das Mainboard nur 6x SATA
> bietet.
Weshalb das mir vorliegende Angebot einen passenden SATA-Hostadapter
enth�lt ;-)
Goetz Hoffart
> Warum nicht?
> Ich bin bei NetAtalk schon lange nicht mehr auf dem Laufenden.
Mir hat es schon einige mal Kopfzerbrechen bereitet, etwa weil die
Datenbank zerbr�selt ist (wer auch immer daran schuld war), so dass ich
Backups einspielen durfte. Unter 'h�herer' Last (ca. 20 User arbeiteten
auf Netatalk-Volumes) ist es mir auch schon stehengeblieben.
In einem Umfeld, wo ein kundiger Admin da ist, w�rde ich es wohl immer
noch einsetzen. Aber die Freundin hat keinen und es muss einfach laufen,
auch wenn ich mal nicht da bin.-)
Ralph Böhme
> Daniel Krebs <spam.a...@t-online.de> wrote:
>> Warum nicht?
>> Ich bin bei NetAtalk schon lange nicht mehr auf dem Laufenden.
> Mir hat es schon einige mal Kopfzerbrechen bereitet, etwa weil die
> Datenbank zerbröselt ist (wer auch immer daran schuld war), so dass ich
> Backups einspielen durfte. Unter 'höherer' Last (ca. 20 User arbeiteten
> auf Netatalk-Volumes) ist es mir auch schon stehengeblieben.
Ohne das in Abrede stellen zu wollen, nur um das Erfahrungsbild zu ergänzen:
es gibt Installationen mit mehrereren hundert *aktiven* Verbindungen wo das
über Jahre stabil betrieben werden konnte.
Goetz Hoffart
> Ohne das in Abrede stellen zu wollen, nur um das Erfahrungsbild zu erg�nzen:
> es gibt Installationen mit mehrereren hundert *aktiven* Verbindungen wo das
> �ber Jahre stabil betrieben werden konnte.
1.6.x oder 2.x? Ich hatte es von Netatalk 2.x. Version 1.5.x lief bei
mir auch jahrelang stabil.
Ralph Böhme
> Ralph Böhme <ralp...@rsrc.de> wrote:
>> Ohne das in Abrede stellen zu wollen, nur um das Erfahrungsbild zu ergänzen:
>> es gibt Installationen mit mehrereren hundert *aktiven* Verbindungen wo das
>> über Jahre stabil betrieben werden konnte.
> 1.6.x oder 2.x? Ich hatte es von Netatalk 2.x. Version 1.5.x lief bei
> mir auch jahrelang stabil.
2.0.x. Allerdings von Hand gebaut Zecks Aktivierung von BerkeleyDB
Transaktionen in Verbindung mit dem dbd CNID backend. Afair ist das in den
meisten Distris leider nicht aktiviert. Mit 2.1 wird das aber wohl Standard.
Marc Stibane
> Ich brauche f�r eine Freundin einen stabilen
> (AFP-)Fileserver mit viiiel Platz und wenig CPU-Bumms.
Gebrauchten (G4-)Mini und 2-3 gro�e Firewire-Platten dranh�ngen.
Goetz Hoffart
> Gebrauchten (G4-)Mini und 2-3 gro�e Firewire-Platten dranh�ngen.
Eh, ungef�hr da ist sie jetzt. Sie braucht aber mittelfristig 6-8 TB,
das will ich nicht per Plattenstapel l�sen. Und zu langsam w�re FW400
auch, ein RAW-Bild kommt schnell mal auf 45 MB.
Goetz Hoffart
> Oder halt ein kleines Firewire Geh�use f�r mehrere Platten.
Ich finde nur FW-Geh�use f�r bis zu 5 Platten (Raidsonic). Und dann hab
ich ein Black Box als RAID: ich ersetze einen SPoF ("Platte putt") durch
einen anderen ("RAID-Controller putt"), den ich nicht vorhalten mag.
Nachdem ich schon viel Spa� mit Taurus-Geh�usen diesbez�glich hatte:
sowas will ich nicht mehr.
Da w�re mir ein PCIe-Slot lieber, in den ich eine Areca stecken kann.
Von denen sind immer welche im Regal. Und hintendran ein dummes Shelf.