Schlagwort-Archive: infrastruktur

cloudAnbieter

da festplatten zwar immer günstiger und größer werden, die dateien und formate aber auch, bleibt das ewige spiel mit dembackup. wie möchte man eine 2-3-4 terabyte platte sichern? wie kann man 10 oder 20TB sinnvoll wegschaufeln? was tun, wenn das haus abgebrannt oder abgesoffen ist – was ist dann mit den eigenen daten. klar, man kann sie brennen oder auf usb kopieren, aber ab einer bestimmten größe macht das alles keinen spass mehr. nun hab ich heut beim g+ ein paar interessante beispiel für verfügbare clouds aufgeschnappt:

tarsnap fällt durch schlichte leistung und geringe kosten auf. 0.30us$/gb-monat für den space und 0.30us$/gb beim traffic scheinen günstig zu sein. der wesentliche punkt aber ist, dass nur veränderte daten hochgeladen werden, ein inkrementelles backup sinngemäß. aes-256 wird angeboten und kann, da linux-basierter-client, durch eigene maßnahmen ergänzt werden. als infrastruktur wird amazon ec2 verwendet, also nichts aufregendes.

crashplan sieht wesentlich ausgereifter und professioneller aus. die verschlüsselung beträgt 448-bit für die dateien und 128bit-aes für die verbindung. 4us$ für einen rechner, total-backup, klingt ok – eine konkrete größe vermisse ich aber dann doch. für firmenkunden werden auch pakete mit 200 oder 1000 und mehr angeboten. die infrasturktur ist nicht auf den ersten blick ausgeschildert.

der vollständigkeithalber wären noch die üblichen  verdächtigen zu nennen:

google-drive
apple-icloud
µ$-onedrive
strato-hidrive

klar kann man sich auch ein nas hinstellen, doch es geht ja um ein offsite-backup, also eine sicherungskopie ausserhalb der eigenen vier wände. sicher, im bunker, tief im rechenzentrum, dupliziert, verteilt, gespiegelt – einfach bombensicher *hust*. was die einzelnen betreiber jedoch im kleingedruckten für regeln und leistungen haben, muss man dann doch genauer evaluieren.

conceptProgressFiles

um die arbeiten an der cloud auch ein wenig dokumentiert zu haben, hab ich das single-page-design noch einmal verwendet und für die konzeptuelle beschreibung online gestellt.

das konzept, welches sehr grob und auch ein bisschen vage oder schwammig die vorstellungen von der private cloud skizziert, beschäftigt sich mit den verschieden modulen. diese sind vorläufig mit

  • 1. frontend
  • 2. backend/datamodell
  • 3. cluster
  • 4. mechanics
  • 5. cdn

umrissen. das frontend soll schlank sein und möglichst in einem rutsch, in einer datei ausgeliefert werden. da dynamische anfragen an die cloud möglichst minimal gehalten werden sollen, ist die anlieferung der inhalte – wenn statisch – dann durch einige cache-layer abgefedert. da die dateien auf verschiedenen knoten verteilt sind, kann es bei ungecachten dateien durchaus 2-3 sekunden dauern, bis diese verfügbar sind. ein prefetch oder precache ist daher sinnvoll. die dynamischen inhalten werden durch ein nosql schema realisiert. das datenmodell ist in verschiedenen schichten sowohl im front- als auch im backend nutzbar und ist teilweise durch generische klassen oder reflektive methoden ergänzt. die dateiablage kann man als flatfile ansehen, die durch map-reduce-aufbau oder ein denormalisiertes modell gekennzeichnet ist.

was heute cloud heißt, war vorher ein cluster, davor ein grid und irgendwann bestimmt auch mal ein mainframe 🙂 die heut noch üblichen architekturen, mit application-server <-> database-server, network-attached-storage und ftp-backup wird verglichen mit dem konzept, welches meiner entwicklung zu grunde liegt. die skalierung von 6-10 maschinen ist dort skizziert, die 5.000 maschinen, die bei hadoop-clustern durchaus üblich sind, muss sich der geneigte leser dann vorerst doch noch vorstellen.

der workflow oder die sequenzen, die für die arbeit zwischen den layern benötigt wird, kann man als mechanik in diagrammen aufzeigen, so können für verschiedene anwendungszenarien die beteiligten komponenten identifiziert, beschrieben und ausgebaut werden. da alles in einer sprache verfasst ist, ist ein medienbruch oder andere dialekte vorerst nicht nötig.

ist die orchestration dann über verschiedene kontinente und mehrere rechenzentren verteilt, so können funktionen eines cdn implementiert werden. dort werden dann ungesehener und gesehener inhalt ausgetauscht, statistiken für die optimierung und auswertung angelegt und die günstigsten, schnellsten oder besten routen für die anlieferung der daten gewählt.

mit dieser infrastruktur kann dann auch streaming betrieben werden, da die signallaufzeiten und die kapazitäten den anforderungen des marktes angepasst sind und entsprechend flexibel dimensionierbar sind.