all-active EVPN-இல் Linux செயலில்-காப்பு bond: என்ன உடையும்

சேவையகத்தில் செயலில்-காப்பு bond வைக்கவும், fabric-இல் all-active Ethernet பிரிவை வைக்கவும், திரும்பி வரும் போக்குவரத்தில் பாதி ஒரு பிழை கணக்கியும் நகராமல் மறையலாம். இரண்டு அமைப்புகளில் எதுவும் தனியாகத் தவறல்ல. பிரச்சினை அவற்றுக்கிடையிலான ஒப்படைப்பில் உள்ளது, அங்கு ஒரு பக்கம் ஒரே போர்ட்டைத் தேர்ந்தெடுக்கிறது, மறு பக்கம் இணைக்கப்பட்ட ஒவ்வொரு leaf-உம் வழங்க முடியும் எனக் கருதுகிறது. ஒவ்வொரு திசையிலும் ஒரு frame-ஐப் பின்தொடர்ந்தால் பொருந்தாமை தெளிவாகும்.

வரும் frame-ஐ செயலில்-காப்பு என்ன செய்கிறது

bonding பயன்முறை 1 அனுப்பும் பாதையில் சரியாக ஒரு slave-ஐ வைத்திருக்கும், தற்போதையது தோல்வியடையும்போது மட்டுமே அதை மாற்றும். அந்தப் பகுதி நன்கு அறியப்பட்டது. இங்கு முக்கியமானது பெறும் பக்கம்: kernel ஒரு frame-ஐ stack-க்கு வழங்குவது அது செயலில் உள்ள slave-இல் வந்தால் மட்டுமே, வேறு எந்த slave-இலும் தோன்றும் frame-களை விட்டுவிடும். இந்த all_slaves_active அமைப்பு அந்த விதியைத் தளர்த்தவே உள்ளது, இயல்பாக இது அணைக்கப்பட்டுள்ளது. ip -d link show bond0 பயன்முறைக்கு அடுத்து தற்போதைய மதிப்பை அச்சிடுகிறது.

/proc/net/bonding/bond0 செயலில் உள்ள slave-ஐப் பெயரிடுகிறது, ஒவ்வொரு slave-க்கும் இணைப்பு நிலையைத் தெரிவிக்கிறது. எந்தப் போர்ட் இப்போது போக்குவரத்தைச் சுமக்கிறது என்பதற்கு அந்தக் கோப்பே ஒரே நேர்மையான மூலம்.

இந்தப் பயன்முறையில் உள்ள ஹோஸ்ட்டுக்கு ஒரு நேரத்தில் ஒரே ஒரு பயன்படுத்தக்கூடிய பெறும் பாதை இருக்கும், அது fabric பற்றிய அறிவின்றி உள்ளூரில் தேர்ந்தெடுக்கப்படும். அந்த ஹோஸ்ட்டுக்கான frame மற்ற கேபிளில் வந்தால், switch போர்ட் அதைப் பெற்றதாகக் கணக்கிடும், ஹோஸ்ட்டின் stack அதை ஒருபோதும் காணாது, ஹோஸ்ட்டின் சொந்த drop கணக்கி தவிர மற்ற எல்லா கணக்கிகளும் முற்றிலும் ஆரோக்கியமாகத் தெரியும்.

all-active multihoming தொலைவு அடுத்த hop-உடன் என்ன செய்கிறது

EVPN multihoming ESI-யால் அடையாளம் காணப்படும் ஒரு Ethernet பிரிவைப் பகிரும் leaf-களின் தொகுப்பை விவரிக்கிறது, அந்தப் பிரிவை மீதமுள்ள fabric-க்கு அறிவிக்கிறது. all-active மாதிரியில் தொலை peer-கள் பிரிவின் முகவரிகளுக்கு ஒன்றுக்கு மேற்பட்ட அடுத்த hop-ஐ நிறுவுகின்றன. சேவையகத்தை நோக்கிய unicast எந்த leaf-க்கும் வந்து சேரலாம், fabric ஒவ்வொரு ஓட்டத்திற்கும் சுதந்திரமாகத் தேர்ந்தெடுக்கலாம். இதுவே வடிவமைப்பின் முழு நோக்கம், சேவையகத்தின் bond நிறைவேற்ற வேண்டிய ஊகமும் இதுவே.

வெள்ளப் போக்குவரத்து வேறு விதியைப் பின்பற்றுகிறது. leaf-கள் ஒவ்வொரு பிரிவுக்கும் நியமிக்கப்பட்ட forwarder-ஐத் தேர்ந்தெடுக்கின்றன, எனவே broadcast, அறியப்படாத unicast, multicast பொதுவாக அவற்றில் ஒன்றின் வழியே நுழைகின்றன. இதனால் unicast-உம் வெள்ளமும் இரண்டு தனித்தனி முடிவுகளை எடுக்கின்றன, அவற்றில் ஒன்றே ஹோஸ்ட்டின் bond நிலையில் தெரிகிறது.

இரு தேர்வுகள் வேறுபடும் இடம்

kernel அதன் செயலில் உள்ள slave-ஐ இணைப்பு நிலை மற்றும் அதன் சொந்தக் கொள்கையிலிருந்து தேர்ந்தெடுக்கிறது. fabric அடுத்த hop-களை EVPN வழிகளிலிருந்தும், நியமிக்கப்பட்ட forwarder-ஐ leaf-களுக்கிடையிலான தேர்விலிருந்தும் தேர்ந்தெடுக்கிறது. எந்தச் செயலும் மற்றதைக் கலந்தாலோசிக்கவில்லை. அவை வெவ்வேறு leaf-களைத் தேர்ந்தெடுத்தால் தோல்வி திசையைச் சார்ந்தது: சேவையகம் அனுப்புவது சாதாரணமாக வெளியேறும், பதில்கள் மறைந்துவிடும்.

இரண்டு ஆதரவு வழிகள் உள்ளன, அவை ஒன்றுக்கொன்று மாற்றாகாது. fabric ஒரே தருக்க இணைப்பாகக் கருதக்கூடிய bond-ஐ ஹோஸ்ட்டுக்குக் கொடுங்கள், நடைமுறையில் இது leaf-களுடன் பேச்சுவார்த்தை நடத்திய LACP bond, இரு இணைப்புகளும் உண்மையிலேயே ஒன்றாகச் செயலில் இருக்கும். அல்லது fabric-இலிருந்து single-active வழங்கலையும் ஏற்கவும், பிரிவு bond-ஐப் போலவே ஒரு-போர்ட்-ஒரு-நேர மாதிரியைப் பின்பற்றும். வேலை செய்யாதது ஒரே போர்ட்டில் மட்டும் கேட்கும் bond-க்கு முன்னால் all-active பிரிவு வைப்பது, நீங்கள் வேண்டுமென்றே செயலற்ற slave-களில் பெறுதலை இயக்கி அதைத் தொடரும் இரட்டை வழங்கலை ஏற்காத வரை.

காப்பு கேபிள் ஆரோக்கியமாகத் தெரிவது ஏன்

போக்குவரத்து சுமக்காத கேபிளும் இணைப்பு மேலே என்று தெரிவிக்கும், bond-இல் உள்ள காத்திருப்பு slave தயாராகத் தெரியும்படி வடிவமைக்கப்பட்டுள்ளது. இயக்குபவர்கள் அதை மிகைப்படுத்தலாகப் படித்து கேட்பதை நிறுத்துகிறார்கள்.

அதற்குப் பதிலாக திரும்பும் frame எந்த இயற்பியல் போர்ட்டைப் பயன்படுத்தியது என்று கேளுங்கள். ஹோஸ்ட்டில், bond-க்கு பதிலாக slave-க்கு பெற்ற packet-களை எண்ணுங்கள், ஏனெனில் bond கணக்கி சமச்சீரற்ற தன்மையை மறைக்கிறது. leaf-இல், பாருங்கள் சேவையகத்தின் MAC-க்கான bridge forwarding பதிவுகளை மேலும் EVPN வழி சுமக்கும் அடுத்த-hop தொகுப்பையும். பதிவு ஹோஸ்ட் இணைப்பு காத்திருப்பில் உள்ள leaf-ஐச் சுட்டினால், வடிவமைப்பு ஹோஸ்ட் புறக்கணிக்கும் போர்ட்டுக்கு வழங்குகிறது. இது hardware கோளாறு அல்ல, அமைப்பு பொருந்தாமை, எவ்வளவு இணைப்பு-நிலை கண்காணிப்பும் இதை வெளிக்கொணராது.

இரு திசைகளிலும் வழங்கலைச் சோதியுங்கள், இணைப்பு நிலையை அல்ல

ஒவ்வொரு தோல்விக்கும் ஒரு வரி, ஒவ்வொரு திசைக்கும் ஒரு நிரல் கொண்ட matrix உருவாக்கி, interface நிலைக்குப் பதிலாக வழங்கப்பட்ட போக்குவரத்தை நிரப்புங்கள். முதல் வரி சாதாரண இயக்கம், பொருந்தாமை அங்கேயே மறைந்துள்ளது, ஏனெனில் அறிகுறி பயன்பாட்டுப் பிரச்சினை போலத் தெரிகிறது.

பின்னர் செயலில் உள்ள ஹோஸ்ட் இணைப்பை அகற்றுங்கள், ஒரு leaf-ஐ அகற்றுங்கள், அந்த leaf-இன் uplink-களை அகற்றுங்கள், ஒவ்வொன்றையும் வரிசையாக மீட்டெடுங்கள். ஒவ்வொரு படியிலும் செயலில் உள்ள slave, EVPN பிரிவு நிலை, தொலை forwarding பதிவு, இரு திசைகளிலும் கவனிக்கப்பட்ட throughput ஆகியவற்றைப் பதிவு செய்யுங்கள். ஹோஸ்ட் இணைப்பு மேலே இருக்கும்போது fabric பாதையை இழக்கும் leaf சுவாரஸ்யமான நிலை, ஏனெனில் இணைப்பு அறிவிக்கப்பட்டே இருக்கும், அமைதியாக முட்டுச் சந்தாகலாம். புதிய unicast ஓட்டங்களுடனும், பயன்பாடு சார்ந்திருக்கும் வெள்ளப் போக்குவரத்துடனும் சோதியுங்கள், ஏனெனில் இரண்டும் வெவ்வேறு forwarding முடிவுகளை எடுக்கின்றன.

நீங்கள் நோக்கிய பாதை வழியாக இரு-திசை வழங்கலை matrix காட்டினால் மட்டுமே வடிவமைப்பை ஏற்கவும். இணைப்பு மேலே உள்ள இரண்டு கேபிள்கள் அந்த முடிவு அல்ல.