Холболтыг хянах (“conntrack”) нь Линуксийн цөмийн сүлжээний стекийн үндсэн шинж чанар юм. Энэ нь цөмд бүх логик сүлжээний холболтууд эсвэл урсгалуудыг хянах боломжийг олгодог бөгөөд ингэснээр урсгал тус бүрийг бүрдүүлдэг бүх пакетуудыг тодорхойлсноор тэдгээрийг дараалан боловсруулах боломжтой болно.
Conntrack нь зарим үндсэн тохиолдолд ашиглагддаг цөмийн чухал функц юм:
- NAT нь conntrack-ийн мэдээлэлд тулгуурладаг тул нэг урсгалын бүх пакетуудыг ижил байдлаар авч үздэг. Жишээлбэл, pod Kubernetes үйлчилгээнд хандах үед kube-proxy ачааллын тэнцвэржүүлэгч нь кластер доторх тодорхой pod руу урсгалыг чиглүүлэхийн тулд NAT-г ашигладаг. Conntrack нь өгөгдсөн холболтын хувьд IP үйлчилгээ рүү чиглэсэн бүх пакетуудыг нэг pod руу илгээх ёстой бөгөөд backend pod-оос буцаасан пакетуудыг хүсэлт ирсэн pod руу буцаан NAT болгосон байх ёстойг Conntrack тэмдэглэв.
- Calico зэрэг статустай галт хана нь холболтын замаас авахуулаад "хариу"-н цагаан жагсаалт хүртэлх мэдээлэлд тулгуурладаг. Энэ нь танд хариултын урсгалыг тодорхой зөвшөөрөх бодлого бичих шаардлагагүйгээр "миний pod-д ямар ч алсын IP хаягтай холбогдохыг зөвшөөрөх" гэсэн сүлжээний бодлогыг бичих боломжийг олгоно. (Үүнгүйгээр та аюулгүй байдал багатай "ямар ч IP-ээс миний pod руу пакет оруулахыг зөвшөөрөх" дүрмийг нэмэх хэрэгтэй болно.)
Нэмж дурдахад, conntrack нь зөвхөн урсгалын эхний пакет учраас системийн гүйцэтгэлийг сайжруулдаг (CPU-ийн хэрэглээ болон пакетийн хоцролтыг багасгах замаар).
юу хийхээ тодорхойлохын тулд сүлжээний стекийг бүхэлд нь дамжих ёстой. Нийтлэлийг үзнэ үү""Энэ хэрхэн ажилладаг тухай жишээг харахын тулд.
Гэсэн хэдий ч, conntrack нь өөрийн хязгаарлалттай ...
Тэгэхээр энэ бүхэн хаана буруу болсон бэ?
Conntrack хүснэгт нь тохируулах боломжтой хамгийн их хэмжээтэй бөгөөд хэрэв дүүрсэн тохиолдолд холболтууд ихэвчлэн татгалзаж эсвэл тасарч эхэлдэг. Хүснэгтэнд ихэнх програмын урсгалыг зохицуулах хангалттай зай байгаа бөгөөд энэ нь хэзээ ч асуудал болохгүй. Гэсэн хэдий ч, та холболтын хүснэгтийг ашиглахыг хүсч болох хэд хэдэн хувилбарууд байдаг:
- Таны сервер маш олон тооны нэгэн зэрэг идэвхтэй холболтуудыг зохицуулдаг бол хамгийн ойлгомжтой тохиолдол юм. Жишээлбэл, хэрэв таны холболтын хүснэгтийг 128к оролтоор тохируулсан боловч танд >128к зэрэгцэн холбогдсон холболт байгаа бол танд асуудал гарах нь гарцаагүй!
- Бага зэрэг тодорхой тохиолдол: хэрэв таны сервер секундэд маш олон тооны холболтыг боловсруулдаг бол. Холболтууд нь богино настай байсан ч тодорхой хугацаанд Линукс (анхдагчаар 120 секунд) үргэлжлүүлэн хянаж байдаг. Жишээлбэл, хэрэв таны холболтын хүснэгтийг 128к оролтоор тохируулсан бөгөөд та секундэд 1100 холболт хийхээр оролдож байгаа бол холболтууд нь маш богино хугацааны (128k/120s = 1092 холболт/) байсан ч тэдгээр нь холболтын хүснэгтийн хэмжээнээс хэтрэх болно. s).
Эдгээр ангилалд хамаарах хэд хэдэн төрлийн програмууд байдаг. Нэмж хэлэхэд, хэрэв танд маш олон муу жүжигчид байгаа бол серверийнхээ холболтын хүснэгтийг олон хагас нээлттэй холболтоор дүүргэх нь үйлчилгээг үгүйсгэх (DOS) халдлагын нэг хэсэг болгон ашиглаж болно. Аль ч тохиолдолд холболт хийх нь таны системд саад болж болзошгүй. Зарим тохиолдолд conntrack хүснэгтийн параметрүүдийг тохируулах нь таны хэрэгцээг хангахад хангалттай байж болох юм - хэмжээг нэмэгдүүлэх эсвэл холболтын хугацааг багасгах (гэхдээ хэрэв та үүнийг буруу хийвэл маш их асуудалтай тулгарах болно). Бусад тохиолдолд түрэмгий замын хөдөлгөөнд зориулж гарцыг тойрч гарах шаардлагатай болно.
Бодит жишээ
Тодорхой жишээ хэлье: бидний хамтран ажиллаж байсан нэг том SaaS үйлчилгээ үзүүлэгч нь хостууд дээр (виртуал машин биш) хэд хэдэн санах ойн сервертэй байсан бөгөөд тэдгээр нь тус бүр нь секундэд 50K+ богино хугацааны холболтыг боловсруулдаг байв.
Тэд холболтын тохиргоог туршиж, хүснэгтийн хэмжээг нэмэгдүүлж, хянах хугацааг богиносгосон боловч тохиргоо нь найдваргүй, RAM-ийн хэрэглээ мэдэгдэхүйц нэмэгдсэн нь асуудал байсан (ГБбайт дарааллаар!), холболтууд нь маш богино байсан тул conntrack ажиллахгүй байв. түүний ердийн гүйцэтгэлийн үр ашгийг бий болгох (багасгасан хэрэглээ CPU эсвэл пакет хоцролт).
Тэд өөр хувилбар болгон Калико руу хандсан. Calico сүлжээний бодлого нь тодорхой төрлийн урсгалд (doNotTrack бодлогын сонголтыг ашиглан) conntrack ашиглахгүй байхыг зөвшөөрдөг. Энэ нь тэдэнд шаардлагатай гүйцэтгэлийн түвшинг, мөн Calico-оос өгсөн аюулгүй байдлын нэмэлт түвшинг өгсөн.
Замыг тойрч гарахын тулд та ямар урт замыг туулах ёстой вэ?
- Сүлжээний бодлого нь ерөнхийдөө тэгш хэмтэй байх ёстой. SaaS үйлчилгээ үзүүлэгчийн хувьд: тэдний програмууд хамгаалагдсан бүс дотор ажилладаг тул сүлжээний бодлогыг ашиглан тэд memcached-д хандах эрхтэй бусад тусгай програмын урсгалыг цагаан жагсаалтад оруулж болно.
- "Бүү дагах" бодлого нь холболтын чиглэлийг харгалздаггүй. Тиймээс, хэрэв memcach-д хадгалагдсан сервер хакердагдсан бол та зөв эх портыг ашиглаж байгаа тохиолдолд та аль ч memcach-тэй клиенттэй холбогдохыг оролдож болно. Гэсэн хэдий ч, хэрэв та өөрийн memcach-тэй үйлчлүүлэгчдэд зориулсан сүлжээний бодлогыг зөв тодорхойлсон бол эдгээр холболтын оролдлогууд үйлчлүүлэгчийн тал дээр няцаагдах болно.
- Урсгалын зөвхөн эхний багцад хэрэглэгдэх ердийн бодлогоос ялгаатай нь "Бүү-хөшөөх" бодлогыг пакет бүрт хэрэглэнэ. Бодлого багц бүрт хэрэгжих ёстой тул энэ нь пакет тутамд CPU-ийн хэрэглээг нэмэгдүүлэх боломжтой. Гэхдээ богино хугацааны холболтын хувьд энэ зардлыг холболтын боловсруулалтын нөөцийн зарцуулалтыг бууруулах замаар тэнцвэржүүлдэг. Жишээлбэл, SaaS үйлчилгээ үзүүлэгчийн хувьд холболт бүрийн багцын тоо маш бага байсан тул пакет тус бүрт бодлого хэрэглэх үед CPU-ийн нэмэлт зарцуулалт үндэслэлтэй байсан.
Туршилтаа эхлүүлцгээе
Бид секундэд маш олон тооны холболтыг ажиллуулахын тулд алсын зангилаанууд дээр ажиллаж байгаа санах ойд хадгалагдсан сервер болон олон тооны санах ойд хадгалагдсан клиент pods бүхий нэг pod дээр туршилтыг явуулсан. Memcached server pod бүхий сервер нь холболтын хүснэгтэд 8 цөмтэй, 512k оролттой байсан (хостын стандарт тохируулсан хүснэгтийн хэмжээ).
Бид гүйцэтгэлийн ялгааг хэмжсэн: сүлжээний бодлого байхгүй; тогтмол Calico бодлоготой; болон Calico do-not-track бодлого.
Эхний туршилтын хувьд бид холболтын тоог секундэд 4.000 гэж тохируулсан тул CPU-ийн хэрэглээний ялгааг анхаарч үзэх боломжтой. Бодлогогүй болон ердийн бодлого хоёрын хооронд мэдэгдэхүйц ялгаа байхгүй байсан ч CPU-ийн хэрэглээ 20 орчим хувиар нэмэгдсэнийг бүү дагаж мөрдөөрэй.
Хоёрдахь туршилтаар бид үйлчлүүлэгчдийнхээ хэр их холболтыг эхлүүлж, манай мемкачтай серверийн ажиллах боломжтой секундэд хамгийн их холболтын тоог хэмжсэн. Хүлээгдэж байсанчлан "бодлоггүй" болон "байнгын бодлого" хоёр секундэд 4,000 гаруй холболтын холболтын хязгаарт хүрсэн (512к / 120с = 4,369 холболт/с). "Бүү дагах" бодлоготойгоор манай үйлчлүүлэгчид секундэд 60,000 холболтыг ямар ч асуудалгүйгээр илгээдэг. Бид илүү олон үйлчлүүлэгч нэмснээр энэ тоог нэмэгдүүлж чадна гэдэгт итгэлтэй байгаа ч эдгээр тоо нь энэ нийтлэлийн гол санааг харуулахад хангалттай гэж бид үзэж байна!
дүгнэлт
Conntrack бол цөмийн чухал функц юм. Тэр ажлаа төгс хийдэг. Энэ нь ихэвчлэн системийн гол бүрэлдэхүүн хэсгүүдэд ашиглагддаг. Гэсэн хэдий ч, зарим тодорхой хувилбарт холболтын улмаас үүссэн түгжрэл нь түүний өгдөг ердийн ашиг тусаас давж гардаг. Энэ хувилбарт Calico сүлжээний бодлогыг сүлжээний аюулгүй байдлыг нэмэгдүүлэхийн зэрэгцээ холболтын ашиглалтыг идэвхгүй болгоход ашиглаж болно. Бусад бүх замын хөдөлгөөний хувьд conntrack таны найз хэвээр байна!
Мөн манай блог дээрх бусад нийтлэлүүдийг уншина уу:
Эх сурвалж: www.habr.com