Helyi integrációs modul hibaelhárítása

A következőkre vonatkozik: Azure Data Factory Azure Synapse Analytics Microsoft Purview

Tipp.

Próbálja ki a Data Factoryt a Microsoft Fabricben, amely egy teljes körű elemzési megoldás a nagyvállalatok számára. A Microsoft Fabric az adattovábbítástól az adatelemzésig, a valós idejű elemzésig, az üzleti intelligenciáig és a jelentéskészítésig mindent lefed. Ismerje meg, hogyan indíthat új próbaverziót ingyenesen!

Ez a cikk az Azure Data Factory és a Synapse-munkaterületek saját üzemeltetésű integrációs moduljának (IR) gyakori hibaelhárítási módszereit ismerteti.

Saját üzemeltetésű integrációs naplók gyűjtése

Azure Data Factory és Azure Synapse Analytics

A saját üzemeltetésű integrációs modulon vagy megosztott integrációs modulon futó sikertelen tevékenységek esetén a szolgáltatás támogatja a hibanaplók megtekintését és feltöltését. A hibajelentés azonosítójának lekéréséhez kövesse az itt leírt utasításokat, majd adja meg a jelentésazonosítót a kapcsolódó ismert problémák kereséséhez.

1. A szolgáltatás felhasználói felületének Monitorozás lapján válassza a Folyamatfuttatások lehetőséget.

2. A Tevékenységfuttatások csoportban a Hiba oszlopban válassza ki a kiemelt gombot a tevékenységnaplók megjelenítéséhez, ahogyan az alábbi képernyőképen látható:

   Azure Data Factory

   

   Azure Synapse

   

   A sikertelen tevékenységfuttatás tevékenységnaplói jelennek meg.

   

3. További segítségért válassza a Naplók küldése lehetőséget.

   Megnyílik a saját üzemeltetésű integrációs modul (IR) naplóinak megosztása a Microsoft ablakával.

   

4. Válassza ki, hogy mely naplókat szeretné elküldeni.

   • Saját üzemeltetésű integrációs modul esetén feltöltheti a sikertelen tevékenységhez kapcsolódó naplókat, vagy az összes naplót a saját üzemeltetésű integrációs modul csomópontján.
   • Megosztott integrációs modul esetén csak a sikertelen tevékenységhez kapcsolódó naplókat tölthet fel.

5. A naplók feltöltésekor jegyezze fel a jelentésazonosítót későbbi használatra, ha további segítségre van szüksége a probléma megoldásához.

   

Feljegyzés

A naplómegtekintési és -feltöltési kérések az összes online, saját üzemeltetésű integrációs modulpéldányon futnak. Ha hiányoznak naplók, győződjön meg arról, hogy az összes saját üzemeltetésű integrációs modulpéldány online állapotban van.

Microsoft Purview

A saját üzemeltetésű integrációs modulon vagy megosztott integrációs modulon futó sikertelen Microsoft Purview-tevékenységek esetén a szolgáltatás támogatja a hibanaplók megtekintését és feltöltését a Windows Eseménynapló.

Az alábbi hibakalauzban látható hibákat megkeresheti. Ha támogatási és hibaelhárítási útmutatást szeretne kapni az SHIR-problémákhoz, előfordulhat, hogy létre kell hoznia egy hibajelentés-azonosítót, és kapcsolatba kell lépnie a Microsoft ügyfélszolgálatával.

A Microsoft ügyfélszolgálata hibajelentés-azonosítójának létrehozásához kövesse az alábbi utasításokat:

1. Mielőtt vizsgálatot indítanának a Microsoft Purview szabályozási portálján:

   1. Lépjen arra a gépre, amelyen telepítve van a saját üzemeltetésű integrációs modul, és nyissa meg a Windows Eseménynapló.
   2. Törölje a Windows Eseménynapló naplóit az Integrációs modul szakaszból. Kattintson a jobb gombbal a naplókra, és válassza a Naplók törlése lehetőséget.
   3. Lépjen vissza a Microsoft Purview szabályozási portálra, és indítsa el a vizsgálatot.

2. Ha a vizsgálat sikertelen állapotot mutat, lépjen vissza az SHIR virtuális gépre vagy gépre, és frissítse az eseménynaplót az Integrációs modul szakaszában.

3. A sikertelen vizsgálat futtatásához megjelennek a tevékenységnaplók.

4. A Microsoft további segítségére válassza a Naplók küldése lehetőséget.

   Megnyílik a saját üzemeltetésű integrációs modul (SHIR) naplóinak megosztása a Microsoft ablakával.

   

5. Válassza ki, hogy mely naplókat szeretné elküldeni.

   • Saját üzemeltetésű integrációs modul esetén feltöltheti a sikertelen tevékenységhez kapcsolódó naplókat, vagy az összes naplót a saját üzemeltetésű integrációs modul csomópontján.
   • Megosztott integrációs modul esetén csak a sikertelen tevékenységhez kapcsolódó naplókat tölthet fel.

6. A naplók feltöltésekor jegyezze fel a jelentésazonosítót későbbi használatra, ha további segítségre van szüksége a probléma megoldásához.

   

Feljegyzés

A naplómegtekintési és -feltöltési kérések az összes online, saját üzemeltetésű integrációs modulpéldányon futnak. Ha hiányoznak naplók, győződjön meg arról, hogy az összes saját üzemeltetésű integrációs modulpéldány online állapotban van.

Helyi integrációs modul – általános meghibásodás vagy hiba

Memóriahiánnyal kapcsolatos probléma

• Hibajelenségek

  Az OutOfMemoryException (OOM) hiba akkor jelentkezik, ha megpróbál keresési tevékenységet futtatni egy társított vagy egy helyi integrációs modullal.

• Ok

  Egy új tevékenység akkor okozhat OOM hibát, ha az integrációs modul gépe átmenetileg magas memóriahasználatot érzékel. Ezt a hibát az egyszerre futó tevékenységek magas száma okozhatja, és a bekövetkezése szándékos.

• Resolution (Osztás)

  Ellenőrizze az erőforrás-használatot és az egyszerre futó tevékenységek végrehajtását az integrációs modul csomópontján. Állítsa be a tevékenységfuttatások belső és kiváltási idejét, hogy egy integrációsmodul-csomóponton ne próbáljon meg egyszerre túl sok tevékenységet végezni a rendszer.

Egyidejű feladatok korlátjával kapcsolatos probléma

• Hibajelenségek

  Amikor megpróbálja növelni az egyidejű feladatok korlátját a felhasználói felületről, a folyamat frissítési állapotban marad.

  Példaforgatókönyv: az egyidejű feladatok maximális értéke jelenleg 24-re van beállítva, és növelni szeretné ezt a számot, hogy a feladatok gyorsabban futhassanak. A megadható minimális érték 3, a maximális érték pedig 32. Növelje az értéket 24-ről 32-re, majd válassza a Frissítés gombot. A folyamat elakad a frissítési állapotban, ahogy az az alábbi képernyőképen látható. Frissíti az oldalt, de a megjelenített érték továbbra is 24. Nem frissült a várt 32-re.

  

• Ok

  Az egyidejű feladatok számának korlátja a számítógép logikai magjától és a memóriájától függ. Próbálja alacsonyabb értékre, például 24-re módosítani a beállítást, majd tekintse meg az eredményt.

  Tipp.

  • Ha szeretne többet megtudni a logikai magok számáról, és meg szeretné határozni a gépe logikai magjainak számát, tekintse meg a Four ways to find the number of cores in your CPU on Windows 10 (Négy módszer a processzorban található magok számának megállapításához Windows 10 rendszeren) című cikket.
  • A math.log kiszámítási módjának megismeréséhez nyissa meg a logaritmus-számológépet.

Helyi integrációs modul magas rendelkezésreállású (HA) SSL-tanúsítványával kapcsolatos probléma

• Hibajelenségek

  A helyi integrációs modul munkacsomópontja a következő hibát jelentette:

  „A megosztott állapotok lehívása az elsődleges csomópontról sikertelen net.tcp://abc.cloud.corp.Microsoft.com:8060/ExternalService.svc/. Tevékenységazonosító: XXXXX Az X.509-tanúsítvány CN=abc.cloud.corp.Microsoft.com, OU=test, O=Microsoft láncának kiépítése meghiúsult. A használt tanúsítvány megbízhatósági lánca nem ellenőrizhető. Cserélje le a tanúsítványt, vagy módosítsa a certificateValidationMode elemet. A visszavonási függvény nem tudta ellenőrizni a visszavonást, mert a visszavonási kiszolgáló offline állapotban volt.”

• Ok

  Az SSL-/TLS-kézfogással kapcsolatos esetek kezelésekor előfordulhat, hogy tanúsítványlánc-ellenőrzéssel kapcsolatos problémákba ütközik.

• Resolution (Osztás)

  • Íme egy rövid és intuitív módszer egy X.509 tanúsítványlánc létrehozási hibájának elhárítására:

    1. Exportálja az ellenőrizni kívánt tanúsítványt. Ehhez tegye a következőket:

       a. A Windowsban válassza a Start gombot, kezdje el beírni a tanúsítványok kifejezést, majd válassza a Számítógép-tanúsítványok kezelése lehetőséget.

       b. Az Intéző bal oldali panelén keresse meg az ellenőrizni kívánt tanúsítványt, kattintson rá a jobb gombbal, majd válassza a Minden feladat>Exportálás elemet.

       

    2. Másolja az exportált tanúsítványt az ügyfélgépre.

    3. Az ügyféloldalon futtassa az alábbi parancsot a parancssori ablakban. Mindenképpen cserélje le <a tanúsítvány elérési útját> és< a kimeneti txt fájl elérési útját> a tényleges elérési utakra.

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

       Például:

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

    4. Keressen hibákat a kimeneti TXT-fájlban. A hibaösszegzést a TXT-fájl végén találja.

       Példa:

       

       Ha nem jelenik meg hiba a naplófájl végén, ahogyan az az alábbi képernyőképen látható, úgy tekintheti, hogy a tanúsítványlánc sikeresen létrejött az ügyfélszámítógépen.

       

  • Azt, hogy konfigurálva lett-e AIA (szolgáltatói adatok elérése), CDP (CRL terjesztési pont) vagy OCSP (OCSP protokoll) típusú fájlnévkiterjesztés a tanúsítványfájlban, még intuitívabb módon ellenőrizheti:

    1. Ezeket az információkat a tanúsítvány részleteinek ellenőrzésével szerezheti be, ahogyan az alábbi képernyőképen látható:

       

    2. Futtassa az alábbi parancsot. Mindenképpen cserélje le <a tanúsítvány elérési útját> a tanúsítvány tényleges elérési útjára.

         Certutil   -URL    <certificate path> 
       

       Megnyílik az URL-lekérési eszköz.

    3. Az AIA-, CDP- és OCSP-fájlnévkiterjesztéssel rendelkező tanúsítványok ellenőrzéséhez kattintson a Beolvasás gombra.

       

       Sikeresen összeállította a tanúsítványláncot, ha az AIA tanúsítványállapota ellenőrzött , és a CDP-ből vagy az OCSP-ből származó tanúsítvány állapota ellenőrzött.

       Ha az AIA vagy a CDP lekérése nem sikerül, működjön együtt a hálózatkezelésért felelős csapattal az ügyfélgépnek a cél URL-címhez való csatlakoztatásának előkészítésében. Elegendő, ha a HTTP- vagy a Lightweight Directory Access Protocol- (LDAP-) útvonal ellenőrizhető.

A helyi integrációs modul nem tudja betölteni a fájlt vagy a szerelvényt

• Hibajelenségek

  A következő hibaüzenetet kapja:

  „Nem lehet betölteni a fájlt vagy a szerelvényt (XXXXXXXXXXXXXXXX, Version=4.0.2.0, Culture=neutral, PublicKeyToken=XXXXXXXXX) vagy valamelyik függőségét. A megadott fájl nem található. Tevékenységazonosító: 92693b45-b4bf-4fc8-89da-2d3dc56f27c3”

  Íme egy konkrétabb hibaüzenet:

  „Nem lehet betölteni a fájlt vagy a szerelvényt (System.ValueTuple, Version=4.0.2.0, Culture=neutral, PublicKeyToken=XXXXXXXXX) vagy valamelyik függőségét. A megadott fájl nem található. Tevékenységazonosító: 92693b45-b4bf-4fc8-89da-2d3dc56f27c3”

• Ok

  A Folyamatfigyelőben a következő eredményt tekintheti meg:

  

  Tipp.

  A folyamatfigyelőben az alábbi képernyőképen látható módon állíthat be szűrőket.

  Az előző hibaüzenet szerint a DLL System.ValueTuple nem a kapcsolódó globális szerelvény-gyorsítótár (GAC) mappában, a C:\Program Files\Microsoft Integration Runtime\4.0\Gateway mappában vagy a C:\Program Files\Microsoft Integration Runtime\4.0\Shared mappában található.

  A folyamat alapvetően először a GAC mappából, majd a Megosztott mappából, végül az Átjáró mappából tölti be a DLL-t. Ezért a DLL-fájlt bármelyik elérési útról betöltheti, amelyik hasznos.

  

• Resolution (Osztás)

  A System.ValueTuple.dll fájl a C:\Program Files\Microsoft Integration Runtime\4.0\Gateway\DataScan mappában található. A probléma megoldásához másolja a System.ValueTuple.dll fájlt a C:\Program Files\Microsoft Integration Runtime\4.0\Gateway mappába.

  Ugyanezt a módszert használhatja más, hiányzó fájllal vagy szerelvénnyel kapcsolatos problémák megoldásához is.

• További információ erről a problémáról

  A %windir%\Microsoft.NET\assembly és a %windir%\assembly területen a System.ValueTuple.dll azért jelenik meg, mert ez egy .NET-viselkedés.

  Az alábbi hibaüzenetben egyértelműen látható, hogy a System.ValueTuple szerelvény hiányzik. Ez a probléma akkor merül fel, amikor az alkalmazás megpróbálja ellenőrizni a System.ValueTuple.dll szerelvényt.

  "<LogProperties><ErrorInfo>[{"Code":0,"Message":"Az "Npgsql.PoolManager" típusinicializálója kivételt jelzett.","EventType":0,"Category":5,"Data":{},"MsgId":null,"ExceptionType":"System.TypeInitializationException","Source":"Npgsql","StackTrace":"","InnerEventInfos":[{"Code":0,"Message":"Nem sikerült betölteni a "System.ValueTuple, Version=4.0.2.0" fájlt vagy szerelvényt, Culture=neutral, PublicKeyToken=XXXXXXXXX' vagy annak egyik függősége. A rendszer nem találja a megadott fájlt.","EventType":0,"Category":5,"Data":{},"MsgId":null,"ExceptionType":"System.IO.FileNotFoundException","Source":"Npgsql","StackTrace":","InnerEventInfos":[]}}]</ErrorInfo></LogProperties>"

  További tudnivalók a GAC kapcsán: Globális szerelvény-gyorsítótár.

Helyi integrációs modul – A hitelesítési kulcs hiányzik

• Hibajelenségek

  Hitelesítési kulcs hiányában a helyi integrációs modul hirtelen offline állapotba lép, és az eseménynaplóban a következő hibaüzenet jelenik meg:

  „Még nincs hozzárendelve hitelesítési kulcs”

  

• Ok

  • A helyi integrációs modul csomópontja vagy a logikai helyi integrációs modul törölve lett az Azure Portalon.
  • Egyszerű eltávolítást hajtottak végre.

• Resolution (Osztás)

  Ha a fenti okok egyike sem érvényes, lépjen a %programdata%\Microsoft\Data Transfer\DataManagementGateway mappába, és ellenőrizze, hogy a konfigurációs fájl törölve lett-e. Ha törölve lett, kövesse a Windows-fájlkiszolgálókról fájlt törlő személy észlelését ismertető Netwrix-cikk útmutatását.

  

A helyi integrációs modul nem használható két helyszíni adattároló áthidalásához

• Hibajelenségek

  Miután létrehozott egy-egy helyi integrációs modult a forrás- és a céladattárhoz, össze szeretné kapcsolni a két integrációs modult egy másolási tevékenység befejezéséhez. Ha az adattárak különböző virtuális hálózatokon vannak konfigurálva, vagy ha nem ismerik az átjáró mechanizmusát, akkor az alábbi hibák valamelyike jelentkezik:

  • „A forrás illesztője nem található a cél integrációs moduljában”
  • „A cél integrációs modulja nem tud hozzáférni a forráshoz”

• Ok

  A helyi integrációs modul a másolási tevékenység központi csomópontjaként lett kialakítva, nem pedig az egyes adattárolók esetében telepítendő ügyfélügynökként.

  Ebben az esetben mindegyik adattár társított szolgáltatását ugyanazzal az integrációs modullal kell létrehozni, és az integrációs modulnak képesnek kell lennie az adattárolók elérésére a hálózaton keresztül. Nem számít, hogy az integrációs modul a forrásadattárban, a céladattárban vagy egy harmadik gépen van telepítve. Ha a két társított szolgáltatás eltérő integrációs modullal lett létrehozva, de azonos másolási tevékenységben használják őket, a rendszer a cél integrációs modult fogja használni, és mindkét adattároló illesztőit telepíteni kell a cél integrációs modul gépén.

• Resolution (Osztás)

  Telepítse a forrás és a cél illesztőit a cél integrációs modulon, és győződjön meg arról, hogy hozzáférnek a forrás adattárolóhoz.

  Ha az adatforgalom nem tud áthaladni a két adattároló közötti hálózaton (például mert az adattárolók két különböző virtuális hálózaton lettek konfigurálva), akkor előfordulhat, hogy a másolás nem végezhető el egyetlen tevékenységben, még akkor sem, ha az integrációs modul telepítve van. Ha a másolást nem lehet egyetlen tevékenységben elvégezni, akkor létrehozhat két másolási tevékenységet két integrációs modullal, mindegyiket egy-egy virtuális hálózatban:

  • Egy integrációs modul másolása az első adattárból az Azure Blob Storage-ba
  • Egy másik integrációs modul másolása az Azure Blob Storage-ból a második adattárba

  Ezzel a megoldással szimulálható azt a követelmény, hogy a két szétkapcsolt adattárolót összekötő hidat az integrációs modul használatával kell létrehozni.

A hitelesítő adatok szinkronizálási hibája miatt hitelesítőadat-vesztés történt a magas rendelkezésreállási szinten

• Hibajelenségek

  Ha a hasznos adatokkal együtt törlik az adatforrás hitelesítő adatait („XXXXXXXXXX”) az aktuális integrációsmodul-csomópontról, a következő hibaüzenet jelenik meg:

  „Amikor törli a kapcsolati szolgáltatást az Azure Portalon, vagy a feladat hibás hasznos adattal rendelkezik, hozzon létre egy új kapcsolati szolgáltatást a hitelesítő adataival.”

• Ok

  A helyi integrációs modul két csomóponttal lett létrehozva a magas rendelkezésreállási módban, de a csomópontok hitelesítő adatai nincsenek szinkronizálva. Ez azt jelenti, hogy a kézbesítő csomópontban tárolt hitelesítő adatok nem lettek szinkronizálva a többi munkavégző csomóponttal. Ha bármilyen feladatátvétel történik a kézbesítő csomópontból a munkavégző csomópontba, és a hitelesítő adatok csak a korábbi kézbesítő csomópontban találhatók meg, akkor a feladat meghiúsul, amikor a hitelesítő adatokhoz próbál hozzáférni, és a fenti hibaüzenet jelenik meg.

• Resolution (Osztás)

  A probléma elkerülésének egyetlen módja annak biztosítása, hogy a két csomópont hitelesítő adatai szinkronizálva legyenek. Ha nincsenek szinkronizálva, az új kézbesítő esetében újra meg kell adnia a hitelesítő adatokat.

A tanúsítvány nem választható ki, mert a titkos kulcs hiányzik

• Hibajelenségek

  • Egy PFX-fájlt importált a tanúsítványtárolóba.

  • Ha az integrációs modul konfigurációkezelőjének felhasználói felülete segítségével választotta ki a tanúsítványt, a következő hibaüzenet jelent meg:

    „Nem sikerült a módosítani az intranetes kommunikáció titkosítási módját. Valószínű, hogy a tanúsítvány "<tanúsítványneve>" nem rendelkezik kulcscserére alkalmas titkos kulccsal, vagy a folyamat nem rendelkezik hozzáférési jogosultságokkal a titkos kulcshoz. A részletekért tekintse meg a belső kivételt.”

    

• Ok

  • A felhasználói fiók alacsony jogosultsági szintű, és nem fér hozzá a titkos kulcshoz.
  • A tanúsítvány aláírásként, de nem kulcscsereként lett létrehozva.

• Resolution (Osztás)

  • A felhasználói felület használatához használjon a titkos kulcs eléréséhez megfelelő jogosultságokkal rendelkező fiókot.

  • Importálja a tanúsítványt az alábbi parancs futtatásával:

    certutil -importpfx FILENAME.pfx AT_KEYEXCHANGE
    

A helyi integrációs modul szinkronizálatlan csomópontjaival kapcsolatos hiba

• Hibajelenségek

  A helyi integrációs modul csomópontjai megpróbálják szinkronizálni a csomópontok között a hitelesítő adatokat, de a folyamat közben elakadnak, és egy idő után az alábbi hibaüzenetet tapasztalják:

  „A (helyi) integrációs modul csomópontja megpróbálja szinkronizálni a hitelesítő adatokat a csomópontok között. Ez eltarthat néhány percig.”

  Feljegyzés

  Ha ez a hiba több mint 10 percig jelenik meg, ellenőrizze a kapcsolatot a diszpécser csomóponttal.

• Ok

  Ennek oka, hogy a munkavégző csomópontok nem férnek hozzá a titkos kulcsokhoz. Ezt a helyi integrációs modul alábbi naplóiban erősítheti meg:

  [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.

  Nincs problémája a szinkronizálási folyamattal, amikor szolgáltatásnév-alapú hitelesítést használ a csatolt szolgáltatásban. Azonban amikor a hitelesítési típust fiókkulcsra módosítja, megjelenik a szinkronizálási hiba. Ennek oka, hogy a helyi integrációs modul szolgáltatás egy szolgáltatásfiók (NT SERVICE\DIAHostService) alatt fut, amelyet hozzá kell adni a titkos kulcs engedélyeihez.

• Resolution (Osztás)

  A probléma megoldásához a helyi integrációs modul szolgáltatásfiókját (NT SERVICE\DIAHostService) hozzá kell adnia a titkos kulcs engedélyeihez. A következő lépéseket alkalmazhatja:

  1. Nyissa meg a Microsoft Management Console (MMC) futtatás parancsát.

     

  2. Az MMC panelen hajtsa végre a következő lépéseket:

     

     1. Válassza a Fájl lehetőséget.
     2. A legördülő menüben válassza a Beépülő modul hozzáadása/eltávolítása elemet.
     3. Az Elérhető beépülő modulok panelen válassza a Tanúsítványok elemet.
     4. Válassza a Hozzáadás lehetőséget.
     5. A Tanúsítványok beépülő modul panelen válasza a Számítógépfiók elemet.
     6. Válassza a Tovább lehetőséget.
     7. A Számítógép kiválasztása panelen válassza a Helyi számítógép: a számítógép, amelyen ez a konzol fut elemet.
     8. Válassza a Befejezés lehetőséget.
     9. A Beépülő modulok hozzáadása vagy eltávolítása panelen válassza az OK gombot.

  3. Az MMC paneljén lépjen tovább a következő lépésekkel:

     

     1. A bal oldali mappalistában válassza a Konzolgyökér –> Tanúsítványok (Helyi számítógép) –> Személyes –> Tanúsítványok lehetőséget.
     2. Kattintson a jobb gombbal a Microsoft Intune Beta MDM elemre.
     3. Válassza a Minden feladat lehetőséget a legördülő listában.
     4. Válassza ki a Titkos kulcsok kezelése lehetőséget.
     5. A Csoportok vagy felhasználók neve területen válassza a Hozzáadás lehetőséget.
     6. Válassza az NT SERVICE\DIAHostService elemet, hogy teljes hozzáférést nyújtson neki a tanúsítványhoz, majd alkalmazza és mentse a módosításokat.
     7. Válassza a Nevek ellenőrzése elemet, majd válassza az OK elemet.
     8. Az Engedélyek panelen válassza az Alkalmaz lehetőséget, majd kattintson az OK gombra.

UserErrorJreNotFound hibaüzenet egy Azure-ba irányuló másolási tevékenység futtatásakor

• Hibajelenségek

  Ha Java-alapú eszköz vagy program használatával próbál tartalmat másolni a Microsoft Azure-ba (például ORC vagy Parquet formátumú fájlok másolásával), az alábbihoz hasonló hibaüzenetet kap:

  ErrorCode=UserErrorJreNotFound,'Type=Microsoft.DataTransfer.Common.Shared.HybridDeliveryException,Message=Java Runtime Environment is not found. Lépjen a http://go.microsoft.com/fwlink/?LinkId=808605 oldalra, töltse le, és telepítse a helyi integrációs modul csomópontjának gépére. Megjegyzés: A 64 bites integrációs modulhoz 64 bites JRE, a 32 biteshez pedig 32 bites JRE szükséges JRE.,Source=Microsoft.DataTransfer.Common,''Type=System.DllNotFoundException,Message=Unable to load DLL 'jvm.dll': The specified module could not be found. (Exception from HRESULT: 0x8007007E),Source=Microsoft.DataTransfer.Richfile.HiveOrcBridge

• Ok

  Ez a probléma az alábbi okok valamelyike miatt fordulhat elő:

  • A Java Runtime Environment (JRE) hibásan lett telepítve az integrációs modul kiszolgálójára.

  • Az integrációs modul kiszolgálója nem rendelkezik a szükséges függőségekkel a JRE-hez.

  Alapértelmezés szerint az integrációs modul a JRE-útvonalat beállításjegyzék-bejegyzésekkel oldja fel. Ezeket a bejegyzéseket a rendszer elvileg automatikusan beállítja a JRE telepítésekor.

• Resolution (Osztás)

  Pontosan kövesse a szakasz lépéseit. A beállításjegyzék helytelen módosítása komoly problémákat okozhat. A módosítás elvégzése előtt készítsen biztonsági másolatot a beállításjegyzékről arra az esetre, ha valami probléma merülne fel.

  A probléma megoldásához kövesse az alábbi lépéseket a JRE-telepítés állapotának ellenőrzéséhez:

  1. Győződjön meg róla, hogy az integrációs modul (Diahost.exe) és a JRE ugyanarra a platformra lettek telepítve. Ellenőrizze a következő feltételeket:

     • A 64 bites ADF-integrációs futtatókörnyezet 64 bites JRE-jét telepíteni kell a mappába: C:\Program Files\Java\

       Feljegyzés

       A mappa nem C:\Program Files (x86)\Java\

     • A Java Runtime (JRE) 11-es vagy újabb verziójú, olyan JRE-szolgáltatótól, mint a Microsoft OpenJDK 11 vagy az Eclipse Temurin 11. Győződjön meg arról, hogy a JAVA_HOME rendszerkörnyezet változója a JDK mappára van állítva (nem csak a JRE mappára), a tárolómappát is hozzá kell adnia a rendszer PATH környezeti változójához.

  2. A megfelelő beállításokat ellenőrizze a beállításjegyzékben. Ehhez kövesse az alábbi lépéseket:

     1. A Futtatás menübe gépelje be a Regedit kifejezést, majd nyomja le az Enter billentyűt.

     2. A navigációs ablakban keresse meg a következő alkulcsot:

        HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment.

        A Részletek ablakban kell lennie egy Jelenlegi verzió bejegyzésnek, amely elárulja a JRE verzióját (például 1.8).

        

     3. A navigációs ablakban keresse meg azt az alkulcsot, amely pontosan egyezik a JRE mappában található verzióval (például 1.8). A Részletek ablakban lennie kell egy JavaHome bejegyzésnek. A bejegyzés értéke a JRE telepítési útvonala.

        

  3. Keresse meg a bin\server mappát a következő elérési úton:

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

     

  4. Ellenőrizze, hogy a mappa tartalmaz-e egy jvm.dll nevű fájlt. Ha nem, ellenőrizze a fájlt a bin\client mappában.

     

  Feljegyzés

  • Ha bármelyik konfiguráció nem felel meg a lépésekben leírtaknak, a probléma elhárításához használja a JRE Windows-telepítőt.
  • Ha a lépésekben leírt összes konfiguráció helyes, előfordulhat, hogy a rendszerből hiányzik a VC++ futtatókörnyezet egy könyvtára. Ezt a problémát úgy oldhatja meg, hogy telepíti a VC++ 2010 terjeszthető csomagját.

Saját üzemeltetésű integrációs modul beállítása

Integrációs modul regisztrációs hibája

• Hibajelenségek

  Előfordulhat, hogy az alábbi okok valamelyike miatt szeretne egy saját üzemeltetésű integrációs modult futtatni egy másik fiókban:

  • A vállalati szabályzat nem engedélyezi a szolgáltatásfiókot.
  • Hitelesítésre van szükség.

  Miután módosította a szolgáltatásfiókot a szolgáltatáspanelen, előfordulhat, hogy az integrációs modul leáll, és a következő hibaüzenet jelenik meg:

  "A Integration Runtime (helyi) csomópont hibát észlelt a regisztráció során. Nem lehet csatlakozni a (helyi) integrációs modul gazdaszolgáltatásához.”

  

• Ok

  Sok erőforrás csak a szolgáltatásfióknak van megadva. Ha a szolgáltatásfiókot egy másik fiókra módosítja, az összes függő erőforrás engedélyei változatlanok maradnak.

• Resolution (Osztás)

  Nyissa meg az integrációs modul eseménynaplóját a hiba ellenőrzéséhez.

  

  • Ha az eseménynaplóban az „UnauthorizedAccessException” hiba szerepel, tegye a következőt:

    1. Ellenőrizze a DIAHostService bejelentkezési szolgáltatásfiókot a Windows-szolgáltatás paneljén.

       

    2. Ellenőrizze, hogy a bejelentkezési szolgáltatásfiók rendelkezik-e olvasási/írási engedélyekkel a %programdata%\Microsoft\DataTransfer\DataManagementGateway mappához.

       • Ha a szolgáltatás bejelentkezési fiókja nem változott, alapértelmezés szerint kell olvasási/írási engedéllyel rendelkeznie.

         

       • Ha módosította a szolgáltatás bejelentkezési fiókját, az alábbiak elvégzésével kezelheti a problémát:

         a. Végezze el az aktuális helyi integrációs modul tiszta eltávolítását.
         b. Telepítse a helyi integrációs modul részeit.
         c. Módosítsa a szolgáltatásfiókot az alábbiak elvégzésével:

         i. Lépjen a helyi integrációs modul telepítési mappájába, majd váltson a Microsoft Integration Runtime\4.0\Shared mappára.
         ii. Nyisson meg egy parancssori ablakot emelt szintű jogosultságokkal. Cserélje le <a felhasználót> és< a jelszót> a saját felhasználónevére és jelszavára, majd futtassa a következő parancsot:
         dmgcmd.exe -SwitchServiceAccount "<user>" "<password>"
         iii. Ha módosítani szeretné a LocalSystem fiókot, győződjön meg arról, hogy a megfelelő formátumot használja a következő fiókhoz: dmgcmd.exe -SwitchServiceAccount "NT Authority\System" ""
         Ne használja ezt a formátumot: dmgcmd.exe -SwitchServiceAccount "LocalSystem" ""
         IV. Opcionálisan, mivel a helyi rendszer magasabb jogosultságokkal rendelkezik, mint Rendszergazda istrator, közvetlenül is módosíthatja azt a "Szolgáltatások" területen.
         v. Az integrációs modul szolgáltatás bejelentkezési fiókjához helyi/tartományi felhasználót is használhat.

         d. Regisztrálja az integrációs modult.

  • Ha a hiba az "Integrációs modulszolgáltatás" (DIAHostService) sikertelen indítása. Ellenőrizze, hogy rendelkezik-e megfelelő jogosultságokkal a rendszerszolgáltatások indításához", tegye a következőket:

    1. Ellenőrizze a DIAHostService bejelentkezési szolgáltatásfiókot a Windows-szolgáltatás paneljén.

       

    2. Ellenőrizze, hogy a bejelentkezési szolgáltatásfiók rendelkezik-e szolgáltatásengedélyként a Windows szolgáltatás elindításához:

       

• További információ

  Ha az előző két megoldási minta egyike sem érvényes az Ön esetében, próbálja meg összegyűjteni a következő Windows-eseménynaplókat:

  • Alkalmazások és szolgáltatások naplóinak integrációs > modulja
  • Windows Naplók > alkalmazás

Nem található a Regisztrálás gomb egy helyi integrációs modul regisztrálásához

• Hibajelenségek

  Saját üzemeltetésű integrációs modul regisztrálásakor a Regisztráció gomb nem jelenik meg a Configuration Manager panelen.

  

• Ok

  Az Integration Runtime 3.0 kiadásától kezdve a meglévő integrációs futásidejű csomópontokon a Register gombot eltávolítottuk, hogy tisztább és biztonságosabb környezetet biztosítsunk. Ha regisztrált egy csomópontot valamilyen integrációs modulba (online vagy nem online), akkor a csomópont másik integrációs modulba történő újraregisztrálásához először el kell távolítania az előző csomópontot, és ezt követően tudja telepíteni és regisztrálni a csomópontot.

• Resolution (Osztás)

  1. A Vezérlőpult távolítsa el a meglévő integrációs modult.

     Fontos

     Az alábbi folyamat során válassza az Igen lehetőséget. Ne őrizze meg az adatokat az eltávolítási folyamat során.

     

  2. Ha nem rendelkezik az integrációs modul telepítő MSI-fájljával, a letöltőközpontból töltheti le a legfrissebb integrációs modult.

  3. Telepítse az MSI-fájlt, és regisztrálja az integrációs modult.

A helyi integrációs modul nem regisztrálható a localhost miatt

• Hibajelenségek

  A saját üzemeltetésű integrációs modul nem regisztrálható egy új gépen get_LoopbackIpOrName használatakor.

  Hibakeresés: Futásidejű hiba történt. A „Microsoft.DataTransfer.DIAgentHost.DataSourceCache” típusinicializáló kivételt jelzett. Helyreállíthatatlan hiba történt az adatbázis-keresés közben.

  Kivétel részletei: System.TypeInitializationException: A Microsoft.DataTransfer.DIAgentHost.DataSourceCache típusinicializálója kivételt jelzett. >--- System.Net.Sockets.SocketException: Nem helyreállítható hiba történt a System.Net.Dns.GetAddrInfo(Sztringnév) adatbázis-keresés során.

• Ok

  A probléma általában akkor fordul elő, ha a localhost megoldása folyamatban van.

• Resolution (Osztás)

  Használja a localhost 127.0.0.1 IP-címét a fájl üzemeltetéséhez és a probléma megoldásához.

A saját üzemeltetésű beállítás nem sikerült

• Hibajelenségek

  Nem távolíthat el meglévő integrációs modult, nem telepíthet új integrációs modult, vagy nem frissíthet meglévő integrációs modult új integrációs modulra.

• Ok

  Az integrációs modul telepítése a Windows Installer szolgáltatástól függ. Telepítési problémákat tapasztalhat a következő okok miatt:

  • Nincs elegendő szabad lemezterület.
  • Engedélyek hiánya.
  • A Windows NT szolgáltatás zárolva van.
  • A processzor kihasználtsága túl magas.
  • Az MSI-fájl lassú hálózati helyen található.
  • Néhány rendszerfájlt vagy adatbázist véletlenül megérintettek.

Az integrációs modul szolgáltatásfiókja nem tudta lekérni a tanúsítványhozzáférést

• Hibajelenségek

  Ha önkiszolgáló integrációs modult telepít a Microsoft Integration Runtime Configuration Manageren keresztül, létrejön egy megbízható hitelesítésszolgáltatóval (CA) rendelkező tanúsítvány. A tanúsítvány nem alkalmazható a két csomópont közötti kommunikáció titkosítására, és a következő hibaüzenet jelenik meg:

  "Nem sikerült módosítani az intranetes kommunikáció titkosítási módját: Nem sikerült hozzáférést adni az integrációs modul szolgáltatásfiókjának a tanúsítványnévhez<>. Hibakód: 103"

  

• Ok

  A tanúsítvány kulcstároló-szolgáltatót (KSP) használ, ami még nem támogatott. A saját üzemeltetésű integrációs modul a mai napig csak a titkosítási szolgáltató (CSP) tárhelyét támogatja.

• Resolution (Osztás)

  Ebben az esetben a CSP-tanúsítványok használatát javasoljuk.

  1\. megoldás

  A tanúsítvány importálásához futtassa a következő parancsot:

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

  

  2\. megoldás

  A tanúsítvány konvertálásához futtassa a következő parancsokat:

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

  Átalakítás előtt és után:

  

  

Saját üzemeltetésű integrációs modul 5.x-es verziója

A saját üzemeltetésű integrációs modul 5.x-es verziójára való frissítéshez .NET-keretrendszer 4.7.2-es vagy újabb futtatókörnyezetre van szükség. A letöltési oldalon megtalálja a legújabb 4.x verzió és a legújabb két 5.x verzió letöltési hivatkozásait.

Az Azure Data Factory 2-es és Azure Synapse-ügyfelei számára:

• Ha az automatikus frissítés be van kapcsolva, és már frissítette a .NET-keretrendszer Futtatókörnyezetet a 4.7.2-es vagy újabb verzióra, a helyi integrációs modul automatikusan frissül a legújabb 5.x verzióra.
• Ha az automatikus frissítés be van kapcsolva, és nem frissítette a .NET-keretrendszer Futtatókörnyezetet a 4.7.2-es vagy újabb verzióra, a helyi integrációs modul nem frissül automatikusan a legújabb 5.x verzióra. A saját üzemeltetésű integrációs modul a jelenlegi 4.x verzióban marad. A portálon és a saját üzemeltetésű integrációs modul ügyfélprogramjában figyelmeztetés jelenik meg a .NET-keretrendszer futtatókörnyezet frissítésére vonatkozóan.
• Ha az automatikus frissítés ki van kapcsolva, és már frissítette a .NET-keretrendszer Futtatókörnyezetet 4.7.2-re vagy újabbra, manuálisan letöltheti a legújabb 5.x verziót, és telepítheti a gépére.
• Ha az automatikus frissítés ki van kapcsolva, és nem frissítette a .NET-keretrendszer Futtatókörnyezetet 4.7.2-re vagy újabbra. Amikor megpróbálja manuálisan telepíteni a saját üzemeltetésű integrációs modul 5.x verzióját, és regisztrálja a kulcsot, először frissítenie kell a .NET-keretrendszer Futtatókörnyezet verzióját.

Helyi integrációs modul csatlakozási problémái

A helyi integrációs modul nem tud kapcsolódni a felhőszolgáltatáshoz

• Hibajelenségek

  Amikor megpróbálja regisztrálni a helyi integrációs modult, a Configuration Manager a következő hibaüzenetet jeleníti meg:

  „A (helyi) integrációs modul csomópontja hibát észlelt a regisztráció során.”

  

• Ok

  A saját üzemeltetésű integrációs modul nem tud csatlakozni a szolgáltatás háttérrendszeréhez. Ezt a problémát általában a tűzfal hálózati beállításai okozzák.

• Resolution (Osztás)

  1. Ellenőrizze, hogy fut-e az integrációs modul. Ha így van, folytassa a 2. lépéssel.

     

  2. Ha nincs konfigurálva proxy a helyi integrációs modulon (ez az alapértelmezett beállítás), futtassa a következő PowerShell-parancsot azon a gépen, amelyen a helyi integrációs modul telepítve van:

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

     Feljegyzés

     A szolgáltatás URL-címe az adat-előállító vagy a Synapse-munkaterület példányától függően változhat. A szolgáltatás URL-címének megkereséséhez használja a felhasználói felület adatkezelési lapját a data factoryban vagy az Azure Synapse-példányban az integrációs futtatókörnyezetek megkereséséhez, és kattintson a saját üzemeltetésű integrációs modulra a szerkesztéséhez. Válassza a Csomópontok lapot, és kattintson a Szolgáltatás URL-címeinek megtekintése elemre.

     A következő a várható válasz:

     

  3. Ha nem a várt választ kapja, a forgatókönyvnek megfelelően használja az alábbi módszerek valamelyikét:

     • Ha „A távoli név nem oldható fel” üzenet jelenik meg, akkor a probléma a tartománynévrendszerrel (DNS) kapcsolatos. A probléma kijavításához lépjen kapcsolatba a hálózatért felelős csapattal.
     • Ha "ssl/tls cert is not trusted" üzenet jelenik meg, ellenőrizze a tanúsítványt (https://wu2.frontend.clouddatahub.net/) annak ellenőrzéséhez, hogy az megbízható-e a gépen, majd telepítse a nyilvános tanúsítványt a Tanúsítványkezelővel. Ezzel a művelettel kezelnie kell tudnia a problémát.
     • Lépjen a Windows>Eseménynapló (naplók)>Alkalmazás- és szolgáltatásnaplók>Integrációs modul területre, és ellenőrizze, hogy találhatók-e ott DNS, tűzfalszabály vagy vállalati hálózati beállítások által okozott hibák. Ha talál ilyen hibát, kényszerített módon bontsa a kapcsolatot. Mivel minden vállalat saját, testre szabott hálózati beállításokkal rendelkezik, az ilyen jellegű problémák elhárításához lépjen kapcsolatba a hálózatért felelős csapattal.

  4. Ha „proxy” lett konfigurálva a helyi integrációs modulon, ellenőrizze, hogy a proxykiszolgáló hozzáfér-e a szolgáltatásvégponthoz. Mintaparancsért lásd a PowerShell-lel, webes kérelmekkel és proxykkal foglalkozó részt.

     $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
     

  A következő a várható válasz:

  

  Feljegyzés

  Proxyval kapcsolatos szempontok:

  • Ellenőrizze, hogy a proxykiszolgálót fel kell-e venni a Széf Címzettek listájára. Ha igen, győződjön meg arról, hogy ezek a tartományok szerepelnek a megbízható címzettek listáján.
  • Ellenőrizze, hogy az SSL/TLS-tanúsítvány wu2.frontend.clouddatahub.net/ megbízható-e a proxykiszolgálón.
  • Ha Active Directory-hitelesítést használ a proxyn, módosítsa a szolgáltatásfiókot arra a felhasználói fiókra, amely a proxyhoz „integrációs modul szolgáltatásként” fér hozzá.

Hibaüzenet: A saját üzemeltetésű integrációs modul csomópontja/a logikai helyi integrációs modul inaktív/ "Fut (korlátozott)" állapotban van

• Ok

  A saját üzemeltetésű integrált futtatókörnyezeti csomópont inaktív állapotú lehet, ahogy az alábbi képernyőképen látható:

  

  Ez akkor fordul elő, ha a csomópontok nem tudnak kommunikálni egymással.

• Resolution (Osztás)

  1. Jelentkezzen be a csomópont által üzemeltetett virtuális gépre (VM). Az Alkalmazás- és szolgáltatásnaplók>Integrációs modul területen nyissa meg az Eseménynaplót, és szűrje a hibanaplókat.

  2. Ellenőrizze, hogy egy hibanapló tartalmazza-e a következő hibát:

     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. Ha ezt a hibát látja, futtassa a következő parancsot egy parancssori ablakban:

     telnet 10.2.4.10 8060
     

  4. Ha a következő képernyőképen látható "Nem sikerült megnyitni a kapcsolatot a gazdagéphez" parancssori hibaüzenet jelenik meg, forduljon az informatikai részleghez a probléma megoldásához. Miután sikerült telnet-kapcsolatot létesíteni, forduljon a Microsoft támogatási szolgálatához, ha továbbra is problémái vannak az integrációs modul csomópontjának állapotával.

     

  5. Ellenőrizze, hogy a hibanapló tartalmazza-e a következő bejegyzést:

     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. A hiba elhárításához próbálkozzon az alábbi módszerek egyikével, vagy mindkettővel:

     • Helyezze a csomópontokat ugyanabba a tartományba.
     • Adja hozzá az IP-címet a gazdagép-leképezéshez az üzemeltetett virtuális gép összes gazdagépfájljában.

Csatlakozás helyi integrációs modul és az adat-előállító vagy az Azure Synapse-példány, illetve a saját üzemeltetésű integrációs modul és az adatforrás vagy fogadó közötti Csatlakozás

A hálózati kapcsolattal kapcsolatos probléma elhárításához tudnia kell, hogyan gyűjtheti össze a hálózati nyomkövetést, hogyan használhatja azt, és elemezheti a Microsoft Network Monitor (Netmon) nyomkövetést , mielőtt valós esetekben alkalmazhatja a Netmon-eszközöket a saját üzemeltetésű integrációs modulból.

• Hibajelenségek

  Előfordulhat, hogy időnként meg kell oldania bizonyos csatlakozási problémákat a saját üzemeltetésű integrációs modul és az adat-előállító vagy az Azure Synapse-példány között az alábbi képernyőképen látható módon, illetve a saját üzemeltetésű integrációs modul és az adatforrás vagy fogadó között.

  

  Bármelyik példány esetében az alábbi hibák léphetnek fel:

  • „A másolás a következő hibával meghiúsult: Type=Microsoft.DataTransfer.Common.Shared.HybridDeliveryException,Message=Cannot connect to SQL Server: 'IP address'”

  • „Egy vagy több hiba történt. Hiba történt a kérelem küldése során. Az alapul szolgáló kapcsolat lezárult: Váratlan hiba történt egy fogadáskor. Nem sikerült beolvasni az átviteli kapcsolatból származó adatokat: A távoli gazdagép kényszerített módon bezárt egy meglévő kapcsolatot. A távoli gazdagép kényszerített módon bezárt egy meglévő kapcsolatot (tevékenységazonosító).”

• Resolution (Osztás)

  Ha az előző hibákat tapasztalja, az ebben a szakaszban található utasításokat követve háríthatja el őket.

  • Netmon-nyomkövetés gyűjtése elemzéshez:

    1. A szűrőt beállíthatja úgy, hogy a kiszolgálóról az ügyféloldalra visszaállítsa az alaphelyzetbe állítást. Az alábbi példa képernyőképen láthatja, hogy a kiszolgálóoldal a Data Factory-kiszolgáló.

       

    2. Amikor megkapja az alaphelyzetbe állítási csomagot, a beszélgetést a Transmission Control Protocol (TCP) követésével találja meg.

       

    3. A szűrő eltávolításával kérje le az ügyfél és a Data Factory-kiszolgáló közötti beszélgetést.

       

  • Az összegyűjtött Netmon-nyomkövetés elemzése azt mutatja, hogy az Élettartam (TTL)) összesen 64. Az IP Time to Live (TTL) és a Hop Limit Basics (TTL) című cikkben említett értékek alapján az alábbi listában látható, hogy a linuxos rendszer alaphelyzetbe állítja a csomagot, és a leválasztást okozza.

    Az alapértelmezett TTL- és ugráskorlátértékek különböző operációs rendszerek között változnak, az alábbiak szerint:

    • Linux kernel 2.4 (2001 körül): 255 TCP, User Datagram Protocol (UDP) és Internet Control Message Protocol (ICMP)
    • Linux kernel 4.10 (2015): 64 TCP, UDP és ICMP esetén
    • Windows XP (2001): 128 TCP, UDP és ICMP esetén
    • Windows 10 (2015): 128 TCP, UDP és ICMP esetén
    • Windows Server 2008: 128 TCP, UDP és ICMP esetén
    • Windows Server 2019 (2018): 128 TCP, UDP és ICMP esetén
    • macOS (2001): 64 TCP, UDP és ICMP esetén

    

    Az előző példában a TTL 64 helyett 61-ként jelenik meg, mivel amikor a hálózati csomag eléri a célját, különböző ugrásokon kell áthaladnia, például útválasztókon vagy hálózati eszközökön. Az útválasztók vagy hálózati eszközök száma a végső TTL előállításához lesz levonva.

    Ebben az esetben láthatja, hogy a TTL 64 használatával alaphelyzetbe állítás küldhető a Linux rendszerből.

  • Annak ellenőrzéséhez, hogy az alaphelyzetbe állítási eszköz honnan származhat, ellenőrizze a negyedik ugrást a saját üzemeltetésű integrációs modulból.

    Hálózati csomag Linux A rendszerből TTL 64 -> B TTL 64 mínusz 1 = 63 -> C TTL 63 mínusz 1 = 62 -> TTL 62 mínusz 1 = 61 saját üzemeltetésű IR

  • Ideális esetben a TTL-ugrások száma 128, ami azt jelenti, hogy a Windows operációs rendszer futtatja a data factory-példányt. Az alábbi példában látható 128 mínusz 107 = 21 ugrás, ami azt jelenti, hogy a csomaghoz 21 ugrást küldtek a data factory-példányból a helyi integrációs modulnak a TCP 3 kézfogás során.

    

    Ezért fel kell vennie a kapcsolatot a hálózati csapattal, hogy ellenőrizze, mi a negyedik ugrás a saját üzemeltetésű integrációs modulból. Ha a tűzfalról van szó, mint a Linux rendszer esetén, ellenőrizze a naplókat, hogy az eszköz miért állítja vissza a csomagot a TCP 3 kézfogás után.

    Ha nem biztos abban, hogy hol kell kivizsgálnia, próbálja meg lekérni a Netmon-nyomkövetést a saját üzemeltetésű integrációs modulból és a tűzfalról is a problémás időszakban. Ez a módszer segít megállapítani, hogy melyik eszköz alaphelyzetbe állíthatta a csomagot, és mi okozta a leválasztást. Ebben az esetben a hálózati csapatnak is fel kell vennie a kapcsolatot a továbblépéshez.

A Netmon-nyomkövetés elemzése

Feljegyzés

A Netmon-nyomkövetésre az alábbi utasítások vonatkoznak. Mivel a Netmon nyomkövetés jelenleg nem támogatott, erre a célra használhatja a Wiresharkot.

Amikor megpróbál telnetezni a 8.8.8.8 888-at az összegyűjtött Netmon-nyomkövetéssel, a nyomkövetésnek a következő képernyőképeken kell megjelennie:

Az előző képek azt mutatják, hogy nem sikerült TCP-kapcsolatot létesíteni a 8.8.8.8-es kiszolgálóoldallal a 888-es porton, ezért két SynReTransmit további csomagot lát. Mivel a forrás Standard kiadás LF-HOST2 nem tudott csatlakozni a 8.8.8.8-hoz az első csomaggal, továbbra is megpróbálja létrehozni a kapcsolatot.

Tipp.

A kapcsolat létrehozásához próbálkozzon a következő megoldással:

1. Válassza a Terhelésszűrő>standard szűrőcímek>>IPv4-címek lehetőséget.
2. A szűrő alkalmazásához írja be az IPv4.Address == 8.8.8.8 értéket, majd válassza az Alkalmaz lehetőséget. Ezután látnia kell a helyi gép és a cél 8.8.8.8 közötti kommunikációt.

A sikeres forgatókönyvek az alábbi példákban láthatók:

• Ha a telnet 8.8.8.8 53-at probléma nélkül meg tudja oldani, a TCP 3 kézfogás sikeres lesz, és a munkamenet TCP 4 kézfogással fejeződik be.

  

  

• Az előző TCP 3 kézfogás a következő munkafolyamatot hozza létre:

  

• A munkamenet befejezéséhez szükséges TCP 4 kézfogást a következő munkafolyamatok szemléltetik:

  

  

A Microsoft e-mail-értesítése a hálózati konfiguráció frissítéséről

A következő e-mail-értesítést kaphatja, amely azt javasolja, hogy frissítse a hálózati konfigurációt, hogy 2020. november 8-ig engedélyezze az Azure Data Factory új IP-címeivel való kommunikációt:

Annak meghatározása, hogy ez az értesítés hatással van-e Önre

Ez az értesítés a következő forgatókönyvekre vonatkozik:

1. forgatókönyv: Kimenő kommunikáció egy helyi integrációs modulból, amely a vállalati tűzfal mögött fut a helyszínen

Hogyan állapítható meg, hogy érintett-e:

• Ez nem érinti, ha olyan teljes tartományneveken (FQDN-eken) alapuló tűzfalszabályokat határoz meg, amelyek a tűzfalkonfiguráció és az IP-címek engedélyezési listájának beállításában leírt megközelítést használják.

• Ez akkor jelentkezik , ha explicit módon engedélyezi a kimenő IP-címek engedélyezési listáját a vállalati tűzfalon.

  Ha érintett, hajtsa végre a következő műveletet: 2020. november 8-ig értesítse a hálózati infrastruktúra csapatát, hogy frissítse a hálózati konfigurációt a legújabb data factory IP-címek használatára. A legújabb IP-címek letöltéséhez lépjen a Szolgáltatáscímkék felfedezése elemre letölthető JSON-fájlok használatával.

2. forgatókönyv: Kimenő kommunikáció egy saját üzemeltetésű integrációs modulból, amely egy Azure-beli virtuális gépen fut egy ügyfél által felügyelt Azure-beli virtuális hálózaton

Hogyan állapítható meg, hogy érintett-e:

• Ellenőrizze, hogy rendelkezik-e kimenő hálózati biztonsági csoportra (NSG) vonatkozó szabályokkal egy saját üzemeltetésű integrációs modult tartalmazó magánhálózatban. Ha nincsenek kimenő korlátozások, nem érinti a probléma.

• Ha kimenő szabálykorlátozásokkal rendelkezik, ellenőrizze, hogy szolgáltatáscímkéket használ-e. Ha szolgáltatáscímkéket használ, az nem érinti. Semmit sem kell módosítania vagy hozzáadnia, mert az új IP-címtartomány a meglévő szolgáltatáscímkék alatt található.

  

• Ez akkor jelentkezik , ha kifejezetten engedélyezi a kimenő IP-címek engedélyezési listáját az NSG-szabályok beállításában az Azure-beli virtuális hálózaton.

  Ha érintett, hajtsa végre a következő műveletet: 2020. november 8-ig értesítse a hálózati infrastruktúra csapatát, hogy frissítse az Azure-beli virtuális hálózati konfiguráció NSG-szabályait a legújabb data factory IP-címek használatára. A legújabb IP-címek letöltéséhez lépjen a Szolgáltatáscímkék felfedezése elemre letölthető JSON-fájlok használatával.

3. forgatókönyv: Kimenő kommunikáció az SSIS integrációs modulból egy ügyfél által felügyelt Azure-beli virtuális hálózaton

Hogyan állapítható meg, hogy érintett-e:

• Ellenőrizze, hogy rendelkezik-e kimenő NSG-szabályokkal az SQL Server Integration Services (SSIS) integrációs modult tartalmazó magánhálózaton. Ha nincsenek kimenő korlátozások, nem érinti a probléma.

• Ha kimenő szabálykorlátozásokkal rendelkezik, ellenőrizze, hogy szolgáltatáscímkéket használ-e. Ha szolgáltatáscímkéket használ, az nem érinti. Semmit sem kell módosítania vagy hozzáadnia, mert az új IP-címtartomány a meglévő szolgáltatáscímkék alatt található.

• Ez akkor jelentkezik , ha kifejezetten engedélyezi a kimenő IP-címek engedélyezési listáját az NSG-szabályok beállításában az Azure-beli virtuális hálózaton.

  Ha érintett, hajtsa végre a következő műveletet: 2020. november 8-ig értesítse a hálózati infrastruktúra csapatát, hogy frissítse az Azure-beli virtuális hálózati konfiguráció NSG-szabályait a legújabb data factory IP-címek használatára. A legújabb IP-címek letöltéséhez lépjen a Szolgáltatáscímkék felfedezése elemre letölthető JSON-fájlok használatával.

Nem hozható létre megbízható kapcsolat a biztonságos SSL-/TLS-csatornához

• Hibajelenségek

  A saját üzemeltetésű integrációs modul nem tudott csatlakozni az Azure Data Factoryhez vagy az Azure Synapse szolgáltatáshoz.

  Ha a Windows>Eseménynapló (naplók)>Alkalmazások és szolgáltatások integrációs modulba való belépése után ellenőrzi a saját üzemeltetésű integrációs>modul eseménynaplóját, a következő hibaüzenet jelenik meg.

  "A mögöttes kapcsolat lezárult: Nem sikerült megbízhatósági kapcsolatot létesíteni az SSL/TLS biztonságos csatornához. A távoli tanúsítvány az érvényesítési eljárás szerint érvénytelen.”

  A szolgáltatás kiszolgálói tanúsítványa úgy ellenőrizhető a legegyszerűbben, ha megnyitja a szolgáltatás URL-címét a böngészőben. Nyissa meg például az ellenőrzőkiszolgáló tanúsítvány hivatkozását (https://eu.frontend.clouddatahub.net/) azon a gépen, amelyen a saját üzemeltetésű integrációs modul telepítve van, majd tekintse meg a kiszolgálótanúsítvány adatait.

  

  

• Ok

  Ennek a problémának két oka lehet:

  • 1\. ok: A szolgáltatás kiszolgálói tanúsítványának legfelső szintű hitelesítésszolgáltatója nem megbízható azon a gépen, amelyen a helyi integrációs modul telepítve van.
  • 2\. ok: Proxyt használ a környezetében, a szolgáltatás kiszolgálói tanúsítványát a proxy lecseréli, a lecserélt kiszolgálói tanúsítványt pedig nem tekinti megbízhatónak az a gép, amelyen a helyi integrációs modul telepítve van.

• Resolution (Osztás)

  • Az 1. ok esetén: Győződjön meg arról, hogy a szolgáltatás kiszolgálói tanúsítványát és tanúsítványláncát megbízhatónak tekinti a gép, amelyen a helyi integrációs modul telepítve van.
  • A 2. ok esetén: Minősítse megbízhatónak a lecserélt legfelső szintű hitelesítésszolgáltatót a helyi integrációs modult futtató gépen, vagy konfigurálhatja úgy a proxyt, hogy ne cserélje le a szolgáltatás kiszolgálói tanúsítványát.

  További információ a tanúsítványok megbízhatóként való beállításáról Windows rendszeren: Megbízható főtanúsítvány telepítése.

• További információ
  Új, a DigiCertből aláírt SSL-tanúsítványt tettünk elérhetővé. Ellenőrizze, hogy a DigiCert Global Root G2 megtalálható-e a megbízható legfelső szintű hitelesítésszolgáltatóban.

  

  Ha nem szerepel a megbízható legfelső szintű hitelesítésszolgáltatóban, töltse le ide.

Kapcsolódó tartalom

A hibaelhárítással kapcsolatos további segítségért próbálja ki a következő erőforrásokat:

• Data Factory-blog
• Data Factory-funkciókérések
• Azure-videók
• Microsoft Q&A lap
• Stack overflow fórum a Data Factory számára
• Twitter-információk a Data Factoryről
• Az adatfolyamok teljesítményének leképezése – útmutató