Bagikan melalui

Pemecahan masalah runtime integrasi yang dihosting sendiri

  • Artikel

BERLAKU UNTUK: Microsoft Azure Data Factory Azure Synapse Analytics Microsoft Purview

Tip

Cobalah Data Factory di Microsoft Fabric, solusi analitik all-in-one untuk perusahaan. Microsoft Fabric mencakup semuanya mulai dari pergerakan data hingga ilmu data, analitik real time, kecerdasan bisnis, dan pelaporan. Pelajari cara memulai uji coba baru secara gratis!

Artikel ini membahas metode pemecahan masalah umum untuk runtime integrasi (IR) yang dihost sendiri di Azure Data Factory dan ruang kerja Synapse.

Mengumpulkan log IR yang dihost sendiri

Azure Data Factory dan Azure Synapse Analytics

Untuk aktivitas gagal yang berjalan pada IR yang dihost sendiri atau IR bersama, layanan mendukung melihat dan mengunggah log galat. Untuk mendapatkan ID laporan kesalahan, ikuti petunjuk di sini, lalu masukkan ID laporan untuk mencari masalah umum terkait.

  1. Pada halaman Monitor untuk antarmuka pengguna layanan, pilih Eksekusi alur.

  2. Di bawah Eksekusi aktivitas, di kolom Kesalahan, pilih tombol yang disorot untuk menampilkan log aktivitas, seperti yang diperlihatkan dalam cuplikan layar berikut ini:

    Log aktivitas menampilkan eksekusi aktivitas yang gagal.

    Cuplikan layar log aktivitas untuk aktivitas yang gagal.

  3. Untuk bantuan lebih lanjut, pilih Kirim log.

    Jendela Bagikan log runtime integrasi (IR) yang dihost sendiri dengan Microsoft akan terbuka.

    Cuplikan layar

  4. Pilih log mana yang ingin Anda kirim.

    • Untuk IR yang dihost sendiri, Anda dapat mengunggah log yang berkaitan dengan aktivitas yang gagal atau semua log pada node IR yang dihost sendiri.
    • Untuk IR berbagi, Anda hanya dapat mengunggah log yang berkaitan dengan aktivitas yang gagal.

  5. Saat log diunggah, simpan rekaman ID Laporan untuk digunakan nanti jika Anda memerlukan bantuan lebih lanjut untuk menyelesaikan masalah.

    Cuplikan layar ID laporan ditampilkan di jendela proses pengunggahan untuk log runtime integrasi.

Catatan

Permintaan melihat dan mengunggah log dijalankan pada semua instans IR yang dihost sendiri secara online. Jika ada log yang hilang, pastikan bahwa semua instans IR yang dihost sendiri sedang online.

Microsoft Purview

Untuk aktivitas Microsoft Purview yang gagal yang berjalan pada IR yang dihost sendiri atau IR bersama, layanan ini mendukung melihat dan mengunggah log kesalahan dari Windows Pemantau Peristiwa.

Anda dapat mencari kesalahan apa pun yang Anda lihat di panduan kesalahan di bawah ini. Untuk mendapatkan panduan dukungan dan pemecahan masalah untuk masalah SHIR, Anda mungkin perlu membuat ID laporan kesalahan dan menghubungi dukungan Microsoft.

Untuk menghasilkan ID laporan kesalahan untuk Dukungan Microsoft, ikuti instruksi berikut:

  1. Sebelum memulai pemindaian di portal tata kelola Microsoft Purview:

    1. Navigasikan ke komputer tempat runtime integrasi yang dihost sendiri diinstal dan buka Pemantau Peristiwa Windows.
    2. Hapus log Windows Pemantau Peristiwa di bagian Integration Runtime. Klik kanan pada log dan pilih opsi hapus log.
    3. Navigasikan kembali ke portal tata kelola Microsoft Purview dan mulai pemindaian.

  2. Setelah pemindaian menunjukkan status Gagal, navigasikan kembali ke komputer virtual SHIR, atau komputer dan refresh penampil peristiwa di bagian Integration Runtime .

  3. Log aktivitas ditampilkan untuk eksekusi pemindaian yang gagal.

  4. Untuk bantuan lebih lanjut dari Microsoft, pilih Kirim Log.

    Bagikan log runtime integrasi yang dihost sendiri (SHIR) dengan jendela Microsoft terbuka.

    Cuplikan layar tombol kirim log pada runtime integrasi yang dihost sendiri (SHIR) untuk mengunggah log ke Microsoft.

  5. Pilih log mana yang ingin Anda kirim.

    • Untuk IR yang dihost sendiri, Anda dapat mengunggah log yang berkaitan dengan aktivitas yang gagal atau semua log pada node IR yang dihost sendiri.
    • Untuk IR berbagi, Anda hanya dapat mengunggah log yang berkaitan dengan aktivitas yang gagal.

  6. Saat log diunggah, simpan rekaman ID Laporan untuk digunakan nanti jika Anda memerlukan bantuan lebih lanjut untuk menyelesaikan masalah.

    Cuplikan layar ID laporan yang ditampilkan di jendela kemajuan unggahan untuk log Purview SHIR.

Catatan

Permintaan melihat dan mengunggah log dijalankan pada semua instans IR yang dihost sendiri secara online. Jika ada log yang hilang, pastikan bahwa semua instans IR yang dihost sendiri sedang online.

Kegagalan atau kesalahan umum IR yang di-host sendiri

Masalah kehabisan memori

  • Gejala

    Kesalahan OutOfMemoryException (OOM) terjadi ketika Anda mencoba menjalankan aktivitas pencarian dengan runtime integrasi yang ditautkan atau IR yang dihost sendiri.

  • Penyebab

    Aktivitas baru dapat memunculkan kesalahan OOM jika komputer IR mengalami penggunaan memori tinggi sesaat. Masalah ini mungkin disebabkan oleh volume besar aktivitas bersamaan, dan kesalahannya adalah dengan sengaja.

  • Resolusi

    Periksa penggunaan sumber daya dan eksekusi aktivitas bersamaan pada node runtime integrasi. Sesuaikan waktu internal dan waktu pemicu eksekusi aktivitas untuk menghindari terlalu banyak eksekusi pada satu node runtime integrasi di waktu yang bersamaan.

Masalah batas pekerjaan bersamaan

  • Gejala

    Saat Anda mencoba meningkatkan batas pekerjaan bersamaan dari antarmuka pengguna, prosesnya macet dalam status Memperbarui.

    Contoh skenario: Nilai maksimum pekerjaan bersamaan saat ini diatur ke 24, dan Anda ingin meningkatkan hitungannya agar pekerjaan Anda dapat berjalan lebih cepat. Nilai minimum yang bisa Anda masukkan adalah 3, dan nilai maksimum yang bisa Anda masukkan adalah 32. Tingkatkan nilai dari 24 ke 32, lalu pilih tombol Perbarui. Prosesnya berhenti dalam status Memperbarui, seperti yang ditunjukkan pada cuplikan layar berikut. Anda merefresh halaman, dan nilainya masih ditampilkan sebagai 24. Nilai ini belum diperbarui ke 32 seperti yang diharapkan.

    Cuplikan layar panel Simpul dari runtime integrasi, menampilkan proses yang macet di

  • Penyebab

    Batas jumlah pekerjaan bersamaan tergantung pada core logis dan memori komputer. Cobalah untuk menyesuaikan nilai dengan menurunkannya, misalnya ke nilai 24, lalu lihat hasilnya.

    Tip

Masalah sertifikat SSL ketersediaan tinggi (high availability/HA) dari IR yang dihost sendiri

  • Gejala

    Node kerja IR yang dihost sendiri telah melaporkan kesalahan di bawah ini:

    "Gagal menarik status berbagi dari node primer net.tcp://abc.cloud.corp.Microsoft.com:8060/ExternalService.svc/. ID Aktivitas: XXXXX Sertifikat X.509 CN=abc.cloud.corp.Microsoft.com, OU=test, O=Microsoft chain building gagal. Sertifikat yang digunakan memiliki rantai kepercayaan yang tak bisa diverifikasi. Ganti sertifikat atau ubah certificateValidationMode. Fungsi pencabutan tidak dapat memeriksa pencabutan karena server pencabutan sedang offline.”

  • Penyebab

    Ketika menangani kasus yang terkait dengan handshake SSL/TLS, Anda mungkin mengalami beberapa masalah yang terkait dengan verifikasi rantai sertifikat.

  • Resolusi

    • Berikut adalah cara cepat dan intuitif untuk memecahkan masalah kegagalan build rantai sertifikat X.509:

      1. Mengekspor sertifikat, ini perlu diverifikasi. Untuk melakukannya, lakukan hal berikut:

        a. Di Windows, pilih Mulai, lalu ketikkan sertifikat, dan pilih Kelola sertifikat komputer.

        b. Di File Explorer, di panel sebelah kiri, cari sertifikat yang ingin Anda periksa, klik kanan sertifikat, lalu pilih Semua tugas>Ekspor.

        Cuplikan layar

      2. Salin sertifikat yang diekspor ke komputer klien.

      3. Di sisi klien, di jendela Wantian Perintah, jalankan perintah berikut ini. Pastikan untuk mengganti <jalur sertifikat> dan <jalur file txt keluaran> dengan jalur yang sebenarnya.

        Certutil -verify -urlfetch    <certificate path>   >     <output txt file path>

        Contohnya:

        Certutil -verify -urlfetch c:\users\test\desktop\servercert02.cer > c:\users\test\desktop\Certinfo.txt

      4. Periksa kesalahan dalam file TXT output. Anda dapat menemukan ringkasan kesalahan di akhir file TXT.

        Contohnya:

        Cuplikan layar ringkasan kesalahan di akhir file TXT.

        Jika Anda tidak melihat kesalahan di akhir file log, seperti yang ditunjukkan pada cuplikan layar berikut, Anda dapat mempertimbangkan bahwa rantai sertifikat telah berhasil dibuat pada komputer klien.

        Cuplikan layar file log yang memperlihatkan bahwa tidak ada kesalahan.

    • Jika ekstensi nama file AIA (Authority Information Access), CDP (CRL Distribution Point), atau OCSP (Online Certificate Status Protocol) dikonfigurasi dalam file sertifikat, Anda dapat memeriksanya dengan cara yang lebih intuitif:

      1. Dapatkan informasi ini dengan memeriksa detail sertifikat, seperti yang ditunjukkan dalam cuplikan layar berikut:

        Cuplikan layar detail sertifikat.

      2. Jalankan perintah berikut. Pastikan untuk mengganti <jalur sertifikat> dengan jalur sertifikat yang sebenarnya.

          Certutil   -URL    <certificate path>

        Alat Pengambilan URL terbuka.

      3. Untuk memverifikasi sertifikat dengan ekstensi nama file AIA, CDP, dan OCSP, pilih Ambil.

        Cuplikan layar Alat Pengambilan URL dan tombol Ambil.

        Rantai sertifikat berhasil dibuat jika status sertifikat dari AIA Diverifikasi dan status sertifikat dari CDP atau OCSP Diverifikasi.

        Jika Anda gagal saat mencoba mengambil AIA atau CDP, minta bantuan tim jaringan Anda dalam menyiapkan komputer klien untuk menyambung ke URL target. Hal ini akan cukup jika jalur HTTP atau jalur Lightweight Directory Access Protocol (LDAP) dapat diverifikasi.

IR yang di-host sendiri tidak dapat memuat berkas atau perakitan

  • Gejala

    Anda mendapatkan pesan kesalahan berikut:

    "Tidak dapat memuat file atau assembly 'XXXXXXXXXXXXXXXX, Version=4.0.2.0, Culture=neutral, PublicKeyToken=XXXXXXXXX' atau salah satu dependensinya. Sistem tidak dapat menemukan file yang ditentukan. Activity ID: 92693b45-b4bf-4fc8-89da-2d3dc56f27c3"

    Berikut adalah pesan kesalahan yang lebih spesifik:

    "Tidak dapat memuat file atau assembly 'System.ValueTuple, Version=4.0.2.0, Culture=neutral, PublicKeyToken=XXXXXXXXX' atau salah satu dependensinya. Sistem tidak dapat menemukan file yang ditentukan. Activity ID: 92693b45-b4bf-4fc8-89da-2d3dc56f27c3"

  • Penyebab

    Dalam Pemantauan Proses, Anda bisa melihat hasil berikut:

    Cuplikan layar daftar Jalur di Monitor Proses.

    Tip

    Di Pemantauan Proses, Anda dapat mengatur filter seperti yang ditunjukkan dalam cuplikan layar berikut.

    Pesan kesalahan sebelumnya menyatakan bahwa System.ValueTuple DLL tidak terletak di folder Global Assembly Cache (GAC) terkait, di folder C:\Program Files\Microsoft Integration Runtime\4.0\Gateway, atau di folder C:\Program Files\Microsoft Integration Runtime\4.0\Shared.

    Pada dasarnya, proses memuat DLL terlebih dahulu dari folder GAC, lalu dari folder Shared, dan terakhir dari folder Gateway. Maka dari itu, Anda dapat memuat DLL dari segala jalur yang memungkinkan.

    Cuplikan layar

  • Resolusi

    Anda akan menemukan file System.ValueTuple.dll di folder C:\Program Files\Microsoft Integration Runtime\4.0\Gateway\DataScan. Untuk mengatasi masalah ini, salin file System.ValueTuple.dll ke folder C:\Program Files\Microsoft Integration Runtime\4.0\Gateway.

    Anda dapat menggunakan metode yang sama untuk menyelesaikan masalah hilangnya file atau perakitan lain.

  • Informasi selengkapnya tentang masalah ini

    Alasan mengapa Anda melihat System.ValueTuple.dll di bawah %windir%\Microsoft.NET\assembly dan %windir%\assembly adalah karena ini adalah perilaku .NET.

    Dalam kesalahan berikut, Anda dapat dengan jelas melihat bahwa assembly System.ValueTuple hilang. Masalah ini muncul ketika aplikasi mencoba memeriksa assembly System.ValueTuple.dll.

    "<LogProperties><ErrorInfo>[{"Code":0,"Message":"The type initializer for 'Npgsql.PoolManager' threw an exception.","EventType":0,"Category":5,"Data":{},"MsgId":null,"ExceptionType":"System.TypeInitializationException","Source":"Npgsql","StackTrace":"","InnerEventInfos":[{"Code":0,"Message":"Could not load file or assembly 'System.ValueTuple, Version=4.0.2.0, Culture=neutral, PublicKeyToken=XXXXXXXXX' or one of its dependencies. Sistem tidak dapat menemukan file yang ditentukan.","EventType":0,"Category":5,"Data":{},"MsgId":null,"ExceptionType":"System.IO.FileNotFoundException","Sumber ":"Npgsql","StackTrace":"","InnerEventInfos":[]}]}]</ErrorInfo></LogProperties>"

    Untuk informasi selengkapnya tentang GAC, lihat Singgahan Perakitan Global.

Kunci Autentikasi runtime integrasi yang dihost sendiri hilang

  • Gejala

    Runtime integrasi yang dihost sendiri tiba-tiba offline tanpa Kunci Autentikasi, dan Log Kejadian menampilkan pesan kesalahan berikut:

    "Kunci Autentikasi belum ditetapkan"

    Cuplikan layar panel kejadian runtime integrasi memperlihatkan bahwa Kunci Autentikasi belum ditetapkan.

  • Penyebab

    • Node IR yang dihost sendiri atau IR yang dihost sendiri secara logis di portal Microsoft Azure dihapus.
    • Penghapusan instalan secarfa menyeluruh dilakukan.

  • Resolusi

    Jika tidak ada penyebab sebelumnya yang berlaku, Anda dapat membuka folder %programdata%\Microsoft\Data Transfer\DataManagementGateway untuk melihat apakah file Konfigurasi telah dihapus. Jika file tersebut telah dihapus, ikuti petunjuk di artikel Netwrix: Mendeteksi siapa yang menghapus file dari server file Windows Anda.

    Cuplikan layar panel detail log kejadian untuk memeriksa file Konfigurasi.

Tidak dapat menggunakan IR yang dihost sendiri untuk menghubungkan dua penyimpanan data lokal

  • Gejala

    Setelah membuat IR yang dihost sendiri untuk penyimpanan data sumber dan tujuan, Anda ingin menyambungkan kedua runtime integrasi untuk menyelesaikan aktivitas salin. Jika penyimpanan data dikonfigurasi di jaringan virtual yang berbeda, atau penyimpanan data tidak dapat memahami mekanisme gateway, Anda akan menerima salah satu kesalahan berikut:

    • "Driver sumber data tidak dapat ditemukan di runtime integrasi tujuan”
    • "Sumber tidak dapat diakses oleh runtime integrasi tujuan"

  • Penyebab

    IR yang dihost sendiri dirancang sebagai node pusat aktivitas salin, bukan agen klien yang perlu dipasang untuk tiap-tiap penyimpanan data.

    Dalam kasus ini, Anda harus membuat layanan tertaut untuk setiap penyimpanan data dengan runtime integrasi yang sama, dan runtime integrasi itu harus dapat mengakses kedua penyimpanan data melalui jaringan. Tidak masalah apakah runtime integrasi dipasang di penyimpanan data sumber atau penyimpanan data tujuan, atau di komputer ketiga. Jika dua layanan tertaut dibuat dengan runtime integrasi yang berbeda tetapi digunakan dalam aktivitas salin yang sama, runtime integrasi tujuan akan digunakan, dan Anda perlu memasang driver untuk kedua penyimpanan data pada komputer runtime integrasi tujuan.

  • Resolusi

    Pasang driver untuk penyimpanan data sumber dan tujuan di runtime integrasi tujuan, dan pastikan ia dapat mengakses penyimpanan data sumber.

    Jika lalu lintas tidak dapat melewati jaringan di antara dua penyimpanan data (misalnya, lalu lintas dikonfigurasi dalam dua jaringan virtual), Anda mungkin tidak dapat menyelesaikan penyalinan dalam satu aktivitas meskipun runtime integrasi sudah terpasang. Jika Anda tidak dapat menyelesaikan penyalinan dalam satu aktivitas, Anda dapat membuat dua aktivitas salin dengan dua runtime integrasi, masing-masing dalam VENT:

    • Menyalin satu runtime integrasi dari penyimpanan data 1 ke Azure Blob Storage
    • Salin runtime integrasi lain dari Azure Blob Storage ke penyimpanan data 2.

    Solusi ini dapat menyimulasikan persyaratan untuk menggunakan runtime integrasi guna membuat jembatan yang menghubungkan dua penyimpanan data yang tidak terhubung.

Masalah sinkronisasi kredensial menyebabkan kredensial hilang dari ketersediaan tinggi

  • Gejala

    Jika kredensial sumber data "XXXXXXXXXX" dihapus dari node runtime integrasi saat ini dengan payload, Anda akan menerima pesan kesalahan berikut:

    "Saat Anda menghapus layanan tautan di portal Microsoft Azure, atau tugas tersebut memiliki payload yang salah, buat layanan tautan baru dengan kredensial Anda lagi."

  • Penyebab

    IR yang dihost sendiri dibangun dalam mode ketersediaan tinggi dengan dua node, tetapi node tersebut tidak dalam status sinkronisasi kredensial. Ini berarti bahwa kredensial yang disimpan dalam node pengirim tidak disinkronkan ke node pekerja lain. Jika ada kegagalan yang terjadi dari node pengirim ke node pekerja, dan kredensial hanya ada di node pengirim sebelumnya, tugas akan gagal ketika Anda mencoba mengakses kredensial, dan Anda akan menerima kesalahan sebelumnya.

  • Resolusi

    Satu-satunya cara untuk menghindari masalah ini adalah dengan memastikan bahwa kedua node ada dalam status sinkronisasi kredensial. Jika mereka tidak sinkron, Anda harus memasukkan kredensial kembali untuk pengirim yang baru.

Tidak dapat memilih sertifikat karena kunci privat hilang

  • Gejala

    • Anda telah mengimpor file PFX ke penyimpanan sertifikat.

    • Ketika Anda memilih sertifikat melalui antarmuka pengguna Configuration Manager runtime integrasi, Anda menerima pesan kesalahan berikut:

      "Gagal mengubah mode enkripsi komunikasi intranet. Kemungkinan sertifikat '<nama sertifikat>' mungkin tidak memiliki kunci privat yang mampu melakukan pertukaran kunci atau prosesnya mungkin tidak memiliki hak akses untuk kunci privat tersebut. Lihat pengecualian dalam untuk detailnya."

      Cuplikan layar panel Pengaturan Manajer Konfigurasi Integration Runtime, menampilkan

  • Penyebab

    • Akun pengguna memiliki tingkat izin yang rendah dan tidak dapat mengakses kunci privat.
    • Sertifikat dibuat sebagai tanda tangan tetapi bukan sebagai penukaran kunci.

  • Resolusi

    • Untuk mengoperasikan antarmuka pengguna, gunakan akun dengan izin yang sesuai untuk mengakses kunci privat.

    • Impor sertifikat dengan menjalankan perintah berikut ini:

      certutil -importpfx FILENAME.pfx AT_KEYEXCHANGE

Simpul runtime integrasi yang dihost sendiri di luar masalah sinkronisasi

  • Gejala

    Simpul runtime integrasi yang dihost sendiri mencoba menyinkronkan kredensial di seluruh simpul tetapi terjebak dalam proses dan menemukan pesan kesalahan di bawah ini setelah beberapa saat:

    "Simpul Integration Runtime (yang dihost sendiri) mencoba menyinkronkan kredensial di seluruh simpul. Hal ini mungkin perlu beberapa menit."

    Catatan

    Jika kesalahan ini muncul selama lebih dari 10 menit, periksa konektivitas dengan simpul dispatcher.

  • Penyebab

    Alasannya adalah bahwa simpul pekerja tidak memiliki akses ke kunci pribadi. Ini dapat dikonfirmasi dari log runtime integrasi yang dihost sendiri di bawah ini:

    [14]0460.3404::05/07/21-00:23:32.2107988 [System] A fatal error occurred when attempting to access the TLS server credential private key. The error code returned from the cryptographic module is 0x8009030D. The internal error state is 10001.

    Anda tidak memiliki masalah pada proses sinkronisasi saat menggunakan autentikasi perwakilan layanan di layanan tertaut. Namun, ketika Anda mengalihkan jenis autentikasi ke kunci akun, masalah sinkronisasi dimulai. Ini karena layanan runtime integrasi yang dihost sendiri berjalan di bawah akun layanan (NT SERVICE\DIAHostService) dan perlu ditambahkan ke izin kunci pribadi.

  • Resolusi

    Untuk mengatasi masalah ini, Anda perlu menambahkan akun layanan runtime integrasi yang dihosting sendiri (NT SERVICE\DIAHostService) ke izin kunci pribadi. Anda dapat menerapkan langkah-langkah berikut:

    1. Buka Perintah Jalankan Microsoft Management Console (MMC).

      Cuplikan layar yang memperlihatkan Perintah Jalankan MMC

    2. Di panel MMC, terapkan langkah-langkah berikut:

      Cuplikan layar yang memperlihatkan langkah kedua untuk menambahkan akun layanan IR yang dihost sendiri ke izin kunci pribadi.

      1. Pilih File.
      2. Pilih Tambahkan/Hapus Snap-in di menu drop-down.
      3. Pilih Sertifikat di panel "Snap-in yang tersedia".
      4. Pilih Tambahkan.
      5. Di panel pop-up "Snap-in sertifikat", pilih Akun komputer.
      6. Pilih Selanjutnya.
      7. Di panel "Pilih Komputer", pilih Komputer lokal: komputer yang menjalankan konsol ini.
      8. Pilih Selesai.
      9. Pilih OK di panel "Tambahkan atau Hapus Snap-in".

    3. Di panel MMC, lanjutkan dengan langkah-langkah berikut ini:

      Cuplikan layar yang menunjukkan langkah ketiga untuk menambahkan akun layanan IR yang dihost sendiri ke izin kunci pribadi.

      1. Dari daftar folder sebelah kiri, pilih Akar Konsol -> Sertifikat (Komputer Lokal) -> Pribadi -> Sertifikat.
      2. Klik kanan Microsoft Intune Beta MDM.
      3. Pilih Semua Tugas di daftar drop-down.
      4. Pilih Kelola Kunci Privat.
      5. Pilih Tambahkan di bagian "Nama grup atau pengguna".
      6. Pilih NT SERVICE\DIAHostService untuk memberikannya akses kontrol penuh ke sertifikat ini, berlaku dan aman.
      7. Pilih Periksa Nama lalu pilih OK.
      8. Di panel "Izin", pilih Terapkan lalu pilih OK.

Pesan kesalahan UserErrorJreNotFound saat Anda menjalankan aktivitas penyalinan ke Azure

  • Gejala

    Saat Anda mencoba menyalin konten ke Microsoft Azure dengan menggunakan alat atau program berbasis Java (misalnya, menyalin file format ORC atau Parquet), Anda menerima pesan kesalahan yang seperti berikut ini:

    ErrorCode=UserErrorJreNotFound,'Type=Microsoft.DataTransfer.Common.Shared.HybridDeliveryException,Message=Java Runtime Environment tidak ditemukan. Buka http://go.microsoft.com/fwlink/?LinkId=808605 untuk mengunduh dan menginstal di mesin node Integrasi Runtime (Dihosting sendiri). Perlu dicatat bahwa Runtime Integrasi 64-bit memerlukan JRE 64-bit dan Runtime Integrasi 32-bit memerlukan JRE 32-bit.,Source=Microsoft.DataTransfer.Common,''Type=System.DllNotFoundException,Message=Unable to load DLL 'jvm.dll': Modul yang ditentukan tidak dapat ditemukan. (Pengecualian dari HRESULT: 0x8007007E),Sumber=Microsoft.DataTransfer.Richfile.HiveOrcBridge

  • Penyebab

    Masalah ini terjadi karena salah satu dari alasan berikut:

    • Java Runtime Environment (JRE) tidak diinstal dengan benar di server Integration Runtime Anda.

    • Server Integration Runtime Anda tidak memiliki dependensi yang diperlukan untuk JRE.

    Secara default, Integration Runtime menyelesaikan jalur JRE dengan menggunakan entri registri. Entri tersebut harus diatur secara otomatis selama penginstalan JRE.

  • Resolusi

    Ikuti langkah-langkah di bagian ini dengan seksama. Masalah serius dapat terjadi jika Anda mengubah registri dengan salah. Sebelum Anda mengubah registri, cadangkan registri untuk pemulihan jika terjadi masalah.

    Untuk memperbaiki masalah ini, ikuti langkah-langkah berikut untuk memverifikasi status penginstalan JRE:

    1. Pastikan bahwa Integration Runtime (Diahost.exe) dan JRE diinstal pada platform yang sama. Periksa kondisi berikut:

      • JRE 64-bit untuk Integration Runtime ADF 64-bit harus diinstal di folder: C:\Program Files\Java\

        Catatan

        Folder bukan C:\Program Files (x86)\Java\

      • Java Runtime (JRE) adalah versi 11 atau lebih tinggi, dari penyedia JRE seperti Microsoft OpenJDK 11 atau Eclipse Temurin 11. Pastikan bahwa variabel lingkungan sistem JAVA_HOME diatur ke folder JDK (bukan hanya folder JRE) Anda mungkin juga perlu menambahkan folder bin ke variabel lingkungan PATH sistem Anda.

    2. Periksa registri untuk pengaturan yang sesuai. Untuk melakukan ini, ikuti langkah-langkah berikut:

      1. Di menu Jalankan, ketik Regedit, lalu tekan Enter.

      2. Di panel navigasi, temukan subkunci berikut ini:

        HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment.

        Di panel Detail, harus ada entri Versi Saat Ini yang menunjukkan versi JRE (misalnya, 1.8).

        Cuplikan layar yang menunjukkan Java Runtime Environment.

      3. Di panel navigasi, temukan subkunci yang sama persis dengan versi (misalnya 1.8) di bawah folder JRE. Di panel detail, seharusnya ada entri JavaHome. Nilai entri ini adalah jalur penginstalan JRE.

        Cuplikan layar yang menunjukkan entri JavaHome.

    3. Temukan folder bin\server di jalur berikut ini:

      C:\Program Files\Java\jre1.8.0_74

      Cuplikan layar yang menunjukkan folder JRE.

    4. Periksa apakah folder ini berisi file jvm.dll. Jika tidak, periksa file di folder bin\client.

      Cuplikan layar yang menunjukkan lokasi file jvm.dll.

    Catatan

    • Jika salah satu dari konfigurasi ini tidak seperti yang dijelaskan dalam langkah-langkah ini, gunakan alat penginstal jendela JRE untuk memperbaiki masalah.
    • Jika semua konfigurasi dalam langkah-langkah ini benar seperti yang dijelaskan, mungkin ada pustaka runtime VC++ yang hilang dalam sistem. Anda dapat memperbaiki masalah ini dengan menginstal VC++ 2010 Redistributable Package.

Penyetelan IR yang dihost sendiri

Kesalahan pendaftaran runtime integrasi

  • Gejala

    Mungkin terkadang Anda ingin menjalankan IR yang dihost sendiri di akun berbeda karena salah satu alasan berikut:

    • Kebijakan perusahaan melarang akun layanan.
    • Beberapa autentikasi diperlukan.

    Setelah Anda mengubah akun layanan di panel layanan, runtime integrasi mungkin berhenti berfungsi, dan Anda mendapatkan pesan kesalahan berikut:

    "Node Integration Runtime (Self-hosted) mengalami kesalahan saat pendaftaran. Tidak dapat tersambung ke Layanan Host Integration Runtime (Self-hosted).”

    Cuplikan layar jendela Configuration Manager Integration Runtime, memperlihatkan kesalahan pendaftaran runtime integrasi.

  • Penyebab

    Banyak sumber daya yang hanya diperbolehkan ke akun layanan tersebut. Saat Anda mengubah akun layanan ke akun lain, semua izin sumber daya dependen tetap tidak berubah.

  • Resolusi

    Buka log kejadian runtime integrasi untuk memeriksa kesalahan.

    Cuplikan layar log kejadian runtime integrasi, memperlihatkan bahwa telah terjadi kesalahan runtime.

    • Jika kesalahan dalam log kejadian adalah "UnauthorizedAccessException," lakukan hal berikut:

      1. Periksa akun layanan masuk DIAHostService di panel layanan Windows.

        Cuplikan layar panel properti akun layanan Masuk.

      2. Periksa untuk melihat apakah akun layanan masuk memiliki izin membaca/menulis untuk folder %programdata%\Microsoft\DataTransfer\DataManagementGateway.

        • Secara default, jika akun masuk layanan belum diubah, ia seharusnya memiliki izin membaca/menulis.

          Cuplikan layar panel izin layanan.

        • Jika Anda telah mengubah akun masuk layanan, perbaiki masalah dengan melakukan hal berikut:

          a. Hapus secara menyeluruh instalan IR yang dihost sendiri saat ini.
          b. Pasang bit IR yang dihost sendiri.
          c. Ubah akun layanan dengan melakukan hal berikut:

          i. Buka folder instalasi IR yang dihost sendiri, lalu beralih ke folder Microsoft Integration Runtime\4.0\Shared.
          ii. Buka jendela Wantian Perintah dengan menggunakan izin yang ditingkatkan. Ganti <pengguna> dan <kata sandi> dengan nama pengguna dan kata sandi Anda sendiri, lalu jalankan perintah berikut:
          dmgcmd.exe -SwitchServiceAccount "<user>" "<password>"
          iii. Jika Anda ingin mengubah ke akun LocalSystem, pastikan untuk menggunakan format yang tepat untuk akun ini: dmgcmd.exe -SwitchServiceAccount "NT Authority\System" ""
          Jangan gunakan format ini: dmgcmd.exe -SwitchServiceAccount "LocalSystem" ""
          iv. Secara opsional, karena Sistem Lokal memiliki izin yang lebih tinggi daripada Admin, Anda juga dapat langsung mengubahnya di "Layanan".
          v. Anda dapat menggunakan pengguna lokal/domain untuk akun masuk layanan runtime integrasi.

          d. Daftarkan runtime integrasi.

    • Jika kesalahannya adalah "Layanan 'Layanan Integration Runtime' (DIAHostService) gagal dimulai. Verifikasi bahwa Anda memiliki izin yang mencukupi untuk memulai layanan sistem", lakukan hal berikut:

      1. Periksa akun layanan masuk DIAHostService di panel layanan Windows.

        Cuplikan layar

      2. Periksa apakah akun layanan masuk memiliki izin Masuk sebagai layanan untuk memulai layanan Windows:

        Cuplikan layar

  • Informasi selengkapnya

    Jika tidak ada satu pun dari dua pola resolusi sebelumnya yang berlaku untuk kasus Anda, cobalah untuk mengumpulkan log kejadian Windows berikut ini:

    • Log Aplikasi dan Layanan > Integration Runtime
    • Log Windows > Aplikasi

Tidak dapat menemukan tombol Daftar untuk mendaftarkan IR yang dihost sendiri

  • Gejala

    Saat Anda mendaftarkan IR yang dihost sendiri, tombol Daftar tidak ditampilkan di panel Configuration Manager.

    Cuplikan layar panel Configuration Manager menampilkan pesan bahwa node runtime integrasi tidak terdaftar.

  • Penyebab

    Pada rilis Integration Runtime 3.0, tombol Daftar di node runtime integrasi yang ada telah dihapus untuk memungkinkan lingkungan yang lebih bersih dan lebih aman. Jika suatu node telah didaftarkan ke runtime integrasi, baik online atau tidak, daftarkan kembali ke runtime integrasi lain dengan mencopot node sebelumnya, lalu pasang dan daftarkan node tersebut.

  • Resolusi

    1. Di Panel Kontrol, hapus instalan runtime integrasi yang ada.

      Penting

      Dalam proses berikutnya, pilih Ya. Jangan menyimpan data saat proses pencopotan.

      Cuplikan layar

    2. Jika Anda tidak memiliki file MSI penginstal runtime integrasi, buka pusat unduhan untuk mengunduh runtime integrasi terbaru.

    3. Pasang file MSI, dan daftarkan runtime integrasi.

Tidak dapat mendaftarkan IR yang dihost sendiri karena localhost

  • Gejala

    Anda tidak dapat mendaftarkan IR yang dihost sendiri pada komputer baru saat Anda menggunakan get_LoopbackIpOrName.

    Debug: Kesalahan runtime baru saja terjadi. Penginisialisasi jenis untuk 'Microsoft.DataTransfer.DIAgentHost.DataSourceCache' mengembalikan pengecualian. Terjadi kesalahan yang tidak dapat dipulihkan saat pencarian database.

    Detail pengecualian: System.TypeInitializationException: Jenis penginisialisasi untuk 'Microsoft.DataTransfer.DIAgentHost.DataSourceCache' memunculkan pengecualian. ---> System.Net.Sockets.SocketException: A non-recoverable error occurred during a database lookup at System.Net.Dns.GetAddrInfo(String name).

  • Penyebab

    Masalah ini biasanya terjadi ketika localhost sedang diperbaiki.

  • Resolusi

    Gunakan alamat IP localhost 127.0.0.1 untuk menghosting file dan menyelesaikan masalah.

Penyetelan IR yang dihost sendiri gagal

  • Gejala

    Anda tidak dapat mencopot runtime integrasi yang ada, memasang runtime integrasi baru, atau meningkatkan runtime integrasi yang ada ke runtime integrasi baru.

  • Penyebab

    Penginstalan runtime integrasi bergantung pada layanan Pemasang Windows. Anda mungkin mengalami masalah penginstalan karena alasan berikut:

    • Ruang disk yang tersedia tidak cukup.
    • Kurangnya izin.
    • Layanan Windows NT terkunci.
    • Penggunaan CPU terlalu tinggi.
    • File MSI dihosting di lokasi jaringan yang lambat.
    • Beberapa file atau registri sistem disentuh secara tidak sengaja.

Akun layanan runtime integrasi gagal mengambil akses sertifikat

  • Gejala

    Saat Anda memasang IR yang dihost sendiri melalui Configuration Manager Microsoft Integration Runtime, sertifikat dengan otoritas sertifikat (OS) tepercaya dibuat. Sertifikat tidak dapat diterapkan untuk mengenkripsi komunikasi antara dua node, dan pesan kesalahan berikut akan ditampilkan:

    "Gagal mengubah mode enkripsi komunikasi Intranet: Gagal memberi akun layanan Integration Runtime akses ke sertifikat '<nama sertifikat>'. Kode Kesalahan 103”

    Cuplikan layar menampilkan pesan kesalahan

  • Penyebab

    Sertifikat ini menggunakan penyimpanan penyedia penyimpanan kunci (Key Storage Provider/KSP) yang belum didukung. Hingga saat ini, IR yang dihost sendiri hanya mendukung penyimpanan penyedia layanan kriptografi (cryptographic service provider/CSP).

  • Resolusi

    Sebaiknya Anda menggunakan sertifikat CSP dalam kasus ini.

    Solusi 1

    Untuk mengimpor sertifikat, jalankan perintah berikut:

    Certutil.exe -CSP "CSP or KSP" -ImportPFX FILENAME.pfx

    Cuplikan layar perintah certutil untuk mengimpor sertifikat.

    Solusi 2

    Untuk mengonversi sertifikat, jalankan perintah berikut:

    openssl pkcs12 -in .\xxxx.pfx -out .\xxxx_new.pem -password pass: <EnterPassword> openssl pkcs12 -export -in .\xxxx_new.pem -out xxxx_new.pfx

    Sebelum dan sesudah konversi:

    Cuplikan layar dari hasil sebelum konversi sertifikat.

    Cuplikan layar dari hasil setelah konversi sertifikat.

IR yang dihost sendiri versi 5.x

Untuk meningkatkan versi ke versi 5.x dari runtime integrasi yang dihost sendiri, kami memerlukan .NET Framework Runtime 4.7.2 atau yang lebih baru. Pada halaman unduhan, Anda akan menemukan tautan pengunduhan untuk versi 4.x terbaru dan dua versi 5.x terbaru.

Untuk pelanggan Azure Data Factory v2 dan Azure Synapse:

  • Jika pembaruan otomatis aktif dan Anda telah meningkatkan .NET Framework Runtime Anda ke 4.7.2 atau yang lebih baru, runtime integrasi yang dihost sendiri akan secara otomatis ditingkatkan ke versi 5.x terbaru.
  • Jika pembaruan otomatis aktif dan Anda belum meningkatkan .NET Framework Runtime Anda ke 4.7.2 atau yang lebih baru, runtime integrasi yang dihost sendiri tidak akan ditingkatkan ke versi 5.x terbaru secara otomatis. IR yang dihost sendiri akan tetap berada dalam versi 4.x yang sekarang ini. Anda dapat melihat peringatan untuk meningkatkan .NET Framework Runtime di portal dan di klien runtime integrasi yang dihost sendiri.
  • Jika pembaruan otomatis nonaktif dan Anda telah meningkatkan .NET Framework Runtime ke 4.7.2 atau yang lebih baru, Anda dapat mengunduh versi 5.x terbaru secara manual dan memasangnya di komputer Anda.
  • Jika pembaruan otomatis nonaktif dan Anda belum meningkatkan .NET Framework Runtime ke 4.7.2 atau yang lebih baru. Saat Anda mencoba memasang runtime integrasi yang dihost sendiri versi 5.x secara manual dan mendaftarkan kuncinya, Anda akan diminta untuk meningkatkan versi .NET Framework Runtime Anda terlebih dahulu.

Masalah konektivitas IR yang dihost sendiri

Runtime integrasi yang dihost sendiri tidak dapat tersambung ke layanan cloud

  • Gejala

    Ketika Anda mencoba mendaftarkan runtime integrasi yang dihost sendiri, Configuration Manager menampilkan pesan kesalahan berikut:

    "Node Integration Runtime (Self-hosted) mengalami kesalahan saat pendaftaran.”

    Cuplikan layar

  • Penyebab

    IR yang dihost sendiri tidak dapat tersambung ke layanan back end. Masalah ini biasanya disebabkan oleh pengaturan jaringan di firewall.

  • Resolusi

    1. Periksa untuk melihat apakah layanan runtime integrasi berjalan. Jika ya, lanjutkan ke langkah 2.

      Cuplikan layar memperlihatkan bahwa layanan IR yang dihost sendiri sedang berjalan.

    2. Jika tidak ada proksi yang dikonfigurasi pada IR yang dihost sendiri, yang merupakan pengaturan default, jalankan perintah PowerShell berikut pada komputer tempat runtime integrasi yang dihost sendiri dipasang:

      (New-Object System.Net.WebClient).DownloadString("https://wu2.frontend.clouddatahub.net/")

      Catatan

      URL layanan mungkin berbeda-beda, tergantung lokasi pabrik data Anda atau instans ruang kerja Synapse. Untuk menemukan URL layanan, gunakan halaman Kelola antarmuka pengguna di pabrik data Anda atau instans Azure Synapse untuk menemukan Runtime integrasi dan klik IR yang dihost sendiri untuk mengeditnya. Di sana, pilih tab Simpul dan klik Lihat URL Layanan.

      Berikut ini adalah perkiraan respons:

      Cuplikan layar respons perintah PowerShell.

    3. Jika Anda tidak menerima respons yang diharapkan, gunakan salah satu metode berikut, sebagaimana mestinya:

      • Jika Anda menerima pesan "Nama jarak jauh tidak dapat diselesaikan", ada masalah Sistem Nama Domain (Domain Name System/DNS). Hubungi tim jaringan Anda untuk memperbaiki masalah tersebut.
      • Jika Anda menerima pesan "sertifikasi ssl/tls tidak tepercaya", periksa sertifikat (https://wu2.frontend.clouddatahub.net/) untuk melihat apakah sertifikat tepercaya pada mesin, lalu instal sertifikat publik dengan menggunakan Pengelola Sertifikat. Tindakan ini akan mengurangi masalah.
      • Buka Windows>Pemantau peristiwa (log)>Log Aplikasi dan Layanan>Integration Runtime, dan periksa segala kegagalan yang disebabkan oleh DNS, aturan firewall, atau pengaturan jaringan perusahaan. Jika Anda menemukan kegagalan seperti itu, tutup koneksi secara paksa. Karena setiap perusahaan memiliki pengaturan jaringan yang telah dikustomisasi, hubungi tim jaringan Anda untuk memecahkan masalah ini.

    4. Jika "proksi" telah dikonfigurasi pada runtime integrasi yang dihost sendiri, verifikasi bahwa server proksi Anda dapat mengakses titik akhir layanan. Untuk perintah sampel, lihat PowerShell, permintaan web, dan proksi.

      $user = $env:username
$webproxy = (get-itemproperty 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet
Settings').ProxyServer
$pwd = Read-Host "Password?" -assecurestring
$proxy = new-object System.Net.WebProxy
$proxy.Address = $webproxy
$account = new-object System.Net.NetworkCredential($user,[Runtime.InteropServices.Marshal]::PtrToStringAuto([Runtime.InteropServices.Marshal]::SecureStringToBSTR($pwd)), "")
$proxy.credentials = $account
$url = "https://wu2.frontend.clouddatahub.net/"
$wc = new-object system.net.WebClient
$wc.proxy = $proxy
$webpage = $wc.DownloadData($url)
$string = [System.Text.Encoding]::ASCII.GetString($webpage)
$string

    Berikut ini adalah perkiraan respons:

    Cuplikan layar dari respons perintah PowerShell yang diharapkan.

    Catatan

    Pertimbangan proksi:

    • Periksa untuk melihat apakah server proksi perlu dimasukkan ke dalam daftar Penerima Aman. Jika demikian, pastikan domain-domain ini ada di daftar Penerima Aman.
    • Periksa untuk melihat apakah sertifikat wu2.frontend.clouddatahub.net/ SSL/TLS tepercaya di server proksi.
    • Jika Anda menggunakan autentikasi Direktori Aktif pada proksi, ubah akun layanan ke akun pengguna yang dapat mengakses proksi sebagai "Layanan Integration Runtime."

Pesan kesalahan: Node runtime integrasi yang dihost sendiri/IR yang dihost sendiri secara logis tidak aktif/ status "Berjalan (Terbatas)”

  • Penyebab

    Node runtime terintegrasi yang dihost sendiri mungkin memiliki status Tidak Aktif, seperti yang ditunjukkan pada cuplikan layar berikut:

    Cuplikan layar node runtime terintegrasi yang dihost sendiri dengan status tidak aktif

    Perilaku ini terjadi ketika node tidak dapat berkomunikasi dengan satu sama lain.

  • Resolusi

    1. Masuk ke komputer virtual yang dihosting node. Di Log Aplikasi dan Layanan>Integration Runtime, buka Pemantau Peristiwa, dan filter log kesalahan.

    2. Periksa untuk melihat apakah log kesalahan berisi kesalahan berikut:

      System.ServiceModel.EndpointNotFoundException: Could not connect to net.tcp://xxxxxxx.bwld.com:8060/ExternalService.svc/WorkerManager. The connection attempt lasted for a time span of 00:00:00.9940994. TCP error code 10061: No connection could be made because the target machine actively refused it 10.2.4.10:8060. 
System.Net.Sockets.SocketException: No connection could be made because the target machine actively refused it. 
10.2.4.10:8060
at System.Net.Sockets.Socket.DoConnect(EndPoint endPointSnapshot, SocketAddress socketAddress)
at System.Net.Sockets.Socket.Connect(EndPoint remoteEP)
at System.ServiceModel.Channels.SocketConnectionInitiator.Connect(Uri uri, TimeSpan timeout)

    3. Jika Anda melihat kesalahan ini, jalankan perintah berikut ini di jendela Wantian Perintah:

      telnet 10.2.4.10 8060

    4. Jika Anda menerima kesalahan baris perintah "Tidak dapat membuka koneksi ke host" yang ditampilkan dalam cuplikan layar berikut, hubungi departemen IT Anda untuk bantuan dalam memperbaiki masalah ini. Setelah berhasil melakukan telnet, hubungi Dukungan Microsoft jika Anda masih mengalami masalah dengan status node runtime integrasi.

      Cuplikan layar

    5. Periksa untuk melihat apakah log kesalahan berisi kesalahan berikut:

      Error log: Cannot connect to worker manager: net.tcp://xxxxxx:8060/ExternalService.svc/ No DNS entries exist for host azranlcir01r1. No such host is known Exception detail: System.ServiceModel.EndpointNotFoundException: No DNS entries exist for host xxxxx. ---> System.Net.Sockets.SocketException: No such host is known at System.Net.Dns.GetAddrInfo(String name) at System.Net.Dns.InternalGetHostByName(String hostName, Boolean includeIPv6) at System.Net.Dns.GetHostEntry(String hostNameOrAddress) at System.ServiceModel.Channels.DnsCache.Resolve(Uri uri) --- End of inner exception stack trace --- Server stack trace: at System.ServiceModel.Channels.DnsCache.Resolve(Uri uri)

    6. Untuk mengatasi masalah ini, cobalah salah satu atau kedua metode berikut:

      • Letakkan semua node di domain yang sama.
      • Tambahkan IP untuk menghosting pemetaan di semua file host komputer virtual yang dihosting.

Masalah konektivitas antara IR yang dihost sendiri dan pabrik data Anda atau instans Azure Synapse atau IR yang dihost sendiri dan sumber data atau sink

Untuk memecahkan masalah konektivitas jaringan, Anda harus tahu cara mengumpulkan jejak jaringan, memahami cara menggunakannya, dan menganalisis jejak Pemantauan Jaringan (Microsoft Network Monitor/Netmon) sebelum menerapkan Alat Netmon dalam kasus nyata dari IR yang dihost sendiri.

  • Gejala

    Terkadang Anda mungkin perlu memecahkan masalah konektivitas tertentu antara IR yang dihost sendiri dan pabrik data Anda atau instans Azure Synapse, seperti yang diperlihatkan dalam tangkapan layar berikut, atau antara IR yang dihost sendiri dan sumber data atau sink.

    Cuplikan layar

    Dalam kedua kasus tersebut, Anda mungkin menemui kesalahan berikut:

    • "Copy failed with error:Type=Microsoft.DataTransfer.Common.Shared.HybridDeliveryException,Message=Cannot connect to SQL Server: 'IP address'"

    • "Terjadi satu atau lebih kesalahan. Terjadi kesalahan saat mengirim permintaan. Koneksi yang mendasarinya ditutup: Terjadi kesalahan yang tidak terduga pada penerimaan. Tidak dapat membaca data dari koneksi transportasi: Koneksi yang ada ditutup secara paksa oleh host jarak jauh. Koneksi yang ada ditutup secara paksa oleh ID Aktivitas host jarak jauh.”

  • Resolusi

    Saat Anda mengalami kesalahan sebelumnya, pecahkan masalahnya dengan mengikuti petunjuk di bagian ini.

    • Kumpulkan jejak Netmon untuk analisis:

      1. Anda dapat mengatur filter untuk melihat reset dari server ke sisi klien. Dalam contoh cuplikan layar berikut, Anda dapat melihat bahwa sisi server adalah server Data Factory.

        Cuplikan layar server Data Factory.

      2. Ketika Anda mendapatkan paket reset, Anda dapat menemukan percakapannya dengan mengikuti Protokol Kendali Transmisi (Transmission Control Protocol/TCP).

        Cuplikan layar percakapan TCP.

      3. Dapatkan percakapan antara klien dan server Data Factory di bawah ini dengan menghapus filter.

        Cuplikan layar detail percakapan.

    • Analisis jejak Netmon yang telah Anda kumpulkan menunjukkan bahwa total Waktu Hidup (Time to Live/TTL) adalah 64. Menurut nilai yang disebutkan dalam artikel Waktu Hidup (TTL) IP dan Dasar-Dasar Batasan Hop yang diekstrak dalam daftar berikut, Anda dapat melihat bahwa Sistem Linux-lah yang mengatur ulang paket dan menyebabkan pemutusan.

      Nilai TTL dan Batasan Hop default bervariasi antar beragam sistem operasi, seperti yang tercantum di sini:

      • Linux kernel 2.4 (sekitar 2001): 255 untuk TCP, User Datagram Protocol (UDP), dan Internet Control Message Protocol (ICMP)
      • Linux kernel 4.10 (2015): 64 untuk TCP, UDP, dan ICMP
      • Windows XP (2001): 128 untuk TCP, UDP, dan ICMP
      • Windows 10 (2015): 128 untuk TCP, UDP, dan ICMP
      • Windows Server 2008: 128 untuk TCP, UDP, dan ICMP
      • Windows Server 2019 (2018): 128 untuk TCP, UDP, dan ICMP
      • macOS (2001): 64 untuk TCP, UDP, dan ICMP

      Cuplikan layar memperlihatkan nilai TTL 61.

      Dalam contoh sebelumnya, TTL ditampilkan sebagai 61 dan bukan 64, karena ketika paket jaringan mencapai tujuannya, ia perlu melalui berbagai hop, seperti perute atau perangkat jaringan. Jumlah perute atau perangkat jaringan dikurangi untuk menghasilkan TTL terakhir.

      Dalam kasus ini, Anda dapat melihat bahwa reset dapat dikirim dari Sistem Linux dengan TTL 64.

    • Untuk mengonfirmasi dari mana perangkat reset berasal, periksa hop keempat dari IR yang dihost sendiri.

      Paket jaringan dari Sistem Linux A dengan TTL 64 -> B TTL 64 minus 1 = 63 -> C TTL 63 minus 1 = 62 -> TTL 62 minus 1 = 61 IR yang dihost sendiri

    • Dalam situasi yang ideal, nomor hop TTL adalah 128, yang berarti sistem operasi Windows sedang menjalankan instans pabrik data Anda. Seperti yang ditunjukkan dalam contoh berikut, 128 dikurangi 107 = 21 hop, yang berarti bahwa 21 hop untuk paket dikirim dari instans pabrik data ke IR yang dihost sendiri saat handshake TCP 3.

      Cuplikan layar memperlihatkan nilai TTL 107.

      Oleh karena itu, Anda perlu melibatkan tim jaringan untuk pemeriksaan guna melihat apa hop keempat dari IR yang dihost sendiri. Jika hop itu firewall, seperti halnya Sistem Linux, periksa semua log untuk melihat mengapa perangkat tersebut mengatur ulang paket setelah handshake TCP 3.

      Jika Anda tidak yakin tentang tempat yang harus diselidiki, cobalah untuk mendapatkan jejak Netmon dari IR yang dihost sendiri dan firewall pada waktu bermasalah tersebut. Pendekatan ini akan membantu Anda untuk mengetahui perangkat mana yang mungkin telah mengatur ulang paket dan menyebabkan pemutusan. Dalam kasus ini, Anda juga perlu melibatkan tim jaringan Anda untuk langkah-langkah selanjutnya.

Menganalisis jejak Netmon

Catatan

Petunjuk berikut berlaku untuk jejak Netmon. Karena jejak Netmon saat ini tidak didukung, Anda dapat menggunakan Wireshark untuk tujuan ini.

Ketika Anda mencoba untuk telnet 8.8.8.8 888 dengan jejak Netmon yang dikumpulkan, Anda akan melihat jejaknya dalam cuplikan layar berikut:

Cuplikan layar memperlihatkan

Cuplikan layar memperlihatkan deskripsi jejak Netmon.

Gambar sebelumnya menunjukkan bahwa Anda tidak dapat membuat koneksi TCP ke sisi server 8.8.8.8 di port 888, sehingga Anda melihat dua paket tambahan SynReTransmit di sana. Karena sumber SELF-HOST2 tidak dapat tersambung ke 8.8.8.8 dengan paket pertama, ia akan terus mencoba untuk membuat koneksi.

Tip

Untuk membuat sambungan ini, cobalah solusi berikut:

  1. Pilih Muat Filter>Filter Standar>Alamat>Alamat IPv4.
  2. Untuk menerapkan filter, masukkan IPv4.Address == 8.8.8.8, lalu pilih Terapkan. Anda kemudian akan melihat komunikasi dari komputer lokal ke tujuan 8.8.8.8.

Cuplikan layar memperlihatkan alamat filter.

Cuplikan layar memperlihatkan lebih banyak alamat filter.

Skenario yang berhasil ditunjukkan dalam contoh berikut:

  • Jika Anda dapat melakukan telnet 8.8.8.8 53 tanpa masalah, berarti ada handshake TCP 3 yang berhasil, dan sesi selesai dengan handshake TCP 4.

    Cuplikan layar memperlihatkan skenario koneksi yang berhasil.

    Cuplikan layar memperlihatkan detail skenario koneksi yang berhasil.

  • Handshake TCP 3 sebelumnya menghasilkan alur kerja berikut:

    Diagram alur kerja handshake TCP 3.

  • Handshake TCP 4 untuk menyelesaikan sesi digambarkan oleh alur kerja berikut:

    Cuplikan layar detail handshake TCP 4.

    Diagram alur kerja handshake TCP 4.

Pemberitahuan surel Microsoft tentang pembaruan konfigurasi jaringan Anda

Anda mungkin menerima pemberitahuan surel berikut, yang menyarankan agar Anda memperbarui konfigurasi jaringan untuk memungkinkan komunikasi dengan alamat IP baru untuk Azure Data Factory sebelum 8 November 2020:

Cuplikan layar pemberitahuan surel Microsoft yang meminta pembaruan konfigurasi jaringan.

Menentukan apakah pemberitahuan ini mempengaruhi Anda

Pemberitahuan ini berlaku untuk skenario berikut:

Skenario 1: Komunikasi keluar dari runtime integrasi yang dihost sendiri yang berjalan secara lokal di belakang firewall perusahaan

Cara menentukan apakah Anda terpengaruh:

Skenario 2: Komunikasi keluar dari runtime integrasi yang dihost sendiri yang berjalan di Azure VM di dalam jaringan virtual Azure yang dikelola pelanggan

Cara menentukan apakah Anda terpengaruh:

  • Periksa apakah Anda memiliki aturan kelompok keamanan jaringan keluar (network security group/NSG) di jaringan privat yang berisi runtime integrasi yang dihost sendiri. Jika tidak ada larangan keluar, Anda tidak terpengaruh.

  • Jika Anda memiliki larangan aturan keluar, periksa untuk melihat apakah Anda menggunakan tag layanan. Jika Anda menggunakan tag layanan, Anda tidak terpengaruh. Tidak perlu mengubah atau menambahkan apa pun, karena rentang IP yang baru berada di tag layanan yang ada.

    Cuplikan layar pemeriksaan tujuan memperlihatkan DataFactory sebagai tujuan.

  • Anda terpengaruh jika Anda secara eksplisit mengaktifkan daftar yang diizinkan untuk alamat IP keluar pada pengaturan aturan NSG di jaringan virtual Azure.

    Jika Anda terpengaruh, lakukan tindakan berikut: sebelum 8 November 2020, beri tahu tim infrastruktur jaringan Anda untuk memperbarui aturan kelompok keamanan jaringan (NSG) pada konfigurasi jaringan virtual Azure Anda menggunakan alamat IP pabrik data terbaru. Untuk mengunduh alamat IP terbaru, buka Menemukan tag layanan dengan menggunakan file JSON yang dapat diunduh.

Skenario 3: Komunikasi keluar dari SSIS Integration Runtime dalam jaringan virtual Azure yang dikelola pelanggan

Cara menentukan apakah Anda terpengaruh:

  • Periksa apakah Anda memiliki aturan kelompok keamanan jaringan keluar di satu jaringan privat yang berisi SQL Server Integration Services (SSIS) Integration Runtime. Jika tidak ada larangan keluar, Anda tidak terpengaruh.

  • Jika Anda memiliki larangan aturan keluar, periksa untuk melihat apakah Anda menggunakan tag layanan. Jika Anda menggunakan tag layanan, Anda tidak terpengaruh. Tidak perlu mengubah atau menambahkan apa pun, karena rentang IP yang baru berada di bawah tag layanan yang ada.

  • Anda terpengaruh jika Anda secara eksplisit mengaktifkan daftar yang diizinkan untuk alamat IP keluar pada pengaturan aturan NSG di jaringan virtual Azure.

    Jika Anda terpengaruh, lakukan tindakan berikut: sebelum 8 November 2020, beri tahu tim infrastruktur jaringan Anda untuk memperbarui aturan kelompok keamanan jaringan (NSG) pada konfigurasi jaringan virtual Azure Anda menggunakan alamat IP pabrik data terbaru. Untuk mengunduh alamat IP terbaru, buka Menemukan tag layanan dengan menggunakan file JSON yang dapat diunduh.

Tidak dapat membangun hubungan kepercayaan untuk saluran aman SSL/TLS

  • Gejala

    IR yang dihost sendiri tidak dapat tersambung ke layanan Azure Data Factory atau Azure Synapse.

    Saat Anda memeriksa log peristiwa runtime integrasi yang dihost sendiri setelah masuk ke Windows>Event viewer (logs)>Applications and Services Logs>Integration Runtime, Anda akan menemukan pesan kesalahan berikut.

    "Koneksi yang mendasarinya ditutup: Tidak dapat membangun hubungan kepercayaan untuk saluran aman SSL/TLS. Sertifikat jarak jauh tidak valid menurut prosedur validasi.”

    Cara termudah untuk memeriksa sertifikat server layanan adalah dengan membuka URL layanan di browser Anda. Misalnya, buka tautan periksa sertifikat server (https://eu.frontend.clouddatahub.net/) pada komputer tempat IR yang dihost sendiri diinstal, lalu lihat informasi sertifikat server.

    Cuplikan layar panel periksa sertifikat server dari layanan Azure Data Factory.

    Cuplikan layar jendela untuk memeriksa jalur sertifikasi server.

  • Penyebab

    Ada dua kemungkinan penyebab kesalahan ini:

    • Alasan 1: OS akar dari sertifikat server layanan tidak dipercaya pada mesin tempat IR yang dihost sendiri diinstal.
    • Alasan 2: Anda menggunakan proksi di lingkungan Anda, sertifikat server layanan digantikan oleh proksi, dan sertifikat server yang diganti tidak dipercaya oleh komputer tempat IR yang dihost sendiri diinstal.

  • Resolusi

    • Untuk alasan 1: Pastikan bahwa sertifikat server layanan dan rantai sertifikatnya dipercaya oleh komputer tempat IR yang dihost sendiri diinstal.
    • Untuk alasan 2: Percayai OS akar yang diganti pada mesin IR yang dihost sendiri, atau konfigurasikan proksi untuk tidak mengganti sertifikat server layanan.

    Untuk informasi selengkapnya tentang mempercayai sertifikat pada Windows, lihat Memasang sertifikat akar tepercaya.

  • Informasi Tambahan
    Kami telah meluncurkan sertifikat SSL baru, yang ditandatangani dari DigiCert. Periksa untuk melihat apakah DigiCert Global Root G2 berada di OS akar tepercaya.

    Cuplikan layar memperlihatkan folder DigiCert Global Root G2 di direktori Otoritas Sertifikasi Akar Tepercaya.

    Jika tidak ada di OS akar tepercaya, unduh di sini.

Konten terkait

Untuk bantuan selengkapnya tentang pemecahan masalah, cobalah sumber daya berikut ini: