గమనిక. అనువాదం.: ఆగస్టు ప్రారంభంలో, Red Hat దాని సేవ యొక్క వినియోగదారులు మునుపటి నెలల్లో ఎదుర్కొన్న ప్రాప్యత సమస్యలను పరిష్కరించడం గురించి బహిరంగంగా మాట్లాడింది. (ఇది 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 Dedicated (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 ద్వారా లేదా డాకర్ యొక్క API ద్వారా), అది ఒక gevent వర్కర్‌ని కేటాయించబడుతుంది. సాధారణంగా ఈ కార్యకర్త డేటాబేస్‌ను సంప్రదించాలి. మొదటి వైఫల్యం తర్వాత, డిఫాల్ట్ సెట్టింగ్‌లను ఉపయోగించి గెవెంట్ వర్కర్లు డేటాబేస్కు కనెక్ట్ అవుతున్నారని మేము కనుగొన్నాము.
గణనీయ సంఖ్యలో క్వే పాడ్‌లు మరియు సెకనుకు వేల సంఖ్యలో ఇన్‌కమింగ్ అభ్యర్థనలు ఉన్నందున, పెద్ద సంఖ్యలో డేటాబేస్ కనెక్షన్లు సిద్ధాంతపరంగా MySQL ఉదాహరణను అధిగమించగలవు. పర్యవేక్షణకు ధన్యవాదాలు, క్వే సెకనుకు సగటున 5 వేల అభ్యర్థనలను ప్రాసెస్ చేస్తుందని తెలిసింది. డేటాబేస్కు కనెక్షన్ల సంఖ్య ఇంచుమించు ఒకే విధంగా ఉంది. 5 వేల కనెక్షన్లు మా RDS ఉదాహరణ (పదివేల గురించి చెప్పలేము) సామర్థ్యాల్లోనే ఉన్నాయి. కొన్ని కారణాల వల్ల కనెక్షన్ల సంఖ్యలో ఊహించని స్పైక్‌లు వచ్చాయి, అయితే, ఇన్‌కమింగ్ అభ్యర్థనలతో ఎలాంటి సహసంబంధాన్ని మేము గమనించలేదు.
ఈసారి మేము సమస్య యొక్క మూలాన్ని కనుగొని తొలగించాలని నిశ్చయించుకున్నాము మరియు మమ్మల్ని రీబూట్‌కి పరిమితం చేయకూడదు. క్వే కోడ్‌బేస్‌కు ప్రతి కార్మికునికి డేటాబేస్కు కనెక్షన్ల సంఖ్యను పరిమితం చేయడానికి మార్పులు చేయబడ్డాయి gevent. ఈ సంఖ్య కాన్ఫిగరేషన్‌లో పారామీటర్‌గా మారింది: కొత్త కంటైనర్ ఇమేజ్‌ని నిర్మించకుండా ఫ్లైలో దాన్ని మార్చడం సాధ్యమైంది. ఎన్ని కనెక్షన్‌లను వాస్తవికంగా నిర్వహించవచ్చో తెలుసుకోవడానికి, మేము స్టేజింగ్ వాతావరణంలో అనేక పరీక్షలను నిర్వహించాము, ఇది లోడ్ పరీక్ష దృశ్యాలను ఎలా ప్రభావితం చేస్తుందో చూడటానికి వివిధ విలువలను సెట్ చేసాము. ఫలితంగా, ఇది కనుగొనబడింది కనెక్షన్ల సంఖ్య 502 వేలకు మించి ఉన్నప్పుడు క్వే 10 లోపాలను విసరడం ప్రారంభిస్తుంది.
మేము వెంటనే ఈ కొత్త వెర్షన్‌ను ఉత్పత్తికి అమలు చేసాము మరియు డేటాబేస్ కనెక్షన్ షెడ్యూల్‌ను పర్యవేక్షించడం ప్రారంభించాము. గతంలో, స్థావరం సుమారు 20 నిమిషాల తర్వాత లాక్ డౌన్ చేయబడింది. 30 ఇబ్బంది లేని నిమిషాల తర్వాత మాకు ఆశ కలిగింది, ఒక గంట తర్వాత మాకు విశ్వాసం వచ్చింది. మేము సైట్‌కి ట్రాఫిక్‌ని పునరుద్ధరించాము మరియు పోస్ట్‌మార్టం విశ్లేషణను ప్రారంభించాము.
నిరోధించడానికి దారితీసే సమస్యను దాటవేయగలిగారు, దాని అసలు కారణాలను మేము కనుగొనలేదు. ఇది ఓపెన్‌షిఫ్ట్ 4.3.19లో ఎటువంటి మార్పులకు సంబంధించినది కాదని నిర్ధారించబడింది, ఎందుకంటే మునుపు క్వేతో ఎలాంటి సమస్యలు లేకుండా పనిచేసిన వెర్షన్ 4.3.18లో అదే జరిగింది.
క్లస్టర్‌లో మరో విషయం స్పష్టంగా దాగి ఉంది.
వివరణాత్మక అధ్యయనం
Quay.io ఆరు సంవత్సరాల పాటు ఎటువంటి సమస్యలు లేకుండా డేటాబేస్కు కనెక్ట్ చేయడానికి డిఫాల్ట్ సెట్టింగ్‌లను ఉపయోగించింది. ఏమి మారింది? ఈ సమయంలో quay.ioలో ట్రాఫిక్ క్రమంగా పెరుగుతోందని స్పష్టమైంది. మా విషయంలో, కొంత థ్రెషోల్డ్ విలువను చేరుకున్నట్లు అనిపించింది, ఇది కనెక్షన్ల హిమపాతానికి ట్రిగ్గర్‌గా పనిచేసింది. మేము రెండవ వైఫల్యం తర్వాత డేటాబేస్ లాగ్‌లను అధ్యయనం చేయడం కొనసాగించాము, కానీ ఎలాంటి నమూనాలు లేదా స్పష్టమైన సంబంధాలు కనుగొనబడలేదు.
ఈ సమయంలో, SRE బృందం క్వే యొక్క అభ్యర్థన పరిశీలన మరియు మొత్తం సేవా ఆరోగ్యానికి మెరుగుదలలపై పని చేస్తోంది. కొత్త కొలమానాలు మరియు డ్యాష్‌బోర్డ్‌లు అమలు చేయబడ్డాయి, క్వేలోని ఏ భాగాలకు కస్టమర్ల నుండి ఎక్కువ డిమాండ్ ఉందో చూపిస్తుంది.
జూన్ 9 వరకు Quay.io బాగా పనిచేసింది. ఈ ఉదయం (EDT) డేటాబేస్ కనెక్షన్ల సంఖ్యలో మేము మళ్లీ గణనీయమైన పెరుగుదలను చూశాము. ఈసారి పనికిరాని సమయం లేదు, కొత్త పరామితి వారి సంఖ్యను పరిమితం చేసింది మరియు వాటిని MySQL నిర్గమాంశను అధిగమించడానికి అనుమతించలేదు. అయితే, దాదాపు అరగంట పాటు, చాలా మంది వినియోగదారులు quay.io యొక్క నెమ్మదిగా పనితీరును గుర్తించారు. మేము జోడించిన పర్యవేక్షణ సాధనాలను ఉపయోగించి సాధ్యమయ్యే మొత్తం డేటాను త్వరగా సేకరించాము. అకస్మాత్తుగా ఒక నమూనా కనిపించింది.
కనెక్షన్ల పెరుగుదలకు ముందు, యాప్ రిజిస్ట్రీ APIకి పెద్ద సంఖ్యలో అభ్యర్థనలు వచ్చాయి. యాప్ రిజిస్ట్రీ అనేది quay.io యొక్క అంతగా తెలియని ఫీచర్. రిచ్ మెటాడేటాతో హెల్మ్ చార్ట్‌లు మరియు కంటైనర్‌ల వంటి వాటిని నిల్వ చేయడానికి ఇది మిమ్మల్ని అనుమతిస్తుంది. చాలా మంది quay.io వినియోగదారులు ఈ ఫీచర్‌తో పని చేయరు, అయితే Red Hat OpenShift దీన్ని చురుకుగా ఉపయోగిస్తుంది. OpenShiftలో భాగంగా ఆపరేటర్‌హబ్ యాప్ రిజిస్ట్రీలో అన్ని ఆపరేటర్‌లను నిల్వ చేస్తుంది. ఈ ఆపరేటర్లు OpenShift వర్క్‌లోడ్ ఎకోసిస్టమ్ మరియు పార్టనర్-సెంట్రిక్ ఆపరేటింగ్ మోడల్ (డే 2 ఆపరేషన్‌లు)కి ఆధారం.
ప్రతి OpenShift 4 క్లస్టర్ ఇన్‌స్టాలేషన్ కోసం అందుబాటులో ఉన్న ఆపరేటర్‌ల జాబితాను ప్రచురించడానికి మరియు ఇప్పటికే ఇన్‌స్టాల్ చేయబడిన వాటికి నవీకరణలను అందించడానికి అంతర్నిర్మిత ఆపరేటర్‌హబ్ నుండి ఆపరేటర్‌లను ఉపయోగిస్తుంది. OpenShift 4 యొక్క పెరుగుతున్న ప్రజాదరణతో, ప్రపంచవ్యాప్తంగా దానిపై ఉన్న క్లస్టర్ల సంఖ్య కూడా పెరిగింది. ఈ క్లస్టర్‌లలో ప్రతి ఒక్కటి quay.ioలోని యాప్ రిజిస్ట్రీని బ్యాకెండ్‌గా ఉపయోగించి, అంతర్నిర్మిత ఆపరేటర్‌హబ్‌ను అమలు చేయడానికి ఆపరేటర్ కంటెంట్‌ను డౌన్‌లోడ్ చేస్తుంది. సమస్య యొక్క మూలం కోసం మా శోధనలో, OpenShift క్రమంగా జనాదరణ పొందుతున్నందున, అరుదుగా ఉపయోగించే quay.io ఫంక్షన్‌లలో ఒకదానిపై లోడ్ కూడా పెరిగింది అనే వాస్తవాన్ని మేము కోల్పోయాము..
మేము యాప్ రిజిస్ట్రీ అభ్యర్థన ట్రాఫిక్ గురించి కొంత విశ్లేషణ చేసాము మరియు రిజిస్ట్రీ కోడ్‌ని పరిశీలించాము. వెంటనే, లోపాలు వెల్లడయ్యాయి, దీని కారణంగా డేటాబేస్కు ప్రశ్నలు సరైన రీతిలో ఏర్పడలేదు. భారం తగ్గినపుడు ఎలాంటి ఇబ్బందులు కలగకపోగా, లోడ్ పెరిగిపోవడంతో సమస్యలకు మూలంగా మారాయి. యాప్ రిజిస్ట్రీ రెండు సమస్యాత్మక ఎండ్‌పాయింట్‌లను కలిగి ఉంది, అవి పెరుగుతున్న లోడ్‌కు బాగా స్పందించలేదు: మొదటిది రిపోజిటరీలోని అన్ని ప్యాకేజీల జాబితాను అందించింది, రెండవది ప్యాకేజీ కోసం అన్ని బ్లాబ్‌లను అందించింది.
కారణాల తొలగింపు
తదుపరి వారంలో మేము యాప్ రిజిస్ట్రీ యొక్క కోడ్‌ను మరియు దాని పర్యావరణాన్ని ఆప్టిమైజ్ చేసాము. స్పష్టంగా పనికిరాని SQL ప్రశ్నలు తిరిగి పని చేయబడ్డాయి మరియు అనవసరమైన కమాండ్ కాల్‌లు తొలగించబడ్డాయి tar (బ్లాబ్‌లను తిరిగి పొందిన ప్రతిసారీ ఇది అమలు చేయబడుతుంది), సాధ్యమైన చోట కాషింగ్ జోడించబడింది. మేము విస్తృతమైన పనితీరు పరీక్షను నిర్వహించాము మరియు మార్పులకు ముందు మరియు తర్వాత యాప్ రిజిస్ట్రీ వేగాన్ని పోల్చాము.
మునుపు అర నిమిషం వరకు పట్టే API అభ్యర్థనలు ఇప్పుడు మిల్లీసెకన్లలో పూర్తయ్యాయి. తరువాతి వారం మేము ఉత్పత్తికి మార్పులను అమలు చేసాము మరియు అప్పటి నుండి quay.io స్థిరంగా పని చేస్తోంది. ఈ సమయంలో, యాప్ రిజిస్ట్రీ ఎండ్‌పాయింట్‌లో ట్రాఫిక్‌లో అనేక పదునైన స్పైక్‌లు ఉన్నాయి, అయితే చేసిన మెరుగుదలలు డేటాబేస్ అంతరాయాలను నిరోధించాయి.
మనం ఏమి నేర్చుకున్నాము?
ఏదైనా సేవ పనికిరాని సమయాన్ని నివారించడానికి ప్రయత్నిస్తుందని స్పష్టమవుతుంది. మా విషయంలో, ఇటీవలి అంతరాయాలు quay.ioని మెరుగుపరచడంలో సహాయపడతాయని మేము నమ్ముతున్నాము. మేము భాగస్వామ్యం చేయాలనుకుంటున్న కొన్ని కీలక పాఠాలను నేర్చుకున్నాము:
- మీ సేవను ఎవరు ఉపయోగిస్తున్నారు మరియు ఎలా ఉపయోగించాలి అనే దాని గురించి డేటా ఎప్పుడూ నిరుపయోగంగా ఉండదు. క్వే "ఇప్పుడే పని చేసింది," మేము ట్రాఫిక్‌ను ఆప్టిమైజ్ చేయడానికి మరియు లోడ్‌ని నిర్వహించడానికి సమయాన్ని వెచ్చించాల్సిన అవసరం లేదు. ఇవన్నీ సేవ నిరవధికంగా స్కేల్ చేయగల తప్పుడు భద్రతా భావాన్ని సృష్టించాయి.
- సేవ తగ్గినప్పుడు, దాన్ని తిరిగి పొందడం మరియు అమలు చేయడం అత్యంత ప్రాధాన్యత.. మొదటి అంతరాయం సమయంలో క్వే లాక్ చేయబడిన డేటాబేస్‌తో బాధపడుతూనే ఉన్నందున, మా ప్రామాణిక విధానాలు ఆశించిన ప్రభావాన్ని చూపలేదు మరియు మేము వాటిని ఉపయోగించి సేవను పునరుద్ధరించలేకపోయాము. ఇది కార్యాచరణను పునరుద్ధరించడంపై అన్ని ప్రయత్నాలను కేంద్రీకరించే బదులు - మూలకారణాన్ని కనుగొనాలనే ఆశతో డేటాను విశ్లేషించడానికి మరియు సేకరించడానికి సమయాన్ని వెచ్చించాల్సిన పరిస్థితికి దారితీసింది.
- ప్రతి సర్వీస్ ఫీచర్ యొక్క ప్రభావాన్ని అంచనా వేయండి. క్లయింట్లు యాప్ రిజిస్ట్రీని చాలా అరుదుగా ఉపయోగించారు, కాబట్టి ఇది మా బృందానికి ప్రాధాన్యత కాదు. కొన్ని ఉత్పత్తి ఫీచర్‌లు ఉపయోగించబడనప్పుడు, వాటి బగ్‌లు చాలా అరుదుగా కనిపిస్తాయి మరియు డెవలపర్‌లు కోడ్‌ని పర్యవేక్షించడం మానేస్తారు. అకస్మాత్తుగా ఆ ఫంక్షన్ ఒక పెద్ద సంఘటనకు కేంద్రబిందువుగా కనిపించే వరకు ఇది ఇలాగే ఉండాలి అనే అపోహకు గురికావడం సులభం.
తరువాత ఏమిటి?
సేవ యొక్క స్థిరత్వాన్ని నిర్ధారించే పని ఎప్పుడూ ఆగదు మరియు మేము దానిని నిరంతరం మెరుగుపరుస్తాము. quay.ioలో ట్రాఫిక్ వాల్యూమ్‌లు పెరుగుతూనే ఉన్నందున, మా కస్టమర్ల నమ్మకానికి అనుగుణంగా జీవించడానికి మేము చేయగలిగినదంతా చేయాల్సిన బాధ్యత మాపై ఉందని మేము గుర్తించాము. కాబట్టి, మేము ప్రస్తుతం ఈ క్రింది పనులపై పని చేస్తున్నాము:
- ప్రైమరీ RDS ఉదంతంతో సమస్యలు ఎదురైనప్పుడు తగిన ట్రాఫిక్‌ని నిర్వహించడానికి సేవకు సహాయం చేయడానికి చదవడానికి మాత్రమే డేటాబేస్ ప్రతిరూపాలను అమలు చేయండి.
- RDS ఉదాహరణను నవీకరిస్తోంది. ప్రస్తుత సంస్కరణ సమస్య కాదు. బదులుగా, మేము తప్పుడు మార్గాన్ని తీసివేయాలనుకుంటున్నాము (మేము వైఫల్యం సమయంలో అనుసరించాము); సాఫ్ట్‌వేర్‌ను తాజాగా ఉంచడం వల్ల భవిష్యత్తులో అంతరాయాలు సంభవించే సందర్భంలో మరొక అంశం తొలగించబడుతుంది.
- మొత్తం క్లస్టర్‌లో అదనపు కాషింగ్. కాషింగ్ డేటాబేస్‌పై లోడ్‌ను తగ్గించగల ప్రాంతాల కోసం మేము వెతకడం కొనసాగిస్తాము.
- quay.ioకి ఎవరు కనెక్ట్ అవుతున్నారో మరియు ఎందుకు కనెక్ట్ అవుతున్నారో చూడటానికి వెబ్ అప్లికేషన్ ఫైర్‌వాల్ (WAF)ని జోడిస్తోంది.
- తదుపరి విడుదలతో ప్రారంభించి, Red Hat OpenShift క్లస్టర్‌లు quay.ioలో అందుబాటులో ఉన్న కంటైనర్ ఇమేజ్‌ల ఆధారంగా ఆపరేటర్ కేటలాగ్‌లకు అనుకూలంగా యాప్ రిజిస్ట్రీని వదిలివేస్తాయి.
- యాప్ రిజిస్ట్రీకి దీర్ఘకాలిక ప్రత్యామ్నాయం ఓపెన్ కంటైనర్ ఇనిషియేటివ్ (OCI) ఆర్టిఫ్యాక్ట్ స్పెసిఫికేషన్‌లకు మద్దతుగా ఉంటుంది. ఇది ప్రస్తుతం స్థానిక క్వే ఫంక్షనాలిటీగా అమలు చేయబడింది మరియు స్పెసిఫికేషన్ ఖరారు అయినప్పుడు వినియోగదారులకు అందుబాటులో ఉంటుంది.
మేము చిన్న "స్టార్టప్-స్టైల్" టీమ్ నుండి పరిపక్వ SRE-ఆధారిత ప్లాట్‌ఫారమ్‌కి మారినప్పుడు పైన పేర్కొన్నవన్నీ quay.ioలో Red Hat యొక్క కొనసాగుతున్న పెట్టుబడిలో భాగం. మా కస్టమర్‌లలో చాలా మంది తమ రోజువారీ పనిలో (Red Hat! సహా) quay.ioపై ఆధారపడతారని మాకు తెలుసు మరియు మేము ఇటీవలి అంతరాయాలు మరియు మెరుగుపరచడానికి జరుగుతున్న ప్రయత్నాల గురించి వీలైనంత పారదర్శకంగా ఉండటానికి ప్రయత్నిస్తాము.
అనువాదకుని నుండి PS
మా బ్లాగులో కూడా చదవండి:
- «";
- «";
- «".
మూలం: www.habr.com