VXLAN NSX-V-s — lahendame underlay probleeme

Tere! Esiteks pisut lüürikat. Vahel kadestan kolleege, kes töötavad kaugelt — see on tõeliselt suurepärane, et saab töötada mistahes maailma nurgast, kus internet on olemas, võtta puhkust igal ajal, kanda vastutust projektide ja tähtaegade eest, mitte istuda kontoris kella 8–17. Minu ametikoht ja töökohustused praktiliselt kõrvaldavad võimaluse pikka aega andmekeskuses eemal olla. Siiski juhtub vahel huvitavaid juhtumeid, nagu allpool kirjeldatud, ja ma mõistan, et on väga vähe ametikohti, kus on nii suur loominguline vabadus sisemise troubleshooter’i jaoks.

Kere lühiülevaade — artikli kirjutamise ajal pole juhtum täielikult lahendatud, kuid arvestades tarnijate vastamise kiirus, võib täielik lahendus võtta veel kuid, kuid tahan oma leidudega juba nüüd jagada. Loodan, kallid lugejad, et andestate mulle selle kiirustamise. Aga piisavalt juttu — mis on juhtumiga?

Alustame sissejuhatusega: on ettevõte (koht, kus töötan võrgusüsteemide insenerina), mis majutab kliendilahendusi privaatse VMWare pilve keskkonnas. Enamik uusi lahendusi ühendatakse VXLAN-segmentidega, mida haldab NSX-V — ei hakka hindama, kui palju aega see lahendus mulle säästis, lühidalt öeldes — palju. Olen suutnud isegi koolitada kolleege NSX ESG seadmes ja väiksed kliendilahendused seadistatakse minu osaluseta. Tähtis märkida, et meie juhtimistasand töötab unicast-replikatsiooniga. Hübriidserverid on ühendatud redundantsete kahe liidese kaudu erinevatesse füüsilistesse Juniper QFX5100 lülititesse (kokku pandud Virtual Chassis) ja marsruutimise põhjaliku poliitika kaudu, mis põhineb algse virtuaalse porte — see on informatsiooni täiendamiseks.

Kliendilahendused on väga mitmekesised: alates Windows IIS-st, kus kõik veebiserveri komponendid on ühel masinal, kuni üsna suurteni — näiteks tasakaalustatud Apache veebifront + LB MariaDB Galera + jagamisserverid, mis on sünkroonitud GlusterFS-i abil. Praktiselt igat serverit tuleb jälgida eraldi, ja mitte kõigil komponentidel pole avalikke aadresse — kui olete selle probleemiga kokku puutunud ja teil on elegantsem lahendus, oleksin tänulik soovituste eest.
Minu jälgimislahendus seisneb tulemüüri (Fortigate) „ühendamises“ iga sisemise kliendivõrguga (+SNAT ja muidugi ranged piirangud lubatud liikluse tüübi osas) ning sisemiste aadresside jälgimises - nii saavutatakse teatud ühtlustamine ja jälgimise lihtsustamine. Jälgimine toimub PRTG serverite klastri kaudu. Jälgimisskeem on umbes selline:

Kuni kasutasime ainult VLAN-e, toimis kõik üsna tavaliselt ja ennustatavalt, nagu kell. Pärast NSX-V ja VXLAN rakendamist seisisime küsimuse ees - kas on võimalik jätkata jälgimist vanaviisi? Selle küsimuse ajal oli kõige „kiirem“ lahendus NSX ESG juurutamine ja VXLAN trunk-liidese ühendamine VTEP võrguga. Kiire, aga kahtluse alla - kuna GUI kasutamine kliendivõrkude, SNAT-i ja tulemüüri reeglite seadistamiseks võib küll ühtlustada haldust ühes vSphere liideses, kuid minu arvates on see üsna mahukas ja lisaks piirab see tõrkeotsingu tööriistade komplekti. Need, kes on kasutanud NSX ESG-d „päris“ tulemüüri asendajana, arvan, et nõustuvad. Kuigi selline lahendus oleks ilmselt stabiilsem - sest kõik toimub ühe tarnija raames.

Teine lahendus on kasutada NSX DLR-i sillerežiimis VLAN ja VXLAN vahel. Siin on kõik selge - kasulikkus VXLAN-i kasutamisel kaob, kuna selles olukorras tuleb ikkagi VLAN-i tõmmata monitoorimise paigalduseni. Muide, selle lahenduse töötamise käigus kohtasin probleemi, kui DLR-sild ei saatnud pakette virtuaalmasinale, mis asus samal hostil. Tean, tean - NSX-V raamatutes ja juhendites on selgelt öeldud, et NSX Edge jaoks peab olema eraldatud klaster, aga need on ju vaid raamatud... Igal juhul ei lahendanud me pärast paari kuud toega probleemi. Lõppkokkuvõttes sain aru, kuidas asjad toimivad - hüperviisori tuumamoodul, mis vastutab VXLAN-i kapseldamise eest, ei aktiveerunud, kui DLR ja jälgitav server asusid samal hostil, kuna liiklus ei lahkunud hostist ja loogika järgi pidi olema ühendatud VXLAN-segmendiga - kapseldamine ei olnud vajalik. Toega jõudsime koos virtualiseeritud liidese vdrPortini, mis loogiliselt ühendab ülesvoolud ja teostab sildamise/kapseldamise - seal märgati sissetuleva liikluse puhul vastuolu, millega ma hakkasin selles olukorras tegelema. Kuid nagu öeldud, ei viime selleni lõpuni, kuna mind suunati teisele projektile ja see teema oli algusest peale ummiktee, seega polnud erilist soovi selle arendamiseks. Kui ma ei eksi, siis probleemi täheldati NSX-i versioonides 6.1.4 ja 6.2.

Ja siin - bingo! Fortinet kuulutab välja natiivse VXLAN-i toe. Ja mitte lihtsalt point-to-point või VXLAN-over-IPSec, mitte tarkvaraline VLAN-VXLAN sillaga - seda hakati rakendama juba versioonist 5.4 (ja see on esitatud ka teiste tootjate), ja tegelikku unicast control plane'i tuge. Lahenduse rakendamisel kohtasin veel ühte probleemi — kontrollimiseks mõeldud serverid kadusid perioodiliselt jälgimisest, kuigi virtuaalmasin ise töötas. Põhjuseks oli see, et ma unustasin lubada Ping'i VXLAN-liideses. Klastrite taaskirjastamise käigus liikusid virtuaalmasinad ringi, ja Ping lõpetas vMotion'i, et tähistada uut ESXI hosti, kuhu masin üle viidi. Rumalus, aga see probleem viis veel kord tootja — seekord Fortinet — toetuseks usalduse kadumisele. Ma ei mainigi, et iga VXLAN-iga seotud juhtum algab küsimusega

Võttes edukalt testi liikluse, otsustati lahendust rakendada. Prodaktsioonis selgus, et pärast päeva või kahte lakkab kõik, mida VXLAN-i kaudu jälgitakse, järk-järgult töötamast. Liidese deaktiveerimine/aktiveerimine aitas, kuid ainult ajutiselt. Mäletades tootja toe aeglust, alustasin probleemide lahendamist ise — lõpuks on minu ettevõte, minu võrk — minu vastutus.

Probleemide lahendamise käik. Kes on tähed ja uhkustamisest väsinud — jätke vahele ja minge post-analüüsi juurde.

Probleemide lahendamise käikAitäh, et jätkasite lugemist — jätkame!

Nii et jälgimine töötab mõnda aega, siis kaob see ise. See tähendab, et tulemüüripoliitikates ei ole tõenäoliselt probleeme. Siiski, kuna olen kokku puutunud süsteemi protsesside peatumise probleemidega Fortigate versioonides 5.6+, vaatame esmalt 'diagnose debug flow' — ootuspäraselt lahendatakse liiklus ja see liigub liidese kaudu, kuid vastust ei tule. Tähendab, kaevume edasi virna. Kahjuks tuleb peita aadresse isegi RFC1918, kuid loodan, et protsess on piisava selgitusega varustatud arusaamiseks. Server VXLAN-i sees on aadress x.x.x.15, Fortigate'i liidese aadress x.x.x.254, kõik teised aadressid kuuluvad VTEP-võrku.

VXLAN-iga kapseldatud pakettide edastamiseks on vajalik korrektne teave mitmes tabelis. Overlay jaoks on need ARP ja OVSDB, underlay puhul ARP ja CAM. Fortigate'i puhul on VXLAN FDB ja OVSDB sama asi. 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

Asjad on siin üsna lihtsad — virtuaalmasina MAC-aadress peab olema VTEP-is, mille aadress on у.у.у.47. Kontrollides ESXI klastrite sisu ja seadeid, leian, et virtuaalmasina MAC on õige, samuti VTEP aadress. Kontrollin CAM/ARP tabelit Fortigate'il — kõik sobib ESXI hosti seadistustega:

fortigate (root) #get sys arp | grep у.у.у.47
у.у.у.47 0 00:50:56:65:f6:2c dmz

Tabelid on õiged ja liiklus läheb välja — äkki probleem ei ole Fortigate'is? Olin tahtlikult vahele jätnud liikluse lülitamise analüüsi Juniper'is — loogika ütleb, et järgmine tõrkeotsimise samm peaks olema seal, kuid minu võrk on lihtne — ainult üks VLAN VTEP jaoks ja kõik komponendid on otseselt ühendatud. Lisaks tuletan meelde juhtumit DLR-sillaga, VDR ja kadunud liiklusega — lähen snuffima ESXI hostis, samal ajal loon juba juhtumi VMWare'ile. Allpool oleva MAC aadress 97:6e kuulub Fortigate'ile, vmnic1 on liides, millel on VTEP aadressiga у.у.у.47; snuffin mõlemast suunast "—dir 2":

pktcap-uw --uplink vmnic1 --vni 5008  --mac 90:6c:ac:a9:97:6e --dir 2 -o /tmp/monitor.pcap

Eedukus — snuffimisel näen ARP päringut ja saabuvat vastust. Toon välja ainult ARP vastuse ja seal on kõik õige. Ma ei maininud, kuid kogu selle aja jälgib monitooringuserver aadressi х.х.х.15 — kus on ICMP liiklus? Tuletan meelde, et mul on kaks uplinki. Siin võib vaielda ja öelda, et virtuaalse allika port on sama (minu teaming policy), ehk siis sama vNIC peab valima sama uplinki, kuid kuna ma olen hostis, ei ole teise uplinki kontrollimine probleem:

pktcap-uw --uplink vmnic4 --vni 5008  --mac 90:6c:ac:a9:97:6e --dir 2 -o /tmp/monitor.pcap

Küsimused tulevad Fortigate'ilt, kuid vastust pole. See tähendab, et probleem ei ole Fortigate'is. Noh, mõtlen ma — jälle sama probleem kaotatud liiklusega VDR-is, jälle paar kuud juhtumiga õigesse suunda liikuda. Paar päeva hiljem jaotasin end maha ning soovides mitte leppida seisu jätkumisega, otsustasin leida rohkem sniffereid tugiteenusele, et protsessi kiirendada. Ja siis satub mu pilk 'juhuslikult' Ethernet'i kapseldamise underlay peale. Keiser pole tõeline ja VTEP MAC-aadress ei kattu tema IP-ga. Lükkan nulli, sniffin, kaevan — tõesti, et vale. Too ARP tabel käele, et oleks mugavam võrrelda. Pange tähele, et ülemises pildis on esimene Ethernet'i kapseldamine:

fortigate (root) #get sys arp | grep x.x.x.47
x.x.x.47 0 00:50:56:65:f6:2c dmz
fortigate (root) #get sys arp | grep x.x.x.42
x.x.x.42 0 00:50:56:6a:78:86 dmz

Nii et, mis meil kokkuvõttes on — pärast virtuaalse masina migreerimist proovib Fortigate suunata liiklust VTEP-le (korrektse) VXLAN FDB-st, kuid kasutab vale DST MAC-i ja liiklus visatakse ootuspäraselt tagasi hüpervisorit vastu võtva liidese poolt. Tegelikult kuuest ühest neljast juhtumisse kuulus see MAC algsele hüpervisorile, millelt masina migreerimist alustati.

Eile sain Fortinet'i tehniliselt toelt kirja — minu juhtumi kohta avati vea 615586. Ma ei tea, kas rõõmustada või kurvastada: ühelt poolt — probleem ei ole seadetes, teiselt — fikseerimine tuleb ainult koos tarkvara uuendusega, parimal juhul järgmisel. Samuti soojendab mu ühte viga, mille avastasin eelmisel kuul, tõsi, siis HTML5 GUI vSphere'is. Tõeline kohalik tarnija QA osakond...

Riskin järeldada järgmist:

1 — multicast'i kontrollplaan ei pruugi tõenäoliselt olla kirjeldatud probleemile vastuvõtlik — MAC-aadressid VTEP-st on saadud grupi IP-aadressist, millele liides on allkirjastatud.

2 — tõenäoliselt on Fortigate'i probleem seansside laadimisega Network Processor'ile (umbes CEF analoog) — kui jagada iga pakett läbi CPU, kasutatakse tabeleid, mis sisaldavad õiget — vähemalt visuaalselt — teavet. Selle oletuse kasuks näitab see, et aitab sulgeda/avamise liidest või oodata mõnda aega — rohkem kui 5 minutit.

3 — meeskonnapoliitika muutmine, näiteks selge ebaõnnestumine, või LAG-i rakendamine ei lahenda probleemi, kuna jälgitud on 'jäämist' MAC-i algsest hüpervisorist kapseldatud pakettides.

Selle valguses saan jagada, et avastasin hiljuti blogi, kus ühe artikli kohaselt väideti, et stetfull tulemüürid ja vahemälutavad andmeedastusmeetodid on toimetused. Noh, ma ei ole IT-s nii kogenud, et selliseid väiteid teha, pealegi ei ole ma kohe kõigega, mida blogiartiklid väidavad, nõus. Kuid midagi ütleb mulle, et Ivanil on tõde oma sõnades.

Aitäh tähelepanu eest! Oleksin rõõmus vastata küsimustele ja kuulda konstruktiivset kriitikat.

Allikas: habr.com