Schlagwort-Archive: cluster

crunching on arm

as far as it looks like, iam not the only one, crunching on arm. dzone got a article from thailand, where some guys connected 22 cubieboards, runinning apache spark, for in-memory-computation.

but ive seen the bottleneck of a 100 mbits network connector on cubieboard pretty much earlier. so ive decided to buy the cubietruck, which includes a 1 gbits adapter, which brings theoretically 128 mbyte/s a sata drive for saturation.

a cluster from france was presented before on cubieboard.org with the same idea, to fit as many cubieboards within a standard rack server enclosure, as possible.

i calculated 8 cubieboards in a 1 he server rack as maximum amount of boards and hard discs last year. the price is then something like 1600-2000 € for the hardware. for that price tag, the memory of 16 gb ram and 16 tb of hdd is not that much, but the theroretical bandwith between the nodes ( within the cluster ) is something like 8 gbits 🙂

8 nodes
8 boards in a 1 he standard rack server

the picture above shows the former choosed boards from hardkernel, called odroid, but the price for that board is above the budget, so i sized it down to a dual-core, from the quad-core.

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.

 

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