Cada desarrollador quiere su propio puesto de desarrollo. Cada probador quiere su propio banco de pruebas. Y cada especialista en preproducción quiere su propio stand, para finalmente verificar todo y ensayar el lanzamiento en la producción. Cuando todos estos Deseos convergen en el procesamiento, uno de los sistemas más grandes y activos del banco, los costos de infraestructura hacen que te rasques la cabeza y busques "opciones". Te contaremos lo que encontramos en esta publicación.
El volumen de procesamiento de bases de datos en nuestra empresa es de aproximadamente 6 TB. En una copia de las bases de datos, los desarrolladores interfieren entre sí, por lo que la cantidad real de espacio ocupado por las bases crece rápida y proporcionalmente. Aunque cuán rápido ... demasiado rápido para el servicio de acompañantes y no lo suficientemente rápido para aquellos que necesitan copias de las bases de datos. Y aquí está el por qué.
Para las pruebas, es necesario que el banco de pruebas sea totalmente compatible con la versión actual de producción (lo mismo se aplica al banco de preproducción). La copia de seguridad principal del sistema se copia durante todo el día y luego se implementa en el soporte. Durante estas operaciones prolongadas, los stands no están disponibles, por lo que la copia se transfiere a los fines de semana y feriados cuando nadie trabaja con los stands. Tenemos un retraso de 1 a 5 días. Para llegar a un acuerdo preliminar sobre el proceso de copia en sí, también lleva tiempo: tenemos varios bancos de pruebas, generalmente de tres a seis. Agregamos 2-3 días para coordinar el tiempo de inactividad del soporte. Antes de obtener la aprobación del administrador, la aplicación todavía está en la cola. En total, tenemos un retraso muy grande.
Lo que ayudó a Delphix
¿Qué puede acelerar el proceso y ahorrar espacio? Virtualización de bases de datos. Consideramos diferentes opciones: Oracle SnapClone, NetApp + Oracle Cloud, solo instantáneas en matrices. Todo requiere una configuración compleja. Las soluciones de Oracle, además, solo funcionan con bases de datos Oracle.
Luego miré a Delphix. Es fácil de implementar, admite diferentes bases de datos: Oracle, SQL Server, DB2, Sybase ASE. Se proporciona una interfaz para todas las operaciones. A través de él, los desarrolladores y evaluadores pueden administrar sus copias de forma independiente: actualizar, guardar / restaurar el estado, detener / iniciar, etc. También hay una API y CLI para la integración con sistemas CI / CD o sus procesos.
El despliegue de Delphix en sí no lleva mucho tiempo, varias horas. La fuente se puede conectar mucho más tiempo, aquí el tiempo es proporcional al tamaño. En nuestro caso, la fuente era una copia de ventas de la base de datos, y su conexión tardó casi un día. La preparación de la fuente y los servidores para los clones de la base de datos no requiere mano de obra especial. En el servidor de destino, debe instalar el ORACLE_HOME apropiado y también crear un usuario especial para conectarse. Para las copias de prueba virtuales, utilizamos los mismos servidores que anteriormente tenían copias físicas.
Delphix le permite crear bancos de pruebas en tiempo casi real, sin ninguna coordinación, porque los bancos están completamente aislados unos de otros. Solo se dedica un tiempo a actualizar la base de datos al estado actual: de 20 minutos a varias horas, no se trata de ningún día.
Intentamos realizar pruebas de estrés en condiciones lo más cercanas posible al producto. Si la picadura en discos físicos, entonces la carga también se mantiene. En este caso, ayuda el botón Delphix V2P, que le permite crear una base de datos "honesta" a partir de una virtual.
En cuanto al ahorro de espacio en disco, las lecturas de nuestro tablero de Delphix, por supuesto, son engañosas: una reducción de volumen de 73 veces es demasiado fabulosa. En nuestro procesamiento, una copia de la venta con instantáneas diarias y registros de transacciones archivados durante 2 semanas (200 GB por día) ocupa 4.5 TB de espacio en disco. Otros 1,5 TB: nueve clones de tamaños de 50 a 500 GB, cada uno de los cuales también almacena un historial de instantáneas diarias. En total, se obtienen 6 TB.
Agregamos otro 15% de espacio libre (900 GB) para que Delphix pueda funcionar normalmente. Por lo tanto, gastando solo alrededor de 7 TB, podemos obtener una copia de prueba con datos relevantes en cualquier momento en las últimas dos semanas.
Anteriormente, para almacenar nueve copias físicas de la base de datos en 6 TB, necesitábamos 54 TB (o ~ 20 TB teniendo en cuenta la compresión de 2-3 veces en el almacenamiento). Y, a diferencia del nuevo sistema, aquí los desarrolladores no pudieron administrar estas copias y restaurar estados anteriores: cuando se destruyeron los datos, solo fue posible recargar desde una copia de la venta.
Delphix también le permite crear rápidamente diferentes ramas del mismo contenedor para diferentes proyectos, y todo esto en un tiempo mínimo. Los desarrolladores no temen corromper los datos, pueden retroceder y restaurar su estado anterior. Esto le da un impulso al rendimiento.
Pero hay matices ...
Las impresiones de Delphix son en su mayoría positivas, aunque no todo es perfecto. El mayor problema es usar discos. Cada bloque de datos se almacena solo una vez para todas las copias virtuales, y hasta que todas las copias virtuales dejen de usar el bloque, no se puede eliminar. Aquí pueden surgir problemas de organización: no todos los usuarios están preparados para soportar el corto ciclo de vida de sus stands. Si el banco de pruebas vive en una copia antigua, la venderé. Resolvemos este problema ampliamente, expandiendo los discos, lo que se puede hacer sin interrumpir el servicio. Nos aseguramos de que siempre se ahorre el 15% del espacio libre. Si es más pequeño, el sistema simplemente dejará de realizar operaciones con copias virtuales. Aunque las bases mismas permanecerán disponibles.
Para sistemas con E / S de disco intensivo, es probable que el ancho de banda de la red sea un factor limitante. Dependiendo del perfil de carga específico, el sistema puede comenzar a funcionar mejor con la virtualización. Dependiendo de la carga, la latencia de lectura secuencial del archivo db promedio es de 5-10 ms, lo cual es bastante bueno incluso para sistemas industriales.
Las unidades "clásicas" de Delphix están conectadas de cualquier manera que admita ESX, y el proveedor tiene una lista de recomendaciones sobre cómo hacer esto con el máximo rendimiento. Usamos SAN El sistema en sí presenta los discos en los que se encuentran los archivos de la base de datos virtual, solo a través del protocolo NFS. Por esta razón, debe tener cuidado con el ancho de banda del canal y su congestión. En nuestro caso, tiene sentido colocar solo archivos de datos para Delphix en matrices de discos para que ninguna actividad en el banco afecte la velocidad de E / S para bases de datos virtuales.
Ahora estamos trabajando en Delphix 5.1.9, pero estamos viendo la versión 5.2: en ella, la interfaz de usuario ha dejado el flash y, según el proveedor, se ha vuelto mucho más conveniente. Delphix impresionó a nuestros colegas, y después del procesamiento, estamos considerando transferir el perfil, CRM y banca por Internet a este sistema de desarrolladores.