Заманбап интернетти медиа-контентсиз элестетүү мүмкүн эмес: дээрлик ар бир чоң эненин смартфону бар, бардыгы социалдык тармактарда жана техникалык тейлөөдөгү токтоп калуу компаниялар үчүн кымбатка турат. Бул жерде компаниянын окуясынын стенограммасы ал аппараттык чечимди колдонуу менен сүрөттөрдү жеткирүүнү кантип уюштургандыгы, процессте кандай аткаруу көйгөйлөрүнө дуушар болгондугу, аларга эмне себеп болгондугу жана бул көйгөйлөр 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нин иштөөсүнө өзгөчө көңүл бурдук жана бул жерде биз графиктерде кайгылуу сүрөттү көрдүк: бардык процессорлордогу жүк бир калыпта кете баштайт, бирок күтүлбөгөн жерден платого келет. Ошол эле учурда, LTM ден соолук текшерүүлөрүнө жана байланыштарга адекваттуу жооп бербейт жана аларды туш келди өчүрө баштайт, бул иштин олуттуу начарлашына алып келет.
Башкача айтканда, биз маселенин булагын аныктадык, бут тосууну аныктадык. Эмне кылаарыбызды чечиш керек.
Биринчи, эң айкын нерсе - бул LTMди кандайдыр бир жол менен модернизациялоо. Бирок бул жерде кээ бир нюанстар бар, анткени бул жабдык абдан уникалдуу, сиз жакынкы супермаркетке барып, аны сатып албайсыз. Бул өзүнчө келишим, өзүнчө лицензиялык келишим жана бул көп убакытты талап кылат. Экинчи вариант - өз алдынча ойлонуп баштоо, өзүңүздүн компоненттериңизди колдонуу менен өзүңүздүн чечимиңизди табуу, эң жакшысы, ачык кирүү программасын колдонуу. Бул үчүн эмнени тандай турганыбызды жана бул көйгөйдү чечүүгө канча убакыт сарптай турганыбызды чечиш гана калды, анткени колдонуучулар жетиштүү сүрөттөрдү алышкан эмес. Ошондуктан мунун бардыгын абдан, абдан тез жасашыбыз керек, деп айтышы мүмкүн кечээ.
Тапшырма "мүмкүн болушунча тезирээк бир нерсени жасап, бизде болгон жабдыктарды колдонуу" сыяктуу угулгандыктан, биз ойлогон биринчи нерсе, жөн гана алдыңкы жагынан анча күчтүү эмес машиналарды алып салуу, Nginxти ошол жерге коюу, биз аны кантип жасоону билебиз. иштеп, аппараттык каражаттар колдонгон логиканы ишке ашырууга аракет кылыңыз. Башкача айтканда, чындыгында, биз аппараттык камсыздообузду таштап, конфигурациялашыбыз керек болгон дагы 4 серверди орноттук, алар үчүн 10 жыл мурункудай тышкы домендерди түздүк... Бул машиналар кулап калса, биз бир аз жеткиликтүүлүгүн жоготтук, бирок дагы азыраак, алар биздин колдонуучулардын көйгөйүн жергиликтүү деңгээлде чечишти.
Демек, логика өзгөрүүсүз бойдон калууда: биз Nginx орното алабыз, ал SSL-жүктөөнү аткара алат, биз кандайдыр бир жол менен маршруттук логиканы программалай алабыз, конфигурациялардагы ден-соолукту текшере алабыз жана жөн гана бизде болгон логиканы кайталай алабыз.
Конфигурацияларды жазуу үчүн отуралы. Башында баары абдан жөнөкөй болуп көрүнгөн, бирок, тилекке каршы, ар бир иш үчүн колдонмолорду табуу абдан кыйын. Ошондуктан, биз жөн гана "сүрөттөр үчүн Nginxти кантип конфигурациялоо керек" дегенди жөн эле Google издөөнү сунуш кылбайбыз: расмий документацияга кайрылуу жакшы, анда кайсы орнотууларга тийүү керек. Бирок конкреттүү параметрди өзүңүз тандап алганыңыз жакшы. Ооба, анда баары жөнөкөй: бизде болгон серверлерди сүрөттөйбүз, сертификаттарды сүрөттөйбүз... Бирок эң кызыктуусу, чындыгында, маршрутташтыруу логикасынын өзү.
Адегенде биз жөн гана жайгашкан жерибизди сүрөттөп, андагы фото кэшибиздин санын дал келтирип, колубузду же генераторду колдонуп, канча өйдө агым керек экенин сүрөттөп жаткандай сезилди, ар бир агымда биз трафик керек болгон серверди көрсөтөбүз. барып, жана резервдик сервер - негизги сервер жок болсо:
Бирок, балким, баары ушунчалык жөнөкөй болсо, биз эч нерсе дебей үйгө жөнөйт элек. Тилекке каршы, демейки Nginx жөндөөлөрү менен, алар жалпысынан көп жылдар бою иштелип чыккан жана бул учурга таптакыр ылайыктуу эмес... конфигурация төмөнкүдөй көрүнөт: эгерде кээ бир өйдө жактагы серверде сурам катасы же күтүү убакыты болсо, Nginx ар дайым трафикти кийинкисине которот. Анын үстүнө, биринчи катадан кийин, 10 секунданын ичинде сервер да жаңылыштык менен да, тайм-аут менен да өчүрүлөт - муну эч кандай конфигурациялоо мүмкүн эмес. Башкача айтканда, эгерде биз жогорудагы директивадагы тайм-аут опциясын алып салсак же баштапкы абалга келтирсек, анда Nginx бул суроону иштетпейт жана анча жакшы эмес ката менен жооп берсе да, сервер жабылат.
Мунун алдын алуу үчүн биз эки нерсени кылдык:
а) алар Nginxке муну кол менен жасоого тыюу салышкан - жана тилекке каршы, муну жасоонун жалгыз жолу - жөн гана максималдуу ката орнотууларын коюу.
б) биз башка долбоорлордо ден соолукту фондук текшерүүлөрдү жүргүзүүгө мүмкүндүк берген модулду колдонгонубузду эстедик - ошого жараша авария болгон учурда токтоп калуулар минималдуу болушу үчүн ден соолукту тез-тез текшерип турчубуз.
Тилекке каршы, мунун баары эмес, анткени бул схеманын иштөөсүнүн алгачкы эки жумасы TCP ден соолугун текшерүү да ишенимсиз нерсе экенин көрсөттү: жогорку серверде ал Nginx же D абалындагы Nginx болбошу мүмкүн. бул учурда ядро байланышты кабыл алат, ден соолук текшерүүдөн өтөт, бирок иштебейт. Ошондуктан, биз аны дароо http Health-check менен алмаштырдык, конкреттүүсүн жасадык, эгерде ал 200 кайтарса, анда бардыгы ушул скриптте иштейт. Сиз кошумча логиканы жасай аласыз - мисалы, серверлерди кэштөө учурунда, файл тутумунун туура орнотулганын текшериңиз:
Жана бул бизге ылайыктуу болмок, бирок азыркы учурда схема аппараттык жабдык жасаганды толугу менен кайталады. Бирок биз жакшыраак иш кылгыбыз келди. Мурда бизде бир резервдик сервер бар болчу жана бул анча деле жакшы эместир, анткени сизде жүз сервер болсо, анда бир нечеси дароо иштебей калганда, бир резервдик сервер жүктү көтөрө албайт. Ошондуктан, биз резервацияны бардык серверлер боюнча бөлүштүрүүнү чечтик: биз жөн гана башка өзүнчө жогорку агым жасадык, ал жердеги бардык серверлерди алар тейлей турган жүктөмгө ылайык белгилүү бир параметрлер менен жаздык, буга чейин болгон ден-соолук текшерүүлөрүн коштук:
Бир өйдө агымдын ичинде башка агымга өтүү мүмкүн болбогондуктан, биз жөн гана туура, керектүү фото кэшти жаздырган негизги агым жеткиликсиз болсо, биз жөн гана error_page аркылуу кайра артка кайтууга өткөнүбүзгө ынануу керек болчу. биз камдык агымга кайда бардык:
Түзмө-түз төрт серверди кошуу менен, биз алган нерсебиз: жүктүн бир бөлүгүн алмаштырдык - биз аны LTMден бул серверлерге алып салдык, ошол эле логиканы стандарттык аппараттык жана программалык камсыздоону колдонуу менен ишке ашырдык жана ошол замат бул серверлер ала турган бонусту алдык. масштабдуу болушу керек, анткени алар жөн гана керектүү өлчөмдө камсыздалышы мүмкүн. Ооба, бир гана терс, биз тышкы колдонуучулар үчүн жогорку жеткиликтүүлүгүн жоготкон. Бирок ошол учурда биз муну курмандыкка чалууга туура келди, анткени маселени тез арада чечүү керек болчу. Ошентип, биз жүктүн бир бөлүгүн алып салдык, ал ошол учурда 40% га жакын болчу, LTM жакшы сезилди жана көйгөй башталгандан эки жума өткөндөн кийин биз секундасына 45 миң эмес, 55 миң суроону жөнөтө баштадык. Чынында, биз 20% га өстүк - бул биз колдонуучуга бербеген трафик. Ошондон кийин алар калган проблеманы кантип чечүү керектиги жөнүндө ойлоно башташты - жогорку тышкы жеткиликтүүлүктү камсыз кылуу.
Бизде бир аз тыныгуу болду, анын жүрүшүндө биз бул үчүн кандай чечимди колдонорубузду талкууладык. Кээ бир үйдө жазылган скрипттерди, динамикалык маршрутташтыруу протоколдорун колдонуп, DNS колдонуу менен ишенимдүүлүктү камсыз кылуу боюнча сунуштар бар болчу... көптөгөн варианттар бар болчу, бирок сүрөттөрдү чындап ишенимдүү жеткирүү үчүн, муну көзөмөлдөй турган башка катмарды киргизүү керек экени белгилүү болду. . Биз бул машиналарды фоторежиссерлор деп атадык. Биз таянган программа Keepalived болчу:
Баштоо үчүн, Keepalived эмнеден турат? Биринчиси VRRP протоколу, тармактык колдонуучуларга кеңири белгилүү, тармактык жабдууларда жайгашкан, ал кардарлар туташкан тышкы IP дарекке катачылыкка чыдамдуулукту камсыз кылат. Экинчи бөлүк - IPVS, IP виртуалдык сервер, фото роутерлердин ортосунда тең салмактуулукту сактоо жана ушул деңгээлде катачылыкка сабырдуулукту камсыз кылуу. Ал эми үчүнчү - ден соолук текшерүү.
Биринчи бөлүктөн баштайлы: VRRP - бул эмнеге окшош? Белгилүү бир виртуалдык IP бар, анда кардарлар туташкан dns badoocdn.com сайтында жазуусу бар. Убакыттын өтүшү менен бир серверде 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 туташуу үчүн көп кат жазат. жана башка . Албетте, серверлер көп болсо, анда бул тамгалар менен өзүңүздү каптап кете аласыз. Биз стандарттык ыкмаларды колдонуу менен фото роутерлерде nginxти көзөмөлдөйбүз, жана аппараттык мониторинг жок болгон жок. Биз, албетте, дагы эки нерсеге кеңеш бермекпиз: биринчиден, сырткы ден соолук-текшерүү жана жеткиликтүүлүк, анткени баары иштесе да, чындыгында, колдонуучулар тышкы провайдерлердин көйгөйлөрүнөн же андан да татаал нерседен улам сүрөттөрдү алышпайт. Бул ар дайым башка тармакта, Amazonда же башка жерде, серверлериңизге сырттан пинг жасай турган өзүнчө машинаны сактап калууга арзыйт, ошондой эле татаал машина үйрөнүүнү же жөнөкөй мониторингди билгендер үчүн аномалияны аныктоону колдонуу керек. , жок дегенде, суроо-талаптар кескин төмөндөп кеткенби же, тескерисинче, көбөйүп кеткендигин көзөмөлдөө үчүн. Ошондой эле пайдалуу болушу мүмкүн.
Жыйынтыктап көрөлү: биз, чындыгында, кандайдыр бир учурда бизге ылайыктуу болбой калган темир капталган чечимди бардыгын бирдей кылган, башкача айтканда, HTTPS трафигин токтотууну жана андан ары акылдуу маршрутташтыруу менен камсыз кылган жөнөкөй системага алмаштырдык. зарыл ден соолук текшерүүлөр. Биз бул системанын туруктуулугун жогорулаттык, башкача айтканда, бизде дагы эле ар бир катмар үчүн жогорку жеткиликтүүлүк бар, ошону менен бирге бизде бонус бар, мунун баарын ар бир катмарда масштабдоо оңой, анткени бул стандарттык программалык камсыздоо менен стандарттык аппараттык, башкача айтканда. , биз мүмкүн болгон көйгөйлөрдү аныктоону жөнөкөйлөштүрдүк.
Биз эмне менен бүттүк? Бизде 2018-жылдын январь майрамында көйгөй болгон. Биринчи алты айда биз бул схеманы ишке киргизип жатканда, LTMден бардык трафикти алып салуу үчүн аны бардык трафикке кеңейттик, биз бир маалымат борборундагы трафикти 40 гигабиттен 60 гигабитке чейин өстүрдүк жана ошол эле учурда бүт 2018 жыл секундасына дээрлик үч эсе көп сүрөттөрдү жөнөтө алышкан.
Source: www.habr.com