Silav Habr! Ez Artem Karamyshev im, serokê tîma rêveberiya pergalê . Di sala borî de me gelek hilberên nû dan destpêkirin. Me xwest ku em pê ewle bin ku karûbarên API-ê bi hêsanî berbelav, xelet-tolerant û ji bo mezinbûna bilez a barkirina bikarhêner amade ne. Platforma me li ser OpenStack-ê tête bicîh kirin, û ez dixwazim ji we re bibêjim ka kîjan pirsgirêkên tolerasyona xeletiya pêkhateyê divê em çareser bikin da ku em pergalek toleransê xelet bistînin. Ez difikirim ku ev ê ji bo kesên ku di heman demê de hilberên li ser OpenStack-ê jî pêşdixin balkêş be.
Tolerasyona xeletiya giştî ya platformek ji reseniya pêkhateyên wê pêk tê. Ji ber vê yekê em ê gav bi gav li hemî astên ku me xetere nas kir û wan girt derbas bibin.
Guhertoya vîdyoyê ya vê çîrokê, çavkaniya bingehîn a ku di konferansa roja 4-ê ya Uptime de, ku ji hêla ve hatî organîze kirin, raporek bû , hûn dikarin bibînin .
Berxwedana mîmariya fîzîkî
Parçeya giştî ya ewrê MCS naha li du navendên daneyê yên Tier III-ê ye, di navbera wan de fîbera xweya tarî heye, ku di asta laşî de ji hêla riyên cihêreng ve hatî veqetandin, bi rêgezek 200 Gbit / s. Asta III ji bo binesaziya laşî asta pêwîst a tolerasyona xeletiyê peyda dike.
Fibera tarî hem di astên laşî û hem jî di asta mentiqî de parastî ye. Pêvajoya veqetandina kanalê dubare bû, pirsgirêk derketin, û em bi berdewamî pêwendiya di navbera navendên daneyê de baştir dikin.
Mînakî, ne demek berê, dema ku li bîrek li nêzî yek ji navendên daneyê dixebitî, kolberek boriyek şikand, û di hundurê vê boriyê de hem kabloyek optîkî ya sereke û hem jî kabloyek piştgir hebû. Kanala meya pêwendiya xelet-tehemûl a bi navenda daneyê re di yek xalê de, di bîrê de, xeternak derket. Li gorî vê yekê me beşek ji binesaziyê winda kir. Me encam derxist û gelek çalakî pêk anîn, di nav de sazkirina optîkên din li bîrê cîran.
Di navendên daneyê de nuqteyên hebûna pêşkêşkerên ragihandinê hene ku em pêşpirtikên xwe bi BGP-ê diweşînin. Ji bo her rêgezek torê, metrîka çêtirîn tête hilbijartin, ku dihêle xerîdarên cûda bi kalîteya pêwendiya çêtirîn peyda bibin. Ger danûstendina bi yek pêşkêşker re têk diçe, em rêça xwe bi navgîniya peydakiroxan ji nû ve ava dikin.
Ger pêşkêşvanek têk nebe, em bixweber diguhezin ya din. Di bûyera têkçûna yek ji navendên daneyê de, me kopiyek neynikê ya karûbarên me di navenda daneya duyemîn de heye, ku tevahiya barkirinê digire ser xwe.
Berxwedana binesaziya fîzîkî
Ya ku em ji bo tolerasyona xeletiya asta serîlêdanê bikar tînin
Karûbarê me li ser gelek hêmanên çavkaniya vekirî hatî çêkirin.
ExaBGP karûbarek e ku bi karanîna protokola rêveçûna dînamîkî ya bingeh-BGP çend fonksiyonan pêk tîne. Em bi çalak wê bikar tînin da ku navnîşanên IP-ya xweya spî ya ku bi navgîniya bikarhêner bigihîjin API-ê reklam bikin.
HAProxy balansek bargiranek bilind e ku dihêle hûn di astên cihêreng ên modela OSI de qaîdeyên hevsengiya seyrûsefera pir maqûl mîheng bikin. Em wê bikar tînin da ku li ber hemî karûbaran hevseng bikin: databases, brokerên peyamê, karûbarên API, karûbarên malperê, projeyên meyên hundurîn - her tişt li pişt HAProxy ye.
serîlêdana API - serîlêdanek malperê ku bi python hatî nivîsandin, ku bikarhêner binesaziya xwe û karûbarê xwe bi rê ve dibe.
Serlêdana karker (li vir bi tenê karker) - di karûbarên OpenStack de, ev damemonek binesaziyê ye ku dihêle hûn fermanên API-ê li binesaziyê biweşînin. Mînakî, afirandina dîskê di karker de pêk tê, û daxwaza afirandinê di serîlêdana API-ê de pêk tê.
Mîmariya Serlêdana OpenStack Standard
Piraniya karûbarên ku ji bo OpenStack têne pêşve xistin hewl didin ku paradîgmayek yekane bişopînin. Karûbarek bi gelemperî ji 2 beşan pêk tê: API û xebatkar (xebatkarên paşîn). Wekî qaîdeyek, API serîlêdanek WSGI di python de ye, ku an wekî pêvajoyek serbixwe (daemon), an jî bi karanîna serverek Nginx an Apache-ya amadekirî tê destpêkirin. API daxwaznameya bikarhêner pêvajo dike û ji bo darvekirinê rêwerzên din ji serîlêdana karker re derbas dike. Veguheztin bi karanîna brokerek peyamê pêk tê, bi gelemperî RabbitMQ, yên din kêm têne piştgirî kirin. Dema ku peyam digihîjin brokerê, ew ji hêla karkeran ve têne pêvajoyê kirin û, ger hewce be, bersivek vedigerin.
Ev paradîgma xalên hevbeş ên têkçûn ên veqetandî vedihewîne: RabbitMQ û databas. Lê RabbitMQ di yek karûbar de veqetandî ye û, di teoriyê de, dikare ji bo her karûbarek kesane be. Ji ber vê yekê li MCS em van karûbaran bi qasî ku pêkan ji hev vediqetînin; ji bo her projeyek kesane em databasek cihê, RabbitMQyek cihê diafirînin. Ev nêzîkatî baş e ji ber ku di bûyerek qezayek li hin xalên xizan de, ne tevahî karûbar têk diçe, lê tenê beşek wê têk diçe.
Hejmara serîlêdanên karker bêsînor e, ji ber vê yekê API dikare bi hêsanî li pişt hevsengkeran bi rengek horizontî mezin bike da ku performans û tolerasyona xeletiyê zêde bike.
Hin karûbar hewceyê koordînasyona di hundurê karûbarê de ne dema ku operasyonên rêzdar ên tevlihev di navbera API û karkeran de çêdibin. Di vê rewşê de, navendek hevrêziyek yekane tê bikar anîn, pergalek komê ya wekî Redis, Memcache, etcd, ku dihêle yek xebatkarek ji yê din re bêje ku ev peywir ji wî re hatiye peywirdarkirin ("ji kerema xwe wê negire"). Em etcd bikar tînin. Wekî qaîdeyek, karker bi rengek çalak bi databasê re têkilî daynin, ji wir agahdarî dinivîsin û dixwînin. Em mariadb wekî databasek bikar tînin, ku di komek multimaster de cih digire.
Ev karûbarê yekane ya klasîk bi rengek ku bi gelemperî ji bo OpenStack-ê hatî pejirandin tête organîze kirin. Ew dikare wekî pergalek girtî were hesibandin, ku ji bo wê rêbazên pîvandinê û tolerasyona xeletiyê pir eşkere ne. Mînakî, ji bo tolerasyona xeletiya API-ê, bes e ku meriv balansek li pêş wan deyne. Karkerên pîvandinê bi zêdebûna hejmara wan pêk tê.
Xala qels a di tevahiyê de RabbitMQ û MariaDB ye. Mîmariya wan gotarek cuda heq dike Di vê gotarê de ez dixwazim li ser tolerasyona xeletiya API-ê bisekinim.
Mîmariya Serlêdana Openstack. Hevsengî û tolerasyona xeletiya platforma ewr
Bi karanîna ExaBGP-ê çêkirina HAProxy-balansek xelet-tolerant
Ji bo ku API-yên xwe berbelav, bilez û toleransê bikin, em balansek bargiraniyê didin pêşiya wan. Me HAProxy hilbijart. Bi dîtina min, ew hemî taybetmendiyên pêwîst ji bo peywira me heye: hevsengkirina di çend astên OSI de, navgînek rêveberiyê, nermbûn û pîvandin, hejmareke mezin ji rêbazên hevsengiyê, piştgirî ji bo tabloyên danişînê.
Pirsgirêka yekem ku hewce bû ku were çareser kirin, tolerasyona xeletiya balanserê bixwe bû. Bi tenê sazkirina balansek di heman demê de xalek têkçûnê jî diafirîne: balansek dişkê û karûbar têk diçe. Ji bo pêşîgirtina vê yekê, me HAProxy bi ExaBGP re bi kar anî.
ExaBGP dihêle hûn mekanîzmayek ji bo kontrolkirina rewşa karûbarek bicîh bikin. Me vê mekanîzmayê bikar anî da ku fonksiyona HAProxy kontrol bike û, heke pirsgirêk hebe, karûbarê HAProxy ji BGP-ê neçalak bike.
Plana ExaBGP + HAProxy
- Em nermalava pêwîst, ExaBGP û HAProxy, li ser sê serveran saz dikin.
- Em li ser her serverek navberek loopback diafirînin.
- Li ser her sê pêşkêşkeran em heman navnîşana IP-ya spî ji vê navberê re destnîşan dikin.
- Navnîşanek IP-ya spî bi navgîniya ExaBGP ve ji Înternetê re tê reklam kirin.
Tolerasyona xeletiyê bi reklamkirina heman navnîşana IP-yê ji her sê serveran ve tête bidestxistin. Ji nêrînek torê ve, heman navnîşan ji sê hopên din ên cihêreng tê gihîştin. Router sê rêgezên yeksan dibîne, pêşaniya herî bilind ji wan li ser bingeha metrika xwe hildibijêre (ev bi gelemperî heman vebijark e), û seyrûsefer tenê diçe yek ji pêşkêşkeran.
Di rewşên pirsgirêkên bi xebitandina HAProxy an têkçûnek serverê de, ExaBGP ragihandina rêgezê radiweste, û seyrûsefer bi rêkûpêk veguherîne serverek din.
Bi vî rengî, me gihîştina tolerasyona xeletiya balanserê.
Tolerasyona xeletiya balanserên HAProxy
Pîlana bêkêmasî derket: em fêr bûn ka meriv çawa HAProxy-ê rezerv dike, lê fêr nebû ka meriv çawa barkirinê di nav karûbaran de belav dike. Ji ber vê yekê, me vê nexşeyê hinekî berfireh kir: me berbi hevsengkirina di navbera çend navnîşanên IP-ya spî de çû.
Balansek li ser bingeha DNS plus BGP
Pirsgirêka hevsengkirina barkirinê ji bo HAProxy-ya me bêçareser dimîne. Lêbelê, ew dikare bi hêsanî çareser bibe, wekî ku me li vir kir.
Ji bo balansa sê serveran hûn ê hewceyê 3 navnîşanên IP-ya spî û DNS-ya kevn a baş bin. Her yek ji van navnîşan li ser navbeynkariya loopback ya her HAProxy-ê tê destnîşankirin û ji Înternetê re tê reklam kirin.
Di OpenStack de, ji bo birêvebirina çavkaniyan, pelrêçek karûbar tê bikar anîn, ku API-ya dawî ya karûbarek taybetî diyar dike. Di vê pelrêçê de em navek domainê tomar dikin - public.infra.mail.ru, ku bi navgîniya DNS-ê ji hêla sê navnîşanên IP-ê yên cûda ve tê çareser kirin. Wekî encamek, em bi riya DNS-ê di navbera sê navnîşan de dabeşkirina barkirinê digirin.
Lê ji ber ku dema ragihandina navnîşanên IP-ya spî em pêşengên hilbijartina serverê kontrol nakin, ev hîna hevseng nebûye. Bi gelemperî, tenê serverek dê li ser bingeha pîrbûna navnîşana IP-yê were hilbijartin, û duyên din dê bêkar bin ji ber ku di BGP-ê de metrîk nayên destnîşan kirin.
Me bi metrîkên cihêreng bi rêya ExaBGP dest bi şandina rêwiyan kir. Her hevseng her sê navnîşanên IP-ya spî reklam dike, lê yek ji wan, ya sereke ji bo vê balanserê, bi metrika herî kêm tê reklam kirin. Ji ber vê yekê dema ku her sê hevseng di xebatê de ne, bangên navnîşana IP-ya yekem diçin balansa yekem, ji ya duyemîn re bang li ya duyemîn, û bang li ya sêyem ji ya sêyemîn re dikin.
Dema ku yek ji hevsengiyan dikeve, çi dibe? Ger balansek têk bibe, navnîşana wê ya sereke hîn jî ji her duyên din tê reklam kirin, û seyrûsefer di navbera wan de ji nû ve tê dabeş kirin. Bi vî rengî, em bi DNS-ê bi yekcarî çend navnîşanên IP-yê didin bikarhêner. Bi hevsengkirina ji hêla DNS û metrîkên cihêreng, em li ser her sê hevsengkeran dabeşek hevûdu ya barkirinê distînin. Û di heman demê de em tolerasyona xeletiyê winda nakin.
Balansek HAProxy li ser bingeha DNS + BGP
Têkiliya di navbera ExaBGP û HAProxy de
Ji ber vê yekê, me li ser bingeha rawestandina ragihandina rêgezan di ger server derkeve de tolerasyona xeletiyê bicîh kir. Lê HAProxy ji bilî têkçûna serverê ji ber sedemên din dikare were girtin: xeletiyên rêveberiyê, têkçûnên di nav karûbarê de. Em dixwazin di van rewşan de jî balansa şikestî ji bin barkirinê derxînin û pêdivî bi mekanîzmayek cûda heye.
Ji ber vê yekê, berbelavkirina pilana berê, me lêdana dil di navbera ExaBGP û HAProxy de bicîh kir. Ev pêkanînek nermalavê ya danûstendina di navbera ExaBGP û HAProxy de ye, dema ku ExaBGP skrîptên xwerû bikar tîne da ku rewşa serlêdanan kontrol bike.
Ji bo kirina vê yekê, hûn hewce ne ku di mîhengê ExaBGP de kontrolkerek tenduristiyê mîheng bikin, ku dikare statûya HAProxy kontrol bike. Di doza me de, me pişta tenduristiyê di HAProxy de mîheng kir, û ji hêla ExaBGP ve em bi daxwazek GET-ê ya hêsan kontrol dikin. Ger ragihandin raweste, wê hingê HAProxy bi îhtimaleke mezin nexebite û ne hewce ye ku wê reklam bike.
Kontrola Tenduristiya HAProxy
HAProxy Peers: hevdemkirina danişînê
Tiştê din ku were kirin senkronîzekirina danişînan bû. Dema ku bi balanserên belavkirî re dixebitin, dijwar e ku meriv hilanîna agahdariya di derbarê danişînên xerîdar de organîze bike. Lê HAProxy yek ji kêm hevsengkeran e ku dikare vê yekê ji ber fonksiyona Peers bike - şiyana veguheztina tabloyên danişînê di navbera pêvajoyên cihêreng ên HAProxy de.
Rêbazên hevsengiyê yên cihêreng hene: yên hêsan ên wekî , û dirêj kirin, dema ku danişîna xerîdar tê bîra wî, û her carê ew li ser heman serverê wekî berê diqede. Me xwest bijardeya duyemîn pêk bînin.
HAProxy tabloyên çîp bikar tîne da ku danişînên xerîdar ên vê mekanîzmayê hilîne. Ew navnîşana IP-ya orîjînal a xerîdar, navnîşana mebesta hilbijartî (paşgir) û hin agahdariya karûbarê tomar dikin. Bi gelemperî, tabloyên çîp ji bo hilanîna cotek çavkanî-IP + mebest-IP-ê têne bikar anîn, ku bi taybetî ji bo serîlêdanên ku nikaribin çarçoweya danişîna bikarhêner veguhezînin dema ku diçin balansek din, mînakî, di moda hevsengkirina RoundRobin de, bikêrhatî ye.
Ger tabloyek darikê were fêr kirin ku di navbera pêvajoyên HAProxy yên cihêreng de bimeşe (di navbera kîjan hevsengiyê de çêdibe), hevsengên me dê karibin bi yek hewzek tabloyên darikê re bixebitin. Ev ê gengaz bike ku ger yek ji hevsengkeran têk biçe, tora xerîdar bi rengek bêkêmasî biguhezîne; xebata bi danişînên xerîdar re dê li ser heman paşînên ku berê hatine hilbijartin bidome.
Ji bo xebitandina rast, divê pirsgirêka navnîşana IP-ya çavkaniyê ya balanserê ku danişîn jê hatî damezrandin were çareser kirin. Di rewşa me de, ev navnîşek dînamîkî ye ku li ser pêwendiya loopback-ê ye.
Xebata rast a hevalan tenê di hin mercan de tê bidestxistin. Ango, wextên TCP-ê divê têra xwe mezin bin an jî divê veguheztin bi têra xwe bilez be da ku danişîna TCP-ê wextê bidawîbûnê nebe. Lêbelê, ew destûrê dide guheztina bêkêmasî.
Di IaaS de karûbarek me heye ku bi karanîna heman teknolojiyê hatî çêkirin. Ev , ku jê re Octavia tê gotin. Ew li ser du pêvajoyên HAProxy-ê ye û di destpêkê de piştgirî ji hevalbendan re vedigire. Wan di vê xizmetê de xwe baş îspat kiriye.
Wêne bi rengek şematîkî tevgera tabloyên peer di navbera sê mînakên HAProxy de destnîşan dike, konfigurasyonek li ser meriv çawa dikare were mîheng kirin tê pêşniyar kirin:
HAProxy Peers (hevdemkirina danişînê)
Ger hûn heman plansaziyê bicîh bînin, divê operasyona wê bi baldarî were ceribandin. Ne rastiyek e ku ew ê 100% ji demê bi heman rengî bixebite. Lê bi kêmanî hûn ê tabloyên darikê winda nekin dema ku hûn hewce ne ku IP-ya çavkaniya xerîdar bi bîr bînin.
Bi sînorkirina hejmara daxwazên hevdemî ji heman xerîdar
Her karûbarên ku bi gelemperî berdest in, tevî API-yên me jî, dikarin bibin mijara daxwazên alan. Sedemên wan dikarin bi tevahî cûda bin, ji xeletiyên bikarhêner bigire heya êrîşên armanckirî. Em bi periyodîk ji hêla navnîşanên IP-ê ve têne DDoSed kirin. Xerîdar bi gelemperî di nivîsarên xwe de xeletiyan dikin û mini-DDoS-an didin me.
Bi awayekî din, divê parastina zêde were dayîn. Çareseriya eşkere ev e ku meriv hejmara daxwazên API-ê sînordar bike û dema CPU-yê ji bo pêvajoyên daxwazên xerab winda neke.
Ji bo bicihanîna qedexeyên weha, em sînorên rêjeyê bikar tînin, ku li ser bingeha HAProxy hatî organîze kirin, bi karanîna heman tabloyên çîpek bikar tînin. Sazkirina sînoran pir hêsan e û dihêle hûn bikarhêner bi hejmara daxwazên API-yê sînordar bikin. Algorîtma IP-ya çavkaniyê ya ku daxwaz jê têne kirin bi bîr tîne û hejmara daxwazên hevdem ên ji bikarhênerek sînordar dike. Bê guman, me ji bo her karûbarek profîla barkirina API-ya navîn hesab kir û ji vê nirxê ≈ 10 carî sînorek danî. Em ji nêz ve şopandina rewşê didomînin û tiliya xwe li ser piyan digirin.
Ev di pratîkê de çawa xuya dike? Xerîdarên me hene ku her dem API-yên meya xweseriya xwe bikar tînin. Ew serê sibê bi qasî du-sê sed makîneyên virtual diafirînin û êvarê wan jêbirin. Ji bo OpenStack, afirandina makîneyek virtual, di heman demê de bi karûbarên PaaS re, bi kêmî ve 1000 daxwazên API-yê hewce dike, ji ber ku têkiliya di navbera karûbaran de jî bi navgîniya API-ê pêk tê.
Veguheztina bi vî rengî ya peywiran dibe sedema barek pir mezin. Me ev bar nirxand, lûtkeyên rojane berhev kirin, deh qat zêde kirin û ev bû sînorê rêjeya me. Em tiliya xwe li ser nebzê digirin. Em bi gelemperî bot û skaneran dibînin ku hewl didin li me binerin da ku bibînin ka me nivîsên CGA hene ku dikarin werin xebitandin, em bi awayekî çalak wan qut dikin.
Meriv çawa bingeha koda xwe nûve dike bêyî ku bikarhêner hay jê bin
Di heman demê de em di asta pêvajoyên bicihkirina kodê de tolerasyona xeletiyê jî bicîh dikin. Dibe ku di dema serîlêdanê de xeletî hebin, lê bandora wan li ser hebûna karûbarê dikare kêm bibe.
Em bi domdarî karûbarên xwe nûve dikin û divê pê ewle bibin ku bingeha kodê bêyî bandorkirina bikarhêneran were nûve kirin. Me bi karanîna kapasîteyên rêveberiyê yên HAProxy û pêkanîna Graceful Shutdown di karûbarên me de ev pirsgirêk çareser kir.
Ji bo çareserkirina vê pirsgirêkê, pêdivî bû ku kontrolkirina hevseng û girtina "rast" ya karûbaran were piştrast kirin:
- Di doza HAProxy de, kontrol bi pelek stats, ku bi bingehîn soketek e û di veavakirina HAProxy de hatî destnîşan kirin, tête kirin. Hûn dikarin bi stdio re fermanan jê re bişînin. Lê amûra meya sereke ya kontrolkirina mîhengê bêserûber e, ji ber vê yekê ew modulek çêkirî ya ji bo birêvebirina HAProxy heye. Ya ku em bi çalak bikar tînin.
- Piraniya karûbarên me yên API û Engine piştgirî didin teknolojiyên girtina xweş: dema ku têne girtin, ew li bendê ne ku peywira heyî biqede, çi daxwazek http an hin karûbarê karûbarê be. Heman tişt bi karkeran re dibe. Ew hemî karên ku dike dizane û gava ku her tişt bi serfirazî qedand bi dawî dibe.
Bi saya van her du xalan, algorîtmaya ewledar a ji bo bicîhkirina me bi vî rengî xuya dike.
- Pêşvebir pakêtek nû ya kodê berhev dike (ji bo me ev RPM e), wê di hawîrdora dev de diceribîne, wê di qonaxê de diceribîne, û di depoya qonaxê de dihêle.
- Pêşvebir bi danasîna herî berfireh a "çêkeran" peywirê ji bo bicihkirinê destnîşan dike: guhertoya pakêta nû, ravekirina fonksiyona nû û hûrguliyên din ên di derbarê bicîhkirinê de heke hewce be.
- Rêvebirê pergalê nûvekirinê dest pê dike. Pirtûka lîstikê ya Ansible dest pê dike, ku di encamê de jêrîn dike:
- Pakêtek ji depoya qonaxê digire û ji bo nûvekirina guhertoya pakêtê di depoya hilberê de bikar tîne.
- Navnîşek paşnavên karûbarê nûvekirî berhev dike.
- Karûbarê yekem a ku di HAProxy-ê de were nûve kirin dadixe û li bendê ye ku pêvajoyên wê biqede. Spas ji girtina dilşewat, em pê bawer in ku hemî daxwazên xerîdar ên heyî dê bi serfirazî temam bibin.
- Piştî ku API û xebatkar bi tevahî têne rawestandin, û HAProxy hate girtin, kod tê nûve kirin.
- Ansible xizmetên dimeşîne.
- Ji bo her karûbarê, hin "destikên" têne kişandin, ku ceribandina yekîneyê li ser hejmarek ceribandinên sereke yên ji berê ve diyarkirî pêk tîne. Kontrolek bingehîn a koda nû pêk tê.
- Ger di gava berê de tu xeletî nehatin dîtin, paşnav tê çalak kirin.
- Ka em herin paşiya paşîn.
- Piştî ku hemî paşnav têne nûve kirin, ceribandinên fonksiyonel têne destpêkirin. Ger ew winda nebin, wê hingê pêşdebir li her fonksiyona nû ya ku wî afirandiye dinêre.
Bi vê yekê bicihkirinê temam dike.
çerxa nûvekirina karûbarê
Ger ku yek qaîdeyek me tunebe ev plan dê nexebite. Em di şer de hem guhertoyên kevn û hem jî yên nû piştgirî dikin. Pêşî, di qonaxa pêşkeftina nermalavê de, tê destnîşan kirin ku heke di databasa karûbarê de guhertin jî hebin, ew ê koda berê neşkînin. Wekî encamek, bingeha kodê hêdî hêdî tê nûve kirin.
encamê
Bi parvekirina ramanên xwe yên di derbarê mîmariya WEB-ê de, ez dixwazim careke din xalên wê yên sereke bibînim:
- tolerasyona xeletiya laşî;
- tolerasyona xeletiya torê (balansek, BGP);
- tolerasyona xeletiya nermalava ku hatî bikar anîn û pêşkeftî.
Hemî dema xebatê ya domdar!
Source: www.habr.com
