Edit

Penyebaran SAP di Azure menggunakan database Oracle

Azure ExpressRoute
SAP HANA on Azure Large Instances
Azure Virtual Machines
Azure Virtual Network
Azure NetApp Files

Arsitektur referensi ini menunjukkan serangkaian praktik yang terbukti untuk menjalankan SAP NetWeaver dengan Oracle Database di Azure. Prinsip arsitekturnya adalah OS-agnostik, namun, kecuali ditentukan lain, arsitektur diasumsikan didasarkan pada Linux.

Diagram pertama menunjukkan arsitektur referensi untuk SAP di Oracle di Azure. Arsitektur menggunakan set ketersediaan.

Diagram arsitektur sistem SAP produksi di Oracle di Azure.

Unduh file Visio arsitektur ini dan arsitektur terkait.

Catatan

Untuk menyebarkan arsitektur referensi ini, Anda memerlukan lisensi produk SAP yang sesuai dan teknologi non-Microsoft lainnya.

Komponen

Arsitektur referensi ini menjelaskan sistem produksi SAP umum yang berjalan di Oracle Database di Azure, dalam penyebaran yang sangat tersedia untuk memaksimalkan ketersediaan sistem. Arsitektur dan komponennya dapat disesuaikan berdasarkan persyaratan bisnis (RTO, RPO, harapan waktu aktif, peran sistem) dan berpotensi dikurangi menjadi satu VM. Tata letak jaringan disederhanakan untuk menunjukkan prinsip arsitektur lingkungan SAP tersebut dan tidak dimaksudkan untuk menggambarkan jaringan perusahaan penuh.

Jaringan

Jaringan virtual. Layanan Azure Virtual Network menghubungkan sumber daya Azure satu sama lain dengan keamanan yang ditingkatkan. Dalam arsitektur ini, jaringan virtual terhubung ke lingkungan lokal melalui gateway jaringan privat maya (VPN) yang disebarkan di hub topologi hub-spoke. Aplikasi dan database SAP terkandung dalam jaringan virtual spoke mereka sendiri. Jaringan virtual dibagi menjadi subnet terpisah untuk setiap tingkatan: aplikasi (SAP NetWeaver), database, dan layanan bersama (seperti Azure Bastion).

Arsitektur ini membagi ruang alamat jaringan virtual menjadi subnet. Tempatkan server aplikasi pada subnet dan server database terpisah di server lain. Melakukannya memungkinkan Anda untuk mengamankannya dengan lebih mudah dengan mengelola kebijakan keamanan subnet daripada server individual dan dengan bersih memisahkan aturan keamanan yang berlaku untuk database dari server aplikasi.

Peering jaringan virtual. Arsitektur ini menggunakan topologi jaringan hub-and-spoke dengan beberapa jaringan virtual yang di-peer bersama. Topologi ini menyediakan segmentasi dan isolasi jaringan untuk layanan yang disebarkan di Azure. Peering memungkinkan konektivitas transparan antara jaringan virtual di-peering melalui jaringan pusat Microsoft. Peering tidak dikenakan penalti performa jika disebarkan dalam satu wilayah.

Gateway zona redundan. Gateway menghubungkan jaringan yang berbeda, memperluas jaringan lokal Anda ke jaringan virtual Azure. Sebaiknya Anda menggunakan ExpressRoute untuk membuat koneksi privat yang tidak melalui internet publik, tetapi Anda juga dapat menggunakan koneksi site-to-site. Azure ExpressRoute atau gateway VPN dapat disebarkan di seluruh zona untuk menjaga dari kegagalan zona. Lihat Gateway jaringan virtual zona-redundan untuk memahami perbedaan antara penyebaran zona dan penyebaran zona-redundan. Perlu disebutkan di sini bahwa alamat IP yang digunakan harus dari SKU Standar untuk penyebaran zona gateway.

Kelompok keamanan jaringan. Untuk membatasi lalu lintas masuk, keluar, dan intra-subnet di jaringan virtual, buat grup keamanan jaringan yang pada gilirannya ditetapkan ke subnet tertentu. DB dan subnet aplikasi diamankan dengan NSG khusus beban kerja.

Kelompok keamanan aplikasi. Untuk menentukan kebijakan keamanan jaringan terperindeks di dalam NSG Anda berdasarkan beban kerja yang berpusat pada aplikasi, gunakan grup keamanan aplikasi alih-alih alamat IP eksplisit. Kelompok keamanan aplikasi memungkinkan Anda mengelompokkan mesin virtual berdasarkan nama dan membantu Anda mengamankan aplikasi dengan memfilter lalu lintas dari segmen tepercaya dari jaringan.

Kartu antarmuka jaringan (NIC). Kartu antarmuka jaringan memungkinkan semua komunikasi antara mesin virtual di jaringan virtual. Penyebaran SAP lokal tradisional menerapkan beberapa NIC per komputer untuk memisahkan lalu lintas administratif dari lalu lintas bisnis.

Di Azure, jaringan virtual adalah jaringan yang ditentukan perangkat lunak yang mengirimkan semua lalu lintas melalui struktur jaringan yang sama. Jadi tidak perlu menggunakan banyak NIC untuk alasan performa. Tetapi jika organisasi Anda perlu memisahkan lalu lintas, Anda dapat menyebarkan beberapa NIC per mesin virtual dan menghubungkan setiap NIC ke subnet yang berbeda. Anda kemudian dapat menggunakan grup keamanan jaringan untuk menerapkan kebijakan kontrol akses yang berbeda pada setiap subnet.

Azure NIC mendukung banyak IP. Dukungan ini sesuai dengan praktik yang disarankan SAP dalam menggunakan nama host virtual untuk penginstalan. Untuk ringkasan lengkap, lihat Catatan SAP 962955. (Untuk mengakses catatan SAP, Anda memerlukan akun SAP Service Marketplace.)

Mesin virtual

Arsitektur ini menggunakan komputer virtual (VM). Untuk tingkat aplikasi SAP, VM disebarkan untuk semua peran instans - dispatcher web dan server aplikasi - layanan pusat SAP (A)SCS dan ERS serta server aplikasi (PAS, AAS). Sesuaikan jumlah komputer virtual berdasarkan kebutuhan Anda. Panduan perencanaan dan penerapan Azure Virtual Machines mencakup detail tentang menjalankan SAP NetWeaver pada mesin virtual.

Demikian pula untuk semua tujuan Oracle komputer virtual digunakan, baik untuk Oracle Database maupun VM pengamat Oracle. VM pengamat dalam arsitektur ini lebih kecil dibandingkan dengan server database aktual.

  • VM vCPU yang dibatasi. Untuk berpotensi menghemat biaya pada lisensi Oracle, pertimbangkan untuk menggunakan VM yang dibatasi vCPU
  • Keluarga VM bersertifikat untuk SAP. Untuk detail tentang dukungan SAP untuk jenis mesin virtual Azure dan metrik throughput (SAPS), lihat SAP Note 1928533. (Untuk mengakses catatan SAP, Anda memerlukan akun SAP Service Marketplace.)

Grup Penempatan Kedekatan (PPG). Untuk mengoptimalkan latensi jaringan, Anda dapat menggunakan grup penempatan kedekatan, yang mendukung kolokasi, yang berarti bahwa komputer virtual berada di pusat data yang sama untuk meminimalkan latensi aplikasi. Grup penempatan kedekatan dapat meningkatkan pengalaman pengguna dengan signifikan untuk sebagian besar aplikasi SAP. Karena potensi pembatasan dengan PPG, menambahkan database AvSet ke PPG sistem SAP harus dilakukan secara jarang dan hanya jika diperlukan untuk latensi antara aplikasi SAP dan lalu lintas database. Untuk detail selengkapnya tentang skenario penggunaan untuk PPG, lihat dokumentasi tertaut.

Komputer virtual Generasi 2 (Gen2). Azure menawarkan pilihan saat menyebarkan VM jika harus generasi 1 atau 2. VM Generasi 2 mendukung fitur utama yang tidak tersedia untuk VM generasi 1. Terutama untuk database Oracle yang sangat besar, ini sangat penting karena beberapa keluarga VM seperti Mv2 atau Mdsv2 hanya didukung sebagai VM Gen2. Demikian pula, sertifikasi SAP di Azure untuk beberapa VM yang lebih baru mungkin mengharuskannya hanya Gen2 untuk dukungan penuh, bahkan jika Azure mengizinkan keduanya. Lihat detail di SAP Note 1928533 - Aplikasi SAP di Microsoft Azure: Produk yang Didukung dan jenis Azure VM.

Karena semua VM lain yang mendukung SAP memungkinkan pilihan Gen2 saja atau Gen1+2 secara selektif, disarankan untuk menyebarkan semua VM SAP sebagai Gen2, bahkan jika persyaratan memori sangat rendah. Bahkan VM terkecil sekali disebarkan sebagai Gen2 dapat diskalakan hingga yang terbesar yang tersedia dengan alokasi dan pengubahan ukuran sederhana. VM Gen1 hanya dapat diubah ukurannya menjadi keluarga VM yang diizinkan untuk menjalankan VM Gen1.

Penyimpanan

Arsitektur ini menggunakan disk terkelola Azure untuk komputer virtual dan Azure Files NFS atau Azure NetApp Files untuk persyaratan penyimpanan bersama NFS seperti volume NFS transportasi sapmnt dan SAP. Panduan untuk penyebaran penyimpanan dengan SAP di Azure terperinci dalam jenis Azure Storage untuk panduan beban kerja SAP

  • Penyimpanan bersertifikat untuk SAP. Mirip dengan jenis VM bersertifikat untuk penggunaan SAP, lihat detail dalam catatan SAP 2015553 dan catatan SAP 2039619.
  • Desain penyimpanan untuk SAP di Oracle. Anda dapat menemukan desain penyimpanan yang direkomendasikan untuk SAP di Oracle di Azure di penyebaran Azure Virtual Machines Oracle DBMS untuk beban kerja SAP. Artikel ini menyediakan panduan khusus tentang tata letak sistem file, rekomendasi ukuran disk, dan opsi penyimpanan lainnya.
  • Menyimpan file Oracle Database. Pada sistem file Linux ext4 atau xfs perlu digunakan untuk database, NTFS untuk penyebaran Windows. Oracle ASM juga didukung untuk penyebaran Oracle untuk Oracle Database 12c Release 2 dan yang lebih tinggi.
  • Alternatif untuk disk terkelola. Anda juga dapat menggunakan Azure NetApp Files untuk database Oracle. Untuk informasi selengkapnya, lihat catatan SAP 2039619 dan dokumentasi Oracle di Azure . Volume NFS Azure Files tidak ditujukan untuk menyimpan file Oracle Database, tidak seperti Azure NetApp Files.
  • Azure Premium SSD v2 dirancang untuk beban kerja kritis performa seperti SAP. Lihat Menyebarkan SSD Premium v2 untuk manfaat solusi penyimpanan ini dan batasannya saat ini.

Ketersediaan tinggi

Arsitektur sebelumnya menggambarkan penyebaran yang sangat tersedia, dengan setiap lapisan aplikasi yang terkandung pada dua atau beberapa komputer virtual. Komponen berikut digunakan.

Di Azure, penyebaran beban kerja SAP dapat berupa regional atau zonal, tergantung pada persyaratan ketersediaan dan ketahanan aplikasi SAP. Azure menyediakan opsi penyebaran yang berbeda, seperti Virtual Machine Scale Sets dengan orkestrasi fleksibel (FD=1), zona ketersediaan, dan set ketersediaan untuk meningkatkan ketersediaan sumber daya. Untuk mendapatkan pemahaman komprehensif tentang opsi penyebaran dan penerapannya di berbagai wilayah Azure (termasuk di seluruh zona, dalam satu zona, atau di wilayah tanpa zona), lihat Arsitektur dan skenario ketersediaan tinggi untuk SAP NetWeaver.

Load balancer.Azure Load Balancer digunakan untuk mendistribusikan lalu lintas ke komputer virtual di subnet SAP. Saat Anda menggabungkan Azure Load Balancer dalam penyebaran zona SAP, pastikan untuk memilih load balancer SKU Standar. Penyeimbang SKU Dasar tidak mendukung redundansi zona.

Pertimbangkan faktor keputusan saat menyebarkan VM di antara zona ketersediaan untuk SAP. Penggunaan grup penempatan kedekatan dengan penyebaran zona ketersediaan perlu dievaluasi dan hanya digunakan untuk VM tingkat aplikasi.

Catatan

Zona Ketersediaan mendukung ketersediaan tinggi intra-wilayah, tetapi tidak efektif untuk DR. Jarak antara zona terlalu pendek. Wilayah DR umumnya harus berjarak setidaknya 100 mil dari wilayah utama.

Komponen khusus Oracle. VM Oracle Database disebarkan dalam set ketersediaan atau di zona ketersediaan yang berbeda. Setiap VM berisi penginstalan perangkat lunak database dan penyimpanan database lokal VM sendiri. Siapkan replikasi database sinkron melalui Oracle Data Guard antara database untuk memastikan konsistensi dan memungkinkan waktu layanan RTO &RPO rendah jika terjadi kegagalan individual. Selain VM database, VM tambahan dengan Oracle Data Guard Observer diperlukan untuk penyiapan Failover Fast-Start Oracle Data Guard. VM pengamat Oracle memantau database dan status replikasi dan memfasilitasi failover database secara otomatis, tanpa perlu manajer kluster apa pun. Manajemen replikasi database dapat bertaruh yang dilakukan kemudian menggunakan Oracle Data Guard Broker untuk kemudahan penggunaan.

Untuk detail tentang penyebaran Oracle Data Guard lihat

Arsitektur ini menggunakan alat Oracle asli tanpa penyiapan kluster aktual atau kebutuhan akan load balancer di tingkat database. Dengan Oracle Data Guard Fast-Start Failover dan konfigurasi SAP, proses failover otomatis dan aplikasi SAP terhubung kembali ke database utama baru jika terjadi failover. Berbagai solusi kluster pihak ke-3 ada sebagai alternatif, seperti SIOS Protection Suite atau Veritas InfoScale, detail penyebaran mana yang dapat ditemukan di masing-masing dokumentasi vendor pihak ke-3.

Oracle RAC. Oracle Real Application Cluster (RAC) saat ini tidak disertifikasi atau didukung oleh Oracle di Azure. Namun teknologi dan arsitektur Oracle Data Guard untuk ketersediaan tinggi dapat memberikan lingkungan SAP yang sangat tangguh dengan perlindungan terhadap rak, pusat data, atau gangguan layanan regional.

Tingkat NFS. Untuk semua penyebaran SAP yang sangat tersedia, tingkat NFS tangguh harus digunakan, menyediakan volume NFS untuk direktori transportasi SAP, volume sapmnt untuk biner SAP serta volume lebih lanjut untuk instans (A)SCS dan ERS. Opsi untuk menyediakan tingkat NFS adalah

Kluster layanan pusat SAP. Arsitektur referensi ini menjalankan Layanan Pusat pada VM diskrit. Layanan Pusat berpotensi menjadi titik kegagalan tunggal (SPOF) saat disebarkan ke satu mesin virtual. Untuk menerapkan solusi yang sangat tersedia, perangkat lunak manajemen kluster diperlukan yang mengotomatiskan failover instans (A)SCS dan ERS ke VM masing-masing. Karena ini sangat terikat dengan solusi NFS yang dipilih

Solusi kluster yang dipilih memerlukan mekanisme untuk memutuskan jika perangkat lunak atau infrastruktur tidak tersedia VM mana yang harus melayani layanan masing-masing. Dengan SAP di Azure, dua opsi tersedia untuk implementasi STONITH berbasis Linux - cara menangani VM atau aplikasi yang tidak responsif

  • SUSE-Linux-onlySBD (STONITH Block Device) - menggunakan satu atau tiga VM tambahan yang berfungsi sebagai ekspor iSCSI dari perangkat blok kecil, yang diakses secara teratur oleh VM anggota kluster aktual, dua VM (A)SCS/ERS di kumpulan kluster ini. VM menggunakan pemasangan SBD ini untuk memberikan suara dan dengan demikian mencapai kuorum untuk keputusan kluster. Arsitektur yang terkandung di halaman ini TIDAK berisi 1 atau 3 VM SBD tambahan. RedHat tidak mendukung implementasi SBD apa pun di Azure dan dengan demikian opsi ini hanya tersedia untuk sistem operasi SUSE SLES.
  • Agen Azure Fence. Tanpa menggunakan VM tambahan, API manajemen Azure digunakan untuk pemeriksaan reguler untuk ketersediaan VM.

Panduan yang ditautkan dalam bagian tingkat NFS berisi langkah-langkah dan desain yang diperlukan untuk pilihan kluster masing-masing. Manajer kluster bersertifikat Azure pihak ketiga juga dapat digunakan untuk menyediakan ketersediaan tinggi layanan pusat SAP.

Kumpulan server aplikasi SAP. Dua atau beberapa server aplikasi di mana ketersediaan tinggi dicapai dengan permintaan penyeimbangan beban melalui server pesan SAP atau dispatcher web. Setiap server aplikasi independen dan tidak ada penyeimbangan beban jaringan yang diperlukan untuk kumpulan VM ini.

Kumpulan dispatcher web SAP. Komponen Web Dispatcher digunakan sebagai load balancer untuk lalu lintas SAP di antara beberapa server aplikasi SAP. Untuk mencapai ketersediaan tinggi SAP Web Dispatcher, Azure Load Balancer menerapkan kluster failover atau penyiapan Web Dispatcher paralel.

Embedded Web Dispatcher pada (A)SCS adalah opsi khusus. Anda harus memperhitungkan ukuran yang tepat karena beban kerja tambahan pada (A)SCS.

Untuk komunikasi yang terhubung ke internet, kami menyarankan solusi yang berdiri sendiri di jaringan sekitar (juga dikenal sebagai DMZ) untuk memenuhi masalah keamanan.

Penyebaran Windows. Dokumen ini, sebagaimana diawali pada awalnya, difokuskan terutama dengan penyebaran berbasis Linux. Untuk penggunaan dengan Windows, prinsip arsitektur yang sama berlaku dan tidak ada perbedaan arsitektur dengan Oracle antara Linux dan Windows.

Untuk bagian aplikasi SAP, lihat detail dalam panduan arsitektur Jalankan SAP NetWeaver di Windows di Azure.

Pertimbangan

Pemulihan dari bencana

Diagram berikut menunjukkan arsitektur sistem SAP produksi di Oracle di Azure. Arsitektur ini menyediakan DR dan menggunakan zona ketersediaan.

Diagram yang menunjukkan arsitektur sistem SAP produksi di Oracle di Azure.

Unduh file Visio arsitektur ini dan arsitektur terkait.

Setiap lapisan arsitektur dalam tumpukan aplikasi SAP menggunakan pendekatan yang berbeda untuk memberikan perlindungan DR. Untuk strategi DR dan detail implementasi, lihat Gambaran umum pemulihan bencana dan panduan infrastruktur untuk beban kerja SAP dan Panduan pemulihan bencana untuk aplikasi SAP.

Cadangan

Pencadangan untuk Oracle di Azure dapat dicapai melalui beberapa cara:

  • Azure Backup.Azure menyediakan dan memelihara skrip untuk Oracle Database, untuk memfasilitasi tindakan Oracle sebelum dan pasca eksekusi pencadangan.
  • Azure Storage. Menggunakan cadangan database berbasis file, misalnya dijadwalkan dengan alat BR SAP, untuk disimpan dan di-versi sebagai file/direktori di layanan penyimpanan Azure Blob NFS, Azure Blob, atau Azure Files. Lihat detail terdokumen cara mencapai data Oracle dan cadangan log.
  • Solusi pencadangan pihak ke-3. Lihat arsitektur penyedia penyimpanan cadangan Anda, mendukung Oracle di Azure.

Untuk VM non-database, Azure Backup untuk VM disarankan untuk melindungi VM aplikasi SAP dan infrastruktur sekitar seperti SAP Web Dispatcher.

Kontributor

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

Penulis utama:

Langkah berikutnya

Komunitas

Komunitas dapat menjawab pertanyaan dan membantu Anda menyiapkan penyebaran yang berhasil. Pertimbangkan sumber daya ini:

Lihat artikel ini untuk informasi selengkapnya dan untuk contoh beban kerja SAP yang menggunakan beberapa teknologi yang sama: