hallo zusammen

Zur Zeit nutzen wir im Geschäft (Grafik Design und Desktop Publishing) für zirka 10 Arbeitsplätze ein Synology NAS. Der Server läuft sehr gut. Alle Mitarbeiter arbeiten direkt auf dem Server, administriert wird der auch durch uns. Bisher hatten wir nie Probleme. der Server hat schon eine Uptime von 250 Tagen. Backups laufen usw. Eigentlich durchwegs positiv. Das System ist nun schon knapp 3.5 Jahre Alt.

Wir haben nun vor das System durch einen Mac Server abzulösen. Da die Funktionen wie Server Spotlight und Tags uns wichtig sind.

Konkret haben wir folgende Hardware vorgesehen:

• Mac Mini Server (2,6 Ghz Quad-Core i7, 256 GB SSD, 8 GB RAM) – Evtl. gleich neue Hardware von Apple, updates sind ja fällig
• Promise Pegasus2 R4 8TB via Thunderbolt

Backup dann auf die alten Synology NAS, welche sich dann auch gleich noch mehrfach spiegeln.


Was meint ihr zur Konfiguration? Hat jemand Erfahrungen damit?

Kleine CPU und HDD statt SSD reichen für einen Fileserver, dafür lieber 16GB RAM nehmen.

Ansonsten ist das ein ganz üblicher Aufbau, reine Routine.

Also eigentlich:

Mac Mini:
2,6 GHz Quad-Core Intel Core i7
2x 1 TB Serial-ATA-Festplatte mit 5400 U/Min.
DDR3 SDRAM mit 16 GB und 1600 MHz – 2x 8 GB

Läuft das gut? Spotlight usw?

Hoffnungslos übermotorisiert

Wozu? Was willst Du mit der zweiten Platte? RAID-1 spielen? Wozu? Damit Du, falls eine Platte ausfällt (und das wird die obere sein), den Betrieb unterbrechen mußt, um den Mini aufzuhebeln und eine neue HD einzusetzen (besser gleich zwei, weil die andere wird paar Monate später hopps gehen). Tipp: Ein Mini startet hervorragend von externer Platte (also auch von einer Partition eines extern angebundenen SAS-RAIDs)

ECC-RAM wäre gerade für einen Server besser . Und wenn der Mini sowieso nichts tut (also nur Fileserver spielt), dann ist das RAM grad ab 10.9 eh nur Dateisystemcache, was wiederum in Verbindung mit lahmem "nur Gbit-Ethernet"-Anschluß ungefähr so sinnvoll ist wie... Fisch auf Fahrrad?

Gibts nur so in der Konfiguration



Auch nur so möglich.

Ich würde mich nicht so sehr an dem Begriff "Server" aufhängen... Auf dem "normalen" Mini OS X Server aus dem App Store aufspielen und fertig... Als Fileserver reicht der i5 locker und die interne Platte würde ich eigentlich gar nicht benutzen (oder maximal zum gelegentlichen Klonen des externen Boot-Laufwerkes).

Ok. Also ein normalen mac mini i5 nehmen mit 16 gb ram. Fusion disk?

Dual core oder quadcore?

Warum nicht die interne festplatte als boot laufwerk nutzen?

Könnte ich Dir vermutlich mehrere nennen. Machen wir 'nen Tausch? Du beantwortest zuerst mal, warum Du überhaupt auf die Idee kommst, die interne Platte als Boot-Laufwerk zu nutzen? Ist eine ernstgemeinte Frage, also interessiert mich tatsächlich sehr

Mmmh finde ich logisch. Also ich kauf mir ja auch keinen iMac dazu eine externe platte von der ich boote. Alle arbeitsgeräte bei uns booten von der internen.

Einziger grund wäre ausfallproblematik.

*kopfkratz*

Also das Argument ist nicht "weil's geht" sondern "weil wir's schon immer so machen"?

Nochmal 'ne Frage: Warum willst Du die "Daten" auf ein Hot-Swap-fähiges RAID legen? Was erwartest Du Dir davon?

Grundsätzlich gehts darum:

Fileserver mit os x (spotlight und co)

Mac mini und pegasus ist doch ne gute kombi.

Was ist am hotswap nicht gut?

Wir haben 10 mac im einsatz, von mac pro bis imac, alle mit fusion drive. Laufen ohne probleme, warum soll ich die extern booten? Ich kenne keine firma, ob agentur oder druckerei (ich kenne firmen mit hunderten mac arbeitsplätzen) die ihre arbeitsmaschinen von der externen festplatte booten. Keine machts, die haben nie probleme. Warum soll man das machen, nur weils technisch möglich ist? Wenn bei uns ein mac ausfällt ist ein neuer in 1 h neu aufgesetzt. Und komplett arbeitsfähig.

Naja, auf jeden Fall gründlich überlegen, was wirklich darauf laufen soll. Für "nur" Fileserver und ggf. OpenDirectory ist selbst ein i5 Dual Core mehr als genug, selbst noch wenn ihr einen Virenscanner permanent mitlaufen lasst. (Wir hatten in einem Projektbüro einmal knapp 50 User auf einem Core 2 Duo Mini aus, ich glaube, 2006/07 und der kam im Schnitt auf etwa 3% Prozessorlast.) Soll auf dem Ding auch ein Mailserver oder gar ein RDBMS laufen... sieht das ggf. anders aus.

Für mich (das mögen andere unterschiedlich sehen) sind die 2 Hauptkriterien eines Fileservers Datendurchsatz und Verfügbarkeit.

Der Datendurchsatz ist eh durch die Netzwerkschnittstelle begrenzt, daran liesse sich nur recht kostspielig über Thunderbolt Interfaces (bspw. nach 10 GbE) und teure Switches etwas drehen.

Für die Verfügbarkeit helfen schnellere Neustartzeiten und reduzierte Ausfallzeiten. Festplatten erzeugen Hitze und sind im Mini auch nicht eben schnell zu wechseln. Aus beiden Gründen nutzen wir die internen Platten in Mini Servern überhaupt nicht. Das ist aber, zugegebenermaßen, eine extreme Haltung, aber da ihr eh ein TB-RAID dranhängen wollt, würde ich das auch eher nutzen, als die interne Platte. Als Bonus sollte dieses RAID auch sicher mit den Neustartzeiten helfen.

FusionDrive ist eine nette Interimslösung für Privatnutzer, denen eine SSD noch zu teuer ist. In einem Fileserver, der 24/7/365 laufen soll hätte ich aber schon a) gerne eine Platte, deren MTBF auf Serverniveau liegt und die ich b) auch problemlos irgendwo kaufen, in Betrieb nehmen und Wiederherstellen kann. Also: Lieber Bewährtes. Wenn es unbedingt intern sein soll, dann lieber eine kleine SSD, selbst 128 GB sollten eigentlich mehr als genug sein.

Danke für die ausführung. Dh. idealerweise nebst dem TB Laufwerk einfach noch ne TB Platte fürs system?

Interne platten als ersatzsystem?

Beim raid: würdet ihr das leer kaufen und serverplatten einbauen? 7200er platten. Oder gleich komplett?

Andersrum: Was soll an nicht-hot-swap eigentlich irgendwie gut sein?

Wenn Ihr schon auf die Idee kommt wegen Datenverfügbarkeit auf ein RAID-6 zu setzen (Ihr seid hoffentlich so klug und setzt auf doppelte Redundanz und macht nicht den RAID-5-Fehler?), bei dem ein Plattenausfall nur bisserl zeitversetzte Bürokratie in Form des Garantieaustausches einer Platte aber keinerlei Unterbrechung bedeutet... warum wollt Ihr Euch dann ohne Not ein separates Verfügbarkeits-Problem konstruieren?

Wenn die interne Platte im Mini abraucht (oder eine in einem RAID-1) oder dessen Netzteil oder was auch immer, dann darfst Du erstmal sofort eine Unterbrechung kalkulieren (denn irgendwer muß jetzt den Mini öffnen und Platte tauschen oder falls der Mini komplett hin ist, das RAID umhängen an anderen Arbeitsplatz, OS X Server installieren, ggf. erstmal richtig konfigurieren, das alles in einer Streßsituation und natürlich gemäß Murphy's Law immer dann, wenn man's gar nicht brauchen kann und der eine, der sich mit der Technik auskennt, in Urlaub ist, etc. pp.)

Oder Du "opferst" von dem RAID-6 'ne 100 GByte Partition, legst das System da drauf... und wenn im RAID mal 'ne Platte stirbt, generiert das ein freundliches Lächeln, das Einschicken der defekten Platte zu Promise, 2 Tage warten, Zurückstecken neue Platte und fertig. Schon die ersten Promise sind bei einem dann fälligen Rebuild fast unverändert performant (was man jetzt auch kritisch sehen kann), so dass Ihr in dem Fall noch nicht mal merken werdet, dass da grad ein Plattenausfall stattgefunden hat. Und wenn der Mini wegstirbt, dann hängt man halt ohne jegliches Gezeter das RAID an irgendeinen anderen Mac, startet den mit gedrückter -Taste und fertig.

Und wenn Dir das RAM im Mini mit der Zeit schlecht wird, dann hast Du einfach Pech gehabt, weil Bitkipper ohne ECC-RAM fallen meist häßlich spät auf. Dazu kommt, dass ca. 0% der Mac-Anwender, die ich kenne, nach einer Speicheraufrüstung den neuen Speicher vernünftig testen (Mac mit -d starten, Apple Diagnostics startet, langen Test laufen lassen, ausschalten, Speicherriegel kreuzweise tauschen, selbes Prozedere von vorne).

Was Du evtl. noch alles nicht bedacht hast, kannst Du übrigens in dem Thread "Mac Server" von neulich finden... Das durchzulesen, dürfte aber vermutlich nicht ganz in Deinem Sinn sein

Naja, grad in seinem Szenarium mit "1 Server, 10 Clients" kann man den Gesamtdurchsatz aller Clients zum Preis von unter 25,- Tacken netto verdoppeln (vorausgesetzt man achtet darauf, keinen Switch vom Grabbeltisch im Baumarkt zu nehmen sondern einen, der LACP/Bonding beherrscht)

Man muß noch nicht mal drandenken, das zu erwerbende Ding idealerweise hinten am RAID zu befestigen, damit im Failover-Fall wieder das bond-Interface mit beiden Gbit-Interfaces funktioniert, weil das zum Glück nicht nur die Gesamtperformance verdoppelt sondern auch noch Fehlertoleranz bringt http://support.apple.com/kb/PH11019?viewlocale=de_DE

Hmm dazu hätte ich gleich noch ne Frage an dich als Experten. Ich habe das bei mir so eingerichtet, also Mac und Server hängen am Switch beide mit Bündelung und der Switch kann das auch und zeigt das auch entsprechend an, also scheint es prinzipiell zu funktionieren. Das Problem ist nur das ich keinen Geschwindigkeitsunterschied habe wenn ich mit LAN-Test (Helios) teste. Woran kann das liegen?

Da sehe ich eigentlich keine Veranlassung, siehe Kommentar von Thomas Kaiser... Einfach auf dem RAID eine Partition anlegen. Insgesamt braucht ihr natürlich eine Strategie für das Backup von Allem (System- und Datenpartitionen)... RAID ersetzt bekanntermaßen kein Backup.


Wenn ihr das Klonen bspw. in Ruhe- bzw. Nachtstunden verlegt, spricht da eigentlich nichts dagegen. Allerdings sollte, wie oben gesagt, erstmal ein Gesamtkonzept für Backups (Systemklon, Daten voll, Daten inkrementell, bei OD Verwendung auch Sicherung des Schemas, etc.) gemacht werden. Wenn das steht und Sinn macht, kann man sehen wie und wo man die Daten verteilt. Wir nutzen, wie gesagt, interne Platten gar nicht und persönlich würde ich die Standardplatte im Mini einfach ungenutzt drin lassen, damit ich gar nie in die Situation kommen könnte, die tauschen, prüfen oder hätscheln zu müssen.

In unseren (TB erste Generation) Pegasus waren bei Lieferung 2 TB Hitachi DeskStars mit 7200 rpm drin. Die haben sich bis jetzt eigentlich sehr gut bewährt. Wenn welche schlapp machen, werde ich sie durch UltraStar Modelle mit 2 Millionen Stunden MTBF und 5 Jahren Garantie ersetzen, den geringen Mehrpreis ist mir das wert. Was Pegasus zur Zeit verbaut, weiss ich nicht. Gemäss unserer IT Richtlinien hätte ich die DeskStars separat nicht kaufen dürfen, da Hitachi gar kein MTBF Rating für die angibt... Also bei zukünftigen Bestellungen würde ich dann wohl nur die Gehäuse ordern, damit mich keiner beißt.

Steht da oben: LACP/Bonding (oder auch Trunking oder bei Cisco EtherChannel) folgt immer dem identischen Prinzip: je Verbindung gibt es nur Link-Speed, d.h. ein Client wird mit dem Server niemals mehr als die Geschwindigkeit erreichen, die ein Interface hergibt.

Spannend wird es immer erst in 1-to-many, many-to-1 und many-to-many-Situationen. Dann sorgen diese Varianten dafür, dass anhand gewisser Kriterien die eine Verbindung über das eine Interface und die andere über das andere läuft. In Summe eröht sich damit ein möglicher höherer Gesamtdruchsatz.

Aber: auch das muß nicht sein, indem die falschen Algorithmen zum Einsatz kommen. Es kann durchaus sein, dass man in einem LAN zwei Power-User hat und die sich Dank doofem Verteilungsalgorithmus auf einem Interface des Servers gegenseitig ausbremsen während bspw. 8 weiteren Clients auf dem zweiten Interface herumidlen. So richtig nett wird -- ohne dass man sich im Detail damit beschäftigt -- diese ganze Bonding-Chose erst ab sehr vielen Clients. Weil dann auf einmal auch primtive Load Balancing Algorithmen nix mehr falsch machen können.

Im Zweifel hilft nur: Messen bzw. Monitoring (gerade Letzteres ist ein Segen. Und am Mac so bamperleinfach, dass es fast schon eine Schande ist, das nicht zu nutzen). SNMP ist schnell angeknipst und 1a Monitoring-Systeme wie bspw. OpenNMS sind OpenSource. Und wenn man dann noch die Macs Parameter wie bspw. Plattenfüllstände oder auch "Seltsamkeiten in Log-Dateien" per SNMP eintüten läßt, hat man im nachhinein als auch prospektiv immer den vollen Überblick.

Schnell mal bspw. der Inhalt der /etc/snmp/snmpd.conf eines MacPro mit 10 GbE-Karte, der Sync-System spielt:

Sehr guter Hinweis. War bei uns damals leider keine wirkliche Option, da die prä-TB Minis ja maximal USB 2.0 für das zweite Interface boten. Das reichte für den Einsatz als Dual-Homed Gateway, war aber für Fileserver komplett nutzlos. Wurde mehr als 1 Gb gebraucht, musste es ein Mac Pro oder Xserve sein.

Aha wieder was gelernt, hatte mir das zwar schon so gedacht aber nun weiss ich es genau… das mit dem Monitoring hört sich interessant an aber wie gesagt.. ich bin endanwender und da sagt mir das nicht viel. Ich kann da zwar was mit Error raus lesen aber das wars dann auch schon...

Jede OS X Version der letzten 100 Jahre hat eine Überwachungsschnittstelle an Bord. Das freut nicht nur die NSA sondern auch den Systembetreuer, denn der muß eigentlich nur ein bisserl was in einer Konfigurationsdatei eintragen und fortan kann er in sog. Monitoringsystemen diese Daten permanent erfassen und sich bei den komfortableren auch in Graphen malen lassen und viel wichtiger: Trigger/Schwellwerte und Aktionen definieren. Im Beispiel oben reicht das bisserl Text, dass Graphen für die 4 Volumes gemalt werden (wie das aussieht im Fall OpenNMS bei einem sehr vollen Backup-RAID siehe unten) und dass vollautomatisch Warnungen generiert werden, wenn das Boot-Volume unter 25% oder eines der anderen Volumes unter 5% freien Platz sinkt.

Dito werden durch die proc-Zeilen sichergestellt, dass vollautomatisch überwacht wird, dass von jenen Prozessen mindestens soundsoviel und höchstens soundsoviel Instanzen laufen. Und zu guter Letzt wird ebenfalls "total billig" durch die logmatch-Direktive sichergestellt, dass Seltsamkeiten, die in beliebigen Logdateien auftauchen sollten, vollautomatisch ins Monitoring kommen, dort wiederum zu Graphen verwurstet werden können (spannend bspw. die Anzahl crashender Prozesse über die Zeit, steigt die auf einmal immer mehr an und hat sich sonst nix geändert -- olé ein RAM-Riegel dürfte grad am Abnippeln sein) und viel spannender: automatisch Warnungen triggern.

Und eben jene Warnungen kann man sich konfigurieren. Wichtige Sachen will man ggf. sofort per Mobiltelefon, Unwichtiges per Mail, etc. pp.

Das ist der Sinn von Monitoring. Und OS X hat all den Kram gratis an Bord. Ausgewachsene Monitoring-Plattformen gibt's als Freeware. Und preiswerte kommerzielle Lösungen gibt's auch noch, bspw. PRTG: http://www.de.paessler.com/prtg (die free-Edition mit maximal 10 Sensoren ist aber definitiv nur Anfixen)

Danke für die Infos, aber mir fehlt die Zeit um mich damit genau zu beschäftigen,
ist leider nicht mein Beruf.

Danke für die Infos. ich habe mal ein grobe Zusammenstellung erstellt. ich werde später dies schriftlich noch erläutern. aber schaut euch das doch mal an.

Schon klar, war auch mehr so in die Runde gelabert

Der Witz ist, dass dieses Monitoring-Thema "meine IT-Erkenntnis des Jahres 2013" war (in mehrerlei Hinsicht sogar). Ich hielt das vorher für was, was sich erst in Installationen mit vielen kaskadierten Switches und komplexer Infrastruktur rentiert und dass man eigentlich nur paar Parameter von Servern überwachen "muß".

Und kaum probiert man's mal aus, klatscht auch alle Client-Rechner (egal ob Mac oder Windows) mit rein, läßt den Kram einfach mitlaufen und guckt dann mal, was man mit den Daten so anfangen kann, dann wird einem schlagartig klar, was für ein elender, dämlicher und völlig unnötiger Blindflug in der IT normalerweise stattfindet.

Da wird "aus dem hohlen Bauch" heraus vermutet, dass man das Netzwerk eigentlich soundso dimensionieren müsse, der Storage am Server eigentlich dasunddas hergeben müsse, bei von Usern gemeldeten Problemen das Rätselraten angefangen anstatt einfach nachgeschaut, usw. usf.

Bzgl. Problemeingrenzung bzw. präventive Problemvermeidung ist das Ganze aber noch viel feiner, einfach weil Zusammenhänge sichtbar im Wortsinn werden (einfach paar Graphen kombinieren und Du hast Korrelationen offenbart, auf die Du vorher nie gekommen wärst). Und all das kriegst Du gratis von jeder OS X Maschine. Bisserl Konfiguration, den snmpd anknipsen und schon werden fast alle relevanten Betriebsparameter in ein Monitoringsystem reingekippt und stehen für Auswertungen und v.a. proaktives bzw. sofortiges Handeln (Dank Triggern/Schwellwerten) zur Verfügung.

Und damals als Apple noch vernünftige Hardware gebaut hat, sind auch die ganzen Sensoren der xServes und später MacPro ebenfalls automatisch per SNMP rausgereicht worden (was letztlich den alten MacPro in gebraucht und mit ECC-RAM eigentlich zur viel geeigneteren Servermaschine machen würde, siehe unten: das ist ein oller MacPro1,1)

Apropos ECC-RAM: das ist wie mit "richtigem Backup" also auch wieder so eine Sache, die man erst lernt, wenn's mal passiert ist (kaputtes non-ECC-RAM in Servern hat völlig andere Auswirkungen als auf Client-Rechnern: das korrumpiert die Daten, die auf dem Storage landen on-the-fly weil fast alles RAM in File-Servern FS-Cache ist).

Egal, letztes Wort zum Monitoring: Stell Dir vor, Du hast 15 Dioptrin auf beiden Glubschern, weißt nicht, dass es Sehhilfen gibt, rennst durchs Leben und findest es völlig normal, dass Du fast nichts siehst. Und dann setzt Dir irgendwer eine Brille auf die Nase. Das ist kaum zu fassen. Auch und vor allem wie blind man vorher war. Und es gibt kein zurück mehr

Tolle Bildskalierung hier Also nochmal solo

Und fertig... wie schon geschrieben: Alles Parameter, die ein OS X "einfach so" rausreicht. Wenn die Hardware paßt sogar inkl. Sensoren. Setzt man auf blöde Hardware wie bspw. Minis, dann hilft bspw. Marcel Bresinks Temperaturmonitor, dessen Sensordaten man auch per SNMP in große Monitoring-Systeme kippen kann. Marcel hat aber auch für kleines Geld kleine remote-Hardware-Monitoring-Lösungen im Programm . Wer sich sowas spart und auf etwas tendenziell Ungeeignetem wie einem Mini Serverdienste laufen läßt, ist einfach nur selber schuld!

Hier nochmals als Link:


Der Aufbau wäre wie folgt:

Mac Mini
+
Pegasus R6 mit Raid 6 (System des Mac Mini auf einer Partition beim Pegasus)

Angeschlossen an Switch mit Ethernet und TB-Ethernet Adapter (mit Bonding)

Backups auf bestehendes Synology Raid (inkrementiell)
– Dieses Backup wird dann von der Synology täglich gespiegelt und noch auf 2 externe Synology Raid gebackupt. Eines davon ist immer im Safe für 1 Woche. Alle Synology sind Raid 5.

Bezüglich Pegasus Raid:

Pegasus2 R6


oder
Pegasus R6


Ich denke das normale R6 würde reichen. Da unser Netzwerk dann der Flaschenhals sein wird.

Ich persönlich hab mich fürs Pegasus2 entschieden, der Preisunterschied ist nicht so groß und wer weiss vielleicht braucht man die Geschwindigkeit ja mal….

Zu der Performance (und warum Blackmagic-Dings und AJA-System-Bums keine vernünftigen Performance-Meßwerkzeuge sind abseits Video-Spezialkram) hat Promise selbst was in der Knowledge-Base veröffentlicht:

http://kb.promise.com/KnowledgebaseArticle10394.aspx

Die gute Nachricht: Auch der RAID-Controller der Pegasus2 saturiert eine TB1-Strecke locker bzw. macht TB2 bereits "nötig" (1340-1350 MB/s). Die schlechte: Das ist bei einem Fileserver komplett egal.

Viel spannender ist jedoch, dass die im Promise verbauten TB-Controller dann eben auch TB2 können, d.h. man mit dem RAID einfach flexibler ist, wenn man mehrere Storage-Devices hintereinander schalten sollte.

@jensche: Die Preise Deines CH-Händlers erscheinen mir etwas happig. Schon mal verglichen?

Ja. ich habe noch nicht verglichen. werden den besten Preis raussuchen. die Links waren einfach der schnellste Weg.

Pegasus2 oder normal?

ich werde dann mal eine Einkaufsliste posten. bin gespannt was ihr meint.
Zur Zeit lese ich mich gerade ein in die Server Konfiguration des OS X Server.

Was meint ihr zum Setup?

Die Synology Hardware unten Links ist die jetzige NAS Umgebung, welche wir als Backup komplett weiternutzen könnten.

Hmm also wenn ich mal überlege was ich bisher hier gelernt habe… wie wäre es dann anstatt des MacMini mit einem "alten" MacPro? Leistung reicht, kannst SSD oder normale Platten schnell ein und aus bauen und hat ECC RAM (ist wichtig wie ich gelernt habe) nur bei TB siehst dann schlecht aus, das muss ich zugeben.

ja. im Mac Server Thread habe ich das auch gelesen. Jedoch ein alter Mac Pro mit TB kostet locker das doppelte vom neuen Mac Mini. Und das dieser ja CPU mässig kaum ausgenutzt wird, sollte der Mini mehr als Locker reichen.

Zudem ja die internen Platten nicht genutzt würden. Das System sowie die Daten werden komplett auf dem Pegasus Raid liegen.

Einzig der ECC RAM ist nicht im Mac Mini.


Noch was anderes: Wie habt ihr den Server Konfiguriert? wir haben durchwegs Mavericks im Einsatz. Apple setzt ja auf SMB2. Soll/kann AFP auf dem Mac Server ausgeschaltet werden?

Ich habe gelernt.. .so lange es irgendwie geht auf AFP bleiben…
Ich persönlich habe hier auf einem Rechner 10.9.1 installiert habe aber als Server noch 10.6.8 und es läuft bisher unter SMB… bei dieser Konfiguration konnte ich vom Client nichts auf dem Server machen nur sehen was drauf ist mehr nicht. Mit 10.8.5 als Client läuft alles prima.. Ich werde als nächstes versuchen 10.9. Server mit 10.9. Client, da werd ich aber vor dem Wochenende sicher nicht dazu kommen.

Ein aktueller Core i5 mit 2 Kernen (und Hyperthreading, wie's bei Apple ja standardmäßig aktiviert ist), verseilt einen originalen MacPro1,1 da, worauf's bei "Server" ankommt -- Integer-Leistung und Speicherdurchsatz -- locker: https://s1.hoffart.de/7zip-bench/

Und ein höher getakteter Quad-Core i7 dreht Kreise um ältliche MacPros, sofern man die nicht unters Messer legt (). Ist aber alles weitestegehend egal

Wieso denn? Ein MacPro ist doch kein Mini? Der MacPro hat ohne Basteleien Platz für 4 SATA-Platten, mit Basteleien Platz für 6-8, SSDs kann man auch noch reinstopfen, an den ganzen Kram kommt man im laufenden Betrieb dran, RAID-Controller gibt es für kleines Geld (ich würde zu kleinen Arecas greifen aber auch nur, weil wir mit denen Erfahrung haben und die sich egal ob unter Solaris, Linux oder eben auch OS X identisch "anfühlen", d.h. mit dem selben CLI gewartet als auch überwacht werden können), usw. usf.

MacPro = komplett andere Ausgangsbedingungen als Mini.

Und Scusa, dass das alles nur weiter verwirrt. Aber das kann hier keine zielgerichtete Beratung sein, alleine schon, weil man das nur seriös machen kann, wenn man die ganze Aufgabenstellung von genau der anderen Seite her aufzäumt, d.h. die ganze konkrete Technik erstmal beiseite läßt, sich überlegt, was da eigentlich mit den Daten passieren soll, wie schnell man auf die in welcher Situation ("Server" fällt aus, Firma brennt ab, etc.) zugreifen können soll, etc. pp. -- und ganz am Ende des Prozesses steht dann das Durchdenken konkreter technischer Lösungen.

Und damit bin ich zumindest auch raus, weil Neues gibt's vermutlich nicht mehr zu entdecken -- ich denk', im "Mac Server"-Thread ist schon alles Relevante durchgenudelt worden...

Danke.

Wir werden auf Mac Mini setzen. ist am einfachsten.
Man kann es auch übertreiben mit Technischen. Nichts gegen Eure Ausführungen. Das ist sehr interessant.

ich werde dan berichten wie es läuft.

Einfach hin oder her, Technik hin oder her… ich bin kein Experte aber das mit dem ECC leuchtet mir schon ein… über alles andere kann man diskutieren...

Schade… ich hab bisher schon so viel gelernt...

ich auch.

Bezüglich ECC: Zur Zeit haben wir über 5 Filemaker Server bei Kunden im Einsatz.
Alle Filemaker Server laufen ohne Probleme und haben auch keine ECC RAM drin.
Dies schon über Jahre. wir hatten nie Probleme. ((auch mit internen Festplatten))