18 de septiembre de 2012

Nueva temporada de Kukudrulu

Empezamos este año con muchas ganas en Kukudrulu. Vamos a hacer 2 podcast mensuales, uno con noticias y otro monográfico (el próximo será de voz IP).

Aquí tenéis la URL si queréis escuchar el podcast 1 de la nueva temporada en la que comentamos las noticias de este último mes:

http://www.ivoox.com/kukupodcast-2x1-noticias-iphone-5-mas_md_1433621_1.mp3

Han participado:

Asier Padilla
Ramón Erkiaga
Pedro Jorge Viana
David del Prado
José Mª Socas, Cachi,
Nasi Nandes
y un servidor.

Espero que os guste!!


11 de septiembre de 2012

Consulta técnica: Blade vs servidores independientes, Backup en virtual y sistema físico de backup.

Mi colega Rafael, desde Barcelona, me formula la siguiente consulta técnica:

Hola Josep, voy leyendo tu blog y la verdad que me parece muy interesante. Quiero aprovechar esta oportunidad que nos das de lanzarte consultas.

Tan solo una consulta sobre infraestructura; actualmente estoy planteándome diseñar una infraestructura de virtualización en la que correrán 3 servidores virtuales a partir de 3 servidores físicos que convertiré y con la posibilidad de crear nuevas máquinas virtuales donde ir creando actualizaciones de los ya existentes, en casi todos los diseños veo que se recomiendan servidores independientes contra cabinas de almacenamiento, yo me planteo el uso de un servidor tipo blade como puede ser un Modular Server de Intel, donde tengo posibilidades de crecer en servidores, en almacenamiento y el conexiones, todo ello bajo VMware Essential plus.


Supongo que el utilizar estas infraestructuras será totalmente recomendable, aunque para el tema de la copia de las máquinas que me recomiendas, ..el uso de una cabina NAS y en cuanto al software cual me recomiendas. dado que tampoco estamos hablando de muchos servidores.


Muchas gracias de antemano.


Gracias Rafael por el seguimiento del blog. Muy agradecido.

Veamos, separaremos tus cuestiones en tres:

1. Recomendación de Blades vs servidores independientes.

2. Backup de entornos virtuales.

3. Sistema físico para backup.

1. Blade vs Servidores Independientes.

Sobre la primera cuestión, siempre me he mostrado partidario de los servidores independientes. Sólo recomendaría blades por comodidad en entornos muy grandes donde el crecimiento sea exponencial o la acomodación de los administradores de sistemas haga que sea recomendable estos sistemas.

En un entorno como el que planteas que empezáis con 3 máquinas virtuales, fruto de P2V y que vais a crecer yo empezaría con dos servidores independientes, con mucha RAM (tanta como para soportar todas las VMs y que te sobre) y una buena cabina. Probablemente en 4 ó 5 años no tendrás que tocar esos hosts y los podrás ir actualizando en las futuras versiones 5.1, 6, etc de vSphere cómodamente.

Por contra si se tiene un blade puede resultar perfectamente que éste sufra un problema o que haya que actualizar el firmware y reiniciar todo el sistema, con lo que adiós utilidad de vMotion.

Siempre recomiendo invertir el dinero en la cabina, pues al final, es el elemento crítico de la infraestructura, si se tienen servidores independientes. Mira que tengas una cabina que soporte muchos discos, que el crecimiento de la misma no sea una soberana hostia en toda la cara, etc. La tendencia actual es a utilizar discos de 2,5" y 10K, pero mayor número, con lo que podemos superar incluso las IOPS de los discos de 15K. Por otra parte ampliar un disco de una cabina de, pongamos 600GB SAS 10K no tendría que suponer más de 350€ aproximadamente + IVA. Mira también que tengas una buena respuesta del servicio técnico y que no te manden un vídeo con la URL de cómo se cambia una controladora.

Mira también si usas iSCSI o Fibra. Dependiendo del número de usuarios y del tipo de aplicaciones que tengáis os recomendaría utilizar uno u otro. Si utilizáis AX, SAP, etc. y sois más de 200 usuarios utiliza fibra. Mira que la cabina sea combo (iSCSI + fibra).

2. Backup para entornos virtuales. La versión 5.1 de vSphere Essentials Plus lleva un sistema de protección de máquinas virtuales que integra las tecnologías de Avamar, de EMC y parece que va a ser muy superior que las versiones anteriores. Te sugeriría que lo probases y, tal vez, te puedas ahorrar la solución que te voy a recomendar.

Desde la versión 1.0, fui de los primeros en recomendar Veeam backup. Siempre me ha resultado una solución magnífica. Permite hacer backup y réplica de las máquinas virtuales. Tener una réplica significa tiempo de restauración 0. No tienes que tirar  de cinta, pues Veeam Backup sólo soporta disco. Puedes tener tantos pasos atrás en las réplicas y los backups como espacio de almacenamiento tengas.

Procura siempre tener una copia de seguridad alejada de la empresa. Bien utilizando sistema de cinta o NAS portable, bien contratando un backup en la nube.

Es fácil de utilizar y las versiones enterprise tienen restauración granular de active directory, exchange y sql.

En cualquier versión tienes restauración de la VM completa, un disco, una carpeta o un archivo. Un producto muy interesante que se licencia por socket físico.

3. Sistema físico para backup.

Y finalmente para copia de seguridad te recomendaría idealmente una SAN con suficiente espacio en disco para hacer réplica completa por hardware y, además, tener un espacio donde lanzar los backups con el Veeam Backup, por aquello de que la réplica no es backup.

Como eso suele salir muy caro la solución recomendada para la mayoría de escenarios es implementar una NAS. Estamos recomendando últimamente QNAP que salen muy bien a nivel técnico y son muy robustas. Hay soluciones de 4, 8, 12 y 16 discos SATA de 2TB. Por poco precio puedes tener mucho espacio de backup donde tener todas vuestras réplicas y muchos puntos de restauración.

Espero que te hayan sido de utilidad las respuestas. Espero tus comentarios en el blog.

Un abrazo,

10 de septiembre de 2012

Trabajar en Ncora es duro...

Empezamos la segunda temporada de Ncora.TV y hemos hecho este vídeo de promoción para que os riáis un rato.

Venimos con las pilas cargadas y vamos a hacer un montón de cosas: vmworld, eventos, diálogos en el paraíso! Vamos a topeeee!! :-)

Problemas de actualización con Rose Mirror HA

Mi colega Andrea, desde Ecuador, me formula esta consulta sobre réplica contínua con Rose Mirror HA:

Hola Josep,

Te saluda Andrea desde Ecuador, encontré tu blog y me pareció muy interesante.

Tengo una consulta, trabajo en una empresa con una base de datos muy grande y contamos con dos servidores un principal y otro backup, en caso de que falle uno usamos el rose mirror para que realice el switch ahora bien aqui va mi duda, tenemos que hacer una actualización del software y firmware y quisiera saber cual es el riego que corro al hacer la actualización primero en el backup mientras el principal funciona y luego mediante el rose cambiar de backup a principal para actualizar el principal.

Ya nos sucedio que en la actualización anterior el rose no funciono al momento de hacer el siwtch y nos quedamos sin sistema, lo que ahora queremos hacer es para el sistema es decir apagar los dos servidores realizar uno por uno la actualizacion y luego encender los dos...

Crees que es aconsejable parar el sistema para que realicemos la actualizacion

Por que crees que haya fallado el rose anteriormente

Espero puedas ayudarme

Saludos

Andrea

Muchas gracias Andrea por seguir el blog, espero que te pueda ayudar durante mucho tiempo.

Los programas de Continous Data Protection (CDP) como con Rose Mirror HA o Double-Take HA son geniales. Permiten tener dos sistemas replicándose de manera contínua incluso a miles de kilómetros de distancia y, en caso de caída de un sistema, se puede producir el cambio, más o menos automatizado al sistema pasivo.



Estos sistemas son bastante simples de instalar, muy fácil es de mantener, pero cuando hay que actualizarlos hay que andar con sumo cuidado, pues no entienden mucho de si lo cambios que se están produciendo son voluntarios o involuntarios.

Mis consejos serían 2:

1. CDP no es backup. Claramente si tenemos un error en origen, ese error se traslada de forma inmediata al destino y nos quedamos con un sistema inutilizado en extremo y extremo. Por tanto, además de la réplica contínua, debemos hacer backup de nuestros sistemas.

2. Seguir las mejores prácticas en el upgrade. Estos sistemas son muy delicados de actualizar. Mi consejo es que miremos con detenimiento las instrucciones del producto y sigamos esos procedimientos meticulosamente, siempre con backup por si el procedimiento está mal o tiene errores. Normalmente tendremos que detener la replicación contínua. Actualizar el sistema en origen (activo) ver que funciona correctamente, actualizar el sistema pasivo (aún sin la réplica contínua en funcionamiento), volver a configurar el sistema y, finalmente, activar nuevamente la réplica continua.

Espero que te sea de utilidad mi respuesta. Espero tus comentarios en el blog.

Un abrazo,

7 de septiembre de 2012

Consulta sobre redundancia en vSphere

Mi colega Òscar Sales, de Riudecanyes, en Tarragona, me formula esta consulta sobre redundancia en entornos vSphere:

Hola Josep,

Me llamo Òscar  y estoy trabajando en un proyecto de implantación de un Cluster de virtualización VMWare. Soy seguidor de tu blog, y te estoy muy agradecido porque me ha servido de mucha ayuda para entrar en el mundo de la virtualizacion.

Aprovechando tu sección de consultas que tienes en el blog, quería plantearte una duda que me ha surgido al intentar crear "NIC Teaming con 2 switches físicos", a ver si me podrías orientar.

Dispongo de:

 - Un Cluster vSphere5 de 2 Hosts (ESXi1, ESXi2)
 - Licència VMware Essentials Plus
 - Dos switches físicos, (de momento uso unos baratillos para probar, mas adelante quiero adquirir los hp 1910 16G)

El objetivo es:

 - Redundancia a nivel de NIC (Si una NIC deja de funcionar, las VMs deben continuar comunicándose a través de la otra NIC del Team)
 - Redundancia a nivel de Switch físico (Si uno de los 2 switches cae, las VMs deben continuar comunicándose a través del otro Switch)

El Escenario es el siguiente:

 - Host ESXi1
   * El adaptador físico (pNIC2) va conectado al switch físico (pSwitch1)
   * El adaptador físico (pNIC3) va conectado al switch físico (pSwitch2)
   * Standard vSwitch (vSwitch1) con la vmnic2 y vmnic3 mapeadas
   * PortGroup utilitzado por las VMs


 - Host ESXi2
   * El adaptador físico (pNIC2) va conectado al switch físico (pSwitch1)
   * El adaptador físico (pNIC3) va conectado al switch físico (pSwitch2)
   * Standard vSwitch (vSwitch1) con la vmnic2 y vmnic3 mapeadas
   * PortGroup utilitzado por las VMs

Configuración del vSwtich en los ESXi:


Configuración del PortGroup en los ESXi:




Comportamiento conseguido:

* Una VM que està en el ESXi1 puede comunicar (haciendo ping) con una VM que esta en el ESXi2, si uno de los dos switches cae, no se pierden pings y continúan comunicándose a través del otro switch. Esto es correcto. (Redundancia a nivel de switch)

* Si desconecto el cable de red de la pNIC2 del ESXi1, el ESXi1 pasa a enviar los paquetes a través de la pNIC3 hacia el pSwtich2, pero el ESXi2 continua teniendo como activa la pNIC2 que esta conectada al pSwitch1, por lo que pierdo los pings (No tengo redundancia a nivel de NIC).

La duda és: Podría obtener esta redundancia a nivel de NIC en este escenario, para evitar que si deja de funcionar una NIC las VM's continúen comunicándose?. 
Solo dispongo de 2 NIC físicas por Host disponibles, ya que las otras 2 (pNIC0 y pNIC1) las tengo conectadas a otro switch físico de otra subred.

Si es posible y me pudieras orientar un poco en como podria conseguir este comportamiento, te estaría muy agradecido.

Muchas Gracias

Òscar Sales
Riudecanyes - Tarragona

Muchas gracias Òscar por el seguimiento del blog y me alegro que te sirva de ayuda.

Aunque lo que me indicas en las pantallas es correcto, creo que el problema lo tienes con la configuración de las NICS físicas.

Repasa la configuración y mira que el vSwitch tenga los diversos nics físicos en Full, tal como se indica en esta imagen:



Muy probablemente lo tengas en stand by, tal vez así:




Revisa también la configuración del teaming dentro del virtual machine port group par que tenga una apariencia similar a esta:



De hecho, si no has tocado nada en la configuración del virtual switch, tal como se crea por defecto, el vSwitch ya hace el teaming con las diversas tarjetas físicas. Así tienes que poder sacar el cable de cada una de las nics y, siempre que haya una, la comunicación no se debe perder.

También puedes hacer un uplink entre los dos switchs físicos de la red, con un cable RJ45 cat 6. Así seguro que te tendría que funcionar.

Ya nos contarás!

Un abrazo!