Sunday, October 11th, 2009...11:34 pm

Jedna podsieć by związać wszystkich …

Jump to Comments

Czas powyrzucać z siebie trochę tematów do blogowania, których nazbierało się ostatnio dużo. Kilka z nich zainspirowanych będzie prezentacjami i rozmowami z TEC 2009 z Berlina – ten jest pierwszym z nich. Dotyczy tematu, który poruszał na swojej prezentacji Brian Desmond, a o którym i tak chciałem napisać po przeczytaniu artykułu na polskich stronach TechNET (okropnie pokaleczonego językowo – jeżeli czyta to osoba, która może coś z tym zrobić … proszę :), zróbcie coś – oryginał jest tutaj).

Tematem jest używanie obiektów podsieci catch-all w topologii usługi katalogowej AD. Zacznijmy więc od ustalenia o czym będziemy mówić.

 

(cc) f-l-e-x

O co chodzi …

Obiekty podsieci są to obiekty definiowane w ramach struktury fizycznej katalogu Active Directory i mają one duże znaczenie dla przebiegu procesu logowania użytkownika, a dokładniej odszukania odpowiedniego kontrolera domeny dla lokalizacji klienta.

W chwili gdy komputer kliencki próbuje zlokalizować kontroler domeny najbardziej odpowiedniego dla lokalizacij sieciowej stacji roboczej wysyła on w ramach początkowych informacji również informację o swojej podsieci. Na podstawie tych informacji, kontroler domeny który wykonuje początkową część procesu lokalizacji DC wraz z klientem jest w stanie określić jego lokację AD (site) i przekierować klienta do opowiedniego dla niego kontrolera(ów) domeny (proces ten dobrze opisał Jorge w swojej serii artykułów– I, II, III). 

Jeżeli na podstawie informacji o podsieci klienta będzie możliwe przypisanie go do odpowiedniej lokacji AD klient będzie mógł następnie wykorzystać tą informację do wykonania zapytań DNS, które powinny w rezultacie pozwolić na określenie odpowiedniego kontrolera domeny. Przypisanie podsieci klienta do odpowiedniej lokacji odbywa się właśnie na podstawie obiektów podsieci zdefiniowanych na poziomie katalogu.

Wszystko pięknie … ale co gdy dla podsieci klienta nie zostanie zdefiniowany odpowiedni obiekt w katalogu i nie będzie możliwe określenie jego lokacji w ten sposób? W takiej sytuacji klient wybierze jeden z dostępnych kontrolerów domeny (definicje dostępności w tym kontekście wyjaśnimy za chwilę) i z niego będzie korzystał do dalszej pracy. Niby wszystko dobrze jednak problem polega na tym, że wybrany DC może nie być najbardziej optymalnym wyborem – może na przykład znajdować się w lokalizacj zdalnej gdzieś w odległym biurze z kiepski łączem.

I co możemy z tym fantem zrobić … na przykład stworzyć podsieć (lub wiele), które będą swoim zakresem pokrywały podsieci używane w całej naszej sieci, w różnych lokalizacjach i przypisać je do wybranej lokacji w AD. Jeżeli przypniemy naszą “super sieć” do wybranej lokacji AD, każdy klient który nie określi poprawnie swojej lokacji zostanie przez nią “złapany” i skorzysta z DC w tej lokacji. W najgorszym razie nie będzie to DC optymalny, ale wybrany przez nas … brzmi dobrze, prawdaż?

W czym problem …

W zasadzie wszystko jest OK ale czy tego samego nie można skonfigurować prościej lub inaczej? W zasadzie można – pisałem o tym w jednym z moich postów “I trzymał sie będę lokacji swojej”. W skrócie – poprzez odpowiednią konfigurację rejestrowanych rekordów DNS możemy kontrolować, z których DC skorzysta klient, który nie jest w stanie określić swojej lokacji w poprawny sposób. Wynika to z faktu, że każdy z DC utrzymuje dwa typu rekordów SRV – specyficzne dla lokacji oraz dla domeny. Jeżeli klient nie jest w stanie określić własnej lokacji skorzysta on z jednego z DC, który zarejestrował rekordy dla domeny (i to oznacza dostępnośc w tym kontekście).

I to wszystko … w niektórych aspektach to rozwiązanie jest według mnie lepsze niż tworzenie obiektów podsieci “catch all”. Może to tylko osobiste preferencje ale takie podejście jest łatwiejsze w zarządzaniu i kontroli w przypadku rozwiązywania problemów z lokalizacją klientów. Końcowy wybór należy jednak do Was … 🙂

Kiedy to podejście może być korzystne …

Są jednak scenariusze, w których podejście oparte na tworzeniu obiektów podsieci “catch all” może być korzystne. Wyobrażmy sobie topologię, która nie podąża dokładnie schematem hub-n-spoke ale jest to na przykład topologia którą określa się jako snow flake". W takim wypadku, oprócz centralnej lokalizacji (hub) mamy dwie lub więcej warstw lokalizacji zdalnych.

 

 

Jeżeli chcielibyśmy skoncentrować ruch z podsieci znajdujących się na 3’ej warstwie w lokacjach na warstwie drugiej nie możemy tego dokonać przez rejestrację rekordów DNS. Możemy jednak przypisać do lokacji na warstwie drugiej odpowiednie “super sieci”, które pozwolą na obsługę wszystkich klientów z lokalizacji zdalnych na warstawie trzeciej. Sytuację taką przedstawia poniższy rysunek.

 

 

 

Takie samo podejście możemy zastosować w przypadku topologii z więcej niż jedną lokalizacją centralną (na przykład 2 data center pełniące role hub).

Oczywiście w takich wypadkach warto również zadbać o odpowiednią konfiguracje DNS :).

I to w zasadzie wszystko …

… z chęcią poznam Waszą opinię na temat stosowania takich podsieci? Czy z nich korzystacie? Czy widzicie w nich korzyści dla swojej topologii?  Komentarze są otwarte … e-mail również :).

3 Comments

Leave a Reply