Wdrażanie pakietu APLIKACJI IBM Maximo na platformie Azure

Azure Files
Azure Load Balancer
Azure Red Hat OpenShift
Azure Virtual Machines
Azure Virtual Network

IBM Maximo Application Suite (MAS) 8.Środowisko x działa w usłudze OpenShift i warto zapoznać się z usługą OpenShift i sugerowanymi wzorcami instalacji na platformie Azure. Aby uzyskać więcej informacji, zobacz Przygotowywanie do instalacji na platformie Azure. Ta architektura ilustruje klaster OpenShift. Nie zawiera szczegółowych informacji na temat sposobu instalowania rozwiązania MAS. Aby dowiedzieć się więcej na temat procesu instalacji, zobacz Instalowanie pakietu aplikacji Maximo z witryny OperatorHub.

Architektura

Diagram architektury przedstawiający składniki i usługi, które obsługują wdrażanie pakietu IBM Maximo Application Suite na platformie Azure.

Pobierz plik programu Visio z tą architekturą.

Obciążenie można wdrożyć wewnętrznie lub zewnętrznie w zależności od wymagań.

Przepływ pracy

Z perspektywy infrastruktury ta architektura zapewnia następujące elementy:

  • Platforma hostingu kontenerów do wdrażania obciążeń o wysokiej dostępności w różnych strefach dostępności
  • Sprywatyzowane wdrożenie węzłów roboczych i kontrolnych, które są zintegrowane z magazynem
  • Usługa Azure Premium Files i pliki standardowe dla magazynu (platforma OpenShift Data Foundation nie jest wymagana)
  • Program SQL Server na maszynach wirtualnych platformy Azure lub kontenerach firmy IBM Db2 Warehouse
  • Usługa Azure DNS do zarządzania usługą DNS platformy OpenShift i jej kontenerami
  • Microsoft Entra ID na potrzeby logowania jednokrotnego do usługi MAS

Składniki

  • Usługa Azure Virtual Machines do hostowania platformy OpenShift i uruchamiania kontenerów Maximo. Usługa Virtual Machines to oferta typu infrastruktura jako usługa (IaaS). Za pomocą usługi Virtual Machines można wdrażać skalowalne zasoby obliczeniowe na żądanie.

  • System Red Hat Enterprise Linux CoreOS udostępnia niestandardowy obraz maszyny wirtualnej dla platformy OpenShift.

  • Moduły równoważenia obciążenia platformy Azure w celu zapewnienia łączności z klastrem. Usługa Azure Load Balancer to usługa równoważenia obciążenia w warstwie 4 o wysokiej wydajności o wysokiej wydajności (ruch przychodzący i wychodzący) dla wszystkich protokołów UDP i TCP. Jest on tworzony tak, aby obsługiwał miliony żądań na sekundę, zapewniając wysoką dostępność rozwiązania. Usługa Azure Load Balancer jest strefowo nadmiarowa, zapewniając wysoką dostępność w Strefy dostępności.

  • Sieć wirtualna do komunikacji między węzłami, usługami platformy Azure i potrzebami łączności hybrydowej. Sieć wirtualna to podstawowy blok konstrukcyjny dla sieci prywatnych na platformie Azure.

  • Usługa Azure Files hostuje dane stanowe dla baz danych i systemów w klastrze. Usługa Azure Files udostępnia w pełni zarządzane udziały plików w chmurze, które są dostępne za pośrednictwem protokołów SMB i NFS.

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

  • Usługa Azure Bastion (opcjonalnie) i podsieć, aby bezpiecznie uzyskać dostęp do dowolnych węzłów procesu roboczego lub opcjonalnych maszyn JumpBox. Azure Bastion to w pełni zarządzana usługa, która zapewnia bezpieczny i bezproblemowy dostęp RDP i SSH do maszyn wirtualnych bez ujawnienia za pośrednictwem publicznych adresów IP.

  • Program SQL Server w usłudze Azure Virtual Machines (opcjonalnie) program SQL Server na maszynach wirtualnych platformy Azure w celu zapewnienia usług danych mas. Baza danych może być również inna, np. Oracle Exadata lub IBM Db2 Warehouse. Usługi Azure SQL Database i Azure SQL Managed Instance nie są obecnie obsługiwane.

  • Usługa Twilio Send Grid (opcjonalnie) wysyła wiadomości e-mail z usługi MAS do użytkowników.

  • Maszyny wirtualne z systemem Linux na platformie Azure (opcjonalnie) w celu zapewnienia szybkiego dostępu do instalacji rozwiązania OpenShift. Za pomocą tej maszyny wirtualnej można również nawiązać połączenie z klastrem OpenShift i zarządzać nim, ponieważ zawiera on plik konfiguracji kubernetes po instalacji. Jeśli masz łączność sieciową ze środowiskiem platformy Azure, możesz przeprowadzić instalację z istniejącej maszyny.

Alternatywy

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

Szczegóły scenariusza

Ibm Maximo Application Suite (MAS), znany również jako Maximo, 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 i aplikacji oraz rozwiązań specyficznych dla branży na platformie. Każda aplikacja zapewnia określoną korzyść:

  • Zarządzanie. Skrócenie czasu pracy i kosztów przy użyciu zarządzania zasobami w celu zwiększenia wydajności operacyjnej.
  • Monitorowanie. Używanie IoT do zaawansowanego monitorowania zdalnego zasobów opartych na sztucznej inteligencji na dużą skalę.
  • Kondycja. Zarządzanie kondycją zasobów przy użyciu danych IoT z czujników, danych zasobów i historii konserwacji.
  • Inspekcja wizualna. Trenowanie modeli uczenia maszynowego w celu korzystania z inspekcji wizualnej na potrzeby wizualnej analizy pojawiających się problemów.
  • Przewidywanie. Przewidywanie przyszłych niepowodzeń przy użyciu uczenia maszynowego i analizy danych.
  • Pomoc. Wspomagaj techników, zapewniając wskazówki oparte na sztucznej inteligencji do baza wiedzy danych dotyczących konserwacji sprzętu i dając im zdalny dostęp do ekspertów.
  • Bezpieczeństwo. Zbieranie i analizowanie danych z czujników, dostarczanie danych kontekstowych i uzyskiwanie znaczących analiz.
  • Cywilny. Integrowanie działań związanych 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.

Te aplikacje i mas 8.X są testowane pod kątem użycia na platformie Azure. Firma Microsoft i zespół IBM Maximo nawiązali współpracowali, aby upewnić się, że to rozwiązanie jest skonfigurowane do optymalnego działania na platformie Azure. Ten artykuł zawiera projekt do uruchamiania rozwiązania MAS 8.x na platformie Azure dla klientów, którzy mają pomoc techniczną od firmy IBM i partnera do instalacji. Skontaktuj się z zespołem IBM w celu uzyskania pytań specyficznych dla produktu. Witryna Azure Marketplace oferuje alternatywną instalację rozwiązania MAS, która obsługuje wprowadzanie własnej licencji. Aby uzyskać więcej informacji, zobacz IBM Maximo Application Suite (BYOL).

Potencjalne przypadki użycia

Wiele branż i sektorów korzysta z rozwiązań w mas, takich jak:

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

Więcej informacji na temat przypadków użycia mas można znaleźć na stronie internetowej IBM Maximo Application Suite.

Zalecenia

Zalecamy zainstalowanie najnowszej stabilnej wersji oprogramowania MAS, ponieważ zapewnia ona najlepsze opcje integracji z platformą Azure. Zwróć szczególną uwagę na obsługiwane wersje biblioteki OpenShift, ponieważ obsługiwane wersje różnią się w zależności od określonej wersji rozwiązania MAS.

Korzystanie z wcześniejszych lub nowszych wersji głównych platformy OpenShift może spowodować rezygnację z oficjalnej obsługi mas. Przed utworzeniem własnego wdrożenia zalecamy użycie przewodnika Szybki start w celu wdrożenia rozwiązania MAS, aby zrozumieć, jak działa wdrożenie i konfiguracja. Wiedza na temat tego, jak to zrobić, przyspiesza tworzenie wymagań projektowych dotyczących implementacji. Aby uzyskać więcej informacji, zobacz Przewodnik Szybki start: Pakiet aplikacji Maximo na platformie Azure.

Ściśle współpracujemy z firmą IBM i innymi partnerami, aby upewnić się, że wskazówki, architektura i przewodnik Szybki start zapewniają najlepsze środowisko na platformie Azure. Postępują zgodnie z najlepszymi rozwiązaniami, jak opisano w witrynie Microsoft Azure Well-Architected Framework. Skontaktuj się z zespołem ds. kont IBM, aby uzyskać pomoc techniczną poza tą dokumentacją.

Przed kontynuowaniem wdrażania należy odpowiedzieć na następujące pytania dotyczące projektowania:

  • Jakich aplikacji MAS potrzebujesz?
  • Jakie zależności mają twoje aplikacje?
  • Jaka wersja platformy OpenShift jest wymagana?
  • Której metody instalacji biblioteki OpenShift należy użyć?
  • Jakie bazy danych są potrzebne?
  • Jakiej liczby i rozmiarów maszyn wirtualnych potrzebujesz?
  • Czy użytkownicy będą łączyć się z sieci zewnętrznych?

Pakiet aplikacji Maximo

Firma Microsoft przetestowała rozwiązanie MAS w wersji 8.5 lub nowszej na platformie Azure. Naszym zaleceniem jest użycie najnowszej wersji oprogramowania MAS, która jest w wersji 8.7.

Przejrzyj aplikacje MAS potrzebne do kompletnego scenariusza biznesowego, a następnie przejrzyj wymagania dla każdej aplikacji. Aby uzyskać więcej informacji, zobacz Wymagania systemowe pakietu IBM Maximo Application Suite. Każda z aplikacji może potrzebować oddzielnych baz danych. Przetestowaliśmy i obsługujemy następujące bazy danych na platformie Azure:

Możesz również uruchomić narzędzie Oracle Exadata na maszynie wirtualnej lub w infrastrukturze Oracle Cloud Infrastructure przy użyciu połączeń wzajemnych, ale nie jest to przetestowana konfiguracja. Aby uzyskać więcej informacji na temat wzajemnych połączeń, zobacz Dowiedz się więcej o połączeniu chmury Oracle Cloud z platformą Microsoft Azure. Obecnie usługi Azure SQL Database, Azure SQL Managed Instance i Azure Cosmos DB nie są obsługiwane.

Uwaga

W niektórych przypadkach nie można ponownie użyć bazy danych dla wielu aplikacji MAS z powodu konfliktu ustawień bazy danych. Na przykład nie można użyć tego samego magazynu IBM Db2 Warehouse for Health and Manage w połączeniu z monitorem. Można jednak mieszać różne produkty bazy danych, takie jak używanie programu SQL Server dla jednej aplikacji i usługi IBM Db2 Warehouse dla innej.

Aby uzyskać więcej informacji na temat wymagań bazy danych dla aplikacji kondycji, zobacz Konfigurowanie bazy danych dla programu Maximo Health.

Platforma MAS i niektóre z jej aplikacji mają zależności od bazy danych MongoDB i platformy Kafka. Zdecyduj, jak wdrożyć te rozwiązania na podstawie zagadnień dotyczących wydajności i operacji. Wartością domyślną jest wdrożenie bazy danych MongoDB Community Edition i Strimzi Kafka w klastrach. Niektóre z wymagań wstępnych mas, na przykład BAS, używają baz danych, których nie można zewnętrznie używać, ale które wymagają przechowywania trwałego magazynu w klastrze OpenShift.

W przypadku usług opartych na stanie, które działają wewnątrz klastra OpenShift, konieczne jest częste tworzenie kopii zapasowych danych i przenoszenie kopii zapasowych do innego regionu. Zaprojektuj i zaplanuj strategię odzyskiwania w przypadku awarii i zdecyduj odpowiednio, zwłaszcza w przypadku uruchamiania platformy Kafka lub bazy danych MongoDB wewnątrz biblioteki OpenShift.

W przypadku usług, które zachowują stan, użyj zewnętrznych ofert platformy Azure jako usługi (PaaS), jeśli jest to możliwe. W ten sposób zwiększa się możliwość obsługi podczas awarii.

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

OpenShift

Uwaga

Pakiet IBM Maximo Application Suite obsługuje usługę Azure Red Hat OpenShift, pod warunkiem że bazowe wersje pakietu OpenShift i Cloud Pak for Data (CP4D) są zgodne.

Przed zainstalowaniem rozwiązania OpenShift należy określić, która metoda będzie używana:

  • Infrastruktura aprowizowana instalatora (IPI) Ta metoda używa instalatora do wdrażania i konfigurowania środowiska OpenShift na platformie Azure. IPI jest najbardziej typową metodą wdrażania na platformie Azure i należy użyć interfejsu IPI, chyba że wymagania dotyczące zabezpieczeń są zbyt rygorystyczne.

  • 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 nie spełnia Twoich potrzeb. Typowym przypadkiem użycia interfejsu UPI jest instalacja prywatna, rozstana z powietrzem. Wybierz pozycję UPI, jeśli nie masz wychodzącego dostępu do Internetu podczas kompilowania środowiska.

Zalecamy używanie interfejsu IPI zawsze, gdy jest to możliwe, ponieważ znacznie zmniejsza ilość pracy wymaganej do ukończenia instalacji rozwiązania OpenShift.

Uwaga

Po zainstalowaniu platformy OpenShift właściciel płaszczyzny sterowania jest odpowiedzialny za konserwowanie i skalowanie węzłów procesu roboczego na platformie Azure. Rozmiar klastra można zwiększyć przy użyciu zestawów maszyn w konsoli administracyjnej, a nie za pośrednictwem witryny Azure Portal. Aby uzyskać więcej informacji, zobacz Tworzenie zestawu maszyn na platformie Azure.

Podczas instalowania rozwiązania OpenShift należy rozwiązać następujące kwestie:

  • Wybór regionu. Zalecamy używanie regionu ze strefami dostępności. Podczas wdrażania usługa OpenShift automatycznie próbuje utworzyć węzły między strefami na podstawie konfiguracji w pliku konfiguracji install-config.yaml. Domyślnie usługa OpenShift równoważy obciążenia we wszystkich dostępnych węzłach i w różnych strefach dostępności. Jeśli w strefie wystąpi awaria, rozwiązanie może nadal działać, mając węzły w innych strefach, które mogą przejąć pracę.

  • Tworzenie kopii zapasowych i odzyskiwanie. Możesz użyć instrukcji dotyczących usługi Azure Red Hat OpenShift na potrzeby tworzenia kopii zapasowych i odzyskiwania. Aby uzyskać więcej informacji, zobacz Tworzenie kopii zapasowej aplikacji klastra usługi 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.

  • Tryb 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ć usługę Azure Traffic Manager między nimi i Internetem, aby przekierować ruch do odpowiedniego klastra, gdy wystąpi awaria regionu. W takiej sytuacji należy również migrować stany aplikacji i woluminy trwałe.

Instalacje rozsyłane powietrzem

W niektórych przypadkach, takich jak zgodność z przepisami, może być wymagana instalacja mas na platformie Azure z przerwą w powietrzu. Wyzłomione powietrze oznacza, że nie ma dostępu przychodzącego ani wychodzącego do Internetu. Bez połączenia z Internetem instalacja nie może pobrać zależności instalacji w czasie wykonywania instalacji oprogramowania MAS lub OpenShift.

Uwaga

Wdrożenia rozszyte w powietrzu wymagają instalowania interfejsu UPI . Nie zostały one jednak w pełni przetestowane.

Nie zalecamy wykonywania instalacji z przerwą w powietrzu, chyba że jest to wymaganie bezpieczeństwa. Luka powietrzna zwiększa znaczącą złożoność działania rozwiązania. Działania takie jak instalowanie oprogramowania, dublowanie kontenerów, aktualizowanie dublowania w celu ochrony przed lukami w zabezpieczeniach i zarządzanie zaporą mogą być bardzo czasochłonne.

Aby uzyskać więcej informacji na temat instalacji rozszczepionych w powietrzu, zobacz następującą dokumentację platformy OpenShift:

Po zainstalowaniu rozwiązania OpenShift zapoznaj się z dokumentacją platformy MAS, aby uzyskać podobne wskazówki.

Zmiana rozmiaru środowiska

W przypadku wszystkich obciążeń (z wyjątkiem inspekcji wizualnej) zalecamy używanie najnowszych maszyn wirtualnych serii Ds jako węzłów procesu roboczego. Przykłady to Dsv3, Dasv4, Dsv4, Dasv5 lub Dsv5. Zalecamy używanie najnowszych wersji, jeśli to możliwe, ponieważ zapewniają lepszą wydajność. Używaj tylko maszyn wirtualnych z magazynem w warstwie Premium.

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. Zalecane typy maszyn wirtualnych to NCv3 i NCasT4_v3. Jeśli musisz trenować przy użyciu YOLOv3, potrzebujesz procesorów GPU opartych na ampere. W przypadku większych zadań szkoleniowych użyj NVadsA10 v5 lub NC A100 v4.

W przypadku maszyn z procesorem GPU zalecamy rozpoczęcie od najmniejszego węzła i skalowanie w górę w miarę wzrostu wymagań.

Ostrzeżenie

Jeśli potrzebujesz maszyn gpu, potrzebujesz biblioteki OpenShift 4.8.22 jako minimalnej wersji, aby włączyć procesory GPU za pośrednictwem operatora procesora GPU firmy NVIDIA.

W przypadku wszystkich innych maszyn zalecamy skonfigurowanie maszyn wirtualnych w różnych strefach dostępności w celu zapewnienia wysokiej dostępności. Skonfiguruj węzły w następujący sposób:

  • Węzły sterujące. Co najmniej jedna maszyna wirtualna na strefę dostępności w wybranym regionie. Zalecamy liczbę procesorów wirtualnych co najmniej 4. Nasze odwołanie używa 3x Standard_D8s_v4 węzłów.

  • Węzły robocze. Co najmniej dwie maszyny na strefę dostępności w wybranym regionie. Zalecamy użycie liczby procesorów wirtualnych co najmniej 8. Nasze odwołanie używa 6x Standard_D8s_v4 węzłów.

Rdzeń MAS wymaga 13 procesorów wirtualnych w przypadku instalacji podstawowej o standardowym rozmiarze. Ustalanie rozmiaru węzłów roboczych zależy od tego, które aplikacje MAS wdrażają konfigurację i obciążenie środowiska. Na przykład zarządzanie dla 10 użytkowników wymaga kolejnych 2 procesorów wirtualnych. Zalecamy przejrzenie wymagań systemowych pakietu IBM Maximo Application Suite w celu uzyskania dobrego oszacowania rozmiaru.

Staraj się 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. Oznacza to, że jeśli używasz maszyny wirtualnej w wersji 4 dla węzłów sterowania, użyj również maszyny wirtualnej w wersji 4 dla węzłów procesu roboczego.

Jeśli potrzebujesz serwera przesiadkowego, aby użyć interfejsu wiersza polecenia OpenShift (oc) lub zainstalować rozwiązanie MAS, wdróż maszynę wirtualną z systemem Red Hat Enterprise Linux w wersji 8.4.

Sieć

W przypadku platformy OpenShift używamy domyślnego dostawcy interfejsu sieciowego kontenera (CNI) sieci zdefiniowanej programowo (SDN) platformy OpenShift. Aby uzyskać więcej informacji na temat domyślnego interfejsu CNI openShift, zobacz Operator sieci klastra na platformie kontenera OpenShift. Należy określić rozmiar sieci dla wymaganej liczby potrzebnych węzłów roboczych i kontrolek OpenShift, a także dla innych wymagań, takich jak bazy danych i konta magazynu.

W przypadku standardowej instalacji produkcyjnej MAS zalecamy sieć wirtualną z przestrzenią adresową, którą zapewnia prefiks CIDR /24. Sieć wirtualna ma trzy lub cztery podsieci (dla usługi Bastion). W przypadku rozwiązania OpenShift podsieć węzłów procesu roboczego ma prefiks CIDR /25, a węzły sterowania mają prefiks /27. Podsieć dla punktów końcowych i opcjonalny zewnętrzny serwer bazy danych powinien mieć prefiks /27. Jeśli wdrażasz usługę Azure Bastion, która jest opcjonalna, potrzebna jest podsieć o nazwie AzureBastionSubnet z prefiksem /26. Aby uzyskać więcej informacji na temat wymagań usługi Azure Bastion, zobacz Architektura.

Jeśli brakuje ci adresów IP, możesz zaimplementować konfigurację o wysokiej dostępności z minimalnym prefiksem /27 dla podsieci węzłów sterowania i /27 dla podsieci węzłów procesu roboczego.

Jeśli chcesz użyć innej sieci CNI, odpowiednio rozmiesz swoje sieci. Platforma 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

Różne 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 wdrożysz ją przy użyciu tej metody, upewnij się, że masz właściwą procedurę tworzenia kopii zapasowej i przywracania bazy danych. Rozważ użycie usługi MongoDB Atlas na platformie Azure, ponieważ zapewnia ona magazyn zewnętrzny, kopie zapasowe, skalowanie i nie tylko. Platforma Azure nie obsługuje obecnie używania interfejsów API bazy danych MongoDB w usłudze Azure Cosmos DB.

W przypadku wdrażania usług IoT wymagane jest również podanie punktu końcowego platformy Kafka. Domyślne wskazówki dotyczą wdrażania platformy Kafka w klastrze OpenShift przy użyciu narzędzia Strimzi. Podczas odzyskiwania po awarii dane w usłudze Strimzi najprawdopodobniej zostaną utracone. Jeśli utrata danych na platformie Kafka jest niedopuszczalna, rozważ użycie platformy Confluent Kafka na platformie Azure. Obecnie usługa Azure Event Hubs z punktami końcowymi platformy Kafka nie jest obsługiwana.

Platforma MAS jest dostarczana z wieloma bazami danych w zasobnikach, a bazy danych zachowują swoje stany w systemie plików udostępnianym przez usługę MAS. Zalecamy użycie mechanizmu magazynu strefowo nadmiarowego, aby zachować stany poza klastrami, aby móc absorbować awarie stref. Naszym zalecanym wzorcem jest użycie usługi Azure File Storage z następującymi konfiguracjami:

  • Standardowa. Udostępnia udziały bloku komunikatów serwera (SMB, Server Message Block) dla obciążeń o mniejszej przepływności i obciążeniach ReadWriteOnce (RWO). Standard jest doskonałym rozwiązaniem dla części aplikacji, które nie zapisują w magazynie często i wymagają pojedynczego trwałego woluminu (na przykład magazynu jednopoziomowego IBM).

  • Premium. Udostępnia udziały systemu plików sieciowych (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 magazyn Db2 w usłudze Cloud Pak for Data lub Postgres in Manage.

Pamiętaj, aby wyłączyć zasady wymuszania bezpiecznego transferu w usłudze Azure Blob Storage lub wykluczać konta z tych zasad. Usługa Azure Premium Files z systemem plików NFS wymaga wyłączenia bezpiecznego transferu. Pamiętaj, aby zagwarantować prywatną łączność z udziałami przy użyciu prywatnego punktu końcowego .

Domyślnie magazyn Db2 jest wdrażany na bazie danych OpenShift Data Foundation (wcześniej znanej jako OpenShift Container Storage). Ze względu na koszty, wydajność, skalowanie i niezawodność zalecamy używanie usługi Azure Premium Files z systemem plików NFS zamiast openShift Data Foundation.

Nie używaj obiektów blob platformy Azure ze sterownikami CSI, ponieważ nie obsługuje twardych linków, które są wymagane. Niektóre zasobniki nie mogą działać bez twardych linków.

Kwestie wymagające rozważenia

Te zagadnienia implementują filary platformy Azure Well-Architected Framework, 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.

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ń.

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 przechodzą do i z architektury.

Platforma Azure dostarcza mas przy użyciu modeli infrastruktury jako usługi (IaaS) i PaaS. Firma Microsoft tworzy zabezpieczenia w usłudze na następujących poziomach:

  • Fizyczne centrum danych
  • Sieć fizyczna
  • Host fizyczny
  • Funkcja hypervisor

Uważnie oceń usługi i technologie wybrane dla obszarów powyżej funkcji hypervisor, takich jak najnowsza poprawiona wersja rozwiązania OpenShift w wersji głównej. Pamiętaj, aby zapewnić odpowiednie mechanizmy kontroli zabezpieczeń dla architektury. Odpowiadasz za stosowanie poprawek i utrzymanie bezpieczeństwa systemów IaaS. Firma Microsoft przyjmuje to rolę dla usług PaaS.

Użyj sieciowych grup zabezpieczeń, aby filtrować ruch sieciowy do i z zasobów w sieci wirtualnej. Dzięki tym grupom można zdefiniować reguły, które udzielają lub odmawiają dostępu do usług MAS. Oto kilka przykładów:

  • Zezwalaj na dostęp SSH do węzłów openShift na potrzeby rozwiązywania problemów
  • Blokuj dostęp do wszystkich pozostałych części klastra
  • Kontrolowanie lokalizacji, które mogą mieć dostęp do usług MAS i klastra OpenShift

Jeśli z jakiegoś powodu potrzebujesz dostępu do maszyn wirtualnych, możesz nawiązać połączenie za pośrednictwem łączności hybrydowej lub za pośrednictwem konsoli administracyjnej openShift. Jeśli masz wdrożenie online lub nie chcesz polegać na łączności, możesz również uzyskać dostęp do maszyn wirtualnych za pośrednictwem usługi Azure Bastion (co jest opcjonalne). Ze względów bezpieczeństwa nie należy ujawniać maszyn wirtualnych w sieci ani w Internecie bez konfigurowania sieciowych grup zabezpieczeń w celu kontrolowania dostępu do nich.

Szyfrowanie po stronie serwera (SSE) usługi Azure Disk Storage chroni dane. Pomaga również spełnić wymagania organizacji dotyczące zabezpieczeń i zgodności. W przypadku dysków zarządzanych platformy Azure usługa 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 obecnie korzystanie z języka SAML (Security Assertion Markup Language) za pośrednictwem identyfikatora Entra firmy Microsoft. Aby wykonać tę pracę, potrzebujesz aplikacji dla przedsiębiorstw w ramach identyfikatora Microsoft Entra i uprawnienia do modyfikowania aplikacji lub pomocy administratora globalnego, który może wprowadzić niezbędne zmiany.

Przewodnik Szybki start w witrynie GitHub zawiera samouczek dotyczący konfigurowania protokołu SAML za pomocą rozwiązania MAS. Aby uzyskać więcej informacji, zobacz Włączanie uwierzytelniania SAML względem identyfikatora Entra firmy Microsoft.

Przed skonfigurowaniem uwierzytelniania opartego na protokole SAML zalecamy zapoznanie się z konfiguracją ibm i konfiguracją platformy Azure. Aby uzyskać informacje o protokole SAML z mas, zobacz SAML w dokumentacji dotyczącej rozwiązania MAS. Aby uzyskać informacje o protokole SAML z platformą Azure, zobacz Szybki start: włączanie logowania jednokrotnego dla aplikacji dla przedsiębiorstw.

Należy również skonfigurować protokół OAuth dla platformy OpenShift. Aby uzyskać więcej informacji, zobacz Omówienie uwierzytelniania i autoryzacji w dokumentacji usługi OpenShift.

Ochrona infrastruktury

Kontroluj dostęp do wdrażanych zasobów platformy Azure. Każda subskrypcja platformy Azure ma relację zaufania z dzierżawą firmy 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. Aby udzielić dostępu, przypisz role platformy Azure użytkownikom lub grupom w określonym zakresie. Zakres może być subskrypcją, grupą zasobów lub pojedynczym zasobem. Pamiętaj, aby przeprowadzić inspekcję wszystkich zmian w infrastrukturze. Aby uzyskać więcej informacji na temat inspekcji, zobacz Dziennik aktywności usługi Azure Monitor.

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.

Standardowe wdrożenie rozwiązania MAS składa się z następujących składników:

  • 3 maszyny wirtualne sterujące
  • 6 maszyn wirtualnych procesów roboczych
  • 3 maszyny wirtualne procesu roboczego dla usługi Db2 Warehouse
    • Program SQL Server można zastąpić na maszynach wirtualnych platformy Azure w niektórych konfiguracjach, zamiast używać usługi Db2 Warehouse.
  • 2 Konta usługi Azure Storage
  • 2 strefy DNS
  • 2 Moduły równoważenia obciążenia
  • Azure Bastion
  • 1 Maszyna wirtualna inspekcji wizualnej
    • Nie jest to wymagane, chyba że planujesz uruchomić inspekcję wizualną wewnątrz mas.

Możesz przejrzeć przykładowe oszacowanie, korzystając z kalkulatora kosztów. Konfiguracje różnią się i przed zakończeniem wdrażania należy zweryfikować konfigurację z zespołem ds. określania rozmiaru ibm.

Niezawodność

Platforma OpenShift ma wbudowane funkcje samonaprawiania, skalowania i odporności, aby upewnić się, że rozwiązania OpenShift i MAS działają pomyślnie. OpenShift i MAS zostały zaprojektowane pod kątem części, które kończą się niepowodzeniem i odzyskiwaniem. Kluczowym wymaganiem do samonaprawiania jest to, że istnieje wystarczająca liczba węzłów roboczych. Aby odzyskać odzyskiwanie po awarii strefy w regionie świadczenia usługi Azure, węzły kontroli i procesu roboczego muszą być zrównoważone w różnych 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, należy użyć magazynu strefowo nadmiarowego zawsze, gdy jest to możliwe. Ten typ magazynu pozostaje dostępny, gdy strefa ulegnie awarii.

Ponieważ błąd człowieka jest typowy, należy wdrożyć rozwiązanie MAS przy użyciu jak największej liczby automatyzacji. W naszym przewodniku Szybki start udostępniamy kilka przykładowych skryptów do konfigurowania pełnej, kompleksowej automatyzacji.

Wdrażanie tego scenariusza

Przed rozpoczęciem zalecamy przejrzenie wymagań systemowych pakietu IBM Maximo Application Suite. Przed rozpoczęciem wdrażania upewnij się, że masz dostępne następujące zasoby:

  • Dostęp do subskrypcji platformy Azure z uprawnieniami czytelnika
  • Rejestracja aplikacji lub nazwa główna usługi z uprawnieniami współautora i dostępu użytkowników Administracja istrator do subskrypcji
  • Domena lub domena podrzędna delegowana do strefy usługi Azure DNS
  • Ściąganie wpisu tajnego z oprogramowania Red Hat w celu wdrożenia rozwiązania OpenShift
  • 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 utworzona przez interfejs IPI w zależności od wymagań
  • Wymagania dotyczące wysokiej dostępności i odzyskiwania po awarii dla określonego wdrożenia
  • Plik konfiguracji install-config.yaml dla instalatora

Aby zapoznać się z przewodnikiem krok po kroku dotyczącym instalowania oprogramowania OpenShift i MAS na platformie Azure, w tym sposobu rozwiązywania wymagań wstępnych, zobacz nasz przewodnik Szybki start w witrynie GitHub.

Uwaga

Przewodnik Szybki start: pakiet aplikacji Maximo na platformie Azure zawiera przykład pliku install-config.yaml w pliku /src/ocp/.

Uwagi dotyczące wdrażania

Najlepszym rozwiązaniem jest wdrożenie obciążeń przy użyciu infrastruktury jako kodu (IaC), a nie ręcznego wdrażania obciążeń, ponieważ 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ść.

Przed utworzeniem środowiska zapoznaj się z przewodnikiem Szybki start, aby opracować opis parametrów projektu. Przewodnik Szybki start nie jest przeznaczony do wdrożenia gotowego do produkcji, ale możesz użyć zasobów przewodnika, aby przejść do mechanizmu klasy produkcyjnej na potrzeby wdrażania.

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

Współautorzy

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

Autorzy zabezpieczeń:

Inny współautor:

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

Następne kroki

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

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