Catatan
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba masuk atau mengubah direktori.
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba mengubah direktori.
Artikel ini menjelaskan strategi untuk menyebarkan platform SAP BusinessObjects BI (BOBI) di Azure untuk Linux. Dalam contoh ini, Anda mengonfigurasi dua komputer virtual dengan disk terkelola SSD Premium sebagai direktori penginstalan. Anda menggunakan Azure Database for MySQL untuk database CMS Anda, dan membagikan Azure NetApp Files untuk server repositori file Anda di kedua server. Di kedua mesin virtual, Anda menginstal aplikasi web Tomcat Java default dan aplikasi platform BI secara bersama-sama. Untuk menyeimbangkan beban permintaan pengguna, Anda menggunakan Azure Application Gateway dengan kemampuan offloading TLS/SSL asli.
Jenis arsitektur ini efektif untuk penyebaran kecil atau lingkungan non-produksi. Untuk penyebaran besar atau lingkungan produksi, Anda dapat memiliki host terpisah untuk aplikasi web Anda. Anda juga dapat memiliki beberapa host aplikasi BOBI, memungkinkan server untuk memproses lebih banyak informasi.
Berikut adalah versi produk dan tata letak sistem file untuk contoh ini:
- Platform SAP BusinessObjects 4.3
- SUSE Linux Enterprise Server 12 SP5
- Azure Database for MySQL (Versi: 8.0.15)
- Konektor MySQL C API - libmysqlclient (Versi: 6.1.11)
| Sistem file | Deskripsi | Ukuran (GB) | Pemilik | Grup | Storage |
|---|---|---|---|---|---|
| /usr/sap | Sistem file untuk penginstalan instans SAP BOBI, aplikasi web Tomcat default, dan driver database (jika perlu). | Panduan ukuran SAP | bl1adm | sapsys | Disk premium terkelola - SSD |
| /usr/sap/frsinput | Direktori mount digunakan untuk file bersama di semua host BOBI dan berfungsi sebagai direktori repositori file input. | Kebutuhan bisnis | bl1adm | sapsys | Azure NetApp Files |
| /usr/sap/frsoutput | Direktori mount adalah untuk file yang dibagikan di seluruh host BOBI dan digunakan sebagai direktori repositori file output. | Kebutuhan bisnis | bl1adm | sapsys | Azure NetApp Files |
Penting
Saat penyiapan platform SAP BusinessObjects dijelaskan menggunakan Azure NetApp Files, Anda dapat menggunakan NFS di Azure Files sebagai repositori file input dan output.
Menyebarkan komputer virtual Linux melalui portal Azure
Pada bagian ini, Anda membuat dua mesin virtual dengan citra sistem operasi Linux untuk platform SAP BOBI. Langkah-langkah tingkat tinggi untuk membuat mesin virtual adalah sebagai berikut:
Buat grup sumber daya.
Buat jaringan virtual.
- Jangan gunakan satu subnet untuk semua layanan Azure dalam penyebaran platform SAP BI. Berdasarkan SAP BI, arsitektur platform, Anda perlu membuat beberapa subnet. Dalam penyebaran ini, Anda membuat tiga subnet: masing-masing untuk aplikasi, penyimpanan repositori file, dan Application Gateway.
- Di Azure, Application Gateway dan Azure NetApp Files harus selalu berada di subnet yang terpisah. Untuk informasi selengkapnya, lihat Azure Application Gateway dan Panduan untuk perencanaan jaringan Azure NetApp Files.
Pilih opsi ketersediaan yang sesuai tergantung pada konfigurasi sistem pilihan Anda dalam wilayah Azure, baik melibatkan rentang di seluruh zona, berada dalam satu zona, atau beroperasi di wilayah tanpa zona.
Buat mesin virtual 1 bernama (azusbosl1).
- Anda dapat menggunakan citra kustom atau memilih citra dari Marketplace Azure. Untuk informasi selengkapnya, lihat Menyebarkan VM dari Azure Marketplace untuk SAP atau Menyebarkan VM dengan gambar kustom untuk SAP.
Buat mesin virtual 2 bernama (azusbosl2).
Tambahkan satu SSD Premium. Anda akan menggunakannya sebagai direktori Penginstalan SAP BOBI Anda.
Memprovisikan Azure NetApp Files
Sebelum Anda melanjutkan penyiapan untuk Azure NetApp Files, biasakan diri Anda dengan dokumentasi Azure NetApp Files.
Azure NetApp Files tersedia di beberapa wilayah Azure. Periksa untuk melihat apakah wilayah Azure yang Anda pilih menawarkan Azure NetApp Files.
Gunakan Ketersediaan Azure NetApp Files menurut Wilayah Azure untuk memeriksa ketersediaan Azure NetApp Files menurut wilayah.
Sebarkan sumber daya Azure NetApp Files
Instruksi berikut mengasumsikan bahwa Anda telah menyebarkan jaringan virtual Azure Anda. Sumber daya Azure NetApp Files, dan VM tempat sumber daya Azure NetApp Files dipasang, harus disebarkan di jaringan virtual Azure yang sama atau di jaringan virtual Azure yang di-peering.
Buat akun Azure NetApp Files di wilayah Azure pilihan Anda.
Siapkan pool kapasitas Azure NetApp Files. Arsitektur platform SAP BI yang disajikan dalam artikel ini menggunakan satu kumpulan kapasitas Azure NetApp Files di tingkat layanan Premium. Untuk Server Repositori File SAP BI di Azure, sebaiknya gunakan Tingkat layanan Premium atau Ultra Azure NetApp Files.
Sebarkan volume Azure NetApp Files dengan mengikuti instruksi pada Membuat volume NFS untuk Azure NetApp Files.
Anda dapat menyebarkan volume sebagai NFSv3 dan NFSv4.1, karena kedua protokol didukung untuk platform SAP BOBI. Sebarkan volume di subnet Azure NetApp Files masing-masing. Alamat IP volume Azure NetApp Files ditetapkan secara otomatis.
Perlu diingat bahwa sumber daya Azure NetApp Files dan VM Azure harus berada di jaringan virtual Azure yang sama atau di jaringan virtual Azure yang diserekan. Misalnya, azusbobi-frsinput dan azusbobi-frsoutput adalah nama volume, dan nfs://10.31.2.4/azusbobi-frsinput dan nfs://10.31.2.4/azusbobi-frsoutput adalah jalur file untuk volume Azure NetApp Files.
- Volume azusbobi-frsinput (nfs://10.31.2.4/azusbobi-frsinput)
- Volume azusbobi-frsoutput (nfs://10.31.2.4/azusbobi-frsoutput)
Pertimbangan penting
Saat Anda membuat Azure NetApp Files untuk server repositori file platform SAP BOBI, ketahui pertimbangan berikut:
- Kumpulan kapasitas minimum adalah 4 tebibyte (TiB). Ukuran kumpulan kapasitas dapat ditingkatkan dengan kelipatan 1-TiB.
- Ukuran volume minimum adalah 100 gibibyte (GiB).
- Azure NetApp Files dan semua komputer virtual tempat volume Azure NetApp Files dipasang harus berada di jaringan virtual Azure yang sama, atau di jaringan virtual yang di-peering di wilayah yang sama. Akses ke Azure NetApp Files melalui peering jaringan virtual di wilayah yang sama dapat dilakukan. Akses Azure NetApp Files melalui peering global saat ini tidak didukung.
- Jaringan virtual yang dipilih harus memiliki subnet yang didelegasikan ke Azure NetApp Files.
- Karakteristik throughput dan performa volume Azure NetApp Files adalah fungsi dari kuota volume dan tingkat layanan, seperti yang didokumentasikan dalam Tingkat layanan untuk Azure NetApp Files. Saat mengukur volume SAP Azure NetApp, pastikan throughput yang dihasilkan memenuhi persyaratan aplikasi.
- Dengan kebijakan ekspor Azure NetApp Files, Anda dapat mengontrol klien yang diperbolehkan, jenis akses yang diizinkan (misalnya, baca-tulis/baca saja).
- Fitur Azure NetApp Files belum mengenali zona. Saat ini, fitur tersebut tidak disebarkan di semua zona ketersediaan di wilayah Azure. Waspadai potensi implikasi latensi di beberapa wilayah Azure.
- Volume Azure NetApp Files dapat disebarkan sebagai volume NFSv3 atau NFSv4.1. Kedua protokol ini didukung untuk aplikasi platform SAP BI.
Mengonfigurasi sistem file di server Linux
Langkah di bagian ini menggunakan awalan berikut:
[A]: Langkah ini berlaku untuk semua host.
Memformat dan memasang sistem file SAP
[A] Cantumkan semua disk yang terpasang.
sudo lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 30G 0 disk ├─sda1 8:1 0 2M 0 part ├─sda2 8:2 0 512M 0 part /boot/efi ├─sda3 8:3 0 1G 0 part /boot └─sda4 8:4 0 28.5G 0 part / sdb 8:16 0 32G 0 disk └─sdb1 8:17 0 32G 0 part /mnt sdc 8:32 0 128G 0 disk sr0 11:0 1 628K 0 rom # Premium SSD of 128 GB is attached to virtual machine, whose device name is sdc[A] Format perangkat blok untuk /usr/sap.
sudo mkfs.xfs /dev/sdc[A] Buat direktori pemasangan.
sudo mkdir -p /usr/sap[A] Dapatkan UUID perangkat blok.
sudo blkid # It will display information about block device. Copy UUID of the formatted block device /dev/sdc: UUID="0eb5f6f8-fa77-42a6-b22d-7a9472b4dd1b" TYPE="xfs"[A] Pertahankan entri pemasangan sistem file di /etc/fstab.
sudo echo "UUID=0eb5f6f8-fa77-42a6-b22d-7a9472b4dd1b /usr/sap xfs defaults,nofail 0 2" >> /etc/fstab[A] Pasang sistem file.
sudo mount -a sudo df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 7.9G 8.0K 7.9G 1% /dev tmpfs 7.9G 82M 7.8G 2% /run tmpfs 7.9G 0 7.9G 0% /sys/fs/cgroup /dev/sda4 29G 1.8G 27G 6% / tmpfs 1.6G 0 1.6G 0% /run/user/1000 /dev/sda3 1014M 87M 928M 9% /boot /dev/sda2 512M 1.1M 511M 1% /boot/efi /dev/sdb1 32G 49M 30G 1% /mnt /dev/sdc 128G 29G 100G 23% /usr/sap
Melakukan pemasangan volume Azure NetApp Files
[A] Buat direktori mount.
sudo mkdir -p /usr/sap/frsinput sudo mkdir -p /usr/sap/frsoutput[A] Konfigurasikan sistem operasi klien untuk mendukung Pemasangan NFSv4.1 (hanya berlaku jika menggunakan NFSv4.1).
Jika Anda menggunakan volume Azure NetApp Files dengan protokol NFSv4.1, jalankan konfigurasi berikut pada semua mesin virtual tempat volume Azure NetApp Files NFSv4.1 perlu dipasang.
Pada langkah ini, Anda perlu memverifikasi pengaturan domain NFS. Pastikan bahwa domain dikonfigurasi sebagai domain Azure NetApp Files default (
defaultv4iddomain.com), dan bahwa pemetaan diatur kenobody.sudo cat /etc/idmapd.conf # Example [General] Domain = defaultv4iddomain.com [Mapping] Nobody-User = nobody Nobody-Group = nobodyPenting
Pastikan untuk mengatur domain NFS di /etc/idmapd.conf pada mesin virtual agar sesuai dengan konfigurasi domain default di Azure NetApp Files (
defaultv4iddomain.com). Jika ada ketidaksesuaian, maka izin untuk file pada volume Azure NetApp Files yang dipasang di mesin virtual akan ditampilkan sebagainobody.Verifikasi
nfs4_disable_idmapping. Harus diatur keY. Untuk membuat struktur direktori tempatnfs4_disable_idmappingberada, jalankan perintah pemasangan. Anda tidak akan dapat membuat direktori secara manual di bawah /sys/modules, karena aksesnya diperuntukkan khusus untuk kernel/driver.# Check nfs4_disable_idmapping cat /sys/module/nfs/parameters/nfs4_disable_idmapping # If you need to set nfs4_disable_idmapping to Y mkdir /mnt/tmp mount -t nfs -o sec=sys,vers=4.1 10.31.2.4:/azusbobi-frsinput /mnt/tmp umount /mnt/tmp echo "Y" > /sys/module/nfs/parameters/nfs4_disable_idmapping # Make the configuration permanent echo "options nfs nfs4_disable_idmapping=Y" >> /etc/modprobe.d/nfs.conf[A] Tambahkan entri pemasangan.
Jika Anda menggunakan NFSv3:
sudo echo "10.31.2.4:/azusbobi-frsinput /usr/sap/frsinput nfs rw,hard,rsize=65536,wsize=65536,vers=3" >> /etc/fstab sudo echo "10.31.2.4:/azusbobi-frsoutput /usr/sap/frsoutput nfs rw,hard,rsize=65536,wsize=65536,vers=3" >> /etc/fstabJika Anda menggunakan NFSv4.1:
sudo echo "10.31.2.4:/azusbobi-frsinput /usr/sap/frsinput nfs rw,hard,rsize=65536,wsize=65536,vers=4.1,sec=sys" >> /etc/fstab sudo echo "10.31.2.4:/azusbobi-frsoutput /usr/sap/frsoutput nfs rw,hard,rsize=65536,wsize=65536,vers=4.1,sec=sys" >> /etc/fstab[A] Memasang volume NFS.
sudo mount -a sudo df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 7.9G 8.0K 7.9G 1% /dev tmpfs 7.9G 82M 7.8G 2% /run tmpfs 7.9G 0 7.9G 0% /sys/fs/cgroup /dev/sda4 29G 1.8G 27G 6% / tmpfs 1.6G 0 1.6G 0% /run/user/1000 /dev/sda3 1014M 87M 928M 9% /boot /dev/sda2 512M 1.1M 511M 1% /boot/efi /dev/sdb1 32G 49M 30G 1% /mnt /dev/sdc 128G 29G 100G 23% /usr/sap 10.31.2.4:/azusbobi-frsinput 101T 18G 100T 1% /usr/sap/frsinput 10.31.2.4:/azusbobi-frsoutput 100T 512K 100T 1% /usr/sap/frsoutput
Mengonfigurasi Azure Database for MySQL
Bagian ini menyediakan detail tentang cara memprovisikan Azure Database for MySQL menggunakan portal Microsoft Azure. Bagian ini juga memberikan instruksi tentang cara membuat database CMS dan audit untuk platform SAP BOBI, dan akun pengguna untuk mengakses database.
Panduan ini hanya berlaku jika Anda menggunakan Azure Database for MySQL. Untuk database lain, lihat dokumentasi khusus SAP atau database untuk mendapatkan petunjuk.
Membuat database
Masuk ke portal Microsoft Azure, dan ikuti langkah-langkah dalam Mulai Cepat: Membuat server Azure Database for MySQL menggunakan portal Microsoft Azure. Berikut adalah beberapa poin yang perlu diperhatikan saat memprovisikan Azure Database for MySQL:
Pilih wilayah yang sama untuk Azure Database for MySQL sebagai tempat server aplikasi platform SAP BI Anda berjalan.
Pilih versi database yang didukung, berdasarkan Matriks Ketersediaan Produk (PAM) untuk SAP BI khusus untuk versi SAP BOBI.
Pada komputasi+penyimpanan, pilih Konfigurasi server, dan pilih tingkat harga yang sesuai berdasarkan output ukuran Anda.
Penambahan Otomatis Penyimpanan diaktifkan secara default. Perlu diingat bahwa penyimpanan hanya dapat ditingkatkan, bukan diturunkan.
Secara default, Periode Retensi Cadangan adalah tujuh hari. Anda dapat mengonfigurasikannya secara opsional hingga 35 hari.
Cadangan Azure Database untuk MySQL secara default memiliki redundansi lokal. Jika Anda ingin pencadangan server di penyimpanan geo-redundan, pilih Redundan Secara Geografis dari Opsi Redundansi Cadangan.
Penting
Mengubah Opsi Redundansi Cadangan setelah server dibuat tidak dapat dilakukan.
Catatan
Fitur tautan pribadi hanya tersedia untuk server Azure Database for MySQL di tingkat harga Tujuan Umum atau Memori yang Dioptimalkan. Pastikan bahwa server database berada di salah satu tingkatan harga ini.
Mengonfigurasi Azure Private Link
Di bagian ini, Anda membuat tautan privat yang memungkinkan mesin virtual SAP BOBI tersambung ke Azure Database for MySQL melalui titik akhir privat. Azure Private Link menghadirkan layanan Azure di dalam jaringan virtual privat Anda.
- Pilih database yang dibuat di bagian sebelumnya.
- Buka Keamanan>Koneksi titik akhir privat.
- Pada Koneksi titik akhir privat, pilih Titik akhir privat.
- Pilih Langganan>Grup sumber daya>Lokasi.
- Masukkan Nama titik akhir privat tersebut.
- Di bagian Sumber Daya , tentukan yang berikut ini:
- Jenis sumber daya: Microsoft.DBforMySQL/servers
- Sumber daya: Database MySQL yang dibuat di bagian sebelumnya
- Subsumber daya target: mysqlServer
- Pada bagian Jaringan, pilih Jaringan virtual dan Subnet tempat aplikasi SAP BOBI disebarkan.
Catatan
Jika Anda mengaktifkan grup keamanan jaringan (NSG) untuk subnet, itu dinonaktifkan untuk titik akhir privat pada subnet ini saja. Sumber daya lainnya di subnet akan tetap memiliki penerapan NSG.
- Untuk Mengintegrasikan dengan zona DNS privat, terima default (ya).
- Pilih zona DNS privat Anda dari daftar drop-down.
- Pilih Tinjau+Buat, dan buat endpoint privat.
Untuk informasi selengkapnya, lihat Tautan Pribadi untuk Azure Database for MySQL.
Membuat database CMS dan audit
Unduh dan pasang Workbench MySQL dari situs web MySQL. Pastikan Anda memasang Workbench MySQL di server yang dapat mengakses Azure Database for MySQL.
Sambungkan ke server menggunakan Workbench MySQL. Ikuti instruksi di Dapatkan informasi koneksi. Jika pengujian koneksi berhasil, Anda akan mendapatkan pesan berikut:
Di tab kueri SQL, jalankan kueri berikut untuk membuat skema untuk database CMS dan audit.
# Here cmsbl1 is the database name of CMS database. You can provide the name you want for CMS database. CREATE SCHEMA `cmsbl1` DEFAULT CHARACTER SET utf8; # auditbl1 is the database name of Audit database. You can provide the name you want for CMS database. CREATE SCHEMA `auditbl1` DEFAULT CHARACTER SET utf8;Buat akun pengguna untuk menyambungkan ke skema.
# Create a user that can connect from any host, use the '%' wildcard as a host part CREATE USER 'cmsadmin'@'%' IDENTIFIED BY 'password'; CREATE USER 'auditadmin'@'%' IDENTIFIED BY 'password'; # Grant all privileges to a user account over a specific database: GRANT ALL PRIVILEGES ON cmsbl1.* TO 'cmsadmin'@'%' WITH GRANT OPTION; GRANT ALL PRIVILEGES ON auditbl1.* TO 'auditadmin'@'%' WITH GRANT OPTION; # Following any updates to the user privileges, be sure to save the changes by issuing the FLUSH PRIVILEGES FLUSH PRIVILEGES;Untuk memeriksa hak istimewa dan peran akun pengguna MySQL:
USE sys; SHOW GRANTS for 'cmsadmin'@'%'; +------------------------------------------------------------------------+ | Grants for cmsadmin@% | +------------------------------------------------------------------------+ | GRANT USAGE ON *.* TO `cmsadmin`@`%` | | GRANT ALL PRIVILEGES ON `cmsbl1`.* TO `cmsadmin`@`%` WITH GRANT OPTION | +------------------------------------------------------------------------+ USE sys; SHOW GRANTS FOR 'auditadmin'@'%'; +----------------------------------------------------------------------------+ | Grants for auditadmin@% | +----------------------------------------------------------------------------+ | GRANT USAGE ON *.* TO `auditadmin`@`%` | | GRANT ALL PRIVILEGES ON `auditbl1`.* TO `auditadmin`@`%` WITH GRANT OPTION | +----------------------------------------------------------------------------+
Pasang konektor MySQL C API di server Linux
Agar server aplikasi SAP BOBI bisa mengakses database, diperlukan driver klien database. Untuk mengakses database CMS dan audit, Anda harus menggunakan Konektor MySQL C API untuk Linux. Koneksi ODBC ke database CMS tidak didukung. Bagian ini menyediakan instruksi tentang cara mengatur Konektor MySQL C API di Linux.
Baca Driver MySQL dan alat manajemen yang kompatibel dengan Azure Database for MySQL. Periksa driver Konektor MySQL/C (libmysqlclient) di artikel tersebut.
Untuk mengunduh driver, lihat Arsip Produk MySQL.
Pilih sistem operasi dan unduh paket rpm komponen berbagi MySQL Connector. Dalam contoh ini, versi konektor mysql-connector-c-shared-6.1.11 digunakan.
Pasang konektor di semua instans aplikasi SAP BOBI.
# Install rpm package SLES: sudo zypper install <package>.rpm RHEL: sudo yum install <package>.rpmPeriksa jalur libmysqlclient.so.
# Find the location of libmysqlclient.so file whereis libmysqlclient # sample output libmysqlclient: /usr/lib64/libmysqlclient.soAtur
LD_LIBRARY_PATHagar mengarah ke direktori/usr/lib64untuk akun pengguna yang akan digunakan untuk penginstalan.# This configuration is for bash shell. If you are using any other shell for sidadm, kindly set environment variable accordingly. vi /home/bl1adm/.bashrc export LD_LIBRARY_PATH=/usr/lib64
Persiapan server
Langkah di bagian ini menggunakan awalan berikut:
[A]: Langkah ini berlaku untuk semua host.
[A] Berdasarkan versi Linux (SLES atau RHEL), Anda perlu mengatur parameter kernel dan memasang pustaka yang diperlukan. Lihat bagian "Persyaratan sistem" di Panduan Penginstalan Platform Kecerdasan Bisnis untuk Unix.
[A] Pastikan bahwa zona waktu pada komputer Anda diatur dengan benar. Dalam Panduan Penginstalan, lihat persyaratan Unix dan Linux lainnya.
[A] Buat akun pengguna (bl1adm) dan grup (sapsys) di mana proses latar belakang perangkat lunak dapat berjalan. Gunakan akun ini untuk menjalankan penginstalan dan perangkat lunak. Akun tidak memerlukan hak akses root.
[A] Atur lingkungan akun pengguna (bl1adm) agar menggunakan lokal UTF-8 yang didukung, dan pastikan perangkat lunak konsol Anda mendukung tataan karakter UTF-8. Untuk memastikan bahwa sistem operasi Anda menggunakan lokal yang benar, atur variabel lingkungan
LC_ALLdanLANGke lokal pilihan Anda di lingkungan pengguna (bl1adm) Anda.# This configuration is for bash shell. If you are using any other shell for sidadm, kindly set environment variable accordingly. vi /home/bl1adm/.bashrc export LANG=en_US.utf8 export LC_ALL=en_US.utf8[A] Konfigurasi akun pengguna (bl1adm).
# Set ulimit for bl1adm to unlimited root@azusbosl1:~> ulimit -f unlimited bl1adm root@azusbosl1:~> ulimit -u unlimited bl1adm root@azusbosl1:~> su - bl1adm bl1adm@azusbosl1:~> ulimit -a core file size (blocks, -c) unlimited data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 63936 max locked memory (kbytes, -l) 64 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) unlimited virtual memory (kbytes, -v) unlimited file locks (-x) unlimitedUnduh dan ekstrak media untuk platform SAP BusinessObjects BI dari SAP Service Marketplace.
Penginstalan
Periksa lokal akun pengguna bl1adm di server.
bl1adm@azusbosl1:~> locale
LANG=en_US.utf8
LC_ALL=en_US.utf8
Buka media platform SAP BOBI, dan jalankan perintah berikut dengan pengguna bl1adm:
./setup.sh -InstallDir /usr/sap/BL1
Ikuti Panduan Penginstalan platform SAP BOBI untuk Unix, khusus untuk versi Anda. Berikut beberapa poin yang perlu diingat saat Anda menginstal platform SAP BOBI:
Pada Konfigurasi Pendaftaran Produk, Anda dapat menggunakan kunci lisensi sementara untuk SAP BusinessObjects Solutions dari SAP Note 1288121, atau Anda dapat menghasilkan kunci lisensi di SAP Service Marketplace.
Pada Pilih Jenis Penginstalan, pilih penginstalan Penuh pada server pertama (
azusbosl1). Untuk server lainnya (azusbosl2), pilih Kustom / Perluas, yang akan memperluas penyiapan BOBI yang ada.Pada Pilih Database Default atau Yang Sudah Ada, pilih konfigurasi database yang sudah ada, yang akan meminta Anda untuk memilih database CMS dan audit. Pilih MySQL untuk jenis database ini.
Anda juga dapat memilih Tidak ada database audit, jika Anda tidak ingin mengonfigurasi audit selama penginstalan.
Pada layar Pilih Server Aplikasi Web Java, pilih opsi yang tepat berdasarkan arsitektur SAP BOBI Anda. Dalam contoh ini, kita telah memilih opsi 1, yang memasang server tomcat pada platform SAP BOBI yang sama.
Masukkan informasi database CMS di Konfigurasikan Database Repositori CMS - MySQL. Contoh berikut menunjukkan input untuk informasi database CMS untuk penginstalan Linux. Azure Database for MySQL digunakan pada port default 3306.
(Opsional) Masukkan informasi database audit dalam Mengonfigurasi Database Repositori Audit - MySQL. Contoh berikut menunjukkan input untuk informasi database audit untuk penginstalan Linux.
Ikuti instruksi dan masukkan input yang diperlukan untuk menyelesaikan penginstalan.
Untuk penyebaran multi-instans, jalankan penyiapan penginstalan di host kedua (azusbosl2). Untuk Pilih Jenis Penginstalan, pilih Kustom/Luaskan, yang akan meluaskan penyiapan BOBI yang ada.
Dalam Azure Database for MySQL, sebuah gateway mengarahkan ulang koneksi ke instans server. Setelah koneksi dibuat, klien MySQL menampilkan versi MySQL yang diatur di gateway, bukan versi yang berjalan pada instans server MySQL Anda. Untuk menentukan versi instans MySQL server Anda, gunakan SELECT VERSION(); perintah pada prompt MySQL. Untuk informasi selengkapnya, lihat Versi server Azure Database for MySQL yang didukung.
# Run direct query to the database using MySQL Workbench
select version();
+-----------+
| version() |
+-----------+
| 8.0.15 |
+-----------+
Setelah Penginstalan
Setelah penginstalan multi-instans platform SAP BOBI, Anda perlu melakukan langkah-langkah konfigurasi tambahan setelah penginstalan guna mendukung ketersediaan tinggi aplikasi.
Mengonfigurasi nama kluster
Dalam penyebaran multi-instans platform SAP BOBI, Anda ingin menjalankan beberapa server CMS secara bersamaan dalam satu kluster. Kluster terdiri dari dua server CMS atau lebih yang bekerja sama pada database sistem CMS umum. Jika node yang berjalan pada CMS gagal, simpul dengan CMS lain terus melayani permintaan platform BI. Secara default di platform SAP BOBI, nama kluster mencerminkan nama host CMS pertama yang Anda pasang.
Untuk mengonfigurasi nama kluster di Linux, ikuti instruksi dalam Panduan Administrator Platform Kecerdasan Bisnis SAP. Setelah mengonfigurasi nama kluster, ikuti SAP Note 1660440 untuk mengatur entri sistem default pada halaman masuk CMC atau BI launchpad.
Mengonfigurasi lokasi filestore input dan output untuk Azure NetApp Files
Filestore mengacu pada direktori disk tempat file SAP BusinessObjects yang sebenarnya berada. Lokasi default server repositori file untuk platform SAP BOBI terletak di direktori penginstalan lokal. Dalam penyebaran multi-instans, penting untuk mengatur filestore pada penyimpanan bersama, seperti Azure NetApp Files. Hal ini memungkinkan akses ke filestore dari semua server tingkat penyimpanan.
Jika Anda belum membuat volume NFS, buat di Azure NetApp Files. (Ikuti petunjuk di bagian sebelumnya "Memprovisikan Azure NetApp Files.")
Pasang volume NFS. (Ikuti instruksi pada bagian sebelumnya "Montase volume Azure NetApp Files.")
Ikuti SAP Note 2512660 untuk mengubah jalur repositori file (input dan output).
Replikasi sesi pada pengklusteran Tomcat
Tomcat mendukung pengklusteran dua server aplikasi atau lebih untuk replikasi sesi dan failover. Sesi platform SAP BOBI dijadikan serial, sehingga sesi pengguna dapat beralih dengan lancar ke instans Tomcat lain, bahkan ketika server aplikasi mengalami kegagalan.
Misalnya, pengguna terhubung ke server web yang gagal saat pengguna menavigasi hierarki folder di aplikasi SAP BI. Dengan kluster yang dikonfigurasi dengan benar, pengguna dapat terus menavigasi hierarki folder tanpa dialihkan ke halaman masuk.
Lihat SAP Note 2808640 untuk langkah-langkah mengonfigurasi pengklusteran Tomcat menggunakan multicast. Perhatikan bahwa Azure, bagaimanapun, tidak mendukung multicast. Jadi, agar kluster Tomcat berfungsi di Azure, Anda harus menggunakan StaticMembershipInterceptor (SAP Note 2764907). Untuk informasi selengkapnya, lihat posting blog Pengklusteran Tomcat menggunakan Keanggotaan Statis untuk Platform SAP BusinessObjects BI.
Tingkat web penyeimbangan beban platform SAP BI
Dalam penyebaran multi-instans SAP BOBI, server Aplikasi Web Java (tingkat web) berjalan pada dua host atau lebih. Untuk mendistribusikan muatan pengguna secara merata di seluruh server web, Anda dapat menggunakan penyeimbang muatan antara pengguna akhir dan server web. Di Azure, Anda dapat menggunakan Azure Load Balancer atau Azure Application Gateway untuk mengelola lalu lintas ke server aplikasi web Anda. Detail tentang setiap penawaran dijelaskan di bagian berikut.
Azure Load Balancer
Azure Load Balancer adalah penyeimbang beban lapisan 4 (TCP, UDP) dengan latensi rendah dan performa tinggi. Ini mendistribusikan lalu lintas di antara mesin virtual (VM) yang kondisinya baik. Probe kesehatan penyeimbang beban mengawasi port tertentu pada setiap VM dan hanya mendistribusikan lalu lintas ke VM yang operasional. Anda dapat memilih penyeimbang beban publik atau penyeimbang beban internal tergantung pada apakah Anda ingin agar platform SAP BI dapat diakses dari internet atau tidak. Ini adalah sistem redundansi zona, yang memastikan ketersediaan tinggi di seluruh zona.
Pada diagram berikut, lihat bagian Load Balancer Internal. Server aplikasi web berjalan pada port 8080, port HTTP Tomcat default, yang akan dipantau oleh pemantauan kesehatan. Setiap permintaan masuk yang berasal dari pengguna akhir dialihkan ke server aplikasi web (azusbosl1 atau azusbosl2). Load Balancer tidak mendukung penghentian TLS/SSL (juga dikenal sebagai offloading TLS/SSL). Jika Anda menggunakan Load Balancer untuk mendistribusikan lalu lintas di seluruh server web, gunakan Standard Load Balancer.
Catatan
Ketika mesin virtual tanpa alamat IP publik ditempatkan di kumpulan internal (tanpa alamat IP publik) Standard Load Balancer, tidak akan ada konektivitas internet keluar, kecuali Anda melakukan konfigurasi tambahan untuk memungkinkan perutean ke titik akhir publik. Untuk informasi selengkapnya, lihat Konektivitas titik akhir publik untuk Virtual Machines menggunakan Azure Standard Load Balancer pada skenario ketersediaan tinggi SAP.
Azure Application Gateway
Azure Application Gateway menyediakan Pengontrol Pengiriman Aplikasi (ADC) sebagai layanan. Layanan ini digunakan untuk membantu aplikasi mengarahkan lalu lintas pengguna ke satu server aplikasi web atau lebih. Ini menawarkan berbagai kemampuan penyeimbangan beban lapisan 7 seperti offloading TLS/SSL, firewall aplikasi web (WAF), dan afinitas sesi berbasis cookie.
Di platform SAP BI, Application Gateway mengarahkan lalu lintas web aplikasi ke sumber daya yang ditentukan, azusbosl1 atau azusbos2. Anda menetapkan pendengar ke port, membuat aturan, dan menambahkan sumber daya ke kumpulan. Dalam diagram berikut, Application Gateway memiliki alamat IP privat (10.31.3.20) yang bertindak sebagai titik entri untuk pengguna. Ini juga menangani koneksi TLS/SSL (HTTPS - TCP/443) yang masuk, mendekripsi TLS/SSL, dan meneruskan permintaan yang tidak terenkripsi (HTTP - TCP/8080) ke server. Ini menyederhanakan operasi untuk mempertahankan hanya satu sertifikat TLS/SSL di Application Gateway.
Untuk mengonfigurasi Application Gateway untuk server web SAP BOBI, lihat posting blog Load Balancing SAP BOBI Web Server menggunakan Azure Application Gateway.
Catatan
Azure Application Gateway lebih baik untuk menyeimbangkan beban lalu lintas ke server web. Ini menyediakan fitur yang bermanfaat, seperti pengurangan beban SSL, manajemen SSL terpusat untuk mengurangi overhead enkripsi dan dekripsi pada server, algoritma round-robin untuk mendistribusikan lalu lintas, kemampuan WAF serta ketersediaan yang tinggi.
Keandalan platform SAP BOBI pada Azure
Platform SAP BOBI mencakup berbagai tingkatan, yang dioptimalkan untuk tugas dan operasi tertentu. Ketika komponen dari satu tingkat menjadi tidak tersedia, aplikasi SAP BOBI menjadi tidak dapat diakses atau dibatasi dalam fungsionalitasnya. Pastikan bahwa setiap tingkatan dirancang agar dapat diandalkan untuk menjaga agar aplikasi tetap beroperasi tanpa gangguan bisnis.
Panduan ini menjelaskan bagaimana kombinasi fitur asli Azure dengan konfigurasi platform SAP BOBI dapat meningkatkan ketersediaan penyebaran SAP. Bagian ini fokus pada opsi berikut:
Pencadangan dan pemulihan: Ini adalah proses pembuatan salinan data dan aplikasi secara berkala ke lokasi terpisah. Anda dapat menyimpan ulang dan memulihkan ke kondisi sebelumnya jika data atau aplikasi asli hilang atau rusak.
Ketersediaan tinggi: Platform dengan ketersediaan tinggi memiliki setidaknya dua dari semua yang ada dalam wilayah Azure untuk menjaga agar aplikasi tetap beroperasi jika salah satu server menjadi tidak tersedia.
Pemulihan bencana: Ini adalah proses pemulihan fungsionalitas aplikasi Anda jika ada kehilangan besar seperti seluruh wilayah Azure menjadi tidak tersedia karena bencana alam.
Implementasi solusi ini bervariasi berdasarkan sifat penyiapan sistem di Azure. Sesuaikan solusi pencadangan dan pemulihan, ketersediaan tinggi, dan pemulihan bencana agar sesuai dengan kebutuhan bisnis Anda.
Pencadangan dan pemulihan
Pencadangan dan pemulihan adalah komponen penting dari strategi pemulihan bencana bisnis apa pun. Untuk mengembangkan strategi komprehensif untuk platform SAP BOBI, identifikasi komponen yang menyebabkan downtime sistem atau gangguan dalam aplikasi. Dalam platform SAP BOBI, pencadangan komponen berikut sangat penting untuk melindungi aplikasi:
- Direktori Penginstalan SAP BOBI (Disk Premium yang Terkelola)
- Server repositori berkas (Azure NetApp Files atau Azure Premium Files)
- Database CMS (Database Azure untuk MySQL atau database di Mesin Virtual Azure)
Bagian berikut menjelaskan cara mengimplementasikan strategi pencadangan dan pemulihan untuk setiap komponen ini.
Pencadangan dan pemulihan untuk direktori penginstalan SAP BOBI
Di Azure, cara paling sederhana untuk mencadangkan server aplikasi dan semua disk yang terpasang adalah dengan menggunakan Azure Backup. Azure Backup menyediakan cadangan independen dan terisolasi untuk melindungi dari kehancuran data yang tidak diinginkan di mesin virtual Anda. Cadangan disimpan dalam brankas layanan pemulihan, dengan manajemen titik pemulihan bawaan. Konfigurasi dan penskalaan dilakukan dengan sederhana, cadangan telah dioptimalkan, dan Anda bisa dengan mudah memulihkan saat diperlukan.
Sebagai bagian dari proses pencadangan, rekam jepret diambil dan data ditransfer ke brankas tanpa memengaruhi beban kerja produksi. Untuk informasi selengkapnya, lihat Konsistensi rekam jepret. Anda juga dapat memilih untuk mencadangkan subset disk data di mesin virtual Anda, dengan menggunakan fungsi pencadangan dan pemulihan disk selektif. Untuk informasi selengkapnya, lihat Pencadangan Azure VM dan FAQ - Mencadangkan Azure VM.
Pencadangan dan pemulihan untuk server repositori file
Berdasarkan penyebaran SAP BOBI Anda di Linux, Anda dapat menggunakan Azure NetApp Files sebagai filestore platform SAP BOBI Anda. Pilih dari opsi berikut untuk pencadangan dan pemulihan berdasarkan penyimpanan yang Anda gunakan untuk filestore.
Azure NetApp Files: Anda dapat membuat rekam jepret sesuai permintaan dan menjadwalkan rekam jepret otomatis menggunakan kebijakan rekam jepret. Salinan Snapshot menyediakan salinan volume Anda pada titik waktu tertentu. Untuk informasi selengkapnya, lihat Mengelola rekam jepret menggunakan Azure NetApp Files.
Jika Anda telah membuat server NFS terpisah, pastikan untuk mengimplementasikan strategi pencadangan dan pemulihan untuk server yang sama.
Mencadangkan dan memulihkan database CMS dan audit
Pada VM Linux, database CMS dan audit dapat berjalan pada salah satu database yang didukung. Untuk informasi selengkapnya, lihat matriks dukungan. Penting bagi Anda untuk mengadopsi strategi pencadangan dan pemulihan berdasarkan database yang digunakan untuk penyimpanan data sistem manajemen konten (CMS) dan audit.
Azure Database for MySQL secara otomatis membuat cadangan server, lalu menyimpannya di penyimpanan yang dikonfigurasi pengguna, penyimpanan redundan secara lokal, atau geo-redundan. Azure Database for MySQL mengambil cadangan berkas data dan log transaksi. Tergantung pada ukuran penyimpanan maksimum yang didukung, dibutuhkan pencadangan penuh dan diferensial (server penyimpanan maks 4 TB), atau cadangan rekam jepret (server penyimpanan maks hingga 16 TB). Cadangan ini memungkinkan Anda memulihkan server kapan saja dalam periode retensi cadangan yang dikonfigurasi. Periode retensi cadangan default adalah tujuh hari, yang dapat Anda konfigurasikan secara opsional hingga tiga hari. Semua cadangan dienkripsi menggunakan enkripsi AES-256 bit. File cadangan ini tidak terekspos pengguna dan tidak dapat diekspor. Cadangan ini hanya dapat digunakan untuk memulihkan operasi di Azure Database for MySQL. Anda dapat menggunakan mysqldump untuk menyalin database. Untuk informasi selengkapnya, lihat Pencadangan dan pemulihan di Azure Database for MySQL.
Untuk database yang dipasang pada mesin virtual Azure, Anda dapat menggunakan alat pencadangan standar atau Azure Backup untuk database yang didukung. Anda juga dapat menggunakan alat pencadangan pihak ketiga yang didukung dan menyediakan agen untuk pencadangan dan pemulihan semua komponen platform SAP BOBI.
Ketersediaan tinggi
Ketersediaan tinggi mengacu pada set teknologi yang dapat meminimalkan gangguan IT dengan memberikan kelangsungan bisnis aplikasi dan layanan. Ini dilakukan melalui komponen redundan, toleran terhadap kesalahan, atau failover yang dilindungi di pusat data yang sama. Dalam kasus kami, pusat data berada dalam satu wilayah Azure. Untuk informasi selengkapnya, lihat Arsitektur dan skenario dengan ketersediaan tinggi untuk SAP.
Berdasarkan hasil pengukuran platform SAP BOBI, Anda perlu merancang lanskap dan menentukan distribusi komponen BI di seluruh Azure Virtual Machines dan subnet. Tingkat redundansi dalam arsitektur terdistribusi tergantung pada tujuan waktu pemulihan (RTO) dan tujuan titik pemulihan (RPO) yang Anda perlukan untuk bisnis Anda. Platform SAP BOBI mencakup berbagai tingkatan, serta komponen pada setiap tingkatan harus dirancang untuk mencapai redundansi. Contohnya:
- Server aplikasi redundan seperti server aplikasi BI dan server web.
- Komponen unik, seperti database CMS, server repositori file, dan Load Balancer.
Bagian berikut menjelaskan cara mencapai ketersediaan tinggi pada masing-masing komponen platform SAP BOBI.
Ketersediaan tinggi untuk server aplikasi
Anda dapat mencapai ketersediaan tinggi untuk server aplikasi dengan menggunakan redundansi. Untuk melakukan ini, konfigurasi beberapa instans BI dan server web di berbagai Azure VM.
Untuk mengurangi dampak downtime karena peristiwa yang direncanakan dan tidak direncanakan, sebaiknya mengikuti panduan arsitektur ketersediaan tinggi.
Untuk informasi selengkapnya, lihat Mengelola ketersediaan mesin virtual Linux.
Penting
- Konsep Zona Ketersediaan Azure dan kumpulan ketersediaan Azure saling eksklusif. Anda dapat menyebarkan sepasang atau beberapa mesin virtual ke zona ketersediaan tertentu atau kumpulan ketersediaan, tetapi Anda tidak bisa melakukan keduanya sekaligus.
- Jika Anda berencana untuk menyebarkan di seluruh zona ketersediaan, disarankan untuk menggunakan set skala fleksibel dengan FD=1 melalui penyebaran zona ketersediaan standar.
Ketersediaan tinggi untuk database CMS
Jika Anda menggunakan Azure Database for MySQL untuk database CMS dan audit, Anda memiliki kerangka kerja ketersediaan tinggi yang redundan secara lokal secara default. Anda hanya perlu memilih wilayah dan layanan dengan kemampuan ketersediaan tinggi, redundansi, dan resiliensi yang melekat tanpa perlu mengonfigurasi komponen tambahan apa pun. Jika strategi penyebaran untuk platform SAP BOBI berada di seluruh zona ketersediaan, Anda harus memastikan bahwa Anda mencapai redundansi zona untuk database CMS dan audit Anda. Untuk informasi selengkapnya, lihat Ketersediaan tinggi pada Azure Database for MySQL dan Ketersediaan tinggi untuk Azure SQL Database.
Untuk penyebaran lainnya dari database CMS, lihat informasi tentang ketersediaan tinggi di Panduan penyebaran DBMS untuk Beban Kerja SAP.
Ketersediaan tinggi untuk penyimpanan file
Filestore mengacu pada direktori disk tempat konten seperti laporan, universe, dan koneksi disimpan. Ini dibagikan di semua server aplikasi dari sistem tersebut. Jadi Anda harus memastikan bahwa memiliki ketersediaan yang tinggi, bersama dengan komponen platform SAP BOBI lainnya.
Untuk platform SAP BOBI yang berjalan di Linux, Anda dapat memilih File Azure Premium atau Azure NetApp Files untuk berbagi file yang dirancang untuk ketersediaan tinggi dan tahan lama secara alami. Untuk informasi selengkapnya, lihat Redundansi untuk Azure Files.
Layanan berbagi file ini tidak tersedia di semua wilayah. Lihat Produk yang tersedia menurut wilayah untuk menemukan informasi terbaru. Jika layanan tersebut tidak tersedia di wilayah Anda, Anda dapat membuat server NFS tempat Anda dapat berbagi sistem file ke aplikasi SAP BOBI. Tetapi Anda juga perlu mempertimbangkan ketersediaannya yang tinggi.
Ketersediaan tinggi untuk Load Balancer
Untuk mendistribusikan lalu lintas di seluruh server web, Anda dapat menggunakan Azure Load Balancer atau Azure Application Gateway. Redundansi untuk salah satunya dapat dicapai berdasarkan SKU yang Anda pilih untuk penyebaran.
Untuk Azure Load Balancer, redundansi dapat dicapai dengan mengonfigurasi Standard Load Balancer sebagai redundan zona. Untuk informasi selengkapnya, lihat Standard Load Balancer dan Zona Ketersediaan.
Untuk Application Gateway, ketersediaan tinggi dapat dicapai berdasarkan jenis tingkatan yang dipilih selama penyebaran.
SKU v1 mendukung skenario ketersediaan tinggi ketika Anda telah menyebarkan dua atau lebih instans. Azure mendistribusikan instans ini ke seluruh domain pembaruan dan kesalahan untuk memastikan bahwa semua instans tidak gagal pada saat yang bersamaan. Anda mencapai redundansi di dalam zona.
SKU v2 secara otomatis memastikan bahwa instans baru tersebar di domain gangguan dan domain pemutakhiran. Jika Anda memilih redundansi zona, instans terbaru juga tersebar di seluruh zona ketersediaan guna menawarkan ketahanan terhadap kegagalan zona. Untuk detail selengkapnya, lihat Penskalaan Otomatis dan Application Gateway v2 yang Redundan Zona.
Referensi arsitektur ketersediaan tinggi untuk platform SAP BOBI
Diagram berikut menunjukkan penyiapan platform SAP BOBI yang berjalan di server Linux. Arsitektur menunjukkan penggunaan berbagai layanan, seperti Azure Application Gateway, Azure NetApp Files, dan Azure Database for MySQL. Layanan ini menawarkan redundansi bawaan, yang mengurangi kompleksitas saat mengelola berbagai solusi ketersediaan tinggi.
Perhatikan bahwa lalu lintas masuk (HTTPS) diseimbangkan menggunakan penyeimbang beban dengan Azure Application Gateway v1/v2 SKU, yang memiliki ketersediaan tinggi saat diterapkan pada lebih dari satu instans. Beberapa instans server web, server manajemen, dan server pemrosesan disebarkan dalam VM terpisah untuk mencapai redundansi. Azure NetApp Files memiliki redundansi bawaan dalam pusat data, sehingga volume Azure NetApp Files Anda untuk server repositori file akan memiliki ketersediaan tinggi. Database CMS disediakan di Azure Database for MySQL yang memiliki ketersediaan tinggi yang melekat. Untuk informasi selengkapnya, lihat Ketersediaan tinggi pada Azure Database for MySQL.
Arsitektur di atas memberikan wawasan tentang cara melakukan penyebaran SAP BOBI di Azure. Namun tidak mencakup semua opsi konfigurasi yang memungkinkan. Anda dapat menyesuaikan penyebaran Anda berdasarkan kebutuhan bisnis Anda.
Di beberapa wilayah Azure, Anda dapat menggunakan zona ketersediaan. Ini berarti Anda dapat memanfaatkan persediaan sumber daya, pendinginan, dan jaringan yang independen. Ini memungkinkan Anda untuk menyebarkan aplikasi di dua atau tiga zona ketersediaan. Jika Anda ingin mencapai ketersediaan tinggi di seluruh zona ketersediaan, Anda dapat menyebarkan platform SAP BOBI di seluruh zona ini, memastikan bahwa setiap komponen di dalam aplikasi adalah zona redundan.
Pemulihan dari bencana
Bagian ini menjelaskan strategi untuk memberikan perlindungan pemulihan bencana untuk platform SAP BOBI yang berjalan di Linux. Ini melengkapi dokumen Pemulihan Bencana untuk SAP, yang mewakili sumber daya utama untuk pendekatan pemulihan bencana SAP secara keseluruhan. Untuk SAP BOBI, lihat SAP Note 2056228, yang menjelaskan metode berikut untuk mengimplementasikan lingkungan pemulihan bencana dengan aman.
- Menggunakan manajemen siklus hidup atau federasi sepenuhnya atau secara selektif untuk mempromosikan dan mendistribusikan konten dari sistem utama.
- Menyalin ulang isi CMS dan server repositori file secara berkala.
Panduan ini berfokus pada opsi kedua. Ini tidak akan mencakup semua opsi konfigurasi yang mungkin untuk pemulihan bencana, tetapi mencakup solusi yang menampilkan layanan Azure asli dalam kombinasi dengan konfigurasi platform SAP BOBI.
Penting
- Ketersediaan setiap komponen pada platform SAP BOBI harus diperhitungkan di wilayah sekunder, dan Anda harus menguji secara menyeluruh semua strategi pemulihan bencana.
- Jika platform SAP BI Anda dikonfigurasi dengan set skala fleksibel dengan FD=1, maka Anda perlu menggunakan PowerShell untuk menyiapkan Azure Site Recovery untuk pemulihan bencana. Saat ini, ini adalah satu-satunya metode yang tersedia untuk mengonfigurasi pemulihan bencana untuk VM yang disebarkan dalam set skala.
Referensi arsitektur pemulihan bencana untuk platform SAP BOBI
Arsitektur referensi ini menjalankan penyebaran multi-instans dari platform SAP BOBI dengan server aplikasi yang redundan. Untuk pemulihan bencana, Anda harus mengalihkan semua komponen platform SAP BOBI ke wilayah sekunder. Dalam diagram berikut, Azure NetApp Files digunakan sebagai filestore, Azure Database for MySQL sebagai CMS dan repositori audit, dan Azure Application Gateway sebagai penyeimbang beban. Strategi untuk mencapai perlindungan pemulihan bencana untuk setiap komponen berbeda, dan perbedaan ini dijelaskan dalam bagian berikut.
Penyeimbang Beban
Penyeimbang beban digunakan untuk mendistribusikan lalu lintas di server aplikasi web dari platform SAP BOBI. Di Azure, Anda dapat menggunakan Azure Load Balancer atau Azure Application Gateway untuk tujuan ini. Untuk mencapai pemulihan bencana untuk layanan penyeimbang beban, Anda harus mengimplementasikan Azure Load Balancer atau Azure Application Gateway lainnya di wilayah sekunder. Untuk mempertahankan URL yang sama setelah failover pemulihan bencana, Anda harus mengubah entri pada server DNS yang menunjuk ke layanan penyeimbangan beban yang berjalan di wilayah sekunder.
Mesin virtual yang menjalankan server aplikasi web dan BI
Gunakan Azure Site Recovery untuk mereplikasi mesin virtual yang menjalankan server aplikasi web dan BI di wilayah sekunder. Ini mereplikasi server dan semua disk terkelola yang terpasang ke wilayah sekunder, sehingga saat terjadi bencana atau pemadaman, Anda dapat dengan mudah melakukan pengalihan ke lingkungan Anda yang direplikasi dan terus bekerja. Untuk memulai replikasi semua mesin virtual aplikasi SAP ke pusat data pemulihan bencana Azure, ikuti panduan di Mereplikasi mesin virtual ke Azure.
Server untuk repositori file
Filestore adalah direktori disk tempat file sebenarnya, seperti laporan dan dokumen BI, disimpan. Penting untuk semua file di filestore disinkronkan ke wilayah pemulihan bencana. Berdasarkan jenis layanan berbagi file yang Anda gunakan untuk platform SAP BOBI yang berjalan di Linux, strategi pemulihan bencana yang tepat perlu diadopsi untuk menyinkronkan konten.
Azure NetApp Files menyediakan volume NFS dan SMB, sehingga Anda bisa menggunakan alat penyalinan berbasis file untuk mereplikasi data antar wilayah Azure. Untuk informasi selengkapnya tentang cara menyalin volume di wilayah lain, lihat FAQ tentang Azure NetApp Files.
Anda bisa menggunakan replikasi lintas wilayah Azure NetApp Files, saat ini dalam pratinjau. Hanya blok yang diubah yang dikirim melalui jaringan dalam format yang terkompresi dan efisien. Ini meminimalkan jumlah data yang diperlukan untuk melakukan replikasi antar wilayah, menghemat biaya transfer data. Ini juga mempersingkat waktu replikasi, sehingga Anda dapat mencapai RPO yang lebih kecil. Untuk informasi selengkapnya, lihat Persyaratan dan pertimbangan untuk menggunakan replikasi lintas wilayah.
Azure premium files hanya mendukung penyimpanan redundan lokal (LRS) dan redundan zona (ZRS). Untuk strategi pemulihan bencana, Anda dapat menggunakan AzCopy atau Azure PowerShell untuk menyalin file ke akun penyimpanan lain di wilayah yang berbeda. Untuk informasi selengkapnya, lihat Pemulihan bencana dan kegagalan akun penyimpanan.
Penting
Protokol SMB untuk Azure Files umumnya tersedia, tetapi dukungan Protokol NFS untuk Azure Files saat ini dalam pratinjau. Untuk informasi selengkapnya, lihat Dukungan NFS 4.1 untuk Azure Files sekarang dalam pratinjau.
CMS Database
Database CMS dan audit di wilayah pemulihan bencana harus merupakan salinan database yang berjalan di wilayah utama. Berdasarkan jenis database, penting untuk menyalin database ke wilayah pemulihan bencana berdasarkan RTO dan RPO yang dibutuhkan bisnis Anda.
Azure Database for MySQL
Azure Database for MySQL menyediakan beberapa opsi untuk memulihkan database jika terjadi bencana. Pilih opsi yang tepat dan cocok untuk bisnis Anda.
replika untuk meningkatkan kelangsungan bisnis dan perencanaan pemulihan bencana Anda. Anda dapat mereplikasi dari server sumber maksimal lima replika. Replika baca diperbarui secara asinkron menggunakan teknologi replikasi log biner MySQL. Replika adalah server baru yang Anda kelola mirip dengan server biasa di Azure Database for MySQL. Untuk informasi selengkapnya, lihat Read Replicas di Azure Database for MySQL.
Gunakan fitur pemulihan geografis untuk memulihkan server dengan menggunakan cadangan geo-redundan. Cadangan ini dapat diakses bahkan ketika wilayah tempat server Anda dihosting sedang offline. Anda dapat memulihkan dari cadangan ini ke wilayah lain dan menjadikan server Anda kembali daring.
Catatan
Pemulihan geo hanya dimungkinkan jika Anda memprovisikan server dengan penyimpanan cadangan geo-redundan. Mengubah Opsi Redundansi Cadangan setelah server dibuat tidak dapat dilakukan. Untuk informasi selengkapnya, lihat artikel Redundansi Cadangan.
Tabel berikut menunjukkan rekomendasi untuk pemulihan bencana setiap tingkatan yang digunakan dalam contoh ini.
| Tingkat platform SAP BOBI | Rekomendasi |
|---|---|
| Azure Application Gateway | Penyiapan paralel Application Gateway di wilayah sekunder. |
| Server aplikasi web | Replikasi menggunakan Azure Site Recovery. |
| Server aplikasi BI | Replikasi menggunakan Site Recovery. |
| Azure NetApp Files | Alat penyalinan berbasis file untuk mereplikasi data ke wilayah sekunder, atau dengan menggunakan replikasi lintas wilayah. |
| Azure Database for MySQL | Replika baca lintas wilayah atau memulihkan cadangan dari cadangan yang bersifat geo-redundan. |