ASM son las siglas de Automatic Storage Management, que es un producto de Oracle que hace de gestor de volúmenes lógicos y/o sistema de ficheros para albergar los ficheros de las bases de datos de la misma compañía. De esta forma, cuando se crea una base de datos Oracle se puede escoger que el almacenamiento para sus archivos sea ASM en vez de un sistema de archivos normal. ¿Pero qué es en realidad ASM? ASM es una instancia Oracle, con su SGA y sus procesos background, que interactúan con las instancias de la base de datos "cliente" para proporcionarle la información necesaria para que pueda leer y escribir en los archivos de datos (datafiles, control files, redo logs, archived logs, flashback logs, spfiles, RMAN backups, Incremental tracking bitmaps y datapumps dumpfiles). Es importante notar que ASM no sirve los bloques de datos a las instancias "cliente", sino que son ellas mismas las que acceden a los discos para leer o escribir. ASM lo único que hace es proporcionarle metainformación sobre dónde leer o escribir los datos.
La instancia ASM, como instancia que es, en vez de montar una base de datos monta disk groups, que son agrupaciones de ASM disks que se usan de forma transparente como si fuera uno sólo. Para verlo con más facilidad, es como si los disk groups fueran tablespaces y los ASM disks, datafiles. Los ASM disks pueden ser LUNs, discos físicos, particiones de discos físicos o incluso volúmenes lógicos aunque Oracle no recomienda esto último porque existiría solapamiento de funciones entre el volume manager instalado y el propio ASM.
ASM puede dar servicio tanto a una base de datos única como a un RAC (Real Application Cluster), que de hecho es donde es más habitual instalarlo. En un RAC, ASM corre en cada nodo y se comunica con el resto de ASMs del RAC a través de la interconexión, pero no nos perdamos en la configuración de RAC y ASM.
Retomando el término disk group, como hemos dicho, un fichero de las bases de datos "cliente" se asigna a un único disk group (un fichero sólo se asocia a un disk group, pero un disk group tiene multitud de ficheros). Las extensiones de los ficheros se distribuyen homogéneamente entre los ASM disks que conforman el disk group equilibrando así la carga de trabajo de los discos y mejorando el rendimiento general del sistema. Normalmente, las instancias usan sólo 2 disk groups para alojar todos sus archivos, una para datos y otra para fast recovery area.
Otra de las funcionalidades de ASM es que permite añadir o eliminar en caliente ASM disks redistribuyendo el contenido del disk group entre los ASM disks que haya. Si se quiere eliminar un ASM disk, antes ASM tiene que redistribuir los datos del disco a eliminar entre los restantes. Si se añade un ASM disk, ASM redistribuye el contenido del disk group entre todos los ASM disks, dado que ahora hay uno más. Lo más interesante es que esta operación la hace ASM en caliente permitiendo a las instancias acceder a sus ficheros mientras se está produciendo el rebalanceo.
Además de poder hacer redistribución (striping), ASM puede hacer redundancia (mirroring) de los datos. Para ello, al crear un disk group se indica el failure group asociado y ASM distribuye cada copia a un fail group distinto. La ídea del fail group es coger los ASM disks del disk group y hacer grupos distintos, los llamados fail groups, de forma que cada grupo esté protegido de los fallos que pueda tener el otro. Ahora bien, en función del tipo de contingencia para la que nos queramos proteger tendremos una agrupaciones u otras. Por ejemplo, un disk group con dos ASM disks podemos definirlo con dos fail groups, cada uno con un sólo disco. Así, la avería de un disco no me dejaría sin datos (tengo otro réplica del afectado). Pero si hay una avería de la controladora de los discos, que es común para ambos, nos quedaríamos sin acceso a los datos. Entonces habría que escoger discos distintos en distintas controladoras. ¿Y si se avería el hardware en donde residen ambas controladoras?. De acuerdo, pues usamos dispositivos de almacenamiento absolutamente distintos. ¿Y si se prende fuego el CPD?.... y así podemos seguir hasta el infinito.
En relación a la redundancia, también se puede hacer réplica de los datos duplicándolos o triplicándolos. Cuando se define el disk group se indica si la replicación será EXTERNAL (sin replicación ASM), NORMAL (se duplican los datos) o HIGH (se triplican los datos). En una configuración NORMAL serán necesarios dos fail groups y en HIGH, tres fail groups.
Por último y para acabar esta breve introducción, sólo decir ASM se puede integrar completamente con OMF (Oracle Managed Files) escribiéndo únicamente el nombre del disk group allí donde se tendría que poner el nombre completo del archivo.
Continuaré escribiendo cosas de ASM, esto es sólo ha sido una breve introducción para coger nociones de qué es y para qué sirve.
Juan Lorenzo Arellano.
Infor Consult Soluciones.
www.inforconsult.es
Suscribirse a:
Enviar comentarios (Atom)
5 comentarios:
Gracias! está bien explicado.
Sael, gracias a ti por leerme y por molestarte en en opinar. En breve publicaré más cosas de ASM.
Excelente tu explicación, espero seguir el paso hasta crear luns.
o llegar a instalar la BD en rac.
Buena explicación, podriamos comentar si el rendimiento en la bd baja si la redundancia es normal o high
Necesito sacar una introducción y conclusión de este reporte
Resumen Ejecutivo
Durante el mes de Julio, a través de su Coordinador de infraestructura tecnológica XX XXXXX, reporta al centro de servicios NASTY COMPANY, que su base de datos de prod ucción no está disponible por falla en sus discos ASM de
Esta falla deja a la organización sin servicio de base de datos de producción a partir de las 12:00 p.m. NASTY COMPANY atiende el caso, asignando el número de ticket 407842 y lo escala al especialista de base de datos XXXXXXXX.
Luego que el especialista de base de datos hace una revisión detallada, se consiguió una intermitencia en los discos ASM, la cual fue resuelta automáticamente por el mot or de basede datos, pero dejó una inconsistencia en la Base de datos que no se pudo recuperarpor la vía de las herramientas automáticas del servidor, ya que por razones a ún no claras este comando estaba pidiendo un archivo de transacciones con un núme to de secuencia muy viejo y que lógicamente por lo antiguo, no se tenia disponible.
Por lo limitado del tiempo para estos casos donde el servicio se debe restablecer lo más pronto posible, y por tratarse del servidor de productivo, no se pudo revisar en ma s detalle la causa raiz de las fallas, por lo que se le formularlo a la organización, las di ferentes alternativas disponibles para hacer la recuperación de la base de datos.
Ellos seleccionaron el escenario donde se borra la BD de producción y se genera a par tir de una de las copias de las base de datos secundarias que ellos generan 2 veces al dia. La recuperación de la BD fue exitosa, pero al reiniciar el servidor, nuevamente se p resentó la falla en los discos ASM
Se decidió con el coordinador de infraestructura, restaurar todo el servidor, a partir de un punto de restauración virtual que ellos habian generado un dia antes de la falla. Lu ego sobre esa imagen se generó la base de datos a partir de una de las copias secund arias y que tiene la data hasta el mismo día anterior a la incidencia.
De esta forma los servicios de base de datos se levantaron exitosamente el mismo dia de la notificación del servicio y el coordinador certifico el acceso al aplicativo.
Recomendaciones Con el objetivo de mitigar este tipo de fallas a futuro, se recomienda:
1.-Activar nuevamente y validar la ejecución sin error de los procesos planificados en el programador de los servidores, los cuales fueron desactivados para no interferir co n el proceso de recuperación por la falla de los discos ASM.
2: Fortalecer la politica de recuperación en caso de desastres con servidores, elcu al consiste en tener un servidor de base de datos en un localidad remota, que será ima gende producción y se mantendrá actualizado "casi al momento" y cuyos tiempos de activaciónen caso de una falla es casi de inmediato.
Se informa a la organización que la disponibilidad del servicio de base de datos se en
cuentra nuevamente disponible para que inicien las pruebas de validación funcional e
on la imagen establecida en el soporte realizado.
Publicar un comentario