Azure Virtual Desktop Hybrid dla lokalnego VDI

Wprowadzenie

Azure Virtual Desktop Hybrid daje organizacjom kolejną ścieżkę między tradycyjnym VDI na miejscu a w pełni hostowanymi w Azure pulpitami. Artykuł ten wyjaśnia, jak działa architektura, jak Azure Arc łączy lokalne hosty sesji z AVD, jakie zmiany zachodzą w istniejącej infrastrukturze VDI oraz jakie ograniczenia pozostają. Zawiera również analizę, kiedy Hybrid AVD ma sens i co zespoły IT powinny ocenić przed jego wdrożeniem.

Czym jest hybrydowy Azure Virtual Desktop?

Azure Virtual Desktop Hybrid to model wdrożenia, w którym usługa Azure Virtual Desktop jest nadal hostowana i zarządzana przez Microsoft w Azure, ale hosty sesji Windows dostarczające pulpity i aplikacje znajdują się lokalnie.

Microsoft używa Azure Arc do nawiązywania łączności między środowiskami. Wszystkie wspierane lokalne komputery będą serwerami z obsługą Azure Arc. Następnie rozszerzenie Azure Virtual Desktop Arc instaluje wymagane komponenty AVD i rejestruje ten komputer jako host sesji w puli hostów AVD.

Wszystko jest mniej więcej takie samo dla końcowego użytkownika, jakby korzystali z AVD hostowanego w Azure. Użytkownicy uzyskują dostęp do przypisanych pulpitów lub aplikacji za pośrednictwem aplikacji Windows. Jednak różnica polega na tym, że obciążenie Windows będzie dostarczane z infrastruktury klienta, a nie z obliczeń Azure.

Więc istnieje separacja infrastruktury, gdzie:

Komponent	Gdzie działa	Kto tym zarządza
Usługa AVD i pośrednictwo	Azure	Microsoft
Pule hostów, grupy aplikacji i przypisania	Azure	Klient je konfiguruje
Gospodarze sesji Windows	Na miejscu	Klient
Hypervisor lub infrastruktura fizyczna	Na miejscu	Klient
System operacyjny i aplikacje hosta sesji	Na miejscu	Klient
Lokalne sieci i przechowywanie	Na miejscu	Klient
Integracja Azure Arc	Azure + lokalnie	Wspólna zależność

Główna konkluzja jest taka, że "hybrydowy" to opis rozkładu odrębnych elementów w architekturze VDI. Azure Virtual Desktop sam w sobie nigdy nie stał się w pełni lokalnym rozwiązaniem.

Jak działa hybrydowy Azure Virtual Desktop?

Architektura zaczyna się od maszyn, które dostarczają pulpity lub aplikacje. Organizacje zapewniają wspierane wirtualne maszyny Windows lub wspierane bezgłowe urządzenia fizyczne na własnej infrastrukturze.

Agent Azure Connected Machine rejestruje każdy host sesji w Azure Arc. Rozszerzenie Azure Virtual Desktop Arc może następnie zainstalować wymagane komponenty AVD i zarejestrować maszynę w puli hostów AVD.

Azure Arc nie zapewnia ani nie zarządza podstawową maszyną wirtualną. Host sesji jest częścią lokalnej infrastruktury organizacji, co oznacza, że zespół IT organizacji jest odpowiedzialny za cykl życia hosta sesji, jego pojemność oraz podstawową platformę wirtualizacji.

Kiedy użytkownik się łączy, Azure Virtual Desktop zapewnia możliwości po stronie usługi do odkrywania zasobów, uwierzytelniania dostępu i mediacji sesji. Rzeczywiste obciążenie systemu Windows działa na lokalnym hoście sesji.

Ta architektura oddziela usługę AVD od hostów sesji, różnicując Hybrid AVD od obu. tradycyjny VDI na miejscu i standardowy AVD hostowany w chmurze: Microsoft zarządza usługą chmurową, ale klient nadal obsługuje infrastrukturę obliczeniową.

Jak hybrydowy AVD zmienia istniejące środowisko VDI w siedzibie?

Dla istniejących środowisk VDI wyzwaniem nie jest tylko to, czy obecne serwery mogą być zachowane w centrum danych, ale które warstwy istniejącej architektury zostały zachowane, które AVD zostały zastąpione i które obowiązki operacyjne zostały zachowane przez organizację.

Istniejące komputery mogą pozostać na miejscu.

W przeciwieństwie do pełnej migracji Azure AVD, w której obliczenia hosta sesji przenoszą się do Azure, to nie wymaga żadnych zmian w istniejących hostach sesji w centrum danych.

Organizacje mogą skorzystać z obsługiwanych wirtualnych maszyn Windows na swoim preferowanym hypervisorze w swoich lokalnych centrach danych. Może to być przydatne w przypadkach, gdy istnieje znaczna infrastruktura wirtualizacji lub aplikacje są w dużym stopniu uzależnione od istniejących systemów lokalnych.

Obecność istniejącego sprzętu nie oznacza, że środowisko VDI pozostaje niezmienione. Gospodarze sesji muszą być dostosowani do specyfikacje Microsoftu i zarejestrowani jako obsługiwani przez Azure Arc, zanim będą mogli być używani z Azure Virtual Hybrid Desktop.

Kontrolny plane VDI przenosi się do Azure

Najważniejsze różnice architektoniczne pojawiają się powyżej hostów sesji.

Zamiast obsługiwać pełny stos dostarczania pulpitu wewnętrznie, organizacja korzysta z platformy Azure Virtual Desktop. Microsoft udostępnia podstawowe komponenty usługi do odkrywania zasobów, pośrednictwa i łączności bramowej.

Organizacje zachowują odpowiedzialność za konfigurowanie pul hostów, grup aplikacji, przestrzeni roboczych i uprawnień użytkowników, ale te zasoby są teraz częścią architektury AVD. Wcześniejsze lokalne brokerzy, bramy i komponenty zarządzające mogą już nie musieć pełnić tych samych funkcji.

Zarządzanie lokalną infrastrukturą pozostaje

Przeniesienie warstwy usługowej do Azure nie sprawia, że infrastruktura wspierająca jest zarządzana przez Microsoft.

Zespoły IT zachowują odpowiedzialność za dostarczanie, łatanie i utrzymywanie lokalnego sprzętu, systemów operacyjnych, aplikacji, sieci, pamięci masowej oraz podstawowej platformy wirtualizacji. Microsoft wyraźnie dokumentuje, że Azure Virtual Desktop Hybrid nie dostarcza lokalnych maszyn wirtualnych hostów sesji ani nie zarządza ich stanem zasilania.

Hybrid AVD powinno być rozumiane jako redystrybucja odpowiedzialności VDI, a nie jako przekazanie całego stosu rozwiązań do Microsoft.

W jakim przypadku ma sens utrzymywanie hostów sesji AVD na miejscu?

Jeśli Azure już oferuje usługę AVD, umieszczenie tego hosta sesji w Azure może wydawać się najłatwiejszą drogą. Hybryda wchodzi w grę, gdy istnieje techniczne, kosztowe lub operacyjne uzasadnienie dla utrzymania obciążeń w centrum danych.

Aplikacje dziedziczone i lokalne zależności

Aplikacje, które są wirtualizowane, to często aplikacje Windows, które w dużym stopniu polegają na lokalnych bazach danych, udostępnianiu plików, usługach uwierzytelniania, urządzeniach peryferyjnych lub innych systemach zaplecza.

Nie zyskujesz wiele, umieszczając hosta sesji w Azure, ale pozostawiając zależności aplikacji w siedzibie, ponieważ tylko dodasz opóźnienie sieciowe do mieszanki. Pozostanie blisko zaplecza unika konieczności rozrywania architektury aplikacji tylko po to, aby zmienić miejsce, z którego łączą się użytkownicy końcowi.

To prawda w szczególności w odniesieniu do dziedziczne aplikacje biznesowe które zostały zaprojektowane do pracy w lokalnej sieci komputerowej.

Wymagania dotyczące lokalizacji danych i infrastruktury

Niektóre firmy potrzebują, aby określone obciążenia lub dane znajdowały się na infrastrukturze pod ich kontrolą z powodów regulacyjnych, umownych lub operacyjnych.

Hybrid AVD pozwala na lokalne przetwarzanie pulpitu i aplikacji, jednocześnie wykorzystując Azure do usługi dostarczania pulpitu. Zespoły IT powinny jednak dokładnie przeanalizować tę opcję architektoniczną w kontekście swoich wymagań dotyczących zgodności, ponieważ model hybrydowy nadal opiera się na Microsoft Azure.

Istniejąca inwestycja w centrum danych

Organizacje z dostępną wolną pojemnością w serwerach, pamięci masowej i zasobach wirtualizacji mogą nie mieć natychmiastowej zachęty do wprowadzenia zmian.

Hybrid AVD może umożliwić takim firmom pozyskiwanie nowej mocy obliczeniowej w falach, gdzie istniejące zasoby obliczeniowe nadal obsługują obciążenia, podczas gdy płaszczyzna kontrolna jest przekształcana wokół niej. Architektura ta sprzyja również iteracyjnej modernizacji, ponieważ różne obciążenia mogą być migrowane w różnym tempie.

Obciążenia wrażliwe na opóźnienia w zapleczu

Dla niektórych aplikacji bliskość hosta sesji do zasobów, które konsumuje, jest ważniejsza niż bliskość hosta sesji do użytkownika końcowego.

Aplikacje, które często wykonują wywołania do lokalnych baz danych, systemów przechowywania lub innej infrastruktury, mogą nie działać tak dobrze, jeśli te zależności są rozproszone w sieci WAN. Utrzymując sesję Windows lokalnie, można zachować bliskość do tych zasobów.

Kiedy Hybrydowe AVD może nie być odpowiednim rozwiązaniem

Wartość utrzymywania hostów sesji na miejscu jest zmniejszona, jeśli celem organizacji jest eliminacja infrastruktury centrum danych, a nie jej utrzymanie. W takim scenariuszu użycie AVD hostowanego w Azure może lepiej pasować do pożądanego modelu operacyjnego.

Zespoły IT powinny również rozważyć, czy w ogóle potrzebują modelu usługi Azure Virtual Desktop. Jeśli głównym wymaganiem jest bezpieczne publikowanie scentralizowanych aplikacji lub pulpitów systemu Windows zachowując bezpośrednią kontrolę nad infrastrukturą, zależny od Azure system kontroli VDI może wprowadzić niepotrzebną złożoność architektoniczną.

Czy Hybrid AVD eliminuje VPN-y i bramy RD?

Azure Virtual Desktop eliminuje wiele złożoności związanych z zewnętrzną łącznością, umożliwiając organizacjom unikanie narażania poszczególnych hostów sesji na internet lub wdrażania standardowego bramy pulpitu zdalnego (RD Gateway) dla AVD.

AVD wykorzystuje infrastrukturę usług Microsoftu do łączenia się przez usługę Microsoftu. Domyślny transport korzysta z połączenia zwrotnego opartego na TCP, podczas gdy RDP Shortpath może negocjować transport oparty na UDP, jeśli sieć i konfiguracja to wspierają.

Dla organizacji, które obecnie mają środowisko VDI, które wykorzystuje przychodzące połączenie protokołu pulpitu zdalnego (RDP), a także inne metody, takie jak dostęp VPN lub lokalnie zarządzane bramy RD do remote access to może znacząco zmienić architekturę zewnętrznego dostępu.

Wymagania dotyczące łączności sieciowej nie zostały wyeliminowane. Lokalne hosty sesji nadal muszą łączyć się z odpowiednimi usługami Azure, podczas gdy aplikacje potrzebują niezawodnego dostępu do lokalnych zależności. Rozważania dotyczące łączności, takie jak DNS, tożsamość, konfiguracja zapory, routowanie i odporność, są zatem nadal ważnymi elementami projektowymi.

Jakie są ograniczenia hybrydowego pulpitu zdalnego Azure?

Hybrid AVD oferuje elastyczność wdrożenia, ale istnieją pewne istotne różnice w porównaniu do AVD hostowanego w Azure, które mogą wpływać na architekturę i operacje.

Microsoft obecnie definiuje kilka możliwości zarządzania hostem sesji jako nieobsługiwane dla Hybrid AVD:

• Zarządzanie energią
• Autoskalowanie Azure Virtual Desktop
• Uruchom VM po połączeniu
• Konfiguracja hosta sesji

Przedsiębiorstwa byłyby odpowiedzialne za zapewnienie tych możliwości za pośrednictwem swojego hypervisora, skryptów, automatyzacji lub innych narzędzi.

Dodatkowo wsparcie dla systemu operacyjnego jest inne, ponieważ nie ma wsparcia dla Azure Virtual Desktop Hybrid z systemem Windows 10 Enterprise w trybie wielosesyjnym i Windows 11 Enterprise w trybie wielosesyjnym. To istotna różnica, ponieważ systemy operacyjne klientów Windows w trybie wielosesyjnym są kluczową cechą hostowanego AVD w Azure.

Wymagania licencyjne powinny być również dokładnie przeglądane, biorąc pod uwagę zamierzony system operacyjny i przypadek użycia. Należy potwierdzić, czy wymagania dotyczące licencjonowania hybrydowego Microsoft Azure Virtual Desktop mają zastosowanie poza istniejącymi licencjami VDI, usługami pulpitu zdalnego lub licencjami Microsoft 365.

Ostatecznie posiadanie lokalnych hostów sesji nie czyni wdrożenia AVD niezależnym od chmury, ponieważ zarządzana przez Microsoft usługa Azure Virtual Desktop nadal stanowi integralną część architektury.

Azure-Hosted AVD vs Hybrydowe AVD vs Tradycyjne VDI na miejscu

Ostateczna wersja zdania (przepisana, z użyciem innych słów, z niektórymi zdaniami zmienionymi w strukturze lub długości):

	Tradycyjny VDI na miejscu	Azure Virtual Desktop Hybrid	Azure-Hosted AVD
Hosty sesji	Na miejscu	Na miejscu	Azure
usługa VDI/panel sterowania	Zwykle infrastruktura klienta/dostawcy	Microsoft AVD w Azure	Microsoft AVD w Azure
Wymagany lokalny hipernadzorca	Zazwyczaj tak	Tak dla hostów opartych na VM	Nie
Zarządzanie lokalnym obliczeniem	Klient	Klient	Nie dotyczy lokalnego obliczenia
Funkcje cyklu życia natywnej maszyny wirtualnej AVD	Nie	Ograniczony	Szersze wsparcie
Bliskość do lokalnych aplikacji	Wysoki	Wysoki	Zależy od projektu sieciowego
zależność Azure	Zależny od produktu	Tak	Tak
Zużycie obliczeniowe Azure	Nie	Nie dla lokalnych hostów sesji	Tak

Zatem hybrydowe AVD ma architekturę pośrednią, w której obciążenia są dostarczane z chmury (zarządzanej przez Microsoft), ale lokalne obliczenia są zarządzane przez klienta.

Taki wybór architektoniczny jest uzasadniony tylko wtedy, gdy istnieje korzyść z utrzymania obciążeń lokalnie.

Jak zespoły IT powinny ocenić przejście na hybrydowe AVD?

Ocena hybrydowego AVD powinna zaczynać się nie od Azure, ale od obciążeń i zależności.

Zidentyfikuj, które aplikacje i pulpity muszą być utrzymywane na miejscu, oraz udokumentuj ich zależności od baz danych, usług plikowych, systemów tożsamości, urządzeń peryferyjnych, pamięci masowej i innej infrastruktury. Umożliwia to ustalenie, czy utrzymywanie hostów sesji na miejscu ma jakiekolwiek zasługi architektoniczne.

Aktualny stan stosu VDI powinien być odwzorowany na modelu AVD. Które brokerzy, bramy i usługi zarządzania zostaną zastąpione przez Azure Virtual Desktop? Jakie obowiązki operacyjne pozostaną?

Zarządzanie cyklem życia hosta sesji jest kluczowym zagadnieniem. Jeśli istniejąca platforma VDI obejmuje automatyczne dostarczanie, uruchamianie/zatrzymywanie lub skalowanie maszyn wirtualnych, oceń, czy te możliwości są dostępne w Hybrid AVD, zamiast zakładać, że kontrola Azure je zastąpi.

Tożsamość, sieci, licencjonowanie, odporność i odpowiedzialności operacyjne powinny być oceniane jako grupa. Celem jest nie tylko ustalenie, czy istniejące maszyny mogą być zarejestrowane w Azure Virtual Desktop, ale także czy oddzielenie infrastruktury VDI między Azure a centrum danych stworzy prostsze i bardziej zrównoważone środowisko.

Szukasz prostszego sposobu na dostarczanie aplikacji i pulpitów systemu Windows?

Hybrid AVD może mieć sens, gdy organizacja szczególnie chce korzystać z Azure Virtual Desktop, jednocześnie utrzymując hosty sesji w siedzibie. Jednak nie każda organizacja musi dzielić swoją architekturę dostarczania pulpitu między usługę zarządzaną przez Azure a lokalnie zarządzane obliczenia.

Gdzie wymagane jest przede wszystkim bezpieczne publikowanie aplikacji Windows lub pełnych pulpitów z istniejącej infrastruktury Windows, TSplus Zdalny Dostęp oferuje bardziej bezpośrednią alternatywę. Organizacje mogą dostarczać aplikacje i pulpity za pomocą dostępu zgodnego z RDP lub opartego na przeglądarce dostępu HTML5, jednocześnie zachowując kontrolę nad tym, gdzie działa wspierająca infrastruktura.

Wniosek

Azure Virtual Desktop Hybrid zapewnia kompromis między tradycyjnym VDI na miejscu a AVD hostowanym w Azure. Przenosi kluczowe usługi dostarczania pulpitu do Azure, jednocześnie pozwalając hostom sesji Windows i ich obciążeniom pozostać w istniejącej infrastrukturze.

Decydującym czynnikiem jest to, czy utrzymanie tych obciążeń lokalnie przynosi wyraźne korzyści techniczne lub operacyjne. Zespoły IT powinny ocenić zależności aplikacji, zarządzanie infrastrukturą, sieci, licencjonowanie oraz zależność od Azure razem, zanim zdecydują, czy Hybrid AVD rzeczywiście upraszcza ich środowisko VDI.