vSphere 4.0: Mis razones para... (I)

Con este post que tenía a medio hacer hace bastante tiempo comienzo una serie (que prometo terminar) sobre mi particular percepción respecto a vSphere 4.0. Como remarco en el título, lo aquí recogido es mi opinión personal (y por tanto profesional) sobre vSphere 4.0. Los lectores de este blog (si aún me queda alguno después de mi dejadez) son libres de estar o no de acuerdo, y espero que ejerzan esta libertad opinando al respecto. Empecemos:

... No implementar VMware FT en producción:

Sí, leeis bien. Todo un vExpert desaconsejando VMware FT en producción. Como muchos sabéis, Vmware FT permite la ejecución en simultáneo de dos máquinas virtuales haciendo exactamente lo mismo, es decir, una actúa como sombra de la otra en otro host distinto. A priori esto suena bien: si cae un host, la VM sobreviviente recoge la carga de la primera sin impacto para los usuarios. La pregunta es si merece asumir las limitaciones que impone FT para evitar 30 segundos de pérdida de servicio. Mi respuesta es que depende. FT no te va a proteger de una corrupción de datos, ni de la pérdida de los mismos. Si el servicio que nos interesa se cae en la VM primaria, también se caerá en la máquina "shadow". FT no garantiza más que la operación de una VM (ojo que digo VM, no servicio) en caso de caída del host que la aloja. No con esto quiero quitar méritos a FT: Como obra de ingeniería es impresionante. Como medida de continuidad del servicio no deja de ser un paso más. FT puede transmitir la falsa sensación de que se ha elevado el nivel de servicio, y quizá en algunos casos lo haga, haciendo que el responsable de sistemas baje la guardia. No creo que por el momento implemente FT en bases de datos críticas o servidores de correo: La penalización de una única CPU y el desaprovechamiento del nodo donde se ejecuta la VM "espejo" no compensan, al menos, por el momento. Nada como una buena replicación de log de transacciones en una base de datos, a ser posible diferido, como para garantizar la disponibilidad.


... Implementar los vNetwork Distributed switchs: Bonding, load balancing, MACs, etc... Demasiados términos que suenan propios de los chicos de networking. Los distributed switches (en especial el Nexus 1000v de Cisco) acercan a los responsables de networking a un área de la virtualización que, hasta ahora, consideraban extraña: los switches virtuales. Con los Distributed Switches el networking virtual es, por fin, networking, y puede caer en las manos de quien mejor lo controla: La gente de red. Para bien o para mal la virtualización ha caido en la parte de sistemas, olvidando que una parte fundamental del entorno virtual es la red. Ahora este aspecto del entorno virtual se vuelve amigable para los chicos de la red.

... Implementar DPM (si deja de ser experimental): En grandes proyectos de virtualización, el consumo eléctrico tiene su peso. Si a las ventajas inherentes a eliminar toneladas de hierro le añadimos que el hierro con el que virtualizamos también consume lo justo... miel sobre hojuelas.

Paro por el momento.

Un saludo.

Para Javier.

No hace mucho, recibí este comentario en este blog al que, últimamente, he de reconocer que no presto la atención que debiera. Lo reproduzco porque creo que tiene valor para todos nosotros.

"Hola.He caído por aquí, como quien no quería la cosa, por un comentario de David Cervigón en su blog. Ya estás en mis favoritos.Lo que me impulsa a escribirte es que me has hecho reflexionar en mis pensamientos negativos que últimamente he tenido. Estoy en una empresa de tamaño pequeño (hablando de IT) de la automoción, y ya ves cómo está el patio últimamente en ese sector. Ahora estoy en un ERE, con lo que me toca "descansar" 2 días a la semana. Como consecuencia de eso, mi actitud está siendo la de "que les dén...", vamos, que me da igual lo que pase, que se caigan servidores, que haya problemas en la red, etc. He intentado "jugar" un poco con la virtualización (Hyper-V, vmWare ESXi, ...) pero en 3 días no saco mucho tiempo, sobre todo si hay que mantener el resto del negocio y de las tareas habituales, y si no hay presupuesto.Por eso lo de la reflexión. Me ha gustado tus comentarios, lo del no tener miedo, no preocuparse de los dineros, sino planear qué hace falta y meterse a ello. No es que me vaya a cambiar la vida, pero bueno, has conseguido al menos despertar algún pensamiento positivo en mi cabeza. Espero al próximo miércoles, cuando vuelvo al trabajo, para empezar a planificar y poner en marcha algunas de esas ideas / proyectos / pruebas que desde hace tiempo he querido hacer.Gracias,Javier."

La nuestra es una profesión ingrata. Nadie se acuerda del informático, sea técnico o director, salvo cuando las cosas fallan. Esta profesión requiere de cierta actitud personal para superar la desidia o indiferencia del resto de la compañía. Cuando todo funciona, somos los privilegiados, normalmente fuera de convenio, que ganamos más pasta que los demás. Cuando las cosas fallan, somos los mantas que no hacemos bien nuestro trabajo. Llevo ya unos cuantos años en esto y sé lo duro y difícil que resulta a veces este trabajo. Sé lo angustioso que resulta tener que tomar decisiones sabiendo que no tengo todos los conocimientos o la información necesaria para tomarlas (Todos hemos dudado ante un "Este proceso es irreversible. ¿Está Ud. seguro de continuar?"). Todos hemos dejado horas de sueño, y algún que otro impacto más o menos dañino en nuestra vida personal, por hacer que algo funcione. Todos hemos llorado, para dentro o para fuera, cuando no conseguíamos que algo funcionase tras horas o días de intentarlo.

Entiendo a Javier, igual que entiendo a otros compañeros que, tras partirse la espalda, se encuentran con un ERE, un traslado indeseado, una subida de sueldo que consideran inmerecida, o un ascenso a un tercero que creen merecer.

La vida es básicamente injusta. Es una frase que me gusta decir. Pero creedme que, cada vez que consigo que algo que falla funcione, cada vez que añado una funcionalidad nueva a un sistema, cada vez que cumplo una fecha estimada en un proyecto, me siento orgulloso de haber elegido una profesión ingrata como esta, independientemente de lo que cobre o no por hacerlo.

Esta es una profesión para ser humilde. Para aprender de todos. No de todos los que saben más que nosotros. De todos: desde el becario que llega, pasando por el usuario que se nos queja, siguiendo por nuestro jefe, y acabando por el externo al que han contratado para que nos ayude. Lo importante no es tener razón, sino que las cosas funcionen, gracias o a pesar de nosotros.

Quizá alguno piense que hablo desde una posición privilegiada. Hoy en día quizá ya no toco la tecla como antes, pero sigo siendo, y me sigo sintiendo técnico. Y me guardo mi pequeño hueco de pinchateclas resuelveincidencias. Porque es lo que he sido siempre, y espero no dejar de serlo. Porque me costó mucho llegar a serlo.

No, no somos héroes, pero quiero pensar que cada uno de nosotros se va a la cama cada noche pensando que ha hecho lo mejor que ha podido.

Alguien que conocí una vez, hace muchos años, me dijo: "J. o esto te gusta o estás jodido".

Por suerte, después de veinte años, me sigue gustando.

Un abrazo.

PD. He de reconocer que este post no es sólo para Javier. Hoy nuestra gente ha terminado de montar nuestra infraestructura de test y pruebas en nuestras nuevas oficinas. Son seis servidores Dell T605 donde ejecutamos las nuevas versiones de los hipervisores y nuevas configuraciones y productos que hay en el mercado, en parte como autoformación, y en parte como evaluación para alguno de nuestros clientes. El "CPD" de desarrollo y evaluación de nuestra compañía está en un cuarto de baño reconvertido, donde nuestra gente ha conseguido meter estás máquinas (y su electrónica de red, SAI's y demás aditamentos) después de un impecable trabajo de evaluación de infraestructuras (espacio físico, disipación de calor, etc, etc). Nuestros sistemas de producción están hospedados fuera de la oficina (con producción me refiero a los internos, entornos demo para clientes y alguna que otra cosilla que ya os contaré). Han trabajado duro para conseguirlo. Han metido horas que nadie les va a pagar. Pero hoy, cuando han terminado (y creedme que han empleado soluciones realmente creativas), sonreian satisfechos. Vaya por ellos también. Me siento orgulloso de este equipo de profesionales.

¿Oracle buenos días?

Así me respondía esta mañana uno de mis contactos en SUN... evidentemente el anuncio por sorpresa de hoy da pié a este tipo de bromas. Contra todo pronóstico (al menos de los gurús del sector), una empresa de Software como Oracle adquiere un fabricante de Hardware como SUN. No hace mucho comentaba con otro de mis contactos en SUN que lo de que les comprara IBM no tenía buena pinta. No puedo imaginar otro interés en SUN por parte de IBM que los clientes de la primera. Resultaba trágico pensar que SUN Microsystems, con su peculiar (correcta o no) manera de hacer las cosas terminara fagocitada por el Gigante Azul.... y mira como son las cosas, el mismo gigante que empezó vendiendo hierro y ahora también tiene software, se encuentra con su némesis inversa: Un tradicional fabricante de software que termina metiéndose a vender hardware. Evidentemente a IBM poca gracia le debe hacer esto: Ni su hardware (y de paso las ventas del mismo) son lo que eran, ni su software ha sabido salir del nicho hardware de la compañía.

Parece que Oracle ha acertado: Unido a su imponente motor de base de datos, toma el control de Java, se deshace de MySQL (que empezaba a cosquillearle por los bajos), y se posiciona en el mercado del hardware con una tecnología avanzada (tanto en el mundo SPARC como en el x64).. y voilá!!... ¿Sólo esto? No. VMware debería poner sus barbas a remojo: Tanto SUN como Oracle demuestran interés en el mercado de la virtualización. SUN con VirtualBox, un hypervisor de tipo 2, y un (ya muy retrasado) xVM, clon de Xen que promete.... junto con una plataforma de gestión completa. Por otro lado, Oracle también hizo sus pinitos (Gracias al gato del CEO de Oracle, que escribe hypervisores cosa mala) con un repintado Xen y una incipiente plataforma de Gestión. Ahora las dos grandes preguntas son:

¿Estaremos ante el tercer gran player en esto de lo virtual?
¿Cuánto se va a pagar por Citrix?

Un saludo.

¡¡Cómo anda el patio!!

Cisco comienza a vender servidores (ya os contaré que tal), IBM, HP y alguno más deja de vender equipamiento Cisco en la línea Blade. IBM amenaza con comprar SUN y resulta que queda en nada.

Cisco decide meterse en el fregado de servidores con la excusa de que no encuentra un "fabric server" adaptado a sus necesidades..... y de paso se quita el estigma de salir al mercado de servers y almacenamiento  de mano de un tercero ( Algunos ya sabéis que si queréis comprar un conmutador Fiber channel para vuestra fastuosa SAN debéis pedírselo al fabricante de la misma, no a Cisco).

A este revuelo se añada vSphere 4.0. Para muchos quizá sólo sea una nueva versión: Para otros resulta ser toda una incursión de VMware en el mundo de las infraestructuras. Partiendo de la base de que el Nexus 1000V de Cisco puede comportarse como una tarjeta más del Nexus 5000 de Core, la cosa va cambiando. El VMware Fault Tolerance (VMware FT) supondrá un enorme cambio en la concepción de el alta disponibilidad: Básicamente compite con los clusters de Microsoft y de Symantec/Veritas. De último llueven las estadísticas sobre rendimiento, certificando que, en la inmensa mayoría de los casos, la penalización del hypervisor no supone un inconveniente para los entornos de producción... o dicho de otra manera, esto de lo virtual resulta que mola.

Y aún habrá más. Este año será crítico en cuanto a las tecnologías de dentro del CPD. Más competidores (no deéis de poner el ojo en Windows Server 2008 R2 o en las siguientes versiones de XenServer).

Añadid a lo que os cuento la presíon presupuestaria que vivimos: Nos aprietan desde arriba para reducir los costes. Y no sólo a los que trabajáis en cliente final, también a nosotros los que os vendemos cosas. Este año, y probablemente el que viene, serán los de la creatividad y la revisión de lo que hemos hecho hasta ahora.

Dejo estas opiniones a vuestra reflexión.

Un saludo.

IT en tiempos de crisis

Aunque este post se salga un poco de lo habitual en este blog, una conversación que tuve en la sobremesa de ayer me ha hecho reflexionar sobre la oportunidad de escribirlo.

Todos sabemos que estos tiempos son tiempos de recortes. El que más y el que menos habrá recibido indicaciones, más o menos directas, sobre la conveniencia de contener y recortar los presupuestos, tanto de gasto como de inversión (OPEX y CAPEX que dicen los anglosajones), de su departamento de IT. Tampoco es un secreto que, a bote pronto, hay dos grandes partidas donde la tijera amenaza con ejercer: Personal y proyectos.

La partida de personal suele verse afectada (y ya lo está siendo en algunas grandes empresas) por la parte de subcontratación. Todos sabemos que, en la mayor parte de las grandes empresas (motor de la inversión IT por otra parte) la práctica totalidad del personal técnico (y con esto me refiero a los que administran y operan los servidores) son externos. En algunas, las partidas en este concepto han ido creciendo en estos años de bonanza económica como respuesta al incremento en complejidad y número de sistemas y aplicaciones que el negocio ha demandado. 

En lo referente a proyectos ocurre más o menos lo mismo. Las inversiones propuestas el año pasado (renovación de parque, ampliaciones, actualizaciones) se consideran, de pronto, prescindibles en un entorno empresarial preocupado por la caja.

Básicamente, al requerimiento de "Más (o al menos lo mismo) por menos" se tiende a recortar en estos aspectos.

En estos tiempos, el peor enemigo del presupuesto IT es el miedo al cambio. El no implementar tecnologías por el miedo infundado al impacto en el entorno IT. Como dijo alguien a quien respeto enormemente, nos pagan para asumir riesgos. Y forma parte de nuestro trabajo el evaluar los riesgos tanto técnicamente como económicamente, y decidir si son asumibles. Y mi experiencia a ambos lados de la mesa (como cliente final y como consultor) me dice que si como profesionales nos dejamos llevar por el "si funciona no lo toques", uno, tarde o temprano dejará de funcionar, y dos, alguien vendrá a exigirnos cuentas de nuestras decisiones no tomadas. Como ejemplo, miremos los downgrades de entorno Host a entorno Wintel: Muchas compañías no lo hicieron por miedo infundado a que un servidor Wintel no pudiese ser tan buen servidor web como un AIX o un Solaris. Otras investigaron, evaluaron y migraron. El tiempo ha demostrado que las segundas, apostando por la evolución del mercado, han conseguido mantener unos presupuestos IT más acordes a los tiempos.

Dicho esto, mi conclusión: Invertir en tecnologías que suponen reducción de costes a corto y medio plazo (de 1 a 2 años) es la mejor manera de, por un lado, hacer más por menos, y por otro, mantener el nivel de servicio e integridad de nuestras estructuras.

¿En qué reducir costes?, evidentemente la pregunta no tiene una respuesta genérica, pero dejadme apuntar algunas respuestas:

• Infraestructuras: Espacio en el CPD que tenemos alquilado. Reducción de consumo eléctrico en nuestro CPD. Reducción o paralización de las ampliaciones de aire acondicionado. Reducción de los requerimientos de remote hands en los servidores del datacenter.
• Red: reducción o eliminación de los planes de ampliación de los puntos de red. Decomisión de electrónica de red sin uso o potencialmente descartable y eliminación de los contratos de mantenimiento.
• Mantenimiento: Eliminación de servidores fuera de garantía, eliminación de excesos en máquinas y electrónica fuera de garantía. 
• Almacenamiento: Selección de nuevas tecnologías, uso de deduplicación, eliminación de SAN fuera de garantía, reducción de la infraestructura Fiber channel.
• Copia de seguridad: Búsqueda de alternativa a la cinta. ¿externalización?, reevaluación de las políticas de copia de seguridad (¿podemos sobrevivir sin un full diario?)
• Política de compras: Evaluación de nuevos proveedores (tanto de servicios como de hardware), modificación de los estándares de compra. Racionalización de las compras.
• Informática de usuario: Limitación de nuevas adquisiciones de PC's, soluciones de informática centralizada.
• Racionalización de las inversiones y renovaciones en seguridad y gestión de sistemas: No eliminarlos... racionalizarlos.
• Organización departamental: Gestión del equipo humano, gestión efectiva del conocimiento. Reasignación de funciones.
• Análisis en profundidad de la relación entre IT y el Negocio: Idoneidad de las soluciones aportadas. Análisis del ratio coste/beneficio en las mismas. 
• Creatividad: ¿Qué puede aportar IT al Negocio (y no hablo de migrar a Windows Vista, a la última versión del antivirus o a poner un logo de la compañía en el explorer)?
• Plan de choche de mejoras inmediatas: Diseñar un plan de choque que mejore la percepción de IT y/o aporte medidas claras de contención de coste a negocio.

Supongo que a ninguno de vosotros os toma esto de sorpresa. Ahora sólo falta ir a por ello. Dejemos el miedo a lo desconocido a un lado y empecemos a pensar por nuestra cuenta, usando nuestros conocimientos y capacidad. Cuidado con los informes de costes de Gartner y demás: La contabilidad americana no es la española, ni los costes e inversiones se manejan de la misma manera. El "lo bueno viene de fuera" quizá tenga sentido respecto a algunas tecnologías, pero este país tiene memorables casos de reducción de costes que merece la pena estudiar.

PD. ¿Os habéis dado cuenta de que no he nombrado la virtualización ni una sola vez? 

Un saludo.

¿Qué significa para mí ser VMware vExpert?

Como anunció VMware, el hecho de ser nominado vExpert no implica que el nominado sepa más que nadie, o que simplemente los nominadores piensen que sabe más o es mejor que nadie. No ha sido la intención de VMware (y que conste que no hablo en su nombre) discriminar a nadie.

Para algunos, el vExpert es el merecido reconocimiento de VMware a una labor de "evangelización" y/o comunicación en todo lo referente al mundo de la virtualización, eso sí, centrado en sus productos.

En mi caso particular, lo considero un reconocimiento a casi diez años de pelea contínua intentando demostrar que esto de convertir PCs o Servidores en programas tiene sentido. Aún recuerdo cuando recibí el correo de VMware, allá por 1.999 en el que me anunciaban que me dejaban ser betatester de VMware Workstation. Aún recuerdo como me impresionó ver abrirse un Windows 95 en una ventana de mi RedHat 4/5. En ese momento supe que esto de la virtualización (Los PCeros, en aquel momento no sabíamos ni cómo se escribía la palabra en cuestión) me iba a gustar. Como buen teki (Técnico para el resto de los humanos) me dejé arrastrar por lo que atraía mi atención.

Pasó el tiempo, y por aquel 2001 cayó en mis manos el VMware GSX. Aquello ya era más serio: No se montaba como aplicación, sino ya como servicio. Me duró un mes, hasta que empecé a tocar ESX 1.0. Creo que la primera instalación en semi-pre-producción en este país la hice yo (admito divergencias sobre este punto)... Y mis ojos volvieron a brillar cuando conseguí que un IBM xSeries 440 arrancara el ESX y levantara máquinas virtuales. Seguía teniendo la misma mirada incrédula que allá por el 99.

Quien me conoce desde hace años sabe como empecé: Programando Cobol y ensamblador en un Phillips 3500. De ahí pasé a sistemas (Lo siento, el desarrollo siempre me aburrió mucho), y de sistemas, a Comms... Chico Cisco. Por estas cosas de la vida (y de la empresa donde trabajaba) tuve que implementar un directorio activo para un gran cliente, así que tocó estudiar. Y durante un tiempo me dediqué a proyectos Microsoft.... hasta que un día encontré mi hueco y me centré en la virtualización de lleno. Durante todo el tiempo previo siempre usé máquinas virtuales, hasta el punto de hacérseme incómodo el trabajar con máquinas físicas. Costó mucho convencerme a mí mismo de que aquello era apto para producción (para bien o para mal conozco ambos lados de la tecnología: El lado del que la vende y el lado del que la explota). Costó muchas pruebas y mucho  tiempo: Sólo en el 2003 me atreví a "meterle" ESX en producción a un cliente. Eso sí, fué un Oracle 8, con 2000 usuarios conectados..... porque el cluster físico se había caído. Y cuando el ESX pudo con ello, volví a sonreir incrédulo.

¿Y sabéis una cosa? Hoy, después de unos cuantos ESX montados, después de todos los proyectos en los que he tenido la suerte de participar... después de evangelizar, tanto fuera como desde este blog.. aún me sorprende ver un Windows 2003 arrancar dentro de un ESX.

¿A qué viene este rollo que os suelto? A que, en cierta manera, la nominación (el "award" que dicen los americanos) es una recompensa (yo lo considero así) a todo ese tiempo, a todo ese esfuerzo.

No diré que no me considero merecedor del "Award". Totalmente al contrario. Y de todas las medallas, chapas y/o certificaciones que pueda tener, esta es de las más preciadas.

Un saludo.

Congratulations! You have received a VMware vExpert Award!

Vaya con el correo que se me coló en la carpeta del Spam:

"Congratulations! On behalf of VMware, we would like to thank you for all the work you’ve done giving back to the virtualization community and sharing your expertise with others. We are pleased to present you with the VMware vExpert Award for 2009. VMware is giving this award to individuals who have contributed significantly to the community of VMware users over the past year.

 

VMware vExpert award winners will receive:

* An award certificate and gift

* Access to a private vExpert community

* vExpert logo to display on website or email signature

* Free subscription to conference session materials on VMworld.com

* Access to exclusive online events and other opportunities to participate in activities

* Inclusion in public vExpert directory

The vExpert award duration is one year (through February, 2010)."

He de reconocer que encontrarme en la misma lista que monstruos de esto de lo virtual como Scott Herold, Eric Siebert o Eric Sloof, entre otros, le infla a uno el ego (si no lo tenía ya suficientemente inflado)

Por último, agradeceros a los que me habéis nominado el haberlo hecho.

Un abrazo.