¿Es­tá pre­pa­ra­do tu ne­go­cio pa­ra so­bre­vi­vir a una caí­da del sis­te­ma?

An­tes de en­fren­tar­se a la caí­da de un sis­te­ma, lo pri­me­ro que debe ha­cer es cues­tio­nar­se si su ne­go­cio pue­de li­diar con un res­pal­do asín­crono o debe ac­tua­li­zar­se en un ser­vi­dor ex­terno ca­da se­gun­do pa­ra man­te­ner­se en pie.

IT Now Rep. Dominicana - - MANAGEMENT - CIO

Los ex­per­tos de seguridad di­cen que la for­ma en la que las com­pa­ñías in­di­vi­dua­les de­ci­den guar­dar sus da­tos an­tes de una caí­da del sis­te­ma de­pen­de de cuán­to pue­den so­bre­vi­vir an­tes de que la “luz” re­gre­se. ¿Qué ni­vel de dis­po­ni­bi­li- dad ne­ce­si­ta tu com­pa­ñía? ¿La in­ter­faz de tu com­pa­ñía es un si­tio de co­mer­cio elec­tró­ni­co don­de in­clu­so unos po­cos mi­nu­tos fue­ra de lí­nea pue­den cos­tar­te una su­ma as­tro­nó­mi­ca? ¿El cos­to de un sis­te­ma ac­ti­vo/ ac­ti­vo so­bre­pa­sa la pér­di­da po­ten­cial del ne­go­cio de­bi­da a una caí­da del sis­te­ma? No se tra­ta de que uno sea más efi­cien­te que el otro, sino que de­bes de­ter­mi­nar cuá­les son las ne­ce­si­da­des que es­tás in­ten­tan­do aten­der. Por ejem­plo, comprar un Fe­rra­ri pa­ra ir a al su­per­mer­ca­do es al­go que ser­vi- rá pa­ra la ta­rea, ¿pe­ro real­men­te, es ne­ce­sa­rio pa­ra el pro­pó­si­to?”, di­jo Don Fos­ter, di­rec­tor se­nior de so­lu­cio­nes de mar­ke­ting y alian­zas téc­ni­cas en Comm­vault. En una ar­qui­tec­tu­ra ac­ti­vo/ac­ti­vo, tí­pi­ca un clús­ter de ser­vi­do­res ex­ter­nos, la sin­cro­ni­za­ción es rea­li­za­da con un ser­vi­dor en el si­tio. Es­to per­mi­te que no ha­ya una cor­te en el ca­so de que un ser­vi­dor se cai­ga. Pue­de ser con­fi­gu­ra­do pa­ra la con­mu­ta­ción au­to­má­ti­ca por error que re­quie­re me­nos hard­wa­re por­que to­dos los sis­te­mas en am­bos si­tios es­tán sien­do usa­dos en un es­ce­na­rio de re­cu­pe­ra­ción os­cu­ra de desas­tres, en el que so­lo se em­plea la mi­tad del hard­wa­re. Si tu­vie­ses 48 nú­cleos pa­ra la re­cu­pe­ra­ción os­cu­ra de desas­tres, ten­drías 96 nú­cleos y so­lo usa­rías 48. En la mo­da­li­dad ac­ti­vo/ac­ti­vo, re­tro­ce­des a una es­ca­la de 32x2, pa­ra un to­tal de 64 nú­cleos, to­dos ac­ti­vos. En un es­ce­na­rio de re­cu­pe­ra­ción os­cu­ra de desas­tres, la ca­pa­ci­dad es un sis­te­ma por com­ple­to re­dun­dan­te, to­do el hard­wa­re y el soft­wa­re es­tán lis­tos pa­ra fun­cio­nar, pe­ro com­ple­ta­men­te inac­ti­vos. Esa ca­pa­ci­dad no se usa has­ta que el pri­mer si­tio fa­lla, pe­ro se re­pli­ca ca­da cier­to tiem­po. Erin Swi­ke, ar­qui­tec­to se­nior de so­lu­cio­nes en la nu­be en Blue­lock, ex­pli­có que la

re­cu­pe­ra­ción de desas­tres ac­ti­vo/ac­ti­vo es el uni­cor­nio en el mun­do de RD. La idea de po­der dor­mir en la no­che sa­bien­do que, si tu si­tio pro­duc­ti­vo fa­lla, tu sis­te­ma de RD au­to­má­ti­ca­men­te em­pe­za­rá a ser­vir a las apli­ca­cio­nes de los usua­rios sin que se pier­da ni un so­lo pa­que­te ni se ge­ne­ren tiem­pos de inac­ti­vi­dad. Es el nir­va­na de cual­quier di­rec­tor in­for­má­ti­co o in­ge­nie­ro de sis­te­ma. “Pa­ra la ma­yo­ría, es co­sa de cuen­tos de ha­das y le­yen­das. Ol­ví­da­te del fac­tor ob­vio de la pro­xi­mi­dad del cen­tro de da­tos y la la­ten­cia de la red. Uno de los fac­to­res más im­por­tan­tes es que tus apli­ca­cio­nes es­tén di­se­ña­das pa­ra so­por­tar es­te ti­po de es­ce­na­rio. A me­nos que tu ex­pli­ca­ción ha­ya si­do di­se­ña­da pa­ra fun­cio­nar así des­de el prin­ci­pio, lo más pro­ba­ble es que no lo so­por­ten,” agre­gó Erin. Los cos­tos del soft­wa­re son más al­tos en la mo­da­li­dad ac­ti­vo/ac­ti­vo por­que cual­quier sis­te­ma fun­cio­nan­do en ella debe te­ner uno con li­cen­cia. Cuan­do el sis­te­ma es­tá en mo­da­li­dad de re­cu­pe­ra­ción os­cu­ra de desas­tres, el se­gun­do sis­te­ma no re­quie­re li­cen­cias de pa­go pa­ra los nú­cleos de las ba­ses de da­tos por­que, por ejem­plo, so­lo un sis­te­ma es­tá vi­vo al mis­mo tiem­po. El he­cho que los dos sis­te­mas es­tén sin­cro­ni­za­dos no afec­ta los cos­tos en ab­so­lu­to. En la re­pli­ca­ción sin­cró­ni­ca, se re­quie­ren co­ne­xio­nes de red con­fia­bles en­tre los dos ser­vi­do­res. Tam­bién hay un tra­ba­jo ex­tra in­vo­lu­cra­do al te­ner que ges­tio­nar otro si­tio cons­tan­te­men­te. El la­do ne­ga­ti­vo de la re­pli­ca­ción asín­cro­na tie­ne que ver con la pér­di­da de al­gu­nos da­tos en­tre el tiem­po de inac­ti­vi­dad y el mo­men­to en el que se ac­tua­li­zó por úl­ti­ma vez el ser­vi­dor. Sin em­bar­go, pue­de con­fi­gu­rar­se pa­ra la con­mu­ta­ción re­du­ci­da por error. Anand Ha­riha­ran, vi­ce­pre­si­den­te de pro­duc­to en Webs­ca­le Net­works, con­si­de­ró que es­to es en esen­cia el con­cep­to de los ser­vi­do­res de res­pal­do frío/ca­lien­te. Los pro y las con­tras pue­den te­ner dos cau­sas: el acuer­do a ni­vel del ser­vi­cio y el cos­to. El pun­to ob­je­ti­vo de la re­cu­pe­ra­ción (RPO, por sus si­glas en in­glés) y el tiem­po ob­je­ti­vo de la re­cu­pe­ra­ción (RTO, por sus si­glas en in­glés) de­fi­nen el acuer­do de ni­vel del ser­vi­cio que el ven­de­dor pro­vee­rá pa­ra in­for­mar al usua­rio so­bre la ex­ten­sión acep­ta­ble del tiem­po en el que, en ca­so de una caí­da, po­drían per­der­se da­tos y qué tan rá­pi­do se­rían res­tau­ra­dos los ser­vi­cios. “Na­tu­ral­men­te, con un res­pal­do en ca­lien­te o una ar­qui­tec­tu­ra ac­ti­vo/ac­ti­vo hay un tiem­po de inac­ti­vi­dad nu­lo y una ré­pli­ca per­fec­ta de los da­tos, por lo que des­de el acuer­do del ni­vel del ser­vi­cio es el ca­mino

“No se tra­ta de que uno sea más efi­cien­te que el otro, sino que de­bes de­ter­mi­nar cuá­les son las ne­ce­si­da­des que es­tás in­ten­tan­do aten­der. Por ejem­plo, comprar un Fe­rra­ri pa­ra ir a al su­per­mer­ca­do es al­go que ser­vi­rá pa­ra la ta­rea, ¿ pe­ro real­men­te, es ne­ce­sa­rio pa­ra el pro­pó­si­to?”. Don Fos­ter, Comm­vault.

más con­ve­nien­te”, di­jo Ha­riha­ran. El la­do ne­ga­ti­vo es, cla­ra­men­te, el cos­to. Man­te­ner dos sis­te­mas fun­cio­nan­do du­pli­ca los re­la­cio­na­dos con la ope­ra­ción de ar­qui­tec­tu­ras en ré­pli­ca en un cen­tro de da­tos pri­va­do, con el pa­go a un pro­vee­dor de al­ma­ce­na­mien­to ges­tio­na­do pa­ra desem­pe­ñar la mis­ma fun­ción en una ubi­ca­ción ex­ter­na; o con el de ope­rar el do­ble de las ins­tan­cias en la nu­be. En al­gu­nos de es­tos es­ce­na­rios, de­pen­dien­do del ta­ma­ño del des­plie­gue, pro­ba­ble­men­te tam­bién ha­ya que con­si­de­rar que pue­de ser ne­ce­sa­rio con­tar con un per­so­nal téc­ni­co adi­cio­nal pa­ra ges­tio­nar el do­ble de los sis­te­mas, con el con­se­cuen­te in­cre­men­to del cos­to. Cos­tos Da­da la ta­sa pro­me­dio (y cre­cien­te) de US$7.900 por mi­nu­to (Po­ne­mon Ins­ti­tu­te), el tiem­po de inac­ti­vi­dad crea un cos­to po­ten­cial enor­me pa­ra las em­pre­sas, tan­to en el ne­go­cio in­me­dia­to co­mo en la repu­tación a lar­go pla­zo. Otros cos­tos in­clu­yen los ser­vi­do­res en un si­tio de co­lo­ca­ción. Tie­nen el atrac­ti­vo su­per­fi­cial de aho­rrar di­ne­ro al dis­tri­buir los cos­tos de in­fra­es­truc­tu­ra en­tre va­rios usua­rios, pe­ro un vis­ta­zo más de­ta­lla­do re­ve­la que esos aho­rros no son ac­tua­li­za­dos, se­ña­ló el Re­por­te de Sca­le Arc. La com­pa­ñía de co­lo­ca­ción co­bra in­clu­so por los re­cur­sos no uti­li­za­dos, in­clu­yen­do los os­cu­ros que al­gún día po­drían ac­ti­var­se pa­ra su uso. Pe­ro aún así las em­pre­sas no pue­den re­du­cir la can­ti­dad de re­cur­sos de­di­ca­dos al si­tio se­cun­da­rio, por­que to­da la in­for­ma­ción del ser­vi­dor pri­ma­rio debe es­tar so­por­ta­da en él. El re­por­te de Sca­le Arc tam­bién des­ta­ca que al igual que la co­lo­ca­ción, las so­lu­cio­nes pú­bli­cas en la nu­be pa­re­cen atrac­ti­vas de­bi­do que se les su­po­ne una eco­no­mía de es­ca­la. Pe­ro las or­ga­ni­za­cio­nes con preo­cu­pa­cio­nes res­pec­to a la seguridad (ban­cos y agencias gu­ber­na­men­ta­les, por ejem­plo) se ale­jan de ellas de­bi­do a los pro­ble­mas res­pec­to a la pri­va­ci­dad. Ade­más los sis­te­mas en la nu­be pue­den in­tro­du­cir una la­ten­cia que im­pac­te en el ren­di­mien­to de la apli­ca­ción más allá de los ni­ve­les acep­ta­bles. Co­mo ve­mos, la eco­no­mía de la nu­be no siem­pre es lo que pa­re­ce. En un es­ce­na­rio de ope­ra­ción com­ple­ta, los gas­tos en la nu­be son su­pe­rio­res a los de cuan­do los ne­go­cios tie­nen y ha­cen fun­cio­nar su pro­pia

in­fra­es­truc­tu­ra. Sca­leArc con­si­de­ró que los cos­tos de man­te­ni­mien­to de una ar­qui­tec­tu­ra ac­ti­vo/ ac­ti­vo son más ba­jos por­que las ta­reas se pue­den ha­cer du­ran­te las ho­ras de tra­ba­jo en lu­gar de re­que­rir un equi­po en me­dio de la no­che. Tam­bién re­quie­ren me­nos per­so­nal, por­que se pue­de man­te­ner la apli­ca­ción en eje­cu­ción du­ran­te el man­te­ni­mien­to, por lo que los desa­rro­lla­do­res y otros es­pe­cia­lis­tas no ne­ce­si­tan es­tar in­vo­lu­cra­dos. “Por ape­nas un 20% de au­men­to en los cos­tos las or­ga­ni­za­cio­nes dis­fru­ta­rán de 33% más de ca­pa­ci­dad del sis­te­ma, jun­to con los be­ne­fi­cios eco­nó­mi­cos adi­cio­na­les de re­du­cir el tiem­po de inac­ti­vi­dad, los me­no­res cos­tos ope­ra­ti­vos, la me­jor uti­li­za­ción de los ac­ti­vos y pro­ba­ble­men­te in­gre­sos to­ta­les más al­tos”, es­cri­bió Sca­leArc. Es po­si­ble que los clien­tes no en­tien­dan las ar­qui­tec­tu­ras de compu­tación, pe­ro quie­ren que sus apli­ca­cio­nes y da­tos es­tén to­do el tiem­po dis­po­ni­bles. Cual­quier pro­vee­dor que no pro­por­cio­ne el 100% de tiem­po de ac­ti­vi­dad co­rre el ries­go de per­der clien­tes e in­gre­sos. Al Sar­gent, di­rec­tor se­nior de OneLo­gin, di­jo que des­de el pun- to de vis­ta fi­nan­cie­ro los in­gre­sos prin­ci­pa­les em­pe­que­ñe­cen lo que las em­pre­sas gas­tan en pre­su­pues­tos de TI. Un es­tu­dio mues­tra que las em­pre­sas gas­tan en­tre el 3 y el 7% de sus in­gre­sos en TI. “El cam­bio a las ar­qui­tec­tu­ras ac­ti­vo/ ac­ti­vo po­dría au­men­tar un po­co ese por­cen­ta­je, pe­ro evi­ta­rá in­te­rrup­cio­nes que po­drían ero­sio­nar los in­gre­sos en mu­chos más pun­tos por­cen­tua­les,” agre­gó. Al­gu­nas de las des­ven­ta­jas en lo que res­pec­ta a los cos­tos dis­mi­nu­yen con una so­lu­ción SaaS ba­sa­da en la nu­be, don­de un en­torno de ad­mi­nis­tra­ción co­mún pue­de man­te­ner­se au­to­má­ti­ca­men­te en am­bos si­tios. La nu­be per­mi­te tiem­pos de am­plia­ción rá­pi­da, por lo que se pue­de im­ple­men­tar una in­fra­es­truc­tu­ra de con­mu­ta­ción por error re­du­ci­da (me­nor ta­ma­ño) que pue­de res­tau­rar, du­ran­te un desas­tre, las apli­ca­cio­nes ca­si al ins­tan­te, per­mi­tien­do un me­jor acuer­do de ni­vel del ser­vi­cio, di­jo Ha­riha­ran. Fos­ter di­jo que am­bos es­ce­na­rios son vá­li­dos pa­ra una es­tra­te­gia de re­cu­pe­ra­ción de desas­tres. Mu­chas apli­ca­cio­nes e in­clu­so in­fra­es­truc­tu­ras (las ma­tri­ces de al­ma­ce­na­mien­to en el es­pa­cio de la em­pre­sa han crea­do gri­llas ac­ti­vo/ ac­ti­vo a tra­vés de es­pa­cios de nom­bres úni­cos que pue­den cru­zar los cen­tros de da­tos tam­bién) han desa­rro­lla­do es­ta tec­no­lo­gía pa­ra fa­ci­li­tar a las em­pre­sas el pro­por­cio­nar pla­nes de con­ti­nui­dad de ne­go­cio y re­cu­pe­ra­ción en el ca­so de que se pro­duz­ca una in­te­rrup­ción en la in­fra­es­truc­tu­ra. “El pro­ble­ma es el cos­to de man­te­ner y ope­rar es­tas in­fra­es­truc­tu­ras. Si una apli­ca­ción o ser­vi­cio tie­ne re­qui­si­tos pa­ra ser ver­da­de­ra­men­te un sis­te­ma de “tono de mar­ca­ción” (siem­pre en­cen­di­do - nun­ca fue­ra de lí­nea), la em­pre­sa gas­ta­rá los dó­la­res ne­ce­sa­rios pa­ra ase­gu­rar los cin­co ni­ve­les de dis­po­ni­bi­li­dad y al­gu­nos más,” men­cio­nó. La ma­yo­ría de las apli­ca­cio­nes crí­ti­cas tie­nen me­ca­nis­mos de con­mu­ta­ción por error in­cor­po­ra­dos pa­ra que los sis­te­mas se­cun­da­rios o ter­cia­rios pue­dan reanu­dar­se si uno tie­ne un fa­llo, aña­dió Fos­ter. La agru­pa­ción tam­bién ha exis­ti­do du­ran­te mu­cho tiem­po pa­ra los ser­vi­do­res y, da­do que esa tec­no­lo­gía se ha des­pla­za­do ha­cia aba­jo en los ser­vi­cios de in­fra­es­truc­tu­ra, la fa­ci­li­dad con la que se pue­de pro­por­cio­nar la dis­po­ni­bi­li­dad ha me­jo­ra­do con­si­de­ra- ble­men­te, in­cu­rrien­do so­lo en un cos­to. “Las so­lu­cio­nes de re­cu­pe­ra­ción ac­ti­vo-ac­ti­vo no tie­nen en cuen­ta el error del usua­rio. Son ba­su­ra en la ba­su­ra, por lo cual en el ca­so una de in­te­rrup­ción es ne­ce­sa­rio te­ner al­go que sir­va co­mo un pun­to de se­gui­mien­to con­sis­ten­te en el tiem­po pa­ra vol­ver a re­cu­pe­rar los da­tos. La caí­da de Gi­tLab de ha­ce unas se­ma­nas es un gran ejem­plo de es­to,” di­jo Fos­ter. Hay un gran nú­me­ro de apli­ca­cio­nes de mi­sión crí­ti­ca que se va­len de la pro­tec­ción de la re­dun­dan­cia ac­ti­vo/ac­ti­vo, el tru­co es­tá en de­ter­mi­nar las que me­re­cen el gas­to. “Es im­por­tan­te re­cor­dar que un buen plan RD / CR re­quie­re una eva­lua­ción am­plia de las prio­ri­da­des em­pre­sa­ria­les que son cla­ve pa­ra una em­pre­sa: el per­so­nal, los da­tos, las apli­ca­cio­nes ne­ce­sa­rias pa­ra apo­yar­lo y el cos­to de las op­cio­nes al­ter­na­ti­vas dis­po­ni­bles pa­ra re­em­pla­zar­los, to­dos de­ben ser so­pe­sa­dos en un aná­li­sis cos­to / be­ne­fi­cio fren­te al ries­go de pér­di­da y la

Si tu­vie­ses 48 nú­cleos pa­ra la re­cu­pe­ra­ción os­cu­ra de desas­tres, ten­drías 96 nú­cleos y so­lo usa­rías 48. En la mo­da­li­dad ac­ti­vo/ ac­ti­vo, re­tro­ce­des a una es­ca­la de 32x2, pa­ra un to­tal de 64 nú­cleos, to­dos ac­ti­vos.

pro­ba­bi­li­dad de una in­te­rrup­ción crí­ti­ca del ne­go­cio”, ex­pli­có Ste­ven Hill, ana­lis­ta se­nior de al­ma­ce­na­mien­to de 451 Re­search. La re­cu­pe­ra­ción de desas­tres os­cu­ra es más ren­ta­ble, pues sue­le es­tar en­fo­ca­da en in­te­rrup­cio­nes de los da­tos y pue­de com­ple­men­tar­se bas­tan­te bien con los ser­vi­cios de re­cu­pe­ra­ción ac­ti­vos in­cor­po­ra­dos, se­ña­ló Fos­ter. La in­fra­es­truc­tu­ra es­ta­ría al­ta­men­te dis­po­ni­ble con co­pias de da­tos mo­ni­to­rea­das en tiem­po real y con ver­sio­nes re­fe­ren­cia­das en el tiem­po pa­ra re­sol­ver cual­quier pro­ble­ma de in­te­rrup­ción. Jus­tin Bar­ney, CEO de Sca­leArc, cree que la eva­lua­ción de los cos­tos de una ar­qui­tec­tu­ra ac­ti­vo-ac­ti­vo debe te­ner en cuen­ta las po­si­bles pér­di­das de tiem­po por inac­ti­vi­dad. “Las ope­ra­cio­nes ac­ti­vo/ac­ti­vo cues­tan un po­co más: al­re­de­dor del 20% adi­cio­nal en el hard­wa­re y el soft­wa­re. Pe­ro al ana­li­zar esos cos­tos adi­cio­na­les de­ben ser con­si­de­ra­das las com­pen­sa­cio­nes, co­mo las pér­di­das de los in­gre­sos que ge­ne­ran los tiem­pos de inac­ti­vi­dad que evi­tan. En ge­ne­ral, la pers­pec­ti­va de que las ope­ra­cio­nes ac­ti­vo/ ac­ti­vo so­lo se jus­ti­fi­can pa­ra las or­ga­ni­za- cio­nes que real­men­te no pue­den per­mi­tir­se el tiem­po de inac­ti­vi­dad es cier­ta,” di­jo Jus­tin Bar­ney, CEO de Sca­leArc. Bar­ney di­jo que la per­ma­nen­te de­man­da de dis­po­ni­bi­li­dad que pre­va­le­ce en ca­si to­das las in­dus­trias, las ope­ra­cio­nes ac­ti­vo/ ac­ti­vo ofre­cen cla­ra­men­te la me­jor com­bi­na­ción de ven­ta­jas. Hay nue­vos da­tos que mues­tran que los sis­te­mas de res­pal­do y los pro­ce­sos en los que la ma­yo­ría de las em­pre­sas se han ba­sa­do pa­ra ga­ran­ti­zar la con­ti­nui­dad del ne­go­cio an­te un desas­tre en reali­dad po­drían es­tar per­ju­di­can­do y no ayu­dan­do cuan­do se tra­ta de pre­ve­nir gran­des in­te­rrup­cio­nes. “Es­to es im­por­tan­te por­que es­tos sis­te­mas de re­cu­pe­ra­ción ya no sa­tis­fa­cen las ne­ce­si­da­des de las or­ga­ni­za­cio­nes que de­ben te­ner una dis­po­ni­bi­li­dad con­ti­nua”, sos­tu­vo Bar­ney. Las em­pre­sas de hoy en día no pue­den dar­se el lu­jo de fa­llar y lue­go re­cu­pe­rar­se, por­que que­dar fue­ra de lí­nea no es una op­ción y, por lo tan­to, el mo­de­lo ‘RD os­cu­ro’ fa­lla. Fos­ter no es­tá de acuer­do con esa opi- nión. Si si­gues rea­li­zan­do co­pias de seguridad y re­cu­pe­ra­ción de da­tos co­mo si fue­ra 2005 pue­de ser co­rrec­ta, pe­ro la reali­dad es que los clien­tes es­tán mo­der­ni­zan­do la for­ma en que eje­cu­tan su RD y sus co­pias de seguridad, pues sus in­fra­es­truc­tu­ras y ar­qui­tec­tu­ras han ma­du­ra­do y cam­bia­do. Cuan­do no lo ha­cen, las in­te­rrup­cio­nes pue­den ocu­rrir de­bi­do a que no se in­te­gran los desa­rro­llos más no­ve­do­sos. Ade­más, el flu­jo de tra­ba­jo normal del ser­vi­dor pri­ma­rio debe ser re­di­ri­gi­do al se­cun­da­rio que se con­vier­te, al me­nos tem­po­ral­men­te, en el nue­vo ser­vi­dor pri­ma­rio. Es­ta re­di­rec­ción pue­de re­que­rir can­ti­da­des sig­ni­fi­ca­ti­vas de con­fi­gu­ra­ción ma­nual, con dos equi­pos de TI (uno en ca­da ubi­ca­ción) tra­ba­jan­do ho­ras ex­tras pa­ra ha­bi­li­tar y so­lu­cio­nar el pro­ble­ma del tras­pa­so. Una re­con­fi­gu­ra­ción si­mi­lar se apli­ca a DNS, re­des, to­po­lo­gía de re­pli­ca­ción y otros ele­men­tos de in­fra­es­truc­tu­ra. Los re­qui­si­tos de las prue­bas son enor­mes, ya que el per­so­nal de TI adi­cio­nal debe ocu­par su lu­gar en la ins­ta­la­ción se­cun­da­ria, mien­tras que el equi­po ori­gi­nal se que­da con la pre­sión de con­se­guir que la ins­ta­la­ción prin­ci­pal es­té nue­va­men­te en lí­nea.

“Por su­pues­to que, mien­tras ve­mos que las gran­des tendencias gi­ran al­re­de­dor de la idea de que “el soft­wa­re se es­tá co­mien­do al mun­do” y “to­das las com­pa­ñías se es­tán con­vir­tien­do en com­pa­ñías de soft­wa­re,” hay ca­da vez me­nos or­ga­ni­za­cio­nes pa­ra las que el tiem­po de inac­ti­vi­dad es in­di­fe­ren­te. La RD a me­nu­do im­pli­ca por lo me­nos va­rios mi­nu­tos, si no más, de tiem­po de inac­ti­vi­dad, lo que se debe a que de pron­to es­tás ac­ti­van­do un sis­te­ma inac­ti­vo, el que po­dría ini­ciar su fun­cio­na­mien­to con pro­ble­mas. Pe­ro lo cier­to es que las ar­qui­tec­tu­ras ac­ti­vo/ ac­ti­vo son las más ade­cua­das pa­ra las or­ga­ni­za­cio­nes que no pue­den per­mi­tir­se un tiem­po de inac­ti­vi­dad,” di­jo Bar­ney.

Sca­leArc con­si­de­ró que los cos­tos de man­te­ni­mien­to de una ar­qui­tec­tu­ra ac­ti­vo/ac­ti­vo son más ba­jos por­que las ta­reas se pue­den ha­cer du­ran­te las ho­ras de tra­ba­jo en lu­gar de re­que­rir un equi­po en me­dio de la no­che.

Jo­seph Geor­ge, vi­ce­pre­si­den­te de ges­tión de pro­duc­tos de Sun­gard AS, di­jo que no en­mar­ca­ría el de­ba­te en­tre las dos ar­qui­tec­tu­ras úni­ca­men­te en tér­mi­nos de efi­cien­cia, ya que a me­nu­do el fac­tor más de­ci­si­vo qué ni­vel de re­si­lien­cia es­co­ge un ne­go­cio, lo que las em­pre­sas pue­dan pa­gar. Cla­ra­men­te, si el cos­to no fue­se un fac­tor, to­das las em­pre­sas ten­drían sis­te­mas de al­ta dis­po­ni­bi­li­dad. Pe­ro so­lo los adop­tan las que ne­ce­si­tan ese ni­vel pa­ra los sis­te­mas y apli­ca­cio­nes que más po­drían per­ju­di­car sus ob­je­ti­vos. “Es im­por­tan­te que las em­pre­sas ‘ni­ve­len’ sus apli­ca­cio­nes pa­ra ma­ne­jar el equi­li­brio eco­nó­mi­co en­tre el ries­go y la in­ver­sión ne­ce­sa­ria pa­ra mi­ti­gar­lo. La ni­ve­la­ción de apli­ca­cio­nes y el ma­peo de sus in­ter­de­pen­den­cias per­mi­ten una or­de­na­ción óp­ti­ma del or­den de re­cu­pe­ra­ción y ge­ne­ran el pro­gra­ma de dis­po­ni­bi­li­dad más ren­ta­ble pa­ra el ni­vel de tiem­po de inac­ti­vi­dad de la apli­ca­ción y la pér­di­da de da­tos que la or­ga­ni­za­ción pue­de per­mi­tir­se en fun­ción del im­pac­to em­pre­sa­rial”, aña­dió. La RD en ca­lien­te es­tá bien Swi­ke di­jo que la ma­yo­ría de las em­pre­sas real­men­te no ne­ce­si- tan una RD ac­ti­vo/ ac­ti­vo. La RD en ca­lien­te sa­tis­fa­ce sus ne­ce­si­da­des. Con un an­cho de ban­da apro­pia­do en­tre los si­tios, un RPO de se­gun­dos y RTO téc­ni­co de mi­nu­tos a ho­ras es muy fac­ti­ble. Aun­que la tec­no­lo­gía es so­lo par­te de la his­to­ria, pues tie­ne que ha­ber dis­ci­pli­na y tiem­po de­di­ca­do al pro­ce­so de RD. Te­ner ser­vi­do­res re­pli­ca­dos es un gran pa­so, pe­ro si no se po­nen a prue­ba re­gu­lar­men­te, ¿có­mo se sa­be que van a fun­cio­nar? Pa­ra mu­chos, la RD es la nú­me­ro 11 en su lis­ta de 10 prio­ri­da­des. Eso no sig­ni­fi­ca que no se preo­cu­pan por la RD, sino que los pro­ble­mas del día a día y los pro­yec­tos de pro­duc­ción tien­den a es­tar siem­pre en la par­te su­pe­rior de la lis­ta. Mi­ke We­ber, vi­ce­pre­si­den­te de la di­vi­sión de la­bo­ra­to­rios de Coal­fi­re, sos­tu­vo que la cla­ve de una só­li­da es­tra­te­gia de res­pal­do de­pen­de de las ne­ce­si­da­des del ne­go­cio y de la im­por­tan­cia crí­ti­ca de los ob­je­ti­vos del sis­te­ma. Hay mu­chos mo­de­los en ni­ve­les que ha­blan de da­tos crí­ti­cos, con un RTO muy cor­to me­di­do en mi­nu­tos, que re­quie­re co­pias de seguridad de flu­jo y/o la re­pli­ca­ción a un sis­te­ma re­dun­dan­te, pe­ro no de al­ta dis­po­ni­bi­li­dad, a tra­vés de los da­tos no crí­ti­cos que pue­dan ab­sor­ber el im­pac­to de la re­cu­pe­ra­ción me­di­do en días. “Ca­da uno de es­tos, con va­rios ni­ve­les en el me­dio, re­quie­re di­fe­ren­tes es­tra­te­gias pa­ra sa­tis­fa­cer tan­to la con­ti­nui­dad del ne­go­cio co­mo los ob­je­ti­vos de la re­cu­pe­ra­ción de desas­tres. Hay do­ce­nas de for­mas de lo­grar­lo,” di­jo We­ber. Di­jo que mu­chas ve­ces Coal­fi­re des­cu­bre que los si­tios de re­cu­pe­ra­ción de desas­tres o de res­pal­do no tie­nen las mis­mas pro­tec­cio­nes y con­tro­les de seguridad que los de­di­ca­dos a la pro­duc­ción. Las prue­bas de pe­ne­tra­ción han de­tec­ta­do que cuan­do hay sis­te­mas que se uti­li­zan en di­ver­sas ca­pa­ci­da­des de co­pia de seguridad o en re­dun­dan­cia, las res­tric­cio­nes pre­su­pues­ta­rias a me­nu­do dan co­mo re­sul­ta­do la fal­ta de los mis­mos con­tro­les de seguridad de red que pro­te­gen el en­torno de pro­duc­ción.

Newspapers in Spanish

Newspapers from Dominican Republic

© PressReader. All rights reserved.