Wykorzystanie Microsoft RDS na Scale HC3

Jedną z wielkich zalet scentralizowanej i ujednoliconej platformy infrastrukturalnej, jaką jest Scale HC3, jest możliwość korzystania z platformy w celu świadczenia scentralizowanych usług desktopowych i dla użytkowników końcowych obok tradycyjnych usług serwerowych. Szybki backplane pozwala zasobom serwerowym i desktopowym komunikować się z dużą prędkością, a scentralizowane zarządzanie obniża całkowity koszt posiadania często kojarzony z tego rodzaju usługami. Aplikacje takie jak udostępnianie plików i komunikacja wrażliwa na opóźnienia szczególnie korzystają z tej architektury.

Dla większości firm podejście, które będzie miało największy sens przy dodawaniu zdalnych usług obliczeniowych dla użytkowników końcowych do ich środowiska, będzie opierało się na zastosowaniu własnych serwerów Remote Desktop Servers (RDS) Microsoft, ponieważ większość środowisk dąży do zapewnienia doświadczenia podobnego do tradycyjnego pulpitu Windows. Microsoft RDS to potężny zestaw narzędzi, stosunkowo łatwy do wdrożenia. Jest to doskonały punkt wyjścia do oferowania szerokiego zakresu usług.

Ze względu na wysoką dostępność platformy Scale HC3 mamy dobre możliwości w zakresie planowania i przygotowywania wdrożenia RDS. Możemy zdecydować się na utrzymanie małego i prostego wdrożenia oraz wykorzystanie wbudowanych funkcji wysokiej dostępności klastra Scale HC3 do utrzymania naszego środowiska w przypadku awarii sprzętu, lub możemy skorzystać z wysokiej dostępności ze środowiska RDS.

W przypadku małego wdrożenia najczęściej stosuje się funkcje wysokiej dostępności Scale HC3 w celu utrzymania dostępności usług RDS. Pozwala to na uruchomienie jednej instancji RDS przy minimalnym narzucie związanym z licencjonowaniem, zasobami i konserwacją. Jest to najprostsze podejście i jest bardzo skuteczne. To doskonały sposób dla większości klientów na jak najlepsze wykorzystanie platformy Scale HC3. Scale może w tym przypadku wykonać ciężką pracę, a my możemy skupić nasze wysiłki tam, gdzie są bardziej efektywne.

W dużych wdrożeniach posiadanie jednej instancji RDS może być niewystarczające. W tym momencie generalnie uzasadnione byłoby przejście do wdrożenia RDS na wielu serwerach z obciążeniami rozłożonymi na instancje za pomocą load balancingu. Zazwyczaj pożądane byłoby wdrożenie nie więcej niż jednego serwera RDS na węzeł Scale HC3, aby jak najlepiej wykorzystać dostępne zasoby. W ten sposób można wdrożyć tyle instancji serwera RDS, ile potrzeba do obsługi pojemności środowiska.

W większości przypadków, nawet przy większym wdrożeniu obejmującym wiele węzłów, używalibyśmy load balancera przed farmą RDS, ale nadal korzystalibyśmy z wbudowanych funkcji wysokiej dostępności klastra Scale HC3 do obsługi awarii sprzętu poprzez przenoszenie uruchomionych obciążeń z awaryjnego węzła do dostępnego węzła. Load balancer widziałby tę samą instancję z tym samym adresem IP, co pozwala na niemal transparentne odtwarzanie, które jest w pełni zautomatyzowane i wymaga minimalnego wysiłku.

W bardziej ekstremalnych przypadkach, gdy wymagana jest pełna pojemność klastra, możliwe jest skonfigurowanie jednej instancji RDS na fizyczny węzeł klastra i wyłączenie funkcji wysokiej dostępności, z wykorzystaniem zamiast nich funkcji load balancingu do przenoszenia obciążenia na pozostałe węzły. Skutkowałoby to stopniową utratą wydajności zamiast awarii. O ile zasoby nie byłyby już bardzo mocno ograniczone, przydzielony użytkownikom CPU i pamięć zmalałyby, ale funkcjonalność systemu zostałaby zachowana. Nie jest to tak idealne rozwiązanie jak pełna wysoka dostępność, ale może być bardzo funkcjonalną alternatywą dla kosztu sprzętu na tym poziomie ochrony.

Microsoft Windows RDS i Scale to oczywiste partnerstwo. Scale koncentruje się na tym, aby platforma była jak najłatwiejsza i jak najbardziej niezawodna, podczas gdy produkt Windows i RDS Microsoft zapewnia nam najprostszy punkt wejścia w przestrzeń współdzielonego przetwarzania. Dla małych i średnich firm, a szczególnie w przypadku wdrożeń on-premises, RDS jest często idealnym wyborem do przejścia na scentralizowane przetwarzanie oparte na cienkich klientach i może być kluczowym czynnikiem umożliwiającym mobilność pracowników, bezpieczeństwo, a nawet opcje BYOD (bring your own device).

[This piece was commissioned for the Scale Blog.]