Push-Nachrichten von MacTechNews.de
Würden Sie gerne aktuelle Nachrichten aus der Apple-Welt direkt über Push-Nachrichten erhalten?
Forum>Hardware>Mac Server?

Mac Server?

MikeMuc13.01.1412:17
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
0

Kommentare

Thomas Kaiser
Thomas Kaiser27.01.1420:29
DonQ
http://www.dooyoo.de/speicherkarten/apple-mac-pro-raid-card/

Brilliante Idee, die Kombination aus teuer, lahm und nicht mehr supported zu wählen. Wann kam für Apples RAID-Karte denn das letzten Firmware-Update (huch, schon 5 Jahre her?!). Wenn man sich ein proprietäres RAID ans Bein binden will (mit anderen Worten: abhängig vom Funktionieren des Controllers), dann würde ich bei einem MacPro ja eher zu sowas raten: Areca ARC-1214-4i http://geizhals.at/de/areca-arc-1214-4i-a1014008.html

Und dann bitte "Sparen um jeden Preis" und nur RAID-5 anstatt RAID-6 und in jedem Fall auf ARC-6120BA-T121 (BBU) verzichten. Und schon ist das ganze eine astreine Themaverfehlung
0
Cyco
Cyco27.01.1420:34
Du vergisst eins Thomas: Geiz ist geil
0
Thomas Kaiser
Thomas Kaiser27.01.1420:34
techie
Carbon Copy Cloner kann auch auf Netzwerkvolumes sichern, ob das dann Images sein müssen oder ob die Sicherungen bootbar sind wäre auszuprobieren.

Hmm... Carbon Copy Cloner kann, da er auf rsync aufsetzt, was völlig anderes. Aber das meinst Du vermutlich? Rsync kann quer durchs Netzwerk auf an anderen Rechnern lokal angeschlossene Platten direkt syncen.

Also weder Netzwerkvolume (das beinhaltet auch "Netzwerk-Protokoll" bspw. AFP), noch Image respektive SparseBundle sondern direkt dort auf dem anderen Rechner auf HFS+. Und davon kann dann auch lokal gebootet werden (aber nicht übers Netz, dafür muß man das "System Image Utility" bemühen, hat am Ende Images, die bisserl präpariert sind und von denen man dann auch übers Netzwerk booten kann).
0
DonQ
DonQ27.01.1420:52
Thomas Kaiser
DonQ
Edit: Hotplugable Raid Karte auf die schnelle…btw. mir wird grad schlecht weil die Suche spackt

Brilliante Idee

Gell, ich kann schon gut zitieren

dsp-memory.de mal schauen, um die 300 war wirklich der Üblichere Raid Karten Preis in "aktuell"

wobei,
war das nicht sogar ein Raid Kontrollor im Mac Pro ?!

Müsste ich mal in Zuverlässigeren Quellen recherchieren/nachfragen

DSP hat aber was in Extern und FW800: Hotswap für 300

http://www.dsp-memory.de/v1/catalog/product_info.php?cPath=9010&products_id=10552&

http://www.inxtron.com/multi-bay-raid-enclosures/hydra-super-s-lcm

afair

wurden einfach ein Mini Server+Ersatzgerät und externe Platten für Backup mit ner Flitzi Box für so kleine "Gewerbe" und einem Budget weit unter 10.000,-- verkauft, eben für 1,5-2 tausend
„an apple a day, keeps the rats away…“
0
Thomas Kaiser
Thomas Kaiser27.01.1421:19
DonQ
war das nicht sogar ein Raid Kontrollor im Mac Pro ?!

Nein. Der MacPro nutzt einfach die SATA-Ports der South Bridge der Intel-Chipsätze. Zum Anschluß der HDs hat's den üblichen Mini-SAS-Connector auf dem Mainboard (SFF-8087) und ein Breakout-Kabel zu den 4-SATA-Ports der Backplane. Da das Kabel verdammt kurz ist, braucht's dann beim Einsatz eines Hardware-RAID-Controllers wie besagtem Areca 'ne Verlängerung, bspw.:

Wenn man nun im Hinterkopf behält, dass RAID-5 (bzw. einfache Redundanz) bei heutigen Plattengrößen einfach nur doof ist, der MacPro nur 4 Platteneinschübe hat und man demzufolge mit Bordmitteln (Software-RAID-10 über 4 Platten) am Ende im Prinzip das selbe hat wie mit einer teuren und proprietären Lösung, deren Controller auch nur wieder ein zusätzlicher Single-Point-of-Failure ist (Hardware-RAID-6 über 4 Platten), dann kriegt man evtl. einen kleinen Eindruck davon, was dieses Hardware-RAID-Gehampel eigentlich für Blödsinn ist.

Was anderes wäre es, wenn man mehr als 4 Platten in einen MacPro stopft (siehe http://www.maxupgrades.com/istore/index.cfm?fuseaction=product.display&product_id=158 ). Nur in welchen Situationen braucht man das, grad wenn die Schüssel eh nur Dateiserver spielen soll? Natürlich keine ernstgemeinte Frage, denn RAID auf Stammtisch-Niveau interessiert mich eh nicht
0
DonQ
DonQ28.01.1400:04
Thomas Kaiser
[Nur in welchen Situationen braucht man das, grad wenn die Schüssel eh nur Dateiserver spielen soll? Natürlich keine ernstgemeinte Frage, denn RAID auf Stammtisch-Niveau interessiert mich eh nicht

Tja, X-San wurde afair schon recht lange verschoben und eingestellt…praktisch 2011 hierzulande, wenn man so will…paar Sächelchen scheint es aber noch zu geben…im US Store.

Allerdings scheinbar das allerletzte Update 2012



Na wie auch immer…vielleicht kommt ja mal wieder was, wenn apple sich mal auf seine eigentlichen Kernkompetenzen konzentrieren darf…wobei ich gerade nicht mal sagen könnte ob der Zug hier schon lange abgefahren und das Gleis vermodert oder nur verstekct ist,
mir war so das es eigentlich ausgelagert worden wäre, weil deutlich zu Nische/Unrentabel, verglichen mit den Phones, wo praktisch jeder Kunde über 500 $ in die Kasse gespült hat
*MundZu*
„an apple a day, keeps the rats away…“
0
DonQ
DonQ28.01.1400:14
Mal Spaße und Aktualisierungshalber minimal im Store gewühlt de,
das war alles was ich noch auf die schnelle zu "zuverlässig(er), groß und schnell" gefunden habe
„an apple a day, keeps the rats away…“
0
ghost
ghost28.01.1400:32
Hat hier zufällig noch jemand die Kombination aus 10.9.1 Client und 10.6.8. Server am laufen?

So wie ich das ganze hier bisher gelesen und eventuell auch ansatzweise ein wenig verstanden habe (bin kein Techniker) gibt es keine "einfache" Lösung, entweder es ist bisher nur Misst produziert worden oder es kommt eine Lösung heraus bei der eine kleine Firma besser gleich den Insolvenzantrag stellt. Ich denke hier gibt es genügend echte Experten um herausfinden zu können welche Lösung aktuell für einen bezahlbaren Preis "gut" ist. Vor allem auch eine Lösung bei der man nicht gleich dem Service Techniker ein eigens Büro einrichten muss.
Windows Server? Welche Version? Irgend was mit Linux? Von den aktuellen Mac Server Versionen liest man ja nicht viel gutes.
Bisher habe ich einen XServe mit XServe Raid, läuft mit 10.6.8. Server, Fileserver, DHCP, DNS, mehr nicht. Backup über LAN in ein anderes Gebäude auf ein NAS. Regelmäßig werden auch alle Daten auf wechselnde Festplatten kopiert und landen im Tresor. Gemischtes Netzwerk mit Mac OS und Windows 7 Rechnern, bisher läuft alles, sicherlich nicht optimal sicher nicht mit maximaler Geschwindigkeit oder sonstigem. So früher oder später ist die bisherige Lösung am Ende und dann? Was empfehlen die Experten hier als brauchbaren Nachfolger?
„Der Tag hat 24 Stunden und wenn das nicht reicht nehmen wir eben die Nacht dazu..."“
0
Thomas Kaiser
Thomas Kaiser28.01.1401:09
ghost
Ich denke hier gibt es genügend echte Experten um herausfinden zu können welche Lösung aktuell für einen bezahlbaren Preis "gut" ist. Vor allem auch eine Lösung bei der man nicht gleich dem Service Techniker ein eigens Büro einrichten muss.

Damit bist Du eigentlich wieder bei der Ausgangsfrage des Threads gelandet. Die man halt kaum seriös beantworten kann, wenn man nicht noch paar mehr weitere Randbedingungen kennt, bspw.:

- welche Datenmengen sollen vorgehalten werden?
- Anzahl der Clients, die drauf zugreifen sollen?
- werden Komfort-Features wie Spotlight-Suche (also auch in Dateiinhalten) benötigt bzw. genutzt?
- wie hoch sind die Anforderungen an Verfügbarkeit (wohl nicht besonders, wenn Du bislang mit einem Stück xServe und einem xServe-RAID am Start warst?)

Wenn man ausgemusterte olle MacPro herumstehen hat (oder sie für den Zweck ausmustert), dann kann man mit 2 dieser Kisten, paar neuen SATA-Platten, RAID-10 in Software und vernünftigem Datensicherheits- und Verfügbarkeitskonzept (inkl. Notfallpläne) sicherlich ein kleines heterogenes Netz mit OS X (Server) und bis zu 11 TByte netto "gut genug" versorgen:

http://geizhals.at/de/?cat=hde7s&xf=958_4000~1654_geeignet+f%FCr+Dauerbetrieb&sort=r

Aber ohne die Randbedingungen zu kennen, kann keine vernünftige und für Deine Situation passende Aussage getroffen werden
0
ghost
ghost28.01.1401:39
Die aktuelle Datenmenge wäre 3 TB, es sind insgesamt 8 Clients die aber selten gleichzeitig viele Daten ziehen. Spotlight-Suche wird nicht unbedingt benötigt.
Wie hoch sind die Anforderungen an die Verfügbarkeit… nun ja die Firma stirbt nicht wenn es mal zu einem Ausfall von einem Tag kommt. Bisher hatte ich seit ich mit dem Mac arbeite 3 echte Ausfälle, die mich etwas Zeit gekostet haben. Ich konnte aber zumindest innerhalb von einer Stunde wieder arbeiten, nicht perfekt aber es lief dann wieder. Wenn "das Netz" ausfällt ist es wie mit jeder anderen Maschine hier auch…. und ich hab keine andere Maschine doppelt hier nur weil sie mal ausfallen könnte. Mir sind meine Daten wichtig, wenn ich mal einen Ausfall habe überlebe ich das, so lange es meine Daten überleben und die leben bisher immer noch. Die Xserve, XRaid Kombination läuft übrigens seit 2009 ohne Ausfall… ich finde das ist als Verfügbarkeit für mich in Ordnung.

Olle MacPro wären nicht das Problem, aber welche Systemsoftware soll da drauf? OS X Server 10.9.1? Bisher habe ich da wie schon gesagt nicht viel gutes gelesen, vor allem wenn noch Windows Maschinen mit an Bord sind.

Bitte verstehe mich nicht falsch, ich suche nicht nach der möglichst billigen Lösung sondern nach eine zuverlässigen bezahlbaren, also sagen wir mal bis 5000 oder 6000 Euro, es gibt immer was besseres, größeres, schnelleres etc. das ist mir schon klar, aber ich denke für dieses Geld müsste es doch schon was "akzeptables" geben oder?
„Der Tag hat 24 Stunden und wenn das nicht reicht nehmen wir eben die Nacht dazu..."“
0
gfhfkgfhfk28.01.1407:52
DonQ
Na wie auch immer…vielleicht kommt ja mal wieder was, wenn apple sich mal auf seine eigentlichen Kernkompetenzen konzentrieren darf…wobei ich gerade nicht mal sagen könnte ob der Zug hier schon lange abgefahren und das Gleis vermodert oder nur verstekct ist, …
Rund um das Thema neuer MacPro ist die generelle Produktpolitik von Apple diskutiert worden. Die Mehrheitsmeinung auch hier im Forum war, daß Apple weiterhin Produkte für Pros anbieten würde. Dem steht gegenüber, daß der xServer 2009 der letzte richtige Server von Apple war. Da Apple grundsätzlich keinerlei Aussagen über die Produktpolitik trifft, und somit auch keinerlei Vorplanungen erlaubt, muß ein jeder selbst entscheiden wie sehr er daran glaubt, daß Apple weiterhin und in welcher Form Pros unterstützt.

Meiner Einschätzung nach ist das Thema Serverhardware bei Apple durch, und wird auf absehbare Zeit nicht mehr auf der Agenda stehen. Da man bei Apple aber gerne einen Zickzackkurs fährt, kann sich das auch kurzfristig ändern. Nur ist das keine Basis auf der man die IT einer Firma gründen sollte.
0
Thomas Kaiser
Thomas Kaiser28.01.1408:25
ghost
Die aktuelle Datenmenge wäre 3 TB, es sind insgesamt 8 Clients die aber selten gleichzeitig viele Daten ziehen. Spotlight-Suche wird nicht unbedingt benötigt.

Wenn Du Spotlight-Suche völlig ausschließen kannst, dann bist Du jetzt plötzlich wieder im Bereich "NAS als Kiste". Zwei Kisten hinstellen, die irgendeine Form von Datenreplizierung können, sich irgendwie mit einer Backup-Lösung verheiraten lassen und erwiesenermaßen und zuverlässig cross-platform funktionieren (das ist wichtig, wenn parallel zu den Macs auch Windows zugreifen soll). Nur: So ganz einfach ist das nicht. Wir machen viel in dem Bereich heterogenes Netzwerken, und das war und ist immer eine Herausforderung gewesen, das wirklich vollumfänglich hinzubekommen, wenn OS X und Windows gleichberechtigt auf identischen Datenbestand zugreifen sollen.

Man muß auch neidlos anerkennen, dass an der Stelle Apple grad am Weitesten ist, was problemlosen Zugriff von Mac- und Windows-Clients auf identischen Server, in dem Fall "OS X als NAS" angeht (NAS ist ja in erster Linie Bezeichnung für ein Konzept und nicht für eine Gerätekategorie). Die Probleme sind dabei vielschichtig, denn es geht um Encoding (ganz allgemein, Sonderzeichen im Speziellen und "böse Zeichen" -- Windows mag da einige Zeichen nicht und Apple löst das mit dem in OS X verbauten SMB-Server ziemlich elegant), um Locking, um Speicherung von Mac-spezifischen Sachen (Finder-Metadaten, EAs, Ressource Forks) und Windows-Spezialitäten (sog. named forks).

Das Doofe bzgl. einer Mac-Lösung ist: Hardwareauswahl mau: der Mini wäre von den Ressourcen her ausreichend, hat aber kein ECC-RAM, ein neuer MacPro für den Zweck ist irgendwie Verschwendung pur. Blieben ältere MacPro, die mit ECC und bisserl interner Erweiterbarkeit punkten könnten. Aber eben: OS X Server -- will man evtl. auch nicht?

Ich hab da null Erfahrung bzgl. der Tauglichkeit (sowohl was Features als auch Stabilität/Robustheit angeht), da wir keinen einzigen Kunden haben, der OS X Server als produktiven Fileserver einsetzt (wenn dann als Sync-Ziel, und in dem einen Fall, wo ein Kunde auf einen Mini als produktiven Server setzt, kommen nicht Apples Dienste zum Einsatz sondern Helios). Dass man schon "viel Schlechtes" gehört hat, juckt mich jetzt nicht sonderlich, weil Hörensagen ist per se ein schlechter Ratgeber. Wenn sowas allerdings fundiert von Koryphäen wie bspw. Marcel Bresink geäußert wird, dann ist das was anderes.

Man könnte das Ganze auf grundsolider Hardware-Basis in günstiger/schneller auf echtem Server-Blech mit Linux, FreeBSD oder Solaris aufsetzen. Hat dann aber immer noch das Problem mit der Interoperabilität zwischen Mac- und Windows-Clients, wenn man auf OpenSource-Komponenten (Netatalk und Samba) setzt. In dem Bereich wird sich 2014 was tun. Wenn Du Zeit hast, könnte sich das Warten lohnen. Apple erzählt grad aller Welt, die Zukunft wäre SMB -- aber außer Apples eigenem SMB2-fähigen Filesharing-Diensten kann noch kein anderer SMB-Server mit den ganzen Apple-Spezialitäten umgehen. Das wird sich aber kurzfristig ändern: http://www.netafp.com/sernet-expands-apple-support-netatalk-and-samba-merge-1230/

Eine weitere Alternative für cross-platform-Filesharing wäre Helios. Ist aber nur für den Zweck den Meisten zu teuer. Funktioniert dafür rock-solid, wenn Hardware und OS drunter passend gewählt sind. Aber... Kontrollverlust bzw. die Angst davor. Ein Helios-Server läuft auch so einfach jahrelang durch, kommt mit GUI für Administration von Mac oder Windows aus und kann auch von wenig technikaffinen Usern per Maus administriert werden. Aber bei vielen Mac-zentrischen Anwendern bleibt die Angst, das System nicht wirklich beherrschen zu können (das trifft genau genommen auch auf OS X und Windows zu -- aber da bilden es sich die Leute halt einfach ein. Und letztlich entscheidet dieses wohlige Bauchgefühl dann). Die Psycho-Komponente eben, die man nicht unterschätzen sollte.
0
Austro-Diesel28.01.1418:52
Ich muss schon anmerken: Sehr analytisch erfasst und für mich als User mehrerer Serverplattformen über die Jahre äußerst nachvollziehbar!

Das Server-OS, um das es mir am meisten leid tut, ist Windows 2000 mit NTFS. Ich muss sagen, der Krempel hat mich nie im Stich gelassen, auch bei Plattenausfällen nicht, es ist Hardware in Hülle und Fülle und für den Anspruch zu bekommen und alles bleibt mit GUI einigermaßen gut administrierbar. Und nebenbei war NTFS damals das einzige Dateisystem, das gut mit den Apple-Spezialitäten Dateinamen, Pfadlängen und Ressource-Forks gut bis sogar hervorragend umgehen konnte!

Schade, dass Microsoft den AFP-Support vor inzwischen vielen Jahren eingestellt hat. Wenn man mal die Grundinstallation überstanden hatte (RAID-Controller-Treiber einbinden, Netzwerkadaptertreiber einbinden), dann war das kein schlechtes OS für einen stabilen und schnellen wie unkomplizierten Mac-Server.


Mit Linux bieten sich gute und günstige Alternativen, allerdings ist hier schon ein bisserl mehr Know-how erforderlich, bis die Kiste richtig konfiguriert und die Raid-Verbände eingerichtet sind. Mangels Zugriff auf einen willigen, leidensfähigen oder schon schlauen Techniker fällt diese Option für mich raus. Die schlechte Koordination zwischen AFP- und SMB-Clients wäre für mich zumindest kein Thema.

Helios & Co schon wegen der aufgerufenen Zahlen.

Also bleibt mein Modell "die Bastelbude". Muss halt schauen, dass ich für mich das Beste draus mache und keinen Kardinalfehler einbaue. Hierbei sind mit Thomas Kaisers sehr kritische, aber durchaus begründete Kommentare recht hilfreich, auch wenn ich alle seine Bedenken (noch?) nicht teile.
0
Thomas Kaiser
Thomas Kaiser28.01.1419:13
Austro-Diesel
Schade, dass Microsoft den AFP-Support vor inzwischen vielen Jahren eingestellt hat.

Da sind MacServer IP und ExtremeZ-IP in die Bresche gesprungen. Waren meines Erachtens seit OS X sowieso Pflicht, wenn man Windows als Server für Macs einsetzen wollte, weil Microsofts Services for Macintosh im Prinzip seit NT 4.0 (oder gar 3.5?) nicht mehr weiterentwickelt worden sind.
Austro-Diesel
Wenn man mal die Grundinstallation überstanden hatte (RAID-Controller-Treiber einbinden, Netzwerkadaptertreiber einbinden), dann war das kein schlechtes OS für einen stabilen und schnellen wie unkomplizierten Mac-Server.

Naja, das hängt wohl vom individuellen Erfahrungshorizont ab (also letztlich "Ahnung von Windows" oder nicht). Ich hab früher bevor ich auf unixoide Mac-Server geschwenkt bin, auch immer NT-basierte Server bevorzugt (v.a. zu Zeiten des klassischen AppleShare, das ja wirklich im Vergleich zu NT 3.x ein ganz schlechter Witz war). Aber diese Rebooterei in Zusammenhang mit dem Einspielen von Treibern... was war die nervtötend. Wir mussten damals wegen "zertifizierte Hardware" und so 'ne Zeit auf Data General Kisten setzen. Bis deren Grundeinrichtung stand, vergingen über 2 Stunden und gefühlte 50 Reboots
0
Austro-Diesel28.01.1420:52
AppleShare auf Mac OS 7 ... *lol* ... das waren noch Zeiten! Viel Geld und wenig Leistung! Mac IIci und Backup mit Retrospect auf 650 MB große magneto-optische Discs ...

Dann NT 3.51 und NT 4, schließlich 2000 ... das schnurrte ganz gut. MacServer IP hab ich dann damals zu Zeiten des MacOS 9 ausprobiert, brachte keinen klaren Vorteil.

Mit Mac OS X kam dann Netatalk 2.0 auf Linux ins Haus ... läuft noch immer hervorragend.

Aber ich bin es leid, mir immer von meinem Linux-Techniker (= Bruder) erklären zu lassen, dass das, was ich will, nicht geht, nicht gescheit ist, zwei kreuzweise gesicherte Server nur kompliziert sind, dass schnelle Harddisks dumm sind, dass man besser mit einem Server fährt und dass Raid 5 immer besser als Raid 1 ist -- oder sonst irgendwas.

Und permanent der Quatsch mit "nimm SMB unter Suse 12, das klappt wunderbar" ... so ein Müll, das hab ich 10 Minuten ausprobiert und bin fertig damit.

Der Kerl hat's gut, er muss ja dann nicht arbeiten damit, dem ist es wurscht, wenn 10.000 Dateiverknüpfungen vom Layoutprogramm zu den Bildern nicht mehr passen oder wenn die Kisten streiken niemand vor Ort verfügbar ist, der das kurzfristig "flicken" kann.
0
Thomas Kaiser
Thomas Kaiser28.01.1421:16
Austro-Diesel
Mit Mac OS X kam dann Netatalk 2.0 auf Linux ins Haus ... läuft noch immer hervorragend.

Lustig, grad mal gestöbert... das ist ja tatsächlich schon 10 Jahre her, dass wir auf der Zielgeraden mit Netatalk 2.0 waren. War 'ne spannende Zeit... aber ich bin dann mehr oder weniger relativ bald danach aus der aktiven Netatalk-Entwicklung ausgestiegen. Und umso froher, dass das Projekt heute bei den NetAFP-Jungs in guten Händen ist.

Ich würde Dir aber dringendst raten, upzudaten, denn Netatalk 2.0 ist uralt...
Austro-Diesel
Und permanent der Quatsch mit "nimm SMB unter Suse 12, das klappt wunderbar" ... so ein Müll, das hab ich 10 Minuten ausprobiert und bin fertig damit.

Naja, auch das wird sich noch ändern in den nächsten Jahren und der ganze Apple-Kram in jeder Situation sauber über SMB funktionieren (wenn man den richtigen SMB-Server wählt -- grad da bin ich mal sehr gespannt, wie sich das unter Windows mit ExtremeZ-IP weiterentwickeln wird)
0
ghost
ghost28.01.1422:23
Hmm noch mal ne Frage an Leute die sich auskennen, kann es sein das sich das aktuelle in 10.9.1. verwende SMB 2 oder 3 oder was auch immer nicht mit dem ursprünglichen SMB von 10.6.8. Server verträgt?
„Der Tag hat 24 Stunden und wenn das nicht reicht nehmen wir eben die Nacht dazu..."“
0
ghost
ghost28.01.1422:34
Thomas Kaiser
ghost
Die aktuelle Datenmenge wäre 3 TB, es sind insgesamt 8 Clients die aber selten gleichzeitig viele Daten ziehen. Spotlight-Suche wird nicht unbedingt benötigt.



Man könnte das Ganze auf grundsolider Hardware-Basis in günstiger/schneller auf echtem Server-Blech mit Linux, FreeBSD oder Solaris aufsetzen. Hat dann aber immer noch das Problem mit der Interoperabilität zwischen Mac- und Windows-Clients, wenn man auf OpenSource-Komponenten (Netatalk und Samba) setzt. In dem Bereich wird sich 2014 was tun. Wenn Du Zeit hast, könnte sich das Warten lohnen. Apple erzählt grad aller Welt, die Zukunft wäre SMB -- aber außer Apples eigenem SMB2-fähigen Filesharing-Diensten kann noch kein anderer SMB-Server mit den ganzen Apple-Spezialitäten umgehen. Das wird sich aber kurzfristig ändern: http://www.netafp.com/sernet-expands-apple-support-netatalk-and-samba-merge-1230/

Also wenn ich dich richtig verstehe dann abwarten und Tee trinken?
„Der Tag hat 24 Stunden und wenn das nicht reicht nehmen wir eben die Nacht dazu..."“
0
Thomas Kaiser
Thomas Kaiser28.01.1423:07
ghost
Hmm noch mal ne Frage an Leute die sich auskennen, kann es sein das sich das aktuelle in 10.9.1. verwende SMB 2 oder 3 oder was auch immer nicht mit dem ursprünglichen SMB von 10.6.8. Server verträgt?

Darf ich fragen, warum Du fragst?

Hintergrund: Als ich gehört habe, dass Apple mit 10.9 "SMB für alle" allen Ernstes propagiert, ist mir erstmal schlecht geworden angesichts der ganzen Probleme, die entstehen können, wenn OS X auf eine andere Kiste (wurscht ob OS X Client oder irgendeine Form von Server) abwechselnd mit AFP und SMB zugreift. Außer... das Zielsystem, d.h. der SMB-Server, ist der von OS X 10.8 (SMB 1) oder 10.9 (SMB 2).

Die Problematiken, in die man rennt, haben dabei weniger mit der Protokollversion zu tun als vielmehr damit, wie Apple OS X Eigenheiten per SMB kaschiert (bzw. die Semantiken an AFP annähert). Als ein simples Beispiel: Wenn Du vom Mac aus einen Ordner auf einem Server anlegst und dem Namen des Ordners am Ende ein Leerzeichen verpaßt (oder eines der "bösen" Zeichen /, |, \, etc. -- Details siehe im ersten Link unten), dann wird ein Windows-Client beim Versuch, auf diesen Ordner zuzugreifen, scheitern. Einfach weil gewisse Zeichen (manchmal auch nur an gewissen Stellen im Namen) unter Windows verboten sind.

Apple löst das in ihrer SMB-Server-Implementierung so, dass sie das fragliche Leerzeichen in die sog. "UTF-8 private range" ausblenden. Folge: Windows kotzt nicht sondern sieht am Verzeichnisnamenende ein Leerzeichen, das gar keines ist. Und ab 10.8 hat der Applesche SMB-Server noch einen ganzen bunten Strauß weiterer Vorkehrungen an Bord, um die Koexistenz von AFP und SMB beim Zugriff auf identischen Datenbestand zu gewährleisten. Vor 10.8 hat sich Apples SMB-Server aber teils deutlich anders verhalten und man hat sich in so einer Situation alleine schon durch den wechselweisen Zugriff von Mac-Clients mal per AFP und mal per SMB Probleme schaffen können. Und das dürfte auf Dein Setup mit 10.6 Server zutreffen.

Die häßlichen Details kannst Du hier halbwegs komplett nachlesen bei Interesse:

https://groups.google.com/forum/#!searchin/de.comp.sys.mac.misc/Synology$20-$20AFP$20vs.$20SMB

Und wie schon geschrieben: Hat nichts mit SMB1 vs. SMB2 zu tun (da passieren die spannenden Sachen an anderen Stellen, v.a. Performance, wo SMB2 tatsächlich massiv punkten kann) sondern mit der Art, wie SMB- und AppleFileServer in OS X mit so Kram wie Encodings, verbotenen Zeichen, dem Speichern von Finder-Metadaten und Extended Attributes, named forks von Windows, usw. usf. umgehen.

In Kurzform: Wo's geht Stand jetzt SMB-Zugriffe vermeiden und überhaupt erst einsetzen, wenn die Gegenstelle ein OS X 10.9 (oder höher) ist.

Zwengs Abwarten und Tee trinken. Ja, würde ich tatsächlich, weil die Transition von AFP zu SMB ein paar Wellen schlagen wird und man im Laufe des Jahres klarer sehen wird, wer was wie weit von den ganzen Apple-proprietären Anbauten an SMB unterstützen wird...
0
ghost
ghost28.01.1423:18
Thomas Kaiser
ghost
Hmm noch mal ne Frage an Leute die sich auskennen, kann es sein das sich das aktuelle in 10.9.1. verwende SMB 2 oder 3 oder was auch immer nicht mit dem ursprünglichen SMB von 10.6.8. Server verträgt?

Darf ich fragen, warum Du fragst?

Naja ich frage weil ich auf einem Rechner 10.9.1 installiert habe und danach konnte ich auf den 10.6.8 Server nicht so so zugreifen wie gewohnt, also Login und so ging konnte aber nichts lesen und schreiben, selbst auf eine Freigabe bei der alle alles dürfen ging nichts, unter 10.8.5 ging alles.

SMB Zugriffe vermeiden? Ja hätte ich gerne aber eine Maschine die hier auf einem Windows Rechner läuft mag die Daten nur über SMB, läuft der Mac über AFP dann findet die Windows Maschine irgendwie die Daten nicht, frag mich nicht warum das so ist, hier waren schon die Entwickler der Software und haben sich die Zähne daran ausgebissen das ich hier meinen Mac Server weiter betreiben wollte… die hassen Mac.. mir gehts mit Windows so
„Der Tag hat 24 Stunden und wenn das nicht reicht nehmen wir eben die Nacht dazu..."“
0
Thomas Kaiser
Thomas Kaiser28.01.1423:27
ghost
Naja ich frage weil ich auf einem Rechner 10.9.1 installiert habe und danach konnte ich auf den 10.6.8 Server nicht so so zugreifen wie gewohnt, also Login und so ging konnte aber nichts lesen und schreiben, selbst auf eine Freigabe bei der alle alles dürfen ging nichts, unter 10.8.5 ging alles.

Ok, völlig andere Symptome und nicht klar genug formuliert von mir vorhin: Warum nutzt Du ausgerechnet SMB zwischen dem 10.9-Mac und dem 10.6-Server? Warum nicht AFP?

BTW: Wenn Du im Finder bei -k kein Präfix eingibst, dann probiert der 10.9-Client erst SMB2, dann AFP, dann SMB1 (und was zuerst zu klappen scheint, wird genommen). Wenn Du smb:// eingibst, probiert er auf Teufel raus SMB2, wenn Du hingegen mit cifs:// werkelst, dann wird's eine SMB1-Verbindung. Am Besten aber: afp://
ghost
SMB Zugriffe vermeiden?

Zwischen OS X und OS X.
ghost
Ja hätte ich gerne aber eine Maschine die hier auf einem Windows Rechner läuft mag die Daten nur über SMB, läuft der Mac über AFP dann findet die Windows Maschine irgendwie die Daten nicht

Versteh ich jetzt nicht aber macht auch nix. Mir ging's vorhin nur um Zugriff von Mac auf Mac. Und da sollte man tunlichst nach wie vor SMB im Zweifel meiden. So als Faustregel. Die diversen Gründe dafür könnten in epischer Breite im vorher geposteten Link nachgelesen werden...
0
Cyco
Cyco28.01.1423:31
Das eigentliche Problem scheint da zu liegen, dass der Windows-Rechner die Daten nicht sieht die über AFP abgelegt wurden. Das ist ein Effekt den ich noch nie gesehen habe.
Kann denn der Mac über AFP die vom Windows-Rechner per SMB abgelegten Daten sehen und nutzen?

Fehlerhafte Zugriffsrechte unter 10.8-Server kenne ich, da muss man Fummeln um den Heterogenen Zugriff in den Griff zu kriegen.
0
ghost
ghost28.01.1423:50
Thomas Kaiser
ghost
Ja hätte ich gerne aber eine Maschine die hier auf einem Windows Rechner läuft mag die Daten nur über SMB, läuft der Mac über AFP dann findet die Windows Maschine irgendwie die Daten nicht

Versteh ich jetzt nicht aber macht auch nix. Mir ging's vorhin nur um Zugriff von Mac auf Mac. Und da sollte man tunlichst nach wie vor SMB im Zweifel meiden. So als Faustregel. Die diversen Gründe dafür könnten in epischer Breite im vorher geposteten Link nachgelesen werden...

Ja so hatte ich das auch eingestellt also immer schön mit AFP, aber die Software hier schick quasi an die Maschine eine art Layout Datei und das RIP holt sich die Inhaltsdaten vom Server, wenn die Inhaltsdaten aber vorher über AFP auf den Server geschickt habe dann konnte das RIP die Daten nicht finden, vermutlich weil der Pfad mit geschickt wird und der RIP Rechner den nicht verstehen konnte?!? Keine Ahnung warum genau.
„Der Tag hat 24 Stunden und wenn das nicht reicht nehmen wir eben die Nacht dazu..."“
0
ghost
ghost28.01.1423:52
Cyco
Das eigentliche Problem scheint da zu liegen, dass der Windows-Rechner die Daten nicht sieht die über AFP abgelegt wurden. Das ist ein Effekt den ich noch nie gesehen habe.
Kann denn der Mac über AFP die vom Windows-Rechner per SMB abgelegten Daten sehen und nutzen?

Fehlerhafte Zugriffsrechte unter 10.8-Server kenne ich, da muss man Fummeln um den Heterogenen Zugriff in den Griff zu kriegen.

Ja genau das ist der Effekt, es kann auch gut sein das die Software da nicht sauber programmiert ist und es nur daran liegt… ich weiss nur das ich es so machen muss sonst läuft es nicht. Mir wäre auch lieber ich könnte hier nur mit dem Mac arbeiten
„Der Tag hat 24 Stunden und wenn das nicht reicht nehmen wir eben die Nacht dazu..."“
0
Thomas Kaiser
Thomas Kaiser29.01.1400:03
ghost
Ja so hatte ich das auch eingestellt also immer schön mit AFP, aber die Software hier schick quasi an die Maschine eine art Layout Datei und das RIP holt sich die Inhaltsdaten vom Server, wenn die Inhaltsdaten aber vorher über AFP auf den Server geschickt habe dann konnte das RIP die Daten nicht finden, vermutlich weil der Pfad mit geschickt wird und der RIP Rechner den nicht verstehen konnte?!? Keine Ahnung warum genau.

Also wenn die Daten per AFP auf den Server geschubst werden, findet die RIP-Software (die unter Windows läuft und per SMB zugreift?) nix? Könnte neben ACL-Drama (siehe Cyco) evtl. auch an verbotenen Zeichen liegen. Windows stolpert über ein paar und Apple hat meines Wissens erst den SMB-Server in OS X ab 10.8 entsprechend angepaßt, dass der dann besagte böse Zeichen wegmapped, siehe:

https://groups.google.com/d/msg/de.comp.sys.mac.misc/xvcVMx8da3s/CLB2LSYUWw4J

Keine Ahnung, wie sich an der Stelle 10.6 anstellt (ob das die "bösen" Zeichen rausreicht oder unterschlägt oder gleich die Dateien per SMB unterschlägt, deren Namen derlei Zeichen enthalten).

Um das zu analysieren, wäre auf dem Server Herumgehampel in der Shell mit "ls" und "hexdump" sinnvoll. Und auf der Windows-Maschine mit 'nem Sniffer und Analyse der Pakete mittels bspw. WireShark. Sowas mach ich aber nur gegen hohes Schmerzensgeld

Im Ernst: Kannst ja mal in die Richtung forschen bzw. wenn mal wieder irgendwer zum Analysieren vorbeikommt, ihn in die Richtung stubsen, falls nicht wer anders noch die Lösung hier abkippt...
0
ghost
ghost29.01.1401:51
Thomas Kaiser
ghost
Ja so hatte ich das auch eingestellt also immer schön mit AFP, aber die Software hier schick quasi an die Maschine eine art Layout Datei und das RIP holt sich die Inhaltsdaten vom Server, wenn die Inhaltsdaten aber vorher über AFP auf den Server geschickt habe dann konnte das RIP die Daten nicht finden, vermutlich weil der Pfad mit geschickt wird und der RIP Rechner den nicht verstehen konnte?!? Keine Ahnung warum genau.

Also wenn die Daten per AFP auf den Server geschubst werden, findet die RIP-Software (die unter Windows läuft und per SMB zugreift?) nix? Könnte neben ACL-Drama (siehe Cyco) evtl. auch an verbotenen Zeichen liegen. Windows stolpert über ein paar und Apple hat meines Wissens erst den SMB-Server in OS X ab 10.8 entsprechend angepaßt, dass der dann besagte böse Zeichen wegmapped, siehe:

https://groups.google.com/d/msg/de.comp.sys.mac.misc/xvcVMx8da3s/CLB2LSYUWw4J

Keine Ahnung, wie sich an der Stelle 10.6 anstellt (ob das die "bösen" Zeichen rausreicht oder unterschlägt oder gleich die Dateien per SMB unterschlägt, deren Namen derlei Zeichen enthalten).

Um das zu analysieren, wäre auf dem Server Herumgehampel in der Shell mit "ls" und "hexdump" sinnvoll. Und auf der Windows-Maschine mit 'nem Sniffer und Analyse der Pakete mittels bspw. WireShark. Sowas mach ich aber nur gegen hohes Schmerzensgeld

Im Ernst: Kannst ja mal in die Richtung forschen bzw. wenn mal wieder irgendwer zum Analysieren vorbeikommt, ihn in die Richtung stubsen, falls nicht wer anders noch die Lösung hier abkippt...

Hmm ich glaube ich löse das mal so das ich 2 Server aufstelle, irgend so ein Windows müll (sorry) auf den kommen die Daten für die Windows Maschinen und alles andere bleibt in der Mac Umgebung. Aber erst mal heisst es wohl never change a running System Den es wird sicher wieder einiges Zeit kosten bis ich das ganze dann auch wirklich am laufen hab.

Wobei wenn Apple doch nun auch auf SMB setzt dann hat sich das ganze doch früher oder später eh wieder erledigt oder?
„Der Tag hat 24 Stunden und wenn das nicht reicht nehmen wir eben die Nacht dazu..."“
0
Austro-Diesel11.02.1416:14
Kurzer Zwischenbericht ... habe versucht, möglichst viele der guten Hinweise umzusetzen und entsprechend zusammengestellt. Den Testlauf habe ich fast abgeschlossen, bin soweit recht zufrieden. Die Konfiguration lautet derzeit:

2 idente Server-Pakete, die unterschiedliche Kundenkreise und ähnlich große Arbeitsgruppen bedienen, bestehend aus:

1 Apple Mac mini i5, 16 GB, 2x SSD 1 TB Samsung 840 EVO intern* und OS X 10.9.1 Server 3.0.2
2 NewerTech MiniStack 3.5 externe USB/FW/eSATA-Gehäuse mit Seagate 4 TB NAS-Festplatte per USB 3.0 direkt angeschlossen
1 APC Smart-UPS 750 VA mit USB-Anschluss zum Mac mini (da hängen auch der Monitor und einige Arbeitsplätze daran)

Die beiden SSDs sind als RAID 1 konfiguriert. Ich weiß, dass der Einsatz zweier identer SSDs ein gewisses Risiko gegenüber Firmwarefehlern bedeutet, aber ich kann keine solchen Erfahrungsberichte im netz finden.

Nachdem ich das Upper-Kabel vom "Glücks-Versand" (Amazon Marketplace) gegen eines von Mac-Speicher-Shop ersetzt habe funktioniert das auch einwandfrei. Jetzt kann ich den Mac mini schon in 20 Minuten auseinander- und wieder zusammenbauen ...

Die eine externe 4 TB-Platte hat eine 64 GB-Partition mit einem "Reserve-System". Der Rest ist für das Archiv-Servervolume gedacht.

Die andere externe 4TB-Platte hat eine 1-TB-Partition als Ziel für das tägliche Backup durch Carbon Copy Cloner, was ein bootfähiges Backup ergibt. Die restlichen 3 TB stehen der Time Machine lokal zur Verfügung.

Zur Sicherheit habe ich die ausgebauten 500-GB-HDs in einfache USB-3.0-2.5"-Gehäuse übersiedelt und die bleiben dort liegen -- was weiß man schon.


Installiert ist OS X 10.9.1 vom flinken USB-3.0-Stick in rund 1 Stunde, der Download der Server-App dauert rund 1/2 Stunde, konfiguriert ist das alles für 10 Accounts in einer halben Stunde. Damit sollte die maximale Zeit für die Wiederinbetriebnahme im Worst-Case bei rund 2 Stunden liegen. Damit kann ich leben.

Da Firewall, Mail-, FTP- und DHCP-Dienste weiterhin auf dem bestehenden Linux-Server verbleiben, ist nicht viel zu konfigurieren. Einzig, dass die Server eine feste IP-Adresse aus dem reservierten Adressenbereich bekommen, habe ich mir als sinnvoll gedacht.


Für einwandfreie Sherlock-Funktion muss man bei dieser Version keine User "_sherlock" oder so anlegen, der erscheint von selber.


Eine einzige Auffälligkeit, die etwas nervt ist, dass sich Schriften, einmal vom Client auf das Servervolume kopiert, nicht mehr löschen lassen. Erst wenn man den Server neu startet oder Erste Hilfe laufen lässt, verhalten sich diese Dateien wieder normal. Auch nach längerer Zeit scheint es manchmal wieder von selber mit dem Löschen zu klappen. Was es damit auf sich hat, das ist mir ein Rätsel.


Die alten OS X 10.6.8-Arbeitsplätze verbinden sich erwartungsgemäß per AFP mit den neuen Servern. Versuchshalber habe ich den neuen Mac mini i7 "Versuchsarbeitsplatz" unter OS X 10.9.1 mal mit dem (automatisch gewählten) SMB und dann manuell per AFP mit den Servern verbunden. Das ergab exakt gar keinen praktischen Unterschied bei einfachem GB-Ethernet.

Was ich schon sagen kann ist: Responsezeiten bei konkurrierenden Zugriffen gibt es auf dem Volume der SSDs so gut wie keine, das Archiv auf klassischer HD verhält sich wie erwartet.
0

Kommentieren

Diese Diskussion ist bereits mehr als 3 Monate alt und kann daher nicht mehr kommentiert werden.