Szyfrowanie danych przesylanych przez siec przedsiebiorstwa zwieksza bezpiecze nstwo uwierzytelniania i zapobiega przechwytywaniu przesylanych danych przez osoby
niepowolane. Dane moga byc szyfrowane za pomoca dowolnego z kilku dostepnych
standardów, stosujacych rózne algorytmy szyfrowania wiadomosci tak, by jedynie pr awowity odbiorca wiedzial, jak je rozszyfrowac. Wiekszosc metod szyfrowania polega
na wykorzystaniu wartosci wspólnego klucza do szyfrowania danych, a nastepnie deszyfracji po stronie odbiorcy. Ten typ szyfrowania jest ogólnie znany pod nazwa infrastruktury klucza publicznego (PKI — Public Key Infrastructure IP).
W skrócie: PKI wykonuje dwie funkcje, zapewne juz znane Czytelnikowi. Mozemy
umiescic w wiadomosci podpis cyfrowy lub zapieczetowac (zaszyfrowac) wiadomosc.
Dla kazdej z tych funkcji proces przebiega nieco odmiennie i dla kazdego uzywana jest
inna para kluczy. Para kluczy uzywana jest razem —jeden sluzy do szyfrowania d anych, zas drugi do deszyfracji. Pary kluczy sa tworzone w taki sposób, by tylko drugi
z nich mógl posluzyc do odszyfrowania danych, zaszyfrowanych pierwszym kluczem.
Sa to tzw. klucze asymetryczne, poniewaz kazdy jest inny.
Podpisywanie wiadomosci
Proces podpisania wiadomosci nie oznacza zaszyfrowania jej, lecz umieszczenie elektronicznego podpisu na koncu wiadomosci. Podpis zostaje zweryfikowany po drugiej
stronie, w celu sprawdzenia, czy wiadomosc nie zostala zmodyfikowana w trakcie
transmisji z miejsca na miejsce.
Do podpisania wiadomosci tworzony jest jej skrót (digest) za pomoca funkcji mieszajacej. Prostym przykladem mieszania moze byc wziecie pierwszych 1024 bitów wiadomosci i wykonanie funkcji XOR (patrz uwaga ponizej) z k olejnymi 1024 bitami. Na
wyniku znowu zostanie wykonana operacja XOR z nastepnymi 1024 bitami i tak dalej,
az do konca wiadomosci. Na koniec otrzymamy lancuch 102 4 bitów, unikatowy dla tej
wiadomosci —a przynajmniej na tyle unikatowy, ze wartosc zmieni sie, j esli ktos choc
troche zmodyfikuje wiadomosc.
Nazwa funkcji XOR pochodzi od Exclusive OR. Jest to logiczne porównanie dajace 0, jesli
dwa bity sa takie same oraz 1, jesli sie róznia.
Wprawdzie proces mieszania niekoniecznie bedzie uzywac funkcji XOR, lecz procedura jest podobna. Liczba bitów wyniku zalezy od uzytego konkretnego algorytmu, lecz
ogólnie wynosi przynajmniej 512. Ten skrót wiadomosci zostaje nas tepnie zaszyfrow any kluczem prywatnym autora i wiadomosc zostaje wyslana.
Po odebraniu wiadomosci skrót zostaje z niej usuniety i za pomocatego samego alg orytmu, co u nadawcy, liczony jest u odbiorcy skrót wiadomosci. Nastepnie oryginalny
odebrany skrót w iadomosci zostaje odszyfrowany za pomoca publicznego klucza nadawcy, sluzacego do podpisywania, a oba skróty zostaja porównane. Jesli sa takie same,
dane podczas transportu nie zostaly zmodyfikowane. Jesli sie róznia, ktos mógl man i pulowac wiadomoscia. Oc zywiscie oznacza to, ze klucz publicznysluzacy do podpisyw ania musi byc znany systemowi odbiorcy; w przeciwnym r a zie nie mozna by bylo sprawdzic wiadomosci i jej podpisywanie nie mialoby zbyt duzego sensu.
Wlasne konta dostepu telefonicznego
Jesli naprawde musimy stosowac wlasne konta dostepu telefonicznego z uwagi na bezpieczenstwo, przygotujmy sie na koszty. Uruchomienie wlasnej puli modemów wymaga
wyspecjalizowanego sprzetu i linii telefonicznych. Na dodatek musimy zastanowic sie,
jak obsluzyc uzytkowników podrózujacych. Albo zmusimy ich do wybierania numeru
centralnego, albo rozmiescimy modemy w kazdym oddziale, z którym uzytkownik bedzie sie laczyc. Jesli uz ytkownicy lacza sie z numerem centralnym, mozemy rozwazyc
opcje numeru bezplatnego (0- 800), aby obnizyc koszty polaczen. Jesli ta opcja jest ni eosiagalna, mozemy pomyslec nad polaczeniami callback . Do tego m oga posluzyc pol aczenia typu wychodzacego, aby utrzymac niskie koszty. Jedyna sytuacja, która spow oduje klopoty w tej strategii to ta, gdy uzytkownicy dzwonia z hotelu —numer telefonu
w pokoju moze nie byc dostepny z zewnatrz.
Umieszczenie modemu w kazdym biurze moze zminimalizowac kosz ty, lecz nadal bedziemy mieli do czynienia z rachunkami za polaczenia zamiejscowe, gdy podrózujacy
uzytkownicy beda daleko od biura. Potrzebny bedzie jeszcze jakis sposób kontroli
uwierzytelniania, poniewaz uzytkownik moze byc w Houston, a jego konto w Albany.
W takim przypadku informacje o koncie uzytkownika musza byc dostepne dla serwera
w Houston. Kolejny problem pojawia sie, gdy uzytkownik nie moze polaczyc sie, nie
znajac numeru dostepowego w Houston. Takie informacje musza byc przechowywane
w laptopie; w przeciwnym razie uzytkownicy beda zmuszeni dzwonic do obslugi technicznej w drugim miescie, aby otrzymac numer.
Protokól PPTP
Wprawdzie PPTP(point-to-point tunneling protocol —protokól tunelowania dwupun ktowego) jest przeznaczony przede wszystkim dla uzytkowników korzystajacych
z polaczen telefonicznych, lecz moze tez posluzyc do pola czenia dwóchbiur poprzez siec
TCP/IP, jak np. Internet. Poniewaz protokól PPTP zostal opracowany przez Microsoft,
sam tunel nie jest uwierzytelniany; zamiast tego dane logowania przesylane tunelem sa
szyfrowane. Uwierzytelnianie zda l nego uzytkownika zachodzi w tradycyjny sposób.
Dla uzytkowników polaczen telefonicznych PPTP jest protokolem latwym do skonfig urowania i stosunkowo prostym. System kliencki inicjuje polaczenie z serwerem przez
istniejace juz polaczenie TCP/IP, szyfrowane tylko pomiedzy tymi dwo ma punktami.
Oznacza to, ze jesli protokól sluzy do polaczenia dwóch biur, to jedynie komunikacja
dwupunktowa —to znaczy, na koncach tunelu pomiedzy dwoma systemami Windows
grajacymi role ruterów —bedzie zaszyfrowana.
Na przyklad dane w sieciach A i B nie sa szyfrowane, a jedynie dane
przesylane tunelem pomiedzy dwoma ruterami. Jesli klient w sieci A wysyla dane do
klienta w sieci B, dane nie sa szyfrowane, poniewaz musialyby najpierw przejsc do stosu protokolu PPTP, a nastepnie zostac za pakowane w pakiet TCP/IP. Poniewaz dane
klientów w sieci A przechodza do stosu IP, nie beda w pierwszej kolejnosci przeslane
przez stos PPTP, a wiec nie zostana zaszyfrowane.
Dane z aplikacji przechodza w dól stosu protokolu PPTP, a nastepnie
przez stos TCP/IP. Pierwszy stos zapewnia szyfrowanie, zas drugi faktyczny transport.
Poniewaz pakiety z sieci nie beda podazac ta sama trasa, PPTP tak naprawde nie nadaje
sie do laczenia sieci.
Polaczenie przez lokalnego ISP
Laczenie sie z lokalnym dostawca uslug jest prosta metoda uzyskania dostepu do Internetu; j ednakze lokalny ISP zazwyczaj nie posiada polaczen dwupunktowych lub laczy
dzierzawionych. Lokalny ISP jest z kolei polaczony z wiekszym operatorem, który zapewnia dostep ISP do Internetu —ISPw zasadzie odsprzedaje pasmo l acza, wobec
czego mo zemy oczekiwac od niego d odatkowych uslug.
Przy podejmowaniu decyzji o wyborze lokalnego ISP, musimy rozwazyc wiele czynników. Przede wszystkim zapytajmy siebie samych, czy okreslony ISP utrzyma sie na
rynku przez nastepne szesc miesiecy. Wielu malych dostawców uslug internetowych
pojawilo sie i zniklo w przeciagu kilku ostatnich lat. W niektórych przypadkach znikli
szybko, zostawiajac klientów na lodzie. Prosze nie zapominac, ze dostajemy to, za co
placimy. Jesli umowa jest zbyt piekna, by mogla byc prawdz iwa, zazwyczaj nie jest. J esli polaczenie ma jedynie sluzyc uzytkownikom do surfowania w Internecie, jest to
niewazne. Jesli jednak polaczenie to ma byc laczem do swiata zewnetrznego dla poczty
elektronicznej i sluzyc do laczenia biur za pomoca tunelowania , to lepiej nie skapic na
usludze.
Warto jeszcze upewnic sie, czy ISP stosuje rozsadne proporcje w wielkosciach sprzedanego pasma do rzeczywistego —podobnie jak towarzystwa lotnicze, dostawcy uslug
i nternetowych sprzedaja wiecej uslug niz posiadaja. Zazwyczaj uchodzi to na sucho,
poniewaz nie wszyscy uzytkownicy sa równoczesnie online. Jesli jednak ISP sprzedal
o wiele za duzo uslug, dostepne pasmo moze na tym ucierpiec. Ponadto mozemy przy jrzec sie ogloszeniom ISP o zatr udnieniu, aby zorientowac sie, jak duzo placi swoim
pracownikom, a wiec na jakim poziomie jest jego personel. Zwlaszcza lo kalni dostawcy
uslug internetowych moga znacznie sie róznic pod wzgledem doswia dczenia i profesj onalizmu obslugi.
Na koniec zidentyfikujmy rodzaj polaczenia ISP z jego dostawca. Jesli korzysta z lacza
T1, moze nie byc w stanie obsluzyc zbyt wielu uzytkowników; jesli jednak posiada kilka laczy T3 lub OC12 do wiecej niz jednego dostawcy, to mozemy byc spokojni, ze ISP
bedzie w stanie swiadczyc nam uslugi dobrej jakosci.
Przelaczanie komórek
Przelaczanie komórek w sieciach IP stanowi bardziej radykalne podejscie do problemu przenoszenia
danych próbujace utworzyc jedna techn ologie, mogaca przesylac glos, dane, obraz i tak
dalej. Poniewaz firmy telefoniczne uzywaja swoich laczy fizycznych do przesylania z arówno glosu, jak i danych, zdolnosc do efektywnego wspóluzytkowania posiadanych
laczy stanowi dla nich olbrzymi pr oblem.
W komutacji pakietów lub ramek przesylane dane mialy zmienna dlugosc. Jednakze
wiekszosc systemów komutacji pakietów i ramek jest obecnie skonfigurowana do przesylania pakietów lub ramek, których rozmiar opiera sie na standardzie Ethernet, stanowiacym aktualnie dominujaca topologie sieciowa. Jedna z podstawowych zmian w komutacji komórek jest przesylanie malych pakietów o stalej dlugosci — komórek .
Rozmiary ramek moga byc duze (do 4096 oktetów), natomiast komórki zawsze posi adaja 53 oktety (4 8 oktetów danych i 5 oktetów informacji towarzysz acych).
Stale rozmiary komórki oznaczaja, ze przelaczniki nie musza juz ustalac rozmiarów pakietów, zanim zaczna dokonywac innych operacji na danych. Nie jest stosowana fra gmentacja i ponowne skladanie, bufory moga pomiescic duza liczbe komórek, zas logike
potrzebna do obslugi malych komórek mozna zaimplementowac sprzetowo na poziomie
ukladów scalonych.
Umieszczenie logiki w ukladzie scalonym zwieksza niestety koszt kart. Jest to jeden
z glównych powodów, poza rozwojem gigabitowego Ethernetu, dla których impleme ntacje typu ATM(Asynchronous Transfer Mode) nie toruja sobie drogi na biurka. A poniewaz kazdym 48 oktetom danych towarzyszy 5 oktetów dodatkowych, stosowanie
komutacji komórek niesie za soba bardzo wysoki ruch sieciowy tla.
Podobnie jak w komutacji pakietów, w komutacji komórek tworzony jest wirtualny obwód w uzytkowanym wspólnie polaczeniu. Ponadto komutacja pakietów moze zapewnic gwarantowana jakosc uslug (Quality of Service), co jest bar dzo przydatne dla przenoszenia danych czasu rzeczywistego, na przyklad dzwieku i wideo, tymi samymi
wspóluzytkowanymi laczami, które sluza do przenoszenia danych.
W wielu przypadkach organizacja nie jest w stanie polozyc fizycznego okablowania,
uzywanego do szybkiej komunikacji na skale swiatowa. Wobec tego musimy podlaczyc
sie do sieci szkieletowej lub szkieletu publicznego (czyli Internetu), co oznacza, ze potrzebne jest polaczenie od naszej lokalizacji do wiekszych sieci. W przypadku Internetu
mozemy wyk orzystac do tego celu lokalnego ISP, zas jesli potrzebne jest lacze dzie rzawione —wiekszego dostawce lub lokalna firme tel efoniczna.
Komutacja pakietów
Przygladajac sie danym, które komputer generuje i wysyla przez siec, zauwazymy dwie
róznice w stosunku do transmisji glosu. Pierwsza róznica jest fakt, iz w transmisji d anych dopuszczalny jest pewien poziom opóznien, poniewaz odbiorca moze zaczekac na
dane —w transmisji glosu powodowaloby to rwanie lub niezrozumialosc rozmowy.
Druga róznica jest postac danych —transmisja glosu uzywa ciaglej fali sinusoidalnej,
natomiast dane komputerowe skladaja sie z bitów zgrupowanych w bajty (o dlugosci
pieciu, siedmiu lub osmiu bitów). Oznacza to, ze grupabajtów moze zostac dalej zapakowana w zaadresowany pakiet. W rzeczywistosci transmisje danych (równiez potoki
bajtów) sa czesto dzielone na osobne je dnostki.
W latach 60. inzynierowie zdecydowali, by traktowac dane jako ciag pakietów, a nie
potok informac ji. W ten sposób zlikwidowali koniecznosc stosowania ciaglych pol aczen, otwierajac droge dla transmisji danych. Obecnie, gdy dane sa wyslane, moga
dojsc do urzadzenia na granicy sieci, które podzieli je na porcje o odpowiednich ro zmiarach, zaadresuje i wysle w siec. Ten proces mozna przyrównac do dzialania referatu
pocztowego firmy.
TCP/IP jest przykladem sieci z komutacja pakietów. Przelacznik na logicznym skraju
kazdego segmentu sieci dane przeznaczone dla innych segmentów sieciowych dzieli na
pakiety (datagramy) o rozmiarach odpowiednich dla topologii nastepnej sieci oraz w ysyla je do kolejnego przelacznika. Ten sprawdza datagram i przesyla do kolejnego przelacznika, az pakiet dotrze do ostatecznego miejsca przeznaczenia. Jak mozemy sie domyslic, omawianymi przelacznikami sa tak naprawde rutery. W rzeczy wistosci rutery
zostaly jako pierwsze urzadzenia wykorzystane do utworzenia sieci szkieletowej ARPANet —pierwszego wcielenia Internetu.
Problem z komutacja pakietów polega na tym, ze wraz ze wzrostem ruchu w sieci ruter
musi pracowac coraz ciezej, aby nadazyc. W pewnym momencie ruter „zatka” sie i z acznie odsylac lub tracic datagramy. W koncu ulegna temu wszystkie rutery, powodujac
zatrzymanie sieci. Razem z nowymi danymi za czna pojawiac sie retransmisje, dalej pogarszajace problem.
Taka sytuacja moze prawie uniemozliwic przesylanie danych. Wieksza czesc problemu
powodowana jest przez nature komutacji pakietów. Nie istnieja stale trasy, opisujace
trase danych przez sieci. Pak iety moga podazac od A do B róznymi drogami, w miare
zmian warunków w sieci, co prowadzi do odbierania pakietów w niewlasciwej kolejn osci lub ich odrzucenia po uplywie limitu czasu. Do rozwiazania problemu sieci z k o mutacja pakietów potrzebne byly podstawo we polaczenia komutacji pakietów, lecz bez
koniecznosci tworzenia ciaglych polaczen. Tu w gre wchodzi technika komutacji
(przelaczania) ramek — frame relay.
Systemy wieloadresowe
Podczas planowania równowazenia obciazenia jednym z rozwiazan, które mozemy
wziac pod uwage, jest wieloadresowosc(multihoming), która wymaga uzycia wiecej niz
jednej karty sieciowej w serwerze, aby uzytkownicy mogli korzystac z systemu loka lnie, a nie przez ruter. Wieloadres owosc jest prostym rozwiazaniem równowazacym obciazenie —i zwiekszajacym w ydajnosc. Wprawdzie ilosc pamieci i szybkosc procesora
oraz dysków ma znaczenie, lecz nadal waskim gardlem jest karta sieciowa. Wszystkie
zadania klientów i wszystkie i nformacje dostarczane im przez serwer musza przejsc
przez ten jeden interfejs.
Problemem moze byc nie karta sieciowa , lecz wysokie obciaz enie danego segmentu.
W takim przypadku podlaczenie dwóch kart sieciowych w jednym systemie do tego
same go segmentu moze nie sprawic zbytniej róznicy, zwlaszcza w przypadku dostepn ego obecnie sprzetu sieciowego. Lecz spójr zmy na rysunek poniżej

Czytelnik moze pomyslec, ze na rysunku jest przedstawiony ruter. W rzeczywistosci
jest to system wieloadresowy. W rozdziale 19. mówilismy, ze ruter jest wieloadres owym systemem, posiadajacym przynajmniej jeden protokól IP. Nic nie przeszkodzi nam
w zamontowaniu kilku kart sieciowych w dowolnym systemie. Gdy dodamy wiecej kart
sieciowych do serwera, bedziemy mogli podlaczyc go bezposrednio do podsieci zawi erajacej uzytkowników.
W istocie nic nie przeszkadza w wykorzystaniu do roli rutera komputera dzialajacego
pod systemem Windows lub Unix. Wiele organizacji uzywa wewnetr znie komputerów
wieloadresowych jako ruterów, poniewaz rozwiazanie takie jest czesto tansze od kupowania wyspecjalizowanych ruterów sprzetowych. W najgorszym przypadku wieloadresowy komputer moze nam posluzyc j a ko ruter zapasowy.
Prawde mówiac, wieloadresowosc mozemy zastosowac w wiekszosci serwerów, w tym
w serwerach aplikacji; w ich przypadku technika ta pozwoli znaczaco zwiekszyc liczbe
klientów, która serwer bedzie w stanie równoczesnie obsluzyc. Na przyklad, rysunek poniżej przedstawia dwa serwery SQL replikujace pomiedzy soba dane przez siec
prywatna, jednoczesnie obslugujace klienty poprzez siec glówna. Takie rozwiazanie
przenosi ruch replikacji z glównej sieci szkieletowej do prywatnego szkieletu SQL.

Poniewaz serwery SQL moga aktualizowac wzajemnie swoje dane poprzez czeste r eplikacje, zmiany moga byc niemal natychmiastowe (jesli nie natychmiastowe), dzieki
takim narzedziom SQL, jak replikacje i potwierdzanie dwuetapowe. Wobec tego klienty
moga uzywac dowolnego z serwerów SQL, poniewaz sa blizniacze. Polowa klientów
moze byc skonfigurowana do korzystania z jednego serwera SQL, a reszta klientów —
z drugiego. W razie niedostepnosci jednego serwera, drugi moze przejac jego zadania
(poniewaz ma w pelni aktualne dane). Taka konfiguracja zapewnia równowazenie o bciazenia oraz pewna nadmiarowosc.
Odrebny szkielet, jak pomiedzy serwerami z rysunku 20.6, moze byc wydajnie wykorzystany z dowolna uslu ga, która replikuje swoje dane do innego serwera. Wada tego
rozwiazania jest wieksza liczba sieci, które trzeba nadzorowac, jednakze sieci zawier ajace tylko kilka systemów sa zwykle stabilniejsze od sieci z wieloma klientami.
Na rysunku 20.7 podstawowa struktura z rysunku 20.6 zostala rozbudowana o wiele
dodatkowych klientów i proporcjonalna liczbe dodatkowych serwerów. Poniewaz liczba
systemów w drugiej sieci szkieletowej jest ograniczona, ruch sieciowy, o który serwery
musza w niej rywalizowac jest mniejs zy, nawet przy radykalnym wzroscie liczby klie ntów. Kolejna korzyscia ze stosowania odrebnego szkieletu jest mozliwosc uzyw ania w
nim wlasnego protokolu serwerów. Na przyklad, gdyby serwery SQL z przykladu byly
produktami Microsoftu, wówczas ich prywatna s iec szkieletowa moglaby obslugi wac
NetBEUI —protokól szybszy w przypadku sieci jednosegmentowej.
Wieloadresowosc i wykorzystanie odrebnej sieci szkieletowej jest rozwiazaniem dobrze
skalowalnym w przypadku uslug typu serwer SQL, które moga dokonywac repli kacji
i rozkladac zapytania na serwery. Nie nadaje sie to jednak dla takich uslug, jak np. DNS
lub serwer proxy. W tych przypadkach zmiany dokonywane sa przez uzytkowników
w serwerze centralnym, a nastepnie rozprowadzane do innych serwerów. Nadal jednak
mo zna uzywac hierarchicznych serwerów do redukcji ogólnego ruchu w sieci.
Serwery hierarchiczne
W przypadku serwerów SQL, na rysunkach wcześniej, uzywana byla odrebna siec szkieletowa, aby polepszyc komunikacje pomiedzy serwer ami równorzednymi. Jednakze w przypadku uslugi DNS serwery nie sa równorzedne —istnieje jeden serwer pod-
stawowy DNS. Musimy wiec znalezc inne rozwiazanie, aby zredukowac ogólny ruch w sieci. Wezmy pod uwage rysunek 20.8, który przedstawia dwa serwery DNS dla calej sieci. Taka konfiguracja bardzo ulatwia transfery stref ; jednakze wszystkie zapytania klientów musza przejsc przez dwa rutery, aby dotrzec do serwera DNS. Nie tylko zwieksza to opóznienia w rozwiazywaniu nazw, lecz równiez objetosc ruchu sieciowego, który wychodzi z lokalnego segmentu.
Rysunek poniżej pokazuje, jak mozemy dodac kolejne serwery wtórne w sieci, aby zmnie jszyc obciazenie dwóch glównych serwerów i zredukowac liczbe segmentów sieci, przez które musi przejsc zapytanie. Mozemy dodac usluge DNS w pierwszym poziomie ruterów, które beda wtórnymi serwerami DNS wzgledem glównego. Zredukuje to do min imum pochodzacy od klientów ruch si eciowy, zwiazany z rozwiazywaniem nazw. Wada rozwiazania z rysunku 20.9 jest koniecznosc replikacji wszystkich zmian, dok onanych w DNS- ie, do duzej liczby serwerów DNS. W tej sieci bedzie przypuszczalnie spora liczba serwerów, co oznacza, ze aktualizacje beda krytyczne. Polaczenie duzej liczby serwerów wymagajacych odbioru aktualizacji z waznoscia aktualizacji oznacza, ze okresy pomiedzy transferami stref musza byc krótkie, co byc moze spowoduje ni emozliwy do zaakceptowania poziom ruchu sieciowego.
W tym przypadku mozemy tez skonfigurowac serwery DNS nizszego poziomu jako tylko buforujace, czyli nie przechowujace kopii pliku strefy. W celu zapewnienia mo zliwosci rozwiazywania nazw powinny one byc tak skonfigurowane, by przesylaly zadania dotyczace nieznanych im nazw do serwerów podstawowego i wtórnego na najwy zszym poziomie. Serwery buforujaceodpytuja glówny serwer DNS o rozwiazywanie nazw, a nastepnie zapisuja lokalnie wyniki w pamieci podrecznej na okreslony czas, bez koniecznosci transferu calej strefy. Zmniejsza to liczbe serwerów, którymi musimy z arzadzac. Taka konfiguracja sprawdza sie bardzo dobrze przy zalozeniu, iz uzytkownicy korzystajacy z okreslonego serwera DNS wyk onuja w pracy te same podstawowe zadania. W takim przypadku te same nazwy serwe rów bylyby rozwiazywane raz za razem, zazwyczaj z lokalnej pamieci podrecznej. Zastosowanie w tym przypadku serwerów b uforujacych jest dobrym rozwiazaniem, zwlaszcza jesli czas zycia (TTL ) rekordów DNS jest wy starczajaco dlugi. Jesli na potrzeby powyzszego rozwiazania ustawimy wysokie wartosci TTL, musimy pamietac, by zmniejszyc TTL przed modyfikacja wpisów w DNS -ie. Na przyklad, jesli zamierzamy przeniesc serwer pocztowy, a obecny TTL dla rekordów wynosi 8 godzin, mozemy na okolo 8 godzin przed przenosinami zmniejszyc TTL do 15 minut. W niektórych systemach mozna ustawiac TTL indywidualnie dla rekordów, co umozliwia modyfikacje tego parametru dla jednego serwera. Jesli zamierzamy zastosowac lokalny serwer b uforujacy skonfigurowany tak, by przes ylal zadania „w góre” do glównego serwera DNS, mozemy tez rozwazyc wykorzyst anie serwera podporzadkowanego ( slave). Zapobiegnie to próbom przekazywania przez se rwer DNS zapytan o nazwy do Internetu lub skonfigurowanychdla danego serwera se rwerów poziomu glównego. Mozemy równiez skonfigurowac dla lokalnych serwerów DNS ich serwer podstawowy jako strefe glówna. Niezaleznie od decyzji, jak skonfigurowac lokalne serwery (jako buforujace lub wtórne), mozemy uzyskac nadmiaro wosc, dodajac po prostu w klientach (za pomoca DHCP) wpis drugiego serwera DNS, wskazujacy na serwer glówny. Konfiguracja taka dobrze sprawdza sie w przypadku serwerów DNS, WINS i proxy. W przypadku serwera WINS wymagany jest dodatkowy krok, w którym lokalny serwer WINS wypycha zmiany do jednego z glównych serwerów WINS, natomiast glówny serwer WINS sciaga zmiany z serwera lokalnego. To pozwoli zaimplementowac jednokierunkowa replikacje pomiedzy lokalnymi serwerami WINS i serwerem glównym. Jako metode równowazenia obciazenia wywolanego zadaniami uzytkowników i zapewnienia nadmiarowosci mozemy stosowac dodatkowe serwery, wielo adres owosc i serwery hierarchiczne —albo polaczenie wszystkich trzech metod. Kazda z nich sie nadaje, lecz wszystkie opieraja sie na z asadzie rozkladu obciazenia na wiecej serwerów. Dobra wiadomosc: wiekszosc uslug, które musimy udostepnic w sieci, pozwala na takie ro zwiazania. W przypadkach, gdy to niemozliwe (na przyklad, dla niektórych baz danych i systemów poczty elektroniczej), musi myznalezc inne rozwiazanie —na przyklad kl astry .
Łączenie usług
Na rysunku trzeba dodac drugi serwer w zdalnej sieci, aby obslugiwal DHCP. Musimy dodac takze dodatkowe serwery sieciowe, na przyklad DNS, WINS i uwierzytelniajace serwery sieciowe.
Najprostsza siec zawiera serwery DHCP, DNS, plików i drukowania. Aby zapewnic nadmiarowosc dla tych uslug, potrzebnych byloby szesc serwerów: dwa DHCP, dwa DNS i dwa plików i drukowania. Dodajac kolejne sieci zdalne, jak na rysunku, musimy dodac trzy kolejne serwery , udostepniajace te podstawowe uslugi w sieci zdalnej.
Dodawanie serwera dla kazdej kolejnej uslugi w sieci jest kosztowne, w coraz wiekszym stopniu utrudnia zarzadzanie i zwieksza ruch sieciowy tla w sieci. Aby zmniejszyc liczbe serwerów w sieci, które wymagaja zarzadzania i generuja ruch sieciowy tla, mozemy polaczyc kilka uslug w jednym systemie. W rzeczywistych warunkach jest to normalne postepowanie i w praktyce mozemy obsluzyc cala siec przez pojedynczy serwer, jesli tylko siec jest wystarczajaco mala. Jedynym problemem jest tu umieszczenie wszystkich uslug raze m. Inaczej mówiac, gdy ten pojedynczy serwer zawiedzie, wszystkie uruchomione w nim uslugi przestana byc dostepne. Decydujac o tym, jakie uslugi polaczyc w jednym systemie, musimy wziac pod uwage, jakich zasobów wymaga kazda z uslug. Dla kazdej uslugi system potrzebuje czterech podstawowych zasobów:
- Procesor —uslugi typu DHCP, DNS, WINS i podobne uslugi zarzadzajace krótkimi listami nie wymagaja zbyt duzej mocy obliczeniowej. Uslugi obslugujaceduze listy (bazy danych), jak np. serwery Ora cle i MS SQL, wymagaja sporej mocy procesorów.
- Pamiec —wieksza ilosc pamieci w kazdym przypadku pomoze serwerowi. Czesto nie zauwaza sie faktu, iz CPU nie komunikuje sie z dyskiem, klawiatura lub z czymkolwiek innym —tylko z pamiecia. Dla systemu przeniesienie danych w pamieci, na przyklad z listy adresów do bufora, w którym budowany jest pakiet odpowiadajacy na zapytanie DNS, jest czynnoscia szybka i prosta. Prosze pamietac, ze elektrony w przewodach poruszaja sie z predkoscia porównywa z predkoscia swiatla, natomiast glowica zapisu-odczytu dysku twardego nie moglaby poruszac sie równie szybko bez zlamania praw fizyki. W teorii, gdyby glowica spróbowala zrobic cos takiego, jej masa wzroslaby do masy planety, powodujac kolaps grawitacyjny i powstanie czarnej dziury w systemie. Wniosek: aby zwiekszyc wydajnosc, potrzebujemy dodatkowej pamieci —a zwiekszenie pamieci wirtualnej (pliku wymiany na dysku) to nie to samo, co dokupienie RAM -u.
- Dysk —wydajnosc podsystemu dyskowego jest w niektórych przypadkach bardzo wazna —zwlaszcza w serwerach baz danych, na przyklad Oracle lub MS SQL , które moga posiadac terabajty danych. Dla serwerów typu DNS, WINS lub DHCP objetosc danych jest tak mala, ze przes trzen dyskowa nie jest czynnikiem krytycznym .
- Siec —zadaniem sieci jest przesylanie danych, wobec tego zdolnosc do przenoszenia danych pomiedzy serwerem i siecia jest bardzo wazna. Musimy zastosowac dobra karte sieciowa, poniewaz to za jej pomoca serwer bedzie wlaczony do sieci. Jesli przylaczymy serwer do koncentratora o przepustowosci 10 Mb/s, to bedzie musial rywalizowac o pasmo z wszystkimi innymi urzadzeniami przylaczonymi do tego koncentratora. Natomiast, jesli przylaczymy serwer do przelacznika 100 Mb/s, wówczas nie bedzie mial praktycznie z czym rywalizowac. Wobec tego polaczenie, typ uzytej karty i liczba kart sieciowychw systemie wplywaja na zdolnosc do przesylania danych, a co za tym idzie, na wydajnosc serwera.
Podczas laczenia uslug w serwerze nalezy wyszukiwac takie, które nie rywalizuja ze
soba o zasoby. W wiekszosci przypadków mozemy latwo polaczyc DNS , DHCP , WINS
i uwierzytelnianie sieciowe. W niekt órych przypadkach p olaczenie uslug jest posuni eciem bardzo oplacalnym. Na przyklad, usluga DDNS (dynamiczny DNS) wspólpracuje
z serwerem DHCP, re jestrujac pary nazwa – adres IP, jesli wiec zainstalujemy obie uslugi
w jednym systemie, ich wspólpraca nie bedzie generowac zadnego ruchu w sieci.
W systemach Microsoftu mozna skonfigurowac DNS tak, by nie znalezione adresy
sprawdzal w usludze WINS, wiec pol aczenie tych dwóch uslug tez jest sensowne.
Po podjeciu decyzji, jakie uslugi polaczyc, musimy po prostu ustalic charakterystyki
obciazenia systemu, który bedzie je obslugiwac. W tym celu mozemy korzystac z ró znych narzedzi, zaleznie od uzywanej platformy. Generalnie jednak powinnismy przy jrzec sie omówionym poprzednio czterem kluczowym zasobom systemu, najpierw dla
jednego klienta, nastepnie dla coraz wiekszych grup klientów. W pewnym momencie
jeden z zasobów osiagnie swój limit.
Prosze pamietac, ze liczba jednoczesnych uzytkowników moze przekroczyc maksimum, z
którym móglby poradzic sobie system. Poniewaz bardzo rza dko (lub nigdy) wszyscy
uzytkownicy beda polaczeni z serwerem jednoczesnie, mozemy do pewnego stopnia
nadmiarowo wykorzystac serwery. Przy planowaniu maksymalnejliczy uzytkowników nalezy
zwracac uwage na wzory wykorzystania serwera —a przynajmniej pamiet ac o nich. Wezmy
na przyklad serwer plików i drukowania: jest bardzo malo prawdopodobne, iz wszyscy
uzytkownicy beda równoczesnie zapisywac w nim plik przez siec.
Spójrzmy na przyklad na serwer DHCP. W danej sieci klienty zwykle pozostaja w je dnym miejscu, wiec przedluzylismy okres dzierzawy do osmiu dni. Jak Czytelnik pamieta z opisu DHCP w rozdziale 9., ustawienie okresu dzierzawy na osiem dni oznacza, iz
klienty musza odnawiac dzierzawy co cztery dni. Nastepnie musimy przyjrzec sie se rwerowi i ustalic liczbe równoczesnych polaczen, które jest w stanie obsluzyc. Z alózmy,
ze serwery, które chcemy wykorzystac sa zdolne do równoczesnej obslugi 6000 zadan
klientów.
Aby oszacowac liczbe klientów DHCP, jaka serwer DHCP jest w stanie obsluzyc, m usimy ustalic ile czasu zajmie serwerowi DHCP obsluga zadania odnowienia dzierzawy
(wybralismy proces odnowienia dzierzawy, poniewaz jest najczesciej uzywany). O dnowienie dzierzawy DHCP wymaga odbioru pakietu, kontroli dzierzawy, obliczenia
nowej daty wygasniecia dzierzawy i odeslania pakietu do klienta. Do ustalenia dokla dnego czasu moga posluzyc analizatory pakietów sieciowych lub monitor wydajnosci
systemu. W praktyce jednak ten proces nie powinien zajac wiecej niz jedna sekunde.
Wobec tego, na potrzeby przykladu zalozym y taka wartosc.
Mamy juz wszystkie dane, wiec musimy polaczyc je w celu ustalenia maksymalnej
liczby klie ntów, jaka moze obsluzyc jeden serwer DHCP. Wzór wyglada tak:
procesy/h = 3600 sekund / czas wykonania procesu
klienty/h = procesy/h * liczba równoczes nych zadan
suma klientów = okres odnawiania [h] * klienty/h
Jesli liczby z naszego przykladu wstawimy do równania, otrzymamy:
procesy/h = 3600/1
klienty/h = 3600 * 6000
suma klientów = 96 * 21 600 000
Maksymalna liczba klientów, jaka moze obsluzyc serwer D HCP w naszym przypadku
wynosi 2 073 600 000. Oczywiscie w rzeczywistych warunkach nigdy nie dojdziemy do
takiej wartosci. Jesli jednak zakladana liczbe klientów uzywajacych serwera DHCP podzielimy przez powyzszy wynik, otrzymamy w przyblizeniu odsetek zasobów systemu,
jakiego usluga (w tym przypadku DHCP) bedzie uzywac. Szacujac przyblizony odsetek
dla kazdej uslugi, bedziemy mogli ocenic, jak obciazony bedzie serwer.
Na rysunku do przykladowej sieci zostaly dodane wszystkie podstawowe uslugi
sieciowe:DHCP, DNS, WINS i uwierzytelnianie. Na tym etapie awaria rutera lub je dnego z systemów uslug sieciowych spowoduje, iz czesc uzytkowników sieci nie bedzie
mogla skorzystac z tych uslug. Co wiecej, gdyby nastapila awaria zasilania, a wszystkie
klienty podcz as uruchamiania pobieraly adres z DHCP, rejestrowaly sie w uslugach WINS
i DDNS, a nastepnie uwierzytelnialy w serwerze, serwery te moglyby zostac przeciazone po przywróceniu zasilania. Inaczej mówiac, gdy mamy juz w sieci wszystkie podstawowe uslugi, pora zaczac planowac równowazenie obciazenia i nadmiarowosc.
