વન-ક્લાઉડ - ઓડનોક્લાસ્નીકીમાં ડેટા સેન્ટર લેવલ ઓએસ

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

તેમાંથી શું આવ્યું?

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

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

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

તે શા માટે છે? આ અભિગમના ઘણા ફાયદા હતા:

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

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

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

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

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

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

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

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

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

ઉપરાંત, ડોકરમાં તૈયાર રજિસ્ટ્રી અને ઇમેજ ટેગિંગ અમને વર્ઝનિંગ અને પ્રોડક્શનમાં કોડ પહોંચાડવા માટે તૈયાર આદિમ આપે છે.

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

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

જ્યારે તમારી પાસે 8 હજાર સર્વર અને 8-16 હજાર કન્ટેનર હોય ત્યારે જાતે કન્ટેનરનું વિતરણ કરવું એ વિકલ્પ નથી.

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

દેખીતી રીતે, અમને એક નિયંત્રણ સ્તરની જરૂર છે જે આ આપમેળે કરશે.

તેથી અમે એક સરળ અને સમજી શકાય તેવા ચિત્ર પર આવ્યા કે જે બધા આર્કિટેક્ટ્સને પસંદ છે: ત્રણ ચોરસ.

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

સાધનો ની ફાળવણી

હવે ચાલો ઘણા મિનિઅન્સ માટે વધુ જટિલ સંસાધન ફાળવણીની સમસ્યા જોઈએ.

એક-ક્લાઉડમાં કમ્પ્યુટિંગ સંસાધન છે:

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

પછી કેટલીક સેવા માટે, ઉદાહરણ તરીકે વપરાશકર્તા-કેશ માટે, અમે આ રીતે વપરાશમાં લેવાયેલા સંસાધનોને રેકોર્ડ કરી શકીએ છીએ: 400 પ્રોસેસર કોરો, 2,5 TB મેમરી, બંને દિશામાં 50 Gbit/s ટ્રાફિક, 6 સ્પિન્ડલ્સ પર સ્થિત HDD સ્પેસનો 100 TB. અથવા આના જેવા વધુ પરિચિત સ્વરૂપમાં:

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

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

ચાલો ઘટકોની ક્રિયાપ્રતિક્રિયાના અમારા મોટા પ્રમાણમાં સરળ રેખાકૃતિ પર પાછા ફરીએ અને તેને વધુ વિગતો સાથે ફરીથી દોરો - જેમ કે:

તમારી આંખ શું પકડે છે:

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

ચાલો ફરીથી ચિત્રને ફરીથી દોરીએ:

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

વધારાની લીટીઓ દૂર કરીને, અમે અમારા ચિત્રના દરેક નોડને ચપટી સ્વરૂપમાં લખી શકીએ છીએ: group1.web.front, api.music.ફ્રન્ટ, user-cache.cache.

આ રીતે આપણે "હાયરાર્કિકલ કતાર" ના ખ્યાલ પર આવીએ છીએ. તેનું "group1.web.front" જેવું નામ છે. સંસાધનો અને વપરાશકર્તા અધિકારો માટેનો ક્વોટા તેને સોંપવામાં આવ્યો છે. અમે DevOps માંથી વ્યક્તિને કતારમાં સેવા મોકલવાના અધિકારો આપીશું, અને આવા કર્મચારી કતારમાં કંઈક શરૂ કરી શકે છે, અને OpsDevની વ્યક્તિ પાસે એડમિન અધિકારો હશે, અને હવે તે કતારનું સંચાલન કરી શકશે, ત્યાં લોકોને સોંપી શકશે, આ લોકોને અધિકાર આપો વગેરે. આ કતાર પર ચાલતી સેવાઓ કતારના ક્વોટામાં ચાલશે. જો કતારનો કમ્પ્યુટિંગ ક્વોટા બધી સેવાઓને એકસાથે એક્ઝિક્યુટ કરવા માટે પૂરતો નથી, તો તે ક્રમિક રીતે ચલાવવામાં આવશે, આમ કતાર પોતે જ બનાવે છે.

ચાલો સેવાઓ પર નજીકથી નજર કરીએ. સેવાનું સંપૂર્ણ લાયક નામ હોય છે, જેમાં હંમેશા કતારનું નામ શામેલ હોય છે. પછી આગળની વેબ સેવાનું નામ હશે ok-web.group1.web.front. અને તે જે એપ્લીકેશન સર્વર સેવાને ઍક્સેસ કરે છે તેને કૉલ કરવામાં આવશે ok-app.group1.web.front. દરેક સેવામાં એક મેનિફેસ્ટ હોય છે, જે ચોક્કસ મશીનો પર પ્લેસમેન્ટ માટે તમામ જરૂરી માહિતીનો ઉલ્લેખ કરે છે: આ કાર્ય કેટલા સંસાધનોનો ઉપયોગ કરે છે, તેના માટે કઈ ગોઠવણીની જરૂર છે, કેટલી પ્રતિકૃતિઓ હોવી જોઈએ, આ સેવાની નિષ્ફળતાને નિયંત્રિત કરવા માટેના ગુણધર્મો. અને સેવા સીધી મશીનો પર મૂક્યા પછી, તેના ઉદાહરણો દેખાય છે. તેઓનું નામ પણ અસ્પષ્ટ રીતે રાખવામાં આવ્યું છે - ઉદાહરણ નંબર અને સેવાના નામ તરીકે: 1.ok-web.group1.web.front, 2.ok-web.group1.web.front, …

આ ખૂબ અનુકૂળ છે: ફક્ત ચાલતા કન્ટેનરનું નામ જોઈને, આપણે તરત જ ઘણું શોધી શકીએ છીએ.

હવે ચાલો નજીકથી જોઈએ કે આ ઉદાહરણો ખરેખર શું કરે છે: કાર્યો.

કાર્ય અલગતા વર્ગો

OK માં તમામ કાર્યો (અને, કદાચ, દરેક જગ્યાએ) જૂથોમાં વિભાજિત કરી શકાય છે:

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

ચાલો જોઈએ કે આવા કાર્યો કેવી રીતે સંસાધનોનો ઉપયોગ કરે છે, ઉદાહરણ તરીકે, સેન્ટ્રલ પ્રોસેસર.

ટૂંકા વિલંબના કાર્યો. આવા કાર્યમાં આના જેવી જ CPU વપરાશ પેટર્ન હશે:

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

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

alloc: cpu = 4 (max)

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

ગણતરી કાર્યો. તેમની પેટર્ન થોડી અલગ હશે:

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

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 cpushers સાથે કાર્યને આપવામાં આવશે, અને બાકીના બે 2048 cpushers સાથે કાર્યને આપવામાં આવશે.

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

• SCHED_OTHER
  મૂળભૂત રીતે, Linux મશીન પરની તમામ સામાન્ય વપરાશકર્તા પ્રક્રિયાઓ પ્રાપ્ત થાય છે.
• 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 ક્ષમતાની જરૂર પડી શકે છે, કારણ કે કન્ટેનર શરૂ કરતી વખતે મૂળભૂત રીતે ડોકર આ ક્ષમતાને દૂર કરે છે.

પરંતુ કાર્યો ફક્ત પ્રોસેસર જ નહીં, પણ ટ્રાફિકનો પણ ઉપયોગ કરે છે, જે પ્રોસેસર સંસાધનોની ખોટી ફાળવણી કરતાં પણ નેટવર્ક કાર્યની વિલંબતાને અસર કરે છે. તેથી, અમે સ્વાભાવિક રીતે ટ્રાફિક માટે બરાબર એ જ ચિત્ર મેળવવા માંગીએ છીએ. એટલે કે, જ્યારે પ્રોડ ટાસ્ક નેટવર્ક પર કેટલાક પેકેટ્સ મોકલે છે, ત્યારે અમે મહત્તમ ઝડપ (સૂત્ર alloc: lan=[*,500mbps) ), જેની સાથે ઉત્પાદન આ કરી શકે છે. અને બેચ માટે અમે ફક્ત ન્યૂનતમ થ્રુપુટની ખાતરી આપીએ છીએ, પરંતુ મહત્તમ (સૂત્ર alloc: lan=[10Mbps,*) ) આ કિસ્સામાં, પ્રોડ ટ્રાફિકને બેચ કાર્યો પર અગ્રતા પ્રાપ્ત થવી જોઈએ.
અહીં ડોકર પાસે કોઈ આદિમ નથી જેનો આપણે ઉપયોગ કરી શકીએ. પરંતુ તે અમારી મદદ માટે આવે છે Linux ટ્રાફિક નિયંત્રણ. અમે શિસ્તની મદદથી ઇચ્છિત પરિણામ પ્રાપ્ત કરી શક્યા હાયરાર્કિકલ ફેર સર્વિસ કર્વ. તેની મદદથી, અમે ટ્રાફિકના બે વર્ગોને અલગ પાડીએ છીએ: ઉચ્ચ-પ્રાધાન્યતા પ્રોડ અને ઓછી-અગ્રતાવાળી બેચ/નિષ્ક્રિય. પરિણામે, આઉટગોઇંગ ટ્રાફિક માટેનું રૂપરેખાંકન આના જેવું છે:

અહીં 1:0 એ hsfc શિસ્તનું "રુટ qdisc" છે; 1:1 - 8 Gbit/s ની કુલ બેન્ડવિડ્થ મર્યાદા સાથે hsfc બાળ વર્ગ, જે હેઠળ તમામ કન્ટેનરના બાળ વર્ગો મૂકવામાં આવે છે; 1:2 - hsfc બાળ વર્ગ "ડાયનેમિક" મર્યાદા સાથેના તમામ બેચ અને નિષ્ક્રિય કાર્યો માટે સામાન્ય છે, જેની નીચે ચર્ચા કરવામાં આવી છે. બાકીના hsfc બાળ વર્ગો હાલમાં તેમના મેનિફેસ્ટ - 450 અને 400 Mbit/s ને અનુરૂપ મર્યાદા સાથે પ્રોડ કન્ટેનર ચલાવવા માટે સમર્પિત વર્ગો છે. દરેક hsfc વર્ગને qdisc કતાર fq અથવા fq_codel સોંપવામાં આવે છે, Linux કર્નલ સંસ્કરણ પર આધાર રાખીને, ટ્રાફિકના વિસ્ફોટ દરમિયાન પેકેટની ખોટ ટાળવા માટે.

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

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

બેન્ડ્સ ઇનકમિંગ અને આઉટગોઇંગ ટ્રાફિક માટે સ્વતંત્ર રીતે વ્યાખ્યાયિત કરવામાં આવે છે. અને નવા મૂલ્યો અનુસાર, miniond બિન-પ્રાધાન્યતા વર્ગ મર્યાદા 1:2 ને ફરીથી ગોઠવે છે.

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

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

વધારાની લીટીઓ ફરીથી દૂર કરીને, અમે સંપૂર્ણ સેવા નામના અંતમાં ટાસ્ક આઇસોલેશન ક્લાસ ઉમેરીને અમારા સેવાના નામોને ફ્લેટર લખી શકીએ છીએ: web.front.prod, catalog.music.batch, transformer.music.idle.

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

બધું સરસ છે, પણ એક કડવું સત્ય છે. એક મશીન પર ચાલતા કાર્યોને સંપૂર્ણપણે અલગ પાડવું અશક્ય છે.

અમે શું પ્રાપ્ત કરવામાં વ્યવસ્થાપિત કર્યું: જો બેચ સઘન વપરાશ કરે છે માત્ર CPU સંસાધનો, પછી બિલ્ટ-ઇન Linux CPU શેડ્યૂલર તેનું કામ ખૂબ જ સારી રીતે કરે છે, અને પ્રોડ કાર્ય પર વ્યવહારીક રીતે કોઈ અસર થતી નથી. પરંતુ જો આ બેચ કાર્ય મેમરી સાથે સક્રિય રીતે કાર્ય કરવાનું શરૂ કરે છે, તો પછી પરસ્પર પ્રભાવ પહેલેથી જ દેખાય છે. આવું થાય છે કારણ કે પ્રોડ ટાસ્ક પ્રોસેસરની મેમરી કેશમાંથી "ધોવાઈ જાય છે" - પરિણામે, કેશ ચૂકી જાય છે, અને પ્રોસેસર પ્રોડ કાર્યને વધુ ધીમેથી પ્રક્રિયા કરે છે. આવા બેચ કાર્ય અમારા લાક્ષણિક પ્રોડ કન્ટેનરની લેટન્સીમાં 10% વધારો કરી શકે છે.

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

વધુમાં, અમે અત્યાર સુધી માત્ર TCP ટ્રાફિકને પ્રાથમિકતા આપવાની સમસ્યાને ઉકેલવામાં વ્યવસ્થાપિત છીએ: hsfc અભિગમ UDP માટે કામ કરતું નથી. અને TCP ટ્રાફિકના કિસ્સામાં પણ, જો બેચ કાર્ય ઘણો ટ્રાફિક જનરેટ કરે છે, તો આ પ્રોડ કાર્યના વિલંબમાં લગભગ 10% વધારો પણ આપે છે.

સહનશીલતા દોષ

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

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

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

જો સંપૂર્ણ મિનિઅન અનુપલબ્ધ હોય તો તમે શું કરી શકો?

દેખીતી રીતે, કન્ટેનરને અન્ય મશીન પર ચલાવો. અહીં રસપ્રદ ભાગ એ છે કે કન્ટેનરને સોંપેલ IP સરનામાઓનું શું થાય છે.

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

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

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

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

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

આમ, સેવાના નામનું તેના IP સરનામાઓની સૂચિમાં મેપિંગ ખૂબ જ ભાગ્યે જ બદલાય છે. જો તમે સેવાના દાખલાઓના નામો પર ફરીથી જોશો જેનો અમે લેખની શરૂઆતમાં ઉલ્લેખ કર્યો છે (1.ok-web.group1.web.front.prod, 2.ok-web.group1.web.front.prod, …), અમે જોશું કે તેઓ DNS માં વપરાતા FQDN ને મળતા આવે છે. તે સાચું છે, સેવાના દાખલાઓના નામોને તેમના IP સરનામાં પર મેપ કરવા માટે, અમે DNS પ્રોટોકોલનો ઉપયોગ કરીએ છીએ. તદુપરાંત, આ DNS બધા કન્ટેનરના તમામ આરક્ષિત IP સરનામાં પરત કરે છે - ચાલતા અને બંધ બંને (ચાલો કહીએ કે ત્રણ પ્રતિકૃતિઓનો ઉપયોગ કરવામાં આવ્યો છે, અને અમારી પાસે ત્યાં પાંચ સરનામાં આરક્ષિત છે - બધા પાંચ પરત કરવામાં આવશે). ગ્રાહકો, આ માહિતી પ્રાપ્ત કર્યા પછી, પાંચેય પ્રતિકૃતિઓ સાથે જોડાણ સ્થાપિત કરવાનો પ્રયાસ કરશે - અને આ રીતે તે નક્કી કરશે કે જેઓ કામ કરી રહ્યાં છે. પ્રાપ્યતા નક્કી કરવા માટેનો આ વિકલ્પ વધુ ભરોસાપાત્ર છે; તેમાં DNS અથવા સર્વિસ ડિસ્કવરીનો સમાવેશ થતો નથી, જેનો અર્થ છે કે માહિતીની સુસંગતતા અને આ સિસ્ટમોની ખામી સહિષ્ણુતાની ખાતરી કરવામાં કોઈ મુશ્કેલ સમસ્યા નથી. તદુપરાંત, જટિલ સેવાઓમાં કે જેના પર સમગ્ર પોર્ટલનું સંચાલન નિર્ભર છે, અમે DNS નો બિલકુલ ઉપયોગ કરી શકતા નથી, પરંતુ ફક્ત રૂપરેખાંકનમાં IP સરનામાઓ દાખલ કરીએ છીએ.

કન્ટેનર પાછળ આવા IP ટ્રાન્સફરને અમલમાં મૂકવું બિન-તુચ્છ હોઈ શકે છે - અને અમે નીચેના ઉદાહરણ સાથે તે કેવી રીતે કાર્ય કરે છે તે જોઈશું:

ચાલો કહીએ કે વન-ક્લાઉડ માસ્ટર minion M1 ને ચલાવવા માટે આદેશ આપે છે 1.ok-web.group1.web.front.prod સરનામું 1.1.1.1 સાથે. મિનિઅન પર કામ કરે છે પક્ષી, જે આ સરનામાની જાહેરાત વિશેષ સર્વર્સ પર કરે છે રૂટ રિફ્લેક્ટર. બાદમાં નેટવર્ક હાર્ડવેર સાથે BGP સત્ર ધરાવે છે, જેમાં M1.1.1.1 પર સરનામાં 1 નો રૂટ અનુવાદિત થાય છે. M1 Linux નો ઉપયોગ કરીને કન્ટેનરની અંદર પેકેટોને રૂટ કરે છે. ત્રણ રૂટ રિફ્લેક્ટર સર્વર્સ છે, કારણ કે આ એક-ક્લાઉડ ઇન્ફ્રાસ્ટ્રક્ચરનો ખૂબ જ મહત્વપૂર્ણ ભાગ છે - તેમના વિના, એક-ક્લાઉડમાં નેટવર્ક કામ કરશે નહીં. અમે તેમને એક જ સમયે ત્રણેય નિષ્ફળ થવાની સંભાવનાને ઘટાડવા માટે, જો શક્ય હોય તો ડેટા સેન્ટરના અલગ-અલગ રૂમમાં સ્થિત વિવિધ રેક્સમાં મૂકીએ છીએ.

ચાલો હવે ધારીએ કે વન-ક્લાઉડ માસ્ટર અને M1 મિનિઅન વચ્ચેનું જોડાણ ખોવાઈ ગયું છે. વન-ક્લાઉડ માસ્ટર હવે એ ધારણા પર કાર્ય કરશે કે M1 સંપૂર્ણપણે નિષ્ફળ ગયું છે. એટલે કે, તે M2 મિનિઅનને લોન્ચ કરવાનો આદેશ આપશે web.group1.web.front.prod સમાન સરનામા સાથે 1.1.1.1. હવે અમારી પાસે 1.1.1.1 માટે નેટવર્ક પર બે વિરોધાભાસી માર્ગો છે: M1 અને M2 પર. આવા તકરારોને ઉકેલવા માટે, અમે મલ્ટી એક્ઝિટ ડિસક્રિમિનેટરનો ઉપયોગ કરીએ છીએ, જે BGP જાહેરાતમાં ઉલ્લેખિત છે. આ એક એવો નંબર છે જે જાહેરાત કરાયેલા માર્ગનું વજન દર્શાવે છે. વિરોધાભાસી માર્ગો પૈકી, નીચા MED મૂલ્ય સાથેનો માર્ગ પસંદ કરવામાં આવશે. વન-ક્લાઉડ માસ્ટર કન્ટેનર IP એડ્રેસના અભિન્ન ભાગ તરીકે MED ને સપોર્ટ કરે છે. પ્રથમ વખત, સરનામું પર્યાપ્ત મોટા MED = 1 સાથે લખવામાં આવ્યું છે. આવી કટોકટી કન્ટેનર ટ્રાન્સફરની પરિસ્થિતિમાં, માસ્ટર MED ઘટાડે છે, અને M000 પહેલાથી જ MED = સાથે સરનામાં 000 ની જાહેરાત કરવાનો આદેશ પ્રાપ્ત કરશે. 2. M1.1.1.1 પર ચાલતો દાખલો આ કિસ્સામાં ત્યાં જ રહેશે જેમાં કોઈ કનેક્શન નથી, અને જ્યાં સુધી માસ્ટર સાથેનું જોડાણ પુનઃસ્થાપિત ન થાય ત્યાં સુધી તેના આગળના ભાગ્યમાં અમને થોડો રસ નથી, જ્યારે તેને જૂના ટેકની જેમ બંધ કરવામાં આવશે.

અકસ્માતો

તમામ ડેટા સેન્ટર મેનેજમેન્ટ સિસ્ટમ હંમેશા નાની નિષ્ફળતાઓને સ્વીકાર્ય રીતે હેન્ડલ કરે છે. કન્ટેનર ઓવરફ્લો લગભગ દરેક જગ્યાએ ધોરણ છે.

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

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

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

તમે આ બધા વિશે શું કરી શકો?

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

ચાલો આપણે જે સેવાઓથી પરિચિત છીએ તેના વંશવેલાને ફરી જોઈએ અને નક્કી કરવાનો પ્રયાસ કરીએ કે આપણે કયા કાર્યોને પહેલા ચલાવવા માંગીએ છીએ.

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

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

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

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

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

સમગ્ર ડીસી અકસ્માતો

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

અને આ અમે કોઈને #alive ટ્વીટ કરવાથી રોકવા માટે કરીએ છીએ.

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

આ અભિગમ માત્ર શારીરિક નિષ્ફળતા સામે રક્ષણ આપે છે, પરંતુ ઓપરેટરની ભૂલ સામે પણ રક્ષણ આપી શકે છે.

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

પરિણામો

એક-મેઘની વિશિષ્ટ સુવિધાઓ:

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

FAQ

આપણે તૈયાર સોલ્યુશન કેમ ન લીધું?

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

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

જેઓ છેલ્લી પંક્તિઓ વાંચે છે, તમારા ધીરજ અને ધ્યાન બદલ આભાર!

સોર્સ: www.habr.com