Mae'r we fodern bron yn annirnadwy heb gynnwys cyfryngau: mae gan bron bob mam-gu ffôn clyfar, mae pawb ar rwydweithiau cymdeithasol, ac mae amser segur mewn cynnal a chadw yn gostus i gwmnïau. Dyma drawsgrifiad o stori'r cwmni am sut y trefnodd gyflwyno lluniau gan ddefnyddio datrysiad caledwedd, pa broblemau perfformiad y daeth ar eu traws yn y broses, beth a'u hachosodd, a sut y datryswyd y problemau hyn gan ddefnyddio datrysiad meddalwedd yn seiliedig ar Nginx, tra'n sicrhau goddefgarwch namau ar bob lefel (). Diolchwn i awduron stori Oleg Efimova ac Alexandra Dymova, a rannodd eu profiad yn y gynhadledd .
- Gadewch i ni ddechrau gydag ychydig o gyflwyniad am sut rydyn ni'n storio a storio lluniau. Mae gennym haen lle rydyn ni'n eu storio, a haen lle rydyn ni'n storio'r lluniau. Ar yr un pryd, os ydym am gyflawni cyfradd tric uchel a lleihau'r llwyth ar storio, mae'n bwysig i ni fod pob llun o ddefnyddiwr unigol ar un gweinydd caching. Fel arall, byddai'n rhaid i ni osod cymaint o weithiau mwy o ddisgiau gan fod gennym fwy o weinyddion. Mae ein cyfradd triciau tua 99%, hynny yw, rydym yn lleihau'r llwyth ar ein storfa 100 gwaith, ac er mwyn gwneud hyn, 10 mlynedd yn ôl, pan oedd hyn i gyd yn cael ei adeiladu, roedd gennym 50 o weinyddion. Yn unol â hynny, er mwyn gwasanaethu'r lluniau hyn, yn y bôn roedd angen 50 parth allanol arnom y mae'r gweinyddwyr hyn yn eu gwasanaethu.
Yn naturiol, cododd y cwestiwn ar unwaith: os bydd un o'n gweinyddion yn mynd i lawr ac yn dod yn anhygyrch, pa ran o'r traffig rydyn ni'n ei golli? Fe wnaethom edrych ar yr hyn oedd ar y farchnad a phenderfynu prynu darn o galedwedd fel y byddai'n datrys ein holl broblemau. Syrthiodd y dewis ar ddatrysiad y cwmni rhwydwaith F5 (sydd, gyda llaw, yn prynu NGINX, Inc yn ddiweddar): Rheolwr Traffig Lleol BIG-IP.
Yr hyn y mae'r darn hwn o galedwedd (LTM) yn ei wneud: mae'n llwybrydd haearn sy'n dileu swyddi haearn o'i borthladdoedd allanol ac yn caniatáu ichi lwybro traffig yn seiliedig ar dopoleg y rhwydwaith, ar rai lleoliadau, ac yn gwneud gwiriadau iechyd. Roedd yn bwysig i ni y gellid rhaglennu'r darn hwn o galedwedd. Yn unol â hynny, gallem ddisgrifio'r rhesymeg o sut y cyflwynwyd ffotograffau o ddefnyddiwr penodol o storfa benodol. Beth mae'n edrych fel? Mae yna ddarn o galedwedd sy'n edrych ar y Rhyngrwyd ar un parth, un IP, yn dadlwytho ssl, yn dosrannu ceisiadau http, yn dewis rhif storfa o IRule, ble i fynd, ac yn gadael i draffig fynd yno. Ar yr un pryd, mae'n cynnal gwiriadau iechyd, ac os na fydd rhywfaint o beiriant ar gael, ar yr adeg honno fe'i gwnaethom fel bod y traffig yn mynd i un gweinydd wrth gefn. O safbwynt cyfluniad, wrth gwrs, mae rhai naws, ond yn gyffredinol mae popeth yn eithaf syml: rydym yn cofrestru cerdyn, gohebiaeth o rif penodol i'n IP ar y rhwydwaith, dywedwn y byddwn yn gwrando ar borthladdoedd 80 a 443, dywedwn, os nad yw'r gweinydd ar gael, yna mae angen i chi anfon traffig i'r un wrth gefn, yn yr achos hwn y 35ain, ac rydym yn disgrifio criw o resymeg ar sut y dylid dadosod y bensaernïaeth hon. Yr unig broblem oedd mai Tcl oedd yr iaith y rhaglennwyd y caledwedd ynddi. Os oes unrhyw un yn cofio hyn o gwbl... mae'r iaith hon yn fwy ysgrifennu-yn-unig nag iaith sy'n gyfleus ar gyfer rhaglennu:
Beth gawson ni? Cawsom ddarn o galedwedd sy'n sicrhau bod ein seilwaith ar gael yn uchel, yn llwybro ein holl draffig, yn darparu buddion iechyd ac yn gweithio'n unig. Ar ben hynny, mae'n gweithio am amser eithaf hir: dros y 10 mlynedd diwethaf ni fu unrhyw gwynion amdano. Erbyn dechrau 2018, roeddem eisoes yn anfon tua 80k o luniau yr eiliad. Mae hyn rhywle tua 80 gigabits o draffig o'n dwy ganolfan ddata.
Fodd bynnag…
Ar ddechrau 2018, gwelsom lun hyll ar y siartiau: roedd yr amser a gymerodd i anfon lluniau yn amlwg wedi cynyddu. Ac roedd yn stopio ein siwtio ni. Y broblem yw bod yr ymddygiad hwn yn weladwy yn unig yn ystod y brig o draffig - i'n cwmni dyma'r noson o ddydd Sul i ddydd Llun. Ond gweddill yr amser roedd y system yn ymddwyn fel arfer, dim arwyddion o fethiant.
Serch hynny, roedd yn rhaid datrys y broblem. Gwnaethom nodi tagfeydd posibl a dechrau eu dileu. Yn gyntaf oll, wrth gwrs, fe wnaethom ehangu cysylltiadau allanol, cynnal archwiliad cyflawn o uwchgysylltiadau mewnol, a dod o hyd i bob tagfa bosibl. Ond ni roddodd hyn i gyd ganlyniad amlwg, ni ddiflannodd y broblem.
Tagfa bosibl arall oedd perfformiad y celc lluniau eu hunain. Ac fe wnaethon ni benderfynu efallai mai nhw sydd â'r broblem. Wel, fe wnaethom ehangu'r perfformiad - yn bennaf porthladdoedd rhwydwaith ar caches lluniau. Ond eto ni welwyd gwelliant amlwg. Yn y diwedd, fe wnaethom dalu sylw manwl i berfformiad y LTM ei hun, ac yma gwelsom lun trist ar y graffiau: mae'r llwyth ar bob CPU yn dechrau mynd yn esmwyth, ond yna'n sydyn yn dod i lwyfandir. Ar yr un pryd, mae LTM yn rhoi'r gorau i ymateb yn ddigonol i wiriadau iechyd ac uwchgysylltiadau ac yn dechrau eu diffodd ar hap, sy'n arwain at ddiraddio perfformiad difrifol.
Hynny yw, rydym wedi nodi ffynhonnell y broblem, wedi nodi'r dagfa. Erys i benderfynu beth fyddwn yn ei wneud.
Y peth cyntaf, amlycaf y gallem ei wneud yw moderneiddio'r LTM ei hun rywsut. Ond mae yna rai arlliwiau yma, oherwydd bod y caledwedd hwn yn eithaf unigryw, ni fyddwch yn mynd i'r archfarchnad agosaf a'i brynu. Mae hwn yn gontract ar wahân, yn gontract trwydded ar wahân, a bydd yn cymryd llawer o amser. Yr ail opsiwn yw dechrau meddwl drosoch eich hun, creu eich datrysiad eich hun gan ddefnyddio'ch cydrannau eich hun, gan ddefnyddio rhaglen mynediad agored yn ddelfrydol. Y cyfan sydd ar ôl yw penderfynu beth yn union y byddwn yn ei ddewis ar gyfer hyn a faint o amser y byddwn yn ei dreulio ar ddatrys y broblem hon, oherwydd nid oedd defnyddwyr yn derbyn digon o luniau. Felly, mae angen inni wneud hyn i gyd yn gyflym iawn, iawn, efallai y bydd rhywun yn dweud ddoe.
Gan fod y dasg yn swnio fel “gwnewch rywbeth cyn gynted â phosibl a defnyddio'r caledwedd sydd gennym ni,” y peth cyntaf yr oeddem yn meddwl oedd tynnu rhai peiriannau nad oeddent yn bwerus iawn o'r blaen, rhowch Nginx yno, ac rydym yn gwybod sut i wneud hynny. gweithio a cheisio gweithredu'r un rhesymeg ag yr oedd caledwedd yn arfer ei wneud. Hynny yw, mewn gwirionedd, fe wnaethom adael ein caledwedd, gosod 4 gweinydd arall yr oedd yn rhaid i ni eu ffurfweddu, creu parthau allanol ar eu cyfer, yn debyg i sut yr oedd 10 mlynedd yn ôl... Fe gollon ni ychydig o argaeledd pe bai'r peiriannau hyn yn disgyn, ond dal yn llai, maent yn datrys y broblem ein defnyddwyr yn lleol.
Yn unol â hynny, mae'r rhesymeg yn aros yr un fath: rydym yn gosod Nginx, gall wneud dadlwytho SSL, gallwn rywsut raglennu'r rhesymeg llwybro, gwiriadau iechyd yn y cyfluniadau a dim ond dyblygu'r rhesymeg a oedd gennym o'r blaen.
Gadewch i ni eistedd i lawr i ysgrifennu configs. Ar y dechrau roedd yn ymddangos bod popeth yn syml iawn, ond, yn anffodus, mae'n anodd iawn dod o hyd i lawlyfrau ar gyfer pob tasg. Felly, nid ydym yn argymell googling yn syml “sut i ffurfweddu Nginx ar gyfer lluniau”: mae'n well cyfeirio at y ddogfennaeth swyddogol, a fydd yn dangos pa osodiadau y dylid eu cyffwrdd. Ond mae'n well dewis y paramedr penodol eich hun. Wel, yna mae popeth yn syml: rydyn ni'n disgrifio'r gweinyddwyr sydd gennym ni, rydyn ni'n disgrifio'r tystysgrifau ... Ond y peth mwyaf diddorol, mewn gwirionedd, yw'r rhesymeg llwybro ei hun.
Ar y dechrau roedd yn ymddangos i ni ein bod yn disgrifio ein lleoliad yn syml, gan baru nifer ein storfa ffotograffau ynddo, gan ddefnyddio ein dwylo neu eneradur i ddisgrifio faint o lifau i fyny'r afon sydd eu hangen arnom, ym mhob i fyny'r afon rydym yn nodi'r gweinydd y dylai'r traffig ei gyrraedd. ewch, a gweinydd wrth gefn - os nad yw'r prif weinydd ar gael:
Ond, mae'n debyg, pe bai popeth mor syml, yn syml iawn y byddem yn mynd adref ac yn peidio â dweud dim byd. Yn anffodus, gyda'r gosodiadau Nginx rhagosodedig, a wnaed, yn gyffredinol, dros nifer o flynyddoedd o ddatblygiad ac nid ydynt yn gwbl addas ar gyfer yr achos hwn ... mae'r ffurfwedd yn edrych fel hyn: os oes gan rai gweinydd i fyny'r afon wall cais neu derfyn amser, mae Nginx bob amser yn newid traffig i'r un nesaf. Ar ben hynny, ar ôl y methiant cyntaf, o fewn 10 eiliad bydd y gweinydd hefyd yn cael ei ddiffodd, trwy gamgymeriad a thrwy amser terfyn - ni ellir hyd yn oed ffurfweddu hyn mewn unrhyw ffordd. Hynny yw, os byddwn yn dileu neu'n ailosod yr opsiwn terfyn amser yn y gyfarwyddeb i fyny'r afon, yna, er na fydd Nginx yn prosesu'r cais hwn ac y bydd yn ymateb gyda rhai gwallau nad ydynt yn dda iawn, bydd y gweinydd yn cau.
Er mwyn osgoi hyn, fe wnaethom ddau beth:
a) maent yn gwahardd Nginx rhag gwneud hyn â llaw - ac yn anffodus, yr unig ffordd i wneud hyn yw gosod y gosodiadau mwyaf yn methu.
b) gwnaethom gofio ein bod mewn prosiectau eraill yn defnyddio modiwl sy'n ein galluogi i wneud gwiriadau iechyd cefndirol - yn unol â hynny, gwnaethom wiriadau iechyd eithaf aml fel mai ychydig iawn o amser segur fyddai'n digwydd pe bai damwain.
Yn anffodus, nid yw hyn i gyd ychwaith, oherwydd yn llythrennol roedd pythefnos cyntaf gweithrediad y cynllun hwn yn dangos bod gwiriad iechyd TCP hefyd yn beth annibynadwy: ar y gweinydd i fyny'r afon efallai nad Nginx, neu Nginx yn D-state, ac mewn yn yr achos hwn bydd y cnewyllyn yn derbyn y cysylltiad, bydd gwiriad iechyd yn mynd heibio, ond ni fydd yn gweithio. Felly, fe wnaethom ddisodli hyn ar unwaith â gwiriad iechyd http, gwneud un penodol, sydd, os bydd yn dychwelyd 200, yna mae popeth yn gweithio yn y sgript hon. Gallwch chi wneud rhesymeg ychwanegol - er enghraifft, yn achos gweinyddwyr caching, gwiriwch fod y system ffeiliau wedi'i gosod yn gywir:
A byddai hyn yn addas i ni, ac eithrio bod y gylched yn ailadrodd yn llwyr yr hyn a wnaeth y caledwedd ar hyn o bryd. Ond roedden ni eisiau gwneud yn well. Yn flaenorol, roedd gennym un gweinydd wrth gefn, ac mae'n debyg nad yw hyn yn dda iawn, oherwydd os oes gennych gant o weinyddion, yna pan fydd sawl un yn methu ar unwaith, mae un gweinydd wrth gefn yn annhebygol o ymdopi â'r llwyth. Felly, fe benderfynon ni ddosbarthu'r archeb ar draws yr holl weinyddion: yn syml iawn fe wnaethom ni wneud un arall i fyny'r afon, ysgrifennu'r holl weinyddion yno gyda pharamedrau penodol yn unol â'r llwyth y gallant ei wasanaethu, ychwanegu'r un gwiriadau iechyd ag a gawsom o'r blaen :
Gan ei bod yn amhosibl mynd i un arall i fyny'r afon o fewn un i fyny'r afon, roedd angen sicrhau pe na bai'r brif ffrwd i fyny'r afon, lle'r oeddem yn syml yn cofnodi'r storfa ffotograffau cywir, angenrheidiol, ar gael, fe aethom trwy'r error_page i wrth gefn, o lle aethon ni i'r copi wrth gefn i fyny'r afon:
A thrwy ychwanegu pedwar gweinydd yn llythrennol, dyma'r hyn a gawsom: fe wnaethom ddisodli rhan o'r llwyth - fe wnaethom ei dynnu o LTM i'r gweinyddwyr hyn, gweithredu'r un rhesymeg yno, gan ddefnyddio caledwedd a meddalwedd safonol, a derbyniwyd y bonws y gall y gweinyddwyr hyn ar unwaith. cael eu graddio, oherwydd gallant fod yn gyflenwad cymaint ag sydd ei angen. Wel, yr unig negyddol yw ein bod wedi colli argaeledd uchel ar gyfer defnyddwyr allanol. Ond ar y foment roedd yn rhaid i ni aberthu hyn, oherwydd roedd angen datrys y broblem ar unwaith. Felly, fe wnaethom dynnu rhan o'r llwyth, roedd tua 40% ar y pryd, roedd LTM yn teimlo'n dda, ac yn llythrennol bythefnos ar ôl i'r broblem ddechrau, dechreuon ni anfon nid 45k o geisiadau yr eiliad, ond 55k. Mewn gwirionedd, fe wnaethom dyfu 20% - mae'n amlwg mai dyma'r traffig na wnaethom ei roi i'r defnyddiwr. Ac ar ôl hynny dechreuon nhw feddwl am sut i ddatrys y broblem sy'n weddill - er mwyn sicrhau hygyrchedd allanol uchel.
Cawsom rywfaint o saib, a thrafodwyd pa ateb y byddem yn ei ddefnyddio ar gyfer hyn. Roedd cynigion i sicrhau dibynadwyedd gan ddefnyddio DNS, gan ddefnyddio rhai sgriptiau a ysgrifennwyd gartref, protocolau llwybro deinamig ... roedd llawer o opsiynau, ond daeth yn amlwg eisoes, er mwyn cyflwyno lluniau yn wirioneddol ddibynadwy, bod angen ichi gyflwyno haen arall a fydd yn monitro hyn . Fe wnaethon ni alw'r peiriannau llun cyfarwyddwyr hyn. Y feddalwedd y buom yn dibynnu arno oedd Keepvived:
I ddechrau, beth mae Keepaved yn ei gynnwys? Y cyntaf yw'r protocol VRRP, sy'n hysbys yn eang i rwydweithwyr, sydd wedi'i leoli ar offer rhwydwaith sy'n darparu goddefgarwch nam i'r cyfeiriad IP allanol y mae cleientiaid yn cysylltu ag ef. Yr ail ran yw IPVS, gweinydd rhithwir IP, ar gyfer cydbwyso rhwng llwybryddion lluniau a sicrhau goddefgarwch nam ar y lefel hon. Ac yn drydydd - gwiriadau iechyd.
Gadewch i ni ddechrau gyda'r rhan gyntaf: VRRP - sut olwg sydd arno? Mae yna IP rhithwir penodol, sydd â chofnod yn y dns badoocdn.com, lle mae cleientiaid yn cysylltu. Ar ryw adeg, mae gennym gyfeiriad IP ar un gweinydd. Mae pecynnau Keepvived yn rhedeg rhwng y gweinyddwyr gan ddefnyddio'r protocol VRRP, ac os yw'r meistr yn diflannu o'r radar - mae'r gweinydd wedi ailgychwyn neu rywbeth arall, yna mae'r gweinydd wrth gefn yn codi'r cyfeiriad IP hwn yn awtomatig - nid oes angen unrhyw gamau gweithredu â llaw. Mae'r gwahaniaeth rhwng meistr a copi wrth gefn yn flaenoriaeth yn bennaf: po uchaf ydyw, y mwyaf yw'r siawns y bydd y peiriant yn dod yn feistr. Mantais fawr iawn yw nad oes angen i chi ffurfweddu cyfeiriadau IP ar y gweinydd ei hun, mae'n ddigon i'w disgrifio yn y ffurfwedd, ac os oes angen rhai rheolau llwybro arferol ar y cyfeiriadau IP, disgrifir hyn yn uniongyrchol yn y ffurfwedd, gan ddefnyddio'r yr un gystrawen ag a ddisgrifir yn y pecyn VRRP. Ni fyddwch yn dod ar draws unrhyw bethau anghyfarwydd.
Sut olwg sydd ar hyn yn ymarferol? Beth sy'n digwydd os bydd un o'r gweinyddion yn methu? Cyn gynted ag y bydd y meistr yn diflannu, mae ein copi wrth gefn yn rhoi'r gorau i dderbyn hysbysebion ac yn dod yn feistr yn awtomatig. Ar ôl peth amser, fe wnaethom atgyweirio'r meistr, ailgychwyn, codi Keepalive - mae hysbysebion yn cyrraedd gyda blaenoriaeth uwch na'r copi wrth gefn, ac mae'r copi wrth gefn yn troi'n ôl yn awtomatig, yn dileu cyfeiriadau IP, nid oes angen gwneud unrhyw gamau gweithredu â llaw.
Felly, rydym wedi sicrhau goddefgarwch bai y cyfeiriad IP allanol. Y rhan nesaf yw rhywsut i gydbwyso'r traffig o'r cyfeiriad IP allanol i'r llwybryddion lluniau sydd eisoes yn ei derfynu. Mae popeth yn eithaf clir gyda'r protocolau cydbwyso. Mae hwn naill ai yn rownd-robin syml, neu bethau ychydig yn fwy cymhleth, wrr, cysylltiad rhestr ac ati. Disgrifir hyn yn y bôn yn y ddogfennaeth, nid oes unrhyw beth arbennig. Ond y dull dosbarthu... Yma byddwn yn edrych yn agosach ar pam y gwnaethom ddewis un ohonynt. Y rhain yw NAT, Llwybro Uniongyrchol a HDDD. Y ffaith yw ein bod yn bwriadu danfon 100 gigabeit o draffig o'r safleoedd ar unwaith. Os ydych chi'n amcangyfrif, mae angen 10 cerdyn gigabit arnoch chi, iawn? Mae 10 cerdyn gigabit mewn un gweinydd eisoes y tu hwnt i gwmpas, o leiaf, ein cysyniad o “offer safonol”. Ac yna fe wnaethon ni gofio nad ydyn ni'n rhoi rhywfaint o draffig i ffwrdd yn unig, rydyn ni'n rhoi lluniau i ffwrdd.
Beth sy'n arbennig? — Gwahaniaeth enfawr rhwng traffig sy'n dod i mewn ac yn mynd allan. Mae traffig sy'n dod i mewn yn fach iawn, mae traffig sy'n mynd allan yn fawr iawn:
Os edrychwch ar y graffiau hyn, gallwch weld bod y cyfarwyddwr yn derbyn tua 200 MB yr eiliad ar hyn o bryd, mae hwn yn ddiwrnod cyffredin iawn. Rydyn ni'n rhoi 4,500 MB yr eiliad yn ôl, mae ein cymhareb oddeutu 1/22. Mae eisoes yn amlwg, er mwyn darparu traffig sy'n mynd allan yn llawn i 22 o weinyddion gweithwyr, mai dim ond un sy'n derbyn y cysylltiad hwn sydd ei angen arnom. Dyma lle mae'r algorithm llwybro uniongyrchol yn dod i'n cymorth ni.
Beth mae'n edrych fel? Mae ein cyfarwyddwr lluniau, yn ôl ei fwrdd, yn trosglwyddo cysylltiadau i lwybryddion lluniau. Ond mae llwybryddion lluniau yn anfon traffig dychwelyd yn uniongyrchol i'r Rhyngrwyd, yn ei anfon at y cleient, nid yw'n mynd yn ôl trwy'r cyfarwyddwr lluniau, felly, gyda nifer lleiaf o beiriannau, rydym yn sicrhau goddefgarwch bai cyflawn a phwmpio'r holl draffig. Yn y cyfluniadau mae'n edrych fel hyn: rydyn ni'n nodi'r algorithm, yn ein hachos ni mae'n rr syml, yn darparu'r dull llwybro uniongyrchol ac yna'n dechrau rhestru'r holl weinyddion go iawn, faint ohonyn nhw sydd gennym ni. A fydd yn pennu'r traffig hwn. Os oes gennym ni un neu ddau weinydd arall yno, neu sawl gweinydd, mae angen o'r fath yn codi - rydyn ni'n ychwanegu'r adran hon at y ffurfweddiad a pheidiwch â phoeni gormod. O ochr gweinyddwyr go iawn, o ochr y llwybrydd lluniau, mae'r dull hwn yn gofyn am y cyfluniad lleiaf posibl, fe'i disgrifir yn berffaith yn y ddogfennaeth, ac nid oes unrhyw beryglon yno.
Yr hyn sy'n arbennig o braf yw nad yw datrysiad o'r fath yn awgrymu ailgynllunio radical o'r rhwydwaith lleol; roedd hyn yn bwysig i ni; roedd yn rhaid i ni ddatrys hyn heb fawr o gostau. Os edrychwch ar , yna byddwn yn gweld sut olwg sydd arno. Yma mae gennym weinydd rhithwir penodol, ar borthladd 443, yn gwrando, yn derbyn y cysylltiad, mae'r holl weinyddion gweithio wedi'u rhestru, a gallwch weld bod y cysylltiad, rhoi neu gymryd, yr un peth. Os edrychwn ar yr ystadegau ar yr un gweinydd rhithwir, mae gennym becynnau sy'n dod i mewn, cysylltiadau sy'n dod i mewn, ond dim rhai sy'n mynd allan o gwbl. Mae cysylltiadau sy'n mynd allan yn mynd yn uniongyrchol i'r cleient. Iawn, roeddem yn gallu ei anghydbwysedd. Nawr, beth sy'n digwydd os bydd un o'n llwybryddion lluniau yn methu? Wedi'r cyfan, haearn yw haearn. Efallai y bydd yn mynd i banig cnewyllyn, efallai y bydd yn torri, efallai y bydd y cyflenwad pŵer yn llosgi allan. Unrhyw beth. Dyna pam mae angen archwiliadau iechyd. Gallant fod mor syml â gwirio sut mae'r porthladd ar agor, neu rywbeth mwy cymhleth, hyd at rai sgriptiau cartref a fydd hyd yn oed yn gwirio rhesymeg y busnes.
Fe wnaethon ni stopio rhywle yn y canol: mae gennym ni gais https i leoliad penodol, gelwir y sgript, os yw'n ymateb gydag ymateb 200, credwn fod popeth yn iawn gyda'r gweinydd hwn, ei fod yn fyw ac y gellir ei droi ymlaen yn eithaf hawdd.
Sut mae hyn, eto, yn edrych yn ymarferol? Gadewch i ni ddiffodd y gweinydd ar gyfer cynnal a chadw - fflachio'r BIOS, er enghraifft. Yn y logiau, mae gennym derfyn amser ar unwaith, fe welwn y llinell gyntaf, yna ar ôl tri chynnig mae'n cael ei farcio fel “methu”, ac yn syml, caiff ei dynnu oddi ar y rhestr.
Mae ail opsiwn ymddygiad hefyd yn bosibl, pan fydd VS wedi'i osod i sero, ond os dychwelir y llun, nid yw hyn yn gweithio'n dda. Daw'r gweinydd i fyny, mae Nginx yn cychwyn yno, mae gwiriad iechyd yn deall ar unwaith bod y cysylltiad yn gweithio, bod popeth yn iawn, ac mae'r gweinydd yn ymddangos yn ein rhestr, ac mae'r llwyth yn dechrau cael ei gymhwyso iddo ar unwaith. Nid oes angen unrhyw gamau gweithredu â llaw gan y gweinyddwr ar ddyletswydd. Ailgychwynnodd y gweinydd yn y nos - nid yw'r adran fonitro yn ein ffonio am hyn gyda'r nos. Maen nhw'n eich hysbysu bod hyn wedi digwydd, mae popeth yn iawn.
Felly, mewn ffordd weddol syml, gyda chymorth nifer fach o weinyddion, gwnaethom ddatrys problem goddefgarwch bai allanol.
Y cyfan sydd ar ôl i'w ddweud yw bod angen monitro hyn oll, wrth gwrs. Ar wahân, dylid nodi bod gan Keepalivede, fel meddalwedd a ysgrifennwyd amser maith yn ôl, lawer o ffyrdd i'w fonitro, gan ddefnyddio gwiriadau trwy DBus, SMTP, SNMP, a Zabbix safonol. Hefyd, mae ef ei hun yn gwybod sut i ysgrifennu llythyrau ar gyfer bron pob tisian, ac i fod yn onest, ar ryw adeg fe wnaethom hyd yn oed feddwl am ei ddiffodd, oherwydd ei fod yn ysgrifennu llawer o lythyrau ar gyfer unrhyw draffig yn newid, yn troi ymlaen, ar gyfer pob cysylltiad IP, ac yn y blaen. Wrth gwrs, os oes llawer o weinyddion, yna gallwch chi orlethu eich hun gyda'r llythyrau hyn. Rydym yn monitro nginx ar lwybryddion lluniau gan ddefnyddio dulliau safonol, ac nid yw monitro caledwedd wedi diflannu. Byddem, wrth gwrs, yn cynghori dau beth arall: yn gyntaf, gwiriadau iechyd allanol ac argaeledd, oherwydd hyd yn oed os yw popeth yn gweithio, mewn gwirionedd, efallai nad yw defnyddwyr yn derbyn lluniau oherwydd problemau gyda darparwyr allanol neu rywbeth mwy cymhleth. Mae bob amser yn werth cadw rhywle ar rwydwaith arall, yn Amazon neu rywle arall, peiriant ar wahân sy'n gallu pingio'ch gweinyddwyr o'r tu allan, ac mae hefyd yn werth defnyddio naill ai canfod anghysondebau, ar gyfer y rhai sy'n gwybod sut i ddysgu peiriant anodd, neu monitro syml, o leiaf er mwyn olrhain a yw ceisiadau wedi gostwng yn sydyn, neu, i'r gwrthwyneb, wedi cynyddu. Gall fod yn ddefnyddiol hefyd.
Gadewch i ni grynhoi: fe wnaethom ni, mewn gwirionedd, ddisodli'r datrysiad wedi'i orchuddio â haearn, a oedd ar ryw adeg yn peidio â bod yn addas i ni, gyda system weddol syml sy'n gwneud popeth yr un peth, hynny yw, mae'n rhoi terfyn ar draffig HTTPS a llwybro clyfar pellach gyda'r archwiliadau iechyd angenrheidiol. Rydym wedi cynyddu sefydlogrwydd y system hon, hynny yw, mae gennym argaeledd uchel o hyd ar gyfer pob haen, ac mae gennym y bonws ei bod yn eithaf hawdd graddio'r cyfan ar bob haen, oherwydd ei fod yn galedwedd safonol gyda meddalwedd safonol, hynny yw , rydym wedi symleiddio gwneud diagnosis o broblemau posibl.
Beth wnaethom ni yn y diwedd? Cawsom broblem yn ystod gwyliau Ionawr 2018. Yn ystod y chwe mis cyntaf wrth i ni roi'r cynllun hwn ar waith, fe wnaethom ei ehangu i bob traffig er mwyn tynnu'r holl draffig o LTM, dim ond mewn un ganolfan ddata y tyfodd traffig o 40 gigabits i 60 gigabits, ac ar yr un pryd ar gyfer llwyddodd y flwyddyn 2018 gyfan i anfon bron deirgwaith yn fwy o luniau yr eiliad.
Ffynhonnell: hab.com