jueves, 20 de julio de 2017

Consideraciones (preventa) de rendimiento y desempeño


Siguiendo esta breve serie, hoy quiero revisar algunas de las consideraciones de rendimiento y desempeño a tener en cuenta al momento de diseñar el almacenamiento.

Si desea revisar las entradas anteriores acá estan los enlaces:

Algunas consideraciones (preventa) para almacenamiento
Consideraciones de Conectividad y de Capacidad





Consideraciones de Rendimiento y Desempeño

En cuanto al rendimiento, desde el punto de vista de capacidad de un disco individual o sistema de almacenamiento, hay que tener en cuenta principalmente 3 variables: IOPS (Input Output por segundo), latencia y throughput. Revisemos estos conceptos:


IOPS (Input Output por segundo)

Input Output por segundo (IOPS) es el término que se da a la cantidad de operaciones de lectura y/o escritura que pueden ser efectuadas en un segundo de tiempo. Es un término muy usado para mostrar las fortalezas de un sistema de almacenamiento, pero es importante tener en cuenta que es solo una característica parcial para demostrar desempeño, y no se debe basar uns decisión sólo en IOps.

En un sistema de almacenamiento, los IOPS que se obtienen son la suma de varios factores, como por ejemplo la cantidad y tipo de discos mecánicos o unidades SSD, la cantidad y tipos de arreglos creados, memroria caché de las controladoras del almacenamiento, capa de caché basada en SSD, software de optimización de acceso a las capas (tiers), la relación de lectura/escritura, así como el tamaño de cada requerimiento de I/O.

Como vemos, no es tan sencillo hablar de IOps. Por ejemplo, si analizamos el tamaño del requerimiento Input/Output (I/O size) notaremos que éste varía dependiendo del sistema operativo y las aplicaciones o servicios que hagan requerimientos de I/O al almacenamiento. El tamaño del I/O size suele medirse en KB (4 KB, 8 KB, 32 KB, etcétera).

La recomendación acá, como siempre, es entender y analizar todas (o la mayor cantidad) de variables, con el fin de obtener un diseño de almacenamiento aterrizado y acorde al requerimiento.


Latencia

En sistemas de almacenamiento, el término latencia se asocia al tiempo en que una operación de lectura/escritura demora en ser realizada (completada) desde que solicita hasta que se confirma. La latencia se la mide en milisegundos (ms), generalmente es el resultado de la suma de varios retardos o latencias acumuladas. Como es obvio, a menor latencia tendremos mejor desempeño de un sistema de almacenamiento.




Los discos mecánicos (HDD) son uno de los componentes que generan mayor latencia en un sistema de almacenamiento (por la latencia rotacional, tiempo de búsqueda, etcétera). Por esta razón se buscan medidas para mitigar el impacto de la "lentitud" de los HDD, como caché SDD, discos híbridos, mayor cantidad de discos, arreglos de discos, entre otros.

Acá la recomendación nuevamente es entender el requerimiento, porque tener un sistema con poca o nula latencia se podría conseguir con unidades SSD, pero sin duda eso tendría un impacto en el presupuesto, y si no existe la clara necesidad de tener esos niveles de desempeño, puede hacer un proyecto inviable económicamente.


Throughput

El throughput es la cantidad de información que un disco o sistema de almacenamiento es capaz de brindar en un periodo de tiempo. Suele ser expresado en Megabytes por segundo (MB/s) y es una de las variables que en ocasiones no es tomada en cuenta, pero es muy importante para conocer la capacidad de un disco o sistema de almacenamiento.





De hecho, hay una relación directa entre el throughput y IOPS que un sistema de almacenamiento puede generar, dependiendo del tamaño de I/O:


Throughput (MB/s) = Tamaño I/O (promedio) x IOPS


De acá podemos deducir que si el tamaño de I/O es pequeño, podemos obtener un gran número de IOPS y cierto nivel de throughput.

Así mismo con un mayor tamaño de I/O, vamos a obtener menos IOPS, pero el monto de throughput será el mismo.

Por ejemplo un sistema de almacenamiento que ofrezca 100,000 IOPS en bloques de 4K genera 400 MB/s; ese mismo sistema con un bloque de 32K generará 12,500 IOPS, con los mismos 400 MB/s (estos valores asumen lecturas secuenciales).

Como vemos, es muy importante considerar todas las variables, y esto se consigue conociendo realmante el requerimiento del cliente, y no solo fijarnos en la capacidad requerida.

Espero sea de utilidad. Hasta la próxima.



Algunas referencias:

Es común confundir el Throughput con Bandwidth. Acá hay un breve video que explica en forma simple esta diferencia: https://www.youtube.com/watch?v=VWxGtl5J7WM


miércoles, 5 de julio de 2017

Consideraciones de Conectividad y de Capacidad

Hace unos días escribí unas breves notas con consideraciones que, desde el punto de vista de preventa, sugiero tener en cuenta al momento de dimensionar una solución de almacenamiento.

Ahora voy a detallar mejor las consideraciones a tener en cuenta respecto de la conectividad y la capacidad.

Consideraciones de conectividad

La conectividad en ocasiones es una variable que no se puede elegir, porque el cliente ya posee infraestructura para este propósito. Sin embargo, hay que tener en cuenta las diferencias para hacer las sugerencias técnicas para el correcto dimensionamiento de la solución. En general, los entornos que se analizan están basado en protocolo Fibra Canal y protocolo Ethernet.

Fibra Canal (FC)


Si la conectividad es por Fibra Canal, es importante validar la compatibilidad de velocidad, en especial cuando ya existe alguna solución de almacenamiento. Los sistemas vigentes soportan velocidades de hasta 16 Gbps, con capacidad de auto negociación a 8 Gbps y hasta 4 Gbps, pero eso dependerá también de la infraestructura de los switches SAN disponibles. Acá es importante tener en cuenta que es probable requerir actualizaciones de firmware, y es mandatorio que exista soporte con el fabricante de los mismos para este propósito.







En el caso de los cables usados, se recomienda el uso de cables OM3 y OM4: la principal diferencia entre estos cables es la distancia que se soportan dependiendo de la velocidad a usar. Por ejemplo, en una red SAN a 16Gbps, usar cables OM3 permiten hasta 100 metros, en cambio con cables OM4 se consiguen hasta 125 metros.

Ethernet



En conectividad Ethernet, las velocidades usadas son 1GbE y 10GbE, con auto-negociación. Es importante definir la infraestructura de red existente, porque aunque al estar basado en IP se puede usar los mismo componentes de red LAN, se debe buscar separar las redes (LAN y SAN-IP) de forma física o lógica (VLANs) y evitar problemas de rendimiento (como sobre-suscripción) o de seguridad.

Para Ethernet existe conectividad en cobre o fibra, de modo que es necesaro validar que los switches tengan disponibilidad de puertos. Es recomendable usar fibra si la velocidad es 10GbE, especialmente por mayores distancias soportadas, y deben seguirse las recomendaciones de los fabricantes en las configuraciones de los switches, como por ejemplo el uso de Jumbo Frames (MTU 9000) o control de flujo (Flow Control).


Consideraciones de Capacidad


La capacidad requerida es uno de los factores más "sencillos" de determinar cuando se dimensiona una solución de almacenamiento, y esto hace que sea una de las variables en que más se pueden cometer errores.

Por eso es importante tener en cuenta ciertas variables, como por ejemplo:

Capacidad de los discos y unidades SSD


El sistema binario normalmente es usado para determinar capacidad y velocidad de los diferentes componentes de TI, pero la nomenclatura usada describe el sistema decimal. Es así que un Megabyte (MB) se considera 2^20 bytes, pero realmente un Megabyte es igual a 10^6 bytes. Como aclaración 2^20 bytes es igual a 1 MiB (1 Mebibyte).






Esta diferencia puede generar confusiones y problemas con el dimensionamiento, porque mientras los fabricantes de discos usan el sistema decimal, algunos sistemas operativos usan el sistema binario, y genera diferencias en su capacidad real. En este blog hay una entrada que detalla este tema con mayor profundidad.


La sugerencia acá es utilizar las herramientas de los mismo fabricantes para conocer la capacidad real de un sistema de almacenaiento (por ejemplo Dell EMC ofrece el Unity Sizer); si eso no existe, es mejor considerar aproximaciones conservadoras.

Arreglos de discos


Los arreglos de discos (conocidos como RAID) permiten protegerse contra fallas individuales de discos y/o además obtener mejoras de rendimiento. Existen diferentes tipos o niveles de arreglos, cada uno con ventajas y desventajas, así como implicaciones de capacidad usable.


Discos de reemplazo (Hot Spare)


Para aumentar la disponibilidad en la soluciones de almacenamiento es recomendable el uso de discos de reemplazo (Hot Spare ó HS). Los discos HS tiene la función de reemplazar cualquier disco averiado dentro de un arreglo de discos, y por esta razón no se debe considerar dentro de la capacidad total del almacenamiento.

Caché de almacenamiento


Existen soluciones que soportan capas de caché de almacenamiento basadas en unidades de estado sólido (SSD). En general, esta capa de SSD no se considera en la capacidad total del almacenamiento, sino que se utiliza para obtener altos rendimientos en especial para las operaciones de lectura.

Espacio para snapshot y clones


Los snapshots (imágen instantáneas) y clones en los sistemas de almacenamientos son usados para respaldos, escenarios de pruebas, replicación, etcétera. En el dimensionamiento deben considerarse el espacio que se dedicará para estos propósitos, y puede ser muy variable dependiendo de las tecnologías a usar.

Por ejemplo, la replicación de Zerto estima entre un 7% y 10% adicional de la capacidad de las máquinas virtuales para su CDP (journaling).

Provisionamiento por demanda




Una de las tecnologías más útiles y usadas en la actualidad es el aprovisionamiento por demanda o Thin Provisioning. La principal ventaja es que posibilidad de sobre-aprovisionar el espacio requerido para una máquina virtual o física, pero se debe tener cuidado con los límites reales del espacio disponible, así como el impacto en rendimiento que puede tener en la plataforma (especialmente si se hace del lado de los servidores y no del almacenamiento).

Crecimiento de la capacidad


La capacidad de almacenamiento de un cliente suele estar afectada por 2 tipos de crecimiento: el crecimiento de datos por la información generada por los sistemas actuales, y el crecimiento generada por el aumento de usuarios y/o nuevos servicios.

Esta información es normalmente proveída por el cliente, y lo que se debe buscar es cotejar esa información con los datos recabados durante el levantamiento de información, porque el cliente tiende a sobre-dimensionar el requerimiento de espacio requerido.

Personalmente suelo utilizar la herramienta DPACK (Dell Perfomance Analysis Collection Kit) porque se cero invasiva (no requiere instalación ni agentes) y permite conocer en línea el comportamiento de la infraestructura (capacidad de almacenamiento, rendimiento por IOps, uso de CPU, memoria RAM entre otros) de forma gráfica sencilla.


Espero sean de utilidad estas breves notas, quizá sea de interés también:



domingo, 2 de julio de 2017

Algunas consideraciones (preventa) para almacenamiento


El almacenamiento es uno de los componentes claves dentro de la arquitectura de TI, más aún que en la actualidad tecnologías ya maduras como la virtualización de infraestructura, aplicaciones de audio/vídeo, volúmenes de datos no estructurados (Big Data), vídeo vigilancia y otras, son generadores de gran cantidad de nuevos datos de forma constante.



Es por esto que al evaluar  una solución de almaceamiento para TI es muy importante elegir la opción que se ajuste más a los requerimientos actuales y futuros del negocio.

Estas breves notas buscan repasar algunos de los tipos de almacenamiento más frecuentes y algunas guías para su elección y configuración, desde el punto de vista de preventa, y por ende no pretende ser una fuente en profundidad de tecnologías de almacenamiento.

Generalidades


Por su forma de acceso a los datos, podemos dividir los almacenamientos en 3 grandes grupos: acceso por bloques, acceso por sistema de archivo, y almacenamiento de objetos.

A los sistemas de almacenamiento basados en bloques se los conoce como SAN (Storage Area Network, aunque no es preciso llamarlo así) y a los basados en archivos se conoce como NAS (Network Attached Storage).

Acceso por bloques


Los datos se almacenan en unidades, que se conocen como bloques y que en su conjunto forman unidades de mayor capacidad conocidas como Unidades Lógicas (LUN) y/o almacenes de datos (datastores).
El acceso por bloques utilizar, entre otros, uno de los siguientes protocolos: SAS, FC, iSCSI, FCoE e Infiniband.

SAS (Serial Attached SCSI)


SAS y SATA son los protocolos que de los discos usan para comunicarse con los sistemas de almacenamiento. En general para entornos de almacenamiento corporativo se usas SAS 3ra Gen (SAS-3 @ 12Gbps).



Pero el protocolo SAS-3 se usa también para la comunicación entre los sistemas de almacenamiento y los servidores. Estos sistemas se denominan DAS (Direct Attached Storage), y anteriormente implicaban la no compartición, pero hoy existen sistemas SAS que permiten compartir su almacenamiento entre varios servidores, aunque normalmente con un número muy limitado de conexiones.


Fibre Channel (FC)


El protocolo de fibra canal (FC) ha sido por mucho tiempo casi un estándar para la implementación de redes de almacenamiento (SAN) de alto desempeño, principalmente a su excelente velocidad de comunicación, tecnología non-blocking, muy baja latencia y soporta largas distancias (comparado con SCSI). Actualmente tenemos, comercialmente disponible, FC a 16 Gbps, y generalmente hay compatibilidad con 2 generaciones previas al menos (4 Gbps, 8 Gbps), que se comunican con los servidores (hosts) por medio de tarjetas HBA.


Internet SCSI (iSCSI)


iSCSI es un protocolo de comunicaciones para almacenamiento que utiliza el protocolo Ethernet (TCP) para encapsular paquetes SCSI, de modo que "cualquier" red LAN se puede utilizar para implementar una red de almacenamiento utilizando los mismos componentes (tarjetas de red (NIC), switches, cables, etc.). Al usar redes Ethernet, se obtienen algunas ventajas como la capacidad nativa de enrutamiento, distancia casi ilimitada, velocidad de 10/40 Gbps, y menores costos de implementación. Su principal desventaja puede ser la velocidad (no hay priorización), si no se usa una red dedicada para iSCSI.

Es común intentar comparar iSCSI a 10GbE con FC 8Gbps, y la realidad es que aunque la velocidad de iSCSI 10GbE es mayor a FC 8Gbps, el ancho de banda es comparable porque el protocolo FC es más eficiente que el protocolo Ethernet.

Fibre Channel over Ethernet (FCoE)


FCoE es un protocolo que canal de fibra vía redes Ethernet, pero no es IP enrutable. Para superar la falta de priorización de Ethernet, para FCoE al estándar Ethernet debe añadirse capacidades de Data Center Brinding. Al estar sobre redes Ethernet, se pueden implementar sobre redes de 10/40Gbps.

Su uso principal es en entornos convergentes, en donde se dispone de una red  de alta velocidad para uso de LAN y SAN, ahorrando componente activos (como switches) y pasivos (cableado, paneles, etcétera), en especial en configuraciones ToR (Top-of-the-Rack).


InfiniBand


InfiniBand es un protocolo maduro, con latencias muy bajas y alto ancho de banda, que se usa principalmente en soluciones que requieren conectividad de muy alta velocidad, como redes de cómputo de alto desempeño (HPC), y como red de interconexión BackEnd entre nodos en sistemas de almacenamiento, como por ejemplo sistemas Dell EMC Isilon.

Actualmente se tienen velocidades de 40 y 100 Gbps. En general son soluciones más costosas que FC y redes Ethernet, tanto en términos de costos administrativos como operativos, y además existen muy pocos proveedores de hardware para esta tecnología.

Acceso por archivos


Los datos se almacenan como archivos o ficheros en una estructura previamente definidas en un formato con estructura, denominado Sistema de Archivos (File System). Para este acceso se utilizan principalmente los protocolos NFS y SMB (CIFS).


NFS (Network File System)


NFS (Network File System, Sistema de archivos de red) es un protocolo cliente/servidor que permite compartir archivos, originalmente desarrollado por Sun Microsystems para entornos Unix usando protocolo Ethernet, y por tanto su velocidad depende de la infraestructura Ethernet sobre la que esté implementado. Hay 3 versiones actualmente NFSv2, NFSv3, NFSv4 y, aunque originalmente fue diseñado para compartir archivos, actualmente existen implementaciones que permiten su uso en entornos de bloques (como por ejemplo Nutanix DFS).


SMB (Server Message Block)


SMB es un protocolo de red tipo cliente/servidor, para compartir archivos u otro recursos en una red de equipos Windows. Originalmente desarrollador por IBM, tiene sus variantes como el CIFS (Microsoft) y Samba (Linux). Al igual que NFS, se rendimiento depende de la infraestructura de red Ethernet sobre la que está implementada. Las versiones más recientes son SMB 3.0, SMB 3.1.1, y su uso está principalmente enfocado en compartir archivos, aunque desde la versi;on SMB 3.0 Microsoft soporta ejecución de máquinas virtuales de Hyper-V desde repositorios basados en SMB.

Espero sean de utilidad estas breves notas, y pronto extenderé este blog con:
  • Consideraciones de Conectividad
  • Consideraciones de Capacidad
  • Consideraciones de Rendimiento.





domingo, 28 de agosto de 2016

Lo nuevo: Veeam Availability Suite 9.5

Hola mundo


Hace unos pocos días Veeam hizo oficial su más reciente versión de producto; lo anunciaron como Veeam's Next Big Thing, así que vamos a revisar algunas de las nuevas características y/o productos mostrados.



Veeam Agentes: Linux y Windows

Uno de las principales objeciones que se escuchaban al querer posicionar Veeam como herramienta de respaldos, es (era) la limitación de proteger solo entornos virtualizados con vSphere o Hyper-V; y es que usualmente existen entornos (cada vez menos por suerte) en donde hay servicios que por diversas razones se mantienen en servidores físicos.

Hace un tiempo Veeam tiene disponible un "agente" para entornos físicos, el ya conocido Veeam Endpoint Backup diseñado para Windows de usuario final, pero ahora ya se hizo el anuncio oficial de los agentes para entornos Windows Server y Linux.

Veeam Windows and Linux Agents


Se anuncian características tipo Enterprise, como procesamiento application-aware, calendarización flexible y opciones diversas de retención. Habrán versiones gratuita, workstation y server, cada una con diferentes niveles de funcionalidad.

Tanto el agente para Windows como para Linux ofrecen integración con los repositorios de Veeam Backup and Repication, así como con Veeam Cloud Connect para generar respaldos directos a entornos de cloud.

Veeam Agent for Microsoft Windows



Veeam Availability Orchestrator

Veeam apunta a fortalecer su posición no solo como una herramienta de respaldos, sino de disponibilidad. Su característica de replicación integrada ahora se ve fortalecida con el anuncio de un orquestador para recuperación de desastres (DR), que promete facilitar la construcción, ejecución, pruebas y documentación de los planes de DR. Se espera tener un beta del producto en unos pocos días (Septiembre 2016).


Veeam Availability Orchestrator


Veeam Availability Console

Al tener ahora entornos virtuales, físico y de cloud que administrar, Veeam ha desarrollado su Availability Console, que promete a las organizaciones una forma más sencilla de administrar la protección de los entornos de nube, oficinas remotas y usuario finales. Así mismo los proveedores de servicio podrán entregar de forma más ágil los servicios de respaldos y replicación basados en Veeam a sus clientes.

Veeam Availability Console


Direct Restore a Microsoft Azure

La posibilidad de hacer restauraciones a la nube de Microsoft Azure es una gran característica que permite optimizar recursos y reducir costos. Esta característica permite obtener respaldos de los entornos físicos (Windows, Linux) y virtuales y llevarlos a Azure, para objeto de migración y/o respaldos.

Veeam Backup para Microsoft Office 365

Es conocido que cada vez es más popular el correo en la nube de Office 365. Si bien es cierto que esa plataforma ofrece un nivel de seguridad muy alto, no reemplaza la necesidad de tener una copia local de los correos. Y qué mejor que tener una plataforma como Veeam con su granularidad para este propósito.

Uno de los anuncios de Veeam fue precisamente su herramienta de respaldos para correo de Office 365, y por lo que se vió tendrá funcionalidades similares a las ya conocidas y poderosas características que tenemos en las instancias On-Premise de Exchange Server.

Veeam Backup for Office 365

Veeam Backup for Office 365


Solo imaginen poder restaurar correos, contactos, citas, y más, sea como .pst, archivo adjunto, o inyectarlo directamente a mi buzón de Office 365, suena bien, no? Y mejor aún que se anunció una promoción de hasta 3 años de suscripción gratuita del servicios para clientes Veeam.



Chargeback y billing en Veeam ONE

El anuncio de la característica de tarifador (chargeback) que se anunció con Veeam ONE 9.5 se alinea al enfoque de poder medir, controlar y monetarizar el impacto que TI ofrece a las organizaciones. Estará disponible tanto para empresas como proveedores de servicio, y se espara ayude a ahorrar y ubicar de mejor manera los recursos.



Integración con snapshots de Nimble Storage

Siguiendo con su integración con fabricantes de almacenamiento, ahora además de HPE, NetApp y EMC, se anuncia la integración de Nimble Storage con Veeam Availability Suite 9.5.



Esto permitirá utilizar snapshots de Nimble para obtener los respaldos, utilizar los Veeam Explorers directamente desde el almacenamiento, e incluso la característica de On-Demand Sandbox.


Veeam + IBM

Como un adelanto de la versión 10, se anunció también la integración de Veeam B&R con la plataforma de almacenamiento de IBM.

Veeam + IBM

Habrá un Tech Preview en el VeeamON en Mayo del 2017, que será en New Orleans.

Integración avanzada con ReFS

Resilient File System (ReFS) es el nuevo sistema de archivos de Microsoft introducido en Windows Server 2012, con la intención de ser la evolución de NTFS.

Aunque no es un sistema de archivos masivamente usado aún, Veeam ya anuncia la integración con ReFS para obtener extraordinario desempeño.

--

Como vemos, hay temas interesantes de este fabricante, y como siempre los beneficiados son los usuarios, que podrán hacer uso de herramientas cada vez más poderosas, intuitivas y que permiten elevar los niveles de servicios que brinda IT a las organizaciones.


Espero sea de utilidad, hasta la próxima.

@robertourgiles



Más info:
https://go.veeam.com/launch-event-recorded.html
https://www.veeam.com/pdf/datasheet/veeam_availability_suite_9_5_highlights_en.pdf
https://www.veeam.com/pdf/datasheet/veeam_agents_one_pager_datasheet_en.pdf

miércoles, 13 de enero de 2016

Habilitando GUI (web) en host ESXi por medio de ESXi Embedded Host Client

Hello World

Todos quienes estamos en el mundo virtual, estuvimos trabajando mucho tiempo con el VI Client que VMware tiene para accesar a los hosts ESXi y/o vCenter Server.

Sin embargo, el client cada vez está cayendo en desuso, especialmente porque no tiene todas las características que el cliente web posee.

Es bueno saber que, en entornos de labs o demos, podemos hacer uso de una herramienta que han generado los labs de VMware; se trata del Fling llamado ESXi Embedded Host Client, que aunque no posee toda la funcionalidad del acceso web por medio del vCenter al menos permite algunas funcionalidades importantes, como:


Operaciones en las VM (encender, apagar, reiniciar, suspender, etc.)
Crear una nueva VM desde cero, o desde OVF/OVA (soporte para OVA limitado)
Configurar NTP en un host
Mostrar resúmenes, eventos, tareas y notificaciones/alertas
Proveer una consola para las VMs
Configurar redes en el host
Realizar configuraciones avanzadas en el host
Configurar servicios en el host




Dicho Fling está en versión 4 actualmente, y en la página están los pasos para la instalación, que paso a detallar:

Lo primero, es habilitar SSH en el host, lo que se puede hacer por consola (DCUI):


Consola DCUI 


Habilitando SSH por consola


Luego es necesario descargar el VIB, lo cual se puede hacer directo al host (si tienen acceso por internet) o a una máquina con acceso a internet. En mi caso, lo descargué a mi laptop:

Descarga VIB ESXUI


El archivo es esxui-signed.vib y pesa alrededor de 3MB. Una vez descargado, necesitamos copiarlo al host, para la cual usaremos FileZilla.

La aplicación FileZilla es bastante sencilla de utilizar: nos va a pedir las credenciales de acceso del host, y una vez autenticados nos muestra 2 paneles, en la izquierda los archivos locales, y sobre la derecha los del host.

Copiamos el archivo esxui-signed.vib al host (en este caso, a la carpeta tmp)

Copiar VIB por medio de Filezilla


Una vez copiado el esxui-signed.vib, procedemos a instalarlo, con el siguiente formato:



Para esto podemos utilizar Putty, en nuestro caso, el comando queda así:

ssh root@172.16.0.81 esxcli software vib install -v /tmp/esxui.vib

Completada la instalación, el acceso es vía web, en nuestro caso queda https://172.16.0.81/ui


Interfaz web de Host ESXi


Y listo, tenemos acceso vía web a un host ESXi. Como se mencionó antes, esta utilidad no se recomienda para entornos de producción.

Finalmente, por seguridad es recomendable deshabilitar el acceso SSH que habilitamos previamente, de hecho veremos que se muestra un mensaje de advertencia, y es aquí donde comenzamos a ver la funcionalidad web, ya que junto al error se habilita el menú para corregirlo:

Deshabilitando SSH por interfaz web


Ahora si, a disfrutar del acceso web.

Host ESXi con acceso web listo


Espero sea de utilidad, hasta la próxima.


Twitter @robertourgiles






viernes, 8 de enero de 2016

El licenciamiento VMware vSphere para replicar VMs con Veeam B&R

Hello world

Veeam Backup & Replication es una herramienta muy poderosa y sencilla, para obtener respaldos de entorno virtual, tanto con VMware vSphere como con MS Hyper-V.

Una de las características que lo hace tan poderosa, es la capacidad de no solo obtener los respaldos y poder replicarlos, sino también de poder replicar máquinas virtuales (VMs) encendidas.

De cara al cliente final, es muy atractivo su modelo basado en sockets (similar a VMware vSphere) sin tener que considerar número de virtuales, ni capacidad a respaldar, menos aún agentes. Y se pone mejor al saber que solamente se licencia el origen de los datos.

Acá hay un post que lo detalla mejor (en inglés):

https://www.veeam.com/blog/starting-with-vmware-vm-replication-using-veeam-availability-suite.html

Hay una parte al final del post, que detalla lo siguiente:

Tomado: https://www.veeam.com/blog/starting-with-vmware-vm-replication-using-veeam-availability-suite.html


Con este antecedente, un colega me hizo la siguiente consulta:


Es claro que de lado de Veeam B&R no se requiere licenciar el sitio destino para replicar una VMs, pero ¿necesito licenciar VMware vSphere?


Ante la duda, levante un pequeño laboratorio, y estos son los resultados:

Tarea de replicación de Veeam B&R con destino ESXi sin licencia (VMware Hypervisor)
Tarea de replicación de Veeam B&R con destino ESXi licenciado

Como vemos, para poder replicar una VM con Veeam B&R, el host destino debe tener el hypervisor VMware licenciado, al menos con la versión mínima por el tema de las APIs.


Importante señalar que todas las pruebas fueron realizadas con Veeam B&R v8 y VMware vSphere 5.5.

Espero sea de utilidad, y hasta la próxima.

Twitter @robertourgiles










lunes, 2 de febrero de 2015

VMware Partner Exchange 2015 - Día 1 (BootCamps) - AirWatch


Es la 3ra vez que asisto al evento de VMware para los socios, el VMware Partner Exchange o mejor dicho el #VMwarePEX, gracias a Akros la compañía en la cual laboro.

Al igual que el 2014, este año vez repite la ciudad de San Francisco, y el escenario fue así mismo el Moscone West, un lugar que por cierto brinda todas las facilidades en cuanto a espacio y cercanía.

El clima está algo frío (considerando que en mi ciudad Guayaquil tenemos entre 25° y 33°) pero al menos esta semana no se esperan lluvias.


El sábado y domingo estuvimos atendiendo el VTSP de AirWatch EUC4702b-BC - VTSP - Mobility (AirWatch Technical Pre-Sales), y honestamente debo decir que me parece un producto muy interesante, del cual hasta ahora no había tenido oportunidad de verlo en acción, pero al mismo tiempo no lo veo directamente relacionado con la virtualización propiamente dicha.

AirWatch Agent for Android


Para quienes conocemos más de entornos Windows, por ejemplo, se podría decir que es AirWatch es para el BYOD lo mismo que las políticas de grupo (GPO) son para las PCs Windows.

Por ejemplo habilitamos un perfil, en donde bloquemos el uso de la cámara, y las capturas de pantalla, y esto es lo que obtuvimos al querer usarlo:


Cámara bloqueada por AirWatch



El producto tiene una estructura muy amplia, permite hacer todo tipo de controles, e incluso la ubicación geográfica del mismo. Tiene una navegador (browser) y carpeta de archivos (content) propia, lo que permite controlar dónde se navega, qué se revisa, qué se puede copiar, qué no se puede copiar, etc.

Es un MDM sencillo de administrar y muy poderoso, ya que tuvimos la oportunidad de probar en equipos Android y iOS y, con algunas diferencias), en ambas plataformas se obtuvo control completo del dispositivo, y también control solo de ciertas aplicaciones (como el cliente de correo electrónico solamente).

AirWatch Profiles


En general, es una apuesta de VMware por la movilidad, y va acorde a la tendencia del BYOD, que crece cada día.

Mi labor actual está mas relacionada con Infraestructura y Virtualización, de modo que el tema MDM no es algo que actualmente esté directamente relacionado, pero conocer estas tendencia sin duda permiten tener un mayor campo de asesoría y mejora de car a nuestros clientes.

AirWatch Compliance



AirWatch Agent Version

Y usted, ¿qué opina?

sábado, 31 de enero de 2015

¿Porqué los soportes de hardware 24x7 con atención en 4 horas ya no son requeridos?




Artículo original en inglés: http://bit.ly/1E8zszR
Publicado por: Josh Odgers


Disclaimer: Lo siguiente es mi interpretación personal, no es una traducción exhaustiva del texto original. Algunas palabras o frases pueden no ser exactas, pero el mensaje final se ha pretendido mantener intacto.

En semanas recientes, he visto numeros RFQ/TDR que tienen requerimientos de soporte 24x7x2 o 24x7x4 con reemplazo de partes en sitio, y aunque esto no es raro, he estado pensando ¿porqué se hace esto?


A lo largo de mi carrera de TI, que abarca mas de 15 años, en la mayoría de los casos yo mismo he recomendado en mis diseños, que el cliente adquiera contratos de soporte de tipo 7x24 con atención de 4 horas en sitio, para equipos de cómputo, almacenamiento, SAN y dispositivos de red en general.


Nunca he encontrado dificultad para justificar esta recomendación, porque tradicionalmente si un componente en el Centro de Datos falla, como por ejemplo una controladora del almacenamiento, esto generalmente tiene un alto impacto en el negocio del cliente, y cuesta decenas o centenas de miles de dólares o incluso millones, dependiendo del tamaño del cliente.


La avería de una controladora de arreglos no solo genera un alto impacto, sino también un alto riesgo para el entorno, ya que no tendrá redundancia y una falla posterior podría (con mucha posibilidad) resultar en una caída completa


Así en este ejemplo, en donde una típica solución de almacenamiento que tiene una falla en una de sus controladoras, resulta en una degradación del rendimiento (pierde el 50% de su capacidad de procesamiento) y un alto impacto/riesgo en el cliente, el poseer el soporte 24x7x4 o 24x7x2 tiene sentido!


La pregunta es, porqué elegir una solución de HW en donde la falla de uno de sus componentes lo pone en alto riesgo?


Con lo rápido que cambia la tecnología cada año, he estado envuelto en muchas reuniones con clientes qué me han preguntado qué recomiendo en términos de soporte para el HW (para clientes Nutanix).


Normalmente estas preguntas/conversaciones ocurren después de la discusión sobre la tecnología, en donde explico varios escenarios de falla y cuán resielente es un cluster de Nutanix.


Mi recomendación será algo como esto:

Si usted arquitecta su solución para el nivel de disponibilidad deseado (p.e. N+2) no hay necesidad de contratar un contrato de soporte de hardware 24x7x4h, la opción de soporte tipo Siguiente Día Hábil (8x5xNBD) aplica perfectamente bien.

Justificación:


1. En el evento de incluso la falla de un nodo completo, el cluster Nutanix va automáticamente a "auto-repararse" con el factor de resiliencia (2 o 3) configurado, incluso antes de que un contrato con atención de 2 horas pueda proveer un técnico en sitio, diagnosticar y reemplazar el componente.


2. Asumiendo que el componente de HW se reemplaza en el plazo de 2 horas (lo cual no es usual en mi experiencia), Y ADEMÁS asumiendo que Nutanix no se "auto curó" automáticamente previo al reemplazo del disco/nodo, el disco/nodo reemplazado empezará en ese momento el proceso de "auto-curado". Es así que el tiempo de recuperación o regeneración va a ser superior a 2 horas. En el caso de Nutanix, el "auto-curado" inicia casi inmediatamente.


3. Si un cluster está dimensionado con el nivel de disponibilidad requerido en función de la necesidad del negocio, p.e. N+2, un nodo puede fallar, Nutanix automáticamente va al auto-curarse y entonces tolerar una falla subsecuente con la habilidad de nuevamente "auto- curarse" con el factor de resiliencia configurado nuevamente (2 o 3).


4. Si un cluster está dimensionado para un cliente solo con N+1, un Nodo puede fallar, y Nutanix automáticamente a auto-curarse; Entonces si, en el poco probable (pero no imposible) evento de una fallo subsecuente (p.e. el fallo del 2do nodo antes del reemplazo del HW con problemas), el Cluster Nutanix se va a mantener operando.


5. El impacto en el rendimiento de la falla de un nodo, en un entorno Nutanix N+1, es en el peor de los casos (cluster de 3 nodos), sería del 33%, que comparado con un entorno SAN/NAS de 2 contraladoras, en donde el impacto de la falla de una de ellas representa el 50%; en un cluser de 4 nodos, el impacto es solo del 25%, y en clientes con 8 nodos es del 12,5%. Mientras mas grande el cluster es menor el impacto.


Nutanix recomienda N+1 con hasta 16 nodos, y N+2 con hasta 32 nodos.Mas allá de 32 nodos mayores niveles de disponibilidad pueden se requeridos, basado en las necesidades del cliente.


El riesgo e impacto de los escenarios de fallas es clave, el caso de Nutanix, por su capacidad de auto-reparado, y el hecho de que todas las controladoras y SSDs/HDDs en el cluster participan en este proceso, y hace que pueda ser realizado rápidamente y con bajo impacto. Es así que el impacto de una falla es bajo (N-1) y la recuperación es hecha rápidamente y el riesgo para el negocio es bajo, por tanto se reduce drásticamente (e incluso es prescindible, en mi opinión) la necesidad de un soporte tipo 24x7x2hr para los clientes Nutanix.


En resumen:

1. La decisión de qué tipo de contrato de soporte de HW es el más apropiado es una decisión que depende del negocio, y debe estar basada en parte en un sesudo análisis de riesgos realizado por un experimentado arquitecto, que debe estar muy familiarizado con toda la tecnología que se va a utilizar.


2. Si la recomendación del arquitecto es que el riesgo de una falla en el HW puede causar un alto impacto o incluso una pérdida de operación para el negocio, tal que se requiera un contrato 24x7x2hr, entonces mi consejo es que se re-considere si la "solución" propuesta cumple con los requerimiento del negocio. Solo si no tiene otra opción, compre el soporte 24x7x4hr ó 24x7x2hr.


3. Tener una alta dependencia de que el HW sea reemplazado para restaurar la resiliencia y/o rendimiento de una solución, es por si mismo un alto riesgo para el negocio.


Y además,

4. En mi experiencia, no es poco común tener problemas obteniendo el soporte de HW en sitio dentro del término del contrato o SLA. A veces esto escapa del control del fabricante, pero la mayoría de fabricantes experimentan uno o mas de estos problemas que personalmente he experimentado en numerosas ocasiones en otros roles, como:

a) Vendor falla en complir el SLA por soporte en sitio

b) Vendor falla el tener la parte requerida disponible dentro del SLA

c) El reemplazo de HW es con parte re-acondicionadas (práctica común) y que han fallado antes


Nota: los contratos de soporte no prometen una resolución dentro del período de 2 o 4 horas, simplemente prometen que alguien va a ir al sitio, y en algunos casos será después de haber llevado un proceso telefónico de detección de problemas con el fabricante, envío de logs para análisis, etc. Por eso es que, las 2 o 4 horas de atención no agregan mucho valor.


Así que en su próxima compra de infraestructura (o cuando hagan recomendaciones, si usted es un arquitecto), considere cuidadosamente qué tipo de solución elije (o propone), y su siente que es mandatorio un contrato de soporte en HW tipo 2hr/4hr, le recomiendo re-evaluar el requerimiento de lo que usted esta adquiriendo (o recomendando), porque puede que no sea lo suficientemente confiable para cumplir la exigencia requerida.


Food for thought

viernes, 24 de agosto de 2012

El arte de la pre-venta




En una reciente conferencia telefónica llevada a cabo por un Gerente de Cuentas y su ingeniero pre-ventas, he sido testigo de algunos errores críticos del ingeniero al momento de presentar la tecnología al cliente. Ninguno de los errores fueron graves o complicaron el hilo de la conversación, pero sin duda no permitieron potenciar el valor de la misma.

Esa conversación me hizo reflexionar acerca de los principios y habilidades que necesitan ser aplicadas por los ingenieros pre-venta, y que quiero plasmar en estas pocas líneas.

La ingeniería pre-venta es un arte en todas sus formas.

Definitivamente existe ciencia y metodologías detrás de su éxito, pero practicando los métodos y estudiando su ciencia no será suficiente para ser excelente; Para ser grandioso es necesario invertir esfuerzos y tiempo en la tecnología, el negocio, y lo más importante... en tu estilo personal.

Si actualmente eres un buen pre-venta y no te preocupa  ser grandioso… entonces el resto del blog no te va a ayudar. Si eres un “usuario-final” o un cliente que interactúa con ingenieros pre-venta, entonces  este blog quizá puede ayudarte a entender un poco qué es lo que pasa por la cabeza de la persona que está al frente tuyo.

Si tu trabajo son las implementaciones post-venta, servicios administrados, etc. este blog puede ayudarle a tener una idea de qué es lo que tu contraparte está haciendo.

Si eres un ingeniero pre-venta que le gustaría utilizar algunas nuevas ideas o herramientas, entonces este blog es para ti.



Las  5 reglas de Joe para los Ingenieros Pre-venta

  1. Tu eres miembro del equipo de ventas
  2. Tu no eres un vendedor
  3. Debes ser relevante para el negocio
  4. Debes tener conocimientos técnicos
  5. Debes conocer tu audiencia o público

Estas son reglas de oro que utilizo para tener una mejor forma de pensar con los clientes, desde el punto de vista del pre-venta. Estas reglas no están escritas en piedra, pero son de mucha utilidad y tratan de abarcar o cubrirlo según mi experiencia; son herramientas, solo utilícenlas.

Veamos rápidamente cada una de la reglas:



1. El ingeniero pre-venta es un miembro del equipo de ventas


Esta es una de las cosas claves que debemos recordar, pero que para muchas gente muy técnica que trabaja como pre-venta es difícil de entender. La relación entre venta y pre-venta no es siempre la más amorosa ni está llena de abrazos y besos, de hecho algunos ingenieros tienden a disgusterse a los vendedores por diversas razones (y viceversa). Haya o no resentimientos, es natural estar orgulloso de sus habilidades técnicas, y pensar en sí mismo en una perspectiva comercial puede no ser lo más cómodo que digamos…

Pues bien, ¡sáquese eso de la cabeza!, o de lo contrario es mejor retirarse del rol de pre-venta!

Como un ingeniero pre-venta su trabajo es actuar como miembro del equipo de ventas, asistiendo a los gerentes de cuentas en la venta de los productos y servicios que la compañía provee. Usted está ahí para impulsar las ventas que proporcionan los ingresos para la compañía.

(Si estás confundido por la referencia mira este video, vale la pena:  http://bit.ly/dqTzU7)


2. El pre-venta no es un vendedor

 

Ahora que usted ya ha asimilado el hecho de que es parte del equipo de ventas, es el momento de reafirmar el hecho de que usted no es un gerente de cuenta o representante comercial. Esto es de vital importancia, solo el hecho de aplicar solo las 2 primeras reglas va a hacer que esté un poco mejor que sus compañeros. Voy a usar el término AM (Account Manager = Gerente de Cuenta) para ventas de aquí en adelante, permitiéndome así que éste abarque cualquier título no-técnico de ventas que se ajuste a este rol.

Un AM y un Ingeniero Pre-Ventas son roles completamentes diferentes, pero ambos tienen un fin en común. Un AM está estrechamente ligado a una meta comercial, y es probable que pase horas hablando respecto de porqué se cumplen o no se cumplen los presupuestos de ventas. El trabajo principal de un AM es mantener excelente relacionamiento con los clientes, y vender lo que la empresa vende.

Por otro lado el trabajo de un Ingeniero Pre-Ventas es una tarea totalmente diferente. Aparte de apoyar el trabajo de los AM, su trabajo es asegurarse de que el producto, servicio o solución que se está ofreciendo es relevante, efectiva, adecuada y completa para un cliente en particular. En el mundo de los distribuidores esto es conocido como “Asesor confiable / Trusted Advisor”, pero en realidad este “Asesor Confiable” suele ser un equipo de 2 personas, que consiste de un AM y un Pre-Venta... quienes conocen bien al cliente, entienden el entorno, y mantienen una relación mutuamente beneficiosa.

En el lado del ingeniero, debe tener presente siempre la IDEA:

  •           Identificar
  •           Diseñar
  •           Evangelizar
  •           Ajustar

Entonces… ¿cuál es la brillante IDEA?

Un ingeniero Pre-Venta debe IDENTIFICAR los requerimientos del cliente, DISEÑAR un conjunto de productos o solución para cumplir estos requerimientos, EVANGELIZAR la solución propuesta, y AJUSTAR la solución las veces que sean necesarias con el cliente.


3. Debe ser relevante para el negocio

 

Esta suele ser una de las cosas más difíciles de entender desde el punto de vista técnico. Entender los requerimientos del negocio y aplicar la tecnología para cubrir estos requemientos no es algo natural para la mayoría de los ingenieros, pero es vital para el éxito. 
Tecnología de punta no tiene ningún valor por si sola, el mundo tecnológico está lleno de casos de negocios que fracasaron porque no supieron capitalizar en beneficios para el negocio la tecnología que tenían. La misma lección se aplica para el ingeniero pre-ventas.

Para ser un gran ingeniero pre-ventas usted debe entender lo suficiente tanto del negocio como de la tecnología como para hacer notar claramente qué problema del negocio podemos solucionar con la tecnología adecuada, y los beneficios que se obtendrían. ¿De qué me sirve tener el CPU más veloz, la mayor cantidad de RAM? ¿Qué significa eso para el negocio, o la empresa? ¿Qué beneficios trae para mi trabajo? ¿Cómo catalizo la tecnología en beneficio para el negocio?

Una forma sencilla de empezar a entender cómo piensan los ejecutivos de las empresas a la que usted les vende, es comenzar a leer las revistas y libros que ellos leen. La próxima vez que usted esté en cualquier sala de espera en vez de ver la revista de modas póngase a hojear revistas de negocios.


4. El pre-venta debe tener conocimientos técnicos

 

Esta parte es obvia, pero desafortunadamente no siempre se cumple. En ocasiones he visto ingenieros pre-venta que se pasan leyendo diapositivas porque no conocen el producto o material que están presentando.

Mantener un apropiado nivel de conocimiento técnico es cada vez más difícil a medida que nuevos productos aparecen, pero se debe hacer de todos modos. Si usted no es capaz de hablar de las características de un producto o solución si tener que recurrir a diapositivas u hojas de datos, es mejor que no lo haga.

Mantenerse actualizado es una tarea complicada, pero afortunadamente hay una gran cantidad de recursos que se pueden utilizar. Blogs y twitter pueden ser usados como un flujo constante de información técnica valiosa y actualizada; agregue a esto el entrenamiento formal y documentación de los fabricantes, y tiene las herramientas para ser técnicamente relevante. 

El mejor consejo que puedo ofrecerles para mantenerse técnicamente vigente es no tener miedo a preguntar o a decir no sé. Si usted necesita entrenamiento búsquelo, si usted necesita información busque alguien que lo sepa y hable con ellos. Igualmente de importante es compartir su experiencia con otros, ya que crea un entorno de colaboración que beneficia a todos.


5. Debe conocer su audiencia o público

 

Esta puede ser quizá la más importante de las 5 reglas, y se resumen en que haga su trabajo y aplíquelo. Asegúrese de que ha investigado lo suficiente a su cliente, sus necesidades y su entorno tanto como sea posible. Conozca qué cosas le interesan, y cuáles son sus necesidades críticas (puntos de dolor) antes de hablar en una reunión, siempre que sea posible.

Conocer a su público aplica también durante las reuniones con el cliente. A medida que el cliente proporciona más información que es relevante, debemos adaptar nuestro discurso sobre la marcha. Cualquier conversación técnica debe tener una retroalimentación constante con los comentarios del cliente.



Practicando el arte 

Como cualquier otro arte, la pre-venta debe ser practicada, recuerde que la práctica hace al maestro.. Usted debe estudiar los productos y servicios que la empresa vende, desarrollar sus habilidades como expositor, y constantemente trabajar en su comunicación.

Desde mi perspectiva la mejor manera de fortalecer estas habilidades es con el uso de la pizarra. 

Un pizarra es una de las mejores armas del arsenal de un ingeniero pre-ventas. Proporcionan el lienzo blanco en el cual podemos dibujar la solución y mantener fluida cualquier conversación. A diferencia de las presentaciones, una sesión con pizarra son mucho más flexibles y permiten fácilmente mantener al cliente enfocado en lo que quiere escuchar. Creo firmemente que un ingeniero pre-venta no debería hablar de cualquier tecnología que no pueda sustentar con confianza a través de una pizarra.

Usted no debe tomar este concepto a la ligera. He dictado una clase completa de datacenter de 5 días completos solo con pizarra, cubriendo temas comoLAN, SAN, almacenamiento, servidores, y redes! Era el sistema más adecuado para la audiencia La pizarra es su amiga!.

Si usted no tiene una pizarra es casa consígase una. Úsela para perfeccionar sus habilidades, ayuda a visualizar la arquitectura, y practicar antes de las reuniones. Mire las presentaciones que suele presentar, y practique transmitir el mismo mensaje solo con pizarra. A medida que se sienta cómodo con las presentaciones técnicas basado en pizarra, va a encontrar que puede transmitir un mayor y mejor nivel de información técnica adaptada a las necesidades del cliente y de una manera mucho más rápida.

Además… las pizarras no necesitan energía eléctrica, y no sufren de dificultades técnicas, como los proyectores. :o)

Con la pizarra en blanco frente a los clientes piense en pintar “un cuadro” para ellos, comenzando con grandes rasgos que describen la tecnología y vaya agregando detalles en las áreas en los cuales se muestre mayor interés, de modo que vamos profundizando solo en los detalles que sean relevantes para el cliente… es aquí donde su conocimiento de la audiencia es clave!







En el diagrama se puede observar la forma en que una conversación con el cliente debería fluir. Se debería iniciar con un marco general y profundizar solo en los puntos en los cuales el cliente muestra interés o son aplicables a su centro de datos o su trabajo. No vuelva a sentir la necesidad de discutir todas las características de un producto o solución, porque no todas son relevantes para cada cliente. 

Por ejemplo, un administrador de servidores probablemente no le importe los rápidos que sean los switches, pero para el equipo de networking probablemente sí. Es posible que su producto pueda ayudar a reducir toneladas de costos, ¡grandioso!, pero probablemente esto no será relevante para los administradores que no son responsables del presupuesto. 

Asegúrese siempre de que usted está manteniendo relevancia para la audiencia y el negocio.


Resumen:

Un pre-venta como cualquier otro conjunto de habilidades debe ser perfeccionado y practicado. No llega de la noche a la mañana, y al igual que cualquier otra cosa, nunca es tan buena como puede ser. Contruya un estilo y una metodolorgía de trabajo para usted, y nunca tenga miedo de cambiar o modificarlos para encontrar áreas donde se pueda mejorar. Lo mejor que se puede hacer es encontrar

Lo mejor de todo es que obtiene mas valor que pueden dar a su cliente, equipo y empresa en general.