Dokumentowanie sieci

Opis tego, jak sieć jest faktycznie zbudowana — topologii, adresacji, grupowania i zależności — tworzony przez system monitorowania, a nie utrzymywany ręcznie.

Dokumentacja sieci ma zwyczaj być dokładna w dniu jej utworzenia, a później stopniowo rozmijać się z rzeczywistością. Diagram znajduje się w jednym miejscu, plan adresacji w innym, a osoba, która wiedziała, dlaczego dane łącze istnieje, już odeszła.

NetCrunch podchodzi do tego z drugiej strony. Aby monitorować sieć, musi wykryć, jak jest ona zorganizowana, a ta wiedza jest przechowywana, przedstawiana graficznie i aktualizowana jako efekt uboczny monitorowania. Otrzymujesz opis sieci w jej obecnym stanie, a nie taki, jaki ktoś ostatnio zapisał.

nd-topology

Mapa rysuje się sama

Dwie warstwy topologii są wykrywane i utrzymywane bez konieczności ręcznego ich tworzenia:

Mapy routingu

Obraz logiczny — jakie sieci IP istnieją i które routery je łączą.

Mapy połączeń fizycznych

Obraz warstwy 2 — które urządzenie jest podłączone do którego portu przełącznika, wraz z widokiem poszczególnych przełączników pokazującym ruch na każdym porcie.

Obie warstwy opisano w Mapy Topologii Sieci, w tym sposób włączania monitorowania segmentów fizycznych oraz postępowania w przypadku braku urządzenia na mapie.

nd-organisation

Organizacja również jest wykrywana

Oprócz połączeń atlas rejestruje sposób podziału infrastruktury — a większość tych podziałów utrzymuje się automatycznie na podstawie monitorowanych danych, zamiast listy edytowanej przez użytkownika:

• Device Groups i Server Types — drukarki, przełączniki, urządzenia bezprzewodowe, Linux, Windows Server
• Locations — na podstawie danych lokalizacji SNMP lub wprowadzane ręcznie
• VLANs i Windows Domains
• Organizations — w przypadku infrastruktury obsługującej więcej niż jedną organizację
• Virtual Machine Hosts wraz z uruchomionymi na nich maszynami gościnnymi

Są to widoki dynamiczne: węzeł, który zmieni swoją rolę, samodzielnie przenosi się do innej grupy. Zobacz Zarządzanie widokami atlasu sieci.

Gdy ten sam adres oznacza dwa różne miejsca

Infrastruktura, w której ten sam zakres prywatny jest używany w więcej niż jednej lokalizacji, to dokładnie ten przypadek, w którym ręcznie utrzymywana dokumentacja przestaje być wiarygodna. NetCrunch obsługuje go za pomocą network sites — oddzielnych przestrzeni adresowych, dzięki czemu 192.168.1.10 w jednym oddziale nie jest mylony z 192.168.1.10 w innym. Site jest częścią sposobu identyfikowania węzła, a nie dodaną do niego adnotacją.

nd-dependencies

Od czego zależy co

Najbardziej użyteczną cechą opisu sieci zwykle nie jest lista jej elementów, lecz wiedza o tym, co przestanie działać, gdy jeden z nich ulegnie awarii.

NetCrunch rejestruje zależności na podstawie tego, co już wie: trasy do węzła, hosta wirtualizacji, na którym działa, oraz wykrytych połączeń warstwy 2. Dzięki temu może zgłosić awarię routera, a nie dwustu znajdujących się za nim węzłów.

Jeśli zależność ma charakter biznesowy, a nie sieciowy, możesz opisać ją samodzielnie za pomocą statusu złożonego, a NetCrunch przedstawi wynik na mapie. Zobacz Status złożony oraz Business Service Views.

nd-your-knowledge

Część znana tylko Tobie

Mechanizm wykrywania nie ustali, kto jest właścicielem serwera, jaki kontrakt go obejmuje ani dlaczego istnieje dane łącze. Służą do tego dwie funkcje:

Custom fields

Pole liczbowe, tekstowe, daty, czasu lub lista wyboru dodawane do rekordu węzła. Ponieważ widoki mogą filtrować według tych pól, „wszystko, czego właścicielem jest dział finansowy” staje się widokiem, który sam się aktualizuje. Zobacz Zarządzanie dodatkowymi danymi o węźle. .

Notes

Dowolny tekst przypisany do węzła, przeznaczony na uzasadnienia i informacje, które nie pasują do żadnego pola.

Klasyfikacja urządzenia znajduje się pomiędzy tymi dwiema funkcjami — jest w większości wykrywana automatycznie, może być korygowana ręcznie i warto ją korygować, ponieważ od niej zależy wiele innych elementów. Zobacz Menedżer identyfikacji urządzeń.

nd-boundaries

Czego to nie obejmuje

• Dokumentuje to, co monitoruje. Wszystko, czego NetCrunch nigdy nie wykrył, nie jest opisane, więc zakres dokumentacji odpowiada zakresowi monitorowania.
• Rejestruje stan faktyczny, a nie zamierzony. Mapy przedstawiają sieć w stanie wykrytym przez system. Łącze, którego nie powinno być, jest rysowane dokładnie tak samo jak łącze, które powinno istnieć.
• Nie jest narzędziem do projektowania. Nie ma diagramu planowanego stanu, z którym można byłoby porównać stan wykryty.

address spaceas-builtcustom fieldsdependenciesdevice typedocumentationdynamic viewsinfrastructurelayer 2network documentationnetwork sitesnotesphysical connectionsrouting maptopology