Hola.
En Technet han actualizado la tabla con la lista de actualizaciones y hotfix sacados hasta la fecha para Hyper-V en Windows Server 2012
Aquí lo tenéis:
En este web también podéis encontrar algo similar en relación a actualizaciones y hotfix para el rol de Failover Clúster:
http://support.microsoft.com/kb/2784261
Saludos.
Hola.
Tras haber estado hablado en las últimas entradas sobre las novedades, principalmente, en la creación de clústeres, ahora tocaría hablar de la principal novedad en cuanto a funcionalidad, esto es, Scale Out.
Scale Out es el nombre que ha recibido la funcionalidad de almacenamiento clusterizado de archivos para aplicaciones que lo soportan. Scale out se combina con csv y por tanto nos ofrece mayor fiabilidad, disponibilidad, manejabilidad y alto rendimiento ya que la información se ofrece on line por parte de todos los nodos del clúster.
En esta entrada veremos la configuración de Scale Out para almacenar máquinas virtuales creadas en Hyper-V r3.
La comparativa entre Scale Out y la solución tradicional es esta:
http://technet.microsoft.com/es-es/library/hh831349.aspx
Antes de nada veamos los requisitos previos:
1. Tener un CSV dedicado en el clúster, que en ws2012 se crea así:
2. La cuenta de equipo de clúster ha de tener permisos de creación de cuentras de equipo en la OU donde está:
3. Tener los servidores de Hyper-V en el mismo dominio que el clúster o en dominios con relaciones de confianza.
En la siguiente entrada creamos el Scale out …
Hola.
Algunas de las novedades que más me gustan en Windows Server 2012 las incorpora el rol de Failover Clúster.
En esta entrada vamos a explotar una novedad gracias a la cual podremos crear un clúster, ubicado en una DMZ en la que por seguridad, hemos ubicado un RODC para ser su DC de referencia.
Algo a tener en cuenta es que podemos ubicar la cuenta de clúster en la OU que necesitemos, algo que a día de hoy, con la cantidad de delegaciones de responsabilidad, subcontratación y descentralización en la que vivimos, se muestra muy efectivo y necesario.
Descripción de entorno:
Yendo un poco mas allá en términos de seguridad y simulando una situación bastante común. En esta ubicación remota donde montaríamos este clúster, ubicamos un RODC y tenemos un administrador que no puede ser más que administrador local de los nodos y simple usuario de dominio. ¿Está complicado que este administrador monte un clúster en versiones anteriores a Windows Server 2012?, ¿verdad?.
No hace falta decir que ya que el departamento de seguridad se ha puesto duro. Como en muchas corporaciones tenemos una directiva que impide que los usuarios metan equipos en dominio y contando que nuestro usuario es administrador local y un simple usuario de dominio, nosotros como administradores de dominio vamos a crear una cuenta previamente para que, en el momento de crear el clúster, nuestro RODC ya la tenga.
Lo primero a tener en cuenta es que previo a la puesta en marcha del clúster, cuento con este entorno:
1. Active Directory con bosque 2012 y dominio 2012, pero en entradas anteriores (creación de RODC) ya visteis como este entorno soportaría tener funcionalidad 2003 teniendo eso si, al menos un DC 2008 y ejecutando la orden adprep /rodcprep.
2. Por hacerlo perfecto en terminos de seguridad, hemos hecho una OU donde tendremos las cuentas de equipo de los nodos, cuenta de equipo del clúster y un usuario al que llamamos ADMcluster que será con el que iniciemos sesión en los nodos para crear el clúster.
3. Aunque como os enseñaré en mi blog, el clúster ya se inicia sin necesidad de tener un DC a su alcance, hacemos miembros del grupo “Allowed Rodc Password…” al usuario ADMcluster, cuentas de equipo de los nodos y del clúster.
Paso a paso (pre requisitos):
1. Crear cuenta ADMCluster e introducir la cuenta como administrador local en los 2 nodos del clúster, además de hacerle miembro de “Allowed RODC…”
2. Crear OU donde moveremos las cuentas de equipo de los nodos y crearemos una cuenta de equipo con el nombre que tendrá el clúster.
3.Tras crear la cuenta, botón derecho sobre la cuenta y elegir la opción “Deshabilitar”.
4. Propiedades sobre la cuenta de equipo deshabilitada “Cluster”
5. A nuestro usuario ADMCluster, le damos control total sobre la cuenta.
Montaje de clúster:
A continuación toca montar el clúster , en esto no voy a entrar en detalles obvios, en mi entorno tengo:
1. Tarjeta que hará de latido del clúster.
2. En mi caso cuento con las tarjetas Iscsi y asignada y formateada la Lun de Quorum y lun para futuro csv .
3. Tarjeta para Lan.
4. Activado el rol de Failover clúster en los dos nodos.
5. Como os he dicho antes, recalco que tenemos el usuario ADMcluster como administrador local en los dos equipos.
Tras tener todos los requisitos, la creación del clúster por parte del usuario ADMCluster no difiere de la creación de un clúster normal y corriente. Observad que al final del proceso la cuenta de clúster aparece como habilitada.
Tened en cuenta el funcionamiento de un RODC, quiero decir, mientras la línea entre el RODC y el DC de referencia esté levantada, todo funciona correctamente esté cacheada la cuenta de los diferentes usuarios y/o equipos o no. El problema viene cuando esta línea no está disponible. En esta situación solo podrán validarse contra el RODC usuarios y equipos cacheados y eso, lo tenéis que prever, por supuesto, cuando todo funciona.
Hay que tener en cuenta otra gran novedad. El servicio de clúster se levanta a pesar de no estar levantado el DC o el propio RODC pero esto nos viene muy bien cuando hospedamos máquinas virtuales, no siendo así cuando hospedamos servicios como file server que luego, al fin y al cabo no son accesibles si no se comprueban los permisos del usuario.
Saludos.
>Hola.
Últimamente andamos siempre metidos entre guest clusters, incentivados además por las licencias extras que ofrece la versión Enterprise y Datacenter.
Aquí tenéis un artículo muy interesante que explica como montarlo:
En el mundo de la virtualización este es un dibujo algo cuestionado a la hora de elegir es u otras formas de proveer alta disponibilidad a un servicio, no hace mucho escuché ciertas preguntas que para mi son claves:
1. ¿Que servicio no puede soportar una parada de 3 minutos +/-?, este es el tiempo de inicio de un Windows Server ante la caida del nodo que lo mantenía levantado.
2. ¿Cuanto dinero estás dispuesto a gastar para evitar esa parada de 3 minutos?.
3. ¿Que no ofrece guest clustering?, ante la necesidad de no parar nunca el servicio.
4. Con guest clustering puedes reiniciar las máquinas sin parada del servicio.
Saludos.
Saludos.
>
Hola.
Una de las cosas que esta semana nos ha tenido ocupados es un problema aparecido durante backups de máquinas virtuales albergadas en un cluster de WS2008r2 y almacenadas en dos CSV, esta vez el software utilizado para hacer backup era el de la gente de Commvault y el que en su última versión, ya aparecen como soportados los nuevos CSV de 2008 r2, mi impresión es que este problema puede aparecer con cualquier otro software de backup.
Pues bien, durante el proceso del backup, de manera controlada los CSV pasan a estar en “Acceso Redirigido” eso es así, porque es necesario tener bien controlado el acceso a la lun, más aún cuando las máquinas virtuales siguen funcionando y por otra parte existe un proceso de copiado de archivos como es el del Backup.
El problema venía en que cuando finalizaba el backup, los CSV no volvían a su estado normal y seguían con el cartelito de “Acceso Redirigido”, incluso habiendo llegado a reiniciar el cluster.
¿La solución?, pues entendiendo lo que está sucediendo por debajo y leyendo lo que hacen, puede resultar lógico instalar los parches que se aconseja instalar previo a la instación de System Center Data Protection Manager y que son estos:
http://support.microsoft.com/kb/975921
http://support.microsoft.com/kb/975354
Estos hotfix relacionados con el proceso de instantáneas, son los que han solucionado el problema. Ahora solo falta que los fabricantes de software de backup, incluyan la instalación de estos hotfix como requisito previo a la instalación del agente correspondiente, al igual que aparece en la documentación de DPM.
Saludos.
>Hola.
Este hotfix ya es un poco antiguo, pero veo que con servidores actualizados a día de hoy aun puede ocurrir, así que es importante que conozcáis la existencia de este hotfix:
Saludos.
>
Hola.
De imprescindible lectura para comprender el desarrollo de esta entrada son los artículos de David que enumero a continuación:
http://blogs.technet.com/davidcervigon/archive/2009/04/17/cl-steres-virtuales-guest-clustering.aspx
Una vez leído sobre todo el primer artículo, extraigo lo siguiente:
“Para ellos, cada CSV tiene un nodo designado como “coordinador”, y el, y solo el, es el encargado de gestionar el espacio de nombres del volumen, y la creación de nuevos ficheros. Sin embargo, existe un filter driver en cada nodo que es capaz de distinguir el I/O producido por estos accesos y operaciones “del explorador de Windows”, para entendernos, del derivado de las lecturas/escrituras rápidas sobre un fichero (en este caso los VHDs) que requiere Hyper-V para trabajar de manera eficiente. El primero es redirigido al coordinador del CSV a través de la red configurada con menor métrica en el cluster (generalmente la interna, o de heartbeat)”
A toda la teoría aparecida, hay que añadir que en el caso de que un nodo pierda el acceso a disco de todas las formas posibles, desconexión física del servidor a la cabina, mala configuración en el conector iscsi, no asignación de permisos adecuados en la cabina a un nodo del clúster, más todas los posibles problemas similares y alguno más que un simple “hobbit” descubrirá seguro, el nodo que se queda sin acceso a la lun CSV, verá esta a través del servidor propieatario de la lun y designado como servidor de transacciones, con lo que venimos a explicar es que para perder el acceso y que nos veamos en un problema grave, no solo el servidor que levanta una máquina virtual ha perder conectividad con la cabina, si no que además debe de perder conectividad por (normalmente) la tarjeta de hearbeath.
Problema
Al final de esto, si perdemos conectividad con la cabina, desde cualquier de los nodos del cluster, lo veamos desde donde lo veamos, los CSV aparecerán tal que así (Fijaros en el color amarillo y en texto “Acceso redirigido” que aparece en cada CSv):
¿Solución?
Pues encontrar el nodo que no tiene un acceso correcto a la cabina, en mi caso estaba provocado al tener quitados todos los accesos iscsi.
Una vez restablecidos estos a través además de doble camino (estoy con el tercero y el cuarto).
Y cuando todos los servidores tienen on-line las luns, todo aparece OK y en verde:
Nota: Podría haber hecho todas estas operaciones, teniendo el servidor en producción y con las máquinas virtuales que salen por él encendidas, sin embargo, como podéis imaginar, este servidor había sido liberado de máquinas virtuales unos momentos antes, gracias a Live y Quick Migration.
Además he provocado la aparición de “Acceso Redirigido” dejando el nodo como funcional en el cluster, bien hecho (y es como he hecho la operación en producción), habría que dejar el servidor con el servicio de clúster detenido.
Saludos.
>De lectura imprescindible si os dedicais a esto de ir por el mundo montando cluster, virtualizando y demás cosas que desaparecerán cuando llegue «la nube»:
>Hola.
A dia de hoy, ya estamos acostumbrados a pelear con cabinas, por le mero hecho de que Windows Server 2008 y 2008 r2, «habla» con ellas, con el protocolo SCSI-3 persistente, para cada marca una solución y en el caso de SUN, la solución que proponen en cabinas modelo stk 2540 es instalar el driver para MPIO de los modelos de la serie 6000.
Tenéis la descarga aquí:
El archivo a ejecutar es este:
