Archiv der Kategorie: cloud

cloud ist das projekt, welches daten und streams aufnehmen und verteilen soll.
cloud is the project to take and deliver data and streams.

cubietruck

die ersten test mit dem cubieboard machen appetit auf mehr. 2 gb ram, dualcore-cpu, dual-gpu klingen nicht viel. okay, sd-card, netzwerkkabel und hdmi-kabel kommen oben drauf. doch zu weihnachten ist auf einmal dat cubietruck lieferbar.

ich muss mich schnell entscheiden, als ich die mail mit der verfügbarkeit erhalte, sind 2.5h später von 120 stk schon nur noch 76 da, ne 75. mist ich muss mich beeilen, also ritsch-ratsch … karte durch, ditt ding bestellt. durch die feiertage geht die bestellung diesmal nicht ganz so zackig, ist aber dann doch 4 tage später da. zumindest ist ein kühlkörper diesmal dabei, sowie ein 4 teilige plexiglas behausung, bei der sogar daran gedacht wurde, dass man eine 2.5″ hdd mit unterbringt.

cubietruck topview
cubietruck ( cubieboard 3 ) top view – power/nic/usb/vga

cubietruck sideview
cubietruck ( cubieboard 3 ) side view – led/sd/line/usb3

endlich gigabit ethernet, wlan, blutooth. fein, so dacht ich mir dass und die abmaße lassen mich hoffen, von den boards ein paar viele in den 19 zoll server zu bekommen, wie ich es gedacht hatte. mit s-ata anschluss geht die post ab, die sd-card ist nach-wie-vor kaum schneller als 10mbyte/s. aber moment, der treiber für den vermaledeiten realtek-chip ist kaum aufzustöbern. naja, versuch ich erstmal was da ist und saug also aufs neue ein paar images in verschiedenster konfiguration. aber der netzwerk-chip will nicht auf turbo schalten, mehr als 100 mbit/s gibts da derzeit nicht. fürs rz sicherlich ausreichend, doch die eisenbahnplatte war eigentlich für gigabit-ethernet gedacht.

muss ich wohl weitere images aus dem netz kramen. das video ruckelt auch hier, trotz zweier gpu´s läuft wohl alles in software ab und die cpu ist auf kante. das thema mit dem grafik-treiber ist damit leider noch nicht durch und wartet sehnsüchtig auf lösung….ebenso das wlan und dat blauzahn. die chipbezeichnungen sind kaum lesbar, so klein geschrieben, es gibt verschiedene revisionen, da sind nicht alle gleich.

cubietruck closeview
cubietruck ( cubieboard 3 ) close view – power/nic/sata/usb/hdmi connected

angenehmerweise hat das board einen 12v anschluss, nach kurzem test ist wohl aber kein wandler verbaut, der die 5v anschlussspannung hochschaltet. jedenfalls ist das ding mit 1.5 ampere noch gemütlich unterwegs, auch wenn in der spitze 2a angezeigt werden, sind das grad mal 10 watt aufnahmeleistung. im vergleich zu den circa 300 watt, die der dual-sockel-xeon-server aufnimmt, ist das doch recht bescheiden. wird sich jedoch noch zeigen, wie das mit der performance dann vergleichbar ist oder wie es korrelliert. ich denke jedoch, dass die leistung ausreichen wird, zumindest für die aktuelle phase der eisenbahnplatte.

abletonMIDI

ach wie ist dat schön, da möchte man ein externes gerät an ableton anknüppern, doch der versatz ( latenz ) mit internen instrumenten ist so auffallend groß, das guter rat teuer ist. der korg electribe offenbart nicht auf anhieb seine kapazitäten, denn diese können doch recht schnell ausgeschöpft werden. dennoch ist er mit seiner röhre ein angenehmer ruhestörer und läßt mit seinen drei dsp einigen spielraum für schmackigen sound.

kurz mal der link, zu dem berliner bau-haus 🙂 http://ableton.com

ableton jedoch will auch nach einigem tuning nicht unter 150ms.latenz laufen und so kommt studio one zum zug, welches durch seine präzision und liebevolle gestaltung positiv auffällt.

im unterschied zu ableton fehlt studio one jedoch die live-ansicht, die das erstellen von pattern nur in der sequenzeransicht ermöglicht und damit im handling definitiv dahinter steht. mit einer latenz von 30ms. punktet es jedoch so weit, dass es nun beinahe unentschieden steht.

(c) chiptune on ioioioio.eu

 

die abtastrate ist mit 48khz nicht sonderlich hoch, der samplepufferzeigt bei einer e-mu 0404 etwa 10ms. an wenn die mukke in der daw ( digital audio workstation ) abspielt

cubieboard

ich bin jetzt doch n bisschen fickrig geworden auf son kleines scheißboard. da ich ohne rootserver und ohne linux kaum an der eisenbahnplatte ( cloud ) weiter schrauben kann, begeb ich mich auf der suche im netz zu einem versand in de_DE.

entweder ich bin zu aufgeregt, zu unkondensiert oder warum auch immer, ich übersehe, dass die erste generation nur single-core ist, 1 gb ram hat und die netzwerkkarte nur 10/100 mbit/s schafft.  egal, für 50€ bin ich ja im budget des raspberry, aber mit doppelt so viel ram UND einem s-ata anschluss. das genügt mir als entschädigung. als ich das cubieboard in betrieb nehme.

cubie connected
cubieboard connected with sata hdd

auf der suche nach dokumentation, manuals, handbüchern – überhaupt irgendwelchen nützlichen informationen finde ich dann nach einigem suchen auch ein paar images, sie sich für sd-card eignen. ausserdem noch ein passendes „brenn-programm“ was die images da drauf tut. dabei fällt mir auch das ein oder andere image für den onboard-nand in die hände. ich saug erstmal was ich finde und probiere die verschiedenen ubuntu/debian/android versionen sukzessiv aus. einige booten garnicht, andere sind in zig versionen vorhanden – welche nehmen?

also bleibt mir wohl nichts übrig, als die verschiedenen konfigurationen zu checken. im wesentlichen schaue ich auf den treiber für die grafik einheit, also die gpu. dort ist eine mali-gpu verbaut, die direkt von arm stammt. das passenste triebwerk heißt „sunxi“ und ist direkt vom hersteller. die cpu, also der system-on-a-chip ( soc ) ist von ( ehemals allwinnertech ) nun unter http://cubieboard.org/model/ erreichbar und was dass heißt,mal schauen.. der schafft wohl 1080p, wie da im datenblatt steht – fragt sich nur mit wieviel frames pro sekunde :p

toll, warum hab ich die letzten monate bei den fights der x-server/clients nicht aufgepasst. mir, wayland, mesa, x11 … man was es da nun alles für zeug gibt. und wie zum henker wuppt man den treiber jetzt in den kernel :/ ich glaub, die frage krieg ich so schnell nicht beantwortet, daher krampf ich nicht weiter rum und mach mit config und install weiter.

einige versuche später bin ich noch nicht klüger, ich weiß zwar jetzt welche pakete so halbwegs laufen und wie man mit dem speicher haushaltet, frisch gebootet verbraucht das ding 80 mb mit xfce dann 180. ist der browser offen, sinds so um die 280 gb. tomcat läuft schon im hintergrund, oracles java ist auch drauf, nur die grafik ruckelt wie sau. von dem gigabyte ram sind 808 mb verfügbar, da bleibt noch ein bisschen luft für arbeitsdaten. jedoch noch kein open.gl, kein videostreaming, kein garnix in der richtung. die cpu auf vollanschlag kotzt, doch der treiber ist wohl noch immer nicht im kernel. muss ich mich jetzt wohl direkt mehr mit beschäftigen…..

cubie housed
cubieboard 1 in plexiglas behausung

tolle wurst, auf der einen seite lockt das ding mit kapazitäten, die eigentlich als settop-box ausreichen sollten und mir das video auf den fernseher streamt, auf der anderen seite könnte ich mir ein mini-nas bauen, da die sata-schnittstelle sowie drei usb anschlüsse platz für erweiterung lassen. aber ohne anständigen grafik-treiber, wirds wohl erstmal nix mit dem streaming-client. nuja, als load-balancer sollte der dampf wohl ausreichen, um die 100 mbit/s zu sätigen. übliche einstiegs-firewall-systeme haben auch nicht mehr und dsl oder vdsl ist derzeit auch nicht wesentlich schneller.

ownCloud

für escii hab ich da grad owncloud installiert. eher durch zufall fiel mir das auf, als ich die verfügbaren softwarepakete bei seinem provider durchsah. also klick-klack gleich mal installiert.

owncloud ist php-basiert und läuft auf nur einer maschine und ist damit nicht wirklich „cloud“ … klingt aber trotzdem toll. es gibt eine community und eine professionell version. die kostenlose v5 hab ich dann gleich mal drauf getan und es lief auf anhieb.

flux ein paar benutzer eingerichtet, plugins nachgeladen und die ersten samples mit ihm geshared. ging alles relativ flott und auch via webdav auf mobilen geräten recht flüssig. bei vielen benutzern kommt jedoch einiges an traffic zusammen, wenn man seine arbeitsverzeichnisse/repositories darüber synchronisieren will. aber für den augenblick war das 1 gigabyte webspace ausgenutzt. also den uralten vertrag beim provider aktualisiert und schon 10 gb gehabt. damit kann er wohl erstmal ne weile leben und brauch keine one-click-hoster mehr, wenn er seine mukke ( tracks oder mixe ) mit anderen teilen möchte.

rackServer

durch einen bekannten bekomme ich zugriff auf vier 19 zoll server von dell ( meine lieblingsmarke :/ ) mit 1 HE, die wohl nicht nur durch die zweite abschreibung durch sind, sondern einfach zu viel strom fressen, als dass ein weiterbetrieb noch sinnvoll oder wirtschaftlich tragbar erscheint.

rack server
dell power edge 1850

also fahr ich da hin, shredder die ultra-scsi platten ein zwei mal mit dem raid tool und kann die vier büchsen mit nach haus nehmen. okay, nicht ganz geschenkt, aber beinahe 😉 …. zu hause angekommen, schmeiß ich so ein ding mal an, der düsenjetähnliche sound kommt mir ja bekannt vor, ist aber in einer wohnung noch sehr viel unschöner, als in einem büro. so what, soll ja eh ins rechenzentrum fürn schmalen thaler.

ich wollte die dinger ja ausschlachten und mit neuen innereien direkt im rack betreiben. spassenshalber messe ich mal die aufnahmeleistung, die im leerlauf bereits 180w mit einer xeon-cpu ( p4/prescott ähnlich ) verbrät. da brauch ich garnicht erst messen, was das ding frißt, wenn ich den zweiten sockel auch bestücke, cpus gibts genügend. ich hader ein wenig, ob ich nicht mangels cashflow einfach die kleinste konfiguration von den möglichen ins rz stelle. doch nachdem ich den taschenrechner angeworfen habe, sind die stromkosten ( ca. 50cent/kwh ) auf ein jahr hochgerechnet, zum schlecht werden viel. zu viel für die eisenbahnplatte.

ich lass das mal sacken, eilt ja nicht – denke ich mir so.

dell power edge 1850
19 zoll rack server

raspberryPI

bei einem bekannten sehe ich wiedermal den raspberrypi. klein, leise und spielt video ab – allerhand. nachdem ich erfahre, das er nur 512mb ram hat, schwindet mein interesse. als node für die cloud zu wenig ram. 1gb sehe ich da als minimum an, selbst dann ist nicht platz, um alle dienste zu starten. ausserdem gibts nur sd-card und usb zur speicher-erweiterung.

immerhin spielt er hd-ready videos ( 720p ) flüssig ab. xbmc ist da eine ganz angenehme oberfläche, die mir unbekannte videoportale zum vorschein bring und damit neugierig macht.

ich gedulde mich in der anschaffung, die 512 mb reizen mich nicht, wohl aber die arm architektur, die in android-handies und tablets verbaut ist. so manches wochenende vergeht und ich rauf mir die haare langsam, dass ich nicht doch so ein ding gekauft habe. einfach um da reinzuschnuppern, 35€ oder 50€ mit ein wenig starter zubehör ist erstmal nicht viel.

aber ich bin in gedanken bei dem odroid, den ich bei der recherche entdeckt habe. quad-core-cpu und 1 gb ram, das wärs ja. oder auch 4+4 kerne, 2 gb ram. sowas fänd ich lecker. dennoch schau ich spassenshalber mal beim mädchenmarkt vorbei und auch beim jupiter, doch metronomisch gesehene, lohnt der verkauf wohl nicht. so ziehe ich ohne konsumrausch wieder ab.

mein bekanter erzählt mir vom cubieboard oder wars cubietruck, na jedenfalls war da neulich ein artikel in den news, wo darüber berichtet wurde. aber wohin man schaut, die dinger sind ausverkauft. doch lieber ein raspberry – werden sehen….

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.

eisenBahnPlatte

„was ist eigentlich eine holzeisenbahn?“

das projekt der private cloud den menschen zu vermitteln und dann noch zu erklären, dass man damit seine freizeit gestaltet, ist mir über die jahre nicht einfacher gefallen.

der begriff „eisenbahnplatte“ trifft vermutlich noch am ehesten dass, was otto normal bereits von anderen kennt, wenn es um viel arbeit, geld und liebe geht, das in ein projekt fließt, welches vermutlich nie wirtschaftlichen bedingungen unterworfen ist. man könnte es auch luxus nennen oder wie es allgemein genannt wird: hobby.

da ich mich nicht nur auf arbyte, sondern auch am wochenende oder nach feierabend mit den themen hier beschäftige, sah ich diesen begriff noch am dichtesten an dem, was eh schwer zu beschreiben ist. da dazu jede menge programmierung gehört, die erst gut läuft, wenn die konfiguration ein mindestmaß erreicht hat, ist die komplexität in zusammenhang mit der hardware und den modulen, die extern verwendet werden immens. ich hab garnicht präzise vor augen, wie viele schichten / layer nun tatsächlich involviert sind, manche sind absichtlich eingezogen, um module zu entkoppeln, andere lassen sich vielleicht auch reduzieren und einsparen.

da mir in den verschiedenen phasen schon beinahe der kopf geplatzt ist, hab ich teilweise oder an bestimmten punkten, die arbeit ruhen lassen und dinge aufgemalt, beschrieben oder sonstwie umrißen oder skizziert, damit nicht nur ich die dinge verstehe, sondern eben auch andere.

daher ist die eisenbahnplatte all das, wozu ich nach dem 3. oder 5. mal keine lust oder kraft hab, es zu schildern oder zu erklärbärn. daher auch der blog hier, um einsicht zu schaffen und ansichten zu vermitteln, die aussenstehenden oder interessierten die möglichkeit gibt, dinge zu erfahren, die sonst nur schwer oder schwierig zu erfassen oder gar zu finden sind.

die eisenbahnplatte fuhr schonmal“ mit drei nodes, doch sind mittlerweile alle server vom netz und derzeit wird neue hardware getestet und konfiguriert, damit der wirtschaftliche aspekt nicht zu kurz kommt.

anotherServerInstance

as a friend from a provider in berlin gave me the access to a vhost he had, i received another donation from him. a vhost instances with some more ram, as i had on the machine since now was now in the park.

so i had three machines to build my cloud further. since 2010 i was working with big-data tools and the hadoop-framework, a distributed file-system was the main aspect to build such thing. with the new server, i was able to raise the replication from 1 to 2. that was not the replication-factor of 3, which could be seen as minimum for hot-fail-over redundancy systems, but on the right way.

i introduced the machine to the cluster and configured the redirect-proxy the same way, as the machine in jena. after some tests, i had failures with „to many open files“ and i noticed, that the vhost-guest-system was heated to much with the hdfs, so i configured them further.

beside the cluster, i was able to use them as streaming-server for the radio as well, as i switched chromanova.fm on, with two channels as well. that was nice, to have capacity in bandwith that way and the scale was nearly linear to the count of machines.

now i was able to play harder with the layer between the tomcat-servlet and the byte-stream, given by the filesystem. the new machine had 4 gigabytes of ram and i gained the headroom for the caching on tomcat much higher then possible before.