Zarządzałem tylko niewielkimi sieciami (<= 25 węzłów). Zazwyczaj umieszczam bramę .1, dns / proxy jako .10, pocztę na .20, drukarki na .30-39 i tak dalej. Nigdy nie używam adresów IP bezpośrednio, ponieważ nazwy hostów DNS są wyraźnie lepszym sposobem, ale lubię mieć jasny wzorzec / układ / projekt podczas budowania sieci od podstaw.
Moje mapowanie DNS ma również prosty wzorzec / układ nazewnictwa. Na przykład wszystkie moje urządzenia mają dwie nazwy; jedna formalna nazwa oparta na roli (dc01, mail02 itp.) i nieformalna nazwa. Nic szczególnego, ale naprawdę proste i łatwe w zarządzaniu.
Próbuję wymyślić bardziej intuicyjny / kreatywny schemat IP / podsieci / DNS (jeśli jest coś lepszego). Jestem pewien, że inni mają bardziej intuicyjne schematy w zależności od celów sieci i tym podobnych. Moja sieć, nad którą pracuję, jest wciąż niewielka, ale mam wiele urządzeń, z którymi mogę się zmagać.
Szukam ogólnego wzorca lub metodyki przypisywania adresu IP (zakresów / klas), nazw dns i sieci podsieci, które obejmują 4-5 głównych punktów:
- Usługi sieciowe (poczta, pliki, proxy itp.)
- Tworzenie oprogramowania (środowiska - dev / staging / prod,
- Media (streaming, przesyłanie dużych plików, archiwizacja)
- Wirtualne serwery / komputery stacjonarne
- VoIP
Nigdy nie współpracowałem bezpośrednio z VoIP, ale warto wziąć to pod uwagę na przyszłość.
Ogólnie mam od wszystkich naprawdę dobre pomysły. Chciałbym dać więcej głosów / zaakceptowanych odpowiedzi. Dziękuję za odpowiedzi!
źródło
Pracowałem w organizacji o podobnej wielkości (mieliśmy / 26), która z przyczyn niezależnych ode mnie uważała, że precyzyjny schemat alokacji własności intelektualnej był najważniejszy dla integralności operacyjnej. Brama musiała być .1, drukarki musiały być między .2 a .12, serwery między .13 a .20 i tak dalej. Prowadziliśmy nawet dokumentację na temat poszczególnych hostów.
To ogromny ból w dupie. Bez względu na to, jak bardzo byłem sumienny, nigdy nie wydawałem się, aby dokumentacja była aktualna. Nie pomogło nam to, że nie mieliśmy żadnych usług DNS, więc korzystanie z dokumentacji schematu alokacji adresów IP było jedynymi usługami „nazywania”, jakie mieliśmy (co w dziwny sposób sprawiło, że wydawało się to bardziej niezbędne niż w rzeczywistości).
W przypadku sieci twojego rozmiaru poleciłbym kilka rzeczy (z których większość już zrobiłeś):
Proste - nie zarządzasz setkami hostów. Złożoność rozwiązania powinna odzwierciedlać złożoność środowiska. Opieraj się pokusie bycia zbyt sprytnym. Podziękujesz sobie później.
Weź dostępną przestrzeń IP i daj klientom 60% za pośrednictwem DHCP. Skonfiguruj jakieś dynamiczne usługi DNS, abyś nigdy więcej nie musiał patrzeć na cholerny adres IP. Zapomnij o ich śledzeniu. Zysk.
Zarezerwuj pozostałe 30% na adresy IP, którymi zarządzasz: serwery, drukarki, urządzenia sieciowe, usługi testowania. itp. UŻYJ DNS DO DOKUMENTOWANIA TEGO. Moim zdaniem nie ma większej straty czasu niż uważne śledzenie wszystkich tych „zarządzanych przez administratora” adresów IP (w przeciwieństwie do adresów IP zarządzanych przez DHCP) za pomocą arkusza kalkulacyjnego Excel (do którego należy stale odnosić się i utrzymywać) , kiedy możesz wkładać ten wysiłek we wspieranie samokontraktującego i znacznie bardziej użytecznego rozwiązania DNS.
Nie wykorzystuj ostatnich 10% swojego adresu u góry przestrzeni adresowej IP. Mała rezerwa nigdy nie boli.
Dostosuj współczynniki według własnego uznania. Niektóre środowiska będą miały więcej klientów, inne będą obciążone „serwerami” (tj. „Zarządzanymi przez administratora”).
Oba należą do kategorii „zarządzanych przez administratora” przestrzeni IP.
Moim zdaniem ma to niewiele wspólnego z podsieciami i wszystko z monitorowaniem sieci.
Serwery są „zarządzane przez administratora”, komputery stacjonarne (tj. Komputery klienckie) powinny być „zarządzane przez DHCP”.
Fizycznie dyskretna sieć byłaby idealna ... ale to nierealne. Kolejną najlepszą rzeczą będzie oddzielna sieć VLAN i podsieć. Jest to jedyny punkt w małej sieci, w którym naprawdę czułbym potrzebę segregacji ruchu (z wyjątkiem rzeczy publicznie dostępnych).
źródło
Przydziały IP
Radzę umieścić wszystko w podsieci 10.0.0.0/8, korzystając z następującej struktury: 10
site..division.devicesitejest fizyczną lokalizacją lub logicznym odpowiednikiem (np. biuro w Nowym Jorku, biuro w NJ, ośrodek DR, środowisko programistyczne).divisionjest logicznym podziałem, który ma dla ciebie sens. np.0 => Przełączniki / routery
1 => Administratorzy, 2 => Użytkownicy
3 => VOIP
4 => Goście
devices to pojedyncze urządzenia (komputery, serwery, telefony, przełączniki itp.)Chodzi o to, że można łatwo określić, co to jest urządzenie i gdzie jest jego adres: 10.2.1.100 jest stacją roboczą administratora w „Witrynie nr 2”.
Ten model wywodzi się z przypisań IP opartych na klasach: klasa A (/ 8) to twoje przedsiębiorstwo. Każda lokalizacja otrzymuje klasę B (/ 16), a każdy logiczny podział w lokalizacji otrzymuje klasę C (/ 24) dla swoich urządzeń.
Możliwe jest (a czasem pożądane) użycie czegoś większego niż a / 24 na poziomie „podziału”, a na pewno możesz to zrobić: wszystko od a / 17 do a / 24 jest ogólnie uczciwą grą z tym schematem.
Dla nazw DNS
Radzę postępować według schematu podobnego do przypisanego powyżej adresu IP:
mycompany.comsitename.mycompany.comsubdomenę.voip.mycompany.com(z urządzeń takich jaktel0000.voip.mycompany.com,tel0001.voip.mycompany.cometc.)switches.mycompany.comworkstations.mycompany.com(ewentualnie podzielony na administratora, użytkownika i gościa)Można to osiągnąć za pomocą „boring” nazwy (
www01,www02,db01,db02,mail, itd.) Lub poprzez ogłaszanie schemat nazewnictwa i trzymanie się go (na przykład: serwery pocztowe są nazwane po skałach, serwery www są nazywane po drzewach, serwery baz danych są nazwany na cześć malarzy).Nudne imiona są łatwiejsze do nauczenia się przez nową osobę, fajne schematy nazewnictwa są przyjemniejsze. Wybierz swój.
Różne uwagi
W odniesieniu do serwerów wirtualnych:
rozważ je tak, jakby były maszynami fizycznymi (posegreguj je według podziału / celu, a nie faktu, że są one „wirtualne”. Mają osobny podział dla sieci Hypervisor / VM Administration.
Może to wydawać się ważne aby dowiedzieć się, czy skrzynka jest wirtualna czy fizyczna, ale gdy system monitorowania mówi „Hej, e-mail nie działa!”, pytanie, które zadajesz, brzmi: „Które maszyny są powiązane z pocztą e-mail?”, a nie „Które maszyny są które są wirtualne i fizyczne?”.
Należy pamiętać, że nIE potrzeba praktycznego sposobu identyfikacji, czy dana maszyna jest wirtualny lub fizyczny w przypadku hosta hypervisor wieje, ale jest to wyzwanie dla systemu monitorowania, nie architekturę sieci.
W odniesieniu do VOIP:
VOIP (w szczególności gwiazdka) jest synonimem „dziury w zabezpieczeniach”. Przenieś wszystkie swoje VOIP na własną podsieć i własną VLAN, i nie pozwól, aby znajdowała się w pobliżu czuła.
Każdy telefon VOIP, który widziałem w ubiegłym roku, obsługuje segregację VLAN (w rzeczywistości wszystkie obsługują zarówno sieci głosowe, jak i danych VLAN, więc nadal możesz używać telefonu jako przepustowego połączenia dla stacjonarnych połączeń Ethernet). Skorzystaj z tego - będziesz zadowolony, że zrobiłeś to, jeśli / kiedy twoje środowisko VOIP zostanie zhakowane.
Odnośnie planowania i dokumentacji:
Narysuj sieć na papierze, zanim zaczniesz przypisywać adresy i nazwy DNS. W rzeczywistości najpierw narysuj ołówkiem na DUŻYM arkuszu papieru.
Popełniaj wiele błędów.
Wymaż swobodnie.
Przeklinaj płynnie.
Gdy przestaniesz przeklinać i wymazywać przez co najmniej 10 dni, nadszedł czas, aby umieścić diagram w Visio / Graffle / Niektóre inne formaty elektroniczne jako oficjalny schemat sieci. Zabezpiecz ten schemat. Zachowaj to w swojej Świętej Poprawności, dodając i usuwając urządzenia, rozwijając organizację i modyfikując strukturę sieci.
Ten schemat sieci będzie najlepszym przyjacielem, gdy będziesz musiał wprowadzić zmiany, wyjaśnić sieć nowym administratorom lub rozwiązać tajemniczą awarię.
źródło
app01.hypervisor02.site.mycompany.com). Przemyślany i wdrożony system monitorowania to drugi niezbędny element (po organizacji sieci) w każdym środowisku, na którym Ci zależy.