mboost-dp1
unknown
I vistnok 1990/91 kunne du købe filserver til Apple Macintosh der fungerede på nogenlunde samme måde. Indholdet blev distribueret ud på de forskellige maskiner i nettet. Virkede glimrende, men det havde naturligvis de begrænsninger der nævnes. Men det var nu mest problemer med slukkede maskiner, da bærbare ikke var nær så udbredte dengang.
#49
15 min. om dagen til at starte din PC / programmer mm. ???
hmm... jeg netop taget tid på min pc. (IBM A31 / 1.6 GHz / 1 GB RAM / 4200 rpm disk).
Start af pc, login, script, policies, start af lotus notes, client access og vores intranet.
Samlet tid 3 min. og 35 sek.
PC'er skal helst genstartes hver dag... ikke fordi pc'en ikke kan klare sig, men for at sikre at der kommer nye opdateringer, scripts, policies osv. ud på klienterne..
Dine beregninger er ikke realistiske da 99% af alle medarbejder godt kan finde ud af at lave andet i de 3-5 min det tager at starte sin PC.. Læse post (hard copy), telefonere, tale med kollegaer osv.
Jeg tvivler på at man vil opnå noget stort på den konto.
Derimod er strømen ikke teoretisk... den er 100% sikker...
/Ronni
15 min. om dagen til at starte din PC / programmer mm. ???
hmm... jeg netop taget tid på min pc. (IBM A31 / 1.6 GHz / 1 GB RAM / 4200 rpm disk).
Start af pc, login, script, policies, start af lotus notes, client access og vores intranet.
Samlet tid 3 min. og 35 sek.
PC'er skal helst genstartes hver dag... ikke fordi pc'en ikke kan klare sig, men for at sikre at der kommer nye opdateringer, scripts, policies osv. ud på klienterne..
Dine beregninger er ikke realistiske da 99% af alle medarbejder godt kan finde ud af at lave andet i de 3-5 min det tager at starte sin PC.. Læse post (hard copy), telefonere, tale med kollegaer osv.
Jeg tvivler på at man vil opnå noget stort på den konto.
Derimod er strømen ikke teoretisk... den er 100% sikker...
/Ronni
Det er mig stadig et mysterie hvordan man kan opnå 160Mb/s på et 100Mb/s-netkort – det betyder vel at en del af dataene nødvendigvis skal ligge på maskinen for at opnå denne hastighed...
Antag at disken kan levere 1000Mb/s, og antag at det er et 100Mb/s-netkort, som kan levere 80Mb/s (det er nok ikke langt fra hvad det reelt vil komme til at ligge på). Lad D og N være størrelserne hvormed hhv. disken og netkortet kan levere data.
x * D + N = 160Mb/s
<=>
x = (160Mb/s - N) / D = (160Mb/s - 80Mb/s) / 1000Mb/s = 0.08 = 8%
Med andre ord skal, under de givne antagelser, (mindst) 8% af dataene ligge på den lokale maskine for at opnå en dataoverførselshastighed på 160Mb/s.
Til deltagelse i elforbrugsberegningen:
Tror nu næppe at strømforbruget på en stationær pc der står standby/Sleep Mode når ret meget over 100W.
Lad os antage at den står standby 16 timer om dagen (24 timer minus 8 timers arbejdsdag). Lad os endvidere antage at elprisen er 1,5kr/KWh, og at man arbejder alle 365 dage om året. Så ser regnestykket således ud:
100W * (16*365)h * 1,5kr/KWh = 876kr
Dvs. der er en merudgift på 876kr pr. år at medarbejderes pc står tændt. Det er jo et par timers overarbejde, en halv ny kontorstol, en kvart ny skærm om året, eller en lønforhøjelse på ca. 2,5kr pr. dag. Altsammen er det "pr. medarbejder", men...
Vær i øvrigt også opmærksom på at maskineriet stadig bruger strøm selvom den er slukket (der brugs strøm til at være klar til "Wake on LAN" o.l.). Oftest skal stikkontakten slukkes for at forbruget stoppes fuldstændigt.
Antag at disken kan levere 1000Mb/s, og antag at det er et 100Mb/s-netkort, som kan levere 80Mb/s (det er nok ikke langt fra hvad det reelt vil komme til at ligge på). Lad D og N være størrelserne hvormed hhv. disken og netkortet kan levere data.
x * D + N = 160Mb/s
<=>
x = (160Mb/s - N) / D = (160Mb/s - 80Mb/s) / 1000Mb/s = 0.08 = 8%
Med andre ord skal, under de givne antagelser, (mindst) 8% af dataene ligge på den lokale maskine for at opnå en dataoverførselshastighed på 160Mb/s.
Til deltagelse i elforbrugsberegningen:
Tror nu næppe at strømforbruget på en stationær pc der står standby/Sleep Mode når ret meget over 100W.
Lad os antage at den står standby 16 timer om dagen (24 timer minus 8 timers arbejdsdag). Lad os endvidere antage at elprisen er 1,5kr/KWh, og at man arbejder alle 365 dage om året. Så ser regnestykket således ud:
100W * (16*365)h * 1,5kr/KWh = 876kr
Dvs. der er en merudgift på 876kr pr. år at medarbejderes pc står tændt. Det er jo et par timers overarbejde, en halv ny kontorstol, en kvart ny skærm om året, eller en lønforhøjelse på ca. 2,5kr pr. dag. Altsammen er det "pr. medarbejder", men...
Vær i øvrigt også opmærksom på at maskineriet stadig bruger strøm selvom den er slukket (der brugs strøm til at være klar til "Wake on LAN" o.l.). Oftest skal stikkontakten slukkes for at forbruget stoppes fuldstændigt.
#37:
Samlet set er det 1157 PC'er der er tændt 131 timer for meget pr. uge = 151.567 timer pr. uge eller 53.957.852 timer pr. år.
Det koster ca. 0,20.- pr. time i strøm = 10.791.570,4
Hmm... meget mystisk.
151.567 timer pr. uge, den er jeg helt med på, men 53.957.852 timer pr. år?
151.567 timer pr. uge ganget med 50 uger om året giver 7.578.350, og ikke 53.957.852 (du har ganget med 356, hvorfor ved jeg ikke).
0,20kr/h, mjaeh, hvis maskineriet hapser 300W, hvilket jeg som sagt tvivler meget på, hvis de står standby.
Samlet set er det 1157 PC'er der er tændt 131 timer for meget pr. uge = 151.567 timer pr. uge eller 53.957.852 timer pr. år.
Det koster ca. 0,20.- pr. time i strøm = 10.791.570,4
Hmm... meget mystisk.
151.567 timer pr. uge, den er jeg helt med på, men 53.957.852 timer pr. år?
151.567 timer pr. uge ganget med 50 uger om året giver 7.578.350, og ikke 53.957.852 (du har ganget med 356, hvorfor ved jeg ikke).
0,20kr/h, mjaeh, hvis maskineriet hapser 300W, hvilket jeg som sagt tvivler meget på, hvis de står standby.
#53
"Det er mig stadig et mysterie hvordan man kan opnå 160Mb/s på et 100Mb/s-netkort – det betyder vel at en del af dataene nødvendigvis skal ligge på maskinen for at opnå denne hastighed..."
Det forstår jeg godt du ikke kan gennemskue, det er jo ikke en ret teknisk artikel... Lad mig prøve at uddybe testen der er udført.
Vi tager så et netværk som på http://www.cs.auc.dk/~lau/heurika/test-network.png
96 klienter alle med 10 Mbit netkort og forbundet gennem en 100 Mbit backbone. Vi lader flere klienter læse filer samtidigt og måler hvor meget der i alt ryger gennem netværket. Se resultatet i rapporten (kapitel 4).
http://www.cs.auc.dk/~jasper/dat3/heurika-report.p...
Grunden til den hurtige overførelse er dels, at få data vil ligge på samme maskine, men nok nærmere at der er tale om et swichet netværk; alle data du kan hente fra din egen afdeling er mere eller mindre gratis; du går ikke gennem flaskehalsen.
Pointen er ikke at vi opnår 160 MBit på et 100 Mbit netværk, men blot at vise hvordan systemet skalere. Ved en central fil server ville den blot kunne skalere til 100 Mbit, fordi alle klienter ville skulle gennem 100 Mbit linket.
"Det er mig stadig et mysterie hvordan man kan opnå 160Mb/s på et 100Mb/s-netkort – det betyder vel at en del af dataene nødvendigvis skal ligge på maskinen for at opnå denne hastighed..."
Det forstår jeg godt du ikke kan gennemskue, det er jo ikke en ret teknisk artikel... Lad mig prøve at uddybe testen der er udført.
Vi tager så et netværk som på http://www.cs.auc.dk/~lau/heurika/test-network.png
96 klienter alle med 10 Mbit netkort og forbundet gennem en 100 Mbit backbone. Vi lader flere klienter læse filer samtidigt og måler hvor meget der i alt ryger gennem netværket. Se resultatet i rapporten (kapitel 4).
http://www.cs.auc.dk/~jasper/dat3/heurika-report.p...
Grunden til den hurtige overførelse er dels, at få data vil ligge på samme maskine, men nok nærmere at der er tale om et swichet netværk; alle data du kan hente fra din egen afdeling er mere eller mindre gratis; du går ikke gennem flaskehalsen.
Pointen er ikke at vi opnår 160 MBit på et 100 Mbit netværk, men blot at vise hvordan systemet skalere. Ved en central fil server ville den blot kunne skalere til 100 Mbit, fordi alle klienter ville skulle gennem 100 Mbit linket.
#55:
Hmm, tak for forsøget på at forklare en novice som mig hvorledes det hænger sammen, men jeg forstår stadig ikke. Jeg ser da flaskehalsen som det netkort der sidder i den enkelte maskine. Hvis jeg sidder på en maskine, så har jeg kun adgang til alt omkring mig med 10Mb/s, hvis mit netkort er et på 10Mb/s.
Hvis jeg har forstået det helt forkert og det ikke er hastigheden af dataoverførslen til den enkelte maskine I måler på, hvor måler I så og hvordan?
Edit: Garh, man kan ikke bruge <sub>... :-/
Hmm, tak for forsøget på at forklare en novice som mig hvorledes det hænger sammen, men jeg forstår stadig ikke. Jeg ser da flaskehalsen som det netkort der sidder i den enkelte maskine. Hvis jeg sidder på en maskine, så har jeg kun adgang til alt omkring mig med 10Mb/s, hvis mit netkort er et på 10Mb/s.
Hvis jeg har forstået det helt forkert og det ikke er hastigheden af dataoverførslen til den enkelte maskine I måler på, hvor måler I så og hvordan?
Edit: Garh, man kan ikke bruge <sub>... :-/
@ Arhus Uni
Får i ikke en ret forfærdelig latens med dette system? Båndbredden er fin, men pyha, jeg kunne forestille mig det trak ud.
Får i ikke en ret forfærdelig latens med dette system? Båndbredden er fin, men pyha, jeg kunne forestille mig det trak ud.
#56: Jeg henviser lige tilbage til #18, da jeg ikke tror du fik fat i at ydelsen er målt over hele systemet, altså den samlede båndbrede for alle klienter. Hash funktionen garantere også en jævn distribution af hashværdier (og derfor blokkene) i netværket, dvs. at en fil deles op i mange dele og hver del gemmes på flere forskellige maskiner. Det er derved muligt at opnå hastigheder højere end 100 Mbit, med kommentar #55 i mente.
#57
"Får i ikke en ret forfærdelig latens med dette system? Båndbredden er fin, men pyha, jeg kunne forestille mig det trak ud."
Jeg forstår 'latens' som værende den tid skal vente på enten at hans fil er hhv. skrevet og læst. Ret mig, hvis du mener noget andet.
For at tale latens, bør vi dele det op i read og write:
Read:
Nej, Her er performance potentielt helt i top, fordi hver enkelt blok er delt ud på så mange Pc’er vælger man blot at hente fra en PC der er tæt på sig (locality) og en som har lidt at lave (load balancing). Potentielt er det hurtigere end at læse fra egen harddisk, da du ikke skal vente på cylinderen. Sidstnævnte forudsætter så at den du skal hente blokken fra har den liggende i hukommelsen.
Write:
Jo, her har vi potentielt et problem vi arbejder på at løse.
Hvis man gerne vil have en fornuftig garanti for data tab, bør man replikere til ca. 3 klienter. Dvs. hver gang du skriver en fil skal den sendes til 3 Pc’er, hvor i et centralt system skal det sendes til 1 maskine. Altså et betydeligt overhead. Derfor arbejder vi på at lave en replikationsfunktion der stiger lineært over tid, således at brugeren f.eks. kun skriver lokalt og til en anden PC. For hver replikation stiger antallet af kopier så lineært indtil der når et passende r_max.
Så jeg tror vi kan løse problemet, men i det nuværende design er det klart uholdbart.
"Får i ikke en ret forfærdelig latens med dette system? Båndbredden er fin, men pyha, jeg kunne forestille mig det trak ud."
Jeg forstår 'latens' som værende den tid skal vente på enten at hans fil er hhv. skrevet og læst. Ret mig, hvis du mener noget andet.
For at tale latens, bør vi dele det op i read og write:
Read:
Nej, Her er performance potentielt helt i top, fordi hver enkelt blok er delt ud på så mange Pc’er vælger man blot at hente fra en PC der er tæt på sig (locality) og en som har lidt at lave (load balancing). Potentielt er det hurtigere end at læse fra egen harddisk, da du ikke skal vente på cylinderen. Sidstnævnte forudsætter så at den du skal hente blokken fra har den liggende i hukommelsen.
Write:
Jo, her har vi potentielt et problem vi arbejder på at løse.
Hvis man gerne vil have en fornuftig garanti for data tab, bør man replikere til ca. 3 klienter. Dvs. hver gang du skriver en fil skal den sendes til 3 Pc’er, hvor i et centralt system skal det sendes til 1 maskine. Altså et betydeligt overhead. Derfor arbejder vi på at lave en replikationsfunktion der stiger lineært over tid, således at brugeren f.eks. kun skriver lokalt og til en anden PC. For hver replikation stiger antallet af kopier så lineært indtil der når et passende r_max.
Så jeg tror vi kan løse problemet, men i det nuværende design er det klart uholdbart.
Vil backup, vha det pågældede filsystem ikke tage meget lang tid.
Jeg ved godt at filsystemet i sig selv giver en vis form for redundans, men vel ikke i forhold til ændring eller sletning af vigtige filer.
En backup vil så foregå med måske max. backbone hastighed (da man må antage at en backupserver er placeret her - eller måske mindre, da systemet vel egentlig er designet til ikke at have en backbone) i jeres tilfælde 100 mbit.
Jeg forstår dog ikke helt hvorledes man holder styr på hvad man har af filer i virksomheden, og derfor hvad man skal have lavet backup af. Eller skal man blot lave en total backup af filsystemet, hvilken så vil blive 4gange så stor som hvis det bare var den centrale server man tog backup af.
En anden ting er belastningen af netværket.. hvorledes styrer man HVOR den enkelt fil placeres. Bliver min fil placeret på firmaets arbejdsstationer i Canada også ??
I så fald er filservere hurtigt billigere end leje af transatlantisk båndbrede.
hvis systemet er bygget på P2P går jeg ud fra at subnetting ikke er løsningen.
Hvad med rettigheder. Bliver mine filer placeret på folk som ikke skal have adgang til disses, arbejdsstationer ??
Umidelbart et sjovt koncept.
Men jeg ser ikke rigtigt nogen fremtid for projektet, udover måske på universiteter eller kollegier.
Jeg ved godt at filsystemet i sig selv giver en vis form for redundans, men vel ikke i forhold til ændring eller sletning af vigtige filer.
En backup vil så foregå med måske max. backbone hastighed (da man må antage at en backupserver er placeret her - eller måske mindre, da systemet vel egentlig er designet til ikke at have en backbone) i jeres tilfælde 100 mbit.
Jeg forstår dog ikke helt hvorledes man holder styr på hvad man har af filer i virksomheden, og derfor hvad man skal have lavet backup af. Eller skal man blot lave en total backup af filsystemet, hvilken så vil blive 4gange så stor som hvis det bare var den centrale server man tog backup af.
En anden ting er belastningen af netværket.. hvorledes styrer man HVOR den enkelt fil placeres. Bliver min fil placeret på firmaets arbejdsstationer i Canada også ??
I så fald er filservere hurtigt billigere end leje af transatlantisk båndbrede.
hvis systemet er bygget på P2P går jeg ud fra at subnetting ikke er løsningen.
Hvad med rettigheder. Bliver mine filer placeret på folk som ikke skal have adgang til disses, arbejdsstationer ??
Umidelbart et sjovt koncept.
Men jeg ser ikke rigtigt nogen fremtid for projektet, udover måske på universiteter eller kollegier.
Umiddelbart lyder systemet jo ganske tilforladeligt - og en fremtidig version vil sikkert være mere anvendlig end den nuværende ;-)
Mht. kl. 16 problemet så er det jo "bare" et spørgsmål om at definere formålet med selve filsystemet: Det er jo ikke alle filer på en maskine der er behov for at distribuere - det er kun filer der af den ene eller anden grund er øremærket som delt-resource som skal distribueres. Hvis formålet med systemet er at maximere udnyttelsen af netværket, som det postuleres at systemet er i stand til, så kan kl. 16 problemet løses ved at man har en global filserver (som normalt) og denne filserver er så kendt af alle klienter således alle distribuerede filer ligger både i netværket samt på den globale filserver (global for den enkelte virksom/organisation).
Men hvis denne løsning er god nok - så er Andrew FS jo også god nok (openafs) :-)
En anden ting: Hvordan håndteres situationen hvor flere brugere redigerer samme fil? Eller hvor flere brugere regelmæssigt læser/opdaterer en fil? Kan systemet opdatere hurtigt nok i endepunkterne så alle klienter læser samme data fra "samme" fil?
Mht. kl. 16 problemet så er det jo "bare" et spørgsmål om at definere formålet med selve filsystemet: Det er jo ikke alle filer på en maskine der er behov for at distribuere - det er kun filer der af den ene eller anden grund er øremærket som delt-resource som skal distribueres. Hvis formålet med systemet er at maximere udnyttelsen af netværket, som det postuleres at systemet er i stand til, så kan kl. 16 problemet løses ved at man har en global filserver (som normalt) og denne filserver er så kendt af alle klienter således alle distribuerede filer ligger både i netværket samt på den globale filserver (global for den enkelte virksom/organisation).
Men hvis denne løsning er god nok - så er Andrew FS jo også god nok (openafs) :-)
En anden ting: Hvordan håndteres situationen hvor flere brugere redigerer samme fil? Eller hvor flere brugere regelmæssigt læser/opdaterer en fil? Kan systemet opdatere hurtigt nok i endepunkterne så alle klienter læser samme data fra "samme" fil?
Tja, jeg ser heller ikke så meget fremtid i det her system som et direkte lagringsmedie. Der hvor jeg ser fremtiden er i et potentielt globalt videnskabeligt net. Lad os sige vi har 1000 universiteter der vil dele data, i form af forskellige dele information, så kunne man potentielt have et, stadig decentralt netværk, hvor disse organisationer kunne koble sig på og dele materialet. Det smarte ville være at systemet vil være selvorganiserende og ikke rigtigt kræve vedligeholdelse, de fleste universiteter bruger idag enorme mængder båndbredde på den slags.
Det fede ville så være bare at kunne gå ind og skrive 'mount university.net/entrynode1 /home/xxx/uninet (eller whatever), og derefter have adgang til alt hvad den node har 'tillid' til, som et systemkomponent, samtidig kunne alle elever på skolen have 'tillid', så de selv kan distribuere uden videre.
Håber det giver lidt ideer til jer, eller at i ihvertfald kan se min ide, for jeg mener helt klart der er muligheder, ikke kun i uddannelsessektoren, også i erhvervslivet :)
Det fede ville så være bare at kunne gå ind og skrive 'mount university.net/entrynode1 /home/xxx/uninet (eller whatever), og derefter have adgang til alt hvad den node har 'tillid' til, som et systemkomponent, samtidig kunne alle elever på skolen have 'tillid', så de selv kan distribuere uden videre.
Håber det giver lidt ideer til jer, eller at i ihvertfald kan se min ide, for jeg mener helt klart der er muligheder, ikke kun i uddannelsessektoren, også i erhvervslivet :)
Hej alle,
Jeg vil lige forsøge at kommentere/svare på de sidst ankommende spørgsmål/kommentare der er kommet til vores system.
#60
"Så hvis man kombinerer denne løsning, med en central server, kan man altid gemme på den centrale server, men læse fra flere klienter."
Se evt. min kommentar i 41:
"Fil systemet udvides således at en eller flere 'over knuder' kan udvælges således at disse indeholder alle filer. Disse maskiner står tændt døgnet rundt og er single point of failure når ingen andre spande er tændt. Hvad er så pointen ved at have dette filsystem?
-At der ikke er single point of failure når klienterne er tændte.
-At der er bedre udnyttelse af netværksressourcer.
-At overknuderne ikke behøver samme stabilitet og ydeevne som en almindelig filserver og er derfor billigere."
#61
"Vil backup, vha det pågældede filsystem ikke tage meget lang tid. [...]
En backup vil så foregå med måske max. backbone hastighed"
Som jeg skriver i #45 er det ikke testet, men jeg ser ingen store problemer.
"Jeg forstår dog ikke helt hvorledes man holder styr på hvad man har af filer i virksomheden, og derfor hvad man skal have lavet backup af."
Filsystemet har et rod-katalog med filer og underkataloger, som et hvert andet filsystem. Så du laver bare en ls / for at få indholdet ;-) (Dog skal der optimeres lidt i det nuværende design, men det er præncippet.
"Eller skal man blot lave en total backup af filsystemet, hvilken så vil blive 4gange så stor som hvis det bare var den centrale server man tog backup af."
Nej, nej - en backup server ville bare spørge hvad der ligger af filer i f.eks. /privat/ og så forespørge indholdet for hver af disse filer. Backupen vil fylde nøjagtigt det samme som ved en central server.
"En anden ting er belastningen af netværket.. hvorledes styrer man HVOR den enkelt fil placeres. Bliver min fil placeret på firmaets arbejdsstationer i Canada også ??"
Nej, tanken er at man har et 'system' per afdeling. Du har jo heller ikke en fil server i københavn som brugerne i Canada gemmer på.
"I så fald er filservere hurtigt billigere end leje af transatlantisk båndbrede.
hvis systemet er bygget på P2P går jeg ud fra at subnetting ikke er løsningen."
Øhm, jeg forstår ikke helt problemstillingen. Man giver vel bare hvert 'system' et navn som den multicaster med. Således at den ved join siger "hej, jeg er x.x.x.x og jeg har hermed joinet 'system Kbh'".
"Hvad med rettigheder. Bliver mine filer placeret på folk som ikke skal have adgang til disses, arbejdsstationer ??"
Ja, men vi indbygger et krypteringslag så han vil desværre ikke kunne andet end læse den krypterede version af de blokke der gemmes på hans PC.
"Umidelbart et sjovt koncept."
Det synes vi også ;-)
"Men jeg ser ikke rigtigt nogen fremtid for projektet, udover måske på universiteter eller kollegier."
Jeg er jo i sagens natur uenig, men det må fremtiden jo vise.
#63
Tak for ideerne. Vi tror på vores eget koncept, men fremtiden må jo vise hvor mange kræfter vi ligger i det og om det kan bruges i praksis. Dine ideer kunne klart være spændende til et andet system, men umiddelbart kan de ikke strikkes ind i Heurika - det er nemlig designet til at køre på LAN.
Jeg vil lige forsøge at kommentere/svare på de sidst ankommende spørgsmål/kommentare der er kommet til vores system.
#60
"Så hvis man kombinerer denne løsning, med en central server, kan man altid gemme på den centrale server, men læse fra flere klienter."
Se evt. min kommentar i 41:
"Fil systemet udvides således at en eller flere 'over knuder' kan udvælges således at disse indeholder alle filer. Disse maskiner står tændt døgnet rundt og er single point of failure når ingen andre spande er tændt. Hvad er så pointen ved at have dette filsystem?
-At der ikke er single point of failure når klienterne er tændte.
-At der er bedre udnyttelse af netværksressourcer.
-At overknuderne ikke behøver samme stabilitet og ydeevne som en almindelig filserver og er derfor billigere."
#61
"Vil backup, vha det pågældede filsystem ikke tage meget lang tid. [...]
En backup vil så foregå med måske max. backbone hastighed"
Som jeg skriver i #45 er det ikke testet, men jeg ser ingen store problemer.
"Jeg forstår dog ikke helt hvorledes man holder styr på hvad man har af filer i virksomheden, og derfor hvad man skal have lavet backup af."
Filsystemet har et rod-katalog med filer og underkataloger, som et hvert andet filsystem. Så du laver bare en ls / for at få indholdet ;-) (Dog skal der optimeres lidt i det nuværende design, men det er præncippet.
"Eller skal man blot lave en total backup af filsystemet, hvilken så vil blive 4gange så stor som hvis det bare var den centrale server man tog backup af."
Nej, nej - en backup server ville bare spørge hvad der ligger af filer i f.eks. /privat/ og så forespørge indholdet for hver af disse filer. Backupen vil fylde nøjagtigt det samme som ved en central server.
"En anden ting er belastningen af netværket.. hvorledes styrer man HVOR den enkelt fil placeres. Bliver min fil placeret på firmaets arbejdsstationer i Canada også ??"
Nej, tanken er at man har et 'system' per afdeling. Du har jo heller ikke en fil server i københavn som brugerne i Canada gemmer på.
"I så fald er filservere hurtigt billigere end leje af transatlantisk båndbrede.
hvis systemet er bygget på P2P går jeg ud fra at subnetting ikke er løsningen."
Øhm, jeg forstår ikke helt problemstillingen. Man giver vel bare hvert 'system' et navn som den multicaster med. Således at den ved join siger "hej, jeg er x.x.x.x og jeg har hermed joinet 'system Kbh'".
"Hvad med rettigheder. Bliver mine filer placeret på folk som ikke skal have adgang til disses, arbejdsstationer ??"
Ja, men vi indbygger et krypteringslag så han vil desværre ikke kunne andet end læse den krypterede version af de blokke der gemmes på hans PC.
"Umidelbart et sjovt koncept."
Det synes vi også ;-)
"Men jeg ser ikke rigtigt nogen fremtid for projektet, udover måske på universiteter eller kollegier."
Jeg er jo i sagens natur uenig, men det må fremtiden jo vise.
#63
Tak for ideerne. Vi tror på vores eget koncept, men fremtiden må jo vise hvor mange kræfter vi ligger i det og om det kan bruges i praksis. Dine ideer kunne klart være spændende til et andet system, men umiddelbart kan de ikke strikkes ind i Heurika - det er nemlig designet til at køre på LAN.
jkjonline:
Har i tænkt på den eventuelle belastning af harddisken ?
Hvis jeg sidder og arbejder ved en maskine hvor harddisken kører som en gal, bliver mit arbejde sløvet hvis jeg skal noget på disken.
Dette problem ville jo reelt blive ret stort med jeres netværk, og rigtigt slemt på laptops, hvor harddiskene er notorisk langsomme.
Har i indbygget en form for load balancing ?
Altså så det ikke altid er den samme maskine der bliver hentet på, men skiftevis på en af de f.eks. 4 filen ligger på ?
Har i tænkt på den eventuelle belastning af harddisken ?
Hvis jeg sidder og arbejder ved en maskine hvor harddisken kører som en gal, bliver mit arbejde sløvet hvis jeg skal noget på disken.
Dette problem ville jo reelt blive ret stort med jeres netværk, og rigtigt slemt på laptops, hvor harddiskene er notorisk langsomme.
Har i indbygget en form for load balancing ?
Altså så det ikke altid er den samme maskine der bliver hentet på, men skiftevis på en af de f.eks. 4 filen ligger på ?
#65
"Har i indbygget en form for load balancing ?
Altså så det ikke altid er den samme maskine der bliver hentet på, men skiftevis på en af de f.eks. 4 filen ligger på ?"
Ja, som systemet er designet nu vælger klienten tilfældigt hvilken af de $R$ maskiner den vil hente blokken fra. Desuden garanterer den hash-funktion vi bruger, at blokke fordeles lige mellem de klienter der deltager.
En udvidelse vi pt. arbejder på kommer til at ændre beslutningen således at loaded fra maskinerne og lokalitet fra maskinerne også får indflydelse på hvorfra blokken hentes. Lokalitet er ekstremt vigtigt i wide-area-networks pga. afstanden, men i lokal-netværk som Heurika er designet til er lokaliten vigtig for at systemet kan overleve nedbrud i backbonen. Som Kap. 3 i rapporten viser er vores system lige så dårlig til at håndtere et sådant netsplit som et centralt fil-delings system. Desuden vil en ændring af lokaliten også have en positiv indflydelse på hastigheden i Mbit/sekund.
Men for at summere op; ja systemet sørger for at en klient ikke skal stå for at dele en populær fil, det vil blive fordelt mellem alle klienter og på sigt mest mellem de klienter der har mindst at lave på et givet tidspunkt og som der er tæt på modtageren.
"Har i indbygget en form for load balancing ?
Altså så det ikke altid er den samme maskine der bliver hentet på, men skiftevis på en af de f.eks. 4 filen ligger på ?"
Ja, som systemet er designet nu vælger klienten tilfældigt hvilken af de $R$ maskiner den vil hente blokken fra. Desuden garanterer den hash-funktion vi bruger, at blokke fordeles lige mellem de klienter der deltager.
En udvidelse vi pt. arbejder på kommer til at ændre beslutningen således at loaded fra maskinerne og lokalitet fra maskinerne også får indflydelse på hvorfra blokken hentes. Lokalitet er ekstremt vigtigt i wide-area-networks pga. afstanden, men i lokal-netværk som Heurika er designet til er lokaliten vigtig for at systemet kan overleve nedbrud i backbonen. Som Kap. 3 i rapporten viser er vores system lige så dårlig til at håndtere et sådant netsplit som et centralt fil-delings system. Desuden vil en ændring af lokaliten også have en positiv indflydelse på hastigheden i Mbit/sekund.
Men for at summere op; ja systemet sørger for at en klient ikke skal stå for at dele en populær fil, det vil blive fordelt mellem alle klienter og på sigt mest mellem de klienter der har mindst at lave på et givet tidspunkt og som der er tæt på modtageren.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund