Bagikan melalui

Panduan penyebaran Platform BI BusinessObjects SAP untuk Windows di Azure

Artikel ini menjelaskan strategi untuk menyebarkan platform SAP BusinessObjects Business Intelligence (SAP BOBI) di Azure for Windows. Dalam contoh ini, dua komputer virtual (VM) yang dilengkapi Azure Premium SSD mengelola disk saat direktori penginstalan mereka dikonfigurasi. Azure SQL Database, penawaran platform as a service (PaaS), digunakan untuk server pengelolaan pusat (CMS) dan database audit. Azure Premium Files, protokol SMB, digunakan sebagai penyimpanan file yang dibagikan di kedua VM. Aplikasi web Tomcat Java default dan aplikasi platform kecerdasan bisnis BI sama-sama diinstal pada kedua VM. Untuk menyeimbangkan beban permintaan pengguna, Azure Application Gateway yang memiliki kemampuan offloading TLS / SSL asli digunakan.

Jenis arsitektur ini efektif untuk penyebaran kecil atau lingkungan non-produksi. Untuk penyebaran Produksi atau skala besar, sebaiknya memiliki host terpisah untuk aplikasi web dan Anda juga dapat memiliki beberapa host aplikasi SAP BOBI, yang memungkinkan server untuk memproses lebih banyak informasi.

Diagram yang memperlihatkan penyebaran SAP BOBI di Azure for Windows.

Dalam contoh ini, versi produk dan tata letak sistem file berikut digunakan:

  • Platform SAP BusinessObjects 4.3 SP01 Patch 1
  • Server Windows 2019
  • SQL Database (Versi: 12.0.2000.8)
  • Driver Microsoft ODBC - msodbcsql.msi (Versi: 13.1)
Sistem file Deskripsi Ukuran (GB) Akses yang diperlukan Penyimpanan
F: Sistem file untuk pemasangan instans SAP BOBI, aplikasi web Tomcat default, dan driver database (jika perlu). Panduan ukuran SAP Hak istimewa admin lokal Disk terkelola Azure Premium SSD
\\azusbobi.file.core.windows.net\frsinput Direktori pemasangan adalah untuk file bersama di semua host SAP BOBI yang akan digunakan sebagai direktori File Input. Kebutuhan bisnis Hak istimewa admin lokal File Azure NetApp
\\azusbobi.file.core.windows.net\frsoutput Direktori pemasangan adalah untuk file bersama di seluruh host SAP BOBI yang akan digunakan sebagai direktori File Output. Kebutuhan bisnis Hak istimewa admin lokal File Azure NetApp

Menyebarkan komputer virtual Windows melalui portal Microsoft Azure

Di bagian ini, kita akan membuat dua VM dengan citra sistem operasi (OS) Windows untuk platform SAP BOBI. Langkah tingkat tinggi untuk membuat VM adalah sebagai berikut:

  1. Buat grup sumber daya.

  2. Buat jaringan virtual:

    • Jangan gunakan satu subnet untuk semua layanan Azure dalam penyebaran platform SAP BI. Berdasarkan arsitektur platform SAP BI, Anda mungkin perlu membuat beberapa subnet. Dalam penyebaran ini, kita akan membuat dua subnet: subnet aplikasi BI dan subnet Application Gateway.
    • Ikuti SAP Note 2276646 guna mengidentifikasi port untuk komunikasi platform SAP BOBI di berbagai komponen.
    • SQL Database berkomunikasi melalui port 1433. Lalu lintas keluar melalui port 1433 harus diizinkan dari server aplikasi SAP BOBI Anda.
    • Di Azure, Application Gateway harus berada di subnet terpisah. Untuk informasi selengkapnya, lihat ringkasan konfigurasi Application Gateway.
    • Jika Anda menggunakan Azure NetApp Files untuk penyimpanan file, bukan Azure Files, buat subnet terpisah untuk Azure NetApp Files. Lihat Pedoman perencanaan jaringan Azure NetApp Files untuk detailnya.

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

  4. Membuat komputer virtual 1 (azuswinboap1):

  5. Membuat komputer virtual 2 (azuswinboap2).

  6. Tambahkan satu drive solid-state Premium. Ini akan digunakan sebagai direktori penginstalan SAP BOBI.

Ketentuan Azure Premium Files

Sebelum Anda melanjutkan penyiapan untuk Azure Files, pelajari dokumentasi Azure Files.

Azure Files menawarkan berbagi standar yang dihosting di perangkat keras berbasis HDD dan berbagi premium yang dihosting di perangkat keras berbasis SSD. Bagi penyimpanan file SAP BusinessObjects, gunakan Azure Premium Files.

Berbagi premium Azure tersedia dengan redundansi lokal dan zona di subset wilayah. Untuk mengetahui apakah berbagi premium saat ini tersedia di wilayah Anda, lihat Produk yang tersedia menurut wilayah. Untuk informasi tentang wilayah yang mendukung ZRS, lihat Redundansi Azure Storage.

Menerapkan akun penyimpanan file Azure dan berbagi NFS

berbagi file Azure disebarkan ke akun penyimpanan, yang merupakan objek tingkat atas yang mewakili gabungan penyimpanan bersama. Kumpulan penyimpanan ini dapat digunakan untuk menyebarkan beberapa berbagi file. Azure mendukung beberapa jenis akun penyimpanan untuk berbagai skenario penyimpanan yang mungkin dimiliki pelanggan. Untuk penyimpanan file SAP BusinessObjects, Anda perlu membuat akun FileStorage. Anda menggunakannya untuk menyebarkan berbagi file Azure pada perangkat keras berbasis Premium SSD.

Catatan

Akun FileStorage hanya dapat digunakan untuk menyimpan berbagi file Azure. Tidak ada sumber daya penyimpanan lain, seperti blob, kontainer, antrean, atau tabel, yang dapat digunakan dalam akun FileStorage.

Akun penyimpanan akan diakses melalui titik akhir privat dan disebarkan dalam jaringan virtual yang sama pada platform SAP BOBI. Dengan pengaturan ini, lalu lintas dari sistem SAP Anda tidak pernah meninggalkan batas keamanan jaringan virtual. Sistem SAP sering berisi data sensitif dan kritis bisnis, jadi tetap berada dalam batas-batas jaringan virtual adalah pertimbangan keamanan penting bagi banyak pelanggan.

Jika Anda perlu mengakses akun penyimpanan dari jaringan virtual yang berbeda, Anda dapat menggunakan penyambungan Microsoft Azure Virtual Network.

Akun penyimpanan file Azure

  1. Untuk membuat akun penyimpanan melalui portal Microsoft Azure, pilih Buat sumber daya>Penyimpanan>Akun penyimpanan.

  2. Pada tab Dasar, lengkapi semua bidang yang diperlukan untuk membuat akun penyimpanan:

    1. Pilih Langganan>Grup sumber daya>Wilayah.

    2. Masukkan Nama akun penyimpanan. Misalnya, masukkan azusbobi. Nama ini harus unik secara global, tapi Anda dapat memberikan nama sesuai keinginan.

    3. Pilih Premium sebagai tingkat performa, dan pilih FileStorage sebagai jenis akun.

    4. Untuk label Replikasi, pilih tingkat redundansi. Pilih Penyimpanan redundan lokal (LRS).

      Untuk Premium FileStorage, ZRS dan LRS adalah satu-satunya opsi yang tersedia. Berdasarkan strategi penyebaran VM Anda (set skala fleksibel, zona ketersediaan, atau set ketersediaan), pilih tingkat redundansi yang sesuai. Untuk informasi lebih lanjut, lihat Redundansi Azure Storage.

    5. Pilih Selanjutnya.

  3. Pada tab Jaringan, pilih titik akhir privat sebagai metode konektivitas. Untuk informasi lebih lanjut, lihat pertimbangan jaringan Azure Files.

    1. Pilih Tambahkan di bagian titik akhir privat.

    2. Pilih Langganan>Grup sumber daya>Lokasi.

    3. Masukkan Nama titik akhir privat tersebut. Misalnya, masukkan azusbobi-pe.

    4. Pilih file di sub-sumber daya penyimpanan.

    5. Pada bagian Jaringan, pilih Jaringan virtual dan Subnet tempat aplikasi SAP BusinessObjects BI disebarkan.

    6. Terima default (ya) untuk Mengintegrasikan dengan zona DNS privat.

    7. Pilih zona DNS privat Anda dari daftar drop-down.

    8. Pilih Oke untuk kembali ke tab Jaringan di Membuat akun penyimpanan.

  4. Di tab Perlindungan data, konfigurasikan kebijakan penghapusan sementara untuk berbagi file Azure di akun penyimpanan Anda. Secara default, fungsi penghapusan sementara dinonaktifkan. Untuk mempelajari penghapusan sementara lebih lanjut, lihat Cara mencegah penghapusan yang tidak disengaja untuk berbagi file Azure.

  5. Pada tab Tingkat Lanjut, pilih opsi keamanan yang berbeda.

    Bidang Transfer aman diperlukan menunjukkan apakah akun penyimpanan memerlukan enkripsi dalam transit untuk komunikasi ke akun penyimpanan. Jika memerlukan dukungan SMB 2.1, Anda harus menonaktifkan bidang ini. Untuk platform SAP BOBI, pertahankan di posisi default (diaktifkan).

  6. Lanjutkan dan buat akun penyimpanan.

Untuk detail tentang cara membuat akun penyimpanan, lihat Membuat akun penyimpanan FileStorage.

Buat berbagi berkas Azure

Langkah berikutnya adalah membuat file Azure di akun penyimpanan. File Azure menggunakan file yang diprovisikan untuk berbagi premium. Dalam model bisnis yang diprovisikan, Anda secara proaktif menentukan ke file Azure apa persyaratan penyimpanan Anda, bukan ditagih berdasarkan apa yang Anda gunakan. Untuk memahami selengkapnya tentang model ini, lihat Model yang diprovisikan. Dalam contoh ini, kami membuat dua file Azure: frsinput (256 GB) dan frsoutput (256 GB) untuk penyimpanan file SAP BOBI.

  1. Buka akun penyimpanan azusbobi>Berbagi.
  2. Pilih Berbagi baru.
  3. Masukkan Nama berbagi. Misalnya, masukkan frsinput atau frsoutput.
  4. Masukkan ukuran berbagi yang diperlukan dalam Kapasitas yang diprovisikan. Misalnya, masukkan 256 GB.
  5. Pilih SMB sebagai Protokol.
  6. Pilih Buat.

Mengonfigurasikan disk data di komputer virtual Windows

Langkah di bagian ini menggunakan awalan berikut:

[A]: Langkah ini berlaku untuk semua host.

Menginisialisasi disk data baru

Aplikasi SAP BusinessObjects BI mewajibkan partisi tempat binernya dapat diinstal. Anda dapat menginstal aplikasi SAP BOBI pada partisi OS (C:), tetapi Anda harus memastikan tersedia ruang yang cukup untuk penyebaran dan OS. Sebaiknya Anda memiliki minimal 2 GB yang tersedia untuk file sementara dan aplikasi web. Selain itu, sebaiknya pisahkan biner penginstalan SAP BOBI dalam partisi terpisah.

Dalam contoh ini, aplikasi SAP BOBI diinstal pada partisi terpisah (F:). Menginisialisasi disk Premium SSD yang Anda lampirkan selama provisi VM:

  1. [A] Jika tidak ada disk data yang dilampirkan pada VM (azuswinboap1 dan azuswinboap2), ikuti langkah-langkah dalam Menambahkan disk data untuk melampirkan disk data terkelola baru.
  2. [A] Setelah disk terkelola dilampirkan ke VM, inisialisasi disk dengan mengikuti langkah-langkah dalam Menginisialisasi disk data baru.

Memasang Azure Premium Files

Untuk menggunakan Azure Files sebagai penyimpanan file, Anda harus memasangnya. Artinya, Anda menetapkan huruf kandar untuknya atau memasang jalur titik.

[A] Untuk memasang berbagi file Azure, ikuti langkah-langkah dalam Memasang berbagi file Azure.

Untuk memasang berbagi file Azure di server Windows, protokol SMB mengharuskan port TCP 445 terbuka. Sambungan akan gagal jika port 445 diblokir. Anda dapat memeriksa apakah firewall atau ISP Anda memblokir port 445 dengan menggunakan Test-NetConnection cmdlet. Lihat Port 445 diblokir.

Mengonfigurasi database CMS: Azure SQL

Bagian ini menyediakan detail tentang cara memprovisikan Azure SQL dengan menggunakan portal Microsoft Azure. Bagian ini juga memberikan instruksi tentang cara membuat CMS dan database audit untuk platform SAP BOBI dan akun pengguna untuk mengakses database.

Panduan ini hanya berlaku jika Anda menggunakan SQL Database. Untuk database lain, lihat dokumentasi khusus SAP atau database untuk mendapatkan petunjuk.

Membuat tabel SQL Database

SQL Database menawarkan berbagai opsi penyebaran: database tunggal, kumpulan database elastis, dan server database. Untuk platform SAP BOBI, kita membutuhkan dua database, yaitu CMS dan audit. Alih-alih membuat dua database tunggal, Anda dapat membuat server SQL Database yang dapat mengelola grup database tunggal dan kumpulan database elastis. Ikuti langkah-langkah ini untuk membuat server SQL Database:

  1. Buka halaman Memilih opsi penyebaran SQL.

  2. Pada Database SQL, ubah Jenis sumber daya ke Server database. Pilih Buat.

  3. Pada tab Dasar, isi semua bidang yang diperlukan untuk Membuat Server SQL Database:

    1. Pada Detail proyek, pilih Langganan dan Grup sumber daya.

    2. Masukkan Nama server. Misalnya, masukkan azussqlbodb. Nama server harus unik secara global, tetapi Anda dapat memberikan nama apa pun yang Anda inginkan jika tidak menemukan nama yang unik.

    3. Pilih Lokasi.

    4. Masukkan Data masuk admin server. Misalnya, masukkan boadmin. Kemudian, masukkan Kata Sandi.

  4. Pada tab Jaringan, ubah Izinkan layanan dan sumber daya Azure untuk mengakses server ini ke Tidak pada Aturan firewall.

  5. Pada Pengaturan tambahan, pertahankan pengaturan default.

  6. Lanjutkan dan buat Server SQL Database.

Pada langkah selanjutnya, buat CMS dan database audit di server SQL Database (azussqlbodb.database.windows.net).

Membuat CMS dan database audit

Setelah Anda memprovisikan server SQL Database, buka sumber daya azussqlbodb. Kemudian, ikuti langkah-langkah ini untuk membuat CMS dan database audit.

  1. Pada halaman Gambaran umum azussqlbodb, pilih Buat database.

  2. Pada tab Dasar, isi semua bidang yang diperlukan:

    1. Masukkan Nama database. Misalnya, masukkan bocms atau boaudit.

    2. Pada opsi Komputasi + penyimpanan pilih Konfigurasi database. Pilih model yang sesuai berdasarkan hasil ukuran Anda. Untuk wawasan tentang opsi, lihat Model ukuran untuk Azure SQL Database.

  3. Pada tab Jaringan, pilih titik akhir privat untuk metode konektivitas. Titik akhir privat akan digunakan untuk mengakses SQL Database dalam jaringan virtual yang dikonfigurasi.

    1. Pilih Tambahkan titik akhir privat.

    2. Pilih Langganan>Grup sumber daya>Lokasi.

    3. Masukkan Nama titik akhir privat tersebut. Misalnya, masukkan azusbodb-pe.

    4. Di Sub-sumber daya target, pilih SqlServer.

    5. Pada bagian Jaringan, pilih Jaringan virtual dan Subnet tempat aplikasi SAP BusinessObjects BI disebarkan.

    6. Terima default (ya) untuk Mengintegrasikan dengan zona DNS privat.

    7. Pilih zona DNS privat Anda dari daftar drop-down.

    8. Pilih OK untuk kembali ke tab Jaringan di Membuat database SQL.

  4. Pada tab Pengaturan tambahan, ubah pengaturan Kolase menjadi SQL_Latin1_General_CP850_BIN2.

  5. Lanjutkan dan buat database CMS.

Anda juga dapat membuat database audit dengan langkah-langkah serupa. Misalnya, masukkan boaudit.

Unduh dan pasang driver ODBC

Server aplikasi SAP BOBI memerlukan driver/klien database untuk mengakses CMS atau database audit. Driver OdBC Microsoft digunakan untuk mengakses CMS dan database audit yang berjalan di SQL Database. Bagian ini menyediakan instruksi tentang cara mengunduh dan menyiapkan driver ODBC di Windows.

  1. Lihat bagian Dukungan repositori CMS + Audit menurut OS di Matriks Ketersediaan Produk (PAM) untuk platform SAP BusinessObjects BI untuk menemukan konektor database yang kompatibel dengan SQL Database.
  2. Unduh versi driver ODBC dari tautan. Dalam contoh ini, kami mengunduh driver ODBC 13.1.
  3. Pasang driver ODBC di semua server BI (azuswinboap1 dan azuswinboap2).
  4. Setelah Anda memasang driver di azuswinboap1, buka Mulai>Alat Administratif Windows>Sumber Data ODBC (64-bit).
  5. Buka tab Sistem DSN.
  6. Pilih Tambahkan untuk membuat koneksi ke database CMS.
  7. Pilih Driver ODBC 13 untuk SQL Server, lalu pilih Selesai.
  8. Masukkan informasi database CMS Anda seperti berikut ini, dan pilih Berikutnya:
    • Nama: Nama database yang dibuat di bagian "Buat CMS dan database audit". Misalnya, masukkan bocms atau boaudit.
    • Deskripsi: Deskripsi yang menjelaskan sumber data. Misalnya, masukkan Database CMS atau Database audit.
    • Server: Nama server yang dibuat di bagian "Buat server Database SQL". Misalnya, masukkan azussqlbodb.database.windows.net.
  9. Pilih Dengan autentikasi SQL Server menggunakan ID masuk dan kata sandi yang dimasukkan oleh pengguna untuk memverifikasi autentikasi ke Server Azure SQL. Masukkan kredensial pengguna yang dibuat saat pembuatan server SQL Database. Misalnya, masukkan boadmin. Pilih Selanjutnya.
  10. Ubah database default menjadi bocms, lalu biarkan pengaturan lainnya sebagai default. Pilih Selanjutnya.
  11. Pilih kotak centang Gunakan enkripsi kuat untuk data, lalu biarkan pengaturan lainnya sebagai default. Pilih Selesai.
  12. Sumber data ke database CMS telah dibuat. Sekarang Anda dapat memilih Uji Sumber Data untuk memvalidasi koneksi ke database CMS dari aplikasi BI. Proses ini harus berhasil diselesaikan. Jika proses gagal, pecahkan masalah konektivitas.

Catatan

SQL Database berkomunikasi melalui port 1433. Lalu lintas keluar melalui port 1433 harus diizinkan dari server aplikasi SAP BOBI Anda.

Ulangi langkah-langkah sebelumnya untuk membuat koneksi database audit di server azuswinboap1. Gunakan langkah-langkah serupa saat menginstal dan mengonfigurasi kedua sumber data ODBC (bocms dan boaudit) di semua server aplikasi BI (azuswinboap2).

Persiapan server

Ikuti panduan terbaru dari SAP untuk menyiapkan server penginstalan platform BI. Untuk mendapatkan informasi terbaru, lihat bagian "Persiapan" di Panduan Penginstalan Platform Kecerdasan Bisnis SAP untuk Windows.

Penginstalan

Untuk memasang platform BI pada host Windows, masuk dengan pengguna yang memiliki hak administratif lokal.

Buka media platform SAP BusinessObjects BI, dan jalankan setup.exe.

Ikuti instruksi di Panduan Penginstalan Platform Kecerdasan Bisnis SAP untuk Windows yang spesifik bagi versi Anda. Berikut beberapa poin yang perlu diingat saat Anda memasang platform SAP BOBI di Windows:

  • Pada layar Konfigurasi Folder Tujuan, berikan folder tujuan tempat Anda ingin memasang platform BI. Misalnya, masukkan F:\SAP BusinessObjects*.

  • Pada layar Konfigurasi Pendaftaran Produk, Anda dapat menggunakan kunci lisensi sementara untuk SAP BusinessObjects Solutions dari SAP Note 1288121 atau dapat menghasilkan kunci lisensi di SAP Service Marketplace.

  • Pada layar Pilih Jenis Penginstalan, pilih penginstalan Penuh pada server pertama (azuswinboap1). Untuk server lain (azuswinboap2), pilih Kustom/Luaskan, yang meluaskan pengaturan SAP BOBI yang ada.

  • Pada layar Pilih Database Default atau Yang Sudah Ada, pilih konfigurasi database yang sudah ada, yang akan meminta Anda untuk memilih CMS dan database Audit. Pilih Microsoft SQL Server menggunakan ODBC untuk jenis Database CMS dan jenis Database Audit.

    Anda juga dapat memilih Tidak ada database audit jika Anda tidak ingin mengonfigurasi audit selama penginstalan.

  • Pilih opsi yang sesuai pada layar Pilih Server Aplikasi Web Java 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 Konfigurasi Database Repositori CMS - SQL Server (ODBC). Gambar berikut memperlihatkan contoh input informasi database CMS untuk penginstalan Windows.

    Cuplikan layar yang memperlihatkan informasi database CMS untuk Windows.

  • (Opsional) Masukkan informasi database audit dalam Konfigurasi Database Audit - SQL Server (ODBC). Gambar berikut memperlihatkan contoh input informasi database audit untuk penginstalan Windows.

    Cuplikan layar yang memperlihatkan informasi database audit untuk Windows.

  • Ikuti instruksi dan masukkan input yang diperlukan untuk menyelesaikan penginstalan.

Untuk penyebaran multi-instans, jalankan penyiapan penginstalan pada host kedua (azuswinboap2). Pada layar Pilih Jenis Penginstalan, pilih Kustom/Luaskan, yang akan meluaskan penyiapan SAP BOBI yang sudah ada. Untuk informasi selengkapnya, lihat Penyiapan platform Kecerdasan Bisnis SAP BusinessObjects dengan Azure SQL Database di blog SAP.

Penting

Nomor versi mesin database untuk SQL Server dan SQL Database tidak dapat dibandingkan satu sama lain. Mesin tersebut adalah nomor build internal untuk produk terpisah ini. Mesin database untuk SQL Database didasarkan pada basis kode yang sama dengan mesin database SQL Server. Yang paling penting, mesin database di SQL Database selalu memiliki bit mesin SQL Database terbaru. SQL Database sersi 12 lebih baru dari SQL Server versi 15.

Untuk mengetahui versi SQL Database saat ini, Anda dapat memeriksa pengaturan Konsol Pengelolaan Pusat (Central Management Console/CMC) atau menjalankan kueri berikut dengan menggunakan sqlcmd atau SQL Server Management Studio. Perataan versi SQL ke kompatibilitas default dapat ditemukan di artikel tingkat kompatibilitas database.

Cuplikan layar yang memperlihatkan informasi database di CMC. 

1> select @@version as version;
2> go
version
------------------------------------------------------------------------------------------
Microsoft SQL Azure (RTM) - 12.0.2000.8
        Feb 20 2021 17:51:58
        Copyright (C) 2019 Microsoft Corporation

(1 rows affected)

1> select name, compatibility_level from sys.databases;
2> go
name                                                                  compatibility_level
--------------------------------------------------------------------- -------------------
master                                                                                150
bocms                                                                                 150
boaudit                                                                               150

(3 rows affected)

Setelah Penginstalan

Setelah penginstalan multi-instans platform SAP BOBI, langkah-langkah konfigurasi tambahan setelah penginstalan perlu dilakukan untuk 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 simpul yang berjalan pada CMS gagal, simpul dengan CMS lain akan 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 Windows, 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 penyimpanan file input dan output untuk Azure Premium Files

Penyimpanan file 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 menyiapkan filestore pada penyimpanan bersama seperti Azure Premium Files atau Azure NetApp Files sehingga filestore dapat diakses dari semua server tingkat penyimpanan.

  1. Jika tidak dibuat, ikuti instruksi yang diberikan di bagian sebelumnya, "Provisikan Azure Premium Files", untuk membuat dan memasang Azure Premium Files.

    Tip

    Berdasarkan apakah komputer virtual disebarkan secara zonal atau regional, pemilihan redundansi penyimpanan untuk Azure Premium Files (ZRS atau LRS) harus ditentukan.

  2. Ikuti SAP Note 2512660 untuk mengubah jalur repositori file (Input dan Output).

Pengklusteran Tomcat - Replikasi sesi

Tomcat mendukung pengklusteran dua server aplikasi atau lebih untuk replikasi sesi dan pengalihan. Jika sesi platform SAP BOBI diserialisasikan, sesi pengguna dapat mengalihkan dengan lancar ke instans tomcat lain, bahkan ketika server aplikasi gagal. Misalnya, jika pengguna tersambung 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.

Dalam SAP Note 2808640, langkah-langkah untuk mengonfigurasikan pengklusteran tomcat disediakan menggunakan multicast. Tetapi multicast tidak didukung di Azure. Jadi untuk membuat kluster Tomcat berfungsi di Azure, Anda harus menggunakan StaticMembershipInterceptor (SAP Note 2764907). Untuk menyiapkan klaster Tomcat di Azure, lihat pengklusteran Tomcat menggunakan keanggotaan statis untuk platform BI SAP BusinessObjects di blog SAP.

Memuat keseimbangan tingkat web 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. Anda dapat menggunakan Azure Load Balancer atau Azure Application Gateway untuk mengelola lalu lintas ke server aplikasi web Anda. Metode ini dijelaskan di bagian berikut:

  • Azure Load Balancer adalah penyeimbang muatan lapisan 4 (TCP, UDP) dengan latensi rendah dan performa tinggi yang mendistribusikan lalu lintas di antara VM yang sehat. Pemeriksaan kondisi penyeimbang muatan memantau port tertentu pada setiap VM dan hanya mendistribusikan lalu lintas ke VM operasional. Anda dapat memilih penyeimbang muatan publik atau penyeimbang muatan internal tergantung pada apakah Anda ingin agar Platform SAP BI dapat diakses dari internet atau tidak. Memiliki redundansi zona, memastikan ketersediaan tinggi di seluruh zona ketersediaan.

    Pada gambar berikut, lihat bagian "Internal Load Balancer" di mana server aplikasi web berjalan pada port 8080 (port HTTP Tomcat default), yang akan dipantau oleh pemeriksaan kesehatan. Setiap permintaan masuk yang berasal dari pengguna akhir akan dialihkan ke server aplikasi web (azuswinboap1 atau azuswinboap2) di kumpulan ujung belakang. Azure Load Balancer tidak mendukung Penghentian TLS/SSL, yang juga dikenal sebagai offloading TLS/SSL. Jika Anda menggunakan Azure Load Balancer untuk mendistribusikan lalu lintas di seluruh server web, sebaiknya gunakan Standard Load Balancer.

    Catatan

    Ketika VM tanpa alamat IP publik ditempatkan di kumpulan back-end internal (tidak ada alamat IP publik) Standard Load Balancer, tidak akan ada konektivitas internet keluar, kecuali konfigurasi tambahan dilakukan untuk memungkinkan perutean ke titik akhir publik. Untuk detail tentang cara mencapai konektivitas keluar, lihat Konektivitas titik akhir publik untuk komputer virtual menggunakan Azure Standard Load Balancer dalam skenario ketersediaan tinggi SAP.

    Cuplikan layar yang memperlihatkan Load Balancer digunakan untuk menyeimbangkan lalu lintas di seluruh server web.

  • Azure Application Gateway menyediakan pengontrol pengiriman aplikasi sebagai layanan, yang digunakan untuk membantu aplikasi mengarahkan lalu lintas pengguna ke satu atau beberapa server aplikasi web. Ini menawarkan berbagai kemampuan load-balancing lapisan 7 seperti offloading TLS / SSL, Web Application Firewall, dan afinitas sesi berbasis cookie untuk aplikasi Anda.

    Di Platform SAP BI, Application Gateway mengarahkan lalu lintas web aplikasi ke sumber daya yang ditentukan di kumpulan ujung belakang. Dalam hal ini, mungkin berupa azuswinboap1 atau azuswinboap2. Anda menetapkan pendengar ke port, membuat aturan, lalu menambahkan sumber daya ke kumpulan ujung belakang. Dalam gambar berikut, Application Gateway dengan alamat IP front-end pribadi (10.31.3.25) bertindak sebagai titik masuk bagi pengguna, menangani koneksi TLS / SSL (HTTPS - TCP/ 443) yang masuk, mendekripsi TLS / SSL, dan meneruskan permintaan (HTTP - TCP / 8080) ke server di kumpulan back-end. Dengan fitur penghentian TLS/ SSL bawaan, kita hanya perlu mempertahankan satu sertifikat TLS/SSL pada gateway aplikasi, yang menyederhanakan operasi.

    Cuplikan layar yang memperlihatkan Application Gateway digunakan untuk menyeimbangkan lalu lintas di seluruh server web.

    Untuk mengonfigurasi Application Gateway untuk Server Web SAP BOBI, lihat Menyeimbangkan muatan server web SAP BOBI menggunakan Application Gateway di blog SAP.

    Catatan

    Gunakan Application Gateway untuk menyeimbangkan muatan lalu lintas ke server web karena menyediakan fitur seperti offloading SSL, manajemen SSL terpusat untuk mengurangi enkripsi dan overhead dekripsi pada server, algoritma round-robin untuk mendistribusikan lalu lintas, kemampuan Web Application Firewall, dan ketersediaan tinggi.

Keandalan Platform SAP BusinessObjects BI di Azure

Platform SAP BusinessObjects BI mencakup berbagai tingkatan, yang dioptimalkan untuk tugas dan operasi tertentu. Ketika komponen dari satu tingkat menjadi tidak tersedia, aplikasi SAP BOBI akan menjadi tidak dapat diakses atau fungsi tertentu dari aplikasi tidak akan berfungsi. Jadi perlu untuk memastikan bahwa setiap tingkatan dirancang agar dapat diandalkan untuk menjaga agar aplikasi tetap beroperasi tanpa gangguan bisnis.

Panduan ini akan menjelajahi bagaimana kombinasi fitur asli Azure dengan konfigurasi platform SAP BOBI dapat meningkatkan ketersediaan penyebaran SAP. Bagian ini berfokus pada opsi berikut untuk keandalan Platform SAP BOBI di Azure:

  • Pencadangan dan pemulihan: Proses ini membuat salinan data dan aplikasi berkala ke lokasi terpisah. Jika data atau aplikasi asli hilang atau rusak, salinan dapat digunakan untuk memulihkan atau memulihkan ke keadaan sebelumnya.
  • 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 (DR): Proses ini mengembalikan fungsionalitas aplikasi Anda jika ada kerugian besar. Misalnya, seluruh wilayah Azure mungkin menjadi tidak tersedia karena bencana alam.

Implementasi solusi ini bervariasi berdasarkan sifat penyiapan sistem di Azure. Anda perlu menyesuaikan solusi pencadangan dan pemulihan, ketersediaan tinggi, dan DR berdasarkan kebutuhan bisnis Anda.

Pencadangan dan pemulihan

Pencadangan dan pemulihan adalah proses pembuatan salinan data dan aplikasi berkala ke lokasi terpisah sehingga dapat dipulihkan atau dipulihkan ke keadaan sebelumnya jika data atau aplikasi asli hilang atau rusak. Ini juga merupakan komponen penting dari setiap strategi DR bisnis. Cadangan ini memungkinkan pemulihan aplikasi dan database ke titik-dalam waktu dalam periode penyimpanan yang dikonfigurasi.

Untuk mengembangkan strategi pencadangan dan pemulihan yang komprehensif untuk platform SAP BOBI, identifikasi komponen yang mengarah pada downtime sistem atau gangguan dalam aplikasi. Dalam Platform SAP BOBI, pencadangan komponen berikut sangat penting untuk melindungi aplikasi:

  • Direktori Penginstalan SAP BOBI (Disk Premium Terkelola)
  • Filestore (Azure Premium Files atau Azure NetApp Files untuk instalasi terdistribusi)
  • CMS dan database audit (SQL Database, Azure Database for MySQL, atau database di Azure Virtual Machines)

Bagian berikut menjelaskan cara mengimplementasikan strategi pencadangan dan pemulihan untuk setiap komponen di Platform SAP BOBI.

Pencadangan dan pemulihan untuk direktori penginstalan SAP BOBI

Di Azure, cara paling sederhana untuk mencadangkan VM dan semua disk yang terpasang adalah dengan menggunakan Azure Backup. Azure Backup menyediakan cadangan yang independen dan terisolasi dengan tujuan melindungi dari penghancuran data yang tidak diinginkan di VM Anda. Cadangan disimpan dalam vault Layanan Pemulihan dengan manajemen titik pemulihan bawaan. Konfigurasi dan penskalaan itu sederhana. Cadangan dioptimalkan dan dapat dipulihkan dengan mudah saat diperlukan.

Sebagai bagian dari proses pencadangan, rekam jepret diambil. Data ditransfer ke vault Layanan Pemulihan tanpa efek pada beban kerja produksi. Rekam jepret memberikan tingkat konsistensi yang berbeda seperti yang dijelaskan dalam artikel Konsistensi rekam jepret. Backup juga menawarkan dukungan berdampingan untuk pencadangan disk terkelola dengan menggunakan cadangan disk Azure selain solusi cadangan Azure VM. Hal ini berguna saat Anda memerlukan cadangan VM yang konsisten setiap harinya dan cadangan disk OS yang lebih sering, atau disk data tertentu, yang secara konsisten mengalami error. Untuk informasi selengkapnya, lihat Tentang pencadangan Azure VM, cadangan disk Azure, dan FAQ: Mencadangkan Azure VMs.

Pencadangan dan pemulihan untuk filestore

Berdasarkan penyebaran Anda, filestore platform SAP BOBI dapat berada di Azure NetApp Files atau Azure Files. 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 rekam jepret menyediakan salinan volume Azure NetApp Files Anda dalam waktu tertentu. Untuk informasi selengkapnya, lihat Mengelola rekam jepret menggunakan Azure NetApp Files.
  • Azure Files: Cadangan File Azure terintegrasi dengan contoh asli Cadangan,yang memusatkan fungsi pencadangan dan pemulihan bersama dengan cadangan VM dan menyederhanakan pekerjaan operasi. Untuk informasi selengkapnya, lihat Cadangan file berbagi Azure dan FAQ: Mencadangkan Azure Files.

Jika Anda telah membuat server NFS terpisah, pastikan untuk mengimplementasikan strategi kembali dan pulihkan untuk hal yang sama.

Pencadangan dan pemulihan untuk CMS dan database audit

Untuk Platform SAP BOBI yang berjalan di mesin virtual Linux, database CMS dan audit dapat berjalan pada salah satu database yang didukung seperti yang dijelaskan dalam matriks dukungan panduan perencanaan dan implementasi platform SAP BOBI di Azure. Jadi penting bagi Anda untuk mengadopsi strategi pencadangan dan pemulihan berdasarkan database yang digunakan untuk penyimpanan data CMS dan audit.

  • SQL Database menggunakan teknologi SQL Server untuk membuat cadangan penuh setiap minggu, pencadangan diferensial setiap 12 hingga 24 jam, dan pencadangan log transaksi setiap 5 hingga 10 menit. Frekuensi pencadangan log didasarkan pada ukuran komputasi dan jumlah aktivitas database.

    Pengguna dapat memilih opsi untuk mengonfigurasi redundansi penyimpanan cadangan antara gumpalan LRS, ZRS, atau GRS. Mekanisme redundansi penyimpanan menyimpan beberapa salinan data Anda sehingga terlindungi dari peristiwa yang terencana dan tidak terencana, termasuk kegagalan perangkat keras sementara, pemadaman jaringan atau listrik, atau bencana alam besar. Secara default, SQL Database menyimpan data dalam blob GRS yang direplikasi ke wilayah yang dipasangkan. Ini dapat diubah berdasarkan persyaratan bisnis untuk gumpalan LRS atau ZRS. Untuk informasi selengkapnya tentang penjadwalan pencadangan, penyimpanan, dan konsumsi penyimpanan SQL Database, lihat Pencadangan otomatis: Azure SQL Database dan Azure SQL Managed Instance.

  • Azure Database untuk MySQL secara otomatis membuat cadangan server dan menyimpan di LRS atau GRS yang dikonfigurasi pengguna. Azure Database for MySQL mengambil cadangan berkas data dan log transaksi. Tergantung ukuran penyimpanan maksimum yang didukung, dibutuhkan cadangan penuh dan diferensial (server penyimpanan maks 4-TB) atau cadangan rekam jepret (hingga server penyimpanan maks 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 konfigurasi 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 diinstal pada Azure VM, Anda bisa menggunakan alat cadangan standar atau Cadangan untuk database yang didukung. Selain itu, jika Layanan dan alat Azure tidak memenuhi persyaratan Anda, Anda dapat menggunakan alat cadangan pihak ketiga yang didukung yang menyediakan agen untuk pencadangan dan pemulihan semua komponen platform SAP BOBI.

Ketersediaan tinggi

Ketersediaan Tinggi mengacu pada serangkaian teknologi yang dapat meminimalkan gangguan IT dengan menyediakan kelangsungan bisnis aplikasi/layanan melalui komponen yang redundan, toleran terhadap kesalahan, atau yang dilindungi kegagalan di dalam pusat data yang sama. Dalam kasus kami, pusat data berada dalam satu wilayah Azure. Artikel Arsitektur dan Skenario Ketersediaan Tinggi untuk SAP memberikan wawasan awal tentang berbagai teknik ketersediaan tinggi dan rekomendasi yang ditawarkan di Azure untuk Aplikasi SAP, yang akan melengkapi instruksi di bagian ini.

Berdasarkan hasil ukuran Platform SAP BOBI, Anda perlu merancang lanskap dan menentukan distribusi komponen BI di seluruh Azure VM dan subnet. Tingkat redundansi dalam arsitektur terdistribusi tergantung pada tujuan waktu pemulihan (RTO) yang diperlukan bisnis dan tujuan titik pemulihan (RPO). Platform SAP BOBI mencakup berbagai tingkatan dan komponen pada setiap tingkatan harus dirancang untuk mencapai redundansi. Sehingga jika satu komponen gagal, ada sedikit atau tidak ada gangguan pada aplikasi SAP BOBI Anda. Contohnya:

  • Server aplikasi berlebihan seperti server aplikasi BI dan server web
  • Komponen unik seperti database CMS, filestore, dan load balancer

Bagian berikut menjelaskan cara mencapai ketersediaan tinggi pada masing-masing komponen Platform SAP BOBI.

Ketersediaan tinggi untuk server aplikasi

BI dan server aplikasi web tidak memerlukan solusi ketersediaan tinggi tertentu, tidak peduli apakah mereka diinstal secara terpisah atau bersama-sama. Anda dapat mencapai ketersediaan tinggi dengan redundansi, yaitu dengan mengonfigurasi beberapa instans BI dan server web di berbagai Azure VM. Anda dapat menyebarkan VM dalam set skala fleksibel, set ketersediaan, atau zona ketersediaan berdasarkan RTO yang diperlukan bisnis. Untuk penyebaran di seluruh zona ketersediaan, pastikan semua komponen lain di platform SAP BOBI dirancang agar zona juga redundansi.

Saat ini, tidak semua wilayah Azure menawarkan zona ketersediaan, jadi Anda perlu mengadopsi strategi penyebaran berdasarkan wilayah Anda. Wilayah Azure yang menawarkan zona tercantum di zona ketersediaan Azure.

Penting

  • Konsep Zona Ketersediaan Azure dan kumpulan ketersediaan Azure saling eksklusif. Anda dapat menyebarkan sepasang atau beberapa mesin virtual ke zona ketersediaan tertentu atau set ketersediaan, tetapi Anda tidak dapat melakukan keduanya.
  • 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 layanan Azure Database as a Service (DBaaS) untuk database CMS dan audit, kerangka kerja ketersediaan tinggi yang redundan secara lokal disediakan secara default. Pilih wilayah dan layanan yang melekat pada kemampuan ketersediaan tinggi, redundansi, dan ketahanan tanpa mengharuskan Anda mengonfigurasikan komponen lagi. Jika strategi penyebaran untuk Platform SAP BOBI berada di seluruh Zona Ketersediaan, maka Anda perlu memastikan Anda mencapai redundansi zona untuk database CMS dan audit Anda. Untuk informasi selengkapnya tentang penawaran ketersediaan tinggi untuk penawaran DBaaS yang didukung di Azure, periksa Ketersediaan tinggi di Azure SQL Database dan Ketersediaan tinggi untuk Azure Database for MySQL

Untuk penyebaran sistem manajemen database (DBMS) lainnya untuk database CMS, lihat panduan penyebaran DBMS untuk beban kerja SAP untuk wawasan tentang penyebaran DBMS yang berbeda dan pendekatannya untuk mencapai ketersediaan tinggi.

Ketersediaan tinggi untuk filestore

Filestore mengacu pada direktori disk tempat konten seperti laporan, universe, dan koneksi disimpan. Filestore dibagikan di semua server aplikasi dari sistem tersebut. Jadi Anda harus memastikan bahwa filestore memiliki ketersediaan tinggi, bersama dengan komponen platform SAP BOBI lainnya.

Untuk Platform SAP BOBI yang berjalan di Linux, Anda dapat memilih Azure Premium Files atau Azure NetApp Files untuk filestore, yang dirancang agar memiliki ketersediaan tinggi dan sangat tahan lama di alam. Azure Premium Files mendukung ZRS, yang dapat berguna untuk penyebaran lintas zona platform SAP BOBI. Untuk informasi selengkapnya, lihat bagian Redundansi untuk Azure Files.

Karena layanan berbagi file tidak tersedia di semua wilayah, pastikan Anda melihat daftar 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 bagi load balancer

Untuk mendistribusikan lalu lintas di seluruh server web, Anda dapat menggunakan Load Balancer atau Application Gateway. Redundansi untuk salah satu load balancer tersebut dapat dicapai berdasarkan SKU yang Anda pilih untuk melakukan penyebaran:

  • Load Balancer: Redundansi dapat dicapai dengan mengonfigurasi ujung depan Standard Load Balancer sebagai zona redundan. Untuk informasi selengkapnya, lihat Standard Load Balancer dan zona ketersediaan.
  • Application Gateway: Ketersediaan tinggi dapat dicapai berdasarkan jenis tingkatan yang dipilih selama penyebaran:
    • SKU v1 mendukung skenario ketersediaan tinggi ketika Anda telah menyebarkan dua instans atau lebih. Azure mendistribusikan instans ini ke seluruh domain pembaruan dan kesalahan untuk memastikan bahwa semua instans tidak gagal pada saat yang bersamaan. Jadi dengan SKU ini, redundansi dapat dicapai dalam zona.
    • SKU v2 secara otomatis memastikan bahwa instans baru tersebar di seluruh domain kesalahan dan memperbarui domain. Jika Anda memilih redundansi zona, instans terbaru juga akan tersebar di seluruh zona ketersediaan untuk menawarkan resiliensi kegagalan zona. Untuk informasi selengkapnya, lihat Penskalaan otomatis dan zona redundan Application Gateway v2.

Arsitektur referensi ketersediaan tinggi untuk platform SAP BusinessObjects BI

Arsitektur referensi berikut menjelaskan pengaturan platform SAP BOBI di seluruh zona ketersediaan yang berjalan di server Windows. Arsitekturnya menampilkan penggunaan layanan Azure yang berbeda seperti Application Gateway, Azure Premium Files (filestore), dan SQL Database (database CMS dan audit). Platform SAP BOBI menawarkan redundansi zona bawaan, yang mengurangi kompleksitas pengelolaan berbagai solusi ketersediaan tinggi.

Pada gambar berikut, lalu lintas masuk (HTTPS - TCP/443) diseimbangkan dengan menggunakan SKU Application Gateway v2, yang mencakup beberapa zona ketersediaan. Gateway aplikasi mendistribusikan permintaan pengguna di server web, yang didistribusikan di seluruh zona ketersediaan. Server web meneruskan permintaan ke manajemen dan memproses instans server yang disebarkan di VM terpisah di seluruh zona ketersediaan. Azure Premium Files dengan ZRS dilampirkan melalui tautan pribadi ke VM tingkat manajemen dan penyimpanan untuk mengakses konten seperti laporan, semesta, dan koneksi. Aplikasi mengakses database audit dan CMS yang berjalan pada instans SQL Database dengan zona redundan, yang mereplikasi database di beberapa lokasi fisik dalam wilayah Azure.

Diagram yang menunjukkan arsitektur ketersediaan tinggi untuk platform SAP BOBI di Windows.

Arsitektur di atas memberikan wawasan tentang cara melakukan penyebaran SAP BOBI di Azure. Namun tidak mencakup semua kemungkinan opsi konfigurasi untuk Platform SAP BOBI di Azure. Anda dapat menyesuaikan penyebaran berdasarkan kebutuhan bisnis dengan memilih produk atau layanan yang berbeda untuk komponen seperti Load Balancer, Server Repositori File, dan DBMS.

Jika zona ketersediaan tidak tersedia di wilayah yang dipilih, Anda dapat menyebarkan VM Azure di kumpulan ketersediaan. Azure memastikan bahwa VM yang Anda tempatkan dalam kumpulan ketersediaan berjalan di beberapa server fisik, rak komputasi, unit penyimpanan, dan pengalihan jaringan. Jika kegagalan perangkat keras atau perangkat lunak terjadi, hanya subset VM Anda yang terpengaruh dan solusi keseluruhan tetap beroperasi.

Pemulihan dari bencana

Bagian ini menjelaskan strategi guna memberikan perlindungan DR untuk platform SAP BOBI. Platform ini melengkapi dokumen Pemulihan bencana untuk SAP, yang mewakili sumber daya utama untuk pendekatan SAP DR secara keseluruhan. Untuk platform SAP BOBI, lihat SAP Note 2056228, yang menjelaskan metode berikut untuk mengimplementasikan lingkungan DR dengan aman:

  • Gunakan sepenuhnya atau secara selektif federasi atau Manajemen Siklus Hidup untuk mempromosikan atau mendistribusikan konten dari sistem utama.
  • Menyalin konten CMS dan FRS secara berkala.

Dalam panduan ini, kami akan membahas opsi kedua untuk mengimplementasikan lingkungan DR. Kami tidak akan membahas daftar lengkap semua kemungkinan opsi konfigurasi untuk DR. Kami akan membahas solusi yang menampilkan layanan Azure asli yang dikombinasikan dengan konfigurasi platform SAP BOBI.

Penting

  • Ketersediaan setiap komponen dalam platform SAP BOBI harus diperhitungkan ke wilayah sekunder. Seluruh strategi DR harus diuji secara menyeluruh.
  • 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.

Arsitektur DR referensi untuk platform SAP BusinessObjects BI

Arsitektur referensi ini menjalankan penyebaran multi-instans dari platform SAP BOBI dengan server aplikasi yang redundan. Untuk DR, Anda harus mengalihkan semua komponen platform SAP BOBI ke wilayah sekunder. Pada gambar berikut, Azure Premium Files digunakan sebagai filestore, SQL Database digunakan sebagai repositori audit serta CMS, dan Application Gateway digunakan untuk menyeimbangkan beban lalu lintas. Strategi guna mencapai perlindungan DR untuk setiap komponen itu berbeda, yang dijelaskan pada bagian berikut.

Diagram yang menunjukkan DR platform SAP BusinessObjects BI untuk Windows.

Load Balancer

Load Balancer 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 menyeimbangkan beban lalu lintas di seluruh server web. Guna mencapai DR untuk layanan load balancer, Anda perlu menerapkan load balancer atau gateway aplikasi lain pada wilayah sekunder. Untuk mempertahankan URL yang sama setelah failover DR, ubah entri di DNS dan arahkan ke layanan load balance yang berjalan pada wilayah sekunder.

Komputer virtual yang menjalankan server aplikasi web dan BI

Layanan Azure Site Recovery dapat digunakan untuk mereplikasi VM yang menjalankan server aplikasi web dan BI di wilayah sekunder. Layanan ini mereplikasi server dan semua disk terkelola yang terpasang di wilayah sekunder sehingga ketika bencana dan pemadaman terjadi, Anda dapat dengan mudah melakukan pengalihan ke lingkungan yang direplikasi dan terus berfungsi. Untuk mulai mereplikasi semua VM aplikasi SAP ke pusat data Azure DR, ikuti panduan di Mereplikasi komputer virtual ke Azure.

FileStore

Filestore adalah direktori disk tempat file sebenarnya seperti laporan dan dokumen BI disimpan. Penting bahwa semua file di filestore disinkronkan ke wilayah DR. Berdasarkan jenis layanan berbagi file yang Anda gunakan untuk platform SAP BOBI yang berjalan di Windows, strategi DR yang diperlukan perlu diadopsi untuk menyinkronkan konten. Contohnya:

  • Azure Premium Files hanya mendukung LRS dan ZRS. Untuk strategi DR File Premium Azure, Anda dapat menggunakan AzCopy atau Azure PowerShell untuk menyalin file Anda ke akun penyimpanan lain di wilayah lain. Untuk informasi selengkapnya, lihat Pemulihan bencana dan kegagalan akun penyimpanan.

  • Azure NetApp Files menyediakan volume NFS dan SMB, sehingga alat penyalinan berbasis file apa pun dapat digunakan untuk mereplikasi data antar wilayah Azure. Untuk informasi selengkapnya tentang cara menyalin volume Azure NetApp Files di wilayah lain, lihat FAQ tentang Azure NetApp Files.

    Anda dapat menggunakan Replikasi Lintas Wilayah Azure NetApp Files, saat ini dalam pratinjau, yang menggunakan teknologi NetApp SnapMirror. Dengan teknologi ini, hanya blok yang diubah yang dikirim melalui jaringan dalam format terkompresi dan efisien. Teknologi kepemilikan ini meminimalkan jumlah data yang diperlukan untuk melakukan replikasi di seluruh wilayah, yang menghemat biaya transfer data. Teknologi 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.

Database CMS

Database CMS dan audit di wilayah DR harus merupakan salinan database yang berjalan di wilayah utama. Berdasarkan jenis database, penting untuk menyalin database ke wilayah DR berdasarkan RTO dan RPO yang diperlukan bisnis. Bagian ini menjelaskan berbagai opsi yang tersedia untuk setiap solusi database di Azure yang didukung untuk aplikasi SAP BOBI yang berjalan di Windows.

Database Azure SQL

Untuk strategi DR SQL Database, dua opsi tersedia guna menyalin database ke wilayah sekunder. Kedua opsi pemulihan menawarkan tingkat RTO dan RPO yang berbeda. Untuk informasi selengkapnya tentang RTO dan RPO untuk setiap opsi pemulihan, lihat Memulihkan database ke server yang sudah ada.

Opsi 1: Pemulihan cadangan database geo-redundan

Secara default, SQL Database menyimpan data dalam blob GRS yang direplikasi ke wilayah yang dipasangkan. Untuk database SQL, redundansi penyimpanan cadangan dapat dikonfigurasi pada saat pembuatan database audit dan CMS, atau database tersebut dapat diperbarui untuk database yang sudah ada. Perubahan yang dibuat pada database yang ada hanya berlaku untuk pencadangan di masa mendatang. Anda dapat memulihkan database pada database SQL apa pun di wilayah Azure mana pun dari cadangan replikasi geografis terbaru. Pemulihan geografis menggunakan cadangan replikasi geografis sebagai sumbernya. Ada penundaan antara ketika cadangan diambil dan ketika cadangan direplikasi secara geografis ke blob Azure di wilayah yang berbeda. Akibatnya, database yang dipulihkan bisa hingga satu jam di belakang database asli.

Penting

Pemulihan geografis tersedia untuk database SQL yang dikonfigurasi dengan penyimpanan cadangan geo-redundan.

Opsi 2: Replikasi geografis atau grup failover otomatis

Replikasi geografis adalah fitur SQL Database yang memungkinkan Anda membuat database sekunder yang dapat dibaca dari database individu pada server di wilayah yang sama atau berbeda. Jika replikasi geografis diaktifkan untuk database CMS dan audit, aplikasi dapat memulai failover ke database sekunder di wilayah Azure yang berbeda. Geo-replikasi diaktifkan untuk database individual, tetapi untuk mengaktifkan failover transparan dan terkoordinasi dari beberapa database (CMS dan audit) untuk aplikasi SAP BOBI, disarankan untuk menggunakan grup failover otomatis. Grup ini menyediakan semantik grup di atas replikasi geografis aktif, yang berarti seluruh server SQL (semua database) direplikasi ke wilayah lain, bukan ke database individual. Periksa tabel kapabilitas yang membandingkan replikasi geografis dengan grup failover.

Grup failover otomatis menyediakan titik akhir pendengar baca/tulis dan baca-saja yang tetap tidak berubah selama failover. Peserta baca/tulis dapat dipertahankan sebagai pendengar dalam entri koneksi ODBC untuk database CMS dan audit. Baik Anda menggunakan aktivasi failover manual atau otomatis, failover akan mengalihkan semua database sekunder di grup ke primer. Setelah failover database selesai, catatan DNS secara otomatis akan diperbarui untuk mengalihkan titik akhir ke wilayah baru. Aplikasi ini secara otomatis terhubung ke database CMS karena peserta baca /tulis dipertahankan sebagai pendengar dalam koneksi ODBC.

Dalam gambar berikut, grup failover otomatis untuk server SQL (azussqlbodb) yang berjalan di wilayah US Timur 2 direplikasi ke wilayah sekunder AS Timur (situs DR). Peserta pendengar baca/tulis dipertahankan sebagai pendengar dalam koneksi ODBC untuk server aplikasi BI yang berjalan di Windows. Setelah failover, peserta akan tetap sama. Tidak diperlukan intervensi manual untuk menghubungkan aplikasi BI ke database SQL pada wilayah sekunder.

Cuplikan layar yang memperlihatkan grup failover otomatis SQL Database.

Opsi ini menyediakan RTO dan RPO yang lebih rendah daripada opsi 1. Untuk informasi selengkapnya tentang opsi ini, lihat Menggunakan grup failover otomatis untuk mengaktifkan failover transparan dan terkoordinasi dari beberapa database.

Azure Database untuk MySQL

Azure Database for MySQL menyediakan opsi untuk memulihkan database jika ada bencana. Pilih opsi yang sesuai dan cocok untuk bisnis Anda:

  • Aktifkan replika baca lintas wilayah untuk meningkatkan kelangsungan bisnis dan perencanaan DR Anda. Anda dapat membuat maksimal lima replikasi server sumber. Replika baca diperbarui secara asinkron dengan menggunakan teknologi replikasi log biner Azure Database for MySQL. Replika adalah server baru yang Anda kelola hampir sama dengan server Azure Database for MySQL biasa. Untuk mempelajari selengkapnya tentang replika baca, wilayah yang tersedia, pembatasan, dan cara mengalihkan, lihat Membaca replika di Azure Database for MySQL.

  • Gunakan fitur pemulihan geografis Azure Database for MySQL yang memulihkan server 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 membawa server Anda kembali daring.

    Penting

    Pemulihan geo hanya dimungkinkan jika Anda memprovisikan server dengan penyimpanan cadangan geo-redundan. Mengubah opsi redundansi cadangan setelah pembuatan server tidak didukung. Untuk informasi selengkapnya, lihat artikel Redundansi Cadangan.

Tabel berikut mencantumkan rekomendasi untuk DR bagi setiap tingkatan yang digunakan dalam contoh ini.

Tingkat platform SAP BOBI Rekomendasi
Azure Application Gateway atau Azure Load Balancer Penyiapan paralel Application Gateway pada wilayah sekunder
Server aplikasi web Mereplikasi menggunakan Azure Site Recovery
Server aplikasi BI Replikasi menggunakan Site Recovery
Azure Premium Files AzCopy atau Azure PowerShell
File Azure NetApp Alat penyalinan berbasis file untuk mereplikasi data ke wilayah sekunder atau Pratinjau Replikasi Lintas Wilayah Azure NetApp Files
Database Azure SQL Replikasi geografis/grup failover otomatis atau pemulihan geografis
Azure Database untuk MySQL Replika baca lintas wilayah atau cadangan pemulihan dari cadangan geo-redundan

Langkah berikutnya