એક નેટવર્ક જે પોતાને સાજા કરે છે: ફ્લો લેબલનો જાદુ અને Linux કર્નલની આસપાસ ડિટેક્ટીવ. યાન્ડેક્ષ રિપોર્ટ

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

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


ઘણા નેટવર્ક એન્જિનિયરો માટે, ડેટા સેન્ટર નેટવર્ક, અલબત્ત, ToR સાથે, રેકમાં સ્વિચ સાથે શરૂ થાય છે. સામાન્ય રીતે ToR બે પ્રકારની લિંક્સ ધરાવે છે. નાના લોકો સર્વર પર જાય છે, અન્ય - તેમાંના N ગણા વધારે છે - પ્રથમ સ્તરના સ્પાઇન્સ તરફ જાય છે, એટલે કે, તેના અપલિંક્સ પર. અપલિંકને સામાન્ય રીતે સમાન ગણવામાં આવે છે, અને અપલિંક વચ્ચેનો ટ્રાફિક 5-ટુપલના હેશના આધારે સંતુલિત હોય છે, જેમાં પ્રોટો, src_ip, dst_ip, src_port, dst_portનો સમાવેશ થાય છે. અહીં કોઈ આશ્ચર્ય નથી.


આગળ, પ્લાન આર્કિટેક્ચર કેવું દેખાય છે? પ્રથમ સ્તરના સ્પાઇન્સ એકબીજા સાથે જોડાયેલા નથી, પરંતુ સુપરસ્પાઇન્સ દ્વારા જોડાયેલા છે. અક્ષર X સુપરસ્પાઇન્સ માટે જવાબદાર હશે; તે લગભગ ક્રોસ-કનેક્ટ જેવું છે.


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


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


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


ત્યાં આઠ વિમાનો છે, દરેક વિમાનમાં 32 સુપરસ્પાઇન્સ છે. પરિણામે, તે તારણ આપે છે કે મોડ્યુલની અંદર આઠ પાથ છે, અને આંતર-મોડ્યુલ ક્રિયાપ્રતિક્રિયા સાથે તેમાંથી 256 પહેલાથી જ છે.

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


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


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


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


હું આશા રાખું છું કે હું આ માહિતીથી કોઈને પણ આંચકો નહીં આપું: TCP એ ટ્રાન્સમિશન કન્ફર્મેશન પ્રોટોકોલ છે. એટલે કે, સૌથી સરળ કિસ્સામાં, પ્રેષક બે પેકેટ મોકલે છે, અને તેમના પર એક સંચિત ack મેળવે છે: "મને બે પેકેટ મળ્યા છે."


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


જો આપણે પેકેટ 3 ગુમાવીએ તો શું થશે? આ કિસ્સામાં, પ્રાપ્તકર્તાને પેકેટ 1, 2 અને 4 પ્રાપ્ત થશે. અને તે SACK વિકલ્પનો ઉપયોગ કરીને પ્રેષકને સ્પષ્ટપણે જાણ કરશે: "તમે જાણો છો, ત્રણ આવ્યા હતા, પરંતુ મધ્ય ખોવાઈ ગયું હતું." તે કહે છે, "Ack 2, SACK 4."


આ ક્ષણે પ્રેષક બરાબર પેકેટનું પુનરાવર્તન કરે છે જે કોઈપણ સમસ્યા વિના ખોવાઈ ગયું હતું.


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

પ્રાપ્તકર્તા પ્રથમ ત્રણ પેકેટ મેળવે છે અને સૌ પ્રથમ રાહ જોવાનું શરૂ કરે છે. Linux કર્નલના TCP સ્ટેકમાં કેટલાક ઑપ્ટિમાઇઝેશન માટે આભાર, તે જોડીવાળા પેકેટની રાહ જોશે સિવાય કે ફ્લેગ્સ સ્પષ્ટપણે દર્શાવે છે કે તે છેલ્લું પેકેટ છે અથવા તેના જેવું કંઈક છે. વિલંબિત ACK સમય સમાપ્ત થાય ત્યાં સુધી તે રાહ જોશે અને પછી પ્રથમ ત્રણ પેકેટો પર સ્વીકૃતિ મોકલશે. પણ હવે મોકલનાર રાહ જોશે. તેને ખબર નથી કે ચોથું પેકેજ ખોવાઈ ગયું છે કે આવવાનું છે. અને નેટવર્કને ઓવરલોડ ન કરવા માટે, તે સ્પષ્ટ સંકેતની રાહ જોવાનો પ્રયાસ કરશે કે પેકેટ ખોવાઈ ગયું છે, અથવા RTO સમયસમાપ્તિ સમાપ્ત થાય છે.


RTO સમયસમાપ્તિ શું છે? TCP સ્ટેક દ્વારા ગણતરી કરાયેલ RTTમાંથી આ મહત્તમ છે અને કેટલાક સ્થિર છે. આ સતત શું છે, આપણે હવે ચર્ચા કરીશું.


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


હવે ચાલો જોઈએ કે આ આધાર શું છે. મૂળભૂત રીતે, ન્યૂનતમ RTO 200 ms છે. ડેટા પેકેજો માટે આ ન્યૂનતમ RTO છે. SYN પેકેટો માટે તે અલગ છે, 1 સેકન્ડ. જેમ તમે જોઈ શકો છો, પેકેટો ફરીથી મોકલવાનો પ્રથમ પ્રયાસ પણ ડેટા સેન્ટરની અંદર RTT કરતા 100 ગણો વધુ સમય લેશે.


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


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


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

ઘણી સેવાઓનું માનવું છે કે NOC માં કંઈક આવું થાય છે. પણ સાચું કહું તો એટલું જ નહિ.


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


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

પરંતુ અહીં એક સૂક્ષ્મતા છે. તે શું છે તે સમજવા માટે, આપણે સ્ટ્રીમ્સ કેવી રીતે સેટ કરવામાં આવે છે તે જોવું પડશે.


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


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


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


હું તમને મારી સાથે થોડી તપાસ કરવા આમંત્રણ આપું છું. ચાલો જોઈએ કે છેલ્લા કેટલાક વર્ષોમાં Linux કર્નલમાં શું થઈ રહ્યું છે.

વર્ષ 2014. એક મોટી અને આદરણીય કંપનીમાંથી એક એન્જિનિયર Linux કર્નલની કાર્યક્ષમતામાં સોકેટ હેશ પર ફ્લો લેબલ મૂલ્યની અવલંબન ઉમેરે છે. તેઓ અહીં શું ઠીક કરવાનો પ્રયાસ કરી રહ્યા હતા? આ RFC 6438 થી સંબંધિત છે, જેણે નીચેના મુદ્દાની ચર્ચા કરી છે. ડેટા સેન્ટરની અંદર, IPv4 ને ઘણીવાર IPv6 પેકેટોમાં સમાવિષ્ટ કરવામાં આવે છે, કારણ કે ફેક્ટરી પોતે IPv6 છે, પરંતુ IPv4 કોઈક રીતે બહાર આપવી જોઈએ. TCP અથવા UDP પર જવા માટે અને ત્યાં src_ports, dst_ports શોધવા માટે બે IP હેડરની નીચે ન જોઈ શકતાં સ્વિચમાં લાંબા સમયથી સમસ્યાઓ હતી. તે બહાર આવ્યું છે કે હેશ, જો તમે પ્રથમ બે આઇપી હેડરો જુઓ છો, તો તે લગભગ નિશ્ચિત હોવાનું બહાર આવ્યું છે. આને અવગણવા માટે, જેથી આ એન્કેપ્સ્યુલેટેડ ટ્રાફિકનું સંતુલન યોગ્ય રીતે કાર્ય કરે, તે ફ્લો લેબલ ફીલ્ડના મૂલ્યમાં 5-ટ્યુપલ એન્કેપ્સ્યુલેટેડ પેકેટના હેશને ઉમેરવાની દરખાસ્ત કરવામાં આવી હતી. લગભગ સમાન વસ્તુ અન્ય એન્કેપ્સ્યુલેશન યોજનાઓ માટે કરવામાં આવી હતી, UDP માટે, GRE માટે, બાદમાં GRE કી ફીલ્ડનો ઉપયોગ કરવામાં આવ્યો હતો. એક યા બીજી રીતે, અહીં ધ્યેયો સ્પષ્ટ છે. અને ઓછામાં ઓછા તે સમયે તેઓ ઉપયોગી હતા.

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

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

ના હોવા છતાં, તમે કરી શકતા નથી, કારણ કે આ વિષય પર એક પણ પ્રકાશન થયું નથી. પણ આપણે જાણીએ છીએ!

અને જો તમે સંપૂર્ણપણે સમજી શકતા નથી કે શું કરવામાં આવ્યું હતું, તો હું તમને હવે કહીશ.


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

અહીં શું મહત્વનું છે? ફ્લો લેબલ ફીલ્ડનું મૂલ્ય દરેક RTO પછી રેન્ડમ નંબરમાં બદલાય છે. આ અમારા કમનસીબ TCP સ્ટ્રીમને કેવી રીતે અસર કરે છે?


જો SACK થાય, તો કંઈ બદલાતું નથી કારણ કે અમે જાણીતું ખોવાયેલ પેકેટ ફરીથી મોકલવાનો પ્રયાસ કરી રહ્યા છીએ. અત્યાર સુધી ખૂબ સારું.


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


એક સમસ્યા રહે છે - RTO. અલબત્ત, બીજો માર્ગ છે, પરંતુ આમાં ઘણો સમય વેડફાય છે. 200 ms ઘણો છે. એક સેકન્ડ એકદમ જંગલી છે. અગાઉ, મેં સમયસમાપ્તિ વિશે વાત કરી હતી જે સેવાઓ ગોઠવેલી છે. તેથી, સેકન્ડ એ સમયસમાપ્તિ છે, જે સામાન્ય રીતે એપ્લિકેશન સ્તર પર સેવા દ્વારા ગોઠવવામાં આવે છે, અને આમાં સેવા પ્રમાણમાં યોગ્ય પણ હશે. વધુમાં, હું પુનરાવર્તન કરું છું, આધુનિક ડેટા સેન્ટરની અંદર વાસ્તવિક RTT લગભગ 1 મિલીસેકન્ડ છે.


RTO સમયસમાપ્તિ સાથે તમે શું કરી શકો? સમયસમાપ્તિ, જે ડેટા પેકેટના નુકશાનના કિસ્સામાં RTO માટે જવાબદાર છે, તે વપરાશકર્તાની જગ્યામાંથી પ્રમાણમાં સરળતાથી ગોઠવી શકાય છે: ત્યાં એક IP ઉપયોગિતા છે, અને તેના પરિમાણોમાંના એકમાં સમાન rto_min છે. આરટીઓ, અલબત્ત, વૈશ્વિક સ્તરે એડજસ્ટ કરવાની જરૂર નથી, પરંતુ આપેલ ઉપસર્ગો માટે, આવી પદ્ધતિ તદ્દન કાર્યક્ષમ લાગે છે.


સાચું, SYN_RTO સાથે બધું કંઈક અંશે ખરાબ છે. તે કુદરતી રીતે નીચે ખીલી છે. કર્નલનું નિશ્ચિત મૂલ્ય 1 સેકન્ડ છે, અને બસ. તમે યુઝર સ્પેસથી ત્યાં પહોંચી શકતા નથી. એક જ રસ્તો છે.


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


પરંતુ તે અમારા માટે મહત્વપૂર્ણ છે કે તેની મદદથી તમે SYN_RTO ના મૂલ્યોને ટ્વિસ્ટ કરી શકો છો. અને સાર્વજનિક રીતે પોસ્ટ કરેલ ઉદાહરણ છે: https://elixir.bootlin.com/linux/latest/source/samples/bpf/tcp_synrto_kern.c. અહીં શું કરવામાં આવ્યું છે? ઉદાહરણ કામ કરી રહ્યું છે, પરંતુ પોતે ખૂબ જ રફ છે. અહીં એવું માનવામાં આવે છે કે ડેટા સેન્ટરની અંદર આપણે પ્રથમ 44 બિટ્સની તુલના કરીએ છીએ; જો તે મેળ ખાય છે, તો આપણે ડેટા સેન્ટરની અંદર છીએ. અને આ કિસ્સામાં અમે SYN_RTO સમય સમાપ્તિ મૂલ્યને 4ms માં બદલીએ છીએ. સમાન કાર્ય વધુ સુંદર રીતે કરી શકાય છે. પરંતુ આ સરળ ઉદાહરણ બતાવે છે કે આ એ) શક્ય છે; b) પ્રમાણમાં સરળ.

આપણે પહેલાથી શું જાણીએ છીએ? હકીકત એ છે કે પ્લેન આર્કિટેક્ચર સ્કેલિંગ માટે પરવાનગી આપે છે, જ્યારે અમે ToR પર ફ્લો લેબલને સક્ષમ કરીએ છીએ અને સમસ્યાવાળા વિસ્તારોમાં વહેવાની ક્ષમતા મેળવીએ છીએ ત્યારે તે અમારા માટે અત્યંત ઉપયોગી સાબિત થાય છે. RTO અને SYN-RTO મૂલ્યો ઘટાડવાનો શ્રેષ્ઠ માર્ગ eBPF પ્રોગ્રામ્સનો ઉપયોગ કરવાનો છે. પ્રશ્ન રહે છે: શું સંતુલન માટે ફ્લો લેબલનો ઉપયોગ કરવો સલામત છે? અને અહીં એક સૂક્ષ્મતા છે.


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


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

એક યા બીજી રીતે, મને લાગે છે કે આપણે પ્રયોગો તરફ આગળ વધવા માટે તૈયાર છીએ.


જ્યારે અમે ToR પર ફ્લો લેબલને સક્ષમ કર્યું, eBPF એજન્ટ તૈયાર કર્યો, જે હવે યજમાનો પર રહે છે, ત્યારે અમે આગામી મોટી નિષ્ફળતાની રાહ જોવાનું નહીં, પરંતુ નિયંત્રિત વિસ્ફોટો કરવાનું નક્કી કર્યું. અમે ToR લીધી, જેમાં ચાર અપલિંક છે અને તેમાંથી એક પર ડ્રોપ્સ સેટ કર્યા. તેઓએ એક નિયમ બનાવ્યો અને કહ્યું - હવે તમે બધા પેકેટ ગુમાવી રહ્યા છો. જેમ તમે ડાબી બાજુ જોઈ શકો છો, અમારી પાસે પ્રતિ-પેકેટ મોનિટરિંગ છે, જે ઘટીને 75% થઈ ગયું છે, એટલે કે, 25% પેકેટો ખોવાઈ ગયા છે. જમણી બાજુએ આ ToR પાછળ રહેતી સેવાઓના ગ્રાફ છે. અનિવાર્યપણે, આ રેકની અંદર સર્વર્સ સાથેના ઇન્ટરફેસના ટ્રાફિક ગ્રાફ છે. જેમ તમે જોઈ શકો છો, તેઓ પણ નીચે ડૂબી ગયા. શા માટે તેઓ નીચા પડ્યા - 25% દ્વારા નહીં, પરંતુ કેટલાક કિસ્સાઓમાં 3-4 વખત? જો TCP કનેક્શન કમનસીબ હોય, તો તે તૂટેલા જંકશન દ્વારા પહોંચવાનો પ્રયાસ ચાલુ રાખે છે. DC ની અંદર સેવાની લાક્ષણિક વર્તણૂક દ્વારા આ વધુ ઉશ્કેરવામાં આવે છે - એક વપરાશકર્તા વિનંતી માટે, આંતરિક સેવાઓ માટે N વિનંતીઓ જનરેટ થાય છે, અને જ્યારે તમામ ડેટા સ્ત્રોતો પ્રતિસાદ આપે છે, અથવા જ્યારે એપ્લિકેશનમાં સમય સમાપ્ત થાય છે ત્યારે પ્રતિસાદ વપરાશકર્તાને જશે. સ્તર, જે હજુ પણ રૂપરેખાંકિત કરવાની જરૂર છે. એટલે કે, બધું ખૂબ, ખૂબ જ ખરાબ છે.


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

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

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

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

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

સોર્સ: www.habr.com