Se debe tener cierta precaución con el thin provisioning de un entorno de aplicaciones porque las tasas de cambios de los datos pueden aumentar de forma inesperada. Por ejemplo, el consumo de espacio debido a las instantáneas puede aumentar rápidamente si se reindexan las tablas de la base de datos o si se aplican parches a gran escala a los huéspedes de VMware. Una copia de seguridad fuera de lugar puede escribir una gran cantidad de datos en muy poco tiempo. Por último, puede ser difícil recuperar algunas aplicaciones si un sistema de archivos se queda sin espacio libre inesperadamente.

Afortunadamente, estos riesgos se pueden abordar con una cuidadosa configuración de volume-autogrow y.. snapshot-autodelete normativas. Como sus nombres implican, estas opciones permiten al usuario crear políticas que desactiven automáticamente el espacio consumido por las copias Snapshot o aumentar un volumen para alojar datos adicionales. Hay muchas opciones disponibles y las necesidades varían según el cliente.

Consulte "documentación de gestión de almacenamiento lógico" para obtener un análisis completo de estas funciones.

La reserva fraccionaria es el comportamiento de una LUN en un volumen con respecto a la eficiencia del espacio. Cuando la opción fractional-reserve se establece en 100 %, todos los datos del volumen pueden experimentar una rotación del 100 % con cualquier patrón de datos sin agotar el espacio en el volumen.

Por ejemplo, piense en una base de datos en un único LUN de 250GB GB en un volumen de 1TB GB. La creación de una instantánea provocaría de inmediato la reserva de 250GB GB de espacio adicional en el volumen para garantizar que el volumen no se quede sin espacio por ningún motivo. El uso de reservas fraccionarias suele ser un desperdicio debido a que es extremadamente poco probable que cada byte del volumen de base de datos deba sobrescribirse. No hay razón para reservar espacio para un evento que nunca ocurre. Sin embargo, si un cliente no puede supervisar el consumo de espacio en un sistema de almacenamiento y debe tener la seguridad de que nunca se agota el espacio, se necesitarían reservas fraccionarias del 100% para utilizar copias Snapshot.

La compresión y la deduplicación son ambas formas de thin provisioning. Por ejemplo, una huella de datos de 50TB MB puede comprimirse hasta 30TB MB, lo que supone un ahorro de 20TB MB. Para que la compresión proporcione beneficios, algunos de esos 20TB MB deben utilizarse para otros datos o el sistema de almacenamiento debe adquirirse con menos de 50TB TB. El resultado es almacenar más datos de los que están disponibles técnicamente en el sistema de almacenamiento. Desde el punto de vista de los datos, hay 50TB GB de datos, a pesar de que ocupa solo 30TB GB en las unidades.

Siempre existe la posibilidad de que cambie la capacidad de compresión de un conjunto de datos, lo que provocaría un aumento del consumo de espacio real. Este aumento del consumo significa que la compresión debe gestionarse como sucede con otras formas de thin provisioning en términos de supervisión y uso volume-autogrow y.. snapshot-autodelete.

La compresión y la deduplicación se tratan de forma más detallada en el enlace de sección:efficiency.html

La eficiencia del thin provisioning de las LUN activas en un entorno de sistema de archivos se puede perder con el tiempo a medida que se eliminan los datos. A menos que los datos eliminados se sobrescriban con ceros (consulte también "ASMRU" O bien, el espacio se libera con la recuperación de espacio TRIM/UNMAP, los datos «borrados» ocupan cada vez más espacio en blanco sin asignar en el sistema de archivos. Además, el thin provisioning de LUN activos es de uso limitado en muchos entornos de bases de datos, ya que los archivos de datos se inicializan en su tamaño completo en el momento de la creación.

Una planificación cuidadosa de la configuración de LVM puede mejorar la eficiencia y minimizar la necesidad de aprovisionar el almacenamiento y redimensionar las LUN. Cuando se utiliza un LVM como Veritas VxVM u Oracle ASM, los LUN subyacentes se dividen en extensiones que solo se utilizan cuando es necesario. Por ejemplo, si un conjunto de datos empieza con un tamaño de 2TB GB, pero podría crecer hasta 10TB TB con el tiempo, este conjunto de datos podría colocarse en 10TB LUN con thin provisioning organizados en un grupo de discos de LVM. Ocuparía solo 2TB GB de espacio en el momento de la creación y solo reclamaría espacio adicional a medida que se asignan extensiones para acomodar el crecimiento de los datos. Este proceso es seguro siempre y cuando se supervise el espacio.