Linux-ի ակտիվ-պահուստային bond-ը all-active EVPN-ում. ինչ է կոտրվում

Տեղադրեք ակտիվ-պահուստային bond սերվերի վրա, all-active Ethernet սեգմենտ՝ ֆաբրիկայի վրա, և վերադարձող թրաֆիկի կեսը կարող է անհետանալ առանց մեկ սխալի հաշվիչ շարժվելու։ Երկու կոնֆիգուրացիաներից ոչ մեկն ինքնին սխալ չէ։ Խնդիրը նրանց միջև հանձնման մեջ է, որտեղ մի կողմը ընտրում է մեկ պորտ, իսկ մյուսը ենթադրում է, որ յուրաքանչյուր միացված leaf կարող է հասցնել։ Հետևեք մեկ շրջանակի յուրաքանչյուր ուղղությամբ և անհամապատասխանությունը դառնում է ակնհայտ։

Ինչ է անում ակտիվ-պահուստայինը մուտքային շրջանակի հետ

Bonding ռեժիմ 1-ը ուղարկման ուղու վրա պահում է ուղիղ մեկ slave և փոխում է այն միայն այն ժամանակ, երբ ընթացիկը ձախողվում է։ Այդ մասը հայտնի է։ Այստեղ կարևորը ընդունման կողմն է. միջուկը շրջանակը ստեկին հանձնում է միայն այն դեպքում, երբ այն հասնում է ակտիվ slave-ին, և դեն է նետում այն շրջանակները, որոնք հայտնվում են որևէ այլ slave-ի վրա։ Այս all_slaves_active կարգավորումը գոյություն ունի հենց այդ կանոնը մեղմելու համար, և լռելյայն անջատված է։ ip -d link show bond0 տպում է ընթացիկ արժեքը ռեժիմի կողքին։

/proc/net/bonding/bond0 անվանում է ակտիվ slave-ը և հայտնում յուրաքանչյուր slave-ի կապի վիճակը։ Այդ ֆայլը միակ ազնիվ աղբյուրն է, թե որ պորտն է հիմա կրում թրաֆիկը։

Այս ռեժիմում հոսթն ունի մեկ օգտագործելի ընդունման ուղի միաժամանակ՝ ընտրված տեղում առանց ֆաբրիկայի մասին իմացության։ Եթե այդ հոսթի համար շրջանակը հասնում է մյուս մալուխով, անջատիչի պորտը հաշվում է այն որպես ընդունված, հոսթի ստեկը երբեք չի տեսնում այն, և բոլոր հաշվիչները, բացի հոսթի սեփական կորստի հաշվիչից, ամբողջովին առողջ տեսք ունեն։

Ինչ է անում all-active multihoming-ը հեռավոր հաջորդ hop-ի հետ

EVPN multihoming-ը նկարագրում է leaf-երի մի շարք, որոնք կիսում են մեկ Ethernet սեգմենտ, որը նույնացվում է ESI-ով, և հայտարարում է այդ սեգմենտը ֆաբրիկայի մնացած մասին։ All-active մոդելում հեռավոր peer-երը սեգմենտի հասցեների համար տեղադրում են մեկից ավելի հաջորդ hop։ Սերվերի ուղղությամբ unicast-ը այնուհետև կարող է հասնել ցանկացած leaf-ի, և ֆաբրիկան ազատ է ընտրելու յուրաքանչյուր հոսքի համար։ Դա է դիզայնի ամբողջ իմաստը, և դա է նաև այն ենթադրությունը, որը սերվերի bond-ը պետք է բավարարի։

Հեղեղված թրաֆիկը հետևում է այլ կանոնի։ Leaf-երը յուրաքանչյուր սեգմենտի համար ընտրում են նշանակված forwarder, այնպես որ broadcast-ը, անհայտ unicast-ը և multicast-ը սովորաբար ներս են մտնում նրանցից մեկի միջով։ Այսպիսով unicast-ը և հեղեղումը երկու առանձին որոշում են կայացնում, և դրանցից միայն մեկն է երևում հոսթի bond-ի վիճակում։

Որտեղ են երկու ընտրությունները տարբերվում

Միջուկն իր ակտիվ slave-ն ընտրում է կապի վիճակից և իր քաղաքականությունից։ Ֆաբրիկան հաջորդ hop-երը ընտրում է EVPN երթուղիներից, իսկ նշանակված forwarder-ը՝ leaf-երի միջև ընտրությունից։ Ոչ մի գործընթաց չի խորհրդակցում մյուսի հետ։ Երբ նրանք ընտրում են տարբեր leaf-եր, խափանումը ուղղությունից կախված է. այն, ինչ սերվերը ուղարկում է, դուրս է գալիս նորմալ, իսկ պատասխանները անհետանում են։

Գոյություն ունի երկու աջակցվող ելք, և դրանք փոխարինելի չեն։ Տվեք հոսթին bond, որը ֆաբրիկան կարող է դիտարկել որպես մեկ տրամաբանական միացում, ինչը գործնականում նշանակում է leaf-երի հետ բանակցված LACP bond, և երկու կապերն էլ իսկապես միասին ակտիվ են։ Կամ ընդունեք նաև single-active առաքում ֆաբրիկայից, որպեսզի սեգմենտը հետևի նույն՝ միաժամանակ մեկ պորտ մոդելին, ինչ bond-ը։ Այն, ինչ չի աշխատում, all-active սեգմենտն է այնպիսի bond-ի առջև, որը լսում է միայն մեկ պորտում, եթե դուք միտումնավոր չմիացնեք ընդունումը ոչ ակտիվ slave-երի վրա և չընդունեք դրան հաջորդող կրկնակի առաքումը։

Ինչու պահուստային մալուխը շարունակում է առողջ երևալ

Թրաֆիկ չկրող մալուխը դեռ հաղորդում է կապը վերև, և bond-ում սպասող slave-ը նախագծված է պատրաստ երևալու համար։ Օպերատորները դա կարդում են որպես ավելորդություն և դադարում հարցնել։

Փոխարենը հարցրեք, թե որ ֆիզիկական պորտն է օգտագործել վերադարձի շրջանակը։ Հոսթի վրա հաշվեք ստացված փաթեթները slave-ով, ոչ bond-ով, քանի որ bond-ի հաշվիչը թաքցնում է ասիմետրիան։ Leaf-ի վրա նայեք կամրջի փոխանցման գրառումներին սերվերի MAC-ի համար և հաջորդ hop-երի բազմությանը, որը կրում է EVPN երթուղին։ Եթե գրառումը մատնանշում է այն leaf-ին, որի հոսթ-կապը պահուստն է, դիզայնը առաքում է մի պորտ, որը հոսթը անտեսում է։ Սա կոնֆիգուրացիայի անհամապատասխանություն է, ոչ թե ապարատային խափանում, և կապի վիճակի ոչ մի մոնիտորինգ դա չի հայտնաբերի։

Փորձարկեք առաքումը երկու ուղղություններով, ոչ թե կապի վիճակը

Կառուցեք մատրիցա՝ յուրաքանչյուր խափանման համար մեկ տող և յուրաքանչյուր ուղղության համար մեկ սյունակ, ապա լրացրեք առաքված թրաֆիկով, ոչ թե ինտերֆեյսի վիճակով։ Առաջին տողը նորմալ աշխատանքն է, և հենց այնտեղ է թաքնված անհամապատասխանությունը, որովհետև ախտանիշը նման է հավելվածի խնդրի։

Այնուհետև հեռացրեք ակտիվ հոսթ-կապը, հեռացրեք մեկ leaf, հեռացրեք այդ leaf-ի uplink-ները, և վերականգնեք յուրաքանչյուրը հերթով։ Ամեն քայլից հետո գրանցեք ակտիվ slave-ը, EVPN սեգմենտի վիճակը, հեռավոր փոխանցման գրառումը և դիտարկված թողունակությունը երկու ուղղություններով։ Leaf-ը, որը կորցնում է ֆաբրիկայի ուղին, մինչ նրա հոսթ-կապը մնում է վերև, հետաքրքիր դեպքն է, որովհետև կցումը մնում է հայտարարված և կարող է հանգիստ դառնալ փակուղի։ Փորձարկեք նոր unicast հոսքերով և այն հեղեղված թրաֆիկով, որից կախված է հավելվածը, որովհետև երկուսն օգտագործում են տարբեր փոխանցման որոշումներ։

Ընդունեք դիզայնը միայն այն ժամանակ, երբ մատրիցը ցույց է տալիս երկկողմանի առաքում այն ուղով, որը նախատեսել էիք։ Երկու մալուխ՝ կապը վերև, այդ արդյունքը չէ։