Wdrażanie pakietu APLIKACJI IBM Maximo w Azure

W tym artykule opisano wdrażanie pakietu IBM Maximo Application Suite (MAS) w Azure. PLATFORMA MAS działa w systemie Red Hat OpenShift. Azure Red Hat OpenShift (ARO) jest preferowaną platformą OpenShift, jeśli spełnia wymagania operacyjne, bezpieczeństwa i sieci. Użyj samoobsługowego rozwiązania Red Hat OpenShift na Azure tylko wtedy, gdy potrzebujesz kontroli, że usługa ARO nie zapewnia, na przykład określone rozłączone wzorce wdrażania lub dostosowywanie na poziomie klastra.

W tym artykule nie opisano szczegółowo sposobu instalowania rozwiązania MAS. Aby uzyskać więcej informacji na temat instalacji, zobacz Instalowanie pakietu aplikacji Maximo.

Architektura

Na poniższym diagramie przedstawiono wdrożenie mas oparte na usłudze ARO na Azure.

Pobierz plik Visio tej architektury.

Obciążenie można wdrożyć jako wdrożenie wewnętrzne lub zewnętrzne, w zależności od wymagań. Ten artykuł nie określa publicznego lub prywatnego modelu wdrażania usługi ARO. Wybierz architekturę płaszczyzny sterowania, ruchu przychodzącego i ruchu wychodzącego na podstawie architektury strefy docelowej Azure, w tym jej topologii sieci, modelu łączności, mechanizmów zabezpieczeń, wymagań dotyczących dostępu operacyjnego, wymagań dotyczących zgodności i wzorców dostępu użytkowników mas.

Gdy firma IBM obsługuje zewnętrzne bazy danych dla wdrażanych aplikacji MAS, spróbuj zdystansować te bazy danych, aby zmniejszyć stan w klastrze OpenShift i rozdzielić zarządzanie bazami danych z zarządzania klastrem.

Workflow

Z perspektywy infrastruktury ta architektura zapewnia następujące możliwości:

• Usługa zarządzana Azure Red Hat OpenShift do wdrażania obciążeń o wysokiej dostępności w różnych strefach dostępności
• Klaster OpenShift zintegrowany z siecią i magazynem Azure
• Azure Files Premium i Azure Files Standard dla obsługiwanych wymagań dotyczących magazynu MAS
• Azure SQL Managed Instance lub IBM Db2 Warehouse oparty na kontenerze
• Azure DNS do zarządzania systemem nazw domen (DNS) openShift i jego kontenerami
• Microsoft Entra ID na potrzeby logowania jednokrotnego w usłudze MAS

Składniki

• Azure Red Hat OpenShift (ARO) to preferowana platforma OpenShift dla platformy MAS w Azure. Usługa ARO zmniejsza odpowiedzialność operacyjną za uruchamianie usługi OpenShift w porównaniu z klastrem zarządzanym samodzielnie na maszynach wirtualnych Azure.

• Azure Virtual Machines to infrastruktura jako usługa (IaaS), która wdraża skalowalne zasoby obliczeniowe na żądanie. Użyj Virtual Machines zamiast usługi ARO, aby wdrożyć samoobsługowe rozwiązanie Red Hat OpenShift na Azure.

  Opcjonalnie należy użyć Azure maszyn wirtualnych z systemem Linux jako serwerów przesiadkowych do instalacji mas i administrowania platformą OpenShift. Jeśli masz łączność sieci prywatnej ze środowiskiem Azure, możesz wykonać administrację z istniejącej zabezpieczonej maszyny.

• Red Hat Enterprise Linux System CoreOS udostępnia obraz systemu operacyjnego dla węzłów OpenShift.

• Azure Load Balancer zapewnia łączność z klastrem. Load Balancer to wysokowydajna usługa równoważenia obciążenia warstwy 4 o wysokiej wydajności dla wszystkich przychodzących i wychodzących protokołów UDP (User Datagram Protocol) i Transmission Control Protocol (TCP). Load Balancer może obsługiwać miliony żądań na sekundę, zapewniając wysoką dostępność rozwiązania. Load Balancer jest strefowo nadmiarowa, zapewniając wysoką dostępność w różnych strefach dostępności.

• Azure Virtual Network jest podstawowym blokiem konstrukcyjnym dla sieci prywatnych na platformie Azure. Użyj Virtual Network do komunikacji między węzłami i usługami Azure oraz na potrzeby łączności hybrydowej.

• Azure Files zapewnia w pełni zarządzane udziały plików w chmurze, które są dostępne za pośrednictwem protokołów bloku komunikatów serwera (SMB) i sieciowego systemu plików (NFS). Użyj Azure Files do hostowania danych stanowych baz danych i systemów w klastrze.

• Azure DNS zarządza rozpoznawaniem nazw DNS dla kontenerów wewnątrz rozwiązania i poza nim. Azure DNS obsługuje wszystkie typowe rekordy DNS i zapewnia wysoką dostępność.

• Azure Bastion jest w pełni zarządzaną usługą, która zapewnia dostęp protokołu RDP (Remote Desktop Protocol) i bezpiecznego powłoki (SSH) do maszyn wirtualnych bez żadnych ekspozycji za pośrednictwem publicznych adresów IP. Opcjonalnie użyj Azure Bastion i podsieci, aby uzyskać rozszerzony dostęp zabezpieczeń do dowolnego węzła roboczego lub opcjonalnych maszyn przesiadkowych.

• SQL Managed Instance udostępnia zewnętrzne usługi danych mas, gdy firma IBM obsługuje SQL Server dla wdrażanych aplikacji. Możesz również wybrać inną bazę danych, taką jak Oracle Exadata lub IBM Db2 Warehouse. Azure SQL Database nie jest obsługiwana.

• Usługa Twilio SendGrid wysyła wiadomości e-mail od MAS do swoich klientów. Jeśli wdrożenie MAS wymaga usługi poczty e-mail na potrzeby scenariuszy wysyłania powiadomień i pracowników, opcjonalnie uwzględnij usługę poczty e-mail, taką jak Twilio SendGrid w projekcie.

Alternatywy

Następujące usługi zazwyczaj nie są niezbędne, ale są skutecznymi alternatywami:

• Azure NetApp Files jako zamiennik Azure Files. Azure NetApp Files obsługuje obciążenia wymagające wysokiej dostępności i wysokiej wydajności.
• Baza danych Oracle Database w usłudze Azure, jeśli jest obsługiwana i wolisz.
• OpenShift Data Foundation , jeśli chcesz użyć usługi Db2 Warehouse w usłudze OpenShift Data Foundation.

Szczegóły scenariusza

Ibm Maximo Application Suite to platforma do zarządzania zasobami przedsiębiorstwa z konserwacją zasobów opartą na sztucznej inteligencji. Platforma MAS koncentruje się na odporności operacyjnej i niezawodności. Pakiet składa się z podstawowej platformy aplikacji MAS oraz następujących aplikacji i rozwiązań specyficznych dla branży, które są tworzone na platformie.

• Maximo Manage. Zmniejsza przestoje i koszty dzięki zarządzaniu zasobami w celu zwiększenia wydajności operacyjnej.
• Maximo Monitor. Korzysta z Internetu rzeczy (IoT) do zaawansowanego monitorowania zasobów zdalnych opartych na sztucznej inteligencji na dużą skalę.
• Maximo Health. Zarządza kondycją zasobów przy użyciu danych IoT z czujników, danych zasobów i historii konserwacji.
• Maximo Visual Inspection. Trenuje modele uczenia maszynowego do korzystania z inspekcji wizualnej na potrzeby wizualnej analizy pojawiających się problemów.
• Maximo Predict(Przewidywanie Maximo). Przewiduje przyszłe awarie przy użyciu uczenia maszynowego i analizy danych.
• Maximo Współpracuj. Obsługuje techników ze wskazówkami opartymi na sztucznej inteligencji z bazy wiedzy danych dotyczących konserwacji sprzętu i zapewnia zdalny dostęp do ekspertów.
• Maximo Health, Safety and Environment (HSE). Łączy bezpieczeństwo, zgodność środowiskową i procesy kontroli pracy z elementami zawartości, lokalizacjami i zamówieniami pracy.
• Maximo Civil Infrastructure. Integruje działania związane z inspekcją, śledzeniem wad i konserwacją w celu poprawy życia zasobów, utrzymania krytycznych systemów operacyjnych i obniżenia całkowitych kosztów posiadania infrastruktury cywilnej.
• Maximo Nieruchomości i obiekty. Zarządza portfelami nieruchomości i zasobami obiektów przy użyciu zarządzania przestrzenią, rezerwacji, projektów kapitałowych, oceny warunków obiektów, zarządzania dzierżawami, operacji i konserwacji.

Potencjalne przypadki użycia

Wiele branż i sektorów korzysta z rozwiązań MAS, takich jak następujące obszary:

• Energetyka i usługi użyteczności publicznej
• Przemysł naftowy
• Produkcja
• Podróże, samochody i transport
• Sektor publiczny

Aby uzyskać więcej informacji na temat przypadków użycia mas, zobacz IBM Maximo Application Suite w witrynie internetowej IBM.

Zalecenia

Ten artykuł został napisany dla bieżących obsługiwanych wdrożeń mas 9.x w Azure. Microsoft współpracowała z zespołem IBM MAS i innymi partnerami, aby upewnić się, że to rozwiązanie jest skonfigurowane do optymalnego działania i zapewnia najlepsze środowisko Azure. Ta dokumentacja, architektura i wskazówki są zgodne z najlepszymi rozwiązaniami opisanymi w przewodniku Microsoft Azure Well-Architected Framework. Skontaktuj się z zespołem ds. kont IBM, aby uzyskać pytania specyficzne dla produktu i pomoc techniczną poza tą dokumentacją.

Skorzystaj z tego artykułu, aby uzyskać wskazówki dotyczące architektury, jeśli masz pomoc techniczną od firmy IBM i partnera do instalacji. Azure również oferuje ścieżkę instalacji dla usługi MAS, która obsługuje wprowadzanie własnej licencji. Aby uzyskać więcej informacji, zobacz IBM Maximo Application Suite (bring your own license (BYOL)).

Zainstaluj obsługiwaną wersję mas, która jest wyświetlana jako zgodna z wybraną wersją openShift i aplikacjami MAS. W przypadku nowych wdrożeń Azure użyj usługi ARO jako preferowanej platformy OpenShift, chyba że potrzebujesz własnego klastra zarządzanego.

Zgodność z obsługą platformy OpenShift zależy od trzech nakładających się granic pomocy technicznej: zgodność z rozwiązaniem IBM MAS, obsługa cyklu życia oprogramowania Red Hat OpenShift i dostępność wersji usługi ARO. Korzystanie z wersji OpenShift, której firma IBM nie wyświetla w raportach zgodności produktów oprogramowania (SPCR) lub poza systemem Red Hat lub ARO może pozostawić nieobsługiwane wdrożenie MAS.

Przed utworzeniem wdrożenia zapoznaj się z omówieniem pakietu IBM Maximo Application Suite, Planowanie instalacji na Microsoft Azure i dokumentacją raportów zgodności produktów oprogramowania (SPCR), aby zrozumieć bieżące wymagania dotyczące wdrażania i konfiguracji.

Przed kontynuowaniem wdrażania odpowiedz na następujące pytania dotyczące projektu:

• Jakich aplikacji MAS potrzebujesz?
• Jakie zależności mają twoje aplikacje?
• Która wersja platformy OpenShift obsługuje wersję i aplikacje MAS?
• Czy usługa ARO spełnia twoje wymagania, czy potrzebujesz samodzielnego zarządzania rozwiązaniem Red Hat OpenShift w Azure?
• Jakich baz danych potrzebujesz?
• Jakiej liczby i rozmiarów maszyn wirtualnych potrzebujesz?
• Czy użytkownicy muszą łączyć się z sieci zewnętrznych?

Pakiet aplikacji Maximo

Przed sfinalizowanie architektury użyj bieżącej obsługiwanej wersji MAS 9.x i zweryfikuj obsługiwane wersje, bazy danych i zależności openShift w usłudze IBM SPCR. Jeśli korzystasz ze starszej wersji pakietu Maximo Application Suite, zapoznaj się ze stanem cyklu życia ibm i zaplanuj uaktualnienie do obsługiwanej wersji MAS 9.x.

Zapoznaj się z aplikacjami MAS potrzebnymi do kompletnego scenariusza biznesowego, a następnie zapoznaj się z wymaganiami dotyczącymi poszczególnych aplikacji. Aby uzyskać więcej informacji, zobacz Wymagania systemowe pakietu IBM Maximo Application Suite.

Każda aplikacja MAS może potrzebować oddzielnej bazy danych. Spróbuj zewnętrznych baz danych, jeśli firma IBM obsługuje zewnętrzną bazę danych dla aplikacji, ponieważ takie podejście zmniejsza ilość stanu, który należy wykonać wewnątrz biblioteki OpenShift. Microsoft i ibm przetestowane i obsługują następujące bazy danych dla rozwiązania MAS w Azure:

• SQL Managed Instance
• IBM Db2 Warehouse on Cloud Pak for Data 5

Azure SQL Database i Azure Cosmos DB nie są obsługiwane.

Możesz również uruchomić narzędzie Oracle Exadata w infrastrukturze Oracle Cloud Infrastructure lub na maszynie wirtualnej przy użyciu połączeń. Ta konfiguracja nie jest oficjalnie testowana, ale podobno zakończyła się pomyślnie. Aby uzyskać więcej informacji na temat wzajemnych połączeń, zobacz Interconnecting Oracle Cloud with Microsoft Azure (Łączenie chmury Oracle Cloud z Microsoft Azure.

Platforma MAS i niektóre z jej aplikacji są zależne od baz danych MongoDB i platformy Kafka. Użyj domyślnych wdrożeń bazy danych MongoDB Community Edition i Strimzi Kafka w klastrze IBM, gdy pasują one do wymagań dotyczących obsługi, tworzenia kopii zapasowych i odzyskiwania. Ten wybór jest odpowiedni, gdy platforma Kafka i baza danych MongoDB są wewnętrznymi zależnościami MAS, a rozwiązanie nie korzysta z nich poza platformą MAS.

Spróbuj użyć zewnętrznych usług zarządzanych, takich jak MongoDB Atlas w usłudze Azure lub Confluent Cloud w Azure, gdy potrzebujesz silniejszej kopii zapasowej, skalowania lub odzyskiwania po awarii. Niektóre wymagania wstępne mas, takie jak usługi Behavior Analytics Services (BAS), używają baz danych, które nie mogą być zewnętrzne, ale wymagają przechowywania trwałego magazynu w klastrze OpenShift.

W przypadku usług opartych na stanie, które działają wewnątrz klastra OpenShift, regularnie twórz kopie zapasowe danych i przenoszą kopie zapasowe do innego regionu. Projektowanie, planowanie i podejmowanie decyzji o strategii odzyskiwania dla awarii, zwłaszcza w przypadku uruchamiania platformy Kafka lub bazy danych MongoDB wewnątrz platformy OpenShift. W przypadku usług, które zachowują stan, należy użyć ofert platformy jako usługi (PaaS) zewnętrznych Azure, jeśli to możliwe, aby zwiększyć możliwości obsługi podczas awarii.

Niektóre usługi mogą wymagać innych narzędzi i usług IBM, takich jak IBM Watson Machine Learning i IBM App Connect. Wszystkie te narzędzia i usługi można wdrożyć w tym samym klastrze OpenShift.

Azure Red Hat OpenShift

Użyj ARO jako preferowanej platformy OpenShift dla platformy MAS w Azure. Usługa ARO udostępnia zarządzaną usługę OpenShift na Azure, co zmniejsza obciążenie operacyjne związane z instalowaniem, stosowaniem poprawek i obsługą platformy OpenShift. Nadal posiadasz usługę MAS i jej konfigurację aplikacji, planowanie pojemności procesu roboczego, integrację sieci, integrację tożsamości, opcje magazynowania, ochronę danych i odzyskiwanie po awarii.

Przed wdrożeniem rozwiązania MAS w usłudze ARO należy wziąć pod uwagę następujące zalecenia:

• Zgodność wersji. Wybierz wersję platformy OpenShift, którą firma IBM wyświetla jako obsługiwaną dla używanej wersji mas i wybranych aplikacji MAS. Upewnij się, że ta sama wersja platformy OpenShift jest dostępna i obsługiwana przez usługę ARO w twoim regionie docelowym Azure. Jeśli to możliwe, wybierz parzystą wersję platformy OpenShift dla produkcyjnych wdrożeń MAS, ponieważ są to wersje rozszerzonej pomocy technicznej (EUS).

  Sprawdź krzyżowo, czy firma IBM obsługuje wybraną wersję openShift dla wszystkich wybranych aplikacji MAS i zależności. Jeśli składnik MAS wyświetla nowszą wersję z numerem nieparzystym openShift jako wymaganie w usłudze IBM SPCR, przed wybraniem wersji klastra zweryfikuj pełny zestaw składników dla usług IBM SPCR, obsługę cyklu życia oprogramowania Red Hat i dostępność wersji usługi ARO.

• Ścieżka wdrożenia. Użyj istniejącego klastra usługi ARO, jeśli masz już istniejące Azure strefy docelowej, sieci, tożsamości, magazynu i kontrolek operacyjnych. Użyj ścieżki instalacji ibm Azure Marketplace, jeśli chcesz, aby automatyzacja zapewniana przez firmę IBM umożliwiała tworzenie lub ponowne używanie obsługiwanej infrastruktury OpenShift. Używaj samoobsługowego rozwiązania Red Hat OpenShift na Azure tylko wtedy, gdy usługa ARO nie spełnia Twoich wymagań.

• Wybór regionu. Jeśli to możliwe, użyj regionu, w którym są strefy dostępności . Skonfiguruj węzły robocze usługi ARO w różnych strefach, gdy region docelowy obsługuje ten wzorzec. W przypadku samoobsługowego rozwiązania OpenShift skonfiguruj plik instalacyjny install-config.yaml, aby platforma OpenShift umieszczała węzły w różnych strefach. Jeśli w strefie wystąpi awaria, rozwiązanie może nadal działać, ponieważ węzły w innych strefach przejmą pracę.

• Tworzenie kopii zapasowych i odzyskiwanie. Możesz użyć Azure Red Hat OpenShift instrukcji dotyczących tworzenia kopii zapasowych i odzyskiwania. Aby uzyskać więcej informacji, zobacz Tworzenie kopii zapasowej aplikacji klastra Azure Red Hat OpenShift 4. Jeśli używasz tej metody do tworzenia kopii zapasowych i odzyskiwania, musisz podać inną metodę odzyskiwania po awarii dla bazy danych.

• Failover. Rozważ wdrożenie rozwiązania OpenShift w dwóch regionach i użycie rozwiązania Red Hat Advanced Cluster Management. Jeśli twoje rozwiązanie ma publiczne punkty końcowe, możesz umieścić Azure Traffic Manager między punktami końcowymi a Internetem, aby przekierować ruch do odpowiedniego klastra w regionalnej awarii. W takiej sytuacji należy również migrować stany aplikacji i woluminy trwałe.

Self-managed OpenShift

Użyj samoobsługowego rozwiązania Red Hat OpenShift na Azure, jeśli usługa ARO nie spełnia wymagań dotyczących kontroli, izolacji lub rozłączenia wdrożenia. W przypadku wdrożeń zarządzanych samodzielnie wybierz między następującymi metodami instalacji:

• Infrastruktura aprowizowana instalatora (IPI) Ta metoda używa instalatora do wdrażania i konfigurowania środowiska OpenShift w Azure. Użyj interfejsu IPI, gdy spełnia wymagania dotyczące zabezpieczeń i sieci.

• Infrastruktura aprowizowana przez użytkownika (UPI). Ta metoda umożliwia precyzyjną kontrolę nad wdrożeniem. Funkcja UPI wymaga większej liczby kroków i zagadnień dotyczących tworzenia środowiska. Użyj interfejsu UPI, jeśli interfejs IPI lub usługa ARO nie spełnia Twoich potrzeb. Prywatna lub rozłączona instalacja jest typowym przypadkiem użycia dla interfejsu UPI.

Instalacja rozciągnięta powietrzem

Niektóre przypadki, takie jak zgodność z przepisami, mogą wymagać instalacji mas w sposób rozmazywany w powietrzu w Azure. Air-gapped oznacza, że nie ma przychodzącego ani wychodzącego dostępu do Internetu. Bez połączenia z Internetem instalacja nie może pobrać zależności instalacji MAS ani OpenShift w czasie wykonywania.

Należy użyć instalacji rozszytej w powietrzu tylko wtedy, gdy jest to wymaganie bezpieczeństwa. Luka powietrzna zwiększa znaczącą złożoność operacji rozwiązania. Działania takie jak instalowanie oprogramowania, dublowanie kontenerów, aktualizowanie dublowania w celu ochrony przed lukami w zabezpieczeniach lub zarządzanie zaporami mogą zużywać znaczne nakłady pracy operacyjnej.

Aby uzyskać więcej informacji na temat instalacji rozszczepowanych w powietrzu, zobacz następującą dokumentację oprogramowania Red Hat OpenShift dotyczącą rozłączonych instalacji i klastrów prywatnych w Azure:

• Dublowanie obrazów dla rozłączonej instalacji przy użyciu narzędzia oc-mirror
• Instalowanie klastra prywatnego w Azure

Po zakończeniu instalacji openShift z przerwą w powietrzu możesz kontynuować pracę z dokumentacją mas, aby uzyskać wskazówki dotyczące odłączonych środowisk.

Ustalanie rozmiaru węzła i środowiska

W przypadku wszystkich obciążeń z wyjątkiem inspekcji wizualnej Maximo zacznij od rodzin maszyn wirtualnych serii Ds lub Das serii Ds, takich jak Dsv6, które są dostępne jako węzły robocze w wybranym regionie. Wybierz rozmiary maszyn wirtualnych, które obsługują magazyn w warstwie Premium i spełniają wymagania dotyczące procesora CPU, pamięci i magazynu dla wdrażanych aplikacji MAS.

Maximo Visual Inspection wymaga, aby węzły procesora GPU wykonywały uczenie maszynowe. Rozwiązanie korzysta z architektury CUDA i obsługuje tylko procesory GPU FIRMY NVIDIA. W przypadku usługi ARO wybierz rozmiar maszyny wirtualnej procesora GPU FIRMY NVIDIA z bieżącej listy obsługi węzła roboczego usługi ARO, a następnie upewnij się, że firma IBM obsługuje ją dla wersji MAS i OpenShift. W przypadku samoobsługowego rozwiązania OpenShift wybierz rozmiar maszyny wirtualnej procesora GPU FIRMY NVIDIA obsługiwany przez firmy IBM i Red Hat.

W przypadku węzłów roboczych procesora GPU zacznij od najmniejszego węzła i skaluj w górę w miarę wzrostu wymagań.

W przypadku usługi ARO i samoobsługowego rozwiązania OpenShift użyj tych samych wskazówek dotyczących określania rozmiaru obciążenia MAS dla węzłów roboczych. Skonfiguruj węzły procesu roboczego w różnych strefach dostępności , aby obsługiwać wysoką dostępność. W przypadku samoobsługowego rozwiązania OpenShift skonfiguruj również płaszczyznę sterowania między strefami dostępności. Użyj następującego punktu początkowego:

• Węzły sterujące. W przypadku usługi ARO płaszczyzna sterowania jest zarządzana w ramach usługi. W przypadku samoobsługowego rozwiązania OpenShift użyj co najmniej jednej maszyny wirtualnej na strefę dostępności w wybranym regionie.

• Węzły pracownicze. Użyj co najmniej dwóch maszyn na strefę dostępności w wybranym regionie. Rozmiar węzłów roboczych na podstawie wskazówek FIRMY IBM, wybranych aplikacji MAS i oczekiwanego obciążenia.

Rdzeń MAS wymaga 13 procesorów wirtualnych w przypadku instalacji podstawowej o standardowym rozmiarze. Określenie rozmiaru węzłów roboczych zależy od tego, które aplikacje MAS są wdrażane przez twoją konfigurację oraz od obciążenia środowiska. Na przykład maximo Manage dla 10 użytkowników wymaga kolejnych 2 procesorów wirtualnych. Traktuj te wartości jako punkty początkowe i zweryfikuj rozmiar zgodnie z bieżącymi wymaganiami systemowymi pakietu IBM Maximo Application Suite dla wersji MAS 9.x, wybranych aplikacji i oczekiwanego użycia.

W przypadku samoobsługowego rozwiązania OpenShift spróbuj zachować typy maszyn wirtualnych podobne do siebie, aby zapewnić bliskość każdej ze stref dostępności między węzłami roboczymi i kontrolnymi. W przypadku usługi ARO dostosuj pule węzłów procesu roboczego do tych samych wymagań dotyczących obciążenia MAS i Azure pojemności regionalnej.

Jeśli potrzebujesz serwera przesiadkowego, aby użyć interfejsu wiersza polecenia openShift oc lub zainstalować platformę MAS, wdróż obsługiwaną maszynę wirtualną z systemem Linux spełniającą wymagania administracyjne i wymagania dotyczące zabezpieczeń organizacji.

Konfiguracja sieci

W przypadku usługi ARO użyj domyślnej konfiguracji sieci openShift wdrażanej przez usługę ARO, chyba że IBM, Red Hat i twój zespół ds. sieci zweryfikuj inną opcję. Zaplanuj sieć wirtualną i oddzielne podsieci dla węzłów płaszczyzny sterowania usługi ARO, węzłów procesu roboczego, zależności usługi Azure, prywatnych punktów końcowych, baz danych i łączności hybrydowej. Umożliwia ustawianie rozmiaru podsieci węzłów dla potrzebnych węzłów roboczych openShift, w tym pojemności uaktualnienia i przyszłego skalowania w poziomie.

W przypadku samoobsługowego rozwiązania OpenShift należy również uwzględnić wymagania dotyczące infrastruktury utworzonej przez instalatora i bootstrap. Zachowaj dostęp administracyjny do interfejsu API openShift i węzłów ograniczony do zatwierdzonych ścieżek sieciowych, takich jak łączność hybrydowa, zabezpieczone hosty skokowe lub inne kontrolki wymagane przez organizację. Jeśli ograniczysz ruch wychodzący klastra, zaplanuj wymagane zależności wychodzące dla usług OpenShift, instalacji MAS, ściągania obrazu kontenera, aktualizacji, monitorowania i usług zewnętrznych.

W przypadku standardowej instalacji produkcyjnej MAS w usłudze ARO nie należy rozpoczynać się od ściśle zapakowanej sieci wirtualnej. Zarezerwuj większą przestrzeń adresową, taką jak prefiks routingu bezklasowego Inter-Domain (CIDR) /16, gdy zezwala na to strefa docelowa, i przydzielaj dedykowane podsieci. Użyj co najmniej /24 rozmiar planowania dla podsieci płaszczyzny sterowania ARO i co najmniej /24 rozmiar planowania dla podsieci węzła procesu roboczego. Dodaj podsieć /27 lub większą dla prywatnych punktów końcowych i zewnętrznych usług baz danych. Jeśli opcjonalnie wdrożysz Azure Bastion, dodaj podsieć o nazwie AzureBastionSubnet z prefiksem /26. Aby uzyskać więcej informacji na temat wymagań dotyczących Azure Bastion, zobacz Architektura.

Jeśli używasz self-managed OpenShift i brakuje adresów IP, możesz zaprojektować konfigurację o wysokiej dostępności z minimalnym prefiksem /27 dla podsieci węzła sterowania i /27 dla podsieci węzła procesu roboczego. Nie używaj tego ograniczonego określania rozmiaru jako punktu początkowego wdrożenia produkcyjnego usługi ARO. Nie należy zwiększać rozmiaru sieci wirtualnej ani podsieci węzłów. Odinstalowywanie wdrożenia openShift po zakończeniu instalacji jest zakłócające i może wymagać ponownego wdrożenia.

Jeśli chcesz użyć innego interfejsu sieciowego kontenera (CNI), odpowiednio rozmiesz swoje sieci. Rozwiązanie MAS z niektórymi standardowymi aplikacjami wdraża ponad 800 zasobników, które prawdopodobnie wymagają prefiksu CIDR /21 lub większego.

Specyfika bazy danych

Niektóre składniki MAS używają bazy danych MongoDB jako magazynu metadanych. Domyślne wskazówki dotyczą wdrażania bazy danych MongoDB Community Edition w klastrze. Jeśli używasz tej metody, upewnij się, że masz odpowiednią procedurę tworzenia kopii zapasowej i przywracania bazy danych. Rozważ użycie usługi MongoDB Atlas w Azure w celu zapewnienia magazynu zewnętrznego, kopii zapasowych i skalowania. Azure obecnie nie obsługuje używania interfejsów API bazy danych MongoDB z Azure Cosmos DB.

W przypadku wdrażania usług IoT należy również podać punkt końcowy platformy Kafka. Domyślne wskazówki dotyczą wdrażania platformy Kafka w klastrze OpenShift przy użyciu narzędzia Strimzi, ale dane w usłudze Strimzi prawdopodobnie zostaną utracone podczas odzyskiwania po awarii. Jeśli utrata danych na platformie Kafka jest niedopuszczalna, rozważ użycie platformy Confluent Kafka w Azure. Obecnie Azure Event Hubs nie jest obsługiwana w przypadku punktów końcowych platformy Kafka.

Platforma MAS zawiera kilka baz danych w zasobnikach, a te bazy danych zachowują swoje stany w systemie plików udostępnionym dla platformy MAS. Aby wychłonąć awarie stref, użyj mechanizmu magazynu strefowo nadmiarowego (ZRS), aby zachować stany poza klastrami. Zalecanym wzorcem jest użycie usługi Azure File Storage z następującymi konfiguracjami:

• Standard zapewnia udziały SMB dla obciążeń ReadWriteOnce (ReadWriteOnce, ReadWriteOnce, ReadWriteOnce). Użyj warstwy Standardowa dla części aplikacji, które nie zapisują w magazynie często i wymagają pojedynczego trwałego woluminu, takiego jak magazyn jednopoziomowy IBM.

• Usługa Premium udostępnia udziały NFS w celu zwiększenia przepływności i obciążeń ReadWriteMany (RWX). Woluminy takie jak te są używane w całym klastrze dla obciążeń RWX, takich jak Db2 Warehouse w usłudze Cloud Pak for Data lub Postgres in Maximo Manage.

Azure Files NFS obsługuje szyfrowanie podczas przesyłania. Jeśli klient MAS OpenShift nie może używać szyfrowania NFS, możesz wykluczyć konto z zasad bezpiecznego wymuszania transferu. Aby uzyskać więcej informacji, zobacz NFS Azure udziały plików: Szyfrowanie. Użyj prywatnego punktu końcowego , aby zapewnić prywatną łączność z udziałami.

Jeśli wdrożysz magazyn Db2 za pomocą pakietu Cloud Pak for Data, użyj narzędzia OpenShift Data Foundation. Aby zapoznać się z przykładem openShift Data Foundation korzystającym z klas magazynu Ceph File System (CephFS) i RADOS Block Device (Ceph RBD) dla różnych typów danych magazynu Db2, zobacz Tworzenie wystąpienia db2 przy użyciu konsoli Cloud Pak for Data.

Nie używaj Azure Blob Storage ze sterownikami interfejsu CSI (Container Storage Interface), ponieważ nie obsługuje twardych linków, które wymagają uruchomienia niektórych zasobników.

Kwestie wymagające rozważenia

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

Niezawodność

Platforma OpenShift ma wbudowane funkcje samonaprawiania, skalowania i odporności. OpenShift i MAS oczekują, że składniki kończą się niepowodzeniem i odzyskiwaniem. Kluczowym wymaganiem do samonaprawiania jest to, że klaster ma wystarczającą liczbę węzłów roboczych. Aby odzyskać z awarii strefy w regionie Azure, węzły kontrolne i robocze muszą być równomiernie rozprowadzone po strefach dostępności.

Mas i OpenShift używają magazynu do utrwalania stanu poza klastrem Kubernetes. Aby upewnić się, że zależności magazynu będą nadal działać podczas awarii, użyj magazynu strefowo nadmiarowego zawsze, gdy jest to możliwe. Magazyn strefowo nadmiarowy pozostaje dostępny w przypadku awarii pojedynczej strefy.

Aby zapobiec błędowi ludzkiemu, należy wdrożyć rozwiązanie MAS przy użyciu jak największej ilości automatyzacji. Użyj bieżącej dokumentacji instalacji ibm i obsługiwanej automatyzacji dla wybranej wersji MAS, platformy OpenShift i ścieżki wdrożenia.

Zabezpieczenia

Zabezpieczenia zapewniają ochronę przed celowymi atakami i nieprawidłowym użyciem cennych danych i systemów. Aby uzyskać więcej informacji, zobacz Lista kontrolna przeglądu projektu dotycząca zabezpieczeń.

Utrzymanie dostępu i wglądu w cykl życia konserwacji zasobów może być jedną z największych możliwości organizacji w zakresie wydajnego działania i utrzymania czasu pracy. Aby poprawić poziom bezpieczeństwa środowiska, ważne jest, aby używać bezpiecznego uwierzytelniania i aktualizować rozwiązania. Użyj szyfrowania, aby chronić wszystkie dane, które przemieszczają się do i z twojej infrastruktury.

Korzystając z wdrożeń usługi ARO, korzystasz z modelu wspólnej odpowiedzialności usługi ARO. Azure Red Hat OpenShift jest wspólnie zaprojektowana, obsługiwana i obsługiwana przez Microsoft i Red Hat, którzy poprawki, aktualizowanie i monitorowanie zarządzanej platformy OpenShift w Twoim imieniu. Nadal ponosisz odpowiedzialność za wdrożenia w usłudze ARO. Ta odpowiedzialność obejmuje usługę MAS i jej konfigurację aplikacji, integrację tożsamości, kontrolę sieci, planowanie pojemności procesu roboczego, opcje magazynowania, tworzenie kopii zapasowych i odzyskiwanie po awarii, wpisy tajne, ochronę danych i wymagania dotyczące zgodności. Aby uzyskać więcej informacji, zobacz Wprowadzenie do zasadpomocy technicznej Azure Red Hat OpenShift i Azure Red Hat OpenShift 4.0.

Microsoft tworzy zabezpieczenia na platformie Azure na następujących poziomach:

• Fizyczne centrum danych
• Sieć fizyczna
• Host fizyczny
• Hypervisor

Użyj wersji OpenShift obsługiwanej przez platformę OpenShift i obsługiwanej przez firmę IBM dla używanej wersji i aplikacji MAS. Jeśli to możliwe, użyj obsługiwanej długoterminowej wersji pomocy technicznej. Jeśli używasz samoobsługowego rozwiązania OpenShift, odpowiadasz za stosowanie poprawek i konserwowanie platformy OpenShift i bazowych maszyn wirtualnych. Jeśli używasz usługi ARO, Microsoft obsługuje stosowanie poprawek i zarządzanie nimi.

Użyj sieciowych grup zabezpieczeń, aby filtrować ruch sieciowy do i z zasobów w sieci wirtualnej. Korzystając z tych grup, można zdefiniować reguły, które udzielają lub odmawiają dostępu do usług MAS, takich jak:

• Zezwalanie na dostęp SSH do węzłów openShift na potrzeby rozwiązywania problemów.
• Blokowanie dostępu do wszystkich innych części klastra.
• Kontrolowanie lokalizacji, które mogą uzyskiwać dostęp do usługi MAS i klastra OpenShift.

Aby uzyskać dostęp do maszyn wirtualnych, możesz nawiązać połączenie za pośrednictwem łączności hybrydowej lub konsoli administracyjnej platformy OpenShift. Jeśli masz wdrożenie online lub nie chcesz polegać na łączności hybrydowej, możesz uzyskać dostęp do maszyn wirtualnych za pośrednictwem Azure Bastion. Ze względów bezpieczeństwa nie ujawniaj maszyn wirtualnych w sieci ani w Internecie bez konfigurowania sieciowych grup zabezpieczeń w celu kontrolowania dostępu.

Szyfrowanie po stronie serwera (SSE) Azure Disk Storage chroni dane i pomaga spełnić wymagania organizacji dotyczące zabezpieczeń i zgodności. W przypadku Azure dysków zarządzanych funkcja SSE szyfruje dane magazynowane podczas utrwalania ich w chmurze. To zachowanie ma zastosowanie domyślnie zarówno do dysków systemu operacyjnego, jak i danych. Usługa OpenShift domyślnie używa protokołu SSE.

Uwierzytelnianie

Usługa MAS obsługuje logowanie jednokrotne z językiem SAML (Security Assertion Markup Language). Aby użyć Microsoft Entra ID jako dostawcy tożsamości SAML, utwórz aplikację dla przedsiębiorstw w Microsoft Entra ID i skonfiguruj mas jako dostawcę usług. Aby uzyskać więcej informacji, zobacz integracja SSO Microsoft Entra z pakietem Maximo Application Suite.

Przed skonfigurowaniem uwierzytelniania opartego na protokole SAML zapoznaj się zarówno z konfiguracją firmy IBM, jak i konfiguracją Azure. Aby uzyskać informacje o protokole SAML z mas, zobacz Konfigurowanie uwierzytelniania SAML. Aby uzyskać informacje o protokole SAML z Azure, zobacz Quickstart: Włączanie logowania jednokrotnego dla aplikacji dla przedsiębiorstw.

Należy również skonfigurować protokół OAuth dla dostępu administracyjnego openShift. Aby uzyskać informacje na temat usługi ARO, zobacz Konfigurowanie uwierzytelniania Microsoft Entra dla klastra Azure Red Hat OpenShift. Aby samodzielnie zarządzać usługą OpenShift, zobacz Configuring identity providers in OpenShift Container Platform 4.21 (Konfigurowanie dostawców tożsamości w usłudze OpenShift Container Platform 4.21).

Dostęp do zasobów i inspekcja

Kontrolowanie dostępu do wdrażanych zasobów Azure. Każda subskrypcja Azure ma relację zaufania z dzierżawą Microsoft Entra. Stosując kontrolę dostępu opartą na rolach na platformie Azure, przyznaj użytkownikom w organizacji odpowiednie uprawnienia do zasobów platformy Azure. Udziel dostępu, przypisując role Azure użytkownikom lub grupom w określonym zakresie, takim jak subskrypcja, grupa zasobów lub pojedynczy zasób. Przeprowadź inspekcję wszystkich zmian w infrastrukturze. Aby uzyskać więcej informacji na temat inspekcji, zobacz Azure Monitor dziennik aktywności.

Optymalizacja kosztów

Optymalizacja kosztów koncentruje się na sposobach zmniejszenia niepotrzebnych wydatków i poprawy wydajności operacyjnej. Aby uzyskać więcej informacji, zobacz Lista kontrolna przeglądu projektu dotycząca optymalizacji kosztów.

Standardowe wdrożenie mas w Azure obejmuje następujące podstawowe czynniki kosztów:

• Koszty klastra ARO, w tym węzły procesu roboczego i wszelkie rozliczane opłaty za płaszczyznę sterowania lub klaster
• Pule węzłów procesu roboczego dla platformy MAS Core i wdrażanych aplikacji MAS
• Opcjonalne węzły robocze procesora GPU na potrzeby inspekcji wizualnej Maximo
• Usługi baz danych, takie jak SQL Managed Instance, Db2 Warehouse lub inna baza danych obsługiwana przez firmę IBM
• Konta magazynu lub zarządzane usługi magazynu dla trwałych woluminów, kopii zapasowych i artefaktów instalacji
• Strefy DNS, równoważenie obciążenia, prywatne punkty końcowe i opcjonalne wystąpienie Azure Bastion

W przypadku usługi ARO i samoobsługowego rozwiązania OpenShift standardowe wdrożenie MAS zwykle używa tego samego punktu odniesienia określania rozmiaru węzła roboczego. Użyj następującego spisu jako punktu wyjścia do szacowania kosztów:

• Sześć maszyn wirtualnych procesów roboczych.
• Trzy maszyny wirtualne procesu roboczego dla magazynu Db2. Możesz zastąpić SQL Managed Instance w niektórych konfiguracjach zamiast używać usługi Db2 Warehouse.
• Dwa konta Azure Storage.
• Dwie strefy DNS.
• Dwa moduły równoważenia obciążenia.
• Azure Bastion.
• Jeden węzeł roboczy procesora GPU z inspekcją wizualną Maximo, jeśli planujesz uruchomić inspekcję wizualną Maximo wewnątrz mas.

Koszt płaszczyzny sterowania różni się od modelu wdrażania. W przypadku wdrożeń samoobsługowych openShift korzystających z interfejsu IPI lub UPI obejmują również trzy maszyny wirtualne sterowania. W przypadku usługi ARO należy uwzględnić zarządzaną płaszczyznę sterowania i wszelkie opłaty za klaster specyficzny dla usługi ARO zamiast dodawać maszyny wirtualne sterowania zarządzane przez klienta.

Możesz przejrzeć przykładowe oszacowanie przy użyciu kalkulatora kosztów. Konfiguracje różnią się, dlatego przed sfinalizowaniem wdrożenia zweryfikuj konfigurację z zespołem ds. określania rozmiaru ibm.

Wdrażanie tego scenariusza

Przed rozpoczęciem zapoznaj się z wymaganiami systemowymi pakietu IBM Maximo Application Suite i usługą IBM SPCR dla używanej wersji i aplikacji MAS. Przed rozpoczęciem wdrażania dostępne są następujące zasoby:

• Dostęp do subskrypcji Azure z uprawnieniem Czytelnik
• Rejestracja aplikacji lub nazwa główna usługi z uprawnieniami współautora i administratora dostępu użytkowników do subskrypcji
• Domena lub poddomena delegowana do strefy Azure DNS
• Obsługiwany klaster ARO lub uprawnienia i wymagania wstępne dotyczące tworzenia
• Wpis tajny ściągania z oprogramowania Red Hat, jeśli ścieżka wdrożenia tworzy infrastrukturę OpenShift lub zarządza nią
• Klucz uprawnień MAS
• Plik licencji MAS utworzony po instalacji mas
• Ustalanie rozmiaru klastra zalecanego przez firmę IBM
• Istniejąca sieć wirtualna lub nowa sieć wirtualna spełniająca wymagania dotyczące usług ARO i MAS
• Wymagania dotyczące wysokiej dostępności i odzyskiwania po awarii dla określonego wdrożenia
• Szczegóły konfiguracji wybranej ścieżki wdrożenia, takie jak szczegóły klastra ARO lub parametry instalacji rozwiązania OpenShift zarządzane samodzielnie

Przed utworzeniem środowiska zapoznaj się z dokumentacją dotyczącą planowania ibm, aby zainstalować je w Microsoft Azure, aby poznać parametry projektu. Aby uzyskać bieżące wskazówki dotyczące instalacji Azure, zobacz Maximo Application Suite on Microsoft Azure overview (Pakiet aplikacji Maximo w Microsoft Azure omówienie). Zweryfikuj proces wdrażania pod kątem bieżącej dokumentacji firmy IBM i macierz obsługi używanej wersji rozwiązania MAS.

Uwagi dotyczące wdrażania

Wdrażanie obciążeń przy użyciu infrastruktury jako kodu (IaC) zamiast ręcznego. Wdrożenie ręczne może spowodować błędną konfigurację. Obciążenia oparte na kontenerach mogą być wrażliwe na błędną konfigurację, co może zmniejszyć produktywność.

FIRMA IBM oferuje specjalistyczne usługi ułatwiające instalację. Skontaktuj się z zespołem IBM, aby uzyskać pomoc techniczną.

Współautorzy

Microsoft utrzymuje ten artykuł. Następujący współautorzy napisali ten artykuł.

Główni autorzy

• David Baumgarten | Główny architekt
• Roeland Nieuwenhuis | Główny architekt

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

Następne kroki

Aby uzyskać pomoc dotyczącą rozpoczynania pracy, zobacz następujące zasoby:

• Azure Red Hat OpenShift
• Pakiet aplikacji Maximo w Microsoft Azure omówienie
• Planowanie instalacji w Microsoft Azure
• Instalowanie platformy OpenShift na platformie Azure
• OpenShift UPI Guide
• Wymagania dotyczące Maximo
• Raporty zgodności produktów IBM Software
• IBM Maximo Application Suite (BYOL)

Aby dowiedzieć się więcej o polecanych technologiach, zobacz następujące zasoby:

• IBM Passport Advantage
• Introduction do Azure DNS
• Wprowadzenie do Azure NetApp Files
• Wprowadzenie do Azure Red Hat OpenShift
• Portal klienta usługi Red Hat

Powiązane zasoby

• Udostępnianie plików w chmurze Azure dla przedsiębiorstw
• Deployowanie aplikacji Java za pomocą platformy aplikacji JBoss dla przedsiębiorstw (EAP) w klastrze ARO