Schlagwort-Archive: streaming

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.

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.

 

shoutcastStreamServer

as i run the webradio ( hardcore-central.net this time ) with craig and the amount of listeners are raising, iam looking for an own root-server, to stream the channels by our own. we send with shoutcast-server, which is listed on the portal for a bigger audience and a lot of customers to catch.

therefore i look for the cheapest machine, with unlimited traffic and i pick up one in southern-germany, in jena at euserv. i take the „misurf-m“ with singlecore athlon, 160 gb hdd and 1 gb ram. the price for that machine is ~28€/month, the slots on citrus, we used before costs around 16 british pounds per 25 users. that means, the machine is a lot of money worth, if fully usable.

configuring and customizing the server takes two days or so, then two streams are ready to play that funky music loud boy.  the machine is connected with 100mbit/s and with 160 kbit/s per stream, ~600 listeners / slots are estimated. that is the initial idea as use-case for streaming.

but during the tests i see, that 20-30 mbit/s is the average bandwith before drop-outs take place and interrupting the stream is not so niceley. anyhow, digging the stats from the logfile, observing the customers wants and needs came into the focus, but a good shout-stats-analyzer is not in sight, the same with a nice player for the browser, with streaming-abilities.

ill take some free widgets from the net, to drop them into  the html page and the radiostation is online then. using winamp or vlc player as stream-client is quite easy, so we stream both the gabba and hardcore channels and later on, i switched electro and acid on as well.

therefore, i register the domain ioioioio.eu to handle the url and links and to present the material somehow neutral, with a to close binding to hc. but to be true, my drive and motivation came out of the music    ( mukke ) at i see that as essential influence in life.