SDSM संपले, पण लिहिण्याची अनियंत्रित इच्छा कायम आहे.

बर्‍याच वर्षांपासून, आमच्या भावाला नियमित काम करणे, काम करण्यापूर्वी बोटे ओलांडणे आणि रात्रीच्या रोलबॅकमुळे झोप येत नाही.
पण काळोखाचा काळ संपत आहे.

या लेखासह मी कसे याबद्दल मालिका सुरू करेन मला ऑटोमेशन पाहिले जाते.
वाटेत, आम्ही ऑटोमेशनचे टप्पे समजू, व्हेरिएबल्स संचयित करू, औपचारिक डिझाइन, RestAPI, NETCONF, YANG, YDK आणि आम्ही बरेच प्रोग्रामिंग करू.
माझ्यासाठी याचा अर्थ असा की अ) ते वस्तुनिष्ठ सत्य नाही, ब) तो बिनशर्त सर्वोत्तम दृष्टीकोन नाही, क) माझे मत, अगदी पहिल्यापासून शेवटच्या लेखापर्यंतच्या चळवळीदरम्यान, बदलू शकते - प्रामाणिकपणे, मसुद्याच्या टप्प्यापासून प्रकाशन, मी सर्वकाही पूर्णपणे दोनदा पुन्हा लिहिले.

सामग्री

1. उद्दीष्टे
   1. नेटवर्क हे एकाच जीवासारखे आहे
   2. कॉन्फिगरेशन चाचणी
   3. आवृत्ती तयार करणे
   4. सेवांचे निरीक्षण आणि स्व-उपचार

2. निधी
   1. इन्व्हेंटरी सिस्टम
   2. आयपी स्पेस मॅनेजमेंट सिस्टम
   3. नेटवर्क सेवा वर्णन प्रणाली
   4. डिव्हाइस आरंभीकरण यंत्रणा
   5. विक्रेता-अज्ञेयवादी कॉन्फिगरेशन मॉडेल
   6. विक्रेता-विशिष्ट ड्रायव्हर इंटरफेस
   7. डिव्हाइसवर कॉन्फिगरेशन वितरीत करण्यासाठी यंत्रणा
   8. सीआय / सीडी
   9. बॅकअप आणि विचलन शोधण्यासाठी यंत्रणा
   10. देखरेख यंत्रणा

3. निष्कर्ष

मी SDSM पेक्षा थोड्या वेगळ्या स्वरूपात ADSM आयोजित करण्याचा प्रयत्न करेन. मोठे, तपशीलवार, क्रमांकित लेख येत राहतील आणि त्यांच्यामध्ये मी रोजच्या अनुभवातील छोट्या नोट्स प्रकाशित करेन. मी येथे परिपूर्णतावादाशी लढण्याचा प्रयत्न करेन आणि त्यापैकी प्रत्येकाला चाटणार नाही.

दुसऱ्यांदा त्याच वाटेवरून जावे लागते ही किती गंमत आहे.

सुरुवातीला मला नेटवर्कबद्दल लेख लिहावे लागले कारण ते RuNet वर नव्हते.

आता मला एक सर्वसमावेशक दस्तऐवज सापडला नाही जो ऑटोमेशनच्या दृष्टीकोनांना पद्धतशीर करेल आणि सोपी व्यावहारिक उदाहरणे वापरून वरील तंत्रज्ञानाचे विश्लेषण करेल.

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

आम्ही मध्यम आकाराचे LAN DC डेटा सेंटर घेण्याचा प्रयत्न करू आणि संपूर्ण ऑटोमेशन योजना तयार करू.
मी तुमच्यासोबत जवळजवळ पहिल्यांदाच काही गोष्टी करणार आहे.

मी येथे वर्णन केलेल्या कल्पना आणि साधनांमध्ये मूळ होणार नाही. दिमित्री फिगोलकडे उत्कृष्ट आहे या विषयावरील प्रवाहांसह चॅनेल.
लेख त्यांच्याशी अनेक पैलूंवर आच्छादित होतील.

LAN DC मध्ये 4 DC, सुमारे 250 स्विचेस, अर्धा डझन राउटर आणि दोन फायरवॉल आहेत.
Facebook नाही, पण तुम्हाला ऑटोमेशनबद्दल खोलवर विचार करायला लावण्यासाठी पुरेसे आहे.
तथापि, असे मत आहे की आपल्याकडे 1 पेक्षा जास्त डिव्हाइस असल्यास, ऑटोमेशन आधीपासूनच आवश्यक आहे.
खरं तर, कोणीही आता किमान गुडघा स्क्रिप्टच्या पॅकशिवाय जगू शकेल याची कल्पना करणे कठीण आहे.
जरी मी ऐकले आहे की अशी कार्यालये आहेत जिथे आयपी पत्ते एक्सेलमध्ये ठेवलेले आहेत आणि हजारो नेटवर्क डिव्हाइसेसपैकी प्रत्येक व्यक्तिचलितपणे कॉन्फिगर केले आहे आणि त्यांचे स्वतःचे अद्वितीय कॉन्फिगरेशन आहे. हे, अर्थातच, आधुनिक कला म्हणून दिले जाऊ शकते, परंतु अभियंताच्या भावना नक्कीच दुखावल्या जातील.

उद्दीष्टे

आता आम्ही सर्वात अमूर्त लक्ष्य सेट करू:

• नेटवर्क हे एकाच जीवासारखे आहे
• कॉन्फिगरेशन चाचणी
• नेटवर्क स्टेट व्हर्जनिंग
• सेवांचे निरीक्षण आणि स्व-उपचार

या लेखात नंतर आपण कोणते साधन वापरणार आहोत ते पाहू आणि पुढीलमध्ये आपण ध्येये आणि माध्यमे तपशीलवार पाहू.

नेटवर्क हे एकाच जीवासारखे आहे

मालिकेचे परिभाषित वाक्यांश, जरी पहिल्या दृष्टीक्षेपात ते इतके लक्षणीय वाटत नाही: आम्ही नेटवर्क कॉन्फिगर करू, वैयक्तिक डिव्हाइसेस नाही.
अलिकडच्या वर्षांत, आम्ही नेटवर्कला एकच घटक मानण्यावर भर दिला आहे, त्यामुळे सॉफ्टवेअर परिभाषित नेटवर्किंग, हेतू प्रेरित नेटवर्क и स्वायत्त नेटवर्क.
शेवटी, नेटवर्कवरून ऍप्लिकेशन्सना जागतिक स्तरावर काय आवश्यक आहे: पॉइंट A आणि B (चांगले, कधीकधी +B-Z) दरम्यान कनेक्टिव्हिटी आणि इतर ऍप्लिकेशन्स आणि वापरकर्त्यांपासून अलगाव.

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

म्हणजेच, उदाहरणार्थ, जर आम्ही ठरवले की आतापासून काझानमधील रॅक स्विचेसने एका ऐवजी दोन नेटवर्कची घोषणा केली पाहिजे, तर आम्ही

1. प्रथम आम्ही सिस्टममधील बदलांचे दस्तऐवजीकरण करतो
2. सर्व नेटवर्क उपकरणांचे लक्ष्य कॉन्फिगरेशन व्युत्पन्न करणे
3. आम्ही नेटवर्क कॉन्फिगरेशन अपडेट प्रोग्राम लाँच करतो, जो प्रत्येक नोडवर काय काढायचे आहे, काय जोडायचे आहे याची गणना करतो आणि नोड्स इच्छित स्थितीत आणतो.

त्याच वेळी, आम्ही केवळ पहिल्या चरणात व्यक्तिचलितपणे बदल करतो.

कॉन्फिगरेशन चाचणी

ते माहित आहेकॉन्फिगरेशन बदलांदरम्यान 80% समस्या उद्भवतात - याचा अप्रत्यक्ष पुरावा असा आहे की नवीन वर्षाच्या सुट्टीत सर्व काही सामान्यतः शांत असते.
मानवी चुकांमुळे मी वैयक्तिकरित्या डझनभर जागतिक डाउनटाइम्स पाहिल्या आहेत: चुकीची आज्ञा, कॉन्फिगरेशन चुकीच्या शाखेत कार्यान्वित केले गेले, समुदाय विसरला, MPLS राउटरवर जागतिक स्तरावर नष्ट केले गेले, हार्डवेअरचे पाच तुकडे कॉन्फिगर केले गेले, परंतु त्रुटी आली नाही सहाव्या दिवशी लक्षात आले की, दुसर्‍या व्यक्तीने केलेले जुने बदल वचनबद्ध होते. एक टन परिस्थिती आहेत.

ऑटोमेशन आम्हाला कमी चुका करण्यास अनुमती देईल, परंतु मोठ्या प्रमाणावर. अशा प्रकारे तुम्ही फक्त एका डिव्हाइसवर नाही तर संपूर्ण नेटवर्क एकाच वेळी विट करू शकता.

अनादी काळापासून, आमच्या आजोबांनी बारकाईने केलेल्या बदलांची अचूकता, स्टीलचे गोळे आणि ते आणल्यानंतर नेटवर्कची कार्यक्षमता तपासली.
ज्या आजोबांच्या कामामुळे डाउनटाइम आणि आपत्तीजनक नुकसान झाले त्यांनी कमी संतती सोडली आणि कालांतराने त्यांचा मृत्यू झाला, परंतु उत्क्रांती ही एक संथ प्रक्रिया आहे आणि म्हणूनच प्रत्येकजण प्रयोगशाळेतील बदलांची चाचणी करत नाही.
तथापि, प्रगतीच्या आघाडीवर ते आहेत ज्यांनी कॉन्फिगरेशनची चाचणी करण्याची प्रक्रिया स्वयंचलित केली आहे आणि नेटवर्कवर त्याचा पुढील अनुप्रयोग आहे. दुसऱ्या शब्दांत, मी CI/CD प्रक्रिया उधार घेतली (सतत एकीकरण, सतत तैनाती) विकसकांकडून.
यापैकी एका भागात आपण आवृत्ती नियंत्रण प्रणाली, बहुधा गिथब वापरून हे कसे अंमलात आणायचे ते पाहू.

एकदा तुम्हाला नेटवर्क CI/CD च्या कल्पनेची सवय झाली की, प्रोडक्शन नेटवर्कवर लागू करून कॉन्फिगरेशन तपासण्याची पद्धत रात्रभर मध्ययुगीन अज्ञानासारखी वाटेल. हातोड्याने वॉरहेड मारल्यासारखा.

बद्दलच्या कल्पनांचा सेंद्रिय निरंतरता प्रणाली नेटवर्क व्यवस्थापन आणि CI/CD कॉन्फिगरेशनची पूर्ण आवृत्ती बनते.

आवृत्ती तयार करणे

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

समजा वर्तमान आवृत्ती 1.0.0 आहे.
लूपबॅक इंटरफेसचा आयपी पत्ता बदलला आहे का? ही एक लहान आवृत्ती आहे आणि ती 1.0.1 क्रमांकित असेल.
आम्ही BGP मध्ये मार्ग आयात करण्याच्या धोरणांमध्ये सुधारणा केली आहे - थोडे अधिक गंभीरपणे - आधीच 1.1.0
आम्ही आयजीपीपासून मुक्त होण्याचा आणि फक्त बीजीपीवर स्विच करण्याचा निर्णय घेतला - हे आधीपासूनच एक मूलगामी बदल आहे - 2.0.0.

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

वर सिमेंटिक आवृत्ती आम्ही एका स्वतंत्र लेखात बोलू.

मी पुनरावृत्ती करतो - कोणताही बदल (डीबगिंग आदेश वगळता) ही आवृत्ती अद्यतन आहे. वर्तमान आवृत्तीमधील कोणत्याही विचलनाबद्दल प्रशासकांना सूचित केले जाणे आवश्यक आहे.

हेच बदल रोलबॅक करण्यासाठी लागू होते - हे शेवटचे आदेश रद्द करत नाही, हे डिव्हाइसची ऑपरेटिंग सिस्टम वापरून रोलबॅक नाही - हे संपूर्ण नेटवर्कला नवीन (जुन्या) आवृत्तीवर आणत आहे.

सेवांचे निरीक्षण आणि स्व-उपचार

हे स्वयं-स्पष्ट कार्य आधुनिक नेटवर्कमध्ये नवीन स्तरावर पोहोचले आहे.
बर्‍याचदा, मोठ्या सेवा प्रदात्यांनी अयशस्वी झालेल्या सेवेचे त्वरीत निराकरण करणे आवश्यक आहे आणि काय झाले हे शोधण्याऐवजी नवीन सेवा वाढवणे आवश्यक आहे.
“खूप” याचा अर्थ असा आहे की आपल्याला सर्व बाजूंनी उदारतेने निरीक्षण करणे आवश्यक आहे, जे काही सेकंदात सर्वसामान्य प्रमाणातील अगदी कमी विचलन ओळखेल.
आणि येथे नेहमीच्या मेट्रिक्स, जसे की इंटरफेस लोडिंग किंवा नोड उपलब्धता, यापुढे पुरेसे नाहीत. ड्युटी ऑफिसरद्वारे त्यांचे मॅन्युअल मॉनिटरिंग देखील पुरेसे नाही.
अनेक गोष्टींसाठी असाव्यात स्वत: ची चिकित्सा — देखरेखीचे दिवे लाल झाले आणि आम्ही गेलो आणि जिथे दुखत असेल तिथे स्वतः केळी लावली.

आणि येथे आम्ही केवळ वैयक्तिक उपकरणांचेच नव्हे तर संपूर्ण नेटवर्कचे आरोग्य देखील निरीक्षण करतो, दोन्ही व्हाईटबॉक्स, जो तुलनेने समजण्यासारखा आहे आणि ब्लॅकबॉक्स, जो अधिक क्लिष्ट आहे.

अशा महत्त्वाकांक्षी योजना राबवण्यासाठी आपल्याला काय लागेल?

• नेटवर्कवरील सर्व उपकरणांची सूची, त्यांचे स्थान, भूमिका, मॉडेल्स, सॉफ्टवेअर आवृत्त्या.
  kazan-leaf-1.lmu.net, Kazan, leaf, Juniper QFX 5120, R18.3.
• नेटवर्क सेवांचे वर्णन करण्यासाठी एक प्रणाली आहे.
  IGP, BGP, L2/3VPN, धोरण, ACL, NTP, SSH.
• डिव्हाइस सुरू करण्यात सक्षम व्हा.
  होस्टनाव, Mgmt IP, Mgmt मार्ग, वापरकर्ते, RSA-की, LLDP, NETCONF
• डिव्हाइस कॉन्फिगर करा आणि कॉन्फिगरेशनला इच्छित (जुन्यासह) आवृत्तीवर आणा.
• चाचणी कॉन्फिगरेशन
• वर्तमानातील विचलनासाठी सर्व उपकरणांची स्थिती वेळोवेळी तपासा आणि ती कोणाला असावी याचा अहवाल द्या.
  रात्रभर, कोणीतरी शांतपणे ACL मध्ये एक नियम जोडला.
• कामगिरीचे निरीक्षण करा.

निधी

प्रकल्पाचे घटकांमध्ये विघटन करणे सुरू करणे पुरेसे क्लिष्ट वाटते.

आणि त्यापैकी दहा असतील:

1. इन्व्हेंटरी सिस्टम
2. आयपी स्पेस मॅनेजमेंट सिस्टम
3. नेटवर्क सेवा वर्णन प्रणाली
4. डिव्हाइस आरंभीकरण यंत्रणा
5. विक्रेता-अज्ञेयवादी कॉन्फिगरेशन मॉडेल
6. विक्रेता-विशिष्ट ड्रायव्हर इंटरफेस
7. डिव्हाइसवर कॉन्फिगरेशन वितरीत करण्यासाठी यंत्रणा
8. सीआय / सीडी
9. बॅकअप आणि विचलन शोधण्यासाठी यंत्रणा
10. देखरेख यंत्रणा

हे, तसे, सायकलच्या उद्दिष्टांवरील दृश्य कसे बदलले याचे एक उदाहरण आहे - मसुद्यात 4 घटक होते.

चित्रात मी सर्व घटक आणि यंत्र स्वतःच चित्रित केले.
छेदणारे घटक एकमेकांशी संवाद साधतात.
ब्लॉक जितका मोठा असेल तितके या घटकाकडे अधिक लक्ष देणे आवश्यक आहे.

घटक 1: इन्व्हेंटरी सिस्टम

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

आमच्या हेतूंसाठी, आम्ही त्यामध्ये डिव्हाइसबद्दल खालील माहिती संचयित करू:

• यादी क्रमांक
• शीर्षक/वर्णन
• मॉडेल (Huawei CE12800, Juniper QFX5120, इ.)
• वैशिष्ट्यपूर्ण मापदंड (बोर्ड, इंटरफेस इ.)
• भूमिका (लीफ, स्पाइन, बॉर्डर राउटर इ.)
• स्थान (प्रदेश, शहर, डेटा सेंटर, रॅक, युनिट)
• उपकरणांमधील परस्पर संबंध
• नेटवर्क टोपोलॉजी

हे पूर्णपणे स्पष्ट आहे की आपल्याला हे सर्व जाणून घ्यायचे आहे.
पण हे ऑटोमेशन हेतूंसाठी मदत करेल?
निःसंशयपणे.
उदाहरणार्थ, आम्हाला माहित आहे की लीफ स्विचेसवरील दिलेल्या डेटा सेंटरमध्ये, जर ते Huawei असेल तर, विशिष्ट ट्रॅफिक फिल्टर करण्यासाठी ACL VLAN वर लागू केले जावे आणि जर ते जुनिपर असेल, तर भौतिक इंटरफेसच्या युनिट 0 वर.
किंवा तुम्हाला प्रदेशातील सर्व सीमांवर नवीन Syslog सर्व्हर आणण्याची आवश्यकता आहे.

त्यामध्ये आम्ही व्हर्च्युअल नेटवर्क डिव्हाइसेस संचयित करू, उदाहरणार्थ व्हर्च्युअल राउटर किंवा रूट रिफ्लेक्टर. आम्ही DNS सर्व्हर, NTP, Syslog आणि सर्वसाधारणपणे नेटवर्कशी संबंधित सर्व काही जोडू शकतो.

घटक २: आयपी स्पेस मॅनेजमेंट सिस्टम

होय, आणि आजकाल असे लोकांचे संघ आहेत जे एक्सेल फाइलमध्ये उपसर्ग आणि आयपी पत्त्यांचा मागोवा ठेवतात. परंतु आधुनिक दृष्टीकोन हा अजूनही डेटाबेस आहे, ज्यामध्ये nginx/apache, API आणि व्हीआरएफमध्ये विभागलेले IP पत्ते आणि नेटवर्क रेकॉर्ड करण्यासाठी विस्तृत कार्ये आहेत.
IPAM - IP पत्ता व्यवस्थापन.

आमच्या हेतूंसाठी, आम्ही त्यात खालील माहिती संग्रहित करू:

• व्हीएलएएन
• व्हीआरएफ
• नेटवर्क/सबनेट
• IP पत्ते
• पत्ते डिव्‍हाइसेस, स्‍थानांना नेटवर्क आणि VLAN क्रमांकांना बंधनकारक

पुन्हा, हे स्पष्ट आहे की आम्ही हे सुनिश्चित करू इच्छितो की जेव्हा आम्ही ToR लूपबॅकसाठी नवीन IP पत्ता वाटप करतो, तेव्हा तो आधीच कोणालातरी नियुक्त केला होता या वस्तुस्थितीवर आम्ही अडखळणार नाही. किंवा आम्ही नेटवर्कच्या वेगवेगळ्या टोकांवर दोनदा समान उपसर्ग वापरला.
पण हे ऑटोमेशनमध्ये कशी मदत करते?
सुलभ
आम्ही सिस्टममध्ये लूपबॅक रोलसह उपसर्गाची विनंती करतो, ज्यामध्ये वाटपासाठी उपलब्ध IP पत्ते असतात - जर ते आढळले तर, आम्ही पत्ता वाटप करतो, नसल्यास, आम्ही नवीन उपसर्ग तयार करण्याची विनंती करतो.
किंवा डिव्हाइस कॉन्फिगरेशन तयार करताना, आम्ही त्याच सिस्टममधून शोधू शकतो ज्यामध्ये इंटरफेस VRF असावा.
आणि नवीन सर्व्हर सुरू करताना, स्क्रिप्ट सिस्टममध्ये लॉग इन करते, सर्व्हर कोणत्या स्विचमध्ये आहे हे शोधते, कोणते पोर्ट आणि कोणते सबनेट इंटरफेसला नियुक्त केले आहे - आणि त्यातून सर्व्हर पत्ता वाटप करेल.

हे DCIM आणि IPAM एकाच सिस्टीममध्ये एकत्र करण्याची इच्छा सूचित करते जेणेकरून फंक्शन्स डुप्लिकेट होऊ नये आणि दोन समान संस्थांना सेवा देऊ नये.
आम्ही तेच करू.

घटक 3. नेटवर्क सेवांचे वर्णन करण्यासाठी प्रणाली

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

• पायाभूत सुविधा
• क्लायंट.

पूर्वीचे मूलभूत कनेक्टिव्हिटी आणि डिव्हाइस नियंत्रण प्रदान करण्यासाठी डिझाइन केलेले आहेत. यामध्ये VTY, SNMP, NTP, Syslog, AAA, राउटिंग प्रोटोकॉल, CoPP इ.
नंतरचे क्लायंटसाठी सेवा आयोजित करतात: MPLS L2/L3VPN, GRE, VXLAN, VLAN, L2TP, इ.
अर्थात, सीमारेषा देखील आहेत - एमपीएलएस एलडीपी, बीजीपी कोठे समाविष्ट करावे? होय, आणि राउटिंग प्रोटोकॉल क्लायंटसाठी वापरले जाऊ शकतात. पण हे महत्त्वाचे नाही.

दोन्ही प्रकारच्या सेवा कॉन्फिगरेशन प्रिमिटिव्हमध्ये विघटित केल्या जातात:

• भौतिक आणि तार्किक इंटरफेस (टॅग/अँटेग, एमटीयू)
• IP पत्ते आणि VRF (IP, IPv6, VRF)
• ACL आणि रहदारी प्रक्रिया धोरणे
• प्रोटोकॉल (IGP, BGP, MPLS)
• राउटिंग धोरणे (उपसर्ग सूची, समुदाय, ASN फिल्टर).
• उपयुक्तता सेवा (SSH, NTP, LLDP, Syslog...)
• इ.

हे आपण नेमके कसे करणार, मला अजून कल्पना नाही. आम्ही एका स्वतंत्र लेखात ते पाहू.

आयुष्याच्या थोडं जवळ आलं तर त्याचं वर्णन करता येईल
लीफ स्विचमध्ये सर्व कनेक्टेड स्पाइन स्विचेससह बीजीपी सत्रे असणे आवश्यक आहे, प्रक्रियेमध्ये कनेक्ट केलेले नेटवर्क आयात करणे आणि स्पाइन स्विचमधून विशिष्ट उपसर्गातून फक्त नेटवर्क स्वीकारणे आवश्यक आहे. CoPP IPv6 ND ला 10 pps पर्यंत मर्यादित करा, इ.
या बदल्यात, मणके सर्व जोडलेल्या लीड्ससह सत्रे ठेवतात, रूट रिफ्लेक्टर म्हणून कार्य करतात आणि त्यांच्याकडून केवळ विशिष्ट लांबीचे आणि विशिष्ट समुदायासह मार्ग स्वीकारतात.

घटक 4: डिव्हाइस इनिशियलायझेशन यंत्रणा

या शीर्षकाखाली मी उपकरण रडारवर दिसण्यासाठी आणि दूरस्थपणे प्रवेश करण्यासाठी आवश्यक असलेल्या अनेक क्रिया एकत्र करतो.

1. इन्व्हेंटरी सिस्टममध्ये डिव्हाइस प्रविष्ट करा.
2. व्यवस्थापन IP पत्ता निवडा.
3. त्यावर मूलभूत प्रवेश सेट करा:
   होस्टनाव, व्यवस्थापन IP पत्ता, व्यवस्थापन नेटवर्कचा मार्ग, वापरकर्ते, SSH की, प्रोटोकॉल - टेलनेट/SSH/NETCONF

तीन दृष्टिकोन आहेत:

• सर्व काही पूर्णपणे मॅन्युअल आहे. डिव्हाइस स्टँडवर आणले आहे, जिथे एक सामान्य सेंद्रिय व्यक्ती सिस्टममध्ये प्रवेश करेल, कन्सोलशी कनेक्ट करेल आणि कॉन्फिगर करेल. लहान स्थिर नेटवर्कवर काम करू शकते.
• ZTP - शून्य स्पर्श तरतूद. हार्डवेअर आले, उभे राहिले, DHCP द्वारे पत्ता प्राप्त झाला, विशेष सर्व्हरवर गेला आणि स्वतः कॉन्फिगर केले.
• कन्सोल सर्व्हरची पायाभूत सुविधा, जिथे प्रारंभिक कॉन्फिगरेशन कन्सोल पोर्टद्वारे स्वयंचलित मोडमध्ये होते.

या तिन्हींबद्दल आपण एका स्वतंत्र लेखात बोलू.

घटक 5: विक्रेता-अज्ञेयवादी कॉन्फिगरेशन मॉडेल

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

1. डिव्हाइसशी संवाद साधण्यासाठी विशिष्ट इंटरफेसशी जुळवून घेऊ नका. CLI, NETCONF, RESTCONF, SNMP - मॉडेल समान असेल.
2. नेटवर्कवरील विक्रेत्यांच्या संख्येनुसार टेम्पलेट्स/स्क्रिप्ट्सची संख्या ठेवू नका आणि डिझाइन बदलल्यास, तीच गोष्ट अनेक ठिकाणी बदला.
3. डिव्हाइस (बॅकअप) वरून कॉन्फिगरेशन लोड करा, ते अगदी त्याच मॉडेलमध्ये ठेवा आणि डेल्टाची गणना करण्यासाठी लक्ष्य कॉन्फिगरेशनची विद्यमान कॉन्फिगरेशनशी थेट तुलना करा आणि कॉन्फिगरेशन पॅच तयार करा जे फक्त आवश्यक असलेले भाग बदलेल किंवा विचलन ओळखेल.

या टप्प्याचा परिणाम म्हणून, आम्हाला विक्रेता-स्वतंत्र कॉन्फिगरेशन मिळते.

घटक 6. विक्रेता-विशिष्ट ड्रायव्हर इंटरफेस

एके दिवशी सिस्का ज्युनिपर प्रमाणेच कॉन्फिगर करणे शक्य होईल या आशेने तुम्ही स्वत:ची खुशामत करू नये, फक्त त्यांना तेच कॉल पाठवून. व्हाईटबॉक्सेसची वाढती लोकप्रियता आणि NETCONF, RESTCONF, OpenConfig साठी समर्थनाचा उदय असूनही, हे प्रोटोकॉल विक्रेत्यापासून विक्रेत्यापर्यंत वितरीत करणारी विशिष्ट सामग्री भिन्न आहे आणि हे त्यांच्या स्पर्धात्मक फरकांपैकी एक आहे जे ते इतक्या सहजपणे सोडणार नाहीत.
हे अंदाजे OpenContrail आणि OpenStack सारखेच आहे, ज्यांचे नॉर्थबाउंड इंटरफेस म्हणून RestAPI आहे, पूर्णपणे भिन्न कॉल्सची अपेक्षा करतात.

तर, पाचव्या पायरीमध्ये, विक्रेता-स्वतंत्र मॉडेलने ते हार्डवेअरवर जाणारे फॉर्म घेणे आवश्यक आहे.
आणि येथे सर्व साधन चांगले आहेत (नाही): CLI, NETCONF, RESTCONF, SNMP फक्त.

म्हणून, आम्हाला एका ड्रायव्हरची आवश्यकता असेल जो मागील चरणाचा निकाल विशिष्ट विक्रेत्याच्या आवश्यक स्वरूपात हस्तांतरित करेल: CLI कमांडचा संच, एक XML रचना.

घटक 7. डिव्हाइसवर कॉन्फिगरेशन वितरीत करण्यासाठी यंत्रणा

आम्ही कॉन्फिगरेशन व्युत्पन्न केले आहे, परंतु ते अद्याप डिव्हाइसेसवर वितरित करणे आवश्यक आहे - आणि स्पष्टपणे, हाताने नाही.
पहिल्याने, आम्ही कोणती वाहतूक वापरणार हा प्रश्न आम्हाला भेडसावत आहे. आणि आज निवड यापुढे लहान नाही:

• CLI (टेलनेट, ssh)
• एसएनएमपी
• NETCONF
• RESTCONF
• आरईएसटी API
• ओपनफ्लो (जरी तो आउटलायर आहे कारण तो FIB वितरित करण्याचा एक मार्ग आहे, सेटिंग्ज नाही)

चला येथे टी बिंदू करूया. CLI हा वारसा आहे. SNMP... खोकला खोकला.
RESTCONF अजूनही अज्ञात प्राणी आहे; REST API जवळजवळ कोणीही समर्थित नाही. म्हणून, आम्ही मालिकेत NETCONF वर लक्ष केंद्रित करू.

खरं तर, वाचकाला आधीच समजले आहे, या टप्प्यापर्यंत आम्ही इंटरफेसवर आधीच निर्णय घेतला आहे - मागील चरणाचा परिणाम आधीच निवडलेल्या इंटरफेसच्या स्वरूपात सादर केला गेला आहे.

दुसरे म्हणजे, आणि आम्ही हे कोणत्या साधनांसह करू?
येथे एक मोठी निवड देखील आहे:

• स्व-लिखित स्क्रिप्ट किंवा व्यासपीठ. चला ncclient आणि asyncIO सह स्वतःला सज्ज करूया आणि सर्वकाही स्वतः करूया. सुरवातीपासून उपयोजन प्रणाली तयार करण्यासाठी आम्हाला काय खर्च येईल?
• नेटवर्किंग मॉड्यूल्सच्या समृद्ध लायब्ररीसह उत्तरदायी.
• नेटवर्कसह त्याच्या अल्प कामासह मीठ आणि नॅपलमशी कनेक्शन.
• वास्तविक नेपलम, ज्याला दोन विक्रेते माहित आहेत आणि तेच आहे, अलविदा.
• नॉरनिर हा आणखी एक प्राणी आहे ज्याचे आपण भविष्यात विच्छेदन करू.

येथे आवडते अद्याप निवडले गेले नाही - आम्ही शोधत आहोत.

येथे आणखी काय महत्वाचे आहे? कॉन्फिगरेशन लागू करण्याचे परिणाम.
यशस्वी किंवा नाही. हार्डवेअरमध्ये अजूनही प्रवेश आहे की नाही?
असे दिसते की कमिट येथे डिव्हाइसवर काय डाउनलोड केले होते याची पुष्टी आणि प्रमाणीकरण करण्यात मदत करेल.
हे, NETCONF च्या योग्य अंमलबजावणीसह एकत्रितपणे, योग्य उपकरणांची श्रेणी लक्षणीयरीत्या संकुचित करते - बरेच उत्पादक सामान्य वचनांना समर्थन देत नाहीत. पण ही फक्त एक पूर्वतयारी आहे आरएफपी. शेवटी, एकही रशियन विक्रेता 32*100GE इंटरफेस स्थितीचे पालन करणार नाही याची कोणालाही काळजी नाही. किंवा तो काळजीत आहे?

घटक 8. CI/CD

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

परंतु, वर म्हटल्याप्रमाणे, आम्ही काही प्रकारचे रानटी नाही ज्यांना सर्वकाही थेट उत्पादनात आणायचे आहे.
जनरेट केलेले कॉन्फिगरेशन प्रथम पाइपलाइन CI/CD मधून जाणे आवश्यक आहे.

CI/CD चा अर्थ सतत एकात्मता, सतत तैनाती. हा एक असा दृष्टीकोन आहे ज्यामध्ये संघ दर सहा महिन्यांनी नवीन प्रमुख प्रकाशन केवळ जुन्याची पूर्णपणे बदली करत नाही, तर लहान भागांमध्ये नियमितपणे वाढीव प्रमाणात (उपयोजन) नवीन कार्यक्षमतेची अंमलबजावणी करतो, ज्यापैकी प्रत्येकाची सुसंगतता, सुरक्षितता आणि सर्वसमावेशकपणे चाचणी केली जाते. कामगिरी (एकीकरण).

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

डीबगिंग कमांड्सचा अपवाद वगळता, नेटवर्कवरील सर्व बदल सीआय/सीडी पाइपलाइनमधूनच झाले पाहिजेत - हीच आमची शांत आयुष्य आणि दीर्घ, आनंदी करिअरची हमी आहे.

घटक 9. बॅकअप आणि विसंगती शोध प्रणाली

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

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

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

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

घटक 10. देखरेख प्रणाली

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

विकसित विचार हा CI/CD प्रक्रियेचा एक सेंद्रिय भाग आहे. नेटवर्कवर कॉन्फिगरेशन रोल आउट केल्यानंतर, आता सर्व काही ठीक आहे की नाही हे निर्धारित करण्यात आम्हाला सक्षम असणे आवश्यक आहे.
आणि आम्ही फक्त इंटरफेस वापर शेड्यूल किंवा नोड उपलब्धता याबद्दल बोलत नाही तर अधिक सूक्ष्म गोष्टींबद्दल बोलत आहोत - आवश्यक मार्गांची उपस्थिती, त्यांच्यावरील गुणधर्म, बीजीपी सत्रांची संख्या, ओएसपीएफ शेजारी, एंड-टू-एंड कामगिरी. अत्याधिक सेवांचा.
बाह्य सर्व्हरवर syslogs जोडणे थांबले, किंवा SFlow एजंट तुटले, किंवा रांगेतील थेंब वाढू लागले, किंवा काही उपसर्ग जोडण्यांमधील कनेक्टिव्हिटी तुटली का?

आम्ही एका स्वतंत्र लेखात यावर विचार करू.

निष्कर्ष

आधार म्हणून, मी एक आधुनिक डेटा सेंटर नेटवर्क डिझाइन निवडले - L3 Clos फॅब्रिक BGP सह रूटिंग प्रोटोकॉल म्हणून.
यावेळी आम्ही ज्युनिपरवर नेटवर्क तयार करू, कारण आता जुनोस इंटरफेस एक व्हॅनलव्ह आहे.

फक्त ओपन सोर्स टूल्स आणि मल्टी-व्हेंडर नेटवर्क वापरून आपण आपले जीवन अधिक कठीण करूया - त्यामुळे ज्युनिपर व्यतिरिक्त, मी वाटेत आणखी एक भाग्यवान व्यक्ती निवडेन.

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

आणि हो, मी तयार सोल्यूशनसह हे चक्र कृपापूर्वक समाप्त करण्याचे वचन देत नाही. 🙂

उपयुक्त दुवे

• मालिकेत जाण्यापूर्वी, नताशा सामोइलेन्कोचे पुस्तक वाचण्यासारखे आहे नेटवर्क अभियंत्यांसाठी पायथन. आणि कदाचित पास अर्थातच.
• वाचायलाही उपयोगी पडेल RFC पीटर लापुखोव्हने फेसबुकवरील डेटा सेंटर कारखान्यांच्या डिझाइनबद्दल.
• आर्किटेक्चर दस्तऐवजीकरण तुम्हाला ओव्हरले SDN कसे कार्य करते याची कल्पना देईल. टंगस्टन फॅब्रिक (पूर्वी ओपन कॉन्ट्रेल).

धन्यवाद

रोमन गॉर्ज. टिप्पण्या आणि संपादनांसाठी.
आर्टिओम चेरनोबे. KDPV साठी.

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