Sobre el comentario de Sauron a "Virtualizar: ¿Qué, Cómo, Cuándo y Dónde?". Siempre hay algo que no se puede virtualizar, al igual que siempre hay algo que requiere 4 procesadores y no funciona con dos. En un mundo perfecto, las aplicaciones .NET están bien diseñadas y los query SQL perfectamente estructurados, lo que nos permitiría - en ese mundo perfecto - virtualizar prácticamente todo. Pero el mundo en que vivimos está lleno de código .NET ineficiente, de querys SQL que hacen que nuestras 230 tablas de esa base de datos de 8 Gb se muevan todas al unísono en el mejor estilo lambada. En este mundo, muchas veces el código está como está, y no se puede cambiar (problemas insalvables de coste, tiempos o de simple ego del jefe del proyecto del desarrollo). En esos casos, virtualizar, como mínimo, sólo nos servirá para darle una excusa más al desarrollador para tachar nuestros sistemas de poco potentes. Recordad que, salvo honrosas excepciones, el dogma de muchos desarrolladores dice algo así como que la capacidad de proceso es infinita y la memoria también. Tened en cuenta que si algo vá lento en un flamante servidor físico, irá igual (o peor) en uno virtual. Si el servidor que aloja vuestro exchange tiene una cola de peticiones a disco de aquí a finisterre, virtualizarno tal cual está no va a arreglarlo. Si vuestro pontetísimo servidor de dos vías las tiene ambas al 100%, así seguirán cuando lo hayáis virtualizado. Si vuestro SQL server se come los 4 Gb de RAM del servidor donde se encuentra ahora, se los seguirá comiendo. Virtualizar reduce costes y mantenimiento... los milagros, para la wish list de ESX 10.0
Yo he visto cosas que vosotros no creeríais. Aplicaciones multiusuario con bases de datos multigiga puestas en Access más allá de Orión. He visto a desarrolladores .NET afirmar que un doble opteron con 8 GB de RAM es poca máquina para una base de datos SQL de más de 4 Gb cerca de la puerta de Tannhäuser. Todos esos momentos se perderán en el tiempo, como lágrimas en la lluvia. Hay que pensarse tranquilamente lo de virtualizar. Nada como una buena evaluación de rendimiento de las aplicaciones a virtualizar antes de virtualizarlas. Herramientas no faltan: Analizadores de queries para SQL, profilers .NET, optimizadores para Exchange, etc.
Un saludo.
Mostrando entradas con la etiqueta Exchange. Mostrar todas las entradas
Mostrando entradas con la etiqueta Exchange. Mostrar todas las entradas
lunes, 19 de marzo de 2007
sábado, 10 de marzo de 2007
Virtualizar: ¿Qué, Cómo, Cuándo y Dónde?
Bueno, aparte del anónimo post sobre qué virtualizar y sobre qué, llevo una semana de disquisiciones filosóficas con compañeros y partners sobre este tema, así que voy a exponer mi opinión. (Por cierto, a los anónimos, dejad un correo o similar)
¿Qué virtualizar?
Creo que no es la pregunta adecuada: La virtualización no se aplica a productos, sino a entornos. Virtualizar un servidor web puede parecer una buena idea, pero si ese servidor es justo donde se ejecuta la aplicación .NET que no admite balanceo y tiene 2.500 usuarios, la idea deja de ser buena. Lo mismo aplicamos a Exchange, SQL server, Oracles, etc. Una vez monté un lab donde teníamos un Lotus Notes virtualizado en el que simulábamos una carga de trabajo de 250.000 mensajes por hora. Lo tuvimos en funcionamiento cinco días, lo que dá un total de treinta millones de mensajes procesados. ¿Pondría yo un servidor de producción con esa carga en VI3?... pues a lo mejor si, pero previo desdoblaje del mismo en dos o tres VM, y balanceando carga. Respecto a Exchange... digo lo mismo. Si en nuestra instalación tenemos un sólo exchange haciendo de client access y de store, puer si, virtualizo, pero desdoblando funciones. Quizá montaría un Exchange para OWA, un SMTP y quizá un par de stores. ¿Tendrá más rendimiento? No necesariamente. ¿Funcionará mejor? Vamos... yo creo que sí. Si al servidor de storage groups le quitas el proceso adicional de cargar con clientes, es obvio que debería ir mejor.
Respecto a los DC... he escuchado de todo... desde que las diferencias de reloj producidas por la virtualización (¿?) afectan al dominio, hasta que las VM no dan potencia suficiente para un DC (más ¿?). Conozco directorios activos completamente virtualizados, y no por ello son menos eficientes. No sé porqué, pero veo la mano oculta de Microsoft cuando no tenía producto con el que competir en la propagación de estos rumores. Y puestos a rumorear, hay quien dice y afirma que Microsoft utiliza VMware ESX en sus departamentos de desarrollo....
La conclusión es que la cuestión no gira alrededor de la virtualización, sino del balanceo de carga de funciones sobre una determinada infraestructura.
¿Dónde virtualizar?
Parece que está de moda usar blades para ESX. Y yo, para no variar, no estoy demasiado de acuerdo. No me parece demasiado lógico utilizar un hardware que comparte I/O entre múltiples servidores para un sistema operativo que necesita un control exhaustivo del hardware para ofrecérselo a las máquinas virtuales. Se me ocurren unas cuantas razones para no pensar en blades para soportar VI3.
Versatibilidad.
El hecho de que la ampliación de un sistema dependa hasta en el menor de los aspectos de un determinado fabricante me hace recordar otros tiempos, y me plantea escenarios donde ESX soporte determinado hardware que el fabricante aún no haya (o haya decidido) no implementar. En estos momentos, donde VI3 aún tiene que mejorar cosas como el soporte iSCSI, atarse a un fabricante de blades que puede o no implementar HBA iSCSI o adaptadores TOE con soporte iSCSI (véase Alacritech), decidirse por una arquitectura absolutamente propietaria (como cualquier host IBM o SUN) me parece arriesgado. Por otra parte, el hardware de conectividad de los blades sigue siendo algo especialito. De acuerdo, hay fabricantes que incorporan switches ethernet y fibre channel de fabricantes reconocidos, pero... ¿os habéis pasado por las páginas de descarga de Cisco o Brocade? Esas "versiones específicas" siempre son pelín distintas... y no dejan de preocuparme esas "pequeñas diferencias" cuando hablo de ESX...
Rendimiento.
Otro tema es el rendimiento. Aún espero que algún integrador comprometido con los blades (no nombraré a nadie) me demuestre que, a igual configuración hardware, el blade dá el mismo rendimiento y escalabilidad (aspectos fundamentales en ESX) que una máquina independiente.
Impactos en el servicio.
Otro aspecto que me preocupa son los impactos en el servicio. Imaginemos que, en un cajón, hemos de actualizar el firmware del chasis, o el del módulo de switch giga que nos dá conectividad: Hay que parar de un tirón catorce máquinas.... Creo que con los problemas que me dá el tener que parar la SAN cuando tengo que hacer lo mismo ya tengo bastante.
Costes.
Pues no, tampoco me parecen tan baratos. Si, efectivamente, el coste del blade es sensiblemente inferior a la máquina de 1 U.... hasta que empiezas a sumar las fuentes adicionales, el dobre switch blade ethernet (¿o no tienen nuestras pizzas de 1 U múltiples puertos ethernet que conectamos a donde queremos?) El doble switch Fiberchannel.... creo que al final no salen tan baratos.
Entonces... ¿Porqué nos los ofrecen?
Razones no faltan. Al fabricante le interesan porque sus costes de soporte son inferiores, al integrador le interesan porque los fabricantes incentivan al canal para que los venda, e indiscutiblemente, hay quien los compra porque efectivamente, hay escenarios donde ofrecen ventajas indiscutibles.
Conclusión.
He instalado blades a lo largo de mi vida profesional: Granjas de servidores web, Granjas Citrix, aplicaciones ASP y .NET... y efectivamente para estas cosas tienen su aquel, pero en lo reference a ESX, sigo prefiriendo servidores independientes, y os recomiendo lo mismo.
Un saludo.
¿Qué virtualizar?
Creo que no es la pregunta adecuada: La virtualización no se aplica a productos, sino a entornos. Virtualizar un servidor web puede parecer una buena idea, pero si ese servidor es justo donde se ejecuta la aplicación .NET que no admite balanceo y tiene 2.500 usuarios, la idea deja de ser buena. Lo mismo aplicamos a Exchange, SQL server, Oracles, etc. Una vez monté un lab donde teníamos un Lotus Notes virtualizado en el que simulábamos una carga de trabajo de 250.000 mensajes por hora. Lo tuvimos en funcionamiento cinco días, lo que dá un total de treinta millones de mensajes procesados. ¿Pondría yo un servidor de producción con esa carga en VI3?... pues a lo mejor si, pero previo desdoblaje del mismo en dos o tres VM, y balanceando carga. Respecto a Exchange... digo lo mismo. Si en nuestra instalación tenemos un sólo exchange haciendo de client access y de store, puer si, virtualizo, pero desdoblando funciones. Quizá montaría un Exchange para OWA, un SMTP y quizá un par de stores. ¿Tendrá más rendimiento? No necesariamente. ¿Funcionará mejor? Vamos... yo creo que sí. Si al servidor de storage groups le quitas el proceso adicional de cargar con clientes, es obvio que debería ir mejor.
Respecto a los DC... he escuchado de todo... desde que las diferencias de reloj producidas por la virtualización (¿?) afectan al dominio, hasta que las VM no dan potencia suficiente para un DC (más ¿?). Conozco directorios activos completamente virtualizados, y no por ello son menos eficientes. No sé porqué, pero veo la mano oculta de Microsoft cuando no tenía producto con el que competir en la propagación de estos rumores. Y puestos a rumorear, hay quien dice y afirma que Microsoft utiliza VMware ESX en sus departamentos de desarrollo....
La conclusión es que la cuestión no gira alrededor de la virtualización, sino del balanceo de carga de funciones sobre una determinada infraestructura.
¿Dónde virtualizar?
Parece que está de moda usar blades para ESX. Y yo, para no variar, no estoy demasiado de acuerdo. No me parece demasiado lógico utilizar un hardware que comparte I/O entre múltiples servidores para un sistema operativo que necesita un control exhaustivo del hardware para ofrecérselo a las máquinas virtuales. Se me ocurren unas cuantas razones para no pensar en blades para soportar VI3.
Versatibilidad.
El hecho de que la ampliación de un sistema dependa hasta en el menor de los aspectos de un determinado fabricante me hace recordar otros tiempos, y me plantea escenarios donde ESX soporte determinado hardware que el fabricante aún no haya (o haya decidido) no implementar. En estos momentos, donde VI3 aún tiene que mejorar cosas como el soporte iSCSI, atarse a un fabricante de blades que puede o no implementar HBA iSCSI o adaptadores TOE con soporte iSCSI (véase Alacritech), decidirse por una arquitectura absolutamente propietaria (como cualquier host IBM o SUN) me parece arriesgado. Por otra parte, el hardware de conectividad de los blades sigue siendo algo especialito. De acuerdo, hay fabricantes que incorporan switches ethernet y fibre channel de fabricantes reconocidos, pero... ¿os habéis pasado por las páginas de descarga de Cisco o Brocade? Esas "versiones específicas" siempre son pelín distintas... y no dejan de preocuparme esas "pequeñas diferencias" cuando hablo de ESX...
Rendimiento.
Otro tema es el rendimiento. Aún espero que algún integrador comprometido con los blades (no nombraré a nadie) me demuestre que, a igual configuración hardware, el blade dá el mismo rendimiento y escalabilidad (aspectos fundamentales en ESX) que una máquina independiente.
Impactos en el servicio.
Otro aspecto que me preocupa son los impactos en el servicio. Imaginemos que, en un cajón, hemos de actualizar el firmware del chasis, o el del módulo de switch giga que nos dá conectividad: Hay que parar de un tirón catorce máquinas.... Creo que con los problemas que me dá el tener que parar la SAN cuando tengo que hacer lo mismo ya tengo bastante.
Costes.
Pues no, tampoco me parecen tan baratos. Si, efectivamente, el coste del blade es sensiblemente inferior a la máquina de 1 U.... hasta que empiezas a sumar las fuentes adicionales, el dobre switch blade ethernet (¿o no tienen nuestras pizzas de 1 U múltiples puertos ethernet que conectamos a donde queremos?) El doble switch Fiberchannel.... creo que al final no salen tan baratos.
Entonces... ¿Porqué nos los ofrecen?
Razones no faltan. Al fabricante le interesan porque sus costes de soporte son inferiores, al integrador le interesan porque los fabricantes incentivan al canal para que los venda, e indiscutiblemente, hay quien los compra porque efectivamente, hay escenarios donde ofrecen ventajas indiscutibles.
Conclusión.
He instalado blades a lo largo de mi vida profesional: Granjas de servidores web, Granjas Citrix, aplicaciones ASP y .NET... y efectivamente para estas cosas tienen su aquel, pero en lo reference a ESX, sigo prefiriendo servidores independientes, y os recomiendo lo mismo.
Un saludo.
Suscribirse a:
Entradas (Atom)