Odporność aplikacji: Utrzymuj dostępność aplikacji Windows

Wprowadzenie

Aplikacje Windows często zależą od znacznie więcej niż serwer, który je hostuje. Bazy danych, usługi tożsamości, przechowywanie, bramy, sieci i punkty końcowe użytkowników mogą wpływać na to, czy aplikacja pozostaje użyteczna podczas zakłóceń. Artykuł ten wyjaśnia, jak zespoły IT mogą ocenić te zależności, zaprojektować odporność wokół istniejących aplikacji Windows, monitorować odpowiednie warstwy i testować, czy plany odzyskiwania rzeczywiście zachowują funkcje biznesowe, na których polegają użytkownicy.

Czym jest odporność aplikacji?

Odporność aplikacji to zdolność aplikacji oraz infrastruktury wokół niej do kontynuowania świadczenia istotnych funkcji podczas zakłócenia oraz do przewidywalnego odzyskiwania po awarii.

Zakłócenie może być małe lub duże, a przyczyny mogą się różnić od awarii sprzętu lub systemu operacyjnego, awarii aplikacji, nieudanych aktualizacji, przerw w działaniu bazy danych, przerw w sieci, niepowodzeń w uwierzytelnianiu, wyczerpania zasobów, niedostępnych zależności lub incydentów bezpieczeństwa.

Odporna architektura uznaje, że awarie są nieuniknione, a zamiast dążyć do zapobiegania każdemu incydentowi, organizacje IT starają się ograniczyć wpływ każdego z nich i ustanowić kontrolowane procedury odzyskiwania, aby utrzymać lub przywrócić usługę.

Odporność aplikacji to więcej niż czas pracy serwera

Powszechnym błędem jest używanie dostępności serwera jako wskaźnika dostępności aplikacji, która działa na serwerze.

Aby aplikacja biznesowa była naprawdę dostępna, szereg komponentów musi być dostępnych jednocześnie:

Infrastruktura → System operacyjny → Aplikacja → Zależności → Ścieżka dostępu → Sesja użytkownika → Proces biznesowy

Problem z jakimkolwiek elementem w tym łańcuchu może spowodować, że aplikacja stanie się praktycznie niedostępna.

Na przykład serwer aplikacji może być sprawny, podczas gdy jego baza danych jest niedostępna. Opublikowana aplikacja może działać poprawnie, ale awaria bramy uniemożliwia zdalnym pracownikom dostęp do niej. Użytkownicy mogą nawet pomyślnie uruchomić aplikację, ale mogą być uniemożliwieni w zakończeniu transakcji, ponieważ licencja, plik lub usługa zaplecza są niedostępne.

Odporność aplikacji powinna być mierzona na podstawie zdolności użytkownika do wykonania niezbędnego zadania biznesowego, a nie na podstawie tego, czy serwer jest w stanie odpowiedzieć na kontrolę dostępności lub stanu.

Dlaczego odporność aplikacji jest inna dla aplikacji Windows?

Nowoczesne praktyki odporności coraz bardziej koncentrują się na aplikacjach natywnych w chmurze, kontenerach, mikroserwisach i zautomatyzowanej orkiestracji. Chociaż są to cenne podejścia, nie zawsze są one stosowane w każdej organizacji.

Wiele organizacji ma starsze aplikacje biznesowe Windows, które zostały opracowane przed tym, jak architektury natywne w chmurze stały się powszechne. Oprogramowanie ERP, aplikacje księgowe, aplikacje produkcyjne, aplikacje zdrowotne, aplikacje inżynieryjne oraz aplikacje opracowane wewnętrznie mogą być kluczowe dla działalności organizacji.

Przekształcenie tych aplikacji w mikroserwisy może być niezwykle kosztowne, technicznie trudne lub wręcz całkowicie niemożliwe, jeśli organizacja nie kontroluje kodu źródłowego.

W takich przypadkach może być istotna wartość w uczynieniu operacji wokół aplikacji bardziej odpornymi, zamiast próbować uczynić samą aplikację bardziej odporną. Publikacja aplikacji może być częścią tego podejścia, utrzymując istniejące aplikacje Windows na scentralizowanej infrastrukturze, jednocześnie zmieniając sposób, w jaki użytkownicy uzyskują do nich dostęp. Może to obejmować zmiany w infrastrukturze hostującej aplikację, takie jak eliminacja ograniczeń infrastrukturalnych, tworzenie redundantnych hostów aplikacji, umożliwienie alternatywnych metod dostępu oraz wdrażanie bardziej responsywnych procedur odzyskiwania dla hosta aplikacji.

W jakim przypadku dostępność aplikacji Windows może zawieść?

Budowanie odporności aplikacji zaczyna się od odkrywania komponentów, które są potrzebne do pomyślnego dostarczenia aplikacji z ich hostów do użytkowników. Proces ten podkreśla potencjalne punkty awarii, które mogą zablokować całą aplikację.

Hosty aplikacji

Aplikacja działająca na jednym serwerze Windows ma wyraźny pojedynczy punkt awarii.

Problemy sprzętowe, aktualizacje systemu Windows, uszkodzenie systemu operacyjnego, wyczerpanie zasobów lub awaria aplikacji mogą zakłócić pracę każdego użytkownika zależnego od tej maszyny. Jeśli wymagania dotyczące dostępności tego wymagają, można wprowadzić wiele hostów aplikacji, aby zmniejszyć zależność od jednej maszyny i zapewnić pojemność, gdy serwer staje się niedostępny.

Bazy danych, przechowywanie i inne zależności

Wiele aplikacji Windows opiera się na usługach zewnętrznych dla hosta aplikacji. Usługi te mogą obejmować:

• bazy danych SQL
• udostępnianie plików
• serwery licencyjne
• Active Directory
• System Nazw Domen (DNS)
• certyfikaty
• API
• oprogramowanie pośredniczące
• przechowywanie w sieci
• infrastruktura druku

Wprowadzenie drugiego serwera aplikacji zapewnia minimalną odporność, jeśli dzielą one wspólną bazę danych lub zależność od pamięci, która jest niedostępna. Staje się oczywiste, że mapowanie zależności musi wykraczać poza widoczną infrastrukturę aplikacji.

Uwierzytelnianie i tożsamość

Użytkownicy nie mogą uzyskać dostępu do zdrowej aplikacji, jeśli nie ma dostępnej niezbędnej infrastruktury uwierzytelniającej.

Zespoły IT muszą zidentyfikować usługi tożsamości, od których zależą ich krytyczne aplikacje, i upewnić się, że mają plany awaryjne na wypadek, gdy te zasoby będą niedostępne. Active Directory, platformy tożsamości w chmurze, usługi uwierzytelniania wieloskładnikowego (MFA) oraz bramy uwierzytelniające mogą być wykorzystywane do zapewnienia łańcucha dostępności dla aplikacji.

Sieciowe i zdalne ścieżki dostępu

Dla scentralizowanych aplikacji Windows, łączność między użytkownikami a środowiskiem aplikacji stanowi kolejny możliwy obszar awarii.

Wyobraźmy sobie pełny łańcuch:

Urządzenie użytkownika → Internet lub LAN → brama → host aplikacji → usługi backendowe

Awaria w dowolnym miejscu w tym łańcuchu może uniemożliwić użytkownikom wykonywanie ich zadań, nawet jeśli aplikacja działa prawidłowo. Szczególnie istotne dla zdalnych organizacji, w których aplikacja może działać w centrum danych, ale jest niedostępna dla użytkowników w innym miejscu.

Punkty końcowe

Odporność aplikacji niekoniecznie wymaga, aby normalne stanowisko robocze użytkownika było dostępne.

Oferowanie uprawnionym użytkownikom możliwości dostępu do centralnie hostowanych aplikacji z alternatywnego urządzenia lub za pośrednictwem przeglądarki może zapewnić dostęp, jeśli laptop stanie się niedostępny, biuro stanie się niedostępne lub pracownicy będą musieli pracować z innej lokalizacji.

Architektura dostarczania aplikacji może być elementem szerszej strategii ciągłości działania biznesu.

Jaki jest proces budowania odporności aplikacji dla aplikacji Windows?

Żadna pojedyncza technologia nie sprawia, że aplikacja jest odporna. Zespoły IT muszą zamiast tego zmniejszyć liczbę awarii, które mogą całkowicie wyłączyć funkcję, i przygotować się na kontrolowane mechanizmy odzyskiwania dla tych, które pozostają.

1. Zidentyfikuj krytyczne aplikacje i procesy biznesowe

Nie wszystkie aplikacje wymagają tego samego stopnia ochrony. Zacznij od określenia, które aplikacje wspierają podstawowe operacje, na których polegają użytkownicy oraz ich tolerancję na przestoje.

Dwa cele odzyskiwania przekładają wymagania biznesowe na specyfikacje techniczne. wytyczne NIST dotyczące planowania awaryjnego określa Cel Czasu Odzyskiwania (RTO) i Cel Punku Odzyskiwania (RPO) jako kluczowe parametry do określenia wymagań dotyczących odzyskiwania:

• Cel Czasu Odzyskiwania (RTO): czas akceptowalnego przestoju przed przywróceniem usługi.
• Cel punktu odzyskiwania (RPO): interwał akceptowalnej utraty danych, mierzony w czasie.

Aplikacja intensywnie używana do przetwarzania zamówień może mieć RTO wynoszący minuty, podczas gdy aplikacja do raportowania finansowego uruchamiana raz w tygodniu może pozwolić sobie na dni przestoju.

RTO i RPO definiują rodzaj ochrony niezbędnej dla aplikacji: natychmiastowe przełączenie, szybkie przywrócenie usług lub po prostu udokumentowana procedura odzyskiwania.

2. Mapuj całą zależność aplikacji

Dokumentuj wszystko, co musi być obecne, aby aplikacja mogła wykonywać swoją pracę.

Nie zatrzymuj się na pliku wykonywalnym lub serwerze Windows. Nie zapominaj o bazach danych, pamięci masowej, uwierzytelnianiu, DNS, sieciach, certyfikatach, systemach licencjonowania, bramkach i usługach zewnętrznych.

Dla każdego, zapytaj:

Co się stanie z aplikacją, jeśli to zniknie?

To ćwiczenie ujawni ukryte pojedyncze punkty awarii i ustali sekwencję odzyskiwania. Przywrócenie hosta aplikacji jako pierwszego niewiele pomoże, jeśli jego baza danych, usługa tożsamości lub pamięć masowa nie są jeszcze dostępne.

3. Usuń krytyczne pojedyncze punkty awarii

Gdy drzewo zależności jest ustalone, określ, które komponenty mają być zredukowane, na podstawie znaczenia dla biznesu i celów odzyskiwania.

W przypadku dostarczania aplikacji na systemie Windows może to obejmować wdrożenie kilku serwerów aplikacji, zamiast polegać na możliwościach jednego hosta. Dzięki warstwie równoważenia obciążenia sesje mogą być rozkładane na instancje aplikacji podczas normalnej pracy. W przypadku awarii hosta przychodzące połączenia mogą być kierowane do zdrowych instancji serwerów aplikacji.

Planowanie redundancji powinno być oparte na analizie zależności. Wiele serwerów aplikacji uzyskujących dostęp do jednej krytycznej bazy danych, bramy sieciowej lub warstwy pamięci masowej nadal stanowi pojedynczy punkt awarii.

Projekt wysokiej dostępności musi zatem uwzględniać usługę aplikacyjną jako zintegrowany podmiot. W przypadku środowisk Windows Server wymagających redundancji na poziomie infrastruktury, Dokumentacja klastra awaryjnego Microsoftu zapewnia dalsze wskazówki dotyczące topologii wysokiej dostępności i odzyskiwania po awarii.

4. Oddziel aplikacje od poszczególnych punktów końcowych

Instalowanie krytycznej aplikacji bezpośrednio na każdym stanowisku pracy pracownika może stworzyć inny rodzaj problemu z odpornością. Jeśli użytkownicy stracą dostęp do swojego regularnego komputera, mogą również stracić dostęp do aplikacji, których potrzebują, aby kontynuować pracę.

Centralizacja aplikacji na zarządzanych hostach Windows i prezentowanie interfejsu aplikacji użytkownikom eliminuje to ryzyko. Dane i stan aplikacji są przechowywane na zarządzanym hoście Windows i dostępne przez autoryzowane punkty końcowe.

Dzięki temu udostępniamy aplikację użytkownikom, nawet jeśli zmieniają urządzenia lub lokalizacje. Chociaż centralizacja aplikacji nie eliminuje problemów z infrastrukturą, pomaga przenieść ją do środowiska, w którym może być kontrolowana przez IT.

5. Zapewnij więcej niż jedną praktyczną metodę dostępu

Odporność można również osiągnąć, unikając niepotrzebnej zależności od jednego typu punktu końcowego lub metody połączenia.

W zależności od architektury dostarczania aplikacji, użytkownicy mogą korzystać z różnych remote access metody, w tym klient zgodny z RDP, dedykowany uruchamiacz aplikacji, portal internetowy lub sesja przeglądarki HTML5.

Alternatywne metody połączenia nie powinny być mylone z redundancją infrastruktury. Jeśli wszystkie polegają na tym samym uszkodzonym serwerze, aplikacja nadal jest niedostępna.

Zapewniają odporność na dostęp, gdy zakłócenia wpływają na normalne urządzenie użytkownika, zainstalowanego klienta lub lokalizację, a nie na samą usługę aplikacji.

6. Monitoruj, zanim degradacja stanie się awarią

Odporność aplikacji nie polega tylko na odzyskiwaniu, ale wczesne wykrycie może zapobiec degradacji do awarii.

Wskaźniki przydatne w środowiskach aplikacji Windows to wykorzystanie CPU, obciążenie pamięci, pojemność dysku i I/O, wykorzystanie sieci, aktywne sesje, proces aplikacji, czas odpowiedzi, nieudane połączenie oraz dostępność usług zależnych.

Monitorowanie trendów jest kluczowe, ponieważ serwer, który wielokrotnie zbliża się do swoich limitów, może nadal być online, podczas gdy doświadczenie użytkownika stopniowo się pogarsza.

Alerty progowe umożliwiają administratorom badanie prekursorów incydentu, zanim użytkownicy stracą dostęp.

7. Planowanie szczytów pojemności i awarii

Aplikacja, która przetrwa awarie na poziomie sprzętowym, ale jest całkowicie niezdolna do działania w warunkach zwiększonego zapotrzebowania, nie jest naprawdę odporna na awarie jakiegokolwiek rodzaju.

Planowanie pojemności musi uwzględniać nie tylko codzienne wzorce użytkowania, ale także brać pod uwagę szczyty związane z sezonowymi wymaganiami, zmianami zmian, wzrostem lub wymaganiami hostingowymi dla innych aplikacji.

Szczególnie w środowiskach hostingu wieloserwerowego, utrata pojedynczego serwera musi być uwzględniona poprzez zapewnienie, że inne węzły hostingowe mają zapasową pojemność, aby pomieścić wszelkie procesy, które w przeciwnym razie byłyby wykonywane na uszkodzonym węźle.

W przeciwnym razie procedury awaryjne mogą po prostu przekształcić odosobniony incydent w szeroki problem z wydajnością systemu.

8. Chroń dane i konfigurację

Zastępczy serwer Windows jest mało przydatny, jeśli IT nie może przywrócić komponentów potrzebnych do uruchomienia aplikacji.

To może oznaczać, że procedury tworzenia kopii zapasowych muszą obejmować dane aplikacji, bazy danych, pliki konfiguracyjne, certyfikaty, ustawienia aplikacji, profile użytkowników, konfigurację infrastruktury, skrypty oraz informacje o licencjach.

Strategia będzie się różnić w zależności od celu czasu odzyskiwania (RTO) i celu punktu odzyskiwania (RPO) aplikacji.

Przede wszystkim upewnij się, że udane tworzenie kopii zapasowej nie równa się udanemu przywracaniu. Zespoły IT powinny przetestować, czy możliwe jest przywrócenie całej usługi aplikacji z chronionych danych i konfiguracji.

9. Zmniejsz promień wpływu zmian

Nie zawsze jest to przypadek nieprzewidzianej katastrofy, która powoduje zakłócenia. Mogą one również być spowodowane wprowadzonymi ulepszeniami. Dlatego poprawki systemu Windows, aktualizacje aplikacji i sterowników, zmiany polityki bezpieczeństwa i konfiguracji mogą również negatywnie wpłynąć na dostępność aplikacji. Zaleca się unikanie wprowadzania podobnych zmian we wszystkich hostach produkcyjnych jednocześnie, jeśli to możliwe.

W konfiguracji wieloserwerowej możliwe jest wprowadzanie zmian poprawiających w etapach, co pozwala administratorowi upewnić się, że wszystko działa poprawnie. Możliwość cofnięcia wprowadzonych zmian jest również niezbędna.

Zatem, projektując procedury awaryjne, należy również wziąć pod uwagę opcje przywracania. Proces powinien być odpowiednio udokumentowany, a personel powinien wiedzieć, co zrobić, jeśli zmiana się nie powiedzie, zamiast po prostu pozostawiać to ich uznaniu.

10. Projektowanie dla łagodnej degradacji

Odporność nie polega na utrzymywaniu 100% normalnych funkcji w działaniu przez cały czas.

W niektórych przypadkach utrzymanie operacji dla kluczowych użytkowników lub aplikacji może być ważniejsze niż zapewnienie dostępności wszystkich usług dla wszystkich użytkowników. Priorytety mogą być ustalane przed wystąpieniem incydentu przez zespoły IT.

Jeśli dostępna jest pojemność, która może być wykorzystana, może mieć sens, aby najpierw przydzielić ją do produkcji, obsługi klienta, finansów lub innych funkcji.

To elegancka degradacja: zachowanie zdolności do uruchamiania funkcji, które generują największą wartość biznesową, zamiast pozwalać, aby awaria mniej krytycznych elementów spowodowała awarię całego systemu.

Jak zespoły IT powinny monitorować odporność aplikacji?

Monitorowanie poszczególnych serwerów może być przydatne, ale monitorowanie odporności powinno odzwierciedlać całkowitą usługę aplikacyjną postrzeganą przez użytkowników.

Realistyczny model składa się z kilku warstw:

Warstwa	Co monitorować	Przykład niepowodzenia
Host	CPU, RAM, dysk, dostępność systemu operacyjnego	Serwer przeciążony lub offline
Aplikacja	Status procesu i usługi	Aplikacja się zawiesza
Zależność	Baza danych, DNS, tożsamość, przechowywanie	Aplikacja uruchamia się, ale nie może działać.
Dostęp	Bramka, portal, ścieżka sieciowa	Użytkownicy nie mogą się połączyć
Sesja	Aktywni użytkownicy, awarie, opóźnienie	Aplikacja jest online, ale nieużyteczna
Funkcja biznesowa	Zakończenie udanego przepływu pracy	Użytkownik nie może wykonać wymagane zadanie

Warstwa funkcji biznesowej jest jedną z najprostszych do przeoczenia.

Pulpity nawigacyjne infrastruktury mogą pokazywać wszystkie serwery, usługi i ścieżki sieciowe jako zdrowe, podczas gdy rzeczywisty przepływ pracy użytkownika jest zagrożony. Dlatego ważne jest, aby krytyczne aplikacje monitorowały swoje zdrowie z perspektywy operacji, które mają wspierać.

Jak należy testować odporność aplikacji?

Architektura odporności, która nigdy nie doświadczyła kontrolowanej awarii, zawiera nieprzetestowane założenia.

Użyj testów, aby ocenić reakcję systemu, gdy kluczowe komponenty stają się niedostępne. Testy powinny obejmować wyłączenie hosta aplikacji, zatrzymanie usługi aplikacji, symulację utraty trasy sieciowej, weryfikację zachowania bramy lub równoważenia obciążenia, przywracanie z kopii zapasowej oraz uzyskiwanie dostępu do aplikacji z alternatywnego punktu końcowego.

Procesy testowe powinny wykraczać poza techniczne aspekty odzyskiwania. Zespoły IT powinny sprawdzić, czy powiadomienia są wysyłane do odpowiednich pracowników administracyjnych, czy kroki odzyskiwania są wykonywane w odpowiedniej kolejności oraz czy użytkownicy są w stanie wykonać rzeczywiste zadanie biznesowe po przywróceniu usług.

Procedury operacyjne są integralną częścią odpornego systemu. Procedury eskalacji alertów: kto otrzymuje alert? Kto ma uprawnienia do inicjowania przełączenia? Gdzie przechowywana jest dokumentacja odzyskiwania i dane uwierzytelniające? Która zależność musi być uruchomiona jako pierwsza?

Nadmiar techniczny przynosi niewielkie korzyści, jeśli procesy odzyskiwania dostępu nie zostały przetestowane.

Co może być na liście kontrolnej odporności aplikacji?

Zanim przystąpią do wdrożenia krytycznej aplikacji Windows odpornej na awarie, zespoły IT powinny być w stanie odpowiedzieć na następujące pytania:

• Jakie procesy biznesowe opierają się na aplikacji?
• Jakie są jego RTO i RPO?
• Jakie serwery, bazy danych i usługi zewnętrzne są wymagane?
• Gdzie są jego krytyczne punkty awarii?
• Czy inny host aplikacji może przyjąć użytkowników, jeśli jeden host zawiedzie?
• Czy użytkownicy mogą się połączyć, jeśli ich normalny punkt końcowy lub lokalizacja są niedostępne?
• Czy jest wystarczająca wolna pojemność do pracy w trybie degradacji?
• Czy problemy z infrastrukturą, zależnościami i sesjami są aktywnie monitorowane?
• Czy administratorzy są powiadamiani przed tym, jak ważne progi stają się awariami?
• Czy dane aplikacji i konfiguracja są chronione?
• Czy przywracanie zostało faktycznie przetestowane?
• Czy problematyczne zmiany można cofnąć?
• Czy sekwencja odzyskiwania jest udokumentowana?
• Czy użytkownicy mogą zakończyć wymagany proces biznesowy po odzyskaniu?

Nie wszystkie odpowiedzi wymagają drogiej infrastruktury o wysokiej dostępności. Odpowiedni poziom ochrony zależy od kosztów i wpływu operacyjnego przestojów.

To, co ma znaczenie, to że decyzje dotyczące dostępności, redundancji i odzyskiwania są podejmowane świadomie, a nie zakładane.

Jak TSplus może pomóc w utrzymaniu dostępności aplikacji Windows?

Dla organizacji, które polegają na istniejących aplikacjach Windows, możemy pomóc poprawić dostępność, centralizując aplikacje na zarządzanych serwerach Windows i dostarczając je do użytkowników za pośrednictwem klientów zgodnych z RDP, dostępu w stylu RemoteApp lub portalu internetowego HTML5. To zmniejsza zależność od indywidualnych punktów końcowych użytkowników i daje zespołom IT większą elastyczność, gdy użytkownicy muszą łączyć się z innego urządzenia lub lokalizacji.

TSplus Zdalny Dostęp może również wspierać wdrożenia wieloserwerowe z równoważeniem obciążenia i dostępem opartym na bramie. W połączeniu z odpornymi bazami danych, przechowywaniem, usługami tożsamości i siecią, ta architektura może zmniejszyć zależność od jednego hosta aplikacji i pomóc w utrzymaniu dostępu do krytycznych aplikacji Windows podczas zakłóceń w infrastrukturze.

Wniosek

Odporność aplikacji zależy od zrozumienia pełnej ścieżki między infrastrukturą a wykorzystaniem biznesowym. Redundancja, monitorowanie, kopie zapasowe, planowanie pojemności i procedury odzyskiwania są najbardziej skuteczne, gdy są zaprojektowane wokół jasno określonych zależności aplikacji i celów odzyskiwania.

Dla istniejących aplikacji Windows odporność często pochodzi z wzmocnienia środowiska wokół oprogramowania, a nie z przebudowy samej aplikacji. Kluczowy test pozostaje prosty: gdy wystąpi zakłócenie, czy użytkownicy mogą kontynuować pracę, czy też IT może przywrócić wymaganą funkcję biznesową w uzgodnionym czasie odzyskiwania?