SMB en hyperv 2012. Configuración de VM no compatible.

SMB en hyperv 2012. Configuración de VM no compatible.

Hoy estaba configurando un cluster SMB con hyperv 2012 y me he encontrado con un error fruto de que ésta configuración la realicé hace unos meses y ya no recordaba el procedimiento exacto, por tanto paso a explicar la situación.

Objetivo:

En hyperv 2012 podemos tener un cluster de máquinas en almacenamiento compartido mediante SMB, es decir, podriamos tener una máquina que haga de servidor de archivos,  con un disco grande físico, compartirlo por SMB y luego meter ahí las máquinas virtuales que necesitemos, gestionándolo en nuestro System Center Virtual Machine Manager.

Algo asi como una cabina de almacenamiento, pero mediante SMB y con discos locales que aporta un servidor.

Creacion del disco compartido SMB

Es sencillo, en un servidor con windows server 2012 , instalamos el rol de servidor de archivos, de tal manera que cuando lo tengamos y vayamos a la consola, debemos ver un apartado que se llame “recursos compartidos”, y ahí seguiremos el asistente para compartir un disco por SMB, (no voy a poner el procedimiento, si alguien lo desea que me comente).

Creación de una máquina virtual

En este paso creamos una nueva máquina virtual y cuando nos pida la ubicación , le damos la ruta UNC de nuestro recurso creado, por ejemplo:

\\srvarchivos\SMB

Comprobaciones en System Center Virtual Machine Manager

Aqui es donde veo que tengo el problema y que me falta algo, voy al host hyperv que tiene la máquina virtual que acabo de crear y dejar en la ruta UNC del recurso compartido SMB y me da el siguiente mensaje de error:

error smb configuracion de maquina no compatible

Me dice que la configuración no es compatible, por tanto trato de ver el porqué:

Vamos a PROPIEDADES sobre la máquina virtual y luego al apartado de ESTADO, ahi nos dice lo que pasa:

2

Me dice como que el Hyperv no tiene constancia de ese recurso, por tanto miro en nuestro “tejido” en la parte de almacenamiento, y , veo que no hay nada relativo a un servidor SMB, por lo que lanzo el asistente de “agregar recursos” y “dispositivos de almacenamiento”.

4Selecciono servidor de archivos basado en windows.

5

Ahi pondré el FQDN del proveedor de nuestro SMB, (mi servidor con el recurso compartido).

Para que al final quede asi:

6

Comprobaciones

Vuelvo a la máquina, y a pesar de este cambio sigue mostrando el mismo error.

Analizamos que mas puede faltar….

Vamos a uno de los host hyperv y PROPIEDADES.

7

Como podemos observar,, no vemos ningun recurso compartido SMB mapeado en el host, (abajo del todo), “recursos compartidos de…..”.

Pulsamos en AGREGAR.

“Agregar recurso compartido de archivos”.

8

Por tanto ahora el host ya tiene constancia, comprobamos,

Bueno, nos da otro error nuevo, (al dar a ok, se inicia una tarea que no acaba bien), veamos el error:

9

Parece que hay algún tipo de problema de permisos de cuenta para poder realizar la acción, revisamos la cuenta de ejecución disponible de los host hyperv.

(Parecer ser que no tenemos ningúna cuenta de ejecución).

Creo por tanto una cuenta de ejecucion y se lo indico a cada host tal y como vemos en la siguiente imagen:

10

Probamos ahora a ver….

Comprobamos que a metido bien la ruta de el almacenamiento de archivos SMB.

11Ahora vamos a la máquina y miramos si el error ya no está.

Pulsamos en “actualizar” y vemos que ya está todo correcto.

12Un saludo,

Anuncios

Maquina se queda “starting indefinidamente”

En un host hyperv en la consola de administracion de maquinas, vemos una maquina en starting demasiado tiempo, el host lo hemos reiniciado y otras maquinas si han arrancado normalmente.

 

http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx

Process explorer

Nos ayuda a matar el proceso de una maquina de manera sencilla.

Debemos localizar guid de la maquina y buscarlo con esta herramienta. Los guid estaran donde almacenamos las maquinas.

 

Live Migration sin System Center Virtual Machine Manager

Live Migration sin System Center Virtual Machine Manager

Los que conozcan la gestión con Vmware , saben que para hacer una migración en caliente (vmotion), hace falta un servidor Vcenter, o tambien podriamos lanzar un comando de powershell para migrar de un servidor a otro sin necesidad de vcenter, es mas, se suele utilizar powercli cuando el vcenter no está operativo.

Microsoft en su version Windows server 2012 R2, nos ha dado la posibilidad de realizar el equivalente a vmotion (live migration), sin necesidad de tener System Center Virtual Machine Manager , es decir, el equivalente a vcenter.

Obviamente tambien en Microsoft tambien podemos utilizar powershell, pero nos brinda una opción para migrar a traves de la consola de administración de hyperv.

Imagen

Bien, sobre una máquina tenemos la opción “mover”, podriamos mover la máquina virtual o el almacenamiento:

Imagen

Tendremos una serie de opciones de movimiento:

Imagen

De ésta manera SIN System Center VIrtual Machine Manager, podemos hacer un movimiento en caliente y de forma sencilla, y además no solo migrar la máquina sino el almacenamiento.

La conclusión es que es un avance importante, ya que si nos falla el System Center Virtual Machine Manager y necesitamos migrar tanto una máquina como su almacenamiento no hace falta SCVMM (cosa que en vmware dependemos de vcenter), simplemente desde la consola de hyperv podemos hacerlo.

No estaria mal que vmware desde su consola cliente (vic) o via web en un esxi tuviera esa misma opción de poder migrar.

un saludo

 

Pasos montaje cluster en System Center Virtual Machine Manager 2012 R2

Pasos montaje cluster en System Center Virtual Machine Manager 2012 R2

Con este post voy a mostrar de manera resumida todos los pasos que hay que seguir hasta montar un cluster de HA (alta disponibilidad), PRO (Drs de Vmware), Live migratión (vmotion vmware), poder migrar almacenamiento, etc, mediante System Center Virtual Machine Manager 2012 R2 y Windows Server 2012 R2.

Comenzamos:

Lo primero de todo , todas las máquinas metidas en el dominio. (Los hosts hyperv, la máquina de sql, la máquina de vmm).

El SQL

Bien , nos hace falta preparar un SQL, no voy a poner todas las pantallas  ,sino únicamente los puntos clave.

El SQL es necesario para poder instalar SCVMM 2012 R2.

1. Quitar puertos dinámicos y ceros.

En primer lugar el “Configuration Manager“, nada mas instalar el SQL nos vamos a encontrar que en la parte de “configuración de red” , en la parte de TCP/IP , tenemos puertos dinámicos y estos debemos quitarlos, (se accede a través de la pestaña direcciones ip), es decir, donde veamos “ceros” tenemos que quitarlos y dejarlo en blanco, veremos ceros donde pone “puertos dinámicos”. Asimismo tambien quitamos al final del todo donde pone “ipall” el puerto dinámico que aparece.

Lo vemos en esta imagen:

Imagen

2. Canalizaciones

Si nos encontramos que las canalizaciones están deshabilitadas, las habilitamos pulsando encima con el boton derecho propiedades.

Imagen

Bien, una vez que tenemos realizadas esas modificaciones reiniciamos los servicios de SQL, desde esa misma consola de la pantalla anterior sobre “servicios de SQL Server”.

Seguimos con el SQL.

Cuando lo tenemos instalado miramos los servicios y como mínimo tenemos que tener éstos:

Imagen

Asimismo, nada mas empezar la instalación tenemos que seleccionar las siguientes características (como mínimo):

* Servicios de motor de bases de datos

* Sql server data tools

* Conectividad con las herramientas de cliente

* Herramientas de administración, tal y como vemos en la imagen mas abajo.

* SDK de conectividad.

Imagen

Imagen

Bien, después instalaremos SQL con “autenticación windows”, no hace falta cambiar la intercalación (a no ser que mas adelante vayamos a integran SCVMM con SCOM), y en los servicios especificaremos a los “automáticos” que utilizen la cuenta de usuario de directorio activo que hayamos creado para la instalación (puede ser el administrador del dominio si queremos o mejor una dedicada para este caso).

Framework

Debemos tener instalado NetFx3 (Framework) en caso contrario al instalar SQL nos podria dar un error, por tanto, mejor tener instalado framework “antes” de instalar SQL.

Podemos activar la funcionalidad lanzando el siguiente comando desde la consola de comandos:

dism /online /enable-feature /featurename:netfx3 /all /source:d:\sources\sxs

Firewall

A tener en cuenta para la comunicación de SCVMM cuando intentemos conectar con el SQL para poder crear la base de datos de SCVMM, o bien desactivamos el firewall en ambas máquinas o filtramos los puertos.

SCVMM 2012 R2

Primeramente para empezar a instalar System Center Virtual Machine Manager, nos va a requerir:

* Al menos 2 gb de ram, sino no nos deja continuar, incluso seria necesario ponerle 4 porque sino mas adelante tambien nos mostrará una advertencia.

* Windows Assesment ,y seleccionamos las siguientes opciones:

Imagen

Una vez estos requisitos continuamos con la instalación y llegamos al punto clave en donde conectamos con nuestro sql:

Imagen

Metemos el nombre que le hemos dado al servidor sql , y especificamos las credenciales d edominio, la instancia nos aparecerá y le ponemos un nombre a la base de datos o dejamos la que está. Continuamos…

En la siguiente pantalla nos pedirá que especifiquemos la “cuenta de servicio”, nosotros ponemos la que hemos especificado anteriormente.

Luego nos pedirá los puertos (dejamos por defecto), nos pedirá la “libreria compartida”.

Imagen

Y ya esperamos a que se termine de instalar.

Una vez finalizado probamos a entrar con las credenciales que hemos especificado durante la instalación:

Imagen

Ver el aspecto y crear grupo host

En primer lugar tenemos que crear “un grupo host”, esto es una agrupación organizada en donde van a estar nuestros host, si por ejemplo tenemos hyperv, vmware y citrix, crearemos tres grupos host, nosotros vamos a crear uno para alojar el cluster de los host hyperv.

Imagen

Debajo de “todos los host” tendremos nuestra carpeta creada.

Failover Cluster

Lo siguiente que tenemos que hacer es “instalar la característica de failover cluster” en cada host hyperv. Por tanto vamos a agregar y quitar roles y vamos hasta característica y encontramos “cluster de conmutacion por error”.

Imagen

Añadir host a failover cluster

Una vez instalada la característica, entramos en ella y tenemos que “crear el cluster” con los host que tenemos, de momento solo vamos a crear el cluster dándole un nombre al cluster y añadiendo los host.

Para crear el cluster tenemos la opción a la derecha:

Imagen

Durante ese asistente nos va a pedir lo siguiente:

* Nombre del cluster:  Aqui lo que hace es crear un registro dns con ese nombre.

* Ip del cluster: Nos va a crear un registro dns con el nombre anterior asociado a esta ip.

* Servidores o nodos para añadir al cluster

Existe una validación para comprobar que es todo correcto.

El almacenamiento todavia no lo tenemos, por tanto le hemos dicho en el asistente que NO queremos añadir el almacenamiento, únicamente hemos agregado los host y creado el cluster.

Imagen

Almacenamiento

Dentro de la consola de failover cluster tenemos que indicarle que tenemos almacenamiento, por tanto tenemos que preparar al menos dos discos:

* Para el quorum

* Para almacenar las máquinas virtuales en un almacenamiento compartido que luego nos permita tener alta disponibilidad.

No voy a entrar en detalles sobre la configuración del almacenamiento, pero por ejemplo podriamos configurar una NAS por ISCSI como TARGET o una máquina virtual o servidor dedicado con un TARGET de microsoft configurado, (por ejemplo windows server 2012 tiene la opcion de crear un target iscsi), podriamos meter discos a ese servidor y configurar los DESTINOS en ese TARGET (los destinos es un grupo de servidores que tienen permiso para acceder al disco).

Bien, imaginemos que ya tenemos preparado dos discos, uno pequeño para el quorum (de entre 1 y 3 gb), y otro mas grande para almacenar máquinas virtuales en cluster.

Debemos decirle a failover cluster que puede disponer de esos discos.

Imagen

En la imagen ya tenemos dos agregados, simplemente tenemos que pulsar a la derecha en “agregar disco”, si el disco es accesible nos aparecerá, sino nos dará un mensaje.

Los discos tienen que estar :

* Inicializados

* En linea

* Formateados

CSV

CSV es la tecnologia que creó Microsoft para poder tener un sistema de almacenamiento en cluster, es decir, que permita que en una misma LUN existan varias máquinas virtuales, asi como que varios servidores hyperv puedan acceder a esa misma LUN.

Por tanto, debemos hacer que uno de los discos anteriores (en el que se van a alojar máquinas virtuales), SEA UN DISCO CSV, es decir, pasara de almacenamiento disponible a almacenamiento en cluster.

Para ello tenemos un asistente:

Imagen

Con solo seleccionar el disco  y pulsar en esa opción, nuestro disco pasara a ser un disco CSV, y se puede comprobar al pinchar en él y ver mas abajo lo que aparece:

Imagen

Inmediatamente el disco pasa a ser un disco de “almacenamiento disponible”, a “volumen compartido de cluster”, el sistema crea una ruta llamada: c:\ClusterStorage\Volume1 que es donde se almacenaran las máquinas virtuales, todas las que estén ahí formaran parte del cluster de HA pudiendose balancear en caso de caida de un host.

RED

En nuestro failover cluster debemos tener configurado las redes de cluster :

Imagen

La red de cluster1 especifica servidores del cluster que tienen un switch virtual que se llama CLUSTER y un rango de red específico (en este caso 192.168.10xx), frente a la red interna (red cluster2) que tiene otro rango (192.168.0.xxx).

Imagen

Por tanto aqui tanto en el host hyperv1 como en el hyperv2 , existe un switch virtual que se llama red y que toma el rango del tercer octeto en 0.

ROLES EN FAILOVER

Si queremos que nuestras máquinas tengan alta disponibilidad debemos añadir el rol de “maquina virtual” en el servicio de failover cluster, y lo hacemos simplemente siguiente el asistente y seleccionando cuáles máquinas queremos que estén en HA.

Imagen

Despues seleccionamos qué máquinas (saldran todas las que existan en ambos host metido como nodos).

Imagen

Vemos en la siguiente imagen como la máquina ya está en HA.

Imagen

SCVMM agregar el cluster

Llegados a este punto ya podemos decirle a SCVMM que puede tener un cluster, por tanto lo que vamos a realizar es añadir el cluster al SCVMM de esta manera:

Sobre el grupo host que hemos creado anteriormente, boton derecho y seleccionamos la opcion de agregar cluster.

Imagen

Especificamos “equipos de windows server en un dominio de active directory de confianza”.

Debemos crear una “cuenta de ejecución”, no es mas que una cuenta con permisos, y lo hacemos desde el mismo asistente. O sino especificamos manualmente las credenciales de dominio.

Despues nos pide especificar el ambito de búsqueda, podemos hacer una consulta de active directory para buscar los objetos, seleccionamos esa opcion y asi va buscando todos los equipos de directorio activo:

Imagen

Como nosotros “ya hemos creado el cluster”, el sistema no nos permite seleccionar un host independientemente, sino que en vez de eso ya nos enumera el “objeto cluster”, (es decir nuestro cluster que llamamos cluster), con los dos host que cuelgan, por tanto seleccionamos el objeto cluster para que lo añada a SCVMM.

Especificamos el grupo host hyperv, es decir, le estamos diciendo que meta el cluster en esa agrupación.

Una vez añadido vemos lo siguiente:

Imagen

A la izquierda debajo de nuestro grupo hosts ya vemos como está el cluster, no obstante nos lo ha creado pero con información, debemos observar el error y solucionar el fallo de comunicación con el agente, este error nos está diciendo que tenemos que actualizar el agente de los host.

De ahí que los host aparezcan como “pendiente”:

Imagen

Por tanto en cada uno de nuestros host tenemos que actualizar la versión del agente, para ello debemos ejecutar el ejecutable de SCVMM y seleccionar la opcion “agente local” tal y como vemos:

Imagen

Esto lo que hace es desinstalar uno previo y actualizarlo con el nuevo.

Lo mejor es una vez instalado el nuevo agente, “reiniciar” los host, en caso contrario puede que los servidores sigan en el mismo estado, el agente es fundamental para que funcione la alta disponibilidad.

Tampoco está de mas hacer esta comprobacion lanzando este comando:

Imagen

Aconsejable verificar si tenemos este paquete instalado en el servidor VMM:

http://support.microsoft.com/kb/2932881

Una nota…

El agente se instala automáticamente durante el proceso de crear el grupo host y luego añadir el cluster. Es muy importante que la cuenta que se utilice para añadir el cluster sea un nuevo usuario que se cree en el directorio activo con los mismos permisos que por ejemplo el administrador del dominio (podemos copiar la cuenta administrador para crear otra cuenta).

El problema anterior se soluciona si hacemos lo que he dicho en la nota, a no ser que como decia antes WinRm no está funcionando , o existan problemas con otro agente anterior el cual deberemos desinstalar.

Por tanto, una vez añadidos los vemos así :

Imagen

COMPROBACIONES

Almacenamiento

Propiedades sobre uno de los host.

Comprobamos que ese host ve un almacenamiento compartido, para ello al dar propiedades y luego a almacenamiento, tenemos que ver el disco compartido que creamos anteriormente.

Imagen

Si nos fijamos lo clasifica como “remote storage”, eso quiere decir que está en un volumen de almaceanamiento compartido de los discos convertidos a CSV desde failover cluster.

Comprobamos lo mismo en el otro servidor el cual tiene que ver el mismo disco.

Comprobaremos tambien con PROPIEDADES sobre el CLUSTER, el ALMACENAMIENTO DISPONIBLE, tal y como vemos, en nuestro caso es solamente el disco para quorum:

Imagen

Ahora vamos a fijarnos que tambien tenemos un apartado de ALMACENAMIENTO EN CLUSTER, el sistema le llama “volúmenes compartidos”, en él vemos nuestro disco para albergan máquinas virtuales que era el disco convertido a CSV.

Vemos tambien que podemos convertir ese disco a almacenamiento disponible o el disco de almacenamiento disponible a CSV, por tanto tenemos dos lugares desde donde poder hacerlo.

Pruebas

Llegados a este punto es el momento de probar si podemos por ejemplo hacer un “live migratión” de una máquina en funcionamiento de un host a otro.

Vamos a migrar una máquina que está en el host hyperv2 al hyperv1, fijemonos en el asistente:

Imagen

El asistente no notifica problemas, si existiera alguno, lo veriamos mas abajo en la “explicacion de la clasificacion”.

El sistema da una clasificación por extrellas de los host para ver cuanto es la carga, en este caso vamos a migrar a un host que está un poco mas cargado.

NOTA: En este asistente de migración hay un tema importante. Si marcamos el check “hacer que la máquina virtual sea de alta disponibilidad”, ocurre que utiliza migracion VSM, es decir, migra tanto los archivos de configuración o dirección de ejecución como los discos (hace un svmotion de vmware). Si continuamos veremos como además nos lo deja en un almacenamiento compartido en cluster.

Imagen

Vemos como pone “c:\clusterStorage\Volume 1

Si no marcamos la opción de hacer que sea de alta disponibilidad, nosotros tendriamos que buscar la ruta.

Hay que tener en cuenta que el sistema ha visto que es una máquina que en  origen NO estaba en un almacenamiento compartido, por eso nos hace tanto migración en vivo como migración de almacenamiento.

Vemos en la siguiente imagen dónde están los archivos de la máquina virtual:

 

Imagen

 

 

Imagen

En la imagen superior vemos como se está realizando la migración, no solo de la máquina sino del almacenamiento. Si ahora quisieramos volver a migrar la misma máquina al otro host, únicamente hariamos la migración de la dirección de ejecucion “live migration”, ya que en el almacenamiento compartido ya está.

Svmotion (Migración almacenamiento)

En este caso nosotros tenemos que especificar el cambio hacia otro almacenamiento, si por ejemplo está en local, indicamos como vemos en la imagen de abajo un almacenamiento compartido, en esa ubicación vemos que ya hay alguna máquina:

Imagen

PRO (Balanceo dinámico)

Primero vamos a ver dónde se activa:

Propiedades en grupo host y ahi vemos la opción de activarlo, tal y como vemos en la imagen:

Imagen

Podemos mirar si hace falta o sugiera alguna migración para balancear:

(boton derecho sobre el cluster , “optimizar hosts”)

Imagen

Vemos que si, procedemos entonces a seleccionar “optimizar”.

Bien, hemos visto entonces cual es el proceso completo para montar una infraestructura con SCVMM 2012 R2, host Windows Server 2012 R2 con hyperv, en cluster , hemos probado que funciona live migratión, migración almanamiento y pro, deberiamos probar la HA pero para ello tenemos que hablar de una forma mas avanzada del funcionamiento de failover cluster en otro post.

un saludo

MAC Address en Hyperv y SCVMM

Quiero clarificar en este post la configuración de pools o agrupaciones de direcciones MAC en Hyperv y System Center Virtual Machine manager.

Quiero enseñaros cómo configurarlo, aunque al principio parece fácil si que es cierto que suceden muchos problemas de duplicidad de MAC en infraestructuras virtuales, concretamente puede suceder que haya máquinas virtuales que cambien su MAC y que debido a ello pueda ocurrir una pérdida de conexión de red.

Como os digo quiero clarificar un poco el funcionamiento, empezamos:

Empezamos con el Host Hyperv:

Nos vamos a la consola de “hyperv manager” y luego al apartado de “virtual switch manager” (o en castellano administrador de conmutadores virtuales) que es donde creamos los switch virtuales.

Imagen

Imagen

Bien, este rango es el que utilizara el hyperv para asignar MAC a las máquinas virtuales que se ejecuten en ese host hyperv.  Como vemos en la información, si cambiamos ésta configuración , los adaptadores de red que ya se configuraron no quedan afectados. Nos dice que si queremos aplicar una nueva configuración, debemos eliminar el adaptador anterior y agregar uno nuevo.

Por tanto, cada máquina virtual tendrá asignada una dirección MAC en su adaptador de red virtual (tarjeta de red virtual), y, lo podemos ver si vamos a las propiedades de la máquina virtual tal y como vemos en la siguiente imágen:

Imagen

Aqui vemos que la dirección MAC es CERO, eso es porque ésta máquina virtual de momento “es una definición” no es una máquina con el sistema operativo instalado. En caso contrario apareceria la dirección MAC.

Como vemos, accedemos desde la parte de la tarjeta de red virtual, en la parte de “características avanzadas“.

Esa MAC que aparecerá en caracteristicas avanzadas, tiene que ser una MAC “del rango” que hemos visto en la imagen mas arriba dentro del intervalo de direcciones MAC.

Evidentemente nosotros podemos especificar una MAC ESTATICA para esa máquina virtual en cuestión.

Ahora tendriamos que lanzar una pregunta…..

Normalmente en un entorno de virtualización o bien tenemos host standalone (independientes) o tenemos varios que forman parte de un cluster.

Hyperv por su forma de trabajar, tiene unos algoritmos que se encargan de detectar posibles conflictos de MAC (duplicación de MAC), sobre el host, PERO NO A TRAVES DE MULTIPLES HOST.

Por lo tanto es muy posible que suceda un fallo de configuración cuando un administrador duplica los rangos  de asignación de MAC en los apartados que hemos visto anteriormente.

Si por ejemplo hacemos un “live migration” de una máquina de un host a otro (como vmotion de vmware), no hay problemas y se mantendrá el mismo MAC en la máquina virtual.

Si en el host destiono hay un rango de MAC distinto, la MAC de la máquina virtual cambiara cuando se den éstos casos:

* Cuando la cambie pase del estado apagada a encendida.

* Cuando se restaure de un estado de guardada.

* Cuando exista otra máquina virtual en ese host con la misma MAC.

Si habiamos configurado una MAC estática en la máquina virtual, esa no se cambia, permanece.

En SCVMM tenemos dentro de FABRIC y en el apartado de NETWORKING , un apartado destinado a los pool de MAC, tal y como vemos:

Imagen

El sistema crea un pool predeterminado con un rango de MAC específico, eso se puede cambiar y nosotros podemos crear nuevas agrupaciones de MAC para luego usarlas.

Por tanto, una “nueva máquina virtual” que creemos desde el asistente de creación de máquina virtual desde SCVMM utilizará este pool de MAC predefinido.

En ésta imagen vemos cómo en las propiedades de una máquina virtual por defecto aparece “dynamic”.

Imagen

Ahora bien, entonces….¿si antes hemos dicho que en el host tenemos en la parte de configuración de conmutadores virtuales un apartado para especificar un rango de MAC, cúal de los dos rangos toma, el de el hyperv o el de vmm?.

¿Buena pregunta para probar verdad?

Si en la imagen anterior seleccionais DYNAMIC, lo que el sistema hace es utilizar el pool de las opciones del host, es decir, de la primera pantalla al principio del artículo (de la configuración de los conmutadores virtuales).

Si en la imagen anterior seleccionais STATIC, lo que el sistema hace es tirar DEL POOL DE MAC de SCVMM.

Os pongo una imagen sin tener VMM simplemente un host que ejecuta una máquina virtual, y podemos ver cómo le ha asignado la MAC primera del rango:

mac6

mac7

(a la izquierda son las propiedades de la máquina virtual y a la derecha el pool del host standalone)

Esto de momento, hay que pensar tambien en relación a problemáticas de MAC , cuando tenemos un host con varias tarjetas de red fisicas y forman parte de un TEAM, aqui habria que dedicar otro artículo (lo  haré), en donde se pueden producir eventos relacionados con conflictos de MAC entre el TEAM y algún miembro del team, y por estos motivos tendremos que ajustar los diferentes modos del team (switch independent, static, lacp), y los diferentes tipos de algoritmos de distribución (transport ports, ipaddresses, macaddress), y luego hacer frente a las recomendaciones de Microsoft en cuanto a cómo hacer la configuración cuando el team está conectado a “diferentes switch” o a un “mismo switch”, por ejemplo con conexión a diferentes switchs lo mejor seria seleccionar la opcion de “swtich independiente”, frente a cuando lo tenemos conectado a un mismo switch en donde seria recomendable utilizar “static” o “lacp”.

Pero eso para otro artículo.

un saludo

 

 

Esquema Clustering

Hola

Para entender de una manera global el funcionamiento de la herramienta failover cluster, os dejo un pequeño gráfico que he hecho en plan diagrama de flujo ( o a ese estilo), en donde trato de resumir un poco el funcionamiento y las distintas cosas a tener en cuenta.

funcionamiento cluster

A modo de pequeño resumen:

Tenemos dos tipos de cluster, de host orientado a fallos de hardware y guest clustering, orientado a disponibilidad del software o servicio.

Despues tenemos diferentes situaciones que se puedan dar en nuestro entorno de producción, (que tengamos que apagar un servidor , que falle su hardware, que falle el quorum, etc.)

Os muestro los distintos tipos de quorum, con testigo , sin testigo, dinámico, y un pequeño resumen del funcionamiento de cada uno para decidir cual es el mejor y en qué situación.

Cuando usarlo y qué tipos de testigo tenemos.

Requisitos de los testigos y la opción de decidir que host votan, si todos, si ninguno…

un saludo en otras entradas hablaremos mas sobre este tema, espero os sirva de esquema global para luego ir trabajando en el conocimiento y funcionamiento de cada apartado.

un saludo

 

Failover Cluster. Detener servicio de Cluster

Failover Cluster. Detener servicio de Cluster

Siguiendo con los apartados  ¿que pasaria si ?….

En el entorno de cluster de system center virtual machine manager 2012 y mediante la herramienta de Failover Cluster, vamos a comentar que pasaria si detenemos el servicio de cluster de uno de los host.

Tenemos dos host y estamos utilizando testigo, y los nodos no tienen voto

Ocurre lo siguiente:

* Las máquinas virtuales que se ejecutan en ese host pierden algun pequeño ping.

* Pasan al otro nodo

* En el VMM el host cuyo servicio está caido se ve como fallo (axpa roja) las máquinas virtuaes, y en breve tiempo  ya aparecen ok en el segundo host.

* En failover cluster se ve el host como caido

* Levanto otra vez el servicio en failover cluster

* En el host que ha tomado control de las máquinas, selecciono las máquina que antes se ejecutaban en el host con el servicio caido y selecciono “mover”, “al mejor nodo posible”, las máquinas me las mueve al host el cual forzamos la caida del servicio. , es decir, hace una migración en vivo (live migration).

Bien, hemos probado “que pasaria si…..” , deteniendo el servicio de cluster tal y como vemos en la imagen.

Imagen

un saludo