Archive for March, 2010

Quedarán en el tiempo los largos procesos de compra de tecnología enlatada?, los días, meses y semanas de preparación para e upgrade de ese firewall que corre en un hardware cerrado?, la espera de esa memoria para el filtro anti-spam que también vive dentro de un equipo físico cerrado?… Cómo podría esto ser posible?.

Creo que para todas estas preguntas que me hago hay una respuesta afirmativa y que todas apuntan hacia los Virtual Appliances que están ganando terreno en las infraestructuras tecnológicas de grandes empresas todos los días. Ya explicamos lo que son los appliances virtuales pero para refrescar un poco el concepto un appliance virtual no es otra cosa que una máquina virtual que corre un sistema operativo y sobre este una aplicación previamente instalada la cual deberá ser simplemente configurada de acuerdo a las necesidades del cliente que la esté utilizando. El concepto es más que interesante y pero para que la idea cierre un poco más tendremos que ver los beneficios que estos appliancces nos entregan:

Reducción de tiempos de implementación

 Luego de muchos años de trabajar en proyectos de tecnología puedo decir que en muchos casos en un proyecto de implementación de ciertas tecnologías la instalación (no habló de configuración) pueden llevar una porción importante del tiempo de puesta en marcha. Los virtual appliances resuelven estas demoras ya que en su gran mayoría tienen sus aplicaciones instaladas o bien el sistema operativo es la aplicación en si. Este concepto aplica también para pruebas de concepto donde estemos evaluando productos nuevos a implementar.

Reducción en los tiempos de entrega

 Firewalls, proxies de internet y  aceleradores de redes wan entre otros son entregados generalmente como appliances físicos los cuales se deben desembalar, encender y comenzar a utilizar. Excepto que el proveedor tenga estos equipos en stock tendremos que esperar un tiempo considerable en la entrega del mismo. Para el caso de los virtual appliances esto es completamente distinto ya que una vez ingresada la orden de compra y el pago de la misma ya tenemos a la descarga del appliance virtual reduciendo considerablemente los tiempos.

 Actualización de hardware instantánea y mejorada

 En el caso de los appliances físicos estándar el hardware de estos tiene un tiempo de soporte determinado generalmente en un plazo de entre uno y tres años. Esto nos lleva a tener que planificar que cada cierto período de tiempo tendremos que interrumpir el servicio que el dispositivo presta para realizar el cambio u actualización del hardware junto con la migración de los datos de un equipo al otro en caso de ser necesaria. Debido a la naturaleza de la virtualización y a la capacidad de gestionar los recursos de hardware prácticamente de forma instantánea los problemas de actualización de hardware se ven reducidos casi a cero.

 Recuperación ante desastres simplificada

 La preparación de un plan de recuperación ante desastres debe contemplar la puesta en marcha de al menos los servicio críticos para la organización en un sitio remoto en el menor tiempo posible siguiendo los requerimientos del negocio. Si en nuestra infraestructura tenemos appliances de red físicos tendremos que pensar en tener el ambiente de estos duplicado en el sitio secundario lo cual desde el punto cero de diseño del plan nos presenta costos agregados a los de la infraestructura de servidores y estaciones de trabajo.  Los appliances virtuales también resuelven este punto dado que pueden ser contemplados en el diseño del plan como un servidor más que deberá ser replicado o copiado al sitio alternativo.

 Reducción de los costos CAPEX

 Debido a que un appliance virtual no es otra cosa quer un conjunto de archivos que conforman una máquina virtual uno tiende a pensar que los costos no deberían ser los mismos que los de un appliance físico. Si bien esto es así, hoy en día los vendors no se resignan a bajar demasiado los precios de sus appliances virtuales. Personalmente creo que esto tiene un solo motivo… Los vendors nos solo obtienen ingresos del software que viene en los appliances físicos sino también del hardware "especializado" en el que vienen.

 El empuje al software open source

 Existe otro punto interesante de los appliances virtuales además de los beneficios expuestos anteriormente y es el de el disparo de la adopción del software open source o de código abierto gracias a esta tecnología. Los que tenemos algunos años en tecnología sabemos que en la mayoría de los casos las corporaciones miran de reojo al software open source simplemente porque en muchos casos la instalación de este tipo de software requiere que la persona que la realice tenga conocimientos de compilación de software o base de datos que no son ni Oracle ni Microsoft SQL y la simple idea de que esta persona se ponga a aprender estas cosas y luego aprender la herramienta no aplica a los tiempos cada vez más cortos de time to market. Si en lugar de perder todo ese tiempo descargamos el appliance y lo encendemos para comenzar a utilizar la herramienta el panorama se torna mucho más alentador.

Muchas empresas están aprovechando los beneficios de los virtual appliances y un caso particular es el de Vyatta que desarrolla routers y firewalls open source y presentan sus soluciones en appliances físicos y virtuales, teniendo estos últimos una gran aceptación en el mercado gracias a que sus appliances virtuales encajan perfectos en escenarios con redes virtualizadas y de cloud computing. En los próximos años tendremos cada vez más appliances virtuales en nuestras infraestructuras nos guste o no la idea siempre y cuando los vendors disminuyan sus precios y comiencen a cumplir con las obligaciones de Green IT impuestas por las regulaciones. Estos son solo algunas ideas sobre los beneficios de los appliances virtuales pero hay más muchos más. Usaste un virtual appliance alguna vez? Cuál fue tu experiencia?

Nicolás Solop

Únete al grupo de virtualización en español en LinkedIn

En algunos casos los archivos de configuración de las máquinas virtuales (archivos de extensión .vmx) se corrompen o en otros casos algunas manos mágicas los eliminan. Si tenemos la suerte de que nuestros archivos de disco (archivos de extensión .vmdk) siguen donde deberían podemos realizar los siguientes pasos para que volver a la vida a nuestra máquina virtual:

1. Ingresar a la infraestructura virtual con un usuario con privilegios de administrador

2. Hacer clic derecho sobre uno de los servidores ESX

3. Dar clic sobre Create New Virtual Machine

4. Clic sobre Custom Virtual Machine

5. Seguir todo el procedimiento hasta llegar a la ventana donde pide seleccionar el disco

6. Dar clic sobre Use Existing Disk y buscar en los datastores el archivo .vmdk indicado

7. Continuar con el procedimiento hasta finalizarlo

Luego de esto podremos encender la nueva máquina virtual y tendremos todos los datos de la anterior disponibles.

Espero les sirva.

Saludos,

Nicolás Solop

Únete al grupo de virtualización en español en LinkedIn

Emprender el viaje de la virtualización del datacenter es un de los proyectos que hoy más disfrutan los CIOs de las compañias que han elegido ir por dicho camino.

Mucho se ha hablado de los beneficios de la virtualización tanto para el negocio como para IT en si misma, pero poco se habla de como percibe el usuario final dicho cambio. En este caso particular no estoy hablando de la virtualización de desktops sinó más bien de la virtualización de los servidores que alojaban sus aplicaciones de negocio. Luego de 5 años virtualizando datacenters me he encontrado que el usario final percibe de manera favorable el cambio realizado.

Ventaja # 1 …el sistema carga mas rapido…

Podemos  asegurar que los sistemas migrados a ambientes virtuales pasan de estar en una infraesctructura de hardware legacy a equipos de ultima generación con procesadores y caché de características muy superiores. Dichos sistemas dejan de experimentar latencia o falta de ciclos de cpu y responden mejor.

Ventaja # 2… el sistema permanece menos tiempo caído…

Dos motivos están asociados a esta visión del usuario, el  primero está directamente relacionado a la casi desaparición de pantallas azules por falla de hardware, el segundo está asociado a la alta disponibilidad que provee HA.

Ventaja # 3 … el tiempo de entrega de un servidor es mucho menor…

Queda claro que hacer deploy de una maquina virtual es mucho mas rápido que encargar el hardware, esperar que llegue, instalarlo, segurizarlo y ponerlo en linea. El usuario nota la gran diferencia de start up en nuevos proyectos de la empresa. Ahora la excusa deja de ser la demora de IT en proveer el server y ahora el problema lo tienen los usuarios para organizar rápidamente su proyecto.

Ventaja # 4 … es mas económica una máquina virtual que una física para el centro de costos del sector…

Muchos proyectos departamentales se encuentran frenados por la falta de presupuesto para ponerlos en marcha. Muchas veces los proyectos son iniciativas propias de los empleados en tratar de hacer un poco mas amigable su trabajo, ej: utilizando un file server para compartir documentos, un servidor de documentación al estilo sharepoint o un software de seguimiento de proyectos, etc… El costo de una VM es 3 veces menor a uno físico para un departamento lo cual termina siendo una diferencia realmente importante.

Ventaja # 5 …mejora en el tiempo de atención de los incidentes…

La virtualización genera una baja imporante en la cantidad de incidentes asosciados a la infraesctructura de IT, lo que permite que los incidentes más complejos de los usuarios puedan ser escalados a nivel 2 de la empresa con mayor facilidad y ser resueltos en tiempos más cortos. Este ejemplo no es menor dado que cambia enormemente la vieja y negativa percepción del usuario que se sentía mal atentido para ser reemplazada por una nueva percepción mas favorable y reconocida.

Conclusión

El CIO de una compañía que decide virtualizar su datacenter debe saber que no solo es una cuestión de números y de simplicidad a la hora de gestionar su infraestructura, sinó que va más allá, es una decisión estratégica que tiene un impacto directo en la percepción de usuario final, siendo esta en la gran mayoría de los casos, muy favorable.

Enfrentando una actualización de equipamiento y sumado a que estaba trabajando en preparar una serie de documentos sobre optimización y performance sobre vSphere, he necesitado realizar sucesivas tareas de VMotion en nuestra granja de ESX (8 servidores corriendo vSphere 4 Enterprise Plus) y me he encontrado con la necesidad de aumentar la cantidad de VMotions simultaneos que podía hacer el vCenter.

Cuando o porque configurar esta opción?, si tenemos un DRP en linea, les aseguro que esta puede ser una excelente ocación.

Para ello hay que recordar que si desean realizar este Tweak al vCenter, deberán tener en cuenta que tienen que tener configurado al menos dos placas Gigabit en Etherchannel o conexión a 10 Gpbs, también será ideal conocer algo sobre networking sobre VMware.

El motivo?.  Utilizar ese tipo de configuración será la unica forma real de poder sacar verdadero provecho de multiples vmotions dado que la demanda de red es realmente alta. Es así como también es  recomendado habilitar JUMBO FRAMES para las placas involucradas en el VMkernel portgroup.

• Ahora bien, para empezar, deberán ingresar al vCenter.
• Abrir el archivo vpdx.cfg ubicado en  - C:\Documents and Settings\All Users\Application Data\VMware\VMware VirtualCenter -
• Editar las siguientes lineas

<ResourceManager>
<maxCostPerHost>16</maxCostPerHost>
</ResourceManager

• Salvar los cambios
• Tipear en START > RUN > SERVICES.MSC
• Reiniciar el servicio -VMware VirtualCenter Server -
• Listo, ya está configurado el vcenter para soportar hasta 4 VMotions en simultaneo.

Ahora bien, que es ese 16 ?, la respuesta la da VMware, la ponderación que se realiza en vCenter para utilizar la funcion Migrate se encuentra definida del 1 al 4, siendo 1 la migración en modo COLD, y el 4 en modo HOT (o sea VMOTION).

Para soportar 4 Vmotions en simultaneo multiplicamos (4 vmotions) x ( 4 tareas) = 16 (valor final en el archivo vpxd.cfg).

De esta manera su virtual center está preparado para realizar mas de un vmotion en simultaneo, ahora bien pueden configurar este parametro hasta poder optimizar la maxima velocidad que su red les permita, Tengan principal consideracion en separar el trafico y segundo separar las NICS FISICAS si es que optan por valores superiores a 4.

Si necesitan una mano, no duden en consultarnos.

Saludos

Ing.Diego Quintana

VCP310-VCP410-VAC-VTSP

Tal como dice el refrán, una imagen vale más que mil palabras, mas aún si hablamos de una imagen real capturada de un centro de cómputos donde implementamos VMware Sphere 4 y View.

Acostumbrados a ver las presentaciones de VMware donde hablan de la gran densidad de maquinas virtuales por core, o sobre la magia del overcommit de memoria, creo que es bueno compartir una captura de pantallas de un escenario de la vida real donde se alcanzan ratios de 56 a 1 sobre ESX 4 utilizando INTEL Xeon 5540 (Nehalem) sobre un Proliant BL460c G6.

Las máquinas virtuales corren windows XP  con 1vCpu – 1GB de memoria Ram y la infraestructura de virtualización sobre servidores blades.

Para alcanzar los ratios antes descriptos es necesario realizar el dimensionamiento adecuado y diseñar la solución considerando cada uno de los componentes de la misma, Storage, Networking, Seguridad y su administración.

Sin lugar a dudas hoy VMware es el líder en su segmento y con este tipo de imágenes queda claro el porqué.

No es novedad que el cloud computing llegó y revolucionó la manera en que hacemos nuestros trabajos diarios ya sean relacionados con tecnología o en otros sectores de cualquier organización. Todas estas novedades que trae aparejado este nuevo concepto de infraestructura también nos llevará con el tiempo a reducir considerablemente nuestros activos tecnológicos en mayor o menor medida.

Cuántas pequeñas empresas hoy en día tienen sus servicios de correo electrónico y colaboración alojados en los servidores de Google utilizando sus servicios gratuitos o los servicios pagos? Reformulando la pregunta… Cuántas empresas grandes están utilizando los servicios de colaboración de Google?. Muchas y el número no para de crecer.

Ahora si hacemos un recorrido básico de los servicios que podemos obtener en la nube suscriptos a los servicios de Google como ser correo electrónico, un file server para almacenar y compartir archivos, un servicio de calendario, una agenda compartida, un servidor web podemos determinar que unos cuantos de estos servicios requieren por lo menos un servidor para ejecutar su tarea (un servidor por servicio y no discutimos si usamos o no virtualización).

Si fuesemos los dueños de estas empresas usuarias de los servicios de la nube tendríamos que salir a comprar hardware, software, acondicionar el espacio físico para alojar estos equipos y contratar personal para realizar la operación diaria de los mismos o por lo menos tener un contrato con un proveedor para que la ejecute. Todo esto (menos el servicio de operación) requiere en la mayoría de los casos un desembolso de dinero importante de antemano que para muchas empresas start-up y para muchas pymes también escapan de sus presupuesto punto que los servicios de cloud computing resuelven de manera muy elegante ya que solo tendríamos que desembolsar nuestros consumos mes a mes.

No todos los casos son como el anterior pero si representan a la mayoría de las pequeñas y medianas empresas con las que me fui cruzando con el tiempo y creo se beneficiarían notablemente con este tipo de soluciones.

Para las empresas un poco más grandes y que tienen mayores requerimientos tecnológicos la posibilidad de alojar sus servidores en la nube tiene el mismo beneficio pero le tenemos que sumar el costo de la operación de la plataforma de servicios propia (no de los da la nube) ya que esto no los podemos evitar.

Volviendo al tema de la idea de ser dueños de una pequeña empresa y para ir cerrando el concepto… Gartner hizo público un estudio el cual demuestra que para el 2012 el 20% de las startups americanas no contarán con activos tecnológicos propios (servidores, centros de cómputos, etc). Como pensamiento personal… si los proveedores de servicios de cloud computing toman un fuerte impulso en la región, bajan sus costos, y logran apuntar también a las pymes van a permitir que muchas empresas hagan foco en su negocio y dejen en un segundo plano las preocupaciones por los servicios en los que este se apoyan.

Nicolás Solop.

Únete al grupo de virtualización en español en LinkedIn

Cisco anunció hoy la disponibilidad del  nuevo routers CRS3 (Carrier Routing System) diseñados para soportar las demandas actuales de internet como las transmisiones de video en tiempo real, como así también los requerimientos futuros de los nuevos servicios online de esta década y las futuras.

Este nuevo router presenta una capacidad 12 veces superior de trabajo con respecto al equipo más cercano en capacidad de la competencia y 3 veces más que su predecesor de la misma marca está pensado para las comunicaciones de banda ancha y los nuevos requerimientos de entretenimiento como de video on demand cada vez más populares.

Detalles del equipo:

• Escalable con una arquitectura multi-chasis el Cisco CSR3 permite procesar hasta 322 tbps lo cual nos permitiría descargar la biblioteca del Congreso de los Estados Unidos en menos de un segundo y permitir que todo China haga video conferencia en simultáneo.

• Diseñado para trabajar de forma óptima, este equipo no solamente puede encaminar los paquetes a las rutas necesarias sino que además de esto puede hacer uso de las nuevas tecnologías multi-direccionales pudiendo determinar el camino más corto a un contenido determinado mejorando el impacto sobre la red y la experiencia del usuario.

• Todo estas funcionalidad consumen solo el 40% de la energía consumida por el modelo anterior, el CSR1, que puede ser modificado para transformarse en un CSR3 protegiendo las inversiones realizadas.

De acuerdo al anuncio de prensa del lanzamiento del Cisco CSR3 el costo del equipo es de U$D90.000 (ya veremos cuanto sale en LATAM).

Nicolás Solop

Únete al grupo de virtualización en español en LinkedIn

El pasado primero de Febrero de 2010, nuestros amigos de xtravirt (empresa dedicada a virtualización) publicó de forma gratuita su plugin de microsoft remote desktop (RDP) para vmware vsphere client.

Por más trivial que parezca, el plugin es sumamente útil para aquellos administradores que día a día utilizan más de 50 o 100 máquinas virtuales y tienen que tomar control remoto de ellas para administrarlas.

El principal motivo para utilizar este plugin es justamente que acceder por el modo consola en VMware no es una de las mejores practicas sugeridas por VMware dado que  consume una importante cantidad de recursos en las másquinas virtuales y en el service console del ESX, ni hablar si hay varios administradores conectados y olvidan las sesiones de consola abiertas.

Por otro lado nos agiliza las tareas del día a día evitando tener que abrir dos o tres aplicaciones para gestionar nuestros servidores.

Sin lugar creo que será una tendencia creciente la de incorporar pequeños plugins que nos facilitaran un poco la existencia.

En esta Nota, enumeramos los puertos que se necesitan disponibles para la infraestructura de VMWare View y la virtualización de Estaciones de Trabajo.

Para permitir la conexión de clientes Externos a un Security Server que se encuentra dentro de una DMZ, el Firewall Front-End debe permitir el tráfico entrante de los siguientes puertos TCP:

También, como es de imaginarse, se necesitan habilitar los puertos para la comunicación entre los Servidores View Connection que están en la red interna.

Los puertos necesarios para habilitar el tráfico de entrada son:

En caso de utilizar las políticas de USB Redirection y MMR, habilitar tambien los siguientes puertos para RDP:

USB Redirection: TCP:32111

MMR: TCP:9427

Cortito y conciso! Justo lo que buscás, los puertos para habilitar y que tu infraestructura de Desktops virtualizadas funcione.

Saludos!

Los servidores blades han experimentado una importante evolución desde sus comienzos. Allá por el 2003 los servidores blades empezaban a hacer auge y las compañías mas cercanas a la innovación eran las primeras en adoptarlos, bajo una gran desconfianza en términos de compatibilidad futura, pero con gran entusiasmo por ser pioneros en la implementación de dicha tecnología.

HP Blade C7000 Chasis

Bien, en esa época IBM también comenzaba a hablar de su Datacenter on demand, una idea muy buena pero con poca visibilidad en Argentina, más aun cuando su principal competidor HP vendía mas Blades que quien promulgaba el on demand como su principal estrategia para el datacenter corporativo. En conreto y en esas epocas, adquirir tecnología blade era sumamente caro y si el CIO intentaba realizar un calculo de retorno de inversión, este prácticamente era viable si el cajón de blades estaba lleno, caso contrario seguía siendo una buena opción comprar equipos slim rackeables.

En principios del 2004 un pequeño vmware pero con aires de grandeza, se empieza a ver instalado en los servidores de IBM, HP y DELL. Ese pequeño tardará poco tiempo en volverse el eje central de todo datacenter de mediano y gran tamaño.

Y volvemos a los blades, que eran caros, pero el paso del tiempo, la maduración de la tecnología y  el cambio de las reglas de juego lo volvieron mucho más atractivo, un chasis de blades básico puede estar USD 1500 e incluso depende el volumen hasta pueden regalarlo, lo cual cambia enormemente las reglas de juego.

El retorno de inversion en los blades ya se ve a partir de 5 hojas o cuchillas, entonces, equipar el datacenter con blades es una buena opción?, sin lugar a dudas si, pero no para todos los casos.

La principal excusa de porque no virtualizar el Datacenter con Blades

Hace 2 años atrás dos especialistas de un carrier  internacional cuestionaban el uso de blades por la falta de escalabilidad en networking, a lo que contesté, – sin lugar a dudas todo depende de como se diseñen y como se calcule la demanda de del servicio que se da – , la realidad también es que ese carrier tenía un acuerdo corporativo con un vendor que no se jactaba de tener blades dignos para el mercado, también es por ese motivo que ellos no podían elegir blades dado que el único vendor al que podían comprarle realmente no los satisfacía y con justa razón.

Entrando en detalle, la realidad es que lo que ellos decían estaba bien, la vieja generación de blades daba poca escalabilidad en términos de networking, y los vendors lo detectaron rápidamente, solo por citar un ejemplo HP por medio de su virtual connect y Flex 10 están permitiendo escalar hasta 32 placas de red en una sola hoja de blade, entonces la respuesta hacia a aquellos especialistas se ha modificado notablemente, hoy no tenemos excusas, los blades son la solución.

Empezando de Cero, como pensar la solución con blades.

Listemos los 9 aspectos fundamentales en una solución de virtualización:

IBM Blade Center

1. Proposito
2. CPU
3. Memoria
4. Red
5. Disco
6. Energización
7. Dinero 

1 – PROPOSITO – Para que utilizaremos la tecnología de virtualización? es para Servicios de Datacenter de un ISP, es para servicios propios ?, es para VDI (virtualización de Desktops) ?. Definir cual es el propósito marcará un punto importante en la definición del SLA, costos de la solución y en el diseño de la arquitectura de Networking. Pensemos que el manejo de vlans en vmware es muy completo y puede ser un punto importante a considerar, más aun para los ISP

2- CPU – La tecnología de cpu es vital, pensando que queremos dar una densidad elevada de maquinas virtuales por CPU, tenemos que considerar. Hoy podríamos citar que por experiencia en distintos ambientes de gran magnitud, los INTEL NEHALEM entregan una razon de 8 maquinas virtuales de carga baja por CORE. EL numero es elevado, o sea una buena noticia para nuestro ROI. Entonces si consideramos poner 2 Procesadores HEXA CORE, hablamos de 12 CORES, lo que hace a un total de 96 maquinas virtuales. Ojo, no todo es Alicia en el país de las maravillas, estos son valores teóricos pero muy cercanos a la realidad.  De llegar a lograr esa densidad van a tener que tener muy ajustados otros parámetros más allá de la CPU. También tengan en cuenta variables como el FSB, la caché de los procesadores elegidos, etc.

3. MEMORIA – Hoy las tecnologías de Blade están permitiendo valores superiores de 128 GB de RAM, claro, estos pueden costar más que un departamento   pero eso no viene al caso,  lo importante es que si buscamos darle la máxima densidad de Virtual Machines por Hoja,  hoy están soportando un valor considerable. ESX hoy admite hasta 1 TB de Memoria dado que ya vSphere 4 corre sobre una arquitectura de 64 bits nativa.

Las maquinas virtuales, consumen en promedio entre 1 a 2 GB de memoria Ram, haciendo uso de memory overcommit en VMware podemos reducir ese valor hasta casi un 50 %, con lo cual seguimos sumando puntos a favor para llegar a convertir el ROI en algo más que aceptable. En general las soluciones de blade de alta densidad están haciendo uso de hasta 96 GB de ram dado el alto costo que implica seguir sumando memoria, dado que en ese caso resulta más barato y performante agregar otra hoja con menos memoria que seguir subiendo en memoria el blade anterior.

3. RED – Diseñar el ambiente de red puede ser muy sencillo o extremadamente complejo. Todo depende que se quiere hacer. Básicamente si diseñaramos una solucion basada en VMware, se podría decir que a nivel networking tendríamos que tener al menos 2 placas para el Port Group de service console, 2 placas para VMkernel donde estará VMotion y Fault tolerance, al menos 2 placas para Payload o carga de VMs, y si usáramos ISCSI, recomendaría otras dos placas más. Si uno toma este ambiente, puede llegar a requerir desde mínimo 6 placas pasando por 8 o más en el caso ideal.  hoy en día una solución promedio de blades contempla el uso de al menos dos switches en la parte trasera del chasis, generalmente la cantidad de switches que están conectados en la parte posterior le agrega mayor cantidad de placas de red a cada hoja (ej: con dos switches se pueden tener 4 placas de red en cada hoja de blade), dependiendo la tecnología usada por el fabricante se puede escalar a numeros mayores.

Generalmente los switches traseros se interconectan entre sí brindando a nivel horizontal y por un uplink a nivel vertical, lo que ofrece alta disponibilidad a nivel de red. También se suelen linkear entre chasis de blades, evitando que el trafico salga al core ( exceptuando el trafico que requiere ser ruteado).

4. DISCO – En términos de disco, no hay grandes secretos, si o si la recomendación es salir a una SAN o una red ISCSI. Particularmente soy un optimista respecto del ISCSI, me parece muy performante, poco costoso y muy confiable (ver soluciones como lefthand, falconstor,openfiler) aunque la mayoría de redes que llevo instaladas son sobre FC.

Es un requerimiento para tener HA, FT y VMotion tener un storage compartido y la verdad es que para Blades, tenerlo afuera es mejor. El unico storage recomendado son apenas dos discos sata para raid 1 donde instalar – por ejemplo – el ESX.

5.ENERGIZACION – El aspecto de consumo es vital. Las soluciones de blades de baja gamma no requieren mas de 10 A, pero en otros casos requieren hasta trifasica. Muchos datacenters están al limite de consumo energético, y conectar un chasis de blades los lleva casi a pasar ese limite. Más aun cuando el proceso de migración de todos los servidores físicos puede durar unos meses. Las soluciones de blades tiene la característica de tener rendundancia en todas sus fuentes y fans, de manera de que ninguna falla de power impida del normal funcionamiento del chasis. Existen soluciones que compensan las fallas de hardware, por ejemplo si una turbina de refrigeración falla, el resto aumenta automáticamente la velocidad para compensar la falta de una de ellas.

6.DINERO – Frente a presupuestos ajustados, optar por blades no siempre será la mejor opción, dado que requiere de acompañar toda la solución de una SAN y probablemente si se necesitan menos de 5 servidores, la solución puede que nos quede algo grande.

Sin embargo, utilizar blades cuando se requiere reducir espacio, bajar el consumo energético, consolidar y virtualizar, esta es hoy en día la mejor opción. Tengamos en cuenta que en un rack de blades con 12 hojas, mas storage, podemos estar colocando casi 600 maquinas virtuales. Imaginen el espacio y consumo que estas tendrían si fueran fisicas? o que costo de mantenimiento de hw tendrían?. En ese caso, la cuenta cierra, y les aseguro que con un ROI de 2 años.

Conclución

No quedan dudas que la tecnología de blades está madura, incluso que supera enormemente en escalabilidad a muchas soluciones tipo rackeables. También quedó demostrado que bajo un diseño adecuado, no hay limitantes en términos de networking, storage , memoria y procesador. Incluso también aprendimos que superando cierta cantidad de equipos, la reducción de costos es verdaderamente tangible.

Todo esto nos pemite pensar que hoy en día el Blade ya es la plataforma elegida para la mayoría de empresas que optan por virtualizar y consolidar, sabiendo que es posible escalará aun más, siempre asegurando la disponibilidad y performance.

Yo por mi parte no lo dudo, hoy elijo virtualizar sobre blades.

Saludos,

Ing. Diego Quintana