De- oder Zentralität?

[Alexander (HH)]

Moin Moin!

Man könnte ja einen zentralen Fileserver aufbauen der mir RAID 0 auf zwei Festplatten läuft.

Fileserver auf RAID-0? Was hast Du für ein phantastisch schnelles LAN, dass Du auf ein RAID-0 zurückgreifen mußt?

Normalerweise wählt man für Fileserver redundante RAID-Level (1, 5, 6) oder kombiniert RAIDs in RAIDs (10, 01, 50). RAID-0 nimmt man nur bei extremen Geschwindigkeitsanforderungen.

Erwähnte ich, dass Fileserver eine Pest sind? Fileserver erlauben, dass jeder seine Daten völlig unstrukturiert und nahezu undurchsuchbar irgendwohin schmeißt. Vererbte Zugriffsrechte machen es dann für die Teams auch noch schwierig, an Dateien heranzukommen, die irgendjemand versehentlich oder absichtlich in einem privaten Verzeichnis verrammelt hat.

Dann könnte man ja sicherlich an einem anderen Gebäude nachts immer über das Firmennetzwerk (LAN, WLAN, Online) an eine NAS den Inhalt des Fileservers nochmals kopieren. (Dann wäre Flut und Einbruch zumindest etwas besser gesichert).

Sync über WLAN? Ohne weiteren Schutz?

Du brauchst vermutlich ohnehin ein VPN, dann schiebe auch sowas über das VPN.

(Wenn das Netzwerk, LAN, WLAN zum anderen Gebäude mal spinnt, dann gibt es ja im Normalfall auch keine Änderungen am zentralen Fileserver, bzw. der Backup wird ja eh immer nachts gemacht)

Der Witz an einer gut redundant ausgeführten Infrastruktur ist, dass BELIEBIGE Teile ausfallen dürfen. Im Sinne von: Du gibst mir alle Schlüssel und Keycards, ich gehe in die Serverräume und ziehe wahllos ein paar Strom-, Netzwerk- und Datenkabel im Betrieb heraus, ohne dass irgendjemand etwas merkt (abgesehen vom Alarm auf den Management-Systemen). Das bedeutet, dass es für jeden Job mindestens zwei Geräte gibt, die automatisch und ohne Service-Einbußen beim Ausfall des einen Gerätes den Job des anderen übernehmen. Damit ist auch klar, dass sich die Clients nicht fest an eine Maschine binden dürfen, sondern an einen Service.

git ist so organisiert, dass man wirklich komplett getrennt vom Rest der Welt arbeiten kann. Wenn man dann wieder in der Zivilisation auftaucht, kann man seine Änderungen mit dem Rest der Welt abgleichen.

Ja das hört sich auch interessant an. Darauf war ich auch schon gestoßen. Wirkte aber noch etwas kompliziert auf mich, weil:

Nehmen wir folgende einen kleinen Auszug der Ordnerstrukturen an:

/Verwaltung/Dokumente/

Alias "Allwissende Müllhalde". Ohne weitere Strukturvorgaben endest Du entweder mit einer Million Dateien in einem Verzeichnis, oder jeder Mitarbeiter macht sich seine eigene kleine Müllhalde.

Dokumente gehören in ein Dokumentenmanagementsystem, nicht auf einen Fileserver.

/Verwaltung/Buchhaltung

Wann gehört eine Datei hierher, wann in /Verwaltung/Dokumente? Die Verzeichnisse scheinen sich inhaltlich zu überlappen. Keine saubere Struktur, das führt zu einem Ablage-Chaos.

/Verwaltungs/Emails (Ein Postfachordner für jeden Mitarbeiter)

Mails gehören nicht auf den Fileserver. Dafür gibt es IMAP, so kannst Du notfalls auch ohne den Standard-Mail-Client alternativ über einen Webmailer arbeiten (der natürlich nur per VPN erreichbar ist!). IMAP ermöglicht auch Dinge wie gemeinsame Ordner, die für alle Mitglieder eines Teams erreichbar sind.

Und warum liegen die EMails für alle Mitarbeiter unter dem Ordner für die Verwaltung?

/Webdesign/Vorlagen

Read-Only, außer für wenige Auserwählte, die neue Vorlagen einstellen dürfen.

/Webdesign/Projekte

Ein Projekt beginnt vermutlich mit einer größeren Kopierorgie aus /Webdesign/Vorlagen?

Und Fehler in Vorlagen muß man dann in allen Kopien manuell nachpflegen? Was vermutlich nie klappt.

Ganz klarer Fall für SVN, git & Co.

/Grafik/Bidlvorlagen
/Grafik/Projekte

Nochmal das gleiche.

Manche /Webdesign/Projekte sind für alle sichtbar. Manche jedoch nur für bestimmte Personen. Es gibt dann aber im gleichen /Webdesign Ordner Vorlagen, die genauso für jeden sichtbar sind.

SVN hat ein minimales Rechtesystem, in das man sich etwas reinlesen muß. GIT ist auf bedingungslose Zusammenarbeit ausgelegt, ob und wenn ja, welche Rechte man vergeben kann, mußt Du selbst herausfinden.

Wo packst Du die Issues (Bugs, Feature-Requests, ...) hin? Intern und von Kunden? Fileserver und Mailserver sind beides ganz schlechte Ideen. Wenn Dir dazu nichts einfällt, sieh Dir Bugzilla und Trac an.

Wenn man nun die ganzen Ordner vom Wurzel als normales Laufwerk einbindet, kann man mit den Benutzerrechten ganz schön die Rechte regeln und hat dann den Standard Dateibrowser für die Ansicht.

Unter Windows per SMB / CIFS? Ja.

Per NFS? Nein. Rechte im NFS kann man ziemlich entspannt aushebeln, wenn man ein System hat, auf dem man sich lokale Root-Rechte verschaffen und lokle Benutzer mit kollidierenden UIDs anlegen kann.

Andere Netzwerk-Protokolle (wie AFS) beheben das Problem.

(Schön wäre natürlich eine DMS, wo man die Dateien mit Metadaten füttern kann, nur hat man nicht mehr schön den Standard Dateibrowser des Betriebssystems)

Doppelter Irrtum:
1. Für Dokumente ist ein DMS eigentlich zwingend notwendig.
2. DMS können sich durchaus in vorhandene Dateimanager einklinken. Unter Windows geht das so weit, dass sich das DMS auch in die Standard-Dialoge für Öffnen und Speichern einklinken kann. Für Office-Pakete gibt es ebenfalls Plugins, die das DMS nahtlos in die Arbeitsumgebung einbauen.

Das SVN (oder auch GIT) würde ich ja nicht auf den kompletten Fileserver (vom Wurzelelement) anwenden, sondern ja nur für bestimmte Ordner (Bsp. /Webdesign/Projekte/kundeA_projekt)

Nein, das SVN / git ist vom Fileserver komplett getrennt (auch wenn es auf der selben Maschine liegen kann). SVN und git haben eigene Protokolle (z.B. svn+ssh, svn über http(s)), um auf das Repository zuzugreifen. Die Dateien, aus denen das Repository besteht, sollten für Normalsterbliche nicht einmal sichtbar sein.

Und in das SVN / git gehören minimal alle Entwicklungsprojekte.

Die veränderten Arbeitsdateien jedes einzelnen Entwicklers und Code-Sklaven liegen in einer Sandbox in dessen Home-Verzeichnis (das für Backup-Zwecke durchaus auf einem Netz-Laufwerk liegen kann).

D.h., ich würde dann für verschiedene Ordner nur das SVN einsetzen, da es sicherlich kein Sinn macht, vom Wurzelelement, da es auch Ordner gibt, die für jeden eh zugänglich sind bzw. auch Ordner gibt, die sich nicht oft ändern und nur allgemeine Dokumente enthalten.

Das Problem wäre aber sicherlich auch, wenn man SVN einsetzt für einen Bereich (Bsp. /Webdesign/Projekte/kundeA_projekt), dass man dieser Ordner über den Standard Dateibrowser ja nicht mehr einsehen/erreichen kann,

Warum sollte das nötig sein?

Die Entwickler haben SVN / git, und der Rest hat dort nichts zu suchen.

da SVN (oder GIT) sicherlich nach seinem eigenen Schema/Formaten die Dateien abspeichern. (Es wird ja eh nur die Änderung gespeichert und Revisioniert)

Richtig erkannt.

Für SVN und git gibt es diverse Frontends, mit denen man einen Read-Only-Zugriff auf das Repository bekommt, z.B. per Webbrowser.

Der Stand im SVN ist aber nicht unbedingt interessant. Wenn Du Web-Projekte baust, hast Du einen Testserver, auf den per Knopfdruck ein "svn export" läuft, gefolgt von einem wie auch immer gearteten Deploy-Script. Dann kannst Du den aktuellen Stand auf dem Testserver beurteilen.

Weitere Knöpfe (mit Zugriffsschutz) schieben einen Export auf den Staging-Server zur Qualitätssicherung, und auf den Produktionsserver. Auf Staging und Produktion hat kein Entwickler etwas verloren, dort wird nicht gecodet, nicht einmal gepatcht. Alle Änderungen werden aus den SVN / git per export herausgeschrieben.

Bei SVN brauchst Du zwingend eine Verbindung zum SVN-Server für ein "commit", und nur den Server mußt Du wirklich sichern. Es sei denn, irgendein Trottel macht sein Ding am SVN vorbei oder hamstert tonnenweise Änderungen ohne ein einziges "commit".

Ah okey, die Datei ist außerhalb vom SVN dann trotzdem normal zu erreichen.

Nein. Wie kommst Du darauf?

Alle un-"commit"-eten Änderungen liegen in der für andere nicht einsehbaren Sandbox eines jeden Entwicklers. Mit dem commit werden die Dateien ins Repository übertragen. Und mit einem export kann man Teile des Repository in ein stinknormales Verzeichnis exportieren, typischerweise für das Einspielen einer Test- oder Release-Version in die entsprechenden Server.

Dann müsste ich mir mal eine Strategie überlegen, und nach Vorteile/Nachteile und Risiken mal abwägen.

Du scheinst noch einige grundlegende Verständnisprobleme zu haben, was SVN & Co angeht. Lies Dich mal in das oben verlinkte SVN-Buch sein. git tickt etwas anders, aber nicht grundlegend anders.

Vorher kannst Du nicht sinnvoll entscheiden.

Alexander