Բարի գալուստ, և սկզբում մի փոքր բանաստեղծականություն: Երբեմն ես завижу իմ գործընկերներին, ովքեր աշխատում են հեռավար — իհարկե, հիանալի է հնարավորություն ունենալ աշխատելու աշխարհում, որտեղ Internet է հասանելի, արձակուրդ երբևէ, պատասխանատվություն նախագծերի և ժամկետների համար, ոչ թե լինել գրասենյակում 8-ից 17: Մեր պաշտոնը և աշխատանքային պարտականությունները գրեթե բացառում են երկարատև բացակայությունը տվյալ կենտրոնում: Սակայն կան հետաքրքիր դեպքեր, նմանեցված ներքևում նկարագրածին — և ես հասկանում եմ, որ քիչ է այն դիրքերը, որտեղ կա այսպիսի տարածություն ստեղծագործական ինքնարտահայտման համար.
Փոքրիկ տեղեկացում — հոդվածը գրելու պահին դեպքը ամբողջությամբ չի լուծվել, բայց հաշվի առնելով մատակարարների պատասխանները, լիարժեք լուծումը կարող է տևել ամսվա, իսկ ես արդեն ցանկանում եմ կիսվել իմ բացահայտումներով: Հույս ունեմ, հարգելի ընթերցողներ, դուք ինձ կներեք այս խանդավառության համար: Բայց բավական է ջրի մասին — ինչ է այդ դեպքի մասին?
Առաջին հերթին, պարտադիր տեղեկություն: Ակա մի ընկերություն (որտեղ ես աշխատում եմ որպես ցանցային ինժեներ), որը տրամադրում է հաճախորդների լուծումներ VMWare-ի մասնավոր Cloud-ում: Նոր լուծումների մեծ մասը միացված է VXLAN-վիրահատվածներին, որոնք կառավարվում են NSX-V — չեմ ուզում գնահատել, թե որքան ժամանակ է ինձ տվել սա, համենայն դեպս, շատ: Ես կարողացել եմ նույնիսկ ուսուցանել գործընկերներին NSX ESG-ի կարգավորմանը, և փոքր հաճախորդների լուծումները իրականանում են առանց իմ մասնակցության: Կարեւոր նշում — մեր kontrol plane-ը unicast-հակառակորդություն ունի: Հայտարարիչները ավելորդ կերպ միացված են երկու ինտերֆեյսների միջոցով տարբեր ֆիզիկական Juniper QFX5100 switch-ներին (կազմավորված Virtual Chassis-ով) և քաղաքականություն `route based on originating virtual port — սա նկարի ամբողջականության համար է.
Հաճախորդների լուծումները շատ բազմազան են: Windows IIS-ից, որտեղ բոլոր web-server կոմպոնենտները տեղադրված են մեկ մեքենայի վրա, մինչև բավականին մեծ `օրինակ՝ load-balanced Apache web-ֆրոնտներ + LB MariaDB Galera-ում + ֆայլային սերվերներ, որոնք սինխրոնիզացվում են GlusterFS-ի օգնությամբ: prácticamente յուրաքանչյուր սերվեր պետք է մոնիտորինգային լինի առանձին, իսկ հանրային հասցեները բոլոր կոմպոնենտների մոտ չունեն — եթե դուք բախվել եք այս խնդրին և ունեք ավելի փարթամ լուծում, ուրախ կլինեմ խորհուրդ տալ.
Իմ մոնիտորինգի լուծումը բաղկացած է «կայացնել» firewall-ը (Fortigate) յուրաքանչյուր ներքին հաճախորդական ցանցի մեջ (+SNAT և, իհարկե, խիստ սահմանափակումներ թույլատրված տրաֆիկի տեսակների վրա) և դիտել ներքին հասցեները — այս կերպ հասնում ենք մի cierta unificación y simplificación de la monitorización. El monitoreo ocurre desde un clúster de servidores PRTG. La схемա de monitorización es aproximadamente así:
Ես մինչև հիմա աշխատում էի միայն VLAN-ների հետ, ու ամեն ինչ սովորաբար և կանխատեսելի կարգով աշխատում էր, ինչպես ժամացույցը։ NSX-V և VXLAN-ի ներդրումից հետո հարց առաջացավ՝ կարելի՞ է շարունակել մոնիտորինգը հին կերպով։ Այդ պահին ամենակարճ բժի լուծումը NSX ESG-deployment-ում VXLAN trunk-հայելին VTEP ցանցում միացնելն էր։ Կարճ մեջ սովորաբար՝ քանի որ GUI օգտագործելը հաճախորդների ցանցերի կարգավորման, SNAT-ի և ֆայլերոլի կանոնների համար միավորելու վրա կենտրոնացած vSphere ինտերֆեյսում, սակայն կարծում եմ, որ դա բավականին ծանր և ավելին էր, քան այդ բոլոր փաստաթղթերը սահմանափակում էին Troubleshooting-ների գործիքները։ Նրանք, ովքեր օգտագործել են NSX ESG-ն իբրև «ես իսկական» ֆայլերոլ, կարծում են, որ համաձայն կլինեն։ Եթե ոչ, նման լուծումն, անկասկած, ավելի կայուն կլիներ՝ քանի որ ամեն ինչ տեղի է ունենում մեկ վենդորի շրջանակներում。
Մեկ այլ լուծում՝ օգտագործել NSX DLR-ն VLAN-ի և VXLAN-ի միջև լադրաստման ռեժիմի մեջ։ Ա这里 կարծում եմ ամեն ինչ հստակ է՝ պարզորեն կորցնում ենք VXLAN-ի կիրառման օգուտը՝ քանի որ այդ դեպքում նույն եղանակով պետք է մոնիտորինգի տեղադրման համար VLAN kéoել։ Քանի որ, այդ լուծումը մշակելու գործընթացում ես բախվել եմ խնդրի, երբ DLR-լադրաստում չի ուղարկում փաթեթներ վիրտուալ մեքենաի հետ, որը մի բնակավայրում է։ Ես գիտեմ, գիտեմ՝ NSX-V-ի գրքերում և ուղեցույցներում ուղղակի ասված է, որ NSX Edge-ի համար այլ հարկ է տրամադրելի կլաստեր, սակայն դա գրքերում է… Ի վերջո, մի քանի ամիսներ խնամելու հետ մենք լուծում չենք գտել։ Հիմնականում հասկացա գործողության տրամաբանությունը՝ հիպերվիզորի kernels մոդուլը, որը պատասխանատու է VXLAN-ի շարքում վերակողմակալելու համար չի դիրքավորվել, եթե DLR և դիտվող սերվերը գտնվում էինոչ մի բնակավայրում, քանի որ տրաֆիկը չի թողնում բնակավայրը, ու տրամաբանության մեջ պետք է միացված լինի VXLAN հատվածին՝ վերակողմակալումը անհրաժեշտ չէ։ Խնամքի հետ կանգնեցինք vdrPort վիրտուալ ինտերֆեյսում, որը տրամադրում է uplinks -ը միաձուլում և նաև կատարում է լադրաստում/վերակողմակալում — այնտեղ նկատվեց մուտքային տրաֆիկի անհամապատասխանություն, որը ես վերցրի մշակման ընթացակարգում։ Բայց ինչպես ասվեց, ես այդ դեպքը չեմ հասցրել վերջացնել, քանզի տեղափոխվել եմ այլ նախագծի, և բնագծի սկզբնիվը փակ էր ու դրա զարգացումը հատուկ ցանկություն չէր։ Եթե ճիշտ չեմ, խնդիրը դիտվեց NSX վարկում 6.1.4 և 6.2-ի վրայով։
Ու այստեղ — բինգո! Fortinet-ը հայտարարում է բնօրինակ ։ Եվ ոչ միայն point-to-point կամ VXLAN-over-IPSec, այլ՝ VLAN-VXLAN-ի սոֆտվարային լադրաստում — որքա՞ն վաղենված է, սկսում են ներդնել դեռ 5.4 տարբերակով (և ներկայացված է այլ ), իսկ իրական աջակցության unicast control plane- ը: լուծում ներդնելու գործընթացում մեկ այլ խնդիր են հանդիպել՝ ստուգման սերվերները ժամանակ առ ժամանակ «կորցնում» էին թե́ և ծածկագրով էին հայտնվում մոնիտորինգում, չնայած վիրտուալ մեքենան կենդանություն էր լսում: Քանի որ պարզվեց, որ ես մոռացել էի թույլ տալ Ping-ը VXLAN- ի ինտերֆեյսում: Կլաստերների վերադասավորման գործընթացում, վիրտուալ մեքենաները տեղափոխվում էին, իսկ Ping- ով ավարտվում էր vMotion-ը՝ որպես նշան նոր ESXI մուրը, որտեղ մեքենան տեղափոխվել էր: Իմ հիմարությունը, բայց այս խնդիրը ևս մեկ անգամ undermined էր վստահությունը արտադրողի աջակցության հանդեպ՝ այս դեպքում Fortinet- ը: Ես այլևս չեմ ասում, որ յուրաքանչյուր դեպք, որը կապված է VXLAN- ի հետ, սկսվում է հարցով «իսկ որտեղ ունեք ձեր սոֆթսվիչի VLAN-VXLAN կարգավորումները?» Այս անգամ ինձ խորհուրդ տվեցին փոխել MTU-ն - սա Ping-ի համար է, որը 32 բյայ է: Այնուհետև «խաղալ» tcp-send-mss և tcp-receive-mss- ի հետ քաղաքականությունում - VXLAN -ի համար, որը սպառնում է UDP-ում: Ուհ, մատյան, ներեք - հասնում եմ: Ընդհանուր առմամբ այս խնդիրը լուծեցի իմ ուժերով:
Առաջին փորձարկային երթևեկությունը հաջողությամբ ավարտելուց հետո, որոշվեց ներդնել այս լուծումը: Եվ արտադրանքում պարզվեց, որ մեկ-երկու օր հետո աստիճանաբար կօգտագործվեն ընդհանրապես ամեն ինչ, ինչին մոնիտորինգ է արվում VXLAN- ի միջոցով: Ինտերֆեյսի անջատումը / ակտիվացումը օգնում էր, բայց միայն ժամանակավոր: Հիշելով արտադրողի աջակցության դանդաղությունը, ես զբաղվեցի խնդիրների լուծմամբ իմ կողմից - մեղմորեն, իմ ընկերությունն է, իմ ցանցը - իմ պատասխանատվությունն:
Սպոյլերում խնդիրների լուծման ընթացքը: Ով հոգնել է տառերից և bragging-ից՝ թող չանցնի և անցնի հետադարձ վերլուծությանը:
Խնդիրների լուծման ընթացքը:Շնորհակալություն, որ շարունակեցիք կարդալ - շարունակենք:
Այսպիսով, մոնիտորինգն աշխատում է մի որոշակի ժամանակ, ապա ինքն իրեն վնասվում է: Դա նշանակում է, որ դրա քաղաքականություններում հավանաբար խնդիրներ չկան: Այնուամենայնիվ, քանի որ ես հանդիպել եմ Fortigate 5.6+ տարբերակներում համակարգային գործընթացների կախվածության խնդրին, ուստի նախ պետք է նայենք «diagnose debug flow» -ը՝ սպասելի է, որ տրաֆիկը թույլ տրվում է և դուրս է գալիս ինտերֆեյսից, և սպասելի չէ, որ ինչ-որ բան գալիս է պատասխան: Ավելին փնտրելու համար մենք արձանագրում ենք: Կոորդինատները փակելու համար, նույնիսկ եթե դա RFC1918-ն է, բայց հույս ունեմ, որ այս գործընթացին տալիս է բավարար նկարագրություն: Վիրտուալ մեքենայի ներսում VXLAN-ը ունի հասցե x.x.x.15, fortigate-ի ինտերֆեյսը x.x.x.254, մյուս հասցեները վերաբերում են VTEP ցանցին:
VXLAN- ի հյուսվածքային փաթեթների հաջող փոխանցման համար անհրաժեշտ է ունենալ հասանելի և ճիշտ տեղեկատվություն մի քանի աղյուսակներում: Overlay համար դա ARP և OVSDB է, underlay համար դա ARP և CAM է: Fortigate VXLAN FDB- ի և OVSDB- ի առկայությունը: Հիմա կմեկնարկենք:
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
Այստեղ բոլորն էլ բավականին պարզ են՝ վիրտուալ մեքենայի MAC հասցեն պետք է գտնվի VTEP հասցեի մոտ՝ у.у.у.47: տեսնելով ESXI կլաստերի պարունակությունների և կարգավորումների մասին, ես գտնում եմ, որ վիրտուալ մեքենայի MAC-ը ճիշտ է, VTEP հասցեն նույնպես: Проверяю CAM/ARP таблица на фортике — опять все совпадает с настройками ESXI хоста:
fortigate (root) #get sys arp | grep у.у.у.47
у.у.у.47 0 00:50:56:65:f6:2c dmz
Թերթերը ճիշտ են և տրանսֆերային տրաֆիկը գնում է՝ գուցե խնդիրն անգամ չի լինի Fortigate-ում: Ես դիտմամբ բաց էի թողել Juniper-ի տրաֆիկի անալիզը՝ տրամաբանորեն հաջորդTroubleshooting քայլը պետք է լիներ այնտեղ, բայց իմ ցանցը չափազանց պարզ է՝ ընդամենը մեկ VLAN VTEP-ի համար և բոլոր բաղադրիչները միացված են ուղղակի: Վերջապես հիշում եմ DLR-բրիջի, VDR-ի և կորած տրաֆիկի դեպքը՝ գնում եմ sniffing անել ESXi հոստում, զուգահեռ կապում եմ արդեն մի հարցում VMWare-ին: Ներքևում՝ MAC «97:6e» պատկանում է Fortigate-ին, vmnic1-ը՝ նրանց ինտերֆեյսին, որը ունի VTEP հասցե նմանությամբ у.у.у.47, sniffing անում երկու ուղղություններով "—dir 2":
pktcap-uw --uplink vmnic1 --vni 5008 --mac 90:6c:ac:a9:97:6e --dir 2 -o /tmp/monitor.pcap
Հ progress — sniffing-ում տեսնում եմ ARP հարցում և եկող պատասխան: Բերում եմ միայն ARP պատասխան և այնտեղ ամեն ինչ ճիշտ է: Չեմ հիշատակել, բայց այս ամբողջ ժամանակ դիտարկման սերվերը ping անում է х.х.х.15 հասցեն — որտեղ ինչպիսին ICMP трафикը? Հիշում եմ, որ ունեմ երկու uplink: Այստեղ կարելի է վիճել և ասել, որ վիրտուալ պորտի աղբյուրը միևնույնն է (իմ teaming policy), այսինքն՝ նույն vNIC-ի համար պետք է ընտրվի նույն uplink, բայց քանի որ ես հոստում եմ, մեկ այլ uplink ստուգելն անհետաքրքիր չէ:
pktcap-uw --uplink vmnic4 --vni 5008 --mac 90:6c:ac:a9:97:6e --dir 2 -o /tmp/monitor.pcap
Ունեմ հարցումներ Fortigate-ի կողմից, բայց պատասխան չկա: Այսինքն՝ խնդիրը ոչ Fortigate-ում է: Միանշանակ հասկանում եմ՝ սա կրկին նույն խնդիրը է VDR-ի վրա կորած տրաֆիկի հետ, կրկին մի քանի ամիսը պետք է ուղղել հարցումը ճիշտ ուղղությամբ: Երբ մի քանի օր անց հանգստացել եմ և չեմ ուզում ենթարկվել կայունակի, որոշել եմ հավաքել լրացուցիչ sniffing-ներ սոոպորտի համար՝ գործընթացը արագացնելու նպատակով: Եվ այստեղ "համագործակցաբար" ինձ նայում է Ethernet encapsulation underlay: Թագավորը իրական չէ և VTEP-ի MAC հասցեն չի համապատասխանում իր IP-ին: Նորից սկսում եմ, sniffing անում, փորփրում՝ ճիշտ է թե ոչ: Կբերեմ ARP աղյուսակը կողք կողքի, որպեսզի ավելի հարմար լինի համեմատել: Ուշադրություն դարձրեք առաջին Ethernet encapsulation-ի վրա վերևում՝
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
Ուրեմն, ի՞նչ ունենք վերջում՝ վիրտուալ մեքենայի միգրացիայից հետո, Fortigate-ը փորձում է ուղարկելու տրաֆիկը VTEP-ին (ճիշտ) VXLAN FDB-ից, բայց օգտագործում է սխալ DST MAC և տրաֆիկը ակնկալաբար գետնով դուրս գրվում է ավելի ստացող ինտերֆեյսից: Մինչև մեկը մեկից զրկվելով տվյալ MAC-ը պատկանում էր սկզբնական hypervisor-ին, որի վրա սկսվել էին մեքենայի միգրացիան:
Քիչ առաջ գրություն ստացա Fortinet-ի տեխնիկական աջակցությունից՝ իմ հարցումում բացել են bug 615586: Ճիշտ չենք իմանում՝ ուրախանալ, թե կշտանալ: Մի կողմից՝ խնդիր չկա կարգավորումներում, մյուս կողմից՝ մարկետ կլինի միայն firmware-ի թարմացում, լավագույն դեպքում հաջորդում: Ինձ աջակցությունները հետաքրքրում են, նաև մի bug, որն եմ հայտնաբերել անցյալ ամսում, միմյանց HTML5 GUI vSphere-ի ընթացքում: Ում ասես QA բաժին վենդորներին…
Ռիսկ է հանդիսանում ասել անխուսափելի է:
1 — multicast control plane հավանաբար չի ենթարկվելու նկարագրված խնդրին, քանի որ VTEP MAC հասցեները ստացվում են խմբի IP հասցեից, որի վրա է подпишется интерфейсը։
2 — հավանաբար խնդիրը Fortigate-ի сессիաների offload-ում է Network Processor-ում (մոտավորապես նման է CEF-ին) — եթե ամեն փաթեթը անցնի CPU-ն, կօգտագործվեն այն աղյուսակները, որոնք պարունակում են ճիշտ — ամեն դեպքում տեսողականորեն — տեղեկատվություն։ Այս ենթադրության օգտին վկայում է այն, որ օգտակար է փակել/բացել интерфիսը կամ մի քիչ սպասել — ավելի քան 5 րոպե։
3 — teaming policy-ի փոփոխությունը, օրինակ, explicit failover-ին, կամ LAG-ի ներդրումն հարցը չի լուծի, քանի որ նկատվել է «կանգ առնել» MAC-ի սարքի հիպերվիզորի ներթափանցումներում։
Այս գիտակցությամբ կարող եմ կիսվել, որ վերջերս բացեցի , որտեղ մեկ հոդվածում ասվում էր, որ stateful ֆայլեր և кешային տվյալների փոխանցման եղանակները — դա կակետներ են։ Ախր, ես այնքան փորձ չունեմ IT-ում, որպեսզի նման բաներ պնդեմ, բայց այս բլոգի հոդվածների բոլոր պնդումներից չեմ համաձայնում։ Բայց ինչ-որ բան ինձ ասում է, որ Իվանի խոսքերում ունի իրականության մի մասն։
Շնորհակալություն ուշադրության համար! Ակնկալում եմ պատասխանել հարցերին և լսել կառուցողական քննադատություն։
Ընտանիք: habr.com
