બે ગાંઠોનું ક્લસ્ટર - શેતાન વિગતોમાં છે

હે હબર! હું તમારા ધ્યાન પર લેખનો અનુવાદ રજૂ કરું છું "બે ગાંઠો - શેતાન વિગતોમાં છે" એન્ડ્રુ બીખોફ દ્વારા.

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

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

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

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

દરેકને સ્વતંત્ર પાવર લાઇન સાથે વૈકલ્પિક વીજળી સપ્લાયર્સની જરૂર હોતી નથી. જો કે પેરાનોઇયાએ ઓછામાં ઓછા એક ગ્રાહકને ચૂકવણી કરી જ્યારે તેમના મોનિટરિંગમાં ખામીયુક્ત ટ્રાન્સફોર્મર મળ્યું. ખામીયુક્ત ટ્રાન્સફોર્મર ફાટી ન જાય ત્યાં સુધી ગ્રાહકે ફોન કરીને વીજ કંપનીને એલર્ટ કરવાનો પ્રયાસ કર્યો હતો.

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

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

તેથી, એક નોડની નિષ્ફળતાના પરિણામે ડેટા ભ્રષ્ટાચારને રોકવા માટે - અમે કહેવાતી વસ્તુ પર આધાર રાખીએ છીએ "વિયોગ" (ફેન્સીંગ).

વિયોજનનો સિદ્ધાંત

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

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

પ્રત્યક્ષ અને પરોક્ષ બંને પદ્ધતિઓનો ઉપયોગ કરતી વખતે કોરમ મદદ કરે છે.

પ્રત્યક્ષ વિયોજન

ડાયરેક્ટ ડિસોસિએશનના કિસ્સામાં, અમે નેટવર્ક નિષ્ફળતાના કિસ્સામાં વિયોજન રેસને રોકવા માટે કોરમનો ઉપયોગ કરી શકીએ છીએ.

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

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

ડિસોસિએશનની સમસ્યા એ છે કે સૌથી સામાન્ય રીતે ઉપયોગમાં લેવાતા ઉપકરણો એ જ નિષ્ફળતાની ઘટનાઓને કારણે અનુપલબ્ધ થઈ જાય છે જેને અમે પુનઃપ્રાપ્તિ માટે લક્ષ્ય બનાવવા માંગીએ છીએ. મોટાભાગના IPMI અને iLO કાર્ડ તેઓ જે હોસ્ટને નિયંત્રિત કરે છે તેના પર ઇન્સ્ટોલ કરેલા હોય છે અને ડિફૉલ્ટ રૂપે, સમાન નેટવર્કનો ઉપયોગ કરે છે, જેના કારણે લક્ષ્ય યજમાનો માને છે કે અન્ય યજમાનો ઑફલાઇન છે.

કમનસીબે, IPMI અને iLo ઉપકરણોની ઓપરેટિંગ સુવિધાઓને સાધનસામગ્રીની ખરીદી સમયે ભાગ્યે જ ધ્યાનમાં લેવામાં આવે છે.

પરોક્ષ વિયોજન

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

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

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

એક મોડ પસંદ કરવામાં સમસ્યા એ છે કે ત્યાં કોઈ કાર્યવાહીનો કોર્સ નથી જે ઉપલબ્ધતાને મહત્તમ કરે અને ડેટાના નુકશાનને અટકાવે.

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

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

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

કોરમ

કોરમ સરસ લાગે છે, ખરું ને?

એકમાત્ર નુકસાન એ છે કે તેને N સભ્યો સાથે ક્લસ્ટરમાં રાખવા માટે, તમારે તમારા બાકી રહેલા નોડ્સના N/2+1 વચ્ચે જોડાણ હોવું જરૂરી છે. જે એક નોડ ફેલ થયા પછી બે નોડ ક્લસ્ટરમાં શક્ય નથી.

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

બે-નોડ ક્લસ્ટર બનાવવાનું કામ

કેટલીકવાર ક્લાયંટ ત્રીજો નોડ ખરીદી શકતો નથી અથવા ઇચ્છતો નથી, અને અમને વિકલ્પ શોધવાની ફરજ પડી છે.

વિકલ્પ 1 - ડુપ્લિકેટ વિયોજન પદ્ધતિ

નોડનું iLO અથવા IPMI ઉપકરણ નિષ્ફળતાના બિંદુને રજૂ કરે છે કારણ કે, જો તે નિષ્ફળ જાય, તો બચી ગયેલા લોકો તેનો ઉપયોગ નોડને સુરક્ષિત સ્થિતિમાં લાવવા માટે કરી શકતા નથી. 3 અથવા વધુ ગાંઠોના ક્લસ્ટરમાં, અમે કોરમની ગણતરી કરીને અને હાર્ડવેર વોચડોગ (અગાઉ ચર્ચા કર્યા મુજબ એક પરોક્ષ ડિસસોસિએશન મિકેનિઝમ) નો ઉપયોગ કરીને આને ઘટાડી શકીએ છીએ. બે નોડ્સના કિસ્સામાં, આપણે તેના બદલે નેટવર્ક પાવર ડિસ્ટ્રિબ્યુશન યુનિટ્સ (PDUs) નો ઉપયોગ કરવો જોઈએ.

નિષ્ફળતા પછી, સર્વાઈવર પ્રથમ પ્રાથમિક ડિસસોસિએશન ઉપકરણ (એમ્બેડેડ iLO અથવા IPMI) નો સંપર્ક કરવાનો પ્રયાસ કરે છે. જો આ સફળ થાય, તો પુનઃપ્રાપ્તિ સામાન્ય રીતે ચાલુ રહે છે. જો iLO/IPMI ઉપકરણ નિષ્ફળ જાય તો જ PDU ઍક્સેસ કરવામાં આવે છે; જો ઍક્સેસ સફળ થાય, તો પુનઃપ્રાપ્તિ ચાલુ રાખી શકાય છે.

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

અહીં તમે પૂછી શકો છો - શું PDU નિષ્ફળતાનો એક મુદ્દો છે? જેનો જવાબ છે, અલબત્ત તે છે.

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

વિકલ્પ 2 - આર્બિટર ઉમેરવું

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

આ કિસ્સામાં, ભલામણ કરેલ વિકલ્પ એ છે કે એક તટસ્થ તૃતીય પક્ષ બનાવવો જે કોરમ ગણતરીને પૂરક બનાવી શકે.

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

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

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

વિકલ્પ 3 - માનવ પરિબળ

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

બોનસ વિકલ્પ

શું મેં ઉલ્લેખ કર્યો છે કે તમે ત્રીજો નોડ ઉમેરી શકો છો?

બે રેક્સ

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

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

ટૂંકો જવાબ એ છે કે તે શક્ય નથી, અને ફરીથી અમે બે-નોડ કેસમાં બધી સમસ્યાઓ સાથે કામ કરી રહ્યા છીએ. અથવા બચી ગયેલા:

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

કોઈ પણ સંજોગોમાં, બે રેક્સ એક કરતા વધુ સારા નથી, અને નોડ્સને ક્યાં તો સ્વતંત્ર પાવર સપ્લાય મળવો જોઈએ અથવા ત્રણ (અથવા વધુ, તમારી પાસે કેટલા ગાંઠો છે તેના આધારે) રેક્સમાં વિતરિત થવો જોઈએ.

બે ડેટા સેન્ટર

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

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

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

સોર્સ: www.habr.com