Istio સર્કિટ બ્રેકર: ખામીયુક્ત કન્ટેનરને અક્ષમ કરવું

રજાઓ પૂરી થઈ ગઈ છે અને અમે ઈસ્ટિઓ સર્વિસ મેશ શ્રેણીમાં અમારી બીજી પોસ્ટ સાથે પાછા ફર્યા છીએ.

આજનો વિષય સર્કિટ બ્રેકર છે, જેનો રશિયન વિદ્યુત ઇજનેરીમાં અનુવાદ થાય છે જેનો અર્થ થાય છે "સર્કિટ બ્રેકર", સામાન્ય ભાષામાં - "સર્કિટ બ્રેકર". માત્ર Istio માં આ મશીન ટૂંકા અથવા ઓવરલોડ સર્કિટને ડિસ્કનેક્ટ કરતું નથી, પરંતુ ખામીયુક્ત કન્ટેનર.

આ કેવી રીતે આદર્શ રીતે કામ કરવું જોઈએ

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

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

તે ખરેખર કેવી રીતે કામ કરે છે

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

Istio માં પૂલ ઇજેક્શન શું છે

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

આઉટલીયર ડિટેક્શન વ્યૂહરચનાનો ઉપયોગ કરીને, Istio કર્વ પોડ્સ શોધી કાઢે છે જે લાઇનની બહાર છે અને તેમને રિસોર્સ પૂલમાંથી ચોક્કસ સમય માટે દૂર કરે છે, જેને સ્લીપ વિન્ડો કહેવાય છે.

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

ક્રેશ માટે તૈયાર થઈ રહ્યા છીએ

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

oc scale deployment recommendation-v2 --replicas=2 -n tutorial

હવે અમે એક રૂટીંગ નિયમ સેટ કરીએ છીએ જેથી ટ્રાફિકને પોડ વચ્ચે 50/50 રેશિયોમાં વહેંચવામાં આવે.

આ નિયમનું પરિણામ કેવું દેખાય છે તે અહીં છે:

તમે એ હકીકતમાં ખામી શોધી શકો છો કે આ સ્ક્રીન 50/50 નથી, પરંતુ 14:9 છે, પરંતુ સમય જતાં પરિસ્થિતિમાં સુધારો થશે.

ભૂલ કરવી

હવે ચાલો બે v2 કન્ટેનરમાંથી એકને અક્ષમ કરીએ જેથી અમારી પાસે એક સ્વસ્થ v1 કન્ટેનર, એક સ્વસ્થ v2 કન્ટેનર અને એક ખામીયુક્ત v2 કન્ટેનર હોય:

ભૂલ સુધારવા

તેથી, અમારી પાસે ખામીયુક્ત કન્ટેનર છે, અને તે પૂલ ઇજેક્શનનો સમય છે. ખૂબ જ સરળ રૂપરેખાનો ઉપયોગ કરીને, અમે આ નિષ્ફળ કન્ટેનરને કોઈપણ રૂટીંગ સ્કીમમાંથી 15 સેકન્ડ માટે બાકાત રાખીશું કે તે તંદુરસ્ત સ્થિતિમાં પાછા આવશે (કાં તો પુનઃપ્રારંભ કરો અથવા પ્રદર્શન પુનઃસ્થાપિત કરો). આ રૂપરેખા આના જેવી દેખાય છે અને તેના કાર્યના પરિણામો:

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

ચાલો આર્કિટેક્ચર બનાવવાનું શરૂ કરીએ

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

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

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

સિદ્ધાંતમાં સર્કિટ બ્રેકર

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

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

વ્યવહારમાં સર્કિટ બ્રેકર

ઉદાહરણ તરીકે, અમે OpenShift પર અમારી ભલામણ માઇક્રોસર્વિસના બે વર્ઝન ચલાવીશું. સંસ્કરણ 1 સારું કામ કરશે, પરંતુ v2 માં અમે સર્વર પર સ્લોડાઉનનું અનુકરણ કરવા માટે વિલંબમાં નિર્માણ કરીશું. પરિણામો જોવા માટે, સાધનનો ઉપયોગ કરો ઘેરો:

siege -r 2 -c 20 -v customer-tutorial.$(minishift ip).nip.io

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

આ કરવા માટે, અમે ધીમા કન્ટેનર પરના કૉલ્સને દૂર કરવા માટે Istio નો ઉપયોગ કરીશું. સર્કિટ બ્રેકરનો ઉપયોગ કરીને અનુરૂપ રૂપરેખા આના જેવી દેખાય છે:

httpMaxRequestsPerConnection પરિમાણ સાથેની છેલ્લી લાઇન સંકેત આપે છે કે જ્યારે હાલના એક ઉપરાંત બીજું - સેકન્ડ - કનેક્શન બનાવવાનો પ્રયાસ કરી રહ્યા હોય ત્યારે સાથેનું કનેક્શન ડિસ્કનેક્ટ થવું જોઈએ. કારણ કે અમારું કન્ટેનર ધીમી સેવાનું અનુકરણ કરે છે, આવી પરિસ્થિતિઓ સમયાંતરે ઊભી થશે, અને પછી Istio 503 ભૂલ આપશે, પરંતુ આ તે છે જે સીઝ બતાવશે:

ઠીક છે, અમારી પાસે સર્કિટ બ્રેકર છે, આગળ શું છે?

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

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

આગલી પોસ્ટમાં: અમે ટ્રેસિંગ અને મોનિટરિંગ વિશે વાત કરીશું જે પહેલેથી જ બિલ્ટ-ઇન છે અથવા Istio માં સરળતાથી ઉમેરવામાં આવી છે, તેમજ સિસ્ટમમાં ઇરાદાપૂર્વક ભૂલો કેવી રીતે દાખલ કરવી તે વિશે.

સોર્સ: www.habr.com