Helo, Habr! Artem Karamyshev ydw i, pennaeth tîm gweinyddu'r system . Rydym wedi cael llawer o lansiadau cynnyrch newydd dros y flwyddyn ddiwethaf. Roeddem am sicrhau bod gwasanaethau API yn hawdd eu graddio, yn gallu goddef diffygion, ac yn barod ar gyfer twf cyflym mewn llwyth defnyddwyr. Mae ein platfform yn cael ei weithredu ar OpenStack, ac rwyf am ddweud wrthych pa broblemau goddefgarwch namau cydran y bu'n rhaid i ni eu datrys i gael system sy'n goddef diffygion. Rwy'n credu y bydd hyn yn ddiddorol i'r rhai sydd hefyd yn datblygu cynhyrchion ar OpenStack.
Mae goddefgarwch bai cyffredinol llwyfan yn cynnwys gwytnwch ei gydrannau. Felly byddwn yn mynd drwy'r holl lefelau yn raddol lle gwnaethom nodi risgiau a'u cau.
Fersiwn fideo o'r stori hon, a'i phrif ffynhonnell oedd adroddiad yng nghynhadledd diwrnod 4 Uptime, a drefnwyd gan , gallwch weld .
Gwydnwch y bensaernïaeth ffisegol
Mae rhan gyhoeddus cwmwl MCS bellach wedi'i lleoli mewn dwy ganolfan ddata Haen III, rhyngddynt mae ei ffibr tywyll ei hun, wedi'i gadw ar y lefel ffisegol gan wahanol lwybrau, gyda mewnbwn o 200 Gbit yr eiliad. Mae Haen III yn darparu'r lefel angenrheidiol o oddefiad namau ar gyfer y seilwaith ffisegol.
Mae ffibr tywyll yn cael ei gadw ar y lefelau ffisegol a rhesymegol. Roedd y broses cadw sianel yn ailadroddus, cododd problemau, ac rydym yn gwella cyfathrebu rhwng canolfannau data yn gyson.
Er enghraifft, ddim yn bell yn ôl, tra'n gweithio mewn ffynnon ger un o'r canolfannau data, torrodd cloddiwr bibell, ac y tu mewn i'r bibell hon roedd prif bibell a chebl optegol wrth gefn. Trodd ein sianel gyfathrebu a oedd yn goddef namau gyda'r ganolfan ddata yn agored i niwed ar un adeg, yn y ffynnon. Yn unol â hynny, rydym wedi colli rhan o’r seilwaith. Daethom i gasgliadau a chymerwyd nifer o gamau, gan gynnwys gosod opteg ychwanegol yn y ffynnon gyfagos.
Mewn canolfannau data mae yna bwyntiau o bresenoldeb darparwyr cyfathrebiadau y darlledwn ein rhagddodiaid iddynt trwy BGP. Ar gyfer pob cyfeiriad rhwydwaith, dewisir y metrig gorau, sy'n caniatáu i wahanol gleientiaid gael yr ansawdd cysylltiad gorau. Os bydd cyfathrebu trwy un darparwr yn lleihau, rydym yn ailadeiladu ein llwybro trwy'r darparwyr sydd ar gael.
Os bydd darparwr yn methu, byddwn yn newid yn awtomatig i'r un nesaf. Os bydd un o'r canolfannau data yn methu, mae gennym gopi drych o'n gwasanaethau yn yr ail ganolfan ddata, sy'n cymryd y llwyth cyfan.
Gwydnwch seilwaith ffisegol
Yr hyn rydyn ni'n ei ddefnyddio ar gyfer goddefgarwch bai ar lefel cais
Mae ein gwasanaeth yn seiliedig ar nifer o gydrannau ffynhonnell agored.
ExaBGP yn wasanaeth sy'n gweithredu nifer o swyddogaethau gan ddefnyddio'r protocol llwybro deinamig sy'n seiliedig ar BGP. Rydym yn ei ddefnyddio'n weithredol i hysbysebu ein cyfeiriadau IP ar y rhestr wen y mae defnyddwyr yn cyrchu'r API drwyddynt.
HAProxy yn gydbwysedd llwyth uchel sy'n eich galluogi i ffurfweddu rheolau cydbwyso traffig hyblyg iawn ar wahanol lefelau o'r model OSI. Rydym yn ei ddefnyddio i gydbwyso o flaen yr holl wasanaethau: cronfeydd data, broceriaid negeseuon, gwasanaethau API, gwasanaethau gwe, ein prosiectau mewnol - mae popeth y tu ôl i HAProxy.
Cais API - cymhwysiad gwe wedi'i ysgrifennu yn python, y mae'r defnyddiwr yn rheoli ei seilwaith a'i wasanaeth ag ef.
Cais gweithiwr (o hyn ymlaen yn syml gweithiwr) - mewn gwasanaethau OpenStack, mae hwn yn daemon seilwaith sy'n eich galluogi i ddarlledu gorchmynion API i'r seilwaith. Er enghraifft, mae creu disg yn digwydd yn y gweithiwr, ac mae'r cais creu yn digwydd yn API y cymhwysiad.
Pensaernïaeth Cais OpenStack Safonol
Mae'r rhan fwyaf o wasanaethau sy'n cael eu datblygu ar gyfer OpenStack yn ceisio dilyn un patrwm. Mae gwasanaeth fel arfer yn cynnwys 2 ran: API a gweithwyr (ysgutorion backend). Fel rheol, mae API yn gais WSGI yn python, sy'n cael ei lansio naill ai fel proses annibynnol (daemon), neu gan ddefnyddio gweinydd gwe Nginx neu Apache parod. Mae'r API yn prosesu cais y defnyddiwr ac yn trosglwyddo cyfarwyddiadau pellach i gais y gweithiwr i'w weithredu. Mae'r trosglwyddiad yn digwydd gan ddefnyddio brocer negeseuon, fel arfer RabbitMQ, ac mae'r lleill yn cael eu cefnogi'n wael. Pan fydd negeseuon yn cyrraedd y brocer, maent yn cael eu prosesu gan weithwyr ac, os oes angen, yn dychwelyd ymateb.
Mae'r patrwm hwn yn cynnwys pwyntiau methiant cyffredin unigol: RabbitMQ a'r gronfa ddata. Ond mae RabbitMQ wedi'i ynysu o fewn un gwasanaeth ac, mewn egwyddor, gall fod yn unigol ar gyfer pob gwasanaeth. Felly yn MCS rydym yn gwahanu’r gwasanaethau hyn cymaint â phosibl; ar gyfer pob prosiect unigol rydym yn creu cronfa ddata ar wahân, RabbitMQ ar wahân. Mae'r dull hwn yn dda oherwydd os bydd damwain ar rai adegau bregus, nid yw'r gwasanaeth cyfan yn torri i lawr, ond dim ond rhan ohono.
Mae nifer y ceisiadau gweithwyr yn anghyfyngedig, felly gall yr API raddfa'n llorweddol yn hawdd y tu ôl i'r balanswyr er mwyn cynyddu perfformiad a goddefgarwch bai.
Mae angen cydlynu rhai gwasanaethau o fewn y gwasanaeth pan fydd gweithrediadau dilyniannol cymhleth yn digwydd rhwng APIs a gweithwyr. Yn yr achos hwn, defnyddir un ganolfan gydlynu, system glwstwr fel Redis, Memcache, ac ati, sy'n caniatáu i un gweithiwr ddweud wrth un arall bod y dasg hon wedi'i neilltuo iddo (peidiwch â'i gymryd"). Rydym yn defnyddio ac ati. Fel rheol, mae gweithwyr yn cyfathrebu'n weithredol â'r gronfa ddata, yn ysgrifennu ac yn darllen gwybodaeth oddi yno. Rydym yn defnyddio mariadb fel cronfa ddata, sydd wedi'i lleoli mewn clwstwr amlfeistr.
Trefnir y gwasanaeth sengl clasurol hwn mewn modd a dderbynnir yn gyffredinol ar gyfer OpenStack. Gellir ei ystyried fel system gaeedig, y mae'r dulliau graddio a goddefgarwch bai yn eithaf amlwg ar ei gyfer. Er enghraifft, ar gyfer goddefgarwch fai API, mae'n ddigon i roi balancer o'u blaenau. Cyflawnir graddio gweithwyr trwy gynyddu eu nifer.
Y pwynt gwan yn y cynllun cyfan yw RabbitMQ a MariaDB. Mae eu pensaernïaeth yn haeddu erthygl ar wahân.Yn yr erthygl hon rwyf am ganolbwyntio ar oddefgarwch fai API.
Pensaernïaeth Cais Openstack. Cydbwyso a goddefgarwch bai y llwyfan cwmwl
Gwneud y cydbwysedd HAProxy yn oddefgar o namau gan ddefnyddio ExaBGP
Er mwyn gwneud ein APIs yn raddadwy, yn gyflym ac yn oddefgar o ddiffygion, rydyn ni'n rhoi cydbwysedd llwyth o'u blaenau. Dewison ni HAProxy. Yn fy marn i, mae ganddo'r holl nodweddion angenrheidiol ar gyfer ein tasg: cydbwyso ar sawl lefel OSI, rhyngwyneb rheoli, hyblygrwydd a scalability, nifer fawr o ddulliau cydbwyso, cefnogaeth ar gyfer tablau sesiwn.
Y broblem gyntaf yr oedd angen ei datrys oedd goddefgarwch bai'r cydbwyseddwr ei hun. Mae gosod cydbwysedd hefyd yn creu pwynt o fethiant: mae'r cydbwysedd yn torri ac mae'r gwasanaeth yn chwalu. Er mwyn atal hyn rhag digwydd, gwnaethom ddefnyddio HAProxy ar y cyd ag ExaBGP.
Mae ExaBGP yn caniatáu ichi roi mecanwaith ar waith ar gyfer gwirio cyflwr gwasanaeth. Defnyddiwyd y mecanwaith hwn i wirio ymarferoldeb HAProxy ac, rhag ofn y byddai problemau, analluogi'r gwasanaeth HAProxy gan BGP.
Cynllun ExaBGP+HAProxy
- Rydym yn gosod y meddalwedd angenrheidiol, ExaBGP a HAProxy, ar dri gweinydd.
- Rydym yn creu rhyngwyneb loopback ar bob gweinydd.
- Ar bob un o'r tri gweinydd rydym yn aseinio'r un cyfeiriad IP gwyn i'r rhyngwyneb hwn.
- Mae cyfeiriad IP gwyn yn cael ei hysbysebu i'r Rhyngrwyd trwy ExaBGP.
Cyflawnir goddefgarwch nam trwy hysbysebu'r un cyfeiriad IP gan bob un o'r tri gweinydd. O safbwynt rhwydwaith, mae'r un cyfeiriad yn hygyrch o dri hopys nesaf gwahanol. Mae'r llwybrydd yn gweld tri llwybr union yr un fath, yn dewis y flaenoriaeth uchaf ohonynt yn seiliedig ar ei fetrig ei hun (yr un opsiwn yw hwn fel arfer), ac mae'r traffig yn mynd i un o'r gweinyddwyr yn unig.
Mewn achos o broblemau gyda gweithrediad HAProxy neu fethiant gweinydd, mae ExaBGP yn stopio cyhoeddi'r llwybr, ac mae'r traffig yn newid yn esmwyth i weinydd arall.
Felly, rydym yn cyflawni goddefgarwch bai y balancer.
Goddefgarwch nam o gydbwyswyr HAProxy
Trodd y cynllun yn amherffaith: dysgon ni sut i gadw HAProxy, ond ni ddysgon ni sut i ddosbarthu'r llwyth o fewn y gwasanaethau. Felly, fe wnaethom ehangu'r cynllun hwn ychydig: symudom ymlaen i gydbwyso sawl cyfeiriad IP gwyn.
Cydbwyso yn seiliedig ar DNS ynghyd â BGP
Mae mater cydbwyso llwyth ar gyfer ein HAProxy yn dal heb ei ddatrys. Fodd bynnag, gellir ei ddatrys yn eithaf syml, fel y gwnaethom yma.
I gydbwyso tri gweinydd bydd angen 3 chyfeiriad IP gwyn arnoch a hen DNS da. Mae pob un o'r cyfeiriadau hyn yn cael ei bennu ar ryngwyneb loopback pob HAProxy a'i hysbysebu i'r Rhyngrwyd.
Yn OpenStack, i reoli adnoddau, defnyddir cyfeiriadur gwasanaeth, sy'n nodi API endpoint gwasanaeth penodol. Yn y cyfeiriadur hwn rydym yn cofrestru enw parth - public.infra.mail.ru, sy'n cael ei ddatrys trwy DNS gan dri chyfeiriad IP gwahanol. O ganlyniad, rydym yn cael dosbarthiad llwyth rhwng tri chyfeiriad trwy DNS.
Ond oherwydd wrth gyhoeddi cyfeiriadau IP gwyn nid ydym yn rheoli blaenoriaethau dewis gweinyddwyr, nid yw hyn yn cydbwyso eto. Yn nodweddiadol, dim ond un gweinydd fydd yn cael ei ddewis yn seiliedig ar hynafedd cyfeiriad IP, a bydd y ddau arall yn segur oherwydd nad oes unrhyw fetrigau wedi'u nodi yn BGP.
Dechreuon ni anfon llwybrau trwy ExaBGP gyda gwahanol fetrigau. Mae pob balancer yn hysbysebu pob un o'r tri chyfeiriad IP gwyn, ond mae un ohonynt, y prif un ar gyfer y cydbwysedd hwn, yn cael ei hysbysebu gyda'r isafswm metrig. Felly, tra bod y tri mantolenydd ar waith, mae galwadau i'r cyfeiriad IP cyntaf yn mynd i'r cydbwysedd cyntaf, galwadau i'r ail i'r ail, a galwadau i'r trydydd i'r trydydd.
Beth sy'n digwydd pan fydd un o'r balanswyr yn cwympo? Os bydd unrhyw fantolwr yn methu, mae ei brif gyfeiriad yn dal i gael ei hysbysebu o'r ddau arall, ac mae traffig yn cael ei ailddosbarthu rhyngddynt. Felly, rydyn ni'n rhoi sawl cyfeiriad IP i'r defnyddiwr ar unwaith trwy DNS. Trwy gydbwyso yn ôl DNS a gwahanol fetrigau, rydyn ni'n cael dosbarthiad cyfartal o'r llwyth ar y tri balans. Ac ar yr un pryd nid ydym yn colli goddefgarwch bai.
Cydbwyso HAProxy yn seiliedig ar DNS + BGP
Rhyngweithio rhwng ExaBGP a HAProxy
Felly, fe wnaethom weithredu goddefgarwch bai rhag ofn i'r gweinydd adael, yn seiliedig ar atal cyhoeddi llwybrau. Ond gall HAProxy gau i lawr am resymau eraill na methiant gweinydd: gwallau gweinyddol, methiannau o fewn y gwasanaeth. Rydym am gael gwared ar y balans sydd wedi torri o dan y llwyth yn yr achosion hyn hefyd, ac mae angen mecanwaith gwahanol arnom.
Felly, gan ehangu'r cynllun blaenorol, gwnaethom weithredu curiad calon rhwng ExaBGP a HAProxy. Mae hwn yn weithrediad meddalwedd o'r rhyngweithio rhwng ExaBGP a HAProxy, pan fydd ExaBGP yn defnyddio sgriptiau wedi'u teilwra i wirio statws cymwysiadau.
I wneud hyn, mae angen i chi ffurfweddu gwiriwr iechyd yn y ffurfwedd ExaBGP, a all wirio statws HAProxy. Yn ein hachos ni, fe wnaethom ffurfweddu'r backend iechyd yn HAProxy, ac o ochr ExaBGP rydym yn gwirio gyda chais GET syml. Os bydd y cyhoeddiad yn peidio â digwydd, mae'n debygol na fydd HAProxy yn gweithio ac nid oes angen ei hysbysebu.
Gwiriad Iechyd HAProxy
Cyfoedion HAProxy: cydamseru sesiwn
Y peth nesaf i'w wneud oedd cydamseru'r sesiynau. Wrth weithio trwy gydbwyswyr dosbarthedig, mae'n anodd trefnu storio gwybodaeth am sesiynau cleientiaid. Ond HAProxy yw un o'r ychydig gydbwyswyr a all wneud hyn oherwydd ymarferoldeb Peers - y gallu i drosglwyddo tablau sesiwn rhwng gwahanol brosesau HAProxy.
Mae yna wahanol ddulliau cydbwyso: rhai syml fel , ac yn estynedig, pan fydd sesiwn y cleient yn cael ei gofio, a phob tro mae'n dod i ben ar yr un gweinydd ag o'r blaen. Roeddem am roi’r ail opsiwn ar waith.
Mae HAProxy yn defnyddio byrddau ffyn i arbed sesiynau cleient o'r mecanwaith hwn. Maent yn arbed cyfeiriad IP gwreiddiol y cleient, y cyfeiriad targed a ddewiswyd (ôl-ddydd) a rhywfaint o wybodaeth am y gwasanaeth. Yn nodweddiadol, defnyddir tablau ffon i storio pâr ffynhonnell-IP + cyrchfan-IP, sy'n arbennig o ddefnyddiol ar gyfer cymwysiadau na allant drosglwyddo cyd-destun sesiwn defnyddiwr wrth newid i balancer arall, er enghraifft, yn y modd cydbwyso RoundRobin.
Os dysgir bwrdd ffon i symud rhwng gwahanol brosesau HAProxy (rhwng pa gydbwyso sy'n digwydd), bydd ein balanswyr yn gallu gweithio gydag un gronfa o fyrddau ffon. Bydd hyn yn ei gwneud hi'n bosibl newid rhwydwaith y cleient yn ddi-dor os bydd un o'r balanswyr yn methu; bydd gwaith gyda sesiynau cleient yn parhau ar yr un backends a ddewiswyd yn gynharach.
Er mwyn gweithredu'n iawn, rhaid datrys problem cyfeiriad IP ffynhonnell y balanswr y sefydlwyd y sesiwn ohono. Yn ein hachos ni, mae hwn yn gyfeiriad deinamig ar y rhyngwyneb loopback.
Dim ond o dan amodau penodol y cyflawnir gwaith cywir cyfoedion. Hynny yw, rhaid i amserau atal TCP fod yn ddigon mawr neu mae'n rhaid i'r newid fod yn ddigon cyflym fel nad oes amser i'r sesiwn TCP ddod i ben. Fodd bynnag, mae'n caniatáu ar gyfer newid di-dor.
Yn IaaS mae gennym ni wasanaeth wedi'i adeiladu gan ddefnyddio'r un dechnoleg. hwn , a elwir Octavia. Mae'n seiliedig ar ddwy broses HAProxy ac i ddechrau mae'n cynnwys cefnogaeth i gymheiriaid. Maent wedi profi eu hunain yn rhagorol yn y gwasanaeth hwn.
Mae'r llun yn dangos yn sgematig symudiad tablau cyfoedion rhwng tri achos HAProxy, cynigir ffurfweddiad ar sut y gellir ei ffurfweddu:
HAProxy Peers (cydamseru sesiwn)
Os byddwch yn gweithredu'r un cynllun, rhaid profi ei weithrediad yn ofalus. Nid yw'n ffaith y bydd yn gweithio yn yr un ffordd 100% o'r amser. Ond o leiaf ni fyddwch yn colli tablau ffon pan fydd angen i chi gofio IP ffynhonnell y cleient.
Cyfyngu ar nifer y ceisiadau cydamserol gan yr un cleient
Gall unrhyw wasanaethau sydd ar gael i'r cyhoedd, gan gynnwys ein APIs, fod yn destun llu o geisiadau. Gall y rhesymau drostynt fod yn hollol wahanol, o gamgymeriadau defnyddwyr i ymosodiadau wedi'u targedu. Rydym yn cael ein DDoSed o bryd i'w gilydd gan gyfeiriadau IP. Mae cleientiaid yn aml yn gwneud camgymeriadau yn eu sgriptiau ac yn rhoi mini-DDoSs i ni.
Un ffordd neu'r llall, rhaid darparu amddiffyniad ychwanegol. Yr ateb amlwg yw cyfyngu ar nifer y ceisiadau API a pheidio â gwastraffu amser CPU yn prosesu ceisiadau maleisus.
Er mwyn gweithredu cyfyngiadau o'r fath, rydym yn defnyddio terfynau cyfradd, wedi'u trefnu ar sail HAProxy, gan ddefnyddio'r un tablau ffon. Mae sefydlu terfynau yn eithaf syml ac yn caniatáu ichi gyfyngu ar y defnyddiwr yn ôl nifer y ceisiadau i'r API. Mae'r algorithm yn cofio'r IP ffynhonnell y gwneir ceisiadau ohono ac yn cyfyngu ar nifer y ceisiadau cydamserol gan un defnyddiwr. Wrth gwrs, fe wnaethom gyfrifo'r proffil llwyth API cyfartalog ar gyfer pob gwasanaeth a gosod terfyn o ≈ 10 gwaith y gwerth hwn. Rydym yn parhau i fonitro'r sefyllfa'n agos ac yn cadw ein bys ar y curiad.
Sut olwg sydd ar hyn yn ymarferol? Mae gennym gwsmeriaid sy'n defnyddio ein APIs graddio awtomatig drwy'r amser. Maent yn creu tua dau i dri chant o beiriannau rhithwir yn y bore ac yn eu dileu gyda'r nos. Ar gyfer OpenStack, mae creu peiriant rhithwir, hefyd gyda gwasanaethau PaaS, yn gofyn am o leiaf 1000 o geisiadau API, gan fod rhyngweithio rhwng gwasanaethau hefyd yn digwydd trwy'r API.
Mae trosglwyddo tasgau o'r fath yn achosi llwyth eithaf mawr. Fe wnaethon ni asesu'r llwyth hwn, casglu uchafbwyntiau dyddiol, eu cynyddu ddeg gwaith, a dyma oedd ein terfyn cyfradd. Rydym yn cadw ein bys ar y pwls. Rydym yn aml yn gweld bots a sganwyr sy'n ceisio edrych arnom i weld a oes gennym unrhyw sgriptiau CGA y gellir eu rhedeg, rydym yn eu torri'n weithredol.
Sut i ddiweddaru'ch cod sylfaen heb i ddefnyddwyr sylwi
Rydym hefyd yn gweithredu goddefgarwch namau ar lefel prosesau defnyddio cod. Efallai y bydd gwendidau yn ystod y broses gyflwyno, ond gellir lleihau eu heffaith ar argaeledd gwasanaethau.
Rydym yn diweddaru ein gwasanaethau yn gyson ac mae'n rhaid i ni sicrhau bod y cod sylfaen yn cael ei ddiweddaru heb effeithio ar ddefnyddwyr. Llwyddom i ddatrys y broblem hon gan ddefnyddio galluoedd rheoli HAProxy a gweithredu Graceful Shutdown yn ein gwasanaethau.
I ddatrys y broblem hon, roedd angen sicrhau rheolaeth ar y cydbwyseddwr a chau gwasanaethau yn “gywir”:
- Yn achos HAProxy, perfformir rheolaeth trwy ffeil stats, sydd yn ei hanfod yn soced ac fe'i diffinnir yn y ffurfwedd HAProxy. Gallwch anfon gorchmynion ato trwy stdio. Ond mae ein prif offeryn rheoli cyfluniad yn ansible, felly mae ganddo fodiwl adeiledig ar gyfer rheoli HAProxy. Yr hyn rydyn ni'n ei ddefnyddio'n weithredol.
- Mae'r rhan fwyaf o'n gwasanaethau API a Engine yn cefnogi technolegau cau gosgeiddig: wrth gau, maen nhw'n aros i'r dasg gyfredol gael ei chwblhau, boed yn gais http neu'n dasg gwasanaeth. Mae'r un peth yn digwydd gyda'r gweithiwr. Mae'n gwybod yr holl dasgau y mae'n eu gwneud ac yn dod i ben pan fydd wedi cwblhau popeth yn llwyddiannus.
Diolch i'r ddau bwynt hyn, mae'r algorithm diogel ar gyfer ein defnyddio yn edrych fel hyn.
- Mae'r datblygwr yn cydosod pecyn newydd o god (i ni dyma RPM), yn ei brofi yn yr amgylchedd dev, yn ei brofi yn y llwyfan, ac yn ei adael yn y storfa lwyfan.
- Mae'r datblygwr yn gosod y dasg ar gyfer defnyddio gyda'r disgrifiad mwyaf manwl o'r “arteffactau”: y fersiwn o'r pecyn newydd, disgrifiad o'r swyddogaeth newydd a manylion eraill am y defnydd os oes angen.
- Mae gweinyddwr y system yn dechrau'r diweddariad. Yn lansio'r llyfr chwarae Ansible, sydd yn ei dro yn gwneud y canlynol:
- Yn cymryd pecyn o'r ystorfa lwyfan ac yn ei ddefnyddio i ddiweddaru'r fersiwn o'r pecyn yn y storfa cynnyrch.
- Yn llunio rhestr o ôl-lenni'r gwasanaeth wedi'i ddiweddaru.
- Yn cau'r gwasanaeth cyntaf i gael ei ddiweddaru yn HAProxy ac yn aros i'w brosesau orffen rhedeg. Diolch i gau lawr gosgeiddig, rydym yn hyderus y bydd yr holl geisiadau cleient presennol yn cael eu cwblhau'n llwyddiannus.
- Ar ôl i'r API a'r gweithwyr gael eu stopio'n llwyr, a HAProxy wedi'i ddiffodd, mae'r cod yn cael ei ddiweddaru.
- Mae Anible yn rhedeg gwasanaethau.
- Ar gyfer pob gwasanaeth, mae rhai “dolenni” yn cael eu tynnu, sy'n cynnal profion uned ar nifer o brofion allweddol a ddiffiniwyd ymlaen llaw. Mae gwiriad sylfaenol o'r cod newydd yn digwydd.
- Os na chanfuwyd unrhyw wallau yn y cam blaenorol, mae'r ôl-wyneb yn cael ei actifadu.
- Gadewch i ni symud ymlaen i'r backend nesaf.
- Ar ôl i'r holl gefnlenni gael eu diweddaru, mae profion swyddogaethol yn cael eu lansio. Os ydynt ar goll, yna mae'r datblygwr yn edrych ar unrhyw swyddogaeth newydd a greodd.
Mae hyn yn cwblhau'r defnydd.
Cylch diweddaru gwasanaeth
Ni fyddai'r cynllun hwn yn gweithio pe na bai gennym un rheol. Rydym yn cefnogi'r fersiynau hen a newydd mewn brwydr. O flaen llaw, ar y cam datblygu meddalwedd, nodir, hyd yn oed os oes newidiadau yn y gronfa ddata gwasanaeth, ni fyddant yn torri'r cod blaenorol. O ganlyniad, mae sylfaen y cod yn cael ei diweddaru'n raddol.
Casgliad
Gan rannu fy meddyliau fy hun am bensaernïaeth WEB sy'n goddef diffygion, hoffwn nodi ei phrif bwyntiau unwaith eto:
- goddefgarwch nam corfforol;
- goddefgarwch nam rhwydwaith (cydbwyswyr, BGP);
- goddefgarwch nam ar y meddalwedd a ddefnyddir ac a ddatblygwyd.
Sefydlog uptime pawb!
Ffynhonnell: hab.com
