Recuperación tras fallos y cambio de ONTAP
Sugerir cambios
PDF
Se requiere comprender las funciones de toma de control y conmutación de sitios de almacenamiento para garantizar que estas operaciones no interrumpan las operaciones de la base de datos de Oracle. Además, los argumentos utilizados por las operaciones de toma de control y conmutación de sitios pueden afectar a la integridad de los datos si se usan incorrectamente.
-
En condiciones normales, las escrituras entrantes en una controladora determinada se reflejan de forma síncrona en su compañero. En un entorno NetApp MetroCluster, las escrituras también se reflejan en una controladora remota. No se reconoce en la aplicación host hasta que se almacena una escritura en medios no volátiles en todas las ubicaciones.
-
El medio que almacena los datos de escritura se denomina memoria no volátil o NVMEM. También se conoce a veces como memoria de acceso aleatorio no volátil (NVRAM), y se puede considerar como una caché de escritura aunque funciona como un diario. En un funcionamiento normal, los datos de NVMEM no se leen; solo se utilizan para proteger los datos en caso de un fallo de software o hardware. Cuando se escriben datos en las unidades, los datos se transfieren desde la RAM del sistema, no desde NVMEM.
-
Durante una operación de toma de control, un nodo de una pareja de alta disponibilidad toma el control de las operaciones de su compañero. Una conmutación de sitios es básicamente la misma, pero se aplica a las configuraciones de MetroCluster en las que un nodo remoto toma las funciones de un nodo local.
Durante las operaciones de mantenimiento rutinarias, una operación de toma de control o de conmutación de sitios debería ser transparente, excepto en una breve pausa potencial de las operaciones cuando cambian las rutas de red. Sin embargo, las redes pueden ser complicadas y es fácil cometer errores, por lo que NetApp recomienda encarecidamente probar exhaustivamente las operaciones de toma de control y conmutación antes de poner un sistema de almacenamiento en producción. Hacerlo es la única forma de asegurarse de que todas las rutas de red están configuradas correctamente. En un entorno SAN, compruebe cuidadosamente la salida del comando sanlun lun show -p para asegurarse de que todas las rutas primarias y secundarias esperadas estén disponibles.
Se debe tener cuidado al emitir una toma de control forzada o cambio. Al forzar un cambio en la configuración de almacenamiento con estas opciones, se ignorará el estado de la controladora propietaria de las unidades y el nodo alternativo tomará el control de las unidades de manera forzada. El forzado incorrecto de una toma de control puede provocar la pérdida de datos o la corrupción. Esto se debe a que una toma de control o una conmutación por error forzada pueden descartar el contenido de NVMEM. Una vez completada la toma de control o la conmutación por error, la pérdida de esos datos implica que los datos almacenados en las unidades pueden revertir a un estado ligeramente más antiguo desde el punto de vista de la base de datos.
En raras ocasiones se debería necesitar una toma de control forzada con un par de alta disponibilidad normal. En prácticamente todas las situaciones de fallo, un nodo se apaga e informa al partner para que se produzca una conmutación automática al respaldo. Hay algunos casos periféricos, como un fallo gradual en el que se pierde la interconexión entre nodos y después se pierde una controladora, en el que se requiere una toma de control forzada. En esta situación, el mirroring entre nodos se pierde antes del fallo de la controladora, lo que significa que la controladora superviviente ya no tendría una copia de las escrituras en curso. Entonces, se debe forzar la toma de control, lo que significa que potencialmente se pueden perder los datos.
La misma lógica se aplica a un switchover de MetroCluster. En condiciones normales, una conmutación es prácticamente transparente. Sin embargo, un desastre puede resultar en una pérdida de conectividad entre el sitio sobreviviente y el sitio del desastre. Desde el punto de vista del sitio sobreviviente, el problema podría ser nada más que una interrupción en la conectividad entre sitios, y el sitio original podría aún estar procesando datos. Si un nodo no puede comprobar el estado de la controladora principal, solo es posible realizar una conmutación de sitios forzada.
|
NetApp recomienda tomar las siguientes precauciones:
|
MetroCluster y varios agregados
MetroCluster es una tecnología de replicación síncrona que cambia al modo asíncrono en caso de interrupción de la conectividad. Esta es la solicitud más común de los clientes, porque la replicación síncrona garantizada implica que la interrupción de la conectividad del sitio provoca una parada completa de las operaciones de I/O de la base de datos, lo que impide que la base de datos funcione.
Con MetroCluster, los agregados se resincronizan rápidamente después de restaurar la conectividad. A diferencia de otras tecnologías de almacenamiento, MetroCluster nunca debería requerir un nuevo mirroring completo tras un fallo del sitio. Sólo se deben enviar los cambios delta.
En conjuntos de datos que abarcan agregados, existe el pequeño riesgo de que se requieran pasos adicionales de recuperación de datos en un escenario de desastre continuo. Específicamente, si (a) se interrumpe la conectividad entre sitios, (b) se restaura la conectividad, (c) los agregados alcanzan un estado en el que algunos están sincronizados y otros no, y luego (d) se pierde el sitio principal, el resultado es un sitio superviviente en el que los agregados no están sincronizados entre sí. Si esto sucede, algunas partes del conjunto de datos se sincronizan entre sí y no es posible activar aplicaciones, bases de datos o almacenes de datos sin recuperación. Si un conjunto de datos abarca agregados, NetApp recomienda aprovechar los backups basados en instantáneas con una de las muchas herramientas disponibles para verificar la capacidad de recuperación rápida en este escenario inusual.