SDSM सकियो, तर लेख्ने अनियन्त्रित चाहना बाँकी छ।

धेरै वर्षदेखि, हाम्रो भाइले दिनचर्या काम गर्न, कमिट गर्नु अघि आफ्नो औंलाहरू पार गर्न र रातको रोलब्याकको कारणले निद्राको कमी भोग्नुपरेको थियो।
तर अँध्यारो समयको अन्त्य हुँदैछ।

यस लेखको साथ म कसरी एक श्रृंखला सुरु गर्नेछु म स्वचालन देखिन्छ।
बाटोमा, हामीले स्वचालनका चरणहरू, भ्यारीएबलहरू भण्डारण गर्ने, औपचारिक डिजाइन, RestAPI, NETCONF, YANG, YDK को चरणहरू बुझ्नेछौं र हामी धेरै प्रोग्रामिङ गर्नेछौं।
मलाई यसको मतलब यो हो कि क) यो वस्तुगत सत्य होइन, ख) यो बिना शर्त उत्तम दृष्टिकोण होइन, ग) मेरो विचार, पहिलो देखि अन्तिम लेख सम्मको आन्दोलनको समयमा पनि, परिवर्तन हुन सक्छ - इमानदार हुन, मस्यौदा चरणबाट प्रकाशन, मैले सबै कुरा पूर्ण रूपमा दुई पटक पुन: लेखे।

सामग्रीहरू

1. उद्देश्यहरू
   1. नेटवर्क एकल जीव जस्तै छ
   2. कन्फिगरेसन परीक्षण
   3. संस्करण
   4. सेवाहरूको अनुगमन र आत्म-उपचार

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

3. निष्कर्षमा

म SDSM भन्दा अलि फरक ढाँचामा ADSM सञ्चालन गर्ने प्रयास गर्नेछु। ठूला, विस्तृत, अंकित लेखहरू देखा पर्न जारी रहनेछन्, र तिनीहरूको बीचमा म दैनिक अनुभवबाट साना नोटहरू प्रकाशित गर्नेछु। म यहाँ पूर्णतावादसँग लड्ने प्रयास गर्नेछु र ती सबैलाई चाट्ने छैन।

कति रमाइलो छ दोश्रो पटक एउटै बाटो भएर हिड्नु पर्ने ।

सुरुमा मैले नेटवर्कहरूको बारेमा लेखहरू लेख्नुपर्‍यो किनभने तिनीहरू RuNet मा थिएनन्।

अब मैले एक व्यापक कागजात फेला पार्न सकेन जसले स्वचालनको दृष्टिकोणलाई व्यवस्थित गर्नेछ र सरल व्यावहारिक उदाहरणहरू प्रयोग गरेर माथिका प्रविधिहरूको विश्लेषण गर्नेछ।

म गलत हुन सक्छु, त्यसैले कृपया उपयोगी स्रोतहरूको लिङ्क प्रदान गर्नुहोस्। जे होस्, यसले मेरो लेख्ने दृढ संकल्पलाई परिवर्तन गर्दैन, किनकि मुख्य लक्ष्य भनेको आफैंले केहि सिक्नु हो, र अरूको लागि जीवनलाई सजिलो बनाउनु भनेको अनुभव साझा गर्नको लागि जीनलाई माया गर्ने सुखद बोनस हो।

हामी एक मध्यम आकारको LAN DC डाटा सेन्टर लिने प्रयास गर्नेछौं र सम्पूर्ण स्वचालन योजनाको काम गर्नेछौं।
म तपाइँसँग लगभग पहिलो पटक केहि चीजहरू गर्दैछु।

यहाँ वर्णन गरिएका विचार र उपकरणहरूमा म मौलिक हुनेछैन। दिमित्री फिगोलसँग उत्कृष्ट छ यस विषयमा स्ट्रिमहरू भएको च्यानल.
लेखहरू तिनीहरूसँग धेरै पक्षहरूमा ओभरल्याप हुनेछन्।

LAN DC मा 4 DC, लगभग 250 स्विचहरू, आधा दर्जन राउटरहरू र केही फायरवालहरू छन्।
फेसबुक होइन, तर तपाईलाई स्वचालनको बारेमा गहिरो सोच्नको लागि पर्याप्त छ।
यद्यपि, त्यहाँ एक राय छ कि यदि तपाइँसँग 1 भन्दा बढी उपकरण छ भने, स्वचालन पहिले नै आवश्यक छ।
वास्तवमा, यो कल्पना गर्न गाह्रो छ कि अब कोही पनि कम्तिमा घुँडा लिपिको प्याक बिना बाँच्न सक्छ।
यद्यपि मैले सुनेको छु कि त्यहाँ अफिसहरू छन् जहाँ IP ठेगानाहरू Excel मा राखिन्छन्, र हजारौं नेटवर्क उपकरणहरू मध्ये प्रत्येक म्यानुअल रूपमा कन्फिगर गरिएको छ र यसको आफ्नै अद्वितीय कन्फिगरेसन छ। यो, निस्सन्देह, आधुनिक कलाको रूपमा पारित गर्न सकिन्छ, तर इन्जिनियरको भावना निश्चित रूपमा अपमानित हुनेछ।

उद्देश्यहरू

अब हामी सबैभन्दा अमूर्त लक्ष्यहरू सेट गर्नेछौं:

• नेटवर्क एकल जीव जस्तै छ
• कन्फिगरेसन परीक्षण
• नेटवर्क राज्य संस्करण
• सेवाहरूको अनुगमन र आत्म-उपचार

यस लेखमा पछि हामी हामीले प्रयोग गर्ने माध्यमहरू हेर्नेछौं, र निम्नमा, हामी लक्ष्य र माध्यमहरू विस्तारमा हेर्नेछौं।

नेटवर्क एकल जीव जस्तै छ

शृङ्खलाको परिभाषित वाक्यांश, यद्यपि पहिलो नजरमा यो यति महत्त्वपूर्ण नहुन सक्छ: हामी नेटवर्क कन्फिगर गर्नेछौं, व्यक्तिगत उपकरणहरू होइन.
हालैका वर्षहरूमा, हामीले नेटवर्कलाई एकल इकाईको रूपमा व्यवहार गर्नेतर्फ जोडमा परिवर्तन देखेका छौं, त्यसैले परिभाषित नेटवर्कि Software सफ्टवेयर, उद्देश्य संचालित नेटवर्कहरू и स्वायत्त नेटवर्कहरू.
आखिर, नेटवर्कबाट एप्लिकेसनहरूलाई विश्वव्यापी रूपमा के चाहिन्छ: बिन्दु A र B बीचको जडान (राम्रो, कहिलेकाहीँ +B-Z) र अन्य अनुप्रयोगहरू र प्रयोगकर्ताहरूबाट अलगाव।

र यस श्रृंखलामा हाम्रो कार्य हो एक प्रणाली निर्माण, हालको कन्फिगरेसन कायम गर्दै सम्पूर्ण नेटवर्क, जुन पहिले नै यसको भूमिका र स्थान अनुसार प्रत्येक यन्त्रमा वास्तविक कन्फिगरेसनमा विघटन गरिएको छ।
सिस्टम सञ्जाल व्यवस्थापनले परिवर्तन गर्नको लागि हामीले यसलाई सम्पर्क गर्छौं भन्ने बुझाउँछ, र यसले प्रत्येक यन्त्रको वांछित अवस्थाको गणना गर्छ र यसलाई कन्फिगर गर्छ।
यसरी, हामी CLI मा म्यानुअल पहुँचलाई लगभग शून्यमा कम गर्छौं - यन्त्र सेटिङहरू वा नेटवर्क डिजाइनमा कुनै पनि परिवर्तनहरू औपचारिक र दस्तावेज हुनुपर्छ - र त्यसपछि मात्र आवश्यक नेटवर्क तत्वहरूमा रोल आउट गरिन्छ।

त्यो हो, उदाहरणका लागि, यदि हामीले निर्णय गर्यौं कि अबदेखि काजानमा र्याक स्विचहरूले एउटाको सट्टा दुईवटा नेटवर्कहरू घोषणा गर्नुपर्छ, हामी

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

एकै समयमा, हामी पहिलो चरणमा मात्र म्यानुअल रूपमा परिवर्तनहरू गर्छौं।

कन्फिगरेसन परीक्षण

ज्ञातकि 80% समस्याहरू कन्फिगरेसन परिवर्तनहरूमा देखा पर्दछ - यसको अप्रत्यक्ष प्रमाण यो हो कि नयाँ वर्षको बिदामा सबै कुरा सामान्यतया शान्त हुन्छ।
मैले व्यक्तिगत रूपमा मानव त्रुटिको कारण दर्जनौं विश्वव्यापी डाउनटाइमहरू देखेको छु: गलत आदेश, कन्फिगरेसन गलत शाखामा कार्यान्वयन गरिएको थियो, समुदायले बिर्सियो, MPLS राउटरमा विश्वव्यापी रूपमा ध्वस्त भयो, हार्डवेयरका पाँच टुक्राहरू कन्फिगर गरियो, तर त्रुटि थिएन। छैटौंमा देखियो, अर्को व्यक्तिले गरेको पुरानो परिवर्तनहरू प्रतिबद्ध थिए। त्यहाँ एक टन परिदृश्यहरू छन्।

स्वचालनले हामीलाई कम गल्तीहरू गर्न अनुमति दिनेछ, तर ठूलो मात्रामा। यस तरिकाले तपाईले एउटा उपकरण मात्र होइन, तर सम्पूर्ण नेटवर्कलाई एकैचोटि ईंट गर्न सक्नुहुन्छ।

अनादिकालदेखि नै, हाम्रा हजुरबुवाहरूले गहिरो आँखा, स्टिलका बलहरू र रोल आउट भएपछि नेटवर्कको कार्यक्षमताका साथ गरिएका परिवर्तनहरूको शुद्धता जाँच गरे।
ती हजुरबुबा जसको कामले डाउनटाइम र विनाशकारी हानि निम्त्यायो उनीहरूले थोरै सन्तान छोडे र समयसँगै मर्नुपर्छ, तर विकास एक ढिलो प्रक्रिया हो, र त्यसैले सबैले अझै पनि प्रयोगशालामा परिवर्तनहरू परीक्षण गर्दैनन्।
यद्यपि, प्रगतिको अगाडि ती व्यक्तिहरू हुन् जसले कन्फिगरेसन परीक्षण गर्ने प्रक्रिया र नेटवर्कमा यसको थप अनुप्रयोगलाई स्वचालित बनाएका छन्। अर्को शब्दमा, मैले CI/CD प्रक्रिया उधारो (निरन्तर एकीकरण, निरन्तर तैनाती) विकासकर्ताहरूबाट।
एउटा भागमा हामी यसलाई कसरी कार्यान्वयन गर्ने भनेर हेर्नेछौं संस्करण नियन्त्रण प्रणाली, सम्भवतः Github।

एकचोटि तपाईंले नेटवर्क CI/CD को विचारमा प्रयोग गरिसकेपछि, उत्पादन नेटवर्कमा लागू गरेर कन्फिगरेसन जाँच गर्ने विधि रातारात प्रारम्भिक मध्ययुगीन अज्ञान जस्तो देखिन्छ। हथौडाले वारहेड प्रहार गरे जस्तै।

बारेमा विचारहरूको एक जैविक निरन्तरता प्रणाली नेटवर्क व्यवस्थापन र CI/CD कन्फिगरेसनको पूर्ण संस्करण हुन्छ।

संस्करण

हामी मान्नेछौं कि कुनै पनि परिवर्तनको साथमा, सबै भन्दा सानोमा पनि, एक नदेखीने उपकरणमा पनि, सम्पूर्ण नेटवर्क एक राज्यबाट अर्कोमा सर्छ।
र हामी सधैं यन्त्रमा आदेश कार्यान्वयन गर्दैनौं, हामी नेटवर्कको स्थिति परिवर्तन गर्छौं।
त्यसोभए यी राज्य संस्करणहरू कल गरौं?

मानौं हालको संस्करण १.०.० हो।
के कुनै एउटा ToR मा लुपब्याक इन्टरफेसको IP ठेगाना परिवर्तन भएको छ? यो एक सानो संस्करण हो र 1.0.1 नम्बर हुनेछ।
हामीले BGP मा मार्गहरू आयात गर्ने नीतिहरू परिमार्जन गरेका छौं - अलि बढी गम्भीर रूपमा - पहिले नै 1.1.0
हामीले IGP बाट छुटकारा पाउन र BGP मा मात्र स्विच गर्ने निर्णय गर्यौं - यो पहिले नै एक कट्टरपन्थी डिजाइन परिवर्तन हो - 2.0.0।

एकै समयमा, विभिन्न DC को विभिन्न संस्करणहरू हुन सक्छन् - नेटवर्क विकास हुँदैछ, नयाँ उपकरणहरू स्थापना भइरहेको छ, स्पाइनहरूको नयाँ स्तरहरू कतै थपिँदै छन्, अरूमा होइन, आदि।

बारेमा सिमेन्टिक संस्करण हामी छुट्टै लेखमा कुरा गर्नेछौं।

म दोहोर्याउँछु - कुनै पनि परिवर्तन (डिबगिङ आदेशहरू बाहेक) संस्करण अद्यावधिक हो। प्रशासकहरूलाई हालको संस्करणबाट कुनै पनि विचलन बारे सूचित गरिनुपर्छ।

उही परिवर्तनहरू रोलिङ ब्याकमा लागू हुन्छ - यसले अन्तिम आदेशहरू रद्द गर्दैन, यो यन्त्रको अपरेटिङ सिस्टम प्रयोग गरेर रोलब्याक होइन - यसले सम्पूर्ण नेटवर्कलाई नयाँ (पुरानो) संस्करणमा ल्याउँदैछ।

सेवाहरूको अनुगमन र आत्म-उपचार

यो आत्म-स्पष्ट कार्य आधुनिक नेटवर्क मा एक नयाँ स्तर पुगेको छ।
अक्सर, ठूला सेवा प्रदायकहरूले असफल सेवालाई के भयो भनेर पत्ता लगाउनुको सट्टा एकदमै चाँडो समाधान गर्न र एउटा नयाँ उठाउनु पर्ने दृष्टिकोण राख्छन्।
"धेरै" को अर्थ हो कि तपाईलाई उदारतापूर्वक अनुगमनको साथ सबै पक्षहरूमा लेपित गर्न आवश्यक छ, जसले सेकेन्ड भित्र सामान्यबाट थोरै विचलनहरू पत्ता लगाउनेछ।
र यहाँ सामान्य मेट्रिक्स, जस्तै इन्टरफेस लोडिङ वा नोड उपलब्धता, अब पर्याप्त छैन। ड्युटी अफिसरबाट उनीहरुको म्यानुअल अनुगमन पनि पर्याप्त छैन।
धेरै चीजहरूको लागि त्यहाँ हुनुपर्छ आत्म-चिकित्सा - निगरानी बत्ती रातो भयो र हामी गयौं र दुखेको ठाउँमा केर आफैं लगायौं।

र यहाँ हामी व्यक्तिगत उपकरणहरू मात्र होइन, तर सम्पूर्ण नेटवर्कको स्वास्थ्यलाई पनि निगरानी गर्छौं, दुवै ह्वाइटबक्स, जुन अपेक्षाकृत बुझ्न सकिन्छ, र ब्ल्याकबक्स, जुन अझ जटिल छ।

यस्ता महत्वाकांक्षी योजनाहरू कार्यान्वयन गर्न हामीले के चाहिन्छ?

• नेटवर्कमा रहेका सबै उपकरणहरूको सूची, तिनीहरूको स्थान, भूमिका, मोडेल, सफ्टवेयर संस्करणहरू।
  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. CI / CD
9. ब्याकअपको लागि संयन्त्र र विचलनहरूको खोजी
10. अनुगमन प्रणाली

यो, वैसे, चक्र को लक्ष्य मा दृश्य कसरी परिवर्तन को एक उदाहरण हो - मस्यौदा मा 4 घटक थिए।

दृष्टान्तमा मैले सबै कम्पोनेन्टहरू र यन्त्र नै चित्रण गरें।
प्रतिच्छेदन घटकहरू एकअर्कासँग अन्तरक्रिया गर्छन्।
ठूलो ब्लक, यो कम्पोनेन्टमा बढी ध्यान दिनु आवश्यक छ।

कम्पोनेन्ट 1: सूची प्रणाली

जाहिर छ, हामी जान्न चाहन्छौं कि कुन उपकरण कहाँ अवस्थित छ, केसँग जोडिएको छ।
सूची प्रणाली कुनै पनि उद्यम को एक अभिन्न अंग हो।
प्रायः, एक उद्यमसँग नेटवर्क उपकरणहरूको लागि छुट्टै सूची प्रणाली छ, जसले थप विशिष्ट समस्याहरू समाधान गर्दछ।
लेखहरूको यस शृङ्खलाको भागको रूपमा, हामी यसलाई DCIM - डेटा केन्द्र पूर्वाधार व्यवस्थापन भन्नेछौं। यद्यपि DCIM शब्द आफैंमा, कडाईका साथ बोल्दा, धेरै धेरै समावेश छ।

हाम्रो उद्देश्यका लागि, हामी यसमा उपकरणको बारेमा निम्न जानकारी भण्डार गर्नेछौं:

• इन्भेन्टरी नम्बर
• शीर्षक/विवरण
• मोडेल (Huawei CE12800, Juniper QFX5120, आदि।)
• विशेषता प्यारामिटर (बोर्ड, इन्टरफेस, आदि।)
• भूमिका (पात, मेरुदण्ड, बोर्डर राउटर, आदि।)
• स्थान (क्षेत्र, शहर, डाटा केन्द्र, र्याक, एकाई)
• यन्त्रहरू बीचको अन्तरसम्बन्ध
• नेटवर्क टोपोलोजी

यो पूर्ण रूपमा स्पष्ट छ कि हामी आफैले यो सबै जान्न चाहन्छौं।
तर के यसले स्वचालन उद्देश्यका लागि मद्दत गर्नेछ?
निस्सन्देह।
उदाहरणका लागि, हामीलाई थाहा छ कि लीफ स्विचहरूमा दिइएको डाटा सेन्टरमा, यदि यो Huawei हो भने, निश्चित ट्राफिकहरू फिल्टर गर्न ACLs VLAN मा लागू गरिनुपर्छ, र यदि जुनिपर हो भने, भौतिक इन्टरफेसको एकाइ 0 मा।
वा तपाईंले क्षेत्रका सबै सीमानाहरूमा नयाँ Syslog सर्भर रोल आउट गर्न आवश्यक छ।

यसमा हामी भर्चुअल नेटवर्क उपकरणहरू भण्डार गर्नेछौं, उदाहरणका लागि भर्चुअल राउटरहरू वा रूट रिफ्लेक्टरहरू। हामी DNS सर्भरहरू, NTP, Syslog र सामान्य रूपमा सबै चीजहरू थप्न सक्छौं जुन कुनै न कुनै रूपमा नेटवर्कसँग सम्बन्धित छ।

कम्पोनेन्ट २: आईपी स्पेस व्यवस्थापन प्रणाली

हो, र आजकल त्यहाँ व्यक्तिहरूको टोलीहरू छन् जसले Excel फाइलमा उपसर्गहरू र IP ठेगानाहरूको ट्र्याक राख्छन्। तर आधुनिक दृष्टिकोण अझै पनि डाटाबेस हो, जसमा nginx/apache, API र VRF मा विभाजित IP ठेगानाहरू र नेटवर्कहरू रेकर्ड गर्नका लागि विस्तृत कार्यहरू छन्।
IPAM - IP ठेगाना व्यवस्थापन।

हाम्रो उद्देश्यका लागि, हामी यसमा निम्न जानकारी भण्डार गर्नेछौं:

• VLANs
• VRF
• नेटवर्क/सबनेटहरू
• आईपी ​​ठेगानाहरू
• यन्त्रहरूमा ठेगानाहरू, स्थानहरूमा नेटवर्कहरू र VLAN नम्बरहरू बाइन्डिङ

फेरि, यो स्पष्ट छ कि हामी यो सुनिश्चित गर्न चाहन्छौं कि जब हामीले ToR लुपब्याकको लागि नयाँ आईपी ठेगाना आवंटित गर्छौं, हामी यो तथ्यलाई ठेस लाग्ने छैनौं कि यो पहिले नै कसैलाई तोकिएको थियो। वा हामीले नेटवर्कको विभिन्न छेउमा दुई पटक समान उपसर्ग प्रयोग गर्यौं।
तर यसले स्वचालनमा कसरी मद्दत गर्छ?
सजिलो
हामी प्रणालीमा लुपब्याक भूमिकाको साथमा एउटा उपसर्ग अनुरोध गर्छौं, जसमा विनियोजनको लागि उपलब्ध IP ठेगानाहरू छन् - यदि यो फेला पर्यो भने, हामी ठेगाना आवंटित गर्छौं, यदि होइन भने, हामी नयाँ उपसर्ग सिर्जना गर्न अनुरोध गर्छौं।
वा यन्त्र कन्फिगरेसन सिर्जना गर्दा, हामी त्यही प्रणालीबाट पत्ता लगाउन सक्छौं जसमा VRF इन्टरफेस अवस्थित हुनुपर्छ।
र नयाँ सर्भर सुरु गर्दा, स्क्रिप्टले प्रणालीमा लग इन गर्छ, पत्ता लगाउँदछ कि कुन स्विच सर्भरमा छ, कुन पोर्ट र कुन सबनेट इन्टरफेसमा तोकिएको छ - र त्यसबाट सर्भर ठेगाना आवंटित गर्नेछ।

यसले DCIM र IPAM लाई एउटै प्रणालीमा संयोजन गर्ने इच्छालाई सुझाव दिन्छ ताकि कार्यहरू डुप्लिकेट नहोस् र दुई समान संस्थाहरू सेवा नगर्नुहोस्।
हामीले गर्ने त्यही हो।

कम्पोनेन्ट 3. नेटवर्क सेवाहरू वर्णन गर्न प्रणाली

यदि पहिलो दुई प्रणालीहरूले भ्यारीएबलहरू भण्डारण गर्दछ जुन अझै पनि कुनै न कुनै रूपमा प्रयोग गर्न आवश्यक छ, त्यसपछि तेस्रोले प्रत्येक यन्त्र भूमिकाको लागि यसलाई कसरी कन्फिगर गर्नुपर्छ भनेर वर्णन गर्दछ।
यो नेटवर्क सेवा को दुई फरक प्रकार भेद लायक छ:

• पूर्वाधार
• ग्राहक।

पहिलेको आधारभूत जडान र उपकरण नियन्त्रण प्रदान गर्न डिजाइन गरिएको हो। यसमा VTY, SNMP, NTP, Syslog, AAA, रूटिङ प्रोटोकल, CoPP, आदि समावेश छन्।
पछिल्लो ग्राहकको लागि सेवा व्यवस्थित गर्नुहोस्: MPLS L2/L3VPN, GRE, VXLAN, VLAN, L2TP, आदि।
अवश्य पनि, त्यहाँ सीमा रेखा केसहरू पनि छन् - MPLS LDP, BGP कहाँ समावेश गर्ने? हो, र राउटिंग प्रोटोकलहरू ग्राहकहरूको लागि प्रयोग गर्न सकिन्छ। तर यो महत्त्वपूर्ण छैन।

दुबै प्रकारका सेवाहरू कन्फिगरेसन प्रिमिटिवहरूमा विघटित हुन्छन्:

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

हामीले यो कसरी गर्ने हो, मलाई अझै थाहा छैन। हामी यसलाई छुट्टै लेखमा हेर्नेछौं।

यदि जीवनको अलिकति नजिक छ भने, हामी त्यो वर्णन गर्न सक्छौं
लीफ स्विचमा सबै जडान गरिएका स्पाइन स्विचहरूसँग BGP सत्रहरू हुनुपर्छ, प्रक्रियामा जडान गरिएका नेटवर्कहरू आयात गर्नुहोस्, र स्पाइन स्विचहरूबाट निश्चित उपसर्गबाट ​​मात्र नेटवर्कहरू स्वीकार गर्नुहोस्। CoPP IPv6 ND लाई 10 pps मा सीमित गर्नुहोस्, आदि।
बदलामा, स्पाइनहरूले रूट रिफ्लेक्टरको रूपमा काम गर्दै सबै जडान गरिएका लिडहरूसँग सत्रहरू राख्छन्, र तिनीहरूबाट एक निश्चित लम्बाइ र निश्चित समुदायसँग मात्र मार्गहरू स्वीकार गर्छन्।

कम्पोनेन्ट ४: यन्त्र प्रारम्भिकरण संयन्त्र

यस शीर्षक अन्तर्गत मैले उपकरणहरू रडारमा देखा पर्न र टाढाबाट पहुँच गर्नको लागि हुनै पर्ने धेरै कार्यहरू संयोजन गर्दछु।

1. सूची प्रणालीमा उपकरण प्रविष्ट गर्नुहोस्।
2. व्यवस्थापन IP ठेगाना चयन गर्नुहोस्।
3. यसमा आधारभूत पहुँच सेट अप गर्नुहोस्:
   होस्टनाम, व्यवस्थापन IP ठेगाना, व्यवस्थापन नेटवर्कको लागि मार्ग, प्रयोगकर्ताहरू, SSH कुञ्जीहरू, प्रोटोकलहरू - telnet/SSH/NETCONF

त्यहाँ तीन दृष्टिकोण छन्:

• सबै पूर्ण रूपमा म्यानुअल छ। उपकरण स्ट्यान्डमा ल्याइएको छ, जहाँ एक साधारण जैविक व्यक्तिले यसलाई प्रणालीहरूमा प्रवेश गर्नेछ, कन्सोलमा जडान गर्नुहोस् र यसलाई कन्फिगर गर्नुहोस्। साना स्थिर नेटवर्कहरूमा काम गर्न सक्छ।
• ZTP - शून्य टच प्रावधान। हार्डवेयर आइपुग्यो, खडा भयो, DHCP मार्फत ठेगाना प्राप्त गर्‍यो, विशेष सर्भरमा गयो, र आफैं कन्फिगर भयो।
• कन्सोल सर्भरको पूर्वाधार, जहाँ प्रारम्भिक कन्फिगरेसन स्वचालित मोडमा कन्सोल पोर्ट मार्फत हुन्छ।

हामी एक अलग लेख मा सबै तीन को बारे मा कुरा गर्नेछौं।

कम्पोनेन्ट ५: विक्रेता-अज्ञेयवादी कन्फिगरेसन मोडेल

अहिले सम्म, सबै प्रणालीहरू भिन्न प्याचहरू छन् जसले चरहरू प्रदान गर्दछ र हामीले नेटवर्कमा के हेर्न चाहन्छौं भन्ने घोषणात्मक विवरण प्रदान गर्दछ। तर ढिलो वा चाँडो, तपाईंले विशेषसँग सम्झौता गर्नुपर्नेछ।
यस चरणमा, प्रत्येक विशिष्ट यन्त्रको लागि, प्रिमिटिभहरू, सेवाहरू र चरहरूलाई कन्फिगरेसन मोडेलमा मिलाइन्छ जुन वास्तवमा एक विशिष्ट उपकरणको पूर्ण कन्फिगरेसन वर्णन गर्दछ, केवल विक्रेता-तटस्थ तरिकामा।
यो कदमले के गर्छ? किन तुरुन्तै एक उपकरण कन्फिगरेसन सिर्जना नगर्नुहोस् जुन तपाइँ सजिलै अपलोड गर्न सक्नुहुन्छ?
वास्तवमा, यसले तीन समस्याहरू समाधान गर्छ:

1. यन्त्रसँग अन्तरक्रिया गर्नको लागि एक विशेष इन्टरफेसमा अनुकूलन नगर्नुहोस्। CLI, NETCONF, RESTCONF, SNMP - मोडेल उस्तै हुनेछ।
2. नेटवर्कमा विक्रेताहरूको संख्या अनुसार टेम्प्लेट/स्क्रिप्टहरूको संख्या नराख्नुहोस्, र यदि डिजाइन परिवर्तन भयो भने, धेरै ठाउँहरूमा एउटै कुरा परिवर्तन गर्नुहोस्।
3. यन्त्र (ब्याकअप) बाट कन्फिगरेसन लोड गर्नुहोस्, यसलाई ठ्याक्कै उही मोडेलमा राख्नुहोस् र डेल्टा गणना गर्नको लागि अवस्थित एकसँग लक्ष्य कन्फिगरेसन सीधै तुलना गर्नुहोस् र कन्फिगरेसन प्याच तयार गर्नुहोस् जसले केवल ती भागहरू परिवर्तन गर्दछ जुन आवश्यक छ वा विचलनहरू पहिचान गर्न।

यस चरणको परिणामको रूपमा, हामीले विक्रेता-स्वतन्त्र कन्फिगरेसन प्राप्त गर्छौं।

कम्पोनेन्ट 6. विक्रेता-विशेष चालक इन्टरफेस

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

त्यसोभए, पाँचौं चरणमा, विक्रेता-स्वतन्त्र मोडेलले फारम लिनुपर्छ जसमा यो हार्डवेयरमा जान्छ।
र यहाँ सबै माध्यमहरू राम्रो छन् (होइन): CLI, NETCONF, RESTCONF, SNMP सरल।

त्यसकारण, हामीलाई एक ड्राइभर चाहिन्छ जसले अघिल्लो चरणको नतिजालाई निर्दिष्ट विक्रेताको आवश्यक ढाँचामा स्थानान्तरण गर्नेछ: CLI आदेशहरूको सेट, XML संरचना।

कम्पोनेन्ट 7. उपकरणमा कन्फिगरेसन डेलिभर गर्नको लागि संयन्त्र

हामीले कन्फिगरेसन उत्पन्न गरेका छौं, तर यसलाई अझै पनि उपकरणहरूमा डेलिभर गर्न आवश्यक छ - र, स्पष्ट रूपमा, हातले होइन।
पहिलेहामी कुन यातायात प्रयोग गर्ने भन्ने प्रश्नको सामना गरिरहेका छौं? र आज छनोट अब सानो छैन:

• CLI (टेलनेट, ssh)
• प्रणालीमोनिटर Comment
• NETCONF
• RESTCONF
• REST API
• ओपनफ्लो (यद्यपि यो आउटलियर हो किनभने यो FIB डेलिभर गर्ने तरिका हो, सेटिङहरू होइन)

यहाँ टी डट गरौं। CLI विरासत हो। SNMP... खोकी खोकी।
RESTCONF अझै पनि अज्ञात जनावर हो; REST API लगभग कसैले पनि समर्थन गर्दैन। त्यसैले, हामी श्रृंखलामा NETCONF मा ध्यान केन्द्रित गर्नेछौं।

वास्तवमा, पाठकले पहिले नै बुझेका छन्, यस बिन्दुमा हामीले पहिले नै इन्टरफेसमा निर्णय गरिसकेका छौं - अघिल्लो चरणको नतिजा पहिले नै छनौट गरिएको इन्टरफेसको ढाँचामा प्रस्तुत गरिएको छ।

दोस्रो, र हामी यो के उपकरण संग गर्नेछौं?
यहाँ पनि ठूलो विकल्प छ:

• स्व-लिखित स्क्रिप्ट वा प्लेटफर्म। ncclient र asyncIO संग आफुलाई सशक्त गरौं र सबै कुरा आफै गरौं। स्क्र्याचबाट डिप्लोइमेन्ट प्रणाली निर्माण गर्न हामीलाई के खर्च लाग्छ?
• यसको सञ्जाल मोड्युलहरूको समृद्ध पुस्तकालयको साथ उत्तरदायी।
• नेटवर्क र Napalm संग जडान संग यसको अल्प काम संग नुन।
• वास्तवमा नेपल्म, जसले केही विक्रेताहरूलाई चिन्छ र त्यो हो, अलविदा।
• Nornir अर्को जनावर हो जुन हामी भविष्यमा विच्छेद गर्नेछौं।

यहाँ मनपर्ने अझै छनोट गरिएको छैन - हामी खोजी हुनेछ।

यहाँ अरू के महत्त्वपूर्ण छ? कन्फिगरेसन लागू गर्ने परिणामहरू।
सफल होस् या नहोस् । हार्डवेयरमा अझै पहुँच छ कि छैन?
यस्तो देखिन्छ कि कमिटले यहाँ उपकरणमा डाउनलोड गरिएको कुराको पुष्टिकरण र प्रमाणीकरणको साथ मद्दत गर्दछ।
यो, NETCONF को सही कार्यान्वयनसँग मिलाएर, उपयुक्त उपकरणहरूको दायरालाई महत्त्वपूर्ण रूपमा संकुचित गर्दछ - धेरै निर्माताहरूले सामान्य प्रतिबद्धताहरूलाई समर्थन गर्दैनन्। तर यो केवल पूर्व शर्तहरु मध्ये एक हो RFP। अन्तमा, कुनै पनि रूसी विक्रेताले 32*100GE इन्टरफेस अवस्थाको पालना गर्दैन भनेर चिन्तित छैन। वा उहाँ चिन्तित हुनुहुन्छ?

कम्पोनेन्ट ८. CI/CD

यस बिन्दुमा, हामीसँग पहिले नै सबै नेटवर्क उपकरणहरूको लागि कन्फिगरेसन तयार छ।
म "सबैका लागि" लेख्छु किनभने हामी नेटवर्क राज्य संस्करणको बारेमा कुरा गर्दैछौं। र यदि तपाइँ केवल एक स्विचको सेटिङहरू परिवर्तन गर्न आवश्यक छ भने, परिवर्तनहरू सम्पूर्ण नेटवर्कको लागि गणना गरिन्छ। स्पष्ट रूपमा, तिनीहरू धेरै नोडहरूको लागि शून्य हुन सक्छन्।

तर, पहिले नै माथि भनिएको छ, हामी केहि प्रकारका बर्बरहरू होइनौं जो सबै चीज सीधा उत्पादनमा रोल गर्न चाहन्छौं।
उत्पन्न कन्फिगरेसन पहिले पाइपलाइन CI/CD मार्फत जानुपर्छ।

सीआई/सीडी भनेको निरन्तर एकीकरण, निरन्तर तैनाती हो। यो एउटा दृष्टिकोण हो जसमा टोलीले पुरानोलाई पूर्ण रूपमा प्रतिस्थापन गर्दै प्रत्येक छ महिनामा एउटा नयाँ प्रमुख रिलीज मात्र गर्दैन, तर नियमित रूपमा स-साना भागहरूमा (डिप्लोइमेन्ट) नयाँ कार्यक्षमता परिचय गराउँछ, जसमध्ये प्रत्येकलाई अनुकूलता, सुरक्षा र विस्तृत रूपमा परीक्षण गरिन्छ। प्रदर्शन (एकीकरण)।

यो गर्नको लागि, हामीसँग कन्फिगरेसन परिवर्तनहरू निगरानी गर्ने संस्करण नियन्त्रण प्रणाली छ, एक प्रयोगशाला जसले ग्राहक सेवा बिग्रिएको छ कि छैन भनेर जाँच गर्दछ, एक निगरानी प्रणाली जसले यो तथ्य जाँच गर्दछ, र अन्तिम चरण उत्पादन नेटवर्कमा परिवर्तनहरू रोल आउट गर्दैछ।

डिबगिङ आदेशहरूको अपवादको साथ, नेटवर्कमा सबै परिवर्तनहरू CI/CD पाइपलाइन मार्फत जानुपर्छ - यो हाम्रो शान्त जीवन र लामो, सुखी क्यारियरको ग्यारेन्टी हो।

कम्पोनेन्ट 9. ब्याकअप र विसंगति पत्ता लगाउने प्रणाली

ठिक छ, ब्याकअपहरूको बारेमा फेरि कुरा गर्न आवश्यक छैन।
हामी तिनीहरूलाई केवल मुकुट अनुसार वा कन्फिगरेसन परिवर्तनको तथ्यमा git मा राख्नेछौं।

तर दोस्रो भाग थप रोचक छ - कसैले यी ब्याकअपहरूमा नजर राख्नु पर्छ। र कतिपय अवस्थामा, यो कसैले गएर सबै कुरालाई जस्तो थियो जस्तै घुमाउनुपर्छ, र अरूमा, कसैलाई केही गलत छ भनेर म्याऊ।
उदाहरण को लागी, यदि एक नयाँ प्रयोगकर्ता देखा पर्यो जो चर मा दर्ता छैन, तपाईले उसलाई ह्याकबाट टाढा हटाउन आवश्यक छ। र यदि नयाँ फायरवाल नियमलाई नछुनु राम्रो हो भने, हुनसक्छ कसैले भर्खरै डिबगिङ खोल्यो, वा हुनसक्छ नयाँ सेवा, एक बंगलर, नियमहरू अनुसार दर्ता गरिएको थिएन, तर मानिसहरू पहिले नै यसमा सामेल भइसकेका छन्।

हामी अझै पनि सम्पूर्ण नेटवर्कको स्केलमा केही सानो डेल्टाबाट उम्कने छैनौं, कुनै पनि स्वचालन प्रणाली र व्यवस्थापनको कडा हातको बावजुद। समस्याहरू डिबग गर्न, कसैले पनि प्रणालीहरूमा कन्फिगरेसन थप्ने छैन। यसबाहेक, तिनीहरू पनि कन्फिगरेसन मोडेलमा समावेश नहुन सक्छ।

उदाहरणका लागि, समस्या स्थानीयकरण गर्न प्रति विशिष्ट आईपी प्याकेटहरूको संख्या गणना गर्न फायरवाल नियम पूर्ण रूपमा सामान्य अस्थायी कन्फिगरेसन हो।

कम्पोनेन्ट १०. निगरानी प्रणाली

सुरुमा म अनुगमनको विषयलाई कभर गर्न गइरहेको थिएन - यो अझै पनि एक विशाल, विवादास्पद र जटिल विषय हो। तर चीजहरू अगाडि बढ्दै जाँदा, यो स्वचालनको अभिन्न अंग हो भनेर बाहिरियो। र यसलाई बाइपास गर्न असम्भव छ, अभ्यास बिना पनि।

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

हामी छुट्टै लेखमा यसलाई विचार गर्नेछौं।

निष्कर्षमा

आधारको रूपमा, मैले आधुनिक डाटा सेन्टर नेटवर्क डिजाइनहरू मध्ये एउटा रोजेको छु - L3 Clos Fabric BGP सँग रूटिङ प्रोटोकलको रूपमा।
यस पटक हामी जुनिपरमा सञ्जाल निर्माण गर्नेछौं, किनकि अब जुनोस इन्टरफेस भ्यानलोभ हो।

खुला स्रोत उपकरणहरू र बहु-विक्रेता नेटवर्क प्रयोग गरेर हाम्रो जीवनलाई अझ कठिन बनाउनुहोस् - त्यसैले जुनिपरको अतिरिक्त, म बाटोमा थप एक भाग्यशाली व्यक्ति छान्नेछु।

आगामी प्रकाशनहरूको योजना यस प्रकार छ:
पहिले म भर्चुअल नेटवर्कको बारेमा कुरा गर्नेछु। सबैभन्दा पहिले, किनभने म चाहन्छु, र दोस्रो, किनभने यो बिना, पूर्वाधार नेटवर्कको डिजाइन धेरै स्पष्ट हुनेछैन।
त्यसपछि नेटवर्क डिजाइनको बारेमा: टोपोलोजी, मार्ग, नीतिहरू।
प्रयोगशाला स्ट्यान्ड जम्मा गरौं।
यसको बारेमा सोचौं र सम्भवतः नेटवर्कमा यन्त्र सुरु गर्ने अभ्यास गरौं।
र त्यसपछि अंतरंग विवरणमा प्रत्येक घटकको बारेमा।

र हो, म तयार समाधानको साथ यस चक्रलाई राम्रोसँग अन्त्य गर्ने वाचा गर्दिन। 🙂

उपयोगी लिङ्कहरू

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

धन्यवाद

रोमन गर्ज। टिप्पणी र सम्पादन को लागी।
Artyom Chernobay। KDPV को लागी।

स्रोत: www.habr.com