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

पुढील HighLoad++ परिषद 6 आणि 7 एप्रिल 2020 रोजी सेंट पीटर्सबर्ग येथे होणार आहे तपशील आणि तिकिटे दुवा. HighLoad++ मॉस्को 2018. हॉल “मॉस्को”. नोव्हेंबर 9, 15:00. प्रबंध आणि सादरीकरण.

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

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

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

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

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

MM: - आणि हे सांगण्यासारखे आहे की Intersvyaz फक्त एक प्रदात्यापेक्षा बरेच काही आहे, ती एक IT कंपनी आहे. आमचे बहुतेक उपाय आमच्या आयटी विभागाद्वारे केले जातात.

उत्तरः रहदारीवर प्रक्रिया करणाऱ्या सर्व्हरपासून कॉल सेंटर आणि मोबाइल अॅप्लिकेशनवर. आयटी विभागाकडे आता जवळजवळ 80 लोक आहेत ज्यात अतिशय वैविध्यपूर्ण क्षमता आहेत.

Zabbix आणि त्याच्या आर्किटेक्चर बद्दल

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

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

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

• सर्व्हर. सी मध्ये लिहिलेले. ऐवजी जटिल प्रक्रिया आणि थ्रेड दरम्यान माहिती हस्तांतरण सह. सर्व प्रक्रिया त्यामध्ये होतात: प्राप्त करण्यापासून ते डेटाबेसमध्ये जतन करण्यापर्यंत.
• सर्व डेटा डेटाबेसमध्ये संग्रहित केला जातो. Zabbix MySQL, PostreSQL आणि Oracle चे समर्थन करते.
• वेब इंटरफेस PHP मध्ये लिहिलेला आहे. बर्‍याच सिस्टीमवर ते Apache सर्व्हरसह येते, परंतु nginx + php सह संयोजनात अधिक कार्यक्षमतेने कार्य करते.

आज आम्ही Zabbix शी संबंधित आमच्या कंपनीच्या आयुष्यातील एक गोष्ट सांगू इच्छितो...

Intersvyaz कंपनीच्या आयुष्यातील एक कथा. आमच्याकडे काय आहे आणि आम्हाला काय हवे आहे?

5 किंवा 6 महिन्यांपूर्वी. कामानंतर एक दिवस...

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

MM: - पण आधी सिंक्रोनाइझ करूया. मी काही वर्षात तिकडे पाहिले नाही. माझ्या आठवणीनुसार, आम्ही नागिओस सोडले आणि सुमारे 8 वर्षांपूर्वी Zabbix वर स्विच केले. आणि आता असे दिसते की आमच्याकडे 6 शक्तिशाली सर्व्हर आणि सुमारे डझनभर प्रॉक्सी आहेत. मी काही गोंधळात टाकत आहे का?

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

MM: - हे स्पष्ट आहे. आपण काहीतरी पाहिले आहे का, आपण निदानातून काहीतरी खोदले आहे का?

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

MM: - हे स्पष्ट आहे. सर्वसाधारणपणे, MySQL हा LTP डेटाबेस आहे. वरवर पाहता, आमच्या आकाराच्या मेट्रिक्सचे संग्रहण संग्रहित करण्यासाठी ते यापुढे योग्य नाही. चला ते बाहेर काढूया.

MCH: - चला!

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

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

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

Clickhouse आणि Elasticsearch ची तुलना

MM: - तुलनेसाठी, आम्ही Zabbix सर्व्हर पुरवतो तसाच लोड व्युत्पन्न केला आणि सिस्टम कसे वागतील ते पाहिले. आम्ही CURL वापरून 1000 ओळींच्या बॅचमध्ये डेटा लिहिला. Zabbix करत असलेल्या लोड प्रोफाइलसाठी Clickhouse अधिक कार्यक्षम असेल असे आम्ही आधीच गृहित धरले. परिणाम आमच्या अपेक्षेपेक्षा जास्त आहेत:

त्याच चाचणी परिस्थितीत, क्लिकहाऊसने तीन पट अधिक डेटा लिहिला. त्याच वेळी, डेटा वाचताना दोन्ही प्रणाली अतिशय कार्यक्षमतेने (थोड्या प्रमाणात संसाधने) वापरतात. परंतु रेकॉर्डिंग करताना इलास्टिकला मोठ्या प्रमाणात प्रोसेसर आवश्यक आहे:

एकूणच, प्रोसेसर वापर आणि गतीच्या बाबतीत क्लिकहाऊस Elastix पेक्षा लक्षणीयरित्या श्रेष्ठ होते. त्याच वेळी, डेटा कॉम्प्रेशनमुळे, क्लिकहाऊस हार्ड ड्राइव्हवर 11 पट कमी वापरते आणि सुमारे 30 पट कमी डिस्क ऑपरेशन करते:

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

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

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

Zabbix मध्ये मतदान कसे कार्य करते?

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

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

MCH: - ते मात्र नक्की! आम्हाला सोडवण्याची आणखी एक समस्या आहे ती धीमे डेटा संकलन. आता आमचे सर्व 15 प्रॉक्सी सर्व्हर SNMP आणि मतदान प्रक्रियांनी ओव्हरलोड झाले आहेत. आणि नवीन आणि नवीन सर्व्हर स्थापित करण्याशिवाय कोणताही मार्ग नाही.

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

MCH: - थोडक्यात, 20 प्रकारचे मेट्रिक्स आणि ते मिळवण्याचे डझनभर मार्ग आहेत. Zabbix एकतर "विनंती-प्रतिसाद" मोडमध्ये डेटा संकलित करू शकते किंवा "ट्रॅपर इंटरफेस" द्वारे नवीन डेटाची प्रतीक्षा करू शकते.

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

लोड वितरणासाठी प्रॉक्सी सर्व्हर आहेत:

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

MM: - आर्किटेक्चरसह सर्व काही स्पष्ट आहे. आम्हाला स्त्रोत पहावे लागतील ...

एक-दोन दिवसांनी

nmap fping कसे जिंकले याची कथा

MM: "मला वाटते मी काहीतरी खोदले आहे."

MCH: - मला सांग!

MM: - मला आढळले की उपलब्धता तपासताना, Zabbix एका वेळी जास्तीत जास्त 128 होस्ट तपासते. मी ही संख्या 500 पर्यंत वाढवण्याचा प्रयत्न केला आणि त्यांच्या पिंग (पिंग) मधील इंटर-पॅकेट अंतराल काढून टाकण्याचा प्रयत्न केला - यामुळे कामगिरी दुप्पट झाली. पण मला जास्त संख्या हवी आहे.

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

MM: - पाचशेहून अधिक तपासा? 600?

MCH: - किमान दोन हजार.

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

MCH: - छान! आणि कधी?

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

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

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

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

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

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

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

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

हे यजमानांच्या संपूर्ण पॅकसाठी केले जाते. हा मोड शेवटी पूर्णतः असिंक्रोनसपेक्षा धीमे नाही, कारण मतदान दीडशे SNMP मूल्ये अद्याप 1 कालबाह्यतेपेक्षा खूप वेगवान आहेत.

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

MCH: - परिणामी मतदान ऑप्टिमायझेशनने दाखवले की आम्ही केवळ सर्व प्रॉक्सीपासून मुक्त होऊ शकत नाही, तर अनेक तपासण्यांसाठीचे अंतर देखील कमी करू शकतो आणि भार सामायिक करण्याचा मार्ग म्हणून प्रॉक्सीची यापुढे आवश्यकता राहणार नाही.

सुमारे तीन महिन्यांपूर्वीची गोष्ट

आर्किटेक्चर बदला - भार वाढवा!

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

MCH: - ठीक आहे, चला योजना करूया. 5 हजार मेट्रिक्स प्रति सेकंदाच्या मृत बिंदूपासून पुढे जाण्याची वेळ आली आहे.

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

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

MM: - 20 हजार कमाल.

MCH: - होय, 25! दुर्दैवाने, आम्ही जिथून सुरुवात केली तेथूनच आहोत.

MM: - का? तुम्ही काही निदान चालवले आहे का?

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

MM: - चला पाहूया. मी पाहतो की आम्ही मोठ्या संख्येने मतदान धागे वापरून पाहिले आहेत:

परंतु त्याच वेळी ते निम्म्यानेही सिस्टमचे रीसायकल करू शकले नाहीत:

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

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

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

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

MCH: - अस्पष्ट.

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

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

या समस्येचे निराकरण करण्याचे दोन मार्ग आहेत.

मशीनचे हार्डवेअर अपग्रेड करा, वेगवान कोरवर स्विच करा:

किंवा आर्किटेक्चर बदला आणि त्याच वेळी लोड बदला:

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

MM: - साफ? आपल्याला सर्व्हर कोड पाहण्याची आवश्यकता आहे.

Zabbix सर्व्हरमधील डेटा पथ

MCH: - हे शोधण्यासाठी, आम्ही Zabbix सर्व्हरमध्ये डेटा कसा हस्तांतरित केला जातो याचे विश्लेषण करण्यास सुरुवात केली:

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

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

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

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

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

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

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

मतदान करणाऱ्यांनी संघर्ष करू नये

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

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

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

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

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

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

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

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

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

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

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

इतिहासाच्या कॅशेसाठी स्पर्धा दिसू लागल्याने वाढीची नॉन-रेखीयता स्पष्ट केली आहे. 4 प्रीप्रोसेसर व्यवस्थापक आणि इतिहास सिंकर्स यासाठी स्पर्धा करतात. या टप्प्यावर, आम्ही चाचणी मशीनवर प्रति सेकंद अंदाजे 130 हजार मेट्रिक्स प्राप्त करत होतो, अंदाजे 95% प्रोसेसरद्वारे त्याचा वापर केला:

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

snmp-समुदायाकडून नकार दिल्यामुळे NVPs दीड पट वाढले

MM: - मॅक्स, मला नवीन चाचणी कारची गरज आहे! आम्ही यापुढे वर्तमानात बसत नाही.

MCH: - आता तुमच्याकडे काय आहे?

MM: – आता – 130k NVPs आणि एक शेल्फ-रेडी प्रोसेसर.

MCH: - व्वा! मस्त! थांबा, माझे दोन प्रश्न आहेत. माझ्या गणनेनुसार, आमची गरज प्रति सेकंद 15-20 हजार मेट्रिक्स इतकी आहे. आम्हाला अधिक का आवश्यक आहे?

MM: "मला काम पूर्ण करायचे आहे." या व्यवस्थेतून आपण किती पिळून काढू शकतो हे मला पहायचे आहे.

MCH: - परंतु…

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

MCH: - हे स्पष्ट आहे. आणि दुसरा प्रश्न: विकासकाच्या मदतीशिवाय, आमच्याकडे जे आहे ते आम्ही स्वतःहून समर्थन देऊ शकतो का?

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

MCH: "मग आम्हाला एक प्रकारचा पर्याय हवा आहे."

MM: - असा पर्याय आहे. नवीन लॉकिंग सिस्टीम सोडून देत आम्ही फास्ट कोरवर स्विच करू शकतो. आम्हाला अजूनही 60-80 हजार मेट्रिक्सची कामगिरी मिळेल. त्याच वेळी, आम्ही सर्व कोड सोडू शकतो. क्लिकहाऊस आणि असिंक्रोनस मतदान कार्य करेल. आणि त्याची देखभाल करणे सोपे होईल.

MCH: - आश्चर्यकारक! मी सुचवितो की आपण येथे थांबू.

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

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

उत्पादनात दोन दिवसांनंतर

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

MCH: - मिशा, आम्ही दोन दिवसांपासून सिस्टम वापरत आहोत आणि सर्वकाही कार्य करते. पण जेव्हा सर्वकाही कार्य करते तेव्हाच! आम्ही नेटवर्कच्या बर्‍यापैकी मोठ्या सेगमेंटच्या हस्तांतरणासह कामाची योजना आखली होती आणि आम्ही पुन्हा आमच्या हातांनी तपासले की काय वाढले आणि काय नाही.

MM: - असू शकत नाही! आम्ही सर्व काही 10 वेळा तपासले. सर्व्हर अगदी संपूर्ण नेटवर्क अनुपलब्धता त्वरित हाताळतो.

MCH: - होय, मला सर्व काही समजले आहे: सर्व्हर, डेटाबेस, टॉप, ऑस्टॅट, लॉग - सर्वकाही वेगवान आहे... परंतु आम्ही वेब इंटरफेस पाहतो, आणि सर्व्हरवर "शेल्फमध्ये" एक प्रोसेसर आहे आणि हे:

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

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

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

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

MCH: - मीशा, तू जात आहेस? बोलायला हवं.

MM: - माझा हेतू नव्हता. Zabbix सह पुन्हा काहीतरी?

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

Zabbix कार्यक्षम आहे

Zabbix ही एक सार्वत्रिक आणि समृद्ध प्रणाली आणि कार्य आहे. हे बॉक्सच्या बाहेर असलेल्या छोट्या स्थापनेसाठी वापरले जाऊ शकते, परंतु जसजशी गरजा वाढतात तसतसे ते ऑप्टिमाइझ केले जावे. मेट्रिक्सचे मोठे संग्रहण संचयित करण्यासाठी, योग्य संचयन वापरा:

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

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

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

त्याच Zabbix पॅच

MM: - मला काही मुद्दे जोडायचे आहेत. संपूर्ण वर्तमान अहवाल, सर्व चाचण्या, क्रमांक आम्ही वापरत असलेल्या कॉन्फिगरेशनसाठी दिलेले आहेत. आता आम्ही त्यातून अंदाजे 20 हजार मेट्रिक्स प्रति सेकंद घेत आहोत. आपण हे आपल्यासाठी कार्य करेल की नाही हे समजून घेण्याचा प्रयत्न करत असल्यास, आपण तुलना करू शकता. आज जी चर्चा झाली ती पॅचच्या स्वरूपात GitHub वर पोस्ट केली आहे: github.com/miklert/zabbix

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

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

पॅच सर्व आवृत्ती 4 सह सुसंगत आहे, lts सह. बहुधा, कमीतकमी बदलांसह ते आवृत्ती 3.4 वर कार्य करेल.

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

प्रश्न

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

MM: - होय, आम्ही निश्चितपणे काही बदल करू. काहीतरी घडेल, काहीतरी पॅच राहील.

उत्तरः - उत्कृष्ट अहवालासाठी खूप खूप धन्यवाद! कृपया मला सांगा, पॅच लागू केल्यानंतर, Zabbix कडून समर्थन राहील आणि उच्च आवृत्त्यांमध्ये अद्यतनित करणे कसे सुरू ठेवायचे? तुमच्या पॅच नंतर 4.2, 5.0 वर Zabbix अपडेट करणे शक्य होईल का?

MM: - मी समर्थनाबद्दल काहीही बोलू शकत नाही. जर मी Zabbix तांत्रिक समर्थन असतो, तर मी कदाचित नाही म्हणेन, कारण हा दुसर्‍याचा कोड आहे. 4.2 कोडबेससाठी, आमची स्थिती अशी आहे: "आम्ही वेळेनुसार पुढे जाऊ, आणि आम्ही पुढील आवृत्तीवर स्वतःला अपडेट करू." म्हणून, काही काळ आम्ही अद्ययावत आवृत्त्यांसाठी पॅच पोस्ट करणार आहोत. मी अहवालात आधीच सांगितले आहे: आवृत्त्यांसह बदलांची संख्या अद्याप खूपच कमी आहे. मला असे वाटते की 3.4 ते 4 मधील संक्रमणास आम्हाला सुमारे 15 मिनिटे लागली. तेथे काहीतरी बदलले, परंतु फार महत्वाचे नाही.

उत्तरः - तर तुम्ही तुमच्या पॅचला सपोर्ट करण्याची योजना आखत आहात आणि तुम्ही ते सुरक्षितपणे प्रोडक्शनमध्ये इन्स्टॉल करू शकता आणि भविष्यात काही प्रकारे अपडेट्स मिळवू शकता?

MM: - आम्ही याची जोरदार शिफारस करतो. हे आमच्यासाठी बर्याच समस्यांचे निराकरण करते.

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

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

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

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

nmap सह fping बदलण्याबद्दल

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

MM: - मस्त. अतिशय योग्य प्रश्न! मुद्दा हा आहे. आम्ही ICMP तपासणीसाठी लायब्ररी (ICMP पिंग, Zabbix चा भाग) सुधारित केली, जे पॅकेट्सची संख्या दर्शवते - एक (1), आणि कोड nmap वापरण्याचा प्रयत्न करतो. म्हणजेच, हे झब्बीक्सचे अंतर्गत कार्य आहे, जे पिंजरचे अंतर्गत कार्य बनले आहे. त्यानुसार, कोणत्याही सिंक्रोनाइझेशन किंवा ट्रॅपरचा वापर आवश्यक नाही. सिस्टम अखंड ठेवण्यासाठी आणि दोन डेटाबेस सिस्टमच्या सिंक्रोनाइझेशनला सामोरे जावे लागू नये म्हणून हे जाणूनबुजून केले गेले: काय तपासायचे, पोलरद्वारे अपलोड करणे आणि आमचे अपलोड तुटलेले आहे का?.. हे बरेच सोपे आहे.

उत्तरः - हे प्रॉक्सीसाठी देखील कार्य करते?

MM: - होय, परंतु आम्ही तपासले नाही. मतदान कोड Zabbix आणि सर्व्हर दोन्ही मध्ये समान आहे. काम केले पाहिजे. मी पुन्हा एकदा जोर देतो: सिस्टमची कार्यक्षमता अशी आहे की आम्हाला प्रॉक्सीची आवश्यकता नाही.

MCH: - प्रश्नाचे योग्य उत्तर आहे: "तुम्हाला अशा प्रणालीसह प्रॉक्सीची आवश्यकता का आहे?" केवळ NAT मुळे किंवा काही प्रकारच्या स्लो चॅनेलद्वारे देखरेख केल्यामुळे...

उत्तरः - आणि जर मला बरोबर समजले तर तुम्ही ऍलर्टर म्हणून Zabbix वापरता. किंवा तुमचे ग्राफिक्स (जेथे संग्रहण स्तर आहे) Grafana सारख्या दुसर्‍या सिस्टममध्ये हलवले आहेत? किंवा तुम्ही ही कार्यक्षमता वापरत नाही आहात?

MM: - मी पुन्हा एकदा जोर देईन: आम्ही संपूर्ण एकीकरण साध्य केले आहे. आम्ही क्लिकहाऊसमध्ये इतिहास ओतत आहोत, परंतु त्याच वेळी आम्ही php फ्रंटएंड बदलला आहे. Php फ्रंटएंड क्लिकहाऊसला जातो आणि तेथून सर्व ग्राफिक्स करतो. त्याच वेळी, प्रामाणिकपणे सांगायचे तर, आमच्याकडे एक भाग आहे जो त्याच क्लिकहाऊसमधून, त्याच Zabbix डेटावरून इतर ग्राफिक डिस्प्ले सिस्टममध्ये डेटा तयार करतो.

MCH: - "ग्राफन" मध्ये देखील.

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

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

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

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

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

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

उत्तरः - तर, नेहमीप्रमाणे, तुम्हाला उत्कटतेची गरज आहे?

MM: - उत्कटता म्हणजे काय हे मला माहित नाही.

उत्तरः - या प्रकरणात, वरवर पाहता, आपण. खूप खूप धन्यवाद, तुम्ही छान आहात.

MM: - धन्यवाद.

Zabbix साठी पॅच बद्दल

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

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

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

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

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

उत्तरः - बहुधा, तुम्हाला अतिरिक्तपणे सर्व्हरवर प्रॉक्सी ट्रान्समिशन पॅच करावे लागणार नाही?

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

MM: - खरं तर, त्यापैकी एक कल्पना वाजली नाही. आम्ही नेहमी कल्पनांचा स्फोट आणि बदलांचे प्रमाण आणि समर्थनाची सुलभता यांच्यात संतुलन राखले आहे.

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

आमच्यासोबत राहिल्याबद्दल धन्यवाद. तुम्हाला आमचे लेख आवडतात का? अधिक मनोरंजक सामग्री पाहू इच्छिता? ऑर्डर देऊन किंवा मित्रांना शिफारस करून आम्हाला समर्थन द्या, $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