Zapewnienie wysokiej dostępności aplikacji bankowych opartych na chmurze

Zapewnienie wysokiej dostępności aplikacji bankowych opartych na chmurze

Kuszące jest myślenie, że dostawca usług w chmurze zapewni wysoką dostępność krytycznych aplikacji bankowych w chmurze. Problem polega na tym, że tak naprawdę ich nie ma.

Ensuring high availability for cloud-based banking applications PlatoBlockchain Data Intelligence. Vertical Search. Ai.Ensuring high availability for cloud-based banking applications PlatoBlockchain Data Intelligence. Vertical Search. Ai.
Todd Doane, architekt rozwiązań, technologia SIOS

Twój dostawca chmury mógł pomóc Ci skonfigurować klaster maszyn wirtualnych (VM) z wieloma centrami danych lub strefami dostępności (AZ). Być może wdrożono automatyczny system przełączania awaryjnego, aby zapewnić, że rezerwowa maszyna wirtualna w konfiguracji może natychmiast przejąć kontrolę, jeśli podstawowa maszyna wirtualna nagle przejdzie w tryb offline. Wszystko wskazuje na to, że powinno zapewniać wysoką dostępność, prawda?

Ale przyjrzyj się uważnie umowie dotyczącej poziomu usług (SLA) określającej wysoką dostępność: Umowa SLA gwarantuje, że co najmniej jedna z maszyn wirtualnych w Twoim systemie będzie dostępna przez co najmniej 99.9%, a nawet 99.99% czasu. Ale to nie gwarantuje dostępności aplikacji ani danych. Jeśli pozostała maszyna wirtualna nie może uzyskać dostępu do infrastruktury pamięci masowej, w której znajdują się aplikacje bankowe i dane, oznacza to, że krytyczne aplikacje są w rzeczywistości offline.

Zapewnienie dostępności w chmurze

Jak zapewnić wysoką dostępność krytycznych aplikacji bankowych i danych w chmurze lub w hybrydowej konfiguracji on-prem/cloud, jeśli skonfigurowanie podstawowej technologii do automatycznego przełączania awaryjnego w wielu AZ jest niewystarczające?

Zacznijmy od stwierdzenia, że ​​rozmieszczenie klastrowanych maszyn wirtualnych w wielu AZ ma kluczowe znaczenie dla zapewnienia wysokiej dostępności (HA) kluczowych aplikacji i danych. Potrzebna jest jednak strategia zapewniająca każdej z tych maszyn wirtualnych dostęp do krytycznych aplikacji i danych, które chcesz zachować. W tym miejscu tradycyjne podejścia do HA różnią się, jeśli chodzi o chmurę.

W tradycyjnej — czyli lokalnej — konfiguracji HA można utworzyć klaster przełączania awaryjnego składający się z wielu serwerów lub maszyn wirtualnych oraz sieci pamięci masowej (SAN), w której znajdują się aplikacje i dane. Każdy serwer lub maszyna wirtualna w klastrze może wchodzić w interakcje z aplikacjami i danymi w sieci SAN, więc jeśli maszyna wirtualna, na której aktywnie działa kluczowa aplikacja, nagle przejdzie w tryb offline, klaster automatycznie przełączy się awaryjnie na inną maszynę wirtualną, która może wchodzić w interakcje z siecią SAN i rozpocząć uruchamianie aplikacji i aktualizacji tej samej bazy danych, z której korzystała poprzednia maszyna.

Konfiguracja dla chmury

Jednak w chmurze nie ma realnej możliwości utworzenia współdzielonej sieci SAN. Istnieje kilka opcji pamięci współdzielonej, ale nie zapewniają one wydajności ani poziomów HA, których wymagają krytyczne aplikacje bankowe. Zamiast tego konfiguracje HA oparte na chmurze zależą od pamięci masowej o wysokiej wydajności dołączonej do każdej maszyny wirtualnej w klastrze. Gdy dana maszyna wirtualna uruchamia aplikację, wchodzi w interakcję z danymi przechowywanymi w bazie danych, która znajduje się w magazynie dołączonym do tej maszyny wirtualnej.

Kluczem do HA dla aplikacji bankowych opartych na chmurze jest zatem zapewnienie, że każda maszyna wirtualna w klastrze zawsze ma te same aplikacje i te same dane. W ten sposób, jeśli podstawowa maszyna wirtualna w klastrze nagle się wyłączy, klaster może automatycznie przełączyć się awaryjnie na maszynę wirtualną w stanie gotowości, z których każda może natychmiast rozpocząć uruchamianie aplikacji i interakcję z danymi, ponieważ kopia aplikacji i danych znajduje się w własną dołączoną pamięć masową.

Twój dostawca chmury może łatwo skonfigurować maszyny wirtualne, które zapewnią poziom wydajności i dostępności wymagany przez Twoje krytyczne aplikacje. Może również dołączać systemy pamięci masowej o wysokiej wydajności do tych maszyn wirtualnych i konfigurować klaster do automatycznego przełączania awaryjnego w wielu AZ. Następnie musisz wdrożyć mechanizm, który automatyzuje synchroniczną replikację danych między wszystkimi systemami pamięci masowej podłączonymi do maszyn wirtualnych w klastrze przełączania awaryjnego.

Rozwiązania do replikacji danych

Masz wiele możliwości, jeśli chodzi o rozwiązania do replikacji danych.

Jeśli Twój klaster jest oparty na systemie Windows i korzystasz z programu Microsoft SQL Server, możesz użyć wbudowanej funkcji grup dostępności (AG), która automatycznie replikuje bazy danych SQL nazwane przez użytkownika do każdego węzła w klastrze. Wadą tego podejścia jest to, że replikuje się tylko bazy danych SQL, a nie każdy blok danych w magazynie. Replikacja wielu baz danych SQL Server na wiele rezerwowych maszyn wirtualnych może być bardzo kosztowna, ponieważ będziesz musiał używać SQL Server Enterprise Edition do replikowania więcej niż jednej bazy danych lub replikowania baz danych do wielu maszyn wirtualnych, nawet jeśli Twoje aplikacje działają doskonale przy użyciu SQL Server Standard Edition .

Alternatywnie można użyć rozwiązania klastrowego bez sieci SAN, które zapewnia zautomatyzowaną replikację danych na poziomie bloków z aktywnej podstawowej maszyny wirtualnej do każdej dodatkowej maszyny wirtualnej w klastrze. Zaletą korzystania z rozwiązania klastrowego bez sieci SAN jest to, że jest ono niezależne od aplikacji i baz danych; po prostu replikuje bloki danych z jednego systemu pamięci masowej do drugiego, zapewniając, że wszystkie dane w podstawowym systemie pamięci masowej zostaną zreplikowane do każdej z pozostałych maszyn wirtualnych. Wadą podejścia opartego na klastrach bez sieci SAN jest to, że istnieje jeszcze jedno oprogramowanie, które zespół IT może licencjonować i uczyć się, co może wydawać się uciążliwe, jeśli można korzystać z funkcji AG SQL Server bez dodatkowych kosztów.

Replikacja danych jest kluczem do zapewnienia HA dla systemów bankowych opartych na chmurze, niezależnie od tego, czy korzystasz z funkcjonalności wbudowanej w rozwiązanie takie jak SQL Server, czy z funkcjonalności zapewnianej przez niezależne rozwiązanie klastrowe bez sieci SAN.

Twój dostawca usług w chmurze może zapewnić wysokowydajną infrastrukturę wymaganą przez Twoje aplikacje, ale musisz upewnić się, że dane i aplikacje dostępne dla każdej maszyny wirtualnej w tym klastrze są aktualne, jeśli Twoje rozwiązanie HA ma działać zgodnie z oczekiwaniami, kiedy tego potrzebujesz to zrobić.

Todd Doane jest architektem rozwiązań w firmie SIOS Technology. Spędził ponad 20 lat, głównie w świecie usług finansowych, tworząc architektury referencyjne o wysokiej dostępności oraz wzorce i zasady projektowe specyficzne dla aplikacji.

Znak czasu:

Więcej z Innowacje bankowe