Penyebaran DBMS SQL Server Azure Virtual Machines untuk SAP Netweaver
Dokumen ini mencakup beberapa area berbeda untuk dipertimbangkan saat menyebarkan SQL Server untuk beban kerja SAP di Azure IaaS. Sebagai prasyarat untuk dokumen ini, baca dokumen Pertimbangan untuk penyebaran DBMS Azure Virtual Machines untuk beban kerja SAP dan panduan lain dalam beban kerja SAP pada dokumentasi Azure.
Penting
Cakupan dokumen ini adalah versi Windows di SQL Server. SAP tidak mendukung SQL Server versi Linux dengan perangkat lunak SAP apa pun. Dokumen ini tidak membahas Microsoft Azure SQL Database, yang merupakan Platform sebagai penawaran Layanan dari Microsoft Azure Platform. Diskusi dalam dokumen ini adalah tentang cara menjalankan produk SQL Server seperti yang dikenal untuk penyebaran lokal di Azure Virtual Machines, memanfaatkan Infrastruktur sebagai kemampuan Layanan Azure. Kemampuan dan fungsionalitas database antara kedua penawaran ini berbeda dan tidak boleh dicampur satu sama lain. Untuk informasi selengkapnya, lihat Azure SQL Database.
Secara umum, Anda harus mempertimbangkan menggunakan rilis SQL Server terbaru untuk menjalankan beban kerja SAP di Azure IaaS. Rilis SQL Server terbaru menawarkan integrasi yang lebih baik ke dalam beberapa layanan dan fungsionalitas Azure. Atau memiliki perubahan yang mengoptimalkan operasi dalam infrastruktur Azure IaaS.
Dokumentasi umum tentang SQL Server yang berjalan di Azure Virtual Machines (VM) dapat ditemukan di artikel ini:
- SQL Server di Azure Virtual Machines (Windows)
- Mengotomatiskan manajemen dengan ekstensi Agen Infrastruktur sebagai Layanan SQL Server Windows
- Mengonfigurasi integrasi Azure Key Vault untuk SQL Server di Azure VM (Resource Manager)
- Daftar Periksa: Praktik terbaik untuk SQL Server di Komputer Virtual Azure
- Penyimpanan: Praktik terbaik performa untuk SQL Server di Azure VM
- Praktik terbaik konfigurasi HADR (SQL Server di Azure VM)
Tidak semua konten dan pernyataan yang dibuat dalam dokumentasi SQL Server umum di Azure VM berlaku untuk beban kerja SAP. Tapi, dokumentasi memberikan kesan yang baik pada prinsip-prinsip. Contoh untuk fungsionalitas yang tidak didukung untuk beban kerja SAP adalah penggunaan pengklusteran FCI.
Ada beberapa informasi spesifik terkait SQL Server di IaaS yang harus Anda ketahui sebelum melanjutkan:
- Dukungan Versi SQL: Bahkan dengan Catatan SAP #1928533 yang menyatakan bahwa rilis SQL Server minimum yang didukung adalah SQL Server 2008 R2, jendela versi SQL Server yang didukung di Azure juga ditentukan dengan siklus hidup SQL Server. Pemeliharaan diperpanjang SQL Server 2012 berakhir pertengahan 2022. Akibatnya, rilis minimum saat ini untuk sistem yang baru disebarkan harus SQL Server 2014. Semakin baru, semakin baik. Rilis SQL Server terbaru menawarkan integrasi yang lebih baik ke dalam beberapa layanan dan fungsionalitas Azure. Atau memiliki perubahan yang mengoptimalkan operasi dalam infrastruktur Azure IaaS.
- Menggunakan Gambar dari Azure Marketplace: Cara tercepat untuk menyebarkan Microsoft Azure VM baru adalah dengan menggunakan gambar dari Azure Marketplace. Terdapat berbagai gambar di Azure Marketplace, yang berisi rilis SQL Server terbaru. Gambar di mana SQL Server sudah terpasang tidak dapat segera digunakan untuk aplikasi SAP NetWeaver. Alasannya adalah kolase SQL Server default diinstal dalam gambar tersebut dan bukan kolase yang diperlukan untuk sistem SAP NetWeaver. Untuk menggunakan gambar tersebut, periksa langkah-langkah yang didokumentasikan dalam bab Menggunakan gambar SQL Server dari Microsoft Azure Marketplace.
- Dukungan SQL Server multi-instance dalam satu Azure VM: Metode penyebaran ini didukung. Namun, waspadai keterbatasan sumber daya, terutama di sekitar jaringan dan bandwidth penyimpanan dari jenis VM yang Anda gunakan. Informasi terperinci tersedia dalam artikel Ukuran untuk mesin virtual di Azure. Batasan kuota ini dapat mencegah Anda dalam menerapkan arsitektur multi-instans yang sama seperti yang dapat Anda terapkan di lokal. Mengenai konfigurasi dan gangguan berbagi sumber daya yang tersedia dalam satu mesin virtual, pertimbangkan juga skenario yang sama di lokal.
- Beberapa database SAP dalam satu instans SQL Server dalam satu VM: Konfigurasi seperti ini didukung. Pertimbangan beberapa database SAP yang berbagi sumber daya dari satu instans SQL Server sama dengan untuk penerapan di tempat. Ingatlah batasan lain seperti jumlah disk yang dapat dilampirkan ke jenis VM tertentu. Atau batasan kuota jaringan dan penyimpanan dari jenis VM tertentu sebagai Ukuran untuk mesin virtual di Azure.
VM seri M baru dan SQL Server
Azure merilis beberapa keluarga baru SKU seri M di bawah keluarga Mv3. Beberapa jenis VM dalam keluarga ini tidak boleh digunakan untuk SQL Server, termasuk SQL Server 2022 tanpa menonaktifkan SMT (Hyperthreading) di OS tamu Windows Server. Alasannya adalah jumlah simpul NUMA yang disajikan ke dalam OS tamu Windows Server yang dengan lebih besar dari 64 vCPU terlalu besar untuk diakomodasi SQL Server. Dengan menonaktifkan SMT di OS tamu Windows Server, jumlah vCPU semakin berkurang. Jadi, jumlah vCPU kurang dari 64 di setiap simpul NUMA. Cara menonaktifkan SMT dijelaskan di sini. Jenis VM tertentu adalah:
- M176(d)s_3_v3 - nonaktifkan SMT atau gunakan M176bds_4_v3 atau M176bds_4_v3 sebagai alternatif
- M176(d)s_4_v3 - nonaktifkan SMT atau gunakan M176bds_4_v3 sebagai alternatif
- M624(d)s_12_v3 - nonaktifkan SMT atau gunakan M416ms_v2 sebagai alternatif
- M832(d)s_12_v3 - nonaktifkan SMT atau gunakan M416ms_v2 sebagai alternatif
- M832i(d)s_16_v3 - nonaktifkan SMT atau gunakan M416ms_v2 sebagai alternatif
Catatan
Dengan beberapa jenis VM M(b)v3 baru, penggunaan penyimpanan SSD v1 Premium yang di-cache dapat mengakibatkan tingkat dan throughput IOPS baca dan tulis yang lebih rendah daripada yang Akan Anda dapatkan jika Anda tidak menggunakan cache baca.
Rekomendasi tentang struktur VM/VHD untuk penyebaran SQL Server terkait SAP
Sesuai dengan deskripsi umum, sistem Operasi, SQL Server yang dapat dieksekusi, SAP yang dapat dieksekusi hari ditempatkan atau diinstal disk Azure terpisah. Biasanya, sebagian besar database sistem SQL Server tidak digunakan pada tingkat tinggi dengan beban kerja SAP NetWeaver. Namun demikian database sistem dari SQL Server harus, berada bersama dengan direktori SQL Server lainnya pada disk Azure terpisah. SQL Server tempdb harus terletak di drive D:\ nonperisisted atau pada disk terpisah.
- Dengan semua jenis VM bersertifikat SAP (lihat Catatan SAP #1928533), data tempdb, dan file log dapat ditempatkan pada drive D:\ nonpersistensi.
- Dengan rilis SQL Server, di mana SQL Server menginstal tempdb dengan satu file data saja, disarankan untuk menggunakan beberapa file data tempdb. Ketahuilah volume drive D:\ berbeda dalam ukuran dan kemampuan berdasarkan jenis VM. Untuk ukuran pasti dari D:\ drive dari VM yang berbeda, periksa artikel Ukuran untuk mesin virtual Windows di Azure.
Konfigurasi ini memungkinkan tempdb untuk mengkonsumsi lebih banyak ruang dan lebih penting lagi, lebih banyak operasi I/O per detik (IOPS) dan bandwidth penyimpanan dibanding yang dapat disediakan drive sistem. Drive D:\ nonpersisten juga menawarkan latensi dan throughput I/O yang lebih baik. Untuk menentukan ukuran tempdb yang tepat, Anda dapat memeriksa ukuran tempdb pada sistem yang ada.
Catatan
jika Anda menempatkan tempdb data file dan log file ke sebuah folder di D:\ drive yang Anda buat, Anda perlu memastikan bahwa folder tersebut memang ada setelah VM memulai ulang. Karena drive D:\ dapat diinisialisasi setelah VM me-reboot semua file dan struktur direktori dapat dihapus. Kemungkinan untuk membuat ulang struktur direktori akhir pada drive D:\ sebelum dimulainya layanan SQL Server didokumentasikan dalam artikel ini.
Konfigurasi VM, yang menjalankan SQL Server dengan database SAP dan di mana data tempdb dan logfile tempdb ditempatkan di drive D:\ dan penyimpanan premium Azure v1 atau v2 akan terlihat seperti:
Diagram menampilkan kasus sederhana. Seperti yang disaalkan dalam artikel Pertimbangan untuk penyebaran Azure Virtual Machines DBMS untuk beban kerja SAP, tipe penyimpanan Azure, jumlah, dan ukuran disk tergantung dari faktor yang berbeda. Tetapi secara umum kami merekomendasikan:
- Untuk penyebaran yang lebih kecil dan menengah, menggunakan satu volume besar, yang berisi file data SQL Server. Alasan di balik konfigurasi ini adalah bahwa lebih mudah untuk menangani beban kerja I/O yang berbeda jika file data SQL Server tidak memiliki ruang kosong yang sama. Sedangkan dalam penyebaran besar, terutama penyebaran di mana pelanggan pindah dengan migrasi database heterogen ke SQL Server di Azure, kami menggunakan disk terpisah dan kemudian mendistribusikan file data di seluruh disk tersebut. Arsitektur seperti itu hanya berhasil ketika setiap disk memiliki jumlah file data yang sama, semua file data berukuran sama, dan kira-kira memiliki ruang kosong yang sama.
- Gunakan D:\drive untuk tempdb selama kinerja cukup baik. Jika beban kerja keseluruhan terbatas dalam performa tempdb yang terletak di drive D:\, Anda perlu memindahkan tempdb ke penyimpanan premium Azure v1 atau v2, atau disk Ultra seperti yang direkomendasikan dalam artikel ini.
Mekanisme pengisian proporsional SQL Server mendistribusikan membaca dan menulis ke semua file data secara merata asalkan semua file data SQL Server berukuran sama dan memiliki kecepatan bebas yang sama. SAP di SQL Server memberikan performa terbaik ketika baca dan tulis didistribusikan secara merata di semua datafiles yang tersedia. Jika database memiliki terlalu sedikit datafiles atau file data yang ada sangat tidak seimbang, metode terbaik untuk memperbaiki adalah ekspor dan impor R3load. Ekspor dan impor R3load melibatkan waktu tidak berfungsi dan hanya boleh dilakukan jika ada masalah performa yang jelas yang perlu diselesaikan. Jika datafiles hanya berukuran cukup berbeda, tingkatkan semua datafiles ke ukuran yang sama, dan SQL Server menyeimbangkan ulang data dari waktu ke waktu. SQL Server secara otomatis menumbuhkan datafiles secara merata jika bendera pelacakan 1117 diatur atau jika SQL Server 2016 atau yang lebih tinggi digunakan tanpa bendera pelacakan.
Khusus untuk M-Series VM
Untuk Azure M-Series VM, penulisan latensi ke dalam log transaksi dapat dikurangi, dibandingkan dengan performa penyimpanan premium Azure v1, saat menggunakan Azure Write Accelerator. Jika latensi penyimpanan premium v1 yang disediakan membatasi skalabilitas beban kerja SAP, disk yang menyimpan file log transaksi SQL Server dapat diaktifkan untuk Write Accelerator. Detail dapat dibaca dalam dokumen Write Accelerator. Azure Write Accelerator tidak berfungsi dengan penyimpanan premium Azure v2 dan disk Ultra. Dalam kedua kasus, latensi lebih baik daripada apa yang diberikan azure premium storage v1. Write Accelerator tidak mendukung Premium SSD v2.
Catatan
Dengan beberapa jenis VM M(b)v3 baru, penggunaan penyimpanan SSD v1 Premium yang di-cache dapat mengakibatkan tingkat dan throughput IOPS baca dan tulis yang lebih rendah daripada yang Akan Anda dapatkan jika Anda tidak menggunakan cache baca.
Memformat disk
Untuk SQL Server, ukuran blok NTFS untuk disk yang berisi data SQL Server dan log file harus 64 KB. Tidak perlu memformat drive D:\. Drive ini telah diformat sebelumnya.
Untuk menghindari bahwa pemulihan atau pembuatan database menginisialisasi file data dengan nol konten file, pastikan bahwa konteks pengguna yang dijalankan layanan SQL Server memiliki tugas pemeliharaan volume User Right Perform. Untuk informasi selengkapnya, lihat Inisialisasi file instan database.
SQL Server 2014 dan versi SQL Server yang lebih baru - Menyimpan File Database langsung di Azure Blob Storage
SQL Server 2014 dan rilis yang lebih baru membuka kemungkinan untuk menyimpan database file langsung di Azure Blob Store tanpa 'pembungkus' VHD di sekitar mereka. Fungsionalitas ini dimaksudkan untuk mengatasi kekurangan penyimpanan blok Azure tahun yang lalu. Hari ini, tidak disarankan untuk menggunakan metode penyebaran ini dan sebaliknya memilih penyimpanan premium Azure v1, penyimpanan premium v2, atau disk Ultra. Tergantung pada persyaratannya.
Pertimbangan Pencadangan/Pemulihan untuk SQL Server
Menyebarkan SQL Server ke Azure, Anda perlu meninjau arsitektur cadangan Anda. Bahkan jika sistem bukan sistem produksi, database SQL Server SAP harus dicadangkan secara berkala. Karena Azure Storage menyimpan tiga gambar, cadangan sekarang kurang penting sehubungan dengan kompensasi crash pada penyimpanan. Alasan prioritas untuk mempertahankan rencana pencadangan dan pemulihan yang tepat penting untuk fungsionalitas pemulihan titik waktu untuk mengimbangi kesalahan logis/manual. Tujuannya adalah untuk menggunakan cadangan untuk memulihkan database kembali ke titik waktu tertentu. Atau untuk menggunakan cadangan di Azure untuk menyemai sistem lain dengan menyalin cadangan database yang ada.
Ada beberapa cara untuk mencadangkan dan memulihkan database SQL Server di Azure. Untuk mendapatkan gambaran umum dan detail terbaik, baca dokumen Pencadangan dan pemulihan untuk SQL Server di Azure VM. Artikel ini membahas beberapa kemungkinan yang berbeda.
Menggunakan gambar SQL Server dari Microsoft Azure Marketplace
Microsoft menawarkan VM di Marketplace Azure, yang sudah berisi versi SQL Server. Bagi pelanggan SAP yang memerlukan lisensi untuk SQL Server dan Windows, menggunakan gambar-gambar ini dapat berfungsi sebagai kesempatan untuk menutupi kebutuhan lisensi dengan memutar VM dengan SQL Server yang telah terpasang. Untuk menggunakan gambar tersebut untuk SAP, pertimbangan berikut perlu dibuat:
- SQL Server versi non-evaluasi memperoleh biaya yang lebih tinggi daripada mesin virtual 'khusus Windows' yang disebarkan dari Marketplace Azure. Untuk membandingkan harga, lihat Harga Windows Virtual Machines dan Harga SQL Server Enterprise Virtual Machines.
- Anda hanya dapat menggunakan rilis SQL Server, yang didukung oleh SAP untuk perangkat lunak mereka.
- Kolase instans SQL Server, yang terpasang di VM yang ditawarkan di Azure Marketplace bukanlah kolase SAP NetWeaver yang mengharuskan instans SQL Server dijalankan. Anda dapat mengubah kolase dengan petunjuk di bagian berikut.
Mengubah Kolase SQL Server dari Microsoft Windows /SQL Server VM
Karena gambar SQL Server di Marketplace Azure tidak disiapkan untuk menggunakan kolase, yang diperlukan untuk aplikasi SAP NetWeaver, itu perlu diubah segera setelah penyebaran. Untuk SQL Server, perubahan kolase ini dapat dilakukan dengan langkah-langkah berikut segera setelah VM disebarkan dan administrator dapat masuk ke VM yang diterapkan:
- Buka Jendela Perintah Windows, sebagai administrator.
- Ubah direktori menjadi C:\Program Files\Microsoft SQL Server\110\Setup Bootstrap\SQLServer2012.
- Jalankan perintah: Setup.exe /QUIET /ACTION=REBUILDDATABASE /INSTANCENAME=MSSQLSERVER /SQLSYSADMINACCOUNTS=
<local_admin_account_name> /SQLCOLLATION=SQL_Latin1_General_Cp850_BIN2<local_admin_account_name> adalah akun, yang didefinisikan sebagai akun administrator saat menyebarkan VM untuk pertama kalinya melalui galeri.
Proses ini hanya akan memakan waktu beberapa menit. Untuk memastikan apakah langkah tersebut berakhir dengan hasil yang benar, lakukan langkah-langkah berikut:
- Buka SQL Server Management Studio.
- Buka Jendela Kueri.
- Jalankan perintah sp_helpsort di SQL Server database master.
Hasil yang diinginkan akan terlihat seperti:
Latin1-General, binary code point comparison sort for Unicode Data, SQL Server Sort Order 40 on Code Page 850 for non-Unicode Data
Jika hasilnya berbeda, HENTIKAN penyebaran apa pun dan selidiki mengapa perintah penyiapan tidak berfungsi seperti yang diharapkan. Penyebaran aplikasi SAP NetWeaver ke instans SQL Server dengan halaman kode SQL Server yang berbeda dari yang disebutkan TIDAK didukung untuk penyebaran NetWeaver.
SQL Server High-Availability untuk SAP di Azure
Menggunakan SQL Server di penyebaran Azure IaaS untuk SAP, Anda memiliki beberapa kemungkinan berbeda untuk ditambahkan untuk menyebarkan lapisan database yang sangat tersedia. Azure menyediakan SLA waktu aktif yang berbeda untuk satu VM menggunakan penyimpanan blok Azure yang berbeda, sepasang VM yang disebarkan dalam set ketersediaan Azure, atau sepasang VM yang disebarkan di seluruh Zona Ketersediaan Azure. Untuk sistem produksi, kami berharap Anda menyebarkan sepasang VM dalam set skala komputer virtual dengan orkestrasi fleksibel di dua zona ketersediaan. Lihat perbandingan jenis penyebaran yang berbeda untuk beban kerja SAP untuk informasi selengkapnya. Satu VM menjalankan Instans SQL Server aktif. VM lainnya menjalankan instans pasif
SQL Server Clustering menggunakan Windows Scale-out Server File atau disk bersama Azure
Dengan Windows Server 2016, Microsoft memperkenalkan Storage Spaces Direct. Berdasarkan Storage Spaces Direct Deployment, pengklusteran SQL Server FCI didukung secara umum. Azure juga menawarkan disk bersama Azure yang dapat digunakan untuk pengelompokan Windows. Untuk beban kerja SAP, kami tidak mendukung opsi KETERSEDIAAN TINGGI ini.
SQL Server Log Shipping
Salah satu fungsionalitas ketersediaan tinggi adalah pengiriman log SQL Server. Jika VM yang berpartisipasi dalam konfigurasi HA memiliki resolusi nama kerja, tidak ada masalah. Penyiapan di Azure tidak berbeda dari penyiapan apa pun yang dilakukan di tempat yang terkait dengan penyiapan pengiriman log dan prinsip-prinsip sekeliling pengiriman log. Detail pengiriman log SQL Server dapat ditemukan di artikel Tentang Pengiriman Log (SQL Server).
Fungsi pengiriman log pada SQL Server hampir tidak digunakan di Azure untuk mencapai ketersediaan tinggi dalam satu wilayah Azure. Namun dalam skenario berikut pelanggan SAP menggunakan pengiriman log berhasil dengan Azure:
- Skenario Disaster Recovery dari satu wilayah Azure ke wilayah Azure lainnya
- Konfigurasi Disaster Recovery dari lokal ke wilayah Azure
- Skenario cut-over dari lokal ke Azure. Dalam kasus tersebut, pengiriman log digunakan untuk menyinkronkan penyebaran database baru di Azure dengan sistem produksi yang sedang berlangsung secara lokal. Pada saat pemotongan, produksi dimatikan dan dipastikan bahwa cadangan log transaksi terakhir dan terbaru ditransfer ke penyebaran database Azure. Kemudian penyebaran database Azure dibuka untuk produksi.
SQL Server Grup Ketersediaan AlwaysOn
Karena Always On didukung untuk SAP lokal (lihat Catatan SAP #1772688), itu didukung dalam kombinasi dengan SAP di Azure. Ada beberapa pertimbangan khusus sekeliling penyebaran Pendengar Grup Ketersediaan SQL Server (tidak bingung dengan Set Ketersediaan Azure). Oleh karena itu, beberapa langkah penginstalan yang berbeda diperlukan.
Beberapa pertimbangan menggunakan Pendengar Grup Ketersediaan adalah:
- Menggunakan Pendengar Grup Ketersediaan hanya dimungkinkan dengan Windows Server 2012 atau lebih tinggi sebagai OS tamu dari VM. Untuk Windows Server 2012, pastikan bahwa pembaruan untuk mengaktifkan Pendengar Grup Ketersediaan SQL Server di Windows Server 2008 R2 dan mesin virtual Microsoft Azure berbasis Windows Server 2012 telah diterapkan.
- Untuk Windows Server 2008 R2, patch ini tidak ada. Dalam hal ini, Always On perlu digunakan dengan cara yang sama seperti Pencerminan Database. Dengan menentukan mitra failover dalam string koneksi (dilakukan melalui parameter SAP default.pfl dbs/mss/server - lihat Catatan SAP #965908).
- Dengan menggunakan Listener Grup Ketersediaan, Anda perlu menyambungkan VM Database ke Load Balancer khusus. Anda harus menetapkan alamat IP statis ke antarmuka jaringan VM tersebut dalam konfigurasi AlwaysOn (menentukan alamat IP statis dijelaskan dalam artikel ini). Alamat IP statis dibandingkan dengan DHCP mencegah penugasan alamat IP baru dalam kasus di mana kedua VM mungkin dihentikan.
- Ada langkah-langkah khusus yang diperlukan ketika membangun konfigurasi klaster WSFC di mana kluster memerlukan alamat IP khusus yang ditetapkan, karena Azure dengan fungsi saat ini akan menetapkan nama kluster alamat IP yang sama dengan node yang dibuat oleh kluster. Perilaku ini berarti langkah manual harus dilakukan untuk menetapkan alamat IP yang berbeda ke klaster.
- Pendengar Grup Ketersediaan akan dibuat di Azure dengan titik akhir TCP/IP, yang ditetapkan ke VM yang menjalankan replika utama dan sekunder dari grup Ketersediaan.
- Mungkin ada kebutuhan untuk mengamankan titik akhir ini dengan ACL.
Dokumentasi terperinci tentang menerapkan Always On dengan SQL Server di daftar Azure VMs seperti:
- Memperkenalkan SQL Server Always On Pada grup ketersediaan di komputer virtual Azure.
- Mengonfigurasi Grup Ketersediaan Always On di komputer virtual Azure dalam berbagai wilayah
- Mengonfigurasi penyeimbang muatan untuk grup ketersediaan Always On di Azure.
- Praktik terbaik konfigurasi HADR (SQL Server di Azure VM)
Catatan
Membaca Memperkenalkan grup ketersediaan SQL Server Grup Ketersediaan AlwaysOn pada mesin virtual Azure, Anda akan membaca tentang pendengar Nama Jaringan Langsung (DNN)SQL Server. Fungsi baru ini diperkenalkan dengan SQL Server 2019 CU8. Fungsi baru ini membuat penggunaan penyeimbang muatan Azure yang menangani alamat IP virtual Pendengar Grup Ketersediaan Availability Group menjadi usang.
SQL Server Always On adalah fungsi ketersediaan tinggi dan pemulihan bencana yang paling umum digunakan di Azure untuk penyebaran beban kerja SAP. Sebagian besar pelanggan menggunakan Always On untuk ketersediaan tinggi dalam satu Wilayah Azure. Jika penyebaran dibatasi hanya untuk dua node, Anda memiliki dua pilihan untuk konektivitas:
- Menggunakan Pendengar Grup Ketersediaan. Dengan Pendengar Grup Ketersediaan, Anda diharuskan untuk menggunakan penyeimbang muatan Azure.
- Dengan SQL Server 2016 SP3, SQL Server 2017 CU 25, atau SQL Server 2019 CU8 atau rilis SQL Server terbaru di Windows Server 2016 atau yang lebih baru, Anda dapat menggunakan pendengar Nama Jaringan Langsung (DNN) alih-alih load balancer Azure. DNN menghilangkan persyaratan penyeimbang beban Azure kepada kami.
Menggunakan parameter konektivitas Pencerminan Database SQL Server hanya boleh dipertimbangkan untuk putaran penyelidikan masalah dengan dua metode lainnya. Dalam hal ini, Anda perlu mengonfigurasi konektivitas aplikasi SAP dengan cara di mana kedua nama node diberi nama. Detail pasti konfigurasi samping SAP tersebut didokumentasikan dalam SAP Note #965908. Dengan menggunakan opsi ini, Anda tidak perlu mengonfigurasi pendengar Grup Ketersediaan. Dan dengan itu tidak ada penyeimbang muatan Azure dan dengan itu dapat menyelidiki masalah komponen tersebut. Namun harap diingat, opsi ini hanya berfungsi jika Anda membatasi Grup Ketersediaan untuk menjangkau dua instans.
Sebagian besar pelanggan menggunakan fungsionalitas AlwaysOn SQL Server untuk fungsionalitas pemulihan bencana antar wilayah Azure. Beberapa pelanggan juga menggunakan kemampuan untuk melakukan pencadangan dari replika sekunder.
Enkripsi Data Transparan SQL Server
Banyak pelanggan yang menggunakan SQL Server Enkripsi Data Transparan (TDE) saat menyebarkan database SAP SQL Server mereka di Azure. Fungsi SQL Server TDE didukung penuh oleh SAP (lihat SAP Note #1380493).
Menerapkan SQL Server TDE
Dalam kasus di mana Anda melakukan migrasi heterogen dari database lain, berjalan secara lokal, ke Windows/SQL Server yang berjalan di Azure, Anda harus membuat database target kosong di SQL Server sebelumnya. Sebagai langkah selanjutnya, Anda akan menerapkan fungsionalitas TDE SQL Server terhadap database kosong ini. Alasan Anda ingin melakukan dalam urutan ini adalah bahwa proses mengenkripsi database kosong bisa memakan waktu cukup lama. Proses impor SAP kemudian akan mengimpor data ke database terenkripsi selama fase downtime. Overhead mengimpor ke database terenkripsi memiliki dampak waktu yang jauh lebih rendah dibanding mengenkripsi database setelah fase ekspor dalam fase down time. Pengalaman negatif dibuat ketika mencoba menerapkan TDE dengan beban kerja SAP yang berjalan di atas database. Oleh karena itu, rekomendasi memperlakukan penyebaran TDE sebagai aktivitas yang perlu dilakukan tanpa atau beban kerja SAP rendah pada database tertentu. Dari SQL Server 2016 aktif, Anda dapat menghentikan dan melanjutkan pemindaian TDE yang melakukan enkripsi awal. Dokumen Transparent Data Encryption (TDE) menjelaskan perintah dan detailnya.
Dalam kasus di mana Anda memindahkan database SAP SQL Server dari lokal ke Azure, kami sarankan pengujian infrastruktur mana yang bisa Anda terapkan tercepat. Untuk kasus ini, ingatlah fakta-fakta ini:
- Anda tidak dapat menentukan berapa banyak thread yang digunakan untuk menerapkan enkripsi data ke database. Jumlah thread terutama tergantung pada jumlah volume disk data SQL Server dan file log didistribusikan. Berarti semakin banyak volume yang berbeda (huruf drive), semakin banyak utas yang terlibat secara paralel untuk melakukan enkripsi. Konfigurasi seperti ini sedikit bertentangan dengan saran konfigurasi disk tentang cara membangun satu atau sejumlah kecil ruang penyimpanan untuk SQL Server database file di VM Azure. Konfigurasi dengan beberapa volume akan menghasilkan beberapa utas yang menjalankan enkripsi. Enkripsi utas tunggal membaca 64KB, mengenkripsinya, dan kemudian menulis catatan ke dalam file log transaksi, mengatakan bahwa sejauh mana dienkripsi. Sebagai akibatnya, beban yang berada pada log transaksi bersifat sedang.
- Dalam rilis SQL Server yang lebih lama, kompresi cadangan tidak mendapatkan efisiensi lagi saat Anda mengenkripsi database SQL Server Anda. Perilaku ini dapat berkembang menjadi masalah ketika rencana Anda adalah mengenkripsi database SQL Server Anda di tempat lalu menyalin cadangan ke Azure untuk memulihkan database di Azure. Kompresi cadangan SQL Server dapat mencapai rasio kompresi faktor 4.
- Dengan SQL Server 2016, SQL Server memperkenalkan fungsionalitas baru yang memungkinkan pemadatan cadangan database terenkripsi juga dengan cara yang efisien. Lihat blog ini untuk beberapa detail.
Gunakan Azure Key Vault
Azure menawarkan layanan Key Vault untuk menyimpan kunci enkripsi. SQL Server di sisi lain menawarkan konektor untuk memanfaatkan Azure Key Vault sebagai toko untuk sertifikat TDE.
Detail selengkapnya untuk menggunakan Azure Key Vault untuk daftar SQL Server TDE seperti:
- Konfigurasikan integrasi Azure Key Vault untuk SQL Server di Azure VM (Resource Manager).
- Pertanyaan Lainnya Dari Pelanggan Mengenai SQL Server Transparent Data Encryption - TDE + Azure Key Vault.
Penting
Menggunakan SQL Server TDE, terutama dengan Azure key Vault, disarankan untuk menggunakan patch terbaru SQL Server 2014, SQL Server 2016, dan SQL Server 2017. Alasannya adalah bahwa berdasarkan umpan balik pelanggan, pengoptimalan dan perbaikan telah diterapkan pada kode. Sebagai contoh, periksa KBA #4058175.
Konfigurasi penyebaran minimum
Di bagian ini, kami menyarankan serangkaian konfigurasi minimum untuk berbagai ukuran database di bawah beban kerja SAP. Terlalu sulit untuk menilai apakah ukuran ini sesuai dengan beban kerja spesifik Anda. Dalam beberapa kasus, kita mungkin murah hati pada memori dibandingkan dengan ukuran database. Di sisi lain, ukuran disk mungkin terlalu rendah untuk beberapa beban kerja. Oleh karena itu, konfigurasi ini harus diperlakukan sebagai apa adanya. Ini adalah konfigurasi yang seharusnya memberi Anda titik untuk memulai. Konfigurasi untuk menyempurnakan beban kerja dan persyaratan efisiensi biaya spesifik Anda.
Contoh konfigurasi untuk instans SQL Server kecil dengan ukuran database antara 50 GB – 250 GB bisa terlihat seperti
| Konfigurasi | Database VM | Komentar |
|---|---|---|
| Tipe VM | E4s_v3/v4/v5 (RAM 4 vCPU/32 GiB) | |
| Penjaringan Dipercepat | Aktifkan | |
| Versi SQL Server | SQL Server 2019 atau yang lebih baru | |
| # file data | 4 | |
| # file log | 1 | |
| # file data sementara | 4 atau default sejak SQL Server 2016 | |
| Sistem operasi | Windows Server 2019 atau yang lebih baru | |
| Agregasi disk | Ruang Penyimpanan jika diinginkan | |
| Sistem file | NTFS | |
| Ukuran blok format | 64 KB | |
| # dan jenis disk data | Penyimpanan premium v1: 2 x P10 (RAID0) Penyimpanan premium v2: 2 x 150 GiB (RAID0) - IOPS dan throughput default atau SSD Premium v2 yang setara |
Cache = Baca Saja untuk penyimpanan premium v1 |
| # dan jenis disk log | Penyimpanan premium v1: 1 x P20 Penyimpanan premium v2: 1 x 128 GiB - IOPS dan throughput default atau Premium SSD v2 yang setara |
Cache = NONE |
| Parameter memori maks SQL Server | 90% RAM Fisik | Dengan asumsi instans tunggal |
Contoh konfigurasi atau instans SQL Server kecil dengan ukuran database antara 250 GB – 750 GB, seperti sistem SAP Business Suite yang lebih kecil, bisa terlihat seperti
| Konfigurasi | Database VM | Komentar |
|---|---|---|
| Tipe VM | E16s_v3/v4/v5 (RAM 16 vCPU/128 GiB) | |
| Penjaringan Dipercepat | Aktifkan | |
| Versi SQL Server | SQL Server 2019 atau yang lebih baru | |
| # file data | 8 | |
| # file log | 1 | |
| # file data sementara | 8 atau default sejak SQL Server 2016 | |
| Sistem operasi | Windows Server 2019 atau yang lebih baru | |
| Agregasi disk | Ruang Penyimpanan jika diinginkan | |
| Sistem file | NTFS | |
| Ukuran blok format | 64 KB | |
| # dan jenis disk data | Penyimpanan premium v1: 4 x P20 (RAID0) Penyimpanan premium v2: 4 x 100 GiB - 200 GiB (RAID0) - IOPS default dan throughput tambahan 25 MB/detik per disk atau SSD Premium v2 yang setara |
Cache = Baca Saja untuk penyimpanan premium v1 |
| # dan jenis disk log | Penyimpanan premium v1: 1 x P20 Penyimpanan premium v2: 1 x 200 GiB - IOPS dan throughput default atau SSD Premium v2 yang setara |
Cache = NONE |
| Parameter memori maks SQL Server | 90% RAM Fisik | Dengan asumsi instans tunggal |
Contoh konfigurasi untuk instans SQL Server sedang dengan ukuran database antara 750 GB – 2.000 GB, seperti sistem SAP Business Suite sedang, bisa terlihat seperti
| Konfigurasi | Database VM | Komentar |
|---|---|---|
| Tipe VM | E64s_v3/v4/v5 (RAM 64 vCPU/432 GiB) | |
| Penjaringan Dipercepat | Aktifkan | |
| Versi SQL Server | SQL Server 2019 atau yang lebih baru | |
| # perangkat data | 16 | |
| # perangkat log | 1 | |
| # file data sementara | 8 atau default sejak SQL Server 2016 | |
| Sistem operasi | Windows Server 2019 atau yang lebih baru | |
| Agregasi disk | Ruang Penyimpanan jika diinginkan | |
| Sistem file | NTFS | |
| Ukuran blok format | 64 KB | |
| # dan jenis disk data | Penyimpanan premium v1: 4 x P30 (RAID0) Penyimpanan premium v2: 4 x 250 GiB - 500 GiB - ditambah 2.000 IOPS dan throughput 75 MB/detik per disk atau SSD Premium v2 yang setara |
Cache = Baca Saja untuk penyimpanan premium v1 |
| # dan jenis disk log | Penyimpanan premium v1: 1 x P20 Penyimpanan premium v2: 1 x 400 GiB - IOPS default dan throughput tambahan 75MB/detik atau Premium SSD v2 yang setara |
Cache = NONE |
| Parameter memori maks SQL Server | 90% RAM Fisik | Dengan asumsi instans tunggal |
Contoh konfigurasi untuk instans SQL Server yang lebih besar dengan ukuran database antara 2.000 GB dan 4.000 GB, seperti sistem SAP Business Suite yang lebih besar, bisa terlihat seperti
| Konfigurasi | Database VM | Komentar |
|---|---|---|
| Tipe VM | E96(d)s_v5 (RAM 96 vCPU/672 GiB) | |
| Penjaringan Dipercepat | Aktifkan | |
| Versi SQL Server | SQL Server 2019 atau yang lebih baru | |
| # perangkat data | 24 | |
| # perangkat log | 1 | |
| # file data sementara | 8 atau default sejak SQL Server 2016 | |
| Sistem operasi | Windows Server 2019 atau yang lebih baru | |
| Agregasi disk | Ruang Penyimpanan jika diinginkan | |
| Sistem file | NTFS | |
| Ukuran blok format | 64 KB | |
| # dan jenis disk data | Penyimpanan premium v1: 4 x P30 (RAID0) Penyimpanan premium v2: 4 x 500 GiB - 800 GiB - ditambah 2500 IOPS dan throughput 100 MB/detik per disk atau SSD Premium v2 yang setara |
Cache = Baca Saja untuk penyimpanan premium v1 |
| # dan jenis disk log | Penyimpanan premium v1: 1 x P20 Penyimpanan premium v2: 1 x 400 GiB - ditambah 1.000 IOPS dan throughput tambahan 75MB/detik atau Premium SSD v2 yang setara |
Cache = NONE |
| Parameter memori maks SQL Server | 90% RAM Fisik | Dengan asumsi instans tunggal |
Contoh konfigurasi untuk instans SQL Server besar dengan ukuran database 4 TB+, seperti sistem SAP Business Suite yang besar yang digunakan secara global, bisa terlihat seperti
| Konfigurasi | Database VM | Komentar |
|---|---|---|
| Tipe VM | Seri M (1,0 hingga 4,0 TB RAM) | |
| Penjaringan Dipercepat | Aktifkan | |
| Versi SQL Server | SQL Server 2019 atau yang lebih baru | |
| # perangkat data | 32 | |
| # perangkat log | 1 | |
| # file data sementara | 8 atau default sejak SQL Server 2016 | |
| Sistem operasi | Windows Server 2019 atau yang lebih baru | |
| Agregasi disk | Ruang Penyimpanan jika diinginkan | |
| Sistem file | NTFS | |
| Ukuran blok format | 64 KB | |
| # dan jenis disk data | Penyimpanan premium v1: 4+ x P40 (RAID0) Penyimpanan premium v2: 4+ x 1.000 GiB - 4.000 GiB - ditambah 4.500 IOPS dan throughput 125 MB/detik per disk atau SSD Premium v2 yang setara |
Cache = Baca Saja untuk penyimpanan premium v1 |
| # dan jenis disk log | Penyimpanan premium v1: 1 x P30 Penyimpanan premium v2: 1 x 500 GiB - ditambah 2.000 IOPS dan throughput 125 MB/detik atau Premium SSD v2 yang setara |
Cache = NONE |
| Parameter memori maks SQL Server | 95% RAM Fisik | Dengan asumsi instans tunggal |
Sebagai contoh, konfigurasi ini adalah konfigurasi VM Database dari SAP Business Suite di SQL Server. VM ini menghosting database 30 TB dari instans SAP Business Suite global tunggal dari perusahaan global dengan pendapatan tahunan lebih dari $ 200B dan lebih dari karyawan penuh waktu 200K. Sistem ini menjalankan semua pemrosesan keuangan, penjualan, dan pemrosesan distribusi dan lebih banyak proses bisnis dari berbagai area, termasuk penggajian Amerika Utara n. Sistem ini berjalan di Azure sejak awal 2018 menggunakan VM seri Azure M sebagai VM database. Karena ketersediaan tinggi, sistem menggunakan Always On dengan satu replika sinkron di Zona Ketersediaan lain dari wilayah Azure yang sama. Dan replika asinkron lainnya di wilayah Azure lain. Lapisan aplikasi NetWeaver disebarkan pada keluarga VM D(a)/E(a) terbaru.
| Konfigurasi | Database VM | Komentar |
|---|---|---|
| Tipe VM | M192dms_v2 (RAM 192 vCPU/4.196 GiB) | |
| Penjaringan Dipercepat | Diaktifkan | |
| Versi SQL Server | SQL Server 2019 | |
| # file data | 32 | |
| # file log | 1 | |
| # file data sementara | 8 | |
| Sistem operasi | Server Windows 2019 | |
| Agregasi disk | Ruang Penyimpanan | |
| Sistem file | NTFS | |
| Ukuran blok format | 64 KB | |
| # dan jenis disk data | Penyimpanan premium v1: 16 x P40 atau SSD Premium yang setara v2 | Cache = Hanya Baca |
| # dan jenis disk log | Penyimpanan premium v1: 1 x P60 atau SSD Premium yang setara v2 | Menggunakan Akselerator Tulis |
| # dan jenis disk tempdb | Penyimpanan premium v1: 1 x P30 atau SSD Premium yang setara v2 | Tidak ada penembolokan |
| Parameter memori maks SQL Server | 95% RAM Fisik |
Server SQL Umum untuk SAP di Ringkasan Azure
Ada banyak rekomendasi dalam panduan ini dan kami menyarankan Anda membacanya lebih dari sekali sebelum merencanakan penyebaran Azure Anda. Namun, secara umum, pastikan untuk mengikuti SQL Server teratas pada rekomendasi khusus Azure:
- Gunakan rilis SQLServer terbaru, seperti SQL Server 2022, yang memiliki keuntungan terbanyak di Azure.
- Rencanakan lanskap sistem SAP Anda dengan hati-hati di Azure untuk menyeimbangkan tata letak file data dan pembatasan Azure:
- Jangan gunakan terlalu banyak disk, tetapi memiliki cukup untuk memastikan Anda dapat mencapai IOPS yang diperlukan.
- Buat garis di seluruh disk hanya jika Anda perlu mencapai throughput yang lebih tinggi.
- Jangan gunakan terlalu banyak disk, tetapi memiliki cukup untuk memastikan Anda dapat mencapai IOPS yang diperlukan.
- Jangan pernah menginstal perangkat lunak atau menempatkan file apa pun yang memerlukan persistensi pada drive D:\ karena tidak aman. Apa pun pada kandar ini bisa hilang pada reboot Windows atau mulai ulang VM.
- Gunakan solusi SQL Server Always On Anda untuk mereplikasi data database.
- Selalu gunakan Resolusi Nama, jangan mengandalkan alamat IP.
- Menggunakan SQL Server TDE, terapkan patch SQL Server terbaru.
- Hati-hati dalam menggunakan gambar SQL Server dari Azure Marketplace. Jika Anda menggunakan SQL Server satu, Anda harus mengubah kolase instans sebelum memasang sistem SAP NetWeaver di dalamnya.
- Pasang dan konfigurasikan SAP Host Monitoring untuk Azure seperti yang dijelaskan dalam Panduan Penggunaan.
Langkah berikutnya
Baca artikel