[LUGOS] več nfs strežnikov

[Joze Klepec]

Uroš Golja wrote:

> S to spremembo sicer zmanjšaš možnost, da bi dva odjemalca hkrati 
> spremenila isto datoteko, vendar pa te možnosti _ne_ odpraviš. Da iz 
> strežnika k zakleneš datoteko x na vseh ostalih strežnikih (1..k-1, 
> k+1..n), rabiš nekaj časa, recimo mu tz(k). Če dva odjemalca popravita 
> datoteko x na strežnikih k in j v času, manjšem od tz(k), potem 
> imaš... sranje, pravzaprav. Seveda lahko tz(k) zmanjšaš na minimum, 
> denimo z uporabo ločenega (=rezerviranega) omrežja za povezave 
> strežnik-strežnik in z uporabo multicasta na tem omrežju (ko en 
> strežnik govori, vsi ostali poslušajo). Trudi se kolikor hočeš, ampak 
> tz(k) te vedno lahko ulovi
>
> Poleg tega pa še vedno nismo rešili problematike padajočih linkov.
>
> Joze Klepec wrote:
>
>> Ja Uroš - za obvladanje (odprte) konzerve črvov si moraš pa zmislit 
>> protokol (=večjo konzervo ;-)), ki bo blokiral pisanje datoteke x na 
>> vseh ostalih strežnikih (n-1). Torej strežniki n -1 dobijo začasen 
>> attr r-w (po dosovsko ro) v določenem časovnem okviru. Časovni okvir 
>> je približno enak času, ki ga potrebuješ za zapis na strežnik,  
>> distribucijo po n-1 strežnikih in popravljanje atributov datotek. 
>> Popravi morebitne napake in imaš delujoč algoritem.
>>
>
E j*** ga, ampak v praksi to tako dostikrat delajo in nanje se moramo 
zanašati v 99.99999% primerih... . Sranje (ali entropija sistema po 
domače) pa pomeni tudi razpad dokumentacijskega sistema.
Ker čečkamo na množino strežnikov z zahtevo po usklajenosti, to na koncu 
privede na sklep: en sam centralni, super zmogljiv strežnik z več IP-ji 
in domenami navzven ni napačna ideja. Pravzaprav je to kar optimum: zelo 
hiter r/w strežnik A in n-1 podstrežnikov z dostopom ro, do katerih ima 
r/w dostop le A. To pa bo že bliže zadeve... .

lp, jk