HighLoad++, მიხაილ მაკუროვი, მაქსიმ ჩერნეცოვი (ინტერსვიაზი): Zabbix, 100kNVPS ერთ სერვერზე

შემდეგი HighLoad++ კონფერენცია გაიმართება 6 წლის 7 და 2020 აპრილს სანკტ-პეტერბურგში დეტალები და ბილეთები по ссылке. HighLoad++ მოსკოვი 2018. დარბაზი “მოსკოვი”. 9 ნოემბერი, 15:00 საათი. თეზისები და პრეზენტაცია.

* მონიტორინგი - ონლაინ და ანალიტიკა.
* ZABBIX პლატფორმის ძირითადი შეზღუდვები.
* ანალიტიკის შენახვის სკალირების გამოსავალი.
* ZABBIX სერვერის ოპტიმიზაცია.
* ინტერფეისის ოპტიმიზაცია.
* სისტემის მუშაობის გამოცდილება 40k NVPS-ზე მეტი დატვირთვით.
* მოკლე დასკვნები.

მიხაილ მაკუროვი (შემდგომში – მ.მ.): - Სალამი ყველას!

მაქსიმ ჩერნეცოვი (შემდგომში - MCH): - Საღამო მშვიდობისა!

მმ: – ნება მომეცით წარმოგიდგინოთ მაქსიმ. მაქსი ნიჭიერი ინჟინერია, საუკეთესო ქსელური, რომელსაც ვიცნობ. Maxim ჩართულია ქსელებსა და სერვისებში, მათ განვითარებასა და ექსპლუატაციაში.

MCH: - და მინდა მოგიყვეთ მიხეილზე. მიხაილი არის C დეველოპერი. მან დაწერა რამდენიმე მაღალი დატვირთვის მქონე ტრაფიკის დამუშავების გადაწყვეტა ჩვენი კომპანიისთვის. ჩვენ ვცხოვრობთ და ვმუშაობთ ურალში, მკაცრი კაცების ქალაქში, ჩელიაბინსკში, კომპანია Intersvyaz-ში. ჩვენი კომპანია არის ინტერნეტისა და საკაბელო ტელევიზიის სერვისების მიმწოდებელი მილიონი ადამიანისთვის 16 ქალაქში.

მმ: – და ღირს იმის თქმა, რომ Intersvyaz ბევრად მეტია ვიდრე უბრალოდ პროვაიდერი, ის არის IT კომპანია. ჩვენი გადაწყვეტილებების უმეტესობა დამზადებულია ჩვენი IT დეპარტამენტის მიერ.

A: სერვერებიდან, რომლებიც ამუშავებენ ტრაფიკს ქოლ ცენტრამდე და მობილურ აპლიკაციამდე. IT დეპარტამენტს ახლა დაახლოებით 80 ადამიანი ჰყავს ძალიან, ძალიან მრავალფეროვანი კომპეტენციებით.

Zabbix-ისა და მისი არქიტექტურის შესახებ

MCH: - ახლა კი ვეცდები დავამყარო პირადი რეკორდი და ერთ წუთში ვთქვა, რა არის Zabbix (შემდგომში "Zabbix").

Zabbix პოზიციონირებს საკუთარ თავს, როგორც საწარმოს დონის გარე მონიტორინგის სისტემა. მას აქვს მრავალი ფუნქცია, რომელიც აადვილებს ცხოვრებას: გაფართოებული ესკალაციის წესები, API ინტეგრაციისთვის, ჰოსტების და მეტრიკის დაჯგუფება და ავტომატური ამოცნობა. Zabbix-ს აქვს ეგრეთ წოდებული სკალირების ხელსაწყოები - პროქსი. Zabbix არის ღია კოდის სისტემა.

მოკლედ არქიტექტურის შესახებ. შეიძლება ითქვას, რომ იგი შედგება სამი კომპონენტისგან:

• სერვერი. დაწერილი C. საკმაოდ რთული დამუშავებითა და ძაფებს შორის ინფორმაციის გადაცემით. მასში ხდება ყველა დამუშავება: მიღებიდან მონაცემთა ბაზამდე შენახვამდე.
• ყველა მონაცემი ინახება მონაცემთა ბაზაში. Zabbix მხარს უჭერს MySQL, PostreSQL და Oracle.
• ვებ ინტერფეისი დაწერილია PHP-ში. უმეტეს სისტემებზე მას გააჩნია Apache სერვერი, მაგრამ უფრო ეფექტურად მუშაობს nginx + php-თან ერთად.

დღეს გვინდა მოგიყვეთ ერთი ამბავი ჩვენი კომპანიის ცხოვრებიდან, რომელიც დაკავშირებულია Zabbix-თან...

ამბავი კომპანია Intersvyaz-ის ცხოვრებიდან. რა გვაქვს და რა გვჭირდება?

5 თუ 6 თვის წინ. სამსახურიდან ერთი დღე...

MCH: -მიშა გამარჯობა! მიხარია, რომ მოვახერხე შენი დაჭერა - საუბარია. ჩვენ ისევ შეგვექმნა პრობლემები მონიტორინგთან დაკავშირებით. დიდი ავარიის დროს ყველაფერი ნელა მიმდინარეობდა და არ იყო ინფორმაცია ქსელის მდგომარეობის შესახებ. სამწუხაროდ, ეს პირველი შემთხვევა არ არის. Შენი დახმარება მჭირდება. მოდით, ჩვენი მონიტორინგი ნებისმიერ პირობებში იმუშაოს!

მმ: - ოღონდ ჯერ სინქრონიზაცია მოვახდინოთ. რამდენიმე წელია იქ არ შემიხედავს. რამდენადაც მახსოვს, ნაგიოსი მივატოვეთ და Zabbix-ზე გადავედით დაახლოებით 8 წლის წინ. ახლა კი, როგორც ჩანს, გვაქვს 6 მძლავრი სერვერი და დაახლოებით ათეული პროქსი. რამეს ვაბნევ?

MCH: - თითქმის. 15 სერვერი, რომელთაგან ზოგიერთი ვირტუალური მანქანაა. რაც მთავარია, ის არ გვიშველის იმ მომენტში, როცა ყველაზე მეტად გვჭირდება. უბედური შემთხვევის მსგავსად - სერვერები ნელდება და ვერაფერს ხედავთ. ჩვენ ვცადეთ კონფიგურაციის ოპტიმიზაცია, მაგრამ ამან ვერ უზრუნველყო ოპტიმალური შესრულების გაზრდა.

მმ: - Ნათელია. რამეს შეხედე, დიაგნოსტიკიდან უკვე ამოთხარე რამე?

MCH: – პირველი, რაც თქვენ უნდა გაუმკლავდეთ არის მონაცემთა ბაზა. MySQL მუდმივად იტვირთება, ინახავს ახალ მეტრიკას და როდესაც Zabbix იწყებს მოვლენების თაიგულის გენერირებას, მონაცემთა ბაზა გადადის ზედმეტად რამდენიმე საათის განმავლობაში. მე უკვე გითხარით კონფიგურაციის ოპტიმიზაციის შესახებ, მაგრამ ფაქტიურად წელს მათ განაახლეს აპარატურა: სერვერებს აქვთ ასზე მეტი გიგაბაიტი მეხსიერება და დისკის მასივები SSD RAID-ებზე - აზრი არ აქვს გრძელვადიან პერსპექტივაში მის ხაზოვან გაზრდას. Რას ვაკეთებთ?

მმ: - Ნათელია. ზოგადად, MySQL არის LTP მონაცემთა ბაზა. როგორც ჩანს, ის აღარ არის შესაფერისი ჩვენი ზომის მეტრიკის არქივის შესანახად. მოდი გავარკვიოთ.

MCH: - მოდით!

Zabbix-ისა და Clickhouse-ის ინტეგრაცია ჰაკათონის შედეგად

გარკვეული პერიოდის შემდეგ მივიღეთ საინტერესო მონაცემები:

ჩვენს მონაცემთა ბაზაში სივრცის უმეტესი ნაწილი ეკავა მეტრიკის არქივს და 1%-ზე ნაკლები გამოიყენებოდა კონფიგურაციისთვის, შაბლონებისთვის და პარამეტრებისთვის. იმ დროისთვის ჩვენ ერთ წელზე მეტი ხნის განმავლობაში ვმუშაობდით Big data გადაწყვეტაზე, რომელიც დაფუძნებულია Clickhouse-ზე. ჩვენთვის აშკარა იყო მოძრაობის მიმართულება. ჩვენს საგაზაფხულო ჰაკათონზე დავწერე Zabbix-ის ინტეგრაცია Clickhouse-თან სერვერისა და ფრონტენდისთვის. იმ დროს Zabbix-ს უკვე ჰქონდა მხარდაჭერა ElasticSearch-ისთვის და ჩვენ გადავწყვიტეთ მათი შედარება.

Clickhouse-ისა და Elasticsearch-ის შედარება

მმ: – შედარებისთვის, ჩვენ შევქმენით იგივე დატვირთვა, რასაც Zabbix სერვერი გვაწვდის და შევხედეთ, როგორ მოიქცეოდნენ სისტემები. ჩვენ დავწერეთ მონაცემები 1000 სტრიქონიანი პარტიებით, CURL-ის გამოყენებით. ჩვენ წინასწარ ვივარაუდეთ, რომ Clickhouse უფრო ეფექტური იქნებოდა დატვირთვის პროფილისთვის, რომელსაც Zabbix აკეთებს. შედეგებმა ჩვენს მოლოდინს გადააჭარბა:

იგივე ტესტის პირობებში Clickhouse-მა დაწერა სამჯერ მეტი მონაცემი. ამავდროულად, ორივე სისტემა ძალიან ეფექტურად მოიხმარდა (მცირე რაოდენობით რესურსებს) მონაცემების წაკითხვისას. მაგრამ Elastics-ს სჭირდებოდა დიდი რაოდენობით პროცესორი ჩაწერისას:

მთლიანობაში Clickhouse მნიშვნელოვნად აღემატებოდა Elastix-ს პროცესორის მოხმარებითა და სიჩქარით. ამავდროულად, მონაცემთა შეკუმშვის გამო, Clickhouse იყენებს 11-ჯერ ნაკლებს მყარ დისკზე და ასრულებს დაახლოებით 30-ჯერ ნაკლებ ოპერაციებს დისკზე:

MCH: – დიახ, Clickhouse-ის მუშაობა დისკის ქვესისტემასთან ძალიან ეფექტურად ხორციელდება. შეგიძლიათ გამოიყენოთ უზარმაზარი SATA დისკები მონაცემთა ბაზებისთვის და მიიღოთ ასობით ათასი ხაზის წერის სიჩქარე წამში. მიღმა სისტემა მხარს უჭერს გაფანტვას, რეპლიკაციას და ძალიან მარტივია კონფიგურაციისთვის. ჩვენ უფრო კმაყოფილი ვართ მისი გამოყენებით მთელი წლის განმავლობაში.

რესურსების ოპტიმიზაციისთვის შეგიძლიათ დააინსტალიროთ Clickhouse თქვენი არსებული ძირითადი მონაცემთა ბაზის გვერდით და ამით დაზოგოთ პროცესორის დიდი დრო და დისკის ოპერაციები. ჩვენ გადავიტანეთ მეტრიკის არქივი არსებულ Clickhouse კლასტერებში:

ჩვენ გავათავისუფლეთ ძირითადი MySQL მონაცემთა ბაზა ისე, რომ შეგვეძლო მისი გაერთიანება ერთ მანქანაზე Zabbix სერვერთან და მიტოვება გამოყოფილი სერვერისთვის MySQL-ისთვის.

როგორ მუშაობს გამოკითხვა Zabbix-ში?

4 თვის წინ

მმ: – აბა, შეგვიძლია დავივიწყოთ ბაზასთან დაკავშირებული პრობლემები?

MCH: - ეს აუცილებლად! კიდევ ერთი პრობლემა, რომელიც უნდა გადავწყვიტოთ, არის მონაცემთა ნელი შეგროვება. ახლა ყველა ჩვენი 15 პროქსი სერვერი გადატვირთულია SNMP და კენჭისყრის პროცესებით. და ახალი და ახალი სერვერების დაყენების გარდა სხვა გზა არ არსებობს.

მმ: - დიდი. მაგრამ ჯერ გვითხარით, როგორ მუშაობს გამოკითხვა Zabbix-ში?

MCH: – მოკლედ, არსებობს 20 ტიპის მეტრიკა და მათი მოპოვების ათეული გზა. Zabbix-ს შეუძლია მონაცემების შეგროვება ან „მოთხოვნა-პასუხის“ რეჟიმში, ან დაელოდო ახალ მონაცემებს „Trapper Interface“-ის მეშვეობით.

აღსანიშნავია, რომ ორიგინალურ Zabbix-ში ეს მეთოდი (Trapper) ყველაზე სწრაფია.

არსებობს პროქსი სერვერები დატვირთვის განაწილებისთვის:

პროქსიებს შეუძლიათ შეასრულონ იგივე შეგროვების ფუნქციები, როგორც Zabbix სერვერი, მიიღონ ამოცანები მისგან და გაგზავნონ შეგროვებული მეტრიკა Trapper ინტერფეისის მეშვეობით. ეს არის ოფიციალურად რეკომენდებული გზა დატვირთვის განაწილებისთვის. პროქსი ასევე სასარგებლოა დისტანციური ინფრასტრუქტურის მონიტორინგისთვის, რომელიც მუშაობს NAT ან ნელი არხით:

მმ: – არქიტექტურაში ყველაფერი ნათელია. წყაროებს უნდა მივხედოთ...

ორიოდე დღის შემდეგ

ამბავი იმის შესახებ, თუ როგორ მოიგო nmap fping

მმ: "ვფიქრობ, რაღაც ამოთხარე."

MCH: - Მითხარი!

მმ: – აღმოვაჩინე, რომ ხელმისაწვდომობის შემოწმებისას, Zabbix ამოწმებს მაქსიმუმ 128 ჰოსტს ერთდროულად. მე ვცადე ამ რიცხვის გაზრდა 500-მდე და ამომეღო პაკეტთაშორისი ინტერვალი მათ პინგში - ამან გააორმაგა შესრულება. მაგრამ მე უფრო დიდი რიცხვები მინდა.

MCH: – ჩემს პრაქტიკაში ზოგჯერ მიწევს ათასობით ჰოსტის ხელმისაწვდომობის შემოწმება და ამისთვის nmap-ზე სწრაფი არაფერი მინახავს. დარწმუნებული ვარ, ეს ყველაზე სწრაფი გზაა. Მოდი ვცადოთ ეს! ჩვენ გვჭირდება მნიშვნელოვნად გავზარდოთ ჰოსტების რაოდენობა ერთ გამეორებაზე.

მმ: – შეამოწმეთ ხუთასზე მეტი? 600?

MCH: - რამდენიმე ათასი მაინც.

მმ: - ᲙᲐᲠᲒᲘ. ყველაზე მნიშვნელოვანი, რაც მინდოდა მეთქვა, არის ის, რომ აღმოვაჩინე, რომ Zabbix-ში გამოკითხვის უმეტესობა სინქრონულად კეთდება. ჩვენ აუცილებლად უნდა შევცვალოთ ის ასინქრონულ რეჟიმში. მაშინ ჩვენ შეგვიძლია მკვეთრად გავზარდოთ გამომძიებლების მიერ შეგროვებული მეტრიკის რაოდენობა, განსაკუთრებით თუ გავზრდით მეტრიკების რაოდენობას თითო გამეორებაზე.

MCH: - დიდი! Და როცა?

მმ: - როგორც ყოველთვის, გუშინ.

MCH: - ჩვენ შევადარეთ fping-ისა და nmap-ის ორივე ვერსია:

ჰოსტების დიდ რაოდენობაზე მოსალოდნელი იყო, რომ nmap ხუთჯერ უფრო ეფექტური იქნებოდა. ვინაიდან nmap ამოწმებს მხოლოდ ხელმისაწვდომობას და რეაგირების დროს, ჩვენ გადავიტანეთ დანაკარგების გამოთვლა ტრიგერებზე და მნიშვნელოვნად შევამცირეთ ხელმისაწვდომობის შემოწმების ინტერვალები. ჩვენ აღმოვაჩინეთ, რომ nmap-ისთვის ჰოსტების ოპტიმალური რაოდენობა იყო დაახლოებით 4 ათასი თითო გამეორებაზე. Nmap-მა მოგვცა საშუალება სამჯერ შეგვემცირებინა CPU-ს ხელმისაწვდომობის შემოწმების ღირებულება და შეგვემცირებინა ინტერვალი 120 წამიდან 10-მდე.

გამოკითხვის ოპტიმიზაცია

მმ: „მაშინ დავიწყეთ გამოკითხვის გაკეთება. ჩვენ ძირითადად დაინტერესებული ვიყავით SNMP-ის გამოვლენით და აგენტებით. Zabbix-ში კენჭისყრა სინქრონულად ხდება და სპეციალური ღონისძიებებია გატარებული სისტემის ეფექტურობის ასამაღლებლად. სინქრონულ რეჟიმში, ჰოსტის მიუწვდომლობა იწვევს პოლინგის მნიშვნელოვან დეგრადაციას. არსებობს სახელმწიფოთა მთელი სისტემა, არის სპეციალური პროცესები - ეგრეთ წოდებული მიუწვდომელი პოლერები, რომლებიც მუშაობენ მხოლოდ მიუწვდომელ ჰოსტებთან:

ეს არის კომენტარი, რომელიც ასახავს მდგომარეობის მატრიცას, გადასვლების სისტემის მთელ სირთულეს, რაც საჭიროა იმისათვის, რომ სისტემა ეფექტური დარჩეს. გარდა ამისა, სინქრონული გამოკითხვა თავისთავად საკმაოდ ნელია:

სწორედ ამიტომ, ათასობით პოლერის ნაკადმა ათეულობით პროქსიზე ვერ შეაგროვა ჩვენთვის საჭირო რაოდენობის მონაცემები. ასინქრონულმა განხორციელებამ გადაჭრა არა მხოლოდ ძაფების რაოდენობასთან დაკავშირებული პრობლემები, არამედ მნიშვნელოვნად გაამარტივა მიუწვდომელი ჰოსტების სახელმწიფო სისტემა, რადგან ერთ გამოკითხვის გამეორებაში შემოწმებული ნებისმიერი რიცხვისთვის მაქსიმალური ლოდინის დრო იყო 1 დრო:

გარდა ამისა, ჩვენ შევცვალეთ და გავაუმჯობესეთ კენჭისყრის სისტემა SNMP მოთხოვნებისთვის. ფაქტია, რომ ადამიანების უმეტესობას არ შეუძლია ერთდროულად უპასუხოს მრავალ SNMP მოთხოვნას. ამიტომ, ჩვენ შევქმენით ჰიბრიდული რეჟიმი, როდესაც იგივე ჰოსტის SNMP გამოკითხვა ხდება ასინქრონულად:

ეს კეთდება მასპინძლების მთელი პაკეტისთვის. ეს რეჟიმი საბოლოოდ არ არის ნელი, ვიდრე სრულიად ასინქრონული, რადგან ასი და ნახევარი SNMP მნიშვნელობის გამოკითხვა ჯერ კიდევ ბევრად უფრო სწრაფია, ვიდრე 1 დრო.

ჩვენმა ექსპერიმენტებმა აჩვენა, რომ მოთხოვნათა ოპტიმალური რაოდენობა ერთ გამეორებაში არის დაახლოებით 8 ათასი SNMP გამოკითხვით. საერთო ჯამში, ასინქრონულ რეჟიმზე გადასვლამ მოგვცა საშუალება 200-ჯერ, რამდენიმე ასეულჯერ გაგვეჩქარებინა გამოკითხვის შესრულება.

MCH: – გამოკითხვის შედეგად მიღებული ოპტიმიზაციამ აჩვენა, რომ ჩვენ შეგვიძლია არა მხოლოდ ყველა პროქსის მოშორება, არამედ შევამციროთ ინტერვალები მრავალი შემოწმებისთვის და პროქსი აღარ იქნება საჭირო, როგორც დატვირთვის გაზიარების საშუალება.

დაახლოებით სამი თვის წინ

შეცვალეთ არქიტექტურა - გაზარდეთ დატვირთვა!

მმ: - კარგი, მაქს, დროა გახდე პროდუქტიული? მჭირდება ძლიერი სერვერი და კარგი ინჟინერი.

MCH: - კარგი, დავგეგმოთ. დროა გადავიდეთ მკვდარი წერტილიდან 5 ათასი მეტრი წამში.

დილა განახლების შემდეგ

MCH: -მიშა, განვაახლეთ, მაგრამ დილამდე უკან დავბრუნდით... გამოიცანით რა სიჩქარის მიღწევა მოვახერხეთ?

მმ: – მაქსიმუმ 20 ათასი.

MCH: - დიახ, 25! სამწუხაროდ, ჩვენ ზუსტად იქ ვართ, სადაც დავიწყეთ.

მმ: - რატომ? რაიმე დიაგნოსტიკა ჩაატარე?

MCH: - Კი, რა თქმა უნდა! აი, მაგალითად, საინტერესო ტოპი:

მმ: - Მოდი ვუყუროთ. მე ვხედავ, რომ ჩვენ გამოვცადეთ კენჭისყრის თემების დიდი რაოდენობა:

მაგრამ ამავე დროს მათ ვერ შეძლეს სისტემის გადამუშავება ნახევარზეც კი:

და საერთო შესრულება საკმაოდ მცირეა, დაახლოებით 4 ათასი მეტრი წამში:

Არის კიდევ რამე?

MCH: – დიახ, ერთ-ერთი გამოკითხვის კვალი:

მმ: – აქ ნათლად ჩანს, რომ კენჭისყრის პროცესი „სემფორებს“ ელოდება. ეს არის საკეტები:

MCH: - გაუგებარია.

მმ: – შეხედე, ეს ჰგავს სიტუაციას, როდესაც თაიგულები ცდილობენ იმუშაონ რესურსებით, რომლებთანაც ერთდროულად მხოლოდ ერთს შეუძლია მუშაობა. შემდეგ მათ შეუძლიათ მხოლოდ გააზიარონ ეს რესურსი დროთა განმავლობაში:

და ასეთ რესურსთან მუშაობის მთლიანი შესრულება შემოიფარგლება ერთი ბირთვის სიჩქარით:

ამ პრობლემის მოგვარების ორი გზა არსებობს.

განაახლეთ აპარატის აპარატურა, გადადით უფრო სწრაფ ბირთვებზე:

ან შეცვალეთ არქიტექტურა და ამავდროულად შეცვალეთ დატვირთვა:

MCH: – სხვათა შორის, სატესტო მანქანაზე გამოვიყენებთ ნაკლებ ბირთვს, ვიდრე საბრძოლოზე, მაგრამ ისინი 1,5-ჯერ უფრო სწრაფია სიხშირით ერთ ბირთვზე!

მმ: - გასაგებია? თქვენ უნდა ნახოთ სერვერის კოდი.

მონაცემთა ბილიკი Zabbix სერვერზე

MCH: – ამის გასარკვევად, დავიწყეთ იმის ანალიზი, თუ როგორ ხდება მონაცემების გადაცემა Zabbix სერვერის შიგნით:

მაგარი სურათია, არა? მოდით, ეტაპობრივად გავიაროთ, რომ მეტ-ნაკლებად ნათელი გახდეს. არსებობს თემები და სერვისები, რომლებიც პასუხისმგებელნი არიან მონაცემთა შეგროვებაზე:

ისინი გადასცემენ შეგროვებულ მეტრებს სოკეტის საშუალებით Preprocessor მენეჯერს, სადაც ისინი ინახება რიგში:

"პრეპროცესორის მენეჯერი" გადასცემს მონაცემებს თავის მუშაკებს, რომლებიც ასრულებენ წინასწარ დამუშავების ინსტრუქციებს და აბრუნებენ მათ იმავე სოკეტის მეშვეობით:

ამის შემდეგ, წინასწარი პროცესორის მენეჯერი ინახავს მათ ისტორიის ქეშში:

იქიდან მათ იღებენ ისტორიის სინკერები, რომლებიც ასრულებენ საკმაოდ ბევრ ფუნქციას: მაგალითად, ტრიგერების გამოთვლას, მნიშვნელობის ქეშის შევსებას და, რაც მთავარია, მეტრიკის შენახვას ისტორიის საცავში. ზოგადად, პროცესი რთული და ძალიან დამაბნეველია.

მმ: – პირველი, რაც ვნახეთ, იყო ის, რომ ძაფების უმეტესობა კონკურენციას უწევს ეგრეთ წოდებულ „კონფიგურაციის ქეში“ (მეხსიერების არე, სადაც ინახება სერვერის ყველა კონფიგურაცია). მონაცემთა შეგროვებაზე პასუხისმგებელი თემები განსაკუთრებით ბევრს ბლოკავს:

...რადგან კონფიგურაცია ინახავს არა მხოლოდ მეტრებს მათი პარამეტრებით, არამედ რიგები, საიდანაც გამოკითხულები იღებენ ინფორმაციას იმის შესახებ, თუ რა უნდა გააკეთონ შემდეგ. როდესაც ბევრი პოლერია და ერთი ბლოკავს კონფიგურაციას, დანარჩენები ელოდებიან მოთხოვნებს:

გამომძიებლები არ უნდა ეწინააღმდეგებოდნენ ერთმანეთს

ამიტომ, პირველი, რაც გავაკეთეთ, იყო რიგის 4 ნაწილად დაყოფა და გამომკითხავების ნება დართოთ დაბლოკონ ეს რიგები, ეს ნაწილები ამავე დროს, უსაფრთხო პირობებში:

ამან გააუქმა კონფიგურაციის ქეში კონკურენცია და პოლერების სიჩქარე მნიშვნელოვნად გაიზარდა. მაგრამ შემდეგ ჩვენ შევხვდით იმ ფაქტს, რომ წინასწარი პროცესორის მენეჯერმა დაიწყო სამუშაოების რიგის დაგროვება:

წინასწარი პროცესორის მენეჯერს უნდა შეეძლოს პრიორიტეტების განსაზღვრა

ეს ხდებოდა იმ შემთხვევებში, როდესაც მას აკლდა შესრულება. შემდეგ ყველაფერი, რაც მას შეეძლო, იყო მონაცემთა შეგროვების პროცესებიდან მოთხოვნების დაგროვება და მათი ბუფერის დამატება, სანამ ის არ მოიხმარდა მთელ მეხსიერებას და ავარიულად არ დაიშალა:

ამ პრობლემის გადასაჭრელად, ჩვენ დავამატეთ მეორე სოკეტი, რომელიც სპეციალურად მუშებს ეძღვნებოდა:

ამრიგად, წინასწარი პროცესორის მენეჯერს ჰქონდა შესაძლებლობა მიეცეს თავისი სამუშაოს პრიორიტეტი და, თუ ბუფერი იზრდება, ამოცანაა შეანელოს მოცილება, რაც მუშებს აძლევს შესაძლებლობას აიღონ ეს ბუფერი:

შემდეგ ჩვენ აღმოვაჩინეთ, რომ შენელების ერთ-ერთი მიზეზი თავად მუშები იყვნენ, რადგან ისინი ეჯიბრებოდნენ რესურსს, რომელიც სრულიად უმნიშვნელო იყო მათი სამუშაოსთვის. ჩვენ დავაფიქსირეთ ეს პრობლემა, როგორც შეცდომების გამოსწორება და ის უკვე მოგვარებულია Zabbix-ის ახალ ვერსიებში:

ჩვენ ვზრდით სოკეტების რაოდენობას - ვიღებთ შედეგს

გარდა ამისა, წინასწარი პროცესორის მენეჯერი თავად იქცა ბოსტნეულად, რადგან ეს არის ერთი ძაფი. იგი ეყრდნობოდა ძირითად სიჩქარეს, რაც მაქსიმალურ სიჩქარეს აძლევდა დაახლოებით 70 ათასი მეტრი წამში:

ამიტომ, ჩვენ გავაკეთეთ ოთხი, ოთხი კომპლექტი სოკეტებით, მუშები:

და ამან მოგვცა საშუალება გაგვეზარდა სიჩქარე დაახლოებით 130 ათას მეტრამდე:

ზრდის არაწრფივობა აიხსნება იმით, რომ გაჩნდა კონკურენცია ისტორიის ქეშისთვის. ამისთვის იბრძოდა 4 წინასწარი პროცესორის მენეჯერი და ისტორიის ჩაძირვა. ამ ეტაპზე ჩვენ ვიღებდით დაახლოებით 130 ათას მეტრს წამში სატესტო მანქანაზე, რომელსაც ვიყენებდით პროცესორის დაახლოებით 95%-ით:

დაახლოებით 2,5 თვის წინ

snmp-საზოგადოებიდან უარის თქმამ NVP-ები გაზარდა ერთნახევარჯერ

მმ: – მაქს, ახალი სატესტო მანქანა მჭირდება! ჩვენ აღარ ვჯდებით ახლანდელში.

MCH: -ახლა რა გაქვს?

მმ: – ახლა – 130 ათასი NVP და თაროზე მზა პროცესორი.

MCH: - Ვაუ! მაგარია! მოიცადე, ორი კითხვა მაქვს. ჩემი გათვლებით, ჩვენი საჭიროება არის დაახლოებით 15-20 ათასი მეტრი წამში. რატომ გვჭირდება მეტი?

მმ: ”მე მინდა დავასრულო სამუშაო.” მსურს ვნახო, რამდენის ამოღება შეგვიძლია ამ სისტემიდან.

MCH: -მაგრამ…

მმ: ”მაგრამ ეს უსარგებლოა ბიზნესისთვის.”

MCH: - Ნათელია. და მეორე კითხვა: შეგვიძლია თუ არა ხელი შევუწყოთ იმას, რაც ახლა გვაქვს დამოუკიდებლად, დეველოპერის დახმარების გარეშე?

მმ: - არა მგონია. კონფიგურაციის ქეშის მუშაობის წესის შეცვლა პრობლემაა. ის გავლენას ახდენს ცვლილებებზე უმეტეს ძაფებში და მისი შენარჩუნება საკმაოდ რთულია. დიდი ალბათობით, მისი შენარჩუნება ძალიან რთული იქნება.

MCH: ”მაშინ ჩვენ გვჭირდება რაიმე სახის ალტერნატივა.”

მმ: - არის ასეთი ვარიანტი. ჩვენ შეგვიძლია გადავიდეთ სწრაფ ბირთვებზე, ხოლო ახალ ჩაკეტვის სისტემაზე უარის თქმა. ჩვენ მაინც მივიღებთ 60-80 ათასი მეტრიკის შესრულებას. ამავდროულად, ჩვენ შეგვიძლია დავტოვოთ ყველა დანარჩენი კოდი. Clickhouse და ასინქრონული გამოკითხვა იმუშავებს. და ადვილი იქნება მისი შენარჩუნება.

MCH: - საოცარი! გირჩევთ აქ გავჩერდეთ.

სერვერის მხარის ოპტიმიზაციის შემდეგ, ჩვენ საბოლოოდ შევძელით ახალი კოდის წარმოებაში გაშვება. ჩვენ უარი თქვით ზოგიერთ ცვლილებაზე სწრაფი ბირთვების მქონე მანქანაზე გადასვლისა და კოდის ცვლილებების რაოდენობის მინიმიზაციის სასარგებლოდ. ჩვენ ასევე გავამარტივეთ კონფიგურაცია და გავაუქმეთ მაკროები მონაცემთა ერთეულებში, სადაც ეს შესაძლებელია, რადგან ისინი დამატებით ჩაკეტვას ახორციელებენ.

მაგალითად, snmp-community მაკროს მიტოვებამ, რომელიც ხშირად გვხვდება დოკუმენტაციასა და მაგალითებში, ჩვენს შემთხვევაში შესაძლებელი გახდა NVP-ების შემდგომი დაჩქარება დაახლოებით 1,5-ჯერ.

წარმოების ორი დღის შემდეგ

ინციდენტების ისტორიის ამომხტარი ფანჯრების წაშლა

MCH: – მიშა, ორი დღეა ვიყენებთ სისტემას და ყველაფერი მუშაობს. მაგრამ მხოლოდ მაშინ, როცა ყველაფერი მუშაობს! ჩვენ გვქონდა დაგეგმილი მუშაობა ქსელის საკმაოდ დიდი სეგმენტის გადაცემასთან დაკავშირებით და ისევ ჩვენი ხელით შევამოწმეთ რა ავიდა და რა არა.

მმ: - არ შეიძლება! ყველაფერი 10-ჯერ გადავამოწმეთ. სერვერი მყისიერად უმკლავდება ქსელის სრულ მიუწვდომლობასაც კი.

MCH: - დიახ, მე მესმის ყველაფერი: სერვერი, მონაცემთა ბაზა, ტოპი, აუსტატი, ლოგები - ყველაფერი სწრაფია... მაგრამ ჩვენ ვუყურებთ ვებ ინტერფეისს და სერვერზე არის პროცესორი "თაროზე" და ეს:

მმ: - Ნათელია. მოდით ვუყუროთ ინტერნეტს. ჩვენ აღმოვაჩინეთ, რომ იმ სიტუაციაში, როდესაც იყო აქტიური ინციდენტების დიდი რაოდენობა, ცოცხალი ვიჯეტების უმეტესობამ დაიწყო მუშაობა ძალიან ნელა:

ამის მიზეზი იყო ინციდენტების ისტორიის ამომხტარი ფანჯრების გენერაცია, რომლებიც იქმნება სიის თითოეული ელემენტისთვის. ამიტომ, ჩვენ მივატოვეთ ამ ფანჯრების გენერაცია (კოდში 5 სტრიქონი დავაფიქსირეთ) და ამან გადაჭრა ჩვენი პრობლემები.

ვიჯეტების ჩატვირთვის დრო, მაშინაც კი, როცა სრულიად მიუწვდომელია, შემცირდა რამდენიმე წუთიდან ჩვენთვის მისაღებ 10-15 წამამდე და ისტორიის ნახვა მაინც შესაძლებელია დროზე დაწკაპუნებით:

Სამუშაოს შემდეგ. 2 თვის წინ

MCH: -მიშა მიდიხარ? Უნდა ვილაპარაკოთ.

მმ: - მე არ ვაპირებდი. ისევ რამე Zabbix-თან?

MCH: - არა, დამშვიდდი! უბრალოდ მინდოდა მეთქვა: ყველაფერი მუშაობს, გმადლობთ! ლუდი მაქვს.

Zabbix ეფექტურია

Zabbix არის საკმაოდ უნივერსალური და მდიდარი სისტემა და ფუნქცია. ის შეიძლება გამოყენებულ იქნას მცირე ზომის ინსტალაციისთვის, მაგრამ საჭიროების ზრდასთან ერთად ის უნდა იყოს ოპტიმიზირებული. მეტრიკის დიდი არქივის შესანახად გამოიყენეთ შესაბამისი საცავი:

• შეგიძლიათ გამოიყენოთ ჩაშენებული ხელსაწყოები Elasticsearch-თან ინტეგრაციის ან ტექსტურ ფაილებში ისტორიის ატვირთვის სახით (ხელმისაწვდომია 4 ვერსიიდან);
• თქვენ შეგიძლიათ ისარგებლოთ ჩვენი გამოცდილებით და Clickhouse-თან ინტეგრაციით.

მეტრიკის შეგროვების სიჩქარის მკვეთრად გაზრდის მიზნით, შეაგროვეთ ისინი ასინქრონული მეთოდების გამოყენებით და გადასცეს ისინი ტრაპერ ინტერფეისის მეშვეობით Zabbix სერვერზე; ან შეგიძლიათ გამოიყენოთ პაჩი Zabbix პოლერების ასინქრონული გასაკეთებლად.

Zabbix დაწერილია C-ზე და საკმაოდ ეფექტურია. რამდენიმე არქიტექტურული შეფერხების გადაჭრა საშუალებას გაძლევთ კიდევ უფრო გაზარდოთ მისი შესრულება და, ჩვენი გამოცდილებით, მიიღოთ 100 ათასზე მეტი მეტრიკა ერთპროცესორულ მანქანაზე.

იგივე Zabbix პაჩი

მმ: - ორიოდე პუნქტი მინდა დავამატო. მთელი მიმდინარე ანგარიში, ყველა ტესტი, ნომრები მოცემულია იმ კონფიგურაციისთვის, რომელსაც ჩვენ ვიყენებთ. ჩვენ ახლა მისგან ვიღებთ დაახლოებით 20 ათას მეტრს წამში. თუ ცდილობთ გაიგოთ, იმუშავებს თუ არა ეს თქვენთვის, შეგიძლიათ შეადაროთ. ის, რაც დღეს განიხილებოდა, გამოქვეყნებულია GitHub-ზე პაჩის სახით: github.com/miklert/zabbix

პატჩი მოიცავს:

• სრული ინტეგრაცია Clickhouse-თან (როგორც Zabbix სერვერი, ასევე ფრონტენდი);
• პრობლემების გადაჭრა წინასწარ პროცესორის მენეჯერთან;
• ასინქრონული გამოკითხვა.

პატჩი თავსებადია ყველა ვერსიასთან 4, მათ შორის lts. სავარაუდოდ, მინიმალური ცვლილებებით ის იმუშავებს 3.4 ვერსიაზე.

დიდი მადლობა ყურადღებისთვის.

კითხვები

კითხვა აუდიტორიის მხრიდან (შემდგომში – A): – შუადღე მშვიდობისა! გთხოვთ, მითხარით, გაქვთ თუ არა გეგმები ინტენსიური ურთიერთობისთვის Zabbix-ის გუნდთან ან მათთან თქვენთან, რათა ეს არ იყოს პაჩი, არამედ Zabbix-ის ნორმალური ქცევა?

მმ: – დიახ, ჩვენ აუცილებლად განვახორციელებთ გარკვეულ ცვლილებებს. რაღაც მოხდება, რაღაც დარჩება პაჩში.

A: - დიდი მადლობა შესანიშნავი ანგარიშისთვის! გთხოვთ მითხრათ, პაჩის გამოყენების შემდეგ, Zabbix-ის მხარდაჭერა დარჩება და როგორ გავაგრძელოთ განახლება უფრო მაღალ ვერსიებზე? იქნება თუ არა შესაძლებელი Zabbix-ის განახლება თქვენი პაჩის შემდეგ 4.2, 5.0-ზე?

მმ: - მხარდაჭერაზე ვერაფერს ვიტყვი. მე რომ Zabbix ტექნიკური მხარდაჭერა ვიყო, ალბათ ვიტყოდი არა, რადგან ეს სხვისი კოდია. რაც შეეხება 4.2 კოდების ბაზას, ჩვენი პოზიცია ასეთია: „ჩვენ დროთა განმავლობაში გადავალთ და განვაახლებთ შემდეგ ვერსიაზე“. ამიტომ, გარკვეული პერიოდის განმავლობაში ჩვენ განვათავსებთ პატჩს განახლებული ვერსიებისთვის. ანგარიშში უკვე ვთქვი: ვერსიებთან ცვლილებების რაოდენობა ჯერ კიდევ საკმაოდ მცირეა. ვფიქრობ, 3.4-დან 4-ზე გადასვლას დაახლოებით 15 წუთი დაგვჭირდა, იქ რაღაც შეიცვალა, მაგრამ არც ისე მნიშვნელოვანი.

A: – მაშ, გეგმავთ თქვენი პაჩის მხარდაჭერას და შეგიძლიათ უსაფრთხოდ დააინსტალიროთ იგი წარმოებაში და მიიღოთ განახლებები მომავალში?

მმ: - ჩვენ მკაცრად გირჩევთ. ეს ბევრ პრობლემას გვიგვარებს.

MCH: – კიდევ ერთხელ მინდა გავამახვილო ყურადღება იმაზე, რომ ცვლილებები, რომლებიც არ ეხება არქიტექტურას და არ ეხება ბლოკირებას ან რიგებს, არის მოდულარული, ისინი ცალკე მოდულებშია. მცირე ცვლილებებითაც კი შეგიძლიათ მათი შენარჩუნება საკმაოდ მარტივად.

მმ: – თუ გაინტერესებთ დეტალები, მაშინ “Clickhouse” იყენებს ე.წ. ისტორიის ბიბლიოთეკას. ის იხსნება - ეს არის Elastics-ის საყრდენის ასლი, ანუ კონფიგურირებადია. კენჭისყრა ცვლის მხოლოდ გამოკითხულებს. ჩვენ გვჯერა, რომ ეს იმუშავებს დიდი ხნის განმავლობაში.

A: - Დიდი მადლობა. მითხარით, არის რაიმე დოკუმენტაცია ცვლილებების შესახებ?

მმ: – დოკუმენტაცია არის პაჩი. ცხადია, Clickhouse-ის დანერგვით, ახალი ტიპის პოლერების დანერგვით, ჩნდება კონფიგურაციის ახალი ვარიანტები. ბოლო სლაიდიდან ბმულს აქვს მოკლე აღწერა, თუ როგორ გამოიყენოთ იგი.

fping-ის nmap-ით ჩანაცვლების შესახებ

A: – საბოლოოდ როგორ განახორციელეთ ეს? შეგიძლიათ კონკრეტული მაგალითების მოყვანა: გაქვთ სტრაპერები და გარე დამწერლობა? რა მთავრდება ასე სწრაფად ჰოსტების ამხელა რაოდენობის შემოწმებაზე? როგორ აგროვებთ ამ მასპინძლებს? უნდა მივაწოდოთ ისინი როგორმე nmap-ისთვის, საიდანღაც ავიღოთ, ჩავდოთ, გავუშვათ რამე?..

მმ: - მაგარია. ძალიან სწორი კითხვაა! საქმე ამაშია. ჩვენ შევცვალეთ ბიბლიოთეკა (ICMP ping, Zabbix-ის ნაწილი) ICMP შემოწმებისთვის, სადაც მითითებულია პაკეტების რაოდენობა - ერთი (1) და კოდი ცდილობს გამოიყენოს nmap. ანუ ეს არის ზაბიქსის შიდა ნამუშევარი, რომელიც გახდა პინგერის შიდა ნამუშევარი. შესაბამისად, არ არის საჭირო ტრაპერის სინქრონიზაცია ან გამოყენება. ეს გაკეთდა შეგნებულად იმისთვის, რომ სისტემა ხელუხლებელი დარჩენილიყო და არ გვქონდეს საქმე ორი მონაცემთა ბაზის სისტემის სინქრონიზაციასთან: რა შევამოწმოთ, ატვირთოთ პოლერის საშუალებით და ჩვენი ატვირთვა გატეხილია?.. ეს ბევრად უფრო მარტივია.

A: – მარიონეტებზეც მუშაობს?

მმ: – კი, მაგრამ არ შევამოწმეთ. კენჭისყრის კოდი ერთნაირია როგორც Zabbix-ში, ასევე სერვერზე. უნდა იმუშაოს. კიდევ ერთხელ ხაზგასმით აღვნიშნავ: სისტემის მუშაობა ისეთია, რომ ჩვენ არ გვჭირდება პროქსი.

MCH: - სწორი პასუხია კითხვაზე: "რატომ გჭირდებათ პროქსი ასეთი სისტემით?" მხოლოდ NAT-ის ან რაიმე ნელი არხის მეშვეობით მონიტორინგის გამო...

A: – და თქვენ იყენებთ Zabbix-ს ალერტორად, თუ სწორად გავიგე. ან თქვენი გრაფიკა (სადაც არის არქივის ფენა) გადავიდა სხვა სისტემაში, როგორიცაა Grafana? ან არ იყენებთ ამ ფუნქციას?

მმ: - კიდევ ერთხელ ხაზს ვუსვამ: ჩვენ მივაღწიეთ სრულ ინტეგრაციას. ჩვენ ისტორიას ვასხამთ Clickhouse-ში, მაგრამ ამავდროულად შევცვალეთ php წინა ნაწილი. Php frontend მიდის Clickhouse-ში და აკეთებს ყველა გრაფიკას იქიდან. ამავდროულად, მართალი გითხრათ, ჩვენ გვაქვს ნაწილი, რომელიც აყალიბებს მონაცემებს სხვა გრაფიკული ჩვენების სისტემებში იმავე Clickhouse-დან, იგივე Zabbix-ის მონაცემებიდან.

MCH: – “გრაფანშიც”.

როგორ მიიღეს გადაწყვეტილებები რესურსების განაწილების შესახებ?

A: - გაუზიარე ცოტა შენი შიდა სამზარეულო. როგორ მიიღეს გადაწყვეტილება, რომ საჭირო იყო რესურსების გამოყოფა პროდუქტის სერიოზული გადამუშავებისთვის? ზოგადად, ეს არის გარკვეული რისკები. და გთხოვთ მითხრათ, იმ კონტექსტში, რომ თქვენ აპირებთ ახალი ვერსიების მხარდაჭერას: როგორ ამართლებს ეს გადაწყვეტილება მენეჯმენტის თვალსაზრისით?

მმ: - როგორც ჩანს, ისტორიის დრამა კარგად არ მოგვიყევი. ჩვენ აღმოვჩნდით სიტუაციაში, როდესაც რაღაც უნდა გაგვეკეთებინა და არსებითად წავედით ორი პარალელური გუნდით:

• ერთი იყო მონიტორინგის სისტემის გაშვება ახალი მეთოდების გამოყენებით: მონიტორინგი, როგორც სერვისი, ღია კოდის გადაწყვეტილებების სტანდარტული ნაკრები, რომელსაც ჩვენ ვათავსებთ და შემდეგ ვცდილობთ შევცვალოთ ბიზნეს პროცესი, რათა ვიმუშაოთ მონიტორინგის ახალ სისტემასთან.
• ამავდროულად, გვყავდა ენთუზიასტი პროგრამისტი, რომელიც ამას აკეთებდა (თავის შესახებ). ისე მოხდა, რომ მან მოიგო.

A: - და რა არის გუნდის ზომა?

MCH: -ის შენს წინაშეა.

A: – მაშ, როგორც ყოველთვის, გჭირდება ვნებიანი?

მმ: - არ ვიცი, რა არის ვნებიანი.

A: - ამ შემთხვევაში, როგორც ჩანს, თქვენ. დიდი მადლობა, საუცხოო ხართ.

მმ: - მადლობა.

Zabbix-ის პატჩების შესახებ

A: – სისტემისთვის, რომელიც იყენებს პროქსიებს (მაგალითად, ზოგიერთ განაწილებულ სისტემაში), შესაძლებელია თუ არა ადაპტირება და დაყენება, ვთქვათ, პოლერების, პროქსიების და ნაწილობრივ თავად Zabbix-ის წინასწარი პროცესორის ადაპტაცია და დაყენება; და მათი ურთიერთქმედება? შესაძლებელია თუ არა არსებული განვითარების ოპტიმიზაცია მრავალი პროქსის მქონე სისტემისთვის?

მმ: – ვიცი, რომ Zabbix სერვერი აწყობილია პროქსის გამოყენებით (კოდი შედგენილია და მიღებულია). ჩვენ არ გამოვცადეთ ეს წარმოებაში. მე არ ვარ დარწმუნებული ამაში, მაგრამ ვფიქრობ, რომ წინასწარი პროცესორის მენეჯერი არ არის გამოყენებული პროქსიში. პროქსის ამოცანაა აიღოს მეტრიკის ნაკრები Zabbix-დან, შეაერთოს ისინი (ასევე ჩაიწერს კონფიგურაციას, ადგილობრივ მონაცემთა ბაზას) და დაუბრუნოს Zabbix სერვერს. სერვერი თავად გააკეთებს წინასწარ დამუშავებას, როდესაც ის მიიღებს მას.

მარიონეტების მიმართ ინტერესი გასაგებია. ჩვენ შევამოწმებთ. ეს საინტერესო თემაა.

A: – იდეა ასეთი იყო: თუ თქვენ შეგიძლიათ დაალაგოთ პოლერები, შეგიძლიათ დაალაგოთ ისინი პროქსიზე და დააყენოთ ინტერაქცია სერვერთან, ხოლო წინასწარი პროცესორის ადაპტირება ამ მიზნებისთვის მხოლოდ სერვერზე.

მმ: - ვფიქრობ, ეს კიდევ უფრო მარტივია. თქვენ იღებთ კოდს, იყენებთ პატჩს, შემდეგ აკონფიგურირებთ მას ისე, როგორც გჭირდებათ - აგროვებთ პროქსი სერვერებს (მაგალითად, ODBC-ით) და ავრცელებთ შესწორებულ კოდს სისტემებში. საჭიროების შემთხვევაში - შეაგროვეთ პროქსი, სადაც საჭიროა - სერვერი.

A: – დიდი ალბათობით, არ მოგიწევთ პროქსი გადაცემის სერვერზე დამატებით გადატვირთვა?

MCH: - არა, სტანდარტულია.

მმ: – ფაქტობრივად, ერთ-ერთი იდეა არ ჟღერდა. ჩვენ ყოველთვის ვინარჩუნებდით ბალანსს იდეების აფეთქებასა და ცვლილებების რაოდენობასა და მხარდაჭერას შორის.

რამდენიმე რეკლამა 🙂

გმადლობთ, რომ დარჩით ჩვენთან. მოგწონთ ჩვენი სტატიები? გსურთ ნახოთ უფრო საინტერესო შინაარსი? მხარი დაგვიჭირეთ შეკვეთის განთავსებით ან მეგობრებისთვის რეკომენდაციით, ღრუბელი VPS დეველოპერებისთვის 4.99 დოლარიდან, საწყისი დონის სერვერების უნიკალური ანალოგი, რომელიც ჩვენ მიერ გამოგონილია თქვენთვის: მთელი სიმართლე VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps 19$-დან ან როგორ გავაზიარო სერვერი? (ხელმისაწვდომია RAID1 და RAID10-ით, 24 ბირთვამდე და 40 გბ-მდე DDR4).

Dell R730xd 2-ჯერ იაფია Equinix Tier IV მონაცემთა ცენტრში ამსტერდამში? Მხოლოდ აქ 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 ტელევიზორი $199-დან ნიდერლანდებში! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99-დან! Წაიკითხო რაღაცის შესახებ როგორ ავაშენოთ ინფრასტრუქტურის კორპუსი. კლასი Dell R730xd E5-2650 v4 სერვერების გამოყენებით 9000 ევროს ღირებულების პენი?

წყარო: www.habr.com