Tervitused ja kõigepealt mõned laulusõnad. Mõnikord kadestan oma kolleege, kes töötavad kaugtööl – see on suurepärane võimalus töötada ükskõik millisest Interneti-ühendusega maailma otsast, puhkus igal ajal, vastutus projektide ja tähtaegade eest ning mitte olla 8-17 kontoris. Minu ametikoht ja töökohustused välistavad praktiliselt võimaluse andmekeskusest pikaks ajaks eemal olla. Siiski juhtub aeg-ajalt selliseid huvitavaid juhtumeid, nagu allpool kirjeldatud, ja ma saan aru, et on vähe positsioone, kus sisemise tõrkeotsija loominguliseks väljenduseks on nii palju ruumi.
Väike lahtiütlemine – selle kirjutamise hetkel ei ole juhtum veel täielikult lahendatud, kuid arvestades tarnijate reageerimiskiirust, võib terviklik lahendus võtta kuid, kuid ma soovin oma järeldusi nüüd jagada. Loodan, kallid lugejad, et annate mulle selle kiirustamise andeks. Aga piisavalt vett – mis korpusel viga on?
Esiteks sissejuhatav märkus: on ettevõte (kus ma töötan võrguinsenerina), mis majutab kliendilahendusi VMWare'i privaatpilves. Enamik uusi lahendusi ühendub VXLAN-i segmentidega, mida haldab NSX-V – ma ei hinda, kui palju aega see lahendus mulle andis, lühidalt – palju. Mul õnnestus isegi oma kolleege koolitada NSX ESG seadistamisel ja väikeklientide lahendused võetakse kasutusele ilma minu osaluseta. Oluline märkus: meil on unicast replikatsiooniga juhttasand. Hüperviisorid on kahe liidesega ühendatud erinevate füüsiliste Juniper QFX5100 lülititega (monteeritud Virtual Chassis) ja marsruudiga, mis põhineb algsel virtuaalse pordi ajastuspoliitikal – see on täielikkuse huvides.
Kliendilahendused on väga mitmekesised: alates Windows IIS, kus kõik veebiserveri komponendid on installitud ühte masinasse, ulatub ka üsna suurteni – näiteks koormusega tasakaalustatud Apache veebiliidesed + LB MariaDB Galeras + jagatud serverid, mis on sünkroniseeritud GlusterFS-i abil. Peaaegu iga serverit tuleb eraldi jälgida ja mitte kõigil komponentidel pole avalikke aadresse. Kui olete selle probleemiga kokku puutunud ja teil on elegantsem lahendus, oleksin teie nõuannete eest tänulik.
Minu monitooringulahendus seisneb tulemüüri (Fortigate) “ühendamises” iga sisemise kliendivõrguga (+SNAT ja loomulikult ranged piirangud lubatud liikluse tüübile) ja sisemiste aadresside jälgimises – nii saavutatakse jälgimise teatav ühtlustamine ja lihtsustamine. saavutatud. Jälgimine ise toimub PRTG serveriklastrist. Seireskeem on umbes selline:
Kui me töötasime ainult VLAN-iga, oli kõik üsna tavaline ja töötas etteaimatavalt, nagu kellavärk. Pärast NSX-V ja VXLANi kasutuselevõttu seisime küsimuse ees: kas jälgimist on võimalik vanaviisi jätkata? Selle küsimuse esitamise ajal oli "kiireim" lahendus NSX ESG juurutamine ja VXLAN-i magistraalliidese ühendamine VTEP-võrguga. Kiire jutumärkides – kuna GUI kasutamine klientvõrkude seadistamiseks, siis SNAT-i ja tulemüüri reeglid võivad ja ühtlustada haldamist ühtsesse vSphere liidesesse, kuid minu arvates on see üsna tülikas ja muuhulgas piirab tõrkeotsingu tööriistade komplekti. Need, kes on kasutanud NSX ESG-d "päris" tulemüüri asendajana, on minu arvates nõus. Kuigi ilmselt oleks selline lahendus stabiilsem - kõik toimub ju ühe müüja raames.
Teine lahendus on kasutada NSX DLR-i sildrežiimis VLAN-i ja VXLAN-i vahel. Siin on minu meelest kõik selge - VXLAN-i kasutamisest saadav kasu läheb lihtsalt kaotsi - kuna sel juhul tuleb ikkagi VLAN-i jälgimisinstallatsiooniga ühendada. Muide, selle lahenduse väljatöötamise käigus tekkis mul probleem, kui DLR-i sild ei saatnud pakette virtuaalmasinasse, millega see samas hostis asus. Ma tean, ma tean - NSX-V raamatutes ja juhendites on otse öeldud, et NSX Edge'i jaoks tuleks eraldada eraldi klaster, aga see on raamatutes... Nii või teisiti, pärast paari kuud tugi, me ei lahendanud probleemi. Põhimõtteliselt sain toimingu loogikast aru - VXLAN-i kapseldamise eest vastutavat hüperviisori kerneli moodulit ei kasutatud, kui DLR ja jälgitav server olid samas hostis, kuna liiklus ei lahku hostist ja loogiliselt võttes tuleks see ühendada VXLAN-i segmendile – kapseldamist pole vaja. Toega leppisime virtuaalse liidese vdrPort kasuks, mis ühendab loogiliselt üleslinke ja teostab ka sildamist/kapseldamist - siin jäi silma sissetuleva liikluse lahknevus, mille kallal praegusel juhul tööle võtsin. Aga nagu öeldud, ma seda juhtumit lõpuni ei viinud, kuna mind viidi üle teise projekti ja haru oli esialgu tupiktee ning erilist soovi seda arendada polnud. Kui ma ei eksi, siis probleem ilmnes versioonides NSX ja 6.1.4 ja 6.2.
Ja siis - bingo! Fortinet teatab emakeelena . Ja mitte ainult point-to-point või VXLAN-over-IPSec, mitte tarkvara VLAN-VXLAN sildamine – seda kõike hakati juurutama juba versioonis 5.4 (ja esitati ka muudes versioonides). ), kuid tõeline unicast juhttasandi tugi. Lahenduse juurutamisel tekkis veel üks probleem - perioodiliselt kontrollitavad serverid “kadusid” ja ilmusid seejärel jälgimisse, kuigi virtuaalmasin ise oli elus. Põhjus, nagu selgus, oli see, et unustasin VXLAN-liidesel Pingi lubada. Klastrite tasakaalustamise käigus teisaldati virtuaalsed masinad ja koos Pingiga viidi lõpule vMotion, mis näitab uut ESXI hosti, kuhu masin oli kolinud. Minu rumalus, aga see probleem õõnestas taas usaldust tootja – antud juhul Fortineti – toe vastu. Ma ei ütle, et iga VXLANiga seotud juhtum algab küsimusega "kus on teie seadetes VLAN-VXLAN softswitch?" Seekord soovitati mul MTU-d muuta - see on Pingi jaoks, mis on 32 baiti. Seejärel "mängige ringi" poliitikas tcp-send-mss ja tcp-receive-mss - VXLAN-i jaoks, mis on kapseldatud UDP-sse. Pheh, vabandust – keeb. Üldiselt lahendasin selle probleemi üksinda.
Pärast testliikluse edukat kasutuselevõttu otsustati see lahendus kasutusele võtta. Ja tootmises selgus, et päeva või paari pärast langes kõik, mida VXLANi kaudu jälgiti, järk-järgult. Liidese deaktiveerimine/aktiveerimine aitas, kuid ainult ajutiselt. Pidades silmas toe tootmise aeglust, alustasin omapoolset tõrkeotsingut - lõppude lõpuks on minu ettevõte, minu võrk minu vastutus.
Veaotsingu käik on spoileri all. Kes on väsinud kirjadest ja praalimisest, jätke see vahele ja liikuge edasi järelanalüüsi juurde.
Tõrkeotsingu edenemineTäname lugemise eest – jätkame!
Niisiis, jälgimine töötab mõnda aega, siis kukub iseenesest ära. See tähendab, et suure tõenäosusega tulemüüripoliitikaga probleeme pole. Kuna aga puutusin kokku süsteemiprotsesside riputamise probleemiga Fortigate'i versioonides 5.6+, vaatame esmalt silumisvoo diagnoosimist - ootuspäraselt lubatakse liiklus ja liides lahkub ning ootuspäraselt ei vasta midagi. Nii et me kaevame virna allapoole. Kahjuks peame aadressid peitma, isegi kui need on RFC1918, kuid ma loodan anda protsessile mõistmiseks piisava kirjelduse. VXLAN-i sees oleva serveri aadress on x.x.x.15, Fortigate'i liides x.x.x.254, kõik muud aadressid kuuluvad VTEP-võrku.
VXLAN-kapseldatud pakettide edukaks edastamiseks on vaja õiget teavet mitmes tabelis. Ülekatte jaoks on need ARP ja OVSDB, aluskatte jaoks ARP ja CAM. Fortigate VXLANi puhul on FDB OVSDB. Alustame sealt:
fortigate (root) #diag sys vxlan fdb list vxlan-LS
mac=00:50:56:8f:3f:5a state=0x0002 flags=0x00 remote_ip=у.у.у.47 port=4789 vni=5008 ifindex=7
Siin on kõik üsna lihtne – virtuaalmasina MAC-aadress peab olema VTEP-is aadressiga u.u.u.47. Vaadates ESXI klastri sisu ja sätteid, leian, et virtuaalmasina MAC on õige, samuti VTEP-aadress. Kontrollin fortiku CAM/ARP tabelit - jällegi ühtib kõik ESXI hosti seadetega:
fortigate (root) #get sys arp | grep у.у.у.47
у.у.у.47 0 00:50:56:65:f6:2c dmz
Tabelid on õiged ja liiklus lahkub – äkki pole probleem Fortigates? Juniperi liikluse sisselülitamise analüüsi jätsin meelega vahele - loogiliselt võttes tuleks tõrkeotsingu järgmine samm läbi viia, aga minu võrk on lihtne - VTEP jaoks vaid üks VLAN ja kõik komponendid on otse ühendatud. Lisaks mäletan juhtumit DLR-silla, VDR-i ja liikluse kaotsiminekuga – hakkan ESXI hosti nuusutama ja samal ajal loon VMWare'i jaoks ümbrist. MAC-i all "97:6e" kuulub fortikile, vmnic1 on liides, millel on VTEP aadressiga u.u.u.47 snifim mõlemas suunas "--dir 2":
pktcap-uw --uplink vmnic1 --vni 5008 --mac 90:6c:ac:a9:97:6e --dir 2 -o /tmp/monitor.pcap
Edenemine – nuusutamisel näen ARP päringut ja sissetulevat vastust. Annan ainult ARP vastuse ja seal on kõik õige. Ma ei maininud seda, kuid kogu selle aja pingib jälgimisserver aadressi x.x.x.15 – kus on ICMP liiklus? Mäletan, et mul on kaks üleslinki. Siin saate vastu vaielda ja öelda, et allika virtuaalne port on sama (minu meeskonnatöö poliitika), st sama vNIC-i jaoks tuleks valida sama üleslink, kuid kuna ma olen hostis, ei ole erineva üleslingi kontrollimine probleem:
pktcap-uw --uplink vmnic4 --vni 5008 --mac 90:6c:ac:a9:97:6e --dir 2 -o /tmp/monitor.pcap
Fortigate'ilt tulevad päringud, kuid vastust pole. See tähendab, et probleem ei ole Fortigate'is. Noh, see on kõik - ma arvan - jälle sama probleem VDR-i liikluse puudumisega, jälle kulub paar kuud, et juhtum õiges suunas suunata. Paari päeva pärast, jahtununa ega tahtnud rippumist leppida, otsustasin protsessi kiirendamiseks tuge juurde kaevata. Ja siis "kogemata" langeb mu pilk Etherneti aluskatte kapseldamisele. Tsaar pole päris ja VTEP-i MAC-aadress ei ühti tema IP-ga. Lähtestan nulli, nuuskan, kaevan - see on tõsi, see pole tõsi. Ma annan ARP-tabeli üksteise kõrvale, et oleks lihtsam võrrelda. Pange tähele esimest Etherneti kapslit ülaloleval pildil:
fortigate (root) #get sys arp | grep у.у.у.47
у.у.у.47 0 00:50:56:65:f6:2c dmz
fortigate (root) #get sys arp | grep у.у.у.42
у.у.у.42 0 00:50:56:6a:78:86 dmz
Nii jõuame selleni, et pärast virtuaalmasina migreerimist üritab Fortigate saata liiklust VTEP-ile (õigest) VXLAN-i FDB-st, kuid kasutab valet DST MAC-i ja seda vastuvõtva hüperviisori liidese tõttu langeb liiklus eeldatavasti. Veelgi enam, ühel juhul neljast kuulus see MAC algsele hüperviisorile, millest masina migratsioon algas.
Eile sain Fortineti tehniliselt toelt kirja - minu puhul avastati viga 615586. Ma tõesti ei tea, kas rõõmustada või kurvastada: ühest küljest pole probleem seadetes, teisalt parandus tuleb ainult püsivara värskendusega või parimal juhul järgmisega. ChSV-d toidab ka teine viga, mille avastasin eelmisel kuul, kuigi sel ajal HTML5 GUI vSphere'is. Noh, lihtsalt müüjate kohalik QA osakond...
Ma julgeksin arvata järgmist:
1 - multisaate juhttasapind tõenäoliselt ei allu kirjeldatud probleemile - lõppude lõpuks saadakse VTEP MAC-aadressid selle rühma IP-aadressilt, millele liides on tellitud.
2 - tõenäoliselt fortik probleem võrguprotsessori mahalaadimise seanssidel (umbes analoogne CEF-iga) - kui edastate iga paketi protsessori kaudu, kasutatakse tabeleid, mis sisaldavad õiget - vähemalt visuaalselt - teavet. Seda oletust toetab asjaolu, et see aitab liidese sulgeda/avada või oodata mõnda aega – üle 5 minuti.
3 - meeskonnatöö poliitika muutmine, näiteks selgesõnaliseks tõrkesiirdeks, või LAG juurutamine ei lahenda probleemi, kuna allika hüperviisori MAC oli kapseldatud pakettides kinni.
Selle valguses võin jagada, et hiljuti avastasin , kus ühes artiklis oli kirjas, et stetfull tulemüürid ja vahemällu salvestatud andmeedastusmeetodid on kargud. Noh, ma pole IT-alal piisavalt kogenud, et seda öelda, ja pealegi ei nõustu ma kohe kõigi ajaveebiartiklite väidetega. Kuid miski ütleb mulle, et Ivani sõnades on tõtt.
Tänan tähelepanu eest! Vastan meeleldi küsimustele ja kuulen konstruktiivset kriitikat.
Allikas: www.habr.com
