Alle Beiträge von tet

mukke

stagePlanning

sitz hier so mit doogie und wir fachsimpeln über beschallung im größeren stil, wie man das „halbwegs“ gut vorher planen kann, wenn man nicht die mittel für simulations-programme hat um seine p.a. optimal im rechner zu testen.

da schau ich im netz und finde da so einige beispiele an 3d-modellen, sogar function one ist dabei und das ergebnis ist für eine aufbauplanung doch recht hilfreich. das ausleuchten des zuschauerraums ist damit noch nicht getan, jedoch kann man anhand der technischen daten, die öffnungswinkel ablesen, und ebenso im drei dimensionalen maßstabsgetreu planen. mit verschiedenen cad-programmen läßt sich so etwas durchführen, eine kostenlose version wäre blender.

im bild auf der linken seite recht gut zu sehen, ein “double bass array”  ( ob der begriff total korrekt ist, ist mir togal – bin ja kein veranstaltungstechniker mehr ) … ein versetzter stack, der dem vorstehenden eine richtung gibt. bass breitet sich bekanntlich im tiefen bereich kugelförmig aus … mit einem zweiten bass/subwoofer wird der schall dann in einer richtung gezielter gefächert, wenn die signallaufzeit zum abstand korrigiert ist. der hintere drückt vermutlich zu erst, dann folgt der vordere lautsprecher.

planning public audio
3d stage planning

diesen aufbau hatte ich vor einem jahr etwa auf einem video gesehen, das von der fusion stammte. fand ich interessant den aufbau und wollte doogie eben mal kurz zeigen, was damit gemeint war, da die mukke so viel fetter rüber kommen dürfte.

cloud, coding, this();

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.

this();

singlePageHTML

beim rumsurfen und vergleichen von downloadgeschwindigkeiten einzelner webseiten, der zeit bis der dom-tree geladen ist und die seite fertig gerendet ist, hat mich von der singlepagevariante überzeugt, die auf ioioioio.eu nun sichtbar ist.

das ding heißt bootstrap und bezeichnet sich als framework. ( wir erinnern uns, framework calls you – you call the library ) … nunja, es soll wohl der komplette baukasten gemeint sein. jquery und kompiliertes javascript tun ihr übriges. die seite ist mit ihrem brutto-volumen von einem megabyte in etwa einer sekunde geladen. die g+ einbettung dauert dann ein wenig länger. gecached ( wiederholt geladen ) ist sie in etwa 500ms aufgebaut und dauert mit dem gugl-geraffel dann knapp über eine sekunde und braucht dann nur noch ein paar kilobyte zu laden.

mir gings im wesentlich darum ein seitendesign zu nutzen, welches in einer datei ausgeliefert, dennoch eine simple navigation ermöglicht. grund ist, das ich solche seiten mit generieren will, die dann statisch auf dem file system vorliegt und daher ultra-fast ausgeliefert werden kann. da es sich jedoch um pures html handelt, ist die erstellung des inhaltes im editor dann nicht so lecker.

die nutzung eines rich-text-clients ( wysiwyg editor ) ist da dann immer noch notwendig, eine synthese aus diesen beiden habe ich bisher noch nicht entdeckt, aber auch noch nicht konkret danach gesucht. ich wollte meine landing page erneuern, mit jquery rumspielen und das ist dann halt dabei rausgekommen. könnte schlimmer sein 🙂

eine der möglichen templates für die seiten in der cloud könnte dann in etwa so aufgebaut sein und in aussehen und verhalten durchaus ähnlich sein. als passive oder statische seite sehe ich dieses design für brauchbar an.

cloud, coding, this();

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.

cloud, english, this();

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.

 

cloud, english, this();

anotherWebServer

as i patched lighthttpd to work with the servlet and the next patches discontinued over a period, i was somehow motivated to check another services, for the same reason.

i just needed the webserver to redirect and reverse proxy the requests and responses from the different instances/services to the client. no php, just port handling and some folder/path specialties. so i kicked lighty and droped nginx on the system.

the configuration wasnt that re-usable as i hoped, but the plenty examples on the web made it possible to came up with the service after two weekends. nginx performed well in the official benchmark examples and i was happy with the result, ive seen on my own on the examples i made. handling the j-session-id was done with a patch and the round-robbin worked much more smooth, then before.

the delivered pages were quick and the hunger for ram was low, so i raised the caching on the webserver a bit higher and played with different configurations between tomcat and nginx over the next weekends. i was ok with what ive seen, so the need to dive into the apache config was not a topic anymore.

cloud, this();

bigData

nun bin ich also doch beim thema „big-data“ gelandetund eher wie die jungfrau zum kinde zu diesem thema gelangt. daher ein paar gedanken zur einleitung in dieses thema.

bisher hatte ich mich mit erp-systemen ( enterprise resource planning aka sap&co. ) beschäftigt. dann gings um reporting-systeme ( abrechnungen, abschätzungen, berichte ) und darüber bin ich nun in der ecke gelandet, die aktiv wird, wenn die datenbank nicht mehr weiter kommt oder sogar dicke backen macht.

im wesentlichen geht es darum, eine große aufgabe so zu dimensionieren und zu portionieren, dass viele kleine maschinen damit zurecht kommen und in der summe dann mehr dampf haben, als eine dicke maschine.  statt die daten jedoch normalisiert ( möglichst ohne duplikate ) wie eine datenbank zu halten, wird bei big-data  jede tabelle im csv/tsv ( comma / tab separated value ) format als flatfile vorgehalten. die daten sind de-normalisiert, weil aufgrund der heutigen plattenkapazitäten, die schrumpfung auf das letzte byte aufgegeben ist und jeder eintrag ( eine zeile ) durchaus mega- oder gigabyte betragen kann.

die daten sind in einem verteilten dateisystem ( hadoop distributed file system / hdfs ) über mehrere rechner redundant verteilt und werden in einer „salami-taktik“ durchgerechnet und wieder zusammengeführt. so kann es passieren, dass ein quell-tabelle in einem full-cross-join ( alle mit allen vergleichen ) auf 300 oder 400 gigabyte swap-file explodiert. normalerweise ist diese menge mit den üblichen sytemen ( fibrechannel oder iscsi ) kaum zu bewältigen, da das nadelöhr / flaschenhals ( bottleneck )  der zugang zum speichersystem ist. in einem cluster mit 10 nodes macht das nur noch 40 gb swap pro node, bei 20 nodes nur noch 20 gb, die ausgelagert werden müssen. die so nutzbaren skaleneffekte sind ein hauptargument dieses verfahren.

die üppigen datenmengen, die so miteinander verglichen werden können, übersteigen die üblichen verfahren des business-intelligence ( bi ) oder data-mining ( dm ) bei weitem, da korrelationen durch model- und testgetriebene entwicklung ausprobiert und das jeweils sinnvollste modell anwendung finden kann. durch verschiedene konfigurationen des systems können die aufgaben optimal auf verarbeitet werden, da bestimmte jobs mal mehr ram, mal mehr cpu oder mal mehr festplatte benötigen. der flaschenhals läßt sich nach identifizierung weiten, in dem auch weitere maschinen in den cluster genommen werden können, um das gewünschte ergebnis zu produzieren.

so wird die möglichkeit geschaffen, völlig neue ansätze oder alte verworfene, durch try&error automatisiert die verschiedenen szenarien durchzuspielen, die bisher aus technischen oder wirtschaftlichen gründen ausser reichweite waren. die verknüpfung verschiedenster datenquellen kann somit über das bestehende datenmodell hinaus erfolgen, ohne dass die ein klassisches datenmodell verändert werden muss. durch transformationsprozesse werden genau die daten zur berechnung herangezogen, die dafür notwendig und sinnvoll sind.

das gängige werkzeug am markt nennt sich hadoop und wurde von yahoo in eigenregie entwickelt und ist seit 2007 ein teil der open-source-community. verschiedene dienstleister bündeln einige dieser frameworks und bibliotheken und sind mit ihren distributionen auch im kommerziellen sektor vertreten. die großen marken der it sind inzwischen auch vertreten und haben die kombination von relationalen und in-memory-datenbanken auch im großen stil im portfolio.

die ursprüngliche idee, legacy-hardware ( standard server / pizza boxen ) zu benutzen, um aufgaben zu lösen, für die vorher sechs- oder siebenstellige beträge notwendig waren, ist damit aber nicht vorbei. im gegenteil, die nutzung diverser resourcen im verbund ist immer noch zentrales argument. da die bisher verwendete hardware jedoch nicht für solch riesige datenmengen gedacht war, haben hersteller oder firmen wie facebook eine open-compute-initiative geschaffen, die server mit 24 und mehr festplatten in einem gehäuse möglich machen. da diese kategorie jedoch nicht mehr in die üblichen racks passte, wurde dort auch ein neuer standard geschaffen, der statt 19 zoll nun 21 zoll anwendung, die verschiedene verbesserungen mit sich bringen.

der ausgangspunkt für die sammlung solche riesiger datenmengen war im internet gegeben. durch suchmaschinen wurden immens viele seiten und damit daten zur bearbeitung, sichtung, indexierung, bewertung und zur verfügungstellung neu geschaffen. in sozialen netzwerken gab es themen und beiträge, die vorher kaum oder nur wenig miteinander verknüpft wurden.

selbst für große cluster gibt es auch heute noch aufgaben, die durch datenmodellierung von graphen erst erfassbar wurde ( kaufempfehlung als klassisches beispiel: leute die schuhe gekauft haben, kauften auch socken ). die verschiedenen mega- und metaebenen lassen sich mittels dieser technologie verknüpfen und ins verhältnis stellen, einhergehend mit diesem thema kam auch der begriff „nosql“ auf, da keine sequenziellen abfragen mehr gestellt wurden, sondern pipeline- oder baumartige abläufe die irgendwie miteinander verkettet waren.

ergebnis solcher analysen sind dann am ende ganz herkömmliche tabellen, wie man sie aus der tabellenkalkulation kennt, jedoch ist der unterschied, dass diese ein paar hundert millionen oder milliarden einträge lang sein können.

zusammengefasst: information overload industries™

cloud, english, this();

moreDNSEntries

as i had the wish to play with more then one server, i felt the need to configure the domain-name-service ( dns ) much more, then before.

my provider, where the usual webspace resides gave me access to the dns-infrastructure he had. that was cute, as i wasnt a reseller by fact and the need to maintain such things where another level of hosting configuration.

with that tool, to register a-records within the dns, i was able to build the cluster to cloud, with the ability to handle different sites for the different machines/server. i played with cdn.ioioioio.eu and other subdomains as the dataflow where handed-over between different services. several services were to handled by ip-addresses before, now i made that more niceley with names. that was a big step toward the idea of a cloud as the complexity was raising with each service and each instance.

the amount of subdomains and service-aliases raised quickly and i reduced them as i i wanted to keep the overview over the different things, that were hidden behind that curtain.

cloud, coding, english, this();

tomcatServer

as i have the rootServer, i can try and play niceley with my own coded stuff in java, running on tomcat. as the default-webserver just having the php stuff on it, i was looking for my own machine ( or at least for the chance to deploy my stuff ) since a long time.

with no big experience in the hosting field, iam not sure to put the tomcat naked onto the web, so i decide to hide the service behind a proxy/router. after i looked into the given examples, apache could be used therefore. thats to easy, i thought and i remembered some lighthttpd from my school, that one professor took for his page.

configuring the ports and the reverse-proxy was done quite quick, but having more then one subdomain means more then a single config-file. another thing is, that i want to play with load-balancing, so the config was done in three parts.  as example, the workflow of a domain like reporteer.ioioioio.eu

part 1:

reporteer.ioioioio.eu to localhost:80. the gateway with round-robbin load-balancing on a virtual host (server-0) in berlin and redirect to the server-1 in jena.

part 2:

redirect from port 80 on server-0 to server-1 port 80, where another lighty was running.

part 3:

redirect from port 80 to port 8080, where tomcat was running and targeting the servlet-path like http://server1:8080/reporteer/

caching on each layer for different filesizes and different file-types was done that way. as the commong filesize on the http level is mostly below 64 kilobyte ( to measure ) i passed files from the servlet between 64kb and 1mb as java-cache, smaller files on the lighty-instances, separated for images and js/css.  so, some css and some javascript ( lets say up to 8 ) per request was reasonable. a unbounded amount of images where handled by the servlet, beside tiny pictures, like thumbnails and icons.

so i felt a bit save for my tomcat, that exploits or my shity code wont run into a desaster for external incomming requests on port 80.  „the evil hacker“, who wanted to get inside the machine would have to overcome the multiple redirect-layers on the plain/vanilla web-server, to catch the tomcat. beside the fact, that i didnt used any php/cgi nor sql-engine, the chance to fail to quick was not my point anymore.

but the main aspect is, that i can run active code now on the machine. before that, i just made passive / xml based stuff with gwt to run on the vhost i had. now remote-procedure-calls ( rpc ) are possible, beside general httpRequest.