Сайн уу, Хабр! Би бол системийн удирдлагын багийн ахлагч Артем Карамышев . Өнгөрсөн нэг жилийн хугацаанд бид олон шинэ бүтээгдэхүүн гаргасан. Бид API үйлчилгээг хялбархан өргөтгөх боломжтой, алдаатай, хэрэглэгчийн ачаалал хурдан өсөхөд бэлэн байлгахыг хүссэн. Манай платформ нь OpenStack дээр хэрэгжсэн бөгөөд алдааг тэсвэрлэх системийг бий болгохын тулд ямар бүрэлдэхүүн хэсгүүдийн эвдрэлийг тэсвэрлэх асуудлыг шийдэх ёстойг танд хэлэхийг хүсч байна. Энэ нь OpenStack дээр бүтээгдэхүүн хөгжүүлдэг хүмүүст сонирхолтой байх болно гэж би бодож байна.
Платформын эвдрэлийг тэсвэрлэх чадвар нь түүний бүрэлдэхүүн хэсгүүдийн уян хатан чанараас бүрдэнэ. Тиймээс бид эрсдэлийг тодорхойлж, хаасан бүх шат дамжлагыг аажмаар даван туулах болно.
Зохион байгуулсан Uptime day 4 бага хурлын үндсэн эх сурвалж нь энэхүү түүхийн видео хувилбар юм , та харж болно .
Физик архитектурын алдааг тэсвэрлэх чадвар
MCS үүлний нийтийн хэсэг нь одоо хоёр түвшний III дата төвд суурилсан бөгөөд тэдгээрийн хооронд өөр өөр маршрутаар физик түвшинд хадгалагдсан, 200 Гбит/с дамжуулах хүчин чадалтай өөрийн гэсэн бараан шилэн утас байрладаг. III шат нь физик дэд бүтцэд шаардлагатай гэмтэл тэсвэрлэх чадварыг хангадаг.
Харанхуй эслэг нь физик болон логик түвшинд хадгалагддаг. Сувгийн захиалгын үйл явц давтагдсан, асуудал үүссэн, бид дата төв хоорондын харилцаа холбоог байнга сайжруулж байна.
Жишээлбэл, саяхан нэг мэдээллийн төвийн ойролцоох худагт ажиллаж байхдаа экскаватор хоолой хагарч, энэ хоолойн дотор гол болон нөөц оптик кабель хоёулаа байсан. Дата төвтэй манай гэмтэлд тэсвэртэй харилцаа холбооны суваг нэг цэгт, худагт эмзэг болсон. Үүний дагуу бид дэд бүтцийнхээ тодорхой хэсгийг алдсан. Бид дүгнэлт хийж, зэргэлдээх худагт нэмэлт оптик суурилуулах зэрэг хэд хэдэн арга хэмжээ авсан.
Дата төвүүдэд бидний угтварыг BGP-ээр дамжуулдаг харилцаа холбооны үйлчилгээ үзүүлэгчид байдаг цэгүүд байдаг. Сүлжээний чиглэл бүрийн хувьд хамгийн сайн хэмжигдэхүүнийг сонгосон бөгөөд энэ нь өөр өөр үйлчлүүлэгчдийг хамгийн сайн холболтын чанараар хангах боломжийг олгодог. Хэрэв нэг үйлчилгээ үзүүлэгчээр дамжуулан холбоо тасарсан бол бид боломжит үйлчилгээ үзүүлэгчээр дамжуулан чиглүүлээ сэргээнэ.
Хэрэв үйлчилгээ үзүүлэгч амжилтгүй болвол бид автоматаар дараагийнх руу шилжинэ. Хэрэв дата төвүүдийн аль нэг нь ажиллахаа больсон тохиолдолд бид хоёр дахь дата төвд үйлчилгээнийхээ толин тусгал хуулбартай бөгөөд энэ нь ачааллыг бүхэлд нь үүрдэг.
Физик дэд бүтцийн уян хатан байдал
Хэрэглээний түвшний алдааг тэсвэрлэхэд бидний ашигладаг зүйл
Манай үйлчилгээ нь хэд хэдэн нээлттэй эхийн бүрэлдэхүүн хэсгүүд дээр суурилагдсан.
ExaBGP нь BGP-д суурилсан динамик чиглүүлэлтийн протоколыг ашиглан хэд хэдэн функцийг хэрэгжүүлдэг үйлчилгээ юм. Бид үүнийг хэрэглэгчдэд API-д нэвтрэх зөвшөөрөлтэй IP хаягуудаа сурталчлахад идэвхтэй ашигладаг.
HAProxy нь OSI загварын янз бүрийн түвшинд маш уян хатан хөдөлгөөн тэнцвэржүүлэх дүрмийг тохируулах боломжийг олгодог өндөр ачаалал тэнцвэржүүлэгч юм. Бид үүнийг бүх үйлчилгээний өмнө тэнцвэржүүлэхэд ашигладаг: мэдээллийн сан, мессеж брокер, API үйлчилгээ, вэб үйлчилгээ, бидний дотоод төслүүд - бүх зүйл HAProxy-ийн ард байдаг.
API програм — Хэрэглэгч өөрийн дэд бүтэц, үйлчилгээгээ удирддаг python хэл дээр бичигдсэн вэб програм.
Ажилчдын өргөдөл (цаашид энгийн ажилтан) - OpenStack үйлчилгээнд энэ нь API тушаалуудыг дэд бүтцэд дамжуулах боломжийг олгодог дэд бүтцийн демон юм. Жишээлбэл, диск үүсгэх нь ажилчинд, үүсгэх хүсэлт нь програмын API-д тохиолддог.
Стандарт OpenStack програмын архитектур
OpenStack-д зориулсан ихэнх үйлчилгээнүүд нэг парадигмыг дагахыг хичээдэг. Үйлчилгээ нь ихэвчлэн 2 хэсгээс бүрдэнэ: API ба ажилчид (арын гүйцэтгэгчид). Дүрмээр бол API нь бие даасан процесс (демон) хэлбэрээр эсвэл бэлэн Nginx эсвэл Apache вэб сервер ашиглан эхлүүлсэн python хэл дээрх WSGI програм юм. API нь хэрэглэгчийн хүсэлтийг боловсруулж, гүйцэтгэх зааварчилгааг ажилчны програм руу дамжуулдаг. Шилжүүлгийг мессеж брокер, ихэвчлэн RabbitMQ ашиглан хийдэг, бусад нь муу дэмжигддэг. Мессежүүд брокерт хүрэх үед тэдгээрийг ажилчид боловсруулж, шаардлагатай бол хариу өгнө.
Энэхүү парадигм нь бүтэлгүйтлийн тусгаарлагдсан нийтлэг цэгүүдийг агуулдаг: RabbitMQ болон мэдээллийн сан. Гэхдээ RabbitMQ нь нэг үйлчилгээнд тусгаарлагдсан бөгөөд онолын хувьд үйлчилгээ тус бүрт хувь хүн байж болно. Тиймээс MCS-д бид эдгээр үйлчилгээг аль болох тусад нь тусад нь төсөл тус бүрд зориулж тусдаа мэдээллийн сан, тусдаа RabbitMQ үүсгэдэг. Зарим эмзэг цэгт осол гарсан тохиолдолд үйлчилгээ бүхэлдээ биш, зөвхөн нэг хэсэг нь эвдэрдэг тул энэ арга нь сайн хэрэг юм.
Ажилчдын хэрэглээний тоо хязгааргүй тул API нь гүйцэтгэл болон алдааны тэсвэржилтийг нэмэгдүүлэхийн тулд тэнцвэржүүлэгчийн ард хэвтээ байдлаар хялбархан масштаблах боломжтой.
API болон ажилчдын хооронд нарийн төвөгтэй дараалсан үйлдлүүд гарах үед зарим үйлчилгээ нь үйлчилгээний хүрээнд зохицуулалт шаарддаг. Энэ тохиолдолд нэг зохицуулалтын төв, Redis, Memcache гэх мэт кластер системийг ашигладаг бөгөөд энэ нь нэг ажилчинд өөрт нь энэ даалгавар өгсөн гэдгийг хэлэх боломжийг олгодог ("Үүнийг бүү ав"). Бид гэх мэтийг ашигладаг. Дүрмээр бол ажилчид мэдээллийн сантай идэвхтэй харилцаж, тэндээс мэдээлэл бичиж, уншдаг. Бид multimaster кластерт байрладаг мэдээллийн сан болгон mariadb ашигладаг.
Энэхүү сонгодог ганц үйлчилгээ нь OpenStack-д нийтлэг хүлээн зөвшөөрөгдсөн байдлаар зохион байгуулагдсан. Үүнийг хаалттай систем гэж үзэж болох бөгөөд түүний хувьд масштаблах, алдааг тэсвэрлэх аргууд нь маш тодорхой байдаг. Жишээлбэл, API алдааг тэсвэрлэхийн тулд тэдгээрийн өмнө тэнцвэржүүлэгч тавихад хангалттай. Ажилчдын тоог нэмэгдүүлэх замаар тэдний тоог нэмэгдүүлнэ.
Бүхэл бүтэн схемийн сул тал бол RabbitMQ болон MariaDB юм. Тэдний архитектур нь тусдаа нийтлэл байх ёстой. Энэ нийтлэлд би API алдааны хүлцэл дээр анхаарлаа хандуулахыг хүсч байна.
Openstack програмын архитектур. Үүл платформыг тэнцвэржүүлэх, алдааг тэсвэрлэх чадвар
ExaBGP ашиглан HAProxy тэнцвэржүүлэгчийг гэмтэлд тэсвэртэй болгох
API-уудаа өргөтгөх боломжтой, хурдан бөгөөд алдаа гаргахад тэсвэртэй болгохын тулд бид ачааллын тэнцвэржүүлэгчийг өмнө нь тавьдаг. Бид HAProxy-г сонгосон. Миний бодлоор энэ нь бидний даалгаварт шаардлагатай бүх шинж чанаруудтай: OSI-ийн хэд хэдэн түвшинд тэнцвэржүүлэх, удирдлагын интерфейс, уян хатан байдал, өргөтгөх чадвар, олон тооны тэнцвэржүүлэх аргууд, сессийн хүснэгтүүдийг дэмжих.
Шийдэх ёстой хамгийн эхний асуудал бол тэнцвэржүүлэгчийн эвдрэлийг тэсвэрлэх чадвар байв. Энгийнээр тэнцвэржүүлэгчийг суулгах нь бас бүтэлгүйтлийн цэгийг бий болгодог: тэнцвэржүүлэгч эвдэрч, үйлчилгээ гацдаг. Үүнээс урьдчилан сэргийлэхийн тулд бид HAProxy-г ExaBGP-тэй хамт ашигласан.
ExaBGP нь үйлчилгээний төлөв байдлыг шалгах механизмыг хэрэгжүүлэх боломжийг танд олгоно. Бид энэ механизмыг ашиглан HAProxy-ийн ажиллагааг шалгаж, асуудал гарвал BGP-ээс HAProxy үйлчилгээг идэвхгүй болгосон.
ExaBGP+HAProxy схем
- Бид шаардлагатай программ хангамж болох ExaBGP болон HAProxy-г гурван сервер дээр суулгадаг.
- Бид сервер бүр дээр давталтын интерфэйс үүсгэдэг.
- Гурван сервер дээр бид энэ интерфейс рүү ижил цагаан IP хаягийг өгдөг.
- Цагаан IP хаягийг ExaBGP-ээр дамжуулан интернетэд сурталчилдаг.
Гурван серверээс ижил IP хаягийг сурталчлах замаар алдааг тэсвэрлэх чадвартай болно. Сүлжээний үүднээс авч үзвэл ижил хаяг нь гурван өөр өөр хопоос хандах боломжтой. Чиглүүлэгч нь гурван ижил чиглэлийг харж, өөрийн хэмжүүр дээр үндэслэн тэдгээрийн хамгийн чухал ач холбогдолтойг нь сонгодог (энэ нь ихэвчлэн ижил сонголт байдаг) бөгөөд траффик нь зөвхөн серверүүдийн аль нэгэнд очдог.
HAProxy-ийн үйл ажиллагаанд асуудал гарсан эсвэл серверийн доголдол гарсан тохиолдолд ExaBGP маршрутыг зарлахаа больж, урсгал нь өөр сервер рүү жигд шилждэг.
Тиймээс бид тэнцвэржүүлэгчийн алдааг тэсвэрлэх чадвартай болсон.
HAProxy тэнцвэржүүлэгчийн алдааг тэсвэрлэх чадвар
Энэ схем нь төгс бус болсон: бид HAProxy-г хэрхэн нөөцлөх талаар сурсан боловч үйлчилгээний хүрээнд ачааллыг хэрхэн хуваарилах талаар сураагүй. Тиймээс бид энэ схемийг бага зэрэг өргөжүүлэв: бид хэд хэдэн цагаан IP хаягуудын хооронд тэнцвэржүүлэх рүү шилжсэн.
DNS нэмэх BGP дээр суурилсан тэнцвэржүүлэх
Манай HAProxy-ийн ачааллыг тэнцвэржүүлэх асуудал шийдэгдээгүй хэвээр байна. Гэсэн хэдий ч бид энд хийсэн шиг үүнийг маш энгийнээр шийдэж болно.
Гурван серверийг тэнцвэржүүлэхийн тулд танд 3 цагаан IP хаяг, хуучин сайн DNS хэрэгтэй болно. Эдгээр хаяг бүрийг HAProxy бүрийн давталтын интерфэйс дээр тодорхойлж, интернетэд сурталчилдаг.
OpenStack-д нөөцийг удирдахын тулд тухайн үйлчилгээний төгсгөлийн API-г зааж өгдөг үйлчилгээний лавлахыг ашигладаг. Энэ санд бид гурван өөр IP хаягаар DNS-ээр шийдэгддэг public.infra.mail.ru домэйн нэрийг бүртгэдэг. Үүний үр дүнд бид DNS-ээр дамжуулан гурван хаягийн хооронд ачааллын хуваарилалтыг авдаг.
Гэхдээ цагаан IP хаягийг зарлахдаа бид серверийн сонголтын тэргүүлэх чиглэлийг хянадаггүй тул энэ нь хараахан тэнцвэржээгүй байна. Ер нь IP хаягийн насжилтаар зөвхөн нэг сервер сонгогдох ба нөгөө хоёр нь BGP-д ямар ч хэмжүүр заагаагүй тул идэвхгүй байх болно.
Бид ExaBGP-ээр дамжуулан өөр өөр хэмжүүрээр маршрут илгээж эхэлсэн. Тэнцвэржүүлэгч бүр бүх гурван цагаан IP хаягийг сурталчилдаг боловч тэдгээрийн нэг нь, энэ тэнцвэржүүлэгчийн гол хаягийг хамгийн бага хэмжүүрээр сурталчилдаг. Тиймээс гурван тэнцвэржүүлэгч бүгд ажиллаж байх үед эхний IP хаяг руу залгасан дуудлага нь эхний тэнцвэржүүлэгч рүү, хоёр дахь руу залгах, гурав дахь нь гуравдахь руу залгана.
Тэнцвэржүүлэгчдийн аль нэг нь унахад юу болох вэ? Хэрэв тэнцвэржүүлэгч бүтэлгүйтсэн бол түүний үндсэн хаягийг нөгөө хоёроос нь сурталчилж, урсгалыг хооронд нь дахин хуваарилдаг. Тиймээс бид DNS-ээр дамжуулан хэрэглэгчдэд хэд хэдэн IP хаягийг нэг дор өгдөг. DNS болон өөр өөр хэмжүүрээр тэнцвэржүүлснээр бид бүх гурван тэнцвэржүүлэгчийн ачааллыг жигд хуваарилдаг. Үүний зэрэгцээ бид алдааг тэсвэрлэх чадвараа алддаггүй.
DNS + BGP дээр суурилсан HAProxy-г тэнцвэржүүлэх
ExaBGP болон HAProxy хоорондын харилцан үйлчлэл
Тиймээс бид чиглүүлэлтийн зарыг зогсоосны үндсэн дээр серверийг орхих тохиолдолд алдааг тэсвэрлэх чадварыг хэрэгжүүлсэн. Гэхдээ HAProxy нь серверийн доголдлоос бусад шалтгааны улмаас унтарч болно: удирдлагын алдаа, үйлчилгээний доголдол. Эдгээр тохиолдолд бид эвдэрсэн тэнцвэржүүлэгчийг ачааллаас нь салгахыг хүсч байгаа бөгөөд бидэнд өөр механизм хэрэгтэй.
Тиймээс өмнөх схемийг өргөжүүлснээр бид ExaBGP болон HAProxy хооронд зүрхний цохилтыг хэрэгжүүлсэн. Энэ нь ExaBGP болон HAProxy хоорондын харилцан үйлчлэлийн програм хангамжийн хэрэгжилт бөгөөд ExaBGP нь програмуудын статусыг шалгахын тулд захиалгат скриптүүдийг ашигладаг.
Үүнийг хийхийн тулд та HAProxy-ийн статусыг шалгах боломжтой ExaBGP тохиргоонд эрүүл мэндийн шалгагчийг тохируулах хэрэгтэй. Манай тохиолдолд бид HAProxy-д эрүүл мэндийн арын хэсгийг тохируулсан бөгөөд ExaBGP талаас бид энгийн GET хүсэлтээр шалгадаг. Хэрэв мэдэгдэл гарахаа больсон бол HAProxy ажиллахгүй байх магадлалтай бөгөөд үүнийг сурталчлах шаардлагагүй болно.
HAProxy эрүүл мэндийн үзлэг
HAProxy Peers: сешн синхрончлол
Дараагийн хийх зүйл бол сессүүдийг синхрончлох явдал байв. Тархсан тэнцвэржүүлэгчээр ажиллахдаа үйлчлүүлэгч сессийн талаарх мэдээллийг хадгалах ажлыг зохион байгуулахад хэцүү байдаг. Гэхдээ HAProxy бол Peers функцийн улмаас үүнийг хийж чадах цөөхөн тэнцвэржүүлэгчдийн нэг юм - өөр өөр HAProxy процессуудын хооронд сессийн хүснэгтүүдийг шилжүүлэх чадвар.
Тэнцвэржүүлэх янз бүрийн аргууд байдаг: энгийн гэх мэт Үйлчлүүлэгчийн сессийг санаж, өмнөхтэй нь ижил сервер дээр дуусах бүрт , өргөтгөх боломжтой. Бид хоёр дахь хувилбарыг хэрэгжүүлэхийг хүссэн.
HAProxy нь энэ механизмын үйлчлүүлэгчийн сешнүүдийг хадгалахын тулд зөөгч хүснэгтүүдийг ашигладаг. Тэд үйлчлүүлэгчийн анхны IP хаяг, сонгосон зорилтот хаяг (арын хэсэг) болон үйлчилгээний зарим мэдээллийг хадгалдаг. Ихэвчлэн зөөгч хүснэгтүүдийг эх үүсвэр-IP + очих газар-IP хосыг хадгалахад ашигладаг бөгөөд энэ нь RoundRobin тэнцвэржүүлэх горимд өөр тэнцвэржүүлэгч рүү шилжих үед хэрэглэгчийн сессийн контекстийг шилжүүлэх боломжгүй програмуудад ялангуяа ашигтай байдаг.
Хэрэв зөөгч ширээг өөр өөр HAProxy процессуудын хооронд шилжүүлэхийг заадаг бол (энэ хооронд тэнцвэржүүлэлт үүсдэг) манай тэнцвэржүүлэгчид нэг савхан ширээтэй ажиллах боломжтой болно. Энэ нь тэнцвэржүүлэгчдийн аль нэг нь бүтэлгүйтсэн тохиолдолд үйлчлүүлэгчийн сүлжээг саадгүй өөрчлөх боломжийг олгоно;
Зөв ажиллахын тулд сесс үүсгэсэн тэнцвэржүүлэгчийн эх IP хаягийн асуудлыг шийдэх ёстой. Манай тохиолдолд энэ нь давталтын интерфэйс дээрх динамик хаяг юм.
Үе тэнгийнхний зөв ажил нь зөвхөн тодорхой нөхцөлд л хүрдэг. Өөрөөр хэлбэл, TCP сессийг дуусгах цаг байхгүй байхын тулд TCP-ийн хугацаа хангалттай том байх ёстой эсвэл шилжих нь хангалттай хурдан байх ёстой. Гэсэн хэдий ч энэ нь саадгүй шилжих боломжийг олгодог.
IaaS-д бид ижил технологи ашиглан бүтээсэн үйлчилгээтэй. Энэ , үүнийг Octavia гэж нэрлэдэг. Энэ нь хоёр HAProxy процесс дээр суурилдаг бөгөөд эхлээд үе тэнгийнхний дэмжлэгийг агуулдаг. Тэд энэ үйлчилгээнд маш сайн гэдгээ баталсан.
Зурган дээр гурван HAProxy тохиолдлын хоорондох үе тэнгийн хүснэгтүүдийн хөдөлгөөнийг схемээр харуулсан бөгөөд үүнийг хэрхэн тохируулах талаар тохиргоог санал болгож байна:
HAProxy Peers (сесс синхрончлол)
Хэрэв та ижил схемийг хэрэгжүүлбэл түүний ажиллагааг сайтар шалгаж үзэх хэрэгтэй. Энэ нь 100% ижил хэлбэрээр ажиллах болно гэдэг нь үнэн биш юм. Гэхдээ ядаж л үйлчлүүлэгчийн эх IP хаягийг санах хэрэгтэй үед та зөөгч хүснэгтээ алдахгүй.
Нэг үйлчлүүлэгчийн нэгэн зэрэг хүсэлтийн тоог хязгаарлах
Манай API зэрэг олон нийтэд нээлттэй аливаа үйлчилгээ нь хүсэлтийн дагуу ажиллах боломжтой. Тэдний шалтгаан нь хэрэглэгчийн алдаанаас эхлээд зорилтот халдлага хүртэл огт өөр байж болно. Бид үе үе IP хаягаар DDoS хийдэг. Үйлчлүүлэгчид ихэвчлэн скрипт дээрээ алдаа гаргаж, бидэнд мини-DDoS өгдөг.
Ямар ч тохиолдолд нэмэлт хамгаалалтыг хангах ёстой. Мэдээжийн шийдэл бол API хүсэлтийн тоог хязгаарлаж, хортой хүсэлтийг боловсруулахад CPU-ийн цагийг үрэхгүй байх явдал юм.
Ийм хязгаарлалтыг хэрэгжүүлэхийн тулд бид ижил зөөгч хүснэгтүүдийг ашиглан HAProxy дээр суурилсан тарифын хязгаарыг ашигладаг. Хязгаарыг тохируулах нь маш энгийн бөгөөд хэрэглэгчийг API-д өгсөн хүсэлтийн тоогоор хязгаарлах боломжийг олгодог. Алгоритм нь хүсэлт гаргасан эх сурвалжийн IP-г санаж, нэг хэрэглэгчийн нэгэн зэрэг хүсэлтийн тоог хязгаарладаг. Мэдээжийн хэрэг, бид үйлчилгээ тус бүрийн API ачааллын дундаж профайлыг тооцоолж, энэ утгыг ≈ 10 дахин их хэмжээгээр тогтоосон. Бид нөхцөл байдлыг анхааралтай ажиглаж, судасны цохилтыг хуруугаараа үргэлжлүүлсээр байна.
Энэ нь практик дээр ямар харагддаг вэ? Манай автомат масштабын API-г байнга ашигладаг үйлчлүүлэгчид бидэнд бий. Тэд өглөө хоёроос гурван зуун виртуал машин үүсгэж, орой нь устгадаг. OpenStack-ийн хувьд PaaS үйлчилгээнүүдтэй виртуал машин үүсгэхэд дор хаяж 1000 API хүсэлт шаардагдана, учир нь үйлчилгээ хоорондын харилцан үйлчлэл нь API-ээр дамждаг.
Ийм даалгаврыг шилжүүлэх нь нэлээд их ачаалал үүсгэдэг. Бид энэ ачааллыг үнэлж, өдөр тутмын оргилуудыг цуглуулж, арав дахин өсгөж, энэ нь бидний тарифын хязгаар болсон. Бид хуруугаа импульс дээр байлгадаг. Бидэнд ажиллах боломжтой CGA скрипт байгаа эсэхийг харах гэж байгаа роботууд болон сканнеруудыг бид байнга хардаг тул бид идэвхтэй хайчилж байна.
Хэрэглэгчид анзааралгүй кодын санг хэрхэн шинэчлэх вэ
Бид мөн кодыг байршуулах үйл явцын түвшинд алдааг тэсвэрлэх чадварыг хэрэгжүүлдэг. Дамжуулах явцад алдаа гарч болзошгүй ч үйлчилгээний хүртээмжид үзүүлэх нөлөөллийг багасгах боломжтой.
Бид үйлчилгээгээ байнга шинэчилж, кодын баазыг хэрэглэгчдэд нөлөөлөхгүйгээр шинэчилж байх ёстой. Бид HAProxy-ийн удирдлагын чадавхи болон Graceful Shutdown-ийг үйлчилгээндээ нэвтрүүлснээр энэ асуудлыг шийдэж чадсан.
Энэ асуудлыг шийдэхийн тулд тэнцвэржүүлэгчийн хяналт, үйлчилгээг "зөв" зогсоох шаардлагатай байв.
- HAProxy-ийн хувьд хяналтыг статистик файлаар гүйцэтгэдэг бөгөөд энэ нь үндсэндээ залгуур бөгөөд HAProxy тохиргоонд тодорхойлогддог. Та stdio-ээр дамжуулан түүнд тушаал илгээх боломжтой. Гэхдээ бидний үндсэн тохиргооны хяналтын хэрэгсэл нь боломжтой тул HAProxy-г удирдах модультай. Үүнийг бид идэвхтэй ашигладаг.
- Манай API болон Хөдөлгүүрийн үйлчилгээнүүдийн ихэнх нь унтрах гайхалтай технологийг дэмждэг: унтрах үед тэд http хүсэлт эсвэл үйлчилгээний ажил ч бай одоогийн ажлыг дуусгахыг хүлээдэг. Ажилчинтай ижил зүйл тохиолддог. Энэ нь хийж буй бүх ажлаа мэддэг бөгөөд бүх зүйлийг амжилттай дуусгасны дараа дуусдаг.
Эдгээр хоёр цэгийн ачаар бидний байршуулах аюулгүй алгоритм нь иймэрхүү харагдаж байна.
- Хөгжүүлэгч нь шинэ багц кодын (бидний хувьд энэ нь RPM) угсарч, хөгжүүлэлтийн орчинд туршиж, үе шатанд туршиж, тайзны репозиторт үлдээдэг.
- Хөгжүүлэгч нь "олдворууд" -ын хамгийн нарийвчилсан тайлбар бүхий байршуулах даалгаврыг тавьдаг: шинэ багцын хувилбар, шинэ функцийн тодорхойлолт, шаардлагатай бол байршуулах талаархи бусад дэлгэрэнгүй мэдээлэл.
- Системийн администратор шинэчлэлтийг эхлүүлнэ. Ansible тоглоомын номыг ажиллуулдаг бөгөөд энэ нь эргээд дараахь зүйлийг хийдэг.
- Тайзны репозитороос багц авч, бүтээгдэхүүний агуулах дахь багцын хувилбарыг шинэчлэхэд ашигладаг.
- Шинэчлэгдсэн үйлчилгээний арын хэсгийн жагсаалтыг эмхэтгэдэг.
- HAProxy-д шинэчлэгдсэн анхны үйлчилгээг унтрааж, процессууд нь ажиллаж дуусахыг хүлээнэ. Сайхан унтраасны ачаар одоо байгаа бүх үйлчлүүлэгчийн хүсэлтийг амжилттай биелүүлнэ гэдэгт бид итгэлтэй байна.
- API болон ажилчдыг бүрэн зогсоосны дараа HAProxy-г унтраасны дараа код шинэчлэгдэнэ.
- Ansible үйлчилгээ эрхэлдэг.
- Үйлчилгээ бүрийн хувьд тодорхой "бариулууд" татагддаг бөгөөд тэдгээр нь урьдчилан тодорхойлсон хэд хэдэн түлхүүрийн туршилтууд дээр нэгжийн туршилт хийдэг. Шинэ кодын үндсэн шалгалт явагдана.
- Хэрэв өмнөх алхамд алдаа олдоогүй бол арын хэсгийг идэвхжүүлнэ.
- Дараагийн арын хэсэг рүү шилжье.
- Бүх арын хэсгийг шинэчилсний дараа функциональ туршилтуудыг эхлүүлнэ. Хэрэв тэдгээр нь байхгүй бол хөгжүүлэгч өөрийн бүтээсэн аливаа шинэ функцийг хардаг.
Энэ нь байршуулалтыг дуусгана.
Үйлчилгээний шинэчлэлтийн мөчлөг
Хэрэв бидэнд нэг дүрэм байхгүй бол энэ схем ажиллахгүй байсан. Бид тулалдаанд хуучин болон шинэ хувилбаруудыг хоёуланг нь дэмждэг. Урьдчилан, програм хангамж боловсруулах үе шатанд үйлчилгээний мэдээллийн санд өөрчлөлт орсон ч өмнөх кодыг зөрчихгүй байхаар заасан. Үүний үр дүнд кодын суурь аажмаар шинэчлэгддэг.
дүгнэлт
Гэмтэлд тэсвэртэй WEB архитектурын талаар өөрийн бодлоо хуваалцахдаа би түүний гол санааг дахин тэмдэглэхийг хүсч байна.
- бие махбодийн эвдрэлийг тэсвэрлэх чадвар;
- сүлжээний алдааг тэсвэрлэх чадвар (тэнцвэржүүлэгч, BGP);
- ашигласан болон хөгжүүлсэн програм хангамжийн алдааг тэсвэрлэх чадвар.
Хүн бүрт тогтвортой ажиллах хугацаа!
Эх сурвалж: www.habr.com
