Орчин үеийн вэбийг хэвлэл мэдээллийн агуулгагүйгээр бараг төсөөлөхийн аргагүй юм: бараг бүх эмээ ухаалаг утастай, хүн бүр олон нийтийн сүлжээнд байдаг, үйлчилгээний тасалдал нь компаниудад үнэтэй байдаг. Таны анхааралд тус компанийн түүхийн хуулбарыг хүргэж байна Тэр техник хангамжийн шийдлийг ашиглан зураг хүргэх ажлыг хэрхэн зохион байгуулсан, гүйцэтгэлийн явцад ямар асуудал тулгарсан, тэдгээр нь юунаас үүдэлтэй, Nginx дээр суурилсан програм хангамжийн шийдлийг ашиглан эдгээр асуудлуудыг хэрхэн шийдвэрлэж, бүх түвшинд алдааны тэсвэр тэвчээрийг хангасан тухай (). Олег түүхийн зохиогчдод баярлалаа Хуралд туршлагаа хуваалцсан Ефимова, Александра Дымова нар .
Зургийг хэрхэн хадгалах, кэш хийх талаар бяцхан танилцуулгаас эхэлцгээе. Бидэнд тэдгээрийг хадгалах давхарга, мөн зургийг кэшлэх давхарга байдаг. Үүний зэрэгцээ, хэрэв бид том заль мэх хийж, хадгалах сангийн ачааллыг багасгахыг хүсч байвал хувь хүний хувь хүний зураг бүр нэг кэш сервер дээр байх нь бидний хувьд чухал юм. Үгүй бол бид олон сервертэй болохоос хэд дахин олон диск суулгах хэрэгтэй болно. Бидний хитийн хувь 99 орчим хувьтай байна, өөрөөр хэлбэл бид хадгалах санныхаа ачааллыг 100 дахин бууруулж, үүнийг хийхийн тулд 10 жилийн өмнө, энэ бүхэн баригдаж байх үед бид 50 сервертэй байсан. Үүний дагуу эдгээр зургуудыг өгөхийн тулд бидэнд эдгээр серверт үйлчилдэг 50 гадаад домэйн хэрэгтэй байсан.
Мэдээжийн хэрэг, тэр даруй асуулт гарч ирэв: хэрэв манай серверүүдийн аль нэг нь унтарч ажиллахгүй бол бид траффикийн аль хэсгийг алдах вэ? Бид зах зээл дээр байгаа зүйлийг хараад, бидний бүх асуудлыг шийдэхийн тулд нэг ширхэг төмөр авахаар шийдсэн. Сонголт нь F5 сүлжээний компанийн шийдэл дээр унасан (дашрамд хэлэхэд, NGINX, Inc-ийг саяхан худалдаж авсан): BIG-IP Local Traffic Manager.
Энэ төмөр (LTM) нь юу хийдэг вэ: энэ нь төмөр чиглүүлэгч бөгөөд гадаад портуудынхаа төмрийн нөөцийг нэмэгдүүлж, сүлжээний топологи, зарим тохиргоонд тулгуурлан урсгалыг чиглүүлэх, эрүүл мэндийн үзлэг хийх боломжийг олгодог. Энэ төмрийг програмчлах боломжтой байх нь бидний хувьд чухал байсан. Үүний дагуу бид тодорхой хэрэглэгчийн зургийг тодорхой кэшээс хэрхэн буцаасан логикийг тайлбарлаж болно. Энэ юу шиг харагдаж байна? Нэг домэйн, нэг ip-ийн интернетийг хардаг, ssl-г буулгадаг, http хүсэлтийг задлан шинжилдэг, IRule-ээс кэшийн дугаар, хаашаа явах, тэнд очих урсгалыг зөвшөөрдөг техник хангамж байдаг. Үүний зэрэгцээ энэ нь эрүүл мэндийн үзлэг хийдэг бөгөөд машин байхгүй тохиолдолд бид траффикийг тухайн үед нэг нөөц сервер рүү шилжүүлэхээр болгосон. Тохиргооны үүднээс авч үзвэл мэдээжийн хэрэг зарим нэг нюансууд байдаг, гэхдээ ерөнхийдөө бүх зүйл маш энгийн: бид газрын зургийг зааж өгдөг, тодорхой тоо нь сүлжээн дэх бидний IP-тэй тохирч, бид 80 порт дээр сонсох болно гэж хэлдэг. болон 443, хэрэв сервер ажиллахгүй бол та траффикийг нөөц рүү шилжүүлэх хэрэгтэй гэж бид хэлж байна, энэ тохиолдолд 35 дахь бөгөөд энэ архитектурыг хэрхэн задлах талаар олон тооны логикийг тайлбарлав. Ганц асуудал нь төмрийг програмчлах хэл нь Tcl хэл юм. Хэрэв хэн нэгэн үүнийг санаж байвал ... энэ хэл нь програмчлахад тохиромжтой хэлээс илүү зөвхөн бичихэд зориулагдсан хэл юм:
Бид юу авсан бэ? Бид дэд бүтцийнхээ өндөр хүртээмжийг хангадаг, бүх урсгалыг чиглүүлдэг, эрүүл мэндийн үзлэгт хамруулдаг, зүгээр л ажилладаг техник хангамжтай болсон. Түүнээс гадна, энэ нь нэлээд удаан хугацаанд ажиллаж байна: сүүлийн 10 жилийн хугацаанд энэ талаар ямар ч гомдол гараагүй. 2018 оны эхээр бид секундэд 80 мянга орчим зураг үзүүлж байсан. Энэ нь манай хоёр дата төвөөс ойролцоогоор 80 гигабит траффик юм.
Гэхдээ ...
2018 оны эхээр бид чартууд дээр муухай зургийг харсан: зургуудыг буцааж өгөх хугацаа тодорхой нэмэгдсэн. Тэгээд энэ нь бидэнд тохирохоо больсон. Асуудал нь энэ зан үйл нь зөвхөн хөдөлгөөний оргил үед л харагддаг байсан - манай компанийн хувьд энэ бол Ням гарагаас Даваа гараг хүртэлх шөнө юм. Гэвч үлдсэн хугацаанд систем хэвийн ажиллаж, эвдэрсэн шинж тэмдэг илрээгүй.
Гэсэн хэдий ч асуудлыг шийдэх ёстой байв. Бид болзошгүй саад бэрхшээлийг тодорхойлж, тэдгээрийг арилгах ажлыг эхлүүлсэн. Мэдээжийн хэрэг, юуны түрүүнд бид гадаад холболтыг өргөжүүлж, дотоод холболтыг бүрэн засварлаж, боломжит бүх саад бэрхшээлийг олж мэдсэн. Гэвч энэ бүхэн тодорхой үр дүнд хүрээгүй, асуудал арилаагүй.
Өөр нэг боломжит гацаа бол зургийн кэшийн гүйцэтгэл байв. Асуудал нь тэдэн дээр байгаа байх гэж бид шийдсэн. За, бид гүйцэтгэлийг өргөжүүлсэн - үндсэндээ зургийн кэш дээрх сүлжээний портууд. Гэхдээ дахин тодорхой ахиц гарсангүй. Эцэст нь бид LTM-ийн гүйцэтгэлд ихээхэн анхаарал хандуулсан бөгөөд энд бид график дээр гунигтай дүр зургийг харав: бүх CPU-ийн ачаалал жигдэрч эхэлдэг боловч дараа нь тавиур дээр огцом байрладаг. Үүний зэрэгцээ LTM нь эрүүл мэндийн үзлэг, холболтод зохих хариу өгөхөө больж, санамсаргүй байдлаар унтрааж эхэлдэг бөгөөд энэ нь гүйцэтгэлийн ноцтой доройтолд хүргэдэг.
Өөрөөр хэлбэл, бид асуудлын эх үүсвэрийг тодорхойлсон, гацааг тодорхойлсон. Юу хийхээ шийдэх л үлдлээ.
Бидний хийж чадах хамгийн эхний зүйл бол LTM-г ямар нэгэн байдлаар шинэчлэх явдал юм. Гэхдээ энд зарим нэг нюансууд байдаг, учир нь энэ төмөр нь маш өвөрмөц тул та хамгийн ойрын супермаркет руу очоод худалдаж авахгүй. Энэ нь тусдаа гэрээ, тусдаа лицензийн гэрээ, маш их цаг хугацаа шаардана. Хоёрдахь сонголт бол өөрөө бодож эхлэх, нээлттэй эхийн програмыг ашиглан өөрийн бүрэлдэхүүн хэсгүүдийн талаар өөрийн шийдлийг гаргах явдал юм. Хэрэглэгчид зураг аваагүй тул бид яг юу сонгох, энэ асуудлыг шийдэхэд хэр их цаг зарцуулахаа шийдэх л үлдлээ. Тиймээс, энэ бүхнийг маш хурдан хийх шаардлагатай байна гэж хэн нэгэн хэлж магадгүй - өчигдөр.
Даалгавар нь "ямар нэг зүйлийг аль болох хурдан хийж, өөрт байгаа техник хангамжийг ашиглана" шиг сонсогдож байсан тул бидний хамгийн түрүүнд бодсон зүйл бол хамгийн хүчирхэг биш машинуудыг урдаас нь салгаж, Nginx-ийг тэнд байрлуулах явдал байв. ажиллаж, төмрийн хэлтэрхий хийдэг байсан бүх логикийг хэрэгжүүлэхийг хичээ. Энэ нь үнэн хэрэгтээ бид техник хангамжаа орхиж, тохируулах шаардлагатай өөр 4 сервер суулгаж, 10 жилийн өмнөхтэй ижил төстэй гадаад домэйн хийсэн ... Хэрэв эдгээр машинууд унасан бол бид бага зэрэг боломжоо алдсан. , гэхдээ бага ч гэсэн манай хэрэглэгчдийн асуудлыг орон нутгийн хэмжээнд шийдсэн.
Үүний дагуу логик нь ижил хэвээр байна: бид Nginx суулгаж, SSL-г буулгах боломжтой, бид ямар нэгэн байдлаар чиглүүлэлтийн логикийг програмчилж, тохиргоонуудын эрүүл мэндийг шалгаж, өмнө нь байсан логикийг хуулбарлах боломжтой.
Бид тохиргоо бичихээр суудаг. Эхэндээ бүх зүйл маш энгийн мэт санагдаж байсан ч харамсалтай нь даалгавар бүрийн гарын авлагыг олоход маш хэцүү байдаг. Тиймээс бид танд зүгээр л "Nginx-г зурагт хэрхэн тохируулах талаар" Google-ээс хайхыг зөвлөдөггүй: албан ёсны баримт бичигт хандах нь дээр бөгөөд энэ нь ямар тохиргоонд хүрэхийг харуулах болно. Гэхдээ тодорхой параметрийг өөрөө сонгох нь дээр. За, тэгвэл бүх зүйл энгийн: бид байгаа серверүүдийг тайлбарлаж, гэрчилгээг тайлбарладаг ... Гэхдээ хамгийн сонирхолтой зүйл бол үнэн хэрэгтээ чиглүүлэлтийн логик өөрөө юм.
Эхлээд бид зүгээр л байршлаа тодорхойлж, түүн доторх зургийн кэшийн дугаараа тааруулж, гараараа эсвэл генераторын тусламжтайгаар хэдэн дээд урсгал хэрэгтэйг тайлбарлаж, дээд урсгал бүрт бид ямар сервер рүү траффик орох ёстойг зааж өгдөг юм шиг санагдаж байсан. нөөц сервер - үндсэн сервер байхгүй тохиолдолд:
Гэхдээ, хэрэв бүх зүйл ийм энгийн байсан бол бид гэртээ харьж, юу ч хэлэхгүй байх байсан. Харамсалтай нь, Nginx-ийн анхдагч тохиргоог ерөнхийдөө олон жилийн хөгжүүлэлтийн явцад хийсэн бөгөөд энэ тохиолдолд тийм ч тохиромжтой биш юм ... тохиргоо нь дараах байдалтай байна: зарим нэг дээд сервер хүсэлтийн алдаа эсвэл хугацаа хэтэрсэн тохиолдолд Nginx үргэлж ажилладаг. урсгалыг дараагийнх руу шилжүүлдэг. Үүний зэрэгцээ, эхний бүтэлгүйтлийн дараа сервер 10 секундын дотор, алдаа болон завсарлагааны улмаас унтрах болно - үүнийг ямар ч байдлаар тохируулах боломжгүй. Өөрөөр хэлбэл, хэрэв бид дээд урсгалын удирдамжийн хугацаа дуусах сонголтыг арилгах эсвэл дахин тохируулах тохиолдолд Nginx энэ хүсэлтийг боловсруулахгүй бөгөөд тийм ч сайн биш алдаатай хариу өгөхгүй ч сервер унтарна.
Үүнээс зайлсхийхийн тулд бид хоёр зүйлийг хийсэн:
a) тэд Nginx-д үүнийг гараар хийхийг хориглосон бөгөөд харамсалтай нь үүнийг хийх цорын ганц арга бол хамгийн их амжилтгүй байдлын тохиргоог тохируулах явдал юм.
б) бусад төслүүдэд бид эрүүл мэндийн суурь үзлэг хийх боломжийг олгодог модулийг ашигладаг гэдгийг бид санаж байсан - үүний дагуу бид эрүүл мэндийн үзлэгийг нэлээд олон удаа хийдэг бөгөөд ингэснээр ослын үед хамгийн бага зогсолт хийх болно.
Харамсалтай нь энэ нь бүгд биш, учир нь энэ схемийн үйл ажиллагааны эхний хоёр долоо хоногт TCP-ийн эрүүл мэндийг шалгах нь найдваргүй зүйл гэдгийг харуулсан: Nginx биш, эсвэл D төлөвт байгаа Nginx-ийг дээд сервер дээр ажиллуулж болно. Энэ тохиолдолд цөм холболтыг хүлээн авах болно, эрүүл мэндийн шалгалтыг давах боловч энэ нь ажиллахгүй болно. Тиймээс бид нэн даруй http-ийн эрүүл мэндийн үзлэгээр сольж, тодорхой нэгийг хийсэн бөгөөд хэрэв энэ нь аль хэдийн 200 өгсөн бол бүх зүйл энэ скрипт дээр ажилладаг. Та нэмэлт логик хийж болно - жишээлбэл, серверүүдийг кэш хийх тохиолдолд файлын систем зөв холбогдсон эсэхийг шалгана уу.
Одоогийн байдлаар хэлхээ нь төмрийн хийсэн зүйлийг бүрэн давтаж байгааг эс тооцвол энэ нь бидэнд тохирсон байх болно. Гэхдээ бид илүү сайн хийхийг хүссэн. Өмнө нь бид нэг нөөц сервертэй байсан бөгөөд энэ нь тийм ч сайн биш байж магадгүй, учир нь хэрэв танд зуун сервер байгаа бол хэд хэдэн серверүүд нэг дор унах үед нэг нөөц сервер ачааллыг даван туулах боломжгүй юм. Тиймээс бид захиалгыг бүх серверүүдийн дунд хуваарилахаар шийдсэн: бид зүгээр л өөр нэг дээд урсгалыг хийж, тэнд байгаа бүх серверүүдийг ямар ачаалалтай ажиллах боломжтойг нь харгалзан тодорхой параметрүүдийг бүртгэж, өмнө нь хийж байсан эрүүл мэндийн шалгалтыг нэмсэн:
Та нэг дээд урсгал дотор өөр дээд урсгал руу явах боломжгүй тул хэрэв бидний зөв, шаардлагатай зургийн кэшийг бичсэн гол дээд урсгал боломжгүй бол бид зүгээр л error_page руу буцах хэрэгтэй. Бид нөөцийн дээд урсгал руу явсан:
Дөрвөн сервер нэмж оруулснаар бид үүнийг олж авлаа: бид ачааллын нэг хэсгийг сольж - LTM-ээс эдгээр серверүүд рүү устгаж, стандарт техник хангамж, програм хангамж ашиглан ижил логикийг хэрэгжүүлсэн, эдгээр серверүүдийг масштаблах боломжтой гэсэн урамшууллыг тэр даруй хүлээн авлаа. зүгээр л хэрэгтэй хэмжээгээрээ оруулаарай. Цорын ганц сөрөг зүйл бол бид гадны хэрэглэгчдэд зориулсан өндөр хүртээмжийг алдсан явдал юм. Гэхдээ тэр үед би үүнийг золиослох хэрэгтэй болсон, учир нь асуудлыг яаралтай шийдэх шаардлагатай байсан. Тиймээс бид ачааллын нэг хэсгийг хассан, тэр үед энэ нь 40 орчим хувь байсан, LTM сайжирч, асуудал эхэлснээс хойш хоёр долоо хоногийн дараа бид секундэд 45 мянга биш, харин 55 мянган хүсэлт өгч эхэлсэн. Үнэн хэрэгтээ бид 20% -иар өссөн - энэ нь бидний хэрэглэгчдэд өгөөгүй урсгал юм. Үүний дараа тэд гадны өндөр хүртээмжийг хангахын тулд үлдсэн асуудлыг хэрхэн шийдвэрлэх талаар бодож эхлэв.
Бид үүнд ямар шийдлийг ашиглах талаар ярилцах завсарлага авсан. Өөрөө бичсэн скриптүүд, динамик чиглүүлэлтийн протоколуудын тусламжтайгаар DNS-ийн найдвартай байдлыг хангах саналууд байсан ... олон сонголт байсан боловч зургийг үнэхээр найдвартай буцааж өгөхийн тулд та өөр давхарга нэвтрүүлэх хэрэгтэй болох нь тодорхой болсон. энэ нь үүнийг хянах болно. Бид эдгээр машинуудыг зургийн найруулагч гэж нэрлэдэг. Бидний найдаж байсан програм хангамж бол Keepalived юм:
Эхлэхийн тулд Keepalived юунаас бүрддэг. Эхнийх нь сүлжээний тоног төхөөрөмж дээр байрладаг, үйлчлүүлэгчдийн холбогдох гадаад IP хаягийн алдааг тэсвэрлэх чадварыг хангадаг сүлжээний хэрэглэгчдийн өргөн мэддэг VRRP протокол юм. Хоёрдахь хэсэг нь IPVS буюу IP виртуал сервер нь фото чиглүүлэгчийн хооронд тэнцвэржүүлж, энэ түвшинд алдааг тэсвэрлэх чадвартай. Гурав дахь нь эрүүл мэндийн үзлэг юм.
Эхний хэсгээс эхэлье: VRRP - энэ нь ямар харагддаг вэ? Үйлчлүүлэгчид холбогддог dns badoocdn.com-д оруулгатай тодорхой виртуал IP байдаг. Хэзээ нэгэн цагт бид нэг сервер дээр IP хаягтай байдаг. Keepalived пакетууд нь VRRP протоколыг ашиглан серверүүдийн хооронд ажилладаг бөгөөд хэрэв мастер радараас алга бол - сервер дахин ачаалагдсан эсвэл өөр зүйл байвал нөөц сервер нь энэ IP хаягийг автоматаар нэмэгдүүлдэг - гарын авлагын үйлдэл хийх шаардлагагүй. Мастер ба нөөцлөлт нь ялгаатай, голчлон тэргүүлэх ач холбогдол нь: өндөр байх тусам машин мастер болох магадлал өндөр болно. Маш том давуу тал бол та сервер дээрээ IP хаягийг тохируулах шаардлагагүй, тэдгээрийг тохиргоонд тайлбарлахад хангалттай бөгөөд хэрэв IP хаягуудад тусгай чиглүүлэлтийн дүрэм шаардлагатай бол үүнийг тохиргоонд шууд тайлбарласан болно. VRRP багцад тайлбарласантай ижил синтакс. Та ямар ч танихгүй зүйлтэй уулзахгүй.
Практик дээр ямар харагддаг вэ? Хэрэв серверүүдийн аль нэг нь унтарвал яах вэ? Мастер алга болмогц манай нөөц урамшуулал хүлээн авахаа больж, автоматаар мастер болно. Хэсэг хугацааны дараа бид мастерийг засварлаж, дахин ачаалж, Keepalived-ийг өсгөсөн - нөөцлөлтөөс илүү ач холбогдолтой зар сурталчилгаа ирэх бөгөөд нөөцлөлт нь автоматаар буцаж, IP хаягийг өөрөө устгаж, гарын авлага хийх шаардлагагүй болно.
Тиймээс бид гадаад IP хаягийн алдааг тэсвэрлэх чадварыг баталгаажуулсан. Дараагийн хэсэг нь гадаад IP хаягаас түүнийг аль хэдийн дуусгасан гэрэл зургийн чиглүүлэгч рүү чиглэсэн урсгалыг ямар нэгэн байдлаар тэнцвэржүүлэх явдал юм. Тэнцвэржүүлэх протоколуудын тусламжтайгаар бүх зүйл хангалттай тодорхой болно. Энэ бол энгийн дугуй, эсвэл арай илүү төвөгтэй зүйл, wrr, жагсаалтын холболт гэх мэт. Үүнийг үндсэндээ баримт бичигт тайлбарласан байгаа бөгөөд үүнд онцгой зүйл байхгүй. Гэхдээ хүргэх арга ... Энд бид илүү дэлгэрэнгүй ярих болно - яагаад бид тэдгээрийн аль нэгийг нь сонгосон юм. Эдгээр нь NAT, Direct Routing, TUN юм. Баримт нь бид сайтуудаас 100 гигабит траффик буцаахыг тэр даруй тавьсан юм. Хэрэв та үүнийг ойлговол танд 10 гигабит карт хэрэгтэй болно, тийм үү? Нэг серверт 10 гигабит картууд - энэ нь ядаж бидний "стандарт төхөөрөмж" гэсэн ойлголтоос хэтэрсэн юм. Тэгээд бид зүгээр л замын хөдөлгөөнд оролцдоггүй, гэрэл зураг өгдөг гэдгийг санав.
Онцлог нь юу вэ? - Ирж буй болон гарах урсгалын хоорондох асар их ялгаа. Ирж буй урсгал маш бага, гарах урсгал маш их байна:
Хэрэв та эдгээр графикуудыг харвал одоогийн байдлаар захирал руу секундэд 200 Мб илгээж байгааг харж болно, энэ бол хамгийн энгийн өдөр юм. Бид секундэд 4,500 МБ буцааж өгдөг, харьцаа нь ойролцоогоор 1/22 байна. Ажиллаж буй 22 сервер рүү гадагш урсгалыг бүрэн хангахын тулд энэ холболтыг хүлээн зөвшөөрөх нэг л хангалттай гэдэг нь тодорхой болсон. Энд шууд чиглүүлэлтийн алгоритм, чиглүүлэлтийн алгоритм нь бидэнд туслах болно.
Энэ юу шиг харагдаж байна? Манай зургийн найруулагч өөрийн хүснэгтийн дагуу зураг чиглүүлэгч рүү холболтыг шилжүүлдэг. Гэхдээ гэрэл зургийн чиглүүлэгчид урвуу урсгалыг шууд интернет рүү илгээж, үйлчлүүлэгч рүү илгээдэг, энэ нь зургийн найруулагчаар дамждаггүй тул хамгийн бага тооны машинтай бол бид бүх урсгалыг бүрэн алдааг тэсвэрлэж, шахах боломжийг олгодог. Тохиргоонд энэ нь иймэрхүү харагдаж байна: бид алгоритмыг зааж өгдөг, бидний тохиолдолд энэ нь энгийн rr юм, бид шууд чиглүүлэлтийн аргыг өгдөг, дараа нь бид бүх бодит серверүүдийг жагсааж эхэлдэг, тэдгээрийн хэд нь бидэнд байна. Энэ нь замын хөдөлгөөнийг тодорхойлох болно. Хэрэв бидэнд нэг эсвэл хоёр өөр, хэд хэдэн сервер гарч ирвэл ийм хэрэгцээ гарч ирдэг - бид энэ хэсгийг тохиргоонд нэмээд нэг их санаа зовох хэрэггүй. Бодит серверийн талаас, гэрэл зураг чиглүүлэгчийн талаас энэ арга нь хамгийн бага тохиргоог шаарддаг, үүнийг баримт бичигт бүрэн дүрсэлсэн бөгөөд энд ямар ч бэрхшээл байхгүй.
Хамгийн таатай зүйл бол ийм шийдэл нь дотоод сүлжээг эрс өөрчлөх гэсэн үг биш юм, энэ нь бидний хувьд чухал байсан, бид үүнийг хамгийн бага зардлаар шийдэх ёстой байсан. Хэрэв та харвал дараа нь бид ямар харагдахыг харах болно. Энд бид тодорхой виртуал сервертэй, 443-р порт дээр, сонсож, холболтыг хүлээн авдаг, бүх ажиллаж байгаа серверүүд жагсаагдсан бөгөөд холболт нь нэмэх эсвэл хасах нь ижил байх нь тодорхой байна. Хэрэв бид ижил виртуал сервер дээрх статистикийг харвал бидэнд ирж буй пакетууд, ирж буй холболтууд байдаг, гэхдээ гарч байгаа нь огт байхгүй. Гарч буй холболтууд нь үйлчлүүлэгч рүү шууд очдог. За, бид тэнцвэрээ алдаж чадсан. Одоо манай зургийн чиглүүлэгчийн аль нэг нь бүтэлгүйтвэл яах вэ? Эцсийн эцэст төмөр бол төмөр юм. Энэ нь цөмийн үймээн самуунд орж магадгүй, энэ нь эвдэрч, тэжээлийн хангамж шатаж магадгүй юм. Юу ч. Үүний тулд эрүүл мэндийн үзлэг хийдэг. Тэдгээр нь бидэнтэй порт хэрхэн нээлттэй байгааг шалгахтай адил энгийн, эсвэл бизнесийн логикийг шалгах зарим өөрөө бичсэн скриптүүд хүртэл илүү төвөгтэй байж болно.
Бид дунд нь хаа нэгтээ зогссон: бидэнд тодорхой байршилд зориулсан https хүсэлт байна, скрипт нь 200 дахь хариултаар хариулбал дуудагддаг, энэ серверт бүх зүйл сайн байгаа, энэ нь амьд бөгөөд амархан асаалттай гэдэгт бид итгэдэг. .
Энэ нь дахин практик дээр хэрхэн харагдаж байна. Серверийг унтраасан, засвар үйлчилгээ хийхийг зөвшөөрдөг - жишээ нь BIOS-ийг анивчуулж байна. Бүртгэлд бид нэн даруй завсарлагатай тул эхний мөрийг харж, гурван оролдлогын дараа үүнийг "амжилтгүй" гэж тэмдэглэж, жагсаалтаас хасна.
VS-г зүгээр л тэг болгож тохируулсан тохиолдолд хоёрдахь үйлдэл хийх боломжтой боловч зургийг буцаах тохиолдолд энэ нь сайн ажиллахгүй болно. Сервер дээшилж, Nginx тэнд ажиллаж эхэлнэ, эрүүл мэндийн шалгалтууд холболт явагдаж байгааг, бүх зүйл хэвийн байгааг ойлгож, сервер бидний жагсаалтад гарч ирэх бөгөөд ачааллыг шууд автоматаар өгч эхэлнэ. Албаны администратороос ямар ч гарын авлага хийх шаардлагагүй. Шөнийн цагаар сервер дахин ачаалагдсан - хяналтын хэлтэс шөнийн цагаар энэ талаар бидэн рүү залгадаггүй. Тэд юу болсныг танд мэдэгдэв, бүх зүйл сайхан байна.
Тиймээс цөөн тооны серверийн тусламжтайгаар бид гадны алдааг тэсвэрлэх асуудлыг шийдсэн.
Энэ бүхэнд мэдээж хяналт тавих шаардлагатай гэж хэлэх л үлдлээ. Keepalivede нь маш эрт дээр үеэс бичигдсэн программ хангамжийн хувьд DBus, SMTP, SNMP, стандарт Zabbix ашиглан шалгах олон арга замтай гэдгийг тэмдэглэх нь зүйтэй. Нэмж дурдахад тэр өөрөө бараг найтаах бүрт хэрхэн захидал бичихээ мэддэг бөгөөд үнэнийг хэлэхэд бид хэзээ нэгэн цагт үүнийг унтраахыг ч бодсон, учир нь тэр ямар ч хөдөлгөөн солих, оруулах, IP-шник болон IP-шник бүрт олон захидал бичдэг. гэх мэт. Мэдээжийн хэрэг, хэрэв олон сервер байгаа бол та эдгээр үсгүүдээр өөрийгөө дүүргэж болно. Стандарт аргуудыг ашиглан бид гэрэл зургийн чиглүүлэгчид nginx-ийг хянадаг бөгөөд техник хангамжийн хяналт арилаагүй байна. Мэдээжийн хэрэг, бид нэмэлт хоёр зүйлийг зөвлөж байна: нэгдүгээрт, гаднах эрүүл мэндийн үзлэг, хүртээмж, учир нь бүх зүйл ажиллаж байсан ч гадны үйлчилгээ үзүүлэгчтэй холбоотой асуудал эсвэл илүү төвөгтэй зүйлээс болж хэрэглэгчид зураг авахгүй байх магадлалтай. Энэ нь үргэлж өөр сүлжээний хаа нэгтээ, Amazon эсвэл өөр хаа нэгтээ таны серверүүдийг гаднаас нь ping хийх боломжтой тусдаа машиныг хадгалах нь зүйтэй бөгөөд гажиг илрүүлэх аргыг ашиглах нь зүйтэй. хүсэлтүүд огцом буурсан, эсвэл эсрэгээрээ өссөн эсэхийг хянахын тулд хяналт тавих. Энэ нь бас ашигтай.
Дүгнэж хэлэхэд: бид үнэн хэрэгтээ хэзээ нэгэн цагт бидэнд тохирохоо больсон төмрийн шийдлийг бүх зүйлийг адилхан хийдэг нэлээд энгийн системээр сольсон, өөрөөр хэлбэл HTTPS траффикийг зогсоож, шаардлагатай эрүүл мэндийн цаашдын ухаалаг чиглүүлэлтээр хангасан. -шалгадаг. Бид энэ системийн тогтвортой байдлыг нэмэгдүүлсэн, өөрөөр хэлбэл, давхарга бүрийг ашиглах боломжтой хэвээр байгаа бөгөөд үүнээс гадна давхарга бүр дээр бүгдийг нь масштаблах нь маш хялбар гэсэн урамшуулал авсан, учир нь энэ нь стандарт програм хангамжтай стандарт техник хангамж юм. , Ингэснээр бид боломжит асуудлуудыг оношлоход хялбар болгосон.
Бид юугаар төгссөн бэ? 2018 оны 40-р сарын баяраар бидэнд асуудал гарсан. Эхний зургаан сарын хугацаанд бид энэ схемийг ашиглалтад оруулж, бүх урсгалд өргөтгөж, LTM-ээс бүх траффикийг арилгахын тулд зөвхөн нэг дата төвийн урсгалыг 60 гигабитээс 2018 гигабит хүртэл өсгөсөн. XNUMX оны туршид секундэд бараг гурав дахин их зураг өгөх боломжтой болсон.
Эх сурвалж: www.habr.com