Microsoft presenteert Azure Data Box om tot 100TB fysiek te verplaatsen

Microsoft heeft een opslagkist aangekondigd die klanten kunnen huren om grote hoeveelheden data fysiek te kunnen versturen, om vervolgens in de Azure-clouddienst opgenomen te worden. De Azure Data Box kan 100TB aan data herbergen en weegt zo'n 20kg.

De kist is volgens Microsoft stevig gebouwd, sabotagebestendig en eenvoudig in gebruik. Specifieke details over de hardware geeft het bedrijf niet, maar er zou ongeveer 100TB aan opslagruimte beschikbaar zijn en de data wordt met aes256-encryptie versleuteld. De kist werkt met protocollen als smb en cifs.

Vooralsnog is de Azure Data Box alleen beschikbaar voor Amerikaanse klanten die zich aanmelden voor het previewprogramma. In de komende maanden moet de kist ook in andere landen beschikbaar komen, maar welke dat zijn, zegt Microsoft niet.

Het versturen van zeer grote hoeveelheden data is in veel gevallen fysiek nog altijd sneller dan via internet. Ook Amazon biedt voor zijn AWS-clouddienst datakisten aan, die hebben capaciteiten van 50TB en 80TB. Amazon zet ook een truck in voor het vervoer van data; de container kan tot 100PB over de snelweg vervoeren.

Microsoft heeft de kist al laten testen door het bedrijf Oceaneering International. Dat bedrijf voert inspecties uit in de zee voor de olieindustrie. Robots vergaren daarbij dagelijks meerdere terabytes aan gegevens, maar vanaf het schip is er geen snelle internetverbinding om die data over te zetten. Ook in dergelijke scenario's moet de Azure Data Box uitkomst bieden.

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

Reacties (113)

[Verwijderd]

Ligt misschien aan mij hoor, maar hoeveel langer kan het duren om 100TB via een knappe netwerk verbinding te sturen t.o.v. fysiek? Lijkt me niet echt heel veel uitmaken... Misschien als er totale paniek is binnen je organisatie op dit gebied, maar dan moet je je echter afvragen of er niet andere problemen zijn die opgepakt moeten worden.
Maar verder en mooi apparaatje

[Keypunchie]

Let wel op: het probleem is er eentje van upload, niet download.

Geinspireerd door wat iemand hieronder schreef: Een scenario dat ik kan bedenken is video. Een cameraploeg schiet in een week op lokatie in 4K ff'tjes 100 TB aan data, maar daarna moet dat gedeeld worden met allemaal partners, voor geluidsbewerking, editing, special effects, etc. etc.. Zelfs als het bedrijf van die cameraploeg een mooie glasvezel heeft, met 500 mbps upload (ik kies bewust niet de duurste optie), dan duurt 100 TB nog steeds 18.5 dagen om te uploaden. En dan zit de upload helemaal snotvol, zonder dat er een byte andere data overheen gaat.

Dan is zo'n doos wel een optie. Verzamelen van de data zal al een hele klus zijn, maar het uploaden is een kwestie van opsturen en zodra Microsoft dit ding in Azure inprikt, ben je vanuit jouw perspectief klaar. Microsoft zal achter de schermen de data ongetwijfeld naar andere storage brengen, maar dat gaat als het goed is voor jou transparant.

[NoUseWhatsoever]

18,5 dag? Ik snap die berekening niet helemaal.

100 TB = 100.000 GB oftewel 100.000.000 MB

500 MB/sec is dus 200.000 seconden (100mln/500), 3.333 minuten (200k/60), 55,55 uur (3333/60) of 2,3 dagen (55,55/24).

Dus je bent in totaal met een flinke consumentenverbinding in het beste geval 2,3 dag bezig met uploaden.

Dat is lang!

Update: weer wat wijzer MB/s vs mbps. nooit geweten.

[Reactie gewijzigd door NoUseWhatsoever op 24 juli 2024 16:10]

[Keypunchie]

Mbps niet MB/s (megabit vs. megabyte. De snelheid van een internetverbinding is doorgaans in megabit)

Dat scheelt dus een factortje 8 :-)

Graag zou ik een 500 MB/s verbinding hebben :-) :-) :-) 40 4 Gbps... lekker hoor, maar niet bepaald consumentenwerk.

@Scr3wdriv3r lol. thx. (die andere met een rekenmachine gedaan, deze uit het hoofd. krijg je ervan.

[Reactie gewijzigd door Keypunchie op 24 juli 2024 16:10]

[Scr3wdriv3r]

Die zou ik ook nog even narekenen

[AjDuLion]

Gemiddeld ''groot'' festival die wij doen doen alles van 8-30TB per weekend, we knallen dit op 2/3 storage units waarvan er 1 van de klant is 1 van ''ons'' en 1 als backup.

voorheen ging dit nog op wat kleinere disks en kon je af met 1 archive disk van 8tb maar meer en meer partners willen ook kunnen editen en 6-8k footage kan nu eenmaal niet geëdit worden met 220MB/s dus zitten ze al snel met mooie raid array's (waarna ze geroepen hebben wat gebruiken jullie dan doen wij dat ook)

mooi spul om mee te werken gaat allemaal rete snel en blijft elke keer leuk als we de boxen uit de 2 auto's halen en aansluiten om te kijken of de disks nog ok zijn

[dev10]

Als je 100TB data overpompt met 10Gbps, duurt dat iets meer dan een dag. Als je een veelvoud aan data moet overzetten, bijvoorbeeld 1000TB, wordt het al snel interessanter om dit via dit soort kastjes te doen. 1000TB zou met een 10Gbps verbinding een dag of 10 duren waar je in principe binnen 48 uur deze kasten aan de andere kant van de wereld kunt hebben staan.

[418O2]

Je moet ook de data nog in zo'n box pompen en op locatie de data weer op het doel-systeem krijgen. Maar ik neem aan dat dat niet over een USB kabeltje hoeft te gaan

[Horatius]

Een usb kabeltje kan 10Gbit/s aan dus zou best wel kunnen hoor en thunderbolt kan als 40Gbit/s aan dus dat is niet het gros van het werk.

[mjl]

Sas connector, iSCSI, glasvebinding. Als het nodig is kun je aardig wat snelheid maken...

[vSchooten]

meestal hebben ze hot-swap poorten waardoor het als een interne schijf gezien wordt.

[servicedb]

Vergis je niet: niet overal is de capaciteit beschikbaar om dit zomaar over te kunnen pompen. En al is het er wel: je kan niet altijd dit 100% benutten omdat het dan op de productie invloed heeft.

[beerse]

Het gaat niet om de bandbreedte die je bruto ter beschikking hebt, maar wat je netto kan gebruiken. Als je een 1Gbit verbinding hebt, dan kan je die als bedrijf niet de hele dag vol pompen met gegevens naar azure, dat vreet aan je bedrijfsvoering.
Daarnaast heb jij die aansluiting wel maar de meeste routers en switches onderweg hebben die bandbreedte niet continu ter beschikking, vooral als het om een enkele route gaat en helemaal als het maar om een doorlooptijd van een week gaat.
Dan huur je zo'n box en draait een week lang de backups daarheen. Daarna kan je de box opsturen en alles is overgezet zonder dat het elders op de verbinding bottlenecks tegenkomt of onnodig resources misbruikt.

[Bardman01]

Misschien de afstand? Als het maar 5 minuten lopen is sleep ik die kast wel even mee. (steekwagen )
Hoe snel je netwerk is maakt dan niet uit als ik bovenstaande berekeningen zie. Snelste is dan iets van 5 uur

[Tiny]

De Azure Data Box kan 100TB aan data herbergen en weegt zo'n 20kg.

20 KG, is dat met of zonder data?

[Umbrah]

Lach maar, maar een volle drive is wel degelijk zwaarder dan een lege drive. De simpele uitleg is dat, zelfs al is het een HDD, de verschillen in orientatie van de magnetische sector (dipool magnetisme) voor een zekere toename aan energie zorgt; en einstein heeft al vrij snel bepaald dat energie gelijk staat aan massa. Hoe miniscuul ook; er is wel degelijk gewichtstoename als een schijf vol is. Voor een typische 1TB disk is het echter iets in de orde van 10^-14. Niet iets waarvoor er ineens een extra postzegel nodig is als je de schijf terug wilt sturen! (hoewel, met hoe PostNL tegenwoordig rekent... je weet maar nooit... misschien geven ze je echter kwantumkorting!)

Geloof het of niet, maar op de physics variant van stackoverflow is er een hele discussie over: https://physics.stackexch...e-heavier-when-it-is-full

[Reactie gewijzigd door Umbrah op 24 juli 2024 16:10]

[Liberteque]

Interessant artikel, maar om nu te stellen dat het echt zwaarder is geworden? Dit bewijst alleen maar hoe belachelijk nauwkeurig wij kunnen wegen. Als er toevallig een wimper op die HDD terecht komt is de gewichtstoename vele malen groter dan wanneer die vol met data is geschreven. Leuk voor een theoretisch gesprek, maar in de praktijk zal je scheef getrokken gezichten zien wanneer je beweert dat een volle HDD zwaarder is dan een lege.. En na je uitleg zullen er vast mensen zijn die zich zullen ziek melden wegens duizeligheid en desoriëntatie.. Nerd-alert nerd-alert... ;-)

Wel bedankt voor het onder de aandacht brengen van dit onderwerp. Ik wist dit niet. Top!

[Keypunchie]

Zoals Andy Tanenbaum al zei:
Never underestimate the bandwidth of a station wagon full of tapes hurtling down the highway.

Stel het duurt 2 dagen om deze doos te verplaatsen

100 TB / 48 u ~ 4630 Mbps.

[Reactie gewijzigd door Keypunchie op 24 juli 2024 16:10]

[Kun]

Maar hoe lang duurt het om dit ding vol te schrijven met 100TB aan data? Ook niet onbelangrijk in je berekening.

[Soldaatje]

Met 200 MB/s zou dat bijna zes dagen duren als ik goed heb gerekend.

[walteij]

Een serieus SAN kan tegenwoordig 40 Gb/sec aan, ofwel 5 GB per seconde.
5 GB/seconde is dus 300 GB per minuut, dus (zonder overhead) heb je dan 100 TB overgepompt in ongeveer 5 1/2 uur. Met wat overhead kun je dan dus rekenen op 8 uur.

Qua harddisks, Microsoft kennende hebben ze in dit apparaat 2 JBOD arrays zitten die gemirrored zijn (zodat er bij 1 defecte HDD geen data verlies optreed). Wellicht dta er een combinatie van SSD en HDD wordt gebruikt, om de benodigde snelheid te halen.

[boolean]

Ik verwacht eerder een RAID 6 array, maar ik ben benieuwd of Microsoft de daadwerkelijke specificaties nog eens vrij geeft.

[walteij]

Maar dan moet bij een disk failure de array weer opnieuw opgebouwd worden.
Bij een gemirrorde JBOD hoeft alleen de data opnieuw gekopieerd te worden, wat toch een stuk sneller is.

Bron
JBOD RAID N+N: With JBOD (just a bunch of disks), it is possible to concatenate disks, but also volumes such as RAID sets. With larger drive capacities, write and rebuilding time may increase dramatically (especially, as described above, with RAID 5 and RAID 6). By splitting larger RAID sets into smaller subsets and concatenating them with JBOD, write and rebuilding time may be reduced. If a hardware RAID controller is not capable of nesting JBOD with RAID, then JBOD can be achieved with software RAID in combination with RAID set volumes offered by the hardware RAID controller. There is another advantage in the form of disaster recovery, if a small RAID subset fails, then the data on the other RAID subsets is not lost, reducing restore time.[citation needed]

[TD-er]

Bij dit soort toepassingen ga je niet voor een rebuild.
Data erop, doos verplaatsen, data eraf, schoonmaken + eventueel disks vervangen.

Dus voor deze oplossingen lijkt mij een simpele RAID 6 oplossing prima.
Sowieso heb je voor 100 TB aan storage tegenwoordig maar 10 drives van 12 TB nodig, of 12 van 10 TB.

Die halen ruwweg 250 MB/s (grote files), dus effectief 2 GByte/sec
Met 2x 10 Gbps ethernet heb je dan al voldoende snelheid om de boel over te zetten.

[dinnnozo]

Als je uit gaat van NVMe SSD's heb je bijvoorbeeld deze https://tweakers.net/pric...4500-pci-e-30-x4-4tb.html
Write op 1.860MB/s en 25 nodig voor 100TB (JBOD) komt neet op 46,5GB/s oftwel 372Gbit/s.
Dis is natuurlijk nogal optimistisch als je uit gaat van de max snelheid.
40Gbit/s en 100Gbit/s ethernet bestaat ook al.
Neem een paar van die en je gooit zo een hoop data op zo'n machine.

[TD-er]

Punt met die NVME drives is dat je maar een beperkt aantal PCI-express lanes hebt.
En rappe ethernet adapters heb je ook weer een paar voor nodig.
Daarnaast zijn die drives een 'tikkeltje' duurder dan hdd's en ik zie niet in waarom je voor dit soort toepassingen zoveel snelheid nodig hebt.
En 10 Gbps is nog wel te vinden in menig bedrijf. 40 en 100 Gbps is al wat meer schaars, al zie je 40 Gbps spul zelfs nu al 2e hands voorbij komen. Die 40 Gbps (QSFP+) is ook gewoon 4x 10Gbps in 1 kabel, dus misschien valt het mee met de beschikbaarheid in de switches, als ze 40G spul inzetten als 10G (bijv. Dell S6000 serie)

[oef!]

Volgens mij is dat een beetje uit de gratie, bij het herbouwen van een array van 100TB heb je een aardige kans dat een andere disk klapt.

[brinkdinges]

Ze gebruiken vast geen RAID 6, want dat is niet heel betrouwbaar meer bij grote schijven. RAID 5 was blijkbaar al een tijdje gevaarlijk:

http://www.zdnet.com/arti...-6-stops-working-in-2019/

[boolean]

Klopt, maar JBOD is helemaal Russische roulette, gemirrord of niet. RAID 60 is "veiliger" (met behoud van snelheid) maar totaal overkill voor de geboden oplossing.

[Verwijderd]

Ligt natuurlijk ook aan de data die je overpompt. 1.000 bestanden die samen 100TB zijn gaan een stuk sneller dan 50.000.000 die samen 80TB zijn. Kan die kist uberhaupt 40Gb/s aan? Ik lees nog niets over de snelheid van de netwerkkaart(en). Kan online bar weinig vinden over de snelheden van dit ding.

[walteij]

Uiteraard ligt het aan de data die je overpompt.
Als je het sec gaat bekijken, is een dergelijke kist met schijven niets meer dan een vervoerbaar SAN dat je voor een bepaalde periode huurt. Als Microsoft een fatsoenlijk product wil verhuren (dat ook over 3 jaar nog snel genoeg kan zijn) is het installeren van de snelste fiber NICs toch wel slim.

Overigens is 100 Gbps ook al mogelijk, maar dat is helemaal kostbaar.

[Boermansjo]

Ik denk dat de bedoeling van deze box is om te gebruiken op extreme locaties. Op een schip heb je niet altijd een san met een netwerk verbinding van 40 Gb/s.
Waarschijnlijk kan Microsoft ook deze data sneller inlezen een maal de box terug komt in het server-fabriek.

[InsanelyHack]

Je hebt natuurlijk wel een systeem nodig die dat met die snelheid kan aanleveren. Ervan uitgaan dat de host 2 X 10Gb converged aangesloten zit of 2X16Gbit Dedicated Fibrechannel via twee fabrics is dat een redelijke uitdaging over de systeembus. En hoe reeel is het dat het nodig is om grote hoeveelheden data "intern" uit een systeem naar het SAN te pompen. Waarom staat het dan al niet direct op die SAN array anyway? Als het van een Array naar een ander zou moeten kan je beter de data migreren zonder tussenkomst van de host.

[walteij]

Ik ging eigenlijk ook uit van een scenario dat de data vanaf een SAN naar de Azure Data box ging kopieren. Een EMC kan deze snelheden prima aan.

Ik zou alleen wel een meertraps strategie toepassen:
- Backup maken van de data die naar Azure moet op een SAN. Dus de gewone files& folders, eventuele VHDX-bestanden, maar ook backups van SQL databases. Op die manier weet je in ieder geval zeker het tijdstip waarop de data is aangemaakt en gekopieerd gaat worden naar de Azure Box en een integriteitscheck uitvoeren;
- De backup 'uitpakken'/kopieren/restoren naar de Azure Box, uiteraard een integriteitscheck er overheen jagen;
- Azure Box vervoeren en de data in Azure laten importeren, wederom integriteitscheck;
- Dit eventueel enkele weken herhalen (als het om erg grote hoeveelheden data gaat);
- De laatste differential over het internet naar Azure verplaatsen en een laatste integriteitscheck.

[ZeRoC00L]

Het 'ding' zal vast minimaal 1 10Gb nic hebben, dus reken maar uit

[spNk]

Het ding zal waarschijnlijk ook mechanische schijven hebben met hun beperkte lees- en schrijfsnelheid.

[TweakOverflow]

Als je zo'n box samenstelt hou je echt wel rekening met deze factoren

[spNk]

Moet dat wel mogelijk zijn natuurlijk. Ik verwacht niet dat er SSD's inzitten, puur vanwege het gewicht.

[dehardstyler]

puur vanwege het gewicht.

Joh! Daarom zegt hij ook dat ze daar rekening mee houden en zinspeelt hij er dus op dat er misschien SSD's inzitten, i.v.m snelheids problemen met volschrijven. Hoezo zouden SSD's niet mogelijk zijn, waar HDD's wel mogelijk zijn?

[Thekilldevilhil]

Geen idee, maar gezien het gewicht van 20KG lijkt hardeschijven logischer. SSD's zijn ontzettend licht. Een standaard 2TB 2,5" SSD weegt zo'n 85gram.

Plus het is niet eens nodig. Je kunt een 10Gb NIC wel volledig benutten met 10 mechanische disks. 120MB/s sequentieel schrijven is niet heel bijzonder, keer 10 en je hebt al 10gbit/s.

[Reactie gewijzigd door Thekilldevilhil op 24 juli 2024 16:10]

[Brummetje]

Het gewicht komt eerder van de behuizing om het zo sterk mogelijk te maken en niet van de HDD's

[Deveon]

Of het is op basis van (trage goedkope) SSDs. Deze kunnen namelijk flink meer hebben.

[dehardstyler]

Nou ik heb vroeger in een loods van DPD gewerkt, en ik denk te weten waarom hij 20KG weegt: De schijven zijn waarschijnlijk gegoten in gewapend beton, wat ook zeker nodig is als je ziet hoe het er aan toe gaat in pakketmagazijnen haha!

Maar ik denk dat je inderdaad gelijk hebt, dat het ook prima kan met gewone HDD's. Had me even verkeken op de hoeveelheid SSD's die je wel niet nodig hebt om tot 100TB te komen. ( Speciale 10TB+ SSD's daargelaten. )

[aadje93]

of er nou data op die schijven staat of niet, dat zou voor verzending niet uit moeten maken. Immers staan ze gewoon in powerless modus (uit)

[dehardstyler]

Waar reageer je precies op, want ik snap niet waarom je dit op mij reageert?

[MaD_co]

En is dat het gewicht mét, of zonder data erop?

[spNk]

Je hebt inmiddels door dat 20KG aan SSD's een beetje te veel van het goede is zo te lezen .

[musback]

Op het eerste zicht dacht ik dat ook, 20KG is wel zwaar.
Maar bedenk dat er ook een hoop bescherming en elektronica extra in zit, misschien ook een UPS of dergelijke...

Stel 100 1TB SSD's. Dat is al 7,8Kg (als een SSD 78gram weegt),
(en als die allemaal nog een backup hebben, heb je al 15,6Kg aan schijven)
Bovendien heb je dan ook de wenselijke snelheid én weerbaarheid.

Maar het is wat speculeren natuurlijk. ik ben wel benieuwd :-)

[Lordfox73]

tijd voor een Tweakreview waarbij het ding helemaal uitelkaar mag worden getrokken :-)

[Lampiz]

Haha wedden dat de 'buren' ook even meekijken?

[FreshMaker]

Maar hoe lang duurt het om dit ding vol te schrijven met 100TB aan data? Ook niet onbelangrijk in je berekening.

Maar dat hoeft dan weer niet in één keer
Het moederschip in het filmpje heeft de data via de ROV's.
Die zal dan simultaan naar de box geschreven worden.
Lijkt me niet dat ze eerst de boel op hun eigen server zetten, en dan net voor shipping de boel even overzetten naar de box.
Deze boxen zijn gewoon ingericht als NAS, die hangen in het interne netwerk, en alle data die verzameld is, gaat direct naar de box.

Ik kan me zelfs voorstellen dat de data zelf niet eens meer aan boord gehouden wordt, maar als box 1 vol is, ondertussen box2 al meedraait.
Pas "thuis" komt de opslag via Azure bij de klant ( read only ) en bij Oceaneering ( backup / master )

Het lijkt me zelfs kostenbesparend, aangezien de schepen niet meer zelf alle apparatuur hoeven te onderhouden

[RobinJ1995]

Over SMB? Zal vast niet langer duren dan een paar weken

[netfast]

Misschien kan je deze box wel gewoon gebruiken om direct de boel op de schrijven tijdens gebruik... Dat zou de tijd daarvoor reduceren tot 0.

[Deveon]

Ligt eraan... Heb je degelijk internet toegang op moment van dat je de Azure Box aansluit voor de upload? In het filmpje zie je een voorbeeld waar de upload pas kan starten als het schip aanmeert. Op dat moment gaat de Azure Box ook de FedEx truck in.

Overigens denk ik dat FedEx dit doosje wel binnen een dag bij Azure Datacenter kan hebben hoor (en vanaf daar intern repliceert na de andere DC's)

[Nogne]

@Chuk geeft aan dat iemand anders dat heeft gezegd. Wie heeft nu gelijk ?

[Keypunchie]

Nee hoor, zelfde quote. Andy Tanenbaum heeft hem opgeschreven in een boek. Hij parafraseerde wel iemand anders. (Oftewel, hij heeft de uitspraak net iets mooier gemaakt).

Het boek dat Chuk vermeld is namelijk geschreven door Tanenbaum :-)

[Reactie gewijzigd door Keypunchie op 24 juli 2024 16:10]

[W.Martijn]

Ik neem aan dat je Andrew S. Tanenbaum bedoelt.

[Keypunchie]

Yup, bedankt. Ik fix het.

[RefriedNoodle]

Alleen is een latency van 48u wat hoog.

mb-refried:~ rn$ ping www.tweakers.net -c 1
PING www.tweakers.net (213.239.154.31): 56 data bytes
64 bytes from 213.239.154.31: icmp_seq=0 ttl=57 time= 172800000 ms

edit: round-trip zou nog dubbel zijn ook.

[Reactie gewijzigd door RefriedNoodle op 24 juli 2024 16:10]

[Sandor_Clegane]

SMB en CIFS is hetzelfde. De ene is de uit de gratie geraakte naam voor de andere.

"Never underestimate the bandwidth of a truck full of tapes". Wel toffe oplossing.

[Jeoh]

Dat is incorrect, CIFS is de naam voor een bepaalde implementatie van SMB1.

[Sandor_Clegane]

Zoals het in het artikel genoemd, lijkt het een wezenlijk ander protocol te zijn terwijl ze nagenoeg hetzelfde zijn. SMB1 en CIFS dan.

Ik denk dan ook dat er NFS had moeten staan.

[beerse]

[zeikmode aan]
Verschil tussen cifs en smb: je schrijft het verschillend
[zeikmode uit]
Wikipedia in NL laat mooi zien dat smb en cifs gelijk zijn https://nl.wikipedia.org/wiki/Server_Message_Block.

Wel vraag ik mij af wat de technische aansluiting is: Is het een netwerk aansluiting (rj45) met 10 GB? of is het een fiber aansluiting?
Of de box nfs zou ondersteunen vraag ik mij af, dat is namelijk een protocol dat ze niet altijd helemaal ondesteunen. Wel kan ik mij voorstellen dat iSCSI en dergelijke worden ondersteund.

[Sandor_Clegane]

Zal een Windows server versie op draaien, die ondersteund ook gewoon NFS.

Ze hebben het zelfs verbeterd in de laatste versies van Windows server.

[beerse]

Met msWindows is nfs is nooit gewoon ondersteund. De nfs client is niet eens op alle varianten beschikbaar, de nfs service heeft altijd een uitdaging. Al is het alleen maar omdat er een stevige mis-match is met de rechten en dergelijke. Niet alleen van de client naar nfs maar ook van nfs naar ntfs waarin het allemaal wordt opgeslagen.

[Sandor_Clegane]

Services for Unix, Interix heette het als ik me niet vergis, is gewoon ondersteund hoor.

En als ik mij het goed herinner draait het zelfs naast Win32 en niet op Win32.

[aadje93]

10GB op RJ45, waar krijgen we dat

ik denk datje 10Gb bedoelt

[InsanelyHack]

CIFS is compatible met SMB of SMB versie 1. Het verwarrende is dat je SMB kan zien als een verzamel naam van verschillende SMB versies. Iedere versie heeft extra features tov de vorige versie. Cifs is compatible met SMB1. SMB2 en hoger dus niet compatible met CIFS. In de praktijk is CIF en SMB1 erg inefficient. Het onderteunt bv geen parallel streams waardoor de doorgave snelheid stagneert op ong 50-60MB.

Volgens wiki is er ook CIF support inmiddels voor de SMB2 versie: The Linux kernel's CIFS client file system has SMB2 support since version 3.7.

[Reactie gewijzigd door InsanelyHack op 24 juli 2024 16:10]

[Jérôme]

Alleen bluetooth grinzz

[dinnnozo]

Met bluetooth 5 haal je maximaal alsnog 6.25MB/s (50Mbit/s)
https://en.wikipedia.org/wiki/Bluetooth#Uses

[Joop!e]

Zoals aadje93 ook al aangaf: 10Gb (niet GB) op koper (RJ45) bestaat.

10GBASE-T werkt tot 55m op CAT6 of 100m op CAT6a / CAT7 bekabeling.
Werkt dus prima in een data center.

[Fermion]

.

[Reactie gewijzigd door Fermion op 24 juli 2024 16:10]

[Slaut]

https://what-if.xkcd.com/31/

[Bardman01]

En uit dezelfde tijdperiode het 'sneakers netwerk' ;-)

[Sandor_Clegane]

Sneakernet

[Bardman01]

Natuurlijk maar e wiki heeft het zelfs over de latency in het sneekernet

[Caelestis]

Nee CIFS is niet hetzelfde als SMB. CIFS is een lichtelijke aangepast versie van het SMB1 protocol en wordt nog wel eens gebruikt in hele oude systemen.
SMB2 en SMB3 daarentegen hebben werkelijk helemaal niks te maken met CIFS dus mag je gerust het onderscheid maken tussen de twee.
Heeft gewoon te maken met compatibility van netwerken. Ook netwerken die al 15+ jaar oud zijn en niet aangesloten zitten op het internet voor welke reden dan ook maar ook data backups nodig hebben of voor migratie plannen.
Scheelt weer FAQ toevoegingen en helpdesk telefoontjes.

[Rabelais]

Het versturen van zeer grote hoeveelheden data is fysiek nog altijd sneller dan via internet.

Kan iemand mij uitleggen waarom dat het geval is?
Sec het transport, daar kan ik nog in komen, maar het kost toch ook tijd om de bestanden in en uit die box te krijgen?

[MiesvanderLippe]

Ja dat is zeker waar maar er zal een redelijk vlotte raid in zitten. Daarnaast is op veel plekken in America gewoon geen snelle verbinding mogelijk, zeker in upload. Onderschat ook niet hoe veel data 100TB is.

[Umbrah]

Dat, en vergeet niet dat, zelfs mét een redelijk maintenance window waar je alleen DIT in doet (data van on-site/local DC naar Azure), en NIKS anders, dat er geen byte extra meer over de lijn heen kan.

Ik werk momenteel voor een techniek reus in Nederland met echt absurd veel assets, en een toch wel vrij kritische functie. Wat we aan data genereren (en de gevoeligheid ervan) ook door een vrij ruim SCADA systeem, is niet misselijk. De cloud (Azure is het enige wat echt aan onze eisen, ook qua privacy voldoet) is voor ons een grote, belangrijke, en natuurlijke beweging. Dat betekend echter dat we van ons DC dan ook wél naar Azure moeten gaan. Helaas draaien we 24/7. Zelfs al zouden we een absurd ruim maintenance window inruimen dan nog zal de migratie absurd lang duren, en daar zit een read-only tijd aan vast. Een tool als dit zal de doorloop tijd significant verkorten terwijl we operationeel kunnen blijven: onze verbinding (die vanuit kosten natuurlijk op operationeel most valuable is aangekocht) blijft voor gebruik beschikbaar, bulk data gaat met de koerier mee, en na afloop syncen we alleen de delta.

[batumulia]

Het valt uit te leggen, maar dit is beter om te lezen

https://what-if.xkcd.com/31/

[svennd]

Wel op een schip in de midden van de oceaan heb je met geluk internet via satellieten... een paar mb downloaden is dan al een hel. Maar ook op land is het zelfde laken een broek, wij hebben om en bij de 600TB aan data staan, maar onze verbinding is maar een Gbit lijn. Reken zelf maar eens uit hoelang dat duurt om naar de cloud. en liefst zonder het gewone verkeer te verstoren ...

Zelfs nu voor alles groter dan een paar gigabyte sturen we nog steeds een schijf op, dat is veel sneller en veiliger.

[Tortelli]

Zo'n 60 dagen kost je dat, uitgaande dat je Gbit vol trekt (en overige diensten daar dus last van zullen hebben). Misschien dat het tijdelijk een optie is snelheid te verhogen, al is dat kans dat je infrastructuur klaar is voor 10Gbit internet?.....

Om een idee te krijgen; welke snelheid zou je data opslag kunnen halen, als internet niet de beperkende factor is?.

[svennd]

Een truck schijven is eenvoudiger sneller en vast goedkoper

[Fireshade]

tijd om de bestanden in en uit die box te krijgen?

Hoezo? Niet eens nodig om het uit de box te krijgen. Gewoon inpluggen en je hebt toegang tot de data.

Easy to use –Plugs right into your network, can store approximately 100 TB, and uses NAS protocols (SMB/CIFS)

[Bardman01]

Nooit een backup gedaan naar een externe lokatie, en daarna hetzelfde met tapes?

Neem het voor beeld hierboven van 100 TB in 5 uur, als het maar 5 min lopen is naar de externe lokatie, of 5 min met de auto, is dat altijd sneller via het netwerk.

Voor de sysbeheerder is het via het netwerk wel makkelijker. Zou mijn keuze zijn maar als snelheid een vereiste is...

[Chuk]

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

Computer Networks, 3rd ed., p. 83. (paraphrasing Dr. Warren Jackson, Director, University of Toronto Computing Services (UTCS) circa 1985)

Was nog nooit zo toepasselijk

[Verwijderd]

Tikje offtopic, maar voor de liefhebbers van de uitspraak "Never underestimate the bandwidth of a truck full of tapes" die deze uit de "What If" serie van XKCD nog nooit gezien hebben:

- When - if ever - will the bandwidth of the Internet surpass that of FedEx?

[Bardman01]

leuk berekening :-) En omdat HD's steeds groter worden, meer data bevatten, zal het nog steeds het geval zijn. Netwerk capaciteit is ook groter dus een nieuwe correcte berekening zou niet misstaan. Maar ik gok dat de berekening voorlopig nog in het voordeel van fysiek blijkt.

[Verwijderd]

Had Amazon een tijdje gelden niet exact dezelfde feature waarbij je "cloud" opslag makkelijk kan verschepen?

Edit: staat gewoon in het bericht.

[Reactie gewijzigd door Verwijderd op 24 juli 2024 16:10]

[Mijzelf]

Klopt. Twee jaar geleden, met 50TB.

[Ronald1302]

Zie het artikel:
[quote]Ook Amazon biedt voor zijn AWS-clouddienst datakisten aan, die hebben capaciteiten van 50TB en 80TB. Amazon zet ook een truck in voor het vervoer van data, die container kan tot 100PB over de snelweg vervoeren[\quote]

[walteij]

Uuhm ja, zoals ook in het artikel staat:

From TFA
Het versturen van zeer grote hoeveelheden data is in veel gevallen fysiek nog altijd sneller dan via internet. Ook Amazon biedt voor zijn AWS-clouddienst datakisten aan, die hebben capaciteiten van 50TB en 80TB. Amazon zet ook een truck in voor het vervoer van data, die container kan tot 100PB over de snelweg vervoeren

[walkstyle]

En je had nog nieuws: Amazon gaat 100PB-containers per truck vervoeren voor klanten

[KaiTak]

100TB is niks meer tegenwoordig. 3 weken 4K gedraaid op de Cook Eilanden en met 128TB data terug gekomen. Maar niet in een stevige box maar op 4 G-Tech G Speeds.

[servicedb]

OT maar hoeveel weegt zoiets en neem je dat mee dan? Durf je dat aan om dat in een vliegtuigkoffer te stoppen? Ik schiet zelf (prive) veel videos maar probeer het altijd via een internet verbinding te backuppen in het geval mijn externe drives kapot gaan.

[MiesvanderLippe]

Kan aan mij liggen maar dat is toch tamelijk veel materiaal.

[rvtk]

Veel materiaal maken is nooit zo moeilijk , maar het uitzoeken daarna is vaak waar het blijft hangen

[KaiTak]

300MB/sec gaat hard hoor!

[Verwijderd]

Dit concept wordt al jaren gebruikt door off location backup en cloud backup services. Dat heet dan een preload drive of een seed drive die de seed backup bevat en in het DC dan op de server gekopieerd wordt waarna alleen de restore points (incrementals van je backup chain) over het internet hoeven te gaan.