SDSM સમાપ્ત થઈ ગયું છે, પરંતુ લખવાની અનિયંત્રિત ઇચ્છા બાકી છે.

ઘણા વર્ષોથી, અમારા ભાઈને નિયમિત કામ કરવામાં, કમિટિંગ કરતા પહેલા આંગળીઓ વટાવવી અને રાતના રોલબેકને કારણે ઊંઘનો અભાવ હતો.
પરંતુ અંધકારમય સમયનો અંત આવી રહ્યો છે.

આ લેખ સાથે હું કેવી રીતે તેની શ્રેણી શરૂ કરીશ મને ઓટોમેશન જોવા મળે છે.
રસ્તામાં, અમે ઓટોમેશન, વેરિયેબલ્સ સ્ટોર કરવા, ફોર્મલાઇઝિંગ ડિઝાઇન, RestAPI, NETCONF, YANG, YDK ના તબક્કાઓ સમજીશું અને અમે ઘણું બધું પ્રોગ્રામિંગ કરીશું.
મને મતલબ કે એ) તે ઉદ્દેશ્યપૂર્ણ સત્ય નથી, b) તે બિનશરતી શ્રેષ્ઠ અભિગમ નથી, c) મારો અભિપ્રાય, પ્રથમથી છેલ્લા લેખ સુધીની ચળવળ દરમિયાન પણ, બદલાઈ શકે છે - પ્રમાણિકપણે, ડ્રાફ્ટ સ્ટેજથી પ્રકાશન, મેં બધું સંપૂર્ણપણે બે વાર ફરીથી લખ્યું.

અનુક્રમણિકા

1. ઉદ્દેશો
   1. નેટવર્ક એક સજીવ જેવું છે
   2. રૂપરેખાંકન પરીક્ષણ
   3. વર્ઝનીંગ
   4. સેવાઓનું નિરીક્ષણ અને સ્વ-હીલિંગ

2. સુવિધાઓ
   1. ઇન્વેન્ટરી સિસ્ટમ
   2. આઈપી સ્પેસ મેનેજમેન્ટ સિસ્ટમ
   3. નેટવર્ક સેવા વર્ણન સિસ્ટમ
   4. ઉપકરણ પ્રારંભ પદ્ધતિ
   5. વિક્રેતા-અજ્ઞેયવાદી રૂપરેખાંકન મોડેલ
   6. વિક્રેતા-વિશિષ્ટ ડ્રાઈવર ઈન્ટરફેસ
   7. ઉપકરણ પર રૂપરેખાંકન પહોંચાડવા માટેની પદ્ધતિ
   8. સીઆઈ / સીડી
   9. બેકઅપ અને વિચલનો માટે શોધ માટેની પદ્ધતિ
   10. મોનીટરીંગ સિસ્ટમ

3. નિષ્કર્ષ

હું SDSM થી સહેજ અલગ ફોર્મેટમાં ADSM ચલાવવાનો પ્રયત્ન કરીશ. મોટા, વિગતવાર, ક્રમાંકિત લેખો આવતા રહેશે, અને તેમની વચ્ચે હું રોજબરોજના અનુભવમાંથી નાની નોંધો પ્રકાશિત કરીશ. હું અહીં સંપૂર્ણતાવાદ સામે લડવાનો પ્રયાસ કરીશ અને તેમાંથી દરેકને ચાટતો નહીં.

કેટલી રમુજી વાત છે કે બીજી વાર તમારે એ જ રસ્તેથી પસાર થવું પડે.

શરૂઆતમાં મને નેટવર્ક્સ વિશે લેખો લખવા પડ્યા કારણ કે તેઓ રુનેટ પર ન હતા.

હવે હું એક વ્યાપક દસ્તાવેજ શોધી શક્યો નથી જે ઓટોમેશન તરફના અભિગમોને વ્યવસ્થિત કરે અને સરળ વ્યવહારુ ઉદાહરણોનો ઉપયોગ કરીને ઉપરોક્ત તકનીકોનું વિશ્લેષણ કરે.

હું ખોટો હોઈ શકું છું, તેથી કૃપા કરીને ઉપયોગી સંસાધનોની લિંક્સ પ્રદાન કરો. જો કે, આ મારા લખવાના નિર્ણયને બદલશે નહીં, કારણ કે મુખ્ય ધ્યેય મારી જાતને કંઈક શીખવાનું છે, અને અન્ય લોકો માટે જીવન સરળ બનાવવું એ એક સુખદ બોનસ છે જે અનુભવ શેર કરવા માટે જનીનને પ્રેમ કરે છે.

અમે એક મધ્યમ કદનું LAN DC ડેટા સેન્ટર લેવાનો પ્રયત્ન કરીશું અને સમગ્ર ઓટોમેશન સ્કીમ પર કામ કરીશું.
હું તમારી સાથે લગભગ પ્રથમ વખત કેટલીક વસ્તુઓ કરીશ.

હું અહીં વર્ણવેલ વિચારો અને સાધનોમાં મૂળ હોઈશ નહીં. દિમિત્રી ફિગોલ પાસે ઉત્તમ છે આ વિષય પર સ્ટ્રીમ્સ સાથેની ચેનલ.
લેખો તેમની સાથે ઘણા પાસાઓમાં ઓવરલેપ થશે.

LAN DCમાં 4 DC, લગભગ 250 સ્વીચો, અડધો ડઝન રાઉટર્સ અને કેટલાક ફાયરવોલ છે.
ફેસબુક નહીં, પરંતુ તમને ઓટોમેશન વિશે ઊંડાણપૂર્વક વિચારવા માટે પૂરતું છે.
જો કે, એક અભિપ્રાય છે કે જો તમારી પાસે 1 થી વધુ ઉપકરણ છે, તો ઓટોમેશન પહેલાથી જ જરૂરી છે.
વાસ્તવમાં, કલ્પના કરવી મુશ્કેલ છે કે હવે કોઈ પણ વ્યક્તિ ઘૂંટણની સ્ક્રિપ્ટના ઓછામાં ઓછા પેક વિના જીવી શકે છે.
જો કે મેં સાંભળ્યું છે કે એવી ઓફિસો છે જ્યાં એક્સેલમાં IP એડ્રેસ રાખવામાં આવે છે, અને હજારો નેટવર્ક ઉપકરણોમાંથી દરેક મેન્યુઅલી રૂપરેખાંકિત થયેલ છે અને તેનું પોતાનું અનન્ય રૂપરેખાંકન છે. આ, અલબત્ત, આધુનિક કલા તરીકે પસાર કરી શકાય છે, પરંતુ એન્જિનિયરની લાગણી ચોક્કસપણે નારાજ થશે.

ઉદ્દેશો

હવે અમે સૌથી અમૂર્ત લક્ષ્યો સેટ કરીશું:

• નેટવર્ક એક સજીવ જેવું છે
• રૂપરેખાંકન પરીક્ષણ
• નેટવર્ક સ્ટેટ વર્ઝનિંગ
• સેવાઓનું નિરીક્ષણ અને સ્વ-હીલિંગ

પાછળથી આ લેખમાં આપણે જોઈશું કે આપણે કયા અર્થનો ઉપયોગ કરીશું, અને નીચેનામાં, આપણે ધ્યેયો અને માધ્યમોને વિગતવાર જોઈશું.

નેટવર્ક એક સજીવ જેવું છે

શ્રેણીનું વ્યાખ્યાયિત વાક્ય, જોકે પ્રથમ નજરમાં તે એટલું નોંધપાત્ર લાગતું નથી: અમે નેટવર્કને ગોઠવીશું, વ્યક્તિગત ઉપકરણોને નહીં.
તાજેતરના વર્ષોમાં, અમે નેટવર્કને એક જ એન્ટિટી તરીકે ગણવા તરફના ભારમાં પરિવર્તન જોયું છે, તેથી સોફ્ટવેર વ્યાખ્યાયિત નેટવર્કિંગ, ઉદ્દેશ આધારિત નેટવર્ક્સ и સ્વાયત્ત નેટવર્ક્સ.
છેવટે, નેટવર્કમાંથી વૈશ્વિક સ્તરે એપ્લિકેશનને શું જોઈએ છે: પોઈન્ટ A અને B (સારી રીતે, ક્યારેક +B-Z) વચ્ચેની કનેક્ટિવિટી અને અન્ય એપ્લિકેશનો અને વપરાશકર્તાઓથી અલગતા.

અને તેથી આ શ્રેણીમાં અમારું કાર્ય છે સિસ્ટમ બનાવો, વર્તમાન રૂપરેખાંકન જાળવવા સમગ્ર નેટવર્ક, જે પહેલાથી જ દરેક ઉપકરણ પર તેની ભૂમિકા અને સ્થાન અનુસાર વાસ્તવિક રૂપરેખાંકનમાં વિઘટિત થયેલ છે.
સિસ્ટમ નેટવર્ક મેનેજમેન્ટ સૂચવે છે કે ફેરફારો કરવા માટે અમે તેનો સંપર્ક કરીએ છીએ, અને તે બદલામાં, દરેક ઉપકરણ માટે ઇચ્છિત સ્થિતિની ગણતરી કરે છે અને તેને ગોઠવે છે.
આ રીતે, અમે CLI ની મેન્યુઅલ એક્સેસને લગભગ શૂન્ય સુધી ઘટાડી દઈએ છીએ - ઉપકરણ સેટિંગ્સ અથવા નેટવર્ક ડિઝાઇનમાં કોઈપણ ફેરફારો ઔપચારિક અને દસ્તાવેજીકૃત હોવા જોઈએ - અને તે પછી જ જરૂરી નેટવર્ક ઘટકોમાં રોલઆઉટ કરવામાં આવે છે.

એટલે કે, ઉદાહરણ તરીકે, જો આપણે નક્કી કર્યું કે હવેથી કાઝાનમાં રેક સ્વીચોએ એકને બદલે બે નેટવર્કની જાહેરાત કરવી જોઈએ, તો અમે

1. પહેલા આપણે સિસ્ટમમાં થતા ફેરફારોને દસ્તાવેજીકૃત કરીએ છીએ
2. બધા નેટવર્ક ઉપકરણોનું લક્ષ્ય રૂપરેખાંકન જનરેટ કરી રહ્યું છે
3. અમે નેટવર્ક રૂપરેખાંકન અપડેટ પ્રોગ્રામ શરૂ કરીએ છીએ, જે દરેક નોડ પર શું દૂર કરવાની જરૂર છે, શું ઉમેરવું છે તેની ગણતરી કરે છે અને નોડ્સને ઇચ્છિત સ્થિતિમાં લાવે છે.

તે જ સમયે, અમે ફક્ત પ્રથમ પગલામાં મેન્યુઅલી ફેરફારો કરીએ છીએ.

રૂપરેખાંકન પરીક્ષણ

તે જાણીતું છેકે રૂપરેખાંકન ફેરફારો દરમિયાન 80% સમસ્યાઓ થાય છે - આનો પરોક્ષ પુરાવો એ છે કે નવા વર્ષની રજાઓ દરમિયાન બધું સામાન્ય રીતે શાંત હોય છે.
માનવીય ભૂલને કારણે મેં વ્યક્તિગત રીતે ડઝનેક વૈશ્વિક ડાઉનટાઇમ્સ જોયા છે: ખોટો આદેશ, રૂપરેખાંકન ખોટી શાખામાં ચલાવવામાં આવ્યું હતું, સમુદાય ભૂલી ગયો હતો, MPLS ને રાઉટર પર વૈશ્વિક સ્તરે તોડી પાડવામાં આવ્યું હતું, હાર્ડવેરના પાંચ ટુકડાઓ ગોઠવવામાં આવ્યા હતા, પરંતુ ભૂલ ન હતી. છઠ્ઠા પર નોંધ્યું, અન્ય વ્યક્તિ દ્વારા કરવામાં આવેલા જૂના ફેરફારો પ્રતિબદ્ધ હતા. ત્યાં એક ટન દૃશ્યો છે.

ઓટોમેશન અમને ઓછી ભૂલો કરવાની મંજૂરી આપશે, પરંતુ મોટા પાયે. આ રીતે તમે માત્ર એક જ ઉપકરણને નહીં, પરંતુ સમગ્ર નેટવર્કને એકસાથે ઈંટ બનાવી શકો છો.

અનાદિ કાળથી, અમારા દાદાઓએ આતુર નજરથી, સ્ટીલના દડાઓ અને નેટવર્કની કાર્યક્ષમતાને રોલઆઉટ કર્યા પછી કરવામાં આવેલા ફેરફારોની સાચીતા તપાસી.
તે દાદા જેમના કામને કારણે ડાઉનટાઇમ અને આપત્તિજનક નુકસાન થયું હતું તેઓ ઓછા સંતાનો છોડે છે અને સમય જતાં મૃત્યુ પામવું જોઈએ, પરંતુ ઉત્ક્રાંતિ એ ધીમી પ્રક્રિયા છે, અને તેથી દરેક જણ હજી પણ પ્રયોગશાળામાં ફેરફારોનું પરીક્ષણ કરતા નથી.
જો કે, પ્રગતિમાં મોખરે એવા લોકો છે જેમણે રૂપરેખાંકન અને નેટવર્ક પર તેની વધુ એપ્લિકેશનની ચકાસણી કરવાની પ્રક્રિયાને સ્વચાલિત કરી છે. બીજા શબ્દોમાં કહીએ તો, મેં CI/CD પ્રક્રિયા ઉછીના લીધી (સતત એકીકરણ, સતત જમાવટ) વિકાસકર્તાઓ તરફથી.
એક ભાગમાં આપણે વર્ઝન કંટ્રોલ સિસ્ટમ, કદાચ ગીથબનો ઉપયોગ કરીને આને કેવી રીતે અમલમાં મૂકવું તે જોઈશું.

એકવાર તમે નેટવર્ક CI/CD ના વિચારની આદત પામી લો, પછી પ્રોડક્શન નેટવર્ક પર તેને લાગુ કરીને રૂપરેખાંકન તપાસવાની પદ્ધતિ રાતોરાત મધ્યયુગીન અજ્ઞાન જેવી લાગશે. હથોડી વડે હથિયાર મારવા જેવું.

વિશે વિચારોનું કાર્બનિક સાતત્ય સિસ્ટમ નેટવર્ક મેનેજમેન્ટ અને CI/CD રૂપરેખાંકનનું સંપૂર્ણ સંસ્કરણ બની જાય છે.

વર્ઝનીંગ

અમે માની લઈશું કે કોઈપણ ફેરફારો સાથે, સૌથી નાનામાં પણ, એક અજાણ્યા ઉપકરણ પર પણ, સમગ્ર નેટવર્ક એક રાજ્યથી બીજા રાજ્યમાં જાય છે.
અને અમે હંમેશા ઉપકરણ પર આદેશ ચલાવતા નથી, અમે નેટવર્કની સ્થિતિ બદલીએ છીએ.
તો ચાલો આ સ્ટેટ્સ વર્ઝન કહીએ?

ચાલો કહીએ કે વર્તમાન સંસ્કરણ 1.0.0 છે.
શું એક ToRs પરના લૂપબેક ઈન્ટરફેસનું IP સરનામું બદલાયું છે? આ એક નાનું સંસ્કરણ છે અને તેને 1.0.1 નંબર આપવામાં આવશે.
અમે BGP માં રૂટ આયાત કરવા માટેની નીતિઓ સુધારી છે - થોડી વધુ ગંભીરતા - પહેલેથી જ 1.1.0
અમે આઈજીપીથી છૂટકારો મેળવવાનું અને માત્ર BGP પર સ્વિચ કરવાનું નક્કી કર્યું - આ પહેલેથી જ એક આમૂલ ડિઝાઇન ફેરફાર છે - 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-Keys, 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 પર.
અથવા તમારે પ્રદેશની તમામ સરહદો પર નવું સિસ્લોગ સર્વર રોલ આઉટ કરવાની જરૂર છે.

તેમાં આપણે વર્ચ્યુઅલ નેટવર્ક ઉપકરણોને સંગ્રહિત કરીશું, ઉદાહરણ તરીકે વર્ચ્યુઅલ રાઉટર્સ અથવા રૂટ રિફ્લેક્ટર. અમે DNS સર્વર્સ, NTP, Syslog અને સામાન્ય રીતે બધું જ ઉમેરી શકીએ છીએ જે એક યા બીજી રીતે નેટવર્ક સાથે સંબંધિત છે.

ઘટક 2: IP સ્પેસ મેનેજમેન્ટ સિસ્ટમ

હા, અને આજકાલ એવા લોકોની ટીમો છે જેઓ એક્સેલ ફાઇલમાં ઉપસર્ગ અને IP એડ્રેસનો ટ્રૅક રાખે છે. પરંતુ આધુનિક અભિગમ હજુ પણ ડેટાબેઝ છે, જેમાં nginx/apache, API પર ફ્રન્ટ-એન્ડ છે અને IP એડ્રેસ અને VRF માં વિભાજિત નેટવર્ક્સને રેકોર્ડ કરવા માટેના વ્યાપક કાર્યો છે.
IPAM - IP એડ્રેસ મેનેજમેન્ટ.

અમારા હેતુઓ માટે, અમે તેમાં નીચેની માહિતી સંગ્રહિત કરીશું:

• વી.એલ.એન.એન.
• વીઆરએફ
• નેટવર્ક્સ/સબનેટ્સ
• IP સરનામાં
• ઉપકરણો માટે સરનામાંઓ, સ્થાનો પર નેટવર્ક અને VLAN નંબરોને બંધનકર્તા

ફરીથી, તે સ્પષ્ટ છે કે અમે ખાતરી કરવા માંગીએ છીએ કે જ્યારે અમે ToR લૂપબેક માટે નવું IP સરનામું ફાળવીએ છીએ, ત્યારે અમે એ હકીકતથી ઠોકર ખાઈશું નહીં કે તે પહેલાથી જ કોઈને સોંપવામાં આવ્યું હતું. અથવા અમે નેટવર્કના જુદા જુદા છેડે બે વાર સમાન ઉપસર્ગનો ઉપયોગ કર્યો છે.
પરંતુ આ ઓટોમેશનમાં કેવી રીતે મદદ કરે છે?
સરળ.
અમે લૂપબેક્સ રોલ સાથે સિસ્ટમમાં એક ઉપસર્ગની વિનંતી કરીએ છીએ, જેમાં ફાળવણી માટે ઉપલબ્ધ 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 સુધી મર્યાદિત કરો, વગેરે.
બદલામાં, કરોડરજ્જુ તમામ કનેક્ટેડ લીડ્સ સાથે સત્રો ધરાવે છે, રુટ રિફ્લેક્ટર તરીકે કામ કરે છે, અને તેમાંથી માત્ર ચોક્કસ લંબાઈના અને ચોક્કસ સમુદાય સાથેના રૂટ સ્વીકારે છે.

ઘટક 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
• REST API
• ઓપનફ્લો (જોકે તે આઉટલીયર છે કારણ કે તે FIB પહોંચાડવાનો માર્ગ છે, સેટિંગ્સ નહીં)

ચાલો ટી અહીં ડોટ કરીએ. CLI વારસો છે. SNMP... ખાંસી ઉધરસ.
RESTCONF હજુ પણ અજ્ઞાત પ્રાણી છે; REST API લગભગ કોઈ દ્વારા સમર્થિત નથી. તેથી, અમે શ્રેણીમાં NETCONF પર ધ્યાન કેન્દ્રિત કરીશું.

વાસ્તવમાં, જેમ કે વાચક પહેલાથી જ સમજી ગયા છે, આ બિંદુએ આપણે પહેલેથી જ ઇન્ટરફેસ પર નિર્ણય લીધો છે - અગાઉના પગલાનું પરિણામ પહેલેથી જ પસંદ કરેલ ઇન્ટરફેસના ફોર્મેટમાં રજૂ કરવામાં આવ્યું છે.

બીજું, અને અમે આ કયા સાધનો સાથે કરીશું?
અહીં એક મોટી પસંદગી પણ છે:

• સ્વ-લિખિત સ્ક્રિપ્ટ અથવા પ્લેટફોર્મ. ચાલો આપણી જાતને ncclient અને asyncIO સાથે સજ્જ કરીએ અને બધું જાતે કરીએ. શરૂઆતથી જમાવટ સિસ્ટમ બનાવવા માટે અમને શું ખર્ચ થાય છે?
• નેટવર્કિંગ મોડ્યુલોની તેની સમૃદ્ધ લાઇબ્રેરી સાથે જવાબ આપવા યોગ્ય.
• નેટવર્ક સાથેના તેના અલ્પ કામ અને નેપલમ સાથેના જોડાણ સાથે મીઠું.
• ખરેખર નેપલમ, જે કેટલાક વિક્રેતાઓને જાણે છે અને બસ, ગુડબાય.
• નોર્નિર એ બીજું પ્રાણી છે જેનું આપણે ભવિષ્યમાં વિચ્છેદન કરીશું.

અહીં મનપસંદ હજી પસંદ કરવામાં આવ્યો નથી - અમે શોધીશું.

અહીં બીજું શું મહત્વનું છે? રૂપરેખાંકન લાગુ કરવાના પરિણામો.
સફળ કે નહીં. શું હજી પણ હાર્ડવેરની ઍક્સેસ છે કે નહીં?
એવું લાગે છે કે કમિટ અહીં ઉપકરણ પર શું ડાઉનલોડ કરવામાં આવ્યું હતું તેની પુષ્ટિ અને માન્યતામાં મદદ કરશે.
આ, NETCONF ના યોગ્ય અમલીકરણ સાથે, યોગ્ય ઉપકરણોની શ્રેણીને નોંધપાત્ર રીતે સંકુચિત કરે છે - ઘણા ઉત્પાદકો સામાન્ય કમિટ્સને સમર્થન આપતા નથી. પરંતુ આ માત્ર એક પૂર્વજરૂરીયાતો છે આરએફપી. અંતે, કોઈને ચિંતા નથી કે એક પણ રશિયન વિક્રેતા 32*100GE ઈન્ટરફેસ શરતનું પાલન કરશે નહીં. અથવા તે ચિંતિત છે?

ઘટક 8. CI/CD

આ બિંદુએ, અમારી પાસે પહેલાથી જ બધા નેટવર્ક ઉપકરણો માટે રૂપરેખાંકન તૈયાર છે.
હું "બધું માટે" લખું છું કારણ કે અમે નેટવર્ક સ્ટેટના સંસ્કરણ વિશે વાત કરી રહ્યા છીએ. અને જો તમારે માત્ર એક સ્વીચની સેટિંગ્સ બદલવાની જરૂર હોય, તો પણ સમગ્ર નેટવર્ક માટે ફેરફારોની ગણતરી કરવામાં આવે છે. દેખીતી રીતે, તેઓ મોટાભાગના ગાંઠો માટે શૂન્ય હોઈ શકે છે.

પરંતુ, જેમ પહેલાથી જ ઉપર કહ્યું હતું તેમ, અમે અમુક પ્રકારના અસંસ્કારી નથી જેઓ દરેક વસ્તુને સીધા ઉત્પાદનમાં રોલ કરવા માંગે છે.
જનરેટ કરેલ રૂપરેખાંકન સૌપ્રથમ પાઇપલાઇન CI/CDમાંથી પસાર થવું જોઈએ.

CI/CD નો અર્થ છે સતત એકીકરણ, સતત જમાવટ. આ એક એવો અભિગમ છે કે જેમાં ટીમ દર છ મહિને માત્ર એક નવું મુખ્ય પ્રકાશન બહાર પાડે છે, જૂનાને સંપૂર્ણપણે બદલીને, પરંતુ નિયમિતપણે નાના ભાગોમાં નવી કાર્યક્ષમતા (ડિપ્લોયમેન્ટ) લાગુ કરે છે, જેમાંથી પ્રત્યેક સુસંગતતા, સુરક્ષા માટે વ્યાપકપણે પરીક્ષણ કરવામાં આવે છે. કામગીરી (એકીકરણ).

આ કરવા માટે, અમારી પાસે વર્ઝન કંટ્રોલ સિસ્ટમ છે જે રૂપરેખાંકન ફેરફારોનું નિરીક્ષણ કરે છે, એક પ્રયોગશાળા જે તપાસે છે કે ક્લાયંટ સેવા તૂટી ગઈ છે કે કેમ, એક મોનિટરિંગ સિસ્ટમ છે જે આ હકીકતને તપાસે છે, અને છેલ્લું પગલું ઉત્પાદન નેટવર્કમાં ફેરફારોને રોલ આઉટ કરવાનું છે.

ડિબગીંગ આદેશોના અપવાદ સાથે, નેટવર્ક પરના તમામ ફેરફારો CI/CD પાઇપલાઇનમાંથી પસાર થવા જોઈએ - આ એક શાંત જીવન અને લાંબી, સુખી કારકિર્દીની અમારી ગેરંટી છે.

ઘટક 9. બેકઅપ અને વિસંગતતા શોધ સિસ્ટમ

ઠીક છે, બેકઅપ વિશે ફરીથી વાત કરવાની જરૂર નથી.
અમે તેમને ફક્ત તાજ અનુસાર અથવા રૂપરેખાંકન ફેરફારની હકીકત પર ગિટમાં મૂકીશું.

પરંતુ બીજો ભાગ વધુ રસપ્રદ છે - કોઈએ આ બેકઅપ્સ પર નજર રાખવી જોઈએ. અને કેટલાક કિસ્સાઓમાં, આ કોઈએ જવું જોઈએ અને બધું જેમ હતું તેમ ફેરવવું જોઈએ, અને અન્યમાં, કોઈને કંઈક ખોટું થયું છે.
ઉદાહરણ તરીકે, જો કોઈ નવો વપરાશકર્તા દેખાયો જે ચલોમાં નોંધાયેલ નથી, તો તમારે તેને હેકથી દૂર કરવાની જરૂર છે. અને જો નવા ફાયરવોલ નિયમને સ્પર્શ ન કરવો તે વધુ સારું છે, તો કદાચ કોઈએ હમણાં જ ડીબગીંગ ચાલુ કર્યું છે, અથવા કદાચ નવી સેવા, એક બંગલર, નિયમો અનુસાર નોંધાયેલ નથી, પરંતુ લોકો પહેલેથી જ તેમાં જોડાયા છે.

કોઈપણ ઓટોમેશન સિસ્ટમ્સ અને મેનેજમેન્ટના ચુસ્ત હાથ હોવા છતાં, અમે સમગ્ર નેટવર્કના સ્કેલ પર કેટલાક નાના ડેલ્ટાને છટકીશું નહીં. સમસ્યાઓને ડીબગ કરવા માટે, કોઈપણ રીતે સિસ્ટમમાં રૂપરેખાંકન ઉમેરશે નહીં. તદુપરાંત, તેઓ રૂપરેખાંકન મોડેલમાં પણ શામેલ ન હોઈ શકે.

ઉદાહરણ તરીકે, સમસ્યાનું સ્થાનિકીકરણ કરવા માટે ચોક્કસ IP દીઠ પેકેટોની સંખ્યા ગણવા માટેનો ફાયરવોલ નિયમ સંપૂર્ણપણે સામાન્ય કામચલાઉ રૂપરેખાંકન છે.

ઘટક 10. મોનીટરીંગ સિસ્ટમ

શરૂઆતમાં હું મોનિટરિંગના વિષયને આવરી લેવાનો ન હતો - તે હજી પણ એક વિશાળ, વિવાદાસ્પદ અને જટિલ વિષય છે. પરંતુ જેમ જેમ વસ્તુઓ આગળ વધી, તે બહાર આવ્યું કે આ ઓટોમેશનનો અભિન્ન ભાગ છે. અને પ્રેક્ટિસ વિના પણ, તેને બાયપાસ કરવું અશક્ય છે.

વિકાસશીલ વિચાર એ CI/CD પ્રક્રિયાનો એક કાર્બનિક ભાગ છે. નેટવર્ક પર રૂપરેખાંકન રોલ આઉટ કર્યા પછી, આપણે હવે તેની સાથે બધું ઠીક છે કે કેમ તે નિર્ધારિત કરવા સક્ષમ બનવાની જરૂર છે.
અને અમે માત્ર ઈન્ટરફેસ વપરાશના સમયપત્રક અથવા નોડની ઉપલબ્ધતા વિશે જ નહીં, પરંતુ વધુ સૂક્ષ્મ બાબતો વિશે વાત કરી રહ્યા છીએ - જરૂરી રૂટ્સની હાજરી, તેના પરના લક્ષણો, BGP સત્રોની સંખ્યા, OSPF પડોશીઓ, એન્ડ-ટુ-એન્ડ કામગીરી. અતિશય સેવાઓ.
શું બાહ્ય સર્વર પરના syslogs ઉમેરવાનું બંધ થઈ ગયું છે, અથવા SFlow એજન્ટ તૂટી ગયું છે, અથવા કતારોમાં ટીપાં વધવા લાગ્યા છે, અથવા શું ઉપસર્ગની કેટલીક જોડી વચ્ચેની કનેક્ટિવિટી તૂટી ગઈ છે?

અમે એક અલગ લેખમાં આ વિશે વિચારણા કરીશું.

નિષ્કર્ષ

એક આધાર તરીકે, મેં એક આધુનિક ડેટા સેન્ટર નેટવર્ક ડિઝાઇન પસંદ કરી - BGP સાથે L3 Clos Fabric રૂટીંગ પ્રોટોકોલ તરીકે.
આ વખતે અમે જ્યુનિપર પર નેટવર્ક બનાવીશું, કારણ કે હવે જૂનો ઇન્ટરફેસ એક વેનલોવ છે.

ચાલો ફક્ત ઓપન સોર્સ ટૂલ્સ અને મલ્ટિ-વેન્ડર નેટવર્કનો ઉપયોગ કરીને આપણું જીવન વધુ મુશ્કેલ બનાવીએ - તેથી જ્યુનિપર ઉપરાંત, હું રસ્તામાં વધુ એક નસીબદાર વ્યક્તિને પસંદ કરીશ.

આગામી પ્રકાશનો માટેની યોજના કંઈક આના જેવી છે:
પહેલા હું વર્ચ્યુઅલ નેટવર્ક વિશે વાત કરીશ. સૌ પ્રથમ, કારણ કે હું ઇચ્છું છું, અને બીજું, કારણ કે આ વિના, ઇન્ફ્રાસ્ટ્રક્ચર નેટવર્કની ડિઝાઇન ખૂબ સ્પષ્ટ રહેશે નહીં.
પછી નેટવર્ક ડિઝાઇન વિશે જ: ટોપોલોજી, રૂટીંગ, નીતિઓ.
ચાલો લેબોરેટરી સ્ટેન્ડ એસેમ્બલ કરીએ.
ચાલો તેના વિશે વિચારીએ અને કદાચ નેટવર્ક પર ઉપકરણને પ્રારંભ કરવાની પ્રેક્ટિસ કરીએ.
અને પછી ઘનિષ્ઠ વિગતમાં દરેક ઘટક વિશે.

અને હા, હું તૈયાર સોલ્યુશન સાથે આ ચક્રને આકર્ષક રીતે સમાપ્ત કરવાનું વચન આપતો નથી. 🙂

ઉપયોગી લિંક્સ

• શ્રેણીમાં પ્રવેશતા પહેલા, નતાશા સમોઇલેન્કોનું પુસ્તક વાંચવું યોગ્ય છે નેટવર્ક એન્જિનિયરો માટે પાયથોન. અને કદાચ પાસ કોર્સ.
• તે વાંચવામાં પણ ઉપયોગી થશે આરએફસી પીટર લાપુખોવ દ્વારા ફેસબુકના ડેટા સેન્ટર ફેક્ટરીઓની ડિઝાઇન વિશે.
• આર્કિટેક્ચર દસ્તાવેજીકરણ તમને ઓવરલે SDN કેવી રીતે કાર્ય કરે છે તેનો ખ્યાલ આપશે. ટંગસ્ટન ફેબ્રિક (અગાઉ ઓપન કોન્ટ્રાઇલ).

આભાર

રોમન ગોર્જ. ટિપ્પણીઓ અને સંપાદનો માટે.
આર્ટીઓમ ચેર્નોબે. KDPV માટે.

સોર્સ: www.habr.com