Zamonaviy internetni media-kontentsiz deyarli tasavvur qilib bo'lmaydi: deyarli har bir buvining smartfoni bor, hamma ijtimoiy tarmoqlarda va texnik xizmat ko'rsatishda uzilishlar kompaniyalar uchun qimmatga tushadi. Bu yerda kompaniya hikoyasining transkripti u apparat yechimi yordamida fotosuratlarni yetkazib berishni qanday tashkil qilgani, jarayonda qanday ishlash muammolariga duch kelgani, ularga nima sabab bo'lganligi va bu muammolar Nginx asosidagi dasturiy yechim yordamida qanday hal qilingani, shu bilan birga barcha darajalarda nosozliklarga bardoshliligi ta'minlangani haqida (). Olegning hikoyasi mualliflariga minnatdorchilik bildiramiz Konferensiyada oβz tajribalari bilan oβrtoqlashgan Efimova va Aleksandra Dymova .
β Keling, fotosuratlarni qanday saqlashimiz va keshlashimiz haqida qisqacha ma'lumot bilan boshlaylik. Bizda ularni saqlaydigan qatlam va fotosuratlarni keshlaydigan qatlam mavjud. Shu bilan birga, agar biz yuqori ayyorlik tezligiga erishmoqchi bo'lsak va saqlash yukini kamaytirmoqchi bo'lsak, biz uchun alohida foydalanuvchining har bir fotosurati bitta keshlash serverida bo'lishi muhimdir. Aks holda, serverlarimiz qancha ko'p bo'lsa, shuncha ko'p disklarni o'rnatishimiz kerak edi. Bizning hiyla-nayrang tezligimiz 99% atrofida, ya'ni biz xotiramizdagi yukni 100 baravar kamaytirmoqdamiz va buning uchun 10 yil oldin, bularning barchasi qurilayotganda, bizda 50 ta server bor edi. Shunga ko'ra, ushbu fotosuratlarga xizmat ko'rsatish uchun bizga ushbu serverlar xizmat qiladigan 50 ta tashqi domen kerak edi.
Tabiiyki, darhol savol tug'iladi: agar serverlarimizdan biri ishlamay qolsa, biz trafikning qaysi qismini yo'qotamiz? Biz bozorda nima borligini ko'rib chiqdik va barcha muammolarimizni hal qilish uchun uskunani sotib olishga qaror qildik. Tanlov F5-tarmoq kompaniyasining (aytmoqchi, yaqinda NGINX, Incni sotib olgan) qaroriga to'g'ri keldi: BIG-IP Local Traffic Manager.
Ushbu uskuna (LTM) nima qiladi: bu temir yo'riqnoma bo'lib, u o'zining tashqi portlarini temir ortiqcha qiladi va tarmoq topologiyasi, ba'zi sozlamalar asosida trafikni yo'naltirish imkonini beradi va sog'lig'ini tekshiradi. Biz uchun ushbu uskunani dasturlash mumkinligi muhim edi. Shunga ko'ra, biz ma'lum bir foydalanuvchining fotosuratlari ma'lum bir keshdan qanday taqdim etilganligi mantiqini tasvirlashimiz mumkin. Bu nimaga o'xshaydi? Bitta domenda, bitta IPda Internetni ko'rib chiqadigan, ssl-ni o'chirib tashlaydigan, http so'rovlarini tahlil qiladigan, IRule-dan kesh raqamini, qayerga borishni tanlaydigan va u erga trafik o'tishiga imkon beradigan apparat mavjud. Shu bilan birga, u sog'lig'ini tekshiradi va agar biron bir mashina mavjud bo'lmasa, biz trafikni bitta zaxira serverga o'tkazish uchun qildik. Konfiguratsiya nuqtai nazaridan, albatta, ba'zi nuanslar mavjud, lekin umuman olganda, hamma narsa juda oddiy: biz kartani, tarmoqdagi IP-ga ma'lum raqamning yozishmalarini ro'yxatdan o'tkazamiz, biz 80 portlarni tinglaymiz, deymiz. va 443-da, agar server mavjud bo'lmasa, siz trafikni zaxiraga, bu holda 35-ga yuborishingiz kerakligini aytamiz va biz ushbu arxitekturani qanday qismlarga ajratish kerakligi haqida bir qator mantiqni tasvirlaymiz. Yagona muammo shundaki, apparat dasturlashtirilgan til Tcl edi. Agar kimdir buni eslab qolsa... bu til dasturlash uchun qulay tildan ko'ra faqat yozish uchun mo'ljallangan tildir:
Biz nima oldik? Biz infratuzilmamizning yuqori darajada mavjudligini ta'minlaydigan, barcha trafikimizni yo'naltiradigan, sog'liq uchun foyda keltiradigan va shunchaki ishlaydigan uskunani oldik. Bundan tashqari, u juda uzoq vaqt ishlaydi: so'nggi 10 yil ichida bu haqda hech qanday shikoyatlar bo'lmagan. 2018 yil boshiga kelib biz sekundiga 80 mingga yaqin fotosuratlarni yuborayotgan edik. Bu bizning ma'lumotlar markazlarimizdan taxminan 80 gigabit trafik.
Biroqβ¦
2018 yil boshida biz jadvallarda xunuk rasmni ko'rdik: fotosuratlarni yuborish vaqti aniq ko'paygan. Va bu bizga mos kelmay qoldi. Muammo shundaki, bu xatti-harakatlar faqat tirbandlikning eng yuqori cho'qqisida ko'rinardi - bizning kompaniyamiz uchun bu yakshanbadan dushanbaga o'tar kechasi. Ammo qolgan vaqtlarda tizim odatdagidek harakat qildi, hech qanday nosozlik belgilari yo'q.
Shunga qaramay, muammoni hal qilish kerak edi. Biz yuzaga kelishi mumkin bo'lgan to'siqlarni aniqladik va ularni bartaraf etishga kirishdik. Albatta, birinchi navbatda, biz tashqi ulanishlarni kengaytirdik, ichki ulanishlarning to'liq auditini o'tkazdik va barcha mumkin bo'lgan to'siqlarni topdik. Ammo bularning barchasi aniq natija bermadi, muammo yo'qolmadi.
Yana bir mumkin bo'lgan muammo bu fotosurat keshlarining ishlashi edi. Va biz, ehtimol, muammo ularda ekanligiga qaror qildik. Xo'sh, biz ishlashni kengaytirdik - asosan foto keshlardagi tarmoq portlari. Ammo yana hech qanday yaxshilanish kuzatilmadi. Oxir-oqibat, biz LTM ning o'zi ishlashiga katta e'tibor qaratdik va bu erda biz grafiklarda qayg'uli rasmni ko'rdik: barcha protsessorlardagi yuk muammosiz keta boshlaydi, lekin keyin birdan platoga keladi. Shu bilan birga, LTM sog'liqni saqlash tekshiruvlari va ulanishlarga adekvat javob berishni to'xtatadi va ularni tasodifiy o'chirib qo'yishni boshlaydi, bu esa ishlashning jiddiy pasayishiga olib keladi.
Ya'ni, muammoning manbasini aniqladik, darbog'ni aniqladik. Nima qilishimizni hal qilish qoladi.
Biz qila oladigan birinchi, eng aniq narsa bu LTMni qandaydir tarzda modernizatsiya qilishdir. Ammo bu erda ba'zi nuances bor, chunki bu uskuna juda noyob, siz eng yaqin supermarketga borib, uni sotib olmaysiz. Bu alohida shartnoma, alohida litsenziya shartnomasi va bu juda ko'p vaqtni oladi. Ikkinchi variant - o'zingiz uchun o'ylashni boshlash, o'z komponentlaringizdan foydalangan holda o'z yechimingizni topish, yaxshisi ochiq kirish dasturidan foydalanish. Buning uchun aniq nimani tanlashimiz va bu muammoni hal qilish uchun qancha vaqt sarflashimizni hal qilish qoladi, chunki foydalanuvchilar etarli fotosuratlarni olmagan. Shuning uchun, biz bularning barchasini juda va juda tez qilishimiz kerak, deyish mumkin kecha.
Vazifa "biror narsani iloji boricha tezroq bajaring va bizda mavjud bo'lgan uskunadan foydalaning" kabi eshitilganligi sababli, biz o'ylagan birinchi narsa, unchalik kuchli bo'lmagan ba'zi mashinalarni old tomondan olib tashlash, Nginx-ni u erga qo'yish edi, biz qanday qilishni bilamiz. ishlang va apparat ishlatgan mantiqni amalga oshirishga harakat qiling. Ya'ni, aslida, biz o'z uskunamizni qoldirdik, sozlashimiz kerak bo'lgan yana 4 ta serverni o'rnatdik, ular uchun tashqi domenlarni yaratdik, xuddi 10 yil oldin bo'lgani kabi... Agar bu mashinalar tushib qolsa, biz biroz mavjudlikni yo'qotdik, lekin hali kamroq, ular bizning foydalanuvchilarning muammosini mahalliy darajada hal qilishdi.
Shunga ko'ra, mantiq bir xil bo'lib qoladi: biz Nginx-ni o'rnatamiz, u SSL-yuklashni amalga oshirishi mumkin, biz qandaydir tarzda marshrutlash mantig'ini dasturlashimiz, konfiguratsiyalardagi sog'liqni tekshirish va oddiygina bizda mavjud bo'lgan mantiqni takrorlashimiz mumkin.
Keling, konfiguratsiyalarni yozish uchun o'tiraylik. Avvaliga hamma narsa juda oddiy bo'lib tuyuldi, ammo, afsuski, har bir vazifa uchun qo'llanmalarni topish juda qiyin. Shuning uchun, biz "fotosuratlar uchun Nginx-ni qanday sozlashni" oddiygina googlingni tavsiya etmaymiz: qaysi sozlamalarga tegish kerakligini ko'rsatadigan rasmiy hujjatlarga murojaat qilish yaxshiroqdir. Lekin o'ziga xos parametrni o'zingiz tanlash yaxshidir. Xo'sh, unda hamma narsa oddiy: bizda mavjud bo'lgan serverlarni tasvirlaymiz, sertifikatlarni tasvirlaymiz ... Lekin eng qiziq narsa, aslida, marshrutlash mantiqining o'zi.
Avvaliga biz shunchaki joylashuvimizni tasvirlab, undagi foto keshimiz sonini moslashtirgandek, qo'llarimiz yoki generator yordamida bizga qancha yuqori oqim kerakligini tasvirlayotgandek tuyuldi, har bir yuqori oqimda biz trafik qaysi serverga kelishini ko'rsatamiz. o'ting va zaxira server - agar asosiy server mavjud bo'lmasa:
Ammo, ehtimol, agar hamma narsa juda oddiy bo'lsa, biz shunchaki uyga qaytamiz va hech narsa demaymiz. Afsuski, ko'p yillar davomida ishlab chiqilgan va umuman bu holatga to'liq mos kelmaydigan standart Nginx sozlamalari bilan... konfiguratsiya quyidagicha ko'rinadi: agar yuqori oqim serverida so'rov xatosi yoki kutish vaqti bo'lsa, Nginx har doim trafikni keyingisiga o'tkazadi. Bundan tashqari, birinchi nosozlikdan so'ng, 10 soniya ichida server ham noto'g'ri, ham vaqt tugashi bilan o'chadi - buni hech qanday tarzda sozlash ham mumkin emas. Ya'ni, agar biz yuqori oqim direktivasidagi vaqt tugashi opsiyasini olib tashlasak yoki qayta o'rnatsak, Nginx bu so'rovni qayta ishlamasa va unchalik yaxshi bo'lmagan xato bilan javob bersa ham, server o'chadi.
Buning oldini olish uchun biz ikkita narsani qildik:
a) ular Nginx-ga buni qo'lda qilishni taqiqladilar - va afsuski, buni qilishning yagona yo'li shunchaki maksimal muvaffaqiyatsizlik sozlamalarini o'rnatishdir.
b) biz boshqa loyihalarda sog'lig'imizni fon tekshiruvini o'tkazishga imkon beruvchi moduldan foydalanishimizni esladik - shunga ko'ra, baxtsiz hodisa yuz berganda ishlamay qolish vaqti minimal bo'lishi uchun biz tez-tez sog'liq tekshiruvlarini o'tkazdik.
Afsuski, bu ham hammasi emas, chunki ushbu sxemaning dastlabki ikki haftasi TCP sog'lig'ini tekshirish ham ishonchsiz narsa ekanligini ko'rsatdi: yuqori oqim serverida u Nginx yoki D holatidagi Nginx bo'lmasligi mumkin. bu holda yadro ulanishni qabul qiladi, sog'liq tekshiruvi o'tadi, lekin ishlamaydi. Shuning uchun, biz buni darhol http sog'lig'ini tekshirish bilan almashtirdik, aniq birini yaratdik, agar u 200 ni qaytarsa, hamma narsa ushbu skriptda ishlaydi. Siz qo'shimcha mantiqni amalga oshirishingiz mumkin - masalan, serverlarni keshlashda, fayl tizimining to'g'ri o'rnatilganligini tekshiring:
Va bu bizga mos bo'lardi, faqat hozirgi vaqtda sxema apparatning qilganini to'liq takrorladi. Ammo biz yaxshiroq harakat qilishni xohladik. Ilgari bizda bitta zahira serveri bor edi va bu unchalik yaxshi emas, chunki agar sizda yuzta server bo'lsa, bir vaqtning o'zida bir nechtasi ishlamay qolsa, bitta zaxira server yukni bardosh bera olmaydi. Shuning uchun, biz bronni barcha serverlar bo'ylab taqsimlashga qaror qildik: biz shunchaki boshqa alohida yuqori oqimni yaratdik, u erdagi barcha serverlarni ular xizmat ko'rsatishi mumkin bo'lgan yukga mos ravishda ma'lum parametrlar bilan yozdik, avvalgi sog'liqni saqlash tekshiruvlarini qo'shdik:
Bir yuqori oqim ichida boshqa yuqori oqimga o'tishning iloji bo'lmagani uchun, agar biz to'g'ri, kerakli fotosurat keshini yozib olgan asosiy yuqori oqim mavjud bo'lmasa, biz shunchaki xato_sahifasini qayta tiklashga o'tganimizga ishonch hosil qilishimiz kerak edi. Yuqori oqimdagi zaxiraga o'tadigan joy:
Va to'g'ridan-to'g'ri to'rtta serverni qo'shish orqali biz bunga erishdik: biz yukning bir qismini almashtirdik - biz uni LTM-dan ushbu serverlarga olib tashladik, u erda standart apparat va dasturiy ta'minotdan foydalangan holda xuddi shu mantiqni amalga oshirdik va darhol ushbu serverlar oladigan bonusni oldik. miqyosda bo'lishi mumkin, chunki ular kerakli darajada etkazib berilishi mumkin. Yagona salbiy tomoni shundaki, biz tashqi foydalanuvchilar uchun yuqori imkoniyatlarni yo'qotdik. Ammo o'sha paytda biz buni qurbon qilishimiz kerak edi, chunki muammoni darhol hal qilish kerak edi. Shunday qilib, biz yukning bir qismini olib tashladik, o'sha paytda u taxminan 40% edi, LTM o'zini yaxshi his qildi va muammo boshlanganidan ikki hafta o'tgach, biz soniyasiga 45 ming emas, balki 55 ming so'rov yuborishni boshladik. Aslida, biz 20% ga o'sdik - bu foydalanuvchiga biz bermagan trafik aniq. Va shundan keyin ular qolgan muammoni qanday hal qilish haqida o'ylay boshladilar - yuqori tashqi foydalanish imkoniyatini ta'minlash.
Biz biroz pauza qildik, buning uchun qanday echimdan foydalanishimizni muhokama qildik. DNS-dan foydalangan holda ishonchlilikni ta'minlash bo'yicha takliflar bor edi, ba'zi bir uyda yozilgan skriptlar, dinamik marshrutlash protokollari ... variantlar ko'p edi, ammo fotosuratlarni haqiqatan ham ishonchli etkazib berish uchun buni nazorat qiladigan boshqa qatlamni joriy qilish kerakligi allaqachon ma'lum bo'ldi. . Biz bu mashinalarni fotorejissorlar deb atashdik. Biz tayangan dasturiy ta'minot Keepalived edi:
Boshlash uchun, Keepalived nimadan iborat? Birinchisi, VRRP protokoli bo'lib, tarmoq foydalanuvchilari uchun keng ma'lum bo'lib, u tarmoq uskunasida joylashgan bo'lib, mijozlar ulanadigan tashqi IP-manzilga nosozliklarga chidamliligini ta'minlaydi. Ikkinchi qism IPVS, IP virtual server bo'lib, u foto marshrutizatorlar o'rtasida muvozanatni saqlash va ushbu darajadagi xatolarga chidamliligini ta'minlash uchun. Va uchinchisi - sog'lig'ini tekshirish.
Birinchi qismdan boshlaylik: VRRP - bu nimaga o'xshaydi? Mijozlar ulanadigan dns badoocdn.com da yozuvga ega ma'lum bir virtual IP mavjud. Vaqt o'tishi bilan bizda bitta serverda IP manzil mavjud. Saqlangan paketlar serverlar o'rtasida VRRP protokoli yordamida ishlaydi va agar master radardan yo'qolsa - server qayta ishga tushirilgan yoki boshqa biror narsa bo'lsa, zaxira server avtomatik ravishda ushbu IP manzilni oladi - qo'lda harakatlar talab qilinmaydi. Magistr va zaxira o'rtasidagi farq asosan ustuvor hisoblanadi: u qanchalik baland bo'lsa, mashinaning usta bo'lish imkoniyati shunchalik yuqori bo'ladi. Juda katta afzallik shundaki, siz IP manzillarini serverning o'zida sozlashingiz shart emas, ularni konfiguratsiyada tasvirlash kifoya qiladi va agar IP manzillar uchun ba'zi maxsus marshrutlash qoidalari kerak bo'lsa, bu to'g'ridan-to'g'ri konfiguratsiyada tasvirlangan. VRRP paketida tasvirlangan bir xil sintaksis. Hech qanday notanish narsalarga duch kelmaysiz.
Bu amalda qanday ko'rinadi? Agar serverlardan biri ishlamay qolsa nima bo'ladi? Magistr yo'qolishi bilan bizning zaxiramiz reklamalarni olishni to'xtatadi va avtomatik ravishda master bo'ladi. Bir muncha vaqt o'tgach, biz masterni ta'mirladik, qayta ishga tushirdik, Keepalivedni ko'tardik - reklamalar zaxiradan ko'ra ko'proq ustuvorlik bilan keladi va zaxira avtomatik ravishda orqaga qaytadi, IP manzillarni o'chirib tashlaydi, qo'lda harakat qilish kerak emas.
Shunday qilib, biz tashqi IP-manzilning nosozliklarga chidamliligini ta'minladik. Keyingi qism, tashqi IP-manzildan uni allaqachon tugatayotgan fotosurat marshrutizatorlarigacha bo'lgan trafikni qandaydir tarzda muvozanatlashdir. Balanslash protokollari bilan hamma narsa aniq. Bu oddiy round-robin, yoki biroz murakkabroq narsalar, wrr, ro'yxat ulanishi va boshqalar. Bu asosan hujjatlarda tasvirlangan, hech qanday maxsus narsa yo'q. Lekin etkazib berish usuli ... Bu erda biz nima uchun ulardan birini tanlaganimizni batafsil ko'rib chiqamiz. Bular NAT, Direct Routing va TUN. Gap shundaki, biz darhol saytlardan 100 gigabit trafikni yetkazib berishni rejalashtirgan edik. Agar siz taxmin qilsangiz, sizga 10 gigabit karta kerak, to'g'rimi? Bitta serverdagi 10 gigabitli kartalar, hech bo'lmaganda, bizning "standart uskunalar" tushunchamiz doirasidan tashqarida. Va keyin biz shunchaki trafikni emas, balki fotosuratlarni ham berishimizni esladik.
Nimasi alohida? - Kiruvchi va chiquvchi trafik o'rtasidagi katta farq. Kiruvchi trafik juda kichik, chiquvchi trafik juda katta:
Agar siz ushbu grafiklarga qarasangiz, hozirgi vaqtda rejissyor soniyasiga taxminan 200 MB qabul qilayotganini ko'rishingiz mumkin, bu juda oddiy kun. Biz soniyasiga 4,500 MB qaytaramiz, bizning nisbatimiz taxminan 1/22. 22 ishchi serveriga chiquvchi trafikni to'liq ta'minlash uchun bizga faqat ushbu ulanishni qabul qiladigan bittasi kerakligi allaqachon aniq. Bu erda to'g'ridan-to'g'ri marshrutlash algoritmi yordamimizga keladi.
Bu nimaga o'xshaydi? Bizning foto direktorimiz, o'z jadvaliga ko'ra, ulanishlarni foto routerlarga uzatadi. Lekin foto marshrutizatorlar qaytariladigan trafikni to'g'ridan-to'g'ri Internetga jo'natadi, uni mijozga yuboradi, u foto direktori orqali qaytib ketmaydi, shuning uchun minimal miqdordagi mashinalar bilan biz to'liq nosozliklarga chidamliligini va barcha trafikning pompalanishini ta'minlaymiz. Konfiguratsiyalarda bu shunday ko'rinadi: biz algoritmni aniqlaymiz, bizning holatlarimizda bu oddiy rr, to'g'ridan-to'g'ri marshrutlash usulini taqdim etamiz va keyin bizda qanchasi bor haqiqiy serverlarni ro'yxatga olishni boshlaymiz. Bu trafikni aniqlaydi. Agar bizda yana bir yoki ikkita server yoki bir nechta serverlar bo'lsa, bunday ehtiyoj paydo bo'ladi - biz ushbu bo'limni konfiguratsiyaga qo'shamiz va ortiqcha tashvishlanmang. Haqiqiy serverlar tomonidan, foto router tomonidan bu usul eng minimal konfiguratsiyani talab qiladi, u hujjatlarda mukammal tasvirlangan va u erda hech qanday tuzoq yo'q.
Qizig'i shundaki, bunday yechim mahalliy tarmoqni tubdan qayta loyihalashni anglatmaydi; bu biz uchun muhim edi, biz buni minimal xarajatlar bilan hal qilishimiz kerak edi. Agar qarasangiz , keyin qanday ko'rinishini ko'ramiz. Bu erda bizda ma'lum bir virtual server bor, 443-portda ulanishni tinglaydi, qabul qiladi, barcha ishlaydigan serverlar ro'yxatga olinadi va ulanish bir xil ekanligini ko'rishingiz mumkin, berish yoki olish. Agar biz bir xil virtual serverdagi statistik ma'lumotlarni ko'rib chiqsak, bizda kiruvchi paketlar, kiruvchi ulanishlar mavjud, lekin mutlaqo chiquvchisi yo'q. Chiquvchi ulanishlar to'g'ridan-to'g'ri mijozga o'tadi. OK, biz uni muvozanatdan chiqara oldik. Endi bizning foto routerlarimizdan biri ishlamay qolsa nima bo'ladi? Axir temir temirdir. U yadro vahimasiga tushishi mumkin, u sinishi mumkin, quvvat manbai yonib ketishi mumkin. Har qanday narsa. Shuning uchun sog'lig'ini tekshirish kerak. Ular portning qanday ochiqligini tekshirish kabi oddiy bo'lishi mumkin yoki undan ham murakkabroq narsa, hatto biznes mantig'ini ham tekshiradigan uyda yozilgan skriptlargacha.
Biz o'rtada bir joyda to'xtadik: bizda ma'lum bir joyga https so'rovi bor, skript chaqiriladi, agar u 200-javob bilan javob bersa, biz ushbu serverda hamma narsa yaxshi, u tirik va uni yoqish mumkinligiga ishonamiz. osongina.
Bu yana amalda qanday ko'rinadi? Xizmat uchun serverni o'chirib qo'yamiz - masalan, BIOS-ni miltillash. Jurnallarda biz darhol vaqt tugashiga ega bo'lamiz, biz birinchi qatorni ko'ramiz, keyin uchta urinishdan so'ng u "muvaffaqiyatsiz" deb belgilanadi va u oddiygina ro'yxatdan o'chiriladi.
VS oddiygina nolga o'rnatilganda ikkinchi xatti-harakatlar varianti ham mumkin, lekin agar fotosurat qaytarilsa, bu yaxshi ishlamaydi. Server paydo bo'ladi, Nginx u erda boshlanadi, sog'liqni tekshirish darhol ulanish ishlayotganini, hamma narsa yaxshi ekanligini tushunadi va server bizning ro'yxatimizda paydo bo'ladi va yuk darhol unga qo'llanila boshlaydi. Navbatchi ma'murdan qo'lda harakatlar talab qilinmaydi. Kechasi server qayta ishga tushirildi - monitoring bo'limi tunda bu haqda bizga qo'ng'iroq qilmaydi. Ular sizga bu sodir bo'lganligi haqida xabar berishadi, hammasi yaxshi.
Shunday qilib, juda oddiy tarzda, oz sonli serverlar yordamida biz tashqi nosozliklarga chidamlilik muammosini hal qildik.
Faqat shuni aytish kerakki, bularning barchasi, albatta, kuzatilishi kerak. Alohida ta'kidlash joizki, Keepalivede, uzoq vaqt oldin yozilgan dasturiy ta'minot sifatida, uni DBus, SMTP, SNMP va standart Zabbix orqali tekshirish yordamida kuzatishning bir qancha usullariga ega. Bundan tashqari, uning o'zi deyarli har bir aksirish uchun xat yozishni biladi va rostini aytsam, biz uni o'chirib qo'yishni o'yladik, chunki u har qanday trafikni almashtirish, yoqish, har bir IP ulanishi uchun juda ko'p harflar yozadi, va hokazo . Albatta, agar serverlar ko'p bo'lsa, unda siz o'zingizni bu harflar bilan to'ldirishingiz mumkin. Biz standart usullardan foydalangan holda fotosurat marshrutizatorlarida nginx-ni kuzatamiz va apparat monitoringi yo'qolmadi. Biz, albatta, yana ikkita narsani maslahat beramiz: birinchidan, tashqi sog'liqni tekshirish va mavjudligi, chunki hamma narsa ishlayotgan bo'lsa ham, aslida foydalanuvchilar tashqi provayderlar bilan bog'liq muammolar yoki yanada murakkabroq narsa tufayli fotosuratlarni olmasligi mumkin. Har doim boshqa tarmoqda, Amazonda yoki boshqa joyda, serverlaringizga tashqaridan ping yuborishi mumkin bo'lgan alohida mashinani saqlashga arziydi, shuningdek, qiyin mashinani o'rganishni biladiganlar uchun anomaliyalarni aniqlashdan foydalanishga arziydi. oddiy monitoring, hech bo'lmaganda so'rovlar keskin kamayganligini yoki aksincha, ko'payganligini kuzatish uchun. Bundan tashqari, foydali bo'lishi mumkin.
Xulosa qilib olaylik: biz, aslida, bir muncha vaqt o'zimizga mos kelmay qolgan temir bilan qoplangan yechimni hamma narsani xuddi shunday bajaradigan, ya'ni HTTPS trafigini to'xtatish va undan keyingi aqlli marshrutlashni ta'minlaydigan juda oddiy tizim bilan almashtirdik. zarur sog'liq tekshiruvlari. Biz ushbu tizimning barqarorligini oshirdik, ya'ni bizda har bir qatlam uchun hali ham yuqori darajadagi mavjudlik mavjud, bundan tashqari, bizda bonus borki, har bir qatlamda hammasini masshtablash juda oson, chunki bu standart dasturiy ta'minotga ega standart uskuna, ya'ni , biz mumkin bo'lgan muammolarni tashxislashni soddalashtirdik.
Biz nima bilan yakunlandik? 2018 yil yanvar oyidagi ta'til paytida muammoga duch keldik. Birinchi olti oy ichida biz ushbu sxemani ishga tushirganimizda, biz LTM-dan barcha trafikni olib tashlash uchun uni barcha trafikka kengaytirdik, biz faqat bitta ma'lumot markazidagi trafikni 40 gigabitdan 60 gigabitgacha oshirdik va shu bilan birga butun 2018 yil sekundiga deyarli uch baravar ko'proq fotosuratlarni yuborishga muvaffaq bo'ldi.
Manba: www.habr.com