En éste artículo no se explica como instalar Lync Server 2013, sino como mover el rol de Administración Central de Lync Server 2010 a Lync Server 2013 y como poder eliminar nuestro viejo front end de Lync Server 2010.

Lo primero y preferiblemente en un servidor dedicado como frontal de Lync, instala Windows 2012 Server en su versión Standard… también es posible sobre W2K8R2SP1, añade los requisitos Windows para Lync, en la forma de características del OS e instala Lync Server 2013.

Tras la instalación observamos que nuestro nuevo servidor se ha unido a la topología de Lync 2010, pero aun hay que mover el servidor de administración central que reside en Lync Server 2010 al servidor front-end 2013 si queremos como es lógico, quitar el servidor Lync Server 2010 heredado. A partir de aquí éste documento indica los pasos a seguir para migrar el servidor de administración central a Lync Server 2013.

Preparación de los servidores Front-End Lync 2013 antes de mover el Servidor de Administración Central.

A continuación, trato de detallar los pasos a seguir para preparar los servidores de Front-End, antes de mover el servidor de administración central de Lync Server 2010 a Lync Server 2013.

Para preparar un pool de servidor/es Front-End.
Para preparar el pool de servidores Front-End habrá que iniciar sesión, con un usuario con permisos administrativos y de sysadmin de base de datos SQL, en el equipo donde esté instalado como miembro del grupo RTCUniversalServerAdmins la consola de PowerShell de administración de Lync Server. Una vez dentro, se ejecutará una consola de PowerShell de administración de Lync Server. Cuando la ventana aparezca y cargue los comandos, se escribirá el siguiente comando:

Install-CsDatabase -CentralManagementDatabase -SQLServerFQDN -SQLInstanceName

Una vez ejecutado, habrá que comprobar que el estado del servicio Lync Server Front-End esté Iniciado.

Mover el servidor de administración central de Lync Server 2010 a Lync Server 2013

A continuación se detallan los pasos a seguir para realizar el movimiento del servidor de administración central de Lync Server 2010 a Lync Server 2013.
En el servidor Lync Server 2013, que será el nuevo servidor de administración central, habrá que iniciar sesión con un usuario con privilegios de administración y de administración de base de datos SQL. Dentro del servidor, la consola de PowerShell de administración de Lync Server estará instalada como miembro del grupo RTCUniversalServerAdmins. Una vez se haya logado dentro del equipo, habrá que abrir una consola de PowerShell de administración de Lync Server. En ella escriba el siguiente comando:

Enable-CSTopology

Es importante que el comando se ejecute correctamente, ya que en caso contrario, se producirá un error en la migración que puede dejar la topología sin ningún almacén de administración central. Si el comando no se ejecuta correctamente, solucione el problema evitando que el comando se complete antes de continuar.

Ahora, habrá que acceder al servidor Front-End o al pool de servidores Front-End y en un PowerShell de administración de Lync Server, habrá que escribir el siguiente comando:

Move-CSManagementserver

En la consola, se mostrarán los servidores, almacenes de archivos, almacenes de bases de datos y puntos de conexión de servicio del estado actual y el estado propuesto. Se leerá la información cuidadosamente para confirmar que el origen sea nuestro antiguo y todavía activo servidor de Lync Server 2010 y el destino el nuevo servidor con Lync Server 2013. Una vez se compruebe que todo es correcto, se escribirá ‘S’ para continuar o, en caso de que haya algún error, ‘N’ para detener la migración.

Una vez finalizada la migración, se revisarán si hay advertencias o errores que se hayan generado al ejecutar el comando move-CsManagementServer, con la intención de resolverlo lo antes posible para poder continuar con el proceso. Hecho esto, en el servidor Lync Server 2013, se abrirá el asistente para la implementación de Lync Server. Una vez abierto. Habrá que pulsar sobre “instalar o actualizar el sistema Lync Server”- Instalar o desinstalar componentes de Lync Server. Después, se hará clic en siguiente, entonces, se abrirá una pantalla de resumen. Una vez leído y revisado, se hará clic en el botón Finalizar para terminar.

El siguiente paso será ir al servidor Lync Server 2010 y abrir el asistente para la implementación de Lync Server. Hecho esto. Habrá que ir, como en la vez anterior, a Instalar o actualizar Lync Server, que se puede encontrar en el mismo sitio. Instalar o desinstalar componentes de Lync Server. Hecho esto, se pulsará en siguiente para continuar. Entonces, aparecerá una página de resumen, se revisará que todo esté correcto y para terminar, se hará clic sobre el botón Finalizar.
Para confirmar que se está efectuando la replicación con el nuevo almacén de administración central, en una consola de Powershell de administración de Lync Server, escriba:

Get-CSManagementStoreReplicationStatus

Es muy posible, que la replicación necesite bastante tiempo para actualizar todas las réplicas.

Quitar archivos de Lync Server 2010 del almacén de administración central después del movimiento.

Antes de realizar este paso. La replicación tiene que haber finalizado por completo y estar estable. Ya que si quita los archivos antes de completar la replicación, se interrumpirá el proceso de replicación y el servidor de administración central migrado quedará en un estado desconocido. Para comprobar y confirmar el estado de la replicación, en una consola de PowerShell de administración de Lync escribir el comando Get-CSManagementStoreReplicationStatus.

Una vez haya finalizado el movimiento del almacén de administración central, habrá que quitar los archivos del servidor Lync Server 2010. Para ello, habrá que seguir los siguientes pasos.

Se accederá al servidor Lync Server 2010 y se iniciará sesión con un usuario con permisos de administración de base de datos SQL Server. Se abrirá una consola de Powershell de administración de Lync Server y se ejecutará el siguiente comando:

Donde el <FQDN of SQL Server> es el servidor Back-End de Lync Server 2010 en una implementación de Enterprise Edition o el FQDN del servidor Standard Edition. Quedaría de la siguiente manera:

Uninstall-CsDatabase –CentralManagementDatabase –SQLServerFQDN Servidor – InstanceName Lync2010

Una vez replicados los cambios, podremos apagar nuestro viejo front end de Lync Server 2010.

Para aquellos que estemos en fase de migración de nuestros DC y DA, es muy recomendable elevar los niveles funcionales del bosque y dominio a un modo nativo, con independencia de los sistemas que corran en nuestro dominio si lo pensamos hacer a modo nativo 2012. En el caso de Windows Server 2012 requiere un nivel funcional de bosque de Windows Server 2003. Es decir, que para poder agregar un controlador de dominio que ejecuta Windows Server 2012 en un bosque de Active Directory ya existente, el nivel funcional del bosque debe ser Windows Server 2003 o superior. Esto significa que los controladores de dominio que ejecutan Windows Server 2008 R2, Windows Server 2008 o Windows Server 2003 pueden funcionar en el mismo bosque, pero los controladores de dominio que ejecutan Windows 2000 Server no son compatibles y bloquearán la instalación de un controlador de dominio que ejecute Windows Server 2012 y si el bosque contiene controladores de dominio que ejecutan Windows Server 2003 o posterior, pero el nivel funcional de dicho bosque sigue siendo Windows 2000, la instalación se bloqueará igualmente.

El nuevo nivel funcional de dominio de Windows Server 2012 permite un nueva característica: la compatibilidad de KDC con notificaciones, autenticación compuesta y protección de Kerberos La directiva de plantillas administrativas KDC tiene dos configuraciones (proporcionar siempre notificaciones y error de solicitudes de autenticación sin blindar) que requieren el nivel funcional de dominio de Windows Server 2012.

El nivel funcional del bosque de Windows Server 2012 no proporciona características nuevas, pero asegura que todo dominio nuevo creado en el bosque funcione automáticamente en el nivel funcional de dominio de Windows Server 2012. El nivel funcional del dominio Windows Server 2012 no proporciona otras características nuevas además de la compatibilidad de KDC con notificaciones, autenticación compuesta y protección de Kerberos. No obstante, garantiza que cualquier controlador de dominio que se encuentre en el dominio ejecute Windows Server 2012.

Después de establecer el nivel funcional del bosque en un determinado valor, no se puede revertir o bajar el nivel funcional del bosque, salvo en las siguientes excepciones: cuando eleve el nivel funcional del bosque a Windows Server 2012, puede bajarlo a Windows Server 2008 R2. Si la papelera de reciclaje de Active Directory no está habilitada, también puede bajar el nivel funcional del bosque de Windows Server 2012 a Windows Server 2008 R2 o Windows Server 2008 o de Windows Server 2008 R2 de vuelta a Windows Server 2008. Si el nivel funcional del bosque está establecido en Windows Server 2008 R2, no puede revertirse, por ejemplo, a Windows Server 2003.

Después de establecer el nivel funcional del dominio en un determinado valor, no se puede revertir o bajar el nivel funcional del dominio, salvo en las siguientes excepciones: cuando eleve el nivel funcional del dominio a Windows Server 2008 R2 o Windows Server 2012 y si el nivel funcional del bosque es Windows Server 2008 o inferior, tiene la opción de revertir el nivel funcional del dominio a Windows Server 2008 o Windows Server 2008 R2. Solo se puede bajar el nivel funcional del dominio de Windows Server 2012 a Windows Server 2008 R2 o Windows Server 2008, o de Windows Server 2008 R2 a Windows Server 2008. Si el nivel funcional del dominio está establecido en Windows Server 2008 R2, no puede revertirse, por ejemplo, a Windows Server 2003.

Más allá de los niveles funcionales, un controlador de dominio que ejecuta Windows Server 2012 proporciona características adicionales que no están disponibles en un controlador de dominio que ejecuta una versión anterior de Windows Server. Por ejemplo, un controlador de dominio que ejecuta Windows Server 2012 puede usarse para la clonación del controlador de dominio virtual, mientras que un controlador de dominio que ejecuta una versión anterior de Windows Server no puede hacerlo. Pero la clonación de controladores de dominio virtuales y las medidas de seguridad de controladores de dominio virtuales en Windows Server 2012 no tienen ningún requisito de nivel funcional.

Los Eventos 5004 y 5014 en entornos de replica DFSR, son eventos típicos de falta de comunicación con otro miembro DFSR.

Si nuestra topología de red NO emplea IPV6, es muy recomendable desmarcar de las tarjetas de red, todo lo alusivo a TCPIPV6

http://social.technet.microsoft.com/Forums/windowsserver/en-US/d27bd902-034e-4230-9516-0ede42308193/event-5014-dfsr-error1726

Pero también es muy necesario deshabilitarlo del registro mediante la creación/modificación de las siguientes claves de registro;

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

Value =DisableTaskOffload
Type = DWORD
Data = 1

Value =EnableTCPChimney
Type = DWORD
Data = 0

Value =EnableTCPA
Type = DWORD
Data = 0

Value =EnableRSS
Type = DWORD
Data = 0

Disable TCPIPV6
http://support.microsoft.com/kb/929852

KEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters
DisabledComponents to change the DisabledComponents entry – 0xffffffff

Finalmente desde línea de comandos ejecutemos los siguientes comandos netsh;

netsh int tcp set global RSS=Disabled
netsh int tcp set global chimney=Disabled
netsh int tcp set global autotuninglevel=Disabled
netsh int tcp set global congestionprovider=None
netsh int ip set global taskoffload=Disabled
netsh int tcp set global timestamps=Disabled
netsh int tcp show global

Cuando Migramos nuestra infraestructura o instalamos un Domain Controller, por defecto se replica el recurso “sysvol” con FRS, pero como es sabido a partir de ADDS 2008, sysvol tiene su replicación como DFRS, con muchas ventajas. Como decía, por defecto la replica de sysvol es mediante FRS, si queremos migrar la réplica a DFSR, tenemos que realizar unos pasos más para poder migrar este tipo de replicación a DFSR, estos pasos los tenemos que realizar por cada dominio de nuestro Forest, es decir que si tenemos mas de un dominio, tenemos que repetir estos pasos de migración en cada dominio que terminemos de migrar a 2008R2 ó 2012, los pasos son;

Prerrequisitos de Migración

1. Verificar que la replicación de AD es correcta en todos los Domain Controllers de la infraestructura.

2. Realizar el proceso de Domain Functional Level a “Windows Server 2008″ , “Windows Server 2008 R2″ ó «Windows Server 2012», según la versión que estemos implementando.

3. Verificar que el directorio SYSVOL existe en todos los Domain Controllers y el mismo esta replicando mediante FRS.

4. Backup del directorio SYSVOL.

5. Chequear que el servicio “DFS Replication Service” este instalado y corriendo con la configuración en “Automático”, dicho servicio este corriendo en todos los Domain Controllers del dominio.

Tipos de estados en el proceso de migración

Global Migration State – A complete process

Local Migration State – Process on each DC to achieve the Global Migration State

Estados Estables / Estados Globales de Migración

STATE 0 START
STATE 1 PREPARED
STATE 2 REDIRECTED
STATE 3 ELIMINATED

Estados de Transición / Estados Locales de Migración

STATE 4 Preparing
STATE 5 Waiting for initial sync to complete
STATE 6 Redirecting STATE 7 Eliminating
STATE 8 Undo redirecting
STATE 9 Undo preparing

Migracion: 0-4-5-1-6-2-7-3
Vuelta atras: 2-8-1-9-0

Cuando el estado de migración pasa a estar en estado 3, ya no hay posibilidad de volver atrás ni revertir la situación a un estado anterior, con lo cual, correr el comando que para a un estado “3″ tenemos que estar seguros que queremos para nuestra infraestructura, utilizar DFSR para replicación de nuestro SYSVOL.

Comandos de Migración

1. DfsrMig /CreateGlobalObjects

Este comando crear los “global Object” o configuración en Active Directory, para comenzar a utilizar DFSR como servicio de Replicación.

2. DfsrMig /SetGlobalState

Bajo este comando, se agrega al mismo el tipo de estado al que se quiere pasar según siguientes líneas:

0 (‘START’ state)
1 (‘PREPARED’ state)
2 (‘REDIRECTED’ state)
3 (‘ELIMINATED’ state)

3. DfsrMig /GetGlobalState

Nos detalla en qué estado Global está el proceso de migración, esta información es recibida desde nuestro Active Directory, con lo que es importante tener los conceptos de replicación presentes.

4. DfsrMig /GetMigrationState

Nos detalla en qué estado de Migración están todos los Domain Controllers, detallando cada uno y el estado del mismo, esta información es recibida desde nuestro Active Directory, con lo que es importante tener los conceptos de replicación presentes.

A continuación, los resultados y los comandos que tenemos que ir ejecutando serían estos;

Iniciar la migracion:
DFSRMig /CreateGlobalObjects
Create the ReplicationGroup, Content object, ContentSet, and Topology objects

msDFSR-GlobalSettings object under System
msDFSR-ReplicationGroup object under “msDFSR-GlobalSettings”
msDFSR-Content under
msDFSR-ReplicationGroup
msDFSR-ContentSet object under
msDFSR-Content objecte
msDFSR-Topology object under
msDFSR-ReplicationGroup object Sets GlobalState to 0

Preparar estado:

DfsrMig /SetGlobalState 1

The DFS Replication service creates the SYSVOL_DFSR folder

ROBOCOPY copies the contents of SYSVOLdomain to the location SYSVOL_DFSRdomain

Local Active Directory Objects are created. These are ‘Member’, ‘LocalSettings’, ‘Subscriber’, and ‘Subscription The migration local state is set to 5 (MIG_STATE_LOCAL_WAITING_FOR_SYNC) When DFS Replication completes Initial Sync, the Local State is set to 1 (’PREPARED’). Confirm that all domain controllers are in the ‘PREPARED’ state DfsrMig /GetMigrationState

Pasar a estado de “Redirección”

DfsrMig /SetGlobalState 2

The goal of this state is to move the live SYSVOL share from the old SYSVOL folder that NTFRS is replicating to the new SYSVOL folder that the DFS Replication service is replicating. From this point onwards, SYSVOL replication will depend on DFS Replication service Change the SYSVOL patyh in the registry to point to the new location Verify that DFS Replication global migration state is set to ‘REDIRECTED’ DfsrMig /GetGlobalState Confirm that all domain controllers are in ‘REDIRECTED’ state DfsrMig /GetMigrationState

Pasar a estado de “Eliminación”

DfsrMig /SetGlobalState 3

The goal of this state is to delete the NTFRS SYSVOL replica set and delete the old SYSVOL folder Deletes the NTFRS SYSVOL Active Directory configuration objects named ‘Subscriptions’ and ‘Settings’ Verify that the DFS Replication global migration state is set to eliminated DfsrMig /GetGlobalState

Una vez finalizado este proceso de migración, cuyo tiempo depende la cantidad de Domain Controllers que tengamos en nuestra infraestructura y la latencia de los mismos, podemos verificarlo desde nuestro Active Directory. CN=Topology,CN=Domain System Volume,CN=DFSR-GlobalSettings,CN=System,DC=Root1,DC=es,DC=inet donde tendremos que ver, el listado de todos nuestros Domain Controllers los cuales ya estarán usando DFSR como replicación de SYSVOL.

ODX – Windows Offloaded Data Transfer

El gran salvador en la transferencia de datos, podríamos decir que es un concepto derivado de la API de VAAI de Vmware y que llega a Windows Server 2012 muy mejorado, su propósito es evitar que un intermediario, en este caso el servidor, haga funciones de buffering para los datos que se transfieren entre dos equipos externos.  Si configuramos bien ODX, conseguiremos aligerar mucho el movimiento de datos y aliviar la carga en los equipos tanto si hablamos de servidores físicos como virtuales.

ALOJAMIENTO ORIGEN -> SERVIDOR -> ALOJAMIENTO DESTINO

La implementación de ODX permite que el servidor en lugar de intermediar en el flujo de datos y tener que manejar un buffer de información sólo actúa para facilitar «las coordenadas de origen y destino» pero el flujo de datos real se realiza entre las dos fuentes implicadas siempre que soporten esta tecnología.

Para usar ODX, el entorno tanto de almacenamiento como de software deben cumplir una serie de requisitos de hardware y software, el siguiente enlace es bastante didáctico; http://technet.microsoft.com/es-es/library/jj200627.aspx

Centrémonos en el software, que es más nuestro, sistema operativo, W2K12 y W8, ojo con los antivirus y si además somos fanáticos de la seguridad, incompatible con el cifrado en unidades BitLocker y si además has querido probar el nuevo sistema de archivos resistente a errores ReFS, olvídate y de FAT mejor ni hablamos, por que no se admiten ninguno de los dos, tendrem0s que formatear a 64KB en NTFS, lo mejor para alojar máquinas virtuales con extensión vhd ó vhdx para hyper-v en W2K12.

Hyper-V en Windows Server 2012 trae una nueva funcionalidad denominada SHARED NOTHING LIVE MIGRATION, esto significa que las máquinas físicas no deben compartir nada más que una conexión de red en donde las máquinas virtuales a migrar, se mueven en vivo de un chasis a otro con todo con las aplicaciones y sesiones que están ejecutando al momento de la migración.

Antes de Windows Server 2012 para hacer una migración de VMs entre chasis se necesitaba tener un almacenamiento compartido entre los varios servidores físicos, ahora sólo se necesita tener una red entre las «n» máquinas físicas con Windows Server 2012 y las VMs se migran en vivo -por la red- al almacenamiento local, del volumen local 1 al volumen local 2. Importante tener en la cabina el firmware para ODX.

Si además nuestro almacenamiento cuenta con TRIM, que es la manera en que la cabina libera el espacio (en la cabina) cuando borras ficheros en el filesystem tendremos una solución global para la transferencia de datos.

Es decir, borras ficheros, y el OS le informa amablemente a la cabina, que ese espacio lo puede liberar (en la cabina) y seguir jugando cómodamente al thin provisioning reasignando el espacio disponible (en la cabina) de un volumen a otro de los que presenta por arriba a los diferentes hosts que consumen volúmenes de ella.

Se me ocurre advertir, que el proceso de borrado se puede quedar a medias. Para paliar el problema tenemos dos opciones, deshabilitar el TRIM en el OS, con lo que el proceso descrito arriba no se llevaría a cabo y nuestro flamante Windows 2012 se comportaría como un Windows Server anterior. El comando desde un Power Shell es:

fsutil behavior set disabledeletenotify 1 

Pero mejor que deshabilitar TRIM y ODX, en mi post anterior, Roll-up de Hyper-V sobre W2K12 explico los varios fix ó parches relacionados con todo esto del TRIM el ODX, los backups y los CSVs.

Fundamentalmente se consigue que Windows dialogue con la cabina para que la carga que debería hacer en front-end se encargue de hacerla automáticamente la cabina en back-end y así evitar el round-trip time de negociación entre Windows y la cabina.  De esta manera los puertos de front-end quedan libres para el resto de servidores lo que permite mantener buenos tiempos de respuesta siempre que los niveles de utilización de caché estén a niveles normales.

Slide útil de ODX en almacenamiento 3PAR de HP;

En entornos de hyper-v bajo Windows 2012, con y sin CSV, existen algunas revisiones fundamentales de roll-up.

Por ejemplo al realizar Live Migration, en ocasiones se pueden producir un bugcheck D1 DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1), la recomendación de Microsoft para resolver el problema, pasa por instalar el roll-up KB2855336, publicado en julio de 2013, fijaos que destaco en rojo roll-up, por que el problema surge al instalar la versión original del KB2855336, y ahora tras aparecer el problema se ha vuelto a generar el paquete y se ha sacado un fix nuevo con el paquete corregido. Aquí os adjunto varios KBs imprescindibles, junto con las notas técnicas y el acceso a la descarga del roll-up;

1.- KB2855336

Éste KB, incluye otros dos KBs (2862073 y 2866029) 0x000000 D1″ Stop error when you perform a live migration of a virtual machine on a Windows Server 2012-based cluster;

http://support.microsoft.com/kb/2866029/en-us

The issue is fixed in the reoffered update rollup 2855336;

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

2.- KB2870270

Éste roll-up hotfix reemplaza al KB2848344.

El problema que resuelve este fix viene de hace unos meses en los que se detectó en cluster w2k12 con CSV event Id  con 5120 STATUS_IO_TIMEOUT y uno de los workaround era deshabilitar TRIM y ODX

El propósito de este hotfix es la corrección para TRIM y ODX. Con esta revisión del roll-up, ya no es necesario desactivar TRIM o ODX

Muchos sistemas de almacenamiento ofrecen la posibilidad de habilitar ODX, para que desde los host de Windows 2012 podamos hacer Live Migration, la VM se copia por intercambio de token, con SHARED NOTHING LIVE MIGRATION, esto significa que las máquinas físicas no deben compartir nada más que una conexión de red en donde las máquinas virtuales a migrar, se mueven en vivo de un chasis a otro con todo con las aplicaciones y sesiones que están ejecutando al momento de la migración. Con ODX las VMs se migran en vivo -por la red- al almacenamiento local, del volumen local 1 al volumen local 2, siempre y cuando la cabina, tenga el firmware para ODX y si ese es el caso;

Update that improves cloud service provider resiliency in Windows Server 2012;

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

3.- KB2869923

Hyper-V, Clustering y DPM de HP. Este fix es crítico para cualquier implementación de clústeres de Hyper-V que está siendo respaldada por el software de backup de HP, DPM (Data Protector Manager)
Durante el proceso de copia de seguridad de un volumen CSV puede hacer que se detengan algunos recursos;

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

Éste es otro fix crítico, que si bien no es tan nuevo, como los dos anteriores, es un alto generador de llamada CSS y debe ser conocido e implementado.
No se puede acceder a un recurso que está alojada en un equipo con Windows 8 o Windows Server 2012 con CSV

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

Hyper-V sobre Windows Server 2012 ó en su versión free de Hyper-V server, implementa una de las mejoras para los nuevos Virtual Switch y sus características avanzadas, siempre y cuando tanto el hardware de red como el sistema operativo e hypervisor lo ofrezcan.

Es SR-IOV algo muy útil para máquinas virtuales con mucha E/S de red.

¿En qué consiste?

Básicamente en asignarle una tarjeta de red física a la máquina virtual sin que esta pase por el hypervisor, una especie de pass-through para las nics de red de tu sistema servidor.

Aquí podemos ver como una máquina virtual accede de forma directa a la nic del servidor mediante SR-IOV sin pasar por Hyper-V.

Requisitos Hardware

La tarjeta de red debe de soporta SR-IOV.

PCI-SIG SR-IOV requiere el soporte del Sistema Operativo y plataforma de hardware. Algunos sistemas soporte SR-IOV a través algunas ranuras PCI Express, pero no en algunas otras ranuras. Se debe consultar la documentación del fabricante para SR-IOV en el sistema.(Al final dejo varias tarjetas de red que soportan SR-IOV)

Requisitos Software

• Entorno Microsoft Hyper-V sobre W2K12
• VMware vSphere 5.1
• Xen
• KVM

Ventajas

• Reduce el uso de CPU hasta en un 50%
• Menor latencia de red, hasta 50%
• Mayor rendimiento de red, hasta 30%

¿Dónde se implementa?

Tarjetas de Red que soportan SR-IOV

• Familia Intel® Controlador Ethernet X540
  • Controlador Ethernet Intel® X540-AT1
  • Controladora Intel® Ethernet X540-AT2
  • Intel 10GbE X520, 1GbE 82576, and 1GbE I350 controllers
• Adaptador de redes convergentes sobre Ethernet Intel® X540 familia
  • Adaptador de redes convergentes sobre Ethernet Intel® X540-T1
  • Adaptador de redes convergentes sobre Ethernet Intel® X540-T2
• Controlador Intel® 10 Gigabit Ethernet 82599 Familia
  • Intel® 82599EB 10 Gigabit Ethernet Controlador Ethernet
  • Ethernet Intel® 82599ES 10 Gigabit Ethernet Controller
  • Ethernet Intel® 82599EN 10 Gigabit Ethernet
• Adaptador de redes convergentes sobre Ethernet Intel® X520 familia
  • Adaptador Intel® Ethernet X520-DA2 para servidor
  • Adaptador Intel® Ethernet X520-SR1 para servidor
  • Adaptador Intel® Ethernet X520-SR2 para servidor
  • Adaptador Intel® Ethernet X520-LR1 para servidor
  • Adaptador de servidor Intel® Ethernet X520-T2
• Controlador Ethernet Intel® Familia I350
  • Controlador Ethernet Intel® I350-AM4
  • Controlador Ethernet Intel® I350-AM2
  • Controlador Ethernet Intel® I350-BT2
• Adaptador de servidor Intel® Ethernet I350 familia
  • Adaptador de servidor Intel® Ethernet I350-T2
  • Adaptador de servidor Intel® Ethernet I350-T4
  • Adaptador de servidor Intel® Ethernet I350-F2
  • Adaptador de servidor Intel® Ethernet I350-F4
• Controladora Ethernet Gigabit Intel® 82576 Familia
  • Controlador Ethernet Gigabit Intel® 82576EB
  • Controlador Ethernet Gigabit Intel® 82576NS
• Intel® Gigabit ET/EF Familia de adaptadores para servidor
  • Adaptador Intel® Gigabit ET de doble puerto para servidor
  • Adaptador Intel® Gigabit EF de doble puerto para servidor
  • Intel® Gigabit ET2 de cuatro puertos para servidor Adaptador
• Otros
  • Broadcom 10GbE 57712 controller
  • Emulex 10GbE OneConnect controller

Finalmente os adjunto un interesante enlace que explica como un controlador Ethernet de Intel que soporta SR-IOV da apoyo a un entorno virtualizado.

http://www.youtube.com/watch?v=hRHsk8Nycdg

Vamos a configurar los servidores de origen y destino para que envíen y reciban migraciones en vivo sobre la versión de hyper-v de Windows 2012.

Al configurar los anfitriones, debemos elegir si vamos a permitir Live Migration (en adelante LM) en cualquier red disponible o solamente en redes específicas. Por motivos de seguridad es recomendado seleccionar redes específicas para pasar el tráfico de LM y si vamos sobrados de NICs, hacerlo utilizando el propio Team de Windows 2012.

Como configurar los anfitriones de origen y destino para la migración en vivo

1.- Abrir el Administrador de Hyper-V

2.- Desde el panel de navegación, seleccionamos uno de los servidores que vamos a configurar para LM.

3.- En el panel Acción, clic en Configuración de Hyper-V.

4.- En el cuadro de diálogo Configuración de Hyper-V, haga clic en Migraciones en vivo.

5.- En el panel Migraciones en vivo, activemos Habilitar migraciones en vivo entrantes y salientes.

6.- En Protocolo de autenticación, seleccione Kerberos si configuró la delegación restringida, que será en la inmensa mayoría de los casos.

7.- En Migraciones en vivo simultáneas, el valor predeterminado es 2, podemos modificarlo de acuerdo a nuestras necesidades.

8.- En Migraciones en vivo entrantes, y si disponemos de suficientes NICs, podemos usar conexiones de red específicas para aceptar tráfico de LM. Clic en Agregar para escribir la información de la dirección IP, sino, haga clic en Usar cualquier red disponible para la migración en vivo. Haga clic en Aceptar y finalmente debemos seleccione otro servidor en el Administrador de Hyper-V para repetir la misma operativa.

Si lo queremos automatizar vía PowerShell

Escriba cada cmdlet Enable-VMMigration, Set-VMMigrationNetwork y Set-VMHost dependiendo del modo en que quiera configurar el host. Los siguientes comandos de ejemplo configuran la LM en el host local y permiten tráfico de migración entrante solamente en la red especificada y especifican Kerberos como el protocolo de autenticación. Cada línea representa un comando separado.

PS C:\> Enable-VMMigration
PS C:\> Set-VMMigrationNetwork 192.168.81.32
PS C:\> Set-VMHost –VirtualMachineMigrationAuthenticationType Kerberos

Si queremos usar Windows PowerShell para mover una máquina virtual en ejecución

El cmdlet es Move-VM. El siguiente ejemplo mueve una máquina virtual llamada LMABB a un servidor de destino llamado Anfitrion02 y mueve los VDHX de la máquina virtual y otros archivos (paginación inteligente e instantáneas) al directorio D:\LMABB en el servidor de destino.

PS C:\> Move-VM LMABB Anfitrion02 –IncludeStorage –DestinationStoragePath D:\LMABB

Microsoft ha publicado una actualización​ para Office Web Apps Server 2013, de nada menos que 584 MB., esta actualización proporciona las últimas correcciones para 2013 de servidor de OWA y contiene mejoras de estabilidad y rendimiento.

Pero cuidado, para aplicar esta actualización no la apliqueis bajo ningun concepto desde el panel de Windows Update sino quereis quedaros sin por ejemplo presentaciones de Power Point desde el cliente de Lync, debemos hacerlo de la siguiente forma;

1. Quitar la granja de Office Web Apps que tenemos creada: Remove-OfficeWebAppsMachine
2. Descargar e instalar la actualización desde http://www.microsoft.com/es-es/download/details.aspx?id=36981
3. Recrear la granja: New-OfficeWebAppsFarm

Vayamos a ello, primero quitar nuestra granja de Office Web Apps: Remove-OfficeWebAppsMachine y a continuación lo comprobamos: Get-OfficeWebAppsMachine

A continuación pasamos a instalar la actualización, wacserver2013-kb2760445-fullfile-x64-glb.exe, aceptamos los terminos de licencia y pulsamos en Continuar.

Una vez que se ha completado la extracción de los archivos y ha finalizado la instalación solicitará reiniciar. Por último tenemos que volver a recrear nuestra granja: New-OfficeWebAppsFarm -InternalUrl «https://migranja.owa.com» -ExternalUrl «https://migranja.owa.com» –EditingEnabled:$true –CertificateName “office”

Solo nos queda verificar que la actualización ha sido correcto y todo funciona como se espera. Para ello accedemos a la dirección url de detección de servidor de Office Web Apps, que será algo asi como, https://miservidorowa/hosting/discovery/ y nos debe aparecer una página con el siguiente encabezado;

<?xml version=»1.0″ encoding=»utf-8″ ?>

– <wopi-discovery>

– <net-zone name=»internal-https«>

– <app name=»Excel» favIconUrl=»https://miservidorowa/hosting/discovery

Si queremos comprobar que está funcionando realmente podemos compartir desde nuestro cliente de Lync 2013 una presentación de Power Point.

Como ya expusimos en otro post de éste blog, Windows Server 2008 R2 soporta y admite configuración Teaming en las NIC de nuestro hardware, con el siempre condicionante de que dependía de los fabricantes de NIC el desarrollo del software de Team.

En Windows Server 2012, el Team es ahora nativo del sistema operativo, independientemente del fabricante que se encuentre en nuestro CPD.

Hay tres grandes aspectos que destacan en la solución de Team.

• Poder asociar Team NICs para el tráfico de red normal o para el entorno virtual.
• Poder trabajar en Team con NICs de diferentes fabricantes.
• Poder formar Team de hasta 32 tarjetas de red en un solo equipo.

Veamos la interfaz de usuario y las opciones que tenemos disponibles.

En  ésta imagen muestro una configuración de NIC Teaming nativa a Windows Server 2012 y quería resaltar algunos de los puntos de interes de éste nuevo concepto de Team.

Evidentemente necesitamos al menos dos tarjetas de red para crear un equipo y notar que podemos trabajar en un servidor con un máximo de 32 NICs. La creación de un grupo de NIC es muy fácil y personalmente me gusta porque el proceso de instalación respeta los nombres que se colocan en las NICs.

Una vez creado el grupo de NIC, al que he llamado Team 1, podemos seleccionar las NICs que formarán parte de ese Team.

Si ampliamos las propiedades adicionales podremos realizar cambios de configuración en base a la parametrización de red individual que necesitemos y debemos tener opciones para configurar nuestro Team más alla de conformarnos con una configuración estática del tipo; «One Size Fits All».

Como vemos en la imagen de arriba, as propiedades del Team, proporcionan una lista de todas las tarjetas disponibles en el servidor. Aquí podremos elegir qué tarjetas de red deseamos añadir a nuestra configuración de Team.

El nombre que he dado a mis tarjetas de red es uno muy al uso en laboratorios como el mío, «Test NIC 1,» Test NIC 2, y «Test NIC 3» y el Team se llama «Team 1».

A partir de aquí se presentan los detalles adicionales que se pueden configurar para nuestro Team, lo cual nos va a permitir ser muy específicos acerca de cómo el Team, equilibra la carga y se conecta a la red.

MODO TEAMING

Como podemos ver en la imagen el Team se puede configurar para trabajar en Team estático, en modo switch independiente, o LACP (Link Aggregation Control Protocol).

Static Teaming requiere configuración tanto en el switch como en el servidor para identificar los vínculos que formaran el Team. Este modelo de Team nos ofrece un switch dependiente del Teaming que formemos con nuestras NICs.

Switch Independent El modo independiente nos permite distribuir las tarjetas de red en el Team a través de múltiples conmutadores de red ó (Network Switches) en nuestro entorno.

LACP proporciona (Link Aggregation) que podríamos traducir como, la agregación de enlace y además permite la expansión y la reducción del grupo de NIC. Este es un modo de swith ó conmutación independiente del NIC Teaming.
MODO LOAD BALANCING:

Las opciones son o bien Address Hash o Hyper-V Port.

Address Hash es la forma de configurar el Team para el tráfico NLB (network load balancing) entre las NIC que forman el Team.

Hyper-V Port balancea la carga para equilibrar el tráfico que pasa por la VM.

Con Hyper-V Port, la buena noticia es que, las transacciones de cada VM tienen una tarjeta de red por separado, con la desventaja de que que cada máquina virtual sólo puede realizar transacciones a través de una tarjeta de red única. Si tienes varias tarjetas de red virtuales en la máquina virtual y se forma un team para ellas, el Hyper-V Port puede ser la mejor opción.

Para la mayoría de las configuraciones, es muy posible que la Address Hash sea la mejor opción para que la máquina virtual pueda acceder a la red, aún en el caso de que la tarjeta de red de la máquina virtual está dando fallo. Recordemos que con la tecnología Hyper-V Port, un fallo de la NIC de la máquina virtual está causando una interrupción de la comunicación entre, la máquina virtual y la red. Con Address Hash no tendremos éste problema.

STANDBY ADAPTER Ó ADAPTADOR EN ESPERA:

Como bien define su nombre, ésta solución nos permite definir un adaptador de reserva para el equipo. Hay que tener en cuenta que sólo se puede definir un adaptador de espera y además se puede asegurar que el ancho de banda asociado estará disponible incluso si una tarjeta de red de nuestro Team falla.

Fijémonos en las conexiones de red que se nos han formado. Team 1 es una asociación de NICs y notar también que las NIC agrupadas son de diferentes fabricantes.