Azure te gebruiken voor berekeningen / exports

[Gomez12]

Wij hebben een aantal (100) gelijkende exports die in de batch lopen en die erg cpu-intensief zijn om te maken, vanwege dat het nu op 1 machine draait zitten we te knoeien met de tijd (batch loopt momenteel na tig optimalisaties 8 uur, maar heeft ook weleens >24 uur gelopen)

Nu kwam iemand aanzetten met dat we als we die db eenmalig (per dag) naar azure zouden zetten dat we dan gewoon 10 vm's zouden kunnen opzetten en dat we dan binnen ongeveer 1 uur klaar zouden zijn. (Of voor mijn part zetten we 100 vm's op, aangezien het per minuut afgerekend wordt is het niet zo boeiend)

Nu zit ik even te kijken maar waar ik op uitkom qua prijzen is dan echt een paar euro per dag.
Want als we voor de 100 instanties zouden gaan (die dan gemiddeld zo'n 10 minuten zouden draaien) dan zit je echt te kijken naar prijzen van 0,068 per uur dus grofweg gezegd 2 cent voor 10 minuten gebruik per vm.

Zie ik iets over het hoofd, zijn er ergens verborgen kosten (inkomend dataverkeer is gratis uitgaand kost wel iets, maar dat is ook niet echt relevant)?

Want als er geen verborgen kosten zitten dan zou Azure toch een perfect platform zijn voor het paralleliseren van taken (want ik hoef geen machine 24 u/dag aan te hebben in azure, ik heb 1 job voor 1 vm)

Wie o wie heeft heeft hier ervaring mee en kan vertellen of wat ik uitreken goed/fout is (zit er bijv een verborgen starttarief ergens in dat een vm een half uur duurt om op te starten oid)

[F_J_K]

Heb je wel genoeg aan 1 core en vooral genoeg aan <2GB intern geheugen? Check ook of je genoeg schijfopslag hebt voor applicaties + data (en reken even uit hoelang de dagelijkse upload duurt). En of de eventueel benodigde licenties het toestaan. Voor zo ver ik weet is er geen opstarttarief.

It never hurts to try. Mits je de kosten in de gaten houdt en niet vergeet te checken dat de machine echt is gestopt en gedealloceerd

Weet je zeker dat er geen kosten zijn voor uploads naar Azure? Er zijn bij de Storage-dienst AFAIK nog wel kosten per 100k transacties.

[Gomez12]

Vermoedelijk hebben we genoeg aan 1 core en <2GB intern geheugen, maar dat zal idd een kwestie van testen zijn.
Schijfopslag zien we niet direct als een probleem (We moeten altijd nog 1 dikke vm pakken voor de dbase instantie en de rest hierop laten wegschrijven lijkt ons)
En licenties zitten afaik gewoon in Azure ingebakken want voor de rest is het allemaal onze eigen programmatuur.

En tja, proberen... We schatten dat het wel een uurtje of 400 kost om het compleet op te zetten (exports moeten anders, er moet een compleet command & control center gebouwd worden om die 100 VM's te starten en te monitoren en desnoods te stoppen etc)

Het gaat ons meer om of we gewoon iets van 100 vm's voor een kwartier / half uur de lucht in kunnen gooien en dan iets van 6 euro moeten betalen voor alle 100, dat klinkt ons gewoon heel erg apart in de oren.
Dat zou neerkomen op een kleine 200 per maand en daarvoor kunnen wij geen server de lucht in gooien (en komen we met een server nog in de problemen omdat je dan weer tegen 8 uur oid zit aan te kijken ipv 30 minuten oid)
Wellicht dat het is doordat wij "perfect" paralliseerbare jobs hebben, maar wij zijn gewoon bang dat we ergens wat kosten missen die ons later gaan bijten als wij eerst xxx uur hebben besteed aan het omzetten hiernaartoe.

[Jazzy]

Ik denk (!) dat je berekening wel klopt, zeker als je de machines na zo'n korte tijde alweer stopt. Dat 'complete command and control center' bestaat trouwens uit één eenvoudig PowerShell scriptje, in ieder geval wat de Azure-kant betreft.

De vraag is vooral even of je aanname over het parallel uitvoeren klopt, maar dat kun je zelf beter inschatten. Kijk dan ook even of je liever 100 machine met één core hebt of toch beter 25 machines met 4 cores. En het werken met grote bestanden is in de praktijk ook wel wat lastig, moet je die exports daarna dan niet downloaden? Of is dat maar een rapportje oid, want anders heb je wel wat uitgaand dataverkeer om mee te rekenen.

[Gomez12]

Jazzy schreef op donderdag 12 december 2013 @ 14:03:
Ik denk (!) dat je berekening wel klopt, zeker als je de machines na zo'n korte tijde alweer stopt. Dat 'complete command and control center' bestaat trouwens uit één eenvoudig PowerShell scriptje, in ieder geval wat de Azure-kant betreft.

Simpel powershell scriptje gaat niet volstaan (we willen ook error-reporting, status etc weten en we hebben nu 1 monolitische export gewoon 100x aangeroepen wordt en die omgebouwd zal moeten worden naar parallel etc)

De vraag is vooral even of je aanname over het parallel uitvoeren klopt, maar dat kun je zelf beter inschatten. Kijk dan ook even of je liever 100 machine met één core hebt of toch beter 25 machines met 4 cores.

Dat gaat idd een kwestie van testen worden, maar aangezien wij het grootste ombouwwerk verwachten in de jobrunner taak willen we het zo maken dat het daarna niet echt uitmaakt of we nu voor 100 vm's kiezen of voor 25 vm's (die 4 taken uitvoeren parallel of niet). Daadwerkelijk 100 vm's die in 1x de data voor de exports uit de dbase server gaan trekken zie ik ook niet echt zitten en momenteel kost het 8 uur dus in theorie als 4 vm's het straks in 4 uur trekken dan zijn we nog steeds 50% opgeschoten.

Het ging voor nu even om een inschatting van de kosten, op het moment dat er nu hier 10 man opdoken die zeiden : Je vergeet kosten x/y/z en daarmee krijg je een vervijfvoudiging van de kosten.
Simpel gezegd, bij een vertienvoudiging van de geschatte kosten hoeven we nog niet eens verder te kijken naar wat het kost om het allemaal om te bouwen

En het werken met grote bestanden is in de praktijk ook wel wat lastig, moet je die exports daarna dan niet downloaden? Of is dat maar een rapportje oid, want anders heb je wel wat uitgaand dataverkeer om mee te rekenen.

Gemiddelde eindexport (gezipt) is in de grote van 5 of 10 mb dus dat zijn nou ook weer niet de kosten (15/30GB per maand en 50GB kost 50 euro extra oid) en bovenal staan onze huidige servers ook al in een datacenter waar we ook al dataverkeer betalen (in dezelfde orde van grootte)

Het achterliggende idee is niet dat we 300 exports aan willen kunnen (daar kunnen we nog wel ijzer voor neerzetten) maar meer dat we verwachten dat we binnen nu en 2 jaar 2000 exports moeten gaan maken en daar hebben we heel snel heel veel flexibele schaling voor nodig en ijzer is daar niet altijd het beste voor (iets met verwachting en werkelijkheid etc)

[Jazzy]

Dan zou ik gewoon een proefabo aanmaken en starten met een kleine proof-of-concept. Ziet er heel interessant uit allemaal.