HighLoad++, Mihails Makurovs, Maksims Čerņecovs (Intersvjaz): Zabbix, 100kNVPS vienā serverī

Nākamā HighLoad++ konference notiks 6. gada 7. un 2020. aprÄ«lÄ« Sanktpēterburgā SÄ«kāka informācija un biļetes ŠæŠ¾ ссыŠ»ŠŗŠµ. HighLoad++ Maskava 2018. Halle ā€œMaskavaā€. 9. novembrÄ« 15:00. Tēzes un prezentācija.

HighLoad++, Mihails Makurovs, Maksims Čerņecovs (Intersvjaz): Zabbix, 100kNVPS vienā serverī

* UzraudzÄ«ba - tieÅ”saistē un analÄ«tika.
* ZABBIX platformas pamata ierobežojumi.
* Risinājums analÄ«tikas krātuves mērogoÅ”anai.
* ZABBIX servera optimizācija.
* UI optimizācija.
* Pieredze sistēmas darbÄ«bā ar slodzi, kas pārsniedz 40 k NVPS.
* ÄŖsi secinājumi.

Mihails Makurovs (turpmāk ā€“ MM): - Sveiki visiem!

Maksims Čerņecovs (turpmāk ā€“ MCH): - Labdien!

MM: ā€“ Ä»aujiet man iepazÄ«stināt ar Maksimu. Makss ir talantÄ«gs inženieris, labākais tÄ«klu veidotājs, ko es pazÄ«stu. Maxim nodarbojas ar tÄ«kliem un pakalpojumiem, to attÄ«stÄ«bu un darbÄ«bu.

HighLoad++, Mihails Makurovs, Maksims Čerņecovs (Intersvjaz): Zabbix, 100kNVPS vienā serverī

MCH: ā€“ Un es gribētu jums pastāstÄ«t par Mihailu. Mihails ir C izstrādātājs. ViņŔ mÅ«su uzņēmumam uzrakstÄ«ja vairākus augstas slodzes satiksmes apstrādes risinājumus. Mēs dzÄ«vojam un strādājam Urālos, skarbo vÄ«ru pilsētā Čeļabinskā, uzņēmumā Intersvyaz. MÅ«su uzņēmums sniedz interneta un kabeļtelevÄ«zijas pakalpojumus vienam miljonam cilvēku 16 pilsētās.

MM: ā€“ Un ir vērts teikt, ka Intersvyaz ir daudz vairāk nekā tikai pakalpojumu sniedzējs, tas ir IT uzņēmums. Lielāko daļu mÅ«su risinājumu izstrādā mÅ«su IT nodaļa.

A: no serveriem, kas apstrādā trafiku, uz zvanu centru un mobilo lietojumprogrammu. IT nodaļā tagad ir aptuveni 80 cilvēku ar ļoti, ļoti dažādām kompetencēm.

Par Zabbix un tā arhitektūru

MCH: - Un tagad es mēģināŔu uzstādÄ«t personÄ«go rekordu un vienā minÅ«tē pateikt, kas ir Zabbix (turpmāk tekstā "Zabbix").

Zabbix pozicionē sevi kā uzņēmuma lÄ«meņa gatavu uzraudzÄ«bas sistēmu. Tam ir daudzas funkcijas, kas atvieglo dzÄ«vi: uzlaboti eskalācijas noteikumi, API integrācijai, grupÄ“Å”anai un saimniekdatoru un metrikas automātiskai noteikÅ”anai. Zabbix ir tā sauktie mērogoÅ”anas rÄ«ki - starpniekserveri. Zabbix ir atvērtā pirmkoda sistēma.

ÄŖsumā par arhitektÅ«ru. Mēs varam teikt, ka tas sastāv no trim sastāvdaļām:

HighLoad++, Mihails Makurovs, Maksims Čerņecovs (Intersvjaz): Zabbix, 100kNVPS vienā serverī

  • Serveris. RakstÄ«ts C. Ar diezgan sarežģītu apstrādi un informācijas pārsÅ«tÄ«Å”anu starp pavedieniem. Tajā notiek visa apstrāde: no saņemÅ”anas lÄ«dz saglabāŔanai datu bāzē.
  • Visi dati tiek glabāti datu bāzē. Zabbix atbalsta MySQL, PostreSQL un Oracle.
  • TÄ«mekļa saskarne ir rakstÄ«ta PHP. Lielākajā daļā sistēmu tas ir aprÄ«kots ar Apache serveri, taču tas darbojas efektÄ«vāk kombinācijā ar nginx + php.

Šodien mēs vēlamies pastāstīt vienu stāstu no mūsu uzņēmuma dzīves, kas saistīts ar Zabbix...

Stāsts no uzņēmuma Intersvyaz dzīves. Kas mums ir un kas mums vajadzīgs?

HighLoad++, Mihails Makurovs, Maksims Čerņecovs (Intersvjaz): Zabbix, 100kNVPS vienā serverī
Pirms 5 vai 6 mēneÅ”iem. Kādu dienu pēc darba...

MCH: - MiÅ”a, sveiks! Priecājos, ka izdevās tevi notvert ā€“ ir saruna. Mums atkal bija problēmas ar uzraudzÄ«bu. Lielas avārijas laikā viss noritēja lēni un nebija informācijas par tÄ«kla stāvokli. Diemžēl Ŕī nav pirmā reize, kad tas notiek. Man vajag tavu palÄ«dzÄ«bu. Panāksim, lai mÅ«su uzraudzÄ«ba darbotos jebkuros apstākļos!

MM: ā€“ Bet vispirms sinhronizēsimies. Neesmu tur skatÄ«jies pāris gadus. Cik atceros, mēs pametām Nagios un pārgājām uz Zabbix pirms kādiem 8 gadiem. Un tagad Ŕķiet, ka mums ir 6 jaudÄ«gi serveri un apmēram ducis starpniekserveru. Vai es kaut ko sajaucu?

MCH: - GandrÄ«z. 15 serveri, no kuriem daži ir virtuālās maŔīnas. Pats galvenais, ka tas mÅ«s neglābj brÄ«dÄ«, kad mums tas visvairāk vajadzÄ«gs. Tāpat kā nelaimes gadÄ«jumā - serveri palēninās, un jÅ«s neko nevarat redzēt. Mēs mēģinājām optimizēt konfigurāciju, taču tas nenodroÅ”ināja optimālu veiktspējas pieaugumu.

MM: - Tas ir skaidrs. Tu kaut ko paskatījies, kaut ko jau izrakājis no diagnostikas?

MCH: ā€“ Pirmā lieta, ar ko jums jātiek galā, ir datubāze. MySQL tiek pastāvÄ«gi ielādēts, glabājot jaunus rādÄ«tājus, un, kad Zabbix sāk Ä£enerēt virkni notikumu, datu bāze burtiski uz dažām stundām pāriet. Es jau stāstÄ«ju par konfigurācijas optimizÄ“Å”anu, bet burtiski Å”ogad viņi atjaunināja aparatÅ«ru: serveriem ir vairāk nekā simts gigabaitu atmiņas un disku masÄ«vi uz SSD RAID ā€” nav jēgas to lineāri palielināt ilgtermiņā. Ko mēs darām?

MM: - Tas ir skaidrs. Kopumā MySQL ir LTP datu bāze. AcÄ«mredzot tas vairs nav piemērots mÅ«su lieluma metriku arhÄ«va glabāŔanai. Izdomāsim.

MCH: - Ejam!

Zabbix un Clickhouse integrācija hakatona rezultātā

Pēc kāda laika mēs saņēmām interesantus datus:

HighLoad++, Mihails Makurovs, Maksims Čerņecovs (Intersvjaz): Zabbix, 100kNVPS vienā serverī

Lielāko daļu vietas mÅ«su datubāzē aizņēma metrikas arhÄ«vs, un mazāk nekā 1% tika izmantots konfigurācijai, veidnēm un iestatÄ«jumiem. LÄ«dz tam laikam mēs jau vairāk nekā gadu izmantojām lielo datu risinājumu, kura pamatā ir Clickhouse. KustÄ«bas virziens mums bija skaidrs. MÅ«su pavasara hakatonā es uzrakstÄ«ju Zabbix integrāciju ar Clickhouse serverim un priekÅ”galam. Tajā laikā Zabbix jau bija ElasticSearch atbalsts, un mēs nolēmām tos salÄ«dzināt.

HighLoad++, Mihails Makurovs, Maksims Čerņecovs (Intersvjaz): Zabbix, 100kNVPS vienā serverī

Clickhouse un Elasticsearch salīdzinājums

MM: ā€“ SalÄ«dzinājumam mēs Ä£enerējām tādu paÅ”u slodzi, kādu nodroÅ”ina Zabbix serveris, un apskatÄ«jām, kā sistēmas darbosies. Mēs rakstÄ«jām datus 1000 rindu grupās, izmantojot CURL. Mēs jau iepriekÅ” pieņēmām, ka Clickhouse bÅ«tu efektÄ«vāks Zabbix slodzes profilam. Rezultāti pat pārsniedza mÅ«su cerÄ«bas:

HighLoad++, Mihails Makurovs, Maksims Čerņecovs (Intersvjaz): Zabbix, 100kNVPS vienā serverī

Tādos paÅ”os testa apstākļos Clickhouse ierakstÄ«ja trÄ«s reizes vairāk datu. Tajā paŔā laikā abas sistēmas ļoti efektÄ«vi patērēja (neliels resursu apjoms), lasot datus. Bet Elastics ierakstÄ«Å”anas laikā prasÄ«ja lielu procesora daudzumu:

HighLoad++, Mihails Makurovs, Maksims Čerņecovs (Intersvjaz): Zabbix, 100kNVPS vienā serverī

Kopumā procesora patēriņa un ātruma ziņā Clickhouse bija ievērojami pārāks par Elastix. Tajā paŔā laikā datu saspieÅ”anas dēļ Clickhouse izmanto 11 reizes mazāk cietā diska un veic aptuveni 30 reizes mazāk darbÄ«bu ar disku:

HighLoad++, Mihails Makurovs, Maksims Čerņecovs (Intersvjaz): Zabbix, 100kNVPS vienā serverī

MCH: ā€“ Jā, Clickhouse darbs ar diska apakÅ”sistēmu tiek Ä«stenots ļoti efektÄ«vi. Varat izmantot milzÄ«gus SATA diskus datu bāzēm un iegÅ«t rakstÄ«Å”anas ātrumu simtiem tÅ«kstoÅ”u rindu sekundē. Sākotnējā sistēma atbalsta sadalÄ«Å”anu, replikāciju un ir ļoti viegli konfigurējama. Mēs esam vairāk nekā apmierināti ar tā lietoÅ”anu visa gada garumā.

Lai optimizētu resursus, varat instalēt Clickhouse blakus esoÅ”ajai galvenajai datubāzei un tādējādi ietaupÄ«t daudz CPU laika un diska darbÄ«bu. Mēs esam pārvietojuÅ”i metrikas arhÄ«vu uz esoÅ”ajiem Clickhouse klasteriem:

HighLoad++, Mihails Makurovs, Maksims Čerņecovs (Intersvjaz): Zabbix, 100kNVPS vienā serverī

Mēs tik ļoti atslogojām galveno MySQL datubāzi, ka varējām to apvienot vienā maŔīnā ar Zabbix serveri un pamest MySQL paredzēto serveri.

Kā Zabbix darbojas aptauja?

4 mēneÅ”iem

MM: ā€“ Vai varam aizmirst par problēmām ar bāzi?

MCH: - Tas tiesa! Vēl viena problēma, kas mums jāatrisina, ir lēna datu vākÅ”ana. Tagad visi mÅ«su 15 starpniekserveri ir pārslogoti ar SNMP un aptaujas procesiem. Un nav citas iespējas, kā tikai instalēt jaunus un jaunus serverus.

MM: - Lieliski. Bet vispirms pastāstiet mums, kā Zabbix darbojas aptauja?

MCH: ā€“ ÄŖsāk sakot, ir 20 metriku veidi un ducis veidu, kā tos iegÅ«t. Zabbix var vākt datus vai nu ā€œpieprasÄ«juma-atbildesā€ režīmā, vai gaidÄ«t jaunus datus, izmantojot ā€œTrapper Interfaceā€.

HighLoad++, Mihails Makurovs, Maksims Čerņecovs (Intersvjaz): Zabbix, 100kNVPS vienā serverī

Ir vērts atzÄ«mēt, ka oriÄ£inālajā Zabbix Ŕī metode (Trapper) ir ātrākā.

Slodzes sadalei ir starpniekserveri:

HighLoad++, Mihails Makurovs, Maksims Čerņecovs (Intersvjaz): Zabbix, 100kNVPS vienā serverī

Starpniekserveri var veikt tādas paÅ”as savākÅ”anas funkcijas kā Zabbix serveris, saņemot no tā uzdevumus un nosÅ«tot savāktos rādÄ«tājus caur Trapper saskarni. Å is ir oficiāli ieteiktais slodzes sadales veids. Starpniekserveri ir noderÄ«gi arÄ« attālās infrastruktÅ«ras uzraudzÄ«bai, kas darbojas, izmantojot NAT vai lēnu kanālu:

HighLoad++, Mihails Makurovs, Maksims Čerņecovs (Intersvjaz): Zabbix, 100kNVPS vienā serverī

MM: ā€“ Ar arhitektÅ«ru viss ir skaidrs. Jāskatās avoti...

Pēc pāris dienām

Stāsts par to, kā nmap fping uzvarēja

MM: "Man Ŕķiet, ka es kaut ko izraku."

MCH: - Pasaki man!

MM: ā€“ Es atklāju, ka, pārbaudot pieejamÄ«bu, Zabbix vienlaikus pārbauda ne vairāk kā 128 saimniekdatorus. Es mēģināju palielināt Å”o skaitli lÄ«dz 500 un noņemt starppakeÅ”u intervālu to ping (ping) ā€” tas dubultoja veiktspēju. Bet es gribētu lielākus skaitļus.

MCH: ā€“ Manā praksē man dažreiz ir jāpārbauda tÅ«kstoÅ”iem saimnieku pieejamÄ«ba, un es nekad neesmu redzējis neko ātrāku par nmap. Esmu pārliecināts, ka tas ir ātrākais veids. Izmēģināsim! Mums ir ievērojami jāpalielina saimniekdatoru skaits vienā iterācijā.

MM: ā€“ PārbaudÄ«t vairāk nekā pieci simti? 600?

MCH: - Vismaz pāris tūkstoŔi.

MM: - LABI. VissvarÄ«gākais, ko gribēju teikt, ir tas, ka es atklāju, ka lielākā daļa aptauju pakalpojumā Zabbix tiek veiktas sinhroni. Mums tas noteikti ir jāmaina uz asinhrono režīmu. Tad mēs varam dramatiski palielināt aptaujas dalÄ«bnieku savākto metrikas skaitu, it Ä«paÅ”i, ja palielināsim metrikas skaitu vienā iterācijā.

MCH: - Lieliski! Un tad, kad?

MM: ā€“ Kā parasti, vakar.

MCH: - Mēs salīdzinājām abas fping un nmap versijas:

HighLoad++, Mihails Makurovs, Maksims Čerņecovs (Intersvjaz): Zabbix, 100kNVPS vienā serverī

Paredzams, ka lielam skaitam saimniekdatoru nmap bÅ«s lÄ«dz pat piecām reizēm efektÄ«vāks. Tā kā nmap pārbauda tikai pieejamÄ«bu un reakcijas laiku, mēs pārcēlām zaudējumu aprēķinu uz trigeriem un ievērojami samazinājām pieejamÄ«bas pārbaudes intervālus. Mēs noskaidrojām, ka nmap optimālais saimniekdatoru skaits ir aptuveni 4 tÅ«kstoÅ”i vienā iterācijā. Nmap ļāva mums trÄ«s reizes samazināt CPU izmaksas par pieejamÄ«bas pārbaudēm un samazināt intervālu no 120 sekundēm lÄ«dz 10.

Aptauju optimizācija

MM: ā€œTad mēs sākām veikt aptaujas. MÅ«s galvenokārt interesēja SNMP noteikÅ”ana un aÄ£enti. Zabbix aptaujā tiek veikta sinhroni, un ir veikti Ä«paÅ”i pasākumi, lai palielinātu sistēmas efektivitāti. Sinhronā režīmā saimniekdatora nepieejamÄ«ba izraisa ievērojamu aptaujas pasliktināŔanos. Ir vesela stāvokļu sistēma, ir Ä«paÅ”i procesi - tā sauktie nesasniedzamie aptauju veicēji, kas strādā tikai ar nesasniedzamiem saimniekiem:

HighLoad++, Mihails Makurovs, Maksims Čerņecovs (Intersvjaz): Zabbix, 100kNVPS vienā serverī

Å is ir komentārs, kas parāda stāvokļa matricu, visu pāreju sistēmas sarežģītÄ«bu, kas nepiecieÅ”ama, lai sistēma saglabātu efektivitāti. Turklāt pati sinhronā aptauja ir diezgan lēna:

HighLoad++, Mihails Makurovs, Maksims Čerņecovs (Intersvjaz): Zabbix, 100kNVPS vienā serverī

Tāpēc tÅ«kstoÅ”iem polleru straumju desmitiem starpniekserveru nevarēja savākt mums nepiecieÅ”amo datu apjomu. Asinhronā ievieÅ”ana atrisināja ne tikai problēmas ar pavedienu skaitu, bet arÄ« ievērojami vienkārÅ”oja nepieejamo saimniekdatoru stāvokļa sistēmu, jo jebkuram skaitam, kas tika pārbaudÄ«ts vienā aptaujas iterācijā, maksimālais gaidÄ«Å”anas laiks bija 1 taimauts:

HighLoad++, Mihails Makurovs, Maksims Čerņecovs (Intersvjaz): Zabbix, 100kNVPS vienā serverī

Turklāt mēs modificējām un uzlabojām SNMP pieprasÄ«jumu aptaujas sistēmu. Fakts ir tāds, ka lielākā daļa cilvēku nevar atbildēt uz vairākiem SNMP pieprasÄ«jumiem vienlaikus. Tāpēc mēs izveidojām hibrÄ«da režīmu, kad viena un tā paÅ”a saimniekdatora SNMP aptauja tiek veikta asinhroni:

HighLoad++, Mihails Makurovs, Maksims Čerņecovs (Intersvjaz): Zabbix, 100kNVPS vienā serverī

Tas tiek darīts visam saimnieku komplektam. Šis režīms galu galā nav lēnāks par pilnīgi asinhrono režīmu, jo pusotra simta SNMP vērtību aptauja joprojām ir daudz ātrāka par 1 taimautu.

MÅ«su eksperimenti ir parādÄ«juÅ”i, ka optimālais pieprasÄ«jumu skaits vienā iterācijā ir aptuveni 8 tÅ«kstoÅ”i ar SNMP aptauju. Kopumā pāreja uz asinhrono režīmu ļāva mums paātrināt aptaujas veiktspēju 200 reizes, vairākus simtus reižu.

MCH: ā€“ Rezultātā iegÅ«tās aptauju optimizācijas parādÄ«ja, ka mēs varam ne tikai atbrÄ«voties no visiem starpniekserveriem, bet arÄ« samazināt daudzu pārbaužu intervālus, un starpniekserveri vairs nebÅ«s nepiecieÅ”ami kā slodzes dalÄ«Å”anas veids.

Apmēram pirms trim mēneÅ”iem

Mainiet arhitektūru - palieliniet slodzi!

MM: - Nu, Maks, vai ir pienācis laiks kļūt produktīvam? Man vajag jaudīgu serveri un labu inženieri.

MCH: - Labi, plānosim. Ir pēdējais laiks pāriet no miruŔā punkta ā€” 5 tÅ«kstoÅ”i metrikas sekundē.

RÄ«ts pēc jaunināŔanas

MCH: - MiÅ”a, mēs paÅ”i atjauninājāmies, bet lÄ«dz rÄ«tam ripinājām atpakaļ... Uzminiet, kādu ātrumu mums izdevās sasniegt?

MM: ā€“ maksimums 20 tÅ«kstoÅ”i.

MCH: - Jā, 25! Diemžēl esam tur, kur sākām.

MM: - Kāpēc? Vai veicat kādu diagnostiku?

MCH: - Jā, protams! Šeit, piemēram, ir interesants tops:

HighLoad++, Mihails Makurovs, Maksims Čerņecovs (Intersvjaz): Zabbix, 100kNVPS vienā serverī

MM: - SkatÄ«simies. Es redzu, ka esam izmēģinājuÅ”i milzÄ«gu skaitu aptaujas pavedienu:

HighLoad++, Mihails Makurovs, Maksims Čerņecovs (Intersvjaz): Zabbix, 100kNVPS vienā serverī

Bet tajā paŔā laikā viņi nevarēja pārstrādāt sistēmu pat uz pusi:

HighLoad++, Mihails Makurovs, Maksims Čerņecovs (Intersvjaz): Zabbix, 100kNVPS vienā serverī

Un kopējā veiktspēja ir diezgan maza, aptuveni 4 tÅ«kstoÅ”i metrikas sekundē:

HighLoad++, Mihails Makurovs, Maksims Čerņecovs (Intersvjaz): Zabbix, 100kNVPS vienā serverī

Vai ir vēl kas?

MCH: ā€“ Jā, viena no aptaujātājiem:

HighLoad++, Mihails Makurovs, Maksims Čerņecovs (Intersvjaz): Zabbix, 100kNVPS vienā serverī

MM: ā€“ Å eit skaidri redzams, ka aptaujas process gaida ā€œsemaforusā€. Å Ä«s ir slēdzenes:

HighLoad++, Mihails Makurovs, Maksims Čerņecovs (Intersvjaz): Zabbix, 100kNVPS vienā serverī

MCH: - Neskaidrs.

MM: ā€“ Skatieties, Ŕī ir lÄ«dzÄ«ga situācijai, kad virkne pavedienu mēģina strādāt ar resursiem, ar kuriem vienlaikus var strādāt tikai viens. Tad viss, ko viņi var darÄ«t, ir koplietot Å”o resursu laika gaitā:

HighLoad++, Mihails Makurovs, Maksims Čerņecovs (Intersvjaz): Zabbix, 100kNVPS vienā serverī

Un kopējo veiktspēju, strādājot ar Ŕādu resursu, ierobežo viena kodola ātrums:

HighLoad++, Mihails Makurovs, Maksims Čerņecovs (Intersvjaz): Zabbix, 100kNVPS vienā serverī

Ir divi veidi, kā atrisināt Å”o problēmu.

Jauniniet iekārtas aparatūru, pārslēdzieties uz ātrākiem kodoliem:

HighLoad++, Mihails Makurovs, Maksims Čerņecovs (Intersvjaz): Zabbix, 100kNVPS vienā serverī

Vai arī mainiet arhitektūru un vienlaikus mainiet slodzi:

HighLoad++, Mihails Makurovs, Maksims Čerņecovs (Intersvjaz): Zabbix, 100kNVPS vienā serverī

MCH: - Starp citu, testa maŔīnā mēs izmantosim mazāk kodolu nekā kaujas maŔīnā, taču tie ir 1,5 reizes ātrāki pēc frekvences uz vienu kodolu!

MM: - Skaidrs? Jāskatās servera kods.

Datu ceļŔ Zabbix serverī

MCH: - Lai to noskaidrotu, mēs sākām analizēt, kā dati tiek pārsūtīti Zabbix serverī:

HighLoad++, Mihails Makurovs, Maksims Čerņecovs (Intersvjaz): Zabbix, 100kNVPS vienā serverī

ForŔa bilde, vai ne? Apskatīsim to soli pa solim, lai tas būtu vairāk vai mazāk skaidrs. Ir pavedieni un pakalpojumi, kas ir atbildīgi par datu vākŔanu:

HighLoad++, Mihails Makurovs, Maksims Čerņecovs (Intersvjaz): Zabbix, 100kNVPS vienā serverī

Viņi pārsÅ«ta savāktos rādÄ«tājus, izmantojot ligzdu, uz priekÅ”apstrādātāja pārvaldnieku, kur tie tiek saglabāti rindā:

HighLoad++, Mihails Makurovs, Maksims Čerņecovs (Intersvjaz): Zabbix, 100kNVPS vienā serverī

ā€œPirmapstrādātāja pārvaldnieksā€ nosÅ«ta datus saviem darbiniekiem, kuri izpilda priekÅ”apstrādes instrukcijas un atdod tos atpakaļ caur to paÅ”u ligzdu:

HighLoad++, Mihails Makurovs, Maksims Čerņecovs (Intersvjaz): Zabbix, 100kNVPS vienā serverī

Pēc tam priekÅ”apstrādātāju pārvaldnieks tos saglabā vēstures keÅ”atmiņā:

HighLoad++, Mihails Makurovs, Maksims Čerņecovs (Intersvjaz): Zabbix, 100kNVPS vienā serverī

No turienes tos paņem vēstures grāvēji, kas veic diezgan daudz funkciju: piemēram, aprēķina trigerus, aizpilda vērtÄ«bu keÅ”atmiņu un, pats galvenais, saglabā metriku vēstures krātuvē. Kopumā process ir sarežģīts un ļoti mulsinoÅ”s.

HighLoad++, Mihails Makurovs, Maksims Čerņecovs (Intersvjaz): Zabbix, 100kNVPS vienā serverī

MM: ā€“ Pirmā lieta, ko mēs redzējām, bija, ka lielākā daļa pavedienu sacenÅ”as par tā saukto ā€œkonfigurācijas keÅ”atmiņuā€ (atmiņas apgabalu, kurā tiek glabātas visas servera konfigurācijas). Pavedieni, kas ir atbildÄ«gi par datu vākÅ”anu, Ä«paÅ”i daudz bloķē:

HighLoad++, Mihails Makurovs, Maksims Čerņecovs (Intersvjaz): Zabbix, 100kNVPS vienā serverī

...jo konfigurācija saglabā ne tikai metriku ar to parametriem, bet arī rindas, no kurām aptaujas veicēji ņem informāciju par tālāko rīcību. Ja ir daudz aptaujas dalībnieku un viens bloķē konfigurāciju, pārējie gaida pieprasījumus:

HighLoad++, Mihails Makurovs, Maksims Čerņecovs (Intersvjaz): Zabbix, 100kNVPS vienā serverī

Aptauju veicējiem nevajadzētu konfliktēt

HighLoad++, Mihails Makurovs, Maksims Čerņecovs (Intersvjaz): Zabbix, 100kNVPS vienā serverī

Tāpēc pirmais, ko darÄ«jām, bija rindu sadalÄ«jums 4 daļās un ļāva aptaujātājiem bloķēt Ŕīs rindas, Ŕīs daļas vienlaicÄ«gi, droÅ”os apstākļos:

HighLoad++, Mihails Makurovs, Maksims Čerņecovs (Intersvjaz): Zabbix, 100kNVPS vienā serverī

Tas novērsa konkurenci par konfigurācijas keÅ”atmiņu, un aptauju veicēju ātrums ievērojami palielinājās. Bet tad mēs saskārāmies ar faktu, ka priekÅ”apstrādātāja vadÄ«tājs sāka uzkrāt darbu rindu:

HighLoad++, Mihails Makurovs, Maksims Čerņecovs (Intersvjaz): Zabbix, 100kNVPS vienā serverī

PriekÅ”procesora pārvaldniekam jāspēj noteikt prioritātes

Tas notika gadÄ«jumos, kad viņam pietrÅ«ka snieguma. Tad viss, ko viņŔ varēja darÄ«t, bija uzkrāt pieprasÄ«jumus no datu vākÅ”anas procesiem un pievienot to buferi, lÄ«dz tas patērēja visu atmiņu un avarēja:

HighLoad++, Mihails Makurovs, Maksims Čerņecovs (Intersvjaz): Zabbix, 100kNVPS vienā serverī

Lai atrisinātu Å”o problēmu, mēs pievienojām otru kontaktligzdu, kas bija Ä«paÅ”i paredzēta darbiniekiem:

HighLoad++, Mihails Makurovs, Maksims Čerņecovs (Intersvjaz): Zabbix, 100kNVPS vienā serverī

Tādējādi priekÅ”apstrādātāja vadÄ«tājam bija iespēja noteikt sava darba prioritātes un, ja buferis palielinās, uzdevums ir palēnināt izņemÅ”anu, dodot darbiniekiem iespēju izmantot Å”o buferi:

HighLoad++, Mihails Makurovs, Maksims Čerņecovs (Intersvjaz): Zabbix, 100kNVPS vienā serverī

Tad mēs atklājām, ka viens no palēnināŔanās iemesliem bija paÅ”i strādnieki, jo viņi sacenÅ”as par resursiem, kas viņu darbam bija pilnÄ«gi nesvarÄ«gi. Mēs dokumentējām Å”o problēmu kā kļūdu labojumu, un tā jau ir atrisināta jaunajās Zabbix versijās:

HighLoad++, Mihails Makurovs, Maksims Čerņecovs (Intersvjaz): Zabbix, 100kNVPS vienā serverī

Mēs palielinām kontaktligzdu skaitu - mēs iegūstam rezultātu

Turklāt pats priekÅ”procesora pārvaldnieks kļuva par saÅ”aurinājumu, jo tas ir viens pavediens. Tas balstÄ«jās uz pamata ātrumu, nodroÅ”inot maksimālo ātrumu aptuveni 70 tÅ«kstoÅ”i metrikas sekundē:

HighLoad++, Mihails Makurovs, Maksims Čerņecovs (Intersvjaz): Zabbix, 100kNVPS vienā serverī

Tāpēc mēs izveidojām četrus strādniekus ar četriem kontaktligzdu komplektiem:

HighLoad++, Mihails Makurovs, Maksims Čerņecovs (Intersvjaz): Zabbix, 100kNVPS vienā serverī

Un tas ļāva mums palielināt ātrumu līdz aptuveni 130 tūkstoŔiem metriku:

HighLoad++, Mihails Makurovs, Maksims Čerņecovs (Intersvjaz): Zabbix, 100kNVPS vienā serverī

Izaugsmes nelinearitāte skaidrojama ar to, ka ir parādÄ«jusies konkurence par vēstures keÅ”atmiņu. Par to sacentās 4 priekÅ”apstrādātāju vadÄ«tāji un vēstures gremdētāji. Å ajā brÄ«dÄ« mēs saņēmām aptuveni 130 tÅ«kstoÅ”us metriku sekundē testa iekārtā, izmantojot to aptuveni 95% procesora:

HighLoad++, Mihails Makurovs, Maksims Čerņecovs (Intersvjaz): Zabbix, 100kNVPS vienā serverī

Apmēram pirms 2,5 mēneÅ”iem

Atteikums no snmp-community palielināja NVP pusotru reizi

MM: ā€“ Maks, man vajag jaunu testa maŔīnu! Mēs vairs neiederamies paÅ”reizējā.

MCH: - Kas tev tagad ir?

MM: ā€“ Tagad ā€“ 130 XNUMX NVP un plauktam gatavs procesors.

MCH: - Oho! ForÅ”i! Pagaidiet, man ir divi jautājumi. Pēc maniem aprēķiniem, mÅ«su nepiecieÅ”amÄ«ba ir aptuveni 15-20 tÅ«kstoÅ”i metriku sekundē. Kāpēc mums vajag vairāk?

MM: "Es gribu pabeigt darbu." Es gribētu redzēt, cik daudz mēs varam izspiest no Ŕīs sistēmas.

MCH: - Betā€¦

MM: "Bet tas ir bezjēdzīgi biznesam."

MCH: - Tas ir skaidrs. Un otrs jautājums: vai mēs paÅ”i, bez izstrādātāja palÄ«dzÄ«bas varam atbalstÄ«t to, kas mums ir tagad?

MM: - Es nedomāju. Konfigurācijas keÅ”atmiņas darbÄ«bas maiņa ir problēma. Tas ietekmē izmaiņas lielākajā daļā pavedienu, un to ir diezgan grÅ«ti uzturēt. Visticamāk, to bÅ«s ļoti grÅ«ti uzturēt.

MCH: "Tad mums ir vajadzīga kāda veida alternatīva."

MM: ā€“ Ir tāds variants. Mēs varam pāriet uz ātrajiem kodoliem, vienlaikus atsakoties no jaunās bloÄ·Ä“Å”anas sistēmas. Mēs joprojām iegÅ«sim 60-80 tÅ«kstoÅ”u metriku veiktspēju. Tajā paŔā laikā mēs varam atstāt visu pārējo kodu. Darbosies Clickhouse un asinhronā aptauja. Un to bÅ«s viegli uzturēt.

MCH: - Apbrīnojami! Iesaku Ŕeit apstāties.

Pēc servera puses optimizācijas mēs beidzot varējām palaist jauno kodu ražoÅ”anā. Mēs atteicāmies no dažām izmaiņām, pārejot uz maŔīnu ar ātriem kodoliem un samazinot koda izmaiņu skaitu. Mēs esam arÄ« vienkārÅ”ojuÅ”i konfigurāciju un, ja iespējams, novērsuÅ”i makro datu vienumos, jo tie ievieÅ” papildu bloÄ·Ä“Å”anu.

HighLoad++, Mihails Makurovs, Maksims Čerņecovs (Intersvjaz): Zabbix, 100kNVPS vienā serverī

Piemēram, atteikÅ”anās no snmp-community makro, kas bieži ir atrodams dokumentācijā un piemēros, mÅ«su gadÄ«jumā ļāva vēl vairāk paātrināt NVP aptuveni 1,5 reizes.

Pēc divām ražoÅ”anas dienām

Notikumu vēstures uznirstoÅ”o logu noņemÅ”ana

MCH: ā€“ MiÅ”a, mēs izmantojam sistēmu divas dienas, un viss darbojas. Bet tikai tad, kad viss darbojas! Bijām plānojuÅ”i darbu ar diezgan liela tÄ«kla segmenta nodoÅ”anu, un atkal ar rokām pārbaudÄ«jām, kas uzkāpa un kas nē.

MM: - Nevar būt! Mēs visu pārbaudījām 10 reizes. Serveris nekavējoties apstrādā pat pilnīgu tīkla nepieejamību.

MCH: - Jā, es visu saprotu: serveris, datu bāze, tops, austats, žurnāli - viss ir ātri... Bet mēs skatāmies uz tÄ«mekļa saskarni, un serverÄ« ir procesors ā€œplauktāā€ un Å”is:

HighLoad++, Mihails Makurovs, Maksims Čerņecovs (Intersvjaz): Zabbix, 100kNVPS vienā serverī

MM: - Tas ir skaidrs. SkatÄ«simies tÄ«meklÄ«. Mēs noskaidrojām, ka situācijā, kad bija liels skaits aktÄ«vu incidentu, lielākā daļa tieÅ”saistes logrÄ«ku sāka darboties ļoti lēni:

HighLoad++, Mihails Makurovs, Maksims Čerņecovs (Intersvjaz): Zabbix, 100kNVPS vienā serverī

Iemesls tam bija incidentu vēstures uznirstoÅ”o logu Ä£enerÄ“Å”ana, kas tiek Ä£enerēti katram saraksta vienumam. Tāpēc mēs atteicāmies no Å”o logu Ä£enerÄ“Å”anas (kodā komentējām 5 rindiņas), un tas atrisināja mÅ«su problēmas.

LogrÄ«ku ielādes laiks, pat ja tie nav pieejami, ir samazināts no vairākām minÅ«tēm lÄ«dz mums pieņemamām 10-15 sekundēm, un vēsturi joprojām var skatÄ«t, noklikŔķinot uz laika:

HighLoad++, Mihails Makurovs, Maksims Čerņecovs (Intersvjaz): Zabbix, 100kNVPS vienā serverī

Pēc darba. pirms 2 mēneÅ”iem

MCH: - MiŔa, tu ej prom? Mums jārunā.

MM: - Es nedomāju. Atkal kaut kas ar Zabbix?

MCH: - Nē, atpūties! Es tikai gribēju teikt: viss darbojas, paldies! Man ir alus.

Zabbix ir efektīvs

Zabbix ir diezgan universāla un bagātīga sistēma un funkcija. To var izmantot nelielām instalācijām, bet, pieaugot vajadzībām, tas ir jāoptimizē. Lai saglabātu lielu metrikas arhīvu, izmantojiet piemērotu krātuvi:

  • varat izmantot iebÅ«vētos rÄ«kus integrācijas veidā ar Elasticsearch vai vēstures augÅ”upielādi teksta failos (pieejams no XNUMX. versijas);
  • JÅ«s varat izmantot mÅ«su pieredzi un integrāciju ar Clickhouse.

Lai ievērojami palielinātu metriku apkopoÅ”anas ātrumu, apkopojiet tos, izmantojot asinhronas metodes, un pārsÅ«tiet tos caur trapper interfeisu uz Zabbix serveri; vai arÄ« varat izmantot plāksteri, lai padarÄ«tu Zabbix pollerus asinhronus.

Zabbix ir rakstÄ«ts C valodā un ir diezgan efektÄ«vs. Vairāku arhitektÅ«ras vājo vietu atrisināŔana ļauj vēl vairāk palielināt tā veiktspēju un, pēc mÅ«su pieredzes, iegÅ«t vairāk nekā 100 tÅ«kstoÅ”us metriku viena procesora maŔīnā.

HighLoad++, Mihails Makurovs, Maksims Čerņecovs (Intersvjaz): Zabbix, 100kNVPS vienā serverī

Tas pats Zabbix plāksteris

MM: ā€“ Es vēlos piebilst dažus punktus. Viss paÅ”reizējais pārskats, visi testi, numuri ir norādÄ«ti mÅ«su izmantotajai konfigurācijai. Tagad mēs no tā ņemam aptuveni 20 tÅ«kstoÅ”us metrikas sekundē. Ja jÅ«s mēģināt saprast, vai tas jums derēs, varat salÄ«dzināt. Å odien apspriestais ir ievietots GitHub ielāpa veidā: github.com/miklert/zabbix

HighLoad++, Mihails Makurovs, Maksims Čerņecovs (Intersvjaz): Zabbix, 100kNVPS vienā serverī

Plāksteris ietver:

  • pilnÄ«ga integrācija ar Clickhouse (gan Zabbix serveri, gan frontend);
  • problēmu risināŔana ar priekÅ”procesora vadÄ«tāju;
  • asinhronā aptauja.

Plāksteris ir savietojams ar visu 4. versiju, ieskaitot lts. Visticamāk, ar minimālām izmaiņām tas darbosies 3.4 versijā.

Paldies par uzmanību.

jautājumi

KlausÄ«tāju jautājums (turpmāk ā€“ A): ā€“ Labdien! Sakiet, lÅ«dzu, vai jums ir plāni intensÄ«vai mijiedarbÄ«bai ar Zabbix komandu vai ar viņiem ar jums, lai tas nebÅ«tu ielāps, bet gan normāla Zabbix uzvedÄ«ba?

MM: ā€“ Jā, mēs noteikti veiksim dažas izmaiņas. Kaut kas notiks, kaut kas paliks ielāps.

A: ā€“ Liels paldies par lielisko ziņojumu! Sakiet, lÅ«dzu, pēc ielāpa uzlikÅ”anas saglabāsies atbalsts no Zabbix un kā turpināt atjaunināŔanu uz augstākām versijām? Vai bÅ«s iespējams atjaunināt Zabbix pēc ielāpa uz 4.2, 5.0?

MM: ā€“ Par atbalstu neko nevaru teikt. Ja es bÅ«tu Zabbix tehniskais atbalsts, es droÅ”i vien teiktu nē, jo tas ir kāda cita kods. AttiecÄ«bā uz 4.2 kodu bāzi mÅ«su nostāja ir Ŕāda: "Mēs virzÄ«simies ar laiku un atjaunināsim sevi nākamajā versijā." Tāpēc kādu laiku mēs publicēsim ielāpu atjauninātajām versijām. Es jau ziņojumā teicu: izmaiņu skaits ar versijām joprojām ir diezgan mazs. Es domāju, ka pāreja no 3.4 uz 4 mums aizņēma apmēram 15 minÅ«tes. Kaut kas tur mainÄ«jās, bet ne Ä«paÅ”i svarÄ«gi.

A: ā€“ Tātad jÅ«s plānojat atbalstÄ«t savu ielāpu un varat droÅ”i instalēt to ražoÅ”anā un kaut kādā veidā saņemt atjauninājumus nākotnē?

MM: ā€“ Mēs to ļoti iesakām. Tas mums atrisina daudzas problēmas.

MCH: ā€“ Vēlreiz gribu vērst uzmanÄ«bu uz to, ka izmaiņas, kas neskar arhitektÅ«ru un neskar bloÄ·Ä“Å”anu vai rindas, ir modulāras, tās ir atseviŔķos moduļos. Pat ar nelielām izmaiņām tos var viegli uzturēt.

MM: ā€“ Ja interesē detaļas, tad ā€œClickhouseā€ izmanto tā saukto vēstures bibliotēku. Tas ir atsaistÄ«ts - tā ir Elastics atbalsta kopija, tas ir, tas ir konfigurējams. AptaujāŔana maina tikai aptaujas dalÄ«bniekus. Mēs uzskatām, ka tas darbosies ilgu laiku.

A: - Liels paldies. Sakiet, vai ir kāda dokumentācija par veiktajām izmaiņām?

HighLoad++, Mihails Makurovs, Maksims Čerņecovs (Intersvjaz): Zabbix, 100kNVPS vienā serverī

MM: ā€“ Dokumentācija ir ielāps. AcÄ«mredzot, ievieÅ”ot Clickhouse, ievieÅ”ot jaunus polleru veidus, rodas jaunas konfigurācijas iespējas. Saitei no pēdējā slaida ir Ä«ss apraksts par to, kā to izmantot.

Par fping aizstāŔanu ar nmap

A: ā€“ Kā jÅ«s to beidzot Ä«stenojāt? Vai varat sniegt konkrētus piemērus: vai jums ir siksnas un ārējs skripts? Kas beidzas, kad tik ātri tiek pārbaudÄ«ts tik liels skaits saimnieku? Kā jÅ«s iegÅ«stat Å”os saimniekus? Vai vajag kaut kā tos iebarot nmap, kaut kur dabÅ«t, ielikt, kaut ko palaist?..

MM: - ForÅ”i. Ä»oti pareizs jautājums! Lieta ir tāda. Pārveidojām bibliotēku (ICMP ping, daļa no Zabbix) ICMP pārbaudēm, kas norāda pakeÅ”u skaitu - vienu (1), un kods mēģina izmantot nmap. Tas ir, tas ir Zabbix iekŔējais darbs, kas ir kļuvis par pingera iekŔējo darbu. AttiecÄ«gi nav nepiecieÅ”ama sinhronizācija vai slazda izmantoÅ”ana. Tas tika darÄ«ts apzināti, lai sistēma paliktu neskarta un nebÅ«tu jānodarbojas ar divu datu bāzes sistēmu sinhronizāciju: ko pārbaudÄ«t, augÅ”upielādēt caur polleri un vai mÅ«su augÅ”upielāde ir bojāta?.. Tas ir daudz vienkārŔāk.

A: ā€“ Vai tas darbojas arÄ« starpniekserveriem?

MM: ā€“ Jā, bet mēs nepārbaudÄ«jām. Aptaujas kods ir vienāds gan Zabbix, gan serverÄ«. Vajadzētu strādāt. Ä»aujiet man vēlreiz uzsvērt: sistēmas veiktspēja ir tāda, ka mums nav nepiecieÅ”ams starpniekserveris.

MCH: ā€“ Pareizā atbilde uz jautājumu ir: "Kāpēc jums ir nepiecieÅ”ams starpniekserveris ar Ŕādu sistēmu?" Tikai NAT vai monitoringa dēļ pa kaut kādu lēnu kanālu...

A: ā€“ Un jÅ«s izmantojat Zabbix kā alergoru, ja es pareizi saprotu. Vai arÄ« jÅ«su grafika (kur atrodas arhÄ«va slānis) ir pārvietota uz citu sistēmu, piemēram, Grafana? Vai arÄ« jÅ«s neizmantojat Å”o funkciju?

MM: ā€“ UzsvērÅ”u vēlreiz: esam panākuÅ”i pilnÄ«gu integrāciju. Mēs ielejam Clickhouse vēsturi, bet tajā paŔā laikā esam mainÄ«juÅ”i php frontend. Php priekÅ”gals nonāk Clickhouse un veic visu grafiku no turienes. Tajā paŔā laikā, godÄ«gi sakot, mums ir daļa, kas veido datus citās grafiskās displeja sistēmās no tā paÅ”a Clickhouse, no tiem paÅ”iem Zabbix datiem.

MCH: ā€“ ArÄ« ā€œGrafānāā€.

Kā tika pieņemti lēmumi par resursu pieŔķirÅ”anu?

A: ā€“ Dalieties mazliet no savas iekŔējās virtuves. Kā tika pieņemts lēmums, ka nepiecieÅ”ams atvēlēt resursus nopietnai produkta pārstrādei? Tie kopumā ir noteikti riski. Un sakiet, lÅ«dzu, kontekstā ar to, ka jÅ«s gatavojaties atbalstÄ«t jaunas versijas: kā Å”is lēmums ir pamatots no vadÄ«bas viedokļa?

MM: ā€“ AcÄ«mredzot mēs ne pārāk labi izstāstÄ«jām vēstures drāmu. Nonācām situācijā, kad kaut kas bija jādara, un bÅ«tÄ«bā gājām ar divām paralēlām komandām:

  • Viens no tiem bija uzraudzÄ«bas sistēmas ievieÅ”ana, izmantojot jaunas metodes: uzraudzÄ«ba kā pakalpojums, standarta atvērtā pirmkoda risinājumu komplekts, ko mēs apvienojam un pēc tam cenÅ”amies mainÄ«t biznesa procesu, lai strādātu ar jauno uzraudzÄ«bas sistēmu.
  • Tajā paŔā laikā mums bija entuziastisks programmētājs, kurÅ” to darÄ«ja (par sevi). SagadÄ«jās, ka viņŔ uzvarēja.

A: ā€“ Un kāds ir komandas lielums?

MCH: ā€“ Viņa ir tavā priekŔā.

A: ā€“ Tātad, kā vienmēr, jums ir vajadzÄ«gs kaislÄ«gs cilvēks?

MM: ā€“ Es nezinu, kas ir kaislÄ«gs cilvēks.

A: - Šajā gadījumā acīmredzot jūs. Liels paldies, jūs esat lieliski.

MM: - Paldies.

Par ielāpiem Zabbix

A: ā€“ Vai sistēmai, kas izmanto starpniekserverus (piemēram, dažās dalÄ«tajās sistēmās), ir iespējams pielāgot un lāpÄ«t, teiksim, pollerus, starpniekserverus un daļēji paÅ”u Zabbix priekÅ”procesoru; un to mijiedarbÄ«ba? Vai ir iespējams optimizēt esoŔās sistēmas ar vairākiem starpniekserveriem?

MM: ā€“ Zinu, ka Zabbix serveris tiek samontēts, izmantojot starpniekserveri (kods tiek apkopots un iegÅ«ts). Mēs to neesam pārbaudÄ«juÅ”i ražoÅ”anā. Es neesmu pārliecināts par to, bet es domāju, ka starpniekserverÄ« netiek izmantots priekÅ”procesora pārvaldnieks. Starpniekservera uzdevums ir paņemt no Zabbix metrikas, apvienot tos (tā arÄ« ieraksta konfigurāciju, lokālo datu bāzi) un atdot to atpakaļ Zabbix serverim. Pēc tam serveris pats veiks priekÅ”apstrādi, kad tas to saņems.

Interese par pilnvarotajiem ir saprotama. Mēs to pārbaudīsim. Šī ir interesanta tēma.

A: ā€“ Ideja bija Ŕāda: ja varat izlāpÄ«t pollerus, varat tos labot starpniekserverÄ« un izlabot mijiedarbÄ«bu ar serveri, kā arÄ« pielāgot priekÅ”apstrādātāju Å”iem mērÄ·iem tikai serverÄ«.

MM: ā€“ Manuprāt, tas ir vēl vienkārŔāk. JÅ«s paņemat kodu, uzliekat ielāpu, pēc tam konfigurējat to tā, kā jums nepiecieÅ”ams - savāc starpniekserverus (piemēram, ar ODBC) un izplata ielāpu kodu pa sistēmām. Kur nepiecieÅ”ams - savākt starpniekserveri, kur nepiecieÅ”ams - serveri.

A: ā€“ Visticamāk, jums nebÅ«s papildus jālāgo starpniekservera pārraide uz serveri?

MCH: - Nē, tas ir standarts.

MM: ā€“ PatiesÄ«bā viena no idejām neizklausÄ«jās. Vienmēr esam saglabājuÅ”i lÄ«dzsvaru starp ideju sprādzienbÄ«stamÄ«bu un izmaiņu apjomu un atbalsta vieglumu.

Dažas reklāmas šŸ™‚

Paldies, ka palikāt kopā ar mums. Vai jums patīk mūsu raksti? Vai vēlaties redzēt interesantāku saturu? Atbalsti mūs, pasūtot vai iesakot draugiem, mākoņa VPS izstrādātājiem no 4.99 USD, unikāls sākuma līmeņa serveru analogs, ko mēs jums izgudrojām: Visa patiesība par VPS (KVM) E5-2697 v3 (6 kodoli) 10GB DDR4 480GB SSD 1Gbps no 19$ vai kā koplietot serveri? (pieejams ar RAID1 un RAID10, līdz 24 kodoliem un līdz 40 GB DDR4).

Dell R730xd 2x lētāk Equinix Tier IV datu centrā Amsterdamā? Tikai Å”eit 2x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV no 199$ NÄ«derlandē! Dell R420 ā€” 2x E5-2430 2.2 GHz 6C 128 GB DDR3 2x960 GB SSD 1 Gbps 100 TB ā€” no 99 USD! LasÄ«t par Kā izveidot infrastruktÅ«ras uzņēmumu klase ar Dell R730xd E5-2650 v4 serveru izmantoÅ”anu 9000 eiro par santÄ«mu?

Avots: www.habr.com

Pievieno komentāru