Yandex.Cloud-ൽ ഒരു നെറ്റ്‌വർക്ക് ലോഡ് ബാലൻസറിന്റെ ആർക്കിടെക്ചർ

ഹലോ, ഞാൻ സെർജി എലാൻസെവ് ആണ്, ഞാൻ വികസിപ്പിക്കുന്നു നെറ്റ്വർക്ക് ലോഡ് ബാലൻസർ Yandex.Cloud-ൽ. മുമ്പ്, Yandex പോർട്ടലിനായുള്ള L7 ബാലൻസറിന്റെ വികസനത്തിന് ഞാൻ നേതൃത്വം നൽകി - ഞാൻ എന്ത് ചെയ്താലും അത് ഒരു ബാലൻസറായി മാറുമെന്ന് സഹപ്രവർത്തകർ തമാശ പറയുന്നു. ഒരു ക്ലൗഡ് പ്ലാറ്റ്‌ഫോമിലെ ലോഡ് എങ്ങനെ കൈകാര്യം ചെയ്യാമെന്നും ഈ ലക്ഷ്യം നേടുന്നതിനുള്ള ഏറ്റവും അനുയോജ്യമായ ഉപകരണമായി ഞങ്ങൾ കാണുന്നതെന്താണെന്നും ഈ ഉപകരണം നിർമ്മിക്കുന്നതിലേക്ക് ഞങ്ങൾ നീങ്ങുന്നത് എങ്ങനെയെന്നും ഞാൻ ഹബ്ർ വായനക്കാരോട് പറയും.

ആദ്യം, നമുക്ക് ചില നിബന്ധനകൾ അവതരിപ്പിക്കാം:

• വിഐപി (വെർച്വൽ ഐപി) - ബാലൻസ് ഐപി വിലാസം
• സെർവർ, ബാക്കെൻഡ്, ഉദാഹരണം - ഒരു ആപ്ലിക്കേഷൻ പ്രവർത്തിപ്പിക്കുന്ന ഒരു വെർച്വൽ മെഷീൻ
• RIP (റിയൽ IP) - സെർവർ IP വിലാസം
• ആരോഗ്യ പരിശോധന - സെർവർ സന്നദ്ധത പരിശോധിക്കുന്നു
• അവൈലബിലിറ്റി സോൺ, AZ - ഒരു ഡാറ്റാ സെന്ററിലെ ഒറ്റപ്പെട്ട ഇൻഫ്രാസ്ട്രക്ചർ
• മേഖല - വിവിധ AZ-കളുടെ ഒരു യൂണിയൻ

ലോഡ് ബാലൻസറുകൾ മൂന്ന് പ്രധാന ജോലികൾ പരിഹരിക്കുന്നു: അവർ ബാലൻസിങ് സ്വയം നിർവഹിക്കുന്നു, സേവനത്തിന്റെ തെറ്റ് സഹിഷ്ണുത മെച്ചപ്പെടുത്തുന്നു, അതിന്റെ സ്കെയിലിംഗ് ലളിതമാക്കുന്നു. ഓട്ടോമാറ്റിക് ട്രാഫിക് മാനേജ്‌മെന്റിലൂടെ തെറ്റ് സഹിഷ്ണുത ഉറപ്പാക്കുന്നു: ബാലൻസർ ആപ്ലിക്കേഷന്റെ അവസ്ഥ നിരീക്ഷിക്കുകയും ലൈവ്‌നസ് പരിശോധനയിൽ വിജയിക്കാത്ത സന്ദർഭങ്ങൾ ബാലൻസിൽ നിന്ന് ഒഴിവാക്കുകയും ചെയ്യുന്നു. ഇൻസ്‌റ്റൻസുകളിലുടനീളം ലോഡ് തുല്യമായി വിതരണം ചെയ്യുന്നതിലൂടെയും അതുപോലെ ഫ്ലൈയിലെ സംഭവങ്ങളുടെ ലിസ്റ്റ് അപ്‌ഡേറ്റ് ചെയ്യുന്നതിലൂടെയും സ്കെയിലിംഗ് ഉറപ്പാക്കുന്നു. ബാലൻസിംഗ് വേണ്ടത്ര ഏകീകൃതമല്ലെങ്കിൽ, ചില സന്ദർഭങ്ങളിൽ അവയുടെ ശേഷി പരിധി കവിയുന്ന ഒരു ലോഡ് ലഭിക്കും, കൂടാതെ സേവനം വിശ്വാസ്യത കുറയുകയും ചെയ്യും.

ഒരു ലോഡ് ബാലൻസറിനെ പലപ്പോഴും അത് പ്രവർത്തിക്കുന്ന ഒഎസ്ഐ മോഡലിൽ നിന്നുള്ള പ്രോട്ടോക്കോൾ ലെയർ ഉപയോഗിച്ച് തരംതിരിക്കുന്നു. ക്ലൗഡ് ബാലൻസർ ടിസിപി തലത്തിലാണ് പ്രവർത്തിക്കുന്നത്, ഇത് നാലാമത്തെ ലെയറായ L4 ന് സമാനമാണ്.

ക്ലൗഡ് ബാലൻസർ ആർക്കിടെക്ചറിന്റെ ഒരു അവലോകനത്തിലേക്ക് നമുക്ക് പോകാം. ഞങ്ങൾ വിശദാംശങ്ങളുടെ അളവ് ക്രമേണ വർദ്ധിപ്പിക്കും. ഞങ്ങൾ ബാലൻസർ ഘടകങ്ങളെ മൂന്ന് ക്ലാസുകളായി വിഭജിക്കുന്നു. കോൺഫിഗറേഷൻ പ്ലെയിൻ ക്ലാസ് ഉപയോക്തൃ ഇടപെടലിന് ഉത്തരവാദിയാണ് കൂടാതെ സിസ്റ്റത്തിന്റെ ടാർഗെറ്റ് അവസ്ഥ സംഭരിക്കുന്നു. കൺട്രോൾ പ്ലെയിൻ സിസ്റ്റത്തിന്റെ നിലവിലെ അവസ്ഥ സംഭരിക്കുകയും ക്ലയന്റുകളിൽ നിന്ന് നിങ്ങളുടെ സന്ദർഭങ്ങളിലേക്ക് ട്രാഫിക് എത്തിക്കുന്നതിന് നേരിട്ട് ഉത്തരവാദികളായ ഡാറ്റാ പ്ലെയിൻ ക്ലാസിൽ നിന്നുള്ള സിസ്റ്റങ്ങൾ നിയന്ത്രിക്കുകയും ചെയ്യുന്നു.

ഡാറ്റാ വിമാനം

ബോർഡർ റൂട്ടറുകൾ എന്നറിയപ്പെടുന്ന വിലകൂടിയ ഉപകരണങ്ങളിലാണ് ട്രാഫിക് അവസാനിക്കുന്നത്. തെറ്റ് സഹിഷ്ണുത വർദ്ധിപ്പിക്കുന്നതിന്, അത്തരം നിരവധി ഉപകരണങ്ങൾ ഒരു ഡാറ്റാ സെന്ററിൽ ഒരേസമയം പ്രവർത്തിക്കുന്നു. അടുത്തതായി, ക്ലയന്റുകൾക്കായി BGP വഴി എല്ലാ AZ-കളിലേക്കും ഏതെങ്കിലും IP വിലാസങ്ങൾ പ്രഖ്യാപിക്കുന്ന ബാലൻസറുകളിലേക്ക് ട്രാഫിക് പോകുന്നു. 

ട്രാഫിക് ഇസിഎംപി വഴി കൈമാറ്റം ചെയ്യപ്പെടുന്നു - ഇത് ഒരു റൂട്ടിംഗ് തന്ത്രമാണ്, അതനുസരിച്ച് ടാർഗെറ്റിലേക്ക് തുല്യമായ നിരവധി റൂട്ടുകൾ ഉണ്ടാകാം (ഞങ്ങളുടെ കാര്യത്തിൽ, ലക്ഷ്യം ലക്ഷ്യസ്ഥാന ഐപി വിലാസമായിരിക്കും) കൂടാതെ പാക്കറ്റുകൾ അവയിലേതെങ്കിലും അയയ്‌ക്കാനും കഴിയും. ഇനിപ്പറയുന്ന സ്കീമിന് അനുസൃതമായി നിരവധി ലഭ്യത സോണുകളിലെ പ്രവർത്തനത്തെ ഞങ്ങൾ പിന്തുണയ്ക്കുന്നു: ഓരോ സോണിലും ഞങ്ങൾ ഒരു വിലാസം പരസ്യം ചെയ്യുന്നു, ട്രാഫിക് അടുത്തുള്ളതിലേക്ക് പോകുന്നു, അതിന്റെ പരിധിക്കപ്പുറം പോകുന്നില്ല. പിന്നീട് പോസ്റ്റിൽ ട്രാഫിക്കിന് എന്ത് സംഭവിക്കുമെന്ന് ഞങ്ങൾ കൂടുതൽ വിശദമായി പരിശോധിക്കും.

കോൺഫിഗറേഷൻ വിമാനം

 
കോൺഫിഗറേഷൻ പ്ലെയിനിന്റെ പ്രധാന ഘടകം API ആണ്, അതിലൂടെ ബാലൻസറുകളുമായുള്ള അടിസ്ഥാന പ്രവർത്തനങ്ങൾ നടത്തുന്നു: സൃഷ്ടിക്കൽ, ഇല്ലാതാക്കൽ, സന്ദർഭങ്ങളുടെ ഘടന മാറ്റൽ, ആരോഗ്യ പരിശോധന ഫലങ്ങൾ നേടൽ തുടങ്ങിയവ. ഒരു വശത്ത്, ഇതൊരു REST API ആണ്, കൂടാതെ മറ്റുള്ളവ, ക്ലൗഡിൽ ഞങ്ങൾ പലപ്പോഴും ഫ്രെയിംവർക്ക് gRPC ഉപയോഗിക്കുന്നു, അതിനാൽ ഞങ്ങൾ REST എന്നത് gRPC ലേക്ക് "വിവർത്തനം ചെയ്യുക" തുടർന്ന് gRPC മാത്രം ഉപയോഗിക്കുക. ഏത് അഭ്യർത്ഥനയും Yandex.Cloud തൊഴിലാളികളുടെ ഒരു പൊതു പൂളിൽ നിർവ്വഹിക്കുന്ന അസിൻക്രണസ് ഐഡമ്പോട്ടന്റ് ടാസ്ക്കുകളുടെ ഒരു പരമ്പര സൃഷ്ടിക്കുന്നതിലേക്ക് നയിക്കുന്നു. ടാസ്‌ക്കുകൾ എപ്പോൾ വേണമെങ്കിലും സസ്പെൻഡ് ചെയ്യാനും പിന്നീട് പുനരാരംഭിക്കാനും കഴിയുന്ന തരത്തിലാണ് എഴുതിയിരിക്കുന്നത്. ഇത് പ്രവർത്തനങ്ങളുടെ സ്കേലബിളിറ്റി, ആവർത്തനക്ഷമത, ലോഗിംഗ് എന്നിവ ഉറപ്പാക്കുന്നു.

തൽഫലമായി, API-ൽ നിന്നുള്ള ടാസ്‌ക് Go- ൽ എഴുതിയിരിക്കുന്ന ബാലൻസർ സർവീസ് കൺട്രോളറോട് ഒരു അഭ്യർത്ഥന നടത്തും. ഇതിന് ബാലൻസറുകൾ ചേർക്കാനും നീക്കംചെയ്യാനും ബാക്കെൻഡുകളുടെയും ക്രമീകരണങ്ങളുടെയും ഘടന മാറ്റാനും കഴിയും. 

ഈ സേവനം അതിന്റെ അവസ്ഥയെ Yandex ഡാറ്റാബേസിൽ സംഭരിക്കുന്നു, നിങ്ങൾക്ക് ഉടൻ ഉപയോഗിക്കാൻ കഴിയുന്ന ഒരു വിതരണം ചെയ്ത നിയന്ത്രിത ഡാറ്റാബേസ്. Yandex.Cloud-ൽ, ഞങ്ങൾ ഇതിനകം തന്നെ പറഞ്ഞു, നായ ഭക്ഷണം എന്ന ആശയം ബാധകമാണ്: ഞങ്ങൾ തന്നെ ഞങ്ങളുടെ സേവനങ്ങൾ ഉപയോഗിക്കുകയാണെങ്കിൽ, ഞങ്ങളുടെ ക്ലയന്റുകളും അവ ഉപയോഗിക്കുന്നതിൽ സന്തോഷിക്കും. Yandex ഡാറ്റാബേസ് അത്തരമൊരു ആശയം നടപ്പിലാക്കുന്നതിനുള്ള ഒരു ഉദാഹരണമാണ്. YDB-യിൽ ഞങ്ങളുടെ എല്ലാ ഡാറ്റയും ഞങ്ങൾ സംഭരിക്കുന്നു, ഡാറ്റാബേസ് പരിപാലിക്കുന്നതിനെക്കുറിച്ചും സ്കെയിൽ ചെയ്യുന്നതിനെക്കുറിച്ചും ഞങ്ങൾ ചിന്തിക്കേണ്ടതില്ല: ഈ പ്രശ്നങ്ങൾ ഞങ്ങൾക്ക് പരിഹരിച്ചിരിക്കുന്നു, ഞങ്ങൾ ഡാറ്റാബേസ് ഒരു സേവനമായി ഉപയോഗിക്കുന്നു.

ബാലൻസർ കൺട്രോളറിലേക്ക് മടങ്ങാം. ബാലൻസറിനെക്കുറിച്ചുള്ള വിവരങ്ങൾ സംരക്ഷിക്കുകയും ഹെൽത്ത് ചെക്ക് കൺട്രോളറിലേക്ക് വെർച്വൽ മെഷീന്റെ സന്നദ്ധത പരിശോധിക്കാൻ ഒരു ടാസ്ക് അയയ്ക്കുകയും ചെയ്യുക എന്നതാണ് ഇതിന്റെ ചുമതല.

ആരോഗ്യ പരിശോധന കൺട്രോളർ

ഇത് ചെക്ക് നിയമങ്ങൾ മാറ്റുന്നതിനുള്ള അഭ്യർത്ഥനകൾ സ്വീകരിക്കുന്നു, അവ YDB-യിൽ സംരക്ഷിക്കുന്നു, ഹെൽത്ത് ചെക്ക് നോഡുകൾക്കിടയിൽ ടാസ്‌ക്കുകൾ വിതരണം ചെയ്യുന്നു, ഫലങ്ങൾ സമാഹരിക്കുന്നു, അവ ഡാറ്റാബേസിൽ സംരക്ഷിച്ച് ലോഡ്ബാലൻസർ കൺട്രോളറിലേക്ക് അയയ്ക്കുന്നു. ഡാറ്റാ പ്ലെയിനിലെ ക്ലസ്റ്ററിന്റെ ഘടന ലോഡ്ബാലൻസർ-നോഡിലേക്ക് മാറ്റാൻ ഇത് ഒരു അഭ്യർത്ഥന അയയ്ക്കുന്നു, അത് ഞാൻ ചുവടെ ചർച്ച ചെയ്യും.

ആരോഗ്യ പരിശോധനകളെക്കുറിച്ച് കൂടുതൽ സംസാരിക്കാം. അവരെ പല ക്ലാസുകളായി തിരിക്കാം. ഓഡിറ്റിന് വ്യത്യസ്ത വിജയ മാനദണ്ഡങ്ങളുണ്ട്. TCP പരിശോധനകൾക്ക് ഒരു നിശ്ചിത സമയത്തിനുള്ളിൽ ഒരു കണക്ഷൻ വിജയകരമായി സ്ഥാപിക്കേണ്ടതുണ്ട്. HTTP പരിശോധനകൾക്ക് വിജയകരമായ കണക്ഷനും 200 സ്റ്റാറ്റസ് കോഡുള്ള പ്രതികരണവും ആവശ്യമാണ്.

കൂടാതെ, ചെക്കുകൾ പ്രവർത്തനത്തിന്റെ ക്ലാസിൽ വ്യത്യാസപ്പെട്ടിരിക്കുന്നു - അവ സജീവവും നിഷ്ക്രിയവുമാണ്. പ്രത്യേക നടപടികളൊന്നും എടുക്കാതെ ട്രാഫിക്കിൽ എന്താണ് സംഭവിക്കുന്നതെന്ന് നിഷ്ക്രിയ പരിശോധനകൾ നിരീക്ഷിക്കുന്നു. ഇത് L4-ൽ നന്നായി പ്രവർത്തിക്കുന്നില്ല, കാരണം ഇത് ഉയർന്ന തലത്തിലുള്ള പ്രോട്ടോക്കോളുകളുടെ യുക്തിയെ ആശ്രയിച്ചിരിക്കുന്നു: L4-ൽ പ്രവർത്തനം എത്ര സമയമെടുത്തു എന്നോ കണക്ഷൻ പൂർത്തീകരണം നല്ലതാണോ ചീത്തയാണോ എന്നോ ഉള്ള ഒരു വിവരവുമില്ല. സജീവ പരിശോധനകൾക്ക് ഓരോ സെർവർ സന്ദർഭത്തിലേക്കും അഭ്യർത്ഥനകൾ അയയ്‌ക്കാൻ ബാലൻസർ ആവശ്യപ്പെടുന്നു.

മിക്ക ലോഡ് ബാലൻസറുകളും ജീവനുള്ള പരിശോധനകൾ സ്വയം നടത്തുന്നു. ക്ലൗഡിൽ, സ്കേലബിളിറ്റി വർദ്ധിപ്പിക്കുന്നതിന് സിസ്റ്റത്തിന്റെ ഈ ഭാഗങ്ങൾ വേർതിരിക്കാൻ ഞങ്ങൾ തീരുമാനിച്ചു. സേവനത്തിലേക്കുള്ള ഹെൽത്ത് ചെക്ക് അഭ്യർത്ഥനകളുടെ എണ്ണം നിലനിർത്തിക്കൊണ്ട് ബാലൻസർമാരുടെ എണ്ണം വർദ്ധിപ്പിക്കാൻ ഈ സമീപനം ഞങ്ങളെ അനുവദിക്കും. വെവ്വേറെ ഹെൽത്ത് ചെക്ക് നോഡുകൾ ഉപയോഗിച്ചാണ് ചെക്കുകൾ നടത്തുന്നത്, അവയിലുടനീളം ചെക്ക് ടാർഗെറ്റുകൾ ഷാർഡ് ചെയ്യുകയും പകർപ്പെടുക്കുകയും ചെയ്യുന്നു. നിങ്ങൾക്ക് ഒരു ഹോസ്റ്റിൽ നിന്ന് പരിശോധന നടത്താൻ കഴിയില്ല, കാരണം അത് പരാജയപ്പെടാം. അപ്പോൾ അദ്ദേഹം പരിശോധിച്ച സംഭവങ്ങളുടെ അവസ്ഥ നമുക്ക് ലഭിക്കില്ല. കുറഞ്ഞത് മൂന്ന് ഹെൽത്ത് ചെക്ക് നോഡുകളിൽ നിന്നെങ്കിലും ഞങ്ങൾ ഏതെങ്കിലും സന്ദർഭങ്ങളിൽ പരിശോധന നടത്തുന്നു. സ്ഥിരമായ ഹാഷിംഗ് അൽഗോരിതങ്ങൾ ഉപയോഗിച്ച് നോഡുകൾക്കിടയിൽ ചെക്കുകളുടെ ഉദ്ദേശ്യങ്ങൾ ഞങ്ങൾ പങ്കിടുന്നു.

സന്തുലിതാവസ്ഥയും ആരോഗ്യ പരിശോധനയും വേർതിരിക്കുന്നത് പ്രശ്നങ്ങളിലേക്ക് നയിച്ചേക്കാം. ഹെൽത്ത്‌ചെക്ക് നോഡ് ബാലൻസറിനെ മറികടന്ന് (ഇത് നിലവിൽ ട്രാഫിക്ക് നൽകുന്നില്ല) ഉദാഹരണത്തിലേക്ക് അഭ്യർത്ഥനകൾ നടത്തുകയാണെങ്കിൽ, ഒരു വിചിത്രമായ സാഹചര്യം ഉടലെടുക്കുന്നു: ഉറവിടം സജീവമാണെന്ന് തോന്നുന്നു, പക്ഷേ ട്രാഫിക് അതിൽ എത്തിച്ചേരില്ല. ഞങ്ങൾ ഈ പ്രശ്നം ഈ രീതിയിൽ പരിഹരിക്കുന്നു: ബാലൻസറുകൾ മുഖേന ആരോഗ്യ പരിശോധന ട്രാഫിക് ആരംഭിക്കുമെന്ന് ഞങ്ങൾക്ക് ഉറപ്പുണ്ട്. മറ്റൊരു വിധത്തിൽ പറഞ്ഞാൽ, ക്ലയന്റുകളിൽ നിന്നും ആരോഗ്യ പരിശോധനകളിൽ നിന്നുമുള്ള ട്രാഫിക്കുള്ള പാക്കറ്റുകൾ നീക്കുന്നതിനുള്ള സ്കീം വളരെ കുറവാണ്: രണ്ട് സാഹചര്യങ്ങളിലും, പാക്കറ്റുകൾ ബാലൻസറുകളിൽ എത്തും, അത് ടാർഗെറ്റ് ഉറവിടങ്ങളിലേക്ക് എത്തിക്കും.

ക്ലയന്റുകൾ വിഐപിയോട് അഭ്യർത്ഥനകൾ നടത്തുന്നു എന്നതാണ് വ്യത്യാസം, അതേസമയം ആരോഗ്യ പരിശോധനകൾ ഓരോ വ്യക്തിഗത ആർഐപിക്കും അഭ്യർത്ഥനകൾ നടത്തുന്നു. രസകരമായ ഒരു പ്രശ്നം ഇവിടെ ഉയർന്നുവരുന്നു: ഗ്രേ ഐപി നെറ്റ്‌വർക്കുകളിൽ ഉറവിടങ്ങൾ സൃഷ്ടിക്കാൻ ഞങ്ങളുടെ ഉപയോക്താക്കൾക്ക് ഞങ്ങൾ അവസരം നൽകുന്നു. ബാലൻസർമാർക്ക് പിന്നിൽ തങ്ങളുടെ സേവനങ്ങൾ മറച്ചിരിക്കുന്ന രണ്ട് വ്യത്യസ്ത ക്ലൗഡ് ഉടമകൾ ഉണ്ടെന്ന് നമുക്ക് സങ്കൽപ്പിക്കാം. അവയിൽ ഓരോന്നിനും 10.0.0.1/24 സബ്‌നെറ്റിൽ ഒരേ വിലാസങ്ങളുള്ള ഉറവിടങ്ങളുണ്ട്. നിങ്ങൾക്ക് അവയെ എങ്ങനെയെങ്കിലും വേർതിരിച്ചറിയാൻ കഴിയണം, ഇവിടെ നിങ്ങൾ Yandex.Cloud വെർച്വൽ നെറ്റ്‌വർക്കിന്റെ ഘടനയിലേക്ക് കടക്കേണ്ടതുണ്ട്. എന്നതിൽ കൂടുതൽ വിശദാംശങ്ങൾ കണ്ടെത്തുന്നതാണ് നല്ലത് കുറിച്ച്:ക്ലൗഡ് ഇവന്റിൽ നിന്നുള്ള വീഡിയോ, നെറ്റ്‌വർക്ക് മൾട്ടി-ലേയേർഡ് ആയതും സബ്‌നെറ്റ് ഐഡി ഉപയോഗിച്ച് വേർതിരിച്ചറിയാൻ കഴിയുന്ന തുരങ്കങ്ങളുള്ളതും ഇപ്പോൾ ഞങ്ങൾക്ക് പ്രധാനമാണ്.

ഹെൽത്ത് ചെക്ക് നോഡുകൾ ക്വാസി-ഐപിവി6 വിലാസങ്ങൾ ഉപയോഗിച്ച് ബാലൻസറുകളെ ബന്ധപ്പെടുക. ഒരു IPv6 വിലാസവും ഉപയോക്തൃ സബ്‌നെറ്റ് ഐഡിയും ഉള്ള ഒരു IPv4 വിലാസമാണ് അർദ്ധവിലാസം. ട്രാഫിക് ബാലൻസറിലേക്ക് എത്തുന്നു, അത് അതിൽ നിന്ന് IPv4 റിസോഴ്സ് വിലാസം വേർതിരിച്ചെടുക്കുന്നു, IPv6-നെ IPv4 ഉപയോഗിച്ച് മാറ്റി പാക്കറ്റ് ഉപയോക്താവിന്റെ നെറ്റ്‌വർക്കിലേക്ക് അയയ്ക്കുന്നു.

റിവേഴ്സ് ട്രാഫിക്കും ഇതേ രീതിയിൽ തന്നെ പോകുന്നു: ഹെൽത്ത് ചെക്കർമാരുടെ ലക്ഷ്യസ്ഥാനം ഗ്രേ നെറ്റ്‌വർക്ക് ആണെന്ന് ബാലൻസർ കാണുകയും IPv4-നെ IPv6 ആക്കി മാറ്റുകയും ചെയ്യുന്നു.

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);
}

അതിനാൽ, ഹെൽത്ത് ചെക്കുകൾ VPP-യുമായി IPv6-ൽ സംസാരിക്കുന്നു, അത് അവയെ IPv4 ആക്കി മാറ്റുന്നു. ഗ്രാഫിലെ ഒരു നോഡാണ് ഇത് ചെയ്യുന്നത്, അതിനെ ഞങ്ങൾ അൽഗോരിതമിക് NAT എന്ന് വിളിക്കുന്നു. റിവേഴ്സ് ട്രാഫിക്കിനും (IPv6-ൽ നിന്ന് IPv4-ലേക്ക് പരിവർത്തനം ചെയ്യാനും) ഇതേ അൽഗോരിതം NAT നോഡ് ഉണ്ട്.

ബാലൻസർ ക്ലയന്റുകളിൽ നിന്നുള്ള നേരിട്ടുള്ള ട്രാഫിക് ഗ്രാഫ് നോഡുകളിലൂടെ കടന്നുപോകുന്നു, അത് ബാലൻസിങ് തന്നെ നിർവഹിക്കുന്നു. 

ആദ്യത്തെ നോഡ് സ്റ്റിക്കി സെഷനുകളാണ്. ഇത് ഹാഷ് സംഭരിക്കുന്നു 5-ട്യൂപ്പിൾ സ്ഥാപിതമായ സെഷനുകൾക്കായി. 5-tuple-ൽ വിവരങ്ങൾ കൈമാറുന്ന ക്ലയന്റിന്റെ വിലാസവും പോർട്ടും, ട്രാഫിക് സ്വീകരിക്കുന്നതിന് ലഭ്യമായ ഉറവിടങ്ങളുടെ വിലാസവും പോർട്ടുകളും, നെറ്റ്‌വർക്ക് പ്രോട്ടോക്കോളും ഉൾപ്പെടുന്നു. 

5-ട്യൂപ്പിൾ ഹാഷ്, തുടർന്നുള്ള സ്ഥിരതയുള്ള ഹാഷിംഗ് നോഡിൽ കുറച്ച് കണക്കുകൂട്ടൽ നടത്താൻ ഞങ്ങളെ സഹായിക്കുന്നു, അതുപോലെ തന്നെ ബാലൻസറിന് പിന്നിലെ റിസോഴ്സ് ലിസ്റ്റ് മാറ്റങ്ങൾ മികച്ച രീതിയിൽ കൈകാര്യം ചെയ്യുന്നു. ഒരു സെഷനും ഇല്ലാത്ത ഒരു പാക്കറ്റ് ബാലൻസറിൽ എത്തുമ്പോൾ, അത് സ്ഥിരമായ ഹാഷിംഗ് നോഡിലേക്ക് അയയ്ക്കും. സ്ഥിരമായ ഹാഷിംഗ് ഉപയോഗിച്ച് ബാലൻസിംഗ് സംഭവിക്കുന്നത് ഇവിടെയാണ്: ലഭ്യമായ "തത്സമയ" ഉറവിടങ്ങളുടെ പട്ടികയിൽ നിന്ന് ഞങ്ങൾ ഒരു ഉറവിടം തിരഞ്ഞെടുക്കുന്നു. അടുത്തതായി, പാക്കറ്റുകൾ NAT നോഡിലേക്ക് അയയ്‌ക്കുന്നു, അത് യഥാർത്ഥത്തിൽ ലക്ഷ്യസ്ഥാന വിലാസം മാറ്റി, ചെക്ക്‌സം വീണ്ടും കണക്കാക്കുന്നു. നിങ്ങൾക്ക് കാണാനാകുന്നതുപോലെ, ഞങ്ങൾ വിപിപിയുടെ നിയമങ്ങൾ പാലിക്കുന്നു - ഇഷ്ടപ്പെടാൻ ഇഷ്ടപ്പെടുന്നു, പ്രോസസർ കാഷെകളുടെ കാര്യക്ഷമത വർദ്ധിപ്പിക്കുന്നതിന് സമാന കണക്കുകൂട്ടലുകൾ ഗ്രൂപ്പുചെയ്യുന്നു.

സ്ഥിരമായ ഹാഷിംഗ്

എന്തുകൊണ്ടാണ് ഞങ്ങൾ ഇത് തിരഞ്ഞെടുത്തത്, അത് എന്താണ്? ആദ്യം, നമുക്ക് മുമ്പത്തെ ചുമതല പരിഗണിക്കാം - ലിസ്റ്റിൽ നിന്ന് ഒരു റിസോഴ്സ് തിരഞ്ഞെടുക്കൽ. 

പൊരുത്തമില്ലാത്ത ഹാഷിംഗ് ഉപയോഗിച്ച്, ഇൻകമിംഗ് പാക്കറ്റിന്റെ ഹാഷ് കണക്കാക്കുന്നു, കൂടാതെ ഈ ഹാഷിനെ റിസോഴ്സുകളുടെ എണ്ണം കൊണ്ട് ഹരിച്ചാൽ ബാക്കിയുള്ള ഒരു റിസോഴ്സ് പട്ടികയിൽ നിന്ന് തിരഞ്ഞെടുക്കുന്നു. ലിസ്റ്റ് മാറ്റമില്ലാതെ തുടരുന്നിടത്തോളം, ഈ സ്കീം നന്നായി പ്രവർത്തിക്കുന്നു: ഞങ്ങൾ എല്ലായ്പ്പോഴും ഒരേ 5-ട്യൂപ്പിൾ ഉള്ള പാക്കറ്റുകൾ ഒരേ ഉദാഹരണത്തിലേക്ക് അയയ്ക്കുന്നു. ഉദാഹരണത്തിന്, ചില ഉറവിടങ്ങൾ ആരോഗ്യ പരിശോധനകളോട് പ്രതികരിക്കുന്നത് നിർത്തിയാൽ, ഹാഷുകളുടെ ഒരു പ്രധാന ഭാഗത്തിന് ചോയ്‌സ് മാറും. ക്ലയന്റിൻറെ TCP കണക്ഷനുകൾ തകരും: മുമ്പ് ഇൻസ്റ്റൻസ് എയിൽ എത്തിയ ഒരു പാക്കറ്റ് ഈ പാക്കറ്റിന്റെ സെഷനുമായി പരിചിതമല്ലാത്ത ഇൻസ്‌റ്റൻസ് ബിയിൽ എത്താൻ തുടങ്ങിയേക്കാം.

സ്ഥിരമായ ഹാഷിംഗ് വിവരിച്ച പ്രശ്നം പരിഹരിക്കുന്നു. ഈ ആശയം വിശദീകരിക്കാനുള്ള എളുപ്പവഴി ഇതാണ്: നിങ്ങൾ ഹാഷ് വഴി വിഭവങ്ങൾ വിതരണം ചെയ്യുന്ന ഒരു റിംഗ് ഉണ്ടെന്ന് സങ്കൽപ്പിക്കുക (ഉദാഹരണത്തിന്, IP:port വഴി). ഒരു റിസോഴ്സ് തിരഞ്ഞെടുക്കുന്നത് ഒരു കോണിലൂടെ ചക്രം തിരിക്കുന്നു, അത് പാക്കറ്റിന്റെ ഹാഷ് നിർണ്ണയിക്കുന്നു.

വിഭവങ്ങളുടെ ഘടന മാറുമ്പോൾ ഇത് ട്രാഫിക് പുനർവിതരണം കുറയ്ക്കുന്നു. ഒരു ഉറവിടം ഇല്ലാതാക്കുന്നത് റിസോഴ്‌സ് സ്ഥിതിചെയ്യുന്ന സ്ഥിരമായ ഹാഷിംഗ് റിംഗിന്റെ ഭാഗത്തെ മാത്രമേ ബാധിക്കുകയുള്ളൂ. ഒരു റിസോഴ്‌സ് ചേർക്കുന്നത് വിതരണത്തെയും മാറ്റുന്നു, പക്ഷേ ഞങ്ങൾക്ക് ഒരു സ്റ്റിക്കി സെഷൻസ് നോഡ് ഉണ്ട്, ഇത് ഇതിനകം സ്ഥാപിച്ച സെഷനുകളെ പുതിയ ഉറവിടങ്ങളിലേക്ക് മാറ്റാതിരിക്കാൻ ഞങ്ങളെ അനുവദിക്കുന്നു.

ബാലൻസറും വിഭവങ്ങളും തമ്മിലുള്ള നേരിട്ടുള്ള ട്രാഫിക്കിന് എന്ത് സംഭവിക്കുമെന്ന് ഞങ്ങൾ നോക്കി. ഇനി റിട്ടേൺ ട്രാഫിക്ക് നോക്കാം. ഇത് ചെക്ക് ട്രാഫിക്കിന്റെ അതേ പാറ്റേൺ പിന്തുടരുന്നു - അൽഗോരിതമിക് NAT വഴി, അതായത്, ക്ലയന്റ് ട്രാഫിക്കിനായി റിവേഴ്സ് NAT 44 വഴിയും ഹെൽത്ത് ചെക്ക് ട്രാഫിക്കിനായി NAT 46 വഴിയും. ഞങ്ങൾ ഞങ്ങളുടെ സ്വന്തം സ്കീം പാലിക്കുന്നു: ഞങ്ങൾ ആരോഗ്യ പരിശോധന ട്രാഫിക്കും യഥാർത്ഥ ഉപയോക്തൃ ട്രാഫിക്കും ഏകീകരിക്കുന്നു.

ലോഡ്ബാലൻസർ-നോഡും അസംബിൾ ചെയ്ത ഘടകങ്ങളും

VPP-യിലെ ബാലൻസറുകളുടെയും ഉറവിടങ്ങളുടെയും ഘടന പ്രാദേശിക സേവനം റിപ്പോർട്ട് ചെയ്യുന്നു - ലോഡ്ബാലൻസർ-നോഡ്. ലോഡ്ബാലൻസർ-കൺട്രോളറിൽ നിന്നുള്ള ഇവന്റുകളുടെ സ്ട്രീമിലേക്ക് ഇത് സബ്‌സ്‌ക്രൈബുചെയ്യുന്നു, കൂടാതെ നിലവിലെ VPP നിലയും കൺട്രോളറിൽ നിന്ന് ലഭിച്ച ടാർഗെറ്റ് അവസ്ഥയും തമ്മിലുള്ള വ്യത്യാസം പ്ലോട്ട് ചെയ്യാൻ കഴിയും. ഞങ്ങൾക്ക് ഒരു അടച്ച സിസ്റ്റം ലഭിക്കുന്നു: API-ൽ നിന്നുള്ള ഇവന്റുകൾ ബാലൻസർ കൺട്രോളറിലേക്ക് വരുന്നു, അത് വിഭവങ്ങളുടെ "ലൈവ്നെസ്" പരിശോധിക്കാൻ ഹെൽത്ത് ചെക്ക് കൺട്രോളറിന് ചുമതലകൾ നൽകുന്നു. അതാകട്ടെ, ഹെൽത്ത് ചെക്ക്-നോഡിലേക്ക് ടാസ്‌ക്കുകൾ നൽകുകയും ഫലങ്ങൾ സമാഹരിക്കുകയും ചെയ്യുന്നു, അതിനുശേഷം അത് ബാലൻസർ കൺട്രോളറിലേക്ക് തിരികെ അയയ്ക്കുന്നു. ലോഡ്ബാലൻസർ-നോഡ് കൺട്രോളറിൽ നിന്നുള്ള ഇവന്റുകൾ സബ്‌സ്‌ക്രൈബ് ചെയ്യുകയും VPP-യുടെ അവസ്ഥ മാറ്റുകയും ചെയ്യുന്നു. അത്തരമൊരു സംവിധാനത്തിൽ, ഓരോ സേവനത്തിനും അയൽ സേവനങ്ങളെക്കുറിച്ച് ആവശ്യമുള്ളത് മാത്രമേ അറിയൂ. കണക്ഷനുകളുടെ എണ്ണം പരിമിതമാണ്, കൂടാതെ വ്യത്യസ്ത സെഗ്‌മെന്റുകൾ സ്വതന്ത്രമായി പ്രവർത്തിപ്പിക്കാനും സ്കെയിൽ ചെയ്യാനും ഞങ്ങൾക്ക് കഴിവുണ്ട്.

എന്തൊക്കെ പ്രശ്നങ്ങൾ ഒഴിവാക്കി?

കൺട്രോൾ പ്ലെയിനിലെ ഞങ്ങളുടെ എല്ലാ സേവനങ്ങളും Go- ൽ എഴുതിയതാണ്, കൂടാതെ നല്ല സ്കെയിലിംഗും വിശ്വാസ്യതയും ഉള്ള സവിശേഷതകളുണ്ട്. വിതരണ സംവിധാനങ്ങൾ നിർമ്മിക്കുന്നതിന് Go- യ്ക്ക് നിരവധി ഓപ്പൺ സോഴ്‌സ് ലൈബ്രറികളുണ്ട്. ഞങ്ങൾ GRPC സജീവമായി ഉപയോഗിക്കുന്നു, എല്ലാ ഘടകങ്ങളിലും സേവന കണ്ടെത്തലിന്റെ ഒരു ഓപ്പൺ സോഴ്‌സ് നടപ്പിലാക്കൽ അടങ്ങിയിരിക്കുന്നു - ഞങ്ങളുടെ സേവനങ്ങൾ പരസ്പരം പ്രകടനം നിരീക്ഷിക്കുന്നു, അവയുടെ ഘടന ചലനാത്മകമായി മാറ്റാൻ കഴിയും, കൂടാതെ ഞങ്ങൾ ഇത് GRPC ബാലൻസുമായി ബന്ധപ്പെടുത്തി. അളവുകൾക്കായി, ഞങ്ങൾ ഒരു ഓപ്പൺ സോഴ്സ് സൊല്യൂഷനും ഉപയോഗിക്കുന്നു. ഡാറ്റാ പ്ലെയിനിൽ, ഞങ്ങൾക്ക് മാന്യമായ പ്രകടനവും ഒരു വലിയ റിസോഴ്‌സ് റിസർവും ലഭിച്ചു: ഇരുമ്പ് നെറ്റ്‌വർക്ക് കാർഡിനേക്കാൾ ഒരു വിപിപിയുടെ പ്രകടനത്തെ ആശ്രയിക്കാൻ കഴിയുന്ന ഒരു സ്റ്റാൻഡ് കൂട്ടിച്ചേർക്കുന്നത് വളരെ ബുദ്ധിമുട്ടാണ്.

പ്രശ്നങ്ങളും പരിഹാരങ്ങളും

എന്താണ് അത്ര നന്നായി പ്രവർത്തിക്കാത്തത്? ഗോയ്ക്ക് ഓട്ടോമാറ്റിക് മെമ്മറി മാനേജ്‌മെന്റ് ഉണ്ട്, പക്ഷേ മെമ്മറി ലീക്കുകൾ ഇപ്പോഴും സംഭവിക്കുന്നു. അവ കൈകാര്യം ചെയ്യാനുള്ള ഏറ്റവും എളുപ്പ മാർഗം ഗൊറൂട്ടീനുകൾ പ്രവർത്തിപ്പിക്കുകയും അവ അവസാനിപ്പിക്കാൻ ഓർമ്മിക്കുകയും ചെയ്യുക എന്നതാണ്. ടേക്ക്അവേ: നിങ്ങളുടെ Go പ്രോഗ്രാമുകളുടെ മെമ്മറി ഉപഭോഗം കാണുക. പലപ്പോഴും ഒരു നല്ല സൂചകം ഗോറൂട്ടീനുകളുടെ എണ്ണമാണ്. ഈ സ്റ്റോറിയിൽ ഒരു പ്ലസ് ഉണ്ട്: Go-യിൽ റൺടൈം ഡാറ്റ ലഭിക്കുന്നത് എളുപ്പമാണ് - മെമ്മറി ഉപഭോഗം, റൺ ചെയ്യുന്ന ഗോറൂട്ടീനുകളുടെ എണ്ണം, കൂടാതെ മറ്റ് നിരവധി പാരാമീറ്ററുകൾ.

കൂടാതെ, ഫങ്ഷണൽ ടെസ്റ്റുകൾക്കുള്ള ഏറ്റവും മികച്ച ചോയിസ് ഗോ ആയിരിക്കണമെന്നില്ല. അവ തികച്ചും വാചാലമാണ്, കൂടാതെ "സിഐയിൽ എല്ലാം ഒരു ബാച്ചിൽ പ്രവർത്തിപ്പിക്കുക" എന്ന സ്റ്റാൻഡേർഡ് സമീപനം അവർക്ക് വളരെ അനുയോജ്യമല്ല. ഫങ്ഷണൽ ടെസ്റ്റുകൾ കൂടുതൽ റിസോഴ്സ് ആവശ്യപ്പെടുന്നതും യഥാർത്ഥ സമയപരിധിക്ക് കാരണമാകുന്നു എന്നതാണ് വസ്തുത. ഇക്കാരണത്താൽ, സിപിയു യൂണിറ്റ് ടെസ്റ്റുകളുടെ തിരക്കിലായതിനാൽ ടെസ്റ്റുകൾ പരാജയപ്പെടാം. ഉപസംഹാരം: സാധ്യമെങ്കിൽ, യൂണിറ്റ് ടെസ്റ്റുകളിൽ നിന്ന് പ്രത്യേകം "ഹെവി" ടെസ്റ്റുകൾ നടത്തുക. 

മൈക്രോസർവീസ് ഇവന്റ് ആർക്കിടെക്ചർ ഒരു മോണോലിത്തിനെക്കാൾ സങ്കീർണ്ണമാണ്: ഡസൻ കണക്കിന് വ്യത്യസ്ത മെഷീനുകളിൽ ലോഗുകൾ ശേഖരിക്കുന്നത് വളരെ സൗകര്യപ്രദമല്ല. ഉപസംഹാരം: നിങ്ങൾ മൈക്രോസർവീസുകൾ നിർമ്മിക്കുകയാണെങ്കിൽ, ട്രെയ്‌സിംഗിനെക്കുറിച്ച് ഉടൻ ചിന്തിക്കുക.

ഞങ്ങളുടെ പദ്ധതികൾ

ഞങ്ങൾ ഒരു ഇന്റേണൽ ബാലൻസറും ഒരു IPv6 ബാലൻസറും സമാരംഭിക്കും, Kubernetes സ്‌ക്രിപ്‌റ്റുകൾക്ക് പിന്തുണ ചേർക്കും, ഞങ്ങളുടെ സേവനങ്ങൾ പങ്കിടുന്നത് തുടരും (നിലവിൽ ഹെൽത്ത്‌ചെക്ക്-നോഡും ഹെൽത്ത്‌ചെക്ക്-ctrl-ഉം മാത്രമേ ഷാർഡ് ചെയ്തിട്ടുള്ളൂ), പുതിയ ഹെൽത്ത് ചെക്കുകൾ ചേർക്കുക, കൂടാതെ പരിശോധനകളുടെ സ്‌മാർട്ട് അഗ്രഗേഷൻ നടപ്പിലാക്കുകയും ചെയ്യും. ഞങ്ങളുടെ സേവനങ്ങൾ കൂടുതൽ സ്വതന്ത്രമാക്കുന്നതിനുള്ള സാധ്യത ഞങ്ങൾ പരിഗണിക്കുന്നു - അതുവഴി അവർ പരസ്പരം നേരിട്ട് ആശയവിനിമയം നടത്തുന്നില്ല, മറിച്ച് ഒരു സന്ദേശ ക്യൂ ഉപയോഗിച്ചാണ്. ഒരു SQS-അനുയോജ്യമായ സേവനം അടുത്തിടെ ക്ലൗഡിൽ പ്രത്യക്ഷപ്പെട്ടു Yandex സന്ദേശ ക്യൂ.

അടുത്തിടെ, Yandex ലോഡ് ബാലൻസറിന്റെ പൊതു റിലീസ് നടന്നു. പര്യവേക്ഷണം ചെയ്യുക പ്രമാണീകരണം സേവനത്തിലേക്ക്, നിങ്ങൾക്ക് സൗകര്യപ്രദമായ രീതിയിൽ ബാലൻസറുകൾ നിയന്ത്രിക്കുകയും നിങ്ങളുടെ പ്രോജക്റ്റുകളുടെ തെറ്റ് സഹിഷ്ണുത വർദ്ധിപ്പിക്കുകയും ചെയ്യുക!

അവലംബം: www.habr.com