LA TRANSFORMACIÓN DEL RESPALDO DESDE ADENTRO

LA TRANSFORMACIÓN DEL
RESPALDO DESDE ADENTRO
Entrevista con Darryl Smith, el arquitecto principal
de Oracle de EMC
¿Qué es la transformación del respaldo y por qué es tan importante para la
fortaleza y la prosperidad de una organización? En esta entrevista, Darryl
Smith, arquitecto principal de Oracle de EMC y veterano de las guerras del
respaldo, proporciona una perspectiva interna de la necesidad y el impacto de
la transformación del respaldo dentro del departamento de TI de EMC y nuestro
propio negocio.
Smith, que es responsable de todas las bases de datos de EMC (principalmente,
de Oracle, pero también de SQL Server, MySQL, Postgres y Greenplum),
describe los cambios en los procesos y el personal que ha atravesado el
"Si la infraestructura de respaldo no puede
mantener el ritmo de la explosión de los
datos o igualar la movilidad del cómputo en
la nube, la base de datos se verá
perjudicada... Por lo tanto, es sumamente
importante asegurarse de que la
infraestructura de respaldo sea mucho más
ágil y permita un escalamiento mucho más
dinámico que ahora". (Darryl Smith)
departamento de TI de EMC y los efectos innovadores que han tenido. También
analiza lo que depara el futuro y proporciona su punto de vista sobre el ideal
del respaldo.
Para
obtener
más
información
y
recursos,
visite
mexico.emc.com/BackupLeader (visite el sitio web de su país correspondiente).
COMO ARQUITECTO DE ORACLE,
¿POR QUÉ ES IMPORTANTE EL RESPALDO
PARA SU TRANQUILIDAD?
Soy responsable de asegurarme de que las bases de datos de EMC estén en
buenas condiciones, funcionen correctamente y sean capaces de atender a los
usuarios del negocio y proporcionarles la información que necesitan. Si yo o mi
equipo no vamos a trabajar, todo se detiene. Si no funciona la base de datos
que respalda la aplicación de CRM, la aplicación de servicio al cliente o
cualquier aplicación que se esté ejecutando, la aplicación tampoco funcionará.
Y para que yo pueda hacer mi trabajo, el respaldo es esencial. Una de las
mayores dificultades que enfrentamos cuando comenzamos el viaje a la nube
era que nuestra infraestructura de respaldo no podía mantener el ritmo.
Dependíamos de infraestructuras basadas en sistemas antiguos y de soluciones
de respaldo punto a punto. Eso era un problema para mi tranquilidad y sigue
siendo un problema para muchas organizaciones actuales.
ENTONCES, ¿LA TRANSFORMACIÓN DEL
RESPALDO ES UN PASO IMPORTANTE?
Sí. Realmente, es un paso que debemos dar. No es posible continuar
respaldando de la manera que siempre lo hacíamos en el pasado, porque el
proceso tradicional no brinda escalamiento y no funciona en infraestructuras de
nube virtualizadas. El motivo es que todas las aplicaciones, desde los pequeños
sistemas de calendarización de la sala de conferencias hasta las aplicaciones de
ERP o de servicio al cliente de misión crítica más importantes, están centradas
en los datos. Por lo tanto, es esencial que los datos estén protegidos, y esto no
es posible sin la transformación del respaldo.
FOLLETO
¿Y ESTO PUEDE AFECTAR LOS ESFUERZOS
DE IMPLEMENTAR LA VIRTUALIZACIÓN Y
LA NUBE?
Exactamente. Si la infraestructura de respaldo no puede mantener el ritmo de
la explosión de los datos o igualar la movilidad del cómputo en la nube, la base
de datos se verá perjudicada. Esto puede implicar desde la reducción del
rendimiento de las aplicaciones hasta la pérdida de datos o, incluso, una falla
completa de las aplicaciones, que, obviamente, podría resultar crítica para un
negocio. Por lo tanto, es sumamente importante asegurarse de que la
infraestructura de respaldo sea mucho más ágil y permita un escalamiento
mucho más dinámico que ahora.
¿QUÉ HA HECHO EN LOS ÚLTIMOS AÑOS
PARA TRANSFORMAR EL RESPALDO?
Actualmente, desde el punto de vista de los servidores, tenemos una virtualización
del 94 %. Desde el punto de vista de las bases de datos, tenemos una
virtualización de alrededor del 84 % y, en este momento, estamos virtualizando lo
más rápido posible. Esto tiene un impacto significativo sobre el respaldo.
Cuando empezamos, utilizábamos metodologías tradicionales de respaldo.
Respaldábamos utilizando RMAN tradicional en nuestro calendarizador de
respaldo, EMC NetWorker, y lo respaldábamos en dispositivos de cinta o en
dispositivos de cinta virtual basados en discos. Las cintas, obviamente, son una
tecnología muy antigua, de modo que las reemplazamos con librerías de cintas
virtuales. Pero ni siquiera estas proporcionaban escalamiento horizontal, y
estábamos midiendo, cuantificando y restringiendo el uso de esos recursos
constantemente.
Ese era el núcleo real de nuestro problema: teníamos una cantidad limitada de
recursos y una cantidad cada vez mayor de bases de datos y de datos que
debían
respaldarse.
Para
mantenernos
a
la
par
de
la
virtualización,
básicamente, dejamos a un lado todas nuestras plataformas anteriores. Incluso
los nodos de almacenamiento de NetWorker se han virtualizado.
¿CUÁL ES EL ESTADO ACTUAL DE LA
TRANSFORMACIÓN DEL RESPALDO?
Ahora, después de 24 meses, nos estamos dirigiendo al escalamiento horizontal
de
la
infraestructura.
Eliminamos
los
dispositivos
de
cinta
y
estamos
reemplazando nuestros dispositivos de cintas virtuales con dispositivos Data
Domain, que tienen mucha más capacidad y mucho más rendimiento, y
permiten almacenar los datos por muchísimo más tiempo gracias a la
deduplicación. Y este primer paso realmente nos ha ayudado a reducir las
restricciones de capacidad. Ahora sabemos que, si necesitamos restaurar un
respaldo, podemos recuperarlo con bastante rapidez, sin necesidad de
depender de cintas o de almacenamiento fuera del site. Sin embargo, seguimos
administrando el respaldo como si algunas de esas antiguas restricciones
siguieran existiendo, y es allí donde necesitamos comenzar a llevar este
proceso al siguiente nivel.
Además, hemos trabajado para brindar "base de datos como servicio", lo cual
nos permitió automatizar completamente el respaldo y la recuperación a fin de
que, básicamente, no necesiten intervención. Antes, cuando no existía esta
expansión desmedida de big data, cuando no había cómputo móvil, podíamos
configurar los respaldos y olvidarnos de ellos, y no había ningún problema.
Ahora, la realidad es mucho más complicada; pero, dado que podemos
automatizar los respaldos y ejecutarlos completamente mediante scripts, ya no
debemos preocuparnos por si los respaldos se llevan a cabo, gracias a que
eliminamos las variables.
Estamos haciendo lo mismo con algunas de nuestras bases de datos de gran
tamaño. Trabajamos con los equipos de respaldo y diseñamos un respaldo
descargado. Con esto me refiero a que tomamos un clon de almacenamiento,
lo montamos en un servidor proxy o un nodo de almacenamiento de NetWorker
y respaldamos la base de datos desde allí. En este caso, la base de datos de
respaldo o el servidor proxy están conectados directamente a Data Domain, de
modo que no existen limitaciones de recursos. De esta manera, ahora los
respaldos funcionan a la perfección y, además, a muy alta velocidad.
Estos son dos ejemplos del trabajo que hemos estado realizando con el equipo
de respaldo para proporcionar un respaldo que sea confiable y escalable, y que
nos permita, básicamente, configurarlo y olvidarnos de él.
AL PARECER, ESTÁ TRABAJANDO DE UN
MANERA DIFERENTE CON EL EQUIPO DE
RESPALDO. ¿CÓMO HAN CAMBIADO LOS
PROCESOS?
El reemplazo de nuestra infraestructura es solo el comienzo del proceso de
transformación de la manera en que funciona nuestra infraestructura de
respaldo.
Realmente,
tenemos
que
trabajar
más
en
los
procesos
y
procedimientos. Por ejemplo, es bueno tener un calendarizador para toda la
empresa. Pero intentar administrar los recursos y componentes individuales
como una tarea manual impide proporcionar escalamiento horizontal dinámico
y obtener la agilidad que el cómputo en la nube realmente necesita.
En realidad, la clave de toda esta transformación es la fusión de todos estos
miembros, grupos y habilidades individuales en un conjunto de habilidades más
grande.
Hablamos
sobre
esto
todo
el
tiempo
cuando
analizamos
la
transformación de TI: todas las habilidades deben unirse. Esto no significa
necesariamente que una persona deba saberlo todo, sino que las personas con
diferentes conjuntos de habilidades necesitan trabajar de manera estrecha para
realmente formar parte de ese equipo de arquitectura principal y para que, al
mismo tiempo, el conocimiento se comparta.
¿CÓMO SE HAN MODIFICADO LAS
RELACIONES CON EL EQUIPO DE
RESPALDO?
Bueno, la relación se estaba volviendo tensa. Teníamos muchas dificultadas con
los respaldos, y los equipos de respaldo estaban constantemente respondiendo
ante los problemas. La exigencia pesaba sobre ambas partes: el equipo de
respaldo y los DBA se sentían muy frustrados. Debían ocuparse de problemas
diarios y estaban constantemente respondiendo ante las dificultades. Era un
problema constante, y no solo hacía que las relaciones fueran tensas, sino que
también afectaba nuestra capacidad de proporcionar un servicio a nuestros
usuarios del negocio.
Tradicionalmente, el equipo de respaldo ha sido, en gran medida, un equipo
interno. No se escucha hablar de ellos; no forman parte de los acontecimientos
más importantes de TI; no forman parte del proceso de toma de decisiones.
Simplemente, hacen los respaldos. Pero ese tipo de pensamiento o cultura ya
no funciona. El equipo de respaldo realmente necesita formar parte del equipo
principal de TI y colaborar en la transformación integral de TI. Si no lo hace,
aparecerán los problemas. Las bases de datos no se ejecutarán del modo que
deberían; se retrasarán al intentar terminar los respaldos. En caso de falla, no
será posible recuperar los sistemas ni los datos. El respaldo realmente debe
integrarse en los procesos principales como nunca antes lo hizo.
¿HACIA DÓNDE SE DIRIGE? ¿CUÁL ES EL
IDEAL DEL RESPALDO PARA USTED?
Bueno, actualmente, no hemos implementado el respaldo como servicio de
forma integral, pero lo estamos usando de manera limitada. Por ejemplo, todas
nuestras otras ofertas de TI como servicio, infraestructura como servicio y base
de datos como servicio utilizan respaldos, y estos están completamente
automatizados y se proporcionan como servicio.
Por lo tanto, la etapa final o el objetivo de la transformación de nuestra
infraestructura de respaldo es que los administradores de respaldo sean
responsables de la infraestructura y de la planificación de capacidad para
garantizar que contemos con capacidad suficiente. Por mi parte, como
consumidor, como el DBA que está consumiendo estos servicios de respaldo,
necesito poder configurar mis propios respaldos, ejecutarlos cuando lo desee y
realizar restauraciones según sea necesario sin tener que depender de otro
grupo para asegurarme de que todo esté funcionando. Por lo tanto, mi ideal es,
básicamente, controlar una consola en la que pueda calendarizar todos los
respaldos de base de datos sin preocuparme por si tengo capacidad o no.
Es similar a la electricidad. Cuando presiono el interruptor, espero que las luces
se enciendan, porque estas reciben suficiente energía. Me gustaría que los
respaldos fueran igualmente sencillos.
¿QUÉ TECNOLOGÍAS DE EMC ESTÁ
UTILIZANDO? ¿QUÉ CAMBIOS
REVOLUCIONARIOS PERMITIERON?
Una de las primeras medidas que tomamos fue comprar sistemas EMC
Data Domain, incluso antes de que EMC adquiriera la empresa. Los elegimos a
causa de la deduplicación. Desde luego,ya contábamos con Avamar, que
permite un nivel significativo de deduplicación. Es excelente para respaldar
sistemas operativos y equipos de escritorio, y teníamos una gran inversión en
Avamar para eso. Pero, para las bases de datos, necesitábamos algo con una
capacidad mucho mayor y por eso elegimos Data Domain.
Siempre contamos con NetWorker, que facilita ampliamente los respaldos. Los
DBA están acostumbrados a utilizar RMAN para realizar respaldos, pero RMAN
necesita escribir en un dispositivo de cinta. Los sistemas operativos no suelen
contar con dispositivos de cinta incorporados. Entonces, NetWorker actúa como
el dispositivo de cinta virtual para el respaldo RMAN, lo cual nos brinda una
integración completa; los DBA pueden iniciar un respaldo, y NetWorker, por
medio de los nodos de almacenamiento, realizará el respaldo, en este caso, en
el dispositivo Data Domain. Esa integración es muy importante.
Una de las tecnologías más recientes que estamos analizando es DD Boost de
Data Domain. Esta tecnología también está integrada con RMAN. De modo que
los DBA pueden usar los respaldos RMAN tradicionales y obtener los beneficios
de un producto como DD Boost, sin necesidad de conocer nada acerca del
producto, que brinda un control completo a los DBA.
Otro motivo por el que estamos intentando realizar una implementación
generalizada de DD Boost es que reduce los recursos necesarios para realizar
los respaldos, ya que gran parte de la deduplicación del respaldo se descarga
en el mismo servidor de bases de datos, por lo que se trasmiten muchos menos
datos a través de la red. Esto permitirá respaldar mucho más al mismo tiempo,
ya sean bases de datos o sistemas operativos. Pero, lo que es más importante,
permitirá que los respaldos se trasladen un poco más lejos. Entonces, ahora
podemos tener una infraestructura que se adecue a la movilidad del cómputo
en la nube.
Otra de las medidas que tomamos fue respaldar directamente en dispositivos
Data
Domain.
De
esta
manera,
podemos
usar
productos
como
VMware Data Director, configurar algunas de las áreas de almacenamiento de
datos
como
montajes
de
NFS
de
Data
Domain
y
tomar
clones
de
almacenamiento y escribirlos directamente en el dispositivo Data Domain. Y
podemos hacer lo mismo con herramientas como Export o Data Pump de Oracle,
o con los respaldos manuales. En SQL Server, a veces, simplemente hacemos
respaldos manuales del sistema de archivos directamente en Data Domain.
EMC2, EMC y el logotipo de EMC son marcas registradas o marcas comerciales de
EMC Corporation en los Estados Unidos y en otros países. VMware es una marca registrada o
marca comercial de VMware, Inc. en los Estados Unidos y en otras jurisdicciones.
© Copyright 2012 EMC Corporation. Todos los derechos reservados. 11/12 Folleto H11297.
mexico.emc.com
(visite el sitio web de su país correspondiente)
EMC considera que la información de este documento es precisa en el momento de su
publicación. La información está sujeta a cambios sin previo aviso.