Quay.io અનુપલબ્ધતા પર પોસ્ટ મોર્ટમ

નૉૅધ. અનુવાદ: ઓગસ્ટની શરૂઆતમાં, Red Hat જાહેરમાં સુલભતા સમસ્યાઓ ઉકેલવા વિશે વાત કરી હતી કે જે તેની સેવાના વપરાશકર્તાઓને અગાઉના મહિનાઓમાં આવી હતી. Quay.io (તે કન્ટેનર ઇમેજ માટેની રજિસ્ટ્રી પર આધારિત છે, જે કંપનીને CoreOS ની ખરીદી સાથે પ્રાપ્ત થઈ હતી). આ સેવામાં તમારી રુચિને ધ્યાનમાં લીધા વિના, કંપનીના SRE એન્જિનિયરોએ અકસ્માતના કારણોનું નિદાન કરવા અને તેને દૂર કરવા માટે જે માર્ગ અપનાવ્યો તે ઉપદેશક છે.

19 મેના રોજ વહેલી સવારે (ઈસ્ટર્ન ડેલાઇટ ટાઈમ, EDT), quay.io સેવા ક્રેશ થઈ ગઈ. આ અકસ્માતે quay.io ઉપભોક્તા અને ઓપન સોર્સ પ્રોજેક્ટ બંનેને અસર કરી હતી જે quay.io નો ઉપયોગ કરીને સોફ્ટવેર બનાવવા અને વિતરણ કરવા માટે પ્લેટફોર્મ તરીકે ઉપયોગ કરે છે. Red Hat બંનેના વિશ્વાસને મહત્ત્વ આપે છે.

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

«શું બદલાયું છે?"- આ પહેલો પ્રશ્ન છે જે સામાન્ય રીતે આવા કિસ્સાઓમાં પૂછવામાં આવે છે. અમે નોંધ્યું છે કે ઇશ્યૂના થોડા સમય પહેલા, OpenShift ડેડિકેટેડ ક્લસ્ટર (જે quay.io ચલાવે છે) એ વર્ઝન 4.3.19 પર અપડેટ કરવાનું શરૂ કર્યું. quay.io Red Hat OpenShift ડેડિકેટેડ (OSD) પર ચાલતું હોવાથી, નિયમિત અપડેટ્સ નિયમિત હતા અને ક્યારેય સમસ્યા ઊભી કરી ન હતી. વધુમાં, પાછલા છ મહિનામાં, અમે સેવામાં કોઈપણ વિક્ષેપ વિના ક્વે ક્લસ્ટરોને ઘણી વખત અપગ્રેડ કર્યા છે.

જ્યારે અમે સેવા પુનઃસ્થાપિત કરવાનો પ્રયાસ કરી રહ્યા હતા, ત્યારે અન્ય એન્જિનિયરોએ સૉફ્ટવેરના પાછલા સંસ્કરણ સાથે એક નવું OSD ક્લસ્ટર તૈયાર કરવાનું શરૂ કર્યું, જેથી જો કંઈક થાય, તો તેઓ તેના પર બધું ગોઠવી શકે.

મૂળ કારણોનું પૃથ્થકરણ

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

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

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

Quay.io એ નવા OSD ક્લસ્ટર પર સ્થિર રીતે કામ કર્યું, તેથી અમે ડેટાબેઝ લૉગ્સ પર પાછા ફર્યા, પરંતુ હજુ પણ એવા સહસંબંધ શોધવામાં અસમર્થ હતા કે જે અવરોધોને સમજાવે. Red Hat OpenShift 4.3.19 માં ફેરફારો Quay સાથે સમસ્યા ઊભી કરી શકે છે કે કેમ તે સમજવા માટે OpenShift એન્જિનિયરોએ અમારી સાથે કામ કર્યું. જો કે, કંઇ મળ્યું ન હતું, અને પ્રયોગશાળાની પરિસ્થિતિઓમાં સમસ્યાનું પુનઃઉત્પાદન કરવું શક્ય ન હતું.

બીજી નિષ્ફળતા

28 મેના રોજ, બપોરના EDTના થોડા સમય પહેલા, quay.io એ જ લક્ષણ સાથે ફરીથી ક્રેશ થયું: ડેટાબેઝ બ્લોક કરવામાં આવ્યો હતો. અને ફરીથી અમે અમારા તમામ પ્રયાસો તપાસમાં નાખી દીધા. સૌ પ્રથમ, સેવા પુનઃસ્થાપિત કરવી જરૂરી હતી. જોકે આ વખતે RDS રીબૂટ કરીને અને quay.io પોડ્સને પુનઃપ્રારંભ કરવાથી કંઈ થયું નથી: જોડાણોના અન્ય હિમપ્રપાતએ આધારને ડૂબી ગયો છે. પણ શા માટે?

ક્વે પાયથોનમાં લખાયેલ છે અને દરેક પોડ એક મોનોલિથિક કન્ટેનર તરીકે કાર્ય કરે છે. કન્ટેનર રનટાઇમ એકસાથે ઘણા સમાંતર કાર્યો ચલાવે છે. અમે પુસ્તકાલયનો ઉપયોગ કરીએ છીએ gevent હેઠળ gunicorn વેબ વિનંતીઓ પર પ્રક્રિયા કરવા માટે. જ્યારે કોઈ વિનંતી Quay માં આવે છે (આપણા પોતાના API દ્વારા, અથવા Docker's API દ્વારા), ત્યારે તેને gevent કાર્યકર સોંપવામાં આવે છે. સામાન્ય રીતે આ કાર્યકર્તાએ ડેટાબેઝનો સંપર્ક કરવો જોઈએ. પ્રથમ નિષ્ફળતા પછી, અમે શોધ્યું કે gevent કામદારો ડિફોલ્ટ સેટિંગ્સનો ઉપયોગ કરીને ડેટાબેઝ સાથે જોડાઈ રહ્યા હતા.

ક્વે પોડ્સની નોંધપાત્ર સંખ્યા અને સેકન્ડ દીઠ હજારો ઇનકમિંગ વિનંતીઓને જોતાં, મોટી સંખ્યામાં ડેટાબેઝ કનેક્શન્સ સૈદ્ધાંતિક રીતે MySQL દાખલાને ડૂબી શકે છે. મોનિટરિંગ માટે આભાર, તે જાણીતું હતું કે Quay પ્રતિ સેકન્ડ સરેરાશ 5 હજાર વિનંતીઓ પર પ્રક્રિયા કરે છે. ડેટાબેઝ સાથેના જોડાણોની સંખ્યા લગભગ સમાન હતી. 5 હજાર કનેક્શન્સ અમારા RDS દાખલાની ક્ષમતામાં સારી રીતે હતા (જે હજારો વિશે કહી શકાય નહીં). કેટલાક કારણોસર જોડાણોની સંખ્યામાં અનપેક્ષિત સ્પાઇક્સ હતા, જો કે, અમે આવનારી વિનંતીઓ સાથે કોઈ સંબંધ જોયો નથી.

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

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

બ્લોકીંગ તરફ દોરી જતા સમસ્યાને બાયપાસ કરવામાં વ્યવસ્થાપિત કર્યા પછી, અમે તેના વાસ્તવિક કારણો શોધી શક્યા નથી. તે પુષ્ટિ કરવામાં આવી હતી કે તે OpenShift 4.3.19 માં કોઈપણ ફેરફારો સાથે સંબંધિત નથી, કારણ કે તે જ વસ્તુ આવૃત્તિ 4.3.18 પર થયું હતું, જે અગાઉ Quay સાથે કોઈપણ સમસ્યા વિના કામ કરતું હતું.

ક્લસ્ટરમાં સ્પષ્ટપણે કંઈક બીજું છુપાયેલું હતું.

વિગતવાર અભ્યાસ

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

આ દરમિયાન, SRE ટીમ ક્વેની વિનંતીની અવલોકનક્ષમતા અને એકંદર સેવા સ્વાસ્થ્યમાં સુધારાઓ પર કામ કરી રહી છે. નવા મેટ્રિક્સ અને ડેશબોર્ડ તૈનાત કરવામાં આવ્યા છે, દર્શાવે છે કે ગ્રાહકો તરફથી ક્વેના કયા ભાગોની સૌથી વધુ માંગ છે.

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

કનેક્શન્સમાં ઉછાળો આવે તે પહેલાં, એપ્લિકેશન રજિસ્ટ્રી API ને મોટી સંખ્યામાં વિનંતીઓ કરવામાં આવી હતી. એપ રજિસ્ટ્રી એ quay.io ની થોડી જાણીતી સુવિધા છે. તે તમને હેલ્મ ચાર્ટ્સ અને સમૃદ્ધ મેટાડેટા સાથે કન્ટેનર જેવી વસ્તુઓ સ્ટોર કરવાની મંજૂરી આપે છે. મોટાભાગના quay.io વપરાશકર્તાઓ આ લક્ષણ સાથે કામ કરતા નથી, પરંતુ Red Hat OpenShift સક્રિયપણે તેનો ઉપયોગ કરે છે. OpenShift ના ભાગ રૂપે OperatorHub એપ રજિસ્ટ્રીમાં તમામ ઓપરેટરોને સ્ટોર કરે છે. આ ઓપરેટરો ઓપનશિફ્ટ વર્કલોડ ઇકોસિસ્ટમ અને ભાગીદાર-કેન્દ્રિત ઓપરેટિંગ મોડલ (દિવસ 2 કામગીરી) માટે આધાર બનાવે છે.

દરેક OpenShift 4 ક્લસ્ટર ઇન્સ્ટોલેશન માટે ઉપલબ્ધ ઑપરેટર્સની સૂચિ પ્રકાશિત કરવા અને પહેલેથી ઇન્સ્ટોલ કરેલાને અપડેટ્સ પ્રદાન કરવા બિલ્ટ-ઇન ઑપરેટરહબમાંથી ઑપરેટર્સનો ઉપયોગ કરે છે. OpenShift 4 ની વધતી જતી લોકપ્રિયતા સાથે, વિશ્વભરમાં તેના પરના ક્લસ્ટરોની સંખ્યામાં પણ વધારો થયો છે. બેકએન્ડ તરીકે quay.io ની અંદર એપ રજિસ્ટ્રીનો ઉપયોગ કરીને બિલ્ટ-ઇન OperatorHub ચલાવવા માટે આ દરેક ક્લસ્ટર ઓપરેટર સામગ્રીને ડાઉનલોડ કરે છે. સમસ્યાના સ્ત્રોતની અમારી શોધમાં, અમે એ હકીકત ચૂકી ગયા કે જેમ જેમ OpenShift ધીમે ધીમે લોકપ્રિયતામાં વધતી ગઈ તેમ તેમ ભાગ્યે જ ઉપયોગમાં લેવાતા quay.io ફંક્શન્સમાંથી એક પરનો ભાર પણ વધ્યો..

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

કારણો દૂર

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

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

આપણે શું શીખ્યા?

તે સ્પષ્ટ છે કે કોઈપણ સેવા ડાઉનટાઇમ ટાળવાનો પ્રયાસ કરે છે. અમારા કિસ્સામાં, અમે માનીએ છીએ કે તાજેતરના આઉટેજથી quay.io ને વધુ સારું બનાવવામાં મદદ મળી છે. અમે કેટલાક મુખ્ય પાઠ શીખ્યા છે જે અમે શેર કરવા માંગીએ છીએ:

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

શું આગામી છે?

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

1. પ્રાથમિક RDS ઉદાહરણ સાથે સમસ્યાઓના કિસ્સામાં સેવાને યોગ્ય ટ્રાફિકને હેન્ડલ કરવામાં મદદ કરવા માટે ફક્ત-વાંચવા માટેના ડેટાબેઝ પ્રતિકૃતિઓનો ઉપયોગ કરો.
2. RDS ઉદાહરણ અપડેટ કરી રહ્યું છે. વર્તમાન સંસ્કરણ પોતે જ સમસ્યા નથી. તેના બદલે, અમે ફક્ત ખોટા પગેરું દૂર કરવા માંગીએ છીએ (જે અમે નિષ્ફળતા દરમિયાન અનુસર્યા હતા); સૉફ્ટવેરને અદ્યતન રાખવાથી ભવિષ્યમાં આઉટેજની ઘટનામાં અન્ય પરિબળ દૂર થશે.
3. સમગ્ર ક્લસ્ટરમાં વધારાની કેશીંગ. અમે એવા વિસ્તારો શોધવાનું ચાલુ રાખીએ છીએ જ્યાં કેશીંગ ડેટાબેઝ પરનો ભાર ઘટાડી શકે છે.
4. quay.io સાથે કોણ અને શા માટે કનેક્ટ થઈ રહ્યું છે તે જોવા માટે વેબ એપ્લિકેશન ફાયરવોલ (WAF) ઉમેરવું.
5. આગામી પ્રકાશનથી શરૂ કરીને, quay.io પર ઉપલબ્ધ કન્ટેનર ઈમેજો પર આધારિત ઓપરેટર કેટલોગની તરફેણમાં Red Hat OpenShift ક્લસ્ટર્સ એપ રજિસ્ટ્રીને છોડી દેશે.
6. એપ રજિસ્ટ્રી માટે લાંબા ગાળાના રિપ્લેસમેન્ટ ઓપન કન્ટેનર ઇનિશિયેટિવ (OCI) આર્ટિફેક્ટ સ્પષ્ટીકરણો માટે સપોર્ટ હોઈ શકે છે. તે હાલમાં મૂળ Quay કાર્યક્ષમતા તરીકે લાગુ કરવામાં આવ્યું છે અને જ્યારે સ્પષ્ટીકરણ પોતે જ અંતિમ સ્વરૂપ આપવામાં આવશે ત્યારે વપરાશકર્તાઓ માટે ઉપલબ્ધ થશે.

ઉપરોક્ત તમામ quay.io માં Red Hat ના ચાલુ રોકાણનો એક ભાગ છે કારણ કે અમે એક નાની "સ્ટાર્ટઅપ-શૈલી" ટીમમાંથી પરિપક્વ SRE-સંચાલિત પ્લેટફોર્મ તરફ આગળ વધીએ છીએ. અમે જાણીએ છીએ કે અમારા ઘણા ગ્રાહકો તેમના રોજિંદા કામમાં (Red Hat! સહિત) quay.io પર આધાર રાખે છે અને અમે તાજેતરના આઉટેજ અને સુધારવાના ચાલુ પ્રયાસો વિશે શક્ય તેટલું પારદર્શક બનવાનો પ્રયાસ કરીએ છીએ.

અનુવાદક તરફથી પીએસ

અમારા બ્લોગ પર પણ વાંચો:

• «CoreOS કન્ટેનર ઈમેજીસ માટે Red Hat ઓપન સોર્સ્ડ રજિસ્ટ્રી કોડ - Quay»;
• «અમારા SRE રોજિંદા જીવનમાંથી વ્યવહારુ વાર્તાઓ. ભાગ 2»;
• «કેવી રીતે કુબરનેટ્સમાં પોડ પ્રાથમિકતાઓને કારણે ગ્રાફના લેબ્સમાં ડાઉનટાઇમ થયો».

સોર્સ: www.habr.com