[ Pobierz całość w formacie PDF ]
.W strefie DNS, bêd¹cejczêœci¹ przestrzeni nazw DNS, rekordy bazy danych s¹ przechowywane i zarz¹dzanew okreœlonym pliku bazy danych DNS.Dane przechowywane w strefie udostêpnianes¹ za pomoc¹ kilku serwerów nazw, w których utrzymuje siê aktualnoœæ danychpoprzez replikacje (nazywane w DNS-ie transferami stref).Drzewo domen Active Directory zawsze stanowi ci¹g³¹ przestrzeñ nazw.Dziêkitemu dana przestrzeñ nazw mo¿e zostaæ przydzielona do jednej strefy, podzielonana wiêcej stref odpowiadaj¹cych poszczególnym domenom lub podzielona wjakikolwiek inny sposób uznawany za rozwi¹zanie optymalne.Ogólnie mówi¹c, wprzedsiêbiorstwie du¿ym i silnie zdecentralizowanym bardziej wydajnymrozwi¹zaniem jest stosowanie wiêkszej iloœci stref.Odpowiednio, w ma³ym iscentralizowanym przedsiêbiorstwie dobrze siê sprawdza mniejsza iloœæ stref, zpowodu mniejszego obci¹¿enia sieci replikacjami i mniejszych nak³adów pracy nazarz¹dzanie.Inaczej mówi¹c, mo¿na podzieliæ przestrzeñ nazw na strefy w celu wyrównywaniaobci¹¿enia.Zak³adanie stref na podstawie struktury fizycznej przedsiêbiorstwazazwyczaj utrzymuje lokalne dane DNS blisko oœrodka najczêœciej potrzebuj¹cegonazw DNS.Mo¿e byæ to znacz¹cym powodem trzymania w ryzach ruchu sieciowego,zwi¹zanego z zapytaniami klientów o nazwy, przez wolne ³¹cza sieci lokalnych irozleg³ych.Z drugiej jednak strony, du¿e scentralizowane przedsiêbiorstwo,posiadaj¹ce proporcjonalnie du¿¹ strukturê stref, rozprowadza transfery strefDNS (replikacje) w znacznie wiêkszym obszarze, co mo¿e zwiêkszyæ spowodowanereplikacjami obci¹¿enie wolnych ³¹czy sieci rozleg³ych i lokalnych.WskazówkaTrzeba zdaæ sobie sprawê, i¿ w rzeczywistoœci do planowania struktur stref ireplikacji nie dysponujemy innymi zasadami ni¿ czysto praktyczne, pochodz¹ce zdoœwiadczenia.Przyczyn¹ takiego stanu rzeczy jest z³o¿onoœæ i elastycznoœæsystemu DNS.Zalecam tutaj maksymalne wykorzystywanie tej elastycznoœci przyprojektowaniu stref i replikacji.Wartoœci podane w rekordzie SOA i stosowaneprzez Microsoft w³aœciwoœci przedawniania i oczyszczania to tylko dwa przyk³adyparametrów, pozostawienia których w spokoju Czytelnik niemal na pewno bêdzie¿a³owa³.Udostêpnienie nadmiarowych Ÿróde³ rozwi¹zywania nazw (tzn.kilku serwerów nazw)w ka¿dej strefie DNS pomo¿e usun¹æ pojedynczy punkt awarii, a w konsekwencji —unikn¹æ ryzyka przesy³u wszystkich zapytañ klientów sieci¹ rozleg³¹.Pozwala torównie¿ na rozmieszczenie danych DNS w pobli¿u klientów, u¿ywaj¹cych ichnajczêœciej.Jednak¿e im wiêcej serwerów nazw, tym wiêcej ruchu sieciowegozwi¹zanego z replikacj¹.Wobec tego, planuj¹c strefy DNS, trzeba zrównowa¿yæiloœæ serwerów nazw potrzebnych w ka¿dej strefie z iloœci¹ stref.WskazówkaUwaga na aktualizacje dynamiczne.Dynamiczny DNS, w przeciwieñstwie do DNS-u,charakteryzuje siê du¿¹ iloœci¹ aktualizacji.Niestety standard nie pozwala nakierowanie aktualizacji gdziekolwiek indziej ni¿ do podstawowego serwera nazw.Wobec tego, nie ma sposobu na pozbycie siê tego istotnego pojedynczego miejscaawarii, nie mo¿na te¿ uporaæ siê z problemami przepustowoœci sieci powodowanymimnogoœci¹ aktualizacji.Jedynym sposobem na utrzymanie w ryzach ruchusieciowego i skali problemu z krytycznym miejscem awarii jest tworzeniekolejnych stref.Projekt rozmieszczenia stref DNS i serwerów nazw zawsze wymaga kompromisupomiêdzy potrzebami odpornoœci na uszkodzenia, równowa¿eniem rozk³aduobci¹¿enia zapytaniami a potrzeb¹ równowa¿enia rozk³adu ruchu sieciowegoreplikacji.Na koniec trzeba jeszcze pamiêtaæ i¿ naj³atwiejszym sposobemzarz¹dzania przestrzeni¹ nazw DNS jest zatrzymanie pe³nomocnictw dla wszystkichdomen podrzêdnych w pojedynczej strefie – harówka administracyjna zawsze roœnierazem z iloœci¹ stref.WskazówkaWzrost liczby stref najczêœciej prowadzi zarazem do wzrostu liczby zapytañprzekazywanych do serwerów DNS na zewn¹trz lokalnego oœrodka.Dobry projektus³ugi DNS powinien wzi¹æ to pod uwagê (stosuj¹c mniej stref, inaczej dziel¹cprzestrzeñ nazw domen, u¿ywaj¹c lokalnych serwerów nazw w roli serwerówwtórnych dla omawianych stref), jednym s³owem unikn¹æ dotycz¹cych strefdecyzji, które mog¹ prowadziæ do znacznego pogorszenia ogólnego obci¹¿eniasieci.Lecz trzeba pamiêtaæ, i¿ zajmujemy siê tutaj bardzo z³o¿on¹ i zmienn¹ sytuacj¹,wobec czego rezultaty mog¹ ró¿niæ siê znacz¹co zale¿nie od aplikacji (a nawetzale¿nie od ró¿nych wersji tej samej aplikacji) i projektów.Wobec tego w wieluprzypadkach trzeba raczej zaufaæ intuicji zamiast podejmowaæ decyzje napodstawie faktów.Przyk³adem takiej niekoñcz¹cej siê z³o¿onoœci mog¹ byæ rekordy do znajdowaniaGC (wykazu globalnego) i kontrolera domeny na podstawie samego GUID, którerejestrowane s¹ jedynie w strefie DNS zawieraj¹cej szczytow¹ domenê lasu ActiveDirectory.O ile lokalizacja DC na podstawie GUID u¿ywana jest przezreplikacje, nikt tak naprawdê nie wie, jak intensywnie rekordy te bêd¹ u¿ywane— oraz, konsekwentnie, czy zapytania o te rekordy bêd¹ do wytrzymania, czy te¿trzeba bêdzie dodaæ w jednym serwerze nazw DNS przypadaj¹cym na ka¿d¹ lokacjêstrefê, zawieraj¹c¹ domenê g³Ã³wn¹ lasu (z doœwiadczenia autora wynika, i¿nale¿y daæ sobie z tym spokój; transfery stref w szkieletowym œrodowiskuWindows 2000 powoduj¹ znacznie wiêkszy ruch sieciowy ni¿ same zapytania, chyba¿e w strefie lasu dysponujemy jedynie kilkoma kontrolerami domen).Nie zapominajmy o strefach wyszukiwania wsteczPozostaj¹c przy temacie stref, nie pope³niajmy typowego b³êdu nowicjuszy:zapominania, koncentruj¹c ca³¹ uwagê na strefach wyszukiwania w przód, ostrefach wyszukiwania wstecz, póki nie wydarzy siê coœ nie tak! Okreœlenie,jakie strefy wyszukiwania wstecz nale¿y utworzyæ i gdzie je rozmieœciæ, wymaganiemal tyle samo wysi³ku, co projektowanie stref wyszukiwania w przód.O ile strefy wyszukiwania wstecz i rekordy zasobów PTR nie s¹ niezbêdne dofunkcjonowania us³ugi Active Directory, to rekordy PTR s¹ powszechnie stosowaneprzez aplikacje weryfikuj¹ce to¿samoœæ klienta.Potrzebne bêd¹ te¿, jeœliklienty maj¹ byæ zdolne do rozwi¹zywania nazw FQDN na podstawie adresów IP.Abydobrze zaprojektowaæ strefy wyszukiwania wstecz, nale¿y wpierw zebraæ listêwszystkich podsieci w danej sieci, a nastêpnie okreœliæ klasê (A, B lub C) oraztyp (oparty o klasê lub podsieæ) ka¿dej podsieci.UwagaAby uproœciæ zarz¹dzanie, warto utworzyæ jak najmniej stref wyszukiwaniawstecz, jak to mo¿liwe.Na przyk³ad, dysponuj¹c tylko jednym identyfikatoremsieci klasy B lub C, czêsto warto zdefiniowaæ strefy wyszukiwania wsteczzgodnie z granicami klasy B lub C, niezale¿nie od tego, czy jest ona podzielonana podsieci, czy nie.Strefy wyszukiwania wstecz s¹ czêœci¹ przestrzeni nazw DNS, wobec czego mog¹byæ, teoretycznie, tworzone bez zwa¿ania na w³aœciwoœci TCP/IP infrastrukturysieci, której dotycz¹.Strefy wyszukiwania wstecz s¹ te¿ ca³kowicie odrêbne odstref wyszukiwania w przód, co oznacza, i¿ poddomeny i strefy wyszukiwania wprzód nie musz¹ posiadaæ w³asnych stref wyszukiwania wstecz
[ Pobierz całość w formacie PDF ]