HighLoad++, Mikhail Makurov, Maxim Chernetsov (Intersvyaz): Zabbix, 100kNVPS एका सर्व्हरवर

पुढील हायलोड++ परिषद ६ आणि ७ एप्रिल २०२० रोजी सेंट पीटर्सबर्ग येथे आयोजित केली जाईल. तपशील आणि तिकिटे उपलब्ध आहेत. दुवा. हायलोड++ मॉस्को २०१८. मॉस्को हॉल. ९ नोव्हेंबर, दुपारी ३:०० वाजता. सारांश आणि सादरीकरण.

* देखरेख - ऑनलाइन आणि विश्लेषण.
* ZABBIX प्लॅटफॉर्मच्या मुख्य मर्यादा.
* विश्लेषण संचयन स्केलिंगसाठी उपाय.
* झब्बीक्स सर्व्हर ऑप्टिमायझेशन.
* UI ऑप्टिमायझेशन.
* ४० हजार एनव्हीपीएस पेक्षा जास्त भाराखाली सिस्टम चालवण्याचा अनुभव घ्या.
* थोडक्यात निष्कर्ष.

मिखाईल मकुरोव (यापुढे - एमएम): - सर्वांना नमस्कार!

मॅक्सिम चेरनेत्सोव्ह (यापुढे - एमसीएच): - शुभ दुपार!

एमएम: "मी मॅक्सिमची ओळख करून देतो. मॅक्स हा एक प्रतिभावान अभियंता आहे, माझ्या ओळखीचा सर्वोत्तम नेटवर्कर आहे. मॅक्सिम नेटवर्क आणि सेवा, त्यांचा विकास आणि ऑपरेशन यावर काम करतो."

एमसी: "मी तुम्हाला मिखाईलबद्दल सांगू इच्छितो. मिखाईल हा एक सी डेव्हलपर आहे. त्याने आमच्या कंपनीसाठी अनेक हाय-लोड ट्रॅफिक प्रोसेसिंग सोल्यूशन्स लिहिले आहेत. आम्ही युरल्समध्ये, चेल्याबिन्स्क या कठीण शहरात, इंटरस्वियाझ येथे राहतो आणि काम करतो. आम्ही १६ शहरांमधील दहा लाख लोकांना इंटरनेट आणि केबल टीव्ही सेवा प्रदान करतो."

एमएम: "आणि हे लक्षात घेण्यासारखे आहे की इंटरस्वियाझ हे केवळ एक प्रदाता नाही; ती एक आयटी कंपनी आहे. आमचे बहुतेक उपाय आमच्या आयटी विभागाद्वारे इन-हाऊस विकसित केले जातात."

उत्तरः ट्रॅफिक-प्रोसेसिंग सर्व्हरपासून ते कॉल सेंटर आणि मोबाईल अॅपपर्यंत, आयटी विभागात सध्या विविध कौशल्यांसह सुमारे ८० लोक आहेत.

झब्बीक्स आणि त्याच्या वास्तुकलेबद्दल

एमसी: - आता मी एक वैयक्तिक रेकॉर्ड प्रस्थापित करण्याचा प्रयत्न करेन आणि एका मिनिटात सांगेन की झब्बीक्स म्हणजे काय (यापुढे "झब्बीक्स" म्हणून संदर्भित).

झब्बीक्स स्वतःला एंटरप्राइझ-ग्रेड, आउट-ऑफ-द-बॉक्स मॉनिटरिंग सिस्टम म्हणून स्थान देते. ते जीवन सोपे करणारी अनेक वैशिष्ट्ये देते: प्रगत एस्केलेशन नियम, एकीकरण API, आणि होस्ट आणि मेट्रिक्सचे गटबद्धीकरण आणि ऑटो-डिस्कव्हरी. झब्बीक्समध्ये स्केलिंग टूल्स देखील समाविष्ट आहेत—प्रॉक्सी. झब्बीक्स ही एक ओपन-सोर्स सिस्टम आहे.

आर्किटेक्चरबद्दल थोडक्यात. त्यात तीन घटक आहेत असे म्हणता येईल:

• सर्व्हर. सी मध्ये लिहिलेले. ते थ्रेड्स दरम्यान बरीच जटिल प्रक्रिया आणि डेटा ट्रान्सफर हाताळते. डेटाबेस प्राप्त करण्यापासून ते सेव्ह करण्यापर्यंत सर्व प्रक्रिया त्यामध्ये होतात.
• सर्व डेटा डेटाबेसमध्ये संग्रहित केला जातो. झब्बीक्स MySQL, PostgreSQL आणि Oracle ला समर्थन देते.
• वेब इंटरफेस PHP मध्ये लिहिलेला आहे. बहुतेक सिस्टीम Apache सह येतात, परंतु ते Nginx आणि PHP सह अधिक प्रभावीपणे कार्य करते.

आज आपण आपल्या कंपनीच्या आयुष्यातील एक गोष्ट शेअर करू इच्छितो, जी झब्बीक्सशी संबंधित आहे...

इंटरस्वियाझच्या आयुष्यातील एक कथा. आपल्याकडे काय आहे आणि आपल्याला काय हवे आहे?

५-६ महिन्यांपूर्वी. कामानंतर एक दिवस...

एमसी: "मीशा, हाय! तुला वेळेवर ओळखून आनंद झाला - मला तुझ्याशी बोलायचे आहे. आम्हाला पुन्हा एकदा देखरेखीच्या समस्या येत आहेत. एका मोठ्या आउटेज दरम्यान, सर्वकाही मंदावले होते आणि नेटवर्क स्थितीबद्दल कोणतीही माहिती नव्हती. दुर्दैवाने, हे पहिल्यांदाच घडले नाही. मला तुमच्या मदतीची आवश्यकता आहे. कोणत्याही परिस्थितीत आमचे देखरेख काम करत आहे याची खात्री करूया!"

एमएम: "पण आधी सिंक करूया. मी गेल्या काही वर्षांपासून ते पाहिलेले नाही. मला आठवते तसे, आम्ही आठ वर्षांपूर्वी नागिओस सोडून झब्बीक्सवर स्विच केले. आणि आता, मला वाटते, आमच्याकडे सहा शक्तिशाली सर्व्हर आणि सुमारे एक डझन प्रॉक्सी आहेत. मी काही चुकवत आहे का?"

एमसी: – जवळजवळ. १५ सर्व्हर, त्यापैकी काही व्हर्च्युअल मशीन आहेत. सर्वात महत्त्वाची गोष्ट म्हणजे जेव्हा आपल्याला त्याची सर्वात जास्त गरज असते तेव्हा ते आपल्याला वाचवत नाही. जेव्हा क्रॅश होतो तेव्हा सर्व्हर मंदावतात आणि तुम्हाला काहीही दिसत नाही. आम्ही कॉन्फिगरेशन ऑप्टिमाइझ करण्याचा प्रयत्न केला, परंतु त्याने इष्टतम कामगिरी वाढवली नाही.

एमएम: - मी समजतो. तुम्ही काही पाहिले आहे का, निदानातून काही शोधून काढले आहे का?

एमसी: "आपल्याला सर्वात आधी डेटाबेस हाताळावा लागतो. MySQL सतत लोडखाली असते, नवीन मेट्रिक्स साठवत असते आणि जेव्हा झब्बीक्स अनेक इव्हेंट्स जनरेट करण्यास सुरुवात करते तेव्हा डेटाबेस काही तासांसाठी लॉकडाऊनमध्ये जातो. मी तुम्हाला कॉन्फिगरेशन ऑप्टिमायझेशनबद्दल आधीच सांगितले होते, परंतु या वर्षीच आम्ही हार्डवेअर अपग्रेड केले आहे: सर्व्हरमध्ये शंभरहून अधिक मेमरी आणि SSD RAID डिस्क अॅरे आहेत - ते रेषीयरित्या स्केल करणे आता अर्थपूर्ण नाही. आपण काय करणार आहोत?"

एमएम: "मला समजले. MySQL हा प्रत्यक्षात एक LTP डेटाबेस आहे. वरवर पाहता, तो आता आपल्या आकाराच्या मेट्रिक्स आर्काइव्हसाठी योग्य नाही. चला ते शोधूया."

एमसी: - चला!

हॅकेथॉनचा ​​परिणाम म्हणून झब्बीक्स आणि क्लिकहाऊस एकत्रीकरण

काही काळानंतर आम्हाला काही मनोरंजक डेटा मिळाला:

आमच्या डेटाबेसमधील बहुतेक जागा मेट्रिक्स आर्काइव्हने व्यापली होती आणि कॉन्फिगरेशन, टेम्पलेट्स आणि सेटिंग्जसाठी १% पेक्षा कमी जागा वापरली गेली. तोपर्यंत, आम्ही एका वर्षापेक्षा जास्त काळ क्लिकहाऊसवर आधारित बिग डेटा सोल्यूशन चालवत होतो. आमची दिशा स्पष्ट होती. आमच्या स्प्रिंग हॅकेथॉनमध्ये, मी सर्व्हर आणि फ्रंटएंडसाठी झब्बीक्स-क्लिकहाऊस इंटिग्रेशन लिहिले. त्या वेळी, झब्बीक्सने आधीच इलास्टिकसर्चला सपोर्ट केला होता, म्हणून आम्ही दोघांची तुलना करण्याचा निर्णय घेतला.

क्लिकहाऊस आणि इलास्टिकसर्चची तुलना

एमएम: तुलनेसाठी, आम्ही झब्बीक्स सर्व्हरने प्रदान केलेल्या लोडसारखेच लोड जनरेट केले आणि सिस्टम कसे कार्य करतील याचे निरीक्षण केले. आम्ही सीयूआरएल वापरून 1000 ओळींच्या बॅचमध्ये डेटा लिहिला. आम्हाला अंदाज होता की झब्बीक्स लोड प्रोफाइलसाठी क्लिकहाऊस अधिक कार्यक्षम असेल. निकालांनी आमच्या अपेक्षांपेक्षाही जास्त यश मिळवले:

समान चाचणी परिस्थितीत, क्लिकहाऊसने तिप्पट जास्त डेटा लिहिला. डेटा वाचताना दोन्ही सिस्टीम खूप कार्यक्षम (संसाधन-कार्यक्षम) होत्या. तथापि, लिहिताना इलास्टिक्सला लक्षणीय प्रमाणात CPU पॉवरची आवश्यकता होती:

एकंदरीत, क्लिकहाऊसने सीपीयू वापर आणि गतीमध्ये इलास्टिक्सला लक्षणीयरीत्या मागे टाकले. शिवाय, डेटा कॉम्प्रेशनमुळे, क्लिकहाऊस हार्ड ड्राइव्हवर ११ पट कमी जागा वापरते आणि सुमारे ३० पट कमी डिस्क ऑपरेशन्स करते:

एमसी: हो, क्लिकहाऊसची डिस्क सबसिस्टम खूप कार्यक्षम आहे. तुम्ही डेटाबेससाठी प्रचंड SATA ड्राइव्ह वापरू शकता आणि प्रति सेकंद लाखो ओळींचा लेखन वेग मिळवू शकता. ही प्रणाली बॉक्समधून शार्डिंग आणि प्रतिकृतीला समर्थन देते आणि कॉन्फिगर करणे खूप सोपे आहे. गेल्या एका वर्षापासून आम्ही त्याच्या ऑपरेशनवर समाधानी आहोत.

संसाधने ऑप्टिमाइझ करण्यासाठी, तुम्ही तुमच्या विद्यमान मुख्य डेटाबेसच्या शेजारी क्लिकहाऊस स्थापित करू शकता, ज्यामुळे CPU वेळ आणि डिस्क ऑपरेशन्सची लक्षणीय बचत होते. आम्ही मेट्रिक्स संग्रह विद्यमान क्लिकहाऊस क्लस्टर्समध्ये हलवला आहे:

आम्ही मुख्य MySQL डेटाबेस इतका अनलोड केला की आम्ही तो एका मशीनवर झब्बीक्स सर्व्हरसह एकत्र करू शकलो आणि समर्पित MySQL सर्व्हर काढून टाकू शकलो.

झब्बीक्समध्ये मतदान कसे काम करते?

4 महिन्यांपूर्वी

एमएम: - बरं, आपण बेसमधील समस्या विसरू शकतो का?

एमसी: "बरोबर आहे! आपल्याला सोडवायची असलेली आणखी एक समस्या म्हणजे डेटा संकलनाची गती कमी आहे. आता आमचे सर्व १५ प्रॉक्सी सर्व्हर SNMP आणि मतदान प्रक्रियेने ओव्हरलोड झाले आहेत. आणि अधिक सर्व्हर जोडत राहण्याशिवाय दुसरा पर्याय नाही."

एमएम: - उत्तम. पण आधी मला सांगा की झब्बीक्समध्ये मतदान कसे चालते?

एमसी: थोडक्यात, २० प्रकारचे मेट्रिक्स आहेत आणि ते मिळवण्याचे डझनभर मार्ग आहेत. झब्बीक्स रिक्वेस्ट-रिस्पॉन्स मोडमध्ये डेटा गोळा करू शकतो किंवा ट्रॅपर इंटरफेसद्वारे नवीन डेटाची वाट पाहू शकतो.

हे लक्षात घेण्यासारखे आहे की मूळ झब्बीक्समध्ये ही पद्धत (ट्रॅपर) सर्वात वेगवान आहे.

लोड बॅलेंसिंगसाठी प्रॉक्सी सर्व्हर आहेत:

प्रॉक्सी हे झब्बीक्स सर्व्हर प्रमाणेच कलेक्शन फंक्शन्स करू शकतात, त्यातून टास्क प्राप्त करू शकतात आणि ट्रॅपर इंटरफेसद्वारे कलेक्शन मेट्रिक्स पाठवू शकतात. लोड बॅलन्सिंगची ही अधिकृतपणे शिफारस केलेली पद्धत आहे. NAT च्या मागे किंवा स्लो लिंकवरून चालणाऱ्या रिमोट इन्फ्रास्ट्रक्चरचे निरीक्षण करण्यासाठी देखील प्रॉक्सी उपयुक्त आहेत:

एमएम: – आर्किटेक्चर स्पष्ट आहे. आपल्याला सोर्स कोड पाहण्याची गरज आहे...

काही दिवसांनी

Nmap Fped कसे जिंकले याची कहाणी

एमएम: - मला वाटतं मी काहीतरी खोदलं.

एमसी: - मला सांग!

एमएम: "मला आढळले की झब्बीक्सच्या उपलब्धता तपासणीमध्ये एकाच वेळी जास्तीत जास्त १२८ होस्ट तपासले जातात. मी ही संख्या ५०० पर्यंत वाढवण्याचा आणि त्यांच्या पिंगमधील इंटर-पॅकेट इंटरव्हल काढून टाकण्याचा प्रयत्न केला - यामुळे कामगिरी दुप्पट झाली. पण मला जास्त संख्या पहायची आहे."

एमसी: "माझ्या प्रॅक्टिसमध्ये, मला कधीकधी हजारो होस्टची उपलब्धता तपासावी लागते आणि यासाठी मी nmap पेक्षा वेगवान काहीही पाहिले नाही. मला खात्री आहे की ही सर्वात वेगवान पद्धत आहे. चला ते वापरून पाहूया! आपल्याला एकाच पुनरावृत्तीमध्ये होस्टची संख्या लक्षणीयरीत्या वाढवायची आहे."

एमएम: – पाचशेपेक्षा जास्त चेक? ६००?

एमसी: - किमान दोन हजार.

एमएम: "ठीक आहे. मला सांगायचे होते ते म्हणजे झब्बीक्समधील बहुतेक मतदान समकालिक पद्धतीने केले जाते असे मला आढळले. आपल्याला ते असिंक्रोनस मोडमध्ये रूपांतरित करावे लागेल. मग आपण पोलर्सद्वारे गोळा केलेल्या मेट्रिक्सची संख्या नाटकीयरित्या वाढवू शकतो, विशेषतः जर आपण प्रत्येक पुनरावृत्तीच्या मेट्रिक्सची संख्या वाढवली तर."

एमसी: - छान! आणि कधी?

एमएम: - नेहमीप्रमाणे, काल.

एमसी: - आम्ही fping आणि nmap च्या दोन्ही आवृत्त्यांची तुलना केली:

अपेक्षेप्रमाणे, मोठ्या संख्येने होस्टवर nmap पाच पट अधिक कार्यक्षम होते. nmap फक्त उपलब्धता आणि प्रतिसाद वेळ तपासत असल्याने, आम्ही नुकसान गणना ट्रिगरवर हलवली आणि उपलब्धता तपासणी मध्यांतर लक्षणीयरीत्या कमी केले. आम्हाला nmap साठी होस्टची इष्टतम संख्या प्रति पुनरावृत्ती सुमारे 4 आढळली. Nmap ने आम्हाला उपलब्धता तपासणीसाठी CPU वापर तीन घटकांनी कमी करण्याची आणि मध्यांतर 120 सेकंदांवरून 10 पर्यंत कमी करण्याची परवानगी दिली.

मतदान ऑप्टिमायझेशन

एमएम: "मग आम्ही पोलर्सकडे वळलो. आम्हाला प्रामुख्याने SNMP पोलिंग आणि एजंट्समध्ये रस होता. झब्बीक्समध्ये, पोलिंग सिंक्रोनस असते आणि सिस्टम कार्यक्षमता वाढवण्यासाठी विशेष उपाययोजना केल्या जातात. सिंक्रोनस मोडमध्ये, होस्ट अनुपलब्धतेमुळे मतदानात लक्षणीय घट होते. विशेष प्रक्रियांसह राज्यांची एक संपूर्ण प्रणाली आहे - तथाकथित अप्राप्य पोलर्स - जी केवळ अप्राप्य होस्टसह कार्य करते:

ही टिप्पणी स्थिती मॅट्रिक्स आणि प्रणाली कार्यक्षम राहण्यासाठी आवश्यक असलेल्या संक्रमण प्रणालीची जटिलता दर्शवते. शिवाय, समकालिक मतदान स्वतःच खूपच मंद आहे:

म्हणूनच डझनभर प्रॉक्सींवरील हजारो पोलर थ्रेड्स आमच्यासाठी आवश्यक प्रमाणात डेटा गोळा करू शकले नाहीत. असिंक्रोनस अंमलबजावणीने केवळ थ्रेड काउंटची समस्या सोडवली नाही तर अनुपलब्ध होस्ट स्टेटस सिस्टम देखील लक्षणीयरीत्या सुलभ केली, कारण एकाच पोलिंग पुनरावृत्तीमध्ये तपासलेल्या कोणत्याही होस्टसाठी, जास्तीत जास्त प्रतीक्षा वेळ एक टाइमआउट होता:

आम्ही SNMP पोलिंग सिस्टीममध्येही बदल आणि सुधारणा केल्या आहेत. बहुतेक होस्ट एकाच वेळी अनेक SNMP विनंत्यांना प्रतिसाद देऊ शकत नाहीत. म्हणून, आम्ही एक हायब्रिड मोड लागू केला आहे, जिथे एकाच होस्टचे SNMP पोलिंग असिंक्रोनसपणे केले जाते:

हे संपूर्ण होस्ट ग्रुपसाठी केले जाते. हा मोड शेवटी पूर्णपणे असिंक्रोनस मोडपेक्षा हळू नाही, कारण १५० SNMP मूल्यांचे मतदान अजूनही एकाच टाइमआउटपेक्षा खूप वेगवान आहे.

आमच्या प्रयोगांमधून असे दिसून आले की SNMP पोलिंगसाठी प्रति पुनरावृत्ती विनंत्यांची इष्टतम संख्या अंदाजे 8 आहे. एकंदरीत, असिंक्रोनस मोडवर स्विच केल्याने आम्हाला मतदान कामगिरी 200 किंवा अनेक शंभर पट वाढवता आली.

एमसी: - परिणामी मतदान ऑप्टिमायझेशनवरून असे दिसून आले की आम्ही केवळ सर्व प्रॉक्सी काढून टाकू शकत नाही, तर अनेक तपासणीसाठी मध्यांतर देखील कमी करू शकतो, ज्यामुळे लोड वितरित करण्यासाठी प्रॉक्सी अनावश्यक बनतात.

सुमारे तीन महिन्यांपूर्वी

वास्तुकला बदला - भार वाढवा!

एमएम: "मग, मॅक्स, आता उत्पादक होण्याची वेळ आली आहे का? मला एक शक्तिशाली सर्व्हर आणि एक चांगला अभियंता हवा आहे."

एमसी: "ठीक आहे, आपण त्याचे नियोजन करू. ५,००० मेट्रिक्स प्रति सेकंद वेगाने काम सुरू करण्याची वेळ आली आहे."

अपग्रेड नंतर सकाळी

एमसी: - मीशा, आम्ही अपडेट केले, पण सकाळपर्यंत आम्ही परत खाली आलो होतो... अंदाज लावा आम्ही किती वेग गाठण्यात यशस्वी झालो?

एमएम: - जास्तीत जास्त २० हजार.

एमसी: - हो, २५! दुर्दैवाने, आपण जिथे सुरुवात केली होती तिथेच परत आलो आहोत.

एमएम: - काय झालं? त्यांनी काही निदान चाचण्या केल्या का?

एमसी: - हो, नक्कीच! उदाहरणार्थ, येथे एक मनोरंजक शीर्ष आहे:

एमएम: – चला एक नजर टाकूया. मला दिसते की आपण मोठ्या संख्येने मतदान प्रवाह वापरून पाहिले आहेत:

परंतु त्यांना प्रणालीचा अर्धा भागही वापरता आला नाही:

आणि एकूण कामगिरी खूपच कमी आहे, प्रति सेकंद सुमारे ४ हजार मेट्रिक्स:

अजून काही आहे का?

एमसी: - हो, एका पोलरचा स्ट्रेस:

एमएम: – येथे तुम्ही स्पष्टपणे पाहू शकता की मतदान प्रक्रिया "सेमाफोर्स" ची वाट पाहत आहे. हे कुलूप आहेत:

एमसी: - हे स्पष्ट नाही.

एमएम: "हे बघा, ही अशी परिस्थिती आहे जिथे अनेक थ्रेड्स अशा संसाधनावर काम करण्याचा प्रयत्न करत आहेत ज्यावर एका वेळी फक्त एकच थ्रेड काम करू शकतो. मग ते फक्त त्या संसाधनाचा वेळ-सामायिकरण करू शकतात:"

आणि अशा संसाधनासह काम करण्याची एकूण कामगिरी एका कोरच्या गतीने मर्यादित आहे:

ही समस्या सोडवण्याचे दोन मार्ग आहेत.

तुमच्या मशीनचे हार्डवेअर अपग्रेड करा आणि वेगवान कोरवर स्विच करा:

किंवा आर्किटेक्चर आणि समांतरपणे, भार बदला:

एमसी: - तसे, आम्ही उत्पादन मशीनपेक्षा चाचणी मशीनवर कमी कोर चालवणार आहोत, परंतु ते प्रति कोर वारंवारतेच्या बाबतीत 1,5 पट वेगवान आहेत!

एमएम: - समजले? आपल्याला सर्व्हर कोड पाहण्याची गरज आहे.

झब्बीक्स सर्व्हरमधील डेटा पथ

एमसी: - हे समजून घेण्यासाठी, आम्ही झब्बीक्स सर्व्हरमध्ये डेटा कसा हस्तांतरित केला जातो याचे विश्लेषण करण्यास सुरुवात केली:

खूपच छान चित्र आहे ना? ते थोडे स्पष्ट करण्यासाठी आपण ते टप्प्याटप्प्याने पाहूया. डेटा गोळा करण्यासाठी जबाबदार असलेले स्ट्रीम आणि सेवा आहेत:

गोळा केलेले मेट्रिक्स सॉकेटद्वारे प्रीप्रोसेसर मॅनेजरकडे पाठवले जातात, जिथे ते एका रांगेत साठवले जातात:

"प्रीप्रोसेसर मॅनेजर" त्याच्या कामगारांना डेटा पाठवतो, जे प्रीप्रोसेसिंग सूचना अंमलात आणतात आणि त्याच सॉकेटद्वारे त्या परत करतात:

यानंतर, प्रीप्रोसेसर मॅनेजर त्यांना इतिहास कॅशेमध्ये संग्रहित करतो:

तिथून, ते इतिहास सिंकर्सद्वारे पुनर्प्राप्त केले जातात, जे विस्तृत कार्ये करतात: उदाहरणार्थ, ट्रिगर्सची गणना करणे, मूल्य कॅशे भरणे आणि सर्वात महत्त्वाचे म्हणजे, इतिहास स्टोअरमध्ये मेट्रिक्स संग्रहित करणे. एकंदरीत, ही प्रक्रिया गुंतागुंतीची आणि गोंधळात टाकणारी आहे.

एमएम: – आम्हाला पहिली गोष्ट लक्षात आली की बहुतेक थ्रेड्स तथाकथित "कॉन्फिगरेशन कॅशे" (मेमरी क्षेत्र जिथे सर्व सर्व्हर कॉन्फिगरेशन संग्रहित केले जातात) साठी स्पर्धा करत होते. डेटा पुनर्प्राप्तीसाठी जबाबदार असलेले थ्रेड्स विशेषतः ब्लॉक होण्याची शक्यता असते:

...कारण कॉन्फिगरेशन केवळ मेट्रिक्स आणि त्यांचे पॅरामीटर्सच साठवत नाही, तर ज्या रांगामधून पोलर्स पुढे काय करायचे याबद्दल माहिती मिळवतात त्या देखील साठवतात. जेव्हा बरेच पोलर्स असतात आणि एक कॉन्फिगरेशन लॉक करतो, तेव्हा इतर विनंत्यांची वाट पाहत असतात:

पोलर्सनी संघर्ष करू नये

म्हणून आम्ही पहिली गोष्ट केली ती म्हणजे रांगेचे चार भाग केले आणि पोलरना हे भाग एकाच वेळी सुरक्षितपणे ब्लॉक करण्याची परवानगी दिली:

यामुळे कॉन्फिगरेशन कॅशेसाठी स्पर्धा संपली आणि पोलरची कामगिरी लक्षणीयरीत्या वाढली. पण नंतर आम्हाला प्रीप्रोसेसर मॅनेजरमध्ये एक समस्या आली, ज्यामुळे कामांची रांग जमा होऊ लागली:

प्रीप्रोसेसर मॅनेजरला प्राधान्य देण्यास सक्षम असणे आवश्यक आहे

जेव्हा त्याची कार्यक्षमता संपली तेव्हा हे घडले. त्यानंतर, ते फक्त डेटा संकलन प्रक्रियांमधून विनंत्या गोळा करू शकत होते आणि त्यांचे बफर स्टॅक करू शकत होते जोपर्यंत त्याची सर्व मेमरी संपत नाही आणि क्रॅश होत नाही:

या समस्येचे निराकरण करण्यासाठी, आम्ही दुसरे सॉकेट जोडले जे विशेषतः कामगारांसाठी समर्पित होते:

अशाप्रकारे, प्रीप्रोसेसर मॅनेजरला त्याच्या कामाला प्राधान्य देण्याची आणि जर बफर वाढला तर पुनर्प्राप्ती कमी करण्याची संधी देण्यात आली, ज्यामुळे कामगारांना हा बफर घेण्याची संधी मिळाली:

त्यानंतर आम्हाला आढळले की मंदीचे एक कारण म्हणजे कामगार स्वतः होते, कारण ते त्यांच्या कामासाठी पूर्णपणे असंबद्ध असलेल्या संसाधनासाठी स्पर्धा करत होते. आम्ही या समस्येसाठी एक बग फिक्स जारी केला आहे आणि झब्बीक्सच्या नवीन आवृत्त्यांमध्ये ते आधीच सोडवले गेले आहे:

आम्ही सॉकेट्सची संख्या वाढवतो आणि निकाल मिळवतो

त्यानंतर प्रीप्रोसेसर मॅनेजर स्वतःच एक अडथळा बनला, कारण तो एकच धागा होता. तो कोरच्या गतीने मर्यादित होता, ज्यामुळे प्रति सेकंद अंदाजे ७०,००० मेट्रिक्सचा कमाल थ्रूपुट मिळत असे:

म्हणून आम्ही चार कामगार बनवले, चार सॉकेटचे संच असलेले:

आणि यामुळे आम्हाला अंदाजे १३० हजार मेट्रिक्सपर्यंत वेग वाढवता आला:

हिस्ट्री कॅशेसाठी स्पर्धेच्या उदयामुळे नॉनलाइनर वाढ स्पष्ट होते. चार प्रीप्रोसेसर मॅनेजर आणि हिस्ट्री सिंकर्सनी त्यासाठी स्पर्धा केली. या टप्प्यापर्यंत, आम्हाला चाचणी मशीनवर प्रति सेकंद अंदाजे १३०,००० मेट्रिक्स मिळत होते, जे अंदाजे ९५% CPU वापरत होते:

सुमारे २.५ महिन्यांपूर्वी

snmp-समुदायाच्या त्यागामुळे NVPs मध्ये दीड पट वाढ झाली.

एमएम: "मॅक्स, मला एक नवीन चाचणी वाहन हवे आहे! आता आपण सध्याच्या वाहनात बसू शकत नाही."

एमसी: - आता तिथे काय आहे?

एमएम: - आता - १३० हजार एनव्हीपी आणि एक प्रोसेसर "शेल्फमध्ये".

एमसी: – व्वा! छान! थांबा, माझे दोन प्रश्न आहेत. माझ्या गणनेनुसार, आपली गरज प्रति सेकंद सुमारे १५-२० हजार मेट्रिक्स आहे. आपल्याला जास्त का हवे आहे?

एमएम: "मला हे सगळं नीट बघायचं आहे. या व्यवस्थेतून आपण किती बाहेर पडू शकतो ते मला बघायचं आहे."

एमसी: - पण…

एमएम: - पण ते व्यवसायासाठी निरुपयोगी आहे.

एमसी: - मला समजले. आणि दुसरा प्रश्न: विकासकाच्या मदतीशिवाय आपण आता जे आहे ते स्वतंत्रपणे राखू शकू का?

एमएम: "मला तसं वाटत नाही. कॉन्फिगरेशन कॅशे कसे काम करते ते बदलणे ही एक समस्या आहे. बहुतेक थ्रेड्समधील बदलांवर त्याचा परिणाम होतो आणि ते समर्थन देणे खूप कठीण आहे. ते राखणे खूप कठीण असण्याची शक्यता आहे."

एमसी: - मग आपल्याला काही पर्याय हवा आहे.

एमएम: "एक पर्याय आहे. नवीन लॉकिंग सिस्टीम सोडून आपण वेगवान कोरवर अपग्रेड करू शकतो. आपल्याला अजूनही ६०,०००-८०,००० मेट्रिक्सचा थ्रूपुट मिळेल. आपण इतर सर्व कोड ठेवू शकतो. क्लिकहाऊस आणि असिंक्रोनस पोलिंग अजूनही काम करतील. आणि ते राखणे सोपे होईल."

एमसी: - छान! मी सुचवतो की आपण इथेच थांबूया.

सर्व्हर साइड ऑप्टिमाइझ केल्यानंतर, आम्ही शेवटी नवीन कोड उत्पादनात लाँच करू शकलो. वेगवान कोर असलेल्या मशीनवर स्थलांतरित करण्यासाठी आणि कोड बदलांची संख्या कमी करण्यासाठी आम्ही काही बदल रद्द केले. आम्ही कॉन्फिगरेशन देखील सोपे केले आणि शक्य असल्यास, डेटा घटकांमधील मॅक्रो काढून टाकले, कारण ते अतिरिक्त लॉकचे स्रोत होते.

उदाहरणार्थ, snmp-community मॅक्रो काढून टाकल्याने, जे बहुतेकदा दस्तऐवजीकरण आणि उदाहरणांमध्ये आढळते, आमच्या बाबतीत आम्हाला NVPs ला अंदाजे 1,5 पटीने वाढवता आली.

उत्पादन सुरू झाल्यानंतर दोन दिवसांनी

घटनेच्या इतिहासाचे पॉप-अप काढून टाकत आहे

एमसी: "मीशा, आम्ही गेल्या दोन दिवसांपासून सिस्टम वापरत आहोत आणि सगळं काम करतंय. पण सगळं काम करतं तेव्हाच! एका मोठ्या नेटवर्क सेगमेंटला मायग्रेट करण्यासाठी आम्ही देखभालीचे वेळापत्रक आखले होते आणि काय काम करतंय आणि काय नाही हे आम्ही पुन्हा मॅन्युअली तपासलं."

एमएम: "असं असू शकत नाही! आम्ही सगळं दहा वेळा तपासलं आहे. संपूर्ण नेटवर्क आउटेज देखील सर्व्हर त्वरित हाताळतो."

एमसी: – हो, मला सगळं समजतं: सर्व्हर, डेटाबेस, टॉप, ऑस्टॅट, लॉग्स – सगळं फास्ट आहे… पण आपण वेब इंटरफेस पाहतो, आणि सर्व्हरवर “शेल्फमध्ये” एक प्रोसेसर आहे आणि हे:

एमएम: – समजले. चला वेबवर एक नजर टाकूया. आम्हाला आढळले की ज्या परिस्थितीत मोठ्या संख्येने सक्रिय घटना घडतात, बहुतेक कार्यरत विजेट्स खूप हळू चालायला लागतात:

याचे कारण म्हणजे घटना इतिहास पॉप-अप्सची निर्मिती, जी यादीतील प्रत्येक आयटमसाठी तयार केली जाते. म्हणून, आम्ही हे पॉप-अप्स बंद केले (कोडच्या पाच ओळींवर टिप्पणी दिली), आणि यामुळे आमच्या समस्या सुटल्या.

पूर्णपणे अनुपलब्ध असतानाही, विजेट लोडिंग वेळ काही मिनिटांवरून १०-१५ सेकंदांपर्यंत कमी करण्यात आला आहे आणि वेळेवर क्लिक करून इतिहास अजूनही पाहता येतो:

कामानंतर. २ महिन्यांपूर्वी

एमसी: - मीशा, तू जात आहेस का? मला काहीतरी बोलायचे आहे.

एमएम: - मी ते प्लॅन केले नव्हते. झब्बीक्ससोबत पुन्हा काही?

एमसी: - नाही, आराम करा! मला फक्त एवढेच म्हणायचे होते: सर्वकाही ठीक आहे, धन्यवाद! बिअर माझ्याकडे आहे.

झब्बीक्स कार्यक्षम आहे.

झब्बीक्स ही एक बहुमुखी आणि वैशिष्ट्यपूर्ण प्रणाली आहे. ती लहान आउट-ऑफ-द-बॉक्स इंस्टॉलेशनसाठी पूर्णपणे वापरण्यायोग्य आहे, परंतु गरजा वाढत असताना, ती ऑप्टिमाइझ करणे आवश्यक आहे. मेट्रिक्सचा मोठा संग्रह संग्रहित करण्यासाठी, योग्य स्टोरेज सोल्यूशन वापरा:

• तुम्ही बिल्ट-इन टूल्स वापरू शकता जसे की Elastisearch सह एकत्रीकरण किंवा टेक्स्ट फाइल्समध्ये इतिहास निर्यात करणे (आवृत्ती ४ पासून उपलब्ध);
• तुम्ही आमच्या अनुभवाचा आणि क्लिकहाऊससोबतच्या एकत्रीकरणाचा फायदा घेऊ शकता.

मेट्रिक संकलनाची गती नाटकीयरित्या वाढवण्यासाठी, त्यांना असिंक्रोनस पद्धतीने गोळा करा आणि ट्रॅपर इंटरफेसद्वारे झब्बीक्स सर्व्हरवर प्रसारित करा; किंवा तुम्ही झब्बीक्स पोलर असिंक्रोनिक करण्यासाठी पॅच वापरू शकता.

झब्बीक्स हे सी मध्ये लिहिलेले आहे आणि ते खूप कार्यक्षम आहे. अनेक आर्किटेक्चरल अडथळ्यांना तोंड दिल्यास कामगिरीत आणखी सुधारणा करता येतात, ज्यामुळे आम्हाला आमच्या अनुभवानुसार, एका सिंगल-प्रोसेसर मशीनवर १००,००० पेक्षा जास्त मेट्रिक्स मिळू शकतात.

तोच झब्बीक्स पॅच

एमएम: मी काही मुद्दे जोडू इच्छितो. हा संपूर्ण अहवाल, सर्व चाचण्या आणि आकडे आम्ही वापरत असलेल्या कॉन्फिगरेशनवर आधारित आहेत. आम्ही सध्या प्रति सेकंद अंदाजे २०,००० मेट्रिक्स गोळा करत आहोत. जर तुम्ही हे तुमच्यासाठी काम करेल का हे शोधण्याचा प्रयत्न करत असाल, तर तुम्ही तुलना करू शकता. आज ज्याची चर्चा झाली ती GitHub वर पॅच म्हणून उपलब्ध आहे: github.com/miklert/zabbix

पॅचमध्ये हे समाविष्ट आहे:

• क्लिकहाऊससह पूर्ण एकात्मता (झब्बिक्स सर्व्हर आणि फ्रंटएंड दोन्ही);
• प्रीप्रोसेसर मॅनेजरसह समस्या सोडवणे;
• असिंक्रोनस मतदान.

हा पॅच आवृत्ती ४ च्या सर्व आवृत्त्यांशी सुसंगत आहे, ज्यामध्ये LTS देखील समाविष्ट आहे. तो किरकोळ बदलांसह आवृत्ती ३.४ सह कार्य करेल.

आपल्या लक्ष दिल्याबद्दल धन्यवाद.

प्रश्न

प्रेक्षकांकडून प्रश्न (यापुढे "अ" म्हणून संदर्भित): शुभ दुपार! कृपया मला सांगा, झब्बीक्स टीम किंवा त्यांच्यासोबत सघन सहकार्याची तुमची काही योजना आहे का, जेणेकरून हे पॅच नसून सामान्य झब्बीक्स वर्तन असेल याची खात्री करता येईल?

एमएम: – हो, आम्ही निश्चितच काही बदल करू. काही जोडले जातील आणि काही पॅचमध्ये राहतील.

उत्तरः उत्तम अहवालाबद्दल खूप खूप धन्यवाद! पॅच लागू केल्यानंतर झब्बीक्स सपोर्ट राहील का आणि मी उच्च आवृत्त्यांमध्ये अपडेट कसे सुरू ठेवू शकतो हे मला सांगाल का? तुमच्या पॅचनंतर झब्बीक्स ४.२ किंवा ५.० वर अपडेट करणे शक्य होईल का?

एमएम: "मी सपोर्टबद्दल बोलू शकत नाही. जर मी झब्बीक्सचा टेक सपोर्ट असतो, तर मी कदाचित नाही म्हणेन, कारण तो दुसऱ्या कोणाचा तरी कोड आहे. ४.२ कोडबेसबद्दल, आमची भूमिका अशी आहे की, 'आम्ही त्यासोबत पुढे जाऊ आणि पुढील आवृत्तीसह स्वतःला अपडेट करू.' तर, काही काळासाठी, आम्ही अपडेटेड आवृत्त्यांसाठी पॅचेस रिलीज करणार आहोत. मी आधीच अहवालात नमूद केले आहे: आवृत्त्यांमधील बदलांची संख्या अजूनही खूपच कमी आहे. मला वाटते की ३.४ ते ४ पर्यंत संक्रमण होण्यास आम्हाला सुमारे १५ मिनिटे लागली. तिथे काही गोष्टी बदलल्या, पण काहीही मोठे झाले नाही."

उत्तरः – तर तुम्ही तुमच्या पॅचला सपोर्ट करण्याची योजना आखत आहात आणि भविष्यात ते आत्मविश्वासाने उत्पादनात तैनात करू शकाल, काही प्रकारे अपडेट्स प्राप्त करू शकाल?

एमएम: "आम्ही त्याची जोरदार शिफारस करतो. ते आमच्यासाठी अनेक समस्या सोडवते."

एमसी: – मी पुन्हा एकदा हे अधोरेखित करू इच्छितो की आर्किटेक्चर किंवा लॉक किंवा क्यूजवर परिणाम न करणारे बदल मॉड्यूलर असतात, ते वेगवेगळ्या मॉड्यूलमध्ये असतात. किरकोळ बदल करूनही, ते अगदी सहजपणे स्वतंत्रपणे राखता येतात.

एमएम: जर तुम्हाला तपशीलांमध्ये रस असेल तर, क्लिकहाऊस इतिहास लायब्ररी वापरते. ते डीकपल्ड आहे—ते इलास्टिक्स सपोर्ट लायब्ररीची प्रत आहे, म्हणजेच ते कॉन्फिगरेशन-बदलण्यायोग्य आहे. मतदान फक्त पोलर बदलते. आम्हाला विश्वास आहे की हे बराच काळ काम करेल.

उत्तरः – खूप खूप धन्यवाद. केलेल्या बदलांचे काही कागदपत्रे आहेत का ते कृपया मला सांगाल का?

एमएम: "डॉक्युमेंटेशन हा एक पॅच आहे. अर्थातच, क्लिकहाऊस आणि नवीन प्रकारच्या पोलरच्या परिचयाने, नवीन कॉन्फिगरेशन पर्याय उद्भवतात. शेवटच्या स्लाइडमधील लिंकमध्ये ते कसे वापरायचे याचे थोडक्यात वर्णन आहे."

fping ला nmap ने बदलण्याबद्दल

उत्तरः तुम्ही हे कसे अंमलात आणले? तुम्ही विशिष्ट उदाहरणे देऊ शकाल का: तुम्ही स्ट्रिपर्स आणि बाह्य स्क्रिप्ट वापरत आहात का? इतक्या मोठ्या संख्येने होस्ट इतक्या लवकर तपासण्यास शेवटी काय सक्षम आहे? तुम्ही हे होस्ट कसे मिळवता? तुम्हाला त्यांना nmap मध्ये कसे तरी फीड करावे लागेल, कुठूनतरी आणावे लागेल, त्यात ठेवावे लागेल, काहीतरी चालवावे लागेल का?

एमएम: "छान. खूप चांगला प्रश्न आहे! सारांश असा आहे. आम्ही लायब्ररीमध्ये (आयसीएमपी पिंग, झॅबिक्सचा एक घटक) बदल केला आहे जेणेकरून आयसीएमपी तपासणी केली जाईल जी एक (1) पॅकेट गणना निर्दिष्ट करते आणि कोड एनएमएपी वापरण्याचा प्रयत्न करतो. म्हणून, ही अंतर्गत झॅबिक्स कार्यक्षमता पिंजरची अंतर्गत कार्यक्षमता बनली आहे. परिणामी, कोणत्याही सिंक्रोनाइझेशन किंवा ट्रॅपिंगची आवश्यकता नाही. सिस्टम सुसंगत ठेवण्यासाठी आणि दोन डेटाबेस सिस्टम सिंक्रोनाइझ करण्याचा त्रास टाळण्यासाठी हे जाणूनबुजून केले गेले: काय तपासायचे, पोलरद्वारे अपलोड करणे किंवा आमचे अपलोडिंग बिघडले आहे का? ते खूप सोपे आहे."

उत्तरः – हे प्रॉक्सींसाठीही काम करते का?

एमएम: "हो, पण आम्ही त्याची चाचणी केलेली नाही. झब्बीक्स आणि सर्व्हर दोन्हीमध्ये पोलिंग कोड सारखाच आहे. तो काम करायला हवा. मी पुन्हा एकदा जोर देतो: सिस्टमची कामगिरी अशी आहे की आम्हाला प्रॉक्सीची आवश्यकता नाही."

एमसी: – या प्रश्नाचे बरोबर उत्तर असे आहे: “अशा प्रणालीसह तुम्हाला प्रॉक्सीची आवश्यकता का आहे?” हे फक्त NAT मुळे आहे की काही स्लो चॅनेलद्वारे निरीक्षण करण्यासाठी आहे…

उत्तरः – आणि जर मी बरोबर समजलो तर तुम्ही झब्बीक्सचा वापर अॅलर्जीन म्हणून करता. किंवा तुमचे आलेख (जिथे संग्रहण थर आहे) ग्राफाना सारख्या दुसऱ्या सिस्टममध्ये हलवले आहेत? किंवा तुम्ही ती कार्यक्षमता वापरत नाही?

एमएम: "मी पुन्हा एकदा जोर देईन: आम्ही पूर्ण एकात्मता लागू केली आहे. आम्ही क्लिकहाऊसवर इतिहास अपलोड करत आहोत, परंतु आम्ही PHP फ्रंटएंडमध्ये देखील बदल केले आहेत. PHP फ्रंटएंड क्लिकहाऊसशी जोडला जातो आणि तिथून सर्व आलेख तयार करतो. त्याच वेळी, प्रामाणिकपणे सांगायचे तर, आमच्याकडे एक घटक आहे जो इतर ग्राफिकल डिस्प्ले सिस्टममध्ये डेटा तयार करण्यासाठी समान क्लिकहाऊस आणि झब्बीक्स डेटा वापरतो."

एमसी: - इतर गोष्टींबरोबरच "ग्राफन" मध्ये.

संसाधन वाटपाचा निर्णय कसा घेण्यात आला?

उत्तरः – अंतर्गत कामकाजाबद्दल थोडी माहिती देऊ शकाल का? उत्पादनाच्या मोठ्या पुनर्बांधणीसाठी संसाधनांचे वाटप करण्याचा निर्णय कसा घेण्यात आला? अर्थातच, यात काही धोके आहेत. आणि, नवीन आवृत्त्यांना समर्थन देण्याच्या तुमच्या योजनांच्या संदर्भात, व्यवस्थापनाच्या दृष्टिकोनातून हा निर्णय कसा न्याय्य आहे?

एमएम: "वरवर पाहता, आम्ही कथेतील नाट्यमयता फारशी चांगली मांडली नाही. आम्ही स्वतःला अशा परिस्थितीत सापडलो जिथे काहीतरी करावेच लागेल आणि आम्ही मूलतः दोन समांतर संघांसह गेलो:

• एक म्हणजे नवीन पद्धती वापरून एक देखरेख प्रणाली सुरू करणे: सेवा म्हणून देखरेख, ओपन-सोर्स उपायांचा एक मानक संच जो आपण एकत्रित करतो आणि नंतर नवीन देखरेख प्रणालीसह कार्य करण्यासाठी व्यवसाय प्रक्रिया बदलण्याचा प्रयत्न करतो.
• त्याच वेळी, आमच्याकडे एक उत्साही प्रोग्रामर होता जो यावर (स्वतःबद्दल) काम करत होता. योगायोगाने तो जिंकला.

उत्तरः - आणि संघाचा आकार किती आहे?

एमसी: - ती तुमच्या समोर आहे.

उत्तरः - तर, नेहमीप्रमाणे, एक तापट व्यक्ती आवश्यक आहे का?

एमएम: - मला माहित नाही की पॅशनरी म्हणजे काय.

उत्तरः – या प्रकरणात, ते तुम्हीच आहात असे दिसते. खूप खूप धन्यवाद, तुम्ही अद्भुत आहात.

एमएम: - धन्यवाद.

झब्बीक्स पॅचेस बद्दल

उत्तरः – प्रॉक्सी वापरणाऱ्या प्रणालीसाठी (उदाहरणार्थ, काही वितरित प्रणालींमध्ये), तुमचे समाधान, उदाहरणार्थ, पोलर, प्रॉक्सी आणि अंशतः झब्बीक्स प्रीप्रोसेसर स्वतः; आणि त्यांच्या परस्परसंवादांना अनुकूलित करणे आणि पॅच करणे शक्य आहे का? अनेक प्रॉक्सी असलेल्या प्रणालीसाठी विद्यमान विकास ऑप्टिमाइझ करणे शक्य आहे का?

एमएम: – मला माहित आहे की झब्बीक्स सर्व्हर प्रॉक्सी वापरून बनवला जातो (तो कोड संकलित करतो आणि तयार करतो). आम्ही उत्पादनात याची चाचणी केलेली नाही. मला याबद्दल खात्री नाही, परंतु मला वाटत नाही की प्रॉक्सीमध्ये प्रीप्रोसेसर मॅनेजर वापरला गेला आहे. प्रॉक्सीचे काम झब्बीक्सकडून मेट्रिक्सचा संच घेणे, त्यांचे सर्वेक्षण करणे (ते कॉन्फिगरेशन आणि स्थानिक डेटाबेस देखील लिहिते) आणि ते झब्बीक्स सर्व्हरला परत देणे आहे. सर्व्हर नंतर ते प्राप्त झाल्यावर प्रीप्रोसेसिंग करेल.

प्रॉक्सीमध्ये रस असणे समजण्यासारखे आहे. आपण ते तपासून पाहू. हा एक मनोरंजक विषय आहे.

उत्तरः – कल्पना अशी होती: जर पोलर पॅच करता येतात, तर ते प्रॉक्सीवर पॅच करता येतात आणि सर्व्हरशी संवाद पॅच करता येतो आणि प्रीप्रोसेसर फक्त सर्व्हरवरच या उद्देशांसाठी अनुकूलित करता येतो.

एमएम: "मला वाटते की ते आणखी सोपे आहे. तुम्ही कोड घेता, पॅच लागू करता, नंतर तो तुम्हाला हवा तसा कॉन्फिगर करता - प्रॉक्सी सर्व्हर तयार करता (उदाहरणार्थ, ODBC सह) आणि पॅच केलेला कोड सर्व सिस्टममध्ये वितरित करता. तुम्ही गरजेनुसार प्रॉक्सी तयार करता आणि गरजेनुसार सर्व्हर."

उत्तरः – सर्व्हरवर प्रॉक्सी ट्रान्समिशन अतिरिक्तपणे पॅच करणे आवश्यक नसण्याची शक्यता आहे का?

एमसी: - नाही, ते मानक आहे.

एमएम: "खरं तर, एका कल्पनेचा उल्लेखही करण्यात आला नव्हता. आम्ही नेहमीच कल्पनांचा स्फोट आणि बदलांची संख्या, तसेच मदतीची सोय यांच्यात संतुलन साधण्याचा प्रयत्न केला आहे."

काही जाहिराती 🙂

आमच्यासोबत राहिल्याबद्दल धन्यवाद. तुम्हाला आमचे लेख आवडतात का? अधिक मनोरंजक सामग्री पाहू इच्छिता? ऑर्डर देऊन किंवा मित्रांना शिफारस करून आम्हाला समर्थन द्या, $4.99 पासून विकसकांसाठी क्लाउड VPS, एंट्री-लेव्हल सर्व्हरचे एक अद्वितीय अॅनालॉग, जे तुमच्यासाठी आमच्याद्वारे शोधले गेले आहे: VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps बद्दल संपूर्ण सत्य $19 पासून किंवा सर्व्हर कसा शेअर करायचा? (RAID1 आणि RAID10 सह उपलब्ध, 24 कोर पर्यंत आणि 40GB DDR4 पर्यंत).

डेल R730xd ऍमस्टरडॅममधील इक्विनिक्स टियर IV डेटा सेंटरमध्ये 2 पट स्वस्त? फक्त इथेच 2 x इंटेल टेट्राडेका-कोर 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 पासून! बद्दल वाचा इन्फ्रास्ट्रक्चर कॉर्पोरेशन कसे तयार करावे. डेल R730xd E5-2650 v4 सर्व्हरचा वापर करून 9000 युरो किमतीचा वर्ग?

स्त्रोत: www.habr.com