Ketersediaan Tinggi menggunakan Grup Ketersediaan AlwaysOn SQL Server - BizTalk Server

Konfigurasikan ketersediaan tinggi menggunakan grup ketersediaan AlwaysOn SQL Server.

Petunjuk / Saran

Menyiapkan BizTalk Server 2016 menggunakan grup ketersediaan LAB menyediakan panduan langkah demi langkah yang ditulis oleh teknisi bidang Microsoft. Ini didasarkan pada lingkungan lab, dan mencakup beberapa pengamatan. Periksalah.

Penting

• BizTalk Server mendukung Grup Ketersediaan AlwaysOn yang dimulai dengan SQL Server 2016 dan yang lebih baru. Jika Anda menggunakan versi SQL Server sebelumnya, artikel ini tidak berlaku untuk Anda.
• BizTalk Server mendukung mode penerapan sinkron; mode penerapan asinkron tidak didukung. Untuk pemulihan bencana, disarankan untuk mengonfigurasi tugas Backup BizTalk Server dan menggunakan pengiriman log. Lihat Mencadangkan dan Memulihkan Database BizTalk Server untuk detail tertentu.

Mode Ketersediaan merinci opsi penerapan dengan Grup Ketersediaan AlwaysOn.

Latar belakang dan riwayat

BizTalk Server sangat bergantung pada SQL Server untuk persistensi data. Komponen dan host lain di BizTalk Server memiliki peran khusus saat mengintegrasikan aplikasi bisnis yang berbeda, seperti menerima, memproses, atau merutekan pesan. Komputer basis data merekam pekerjaan ini dan menyimpannya ke disk.

BizTalk menggunakan SQL Server Failover Clustering dan Log Shipping untuk menyediakan ketersediaan tinggi, pencadangan dan pemulihan, serta pemulihan bencana untuk databasenya. Di Azure IaaS (komputer virtual Azure), sebelumnya, BizTalk (Windows dan SQL) tidak mendukung Instans Kluster Failover karena tidak ada disk bersama yang didukung, yang diperlukan untuk pengklusteran SQL dan MSDTC. Akibatnya, BizTalk tidak memiliki solusi KETERSEDIAAN TINGGI saat menggunakan Azure VM. Karena Azure Shared Disk sekarang tersedia, dimungkinkan untuk mengkluster SQL dan MSDTC di Azure VM. Instans Kluster Failover SQL menggunakan Disk Bersama Azure adalah solusi yang paling tersedia.

Dimulai dengan SQL Server 2016, Grup Ketersediaan AlwaysOn SQL Server mendukung MSDTC untuk lokal dan menggunakan Azure VM. Akibatnya, fitur AlwaysOn SQL Server 2016 (atau yang lebih baru) didukung untuk database BizTalk lokal atau dalam skenario IaaS Azure. Karena terdapat overhead tambahan dengan sinkronisasi disk sinkron saat menggunakan Storage Spaces Direct (S2D) dan waktu tambahan selama failover, S2D kurang tersedia dibandingkan dengan Instans Kluster Failover SQL.

Grup Ketersediaan AlwaysOn pada SQL Server 2016

Menyebarkan Grup Ketersediaan AlwaysOn memerlukan kluster Windows Server Failover Clustering (WSFC). Setiap replika ketersediaan dari grup ketersediaan yang diberikan harus berada di node yang berbeda dalam kluster WSFC yang sama. Grup sumber daya WSFC dibuat untuk setiap grup ketersediaan yang Anda buat. Kluster WSFC memantau grup sumber daya ini untuk mengevaluasi kesehatan replika utama.

Ilustrasi berikut menunjukkan grup ketersediaan yang berisi satu replika utama dan empat replika sekunder.

Para klien dapat terhubung ke replika utama dari grup ketersediaan tertentu menggunakan availability group listener. Pendengar grup ketersediaan menyediakan serangkaian sumber daya yang terkait dengan grup ketersediaan tertentu untuk mengarahkan koneksi klien ke replika ketersediaan yang tepat.

Penting

SQL Server 2016 mendukung MSDTC dengan Grup Ketersediaan AlwaysOn (AG) di Windows Server 2016 dan Windows Server 2012 R2. Windows Server 2012 R2 memerlukan perbaikan Windows 3090973 diinstal. Windows Server 2016 mengharuskan kunci registri RemoteAccessEnabled diaktifkan.

SQL Server tidak mendukung MSDTC dengan AlwaysOn AG untuk versi apa pun sebelum 2016. SQL Server 2016 SP2 meningkatkan penanganan transaksi MSDTC sehingga SP2 atau yang lebih baru direkomendasikan.

Menyediakan ketersediaan tinggi untuk database BizTalk menggunakan Grup Ketersediaan AlwaysOn

Dalam konfigurasi dasar BizTalk Server, minimal 9 database dibuat termasuk Aturan dan database BAM.

Sebelum SQL Server 2016 SP2, Grup Ketersediaan tidak mendukung MSDTC antara database pada instans SQL yang sama sehingga database BizTalk harus didistribusikan di minimal 4 instans SQL. Karena batasan ini, disarankan untuk menggunakan SQL Server 2016 SP2 (atau lebih tinggi) dan BizTalk Server 2016 CU5 (atau lebih tinggi) sehingga semua database BizTalk dapat menggunakan instans SQL Server yang sama. Anda mungkin masih mempertimbangkan untuk menggunakan lebih dari satu instans SQL karena alasan performa (misalnya memiliki MessageBox pada instans SQL yang berbeda).

Dalam skenario MessageBox yang diskalakan (konfigurasi dengan lebih dari satu MessageBox), ada lebih dari satu database MessageBox, dan setiap database MessageBox harus ditambahkan ke grup ketersediaan.

BizTalk Server juga bergantung pada SQL Server Analysis Services dan SQL Server Integration Services untuk Analisis dan Pengarsipan BAM. SQL Server tidak menyediakan solusi ketersediaan tinggi untuk Integration Services atau Analysis Services di Azure IaaS. Oleh karena itu, disarankan untuk menggunakan instans SQL Server mandiri lainnya untuk database BAMArchive dan BAMAnalysis Analysis Services. Untuk penginstalan di lokasi, Instans Klaster Failover SQL dapat digunakan untuk membuat konfigurasi ketersediaan tinggi.

Untuk BizTalk Server 2016, konfigurasi ini ditampilkan dalam gambar berikut, dan direkomendasikan untuk database BizTalk dalam Grup Ketersediaan (seperti disebutkan di atas, dimulai dengan SQL 2016 SP2 dan BizTalk 2016 CU5, 4 instans SQL tidak lagi diperlukan):

Dimulai dengan BizTalk Server 2020, ketersediaan tinggi untuk paket BAM DTS didukung menggunakan Katalog SSIS. Tambahkan database SSISDB ke grup ketersediaan yang sama dengan database BizTalk Server. Konfigurasi ini ditampilkan dalam gambar berikut, dan direkomendasikan untuk database BizTalk di Grup Ketersediaan (seperti disebutkan di atas, 4 instans SQL tidak lagi diperlukan):

Selain database SQL Server, konfigurasi BizTalk Server juga membuat login keamanan SQL Server dan Pekerjaan Agen SQL. Grup Ketersediaan AlwaysOn hanya menyediakan kemampuan untuk mengelola database di dalam Grup Ketersediaan. Pada semua replika ketersediaan, login BizTalk Server dan Tugas Agen SQL perlu dibuat dan diperbarui secara manual.

Daftar login keamanan SQL Server berikut dikaitkan dengan BizTalk Server. Anda mungkin memiliki login tambahan yang dibuat untuk aplikasi BizTalk Server Anda. Jika demikian, Anda perlu mereplikasinya pada setiap instans SQL Server yang menghosting replika database BizTalk.

1. Pengguna Aplikasi BizTalk (satu atau beberapa yang terkait dengan setiap Host in-proc)
2. Pengguna BizTalk Host Terisolasi (satu atau beberapa yang sesuai dengan setiap Host Terisolasi)
3. Administrator BizTalk Server
4. Pengelola BizTalk Server B2B
5. Operator BizTalk Server
6. Administrator SSO
7. Pengguna Pemberitahuan BAM
8. Pengguna Layanan Web Manajemen BAM
9. Akun Layanan Pembaruan Mesin Aturan

Jika Anda telah membuat host tambahan atau akan membuat host tambahan nanti, akan ada login SQL baru yang dibuat sebagai bagian dari proses ini. Anda harus memastikan untuk membuat login SQL ini secara manual pada replika yang sesuai.

Pekerjaan SQL Server Agent berikut dikaitkan dengan BizTalk Server. Pekerjaan yang diinstal pada setiap server berbeda tergantung pada fitur mana yang diinstal dan dikonfigurasi. Sebagian besar pekerjaan ini dibuat selama konfigurasi BizTalk Server. Beberapa dibuat saat mengonfigurasi pengiriman log data. Pekerjaan ini perlu direplikasi pada setiap instans replika hosting SQL Server dari database BizTalk yang sesuai. Ini harus dilakukan secara manual.

• Pekerjaan BizTalkMgmtDb:
  • Backup BizTalk Server (BizTalkMgmtDb)
  • CleanupBTFExpiredEntriesJob_BizTalkMgmtDb
  • Memantau BizTalk Server (BizTalkMgmtDb)
• Pekerjaan BizTalkMsgBoxDb:
  • MessageBox_DeadProcesses_Cleanup_BizTalkMsgBoxDb
  • MessageBox_Message_Cleanup_BizTalkMsgBoxDb
  • MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb
  • MessageBox_Parts_Cleanup_BizTalkMsgBoxDb
  • MessageBox_UpdateStats_BizTalkMsgBoxDb
  • Operations_OperateOnInstances_OnMaster_BizTalkMsgBoxDb
  • PurgeSubscriptionsJob_BizTalkMsgBoxDb
  • TrackedMessages_Copy_BizTalkMsgBoxDb
• Tugas untuk kotak-kotak pesan tambahan
• Pekerjaan BizTalkDTADb:
  • Pembersihan dan Arsip DTA (BizTalkDTADb)
• Pekerjaan BizTalkRulesEngineDb:
  • Rules_Database_Cleanup_BizTalkRuleEngineDb
• Pekerjaan BAMAlertsApplication:
  • 0 atau lebih DelAlertHistJob

Tidak seperti Instans Pengklusteran Failover SQL, di Grup Ketersediaan semua replika aktif, berjalan, dan tersedia. Ketika SQL Agent job diduplikasi pada setiap replika untuk failover, job tersebut akan berjalan pada replika yang sesuai, terlepas dari apakah replika tersebut saat ini berperan sebagai utama atau sekunder. Untuk memastikan pekerjaan ini hanya dijalankan pada replika utama saat ini, setiap langkah dalam setiap pekerjaan harus diapit dalam blok IF, seperti yang ditunjukkan:

IF (sys.fn_hadr_is_primary_replica(‘dbname’) = 1)  
BEGIN  
…  
END

Ganti ‘dbname’ dengan nama database yang sesuai tempat pekerjaan dikonfigurasi untuk dijalankan. Contoh berikut menunjukkan perubahan ini untuk TrackedMessages_Copy_BizTalkMsgBoxDb di BizTalkMsgBoxDb:

Mengonfigurasi BizTalk saat Availability Group sudah disiapkan

1. Periksa persyaratan OS Anda:
   • Di semua komputer Windows Server 2012 R2 , instal perbaikan 3090973 MSDTC (membuka artikel KB).
   • Pada semua komputer Windows Server 2016 , aktifkan kunci registri RemoteAccessEnabled (membuka artikel KB).
2. Buat Grup Ketersediaan yang diperlukan. Pastikan Grup Ketersediaan dibuat dengan opsi Dukungan DTC Per Database.
3. Saat mengonfigurasi BizTalk Server dan menentukan nama server SQL, gunakan nama pendengar Grup Ketersediaan alih-alih nama komputer yang sebenarnya. Ini membuat database BizTalk, login, dan tugas SQL Agent pada replika utama saat ini.
4. Hentikan pemrosesan BizTalk (Instans Host, Layanan SSO, IIS, Layanan Pembaruan Mesin Aturan, Layanan BAMAlerts, dan sebagainya), dan hentikan Pekerjaan Agen SQL.
5. Sekarang tambahkan database BizTalk ke Grup Ketersediaan masing-masing.
6. Sertakan isi langkah-langkah pekerjaan Agen SQL dalam IF blok (disebutkan sebelumnya) untuk memastikan mereka berjalan hanya jika target adalah replika utama.
7. Skrip Login dan Tugas Agen SQL untuk mereplikasinya pada replika yang sesuai.
8. Replika Profil dan Akun SQL DBMail untuk Pemberitahuan BAM pada instans SQL terkait yang menghosting replika sekunder.
9. Jika Anda menambahkan database kotak pesan tambahan atau menyebarkan aktivitas/tampilan BAM baru nanti, maka pekerjaan SQL baru dibuat untuk database kotak pesan baru atau database Pemberitahuan BAM pada replika utama saat ini. Pastikan untuk mengeditnya pada replika utama, lalu buat secara manual pada replika sekunder yang sesuai.
10. Dimulai dengan BizTalk Server 2020 dan yang lebih baru, paket BAM DTS disebarkan ke Katalog SSIS. Tambahkan database SSISDB ke grup ketersediaan yang sama dengan database BizTalk. Untuk informasi selengkapnya, lihat AlwaysON untuk Katalog SSIS.

Konfigurasi ini juga dapat dilakukan menggunakan Instans SQL yang menghosting replika utama. Dalam hal ini, setelah konfigurasi BizTalk, jalankan UpdateDatabase.vbs skrip dan UpdateRegistry.vbs pada mesin BizTalk setelah langkah-langkah di atas. Ini dibahas secara lebih rinci di bagian berikutnya.

Memindahkan database BizTalk yang sudah ada ke Grup Ketersediaan

1. Periksa persyaratan OS Anda:

   • Di semua komputer Windows Server 2012 R2 , instal perbaikan 3090973 MSDTC (membuka artikel KB)
   • Pada semua komputer Windows Server 2016 , aktifkan kunci registri RemoteAccessEnabled (membuka artikel KB)

2. Buat Grup Ketersediaan yang diperlukan. Pastikan Grup Ketersediaan dibuat dengan opsi Dukungan DTC Per Database.

3. Hentikan pemrosesan BizTalk dan Pekerjaan Agen SQL.

4. Lakukan pencadangan penuh semua Database BizTalk.

5. Pulihkan basis data BizTalk pada instance SQL yang saat ini berada dalam peran primer dalam Grup Ketersediaan.

6. Login Skrip dan pekerjaan Agen SQL pada Instans SQL yang sesuai saat ini dalam peran utama dalam Grup Ketersediaan.

7. Jalankan UpdateDatabase.vbs skrip dan UpdateRegistry.vbs pada mesin BizTalk menggunakan langkah-langkah berikut. Masukkan Listener Grup Availabilitas sebagai nama server baru pada info pembaruan masukan xml.

   1. Hentikan semua layanan BizTalk dan layanan SSO Enterprise di BizTalk Server. Hentikan Layanan Agen SQL di SQL Server.

   2. Di BizTalk Server, edit SampleUpdateInfo.xml di folder berikut:

      Komputer 32-bit: %SystemRoot%\Program Files\Microsoft BizTalk Server 20xx\Schema\Restore

      Komputer 64-bit: %SystemRoot%\Program Files (x86)\Microsoft BizTalk Server 20xx\Bins32\Schema\Restore

      1. Ganti "SourceServer" dengan nama server sumber (SQL Server lama yang menghosting database lama).
      2. Ganti "DestinationServer" dengan nama server tujuan, yang seharusnya menjadi nama pendengar grup ketersediaan.
      3. Jika Anda memiliki BAMAnalysis, database BAM, atau RuleEngineDB, batalkan komentar bagian yang sesuai.

   3. Buka prompt perintah, kemudian pergi ke:

      Komputer 32-bit: %SystemRoot%\Program Files\Microsoft BizTalk Server 20xx\Schema\Restore

      Komputer 64-bit: %SystemRoot%\Program Files (x86)\Microsoft BizTalk Server 20xx\Bins32\Schema\Restore

      Pada jendela perintah, jalankan:
      cscript UpdateDatabase.vbs SampleUpdateInfo.xml

      Jalankan UpdateDatabase.vbs hanya di satu server di grup BizTalk.

   4. Salin file SampleUpdateInfo.xml yang diedit ke folder berikut di setiap komputer BizTalk Server dalam grup BizTalk ini:

      Komputer 32-bit: %SystemRoot%\Program Files\Microsoft BizTalk Server 20xx\Schema\Restore

      Komputer 64-bit: %SystemRoot%\Program Files (x86)\Microsoft BizTalk Server 20xx\Bins32\Schema\Restore

   5. Pada setiap komputer di grup BizTalk Server, buka prompt perintah, dan pergi ke:

      Komputer 32-bit: %SystemRoot%\Program Files\Microsoft BizTalk Server 20xx\Schema\Restore

      Komputer 64-bit: %SystemRoot%\Program Files (x86)\Microsoft BizTalk Server 20xx\Bins32\Schema\Restore

      Pada jendela perintah, jalankan:
      cscript UpdateRegistry.vbs SampleUpdateInfo.xml

      Jalankan UpdateRegistry.vbs di setiap server di grup BizTalk.

8. Sekarang pindahkan database ke Grup Ketersediaan masing-masing.

9. Replikasi Profil SQL DBMail dan Akun untuk Pemberitahuan BAM pada instans SQL yang menghosting replika database BAMAlerts.

10. Sertakan isi langkah-langkah pekerjaan Agen SQL dalam blok IF untuk memastikan mereka berjalan hanya jika target adalah yang utama.

11. Skrip Login dan SQL Agent Jobs untuk mereplikasikannya pada replika yang sesuai. Skrip UpdateDatabase juga memperbarui nama server dalam pekerjaan Operations_OperateOnInstances_OnMaster_BizTalkMsgBoxDb dan TrackedMessages_Copy_BizTalkMsgBoxDb. Jadi skrip Pekerjaan Agen SQL hanya setelah menjalankan skrip UpdateDatabase.

Persyaratan

• BizTalk Server:
  • BizTalk Server 2020 Enterprise
  • BizTalk Server 2016 Enterprise CU5
• SQL Server:

  • SQL Server 2019 Enterprise atau Standard

  • SQL Server 2017 Enterprise atau Standard

  • SQL Server 2016 Enterprise atau Standard.

    Lihat Batasan yang diketahui dalam artikel ini untuk batasan SQL Server Standard Edition.

• Windows Server
  • Windows Server 2019
  • Windows Server 2016
  • Windows Server 2012 R2

Listener Grup Ketersediaan dikonfigurasi dengan port yang bukan default (1433)

Gunakan alias SQL pada mesin BizTalk Server.

Grup Ketersediaan Multi-Subnet

BizTalk Server tidak mendukung opsi koneksi MultiSubnetFailover (=TRUE).

Lihat dokumentasi SQL untuk informasi selengkapnya tentang masalah yang dapat terjadi saat menyambungkan klien SQL yang tidak mendukung opsi ini ke grup ketersediaan SQL multi-subnet. Beberapa masalah ini dibahas dalam tautan berikut:

• Batas Waktu Koneksi dalam Grup Ketersediaan Multi-subnet
• Latensi Pemulihan Klien Selama Failover

Pengarahan Baca-Saja

Perutean read-only mengacu pada kemampuan SQL Server untuk merutekan koneksi masuk untuk pendengar grup ketersediaan ke replika sekunder yang dikonfigurasi untuk memungkinkan beban kerja read-only.

BizTalk tidak menggunakan "Read-Only Routing" untuk semua koneksi ke database-nya. Ini berarti opsi "Sekunder yang Dapat Dibaca" pada Availability Replicas dalam grup ketersediaan tidak berdampak pada koneksi database BizTalk.

Perilaku Instans Host BizTalk selama Failover SQL Server

Jika grup ketersediaan SQL Server mengalami failover, database BizTalk Server pada grup ketersediaan untuk sementara tidak tersedia.

Perilaku Instans Host In-Process selama Failover SQL Server

Jika database BizTalk Server tidak tersedia, maka instans dalam proses host BizTalk Server didaur ulang hingga koneksi ke SQL Server dipulihkan. Setelah koneksi ke database SQL Server dipulihkan, pemrosesan dokumen dilanjutkan secara normal.

Perilaku Instans Host Terisolasi Selama Failover SQL Server

Jika database BizTalk Server tidak tersedia, maka instans terisolasi dari host BizTalk Server berhenti sementara, dan kesalahan yang mirip dengan yang berikut ini dihasilkan di log Aplikasi BizTalk Server:

All receive locations are being temporarily disabled because either the MessageBox or Configuration database is not available. When these databases become available, the receive locations will be automatically enabled.

Setelah koneksi ke database SQL Server dipulihkan, pesan informasi yang mirip dengan berikut ini ditulis ke log Aplikasi BizTalk Server, lalu pemrosesan dokumen dilanjutkan secara normal:

All receive locations are being enabled because both the MessageBox and Configuration databases are back online.

Pengiriman Log Data untuk Pemulihan Bencana

BizTalk Server mengimplementasikan kemampuan siaga database melalui penggunaan pengiriman log database. Pengiriman log BizTalk Server mengotomatiskan pencadangan dan pemulihan database dan file log transaksi mereka, memungkinkan server siaga untuk melanjutkan pemrosesan database jika server database produksi gagal.

Database sekunder dalam grup ketersediaan bukan cadangan. Lanjutkan melanjutkan pencadangan database BizTalk dan log transaksinya menggunakan tugas Pengiriman Log pada BizTalk Server. Cara implementasi BizTalk Log Shipping memastikan pencadangan selalu dilakukan terhadap replika utama yang sedang aktif dari setiap database. Pengaturan preferensi pencadangan pada grup ketersediaan tidak dihormati oleh pekerjaan Pengiriman Log Server BizTalk.

Jika Anda menambahkan database BizTalk lainnya ke dalam tugas pencadangan Database BizTalk, pastikan untuk menggunakan nama Listener Grup Ketersediaan sebagai server database saat menyiapkan cadangan.

Referensi

• Menyediakan Ketersediaan Tinggi untuk Database BizTalk Server
• dukungan perangkat lunak server Microsoft untuk komputer virtual Microsoft Azure
• Pencerminan database SQL Server, layanan Volume Shadow Copy, dan Always On
• Gambaran Umum Grup Ketersediaan AlwaysOn (SQL Server)
• Dukungan Transaksi Lintas Database untuk Database Mirroring atau AlwaysOn Availability Groups (SQL Server)
• Daftar ulang tidak dapat dipanggil ketika SQL Server menerima hasil transaksi dari MSDTC di Windows Server 2012 R2
• Mencadangkan dan Memulihkan Database Server BizTalk
• Cara Memindahkan Database BizTalk Server
• Cara Memulihkan Database Anda
• Batas Waktu Koneksi dalam Grup Ketersediaan Multi-subnet

Batasan yang diketahui

Batasan ini untuk BizTalk Server, Grup Ketersediaan AlwaysOn SQL Server, dan Azure Virtual Machines. Batasan ini mungkin atau mungkin tidak ditangani di masa mendatang.

• Login, Pekerjaan Agen SQL, profil Email SQL DB, dan akun tidak dikelola dalam Grup Ketersediaan. Ini memerlukan modifikasi manual dalam Pekerjaan untuk memastikan mereka berjalan terhadap replika utama.

• SQL Server Analysis Services dan SQL Server Integration Services tidak berpartisipasi dalam Grup Ketersediaan. Tanpa dukungan ini dari SQL Server, tidak ada solusi HA untuk Azure Virtual Machines ini. Kemampuan BAM BizTalk Server bergantung pada layanan ini.

• Sebelum SQL Server 2016 SP2, Grup Ketersediaan tidak mendukung MSDTC antar database pada instans SQL yang sama.

  Dimulai dengan SQL Server 2016 SP2 dan BizTalk Server 2016 CU5, database BizTalk dapat menggunakan instans SQL Server yang sama.

• BizTalk Server tidak dapat menggunakan Perutean Read-Only.

• BizTalk Server tidak mengatur MultiSubnetFailover properti koneksi.

• Pekerjaan Pencadangan BizTalk menggunakan Pengiriman Log akan selalu menargetkan salinan utama tanpa memperhatikan preferensi cadangan yang ditetapkan pada Grup Ketersediaan.

• Standar SQL Server 2016 hanya mendukung satu database tunggal di setiap SQL AlwaysOn AG. Karena BizTalk menggunakan banyak database, edisi SQL Server Enterprise biasanya direkomendasikan.

• Jika menggunakan Azure VM, disarankan untuk menggunakan port TCP/IP tetap khusus untuk MSDTC. Saat menggunakan port TCP/IP tetap, Anda tidak membatasi rentang port RPC yang biasanya digunakan dengan sistem operasi yang lebih lama; dan membantu menyederhanakan firewall dan aturan load balancer Anda. Untuk menghindari konflik dengan port bawah yang diketahui, pertimbangkan untuk menggunakan port tetap yang lebih tinggi (seperti >20000). Mengonfigurasi Dukungan Port Tunggal DTC menjelaskan kunci registri ServerTcpPort . Selain port tetap untuk MSDTC, port RPC utama 135 juga digunakan.

Langkah selanjutnya

Rencanakan toleransi kesalahan.