വൺ-ക്ലൗഡ് - ഒഡ്നോക്ലാസ്നിക്കിയിലെ ഡാറ്റാ സെന്റർ ലെവൽ ഒഎസ്

അയ്യോ, ജനമേ! എൻ്റെ പേര് ഒലെഗ് അനസ്താസിയേവ്, ഞാൻ പ്ലാറ്റ്ഫോം ടീമിൽ ഒഡ്നോക്ലാസ്നിക്കിയിൽ ജോലി ചെയ്യുന്നു. എന്നെ കൂടാതെ, ഒഡ്‌നോക്ലാസ്‌നിക്കിയിൽ ധാരാളം ഹാർഡ്‌വെയറുകൾ പ്രവർത്തിക്കുന്നു. 500 ആയിരത്തിലധികം സെർവറുകളുള്ള 8 റാക്കുകളുള്ള നാല് ഡാറ്റാ സെൻ്ററുകൾ ഞങ്ങൾക്ക് ഉണ്ട്. ഒരു പ്രത്യേക ഘട്ടത്തിൽ, ഒരു പുതിയ മാനേജുമെൻ്റ് സിസ്റ്റം അവതരിപ്പിക്കുന്നത് ഉപകരണങ്ങൾ കൂടുതൽ കാര്യക്ഷമമായി ലോഡുചെയ്യാനും ആക്‌സസ് മാനേജ്‌മെൻ്റ് സുഗമമാക്കാനും കമ്പ്യൂട്ടിംഗ് ഉറവിടങ്ങളുടെ (വീണ്ടും) വിതരണം ഓട്ടോമേറ്റ് ചെയ്യാനും പുതിയ സേവനങ്ങളുടെ സമാരംഭം വേഗത്തിലാക്കാനും പ്രതികരണങ്ങൾ വേഗത്തിലാക്കാനും ഞങ്ങളെ അനുവദിക്കുമെന്ന് ഞങ്ങൾ മനസ്സിലാക്കി. വലിയ തോതിലുള്ള അപകടങ്ങളിലേക്ക്.

അതിൽ എന്താണ് വന്നത്?

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

ഉപയോക്തൃ അഭ്യർത്ഥനകൾ പ്രധാന പോർട്ടലിൻ്റെ മുൻവശത്തും സ്വീകരിക്കുന്നു www.ok.ru, കൂടാതെ മറ്റുള്ളവയിൽ, ഉദാഹരണത്തിന് സംഗീത API മുന്നണികളിൽ. ബിസിനസ്സ് ലോജിക് പ്രോസസ്സ് ചെയ്യുന്നതിന്, അവർ ആപ്ലിക്കേഷൻ സെർവറിനെ വിളിക്കുന്നു, അത് അഭ്യർത്ഥന പ്രോസസ്സ് ചെയ്യുമ്പോൾ ആവശ്യമായ പ്രത്യേക മൈക്രോസർവീസുകളെ വിളിക്കുന്നു - ഒരു ഗ്രാഫ് (സോഷ്യൽ കണക്ഷനുകളുടെ ഗ്രാഫ്), ഉപയോക്തൃ കാഷെ (ഉപയോക്തൃ പ്രൊഫൈലുകളുടെ കാഷെ) മുതലായവ.

ഈ സേവനങ്ങളിൽ ഓരോന്നും നിരവധി മെഷീനുകളിൽ വിന്യസിച്ചിരിക്കുന്നു, അവയിൽ ഓരോന്നിനും മൊഡ്യൂളുകളുടെ പ്രവർത്തനത്തിനും അവയുടെ പ്രവർത്തനത്തിനും സാങ്കേതിക വികസനത്തിനും ഉത്തരവാദിത്തമുള്ള ഡെവലപ്പർമാർ ഉണ്ട്. ഈ സേവനങ്ങളെല്ലാം ഹാർഡ്‌വെയർ സെർവറുകളിൽ പ്രവർത്തിക്കുന്നു, അടുത്തിടെ വരെ ഞങ്ങൾ ഓരോ സെർവറിനും കൃത്യമായി ഒരു ടാസ്‌ക് സമാരംഭിച്ചു, അതായത് ഇത് ഒരു നിർദ്ദിഷ്ട ടാസ്‌ക്കിനായി പ്രത്യേകം തയ്യാറാക്കിയതാണ്.

എന്തുകൊണ്ടാണത്? ഈ സമീപനത്തിന് നിരവധി ഗുണങ്ങളുണ്ടായിരുന്നു:

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

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

ഈ സമീപനം ഞങ്ങളെ ചെയ്യാൻ അനുവദിച്ചു പ്രത്യേക ഇരുമ്പ് കോൺഫിഗറേഷനുകൾ ഈ സെർവറിൽ പ്രവർത്തിക്കുന്ന ഒരു ടാസ്ക്കിനായി. ടാസ്‌ക് വലിയ അളവിലുള്ള ഡാറ്റ സംഭരിക്കുന്നുവെങ്കിൽ, ഞങ്ങൾ 4 ഡിസ്കുകളുള്ള ഒരു ചേസിസുള്ള 38U സെർവർ ഉപയോഗിക്കുന്നു. ടാസ്ക് പൂർണ്ണമായും കമ്പ്യൂട്ടേഷണൽ ആണെങ്കിൽ, ഞങ്ങൾക്ക് വിലകുറഞ്ഞ 1U സെർവർ വാങ്ങാം. ഇത് കണക്കുകൂട്ടൽ കാര്യക്ഷമമാണ്. മറ്റ് കാര്യങ്ങളിൽ, ഒരു സൗഹൃദ സോഷ്യൽ നെറ്റ്‌വർക്കുമായി താരതമ്യപ്പെടുത്താവുന്ന ലോഡുള്ള നാലിരട്ടി കുറഞ്ഞ മെഷീനുകൾ ഉപയോഗിക്കാൻ ഈ സമീപനം ഞങ്ങളെ അനുവദിക്കുന്നു.

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

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

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

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

വ്യക്തമായും, നിങ്ങൾ ടാസ്‌ക്കുകൾ കണ്ടെയ്‌നറുകളിലോ വെർച്വൽ മെഷീനുകളിലോ പ്രവർത്തിപ്പിക്കേണ്ടതുണ്ട്. ഞങ്ങളുടെ മിക്കവാറും എല്ലാ ജോലികളും ഒരു OS (ലിനക്സ്) ന് കീഴിൽ പ്രവർത്തിക്കുന്നതിനാൽ അല്ലെങ്കിൽ അതിനായി പൊരുത്തപ്പെടുന്നതിനാൽ, ഞങ്ങൾ പല ഓപ്പറേറ്റിംഗ് സിസ്റ്റങ്ങളെ പിന്തുണയ്ക്കേണ്ടതില്ല. അതനുസരിച്ച്, വിർച്ച്വലൈസേഷൻ ആവശ്യമില്ല; അധിക ഓവർഹെഡ് കാരണം, കണ്ടെയ്നറൈസേഷനേക്കാൾ കാര്യക്ഷമത കുറവായിരിക്കും.

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

കൂടാതെ, ഡോക്കറിലെ ഒരു റെഡിമെയ്ഡ് രജിസ്ട്രിയും ഇമേജ് ടാഗിംഗും ഞങ്ങൾക്ക് പതിപ്പ് ചെയ്യുന്നതിനും നിർമ്മാണത്തിലേക്ക് കോഡ് വിതരണം ചെയ്യുന്നതിനുമുള്ള റെഡിമെയ്ഡ് പ്രിമിറ്റീവുകൾ നൽകുന്നു.

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

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

നിങ്ങൾക്ക് 8 ആയിരം സെർവറുകളും 8-16 ആയിരം കണ്ടെയ്‌നറുകളും ഉള്ളപ്പോൾ കണ്ടെയ്‌നറുകൾ സ്വമേധയാ വിതരണം ചെയ്യുന്നത് ഒരു ഓപ്ഷനല്ല.

കൂടാതെ, ഡെവലപ്പർമാർക്ക് റിസോഴ്‌സ് അലോക്കേഷനിൽ കൂടുതൽ സ്വാതന്ത്ര്യം നൽകാനും ഞങ്ങൾ ആഗ്രഹിച്ചു, അതിലൂടെ അവർക്ക് ഒരു അഡ്മിനിസ്ട്രേറ്ററുടെ സഹായമില്ലാതെ തന്നെ പ്രൊഡക്ഷനിൽ അവരുടെ സേവനങ്ങൾ ഹോസ്റ്റുചെയ്യാനാകും. അതേ സമയം, ചില ചെറിയ സേവനങ്ങൾ ഞങ്ങളുടെ ഡാറ്റാ സെൻ്ററുകളുടെ എല്ലാ വിഭവങ്ങളും ഉപയോഗിക്കാതിരിക്കാൻ നിയന്ത്രണം നിലനിർത്താൻ ഞങ്ങൾ ആഗ്രഹിച്ചു.

വ്യക്തമായും, ഇത് യാന്ത്രികമായി ചെയ്യുന്ന ഒരു നിയന്ത്രണ പാളി ഞങ്ങൾക്ക് ആവശ്യമാണ്.

അതിനാൽ എല്ലാ ആർക്കിടെക്റ്റുകളും ആരാധിക്കുന്ന ലളിതവും മനസ്സിലാക്കാവുന്നതുമായ ഒരു ചിത്രത്തിലേക്ക് ഞങ്ങൾ എത്തി: മൂന്ന് ചതുരങ്ങൾ.

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

രസ്പ്രെദെലെനിഎ രെസുര്സൊവ്

ഇപ്പോൾ പല കൂട്ടാളികൾക്കും കൂടുതൽ സങ്കീർണ്ണമായ റിസോഴ്സ് അലോക്കേഷൻ്റെ പ്രശ്നം നോക്കാം.

ഒരു ക്ലൗഡിലെ ഒരു കമ്പ്യൂട്ടിംഗ് ഉറവിടം ഇതാണ്:

• ഒരു നിർദ്ദിഷ്‌ട ടാസ്‌ക്ക് ഉപയോഗിക്കുന്ന പ്രോസസ്സർ പവറിൻ്റെ അളവ്.
• ടാസ്ക്കിന് ലഭ്യമായ മെമ്മറിയുടെ അളവ്.
• നെറ്റ്‌വർക്ക് ട്രാഫിക്. ഓരോ മിനിയൻമാർക്കും പരിമിതമായ ബാൻഡ്‌വിഡ്ത്ത് ഉള്ള ഒരു പ്രത്യേക നെറ്റ്‌വർക്ക് ഇൻ്റർഫേസ് ഉണ്ട്, അതിനാൽ നെറ്റ്‌വർക്കിലൂടെ അവർ കൈമാറുന്ന ഡാറ്റയുടെ അളവ് കണക്കിലെടുക്കാതെ ടാസ്‌ക്കുകൾ വിതരണം ചെയ്യുന്നത് അസാധ്യമാണ്.
• ഡിസ്കുകൾ. കൂടാതെ, വ്യക്തമായും, ഈ ടാസ്ക്കുകൾക്കുള്ള സ്ഥലത്തേക്ക്, ഞങ്ങൾ ഡിസ്കിൻ്റെ തരം അനുവദിക്കും: HDD അല്ലെങ്കിൽ SSD. ഡിസ്കുകൾക്ക് സെക്കൻഡിൽ പരിമിതമായ എണ്ണം അഭ്യർത്ഥനകൾ നൽകാൻ കഴിയും - IOPS. അതിനാൽ, ഒരു ഡിസ്കിന് കൈകാര്യം ചെയ്യാൻ കഴിയുന്നതിനേക്കാൾ കൂടുതൽ ഐഒപിഎസ് സൃഷ്‌ടിക്കുന്ന ടാസ്‌ക്കുകൾക്കായി, ഞങ്ങൾ “സ്പിൻഡിലുകളും” അനുവദിക്കും - അതായത്, ടാസ്‌ക്കിനായി മാത്രം റിസർവ് ചെയ്യേണ്ട ഡിസ്ക് ഉപകരണങ്ങൾ.

പിന്നീട് ചില സേവനങ്ങൾക്കായി, ഉദാഹരണത്തിന് ഉപയോക്തൃ-കാഷെക്കായി, ഉപഭോഗം ചെയ്ത ഉറവിടങ്ങൾ നമുക്ക് ഈ രീതിയിൽ രേഖപ്പെടുത്താം: 400 പ്രോസസർ കോറുകൾ, 2,5 TB മെമ്മറി, 50 Gbit/s ട്രാഫിക്ക്, രണ്ട് ദിശകളിലും 6 TB HDD സ്പേസ്, 100 സ്പിൻഡിലുകളിൽ സ്ഥിതിചെയ്യുന്നു. അല്ലെങ്കിൽ ഇതുപോലുള്ള കൂടുതൽ പരിചിതമായ രൂപത്തിൽ:

alloc:
    cpu: 400
    mem: 2500
    lan_in: 50g
    lan_out: 50g
    hdd:100x6T

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

ഘടകങ്ങളുടെ ഇടപെടലിൻ്റെ വളരെ ലളിതമാക്കിയ ഞങ്ങളുടെ ഡയഗ്രാമിലേക്ക് മടങ്ങുകയും കൂടുതൽ വിശദാംശങ്ങളോടെ അത് വീണ്ടും വരയ്ക്കുകയും ചെയ്യാം - ഇതുപോലെ:

എന്താണ് നിങ്ങളുടെ ശ്രദ്ധ ആകർഷിക്കുന്നത്:

• വെബ് ഫ്രണ്ടൻഡും സംഗീതവും ഒരേ ആപ്ലിക്കേഷൻ സെർവറിൻ്റെ ഒറ്റപ്പെട്ട ക്ലസ്റ്ററുകൾ ഉപയോഗിക്കുന്നു.
• ഈ ക്ലസ്റ്ററുകൾ ഉൾപ്പെടുന്ന ലോജിക്കൽ ലെയറുകൾ നമുക്ക് വേർതിരിച്ചറിയാൻ കഴിയും: ഫ്രണ്ടുകൾ, കാഷെകൾ, ഡാറ്റ സ്റ്റോറേജ്, മാനേജ്മെൻ്റ് ലെയർ.
• മുൻഭാഗം വൈവിധ്യപൂർണ്ണമാണ്; അതിൽ വ്യത്യസ്ത പ്രവർത്തന ഉപസിസ്റ്റങ്ങൾ അടങ്ങിയിരിക്കുന്നു.
• ഡാറ്റ കാഷെ ചെയ്യുന്ന ഉപസിസ്റ്റമിലുടനീളം കാഷെകൾ ചിതറിക്കിടക്കാനും കഴിയും.

നമുക്ക് ചിത്രം വീണ്ടും വരയ്ക്കാം:

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

അധിക വരികൾ നീക്കം ചെയ്യുന്നതിലൂടെ, ഞങ്ങളുടെ ചിത്രത്തിലെ ഓരോ നോഡും ഒരു പരന്ന രൂപത്തിൽ എഴുതാം: group1.web.front, api.music.front, user-cache.cache.

ഇങ്ങനെയാണ് നമ്മൾ "ശ്രേണീകൃത ക്യൂ" എന്ന ആശയത്തിലേക്ക് വരുന്നത്. ഇതിന് "group1.web.front" എന്നൊരു പേരുണ്ട്. വിഭവങ്ങൾക്കും ഉപയോക്തൃ അവകാശങ്ങൾക്കുമുള്ള ഒരു ക്വാട്ട അതിന് നിയുക്തമാക്കിയിരിക്കുന്നു. DevOps-ൽ നിന്നുള്ള വ്യക്തിക്ക് ക്യൂവിലേക്ക് ഒരു സേവനം അയയ്‌ക്കാനുള്ള അവകാശം ഞങ്ങൾ നൽകും, അത്തരമൊരു ജീവനക്കാരന് ക്യൂവിൽ എന്തെങ്കിലും സമാരംഭിക്കാൻ കഴിയും, കൂടാതെ OpsDev-ൽ നിന്നുള്ള വ്യക്തിക്ക് അഡ്മിൻ അവകാശങ്ങൾ ഉണ്ടായിരിക്കും, ഇപ്പോൾ അയാൾക്ക് ക്യൂ നിയന്ത്രിക്കാനും അവിടെ ആളുകളെ നിയോഗിക്കാനും കഴിയും, ഈ ആളുകൾക്ക് അവകാശങ്ങൾ നൽകുക തുടങ്ങിയവ. ഈ ക്യൂവിൽ പ്രവർത്തിക്കുന്ന സേവനങ്ങൾ ക്യൂവിൻ്റെ ക്വാട്ടയിൽ പ്രവർത്തിക്കും. എല്ലാ സേവനങ്ങളും ഒരേസമയം എക്സിക്യൂട്ട് ചെയ്യാൻ ക്യൂവിൻ്റെ കമ്പ്യൂട്ടിംഗ് ക്വാട്ട പര്യാപ്തമല്ലെങ്കിൽ, അവ തുടർച്ചയായി നടപ്പിലാക്കും, അങ്ങനെ ക്യൂ തന്നെ രൂപപ്പെടും.

സേവനങ്ങൾ നമുക്ക് കൂടുതൽ വിശദമായി പരിശോധിക്കാം. ഒരു സേവനത്തിന് പൂർണ്ണ യോഗ്യതയുള്ള ഒരു പേരുണ്ട്, അതിൽ എല്ലായ്പ്പോഴും ക്യൂവിൻ്റെ പേര് ഉൾപ്പെടുന്നു. അപ്പോൾ ഫ്രണ്ട് വെബ് സേവനത്തിന് പേരുണ്ടാകും ശരി-web.group1.web.front. അത് ആക്‌സസ് ചെയ്യുന്ന ആപ്ലിക്കേഷൻ സെർവർ സേവനത്തെ വിളിക്കും ok-app.group1.web.front. ഓരോ സേവനത്തിനും ഒരു മാനിഫെസ്റ്റ് ഉണ്ട്, അത് നിർദ്ദിഷ്ട മെഷീനുകളിൽ സ്ഥാപിക്കുന്നതിന് ആവശ്യമായ എല്ലാ വിവരങ്ങളും വ്യക്തമാക്കുന്നു: ഈ ടാസ്‌ക് എത്ര വിഭവങ്ങൾ ഉപയോഗിക്കുന്നു, അതിന് എന്ത് കോൺഫിഗറേഷൻ ആവശ്യമാണ്, എത്ര പകർപ്പുകൾ ഉണ്ടായിരിക്കണം, ഈ സേവനത്തിൻ്റെ പരാജയങ്ങൾ കൈകാര്യം ചെയ്യുന്നതിനുള്ള സവിശേഷതകൾ. സേവനം നേരിട്ട് മെഷീനുകളിൽ സ്ഥാപിച്ച ശേഷം, അതിൻ്റെ സംഭവങ്ങൾ ദൃശ്യമാകും. അവ അവ്യക്തമായി നാമകരണം ചെയ്യപ്പെടുന്നു - ഉദാഹരണ നമ്പറും സേവന നാമവും: 1.ok-web.group1.web.front, 2.ok-web.group1.web.front, …

ഇത് വളരെ സൗകര്യപ്രദമാണ്: പ്രവർത്തിക്കുന്ന കണ്ടെയ്നറിൻ്റെ പേര് മാത്രം നോക്കിയാൽ, നമുക്ക് ഉടനടി ഒരുപാട് കണ്ടെത്താനാകും.

ഈ സംഭവങ്ങൾ യഥാർത്ഥത്തിൽ എന്താണ് ചെയ്യുന്നതെന്ന് ഇപ്പോൾ നമുക്ക് സൂക്ഷ്മമായി പരിശോധിക്കാം: ടാസ്ക്കുകൾ.

ടാസ്ക് ഐസൊലേഷൻ ക്ലാസുകൾ

ശരിയിലെ എല്ലാ ജോലികളും (കൂടാതെ, മിക്കവാറും എല്ലായിടത്തും) ഗ്രൂപ്പുകളായി തിരിക്കാം:

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

അത്തരം ജോലികൾ വിഭവങ്ങൾ എങ്ങനെ ഉപയോഗിക്കുന്നു എന്ന് നോക്കാം, ഉദാഹരണത്തിന്, സെൻട്രൽ പ്രോസസർ.

ചെറിയ കാലതാമസം ജോലികൾ. അത്തരമൊരു ടാസ്‌ക്കിന് ഇതുപോലുള്ള ഒരു സിപിയു ഉപഭോഗ പാറ്റേൺ ഉണ്ടായിരിക്കും:

പ്രോസസ്സിംഗിനായി ഉപയോക്താവിൽ നിന്നുള്ള ഒരു അഭ്യർത്ഥന ലഭിച്ചു, ടാസ്ക് ലഭ്യമായ എല്ലാ സിപിയു കോറുകളും ഉപയോഗിക്കാൻ തുടങ്ങുന്നു, അത് പ്രോസസ്സ് ചെയ്യുന്നു, ഒരു പ്രതികരണം നൽകുന്നു, അടുത്ത അഭ്യർത്ഥനയ്ക്കായി കാത്തിരിക്കുകയും നിർത്തുകയും ചെയ്യുന്നു. അടുത്ത അഭ്യർത്ഥന എത്തി - വീണ്ടും ഞങ്ങൾ അവിടെയുള്ളതെല്ലാം തിരഞ്ഞെടുത്തു, അത് കണക്കാക്കി, അടുത്തതിനായി കാത്തിരിക്കുകയാണ്.

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

alloc: cpu = 4 (max)

ഞങ്ങൾക്ക് 16 കോറുകളുള്ള ഒരു മിനിയൻ മെഷീൻ ഉണ്ടെങ്കിൽ, അത്തരം നാല് ജോലികൾ കൃത്യമായി അതിൽ സ്ഥാപിക്കാൻ കഴിയും. അത്തരം ജോലികളുടെ ശരാശരി പ്രോസസ്സർ ഉപഭോഗം പലപ്പോഴും വളരെ കുറവാണെന്ന് ഞങ്ങൾ പ്രത്യേകം ശ്രദ്ധിക്കുന്നു - ഇത് വ്യക്തമാണ്, കാരണം ടാസ്‌ക് ഒരു അഭ്യർത്ഥനയ്ക്കായി കാത്തിരിക്കുകയും ഒന്നും ചെയ്യാതിരിക്കുകയും ചെയ്യുന്നു.

കണക്കുകൂട്ടൽ ജോലികൾ. അവരുടെ പാറ്റേൺ അല്പം വ്യത്യസ്തമായിരിക്കും:

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

alloc: cpu = [1,*)

"ദയവായി ഒരു ഫ്രീ കോറെങ്കിലും ഉള്ള ഒരു മിനിയനിൽ ഇത് സ്ഥാപിക്കുക, തുടർന്ന് ഉള്ളത്രയും അത് എല്ലാം വിഴുങ്ങും."

ചെറിയ കാലതാമസമുള്ള ജോലികളേക്കാൾ ഇവിടെ ഉപയോഗത്തിൻ്റെ കാര്യക്ഷമത ഇതിനകം തന്നെ മികച്ചതാണ്. എന്നാൽ നിങ്ങൾ ഒരു മിനിയന് മെഷീനിൽ രണ്ട് തരത്തിലുള്ള ജോലികളും സംയോജിപ്പിച്ച് അതിൻ്റെ വിഭവങ്ങൾ എവിടെയായിരുന്നാലും വിതരണം ചെയ്താൽ നേട്ടം വളരെ വലുതായിരിക്കും. ഒരു ചെറിയ കാലതാമസമുള്ള ഒരു ടാസ്‌ക്കിന് ഒരു പ്രോസസ്സർ ആവശ്യമായി വരുമ്പോൾ, അത് ഉടനടി സ്വീകരിക്കുന്നു, കൂടാതെ ഉറവിടങ്ങൾ ആവശ്യമില്ലാത്തപ്പോൾ, അവ കമ്പ്യൂട്ടേഷണൽ ടാസ്‌ക്കിലേക്ക് മാറ്റുന്നു, അതായത് ഇതുപോലുള്ള ഒന്ന്:

എന്നാൽ അത് എങ്ങനെ ചെയ്യാം?

ആദ്യം, നമുക്ക് പ്രോഡും അതിൻ്റെ അലോക്കും നോക്കാം: cpu = 4. നമുക്ക് നാല് കോറുകൾ റിസർവ് ചെയ്യേണ്ടതുണ്ട്. ഡോക്കർ റണ്ണിൽ ഇത് രണ്ട് തരത്തിൽ ചെയ്യാം:

• ഓപ്ഷൻ ഉപയോഗിച്ച് --cpuset=1-4, അതായത് ടാസ്ക്കിലേക്ക് മെഷീനിൽ നാല് നിർദ്ദിഷ്ട കോറുകൾ അനുവദിക്കുക.
• ഉപയോഗിക്കുക --cpuquota=400_000 --cpuperiod=100_000, പ്രോസസ്സർ സമയത്തിനായി ഒരു ക്വാട്ട നിയോഗിക്കുക, അതായത് ഓരോ 100 ms തൽസമയവും ടാസ്‌ക് 400 ms-ൽ കൂടുതൽ പ്രോസസ്സർ സമയം ചെലവഴിക്കുന്നില്ലെന്ന് സൂചിപ്പിക്കുക. ഒരേ നാല് കോറുകൾ ലഭിക്കും.

എന്നാൽ ഈ രീതികളിൽ ഏതാണ് അനുയോജ്യം?

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

ഏറ്റവും കുറഞ്ഞ കോറുകളെ അടിസ്ഥാനമാക്കി ഡോക്കറിൽ റിസർവേഷൻ എങ്ങനെ നടത്താമെന്ന് നമുക്ക് നോക്കാം. ബാച്ച് ടാസ്‌ക്കുകൾക്കുള്ള ക്വാട്ട ഇനി ബാധകമല്ല, കാരണം പരമാവധി പരിമിതപ്പെടുത്തേണ്ട ആവശ്യമില്ല, മിനിമം ഗ്യാരണ്ടി നൽകിയാൽ മതി. ഇവിടെ ഓപ്ഷൻ നന്നായി യോജിക്കുന്നു docker run --cpushares.

ഒരു ബാച്ചിന് കുറഞ്ഞത് ഒരു കോറിനെങ്കിലും ഗ്യാരണ്ടി ആവശ്യമാണെങ്കിൽ, ഞങ്ങൾ സൂചിപ്പിക്കുമെന്ന് ഞങ്ങൾ സമ്മതിച്ചു --cpushares=1024, കൂടാതെ കുറഞ്ഞത് രണ്ട് കോറുകളെങ്കിലും ഉണ്ടെങ്കിൽ, ഞങ്ങൾ സൂചിപ്പിക്കുന്നു --cpushares=2048. Cpu ഷെയറുകൾ ആവശ്യത്തിന് ഉള്ളിടത്തോളം പ്രോസസ്സർ സമയത്തിൻ്റെ വിതരണത്തിൽ ഒരു തരത്തിലും ഇടപെടുന്നില്ല. അതിനാൽ, പ്രോഡ് നിലവിൽ അതിൻ്റെ നാല് കോറുകളും ഉപയോഗിക്കുന്നില്ലെങ്കിൽ, ബാച്ച് ടാസ്‌ക്കുകൾ പരിമിതപ്പെടുത്തുന്ന ഒന്നുമില്ല, കൂടാതെ അവർക്ക് അധിക പ്രോസസ്സർ സമയം ഉപയോഗിക്കാനും കഴിയും. എന്നാൽ പ്രോസസറുകളുടെ കുറവുള്ള സാഹചര്യത്തിൽ, പ്രോഡ് അതിൻ്റെ നാല് കോറുകളും കഴിച്ച് അതിൻ്റെ ക്വാട്ടയിൽ എത്തിയാൽ, ശേഷിക്കുന്ന പ്രോസസ്സർ സമയം cpushares-ന് ആനുപാതികമായി വിഭജിക്കപ്പെടും, അതായത് മൂന്ന് ഫ്രീ കോറുകൾ ഉള്ള സാഹചര്യത്തിൽ, ഒന്ന് 1024 cpushares ഉള്ള ഒരു ടാസ്‌ക്കിന് നൽകി, ശേഷിക്കുന്ന രണ്ടെണ്ണം 2048 cpushares ഉള്ള ഒരു ടാസ്‌ക്കിലേക്ക് നൽകും.

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

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

one.nio.os.Proc.sched_setscheduler( pid, Proc.SCHED_IDLE )

നിങ്ങൾ ജാവയിൽ പ്രോഗ്രാം ചെയ്യുന്നില്ലെങ്കിലും, chrt കമാൻഡ് ഉപയോഗിച്ച് ഇതുതന്നെ ചെയ്യാം:

chrt -i 0 $pid

വ്യക്തതയ്ക്കായി നമ്മുടെ എല്ലാ ഐസൊലേഷൻ ലെവലുകളും ഒരു പട്ടികയിലേക്ക് സംഗ്രഹിക്കാം:

ഇൻസുലേഷൻ ക്ലാസ്
അലോക്ക് ഉദാഹരണം
ഡോക്കർ റൺ ഓപ്ഷനുകൾ
sched_setscheduler chrt*

പ്രൊഡ
cpu = 4
--cpuquota=400000 --cpuperiod=100000
SCHED_OTHER

ബാച്ച്
Cpu = [1, *)
--cpushares=1024
SCHED_BATCH

നിഷ്ക്രിയം
Cpu= [2, *)
--cpushares=2048
SCHED_IDLE

*നിങ്ങൾ ഒരു കണ്ടെയ്‌നറിനുള്ളിൽ നിന്നാണ് chrt ചെയ്യുന്നതെങ്കിൽ, നിങ്ങൾക്ക് sys_nice കഴിവ് ആവശ്യമായി വന്നേക്കാം, കാരണം കണ്ടെയ്‌നർ ആരംഭിക്കുമ്പോൾ സ്ഥിരസ്ഥിതിയായി ഡോക്കർ ഈ കഴിവ് നീക്കം ചെയ്യുന്നു.

എന്നാൽ ടാസ്‌ക്കുകൾ പ്രോസസ്സർ മാത്രമല്ല, ട്രാഫിക്കും ഉപയോഗിക്കുന്നു, ഇത് പ്രോസസർ ഉറവിടങ്ങളുടെ തെറ്റായ അലോക്കേഷനേക്കാൾ കൂടുതൽ നെറ്റ്‌വർക്ക് ടാസ്‌ക്കിൻ്റെ ലേറ്റൻസിയെ ബാധിക്കുന്നു. അതിനാൽ, ട്രാഫിക്കിന് സമാനമായ ചിത്രം ലഭിക്കാൻ ഞങ്ങൾ സ്വാഭാവികമായും ആഗ്രഹിക്കുന്നു. അതായത്, ഒരു പ്രോഡ് ടാസ്‌ക് ചില പാക്കറ്റുകൾ നെറ്റ്‌വർക്കിലേക്ക് അയയ്‌ക്കുമ്പോൾ, ഞങ്ങൾ പരമാവധി വേഗത പരിമിതപ്പെടുത്തുന്നു (സൂത്രവാക്യം അലോക്ക്: ലാൻ=[*,500mbps) ), ഏത് ഉൽപ്പന്നം ഉപയോഗിച്ചാണ് ഇത് ചെയ്യാൻ കഴിയുക. ബാച്ചിനായി ഞങ്ങൾ ഏറ്റവും കുറഞ്ഞ ത്രൂപുട്ട് മാത്രമേ ഗ്യാരൻ്റി നൽകൂ, പക്ഷേ പരമാവധി പരിമിതപ്പെടുത്തരുത് (സൂത്രവാക്യം അനുവദിക്കുക: ലാൻ=[10Mbps,*) ) ഈ സാഹചര്യത്തിൽ, ബാച്ച് ടാസ്‌ക്കുകളേക്കാൾ പ്രോഡ് ട്രാഫിക്കിന് മുൻഗണന ലഭിക്കണം.
ഇവിടെ ഡോക്കറിന് നമുക്ക് ഉപയോഗിക്കാനാകുന്ന പ്രാകൃതങ്ങളൊന്നും ഇല്ല. പക്ഷേ, അത് നമ്മുടെ സഹായത്തിനെത്തുന്നു ലിനക്സ് ട്രാഫിക് നിയന്ത്രണം. അച്ചടക്കത്തിൻ്റെ സഹായത്തോടെ ആഗ്രഹിച്ച ഫലം നേടാൻ ഞങ്ങൾക്ക് കഴിഞ്ഞു ഹൈറാർക്കിക്കൽ ഫെയർ സർവീസ് കർവ്. അതിൻ്റെ സഹായത്തോടെ, ഞങ്ങൾ രണ്ട് തരം ട്രാഫിക്കുകളെ വേർതിരിക്കുന്നു: ഉയർന്ന മുൻഗണനയുള്ള ഉൽപ്പന്നവും കുറഞ്ഞ മുൻഗണനയുള്ള ബാച്ച്/നിഷ്ക്രിയവും. തൽഫലമായി, ഔട്ട്‌ഗോയിംഗ് ട്രാഫിക്കിനുള്ള കോൺഫിഗറേഷൻ ഇതുപോലെയാണ്:

ഇവിടെ 1:0 എന്നത് hsfc അച്ചടക്കത്തിൻ്റെ "റൂട്ട് qdisc" ആണ്; 1:1 - ആകെ ബാൻഡ്‌വിഡ്ത്ത് പരിധി 8 Gbit/s ഉള്ള hsfc ചൈൽഡ് ക്ലാസ്, അതിന് കീഴിൽ എല്ലാ കണ്ടെയ്‌നറുകളുടെയും ചൈൽഡ് ക്ലാസുകൾ സ്ഥാപിച്ചിരിക്കുന്നു; 1:2 - hsfc ചൈൽഡ് ക്ലാസ് എല്ലാ ബാച്ച്, നിഷ്‌ക്രിയ ടാസ്‌ക്കുകൾക്കും "ഡൈനാമിക്" പരിധിയുള്ളതാണ്, അത് ചുവടെ ചർച്ചചെയ്യുന്നു. ശേഷിക്കുന്ന എച്ച്എസ്എഫ്സി ചൈൽഡ് ക്ലാസുകൾ അവയുടെ മാനിഫെസ്റ്റുകൾക്ക് അനുയോജ്യമായ പരിധികളുള്ള പ്രോഡ് കണ്ടെയ്‌നറുകൾക്ക് വേണ്ടിയുള്ള സമർപ്പിത ക്ലാസുകളാണ് - 450, 400 Mbit/s. ഓരോ hsfc ക്ലാസിനും ലിനക്സ് കേർണൽ പതിപ്പിനെ ആശ്രയിച്ച്, ട്രാഫിക് പൊട്ടിത്തെറിയിൽ പാക്കറ്റ് നഷ്ടപ്പെടാതിരിക്കാൻ, ഒരു qdisc ക്യൂ fq അല്ലെങ്കിൽ fq_codel നൽകിയിരിക്കുന്നു.

സാധാരണഗതിയിൽ, ഔട്ട്‌ഗോയിംഗ് ട്രാഫിക്കിന് മാത്രം മുൻഗണന നൽകുന്നതാണ് ടിസി വിഭാഗങ്ങൾ. എന്നാൽ ഇൻകമിംഗ് ട്രാഫിക്കിനും മുൻഗണന നൽകാൻ ഞങ്ങൾ ആഗ്രഹിക്കുന്നു - എല്ലാത്തിനുമുപരി, ചില ബാച്ച് ടാസ്‌ക്കുകൾക്ക് മുഴുവൻ ഇൻകമിംഗ് ചാനലും എളുപ്പത്തിൽ തിരഞ്ഞെടുക്കാനാകും, ഉദാഹരണത്തിന്, മാപ്പിനായുള്ള ഇൻപുട്ട് ഡാറ്റയുടെ ഒരു വലിയ ബാച്ച് & കുറയ്ക്കുക. ഇതിനായി ഞങ്ങൾ മൊഡ്യൂൾ ഉപയോഗിക്കുന്നു ifb, ഇത് ഓരോ നെറ്റ്‌വർക്ക് ഇൻ്റർഫേസിനും ഒരു ifbX വെർച്വൽ ഇൻ്റർഫേസ് സൃഷ്‌ടിക്കുകയും ഇൻ്റർഫേസിൽ നിന്ന് ഇൻകമിംഗ് ട്രാഫിക്കിനെ ifbX-ലെ ഔട്ട്‌ഗോയിംഗ് ട്രാഫിക്കിലേക്ക് റീഡയറക്‌ട് ചെയ്യുകയും ചെയ്യുന്നു. കൂടാതെ, ifbX-ന്, ഔട്ട്‌ഗോയിംഗ് ട്രാഫിക് നിയന്ത്രിക്കാൻ ഒരേ വിഭാഗങ്ങളെല്ലാം പ്രവർത്തിക്കുന്നു, ഇതിനായി hsfc കോൺഫിഗറേഷൻ വളരെ സമാനമായിരിക്കും:

പരീക്ഷണങ്ങൾക്കിടയിൽ, 1:2 ക്ലാസ് നോൺ-പ്രോറിറ്റി ബാച്ച്/നിഷ്‌ക്രിയ ട്രാഫിക്ക് മിനിയൻ മെഷീനുകളിൽ ഒരു നിശ്ചിത ഫ്രീ ലെയിനിൽ കൂടുതലായി പരിമിതപ്പെടുത്തിയിരിക്കുമ്പോൾ hsfc മികച്ച ഫലങ്ങൾ കാണിക്കുന്നുവെന്ന് ഞങ്ങൾ കണ്ടെത്തി. അല്ലാത്തപക്ഷം, മുൻഗണനയില്ലാത്ത ട്രാഫിക് പ്രോഡ് ടാസ്‌ക്കുകളുടെ കാലതാമസത്തെ വളരെയധികം സ്വാധീനിക്കുന്നു. ഓരോ സെക്കൻഡിലും നിലവിലെ സൗജന്യ ബാൻഡ്‌വിഡ്ത്ത് തുക miniond നിർണ്ണയിക്കുന്നു, ഒരു നിശ്ചിത മിനിയൻ്റെ എല്ലാ പ്രോഡ്-ടാസ്കുകളുടെയും ശരാശരി ട്രാഫിക് ഉപഭോഗം അളക്കുന്നു നെറ്റ്‌വർക്ക് ഇൻ്റർഫേസ് ബാൻഡ്‌വിഡ്‌ത്തിൽ നിന്ന് അത് കുറയ്ക്കുന്നു ഒരു ചെറിയ മാർജിൻ ഉപയോഗിച്ച്, അതായത്.

ഇൻകമിംഗ്, ഔട്ട്ഗോയിംഗ് ട്രാഫിക്കിനായി ബാൻഡുകളെ സ്വതന്ത്രമായി നിർവചിച്ചിരിക്കുന്നു. കൂടാതെ പുതിയ മൂല്യങ്ങൾ അനുസരിച്ച്, miniond മുൻഗണനേതര ക്ലാസ് പരിധി 1:2 പുനഃക്രമീകരിക്കുന്നു.

അങ്ങനെ, ഞങ്ങൾ മൂന്ന് ഐസൊലേഷൻ ക്ലാസുകളും നടപ്പിലാക്കി: പ്രോഡ്, ബാച്ച്, ഐഡിൽ. ഈ ക്ലാസുകൾ ടാസ്ക്കുകളുടെ പ്രകടന സവിശേഷതകളെ വളരെയധികം സ്വാധീനിക്കുന്നു. അതിനാൽ, ഈ ആട്രിബ്യൂട്ട് ശ്രേണിയുടെ മുകളിൽ സ്ഥാപിക്കാൻ ഞങ്ങൾ തീരുമാനിച്ചു, അതിനാൽ ശ്രേണിപരമായ ക്യൂവിൻ്റെ പേര് നോക്കുമ്പോൾ ഞങ്ങൾ എന്താണ് കൈകാര്യം ചെയ്യുന്നതെന്ന് ഉടനടി വ്യക്തമാകും:

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

അധിക ലൈനുകൾ വീണ്ടും നീക്കം ചെയ്‌താൽ, പൂർണ്ണ സേവന നാമത്തിൻ്റെ അവസാനത്തിൽ ടാസ്‌ക് ഐസൊലേഷൻ ക്ലാസ് ചേർത്ത് ഞങ്ങളുടെ സേവന നാമങ്ങൾ ആകർഷകമായി എഴുതാം: web.front.prod, catalog.music.batch, ട്രാൻസ്ഫോർമർ.സംഗീതം.നിഷ്ക്രിയം.

ഇപ്പോൾ, സേവനത്തിൻ്റെ പേര് നോക്കുമ്പോൾ, അത് എന്ത് പ്രവർത്തനമാണ് നിർവഹിക്കുന്നതെന്ന് മാത്രമല്ല, അതിൻ്റെ ഐസൊലേഷൻ ക്ലാസും ഞങ്ങൾ മനസ്സിലാക്കുന്നു, അതായത് അതിൻ്റെ വിമർശനം മുതലായവ.

എല്ലാം മികച്ചതാണ്, പക്ഷേ ഒരു കയ്പേറിയ സത്യമുണ്ട്. ഒരു മെഷീനിൽ പ്രവർത്തിക്കുന്ന ജോലികൾ പൂർണ്ണമായും ഒറ്റപ്പെടുത്തുക അസാധ്യമാണ്.

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

ആധുനിക നെറ്റ്‌വർക്ക് കാർഡുകൾക്ക് പാക്കറ്റുകളുടെ ആന്തരിക ക്യൂ ഉള്ളതിനാൽ ട്രാഫിക് ഒറ്റപ്പെടുത്തുന്നത് കൂടുതൽ ബുദ്ധിമുട്ടാണ്. ബാച്ച് ടാസ്‌ക്കിൽ നിന്നുള്ള പാക്കറ്റ് ആദ്യം അവിടെയെത്തുകയാണെങ്കിൽ, അത് കേബിളിലൂടെ ആദ്യം കൈമാറ്റം ചെയ്യപ്പെടും, അതിനെക്കുറിച്ച് ഒന്നും ചെയ്യാൻ കഴിയില്ല.

കൂടാതെ, TCP ട്രാഫിക്കിന് മുൻഗണന നൽകുന്ന പ്രശ്നം പരിഹരിക്കാൻ മാത്രമേ ഞങ്ങൾക്ക് ഇതുവരെ കഴിഞ്ഞിട്ടുള്ളൂ: Hsfc സമീപനം UDP-യിൽ പ്രവർത്തിക്കുന്നില്ല. ടിസിപി ട്രാഫിക്കിൻ്റെ കാര്യത്തിൽ പോലും, ബാച്ച് ടാസ്‌ക് വളരെയധികം ട്രാഫിക് സൃഷ്‌ടിക്കുന്നുവെങ്കിൽ, ഇത് പ്രോഡ് ടാസ്‌ക്കിൻ്റെ കാലതാമസത്തിൽ ഏകദേശം 10% വർദ്ധനവ് നൽകുന്നു.

തെറ്റ് സഹിഷ്ണുത

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

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

രണ്ടാമത്തെ പ്രശ്നം കണ്ടെയ്നർ വീഴുന്നതാണ്. ഇവിടെ പുനരാരംഭിക്കുന്ന നയങ്ങൾ ഞങ്ങളെ രക്ഷിക്കുന്നു, എല്ലാവർക്കും അവരെ അറിയാം, ഡോക്കർ തന്നെ ഒരു മികച്ച ജോലി ചെയ്യുന്നു. മിക്കവാറും എല്ലാ പ്രോഡ് ടാസ്‌ക്കുകൾക്കും എപ്പോഴും പുനരാരംഭിക്കുന്ന നയമുണ്ട്. ചിലപ്പോൾ ഞങ്ങൾ ബാച്ച് ടാസ്‌ക്കുകൾക്കോ ​​അല്ലെങ്കിൽ പ്രോഡ് കണ്ടെയ്‌നറുകൾ ഡീബഗ്ഗിംഗ് ചെയ്യാനോ on_failure ഉപയോഗിക്കുന്നു.

ഒരു മുഴുവൻ മിനിയനും ലഭ്യമല്ലെങ്കിൽ നിങ്ങൾക്ക് എന്തുചെയ്യാൻ കഴിയും?

വ്യക്തമായും, മറ്റൊരു മെഷീനിൽ കണ്ടെയ്നർ പ്രവർത്തിപ്പിക്കുക. കണ്ടെയ്‌നറിന് നൽകിയിരിക്കുന്ന IP വിലാസത്തിന് (ഇ) എന്ത് സംഭവിക്കും എന്നതാണ് ഇവിടെ രസകരമായ ഭാഗം.

ഈ കണ്ടെയ്‌നറുകൾ പ്രവർത്തിക്കുന്ന മിനിയന് മെഷീനുകളുടെ അതേ ഐപി വിലാസങ്ങൾ നമുക്ക് കണ്ടെയ്‌നറുകൾക്ക് നൽകാം. തുടർന്ന്, മറ്റൊരു മെഷീനിൽ കണ്ടെയ്‌നർ സമാരംഭിക്കുമ്പോൾ, അതിൻ്റെ IP വിലാസം മാറുന്നു, കൂടാതെ എല്ലാ ക്ലയൻ്റുകളും കണ്ടെയ്നർ നീങ്ങിയതായി മനസ്സിലാക്കണം, ഇപ്പോൾ അവർ മറ്റൊരു വിലാസത്തിലേക്ക് പോകേണ്ടതുണ്ട്, അതിന് ഒരു പ്രത്യേക സേവന കണ്ടെത്തൽ സേവനം ആവശ്യമാണ്.

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

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

ഒരു-ക്ലൗഡിൽ, IP കണ്ടെയ്‌നറിനെ പിന്തുടരുന്നു, അതായത് ഓരോ ടാസ്‌ക് സംഭവത്തിനും അതിൻ്റേതായ IP വിലാസമുണ്ട്. ഈ വിലാസം "സ്റ്റാറ്റിക്" ആണ്: സേവനം ആദ്യം ക്ലൗഡിലേക്ക് അയയ്‌ക്കുമ്പോൾ ഓരോ സന്ദർഭത്തിനും ഇത് നിയോഗിക്കപ്പെടുന്നു. ഒരു സേവനത്തിന് അതിൻ്റെ ജീവിതത്തിൽ വ്യത്യസ്‌ത എണ്ണം സംഭവങ്ങളുണ്ടെങ്കിൽ, അവസാനം അതിന് പരമാവധി സന്ദർഭങ്ങൾ ഉള്ളത്ര ഐപി വിലാസങ്ങൾ നൽകും.

തുടർന്ന്, ഈ വിലാസങ്ങൾ മാറില്ല: അവ ഒരിക്കൽ നിയുക്തമാക്കുകയും ഉൽപാദനത്തിലെ സേവനത്തിൻ്റെ ജീവിതത്തിലുടനീളം നിലനിൽക്കുകയും ചെയ്യുന്നു. IP വിലാസങ്ങൾ നെറ്റ്‌വർക്കിലുടനീളം കണ്ടെയ്‌നറുകളെ പിന്തുടരുന്നു. കണ്ടെയ്നർ മറ്റൊരു മിനിയനിലേക്ക് മാറ്റുകയാണെങ്കിൽ, വിലാസം അതിനെ പിന്തുടരും.

അതിനാൽ, ഒരു സേവന നാമം അതിൻ്റെ ഐപി വിലാസങ്ങളുടെ പട്ടികയിലേക്ക് മാറ്റുന്നത് വളരെ അപൂർവമായി മാത്രമേ മാറുന്നുള്ളൂ. ലേഖനത്തിൻ്റെ തുടക്കത്തിൽ ഞങ്ങൾ പരാമർശിച്ച സേവന സംഭവങ്ങളുടെ പേരുകൾ നിങ്ങൾ വീണ്ടും നോക്കുകയാണെങ്കിൽ (1.ok-web.group1.web.front.prod, 2.ok-web.group1.web.front.prod, …), അവ DNS-ൽ ഉപയോഗിക്കുന്ന FQDN-കളോട് സാമ്യമുള്ളതായി ഞങ്ങൾ ശ്രദ്ധിക്കും. അത് ശരിയാണ്, സേവന സംഭവങ്ങളുടെ പേരുകൾ അവയുടെ IP വിലാസങ്ങളിലേക്ക് മാപ്പ് ചെയ്യുന്നതിന്, ഞങ്ങൾ DNS പ്രോട്ടോക്കോൾ ഉപയോഗിക്കുന്നു. മാത്രമല്ല, ഈ ഡിഎൻഎസ് എല്ലാ കണ്ടെയ്‌നറുകളുടെയും റിസർവ് ചെയ്‌ത എല്ലാ ഐപി വിലാസങ്ങളും നൽകുന്നു - പ്രവർത്തിക്കുന്നതും നിർത്തിയതും (മൂന്ന് പകർപ്പുകൾ ഉപയോഗിച്ചിട്ടുണ്ടെന്ന് പറയാം, ഞങ്ങൾക്ക് അഞ്ച് വിലാസങ്ങൾ അവിടെ റിസർവ് ചെയ്‌തിരിക്കുന്നു - അഞ്ചെണ്ണവും തിരികെ നൽകും). ക്ലയൻ്റുകൾ, ഈ വിവരം ലഭിച്ച ശേഷം, എല്ലാ അഞ്ച് പകർപ്പുകളുമായും ഒരു കണക്ഷൻ സ്ഥാപിക്കാൻ ശ്രമിക്കും - അങ്ങനെ പ്രവർത്തിക്കുന്നവ നിർണ്ണയിക്കുക. ലഭ്യത നിർണ്ണയിക്കുന്നതിനുള്ള ഈ ഓപ്ഷൻ കൂടുതൽ വിശ്വസനീയമാണ്; ഇതിൽ ഡിഎൻഎസോ സേവന കണ്ടെത്തലോ ഉൾപ്പെടുന്നില്ല, അതായത് ഈ സിസ്റ്റങ്ങളുടെ വിവരങ്ങളുടെ പ്രസക്തിയും തെറ്റ് സഹിഷ്ണുതയും ഉറപ്പാക്കുന്നതിൽ ബുദ്ധിമുട്ടുള്ള പ്രശ്നങ്ങളൊന്നും ഇല്ല. മാത്രമല്ല, മുഴുവൻ പോർട്ടലിൻ്റെ പ്രവർത്തനവും ആശ്രയിക്കുന്ന നിർണായക സേവനങ്ങളിൽ, ഞങ്ങൾക്ക് DNS ഉപയോഗിക്കാൻ കഴിയില്ല, പക്ഷേ കോൺഫിഗറേഷനിൽ IP വിലാസങ്ങൾ നൽകുക.

കണ്ടെയ്‌നറുകൾക്ക് പിന്നിൽ അത്തരം ഐപി കൈമാറ്റം നടപ്പിലാക്കുന്നത് നിസ്സാരമല്ല - ഇനിപ്പറയുന്ന ഉദാഹരണം ഉപയോഗിച്ച് ഇത് എങ്ങനെ പ്രവർത്തിക്കുന്നുവെന്ന് ഞങ്ങൾ നോക്കാം:

വൺ-ക്ലൗഡ് മാസ്റ്റർ minion M1-ന് റൺ ചെയ്യാൻ കമാൻഡ് നൽകുന്നു എന്ന് നമുക്ക് പറയാം 1.ok-web.group1.web.front.prod വിലാസം 1.1.1.1 ഉപയോഗിച്ച്. ഒരു മിനിയനിൽ പ്രവർത്തിക്കുന്നു പക്ഷി, ഈ വിലാസം പ്രത്യേക സെർവറുകളിലേക്ക് പരസ്യം ചെയ്യുന്നു റൂട്ട് റിഫ്ലക്ടർ. പിന്നീടുള്ളവർക്ക് നെറ്റ്‌വർക്ക് ഹാർഡ്‌വെയറുമായി ഒരു BGP സെഷൻ ഉണ്ട്, അതിലേക്ക് M1.1.1.1-ലെ വിലാസം 1 എന്നതിൻ്റെ റൂട്ട് വിവർത്തനം ചെയ്യപ്പെടുന്നു. ലിനക്സ് ഉപയോഗിച്ച് M1 കണ്ടെയ്‌നറിനുള്ളിൽ പാക്കറ്റുകൾ റൂട്ട് ചെയ്യുന്നു. മൂന്ന് റൂട്ട് റിഫ്ലക്ടർ സെർവറുകളുണ്ട്, കാരണം ഇത് ഒരു ക്ലൗഡ് ഇൻഫ്രാസ്ട്രക്ചറിൻ്റെ വളരെ നിർണായകമായ ഭാഗമാണ് - അവയില്ലാതെ, ഒരു ക്ലൗഡിലെ നെറ്റ്‌വർക്ക് പ്രവർത്തിക്കില്ല. ഒരേ സമയം മൂന്നും പരാജയപ്പെടാനുള്ള സാധ്യത കുറയ്ക്കുന്നതിന്, സാധ്യമെങ്കിൽ ഡാറ്റാ സെൻ്ററിൻ്റെ വിവിധ മുറികളിൽ സ്ഥിതി ചെയ്യുന്ന വ്യത്യസ്ത റാക്കുകളിൽ ഞങ്ങൾ അവയെ സ്ഥാപിക്കുന്നു.

വൺ-ക്ലൗഡ് മാസ്റ്ററും M1 മിനിയനും തമ്മിലുള്ള ബന്ധം നഷ്ടപ്പെട്ടുവെന്ന് നമുക്ക് അനുമാനിക്കാം. M1 പൂർണ്ണമായും പരാജയപ്പെട്ടുവെന്ന അനുമാനത്തിലാണ് വൺ-ക്ലൗഡ് മാസ്റ്റർ ഇപ്പോൾ പ്രവർത്തിക്കുന്നത്. അതായത്, അത് ലോഞ്ച് ചെയ്യാനുള്ള കമാൻഡ് M2 മിനിയന് നൽകും web.group1.web.front.prod അതേ വിലാസത്തിൽ 1.1.1.1. ഇപ്പോൾ നമുക്ക് നെറ്റ്‌വർക്കിൽ 1.1.1.1-ന് രണ്ട് വൈരുദ്ധ്യ റൂട്ടുകളുണ്ട്: M1-ലും M2-ലും. അത്തരം പൊരുത്തക്കേടുകൾ പരിഹരിക്കുന്നതിന്, ഞങ്ങൾ മൾട്ടി എക്സിറ്റ് ഡിസ്ക്രിമിനേറ്റർ ഉപയോഗിക്കുന്നു, അത് BGP പ്രഖ്യാപനത്തിൽ വ്യക്തമാക്കിയിരിക്കുന്നു. പരസ്യപ്പെടുത്തിയ റൂട്ടിൻ്റെ ഭാരം കാണിക്കുന്ന നമ്പറാണിത്. വൈരുദ്ധ്യമുള്ള റൂട്ടുകളിൽ, കുറഞ്ഞ MED മൂല്യമുള്ള റൂട്ട് തിരഞ്ഞെടുക്കും. കണ്ടെയ്‌നർ ഐപി വിലാസങ്ങളുടെ അവിഭാജ്യ ഘടകമായി വൺ-ക്ലൗഡ് മാസ്റ്റർ MED-യെ പിന്തുണയ്ക്കുന്നു. ആദ്യമായി, മതിയായ വലിയ MED = 1 ഉപയോഗിച്ചാണ് വിലാസം എഴുതിയിരിക്കുന്നത്. അത്തരമൊരു അടിയന്തര കണ്ടെയ്നർ കൈമാറ്റത്തിൻ്റെ സാഹചര്യത്തിൽ, മാസ്റ്റർ MED കുറയ്ക്കുന്നു, കൂടാതെ M000 = വിലാസം 000 എന്ന വിലാസത്തിൽ പരസ്യം ചെയ്യുന്നതിനുള്ള കമാൻഡ് ഇതിനകം തന്നെ M2 സ്വീകരിക്കും. 1.1.1.1. M999-ൽ പ്രവർത്തിക്കുന്ന ഉദാഹരണം ഈ സാഹചര്യത്തിൽ ഒരു ബന്ധവുമില്ലാതെ നിലനിൽക്കും, കൂടാതെ മാസ്റ്ററുമായുള്ള ബന്ധം പുനഃസ്ഥാപിക്കുന്നതുവരെ, പഴയ ഒരു ടേക്ക് പോലെ അവനെ നിർത്തുന്നത് വരെ അവൻ്റെ ഭാവി ഞങ്ങൾക്ക് താൽപ്പര്യമില്ല.

അപകടങ്ങൾ

എല്ലാ ഡാറ്റാ സെൻ്റർ മാനേജ്മെൻ്റ് സിസ്റ്റങ്ങളും ചെറിയ പരാജയങ്ങൾ സ്വീകാര്യമായി കൈകാര്യം ചെയ്യുന്നു. കണ്ടെയ്നർ ഓവർഫ്ലോ മിക്കവാറും എല്ലായിടത്തും സാധാരണമാണ്.

ഒരു ഡാറ്റാ സെൻ്ററിലെ ഒന്നോ അതിലധികമോ മുറികളിലെ വൈദ്യുതി തകരാർ പോലെയുള്ള അടിയന്തര സാഹചര്യം എങ്ങനെ കൈകാര്യം ചെയ്യുന്നുവെന്ന് നോക്കാം.

ഒരു ഡാറ്റ സെൻ്റർ മാനേജ്മെൻ്റ് സിസ്റ്റത്തിന് ഒരു അപകടം എന്താണ് അർത്ഥമാക്കുന്നത്? ഒന്നാമതായി, ഇത് പല മെഷീനുകളുടെയും വൻതോതിലുള്ള ഒറ്റത്തവണ പരാജയമാണ്, കൂടാതെ നിയന്ത്രണ സംവിധാനത്തിന് ഒരേ സമയം ധാരാളം കണ്ടെയ്നറുകൾ മൈഗ്രേറ്റ് ചെയ്യേണ്ടതുണ്ട്. ദുരന്തം വളരെ വലിയ തോതിലുള്ളതാണെങ്കിൽ, എല്ലാ ജോലികളും മറ്റ് മിനിയൻമാർക്ക് വീണ്ടും അനുവദിക്കാൻ കഴിയില്ല, കാരണം ഡാറ്റാ സെൻ്ററിൻ്റെ റിസോഴ്സ് കപ്പാസിറ്റി ലോഡിൻ്റെ 100% താഴെയായി കുറയുന്നു.

പലപ്പോഴും അപകടങ്ങൾ കൺട്രോൾ ലെയറിൻ്റെ പരാജയത്തോടൊപ്പമാണ്. അതിൻ്റെ ഉപകരണങ്ങളുടെ പരാജയം കാരണം ഇത് സംഭവിക്കാം, പക്ഷേ പലപ്പോഴും അപകടങ്ങൾ പരീക്ഷിക്കപ്പെടാത്തതിനാൽ, വർദ്ധിച്ച ലോഡ് കാരണം നിയന്ത്രണ പാളി തന്നെ വീഴുന്നു.

ഇതിനെല്ലാം നിങ്ങൾക്ക് എന്ത് ചെയ്യാൻ കഴിയും?

വൻതോതിലുള്ള കുടിയേറ്റങ്ങൾ അർത്ഥമാക്കുന്നത് അടിസ്ഥാന സൗകര്യങ്ങളിൽ ധാരാളം പ്രവർത്തനങ്ങൾ, കുടിയേറ്റങ്ങൾ, വിന്യാസങ്ങൾ എന്നിവ നടക്കുന്നു എന്നാണ്. ഓരോ മൈഗ്രേഷനും കണ്ടെയ്‌നർ ഇമേജുകൾ മിനിയൻമാർക്ക് കൈമാറുന്നതിനും അൺപാക്ക് ചെയ്യുന്നതിനും കണ്ടെയ്‌നറുകൾ സമാരംഭിക്കുന്നതിനും സമാരംഭിക്കുന്നതിനും മറ്റും കുറച്ച് സമയമെടുത്തേക്കാം. അതിനാൽ, പ്രാധാന്യം കുറഞ്ഞവയ്‌ക്ക് മുമ്പ് കൂടുതൽ പ്രധാനപ്പെട്ട ജോലികൾ സമാരംഭിക്കുന്നത് അഭികാമ്യമാണ്.

നമുക്ക് പരിചിതമായ സേവനങ്ങളുടെ ശ്രേണി വീണ്ടും നോക്കാം, ഏതൊക്കെ ടാസ്‌ക്കുകളാണ് ആദ്യം പ്രവർത്തിപ്പിക്കേണ്ടതെന്ന് തീരുമാനിക്കാൻ ശ്രമിക്കാം.

തീർച്ചയായും, ഉപയോക്തൃ അഭ്യർത്ഥനകൾ പ്രോസസ്സ് ചെയ്യുന്നതിൽ നേരിട്ട് ഉൾപ്പെട്ടിരിക്കുന്ന പ്രക്രിയകളാണ് ഇവ, അതായത് പ്രോഡ്. ഞങ്ങൾ ഇത് സൂചിപ്പിക്കുന്നു പ്ലേസ്മെൻ്റ് മുൻഗണന - ക്യൂവിൽ അസൈൻ ചെയ്യാവുന്ന ഒരു നമ്പർ. ഒരു ക്യൂവിന് ഉയർന്ന മുൻഗണനയുണ്ടെങ്കിൽ, അതിൻ്റെ സേവനങ്ങൾ ആദ്യം സ്ഥാപിക്കും.

ഉൽപ്പന്നത്തിൽ ഞങ്ങൾ ഉയർന്ന മുൻഗണനകൾ നൽകുന്നു, 0; ബാച്ചിൽ - അല്പം താഴ്ന്നത്, 100; നിഷ്ക്രിയാവസ്ഥയിൽ - ഇതിലും താഴെ, 200. മുൻഗണനകൾ ശ്രേണിയിൽ പ്രയോഗിക്കുന്നു. ശ്രേണിയിൽ താഴെയുള്ള എല്ലാ ജോലികൾക്കും അനുയോജ്യമായ മുൻഗണന ഉണ്ടായിരിക്കും. ഫ്രണ്ട്എൻഡിന് മുമ്പായി പ്രോഡിനുള്ളിലെ കാഷെകൾ സമാരംഭിക്കണമെന്ന് ഞങ്ങൾ ആഗ്രഹിക്കുന്നുവെങ്കിൽ, കാഷെ = 0, ഫ്രണ്ട് സബ്‌ക്യൂകൾ = 1 എന്നിവയ്‌ക്ക് ഞങ്ങൾ മുൻഗണന നൽകുന്നു. ഉദാഹരണത്തിന്, പ്രധാന പോർട്ടൽ ആദ്യം ഫ്രണ്ടുകളിൽ നിന്ന് സമാരംഭിക്കണമെന്നും മ്യൂസിക് ഫ്രണ്ട് മാത്രമായിരിക്കണമെന്നും ഞങ്ങൾ ആഗ്രഹിക്കുന്നു. തുടർന്ന്, രണ്ടാമത്തേതിന് നമുക്ക് കുറഞ്ഞ മുൻഗണന നൽകാം - 10.

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

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

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

മുഴുവൻ ഡിസി അപകടങ്ങളും

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

ജീവനോടെ ആരെങ്കിലും ട്വീറ്റ് ചെയ്യുന്നത് തടയാൻ ഇതാണ് ഞങ്ങൾ ചെയ്യുന്നത്.

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

ഈ സമീപനം ശാരീരിക പരാജയത്തിൽ നിന്ന് സംരക്ഷിക്കുക മാത്രമല്ല, ഓപ്പറേറ്റർ പിശകിൽ നിന്ന് സംരക്ഷിക്കുകയും ചെയ്യും.

മാനുഷിക ഘടകം ഉപയോഗിച്ച് മറ്റെന്താണ് ചെയ്യാൻ കഴിയുക? ഒരു ഓപ്പറേറ്റർ ക്ലൗഡിന് വിചിത്രമോ അപകടകരമോ ആയ എന്തെങ്കിലും കമാൻഡ് നൽകുമ്പോൾ, അവൻ എത്ര നന്നായി ചിന്തിച്ചുവെന്ന് കാണാൻ പെട്ടെന്ന് ഒരു ചെറിയ പ്രശ്നം പരിഹരിക്കാൻ ആവശ്യപ്പെടാം. ഉദാഹരണത്തിന്, ഇത് നിരവധി പകർപ്പുകളുടെ ഏതെങ്കിലും തരത്തിലുള്ള മാസ് സ്റ്റോപ്പ് അല്ലെങ്കിൽ ഒരു വിചിത്രമായ കമാൻഡ് ആണെങ്കിൽ - പകർപ്പുകളുടെ എണ്ണം കുറയ്ക്കുകയോ ചിത്രത്തിൻ്റെ പേര് മാറ്റുകയോ ചെയ്യുക, പുതിയ മാനിഫെസ്റ്റിലെ പതിപ്പ് നമ്പർ മാത്രമല്ല.

ഫലങ്ങൾ

ഒരു മേഘത്തിൻ്റെ പ്രത്യേകതകൾ:

• സേവനങ്ങൾക്കും കണ്ടെയ്‌നറുകൾക്കുമുള്ള ശ്രേണിപരവും ദൃശ്യപരവുമായ നാമകരണ പദ്ധതി, ടാസ്ക് എന്താണെന്നും അത് എന്തുമായി ബന്ധപ്പെട്ടിരിക്കുന്നുവെന്നും അത് എങ്ങനെ പ്രവർത്തിക്കുന്നുവെന്നും അതിൻ്റെ ഉത്തരവാദിത്തം ആരാണെന്നും വളരെ വേഗത്തിൽ കണ്ടെത്താൻ നിങ്ങളെ അനുവദിക്കുന്നു.
• ഞങ്ങൾ പ്രയോഗിക്കുന്നു ഉൽപ്പന്നവും ബാച്ചും സംയോജിപ്പിക്കുന്നതിനുള്ള സാങ്കേതികത-മെഷീൻ ഷെയറിംഗിൻ്റെ കാര്യക്ഷമത മെച്ചപ്പെടുത്തുന്നതിന് മിനിയൻമാരുടെ ചുമതലകൾ. cpuset-ന് പകരം ഞങ്ങൾ CPU ക്വാട്ടകൾ, ഷെയറുകൾ, CPU ഷെഡ്യൂളർ പോളിസികൾ, Linux QoS എന്നിവ ഉപയോഗിക്കുന്നു.
• ഒരേ മെഷീനിൽ പ്രവർത്തിക്കുന്ന കണ്ടെയ്‌നറുകൾ പൂർണ്ണമായും ഒറ്റപ്പെടുത്താൻ സാധ്യമല്ല, പക്ഷേ അവയുടെ പരസ്പര സ്വാധീനം 20% ൽ തുടരുന്നു.
• സേവനങ്ങളെ ഒരു ശ്രേണിയിലേക്ക് ഓർഗനൈസുചെയ്യുന്നത് ഉപയോഗിച്ച് സ്വയമേവയുള്ള ദുരന്ത വീണ്ടെടുക്കൽ സഹായിക്കുന്നു പ്ലേസ്‌മെൻ്റ്, മുൻകരുതൽ മുൻഗണനകൾ.

പതിവുചോദ്യങ്ങൾ

എന്തുകൊണ്ടാണ് ഞങ്ങൾ ഒരു റെഡിമെയ്ഡ് പരിഹാരം എടുക്കാത്തത്?

• വിവിധ തരം ടാസ്‌ക് ഐസൊലേഷനുകൾക്ക് മിനിയണുകളിൽ സ്ഥാപിക്കുമ്പോൾ വ്യത്യസ്ത യുക്തി ആവശ്യമാണ്. റിസോഴ്‌സുകൾ റിസർവ് ചെയ്‌ത് പ്രോഡ് ടാസ്‌ക്കുകൾ സ്ഥാപിക്കാൻ കഴിയുമെങ്കിൽ, മിനിയന് മെഷീനുകളിലെ വിഭവങ്ങളുടെ യഥാർത്ഥ വിനിയോഗം ട്രാക്കുചെയ്‌ത് ബാച്ചും നിഷ്‌ക്രിയ ടാസ്‌ക്കുകളും സ്ഥാപിക്കണം.
• ഇനിപ്പറയുന്നതുപോലുള്ള ടാസ്‌ക്കുകൾ ഉപയോഗിക്കുന്ന ഉറവിടങ്ങൾ കണക്കിലെടുക്കേണ്ടതിൻ്റെ ആവശ്യകത:
  • നെറ്റ്വർക്ക് ബാൻഡ്വിഡ്ത്ത്;
  • ഡിസ്കുകളുടെ തരങ്ങളും "സ്പിൻഡിലുകളും".
• അടിയന്തിര പ്രതികരണ സമയത്ത് സേവനങ്ങളുടെ മുൻഗണനകൾ സൂചിപ്പിക്കേണ്ടതിൻ്റെ ആവശ്യകത, ഉറവിടങ്ങൾക്കായുള്ള കമാൻഡുകളുടെ അവകാശങ്ങളും ക്വാട്ടകളും, ഇത് ഒരു ക്ലൗഡിലെ ശ്രേണിപരമായ ക്യൂകൾ ഉപയോഗിച്ച് പരിഹരിക്കുന്നു.
• അപകടങ്ങളോടും സംഭവങ്ങളോടുമുള്ള പ്രതികരണ സമയം കുറയ്ക്കുന്നതിന് കണ്ടെയ്‌നറുകൾക്ക് മനുഷ്യനാമം നൽകേണ്ടതിൻ്റെ ആവശ്യകത
• സർവീസ് ഡിസ്കവറി ഒറ്റത്തവണ വ്യാപകമായ നടപ്പാക്കലിൻ്റെ അസാധ്യത; ഹാർഡ്‌വെയർ ഹോസ്റ്റുകളിൽ ഹോസ്‌റ്റ് ചെയ്‌തിരിക്കുന്ന ടാസ്‌ക്കുകളുമായി ദീർഘകാലം നിലനിൽക്കേണ്ടതിൻ്റെ ആവശ്യകത - കണ്ടെയ്‌നറുകൾക്ക് ശേഷമുള്ള “സ്റ്റാറ്റിക്” ഐപി വിലാസങ്ങൾ വഴി പരിഹരിക്കപ്പെടുന്ന ഒന്ന്, അതിൻ്റെ ഫലമായി, ഒരു വലിയ നെറ്റ്‌വർക്ക് ഇൻഫ്രാസ്ട്രക്ചറുമായി അതുല്യമായ സംയോജനത്തിൻ്റെ ആവശ്യകത.

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

അവസാന വരികൾ വായിച്ചവരോട്, നിങ്ങളുടെ ക്ഷമയ്ക്കും ശ്രദ്ധയ്ക്കും നന്ദി!

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