Que tal Gente, continuando con los temas de VCAP nos toca hablar de las mejores practicas sobre almacenamiento y VMware.
VMware al igual que cualquier ambiente físico de servidores tiene mejores practicas para el almacenamiento, de entrada VMware nos recomienda siempre utilizar VMFS por las cualidades que este nos ofrece ya que es un sistema de archivos creado específicamente con la idea de ser clusterizable y para trabajar con ambientes VMware.
Voy a tratar de hacer este post lo más breve posible, así que vamos directo a las mejores prácticas:
- Evitar el uso de Extents para el crecimiento de nuestros Datastores: siempre que podamos lo mejor será evitar el uso de extents, debido a que por su principio básico lo que se esta logrando es tener un único sistema de archivos (VMFS) que esta constituido por varios luns, el problema principal que veo aquí es el hecho de si se pierde un lun de dicho sistema de archivos el Datastore completo se viene abajo. Una mejor opción sería el uso de Volume grow.
- Definir "Tiers" o prioridades de LUNS: Es básico definir el performance que cada aplicación requiere, y tener en base al performance requerido distintos grupos de LUNS con características específicas de performance, capacidad, etc.
- NUNCA crear más de un VMFS por lun: Esto es algo esencial, debido a que cada vez que se requiere hacer una actualización al metadata del lun VMware hace un "lock" o reservación scsi de el LUN completo, no solo de una partición.
- Definir el tamaño de bloque de nuestro VMFS: Aquí antes que nada les comento que no existe ninguna ganancia en cuanto a performance se refiere si nosotros seleccionamos algún tipo de blocksize.Este punto tiene que ver más con un correcto dimensionamiento y planeación de nuestra arquitectura, ya que el blocksize de nuestro vmfs dictará el tamaño máximo de un archivo en dicho Datastore:
- Alinear nuestros VMDKs: En este punto vSphere ya crea los datastores alineados con el almacenamiento adyacente, pero el problema se sigue presentando a nivel de nuestras máquinas virtuales, por eso es necesario siempre alinear nuestros templates para una vez que tengamos que hacer entrega de una maquina virtual tenga los discos alineados con el almacenamiento. Aquí les dejo unos links para que sepan cómo realizarlo:
- Limitar el número de VMs por Datastore: Aquí no existe un límite definido por VMware en cuanto a las máquinas virtuales que debemos tener por datastore, pero una buena práctica es la de limitar el número de VMs a 16 por datastore en el caso de servidores, y en el caso de vms view no más de 30 – 40 vms por datastore. Con esto tenemos un menor número de reservaciones scsi.
- ¿RDM o VMDK?: Personalmente solo utilizo RDMs en el momento que una máquina virtual requiere de un disco duro mayor a 400 – 500 GB por cuestiones de movilidad, razones específicas para utilizar rdm son las siguientes: Cluster Microsoft y Acceso directo a SAN para hacer uso de utilidades del almacenamiento.
- Crear un Datastore específico para archivos swap:Útil para ambientes donde se este replicando ciertos volúmenes, este espacio en disco puede ser dado en un arreglo de menor performance , está claro que este datastore tendrá que ser presentado de igual manera a todos los host del cluster para poder tener funcionalidades como VMotion.
- Crear un Datastore específico para imágenes ISO: Con esto logramos una estandarización de nuestras imágenes, una mejor administración y claro una mejor velocidad en el momento de instalaciones.
- Crear un Datastore específico para Templates: una mejor administración de nuestra libreria de VMs.
- Multipathing: tanto en ISCSI como en FC es necesario tener varios canales de comunicación con nuestro almacenamiento, por cuestiones de disponibilidad del mismo y en caso de el uso de Round Robin o Multipathing de terceros la capacidad de distribuir la carga entre distintos paths hacia nuestro almacenamiento.
Existen muchas otras recomendaciones / best practices especificas para cada proveedor de almacenamiento, aquí les plasme las best practices mas comunes y sin tomar en cuenta el proveedor de almacenamiento.
No hay comentarios:
Publicar un comentario