Hallo zusammen,

wenn man zur Zeit einen neuen Macserver für 10-15 Leute braucht was soll man den da als Rechner nehmen (Eigentlich nur Filesharing).
Ein iMac kann es ja wohl nicht sein, der neue MacPro als extremer Rechenknecht auch nicht und ein Mini... muß erstmal extern mit Raids erweitert werden.

Also auf die Suche gehen nach einem gebrauchten MacPro? Einen Hackinotosh basteln??? Gar einen PC mit welchem Betriebssystem fürs Filesharing? Oder ein NAS und wenn ja welches kann gut mit Spotlight umgehen?

Wichtig ist das er gut läuft und Spotlighttauglich sein muß. Optimal wäre natürlich wenn das System "Dau-tauglich" ist und man jemand ggf vor Ort im Falle eines Falles per Telephon instruieren kann

Bei Mac OS X Server 10.8 muss man den Benutzer „Spotlight“ hinzufügen, und schon funktioniert Spotlight auf Servervolumes.

Gefunden hier: www.macuser.de

Gar nicht. Weil's (den Usern, dem Admin und dem Systemhaus meist) völlig wurscht ist. Du hast vergessen, dass es hier um den Dateiserver für ein kleines Team geht und nicht um irgendwelche RZ-Szenarien. Die Liste an Nachteilen bzgl. Mini kann man übrigens noch fortsetzen (was dann in Summe der Grund ist, dass dort, wo wir die Finger auf den Servern haben, dann doch abseits Spezialitäten eher richtige Server unter Linux oder Solaris zum Einsatz kommen).

Dem Mini fehlt auch noch ECC-RAM und das größte Problem ist OS X (Server) und sein Dateisystem. Die unleidige Verknüpfung aus Patches und Funktionalitätsupdates, die einem Apple einschenkt (und der man nicht entkommen kann) nebst dem im Zweifel nicht funktionierenden Journaling eines HFS+ machen den Einsatz als Fileserver gerade bei großen Datenmengen riskant.

Rein technisch gesehen ist der Betrieb von Helios, Netatalk oder auch ExtremeZ-IP auf echter Serverhardware unter Linux, FreeBSD, Solaris oder im letzteren Fall halt eben Windows jeder OS X basierten Lösung überlegen. Aber da gibt's dann sowohl reale Schwierigkeiten (wer beherrscht das OS des Servers und kennt sich mit der Hardware aus, was braucht's alles an Ersatzhardware/Konzept vor Ort?) als auch psychologische ("Windows?! Linux?! Igitt!"), die natürlich auch eine Rolle spielen.

Wenn jemand mit minimaler technischer Affinität halt drauf schwört, dass OS X das einzig wahre ist, dann wird der halt nur eine Mac-Lösung akzeptieren, völlig egal, ob die nun die minderwertigste ist oder nicht. Und der Witz in diesem Kontext ist ja: Es funktioniert ausreichend. Die Anwender haben das Gefühl, alles im Griff zu haben und wenn Mac-Admins vor Ort bzw. beim betreuenden Systemhaus sind, die wirklich was können (was ja fast noch seltener ist, als gute Windows-Admins zu finden), dann klappt sowas ja auch leidlich Dank Konzeptionierung und Absicherung auf höheren Schichten (bspw. Sync der Daten auf Zweit-System, drauf achten, dass die OS-Installation unisex ist und somit im Falle des Verstebens des Minis an irgendeinem Arbeitsplatz-Mac, der zum Übergangs-Server erklärt wird, weiterbetrieben werden kann, etc. pp.)

Das alles ist möglich, hat selbstredend nichts mit "Data Center IT" zu tun und ob's in der konkreten Situation sinnvoll ist, steht auf einem anderen Blatt (da spielt nämlich immer auch die Akzeptanz seitens Endkunde mit rein und wenn der partout kein Windows oder dann nach schlechten Erfahrungen mit "NAS" nichts mehr haben will, auf dem diese 3 Buchstaben vorkommen, dann ist das halt so und danach muß man sich richten)
Ich halte mdtest und ior für deutlich sinnvoller, um die Performance zu ermitteln. Beides sind per MPI parallelisierte Filesystembenchmarks[/quote]

Es geht immer noch um "Dateiserver für kleines Team". Das Team öffnet und speichert Dateien, klickt im Finder in Ordnern herum, dupliziert mal irgendwelchen Kram und will per Spotlight suchen. Das alles ist Lichtjahre von MPI und parallelisiertem sonstnochwas entfernt. Helios' LanTest ist hingegen genau als kombinierter Netz- und Dateisystembenchmark entwickelt worden, der nach separatem Durchtesten der unteren Layer (iozone, iperf, etc.) dazu dient, das Endresultat, also "das, was beim User ankommt" abzunicken. Und dafür ist es wirklich sehr geeignet...

Das ist alles extrem unscharfes und dies&das vermischendes Geblubber

Spotlight kam neu mit 10.4 und war damals nicht netzwerkfähig. Punkt. Man konnte da zwar client-seitig eine Indizierung quer durchs Netz von irgendwelchen Servervolumes anstoßen. Aber das Feature war praktisch nicht zu gebrauchen, da a) keine automatische Neuindizierung auf dem Server vorgenommen wird und b) jeder Client individuell indizieren müsste. Jede Änderung, die auf dem Server geschehen wäre, wäre nicht automatisch zu den Clients propagiert worden, stattdessen hätten die alle manuell und parallel eine komplette Neuindizierung des Server-Volumes anstoßen müssen. Noch schwachsinniger geht's quasi gar nicht. Falls Dich tatsächlich auch mal Details interessieren sollten, wie das damals in 10.4 war, bitte sehr:

Mit 10.5 kam dann "Spotlight im Netzwerk". Apple hatte damals proprietäre und noch nicht mal offiziell dokumentierte Erweiterungen in AFP eingebracht und nutze diese zwischen 10.5 Client und Server, wenn der Server diese AFP-Spotlight-Erweiterungen auch propagierte (was erstmal nur Apples eigener AppleFileServer-Dienst tat, aus dem simplen Grund, weil Apple die Dokumentation der neuen AFP-Calls weggeschlossen hatte). Wenn der Server die Spotlight-Erweiterungen nicht beherrscht, dann kriegen auf dem Server-Volume suchende Clients das nur insofern mit, dass sie eben auf einmal nur wieder maximal nach Dateinamen finden (weil im Hintergrund heimlich still und leise ein Fallback von Spotlight-per-Netzwerk auf Apples altbekannte FPCatSearch-Suche -- Suche vom Client aus in der Desktop-Datenbank des Server-Volumes -- stattfand)

Das Prozedere in dieser Spielart läuft völlig anders:

a) der Server indiziert selbst und pflegt einen eigenen Metadaten und Volltext-Index je Volume

b) Clients, die auf Server-Volumes suchen, nutzen wenn sowohl Server als auch Client die Spotlight-Erweiterungen beherrschen, diese, d.h. Suchbegriff wird zum Server übermittelt, dort sucht der AFP-Server in seinen Indices und schickt dann die Ergebnislisten zum Client zurück

c) der Client bzw. in dem Fall Finder fängt dann sofort an, alle diese per Spotlight-API übermittelten Treffer auf dem Server-Volume zu befummeln -- macht einen stat drauf, um zu sehen, ob's die Datei überhaupt gibt (was den interessanten Nebeneffekt hat, dass eine blitzschnelle Rücklieferung von Spotlight-Suchergebnissen völlig kontraproduktiv ist, da der Finder des Clients dann bei einer trivialen Suche, die bspw. 100.000 Treffer generiert, sofort anfangen will, diese 100.000 Dateien übers Netzwerk zu befummeln. Weshalb serverseitige Spotlight-Suche inzwischen bei allen Anbietern bedeutet, dass die Trefferliste nicht einfach rausgeschossen wird, sondern ausgebremst und häppchenweise an den Client geliefert wird. "weniger ist mehr" und so)

Diese Spotlight-AFP-Erweiterungen werden von Apple im eigenen AppleFileServer seit Version 10.5 umgesetzt, Helios kann's IIRC seit Version UB2, Netatalk seit Version 3.1 und ExtremeZ-IP seit Version 8.

Sowohl Netatalk als auch ExtremeZ-IP kommen in billigen NAS-Eimern zum Einsatz (LaCie hatte mal NAS, die auf Windows CE oder sowas basierten und mit einer abgespeckten Version von ExtremeZ-IP 5 liefen). Allerdings verwendet meines Wissens nach keiner der NAS-Hersteller die richtige Version. Und das viel größere Problem ist: Man muß den Kram nämlich auch zum Laufen bringen.

Apple mit dem AppleFileServer hat es da bamperleinfach: Die nutzen auf dem Server einfach die eh schon in OS X eingebaute Spotlight-Indizierungsfunktionalität und für Benachrichtigungen, welche Datei neu indiziert gehört, ganz einfach den FSEvents-Mechanismus. D.h. unter OS X (Server) ist die Chance, dass wenn man mal das richtige Hakerl im GUI findet und Spotlight-Suche im Netz anknipst, anschl. auch alles funktioniert.

Das ist bei den drei anderen Lösungen nicht so simpel bzw. nur, wenn man wirklich weiß, was man tut, den Kram richtig einrichtet und anschl. drauf aufpaßt, dass alle Modifikationen innerhalb von Server-Volumes richtig vorgenommen werden (also nur per Netzwerk-Client und nicht direkt auf dem Server). Weil sonst evtl. am Indizierungsmechanismus des Servers vorbeigearbeitet wird und man dann zwar neue Dateien in den Server-Volumes hat, diese aber nicht im Spotlight-Index auftauchen und man sie demzufolge auch nicht findet. Das ist aus Sicht der "User Experience" eine glatte Katastrophe.

Da oben steht jetzt andauernd AFP aber Apple setzt doch jetzt auf SMB2? Richtig, sie haben einfach ihre eigenen proprietären Spotlight-Calls in SMB-Requests gewrapped, können unter OS X nach wie vor die Bordmittel FSEvents/MDImporter nutzen und sind demnach in der Lage, mit dem hauseigenen SMB2-Server ab 10.9 auch Spotlight per SMB bereitzustellen.

Das kann Stand jetzt keine andere Lösung weit und breit. Da aber die beiden deutschen Firmen NetAFP und SerNet vor paar Wochen fusioniert haben, wird diese Funktionalität wohl im Laufe des Jahres 2014 in Samba verfügbar werden. Die NAS-Hersteller, die schon bislang die Netatalk-Entwicklung mitgetragen haben, kapieren vermutlich früher, dass sie auf den "Apple-SMB-Zug" aufspringen sollten und werden dann wohl die ersten sein, die in ihren NAS-Geräten dann auch plattformübergreifende Spotlight-Suche anbieten können. Die "Schmarotzer" wie Synology, die sich bislang einfach nur bei OpenSource bedient aber nix dazu beigetragen haben, brauchen wohl auch wie in der Vergangenheit länger. Heißt: NAS-Eimer mit Spotlight 2015 neu gucken. Ansonsten jetzt je nach Gusto OS X basierte Lösung einsetzen oder "echter Server" mit einer der drei Spotlight-fähigen AFP-Server-Varianten.

Die Knackpunkte wie folgt:

- Netatalk 3.1 nutzt für die Indizierung Gnome Tracker in einer ganz spezifischen Version. Das muß mitsamt aller Dependencies erstmal soweit laufen, dass sich Netatalk und die parallel laufende Hintergrund-Indizierung verheiraten lassen. Wie's für Debian/Ubuntu geht, hab ich ins Netatalk-Wiki gekippt (Link schon hier im Thread gepostet)

- Die Basis-Mechanismen, die im Hintergrund Gnome Tracker befeuern, haben ihrerseits Limitationen:

Bis die typischen NAS-Hersteller das alles soweit adaptiert haben und fehlerfrei umsetzen, wird noch Zeit ins Land gehen (und ggf. die Basis für das Ganze seitens SerNet nochmal umgebaut bzw. optimiert werden). Wenn man sich ansieht, wie simpel vor paar Jahren im Vergleich dazu das Nachrüsten von stabilem TimeMachine-Support in die NAS-Eimer war und wie lange da ein paar gebraucht haben, um das umzusetzen (sie mussten sich ja nur bei Netatalk bedienen -- alle diese NAS-Hersteller nutzen ja heute die gleiche Engine) sollte man sich keine Hoffnungen machen, dass Spotlight-NAS bald Realität wird.

Genau darum ging es. Wenn man die Limits von Mac mini Server oder nMP erreicht, verbleiben nur zwei Möglichkeiten: Man arrangiert sich oder muß eine andere Plattform nutzen.

Hi Thomas. Erstmal noch einen Gruß, finde es sehr schick, daß Du hier (wieder) postet, ich zolle Dir großen Respekt für Dein Know-How und Deinen Stil. Danke!
Neben all den technischen Wunderdingen gibt es ganz oft einen sehr trivialen Grund, warum sich Kunden für NAS oder mini+Platte entscheiden anstatt für eine HA-Lösung: Geld. Klar hat die kleine Lösung hier und da technische Defizite, und ist eine einzige Kette von Single-Point-of-Failures. Wenn ein Kunde dann fragt, wie eine "ausfallsichere" Lösung aussieht, bitte sehr:

- Rack
- dicke USV
- zwei Switche
- Stapel Mac minis (falls es unbedingt Apple-Hardware sein soll)
- HP ProLiant oder ähnliche Bleche
- VMware EXSi-Wolke, mit der großen Lizenz für Live-Transfer der laufenden Container
- Container für allerlei Dienste, egal ob OS X mit oder oder Server.app, Linux, Windows
- Storage via iSCSI oder noch besser via SAN
- Backup automatisiert offsite, im Haus synchronisiert auf zweites Storage-System, ...

Könnte man alles bauen. Führt zu folgenden Dialogen, Kunde fängt an: "Also, so ein Mac mini könnte aber ausfallen, oder"? - "Klar." - "Was mache ich dann?" - "Dann hängen Sie das TB-RAID an einen anderen Rechner, und können ein paar Minuten später wieder auf die Daten zugreifen." - "Hm, das ist aber nicht so schön. Können Sie das nicht ausfallsicher machen?" - "Sicherlich, wir können Ihnen sehr gerne eine Lösung hinstellen, die das richtig macht." - "Was kostet das?" - "Naja, je nach Storage-Lösung zwischen 20.000 und 50.000 Euro, bis alles läuft." - ".......(ächz)........" - "Ok, also lieber doch den mini+Platte für 3.000?" - ".....(kommt wieder zu Bewusstsein)......ja, reicht....."

Ja, es gibt Firmen, die die große Lösung brauchen. Aber es gibt eben erstaunlich viele Firmen, wo die kleine Lösung ausreicht bzw. ausreichen muß.

Äh, ja klar. Nur, da es um "einen neuen Macserver für 10-15 Leute" und "Eigentlich nur Filesharing" ging, dürften diese Limits in weiter Ferne sein.

Ich kenne fette Installationen, in denen aufgrund "MaxiMin-Prinzip" (maximaler Aufwand, minimaler Effekt), schweinsteure Solaris-Server in dedizierten Rechenzentren stehen mit wahnsinnig schnellem Storage dran und das Ganze dadurch zum Treppenwitz degradiert wird, dass zwischen dem Highend-Server-Setup und den mehreren hundert Usern nur ein Etherchannel mit 2 Gbit/sek gespannt ist, der dann noch durch paar weitere Fehlplanungen im LAN der User zu durchschnittlichen Transferraten im Bereich 25 bis maximal 40 MByte/sek geführt hat.

Und niemand ist es aufgefallen, bis der blöde Kaiser dann das Messen angefangen hat. Was ist die Erkenntnis daraus:

- User sind schon zufrieden, wenn es überhaupt geht (sehr zum Glück vieler kleiner Mac-Klitschen)

- ein Mini mit TB-RAIDs und Bonding kann absurderweise mehr beim User ankommen lassen als ein Highend-Setup

Bzw. ganz simpel und immer das Maß aller Dinge: "Grundsatz der Verhältnismäßigkeit".

Und übrigens: Das alles ist null Plädoyer pro Mini, nur der Versuch einer differenzierten Betrachtung.

Welche HA-Fileserver-Lösung für Macs, die wirklich funktioniert (das bedeutet Stand heute noch AFP), kennst Du denn?

"Grundsatz der Verhältnismäßigkeit" eben.

Und ich finde ja, dass man den psychologischen Faktor nie außer acht lassen sollte. Es kann rein technisch gesehen besser als auch günstiger sein, anstatt auf Mac-Hardware nebst OS X basierten Diensten auf "echte Server" zu setzen. Das muß dann auch nicht gleich die sündteure HA-Lösung sein, man kann da durchaus mit 3 Stück identischem Blech, vSphere, einem Rudel virtualisierter Server und einem Konzept, das auf permanenter Daten-Synchronisierung und "Platten umstecken wenn tot" basiert, eine "gut genug"-Verfügbarkeit einrichten (die jedem echten HAler natürlich nur Lachkrämpfe beschert )

Aber: Wer beherrscht das Setup, wenn's soweit ist? Kann man das dann selbst (oder will man's selbst überhaupt können und sich die Verantwortung aufbürden, etwas kaputtzumachen)? Oder braucht man ein Systemhaus? Und gibt's beim Systemhaus für diese IT-Schiene einen Betreuer, der User nicht nur für verabscheuungswürdige ahnungslose Volltrottel hält sondern als Kunden betrachtet (ist mir bei kleinen "heterogenen" Systemhäusern jetzt schon mehrfach aufgefallen, dass die echten Checker, die auch mehr als Mac-Voodoo können, meist schon ziemliche Nerds sind -- was jetzt noch nicht per se schlimm ist -- aber Sprache/Bedürfnisse/Befindlichkeiten ihrer Kunden nicht nur nicht verstehen wollen sondern gar nicht können, weil sie schon halbe IT-Autisten sind -- an so jemanden dann zu gelangen, wenn man ihn wirklich braucht, weil irgendwas abgeraucht ist, kann dann recht simpel zu "ab jetzt nur noch Mac" führen)

Und abgesehen vom Psycho-Aspekt. Ein TB-RAID irgendwo ab- und woanders wieder anzustöpseln, kriegt eben jeder feinmotorisch halbwegs begabte User auch ohne Admin oder Systemhaus hin (und wenn Letztere richtig vorgebaut haben, dann läuft anschl. die Chose auch wieder). Hat eben alles seine Vor- und Nachteile

Die Methode hat 2 Nachteile:
1. Die Daten liegen komplett auch in den USA und man braucht dort entsprechend viel Platz.
2. Alle Daten liegen auf allen Geräten.

Statt DropBox liesse sich auch Bittorrent Sync lokal im Netzwerk nutzen, dann entfällt Nachteil 1.
Nachteil 2 bleibt aber weiterhin bestehen.

LOL,
Respekt

dafür hast a Bier bei mir gut

Sehr schön auf den Punkt gebracht

Das hängt sehr stark vom Zugriffsmuster der Nutzer ab. Viele kleine Dateien sind auf dem typischen TB RAID lahm, weil es kein SSD Caching gibt. Selbst die alte Methode viele Platten wird bei den typischen TB RAIDs nicht benutzt. 8 relativ träge 3.5" HDDs (das steckt doch meistens in den TB RAIDs) ist für so ein Szenario wahrlich nicht ideal. Früher hätte man viele 2.5" 15k Platten verbaut, aber das geht am Mac mini nur mit vielen JBODs.
Aber nur in Ausnahmefällen sonst ist es immer deutlich langsamer. Standardlösungen sind hier mit dem gleichen Geldaufwand deutlich schneller. Der einzige Vorteil ist das bekannte OS. Und darüber verkauft Apple noch die OSX Server Lösung, sonst wäre das kein Thema mehr.

Da wir ohnehin nur Daten haben die wenige Tage später veröffentlicht werden (Werbeagentur), spielt das keine Rolle. Der Platz kostet auch nicht viel, so um 50 Euro pro Jahr. Und wer schützenswerte Daten hat, der verwendet Boxcyptor oder ein verschlüsseltes Disk Image.
Das ist kein Nachteil, das ist sogar ein Vorteil! Das ist genau so eine Redundanz wie RAID-Systeme sie aus Sicherheitsgründen extra aufbauen, halt nur anders.
„Nachteil 2“ ist aber ein Vorteil (Schutz vor Datenverlust). BTSync hat aber den Nachteil, dass sehr wichtige Bestandteile der Daten nicht mit synchronisiert werden. Ansonsten wäre BTSync das bessere Tool, ja.

Wenn ich sehe, was alles nicht geht, wenn man einen File-Server verwendet, dann bin ich mit meiner Lösung besser dran. Dort funktioniert alles, ich habe eine Redundanz der Daten (Schutz vor Verlust) und auch gleich ein Offsite-Backup (Dropbox).

Einen Server habe ich zwar auch, aber der stellt nur Backup-Volumes bereit, einen Datenbankserver für die Buchhaltung und Rechnungswesen, Adressbuch und Kalender für eine andere Firma und dient als Render-Slave. Ach ja, und ein Datenarchive. Das ist das einzige, was ich zentral auf einem File-Server liegen habe.

Ich habe also beide Lösungen im Einsatz, und daher den direkten Vergleich. Und die Lösung mit synchronisierten Daten ist m.E. die bessere Lösung, weil dort alle OS X-Dienste funktionieren. Klar, dass die Systemhändler das nicht befürworten, denn dann verkaufen sie ja nichts mehr.

Aber jeder soll es so machen wie er will, ich habe nichts dagegen.

Nur, falls sich jemand fragt, was eine "HA-Lösung" ist:

Ob SSD-Caching überhaupt was bringt, hängt aber auch "sehr stark vom Zugriffsmuster der Nutzer ab"

Es ist alles sogar noch viel schlimmer, denn in den "typischen" (also real existierenden) TB-RAIDs stecken meist noch nicht mal 8 sondern deren 6 oder 4 Platten drin. D.h. das ist sogar noch lahmer. Und gleichzeitig völlig egal.

Du betrachtest das rein aus der technischen Perspektive und weist auch völlig zurecht darauf hin, dass es für identisches Budget entweder deutlich schnellere Lösungen gibt oder wahlweise auf anderer Plattform günstiger geht (wenn man es auf Anschaffungskosten reduziert und psychologische Gesichtspunkte außer acht läßt).

Aber wenn man's im Praxiskontext sieht (ein Rudel Grafiker und Redakteure sollen gemeinsam mit Daten arbeiten), dann ist Performance in so einem Setup heutzutage im Normallfall kein Thema mehr weil völlig ausreichend. Vielleicht der Hauptgrund, an der Stelle auf "zentrales Datensilo" also NAS als Konzept zu setzen ist die Lösung des einen Problems, das zwangsläufig entsteht, wenn ein Rudel Menschen unkoordiniert auf den selben Daten herumschraddelt: Konfliktvermeidung. Was geschieht in der Situation, in der User A und User B parallel ein und dieselbe Datei bearbeiten bzw. speichern wollen. Die Antwort, die "NAS als Konzept" (also völlig egal in der Form NAS-Eimer, toller Linux-Server oder Mac Mini mit OS X Server) dafür vorsieht, lautet File- und Byte-Range-Locking. Ein herrlich anachronistisches Konzept, das aber meist funktioniert (solange irgendwelche Anwendungsentwickler sich auch an die Dateisystem-APIs bzw. -semantiken halten -- Adobe ist da ja regelmäßig "leuchtendes Beispiel", wie man's nicht macht)

Es gibt freilich auch andere Ansätze, mit der Problematik umzugehen (Versionskontrollsysteme oder Mediendatenbanken, in die Dateien ein- und ausgecheckt werden, um diesen potentiellen Konflikt gar nicht erst entstehen zu lassen). Nebenbei auch spannend, wie Gerhard in seinem "einfach mal alles überallhin syncen"-Setup mit dieser Problematik umgeht...

Aber meist ist sowas Overkill bzw. setzen "geübte Abläufe" oder gar gleich sowas wie Workflow-Tools (in egal welcher Spielart, bspw. als Redaktionssystem) halt nunmal zwingend darauf, dass jeder Arbeitsplatz eine identische Sicht auf die Daten hat und parallel zumindest lesend darauf zugreifen kann. Da ist das Konzept NAS meist eine völlig valide bzw. ausreichende Lösung. Und die Performance des Ganzen in der heutigen Zeit ziemlich nachrangig.

Ich persönlich (als Server-Zampano, der letztlich von sowas lebt) halte das NAS-Konzept ja für seit halben Ewigkeiten schon für überholt. Der Ansatz eines "universellen Versionskontrollsystems", wie er sich in den aktuellen Apple-APIs wiederfindet, wäre eigentlich gar nicht schlecht. Blöd nur, dass das bei Apple momentan im Team nur funktioniert, wenn man seine Daten bei der NSA speichert. Mal schauen, ob in der Post-Snowden-Ära sich vielleicht doch noch die Erkenntnis durchsetzt, dass Datensparsamkeit und -hoheit wichtige Güter sind, und der Kram, der heute nur zus. mit iCloud funktioniert, sich auch mal auf eigenen Storage umbiegen lassen wird. Aber da hab ich so meine Zweifel.

Ah, danke. Danach ist mein System laut Erfahrung ein Klasse 5 HA. Nur wenn ich einen seltenen Stromausfall habe, ist das System weg.

Schön, kurz Wikipedia quergelesen und alles ist gut

Bei HA geht es eigentlich um prospektive Einschätzungen/Zusicherungen und erst am Ende um die retrospektive Überprüfung der Einstufung. Dass die Verfügbarkeit Deines "Systems" rückblickend betrachtet erfreulich hoch gewesen sein soll, ist das eine. Das andere ist, was erwartbar gewesen ist.

Wenn Dein System auf Strom basieren sollte, was es ja tut, dann kannst Du mal bei Deinem Stromanbieter anfragen, was die so zusichern bzgl. Verfügbarkeit (immer schön die Klauseln bzgl. höherer Gewalt richtig interpretieren). Wenn Du keine monströse USV (bzw. das dicke Dieselaggregat im Keller hast), kannst Du HA automatisch eh schon vergessen (nebenbei: schon alleine die -- in diesem Kontext völlig irrelevante -- durchschnittliche Nichtverfügbarkeit je Endverbraucher laut SAIDI versaut Dir Deine angeblich HA-Klassifizierung

Sollte Dein System auf "Internet muß funktionieren" basieren, dann kannst Du Dir auch bei dem Anbieter mal Zusicherungen bzgl. Verfügbarkeit holen bzw diese prüfen. Die werden üblicherweise bei 99%-99,5% liegen (und damit sind seeeehr lange Nichtverfügbarkeiten vertraglich bzw. per SLA abgedeckt). Auch das würde Dir die HA-Einstufung dann verhageln bzw. mindestens einen zweiten redundanten Internetzugang nötig machen (dabei schön das Kleingedruckte in den Anbieter-SLAs lesen bzw. technische Recherchen anstellen, dass das nicht nur ein anderer Anbieter ist sondern andere Leitung, Backbone, Core-Router, etc. mit involviert).

Mit anderen Worten: Dein System hat wie auch nicht anders zu erwarten gar nichts mit HA bzw. den zugrundeliegenden "allgemein gültigen Annahmen" zu tun, die nunmal gelten, wenn man das Wörtchen "high availability" professionell gebraucht (und abseits professionell macht's überhaupt keinen Sinn)

Und genau deshalb, weil das viel mit Statistik und dies&das zu tun hat, wenn man es tatsächlich ernst nehmen will, lohnt sich die Erstrebung wirklicher HA in SOHO-Umgebungen eh nicht (außer man betrachtet einfach willkürlich nur einen Teilaspekt des Ganzen und "vergißt" großzügig alle sonstigen Randbedingungen, die auch noch passen müssten, damit wirklich Hochverfügbarkeit eintritt).

Was mich aber an Deinem "System" mehr interessieren würde: Wie viel User bedient das denn? Und falls mehr als nur einer: Wie geht es damit um, dass mehr als ein User ggf. an den selben Daten herumschraubt und sich Änderungen nicht gegenseitig überschreiben/auslöschen?

Ja, das sind Erfahrungswerte, aber das schrieb ich ja auch.

Bei einem meiner Kunden, einem Handwerksbetrieb, sind es 5 Arbeitsplätze im Haus und 1 oder 2 außer Haus. Aber das schrieb ich weiter oben schon. Das funktioniert grundsätzlich auch mit mehr Arbeitsplätzen.

Und das zählt nicht bei HA, weil es da um Erwartbares (in die Zukunft guckend) und weniger "zufälligerweise Erreichtes" (rückblickend) geht. Aber das schrieb ich ja auch

Lesen kann ich übrigens

Die Frage war: wie funktioniert "das"? Da syncen alle Arbeitsplätze mit dem selben Dropbox-Account Daten hin und her. Und User A (Homeoffice) wurschtelt grad in einem Dokument, in dem User B (in der Schreinerei) auch grad herumwurschtelt. Und beide drücken CMD-S.

a) wessen Version gewinnt?
b) was geschieht mit der anderen Version?
c) wie kriegen die User überhaupt mit, dass es einen Versionskonflikt gab?

Versuch bitte c) im Hinterkopf zu haben, bevor Du sagst "Das ist noch nie vorgekommen".

Mich interessiert das übrigens wirklich, denn wenn das Chaos-Gesynce im Team tatsächlich das uralte Problem parallelen Zugriffs auf identische Daten sinnvoll lösen sollte, kann man sich den teuren Spaß, Arbeitsgruppen Server vor die Nase zu stellen, auch sparen.

Übrigens: So, wie Dropbox das als FAQ abhandelt, halte ich das Ganze nicht für sinnvoll: (es gibt Dateiformate wie z.B. "reiner Text" bzw. Tools, mit denen sich in so einem Fall auseinanderdriftende Versionen relativ simpel wieder zusammenführen lassen, es gibt aber auch Formate, wo das nicht der Fall ist und wo so eine Situation unnötige Mehrarbeit bedeutet, die durch zentrales Locking schon vom Start weg vermieden hätte können)

Der Kaiser ist auf mtn angekommen. Da können wir uns ja auf ein paar "freundliche" Postings gefasst machen. dcsm* lassen grüßen.

Ach, kantig sein können hier ja viele (oder glaube das zu können). Aber Ahnung wie Thomas haben leider nur wenige, ziemlich wenige...

Er hat zweifellos Ahnung. Ich kann ihn verstehen. In meinem Job fällt es mir zunehmend schwerer,
IQ-Allergikern wohlwollend und verständnisvoll zu antworten...

Also mich kannst Du nicht meinen, ich setz wie jedes Jahr um die Zeit brav bisserl Winterspeck an

Aber Problemlage erkannt, ich registrier mich einfach neu als Sexyhexy69 und dann bleibt der Beißreflex hoffentlich aus...

Mal wieder zu dem zurück, worum's eigentlich geht, also spannende Implikationen technischer Implementationen bzw. zum eigentlichen Thema. Die Frage, welche funktionierenden HA-Lösungen Du im Kontext AFP-Server kennst, interessiert mich tatsächlich (wie eigentlich jede hier bisher gestellte Frage auch).

Weil ich find HA als Designziel grundsätzlich total spannend. Blöd halt nur, dass so 'ne Lösung absolut zuverlässig zu 100% funktionieren muß, sonst hat man am Ende was, was trotz viel höherer Kosten letztlich bescheidener funktioniert als eine "Failover zu Fuß"-Lösung, die mit kleiner Downtime verbunden auch der sprichwörtliche DAU erfolgreich hinbekommt.

Diese subjektive Einschätzung hat vor paar Wochen erst wieder neue Nahrung bekommen als bei 'nem Ex-Kunden die sündteure HA-Chose eben doch nicht funktioniert hat und paar hundert User mal eben 1,5 Tage Däumchen drehen durften.

Auch aus dem Grund, habe ich an meinem OS X Server nun die RAID System aufgelöst. Hatte jetzt am Ende eh nur Software RAIDs, aber da die Daten dann nochmal auf einer anderen gesichert wurden, habe ich kurz überlegt, ob da ein RAID 1 wirklich für einen "Home-Server" Sinn macht.

Für mich reicht ein Backup. Geht Platte kaputt, spiel ich halt das Backup in x Stunden zurück. Dann werden solange halt keine Adressen synchronisiert.
Und die Mails werden zumindest über kurzen Zeitraum zwischengespeichert.

PS: Ich lese deine Beiträge, Thomas, auch sehr gerne. Also bitte weitermachen.

Vermutlich kann es für AFP aus Prinzip keine echte HA-Lösung geben - denn weder Protokoll noch irgendeine existierende Implementierung eines AFP-Servers (egal ob Apple, helios, ExtremeZ-IP) sehen das vor. Man kann mit obiger Materialliste relativ gut den Server an sich samt Storage auf hohe Ausfallsicherheit trimmen, aber wenn der Container mit dem AFP-Dienst hängt oder der AFP-Server sich aufhängt, dann ist es für eine Weile einfach vorbei, und der Admin muß ran.

Vielleicht einer der vielen Gründe, warum Apple nun Richtung SMB schwenkt, denn SMB bringt mit 2.2 und 3.0 ja einiges in der Richtung mit.

Es gibt in AFP ab 3.x schon diesbzgl. Features: AFP Reconnect. Der kennt zwei Varianten:

- primärer Reconnect (das ist die Situation "Kabel weg" und innerhalb Sekunden wieder angesteckt): Dabei bleiben offene Dateien, Locks und der ganze Kram -- also die komplette AFP-Session -- erhalten, weil das die Situation ist, bei der der Server nur kurz nicht erreichbar war und demzufolge selbst noch die ganzen Sessions der Clients verwaltet (AFAIK wird der Typ mindestens vom AppleFileServer und Netatalk unterstützt)

- Sekundärer Reconnect (das wäre jetzt der Fall: Wir sind auf einen anderen AFP-Server umgeschwenkt). In dem Fall ist Voraussetzung, dass IP-Adresse und Storage von einem zweiten System übernommen wurden. Die Clients bauen dann neue Sessions auf, scheitern dabei aber ggf. wenn ein anderer Client schneller war und nun bspw. schneller beim Aufbau der Session ein Lock auf eine Datei gesetzt hat (sehr unwahrscheinlich aber technisch möglich)

Abseits des AppleFileServers ist aber das große Problem inzwischen, dass ein AFP-Server immer eine Melange aus Fileservices und Datenbanken darstellt (zum einen für die CNIDs, also die IDs, über die per AFP anstatt absoluter Pfade Dateien/Verzeichnisse angesprochen werden können und seit geraumer Zeit auch bzgl. Volltext- und Metadaten-Indizes, vulgo Spotlight)

Und genau das, also dass man bei einem Schwenk auf zweites System diese Datenbanken konsistent halten muß, ist bisserl das Problem. An uns ist Ende letzten Jahres ein IBM-Systemhaus herangetreten, die dick im Mac-Umfeld GPFS-Storage-Lösungen verticken wollten (aber weder die Bedürfnisse der Branche noch "den Markt an sich" in dem Umfeld kannten).

Und ein Nebeneffekt des Ganzen war dann, dass die NetAFP-Jungs in Netatalk 3.1 jetzt auch ein MySQL-Backend eingebaut haben (vormals die nur lokal laufende BerkeleyDB). Mit einem MySQL-Cluster und großzügigem Caching zwengs Geschwindigkeit, sonst fällt grad Random-I/O im Vergleich zur BerkeleyDB gnadenlos zurück, könnte man mit Netatalk ab 3.1 auch sowas in HA-fähig bauen. Also so in klassischen HA-Cluster-Implementierungen...

Das wiederum ist jetzt eine Situation, die man mit Helios, Netatalk und ExtremeZ-IP (mit Letzterem hab ich aber zu wenig Erfahrungen, weil das nur Kunden einsetzen, bei denen wir die Finger nicht auf den Maschinen haben sondern nur kreatives Projektgedöns machen) vermutlich nicht erreicht. Zumindest Helios und Netatalk sind beides rock-solid, wenn richtig eingerichtet. Da macht sich wohl auch schon alleine der grundsätzliche Unterschied zum AppleFileServer (ein Prozeß für alle Clients bei Apple vs. "je Client ein eigener geforkter Prozeß") bemerkbar.

Naja, ich werd's wohl mal durchtesten (mit einer Solaris-VM und vMotion), im Prinzip müsste das reichen, wenn denn all die anderen Randbedingungen auch passen.

Oh, das kommt sogar häufiger vor als man denkt. Dropbox erzeugt dann einfach 2 Dateien. Das kann der Benutzer gar nicht übersehen. In der Praxis stellt das erfahrungsgemäß jedoch kein Problem dar.

Synchronisationskonflikte hatten wir oft bei Datenbanken (Grand Total), und dort war es allerdings ein Problem. Bei normalen Dokumenten jedoch kommt das so gut wie nie vor und stellt auch kein Problem dar, nicht mal wenn es vorkommt. Das ist zumindest die Erfahrung aus der Praxis. Schlimmstenfalls muss man eben zwei Dokumente zusammenführen.

Wie gesagt, es läuft in den Firmen gut. Man hat keinen Server der ausfallen kann, man hat einen Schutz vor Datenverlust wegen Redundanz der Daten, Man hat ein automatisches Offsite-Backup, man hat eine Anbindung externer Arbeitsplätze und man hat alle Funktionen von Mac OS X, also Tags, Farben, Spotlightkommentare und -Suche, Time-Machine-Widerherstellung, Versions, Autosave usw.

Cloud-Computing ist eben die Zukunft! Die Daten müssen nur besser vor NSA & Co. geschützt werden, aber auch das ist kein Problem. Man muss es nur machen.

Sicher, aber es existiert diese Option.
Es ist in der üblichen Kleinfirma, die Macs benutzt, noch viel schlimmer. Die meisten Firmen hängen mehr oder minder von der Funktionsfähigkeit der Computer ab, aber definitiv von den Daten auf den Massenspeichern. Leider wird bei den meisten Kleinfirmen kein wirkliches Konzept erarbeitet, was im Fall des Falles gemacht werden muß. OSX ist ja vielleicht besonders anwenderfreundlich, das entbindet aber die Nutzer nicht davon, sich mit dieser Problematik auseinander zu setzen. Die Realität ist meist eine andere, Naivität und ein gehöriges Maß an Borniertheit ersetzen die dringend notwendige Kenntnis.

Es geht in erster Linie um das Verständnis, daß man sich auf den Katastrophenfall vorbereiten muß, und das ist bei den vielen Mac Anwendern nicht der Fall. Gerade die "Kreativen" sind häufig in Projektarbeiten involviert. Die Frage ist also wieviel Zeit man verstreichen lassen kann, bis es der Firma substantiell schadet, bis der Fileserver wieder läuft. Verpaßt man hierbei einen wichtigen Projektermin, wird es eng. Die Hardwarewahl muß diese Problematik widerspiegeln, nur ist das meist nicht der Fall.

Wenn man ein RAID mit wenigen Platten betreibt, kann es nur ein RAID mit RAID 1, 10 oder 5 sein. Wenn bei so einer Konstellation eine Platte ausfällt ist man sofort im Zustand des Critical Rebuilds. D.h. ca. 1-4 Tage wird die Performance des System drastisch verringert sein, und es besteht die akute Gefahr eines Datenverlustes. Wenn man die falschen Platten verbaut hat oder einfach nur Pech hat, besteht ferner die Gefahr, daß sich während des Critical Rebuilds die nächste Platte verabschiedet Datenverlust. Dann muß erstmal Ersatz für die kaputten Platten vorhanden sein/gekauft werden, der Server neuinstalliert (das RAID neu aufgebaut werden) werden und anschließend das Backup zurückgespielt werden. In so einem Fall nützt es herzlich wenig, wenn man jeden Mac zu einem Server machen kann, weil das RAID selbst das Problem ist. Uns sind mittlerweile mehr RAIDs um die Ohren geflogen als Server verreckt sind. "Lustig" sind auch die Fälle, bei denen der RAID Controller Platten aus dem Verbund wirft, und diese eigentlich ohne jeden Fehler sind.

Auch besonders nett sind Fehler im Arbeitsspeicher. Da der Mac mini kein ECC hat, schreibt er im Falle eines defekten Moduls still und leise kaputte Dateien aufs RAID ohne daß es jemand merken würde. Weil es niemand merkt, werden auch die Backups mit kaputten Dateien zugemüllt. Und wenn man auf die Daten wieder zugreifen muß, ist das Problem da. Frei nach Murphy schlägt der Fehlerteufel dann gleich mit dem Dampfhammer zu, so daß die Daten gar nicht mehr rekonstruiert werden können.
Das kann nur funktionieren, wenn es offene Datenformate gibt, die das Versionkontrollsystem kennt und somit effektiv ein Differenz der Daten erstellen kann. Reine binäre Versionskontrolle gibt es jetzt schon, ohne aufwendige proprietäre Apple APIs.

Ok, Danke für die Bestätigung.

Wir haben uns die Chose natürlich auch angeschaut, speziell weil im Kundenumfeld einige Anfragen in der Richtung gekommen sind. Selbstverständlich testet man sowas (als technischer Berater, d.h. als jemand, der später mal in die Pflicht genommen werden könnte, wenn er Blödsinn verzapft hat) unter Schlechtwetterbedingungen.

D.h. vorher mal überlegen, was alles bei einem Tool, das für "1 User, mehrere Geräte" entwickelt wurde und dort leidlich funktioniert, in einer "viele User, viele Geräte"-Chaos-Situation alles schiefgehen kann. Also schnell ein Skript mit Testparcours zusammengehackt (Dateien erzeugen, umbenennen, bewegen, öffnen mit den diversen Lock-Varianten auf die Datei, Finder-Flags wie uchg setzen und wegnehmen, etc. pp.) und auf zwei lokalen und zwei Arbeitsplätzen ganz woanders remote per VPN ausgeführt.

Überraschend war dann nicht wie schlecht das alles funktioniert, sondern eher wie gar nicht. Wenn der Dropbox Sync Daemon nicht eh gleich völlig hohlgedreht hat und mit 100% CPU-Last alle viere von sich streckte, wurde zumindest ein famoses Datengeschnetzeltes auf allen 4 Clients erzeugt. Herauszufinden, warum die beiden, die im selben LAN standen, am fürchterlichsten Daten geschreddert haben, konnten wir nicht. Wir waren ja immer noch mit der Abwägung beschäftigt, ob wir lieber lachen oder weinen sollen

Bei hinreichend absurder Definition von "gut" vielleicht. Nichts für ungut aber grad für Firmen, in denen auch sowas wie Produktionssicherheit und SLAs (dann als "Abgabetermine" bekannt) eine Rolle spielen (und das ist bei unseren Kunden oft der Fall inkl. Konventionalstrafen oder einfach Umlage von Gebühren wie bspw. "stehende Tiefdruckstraße pro angefangener Stunde") eine Rolle spielen, sollte man sich das eher sparen. Und das trifft prinzipiell auch für rein lokale Syncs zu, die nicht auch noch zur NSA abbiegen. Auch da muß man erstmal unter Schlechtwetterbedingungen durchtesten, wie gut das mit solchen Konfliktsituationen umgeht.

Du gehörst glücklicherweise nicht zu denen, die sich bei dem Thema blind- und blödstellen (wie es ja das Gros der deutschen Bevölkerung macht und auf Ignoranz/Fatalismus setzt -- "wer nichts zu befürchten hat..." und so)

Das Problem mit der NSA und Dropbox ist aber leider zweistufig:

1) Storage in der Cloud: Da könnte starke Verschlüsselung auf Client-Seite schützen, sofern dort prinzipiell keine Hintertüren zum Einsatz kommen, die die Verschlüsselung aushebeln (bei Interesse nachlesen, welche Rolle Zufallsgeneratoren für starke Kryptographie spielen und inwiefern Hintertüren "ab Werk" in Prozessoren der US-Firma Intel diesbzgl. angreifbar sind)

2) Der Sync-Daemon: Wenn Du "die DropBox" irgendwas syncen läßt, dann installierst Du bei vollem Bewußtsein einen Daemon auf Deinem Mac, der mit den Superuser-Privilegien läuft, der am FSEvents-Mechanismus des Betriebsystems andockt und damit jegliche Dateisystemaktivität proaktiv gemeldet bekommt und dem Du erlaubst, permanent mit US-amerikanischen Server übers Internet zu kommunizieren.

Wäre ich bei der NSA angestellt und würde Punkt 2) das erste mal hören, dann reicht wohl ein Packerl Taschentücher nicht mehr aus. Man muß keine Hardware-Implantate an/in Rechner einbauen, man muß die Betriebsysteme nichtmal umständlich mit Schadsoftware infizieren, um eine Hintertür zu installieren, man braucht sich nicht um Privileges Escalation und so'n Zeug kümmern, weil da ein Prozeß bereits als root läuft. Es reicht völlig, die Jungs von der FBI bei der US-Firma Dropbox mit einem NSL (National Security Letter) vorbeizuschicken, um umgehend eine bei Bedarf blitzschnell aktivierbare Hintertür, die die User freiwillig und bei vollem Bewußtsein installiert haben, zu aktivieren. Weihnachten und Ostern für die Drei-Buchstaben-Vereine zugleich. Und wie wir inzwischen leider bzw. zum Glück alle wissen, sofern wir uns nicht blind-/blödstellen, machen die auch alles, was technisch möglich ist.

Wir haben letztes Jahr für einen Kunden einen Proof-of-Concept für eine mobile Backup-Lösung erstellt (einfach an das Mobile Backup-Feature von TimeMachine angedockt, ein verschlüsseltes SparseBundle mit kleinerer Bandsize, die zu der Datenbrockengröße, die Dropbox beim Sync paßt, verwendet und lokal das SparseBundle befüllt). Klappt super, die Ablage der Daten "in der Cloud" dürfte -- wenn man den aktuellen Stand der Technik bzgl. Aushebelung von Kryptografie mal freundlich ausblendet -- sicher sein. Aber die wissentliche Installation einer NSA-Backdoor auf Firmenrechnern könnte strafrechtliche Konsequenzen haben.

Nicht anders bei anderen Cloud-Lösungen. Abgesehen davon, dass man deren eigenen "Security Features" prinzipiell nicht trauen kann (siehe iCloud, wo die Daten zwar mit eigentlich ausreichenden Standards verschlüsselt werden, die Schlüssel aber direkt daneben liegen, d.h. im Vollzugriff der NSA), beinhaltet das Feature "automatisch mit Cloud abgleichen" systemimmanent auch und automatisch "Hintertür". Bzw. in dem Fall sogar eher "Vordertür".

Ja, mir ist die Problematik durchaus bekannt. Und supergeheime Dokumente würde ich ohnehin nicht in eine Cloud tun, eigentlich nicht mal überhaupt in irgendeiner Weise einem digitalen System anvertrauen. Die Russen schaffen nicht umsonst wieder Schreibmaschinen an ().

Meine Arbeitsdaten sind aber Dokumente, die kurze Zeit später sowieso veröffentlicht werden (Werbung). Daran ist nichts geheim. Bei Angeboten und Rechnungen eines kleinen Heizungsbauers z.B. dürfte die NSA wohl auch kaum Interesse haben. Bei Dokumenten, welche für Wirtschaftsspionage interessant sein könnten, würde ich auf eine gute Verschlüsselung zurückgreifen. Dann lässt sich auch eine Cloud verwenden.

Für Dropbox und andere Clouds empfiehlt sich übrigens die deutsche Software Boxcyptor () oder eben ein Disk Image.
Nur in der Praxis arbeiten selten 2 Leute gleichzeitig an einem Dokument. Und man ändert auch nicht auf einem Rechner tausende Dateien quasi gleichzeitig. Daher ist so einen Test-Parcours praxisfern.

Wie gesagt, bei kleinen Arbeitsgruppen (in meinem Fall Handwerksfirmen) klappt das ganz hervorragend. Und das schon seit vielen Jahren.

Wenn man einen File-Server verwendet, dann muss man auf viele sehr nützliche Funktionen von Mac OS X verzichten. Außerdem kostet er Geld und er kann ausfallen. Störungen müssen auch immer wieder behoben werden, er muss auch gewartet werden.

Beim Cloud-Sync kann der File-Server kein Ausfall verursachen, denn es gibt ihn nicht. Fällt der Arbeitsrechner aus, geht man einfach zu einem anderen Rechner und arbeitet dort weiter.

Ein ausgefallener File-Server kann eine ganze Arbeitsgruppe lahmlegen.

Letztlich muss aber jeder selbst überlegen wie er am besten fährt. Und Cloud-Synchronisation ist dabei durchaus eine praktikable Lösung, das zeigt die Praxis ganz klar. Und es auszuprobieren kostet nichts (oder nicht viel).

Tja, schade, dass die MegaRAID-Controller keinen OS X Support mitbringen, denn sonst wäre es ja Dank der Natur von Thunderbolt (PCIe am Kabel) durchaus möglich, sowas auch am Mac einzusetzen, sogar so, dass der typische Mac-User immer noch glauben würde, Thunderbolt wäre eine Festplatten-Schnittstelle: http://www.netstor.com.tw/_03/03_02.php?MTA4

Die kleinen Promise-TB-RAIDs auch mit nur 4 Einschüben bieten RAID-6 und aktuell ist das sinnigerweise sogar genau so vorkonfiguriert. Leider erblöden sich in vielen Installationen Admins (Usern und Privatanwendern kann man an der Stelle eher nix vorwerfen), das auf RAID-5 umzuheben und karikieren das Prinzip RAID. Milchmädchenmodus eben

Zum ganzen Rest kann ich Dir nahezu uneingeschränkt zustimmen. Fehlendes ECC-RAM im Zusammenhang mit Dateisystem mit niedriger Halbwertszeit (HFS+) ist meines Erachtens der stärkste Minuspunkt an einer kleinen OS X basierten Lösung.

Man kann davon einiges durch Konzept, Notfallpläne und redundante Hardware abfangen (und das bedeutet in jedem Fall: Zweites größeres RAID für echtes Backup und nicht nur Spiegelung. In so einem Fall merkt man dann ggf. auch noch rechtzeitig Bitkipper an der Quelle, weil das Backup explodiert. Aber dafür müsste man Monitoring einsetzen, was a) in Mac-Klitschen nahezu nirgends passiert, was b) einigermaßen simpel einzurichten/nutzen ist und was c) ein dermaßener Segen hinsichtlich der Erkennbarkeit von Situationen ist, dass ich mich rückblickend immer noch in den Ar*** beißen könnte, das nicht schon längst bei allen Kunden verpflichtend und flächendeckend eingeführt zu haben )

Nein. Siehe das Posting, auf das Du Dich beziehst. Du mußt alle Randbedingungen von "gute Verschlüsselung" verstanden haben und deren richtige Implementierung prüfen können.

Nein, bzw. nur wenn man sämtliche 2013 bekannt gewordenen Entwicklungen in dem Bereich komplett verpennt hat.

Das ist halt der Unterschied zwischen Schönwettertests und Schlechtwettertests. Wir können da leider nicht anders als uns a) konzeptionell zu überlegen, welche Schwächen eine Lösung hat, b) ein Instrumentarium zu schaffen, um den Worst Case zu simulieren und c) diesen Worst Case dann auch zu testen (denn das ist das, mit dem man später mal umgehen können muß bzw. den man sinnvoll abfedern will).

Wie Du auf "tausende Dateien quasi gleichzeitig" kommst, ist dito rätselhaft. Wir haben mit 4 Dateien getestet. Wieviele Varianten Dropbox dann daraus in den Sync-Ordnern gemacht hat (und wie aberwitzig viele dann in dem normal unsichtbaren Dropbox-Cache-Folder herumgelegen sind am Ende) haben wir allerdings nicht gezählt.

Mag sogar sein solange man "schönes Wetter" als Randbedingung definieren kann

Im Ernst: eine Eigentümlichkeit des graphischen Gewerbes ist ja unter anderem "Dateireferenzierung anhand absoluter Pfade". Wenn ein Layout-Dokument auf ein Bilddokument an Stelle xy verweist, die neue und eigentlich zu aktualisierende Version sich dann aber als "xy (Marias conflicted copy from bla/bli/blubb)" daneben manifestiert, ist man schnell ganz weit weg von jeglicher Produktionssicherheit.

Und wenn man mal bisserl eifrig im Team arbeitet, dann wird's immer genau dann, wenn man's am wenigstens brauchen kann (Rush Hour kurz vor Abgabeterminen) das meiste Geschissel mit Dateiversionskonflikten geben. Die "Lösung" ist halt leider keine.

Also das ganze kann man deutlich günstiger umsetzen. Man braucht für Fileservices keine VM Lösung und auch kein SAN. Wozu bietet SAS Wide Verkabelung an? D.h. zwei Server mit RAID Controller sind an Wide JBODs angeschlossen. Man muß in diesem Fall unbedingt SAS Platten einsetzen, aber die sind ohnehin nicht so teuer in Relation zu SATA Server Platten. Auch mit SAN/iSCSI werden ein gesharter Storage im Zweifelsfall zerstört und man muß erstmal ein Konsistentcheck über das RAID laufen lassen, wenn man den Server nach einem Crash umschaltet. Worst Case ist der Restore des Komplettbackups. Vorteile von einem SAN hat man hier nicht wirklich.

Solange alle Arbeitsplätze an einem Switch hängen, braucht man auch keine zusätzlichen Switche. Fällt der zentrale Switch aus, steht ohnehin alles. Sinnvoll wird eine Fabric nur dann, wenn die Arbeitsplätze an verschiedenen Switchen angeschlossen sind, oder jeder Arbeitsplatz mit zwei NICs ausgestattet ist, was i.d.R. nicht der Fall ist.

Optimist, bei uns kommt es sehr viel häufiger vor, daß das RAID Probleme macht. Ok, der Mini wird eher früher anstatt später Probleme mit dem Netzteil oder dem Speicher entwickeln. Mit besserer Hardware hätte diese beiden Probleme nicht.

Was macht also diese Kleinfirma, wenn der RAID Controller verreckt?

Klar, war ja nur ein Beispiel. Es gibt unzählige Lösungen und Konfigurationen.
Das passiert eigentlich relativ selten, die Ausfallrate bei den minis ist nicht sehr hoch. Mal stirbt eine interne Platte, aber Netzteil oder RAMs eher selten.
Typischerweise laufen weitere Platten mit, die min. ein aktuelles 1:1-Backup als offenes Dateisystem fahren. Sollte also das RAID ausfallen, wird darauf zugegriffen. Promise liefert relativ schnell per Vorab-Tausch die Gehäuse an, in einem bis zwei Werktagen.

Hättest Du Lust, das mal knapp aber halbwegs konkret zu skizzieren? Auf der Basis der angefragten Aufgabenstellung also "Fileserver für paar Mac-Arbeitsplätze". Gehen wir mal von aktuell 6 TByte Nutzdaten aus (ja, willkürlich gewählt). Dann könnte man das evtl. mit "OS X Bordmitteln" wie folgt anzugehen versucnen (ich würde es mangels Erfahrung mit so 'ner Lösung als produktiver Fileserver nicht machen -- wir kennen den AppleFileServer immer nur aus Situationen, wo wir ihn durch was Unixoides auf "echtem Server" ablösen):

2 x Mac Mini (Core i5, 16 GByte RAM, OS X Server.app, TB-Ethernet-Dongle) à ca. 600,- €

2 x Pegasus-R6 mit 7,x TByte netto http://geizhals.at/de/promise-pegasus-r6-12tb-f40ds6704100000-a656862.html à ca. 1.700,- €

1 x Areca ARC-8050 http://geizhals.at/de/areca-arc-8050-a986580.html à ca. 1.000 €

8 x WD3000F9YZ http://geizhals.at/de/western-digital-se-3tb-wd3000f9yz-a957529.html à ca. 140,- €

Die Minis haben vermutlich irgendeine interne Platte, das ist aber egal, weil die stillgelegt wird, da das Startvolume als eigene Partition mit auf den Pegasus ist.

Der erste Mini mit Pegasus R6 ist der produktive Fileserver, der mit einem 2 Gbit/sek-Trunk am -- als gegeben bzw. bereits vorhanden anzusehenden -- Gbit-Switch hängt, der andere hängt ebenfalls per Trunk am Netz (idealerweise weit weit weg bzw. in anderem Brandabschnitt), an dessen TB-Ports hängt das Areca mit 17,x TByte netto als alleinige TimeMachine-Share. Dort an dem Mini hängt auch das zweite R6, auf das periodisch 1:1 der Datenbestand des ersten am anderen Mini synchronisiert wird.

Der erste Mini sichert parallel per TimeMachine übers Netz auf das Areca am zweiten. Auf den Clients wird durch angepasste TM-Property-Lists alles, was dort sinnvollerweise noch lokal zu sichern ist, ebenfalls aufs Areca am Failover-Mini gesichert. Die Lösung kostet netto inkl. Thunderboltstrippen keine 7.000,- € und federt eigentlich schon einiges ab (egal wie unelegant das aussehen mag). Von der Performance her reicht das unserer Erfahrung nach (auf der Basis "typischer Medienbetriebe") völlig aus, evtl. steigenden Storage-Kapazitätsanforderungen kann man durch Plattentausch in 2-n Jahren relativ günstig gerecht werden.

Wie sähe eine Alternative auf richtigem Blech mit richtigem Server-OS aus? Bzw. was wäre daran (abseits Performance -- die reicht) daran alles auszusetzen?

Danke Thomas!

Fangen wir mal mit dem Ende Deines Postings an. Die Mac minis fehlt folgendes IPMI, ECC und redundantes Netzteil (das ist aber am ehesten zu verschmerzen). Es fehlt ein Hinweis auf die Failover Lösung für den AFP Dienst. Wir der Dienst von Hand umgezogen?

Ferner ist der Aspekt Synchronisation relativ wage. Wie sollen die Server konkret synchron gehalten werden?
Wir haben viele SuperMicro Boxen. Unter anderem weil man faktisch jede wilde Kombination von Chassis und Mainboard (ATX Board geht nur mit ATX Chassis und WIO Board nur mir WIO Chassis) vom Händler kaufen kann und Support darauf bekommt. Zertifiziert sind die Boards auch für alle wichtigen OS (Vmware, Windows Server, RHEL, SLES, Ubuntu, …).

Zur Software: für Mac Clients braucht man natürlich einen AFP Service, uns fehlt da die praktische Erfahrung, weil wir nur wenige Windows Systeme haben und massenweise Linux Systeme. Das liefe auf das vorher schon angesprochene Netatalk, Helios o.ä. hinaus. Da AFP nur einen aktiven Server unterstützt, muß man eine HA Lösung benutzen, um den aktiven Dienst zu überwachen. Wir haben dafür eine kommerzielle Software, weil die Paket so geliefert wurde. Aber dafür reicht auch Pacemaker+Heartbeat aus. Problematischer ist es Regel für die Überwachung zu schreiben, damit das zuverlässig erkannt wird. Wenn man das nur von Hand umschalten will, gibt es keine wirklichen Probleme.

Es ist bei AFP vollkommen egal, ob man iSCSI, FC oder eben ein anderes FS als Storage Backend nutzt, die Problematik des Failovers besteht hier immer, weil man das Backend niemals von zwei AFP-Server aus mounten darf. Mit den Techniken oben wäre man ja prinzipiell in der Lage unter Linux mittels GFS2 das FS von zwei oder mehr Computern zu mounten. Der interne Zustand des AFP-Servers (genauso bei NFS und SMB) macht das bei AFP aber unmöglich.

Zum Storage:
Damit man zwei Server synchron halten kann, kann man entweder das per Skript synchronisieren (cron job + rsync o.ä.), man nutzt eine BlockDevice Lösung (z.B. drdb) oder man nimmt lieber gleich ein passendes ClusterFS. Beispiele dafür GlusterFS, Lustre, FhGFS, GPFS, … Wir haben FhGFS im Einsatz, es taugt als HPC FS. Für normale Aufgaben erscheinen mir GlusterFS (das haben wir in einer Testinstallation laufen) besser geeignet.

Der wesentliche Unterschied zwischen GPFS und den anderen ClusterFS, die letzteren brauchen jeweils ein Backend FS. GPFS macht alles selbst und kann deshalb ein declustered RAID umsetzen und kommt komplett ohne Hardware RAID Controller aus. Ferner beherrscht es SSD Caching in Software. Bei Linux ist das erst neu eingeführt worden, und somit in den Produktionsversionen der Distributionen noch nicht enthalten, und scheidet somit als Option für die anderen FS aus. Als Backend FS kann somit ext4 oder xfs nutzen. RHEL unterstützt ext4 bis 25TB und xfs bis 100TB Volume Size. Es gibt noch ein paar andere kommerzielle Lösungen und nicht nur GPFS.

Alternativ kann man ein RAID/JBOD nehmen, welches von zwei Server gemeinsam genutzt wird. Es kann dann aber wegen der AFP Problematik nur von einem Server gemountet werden. Als Beispiel dafür sei das Dell MD3200 genannt. Die IBM GSS24 bzw 26 nutzen gemeinsam Wide JBODs, die auch gleichzeitig von beiden Server genutzt werden, aber da GPFS geshared gemountet werden kann, greifen jeweils beide Server auf die JBODs zu.

Als OS nimmt man sinnigerweise entweder RHEL oder einen Clone davon. (Scientific Linux ist ganz brauchbar.) Bei GPFS läuft auf den Server eine spezielle RHEL Version, und man braucht neben dem GSS noch zwei weitere Server für die Lizenzen anfallen. Für das Minibeispiel von Dir fällt GPFS ohnehin heraus, da es zu teuer ist.

Kommen wir zur Hardware. Es ist leider so, daß eine nahezu endlose Anzahl an Server Modellen gibt. Je nach Bedarf sollte man zu einem 3.5" oder 2.5" Gehäuse mit SAS Backplane greifen. Wahrscheinlich ein 2U und ein 3U System, da passen dann ausreichend Platten rein. Als Server reichen je ein Xeon E3 aus, dazu ein LSI RAID Controller + CV und bei Bedarf CC mit einer Server SSD. Für die Netzanbindung nimmt man eine 10GbE Karte. Software wie oben skizziert.

IPMI und Netzteil wären mir wurscht. Bauchschmerzen bereiten mir ganz konkret:

- kein ECC-RAM (die Idee, ein kippendes Modul evtl. noch rechtzeitig zu erkennen, dadurch, dass das Backup explodiert, müsste sich auch erst mal in der Praxis als praktikabel erweisen. Bei näherem Nachdenken halte ich meine Idee mittlerweile für blöd)

- HFS+ als das hinsichtlich Datenintegrität wohl am schlechtesten aufgestellte FS im Vergleich zu allen anderen heute im "Servereinsatz" gebräuchlichen

- AppleFileServer (hab das immer nur am Rand mitbekommen. Aber für meinen Geschmack ist der grad unter Last -- viel zu -- instabil).

Wobei in dieser Liste meine größte Sorge Bitfehler im RAM sind. Das ist ja schon mit guten FS tödlich, an der Stelle zu sparen (sollten es Mitleser nicht glauben, dann bspw. goutieren), mit HFS+ wird's dann fast schon kriminell. Bitkipper, die HFS+ Strukturinformationen betreffen, führen dann eben nicht nur zu schleichender Datenkorrumption sondern gleich zu defektem Dateisystem, das auch "Disk Warrior" nicht mehr retten können wird, wenn's blöd läuft.

Muß wohl mangels Alternativen, die das automatisieren könnten. Apple hat ja "IP Failover" in OS X Server schon mit 10.6 wieder über Bord geworfen. Dito die Idee, eine HA-Fileserver-Lösung mit einem (X)SAN dahinter betreiben zu können (meiner Meinung nach auch und vor allem, weil XSAN bzw. das StorNextFS in Extremfällen Probleme mit CNIDs hatte, die ganze ID-Verwaltung war da ja draufgepropft und wird dann doch nicht zu 100% kompatibel mit der in HFS+ integrierten gewesen sein).

Konsequenterweise verweigert der AppleFileServer seit 10.7 auch das Sharing von anderen FS als HFS+ -- wohl aus dem simplen Grund, dass oberhalb HFS+ der ganze ID-Kram via API von HFS+ ausgeborgt werden kann und sich der AppleFileServer selbst null mit IDs rumschlagen muß.

Hätte ich mit einem mehrstufigen "dummen" 1:1 Sync gemacht:

1) an FSEvents andocken, um eine Liste der Verzeichnisse mit Änderungen zu bekommen, diese über 1-n Minuten konsolidieren und dann alle Verzeichnisse differentiell per rsync syncen lassen

2) alle n Minuten (30 oder 60) einen rsync übers ganze FS laufen lassen, der das, was an der Quelle gelöscht wurde, entweder löscht oder falls am Ziel Platz ist, dort irgendwohin zur Sicherheit bewegt, wo's dann periodisch abgeräumt wird (so als "Netz und doppelter Boden")

3) Das TM-Log "abhören", sobald dort "deep traversal" auftaucht (Indiz dafür, dass die FSEvents-Schnittstelle übergelaufen sein muß und damit Events durch die Lappen gegangen sind) einen kompletten Sync per rsync anstubsen (lassen)

Alles komplett automatisiert und passend in ein parallel einzurichtendes Monitoring-System (ggf. auch nur beim Dienstleister stehend) berichtend. Ohne sowas halte ich das ganze Unterfangen auf Basis OS X eh für Harakiri.

Das eigentliche Problem, das jeder AFP-Server hat, ist dass er eine Kombination aus Fileservices und Datenbank darstellt (außer der AppleFileServer, der diesen Part an das bröselige HFS+ drunter delegiert). AFP muß mit Dateireferenzierung per CNID (Catalog Node ID) zurechtkommen (also Client fragt an nach "Gib mir Datein mit Namen »bla.txt« in Verzeichnis mit der CNID 345435) und muß dafür Datenbanken pflegen.

Und diese Datenbanken stellen ein wenig ein Problem bzgl. eines vollautomatischen Failovers dar (denn wenn der DB-Server wegcrasht, dann sind die ggf. in inkonsistentem Zustand). Eben aus der Fragestellung heraus hat NetAFP nun zus. MySQL als CNID-Backend in Netatalk 3.1 eingeführt. Man kann jetzt von MySQL halten, was man will. Aber damit könnte man zwei Netatalk-Server mit shared Storage auch noch als MySQL-Cluster einrichten und bekäme auf die Variante eine echte HA-Lösung hin (sogar als aktive Lösung, so dass beide Netatalk-Instanzen einfach je die Hälfte der Volumes rausreichen und nur im Failoverfall nach Übernahme der IP-Adresse eine Instanz alle Volumes bereitstellt). Auf Mac-Seite müsste der sekundäre AFP-Reconnect das Ganze dann richten, wenn man das vorher sauber durchgetestet hat (weil der Client seine eigenen Vorstellungen hat, was wie geschehen soll, wenn bspw. nicht innerhalb soundsoviel Sekunden irgendwas wieder auf einen ping reagiert)

Mein Bauchgefühl sagt mir, dass man eine vollwertige HA-Lösung nur einsetzen will, wenn die wirklich zu 100% robust ist und exzessivst durchgetestet. Ich wüsste aktuell nicht, wer sich diese Arbeit in diesem Kontext schon gemacht hat und für das Ganze als bekanntermaßen stabiles Setup die Hand ins Feuer legen würde.

Ich würde an der Stelle eh eher zu Solaris und ZFS tendieren (das hat diverse Features wie SSD-Caching schon länger und in der Praxis ausreichend bewährt). Aber das löst die grundlegenden Probleme auch nicht.

An der Stelle hätte ich mir bisserl mehr Konkretes gewünscht. Denn wenn ich das nur grob von der Grundhardware her überschlage, bin ich doch schon dermaßen jenseits von 7.000,- € und hab noch immer nichts, was ein Backup darstellen würde (und da bitte eines mit Restore-GUI, sonst bringt's in einer Agentur- bzw. Mac-Klitschen-Umgebung nichts. BTST). Die von mir für den Mini angedachte "Lösung", das übers Netz auf ein Areca-SAS-RAID zu machen, ist natürlich ganz weit davon entfernt, perfekt zu sein (SparseBundle sei Dank -- unnötige Komplexität rächt sich grad bei Backup gerne immer wieder)

Für die Aufgabestellung damit in jedem Fall schon "Kanonen auf Spatzen"

Der Vorschlag war eigentlich als Erwiderung auf Hannes G.s gedacht, Ausfallsicherheit gäbe es nur für 30k-50k.

Also konkret zwei baugleiche Server: Mainboard und Gehäuse . Das gibt es nicht so als BareBone in der Preisliste, da gibt es nur das Modell mit nur zwei GbE Ports. Über den Händler bekommt man dann die Wunschkonfiguration geliefert, man muß nur den Aufpreis des Mainboards zahlen. Dazu Xeon E3-1230v3 + 32GB RAM. Für beide zusammen ein Kit.

Als JBOD nimmt man ein SuperMicro Gehäuse und dazu ein JBOD Kit. Oder jedes andere Dual LSI Expander Backplane JBOD Gehäuse der Wahl. Der Vorteil dieser Lösung man hat einen HA Cluster mit geshartem JBOD und muß sich nicht um das Synchronisieren kümmern. Was fehlt ist ein Backup.

Die beiden Server werden direkt mit einem GbE Kabel verbunden fürs Failover, die RAID Controller werden nach Anleitung mit dem JBOD verbunden und dann hat man noch 3 GbE Ports an jedem Server frei. LSI hat für die Controller eine umfangreiche GUI Software für die Konfiguration, und fürs Backup nimmt man Bacula und speichert auf ein anderes Datengrab. Auch für Bacula gibt es ein GUI.
Preislich sind die Xeon E3 Server nicht sonderlich teuer, und diese Konfiguration ist sogar billiger als die Shared Stored Konfig oben, weil man nur Standardgehäuse einsetzt und normale RAID Controller. Wenn die Xeon E3 zu

Konkrete Konfig:
Board wie oben, LSI 9271-8i+CV ein 2U Gehäuse für 12x3,5" HDDs und ein zweites für 24x3.5". Synchronisiert wird per GlusterFS. Platten wieder nach Bedarf.

Auf der Suche nach Trost & Rat betreffend unserer Severausstattung bin ich auf diesen interessanten Thread gestoßen, wo einiges angesprochen wird, was unser Unternehmen betrifft. Darf ich mich daher hier "reinhängen"?

Tatsächlich ist aus meiner Sicht nicht die "maximal-elegante Lösung", sondern die in der Administration und bei Problemen schlankeste Konfiguration die bessere. Wenn Probleme auftauchen ist eine einfache Wiederinbetriebnahme wichtiger als potenziell 10% mehr Netzwerkdurchsatz.

Konkret steht bei in meinem Unternehmen (Grafikbetrieb mit 10 Arbeitsplätzen) der Umstieg von zwei vier Jahre alten Linux/Netatalk-Servern auf Max OS X 10.9.1 Server an. Da das alte Netatalk 2.0.? noch keine verschlüsselte Anmeldung unterstützt und somit sich die neuen Macs mit OS X 10.9 nicht anmelden können (OS 10.7 und 10.8 haben wir bis heute bei den Arbeitsplätzen ausgelassen) muss hier nun etwas geschehen.

Die komplizierte und zeitintensive Aktualisierung der bestehenden Linux-Server erscheint mir wenig attraktiv, die zu erwartenden Stehzeiten sind lästig. Auch habe ich derzeit keine Mac-erfahrenen Linux-Profis im Zugriff. Zwar läuft Netatalk bei uns äußerst stabil, aber auch nicht ganz "zickenfrei", mein Linux-Admin brachte damals Netatalk gerade mal so auf die Reihe und zeigt keine Lust sein Wissen zu vertiefen. Und nicht zuletzt ist die Suchfunktion für uns recht wichtig, eine Client-Server-Lösung wie Mac OS X Server sie bietet, hochinteressant.

Die aktuelle Kapazität der beiden eher performancekritischen Server-Arbeitsvolumes liegt bei derzeit 600 GB und genügt im Prinzip, leichter Zuwachs wäre natürlich immer schön. Der werktägliche Datenumsatz (Schreibvolumen) liegt bei rund 10-20 GB, also bei rund 2 bis 4 TB/Jahr. Eine wenig zeitkritisches zweites, größeres Servervolume stellt Archivdaten im Netz bereit. Backup des Arbeitsvolumes muss täglich verlässlich durchgeführt werden, ein möglicher Rückgriff über mehrere Tage ist anzustreben. Aus Performancegründen ist die Aufteilung der Last auf zwei Server kein Nachteil..

Mein Gedankengang: Was liegt also näher, als einen kleinen Mac Mini i5 mit zwei gespiegelten Samsung 840 EVO SSDs mit je 1 TB Kapazität zu bestücken und diesen mit OS X Server zu betreiben? Eine flinkere externe USB-3.0-Festplatte mit 24/7-Eignung mit 4 TB (Seagate Constellation ES.3 ST4000NM0023) als Archiv-Servervolume und eine zweite, gemütlichere (Seagate ST4000VN000) als Timemachine-Volume daran und "ferddich". Klingt klein, fein, sparsam und ist nicht absurd teuer.

Der Charme des Entfalls verschleißträchtiger mechanischer Komponenten, die geringe Zugriffszeit mit daraus resultierender Beschleunigung konkurrierender Zugriffe und der geringe Energieverbrauch wären mir den Aufpreis wert.

SSDs haben bewiesen, dass sie funktionieren, bei dem erwarteten geringen Durchsatz erscheint mir sogar Desktop-Technik (abgesichert durch ein Raid 1) zulässig. Probleme mit Dateinamen, Sherlock und der notwendigen Betreuung durch einen Linux-Profi scheinen mir hier der Vergangenheit anzugehören.

Gibt es hier Erfahrungswerte? Die geplante Nutzungsdauer liegt irgendwo bei 3 bis 5 Jahren.

SSDs funktionieren vor allem ganz anders. Und wenn man das nicht berücksichtigt, macht man den klassischen Fehler in der IT: alte Konzepte auf Neues propfen, wo sie überhaupt nicht passen. Und schon hat man wieder mal die olle Chose mit "gut gemeint ist das Gegenteil von gut gemacht" und eigentlich viel schlimmer: "In fälschlicher Sicherheit wiegen"

Und genau das wäre schon einer der kapitaleren Fehler. Ein RAID-1 aus 2 möglicherweise identischen SSDs, evtl. noch aus der selben Charge, ist leider eine extreme Sch***idee

Bin grad schreibfaul daher Zitatmodus:

https://groups.google.com/forum/#!searchin/de.comp.sys.mac.misc/kaiser$20raid$20ssd/de.comp.sys.mac.misc/tXPseFJWmVU/T4cenOm5psUJ

Ich würde nicht die internen Platten des minis für die Live-Daten nehmen, das erschwert das Umstecken enorm. mini mit 16 GM RAM bestücken, Live-Daten auf externes RAID, und gut.

Danke fürs erste Feedback, meine Herren!

Klar ist, dass alles, bei uns sogar auch die Arbeitsplätze, an USVs betrieben wird. Auch stehen genug Ersatzgeräte zur Verfügung, rund 10 Mac Minis i7 gleicher Generation (Late 2012) dienen als Arbeitsplätze -- als Ersatzteilpool verfügbar.

16 GB RAM sind am Radar.

Zwei idente Geräte (SSDs) zeigen natürlich dieselben logischen Fehler, klar. Die 840 EVO hat jedoch schon bewiesen, dass sie funktioniert, zumindest liest man nichts auffällig Negatives über dieses Modell. Wovon bei SSDs da und dort berichtet wird ist ein "spontaner Totalausfall", da hilft Raid 1 weiter, denke ich.

Das Argument des erschwerten Umbaus im Fall eines Geräte-Ausfalls ist klar, was ist jedoch die Alternative? Ich denke, das es keine gute Idee ist, die SSDs in externe Gehäuse zu verbauen, denn dann klappt TRIM (angeblich) gar nicht und das leistbare USB 3 ist ein Flaschenhals, Thunderbolt-Leergehäuse nicht erhältlich bzw. (noch) unverschämt teuer.

Danke für die Diskussion, trotz Schreibfaulheit.

Warum? Setzt Du bei dieser Empfehlung jetzt auf die von pseudo-statistischen Erhebungen bei Euch und Euren Kunden abgeleitete "Erkenntnis", dass das reicht, obwohl das Konzept objektiv ganz viel nicht abfängt und nicht abfangen kann?

Ich habe in den Weiten des iNet auch einen spannenden Bericht über einen relativ aufwändigen Versuch gelesen, wo es um das Verhalten in Hinsicht auf allgemeiner Verfügbarkeit, Lesbarkeit, und Richtigkeit von Daten auf 15 verschiedenen SSDs von 5 Herstellern gefunden und auch gelesen, wenn bei hoher last Stromausfälle provoziert werden.

Da prasselt es natürlich eine Menge Probleme von Totalausfall bis hin zu chronologischen Verfälschungen der geschriebenen Daten. Andererseits sind in Anbetracht der massiven Belastung der SSDs (alle 30 Sekunden irgendwann ein Stromausfall) über viele tausend Zyklen die Ausfälle und Fehler relativ selten geblieben -- wenngleich auch signifikant häufiger als bei klassischen Festplatten, die ja vergleichsweise primitiv sequentiell speichern.

Wear-out scheint bei SSDs, vor allem bei so großen Exemplaren, weniger das Problem zu sein.

Ein mit mir befreundeter Polizist sagte mal: "Manche wollen einfach einen Strafzettel und wollen bezahlen. Da mache ich zwei, drei, vier Verwarnungen, versuche Verständnis zu ernten. Als Antwort bekomme ich dann, warum alle anderen Schuld sind, warum die Physik jetzt gerade nicht gilt usw."

Nochmal langsam, da ich den Eindruck habe, dass Du nicht gerne liest:

Hat die SSD einen Serienfehler und Du baust zwei Serienfehler ein, dann hast Du ein Problem. Dem Problem ist es dabei egal, wie viele Amazonbewertungen Du vorher gelesen hast.

TB-Gehäuse sind nicht unverschämt teuer, sondern Qualitativ eine andere Baustelle als die meisten USB-Leergehäuse.

Eine SSD als Netzwerkspeicher einzusetzen scheint mir in etwa so sinnvoll, wie Postautos mit Turbomotoren auszustatten, damit die Post schneller liefert.

...von der Versioningproblematik, die oben episch breit diskutiert und erklärt wurde, mal abgesehen...

Die Theorie ist klasse.
Nur sieht die Welt der kleinen Unternehmen meiner Erfahrung nach meist anders aus.

Es ist doch so, dass sich in den meisten kleinen Firmen der Inhaber erst einmal selber um vieles kümmern will. Er fängt also damit an sich im Bekanntenkreis umzuhören was es für mögliche Lösungen gibt. Die Antwort darauf lautet heutzutage in den meisten Fällen "NAS" mit 2 - 5 Platten.
"Das ist eine ganz tolle Lösung, die ganz viel kann, und nur ca. 1000 - 2000 Euro kostet."
Mit diesem eingebrannten Gedanken meldet er sich dann beim Systemhaus. Und es liegt an uns ihn von dieser Harakiri-Idee wieder weg zu bekommen.
Ich bevorzuge die Lösung wie sie Thomas oben angesprochen hat. Die Mac-Minis mit externem System auf den RAIDs und Backup-RAID.
Aus Erfahrung scheuen die meisten Unternehmer die Anschaffung eines Ersatz-Minis, solange bis der laufende Mac-Mini wirklich irgendwann einmal ausfällt. Selbst die Anschaffung eines zusätzlichen RAIDs für die Spiegelung der Produktivdaten wird von vielen aus Kostengründen abgelehnt.

Und ganz böse sieht es bei den Firmen aus die sich gerade ein neues Systemhaus suchen, weil sie zuvor an jemanden geraten sind, der sie nicht davon überzeugen konnte mehr Geld auszugeben, und der ihnen dann ein NAS oder einen Mini mit nur einer externen Backup-HD verkauft hat.
Wobei diese Kunden natürlich sich nicht mehr auf einen Bekannten verlassen, und sie schauen können wie sie ihren Datenverlust wieder aufarbeiten, nachdem ihnen das Ding um die Ohren geflogen ist.

Deine Formulierung deutet zum Glück schon an, dass Du Zweifel hast (dann an der Oberfläche zu bleiben und sich nicht darauf einzulassen, in die Tiefe zu gehen, bedeutet bei Privatleuten "nur leichtsinnig" und bei professionellen Anwendern in jedem Fall fahrlässig, ggf. sogar grob)

SSDs und HDs gehen immer kaputt. Irgendwann oder auch sofort. Dieses "sofort" hängt aber von Randbedingungen ab, bspw. gibt es das in Form des klassischen DOA (death on arrival -- gerne auch noch mit Verzögerung. Gewisse Trümmer IT überleben die ersten Wochen nicht oder laufen dann jahrelang durch -- auch das wieder ein klassischer Fall für Statistik, in den man dann auch wieder Faktoren wie "geplante Obsoleszenz" einfließen lassen könnte) oder abseits davon in Abhängigkeit von Ereignissen.

Ein solches Ereignis kann ein einen seltenen Bug triggerndes seltsames Zugriffsmuster sein, kann ein Firmware-Update sein, whatever. Da sind hinlänglich Fälle bekannt.

Die andere Variante von "kaputtgehen" wäre dann Altersschwäche. Auch das tritt bei HDs und SSDs gleichermaßen ein. Nur in völlig anderer Spielart. Bei der HD sind die Daten futsch, bei SSDs sind die Dinger dann vom Controller auf read-only gestellt worden, d.h. die Daten sind noch da (zumindest mit extrem hoher Wahrscheinlichkeit. Und das ganze RAID- und Datenverfügbarkeits-Gehampel ist immer nur ein Spiel mit Wahrscheinlichkeit)

Zwei identische SSDs nutzen sich auch exakt identisch ab, weil selbe Flash-Chips verbaut, selbe Controller mit selber Firmware, die identisches Wear Leveling und Garbage Collection implementiert, identische Firmware-Bugs, die identisch fatal auf identische Ereignisse reagieren (siehe die Intel 320er SSDs und dem 8-Mbyte-Bug).

D.h. wenn ich diese SSDs am identischen Host-Controller anschließe und auch noch mit exakt den identischen Daten beschreibe (und äh... was macht dieses RAID-1 nochmal genau aus?) dann stelle ich maximal sicher, dass der Ausfallzeitpunkt beider SSDs so nah wie möglich aneinander liegt (weil dann nur noch Schwankungen in der Qualität einzelner Flash-Zellen den Unterschied machen -- wäre man jetzt Statistiker und kennt Daten bzgl. den Flash-Zellen kann man sich die Wahrscheinlichkeit, wie nah die zu erwartenden Ausfälle beider Platten beieinander liegen, sogar halbwegs exakt ausrechnen. Aber auch als Nicht-Statistiker und Mathe-Legastheniker muß einem klar sein, dass RAID-1 für eine Maximierung dieses Effekts sorgt)

D.h. das, was ich von RAID-1 erwarte, wird nicht nur überhaupt nicht erfüllt sondern ich stelle sogar das Gegenteil sicher. Alles nur, weil ich ein Konzept, das für HDs paßt, auf SSDs stülpe.

Nächster Punkt, der Dich jetzt nicht treffen würde aber all die Leute, die es für eine gute Idee halten, daheim oder im Kleinstbüro mit Hardware-RAID herumzuspielen: Wie reagiert der RAID-Controller darauf, dass eine SSD anders stirbt als eine HD? Welche Strategie implementiert das Ding, um zu erkennen, dass "kann noch gelesen werden" nichts bedeutet. Ist der RAID-Controller auf SSDs optimiert (das würde in jedem Fall schon mal TRIM-Support bedeuten) oder nicht? Wieviele dieser Fragen kann man im Vorfeld ohne Test sicher beantworten und wie viele nicht (huch, eigentlich alle!).

Drobo hat sowas. Aber Drobo will man eigentlich nicht, wenn man sich im Detail damit beschäftigt

Und die Schlüsse bzgl. USB3 basieren auf Unkenntnis bzw. dem Ausblenden der eigentlich wichtigen Fakten bzgl. USB. Bin immer noch schreibfaul und würde daher empfehlen, nach "UASP vs. mass storage bzw. bot" (ggf. gleich hier im Forum) zu suchen.

@Austro:
Wie hoch darf der Datenverlust bei einem Vorfall denn sein? 1Std? 2Std?
Wie hoch darf der Serverstillstand beim Vorfall sein? 10Min? 1Std, 1Tag?
Den Worst-Case in dem alles in die Knie geht lassen wir hierbei aus, denn dann sprengen wir den Rahmen. Dafür müssten genügend Geräte und sofort lauffähige Syncs und Backups ausser Haus vorgehalten werden.

Wie oben schon gesagt, ich bevorzuge die Variante die Thomas weiter oben geschildert hat, mit den 2 Mac Minis, 2 Daten-RAIDs und dem Backup-RAID.
Damit erreicht man schon eine recht gut Datensicherheit. Man verliert im nur die Daten die seit der letzten Synchronisierung erstellt wurden, und der Wechsel auf das Backup-System funktioniert innerhalb weniger Minuten.