편집

다음을 통해 공유


Azure에 IBM Maximo Application Suite 배포

Azure 파일
Azure Load Balancer
Azure Red Hat OpenShift
Azure Virtual Machines
Azure Virtual Network

IBM Maximo Application Suite(MAS) 8.x는 OpenShift에서 실행되고, OpenShift와 Azure에 설치를 위해 제안된 패턴을 익히는 것이 좋습니다. 자세한 내용은 Azure에 설치 준비를 참조하세요. 이 아키텍처는 OpenShift 클러스터를 보여 줍니다. MAS를 설치하는 방법을 자세히 설명하지는 않습니다. 설치 프로세스에 대해 자세히 알아보려면 OperatorHub에서 Maximo Application Suite 설치를 참조하세요.

아키텍처

Azure에 IBM Maximo Application Suite 배포를 지원하는 구성 요소 및 서비스를 보여 주는 아키텍처 다이어그램.

이 아키텍처의 Visio 파일을 다운로드합니다.

워크로드는 요구 사항에 따라 내부 또는 외부적으로 배포할 수 있습니다.

워크플로

인프라의 관점에서 이 아키텍처는 다음을 제공합니다.

  • 가용성 영역에 고가용성 워크로드를 배포하는 컨테이너 호스팅 플랫폼
  • 스토리지와 통합된 작업자 및 제어 노드의 개인화된 배포
  • Azure Files 프리미엄 및 스토리지용 표준 파일(OpenShift Data Foundation이 필요하지 않음)
  • Azure VM 또는 컨테이너 기반 IBM Db2 Warehouse에서 SQL Server
  • OpenShift 및 해당 컨테이너의 DNS 관리를 위한 Azure DNS
  • MAS로의 Single Sign-On을 위한 Microsoft Entra ID

구성 요소

  • OpenShift 플랫폼을 호스트하고 Maximo 컨테이너를 실행할 Azure Virtual Machines. Virtual Machines는 IaaS(Infrastructure-as-a-Service) 제품입니다. Virtual Machines를 사용하여 확장 가능한 주문형 컴퓨팅 리소스를 배포할 수 있습니다.

  • OpenShift에 대한 사용자 지정 VM 이미지를 제공하는 Red Hat Enterprise Linux CoreOS.

  • 클러스터에 대한 연결을 제공하는 Azure Load Balancer. Azure Load Balancer는 모든 UDP/TCP 프로토콜에 대한 대기 시간이 매우 낮은 고성능의 계층 4 부하 분산 서비스(인바운드 및 아웃바운드)입니다. 솔루션의 고가용성을 보장하면서 초당 수백만 개의 요청을 처리하도록 빌드되었습니다. Azure Load Balancer는 영역 중복으로, 가용성 영역에서 고가용성을 보장합니다.

  • 노드, Azure 서비스 및 하이브리드 연결 요구 사항 간의 통신을 위한 가상 네트워크. Virtual Network는 Azure의 개인 네트워크에 대한 기본 구성 요소입니다.

  • 클러스터 내 데이터베이스 및 시스템에 대한 상태 저장 데이터를 호스트하는 Azure Files. Azure Files는 클라우드에서 SMB 및 NFS(네트워크 파일 시스템) 프로토콜을 통해 액세스할 수 있는 완전 관리형 파일 공유를 제공합니다.

  • 솔루션 내부 및 외부 컨테이너에 대한 DNS 확인을 관리하는 Azure DNS. Azure DNS는 모든 일반적인 DNS 레코드를 지원하며 고가용성을 제공합니다.

  • 작업자 노드 또는 선택적 JumpBox 머신에 대해 보안이 강화된 액세스를 위한 Azure Bastion(선택 사항) 및 서브넷. Azure Bastion은 공용 IP 주소를 통해 노출하지 않고 VM에 원활하고 향상된 보안 RDP 및 SSH 액세스를 제공하는 완전 관리형 서비스입니다.

  • Azure Virtual Machines의 SQL Server(선택 사항)를 사용하여 MAS에 데이터 서비스를 제공합니다. 또한 데이터베이스는 Oracle Exadata 또는 IBM Db2 Warehouse와 같은 다른 데이터베이스일 수도 있습니다. Azure SQL Database 및 Azure SQL Managed Instance는 현재 지원되지 않습니다.

  • MAS에서 소비자에게 메일을 보내는 Twilio Send Grid(선택 사항).

  • OpenShift 설치를 위한 점프 상자를 제공하는 Azure의 Linux 가상 머신(선택 사항). 설치 후 Kubernetes 구성 파일이 포함되어 있으므로 이 VM을 사용하여 OpenShift 클러스터를 연결하고 관리할 수도 있습니다. Azure 환경에 네트워크 연결을 할 수 있는 경우 기존 머신에서 설치를 수행할 수 있습니다.

대안

일반적으로 다음 서비스는 필수적이지는 않지만, 효과적인 대안입니다.

시나리오 정보

Maximo로도 알려진 IBM의 Maximo Application Suite(MAS)는 AI 기반 자산 유지 관리가 포함된 엔터프라이즈 자산 관리 플랫폼입니다. MAS는 운영 복원력 및 안정성에 중점을 둡니다. 제품군은 핵심 애플리케이션 플랫폼, MAS, 플랫폼 위의 애플리케이션 및 산업별 솔루션으로 구성됩니다. 각 애플리케이션은 다음과 같은 특정 이점을 제공합니다.

  • 관리. 자산 관리를 사용하여 운영 성능을 개선하여 가동 중지 시간 및 비용을 줄입니다.
  • 모니터링. 대규모 원격 자산의 고급 AI 기반 모니터링에 IoT를 사용합니다.
  • 상태. 센서, 자산 데이터 및 유지 관리 기록의 IoT 데이터를 사용하여 자산 상태를 관리합니다.
  • 시각적 검사. 기계 학습 모델을 학습하여 새로운 문제에 대한 시각적 분석을 하는 데 시각적 검사를 사용합니다.
  • 예측. 기계 학습 및 데이터 분석을 사용하여 향후 오류를 예측합니다.
  • 지원. 장비 유지 관리 데이터의 기술 자료에 대한 AI 기반 지침을 제공하고 전문가에게 원격 액세스를 제공하여 기술자를 지원합니다.
  • 안전성. 센서에서 데이터를 수집 및 분석하고, 컨텍스트 데이터를 제공하고, 의미 있는 분석을 도출합니다.
  • 민간. 검사, 결함 추적 및 유지 관리 작업을 통합하여 자산 수명을 개선하고, 중요한 시스템 운영을 유지하고, 민간 인프라의 총 소유 비용을 낮춥니다.

이러한 애플리케이션 및 MAS 8.x는 Azure에서 사용하도록 테스트되었습니다. Microsoft와 IBM Maximo 팀은 이 솔루션이 Azure에서 최적으로 실행하도록 구성되도록 협력했습니다. 이 문서에서는 설치를 위해 IBM 및 파트너의 지원을 받는 고객에게 Azure에서 MAS 8.x를 실행하기 위한 디자인을 제공합니다. 제품 관련 질문은 IBM 팀에 문의하세요. 이 Azure Marketplace는 자신의 라이선스 가져오기를 지원하는 MAS에 대한 대체 설치를 제공합니다. 자세한 정보는 IBM Maximo Application Suite (BYOL(Bring Your Own License))를 참조하십시오.

잠재적인 사용 사례

다음과 같은 많은 산업 및 부문에서 MAS의 솔루션을 사용합니다.

  • 에너지 및 유틸리티
  • 석유 및 가스
  • 제조업
  • 여행, 자동차 및 운송
  • 공공 부문

IBM Maximo Application Suite에 있는 IBM 웹사이트에서 MAS의 사용 사례에 대한 자세한 내용을 찾아보세요.

권장 사항

Azure와 최상의 통합 옵션을 제공하는 MAS의 안정적인 최신 버전을 설치하는 것이 좋습니다. 지원되는 버전은 MAS의 특정 버전에 따라 다르므로 지원되는 OpenShift의 버전에 각별히 주의를 기울이세요.

이전 또는 이후의 OpenShift 주 버전을 사용하면 MAS에 대한 공식 지원이 중단될 수 있습니다. 자체 배포를 빌드하기 전에 빠른 시작 가이드를 사용하여 MAS를 배포하여 배포 및 구성의 작동 방식을 이해하는 것이 좋습니다. 이 작업이 수행되는 방법을 알면 구현에 대한 디자인 요구 사항을 빠르게 만들 수 있습니다. 자세한 내용은 빠른 시작 가이드: Azure의 Maximo Application Suite를 참조하세요.

당사는 IBM 및 기타 파트너와 긴밀히 협력하여 지침, 아키텍처 및 빠른 시작 가이드가 Azure에서 최상의 환경을 제공하도록 합니다. Microsoft Azure Well-Architected Framework에 설명된 모범 사례를 따릅니다. 이 설명서 이외의 지원을 받으려면 IBM 계정 팀에 문의하세요.

배포를 진행하기 전에 디자인에 대한 다음 질문에 대답해야 합니다.

  • 어떤 MAS 애플리케이션이 필요한가요?
  • 애플리케이션에 어떤 종속성이 있나요?
  • 어떤 버전의 OpenShift가 필요한가요?
  • 어떤 OpenShift 설치 방법을 사용해야 하나요?
  • 필요한 데이터베이스는 무엇인가요?
  • 필요한 VM의 개수와 크기는 무엇인가요?
  • 사용자가 외부 네트워크에서 연결할까요?

Maximo Application Suite

Microsoft는 Azure에서 MAS 버전 8.5 이상을 테스트했습니다. 최신 버전의 MAS(버전 8.7)를 사용하는 것이 좋습니다.

전체 비즈니스 시나리오에 필요한 MAS 애플리케이션을 검토한 다음 각 애플리케이션에 대한 요구 사항을 검토합니다. 자세한 내용은 IBM Maximo Application Suite 시스템 요구 사항을 참조하세요. 각 애플리케이션에는 별도의 데이터베이스가 필요할 수 있습니다. Azure에서 다음 데이터베이스를 테스트했고 지원합니다.

상호 연결을 사용하여 VM 또는 Oracle 클라우드 인프라에서 Oracle Exadata를 실행하도록 선택할 수도 있지만, 이 구성은 테스트되지 않았습니다. 상호 연결에 대한 자세한 내용은 Oracle Cloud와 Microsoft Azure의 상호 연결을 참조하세요. 현재 Azure SQL Database, Azure SQL Managed Instance 및 Azure Cosmos DB는 지원되지 않습니다.

참고 항목

경우에 따라 데이터베이스 설정이 충돌하여 여러 MAS 애플리케이션에 데이터베이스를 다시 사용할 수 없습니다. 예를 들어 모니터와 함께 Health와 Manage에 동일한 IBM Db2 Warehouse를 사용할 수 없습니다. 그러나 한 애플리케이션에는 SQL Server를 사용하고 다른 애플리케이션에는 IBM Db2 Warehouse를 사용하는 등 여러 데이터베이스 제품을 혼합할 수 있습니다.

Health 애플리케이션에 대한 데이터베이스 요구 사항에 대한 자세한 내용은 Maximo Health용 데이터베이스 구성을 참조하세요.

MAS 및 일부 애플리케이션은 MongoDB 및 Kafka에 종속되어 있습니다. 성능 및 작업의 고려 사항에 따라 이러한 솔루션을 배포하는 방법을 결정합니다. 기본값은 클러스터 내에 MongoDB Community Edition 및 Strimzi Kafka를 배포하는 것입니다. BAS와 같은 MAS의 일부 필수 구성 요소는 외부화할 수 없지만 OpenShift 클러스터에 영구 스토리지를 제공해야 하는 데이터베이스를 사용합니다.

OpenShift 클러스터 내에서 실행되는 상태 기반 서비스의 경우 데이터를 자주 백업하고 백업을 다른 지역으로 이동해야 합니다. 재해 발생 시 복구 전략을 설계 및 계획하고, 특히 OpenShift 내에서 Kafka 또는 MongoDB를 실행할 때 적절하게 결정합니다.

상태를 유지하는 서비스의 경우 가능하면 외부 Azure PaaS(Platform as a Service) 제품을 사용합니다. 이렇게 하면 가동 중단 시 지원 가능성이 향상됩니다.

일부 서비스에는 IBM Watson Machine Learning 및 IBM App Connect와 같은 다른 IBM 도구 및 서비스가 필요할 수 있습니다. 모든 도구와 서비스를 동일한 OpenShift 클러스터에 배포할 수 있습니다.

OpenShift

참고 항목

IBM Maximo Application Suite는 기본 버전의 OpenShift 및 CP4D(Cloud Pak for Data)가 정렬되는 경우 Azure Red Hat OpenShift를 지원합니다.

OpenShift를 설치하기 전에 사용할 방법을 결정해야 합니다.

  • IPI(설치 프로그램 프로비저닝 인프라). 이 방법은 설치 프로그램을 사용하여 Azure에서 OpenShift 환경을 배포하고 구성합니다. IPI는 Azure에 배포하기 위한 가장 일반적인 방법으로, 보안 요구 사항이 너무 엄격하지 않은 경우 IPI를 사용해야 합니다.

  • UPI(사용자 프로비저닝 인프라). 이 방법을 사용하면 배포를 세밀하게 제어할 수 있습니다. UPI에서는 환경을 빌드하기 위해 더 많은 단계와 고려 사항이 필요합니다. IPI가 요구 사항을 충족하지 않는 경우 UPI를 사용합니다. UPI의 일반적인 사용 사례는 비공개의 에어 갭 설치를 하는 경우입니다. 환경을 빌드할 때 아웃바운드 인터넷 액세스 권한이 없는 경우 UPI를 선택합니다.

IPI는 OpenShift 설치를 완료하는 데 필요한 작업의 양을 크게 줄일 수 있으므로 가능하면 이것을 사용하는 것이 좋습니다.

참고

OpenShift를 설치한 후 Azure에서 작업자 노드를 유지 관리하고 스케일링하는 일은 컨트롤 플레인의 소유자가 담당합니다. Azure Portal을 통해서가 아니라 관리 콘솔에서 머신 집합을 사용하여 클러스터 크기를 늘입니다. 자세한 내용은 Creating a machine set on Azure(Azure에 머신 집합 만들기)를 참조하세요.

OpenShift를 설치할 때 다음 고려 사항을 해결해야 합니다.

  • 지역 선택. 가용성 영역이 있는 지역을 사용하는 것이 좋습니다. 배포하는 동안 OpenShift는 구성 파일, install-config.yaml의 구성에 따라 자동으로 영역 간에 노드를 만들려고 합니다. 기본적으로 OpenShift는 사용 가능한 모든 노드와 가용성 영역에서 워크로드의 균형을 조절합니다. 영역에 중단이 있는 경우 작업을 인수할 수 있는 다른 영역에 노드가 있으면 솔루션은 계속 작동할 수 있습니다.

  • 백업 & 복구. 백업 및 복구를 위해 Azure Red Hat OpenShift에 대한 지침을 사용할 수 있습니다. 자세한 내용은 Azure Red Hat OpenShift 4 클러스터 애플리케이션 백업 만들기를 참조하세요. 백업 및 복구에 이 방법을 사용하는 경우 데이터베이스에 대한 다른 재해 복구 방법을 제공해야 합니다.

  • 장애 조치(Failover). 두 지역에 OpenShift를 배포하고 Red Hat Advanced Cluster Management를 사용해 보세요. 솔루션에 퍼블릭 엔드포인트가 있는 경우, 해당 엔드포인트와 인터넷 사이에 Azure Traffic Manager를 배치하여 한 지역에서 중단이 발생할 때 트래픽을 적절한 클러스터로 리디렉션할 수 있습니다. 이러한 상황에서는 애플리케이션의 상태 및 영구 볼륨도 마이그레이션해야 합니다.

에어 갭 설치

규정 준수와 같은 일부 경우에는 Azure에서 MAS의 에어 갭 설치가 필요할 수 있습니다. 에어 갭은 인바운드 또는 아웃바운드 인터넷 액세스가 없음을 의미합니다. 인터넷 연결이 없으면 설치 시 MAS 또는 OpenShift 설치를 위한 런타임에 설치 종속성을 검색할 수 없습니다.

참고

에어 갭 배포에는 설치를 위해 UPI가 필요합니다. 그러나 이러한 배포는 완전히 테스트되지는 않았습니다.

보안 요구 사항이 아니면 에어 갭 설치를 수행하지 않는 것이 좋습니다. 에어 갭은 솔루션 운영에 상당한 복잡성을 더합니다. 소프트웨어 설치, 컨테이너 미러링, 보안 취약성으로부터 보호하기 위해 미러 업데이트 및 방화벽 관리와 같은 작업은 시간이 매우 많이 걸릴 수 있습니다.

에어 갭 설치에 대한 자세한 내용은 다음 OpenShift 설명서를 참조하세요.

OpenShift를 설치한 후 비슷한 지침은 MAS 설명서를 참조하세요.

환경 크기 조정

시각적 검사를 제외한 모든 워크로드에는 최신 Ds 시리즈 VM을 작업자 노드로 사용하는 것이 좋습니다. 예로 Dsv3, Dasv4, Dsv4, Dasv5 또는 Dsv5가 있습니다. 최신 버전이 더 좋은 성능을 제공하므로, 가능하면 최신 버전을 사용하는 것이 좋습니다. Premium Storage가 있는 VM만 사용합니다.

Maximo Visual Inspection을 사용하려면 GPU 노드가 기계 학습을 수행해야 합니다. 이 솔루션은 CUDA를 사용하고 NVIDIA GPU만 지원합니다. 권장되는 VM 유형은 NCv3NCasT4_v3입니다. YOLOv3를 사용하여 학습해야 할 경우, Ampere 기반 GPU가 필요합니다. 대규모 학습 작업에는 NVadsA10 v5 또는 NC A100 v4를 사용합니다.

GPU 머신의 경우 가장 작은 노드부터 시작하여 요구 사항이 증가함에 따라 확장하는 것이 좋습니다.

경고

GPU 머신이 필요한 경우 NVIDIA GPU 연산자를 통해 GPU를 사용하도록 설정하려면 최소 버전으로 OpenShift 4.8.22가 필요합니다.

다른 모든 머신의 경우 가용성 영역에서 VM을 구성하여 고가용성을 지원하는 것이 좋습니다. 다음과 같이 노드를 구성합니다.

  • 제어 노드. 선택한 지역 내의 가용성 영역당 최소 VM 1개. vCPU 수는 4개 이상인 것이 좋습니다. 참조에서는 3x Standard_D8s_v4 노드를 사용합니다.

  • 작업자 노드 선택한 지역 내의 가용성 영역당 최소 머신 2대. vCPU 수는 8개 이상인 것이 좋습니다. 참조에서는 6x Standard_D8s_v4 노드를 사용합니다.

MAS 코어는 표준 크기의 기본 설치를 위해 13개의 vCPU가 필요합니다. 작업자 노드의 크기 조정은 구성이 배포하는 MAS 애플리케이션과 환경의 부하에 따라 달라집니다. 예를 들어 10명의 사용자에 대해 관리하려면 다른 2개의 vCPU가 필요합니다. IBM Maximo Application Suite 시스템 요구 사항을 검토하여 적절한 크기 조정 예상치를 얻는 것이 좋습니다.

VM 유형을 서로 비슷하게 유지하여 작업자와 제어 노드 간의 각 가용성 영역에 근접성을 제공해 보세요. 즉, 제어 노드에 v4 VM을 사용하는 경우 작업자 노드에도 v4 VM을 사용합니다.

OpenShift 명령줄 인터페이스(oc)를 사용하거나 MAS를 설치하기 위해 점프 상자가 필요한 경우 Red Hat Enterprise Linux 버전 8.4를 실행하는 VM을 배포합니다.

네트워크

OpenShift를 사용하면 OpenShift SDN(소프트웨어 정의 네트워킹)의 기본 CNI(컨테이너 네트워크 인터페이스) 공급자를 사용합니다. 기본 OpenShift CNI에 대한 자세한 내용은 OpenShift Container Platform의 클러스터 네트워크 운영자를 참조하세요. 필요한 OpenShift 제어 및 작업자 노드 수와 데이터베이스 및 스토리지 계정과 같은 다른 요구 사항에 맞게 네트워크의 크기를 조정해야 합니다.

표준 MAS 프로덕션 설치의 경우 클래스 없는 도메인 간 라우팅(CIDR) 접두사 /24가 제공하는 주소 공간이 있는 가상 네트워크를 사용하는 것이 좋습니다. 가상 네트워크에는 3개 또는 4개의 서브넷이 있습니다(Azure Bastion의 경우). OpenShift의 경우 작업자 노드의 서브넷에는 CIDR 접두사 /25가 있고 제어 노드에는 접두사 /27이 있습니다. 엔드포인트 및 선택적 외부 데이터베이스 서버에 대한 서브넷의 접두사는 /27이어야 합니다. 선택 사항인 Azure Bastion을 배포하는 경우 접두사 /26을 사용하는 AzureBastionSubnet이라는 서브넷이 필요합니다. Azure Bastion의 요구 사항에 대한 자세한 내용은 아키텍처를 참조하세요.

IP 주소가 부족한 경우 제어 노드의 서브넷에 대해 최소 접두사 /27, 작업자 노드의 서브넷에 대해 최소 접두사 /27을 사용하여 고가용성 구성을 구현할 수 있습니다.

다른 CNI를 사용하려는 경우 그에 따라 네트워크 크기를 조정합니다. 일부 표준 애플리케이션이 있는 MAS는 800개 이상의 Pod를 배포하며, 그래서 CIDR 접두사 /21 이상이 필요할 수 있습니다.

데이터베이스 세부 정보

MAS의 다양한 구성 요소는 MongoDB를 메타데이터 저장소로 사용합니다. 기본 지침은 클러스터 내에 MongoDB Community Edition을 배포하는 것입니다. 해당 방법을 사용하여 배포하는 경우 데이터베이스를 백업하고 복원하기 위한 적절한 절차가 있는지 확인합니다. MongoDB Atlas는 외부화된 저장소, 백업, 스케일링 등을 제공하기 때문에 Azure에서 이를 사용하는 것이 좋습니다. Azure는 현재 Azure Cosmos DB에서 MongoDB API 사용을 지원하지 않습니다.

IoT 서비스를 배포하는 경우 Kafka 엔드포인트도 제공해야 합니다. 기본 지침은 Strimzi를 사용하여 OpenShift 클러스터 내에 Kafka를 배포하는 것입니다. 재해 복구 중에 Strimzi 내의 데이터가 유실될 가능성이 높습니다. Kafka 내의 데이터 유실을 용인할 수 없다면 Azure에서 Confluent Kafka를 사용하는 것이 좋습니다. 현재 Kafka 엔드포인트가 있는 Azure Event Hubs는 지원되지 않습니다.

MAS는 Pod 내에 많은 데이터베이스로 채워져 있으며, 해당 데이터베이스는 MAS에 대해 제공되는 파일 시스템에서 상태를 유지합니다. 영역 중복 스토리지(ZRS) 메커니즘을 사용하여 영역 오류를 흡수할 수 있도록 클러스터 외부의 상태를 유지하는 것이 좋습니다. 권장되는 패턴은 다음 구성으로 Azure File Storage를 사용하는 것입니다.

  • 표준. 낮은 처리량 및 RWO(ReadWriteOnce) 워크로드를 위한 SMB(서버 메시지 블록) 공유를 제공합니다. 표준은 스토리지에 자주 쓰지 않고 단일 영구 볼륨(예: IBM 단일 수준 스토리지)이 필요한 애플리케이션의 부분에 매우 적합합니다.

  • 프리미엄. 높은 처리량 및 RWX(ReadWriteMany) 워크로드를 위한 NFS(네트워크 파일 시스템) 공유를 제공합니다. 이와 같은 볼륨은 Db2 Warehouse in Cloud Pak for Data 또는 Postgres in Manage와 같은 RWX 워크로드에 대한 클러스터 전체에서 사용됩니다.

Azure Blob Storage에 보안 전송을 적용하기 위한 정책을 사용하지 않도록 설정하거나 해당 정책에서 계정을 제외하세요. NFS를 사용하는 Azure Premium Files를 사용하려면 보안 전송을 사용하지 않도록 설정해야 합니다. 프라이빗 엔드포인트를 사용하여 공유에 대한 프라이빗 연결을 보장해야 합니다.

기본적으로 Db2 Warehouse는 OpenShift Data Foundation(이전에는 OpenShift Container Storage로 알려졌음) 위에 배포됩니다. 비용, 성능, 스케일링 및 안정성을 위해 OpenShift Data Foundation 대신 NFS와 함께 Azure Premium Files를 사용하는 것이 좋습니다.

Azure Blob Storage는 필요한 하드 링크를 지원하지 않으므로 CSI 드라이버와 함께 사용하지 마세요. 일부 Pod는 하드 링크 없이 실행할 수 없습니다.

고려 사항

이러한 고려 사항은 워크로드의 품질을 향상시키는 데 사용할 수 있는 일련의 기본 원칙인 Azure Well-Architected Framework의 핵심 요소를 구현합니다. 자세한 내용은 Microsoft Azure Well-Architected Framework를 참조하세요.

보안

우수한 보안은 중요한 데이터 및 시스템에 대한 고의적인 공격과 악용을 방어합니다. 자세한 내용은 보안 요소의 개요를 참조하세요.

자산의 유지 관리 수명 주기에 대한 액세스 및 가시성을 유지하는 것은 효율적으로 작동하고 가동 시간을 유지 관리할 수 있는 조직의 가장 큰 기회 중 하나일 수 있습니다. 환경의 보안 상태를 개선하려면 보안 인증을 사용하고 솔루션을 최신 상태로 유지하는 것이 중요합니다. 암호화를 사용하여 아키텍처에 들어오고 나가는 모든 데이터를 보호할 수 있습니다.

Azure는 IaaS(Infrastructure as a Service) 및 PaaS 모델을 사용하여 MAS를 제공합니다. Microsoft는 다음 수준에서 서비스에 보안 대책을 빌드합니다.

  • 실제 데이터 센터
  • 실제 네트워크
  • 물리적 호스트
  • 하이퍼바이저

주요 릴리스의 가장 최근에 패치된 OpenShift 버전과 같이 하이퍼바이저 위의 영역에 대해 선택한 서비스 및 기술을 신중하게 평가합니다. 아키텍처에 적절한 보안 장치를 제공해야 합니다. 사용자에게 IaaS 시스템의 보안을 패치하고 유지 관리할 책임이 있습니다. Microsoft는 PaaS 서비스에 대해 그러한 역할을 합니다.

가상 네트워크의 리소스에 들어오고 나가는 네트워크 트래픽을 필터링하려면 네트워크 보안 그룹을 사용합니다. 이러한 그룹을 사용하면 MAS 서비스에 대한 액세스 권한을 부여하거나 거부하는 규칙을 정의할 수 있습니다. 다음은 이러한 템플릿의 예입니다.

  • 문제 해결을 위해 OpenShift 노드에 대한 SSH 액세스 허용
  • 클러스터의 다른 모든 부분에 대한 액세스 차단
  • MAS 및 OpenShift 클러스터에 액세스할 수 있는 위치 제어

어떤 이유로 VM에 액세스해야 하는 경우 하이브리드 연결을 통해 또는 OpenShift 관리 콘솔을 통해 연결할 수 있습니다. 온라인 배포가 있거나 연결에 의존하지 않으려는 경우 Azure Bastion(선택 사항)을 통해 VM에 액세스할 수도 있습니다. 보안상의 이유로, VM에 대한 액세스를 제어하려면 네트워크 보안 그룹을 구성하지 않고 네트워크 또는 인터넷에 VM을 노출해서는 안 됩니다.

Azure Disk Storage의 SSE(서버 쪽 암호화)는 데이터를 보호합니다. 또한 조직의 보안 및 규정 준수 약정을 충족하는 데 도움이 됩니다. 데이터를 클라우드에 유지하는 경우 SSE는 Azure 관리 디스크를 사용하여 미사용 데이터를 암호화합니다. 이 동작은 OS 및 데이터 디스크 모두에 기본적으로 적용됩니다. OpenShift는 기본적으로 SSE를 사용합니다.

인증

MAS는 현재 Microsoft Entra ID에서 SAML(Security Assertion Markup Language)을 사용하는 SSO(Single Sign-On)를 지원합니다. 이 인증 방법을 사용하려면 Microsoft Entra ID 내의 엔터프라이즈 애플리케이션과 애플리케이션을 수정할 수 있는 권한이 필요합니다. 자세한 정보는 Maximo Application Suite와 Microsoft Entra SSO 통합을 참조하세요.

SAML 기반 인증을 설정하기 전에 IBM 구성 및 Azure 구성을 진행하는 것이 좋습니다. MAS를 사용하는 SAML에 대한 자세한 내용은 MAS에 대한 설명서에서 SAML을 참조하세요. Azure를 사용하는 SAML에 대한 자세한 내용은 빠른 시작: 엔터프라이즈 애플리케이션에 Single Sign-On 사용을 참조하세요.

OpenShift에 대한 Open Authorization (OAuth)도 구성해야 합니다. 자세한 내용은 OpenShift 설명서의 인증 및 권한 부여 개요를 참조하세요.

인프라 준비

배포하는 Azure 리소스에 대한 액세스를 제어합니다. 모든 Azure 구독은 Microsoft Entra 테넌트와 트러스트 관계가 있습니다. RBAC(Azure 역할 기반 액세스 제어)를 사용하여 조직 내의 사용자에게 Azure 리소스에 대한 올바른 사용 권한을 부여합니다. 특정 범위에서 사용자 또는 그룹에 Azure 역할을 할당하여 액세스를 부여합니다. 범위는 구독, 리소스 그룹 또는 단일 리소스일 수 있습니다. 인프라에 대한 모든 변경 내용을 감사해야 합니다. 감사에 대한 자세한 내용은 Azure Monitor 활동 로그를 참조하세요.

비용 최적화

비용 최적화는 불필요한 비용을 줄이고 운영 효율성을 높이는 방법을 찾는 것입니다. 자세한 내용은 비용 최적화 핵심 요소 개요를 참조하세요.

MAS의 표준 배포는 다음 구성 요소로 구성됩니다.

  • 제어 VM 3개
  • 작업자 VM 6개
  • Db2 Warehouse용 작업자 VM 3개
    • 일부 구성에서는 Db2 Warehouse를 사용하는 대신 Azure VM의 SQL Server로 대체할 수 있습니다.
  • Azure Storage 계정 2개
  • DNS 영역 2개
  • 부하 분산 장치 2개
  • Azure Bastion
  • 시각적 검사 VM 1개
    • MAS 내에서 시각적 검사를 실행하려는 경우가 아니면 이 작업은 필요하지 않습니다.

비용 계산기를 사용하여 예제 예측을 검토할 수 있습니다. 구성은 다양하며, 배포를 완료하기 전에 IBM 크기 조정 팀에서 구성을 확인해야 합니다.

안정성

OpenShift에는 OpenShift 및 MAS가 성공적으로 작동하도록 자동 복구, 스케일링 및 복원력을 위한 기본 제공 기능이 있습니다. OpenShift 및 MAS는 실패하고 복구하는 부품을 위해 설계되었습니다. 자동 복구가 작동하기 위해서는 작업자 노드가 충분히 있어야 합니다. Azure 지역 내의 영역 오류에서 복구하려면 제어 노드와 작업자 노드가 가용성 영역 간에 균형을 유지해야 합니다.

MAS 및 OpenShift는 스토리지를 사용하여 Kubernetes 클러스터 외부에서 상태를 유지합니다. 오류 발생 시 스토리지 종속성이 계속 작동하도록 하려면 가능한 영역 중복 스토리지를 사용하세요. 이러한 유형의 스토리지는 영역이 실패할 때도 계속 사용할 수 있습니다.

사용자 오류는 일반적이므로, 최대한 많은 자동화를 사용하여 MAS를 배포해야 합니다. 빠른 시작 가이드에서는 전체 엔드투엔드 자동화를 설정하기 위한 몇 가지 샘플 스크립트를 제공합니다.

시나리오 배포

시작하기 전에 IBM Maximo Application Suite 시스템 요구 사항을 검토하는 것이 좋습니다. 배포를 시작하기 전에 다음 리소스를 사용할 수 있는지 확인하세요.

  • 읽기 권한자 권한을 가진 Azure 구독에 대한 액세스
  • 구독에 대해 기여자 및 사용자 액세스 관리자 권한을 가지는 애플리케이션 등록 또는 서비스 사용자 이름
  • Azure DNS 영역에 대한 도메인 또는 위임된 하위 도메인
  • Red Hat에서 비밀을 끌어와서 OpenShift 배포
  • MAS 자격 키
  • MAS 라이선스 파일(MAS 설치 후 생성됨)
  • IBM 권장 클러스터 크기 조정
  • 요구 사항에 따라 기존 가상 네트워크 또는 IPI에서 만든 새 가상 네트워크
  • 특정 배포에 대한 고가용성 및 재해 복구 요구 사항
  • 설치 프로그램에 대한 구성 파일, install-config.yaml

필수 구성 요소를 해결하는 방법을 포함하여 Azure에 OpenShift 및 MAS를 설치하기 위한 단계별 가이드는 GitHub의 빠른 시작 가이드를 참조하세요.

참고

빠른 시작 가이드: Azure의 Maximo Application Suite에는 /src/ocp/install-config.yaml 파일 예가 포함되어 있습니다.

배포 고려 사항

수동 배포로 인해 구성이 잘못 될 수 있으므로 워크로드를 수동으로 배포하기 보다는 IaC(Infrastructure as Code)를 사용하여 워크로드를 배포하는 것이 가장 좋습니다. 컨테이너 기반 워크로드는 잘못된 구성에 민감하여 생산성을 줄일 수 있습니다.

환경을 빌드하기 전에 빠른 시작 가이드를 검토하여 디자인 매개 변수에 대한 이해를 높이세요. 빠른 시작 가이드는 프로덕션 준비 배포를 위한 것이 아니지만 가이드의 자산을 사용하여 배포를 위한 프로덕션급 메커니즘을 볼 수 있습니다.

IBM은 설치에 도움이 되는 전문 서비스를 제공합니다. 지원을 받으려면 IBM 팀에 문의하세요.

참가자

Microsoft에서 이 문서를 유지 관리합니다. 원래 다음 기여자가 작성했습니다.

주요 작성자:

기타 기여자:

비공개 LinkedIn 프로필을 보려면 LinkedIn에 로그인하세요.

다음 단계

시작에 대한 도움말은 다음 리소스를 참조하세요.

주요 기술에 대해 자세히 알아보려면 다음 리소스를 참조하세요.