ઓટોમેટીંગ ડિસ્ક રિપ્લેસમેન્ટ જવાબો સાથે

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

આ લેખ એક પ્રકારનું લિવ્યંતરણ છે પ્રદર્શન HighLoad+ 2018 પર

ડિસ્ક રિપ્લેસમેન્ટ પ્રક્રિયાનું નિર્માણ

પ્રથમ કેટલાક નંબરો

OK એ લાખો લોકો દ્વારા ઉપયોગમાં લેવાતી વિશાળ સેવા છે. તે લગભગ 7 હજાર સર્વર્સ દ્વારા સેવા આપવામાં આવે છે, જે 4 અલગ અલગ ડેટા સેન્ટરોમાં સ્થિત છે. સર્વરમાં 70 હજારથી વધુ ડિસ્ક છે. જો તમે તેમને એકબીજાની ટોચ પર સ્ટેક કરો છો, તો તમને 1 કિમીથી વધુ ઉંચો ટાવર મળશે.

હાર્ડ ડ્રાઈવ એ સર્વર ઘટક છે જે મોટાભાગે નિષ્ફળ જાય છે. આવા વોલ્યુમો સાથે, અમારે દર અઠવાડિયે લગભગ 30 ડિસ્ક બદલવી પડે છે, અને આ પ્રક્રિયા ખૂબ જ સુખદ નિયમિત બની નથી.

ઘટનાઓ

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

સંગ્રહ ઉપકરણો કોઈ અપવાદ નથી. Zabbix દ્વારા તેમની સ્થિતિનું નિરીક્ષણ કરવામાં આવે છે. અમે લખવા/વાંચવામાં ભૂલો માટે સિસ્લોગમાં સંદેશાઓનું નિરીક્ષણ કરીએ છીએ, HW/SW દરોડાની સ્થિતિનું વિશ્લેષણ કરીએ છીએ, SMARTનું નિરીક્ષણ કરીએ છીએ અને SSDs માટે વસ્ત્રોની ગણતરી કરીએ છીએ.

અગાઉ ડિસ્ક કેવી રીતે બદલાઈ હતી

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

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

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

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

વધુમાં, એન્જિનિયર યોગ્ય રીતે પ્રાથમિકતાઓ સેટ કરી શક્યો નથી, કારણ કે તે ચોક્કસ સર્વર્સના હેતુ વિશે અથવા ડ્રાઇવ્સ વચ્ચેની માહિતીના વિતરણ વિશે કશું જ જાણતો નથી.

નવી બદલી પ્રક્રિયા

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

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

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

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

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

અગાઉ તે આના જેવું હતું:

આ રીતે એન્જિનિયરો આજે પણ કામ કરવાનું ચાલુ રાખે છે જ્યારે તેમને એડમિનિસ્ટ્રેટરની મદદની જરૂર નથી.

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

અમે સ્ટેટસ પણ ઉમેર્યું તૈયાર. ડિસ્કને બદલ્યા પછી ટિકિટ તેને ટ્રાન્સફર કરવામાં આવે છે. એટલે કે, બધું પહેલેથી જ થઈ ગયું છે, પરંતુ HW/SW RAID સર્વર પર સમન્વયિત છે. આમાં ઘણો સમય લાગી શકે છે.

જો કોઈ એડમિનિસ્ટ્રેટર કામમાં સામેલ હોય, તો યોજના થોડી વધુ જટિલ બની જાય છે.

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

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

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

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

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

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

વર્કફ્લો બનાવતી વખતે શીખેલા પાઠ

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

ડિસ્ક રિપ્લેસમેન્ટનું ઓટોમેશન

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

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

ઝૂ સેટઅપ્સ

આપણે બોટ વિશે વાત કરીએ તે પહેલાં, ચાલો આપણા સ્થાપનોના પ્રાણી સંગ્રહાલયમાં એક નાનકડું પ્રવાસ લઈએ. સૌ પ્રથમ, તે આપણા ઈન્ફ્રાસ્ટ્રક્ચરના વિશાળ કદને કારણે છે. બીજું, અમે દરેક સેવા માટે શ્રેષ્ઠ હાર્ડવેર ગોઠવણી પસંદ કરવાનો પ્રયાસ કરીએ છીએ. અમારી પાસે લગભગ 20 હાર્ડવેર RAID મોડલ્સ છે, જેમાં મોટાભાગે LSI અને Adaptec છે, પરંતુ HP અને DELL વિવિધ સંસ્કરણો પણ છે. દરેક RAID નિયંત્રક તેની પોતાની વ્યવસ્થાપન ઉપયોગિતા ધરાવે છે. દરેક RAID નિયંત્રક માટે આદેશોનો સમૂહ અને તેમને જારી કરવાની આવૃત્તિ અલગ અલગ હોઈ શકે છે. જ્યાં HW-RAID નો ઉપયોગ થતો નથી, ત્યાં mdraid નો ઉપયોગ થઈ શકે છે.

અમે લગભગ તમામ નવા ઇન્સ્ટોલેશન ડિસ્ક બેકઅપ વિના કરીએ છીએ. અમે હવે હાર્ડવેર અને સોફ્ટવેર RAID નો ઉપયોગ ન કરવાનો પ્રયાસ કરીએ છીએ, કારણ કે અમે અમારી સિસ્ટમ્સનો ડેટા સેન્ટર સ્તરે બેકઅપ લઈએ છીએ, સર્વર પર નહીં. પરંતુ અલબત્ત એવા ઘણા લેગસી સર્વર્સ છે જેને સપોર્ટ કરવાની જરૂર છે.

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

કુલ મળીને, અમારી પાસે લગભગ 400 વિવિધ એપ્લિકેશનો ચલાવતા 100 થી વધુ અનન્ય સર્વર જૂથો છે. આટલી મોટી સંખ્યામાં વિકલ્પોને આવરી લેવા માટે, અમને મલ્ટિફંક્શનલ ઓટોમેશન ટૂલની જરૂર છે. પ્રાધાન્યમાં એક સરળ DSL સાથે, જેથી માત્ર તે વ્યક્તિ જેણે તેને લખ્યું છે તે જ તેને સમર્થન આપી શકે.

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

સામાન્ય યોજના

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

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

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

પરિણામોના આધારે, બોટ આપમેળે ટિકિટને બદલવા માટે તૈયાર પર સ્થાનાંતરિત કરે છે. એન્જિનિયરને એક સૂચના મળે છે અને તે ડિસ્ક બદલવા જાય છે, ત્યારબાદ તે ટિકિટ ચેન્જ્ડમાં ટ્રાન્સફર કરે છે.

ઉપર વર્ણવેલ સ્કીમ મુજબ, ટિકિટ બૉટ પર પાછી જાય છે, જે બીજી પ્લેબુક લૉન્ચ કરે છે, હોસ્ટ પાસે જાય છે અને ડિસ્કને રોટેશનમાં મૂકે છે. બોટ ટિકિટ બંધ કરે છે. હુરે!

હવે ચાલો સિસ્ટમના કેટલાક ઘટકો વિશે વાત કરીએ.

ડિસ્કબોટ

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

JQL અને મતદાન અંતરાલો એપ્લીકેશન રૂપરેખાંકન ફાઇલમાં વ્યાખ્યાયિત થયેલ છે.

jira_states:
  investigate:
    jql: '… status = Open and "Disk Size" is EMPTY'
    interval: 180

  inprogress:
    jql: '…  and "Disk Size" is not EMPTY and "Device Name" is not EMPTY'
 
  ready:
    jql: '… and (labels not in ("dbot_ignore") or labels is EMPTY)'
    interval: 7200

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

અને તૈયાર સ્થિતિવાળી ટિકિટોમાંથી, dbot_ignore લેબલવાળી ટિકિટો ફિલ્ટર આઉટ થઈ જાય છે. માર્ગ દ્વારા, અમે આવા ફિલ્ટરિંગ માટે અને ડુપ્લિકેટ ટિકિટને ચિહ્નિત કરવા અને આંકડા એકત્રિત કરવા બંને માટે જીરા લેબલનો ઉપયોગ કરીએ છીએ.

જો પ્લેબુક નિષ્ફળ જાય, તો જીરા dbot_failed લેબલ સોંપે છે જેથી કરીને તેને પછીથી ઉકેલી શકાય.

Ansible સાથે આંતરકાર્યક્ષમતા

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

જવાબમાં પણ, *extra_vars* દ્વારા, બ્લોક ઉપકરણનું નામ, ટિકિટનું સ્ટેટસ, તેમજ callback_url, જેમાં ઈશ્યુ કી હોય છે - તેનો ઉપયોગ HTTP માં કોલબેક માટે થાય છે.

દરેક પ્રક્ષેપણ માટે, એક અસ્થાયી ઇન્વેન્ટરી જનરેટ કરવામાં આવે છે, જેમાં એક યજમાન અને આ યજમાન જે જૂથનું છે તેનો સમાવેશ થાય છે, જેથી જૂથ_વાર લાગુ કરવામાં આવે.

અહીં એક કાર્યનું ઉદાહરણ છે જે HTTP કૉલબેકનો અમલ કરે છે.

અમને કૉલબેક(ઓ) નો ઉપયોગ કરીને પ્લેબુક ચલાવવાનું પરિણામ મળે છે. તેઓ બે પ્રકારના હોય છે:

• જવાબી કૉલબેક પ્લગઇન, તે પ્લેબુક એક્ઝેક્યુશનના પરિણામો પર ડેટા પ્રદાન કરે છે. તે એવા કાર્યોનું વર્ણન કરે છે કે જે લોંચ કરવામાં આવ્યા હતા, સફળતાપૂર્વક પૂર્ણ થયા હતા અથવા નિષ્ફળ ગયા હતા. જ્યારે પ્લેબુક રમવાનું સમાપ્ત થઈ જાય ત્યારે આ કૉલબેક કહેવામાં આવે છે.
• પ્લેબુક ચલાવતી વખતે માહિતી મેળવવા માટે HTTP કૉલબેક. જવાબી કાર્યમાં અમે અમારી અરજી પર POST/GET વિનંતીનો અમલ કરીએ છીએ.

ચલોને HTTP કૉલબૅક(ઓ) દ્વારા પસાર કરવામાં આવે છે જે પ્લેબુકના અમલ દરમિયાન વ્યાખ્યાયિત કરવામાં આવ્યા હતા અને અમે તેને સાચવવા અને પછીના રનમાં ઉપયોગ કરવા માગીએ છીએ. અમે આ ડેટાને sqlite માં લખીએ છીએ.

અમે ટિપ્પણીઓ પણ છોડીએ છીએ અને HTTP કૉલબેક દ્વારા ટિકિટની સ્થિતિ બદલીએ છીએ.

HTTP કૉલબેક

# Make callback to Diskobot App
# Variables:
#    callback_post_body: # A dict with follow keys. All keys are optional
#       msg: If exist it would be posted to Jira as comment
#       data: If exist it would be saved in Incident.variables
#       desire_state: Set desire_state for incident
#       status: If exist Proceed issue to that status

  - name: Callback to Diskobot app (jira comment/status)
    uri:
      url: "{{ callback_url }}/{{ devname }}"
      user: "{{ diskobot_user }}"
      password: "{{ diskobot_pass }}"
      force_basic_auth: True
      method: POST
      body: "{{ callback_post_body | to_json }}"
      body_format: json
    delegate_to: 127.0.0.1

સમાન પ્રકારનાં ઘણાં કાર્યોની જેમ, અમે તેને એક અલગ સામાન્ય ફાઇલમાં મૂકીએ છીએ અને જો જરૂરી હોય તો તેનો સમાવેશ કરીએ છીએ, જેથી પ્લેબુકમાં તેનું સતત પુનરાવર્તન ન થાય. આમાં કૉલબૅક_ url શામેલ છે, જેમાં ઇશ્યૂ કી અને હોસ્ટનું નામ છે. જ્યારે Ansible આ POST વિનંતીને એક્ઝિક્યુટ કરે છે, ત્યારે બોટ સમજે છે કે તે આવી અને આવી ઘટનાના ભાગરૂપે આવી છે.

અને અહીં પ્લેબુકમાંથી એક ઉદાહરણ છે, જેમાં આપણે MD ઉપકરણમાંથી ડિસ્ક આઉટપુટ કરીએ છીએ:

  # Save mdadm configuration
  - include: common/callback.yml
    vars:
      callback_post_body:
        status: 'Ready to change'
        msg: "Removed disk from mdraid {{ mdadm_remove_disk.msg | comment_jira }}"
        data:
          mdadm_data: "{{ mdadm_remove_disk.removed }}"
          parted_info: "{{ parted_info | default() }}"
    when:
      - mdadm_remove_disk | changed
      - mdadm_remove_disk.removed

આ કાર્ય જિરા ટિકિટને “રેડી ટુ ચેન્જ” સ્ટેટસમાં સ્થાનાંતરિત કરે છે અને ટિપ્પણી ઉમેરે છે. ઉપરાંત, mdam_data ચલ md ઉપકરણોની યાદી સંગ્રહિત કરે છે જેમાંથી ડિસ્ક દૂર કરવામાં આવી હતી, અને parted_info partedમાંથી પાર્ટીશન ડમ્પ સંગ્રહિત કરે છે.

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

જવાબ આપવા યોગ્ય ચેક મોડ

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

આવા પ્રક્ષેપણ એક અલગ કૉલબેક મોડ્યુલ દ્વારા ચલાવવામાં આવે છે, અને પ્લેબુક એક્ઝેક્યુશનનું પરિણામ જીરામાં ટિપ્પણી તરીકે સાચવવામાં આવે છે.

સૌપ્રથમ, આનાથી બોટ અને પ્લેબુકના કાર્યને માન્ય કરવાનું શક્ય બન્યું. બીજું, તે બોટમાં સંચાલકોનો વિશ્વાસ વધાર્યો.

જ્યારે અમે માન્યતા પાસ કરી અને સમજાયું કે તમે માત્ર ડ્રાય રન મોડમાં જ નહીં પણ Ansible ચલાવી શકો છો, ત્યારે અમે સમાન પ્લેબુકને સમાન હોસ્ટ પર, પરંતુ સામાન્ય મોડમાં સમાન વેરિયેબલ્સ સાથે લોન્ચ કરવા માટે Jiraમાં એક Run Diskobot બટન બનાવ્યું છે.

વધુમાં, જો તે ક્રેશ થાય તો પ્લેબુકને પુનઃપ્રારંભ કરવા માટે બટનનો ઉપયોગ કરવામાં આવે છે.

પ્લેબુકનું માળખું

મેં પહેલેથી જ ઉલ્લેખ કર્યો છે કે જીરા ટિકિટની સ્થિતિના આધારે, બોટ વિવિધ પ્લેબુક લોન્ચ કરે છે.

પ્રથમ, પ્રવેશદ્વાર ગોઠવવાનું ખૂબ સરળ છે.
બીજું, કેટલાક કિસ્સાઓમાં તે ફક્ત જરૂરી છે.

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

અમે સર્વરના દરેક જૂથ માટે જવાબી ભૂમિકાઓનો ઉપયોગ કરીએ છીએ. અહીં તમે જોઈ શકો છો કે તેમાંથી એકમાં પ્લેબુક(ઓ) કેવી રીતે ગોઠવાય છે.

આ અનુકૂળ છે કારણ કે તે તરત જ સ્પષ્ટ છે કે કયા કાર્યો ક્યાં સ્થિત છે. main.yml માં, જે જવાબી ભૂમિકા માટેનું ઇનપુટ છે, અમે ફક્ત ટિકિટની સ્થિતિ દ્વારા અથવા દરેક માટે જરૂરી સામાન્ય કાર્યોનો સમાવેશ કરી શકીએ છીએ, ઉદાહરણ તરીકે, ઓળખ પાસ કરવી અથવા ટોકન પ્રાપ્ત કરવું.

તપાસ.yml

ઇન્વેસ્ટિગેશન અને ઓપન સ્ટેટસમાં ટિકિટ માટે દોડે છે. આ પ્લેબુક માટે સૌથી મહત્વની વસ્તુ બ્લોક ડિવાઇસનું નામ છે. આ માહિતી હંમેશા ઉપલબ્ધ હોતી નથી.

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

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

ready2change.yml

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

સૌથી સરળ કિસ્સામાં, અમે HW/MD RAID માંથી ડિસ્ક દૂર કરવા વિશે વાત કરી રહ્યા છીએ.

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

અમે હવે સામૂહિક રીતે સ્થળાંતર કરી રહ્યા છીએ વાદળ, અને જો સર્વર ક્લાઉડ-આધારિત હોય, તો ડિસ્કોબોટ ક્લાઉડ API ને કૉલ કરે છે, કહે છે કે તે આ મિનિઅન સાથે કામ કરવા જઈ રહ્યું છે - સર્વર ચલાવતા કન્ટેનર - અને પૂછે છે "આ મિનિઅનમાંથી બધા કન્ટેનર સ્થાનાંતરિત કરો." અને તે જ સમયે, ડિસ્કની બેકલાઇટ ચાલુ કરે છે જેથી એન્જિનિયર તરત જ જોઈ શકે કે કોને ખેંચવાની જરૂર છે.

બદલાયેલ.yml

ડિસ્કને બદલ્યા પછી, અમે પહેલા તેની ઉપલબ્ધતા તપાસીએ છીએ.

એન્જિનિયરો હંમેશા નવી ડ્રાઇવ્સ ઇન્સ્ટોલ કરતા નથી, તેથી અમે SMART મૂલ્યો માટે એક ચેક ઉમેર્યો છે જે અમને સંતુષ્ટ કરે છે.

આપણે કયા લક્ષણો જોઈ રહ્યા છીએ?ફરીથી ફાળવેલ ક્ષેત્રોની ગણતરી (5) < 100
વર્તમાન બાકી સેક્ટર કાઉન્ટ (107) == 0

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

તૈયાર.yml

સૌથી સરળ કેસ: HW/SW રેઇડ સિંક્રનાઇઝેશન તપાસવું અથવા એપ્લિકેશનમાં ડેટા સિંક્રનાઇઝેશન સમાપ્ત કરવું.

એપ્લિકેશન API

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

• સ્થિતિ. તેની સાથે કામ કરી શકાય છે કે કેમ તે સમજવા માટે ક્લસ્ટર અથવા ડિસ્કની સ્થિતિ;
• પ્રારંભ/રોકો. ડિસ્ક સક્રિયકરણ/નિષ્ક્રિયકરણ;
• સ્થાનાંતરિત/પુનઃસ્થાપિત કરો. રિપ્લેસમેન્ટ દરમિયાન અને પછી ડેટા સ્થાનાંતરણ અને પુનઃપ્રાપ્તિ.

Ansible પાસેથી શીખ્યા પાઠ

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

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

- name: Blink disk
  become: True
  register: locate_action
  disk_locate:
      locate: '{{ locate }}'
      devname: '{{ devname }}'
      ids: '{{ locate_ids | default(pd_id) | default(omit) }}'

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

તેઓ લખવામાં સરળ અને ઝડપી છે. ઉદાહરણ તરીકે, ડિસ્ક બેકલાઇટ મોડ્યુલ, જેનું ઉદાહરણ ઉપર બતાવેલ છે, તેમાં 265 રેખાઓ છે.

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

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

જો તમે જવાબી API સાથે અમારા અનુભવને પુનરાવર્તિત કરવા માંગતા હો, તો બે બાબતો ધ્યાનમાં રાખો:

• પ્લેબુક_એક્સીક્યુટર અને સામાન્ય રીતે પ્લેબુકને સમયસમાપ્તિ આપી શકાતી નથી. ssh સત્ર પર સમયસમાપ્તિ છે, પરંતુ પ્લેબુક પર કોઈ સમયસમાપ્તિ નથી. જો આપણે ડિસ્કને અનમાઉન્ટ કરવાનો પ્રયાસ કરીએ કે જે હવે સિસ્ટમમાં અસ્તિત્વમાં નથી, તો પ્લેબુક અવિરતપણે ચાલશે, તેથી અમારે તેના લોંચને અલગ રેપરમાં લપેટીને સમયસમાપ્તિ સાથે તેને મારી નાખવો પડ્યો.
• Ansible ફોર્ક્ડ પ્રક્રિયાઓ પર ચાલે છે, તેથી તેનું API થ્રેડ સલામત નથી. અમે અમારી તમામ પ્લેબુક સિંગલ-થ્રેડેડ ચલાવીએ છીએ.

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

પરંતુ હવે અમે બીજી સમસ્યાનો સામનો કરવાનું શરૂ કરી રહ્યા છીએ: કેટલાક નવા એડમિનિસ્ટ્રેટર્સ ડ્રાઇવ્સ કેવી રીતે બદલવી તે જાણતા નથી. 🙂

સોર્સ: www.habr.com