Анхаарна уу. орчуулга.: 8-р сарын эхээр Red Hat өмнөх саруудад үйлчилгээнийхээ хэрэглэгчдэд тулгарч байсан хүртээмжтэй холбоотой асуудлуудыг шийдвэрлэх талаар олон нийтэд ярьсан. (энэ нь CoreOS-ийг худалдаж авснаар компани хүлээн авсан контейнер зургийн бүртгэл дээр үндэслэсэн болно). Та энэ үйлчилгээг сонирхож байгаагаас үл хамааран ослын шалтгааныг оношлох, арилгахын тулд компанийн SRE инженерүүдийн сонгосон зам нь сургамжтай юм.
19-р сарын XNUMX-ний өглөө эрт (Зүүн өдрийн цагаар, EDT) quay.io үйлчилгээ эвдэрсэн. Энэхүү осол нь quay.io-ийн хэрэглэгчид болон програм хангамжийг бүтээх, түгээх платформ болгон quay.io-г ашигладаг Нээлттэй эхийн төслүүдэд хоёуланд нь нөлөөлсөн. Red Hat нь хоёулангийнх нь итгэлийг үнэлдэг.
SRE инженерүүдийн баг нэн даруй оролцож, Quay үйлчилгээг аль болох хурдан тогтворжуулахыг хичээсэн. Гэсэн хэдий ч, үүнийг хийж байх үед үйлчлүүлэгчид шинэ зургуудыг түлхэх чадвараа алдаж, хааяа л хуучин зургуудыг татаж чаддаг байв. Үл мэдэгдэх шалтгааны улмаас үйлчилгээг бүрэн хүчин чадлаараа өргөжүүлсний дараа quay.io мэдээллийн сан хаагдсан.
«Юу өөрчлөгдсөн бэ?" - энэ бол ийм тохиолдолд ихэвчлэн асуудаг анхны асуулт юм. Энэ асуудал гарахаас өмнөхөн OpenShift Dedicated кластер (quay.io ажиллуулдаг) 4.3.19 хувилбар руу шинэчлэгдэж эхэлснийг бид анзаарсан. Quay.io нь Red Hat OpenShift Dedicated (OSD) дээр ажилладаг тул тогтмол шинэчлэлтүүд нь ердийн байсан бөгөөд хэзээ ч асуудал үүсгэдэггүй. Түүнчлэн, өмнөх зургаан сарын хугацаанд бид Quay кластеруудыг үйлчилгээгээ тасалдуулалгүйгээр хэд хэдэн удаа сайжруулсан.
Биднийг уг үйлчилгээг сэргээх гэж оролдож байх үед бусад инженерүүд программ хангамжийн өмнөх хувилбартай шинэ OSD кластер бэлдэж эхэлсэн бөгөөд ингэснээр ямар нэг зүйл тохиолдвол бүх зүйлийг түүн дээр байрлуулж болно.
Үндэс шалтгааны шинжилгээ
Гэмтлийн гол шинж тэмдэг нь хэдэн арван мянган мэдээллийн сангийн холболтын нуранги байсан бөгөөд энэ нь MySQL инстанцыг үр дүнтэй ажиллах боломжгүй болгосон. Энэ нь асуудлыг оношлоход хүндрэл учруулсан. Бид SRE-ийн багт асуудлыг үнэлэхэд нь туслахын тулд үйлчлүүлэгчдийн холболтын дээд хязгаарыг тогтоосон. Бид мэдээллийн сан руу ямар нэгэн ер бусын урсгалыг анзаарсангүй: үнэндээ ихэнх хүсэлтийг уншсан бөгөөд цөөхөн нь бичдэг.
Бид мөн энэ нуранги үүсгэж болох мэдээллийн сангийн урсгалын хэв маягийг тодорхойлохыг оролдсон. Гэсэн хэдий ч бид логуудаас ямар ч хэв маягийг олж чадсангүй. OSD 4.3.18-тай шинэ кластер бэлэн болтол бид quay.io pods-ыг эхлүүлэхээр оролдсон. Кластер бүрэн хүчин чадлаараа ажиллах бүрт мэдээллийн сан хөлддөг. Энэ нь бүх quay.io pod-оос гадна RDS жишээг дахин эхлүүлэх шаардлагатай гэсэн үг юм.
Орой гэхэд бид үйлчилгээг зөвхөн уншигдах горимд тогтворжуулж, мэдээллийн сангийн ачааллыг багасгахын тулд аль болох олон чухал бус функцуудыг (жишээ нь нэрийн талбайн хог цуглуулах) идэвхгүй болгосон. Хөлдөлт зогссон гэхдээ шалтгааныг нь хэзээ ч олоогүй. Шинэ OSD кластер бэлэн болсон бөгөөд бид үйлчилгээг шилжүүлж, траффикийг холбож, хяналтыг үргэлжлүүлэв.
Quay.io нь шинэ OSD кластер дээр тогтвортой ажиллаж байсан тул бид өгөгдлийн сангийн бүртгэл рүү буцаж очсон боловч түгжрэлийг тайлбарлах хамаарлыг олж чадсангүй. OpenShift инженерүүд Red Hat OpenShift 4.3.19-д гарсан өөрчлөлт нь Quay-д асуудал үүсгэж болзошгүй эсэхийг ойлгохын тулд бидэнтэй хамтран ажилласан. Гэсэн хэдий ч юу ч олдсонгүй, мөн Лабораторийн нөхцөлд асуудлыг дахин гаргах боломжгүй байсан.
Хоёр дахь бүтэлгүйтэл
28-р сарын XNUMX-нд, EDT-ийн үдээс өмнөхөн quay.io ижил шинж тэмдгээр дахин унав: мэдээллийн сан хаагдсан. Дахин бид бүх хүчин чармайлтаа мөрдөн байцаалтад зориулав. Юуны өмнө үйлчилгээг сэргээх шаардлагатай байв. Гэсэн хэдий ч Энэ удаад RDS-г дахин ачаалж, quay.io pod-уудыг дахин эхлүүлсэн нь юу ч хийсэнгүй: дахин нэг холболтын нуранги баазыг дарсан. Гэхдээ яагаад?
Quay нь Python хэл дээр бичигдсэн бөгөөд pod тус бүр нь нэг цул сав шиг ажилладаг. Контейнерийн ажиллах хугацаа нь олон зэрэгцээ ажлуудыг нэгэн зэрэг гүйцэтгэдэг. Бид номын сан ашигладаг gevent дор gunicorn вэб хүсэлтийг боловсруулах. Quay-д хүсэлт ирэхэд (бидний API эсвэл Docker-ийн API-ээр) түүнд gevent ажилтан томилогддог. Ерөнхийдөө энэ ажилтан мэдээллийн сантай холбоо барих ёстой. Эхний бүтэлгүйтлийн дараа бид gevent-ийн ажилчид анхдагч тохиргоог ашиглан мэдээллийн санд холбогдож байгааг олж мэдсэн.
Их хэмжээний Quay pods болон секундэд олон мянган ирж буй хүсэлтүүдийг харгалзан үзэхэд олон тооны мэдээллийн сангийн холболтууд нь MySQL жишээг онолын хувьд хэтрүүлж болзошгүй юм. Хяналт шалгалтын ачаар Quay секундэд дунджаар 5 мянган хүсэлтийг боловсруулдаг болохыг мэдсэн. Өгөгдлийн санд холбогдсон холболтын тоо ойролцоогоор ижил байв. 5 мянган холболт нь манай RDS жишээний чадамжид бүрэн нийцэж байсан (энэ нь хэдэн арван мянган гэж хэлж болохгүй). Зарим шалтгааны улмаас холболтын тоо гэнэтийн огцом өсөлттэй байсанГэсэн хэдий ч бид ирж буй хүсэлтүүдтэй ямар ч хамаарлыг анзаарсангүй.
Энэ удаад бид дахин ачаалахаар хязгаарлагдахгүй, асуудлын эх үүсвэрийг олж, арилгахаар шийдсэн. Quay кодын сан руу ажилчин бүрийн мэдээллийн санд холбогдох тоог хязгаарлах өөрчлөлтийг хийсэн gevent. Энэ тоо нь тохиргооны параметр болсон: шинэ контейнерийн дүрсийг бүтээхгүйгээр шууд өөрчлөх боломжтой болсон. Хэдэн холболтыг бодитойгоор зохицуулж болохыг олж мэдэхийн тулд бид ачааллын туршилтын хувилбарт хэрхэн нөлөөлөхийг харахын тулд янз бүрийн утгыг тохируулан шатлалын орчинд хэд хэдэн туршилт явуулсан. Үүний үр дүнд үүнийг олж мэдсэн Quay холболтын тоо 502 мянгаас хэтэрсэн үед 10 алдаа гаргаж эхэлдэг.
Бид энэ шинэ хувилбарыг нэн даруй үйлдвэрлэлд нэвтрүүлж, мэдээллийн сангийн холболтын хуваарийг хянаж эхэлсэн. Өмнө нь 20 орчим минутын дараа баазыг хаадаг байсан. Асуудалгүй 30 минутын дараа бид итгэл найдвар төрүүлж, нэг цагийн дараа өөртөө итгэлтэй болсон. Бид сайт руу чиглэсэн урсгалыг сэргээж, үхлийн дараах шинжилгээг эхлүүлсэн.
Блоклоход хүргэсэн асуудлыг даван туулж чадсанаар, Бид түүний жинхэнэ шалтгааныг олж чадаагүй байна. Өмнө нь Quay-тай ямар ч асуудалгүй ажиллаж байсан 4.3.19 хувилбар дээр ижил зүйл тохиолдсон тул OpenShift 4.3.18-д гарсан өөрчлөлттэй холбоогүй нь батлагдсан.
Кластерт өөр зүйл нуугдаж байсан нь тодорхой.
Нарийвчилсан судалгаа
Quay.io нь үндсэн тохиргоог ашиглан өгөгдлийн сантай зургаан жилийн турш ямар ч асуудалгүй холбогдож байсан. Юу өөрчлөгдсөн бэ? Энэ бүх хугацаанд quay.io дээрх ачаалал тогтвортой өсч байгаа нь тодорхой байна. Манай тохиолдолд ямар нэгэн босго утгад хүрсэн юм шиг харагдаж байсан бөгөөд энэ нь холболтын нуранги үүсэхэд түлхэц болсон юм. Бид хоёр дахь бүтэлгүйтлийн дараа мэдээллийн сангийн бүртгэлийг үргэлжлүүлэн судалсан боловч ямар ч хэв маяг, тодорхой харилцаа холбоо олдсонгүй.
Энэ хооронд SRE баг Quay-ийн хүсэлтийг ажиглах чадвар болон үйлчилгээний ерөнхий байдлыг сайжруулахаар ажиллаж байна. Шинэ хэмжигдэхүүн болон хяналтын самбарыг байршуулсан, Quay-ийн аль хэсэг нь үйлчлүүлэгчдээс хамгийн их эрэлт хэрэгцээтэй байгааг харуулж байна.
Quay.io 9-р сарын XNUMX хүртэл сайн ажилласан. Өнөө өглөө (EDT) бид мэдээллийн сангийн холболтын тоо мэдэгдэхүйц нэмэгдсэнийг дахин харлаа. Энэ удаад завсарлага гарсангүй, учир нь шинэ параметр нь тэдний тоог хязгаарлаж, MySQL нэвтрүүлэх чадварыг хэтрүүлэхийг зөвшөөрөөгүй. Гэсэн хэдий ч хагас цагийн турш олон хэрэглэгчид quay.io-ийн удаан гүйцэтгэлийг тэмдэглэжээ. Бид нэмэлт хяналтын хэрэгслийг ашиглан боломжтой бүх мэдээллийг хурдан цуглуулсан. Гэнэт нэгэн хэв маяг гарч ирэв.
Холболт нэмэгдэхийн өмнөхөн App Registry API-д олон тооны хүсэлт ирсэн. App Registry бол quay.io-ийн бага зэрэг мэддэг функц юм. Энэ нь танд Helm диаграм, баялаг мета өгөгдөл бүхий контейнер зэрэг зүйлсийг хадгалах боломжийг олгодог. Ихэнх quay.io хэрэглэгчид энэ функцтэй ажилладаггүй ч Red Hat OpenShift үүнийг идэвхтэй ашигладаг. OpenShift-ийн нэг хэсэг болох OperatorHub нь бүх операторуудыг Програмын бүртгэлд хадгалдаг. Эдгээр операторууд нь OpenShift ажлын ачааллын экосистем болон түнш төвтэй үйлдлийн загвар (2 дахь өдрийн үйл ажиллагаа)-ын үндэс суурийг бүрдүүлдэг.
OpenShift 4 кластер бүр нь суурилуулсан OperatorHub-ийн операторуудыг ашиглан суулгаж болох операторуудын каталогийг нийтэлж, суулгасан хүмүүст шинэчлэлт өгдөг. OpenShift 4-ийн нэр хүнд өсөхийн хэрээр дэлхий даяар үүн дээрх кластеруудын тоо нэмэгдсээр байна. Эдгээр кластер бүр нь операторын агуулгыг татан авч суурилуулсан OperatorHub-ийг ажиллуулж, quay.io доторх Програмын бүртгэлийг арын хэсэг болгон ашигладаг. Асуудлын эх сурвалжийг хайх явцад бид OpenShift-ийн нэр хүнд аажмаар өсөхийн хэрээр ховор хэрэглэгддэг quay.io функцүүдийн нэгний ачаалал нэмэгдэж байгааг анзаарсангүй..
Бид Апп Бүртгэлийн хүсэлтийн урсгалд дүн шинжилгээ хийж, бүртгэлийн кодыг харлаа. Мэдээллийн сангийн асуулга оновчтой бүрдээгүйн улмаас дутагдлууд нэн даруй илэрсэн. Ачаалал багатай үед хүндрэл учруулдаггүй байсан ч ачаалал ихсэх үед асуудал үүсгэдэг. Апп бүртгэлд ачаалал ихсэхэд тийм ч сайн хариу өгөхгүй хоёр асуудалтай төгсгөлийн цэг байсан нь тогтоогдсон: эхнийх нь репозитор дахь бүх багцын жагсаалтыг гаргаж өгсөн бол хоёр дахь нь багцын бүх бөөгнөрөлүүдийг буцаан өгсөн.
Шалтгааныг арилгах
Дараагийн долоо хоногт бид Програмын бүртгэлийн код болон түүний орчныг оновчтой болгоход зарцуулсан. Үр дүнгүй SQL асуулгыг дахин боловсруулж, шаардлагагүй командын дуудлагыг арилгасан нь илт. tar (энэ нь blob-ыг олж авах болгонд ажиллуулж байсан), боломжтой бол кэшийг нэмсэн. Дараа нь бид гүйцэтгэлийн өргөн цар хүрээтэй туршилт хийж, өөрчлөлтийн өмнөх болон дараах програмын бүртгэлийн хурдыг харьцуулсан.
Өмнө нь хагас минут зарцуулдаг байсан API хүсэлтүүд одоо миллисекундэд дуусдаг. Дараагийн долоо хоногт бид үйлдвэрлэлд өөрчлөлт оруулсан бөгөөд түүнээс хойш quay.io тогтвортой ажиллаж байна. Энэ хугацаанд Апп Бүртгэлийн төгсгөлийн цэг дээр ачаалал хэд хэдэн огцом нэмэгдсэн боловч сайжруулалт хийснээр мэдээллийн сан тасрахаас сэргийлсэн.
Бид юу сурсан бэ?
Аливаа үйлчилгээ сул зогсолтоос зайлсхийхийг хичээдэг нь ойлгомжтой. Манай тохиолдолд сүүлийн үеийн тасалдал нь quay.io-г сайжруулахад тусалсан гэж бид үзэж байна. Бид хуваалцахыг хүссэн хэд хэдэн чухал сургамжийг олж авлаа:
- Таны үйлчилгээг хэн, хэрхэн ашигладаг тухай мэдээлэл хэзээ ч илүүдэхгүй. Quay "зүгээр л ажилласан" учраас бид замын хөдөлгөөнийг оновчтой болгож, ачааллыг зохицуулахад хэзээ ч цаг зарцуулдаггүй байсан. Энэ бүхэн нь үйлчилгээг хязгааргүй хэмжээгээр өргөжүүлж болох аюулгүй байдлын хуурамч мэдрэмжийг бий болгосон.
- Үйлчилгээ тасрахад, үүнийг сэргээх, ажиллуулах нь нэн тэргүүний зорилт юм.. Анхны тасалдал гарах үед Quay түгжигдсэн мэдээллийн сангаас болж зовж шаналж байсан тул бидний стандарт журам нь төлөвлөсөн үр дүнд хүрээгүй бөгөөд бид тэдгээрийг ашиглан үйлчилгээг сэргээх боломжгүй болсон. Энэ нь үйл ажиллагааг сэргээхэд бүх хүчин чармайлтаа төвлөрүүлэхийн оронд үндсэн шалтгааныг олохын тулд дүн шинжилгээ хийх, мэдээлэл цуглуулахад цаг хугацаа зарцуулах нөхцөл байдалд хүргэсэн.
- Үйлчилгээний онцлог бүрийн нөлөөллийг үнэл. Үйлчлүүлэгчид Програмын бүртгэлийг ховор ашигладаг байсан тул манай багийн хувьд энэ нь нэн тэргүүний асуудал биш байв. Бүтээгдэхүүний зарим функцийг бараг ашиглаагүй тохиолдолд алдаанууд нь ховор тохиолддог бөгөөд хөгжүүлэгчид кодыг хянахаа больдог. Ийм л байх ёстой гэсэн буруу ойлголтод автах нь амархан байдаг—энэ функц нь гэнэт томоохон үйл явдлын төвд орох хүртэл.
Дараа нь юу юм бэ?
Үйлчилгээний тогтвортой байдлыг хангах ажил хэзээ ч зогсохгүй, байнга сайжруулж байна. Quay.io дээр замын хөдөлгөөний хэмжээ өссөөр байгаа тул үйлчлүүлэгчдийнхээ итгэлийг дааж чадах бүхнээ хийх үүрэгтэй гэдгээ бид ойлгож байна. Тиймээс бид одоогоор дараах ажлуудыг хийж байна.
- Үндсэн RDS инстанттай холбоотой асуудал гарсан тохиолдолд үйлчилгээнд тохирох урсгалыг зохицуулахад туслахын тулд зөвхөн унших боломжтой мэдээллийн сангийн хуулбарыг байрлуул.
- RDS жишээг шинэчилж байна. Одоогийн хувилбар нь өөрөө асуудал биш юм. Үүний оронд бид зүгээр л хуурамч мөрийг арилгахыг хүсч байна (бүтэлгүйтлийн үед бидний дагаж байсан); Програм хангамжийг байнга шинэчилж байх нь ирээдүйд тасалдал гарах үед өөр хүчин зүйлийг арилгах болно.
- Бүх кластер даяар нэмэлт кэш хийх. Бид кэш нь мэдээллийн баазын ачааллыг бууруулах боломжтой газруудыг үргэлжлүүлэн хайж байна.
- Quay.io руу хэн, яагаад холбогдож байгааг харахын тулд вэб програмын галт хана (WAF) нэмж байна.
- Дараагийн хувилбараас эхлэн Red Hat OpenShift кластерууд Quay.io дээр байгаа контейнерийн зураг дээр суурилсан Операторын каталогийг ашиглахын тулд App Registry-ээс татгалзана.
- Апп бүртгэлийн урт хугацааны орлуулалт нь Нээлттэй Контейнер Санаачилга (OCI) олдворын техникийн үзүүлэлтүүдэд дэмжлэг үзүүлж болно. Энэ нь одоогоор үндсэн Quay функцээр хэрэгжиж байгаа бөгөөд техникийн үзүүлэлтүүд нь өөрөө шийдэгдэх үед хэрэглэгчид ашиглах боломжтой болно.
Дээр дурдсан бүх зүйл бол Red Hat-ийн quay.io-д хийж буй хөрөнгө оруулалтын нэг хэсэг бөгөөд бид жижиг "эхлэлийн маягийн" багаас SRE-д суурилсан төлөвшсөн платформ руу шилжиж байна. Манай олон хэрэглэгчид quay.io-г өдөр тутмын ажилдаа (түүний дотор Red Hat!) даатгадаг гэдгийг бид мэддэг бөгөөд бид сүүлийн үеийн тасалдал, сайжруулахын тулд хийж буй хүчин чармайлтын талаар аль болох ил тод байхыг хичээдэг.
Орчуулагчийн жич
Мөн манай блог дээрээс уншина уу:
- «";
- «";
- «".
Эх сурвалж: www.habr.com