HighLoad++, Evgeniy Kuzovlev (EcommPay IT): kaj storiti, ko minuta izpada stane 100000 $

Vsi govorijo o procesih razvoja in testiranja, usposabljanja osebja, povečevanja motivacije, a ti procesi niso dovolj, ko minuta izpada storitve stane ogromne vsote denarja. Kaj storiti, ko izvajate finančne transakcije v skladu s strogim SLA? Kako povečati zanesljivost in odpornost na napake vaših sistemov, tako da razvoj in testiranje izločite iz enačbe?

Naslednja konferenca HighLoad++ bo 6. in 7. aprila 2020 v St. Podrobnosti in vstopnice na povezava. 9. november, 18:00. HighLoad++ Moskva 2018, Delhi + dvorana Kolkata. Teze in predstavitev.

Evgeniy Kuzovlev (v nadaljevanju – EC): - Prijatelji, pozdravljeni! Moje ime je Kuzovlev Evgeniy. Sem iz podjetja EcommPay, poseben oddelek je EcommPay IT, IT oddelek skupine podjetij. In danes bomo govorili o izpadih - o tem, kako se jim izogniti, o tem, kako zmanjšati njihove posledice, če se jim ni mogoče izogniti. Tema je navedena takole: "Kaj storiti, ko minuta izpada stane 100 $"? Za naprej so naše številke primerljive.

Kaj počne EcommPay IT?

Kdo smo mi? Zakaj stojim tukaj pred vami? Zakaj imam jaz pravico, da ti tukaj nekaj rečem? In o čem bomo tukaj podrobneje govorili?

Skupina podjetij EcommPay je mednarodni prevzemnik. Plačila obdelujemo po vsem svetu – v Rusiji, Evropi, jugovzhodni Aziji (povsod po svetu). Imamo 9 pisarn, skupaj 500 zaposlenih, od tega jih je približno nekaj manj kot polovica informatikov. Vse, kar počnemo, vse, s čimer zaslužimo, smo naredili sami.

Vse naše produkte (in imamo jih kar veliko - v naši liniji velikih IT produktov imamo približno 16 različnih komponent) smo napisali sami; Sami pišemo, sami se razvijamo. In trenutno opravimo približno milijon transakcij na dan (verjetno se pravi milijoni). Smo dokaj mlado podjetje - stari smo komaj šest let.

Pred 6 leti je bil tak zagon, ko so fantje prišli skupaj s podjetjem. Združila jih je ideja (drugega ni bilo kot ideja) in tekli smo. Kot vsak startup smo tekli hitreje ... Za nas je bila hitrost pomembnejša od kakovosti.

Na neki točki smo se ustavili: ugotovili smo, da s to hitrostjo in s to kakovostjo nekako ne moremo več živeti in se moramo najprej osredotočiti na kakovost. V tem trenutku smo se odločili napisati novo platformo, ki bo pravilna, razširljiva in zanesljiva. Začeli so pisati to platformo (začeli so vlagati, razvijati razvoj, testirati), vendar so na neki točki spoznali, da razvoj in testiranje ne omogočata, da bi dosegli novo raven kakovosti storitev.

Narediš nov izdelek, ga daš v proizvodnjo, pa bo vseeno nekje nekaj šlo narobe. In danes bomo govorili o tem, kako doseči novo kakovostno raven (kako nam je uspelo, o naših izkušnjah), pri čemer bomo razvoj in testiranje izločili iz enačbe; Pogovarjali se bomo o tem, kaj je operaciji na voljo - kaj operacija zmore sama, kaj lahko ponudi testiranju, da vpliva na kakovost.

Izpadi. Zapovedi delovanja.

Vedno glavni temelj, o čemer bomo danes pravzaprav govorili, so izpadi. Grozna beseda. Če imamo zastoje, je za nas vse slabo. Tečemo, da ga dvignemo, administratorji držijo strežnik - bog ne daj, da ne pade, kot pravijo v tej pesmi. O tem bomo danes govorili.

Ko smo začeli spreminjati pristope, smo oblikovali 4 zapovedi. Predstavljene imam na diapozitivih:

Te zapovedi so zelo preproste:

• Hitro ugotovite težavo.
• Znebite se ga še hitreje.
• Pomagajte razumeti razlog (kasneje, za razvijalce).
• In standardizirati pristope.

Rad bi vas opozoril na točko št. 2. Problema se znebimo, ne rešujemo. Odločanje je drugotnega pomena. Za nas je primarno, da je uporabnik zaščiten pred tem problemom. Obstajal bo v nekem izoliranem okolju, vendar to okolje ne bo imelo nobenega stika z njim. Pravzaprav bomo šli skozi te štiri skupine problemov (nekateri bolj podrobno, nekateri manj podrobno), povedal vam bom, kaj uporabljamo, kakšne ustrezne izkušnje imamo pri rešitvah.

Odpravljanje težav: Kdaj se pojavijo in kaj storiti glede njih?

Toda začeli bomo nepravilno, začeli bomo s točko št. 2 - kako se hitro znebiti težave? Obstaja težava – moramo jo odpraviti. "Kaj naj naredimo glede tega?" - glavno vprašanje. In ko smo začeli razmišljati o tem, kako odpraviti težavo, smo si razvili nekaj zahtev, ki jih mora odpravljanje težav upoštevati.

Za oblikovanje teh zahtev smo se odločili, da si zastavimo vprašanje: "Kdaj imamo težave"? In težave, kot se je izkazalo, se pojavijo v štirih primerih:

• Okvara strojne opreme.
• Zunanje storitve niso uspele.
• Spreminjanje različice programske opreme (enaka uvedba).
• Eksplozivna rast obremenitve.

O prvih dveh ne bomo govorili. Motnjo v delovanju strojne opreme je mogoče preprosto rešiti: vse morate imeti podvojeno. Če so to diski, morajo biti diski sestavljeni v RAID, če je to strežnik, mora biti strežnik podvojen, če imate omrežno infrastrukturo, morate dobaviti drugo kopijo omrežne infrastrukture, torej jo vzamete in podvoji. In če kaj ne uspe, preklopite na rezervno moč. Tukaj je težko povedati kaj več.

Drugi je odpoved zunanjih storitev. Za večino sistem sploh ni problem, za nas pa ne. Ker procesiramo plačila, smo agregator, ki stoji med uporabnikom (ki vnese podatke o svoji kartici) in bankami, plačilnimi sistemi (Visa, MasterCard, Mira itd.). Naše zunanje storitve (plačilni sistemi, banke) ponavadi odpovejo. Na to ne moremo vplivati ​​niti mi niti vi (če imate take storitve).

Kaj potem narediti? Tukaj sta dve možnosti. Najprej, če lahko, morate na nek način podvojiti to storitev. Na primer, če lahko, prenesemo promet iz ene storitve v drugo: na primer, kartice so bile obdelane prek Sberbank, Sberbank ima težave - prenesemo promet [pogojno] na Raiffeisen. Druga stvar, ki jo lahko naredimo, je, da zelo hitro opazimo izpad zunanjih storitev, zato bomo o odzivni hitrosti govorili v naslednjem delu poročila.

Pravzaprav lahko od teh štirih vplivamo na spremembo različic programske opreme - ukrepamo, da se stanje izboljša v kontekstu uvajanj in v kontekstu eksplozivne rasti obremenitev. Pravzaprav smo to storili. Tukaj pa spet majhna opomba...

Od teh štirih težav jih je nekaj takoj rešenih, če imate oblak. Če ste v oblakih Microsoft Azhur, Ozone ali uporabljate naše oblake, iz Yandexa ali Mail-a, potem vsaj okvara strojne opreme postane njihov problem in vse vam takoj postane v redu v kontekstu okvare strojne opreme.

Smo nekoliko nekonvencionalno podjetje. Tukaj vsi govorijo o "Kubernetih", o oblakih - nimamo ne "Kubernetov" ne oblakov. Vendar imamo stojala s strojno opremo v številnih podatkovnih centrih in prisiljeni smo živeti na tej strojni opremi, prisiljeni smo biti odgovorni za vse to. Zato bomo govorili v tem kontekstu. Torej o težavah. Prva dva sta bila vzeta iz oklepaja.

Spreminjanje različice programske opreme. Baze

Naši razvijalci nimajo dostopa do proizvodnje. Zakaj? Preprosto imamo certifikat PCI DSS in naši razvijalci preprosto nimajo pravice vstopiti v "izdelek". To je to, pika. Nasploh. Zato se odgovornost za razvoj konča natanko v trenutku, ko razvoj odda gradnjo v izdajo.

Naša druga osnova, ki jo imamo in ki nam prav tako zelo pomaga, je odsotnost edinstvenega nedokumentiranega znanja. Upam, da je tudi pri vas enako. Ker če temu ni tako, boste imeli težave. Težave se bodo pojavile, ko to edinstveno, nedokumentirano znanje ne bo prisotno ob pravem času na pravem mestu. Recimo, da imate eno osebo, ki zna razmestiti določeno komponento – osebe ni, je na dopustu ali bolni – to je to, imate težave.

In tretja osnova, do katere smo prišli. Do tega smo prišli z bolečino, krvjo, solzami – prišli smo do zaključka, da vsaka naša gradnja vsebuje napake, tudi če je brez napak. Sami smo se tako odločili: ko nekaj razmestimo, ko nekaj uvedemo v proizvodnjo, imamo gradnjo z napakami. Oblikovali smo zahteve, ki jih mora naš sistem izpolnjevati.

Zahteve za spremembo različice programske opreme

Obstajajo tri zahteve:

• Hitro moramo razveljaviti uvajanje.
• Vpliv neuspešne uvedbe moramo čim bolj zmanjšati.
• In moramo biti sposobni hitro vzporedno uvesti.
  Točno v tem vrstnem redu! Zakaj? Ker najprej pri uvajanju nove različice hitrost ni pomembna, ampak je pomembno, da se, če gre kaj narobe, hitro vrnete nazaj in imate minimalen vpliv. Če pa imate nabor različic v produkciji, za katere se izkaže, da je prišlo do napake (od nenavadnega ni bilo uvajanja, vendar je prišlo do napake) - je za vas pomembna hitrost nadaljnje uvedbe. Kaj smo storili, da bi izpolnili te zahteve? Uporabili smo naslednjo metodologijo:

  
  
  To je precej dobro znano, nikoli si ga nismo izmislili - to je Blue/Green deploy. Kaj je to? Imeti morate kopijo za vsako skupino strežnikov, na katerih so nameščene vaše aplikacije. Kopija je "topla": na njej ni prometa, vendar se ta promet lahko kadar koli pošlje tej kopiji. Ta kopija vsebuje prejšnjo različico. In v času uvajanja kodo uvedete v neaktivno kopijo. Nato del prometa (ali ves) preklopiš na novo verzijo. Če želite torej spremeniti prometni tok iz stare različice v novo, morate narediti samo eno dejanje: spremeniti morate izravnalnik v zgornjem toku, spremeniti smer - od enega proti drugemu. To je zelo priročno in rešuje problem hitrega preklopa in hitrega povrnitve.

  Tu je rešitev drugega vprašanja minimizacija: v novo linijo, v linijo z novo kodo (naj bo na primer 2%), lahko pošljete le del prometa. In ta 2% nista 100%! Če ste zaradi neuspešne uvedbe izgubili 100% prometa, je to strašljivo, če ste izgubili 2% prometa, je to neprijetno, ni pa strašljivo. Poleg tega uporabniki tega najverjetneje sploh ne bodo opazili, saj bo v nekaterih primerih (ne v vseh) isti uporabnik s pritiskom na F5 preusmerjen na drugo, delujočo različico.

  Modra/zelena uvedba. Usmerjanje

  Vendar pa ni vse tako preprosto “Blue/Green deploy”... Vse naše komponente lahko razdelimo v tri skupine:

  • to je frontend (strani za plačilo, ki jih vidijo naše stranke);
  • procesno jedro;
  • adapter za delo s plačilnimi sistemi (banke, MasterCard, Visa...).

  In tukaj je odtenek - odtenek je v usmerjanju med vrsticami. Če pač zamenjaš 100% prometa, teh težav nimaš. Toda če želite zamenjati 2%, začnete spraševati: "Kako to narediti?" Najpreprostejša stvar je naravnost naprej: Round Robin lahko nastavite v nginxu z naključno izbiro in imate 2 % na levi, 98 % na desni strani. Vendar to ni vedno primerno.

  Na primer, v našem primeru uporabnik komunicira s sistemom z več kot eno zahtevo. To je normalno: 2, 3, 4, 5 zahtev – vaši sistemi so lahko enaki. In če je za vas pomembno, da vse uporabniške zahteve pridejo v isto vrstico, na kateri je prišla prva zahteva, ali (druga točka) vse uporabniške zahteve pridejo v novo vrstico po preklopu (lahko bi začel delati že prej z sistem, pred preklopom), - potem ta naključna porazdelitev ni primerna za vas. Nato so na voljo naslednje možnosti:

  
  
  Prva možnost, najpreprostejša, temelji na osnovnih parametrih odjemalca (IP Hash). Imate IP in ga razdelite od desne proti levi po naslovu IP. Potem bo drugi primer, ki sem ga opisal, deloval za vas, ko je prišlo do uvajanja, je uporabnik že lahko začel delati z vašim sistemom in od trenutka uvajanja bodo vse zahteve šle v novo vrstico (recimo v isto).

  Če vam iz nekega razloga to ne ustreza in morate zahteve pošiljati na linijo, kjer je prišla uporabnikova začetna, začetna zahteva, potem imate dve možnosti ...
  Prva možnost: lahko kupite plačljivi nginx+. Obstaja mehanizem Sticky sessions, ki na prvotno zahtevo uporabnika dodeli sejo uporabniku in jo veže na enega ali drugega upstreama. Vse nadaljnje uporabniške zahteve znotraj življenjske dobe seje bodo poslane istemu zgornjemu toku, kjer je bila seja objavljena.

  To nam ni ustrezalo, ker smo že imeli običajni nginx. Prehod na nginx+ ne pomeni, da je drag, le to je bilo za nas nekoliko boleče in ni bilo prav. »Sticks Sessions« nam na primer ni deloval iz preprostega razloga, ker »Sticks Sessions« ne dovoljuje usmerjanja na podlagi »Ali-ali«. Tam lahko določite, kaj počnemo »Sticks Sessions«, na primer z naslovom IP ali z naslovom IP in piškotki ali s postparametrom, vendar je »ali-ali« tam bolj zapleteno.

  Zato smo prišli do četrte možnosti. Vzeli smo nginx na steroidih (to je openresty) - to je isti nginx, ki dodatno podpira vključitev zadnjih skriptov. Lahko napišete zadnji skript, mu daste "odprt počitek" in ta zadnji skript se bo izvedel, ko pride zahteva uporabnika.

  In napisali smo pravzaprav takšno skripto, si nastavili “openresti” in v tej skripti razvrščamo 6 različnih parametrov z veriženjem “Ali”. Glede na prisotnost enega ali drugega parametra vemo, da je uporabnik prišel na eno ali drugo stran, eno ali drugo vrstico.

  Modra/zelena uvedba. Prednosti in slabosti

  Seveda je bilo verjetno mogoče narediti nekoliko poenostavljeno (uporabite iste »Sticky Sessions«), vendar imamo tudi tako nianso, da uporabnik ne komunicira samo z nami v okviru ene obdelave ene transakcije ... Toda plačilni sistemi tudi sodelujejo z nami: Ko obdelamo transakcijo (s pošiljanjem zahteve plačilnemu sistemu), prejmemo povratno informacijo.
  In recimo, če znotraj našega vezja lahko posredujemo uporabnikov naslov IP v vseh zahtevah in razdelimo uporabnike na podlagi naslova IP, potem istemu »Visa« ne bomo rekli: »Stari, mi smo tako retro podjetje, zdi se nam biti mednaroden (na spletnem mestu in v Rusiji) ... Prosimo, da nam v dodatnem polju posredujete IP naslov uporabnika, vaš protokol je standardiziran«! Jasno je, da se ne bodo strinjali.

  
  
  Zato nam to ni uspelo - naredili smo openresty. V skladu s tem smo z usmerjanjem dobili nekaj takega:

  Modro/zelena uvedba ima torej prednosti, ki sem jih omenil, in slabosti.

  Dve slabosti:

  • se morate ukvarjati z usmerjanjem;
  • druga glavna pomanjkljivost so stroški.

  Potrebujete dvakrat več strežnikov, potrebujete dvakrat več operativnih virov, porabiti morate dvakrat več truda za vzdrževanje celotnega živalskega vrta.

  Mimogrede, med prednostmi je še ena stvar, ki je prej nisem omenil: imate rezervo v primeru povečanja obremenitve. Če imate eksplozivno rast obremenitve, imate veliko število uporabnikov, potem preprosto vključite drugo linijo v distribucijo 50 proti 50 – in takoj imate x2 strežnika v gruči, dokler ne rešite težave z več strežniki.

  Kako narediti hitro namestitev?

  Govorili smo o tem, kako rešiti problem minimizacije in hitrega povrnitve, vendar ostaja vprašanje: "Kako hitro uvesti?"

  
  
  Tukaj je kratko in preprosto.

  • Imeti morate CD sistem (Continuous Delivery) - brez njega ne morete živeti. Če imate en strežnik, ga lahko namestite ročno. Seveda imamo približno tisoč in pol strežnikov in tisoč in pol ročajev - lahko postavimo oddelek v velikosti te sobe samo za namestitev.
  • Razporeditev mora biti vzporedna. Če je vaša uvedba zaporedna, potem je vse slabo. En strežnik je normalen, ves dan boste namestili tisoč in pol strežnikov.
  • Še enkrat, za pospeševanje to verjetno ni več potrebno. Med uvajanjem je projekt običajno zgrajen. Imate spletni projekt, obstaja front-end del (tam naredite web pack, prevedete npm - nekaj takega), in ta proces je načeloma kratkotrajen - 5 minut, vendar teh 5 minut lahko bodite kritični. Zato na primer tega ne počnemo: odstranili smo teh 5 minut, razporedimo artefakte.

    Kaj je artefakt? Artefakt je sestavljena zgradba, v kateri so vsi sestavni deli že dokončani. Ta artefakt hranimo v skladišču artefaktov. Nekoč smo uporabljali dve takšni shrambi - to je bil Nexus in zdaj jFrog Artifactory) Sprva smo uporabljali "Nexus", ker smo začeli ta pristop prakticirati v java aplikacijah (dobro je ustrezal). Nato so tja dali nekaj aplikacij, napisanih v PHP; in "Nexus" ni bil več primeren, zato smo izbrali jFrog Artefactory, ki lahko artifaktorizira skoraj vse. Prišli smo celo do točke, da v tem repozitoriju artefaktov hranimo lastne binarne pakete, ki jih zbiramo za strežnike.

  Eksplozivna rast obremenitve

  Govorili smo o spremembi različice programske opreme. Naslednja stvar, ki jo imamo, je eksplozivno povečanje obremenitve. Tukaj verjetno mislim z eksplozivno rastjo obremenitve ne čisto pravo stvar...

  Napisali smo nov sistem - je storitveno usmerjen, moden, lep, povsod delavci, povsod čakalne vrste, povsod asinhronost. In v takih sistemih lahko podatki tečejo skozi različne tokove. Za prvo transakcijo se lahko uporabi 1., 3., 10. delavec, za drugo transakcijo - 2., 4., 5. delavec. In danes, recimo, imate zjutraj podatkovni tok, ki uporablja prve tri delavce, zvečer pa se dramatično spremeni in vse uporablja druge tri delavce.

  In tukaj se izkaže, da morate nekako povečati delavce, nekako morate povečati svoje storitve, a hkrati preprečiti napihnjenost virov.

  
  
  Določili smo svoje zahteve. Te zahteve so precej preproste: da obstaja odkrivanje storitev, parametrizacija - vse je standardno za gradnjo takšnih razširljivih sistemov, razen ene točke - amortizacija vira. Rekli smo, da nismo pripravljeni amortizirati virov, da bi strežniki ogrevali zrak. Vzeli smo "Consul", vzeli smo "Nomad", ki upravlja naše delavce.

  Zakaj je to za nas problem? Vrnimo se malo nazaj. Zdaj imamo za seboj okoli 70 plačilnih sistemov. Zjutraj gre promet prek Sberbank, potem je Sberbank na primer padla, pa jo preklopimo na drug plačilni sistem. Pred Sberbank smo imeli 100 delavcev, potem pa moramo za drug plačilni sistem močno povečati 100 delavcev. In zaželeno je, da se vse to zgodi brez človeškega sodelovanja. Ker če je človeška udeležba, bi moral tam 24/7 sedeti inženir, ki bi moral samo to delati, ker se takšne okvare, ko je za teboj 70 sistemov, dogajajo redno.

  Zato smo pogledali Nomad, ki ima odprt IP in napisali svojo zadevo Scale-Nomad - ScaleNo, ki naredi približno tole: spremlja rast čakalne vrste in zmanjšuje ali povečuje število delavcev glede na dinamiko čakalne vrste. Ko smo to storili, smo pomislili: "Mogoče bi lahko to odprli?" Potem so jo pogledali - bila je preprosta kot dve kopejci.

  Zaenkrat ga še nismo odprli, a če nenadoma po poročilu, ko ugotovite, da potrebujete kaj takega, ga potrebujete, so moji kontakti na zadnjem diapozitivu - prosim, pišite mi. Če bo vsaj 3-5 ljudi, bomo sponzorirali.

  
  
  Kako deluje? Gremo pogledat! Pogled naprej: na levi strani je delček našega spremljanja: to je ena vrstica, na vrhu je čas obdelave dogodka, na sredini je število transakcij, na dnu je število delavcev.

  Če pogledate, je na tej sliki napaka. Na zgornji lestvici se je ena od lestvic zrušila v 45 sekundah - eden od plačilnih sistemov je padel. Takoj je bil promet uveden v 2 minutah in čakalna vrsta se je začela povečevati na drugem plačilnem sistemu, kjer ni bilo delavcev (nismo izkoriščali virov - nasprotno, z virom smo pravilno razpolagali). Nismo želeli ogrevati - bilo je minimalno število, približno 5-10 delavcev, vendar se niso mogli spopasti.

  Zadnji graf kaže "grbo", kar samo pomeni, da je "Skaleno" ta znesek podvojilo. In potem, ko je graf malo padel, ga je malo zmanjšal - število delavcev se je samodejno spremenilo. Tako ta stvar deluje. Govorili smo o točki številka 2 - "Kako se hitro znebiti razlogov."

  Spremljanje. Kako hitro prepoznati težavo?

  Prva točka je "Kako hitro prepoznati težavo?" Spremljanje! Nekatere stvari moramo hitro razumeti. Katere stvari bi morali hitro razumeti?

  
  
  Tri stvari!

  • Razumeti in hitro moramo razumeti učinkovitost lastnih virov.
  • Hitro moramo razumeti napake in spremljati delovanje sistemov, ki so nam zunanji.
  • Tretja točka je prepoznavanje logičnih napak. To je takrat, ko vam sistem deluje, po vseh kazalnikih je vse normalno, nekaj pa gre narobe.

  Tukaj vam verjetno ne bom povedal ničesar tako kul. Jaz bom kapitan Obvious. Iskali smo, kaj je na trgu. Imamo "zabavni živalski vrt". Takšen živalski vrt imamo zdaj:

  
  
  Zabbix uporabljamo za spremljanje strojne opreme, za spremljanje glavnih indikatorjev strežnikov. Okmeter uporabljamo za baze podatkov. Za vse ostale indikatorje, ki ne ustrezajo prvima dvema, uporabljamo »Grafana« in »Prometheus«, nekatere z »Grafana« in »Prometheus«, nekatere pa z »Grafana« z »Influx« in Telegraf.

  Pred letom dni smo želeli uporabiti New Relic. Kul stvar, zmore vse. A kolikor vse zmore, toliko je draga. Ko smo zrasli na obseg 1,5 tisoč strežnikov, je k nam prišel prodajalec in rekel: "Sklenimo pogodbo za naslednje leto." Pogledali smo ceno in rekli ne, tega ne bomo storili. Zdaj opuščamo New Relic, ostalo nam je približno 15 strežnikov pod nadzorom New Relic. Cena se je izkazala za naravnost divjo.

  In obstaja eno orodje, ki smo ga implementirali sami - to je Debugger. Sprva smo ga imenovali »Bagger«, potem pa je mimo prišla učiteljica angleščine, se divje nasmejala in ga preimenovala v »Debagger«. Kaj je to? To je orodje, ki dejansko v 15-30 sekundah na vsaki komponenti, kot "črna skrinjica" sistema, izvede teste celotnega delovanja komponente.

  Na primer, če obstaja zunanja stran (plačilna stran), jo preprosto odpre in pogleda, kako bi morala izgledati. Če gre za obdelavo, pošlje testno "transakcijo" in poskrbi, da ta "transakcija" prispe. Če je to povezava s plačilnimi sistemi, ustrezno sprožimo testno zahtevo, kjer lahko, in vidimo, da je z nami vse v redu.

  Kateri kazalniki so pomembni za spremljanje?

  Kaj predvsem spremljamo? Kateri kazalniki so za nas pomembni?

  
  

  • Odzivni čas / RPS na frontah je zelo pomemben indikator. Takoj odgovori, da je s tabo nekaj narobe.
  • Število obdelanih sporočil v vseh čakalnih vrstah.
  • Število delavcev.
  • Osnovna metrika pravilnosti.

  Zadnja točka je "posel", "poslovna" metrika. Če želite spremljati isto stvar, morate določiti eno ali dve metriki, ki sta za vas glavna indikatorja. Naša metrika je prepustnost (to je razmerje med številom uspešnih transakcij in celotnim tokom transakcije). Če se v njem nekaj spremeni v intervalu 5-10-15 minut, pomeni, da imamo težave (če se korenito spremeni).

  Kako izgleda za nas, je primer ene od naših plošč:

  
  
  Na levi strani je 6 grafov, to je glede na vrstice - število delavcev in število sporočil v čakalnih vrstah. Na desni strani - RPS, RTS. Spodaj je ista "poslovna" metrika. In v metriki “poslovnost” lahko takoj vidimo, da je šlo nekaj narobe v dveh srednjih grafih ... To je samo še en sistem, ki stoji za nami, ki je padel.

  Druga stvar, ki smo jo morali narediti, je bilo spremljanje padca zunanjih plačilnih sistemov. Tukaj smo vzeli OpenTracing - mehanizem, standard, paradigmo, ki vam omogoča sledenje porazdeljenih sistemov; in je bilo malo spremenjeno. Standardna paradigma OpenTracing pravi, da zgradimo sled za vsako posamezno zahtevo. Tega nismo potrebovali in smo ga zavili v povzetek, združevanje. Izdelali smo orodje, ki nam omogoča sledenje hitrosti sistemov za nami.

  
  
  Graf nam kaže, da se je eden od plačilnih sistemov začel odzivati ​​v 3 sekundah - imamo težave. Poleg tega se bo ta stvar odzvala, ko se bodo težave začele, v intervalu 20-30 sekund.

  In tretji razred napak spremljanja, ki obstaja, je logično spremljanje.

  Iskreno povedano, nisem vedel, kaj naj narišem na ta diapozitiv, saj smo na trgu dolgo iskali nekaj, kar bi nam ustrezalo. Ničesar nismo našli, zato smo morali sami.

  
  
  Kaj mislim z logičnim spremljanjem? No, predstavljajte si: naredite si sistem (na primer klon Tinder); uspelo ti je, sprožil si. Uspešni menedžer Vasya Pupkin si ga je dal na telefon, tam vidi dekle, mu je všeč ... in podobno ne gre dekletu - podobno gre varnostniku Mikhalychu iz istega poslovnega centra. Vodja se spusti po stopnicah in se nato sprašuje: "Zakaj se mu ta varnostnik Mikhalych tako prijazno nasmehne?"

  V takšnih situacijah ... Za nas ta situacija zveni malo drugače, ker (sem napisal) gre za izgubo ugleda, ki posredno vodi v finančne izgube. Pri nas je ravno obratno: lahko utrpimo neposredno finančno izgubo – na primer, če smo izvedli transakcijo kot uspešno, a je bila neuspešna (ali obratno). Moral sem napisati svoje orodje, ki spremlja število uspešnih transakcij skozi čas s pomočjo poslovnih indikatorjev. Na trgu nisem našel ničesar! Točno to idejo sem želel posredovati. Na trgu ni ničesar, kar bi rešilo tovrstne težave.

  To je bilo o tem, kako hitro prepoznati težavo.

  Kako ugotoviti razloge za namestitev

  Tretja skupina problemov, ki jih rešujemo, je potem, ko smo identificirali problem, ko smo se ga znebili, bi bilo dobro razumeti razlog za razvoj, za testiranje in nekaj narediti glede tega. V skladu s tem moramo raziskati, moramo dvigniti polena.

  
  
  Če govorimo o dnevnikih (glavni razlog so dnevniki), je večina naših dnevnikov v skladu ELK - skoraj vsi imajo enakega. Za nekatere morda ni v ELK, a če pišete dnevnike v gigabajtih, boste prej ali slej prišli v ELK. Zapišemo jih v terabajtih.

  
  
  Tukaj je problem. Popravili smo, popravili napako za uporabnika, začeli izkopavati, kaj je tam, splezali v Kibano, tam vnesli ID transakcije in dobili takšno krpico (pokaže veliko). In čisto nič ni jasno v tej krpi. Zakaj? Da, ker ni jasno, kateri del pripada kateremu delavcu, kateri del pripada kateri komponenti. In v tistem trenutku smo spoznali, da potrebujemo sledenje – isti OpenTracing, o katerem sem govoril.

  To smo razmišljali pred enim letom, usmerili pozornost na trg in tam sta bili dve orodji - "Zipkin" in "Jaeger". "Jager" je pravzaprav tak idejni dedič, idejni naslednik "Zipkina". V Zipkinu je vse dobro, le da ne zna agregirati, ne zna vključiti dnevnikov v sledenje, samo časovno sledenje. In "Jager" je to podpiral.

  Pogledali smo "Jager": lahko instrumentirate aplikacije, lahko pišete v Api (takratni standard Api za PHP pa ni bil odobren - to je bilo pred enim letom, zdaj pa je že odobren), vendar tam ni bil absolutno nobena stranka. »Prav,« smo pomislili in napisali svoji stranki. Kaj smo dobili? Takole je približno videti:

  
  
  V Jaegerju se razponi ustvarijo za vsako sporočilo. To pomeni, da ko uporabnik odpre sistem, vidi enega ali dva bloka za vsako dohodno zahtevo (1-2-3 - število dohodnih zahtev od uporabnika, število blokov). Da bi uporabnikom olajšali delo, smo v dnevnike in časovne sledi dodali oznake. V skladu s tem bo naša aplikacija v primeru napake označila dnevnik z ustrezno oznako Napaka. Filtrirate lahko po oznaki napake in prikazani bodo samo razponi, ki vsebujejo ta blok z napako. Takole izgleda, če razširimo razpon:

  
  
  Znotraj razpona je niz sledi. V tem primeru so to tri testne sledi, tretja sled pa nam pove, da je prišlo do napake. Hkrati pa tukaj vidimo časovno sled: na vrhu imamo časovno lestvico in vidimo, v kakšnem časovnem intervalu je bil zabeležen ta ali oni dnevnik.

  Temu primerno nam je šlo dobro. Napisali smo lastno razširitev in jo odprli. Če želite delati s sledenjem, če želite delati z »Jagerjem« v PHP, obstaja naša razširitev, dobrodošla za uporabo, kot pravijo:

  
  
  Imamo to razširitev - je odjemalec za OpenTracing Api, narejena je kot php-razširitev, kar pomeni, da jo boste morali sestaviti in namestiti v sistem. Pred letom dni ni bilo nič drugače. Zdaj obstajajo druge stranke, ki so kot komponente. Tukaj je odvisno od vas: ali izčrpate komponente s skladateljem ali pa uporabite razširitev po vaši izbiri.

  Korporacijski standardi

  Pogovarjali smo se o treh zapovedih. Četrta zapoved je poenotenje pristopov. za kaj gre Gre za tole:

  
  
  Zakaj je tukaj beseda "podjetje"? Ne zato, ker smo veliko ali birokratsko podjetje, ne! Tukaj sem želel uporabiti besedo "korporacija" v kontekstu, da mora imeti vsako podjetje, vsak izdelek svoje standarde, vključno z vami. Kakšne standarde imamo?

  
  

  • Imamo predpise o uporabi. Brez njega se ne premaknemo nikamor, ne moremo. Razporejamo približno 60-krat na teden, torej skoraj nenehno. Hkrati pa imamo na primer v pravilniku o napotitvah tabu o napotitvah v petek - načeloma ne razporejamo.
  • Potrebujemo dokumentacijo. Nobena nova komponenta ne pride v proizvodnjo, če zanjo ni dokumentacije, tudi če je nastala izpod peresa naših strokovnjakov za RnD. Od njih zahtevamo navodila za namestitev, zemljevid spremljanja in grob opis (no, kot znajo napisati programerji), kako ta komponenta deluje, kako jo odpraviti.
  • Ne rešujemo vzroka problema, ampak problem - kar sem že rekel. Za nas je pomembno, da zaščitimo uporabnika pred težavami.
  • Imamo dovoljenja. Na primer, ne štejemo za izpad, če smo v dveh minutah izgubili 2 % prometa. To v bistvu ni zajeto v naši statistiki. Če je več v odstotkih ali začasno, že štejemo.
  • In vedno pišemo obsmrtnice. Karkoli se nam zgodi, se bo vsaka situacija, ko se je nekdo nenormalno obnašal v proizvodnji, odrazila v obdukciji. Obdukcija je dokument, v katerem napišete, kaj se vam je zgodilo, podroben čas, kaj ste storili, da ste to popravili in (to je obvezen blok!) kaj boste storili, da se to v prihodnosti ne bo zgodilo. To je obvezno in potrebno za nadaljnjo analizo.

  Kaj se šteje za izpad?

  
  
  Kaj je vse to vodilo?

  To je pripeljalo do tega, da (imeli smo določene težave s stabilnostjo, to ni ustrezalo ne strankam ne nam) v zadnjih 6 mesecih naš indikator stabilnosti znaša 99,97. Lahko rečemo, da to ni veliko. Ja, imamo za kaj prizadevati. Od tega kazalnika je približno polovica stabilnost, tako rekoč, ne našega, ampak požarnega zidu naše spletne aplikacije, ki stoji pred nami in se uporablja kot storitev, a naročnikom je za to vseeno.

  Ponoči smo se naučili spati. Končno! Pred šestimi meseci nismo mogli. In ob tej beležki z rezultati bi rad naredil eno opombo. Sinoči je bilo čudovito poročilo o nadzornem sistemu za jedrski reaktor. Če me ljudje, ki so napisali ta sistem, slišijo, prosim pozabite na to, kar sem rekel o tem, da "2 % ni izpad." Za vas je 2% izpad, čeprav za dve minuti!

  To je vse! Vaša vprašanja.

  
  

  O balansirjih in selitvi baz podatkov

  Vprašanje iz publike (v nadaljevanju – B): – Dober večer. Najlepša hvala za tako skrbniško poročilo! Kratko vprašanje o vaših balanserjih. Omenili ste, da imate WAF, se pravi, kot razumem, uporabljate nekakšen zunanji balanser...

  EK: – Ne, naše storitve uporabljamo kot uravnoteženje. V tem primeru je WAF za nas izključno orodje za zaščito pred napadi DDoS.

  V: – Lahko poveste nekaj besed o balanserjih?

  EK: – Kot sem že rekel, je to skupina strežnikov v openrestyju. Sedaj imamo 5 rezervnih skupin, ki se odzivajo ekskluzivno... se pravi strežnik, ki izvaja izključno openresty, samo posreduje promet. V skladu s tem, da razumemo, koliko imamo: zdaj imamo reden prometni tok nekaj sto megabitov. Zdržijo, počutijo se dobro, niti se ne obremenjujejo.

  V: – Tudi preprosto vprašanje. Tukaj je modro/zelena uvedba. Kaj počnete na primer s selitvami baz podatkov?

  EK: - Dobro vprašanje! Poglejte, pri modro/zeleni uvedbi imamo ločene čakalne vrste za vsako vrstico. To pomeni, da če govorimo o čakalnih vrstah dogodkov, ki se prenašajo od delavca do delavca, obstajata ločeni čakalni vrsti za modro in zeleno črto. Če govorimo o sami bazi podatkov, potem smo jo namenoma zožili, kolikor se je dalo, vse premaknili tako rekoč v čakalne vrste, v bazi hranimo le kup transakcij. In naš sklad transakcij je enak za vse vrstice. Z bazo podatkov v tem kontekstu: ne delimo je na modro in zeleno, ker morata obe različici kode vedeti, kaj se s transakcijo dogaja.

  Prijatelji, imam tudi majhno nagrado, da vas spodbudim - knjigo. In moral bi dobiti nagrado za najboljše vprašanje.

  V: - Zdravo. Hvala za poročilo. Vprašanje je naslednje. Spremljate plačila, spremljate storitve, s katerimi komunicirate ... Kako pa spremljate, da je oseba nekako prišla na vašo plačilno stran, opravila plačilo in mu je projekt pripisal denar? To pomeni, kako spremljate, ali je trgovec dosegljiv in je sprejel vaš povratni klic?

  EK: – »Trgovec« je za nas v tem primeru popolnoma enaka zunanja storitev kot plačilni sistem. Spremljamo hitrost odziva trgovca.

  O šifriranju baze podatkov

  V: - Zdravo. Imam malo povezano vprašanje. Imate občutljive podatke PCI DSS. Zanima me, kako shranjujete PAN v čakalne vrste, v katere morate prenesti? Ali uporabljate kakšno šifriranje? In to vodi do drugega vprašanja: v skladu s PCI DSS je treba občasno znova šifrirati bazo podatkov v primeru sprememb (odpuščanje skrbnikov itd.) - kaj se v tem primeru zgodi z dostopnostjo?

  
  
  EK: - Čudovito vprašanje! Prvič, številk PAN ne shranjujemo v čakalne vrste. Načeloma nimamo pravice shranjevati PAN kjer koli v jasni obliki, zato uporabljamo posebno storitev (imenujemo jo »Kademon«) - to je storitev, ki naredi samo eno stvar: sprejme sporočilo kot vhod in pošlje iz šifriranega sporočila. In vse shranimo s tem šifriranim sporočilom. Skladno s tem je dolžina ključa pod kilobajtom, tako da je to resno in zanesljivo.

  V: – Ali zdaj potrebujete 2 kilobajta?

  EK: – Zdi se, kot da jih je bilo ravno včeraj 256 ... No, kje drugje?!

  V skladu s tem je to prvi. In drugič, rešitev, ki obstaja, podpira postopek ponovnega šifriranja - obstajata dva para "kekov" (ključev), ki dajejo "decke", ki šifrirajo (ključi so ključi, deki so izpeljanke ključev, ki šifrirajo) . In če se postopek sproži (to se zgodi redno, od 3 mesecev do ± nekaj), prenesemo nov par "tortic" in ponovno šifriramo podatke. Imamo ločene storitve, ki iztrgajo vse podatke in jih šifrirajo na nov način; Podatki so shranjeni poleg identifikatorja ključa, s katerim so šifrirani. Skladno s tem, takoj ko šifriramo podatke z novimi ključi, stari ključ izbrišemo.

  Včasih je treba plačila opraviti ročno ...

  V: – Se pravi, če je prispelo vračilo za neko operacijo, ga boste še vedno dešifrirali s starim ključem?

  EK: - Da.

  V: – Potem pa še eno majhno vprašanje. Ko pride do kakšne okvare, padca ali incidenta, je treba transakcijo prebiti ročno. Obstaja taka situacija.

  EK: - Da včasih.

  V: – Od kod vam ti podatki? Ali pa greste sami v to skladišče?

  EK: – Ne, no, seveda imamo nekakšen zaledni sistem, ki vsebuje vmesnik za našo podporo. Če ne vemo, v kakšnem statusu je transakcija (npr. dokler se plačilni sistem ne odzove s časovno omejitvijo), tega ne vemo a priori, to pomeni, da končni status določimo samo s popolnim zaupanjem. V tem primeru transakciji dodelimo poseben status za ročno obdelavo. Zjutraj, naslednji dan, takoj ko podpora prejme informacijo, da takšne in drugačne transakcije ostanejo v plačilnem sistemu, jih ročno obdelajo v tem vmesniku.

  
  
  V: – Imam nekaj vprašanj. Eden od njih je nadaljevanje cone PCI DSS: kako zapišete njihovo vezje? To vprašanje je zato, ker bi lahko razvijalec v dnevnike vnesel karkoli! Drugo vprašanje: kako uvedete hitre popravke? Ena od možnosti je uporaba ročk v zbirki podatkov, vendar so morda na voljo brezplačni hitri popravki - kakšen je tam postopek? In tretje vprašanje je verjetno povezano z RTO, RPO. Vaša razpoložljivost je bila 99,97, skoraj štiri devetke, toda kot razumem, imate drugi podatkovni center, tretji podatkovni center in peti podatkovni center ... Kako jih sinhronizirate, replicirate in vse ostalo?

  EK: - Začnimo s prvim. Je bilo prvo vprašanje o dnevnikih? Ko pišemo dnevnike, imamo plast, ki prikrije vse občutljive podatke. Gleda masko in dodatna polja. V skladu s tem se naši dnevniki prikažejo z že zamaskiranimi podatki in vezjem PCI DSS. To je ena od rednih nalog oddelka za testiranje. Vsako nalogo morajo preveriti, vključno z dnevniki, ki jih pišejo, in to je eno od rednih opravil med pregledi kode, da se preveri, da razvijalec ni kaj zapisal. Naknadne preglede tega redno izvaja oddelek za informacijsko varnost približno enkrat na teden: selektivno se vzamejo dnevniki za zadnji dan in jih s testnih strežnikov požene skozi poseben skener-analizator, da se preveri vse.
  O hitrih popravkih. To je vključeno v naše predpise o uporabi. Imamo ločeno klavzulo o hitrih popravkih. Verjamemo, da hitre popravke uvajamo XNUMX ur na dan, ko jih potrebujemo. Takoj, ko je verzija sestavljena, takoj, ko se požene, takoj, ko imamo artefakt, imamo dežurnega sistemskega administratorja na klic podpore, ki ga razmesti v trenutku, ko je to potrebno.

  O "štirih devetkah". Številka, ki jo imamo zdaj, je res dosežena in k njej smo težili v drugem podatkovnem centru. Zdaj imamo drugi podatkovni center in začenjamo usmerjati med njima, vprašanje podvajanja med podatkovnimi centri pa je resnično netrivialno vprašanje. Enkrat smo to poskušali rešiti z različnimi sredstvi: poskušali smo uporabiti isto "Tarantulo" - ni nam uspelo, vam bom takoj povedal. Zato smo na koncu "sens" naročili ročno. Pravzaprav vsaka aplikacija v našem sistemu asinhrono izvede potrebno sinhronizacijo »sprememba – opravljeno« med podatkovnimi centri.

  V: – Če si dobil drugega, zakaj nisi dobil še tretjega? Ker še nihče nima razcepljenih možganov...

  EK: – Ampak nimamo Split Brain. Glede na to, da vsako aplikacijo poganja multimaster, nam ni pomembno, v kateri center je zahteva prispela. Pripravljeni smo na dejstvo, da če eden od naših podatkovnih centrov odpove (na to se zanašamo) in sredi zahteve uporabnika preklopi na drugi podatkovni center, smo tega uporabnika res pripravljeni izgubiti; ampak to bodo enote, absolutne enote.

  V: - Dober večer. Hvala za poročilo. Govorili ste o svojem razhroščevalniku, ki izvaja nekaj testnih transakcij v produkciji. Toda povejte nam o testnih transakcijah! Kako globoko gre?

  EK: – Gre skozi celoten cikel celotne komponente. Za komponento ni razlike med testno transakcijo in proizvodno transakcijo. Toda z logičnega vidika je to preprosto ločen projekt v sistemu, na katerem se izvajajo samo testne transakcije.

  V: -Kje ga odrežeš? Tukaj je Core poslal ...

  EK: – V tem primeru stojimo za »Korom« za testne transakcije ... Imamo nekaj takega, kot je usmerjanje: »Kor« ve, v kateri plačilni sistem naj pošlje - pošljemo v lažni plačilni sistem, ki preprosto da signal http in to je vse.

  V: – Povejte mi, prosim, ali je bila vaša aplikacija napisana v enem ogromnem monolitu ali ste jo razdelili na nekaj storitev ali celo mikrostoritev?

  EK: – Seveda nimamo monolita, imamo storitveno usmerjeno aplikacijo. Šalimo se, da je naš servis sestavljen iz monolitov – res so kar veliki. Težko bi temu rekli mikrostoritve, vendar so to storitve, znotraj katerih delujejo delavci porazdeljenih strojev.

  Če je storitev na strežniku ogrožena ...

  V: – Potem imam naslednje vprašanje. Tudi če bi šlo za monolit, ste še vedno rekli, da imate veliko teh instantnih strežnikov, vsi v bistvu obdelujejo podatke, in vprašanje je: »V primeru ogroženosti enega od instantnih strežnikov ali aplikacije, vsaka posamezna povezava , ali imajo kakšno kontrolo dostopa? Kdo od njih kaj zmore? Na koga naj se obrnem za kakšne informacije?

  
  
  EK: - Da, vsekakor. Varnostne zahteve so precej resne. Prvič, imamo odprte pretoke podatkov, vrata pa so le tista, skozi katera vnaprej predvidevamo gibanje prometa. Če komponenta komunicira z bazo podatkov (recimo z Muskul) prek 5-4-3-2, bo zanjo odprt samo 5-4-3-2, druga vrata in druge prometne smeri pa ne bodo na voljo. Poleg tega morate razumeti, da je v naši proizvodnji približno 10 različnih varnostnih zank. In tudi če je bila aplikacija kakorkoli ogrožena, bog ne daj, napadalec ne bo mogel dostopati do konzole za upravljanje strežnika, ker je to drugo varnostno območje omrežja.

  V: – In v tem kontekstu mi je bolj zanimivo to, da imaš določene pogodbe s službami – kaj lahko naredijo, s kakšnimi »akcijami« se lahko povežejo ... In v normalnem toku nekatere posebne službe zahtevajo nekaj. vrstico, na drugi seznam "dejanja". Zdi se, da se v običajnih razmerah ne obračajo na druge in imajo druga področja odgovornosti. Če je eden od njih ogrožen, ali bo lahko motil "dejanja" te storitve?..

  EK: - Razumem. Če bi bila v običajni situaciji komunikacija z drugim strežnikom sploh dovoljena, potem ja. V skladu s pogodbo SLA ne spremljamo, da so vam dovoljene le prve 3 "dejanja" in da vam niso dovoljena 4 "dejanja". To nam je verjetno odveč, ker že imamo 4-stopenjsko zaščito, načeloma za tokokroge. Raje se branimo s konturami, kot na ravni notranjosti.

  Kako delujejo Visa, MasterCard in Sberbank

  V: – Želim pojasniti točko o preklopu uporabnika iz enega podatkovnega centra v drugega. Kolikor vem, Visa in MasterCard delujeta z uporabo binarnega sinhronega protokola 8583 in tam so mešanice. In želel sem vedeti, zdaj mislimo na zamenjavo – ali gre neposredno za »Visa« in »MasterCard« ali pred plačilnimi sistemi, pred obdelavo?

  EK: - To je pred mešanicami. Naše mešanice se nahajajo v istem podatkovnem centru.

  V: – Grobo rečeno, ali imate eno povezovalno točko?

  EK: – »Visa« in »MasterCard« - da. Preprosto zato, ker Visa in MasterCard zahtevata precej resne naložbe v infrastrukturo za sklenitev ločenih pogodb za pridobitev drugega para mešanic, na primer. Rezervirani so znotraj enega podatkovnega centra, če pa nam, bog ne daj, zamre podatkovni center, kjer so mešanice za povezovanje z Viso in MasterCardom, potem bomo imeli izgubljeno povezavo z Viso in MasterCardom ...

  V: – Kako jih je mogoče rezervirati? Vem, da Visa načeloma omogoča samo eno povezavo!

  EK: – Opremo dobavljajo sami. V vsakem primeru smo dobili opremo, ki je v notranjosti popolnoma odveč.

  V: – Torej je stojalo iz njihovega Connects Orange?..

  EK: - Da.

  V: – Kaj pa ta primer: če vaš podatkovni center izgine, kako ga lahko še naprej uporabljate? Ali pa se promet preprosto ustavi?

  EK: - Ne. V tem primeru bomo promet preprosto preusmerili na drug kanal, kar bo seveda dražje za nas in dražje za naše stranke. Toda promet ne bo potekal prek naše neposredne povezave z Viso, MasterCard, ampak prek pogojne Sberbank (zelo pretirano).

  Divje se opravičujem, če sem užalil zaposlene v Sberbank. Toda po naši statistiki med ruskimi bankami najpogosteje pade Sberbank. Ne mine mesec, da ne bi pri Sberbank kaj odpadlo.

  
  
  

  Nekaj ​​oglasov 🙂

  Hvala, ker ste ostali z nami. So vam všeč naši članki? Želite videti več zanimivih vsebin? Podprite nas tako, da oddate naročilo ali priporočite prijateljem, oblak VPS za razvijalce od 4.99 $, edinstven analog začetnih strežnikov, ki smo ga izumili za vas: Vsa resnica o VPS (KVM) E5-2697 v3 (6 jeder) 10 GB DDR4 480 GB SSD 1 Gbps od 19 USD ali kako deliti strežnik? (na voljo z RAID1 in RAID10, do 24 jeder in do 40 GB DDR4).

  Dell R730xd dvakrat cenejši v podatkovnem centru Equinix Tier IV v Amsterdamu? Samo tukaj 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6 GHz 14C 64 GB DDR4 4 x 960 GB SSD 1 Gbps 100 TV od 199 $ na Nizozemskem! Dell R420 - 2x E5-2430 2.2 Ghz 6C 128 GB DDR3 2x960 GB SSD 1 Gbps 100 TB - od 99 $! Preberite o Kako zgraditi infrastrukturo Corp. razreda z uporabo strežnikov Dell R730xd E5-2650 v4 v vrednosti 9000 evrov za drobiž?

Vir: www.habr.com