Virtual Network Name

Virtual Network Name to nazwa sieciowa klastra, pod którą klienci łączą się niezależnie od tego, który węzeł jest aktywny.

Virtual Network Name jako punkt dostępu do klastra

Virtual Network Name, w skrócie VNN, to logiczna nazwa sieciowa przypisana do klastra lub jednej z jego ról. Klient korzysta z tej nazwy zamiast wskazywać bezpośrednio konkretny węzeł. Dzięki temu aplikacja, usługa albo użytkownik odwołuje się do stałego punktu dostępu, nawet gdy obsługa żądania zostanie przeniesiona z jednego węzła na inny. Nazwa nie oznacza dodatkowej fizycznej karty sieciowej ani osobnego komputera. Jest zasobem logicznym utrzymywanym przez oprogramowanie klastrowe.

W środowisku Windows Server Failover Clustering VNN jest zwykle reprezentowany jako zasób nazwy sieciowej, często określany jako Network Name resource. Może występować jako nazwa samego klastra albo jako nazwa konkretnej roli klastrowej, na przykład usługi udostępnianej przez klaster. Zależnie od konfiguracji z nazwą powiązany jest jeden lub więcej zasobów adresu IP. Ten zestaw tworzy Client Access Point, czyli punkt, przez który klienci lokalizują daną rolę w sieci.

Powiązanie nazwy z adresem IP i DNS

Żeby VNN był użyteczny, jego nazwa musi zostać rozpoznana przez DNS. Klient najpierw wykonuje rozpoznanie nazwy na adres IP, a następnie próbuje nawiązać połączenie z usługą działającą pod tym punktem dostępu. W środowisku z jednym adresem IPv4 odpowiedź DNS może wskazywać właśnie ten adres. W konfiguracjach obsługujących IPv6 może być używany także adres IPv6, o ile sieć, system operacyjny i aplikacja są skonfigurowane do pracy z tym protokołem.

Sam wpis DNS nie zapewnia jednak poprawnego działania klastra. Zasób VNN musi być uruchomiony na węźle, który aktualnie posiada daną rolę, a przypisany adres IP musi być osiągalny w odpowiedniej sieci. W zależności od konfiguracji rekord DNS może być tworzony, aktualizowany lub usuwany przez mechanizm klastra i konto komputera klastra w usłudze Active Directory Domain Services. Uprawnienia do rejestracji nazwy, stan DNS, dostępność kontrolera domeny oraz poprawność delegowania uprawnień mogą więc wpływać na to, czy nazwa zostanie opublikowana prawidłowo.

Problemy z VNN często wyglądają jak awaria samej aplikacji, chociaż przyczyna znajduje się w warstwie rozpoznawania nazwy. Przykładem jest sytuacja, w której usługa działa na aktywnym węźle, ale klient otrzymuje błąd rozpoznania DNS albo stary adres zapisany w pamięci podręcznej. Podczas analizy należy rozdzielić kilka testów: sprawdzenie, jaki adres zwraca DNS, weryfikację osiągalności tego adresu oraz potwierdzenie, że właściwa rola klastrowa rzeczywiście działa pod daną nazwą.

Zachowanie VNN podczas przełączania roli

Najważniejszą funkcją VNN jest zachowanie stałego adresu logicznego podczas zmiany właściciela roli. Jeżeli aktywny węzeł przestanie działać albo administrator uruchomi kontrolowane przełączenie, klaster może przenieść rolę na inny węzeł. Nowy właściciel uruchamia wymagane zasoby, w tym nazwę sieciową i adres IP, a następnie udostępnia usługę pod tym samym punktem dostępu. Z perspektywy klienta nazwa pozostaje taka sama, choć wewnętrzna lokalizacja obsługi zmienia się.

Przełączenie nie gwarantuje zachowania wszystkich istniejących połączeń. Sesja TCP może zostać przerwana, jeżeli była związana z poprzednim węzłem, a aplikacja może wymagać ponownego połączenia. To, czy użytkownik zauważy przerwę, zależy od rodzaju usługi, sposobu przechowywania stanu sesji, mechanizmu ponawiania połączeń i czasu potrzebnego na uruchomienie zasobów na nowym węźle. VNN zapewnia stabilny sposób odnalezienia usługi, ale nie zastępuje mechanizmów wysokiej dostępności właściwych dla konkretnej aplikacji.

Na działanie nazwy wpływają również zależności między zasobami. Nazwa sieciowa może wymagać dostępnego adresu IP, a rola aplikacyjna może wymagać uruchomionej nazwy i innych zasobów. Jeśli jeden z wymaganych elementów pozostaje w stanie offline, sama obecność rekordu DNS nie oznacza, że usługa będzie odpowiadała. W praktyce ocenia się więc jednocześnie stan grupy klastrowej, właściciela roli, zasobów adresowych, zasobu nazwy oraz dzienników zdarzeń systemu i klastra.

Rozpoznawanie usterek związanych z Virtual Network Name

Diagnostykę rozpoczyna się od ustalenia zakresu problemu. Jeżeli nazwa VNN nie jest rozpoznawana, należy sprawdzić konfigurację DNS i odpowiedzi otrzymywane przez stację kliencką. Jeżeli nazwa jest rozpoznawana, ale połączenie nie dochodzi do skutku, trzeba zbadać routing, zaporę sieciową, nasłuchiwanie usługi oraz stan adresu IP przypisanego do roli. Jeżeli problem pojawia się dopiero po przełączeniu, istotne są informacje o czasie failover, właścicielu grupy i stanie zależności.

Ważne jest odróżnienie nazwy klastra od nazwy roli. Nazwa klastra służy do identyfikacji określonego obiektu klastrowego, natomiast nazwa roli może być punktem dostępu do konkretnej usługi. Podanie klientowi niewłaściwej nazwy może prowadzić do połączenia z innym zasobem niż oczekiwany albo do braku usługi pod wskazanym adresem. Przydatne jest również sprawdzenie, czy w DNS nie pozostały nieaktualne rekordy, czy adres nie został przypisany do innej maszyny oraz czy czas życia rekordu nie powoduje zbyt długiego przechowywania starej odpowiedzi w pamięci podręcznej.

Virtual Network Name dotyczy infrastruktury klastrowej i zastosowań serwerowych, dlatego jego analiza wymaga dostępu do konfiguracji klastra, DNS, dzienników zdarzeń oraz zależności zasobów. Błędna zmiana nazwy, adresu lub uprawnień może spowodować niedostępność całej roli, dlatego modyfikacje powinny być wykonywane po zapisaniu aktualnej konfiguracji i ustaleniu, który element faktycznie powoduje problem. W przypadku niejednoznacznych objawów rozdzielenie warstwy DNS, sieci, mechanizmu klastra i samej aplikacji pozwala uniknąć przypisywania jednej przyczynie wszystkich błędów.