Mostrando entradas con la etiqueta Virtualizacion. Mostrar todas las entradas
Mostrando entradas con la etiqueta Virtualizacion. Mostrar todas las entradas

jueves, 30 de enero de 2014

Software-Defined Storage. Capa de almacenamiento en entornos virtuales



Uno de los temas tratados en el último VMWORLD fue la estrategia a seguir por parte de VMWARE con respecto a la capa de almacenamiento, ya en un post anterior tratamos las funcionalidades de VSA (Virtual Storage Appliance) de Vmware, que ofrecía una alternativa a un almacenamiento externo y compartido a través de ARRAYS de discos locales en cada uno de los Hosts ESX que eran gestionados en una capa virtual proporcionada por la arquitectura de VMWARE, esta solución implicaba prescindir de una arquitectura de almacenamiento externo, aunque está claro que esto depende del diseño y de las funcionalidades y aplicaciones que queremos implementar dentro de nuestra infraestructura virtual.

            Se habló del concepto de “Software-Defined Storage (SDS)”, que  es un modelo de almacenamiento que nos permitirá, dentro de nuestra infraestructura virtual, tener la capacidad de gestionar “pools” de recursos de almacenamiento y poder realizar gestión y flexibilidad de movimiento de datos sobre las cabinas en donde se almacena la información, esto ha sido posible con la integración de VMware con las cabinas de almacenamiento a través de la funcionalidad VAAI (vStorage API for ArrayIntegration), que permite tener un mayor control sobre el almacenamiento teniendo la capacidad de asignar recursos cuando y donde se necesite, a través de políticas dentro de nuestra plataforma de virtualización.


           
            Sin duda todos estos cambios y nuevas funcionalidades en las arquitecturas de virtualización correspondientes a almacenamiento,  nos llevará a facilitar la transición hacía entornos de Cloud, donde los conceptos de movilidad e integración de datos son fundamentales para ofrecer un servicio más óptimo en nuestra infraestructura de datos.

 Hasta la próxima.

martes, 31 de diciembre de 2013

El futuro de DataOntap pasa por Cluster-Mode




.. En post anteriores comentamos de la importancia que iban a tener en las infraestructuras tecnológicas, conceptos como entornos virtualizados, almacenamiento unificado, soluciones de Cluster Heterogéneas y sobre todo la evolución que iba a experimentar el almacenamiento dentro de cualquier plataforma, con la finalidad de garantizar alta disponibilidad, escalabilidad y por supuesto alto rendimiento.
En este sentido NetApp propone una evolución de sus sistemas DataOntap que denomina DataOntap Cluster-Mode.

En este artículo explicaremos algunas características y funcionalidades de esta versión de DataOntap que a medida que pase el tiempo veremos en más implementaciones de arquitecturas basadas en NetApp.

jueves, 21 de noviembre de 2013

STORAGECONSEJOS: Procesos de RESTORE a través de VSC (Virtual Storage Console) de NetApp en VMWARE



Quiero compartir este “storage consejo” a raíz de una incidencia que tuve al momento de realizar un RESTORE a partir de un Backup realizado en VMWARE mediante el VSC. El problema se produjo cuando se realizó un RESTORE de un DATASTORE y la CPU de la controladora aumentó considerablemente lo que ocasionó una penalización en el rendimiento de la cabina de NetApp.
La explicación es la siguiente. El VSC realiza el proceso de Backup tanto de máquinas virtuales como de Datastores, para este proceso el procedimiento es el mismo, es decir realiza un Snapshot a nivel de volumen , la diferencia radica en el procedimiento para hacer el RESTORE, de hecho se recomienda hacer un RESTORE a nivel de Datastore sólo en caso de Disaster Recovery, y es lógico ya que el proceso en sí, lo que hace es utilizar la funcionalidad de Snaprestore ( por eso es pre-requisito tenerlo licenciado) para restaurar a nivel de Datastore ya que hace un clone/Split del Snapshot restaurado para luego realizar un VMotion y reemplazar el Datastore antiguo, el mismo proceso lo realiza el SFR (single FileRestore), en cambio si se hace a nivel de máquina virtual no utiliza el SnapRestore sino el Clonado de LUN (Lun clone) que no ocupa espacio en el volumen y simplemente a través de VMotion copia la máquina virtual restaurada en el Datastore reemplazando la antigua.

En resumen los procesos en “background” que se generan en las controladoras de NetApp son los siguientes:

Restore de Datastore.

snap restore -t file -s nightly.0 /vol/vol_name/vmfs_lun_name

Restore de Máquinas Virtuales

lun clone create /vol/clone_vol_name -o noreserve -b /vol/vol_name nightly.0

En conclusión, si tenemos nuestras controladoras  a un nivel de CPU por encima del 50% se debe tener cuidado al programar o ejecutar un RESTORE de un Datastore por VSC ya que la ejecución de un clone/Split puede hacer que nuestra infraestructura de almacenamiento se vea afectada considerablemente.

Bueno amigos, espero que este storage consejo les haya sido de utilidad.

jueves, 10 de enero de 2013

Objetos y componentes de una Infraestructura de Virtualización basado en VMWARE



En VMWARE denominamos inventario a la colección de objetos que son agrupados en una infraestructura Virtual con elementos para configurar permisos, funcionalidades, tareas, eventos y alarmas. Estos elementos se pueden agrupar para facilitar la administración de la plataforma.

A continuación haremos una descripción de estos objetos.

DATACENTERS

Es una agregación de los diferentes tipos de objetos que se utilizarán en la plataforma virtual, se dividen en 4 tipos de objetos.

·       Máquinas Virtuales y plantillas.

·       Hosts y Clusters.

·       Networking (Redes).

·       Datastores (Almacenamiento).

Los nombres de estos objetos no se pueden repetir en la plataforma virtual, sin embargo se puede tener objetos con el mismo nombre si estos se encuentran en DataCenters diferentes.

CLUSTERS

Es una colección de Hosts ESX´s físicos y asociación de máquinas virtuales para aplicar las diferentes funcionalidades de nuestra arquitectura de virtualización como una unidad, cuando se añade un host a un cluster este comparte todos los recursos disponibles en el cluster.

HOSTS

Son equipos físicos donde se instala el Hypervisor de VMWARE Vsphere, todas las máquinas virtuales de la plataforma se ejecutan en los hosts, mediante el Vsphere Client se pueden administrar los Hosts de manera independiente o conectándose al Vcenter donde podremos gestionar los DataCenters o Clusters de la plataforma.

DATASTORES

Es una representación virtual de almacenamiento tanto local o compartido en una cabina de almacenamiento externa. Estos datastores accederán al almacenamiento a través de los diferentes protocolos de acceso NAS o SAN dependiendo de la tecnología de almacenamiento utilizada.

FOLDERS

Los “Folders” permiten agrupar objetos del mismo tipo para facilitar la gestión, como por ejemplo para establecer permisos o alertas a un grupo de objetos determinados.

NETWORKS

Conjunto de tarjetas de Red (NICS) instaladas en los Hosts físicos  que son agrupadas para dar conectividad a la plataforma de virtualización, tanto a nivel de Host o Cluster , almacenamiento o para proveer redes a las máquinas virtuales dentro de nuestra infraestructura. Se agrupan en Switches Standard cuya configuración se aloja en cada Host o también en Switches Distribuidos que forma parte de la comunicación entre todos los hosts dentro de un Cluster y que son configurados a nivel de VCENTER, además de ofrecer una administración más centralizada de las redes y nos permite configurar funcionalidades adicionales como QoS

RESOURCES POOL  

Es una agrupación de recursos de hardware que permite una mejor distribución entre toda la plataforma de virtualización, se agrupan de acuerdo a la aplicación o servicios que ofrecen las máquinas virtuales, permitirá una mejor gestión de la plataforma utilizando la funcionalidad de DRS.

TEMPLATES (Plantillas)

Es una copia maestra de una máquina virtual que se utiliza para la creación de máquinas virtuales de características específicas, esto facilitará el despliegue de nuevas máquinas virtuales.

COMPONENTES DE VCENTER SERVER

VMOTION

Característica que permite mover máquinas virtuales de un Host a otro miembro de un Cluster sin que el servicio se interrumpa, la característica de VMOTION es coordinada por el Vcenter.

STORAGE VMOTION

Funcionalidad que permite mover los discos y archivos de configuración de una máquina virtual entre almacenamientos compartidos sin interrupción de servicio.

VMWARE HA

Permite alta disponibilidad en un cluster, a través de mecanismos de Heartbeat, si un host cae todas las máquinas virtuales de este host son movidas a otros hosts miembros del Cluster, cuando se produce este proceso las máquinas virtuales son reiniciadas.

VMWARE DRS

Es una característica que ayuda a mejorar la asignación de los recursos de una plataforma de virtualización ofreciendo balanceo de carga entre hosts. De acuerdo a la configuración de DRS Vcenter nos ofrece una serie de recomendaciones de encendido de acuerdo a la distribución de los recursos configurados.

VMWARE Fault Tolerance (FT)

Proporciona una disponibilidad continua de las máquinas virtuales a través de la creación y mantenimiento de una máquina virtual secundaria con características idénticas a la primaria, cuando la máquina primaria deja de dar servicio, automáticamente la secundaria entra en funcionamiento garantizando así la no pérdida de servicio de la máquina virtual y las aplicaciones que se ejecutan.

Bueno amigos espero que este post les haya sido de utilidad.

Hasta pronto.

miércoles, 19 de diciembre de 2012

STORAGECONSEJOS. JUMBO FRAMES - El tamaño si importa



…. No sean mal pensados por el título del post J , en este artículo describiremos el concepto de JUMBO FRAMES, que no es más que la posibilidad de permitir a nuestros elementos de red ya sea tarjetas NICs , Switches o interfaces virtuales a enviar un mayor tamaño de paquetes Ethernet por encima de los 1500 bytes convencionales, alcanzado si estos elementos lo soportan hasta los 9000 bytes, tanto a nivel de redes locales como de redes de largo alcance WAN, sin embargo hay que tener cuidado al habilitar esta funcionalidad por que algunos proveedores de Internet no soportan JUMBO FRAMES y podemos encontrarnos también que algún elemento de red dentro de nuestra infraestructura tampoco lo soporte, sobre todo los switches antiguos.

      La activación de esta característica básicamente nos permitirá reducir el coste y los ciclos de CPU, mejorando el rendimiento de las conexiones por TCP notoriamente.

      En lo que se refiere a almacenamiento, sobre todo para conexiones a través de ISCSI,   siempre y cuando todos los elementos de nuestra ruta de red soporte JUMBO FRAMES, es recomendable activarlo, de esta manera se ganará en rendimiento tanto de lectura o escritura en disco provisionado por SAN, como en el caso de la conectividad con una librería de cinta por ISCSI al momento de realizar escrituras hacia una cinta en un proceso de Backup.

 ¿ Y porque se limita a 9000 bytes?

      Simplemente porque una trama Ethernet emplea un CRC (Cyclic Redundancy Checksum) de 32 bits el cual pierde su eficacia de detección de errores por encima de los 12000 bytes.

    A continuación les detallo como activar JUMBO FRAMES en diferentes tecnologías.

NETAPP

ifconfig <nombredeinterfaz o VIF> mtusize 9000

VMWARE

esxcfg-vmknic -a -i <dirección IP> -n <MASCARA> -m 9000 <NOMBRE NIC>

LINUX

ifconfig eth1 mtu 9000
ip link set eth1 mtu 9000

XEN SERVER

xe vif-param-set uuid=<vif_uuid> other-config:mtu=9000

WINDOWS

netsh int ipv4 set subint “” mtu=9000 store=persistent

 

domingo, 9 de diciembre de 2012

jueves, 6 de diciembre de 2012

VMWare Storage Appliance ¿Es realmente necesario?


..  VMWare en su última versión la 5.1 añade muchas novedades no sólo en licenciamiento (importante revisar este apartado porque no tiene desperdicio), sino también en funcionalidades y en la orientación que se le quiere dar a las arquitecturas basadas en VMWare básicamente hacía entornos de Cloud, es allí cuando se incorpora la funcionalidad de Single Sign On o de la próxima desaparición del VSphere Client para darle mayor protagonismo al VSphere Web Client, pero también las novedades radican en aspectos de almacenamiento, en este sentido se ha incluido dentro de la suite un “Appliance” llamado VMWare Storage Appliance o VSA, que se desplega a través del VCenter, y que nos ofrece la posibilidad de utilizar y compartir el almacenamiento local de cada uno de los hosts que componen un Cluster y convertirlo en un almacenamiento compartido a modo de SAN para toda la infraestructura virtual, para así aplicar funcionalidades de Storage VMotion, HA, DRS y Storage I/O Control. La idea no parece mala.

jueves, 29 de noviembre de 2012

Fin de disponibilidad de ESX 4.x



VMware anuncia la fecha de fin de disponibilidad del hipervisor VMware vSphere® ESX 4.x y de VMware Management Assistant versiones 1 y 4

El 28 de noviembre de 2012, VMware notificará a sus clientes la fecha de fin de disponibilidad del
hipervisor VMware vSphere® ESX 4.x y de VMware Management Assistant versiones 1 y 4. La fecha de fin de disponibilidad será el 15 de agosto de 2013. Esta comunicación está relacionada con el anuncio general efectuado en julio de 2011 respecto al lanzamiento de VMware vSphere 5.0.


viernes, 26 de octubre de 2012

VCENTER Físico o Virtual.


…. Cuando estamos en las tareas previas para empezar a diseñar una infraestructura virtual basado en VSphere VMWARE una duda que siempre nos asalta es si instalamos el VCenter en una máquina física o en una Virtual, tomando en cuenta lo importante que este elemento supone, la respuesta no queda del todo respondida debido a que en parte depende de cada entorno y de los puntos de fallo que podamos encontrar en hacerlo de una manera u otra, por tanto aquí describimos unos TIPS a tomar en cuenta que pueden ayudarnos en esta decisión.

La primer pregunta que nos debemos de hacer es ¿Qué pasa si nuestro VCENTER falla?

·        La alta disponibilidad HA sigue funcionando ya que solamente se requiere el VCenter para configurar esta funcionalidad

·        VMware VMotio n y Storage VMotion requieren del VCENTER sin embargo si antes se ha ejecutado una tarea de estas funcionalidades no se verá afectada.

·        DRS y DPM solamente funcionan con el VCenter activo , debido a que son necesarios  los datos que están en la base de datos de VCenter .

·        Los templates también son manejados por el VCenter

·        El acceso a los históricos, estadísticas de los ESX´s de la plataforma no se podrán consultar sin el VCenter activo

·        Una de las características que gestiona el VCenter son los switches distribuidos aunque una parte de la configuración de los mismo se guarda en cada uno de los Hosts , las funcionalidad de los switches distribuidos dejaran de operar, por eso es probable que si nuestro VCenter tiene la red en un switch distribuido no tengamos acceso al VCenter, para entornos grandes que se disponen de NICs suficientes se configura la parte de red del VCENTER en switches Standard con lo cual se tendría una configuración híbrida.

Uno de los puntos importantes en nuestro diseño es por tanto determinar como protegemos nuestros VCenter, es aquí donde toma vital importancia el tema de virtualizarlo, ya que gozaríamos de todos los mecanismos de alta disponibilidad y recuperación de toda la plataforma de virtualización al ser una máquina más dentro del entorno, otra alternativa es almacenar la base de datos del VCenter en por ejemplo nuestro entorno de base de datos de producción sea SQL u ORACLE, por otroa lado también VMWare nos ofrece el producto VMWare Heartbeat, o también considerar activar el FT (fault Tolerance) en la máquina de VCenter sin embargo habría que considerar pro y contras de activar la funcionalidad de Fault Tolerance.

Ventajas y desventajas de VCenter Fisico

·        El VCEnter al estar fuera de la infraestructura virtual no tendría que competir con los recursos de las otras máquinas que se encuentran en el entorno, generalmente se reserva a través de los Resource Pools valores determinados para garantizar la alta disponibilidad.

·        Si falla un Host (ESX) tendremos acceso inmediato al VCenter sin necesidad de esperar a que el HA del entorno de virtualización actúe.

·        Se necesita de un servidor físico para instalar el VCenter

·        Los métodos de backup son más complejos tanto del Sistema Operativo de la máquina como de la base de datos de VCenter

·        Un Servidor físico está más expuesto a fallos de hardware .

·        Las tareas de mantenimiento y actualizaciones son más costosas y en caso de fallo los procedimientos de recuperación son más costosos .

Ventajas y desventajas de VCenter Virtual

·        No requerimos de un servidor físico para instalar el VCenter

·        Al fallar el ESX donde este el VCenter a través de HA tendríamos la recuperación de la máquina rápidamente.

·        Se aprovechan los mecanismos y procedimientos de BAckup de toda la infraestructura virtual para respaldar el VCenter.

·        Si tenemos VMotion, podemos mover en “caliente” nuestro VCenter  a otro servidor en caso de que necesite más recursos de hardware.

·        El VCenter estaría compitiendo con las otras máquinas virtuales por los recursos del Host (ESX) o Cluster.

En conclusión si tenemos todos las funcionalidades a nivel de alta disponibilidad, balanceo y mecanismos de respaldo y recuperación además de un almacenamiento remoto lo más recomendable es hacerlo virtual, si no tenemos estas funcionalidades y disponemos del hardware necesario y de un hardware limitado a nivel de recursos en los ESX´s lo mejor es instalarlo en una máquina física.

Espero que este artículo les haya sido de utilidad.

Hasta Pronto……