ESXi

VMware 101 – partedUtil y particiones de diagnostico

rsz_vmware

Que tal gente, el día de hoy les voy a platicar de un tema muy “básico” aunque me tomo un buen tiempo recordar e investigar para poderlo configurar… es impresionante como con el tiempo vamos perdiendo práctica en temas que consideramos “sencillos” o “básicos” es por eso que quiero compartir este procedimiento para todos aquellos […]

vSphere troubleshooting – Memoria

rsz_vmware

Que tal gente, el día de hoy estaré continuando con la serie de vSphere troubleshooting, en este caso estaremos hablando sobre Memoria. En el articulo anterior hablamos de algunos pasos para poder comenzar con el proceso de troubleshooting a nivel general por lo que no estaremos hablando sobre eso en esta ocasión de cualquier manera […]

vSphere 5.5 – ¿Que hay de nuevo? – Parte 1

Que tal gente el día de hoy les voy a hablar sobre lo nuevo que se agrego a vSphere 5.5, estaremos revisando de manera “profunda” todas las nuevas capacidades. Recordemos que en VMworld 2013 San Francisco Pat Gelsinger anunció la nueva versión de la plataforma entre otras noticias (vSAN (aunque este pertenece a vSphere), NSX, vCHS, etc.).

Computo – Host ESXi

La capacidad que podemos tener en un solo host ESXi tanto lógica como física aumento bastante en este release estos son los máximos que manejamos en esta versión:

  • 4TB de Memoria RAM por Host ESXi – ¿Mayor densidad?, claramente el tener la posibilidad de alcanzar este nivel de recursos no quiere decir que es algo recomendable, todo dependerá del caso de uso y el ambiente (ej. cargas no criticas vs cargas críticas, overcommitment vs recursos dedicados, etc.) Se tiene soporte experimental para 16TB de RAM. Es interesante saber que se tiene soporte para memoría de tipo “reliable” donde se tiene una copia o “mirror” de una sección de la memoría, ESXi identificará este espacio de memoría designado como “reliable” (claramente configurado previamente por el usuario/admin a nivel del host físico) y podrá colocar ciertos procesos como watchdog podemos verificar la cantidad de memoria “reliable” en uso con el comando:

esxcli hardware memory get

  • 320 CPUs físicos por Host y 4096 vCPUs (CPUs de VM) – nuevamente, una cantidad impresionante, numeros difícilmente utilizados o empleados en el campo.
  • C-States – se integra el manejo de CState además de los PStates de procesador para poder optimizar energía en distintos tiempos, los P-states básicamente son aquellos niveles de rendimiento (operacionales, frecuencia y voltaje) que ofrece el procesador mientras que el C-State permite desactivar ciertas capacidades propias del procesador para ahorrar energía extra entrando en distintos estados “idle”, todo esto ESXi lo realiza a través del ACPI.

Pstatescstates

Storage – Host ESXi

Una sección que recibió BASTANTES nuevas funcionalidades y mejoras a lo ya existente vamos a revisar que nos trae vSphere 5.5 del lado de storage:

  • vSAN  vSAN nos permite tener almacenamiento centralizado a partir de discos locales, lo interesante en esto es que se emplea SSD para poder realizar cache de lecturas y buffering de escrituras (write back cache) lo que nos permite tener almacenamiento verdaderamente escalable y con un excelente rendimiento, para saber mas sobre vSAN les recomiendo leer mi articulo vSAN Deepdive.  Es importante notar que no tiene nada que ver con VSA o la vSphere Storage Appliance, aunque ambas nos permiten entregar almacenamiento local de manera centralizada estan enfocadas para distintos segmentos y casos de uso, para esto les recomiendo leer el articulo de Rawlinson Rivera donde nos presenta una tabla comparativa entre ambas soluciones, leelo aquí.
    vsanhabiliar
  • vFlash Otra interesante funcionalidad que se agrega a vSphere 5.5 que nos permite dar read cache a las VMs, es importante saber que esto no ofrece aceleración de escrituras o writeback cache. Se habilita de manera granular por VMDK como lo podemos ver en la imagen. La aceleración es provista por SSDs locales en el host ESXi, estaré hablando mas a fondo sobre vFlash en un articulo futuro, tocando temas de mejores prácticas, arquitectura, etc.

virtualflashhabilitar

  • Microsoft Clustering Services se agrega soporte para el path selection policy (PSP) de Round Robin cuando utilizamos MSCS con Windows 2008 y 2012 (que emplean reservaciones SCSI3) el disco de quorum tiene que ser entregado como passthrough RDM. De igual manera se agrega soporte para iSCSI en las 3 distintas arquitecturas de MSCS soportadas (Cluster in a box, Cluster across boxes y N+1) ya sea con software iSCSI o hardware iSCSI.
  • VMDKs de 2TB+ Se cuenta con soporte de VMDKs de hasta 64TB (utilizables 63.36TB por metadata y demás), aunque debemos tener algunas consideraciones: Al utilizar NFS se tendrá la limitante del sistema de archivos que provee dicho punto de montaje, es decir, el tamaño de archivo máximo que maneja (ej. ext3 llega a 16TB), VMFS3 continua con la límitante de 2TB , No se puede extender un volumen en “vivo” u online de 2TB a un espacio mayor, esto tiene que ser con la VM apagada, No se soporta FT, VSAN no soporta VMDKs de 2TB+ y El adaptador Buslogic no es compatible. Se logro este incremento a través de 2 capas de direccionamiento indirecto de bloques. En el caso de tener snapshots para este tipo de discos de mas de 2TB+ los snaps serán creados automáticamente en formato sesparse (funcionalidad que solo esta presente para Horizon View en los linked clones).
  • Mejor manejo para PDL Se agregó un mecanismo que de manera automática remueve todos aquellos dispositivos de storage que se encuentren marcados con PDL o “Permanent Device Loss” que básicamente es la perdida de acceso al dispositivo (LUN) lo que evita futuras operaciones de I/O a nivel de dicho dispositivo y también nos permite liberar un dispositivo del máximo de 255 que se maneja.
  • Heap de VMFS  nos permite abrir hasta 64TB concurrentes por Host ESXi, cosa que en versiones anteriores era un problema, muchas veces necesitábamos modificar el heap de vmfs para poder tener acceso a mas archivos abiertos.
  • Soporte para EndtoEnd 16Gb FC   anteriormente se soportaba HBAs de 16Gb pero trabajando a 8Gb, ahora toda la fabric puede estar a 16Gb.
  • Soporte para Hot-plug de PCIe SSDs –  se soporta el agregar discos SSD en caliente (con el servidor operando) mientras que estos esten conectados a una controladora PCIe, esto extiende el soporte de hot-plug de discos donde se soportaba SAS y SATA.

Networking- Host ESXi

Del lado de networking se agregaron algunas funcionalidades interesantes, revisemos que tenemos nuevo en vSphere 5.5:

  • Traffic filtering & marking – se nos permite agregar ACLs a nivel de portgroup (se implementa y configura en cada portgroup), esto básicamente nos da la opción de permitir o tirar paquetes en base a distintos “calificadores”:opcionesacls
    De igual manera nos permite marcar con DSCP para brindar QoS en los paquetes y al igual que los ACLs nos permite definir los mismos calificadores, un caso de uso en para esta funcionalidad sería VoIP:

cosdscpqualifiers

  • pktcap-uw – esta herramienta que forma parte del hipervisor es similar a lo que vendría siendo TCPdump, nos permite recolectar paquetes para su analisis, realizar un trace y demás esta bastante interesante y nos brinda visibilidad y capacidad de poder realizar troubleshooting de a nivel de redes incluso permitiéndonos extraer los paquetes en formato .pcap para su analísis en Wireshark, aquí les muestro un ejemplo de captura de 1 paquete de iSCSI entre mi host ESXi y mi almacenamiento PX6 de LenovoEMC:

capturapktcap

  • Soporte para NICs de 40Gb – se agrega soporte para el manejo de tarjetas ethernet a 40Gbps esto permite tener una escalabilidad en términos de rendimiento bastante alta, en ambientes donde el crecimiento del host esta topado por cuestiones de bahias de expansión PCIe (ej. blades) hace mucho sentido (claramente debemos de contar con infraestructura de red capaz de manejarlo.
  • Mejoras en SR-IOV – desde la versión 5.1 de vSphere soportamos SRIOV o Single Root I/O Virtualization, que básicamente nos permite segmentar un mismo dispositivo físico que este conectado a través de PCIe en distintos dispositivos virtuales que son conocidos como “VFs” o Virtual Functions que son despúes presentados directamente a las VMs permitiendo así hacer un bypass de todo el stack de networking del vmkernel (hipervisor) reduciendo latencia y mejorando el throughput, en esta versión se agrega una funcionalidad de poder presentar las propiedades del Portgroup al cual esta conectado dicha VF ej. presentar modo promiscuo, vlans, etc.
  • Mejoras para LACP – Se cuentan con mejoras en LACP, desde la versión 5.1 se soportaba LACP. Con este release se agregan mas algoritmos de negociación, se soportan 64LACPs por ESXi y 64 por vDS, cosa que antes era 1 LACP por vDS y 1 por Host ESXi, estaré escribiendo un articulo puntual sobre esto.

Hardware virtual (VMs)

Con vSphere 5.5 también se liberó una nueva versión de hardware virtual o “VM compatibility”, versión 10:

vmhw10

¿Que beneficios nos brinda esta nueva compatibilidad de VM?

  • Hasta 128 vCPUs por VM
  • 2TB de Memoria RAM por VM
  • 64TB en un solo VMDK (utilizables son 63.36TB) y vRDMS de ~64TB (buslogic no soporta estos tamaños).
  • 4 adaptadores vSCSI y 30 discos por controladora lo cual nos da un total de 120 discos por VM
  • Adaptador SATA (AHCI), en este caso solo se soporta un máximo de 30 discos y cuatro controladoras
  • Soporte para GPUs de Nvidia y AMD
  • Aceleración de gráficos para Linux.

Como pueden ver se agregan capacidades interesantes a nivel de VM, en este caso desde mi punto de vista veo una que resalta entre las demás, soporte para VMDKs de 2TB+, existen muchos casos de uso donde se justifica tener discos de mayor tamaño y el configurar RDMs para estas VMs resulta un incremento el la administración tanto del storage como de VMware, aquí lo importante que debemos recordar es el hecho de que aunque podamos agregar discos de dicho tamaño debemos de tomar en cuenta temas como DR, BC, backups y demás, tomando como ejemplo que tengamos un datastore de 64TB donde coloquemos 5 VMs con VMDKs de 10TB imaginemos el tiempo que nos toma el respaldar esta info, el restaurar este LUN, replicación, etc y siempre apegandonos a los RPOs y RTOs definidos (¿comienza a complicarse cierto?) claramente existen muchos casos de uso donde será la opción utilizar VMDKs de gran tamaño pero debemos de comparar todos los “trade-offs” entre las distintas opciones para poder justificar nuestra decisión.

Esten atentos para el siguiente articulo donde estaré hablando de las mejoras en vSphere replication y vCenter Server.

Intel NUC – laboratorio casero.. bueno, bonito y barato

Que tal gente quería platicarles sobre una nueva adquisición para mi laboratorio, es claro que todos queremos reducir costos y hacer mas con menos, en mi caso, mi laboratorio tiene un componente que le llamo “controlcenter” que básicamente es una VM que permite conectarme desde el exterior para poder encender todos los demás componentes de la infraestructura, a través de PXE (Servidores ESXi y almacenamiento). Claramente esta VM estaba siendo ejecutada en una workstation con 16GB de RAM y tenía ESXi instalado, el problema de esta Workstation es que tenía una fuente de poder algo poderosa para la simple tarea de mantener encendida dos vms de core y resultaba costoso mantenerla arriba. Me dí a la tarea de buscar un remplazo para esta workstation y así me encontré con la magnífica Intel NUC o Next Unit of Computing:

Esta pequeña, en verdad PEQUEÑA computadora nos ofrece interesantes propiedades dignas para un laboratorio basado en VMware, en mi caso pude adquirir el modelo “DC3217IYE” que a grandes rasgos tiene lo siguiente:

IntelNuc

  * Hasta 16GB de RAM DDR3 a 1600MHz (SODIMM)

  * 1 Puerto Gigabit de Intel

  * 2 interfaces mSATA

  * Procesador Intel Core i3 3217U dual core con HT y 1.80GHz

En mi caso adquirí un SSD de 240GB mSATA lo cual me permite almacenar localmente las VMs de core sin necesidad de tener encendido mi almacenamiento central, cosa que reduce bastante el consumo de energía.

Existe otro modelo de intel NUC que tiene un puerto thunderbolt, con el cual podrían tener 2 interfaces de red gigabit utilizando el convertidor de thunderbolt a gigabit ethernet de Mac. esto les permitiría armar un laboratorio solo a partir de Intel NUC. Una consideración es el hecho que la interfaz de red no es soportada por ESXi 5.5 (almenos en el beta) por lo que deben de agregar el vib de Intel que viene con ESXi 5.1 utilizando image builder, bastante sencillo.

Aquí podemos ver mi pequeña gran caja desplazando a una workstation que ademas de consumo energetico también generaba mucho calor:

nucesxi

Actualización a Lab

Que tal gente, solo para platicarles que debido a requerimientos de recursos de computo para poder tener ambientes mas complejos y poder estudiar, escribir en mi blog y en otras fuentes me dí a la tarea de actualizar mi laboratorio.

Como parte de este esfuerzo se agregó un nuevo nodo ESXi para sustituir otros 2 nodos de menor capacidad que gestionaban las cargas de Management (vCD, vCenter, vCO, etc). Podemos ver que en la capacidad actual cluster ya se cuenta con 128GB de memoria RAM y 29GHz de CPU.

Screen Shot 2013-07-28 at 11.14.11 PM

Además de la capacidad para poder contar con ambientes mas complejos que consumen mas recursos de computo, también esto fue con el objetivo de poder reducir la cantidad de energía consumida, podemos ver que con los 2 servidores (whiteboxes) encendidos y un servidor que ya se convirtió en workstation (16GB de RAM/proc hexa core) se consumen aprox 420 – 450 Kw (esto en estado “steady” sin carga), falta realizar una prueba de estrés al ambiente para poder determinar los consumos reales en el momento de estar trabajando con el mismo.

imageEl consumo que podemos ver en la imagen esta siendo realizado por los siguientes elementos de mi laboratorio:

* 2 “Servidores” (Whiteboxes)

* NAS PX6 -300D Iomega con 6 discos SATA

*Switch Dell Powerconnect 2708

*Switch TRENDnet teg-s80g (soporte para jumbo frames, tráfico iSCSI)

* Workstation

Características de Whiteboxes:

“Servidor 1”

  • Motherboard Gigabyte X79-UP4 Socket LGA2011 8 DIMMs
  • Procesador Intel Core i7-3820 Quad/HT
  • 64GB RAM DDR3 / 1333MHz (no ECC)
  • 2 Puertos LAN gigabit onboard, intel 82579V/Realtek

“Servidor 2”

  • Motherboard Asus P9X79 Deluxe Socket LGA2011 8 DIMMs             la foto
  • Procesador Intel Core i7-3820 Quad/HT
  • 64GB RAM DDR3 / 1333MHz (no ECC)
  • 2 Puertos LAN gigabit onboard, intel 82579V/Realtek

Workstation

  • Motherboard Gigabyte GA-880GM Socket AM3 4 DIMMs
  • Procesador AMD Phenom II X6 1090T
  • 16GB RAM DDR / 1333MHz (No ECC)
  • 1 Puerto LAN gigabit Realtek onboard RTL8169
  • 1 Puerto LAN gigabit Realtek en tarjeta PCI RTL8169

¿Siguientes Pasos?

Como siguientes mejoras tengo en mente mejorar el networking del laboratorio tal vez con un switch SG300-x para poder contar con capacidades de L3 y poder consolidar el networking en solo un switch administrable.
También se tiene la necesidad de crecer el almacenamiento disponible, por cuestiones de presupuesto en su tiempo adquirí discos duros de 250GB SATA para la NAS Iomega, cosa que pienso crecer a discos de 3TB.

Ya con el tiempo iremos viendo que mas se agrega, tal vez podrán considerar esto como una inversión que no se justifique, pero aparte de utilizarlo para escribir aquí, estudio, y me divierto en el ambiente (si para mi es divertido el tiempo en laboratorio) así que siempre que pueda estaré agregando mejores componentes a este lab.

Conociendo vCenter Log insight

Que tal gente, el día de hoy les voy a hablar sobre un producto que VMware liberó en un estado beta y que en este punto se encuentra de manera gratuita y abierta para su prueba, vCenter Log Insight. Este producto llega a cubrir un área de oportunidad en VMware que es la de tener análisis a nivel de logs, sabemos que contábamos en los días de vSphere 4 con el recolector de logs de la vMA (vilogger) o que en este tiempo podemos utilzar el syslog collector de vCenter Server… ¿Pero en realidad lo que queremos es solo “recolectar los logs”? ¿o queremos contar con un análisis avanzado de los mismos?. Si nos tomamos algo de tiempo para revisar la industria podemos notar que existen soluciones como Splunk que precisamente nos permite el análisis y recolección de logs a nivel de nuestra infraestructura es aquí donde queremos tener un producto 100% integrado con VMware para poder tener un análisis continuo, preciso y que sin importar la versión de nuestros productos funcione. Es por eso que VMware adquirió a través de Pattern Insight la tecnología para sentar las bases para este nuevo producto, que en este momento conocemos como vCenter Log Insight.

¿Que nos ofrece vCenter Log Insight?

Análisis de información provista por los distintos sistemas que estén enviando sus logs, este producto no se limita a VMware, estaremos revisando un concepto llamado “content packs” donde proveedores podrían ofrecer queries específicos para el análisis de sus productos. Podríamos estar hablando de las siguientes capacidades a grandes rasgos:

  • Análisis de información en tiempo real – se cuenta con la capacidad de realizar queries a la información que esta siendo almacenada en el momento en la base de datos de log insight
  • Definición de esquema en el momento – creación de queries personalizados con filtros y elementos específicos.

Screen Shot 2013-07-03 at 12.13.11 PM

  • Ejecución de queries en información no estructurada – la información que esta siendo almacenada no tiene un esquema definido notros definimos bajo que criterios será analizada.
  • Pensado para el análisis de un volumen de información muy grande (big data)

¿Como se instala y configura?

Algo bastante interesante de vCenter log insight es el hecho de su simplicidad, la instalación y configuración inicial es a través de un OVA:

Screen Shot 2013-07-03 at 12.41.26 PM

En este OVA seleccionamos el almacenamiento y variables de OVF como IP, DNS, subnet mask, etc. Una vez importada tenemos una VM funcional dentro de nuestra infraestructura

importada

Cuando nuestro appliance este listo solo necesitamos apuntar desde un navegador a la ip de este, para poder terminar la configuración:

Welcome

Aquí configuraremos credenciales de administrador,licencia, notificaciones NTP (¡100% BASICO! por timestamps):

NTP

Por último tenemos otras dos configuraciones muy importantes, la integración con VMware (vC y vC Ops) y data archiving:

integracion

Bastante interesante la funcionalidad de “launch in context”

que nos permite desde vC Ops (vC Ops 5.7.1+) analizar un objeto y poder realizar un query directamente a Log Insight

Screen Shot 2013-07-02 at 11.18.45 AM

Data archiving nos permite retener información por mas tiempo, debido a que la información “viva” o en la cual podemos

realizar un análisis estará siendo almacenada dentro de la base de datos, la información mas “vieja” estará siendo exportada

hacia este repositorio de NFS donde será comprimida y podremos importarla en el caso que se requiera un análisis de la misma

Una vez terminada la configuración es necesario un reinicio y con eso tendremos nuestro sistema arriba y funcionando:

listo

en este caso solo registré vCenter Server por lo que nos falta algunos pasos para poder terminar la configuración, al menos en mi laboratorio requiero monitorear los servidores ESXi.

Lo primero es cambiar el password del usuario root, para esto abrimos una consola y accedemos a la línea de comando:

login

Donde ingresaremos las credenciales “root” y de password solo un enter (password vacio), con esto podremos cambiar el password de root. Una vez listo vamos a utilizar una herramienta llamada “configure-esxi” que nos permite configurar el servidor de syslog de manera masiva para todos los servidores ESXi que esten siendo gestionados por una instancia de vCenter server, claramente esta no es la única opción, podemos realizarlo a través del vSphere client, vSphere Web client, Powershell, esxcli etc etc… pero este es el método mas sencillo desde mi punto de vista. Necesitamos ingresar los siguientes comandos:

cd opt/vmware/bin   –> cambiamos el working directory a donde se encuentra la herramienta

./configure-esxi -u (ususario) -s (vcenter) -t (server de syslog)

comando

Algo extraño, tal vez un bug sucede en el momento que configuramos syslog para nuestros servidores ESXi… si nosotros queremos confirmar que el servidor de syslog fue correctamente configurado desde el vSphere Web client o el vSphere client no veremos ningún servidor, pero podemos verificar que efectivamente esto esta listo a través de la herramienta de configure-esxi con el switch “-q”

query

Una vez listos nuestros servidores ESXi podemos analizar la información que es enviada a nuestro sistema de Log Insight:

hosts-dashboard

Integración con vCenter Operations

Como les comenté podemos integrar vCenter Log Insight con vC Ops para poder crear alarmas a partir de datos no estructurados, es decir, podemos realizar un query a la información que esta almacenada en la BD de vCenter Log Insight y a partir de ella crear una alarma que sea enviada a su vez a vC Ops cada vez que se encuentren los criterios y el esquema definido en la información que va siendo recibida, vamos a revisar un ejemplo para la creación de una alarma a partir de latencia a nivel de storage:

Screen Shot 2013-07-03 at 1.52.26 PMEn la imagen podemos ver un filtro de información para poder obtener latencia a nivel de SCSI

Screen Shot 2013-07-03 at 1.55.41 PMAquí podemos ver la creación del esquema a partir de la información que se nos esta mostrando

Screen Shot 2013-07-03 at 2.02.12 PMEn esta imagen podemos ver la creación de una tabla a partir de un máximo y un grupo de dispositivos, esto después lo estaremos convirtiendo a una “alarma” o notificación a nivel de vC Ops

Screen Shot 2013-07-03 at 2.05.26 PMEstas alarmas se verán reflejadas directamente en vC ops

Screen Shot 2013-07-03 at 2.07.24 PM

¿Que son los Dashboards?

Algo bastante interesante es la capacidad que tenemos de compartir ciertos grupos de gráficas e información especifica, en el caso de vCenter Log Insight tenemos algunos dashboards incluidos que son provistos por el content pack de vSphere (explicaremos mas adelante que es un content pack) como lo podemos ver en la imagen:

Screen Shot 2013-07-03 at 5.39.49 PM

El concepto de dashboard nos da la capacidad de poder crear conjuntos de gráficas a partir de queries con información relevante para nosotros o para el grupo de admins de vSphere, lo interesante es que podemos compartir estos dashboards para que sean de uso público o podemos tener dashboards privados:

Screen Shot 2013-07-03 at 5.45.13 PM

Es interesante saber que esto permite a terceros el integrar análisis de sus propios productos con información especifica obtenida a partir de  querys realizados a los logs que son enviados a vCenter Log Insight. Crear un dashboard es bastante sencillo, aquí podemos ver el ejemplo para agregar un dashboard o crecer uno existente:

Screen Shot 2013-07-03 at 6.05.14 PMNos vamos a “interactive analysis” y ahí creamos un query para obtener la info que necesitamos, en este caso pueden ver que agregue dos elementos, el nombre de un host y que contuviera “error” para todo el tiempo que se ha monitoreado. Hacemos click en la esquina superior izquierda “add to dashboard”:

Screen Shot 2013-07-03 at 6.12.33 PMAquí podemos agregar el análisis de información y la gráfica a un dashboard existente o podemos crear un nuevo dashboard, que incluso podemos compartir con mas usuarios con acceso a vCenter Log Insight:

Screen Shot 2013-07-03 at 6.14.56 PMUna vez creado podemos encontrarlo en el menú de “dashboards” en la pantalla principal.

¿Que son los content packs?

Screen Shot 2013-07-03 at 8.49.45 PMLos content packs son un conjunto de queries que se entregan con el fin de analizar la información recolectada, en el caso de la versión beta de vCenter Log Insight contamos con el content pack de vSphere claramente provisto por VMware para poder analizar ciertos componentes clave. Los content packs pueden incluir:

  • Queries
  • Alertas
  • Dashboards
  • Extracciones de información a partir de campos clave

Como usuario podemos crear nuestro propio content pack, básicamente es exportar todo nuestro contenido:

Screen Shot 2013-07-03 at 9.04.03 PM

Dimensionamiento y consideraciones

  • El appliance virtual de vCenter Log Insight tiene como recursos iniciales 2 vCPUs y 8GB en RAM con 144GB en disco duro de los cuales 100GB están pensados para almacenar la información que le es enviada. En la siguiente tabla podemos encontrar algunos lineamientos para el dimensionamiento según la carga que presentará el appliance virtual:

Screen Shot 2013-07-03 at 9.20.36 PM

El calculo del almacenamiento que necesitamos lo podemos obtener de la siguiente manera:

calculamos la cantidad de tiempo que estaremos almacenando la información vs la cantidad de host (ver tabla), por ej. 100 hosts ESXi = 15GB aprox de almacenamiento si la queremos almacenar 7 dias sería:

15*7=105GB (esto es la cantidad de espacio para almacenar los datos de manera “raw”)

después debemos considerar temas como en índice otro tipo de metadata de dicha información por lo que multiplicaremos la cantidad requerida de espacio para almacenar dichos datos en forma “raw” o cruda por 1.6:

105*1.6=168GB

Considerando que el appliance virtual tiene un espacio dedicado de 100GB por default para el almacenamiento de datos al menos deberíamos agregar 68GB extras.

Agregar espacio de disco duro es tan simple como apagar el appliance virtual, agregar un nuevo disco, encenderla y el LVM de linux reconocerá el disco y lo agregará al grupo de LVM.

  • Otra consideración importante es la autenticación en esta versión solo es LOCAL (no se soporta AD, LDAP,etc.)
  • No se cuenta con clusterización en esta versión por lo que la única manera para poder escalar es agregando recursos al appliance virtual o agregando varias appliances virtuales y distribuyendo la colección de los entre estas (de manera manual).