Bagikan melalui


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, Anda harus membaca dokumen Pertimbangan untuk penyebaran DBMS Azure Virtual Machines untuk beban kerja SAP dan panduan lainnya 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 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 oleh 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. Hal ini dikarenakan kolase SQL Server default telah terpasang dalam gambar-gambar tersebut dan bukan kolase yang diperlukan oleh 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.

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 oleh 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:\ yang tidak bertahan.
  • Dengan rilis SQL Server yang lebih lama, di mana SQL Server memasang tempdb dengan satu data file secara default, disarankan untuk menggunakan beberapa data file 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 of simple VM disk configuration for 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 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 dibatasi dalam performa oleh 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 pada SQL Server akan memberikan performa terbaik ketika membaca dan menulis didistribusikan secara merata di semua file data 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 akan menyeimbangkan ulang data dari waktu ke waktu. SQL Server akan secara otomatis menumbuhkan datafiles secara merata jika bendera pelacakan 1117 diatur atau jika SQL Server 2016 atau yang lebih tinggi digunakan.

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 yang disediakan oleh penyimpanan premium v1 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.

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 hadir dalam pra-format.

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 yang lebih baru - Menyimpan Database File 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.

Ekstensi Kumpulan Buffer SQL Server 2014

SQL Server 2014 memperkenalkan fitur baru, yang disebut Ekstensi Kumpulan Buffer. Fungsionalitas ini meskipun diuji di bawah beban kerja SAP di Azure tidak memberikan peningkatan dalam beban kerja hosting. Oleh karena itu, seharusnya tidak dipertimbangkan

Pertimbangan Pencadangan/Pemulihan untuk SQL Server

Menyebarkan SQL Server ke Azure, Anda perlu meninjau arsitektur cadangan Anda. Bahkan jika sistem bukan sistem produksi, database SAP yang dihosting oleh SQL Server 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 adalah lebih kepada bahwa Anda dapat mengkompensasi kesalahan logis/manual dengan memberikan titik dalam kemampuan pemulihan waktu. 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 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 berisikan 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.
  • 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 citra SQL Server di Azure Marketplace tidak disiapkan untuk menggunakan kolase, yang mana diperlukan oleh aplikasi SAP NetWeaver, pengaturan 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 dalam penyebaran Azure IaaS untuk SAP, Anda memiliki beberapa kemungkinan berbeda untuk ditambahkan untuk menyebarkan lapisan DBMS 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 akan menjalankan SQL Server Instance aktif. VM lainnya akan 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 DBMS baru di Azure dengan sistem produksi yang sedang berlangsung di tempat. Pada saat pemotongan berlangsung, produksi dimatikan dan memastikan bahwa cadangan log transaksi terakhir dan terbaru ditransfer ke penyebaran Azure DBMS. Kemudian penyebaran Azure DBMS 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:

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 DBMS lain, berjalan di tempat, 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 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. Ini berarti semakin jelas perbedaan volume (huruf drive), semakin banyak thread akan 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:

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 DBMS 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
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
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 DBMS 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
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
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 DBMS 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
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
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 DBMS 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
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
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 DBMS 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
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
Cache = NONE
Parameter memori maks SQL Server 95% RAM Fisik Dengan asumsi instans tunggal

Sebagai contoh, konfigurasi ini adalah konfigurasi VM DBMS 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, pemrosesan penjualan dan distribusi dan banyak lagi proses bisnis di luar area yang berbeda, termasuk penggajian Amerika Utara n. Sistem ini berjalan di Azure sejak awal 2018 menggunakan VM seri Azure M sebagai VM DBMS. 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 di VM Ev4.

Konfigurasi DBMS 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 Windows Server 2019
Agregasi disk Ruang Penyimpanan
Sistem file NTFS
Ukuran blok format 64 KB
# dan jenis disk data Penyimpanan premium v1: 16 x P40 Cache = Hanya Baca
# dan jenis disk log Penyimpanan premium v1: 1 x P60 Menggunakan Akselerator Tulis
# dan jenis disk tempdb Penyimpanan premium v1: 1 x P30 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 DBMS umum teratas pada rekomendasi khusus Azure:

  1. Gunakan rilis DBMS terbaru, seperti SQL Server 2019, yang memiliki keuntungan terbanyak di Azure.
  2. 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.
  3. Jangan pernah menginstal perangkat lunak atau menempatkan file apa pun yang memerlukan persistensi pada drive D:\ karena tidak permanen dan apa pun pada drive ini dapat hilang pada reboot Windows atau mulai ulang VM.
  4. Gunakan solusi HA/DR dari vendor DBMS Anda untuk mereplikasi database data.
  5. Selalu gunakan Resolusi Nama, jangan mengandalkan alamat IP.
  6. Menggunakan SQL Server TDE, terapkan patch SQL Server terbaru.
  7. 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.
  8. Pasang dan konfigurasikan SAP Host Monitoring untuk Azure seperti yang dijelaskan dalam Panduan Penggunaan.

Langkah berikutnya

Baca artikel