Kafka puhverserveri kaudu: bootstrap töötab, brokeriühendused ebaõnnestuvad
Selgitab, miks õnnestunud Kafka bootstrap-ühendus ei taga puhverserveri kaudu juurdepääsu kõigile avastatud brokeritele.
Bootstrap-ühendus võib õnnestuda, samal ajal kui Kafka klient ei saa ikka veel toota ega tarbida. Bootstrap-serverid aitavad kliendil klasteri avastada; need ei ole tingimata ainsad lõpp-punktid, millega klient ühendust loob.
Brokeri metaandmed sisaldavad aadresse, mida kasutatakse hilisemate ühenduste jaoks. Kui need nimed või pordid ei ole kavandatud puhverserveri marsruudi kaudu kättesaadavad, ei lahenda esimene õnnestunud ühendus ülejäänud tööd.
Lugege reklaamitud lõpp-punkte
Võrrelge bootstrap-aadressi brokeri aadressidega, mille klient tegelikult saab. Avalik bootstrap-i alias võib viia privaatsete reklaamitud nimedeni ja ühe kohaliku pordi edastamine ei kirjuta automaatselt ümber iga aadressi metaandmetes.
Tehke kindlaks ka puhverserveri tee, mida kliendi teostus toetab. Java süsteemi SOCKS-omadus ei taga, et teegi NIO-põhine transport kasutab JDK Socketi puhverserveri mehhanismi. Kontrollige tegelikku Kafka klienti ja võrguintegratsiooni, selle asemel et eeldada, et iga Java socket järgib sama seadet.
Puhverserverist teadlik klient vajab lubatud marsruuti asjakohaste brokeri lõpp-punktideni. Võrgutasandi lahendus vajab vastavat kättesaadavust ja nimede lahendamist. Need on erinevad lahendused ja kumbagi ei anta lihtsalt puhverserveri loetlemisega bootstrap-serverina.
Hoidke turbeprotokolli ja autentimise seaded eraldi. Puhverserver võib luua TCP tee, samal ajal kui TLS-i identiteet, SASL-autentimine või brokeri autoriseerimine ikka ebaõnnestub.
Diagnoosimiseks märkige, milline lõpp-punkt ebaõnnestus ja kas see tuli staatilisest konfiguratsioonist või tagastatud metaandmetest. See eristus kitsendab probleemi palju rohkem kui juba kättesaadava lõpp-punkti korduv muutmine.