Забелешка. превод.: на почетокот на август, Red Hat јавно зборуваше за решавање на проблемите со пристапноста со кои се сретнаа корисниците на нејзината услуга во претходните месеци (се базира на регистар за слики од контејнери, кои компанијата ги доби заедно со купувањето на CoreOS). Без оглед на вашиот интерес за оваа услуга како таква, патот што го поминаа инженерите на SRE на компанијата за да ги дијагностицираат и елиминираат причините за несреќата е поучен.
На 19 мај, рано наутро (Источно летно сметање на времето, EDT), се урна услугата quay.io. Несреќата ги погоди и корисниците на quay.io и проектите со отворен код што го користат quay.io како платформа за градење и дистрибуција на софтвер. Red Hat ја цени довербата на двајцата.
Тим од инженери на SRE веднаш се вклучи и се обиде што поскоро да ја стабилизира услугата на Кејот. Меѓутоа, додека го правеа ова, клиентите ја изгубија способноста да туркаат нови слики и само повремено можеа да ги повлечат постоечките. Од некоја непозната причина, базата на податоци на quay.io беше блокирана по скалирањето на услугата до полн капацитет.
«Што се смени?“ – ова е првото прашање што вообичаено се поставува во вакви случаи. Забележавме дека непосредно пред изданието, OpenShift Dedicated кластерот (кој работи на quay.io) започна да се ажурира на верзијата 4.3.19. Бидејќи quay.io работи на Red Hat OpenShift Dedicated (OSD), редовните ажурирања беа рутински и никогаш не предизвикуваа проблеми. Покрај тоа, во текот на претходните шест месеци, неколку пати ги надградивме кластерите на Кеј без никаков прекин во сервисот.
Додека се обидувавме да ја вратиме услугата, други инженери почнаа да подготвуваат нов кластер за OSD со претходната верзија на софтверот, така што ако се случи нешто, тие можат да распоредат сè на него.
Анализа на корените причини
Главниот симптом на неуспехот беше лавина од десетици илјади конекции со бази на податоци, што го направи примерот на MySQL ефективно нефункционален. Ова го отежна дијагностицирањето на проблемот. Поставивме ограничување на максималниот број на врски од клиенти за да му помогнеме на тимот на SRE да го оцени проблемот. Не забележавме необичен сообраќај кон базата на податоци: всушност, повеќето барања беа прочитани, а само неколку беа запишувани.
Исто така, се обидовме да идентификуваме шема во сообраќајот на базата на податоци што може да ја предизвика оваа лавина. Сепак, не можевме да најдеме никакви обрасци во дневниците. Додека чекавме да биде подготвен новиот кластер со OSD 4.3.18, продолживме да се обидуваме да лансираме quay.io pods. Секој пат кога кластерот ќе достигне полн капацитет, базата на податоци се замрзнува. Ова значеше дека е неопходно да се рестартира примерокот на RDS како додаток на сите quay.io pods.
До вечерта, ја стабилизиравме услугата во режим само за читање и оневозможивме што е можно повеќе несуштински функции (на пример, собирање ѓубре во именскиот простор) за да го намалиме оптоварувањето на базата на податоци. Замрзнувањата престанаа но причината никогаш не беше пронајдена. Новиот OSD кластер беше подготвен и ја префрливме услугата, го поврзавме сообраќајот и продолживме со мониторингот.
Quay.io работеше стабилно на новиот OSD кластер, па се вративме на дневниците на базата на податоци, но не можевме да најдеме корелација што ќе ги објасни блокирањата. Инженерите на OpenShift работеа со нас за да разберат дали промените во Red Hat OpenShift 4.3.19 може да предизвикаат проблеми со Quay. Сепак, ништо не беше пронајдено, и Не беше можно да се репродуцира проблемот во лабораториски услови.
Втор неуспех
На 28 мај, непосредно пред пладне EDT, quay.io повторно падна со истиот симптом: базата на податоци беше блокирана. И повторно ги вложивме сите наши напори во истрагата. Пред сè, беше неопходно да се врати услугата. Сепак овој пат рестартирањето на RDS и рестартирањето на pods на quay.io не доведоа до ништо: уште една лавина од врски ја преплави базата. Но зошто?
Кејот е напишан во Python и секој pod работи како единствен монолитен контејнер. Времето на извршување на контејнерот извршува многу паралелни задачи истовремено. Ја користиме библиотеката gevent под gunicorn за обработка на веб-барања. Кога барањето доаѓа во Quay (преку нашето сопствено API или преку Docker API), му се доделува gevent работник. Обично овој работник треба да ја контактира базата на податоци. По првиот неуспех, откривме дека работниците на gevent се поврзуваат со базата на податоци користејќи стандардни поставки.
Со оглед на значителниот број на Quay pods и илјадниците дојдовни барања во секунда, голем број на поврзувања со базата на податоци теоретски би можеле да го надминат примерот на MySQL. Благодарение на мониторингот беше познато дека Кеј во просек обработува 5 илјади барања во секунда. Бројот на врски со базата на податоци беше приближно ист. 5 илјади конекции беа целосно во рамките на можностите на нашиот пример RDS (што не може да се каже за десетици илјади). Поради некоја причина имаше неочекувани скокови во бројот на врски, сепак, не забележавме никаква корелација со дојдовните барања.
Овој пат бевме решени да го пронајдеме и елиминираме изворот на проблемот, а не да се ограничуваме на рестартирање. До базата на кодови на Кеј беа направени промени за да се ограничи бројот на врски со базата на податоци за секој работник gevent. Овој број стана параметар во конфигурацијата: стана возможно да се промени во лет без да се изгради нова слика на контејнер. За да откриеме со колку конекции може реално да се постапува, извршивме неколку тестови во опкружување за поставување, поставувајќи различни вредности за да видиме како тоа ќе влијае на сценаријата за тестирање на оптоварување. Како резултат на тоа, беше откриено дека Кејот почнува да фрла 502 грешки кога бројот на приклучоци ќе надмине 10 илјади.
Веднаш ја распоредивме оваа нова верзија во производство и почнавме да го следиме распоредот за поврзување со базата на податоци. Во минатото, базата беше заклучена по околу 20 минути. По 30 минути без проблеми имавме надеж, а еден час подоцна имавме доверба. Го вративме сообраќајот на локацијата и започнавме постмортемска анализа.
Откако успеа да го заобиколи проблемот што доведе до блокирање, не ги дознавме неговите вистински причини. Потврдено е дека не е поврзано со никакви промени во OpenShift 4.3.19, бидејќи истото се случи и на верзијата 4.3.18, која претходно работеше со Quay без никакви проблеми.
Очигледно нешто друго демнеше во кластерот.
Детална студија
Quay.io ги користеше стандардните поставки за да се поврзе со базата на податоци шест години без никакви проблеми. Што се смени? Јасно е дека сето ова време сообраќајот на quay.io постојано расте. Во нашиот случај, изгледаше како да е достигната некоја праг вредност, што служеше како активирач за лавина од врски. Продолживме да ги проучуваме дневниците на базата на податоци по вториот неуспех, но не најдовме никакви обрасци или очигледни врски.
Во меѓувреме, тимот на SRE работи на подобрувања на забележливоста на барањата на Кеј и целокупното здравје на услугите. Употребени се нови метрики и контролни табли, покажувајќи кои делови од Кејот се најбарани од клиентите.
Quay.io работеше добро до 9-ти јуни. Утрово (EDT) повторно видовме значително зголемување на бројот на поврзувања со бази на податоци. Овој пат немаше застој, бидејќи новиот параметар го ограничи нивниот број и не им дозволуваше да ја надминат пропусната моќ на MySQL. Сепак, околу половина час, многу корисници забележаа бавни перформанси на quay.io. Брзо ги собравме сите можни податоци користејќи ги додадените алатки за следење. Одеднаш се појави шема.
Непосредно пред напливот на врски, беа направени голем број барања до АПИ-то за регистар на апликации. Регистарот на апликации е малку позната карактеристика на quay.io. Тоа ви овозможува да складирате работи како дијаграми на Helm и контејнери со богати метаподатоци. Повеќето корисници на quay.io не работат со оваа функција, но Red Hat OpenShift активно ја користи. OperatorHub како дел од OpenShift ги складира сите оператори во Регистарот на апликации. Овие оператори ја формираат основата за екосистемот на оптоварување на работа OpenShift и оперативниот модел фокусиран на партнерите (оперативност на Ден 2).
Секој кластер OpenShift 4 користи оператори од вградениот OperatorHub за да објави каталог на оператори достапни за инсталација и да обезбеди ажурирања на веќе инсталираните. Со зголемената популарност на OpenShift 4, се зголеми и бројот на кластери на него низ целиот свет. Секој од овие кластери презема содржини од операторот за да го стартува вградениот OperatorHub, користејќи го Регистарот на апликации во quay.io како заднина. Во потрагата по изворот на проблемот, го пропуштивме фактот дека како што OpenShift постепено растеше во популарност, се зголемуваше и оптоварувањето на една од ретко користените функции quay.io..
Направивме одредена анализа на сообраќајот на барањата во Регистарот на апликации и го разгледавме кодот на регистарот. Веднаш беа откриени недостатоци, поради што барањата до базата не беа оптимално формирани. Кога товарот беше мал, тие не правеа проблеми, но кога товарот се зголеми, тие станаа извор на проблеми. Се покажа дека Регистарот на апликации има две проблематични крајни точки кои не реагираа добро на зголеменото оптоварување: првата обезбеди листа на сите пакети во складиштето, втората ги врати сите блузони за пакетот.
Елиминација на причините
Во текот на следната недела потрошивме оптимизирање на кодот на самиот регистар на апликации и неговата околина. Очигледно неефективните SQL прашања беа преработени и непотребните командни повици беа елиминирани tar (се извршуваше секој пат кога се вадеа дамки), се додаваше кеширање каде што беше можно. Потоа спроведовме опширно тестирање на перформансите и ја споредивме брзината на Регистарот на апликации пред и по промените.
Барањата за API кои претходно траеја до половина минута сега се комплетираат во милисекунди. Следната недела ги распоредивме промените во производството и оттогаш quay.io работи стабилно. Во тоа време, имаше неколку остри скокови во сообраќајот на крајната точка на Регистарот на апликации, но направените подобрувања спречија прекини на базата на податоци.
Што научивме?
Јасно е дека секоја услуга се обидува да избегне застој. Во нашиот случај, веруваме дека неодамнешните прекини помогнаа да се подобри quay.io. Научивме неколку клучни лекции кои би сакале да ги споделиме:
- Податоците за тоа кој и како ја користи вашата услуга никогаш не се излишни. Бидејќи Кејот „штотуку работеше“, никогаш не моравме да трошиме време за оптимизирање на сообраќајот и управување со товарот. Сето ова создаде лажно чувство на сигурност што услугата може да го размери на неодредено време.
- Кога услугата ќе се намали, повторното активирање и работа е главен приоритет.. Бидејќи Кеј продолжи да страда од заклучена база на податоци за време на првиот прекин, нашите стандардни процедури го немаа предвидениот ефект и не можевме да ја вратиме услугата користејќи ги. Ова доведе до ситуација кога требаше да се потроши време за анализа и собирање податоци со надеж дека ќе се најде основната причина - наместо да се фокусираат сите напори на враќање на функционалноста.
- Оценете го влијанието на секоја карактеристика на услугата. Клиентите ретко користеа Регистар на апликации, така што тоа не беше приоритет за нашиот тим. Кога некои карактеристики на производот едвај се користат, нивните грешки ретко се појавуваат, а програмерите престануваат да го следат кодот. Лесно е да станете жртва на заблудата дека така треба да биде - додека ненадејно таа функција не се најде во центарот на голем инцидент.
Што е следно?
Работата за обезбедување стабилност на услугата никогаш не запира и ние постојано ја подобруваме. Бидејќи обемот на сообраќајот продолжува да расте на quay.io, признаваме дека имаме одговорност да направиме се што можеме за да ја исполниме довербата на нашите клиенти. Затоа, во моментов работиме на следните задачи:
- Распоредете реплики на бази на податоци само за читање за да и помогнете на услугата да се справи со соодветен сообраќај во случај на проблеми со примарната инстанца RDS.
- Ажурирање на пример RDS. Тековната верзија сама по себе не е проблем. Наместо тоа, ние едноставно сакаме да ја отстраниме лажната трага (која ја следевме за време на неуспехот); Одржувањето на софтверот ажуриран ќе елиминира уште еден фактор во случај на идни прекини.
- Дополнително кеширање низ целиот кластер. Продолжуваме да бараме области каде кеширањето може да го намали оптоварувањето на базата на податоци.
- Додавање заштитен ѕид за веб-апликации (WAF) за да се види кој се поврзува со quay.io и зошто.
- Почнувајќи од следното издание, кластерите на Red Hat OpenShift ќе го напуштат Регистарот на апликации во корист на каталозите на оператори базирани на слики од контејнери достапни на quay.io.
- Долгорочна замена за регистарот на апликации може да биде поддршка за спецификациите на артефактот на иницијативата за отворен контејнер (OCI). Моментално е имплементирана како функционалност на мајчин Кеј и ќе биде достапна за корисниците кога самата спецификација ќе биде финализирана.
Сето горенаведено е дел од тековната инвестиција на Red Hat во quay.io додека преминуваме од мал тим во „стил на стартап“ кон зрела платформа управувана од SRE. Знаеме дека многу од нашите клиенти се потпираат на quay.io во нивната секојдневна работа (вклучувајќи ја и Red Hat!) и се трудиме да бидеме што е можно потранспарентни за неодамнешните прекини и тековните напори за подобрување.
PS од преведувач
Прочитајте и на нашиот блог:
- «";
- «";
- «".
Извор: www.habr.com