Edytuj

Share via

Hostowanie obciążenia Murex MX.3 na platformie Azure przy użyciu programu Oracle

Azure Firewall
Azure ExpressRoute
Azure Key Vault
Azure Storage
Azure Monitor

Celem tego artykułu jest przedstawienie szczegółów technicznych dotyczących implementowania obciążeń Murex na platformie Azure.

Architektura

Obciążenia Murex MX.3 mogą być uruchamiane w bazach danych, takich jak Oracle, Sybase lub SQL Server. Ta architektura koncentruje się na szczegółach implementowania aplikacji MX.3 przy użyciu oracle jako bazy danych.

Diagram przedstawiający architekturę platformy Azure dla aplikacji Murex MX.3.

Pobierz plik programu Visio z tą architekturą.

Przepływ pracy

  • Uzyskaj dostęp do składnika warstwy prezentacji MX.3 warstwy aplikacji hostowanej na platformie Azure przy użyciu usługi Azure ExpressRoute lub połączenia sieci VPN między platformą Azure a środowiskiem lokalnym. Połączenie jest chronione za pomocą usługi Azure Firewall.
  • Uzyskaj dostęp do warstwy prezentacji przy użyciu rozwiązań infrastruktury pulpitu wirtualnego (VDI), takich jak Citrix. Możesz również bezpośrednio uzyskać dostęp do warstwy za pośrednictwem aplikacji klasycznej lub za pomocą interfejsu internetowego dostarczonego przez aplikację MX.3.
  • Warstwa aplikacji zawiera warstwę prezentacji, warstwę biznesową, warstwę orkiestracji i warstwę siatki. Uzyskuje dostęp do bazy danych Oracle na potrzeby przechowywania i pobierania danych.
  • Warstwa prezentacji uzyskuje dostęp do warstwy biznesowej, warstwy aranżacji i składników warstwy siatki w celu ukończenia procesu biznesowego.
  • Baza danych Oracle używa dysków SSD Azure Premium lub Azure NetApp Files jako mechanizmu magazynu w celu szybszego dostępu.
  • Warstwa aplikacji uzyskuje dostęp do usług Azure Key Vault w celu bezpiecznego przechowywania kluczy szyfrowania i wpisów tajnych.
  • Administracja użytkownicy bezpiecznie uzyskują dostęp do serwerów Murex MX.3 przy użyciu usługi Azure Bastion.

Składniki

Szczegóły scenariusza

Murex to wiodący globalny dostawca oprogramowania do handlu, zarządzania ryzykiem, operacji przetwarzania i rozwiązań po handlu dla rynków kapitałowych. Wiele banków wdraża platformę TRZECIEj generacji Murex MX.3, aby zarządzać ryzykiem, przyspieszyć transformację i uprościć zgodność, a jednocześnie zwiększyć przychody. Platforma Murex umożliwia klientom uzyskanie większej kontroli nad swoimi operacjami, zwiększenie wydajności i zmniejszenie kosztów operacyjnych.

MX.3 to aplikacja kliencka/serwerowa oparta na strukturze architektury trójwarstwowej. Banki używają MX.3 do swoich wymagań biznesowych, takich jak sprzedaż i handel, zarządzanie ryzykiem przedsiębiorstwa oraz zabezpieczenia i inwestycje.

Platforma Microsoft Azure zapewnia klientom Murex szybki i łatwy sposób tworzenia i skalowania infrastruktury MX.3. Platforma Azure umożliwia bezpieczne, niezawodne i wydajne środowisko dla systemów produkcyjnych, programistycznych i testowych. Znacznie zmniejsza koszt infrastruktury potrzebny do obsługi środowiska MX.3.

Aby uzyskać szczegółowe informacje na temat różnych warstw i warstw aplikacji Murex MX.3, obliczeń i wymagań dotyczących magazynu, skontaktuj się z zespołem technicznym Murex.

Linux jest znakiem towarowym swojej firmy. Użycie tego znaku oznacza nie jest dorozumiane.

Potencjalne przypadki użycia

To rozwiązanie jest idealne do użycia w branży finansowej. Poniżej przedstawiono niektóre potencjalne przypadki użycia.

  • Zyskaj lepszą kontrolę nad operacjami, zwiększ wydajność i zmniejsz koszty infrastruktury.
  • Tworzenie bezpiecznego, niezawodnego i wydajnego środowiska na potrzeby produkcji i programowania.

Kwestie wymagające rozważenia

Te zagadnienia implementują filary struktury Azure Well-Architected Framework, która jest zestawem wytycznych, które mogą służyć do poprawy jakości obciążenia. Aby uzyskać więcej informacji, zobacz Microsoft Azure Well-Architected Framework.

Murex MX.3 to złożone obciążenie o dużej ilości pamięci, małych opóźnieniach i wymaganiach dotyczących wysokiej dostępności. W tej sekcji opisano niektóre zagadnienia techniczne, które należy przeanalizować podczas implementowania obciążenia Murex MX.3 na platformie Azure.

  • Usługa MX.3 używa architektury klienta/serwera. Podczas implementowania jej na platformie Azure należy postępować zgodnie z architekturą infrastruktura jako usługa (IaaS). Dokładnie przeanalizuj wszystkie natywne usługi platformy Azure, aby upewnić się, że spełniają one wymagania techniczne dotyczące murexu.
  • Rozwiązanie MX.3 można wdrożyć całkowicie na platformie Azure lub wdrożyć częściowy zestaw składników platformy Azure przy użyciu modelu hybrydowego. Ten artykuł nie obejmuje modeli hybrydowych. Przed użyciem hybrydowego modelu wdrażania należy dokładnie przeanalizować architekturę i wymagania techniczne. Modele hybrydowe wdrożenia mx.3 podlegają przeglądowi technicznemu przez zespół Murex.
  • Dostęp do warstwy klienta MX.3 można uzyskać bezpośrednio z poziomu pulpitu użytkownika lub za pośrednictwem rozwiązań VDI, takich jak Citrix.
  • Obciążenia Murex MX.3 w różnych warstwach wymagają określonych typów zasobów obliczeniowych, aby spełnić wymagania funkcjonalne i techniczne. Zapoznaj się z architekturą Murex MX.3, aby zrozumieć wymagania dotyczące mocy obliczeniowej, pamięci i magazynu dla obciążenia MX.3.
  • Aplikacja MX.3 wymaga łączności zewnętrznej (internetowej) i wewnętrznej (lokalnej) do wykonywania zadań. Architektura platformy Azure dla aplikacji MX.3 musi obsługiwać bezpieczny model łączności w celu integracji z usługami wewnętrznymi i zewnętrznymi. Użyj sieci VPN typu lokacja-lokacja platformy Azure lub usługi ExpressRoute (zalecane), aby nawiązać połączenie z usługami lokalnymi.
  • W przypadku tworzenia kopii zapasowych można używać natywnych usług kopii zapasowych platformy Azure w połączeniu z usługą Azure Storage. Te usługi są używane do wykonywania codziennych, cotygodniowych lub miesięcznych kopii zapasowych maszyn wirtualnych aplikacji lub innych wymagań dotyczących kopii zapasowych/archiwizacji warstwy aplikacji. W przypadku wymagań dotyczących bazy danych należy użyć natywnej replikacji bazy danych lub narzędzi do tworzenia kopii zapasowych.
  • Aby uzyskać wysoką dostępność i odporność rozwiązań Murex na platformie Azure, należy uruchomić każdą warstwę warstwy aplikacji na co najmniej dwóch maszynach wirtualnych. Aby uzyskać wysoką dostępność na wielu maszynach wirtualnych, możesz użyć konfiguracji zestawu dostępności platformy Azure. Zestawy skalowania maszyn wirtualnych platformy Azure umożliwiają również nadmiarowość i lepszą wydajność aplikacji rozproszonych w wielu wystąpieniach. Wysoką dostępność warstwy aranżacji można osiągnąć, hostując je w wielu wystąpieniach i wywołując wystąpienia przy użyciu skryptów niestandardowych. Aby osiągnąć wymagania dotyczące wysokiej dostępności, można użyć funkcji wysokiej dostępności baz danych, takich jak Oracle Data Guard lub SQL Server Always On.
  • Aby uzyskać wymagane metryki wydajności dla obciążeń Murex, rozważ przechowywanie katalogu aplikacji MX.3 i baz danych na platformie Azure Dyski zarządzane przy użyciu dysków SSD w warstwie Premium. W przypadku operacji o dużej ilości danych wejściowych/wyjściowych na sekundę i małych opóźnieniach można użyć usługi Azure NetApp Files jako opcji magazynu. Możesz użyć grupy umieszczania w pobliżu i przyspieszania sieci na platformie Azure, aby uzyskać wysoką przepływność sieci między warstwami.
  • Usługi Azure Monitor można używać do monitorowania składników infrastruktury platformy Azure. Mechanizm zgłaszania alertów umożliwia wykonywanie jakichkolwiek działań zapobiegawczych, takich jak automatyczne skalowanie lub powiadomienia.
  • Użyj usług takich jak Azure Key Vault, aby spełnić wymagania dotyczące zabezpieczeń aplikacji MX.3 na platformie Azure, przechowując klucze i certyfikaty. Za pomocą sieci wirtualnych platformy Azure, sieciowych grup zabezpieczeń i grup zabezpieczeń aplikacji można kontrolować dostęp między różnymi warstwami i warstwami. Usługi Azure Firewall, DDoS protection i aplikacja systemu Azure Gateway lub Web Application Firewall umożliwiają ochronę warstwy frontonu w zależności od wymagań dotyczących zabezpieczeń.
  • Automatyzację infrastruktury można osiągnąć przy użyciu usług Infrastructure as Code (IaC), takich jak szablony usługi Azure Resource Manager lub skrypty narzędzia Terraform. Aby spełnić wymagania metodyki DevOps na poziomie aplikacji, możesz użyć narzędzi Murex DevOps.

Niezawodność

Niezawodność zapewnia, że aplikacja może spełnić zobowiązania podjęte przez klientów. Aby uzyskać więcej informacji, zobacz Omówienie filaru niezawodności.

  • Wszystkie warstwy warstwy aplikacji są hostowane w co najmniej dwóch maszynach wirtualnych lub zestawach skalowania maszyn wirtualnych w każdej strefie dostępności w celu zapewnienia wysokiej odporności.
  • Warstwy biznesowe i sieciowe warstwy aplikacji są hostowane w zestawach skalowania maszyn wirtualnych. Te zestawy skalowania obsługują skalowanie automatyczne maszyn wirtualnych na podstawie wstępnie skonfigurowanych warunków.
  • W przypadku warstw aranżacji serwery mogą być dystrybuowane między różnymi maszynami wirtualnymi w razie potrzeby. Jeśli występują problemy z jedną z maszyn wirtualnych, możesz skonfigurować skrypty automatyzacji (szablon usługi Resource Manager lub narzędzie Terraform) i powiadomienia o alertach, aby automatycznie aprowizować więcej maszyn wirtualnych.
  • W przypadku warstwy trwałości można uzyskać wysoką dostępność bazy danych Oracle za pomocą rozwiązania Oracle Data Guard. W tym rozwiązaniu wiele maszyn wirtualnych działa w różnych strefach dostępności z aktywną replikacją skonfigurowaną między nimi.
  • W przypadku warstwy aplikacji nadmiarowe maszyny wirtualne są hostowane dla każdej warstwy. Jeśli wystąpi awaria dowolnej maszyny wirtualnej, platforma Azure zapewnia, że kolejne wystąpienie maszyny wirtualnej jest automatycznie aprowizowane w celu obsługi wymaganego poziomu odzyskiwania po awarii.
  • W przypadku odzyskiwania po awarii należy uruchomić lokację odzyskiwania po awarii w innym regionie świadczenia usługi Azure. Konfiguracje odzyskiwania po awarii aktywne/aktywne/pasywne można używać na podstawie wymagań celu punktu odzyskiwania i celu czasu odzyskiwania. Za pomocą usługi Site Recovery można zautomatyzować proces odzyskiwania po awarii i natywną replikację bazy danych. Możesz również użyć narzędzi do tworzenia kopii zapasowych, aby uzyskać wymagany poziom metryk celu punktu odzyskiwania.
  • W przypadku warstwy trwałości należy skonfigurować usługę Oracle DataGuard z maksymalną wydajnością (zatwierdzenie synchroniczne), aby uniknąć żadnego wpływu na mx.3. Wystąpienia bazy danych Oracle między strefami dostępności zapewniają odzyskanie aplikacji przy minimalnej utracie danych.
  • Jeśli wystąpi awaria regionu, możesz użyć skryptów automatyzacji (Resource Manager lub Terraform) lub usług Site Recovery, aby szybko aprowizować środowisko w sparowanym regionie świadczenia usługi Azure.
  • W zależności od wymagań celu punktu odzyskiwania można używać natywnych rozwiązań do tworzenia kopii zapasowych Oracle, takich jak Program Recovery Manager (RMAN), aby okresowo tworzyć kopie zapasowe bazy danych i przywracać ją.

Zabezpieczenia

Zabezpieczenia zapewniają ochronę przed celowymi atakami i nadużyciami cennych danych i systemów. Aby uzyskać więcej informacji, zobacz Omówienie filaru zabezpieczeń.

  • Za pomocą usługi Azure Firewall można chronić sieć wirtualną MX.3. Pomaga to w analizie zagrożeń i kontrolowaniu ruchu przychodzącego do warstwy prezentacji i ruchu wychodzącego z warstwy aplikacji do Internetu.
  • Sieciowe grupy zabezpieczeń w podsieci aplikacji i podsieci bazy danych w aplikacji MX.3 mogą zapewnić kontrolę nad ruchem sieciowym przepływającym w bazie danych, firmie i warstwie aranżacji.
  • Za pomocą usługi Azure Key Vault można bezpiecznie przechowywać wszelkie poufne informacje i certyfikaty.

Optymalizacja kosztów

Optymalizacja kosztów dotyczy sposobów zmniejszenia niepotrzebnych wydatków i poprawy wydajności operacyjnej. Aby uzyskać więcej informacji, zobacz Omówienie filaru optymalizacji kosztów.

  • Możesz hostować zasoby infrastruktury dla rozwiązań VDI, takich jak Citrix na platformie Azure. Warstwa klienta używa rozwiązań VDI do uzyskiwania dostępu do warstwy aplikacji i optymalizowania ogólnego kosztu i wydajności rozwiązania.
  • W przypadku obliczeń użyj planu oszczędności platformy Azure i rezerwacji platformy Azure na potrzeby obliczeń i uzyskaj znaczne oszczędności w porównaniu z płatnościami zgodnie z rzeczywistym użyciem.

Aby oszacować koszty, możesz użyć kalkulatora cen platformy Azure.

Doskonałość operacyjna

Doskonałość operacyjna obejmuje procesy operacyjne, które wdrażają aplikację i działają w środowisku produkcyjnym. Aby uzyskać więcej informacji, zobacz Omówienie filaru doskonałości operacyjnej.

  • Za pomocą usługi Azure Monitor można monitorować platformę i monitorować aplikację przy użyciu dzienników usługi Azure Monitor. Można jednak również skonfigurować własne niestandardowe narzędzie do monitorowania platformy i aplikacji w razie potrzeby.
  • Tagowanie zasobów umożliwia etykietowanie zasobów i rozszerzanie monitorowania alertów i powiadomień przy użyciu efektywnej integracji systemu zarządzania usługami IT.
  • Aby zautomatyzować proces aprowizacji infrastruktury, można użyć narzędzi IaC, takich jak szablony usługi Resource Manager lub skrypty narzędzia Terraform. Za pomocą narzędzi usługi Azure DevOps można zintegrować narzędzia IaC z łańcuchem narzędzi Murex DevOps.
  • Za pomocą zasad platformy Azure można skodyfikować wymagania dotyczące zabezpieczeń lub zgodności oraz weryfikować środowisko platformy Azure pod kątem wymagań dotyczących inspekcji i zgodności.

Maszyny wirtualne można aprowizować w warstwie aranżacji warstwy aplikacji przy użyciu skryptów niestandardowych.

Efektywność wydajności

Efektywność wydajności to możliwość skalowania obciążenia w celu zaspokojenia zapotrzebowania użytkowników w wydajny sposób. Aby uzyskać więcej informacji, zobacz Omówienie filaru wydajności.

  • Możesz uzyskać wysoką przepływność magazynu dla serwera bazy danych przy użyciu usługi Azure NetApp Files Ultra Storage do hostowania bazy danych Oracle. Można jednak również użyć maszyny wirtualnej platformy Azure z dyskiem zarządzanym w celu uzyskania mniejszej przepływności magazynu, takiej jak magazyn SSD w warstwie Premium.
  • W przypadku scenariuszy o małych opóźnieniach należy użyć grup umieszczania w pobliżu platformy Azure między warstwą aplikacji i trwałością.
  • Aby uzyskać lepszą wydajność i niezawodność, użyj usługi ExpressRoute, aby nawiązać połączenie z systemem lokalnym.
  • Usługa Azure Files umożliwia przechowywanie plików używanych przez warstwę aplikacji MX.3, takich jak pliki konfiguracji, pliki dziennika i pliki binarne.

Model piasty i szprych sieci

Kluczową kwestią podczas implementowania obciążeń MX.3 na platformie Azure jest zdefiniowanie architektury strefy docelowej. Ta architektura zawiera subskrypcję, grupę zasobów, izolację sieci wirtualnej oraz łączność między różnymi składnikami rozwiązania. W tej sekcji opisano architekturę strefy docelowej w celu zaimplementowania obciążenia MX.3 na platformie Azure opartego na przewodniku Microsoft Cloud Adoption Framework.

Na poniższym diagramie przedstawiono ogólny widok strefy docelowej korzystającej z topologii sieci piasty i szprych na platformie Azure.

Diagram przedstawiający przykład modelu piasty i szprych z usługami platformy Azure.

  • Użycie tego modelu umożliwia silną izolację sieci szprych używanych do uruchamiania różnych środowisk. Model utrzymuje również bezpieczną kontrolę dostępu i warstwę usługi udostępnionej w sieci piasty.
  • Możesz użyć tego samego modelu piasty i szprych w innym regionie, co jest rozwiązaniem obejmującym wiele regionów. Możesz utworzyć koncentrator dla każdego regionu, a następnie różne szprychy dla nieprodukcyjnej i produkcyjnej.
  • Możesz użyć tej strefy docelowej dla jednej subskrypcji lub wielu subskrypcji w zależności od tego, jak organizacja kategoryzuje aplikacje.

Każdy składnik w strefie docelowej jest omówiony poniżej.

Centrum: Piasta to sieć wirtualna, która działa jako centralna lokalizacja do zarządzania łącznością zewnętrzną z siecią lokalną klienta MX.3 i usługami hostingowymi używanymi przez wiele obciążeń.

Szprycha: Szprychy to sieci wirtualne, które hostują obciążenia platformy Azure mx.3 i łączą się z centralnym koncentratorem za pośrednictwem komunikacji równorzędnej sieci wirtualnych.

Komunikacja równorzędna sieci wirtualnych: sieci wirtualne piasty i szprych są połączone za pomocą komunikacji równorzędnej sieci wirtualnych, która obsługuje połączenia o małych opóźnieniach między sieciami wirtualnymi.

Brama: brama służy do wysyłania ruchu z sieci lokalnej klienta MX.3 do sieci wirtualnej platformy Azure. Możesz zaszyfrować ruch przed jego wysłaniem.

Podsieć bramy: brama, która wysyła ruch ze środowiska lokalnego do platformy Azure, używa określonej podsieci nazywanej podsiecią bramy. Podsieć bramy jest częścią zakresu adresów IP sieci wirtualnej, który jest wybierany podczas konfigurowania sieci wirtualnej. Zawiera ona adresy IP używane przez zasoby i usługi bramy sieci wirtualnej.

Maszyna wirtualna usługi Azure Jumpbox: usługa Jumpbox łączy maszyny wirtualne platformy Azure z warstwami aplikacji i trwałości przy użyciu dynamicznego adresu IP. Usługa Jumpbox uniemożliwia udostępnianie wszystkim maszynom wirtualnym aplikacji i bazy danych publicznej. To połączenie jest punktem wejścia, aby nawiązać połączenie za pośrednictwem protokołu RDP z sieci lokalnej.

Azure Firewall: należy kierować wszystkie połączenia przychodzące i wychodzące między maszynami wirtualnymi MX.3 i Internetem za pośrednictwem usługi Azure Firewall. Typowe przykłady takiej łączności to synchronizacja czasu i aktualizacja definicji oprogramowania antywirusowego.

Azure Bastion: przy użyciu usługi Azure Bastion można bezpiecznie połączyć maszyny wirtualne aplikacji i bazy danych za pośrednictwem witryny Azure Portal. Wdróż hosta usługi Azure Bastion w sieci wirtualnej piasty, a następnie uzyskaj dostęp do maszyn wirtualnych w równorzędnych sieciach wirtualnych szprych. Ten składnik jest opcjonalny i można go użyć w razie potrzeby.

Podsieć usługi Azure Bastion: usługa Azure Bastion wymaga dedykowanej podsieci: AzureBastionSubnet. Należy utworzyć tę podsieć w centrum i wdrożyć hosta bastionu w tej podsieci.

Podsieć zarządzania platformą Azure: usługa Azure Jumpbox musi znajdować się w podsieci zarządzania. Serwer Przesiadkowy zawiera maszyny wirtualne, które implementują funkcje zarządzania i monitorowania dla maszyn wirtualnych aplikacji i bazy danych w sieci wirtualnej będącej szprychą.

Podsieć aplikacji: w tym miejscu możesz umieścić wszystkie składniki w warstwie aplikacji. Posiadanie dedykowanej podsieci aplikacji pomaga również kontrolować ruch do warstw biznesowych, orkiestracji i usług technicznych za pośrednictwem sieciowych grup zabezpieczeń.

Podsieć bazy danych: składniki w podsieci bazy danych można umieścić w dedykowanej podsieci, aby zarządzać ruchem wokół bazy danych.

Link prywatny: usługi platformy Azure, takie jak magazyny usługi Recovery Services, usługa Azure Cache for Redis i usługa Azure Files, są połączone za pośrednictwem łącza prywatnego do sieci wirtualnej. Połączenie prywatne między tymi usługami a siecią wirtualną zabezpiecza połączenie między punktami końcowymi na platformie Azure, eliminując narażenie danych na Internet.

Współautorzy

Ten artykuł jest obsługiwany przez firmę Microsoft. Pierwotnie został napisany przez następujących współautorów.

Autorzy zabezpieczeń:

Inni współautorzy:

Aby wyświetlić niepubalne profile serwisu LinkedIn, zaloguj się do serwisu LinkedIn.

Następne kroki