Andi vs. Die Cloud: Die Manuellen

cloudheaderMein fancy-schmancy neues Laptop hat eine SSD. Die ist toll, aber verdammt klein. Wohin mit all den wichtigen Daten, damit mein Autobiograph sie in siebzehn Jahren noch finden kann? In die Cloud!

Ich fand also heraus, dass die großen, allanwesenden Cloud-Anbieter für meinen Fall nichts taugen. Was macht man als Physiker, wenn das erste Suchresultat nicht befriedigend ist? Richtig: Man startet LaTeX beginnt, es selbst zu bauen.

Schauen wir uns also ein mal an, was man alles nutzen kann, um seine eigene Minicloud zu bauen. Dabei beginnen wir mit der Software, die das Datenausliefern übernimmt, gehen weiter zu Out-Of-The-Box-Lösungen und enden mit Installationen auf eigenen und auf Amazon-Servern.

Protokollismus: SMB, AFP, NFS, SSH, WebDAV

The logbook by littlevanities, on Flickr

Protokoll. CC-Bild von littlevanities.

Prinzipiell gibt es einige Protokolle, die serverseitige Dateiverwaltung ermöglichen. Die Wichtigsten:

  • Samba setzt das SMB-Protokoll und damit die spacige Windows-Freigabe Open Source um und macht sie damit auch für Unix/Linux-Systeme verfügbar. Samba ist böse. Vielleicht liegt es an meinen eingeschränkten Konfigurierungsskills, aber Samba hat bei mir nie zuverlässig und schnell funktioniert. Es war immer ein PITA.
  • AFP ist nicht so böse. Das Apple Filing Protocol ist Apples Alternative zur Windows-Freigabe via SMB. Da bei mir Mac OS im Einsatz ist, ist das natürlich die nähere Wahl. Die Open-Source-Umsetzung für Linux, netatalk, funktioniert auch ganz hervorragend bei mir im lokalen Netzwerk. Sogar mit Bonjour. Ist bei mir für Backups und sonstigen Dateitransfer zuständig und macht auch locker das Gigabit pro Sekunde beim Datentransfer voll.
  • SMB ⇆ Windows, AFP ⇆ Apple — NFS ⇆ Unix. Das ist natürlich völlig simplifiziert und vermutlich werden mich die Unix-Nerds dafür mit TCP-Paketen verprügeln, aber mehr oder weniger ist das so. NFS stellt auf Unix-Betriebssysteme Netzwerkfreigabemechanismen zur Verfügung. Die sind, wegen der Philosophie von Unix als Multi-User-Betriebssysteme, allerdings tiefer in die Infrastruktur des Systems eingebettet. Ich glaube, wenn man NFS einmal vernünftig eingerichtet hat, dann läuft das ganz wunderbar. Allerdings hab ich es soweit noch nie geschafft, zumal bei mir auch noch ein komplizierendes Mac OS X involviert ist…
  • MacFusion, mounted SSH-Laufwerke mit Klick. Leider kaputt.SSH gibt es ja ungefähr seit dem Bau der Pyramiden.1 Gefühlt. Ist aber immer noch in Benutzung wie warme Semmeln.2 SSH stellt eigentlich nur eine Verbindung zu einer Kommandozeile auf einem anderen Rechner her. Aber dank SFTP und anderem Protokoll-Schnick-Schnack, haben fähige Leute SSHFS gebaut. Das ermöglicht das Mounten eines entfernten Ordners im eigenen, lokalen Dateisystem. Mit verschlüsselter Datenverbindung zwischen den beiden Enden. Klappt ganz hervorragend — und mit ein bisschen Suchen nach den Tools, die den gewünschten Comfort bereitstellen, auch außerhalb der Kommandozeile über Betriebssystemgrenzen hinweg.
    SSHFS ist bei mir ebenfalls in Benutzung. Ich nutze es, um das Dateisystems des Instituts zu mounten und direkt im Rechencluster zu programmieren.
  • WebDAV ist eine Erweiterung des HTTP-Protokolls, die das Lesen und Schreiben von Dateien und Ordnern ermöglicht. Die bekannteste Serverumsetzung von WebDAV bietet Apache. Alle großen Betriebssysteme (sogar Windows) können von Haus aus auf WebDAV-Server verbinden. Klassischer Weise benutzt man WebDAV dazu, seine HTML-Dateien auf einen Webserver zu laden, so dass der die ausliefern kann. Schließlich ist Apache dann meist sowieso installiert. Aber prinzipiell spricht nichts dagegen, Apache (o.Ä.) allein für ein WebDAV-Verzeichnis zu installieren.

Das sind die bekanntesten Umsetzungen von Dateiverwaltungen über Rechnergrenzen hinweg. Aber bei weitem nicht alle — es gibt noch jede Menge weitere, für allgemeine Anwendungen sowie spezielle Use-Cases. Mit unterschiedlicher Komplexität und Einrichtungsaufwand.3

A propos Einrichtungsaufwand: Mit hinreichend intensiver Googleung und ausreichend verschwendeter Zeit4 lässt sich rausfinden, wie die einzelnen Protokolle aufzusetzen sind. Anleitungen gibt’s, gerade bei den Großen hier, zu Genüge.

Aber geht’s vielleicht auch was automatischer?

Kistenlösungen: ownCloud, Sparkle Share

Klar tut es das. Zwei Dienste, die die rohe Protokollkost vom Benutzer abschirmen und vorgegart präsentieren sind ownCloud und Sparkle Share.

  • ownCloud LogoownCloud benutzt WebDAV, um Zugang zu Cloud-artiger Dateiverwaltung zu geben. Außerdem gibt’s Dienste zum Synchronisieren von Kontakten, Kalendereinträgen und Bookmarks. Versionierung von Dokumenten ist ebenfalls eingebaut.
    Verschiedene Installationspakete des Servers stehen bereit, die auf Apache-Installationen (als LAMP5 bzw. MAMP6) unter Unix-Flavor-Betriebssystemen oder IIS-Installationen unter Windows zurückgreifen. Natürlich gibt’s ausführliche Installationsanleitungen. Wem selbst die paar wenigen Installationsschritte zu viel sind, der kann auf die kommerzielle Seite von ownCloud zugreifen: ownCloud.com7 vermittelt bereits fertig installierte ownCloud-Server.
    Klienten-Software, also die, die nach der einmaligen Serverinstallation dann tagtäglich auf dem Anwender-PC im Einsatz ist, gibt’s für Linux, Mac und Windows. Genauso wie der Serverteil von ownCloud werden auch die Clients aktiv weiterentwickelt. Da ownCloud auf WebDAV basiert, kommt man auch ohne den offiziellen Client, direkt mit WebDAV8 drauf.
    ownCloud besitzt ein Webinterface, mit dem man alles machen kann, und Apps für Android und iOS, die u.a. ein automatisches sichern geschossener Fotos ermöglichen.

    ownCloud ist ausgereift und funktionierte in meinem Test wie es soll. Allerdings synchronisiert es normalerweise lokalen Kram mit dem Server, d.h. der Festplattenspeicherplatz auf Klientenseite muss vorhanden sein. ownCloud ist da mehr die Dropbox-Alternative. Für meinen Fall, also: Meh.

  • SparkleShareSparkleShare. Folgende Gleichung: (ownCloud/WebDAV) = (SparkleShare/Git). Soll heißen: Während ownCloud unter der Haube auf WebDAV beruht, benutzt SparkleShare Git als Synchronisationsbasis. Das ist lustig, habe ich die Programm-Code-Verwaltung Git doch nie als Dateiverwaltung gesehen. Aber warum nicht?
    SparkleShare wird, so wie ownCloud, Open Source entwickelt. Die Entwicklergemeinde scheint dabei etwas kleiner, aber nicht minder aktiv. Da SparkleShare auf reinem Git beruht, bedarf es serverseitig nichts anderem als einem Git-Server. Da kann man entweder ein freies/kommerzielles Repository bei Github oder Bitbucket nehmen, oder sich einen Git-Server auf der eigenen Maschine installieren.
    Den SparkleShare-Client gibt’s für Linux, Mac OS X und Windows. Der läuft im Hintergrund und synchronisiert die Änderungen am lokalen, eingerichteten SparkleShare-Ordner mit dem Server — und etwaigen anderen Rechnern, die ebenfalls dort verbunden sind.
    Hat in meinem Test ebenfalls gut geklappt9 — aber synchronisiert ebenfalls wieder nur einen Ordner mit einer entfernten Stelle. Lokaler Plattenplatz wird also benötigt. Still: Meh.

ownCloud und SparkleShare sind also gute Tools, die einem das Aufsetzen einer eigenen Cloud ermöglichen. Um sich vom Joch der großen, unternehmerischen Cloud-Firmen zu emanzipieren prinzipiell eine gute Idee. Auch, wenn man dem Datenschutz von Dropbox und Co nicht traut — zumal deren Server in den USA stehen und den dortigen Gesetzen unterliegen.10 Für mich und meinen fehlenden Festplattenspeicherplatz allerdings keine wirkliche Option.

Die Serverfrage: Eigenservung

Egal ob selbstgebaute Lösung oder ownCloud oder SparkleShare, was ich oben heimlich ausgeklammert habe, ist die Frage nach dem Server. Denn all die Protokolle und ihre Umsetzungen benötigen, logisch, eine Gegenseite mit der sie kommunizieren können.
Zu Hause habe ich eine kleine Ubuntu-Kiste laufen, für Datensicherungen und als Datenablage. Allerdings ist mein Telekom-DSL-16.000-Anschluss im Upload viel zu langsam, um mit dem Server irgendetwas Cloud-artiges ernsthaft zu betreiben.11 120 Kilobyte pro Sekunde beim Hochladen machen keinen Spaß.12 VDSL gibt es bei mir leider nicht, aber damit wären ca. 1 Megabyte pro Sekunde Upstream möglich. Das geht schon in die richtige Richtung und ist für sporadischen Dateizugriff vermutlich genug. Dauerhaft damit Daten zu clouden ist aber auch müßig.
Die Telekom baut zwar deutschlandweit Glasfaser aus, aber das nur in einzelnen Orten.13 Interessanter wird’s da mit lokalen Anbietern. Hier in Aachen gibt’s NetAachen, die ihr Glasfaser-Netz ausbauen. Allerdings auch nur straßenweise — und nicht bei mir.

Also kein Heimserver für mich.

Die Serverfrage: Fremdservung

Anmietbare Server in Rechenzentren gibt’s wie Sand am Meer.
Der Server dieses Blogs ist ein virtueller Server14 bei Host Europe. Allerdings nur mit 50 GB, richtig viel passt da auch nicht drauf. Mehr Plattenplatz wird bei solchen Servern in Rechenzentrum immer relativ schnell teuer — bei manchen Anbietern mehr, bei manchen weniger.

Amazon Web ServicesDann gibt es natürlich noch das Modell à la Amazon Web Services. Man hat nicht wie beim virtuellen / dedizierten Server Zugang zu seinem eigenen, kompletten Rechner irgendwo im Rechenzentrum, sondern kauft einzelne Dienste und Operationen ein: Daten schreiben, Daten lesen, Daten berechnen. Amazon S3 ist der Name der Sparte, die Dienste zur Datenverwaltung bereit stellt, Amazon EC2 benennt den CPU-Rechen-Teil.
Abgerechnet wird nach dem, was man wirklich verbraucht. 0,1 US-Dollar pro Gigabyte, was man speichert, 0,12 US-Dollar pro Gigabyte, was man (rausgehend) überträgt. Bei 500 GB wären das also monatlich 50 Dollar Speichergebühren plus Transfer. Vermutlich habe ich etwas übersehen15 und geschludert, aber, bottom line: Das kostet. Um den Zugriff muss man sich selber kümmern. Zum Beispiel über ein FUSE16.

Natürlich geht’s auch komfortabler, wenn man etwas mehr Intelligenz in die Cloud steckt. Man kann auf Amazon EC2 sein Lieblings-Linux installieren. Das konfiguriert man dann nach Geschmack und hat, tada, seinen eigenen Server in der Amazon-Cloud.
Natürlich seid ihr nicht die ersten, die sich mit persönlicher Amazon Cloud auseinander gesetzt haben. Für ownCloud gibt’s z.B. schon fertig konfigurierte Pakete im Amazon AWS Marketplace.

Alternativen zu Amazon, bei gleichem »On Demand«-Modell gibt’s auch. Host Europe hat da zum Beispiel was.

Fazit

Es gibt also jede Menge unterschiedliche Protokolle mit jede Menge unterschiedlichen Features. Außerdem eine Menge Möglichkeiten, seine eigene Cloud aufzusetzen. Von einfach bis kompliziert, von simpel bis fancy, von lahm bis schnell.
Aber für (so gut wie) alles braucht man lokalen Speicherplatz.

Nicht so, bei dem, was ich euch als nächstes zeigen werde. Jaha.

  1. Deine Mudda is‘ älter als SSH! []
  2. Deine Mudda wird mehr benutzt als SSH. Ok, ok. Genug. []
  3. Lustre, anyone? []
  4. Ersteres lässt sich durch Letzteres substituieren und andersrum. []
  5. »Linux, Apache, MySQL, PHP« []
  6. »Mac OS X, Apache, MySQL, PHP« []
  7. Wie bei WordPress: .org-Domain bietet die Software an, .com die kommerzielle Umsetzung. []
  8. Zweiter Link. []
  9. Und hat endlich mal keine Wolke als Icon! []
  10. Wusstet ihr, dass das FBI einen Backdoor in jedes File einbaut, was auf die Dropbox-Server hochgeladen wird? Außerdem hat der Mossad Schadcode in jedem FBI-Backdoor. Und die Chinesen haben ja bekanntlich versteckte Programmroutinen sowohl im FBI-Backdoor als auch im Mossad-Code. Da kann’s sein, dass das 1-KB-Textfile auf einmal 10 MB groß ist. ECHTJETZT! []
  11. Bestimmt verbietet mir das auch irgendeine Vertragsklausel. []
  12. Selbst Cloud-Kram mit richtigen Servern am anderen Leitungsende ist ja abenteuerlich genug mit normalem DSL-Upload. []
  13. Und selbst da wird nach 400 GB pro Monat die Bandbreite auf 50 Kilobyte pro Sekunde gedrosselt. []
  14. Die Doppelhaushälfte Eigentumswohnung des Internetties. []
  15. Vielleicht wäre Amazon Glacier zum Backup interessanter — das hat längere Zugriffszeiten, kostet aber auch ein Zehntel… []
  16. File System in User Space []

8 Gedanken zu „Andi vs. Die Cloud: Die Manuellen

  1. Das mit OwnCloud bringt mich wieder auf die Idee, dass das ja eigentlich eine schöne Alternative zu Dropbox wäre und man die Daten nicht /irgendwo/ hinschiebt. Aber wenn man den Ordner-Sharing-Modus von Dropbox behalten will, muss man doch wieder zwei Dienste laufen haben. Neee.

    Zur Eigenservung: Ich glaube, für Backups ist 1 MB/s Upload auf Serverseite voll OK. Vor allem, weil man diese Richtung ja nur für vereinzelte Sachen braucht bzw. für den Notfall. Wenn man was größeres braucht (Musik für die dicke Party, Fotoalbum für das Familientreffen) kann man das auch immer noch im Vorfeld kopieren. Denn zu Hause hat man LAN und das ist schnell genug 😉
    Mit den 120 kB/s stimme ich dir allerdings zu: uarx!

    1. Ja, ok ist das. Für ein sporadischen Zugreifen auf die Daten. Aber stell dir vor (um das mal auszureizen) du hast deine täglichen Dokumente in der Cloud? Riesige Word-Dokumente, mit tausenden integrierten Bildern, wie wir sie eben bei unsere täglichen Arbeit brauchen ;)? Naja, so halt… 😉

  2. Eventuell ist git-annex (http://git-annex.branchable.com/) einen Blick wert? Basiert auch auf git, nutzt das aber nur für die Metainformationen und legt die Dateiinhalte in einem eigenen System ab, welches es automatisch auf mehreren Backends verteilen kann, unter anderem box.com, amazon s3/glacier, rsync.net, eigener Root-Server.

  3. Das geht jetzt ein bißchen am eigentlichen Thema des Beitrags vorbei, aber hast Du Dir mal die Datei-Struktur von git angesehen? Das ist ein Dateisystem. Wirklich.

Kommentare sind geschlossen.