Od wielu lat pracujesz, bawisz się i ogólnie zajmujesz się komputerami. Obecnie używasz dwóch lub trzech komputerów typu PC, na których działa Windows 2000, Windows 98, Windows ME i kilka dystrybucji Linuksa. Połączyłeś je nawet w sieć w swoim domu. Twój garaż szybko zapełnia się pozostałościami po ostatnich modyfikacjach sprzętu. Czy to brzmi znajomo?
Być może używasz komputerów PC w biurze i masz tam mieszankę nowych i niezbyt nowych maszyn, wśród których można znaleźć także zniszczone komputery, których nikt nie chce wyrzucić. Być może mają one jeszcze jakąś wartość zapisaną na papierze w dziale księgowości, albo ich naprawa nie jest uzasadniona ekonomicznie z powodu uszkodzonych dysków.
Jeżeli masz sieciowy dostęp do komputera, na którym działa Linux, to możesz ożywić niektóre z tych starszych maszyn. W rzeczywistości można tego dokonać, dysponując prawie dowolnym serwerem udostępniającym protokoły BOOTP i TFTP, ale tutaj zajmiemy się tylko Linuksem.
W tym rozdziale mamy zamiar skrótowo pokazać bezdyskowe systemy linuksowe. Pomysł jest bardzo prosty: weź pierwszy lepszy komputer typu PC wyposażony w pamięć, tanią kartę grafiki oraz kartę sieciową (i nic więcej!) i zmień go w stację roboczą, maszynę obliczeniową, albo w system do buszowania po Internecie ustawiony na korytarzu.
Być może trudno będzie uzasadnić nakład pracy i czasu, ale jest to rozdział-przerywnik i należy się nam trochę rozrywki!
W latach 80-tych pamięć i twarde dyski były bardzo drogie, dlatego wynaleziono kilka sposobów na zbudowanie biurkowych stacji roboczych. Coraz więcej aplikacji uzyskiwało interfejs graficzny i wymagało zastosowania kolorowych monitorów, zamiast starszych terminali znakowych.
Na uniwersytetach i w większych firmach użytkowane wspólnie komputery, obsługujące całe działy mogły obsługiwać system X Window i tu narodził się pomysł X-terminala. X-terminal nie ma własnych lokalnych urządzeń do przechowywania danych i ma bardzo mało pamięci. Jego wyłącznym zadaniem jest obsługa aplikacji działających na serwerze. Zazwyczaj działa na nich bardzo prosty własny system operacyjny, który wystarcza do obsługi serwera X.
Gdy osobiste stacje robocze uzyskały popularność i nastąpił wzrost ich wydajności obliczeniowej, następnym logicznym krokiem było uruchamianie aplikacji na samych stacjach roboczych. Niestety, urządzenia do przechowywania danych nadal były drogie. Jednym ze sposobów obejścia tego problemu stało się korzystanie z serwera do przechowywania wymaganych przez stację roboczą danych, które mogły zawierać system operacyjny tej stacji.
X-terminale i bezdyskowe stacje robocze znalazły uznanie w wielu firmach. Był to bardzo wygodny sposób uzyskania wydajnego komputera na biurku. Główny serwer kontrolował całe oprogramowanie, a więc stosunkowo łatwo można było nim zarządzać (szczególnie wtedy, gdy porówna się to ze współczesnymi komputerami osobistymi) — wszelkie modyfikacje dokonywane były tylko w jednym miejscu, czyli na serwerze. Jeżeli uszkodziła się stacja robocza lub X-terminal, to można było je natychmiast wymienić na inne — wymagało to tylko zmiany jednego wiersza (lub wcale!) na serwerze i użytkownik mógł kontynuować pracę.
Do sukcesu takiego sposobu pracy przyczyniła się w znacznym stopniu sieć, ale stanowiło to prawdopodobnie także jedną z przyczyn upadku idei stacji roboczych. W miarę wzrostu ich wydajności okazywało się, że wydajność sieci jest za mała. Żądania odczytu dużych aplikacji i plików danych z serwera stały się zbyt trudnym zadaniem. Niektóre stacje robocze zaczęto wyposażać w twarde dyski i instalować lokalnie aplikacje, a więc stacja robocza przekształciła się w komputer osobisty. Systemy bezdyskowe odeszły w zapomnienie, a wiele zalet zarządzania takimi scentralizowanymi systemami po prostu zniknęło.
W latach 90-tych idea systemów bezdyskowych nieco odżyła, ponieważ sieci stały się towarem konsumpcyjnym. Można je łatwo zbudować i uzyskać większą przepustowość. Jako przykłady użycia systemów bezdyskowych (lub prawie bezdyskowych) należy wymienić:
q komputer sieciowy,
q przystawki obsługujące kino domowe,
q kioski internetowe.
W naszej aplikacji obsługującej wypożyczalnię płyt DVD można zastosować system bezdyskowy umożliwiający dostęp wielu użytkowników lub działający w publicznym kiosku.
Wszystkie urządzenia tego rodzaju działają na zasadzie pobrania systemu operacyjnego (lub tylko podstawowych procedur tego systemu) poprzez sieć, a więc nie wymagają stosowania lokalnych urządzeń do przechowywania danych. Ich oprogramowanie jest aktualizowane natychmiast po zmianie plików w sieci, a więc nie zwiększają one nakładów pracy potrzebnych na utrzymanie. Jest to więc rozwiązanie idealne dla masowego klienta.
Jeden z autorów książki wniósł do koncepcji systemu bezdyskowego pewną nowość, zauważywszy, że maszyna bezdyskowa pracuje o wiele ciszej niż zwykły komputer osobisty, ponieważ nie ma twardego dysku. Prawie pusta obudowa pozwala także na utrzymanie niższej temperatury. Postanowił się więc zbudować działający bezgłośnie PC. Usunąwszy wentylator z zasilacza i zastąpiwszy wiatraczek na procesorze dużym radiatorem, uzyskał bezgłośną maszynę. Jak stwierdziliśmy, jest to idealne rozwiązanie dla surfowania po Internecie.
Uważajcie jednak na zabawy z zasilaczem, jeżeli nie macie pewnej dozy doświadczenia w tego typu pracach. Wentylator nie jest tam wstawiony całkowicie bez powodu.
Linux obsługiwał bezdyskowe maszyny prawie od początku swojego powstania. Kluczowe właściwości jądra umożliwiają załadowanie systemu z sieci i pobieranie wszystkich potrzebnych plików z serwera. Wykorzystując system Linux, można więc zbudować X-terminal lub bezdyskową stację roboczą.
W tym rozdziale mamy zamiar pokazać krok po kroku, w jaki sposób można to zrobić, mając na uwadze następujące zagadnienia:
q Czym jest system bezdyskowy?
q Dlaczego chcemy go zbudować?
q Jak ma działać system bezdyskowy?
q Jakiego rodzaju aplikacje mają być na nim uruchamiane?
Prawdziwie bezdyskowy system nie ma żadnego lokalnego urządzenia do przechowywania danych, czyli nie można w nim znaleźć:
q twardego dysku,
q napędu CD-ROM,
q stacji dyskietek,
q monitora (prawdopodobnie).
Każdy plik potrzebny do działania takiego systemu jest pobierany z serwera poprzez sieć. Zazwyczaj spotyka się sieć typu Ethernet o przepływności albo 10 Mbit/s, albo 100 Mbit/s. Można też spotkać łącza ATM i xDSL (najczęściej w przystawkach obsługujących systemy „wideo na żądanie”). Jeżeli w takiej sieci można przekazywać pliki, to oznacza, że można także korzystać z systemów bezdyskowych. Skoncentrujemy się tutaj na zastosowaniu sieci typu Ethernet z protokołem TCP/IP, ale większość omawianych zagadnień można odnieść także do sieci innego rodzaju.
Systemy bezdyskowe mają wiele zalet:
q Koszt systemu może być bardzo mały, ponieważ nie ma on twardego dysku ani napędu CD-ROM.
Można zbudować bezdyskowy komputer osobisty, wydając nań znacznie mniej ciężko zarobionych pieniędzy, niż wydałoby się na zwyczajny PC. Jeśli system bezdyskowy ma pracować jako X-terminal, to nie trzeba w nim nawet stosować nowinek w postaci najwydajniejszych procesorów. Można zbudować doskonały system bezdyskowy na maszynie z procesorem 486, czyli na takiej, która dzisiaj uważana jest za przestarzałą (szczególnie dla Microsoft Windows). Pentium-100, 32 MB RAM jest wyzwaniem dla Windows NT4 (nie mylić z Windows 2000!), natomiast Linux na takim systemie bezdyskowym radzi sobie całkiem nieźle.
q System pozbawiony lokalnych urządzeń do przechowywania danych może być bardzo bezpieczny.
Są to idealne maszyny dla studentów eksperymentujących z Linuksem. Brak tu lokalnego systemu plików, który mógłby być zniszczony podczas eksperymentów, zaś pliki na serwerze można łatwo kontrolować lub wymieniać.
q Administrowanie grupą maszyn bezdyskowych jest prostsze, ponieważ wszystko dzieje się na serwerze.
Jak już wspomniano wcześniej, nowe maszyny bezdyskowe można dodawać bardzo prosto. Jednocześnie może być utworzona kopia konfiguracji każdej z nich, a więc odtwarzanie systemu po awarii nie sprawia kłopotów. Taki rodzaj centralnego zarządzania jest szczególnie przydatny w systemach rozproszonych na terenie większej organizacji, np. uczelni lub kilku biur jednej firmy.
Oczywiście, są też wady systemów bezdyskowych:
q Systemy bezdyskowe wymagają użycia serwera dostarczającego pliki i inne zasoby.
Niezależnie od tego, że stosunkowo nowoczesny i dobrze wyposażony komputer osobisty może działać jako serwer obsługujący całkiem sporą liczbę stacji bezdyskowych, to czynnikiem ograniczającym takie zastosowanie jest sama sieć. Ponieważ wszystkie pliki są przekazywane przez sieć na żądanie, jej obciążenie może bardzo wzrosnąć i stać się poważnym ograniczeniem.
q Szybkość transmisji w sieci lokalnej, wynosząca 10 Mbit/s nie może się równać z szybkością zapisu danych na dysk.
Możemy tylko stwierdzić, że jeśli aplikacje działające w systemie bezdyskowym są właściwie dobrane, to całość może działać poprawnie (użyteczne aplikacje omówimy później). Podział sieci na segmenty i zastosowanie przełączników także może zmniejszyć wpływ innych użytkowników sieci na działanie systemów bezdyskowych.
q W systemach wykorzystujących tylko serwer istnieje możliwość groźnej awarii spowodowanej uszkodzeniem jednego węzła.
Jest to kluczowe zagadnienie, które odegrało zasadniczą rolę w rozwoju osobistych komputerów biurkowych i rozproszonego przetwarzania danych. Nie trzeba jednak zanadto się martwić, bowiem nie jest to sytuacja gorsza niż zależność od centralnego serwera plików lub poczty. Tutaj kluczową sprawą także jest odpowiednie zarządzanie serwerem.
System bezdyskowy, chcąc po rozruchu i uruchomieniu użyć swoich plików, korzysta po prostu z sieciowego systemu plików. Będziemy tu używali NFS (skrót od Network File System). W rzeczywistości serwer udostępnia kilka systemów plików. Każda maszyna bezdyskowa ma pełny dostęp do przydzielonego jej obszaru na serwerze plików. Jest to tzw. nadrzędny system plików oznaczany symbolem „/”. Oprócz tego maszyny bezdyskowe korzystają ze wspólnej partycji /usr. Aby zapobiec konfliktom przy zapisie w systemie plików /usr, montujemy tę partycję z atrybutem „tylko do odczytu”.
W rzeczywistości jest całkowicie możliwe uruchamianie wielu maszyn bezdyskowych z jednego nadrzędnego systemu plików, mającego status „tylko do odczytu”. Dzięki temu uzyskujemy dodatkowe zabezpieczenie, ponieważ dosyć trudno włamać się do takiego systemu.
Często nie zwraca się na to uwagi, ale w standardowym wydaniu Uniksa pliki w katalogu /usr mają zazwyczaj atrybut „tylko do odczytu” — dzięki temu mogą być współużytkowane w postaci pojedynczych kopii. Pliki, które były przechowywane w katalogu /usr i musiały mieć zezwolenie zapisu (np. logi przechowywane w /usr/adm), zostały przeniesione do katalogu /var, który jest udostępniony do zapisu. Szczegółowe informacje na temat hierarchii plików w systemie Linux i atrybutów plików w katalogu /usr można znaleźć po adresem http://www.pathname.com/fhs/.
Na powyższym schemacie mamy dwie bezdyskowe stacje robocze (o nazwach dl-1 i dl-2), które korzystają z oddzielnych obszarów na dysku serwera, przeznaczonych na partycje główne. Stacje robocze wspólnie wykorzystują /usr. W wyniku takiej konfiguracji działają one tak, jakby było wykonane następujące polecenia montowania systemu NFS:
Dla stacji dl-1:
mount -t nfs server:/root-1 /
mount -t nfs -o ro server:/dl-usr /usr
Dla stacji dl-2:
mount -t nfs server:/root-2 /
W rzeczywistości w wielu dystrybucjach Linuksa zarzucono wykorzystanie subtelności zezwoleń na zapis w katalogu /usr i na trwałe pozostawiono w nim pliki zapisywalne. Ten problem omówimy w dalszej części rozdziału.
Jak można osiągnąć ten szczęśliwy stan korzystania z plików na serwerze, jeśli nie mamy jeszcze zainstalowanego systemu operacyjnego?
Uruchamianie maszyny bezdyskowej odbywa się w trzech etapach:
q Rozruch wstępny (ang. Initial Boot) — uzyskanie adresu IP,
q Rozruch wtórny (ang. Secondary Boot) — załadowanie kopii systemu operacyjnego i uruchomienie jej,
q Rozruch z udostępnianiem (ang. Multi-user Boot) — normalne uruchomienie systemu Linux.
Podczas etapu wstępnego system bezdyskowy kontaktuje się ze swoim środowiskiem sieciowym. Odbywa się to zwykle za pomocą uruchomienia małego programu (o rozmiarze mniejszym niż 32 kB) rezydującego w maszynie bezdyskowej. Program ten jest na tyle mały, że można go wpisać do pamięci EPROM umieszczonej na karcie sieciowej systemu bezdyskowego.
Podczas prób z konfiguracją bezdyskową można uruchamiać ten program z dyskietki rozruchowej lub płyty CD-ROM. Oczywiście, nie będziemy wtedy mieć maszyny całkowicie pozbawionej dysków, ale dla prób możemy tak postąpić. Jeżeli zupełnie nie można skonfigurować rozruchu z karty sieciowej, to taka konfiguracja może być najlepszym rozwiązaniem. W przeciwnym wypadku, jeżeli wszystko działa poprawnie, można przejść do rozruchu z karty sieciowej.
Komputery osobiste przeważnie próbują dokonać rozruchu systemu operacyjnego zapisanego na dyskietce, na twardym dysku lub na dysku CD-ROM. Kolejność tych prób jest ustawiana w BIOS i często spotyka się takie ustawienie: „CD-ROM, A:, C:”. Oznacza to, że najpierw następuje próba rozruchu z CD-ROM (jeśli płyta jest umieszczona w napędzie), potem z dyskietki (jeśli jest umieszczona w stacji), a na końcu z twardego dysku. Aby rozruch systemu bezdyskowego mógł się odbyć poprawnie, jego BIOS musi znać sposób dostępu do karty sieciowej.
Jeżeli karta sieciowa ma podstawkę dla pamięci EPROM, to na ogół jest możliwa taka jej konfiguracja, aby ta pamięć stała się rozszerzeniem BIOS dodającym możliwość rozruchu z sieci. Oznacza to często, że system najpierw próbuje dokonać rozruchu z sieci, a więc program konfigurujący kartę sieciową należy zawsze mieć pod ręką.
Istnieje wiele kart sieciowych, które można zastosować przy rozruchu systemu bezdyskowego za pomocą opisanych dalej metod. Oto niektóre z nich:
q 3Com: 3c503, 3c507, 3c509, 3c590, 3c595, 3c905,
q Novell: NE1000, NE2000, NE2100 i ich odpowiedniki,
q Digital: DE100, DE200,
q Intel: EtherExpress Pro, EtherExpress 100,
q SMC: 83c170 EPIC, 83c170/100.
Oczywiście, można także użyć kart, w których zastosowano te same układy scalone jak w kartach wymienionych wyżej. Szczegółowe informacje na ten temat są podane w pakiecie etherboot, z którym zapoznamy się nieco później.
Każdy komputer pracujący w sieci TCP/IP ma przydzielony adres IP używany przy wymianie informacji z innymi komputerami. Adres ten bywa często nadawany podczas pierwszej instalacji systemu operacyjnego. Można go także przydzielić automatycznie podczas rozruchu systemu operacyjnego, korzystając z protokołu DHCP (Dynamic Host Configuration Protocol).
Podczas rozruchu system bezdyskowy nie dysponuje żadną informacją na temat swojego adresu ani nawet na temat systemu operacyjnego, który ma być uruchomiony. Informacja ta musi być pobrana z serwera poprzez sieć, ale początkowo nie wiadomo nawet, jaka jest lokalizacja tego serwera! Rozruch wstępny jest więc po prostu płaczliwym wołaniem o pomoc.
Wszystkie karty sieciowe mają unikatowe adresy nadane im przez producentów. Adresy te są oznaczane skrótem MAC (od Media Access Control). System bezdyskowy rozpoczyna więc pracę od rozgłoszenia swojego adresu MAC w całej sieci, co stanowi część żądań o podanie informacji o nim samym.
Serwer może określić adres IP, który odpowiada adresowi MAC, używając jednego z protokołów: RARP (Reverse Address Resolution Protocol), BOOTP (Boot Protocol) lub DHCP. My posłużymy się protokołem BOOTP.
Serwer, na którym działa usługa BOOTP, odbiera żądanie adresu IP (jeżeli został skonfigurowany tak, aby reagować na takie żądania) i wysyła odpowiedni adres, który system klienta może wykorzystać. Ponieważ żądanie BOOTP jest rozgłaszane (ang. broadcast), czyli jest adresowane do wszystkich komputerów w sieci, klient nie musi znać adresu serwera.
Należy zachować pewne środki ostrożności podczas konfigurowania sieci, w której znajduje się więcej niż jeden serwer BOOTP, ale taka konfiguracja jest na pewno możliwa.
Po tym, jak system bezdyskowy uzyskał swój adres IP, nadal nie wiadomo, co trzeba dalej robić, bowiem BOOTP jest przeznaczony tylko do przydzielania adresów. Wówczas maszyna bezdyskowa wysyła następne żądanie — tym razem żąda przesłania systemu operacyjnego. Do sieci, łącznie z podaniem adresu IP, wysyłane jest pytanie, czy jakiś serwer ma kopię systemu operacyjnego gotową do uruchomienia. Serwer BOOTP odpowiada wówczas na to żądanie, podając lokalizację serwera, z którego można pobrać system operacyjny.
Podczas rozruchu systemu operacyjnego w naszych linuksowych stacjach bezdyskowych będziemy używać RAM-dysku. Przygotujemy w tym celu coś, co efektywnie będzie kopią wyimaginowanej dyskietki przesyłaną do bezdyskowego klienta i tam uruchamianą. System bezdyskowy załaduje tę kopię do pamięci i uruchomi ją, dokonując rozruchu w taki sam sposób, jakby robił to ze zwykłej dyskietki. Aby można było tak pracować, jako kopię (obraz) systemu operacyjnego należy przygotować specjalne jądro Linuksa. Po uruchomieniu nasz komputer bezdyskowy uzyska dostęp do pełnego systemu Linux za pośrednictwem serwera.
W tym momencie można podjąć decyzję, czy uruchamiać Linux, czy może inny system operacyjny. Może to być dowolny system, który da się uruchomić w niewielkiej przestrzeni (idealna jest dyskietka, ale RAM-dysk może mieć większą pojemność). Jako przykład można podać MS-DOS 6.22, który może pracować bez dysków, a jako lokalne urządzenie do przechowywania danych używać tylko RAM-dysku. Jeżeli doda się do niego klienta sieci Microsoft dla DOS, to można uzyskać dostęp do serwerów z oprogramowaniem firmy Microsoft, powiększając dzięki temu zasoby. Można także zainstalować Microsoft Windows 3.11 na serwerze podłączonym w taki właśnie sposób i uruchomić Windows całkowicie bez dysków. W Windows 95 taka sztuczka jest nieco trudniejsza, ale się udaje, natomiast w praktyce nie udaje się tego zrobić z Windows 98. W systemie Linux wszystko odbywa się bardzo łatwo.
Obraz RAM-dysku jest przesyłany z serwera do bezdyskowego klienta za pomocą innego protokołu, a mianowicie bardzo prostego protokołu do przekazu plików TFTP (Trivial File Transfer Protocol).
Zbliżyliśmy się więc do zakończenia operacji rozruchowych na maszynie bezdyskowej. Gdy jądro Linuksa zacznie działać, może ono korzystać z dostępu do serwera. Aby utworzyć takie jądro, które będzie sobie radzić bez lokalnych urządzeń do przechowywania danych, trzeba wykonać kilka specjalnych czynności. Jądro musi być skonfigurowane tak, aby pobierało adres IP za pomocą protokołu BOOTP (tak jak w pierwszym etapie rozruchu) oraz umożliwiało zamontowanie głównego systemu plików na serwerze za pomocą NFS.
Po zamontowaniu głównego systemu plików Linux zaczyna działać normalnie, uruchamiając skrypty i usługi zdefiniowane w plikach rozruchowych umieszczonych w głównym systemie plików. W pewnym momencie podczas operacji rozruchowych następuje zamontowanie katalogu /usr w trybie „tylko do odczytu”, jak na poprzednim schemacie. I to już wszystko!
Jako podsumowanie pokazujemy wyobrażenie konwersacji, która odbywa się w sieci:
Zdarzenie
Klient
Protokół
Serwer
Włączenie zasilania
„Ja istnieję!”
PabloPCK