સળગાવવાની સેવા ગ્રીડ - રીબૂટ કરો

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

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

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

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

વપરાશકર્તા સમગ્ર ક્લસ્ટરમાં સેવાના દાખલાઓની સંખ્યા પણ નિર્દિષ્ટ કરી શકે છે અને યોગ્ય નોડ્સને ફિલ્ટર કરવા માટે પૂર્વધારણા વ્યાખ્યાયિત કરી શકે છે. આ દૃશ્યમાં, સર્વિસ ગ્રીડ પોતે સેવાઓ જમાવવા માટે શ્રેષ્ઠ વિતરણની ગણતરી કરશે.

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

હવે જ્યારે આપણે જાણી લીધું છે કે સર્વિસ ગ્રીડની સુંદરતા શું છે, ચાલો તેના વિકાસ ઇતિહાસ વિશે વાત કરીએ.

પહેલા શું થયું

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

જ્યારે વપરાશકર્તા સેવા જમાવવા માંગે ત્યારે શું થયું?

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

જે અમને અનુકૂળ ન હતું

અમુક સમયે અમે નિષ્કર્ષ પર આવ્યા: સેવાઓ સાથે કામ કરવાનો આ રસ્તો નથી. તેના અનેક કારણો હતા.

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

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

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

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

સમસ્યાઓ

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

આ એક અલગ સૂચિમાં એકત્રિત કરી શકાય તેવી સમસ્યાઓમાંથી એક છે:

• નોડ સ્ટાર્ટઅપ પર સ્ટેટિકલી રૂપરેખાંકિત સેવાઓ કેવી રીતે જમાવવી?
• ક્લસ્ટરમાંથી નોડ છોડવું - જો નોડ સેવાઓ હોસ્ટ કરે તો શું કરવું?
• જો સંયોજક બદલાઈ ગયો હોય તો શું કરવું?
• જો ક્લાયન્ટ ક્લસ્ટર સાથે ફરીથી કનેક્ટ થાય તો શું કરવું?
• શું સક્રિયકરણ/નિષ્ક્રિયકરણ વિનંતીઓ પર પ્રક્રિયા કરવાની જરૂર છે અને કેવી રીતે?
• જો તેઓ કેશ વિનાશ માટે બોલાવે અને અમારી પાસે એફિનિટી સેવાઓ તેની સાથે જોડાયેલ હોય તો શું?

અને તે બધુ જ નથી.

નિર્ણય

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

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

ચાલો જમાવટ પ્રોટોકોલ જોઈએ. ડિપ્લોયમેન્ટ અને અનડેપ્લોયમેન્ટ માટેની તમામ વપરાશકર્તા વિનંતીઓ ડિસ્કવરી-સ્પી દ્વારા મોકલવામાં આવે છે. આ નીચેના આપે છે ગેરંટી:

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

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

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

1. દરેક નોડ સ્વતંત્ર રીતે નવા નિર્ધારિત સોંપણી કાર્યને આભારી વિતરણની ગણતરી કરે છે.
2. નોડ્સ જમાવટના પરિણામો સાથે એક સંદેશ જનરેટ કરે છે અને તેને કોઓર્ડિનેટરને મોકલે છે.
3. કોઓર્ડિનેટર તમામ સંદેશાઓને એકત્ર કરે છે અને સમગ્ર જમાવટ પ્રક્રિયાનું પરિણામ જનરેટ કરે છે, જે ડિસ્કવરી-સ્પી દ્વારા ક્લસ્ટરમાંના તમામ નોડ્સ પર મોકલવામાં આવે છે.
4. જ્યારે પરિણામ પ્રાપ્ત થાય છે, ત્યારે જમાવટ પ્રક્રિયા સમાપ્ત થાય છે, જેના પછી કાર્ય કતારમાંથી દૂર કરવામાં આવે છે.

નવી ઇવેન્ટ આધારિત ડિઝાઇન: org.apache.ignite.internal.processors.service.IgniteServiceProcessor.java

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

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

આગળ શું થશે

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

અમે IEP માં કાર્યોને 2 તબક્કામાં વિભાજિત કર્યા છે. પ્રથમ એક મુખ્ય તબક્કો છે, જેમાં જમાવટ પ્રોટોકોલને ફરીથી કામ કરવાનો સમાવેશ થાય છે. તે પહેલાથી જ માસ્ટરમાં શામેલ છે, તમે નવી સર્વિસ ગ્રીડનો પ્રયાસ કરી શકો છો, જે સંસ્કરણ 2.8 માં દેખાશે. બીજા તબક્કામાં અન્ય ઘણા કાર્યો શામેલ છે:

• ગરમ પુનઃઉપયોગ
• સેવા આવૃત્તિ
• દોષ સહનશીલતામાં વધારો
• પાતળા ક્લાયંટ
• વિવિધ મેટ્રિક્સની દેખરેખ અને ગણતરી માટેના સાધનો

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

સોર્સ: www.habr.com