Torben Mogensen header

Giver Skyen regnvejr?

En af de store tendenser for tiden er "Skyen" (The Cloud): Ideen om at firmaer og privatpersoner lægger deres data på servere hos firmaer, der udbyder plads, regnekraft og applikationer. Eksempler er Google Docs, Office 365, Amazon Cloud og mange flere.

Som jeg skrev i et indlæg for et par år siden, er ideen ikke ny: For 18 år siden satsede Oracle på at udbrede skyen til private som et alternative til den traditionelle PC, men satsningen fejlede dels på grund af en halvhjertet indsats og dels fordi infrastrukturen ikke var til stede. Selve ideen bag skyen går endda mindst tilbage til 1961.

Skyen har en masse fordele for brugerne: Backup, vedligeholdelse, opgradering og skalering klares af udbyderen, så man kan koncentrere sig om brugen. Og skyen er tilgængelig alle steder, man har en internetforbindelse, så man får mobilitet med nærmest gratis. Men der er også ulemper:

  • Lokal regnekraft er billig, så for beregningstunge ting kan skyen være en dyr løsning -- i hvert fald hvis man hele tiden skal bruge meget regnekraft.

  • Internetforbindelsen kan være en flaskehals: Selv med en hurtig internetforbindelse kan svartider blive langsomme. Det skyldes dels, at TCP-protokollen ikke er ideel til formålet, at pakketab øges med afstanden, samt den ufravigelige grænse for lysets udbredelseshastighed: Det tager ca. 0.07 sekunder for lyset at nå halvvejs rundt om jorden, og hvis man skal en tur forbi et par geostationære satellitter, øges tiden til omkring 0.4 sekunder. Så der skal ikke ret mange håndtryk til, før det tager over et sekund for en pakke af data at nå frem.

  • Dertil kommer sikkerheden: Når dine data farer rundt på Internettet, risikerer du nemt, at de bliver opfanget og -- endnu værre -- måske endda modificeret. En sikring mod dette kræver stærk kryptering, som koster i regnekraft og svartider. Derudover skal du kunne stole på, at udbyderen opbevarer dine data forsvarligt og fortroligt. Lovgivningen sætter også grænser for brug af skyen til personfølsomme oplysninger.

  • Og til sidst er der spørgsmålet om, hvad der sker, hvis udbyderen går konkurs: Vil du miste adgang til dine data (midlertidigt eller permanent)? Kan en evt. ny ejer skrue prisen i vejret og holde dine data som gidsel, indtil du betaler?

Så det er ikke nogen oplagt eller nem beslutning for et firma (eller en privatperson), om Skyen er den rigtige løsning. Blandt andet derfor har DIKU lavet et arrangement om Skyen og dens fordele og ulemper. Men jeg er helt sikker på, at I også har nogle meninger om sagen.

Kommentarer (16)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#3 Daniel Udsen

Skyen's akilleshæl har fra starten været I/O og i dagens private skyer er det også storage delen der giver de største hovedpiner. og selv idag er båndbrede(især upstream) en stor nok udgiftspost til at lægge begrænsninger for den offentlige sky.

Det anden store problem handler om ejerskab i skyen ejer du ikke og er stillet juridisk meget svagere over for f.eks. myndighedsmisbrug osv end uden for skyen, der skal meget stærkere argumenter til før du kan nægtens privatliv eller adgang uden for et lokalt system end for skyen. Denne problemstilling kan ikke reduceres til teknisk sikkerhed, og har ligeså meget af gøre med det "frivillige" samarbejde der er mellem stat og ehversliv, som konkret jura.

  • 1
  • 0
#4 Hans Andersen

Du mangler også:

Lockin...... Hvor nemt er det at skifte fra a cloud til b cloud.... Sletning af data: Hvis du for til opgave at slette noget data, hvordan sikre du dig, at det ikke komme og bider dig i bagdelen senere.

Her er et uddrag af Podios SLA:

  1. Service Level

Podio will at all times reasonably attempt to achieve the highest possible availability and shortest possible access time of the Service, but no warranties of any kind, regarding any specific availability or time of access are granted. The Service is hosted by Citrix, or a subcontractor of its choice. All data stored as part of the Service may be backed up on a regular basis. If Customers with a paid service plan experience loss of data, Citrix may use reasonable efforts to attempt to restore data from the most recent working backup; provided, however, Citrix gives no warranties with respect to recovering or restoring any lost Customer data. The User or Customer is always encouraged to make its own backups of all data stored on the Service.

og

  1. Data

Citrix does not own any data, information or material that You or others submit to the Service in the course of using the Service ("Uploaded Data"). You shall have sole responsibility for the accuracy, quality, integrity, legality, reliability, appropriateness, and intellectual property ownership or right to use any and all Uploaded Data that You submit. Citrix shall not be responsible or liable for the deletion, correction, destruction, damage, loss or failure to store any Uploaded Data.

Ja det siger alt

  • 2
  • 0
#6 Jesper Louis Andersen

Ad 1: Lokal regnekraft er ikke altid billigt. Hvis du sidder med et mobildevice på batteri har du ikke lyst til at det tager klokcykler. Det er også nogen gange problematisk med lokal regnekraft fordi det ikke kan opgraderes løbende når behovet bliver større. Og det kan nogengange være ganske irriterrende. Der er et stort potentiale hvis du kan lave noget Grid-agtigt, men jeg ser det faktisk som en fordel at samle data et sted hvor du har massiv regnekraft tæt på.

Ad 2: Hvorfor er TCP-protokollen ikke ideel til formålet? Hvad tænker du konkret på er problemet med den? Og pakketab er ikke et problem for TCP. Du skal have pakketab for at protokollen fungerer korrekt. Faktisk forholder det sig omvendt: Fordi vi ikke har pakketab på nettet i dag, men laver store buffers, så har vi problemer. Se "bufferbloat" (Jim Gettys, Kathie Nichols, Van Jacobsen).

Skyen er ikke interessant fordi den er billig. Den er hundedyr. Men det interessante er at du kan skalere den linært op efterhånden som du får et større behov. Elasticitet er en langt vigtigere grund og faktor. Mange virksomheder har perioder hvor de laver beregninger og andre perioder hvor der ikke er nogen synderlig belastning. At de kan 3-doble din kapacitet i 2 timer kan være meget nyttigt. Du kan for eksempel lancere et nyt produkt, skalere kapaciteten, og så rette performancebugs. Efterhånden som de bliver rettet kan du så skalere ned igen.

  • 2
  • 1
#9 Stephen Alstrup

TCP håndterer pakketab, og derfor som sådan godt til pakketab Men den måde standard anvendelser af TCP klarer pakketab på, nedsættes hastigheden af forbindelsen kraftigt i forhold til mere avancerede teknikker. Et par generelle formler er angivet på Wikipedia: http://en.wikipedia.org/wiki/TCP_tuning#TCP_speed_limits.

Jeg har flere gang siddet i én ende (Asien) med 100mbs upload og kommunikeret med en maskine i en anden ende (Europa) med 1gbps, hvor maks. forbindelsen alligevel har været få kbps netop på grund af pakketab m.m., og hvor det med mere avancerede teknikker har været muligt at få mange mbps igennem.

Med Cloud løsninger, hvor der bruges standard TCP internetforbindelse, giver det derfor god mening at tænke over, om denne eventuelle forøgelse af afstanden mellem bruger og data er en udfordring med hensyn til hastigheden af datatransmissionen

  • 1
  • 0
#13 Carsten Jørgensen

Hvad er en cloud server? jeg har adskillige servere stående rundt omkring ude i verden, jeg taler næsten altid med den over ssh (+evt portforward (postgresql databaser)) og sshfs er det en cloud server ?

Cloud er veldefineret, se http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf

Cloud er ikke en teknologi som SSH, det er en drifts- og leverancemodel. Hvis dine servere ude i verden - uden du kontakter leverandøren, kan gå fra at være "adskillige" til f.eks. "500 ekstra servere på 8 minutter" (som Netflix gør). Og hvis du kan slukke for dem alle sammen efter to timer, uden at skulle betale mere end for de to timers brug, så er det cloud.

Men et af de vigtigste spørgsmål er selvfølgelig hvilke API'er du har til dine servere? "Lego-opbygningen" er den vigtigste del af cloud computing.

Ikke nok med at man skal overveje udbyderens generelle sikkerhed - men ligeledes ens, som kunde, rettigheder i forhold til myndighederne i hostlandet (FISAAA).

Selvfølgelig, men det skal man jo også selvom det ikke er cloud computing.

  • 1
  • 0
#16 Jesper Louis Andersen

Jeg har flere gang siddet i én ende (Asien) med 100mbs upload og kommunikeret med en maskine i en anden ende (Europa) med 1gbps, hvor maks. forbindelsen alligevel har været få kbps netop på grund af pakketab m.m., og hvor det med mere avancerede teknikker har været muligt at få mange mbps igennem.

Det luger mere af en fejlkonfiguration af en moderne TCP-stak end det lyder som om det er et problem med TCP. Ok, har du mere end 1% pakketab, så findes der helt sikkert bedre løsninger. Men har du mere end det, så har du et andet problem forudsat at dit netværk er nogenlunde stabilt. Som skrevet, handler det om at have et tilstrækkeligt stort vindue så latency bliver skjult og ikke som skrevet, så er det formentlig en fordel med SACK i det tilfælde.

Pointen er bare at du sjældent ser bare 1% pakketab i moderne netværk.

  • 0
  • 0
Log ind eller Opret konto for at kommentere