Yandex.Cloud માં નેટવર્ક લોડ બેલેન્સરનું આર્કિટેક્ચર

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

પ્રથમ, ચાલો કેટલીક શરતો રજૂ કરીએ:

• VIP (વર્ચ્યુઅલ IP) - બેલેન્સર IP સરનામું
• સર્વર, બેકએન્ડ, ઉદાહરણ - એપ્લિકેશન ચલાવતું વર્ચ્યુઅલ મશીન
• RIP (રિયલ IP) - સર્વર IP સરનામું
• આરોગ્ય તપાસ - સર્વરની તત્પરતા તપાસવી
• ઉપલબ્ધતા ઝોન, AZ - ડેટા સેન્ટરમાં અલગ ઈન્ફ્રાસ્ટ્રક્ચર
• પ્રદેશ - વિવિધ એઝેડનું સંઘ

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

લોડ બેલેન્સર ઘણીવાર OSI મોડેલના પ્રોટોકોલ સ્તર દ્વારા વર્ગીકૃત કરવામાં આવે છે જેના પર તે ચાલે છે. ક્લાઉડ બેલેન્સર TCP સ્તર પર કાર્ય કરે છે, જે ચોથા સ્તર, L4 ને અનુરૂપ છે.

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

ડેટા પ્લેન

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

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

રૂપરેખા પ્લેન

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

પરિણામે, API તરફથી કાર્ય બેલેન્સર સેવા નિયંત્રકને વિનંતી કરશે, જે Go માં લખાયેલ છે. તે બેલેન્સર્સ ઉમેરી અને દૂર કરી શકે છે, બેકએન્ડ અને સેટિંગ્સની રચના બદલી શકે છે. 

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

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

આરોગ્ય તપાસ નિયંત્રક

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

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

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

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

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

તફાવત એ છે કે ગ્રાહકો VIP ને વિનંતી કરે છે, જ્યારે આરોગ્ય તપાસ દરેક વ્યક્તિગત RIP ને વિનંતી કરે છે. અહીં એક રસપ્રદ સમસ્યા ઊભી થાય છે: અમે અમારા વપરાશકર્તાઓને ગ્રે IP નેટવર્ક્સમાં સંસાધનો બનાવવાની તક આપીએ છીએ. ચાલો કલ્પના કરીએ કે બે અલગ અલગ ક્લાઉડ માલિકો છે જેમણે તેમની સેવાઓ બેલેન્સર્સ પાછળ છુપાવી છે. તેમાંના દરેક પાસે સમાન સરનામાં સાથે 10.0.0.1/24 સબનેટમાં સંસાધનો છે. તમારે તેમને કોઈક રીતે અલગ પાડવા માટે સક્ષમ બનવાની જરૂર છે, અને અહીં તમારે Yandex.Cloud વર્ચ્યુઅલ નેટવર્કની રચનામાં ડાઇવ કરવાની જરૂર છે. માં વધુ વિગતો શોધવાનું વધુ સારું છે વિશે:ક્લાઉડ ઇવેન્ટમાંથી વિડિઓ, અમારા માટે હવે એ મહત્વનું છે કે નેટવર્ક બહુ-સ્તરવાળું છે અને તેમાં ટનલ છે જેને સબનેટ આઈડી દ્વારા ઓળખી શકાય છે.

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

રિવર્સ ટ્રાફિક એ જ રીતે જાય છે: બેલેન્સર જુએ છે કે ગંતવ્ય હેલ્થચેકર્સનું ગ્રે નેટવર્ક છે, અને IPv4 ને IPv6 માં રૂપાંતરિત કરે છે.

VPP - ડેટા પ્લેનનું હૃદય

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

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

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

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

n_left_from = frame->n_vectors;
while (n_left_from > 0)
{
    vlib_get_next_frame (vm, node, next_index, to_next, n_left_to_next);
    // ...
    while (n_left_from >= 4 && n_left_to_next >= 2)
    {
        // processing multiple packets at once
        u32 next0 = SAMPLE_NEXT_INTERFACE_OUTPUT;
        u32 next1 = SAMPLE_NEXT_INTERFACE_OUTPUT;
        // ...
        /* Prefetch next iteration. */
        {
            vlib_buffer_t *p2, *p3;

            p2 = vlib_get_buffer (vm, from[2]);
            p3 = vlib_get_buffer (vm, from[3]);

            vlib_prefetch_buffer_header (p2, LOAD);
            vlib_prefetch_buffer_header (p3, LOAD);

            CLIB_PREFETCH (p2->data, CLIB_CACHE_LINE_BYTES, STORE);
            CLIB_PREFETCH (p3->data, CLIB_CACHE_LINE_BYTES, STORE);
        }
        // actually process data
        /* verify speculative enqueues, maybe switch current next frame */
        vlib_validate_buffer_enqueue_x2 (vm, node, next_index,
                to_next, n_left_to_next,
                bi0, bi1, next0, next1);
    }

    while (n_left_from > 0 && n_left_to_next > 0)
    {
        // processing packets by one
    }

    // processed batch
    vlib_put_next_frame (vm, node, next_index, n_left_to_next);
}

તેથી, હેલ્થચેક્સ IPv6 પર VPP સાથે વાત કરે છે, જે તેમને IPv4 માં ફેરવે છે. આ ગ્રાફમાં નોડ દ્વારા કરવામાં આવે છે, જેને આપણે અલ્ગોરિધમિક NAT કહીએ છીએ. રિવર્સ ટ્રાફિક (અને IPv6 થી IPv4 માં રૂપાંતર) માટે સમાન અલ્ગોરિધમિક NAT નોડ છે.

બેલેન્સર ક્લાયન્ટ્સનો સીધો ટ્રાફિક ગ્રાફ નોડ્સમાંથી પસાર થાય છે, જે પોતે જ બેલેન્સિંગ કરે છે. 

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

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

સતત હેશિંગ

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

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

સતત હેશિંગ વર્ણવેલ સમસ્યાને હલ કરે છે. આ ખ્યાલને સમજાવવાનો સૌથી સહેલો રસ્તો આ છે: કલ્પના કરો કે તમારી પાસે એક રિંગ છે જેમાં તમે હેશ દ્વારા સંસાધનોનું વિતરણ કરો છો (ઉદાહરણ તરીકે, IP:પોર્ટ દ્વારા). સંસાધન પસંદ કરવું એ વ્હીલને કોણ દ્વારા ફેરવવાનું છે, જે પેકેટના હેશ દ્વારા નક્કી કરવામાં આવે છે.

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

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

લોડબેલેન્સર-નોડ અને એસેમ્બલ ઘટકો

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

કયા મુદ્દાઓ ટાળવામાં આવ્યા હતા?

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

સમસ્યાઓ અને ઉકેલો

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

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

માઇક્રોસર્વિસ ઇવેન્ટ આર્કિટેક્ચર મોનોલિથ કરતાં વધુ જટિલ છે: ડઝનેક અલગ-અલગ મશીનો પર લૉગ્સ એકત્રિત કરવા ખૂબ અનુકૂળ નથી. નિષ્કર્ષ: જો તમે માઇક્રોસર્વિસિસ કરો છો, તો તરત જ ટ્રેસિંગ વિશે વિચારો.

અમારી યોજનાઓ

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

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

સોર્સ: www.habr.com