Fileserver- und Backupstrategie-Empfehlung f ür HELIOS-Suite
Yann Borg
ich stehe ziemlich ratlos vor einem Problem was eigentlich nur deshalb
entstanden ist weil unser momentaner FileServer eine
Festplattenspeichererweiterung bekommen soll. Da der Server bald
ausgetauscht werden soll stellt sich die Frage ob wir nicht auf eine andere
Plattform als SUN "switchen". Aber zum Anfang der Geschichte:
Wir haben hier eine SUN Ultra10 die eigentlich noch Ihre Dienste als
EtherShare bzw. OPI-Server (auf neuhelios "ImageServer") mind. ein Jahr
überwältigen sollte. OPI hat sie noch nie gemacht und ich trauere der
Gigabit-Übertragungswegen immer noch unser alter ASIP-Server... Meine
Befürchtung ist, dass die kleine Workstation bald nicht mehr ausreichende
Performance bieten kann wenn Sie parallel zu ein paar Druckjobs noch Bilder
konvertiert und Filedienste nachgehen muss.
Jetzt brauchen wir zusätzliche Festplattenkapazität in Form eines externen
RAID-System, da unser momentanes 150 GB SCSI RAID-5 System überstrapaziert
ist. Die aktuelle c't brachte mir dazu in Richtung "billigen" IDE-RAID
Systeme nachzudenken wobei sich die Frage des Backups stellt: die Lösung die
Heise laufen hat, Datenbackup auf einen RAID-5 Volume zu sichern gefällt mir
ganz gut weil verhältnismäßig günstig. Von Transtec kostet z.B. das transtec
5000 mit 12 Platten à 120 GB (mit spare Drives ca. 900 GB RAID-5)
vorkonfiguriert ca. 8300 EUR. Von Infortrend gibt es vergleichbares in Form
des IFT 6300, allerdings ohne Festplatten so das die Konfiguration an einem
hängen bleibt (angesichts der völligen Auslastung momentan eher 2. Wahl).
Dafür ist es auch um ca. 1700 EUR günstiger. Man könnte das System in 2
RAIDs à 6 Platten (inkl. Spare-Drive) teilen, das erste für die Daten, das
zweite für das Backup was z.B. mittels ES-Backup oder Retrospect gesichert
werden könnte. Zweiteres ist nicht so elegant weil Netzwerklastig und evtl.
auch AFP-Rechte verlieren gehen.
Wenn wir jetzt also das neue RAID in einem für Solaris initialisierten
Filesystem an der SUN hängen, hätten wir möglicherweise ein Problem die
Datenmenge zu sichern im Falle eines nicht unter Solaris laufender neuen
Server. Ist das richtig so? Oder ist das Festplattensystem was unter Solaris
8 läuft mit andere UNIXe "kompatible", als Plug and Play? Ich denke z.B. an
einen freien UNIX oder an MacOSX.
Wenn nicht müssten beide RAIDs neuinitialisert werden, das heißt
Datensicherung für max. 1 TB! Uuupsala. Abgesehen davon dass ich nicht so
recht weiss ob eine Datensicherung über AFP die sinnvollste Lösung wäre,
oder ob man nicht lieber über UNIX-Terminal und HELIOS eigene Tools die
Daten schieben sollte.
Das heißt es müsste dann doch ein neuer Solaris-Rechner her (SUN oder
Kompatibel). Vorteil ist ganz klar die Migration zwischen den beiden Server,
die legendäre Stabilität der SUN-Hardware die ich sehr zu schätzen weiß.
Nachteil sehe ich im Preis: eine SUN Fire 280R mit 2 x 900 MHz UltraSparc
III Prozessoren kostet um die 20.000 EUR. Aber vielleicht greife ich auch zu
Hoch? Die Blade 2000 mit den gleichen Prozessoren kostet 16.400 EUR, ist
aber auch kein Server soweit ich weiß, d.h. keine redundante Netzteile usw.
Wobei, falls die Xinet Test-Suite [1] auf die HELIOS Produktlinie
Übertragbar ist schneidet die SUN Fire 280R (mit 2 x 750 MHz) am
schlechtesten ab und wird z.B. von Apples XServe oder Dells Poweredge
geschlagen.
Oder wir nehmen gleich einen Mac als Server, hier steht das Spitzmodell von
Apple der die Dienste ausführen könnte. Vorteil: günstig, schnell und falls
mal die Kiste abschmiert nehme ich einfach eine Arbeitstation unterm
Nachbartisch weg und ersetze den Server kurzerhand. Nachteil: Apples
unvorhersehbare Politik, MacOSX als Serverbetriebsystem IMO gewagt (Update
alle 6 Wochen...), Rechner nicht für Serverdienste konzipiert (kein ECC-RAM,
2. Netzteil usw.)
Alternativ bietet sich ein auf ein freies UNIX basierender Server wie es die
von Dell, Transtec & Co. gibt. Für mich komplett Neuland wobei das halb so
schlimm ist weil ich den Server nur mit ES-Admin administriere und
Installation & Co. vom HELIOS-Händler übernommen wird. Vorteil:
Preisgünstiger und Leistungsfähiger als die SUN Fire 280R, echter Server mit
allem drum und dran. Nachteil: fällt mir gerade dazu nix ein, außer das es
Neuland für mich ist und ich von der Konfiguration nicht einschätzen kann
was mich später erwarten wird.
Auf jeden Fall stehe ich auf flotte LAN-Tests, das muss ich hier keinem
sagen ;-) Die Netzperformance sollte nicht arg unter 30 MB/Sek gehen
(Gigabit-Enet an Grafik-Clients). Die OPI-Umwandlung flott von Stande gehen
wobei ich schwer einschätzen kann was auf uns zukommt. Hier arbeiten 8
Grafik-Arbeitsplätze recht intensiv mit Bilddaten, 20 weitere eher
Office-lästig und es laufen monatlich mehrere VKF-Broschüren mit viele
Freisteller von denen wir die High-End PDFs für die Druckerei produzieren.
Zudem werden wir für mehrere Kunden die Bilddaten hosten und stellen sie
über einen Cumulus-Server zu Verfügung.
Soviel also zu meine Überlegungen. Was halltet ihr von der Geschichte mit
der Datensicherung auf einen und das selbe RAID-System (Wobei für kritische
Daten immer noch das AIT-2-Stack mit 100 GB unkomprimiert eingesetzt werden
soll)? Was würdet Ihr lieber für eine Serverhardware-/
Betriebssystemkombination einsetzen? Fragen über Fragen die momentan von mir
nicht wirklich beantwortet werden können. Höchstens von meine Chefs wenn ich
Montag zu den gehe und ein paar Zahlen vorlege ;-) Wobei Sie auch Einsichtig
sind wenn es um die Integrität der Daten und die Arbeitsqualität der
Mitarbeiter geht, zum Glück!
Danke vorab für euer Input!
Gruss,
Yann
[1]:
<http://www.xinet.com/aboutxinet/pdf.library/configurations.pdf/xinet.benchm
ark.config.2002.pdf>
Thomas Kaiser
<news:BA3638CC.2FECD%y.b...@arts-others.de>:
> Die aktuelle c't brachte mir dazu in Richtung "billigen" IDE-RAID
> Systeme nachzudenken wobei sich die Frage des Backups stellt: die Lösung die
> Heise laufen hat, Datenbackup auf einen RAID-5 Volume zu sichern gefällt mir
> ganz gut weil verhältnismäßig günstig.
Die sichern aber auf ein *separates* RAID in "virtuelle Tapes" und nicht in
ein Dateisystem hinein. Das bitte im Hinterkopf behalten.
> Man könnte das System in 2 RAIDs à 6 Platten (inkl. Spare-Drive) teilen, das
> erste für die Daten, das zweite für das Backup
Dann nenne das aber lieber nicht "Backup". Zuerst mal sind Verkabelung und
Controller massive "single points of failure" in dem Szenarium, zum anderen
reicht die Kapazität des Backup-Mediums vermutlich nicht aus, wenn Du eine
vernünftige Backup-Strategie mit mehreren Generationen fahren willst.
Wenn Sicherung auf Platten, dann mindestens auf separate Platten (muss kein
RAID sein -- Platten einzeln ansteuern bzw. JBOD tun's auch), wobei sich da
dann auch die Frage stellt, wie die Daten dort gesichert werden (Dateisystem
mit populärer Backup-Lösung oder Helios Bordmitteln oder per UNIX Tools in
Images oder was-auch-immer)
> was z.B. mittels ES-Backup
Ach, das kann auch auf Platten im/am Server sichern?
> oder Retrospect gesichert werden könnte. Zweiteres ist nicht so elegant weil
> Netzwerklastig und evtl. auch AFP-Rechte verlieren gehen.
Keine Ahnung, ob Retrospect in so einem Fall mit zwei Dateisystemen die
AFP "copy file" Methode ausnutzt (dabei müssen die Daten nicht übers Netz
transferiert werden, wenn der Finder merkt, daß Quell- und Zielvolume auf
dem selben Server residieren --> es werden per AFP nur die nötigen
Kopieroperationen auf dem Server veranlasst und auf deren Bestätigung
gewartet, d.h. es geht von der Datenmenge her fast nichts durchs Netz)
Ich finde so eine Lösung mit Retrospect aber auch hinsichtlich Konsistenz
der File-IDs nicht so wirklich prickelnd (von den Rechten und
Eigentümerschaften mal ganz abgesehen)
> [...] ist das Festplattensystem was unter Solaris 8 läuft mit andere UNIXe
> "kompatible", als Plug and Play?
Ihr werdet bei den Datenmengen sicherlich ein journaled UFS verwenden und
ich befürchte mal stark, daß das zu nichts anderem außer Solaris kompatibel
ist (weiß es aber nicht sicher)
> Ich denke z.B. an einen freien UNIX oder an MacOSX.
Um es weiter einzuschränken: Entweder Linux oder MacOS X, da Helios je
Prozessorfamilie in der Regel nur ein OS unterstützt, d.h. daß die "echten"
freien UNIX-Varianten (Free-, NetBSD, etc.) eh außen vor bleiben...
> Wenn nicht müssten beide RAIDs neuinitialisert werden, das heißt
> Datensicherung für max. 1 TB! Uuupsala.
Naja, Du brauchst in jedem Fall vorher schon eine vernünftige
Datensicherung, die alle Daten, die es wert sind, irgendwo ablegt (seien es
nun Platten oder irgendwas anderes). Wenn die Daten dann auf ein anderes
Server-OS migrieren sollen, dann würde ich erst das Produktiv-RAID frisch
einrichten und dann per Netzwerk und UNIX-Tools aus dem Backup am alten
Server auf das frische RAID am neuen Server zurücksichern. Das Dateiformat,
das Helios verwendet, ist netterweise auf allen sieben (oder acht?)
unterstützten UNIX-Plattformen identisch (inkl. Feinheiten wie automatische
Behandlung von "big endian" vs. "little endian"), so daß der Weg quer durchs
Netz von UNIX zu UNIX wirklich kein grösseres Problem darstellt.
Wichtig ist nur, daß man sich eben vorher bei der Wahl der Backup-Methode
schon Gedanken bzgl. dieses Umzug macht, also die Möglichkeit per Netz aus
dem Backup heraus den Kram woanders hinzusichern, unbedingt berücksichtigt.
> Abgesehen davon dass ich nicht so recht weiss ob eine Datensicherung über
> AFP die sinnvollste Lösung wäre, oder ob man nicht lieber über UNIX-Terminal
> und HELIOS eigene Tools die Daten schieben sollte.
Das hängt v.a. von Euren Anforderungen ab, was alles soz. an Metadaten
(Eigentümerschaften, Rechte und letzten Endes so Dinge wie konsistente File-
und Directory-IDs -- kann für Bilddatenbanken und/oder OPI wichtig sein)
noch benötigt ist.
Im Prinzip würde ich das aber mit dem Händler bzw. Systemhaus Deines
Vertrauens im Detail durchsprechen, um hier eine richtige Strategie zu
entwickeln... In dem Bereich ist jeder gesparte Cent beim Consulting
meistens fünfmal bei der Umsetzung wieder verschleudert ;-)
[Serverplattform]
Schwierig zu beantworten, v.a. wenn man außen vor läßt, wer das System mal
betreuen soll. Wenn das Systemhaus auf der entsprechenen Plattform nicht fit
ist, hörst Du gerne mal ein "Hätten Sie halt auf uns gehört und lieber OS
xyz verwendet", wenn Techniker an Trivialitäten scheitern.
Bzgl. Sun sollte auch schon eine 280er in Minimalkonfiguration deutlich
schneller sein als Eure Ultra10 (kostet dann aber auch nur zehn KEUR). Hätte
zudem den Vorteil, die Ultra10 als Backup-Maschine nutzen zu können, wenn Du
an entsprechende ColdSpare Lizenzen denkst (in der Hinsicht wären Linux und
MacOS X natürlich viel doller, weil nur der Dongle umgesteckt werden müsste
-- auch wieder wahr)
Irgendeine DELL- oder Transtec- Kiste kostet dann nochmals die Hälfte der
kleinsten Sun, allerdings solltest Du entweder sehr genau wissen, was darin
verbaut ist (bevorzugt Standardteile, die man irgendwo in der Bahnhofsgegend
schnell wiederbeschaffen kann) oder aber gleich 'ne zweite Maschine als
Ersatzteillager daneben stellen. Beides bedingt dann entsprechendes
personelles Knowhow oder andererseits entsprechende Supportverträge (die
Ersatzteilvorhaltung evtl. auch mit einschließen)
Wenn Du Dir die Frage stellst, welches System letzten Endes günstiger kommt,
steht IMO erstmal eine genaue Abschätzung an, was Du von dem Server
erwartest (also neben dem Faktor Geschwindigkeit eben auch und vor allem
Ausfallsicherheit und Wartungsarmut). Diese Dinge müssen in eine Kalkulation
unbedingt ebenfalls eingehen, ansonsten verdient die den Namen nicht ;-)
Gruss,
Thomas
Goetz Hoffart
> IDE-RAID Systeme nachzudenken wobei sich die Frage des Backups stellt: die
> Lösung die Heise laufen hat, Datenbackup auf einen RAID-5 Volume zu
> sichern gefällt mir ganz gut weil verhältnismäßig günstig. [...] Man
> könnte das System in 2 RAIDs à 6 Platten (inkl. Spare-Drive) teilen, das
> erste für die Daten, das zweite für das Backup was z.B. mittels ES-Backup
> oder Retrospect gesichert werden könnte.
Nun, damit hast du natürlich nur eine Backupgeneration auf Platte
vorrätig. Reicht dir das?
Wenn ja, ist das natürlich eine einfache und schnelle Lösung. Wenn nein,
scheidet sie fast sofort aus bzw. du kannst das RAID anders nutzen.
Schau bei den "Billig"-RAIDs auf jeden Fall, wie gut die
Benachrichtigung bei Ausfällen bzw. drohenden Ausfällen aussieht. Und ob
du diese Qualität der Benachrichtigung auch bei einem OS-Wechsel noch
hättest.
> Wenn wir jetzt also das neue RAID in einem für Solaris initialisierten
> Filesystem an der SUN hängen, hätten wir möglicherweise ein Problem die
> Datenmenge zu sichern im Falle eines nicht unter Solaris laufender neuen
> Server. Ist das richtig so?
Jein. UFS kannst du auch an freien Betriebssystemen auslesen. Da das bei
dir aber eher nach "mission critical" als nach "dann kratzen wir halt
mal zum Spaß ein paar alte Daten von der Platte, mal sehen, was noch da
ist" klingt, würde ich vorher testen, wie gut das in eurem Fall
tatsächlich klappt. Oder genauer recherchieren. Das sind Features, die
nicht sehr oft benötigt werden und daher nicht immer gut getestet sind.
BTW: Thomas Kaiser, auch Entourage scheint den Betreff-Bug noch zu
pflegen: auch Yanns Betreff ist zerhackstückt.
Grüße
Götz
--
http://www.knubbelmac.de/
Daniel Krebs
> Von Infortrend gibt es vergleichbares in Form
> des IFT 6300, allerdings ohne Festplatten so das die Konfiguration an einem
> hängen bleibt (angesichts der völligen Auslastung momentan eher 2. Wahl).
Das kannst Du Dir aber alles beispielsweise von Starline
<http://www.starline.de/> machen lassen. Ich habe vor etwa einem Monat
ein IFT 6210-8 mit 8 120 GB Platten fertig konfiguriert als RAID 5 mit 2
Hotspare bekommen. Die haben vor der Lieferung telefonisch angefragt,
wie ich es haben will, aber auch ohne deren Hilfe ist es kein Problem,
über das Knöpfcheninterface des Gehäuses sein RAID zu konfgurieren.
Allerdings würde es etwas Arbeit machen, die Platten in die Hot-Plug-
Schlitten einzuschrauben. Zusätzlich haben sie sogar noch eine Cold
Spare im Schlitten geliefert.
Das war aber nur ein Test :-) Ich habe vor, Anfang des Jahres eine
Backup-Lösung aus einem Dell- Server mit Redhat und Veritas Netbackup
aufzubauen. Dieser soll über zwei FC- Kanäle jeweils zwei FC- Hubs
ansteuern, die wiederum jeweils 4 IFT 6210-8 versorgen, welche 8 320 GB
Maxtor- Platten beinhalten, jeweils konfiguriert als RAID 5 mit zwei Hot
Spare. Mittels Veritas Netbackup, welches seit Version 4.5 Backups
doppelt schreiben kann, will ich ich die Backups abgesehen vom RAID
redundant halten. Durch Glas- FC kann ich einen der ALs räumlich von
Server und dem anderen Loop trennen und komme in einen anderen
Brandschutzabschnitt.
Sofern Du genügend Kohle hast, mach Dir nicht zuviel Arbeit. Die Preise
von Starline haben mich echt überrascht und werden wohl noch sinken.
> Dafür ist es auch um ca. 1700 EUR günstiger. Man könnte das System in 2
> RAIDs à 6 Platten (inkl. Spare-Drive) teilen, das erste für die Daten, das
> zweite für das Backup was z.B. mittels ES-Backup oder Retrospect gesichert
> werden könnte.
Das würde ich nicht tun. Teile die Sache lieber auf zwei Gehäuse auf.
Was machtst Du, wenn Dir Dein eines Gehäuse abraucht? Ich hab mich genau
deswegen für die 8- Bay- Gehäuse entschieden.
> Wenn wir jetzt also das neue RAID in einem für Solaris initialisierten
> Filesystem an der SUN hängen, hätten wir möglicherweise ein Problem die
> Datenmenge zu sichern im Falle eines nicht unter Solaris laufender neuen
> Server. Ist das richtig so?
Trenne Daten- RAID und Backup- RAID. Da ich es nur mit einem Backp zu
tun habe, habe ich nur das Problem, daß Netbackup, so waren jedenfalls
meine bisherigen Erfahrungen, einen schlecht optimierten Client für
MacOS hat. Also nehme ich für die wenigen hier noch laufenden Macs einen
separaten Retrospect- Server, dessen Sicherungen wiederum von Netbackup
gesichert werden. Ist freilich supoptimal und ich muß mal mit dem
aktuellen Mac- Client von Netbackup rumspielen.
> Das heißt es müsste dann doch ein neuer Solaris-Rechner her (SUN oder
> Kompatibel). Vorteil ist ganz klar die Migration zwischen den beiden Server,
> die legendäre Stabilität der SUN-Hardware die ich sehr zu schätzen weiß.
> Nachteil sehe ich im Preis: eine SUN Fire 280R mit 2 x 900 MHz UltraSparc
> III Prozessoren kostet um die 20.000 EUR. Aber vielleicht greife ich auch zu
> Hoch? Die Blade 2000 mit den gleichen Prozessoren kostet 16.400 EUR, ist
> aber auch kein Server soweit ich weiß, d.h. keine redundante Netzteile usw.
> Wobei, falls die Xinet Test-Suite [1] auf die HELIOS Produktlinie
> Übertragbar ist schneidet die SUN Fire 280R (mit 2 x 750 MHz) am
> schlechtesten ab und wird z.B. von Apples XServe oder Dells Poweredge
> geschlagen.
Ich kann nur nochmal betonen, trenne den Helios- Server vom Backup-
Server! Für Veritas gibt es sogar DOS- Clients. Aber Du kannst natürlich
auch eine andere Software nutzen. Wir haben hier allerdings eine Update-
Lizenz. Für Retrospect gibt es IMO keine Solaris- Clients. Das schränkt
ein.
> Oder wir nehmen gleich einen Mac als Server, hier steht das Spitzmodell von
> Apple der die Dienste ausführen könnte. Vorteil: günstig, schnell und falls
> mal die Kiste abschmiert nehme ich einfach eine Arbeitstation unterm
> Nachbartisch weg und ersetze den Server kurzerhand. Nachteil: Apples
> unvorhersehbare Politik, MacOSX als Serverbetriebsystem IMO gewagt (Update
> alle 6 Wochen...), Rechner nicht für Serverdienste konzipiert (kein ECC-RAM,
> 2. Netzteil usw.)
Da kann ich Dir nicht helfen. Ich würde einen XServe, oder wie die
heißen, nie als Produktionsserver einsetzen und als Retrospect- Server
reicht auch ein aktueller Mac.
> Soviel also zu meine Überlegungen. Was halltet ihr von der Geschichte mit
> der Datensicherung auf einen und das selbe RAID-System
Nix.
> (Wobei für kritische
> Daten immer noch das AIT-2-Stack mit 100 GB unkomprimiert eingesetzt werden
> soll)? Was würdet Ihr lieber für eine Serverhardware-/
> Betriebssystemkombination einsetzen?
Für den Fileserver Solaris auf Sun Sparc. Das RAID muß ja nicht von Sun
sein, da teuer. Ich würde aber unbedingt SCSI- Platten einsetzen.
Für das Backup kannst Du was billiges nehmen, wenn die Redundanz hoch
genug ist und der Wartungsvertrag ausreichend schnell.
Was AIT angeht, sind die Restore- zeiten ja recht gut. Aber ich will
mich nie wieder mit einem Bandroboter rumschlagen.
> Fragen über Fragen die momentan von mir
> nicht wirklich beantwortet werden können. Höchstens von meine Chefs wenn ich
> Montag zu den gehe und ein paar Zahlen vorlege ;-)
Da hast Du ja bis Montag noch viel zu tun. Ich habe Wochen für die
Planung gebraucht, obwohl es sich nur um den Backup- Server handelt.
Daniel, der gern bereit ist, seine Erfahrungen zu mailen. Aber unser
Einkauf wacht immer erst Anfang Februar auf. Kann also noch dauern...
Daniel Krebs
> Nun, damit hast du natürlich nur eine Backupgeneration auf Platte
> vorrätig. Reicht dir das?
Noch ein Grund mehr, mehrere RAIDs zu benutzen. Zum Beispiel eines für
die monatlichen Full- Backups und die inkrementellen und eines für die
wöchentlichen Full- Backups. Und das dann auch noch doppelt. Natürlich
plant man ein Fileserver- RAID so, daß es nicht von Anfang an voll ist.
Deswegen könnteYanns Backup- RAID erstmal ausreichen.
Wichtig ist jedoch so oder so: Wenn man etwas neues kauft, sollte es für
die nächsten paar Jahre reichen oder zumindest bequem erweiterbar sein.
Daniel
Thomas Kaiser
<news:1fo0rek.1it6f1f9ycyc4N%el.k...@de-soc-mac.de>:
> Wichtig ist jedoch so oder so: Wenn man etwas neues kauft, sollte es für
> die nächsten paar Jahre reichen oder zumindest bequem erweiterbar sein.
Und an der Stelle könnte es sich sowohl wegen Produktions-RAID als auch
Backup-Lösung lohnen, mal HSM-Lösungen wie bspw. Sam-FS anzusehen (und mit
dem spitzen Bleistift alles durchzurechnen, speziell in Hinblick auf die
wahrscheinlich explodierende Speichersituation in ein paar Jahren und
wieviel Aufwand die Migrationsprojekte alle paar Monate wirklich mit sich
bringen)
Sam-FS ist IMO gerade deshalb so nett, weil man bei geeigneter Konfiguration
(mehr als eine Library und angepasste Config-Dateien) sich sogar das Backup
schenken kann...
Gruss,
Thomas
Tibor Pausz
> Wobei, falls die Xinet Test-Suite [1] auf die HELIOS Produktlinie
> Übertragbar ist schneidet die SUN Fire 280R (mit 2 x 750 MHz) am
> schlechtesten ab und wird z.B. von Apples XServe oder Dells Poweredge
> geschlagen.
Der Test ist meiner Meinung nach nicht sonderlich viel Wert. Schau Dir
die Konfigurationen an. Am Xserver hängt ein Hardware RAID und an der
SUN wird bloß, die System Disk genutzt.
Nun gut die UltraIII CPUs sind nicht sonderlich fix im Vergleich zu
anderen aktuellen CPUs, aber bei IO Jobs ist das nicht so wichtig, das
zählt Durchsatz auf dem Bus.
Daniel Krebs
> Sam-FS ist IMO gerade deshalb so nett, weil man bei geeigneter Konfiguration
> (mehr als eine Library und angepasste Config-Dateien) sich sogar das Backup
> schenken kann...
Klardoch. SamFS ist sicher geil. Aber nur für Solaris. Und ob sich Yann
bis Montag halbwegs soweit damit vertraut machen kann, daß er seinem
Chef halbwegs erklären kann, was der für diesen Luxus ausgeben muß.
Aber warum nicht...
Daniel, der SamFS- Konfigurationen gesehen hat, die einfach nur
schwachsinnig waren.
Thomas Kaiser
<news:1fo0tk9.pbmmn5yi2c9tN%el.k...@de-soc-mac.de>:
[Sam-FS]
> ob sich Yann bis Montag halbwegs soweit damit vertraut machen kann, daß er
> seinem Chef halbwegs erklären kann, was der für diesen Luxus ausgeben muß.
Ich glaube eher nicht... ich bin mir nicht mal sicher, ob ich es empfehlen
würde, so ohne Kenntnis weiterer Parameter...
> Aber warum nicht...
Ich versuchte eigentlich auch zwischen den Zeilen zu schreiben, daß man
derlei Entscheidungen niemals "auf die Schnelle" treffen sollte, sondern
sich immer die nötige Zeit einräumen sollte, das Ganze sauber durchzuplanen
und alle nötigen Faktoren (die bei den "schnell schnell" Entschlüssen ja
zumeist unter den Tisch fallen) einzubeziehen.
Aus meiner eigenen Erfahrung heraus habe ich lernen müssen, das sogar in
Situationen zu machen, in denen man mit dem Rücken zur Wand steht. Denn wenn
man erstmal damit anfängt "zwischenzeitlich ein Provisorium einzusetzen",
merkt man meistens Jahre später, das nichts so endgültig wie ein Provisorium
ist ;-)
> Daniel, der SamFS- Konfigurationen gesehen hat, die einfach nur
> schwachsinnig waren.
Das können wir -- glaube ich -- beliebig auf diverse andere Bereiche
(Serverkonfigurationen, "Workflow"-Planungen, etc.) ausdehnen, oder :-)
Gruss,
Thomas, der schon nach vielen Kundenbesuchen nur noch verwirrt war bzgl.
Verschwendung und schwachsinniger Konfigurationen auf der einen Seite und
gleichzeitig Sparsamkeit bzgl. eigentlich wichtiger Dinge auf der anderen
Daniel Krebs
> Ich versuchte eigentlich auch zwischen den Zeilen zu schreiben, daß man
> derlei Entscheidungen niemals "auf die Schnelle" treffen sollte, sondern
> sich immer die nötige Zeit einräumen sollte, das Ganze sauber durchzuplanen
> und alle nötigen Faktoren (die bei den "schnell schnell" Entschlüssen ja
> zumeist unter den Tisch fallen) einzubeziehen.
Das hast Du aber ganz schön durch die Blume gesagt, indem Du darauf
hinwiest, daß es auch HSM- Lösungen gibt :-)
> Aus meiner eigenen Erfahrung heraus habe ich lernen müssen, das sogar in
> Situationen zu machen, in denen man mit dem Rücken zur Wand steht. Denn wenn
> man erstmal damit anfängt "zwischenzeitlich ein Provisorium einzusetzen",
> merkt man meistens Jahre später, das nichts so endgültig wie ein Provisorium
> ist ;-)
Oh ja. Vor allem sollte man möglichst nie versuchen, ein solches
Provisorium weiter auszubauen. Auch nicht provisorisch ;-)
> > Daniel, der SamFS- Konfigurationen gesehen hat, die einfach nur
> > schwachsinnig waren.
>
> Das können wir -- glaube ich -- beliebig auf diverse andere Bereiche
> (Serverkonfigurationen, "Workflow"-Planungen, etc.) ausdehnen, oder :-)
Sicher, es fiel mir gestern nur gerade ein, als Du SamFS erwähntest. Ich
wollte damit sagen, daß man, wenn man eine HSM- Lösung einsetzen will,
ziemlich genau wissen muß, was man macht. Dazu gehört eine nicht kurze
Einarbeitungszeit.
Das gilt übrigens auch für Backup- Strategien, Yann :-) In einer der
letzten iXen gab es zum Beispiel einen Artikel darüber.
> Thomas, der schon nach vielen Kundenbesuchen nur noch verwirrt war bzgl.
> Verschwendung und schwachsinniger Konfigurationen auf der einen Seite und
> gleichzeitig Sparsamkeit bzgl. eigentlich wichtiger Dinge auf der anderen
Ich glaube es liegt oft daran, daß Entscheider keine Ahnung haben und
die, die Ahnung haben, keinen Mut oder einfach keinen Ehrgeiz :-)
Aber das läßt sich natürlich auch wieder verallgemeinern...
Daniel, der hofft, daß Manfred jetzt nicht mitgelesen hat *g*
Jens-Uwe Mager
news:BA36445C.3A1C5%Thomas...@phg-online.de:
> Um es weiter einzuschr„nken: Entweder Linux oder MacOS X, da Helios je
> Prozessorfamilie in der Regel nur ein OS unterst tzt, d.h. daá die
> "echten" freien UNIX-Varianten (Free-, NetBSD, etc.) eh auáen vor
> bleiben...
Die Taktik nur ein OS per Prozessorfamilie zu unterstuetzen ist eher der
Versuch die Anzahl der Varianten beim Bauen der Software zu reduzieren.
Irgendwo muss man die Grenze ziehen, sonst verstrickt man sich. Und ist das
SMP unter den *BSDs nicht noch in den Kinderschuhen?
--
Jens-Uwe Mager <pgp-mailto:62CFDB25>
Frank-Christian Kruegel
>Wenn wir jetzt also das neue RAID in einem für Solaris initialisierten
>Filesystem an der SUN hängen, hätten wir möglicherweise ein Problem die
>Datenmenge zu sichern im Falle eines nicht unter Solaris laufender neuen
>Server. Ist das richtig so?
Im Allgemeinen ja. UFS ist nicht gleich UFS, speziell wenn es um sowas wie large
files oder acls oder logging geht. Es gibt funktionierende Kombinationen, aber
darauf solltest Du nicht Deine Strategie aufsetzen.
>Das heißt es müsste dann doch ein neuer Solaris-Rechner her (SUN oder
>Kompatibel). Vorteil ist ganz klar die Migration zwischen den beiden Server,
>die legendäre Stabilität der SUN-Hardware die ich sehr zu schätzen weiß.
>Nachteil sehe ich im Preis: eine SUN Fire 280R mit 2 x 900 MHz UltraSparc
>III Prozessoren kostet um die 20.000 EUR. Aber vielleicht greife ich auch zu
>Hoch? Die Blade 2000 mit den gleichen Prozessoren kostet 16.400 EUR, ist
>aber auch kein Server soweit ich weiß, d.h. keine redundante Netzteile usw.
>Wobei, falls die Xinet Test-Suite [1] auf die HELIOS Produktlinie
>Übertragbar ist schneidet die SUN Fire 280R (mit 2 x 750 MHz) am
>schlechtesten ab und wird z.B. von Apples XServe oder Dells Poweredge
>geschlagen.
Ich würde mich hier eher nach einer gebrauchen E250 oder E450 oder den
entsprechenden Rack-Modellen E220R bzw E420R in der entsprechenden Ausstattung
umschauen. Damit könnt Ihr einiges an Geld sparen. Und in eine 450'er passen
intern 12 SCA-Platten.
Ich habe hier ein IFT IDE-Raid mit 4 120 GB WD1200JB Platten als RAID5 an einer
UltraAXi Maschine (sozusagen eine Ultra 10 mit SCSI statt IDE als
ATX-Standard-Mainboard) hängen, und der begrenzende Faktor ist ganz eindeutig
das RAID. Ein IFT SCSI-Raid mit den passenden Platten ist doch um einiges
schneller. Wenn die Kiste nichts anderes macht, sollte eine E250 mit 2*400 MHz
CPUs das locker schaffen.
Mein IFT IDE-Raid macht so etwa 35 MB/s.
>Soviel also zu meine Überlegungen. Was halltet ihr von der Geschichte mit
>der Datensicherung auf einen und das selbe RAID-System (Wobei für kritische
>Daten immer noch das AIT-2-Stack mit 100 GB unkomprimiert eingesetzt werden
>soll)? Was würdet Ihr lieber für eine Serverhardware-/
>Betriebssystemkombination einsetzen? Fragen über Fragen die momentan von mir
>nicht wirklich beantwortet werden können. Höchstens von meine Chefs wenn ich
>Montag zu den gehe und ein paar Zahlen vorlege ;-) Wobei Sie auch Einsichtig
>sind wenn es um die Integrität der Daten und die Arbeitsqualität der
>Mitarbeiter geht, zum Glück!
Alles auf ein Raid zu packen ist gewagt. Was ist, wenn der Controller im
Raid-System ausfällt? Nehmt besser zwei getrennte RAIDs an getrennten
SCSI-Bussen.
Mit freundlichen Grüßen
Dipl.-Ing. Frank-Christian Krügel
IstDa Kommunikationssysteme
Thomas Kaiser
<news:Xns92F726442348...@212.63.63.2>:
> Die Taktik nur ein OS per Prozessorfamilie zu unterstuetzen ist eher der
> Versuch die Anzahl der Varianten beim Bauen der Software zu reduzieren.
> Irgendwo muss man die Grenze ziehen, sonst verstrickt man sich.
Ach, ich finde das gar nicht so schlecht, daß nicht beliebige weitere
Prozessor/OS Kombinationen möglich sind (und die jetzigen bieten ja
genaugenommen sowieso schon für jeden Geschmack und jedes Einsatzfeld
etwas).
Schließlich steht man beim Entwickeln von Lösungen im Helios Umfeld
ebenfalls vor der Situation, daß die Vielfalt teils nicht unerheblichen
Mehraufwand bedeutet...
Gruss,
Thomas
Thomas Kaiser
<news:3e14ee74....@uaxe.intern.istda.com>:
> Wenn die Kiste nichts anderes macht, sollte eine E250 mit 2*400 MHz
> CPUs das locker schaffen.
Die Kiste wird aber noch OPI machen müssen bzw. Bilddatenkonvertierung, wenn
ich das alles richtig verstanden habe. Das geht zwar auch mit einer E250
(kenne eine Installation, in der 20 Leute simultan auf einer solchen mit 2
250 MHz CPUs arbeiten -- aber das sind disziplinierte Reproiden, die dazu
gewzungen wurden, sich vorausschauend die CPU-Power einzuteilen) aber ich
denke, es dürfte ein wenig zäh sein, wenn Yann jetzt schon mit der Ultra10
unzufrieden ist (und aktuell noch nichts anderes drauf läuft)
Gruss,
Thomas
Yann Borg
Thomas...@phg-online.de (Thomas Kaiser) wrote:
>> Man könnte das System in 2 RAIDs ŕ 6 Platten (inkl. Spare-Drive) teilen, das
>> erste für die Daten, das zweite für das Backup
>
> Dann nenne das aber lieber nicht "Backup". Zuerst mal sind Verkabelung und
> Controller massive "single points of failure" in dem Szenarium,
Stimmt, das wäre kein Backup. Ich ging halt aus meinem kleinen
Erfahrungsschatz aus, in dem sich zeigte, dass keiner der 3 RAID-Systeme die
hier standen wirklich verabschiedet hat. Sie sind nur deshalb gestorben weil
sie zu wenig Platz boten.
> zum anderen reicht die Kapazität des Backup-Mediums vermutlich nicht aus, wenn
> Du eine vernünftige Backup-Strategie mit mehreren Generationen fahren willst.
Jein. Auf langer Sicht nicht, mittelfristig schon, da wir definitiv nicht
gleich die RAID-Systeme voll kriegen, so sehr wir uns anstrengen würden. Die
Erfahrung zeigt aber klar, dass Speicherkapazitäten dazu neigen komplett
gefüllt zu werden, egal wie Groß sie ursprünglich waren.
> Wenn Sicherung auf Platten, dann mindestens auf separate Platten (muss kein
> RAID sein -- Platten einzeln ansteuern bzw. JBOD tun's auch),
Die Idee das Backup auf einzelne Platten zu sichern gefällt mir gut. Aus
lauter "billige IDE-RAID sind gut" bin ich etwas verblindet. Schliesslich
ist unsere momentane Datensicherung auf AIT-2 Bänder eher ein verzögertes
RAID-1 (2 wöchentliches Backup) als ein RAID Level 5.
> wobei sich da dann auch die Frage stellt, wie die Daten dort gesichert werden
> (Dateisystem mit populärer Backup-Lösung oder Helios Bordmitteln oder per UNIX
> Tools in Images oder was-auch-immer)
Nächstes Dilemma. Erstere Lösung in Form von Retrospect wäre mir vertraut,
könnte aber zu inkonsistente File-IDs führen (hat wer Erfahrung mit
Retrospect und OPI-Daten?). ES-Backup scheint nur auf Bänder sichern zu
können, fällt also aus, und ein UNIX-Tool kann ich nicht bedienen :-(
>> was z.B. mittels ES-Backup
>
> Ach, das kann auch auf Platten im/am Server sichern?
Hatte ich nicht recherchiert... google... Steht zumindest nicht explizit in
der Feature-Liste. Ich gehe davon aus dass nicht.
>> oder Retrospect gesichert werden könnte. Zweiteres ist nicht so elegant weil
>> Netzwerklastig und evtl. auch AFP-Rechte verlieren gehen.
>
> Keine Ahnung, ob Retrospect in so einem Fall mit zwei Dateisystemen die
> AFP "copy file" Methode ausnutzt (dabei müssen die Daten nicht übers Netz
> transferiert werden, wenn der Finder merkt, daß Quell- und Zielvolume auf
> dem selben Server residieren --> es werden per AFP nur die nötigen
> Kopieroperationen auf dem Server veranlasst und auf deren Bestätigung
> gewartet, d.h. es geht von der Datenmenge her fast nichts durchs Netz)
Soweit ich weiß sichert Retrospect in einer einzelnen und Proprietären Datei
hinein. Es entsteht dadurch wahrscheinlich Netzwerktraffic da die Daten von
Retrospect selbst "verarbeitet" werden.
> Ich finde so eine Lösung mit Retrospect aber auch hinsichtlich Konsistenz
> der File-IDs nicht so wirklich prickelnd (von den Rechten und
> Eigentümerschaften mal ganz abgesehen)
IMHO Glatteisgefahr.
[Server-OS Migrations Strategie]
> Das Dateiformat, das Helios verwendet, ist netterweise auf allen sieben (oder
> acht?) unterstützten UNIX-Plattformen identisch (inkl. Feinheiten wie
> automatische Behandlung von "big endian" vs. "little endian"), so daß der Weg
> quer durchs Netz von UNIX zu UNIX wirklich kein grösseres Problem darstellt.
Okay. Also Backup-Rechner mit einzel-Festplatten am nächsten Flurende mit...
Mac OS X und ein auf Kommandozeilen beruhendes Backup-Programm was Daten im
UNIX-Format quer durchs Netz schleust und auf ein UFS-Volume sichert?
Elegant für das Restaurieren im Migrationfall, aber gibt es eine GUI für die
Alltagsrestauration? Alltag ist vielleicht nicht ganz richtig, in den
letzten 6 Monaten musste ich AFAIR ein- bis zweimal eine Datei
Wiederherstellen.
> [Serverplattform]
>
> Schwierig zu beantworten, v.a. wenn man außen vor läßt, wer das System mal
> betreuen soll. Wenn das Systemhaus auf der entsprechenen Plattform nicht fit
> ist, hörst Du gerne mal ein "Hätten Sie halt auf uns gehört und lieber OS
> xyz verwendet", wenn Techniker an Trivialitäten scheitern.
Wenn ich mir die Systemhäuser "um die Ecke" anschaue, neigen fast alle in
Richtung SUN zu schauen.
> Bzgl. Sun sollte auch schon eine 280er in Minimalkonfiguration deutlich
> schneller sein als Eure Ultra10 (kostet dann aber auch nur zehn KEUR).
Kann man sie im Zweifelsfall mit einem 2. Prozessor nachrüsten? Weshalb ich
nur Biprozessor-Maschinen aufgelistet habe liegt ein wenig daran, dass AFAIR
Daniel irgendwann meinte Gigabit-Enet auf eine Einprozessor-Maschine (wie
die Ultra10) kein Sinn macht. Ein HELIOS-Händler meinte ich wäre damals
schlecht beraten gewesen Gigabit-Enet auf der Ultra10 einzusetzen, da die
PCI-Karte "300 MHz der Prozessorleistung frisst". Klingt etwas seltsam, kann
diese Aussage nicht Fachkundig beurteilen.
> Hätte zudem den Vorteil, die Ultra10 als Backup-Maschine nutzen zu können,
> wenn Du an entsprechende ColdSpare Lizenzen denkst
Wusste nicht dass es das gibt. Der Gedanke ist nett, die Ultra10 als
Ersatzserver zu behalten... Ich hätte sie gerade mal in Kauf gegeben.
> Wenn Du Dir die Frage stellst, welches System letzten Endes günstiger kommt,
> steht IMO erstmal eine genaue Abschätzung an, was Du von dem Server
> erwartest (also neben dem Faktor Geschwindigkeit eben auch und vor allem
> Ausfallsicherheit und Wartungsarmut). Diese Dinge müssen in eine Kalkulation
> unbedingt ebenfalls eingehen, ansonsten verdient die den Namen nicht ;-)
Danke für die Erinnerung.
Gruss,
Yann
Yann Borg
(Goetz Hoffart) wrote:
>> IDE-RAID Systeme nachzudenken wobei sich die Frage des Backups stellt: die
>> Lösung die Heise laufen hat, Datenbackup auf einen RAID-5 Volume zu
>> sichern gefällt mir ganz gut weil verhältnismäßig günstig. [...] Man
>> erste für die Daten, das zweite für das Backup was z.B. mittels ES-Backup
>> oder Retrospect gesichert werden könnte.
>
> Nun, damit hast du natürlich nur eine Backupgeneration auf Platte
> vorrätig. Reicht dir das?
Okay, ich habe nur mittelfristig gedacht und darauf gesetzt, dass die
Kapazität des Daten-RAIDs nicht voll ausgeschöpft werden. Auf das aktuelle
150 GB RAID hätte zudem noch Datensicherung laufen können.
Ich bin mittlerweile aber von der Daten- & Backup auf ein RAID Story
weggekommen und bevorzuge das Backup auf nicht gespiegelte Festplatten.
Diese können auch nach Gusto erweitert werden... Wir haben noch ein altes
RAID-Gehäuse mit 10 oder 12 Einschübe in einer Ecke stehen, darin könnte man
evtl. die Platten einbauen und mit einem IDE-to-SCSI Adapter verbauen und in
einer SCSI-Kette einbinden. Ein bisschen Aufwendig aber evtl. sinniger als
bei jeder Backup-Kapazität Erweiterung einen IDE-Controller dazu zu kaufen.
Abgesehen davon dass nicht mehr als 6 Platten in aktuelle PowerMacs passen.
> Schau bei den "Billig"-RAIDs auf jeden Fall, wie gut die
> Benachrichtigung bei Ausfällen bzw. drohenden Ausfällen aussieht. Und ob
> du diese Qualität der Benachrichtigung auch bei einem OS-Wechsel noch
> hättest.
Ich sehe es ein, mir in der Richtung "_Qualität_ der Benachrichtigung" mehr
Gedanken machen zu müssen als ich es bisher tat...
Gruss,
Yann
Yann Borg
el.k...@de-soc-mac.de (Daniel Krebs) wrote:
>> Von Infortrend gibt es vergleichbares in Form
>> des IFT 6300, allerdings ohne Festplatten so das die Konfiguration an einem
>> hängen bleibt (angesichts der völligen Auslastung momentan eher 2. Wahl).
>
> Das kannst Du Dir aber alles beispielsweise von Starline
> <http://www.starline.de/> machen lassen.
Habe gerade bei meinem Händlerkollege nachgefragt, unsere bisherige
Infortrend Controller stammen von Starline.
> Ich habe vor etwa einem Monat ein IFT 6210-8 mit 8 120 GB Platten fertig
> konfiguriert als RAID 5 mit 2 Hotspare bekommen.
8 Platten und 2 Hotspare scheinen mir ein guter Kompromiss zwischen Kosten
und Sicherheit zu sein. Da wir im Grunde nicht soviel Speicherplatz brauchen
lohnt sich ein kleineres Modell mit großen Festplatten eher.
> Die haben vor der Lieferung telefonisch angefragt, wie ich es haben will,
Habe ich vom Kollege auch gehört. Kostet AFAIK nicht mehr.
> aber auch ohne deren Hilfe ist es kein Problem, über das Knöpfcheninterface
> des Gehäuses sein RAID zu konfgurieren.
Kenne ich auch so, habe es aber als sehr langwierig in Erinnerung (1%... 5
Min. später, 2%...)
> Zusätzlich haben sie sogar noch eine Cold Spare im Schlitten geliefert.
Wussten Sie schon von Deine Pläne evtl. mehrere davon zu kaufen? ;-)
[Dein Plan à 4 IFT 6210-8 mit 8 320 GB Maxtor- Platten]
Interessant. Auch zu lesen dass Maxtor eine Festplatten-Reihe (MaXLine II
und Plus II) rausbringt mit dieser Absicht "Designed to augment or replace
tape and optical storage solutions".
<http://www.maxtor.com/en/products/ata/enterprise_applications/index.htm>
>> Dafür ist es auch um ca. 1700 EUR günstiger. Man könnte das System in 2
>> RAIDs à 6 Platten (inkl. Spare-Drive) teilen, das erste für die Daten, das
>> zweite für das Backup was z.B. mittels ES-Backup oder Retrospect gesichert
>> werden könnte.
>
> Das würde ich nicht tun. Teile die Sache lieber auf zwei Gehäuse auf.
> Was machtst Du, wenn Dir Dein eines Gehäuse abraucht? Ich hab mich genau
> deswegen für die 8- Bay- Gehäuse entschieden.
Ich sehe es mittlerweile ein...
>> Wenn wir jetzt also das neue RAID in einem für Solaris initialisierten
>> Filesystem an der SUN hängen, hätten wir möglicherweise ein Problem die
>> Datenmenge zu sichern im Falle eines nicht unter Solaris laufender neuen
>> Server. Ist das richtig so?
>
> Trenne Daten- RAID und Backup- RAID.
Backup-RAID aber nur in Form einer Sicherung auf Platten und einer
zusätzlichen kritischer Daten auf das AIT-Laufwerk. Oder die Chefs scheuen
nicht vor den Kosten und nehmen die zusätzliche Sicherung in Kauf.
> Ich würde einen XServe, oder wie die heißen, nie als Produktionsserver
> einsetzen
Das habe ich anderswo (oder war es auch hier?) auch schon gehört.
>> Was würdet Ihr lieber für eine Serverhardware-/ Betriebssystemkombination
>> einsetzen?
> Für den Fileserver Solaris auf Sun Sparc.
Auf SUN-Harware? Wie ist die Erfahrungen im Allgemeinen mit Sparc-Klones?
> Ich würde aber unbedingt SCSI- Platten einsetzen.
Zum Thema hat sich die c't in der aktuellen Ausgabe befasst. Ich dachte
bisher auch immer an SCSI-Platten, aber Kostenmäßig würde ich jetzt lieber
in einem 2. IDE-RAID für Backupzwecke setzen als in einem SCSI-RAID ohne
vernünftiges Backup.
>> Fragen über Fragen die momentan von mir
>> nicht wirklich beantwortet werden können. Höchstens von meine Chefs wenn ich
>> Montag zu den gehe und ein paar Zahlen vorlege ;-)
>
> Da hast Du ja bis Montag noch viel zu tun.
Nebenbei auch noch ein bisschen was ganz anderes. Ich denke mittlerweile
auch an eine Zwischenlösung mit IDE-RAID und Backuplösung ohne neuen Server.
Wenn das Backup stimmt könnte Thomas Server-OS-Wechsel Strategie mir noch
mehr Reflexionszeit geben, die wie ich jetzt schon merke heilende Wirkungen
zeigt.
Gruss,
Yann
Yann Borg
el.k...@de-soc-mac.de (Daniel Krebs) wrote:
>> Nun, damit hast du natürlich nur eine Backupgeneration auf Platte
>> vorrätig. Reicht dir das?
>
> Noch ein Grund mehr, mehrere RAIDs zu benutzen. Zum Beispiel eines für
> die monatlichen Full- Backups und die inkrementellen und eines für die
> wöchentlichen Full- Backups. Und das dann auch noch doppelt.
Heute habe ich beim Radiohören erfahren, dass es Versicherungsunternehmen
für Versicherungen gibt. War mir auch neu ;-)
> Natürlich plant man ein Fileserver- RAID so, daß es nicht von Anfang an voll
> ist. Deswegen könnteYanns Backup- RAID erstmal ausreichen.
So war es auch gemeint. Ich ging von den momentanen 150 GB + nochmal soviel.
Gruss,
Yann
Yann Borg
Thomas...@phg-online.de (Thomas Kaiser) wrote:
>> Wichtig ist jedoch so oder so: Wenn man etwas neues kauft, sollte es für
>> die nächsten paar Jahre reichen oder zumindest bequem erweiterbar sein.
>
> Und an der Stelle könnte es sich sowohl wegen Produktions-RAID als auch
> Backup-Lösung lohnen, mal HSM-Lösungen wie bspw. Sam-FS anzusehen
[...]
Okay, die smarte Lösung von Thomas Kaiser von der ich schon vor Jahren zum
ersten mal hörte ;-)
Aber solche Projekte haben es an sich, nicht genügend durchdacht zu werden
weil einfach aus der Not heraus geboren. Es ist so einfach: Ich bräuchte
sofort mehr Speicherplatz um das bisherige (größtenteils unsortiertes)
Datenbestand auf ein altes Netzwerkvolume zu belassen und das neue,
sortierte Datenbestand, auf das neue draufzuspielen. Dort wird mit OPI
gearbeitet und Cumulus wird ein Auge drauf werfen.
Parallel läuft natürlich das Tagesgeschäft weiter, so dass ich nicht die
Sortierungsarbeit auf einmal von einem Backup auf das vorhandene
leergeräumtes RAID machen kann. Zudem kann ich diese Arbeit zeitlich &
inhaltlich nicht allein überwältigen, das sollen Kollegen im Grafik-Bereich
und Projektmanager auch selbst machen können.
Und mir fällt momentan keine billigere & sicherste Lösung ein als dies mit
einem, wahrscheinlich viel zu Großem IDE-RAID zu machen.
Gruss,
Yann
Yann Borg
pa...@stud.uni-frankfurt.de (Tibor Pausz) wrote:
[SUN Fire 280R Performance im Xinet-Test]
> Nun gut die UltraIII CPUs sind nicht sonderlich fix im Vergleich zu
> anderen aktuellen CPUs, aber bei IO Jobs ist das nicht so wichtig, das
> zählt Durchsatz auf dem Bus.
Also würde für reine Netzwerkperformance ein 2. Prozessor nicht sonderlich
viel ausmachen?
Gruss,
Yann, immer wieder überrascht wie teuer ein Prozessor bei SUN ist.
Yann Borg
(Frank-Christian Kruegel) wrote:
> Ich würde mich hier eher nach einer gebrauchen E250 oder E450 oder den
> entsprechenden Rack-Modellen E220R bzw E420R in der entsprechenden Ausstattung
> umschauen. Damit könnt Ihr einiges an Geld sparen. Und in eine 450'er passen
> intern 12 SCA-Platten.
Somit nicht mehr wirklich günstig da kein IDE-RAID. 12 SCA-Schächte leer zu
lassen wäre außerdem unschön ;-)
> Ich habe hier ein IFT IDE-Raid mit 4 120 GB WD1200JB Platten als RAID5 an
> einer UltraAXi Maschine (sozusagen eine Ultra 10 mit SCSI statt IDE als
> ATX-Standard-Mainboard) hängen, und der begrenzende Faktor ist ganz eindeutig
> das RAID.
In unsere Ultra10 steckt eine 70 GB SCSI Platte -- Modell nicht genau im
Kopf ist aber eine ein Jahr alte 7200 RPM die höchstwahrscheinlich schneller
als das externe SCSI to SCSI RAID-5 mit IFT-SR150 und 6x Fujitsu 36 GB
SCA-Platten (auch 12 Monate alt) ist. Wie dem auch sei: meine
AFP-Durchsatz-Tests über Gigabit-Enet ergaben keine Performance-Unterschiede
zwischen beide Laufwerke. Bei ca. 30 MB/s Schreiben und ca. 25 MB/s Lesen
ist Schluss.
> Wenn die Kiste nichts anderes macht, sollte eine E250 mit 2*400 MHz
> CPUs das locker schaffen.
Du meinst reines Datendurchsatz auf lokales RAID oder Zugriff von Clients
auf AFP-Volume?
Gruss,
Yann
Goetz Hoffart
> Ich bin mittlerweile aber von der Daten- & Backup auf ein RAID Story
> weggekommen und bevorzuge das Backup auf nicht gespiegelte Festplatten.
> Diese können auch nach Gusto erweitert werden... Wir haben noch ein altes
> RAID-Gehäuse mit 10 oder 12 Einschübe in einer Ecke stehen, darin könnte man
> evtl. die Platten einbauen und mit einem IDE-to-SCSI Adapter verbauen und in
> einer SCSI-Kette einbinden.
Hm. Damit hast du aber keine Trennung der Medien voneinander. Wenn es
dir da etwas reißt aufgrund eines amoklaufenden Netzteils oder weil die
Putzfrau gegen den Schrank fällt oder sonstwas, dann ist gleich alles
kaputt. Ein Backup sollte immer eine physikalische Trennung von den
Originaldaten und untereinander aufweisen.
(der den Betreff wg. Outlook geändert hat)
Yann Borg
(Goetz Hoffart) wrote:
[IDE-Backup-Platten in altem SCSI-RAID-Gehäuse]
> Hm. Damit hast du aber keine Trennung der Medien voneinander.
Wie meinst Du?
> Wenn es dir da etwas reißt aufgrund eines amoklaufenden Netzteils oder weil
> die Putzfrau gegen den Schrank fällt oder sonstwas, dann ist gleich alles
> kaputt.
Meine Überlegung war IDE-Festplatten so zu verbauen, dass es ein leichtes
ist die Backup-Kapazität nach Bedarf zu erweitern. Im vorhandenem Gehäuse
würde ich erstmal z.B. 3 Platten à 200 GB einbauen, was für mehrere
Backup-Generationen ausreichen sollte auch wenn die netto-Kapazität vom
RAID-Volume Größer ist. Wenn das Netzteil ausfällt ist ein zweites drin.
Wenn die Putzfrau mit einem Eimer auf das Gehäuse fällt ist wahrscheinlich
erstmal schluss (wobei Sie gezielt im Serverschrank putzen müsste).
> Ein Backup sollte immer eine physikalische Trennung von den Originaldaten und
> untereinander aufweisen.
Die physikalische Trennung wäre in der Lösung vorhanden (50 Meter in der
anderen Gebäude-Ecke).
Gruss,
Yann
Goetz Hoffart
>>>[IDE-Backup-Platten in altem SCSI-RAID-Gehäuse]
>> Hm. Damit hast du aber keine Trennung der Medien voneinander.
> Wie meinst Du?
Wenn du ein Gehäuse mit Platten vollstopfst und auf die ein Backup
fährst, aber dummerweise das Netzteil des Gehäuses alle Platten grillt
oder ein Wasserrohrbruch genau über dem Gehäuse durchtropft oder jemand
dagegen stolpert oder ein Virus bei gemounteten Filesystemen alles
löscht oder ... stehst du mit heruntergelassenen Hosen da, da du dann
kein Backup mehr hast.
Die räumliche Trennung von Backupgenerationen ist IMHO wichtig. Das
heißt: Band nehmen, in einen anderen Raum tragen, dort ins Regal
stellen. Und je nach Wichtigkeit der Daten auch noch Außer-Haus-Sätze
haben.
> Meine Überlegung war IDE-Festplatten so zu verbauen, dass es ein leichtes
> ist die Backup-Kapazität nach Bedarf zu erweitern. Im vorhandenem Gehäuse
> würde ich erstmal z.B. 3 Platten à 200 GB einbauen, was für mehrere
> Backup-Generationen ausreichen sollte auch wenn die netto-Kapazität vom
> RAID-Volume Größer ist. Wenn das Netzteil ausfällt ist ein zweites drin.
Ausfallen bedeutet aber evtl. ein Spannungspuls auf der 5V/12V-Leitung -
und deine drei Platten sind hin. Alles schon passiert.
> Wenn die Putzfrau mit einem Eimer auf das Gehäuse fällt ist wahrscheinlich
> erstmal schluss (wobei Sie gezielt im Serverschrank putzen müsste).
Den Wasserrohrbruch bedacht? Es gibt viele Szenarien, die immer wieder
eines zeigen: ein paar Backup-Generationen sollten räumlich getrennt
aufbewahrt werden.
Ich weiß ja, dass es fürchterlich einfach, schnell und billig ist, sich
einen Stall IDE-Platten hinzustellen und damit glücklich zu sein. Aber
die Entscheidung pro Band oder MO-Disks fiel ja bisher nicht nur, weil
die Dinger teuer, lahm und nicht-einfach sind, es gibt da durchaus gute
Gründe :-)
> Die physikalische Trennung wäre in der Lösung vorhanden (50 Meter in der
> anderen Gebäude-Ecke).
Das ist die rein räumliche Trennung, gut. Die Platten hängen aber immer
noch alle an einem Bus, an einem Netzteil, evtl. in einem Filesystem ...
Tibor Pausz
> Also würde für reine Netzwerkperformance ein 2. Prozessor nicht sonderlich
> viel ausmachen?
Ah, so einfach kann man das nicht sagen. Dies Aussage war eher so zu
verstehen, daß SUN UltraIII eher weniger CPU Power hat als vergleichbare
Geräte anderer Anbieter siehe HP siehe IBM.
Daniel Krebs
<y.b...@arts-others.de> wrote:
> Kenne ich auch so, habe es aber als sehr langwierig in Erinnerung (1%...
> 5
> Min. später, 2%...)
Und wenn Du die Filesysteme einrichtest, wartest Du nochmal? Da muß man
nun wirklich nicht daneben stehen.
> > Zusätzlich haben sie sogar noch eine Cold Spare im Schlitten geliefert.
>
> Wussten Sie schon von Deine Pläne evtl. mehrere davon zu kaufen? ;-)
IMO nicht. Schätze, das mit der zusätzlichen spare hat unser Einkäufer
eingefädelt.
> Backup-RAID aber nur in Form einer Sicherung auf Platten und einer
> zusätzlichen kritischer Daten auf das AIT-Laufwerk. Oder die Chefs
> scheuen
> nicht vor den Kosten und nehmen die zusätzliche Sicherung in Kauf.
Es ist ja eigentlich umgekehrt. Du machst, was die Chefs wollen. Sind
ihnen die Daten nicht wichtig, brauchst Du Dir beim Backup keinen
abzubrechen. Womöglich kannst Du es Dir ganz sparen ;-)
> Wie ist die Erfahrungen im Allgemeinen mit Sparc-Klones?
Da hab ich keine. Hab ledinglich Kingston- RAM in der E 450. Der von Sun
war mir dann doch zu teuer.
> > Ich würde aber unbedingt SCSI- Platten einsetzen.
>
> Zum Thema hat sich die c't in der aktuellen Ausgabe befasst.
Hab ich noch nicht gelesen.
> Ich dachte
> bisher auch immer an SCSI-Platten, aber Kostenmäßig würde ich jetzt
> lieber in einem 2. IDE-RAID für Backupzwecke setzen als in einem SCSI-RAID
> ohne vernünftiges Backup.
Ohne Backup sowie so nicht.
> Nebenbei auch noch ein bisschen was ganz anderes. Ich denke mittlerweile
> auch an eine Zwischenlösung mit IDE-RAID und Backuplösung ohne neuen
> Server.
Das kannst Du ja machen. Das ext. RAID wird ja nicht weggeschmissen,
wenn ein dedizierter Server kommt.
Hab übrigens eben erfolglos versucht, das RAID von Infortrend an einen
NT4- Server (SP6) zu hängen :-( Der bootet nicht, wenn das RAID
eingeschaltet ist. Der Controller (Adaptec AAA 133 U2) sieht es aber,
doch die Kiste bleibt hängen, nachdem er alle devices erkannt hat
(insgesamt gerade mal 9). Am Channel A hängen neben dem RAID noch die
Bootplatte und ein CDROM.
Mit ausgeschaltetem RAID bootet NT und ich kann das RAID hinterher
einschalten und durch ein Rescan des Channel A sichtbar machen. Es wird
aber vom System nicht erkannt. Ich hatte es vorher an einem XP- Rechner
mit Adaptec 2940 UW zu hängen und dort partitioniert. Scheiße, jetzt
weiß ich mir nicht anders zu helfen, als in den Server auch so eine 2940
UW (Hab noch eine da.) einzubauen. Ich glaube, daß es sich um ein SCSI-
Problem handelt, aber was für eins??? Ich werd die Kiste wohl aufmachen
müssen, möglichwerweise sind schon beide internen Stecker für Channel A
belegt :-/ (Ich war das dann aber nicht :-)
Daniel
--
"Das Land wurde nicht, wie die Legende es will, besiedelt
von zähen und unerschrockenen Abenteurern, sondern von Nieten,
die es zu Hause zu nichts gebracht hatten..."
H. L. Mencken in On Being an American
Daniel Krebs
<y.b...@arts-others.de> wrote:
> Heute habe ich beim Radiohören erfahren, dass es Versicherungsunternehmen
> für Versicherungen gibt. War mir auch neu ;-)
Sog. Rückversicherer, ja...
> So war es auch gemeint. Ich ging von den momentanen 150 GB + nochmal
> soviel.
Hmmm, bei meiner Backup- Strategie komme ich auf ca. 12 TB Backup bei
600 GByte zu sichernden Daten. Dabei mache ich, wie ich schrieb,
allerdings alles (wöchentlich full, monatlich full und die ganzen
inkrementellen Backups) doppelt, wobei ich das Dupikat räumlich getrennt
vom ersten Backup halte.
Da Du das ja nicht machen willst, kämest Du bei einer ähnlichen
Strategie auf 1,5 TByte Backup. 1500 GByte/320 GB/Platte = 5 Platten.
Trifft sich gut, macht genau ein 8- Bay- RAID 5 aus 6 PLatten mit 2 hot
spare :-)
Yann Borg
(Daniel Krebs) wrote:
[600 GByte auf 12 TByte backupen]
Feine Sache! Wieviel Generationen von wöchentlichen, monatlichen und
inkrementelle Backups sicherst Du insgesamt? Ich meine wie weit könnt ihr
auf Eure Daten zurückblicken?
> Da Du das ja nicht machen willst,
Das überdenke ich im Augenblick. Das Netzwerk unsers AIT-2 Stack hat gerade
den Geist aufgegeben (fast genau 1 Jahr alt). Sowas passiert natürlich
Freitag um 20:00 Uhr vor dem wöchentlichen Backup... Zum Glück können wir
uns mit einem alten Netzteil behelfen und die Kiste sollte übers Wochenende
ihre Dienste weiter tun.
Kommt wie gerufen, als Grundlage für mein Gespräch Anfang der Woche, bis
dahin kann ich mir die Backupstrategie noch etwas durch den Kopf gehen
lassen ;-)
Ich dachte jetzt an einer Kombination von inkrementelle Sicherungen auf
einem IDE-RAID-5, wöchentliche Sicherungen auf IDE-Festplatten und
monatliche Sicherungen auf AIT-Bänder. Die Lösung lässt sich gut Realisieren
wenn wir tatsächlich nicht über die ursprünglich geschätzten 300 GB hinaus
brauchen. Dann ließe sich (geschätzt) 3 Monate inkrementelles, 1 Monat
wöchentliches und 3 Monate monatliches Backup sichern.
Was hältst Du von dieser Lösung? Die erste Gefahr ist IMHO wenn die
ursprünglichen 300 GB auf das doppelte oder dreifach wachsen, dann haben wir
als erstes ein großes Problem mit den inkrementellen Sicherungen... Wobei
man könnte von Vorne rein das Hauptvolume auf 300 GB partitionieren.
> kämest Du bei einer ähnlichen Strategie auf 1,5 TByte Backup. 1500 GByte/320
> GB/Platte = 5 Platten. Trifft sich gut, macht genau ein 8- Bay- RAID 5 aus 6
> PLatten mit 2 hot spare :-)
Jein, siehe oben. Zumal ich noch keine 320 GB Platten bei irgendein Händler,
geschweige den Festplatten-Hersteller (Maxtor) gesehen habe.
Gruss,
Yann
Daniel Krebs
> Feine Sache! Wieviel Generationen von wöchentlichen, monatlichen und
> inkrementelle Backups sicherst Du insgesamt? Ich meine wie weit könnt ihr
> auf Eure Daten zurückblicken?
Hängt vom Client ab. Maximal 3 Monate, hauptsächlich für Server. Ich
habe letztes Jahr eine Bedarfserfassung gemacht. Viele wollen nur 1 oder
zwei Monate Retention. Nicht jeder kriegt ein wöchentliches Full. Nur
das inkrementelle findet täglich statt. Bin gespannt, ob ich das über
ein GBit- NIC hinkriege. Netbackup kann natürlich mehrere Backups
parallel fahren.
Außerdem gibt es bei uns die Möglichkeit, manuell auf ein HSM zu
archivieren. Das mache ich aber nicht, läuft über eine 34 Mbps- Leitung
in eine andere Stadt.
> Kommt wie gerufen, als Grundlage für mein Gespräch Anfang der Woche
Ganz ungeschickt bist Du ja wirklich nicht <eg>
> Ich dachte jetzt an einer Kombination von inkrementelle Sicherungen auf
> einem IDE-RAID-5, wöchentliche Sicherungen auf IDE-Festplatten und
> monatliche Sicherungen auf AIT-Bänder. Die Lösung lässt sich gut Realisieren
> wenn wir tatsächlich nicht über die ursprünglich geschätzten 300 GB hinaus
> brauchen. Dann ließe sich (geschätzt) 3 Monate inkrementelles, 1 Monat
> wöchentliches und 3 Monate monatliches Backup sichern.
Brauchst Du bei deser Strategie wirklich 3 Monate Retention für das
inkrementelle Backup?
Andererseits mache ich für unsere paar Macs mit Retrospect ein tägliches
"normales" Backup, also ein kumulatives, auf Platte. Das wiederum
sichere ich zweimal wöchentlich auf ein VXA- Band (3 Generationen).
Inzwischen haben einige Clients eine Retention von über 3 Jahren :-)
Es handelt sich aber nur um ca. 30 GByte.
> Was hältst Du von dieser Lösung? Die erste Gefahr ist IMHO wenn die
> ursprünglichen 300 GB auf das doppelte oder dreifach wachsen, dann haben wir
> als erstes ein großes Problem mit den inkrementellen Sicherungen... Wobei
> man könnte von Vorne rein das Hauptvolume auf 300 GB partitionieren.
Ich würde evtl. mehrere kleinere Filesysteme benutzen. Deine Strategie
muß auf den Anforderungen der Nutzer basieren. Was ich dazu sage, ist
irrelevant.
> Jein, siehe oben. Zumal ich noch keine 320 GB Platten bei irgendein Händler,
> geschweige den Festplatten-Hersteller (Maxtor) gesehen habe.
Da ist was dran. Maxtor hatte die 320 GB Platten bereits im Herbst
angekündigt. IMO gibt es aber erst die 250 GB Modelle. Schau mal bei
dchl.festplatten vorbei. Da las ich letztes Jahr was von 600 € pro
Retail- Modell. Oder Du rufst mal bei Starline an.
Daniel, der jetzt aber endlich Episode Vier von Twin Peaks gucken will.
Hab mir die 4 DVDs zu Weihnachten geschenkt. Dazu paßt...poste ich jetzt
lieber nicht :-)
Yann Borg
(Daniel Krebs) wrote:
>> Kenne ich auch so, habe es aber als sehr langwierig in Erinnerung (1%... 5
>> Min. später, 2%...)
>
> Und wenn Du die Filesysteme einrichtest, wartest Du nochmal? Da muß man
> nun wirklich nicht daneben stehen.
Wenn es richtig geplannt ist und man weiss wie lange das dauert. Das war bei
meiner Ersteinrichtung nicht der Fall.
>> Backup-RAID aber nur in Form einer Sicherung auf Platten und einer
>> zusätzlichen kritischer Daten auf das AIT-Laufwerk. Oder die Chefs
>> scheuen
>> nicht vor den Kosten und nehmen die zusätzliche Sicherung in Kauf.
>
> Es ist ja eigentlich umgekehrt. Du machst, was die Chefs wollen. Sind
> ihnen die Daten nicht wichtig, brauchst Du Dir beim Backup keinen
> abzubrechen. Womöglich kannst Du es Dir ganz sparen ;-)
Ich sehe es ein bischen differenzierter, da ich fast schon immer für die
Rechner und Server hier "gesorgt" habe. Anfangs gab es nur die gerade ganz
neuen und ganz aufregenden 200 MB Syquest-Laufwerke und wir ranten von einem
Arbeitsplatz zum anderen mit unsere Cartridges. Zustand längst behoben, Dank
der Einsicht der Chefs und die fast allgemeine Akzeptanz der Lösungen die
ich vorlegte. Ich übernehme somit ganz natürlich ein bischen die Vaterschaft
des ganzem ;-) [Natürlich nur zum Teil, da hier vieles funktioniert was ich
mir ohne gutem Zureden von Listen- und Newsgroupsteilnehmer nie hätte
zusammendenken können -- typisch Quereinsteiger, ist auch gut so].
>> Wie ist die Erfahrungen im Allgemeinen mit Sparc-Klones?
>
> Da hab ich keine. Hab ledinglich Kingston- RAM in der E 450. Der von Sun
> war mir dann doch zu teuer.
Sehe ich ein. Die FC-Platten von Sun sind auch teuer. Sun ist unereichbar
teuer.
>> Nebenbei auch noch ein bisschen was ganz anderes. Ich denke mittlerweile
>> auch an eine Zwischenlösung mit IDE-RAID und Backuplösung ohne neuen
>> Server.
>
> Das kannst Du ja machen. Das ext. RAID wird ja nicht weggeschmissen,
> wenn ein dedizierter Server kommt.
Ich denke schon wieder anders, die fette Lösung mit einer fetten Fire 280R +
IDE- und SCSI-RAID, die Ultra10 als Backup- und HELIOS ColdSpare-Rechner mit
2. IDE-RAID (wobei mir noch nicht wirklich klar ist wie das gehen soll) und
die ganzen wöchentlichen und monatlichen Backup an vorhandene Macs mit
Retrospect. Das ganze Räumlich geteilt wobei wir eine 2. Klimaanlage
einbauen müssten und ein echten Serverschrank für unsern
Hauptserverraümchen.
Je nachdem wieviel Geld für diesen Wahn übrig bleibt, werden wir an der
Ideal-Konstellation knappern.
[Infortrend RAID an NT4- Server]
> Der bootet nicht, wenn das RAID eingeschaltet ist.
Außer das mir das Phenomen in einem anderen Zusammenhang aufgefallen ist,
kann ich nicht weiterhelfen. Damals beim Umzug des alten RAID vom ASIP zur
Ultra10 wollte es plötzlich nicht mehr. Wobei es hier eher an den
Festplatten lag die 2 Jahren ununterbrochen liefen: Einmal ausgeschlatet,
ausgekühlt und wieder eingeschaltet, und schon fingen sie der Reihe nach
kaputt zu gehen (SCSI Seagate 18 GB, 1,5 Zoll Bauhöhe, Bezeichnung
vergessen...Oh doch: im c't Test die lautesten überhaupt).
Gruss,
Yann
Daniel Krebs
> typisch Quereinsteiger, ist auch gut so].
Wer ist das nicht in unserem Alter? Ich bin eigentlich Quantenchemiker
:-)
> Außer das mir das Phenomen in einem anderen Zusammenhang aufgefallen ist,
> kann ich nicht weiterhelfen. Damals beim Umzug des alten RAID vom ASIP zur
> Ultra10 wollte es plötzlich nicht mehr. Wobei es hier eher an den
> Festplatten lag die 2 Jahren ununterbrochen liefen: Einmal ausgeschlatet,
> ausgekühlt und wieder eingeschaltet, und schon fingen sie der Reihe nach
> kaputt zu gehen (SCSI Seagate 18 GB, 1,5 Zoll Bauhöhe, Bezeichnung
> vergessen...Oh doch: im c't Test die lautesten überhaupt).
Mein RAID ist ja neu. Es liegt an der NT- Kiste. Ich weiß nur noch nicht
woran genau.
Als ich das postete, kam ich nicht mehr an die Kiste ran. Ist nicht
meine. Ich bin mir aber fast sicher, daß meine Vermutung sich bestätigen
wird. Der AAA 133 hat drei Kanäle. Und gerade der erste, der auch nach
außen geführt wird, hat auch intern zwei Interfaces, 68-polig und 50-
polig. Und wahrscheinlich wird die Bootplatte am 68- poligem und das
CDROM am 50- poligem hängen. Was mich dabei jedoch erstaunt, ist, daß
das ext. RAID trotzdem vom Controller erkannt wird. Bin gespannt, was
Tibor dazu sagen wird.
Ich werde die Kiste frühestens am Dienstag aufmachen können.
Daniel
Yann Borg
el.k...@de-soc-mac.de (Daniel Krebs) wrote:
>> Kommt wie gerufen, als Grundlage für mein Gespräch Anfang der Woche
>
> Ganz ungeschickt bist Du ja wirklich nicht <eg>
Ich habe wiklich nichts gemacht. Oder doch? Das passiert nicht zum ersten
mal hier, dass sich die Geräte irgendwie melden wie sie es halt tu könnten:
die Frage ist ob sie es tun Aufgrund der Überlegungen sie zu ersetzen oder
ob es nicht damit zusammen hängt und sie wären auch ohne diese Überlegung
kaputt gegangen. Wahrscheinlich ein bischen beides. Aber das wird langsam zu
OT.
>> Ich dachte jetzt an einer Kombination von inkrementelle Sicherungen auf
>> einem IDE-RAID-5, wöchentliche Sicherungen auf IDE-Festplatten und
>> monatliche Sicherungen auf AIT-Bänder. Die Lösung lässt sich gut Realisieren
>> wenn wir tatsächlich nicht über die ursprünglich geschätzten 300 GB hinaus
>> brauchen. Dann ließe sich (geschätzt) 3 Monate inkrementelles, 1 Monat
>> wöchentliches und 3 Monate monatliches Backup sichern.
>
> Brauchst Du bei deser Strategie wirklich 3 Monate Retention für das
> inkrementelle Backup?
Wenn wir 300 GB Daten inkrementel auf 900 GB sichern wollen, dauert es
schätzungsweise > 3 Monate bis sie voll werden. Warum den nicht?
> Andererseits mache ich für unsere paar Macs mit Retrospect ein tägliches
> "normales" Backup, also ein kumulatives, auf Platte.
Mit dem Retrospect-Client über Nacht z.B.? Mit welcher Version? Ich lasse
die Finger davon Weg seitdem der 4.x. Client das alte ASIP-Server zum
Absturz brachte. Aber das wäre durchaus interessant jetzt wo evtl. Platz für
Client-Sicherung wäre? Oder doch mit Synchronize (Pro)? Und später mit
CarbonCopyCloner? Mal schauen. Das Update von Retrospect 4 auf ein aktuelles
5 ist IMO überteuert.
> Das wiederum
> sichere ich zweimal wöchentlich auf ein VXA- Band (3 Generationen).
> Inzwischen haben einige Clients eine Retention von über 3 Jahren :-)
Du übertreibst ;-) Obwohl selbst letzens eine JAZ-Cartridge mit Backup von
meinem ehemaligen-hoch-5 Rechner ;-)
>> Was hältst Du von dieser Lösung? Die erste Gefahr ist IMHO wenn die
>> ursprünglichen 300 GB auf das doppelte oder dreifach wachsen, dann haben wir
>> als erstes ein großes Problem mit den inkrementellen Sicherungen... Wobei
>> man könnte von Vorne rein das Hauptvolume auf 300 GB partitionieren.
>
> Ich würde evtl. mehrere kleinere Filesysteme benutzen. Deine Strategie
> muß auf den Anforderungen der Nutzer basieren. Was ich dazu sage, ist
> irrelevant.
Ich habe irgendwie auch nur laut nachgedcht. Hat schon sehr geholfen, was Du
bis jetzt "gesagt" hast.
Gruss,
Yann
Daniel Krebs
> Aber das wird langsam zu
> OT.
Überhaupt nicht. Vielleicht merkt ein guter Admin einfach, wann es an
der Zeit ist, mal wieder einen Finger zu krümmen ;-)
> Wenn wir 300 GB Daten inkrementel auf 900 GB sichern wollen, dauert es
> schätzungsweise > 3 Monate bis sie voll werden. Warum den nicht?
Probier es. War doch nur 'ne Frage.
> Mit dem Retrospect-Client über Nacht z.B.?
Nachts sind die Macs aus. Nachts werden die Kataloge aufs Band
gesichert.
> Mit welcher Version?
4.3, wo die Kataloge nicht größer als 2 GB werden dürfen :-(
> Ich lasse
> die Finger davon Weg seitdem der 4.x. Client das alte ASIP-Server zum
> Absturz brachte.
Kenne ich sehr gut. War mit AShare 4.x nicht anders. Außerdem kann man
mit Retrospect 4.3 die Zugriffsrechte nicht mitsichern. Hab mir so
geholfen, die Volumes auf dem Backup- Server zu monten und lokal zu
sichern. Geht ja alles per Script. Aber meine verbliebenen AS- Server
sind eh nur Relikte. Ich hab da eine Sammlung von alter Mac- Software
drauf, nach dem sich Götz womöglich die Finger lecken würde ;-)
> Aber das wäre durchaus interessant jetzt wo evtl. Platz für
> Client-Sicherung wäre? Oder doch mit Synchronize (Pro)?
Hab ich schon Jahre nicht benutzt. Synchronisieren kann man doch auch
mit Retrospect.
> Und später mit
> CarbonCopyCloner?
Auja! Teste das mal :-)
> Mal schauen. Das Update von Retrospect 4 auf ein aktuelles
> 5 ist IMO überteuert.
Weißt Du, was Veritas Netbackup kostet? Soweit ich mich erinnere, kostet
ein Update von Retrospect Workgroup 4.3 auf 5.x keine 500 Euro. Das ist
für 20 Clients lächerlich.
> Du übertreibst ;-)
Überhaupt nicht! Es gibt Kollegen, die ein paar Word-, Excel-, und
Ragtime- Dateien in der Woche erzeugen. Was soll da in drei Jahren groß
zusammenkommen? Damit will ich überhaupt nicht sagen, daß sie faul
wären! Andere erzeugen pro Woche 10 GByte an Bildern, dessen Großteil
womöglich nie einer zu Gesicht bekommt...
Oder die ganzen Powerpoint- Präsentationen mit eingebundenen Tiffs
(jaja, möglichst 600 dpi :(, die einmal als Präsentation dienten und von
nun an zum Lebenswerk eines kreativen Menschen gehören...
Oder vergessene downloads von fragwürdigen Seiten, die dummerweise im
Datenordner landeten...
Sind aber immer "wichtige" Daten.
Mit so einer Einstellung kommt ein Admin nie in die Versuchung, mal in
ein fremdes Backup zu linsen ;-) Ich jedenfalls tue das nie.
> Obwohl selbst letzens eine JAZ-Cartridge mit Backup von
> meinem ehemaligen-hoch-5 Rechner ;-)
Du erinnerst mich daran, mal mein erstes Archiv (44 MB Syquest- Pladde)
aus dem Panzerschrank zu holen ;-)
> Ich habe irgendwie auch nur laut nachgedcht. Hat schon sehr geholfen, was Du
> bis jetzt "gesagt" hast.
"Gesagt"?
*g*
Bin jetzt bei Episode 6. Das ist eine wirklich geile Serie gewesen!!!
Daniel
Daniel Krebs
> Maxtor hatte die 320 GB Platten bereits im Herbst
> angekündigt. IMO gibt es aber erst die 250 GB Modelle. Schau mal bei
> dchl.festplatten vorbei. Da las ich letztes Jahr was von 600 € pro
> Retail- Modell.
Das ist Quatsch! Kosten nur noch ca. 450 €.
Schau mal hier rein:
<jtq81v0jdclrie3td...@4ax.com>
Ingrid
Daniel Krebs
> Festplatten lag die 2 Jahren ununterbrochen liefen: Einmal ausgeschlatet,
> ausgekühlt und wieder eingeschaltet, und schon fingen sie der Reihe nach
> kaputt zu gehen
Das kenne ich von den Quantum Lightening, die Apple in bestimmten PM
7x00 und 8x00 verbaut hatte. Die sind immer gestorben, wenn die Kollegen
aus dem Urlaub kamen. Irgendwann habe ich sie dann vorsorglich ersetzt.
Daniel
Thomas Kaiser
<news:1fo6dxo.1hthad719yrhr9N%use...@hoffart.de>:
> Den Wasserrohrbruch bedacht? Es gibt viele Szenarien, die immer wieder
> eines zeigen: ein paar Backup-Generationen sollten räumlich getrennt
> aufbewahrt werden.
Und selbst das will noch wohlüberlegt sein.
Thomas, dem grad die Story mit dem Serverraum im 5. Stock und der Lagerung
der Backups im Keller einfällt --> Brand im 5. Stock und der Keller war voll
Löschwasser ;-)
Thomas Kaiser
<news:BA39DF09.2FF42%y.b...@arts-others.de>:
> Die Erfahrung zeigt aber klar, dass Speicherkapazitäten dazu neigen komplett
> gefüllt zu werden, egal wie Groß sie ursprünglich waren.
Exakt. Und das um einen beliebigen Faktor x schneller als den, den Du im
schlimmsten Fall kalkuliert hättest ;-)
Hint: Während ganz "Repro-Land" von Dateisystemen im TByte Bereich besetzt
ist, widersetzt sich ein kleines Dorf vor den Toren von München weiterhin.
Dort sind insg. ca. 300 GByte auf drei Servern online, der Rest wird mit
einer Workflow-Software auf einer DLT-Jukebox verwaltet. Unnötig zu
erwähnen, daß die 100 GByte-Lösung die Anforderungen an das Backup senkt,
bei den Mitarbeitern ein Gefühl für die Wertigkeit von Daten entstehen lässt
und wenig administrativen Aufwand nach sich zieht --> das Ein-/Auslagern
nebst Auftragsrecherche geht bequem per (MacOS- oder OS/2-)Programm...
Die TByte Fraktion (bzw. ganz konkret deren Admins) sind entweder Kandidaten
für Alkoholismus oder sonstigen Drogenkonsum und haben aufgrund Dauersorgen
vermutlich eine recht niedrige Lebenserwartung (denn wie Daniel schon so
treffend bemerkt hat, treffen sie ja meist nicht die Entscheidungen -- weil
sie nicht wollen/können -- leiden aber nichtsdestotrotz darunter; Ausnahmen
bestätigen wie immer die Regel)
>> wobei sich da dann auch die Frage stellt, wie die Daten dort gesichert
>> werden (Dateisystem mit populärer Backup-Lösung oder Helios Bordmitteln
>> oder per UNIX Tools in Images oder was-auch-immer)
>
> Nächstes Dilemma. Erstere Lösung in Form von Retrospect wäre mir vertraut,
> könnte aber zu inkonsistente File-IDs führen (hat wer Erfahrung mit
> Retrospect und OPI-Daten?).
Ich nicht. Es erscheint aber offensichtlich, daß eine (versehentlich
gelöschte) Datei bei deren Wiederherstellung eine neue File-ID bekommt, bzw.
die Vergabe der ID außerhalb Deines Zugriffs liegt.
Insg. würde ich den IDs aber nur insofern Bedeutung beimessen, als das
*wirklich* für Eure angedachten Workflows von Bedeutung sein sollte. Zumal
Ihr ja anscheinend eh lauter gut erzogene Leutchen vor Ort habt, wenn es
stimmt, daß Du nur so selten was aus dem Backup zerren musst?
> ES-Backup scheint nur auf Bänder sichern zu können, fällt also aus, und
> ein UNIX-Tool kann ich nicht bedienen :-(
ES-Backup *ist* ein "UNIX-Tool", welches ein Mac-Frontend mitbringt ;-)
BTW: Die Softwareschmiede hinter ES-Backup ist klein genug, daß Du wohl
schnell und kompetent Antworten auf Fragestellungen oder Feature Requests
erwarten können solltest.
Es gibt nebenbei gesagt auch noch zwei (mir bekannte) weitere Anbieter, die
im selben Segment aktiv sind:
<http://www.dimm.de> und <http://www.archiware.com>
Sind alle nicht besonders gross und ich traue mich zu sagen, daß man --
vernünftige und für mehr als einen potentiellen Kunden interessante
Argumente vorausgesetzt -- mit wohlformulierten Feature-Requests nicht auf
taube Ohren stösst.
> Okay. Also Backup-Rechner mit einzel-Festplatten am nächsten Flurende mit...
> Mac OS X und ein auf Kommandozeilen beruhendes Backup-Programm was Daten im
> UNIX-Format quer durchs Netz schleust und auf ein UFS-Volume sichert?
Hä? Woher kommt MacOS X auf einmal?
> Elegant für das Restaurieren im Migrationfall, aber gibt es eine GUI für die
> Alltagsrestauration?
Ich stecke immer noch in den Überlegungen zu einem kombinierten
Backup-/aktiven Synchronisierungs-Szenarium für zwei EtherShare Server (das
aber aufgrund Prioritätenverschiebungen bei dem Kunden immer wieder nach
hinten rückt -- die oberen Etagen wollen "sichtbare" Erfolge sehen... was ja
bei Backup nur im "worst case" auffällt, dann allerdings mit negativem
Vorzeichen)
Die Grundidee dahinter ist die, eine Anzahl Backup-Generationen "live"
mitzunehmen, d.h. bei Änderungen an einem Bild auf dem Produktionsserver,
dieses direkt nach Abspeicherung auf dem Standby-Server im anderen
Brandabschnitt zu verschieben (dort stehen 1 bis x separate Volumes für
dieses Instant-Backup bereit, deren Inhalt rotiert wird --> speichert der
Retuscheur also x-mal nacheinander falsch -- verbraucht also die maximale
Anzahl an Generationen -- ist der Nutzen dieser Funktion praktisch wieder ad
absurdum geführt. Das ist aber ein eher theoretischer Fall)
Parallel wird in bestimmten Abständen (angedacht nächtlich) ein Vollbackup
gemacht (dieses aber um die Netzlast gering zu halten inkrementell, d.h. nur
die Sachen, die sich wirklich geändert haben, werden synchronisiert) und
eben dazwischen inkrementell gesichert. Soweit also absolut nichts
Besonderes...
Der Clou an der Sache ist aber, daß es erstens für das Restore nicht einmal
ein GUI bräuchte (die Dateifassungen stünden ja per AFP zur Verfügung) und
zweitens die IDs immer konsistent sind und drittens der Backup-Server im
Falle des Falles (Ausfall des Produktivservers *oder* des RAIDs am demselben
*oder* der Cumulus-Lösung -- letzteres übrigens "wahnsinnig" stabil auch
unter UNIX ;-) per "Knopfdruck" in kurzer Zeit einen Teil der Funktionalität
oder die vollständige übernehmen kann.
So gibt es das Szenarium, daß nur die Cumulus-Funktionalität umzieht
(Mountpoints und vorangestellten Proxy umstellen) oder eben auch der
komplette File-/OPI-/Print-Server, etc.
> Alltag ist vielleicht nicht ganz richtig, in den letzten 6 Monaten musste
> ich AFAIR ein- bis zweimal eine Datei Wiederherstellen.
Dann wird die oben dargestellte Möglichkeit uninteressant sein (kostet wohl
auch einiges, wobei ich da immer noch keinen exakten Überblick habe --
Feature Freeze weiterhin in weiter Ferne)
> Wenn ich mir die Systemhäuser "um die Ecke" anschaue, neigen fast alle in
> Richtung SUN zu schauen.
Ist wohl das, was man als "gesund konservativ" bezeichnen könnte ;-)
Ich glaube auch gehört zu haben, daß die Supportfälle auf Sun-Hardware einen
vergleichsweise niedrigen Anteil haben... bzw. hat mir jemand, der denselben
Job wie ich macht, mal gesteckt, daß er sich selbst arbeitslos gemacht hat,
weil er einige Server durch Suns ersetzt hat (und jetzt nur noch ab und zu
zum Nachgucken kommt, anstatt sich für den Kunden teure Nächte um die Ohren
schlagen zu dürfen)
>> Bzgl. Sun sollte auch schon eine 280er in Minimalkonfiguration deutlich
>> schneller sein als Eure Ultra10 (kostet dann aber auch nur zehn KEUR).
>
> Kann man sie im Zweifelsfall mit einem 2. Prozessor nachrüsten?
AFAIK ja.
Kurze Anekdote: Ich saß neulich mit Techniker-Spezl bei ein paar Bieren
zusammen und er erzählte seine Quereinsteiger-Story (war Controller-Heini
und sollte bei Systemhaus aufräumen -- da Not am Mann war, nahmen sie ihn
mit auf Installationen --> jetzt ist er hier in Bayern schon sowas wie eine
Institution auf dem speziellen Gebiet ;-)
Der hatte ursprünglich nur mit Suns zu tun und erzählte mir, wie schwer es
ihm gefallen sei, dann auch Macs mitzumachen. Denn von den Suns war er nur
"aufmachen, reinstecken, einschalten, läuft" gewohnt -- egal ob Prozessor,
Speicher, PCI-Karten, was-auch-immer... Das ist IMO schon bezeichnend (und
dafür zahlt man halt eben mit ;-)
> Weshalb ich nur Biprozessor-Maschinen aufgelistet habe liegt ein wenig
> daran, dass AFAIR Daniel irgendwann meinte Gigabit-Enet auf eine
> Einprozessor-Maschine (wie die Ultra10) kein Sinn macht.
Die Aussage nebst Testergebnissen kannst Du eigentlich auch auf Helios'
Webseiten nachlesen: <http://translate.google.com/translate?u=http%3A%2F%2Fw
ww.helios.de%2Fnews%2Fnews99%2FN_14a_99.html&langpair=en%7Cfr&hl=de&ie=ISO-8
859-1&prev=%2Flanguage_tools> ;-)
Inwiefern man davon ausgehend noch verlässlich Rückschlüsse auf heute
aktuelle Server (und die höheren internen Bandbreiten, schnelleren
Prozessoren, etc.) ziehen kann, entzieht sich aber meiner Kenntnis (ich habe
normalerweise erst dann mit Installationen zu tun, wenn Kaufentscheidungen
schon längst gefallen sind -- und dann ist es normalerweise egal bzw. will
niemand auch noch Geld dafür ausgeben, daß ihm jemand einen Fehlkauf
meßtechnisch attestiert ;-)
Tja, wahrscheinlich hat das alles da oben nur noch zu mehr Konfusion geführt
-- war aber nicht meine Intention. Aber im Usenet fühle ich mich frei genug,
nur Anregungen zu geben -- ohne zielgerichtete Analysen durchzuführen (das
bedeutet ja echte Arbeit -- <grusel> ;-)
Gruss,
Thomas
Daniel Krebs
> Gruss,
>
> Thomas
Kannst Du bitte Deinen postings ein Inhaltsverzeichnis hinzufügen?
Daniel,
Danke
Thomas Kaiser
<news:1foc346.1ixmgft1mvstooN%el.k...@de-soc-mac.de>:
> Kannst Du bitte Deinen postings ein Inhaltsverzeichnis hinzufügen?
Ab 10 KByte Postings geschieht das automatisch. Davor sperrt sich ein
Relevanz-Filter dagegen...
Tja, vielleicht erleben meine Hände nach dem Überwinden der sylvestrischen
Brandverletzungen grad ihren Frühlung und toben sich mangels Alternativen im
Usenet aus?
Gruss,
Thomas, der letztes Jahr mal gaudihalber eine Analyse von Usenetpostings
unter den Aspekten Mengenverhältnis von Header vs. eigenen Gedanken vs.
Zitaten vs. Signatur automatisch durchführen hat lassen (und sich daher
traffic-mässig als *absolut* harmlos einstuft :-))
Yann Borg
Thomas...@phg-online.de (Thomas Kaiser) wrote:
[Die Astérix-Lösung]
> Dort sind insg. ca. 300 GByte auf drei Servern online, der Rest wird mit
> einer Workflow-Software auf einer DLT-Jukebox verwaltet.
Sind die Daten auf der Jukebox eine einfache Verlagerung von Online-Daten?
Oder dient die Jukebox auch als Datenarchiv?
Wäre heutzutage z.B. 1 oder 2 billige IDE-RAID-5 (evtl. als RAID-5-1 der
Ausfallsicherheitshalber) und die Workflow-Software nicht besser geeignet
als eine DLT-Jukebox? Beliebig durch weitere immer größere und billigere
IDE-RAID erweiterbar?
Ist die Jukebox redundant ähnlich aufgebaut wie die "echten" Online-Daten
(RAID-1-Jukebox). Was passiert wenn alle Bänder in der Library voll sind?
Kommt eine neue rein? Und wenn die alte Lib durch eine Online-Bildanfrage
schnell wieder gebraucht wird, wird sie automatisch wieder eingefahren?
Ich meine damit, dass solche Jukebox auch ihre Grenzkapazität haben die
evtl. billige IDE-RAIDs für manche Anforderungen mittlerweile auch anbieten
können. Wohlgemerkt, letztendlich doch TBytes, als Band-Library oder als
IDE-RAID, aber Dank intelligente Workflow-Software, smart-verwaltete TBytes
;-)
Wenn ich die Aussage von Daniel "nie wieder Roboter" oder die der
heise-Redaktion (dessen DLT-Lib ein Sorgenkind zu sein schien) betrachte
frage ich mich ob es sich lohnt, für unsere Bedürfnisse Datensicherung auf
Band-Roboter zu machen. Ich kann nicht einschätzen was man sich für ein
Ärger damit einholt.
> Unnötig zu erwähnen, daß die 100 GByte-Lösung die Anforderungen an das
> Backup senkt, bei den Mitarbeitern ein Gefühl für die Wertigkeit von Daten
> entstehen lässt und wenig administrativen Aufwand nach sich zieht --> das
> Ein-/Auslagern nebst Auftragsrecherche geht bequem per (MacOS- oder
> OS/2-)Programm...
Die Vorteile liegen auf der Hand.
[Datensicherung und File-IDs]
> Insg. würde ich den IDs aber nur insofern Bedeutung beimessen, als das
> *wirklich* für Eure angedachten Workflows von Bedeutung sein sollte.
Da muss ich blöd nachfragen: Sind den konsistente File-IDs nicht
unverzichtbar im Einsatz mit OPI?
> Zumal Ihr ja anscheinend eh lauter gut erzogene Leutchen vor Ort habt,
> wenn es stimmt, daß Du nur so selten was aus dem Backup zerren musst?
Wirklich. Es werden aber auch abertausende Kopien von Xpress-Daten gemacht.
Und das sind die die am meisten dazu neigen korrupt zu werden. Von (fast)
jedem Layout-Stand gibt es eine Datei, abhängig von wer die Jobs anlegt: ich
gehöre mittlerweile eher zur InDesign-Fraktion die nicht vor kaputte Dateien
scheuen muss. [BTW: ich konnte irgendwann ein kaputtes Xpress-Dok in ID
problemlos öffnen...]
> > Okay. Also Backup-Rechner mit einzel-Festplatten am nächsten Flurende mit...
> > Mac OS X und ein auf Kommandozeilen beruhendes Backup-Programm was Daten im
> > UNIX-Format quer durchs Netz schleust und auf ein UFS-Volume sichert?
>
> Hä? Woher kommt MacOS X auf einmal?
Wäre halt der Fall wenn nicht die Ultra10 als Backup-Maschine eingesetzt
wird weil wir noch kein Ersatz für sie haben und wir keine 2. ES-Lizenz
hätten. Ich dachte ein MacOS X Rechner mit einer UFS-Partition könnte die
Daten im "ES-Format" mittels UNIX-Kommando übers Netz kopieren.
[Backup-/aktiven Synchronisierungs-Szenarium für zwei EtherShare Server]
> [...]
Also doch 2 ES-Lizenzen. Klingt sehr interessant und ist tatsächlich eine
Überlegung Wert...
> Die Grundidee dahinter ist die, eine Anzahl Backup-Generationen "live"
> mitzunehmen, d.h. bei Änderungen an einem Bild auf dem Produktionsserver,
> dieses direkt nach Abspeicherung auf dem Standby-Server im anderen
> Brandabschnitt zu verschieben (dort stehen 1 bis x separate Volumes für
> dieses Instant-Backup bereit, deren Inhalt rotiert wird --> speichert der
> Retuscheur also x-mal nacheinander falsch -- verbraucht also die maximale
> Anzahl an Generationen -- ist der Nutzen dieser Funktion praktisch wieder ad
> absurdum geführt. Das ist aber ein eher theoretischer Fall)
Also ist jeder "letzter Stand" einer Datei auf ein "letzten Stand" Volume
abgelegt? Uns würde auch eine 1 zu 1 Kopie des aktuellen Volume reichen,
vorausgesetzt es laufen inkrementelle Vollbackups in regelmäßige Abstände.
Auf die schnelle die Datei Wiederherzustellen die vor 2 Stunden geschrieben
wurde ist Angesichts des Aufwandes overdone (extra-Volume dafür, d.h.
Speicherplatz dafür, d.h. Backup dafür...).
> Der Clou an der Sache ist aber, daß es erstens für das Restore nicht einmal
> ein GUI bräuchte (die Dateifassungen stünden ja per AFP zur Verfügung)
Im Genuss des ersten Clous könnten wir mit o.g. Vorschlag nicht kommen.
> und zweitens die IDs immer konsistent sind
Aber in diesem.
> und drittens der Backup-Server im Falle des Falles (Ausfall des
> Produktivservers *oder* des RAIDs am demselben *oder* der Cumulus-Lösung --
> letzteres übrigens "wahnsinnig" stabil auch unter UNIX ;-) per "Knopfdruck" in
> kurzer Zeit einen Teil der Funktionalität oder die vollständige übernehmen
> kann.
Und in diesem. Und das wäre IMHO das wichtigste im Falle eines Ausfalls.
> > Alltag ist vielleicht nicht ganz richtig, in den letzten 6 Monaten musste
> > ich AFAIR ein- bis zweimal eine Datei Wiederherstellen.
>
> Dann wird die oben dargestellte Möglichkeit uninteressant sein (kostet wohl
> auch einiges, wobei ich da immer noch keinen exakten Überblick habe --
> Feature Freeze weiterhin in weiter Ferne)
"Kostet auch einiges" ohne Sicherung aller Daten-Versionen?
[Gute Argumente für Sun-Hardware als Server]
Ich bin ja schon längst überzeug. AFAIR hat sich Thomas Ludwig (der vor 10
Monate ähnliche Fragen wie ich hier stellte), letztendlich dann auch für
eine Sun Fire 280R entschieden.
> > Weshalb ich nur Biprozessor-Maschinen aufgelistet habe liegt ein wenig
> > daran, dass AFAIR Daniel irgendwann meinte Gigabit-Enet auf eine
> > Einprozessor-Maschine (wie die Ultra10) kein Sinn macht.
>
> Die Aussage nebst Testergebnissen kannst Du eigentlich auch auf Helios'
> Webseiten nachlesen: <http://translate.google.com/translate?u=http%3A%2F%2Fw
> ww.helios.de%2Fnews%2Fnews99%2FN_14a_99.html&langpair=en%7Cfr&hl=de&ie=ISO-8
> 859-1&prev=%2Flanguage_tools> ;-)
Danke für die Aufmerksamkeit, einfach köstliche Übersetzung :-) Zum Teil zum
Kaputt lachen [Serverkonfiguration O-Text: "Serveur: Unité centrale de
traitement ultra 60 360, cachette du mb 2, 512MB RAM duelle du soleil, carte
v.2 de gigabit du soleil". "cachette" heisst "Versteck" und was die Sonne
mit Gigabit-KArten zu tun hat, frage ich mich immer noch ;-]
> Inwiefern man davon ausgehend noch verlässlich Rückschlüsse auf heute
> aktuelle Server (und die höheren internen Bandbreiten, schnelleren
> Prozessoren, etc.) ziehen kann, entzieht sich aber meiner Kenntnis
Genau das wäre aber interessant. Ich habe schon überlegt auf einer der
Duallen G4-Maschinen per Firmware ein Prozessor auszuschalten und ein paar
LAN-Tests durzuführen. Ist mir Angesichts mangelnder Zeit zu Aufwendig. Aber
evtl. kann Jemand präzise über den Nutzen eines Zweitprozessors bei
LAN-Tests und Gigabit-Enet spekulieren? ;-) Ist sicherlich sinniger wenn der
Server auch noch OPI macht, aber um wie viel? (Letzens mit der Ultra10 2
fette Druckjobs ohne OPI abgeschickt + 10 grosse Bilder umrechnen + LanTest
per Gigabit Enet: der Lantest hielt sich wacker (ca. 10 MB/s Schreiben, 8
MB/s Lesen) aber das OPI-event hat sich ewig Zeit gelassen, so sehr dass ich
es abgebrochen habe.
> Tja, wahrscheinlich hat das alles da oben nur noch zu mehr Konfusion geführt
> -- war aber nicht meine Intention.
Tatsächlich, und jetzt wo ich schon fast eine Lösung vorschlagen konnte ;-)
Ich bin trotzdem für die Konfusion Dankbar, da wir bei der Planung jetzt
schon die Komponente "intelligente Workflow-Software" berücksichtigen
können, auch wenn wir wahrscheinlich nicht gleich mit dessen Realisierung
anfangen werden. Die Frage "Roboter" oder "IDE-RAID" steht aber noch in der
Luft. Wenn Roboter, dann eins auf AIT basierend, da wir solche Medien hier
schon haben. Es könnte vorerst auch das Backup machen bis es dann als
Online-Speichermedium dienen kann. Dann könnte auch unser aktuelle AIT-Stack
die (wöchentliche/monatliche) Datensicherung machen und ein IDE-RAID wäre
mit der inkrementellen beschäftigt.
Oder wir hollen uns eine zweite ES-Lizenz (eine kleine 5. Lizenz) die auf
der Ultra10 laufen könnte und eine Parallel-Sicherung der Daten durchführt.
Oder eine Kombi aus Jukebox und Parallel-Sicherung auf IDE-RAID. Das
schlimme ist das es unmengen an Lösungen gibt und ich nicht einschätzen kann
wieviel das ganze kostet und wieviel die Chefs für was ausgeben werden
wollen -- wenn dieses "was" auf Spekulationen eines eventuellen
Datenverlustes basiert.
Gruss,
Yann
Thomas Kaiser
<news:BA3F33CA.302F2%y.b...@arts-others.de>:
> Sind die Daten auf der Jukebox eine einfache Verlagerung von Online-Daten?
> Oder dient die Jukebox auch als Datenarchiv?
Diese Lösung erzwingt zuerst mal ein starres Korsett der Auftragsdaten
(unterteilt in sog. A-/B- und C-Knoten), die wahlweise ausgelagert (eben per
Library) oder online sein können. Das ganze Ein-/Auslagern wird bequem per
GUI gesteuert und kann auch zeitlich voraus geplant werden (also bspw. das
autom. Einlagern eines Auftrags, der von der Kundenkorrektur retour kam, um
5:00 Uhr in der früh, damit die Frühschicht weiter retuschieren kann. Oder
das Kopieren eines Bildes aus einem offline-liegenden Auftrag in einen
aktuellen, der gerade online ist)
Ob sich diese Workflow-Lösung (die übrigens noch einiges anderes macht wie
bspw. Kalkulation, Fakturierung, etc.) auch mit IDE-Platten oder allg. RAIDs
versteht, entzieht sich meiner Kenntnis.
Aber ganz allgemein gibt es schon Geräte (bspw. von Quantum), die mit
IDE-Platten vollgestopft sind, sich aber extern wie ein SCSI-Bandwechsler
verhalten. Primär wird sowas aber heutzutage als transparenter
Zwischenspeicher vor Libraries genutzt, um Backups drastisch zu
beschleunigen.
> Wenn ich die Aussage von Daniel "nie wieder Roboter" oder die der
> heise-Redaktion (dessen DLT-Lib ein Sorgenkind zu sein schien) betrachte
> frage ich mich ob es sich lohnt, für unsere Bedürfnisse Datensicherung auf
> Band-Roboter zu machen.
Wenn eine Library nur für Backup eingesetzt wird, sind nach meiner Erfahrung
die Probleme nicht so gross. Wird allerdings die Library für so eine
Archiv-Lösung, wie oben angesprochen, benutzt, so sind die Verschleiß-
erscheinungen viel drastischer. In so einem Fall sind mindestens zwei
Laufwerke in der Library Pflicht (damit der Laden nicht steht, wenn sich ein
Band in einem Laufwerk verheddert) und um die Nerven zu schonen, ein
entsprechender Supportvertrag (Second Level Support für eine der Libraries
macht übrigens die in diesem Thread schon mehrfach erwähnte Fa. Starline :-)
> Da muss ich blöd nachfragen: Sind den konsistente File-IDs nicht
> unverzichtbar im Einsatz mit OPI?
Tja, da die Suche nach der File-ID von der Priorität her an zweiter Stelle
nach der Suche per Pfad kommt (also immer dann zuschlägt, wenn das Feinbild
umbenannt oder verschoben wurde) halte ich es schon für wichtig, auf
konsistente IDs zu achten.
Die möglichen Konsequenzen hängen natürlich stark vom Workflow ab...
> Ich dachte ein MacOS X Rechner mit einer UFS-Partition könnte die
> Daten im "ES-Format" mittels UNIX-Kommando übers Netz kopieren.
Das kann er auch. Das Zieldateisystem ist dabei tatsächlich nicht weiter von
Belang. Allerdings liegen die Daten dann anschl. immer noch im ES-eigenen
Format vor, d.h. man nicht einfach über einen anderen FileSharing Daemon
drauf zugreifen kann (ohne Verlust an Metadaten und/oder Resourceforks).
Mal schauen, wann Helios xtar freigibt; dann könnte man sich evtl. auch eine
MacOS X Maschine als Backup-Host vorstellen (muß dann aber wieder auf die
Konsistenz der IDs pfeifen)
[Idee eines Live-Backup]
> Also ist jeder "letzter Stand" einer Datei auf ein "letzten Stand" Volume
> abgelegt?
Im Prinzip ja: Man muß ja quasi mit leeren Volumes auf dem Backup-Server
anfangen, um eine Konsistenz der IDs zwischen Produktions- und Backup-Server
zu erreichen (zumindest muß man peinlichst einen potentiellen Konflikt mit
identischen IDs vermeiden).
> Uns würde auch eine 1 zu 1 Kopie des aktuellen Volume reichen, vorausgesetzt
> es laufen inkrementelle Vollbackups in regelmäßige Abstände.
Da ich ein Freund von durchdachten Lösungen bin (die Universalausrede für
überzogene Termine ;-) wird das Ganze natürlich so zu konfigurieren sein,
daß man auf einer "per Volume" Basis definieren kann, wie die Speicherung
mehrerer Generationen vonstatten gehen soll (also wahlweise Anzahl
Dateifassungen oder Anzahl Tage)
> Auf die schnelle die Datei Wiederherzustellen die vor 2 Stunden geschrieben
> wurde ist Angesichts des Aufwandes overdone
Nicht unbedingt. Es kommt darauf an, was die Anforderungen sind. In dem
Szenarium bei dem Kunden läuft momentan ein perfekt eingespielter
dezentraler Workflow (einer der ganz wenigen, an dem mehr als 100 Leute
beteiligt sind und trotzdem alles klappt), der dafür sorgt, daß quasi
nebenbei immer noch ältere Fassungen einer Datei vorhanden sind (auf den
lokalen Macs eben). Zerschießt es eine Xpress-Datei oder zerbröselt ein
Bild, so ist der Schaden aktuell immer noch leicht zu begrenzen. Bei einer
zentralen Lösung, bei der alle Daten auf dem Server zu sein haben, wäre das
nicht mehr gegeben, d.h. hier muß dieses Gefahrenpotential eben anders
abgefangen werden.
> (extra-Volume dafür, d.h. Speicherplatz dafür, d.h. Backup dafür...).
Hmm... Backup davon braucht man eigentlich keines zu machen, da das ja das
Backup darstellt (muß man aber genau durchplanen, damit einem nicht
unvorhergesehene Ausfälle doch die Daten schreddern können)...
Also nochmal zur Erläuterung: Auf dem Produktionsserver "A" sind auf einem
bspw. 4 TByte grossen Dateisystem verschiedene Volumes definiert. Auf
Backup-Server "B" ist mindestens der doppelte Platz vorhanden. Nächtlich
wird A mit B abgeglichen, so daß B soz. immer den letzen Stand mit maximal
24 Stunden Latenz vorhält (und das in einem Zustand, in dem man *sofort*
damit weiterarbeiten kann, wenn A explodiert oder ähnliches).
Für manche Volumes auf A wird nun definiert, daß bei Änderungen über den Tag
hinweg einfach bis zu einer Anzahl x alle Varianten dieser Datei auf B in
separate Volumes (wegen den IDs!) gesichert werden (und dabei die jeweils
älteren Fassungen einfach durchrotiert werden). Zerschießt es eine Datei, so
kann man diese entweder per AFP von Server B holen (manchmal problematisch
wegen File-ID) oder aber per GUI (ich denke da momentan an Webmin, da das
ausreichend sein sollte) wieder von B nach A gespielt werden. Bzgl. der
Pfade hilft ein kleines Droplet, das die Pfade, wie sie der Client sieht, in
die entsprechenden UNIX-Pfade auf dem Server umwandelt. Wenn mich die Lust
packen sollte, mich intensiver mit XML-RPC zu spielen, packe ich evtl. den
ganzen GUI-Kram gleich in ein Mac-only GUI...
Diese Sache mit den x aktuellsten Versionen kann andererseits noch dazu
genutzt werden, simpelst im Falle, daß Server B den Produktionserver
ersetzen muß, das nächtliche Vollbackup auf den gerade aktuellsten Stand zu
bringen (einfach die inkrementell letzten Änderungen in das Vollbackup
"mergen" und man hat den Stand, wie er eine Minute vorher noch auf Server A
war, wieder online im Netz)
Man kann also jederzeit A vom Netz nehmen und auf B mit dem zuletzt
aktuellen Stand auf A weiterarbeiten und hat andererseits trotzdem 1-x
ältere Versionen zus. auf B liegen, so daß auch Aktionen von vor ein paar
Tagen noch rückgängig gemacht werden können.
> evtl. kann Jemand präzise über den Nutzen eines Zweitprozessors bei
> LAN-Tests und Gigabit-Enet spekulieren? ;-)
Zweite CPU --> Mehr Power. Tibor führte hier schon vor längerem mal aus, daß
die Performance, die im LAN erreichbar ist, durchaus von CPU-Power (wegen
den Treibern) abhängen kann...
> Ist sicherlich sinniger wenn der Server auch noch OPI macht, aber um wie viel?
EtherShare OPI reisst je CPU einen opisrv Task auf, d.h. mit jeder zus. CPU
können mehr Dinge parallel passieren. IMO skaliert das Ganze ziemlich gut
mit der Anzahl CPUs...
Also kurz und knapp: Wenn Du Dir heute eine Maschine mit einem Prozessor
zulegst, die man aber auf bspw. 4 (besser wären evtl. 8, wenn Ihr
ungebremste Wachstumsanfälle haben solltet ;-) erweitern kann, hast Du
später jederzeit die Möglichkeit, bei Engpässen nach Bedarf zu reagieren.
Und behalte auch Daniels Tipp mit Kingston RAM im Hinterkopf -- das hilft
ebenfalls initial Geld zu sparen...
> Ich bin trotzdem für die Konfusion Dankbar, da wir bei der Planung jetzt
> schon die Komponente "intelligente Workflow-Software" berücksichtigen
> können,
Das will aber wirklich wohlüberlegt sein, da man sich vom Arbeitsfluß her
schon verdammt darauf einstellen muß. Es sind verschiedene Lösungen am Markt
(bspw. ISY II, auf das ich mich weiter oben bezog, Opas-G oder OPIX). Zum
Teil versuchen die Funktionalitäten von Bilddatenbanken zu übernehmen, zum
Teil von Agentursoftware...
> Das schlimme ist das es unmengen an Lösungen gibt und ich nicht einschätzen
> kann wieviel das ganze kostet und wieviel die Chefs für was ausgeben werden
> wollen -- wenn dieses "was" auf Spekulationen eines eventuellen Datenverlustes
> basiert.
Dann versuch doch zumindest für den Aspekt mal in Zahlen zu fassen, was wann
in welcher Phase ein Daten-/Datenbank- oder Serververlust kosten kann.
Spätestens, wenn Ihr für Dritte Bilddatenbanken hostet, kommt dem Thema
Verfügbarkeit noch mal eine ganz andere Rolle zu. Während man bei der
Auslieferung von Werbemitteln evtl. durch Ausfälle verlorene Zeit meistens
wieder hereinholen kann, ist das mit online verfügbaren Medien wie eben
Webfrontends für Datenbanken eine andere Sache...
Gruss,
Thomas
Yann Borg
Borg) wrote:
> (Letzens mit der Ultra10 2 fette Druckjobs ohne OPI abgeschickt + 10 grosse
> Bilder umrechnen + LanTest per Gigabit Enet: der Lantest hielt sich wacker
> (ca. 10 MB/s Schreiben, 8 MB/s Lesen)
Mein Händler meinte es gäbe ein Performance Problem mit der CD 18 (aka. ES
3.1). Druckerqueues würden mit enormer Verzögerungen starten und trotzdem
ungewöhnlich viel Leistung für sich beanspruchen. HELIOS sei mit höchster
Priorität dabei diesen Fehler zu beheben.
Gruss,
Yann
Thomas Kaiser
<news:BA3F751A.3047F%y.b...@arts-others.de>:
> Mein Händler meinte es gäbe ein Performance Problem mit der CD 18 (aka. ES
> 3.1). Druckerqueues würden mit enormer Verzögerungen starten und trotzdem
> ungewöhnlich viel Leistung für sich beanspruchen.
Mir ist dieser Fehler all die Monate, in denen ich mit der Beta1 der neuen
Versionen auf einem Produktiosserver getestet habe, nie aufgefallen. Und
umgestellt auf die finale CD18 habe ich erst kürzlich, und niemand hat sich
seitdem beschwert. Aber anscheinend gab es da tatsächlich Handlungsbedarf...
> HELIOS sei mit höchster Priorität dabei diesen Fehler zu beheben.
In der Tat:
<http://www.helios.de/support/updatebrowser.phtml>
Gruss,
Thomas
Yann Borg
Borg) wrote:
> Aber zum Anfang der Geschichte:
Nun ist es soweit, die Entscheidungen sind gefallen.
Beim Server bleibt es bei einer SUN: Hauptargument dafür ist die Legendäre
Ausfallsicherheit, Service im Bedarfsfall, und die Tatsache dass ich keine
Kompetenz aufbringen kann im Falle eines Ausfalles einer X-Beliebiger
Linux-Kiste. Outsourcing ist daher willkommen. Ach ja, die Konfiguration:
eine Fire 280R mit 2 Prozessoren à 900 MHz, 2 GByte RAM, 2 FC-Platten und
eine zusätzliche Gigabit-Enet Karte (überlege gerade ob evtl. noch eine rein
sollte um Switch-Cascadings zu vermeiden). Da SUN in dieser Konfiguration
die Maschinen relativ "Preisgünstig" zusammenstellt, macht es preislich
keinen Sinn die kleinste Ausführung mit eine 2. Prozessor und Kingston-RAM
aufzubohren.
Als Datenspeichersystem fiel die Entscheidung auf einen SCSI to IDE RAID-5
mit Infortrend Controller, und zwar mit 8 Platten à 120 GByte: IDE weil
definitiv preiswerter. Warum so "kleine" Platten angesichts des unschönen
Preis/Speicherkapazität Verhältnis? Weil wir IMO sowieso nur die hälfte
davon brauchen werde (ja ja, ich lese mich in einem Jahr wieder und
revidiere meine Aussage ;-). Es sollen auch nicht die ganzen 700 GByte
freigegeben werden, mein HELIOS-Händler meinte man könne jetzt mit Solaris 9
eigener Tool eine Partition nachträglich vergrößern.
Bezüglich Backup-Software ist die Entscheidung in Richtung PresStore von
Archiware gefallen: einerseits wegen der Unterstützung von ES-Files,
andererseits wegen der leichten Bedienbarkeit per Web-Browser, aber auch
wegen das nette Feature bestimmte Verzeichnisse nach Gusto online zu
Verfügung zu stellen. Ein wichtiger Aspekt ist auch die Tatsache dass die
Software eine Archivierungsfunktion besitzt. Fertig die ewige Brennerei auf
CD-R/DVD-R. Es soll auch bald ein Tool geben was PresStore und Cumulus
miteinander kommunizieren lässt: Cumulus könnte somit Daten On- / Offline
stellen.
Zum Thema Backup/Archiv-Medium fiel die Wahl letzen Endes doch auf Bänder
und nicht auf Festplatten wie ich ursprünglich angedacht hatte: Eine
Qualstar Tape-Library mit 22 Bänder und 2 AIT-3 Laufwerke bieten eine
Kapazität von 2,2 TByte unkomprimiert. Schönes Ding aber fast so teuer wie
die SUN 280R... Alternativ mehrere RAIDs einzusetzen? AFAIK unterstützt
PresStore nur Band-Laufwerke. FC-Kabeln hätten gefehlt. Die
Live-Backup-Lösung auf einen zweiten RAID ist nicht gestorben, wird evtl. zu
einem späteren Zeitpunkt verschoben. Die vorhandene Ultra10 wird so
konfiguriert, dass sie bei Ausfalls der 280R mit wenig Aufwand die Arbeit
übernimmt.
Irgendwo musste ein Strich unter alle Positionen der Rechnung. Falls es noch
mehr hätte kosten dürfen hätte ich die Raumtrennung zwischen
Backup-/ArchivDaten und Online-Daten gerne realisiert. Es hätte aber ein
Klimagerät montiert werden müssen und RAID und Library hätten über FC-Kabel
angesteuert werden müssen (Die FC-Erweiterung für die Library kostet fast
soviel wie das ganze RAID...).
Immerhin erfolgt die Trennung jetzt Dank Verlagerung der Bänder, und die
kleine SUN kann als Backup-Maschine eingesetzt werden.
Soweit zu Thema: die nächsten LAN-Tests werden asap folgen ;-)
An dieser Stelle nochmal lieben Dank für eure Ratschläge und irgendwie auch
seelische Unterstützung in stressiger Zeit ;-)
Gruss,
Yann
Thomas Kaiser
<news:BA5D8865.3174D%y.b...@arts-others.de>:
> eine Fire 280R mit 2 Prozessoren ŕ 900 MHz,
Das hört sich erstmal gut an, auch wenn's um die Erweiterbarkeit eher
schlecht bestellt ist...
> 2 GByte RAM,
IMHO Overkill, da Ihr doch nur File-/Print-/OPI-Server und AFAIR
PDF-Handshake drauf laufen habt? Naja, die Kiste wird dann wenigstens nie
swappen müssen :-)
> Warum so "kleine" Platten angesichts des unschönen Preis/Speicherkapazität
> Verhältnis? Weil wir IMO sowieso nur die hälfte davon brauchen werde (ja
> ja, ich lese mich in einem Jahr wieder und revidiere meine Aussage ;-).
Wahrscheinlich eher nicht. Ihr habt ja jetzt auch eine Software für
Archivierung, die bequem zu steuern ist. Da wird dann eher noch ein
Kühlschrank von Qualstar anrumpeln, vermute ich mal ;-)
[PresStore]
> wegen der Unterstützung von ES-Files,
BTW: Die werden zu der diese Woche veröffentlichten 1.1 ein Maintainance
Update nachschieben (vermutlich), das beim Restore auch automatisch "OPI
Events" triggern kann, damit Asset Management Lösungen wie MediaBeacon oder
Cumulus, die sich mit dem Fileserver synchronisieren sollen, auch was von
Datei- und Ordnerbewegungen mitbekommen werden.
Die passenden Helios-Updates sind seit heute offiziell verfügbar:
<http://www.helios.de/support/updatebrowser.phtml>
> Soweit zu Thema: die nächsten LAN-Tests werden asap folgen ;-)
Au weia. Und was machst Du, wenn die Sun lahmer ist als der G4, aus dem Du
letztens die 120 MByte/sek rausgequetscht hast?
Gesetzt den Fall, Du willst sie wegschmeissen, laß es mich vorher wissen.
Ich würde sie sogar selbst abholen ;-)
Gruss,
Thomas
Yann Borg
>> 2 GByte RAM,
>
> IMHO Overkill, da Ihr doch nur File-/Print-/OPI-Server und AFAIR
> PDF-Handshake drauf laufen habt?
Na ja, "nur" ist relativ: ist doch schon ziemlich viel, oder? Die Fire280R
gibt es im Bundle mit 2 Prozessoren, 2 FC-Platten und 2 GByte RAM günstiger.
Hätte ich nur 1 GByte RAM gewollt, hätte ich sie für mehr Geld
zusammenstellen lassen müssen :-/
>> Soweit zu Thema: die nächsten LAN-Tests werden asap folgen ;-)
>
> Au weia. Und was machst Du, wenn die Sun lahmer ist als der G4, aus dem Du
> letztens die 120 MByte/sek rausgequetscht hast?
Abstellen. Und das für meine Ohren viel zu laute G4 1.25 MP mit einer
zweiten Gigabit-Enet-Karte bestücken und als Server einsetzen.
> Gesetzt den Fall, Du willst sie wegschmeissen, laß es mich vorher wissen.
> Ich würde sie sogar selbst abholen ;-)
Kommt schon von alleine ... here comes the Sun, hmm-hmm ...
Gruss,
Yann ;-)