Bagikan melalui

Penyebaran DBMS SQL Server Azure Virtual Machines untuk SAP Netweaver

Dokumen ini mencakup beberapa area berbeda yang perlu dipertimbangkan saat menyebarkan SQL Server untuk beban kerja SAP di Azure Infrastructure as a Service (IaaS). Sebagai prasyarat untuk dokumen ini, lihat Pertimbangan untuk penyebaran DBMS Azure Virtual Machines untuk beban kerja SAP. Lihat juga panduan lain dalam dokumentasi beban kerja SAP di Azure.

Penting

Cakupan dokumen ini adalah versi Windows di SQL Server. SAP tidak mendukung SQL Server versi Linux dengan salah satu perangkat lunak SAP. Dokumen tidak membahas Microsoft Azure SQL Database, yang merupakan penawaran Platform as a Service (PaaS) dari Platform Microsoft Azure. Diskusi dalam artikel ini adalah tentang menjalankan produk SQL Server, yang dikenal untuk penyebaran lokal di komputer virtual (VM) Azure, menggunakan kemampuan IaaS 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 VM dapat ditemukan di artikel ini:

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 Marketplace Azure: Cara tercepat untuk menyebarkan Microsoft Azure VM baru adalah dengan menggunakan gambar dari Marketplace Azure. Ada 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 pengaturan dan interferensi berbagi sumber daya yang tersedia dalam satu mesin virtual, pertimbangan yang sama seperti di on-premises perlu diperhatikan.

  • 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 untuk 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, dengan lebih dari 64 vCPU, terlalu besar untuk diakomodasi oleh SQL Server. Dengan menonaktifkan SMT di OS tamu Windows Server, jumlah vCPU berkurang. Jadi, jumlah vCPU kurang dari 64 di setiap simpul NUMA. Cara menonaktifkan SMT dijelaskan Nonaktifkan SMT di Azure VM. 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 dengan cache baca dapat mengakibatkan tingkat IOPS baca dan tulis serta throughput yang lebih rendah daripada yang akan Anda dapatkan jika Anda tidak menggunakan cache baca.

Sesuai dengan deskripsi umum, sistem operasi, eksekusi SQL Server, dan eksekusi SAP harus ditempatkan atau diinstal di dalam disk Azure yang 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:\ yang non-persisten atau pada disk terpisah.

  • Dengan semua tipe VM bersertifikat SAP (lihat Catatan SAP #1928533), tempdb data, dan file log dapat diletakkan pada drive D:\ nonpersisten.
  • Pada rilis SQL Server, di mana SQL Server diinstal tempdb dengan hanya satu file data, disarankan 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 mengonsumsi lebih banyak ruang dan lebih penting lagi operasi I/O per detik (IOPS) serta bandwidth penyimpanan daripada yang mampu disediakan oleh drive sistem. Drive D:\ yang tidak persisten juga menawarkan latensi dan throughput I/O yang lebih baik. Untuk menentukan ukuran yang tepat tempdb , Anda dapat memeriksa tempdb ukuran pada sistem yang ada.

Catatan

Jika Anda menempatkan tempdb file data dan file log ke folder di drive D:\ yang Anda buat, Anda perlu memastikan bahwa folder tersebut memang ada setelah boot ulang VM. Karena drive D:\ dapat diinisialisasi setelah reboot VM, semua file dan struktur direktori dapat dihapus. Kemungkinan untuk membuat ulang struktur direktori akhir pada drive D:\ sebelum dimulainya layanan SQL Server dijelaskan dalam Menggunakan SSD di Azure VM untuk menyimpan SQL Server TempDB dan Ekstensi Kumpulan Buffer.

Konfigurasi VM, yang menjalankan SQL Server dengan database SAP dan di mana tempdb data dan tempdb logfile ditempatkan di drive D:\ dan Azure Premium Storage v1 atau v2 akan terlihat seperti:

Diagram konfigurasi disk komputer virtual sederhana untuk SQL Server.

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 ini 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 performanya tetap cukup baik. Jika beban kerja keseluruhan terbatas dalam performa tempdb yang terletak di drive D:\, Anda perlu pindah tempdb ke Azure Premium Storage v1 atau v2, atau Ultra Disk seperti yang direkomendasikan dalam Praktik terbaik panduan performa.

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 henti dan hanya dilakukan jika ada masalah performa yang jelas yang perlu diselesaikan. Jika datafile berbeda ukuran secara moderat, tarik semua datafile ke ukuran yang sama, dan SQL Server akan 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.

Pertimbangan untuk VM Seri M

Untuk Azure M-Series VM, penulisan latensi ke dalam log transaksi dapat dikurangi, dibandingkan dengan performa Azure Premium Storage 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 Azure Premium Storage v2 dan Ultra Disk. Dalam kedua kasus, latensi lebih baik daripada apa yang diberikan Azure Premium Storage v1. Write Accelerator tidak mendukung Azure Premium SSD v2.

Catatan

Dengan beberapa jenis VM M(b)v3 baru, penggunaan penyimpanan SSD v1 Premium dengan cache baca dapat mengakibatkan tingkat IOPS baca dan tulis serta throughput 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 sudah diformat sebelumnya.

Untuk menghindari pemulihan atau pembuatan database yang menginisialisasi file data dengan mengatur konten file ke nol, pastikan bahwa konteks pengguna yang menjalankan layanan SQL Server memiliki Hak Pengguna Perform volume maintenance tasks. Untuk informasi selengkapnya, lihat Inisialisasi file instan database.

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-hari ini, tidak disarankan untuk menggunakan metode penyebaran ini dan sebaliknya memilih Azure Premium Storage v1 atau v2, atau Ultra Disk tergantung pada persyaratannya.

Pertimbangan pencadangan dan pemulihan untuk SQL Server

Menyebarkan SQL Server ke Azure, Anda perlu meninjau arsitektur cadangan Anda. Meskipun sistem bukanlah sistem produksi, database SQL Server SAP harus dibackup secara berkala. Karena Azure Storage menyimpan tiga citra, cadangan sekarang kurang penting untuk mengatasi kerusakan penyimpanan. Prioritas utama untuk mempertahankan rencana pencadangan dan pemulihan yang tepat adalah fungsi pemulihan titik waktu yang penting untuk mengimbangi kesalahan logis/manual. Tujuannya adalah untuk menggunakan penyimpanan cadangan untuk memulihkan atau mengembalikan database ke keadaan pada 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 Azure Marketplace, 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 SAP untuk perangkat lunak mereka.
  • Kolase instans SQL Server, yang diinstal di VM yang ditawarkan di Azure Marketplace bukanlah kolase SAP NetWeaver yang mengharuskan instans SQL Server dijalankan. Anda dapat mengubah pengaturan kolasi dengan mengikuti petunjuk di bagian berikut.

Mengubah kolase SQL Server dari komputer virtual Microsoft Windows SQL Server

Karena gambar SQL Server di Azure Marketplace tidak disiapkan untuk menggunakan kolasi yang diperlukan untuk aplikasi SAP NetWeaver, kolasi tersebut 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 disebarkan:

  • 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 ketika pertama kali men-deploy VM 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 Ketersediaan Tinggi 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 up-time yang berbeda untuk satu VM menggunakan:

  • Penyimpanan blok Azure yang berbeda
  • Sepasang VM yang disebarkan dalam Set Ketersediaan Azure
  • 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. Untuk mempelajari lebih lanjut, lihat perbandingan jenis penyebaran yang berbeda untuk beban kerja SAP. Satu VM menjalankan Instans SQL Server aktif. VM lainnya menjalankan instans pasif.

SQL Server Clustering menggunakan Windows Scale-out File Server atau disk berbagi 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.

Pengiriman log SQL Server

Salah satu fungsionalitas ketersediaan tinggi adalah pengiriman log SQL Server. Jika VM yang berpartisipasi dalam konfigurasi HA memiliki resolusi nama yang berfungsi, tidak ada masalah. Penyiapan di Azure tidak berbeda dari penyiapan apa pun yang dilakukan di tempat terkait dengan pengaturan pengiriman log dan prinsip-prinsipnya. 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 berhasil memanfaatkan pengiriman log dengan Azure.

  • Skenario Disaster Recovery dari satu wilayah Azure ke wilayah Azure lainnya
  • Konfigurasi Disaster Recovery dari infrastruktur lokal ke wilayah Azure
  • Skenario pemindahan dari di tempat 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 transisi, produksi dihentikan sementara dan dipastikan bahwa cadangan log transaksi terakhir dan terbaru telah ditransfer ke dalam penyebaran database Azure. Kemudian penyebaran database Azure siap untuk digunakan dalam produksi.

SQL Server Grup Ketersediaan AlwaysOn

Always On didukung untuk SAP lokal (lihat Catatan SAP #1772688) dan didukung dalam kombinasi dengan SAP di Azure. Ada beberapa pertimbangan khusus mengenai penyebaran SQL Server Availability Group Listener (tidak untuk disamakan dengan Azure Availability Set). Oleh karena itu, langkah-langkah penginstalan yang berbeda diperlukan.

Beberapa pertimbangan menggunakan Pendengar Grup Ketersediaan adalah:

  • Menggunakan Listener Grup Ketersediaan hanya dimungkinkan dengan Windows Server 2012 dan yang lebih baru sebagai sistem operasi tamu di VM. Untuk Windows Server 2012, pastikan bahwa Listener Grup Ketersediaan SQL Server di komputer virtual Microsoft Azure berbasis Windows Server 2008 R2 dan Windows Server 2012 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 sebagaimana ditetapkan melalui parameter SAP default.pfl dbs/mss/server. Lihat Catatan SAP #965908.
  • Dengan menggunakan Pendengar 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 Membuat VM dengan alamat IP privat statis. Jika dibandingkan dengan DHCP, alamat IP statis menghalangi penugasan alamat IP baru ketika kedua VM mungkin dihentikan.
  • Ada langkah-langkah khusus yang diperlukan saat membangun konfigurasi kluster WSFC di mana kluster membutuhkan alamat IP khusus yang ditetapkan. Azure, dengan fungsionalitasnya saat ini, akan menetapkan nama kluster alamat IP yang sama dengan node tempat kluster dibuat. 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 penerapan Always On dengan SQL Server dalam Azure VMs mencantumkan seperti:

Catatan

Saat membaca Memperkenalkan grup ketersediaan Always On SQL Server pada mesin virtual Azure, Anda akan mempelajari tentang SQL Server listener Direct Network Name (DNN). Fungsionalitas DNN diperkenalkan dengan SQL Server 2019 CU8. Fungsi baru ini membuat penggunaan penyeimbang muatan Azure yang menangani alamat IP virtual Pendengar 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 Availability Group Listener, Anda diharuskan untuk mengonfigurasi penyeimbang beban Azure.

  • Pendengar Direct Network Name (DNN) dapat digunakan sebagai pengganti load balancer Azure. DNN menghilangkan persyaratan untuk menggunakan load balancer Azure, yang juga berlaku untuk:

    • SQL Server 2016 SP3

      • Rilis SQL Server terbaru di Windows Server 2016

    • SQL Server 2017 CU 25

    • SQL Server 2019 CU8

Menggunakan parameter konektivitas dari Pencerminan Database SQL Server sebaiknya hanya dipertimbangkan sebagai langkah penyelidikan masalah setelah dua metode lainnya dipertimbangkan terlebih dahulu. 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 hanya mencakup 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. SAP sepenuhnya mendukung fungsionalitas TDE SQL Server. Lihat Catatan SAP #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 Anda 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 dalam database terenkripsi memiliki dampak waktu yang jauh lebih rendah dibandingkan dengan mengenkripsi database setelah fase ekspor dalam fase waktu henti. Pengalaman negatif dibuat ketika mencoba menerapkan TDE dengan beban kerja SAP yang berjalan di atas database. Oleh karena itu, disarankan untuk memperlakukan penyebaran TDE sebagai aktivitas yang perlu dilakukan dengan beban kerja SAP yang tidak ada atau rendah pada database tertentu. Mulai dari SQL Server 2016, Anda dapat menghentikan sementara dan melanjutkan pemindaian TDE yang melakukan enkripsi awal.

Dalam kasus di mana Anda memindahkan database SAP SQL Server dari lokal ke Azure, kami sarankan untuk menguji infrastruktur mana yang dapat menerapkan enkripsi paling cepat. Untuk kasus ini, ingatlah fakta-fakta ini:

  • Anda tidak dapat menentukan berapa banyak thread yang digunakan untuk menerapkan enkripsi data ke database. Jumlah thread sebagian besar tergantung pada jumlah volume disk yang digunakan untuk mendistribusikan file data dan log SQL Server. Berarti semakin banyak volume yang berbeda (huruf drive), semakin banyak utas yang terlibat secara paralel untuk melakukan enkripsi. Konfigurasi seperti itu bertentangan dengan saran konfigurasi disk sebelumnya tentang membangunnya, atau jumlah ruang penyimpanan yang lebih kecil untuk file database SQL Server di Azure VM. Konfigurasi dengan beberapa volume akan menghasilkan beberapa utas yang menjalankan enkripsi. Proses enkripsi dengan utas tunggal membaca bagian sebesar 64 KB, mengenkripsinya, dan kemudian menulis rekaman ke dalam file log transaksi, memberi tahu bahwa bagian tersebut telah 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:

Penting

Saat Anda menggunakan SQL Server TDE, terutama dengan Azure key Vault, rekomendasinya adalah 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. Konfigurasi ini seharusnya memberi Anda titik awal. 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 (4 vCPU/32 GiB RAM)
Penjaringan Dipercepat Aktifkan
Versi SQL Server SQL Server 2019 atau yang lebih baru
Jumlah file data 4
Jumlah file log 1
Jumlah 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 (New Technology File System)
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 Premium SSD 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 bawaan atau Premium SSD v2 yang setara		 Cache = TIDAK ADA
Parameter maksimum memori SQL Server 90% 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 $200 miliar dan lebih dari 200 ribu karyawan penuh waktu. Sistem ini menjalankan semua pemrosesan keuangan, penjualan, pemrosesan distribusi, dan banyak proses bisnis lainnya dari berbagai area, termasuk penggajian Amerika Utara. 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
Jumlah file data 32
Jumlah file log 1
Jumlah file data sementara 8
Sistem operasi Windows Server 2019
Agregasi disk Ruang Penyimpanan
Sistem file NTFS (New Technology File System)
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 tempdb disk Penyimpanan premium v1: 1 x P30 atau SSD Premium yang setara v2 Tidak ada cache
Parameter maksimum memori SQL Server 95% RAM Fisik

Ikhtisar Umum SQL Server untuk SAP di Azure

Ada banyak rekomendasi dalam panduan ini dan kami menyarankan Anda membacanya lebih dari sekali sebelum merencanakan penyebaran Azure Anda. 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.
  • Untuk menyeimbangkan tata letak file data dan pembatasan Azure, rencanakan lanskap sistem SAP Anda dengan cermat di 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 pernah menginstal perangkat lunak atau menempatkan file apa pun yang memerlukan persistensi pada drive D:\ karena tidak aman. Apa pun pada drive ini dapat hilang saat reboot Windows atau restart VM.
  • Untuk mereplikasi data database, gunakan solusi SQL Server AlwaysOn Anda.
  • Selalu gunakan Resolusi Nama, jangan mengandalkan alamat IP.
  • Menggunakan SQL Server TDE, terapkan patch SQL Server terbaru.
  • Berhati-hatilah menggunakan gambar SQL Server dari Azure Marketplace. Jika Anda menggunakan SQL Server, Anda harus mengubah pengurutan instans sebelum memasang sistem SAP NetWeaver padanya.
  • Pasang dan konfigurasikan SAP Host Monitoring untuk Azure seperti yang dijelaskan dalam Panduan Penggunaan.
  • Last updated on