ભલે તે પૂર હોય, 1C કામ કરવું જોઈએ! અમે DR પરના વ્યવસાય સાથે સંમત છીએ

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

વર્ણવેલ વાર્તા કોઈ કાલ્પનિક નથી, પરંતુ 2020 ની કેટલીક ઘટનાઓનું સામૂહિક વર્ણન છે. મોટી કંપનીઓમાં, આ કેસ માટે ડિઝાસ્ટર રિકવરી પ્લાન (DRP) હંમેશા હાથમાં હોય છે. કોર્પોરેશનોમાં, આ વ્યવસાય સાતત્ય નિષ્ણાતોની જવાબદારી છે. પરંતુ મધ્યમ અને નાની કંપનીઓમાં આવી સમસ્યાઓનું નિરાકરણ IT સેવાઓ પર આવે છે. તમારે વ્યવસાયના તર્કને જાતે સમજવાની જરૂર છે, શું નિષ્ફળ થઈ શકે છે અને ક્યાં થઈ શકે છે તે સમજવું, રક્ષણ સાથે આવવું અને તેનો અમલ કરવો. 

જો કોઈ આઈટી નિષ્ણાત વ્યવસાય સાથે વાટાઘાટ કરી શકે અને રક્ષણની જરૂરિયાત વિશે ચર્ચા કરી શકે તો તે સરસ છે. પરંતુ મેં એક કરતા વધુ વાર જોયું છે કે કેવી રીતે કંપનીએ ડિઝાસ્ટર રિકવરી (DR) સોલ્યુશનમાં કમી કરી કારણ કે તે તેને નિરર્થક માનતી હતી. જ્યારે અકસ્માત થયો, ત્યારે લાંબી પુનઃપ્રાપ્તિ નુકસાનની ધમકી આપે છે, અને વ્યવસાય તૈયાર ન હતો. તમે તમને ગમે તેટલું પુનરાવર્તન કરી શકો છો: "મેં તમને કહ્યું હતું," પરંતુ IT સેવાએ હજી પણ સેવાઓ પુનઃસ્થાપિત કરવી પડશે.

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

• આપણે શું રક્ષણ કરીએ છીએ?
• આપણે શેનાથી રક્ષણ કરીએ છીએ?
• આપણે કેટલું રક્ષણ કરીએ છીએ? 

બીજા ભાગમાં, અમે પ્રશ્નનો જવાબ આપવાના વિકલ્પો વિશે વાત કરીશું: તમારો બચાવ કેવી રીતે કરવો. વિવિધ ગ્રાહકો તેમની સુરક્ષા કેવી રીતે બનાવે છે તેના ઉદાહરણો હું આપીશ.

અમે શું સુરક્ષિત કરીએ છીએ: નિર્ણાયક વ્યવસાય કાર્યોને ઓળખવા 

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

આઇટી પ્રોફેશનલને અનેક કારણોસર આવી વાટાઘાટોમાં મુશ્કેલી પડી શકે છે:

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

હું વાતચીતની રચના આ રીતે કરીશ: 

1. અમે વ્યવસાયોને સમજાવીએ છીએ કે અકસ્માતો દરેકને થાય છે અને પુનઃપ્રાપ્તિમાં સમય લાગે છે. શ્રેષ્ઠ બાબત એ છે કે પરિસ્થિતિઓ દર્શાવવી, આ કેવી રીતે થાય છે અને કયા પરિણામો શક્ય છે.
2. અમે બતાવીએ છીએ કે બધું IT સેવા પર નિર્ભર નથી, પરંતુ તમે તમારી જવાબદારીના ક્ષેત્રમાં કાર્ય યોજનામાં મદદ કરવા તૈયાર છો.
3. અમે વેપારી ગ્રાહકને જવાબ આપવા માટે કહીએ છીએ: જો સાક્ષાત્કાર થાય, તો કઈ પ્રક્રિયા પહેલા પુનઃસ્થાપિત થવી જોઈએ? તેમાં કોણ અને કેવી રીતે ભાગ લે છે? 

   વ્યવસાય તરફથી એક સરળ જવાબ આવશ્યક છે, ઉદાહરણ તરીકે: કૉલ સેન્ટરને 24/7 એપ્લિકેશનની નોંધણી ચાલુ રાખવાની જરૂર છે.

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

   શરૂઆતમાં, વર્ણન આના જેવું દેખાઈ શકે છે: કૉલ સેન્ટર ફોન દ્વારા, મેઇલ દ્વારા અને વેબસાઇટ પરથી સંદેશાઓ દ્વારા વિનંતીઓ પ્રાપ્ત કરે છે. પછી તે વેબ ઈન્ટરફેસ દ્વારા તેમને 1C માં દાખલ કરે છે, અને ઉત્પાદન તેમને ત્યાંથી આ રીતે લઈ જાય છે.

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

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

આપણે જેનાથી રક્ષણ કરીએ છીએ: જોખમો

આગળ, અમે વેપારી ગ્રાહક પાસેથી શોધી કાઢીએ છીએ કે આપણે સૌ પ્રથમ આપણી જાતને કયા જોખમોથી સુરક્ષિત રાખીએ છીએ. બધા જોખમોને બે જૂથોમાં વિભાજિત કરી શકાય છે: 

• સર્વિસ ડાઉનટાઇમને કારણે સમયની ખોટ;
• ભૌતિક પ્રભાવો, માનવીય પરિબળો, વગેરેને કારણે ડેટાની ખોટ.

વ્યવસાયો ડેટા અને સમય બંને ગુમાવવાથી ડરતા હોય છે - આ બધા પૈસાની ખોટ તરફ દોરી જાય છે. તેથી અમે ફરીથી દરેક જોખમ જૂથ માટે પ્રશ્નો પૂછીએ છીએ: 

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

ચર્ચા પછી, અમે સમજીશું કે નિષ્ફળતાના મુદ્દાઓને કેવી રીતે પ્રાધાન્ય આપવું. 

અમે કેટલું રક્ષણ કરીએ છીએ: RPO અને RTO 

જ્યારે નિષ્ફળતાના નિર્ણાયક મુદ્દા સ્પષ્ટ હોય, ત્યારે અમે RTO અને RPO સૂચકાંકોની ગણતરી કરીએ છીએ. 

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

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

અંતિમ વપરાશકર્તા માટે પુનઃપ્રાપ્તિ સમયની ગણતરી કરવાની જરૂર છે: તે કેટલો સમય સિસ્ટમમાં લૉગ ઇન કરી શકશે. તેથી પ્રથમ આપણે સાંકળમાંની તમામ લિંક્સનો પુનઃપ્રાપ્તિ સમય ઉમેરીએ છીએ. અહીં ઘણીવાર ભૂલ થાય છે: તેઓ SLA પાસેથી પ્રદાતાના RTO લે છે અને બાકીની શરતો ભૂલી જાય છે.

ચાલો ચોક્કસ ઉદાહરણ જોઈએ. વપરાશકર્તા 1C માં લૉગ ઇન કરે છે, સિસ્ટમ ડેટાબેઝ ભૂલ સાથે ખુલે છે. તે સિસ્ટમ એડમિનિસ્ટ્રેટરનો સંપર્ક કરે છે. ડેટાબેઝ ક્લાઉડમાં સ્થિત છે, સિસ્ટમ એડમિનિસ્ટ્રેટર સેવા પ્રદાતાને સમસ્યાની જાણ કરે છે. ચાલો કહીએ કે તમામ સંચારમાં 15 મિનિટ લાગે છે. ક્લાઉડમાં, આ કદના ડેટાબેઝને એક કલાકમાં બેકઅપથી પુનઃસ્થાપિત કરવામાં આવશે, તેથી, સેવા પ્રદાતા બાજુ પરનો RTO એક કલાકનો છે. પરંતુ આ અંતિમ સમયમર્યાદા નથી; વપરાશકર્તા માટે, સમસ્યાને શોધવા માટે તેમાં 15 મિનિટ ઉમેરવામાં આવી છે. 
 
આગળ, સિસ્ટમ એડમિનિસ્ટ્રેટરને તપાસવાની જરૂર છે કે ડેટાબેઝ સાચો છે, તેને 1C થી કનેક્ટ કરો અને સેવાઓ શરૂ કરો. આ માટે વધુ એક કલાકની જરૂર છે, જેનો અર્થ છે કે એડમિનિસ્ટ્રેટરની બાજુમાં આરટીઓ પહેલેથી જ 2 કલાક અને 15 મિનિટ છે. વપરાશકર્તાને બીજી 15 મિનિટની જરૂર છે: લોગ ઇન કરો, તપાસો કે જરૂરી વ્યવહારો દેખાયા છે. 2 કલાક 30 મિનિટ આ ઉદાહરણમાં કુલ સેવા પુનઃપ્રાપ્તિ સમય છે.

આ ગણતરીઓ વ્યવસાયને બતાવશે કે પુનઃપ્રાપ્તિ અવધિ કયા બાહ્ય પરિબળો પર આધારિત છે. ઉદાહરણ તરીકે, જો ઑફિસમાં પૂર આવે છે, તો તમારે પહેલા લીક શોધવાની અને તેને ઠીક કરવાની જરૂર છે. તે સમય લેશે, જે IT પર નિર્ભર નથી.  

અમે કેવી રીતે રક્ષણ કરીએ છીએ: વિવિધ જોખમો માટે સાધનોની પસંદગી

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

ચાલો જોખમોના પ્રથમ જૂથથી પ્રારંભ કરીએ: સેવાના ડાઉનટાઇમને લીધે થતા નુકસાન. આ સમસ્યાનો ઉકેલ સારો આરટીઓ પૂરો પાડવો જોઈએ.

1. ક્લાઉડમાં એપ્લિકેશન હોસ્ટ કરો 

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

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

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

2. એપ્લિકેશનને ક્લસ્ટર કરો  

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

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

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

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

3. ડિઝાસ્ટર-પ્રૂફ ક્લાઉડ પર જાઓ

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

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

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

   • આપત્તિ-સહિષ્ણુ વાદળ એપ્લિકેશનને ઇન્ફ્રાસ્ટ્રક્ચર સ્તરે નિષ્ફળતાઓથી સુરક્ષિત કરે છે. 
   • માનવીય ભૂલના કિસ્સામાં બે-લેવલ બેકઅપ સુરક્ષા પ્રદાન કરે છે. બે પ્રકારના બેકઅપ છે: “ઠંડા” અને “ગરમ”. "કોલ્ડ" બેકઅપ અક્ષમ સ્થિતિમાં છે અને તેને જમાવવામાં સમય લાગે છે. "હોટ" બેકઅપ પહેલેથી જ ઉપયોગ માટે તૈયાર છે અને ઝડપથી પુનઃસ્થાપિત થાય છે. તે ખાસ સમર્પિત સ્ટોરેજ સિસ્ટમ પર સંગ્રહિત છે. ત્રીજી નકલ ટેપ પર રેકોર્ડ કરવામાં આવે છે અને બીજા રૂમમાં સંગ્રહિત થાય છે. 

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

4. બીજી સાઇટ પર પ્રતિકૃતિ ગોઠવો 

   મુખ્ય સાઇટ પર વૈશ્વિક સમસ્યાઓને કેવી રીતે ટાળવી તે અંગેનો બીજો વિકલ્પ: જીઓ-રિઝર્વેશન પ્રદાન કરો. બીજા શબ્દોમાં કહીએ તો, અન્ય શહેરની સાઇટ પર બેકઅપ વર્ચ્યુઅલ મશીનો બનાવો. DR માટે વિશેષ ઉકેલો આ માટે યોગ્ય છે: અમારી કંપનીમાં અમે VMware vCloud Availability (vCAV) નો ઉપયોગ કરીએ છીએ. તેની સહાયથી, તમે ઘણી ક્લાઉડ પ્રદાતા સાઇટ્સ વચ્ચે સુરક્ષાને ગોઠવી શકો છો અથવા ઑન-પ્રિમિસ સાઇટથી ક્લાઉડ પર પુનઃસ્થાપિત કરી શકો છો. મેં vCAV સાથે કામ કરવાની યોજના વિશે વધુ વિગતવાર વાત કરી છે અહીં. 

   RPO અને RTO: 5 મિનિટથી. 

   કિંમત: પ્રથમ વિકલ્પ કરતાં વધુ ખર્ચાળ, પરંતુ આપત્તિ-પ્રૂફ ક્લાઉડમાં હાર્ડવેર પ્રતિકૃતિ કરતાં સસ્તું. કિંમતમાં VCAV લાયસન્સ, વહીવટી ફી, ક્લાઉડ સંસાધનોની કિંમત અને PAYG મોડલ (સ્વીચ ઑફ VM માટે કાર્યકારી સંસાધનોની કિંમતના 10%) અનુસાર રિઝર્વ સંસાધનોની કિંમતનો સમાવેશ થાય છે.

   પ્રેક્ટિસમાંથી: ક્લાયન્ટે મોસ્કોમાં અમારા ક્લાઉડમાં વિવિધ ડેટાબેઝ સાથે 6 વર્ચ્યુઅલ મશીનો રાખ્યા હતા. શરૂઆતમાં, બેકઅપ દ્વારા રક્ષણ પૂરું પાડવામાં આવ્યું હતું: બેકઅપની કેટલીક નકલો મોસ્કોમાં ક્લાઉડમાં સંગ્રહિત કરવામાં આવી હતી, અને કેટલીક અમારી સેન્ટ પીટર્સબર્ગ સાઇટ પર સંગ્રહિત કરવામાં આવી હતી. સમય જતાં, ડેટાબેસેસનું કદ વધ્યું, અને બેકઅપમાંથી પુનઃસ્થાપિત કરવામાં વધુ સમય લાગવા લાગ્યો. 
    
   VMware vCloud ઉપલબ્ધતા પર આધારિત પ્રતિકૃતિ બેકઅપ્સમાં ઉમેરવામાં આવી હતી. વર્ચ્યુઅલ મશીનોની પ્રતિકૃતિઓ સેન્ટ પીટર્સબર્ગમાં બેકઅપ સાઇટ પર સંગ્રહિત થાય છે અને દર 5 મિનિટે અપડેટ થાય છે. જો મુખ્ય સાઇટ પર નિષ્ફળતા થાય છે, તો કર્મચારીઓ સ્વતંત્ર રીતે સેન્ટ પીટર્સબર્ગમાં વર્ચ્યુઅલ મશીનની પ્રતિકૃતિ પર સ્વિચ કરે છે અને તેની સાથે કામ કરવાનું ચાલુ રાખે છે. 

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

5. બેકઅપ વિશે ભૂલશો નહીં

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

કડક શબ્દોમાં કહીએ તો, બેકઅપ એ DR નથી. અને તેથી જ: 

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

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

અંતિમ આપત્તિ પુનઃપ્રાપ્તિ યોજનામાં ઓછામાં ઓછા 2 સાધનો હોવા જોઈએ:  

• 1-4 વિકલ્પોમાંથી એક, જે સિસ્ટમને નિષ્ફળતા અને પડતી સામે રક્ષણ આપશે.
• ડેટાને નુકશાનથી બચાવવા માટે બેકઅપ. 

જો મુખ્ય ઈન્ટરનેટ પ્રદાતા નીચે જાય તો બેકઅપ કમ્યુનિકેશન ચેનલની કાળજી લેવી પણ યોગ્ય છે. અને - વોઇલા! - લઘુત્તમ વેતન પર ડીઆર પહેલેથી જ તૈયાર છે. 

સોર્સ: www.habr.com