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 алсын дараагийн хопт юу хийдэг

EVPN multihoming нь ESI-ээр тодорхойлогддог нэг Ethernet сегментийг хуваалцдаг leaf-үүдийн багцыг тодорхойлж, тэр сегментийг фабрикийн үлдсэн хэсэгт зарладаг. All-active загварт алсын peer-үүд сегментийн хаягуудад нэгээс олон дараагийн хоп суулгадаг. Сервер рүү чиглэсэн unicast аль ч leaf дээр ирж болох бөгөөд фабрик урсгал бүрээр чөлөөтэй сонгоно. Энэ бол загварын бүх утга бөгөөд серверийн bond-ийн биелүүлэх ёстой таамаглал ч мөн адил.

Үердсэн траффик өөр дүрмийг дагадаг. Leaf-үүд сегмент бүрд томилогдсон forwarder сонгодог тул broadcast, үл мэдэгдэх unicast, multicast ихэвчлэн тэдгээрийн аль нэгээр ордог. Тиймээс unicast ба үер хоёр тусдаа шийдвэр гаргаж, тэдгээрийн зөвхөн нэг нь хотын bond-ийн төлөвт харагдана.

Хоёр сонголт хаана зөрдөг

Цөм идэвхтэй slave-ээ холбоосын төлөв болон өөрийн бодлогоос сонгодог. Фабрик дараагийн хопуудыг EVPN маршрутуудаас, томилогдсон forwarder-ийг leaf-үүдийн хоорондын сонголтоос сонгодог. Аль ч процесс нөгөөгөөсөө асуудаггүй. Тэд өөр leaf сонговол алдаа нь чиглэлээс хамаарна: серверийн илгээсэн нь хэвийн гарч, хариу нь алга болно.

Хоёр дэмжигдсэн гарах зам байгаа бөгөөд тэдгээр нь солигддоггүй. Хостод фабрик нэг логик холболт гэж үзэх боломжтой bond өг, энэ нь практикт leaf-үүдтэй хэлэлцсэн LACP bond гэсэн үг бөгөөд хоёр холбоос нь үнэхээр хамт идэвхтэй байна. Эсвэл фабрикаас single-active хүргэлтийг ч хүлээн ав, ингэснээр сегмент bond-ийн адил нэг-порт-нэг-удаа загварыг баримтлана. Ажиллахгүй зүйл бол зөвхөн нэг порт дээр сонсдог bond-ийн өмнөх all-active сегмент бөгөөд идэвхгүй slave-үүд дээр хүлээн авалтыг зориуд асааж, дараагийн давхар хүргэлтийг хүлээж авахгүй л бол.

Нөөц кабель яагаад эрүүл харагдаж байдаг вэ

Траффик зөөдөггүй кабель ч холбоосыг дээш гэж мэдээлдэг, bond дахь хүлээж буй slave бэлэн харагдахаар зохиогдсон. Операторууд үүнийг илүүдэл гэж уншиж, асуулт тавихаа болино.

Үүний оронд буцаж буй кадр аль физик портыг ашигласныг асуу. Хост дээр хүлээн авсан пакетуудыг bond-оор биш, slave тус бүрээр тоол, учир нь bond-ийн тоолуур тэгш бус байдлыг нуудаг. Leaf дээр хар серверийн MAC-д зориулсан гүүрний дамжуулалтын бичлэгүүдийг болон EVPN маршрутын зөөж буй дараагийн хопуудын багцыг. Хэрэв бичлэг нь хотын холбоос нь нөөц байгаа leaf рүү зааж байвал, загвар нь хост үл тоомсорлодог порт руу хүргэж байна. Энэ нь техник хангамжийн гэмтэл биш, тохиргооны зөрүү бөгөөд холбоосын төлөвийг хэдий чинээ хянасанаас үл хамааран илрэхгүй.

Хүргэлтийг хоёр чиглэлд туршиж үз, холбоосын төлөвийг биш

Алдаа бүрт нэг мөр, чиглэл бүрт нэг баганатай матриц байгуулж, интерфэйсийн төлөвийн оронд хүргэсэн траффикоор дүүргэ. Эхний мөр нь хэвийн ажиллагаа бөгөөд зөрүү яг тэнд нуугдаж байдаг, учир нь шинж тэмдэг нь програмын асуудал мэт харагддаг.

Дараа нь идэвхтэй хотын холбоосыг ав, нэг leaf-ийг ав, тэр leaf-ийн uplink-үүдийг ав, тус бүрийг ээлжлэн сэргээ. Алхам бүрийн дараа идэвхтэй slave, EVPN сегментийн төлөв, алсын дамжуулалтын бичлэг, хоёр чиглэлд ажиглагдсан дамжуулах чадварыг тэмдэглэ. Хотын холбоос дээшээ байхад фабрикийн замаа алддаг leaf нь сонирхолтой тохиолдол, учир нь холболт зарлагдсан хэвээр үлдэж, чимээгүйхэн мухардмал болж болно. Шинэ unicast урсгал болон програм ашигладаг үердсэн траффикаар туршаарай, учир нь хоёулаа өөр дамжуулалтын шийдвэр гаргадаг.

Матриц таны зорьсон замаар хоёр талын хүргэлтийг харуулсан үед л загварыг хүлээн зөвшөөр. Холбоос дээшээ хоёр кабель бол тэр үр дүн биш.