Menyebarkan IBM Maximo Application Suite di Azure

IBM Maximo Application Suite (MAS) 8.x berjalan di OpenShift, dan bermanfaat untuk membiasakan diri dengan OpenShift dan pola yang disarankan untuk penginstalan di Azure. Untuk informasi selengkapnya, lihat Mempersiapkan penginstalan di Azure. Arsitektur ini menggambarkan kluster OpenShift. Ini tidak masuk ke detail tentang cara menginstal MAS. Untuk mempelajari selengkapnya tentang proses penginstalan, lihat Menginstal Maximo Application Suite dari OperatorHub.

Sistem

Unduh file Visio arsitektur ini.

Beban kerja dapat disebarkan secara internal atau eksternal, tergantung pada kebutuhan Anda.

Alur kerja

Dari perspektif infrastruktur, arsitektur ini menyediakan yang berikut:

• Platform hosting kontainer untuk menyebarkan beban kerja yang sangat tersedia di seluruh zona ketersediaan
• Penyebaran privatisasi simpul pekerja dan kontrol yang terintegrasi dengan penyimpanan
• Azure Premium Files dan file standar untuk penyimpanan (OpenShift Data Foundation tidak diperlukan)
• SQL Server di Azure VM atau Gudang IBM Db2 berbasis kontainer
• Azure DNS untuk manajemen DNS OpenShift dan kontainernya
• MICROSOFT Entra ID untuk akses menyeluruh ke MAS

Komponen

• Azure Virtual Machines untuk menghosting platform OpenShift dan menjalankan kontainer Maximo. Virtual Machines adalah penawaran infrastruktur sebagai layanan (IaaS). Anda dapat menggunakan Virtual Machines untuk menyebarkan sumber daya komputasi sesuai permintaan dan terukur.

• Red Hat Enterprise Linux CoreOS untuk menyediakan gambar VM kustom untuk OpenShift.

• Azure Load Balancer untuk menyediakan konektivitas ke dalam kluster. Azure Load Balancer adalah layanan penyeimbangan beban Lapisan 4 berperforma tinggi dengan latensi sangat rendah (masuk dan keluar) untuk semua protokol UDP dan TCP. Azure Load Balancer dibangun untuk menangani jutaan permintaan per detik sambil memastikan solusi Anda sangat tersedia. Azure Load Balancer bersifat zona-redundan, memastikan ketersediaan tinggi di seluruh Zona Ketersediaan.

• Virtual Network untuk komunikasi antara simpul, layanan Azure, dan kebutuhan konektivitas hibrid. Virtual Network adalah blok penyusun dasar untuk jaringan privat di Azure.

• Azure Files yang menghosting data stateful untuk database dan sistem di dalam kluster. Azure Files menyediakan berbagi file yang dikelola sepenuhnya di cloud yang dapat diakses melalui protokol SMB dan NFS.

• Azure DNS untuk mengelola resolusi DNS untuk kontainer di dalam dan di luar solusi. Azure DNS mendukung semua catatan DNS umum dan menyediakan ketersediaan tinggi.

• Azure Bastion (opsional) dan subnet untuk mengakses simpul pekerja atau mesin JumpBox opsional dengan aman. Azure Bastion adalah layanan terkelola penuh yang menyediakan akses RDP dan SSH yang aman dan mulus ke VM tanpa paparan melalui alamat IP publik.

• SQL Server di Azure Virtual Machines (opsional) SQL Server di Azure Virtual Machines (VM) untuk menyediakan layanan data ke MAS. Database juga bisa menjadi yang lain, seperti Oracle Exadata atau IBM Db2 Warehouse. Azure SQL Database dan Azure SQL Managed Instance tidak didukung saat ini.

• Twilio Send Grid (opsional) untuk mengirim email dari MAS ke konsumen Anda.

• Komputer virtual Linux di Azure (opsional) untuk menyediakan jump box untuk penginstalan OpenShift. Anda juga dapat menggunakan VM ini untuk menyambungkan dan mengelola kluster OpenShift karena berisi file konfigurasi Kubernetes setelah penginstalan. Jika Anda memiliki konektivitas jaringan ke lingkungan Azure, Anda dapat melakukan penginstalan dari komputer yang ada.

Alternatif

Layanan berikut biasanya tidak diperlukan, tetapi merupakan alternatif yang efektif:

• Azure NetApp Files sebagai pengganti Azure Files. NetApp Files mendukung semua jenis beban kerja dengan ketersediaan tinggi dan performa tinggi.
• Oracle Database di Azure jika Anda lebih suka itu ke SQL Server atau Gudang Db2.
• OpenShift Data Foundation jika Anda ingin menggunakan Db2 Warehouse di OpenShift Data Foundation.

Detail skenario

Maximo Application Suite (MAS) IBM, juga dikenal sebagai Maximo, adalah platform manajemen aset perusahaan dengan pemeliharaan aset berbasis AI. MAS berfokus pada ketahanan dan keandalan operasional. Rangkaian ini terdiri dari platform aplikasi inti, MAS, dan aplikasi dan solusi khusus industri di atas platform. Setiap aplikasi memberikan manfaat tertentu:

• Kelola. Kurangi waktu dan biaya dengan menggunakan manajemen aset untuk meningkatkan performa operasional.
• Pantau. Gunakan IoT untuk pemantauan aset jarak jauh yang didukung AI tingkat lanjut dalam skala besar.
• Kesehatan. Mengelola kesehatan aset dengan menggunakan data IoT dari sensor, data aset, dan riwayat pemeliharaan.
• Inspeksi visual. Latih model pembelajaran mesin untuk menggunakan inspeksi visual untuk analisis visual masalah yang muncul.
• Prediksi. Memprediksi kegagalan di masa mendatang dengan menggunakan pembelajaran mesin dan analitik data.
• Bantuan. Bantu teknisi dengan memberikan panduan yang didukung AI ke basis pengetahuan data pemeliharaan peralatan dan dengan memberi mereka akses jarak jauh ke para ahli.
• Keamanan. Kumpulkan dan analisis data dari sensor, berikan data kontekstual, dan dapatkan analitik yang bermakna.
• Sipil. Integrasikan aktivitas inspeksi, pelacakan cacat, dan pemeliharaan untuk membantu meningkatkan kehidupan aset, menjaga sistem penting tetap beroperasi, dan menurunkan total biaya kepemilikan infrastruktur sipil.

Aplikasi ini dan MAS 8.x diuji untuk digunakan di Azure. Microsoft dan tim IBM Maximo bermitra untuk memastikan solusi ini dikonfigurasi agar berjalan optimal di Azure. Artikel ini menyediakan desain untuk menjalankan MAS 8.x di Azure untuk pelanggan yang memiliki dukungan dari IBM dan mitra untuk penginstalan. Silakan hubungi tim IBM Anda untuk pertanyaan khusus produk. Marketplace Azure menawarkan penginstalan alternatif untuk MAS yang mendukung membawa lisensi Anda sendiri. Untuk informasi selengkapnya, lihat IBM Maximo Application Suite (BYOL).

Kemungkinan kasus penggunaan

Banyak industri dan sektor menggunakan solusi di MAS, seperti:

• Energi dan utilitas
• Minyak dan gas
• Manufaktur
• Perjalanan, otomotif, dan transportasi
• Sektor publik

Temukan informasi selengkapnya tentang kasus penggunaan untuk MAS di situs web IBM di IBM Maximo Application Suite.

Rekomendasi

Sebaiknya instal MAS versi stabil terbaru karena menyediakan opsi integrasi terbaik dengan Azure. Perhatikan dengan cermat versi OpenShift yang didukung, karena versi yang didukung bervariasi dengan versi MAS tertentu.

Penggunaan OpenShift versi utama yang lebih lama atau yang lebih baru dapat mengakibatkan jatuh dari dukungan resmi untuk MAS. Sebelum membangun penyebaran Anda sendiri, sebaiknya gunakan panduan mulai cepat untuk menyebarkan MAS sehingga Anda memahami cara kerja penyebaran dan konfigurasi. Mengetahui bagaimana hal ini dilakukan mempercepat pembuatan persyaratan desain untuk implementasi Anda. Untuk informasi selengkapnya, lihat Panduan Mulai Cepat: Maximo Application Suite di Azure.

Kami bekerja sama dengan IBM dan mitra lain untuk memastikan bahwa panduan, arsitektur, dan panduan mulai cepat memberi Anda pengalaman terbaik di Azure. Mereka mengikuti praktik terbaik seperti yang diuraikan dalam Microsoft Azure Well-Architected Framework. Hubungi tim akun IBM Anda untuk mendapatkan dukungan di luar dokumentasi ini.

Sebelum melanjutkan penyebaran, Anda perlu menjawab pertanyaan berikut tentang desain:

• Aplikasi MAS apa yang Anda butuhkan?
• Dependensi apa yang dimiliki aplikasi Anda?
• Versi OpenShift apa yang diperlukan?
• Metode penginstalan OpenShift mana yang harus Anda gunakan?
• Database apa yang diperlukan?
• Jumlah dan ukuran VM apa yang Anda butuhkan?
• Apakah pengguna akan tersambung dari jaringan eksternal?

Maximo Application Suite

Microsoft telah menguji MAS versi 8.5 dan yang lebih baru di Azure. Rekomendasi kami adalah menggunakan mas versi terbaru, yaitu versi 8.7.

Tinjau aplikasi MAS yang Anda butuhkan untuk skenario bisnis lengkap Anda, lalu tinjau persyaratan untuk setiap aplikasi. Untuk informasi selengkapnya, lihat Persyaratan sistem IBM Maximo Application Suite. Setiap aplikasi mungkin memerlukan database terpisah. Kami telah menguji dan mendukung database berikut di Azure:

• SQL Server di Azure VM versi 2019 menggunakan Windows atau Linux
• Gudang IBM Db2 di Cloud Pak untuk Data 3.5

Anda mungkin juga memilih untuk menjalankan Oracle Exadata pada VM atau di Oracle Cloud Infrastructure dengan menggunakan interkoneksi, tetapi ini bukan konfigurasi yang diuji. Untuk informasi selengkapnya tentang interkoneksi, lihat Mempelajari tentang interkoneksi Oracle Cloud dengan Microsoft Azure. Saat ini, Azure SQL Database, Azure SQL Managed Instance, dan Azure Cosmos DB tidak didukung.

MAS dan beberapa aplikasinya memiliki dependensi pada MongoDB dan Kafka. Tentukan cara menyebarkan solusi ini berdasarkan pertimbangan performa dan operasi. Defaultnya adalah menyebarkan MongoDB Community Edition dan Strimzi Kafka di dalam kluster. Beberapa prasyarat MAS, misalnya BAS, menggunakan database yang tidak dapat diekstersterisasi tetapi memerlukan penyimpanan persisten untuk disediakan ke kluster OpenShift.

Untuk layanan berbasis status yang berjalan di dalam kluster OpenShift, sering mencadangkan data dan memindahkan cadangan ke wilayah lain diperlukan. Merancang dan merencanakan strategi pemulihan jika terjadi bencana dan memutuskan dengan tepat, terutama saat menjalankan Kafka atau MongoDB di dalam OpenShift.

Untuk layanan yang mempertahankan status, gunakan penawaran platform as a service (PaaS) Azure eksternal jika memungkinkan. Melakukannya meningkatkan dukungan selama pemadaman.

Beberapa layanan mungkin memerlukan alat dan layanan IBM lainnya, seperti IBM Watson Pembelajaran Mesin dan IBM App Koneksi. Anda dapat menyebarkan semua alat dan layanan pada kluster OpenShift yang sama.

OpenShift

Sebelum menginstal OpenShift, Anda perlu menentukan metode mana yang akan Anda gunakan:

• Installer Provisioned Infrastructure (IPI). Metode ini menggunakan alat penginstal untuk menyebarkan dan mengonfigurasi lingkungan OpenShift di Azure. IPI adalah metode paling umum untuk menyebarkan di Azure, dan Anda harus menggunakan IPI kecuali persyaratan keamanan Anda terlalu ketat untuk melakukannya.

• User Provisioned Infrastructure (UPI). Metode ini memungkinkan kontrol halus atas penyebaran Anda. UPI memerlukan lebih banyak langkah dan pertimbangan untuk membangun lingkungan Anda. Gunakan UPI jika IPI tidak memenuhi kebutuhan Anda. Kasus penggunaan umum untuk UPI adalah untuk penginstalan privat yang terpasang di udara. Pilih UPI saat Anda tidak memiliki akses internet keluar saat membangun lingkungan.

Sebaiknya gunakan IPI jika memungkinkan, karena secara signifikan mengurangi jumlah pekerjaan yang diperlukan untuk menyelesaikan penginstalan OpenShift.

Saat menginstal OpenShift, Anda harus menyelesaikan pertimbangan berikut:

• Pemilihan wilayah. Sebaiknya gunakan wilayah dengan zona ketersediaan. Selama penyebaran, OpenShift secara otomatis mencoba membuat simpul di seluruh zona berdasarkan konfigurasi dalam file konfigurasi, install-config.yaml. Secara default, OpenShift menyeimbangkan beban kerja di semua simpul yang tersedia dan di seluruh zona ketersediaan. Jika ada pemadaman di zona, solusi Anda dapat terus berfungsi dengan memiliki simpul di zona lain yang dapat mengambil alih pekerjaan.

• Pencadangan & pemulihan. Anda dapat menggunakan instruksi untuk Azure Red Hat OpenShift untuk pencadangan dan pemulihan. Untuk informasi selengkapnya, lihat Membuat Cadangan Aplikasi kluster Azure Red Hat OpenShift 4. Jika Anda menggunakan metode ini untuk pencadangan dan pemulihan, Anda harus menyediakan metode pemulihan bencana lain untuk database.

• Failover. Pertimbangkan untuk menyebarkan OpenShift di dua wilayah dan menggunakan Red Hat Advanced Cluster Management. Jika solusi Anda memiliki titik akhir publik, Anda dapat menempatkan Azure Traffic Manager di antara mereka dan internet untuk mengalihkan lalu lintas ke kluster yang sesuai saat ada pemadaman wilayah. Dalam situasi seperti itu, Anda juga harus memigrasikan status aplikasi dan volume persisten Anda.

Penginstalan yang dipetakan udara

Dalam beberapa kasus, seperti untuk kepatuhan terhadap peraturan, Anda mungkin memerlukan penginstalan MAS yang terpasang di udara di Azure. Udara bersinar berarti bahwa tidak ada akses internet masuk atau keluar. Tanpa koneksi internet, penginstalan Anda tidak dapat mengambil dependensi penginstalan pada waktu proses untuk penginstalan MAS atau OpenShift.

Kami tidak menyarankan Agar Anda melakukan penginstalan yang terpasang di udara kecuali itu adalah persyaratan keamanan. Kesenjangan udara menambah kompleksitas yang signifikan pada operasi solusi Anda. Aktivitas seperti menginstal perangkat lunak, mencerminkan kontainer, memperbarui cermin untuk melindungi dari kerentanan keamanan, dan mengelola firewall dapat menjadi sangat memakan waktu.

Untuk informasi selengkapnya tentang penginstalan yang di-air-gapped, lihat dokumentasi OpenShift berikut ini:

• Mencerminkan gambar untuk penginstalan yang terputus
• Menginstal kluster privat di Azure

Setelah Anda menginstal OpenShift, lihat dokumentasi MAS untuk panduan serupa.

Mengubah ukuran lingkungan Anda

Untuk semua beban kerja (kecuali inspeksi visual), sebaiknya gunakan VM seri Ds terbaru sebagai simpul pekerja Anda. Contohnya adalah Dsv3, Dasv4, Dsv4, Dasv5, atau Dsv5. Sebaiknya gunakan versi terbaru, jika memungkinkan, karena memberikan performa yang lebih baik. Hanya gunakan VM yang memiliki penyimpanan premium.

Maximo Visual Inspection memerlukan simpul GPU untuk melakukan pembelajaran mesinnya. Solusinya menggunakan CUDA dan hanya mendukung GPU NVIDIA. Jenis VM yang direkomendasikan adalah NCv3 dan NCasT4_v3. Jika Anda perlu melatih dengan menggunakan YOLOv3, Anda memerlukan GPU berbasis Ampere. Gunakan NVadsA10 v5 atau NC A100 v4 untuk tugas pelatihan yang lebih besar.

Untuk komputer GPU, sebaiknya mulai dengan simpul terkecil dan peningkatan skala saat kebutuhan Anda meningkat.

Untuk semua komputer lain, sebaiknya konfigurasikan VM di seluruh zona ketersediaan untuk mendukung ketersediaan tinggi. Konfigurasikan simpul sebagai berikut:

• Kontrol simpul. Minimal satu VM per zona ketersediaan dalam wilayah yang dipilih. Kami merekomendasikan jumlah vCPU setidaknya 4. Referensi kami menggunakan simpul 3x Standard_D8s_v4 .

• Simpul pekerja. Minimal dua komputer per zona ketersediaan dalam wilayah yang dipilih. Kami merekomendasikan jumlah vCPU setidaknya 8. Referensi kami menggunakan simpul 6x Standard_D8s_v4 .

Inti MAS memerlukan 13 vCPU untuk penginstalan dasar berukuran standar. Ukuran untuk simpul pekerja bervariasi berdasarkan aplikasi MAS mana yang disebarkan konfigurasi Anda dan beban pada lingkungan Anda. Misalnya, Kelola untuk 10 pengguna memerlukan 2 vCPU lain. Sebaiknya tinjau persyaratan sistem IBM Maximo Application Suite untuk mendapatkan perkiraan ukuran yang baik.

Cobalah untuk menjaga jenis VM tetap mirip satu sama lain untuk memberikan kedekatan dengan masing-masing zona ketersediaan antara simpul pekerja dan kontrol. Artinya, jika Anda menggunakan VM v4 untuk simpul kontrol Anda, gunakan juga VM v4 untuk simpul pekerja Anda.

Jika Anda memerlukan jump box untuk menggunakan antarmuka baris perintah (oc) OpenShift atau untuk menginstal MAS, sebarkan VM yang menjalankan Red Hat Enterprise Linux versi 8.4.

Jaringan

Dengan OpenShift, kami menggunakan penyedia antarmuka jaringan kontainer default (CNI) dari jaringan yang ditentukan perangkat lunak (SDN) OpenShift. Untuk informasi selengkapnya tentang OpenShift CNI default, lihat Operator Jaringan Kluster di Platform Kontainer OpenShift. Anda harus mengukur jaringan Anda untuk jumlah kontrol OpenShift dan simpul pekerja yang Anda butuhkan, dan juga untuk persyaratan lain, seperti database dan akun penyimpanan.

Untuk penginstalan produksi MAS standar, kami merekomendasikan jaringan virtual dengan ruang alamat yang disediakan awalan CIDR /24. Jaringan virtual memiliki tiga atau empat subnet (untuk Bastion). Untuk OpenShift, subnet untuk simpul pekerja memiliki awalan CIDR /25, dan node kontrol memiliki awalan /27. Subnet untuk titik akhir dan server database eksternal opsional harus memiliki awalan /27. Jika Anda menyebarkan Azure Bastion, yang bersifat opsional, Anda memerlukan subnet bernama AzureBastionSubnet dengan awalan /26. Untuk informasi selengkapnya tentang persyaratan untuk Azure Bastion, lihat Arsitektur.

Jika Anda kekurangan alamat IP, Anda dapat menerapkan konfigurasi yang sangat tersedia dengan awalan minimum /27 untuk subnet simpul kontrol dan /27 untuk subnet simpul pekerja.

Jika Anda ingin menggunakan CNI yang berbeda, sesuaikan ukuran jaringan Anda. MAS dengan beberapa aplikasi standar menyebarkan lebih dari 800 pod, yang kemungkinan memerlukan awalan CIDR /21 atau lebih besar.

Database spesifik

Berbagai komponen MAS menggunakan MongoDB sebagai penyimpanan metadata. Panduan default adalah menyebarkan MongoDB Community Edition di dalam kluster. Jika Anda menyebarkannya dengan menggunakan metode tersebut, pastikan Anda telah menerapkan prosedur yang tepat untuk mencadangkan dan memulihkan database. Pertimbangkan untuk menggunakan MongoDB Atlas di Azure, karena menyediakan penyimpanan eksternal, cadangan, penskalakan, dan banyak lagi. Azure saat ini tidak mendukung penggunaan API MongoDB dengan Azure Cosmos DB.

Jika Anda menyebarkan layanan IoT, Anda juga diharuskan untuk menyediakan titik akhir Kafka. Panduan defaultnya adalah menggunakan Strimzi untuk menyebarkan Kafka di dalam kluster OpenShift. Selama pemulihan bencana, data di dalam Strimzi kemungkinan besar akan hilang. Jika kehilangan data dalam Kafka tidak dapat diterima, Anda harus mempertimbangkan untuk menggunakan Confluent Kafka di Azure. Saat ini, Azure Event Hubs dengan titik akhir Kafka tidak didukung.

MAS dilengkapi dengan banyak database di dalam podnya, dan database tersebut mempertahankan statusnya pada sistem file yang disediakan untuk MAS. Sebaiknya gunakan mekanisme penyimpanan zona-redundan untuk mempertahankan status di luar kluster Anda agar dapat menyerap kegagalan zona. Pola yang kami rekomendasikan adalah menggunakan Azure File Storage dengan konfigurasi berikut:

• Standar. Menyediakan berbagi Blok Pesan Server (SMB) untuk throughput yang lebih rendah dan beban kerja ReadWriteOnce (RWO). Standar sangat cocok untuk bagian aplikasi yang tidak sering menulis ke penyimpanan dan memerlukan satu volume persisten (misalnya, penyimpanan tingkat tunggal IBM).

• Premium. Menyediakan berbagi Network File System (NFS) untuk throughput yang lebih tinggi dan beban kerja ReadWriteMany (RWX). Volume seperti ini digunakan di seluruh kluster untuk beban kerja RWX, seperti Gudang Db2 di Cloud Pak untuk Data atau Postgres di Kelola.

Pastikan untuk menonaktifkan kebijakan untuk memberlakukan transfer aman pada Azure Blob Storage atau mengecualikan akun dari kebijakan tersebut. Azure Premium Files dengan NFS mengharuskan transfer aman dinonaktifkan. Pastikan untuk menggunakan titik akhir privat untuk menjamin konektivitas privat ke berbagi Anda.

Secara default, Db2 Warehouse disebarkan di atas OpenShift Data Foundation (sebelumnya dikenal sebagai OpenShift Container Storage). Untuk alasan biaya, performa, penskalaan, dan keandalan, sebaiknya gunakan Azure Premium Files dengan NFS alih-alih OpenShift Data Foundation.

Jangan gunakan Azure Blob dengan driver CSI, karena tidak mendukung tautan keras, yang diperlukan. Beberapa pod tidak dapat berjalan tanpa tautan keras.

Pertimbangan

Pertimbangan ini mengimplementasikan pilar Azure Well-Architected Framework, yang merupakan serangkaian tenet panduan yang dapat Anda gunakan untuk meningkatkan kualitas beban kerja. Untuk informasi selengkapnya, lihat Microsoft Azure Well-Architected Framework.

Keamanan

Keamanan memberikan jaminan terhadap serangan yang disukai dan penyalahgunaan data dan sistem berharga Anda. Untuk informasi selengkapnya, lihat Gambaran Umum pilar keamanan.

Mempertahankan akses dan visibilitas ke dalam siklus hidup pemeliharaan aset Anda dapat menjadi salah satu peluang terbesar organisasi Anda untuk beroperasi secara efisien dan mempertahankan waktu aktif. Untuk meningkatkan postur keamanan lingkungan Anda, penting untuk menggunakan autentikasi yang aman dan menjaga solusi Anda tetap terbarui. Gunakan enkripsi untuk melindungi semua data yang bergerak masuk dan keluar dari arsitektur Anda.

Azure memberikan MAS dengan menggunakan model infrastruktur sebagai layanan (IaaS) dan PaaS. Microsoft membangun perlindungan keamanan ke dalam layanan di tingkat berikut:

• Pusat data fisik
• Jaringan fisik
• Host fisik
• Hypervisor

Evaluasi layanan dan teknologi yang Anda pilih dengan hati-hati untuk area di atas hypervisor, seperti versi openShift terbaru yang di-patch untuk rilis utama. Pastikan untuk memberikan kontrol keamanan yang tepat untuk arsitektur Anda. Anda bertanggung jawab untuk menambal dan menjaga keamanan sistem IaaS. Microsoft mengambil peran tersebut untuk layanan PaaS.

Gunakan grup keamanan jaringan untuk memfilter lalu lintas jaringan ke dan dari sumber daya di jaringan virtual Anda. Dengan grup ini, Anda dapat menentukan aturan yang memberikan atau menolak akses ke layanan MAS Anda. Contohnya meliputi:

• Mengizinkan akses SSH ke node OpenShift untuk pemecahan masalah
• Memblokir akses ke semua bagian lain dari kluster
• Mengontrol lokasi mana yang dapat memiliki akses ke MAS dan kluster OpenShift

Jika Memerlukan akses ke VM karena alasan tertentu, Anda dapat terhubung melalui konektivitas hibrid atau melalui konsol admin OpenShift. Jika Anda memiliki penyebaran online atau tidak ingin mengandalkan konektivitas, Anda juga dapat mengakses VM Melalui Azure Bastion (yang bersifat opsional). Untuk alasan keamanan, Anda tidak boleh mengekspos VM ke jaringan atau internet tanpa mengonfigurasi kelompok keamanan jaringan untuk mengontrol akses ke VM.

Enkripsi sisi server (SSE) Azure Disk Storage melindungi data Anda. Enkripsi ini juga membantu Anda memenuhi komitmen kepatuhan dan keamanan organisasi. Dengan disk terkelola Azure, SSE mengenkripsi data tidak aktif saat menyimpannya ke cloud. Perilaku ini berlaku secara default untuk OS dan disk data. OpenShift menggunakan SSE secara default.

Autentikasi

MAS saat ini mendukung penggunaan Security Assertion Markup Language (SAML) melalui MICROSOFT Entra ID. Untuk membuat ini berfungsi, Anda memerlukan aplikasi perusahaan dalam ID Microsoft Entra dan izin untuk mengubah aplikasi atau bantuan administrator global yang dapat membuat perubahan yang diperlukan.

Panduan mulai cepat di GitHub memiliki tutorial tentang cara menyiapkan SAML dengan MAS. Untuk informasi selengkapnya, lihat Mengaktifkan autentikasi SAML terhadap ID Microsoft Entra.

Sebelum Anda menyiapkan autentikasi berbasis SAML, kami sarankan Anda melalui konfigurasi IBM dan konfigurasi Azure. Untuk informasi tentang SAML dengan MAS, lihat SAML dalam dokumentasi untuk MAS. Untuk informasi tentang SAML dengan Azure, lihat Mulai Cepat: Mengaktifkan akses menyeluruh untuk aplikasi perusahaan.

Anda juga harus mengonfigurasi OAuth untuk OpenShift. Untuk informasi selengkapnya, lihat Gambaran Umum autentikasi dan otorisasi dalam dokumentasi OpenShift.

Melindungi infrastruktur Anda

Kontrol akses ke sumber daya Azure yang Anda sebarkan. Setiap langganan Azure memiliki hubungan kepercayaan dengan penyewa Microsoft Entra. Gunakan kontrol akses berbasis peran Azure (Azure RBAC) untuk memberi pengguna dalam organisasi Anda izin yang benar ke sumber daya Azure. Berikan akses dengan menetapkan peran Azure kepada pengguna atau grup pada cakupan tertentu. Cakupannya bisa berupa langganan, grup sumber daya, atau satu sumber daya. Pastikan untuk mengaudit semua perubahan pada infrastruktur. Untuk informasi selengkapnya tentang audit, lihat Log aktivitas Azure Monitor.

Pengoptimalan biaya

Optimalisasi biaya adalah tentang mencari cara untuk mengurangi pengeluaran yang tidak perlu dan meningkatkan efisiensi operasional. Untuk informasi selengkapnya, lihat Gambaran umum pilar pengoptimalan biaya.

Penyebaran standar MAS terdiri dari komponen-komponen berikut:

• 3 komputer virtual kontrol
• 6 VM pekerja
• 3 VM pekerja untuk Db2 Warehouse
  • Anda dapat mengganti SQL Server di Azure VM dalam beberapa konfigurasi, daripada menggunakan Db2 Warehouse.
• 2 akun Azure Storage
• 2 Zona DNS
• 2 Load balancer
• Azure Bastion
• 1 Visual Inspection VM
  • Ini tidak diperlukan kecuali Anda berencana untuk menjalankan Inspeksi Visual di dalam MAS.

Anda dapat meninjau perkiraan contoh dengan menggunakan kalkulator biaya kami. Konfigurasi bervariasi, dan Anda harus memverifikasi konfigurasi Anda dengan tim ukuran IBM Anda sebelum menyelesaikan penyebaran Anda.

Keandalan

OpenShift memiliki kemampuan bawaan untuk penyembuhan diri, penskalaan, dan ketahanan untuk memastikan OpenShift dan MAS berhasil bekerja. OpenShift dan MAS telah dirancang untuk bagian yang gagal dan pulih. Persyaratan utama untuk penyembuhan diri untuk bekerja adalah bahwa ada cukup simpul pekerja. Untuk memulihkan dari kegagalan zona dalam wilayah Azure, simpul kontrol dan pekerja Anda harus seimbang di seluruh zona ketersediaan.

MAS dan OpenShift menggunakan penyimpanan untuk mempertahankan status di luar kluster Kubernetes. Untuk memastikan bahwa dependensi penyimpanan terus berfungsi selama kegagalan, Anda harus menggunakan penyimpanan redundan zona jika memungkinkan. Jenis penyimpanan ini tetap tersedia ketika zona gagal.

Karena kesalahan manusia adalah umum, Anda harus menyebarkan MAS dengan menggunakan otomatisasi sebanyak mungkin. Dalam panduan mulai cepat kami, kami menyediakan beberapa contoh skrip untuk menyiapkan otomatisasi menyeluruh dan menyeluruh.

Menyebarkan skenario ini

Sebelum memulai, kami sarankan Anda meninjau persyaratan sistem IBM Maximo Application Suite. Pastikan Anda memiliki sumber daya berikut yang tersedia sebelum memulai penyebaran:

• Akses ke Langganan Azure dengan izin Pembaca
• Pendaftaran Aplikasi atau nama perwakilan layanan yang memiliki izin Kontributor dan Administrator Akses Pengguna ke langganan
• Domain atau subdomain yang didelegasikan ke zona Azure DNS
• Menarik rahasia dari Red Hat untuk menyebarkan OpenShift
• Kunci pemberian izin MAS
• File lisensi MAS (dibuat setelah penginstalan MAS)
• Ukuran kluster yang direkomendasikan IBM
• Jaringan virtual yang ada atau jaringan virtual baru yang dibuat oleh IPI, tergantung pada kebutuhan Anda
• Persyaratan ketersediaan tinggi dan pemulihan bencana untuk penyebaran spesifik Anda
• File konfigurasi, install-config.yaml, untuk alat penginstal

Untuk panduan langkah demi langkah untuk menginstal OpenShift dan MAS di Azure, termasuk cara mengatasi prasyarat, lihat panduan mulai cepat kami di GitHub.

Pertimbangan penyebaran

Sebaiknya sebarkan beban kerja dengan menggunakan infrastruktur sebagai kode (IaC) daripada menyebarkan beban kerja secara manual, karena penyebaran manual dapat mengakibatkan kesalahan konfigurasi. Beban kerja berbasis kontainer dapat sensitif terhadap kesalahan konfigurasi, yang dapat mengurangi produktivitas.

Sebelum membangun lingkungan Anda, tinjau panduan mulai cepat untuk mengembangkan pemahaman tentang parameter desain. Panduan mulai cepat tidak ditujukan untuk penyebaran siap produksi, tetapi Anda dapat menggunakan aset panduan untuk sampai ke mekanisme tingkat produksi untuk penyebaran.

IBM menawarkan layanan spesialis untuk membantu Anda menginstal. Hubungi tim IBM Anda untuk mendapatkan dukungan.

Kontributor

Artikel ini dikelola oleh Microsoft. Ini awalnya ditulis oleh kontributor berikut.

Penulis utama:

• David Baumgarten | Arsitek Solusi Cloud Senior
• Roeland Nieuwenhuis | Arsitek Solusi Cloud Utama

Kontributor lainnya:

• Gary Moore | Programmer/Writer

Untuk melihat profil LinkedIn non-publik, masuk ke LinkedIn.

Langkah berikutnya

Untuk bantuan tentang memulai, lihat sumber daya berikut ini:

• Menginstal OpenShift di Azure
• Panduan Mulai Cepat: Maximo Application Suite di Azure
• Panduan UPI OpenShift
• Persyaratan untuk Maximo
• IBM Maximo Application Suite (BYOL)

Untuk mempelajari selengkapnya tentang teknologi unggulan, lihat sumber daya berikut:

• Keunggulan IBM Passport
• Pengantar Azure DNS
• Pengenalan Azure NetApp Files
• Pengantar Red Hat di Azure
• Portal Pelanggan Red Hat

Sumber daya terkait

• Berbagi file cloud perusahaan Azure
• Pendahuluan pemeliharaan prediktif di bidang manufaktur
• Menyebarkan aplikasi Java dengan JBoss EAP pada kluster ARO