Ji°φ Peterka

Nev²hody plynoucφ ze vzßjemnΘ izolovanosti samostatn²ch osobnφch poΦφtaΦ∙ jsme si zd∙raz≥ili ji₧ minule, a proto jen struΦn∞: problΘm je jednak se sprßvou mnoha samostatn²ch poΦφtaΦ∙, kterΘ musφ mφt vÜechno pot°ebnΘ äu sebe" (a n∞kdo musφ toto ävÜechno" udr₧ovat, aktualizovat atd.). Druh²m zßkladnφm problΘmem byla spoluprßce u₧ivatel∙ samostatn²ch poΦφtaΦ∙, nap°φklad jejich p°φstup do jednΘ a tΘ₧e databßze, obecn∞ pak prßce nad spoleΦn²mi daty. Majφ mφt vÜichni svΘ vlastnφ repliky? Jak to bude s jejich pr∙b∞₧n²mi aktualizacemi?

V p∙vodnφm centralizovanΘm sv∞t∞, ob²vanΘm modelem host/terminßl, obdobnΘ problΘmy sice takΘ vznikaly, ale byly mnohem snßze °eÜitelnΘ, proto₧e k nim dochßzelo jen jedenkrßt a na jednom mφst∞. Nelze se tedy divit, ₧e lidΘ brzy pocφtili pot°ebu vzßjemn∞ propojit svΘ osobnφ poΦφtaΦe, a za°φdit v∞ci tak, aby alespo≥ n∞kterΘ soubory mohly b²t ulo₧eny centrßln∞ a mohly b²t sdφleny vφce u₧ivateli.

Na pomoc p°ichßzφ Ethernet

Ethernet m∞l tΘm∞° ideßlnφ vlastnosti k tomu, aby pokryl vznikajφcφ pot°ebu propojenφ osobnφch poΦφtaΦ∙. Byl relativn∞ jednoduch², a nebylo p°φliÜ t∞₧kΘ jej implementovat. M∞l sice mal² dosah (stovky metr∙), ale to nijak moc nevadilo, proto₧e m∞l v∞tÜinou slou₧it k propojenφ poΦφtaΦ∙ nachßzejφcφch se nep°φliÜ daleko od sebe. Hlavn∞ ale byl dostateΦn∞ rychl² - jeho nominßlnφ p°enosovß rychlost 10 megabit∙ za sekundu umo₧nila p°enßÜet soubory tak rychle, ₧e ji₧ nemusel vznikat markantn∞jÜφ rozdφl mezi p°φstupem k mφstnφm soubor∙m a p°φstupem ke vzdßlen²m soubor∙m, nachßzejφcφm se na n∞kterΘm jinΘm poΦφtaΦi. Prßv∞ to byl toti₧ velmi podstatn² moment, umo₧≥ujφcφ p°ekonat psychologickou bariΘru v pohledu u₧ivatel∙ na sdφlenΘ soubory a za°φdit v∞ci tak, aby u₧ivatel vlastn∞ ani nemusel tuÜit ₧e pracuje se vzdßlen²m souborem.

Vznikajφ file servery

Jak ji₧ jeho nßzev naznaΦuje, je file server serverem, a tudφ₧ poskytovatelem urΦitΘ slu₧by (zatφmco ostatnφ uzly, kterΘ jeho slu₧by vyu₧φvajφ, jsou v∙Φi n∞mu v postavenφ klient∙). Obsahem poskytovanΘ slu₧by nenφ nic jinΘho ne₧ uchovßvßnφ soubor∙ - file server nabφzφ sv²m klient∙m, ₧e pro n∞ na sv²ch discφch uchovß jejich soubory. Pro konkrΘtnφ napln∞nφ tΘto slu₧by pak od sv²ch klient∙ p°ijφmß p°φkazy typu: äzde je obsah souboru X.Y, uchovej si jej u sebe", Φi äpoÜli mi obsah souboru XY".

Zajφmavß je na celΘ v∞ci i skuteΦnost, ₧e klient nemß file serveru co mluvit do toho, jak si on jeho soubory uklßdß na sv∙j disk. Je v∞cφ file serveru, jakΘ äsouborovΘ hospodß°stvφ" si zvolφ a bude pou₧φvat. Dφky tomu je nap°φklad mo₧nΘ, aby file server i jeho klient stßli na odliÜn²ch platformßch - aby nap°φklad file server byl Unixov²m strojem, a soubory si uchovßval äUnixov²m" zp∙sobem, zatφmco jeho klient byl osobnφm poΦφtaΦem s MS DOSem.

P∙vodn∞ existovaly jeÜt∞ takΘ tzv. diskovΘ servery (disk servers), ale ty Φasem zanikly. Byly charakteristickΘ tφm, ₧e na rozdφl od file server∙ poskytovaly svou diskovou kapacitu äna stojato": jejich klienti jim posφlali po₧adavky typu äzapiÜ tato data do sektoru X stopy Y cylindru Z", Φi änaΦti mi obsah sektory X stopy Y na cylindru Z". Zde to tedy byl klient, kdo se staral o organizaci soubor∙ na disku, zatφmco v p°φpad∞ dnes zcela dominujφcφch file server∙ je toto ·kolem file serveru.

Sprßvn² file server nenφ vid∞t

P°edstava p°esm∞rovßvaΦe (redirectoru, shellu)

P°edstava mapovßnφ adresß°ov²ch strom∙

PraktickΘ napln∞nφ äneviditelnosti" Φi lΘpe ätransparentnosti" sdφlenφ soubor∙ na file serverech se samoz°ejm∞ setkalo i s jist²mi potφ₧emi. Nap°φklad operaΦnφ systΘm MS DOS, dominujφcφ na osobnφch poΦφtaΦφch standardu IBM PC, v∙bec nepoΦφtal s existencφ sφt∞. Nedokßzal sprßvn∞ nalo₧it s po₧adavkem b∞₧φcφ aplikace na p°φstup k souboru, kter² je ve skuteΦnosti po₧adavkem na p°φstup ke vzdßlenΘmu souboru (hlavn∞ nedokßzal tento po₧adavek p°edat n∞komu jinΘmu, kdo jej dokßzal vy°φdit). NaÜt∞stφ se ale i zde °eÜenφ naÜlo - MS DOS se p°ekryl tenkou vrstviΦkou äp°esm∞rovßvaΦe" (redirectoru, shell-u), kter² rozhodoval za n∞j - jednotlivΘ po₧adavky od aplikacφ p°ijφmal tento äp°esm∞rovßvaΦ", a pouze po₧adavky na p°φstup k mφstnφm soubor∙m p°edßval dßl MS DOSu, zatφmco po₧adavky na p°φstup ke vzdßlen²m soubor∙m p°edßval p°φsluÜnΘ Φßsti sφ¥ovΘho programovΘho vybavenφ (viz obr. 1).

V²sledn²m efektem p∙sobenφ p°esm∞rovßvaΦe bylo zp°φstupn∞nφ adresß°ov²ch strom∙ file serveru klient∙m (osobnφm poΦφtaΦ∙m, pozd∞ji oznaΦovan²m i jako pracovnφ stanice) takov²m zp∙sobem, ₧e pro n∞ se ätvß°ily" jako skuteΦn∞ mφstnφ za°φzenφ (nap°. jako mφstnφ pevnΘ disky). V praxi se hovo°φ o tzv. mapovßnφ adresß°ov²ch struktur file serveru na logickß za°φzenφ (logickΘ jednotky) klient∙, viz obrßzek Φ. 2.

Vznikß nov² v²poΦetnφ model?

Provozovßnφ aplikace v re₧imu file server/pracovnφ stanice

V n∞kter²ch situacφch ovÜem m∙₧e b²t v²hodnΘ, aby si aplikace existenci sφt∞ uv∞domovala. Nap°φklad tehdy, kdy₧ m∙₧e b²t spuÜt∞no vφce instancφ tΘ₧e aplikace (p°esn∞ji spuÜt∞no vφce instancφ programu, umφst∞nΘho jako soubor na file serveru). Pak je nap°φklad vhodnΘ, aby si ka₧dß z nich vytvß°ela svΘ pracovnφ soubory (pot°ebuje-li n∞jakΘ) jinde ne₧ ostatnφ instance, aby nedochßzelo k jejich vzßjemnΘmu ovliv≥ovßnφ. DalÜφ motivacφ je pak snaha umo₧nit vφce u₧ivatel∙m prßci nad spoleΦn²mi daty, kterΘ se nynφ ji₧ mohou nachßzet na jedinΘm spoleΦnΘm mφst∞, jako centrßln∞ umφst∞nΘ soubory na file serveru. Pokud by se toti₧ r∙znΘ aplikace (Φi alespo≥ r∙znΘ exemplß°e jednΘ a tΘ₧e aplikace) sna₧ily o souΦasn² p°φstup k jednomu a tΘmu₧ souboru, nastaly by problΘmy. Ty se samoz°ejm∞ dajφ °eÜit, nap°φklad r∙zn²mi zp∙soby zamykßnφ cel²ch soubor∙ Φi jejφch Φßstφ bu∩ na jak²koli p°φstup, nebo jen na zßpis apod. NicmΘn∞ aplikace, kterß mß tyto mechanismy pou₧φvat, si existenci sφ¥ovΘho prost°edφ obecn∞ i t∞chto mechanism∙ konkrΘtn∞ musφ uv∞domovat. Tak₧e sprßvnß odpov∞∩ na p∙vodnφ otßzku je spφÜe kladnß: p°eci jen vznikß nov² v²poΦetnφ model. Nemß vÜak dodnes p°φliÜ ustßlenΘ jmΘno, °φkejme mu tedy ämodel file server / pracovnφ stanice".