ક્લાઉડ ઇન્ફ્રાસ્ટ્રક્ચરના નેટવર્ક ભાગનો પરિચય

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

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

વાદળ શું છે? સમાન વર્ચ્યુઅલાઈઝેશન - પ્રોફાઇલ દૃશ્ય?

તાર્કિક પ્રશ્ન કરતાં વધુ. ના - આ વર્ચ્યુઅલાઈઝેશન નથી, જો કે તે તેના વિના થઈ શકતું નથી. ચાલો બે વ્યાખ્યાઓ જોઈએ:

ક્લાઉડ કમ્પ્યુટિંગ (ત્યારબાદ ક્લાઉડ તરીકે ઓળખાય છે) વિતરિત કમ્પ્યુટિંગ સંસાધનોની વપરાશકર્તા-મૈત્રીપૂર્ણ ઍક્સેસ પ્રદાન કરવા માટેનું એક મોડેલ છે જે સેવા પ્રદાતાને સૌથી ઓછી શક્ય વિલંબતા અને ન્યૂનતમ ખર્ચ સાથે માંગ પર તૈનાત અને લોન્ચ કરવું આવશ્યક છે.

વર્ચ્યુઅલાઈઝેશન - આ એક ભૌતિક એન્ટિટી (ઉદાહરણ તરીકે, સર્વર) ને ઘણા વર્ચ્યુઅલમાં વિભાજિત કરવાની ક્ષમતા છે, જેનાથી સંસાધનોનો ઉપયોગ વધે છે (ઉદાહરણ તરીકે, તમારી પાસે 3-25 ટકા પર 30 સર્વર લોડ થયા હતા, વર્ચ્યુઅલાઈઝેશન પછી તમને 1 સર્વર લોડ થાય છે. 80-90 ટકા પર). સ્વાભાવિક રીતે, વર્ચ્યુઅલાઇઝેશન કેટલાક સંસાધનો ખાય છે - તમારે હાઇપરવાઇઝરને ખવડાવવાની જરૂર છે, જો કે, પ્રેક્ટિસ બતાવે છે તેમ, રમત મીણબત્તીની કિંમત છે. વર્ચ્યુઅલાઈઝેશનનું એક આદર્શ ઉદાહરણ VMWare છે, જે વર્ચ્યુઅલ મશીનને સંપૂર્ણ રીતે તૈયાર કરે છે, અથવા ઉદાહરણ તરીકે KVM, જે હું પસંદ કરું છું, પરંતુ આ સ્વાદની બાબત છે.

અમે તેને સમજ્યા વિના વર્ચ્યુઅલાઈઝેશનનો ઉપયોગ કરીએ છીએ, અને આયર્ન રાઉટર્સ પણ પહેલેથી વર્ચ્યુઅલાઈઝેશનનો ઉપયોગ કરે છે - ઉદાહરણ તરીકે, JunOS ના નવીનતમ સંસ્કરણમાં, ઑપરેટિંગ સિસ્ટમ રીઅલ-ટાઇમ Linux વિતરણ (વિન્ડ રિવર 9) ની ટોચ પર વર્ચ્યુઅલ મશીન તરીકે ઇન્સ્ટોલ કરેલી છે. પરંતુ વર્ચ્યુઅલાઈઝેશન એ ક્લાઉડ નથી, પરંતુ ક્લાઉડ વર્ચ્યુઅલાઈઝેશન વિના અસ્તિત્વમાં નથી.

વર્ચ્યુઅલાઈઝેશન એ બિલ્ડિંગ બ્લોક્સમાંનું એક છે જેના પર ક્લાઉડ બનાવવામાં આવે છે.

ફક્ત એક L2 ડોમેનમાં ઘણા હાઇપરવાઇઝર્સને એકત્ર કરીને ક્લાઉડ બનાવવું, અમુક પ્રકારના જવાબો દ્વારા આપમેળે vlans રજીસ્ટર કરવા માટે yaml પ્લેબુક ઉમેરવા અને વર્ચ્યુઅલ મશીનો આપમેળે બનાવવા માટે તેના પર ઓર્કેસ્ટ્રેશન સિસ્ટમ જેવું કંઈક જામ કરવું કામ કરશે નહીં. તે વધુ સચોટ હશે, પરંતુ પરિણામી ફ્રેન્કેસ્ટાઈન એ આપણને જોઈતું વાદળ નથી, જો કે તે અન્ય લોકો માટે અંતિમ સ્વપ્ન હોઈ શકે છે. તદુપરાંત, જો તમે સમાન ઓપનસ્ટૅક લો છો, તો તે આવશ્યકપણે હજી પણ ફ્રેન્કેસ્ટાઇન છે, પરંતુ ઓહ સારું, ચાલો તેના વિશે હમણાં વાત ન કરીએ.

પરંતુ હું સમજું છું કે ઉપર પ્રસ્તુત વ્યાખ્યા પરથી તે સંપૂર્ણપણે સ્પષ્ટ નથી કે વાસ્તવમાં વાદળ કોને કહી શકાય.

તેથી, NIST (નેશનલ ઇન્સ્ટિટ્યૂટ ઑફ સ્ટાન્ડર્ડ્સ એન્ડ ટેક્નોલોજી) નો દસ્તાવેજ 5 મુખ્ય લાક્ષણિકતાઓ પ્રદાન કરે છે જે ક્લાઉડ ઇન્ફ્રાસ્ટ્રક્ચરમાં હોવી જોઈએ:

વિનંતી પર સેવા પૂરી પાડે છે. વપરાશકર્તાને તેને ફાળવેલ કમ્પ્યુટર સંસાધનોની મફત ઍક્સેસ આપવી જોઈએ (જેમ કે નેટવર્ક્સ, વર્ચ્યુઅલ ડિસ્ક, મેમરી, પ્રોસેસર કોરો, વગેરે), અને આ સંસાધનો આપમેળે પ્રદાન કરવા જોઈએ - એટલે કે, સેવા પ્રદાતાના હસ્તક્ષેપ વિના.

સેવાની વ્યાપક ઉપલબ્ધતા. સંસાધનોની ઍક્સેસ પ્રમાણભૂત પીસી અને પાતળા ક્લાયંટ અને મોબાઇલ ઉપકરણો બંનેના ઉપયોગને મંજૂરી આપવા માટે પ્રમાણભૂત પદ્ધતિઓ દ્વારા પ્રદાન કરવી આવશ્યક છે.

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

વિવિધ પરિસ્થિતિઓમાં ઝડપી અનુકૂલન. સેવાઓ લવચીક હોવી જોઈએ - સંસાધનોની ઝડપી જોગવાઈ, તેમનું પુનઃવિતરણ, ક્લાયન્ટની વિનંતી પર સંસાધનો ઉમેરવા અથવા ઘટાડવું, અને ક્લાઉડ સંસાધનો અનંત છે તેવી લાગણી ક્લાયન્ટની તરફથી હોવી જોઈએ. સમજવાની સરળતા માટે, ઉદાહરણ તરીકે, તમને એવી ચેતવણી દેખાતી નથી કે Apple iCloud માં તમારી ડિસ્ક સ્પેસનો ભાગ અદૃશ્ય થઈ ગયો છે કારણ કે સર્વર પરની હાર્ડ ડ્રાઈવ તૂટી ગઈ છે અને ડ્રાઈવો તૂટી ગઈ છે. વધુમાં, તમારા તરફથી, આ સેવાની શક્યતાઓ લગભગ અમર્યાદિત છે - તમારે 2 TBની જરૂર છે - કોઈ વાંધો નથી, તમે ચૂકવણી કરી અને પ્રાપ્ત કરી. Google.Drive અથવા Yandex.Disk સાથે સમાન ઉદાહરણ આપી શકાય છે.

પૂરી પાડવામાં આવેલ સેવાને માપવાની શક્યતા. ક્લાઉડ સિસ્ટમ્સે વપરાશ કરેલ સંસાધનોને આપમેળે નિયંત્રિત અને ઑપ્ટિમાઇઝ કરવું આવશ્યક છે, અને આ પદ્ધતિઓ વપરાશકર્તા અને સેવા પ્રદાતા બંને માટે પારદર્શક હોવી જોઈએ. એટલે કે, તમે હંમેશા તપાસ કરી શકો છો કે તમે અને તમારા ગ્રાહકો કેટલા સંસાધનોનો ઉપયોગ કરી રહ્યાં છો.

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

આપણને વાદળની કેમ જરૂર છે?

જો કે, કોઈપણ નવી અથવા હાલની તકનીક, કોઈપણ નવો પ્રોટોકોલ કંઈક માટે બનાવવામાં આવે છે (સારી રીતે, RIP-ng સિવાય, અલબત્ત). પ્રોટોકોલ ખાતર કોઈને પ્રોટોકોલની જરૂર નથી (સારી રીતે, RIP-ng સિવાય, અલબત્ત). તે તાર્કિક છે કે ક્લાઉડ વપરાશકર્તા/ક્લાયન્ટને અમુક પ્રકારની સેવા પૂરી પાડવા માટે બનાવવામાં આવ્યું છે. અમે બધા ઓછામાં ઓછી કેટલીક ક્લાઉડ સેવાઓથી પરિચિત છીએ, ઉદાહરણ તરીકે ડ્રૉપબૉક્સ અથવા Google.Docs, અને હું માનું છું કે મોટાભાગના લોકો તેનો સફળતાપૂર્વક ઉપયોગ કરે છે - ઉદાહરણ તરીકે, આ લેખ Google.Docs ક્લાઉડ સેવાનો ઉપયોગ કરીને લખવામાં આવ્યો હતો. પરંતુ આપણે જે ક્લાઉડ સેવાઓ જાણીએ છીએ તે ક્લાઉડની ક્ષમતાઓનો માત્ર એક ભાગ છે — વધુ સ્પષ્ટ રીતે, તે માત્ર SaaS-પ્રકારની સેવા છે. અમે ત્રણ રીતે ક્લાઉડ સેવા પ્રદાન કરી શકીએ છીએ: SaaS, PaaS અથવા IaaS ના રૂપમાં. તમને કઈ સેવાની જરૂર છે તે તમારી ઇચ્છાઓ અને ક્ષમતાઓ પર આધારિત છે.

ચાલો દરેકને ક્રમમાં જોઈએ:

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

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

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

OpenStack શું છે?

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

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

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

આ સામગ્રી લખતી વખતે, OpenStack માળખું આના જેવું દેખાય છે:

પરથી લેવામાં આવેલ તસવીર openstack.org

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

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

તમામ પ્રોજેક્ટ્સ અને તેમના હેતુઓની સંપૂર્ણ સૂચિ જોઈ શકાય છે અહીં.

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

જો કે, જો તમે તેને જુઓ, તો OpenStack માં ચાલતી તમામ સેવાઓ આખરે નેટવર્ક સાથે જોડાયેલ અમુક પ્રકારની વર્ચ્યુઅલ મશીન (અથવા કન્ટેનર) છે. પ્રશ્ન ઊભો થાય છે - શા માટે આપણને આટલા બધા તત્વોની જરૂર છે?

ચાલો વર્ચ્યુઅલ મશીન બનાવવા અને તેને નેટવર્ક સાથે કનેક્ટ કરવા અને Openstack માં સતત સ્ટોરેજ માટેના અલ્ગોરિધમમાંથી પસાર થઈએ.

1. જ્યારે તમે મશીન બનાવવા માટે વિનંતી કરો છો, તે હોરાઇઝન (ડૅશબોર્ડ) દ્વારા વિનંતી હોય અથવા CLI દ્વારા વિનંતી હોય, પ્રથમ વસ્તુ જે થાય છે તે કીસ્ટોન પર તમારી વિનંતીની અધિકૃતતા છે - શું તમે મશીન બનાવી શકો છો, શું તેની પાસે છે આ નેટવર્કનો ઉપયોગ કરવાનો અધિકાર, શું તમારો ડ્રાફ્ટ ક્વોટા, વગેરે.
2. કીસ્ટોન તમારી વિનંતીને પ્રમાણિત કરે છે અને પ્રતિભાવ સંદેશમાં એક પ્રમાણીકરણ ટોકન જનરેટ કરે છે, જેનો આગળ ઉપયોગ કરવામાં આવશે. કીસ્ટોન તરફથી પ્રતિસાદ મળ્યા પછી, વિનંતી નોવા (nova api) તરફ મોકલવામાં આવે છે.
3. નોવા-એપીઆઈ અગાઉ જનરેટ કરેલ ઓથ ટોકનનો ઉપયોગ કરીને કીસ્ટોનનો સંપર્ક કરીને તમારી વિનંતીની માન્યતા તપાસે છે
4. કીસ્ટોન પ્રમાણીકરણ કરે છે અને આ પ્રમાણીકરણ ટોકન પર આધારિત પરવાનગીઓ અને પ્રતિબંધો પર માહિતી પ્રદાન કરે છે.
5. Nova-api નોવા-ડેટાબેઝમાં નવા VM માટે એન્ટ્રી બનાવે છે અને મશીનને નોવા-શેડ્યૂલર બનાવવાની વિનંતી પસાર કરે છે.
6. નોવા-શેડ્યુલર હોસ્ટ (કોમ્પ્યુટર નોડ) પસંદ કરે છે જેના પર નિર્દિષ્ટ પરિમાણો, વજન અને ઝોનના આધારે VM ગોઠવવામાં આવશે. આનો રેકોર્ડ અને VM ID નોવા-ડેટાબેઝ પર લખવામાં આવે છે.
7. આગળ, નોવા-શેડ્યૂલર એક દાખલો જમાવવાની વિનંતી સાથે નોવા-કમ્પ્યુટનો સંપર્ક કરે છે. નોવા-કમ્પ્યુટ સંપર્કો નોવા-કંડક્ટર મશીન પરિમાણો વિશે માહિતી મેળવવા માટે (નોવા-કન્ડક્ટર એ નોવા એલિમેન્ટ છે જે નોવા-ડેટાબેઝ અને નોવા-કમ્પ્યુટ વચ્ચે પ્રોક્સી સર્વર તરીકે કાર્ય કરે છે, ડેટાબેઝ સાથે સમસ્યાઓ ટાળવા માટે નોવા-ડેટાબેઝની વિનંતીઓની સંખ્યા મર્યાદિત કરે છે. સુસંગતતા લોડ ઘટાડો).
8. નોવા-કંડક્ટર નોવા-ડેટાબેઝમાંથી વિનંતી કરેલી માહિતી મેળવે છે અને તેને નોવા-કમ્પ્યુટમાં પસાર કરે છે.
9. આગળ, ઈમેજ આઈડી મેળવવા માટે નોવા-કમ્પ્યુટ કોલ ગ્લાન્સ. Glace કીસ્ટોનમાં વિનંતીને માન્ય કરે છે અને વિનંતી કરેલી માહિતી પરત કરે છે.
10. નેટવર્ક પરિમાણો વિશે માહિતી મેળવવા માટે નોવા-કમ્પ્યુટ સંપર્કો ન્યુટ્રોન. નજરની જેમ જ, ન્યુટ્રોન કીસ્ટોનમાં વિનંતીને માન્ય કરે છે, જે પછી તે ડેટાબેઝમાં એન્ટ્રી બનાવે છે (પોર્ટ ઓળખકર્તા, વગેરે), પોર્ટ બનાવવાની વિનંતી બનાવે છે અને વિનંતી કરેલી માહિતી નોવા-કમ્પ્યુટમાં પરત કરે છે.
11. વર્ચ્યુઅલ મશીનને વોલ્યુમ ફાળવવાની વિનંતી સાથે નોવા-કમ્પ્યુટ કોન્ટેક્ટ્સ સિન્ડર. નજરની જેમ, સાઇડર કીસ્ટોનમાં વિનંતીને માન્ય કરે છે, વોલ્યુમ બનાવવાની વિનંતી બનાવે છે અને વિનંતી કરેલી માહિતી પરત કરે છે.
12. ઉલ્લેખિત પરિમાણો સાથે વર્ચ્યુઅલ મશીન જમાવવાની વિનંતી સાથે નોવા-કમ્પ્યુટ સંપર્કો libvirt.

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

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

ન્યુટ્રોન, નેટવર્ક સેવા તરીકે, ક્લાઉડ ઈન્ફ્રાસ્ટ્રક્ચરના નેટવર્ક ભાગને સંચાલિત કરવા માટે API પ્રદાન કરે છે. સેવા નેટવર્ક-એઝ-એ-સર્વિસ (NaaS) નામનું એબ્સ્ટ્રેક્શન લેયર પ્રદાન કરીને ઓપનસ્ટૅકના નેટવર્કિંગ ભાગને સત્તા આપે છે અને તેનું સંચાલન કરે છે. એટલે કે, નેટવર્ક એ સમાન વર્ચ્યુઅલ માપી શકાય તેવું એકમ છે, ઉદાહરણ તરીકે, વર્ચ્યુઅલ CPU કોરો અથવા RAM નો જથ્થો.

પરંતુ OpenStack ના નેટવર્ક ભાગના આર્કિટેક્ચર પર આગળ વધતા પહેલા, ચાલો ધ્યાનમાં લઈએ કે OpenStack માં આ નેટવર્ક કેવી રીતે કાર્ય કરે છે અને શા માટે નેટવર્ક એ ક્લાઉડનો એક મહત્વપૂર્ણ અને અભિન્ન ભાગ છે.

તેથી અમારી પાસે બે RED ક્લાયંટ VM અને બે GREEN ક્લાયન્ટ VM છે. ચાલો ધારીએ કે આ મશીનો આ રીતે બે હાઇપરવાઇઝર પર સ્થિત છે:

આ ક્ષણે, આ માત્ર 4 સર્વર્સનું વર્ચ્યુઅલાઈઝેશન છે અને વધુ કંઈ નથી, કારણ કે અત્યાર સુધી અમે 4 સર્વરને વર્ચ્યુઅલાઈઝ કરવાનું કર્યું છે, તેમને બે ભૌતિક સર્વર પર મૂકીને. અને અત્યાર સુધી તેઓ નેટવર્ક સાથે પણ જોડાયેલા નથી.

વાદળ બનાવવા માટે, આપણે ઘણા ઘટકો ઉમેરવાની જરૂર છે. પ્રથમ, અમે નેટવર્ક ભાગને વર્ચ્યુઅલાઈઝ કરીએ છીએ - અમારે આ 4 મશીનોને જોડીમાં જોડવાની જરૂર છે, અને ક્લાયંટને L2 કનેક્શન જોઈએ છે. તમે સ્વીચનો ઉપયોગ કરી શકો છો અને ટ્રંકને તેની દિશામાં ગોઠવી શકો છો અને લિનક્સ બ્રિજનો ઉપયોગ કરીને દરેક વસ્તુને ઉકેલી શકો છો અથવા, વધુ અદ્યતન વપરાશકર્તાઓ માટે, ઓપન સ્વિચ (અમે આના પર પછીથી પાછા આવીશું). પરંતુ ત્યાં ઘણા બધા નેટવર્ક હોઈ શકે છે, અને L2 ને સ્વીચ દ્વારા સતત દબાણ કરવું એ શ્રેષ્ઠ વિચાર નથી - ત્યાં વિવિધ વિભાગો છે, એક સેવા ડેસ્ક છે, એપ્લિકેશન પૂર્ણ થવાની રાહ જોવાના મહિનાઓ છે, મુશ્કેલીનિવારણના અઠવાડિયા - આધુનિક વિશ્વમાં આ અભિગમ હવે કામ કરતું નથી. અને જેટલી જલ્દી કંપની આને સમજે છે, તેના માટે આગળ વધવું તેટલું સરળ છે. તેથી, હાઇપરવાઇઝર્સ વચ્ચે અમે એક L3 નેટવર્ક પસંદ કરીશું જેના દ્વારા અમારા વર્ચ્યુઅલ મશીનો વાતચીત કરશે, અને આ L3 નેટવર્કની ટોચ પર અમે વર્ચ્યુઅલ L2 ઓવરલે નેટવર્ક્સ બનાવીશું જ્યાં અમારા વર્ચ્યુઅલ મશીનોનો ટ્રાફિક ચાલશે. તમે એન્કેપ્સ્યુલેશન તરીકે GRE, Geneve અથવા VxLAN નો ઉપયોગ કરી શકો છો. ચાલો હવે પછીના પર ધ્યાન કેન્દ્રિત કરીએ, જો કે તે ખાસ મહત્વનું નથી.

અમારે ક્યાંક VTEP શોધવાની જરૂર છે (મને આશા છે કે દરેક વ્યક્તિ VxLAN પરિભાષાથી પરિચિત હશે). અમારી પાસે L3 નેટવર્ક સીધું સર્વરથી આવતું હોવાથી, અમને સર્વર પર VTEP મૂકવાથી કંઈપણ અટકાવતું નથી, અને OVS (OpenvSwitch) આ કરવા માટે ઉત્તમ છે. પરિણામે, અમને આ ડિઝાઇન મળી:

VM વચ્ચેનો ટ્રાફિક વિભાજિત હોવો આવશ્યક હોવાથી, વર્ચ્યુઅલ મશીનો તરફના પોર્ટમાં અલગ અલગ vlan નંબરો હશે. ટેગ નંબર માત્ર એક વર્ચ્યુઅલ સ્વિચમાં જ ભૂમિકા ભજવે છે, કારણ કે જ્યારે VxLAN માં સમાવિષ્ટ થઈએ ત્યારે અમે તેને સરળતાથી દૂર કરી શકીએ છીએ, કારણ કે અમારી પાસે VNI હશે.

હવે અમે કોઈપણ સમસ્યા વિના તેમના માટે અમારા મશીનો અને વર્ચ્યુઅલ નેટવર્ક બનાવી શકીએ છીએ.

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

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

એટલે કે, અમને નીચેનો આકૃતિ મળે છે:

L2 ટનલ તમામ કમ્પ્યુટીંગ નોડથી કંટ્રોલ નોડમાં ભેગી થાય છે. નોડ જ્યાં આ નેટવર્ક્સ માટે L3 ઈન્ટરફેસ સ્થિત છે, દરેક અલગતા માટે સમર્પિત નેમસ્પેસમાં.

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

પરિણામે, અમને આ રેખાકૃતિ મળી:

વાજબી પ્રશ્ન એ છે કે શા માટે કમ્પ્યુટ નોડ્સ પર ગેટવે જાતે બનાવતા નથી? આ કોઈ મોટી સમસ્યા નથી; વધુમાં, જો તમે વિતરિત રાઉટર (DVR) ચાલુ કરો છો, તો આ કામ કરશે. આ દૃશ્યમાં, અમે કેન્દ્રિય ગેટવે સાથેના સૌથી સરળ વિકલ્પ પર વિચાર કરી રહ્યા છીએ, જેનો ઉપયોગ Openstackમાં મૂળભૂત રીતે થાય છે. ઉચ્ચ-લોડ કાર્યો માટે, તેઓ વિતરિત રાઉટર અને પ્રવેગક તકનીકો જેમ કે SR-IOV અને પાસથ્રુ બંનેનો ઉપયોગ કરશે, પરંતુ જેમ તેઓ કહે છે, તે સંપૂર્ણપણે અલગ વાર્તા છે. પ્રથમ, ચાલો મૂળભૂત ભાગ સાથે વ્યવહાર કરીએ, અને પછી અમે વિગતોમાં જઈશું.

ખરેખર, અમારી યોજના પહેલેથી જ કાર્યક્ષમ છે, પરંતુ તેમાં કેટલીક ઘોંઘાટ છે:

• અમારે કોઈક રીતે અમારા મશીનોને સુરક્ષિત રાખવાની જરૂર છે, એટલે કે, ક્લાયન્ટ તરફ સ્વિચ ઈન્ટરફેસ પર ફિલ્ટર મૂકો.
• વર્ચ્યુઅલ મશીન માટે આપમેળે IP સરનામું મેળવવાનું શક્ય બનાવો, જેથી તમારે દર વખતે કન્સોલ દ્વારા તેમાં લૉગ ઇન કરવું અને સરનામું રજીસ્ટર કરવું ન પડે.

ચાલો મશીન સંરક્ષણથી પ્રારંભ કરીએ. આ માટે તમે બેનલ iptables નો ઉપયોગ કરી શકો છો, કેમ નહીં.

એટલે કે, હવે અમારી ટોપોલોજી થોડી વધુ જટિલ બની ગઈ છે:

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

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

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

અને અહીં NAT અમારી મદદ માટે આવે છે - અમે NAT અનુવાદનો ઉપયોગ કરીને ડિફોલ્ટ નેમસ્પેસ દ્વારા ક્લાયન્ટ માટે બહારની દુનિયાને ઍક્સેસ કરવાનું શક્ય બનાવીશું. સારું, અહીં એક નાની સમસ્યા છે. આ સારું છે જો ક્લાયંટ સર્વર ક્લાયંટ તરીકે કાર્ય કરે છે અને સર્વર તરીકે નહીં - એટલે કે, તે જોડાણો સ્વીકારવાને બદલે પ્રારંભ કરે છે. પરંતુ અમારી સાથે તે વિપરીત હશે. આ કિસ્સામાં, અમારે ડેસ્ટિનેશન NAT કરવાની જરૂર છે જેથી ટ્રાફિક પ્રાપ્ત કરતી વખતે, કંટ્રોલ નોડ સમજી શકે કે આ ટ્રાફિક ક્લાયંટ A ના વર્ચ્યુઅલ મશીન A માટે છે, જેનો અર્થ છે કે આપણે બાહ્ય સરનામાંમાંથી NAT અનુવાદ કરવાની જરૂર છે, ઉદાહરણ તરીકે 100.1.1.1 .10.0.0.1, આંતરિક સરનામા 100 પર. આ કિસ્સામાં, જો કે તમામ ક્લાયન્ટ્સ સમાન નેટવર્કનો ઉપયોગ કરશે, આંતરિક અલગતા સંપૂર્ણપણે સાચવેલ છે. એટલે કે, આપણે કંટ્રોલ નોડ પર dNAT અને sNAT કરવાની જરૂર છે. ફ્લોટિંગ સરનામાંઓ અથવા બાહ્ય નેટવર્ક્સ સાથે એક જ નેટવર્કનો ઉપયોગ કરવો કે નહીં, અથવા બંને એક સાથે, તમે ક્લાઉડમાં શું લાવવા માંગો છો તેના પર નિર્ભર છે. અમે ડાયાગ્રામમાં ફ્લોટિંગ સરનામાં ઉમેરીશું નહીં, પરંતુ પહેલાથી ઉમેરાયેલા બાહ્ય નેટવર્ક્સને છોડીશું - દરેક ક્લાયંટનું પોતાનું બાહ્ય નેટવર્ક છે (ડાયાગ્રામમાં તેઓ બાહ્ય ઇન્ટરફેસ પર vlan 200 અને XNUMX તરીકે દર્શાવેલ છે).

પરિણામે, અમને એક રસપ્રદ અને તે જ સમયે સારી રીતે વિચારી શકાય તેવું સોલ્યુશન મળ્યું, જેમાં ચોક્કસ લવચીકતા છે પરંતુ હજુ સુધી ખામી સહિષ્ણુતા મિકેનિઝમ્સ નથી.

પ્રથમ, અમારી પાસે ફક્ત એક નિયંત્રણ નોડ છે - તેની નિષ્ફળતા તમામ સિસ્ટમોના પતન તરફ દોરી જશે. આ સમસ્યાને ઠીક કરવા માટે, તમારે ઓછામાં ઓછા 3 નોડ્સનો કોરમ બનાવવાની જરૂર છે. ચાલો આને આકૃતિમાં ઉમેરીએ:

સ્વાભાવિક રીતે, બધા નોડ સિંક્રનાઇઝ થાય છે અને જ્યારે એક સક્રિય નોડ નીકળી જાય છે, ત્યારે અન્ય નોડ તેની જવાબદારીઓ સંભાળશે.

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

Ceph તમને શક્ય બેકઅપ વિકલ્પોના સમૂહ સાથે અત્યંત ઉપલબ્ધ ડેટા સ્ટોરેજ સોલ્યુશન બનાવવાની મંજૂરી આપે છે, જેમાં ડિસ્કના સ્થાનને ધ્યાનમાં લેતા, વિવિધ ડિસ્ક પર સંપૂર્ણ ડેટા પ્રતિકૃતિ સાથે સમાપ્ત થતા પેરિટી ચેકિંગ (રેઇડ 5 અથવા 6ના સમાન) સાથેના કોડ્સથી શરૂ થાય છે. સર્વર, અને કેબિનેટમાં સર્વર, વગેરે.

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

નોંધ: તમે હાઇપરકન્વર્જ્ડ કમ્પ્યુટ નોડ્સ પણ બનાવી શકો છો - આ એક નોડ પર અનેક ફંક્શન્સને સંયોજિત કરવાનો ખ્યાલ છે - ઉદાહરણ તરીકે, સ્ટોરેજ+કમ્પ્યુટ - સેફ સ્ટોરેજ માટે વિશેષ ગાંઠો સમર્પિત કર્યા વિના. અમને સમાન ફોલ્ટ-ટોલરન્ટ સ્કીમ મળશે - કારણ કે SDS અમે ઉલ્લેખિત આરક્ષણ સ્તર સાથે ડેટા આરક્ષિત કરશે. જો કે, હાયપરકન્વર્જ્ડ નોડ્સ હંમેશા એક સમાધાન હોય છે - કારણ કે સ્ટોરેજ નોડ માત્ર હવાને ગરમ કરતું નથી કારણ કે તે પ્રથમ નજરમાં લાગે છે (કારણ કે તેના પર કોઈ વર્ચ્યુઅલ મશીન નથી) - તે SDS સર્વિસ કરવા માટે CPU સંસાધનો ખર્ચ કરે છે (હકીકતમાં, તે બધું જ કરે છે. નોડ્સ, ડિસ્ક વગેરેની નિષ્ફળતા પછી નકલ અને પુનઃપ્રાપ્તિ). એટલે કે, જો તમે તેને સ્ટોરેજ સાથે જોડશો તો તમે ગણતરી નોડની થોડી શક્તિ ગુમાવશો.

આ બધી સામગ્રીને કોઈક રીતે મેનેજ કરવાની જરૂર છે - અમને કંઈક જોઈએ છે જેના દ્વારા આપણે મશીન, નેટવર્ક, વર્ચ્યુઅલ રાઉટર વગેરે બનાવી શકીએ. આ કરવા માટે, અમે કંટ્રોલ નોડમાં એક સેવા ઉમેરીશું જે ડેશબોર્ડ તરીકે કાર્ય કરશે - ક્લાયંટ http/ https દ્વારા આ પોર્ટલ સાથે જોડાઈ શકશે અને તેને જે જોઈએ તે બધું કરી શકશે (સારું, લગભગ).

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

ન્યુટ્રોન આર્કિટેક્ચર

ઓપનસ્ટૅકમાં, તે ન્યુટ્રોન છે જે વર્ચ્યુઅલ મશીન પોર્ટ્સને સામાન્ય L2 નેટવર્ક સાથે જોડવા, વિવિધ L2 નેટવર્ક્સ પર સ્થિત VM વચ્ચે ટ્રાફિક રૂટીંગની ખાતરી કરવા તેમજ આઉટવર્ડ રૂટીંગ, NAT, ફ્લોટિંગ IP, DHCP વગેરે જેવી સેવાઓ પ્રદાન કરવા માટે જવાબદાર છે.

ઉચ્ચ સ્તરે, નેટવર્ક સેવાનું સંચાલન (મૂળભૂત ભાગ) નીચે પ્રમાણે વર્ણવી શકાય છે.

VM શરૂ કરતી વખતે, નેટવર્ક સેવા:

1. આપેલ VM (અથવા પોર્ટ) માટે પોર્ટ બનાવે છે અને તેના વિશે DHCP સેવાને સૂચિત કરે છે;
2. નવું વર્ચ્યુઅલ નેટવર્ક ઉપકરણ બનાવવામાં આવ્યું છે (libvirt દ્વારા);
3. VM પગલું 1 માં બનાવેલ પોર્ટ(પો) સાથે જોડાય છે;

વિચિત્ર રીતે, ન્યુટ્રોનનું કાર્ય લિનક્સ - નેમસ્પેસ, iptables, લિનક્સ બ્રિજ, openvswitch, conntrack, વગેરેમાં ડાઇવ કરનારા દરેકને પરિચિત માનક પદ્ધતિઓ પર આધારિત છે.

તે તરત જ સ્પષ્ટ થવું જોઈએ કે ન્યુટ્રોન એ SDN નિયંત્રક નથી.

ન્યુટ્રોન ઘણા એકબીજા સાથે જોડાયેલા ઘટકો ધરાવે છે:

ઓપનસ્ટૅક-ન્યુટ્રોન-સર્વર એ એક ડિમન છે જે API દ્વારા વપરાશકર્તા વિનંતીઓ સાથે કામ કરે છે. આ રાક્ષસ કોઈપણ નેટવર્ક કનેક્શનની નોંધણીમાં સામેલ નથી, પરંતુ તેના પ્લગિન્સને આ માટે જરૂરી માહિતી પ્રદાન કરે છે, જે પછી ઇચ્છિત નેટવર્ક ઘટકને ગોઠવે છે. OpenStack નોડ્સ પર ન્યુટ્રોન એજન્ટો ન્યુટ્રોન સર્વર સાથે નોંધણી કરાવે છે.

ન્યુટ્રોન-સર્વર વાસ્તવમાં અજગરમાં લખાયેલ એપ્લિકેશન છે, જેમાં બે ભાગોનો સમાવેશ થાય છે:

• REST સેવા
• ન્યુટ્રોન પ્લગઇન (કોર/સેવા)

REST સેવા અન્ય ઘટકો (ઉદાહરણ તરીકે, કેટલીક માહિતી પ્રદાન કરવાની વિનંતી વગેરે) તરફથી API કૉલ્સ પ્રાપ્ત કરવા માટે રચાયેલ છે.

પ્લગઇન્સ એ પ્લગ-ઇન સોફ્ટવેર ઘટકો/મોડ્યુલ્સ છે જેને API વિનંતીઓ દરમિયાન બોલાવવામાં આવે છે - એટલે કે, સેવાનું એટ્રિબ્યુશન તેમના દ્વારા થાય છે. પ્લગઇન્સ બે પ્રકારમાં વહેંચાયેલા છે - સેવા અને રૂટ. નિયમ પ્રમાણે, હોર્સ પ્લગઇન મુખ્યત્વે એડ્રેસ સ્પેસ અને VM વચ્ચેના L2 કનેક્શનને મેનેજ કરવા માટે જવાબદાર છે, અને સર્વિસ પ્લગઇન્સ પહેલેથી જ VPN અથવા FW જેવી વધારાની કાર્યક્ષમતા પ્રદાન કરે છે.

આજે ઉપલબ્ધ પ્લગિન્સની સૂચિ ઉદાહરણ તરીકે જોઈ શકાય છે અહીં

ત્યાં ઘણા સેવા પ્લગઈનો હોઈ શકે છે, પરંતુ માત્ર એક હોર્સ પ્લગઈન હોઈ શકે છે.

openstack-neutron-ml2 પ્રમાણભૂત Openstack રૂટ પ્લગઇન છે. આ પ્લગઇન મોડ્યુલર આર્કિટેક્ચર ધરાવે છે (તેના પુરોગામીથી વિપરીત) અને તેની સાથે જોડાયેલા ડ્રાઇવરો દ્વારા નેટવર્ક સેવાને ગોઠવે છે. અમે થોડા સમય પછી પ્લગઇનને જ જોઈશું, કારણ કે હકીકતમાં તે નેટવર્ક ભાગમાં OpenStack પાસે રહેલી લવચીકતા આપે છે. રૂટ પ્લગઇનને બદલી શકાય છે (ઉદાહરણ તરીકે, કોન્ટ્રાઇલ નેટવર્કીંગ આવી બદલી કરે છે).

RPC સેવા (rabbitmq-server) — એક સેવા જે કતાર વ્યવસ્થાપન અને અન્ય OpenStack સેવાઓ સાથેની ક્રિયાપ્રતિક્રિયા તેમજ નેટવર્ક સેવા એજન્ટો વચ્ચેની ક્રિયાપ્રતિક્રિયા પૂરી પાડે છે.

નેટવર્ક એજન્ટો — એજન્ટો કે જે દરેક નોડમાં સ્થિત છે, જેના દ્વારા નેટવર્ક સેવાઓ ગોઠવવામાં આવે છે.

ત્યાં ઘણા પ્રકારના એજન્ટો છે.

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

આગળ, કોઈ ઓછું મહત્વનું એજન્ટ નથી L3 એજન્ટ. ડિફૉલ્ટ રૂપે, આ ​​એજન્ટ ફક્ત નેટવર્ક નોડ પર ચાલે છે (ઘણીવાર નેટવર્ક નોડ કંટ્રોલ નોડ સાથે જોડવામાં આવે છે) અને ભાડૂત નેટવર્ક્સ (તેના નેટવર્ક અને અન્ય ભાડૂતોના નેટવર્ક્સ બંને વચ્ચે, અને બહારની દુનિયા માટે સુલભ છે) વચ્ચે રૂટીંગ પ્રદાન કરે છે. NAT, તેમજ DHCP સેવા). જો કે, DVR (વિતરિત રાઉટર) નો ઉપયોગ કરતી વખતે, L3 પ્લગઇનની જરૂરિયાત ગણતરી નોડ્સ પર પણ દેખાય છે.

L3 એજન્ટ દરેક ભાડૂતને તેના પોતાના આઇસોલેટેડ નેટવર્કનો સમૂહ અને ટ્રાફિકને રૂટ કરતા વર્ચ્યુઅલ રાઉટર્સની કાર્યક્ષમતા અને લેયર 2 નેટવર્ક માટે ગેટવે સેવાઓ પ્રદાન કરવા માટે Linux નેમસ્પેસનો ઉપયોગ કરે છે.

ડેટાબેઝ — નેટવર્ક્સ, સબનેટ્સ, પોર્ટ્સ, પૂલ, વગેરેના ઓળખકર્તાઓનો ડેટાબેઝ.

હકીકતમાં, ન્યુટ્રોન કોઈપણ નેટવર્ક એન્ટિટીના નિર્માણમાંથી API વિનંતીઓ સ્વીકારે છે, વિનંતીને પ્રમાણિત કરે છે, અને RPC (જો તે કેટલાક પ્લગઇન અથવા એજન્ટને ઍક્સેસ કરે છે) અથવા REST API (જો તે SDN માં વાતચીત કરે છે) એજન્ટોને (પ્લગઇન દ્વારા) ટ્રાન્સમિટ કરે છે. વિનંતી કરેલ સેવાને ગોઠવવા માટે જરૂરી સૂચનાઓ.

હવે ચાલો ટેસ્ટ ઇન્સ્ટોલેશન તરફ વળીએ (તે કેવી રીતે જમાવવામાં આવે છે અને તેમાં શું સમાવવામાં આવેલ છે, આપણે વ્યવહારિક ભાગમાં પછીથી જોઈશું) અને દરેક ઘટક ક્યાં સ્થિત છે તે જોઈએ:

(overcloud) [stack@undercloud ~]$ openstack network agent list  
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| ID                                   | Agent Type         | Host                                | Availability Zone | Alive | State | Binary                    |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| 10495de9-ba4b-41fe-b30a-b90ec3f8728b | Open vSwitch agent | overcloud-novacompute-1.localdomain | None              | :-)   | UP    | neutron-openvswitch-agent |
| 1515ad4a-5972-46c3-af5f-e5446dff7ac7 | L3 agent           | overcloud-controller-0.localdomain  | nova              | :-)   | UP    | neutron-l3-agent          |
| 322e62ca-1e5a-479e-9a96-4f26d09abdd7 | DHCP agent         | overcloud-controller-0.localdomain  | nova              | :-)   | UP    | neutron-dhcp-agent        |
| 9c1de2f9-bac5-400e-998d-4360f04fc533 | Open vSwitch agent | overcloud-novacompute-0.localdomain | None              | :-)   | UP    | neutron-openvswitch-agent |
| d99c5657-851e-4d3c-bef6-f1e3bb1acfb0 | Open vSwitch agent | overcloud-controller-0.localdomain  | None              | :-)   | UP    | neutron-openvswitch-agent |
| ff85fae6-5543-45fb-a301-19c57b62d836 | Metadata agent     | overcloud-controller-0.localdomain  | None              | :-)   | UP    | neutron-metadata-agent    |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
(overcloud) [stack@undercloud ~]$ 

વાસ્તવમાં, તે ન્યુટ્રોનનું સંપૂર્ણ માળખું છે. હવે તે ML2 પ્લગઇન પર થોડો સમય પસાર કરવા યોગ્ય છે.

મોડ્યુલર લેયર 2

ઉપર જણાવ્યા મુજબ, પ્લગઇન એ પ્રમાણભૂત OpenStack રૂટ પ્લગઇન છે અને તેમાં મોડ્યુલર આર્કિટેક્ચર છે.

ML2 પ્લગઇનના પુરોગામી પાસે મોનોલિથિક માળખું હતું, જે મંજૂરી આપતું ન હતું, ઉદાહરણ તરીકે, એક ઇન્સ્ટોલેશનમાં ઘણી તકનીકોના મિશ્રણનો ઉપયોગ કરીને. ઉદાહરણ તરીકે, તમે એક જ સમયે openvswitch અને linuxbridge બંનેનો ઉપયોગ કરી શકતા નથી - કાં તો પ્રથમ અથવા બીજા. આ કારણોસર, તેના આર્કિટેક્ચર સાથે ML2 પ્લગઇન બનાવવામાં આવ્યું હતું.

ML2 માં બે ઘટકો છે - બે પ્રકારના ડ્રાઈવરો: પ્રકાર ડ્રાઈવરો અને મિકેનિઝમ ડ્રાઈવરો.

ડ્રાઇવરો લખો નેટવર્ક કનેક્શનને ગોઠવવા માટે ઉપયોગમાં લેવાતી તકનીકો નક્કી કરો, ઉદાહરણ તરીકે VxLAN, VLAN, GRE. તે જ સમયે, ડ્રાઇવર વિવિધ તકનીકોનો ઉપયોગ કરવાની મંજૂરી આપે છે. પ્રમાણભૂત ટેકનોલોજી ઓવરલે નેટવર્ક્સ અને vlan બાહ્ય નેટવર્ક્સ માટે VxLAN એન્કેપ્સ્યુલેશન છે.

પ્રકાર ડ્રાઇવરોમાં નીચેના નેટવર્ક પ્રકારો શામેલ છે:

ફ્લેટ - ટેગીંગ વિના નેટવર્ક
વી.એલ.એન.એન. - ટૅગ કરેલ નેટવર્ક
સ્થાનિક — ઓલ-ઇન-વન ઇન્સ્ટોલેશન માટે એક વિશિષ્ટ પ્રકારનું નેટવર્ક (આવા ઇન્સ્ટોલેશન કાં તો વિકાસકર્તાઓ માટે અથવા તાલીમ માટે જરૂરી છે)
જીઆરએ — GRE ટનલનો ઉપયોગ કરીને નેટવર્કને ઓવરલે કરો
VxLAN — VxLAN ટનલનો ઉપયોગ કરીને નેટવર્કને ઓવરલે કરો

મિકેનિઝમ ડ્રાઇવરો ટૂલ્સને વ્યાખ્યાયિત કરો કે જે પ્રકાર ડ્રાઇવરમાં ઉલ્લેખિત તકનીકોના સંગઠનને સુનિશ્ચિત કરે છે - ઉદાહરણ તરીકે, openvswitch, sr-iov, opendaylight, OVN, વગેરે.

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

ઉદાહરણ: જો આપણે OVS સાથે ML2 નો ઉપયોગ કરીએ છીએ, તો દરેક કમ્પ્યુટિંગ નોડ પર L2 એજન્ટ ઇન્સ્ટોલ કરવામાં આવે છે જે OVS નું સંચાલન કરે છે. જો કે, જો આપણે ઉપયોગ કરીએ છીએ, ઉદાહરણ તરીકે, OVN અથવા OpenDayLight, તો OVS નું નિયંત્રણ તેમના અધિકારક્ષેત્ર હેઠળ આવે છે - ન્યુટ્રોન, રૂટ પ્લગઇન દ્વારા, કંટ્રોલરને આદેશો આપે છે, અને તે પહેલેથી જ તેને જે કહેવામાં આવ્યું હતું તે કરે છે.

ચાલો ઓપન vSwitch પર બ્રશ અપ કરીએ

આ ક્ષણે, OpenStack ના મુખ્ય ઘટકોમાંનું એક ઓપન vSwitch છે.
કોઈપણ વધારાના વિક્રેતા SDN જેમ કે જ્યુનિપર કોન્ટ્રેલ અથવા નોકિયા ન્યુએજ વગર OpenStack ઇન્સ્ટોલ કરતી વખતે, OVS એ ક્લાઉડ નેટવર્કનું મુખ્ય નેટવર્ક ઘટક છે અને, iptables, conntrack, નેમસ્પેસ સાથે, તમને સંપૂર્ણ સુવિધાયુક્ત મલ્ટિ-ટેનન્સી ઓવરલે નેટવર્ક્સ ગોઠવવાની મંજૂરી આપે છે. સ્વાભાવિક રીતે, આ ઘટકને બદલી શકાય છે, ઉદાહરણ તરીકે, જ્યારે તૃતીય-પક્ષ માલિકી (વિક્રેતા) SDN સોલ્યુશન્સનો ઉપયોગ કરો.

OVS એ એક ઓપન સોર્સ સોફ્ટવેર સ્વીચ છે જે વર્ચ્યુઅલાઈઝ્ડ વાતાવરણમાં વર્ચ્યુઅલ ટ્રાફિક ફોરવર્ડર તરીકે ઉપયોગ કરવા માટે રચાયેલ છે.

આ ક્ષણે, OVS પાસે ખૂબ જ યોગ્ય કાર્યક્ષમતા છે, જેમાં QoS, LACP, VLAN, VxLAN, GENEVE, OpenFlow, DPDK વગેરે જેવી તકનીકોનો સમાવેશ થાય છે.

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

OVS ના ત્રણ મહત્વના ઘટકો છે જેના વિશે તમારે જાગૃત રહેવાની જરૂર છે:

• કર્નલ મોડ્યુલ — કર્નલ સ્પેસમાં સ્થિત એક ઘટક કે જે નિયંત્રણ તત્વમાંથી પ્રાપ્ત નિયમોના આધારે ટ્રાફિકની પ્રક્રિયા કરે છે;
• વીસ્વિચ ડિમન (ovs-vswitchd) એ યુઝર સ્પેસમાં લોંચ કરવામાં આવેલી પ્રક્રિયા છે જે કર્નલ મોડ્યુલના પ્રોગ્રામિંગ માટે જવાબદાર છે - એટલે કે, તે સ્વીચની કામગીરીના તર્કને સીધી રીતે રજૂ કરે છે.
• ડેટાબેસ સર્વર - OVS ચલાવતા દરેક હોસ્ટ પર સ્થિત સ્થાનિક ડેટાબેઝ, જેમાં રૂપરેખાંકન સંગ્રહિત થાય છે. SDN નિયંત્રકો OVSDB પ્રોટોકોલનો ઉપયોગ કરીને આ મોડ્યુલ દ્વારા વાતચીત કરી શકે છે.

આ તમામ ડાયગ્નોસ્ટિક અને મેનેજમેન્ટ યુટિલિટીઝના સમૂહ સાથે છે, જેમ કે ovs-vsctl, ovs-appctl, ovs-ofctl, વગેરે.

હાલમાં, ઓપનસ્ટૅકનો ઉપયોગ ટેલિકોમ ઓપરેટરો દ્વારા નેટવર્ક ફંક્શનને તેના પર સ્થાનાંતરિત કરવા માટે વ્યાપકપણે થાય છે, જેમ કે EPC, SBC, HLR, વગેરે. કેટલાક ફંક્શન્સ OVS સાથે સમસ્યા વિના જીવી શકે છે જેમ કે, પરંતુ ઉદાહરણ તરીકે, EPC સબસ્ક્રાઇબર ટ્રાફિકની પ્રક્રિયા કરે છે - પછી તે પસાર થાય છે. ટ્રાફિકની વિશાળ માત્રા (હવે ટ્રાફિક વોલ્યુમ પ્રતિ સેકન્ડમાં કેટલાક સો ગીગાબીટ સુધી પહોંચે છે). સ્વાભાવિક રીતે, કર્નલ સ્પેસ દ્વારા આવા ટ્રાફિકને ચલાવવો (કારણ કે ફોરવર્ડર મૂળભૂત રીતે ત્યાં સ્થિત છે) શ્રેષ્ઠ વિચાર નથી. તેથી, કર્નલને બાયપાસ કરીને NIC થી યુઝર સ્પેસમાં ટ્રાફિક ફોરવર્ડ કરવા માટે DPDK એક્સિલરેશન ટેક્નોલોજીનો ઉપયોગ કરીને OVS ઘણીવાર સંપૂર્ણપણે યુઝર સ્પેસમાં ગોઠવવામાં આવે છે.

નોંધ: ટેલિકોમ ફંક્શન્સ માટે તૈનાત ક્લાઉડ માટે, ઓવીએસને બાયપાસ કરીને કમ્પ્યુટ નોડમાંથી ટ્રાફિકને સીધા સ્વિચિંગ સાધનો પર આઉટપુટ કરવાનું શક્ય છે. આ હેતુ માટે SR-IOV અને પાસથ્રુ મિકેનિઝમનો ઉપયોગ કરવામાં આવે છે.

વાસ્તવિક લેઆઉટ પર આ કેવી રીતે કાર્ય કરે છે?

સારું, હવે ચાલો વ્યવહારુ ભાગ તરફ આગળ વધીએ અને જોઈએ કે તે બધું વ્યવહારમાં કેવી રીતે કાર્ય કરે છે.

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

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

તેથી, ચાલો ક્રમમાં શરૂ કરીએ. પ્રથમ, થોડો સિદ્ધાંત. અમે TripleO (Openstack પર Openstack) નો ઉપયોગ કરીને Openstack ઇન્સ્ટોલ કરીશું. TripleO નો સાર એ છે કે અમે ઓપનસ્ટૅક ઑલ-ઇન-વન (એટલે ​​કે, એક નોડ પર) ઇન્સ્ટોલ કરીએ છીએ, જેને અંડરક્લાઉડ કહેવાય છે, અને પછી ઑપર ક્લાઉડ તરીકે ઓળખાતા ઑપનસ્ટૅકને ઇન્સ્ટોલ કરવા માટે તૈનાત ઓપનસ્ટૅકની ક્ષમતાઓનો ઉપયોગ કરીએ છીએ. અંડરક્લાઉડ ભૌતિક સર્વર્સ (બેર મેટલ) નું સંચાલન કરવાની તેની સહજ ક્ષમતાનો ઉપયોગ કરશે - આયર્નિક પ્રોજેક્ટ - હાઇપરવાઇઝરની જોગવાઈ કરવા માટે કે જે ગણતરી, નિયંત્રણ, સંગ્રહ ગાંઠોની ભૂમિકા ભજવશે. એટલે કે, અમે Openstack જમાવવા માટે કોઈપણ તૃતીય-પક્ષ સાધનોનો ઉપયોગ કરતા નથી - અમે Openstackનો ઉપયોગ કરીને Openstackનો ઉપયોગ કરીએ છીએ. જેમ જેમ ઇન્સ્ટોલેશન આગળ વધશે તેમ તે વધુ સ્પષ્ટ થશે, તેથી અમે ત્યાં રોકાઈશું નહીં અને આગળ વધીશું નહીં.

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

નોંધ: આપણે વર્ચ્યુઅલ મશીનો પર આધારિત વર્ચ્યુઅલ એન્વાયર્નમેન્ટમાં વર્ચ્યુઅલ મશીનો ચલાવવાના હોવાથી, આપણે સૌ પ્રથમ નેસ્ટેડ વર્ચ્યુઅલાઈઝેશનને સક્ષમ કરવાની જરૂર છે.

તમે તપાસી શકો છો કે નેસ્ટેડ વર્ચ્યુઅલાઈઝેશન સક્ષમ છે કે નહીં આની જેમ:

[root@hp-gen9 bormoglotx]# cat /sys/module/kvm_intel/parameters/nested
N
[root@hp-gen9 bormoglotx]# 

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

આપણે વર્ચ્યુઅલ મશીનોમાંથી નીચેના સર્કિટને એસેમ્બલ કરવાની જરૂર છે:

મારા કિસ્સામાં, વર્ચ્યુઅલ મશીનોને કનેક્ટ કરવા માટે જે ભાવિ ઇન્સ્ટોલેશનનો ભાગ છે (અને મને તેમાંથી 7 મળ્યા છે, પરંતુ જો તમારી પાસે ઘણા સંસાધનો ન હોય તો તમે 4 સાથે મેળવી શકો છો), મેં OpenvSwitch નો ઉપયોગ કર્યો. મેં એક ovs બ્રિજ બનાવ્યો અને તેની સાથે વર્ચ્યુઅલ મશીનોને પોર્ટ-ગ્રુપ્સ દ્વારા કનેક્ટ કર્યા. આ કરવા માટે, મેં આના જેવી xml ફાઇલ બનાવી છે:

[root@hp-gen9 ~]# virsh net-dumpxml ovs-network-1        
<network>
  <name>ovs-network-1</name>
  <uuid>7a2e7de7-fc16-4e00-b1ed-4d190133af67</uuid>
  <forward mode='bridge'/>
  <bridge name='ovs-br1'/>
  <virtualport type='openvswitch'/>
  <portgroup name='trunk-1'>
    <vlan trunk='yes'>
      <tag id='100'/>
      <tag id='101'/>
      <tag id='102'/>
    </vlan>
  </portgroup>
  <portgroup name='access-100'>
    <vlan>
      <tag id='100'/>
    </vlan>
  </portgroup>
  <portgroup name='access-101'>
    <vlan>
      <tag id='101'/>
    </vlan>
  </portgroup>
</network>

અહીં ત્રણ પોર્ટ જૂથો જાહેર કરવામાં આવ્યા છે - બે એક્સેસ અને એક ટ્રંક (બાદમાં DNS સર્વર માટે જરૂરી હતું, પરંતુ તમે તેના વિના કરી શકો છો, અથવા તેને હોસ્ટ મશીન પર ઇન્સ્ટોલ કરી શકો છો - જે તમારા માટે વધુ અનુકૂળ હોય તે). આગળ, આ નમૂનાનો ઉપયોગ કરીને, અમે virsh net-define દ્વારા આપણું જાહેર કરીએ છીએ:

virsh net-define ovs-network-1.xml 
virsh net-start ovs-network-1 
virsh net-autostart ovs-network-1 

હવે અમે હાઇપરવાઇઝર પોર્ટ રૂપરેખાંકનોને સંપાદિત કરીએ છીએ:

[root@hp-gen9 ~]# cat /etc/sysconfig/network-scripts/ifcfg-ens1f0   
TYPE=Ethernet
NAME=ens1f0
DEVICE=ens1f0
TYPE=OVSPort
DEVICETYPE=ovs
OVS_BRIDGE=ovs-br1
ONBOOT=yes
OVS_OPTIONS="trunk=100,101,102"
[root@hp-gen9 ~]
[root@hp-gen9 ~]# cat /etc/sysconfig/network-scripts/ifcfg-ovs-br1 
DEVICE=ovs-br1
DEVICETYPE=ovs
TYPE=OVSBridge
BOOTPROTO=static
ONBOOT=yes
IPADDR=192.168.255.200
PREFIX=24
[root@hp-gen9 ~]# 

નોંધ: આ દૃશ્યમાં, ovs-br1 પોર્ટ પરનું સરનામું ઍક્સેસિબલ રહેશે નહીં કારણ કે તેની પાસે vlan ટેગ નથી. આને ઠીક કરવા માટે, તમારે sudo ovs-vsctl set port ovs-br1 tag=100 આદેશ જારી કરવાની જરૂર છે. જો કે, રીબૂટ કર્યા પછી, આ ટેગ અદૃશ્ય થઈ જશે (જો કોઈ જાણતું હોય કે તેને સ્થાને કેવી રીતે રાખવું, તો હું ખૂબ આભારી રહીશ). પરંતુ આ એટલું મહત્વનું નથી, કારણ કે અમને ફક્ત ઇન્સ્ટોલેશન દરમિયાન આ સરનામાંની જરૂર પડશે અને જ્યારે Openstack સંપૂર્ણ રીતે જમાવવામાં આવશે ત્યારે તેની જરૂર પડશે નહીં.

આગળ, અમે અન્ડરક્લાઉડ મશીન બનાવીએ છીએ:

virt-install  -n undercloud --description "undercloud"  --os-type=Linux  --os-variant=centos7.0  --ram=8192  --vcpus=8  --disk path=/var/lib/libvirt/images/undercloud.qcow2,bus=virtio,size=40,format=qcow2 --network network:ovs-network-1,model=virtio,portgroup=access-100 --network network:ovs-network-1,model=virtio,portgroup=access-101 --graphics none  --location /var/lib/libvirt/boot/CentOS-7-x86_64-Minimal-2003.iso --extra-args console=ttyS0

ઇન્સ્ટોલેશન દરમિયાન, તમે બધા જરૂરી પરિમાણો સેટ કરો છો, જેમ કે મશીનનું નામ, પાસવર્ડ્સ, વપરાશકર્તાઓ, એનટીપી સર્વર, વગેરે, તમે તરત જ પોર્ટને ગોઠવી શકો છો, પરંતુ મારા માટે વ્યક્તિગત રીતે, ઇન્સ્ટોલેશન પછી, મશીન દ્વારા લૉગ ઇન કરવું વધુ સરળ છે. કન્સોલ અને જરૂરી ફાઇલોને ઠીક કરો. જો તમારી પાસે પહેલેથી જ તૈયાર છબી છે, તો તમે તેનો ઉપયોગ કરી શકો છો, અથવા મેં જે કર્યું તે કરી શકો છો - ન્યૂનતમ Centos 7 છબી ડાઉનલોડ કરો અને VM ઇન્સ્ટોલ કરવા માટે તેનો ઉપયોગ કરો.

સફળ ઇન્સ્ટોલેશન પછી, તમારી પાસે વર્ચ્યુઅલ મશીન હોવું જોઈએ જેના પર તમે અંડરક્લાઉડ ઇન્સ્ટોલ કરી શકો

[root@hp-gen9 bormoglotx]# virsh list
 Id    Name                           State
----------------------------------------------------
 6     dns-server                     running
 62    undercloud                     running

પ્રથમ, ઇન્સ્ટોલેશન પ્રક્રિયા માટે જરૂરી સાધનો ઇન્સ્ટોલ કરો:

sudo yum update -y
sudo yum install -y net-tools
sudo yum install -y wget
sudo yum install -y ipmitool

અન્ડરક્લાઉડ ઇન્સ્ટોલેશન

અમે સ્ટેક યુઝર બનાવીએ છીએ, પાસવર્ડ સેટ કરીએ છીએ, તેને સુડોરમાં ઉમેરીએ છીએ અને તેને પાસવર્ડ દાખલ કર્યા વિના સુડો દ્વારા રૂટ આદેશો ચલાવવાની ક્ષમતા આપીએ છીએ:

useradd stack
passwd stack

echo “stack ALL=(root) NOPASSWD:ALL” > /etc/sudoers.d/stack
chmod 0440 /etc/sudoers.d/stack

હવે અમે હોસ્ટ ફાઇલમાં સંપૂર્ણ અન્ડરક્લાઉડ નામનો ઉલ્લેખ કરીએ છીએ:

vi /etc/hosts

127.0.0.1   undercloud.openstack.rnd localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6

આગળ, અમે રીપોઝીટરીઝ ઉમેરીએ છીએ અને અમને જરૂરી સોફ્ટવેર ઇન્સ્ટોલ કરીએ છીએ:

sudo yum install -y https://trunk.rdoproject.org/centos7/current/python2-tripleo-repos-0.0.1-0.20200409224957.8bac392.el7.noarch.rpm
sudo -E tripleo-repos -b queens current
sudo -E tripleo-repos -b queens current ceph
sudo yum install -y python-tripleoclient
sudo yum install -y ceph-ansible

નોંધ: જો તમે ceph ઇન્સ્ટોલ કરવાની યોજના નથી કરતા, તો તમારે ceph-સંબંધિત આદેશો દાખલ કરવાની જરૂર નથી. મેં ક્વીન્સ રીલીઝનો ઉપયોગ કર્યો છે, પરંતુ તમે તમને ગમે તે કોઈપણ અન્યનો ઉપયોગ કરી શકો છો.

આગળ, અંડરક્લાઉડ રૂપરેખાંકન ફાઇલને વપરાશકર્તાની હોમ ડિરેક્ટરી સ્ટેક પર કૉપિ કરો:

cp /usr/share/instack-undercloud/undercloud.conf.sample ~/undercloud.conf

હવે આપણે આ ફાઇલને આપણા ઇન્સ્ટોલેશનમાં સમાયોજિત કરીને તેને સુધારવાની જરૂર છે.

તમારે ફાઇલની શરૂઆતમાં આ રેખાઓ ઉમેરવાની જરૂર છે:

vi undercloud.conf
[DEFAULT]
undercloud_hostname = undercloud.openstack.rnd
local_ip = 192.168.255.1/24
network_gateway = 192.168.255.1
undercloud_public_host = 192.168.255.2
undercloud_admin_host = 192.168.255.3
undercloud_nameservers = 192.168.255.253
generate_service_certificate = false
local_interface = eth0
local_mtu = 1450
network_cidr = 192.168.255.0/24
masquerade = true
masquerade_network = 192.168.255.0/24
dhcp_start = 192.168.255.11
dhcp_end = 192.168.255.50
inspection_iprange = 192.168.255.51,192.168.255.100
scheduler_max_attempts = 10

તેથી, ચાલો સેટિંગ્સમાં જઈએ:

undercloud_hostname — અન્ડરક્લાઉડ સર્વરનું પૂરું નામ, DNS સર્વર પરની એન્ટ્રી સાથે મેળ ખાતું હોવું જોઈએ

local_ip — નેટવર્ક જોગવાઈ તરફ સ્થાનિક અન્ડરક્લાઉડ સરનામું

નેટવર્ક_ગેટવે — એ જ સ્થાનિક સરનામું, જે ઓવરક્લાઉડ નોડ્સના ઇન્સ્ટોલેશન દરમિયાન બહારની દુનિયામાં પ્રવેશ માટેના પ્રવેશદ્વાર તરીકે કાર્ય કરશે, તે સ્થાનિક ip સાથે પણ એકરુપ છે.

undercloud_public_host - બાહ્ય API સરનામું, જોગવાઈ નેટવર્કમાંથી કોઈપણ મફત સરનામું સોંપેલ છે

undercloud_admin_host આંતરિક API સરનામું, જોગવાઈ નેટવર્કમાંથી કોઈપણ મફત સરનામું સોંપેલ છે

undercloud_nameservers - DNS સર્વર

generate_service_certificate - વર્તમાન ઉદાહરણમાં આ વાક્ય ખૂબ જ મહત્વપૂર્ણ છે, કારણ કે જો તમે તેને ખોટા પર સુયોજિત કરશો નહીં તો તમને સ્થાપન દરમ્યાન ભૂલ મળશે, સમસ્યાનું વર્ણન Red Hat બગ ટ્રેકર પર કરવામાં આવ્યું છે.

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

local_mtu - એમટીયુ. અમારી પાસે એક પરીક્ષણ પ્રયોગશાળા હોવાથી અને મારી પાસે OVS સ્વીચ પોર્ટ પર 1500 નું MTU છે, તેથી તેને 1450 પર સેટ કરવું જરૂરી છે જેથી VxLAN માં સમાવિષ્ટ પેકેટો પસાર થઈ શકે.

નેટવર્ક_સીડીઆર - જોગવાઈ નેટવર્ક

માસ્કરેડ - બાહ્ય નેટવર્કને ઍક્સેસ કરવા માટે NAT નો ઉપયોગ કરો

માસ્કરેડ_નેટવર્ક - નેટવર્ક જે નેટેડ હશે

dhcp_start — સરનામાં પૂલનું પ્રારંભિક સરનામું જેમાંથી ઓવરક્લાઉડ જમાવટ દરમિયાન નોડ્સને સરનામાં સોંપવામાં આવશે

dhcp_end — સરનામાં પૂલનું અંતિમ સરનામું જેમાંથી ઓવરક્લાઉડ જમાવટ દરમિયાન નોડ્સને સરનામાં સોંપવામાં આવશે

inspection_iprange - આત્મનિરીક્ષણ માટે જરૂરી સરનામાંનો પૂલ (ઉપરોક્ત પૂલ સાથે ઓવરલેપ ન થવો જોઈએ)

શેડ્યૂલર_મેક્સ_પ્રયાસો — ઓવરક્લાઉડ ઇન્સ્ટોલ કરવાના પ્રયાસોની મહત્તમ સંખ્યા (નોડ્સની સંખ્યા કરતા વધારે અથવા તેના જેટલી હોવી જોઈએ)

ફાઇલનું વર્ણન કર્યા પછી, તમે અન્ડરક્લાઉડને જમાવવા માટે આદેશ આપી શકો છો:

openstack undercloud install

તમારા આયર્નના આધારે પ્રક્રિયામાં 10 થી 30 મિનિટનો સમય લાગે છે. આખરે તમારે આના જેવું આઉટપુટ જોવું જોઈએ:

vi undercloud.conf
2020-08-13 23:13:12,668 INFO: 
#############################################################################
Undercloud install complete.

The file containing this installation's passwords is at
/home/stack/undercloud-passwords.conf.

There is also a stackrc file at /home/stack/stackrc.

These files are needed to interact with the OpenStack services, and should be
secured.

#############################################################################

આ આઉટપુટ કહે છે કે તમે સફળતાપૂર્વક અંડરક્લાઉડ ઇન્સ્ટોલ કર્યું છે અને તમે હવે અન્ડરક્લાઉડની સ્થિતિ તપાસી શકો છો અને ઓવરક્લાઉડ ઇન્સ્ટોલ કરવા આગળ વધી શકો છો.

જો તમે ifconfig આઉટપુટ જોશો, તો તમે જોશો કે નવો બ્રિજ ઈન્ટરફેસ દેખાયો છે

[stack@undercloud ~]$ ifconfig
br-ctlplane: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1450
        inet 192.168.255.1  netmask 255.255.255.0  broadcast 192.168.255.255
        inet6 fe80::5054:ff:fe2c:89e  prefixlen 64  scopeid 0x20<link>
        ether 52:54:00:2c:08:9e  txqueuelen 1000  (Ethernet)
        RX packets 14  bytes 1095 (1.0 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 20  bytes 1292 (1.2 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

ઓવરક્લાઉડ ડિપ્લોયમેન્ટ હવે આ ઇન્ટરફેસ દ્વારા હાથ ધરવામાં આવશે.

નીચેના આઉટપુટમાંથી તમે જોઈ શકો છો કે અમારી પાસે એક નોડ પર બધી સેવાઓ છે:

(undercloud) [stack@undercloud ~]$ openstack host list
+--------------------------+-----------+----------+
| Host Name                | Service   | Zone     |
+--------------------------+-----------+----------+
| undercloud.openstack.rnd | conductor | internal |
| undercloud.openstack.rnd | scheduler | internal |
| undercloud.openstack.rnd | compute   | nova     |
+--------------------------+-----------+----------+

નીચે અન્ડરક્લાઉડ નેટવર્ક ભાગનું રૂપરેખાંકન છે:

(undercloud) [stack@undercloud ~]$ python -m json.tool /etc/os-net-config/config.json 
{
    "network_config": [
        {
            "addresses": [
                {
                    "ip_netmask": "192.168.255.1/24"
                }
            ],
            "members": [
                {
                    "dns_servers": [
                        "192.168.255.253"
                    ],
                    "mtu": 1450,
                    "name": "eth0",
                    "primary": "true",
                    "type": "interface"
                }
            ],
            "mtu": 1450,
            "name": "br-ctlplane",
            "ovs_extra": [
                "br-set-external-id br-ctlplane bridge-id br-ctlplane"
            ],
            "routes": [],
            "type": "ovs_bridge"
        }
    ]
}
(undercloud) [stack@undercloud ~]$

ઓવરક્લાઉડ ઇન્સ્ટોલેશન

આ ક્ષણે અમારી પાસે ફક્ત અન્ડરક્લાઉડ છે, અને અમારી પાસે પર્યાપ્ત નોડ્સ નથી કે જેમાંથી ઓવરક્લાઉડ એસેમ્બલ કરવામાં આવશે. તેથી, સૌ પ્રથમ, ચાલો આપણે જોઈતા વર્ચ્યુઅલ મશીનોનો ઉપયોગ કરીએ. જમાવટ દરમિયાન, અંડરક્લાઉડ પોતે ઓવરક્લાઉડ મશીન પર OS અને જરૂરી સોફ્ટવેર ઇન્સ્ટોલ કરશે - એટલે કે, આપણે મશીનને સંપૂર્ણપણે જમાવવાની જરૂર નથી, પરંતુ તેના માટે માત્ર એક ડિસ્ક (અથવા ડિસ્ક) બનાવો અને તેના પરિમાણો નક્કી કરો - એટલે કે. , વાસ્તવમાં, અમને તેના પર OS ઇન્સ્ટોલ કર્યા વિના એકદમ સર્વર મળે છે.

ચાલો આપણા વર્ચ્યુઅલ મશીનોની ડિસ્ક સાથે ફોલ્ડર પર જઈએ અને જરૂરી કદની ડિસ્ક બનાવીએ:

cd /var/lib/libvirt/images/
qemu-img create -f qcow2 -o preallocation=metadata control-1.qcow2 60G
qemu-img create -f qcow2 -o preallocation=metadata compute-1.qcow2 60G
qemu-img create -f qcow2 -o preallocation=metadata compute-2.qcow2 60G
qemu-img create -f qcow2 -o preallocation=metadata storage-1.qcow2 160G
qemu-img create -f qcow2 -o preallocation=metadata storage-2.qcow2 160G

અમે રૂટ તરીકે કામ કરી રહ્યા હોવાથી, અમારે આ ડિસ્કના માલિકને બદલવાની જરૂર છે જેથી અધિકારો સાથે સમસ્યા ન આવે:

[root@hp-gen9 images]# ls -lh
total 5.8G
drwxr-xr-x. 2 qemu qemu 4.0K Aug 13 16:15 backups
-rw-r--r--. 1 root root  61G Aug 14 03:07 compute-1.qcow2
-rw-r--r--. 1 root root  61G Aug 14 03:07 compute-2.qcow2
-rw-r--r--. 1 root root  61G Aug 14 03:07 control-1.qcow2
-rw-------. 1 qemu qemu  41G Aug 14 03:03 dns-server.qcow2
-rw-r--r--. 1 root root 161G Aug 14 03:07 storage-1.qcow2
-rw-r--r--. 1 root root 161G Aug 14 03:07 storage-2.qcow2
-rw-------. 1 qemu qemu  41G Aug 14 03:07 undercloud.qcow2
[root@hp-gen9 images]# 
[root@hp-gen9 images]# 
[root@hp-gen9 images]# chown qemu:qemu /var/lib/libvirt/images/*qcow2
[root@hp-gen9 images]# ls -lh
total 5.8G
drwxr-xr-x. 2 qemu qemu 4.0K Aug 13 16:15 backups
-rw-r--r--. 1 qemu qemu  61G Aug 14 03:07 compute-1.qcow2
-rw-r--r--. 1 qemu qemu  61G Aug 14 03:07 compute-2.qcow2
-rw-r--r--. 1 qemu qemu  61G Aug 14 03:07 control-1.qcow2
-rw-------. 1 qemu qemu  41G Aug 14 03:03 dns-server.qcow2
-rw-r--r--. 1 qemu qemu 161G Aug 14 03:07 storage-1.qcow2
-rw-r--r--. 1 qemu qemu 161G Aug 14 03:07 storage-2.qcow2
-rw-------. 1 qemu qemu  41G Aug 14 03:08 undercloud.qcow2
[root@hp-gen9 images]# 

નોંધ: જો તમે તેનો અભ્યાસ કરવા માટે ceph ઇન્સ્ટોલ કરવાની યોજના નથી બનાવતા, તો આદેશો ઓછામાં ઓછા બે ડિસ્ક સાથે ઓછામાં ઓછા 3 નોડ્સ બનાવતા નથી, પરંતુ નમૂનામાં સૂચવે છે કે વર્ચ્યુઅલ ડિસ્ક vda, vdb, વગેરેનો ઉપયોગ કરવામાં આવશે.

સરસ, હવે આપણે આ તમામ મશીનોને વ્યાખ્યાયિત કરવાની જરૂર છે:

virt-install --name control-1 --ram 32768 --vcpus 8 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/control-1.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc  --network network:ovs-network-1,model=virtio,portgroup=access-100 --network network:ovs-network-1,model=virtio,portgroup=trunk-1 --dry-run --print-xml > /tmp/control-1.xml  

virt-install --name storage-1 --ram 16384 --vcpus 4 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/storage-1.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc  --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > /tmp/storage-1.xml  

virt-install --name storage-2 --ram 16384 --vcpus 4 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/storage-2.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc  --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > /tmp/storage-2.xml  

virt-install --name compute-1 --ram 32768 --vcpus 12 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/compute-1.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc  --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > /tmp/compute-1.xml  

virt-install --name compute-2 --ram 32768 --vcpus 12 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/compute-2.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc  --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > /tmp/compute-2.xml 

અંતે એક આદેશ છે -print-xml > /tmp/storage-1.xml, જે /tmp/ ફોલ્ડરમાં દરેક મશીનના વર્ણન સાથે xml ફાઇલ બનાવે છે; જો તમે તેને ઉમેરશો નહીં, તો તમે વર્ચ્યુઅલ મશીનો ઓળખવામાં સક્ષમ.

હવે આપણે આ તમામ મશીનોને virsh માં વ્યાખ્યાયિત કરવાની જરૂર છે:

virsh define --file /tmp/control-1.xml
virsh define --file /tmp/compute-1.xml
virsh define --file /tmp/compute-2.xml
virsh define --file /tmp/storage-1.xml
virsh define --file /tmp/storage-2.xml

[root@hp-gen9 ~]# virsh list --all
 Id    Name                           State
----------------------------------------------------
 6     dns-server                     running
 64    undercloud                     running
 -     compute-1                      shut off
 -     compute-2                      shut off
 -     control-1                      shut off
 -     storage-1                      shut off
 -     storage-2                      shut off

[root@hp-gen9 ~]#

હવે એક નાનો નુન્સ - ટ્રિપલઓ ઇન્સ્ટોલેશન અને આત્મનિરીક્ષણ દરમિયાન સર્વર્સનું સંચાલન કરવા માટે IPMI નો ઉપયોગ કરે છે.

આત્મનિરીક્ષણ એ નોડ્સની વધુ જોગવાઈ માટે જરૂરી પરિમાણો મેળવવા માટે હાર્ડવેરનું નિરીક્ષણ કરવાની પ્રક્રિયા છે. બેર મેટલ સર્વર સાથે કામ કરવા માટે રચાયેલ સેવા, આયર્નિકનો ઉપયોગ કરીને આત્મનિરીક્ષણ હાથ ધરવામાં આવે છે.

પરંતુ અહીં સમસ્યા છે - જ્યારે હાર્ડવેર IPMI સર્વર્સ પાસે એક અલગ પોર્ટ છે (અથવા શેર કરેલ પોર્ટ, પરંતુ આ મહત્વપૂર્ણ નથી), તો વર્ચ્યુઅલ મશીનોમાં આવા પોર્ટ નથી. અહીં vbmc નામની ક્રચ અમારી મદદ માટે આવે છે - એક ઉપયોગિતા જે તમને IPMI પોર્ટનું અનુકરણ કરવાની મંજૂરી આપે છે. ખાસ કરીને જેઓ ESXI હાઈપરવાઈઝર પર આવી પ્રયોગશાળા ગોઠવવા માગે છે તેમના માટે આ સૂક્ષ્મતા ધ્યાન આપવા યોગ્ય છે - પ્રમાણિકતા કહું તો, મને ખબર નથી કે તેમાં vbmc નું એનાલોગ છે કે કેમ, તેથી બધું ગોઠવતા પહેલા આ મુદ્દા વિશે વિચારવું યોગ્ય છે. .

vbmc ઇન્સ્ટોલ કરો:

yum install yum install python2-virtualbmc

જો તમારું OS પેકેજ શોધી શકતું નથી, તો પછી રીપોઝીટરી ઉમેરો:

yum install -y https://www.rdoproject.org/repos/rdo-release.rpm

હવે અમે ઉપયોગિતા સુયોજિત કરીએ છીએ. અહીં બધું શરમજનક બિંદુ સુધી મામૂલી છે. હવે તે તાર્કિક છે કે vbmc સૂચિમાં કોઈ સર્વર નથી

[root@hp-gen9 ~]# vbmc list

[root@hp-gen9 ~]# 

તેમના દેખાવા માટે, તેઓને મેન્યુઅલી આ રીતે જાહેર કરવું આવશ્યક છે:

[root@hp-gen9 ~]# vbmc add control-1 --port 7001 --username admin --password admin
[root@hp-gen9 ~]# vbmc add storage-1 --port 7002 --username admin --password admin
[root@hp-gen9 ~]# vbmc add storage-2 --port 7003 --username admin --password admin
[root@hp-gen9 ~]# vbmc add compute-1 --port 7004 --username admin --password admin
[root@hp-gen9 ~]# vbmc add compute-2 --port 7005 --username admin --password admin
[root@hp-gen9 ~]#
[root@hp-gen9 ~]# vbmc list
+-------------+--------+---------+------+
| Domain name | Status | Address | Port |
+-------------+--------+---------+------+
| compute-1   | down   | ::      | 7004 |
| compute-2   | down   | ::      | 7005 |
| control-1   | down   | ::      | 7001 |
| storage-1   | down   | ::      | 7002 |
| storage-2   | down   | ::      | 7003 |
+-------------+--------+---------+------+
[root@hp-gen9 ~]#

મને લાગે છે કે આદેશ વાક્યરચના સમજૂતી વિના સ્પષ્ટ છે. જો કે, અત્યારે અમારા તમામ સત્રો ડાઉન સ્ટેટસમાં છે. તેમને યુપી સ્ટેટસ પર જવા માટે, તમારે તેમને સક્ષમ કરવાની જરૂર છે:

[root@hp-gen9 ~]# vbmc start control-1
2020-08-14 03:15:57,826.826 13149 INFO VirtualBMC [-] Started vBMC instance for domain control-1
[root@hp-gen9 ~]# vbmc start storage-1 
2020-08-14 03:15:58,316.316 13149 INFO VirtualBMC [-] Started vBMC instance for domain storage-1
[root@hp-gen9 ~]# vbmc start storage-2
2020-08-14 03:15:58,851.851 13149 INFO VirtualBMC [-] Started vBMC instance for domain storage-2
[root@hp-gen9 ~]# vbmc start compute-1
2020-08-14 03:15:59,307.307 13149 INFO VirtualBMC [-] Started vBMC instance for domain compute-1
[root@hp-gen9 ~]# vbmc start compute-2
2020-08-14 03:15:59,712.712 13149 INFO VirtualBMC [-] Started vBMC instance for domain compute-2
[root@hp-gen9 ~]# 
[root@hp-gen9 ~]# 
[root@hp-gen9 ~]# vbmc list
+-------------+---------+---------+------+
| Domain name | Status  | Address | Port |
+-------------+---------+---------+------+
| compute-1   | running | ::      | 7004 |
| compute-2   | running | ::      | 7005 |
| control-1   | running | ::      | 7001 |
| storage-1   | running | ::      | 7002 |
| storage-2   | running | ::      | 7003 |
+-------------+---------+---------+------+
[root@hp-gen9 ~]#

અને અંતિમ સ્પર્શ - તમારે ફાયરવોલ નિયમો સુધારવાની જરૂર છે (અથવા તેને સંપૂર્ણપણે અક્ષમ કરો):

firewall-cmd --zone=public --add-port=7001/udp --permanent
firewall-cmd --zone=public --add-port=7002/udp --permanent
firewall-cmd --zone=public --add-port=7003/udp --permanent
firewall-cmd --zone=public --add-port=7004/udp --permanent
firewall-cmd --zone=public --add-port=7005/udp --permanent
firewall-cmd --reload

હવે ચાલો અન્ડરક્લાઉડ પર જઈએ અને તપાસીએ કે બધું કામ કરી રહ્યું છે. હોસ્ટ મશીનનું સરનામું 192.168.255.200 છે, અંડરક્લાઉડ પર અમે જમાવટ માટેની તૈયારી દરમિયાન જરૂરી ipmitool પેકેજ ઉમેર્યું છે:

[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power status          
Chassis Power is off
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power on
Chassis Power Control: Up/On
[stack@undercloud ~]$ 

[root@hp-gen9 ~]# virsh list 
 Id    Name                           State
----------------------------------------------------
 6     dns-server                     running
 64    undercloud                     running
 65    control-1                      running

જેમ તમે જોઈ શકો છો, અમે vbmc દ્વારા કંટ્રોલ નોડ સફળતાપૂર્વક લોન્ચ કર્યું છે. હવે ચાલો તેને બંધ કરીએ અને આગળ વધીએ:

[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power off
Chassis Power Control: Down/Off
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power status
Chassis Power is off
[stack@undercloud ~]$ 

[root@hp-gen9 ~]# virsh list --all
 Id    Name                           State
----------------------------------------------------
 6     dns-server                     running
 64    undercloud                     running
 -     compute-1                      shut off
 -     compute-2                      shut off
 -     control-1                      shut off
 -     storage-1                      shut off
 -     storage-2                      shut off

[root@hp-gen9 ~]#

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

[root@hp-gen9 ~]# virsh domiflist --domain control-1 
Interface  Type       Source     Model       MAC
-------------------------------------------------------
-          network    ovs-network-1 virtio      52:54:00:20:a2:2f
-          network    ovs-network-1 virtio      52:54:00:3f:87:9f

[root@hp-gen9 ~]# virsh domiflist --domain compute-1
Interface  Type       Source     Model       MAC
-------------------------------------------------------
-          network    ovs-network-1 virtio      52:54:00:98:e9:d6

[root@hp-gen9 ~]# virsh domiflist --domain compute-2
Interface  Type       Source     Model       MAC
-------------------------------------------------------
-          network    ovs-network-1 virtio      52:54:00:6a:ea:be

[root@hp-gen9 ~]# virsh domiflist --domain storage-1
Interface  Type       Source     Model       MAC
-------------------------------------------------------
-          network    ovs-network-1 virtio      52:54:00:79:0b:cb

[root@hp-gen9 ~]# virsh domiflist --domain storage-2
Interface  Type       Source     Model       MAC
-------------------------------------------------------
-          network    ovs-network-1 virtio      52:54:00:a7:fe:27

નોંધ: કંટ્રોલ નોડમાં બે ઇન્ટરફેસ છે, પરંતુ આ કિસ્સામાં આ મહત્વપૂર્ણ નથી, આ ઇન્સ્ટોલેશનમાં અમારા માટે એક પૂરતું હશે.

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

{
    "nodes":[
        {
            "mac":[
                "52:54:00:20:a2:2f"
            ],
            "cpu":"8",
            "memory":"32768",
            "disk":"60",
            "arch":"x86_64",
            "name":"control-1",
            "pm_type":"pxe_ipmitool",
            "pm_user":"admin",
            "pm_password":"admin",
            "pm_addr":"192.168.255.200",
            "pm_port":"7001"
        },
        {
            "mac":[
                "52:54:00:79:0b:cb"
            ],
            "cpu":"4",
            "memory":"16384",
            "disk":"160",
            "arch":"x86_64",
            "name":"storage-1",
            "pm_type":"pxe_ipmitool",
            "pm_user":"admin",
            "pm_password":"admin",
            "pm_addr":"192.168.255.200",
            "pm_port":"7002"
        },
        {
            "mac":[
                "52:54:00:a7:fe:27"
            ],
            "cpu":"4",
            "memory":"16384",
            "disk":"160",
            "arch":"x86_64",
            "name":"storage-2",
            "pm_type":"pxe_ipmitool",
            "pm_user":"admin",
            "pm_password":"admin",
            "pm_addr":"192.168.255.200",
            "pm_port":"7003"
        },
        {
            "mac":[
                "52:54:00:98:e9:d6"
            ],
            "cpu":"12",
            "memory":"32768",
            "disk":"60",
            "arch":"x86_64",
            "name":"compute-1",
            "pm_type":"pxe_ipmitool",
            "pm_user":"admin",
            "pm_password":"admin",
            "pm_addr":"192.168.255.200",
            "pm_port":"7004"
        },
        {
            "mac":[
                "52:54:00:6a:ea:be"
            ],
            "cpu":"12",
            "memory":"32768",
            "disk":"60",
            "arch":"x86_64",
            "name":"compute-2",
            "pm_type":"pxe_ipmitool",
            "pm_user":"admin",
            "pm_password":"admin",
            "pm_addr":"192.168.255.200",
            "pm_port":"7005"
        }
    ]
}

હવે આપણે વ્યંગાત્મક માટે છબીઓ તૈયાર કરવાની જરૂર છે. આ કરવા માટે, તેમને wget દ્વારા ડાઉનલોડ કરો અને ઇન્સ્ટોલ કરો:

(undercloud) [stack@undercloud ~]$ sudo wget https://images.rdoproject.org/queens/delorean/current-tripleo-rdo/overcloud-full.tar --no-check-certificate
(undercloud) [stack@undercloud ~]$ sudo wget https://images.rdoproject.org/queens/delorean/current-tripleo-rdo/ironic-python-agent.tar --no-check-certificate
(undercloud) [stack@undercloud ~]$ ls -lh
total 1.9G
-rw-r--r--. 1 stack stack 447M Aug 14 10:26 ironic-python-agent.tar
-rw-r--r--. 1 stack stack 1.5G Aug 14 10:26 overcloud-full.tar
-rw-------. 1 stack stack  916 Aug 13 23:10 stackrc
-rw-r--r--. 1 stack stack  15K Aug 13 22:50 undercloud.conf
-rw-------. 1 stack stack 2.0K Aug 13 22:50 undercloud-passwords.conf
(undercloud) [stack@undercloud ~]$ mkdir images/
(undercloud) [stack@undercloud ~]$ tar -xpvf ironic-python-agent.tar -C ~/images/
ironic-python-agent.initramfs
ironic-python-agent.kernel
(undercloud) [stack@undercloud ~]$ tar -xpvf overcloud-full.tar -C ~/images/                       
overcloud-full.qcow2
overcloud-full.initrd
overcloud-full.vmlinuz
(undercloud) [stack@undercloud ~]$ 
(undercloud) [stack@undercloud ~]$ ls -lh images/
total 1.9G
-rw-rw-r--. 1 stack stack 441M Aug 12 17:24 ironic-python-agent.initramfs
-rwxr-xr-x. 1 stack stack 6.5M Aug 12 17:24 ironic-python-agent.kernel
-rw-r--r--. 1 stack stack  53M Aug 12 17:14 overcloud-full.initrd
-rw-r--r--. 1 stack stack 1.4G Aug 12 17:18 overcloud-full.qcow2
-rwxr-xr-x. 1 stack stack 6.5M Aug 12 17:14 overcloud-full.vmlinuz
(undercloud) [stack@undercloud ~]$

અન્ડરક્લાઉડ પર છબીઓ અપલોડ કરવી:

(undercloud) [stack@undercloud ~]$ openstack overcloud image upload --image-path ~/images/
Image "overcloud-full-vmlinuz" was uploaded.
+--------------------------------------+------------------------+-------------+---------+--------+
|                  ID                  |          Name          | Disk Format |   Size  | Status |
+--------------------------------------+------------------------+-------------+---------+--------+
| c2553770-3e0f-4750-b46b-138855b5c385 | overcloud-full-vmlinuz |     aki     | 6761064 | active |
+--------------------------------------+------------------------+-------------+---------+--------+
Image "overcloud-full-initrd" was uploaded.
+--------------------------------------+-----------------------+-------------+----------+--------+
|                  ID                  |          Name         | Disk Format |   Size   | Status |
+--------------------------------------+-----------------------+-------------+----------+--------+
| 949984e0-4932-4e71-af43-d67a38c3dc89 | overcloud-full-initrd |     ari     | 55183045 | active |
+--------------------------------------+-----------------------+-------------+----------+--------+
Image "overcloud-full" was uploaded.
+--------------------------------------+----------------+-------------+------------+--------+
|                  ID                  |      Name      | Disk Format |    Size    | Status |
+--------------------------------------+----------------+-------------+------------+--------+
| a2f2096d-c9d7-429a-b866-c7543c02a380 | overcloud-full |    qcow2    | 1487475712 | active |
+--------------------------------------+----------------+-------------+------------+--------+
Image "bm-deploy-kernel" was uploaded.
+--------------------------------------+------------------+-------------+---------+--------+
|                  ID                  |       Name       | Disk Format |   Size  | Status |
+--------------------------------------+------------------+-------------+---------+--------+
| e413aa78-e38f-404c-bbaf-93e582a8e67f | bm-deploy-kernel |     aki     | 6761064 | active |
+--------------------------------------+------------------+-------------+---------+--------+
Image "bm-deploy-ramdisk" was uploaded.
+--------------------------------------+-------------------+-------------+-----------+--------+
|                  ID                  |        Name       | Disk Format |    Size   | Status |
+--------------------------------------+-------------------+-------------+-----------+--------+
| 5cf3aba4-0e50-45d3-929f-27f025dd6ce3 | bm-deploy-ramdisk |     ari     | 461759376 | active |
+--------------------------------------+-------------------+-------------+-----------+--------+
(undercloud) [stack@undercloud ~]$

તપાસી રહ્યું છે કે બધી છબીઓ લોડ થઈ છે

(undercloud) [stack@undercloud ~]$  openstack image list
+--------------------------------------+------------------------+--------+
| ID                                   | Name                   | Status |
+--------------------------------------+------------------------+--------+
| e413aa78-e38f-404c-bbaf-93e582a8e67f | bm-deploy-kernel       | active |
| 5cf3aba4-0e50-45d3-929f-27f025dd6ce3 | bm-deploy-ramdisk      | active |
| a2f2096d-c9d7-429a-b866-c7543c02a380 | overcloud-full         | active |
| 949984e0-4932-4e71-af43-d67a38c3dc89 | overcloud-full-initrd  | active |
| c2553770-3e0f-4750-b46b-138855b5c385 | overcloud-full-vmlinuz | active |
+--------------------------------------+------------------------+--------+
(undercloud) [stack@undercloud ~]$

એક વધુ વસ્તુ - તમારે DNS સર્વર ઉમેરવાની જરૂર છે:

(undercloud) [stack@undercloud ~]$ openstack subnet list
+--------------------------------------+-----------------+--------------------------------------+------------------+
| ID                                   | Name            | Network                              | Subnet           |
+--------------------------------------+-----------------+--------------------------------------+------------------+
| f45dea46-4066-42aa-a3c4-6f84b8120cab | ctlplane-subnet | 6ca013dc-41c2-42d8-9d69-542afad53392 | 192.168.255.0/24 |
+--------------------------------------+-----------------+--------------------------------------+------------------+
(undercloud) [stack@undercloud ~]$ openstack subnet show f45dea46-4066-42aa-a3c4-6f84b8120cab
+-------------------+-----------------------------------------------------------+
| Field             | Value                                                     |
+-------------------+-----------------------------------------------------------+
| allocation_pools  | 192.168.255.11-192.168.255.50                             |
| cidr              | 192.168.255.0/24                                          |
| created_at        | 2020-08-13T20:10:37Z                                      |
| description       |                                                           |
| dns_nameservers   |                                                           |
| enable_dhcp       | True                                                      |
| gateway_ip        | 192.168.255.1                                             |
| host_routes       | destination='169.254.169.254/32', gateway='192.168.255.1' |
| id                | f45dea46-4066-42aa-a3c4-6f84b8120cab                      |
| ip_version        | 4                                                         |
| ipv6_address_mode | None                                                      |
| ipv6_ra_mode      | None                                                      |
| name              | ctlplane-subnet                                           |
| network_id        | 6ca013dc-41c2-42d8-9d69-542afad53392                      |
| prefix_length     | None                                                      |
| project_id        | a844ccfcdb2745b198dde3e1b28c40a3                          |
| revision_number   | 0                                                         |
| segment_id        | None                                                      |
| service_types     |                                                           |
| subnetpool_id     | None                                                      |
| tags              |                                                           |
| updated_at        | 2020-08-13T20:10:37Z                                      |
+-------------------+-----------------------------------------------------------+
(undercloud) [stack@undercloud ~]$ 
(undercloud) [stack@undercloud ~]$ neutron subnet-update f45dea46-4066-42aa-a3c4-6f84b8120cab --dns-nameserver 192.168.255.253                                    
neutron CLI is deprecated and will be removed in the future. Use openstack CLI instead.
Updated subnet: f45dea46-4066-42aa-a3c4-6f84b8120cab
(undercloud) [stack@undercloud ~]$

હવે આપણે આત્મનિરીક્ષણ માટે આદેશ આપી શકીએ છીએ:

(undercloud) [stack@undercloud ~]$ openstack overcloud node import --introspect --provide inspection.json 
Started Mistral Workflow tripleo.baremetal.v1.register_or_update. Execution ID: d57456a3-d8ed-479c-9a90-dff7c752d0ec
Waiting for messages on queue 'tripleo' with no timeout.


5 node(s) successfully moved to the "manageable" state.
Successfully registered node UUID b4b2cf4a-b7ca-4095-af13-cc83be21c4f5
Successfully registered node UUID b89a72a3-6bb7-429a-93bc-48393d225838
Successfully registered node UUID 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e
Successfully registered node UUID bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8
Successfully registered node UUID 766ab623-464c-423d-a529-d9afb69d1167
Waiting for introspection to finish...
Started Mistral Workflow tripleo.baremetal.v1.introspect. Execution ID: 6b4d08ae-94c3-4a10-ab63-7634ec198a79
Waiting for messages on queue 'tripleo' with no timeout.
Introspection of node b89a72a3-6bb7-429a-93bc-48393d225838 completed. Status:SUCCESS. Errors:None
Introspection of node 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e completed. Status:SUCCESS. Errors:None
Introspection of node bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 completed. Status:SUCCESS. Errors:None
Introspection of node 766ab623-464c-423d-a529-d9afb69d1167 completed. Status:SUCCESS. Errors:None
Introspection of node b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 completed. Status:SUCCESS. Errors:None
Successfully introspected 5 node(s).
Started Mistral Workflow tripleo.baremetal.v1.provide. Execution ID: f5594736-edcf-4927-a8a0-2a7bf806a59a
Waiting for messages on queue 'tripleo' with no timeout.
5 node(s) successfully moved to the "available" state.
(undercloud) [stack@undercloud ~]$

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

(undercloud) [stack@undercloud ~]$ openstack baremetal node list
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
| UUID                                 | Name      | Instance UUID | Power State | Provisioning State | Maintenance |
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | None          | power off   | available          | False       |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | None          | power off   | available          | False       |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | None          | power off   | available          | False       |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | None          | power off   | available          | False       |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | None          | power off   | available          | False       |
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
(undercloud) [stack@undercloud ~]$ 

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

આગળ, આપણે તે સૂચવવાની જરૂર છે કે કયું નોડ કયું કાર્ય કરશે - એટલે કે, તે પ્રોફાઇલ સૂચવો કે જેની સાથે નોડ જમાવશે:

(undercloud) [stack@undercloud ~]$ openstack overcloud profiles list
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| Node UUID                            | Node Name | Provision State | Current Profile | Possible Profiles |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | available       | None            |                   |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | available       | None            |                   |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | available       | None            |                   |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | available       | None            |                   |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | available       | None            |                   |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
(undercloud) [stack@undercloud ~]$ openstack flavor list
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
| ID                                   | Name          |  RAM | Disk | Ephemeral | VCPUs | Is Public |
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
| 168af640-7f40-42c7-91b2-989abc5c5d8f | swift-storage | 4096 |   40 |         0 |     1 | True      |
| 52148d1b-492e-48b4-b5fc-772849dd1b78 | baremetal     | 4096 |   40 |         0 |     1 | True      |
| 56e66542-ae60-416d-863e-0cb192d01b09 | control       | 4096 |   40 |         0 |     1 | True      |
| af6796e1-d0c4-4bfe-898c-532be194f7ac | block-storage | 4096 |   40 |         0 |     1 | True      |
| e4d50fdd-0034-446b-b72c-9da19b16c2df | compute       | 4096 |   40 |         0 |     1 | True      |
| fc2e3acf-7fca-4901-9eee-4a4d6ef0265d | ceph-storage  | 4096 |   40 |         0 |     1 | True      |
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
(undercloud) [stack@undercloud ~]$

દરેક નોડ માટે પ્રોફાઇલનો ઉલ્લેખ કરો:

openstack baremetal node set --property capabilities='profile:control,boot_option:local' b4b2cf4a-b7ca-4095-af13-cc83be21c4f5
openstack baremetal node set --property capabilities='profile:ceph-storage,boot_option:local' b89a72a3-6bb7-429a-93bc-48393d225838
openstack baremetal node set --property capabilities='profile:ceph-storage,boot_option:local' 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e
openstack baremetal node set --property capabilities='profile:compute,boot_option:local' bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8
openstack baremetal node set --property capabilities='profile:compute,boot_option:local' 766ab623-464c-423d-a529-d9afb69d1167

ચાલો તપાસીએ કે અમે બધું બરાબર કર્યું છે:

(undercloud) [stack@undercloud ~]$ openstack overcloud profiles list
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| Node UUID                            | Node Name | Provision State | Current Profile | Possible Profiles |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | available       | control         |                   |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | available       | ceph-storage    |                   |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | available       | ceph-storage    |                   |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | available       | compute         |                   |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | available       | compute         |                   |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
(undercloud) [stack@undercloud ~]$

જો બધું બરાબર છે, તો અમે ઓવરક્લાઉડને જમાવવા માટે આદેશ આપીએ છીએ:

openstack overcloud deploy --templates --control-scale 1 --compute-scale 2  --ceph-storage-scale 2 --control-flavor control --compute-flavor compute  --ceph-storage-flavor ceph-storage --libvirt-type qemu

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

નોંધ: --libvirt-type qemu ચલ આ કિસ્સામાં જરૂરી છે, કારણ કે આપણે નેસ્ટેડ વર્ચ્યુઅલાઈઝેશનનો ઉપયોગ કરીશું. નહિંતર, તમે વર્ચ્યુઅલ મશીનો ચલાવવા માટે સમર્થ હશો નહીં.

હવે તમારી પાસે લગભગ એક કલાક છે, અથવા કદાચ વધુ (હાર્ડવેરની ક્ષમતાઓ પર આધાર રાખીને) અને તમે માત્ર આશા રાખી શકો છો કે આ સમય પછી તમે નીચેનો સંદેશ જોશો:

2020-08-14 08:39:21Z [overcloud]: CREATE_COMPLETE  Stack CREATE completed successfully

 Stack overcloud CREATE_COMPLETE 

Host 192.168.255.21 not found in /home/stack/.ssh/known_hosts
Started Mistral Workflow tripleo.deployment.v1.get_horizon_url. Execution ID: fcb996cd-6a19-482b-b755-2ca0c08069a9
Overcloud Endpoint: http://192.168.255.21:5000/
Overcloud Horizon Dashboard URL: http://192.168.255.21:80/dashboard
Overcloud rc file: /home/stack/overcloudrc
Overcloud Deployed
(undercloud) [stack@undercloud ~]$

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

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

(undercloud) [stack@undercloud ~]$ openstack server list
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
| ID                                   | Name                    | Status | Networks                | Image          | Flavor       |
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
| fd7d36f4-ce87-4b9a-93b0-add2957792de | overcloud-controller-0  | ACTIVE | ctlplane=192.168.255.15 | overcloud-full | control      |
| edc77778-8972-475e-a541-ff40eb944197 | overcloud-novacompute-1 | ACTIVE | ctlplane=192.168.255.26 | overcloud-full | compute      |
| 5448ce01-f05f-47ca-950a-ced14892c0d4 | overcloud-cephstorage-1 | ACTIVE | ctlplane=192.168.255.34 | overcloud-full | ceph-storage |
| ce6d862f-4bdf-4ba3-b711-7217915364d7 | overcloud-novacompute-0 | ACTIVE | ctlplane=192.168.255.19 | overcloud-full | compute      |
| e4507bd5-6f96-4b12-9cc0-6924709da59e | overcloud-cephstorage-0 | ACTIVE | ctlplane=192.168.255.44 | overcloud-full | ceph-storage |
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
(undercloud) [stack@undercloud ~]$ 

(undercloud) [stack@undercloud ~]$ source overcloudrc 
(overcloud) [stack@undercloud ~]$ 
(overcloud) [stack@undercloud ~]$ openstack project list
+----------------------------------+---------+
| ID                               | Name    |
+----------------------------------+---------+
| 4eed7d0f06544625857d51cd77c5bd4c | admin   |
| ee1c68758bde41eaa9912c81dc67dad8 | service |
+----------------------------------+---------+
(overcloud) [stack@undercloud ~]$ 
(overcloud) [stack@undercloud ~]$ 
(overcloud) [stack@undercloud ~]$ openstack network agent list  
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| ID                                   | Agent Type         | Host                                | Availability Zone | Alive | State | Binary                    |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| 10495de9-ba4b-41fe-b30a-b90ec3f8728b | Open vSwitch agent | overcloud-novacompute-1.localdomain | None              | :-)   | UP    | neutron-openvswitch-agent |
| 1515ad4a-5972-46c3-af5f-e5446dff7ac7 | L3 agent           | overcloud-controller-0.localdomain  | nova              | :-)   | UP    | neutron-l3-agent          |
| 322e62ca-1e5a-479e-9a96-4f26d09abdd7 | DHCP agent         | overcloud-controller-0.localdomain  | nova              | :-)   | UP    | neutron-dhcp-agent        |
| 9c1de2f9-bac5-400e-998d-4360f04fc533 | Open vSwitch agent | overcloud-novacompute-0.localdomain | None              | :-)   | UP    | neutron-openvswitch-agent |
| d99c5657-851e-4d3c-bef6-f1e3bb1acfb0 | Open vSwitch agent | overcloud-controller-0.localdomain  | None              | :-)   | UP    | neutron-openvswitch-agent |
| ff85fae6-5543-45fb-a301-19c57b62d836 | Metadata agent     | overcloud-controller-0.localdomain  | None              | :-)   | UP    | neutron-metadata-agent    |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
(overcloud) [stack@undercloud ~]$

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

(undercloud) [stack@undercloud ~]$ ssh [email protected]         
Last login: Fri Aug 14 09:47:40 2020 from 192.168.255.1
[heat-admin@overcloud-controller-0 ~]$ 
[heat-admin@overcloud-controller-0 ~]$ 
[heat-admin@overcloud-controller-0 ~]$ sudo ip route add 10.169.0.0/16 via 192.168.255.254

સારું, હવે તમે ક્ષિતિજમાં જઈ શકો છો. બધી માહિતી - સરનામાં, લોગિન અને પાસવર્ડ - ફાઇલ /home/stack/overcloudrc માં છે. અંતિમ રેખાકૃતિ આના જેવો દેખાય છે:

માર્ગ દ્વારા, અમારા ઇન્સ્ટોલેશનમાં, મશીન સરનામાં DHCP દ્વારા જારી કરવામાં આવ્યા હતા અને, જેમ તમે જોઈ શકો છો, તે "રેન્ડમ" દ્વારા જારી કરવામાં આવે છે. જો તમને તેની જરૂર હોય તો, જમાવટ દરમિયાન કયા મશીન સાથે કયું સરનામું જોડવું જોઈએ તે તમે નમૂનામાં સખત રીતે વ્યાખ્યાયિત કરી શકો છો.

વર્ચ્યુઅલ મશીનો વચ્ચે ટ્રાફિક કેવી રીતે વહે છે?

આ લેખમાં આપણે ટ્રાફિક પસાર કરવાના ત્રણ વિકલ્પો જોઈશું

• એક L2 નેટવર્ક પર એક હાઇપરવાઇઝર પર બે મશીનો
• સમાન L2 નેટવર્ક પર વિવિધ હાઇપરવાઇઝર પર બે મશીનો
• વિવિધ નેટવર્ક પર બે મશીનો (ક્રોસ-નેટવર્ક રૂટીંગ)

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

તપાસવા માટે, ચાલો નીચેનો આકૃતિ એકસાથે મૂકીએ:

અમે 4 વર્ચ્યુઅલ મશીન બનાવ્યાં છે - 3 એક L2 નેટવર્ક પર - નેટ-1, અને 1 વધુ નેટ-2 નેટવર્ક પર

(overcloud) [stack@undercloud ~]$ nova list --tenant 5e18ce8ec9594e00b155485f19895e6c             
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
| ID                                   | Name | Tenant ID                        | Status | Task State | Power State | Networks        |
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
| f53b37b5-2204-46cc-aef0-dba84bf970c0 | vm-1 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | -          | Running     | net-1=10.0.1.85 |
| fc8b6722-0231-49b0-b2fa-041115bef34a | vm-2 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | -          | Running     | net-1=10.0.1.88 |
| 3cd74455-b9b7-467a-abe3-bd6ff765c83c | vm-3 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | -          | Running     | net-1=10.0.1.90 |
| 7e836338-6772-46b0-9950-f7f06dbe91a8 | vm-4 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | -          | Running     | net-2=10.0.2.8  |
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
(overcloud) [stack@undercloud ~]$ 

ચાલો જોઈએ કે બનાવેલ મશીનો કયા હાઇપરવાઇઝર પર સ્થિત છે:

(overcloud) [stack@undercloud ~]$ nova show f53b37b5-2204-46cc-aef0-dba84bf970c0 | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname             | vm-1                                                     |
| OS-EXT-SRV-ATTR:hypervisor_hostname  | overcloud-novacompute-0.localdomain                      |
| OS-EXT-SRV-ATTR:instance_name        | instance-00000001                                        |

(overcloud) [stack@undercloud ~]$ nova show fc8b6722-0231-49b0-b2fa-041115bef34a | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname             | vm-2                                                     |
| OS-EXT-SRV-ATTR:hypervisor_hostname  | overcloud-novacompute-1.localdomain                      |
| OS-EXT-SRV-ATTR:instance_name        | instance-00000002                                        |

(overcloud) [stack@undercloud ~]$ nova show 3cd74455-b9b7-467a-abe3-bd6ff765c83c | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname             | vm-3                                                     |
| OS-EXT-SRV-ATTR:hypervisor_hostname  | overcloud-novacompute-0.localdomain                      |
| OS-EXT-SRV-ATTR:instance_name        | instance-00000003                                        |

(overcloud) [stack@undercloud ~]$ nova show 7e836338-6772-46b0-9950-f7f06dbe91a8 | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname             | vm-4                                                     |
| OS-EXT-SRV-ATTR:hypervisor_hostname  | overcloud-novacompute-1.localdomain                      |
| OS-EXT-SRV-ATTR:instance_name        | instance-00000004                                        |

(ઓવરક્લાઉડ) [stack@undercloud ~]$
મશીનો vm-1 અને vm-3 કોમ્પ્યુટ-0 પર સ્થિત છે, મશીનો vm-2 અને vm-4 નોડ કોમ્પ્યુટ-1 પર સ્થિત છે.

વધુમાં, ઉલ્લેખિત નેટવર્ક્સ વચ્ચે રૂટીંગને સક્ષમ કરવા માટે વર્ચ્યુઅલ રાઉટર બનાવવામાં આવ્યું છે:

(overcloud) [stack@undercloud ~]$ openstack router list  --project 5e18ce8ec9594e00b155485f19895e6c
+--------------------------------------+----------+--------+-------+-------------+-------+----------------------------------+
| ID                                   | Name     | Status | State | Distributed | HA    | Project                          |
+--------------------------------------+----------+--------+-------+-------------+-------+----------------------------------+
| 0a4d2420-4b9c-46bd-aec1-86a1ef299abe | router-1 | ACTIVE | UP    | False       | False | 5e18ce8ec9594e00b155485f19895e6c |
+--------------------------------------+----------+--------+-------+-------------+-------+----------------------------------+
(overcloud) [stack@undercloud ~]$ 

રાઉટરમાં બે વર્ચ્યુઅલ પોર્ટ છે, જે નેટવર્ક માટે ગેટવે તરીકે કામ કરે છે:

(overcloud) [stack@undercloud ~]$ openstack router show 0a4d2420-4b9c-46bd-aec1-86a1ef299abe | grep interface
| interfaces_info         | [{"subnet_id": "2529ad1a-6b97-49cd-8515-cbdcbe5e3daa", "ip_address": "10.0.1.254", "port_id": "0c52b15f-8fcc-4801-bf52-7dacc72a5201"}, {"subnet_id": "335552dd-b35b-456b-9df0-5aac36a3ca13", "ip_address": "10.0.2.254", "port_id": "92fa49b5-5406-499f-ab8d-ddf28cc1a76c"}] |
(overcloud) [stack@undercloud ~]$ 

પરંતુ આપણે ટ્રાફિક કેવી રીતે વહે છે તે જોઈએ તે પહેલાં, ચાલો જોઈએ કે હાલમાં આપણી પાસે કંટ્રોલ નોડ (જે નેટવર્ક નોડ પણ છે) અને કોમ્પ્યુટ નોડ પર શું છે. ચાલો ગણતરી નોડથી શરૂઆત કરીએ.

[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-vsctl show
[heat-admin@overcloud-novacompute-0 ~]$ sudo sudo ovs-appctl dpif/show
system@ovs-system: hit:3 missed:3
  br-ex:
    br-ex 65534/1: (internal)
    phy-br-ex 1/none: (patch: peer=int-br-ex)
  br-int:
    br-int 65534/2: (internal)
    int-br-ex 1/none: (patch: peer=phy-br-ex)
    patch-tun 2/none: (patch: peer=patch-int)
  br-tun:
    br-tun 65534/3: (internal)
    patch-int 1/none: (patch: peer=patch-tun)
    vxlan-c0a8ff0f 3/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.15)
    vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$

આ ક્ષણે, નોડમાં ત્રણ ovs પુલ છે - br-int, br-tun, br-ex. તેમની વચ્ચે, જેમ આપણે જોઈએ છીએ, ત્યાં ઇન્ટરફેસનો સમૂહ છે. સમજવાની સરળતા માટે, ચાલો આ બધા ઇન્ટરફેસને ડાયાગ્રામ પર પ્લૉટ કરીએ અને જોઈએ કે શું થાય છે.

VxLAN ટનલ જે સરનામાંઓ પર ઉભી કરવામાં આવે છે તે જોઈ શકાય છે, તે જોઈ શકાય છે કે એક ટનલ ગણતરી-1 (192.168.255.26) પર ઉભી કરવામાં આવી છે, બીજી ટનલ નિયંત્રણ-1 (192.168.255.15) તરફ દેખાય છે. પરંતુ સૌથી રસપ્રદ બાબત એ છે કે br-ex પાસે ભૌતિક ઇન્ટરફેસ નથી, અને જો તમે જુઓ કે કયા પ્રવાહને ગોઠવવામાં આવ્યા છે, તો તમે જોઈ શકો છો કે આ બ્રિજ આ ક્ષણે ફક્ત ટ્રાફિકને છોડી શકે છે.

[heat-admin@overcloud-novacompute-0 ~]$ ifconfig eth0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1450
        inet 192.168.255.19  netmask 255.255.255.0  broadcast 192.168.255.255
        inet6 fe80::5054:ff:fe6a:eabe  prefixlen 64  scopeid 0x20<link>
        ether 52:54:00:6a:ea:be  txqueuelen 1000  (Ethernet)
        RX packets 2909669  bytes 4608201000 (4.2 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1821057  bytes 349198520 (333.0 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

[heat-admin@overcloud-novacompute-0 ~]$ 

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

[heat-admin@overcloud-novacompute-0 ~]$  sudo ovs-appctl fdb/show br-ex
 port  VLAN  MAC                Age
[heat-admin@overcloud-novacompute-0 ~]$  sudo ovs-ofctl dump-flows br-ex
 cookie=0x9169eae8f7fe5bb2, duration=216686.864s, table=0, n_packets=303, n_bytes=26035, priority=2,in_port="phy-br-ex" actions=drop
 cookie=0x9169eae8f7fe5bb2, duration=216686.887s, table=0, n_packets=0, n_bytes=0, priority=0 actions=NORMAL
[heat-admin@overcloud-novacompute-0 ~]$ 

પ્રથમ નિયમ મુજબ, phy-br-ex પોર્ટમાંથી આવતી દરેક વસ્તુને કાઢી નાખવી આવશ્યક છે.
વાસ્તવમાં, આ ઈન્ટરફેસ (br-int સાથેનું ઈન્ટરફેસ) સિવાય આ બ્રિજ પર ટ્રાફિક આવવા માટે હાલમાં બીજે ક્યાંય નથી, અને ટીપાંને ધ્યાનમાં રાખીને, BUM ટ્રાફિક પહેલેથી જ બ્રિજમાં વહી ગયો છે.

એટલે કે, ટ્રાફિક આ નોડને ફક્ત VxLAN ટનલ દ્વારા જ છોડી શકે છે અને બીજું કંઈ નહીં. જો કે, જો તમે DVR ચાલુ કરો છો, તો પરિસ્થિતિ બદલાઈ જશે, પરંતુ અમે બીજી વાર તેનો સામનો કરીશું. નેટવર્ક આઇસોલેશનનો ઉપયોગ કરતી વખતે, ઉદાહરણ તરીકે vlans નો ઉપયોગ કરીને, તમારી પાસે vlan 3 માં એક L0 ઇન્ટરફેસ નહીં, પરંતુ ઘણા ઇન્ટરફેસ હશે. જો કે, VxLAN ટ્રાફિક નોડને એ જ રીતે છોડશે, પણ અમુક પ્રકારના સમર્પિત vlanમાં પણ સમાવિષ્ટ થશે.

અમે કોમ્પ્યુટ નોડને સોર્ટ આઉટ કર્યો છે, ચાલો કંટ્રોલ નોડ પર આગળ વધીએ.

[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl dpif/show
system@ovs-system: hit:930491 missed:825
  br-ex:
    br-ex 65534/1: (internal)
    eth0 1/2: (system)
    phy-br-ex 2/none: (patch: peer=int-br-ex)
  br-int:
    br-int 65534/3: (internal)
    int-br-ex 1/none: (patch: peer=phy-br-ex)
    patch-tun 2/none: (patch: peer=patch-int)
  br-tun:
    br-tun 65534/4: (internal)
    patch-int 1/none: (patch: peer=patch-tun)
    vxlan-c0a8ff13 3/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.19)
    vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$

હકીકતમાં, આપણે કહી શકીએ કે બધું સમાન છે, પરંતુ IP સરનામું હવે ભૌતિક ઇન્ટરફેસ પર નહીં પરંતુ વર્ચ્યુઅલ બ્રિજ પર છે. આ એટલા માટે કરવામાં આવ્યું છે કારણ કે આ પોર્ટ એ બંદર છે જેના દ્વારા ટ્રાફિક બહારની દુનિયામાં જશે.

[heat-admin@overcloud-controller-0 ~]$ ifconfig br-ex
br-ex: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1450
        inet 192.168.255.15  netmask 255.255.255.0  broadcast 192.168.255.255
        inet6 fe80::5054:ff:fe20:a22f  prefixlen 64  scopeid 0x20<link>
        ether 52:54:00:20:a2:2f  txqueuelen 1000  (Ethernet)
        RX packets 803859  bytes 1732616116 (1.6 GiB)
        RX errors 0  dropped 63  overruns 0  frame 0
        TX packets 808475  bytes 121652156 (116.0 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

[heat-admin@overcloud-controller-0 ~]$ 
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-ex
 port  VLAN  MAC                Age
    3   100  28:c0:da:00:4d:d3   35
    1     0  28:c0:da:00:4d:d3   35
    1     0  52:54:00:98:e9:d6    0
LOCAL     0  52:54:00:20:a2:2f    0
    1     0  52:54:00:2c:08:9e    0
    3   100  52:54:00:20:a2:2f    0
    1     0  52:54:00:6a:ea:be    0
[heat-admin@overcloud-controller-0 ~]$ 

આ બંદર br-ex બ્રિજ સાથે જોડાયેલું છે અને તેના પર કોઈ vlan ટૅગ્સ ન હોવાથી, આ બંદર એક ટ્રંક બંદર છે જેના પર તમામ વ્લાન્સને મંજૂરી છે, હવે ટ્રાફિક ટૅગ વિના બહાર જાય છે, જેમ કે vlan-id 0 દ્વારા સૂચવવામાં આવ્યું છે. ઉપર આઉટપુટ.

આ ક્ષણે બાકીનું બધું કમ્પ્યુટ નોડ જેવું જ છે - સમાન પુલ, બે કમ્પ્યુટ ગાંઠો પર જતી સમાન ટનલ.

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

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

અત્યાર સુધી અમારું નેટવર્ક આના જેવું દેખાય છે:

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

[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh list 
 Id    Name                           State
----------------------------------------------------
 1     instance-00000001              running
 3     instance-00000003              running

[heat-admin@overcloud-novacompute-0 ~]$ 

મશીનમાં માત્ર એક વર્ચ્યુઅલ ઈન્ટરફેસ છે - tap95d96a75-a0:

[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interface  Type       Source     Model       MAC
-------------------------------------------------------
tap95d96a75-a0 bridge     qbr95d96a75-a0 virtio      fa:16:3e:44:98:20

[heat-admin@overcloud-novacompute-0 ~]$ 

આ ઇન્ટરફેસ લિનક્સ બ્રિજમાં દેખાય છે:

[heat-admin@overcloud-novacompute-0 ~]$ sudo brctl show
bridge name     bridge id               STP enabled     interfaces
docker0         8000.0242904c92a8       no
qbr5bd37136-47          8000.5e4e05841423       no              qvb5bd37136-47
                                                        tap5bd37136-47
qbr95d96a75-a0          8000.de076cb850f6       no              qvb95d96a75-a0
                                                        tap95d96a75-a0
[heat-admin@overcloud-novacompute-0 ~]$ 

જેમ તમે આઉટપુટમાંથી જોઈ શકો છો, બ્રિજમાં ફક્ત બે ઇન્ટરફેસ છે - tap95d96a75-a0 અને qvb95d96a75-a0.

અહીં OpenStack માં વર્ચ્યુઅલ નેટવર્ક ઉપકરણોના પ્રકારો પર થોડું ધ્યાન રાખવું યોગ્ય છે:
vtap - એક ઉદાહરણ સાથે જોડાયેલ વર્ચ્યુઅલ ઈન્ટરફેસ (VM)
qbr - Linux બ્રિજ
qvb અને qvo - vEth જોડી Linux બ્રિજ અને ઓપન vSwitch બ્રિજ સાથે જોડાયેલ છે
br-int, br-tun, br-vlan — ઓપન vSwitch બ્રિજ
patch-, int-br-, phy-br- - પુલને જોડતા vSwitch પેચ ઈન્ટરફેસ ખોલો
qg, qr, ha, fg, sg - OVS સાથે કનેક્ટ કરવા માટે વર્ચ્યુઅલ ઉપકરણો દ્વારા ઉપયોગમાં લેવાતા vSwitch પોર્ટ ખોલો

જેમ તમે સમજો છો, જો આપણી પાસે બ્રિજમાં qvb95d96a75-a0 પોર્ટ છે, જે vEth જોડી છે, તો ક્યાંક તેનો સમકક્ષ છે, જેને તાર્કિક રીતે qvo95d96a75-a0 કહેવા જોઈએ. ચાલો જોઈએ કે OVS પર કયા પોર્ટ છે.

[heat-admin@overcloud-novacompute-0 ~]$ sudo sudo ovs-appctl dpif/show
system@ovs-system: hit:526 missed:91
  br-ex:
    br-ex 65534/1: (internal)
    phy-br-ex 1/none: (patch: peer=int-br-ex)
  br-int:
    br-int 65534/2: (internal)
    int-br-ex 1/none: (patch: peer=phy-br-ex)
    patch-tun 2/none: (patch: peer=patch-int)
    qvo5bd37136-47 6/6: (system)
    qvo95d96a75-a0 3/5: (system)
  br-tun:
    br-tun 65534/3: (internal)
    patch-int 1/none: (patch: peer=patch-tun)
    vxlan-c0a8ff0f 3/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.15)
    vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$ 

જેમ આપણે જોઈ શકીએ છીએ, પોર્ટ br-int માં છે. Br-int એ સ્વીચ તરીકે કામ કરે છે જે વર્ચ્યુઅલ મશીન પોર્ટને સમાપ્ત કરે છે. qvo95d96a75-a0 ઉપરાંત, પોર્ટ qvo5bd37136-47 આઉટપુટમાં દેખાય છે. આ બીજા વર્ચ્યુઅલ મશીનનું પોર્ટ છે. પરિણામે, અમારું આકૃતિ હવે આના જેવું દેખાય છે:

એક પ્રશ્ન જે સચેત વાચકને તરત જ રસ લેવો જોઈએ - વર્ચ્યુઅલ મશીન પોર્ટ અને OVS પોર્ટ વચ્ચેનો લિનક્સ બ્રિજ શું છે? હકીકત એ છે કે મશીનને સુરક્ષિત કરવા માટે, સુરક્ષા જૂથોનો ઉપયોગ કરવામાં આવે છે, જે iptables કરતાં વધુ કંઈ નથી. OVS iptables સાથે કામ કરતું નથી, તેથી આ "ક્રચ" ની શોધ કરવામાં આવી હતી. જો કે, તે અપ્રચલિત બની રહ્યું છે - તેને નવા પ્રકાશનોમાં કોન્ટ્રાક દ્વારા બદલવામાં આવી રહ્યું છે.

એટલે કે, આખરે યોજના આના જેવી દેખાય છે:

એક L2 નેટવર્ક પર એક હાઇપરવાઇઝર પર બે મશીનો

આ બે VM સમાન L2 નેટવર્ક પર અને એક જ હાઇપરવાઇઝર પર સ્થિત હોવાથી, તેમની વચ્ચેનો ટ્રાફિક તાર્કિક રીતે br-int દ્વારા સ્થાનિક રીતે વહેશે, કારણ કે બંને મશીનો સમાન VLAN પર હશે:

[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interface  Type       Source     Model       MAC
-------------------------------------------------------
tap95d96a75-a0 bridge     qbr95d96a75-a0 virtio      fa:16:3e:44:98:20

[heat-admin@overcloud-novacompute-0 ~]$ 
[heat-admin@overcloud-novacompute-0 ~]$ 
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000003
Interface  Type       Source     Model       MAC
-------------------------------------------------------
tap5bd37136-47 bridge     qbr5bd37136-47 virtio      fa:16:3e:83:ad:a4

[heat-admin@overcloud-novacompute-0 ~]$ 
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-int 
 port  VLAN  MAC                Age
    6     1  fa:16:3e:83:ad:a4    0
    3     1  fa:16:3e:44:98:20    0
[heat-admin@overcloud-novacompute-0 ~]$ 

સમાન L2 નેટવર્ક પર વિવિધ હાઇપરવાઇઝર પર બે મશીનો

હવે ચાલો જોઈએ કે એક જ L2 નેટવર્ક પર બે મશીનો વચ્ચે ટ્રાફિક કેવી રીતે જશે, પરંતુ વિવિધ હાઇપરવાઇઝર્સ પર સ્થિત છે. પ્રમાણિકતાથી કહું તો, કંઈ બહુ બદલાશે નહીં, માત્ર હાઈપરવાઈઝર વચ્ચેનો ટ્રાફિક vxlan ટનલમાંથી પસાર થશે. ચાલો એક ઉદાહરણ જોઈએ.

વર્ચ્યુઅલ મશીનોના સરનામાં જેની વચ્ચે આપણે ટ્રાફિક જોઈશું:

[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interface  Type       Source     Model       MAC
-------------------------------------------------------
tap95d96a75-a0 bridge     qbr95d96a75-a0 virtio      fa:16:3e:44:98:20

[heat-admin@overcloud-novacompute-0 ~]$ 

[heat-admin@overcloud-novacompute-1 ~]$ sudo virsh domiflist instance-00000002
Interface  Type       Source     Model       MAC
-------------------------------------------------------
tape7e23f1b-07 bridge     qbre7e23f1b-07 virtio      fa:16:3e:72:ad:53

[heat-admin@overcloud-novacompute-1 ~]$ 

અમે ગણતરી-0 પર br-int માં ફોરવર્ડિંગ ટેબલ જોઈએ છીએ:

[heat-admin@overcloud-novacompute-0 ~]$  sudo ovs-appctl fdb/show br-int | grep fa:16:3e:72:ad:53
    2     1  fa:16:3e:72:ad:53    1
[heat-admin@overcloud-novacompute-0 ~]

ટ્રાફિક પોર્ટ 2 પર જવો જોઈએ - ચાલો જોઈએ કે તે કયા પ્રકારનું બંદર છે:

[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl show br-int | grep addr
 1(int-br-ex): addr:7e:7f:28:1f:bd:54
 2(patch-tun): addr:0a:bd:07:69:58:d9
 3(qvo95d96a75-a0): addr:ea:50:9a:3d:69:58
 6(qvo5bd37136-47): addr:9a:d1:03:50:3d:96
 LOCAL(br-int): addr:1a:0f:53:97:b1:49
[heat-admin@overcloud-novacompute-0 ~]$

આ પેચ-ટ્યુન છે - એટલે કે, બીઆર-ટુનમાં ઇન્ટરફેસ. ચાલો જોઈએ કે br-tun પર પેકેજનું શું થાય છે:

[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl dump-flows br-tun | grep fa:16:3e:72:ad:53
 cookie=0x8759a56536b67a8e, duration=1387.959s, table=20, n_packets=1460, n_bytes=138880, hard_timeout=300, idle_age=0, hard_age=0, priority=1,vlan_tci=0x0001/0x0fff,dl_dst=fa:16:3e:72:ad:53 actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:2
[heat-admin@overcloud-novacompute-0 ~]$ 

પેકેટ VxLAN માં પેક કરવામાં આવે છે અને પોર્ટ 2 પર મોકલવામાં આવે છે. ચાલો જોઈએ કે પોર્ટ 2 ક્યાં લઈ જાય છે:

[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl show br-tun | grep addr   
 1(patch-int): addr:b2:d1:f8:21:96:66
 2(vxlan-c0a8ff1a): addr:be:64:1f:75:78:a7
 3(vxlan-c0a8ff0f): addr:76:6f:b9:3c:3f:1c
 LOCAL(br-tun): addr:a2:5b:6d:4f:94:47
[heat-admin@overcloud-novacompute-0 ~]$

આ ગણતરી-1 પર vxlan ટનલ છે:

[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl dpif/show | egrep vxlan-c0a8ff1a
    vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$

ચાલો ગણતરી-1 પર જઈએ અને પેકેજ સાથે આગળ શું થાય છે તે જોઈએ:

[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-appctl fdb/show br-int | egrep fa:16:3e:44:98:20
    2     1  fa:16:3e:44:98:20    1
[heat-admin@overcloud-novacompute-1 ~]$ 

મેક કોમ્પ્યુટ-1 પર br-int ફોરવર્ડિંગ કોષ્ટકમાં છે, અને ઉપરના આઉટપુટમાંથી જોઈ શકાય છે, તે પોર્ટ 2 દ્વારા દૃશ્યમાન છે, જે br-tun તરફનું પોર્ટ છે:

[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-ofctl show br-int | grep addr   
 1(int-br-ex): addr:8a:d7:f9:ad:8c:1d
 2(patch-tun): addr:46:cc:40:bd:20:da
 3(qvoe7e23f1b-07): addr:12:78:2e:34:6a:c7
 4(qvo3210e8ec-c0): addr:7a:5f:59:75:40:85
 LOCAL(br-int): addr:e2:27:b2:ed:14:46

ઠીક છે, પછી આપણે જોઈએ છીએ કે કોમ્પ્યુટ-1 પર br-int માં એક ડેસ્ટિનેશન પોપી છે:

[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-appctl fdb/show br-int | egrep fa:16:3e:72:ad:53
    3     1  fa:16:3e:72:ad:53    0
[heat-admin@overcloud-novacompute-1 ~]$ 

એટલે કે, પ્રાપ્ત પેકેટ પોર્ટ 3 પર જશે, જેની પાછળ પહેલેથી જ વર્ચ્યુઅલ મશીન ઇન્સ્ટન્સ-00000003 છે.

વર્ચ્યુઅલ ઈન્ફ્રાસ્ટ્રક્ચર પર શીખવા માટે ઓપનસ્ટૅકને જમાવવાની સુંદરતા એ છે કે અમે હાઈપરવાઈઝર વચ્ચેના ટ્રાફિકને સરળતાથી કૅપ્ચર કરી શકીએ છીએ અને તેની સાથે શું થઈ રહ્યું છે તે જોઈ શકીએ છીએ. આ આપણે હવે કરીશું, vnet પોર્ટ પર tcpdump ને compute-0 તરફ ચલાવો:

[root@hp-gen9 bormoglotx]# tcpdump -vvv -i vnet3
tcpdump: listening on vnet3, link-type EN10MB (Ethernet), capture size 262144 bytes

*****************omitted*******************

04:39:04.583459 IP (tos 0x0, ttl 64, id 16868, offset 0, flags [DF], proto UDP (17), length 134)
    192.168.255.19.39096 > 192.168.255.26.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 8012, offset 0, flags [DF], proto ICMP (1), length 84)
    10.0.1.85 > 10.0.1.88: ICMP echo request, id 5634, seq 16, length 64
04:39:04.584449 IP (tos 0x0, ttl 64, id 35181, offset 0, flags [DF], proto UDP (17), length 134)
    192.168.255.26.speedtrace-disc > 192.168.255.19.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 59124, offset 0, flags [none], proto ICMP (1), length 84)
    10.0.1.88 > 10.0.1.85: ICMP echo reply, id 5634, seq 16, length 64
	
*****************omitted*******************

પ્રથમ લાઇન બતાવે છે કે એડ્રેસ 10.0.1.85 થી Patek એડ્રેસ 10.0.1.88 (ICMP ટ્રાફિક) પર જાય છે, અને તે vni 22 સાથે VxLAN પેકેટમાં લપેટાયેલું છે અને પેકેટ હોસ્ટ 192.168.255.19 (કમ્પ્યુટ-0) થી હોસ્ટ 192.168.255.26 પર જાય છે. .1 ( ગણતરી-XNUMX). અમે ચકાસી શકીએ છીએ કે VNI ovs માં ઉલ્લેખિત એક સાથે મેળ ખાય છે.

ચાલો આ લાઇન પર પાછા જઈએ actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],આઉટપુટ:2. હેક્સાડેસિમલ નંબર સિસ્ટમમાં 0x16 એ vni છે. ચાલો આ સંખ્યાને 16મી સિસ્ટમમાં કન્વર્ટ કરીએ:

16 = 6*16^0+1*16^1 = 6+16 = 22

એટલે કે, vni વાસ્તવિકતાને અનુરૂપ છે.

બીજી લાઇન રીટર્ન ટ્રાફિક બતાવે છે, સારું, તેને સમજાવવાનો કોઈ અર્થ નથી, ત્યાં બધું સ્પષ્ટ છે.

વિવિધ નેટવર્ક પર બે મશીનો (ઇન્ટર-નેટવર્ક રૂટીંગ)

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

પ્રથમ, ચાલો જોઈએ કે રૂટીંગ કામ કરે છે:

$ ping 10.0.2.8
PING 10.0.2.8 (10.0.2.8): 56 data bytes
64 bytes from 10.0.2.8: seq=0 ttl=63 time=7.727 ms
64 bytes from 10.0.2.8: seq=1 ttl=63 time=3.832 ms
^C
--- 10.0.2.8 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 3.832/5.779/7.727 ms

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

$ arp
host-10-0-1-254.openstacklocal (10.0.1.254) at fa:16:3e:c4:64:70 [ether]  on eth0
host-10-0-1-1.openstacklocal (10.0.1.1) at fa:16:3e:e6:2c:5c [ether]  on eth0
host-10-0-1-90.openstacklocal (10.0.1.90) at fa:16:3e:83:ad:a4 [ether]  on eth0
host-10-0-1-88.openstacklocal (10.0.1.88) at fa:16:3e:72:ad:53 [ether]  on eth0

હવે ચાલો જોઈએ કે ગંતવ્ય (10.0.1.254) fa:16:3e:c4:64:70 સાથેનો ટ્રાફિક ક્યાં મોકલવો જોઈએ:

[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-int | egrep fa:16:3e:c4:64:70
    2     1  fa:16:3e:c4:64:70    0
[heat-admin@overcloud-novacompute-0 ~]$ 

ચાલો જોઈએ કે પોર્ટ 2 ક્યાં દોરી જાય છે:

[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl show br-int | grep addr
 1(int-br-ex): addr:7e:7f:28:1f:bd:54
 2(patch-tun): addr:0a:bd:07:69:58:d9
 3(qvo95d96a75-a0): addr:ea:50:9a:3d:69:58
 6(qvo5bd37136-47): addr:9a:d1:03:50:3d:96
 LOCAL(br-int): addr:1a:0f:53:97:b1:49
[heat-admin@overcloud-novacompute-0 ~]$ 

બધું તાર્કિક છે, ટ્રાફિક br-tun પર જાય છે. ચાલો જોઈએ કે તે કઈ vxlan ટનલમાં લપેટવામાં આવશે:

[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl dump-flows br-tun | grep fa:16:3e:c4:64:70
 cookie=0x8759a56536b67a8e, duration=3514.566s, table=20, n_packets=3368, n_bytes=317072, hard_timeout=300, idle_age=0, hard_age=0, priority=1,vlan_tci=0x0001/0x0fff,dl_dst=fa:16:3e:c4:64:70 actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:3
[heat-admin@overcloud-novacompute-0 ~]$ 

ત્રીજું બંદર vxlan ટનલ છે:

[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-tun | grep addr
 1(patch-int): addr:a2:69:00:c5:fa:ba
 2(vxlan-c0a8ff1a): addr:86:f0:ce:d0:e8:ea
 3(vxlan-c0a8ff13): addr:72:aa:73:2c:2e:5b
 LOCAL(br-tun): addr:a6:cb:cd:72:1c:45
[heat-admin@overcloud-controller-0 ~]$ 

જે કંટ્રોલ નોડને જુએ છે:

[heat-admin@overcloud-controller-0 ~]$ sudo sudo ovs-appctl dpif/show | grep vxlan-c0a8ff1a
    vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$ 

ટ્રાફિક કંટ્રોલ નોડ પર પહોંચી ગયો છે, તેથી અમારે તેના પર જઈને રૂટીંગ કેવી રીતે થશે તે જોવાની જરૂર છે.

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

તેથી, તે સ્પષ્ટ છે કે ગેટવે MAC સરનામું કંટ્રોલ નોડ પરના br-int ફોરવર્ડિંગ ટેબલમાં હોવું જોઈએ. ચાલો તપાસીએ કે તે ત્યાં છે અને તે ક્યાં જોઈ રહ્યું છે:

[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:c4:64:70
    5     1  fa:16:3e:c4:64:70    1
[heat-admin@overcloud-controller-0 ~]$ 
[heat-admin@overcloud-controller-0 ~]$  sudo ovs-ofctl show br-int | grep addr
 1(int-br-ex): addr:2e:58:b6:db:d5:de
 2(patch-tun): addr:06:41:90:f0:9e:56
 3(tapca25a97e-64): addr:fa:16:3e:e6:2c:5c
 4(tap22015e46-0b): addr:fa:16:3e:76:c2:11
 5(qr-0c52b15f-8f): addr:fa:16:3e:c4:64:70
 6(qr-92fa49b5-54): addr:fa:16:3e:80:13:72
 LOCAL(br-int): addr:06:de:5d:ed:44:44
[heat-admin@overcloud-controller-0 ~]$ 

Mac qr-0c52b15f-8f પોર્ટ પરથી દેખાય છે. જો આપણે Openstack માં વર્ચ્યુઅલ પોર્ટની યાદી પર પાછા જઈએ, તો આ પ્રકારના પોર્ટનો ઉપયોગ OVS સાથે વિવિધ વર્ચ્યુઅલ ઉપકરણોને કનેક્ટ કરવા માટે થાય છે. વધુ ચોક્કસ થવા માટે, qr એ વર્ચ્યુઅલ રાઉટરનું પોર્ટ છે, જે નેમસ્પેસ તરીકે રજૂ થાય છે.

ચાલો જોઈએ કે સર્વર પર કઈ નેમસ્પેસ છે:

[heat-admin@overcloud-controller-0 ~]$ sudo  ip netns
qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe (id: 2)
qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638 (id: 1)
qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 (id: 0)
[heat-admin@overcloud-controller-0 ~]$ 

ત્રણ જેટલી નકલો. પરંતુ નામો દ્વારા અભિપ્રાય આપતા, તમે તેમાંથી દરેકનો હેતુ અનુમાન કરી શકો છો. અમે પછીથી ID 0 અને 1 સાથેના ઉદાહરણો પર પાછા આવીશું, હવે અમને નેમસ્પેસ qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe માં રસ છે:

[heat-admin@overcloud-controller-0 ~]$ sudo  ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe ip route
10.0.1.0/24 dev qr-0c52b15f-8f proto kernel scope link src 10.0.1.254 
10.0.2.0/24 dev qr-92fa49b5-54 proto kernel scope link src 10.0.2.254 
[heat-admin@overcloud-controller-0 ~]$ 

આ નેમસ્પેસમાં બે આંતરિક જગ્યાઓ છે જે આપણે પહેલા બનાવી છે. બંને વર્ચ્યુઅલ પોર્ટ br-int માં ઉમેરવામાં આવ્યા છે. ચાલો પોર્ટ qr-0c52b15f-8f નું મેક સરનામું તપાસીએ, કારણ કે ટ્રાફિક, ગંતવ્ય મેક સરનામાં દ્વારા નક્કી કરીને, આ ઇન્ટરફેસ પર જાય છે.

[heat-admin@overcloud-controller-0 ~]$ sudo  ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe ifconfig qr-0c52b15f-8f
qr-0c52b15f-8f: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1450
        inet 10.0.1.254  netmask 255.255.255.0  broadcast 10.0.1.255
        inet6 fe80::f816:3eff:fec4:6470  prefixlen 64  scopeid 0x20<link>
        ether fa:16:3e:c4:64:70  txqueuelen 1000  (Ethernet)
        RX packets 5356  bytes 427305 (417.2 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 5195  bytes 490603 (479.1 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

[heat-admin@overcloud-controller-0 ~]$ 

એટલે કે, આ કિસ્સામાં, બધું પ્રમાણભૂત રૂટીંગના કાયદા અનુસાર કાર્ય કરે છે. ટ્રાફિક હોસ્ટ 10.0.2.8 માટે નિર્ધારિત હોવાથી, તે બીજા ઈન્ટરફેસ qr-92fa49b5-54માંથી બહાર નીકળવું જોઈએ અને vxlan ટનલમાંથી કોમ્પ્યુટ નોડ પર જવું જોઈએ:

[heat-admin@overcloud-controller-0 ~]$ sudo  ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe arp
Address                  HWtype  HWaddress           Flags Mask            Iface
10.0.1.88                ether   fa:16:3e:72:ad:53   C                     qr-0c52b15f-8f
10.0.1.90                ether   fa:16:3e:83:ad:a4   C                     qr-0c52b15f-8f
10.0.2.8                 ether   fa:16:3e:6c:ad:9c   C                     qr-92fa49b5-54
10.0.2.42                ether   fa:16:3e:f5:0b:29   C                     qr-92fa49b5-54
10.0.1.85                ether   fa:16:3e:44:98:20   C                     qr-0c52b15f-8f
[heat-admin@overcloud-controller-0 ~]$ 

બધું તાર્કિક છે, કોઈ આશ્ચર્ય નથી. ચાલો જોઈએ કે હોસ્ટ 10.0.2.8 નું પોપી એડ્રેસ br-int માં ક્યાં દેખાય છે:

[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:6c:ad:9c
    2     2  fa:16:3e:6c:ad:9c    1
[heat-admin@overcloud-controller-0 ~]$ 
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-int | grep addr
 1(int-br-ex): addr:2e:58:b6:db:d5:de
 2(patch-tun): addr:06:41:90:f0:9e:56
 3(tapca25a97e-64): addr:fa:16:3e:e6:2c:5c
 4(tap22015e46-0b): addr:fa:16:3e:76:c2:11
 5(qr-0c52b15f-8f): addr:fa:16:3e:c4:64:70
 6(qr-92fa49b5-54): addr:fa:16:3e:80:13:72
 LOCAL(br-int): addr:06:de:5d:ed:44:44
[heat-admin@overcloud-controller-0 ~]$ 

અપેક્ષા મુજબ, ટ્રાફિક br-tun પર જાય છે, ચાલો જોઈએ કે આગળ કઈ ટનલ પર ટ્રાફિક જાય છે:

[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl dump-flows br-tun | grep fa:16:3e:6c:ad:9c
 cookie=0x2ab04bf27114410e, duration=5346.829s, table=20, n_packets=5248, n_bytes=498512, hard_timeout=300, idle_age=0, hard_age=0, priority=1,vlan_tci=0x0002/0x0fff,dl_dst=fa:16:3e:6c:ad:9c actions=load:0->NXM_OF_VLAN_TCI[],load:0x63->NXM_NX_TUN_ID[],output:2
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-tun | grep addr
 1(patch-int): addr:a2:69:00:c5:fa:ba
 2(vxlan-c0a8ff1a): addr:86:f0:ce:d0:e8:ea
 3(vxlan-c0a8ff13): addr:72:aa:73:2c:2e:5b
 LOCAL(br-tun): addr:a6:cb:cd:72:1c:45
[heat-admin@overcloud-controller-0 ~]$ 
[heat-admin@overcloud-controller-0 ~]$ sudo sudo ovs-appctl dpif/show | grep vxlan-c0a8ff1a
    vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$ 

કમ્પ્યુટ-1માં ટ્રાફિક ટનલમાં જાય છે. ઠીક છે, ગણતરી -1 પર બધું સરળ છે - br-tun થી પેકેજ br-int પર જાય છે અને ત્યાંથી વર્ચ્યુઅલ મશીન ઇન્ટરફેસ પર જાય છે:

[heat-admin@overcloud-controller-0 ~]$ sudo sudo ovs-appctl dpif/show | grep vxlan-c0a8ff1a
    vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$ 
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:6c:ad:9c
    4     2  fa:16:3e:6c:ad:9c    1
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-ofctl show br-int | grep addr                  
 1(int-br-ex): addr:8a:d7:f9:ad:8c:1d
 2(patch-tun): addr:46:cc:40:bd:20:da
 3(qvoe7e23f1b-07): addr:12:78:2e:34:6a:c7
 4(qvo3210e8ec-c0): addr:7a:5f:59:75:40:85
 LOCAL(br-int): addr:e2:27:b2:ed:14:46
[heat-admin@overcloud-novacompute-1 ~]$ 

ચાલો તપાસીએ કે આ ખરેખર સાચો ઈન્ટરફેસ છે:

[heat-admin@overcloud-novacompute-1 ~]$ brctl show
bridge name     bridge id               STP enabled     interfaces
docker0         8000.02429c001e1c       no
qbr3210e8ec-c0          8000.ea27f45358be       no              qvb3210e8ec-c0
                                                        tap3210e8ec-c0
qbre7e23f1b-07          8000.b26ac0eded8a       no              qvbe7e23f1b-07
                                                        tape7e23f1b-07
[heat-admin@overcloud-novacompute-1 ~]$ 
[heat-admin@overcloud-novacompute-1 ~]$ sudo virsh domiflist instance-00000004
Interface  Type       Source     Model       MAC
-------------------------------------------------------
tap3210e8ec-c0 bridge     qbr3210e8ec-c0 virtio      fa:16:3e:6c:ad:9c

[heat-admin@overcloud-novacompute-1 ~]$

ખરેખર, અમે પેકેજ દ્વારા બધી રીતે ગયા. મને લાગે છે કે તમે નોંધ્યું છે કે ટ્રાફિક વિવિધ vxlan ટનલમાંથી પસાર થાય છે અને વિવિધ VNIs સાથે બહાર નીકળે છે. ચાલો જોઈએ કે આ કયા પ્રકારના VNI છે, જેના પછી આપણે નોડના કંટ્રોલ પોર્ટ પર ડમ્પ એકત્રિત કરીશું અને ખાતરી કરીશું કે ઉપર વર્ણવ્યા પ્રમાણે ટ્રાફિક બરાબર વહે છે.
તેથી, ગણતરી-0ની ટનલમાં નીચેની ક્રિયાઓ છે=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],આઉટપુટ:3. ચાલો 0x16 ને દશાંશ નંબર સિસ્ટમમાં કન્વર્ટ કરીએ:

0x16 = 6*16^0+1*16^1 = 6+16 = 22

ગણતરી-1 માટેની ટનલ નીચેની VNI:એક્શન્સ=લોડ:0->NXM_OF_VLAN_TCI[],load:0x63->NXM_NX_TUN_ID[],આઉટપુટ:2 ધરાવે છે. ચાલો 0x63 ને દશાંશ નંબર સિસ્ટમમાં કન્વર્ટ કરીએ:

0x63 = 3*16^0+6*16^1 = 3+96 = 99

સારું, હવે ચાલો ડમ્પ જોઈએ:

[root@hp-gen9 bormoglotx]# tcpdump -vvv -i vnet4 
tcpdump: listening on vnet4, link-type EN10MB (Ethernet), capture size 262144 bytes

*****************omitted*******************

04:35:18.709949 IP (tos 0x0, ttl 64, id 48650, offset 0, flags [DF], proto UDP (17), length 134)
    192.168.255.19.41591 > 192.168.255.15.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 49042, offset 0, flags [DF], proto ICMP (1), length 84)
    10.0.1.85 > 10.0.2.8: ICMP echo request, id 5378, seq 9, length 64
04:35:18.710159 IP (tos 0x0, ttl 64, id 23360, offset 0, flags [DF], proto UDP (17), length 134)
    192.168.255.15.38983 > 192.168.255.26.4789: [no cksum] VXLAN, flags [I] (0x08), vni 99
IP (tos 0x0, ttl 63, id 49042, offset 0, flags [DF], proto ICMP (1), length 84)
    10.0.1.85 > 10.0.2.8: ICMP echo request, id 5378, seq 9, length 64
04:35:18.711292 IP (tos 0x0, ttl 64, id 43596, offset 0, flags [DF], proto UDP (17), length 134)
    192.168.255.26.42588 > 192.168.255.15.4789: [no cksum] VXLAN, flags [I] (0x08), vni 99
IP (tos 0x0, ttl 64, id 55103, offset 0, flags [none], proto ICMP (1), length 84)
    10.0.2.8 > 10.0.1.85: ICMP echo reply, id 5378, seq 9, length 64
04:35:18.711531 IP (tos 0x0, ttl 64, id 8555, offset 0, flags [DF], proto UDP (17), length 134)
    192.168.255.15.38983 > 192.168.255.19.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 63, id 55103, offset 0, flags [none], proto ICMP (1), length 84)
    10.0.2.8 > 10.0.1.85: ICMP echo reply, id 5378, seq 9, length 64
	
*****************omitted*******************

પ્રથમ પેકેટ હોસ્ટ 192.168.255.19 (કમ્પ્યુટ-0) થી vni 192.168.255.15 સાથે 1 (કંટ્રોલ-22) ને હોસ્ટ કરવા માટેનું vxlan પેકેટ છે, જેની અંદર ICMP પેકેટ હોસ્ટ 10.0.1.85 થી.. 10.0.2.8 હોસ્ટ સુધીનું પેકેટ છે. જેમ આપણે ઉપર ગણતરી કરી છે, vni આપણે આઉટપુટમાં જે જોયું તે સાથે મેળ ખાય છે.

બીજું પેકેટ હોસ્ટ 192.168.255.15 (કંટ્રોલ-1) થી vni 192.168.255.26 સાથે 1 (કમ્પ્યુટ-99) ને હોસ્ટ કરવા માટેનું vxlan પેકેટ છે, જેની અંદર ICMP પેકેટ હોસ્ટ 10.0.1.85 થી..10.0.2.8 હોસ્ટ સુધી પેક કરવામાં આવે છે. જેમ આપણે ઉપર ગણતરી કરી છે, vni આપણે આઉટપુટમાં જે જોયું તે સાથે મેળ ખાય છે.

આગળના બે પેકેટો 10.0.2.8 થી 10.0.1.85 ના બદલે રીટર્ન ટ્રાફિક છે.

એટલે કે, અંતે અમને નીચેની નિયંત્રણ નોડ યોજના મળી:

જુઓ કે તે છે? અમે બે નેમસ્પેસ વિશે ભૂલી ગયા છીએ:

[heat-admin@overcloud-controller-0 ~]$ sudo  ip netns
qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe (id: 2)
qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638 (id: 1)
qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 (id: 0)
[heat-admin@overcloud-controller-0 ~]$ 

જેમ આપણે ક્લાઉડ પ્લેટફોર્મના આર્કિટેક્ચર વિશે વાત કરી છે, તે સારું રહેશે જો મશીનો DHCP સર્વરથી આપમેળે સરનામાં પ્રાપ્ત કરે. અમારા બે નેટવર્ક 10.0.1.0/24 અને 10.0.2.0/24 માટે આ બે DHCP સર્વર છે.

ચાલો તપાસીએ કે આ સાચું છે. આ નેમસ્પેસમાં માત્ર એક સરનામું છે - 10.0.1.1 - DHCP સર્વરનું સરનામું, અને તે br-int માં પણ સામેલ છે:

[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 ifconfig
lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 1  bytes 28 (28.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1  bytes 28 (28.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

tapca25a97e-64: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1450
        inet 10.0.1.1  netmask 255.255.255.0  broadcast 10.0.1.255
        inet6 fe80::f816:3eff:fee6:2c5c  prefixlen 64  scopeid 0x20<link>
        ether fa:16:3e:e6:2c:5c  txqueuelen 1000  (Ethernet)
        RX packets 129  bytes 9372 (9.1 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 49  bytes 6154 (6.0 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

ચાલો જોઈએ કે કંટ્રોલ નોડ પર તેમના નામમાં qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 ધરાવતી પ્રક્રિયાઓ છે કે કેમ:

[heat-admin@overcloud-controller-0 ~]$ ps -aux | egrep qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638 
root      640420  0.0  0.0   4220   348 ?        Ss   11:31   0:00 dumb-init --single-child -- ip netns exec qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638 /usr/sbin/dnsmasq -k --no-hosts --no-resolv --pid-file=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/pid --dhcp-hostsfile=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/host --addn-hosts=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/addn_hosts --dhcp-optsfile=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/opts --dhcp-leasefile=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/leases --dhcp-match=set:ipxe,175 --local-service --bind-dynamic --dhcp-range=set:subnet-335552dd-b35b-456b-9df0-5aac36a3ca13,10.0.2.0,static,255.255.255.0,86400s --dhcp-option-force=option:mtu,1450 --dhcp-lease-max=256 --conf-file= --domain=openstacklocal
heat-ad+  951620  0.0  0.0 112944   980 pts/0    S+   18:50   0:00 grep -E --color=auto qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638
[heat-admin@overcloud-controller-0 ~]$ 

આવી પ્રક્રિયા છે અને ઉપરના આઉટપુટમાં પ્રસ્તુત માહિતીના આધારે, અમે, ઉદાહરણ તરીકે, જોઈ શકીએ છીએ કે અમારી પાસે હાલમાં ભાડા માટે શું છે:

[heat-admin@overcloud-controller-0 ~]$ cat /var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/leases
1597492111 fa:16:3e:6c:ad:9c 10.0.2.8 host-10-0-2-8 01:fa:16:3e:6c:ad:9c
1597491115 fa:16:3e:76:c2:11 10.0.2.1 host-10-0-2-1 *
[heat-admin@overcloud-controller-0 ~]$

પરિણામે, અમને કંટ્રોલ નોડ પર નીચેની સેવાઓનો સમૂહ મળે છે:

સારું, ધ્યાનમાં રાખો - આ માત્ર 4 મશીનો, 2 આંતરિક નેટવર્ક્સ અને એક વર્ચ્યુઅલ રાઉટર છે... અમારી પાસે હવે અહીં બાહ્ય નેટવર્ક નથી, વિવિધ પ્રોજેક્ટ્સનો સમૂહ, દરેક તેમના પોતાના નેટવર્ક્સ (ઓવરલેપિંગ) સાથે, અને અમારી પાસે છે ડિસ્ટ્રિબ્યુટેડ રાઉટર બંધ થઈ ગયું, અને અંતે, ટેસ્ટ બેન્ચમાં માત્ર એક જ કંટ્રોલ નોડ હતો (ફોલ્ટ ટોલરન્સ માટે ત્રણ નોડ્સનો કોરમ હોવો જોઈએ). તે તાર્કિક છે કે વાણિજ્યમાં બધું "થોડું" વધુ જટિલ છે, પરંતુ આ સરળ ઉદાહરણમાં આપણે સમજીએ છીએ કે તે કેવી રીતે કાર્ય કરવું જોઈએ - તમારી પાસે 3 અથવા 300 નેમસ્પેસ છે તે અલબત્ત મહત્વપૂર્ણ છે, પરંતુ સમગ્ર કામગીરીના દૃષ્ટિકોણથી માળખું, કંઈપણ વધુ બદલાશે નહીં... જો કે જ્યાં સુધી તમે કોઈ વિક્રેતા SDN માં પ્લગ નહીં કરો. પરંતુ તે સંપૂર્ણપણે અલગ વાર્તા છે.

મને આશા છે કે તે રસપ્રદ હતું. જો તમારી પાસે કોઈ ટિપ્પણી/ઉમેરાઓ હોય, અથવા ક્યાંક મેં સ્પષ્ટ જૂઠું બોલ્યું હોય (હું માનવ છું અને મારો અભિપ્રાય હંમેશા વ્યક્તિલક્ષી રહેશે) - જે સુધારવા/ઉમેરવાની જરૂર છે તે લખો - અમે બધું સુધારી/ઉમેરશું.

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

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

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

મારા મતે, VMWare નો સૌથી મોટો ગેરલાભ એ તેની સંપૂર્ણ બંધતા છે - કંપની તમને તે કેવી રીતે કાર્ય કરે છે તે વિશે કોઈ માહિતી આપશે નહીં, ઉદાહરણ તરીકે, vSAN અથવા હાઇપરવાઇઝર કર્નલમાં શું છે - તે ફક્ત તેના માટે નફાકારક નથી - એટલે કે, તમે VMWare માં ક્યારેય નિષ્ણાત ન બનો - વિક્રેતાના સમર્થન વિના, તમે વિનાશકારી છો (ઘણી વાર હું VMWare નિષ્ણાતોને મળું છું જેઓ તુચ્છ પ્રશ્નોથી મૂંઝાઈ જાય છે). મારા માટે, VMWare હૂડ લૉકવાળી કાર ખરીદી રહ્યું છે - હા, તમારી પાસે નિષ્ણાતો હોઈ શકે છે જેઓ ટાઇમિંગ બેલ્ટ બદલી શકે છે, પરંતુ ફક્ત તે જ હૂડ ખોલી શકે છે જેણે તમને આ સોલ્યુશન વેચ્યું છે. અંગત રીતે, મને એવા ઉકેલો પસંદ નથી કે જેમાં હું ફિટ ન થઈ શકું. તમે કહેશો કે તમારે હૂડ હેઠળ જવું પડશે નહીં. હા, આ શક્ય છે, પરંતુ જ્યારે તમારે 20-30 વર્ચ્યુઅલ મશીનો, 40-50 નેટવર્ક્સમાંથી ક્લાઉડમાં મોટા ફંક્શનને એસેમ્બલ કરવાની જરૂર હોય ત્યારે હું તમને જોઈશ, જેમાંથી અડધા બહાર જવા માંગે છે, અને બીજા અડધા માટે પૂછે છે. SR-IOV પ્રવેગક, અન્યથા તમારે આ કારમાંથી બે ડઝન વધુની જરૂર પડશે - અન્યથા પ્રદર્શન પૂરતું નહીં હોય.

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

સોર્સ: www.habr.com