Reporting Services dengan Grup Ketersediaan AlwaysOn (SQL Server)
Topik ini berisi informasi tentang mengonfigurasi Reporting Services untuk bekerja dengan Grup Ketersediaan AlwaysOn (AG) di SQL Server 2014. Tiga skenario untuk menggunakan Reporting Services dan Grup Ketersediaan AlwaysOn adalah database untuk sumber data laporan, database server laporan, dan desain laporan. Fungsionalitas yang didukung dan konfigurasi yang diperlukan berbeda untuk tiga skenario.
Manfaat utama menggunakan Grup Ketersediaan AlwaysOn dengan sumber data Reporting Services adalah memanfaatkan replika sekunder yang dapat dibaca sebagai sumber data pelaporan sementara, pada saat yang sama replika sekunder menyediakan failover untuk database utama.
Untuk informasi umum tentang Grup Ketersediaan AlwaysOn, lihat Tanya Jawab Umum AlwaysOn untuk SQL Server 2012 (https://msdn.microsoft.com/sqlserver/gg508768).
Persyaratan untuk menggunakan Reporting Services dan Grup Ketersediaan AlwaysOn
Untuk menggunakan Grup Ketersediaan AlwaysOn dengan SQL Server 2014 Reporting Services, Anda perlu mengunduh dan menginstal perbaikan untuk .Net 3.5 SP1. Perbaikan menambahkan dukungan ke Klien SQL untuk fitur AG dan dukungan properti string koneksi ApplicationIntent dan MultiSubnetFailover. Jika Hotfix tidak diinstal pada setiap komputer yang menghosting server laporan, maka pengguna yang mencoba mempratinjau laporan akan melihat pesan kesalahan yang mirip dengan yang berikut ini, dan pesan kesalahan akan ditulis ke log jejak server laporan:
Pesan kesalahan: "Kata kunci tidak didukung 'applicationintent'"
Pesan terjadi ketika Anda menyertakan salah satu properti Grup Ketersediaan AlwaysOn dalam string koneksi Reporting Services, tetapi server tidak mengenali properti . Pesan kesalahan yang dicatat akan terlihat ketika Anda mengklik tombol 'Uji Koneksi' di antarmuka pengguna Reporting Services dan ketika Anda mempratinjau laporan jika kesalahan jarak jauh diaktifkan di server laporan.
Untuk informasi selengkapnya tentang perbaikan yang diperlukan, lihat perbaikan KB 2654347A memperkenalkan dukungan untuk fitur AlwaysOn dari SQL Server 2012 ke .NET Framework 3.5 SP1.
Untuk informasi tentang persyaratan Grup Ketersediaan AlwaysOn lainnya, lihat Prasyarat, Pembatasan, dan Rekomendasi untuk Grup Ketersediaan AlwaysOn (SQL Server).
Catatan
File konfigurasi Reporting Services seperti RSreportserver.config tidak didukung sebagai bagian dari fungsi grup ketersediaan AlwaysOn. Jika Anda membuat perubahan secara manual pada file konfigurasi di salah satu server laporan, Anda harus memperbarui replika secara manual.
Melaporkan Sumber Data dan Grup Ketersediaan
Perilaku sumber data Reporting Services berdasarkan Grup Ketersediaan AlwaysOn dapat bervariasi tergantung pada bagaimana administrator Anda telah mengonfigurasi lingkungan AG.
Untuk menggunakan Grup Ketersediaan AlwaysOn untuk sumber data laporan, Anda perlu mengonfigurasi string koneksi sumber data laporan adalah menggunakan nama DNS Listener grup ketersediaan. Sumber data yang didukung adalah sebagai berikut:
Sumber data ODBC menggunakan SQL Native Client.
Klien SQL, dengan perbaikan .Net diterapkan ke server laporan.
String koneksi juga dapat berisi properti koneksi AlwaysOn baru yang mengonfigurasi permintaan kueri laporan untuk menggunakan replika sekunder untuk pelaporan baca-saja. Penggunaan replika sekunder untuk permintaan pelaporan akan mengurangi beban pada replika utama baca-tulis. Ilustrasi berikut adalah contoh konfigurasi AG tiga replika di mana string koneksi sumber data Reporting Services telah dikonfigurasi dengan ApplicationIntent=ReadOnly. Dalam contoh ini, permintaan kueri laporan dikirim ke replika sekunder dan bukan replika utama.
Berikut ini adalah contoh string koneksi, di mana [AvailabilityGroupListenerName] adalah Nama DNS Listener yang dikonfigurasi saat replika dibuat:
Data Source=[AvailabilityGroupListenerName];Initial Catalog = AdventureWorks2008R2; ApplicationIntent=ReadOnly
Tombol Uji Koneksi di antarmuka pengguna Reporting Services akan memvalidasi apakah koneksi dapat dibuat tetapi tidak akan memvalidasi konfigurasi AG. Misalnya jika Anda menyertakan ApplicationIntent dalam string koneksi ke server yang bukan bagian dari AG, parameter tambahan diabaikan dan tombol Uji Koneksi hanya akan memvalidasi koneksi yang dapat dibuat ke server yang ditentukan.
Bergantung pada bagaimana laporan Anda dibuat dan diterbitkan akan menentukan di mana Anda mengedit string koneksi:
Mode asli: Gunakan Manajer Laporan untuk sumber data bersama dan laporan yang sudah diterbitkan ke server laporan mode asli.
Mode SharePoint: Gunakan halaman konfigurasi SharePoint dalam pustaka dokumen untuk laporan yang sudah diterbitkan ke server SharePoint.
Desain Laporan: SQL Server Report Builder untuk SQL Server 2012 atau SQL Server Data Tools (SSDT) saat Anda membuat laporan baru. Lihat bagian 'Desain Laporan' dalam topik ini atau informasi selengkapnya.
Sumber Daya Tambahan:
Untuk informasi selengkapnya tentang properti string koneksi yang tersedia, lihat Menggunakan Kata Kunci String Koneksi dengan SQL Server Native Client.
Untuk informasi selengkapnya tentang listener grup ketersediaan, lihat Membuat atau Mengonfigurasi Listener Grup Ketersediaan (SQL Server).
Pertimbangan: Replika sekunder biasanya akan mengalami keterlambatan dalam menerima perubahan data dari replika utama. Faktor-faktor berikut dapat memengaruhi latensi pembaruan antara replika primer dan sekunder:
Jumlah replika sekunder. Penundaan meningkat dengan setiap replika sekunder ditambahkan ke konfigurasi.
Lokasi geografis dan jarak antara replika primer dan sekunder. Misalnya penundaan biasanya lebih besar jika replika sekunder berada di pusat data yang berbeda daripada jika mereka berada di bangunan yang sama dengan replika utama.
Konfigurasi mode ketersediaan untuk setiap replika. Mode ketersediaan menentukan apakah replika utama menunggu untuk melakukan transaksi pada database hingga replika sekunder telah menulis transaksi ke disk. Untuk informasi selengkapnya, lihat bagian 'Mode Ketersediaan' dari Gambaran Umum Grup Ketersediaan AlwaysOn (SQL Server).
Saat menggunakan sekunder baca-saja sebagai sumber data Reporting Services, penting untuk memastikan bahwa latensi pembaruan data memenuhi kebutuhan pengguna laporan.
Grup Desain dan Ketersediaan Laporan
Saat mendesain laporan di SQL Server Report Builder untuk SQL Server 2012 atau proyek laporan di SQL Server Data Tools (SSDT), pengguna dapat mengonfigurasi string koneksi sumber data laporan untuk berisi properti koneksi baru yang disediakan oleh Grup Ketersediaan AlwaysOn. Dukungan untuk properti koneksi baru bergantung pada di mana pengguna mempratinjau laporan.
Pratinjau lokal: SQL Server Report Builder untuk SQL Server 2012 dan SQL Server Data Tools (SSDT) menggunakan .Net framework 4.0 dan mendukung properti string koneksi Grup Ketersediaan AlwaysOn.
Pratinjau mode jarak jauh atau server: Jika setelah menerbitkan laporan ke server laporan atau menggunakan pratinjau di SQL Server Report Builder untuk SQL Server 2012, Anda melihat kesalahan yang mirip dengan yang berikut ini, ini adalah indikasi Anda mempratinjau laporan terhadap server laporan dan Hotfix .Net Framework 3.5 SP1 untuk Grup Ketersediaan AlwaysOn belum diinstal di server laporan.
Pesan kesalahan: "Kata kunci tidak didukung 'applicationintent'"
Database Server Laporan dan Grup Ketersediaan
Reporting Services menawarkan dukungan terbatas untuk menggunakan Grup Ketersediaan AlwaysOn dengan database server laporan. Database server laporan dapat dikonfigurasi di AG untuk menjadi bagian dari replika; namun Reporting Services tidak akan secara otomatis menggunakan replika yang berbeda untuk database server laporan ketika failover terjadi.
Tindakan manual atau skrip otomatisasi kustom perlu digunakan untuk menyelesaikan failover dan pemulihan. Hingga tindakan ini selesai, beberapa fitur server laporan mungkin tidak berfungsi dengan benar setelah failover Grup Ketersediaan AlwaysOn.
Catatan
Saat merencanakan failover dan pemulihan bencana untuk database server laporan, disarankan agar Anda selalu mencadangkan salinan kunci enkripsi server laporan.
Perbedaan antara Mode Asli SharePoint
Bagian ini merangkum perbedaan antara bagaimana mode SharePoint dan server laporan mode asli berinteraksi dengan Grup Ketersediaan AlwaysOn.
Server laporan SharePoint membuat 3 database untuk setiap aplikasi layanan Reporting Services yang Anda buat. Koneksi ke database server laporan dalam mode SharePoint dikonfigurasi di Administrasi Pusat SharePoint saat Anda membuat aplikasi layanan. Nama default database menyertakan GUID yang terkait dengan aplikasi layanan. Berikut ini adalah contoh nama database, untuk server laporan mode SharePoint:
ReportingService_85c08ac3c8e64d3cb400ad06ed5da5d6
ReportingService_85c08ac3c8e64d3cb400ad06ed5da5d6TempDB
ReportingService_85c08ac3c8e64d3cb400ad06ed5da5d6_Alerting
Server laporan mode asli menggunakan 2 database. Berikut ini adalah contoh nama database, untuk server laporan mode asli:
ReportServer
ReportServerTempDB
Mode asli tidak mendukung atau menggunakan database Pemberitahuan dan fitur terkait. Anda mengonfigurasi server laporan mode asli di Configuration Manager Reporting Services. Untuk mode SharePoint, Anda mengonfigurasi nama database aplikasi layanan untuk menjadi nama "titik akses klien" yang Anda buat sebagai bagian dari konfigurasi SharePoint. Untuk informasi selengkapnya tentang mengonfigurasi SharePoint dengan Grup Ketersediaan AlwaysOn, lihat Mengonfigurasi dan mengelola grup ketersediaan SQL Server untuk SharePoint Server (https://go.microsoft.com/fwlink/?LinkId=245165).
Catatan
Server laporan mode SharePoint menggunakan proses sinkronisasi antara database aplikasi layanan Reporting Services dan database konten SharePoint. Penting untuk mempertahankan database server laporan dan database konten bersama-sama. Anda harus mempertimbangkan untuk mengonfigurasinya dalam grup ketersediaan yang sama sehingga failover dan pulih sebagai satu set. Pertimbangkan skenario berikut:
- Anda memulihkan atau failover ke salinan database konten yang belum menerima pembaruan terbaru yang sama dengan yang diterima database server laporan.
- Proses sinkronisasi Reporting Services akan mendeteksi perbedaan antara daftar item dalam database konten dan database server laporan.
- Proses sinkronisasi akan menghapus atau memperbarui item dalam database konten.
Menyiapkan Database Server Laporan untuk Grup Ketersediaan
Berikut ini adalah langkah-langkah dasar menyiapkan dan menambahkan database server laporan ke Grup Ketersediaan AlwaysOn:
Buat Grup Ketersediaan Anda dan konfigurasikan nama DNS Listener.
Replika Utama: Konfigurasikan database server laporan untuk menjadi bagian dari grup ketersediaan tunggal dan buat replika utama yang menyertakan semua database server laporan.
Replika Sekunder: Buat satu atau beberapa replika sekunder. Pendekatan umum untuk menyalin database dari replika utama ke replika sekunder adalah memulihkan database ke setiap replika sekunder menggunakan 'RESTORE WITH NORECOVERY'. Untuk informasi selengkapnya tentang membuat replika sekunder dan memverifikasi sinkronisasi data berfungsi, lihat Memulai Pergerakan Data pada Database Sekunder AlwaysOn (SQL Server).
Kredensial Server Laporan: Anda perlu membuat kredensial server laporan yang sesuai pada replika sekunder yang Anda buat di primer. Langkah-langkah yang tepat bergantung pada jenis autentikasi apa yang Anda gunakan di lingkungan Reporting Services Anda; Akun layanan Window Reporting Services, akun pengguna Windows, atau autentikasi SQL Server. Untuk informasi selengkapnya, lihat Mengonfigurasi Koneksi Database Server Laporan (Configuration Manager SSRS)
Perbarui koneksi database untuk menggunakan Nama DNS Lister. untuk server laporan mode asli, ubah Nama Database Server Laporan di manajer konfigurasi Reporting Services. Untuk mode SharePoint, ubah Nama server database untuk aplikasi layanan Reporting Services.
Langkah-langkah untuk menyelesaikan pemulihan bencana Database Server Laporan
Langkah-langkah berikut perlu diselesaikan setelah failover Grup Ketersediaan AlwaysOn ke replika sekunder:
Hentikan instans layanan SQL Agent yang sedang digunakan oleh mesin database utama yang menghosting database Reporting Services.
Mulai layanan SQL Agent di komputer yang merupakan replika utama baru.
Hentikan layanan Server Laporan.
Jika server laporan dalam mode asli, hentikan server laporan Windows server menggunakan manajer konfigurasi Reporting Services.
Jika server laporan dikonfigurasi untuk mode SharePoint, hentikan layanan bersama Reporting Services di Administrasi Pusat SharePoint.
Mulai layanan server laporan atau layanan Reporting Services SharePoint.
Verifikasi bahwa laporan dapat berjalan terhadap replika utama baru.
Perilaku Server Laporan Ketika Failover Terjadi
Ketika melaporkan kegagalan database server dan Anda telah memperbarui lingkungan server laporan untuk menggunakan replika utama baru, ada beberapa masalah operasional yang dihasilkan dari proses failover dan pemulihan. Dampak dari masalah ini akan bervariasi tergantung pada beban Reporting Services pada saat failover serta lamanya waktu yang diperlukan Grup Ketersediaan AlwaysOn untuk failover ke replika sekunder dan bagi administrator server laporan untuk memperbarui lingkungan pelaporan untuk menggunakan replika utama baru.
Eksekusi pemrosesan latar belakang dapat terjadi lebih dari sekali karena logika coba lagi dan ketidakmampuan server laporan untuk menandai pekerjaan terjadwal sebagai selesai selama periode failover.
Eksekusi pemrosesan latar belakang yang biasanya dipicu untuk berjalan selama periode failover tidak akan terjadi karena SQL Server Agent tidak akan dapat menulis data ke database server laporan dan data ini tidak akan disinkronkan ke replika utama baru.
Setelah failover database selesai dan setelah layanan server laporan dimulai kembali, SQL Server Agent pekerjaan akan dibuat ulang secara otomatis. Sampai pekerjaan agen SQL dibuat ulang, eksekusi latar belakang apa pun yang terkait dengan pekerjaan SQL Server Agent tidak akan diproses. Ini termasuk langganan Reporting Services, jadwal, rekam jepret.
Lihat juga
SQL Server Native Client Dukungan untuk Ketersediaan Tinggi,Grup Ketersediaan AlwaysOn Pemulihan Bencana (SQL Server)Memulai Grup Ketersediaan AlwaysOn (SQL Server)Menggunakan Kata Kunci String Koneksi dengan SQL Server Native ClientSQL Server Native Client Dukungan untuk Ketersediaan Tinggi, Pemulihan BencanaTentang Akses Koneksi Klien ke Replika Ketersediaan (SQL Server)