Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 90 reacties
Submitter: VerySmart

Hogeschool Inholland heeft een nieuwe netwerktool in gebruik genomen voor de verspreiding van software binnen het schoolnetwerk. De tool is gebaseerd op het bittorrent-protocol en verspreidt een update binnen 4 uur over 6500 computers.

Hogeschool InhollandInholland had voorheen 20 servers in gebruik, die 4 dagen nodig hadden om een update uit te rollen, zo meldt Torrentfreak. In de nieuwe opzet maakt de hogeschool gebruik van 2 servers die Microsoft Systems Management Server 2003 draaien. Via een speciaal gebruikersaccount, dat niet toegankelijk is voor studenten, kan een update binnen 4 uur over de 6500 schoolcomputers uitgerold worden, waarbij de schoolcomputers ingezet worden om de update verder te verspreiden.

Hogeschool Inholland heeft voor de ontwikkeling van de bittorrent-netwerktool de hulp ingeroepen van een extern bedrijf. De tool is gebaseerd op Bittorrent DNA waardoor een update of migratie niet meer vanuit een centrale server verspreid hoeft te worden, maar alle computers in het netwerk gebruikt worden om de update of migratie over het hele netwerk uit te rollen. Deze manier van systeembeheer zou niet alleen geld besparen omdat er minder hardware nodig is, ook zou het veel minder tijd kosten om een groot aantal computers te migreren.

Moderatie-faq Wijzig weergave

Reacties (90)

Dé grote boosdoener qua belasting, is het weg-en weer verkeer. Bij bit-torrents begint degene die downloadt, automatisch ook te verdelen (uploaden) naar andere peers die ook nog aan de torrent hangen.

Echter, ieder pakketje wordt slechts één keer aangeboden, aangezien de torrent-client (software die nodig is om bit-torrents binnen te halen), bijhoudt wat er reeds aanwezig is en aan de verdeler die pakketjes vraagt die nog nodig zijn om de torrent te vervolledigen. Dat heeft dan weer als voordeel dat er geen onnodige bandbreedte wordt verkwist aan onnodige pakketjes die heen en weer worden geslingerd.

Ander voordeel is de cumulatie van de down- en uploadsnelheden van de peers (zij die aan de torrent hangen). Iemand die een torrent aanbiedt, zal in de beginne natuurlijk de enige verdeler (seeder) zijn, omdat hij de enige is met een volledig pakket. Wiskundig gezien zouden degenen die downloaden alles bij elkaar geen hogere downloadsnelheid kunnen halen dan de uploadsnelheid van de aanbieder.

Bit-torrent clients verdelen de gehashte files echter niet in volgorde, en peer A zal ook niet altijd hetzelfde pakketje terzelfdertijd downloaden dan peer B of C of D, waardoor iedereen constant iedreen kan 'bevoorraden', wat resulteert in, zoals eerder gezegd, een cumul van de down- en uploaders hun snelheid.

Eens er genoeg seeders zijn, kan de originele aanbieder zich terugtrekken en de verdeling overlaten aan de rest. Het is dus zaak, indien men de files aan zoveel mogelijk mensen wil aanbieden, van de torrent-client zolang mogelijk open te laten en te blijven seeden.

Binnen een eigen netwerk hebben bit-torrents weinig zin, aangezien het makkelijker is van de software aan te bieden via een server, zelfs indien er meerdere servers voor de verdeling moeten zorgen. In dit geval, betreft het een aangepaste bit-torrent client, waardoor het voor de InHolland Hogeschool blijkbaar wel nuttig is van updates uit te voeren via de bijgewerkte torrent client.

Bram Cohen, de bedenker van de oorspronkelijke bit-torrent en de bijbehorende client, heeft zijn systeem enkel en alleen uitgedokterd, omdat bij reguliere downloads, de ontvangende PC het hele pakket in één keer binnen trekt, wat zeer zwaar weegt op de PC. Bit-torrent clients maken van het grote file een hash, ofte verdelen het geheel in kleinere stukjes, die dan gecodeerd één voor één worden binnegehaald en in de goeie volgorde worden gezet, wat veel minder op de PC weegt.

Verder was het de idee om, ipv één anbieder die constant iedereen moest bevoorraden, een client te maken die met alle peers onderling kon contact zoeken via een code in het hash- of torrentfile...

[Reactie gewijzigd door JimmyJump op 8 maart 2008 18:27]

Ik vind het een prachtig elegante oplossing eigenlijk, en qua netwerkbelasting:

Elke pc zal de update echt maar 1x krijgen (+ een klein beetje extra voor wat error control etc).

Dus qua download zal het gelijk blijven. Upload wordt natuurlijk ook niet hoger, want elke pc zal 1 download ontvangen, dus 1 download verstuurd krijgen. Enige andere is, is dat de update nu niet van 20 centrale servers komt, maar van 6669 andere computers (seeders).

Duz dat argument snap ik niet helemaal.
Het is meer hoe het netwerk gebruikt wordt. Bij een centrale server gaat alles 6500 keer over het (vaak duurdere) netwerk tussen de locaties. Als je op elke locatie een server hebt die eerste geupdate wordt en dan alle computers op die locatie update gaat alles maar een paar keer over het tussenliggende netwerk. BitTorrent is qua belasting vergelijkbaar met de centrale server aangezien slechts een klein deel van de blocks van het lokale netwerk zal komen en de meeste van netwerken op andere locaties. Verder is er een heel praktisch verschil: BitTorrent is in 4 uur klaar en de servers in 4 dagen. Dat betekent dat BitTorrent het netwerk 10x zo intensief gebruikt.

Overigens kan de tracker ook de voorkeur geven aan dichtbijzijnde peers, maar daar doe ik nog onderzoek naar.

[Reactie gewijzigd door tybris op 9 maart 2008 10:33]

Toevallig dat ik daar net per februari ben vertrokken, technisch best knap in elkaar gezet allemaal maar het draait al weer een tijdje zo (Tegelijk met de migratie naar het nieuwe office pakket opgezet).

en dat 100Mbit is ruim voldoende met die infrastructuur. Meeste computerlokalen (30-40 machines per ruimte) hebben een switch die met 1Gbit aan de backbone hangt. ongeveer 90 minuten om alle machines in een lokaal te migreren (handmatig in die gevallen). Voorheen was overduidelijk het netwerk een vertragende factor. nu is het een kwestie van een paar machines aan het werk zetten en na een paar minuten de volgende batch. zo is de hoeveelheid data binnen die ene switch wel hoog, maar hoeft het niet van het datacenter (op een andere lokatie) of vanuit de lokale servers te komen.
Er zijn wel veel baten genoemd.

Maar vergeet niet dat er enorme belasting optreedt op het netwerk.
Maar is die belasting slecht dan? Ik snap niet waarom er door sommigen altijd zo'n probleem van gemaakt wordt. Want het is helemaal geen probleem. Heb jij ooit gehoord dat er iets mis is gegaan door een te hoge belasting van het internet?

Als de belasting te hoog dreigt te worden moet de capaciteit van het netwerk uitgebreid worden. Is technisch prima realiseerbaar en zorgt alleen maar voor vooruitgang.
Op een intern netwerk van bijvoorbeeld een hogeschool, waar de meeste verbindingen (van de desktop PC's naar de switches) normaal gesproken voor minder dan 1% oid gebruikt worden maakt de extra belasting nauwelijks uit. In princiepe is het versturen van bitjes van client A naar client B over het netwerk even 'duur' als vanaf server A naar client B, er even van uitgaande dat alle PC's op 1 fysieke locatie staan. Een p2p oplossing kan dan ook wel degelijk een besparingen opleveren.

Op internet is dit echter niet het geval. Bittorrent is dan ook bedoelt om het downloaden goedkoper te maken voor de aanbieder. Per saldo kost het internetgebruikers in het algemeen echter alleen maar meer. Een bittorrent client in de US zal een stukje uploaden naar een client in de EU, en die upload het weer naar een andere client in de US. Uiteindelijk is het twee keer over een trans-Atlantische kabel geweest, terwijl er waarschijnlijk wel een andere client in de EU was die dat stukje torrent ook heeft.

Geografisch gespreide servers hebben dit probleem niet. De data wordt een maal verstuurd over een dure(in aanleg en onderhoud) trans-Atlantische verbinding. De eindgebruikers downloaden het dan weer van een lokale server. Met een beetje geluk is deze lokale server via een lokale, en goedkope, internet exchange beschikbaar.

Daarbij komt nog dat een gigabit verbinding in een datacentrum vele malen goedkoper is(per mbit) dan een gemiddelde consumentenverbinding. Het transporteren van bitjes naar Piet Pietersen in een of ander plattelandsdorpje is vanwege de schaalgrote nu eenmaal duurder dan naar een datacentrum, waar toch al apperatuur aanwezig is om vele tientallen terra bits doorheen te pompen.

Samengevat zijn we door p2p met zijn alle meer gaan betalen voor onze internetverbinding. Niet alleen omdat er uberhoubt meer gedownload wordt nu, maar ook omdat p2p netwerk technisch gezien enorm inefficiënt is. Dat wil overigens niet zeggen dat p2p geen nut heeft. Het aanleggen van een geografisch gespreid netwerk cluster is nu eenmaal niet voor iedereen betaalbaar</understatement>.

PS. Ik wil hiermee enkel uitleggen dat netwerk belasting door p2p daadwerkelijk een probleem is. Ik heb niet uitgerekend of de kosten van de extra servers opwegen tegen de extra kosten in netwerkapparatuur.
P2P binnen een bedrijfsnetwerk is geen enkel probleem. Het grote verschil is uiteraard dat alle data gemanaged aangeboden wordt. Met andere woorden De afdeling IT bepaald wat er rond gaat. Bovendien is de client gedurende productie ' geknepen' zodat eindgebruikers altijd ongestoord kunnen blijven werken.

P2P op het internet moet niet vergeleken worden met P2P voor bedrijfsmatige toepassingen. Appels met Peren vergelijken toch??
P2P op het internet moet niet vergeleken worden met P2P voor bedrijfsmatige toepassingen. Appels met Peren vergelijken toch??
Dat klopt tot op zekere hoogte. De meeste grotere bedrijven hebben meerdere vestigingen met daar tussen een relatief trage WAN verbinding. Men dient te zorgen dat juist deze tragere WAN verbinding niet compleet vol loopt waardoor replicatie / inter site verkeer hinder ondervind. De meeste torrent oplossingen bieden echter geen mogelijkheid om het netwerk in zones onder te verdelen. Een oplossing zou kunnen zijn het tegenhouden van inter site torrent verkeer door een firewall of router en dan de torrents op elke lokatie te verspreiden.
het schooltje waar ik werk heeft tussen alle vestigingen glas liggen...
Wat maakt het uit voor de belasting? een netwerk dat 24u per dag voor 2% belast is, lijkt mij een desinvestering. Er ligt dan gewoon verloren kapitaal.

Daarbij in deze situatie zou je de updates heel goed snachts over het netwerk kunnen blazen hebben de gebruikers er geen last van.
Op een school? Gewoon vrijdagochtend beginnen, en maandag eindigen (de meeste studenten toch thuis). Nauwelijks last van.

Een bedrijf zal dan wel wat limieten opzetten om tijdens kantooruren de belasting binnen de perken te houden, maar na werktijd maakt netwerkbelasting echt helemaal niks uit.
Je hebt capaciteit toch juist zodat je het kan benutten? Beter dan dat al due netwerkapparatuur staat te idlen ;)
Hoge Netwerk Belasting??

Is deze niet gelijk aan het oude systeem. Deze zal dan wel versprijd zijn.
Daarnaast wordt er geen gebruik gemaakt van servers. maar van de clients zelf die versturen. Servers worden hierdoor totaal niet belast. Alleen de clients.

De belasting bij de switches zullen ook wel mee vallen. door gebruik te maken van restricties op het Protocol. (QoS)
Je kan het protocol een fixed belasting per client opgeven. zodat b.v elke client maar 100kb/s verstuurt. uitgaande dat ze 48 poorts switches hebben 4800kb/s dat is niets voor zo'n switch.

Verder kunnen we natuurlijk alleen maar gissen. want wij weten allemaal niet hoe netwerk is geconfigureerd. Wel kan er gesugereerd worden dat elke switch zijn eigen boontjes dopt. en de servers alleen zijn updates versturten naar enkele clients per switch.
Minder belasting als voorheen,

Server -> switch 1 -> switch 2 -> pc1 (100mbit 100% bezet, heel de weg)
Server -> switch 1 -> switch 2 -> pc2 (idem.)

Server -> switch 1 -> switch 2 -> pc1 (100mbit heel de weg)
pc1 -> switch 2 -> pc2 ( alleen switch 2 gaat nog voor 100mbit in het touw)
Niet helemaal, er is meer trafiek, maar deze is verspreid, het voordeel aan deze techniek is dat er geen stress punten ontstaan, als je daarnaast nog eens je QoS goed instelt dan ga je normaal weinig problemen ondervinden van de extra belasting.
daar heb je gelijk in...

maar het is wel een goeie oplossing voor geld besparen ja!
en binnen 4 uur 6500 computers geupdate is zeker niet slecht :)

[Reactie gewijzigd door Iceman1991 op 8 maart 2008 11:48]

Als het goed is zitten niet alle 6500 computers aan één kabeltje!

Ieder lokaal, iedere vleugel, ieder gebouw, iedere plaats hebben allemaal een eigen knooppunt. De bandbreedte wordt geleidelijk aan verdeeld over het héle netwerk.

Moet je voorstellen wat voor een bandbreedte er gevreten wordt als alle computers tegelijkertijd worden geupdate... De verbinding bij de bron slibt dan helemaal dicht.

Dat probleem is op deze wijze verholpen en daarom gemiddeld een lichtere "load". :)

Persoonlijk vind ik het een geniaal systeem _/-\o_
Het lijkt me dan vrij logisch dat ze dan alleen updates zullen doorvoeren in het begin van de avond of 's nachts.
Daar heb je wel een punt, maar vergeet niet dat het in de oude situatie niet veel anders is. Voor het uitrollen van een update op deze schaal is nou eenmaal veel bandbreedte nodig.

Daarbij zou men nog door slimme cache en distributie methoden, voor wanneer het systeem minder belast wordt, het netwerk kunnen ontzien. Want zeg nou eerlijk, wie is er nou 's avonds laat nog op school. ;)
Met BT kun je ook het upload / download gebruik van de clients instellen, als dit een groot probleem is kunnen ze de max totale download wel instellen.
Dat heet optimaal gebruik maken van je resources.
Dat scheelt wel weer 18 servers en 92 uur om die updates uit te rollen.
Scheelt dus in stroom onderhoud etc.
Alleen worden de update's die verspreid word ook weer verwijderd ? (bedoel dus het instalatie paketje :P)
Anders loopt binnen no time je HD vol en dan kan je dus niks meer.
Verder vind ik het wel heel erg goed gevonden om zo gebruik te maken van p2p.
Hoezo moeten de update-pakketjes weer verwijderd worden? Geen idee of jij Windows-gebruiker bent en uberhaupt een servicepack ooit hebt geinstalleerd maar die staat mooi ergens in je windows-dir uitgepakt en wel. Is namelijk handig voor toekomstige updates om bepaalde files te checken etc.

Daarbij zie ikzelf geen noodzaak om de update-pakketjes te verwijderen; geen idee hoe groot de schijven zijn op de Hogeschool maar aangenomen dat de studenten-data ergens anders staat, moet je met een ouderwetse schijf van 20GB toch aardig uit de voeten kunnen in de lifecycle van een Windows-OS, zelfs als je alle updates erop laat staan.
Denk niet dat je de pakketen op je machine wilt houden. je gaat anders je bestanden in je download dir houden en in je windows dir. of andere programatuur directory. Niet alleen Microsoft updates zullen dmv deze oplossing worden aangeboden.

Je hebt namelijk het gedownloade bestand en de instalatie inc eventeul repair files. Gedownloade bestand kan na het uplaoden verwijderd worden.
Dat verwijderen zal wel gebeuren nadat de file voor de update gebruikt is. Wellicht gebeurt dit laatste pas (op commando) een tijdje na het downloaden van de file. Tot dat moment wordt de file geshared.

Wat ook kan is dat bittorrent op een lager niveau gebruikt wordt. M.a.w. de computer (Windows) wil een update ophalen en doet dit uit zichzelf via Bittorrent. In dat scenario is dus geen "externe" download procedure nodig en zal de file alleen geshared worden als de download plaatsvindt. Direct na het binnenhalen wordt de file door windows gebruikt en verwijderd.

[Reactie gewijzigd door grizzlybeer op 8 maart 2008 11:58]

Zelfs al zouden ze een 40 GB HD hebben, dan nog kan je die niet vol krijgen met software updates, of je moet wel extreem veel te updaten hebben.
Ik hoop dat ze heel goed nagedacht hebben over de beveiliging, dit is namelijk voor de helft al een virus, om het distributiegedeelte hoef je je dan geen zorgen te maken.

@Silver7:
Het bittorrent protocol levert uiteindelijk juist een veel lagere belasting van het netwerk op, vergeleken met de standaard centrale methode.
Microsoft is op een omgekeerde manier bezig. Ze onderzoeken het gedrag van worms en dergelijke om er een verbeterde versie van te maken, en zo sneller patches te kunnen verspreiden ^^

http://technology.newscie...pread-software-fixes.html
Hoe kom je er in godsnaam bij dat dit een virus is? Een virus is bij mij nog altijd iets dat ongevraagd verspreid word en dat probeerd zonder de toestemming van de eigenaar van de PC data te manipuleren of te versturen.
Wat smokalot waarschijnlijk bedoeld is dat de beveiliging wel heel goed op orde moet zijn want anders kan iemand met minder goede bedoelingen heel snel malware verspreiden over 6.500 PC's.
Waarom niet multicasten? Dan hoef je de update er maar 1 keer uit te sturen, en binnen een lan is multicast prima mogelijk.
wat denk je dat multicast fysiek doet?
Het stuurt de data alsnog naar alle stations en zelfs naar stations die niet gesubscribed zijn aan de multicast group. Met andere woorden je maakt zelfs onnodig veel dataverkeer met multicast.
Hetzelfde verhaal met broadcast.
Natuurlijk moet elk bitje nog fysiek bij de clients aankomen. Daar gaat het toch ook helemaal niet om.

Het voordeel van multicast dat de server het maar 1 maal hoeft te versturen. Op elke tussenliggende verbinding van router naar router en van switch naar switch hoeft het maar 1 maal getransporteerd te worden, onafhankelijk van hoeveel clients er achter hangen. Het updaten van 1 client duurt net zo lang als het updaten van 10000 clients.

Het is niet waar dat bij multicast het verkeer altijd verstuurd wordt naar elke client. Als in een netwerksegment(achter een multicast ondersteunende router) niemand gesubscribed is dan wordt de data niet verstuurd. Het probleem is dat als er wel iemand, als is dit maar 1 client, de data wil ontvangen deze op ethernet niveau gebroadcast wordt. Dit is echter niet echt een probleem. Verspreid de update op bijvoorbeeld 50mbits, dan heb je nog 50mbits over voor andere dingen. Met QoS moet dat wel te regelen zijn. 50mbit is nog steeds meer dan voldoende voor gemiddeld kantoor/school gebruik, bovendien is het maar tijdelijk.

Het probleem met multicast is wat je moet doen als het niet helemaal lekker gaat. Wat doe je als door netwerkproblemen een paar pakketjes niet aankomen bij een client? Het hele bestand opnieuw versturen net zolang tot iedereen het heeft? Redundante data versturen zodat de clients de missende gedeelten kunnen reconstrueren?
Ligt er aan hoe jij je multicast traffic geconfigureerd hebt.
Indien jij het als spare mode configureerd wordt het multicast verkeer alleen naar de gebruikers gestuurd die zich hebben aangemeld op de multicast group
Ik vraag me af of er ook een soort exploit komt voor het bittorrent protocol. Als je een soort MITM attack kan uitvoeren en zo andere data richting de clients kan krijgen kun je op deze manier ook enorm snel een heel netwerk infecten... Dus of de executable die richting de machines gaat replacen met een eigen versie, of de torrent die richting de client gaat veranderen. Lijkt me leuk om eens te testen.
Bittorrent gebruikt hiervoor hashing. Zo weet de client zeker dat hij download wat hij moet downloaden.. In de torrent-file staat de URL van de tracker en een hash waarmee de client kan controleren of hij wel het juiste file gedownload heeft. Je zou dan dus de hele torrent-file moeten vervangen.
CMG zit wel op een leuk spoor...

Het controleren van hashes zorgt er alleen voor dat het bestand dat binnengehaald wordt geen fouten bevat.

De pc's krijgen een melding van de centrale server over een nieuwe update. Met een MITM attack doe je voor alsof jij de centrale server bent die de melding naar de pc's stuurt. Je verzend een soort ".torrent" bestand en de pc gaat dit vrolijk binnenhalen. Als er eventueel gecontroleerd wordt van welke tracker er gedownload wordt, kan je via DNS spoofing het adres vervormen en de controle omzeilen.

Zolang de melding en het binnenhalen van de ".torrent" bestanden van de centrale servers naar de pc's maar beveiligd is, zou er geen problemen moeten zijn. Dit zou bijvoorbeeld via een SSL verbinding kunnen. Als eenmaal bekend is welk bestand er gedownload moet worden, kickt de hashbeveiliging in.
MITM is in principe voor elk protocol toepasbaar ALS je VOLLEDIG de zender kan imiteren. Dan moet je dus wel volledig kunnen spoofen, terwijl als je een goed geregeld netwerk hebt (waarbij Level 3 switches gebruikt worden die dus ook alleen specifieke ip's doorlaten) dat niet gaat lukken.
Ach, er zijn genoeg bt poison methodes, vraag maar aan de anti piraterij instanties.
Het is echter niet effectief genoeg om serieuse schade te veroorzaken.
Heb je hier ook concrete bewijzen voor? Het hele principe van het hashen van pieces is dus dat dit redelijk onmogelijk is. Tuurlijk kan je als je heel erg je best doet een hash collision vinden en daarmee eventueel een file corrupt maken, maar de tijd die nodig is om een collision hash te vinden staat in geen vergelijking tot de tijd dat een torrent 'in de lucht is' (vaak maar enkele dagen).
Erg slim bedacht.. Microsoft zou dit van mij best mogen overnemen en standaard in WSUS/Software Deployment inbouwen :)

[Reactie gewijzigd door Radiant op 8 maart 2008 12:24]

BRILJANTE inzet van beschikbare middelen.

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True