Afdrukvoorbeeld
Het probleem is dat wij vaak niet de ontwikkelaar zijn in dergelijke gevallen. Developers van klanten willen hier niet altijd in mee gaan (mijn vermoeden is gebrek aan kennis als voornaamste oorzaak). Met name daarom is er behoeft aan snellere processors (naast dat het in bepaalde gevallen leuk zou zijn als het 2x zo snel zou zijn en dat meer threads het niet altijd gaat versnellen).Citaat:
Oorspronkelijk geplaatst door Apoc
Auwwww .Citaat:
Oorspronkelijk geplaatst door systemdeveloper
Als je twee keer achter elkaar een munt op gooit, heb je geen _garantie_ dat er een kop bij zit.
En als je tien servers in een rack hangt, die elk een kans van 1/10 hebben om kapot te gaan, heb je geen zekerheid dat er één kapot gaat.
Oftewel, je moet de kansen niet optellen.
Als de kans dat een server uitvalt p is, is de kans dat de server _niet_ uitvalt (1-p ).
De kans dat een set van n van die servers allemaal niet uitvallen is dan (1-p)^n .
Als de servers gelijke uitvalkansen hebben , is de kans op uitval van de single server kleiner dat de kans op 'minder dan 100%' capaciteit in het cluster.
Daarintegen is de kans op totale uitval van het cluster (alle drie tegelijk uitgevallen) wel kleiner (p^3 ) dan de kans op totale uitval van de single server (p).
Ik heb het zitten uitschrijven voor twee componenten, met uitvalkans <p> , tussen één set van twee , en twee sets van twee.
Ik dacht aan voedingen, waarvan ik stel dat zowel de single server een redundante config heeft, en dat twee losse servers ook elk een redundante voeding hebben.
En dan zoek ik de kans dat er service impact is vanwege het uitvallen van een x-tal voedingen.
In het geval van de single server is er uitval (tgv van een voedingsprobleem) met kans p^2 .
Bij de twee losse servers wordt het al veel schrijfwerk. totale uitval (4 voedingen kapot), 50% uitval gegarandeerd (3 voedingen kapot) , en 2/6 kans 50% uitval (2 voedingen kapot ) .
Als ik me niet vergist heb, kom ik op een kans van p^2*(2-p^2) op "minder dan 100% capaciteit" (dwz - meer dan nul servers down) .
. Bijna twee keer zo groot als het geval van de single server, maar daarintegen is de grootste bijdrage aan die faalkans de situatie met één server down, en is de kans op beide servers down veel kleiner .
Een versie voor drie servers wordt helemaal veel schrijf/rekenwerk.
Voor een component als een voeding durf ik nog wel te verwachten dat de kans op falen niet zo erg zal verschillen tussen de voeding voor een grote single server versus die voor een wat kleinere server .
Faalkansen tussen redelijk standaard technologie als dual-quad core borden versus cutting edge 60-core systemen zullen denk ik niet vergelijkbaar zijn.
Samenvattend : is alles minder dan 100% even slecht, ben je het beste af met zo min mogelijk componenten die kunnen falen.
Kun je overweg met 'degraded service' als een deel van de componenten uitvalt, dan kun je je kans op totale uitval veel kleiner door de hogere kans op 'enige uitval' te accepteren , die je krijgt wanneer je service verspreid over meerdere componenten draait.
Aangenomen dat de foutkansen in beide opties gelijk zijn.
Dat kan zijn, maar dan nog zou het niet logisch zijn als fabrikanten zouden gaan inzetten op anticipatie van het gebrek aan innovatie vanuit ontwikkelaars. Dat is ongeveer hetzelfde als wanneer je het wegennet zou gaan aanpassen op slecht onderhouden auto's. Als de infrastructuur al goed is, dan zou het onlogisch zijn om die infrastructuur aan te gaan passen op inefficiënte gebruikers.Citaat:
Oorspronkelijk geplaatst door Mark17
Leg dat eens nader uit? Ik kan namelijk geen enkele toepassing bedenken waarin dat nuttig zou kunnen zijn (behalve zaken als kwantummechanica, maar daar worden geen reguliere processoren voor gebruikt - of zaken als grafische/encryptie toepassingen, en daar worden ook geen reguliere processoren voor gebruikt). Voor reguliere toepassingen lijken snellere processoren me vrij nutteloos, behalve wanneer een applicatie niet horizontaal kan schalen (hetgeen een tekortkoming van de applicatie is, niet van de processor).Citaat:
Oorspronkelijk geplaatst door Mark17
Het lijkt mij in ieder geval totaal niet logisch om een tekortkoming van een applicatie te willen compenseren met iets anders dan een verbetering van die applicatie zelf.
Hehe, ik stond al op het punt om een stukje over kansberekening te schrijven, maar ik zie dat visser me al voor was.Citaat:
Oorspronkelijk geplaatst door systemdeveloper
Om nog even een simplistisch voorbeeld te nemen: stel je hebt 10% kans dat een specifieke server vandaag uitvalt. Als je 10 van die servers hebt, dan is het niet alsof er een 10x10% = 100% kans is dat er vandaag uitval zal zijn.
Sommige taken moeten perse (volgens de ontwikkelaar) in een bepaalde volgorde uitgevoerd worden. Daar zou het grootste voordeel te behalen zijn met snellere processors. Dat gaat dan niet specifiek om (web)hosting gerelateerde toepassingen.Citaat:
Oorspronkelijk geplaatst door Apoc
Haha, nee, zo bedoelde ik het ook niet. Bij 1 server heb je 10% kans dat ie plat is, bij 3 servers heb je 0,1% kans dat ze ALLEMAAL uitvallen, maar altijd nog een fikse kans dat minimaal één van de drie uitvalt. (Namelijk 1 - de kans dat ze alledrie NIET uitvallen ~ en dan zit je bij 3 servers en dit voorbeeld percentage van 10% toch al snel op ruim 27%).Citaat:
Oorspronkelijk geplaatst door Apoc
Of en hoe dit verder van toepassing is op je platform als geheel is dan weer afhankelijk van de load van alle bakken en/of de resterende bakken de boel kunnen opvangen.
Zorgen dat bestaande software goed genoeg/niet slechter draait op een nieuwe architectuur is een succes strategie gebleken.Citaat:
Oorspronkelijk geplaatst door Apoc
En hoe afwijkender in programmeermodel/architectuur een nieuwe innovatie was, des te kleiner de kans op overleven.
Zelfs in niches als HPC waar tenminste hercompileren niet te veel gevraagd is, heeft uniformiteit nogal toegeslagen.
Maar ook dan is echt herschrijven, eventueel in een andere taal wel veel gevraagd.
Inderdaad is bij een nieuwe (processor) microarchitectuur 'niet slechter op bestaande code stijlen' een heel belangrijk criterium.
Het 'deprecaten' van instructies of manieren van gebruik duurt heel lang.
Zoek op 'A20 gate' voor een symbiose van software en hardware evolutie waar 'iedereen' vanaf zou willen ware het niet dat ...
Ik dacht eigenlijk dat grote databases al een standaard voorbeeld waren van applicaties die, zo niet een single CPU dan wel een single-image SMP server nodig hebben om optimaal te draaien.Citaat:
Oorspronkelijk geplaatst door Apoc
Allerhande 'grote simulaties' (niks speciaal met quantum) [weer, vloeistof, constructies] hebben vzviw ook het liefst zo krachtig mogelijke CPUs, en een heel directe koppeling tussen verschillende processing nodes.
Verder, zie 'Amdahls law' waarbij de limiet voor parallelle speedup heel snel beperkt wordt door een enkele seriële stap.
Daarmee wil ik niet zeggen dat er aan de applicatie kant geen laaghangend fruit meer zou zijn, maar sommige dingen zijn wel fundamenteel moeilijk.
Overigens kan ik voor webhosting eigenlijk geen voorbeelden verzinnen waar reusachtige single-servers echt noodzakelijk zouden zijn.
Uiteraard, maar dat is niet waar ik op doelde. Waar ik het over had is dat het me onlogisch lijkt om voor bestaande software die op bestaande infrastructuur al niet lekker draait (als gevolg van inefficiënte code), nieuwe infrastructuur te ontwerpen die dat (enigszins) compenseert. Dat is namelijk gewoon symptoombestrijding - m.i. is het logischer om simpelweg de oorsprong van het probleem aan te pakken.Citaat:
Oorspronkelijk geplaatst door visser
Dat zullen - denk ik - in de meeste gevallen toch ook beperkingen van de software zijn. Uiteraard begrijp ik dat dit soort software vaak niet 1 2 3 even aan te passen is, maar op termijn zal dat toch echt de enige oplossing zijn. Je kan niet eindeloos in de hoogte schalen, wel in de breedte. Ik kan in ieder geval geen reden bedenken waarom er noodzaak zou zijn om voor de applicaties die je beschrijft alles in een single thread uitgevoerd zou moeten worden (buiten tekortkomingen in de code). Ik zou er natuurlijk volkomen naast kunnen zitten.. ik ben eigenlijk op zoek naar een specifieke proces beschrijving van een relatief veelvoorkomende toepassing waaruit duidelijk wordt dat het een technische vereiste is dat er maar 1 thread gebruikt kan worden.Citaat:
Oorspronkelijk geplaatst door visser
Om even heel eenvoudig te omschrijven wat ik bedoel:
Stel een thread wil de rekensom 2*4+5*3 oplossen. Je zou dan 2*4 door 1 thread kunnen laten berekenen en 5*3 door een andere thread, en de uitkomsten daarna samenvoegen. De tekortkoming van veel applicaties waar ik op doel, is dat ze niet met dergelijke horizontale schaalbaarheid in het achterhoofd zijn ontworpen, waardoor zeer complexe berekeningen allemaal in 1 thread afgehandeld moeten worden (waardoor je dus enkel in de hoogte zult moeten schalen). En als dergelijke berekeningen steeds complexer worden, dan zul je dus feitelijk keer op keer meer snelheid nodig hebben. Voor de lange termijn is het aanpassen van de code voor horizontale schaalbaarheid dan veel logisch
In mijn eerste reactie doelde ik daar ook op, aangezien we hier tenslotte toch op een webhosting forum zijn en er specifiek "heilige graal van cloud" genoemd werd in het artikel. Maar ook in algemene zin denk ik dat er uiteindelijk zeer weinig applicaties zijn die niet in de breedte kunnen schalen (en met "kunnen" bedoel ik dan of het technisch gezien mogelijk zou zijn, niet of een applicatie het ook daadwerkelijk ondersteunt).Citaat:
Oorspronkelijk geplaatst door visser
Als dat kan, is dat zeker logischer ja.Citaat:
Oorspronkelijk geplaatst door Apoc
Een deel zal inderdaad gewoon inertie zijn, of een lokaal maximum (ie,investering, periode van extra bugs voordat er rendement uit een rewrite komt) en voor een ander deel ontbreekt gewoon een idee of de mogelijkheid.
Ik begrijp wat je bedoelt, maar m.i. ontbreekt voor een aantal toepassingen toch gewoon een algorithme.Citaat:
Oorspronkelijk geplaatst door Apoc
Er worden nog steeds een hoop supercomputers verkocht die vooral proberen om zo veel mogelijk CPUs die strak mogelijk te koppelen . Die worden verkocht in sectoren die eigenlijk nooit genoeg processing power hebben, en geld als water (of - geld als olie - seismische data verwerken is zo'n toepassing.).
Als je die toepassingen 'net zo goed' zou kunnen schalen over willekeurig veel rijen van kasten, in plaats van over die mega server met 128/512/1024 cores lopen ze je deur plat.
Je hebt hopelijk een link gezocht naar Amdahl's law ?
zie bv http://en.wikipedia.org/wiki/Amdahl%27s_law
Ook al kun je een aantal stappen paralleliseren, geeft elke seriële stap je snel een bovengrens aan de bereikbare versnelling.
In jouw voorbeeld is de seriële stap het samenvoegen .
Ik heb zo geen voorbeeld van 'technisch belangrijke' (wanneer noem je iets zo) algorithmen die inherent (of - niet bekend) 100% sequentieel zijn.
Wel dus aantal toepassingen met veel onderlinge communicatie die grote SMP systemen nodig hebben, en niet schalen op veel losser gekoppelde nodes.
Met wat google werk vind ik oa:
http://en.wikipedia.org/wiki/P-complete
http://scicomp.stackexchange.com/que...that-cannot-be
http://en.wikipedia.org/wiki/Parallel_algorithm
https://plus.google.com/+RichardFabi...ts/62wVd9ZoRqC
Illustratie met Fibonacci getallen parallel berekenen : (0,1,1,2,3,5,8 ... )
http://trigonakis.com/blog/2011/02/2...hms-fibonacci/
Ik vermoed dat ook database queries vrij snel een complexiteit hebben waarbij de sql engine de query sequentieel moet uitvoeren.
Het lijkt me analoog aan een compiler die moet auto-vectoriseren .
Als de cpu beschikt over meerdere rekenunits (of een volledige vector feature zoals SSE ) kan de compiler daar gebruik van maken, maar alleen zolang de compiler kan bewijzen /afleiden dat de data niet onderling afhankelijk is.
http://en.wikipedia.org/wiki/Vectori...l_computing%29
Een programmeertaal kan hier verschil maken, wanneer die een syntax biedt waar de compiler de aanwijzing en garantie krijgt dat een berekening gevectoriseerd mag worden.
Ik denk dat een SQL engine vergelijkbare uitdagingen heeft om data (on)hankelijkheid af te leiden, en dus voor de vraag of een query tegelijk van meerdere cores gebruik kan maken.
(google - yup. genoeg blogs en tips hoe de aanpak van sql engines te bekijken en tunen )
Anyway, deze posting is me lang genoeg geworden. Boeiend (vind ik), maar de typische schaling van hosting gebruik zit niet met deze vragen.Citaat:
Oorspronkelijk geplaatst door Apoc
Soms met enigszins vergelijkbare vragen, maar die zijn vaak nog prima oplosbaar door 'slechts' de applicatie grondig te herschrijven. Een design met een single (actieve) backend database kan al heel veel redesign kosten om naar <n> actieve (inc. write) databases te gaan.
Kijk, zo'n inhoudelijke reactie, top :)
Ik heb momenteel geen tijd om in detail naar alle linkjes te kijken, maar zal dat een dezer dagen eens doen. Wilde ondertussen nog wel op 2 puntjes reageren:
Daar ben ik me inderdaad van bewust. Simpel gezegd is het hetzelfde als wanneer je de overweging moet maken om bepaalde taken aan anderen te delegeren, of dat je het zelf doet omdat het relatief veel werk is om de taak aan een ander uit te leggen.Citaat:
Oorspronkelijk geplaatst door visser
De applicatie hoeft daarvoor (in dit specifieke geval) niet te worden herschreven. Je kan daarvoor simpelweg een database cluster gebruiken wat er vanuit het perspectief van de applicatie gewoon uitziet als 1 enkele SQL server (dmv decentrale loadbalancer). Eveneens een relatief eenvoudige methode van horizontale schaalbaarheid die al snel interessant is ten opzichte van alsmaar snellere hardware nodig te hebben. Vooral omdat je bij horizontale schaalbaarheid de bestaande hardware simpelweg kunt blijven gebruiken en bij verticale schaalbaarheid vaak niet.Citaat:
Oorspronkelijk geplaatst door visser
Dat is m.i. sowieso de toekomst. Of alle benodigde software en algoritmen er al voor bestaan of niet; het is de enige aanpak die op lange termijn kan werken. Dat is ook waar ik op doelde in de zin van dat het me voor fabrikanten in veel gevallen niet logisch lijkt om in te zetten op alsmaar snellere hardware. Er kan m.i. juist beter ingezet worden op het verbeteren van de snelheid waarmee processen opgesplitst kunnen worden voor parallelle uitvoering.Citaat:
Oorspronkelijk geplaatst door visser