ડેટા સેન્ટર્સને કેવી રીતે સ્કેલ કરવું. યાન્ડેક્ષ રિપોર્ટ

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

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

- દરેકને શુભ બપોર! મારું નામ દિમિત્રી અફનાસ્યેવ છે, હું યાન્ડેક્સમાં નેટવર્ક આર્કિટેક્ટ છું અને મુખ્યત્વે ડેટા સેન્ટર નેટવર્ક ડિઝાઇન કરું છું.



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

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

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

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

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

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

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

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

અલબત્ત, અમને ઓટોમેશનની જરૂર છે, કારણ કે આવા ઇન્ફ્રાસ્ટ્રક્ચરનું જાતે સંચાલન કરવું અશક્ય છે, અને તે કેટલાક સમયથી અશક્ય છે. અમને શક્ય તેટલું ઓપરેશનલ સપોર્ટ અને તે પૂરી પાડી શકાય તેટલી હદ સુધી CI/CD સપોર્ટની જરૂર છે.

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

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

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

તો, તે શું છે જેની આપણને જરૂર નથી, આપણે શું છોડી શક્યા છીએ, તે બન્યું તે સમયે હંમેશા આનંદ સાથે નહીં, પરંતુ જ્યારે પ્રક્રિયા પૂર્ણ થાય ત્યારે મોટી રાહત સાથે?

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

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

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

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

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

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

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

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

અલબત્ત, પ્રશ્ન ઊભો થાય છે: ક્લોસ નેટવર્ક્સ થોડા સમય માટે બનાવવામાં આવ્યા છે; આ વિચાર સામાન્ય રીતે ક્લાસિકલ ટેલિફોની, TDM નેટવર્કના સમયથી આવે છે. કદાચ કંઈક સારું દેખાયું, કદાચ કંઈક વધુ સારું કરી શકાય? હા અને ના. સૈદ્ધાંતિક રીતે હા, વ્યવહારમાં નજીકના ભવિષ્યમાં ચોક્કસપણે નહીં. કારણ કે ત્યાં અસંખ્ય રસપ્રદ ટોપોલોજીઓ છે, તેમાંના કેટલાકનો ઉપયોગ ઉત્પાદનમાં પણ થાય છે, ઉદાહરણ તરીકે, ડ્રેગનફ્લાયનો ઉપયોગ HPC એપ્લિકેશન્સમાં થાય છે; Xpander, FatClique, Jellyfish જેવી રસપ્રદ ટોપોલોજી પણ છે. જો તમે તાજેતરમાં SIGCOMM અથવા NSDI જેવી પરિષદોના અહેવાલો જુઓ છો, તો તમે વૈકલ્પિક ટોપોલોજીઓ પર ખૂબ મોટી સંખ્યામાં કામો શોધી શકો છો જેમાં Clos કરતાં વધુ સારી પ્રોપર્ટીઝ (એક અથવા બીજી) હોય છે.

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

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

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

આમ, દિશા રસપ્રદ છે, પરંતુ, અરે, અમે તેને હમણાં લાગુ કરી શકતા નથી.

ઠીક છે, અમે Clos લોજિકલ ટોપોલોજી પર સ્થાયી થયા છીએ. આપણે તેને કેવી રીતે માપીશું? ચાલો જોઈએ કે તે કેવી રીતે કાર્ય કરે છે અને શું કરી શકાય છે.

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

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

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

જો તમે Clos નેટવર્કનું વિસ્તૃત સંસ્કરણ જુઓ (નીચે જમણા ખૂણે) અને નીચે Clos નેટવર્ક સાથે આ ચિત્ર પર પાછા ફરો...

... પછી આ બરાબર એ જ ટોપોલોજી છે, પરંતુ આ સ્લાઇડ પર તે વધુ સઘન રીતે ભાંગી પડે છે અને ફેક્ટરીના વિમાનો એકબીજા પર સુપરઇમ્પોઝ કરવામાં આવે છે. તે એકસરખુ છે.

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

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

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

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

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

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

આ ચિત્રના આધારે, તે સ્પષ્ટ છે કે અમે ખરેખર 128 ના રેડિક્સ સાથે સ્વિચ જેવા કંઈક પર બિલ્ડ કરવા માંગીએ છીએ.

અહીં, સૈદ્ધાંતિક રીતે, મેં હમણાં જ જે કહ્યું તે જ બધું છે; આ પછીથી વિચારણા માટે એક સ્લાઇડ છે.

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

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

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

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

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

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

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

સારાંશ માટે, અમે આઠ ફેક્ટરી સ્તરો સાથે, સ્પાઇન્સના બે સ્તરો સાથે ટોપોલોજી પર નિર્માણ કરી રહ્યા છીએ.

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

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

એક વધુ નોંધ: કમનસીબે, ડિસએસેમ્બલ 100 થી 4x25 મલ્ટિમોડ પોર્ટનો ઉપયોગ કરવો ખૂબ જ શક્ય નથી. SFP28 ટ્રાન્સસીવર્સની ડિઝાઇન સુવિધાઓને લીધે, તે 28 Gbit QSFP100 કરતાં વધુ સસ્તું નથી. અને મલ્ટિમોડ માટે આ ડિસએસેમ્બલી ખૂબ સારી રીતે કામ કરતું નથી.

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

પરિણામે, જો આપણે કિંમત માટે ઑપ્ટિમાઇઝ કરીએ અને આ ડિઝાઇનની ભૂમિતિને ધ્યાનમાં લઈએ, તો અમને CWDM નો ઉપયોગ કરીને ટ્વીનેક્સનો એક સ્પાન, મલ્ટિમોડનો એક સ્પાન અને સિંગલમોડનો એક સ્પાન મળે છે. આ સંભવિત અપગ્રેડ પાથને ધ્યાનમાં લે છે.

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

ભૌતિકશાસ્ત્રની પસંદગી વિશે વધુ એક સૂક્ષ્મતા. સૈદ્ધાંતિક રીતે, અમે પહેલેથી જ 400G SerDes નો ઉપયોગ કરીને 200 અથવા 50 ગીગાબીટ પોર્ટનો ઉપયોગ કરી શકીએ છીએ. પરંતુ તે તારણ આપે છે કે આનો કોઈ અર્થ નથી, કારણ કે, જેમ મેં અગાઉ કહ્યું તેમ, અમને સ્વીચો પર એકદમ મોટો રેડિક્સ જોઈએ છે, અલબત્ત, કારણસર. અમને 128 જોઈએ છે. અને જો અમારી પાસે મર્યાદિત ચિપ ક્ષમતા હોય અને અમે લિંકની ઝડપ વધારીએ, તો મૂળાંક કુદરતી રીતે ઘટે છે, ત્યાં કોઈ ચમત્કાર નથી.

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

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

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

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

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

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

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

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

આ કરવા માટે, અમે એવી ડિઝાઇનનો ઉપયોગ કરીએ છીએ જે અંતર્ગત BGP મિકેનિઝમનો ઉપયોગ કરવા માટે પૂરતી સરળ છે. એટલે કે, અમે લિંક લોકલ પર ચાલતા eBGP નો ઉપયોગ કરીએ છીએ, અને ઓટોનોમસ સિસ્ટમ્સ નીચે પ્રમાણે અસાઇન કરવામાં આવી છે: ToR પર એક ઓટોનોમસ સિસ્ટમ, એક પોડના સ્પાઇન-1 સ્વીચોના સમગ્ર બ્લોક પર એક ઓટોનોમસ સિસ્ટમ અને સમગ્ર ટોપ પર સામાન્ય ઓટોનોમસ સિસ્ટમ ફેબ્રિકનું. તે જોવું અને જોવું મુશ્કેલ નથી કે BGP ની સામાન્ય વર્તણૂક પણ અમને જોઈતા અપડેટ્સનું વિતરણ આપે છે.

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

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

આ સંદર્ભમાં ખૂબ જ રસપ્રદ કાર્ય RIFT પ્રોટોકોલના માળખામાં કરવામાં આવ્યું છે, જેની ચર્ચા આગામી અહેવાલમાં કરવામાં આવશે.

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

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

આધુનિક ઉપકરણો પર ડેટા પ્લેન માપનીયતા કેવી દેખાય છે? જો આપણે LPM (સૌથી લાંબો ઉપસર્ગ મેચ) કરીએ, તો બધું ખૂબ સારું છે, 100k ઉપસર્ગોથી વધુ. જો આપણે નેક્સ્ટ હોપ જૂથો વિશે વાત કરી રહ્યા છીએ, તો બધું ખરાબ છે, 2-4 હજાર. જો આપણે એક ટેબલ વિશે વાત કરી રહ્યા છીએ જેમાં નેક્સ્ટ હોપ્સ (અથવા સંલગ્નતા) નું વર્ણન છે, તો આ ક્યાંક 16k થી 64k છે. અને આ એક સમસ્યા બની શકે છે. અને અહીં આપણે એક રસપ્રદ વિષયાંતર પર આવીએ છીએ: ડેટા સેન્ટર્સમાં એમપીએલએસનું શું થયું? સૈદ્ધાંતિક રીતે, અમે તે કરવા માંગતા હતા.

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

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

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

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

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

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

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

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

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

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

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

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

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

સોર્સ: www.habr.com