Almacenamiento ZFS, entornos de espera y prueba

- ¿Tenemos alguna foto para enero, más cerca de febrero?
- Ahora veamos ... ¡Sí, lo hay! Ahora abierto

Sucede que hay una vida útil promedio de la base de prueba, hay una vida útil para las instantáneas acordadas por todos los interesados, pero algunos de los entornos "permanecen" demasiado tiempo en su imagen, lo que no se puede eliminar ... y luego resulta ser útil para los colegas. Y menos a menos da un plus.

Por lo general, para cualquier sistema en el que algo pueda suceder, debe crear copias de seguridad. Y si todavía se está desarrollando y finalizando, entonces en algún lugar también es necesario implementar entornos de desarrollo y prueba. Además, para las copias de seguridad y los entornos de prueba que funcionan, de hecho, con los mismos datos, necesita mucho espacio. Y, sin embargo, estos entornos deben de alguna manera conducir al estado actual. Y todo esto requiere hardware y recursos de tiempo.

En nuestro caso, estas necesidades fueron cubiertas por el dispositivo de almacenamiento Oracle ZFS y los servidores Oracle / Sun, que realmente se fusionaron en el mismo ecosistema que Exadata, que apareció poco antes que ellos.

Dado que hay un conmutador InfiniBand dentro de Exadata, a través del cual se comunican sus componentes, y ZFS Storage también es un dispositivo Oracle, entonces:

• en primer lugar, estaba conectado directamente a este conmutador por parte de sus puertos;
• en segundo lugar, puede almacenar archivos de espacio de tabla con segmentos comprimidos en la compresión de columnas híbrida Exadata (EHCC), lo que nos ahorra mucho espacio en el sistema principal. Si intenta restaurar la base de datos en un servidor separado, luego de la recuperación, refiriéndose a los datos comprimidos, obtendrá el error: "ORA-64307: la compresión columnar híbrida no es compatible con espacios de tablas en este tipo de almacenamiento", porque los archivos de datos comprimido en el EHCC debe almacenarse en el dispositivo Oracle;
• En tercer lugar, esto abre la posibilidad de utilizar las capacidades de ZFS para almacenar archivos de entorno de prueba.

Bueno, ¿qué hay del lugar? Se debe evitar la duplicación.

Los entornos de prueba necesitan los mismos datos que en las copias de seguridad. ¿Pueden estos datos realizar ambas funciones? ¿Para ser una copia de seguridad y una base para cualquier entorno de prueba privilegiado que necesite un conjunto de datos completo? Pueden!

El dispositivo de almacenamiento Oracle ZFS es una matriz que proporciona, entre otras cosas, la capacidad de formar recursos compartidos de red que se ejecutan bajo el sistema de archivos ZFS. Dentro del sistema de archivos ZFS, es posible crear instantáneas, en función de las cuales puede implementar clones, que son visibles como nuevos recursos compartidos de red. Utilizamos esta oportunidad de la siguiente manera:

1. En ZFS Storage (como llamaremos a la matriz, para no confundirnos con el sistema de archivos), se crean dos recursos compartidos: Archivelog se agrega a uno y los archivos de base de datos al otro;
2. El recurso compartido se monta en el servidor Oracle / Sun (que también es el dispositivo), y en el servidor mismo se eleva una instancia de Oracle Database, que actúa como un modo de espera físico en cascada: recibe registros de un sitio de copia de seguridad condicional y aplica los cambios a los archivos en el recurso compartido;
3. El uso de registros se organiza de acuerdo con el principio de la unidad de trabajo (¡hola a todos los participantes en informática distribuida!). A nivel de algoritmo, se introduce el concepto de unidad de trabajo, que corresponde a un cierto intervalo de tiempo. Después de rodar los registros durante el intervalo requerido, la instancia se detiene y los archivos permanecen en el recurso compartido en un estado coherente entre sí y con el archivo de control. De hecho, esta es una copia de seguridad en frío, también es una copia de imagen, sobre la cual se realiza una instantánea;
4. Cuando llega el momento de recrear el entorno de prueba, se crea un clon a partir de la instantánea deseada. Se monta en el servidor en el que se ejecuta el entorno, después de lo cual los archivos se abren como una base de datos con un nombre diferente y en modo de lectura / escritura;
5. En el proceso de trabajar en la base de prueba, se realizan cambios que se posponen como parte del clon, y está creciendo lentamente. Al final del ciclo de vida, el medio crece al máximo.
6. Para reducir el consumo de espacio en disco, utilizamos la compresión LZJB, que ZFS Storage realiza sobre la marcha.

En resumen:

1. En la configuración actual, los entornos de prueba pueden realizar E / S hasta el nivel de 3.75 Gb / s;
   El máximo para la lectura está limitado por la configuración del puerto InfiniBand existente en el servidor, el máximo para la escritura es la CPU en los controladores de almacenamiento ZFS y alcanza aproximadamente 2 Gb / s. (¡Sí, sí! Dado que 10 GbE no eran suficientes, se compraron conmutadores separados para los servidores de prueba, que incluían ZFS Storage y los propios servidores);
2. Se crean varias instantáneas por día, que ahora se almacenan, según la base, de 2 semanas a 2 meses. Después de lo cual se eliminan todos, excepto las instantáneas creadas a las 00:00, el 1 de cada mes, que se almacenan durante más de una cuarta parte. Hubo casos en que las instantáneas almacenadas durante aproximadamente seis meses resultaron útiles;
3. Si es necesario, se puede restaurar toda la base de datos industrial a partir de la instantánea deseada. También con una velocidad del orden de 1 ... 3 Gb / s, pero la opción de crear un clon a partir de la instantánea deseada es mucho más popular, desde donde se descargan los datos de las tablas deseadas;
4. El tiempo para recrear el entorno de prueba es de aproximadamente 1 hora (con la transferencia de varios circuitos adicionales, etc.);
5. El tiempo para proporcionar a sus colegas un clon desde el que puede recopilar datos para la recuperación o simplemente algún tipo de análisis es de 15 minutos (con una combinación ideal de condiciones) a 1-2 horas (con una gran carga paralela en ZFS Storage o us J);
6. Si es necesario, puede restaurar desde la instantánea y el clon, y toda la base de datos;
7. Una limitación importante del rendimiento es la cantidad de IOPS generados por entornos de prueba o instancias de espera en cascada. Y aquí el sistema se comporta de manera absolutamente adecuada y previsible: tan pronto como se selecciona su número a 75 IOPS por HDD (contiene discos de 3.5 ”a 7200 rpm) bajo carga prolongada, el sistema comienza a ceder gradualmente. Y poco tiempo: escribir y leer Flash son notablemente más fáciles;
8. La cantidad de IOPS, la cantidad total de datos entrantes, la carga en la CPU, la cantidad de lecturas de cachés en RAM y Flash, así como varias docenas (si no cientos) de métricas se pueden ver en la interfaz de administración web;
9. Puede trabajar con objetos de almacenamiento ZFS utilizando las solicitudes REST descritas en la documentación. Con su ayuda, fue posible automatizar la eliminación de instantáneas obsoletas, ¡pero se puede hacer mucho más!