Amazon gaat 100PB-containers per truck vervoeren voor klanten

Amazon heeft AWS Snowmobile onthuld. Dit is een dienst om grote hoeveelheden data fysiek te kunnen vervoeren. Het bedrijf biedt de mogelijkheid tot aan 100 petabyte per verstevigde container met een truck te verplaatsen.

De dataoverdracht verloopt via een container van bijna 14 meter lang en bijna 3 meter hoog. De Snowmobile-truck komt naar het datacenter van de klant rijden waarna het AWS-personeel zorgt voor de koppeling van de container als netwerkopslag. Er is twee kilometer aan netwerkkabel aan boord voor de connectie met de backbone van het rekencentrum.

Bij de maximale bandbreedte van 1Tb/s, duurt het tien dagen voor de volledige opslagcapaciteit van 100PB bereikt is. Voor klanten met lage bandbreedte raadt Amazon aan om grote hoeveelheden data in delen over te brengen, bijvoorbeeld met de eerder aangekondigde Snowball-dienst, die data via kisten van 50TB vervoert.

Bij Snowmobile worden de gegevens met 256bits encryptie versleuteld; klanten kunnen hun sleutels beheren via de AWS Key Management Service. Alleen AWS-personeel krijgt toegang tot de container, belooft Amazon, en er is videobewaking en een alarmsysteem aanwezig. Daarnaast garandeert het bedrijf gps-tracking en is er de mogelijkheid voor een optionele beveiligingsescorte. De prijzen maakt Amazon nog niet bekend.

Helaas!
De video die je probeert te bekijken is niet langer beschikbaar op Tweakers.net.

Reacties (139)

[jimbo123]

Ok, even zien of ik het begrijp.

- We wachten 10 dagen tot de vrachtwagen volgeladen is met 100PB aan data
- De vrachtwagen gaat rijden naar bestemming (1 dag?)
- We wachten 10 dagen tot de data weer is uitgeladen op bestemming.

En in de tussentijd muteren we die data gewoon 21 dagen niet? We accepteren 21 dagen downtime?
Nee natuurlijk niet, we gaan later de wijzigingen synchroniseren. Ja, gewoon. Even 100PB op verschillen controleren en synchroniseren. Hoe dan?

Bovenstaand gaat nog uit van 100PB, wat al absurd veel is.
In het filmpje hebben ze het over een exabyte, en geven ze aan dat dit 6 maanden duurt om te verplaatsen.

Je moet dus over erg statische data beschikken om dit te kunnen doen, of je moet in staat zijn om wijzigingen apart bij te houden en eenvoudig later te synchroniseren.

Denk dat dit al met al een enorm niche service is en dat ze die vrachtwagen veel stil gaan zien staan zonder enige inzet bij klanten.

[dasiro]

even rekenen
100PB = 100.000TB = 100.000.000GB
100.000.000
/2 (1x up- en 1x down)
/10 dagen
/24 uur
/60 minuten
/60 seconden
= 57GB/s
veel succes om zo'n lijntjes te trekken voor eenmalig gebruik

[Stoney3K]

"Never underestimate the bandwidth of a station wagon full of tapes hurtling down the highway!" -- Andy Tanenbaum

Ideale oplossing voor mensen die gigantisch veel data moeten vervoeren maar waarbij latency niet uitmaakt.

Uiteraard verplicht leesvoer: https://what-if.xkcd.com/31/

[Reactie gewijzigd door Stoney3K op 26 juli 2024 19:35]

[-Dream]

http://www.packetlight.com/products/100g-dwdm-solutions/

100GbE over 2500km.
Niet dat je hier wat aan hebt behalve als je Microsoft of Google heet ofzo.

[Byron010]

100 Gb > Giga bit.

Dus nog even door 8 delen = 12.5 GB/s vs 57GB/s

[-Dream]

Als je die kabel een maal hebt liggen maakt dat allemaal niet zoveel meer uit heh.

Of je moet meer dan 12 GB aan data produceren per seconde, maar dan produceer je in een dag ook al meer dan een PB aan data. En dan denk ik niet dat deze dienst van Amazon nog heel aantrekkelijk is en dat je beter voor twee kabeltjes ofzo kan gaan.

[Gomez12]

Deze dienst is dan ook niet geschikt voor continu gebruik.

En voor eenmalig gebruik leg je die kabel niet even neer...

[Mopperman]

zeker niet onhaalbaar, maar ligt aan de techniek....

[Byron010]

Met de 12x links van 2014 zit je op ongeveer 36GB/s. Misschien dat die van 2017 het wel zou halen

(290 Gigabit / 8 = 36.25 GigaByte)

[Mopperman]

je kan natuurlijk ook 2x 12x gebruiken

[Resistor]

Wat dacht je van telescopen in erg afgelegen gebieden? Daar trek je niet even een datakabel naartoe.

Jaar lang even fotootjes maken van de ruimte, data in de vrachtwagen, en dan naar een wat comfortabeler plek (met betere computers) om te analyseren wat je nou eigenlijk op de foto hebt gezet.

[Gemeijer]

Idd
According to the CSIRO, in the next decade, astronomers expect to be processing 10 petabytes of data every hour from the Square Kilometre Array (SKA) telescope.[11] The array is thus expected to generate approximately one exabyte every four days of operation. According to IBM, the new SKA telescope initiative will generate over an exabyte of data every day. IBM is designing hardware to process this information.

[TD-er]

Die SKA zal uiteindelijk ongeveer 1.25 PByte per etmaal per locatie (2 locaties) aan al voorbewerkte data naar een ander continent moeten verzenden.
Dus vanuit ZuidAfrika en Australie naar bijv. Europa of de VS.
Als je dat uitrekent, is het nog maar in de orde van 115 Gbps per locatie
Dat is nog wel te doen over een dedicated kabeltje.
Zeker als je na gaat dat dat project ongeveer 50 jaar moet draaien.

Leuke is dat die 1.25 PByte per etmaal ook gearchiveerd moet worden.

[timmiej93]

Hoezo niet? Als je een dergelijke telescoop hebt die zoveel data produceert, mag ik aannemen dat er al fatsoenlijke verbindingen liggen. Zo'n ding heeft immers ook een bak elektriciteit nodig, als die kabels gelegd worden kan de andere infrastructuur meteen mee. Daarbij, wat stellen de kosten van een fatsoenlijk netwerk naar die telescoop leggen nou voor bij het bouwen van het ding zelf? En vergeet niet dat AWS dit niet gratis doet. Op de lange termijn kan ik me echt niet voorstellen dat het makkelijker of goedkoper is om deze truck te gebruiken. Deze truck kan bijna alleen écht nuttig zijn bij scenario's waar eenmalig veel data verplaatst moet worden.

[Magic]

Gezien de naam "snowmobile" ga ik er van uit dat het bedoeld is om in combinatie met hun Glacier service te worden gebruikt. Data die dus niet gewijzigd word, maar die wel beschikbaar moet blijven zoals archiefdata of historische backups.

[Reactie gewijzigd door Magic op 26 juli 2024 19:35]

[darknessblade]

en dan over een paar 100 jaar vinden ze het "dan vervallen" data center weer terug met alle oude data die ze dan mogelijk niet meer kunnen lezen.
(beetje zoals nu de oude mac diskettes op een nieuwe macbook)
(windows kan nog oude dos diskettes lezen)

[Swerfer]

Voor diskettes heb je hardware nodig om die uit te lezen terwijl een harddisk eigenlijk al hardware is met een eenvoudige dataverbinding. Over 100 jaar kunnen ze natuurlijk heel simpel een Sata(x) controllertje maken en de data weer uitlezen.

Bovenstaand scenario is natuurlijk onzin. De harddisks zijn waarschijnlijk al overleden tegen die tijd en zelfs de magnetische informatie op de platters zullen niet meer fatsoenlijke data bevatten. Het gaat erom dat als je data wilt blijven bewaren dat je steeds je data weer veilig stelt en uiteindelijk zal over 100 jaar de 100PByte wel op een stukje DNA of zo geschreven kunnen worden...

[darknessblade]

meer iets zoals.:

connectie X naar connector Y, naar connector Q naar connector S[ata]

bv parallel printer-> parallel naar serial -> serial naar Rj45 -> telefoon port -> BNC

dan krijg je meer een zeer lange kabel met wat omzet stukjes zodat de data word omgezet naar een andere standaard, en zo de data leesbaar word gemaakt.

want over een 100 jaar zullen ze vast geen sata meer hebben. maar een andere standaard die dan nog een een flink eind sneller is.

[roches]

Zoiets als de Macbook Pro nu ..

[darknessblade]

nee dat niet, er blijven toch nog steeds modulair/ diy systemen.
natuurlijk komen zulke apparaten ook steeds meer.

(de macbook pro heeft natuurlijk wel onzinnig veel adapters nodig)
--------------
maar meer zoiets als het modulair pc system van razer/acer (mini barebone)

waarbij je alle apparaten via aparte conencties op een modulair core stopt.
----
en dan krijg je ook nog, systemen (zoals in de anime accel world& SAO)
die "direct" op je zenuwstelsel worden aangesloten.
waardoor je ten alle tijden een krachtige (full virtual "argumented" reality system) hebt, en zo direct in je onderbewustzijn bv een game speeld, of in een virtuele plek kan werken.
(beetje de toekomst van de holo-lens)

enigst nadeel is dat als hackers in je systeem zitten ze je mogelijk ook zonder dat jij het weet dingen kan laten doen.
wat ook weer risico's met zich meebrengt

[johnkeates]

Nee, de data migreert binnen het AWS platform natuurlijk gewoon constant mee.

[YopY]

De vraag is of het tegen die tijd nog relevante data is natuurlijk. Zelfs als het dan nog bestaat, 100PB is niet triviaal om te doorzoeken (en dat is nog maar een fractie van wat er in de datacenters overal staat)

[fantafriday]

Tja een bijbel of welk ander boek uit jaar x us ook nog interresant tegenwoordig.

[procyon]

Toch lijkt het erg langzaam maar het is erg snel voor 100PB.

Als je bijvoorbeeld 4 huurlijnen hebt die ieder 1.000 Mbit/sec kunnen leveren zal je er jaren (2300 dagen) over doen om dat te transporteren (@ 0.5GB/s)

[robvanwijk]

Nee natuurlijk niet, we gaan later de wijzigingen synchroniseren. Ja, gewoon. Even 100PB op verschillen controleren en synchroniseren. Hoe dan?

Vermoedelijk zijn hier twee grote markten voor: archiveren (al dan niet vanwege wetgeving die een minimale bewaartermijn voorschrijft) en dataminen. Voor het archiveren is het alleszins redelijk om aan te nemen dat data niet meer muteert (goede kans dat je die data zelfs niet mag muteren) en datamining doe je vaak op historische gegevens; die leg je één keer vast en daarna verandert het niet meer.
Daarnaast heeft veel data een timestamp, dus die kun je ook chronologisch in de truck laden; dag voor dag, net zolang tot ie vol is. Als gegevens veranderen, dan wordt de timestamp bijgeewerkt en zal ie een paar trucks later gewoon nogmaals geëxporteerd worden.

[Gomez12]

Plus dat je op timestamp perfect kan sybchen, dan kom je dus uit op 21 dagen om de bulk te vervoeren en dan nog 3 dagen om de wijzigingen te synchen... Dan kan je met 100pb aan data wel in een maand uit een datacenter zijn als het moet.

[Diavire]

Allemaal doordacht en onderbouwd, maar je conclusie is incorrect.

Amazon zou dit product niet opgezet hebben als zij er geen bestaande vraag naar zouden hebben.

[Gomez12]

Ik vermoed dat Amazon hier al hun eigen klant is en dat dat genoeg is. En daarnaast de andere grote cloud providers.

DIt is voornamelijk een antwoord op de vraag : Hoe vul je een (nieuw gebouwd) datacenter en hoe verplaats je een datacenter.

[Gawin]

Voor degene die twijfelen aan de use case:

Bij het Internet Archive heb ik mee mogen helpen met het opzetten en beheren van de Europese clone in Amsterdam (petabox.org). Het versturen van complete zeecontainers gevuld met servers (inclusief data) was vele malen goedkoper (bandbreedte kosten) en sneller (bandbreedte snelheid) dan versturen via een datalijntje.

Voor Amazon klanten geldt dit in bepaalde gevallen ook. Niet alleen als je wil migreren naar Amazon. Maar ook als je als bestaande Amazon klant nadenkt over een nieuwe fysieke locatie voor je data.

Het gebruik van containers is overigens niet nieuw. Zo had Sun Microsystems de Sun Modular Datacenter en Google heeft ook diverse data centers waar containers gebruikt worden.

[jimbo123]

Ah ja, dat is dom van mij. Er is nog nooit een bedrijf geweest wat een dienst lanceerde waarbij er later onvoldoende vraag bleek te zijn.

[Timoo.vanEsch]

Amazon is één van de grootste aanbieders van virtuele servers.
Me dunkt dat die containers goed van pas komen in hun eigen bedrijfsnetwerk. Door er tevens een commerciële dienst van te maken, kunnen ze een deel van de kosten terugverdienen.

[robvanwijk]

Ah ja, dat is dom van mij. Er is nog nooit een bedrijf geweest wat een dienst lanceerde waarbij er later onvoldoende vraag bleek te zijn.

Als er onvoldoende vraag is dan zijn er twee of drie vrachtwagens omgebouwd die ze ergens ongebruikt parkeren. Duur geintje, maar niet bepaald iets waar Amazon aan onderdoor gaat.
Het probleem van diensten met te weinig klanten is dat je met dezelfde vaste kosten zit die je er op die paar gebruikers niet uit krijgt. Maar eerlijk gezegd zie ik hier geen noemenswaardige vaste maandelijkse kosten, dus dat is geen probleem. Het grootste risico om aan dit project veel geld te verliezen is als het enorm succesvol wordt en andere (lucratieve) diensten daardoor minder populair worden. Ik weet even niet hoeveel uploaden via netwerk kost (betaalde je bij Amazon niet alleen / voornamelijk voor downloaden??) maar de winst die ze daarop maken zou kunnen dalen als grote klanten liever af en toe een vrachtwagen huren.

[Tozz]

Het kan ook een leuk stukje marketing zijn

[Luuk.vanRiel]

Goed punt, denk ook niet dat het heel handig is voor services die continu online zijn en data muteren zoals banken. Wel zou het mijns insziens nuttig kunnen zijn voor bedrijven die dingen archiveren en hier back ups van willen hebben op verschillende locaties. Je belast dan je netwerken en het algehele internet niet en je data is toch statisch en onveranderd dus maakt het niet uit als er een paar weken tussen zitten.

[telskamp]

Banken hebben ook historische transactiedata

[Gomez12]

Goed punt, denk ook niet dat het heel handig is voor services die continu online zijn en data muteren zoals banken.

Banken hebben juist historische data die niet meer muteert. En maar een piepklein gedeelte wat muteert.

Het gedeelte wat muteert kan je wel online synchen, maar de transacties van zeg 1990 tot zeg 2015 die wil je op zo'n manier synchen...

[pven]

Actieve data sla je niet op in de storage-container

[Timoo.vanEsch]

lol

[Hemera]

Het kan zijn dat dit bijvoorbeeld backups betreft, dan zal het nooit veranderen.

[CrazyBernie]

Bijvoorbeeld log informatie van iot projecten die is zeer statisch maar door de hoeveelheid sensors wel enorm hoog. Die data wordt pas echt interessant als je hem lange termijn op kunt slaan zodat je daar dan weer analytics op los kunt laten. Wanneer je dan van een de ene naar de andere provider wilt verplaatsen dan kan die data er prima een paar weken over doen aangezien je tot je om bent op de oude omgeving nog met de data kunt werken.

Ik denk dat hier dus zeker markt voor is wel natuurlijk alleen bij grote partijen die zo ie al zo'n enorme hoeveelheid data hebben opgeslagen.

[borft]

Wat dacht je van append-only databases bv? Of cold storage, er zijn zoveel toepassingen te bedenken!

[Lapa]

Denk dat dit al met al een enorm niche service is en dat ze die vrachtwagen veel stil gaan zien staan zonder enige inzet bij klanten.

Is dit een niche product? Tja, dat ligt aan je definitie. Het is in ieder geval niet voor consumenten, het MKB of een of ander willekeurig bedrijfje, dat snappen we allemaal.

Maar ga er maar vanuit dan Amazon dit niet voor de lol doet en er zeker een markt voor kent. Die hebben hier langer en beter over nagedacht dan jij en ik doen na het lezen van een artikeltje op Tweakers. Het komt ook niet uit de lucht vallen, ze hebben al een tijdje de snowball kisten die hetzelfde op iets kleinere schaal doen. Blijkbaar zagen ze de behoefte om dit op nog grotere schaal aan te bieden.

[WienerBlut]

Denk eens aan video archieven... die worden ook snel heel groot... daar heb je wel aardig wat bandbreedte/storage voor nodig...

[Tralapo]

Bovenstaand gaat nog uit van 100PB, wat al absurd veel is.
In het filmpje hebben ze het over een exabyte, en geven ze aan dat dit 6 maanden duurt om te verplaatsen.

Je moet dus over erg statische data beschikken om dit te kunnen doen, of je moet in staat zijn om wijzigingen apart bij te houden en eenvoudig later te synchroniseren.

Als je doorklinkt naar de bron, https://aws.amazon.com/bl...ta-to-the-cloud-in-weeks/, zie je dat er al een usecase genoemd is: DigitalGlobe. Zij produceren 10PB aan satellietbeeld per jaar momenteel en gaan de trucks gebruiken om hun archieven te verplaatsen.

[Rob Coops]

Ehm, dus jouw DB is 100PB groot en je draait nog niet in een cloud

Goed, even serieus, natuurlijk is er data die je niet zo maar even kwijt kan raken maar als je een beetje weet wat je doet met je data warehouse / data lake etc dan kun je heus we een manier bedenken om die 50TB of zo die je aan data genegeerd per dag tijdelijk te flaggen als nieuw en dan de data over te brengen met bijvoorbeeld snowball devices etc.

Op dit moment ben ik zelf toevallig betrokken bij een migratie van een on premise DC naar Amazon en dat is precies het geen waar de uitdaging komt kijken de delta tussen de dump die je naar Amazon brengt en de tijd die je nodig hebt om alles aan de andere kant aan te zwengelen. Maar dat is niet iets dat echt moeilijk is zo lang je even na denkt is het vrij simpel om hier een passende oplossing voor te vinden.
Het hangt natuurlijk heel erg af van wat voor data je verplaatst maar na jaren van migraties tussen DC's en van en naar clouds kan ik je met zekerheid zeggen dat ook een paar Exabyte niet al te moeilijk is aangezien de meeste data inderdaad gewoon statisch is en je over het algemeen redelijk eenvoudig de mutaties kunt bijhouden gedurende een paar dagen weken/maanden.

Ik denk dat het probleem dat jij ziet meer te maken heeft met nog niet veel ervaring met het werken met grote hoeveelheden data en niet zo zeer met een fout in het idee van Amazon over hoe met redelijk gemakkelijk een paar Exabyte kan verplaatsen van een DC naar een ander DC.

[TD-er]

Mutaties op dergelijke schaal moet je automatiseren. Dus dan komen technieken als iRODS en OODT om de hoek kijken. Dan gaat dat allemaal volgens regels en policies en gaat de data precies daar naar toe waar het moet zijn. (workflow automation, backup, duplicatie, etc)
* TD-er is bezig met een projectje voor 20 PB aan data

[Verwijderd]

Btrfs of een dergelijke zou in een oplossing kunnen zijn. Door read-only snapshots te maken kun je later in één klap de wijzigingen porteren naar een ander (schaduw)volume.

[sympa]

Nee natuurlijk niet, we gaan later de wijzigingen synchroniseren. Ja, gewoon. Even 100PB op verschillen controleren en synchroniseren. Hoe dan?

Als je zoveel data hebt staan dan heb je wel een manier om het behapbaar te maken. Dat heb je ook al nodig voor backups. Er zijn file systems die dat voor je kunnen, maar als je zoveel data hebt zijn dat vaak allemaal objecten die zelf niet muteerbaar zijn.
File system of niet, het concept is: zorg dat data van voor en bepaalde datum niet gemuteerd wordt. Van alle mutaties houd je bij welke objecten het betrof. Je gaat dan alle data langs en kopieert data van voor de startdatum.
Ben je daarmee klaar, dan begin je opnieuw. Je gaat nu alle data langs die in het changelog staat. Uiteraard worden nieuwe mutaties in een nieuw changelog geschreven.
Als je maar snel genoeg kopieert haal je altijd de mutaties in, en krijg je een 1 op 1 kopie.

File systems die dit kunnen vind je bij NetApp, maar ZFS en BTRFS kunnen het ook. Maar als je 100 PB hebt gebruik je waarschijnlijk iets anders om je data te verdelen en beheersen.

[TD-er]

Dat soort hoeveelheden staat niet in 1 filesysteem, maar in zgn. object-stores.
En laat Amazon nou zo'n beetje de bedenker zijn van S3
Dus ik gok zo dat ze dit "schijven-rack-op-wielen" toegankelijk maken via S3. Dat is lekker schaalbaar, zowel in ruimte als bandbreedte en de onderliggende laag kan de boel wel met de benodigde redundantie wegschrijven en vaak zit daar ook snapshot-functionaliteit in. Maar als het je gaat om te zien wat er veranderd is, is dat met S3 nog makkelijker, want je kunt objecten niet aanpassen (zelfs niet hernoemen), dus dan moet een object gelezen worden en de veranderde versie als nieuw object weer opgeslagen worden.

[sympa]

Precies. Dus het hele probleem van incrementeel doorsturen is allang opgelost. Anders zijn die hoeveelheden data niet hanteerbaar.

Overigens heb je dat 'doorsturen' ook nodig om te kunnen migreren. Ooit zal je NAS met 100 PB aan data verouderd zijn en wil je de data naar nieuwe schijven overzetten. En dan is het handig dat er al aan de migratie gedacht is voordat het vullen begon

[Chakotay]

Never underestimate the bandwidth of a station wagon full of tapes hurtling down the highway.

–Andrew Tanenbaum, 1981

leuke XKCD what if? hierover

[LankHoar]

Je bent me voor, ik dacht precies hetzelfde!

Prijzen zijn nog niet bekend. Die zullen wel extreem hoog liggen. Toch wel nieuwsgierig naar wat zoiets nou zou kosten.. De naam snowball, zou die gekozen zijn door de vergelijking met het snowball effect?

[TD-er]

Prijs van 1 PB aan harde schijven (zonder iets aan verdere hardware) ligt op ongeveer 35'000 euro.
Dus puur en alleen al de hdd-prijs van die truck is 3.5 mln euro.
Met alles erop en eraan zal die truck dus ruwweg 4.5 - 5 mln kosten.
Dat spul is voor het grootste deel in 5 jaar afgeschreven (grootste deel in geld dus, die truck zelf kan wel langer mee) en je moet dus ongeveer 20 dagen rekenen voor "laden en lossen" van de data. (of de boel moet bij Amazon fysiek eruit getrokken kunnen worden)
Dus maximaal zo'n 12 - 15 ritjes per jaar per truck. Dus de ruwweg 1 mln afschrijving per jaar moet je dan verdelen over die ritjes en bij voorkeur ook nog wat winst maken.
Reken dus op ruwweg een ton aan kosten om 100 PB te vervoeren.

[Marnixjee]

ik zou eerder een vrachtwagen maken met rekken waar klanten zelf schijven in kunnen drukken, dan heb je als Amazon minder afschrijving en als klant hoef jij niet enkele uren die vrachtwagen op de stoep te hebben, dan is het inladen en wegwezen.

[aadje93]

dan krijg je dus een datadichtheid die veel lager is, de truck staat veeeel langer bij een klant etc. De heren bij amaazon hebben hier echt wel goed over nagedacht en user cases bekeken denk ik

[Gomez12]

Dat is geen reeel businessplan meer, want of de klant moet dan 100pb aan storagedevices gaan kopen en het eerst in het datacentrum daarop gaan kopieren, waarna hij het in de truck kan laden (duurt langer en is duurder).

Of de klant moet volledige downtime voor de overdracht aankunnen (wat bijna niet kan)

Ergens moet die kopieslag plaatsvinden, doe het dan maar direct en in de truck.
Plus dat je met losse rekken met hdd's allerlei andere problemen ook gaat krijgen zoals wat gebeurt er als de truck omslaat en de schijven op de weg belanden, zijn ze dan ge-encrypt of niet?

Wat jij wil kan ook, maar dan huur je gewoon een transport/verhuisbedrijf in met een truck.

[Timoo.vanEsch]

Zoals eerder al geschreven hierboven, door iemand:
Over internet zou het ongeveer een miljoen per maand kosten.

Da's dus een factor 10 goedkoper...

[Gomez12]

Dus de ruwweg 1 mln afschrijving per jaar moet je dan verdelen over die ritjes en bij voorkeur ook nog wat winst maken.
Reken dus op ruwweg een ton aan kosten om 100 PB te vervoeren.

Ik vraag me af of ze hier wel winst op willen maken hoor. Ze zullen geen verlies draaien, maar waarom zou je hier winst op willen maken?

In wezen als een klant deze dienst afneemt zit hij wel aan je vast. Probeer het maar eens weg te krijgen weer...

Oftewel je hebt meerdere maanden / jaren je glacier inkomsten waar je je winst op kan maken en die inkomsten zijn niet gering...

[FreshMaker]

Wat is extreem hoog ?

Om je privéalbum naar een secure locatie te brengen ... ja, denk het wel
Om mission critical bedrijfsdata snel aan de andere kant van de lijn te krijgen, bij calamiteiten ( huidige locatie is niet effectief genoeg ) kan het een schijntje zijn.

Elke kostprijs heeft een waarde, de vraag is waar ligt je grens.

Ik hoef geen Puma ren-schoentjes á 250€ te hebben voor mijn avondje sprinttraining, maar ik denk dat Dhr Bolt er anders over denkt.

[Blokker_1999]

Extreem hoog is ook relatief natuurlijk. Voor de hoeveelheid data die je kunt verplaatsen zal het zeker en vast een geode prijs hebben.

[Deveon]

Helaas alleen geen rekening gehouden met de transfer snelheid van de data naar de mobiele data drager en weer terug. Zoals je bij deze container ziet is dat maximaal 10 dagen. Zonder transport zit je al op 20 dagen om het van A naar B te zetten.

[supersnathan94]

Dat is anders nog steeds bijna 60GB/s. Reken maar uit. Vele malen meer dan je via het internet kan verplaatsen.

Als wij 2TB aan data moeten verplaatsen doen we dat ook met een externe hdd.

[TagForce]

Maar de bandwidth is afhankelijk van het traagste onderdeel in de weg naar de eindlocatie... En dat is niet die station wagen, maar de tapedrives waar die tapes in moeten.

Dus ja... Een FedEx vloot met een bandwidth van 400000 SD kaartjes per seconde heb je weinig aan als je op de bestemming maar 1 SD cardreader hebt staan van 10Mbit/s.

Het idee is simpel:
Wat is sneller:
- Alle data overpompen via de internets met 100Mbit/s
- Alle data op SSDs pompen, in een vrachtwaggel stoppen, naar de opslaglocatie rijden, en daar alle data weer terugpompen op de disks die daar draaien

In dit artikel wordt gesproken over 10 dagen upload naar de truck, 1 dag rijden, 10 dagen download vanaf de truck... Da's 21 dagen voor 100 PetaByte. Gemakshalve maar even 1000 Petabits of 1 Exabit in 1.814.400 seconden... Dat is 552 Gbit/s... Als je dus een verbinding hebt
die sneller is dan dat (en ik zit thuis al op 0,2% daarvan) dan is deze vrachtwaggel dus langzamer)

[teamacc]

Reken hier wel even mee dat hier in europa data ongeveer 1 euro per maand per (mbit per seconde) kost, 50 cent als je de goedkoopste aanbieder pakt. In de US of A is dat 1-2 dollar per mbit. Die 500+gbit/s kost je dus al gauw een miljoen per maand. Dan kan het echt wel uit om even met een vrachtwagen op en neer te rijden.

(Ja, jouw gigabit lijntje kost (jou) minder, maar dat is ook hopeloos driedubbel oververhuurd, je gebruikt echt geen 300TB per maand op dat ding.)

[Gomez12]

Je negeert nog even een van de grote voordelen : Die trucks kunnen weer in een vliegtuig.

Wil jij van Amerika even 100pb overpompen naar Australie dan heb je een redelijke uitdaging met je verbinding want die gaat gewoon niet zo snel en er valt ook niet even een kabeltje bij te leggen.

Met een beetje planning kan je hiermee je data overal ter wereld krijgen binnen een maand ongeacht lokale verbindingen etc.

[PvdVen777]

Zeer toepasselijke quote inderdaad !

[Exirion]

Grappig, toen ik het artikel las moest ik meteen weer aan Tanenbaum's colleges denken

[arsimo]

Moest hier ook meteen aan denken, net als anderen hier zo te zien :-)

Never underestimate the bandwidth of a station wagon full of tapes hurtling down the highway.
–Andrew Tanenbaum
Computer Networks, 3rd ed., p. 83. (paraphrasing Dr. Warren Jackson, Director, University of Toronto Computing Services (UTCS) circa 1985)

[pennenlikker]

Alleen slaat z'n verhaal nergens op want hij neemt het stuk wat het meeste tijd kost het 'in' en 'uit' laden niet mee. Als je iets over het internet kopieert zit die tijd daar al in. Met een pakketje moet je eerst de data uploaden naar een vervoerbaar medium, vervoeren en vervolgens de data downloaden van dit medium naar de nieuwe locatie.

[[Yellow]]

Er is toch nergens gezegd dat je alle data ook daadwerkelijk wilt transferren? Ik kan me voorstellen dat je in die container je volledige dataset opslaat. En dan elke keer stukjes ervan opvragen/aanpassen. En omdat je waarschijnlijk niet weet wélke stukjes je nodig zult hebben bewaar je gewoon alles maar in je container.

Vergelijk het met je foto album: je hoeft niet continue toegang te hebben tot al je foto's. Alleen weet je vantevoren nooit over welke vakantie je het het gaat hebben tijdens een verjaardagsfeestje (ja oke, de laatste ook natuurlijk).

[Reactie gewijzigd door [Yellow] op 26 juli 2024 19:35]

[Tweakmans]

Het klinkt nogal paranoïde om voor een container met versleutelde data ook nog eens een beveiligingsescorte in te schakelen... Of ligt dat aan mij?

[tweaknico]

Dat ligt aan jou, als de data gestolen wordt ben je het ook KWIJT, de dief heeft er weinig aan zonder sleutel, maar er zit nog steeds een leuke verzameling schijven, CPUS's etc. in die je in de ramsch kwijt kan..

[Gulli]

Een dief kan het ook als pressiemiddel gebruiken. Zeg maar de fysieke vorm van Ransomware (je data is gekidnapt). Je bent je data kwijt, als je betaalt krijg je het terug. Natuurlijk is het bedrijf die data niet echt kwijt want de bronsystemen hebben het neem ik aan nog opgeslagen staan totdat de transfer aan de ontvangende kant compleet is, maar als het je een half miljoen kost om een nieuwe truck te regelen wil je misschien wel losgeld van 400.000,- betalen. Dieven hebben hun geld, en jij hebt met 100.000,- 'korting' je data terug.

[tweaknico]

Geen korting, want de rekening bij amazon zal gewoon doorlopen als e data terug komt.... slechts 400.000 Extra...

[Gulli]

En als de data niet terug was gekomen omdat je geen losgeld had betaald was het 500.000 extra geweest om een nieuwe truck te regelen. Ergo; 'korting'.

[FreshMaker]

De data is een copie van je bestaande data.
Truck weg -> sleutel laten vervallen -> data onbruikbaar.
De transporteur ( Amazon ) is verantwoordelijk voor het verlies onderweg, vandaar de gps tracking / escorte.

imho zal er een 'nieuwe' truck geboden worden, die de data opnieuw binnenhaalt, en vervoert ( met hogere security / andere route )

Geen losgeld, want er is niets echt "weg"
De (oude) data is onbruikbaar, want versleuteld opgeslagen

[StefanTs]

Lijkt me niet dat je de de data van de bron verwijderd voordat het veilig op de bestemming is. Dus je zult het niet kwijt zijn maar je hebt wel een potentieel datalek. En meteen een flinke.

[nokie]

"De data kan me gestolen worden, maar zo'n truck staat wel stoer in mijn mangrot." zou iemand zo spontaan wel kunnen denken.

(m.a.w. ik neem aan dat Amazon zijn hardware niet zomaar gestolen wil zien)

[FreshMaker]

IBM, SUN, Google en nog een paar gingen hun voor, op losse containers dan.
https://en.wikipedia.org/wiki/Modular_data_center

https://en.wikipedia.org/wiki/Google_Modular_Data_Center

http://www.datacentermap....acenter-container-55.html.
( met plaatjes )

[walteij]

Nee, wat jij nu noemt zijn datacenter containers. Ofwel modules die eenvoudig aan je datacenter kunnen worden toegevoegd of verwijderd, zodat capaciteit op- of afgeschaald kan worden (of complete containers vervangen als meer dan x% van de hardware storingen heeft).
De Amazon truck is letterlijk een vervoer mechanisme om je on premise data te verplaatsen naar de Amazon cloud. Dus je kopieert je statische/historische data naar de truck, de truck rijdt naar een Amazon datacenter toe, en daar wordt de data op glacier geplaatst.

[Reactie gewijzigd door walteij op 26 juli 2024 19:35]

[FreshMaker]

Dat weet ik, maar het ging over de mancave ....
Dan zou ik toch graag wat kracht hebben, en niet alleen maar opslag

[walteij]

Ah, check!
Dan had ik het even verkeerd begrepen. Een datacenter container naast/onder/boven de mancave is inderdaad wel een leuke bonusfeature ja.

[FreshMaker]

Scheelt in de verwarmingskosten ...
Met zo'n container half ingegraven, kan je de warmte afvoer mooi gebruiken als vloerverwarming in de winter.

Die 4 dagen warme zomer zijn verwaarloosbaar, even uizetten

[S0epkip]

Eens. Als je de encryptie vertrouwd is dat niet nodig en trekt het juist eerder de aandacht zou ik zeggen.

Als je de encryptie niet vertrouwd moet je er gewoon niet aan beginnen

[soulcrusher]

Ligt er maar net aan hoe waardevol de data voor je is. De encryptie houdt het stelen van je data tegen maar de beveilgingsecorte houdt het stelen van je container tegen. Het een sluit het andere niet uit.

[eamelink]

Er staan inmiddels wel prijzen bij: $0.005/GB per month.

Dus als je hem bestelt met 100PB capaciteit, dan kost het je een half miljoen dollar per maand. Vlotjes vullen en terugsturen is dus het devies

[pven]

Mwa, als je over dat soort hoeveelheiden storage praat dan heb je het niet over een adressenbestandje welke je 100.000.000 keer veilig op wil slaan.

[GrooV]

Dat zijn gewoon de standaard AWS Glacier prijzen

[don_jorg]

Gezien het nieuws van de afgelopen jaren, in combinatie met data, vind ik het toch een zeer aparte marketingactie om 'Snow' te gebruiken als het over data gaat...

Los daarvan: mooi product. Doet me denken aan de stelling dat een oceaanstomer de snelste manier is om gigantische hoeveelheden data te verplaatsen: het aantal harddisken dat in zo'n boot past is zó groot, dat ondanks de lange tijd dat zo'n boot erover doet, je tóch sneller al je data hebt.

[FreshMaker]

Ze mogen dan ook geen 'dark' gebruiken, of 'black' ?

Snow is hun verwijzing naar Glacier, wat weer moet duiden op "lange tijd"
Ik vind het wel inventief, de benamingen, snowball voor 50TB, snowmobile voor 100PB ( incl truck )

Hebben ze al snowflakes ? -> ja

[don_jorg]

Ik bedoelde meer de associatie met Edward Snowden, dat lijkt me niet zo'n goed plan... Dark of black zie ik niet zoveel problemen mee.

[AJediIAm]

Ik moest er ook aan denken. Helaas kon ik er geen passende flauwe grap bij bedenken. Uiteindelijk zal het niet zo veel uitmaken hoe ze het noemen.

[ATS]

Nou... als ik zie hoe snel die de laatste jaren aan het smelten zijn, dan associeer ik dat niet meer met "lange tijd" maar met "bijna pleite". Niet een lekkere associatie voor een datacentrum

[TD-er]

Dat is gewoon een verregaande miniaturisatie van zo'n gletsjer, analoog aan hoeveel ruimte die data nog inneemt

[two]

Ik denk dat ze juist gekozen hebben voor Snow omdat het wordt geassocieerd met datalekken/veiligheid ook al valt het op meerdere (waaronder ook negatieve) manieren te interpreteren.

[s0larus]

Het zal inderdaad een stuk sneller zijn om 100PB per container vervoeren dan oversturen via het internet. Ben benieuwd hoeveel Amazon er voor zal vragen voor de verschillende extra opties.

XKCD had daar een What If over maar dan met FedEx. Enige probleem was natuurlijk de ping time bij data heen en weer sturen.

[supersnathan94]

80.000.000ms.

Gelukkig is dit geen probleem voor statische data waar je een enorm rekencluster voor nodig hebt. Het rekenen aan die data duurt dermate lang dat een halvering van de tijd vaak wel miljoenen mag kosten.

[kh65]

Digitale techniek anno 2017 ?
Het blijft bijzonder dat er behoefte is voor dit soort dingen...

[darkangel456]

Het is dus gewoon een grote op wielen uitgevoerde MEGA USB stick.

[Goldwing1973]

Eerder een NARS (Network Attached Roadworthy Storage)

[SwerveShot]

Dat is een big ass NAS! Komt 'ie ook met xpenology preloaded?

[FreshMaker]

Voor de gemiddelde thuisgebruiker hebben ze wel een 'dinky toy' uitvoering
https://www.synology.com/nl-nl/products/FS3017

Wel zelf wieltjes plaatsen

[Goldwing1973]

Helaas, maar hij "mist" nog 910TB
De onbewerkte capaciteit van of FS3017 bedraagt 90TB.

[FreshMaker]

vandaar, dinky toy

[TD-er]

Helaas, maar hij "mist" nog 910TB
De onbewerkte capaciteit van of FS3017 bedraagt 90TB.

Het verschil tussen 100 PB en 90 TB = 99'910 TB

[SwerveShot]

Zo'n editie kunnen ze automagisch met een drone thuisbezorgen. No wheels required.

[MScheveningen]

als je de bandbreedte berekent (basis volume/(laden+lossen+rijden)is deze methode ongeveer equivalent aan 430Gbit/s , zo'n huurlijn koop je niet overal. Voor actieve data kun je overigens een snapshot transporteren en de rest met changelogs opslossen totdat je locaties zo sysnchroon zijn dat je ze online sysnchroon kunt houden.
Wat kost een 500Gbit huurlijn voor een paar weken ?

[Reactie gewijzigd door MScheveningen op 26 juli 2024 19:35]

[supersnathan94]

Geen idee, maar dat trek je natuurlijk niet zomaar over je bestaande glasvezel. Met een halve TBit/s mag je waarschijnlijk direct bij een exchange gaan inprikken met een agregaat aan kabels. De aanleg daarvan zal niet mals zijn.

[Gomez12]

Wat kost een 500Gbit huurlijn voor een paar weken ?

Dat is een hele leuke vraag als je 2km gaat verhuizen, maar als je bijv iets van West-US naar Oost-US wilt transporteren dan gaan niet alle tussenstukken 500Gbit aankunnen.
Of wat denk je als je van US naar EU wilt transporteren?

Plus dat ik sowieso al denk dat je voor 500Gbit je ook giga-veel tijd aan voorbereiding kwijt bent (wellicht moet er gegraven worden, wellicht moeten er switches vervangen worden aan beide kanten etc etc), ik ken niet zo heel veel commerciele partijen die een 500Gbit slot vrijhouden voor incidenten wat je wel nodig hebt als je het snel wilt huren.