Wykłady z przedmiotu Sieci komputerowe podstawy Wykład 12

Transkrypt

1 Wykłady z przedmiotu Sieci komputerowe podstawy Wykład 12 Opracowali: Monika Nazarko, Krzysztof Raczkowski IIIFDS na podstawie wy- kładów dr inż. Mirosława Hajdera

2 1 STRESZCZENIE Wykład omawia problem diagnostyki i zarządzania siecią. Opisuje metodykę poszukiwań uszkodzeń w sieci oraz typowe problemy, jakie mogą w niej wystąpić. Przedstawia także protokoły służące do zbierania informacji o sieci, pozwalające diagnozować jej stan oraz śledzić ruch w niej generowany.

3 SPIS TREŚCI 2 Streszczenie Diagnostyka sieci Metodyka wyszukiwania uszkodzeń w sieci Określenie priorytetów Kompletowanie stosownej informacji Określanie prawdopodobnych przyczyn Sprawdzanie rozwiązań Badanie i szacowanie rezultatów Dokumentowanie Typowe problemy sieci komputerowych Elementy zarządzania siecią SNMP RMON... 7

4 3 1. DIAGNOSTYKA SIECI Obiekty informatyczne dzielą się na dwie grupy: - już zepsute - te, które zepsują się w pewnym konkretnym czasie. Pewne parametry niezawodnościowe (np. MTBF) wprowadzają błędne rozumowanie stwierdzające, że w eksploatacji systemu nie można mówić o jakiejkolwiek awarii. Założenie to jest prawdziwe jedynie przy zapewnieniu idealnych warunków funkcjonowania systemu. W praktyce, takie warunki są niemożliwe do spełnienia. Próbując więc zapewnić maksymalną niezawodność dowolnego systemu, nie można polegać wyłącznie na jego parametrach niezawodnościowych. Im bardziej złożony system, tym jego czas MTBF jest mniejszy (jest on wypadkową czasów MTBF poszczególnych urządzeń). Istnieją systemy, od których wymaga się niezawodności działania noszą nazwę newralgicznych. Wprowadza się w nich nadmiarowość sprzętową, informacyjną i ewentualnie czasową. W rezultacie osiąga się system odporny na uszkodzenia (fault-tolerant). Jest on w stanie pełnić swoje funkcje nawet po wystąpieniu awarii (wówczas jego praca odbywa się przy gorszych parametrach, np. czasowych). Według statystyk, procent fałszywych zgłoszeń awarii w systemie jest największy w początkowym okresie jego działania (sięga nawet do 80-90%). Problemy wynikają np. z tego, że użytkownik samodzielnie przekonfigurował coś w systemie, bądź nie ma wystarczających wiadomości do korzystania z systemu. Rozkład pomiędzy zgłoszeniami fałszywymi a prawdziwymi zmienia się wraz ze zwiększaniem się długości eksploatowania systemu. Okres wstępny (z ogromną ilością fałszywych alarmów) trwa zazwyczaj do pół roku. Bez względu na parametry niezawodnościowe poszczególnych komponentów, istnieje znaczne prawdopodobieństwo uszkodzenia systemu informatycznego, zarówno w części programowej jak i sprzętowej. W większości przypadków, przyczyną uszkodzenia jest niespełnienie wymogów odnoszących się do funkcjonowania systemu. Jeżeli system jest systemem newralgicznym, konieczne jest zastosowanie architektury odpornej na uszkodzenia. System odporny na uszkodzenia (fault-tolerant) to system, w którym w przypadku uszkodzenia jego komponentów zachowywane są parametry funkcjonalne przy niezmiennym, bądź zmieniającym się w niewielkim zakresie wydajności systemu. W przypadku sieci komputerowych, przestoje w działaniu powinny być mierzone w promilach. W niektórych warunkach może to być trudne do osiągnięcia (do przestoi zalicza się również brak kontaktu z siecią zewnętrzną a to już może być problem niezależny). W warunkach polskich, dopuszczalne są przestoje rzędu pojedynczych procentów. Projektując sieć komputerową należy być przygotowanym, że bez względu na sposób projektowania i jej eksploatacji, uszkodzenia i defekty najprawdopodobniej się i tak pojawią. Należy je wówczas zlokalizować i usunąć.

5 2 METODYKA WYSZUKIWANIA USZKODZEŃ W SIECI Metodyka składa się z następujących podstawowych kroków: 1) określenie priorytetów, 2) kompletowanie stosownej informacji, 3) określanie prawdopodobnych przyczyn, 4) sprawdzanie rozwiązań, 5) badanie i szacowanie rezultatów, 6) dokumentowanie Określenie priorytetów Problemy występujące w sieci należy uszeregować względem stopnia ważności. Rozwiązywać należy najpierw zadania o najwyższym priorytecie. Nierzadko zdarza się tak, że administratorzy w pierwszej kolejności rozwiązują problemy, które są im znane. Podczas rozwiązywania tych problemów pojawiają się nowe, proste do rozwiązania którymi administrator zajmuje się w następnej kolejności. Natomiast problemy o dość wysokim priorytecie, które w sposób istotny rzutują na funkcjonowanie sieci (w wielu przypadkach trudne problemy), są często nie rozwiązywane Kompletowanie stosownej informacji Podstawowymi źródłami informacji są: 1) użytkownicy, Jednym z podstawowych źródeł pochodzenia informacji o uszkodzeniu w systemie są sami użytkownicy. Często nie są to jednak wiarygodne źródła informacji. Większość użytkowników ma niską kulturę informatyczną i nie potrafi sprecyzować problemu. Rozwiązaniem mogą tu być ankiety, w których większość pytań sformułowana jest tak, aby odpowiedź na nie brzmiała tak lub nie. 2) raporty systemu, w tym systemu zarządzania, Innym źródłem są informacje zbierane przez sam system. Można wykorzystać tu standardowe rejestry systemu. W większości przypadków, audyt systemowy jest dość ubogi producent, projektując system, nie chce zawierać w nim funkcji, które w istotny sposób będą obciążać zasoby. Analiza audytu pozwala określić, czy występujące problemy nie pojawiały się już wcześniej. Przeglądanie ręczne może być jednak niezbyt efektywne audyt może mieć pokaźne rozmiary. Większość producentów systemów operacyjnych (jednak nie tych popularnych, użytku domowego) wyposaża je standardowo w specjalne podsystemy diagnostyki, rejestrujące wszystkie przerwania natury sprzętowej. Awaria np. dysku twardego jest odnotowana przez taki system i można przeczytać wszystkie dane dotyczące błędów odczytu bądź zapisu. Metody te wykorzystują np. systemy firmy Sun. Jest to kontynuacja idei IBM-a z roku 1978 procesora diagnostycznego z serii 43.

6 Systemy diagnostyczne nie mogą być efektywnie wykorzystane w sieciach komputerowych. Tu szersze zastosowanie mają systemy zarządzania. 5 Istnieje także szereg specjalistycznych narzędzi diagnostycznych (np. tester protokołów, sonda IDS). Barierą przed ich powszechnym wykorzystywaniem jest wysoka cena (rzędu kilkudziesięciu tysięcy dolarów). W przypadku części problemów, jako źródło informacji mogą posłużyć pliki audytu, rejestrujące zdarzenia występujące w systemie operacyjnym. W odniesieniu do sieci, źródłem takich informacji mogą być systemy zarządzania, w szczególności oparte o mechanizm RMON. W dużych sieciach źródłem informacji mogą być przyrządy diagnostyczne (tester okablowania, tester protokołu, reflektometr) Określanie prawdopodobnych przyczyn Metodą eliminacji określamy najbardziej prawdopodobne przyczyny uszkodzenia. Na podstawie zdobytych informacji należy określić prawdopodobne przyczyny awarii. Źródłem może być każda z informacji zebranych w poprzednim kroku Sprawdzanie rozwiązań Określone w poprzednim kroku potencjalne przyczyny należy posortować według. prawdopodobieństwa ich wystąpienia, a następnie, z pomocą konkretnych metod, sprawdzać czy stanowią one przeszkodę w funkcjonowaniu sieci. Należy dbać o możliwość przywrócenia stanu systemu sprzed modyfikacji. Po zmianie plików konfiguracyjnych, musi istnieć możliwość wrócenia do konfiguracji pierwotnej (backup). Zmieniając okablowanie musi istnieć możliwość przywrócenia jego dawnego stanu Badanie i szacowanie rezultatów Weryfikacja polega na sprawdzeniu poprawności funkcjonowania systemu Dokumentowanie Dokumentowanie problemu wykorzystywane jest: 1) do rozwiązania problemu w przypadku jego ponownego pojawienia się; 2) w profilaktyce. 3. TYPOWE PROBLEMY SIECI KOMPUTEROWYCH Typowe problemy występujące w sieciach komputerowych związane są z: 1) mediami transmisyjnymi (niska jakość, zanieczyszczenie końcówek stykowych, zagięcia kabla występujące odbicia, uszkodzone terminatory itp.); 2) urządzeniami sieciowymi (najczęściej zdezaktualizowanie sterowników); 3) niezgodnością protokołów sieciowych; 4) przeciążeniem sieci; 5) sztormami transmisyjnymi; 6) problemami z zasilaniem;

7 7) problemami serwera ELEMENTY ZARZĄDZANIA SIECIĄ Jednym z podstawowych zadań, które ma spełniać rozbudowany system zarządzający jest realizacja w trybie bezpiecznym (szyfrowanym) rekonfiguracji urządzeń zdalnych. Bardzo ważną rolę spełnia też możliwość zbierania informacji o funkcjonowaniu sieci. W systemach zcentralizowanych (opartych na jednej jednostce), system zarządzania może ograniczyć się wyłącznie do zarządzania daną jednostką. Profesjonalne systemy zarządzania pracują w systemie rozproszonym. Składają się ze stacji-managera i klientów zainstalowanych na wszystkich stacjach roboczych. W strukturze sieci mogą znaleźć się jednostki, na których nie można zastosować agenta zrządzającego. Jako rozwiązanie stosuje się tu tzw. agenta zastępczego specjalne oprogramowanie (ewentualnie sprzęt) konwertujące informacje pomiędzy stacją zarządzającą a urządzeniem zarządzanym. System zarządzający ma charakter rozproszony i składa się z trzech podstawowych komponentów: 1) menadżera stacji roboczej z zainstalowanym programem zarządzającym; 2) agenta systemu programowo-sprzętowego zainstalowanego w węźle systemu, zadaniem którego jest zbieranie, przechowywanie oraz przetwarzanie informacji o funkcjonowaniu systemu; 3) bazy informacyjnej zarządzania MIB zbiór zarządzalnych obiektów zdefiniowanych dla konkretnego urządzenia zarządzanego. W chwili obecnej wyróżniamy dwa podstawowe standardy zarządzania 1) SNMP, 2) RMON SNMP Procedury SNMP zostały zrealizowane na poziomie warstwy aplikacji modelu ISO/OSI. Powstały końcem lat 80-tych (rok 1989). Zdefiniowane były głównie po to, aby zbierać statystyki funkcjonowania urządzeń. Protokół ten nie zawiera żadnych narzędzi bezpieczeństwa. Zapytania do dowolnych agentów można było kierować z dowolnej stacji, która mogła się podszywać pod stację zarządzającą. W roku 1994 pojawiła się druga wersja protokołu SNMP. Poza zmianami wprowadzającymi większą elastyczność procesu zarządzania, dodano również narzędzia bezpieczeństwa. Wśród nich mechanizmy autentyfikacji (zarówno stacji zarządzającej, jak i agenta, z zastosowaniem narzędzi kryptograficznych) oraz procedury szyfrowania.

8 7 4.2.RMON Protokół SNMP zawiera narzędzia do analizy funkcjonowania urządzeń sieciowych. Brakuje mu jednak rozwiązania pozwalającego na śledzenie przepływów w sieci. Zadaniem protokołu RMON, który powstał w roku 1990, jest śledzenie i analiza ruchu w sieci. Jest to narzędzie dopełniające działanie SNMP. Wyróżnić można dwie wersje protokołu RMON. Pierwsza powstała w Początkowo była nazywana RMON, po pewnym czasie zaczęto ją określać jako RMON1. Aplikacja ta funkcjonowała na poziomie warstwy fizycznej i warstwy łącza danych pozwalała na analizę dość prymitywnych protokołów, co ograniczało jej funkcjonalność. W roku 1996 pojawiła się kolejna wersja protokołu RMON2, funkcjonująca na pięciu górnych warstwach modelu ISO/OSI (od warstwy sieci do warstwy aplikacji). Wykorzystanie protokołów o wyższym poziomie abstrakcji zwiększało możliwości funkcjonalne, kosztem pogorszenia parametrów wydajnościowych. Aby poprawić wydajność zakłada się, że dane przetwarzane są lokalnie na stacji zarządzanej, a do stacji-managera trafiają wyniki przetwarzania. W procedurach RMON pojawiły się grupy (w przypadku RMON1 było to 9 grup, dla RMON2 12 grup) opisujące pewne konkretne możliwości, np. dokładne trasowanie ruchu (tzw. przepływy międzywęzłowe), filtracja (sposób traktowania filtrowanych pakietów), ruch hostów, analiza ruchu pomiędzy stacją roboczą a hostem, alarmy, historia, zdarzenia o negatywnym charakterze. Do niedawna, nie spotykało się urządzeń, które miałyby wbudowanych agentów RMON pracujących na wszystkich grupach. Zwykle używano grup związanych z przepływami, statystykami. Obecne urządzenia wykorzystują wszystkie grupy.