Por tanto, una de las configuraciones es la política de replicación la cual, de forma simple, establece que snapshots queremos transferir al sistema destino. Las políticas de replicación predefinidas en ONTAP son las siguientes:
Si listamos las políticas predefinidas para el tipo async-mirror correspondiente a SnapMirror, veremos lo siguiente:
Como podemos ver hay tres políticas diferentes, siendo la política DPDefault la política correspondiente al modo de replicación Data Protection que, como recordaremos, era el modo por defecto empleado al crear una relación SnapMirror hasta ONTAP 9.3. Si comparamos esta polítca con la política MirrorAllSnapshots podemos comprobar que son idénticas, ya que esta es la nueva política por defecto empleada desde ONTAP 9.3.
Como podemos ver en la salida del comando anterior, las políticas contienen una serie de reglas con lo que vamos a analizarlas más detenidamente:
 |
| Política MirrorAllSnapshots. |
 |
| Política MirrorLatest. |
Como podemos ver, la principal diferencia entre ambas políticas es que MirrorAllSnapshots contiene una regla que indica que hay que transferir todos los snapshots del origen, indicada por la regla número 2 y la etiqueta all_source_snapshots. La pregunta es ¿que son estas reglas y cual es su relación con la transferencia de snapshots?
Para esto primero empecemos por analizar un snapshot en nuestro sistema origen:
 |
| Características de un snapshot. |
De todas las características que podemos ver en la salida, vemos que hay un campo Label for SnapMirror Operations, cuyo valor es standard. Debemos recordar, que esta etiqueta de snapshots la fijamos nosotros en el momento de crear las políticas de snapshots para nuestros volúmenes.
Si buscamos este mismo snapshot en el sistema destino veremos que tiene las mismas características y que, salvo los valores que cambian debido a que se ha transferido al cluster destino, veremos que el campo de etiqueta contiene el mismo valor identificado como standard.
Adicionalmente, si nos fijamos en los snapshots creados por las operaciones de snapmirror, identificados con el nombre snapmirror tanto en origen como en destino, veremos que también tienen un campo label, pero en este caso está vacia.
Lo que establecen las reglas de las políticas de SnapMirror es el nombre de la etiqueta de los snapshots que se transferiran y, en el caso de las políticas predefinidas las reglas establecen:
- sm_created - Esta etiqueta fuerza la transferencia del snapshot creado por SnapMirror en cada transferencia programada. Este snapshot siempre estará identificado con una etiqueta SnapMirror vacía. Como indica la documentación, esta regla no puede modificarse ni puede eliminarse de la política.
- all_source_snapshots - Esta etiqueta indica que deben transferirse todos los snapshots del volumen origen, realizados desde la útlima replicación.
Veamos un ejemplo modificando la etiqueta de un snapshot del volumen origen. Para esto, primero vamos a crear un snapshot del volumen origen al cual vamos a fijar una etiqueta de snapmirror diferente, lo cual podemos hacer con un comando como el siguiente:
 |
| Creación de un snapshot con una etiqueta de pruebas. |
Ahora podemos ver los snapshots del volumen y veremos que la etiqueta es difernte del resto de snpashots:
 |
| Lista de snapshots del volumen origen. |
Con esta nueva etiqueta y la programación que establecimos para la relación de SnapMirror, vemos que la regla all_source_snapshots transfiere todos los snapshots existentes en el volumen origen como ya hemos visto independientemente de su etiqueta, y por tanto ahora tenemos nuestro snapshot snap_test en el volumen destino:
 |
| Snapshots del volumen destino incluyendo el snapshot de test. |
Teniendo en cuenta que SnapMirror es una solución de disaster recovery y que, como es lógico, deberíamos tener nuestros datos de origen totalmente replicados en destino, el comportamiento de la política MirrorAllSnapshots es el esperado en ese caso.
Al comparar esta política con la política MirrorLatest, vemos que la diferencia fundamental es que únicamente contiene la regla con la etiqueta sm_created, es decir, todas aquellas relaciones de protección que utilicen esta política solo transferiran el snapshot creado por SnapMirror en cada actualización.
Y nos podemos preguntar ¿y si quiero crear mi propia política de SnapMirror y especificar reglas diferentes? Pues en ese caso, como podemos ver a continuación, veremos que no es posible cuando usamos una política de tipo async-mirror.
Emepcemos creando una nueva política de Snapmirror en nuestro cluster destino, en la cual vamos a especificar que es de tipo async-mirror por tratarse de una relación SnapMirror y que habrá una regla para los snapshots con una etiqueta DEVELOP, forzando así que no se transfieran todos los snapshots que puedan existir en el volumen origen, sino solo aquellos que contengan dicha etiqueta. Esta política podemos crearla con el siguiente comando:
 |
| Creación de una política de SnapMirror. |
Como ya hemos visto, esta política recien creada tiene por defecto la regla sm_created, para asegurar que se transferirá en todas las actualziaciones de la relación de protección, el snapshot creado por SnapMirror:
 |
| Nuestra política recien creada. La regla sm_created la incluye ONTAP. |
Si ahora intentamos añadir la regla indicando la etiqueta de los snapshots de origen que queremos que se transfieran, que en este caso es DEVELOP recibiremos un bonito mensaje de error como el siguiente:
 |
| Error al intentar modificar una política de tipo async-mirror. |
De nuevo pensemos que SnapMirror es una solución de disaster recovery, está diseñado para replicar todos los datos de nuestros volúmenes de origen y establecer reglas para determinadas etiquetas implicaría no replicar toda la información. Para poder establecer relaciones de protección, en las que controlar los snapshots de origen que deben transferirse a destino, tendremos que establecer relaciones de SnapVault lo cual veremos en futuras entradas.
Por tanto, y en resumen, las políticas de SnapMirror contienen reglas que definen su comportamiento. En el caso de las relaciones SnapMirror de tipo async-mirror, o lo que es lo mismo relaciones de protección para disaster recovery, estas reglas se asegurarán de transferir siempre la información actual del volumen origen y, si así lo deseamos, de todos los snapshots que se hayan generado desde la última transferencia de datos.
