muchas veces nos preguntamos como podemos comprobar que la infraestructura esta bien, o si el flujo saliente o entrante de correo es correcto para ello les traigo una de las mejores recomendaciones hecha por Microsoft
La mejor Solucion Virtualizada para Seguridad Integral de Red, Balanceo, Firewall, Routing, DNS, VPN.
Como Generar Certificados con multiples Alias para nuestros Servidores de Exchange.
| Protocol | TCP port numbers |
| HTTPS | 443 |
| IMAP4 | 143 and 993 |
| POP3 | 110 and 995 |
| RPC Endpoint Mapper | 135 |
| Address Book service | 59595 |
| RPC Client Access service | 59596 |
adicionalmente y después de instalar y configurar el nlb, y el MS Exchange Server 2010, debemos seguir el siguiente procedimiento para la configuración del ARRAY CAS.
Para poder hacer que el client Access y el libro de direcciones esté disponible en alta disponibles:
· Se deben agregar las siguientes llaves del registro.
o En HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeRPC
o Click derecho MSExchangeRPC, Crear nueva llave.
o escribimos ParametersSystem.
o derecho ParametersSystem, seleccionamos New, y luego click DWORD (32-bit) Value.
o escribimos TCP/IP Port.
o Doble-click TCP/IP Port.
o escribimos 59595 OK.
· Se deben agregar las siguientes llaves del registro.
o En HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeAB
o Click derecho MSExchangeAB, Crear nueva llave.
o escribimos Parameters.
o derecho Parameters, seleccionamos New, y luego click String Value.
o escribimos RpcTcpPort.
o Doble-click RpcTcpPort.
o escribimos 59596 OK.
Adicionalmente debemos ejecutar en el PowerShell Exchange la siguiente liniea de comando para configurar el Array del CAS
| New-ClientAccessArray -Fqdn cas2010.url-interna.local <FQDN of CAS load balanced array> –Site Defaul-First-site<Active Directory Site> |
Para la instalación de los prerrequisitos iniciaremos la consola del PowerShell y le daremos los siguientes comandos.
| Import-Module ServerManager Add-WindowsFeature NET-Framework,RSAT-ADDS,Web-Server,Web-Basic-Auth,Web-Windows-Auth,Web-Metabase,Web-Net-Ext,Web-Lgcy-Mgmt-Console,WAS-Process-Model,RSAT-Web-Server,Web-ISAPI-Ext,Web-Digest-Auth,Web-Dyn-Compression,NET-HTTP-Activation,Web-Asp-Net,Web-Client-Auth,Web-Dir-Browsing,Web-Http-Errors,Web-Http-Logging,Web-Http-Redirect,Web-Http-Tracing,Web-ISAPI-Filter,Web-Request-Monitor,Web-Static-Content,Web-WMI,RPC-Over-HTTP-Proxy -Restart |
Después de reiniciar los servidores se debe de habilitar el servicio de .net TCP Port Sharing.
| Set-Service NetTcpPortSharing -StartupType Automatic |
La función del servidor HUB Transport está diseñada para manejar todo el flujo de correo para la organización de MS Exchange. También es responsable de manejar las reglas de transporte, las políticas de diario y la entrega de mensajes. Este servidor está implementado en el bosque de Active Directory y se requiere para los buzones de MS Exchange Server 2010 para enviar y recibir mensajes. Los mensajes enviados a la Internet se transmiten por el servidor de transporte perimetral en el servidor de transporte perimetral (EDGE).
Se puede añadir un servidor de MS Exchange Server 2010 Transporte de concentradores en una organización existente de Exchange después de desplegar con éxito servidores de Exchange 2010 de acceso de cliente. Después de introducir servidores de MS Exchange Server 2010 de HUB Transport a su entorno de Exchange 2007, todavía los necesitaremos para mantener los servidores de MS Exchange Server 2007 HUB Transport. Los servidores de MS Exchange Server 2010 buzones de correo sólo pueden comunicarse con servidores de Exchange 2010 Transporte de concentradores y servidores de buzones de Exchange 2007 sólo puede comunicarse con servidores de MS Exchange Server 2007 HUB Transport. Cuando se envía un mensaje de un buzón en un servidor de buzones de MS Exchange Server 2010 a un buzón en un servidor de buzones de MS Exchange Server 2007, el mensaje se presentó por primera vez al Servidor más cercano de MS Exchange Server 2010 HUB Trasnport en el sitio. Este servidor retransmite el mensaje a un servidor de MS Exchange Server 2007 HUB Transport en el mismo sitio, que finalmente entrega el mensaje al servidor de buzones de MS Exchange Server 2007.
· Se debe Subscribirse los servidores de transporte perimetral EDGE a la organización de Exchange. Esto permitirá que el flujo de mensajes de Internet a través de Exchange 2010 HUB Transport y EDGE.
o Crearemos un archivo de suscripción perimetral en un servidor de transporte perimetral EDGE.
o Importar un archivo de suscripción perimetral a un sitio de Active Directory.
· Retire el conector SMTP de Exchange 2003 que se utiliza para manejar el correo de Internet. Su cuenta debe ser miembro del grupo local Administradores y miembro de un grupo que ha tenido la función Administrador de Exchange en el nivel de grupo administrativo.
o En Exchange System Manager, expanda el nodo de organización, expanda Grupos administrativos, expanda <AdministrativeGroupName>, Grupos de enrutamiento, expanda <RoutingGroupName>, a continuación, seleccione Conector.
o En el panel de la derecha, haga clic en el conector que desea eliminar y seleccione Eliminar.
· Click clic en Aceptar para confirmar la eliminación.
· Ya que organización necesita tener acceso a Microsoft-Server-ActiveSync, habilitar Microsoft-Server-ActiveSync, como se muestra en el siguiente ejemplo.
| Enable-OutlookAnywhere-servidor: <CAS2010>-ExternalHostname: URL.externa.com -SSLOffloading $ false |
· Se debe configurar un espacio de nombres externo principal durante la instalación, configurar los directorios virtuales de la libreta de direcciones sin conexión (OAB), servicios web de Exchange, Microsoft Exchange ActiveSync, Microsoft Office Outlook Web Access y Exchange Panel de Control (PAC), como se muestra en los siguientes ejemplos.
| Ejemplo configura los directorios virtuales de la OAB. Set-OABVirtualDirectory <CAS2010> \ OAB *-ExternalUrl "https://URL.externa.com/OAB" Ejemplo configura los directorios virtuales de servicios web de Exchange. Set-WebServicesVirtualDirectory <CAS2010> \ * EWS-ExternalUrl https://URL.externa.com/ews/exchange.asmx Ejemplo configura los directorios virtuales de Exchange ActiveSync. Set-ActiveSyncVirtualDirectory-Identidad <CAS2010> \ Microsoft-Server-ActiveSync-ExternalUrl "https://URL.externa.com" Ejemplo configura los directorios virtuales para Outlook Web Access. Set-OwaVirtualDirectory <CAS2010> \ OWA *-ExternalUrl https://URL.externa.com/OWA Ejemplo configura los directorios virtuales para el ECP. Set-EcpVirtualDirectory <CAS2010> \ * ECP-ExternalUrl https://URL.externa.com /ECP |
· Para configurar el Outlook Web de la organización se deben de seguir los siguientes pasos.
o Para obtener la configuración de Outlook Web Access de Exchange Server 2007, ejecute el cmdlet Get-OwaVirtualDirectory.
o Para configurar las opciones de Outlook Web App en Exchange 2010, ejecute el cmdlet Set-OwaVirtualDirectory.
· Para cambiar la configuración de autenticación de ActiveSync.
o Para obtener la configuración de Exchange ActiveSync de su servidor de Exchange 2007, ejecute el cmdlet Get-ActiveSyncVirtualDirectory.
o Para configurar las opciones de Exchange ActiveSync en Exchange 2010, ejecute el cmdlet Set-ActiveSyncVirtualDirectory.
· Cambiar el servidor de generación de la OAB y permitir la distribución de Web en el servidor de Exchange 2010 Acceso de cliente que utiliza los pasos siguientes.
o Mover el OAB.
| Move-OfflineAddressBook "Lista de direcciones sin conexión predeterminada"-Server <MBX2010> |
o agregar el servidor de MS Exchange Server2010 Acceso de cliente como punto de distribución Web.
| $ OABVDir = Get-OABVirtualDirectory-Server <CAS2010> $ OAB = Get-OfflineAddressBook "Lista de direcciones sin conexión predeterminada" $ OAB.VirtualDirectories + = $ OABVdir.DistinguishedName Set-OfflineAddressBook "Lista de direcciones sin conexión predeterminada", VirtualDirectories $OAB.VirtualDirectories |
Importante:
No use el Administrador de IIS para cambiar la configuración de autenticación en el directorio virtual de ActiveSync de Microsoft, ya que el proceso DS2MB en el Powershell de Exchange sobrescribe la configuración almacenada en Active Directory.
· Crearan un legado de un nombre de host en su sistema externo de Nombres de Dominio (DNS) y asociar este nombre de host con el servidor de Exchange 2007 Acceso de cliente o con la infraestructura de su servidor proxy. Consulte "Creación de un nombre de host Legacy" en otro articulo explicaremos con mas detalles este tema.
Una vez realizado este procedimiento se deberán realizar las configuraciones oportunas para cambiar el punto de acceso desde internet, en los Firewall correspondientes.
Para el proceso de migración de debe seguir la siguiente secuencia para una migración desde Exchange 2007 a Exchange 2010 es el siguiente:
1. Actualice todos los servidores de Exchange a Exchange Server 2007 Service Pack 2 (Se recomienda la instalación del Service Pack 3).
2. Llevar el bosque de AD y los dominios de Windows Server 2003 Funcional (o más) niveles.
3. Actualiza por lo menos un controlador de dominio de catálogo global en cada sitio que albergará AD Exchange Server a Windows Server 2003 SP2 o superior.
4. Prepare un equipo Windows Server 2008 (RTM o R2) servidor de edición de 64 bits para el primer intercambio Server 2010.
5. Instalar las herramientas de LDIFDE AD en el nuevo servidor de Exchange 2010 (para actualizar el esquema).
6. Instale los requisitos previos necesarios (WWW para la función del servidor CAS).
7. Ejecutar la instalación en el servidor de Exchange 2010, actualizar el esquema, y preparar el bosque y los dominios. (La instalación se ejecuta en un solo paso o por separado en la línea de comandos.)
8. Instalación de servidores CAS función de servidor y configurar por el diseño establecido 2010. Validar la funcionalidad.
9. Transferencia de OWA, ActiveSync y Outlook en cualquier lugar de tránsito a los nuevos servidores CAS.
10. Instale papel de HUB y configure por diseño 2010.
11. La transferencia de tráfico de correo entrante y saliente en el 2010 los servidores de HT.
12. Instalar y configurar servidores de buzones de bases de datos (DAG si es necesario).
13. Crear réplicas de carpetas públicas en servidores de Exchange 2010 con AddReplicatoPFRe-cursive.ps1 o herramienta de Exchange 2010 de carpetas públicas.
14. Mueva los buzones de Exchange 2010 mediante el Asistente para mover buzón o Powershell.
15. Volver a asignar la Libreta de direcciones sin conexión (OAB), servidor de generación de Exchange Server 2010.
16. Transferencia de todas las réplicas de carpetas públicas de Exchange Server 2010 almacén de carpetas públicas.
17. Eliminar almacenes de información públicos y privados del servidor de Exchange 2007 (s).
18. Desinstalar todos los servidores de Exchange 2007.
Una de las áreas de cambio que se debe tomar en cuenta en la transición a Exchange 2010 que es diferente que en su implementación de Exchange 2007 es la alta disponibilidad y funciones de recuperación de desastres en la función del servidor Buzón. Porque los conceptos de clústeres de copia única, replicación continua en clúster (CCR), y Replicación continua en espera (SCR) ya no existen en Exchange 2010, en la transición de sus buzones de correo de Exchange 2007 que tiene las siguientes funciones de Exchange 2010 que la base de datos de Grupos de usuarios en disponibilidad (DAG). Por supuesto, si son sólo la migración a un servidor de buzones de Exchange 2010 sin una sola en alta disponibilidad o recuperación de desastres, a continuación, sólo tendrá bases de datos de buzones que se le mueven sus buzones de correo a otro. Sin embargo, para las organizaciones ejecutoras de alta disponibilidad y recuperación ante desastres, el DAG proporcionar la replicación de correo electrónico (de hasta 16 copias) de un servidor a otro. Cuando la configuración de su buzón de servidores de Exchange 2010 para prepararse para la transición de buzones de correo, la configuración de replicación DAG y poner a prueba su conmutación por error y conmutación por recuperación de los servidores de buzones de Exchange 2010, y luego mover los buzones al DAG.
Otra área de cambio entre Exchange 2007 y Exchange 2010 es que todas las conexiones de clientes a través del servidor CAS. A diferencia de Exchange 2007 y antes de que las conexiones OWA fue a través del servidor CAS pero Outlook (2003/2007) establece las conexiones directamente a través de MAPI para los servidores de buzones back-end. Sin embargo, con Exchange 2010, los sistemas cliente ya no se comunican directamente con los servidores de buzones back-end. En cambio, las conexiones de cliente MAPI contra el servidor CAS que se comunican con los servidores de buzones en el servidor. Así que al igual que en el cambio de servidores de transporte perimetral de Exchange 2007 en todas las rutas de correo a través de los servidores de HUB (los correos entrantes, salientes, de usuario a usuario de correo entre los servidores, e incluso para el usuario de correo de usuario entre los usuarios en el mismo servidor), con Exchange 2010, todos los clientes a través del servidor CAS. Por lo tanto, los servidores CAS tomar más de una carga de rendimiento y tienen que ser reforzado un poco. Nuestras recomendaciones para el CAS de buzones de Exchange 2007 es un servidor CAS de cada dos servidores de buzones. Para Exchange 2010, nuestra recomendación es de 3 servidores CAS de cada 4 servidores de buzones. La mayoría de organizaciones tienen por lo menos dos servidores CAS en su entorno para la redundancia, y porque se puede virtualizar la función CAS Plus tienen 2000, 3000, hasta 5.000 buzones de correo en un servidor de buzones individuales, que suelen encontrar este CAS 03:04: MBX relación sido sensacional para las organizaciones en términos de un cambio de diseño.
También es importante destacar que todas las funciones de servidor (CAS, HUB, Buzón de correo) en Exchange 2007 deben permanecer hasta que todos los usuarios se migran a Exchange 2010. Exchange 2010 CAS, HUB y servidores de buzones no son compatibles con Exchange 2007, así que para que un usuario pueda acceder a Outlook Web Access en Exchange 2007, Sera necesario que se conecte a uno de los servidores Exchange 2007 CAS para acceder a su buzón de correo en 2007 del servidor de buzones. Después de que su buzón se migra a Exchange 2010, el usuario llegará al servidor de Exchange 2010 CAS y el acceso a sus buzones de correo en el servidor de buzones de Exchange 2010. Debido a que Exchange 2010 tiene un servicio de proxy en el servidor CAS, la dirección URL externa para OWA puede apuntar a la CAS de Exchange Server 2010 y si el buzón del usuario está todavía en Exchange 2007, el servidor CAS/2010 pasará automáticamente la conexión del cliente a la CAS / 2007 del servidor de OWA.
Por último, pero no menos importante, después de mover buzones fuera de Exchange 2007 a Exchange 2010, Exchange 2007 debe de salir de la infraestructura necesaria para unas dos semanas. Al dejar el antiguo servidor de Exchange 2007 en su lugar, cuando un cliente de Outlook intenta conectarse al buzón del Server 2007 para su correo, el antiguo servidor de Exchange 2007 se notificará a los software de cliente de Outlook que el correo del usuario se ha trasladado a los Exchange Server 2010 y se actualizará automáticamente el perfil del usuario de Outlook con la información de destino del nuevo servidor. A partir de entonces, cuando el cliente de Outlook se pone en marcha, Outlook cambiara el acceso al buzón del usuario en el nuevo servidor de Exchange 2010. Al salir de esta infraestructura el cambio se llevara a cabo en un par de semanas, casi todos los usuarios que inicie el Outlook para que el perfil cambie automáticamente por lo que no requiere ninguna intervención del sistema cliente durante el proceso de migración. Los únicos usuarios que probablemente tendrá que reiniciar manualmente su perfil de Outlook son los usuarios que están en excedencia y que no había accedido a su correo de Outlook durante el tiempo de 2 semanas que tenía el entorno de Exchange 2007 sigue en pie.
HP System Insight Manager (HP SIM) se encarga de la supervisión de la infraestructura virtual. CLIENTE ha optado por utilizar Insight Manager y el MIB asociado que se va a instalar en cada host ESX como se muestra en el siguiente diagrama. SNMP deben estar habilitadas en la configuración de seguridad del cliente vSphere.
Esto lo lograremos instalando el cliente VSphere en el HP SIM y Instalado el modulo de SIM VCENTER, que se encuentra en el DVD de instalación de HP SIM
Una SAN es una infraestructura que proporciona almacenamiento y gestión del propio almacenamiento dentro de una empresa. Típicamente una SAN conecta uno o varios servidores con algún dispositivo de almacenamiento como se muestra en la siguiente figura.
Esta red de almacenamiento tiene como propósito liberar a la red local LAN del tráfico que originan, entre otras cosas, las copias de seguridad y además agregar sistemas de tolerancia a fallo, eliminar los puntos únicos de fallo, manejar grandes volúmenes de información, facilitar la recuperación, repartición y reasignación de espacio en disco.
Las SAN´s reducen al mínimo la necesidad de disponer de servidores equipados con grandes discos donde se almacena localmente la información y además permiten también tener un almacenamiento centralizado para multitud de sistemas de ficheros de sistemas operativos distintos como Windows, Unix, Linux, etc.
El hecho de que servidores y sistemas de almacenamiento compartan la misma red permite la transferencia de datos de tres maneras distintas:
- Entre servidor y almacenamiento. Es el modelo tradicional de interacción, aunque en el caso de una SAN el mismo dispositivo de almacenamiento puede ser accedido por múltiples servidores.
- Entre servidores. La propia SAN puede usarse como medio de comunicaciones entre servidores.
- Entre dispositivos de almacenamiento. La SAN permite la transferencia de datos entre sistemas de almacenamiento sin intervención directa de los servidores.
Son diversas las aplicaciones de una SAN. A continuación se enumeran algunas de ellas.
- Gestión centralizada: Una SAN permite agrupar los dispositivos de almacenamiento formando elementos especializados y separados de los servidores. Ya no necesitamos una tarjeta RAID y varios discos para cada servidor, con una cabina de discos y varios servidores en una SAN optimizamos la gestión del almacenamiento. La interconexión de todo el almacenamiento dentro de la misma infraestructura de red permite la utilización de las técnicas de gestión globales propias de las redes en una SAN.
- Protección de datos: La oportunidad de conectar unidades de cintas magnéticas a una SAN abre la posibilidad de descargar la red de datos del tráfico de copias (LAN-less backup), incluso si los elementos de la red tienen la funcionalidad adecuada se pueden realizar las copias de disco a cinta sin pasar por el servidor (server-free o server-less backup). Nuevas técnicas de protección de datos pueden implementarse en una SAN: mirroring entre dos volúmenes remotos, snapshots de volúmenes como paso intermedio para un volcado a cinta, etc.
- Alta disponibilidad: Una SAN permite que varios servidores tengan acceso al mismo volumen de datos por uno o varios caminos dependiendo de la topología y configuración de la misma. Es el escenario adecuado para los entornos críticos y para la implementación de clusters de servidores.
- Continuidad de negocio: Una SAN puede extenderse a largas distancias, incluso su tráfico puede ser encaminado a través de otras redes de área extensa. Esto permite soluciones de recuperación ante desastres.
Los componentes de una SAN se conectan entre sí principalmente por canales de fibra óptica (Fibre Channel).
El canal de fibra aprovecha todas estas tecnologías, tales como FDDI, SCSI, IP, etc. y permite seguir utilizando protocolos establecidos, funcionando a través de un cable de cobre de hasta 100 metros o de un cable de fibra óptica de hasta 10 kilómetros, posibilitando la colocación de dispositivos de almacenamiento en lugares seguros, un aspecto importante para cuestiones de recuperación en caso de desastre.
La interconexión de los nodos de una red de fibra se realiza mediante tres topologías físicas:
- Punto a punto (Point-to-Point): Conexión única entre dos nodos. Todo el ancho de banda es usado por estos dos nodos.
- Bucle arbitrado (Arbitrated Loop): En esta topología el ancho de banda es compartido entre todos los nodos conectados al bucle. Es similar al concepto de red Token Ring en el cual los nodos que lo componen forman una red en anillo y se van pasando el testigo de uno a otro. Para la conexión de todos los dispositivos de un bucle, hasta un total de 127, se utilizan concentradores (hubs).
- Conmutado (Switched): Permite múltiples conexiones concurrentes entre todos los nodos que estén conectados a un switch o red de switches (fabric).
Los elementos que forman parte de una red de almacenamiento se pueden clasificar en tres grupos.
- Una red de almacenamiento debe ser una red abierta y heterogénea en la que entre a formar parte todo tipo de servidores con todo tipo de sistemas operativos que puedan acceder al almacenamiento de la red.
- La red entre los servidores y el almacenamiento será transparente a las aplicaciones, que verán los discos y cintas magnéticas compartidas como si fuesen dispositivos locales del sistema.
- Los servidores se conectan a la SAN mediante uno o varios adaptadores Fibre Channel (HBA, Host Bus Adapter).
- El sistema operativo deberá estar optimizado para la nueva situación:
- Número elevado de dispositivos.
- Varios caminos distintos alternativos para acceder al mismo dispositivo con reconfiguración automática en caso de caída de un camino.
Sistemas de ficheros adaptados a las nuevas capacidades de crecimiento.
Los dispositivos de almacenamiento son la base de la SAN. La SAN libera el almacenamiento de tal manera que ya no forma parte de un bus particular de un servidor, es decir, el almacenamiento se externaliza y su funcionalidad se distribuye. Tanto unidades de cinta magnética o librerías y robots de cintas como cabinas de discos se conectan directamente a la red Fibre Channel (fabric).
Las cabinas de discos se diseñan teniendo en cuenta la importancia de la disponibilidad y seguridad de los datos contenidos en sus dispositivos. Elementos redundados e intercambiables en caliente: controladoras, módulos de caché, baterías, fuentes de alimentación, discos. El componente fundamental de una cabina de discos es su controladora, normalmente emparejada con otra igual.
Las controladoras se conectan a la SAN mediante puertos Fibre Channel y a la estructura interna de la cabina mediante buses SCSI o conexiones Fibre Channel internas formándose un doble bucle balanceado. Los discos serán dispositivos propiamente SCSI o discos Fibre Channel. Las controladoras tiene funcionalidades de redundancia y paridad tipo RAID, de acceso a los volúmenes o LUN por ellas gestionadas (LUN Masking) y capacidad de tomar el control del sistema transparentemente si su pareja falla.
Toda la terminología de una red de datos se hereda en el mundo de las SAN para definir los dispositivos y elementos usados para interconectar los servidores con el almacenamiento.
Ya se ha mencionado al hablar del estándar Fibre Channel que existe cableado y conectores tanto para cobre como para fibra óptica multimodo y monomodo. Igualmente existen otros elementos como adaptadores de media (MIA), convertidores de interface (GBIC, SFP) y extensores para facilitar mayores distancias en los enlaces.
Un switch o conmutador es un equipo de red de alto rendimiento capaz de interconectar muchos dispositivos o interactuar con otros conmutadores. Al conjunto de conmutadores de una red se denomina fabric o switch fabric. Cualquier dispositivo conectado a un puerto de un conmutador puede conectarse con cualquier otro dispositivo de la red.
La infraestructura de conmutadores de una red es la encargada de encaminar todo el tráfico de un dispositivo a otro. También tienen la funcionalidad de restringir a qué puertos puede otro puerto conectarse mediante lo que se denomina “Port Zoning”, recomendado a la hora de mezclar en una misma SAN clusters de servidores y dispositivos de copia en cinta.
Un puente o bridge SCSI permite conectar dispositivos SCSI tradicionales a una red Fibre Channel. Existen también routers o encaminadores que permiten conectar una red Fibre Channel con otro tipo de redes: ATM (Asyncronous Transfer Mode ), IP.
en esta ocacion les traigo algo que para mi es el mejor software de backup que he visto en el mercado para Xenserver, aun tiene fallos pero lo ha ido mejorando y lo mejor de todo es un producto español, Se llama XenBackup.
XenBackup es, como ellos mismos indican en su web un software de copias de Seguridad para XenServer y de su configuración a un coste muy bajo con un aplicativo intuitivo y muy fácil de utilizar que aporta las siguientes características:
La licencia proporciona además de actualizaciones, consultas y soporte de instalación y configuración a través de teléfono o correo electrónico.
La instalación esta soportada en:
Durante el mismo se nos solicitará instalar una serie de componentes de Citrix.
Para el correcto funcionamiento será necesario deshabilitar UAC. User Control Access, este control de cuentas de usuario solicita autorización cada vez que se lanza un programa no identificado lo que causaría que XenBackup se cortará y no funcionara correctamente.
Para deshabilitar el mismo, seguiremos las indicaciones aparecidas en el mensaje de aviso.
El primer punto del proceso es configurar el acceso a nuestro servidor Xen. Podemos ver una muestra de lo fácil que resulta el proceso en la siguiente captura.
Validada la conexión con nuestro XenServer se nos mostrarán las VM disponibles en el Pool.
Guardamos y procedemos a configurar el proceso de Backup.
Activado el producto vamos a empezar a probar el mismo, para empezar tendremos la posibilidad de crear un tarea, en la que tras indicar la definición, podemos indicar de que maquinas realizará el Backup, hora de inicio, los días y opciones adicionales como:
Seleccionamos el destino de Backup y ya tenemos la tarea creada.
El servicio cron nos permite definir tareas automatizadas para que nuestro sistema Linux las ejecute sin necesidad de que tecleemos los comandos continuamente.
El Cron nos permite establecer la hora, la fecha y la periocidad de la ejecución del comando, permitiendo automatizar tareas repetitivas y facilitando nuestra labor diaria.
Cron puede ser interpretado como un servicio de Linux que se carga durante el proceso de arranque de nuestro sistema.
Para ejecutar tareas, cron usa un archivo conocido como crontab. El archivo crontab esta, generalmente, localizado en el directorio /etc. en /var/spool/cron/ localizamos también ficheros de cron que hacen relación a un usuario en concreto. (ver directorio)
Como usar el Crontab
El primer paso es abrir crontab. Para ello, podemos utilizar cualquier editor de textos, como vi, joe o emacs. También podemos editar crontab tecleando “crontab -e” utilizando de este modo el editor vi para su edición. (ello editara por defecto el crontab del usuario que invoca el comando)
El crontab utiliza el siguiente formato.
[minutos] [horas] [dias] [mes] [dias de la semana] [usuario] [comando]
minutos: 0-59
horas: 0-23
dias: 1-31
mes: 1-12
Dias de la semana: 0-6 (de domingo a sábado)
Usuario: usuario con el que se lanza el comando
Comando: comando a lanzar
El orden de los valores debe ser mantenido. En lugar de un valor, podemos usar tambien el caracter “*” el cual sera utilizado como comodín, es decir, si ponemos en dia de la semana un *, significara que se lanzara cada dia, si ponemos en el de los minutos, se lanzara el comando a cada minuto.
También es posible especificar rangos con “-“, si ponemos en dias de la semana, 0-3, el comando se ejecutara, domingo, lunes, martes, miercoles. Igualmente podemos indicar dias o horas separadas, utilizando la “,“, asi pues usando 0,3 el comando solo será lanzado los dias domingo y miércoles.
Ejemplo: Teniendo en cuenta que disponemos de un script en nuestro directorio personal llamado borrado.sh con sus respectivos permisos)
Editamos el crontab y añadimos:
$ crontab -e
# comentario sobre la tarea
30 22 1,15 * * cristiansan /home/cristiansan/borrado.sh
Esto ejecutaria el script borrado.sh a las 22:30 de cada dia 1 y 15 de cada mes, sin tener en cuenta el dia de la semana.
Cabe tener en cuenta además los ficheros /etc/cron.deny y /etc/cron.allow.cron.deny nos permite definir usuarios los cuales no tendran acceso a crontab. Su formato es muy sencillo, un usuario por linea. El espacio en blanco no esta permitido, tampoco es necesario reiniciar el demonio cron tras el cambio realizado, estos ficheros son leidos por crontab cuando se intenta acceder a el.
root siempre debe disponer de acceso a cron. Si el fichero cron.allowexiste, solo los nombres que hay en dicho fichero tendrán acceso a cron, y cron.deny será ignorado.
Si cron.allow no existe, cron consultará cron.deny y denegará el acceso a los usuarios que aparezcan en este.
Aplicando CRON en XenServer
Crontab nos ofrece el poder para automatizar muchas tareas dentro de nuestro XenServer tales como borrado de logs, update programados, reinicios y todo aquello susceptible de realizar en línea de comandos (CLI).
Un ejemplo práctico podría ser el programar un pequeño script de pausado o suspendido de VM en ejecución y uno de arranque. Utilizando CRON podríamos establecer que a cierta hora, en la cual no son necesarias ciertas VM, suspender las mismas y configurar el mismo cron para que a cierta hora (principio de la jornada) las arranque.
Los siguientes son dos scripts muy sencillos (podrían mejorarse mucho) que pausan el estado de la máquina arrancadas y arrancan las máquinas pausadas anteriormente respectivamente.
Los scripts son llamados pause.sh y unpause.sh. Una vez editados podemos añadir las siguientes líneas en Crontab:
00 20 * * [1-5] ctxdom /home/ctxdom/pause.sh
00 07 * * [1-5] ctxdom /hom/ctxdom/unpause.sh
Ello ejecutara el script de pausado a las 20:00h de Lunes a Viernes y arrancara las máquinas igualmente de Lunes a viernes a las 7 AM.
A continuación dejo los dos scripts realizados a modo orientativo:
Pause.sh (Script de pausado de máquinas en ejecución)
#!/bin/bash
echo "Listando VMs en ejecucion..."
sleep 2
xe vm-list params=uuid power-state=running | grep uuid | cut -c 17-63 > /tmp/listado.vm
declare -a VM
exec</tmp/listado.vm
let count=0
while read line; do
VM[$count]="$line"
count=$(($count+1))
done
COUNTVM=`wc -l /tmp/listado.vm | cut -c1-2`
VMPI=0
echo "VM totales en ejecucion...: $COUNTVM"
sleep 3
while [ $VMPI -lt $COUNTVM ]
do
xe vm-pause uuid=${VM[$VMPI]}
echo "Pausando maquina: $VMPI"
sleep 2
2>/dev/null
VMPI=$(($VMPI+1))
done
echo "Finalizado"
unpause.sh (Script de arrancado de máquinas pausadas)
#!/bin/bash
echo "Listando VMs en ejecucion..."
sleep 2
declare -a VM
exec</tmp/listado.vm
let count=0
while read line; do
VM[$count]="$line"
count=$(($count+1))
done
COUNTVM=`wc -l /tmp/listado.vm | cut -c1-2`
VMPI=0
echo "VM totales pausadas...: $COUNTVM-1"
sleep 3
while [ $VMPI -lt $COUNTVM ]
do
xe vm-unpause uuid=${VM[$VMPI]}
echo "Arrancando maquina: $VMPI"
sleep 2
2>/dev/null
VMPI=$(($VMPI+1))
done
echo "Finalizado"
El procedimiento es muy sencillo y no causa mayores dificultades, para ello seguiremos los siguientes pasos:
• Conectaremos nuestro USB drive a nuestro Host XenServer
• Accederemos a la consola CLI
• Una vez en la consola, verificaremos que discos hay disponibles, mediante el comando:
# fdisk -l
• Dispondremos de un listado, donde /dev/sdb podría ser nuestro dispositivo, estándo este marcado como:
Disk /dev/sdb: 1024 MB, xxxxxxx bytes
• Una vez reconocido, ejecutaremos el siguiente comando para que sea reconocido:
# pvcreate /dev/sdb
• Verificaremos y checkearemos el ID del disco que ha sido asignado, cambiando posteriormente al directorio by-id, mediante el comando:
# cd /dev/disk/by-id/
• Listaremos las unidades disponibles,
# ls
• Donde visualizaremos algo parecido a esto:
scsi-SATA_FABRICANTE_HTD123123123123123XXXXXXX
usb-USB_Flash_Drive_AA00000099900XXXX
• Añadiremos posteriormente el disco al sistema mediante:
# xe sr-create type=lvm content-type=user device-config:device=/dev/disk/by-id/ usb-USB_Flash_Drive_AA00000099900XXXX name-label="Local USB Storage"
Una vez realizado esto, podremos utilizarlo desde XenCenter donde observaremos que ha estado añadido a nuestro HOST.
Funcionamiento de Dom0 en cuanto a asignación de memoria para las distintas VMs, tenemos que tener en cuenta que la memoria reservada de Dom0 no es una memoria que podamos utilizarla de forma infinita, y en muchas integraciones suceden casos realmente curiosos. Pondremos un ejemplo para entender el funcionamiento, imaginemos que tenemos un servidor HOST con 12GB de memoria, este servidor Host dispone de un Dom0 el cual está asignado a un Pool, bién, ese Host tiene un espacio de memoria reservado de 752MB por defecto, de esos 752MB, se reservan 400MB para Dom0, y por cada VM que se crea nueva, se genera un DomU donde se asignan 6MB para cada una de las distintas VMs que creemos,el DomU tendrá permisos de lectura sobre el mismo, pero no los permisos de root como dispone Dom0 por defecto.
Con ello podremos indicar que:
6MB * n = Total DomU
Si realizamos la operación completa tendríamos que:
400MB + (6MB * n) = Memoria requerida para en VMs Siendo el total de la operación un máximo de unas 60VMs por Host
XenServer 5.6 incluye la nueva característica del control dinamico de memoria y como configurarlo.
![clip_image002[1]](http://lh4.ggpht.com/-XQSAIUMFLeo/T1X8EjF4MGI/AAAAAAAAGp4/lbeC42Oc7hc/s1600-h/clip_image002%25255B1%25255D%25255B2%25255D.jpg "clip_image002[1]")
En el podemos monitorizar la "visión global" de la memoria utilizada, así como los efectos individuales de cada máquina virtual - para saber realmente cómo y dónde la memoria está siendo utilizado.
Este es el exceso que ha sido utilizado en muchas plataformas VMWare ha sido siempre conocido por. Control dinámico de memoria (DMC) y ofrece las siguientes ventajas:
Para cada máquina virtual, el administrador puede establecer un rango de memoria dinámica - este es el rango dentro del cual la memoria puede ser añadida / borrada de la máquina virtual sin necesidad de reiniciar. Cuando una máquina virtual se ejecuta el administrador puede ajustar el rango dinámico.
![clip_image003[1]](http://lh3.ggpht.com/-2JBB3w0j9AY/T1X8GDF9aUI/AAAAAAAAGqI/wymKrOvw6og/s1600-h/clip_image003%25255B1%25255D%25255B2%25255D.jpg "clip_image003[1]")
XenServer siempre provee de las garantías de la cantidad de memoria asignada a la máquina virtual dentro del rango dinámico, por lo que ajustar la máquina virtual mientras está en ejecución en XenServer es realmente sencillo.
![clip_image004[1]](http://lh4.ggpht.com/-V2HyDzivAeQ/T1X8Ix-P2bI/AAAAAAAAGqU/EAYVW3gmWa4/s1600-h/clip_image004%25255B1%25255D%25255B2%25255D.jpg "clip_image004[1]")
DMC permite además configurar memoria dinámica mínima y límites máximos de memoria - la creación de una memoria dinámica Range (DMR) que la máquina virtual funcionará automáticamente en XenCenter, esto se puede configurar como una memoria fija, o un rango. La gama se puede definir de forma manual o utilizando la herramienta gráfica para deslizar los puntos de ajuste.
En algunas ocasiones podemos encontrarnos que al intentar dejar un servidor del Pool de XenServer en modo de mantenimiento, nos aparezca el error de "Server could not be contacted", en este apartado mostramos como solucionar este problema.
El error sería similar al que mostramos en la siguiente imagen, ello debido a un cambio de Pool, o al añadir algún nuevo servidor al mismo.
Visto esto y para solucionarlo, accederemos al servidor en cuestión, en nuestro ejercicio en el servidor xenserver-01, accediendo posteriormente a console, tal y como se muestra,
Desde línea de comando realizaremos una sincronización del Pool, tal y como se muestra,
Este mostrará si hay algún servidor que no puede ser sincronizado con el pool y sincronizará los actualmente existentes,
Posteriormente nos dará el UUID, utilizaremos este UUID para especificar que dicho server es unrecoverable para posteriormente poder realizar y activar el modo de mantenimiento del existente, para ello utilizaremos el comando xe host-forget uuid=<numero_UUID_localizado> , solucionando de esta forma la problemática localizada, tal y como se muestra anteriormente, pulsando en "Yes" para que realice dicho proceso
Los pasos que tendremos que realizar son los siguientes,
1) Deshabilitaremos la Alta disponibilidad (HA).
a. Este paso podremos realizarlo desde XenCenter o bién mediante línea de comando.
b. xe pool-ha-disable
2) Listaremos que xenServer hosts están disponibles
a. xe host-list
3) Utilizaremos el listado para detectar el UUID asociado al servidor que necesitemos migrar.
4) Posteriormente escribiremos:
a. xe pool-designate-new-master host-uuid=<con el UUID que hemos observado>
5) Posteriormente a ello, perderemos la conexión durante un rato, una vez pasado, escribiremos:
a. xe pool-ha-enable
También será posible realizarlo mediante el acceso a modo manternimiento del Pool Master, ello nos permitirá realizar el cambio y asignar un nuevo Master Pool., una vez finalizado podremos habilitar nuevamente el modo de mantenimiento.
Performance VM XenServer es una máquina virtual que ayuda a solucionar problemas relacionados con el rendimiento, tales como el bajo rendimiento causada por el almacenamiento de storage I/O y network I/O. La máquina virtual, basada en Debian Linux, está equipada con servicios de prueba y es accesible mediante una interfaz de usuario basada en Web:
Puede ser utilizado para llevar el control del disco después de operaciones de I/O para medir: sequential read/writes y random read/writes con diferentes tamaños de bloque. Esta utilidad pruebas el rendimiento y se evalúa el desempeño de un determinado Storage Repository mediante la lectura y escritura de datos en un disco de prueba virtual, creado por el usuario específicamente para esta prueba.
Es básicamente una versión modificada del netperf. Información adicional acerca de netperf se puede encontrar en http://www.netperf.org. Netperf se ejecuta en el backend y proporciona solicitud de extremo a extremo / ronda de respuesta de latencia de viaje y TCP / UDP pruebas de rendimiento.
| Acción | Captura de pantalla (si está disponible) |
| 1) Descomprimir la maquina Virtual. |
|
| 2) Importaremos la maquina virtual |
|
| 3) Agregaremos discos de 2 gigas de cada almacenamiento. |
|
| 4) Cambiaremos la IP |
|
| 5) Iniciaremos el servicio WEB |
|
| 6) Nos pedirá realizar pruebas de escritura en los discos |
|
| 7) Pondremos la contraseña del root |
|
Ahora en un Browser poniendo la http://ip-host:8888
Podremos hacer las pruebas de performance de discos y redes.
Para Instalar antivirus y configurar las siguientes exclusiones (la mayoría de programas antivirus le permite excluir determinados directorios, archivos y procesos de exploración para ayudar a lidiar con problemas como estos):
1. Los directorios donde se guardan las configuraciones de las configuraciones de las maquinas virtuales es la siguiente (C:\ProgramData\Microsoft\Windows\Hyper-V)
2. Los directorios donde se guardan los ficheros de las configuraciones de las maquinas virtuales es la siguiente (C:\Users\Public\Documents\Hyper-V\Virtual Hard Disks, C:\ClusterStorage\Volume1, C:\ClusterStorage\Volume2, C:\ClusterStorage\Volume3)
3. Los directorios donde se guardan los ficheros de los Snapshot de las maquinas virtuales es la siguiente (%systemdrive%\ProgramData\Microsoft\Windows\Hyper-V\Snapshots; C:\ClusterStorage\Volume1, C:\ClusterStorage\Volume2, C:\ClusterStorage\Volume3).
4. Las siguientes ejecutables
i. Vmms.exe.
ii. Vmwp.exe
Para la Excepciones del clúster utilizaremos las siguientes:
1. Q:\(Quorum Drive)
2. \Windows\Cluster
Para la conexión entre los Hyper-V y El MS SCVMM.
| Tipo de conexión | Protocolo | Puerto | Servicio |
| VMM server to VMM agent on Windows Server–based host (control) | WinRM | 80 | During VMM setup, registry |
| VMM server to VMM agent on Windows Server–based host (data) | SMB | 445 | Registry |
| VMM server to remote Microsoft SQL Server database | TDS | 1433 | Registry |
| VMM server to P2V source agent | DCOM | 135 | Registry |
| VMM Administrator Console to VMM server | WCF | 8100 | During VMM setup, registry |
| VMM Self-Service Portal Web server to VMM server | WCF | 8100 | During VMM setup |
| VMM Self-Service Portal to VMM self-service Web server | HTTPS | 443 | During VMM setup |
| VMM library server to hosts | BITS | 443 | During VMM setup, registry |
| VMM host-to-host file transfer | BITS | 443 | Registry |
| VMRC connection to Virtual Server host | VMRC | 5900 | VMM Administrator Console, registry |
| VMConnect (RDP) to Hyper-V hosts | RDP | 2179 | VMM Administrator Console, registry |
| Remote Desktop to virtual machines | RDP | 3389 | Registry |
| VMware Web Services communication | HTTPS | 443 | VMM Administrator Console, registry |
| SFTP file transfer from VMWare ESX Server 3.0 and VMware ESX Server 3.5 hosts | SFTP | 22 | Registry |
| SFTP file transfer from VMM server to VMWare ESX Server 3i hosts | HTTPS | 443 | Registry |
Siempre se recomienda la utilización de una red privada, en el caso de la instalación de cluster Service. Para la red de HeardBit.
La base de datos Virtual Machine Manager (VMM) es una base de datos de SQL Server que contiene toda la información de configuración de VMM.
Es importante realizar copias de seguridad regulares de la base de datos VMM como parte de un plan de copia de seguridad completo para proteger todos los datos de VMM, como la información de hosts, máquinas virtuales y servidores de biblioteca. Además de las herramientas proporcionadas en VMM, también puede usar SQL Server Management Studio para hacer una copia de seguridad y restaurar la base de datos VMM.
1. En la vista Administración, haga clic en General y después, en el panel Acciones, haga clic en Realizar copia de seguridad de Virtual Machine Manager.
2. En el cuadro de diálogo Copia de seguridad de Virtual Machine Manager, escriba la ruta de acceso para una carpeta de destino para el archivo de copia de seguridad. La carpeta no debe encontrarse en un directorio raíz y debe ser accesible para el servidor SQL Server.
Nota
Puede supervisar el estado de la copia de seguridad en la vista Trabajos.
Use los siguientes procedimientos para realizar la recuperación de datos y volver a asociar los equipos administrados en el entorno VMM. El procedimiento que se use depende de si va a realizar la restauración en el mismo equipo físico o en otro diferente.
1. Para restaurar la base de datos VMM, en el equipo donde realiza esta restauración, ejecute la herramienta SCVMMrecover.exe desde la línea de comandos. La herramienta scvmmrecover.exe se encuentra en el CD del producto en esta ruta: %ROOT%\i386\bin para un equipo de 32 bits o en %ROOT%\amd64\bin para un equipo de 64 bits.
2. En el equipo de la base de datos VMM, abra una ventana de símbolo del sistema con privilegios elevados y después ejecute la herramienta SCVMMrecover.exe con la siguiente sintaxis, SCVMMRecover [-Path <location>] [-Confirm].
3. Si el equipo físico en el que está restaurando la base de datos VMM tiene el mismo número de identificación del sistema (SID) que el equipo donde estaba antes, debe realizar los siguientes pasos:
a. En la Consola de administrador de VMM, en la vista Hosts, haga lo siguiente:
i. Quite los hosts que se quitaron de VMM desde que se creó la última copia de seguridad. Para obtener más información, consulte Quitar un host.
NOTA
Si se ha quitado un host de VMM después de crearse la copia de seguridad más reciente, tendrá el estado Precisa atención en la vista Hosts y cualquier máquina virtual de ese host tendrá el estado El host no responde en la vista Máquinas virtuales.
ii. Vuelva a agregar los hosts que se agregaron desde la última actualización. Para obtener más información, consulte Agregar hosts.
b. En la Consola de administrador de VMM, en la vista Máquinas virtuales, quite cualquier máquina virtual que se haya quitado de VMM desde que se creó la última copia de seguridad. Para obtener más información, consulte Quitar una máquina virtual.
Nota
Si hay un host presente pero tiene una máquina virtual que se quitó desde la última copia de seguridad, la máquina virtual tendrá el estado Falta en la vista Máquinas virtuales.
1. Para restaurar la base de datos VMM, en el equipo donde realiza esta restauración, ejecute la herramienta scvmmrecover.exe desde la línea de comandos. La herramienta scvmmrecover.exe se encuentra en el CD del producto en esta ruta: %ROOT%\i386\bin para un equipo de 32 bits o en %ROOT%\amd64\bin para un equipo de 64 bits.
2. En el equipo de la base de datos VMM, abra una ventana Símbolo del sistema con privilegios elevados y después ejecute la herramienta scvmmrecover.exe con la siguiente sintaxis, SCVMMRecover [-Path <location>] [-Confirm].
3. Si el equipo físico en el que esté restaurando la base de datos VMM es diferente del equipo original y tiene un número de identificación del sistema (SID) diferente, debe realizar los siguientes pasos:
a. En la Consola de administrador de VMM, en la vista Administración, haga lo siguiente:
i. Haga clic en Equipos administrados y, en el panel de resultados, identifique los equipos administrados con el estado Acceso denegado.
ii. Haga clic en un equipo administrado con el estado Acceso denegado y después, en el panel Acciones, haga clic en Reasociar.
b. En la Consola de administrador de VMM, en la vista Hosts, haga lo siguiente:
i. Quite los hosts que se quitaron de VMM desde que se creó la última copia de seguridad. Para obtener más información, consulte Quitar un host.
Nota
Si se ha quitado un host de VMM después de crearse la copia de seguridad más reciente, tendrá el estado Precisa atención en la vista Hosts y Acceso denegado en Equipos administrados, y cualquier máquina virtual de ese host tendrá el estado El host no responde en la vista Máquinas virtuales.
ii. Vuelva a agregar los hosts que se agregaron desde la última actualización. Para obtener más información, consulte Agregar hosts.
c. En la Consola de administrador de VMM, en la vista Máquinas virtuales, quite cualquier máquina virtual que se haya quitado de VMM desde que se creó la última copia de seguridad. Para obtener más información, consulte Quitar una máquina virtual.
Nota
Si hay un host presente pero tiene una máquina virtual que se quitó desde la última copia de seguridad, la máquina virtual tendrá el estado Falta en la vista Máquinas virtuales.
Administración de cambios externos a clústeres de hosts.
Cuando agrega o quita nodos de un clúster de hosts fuera de Virtual Machine Manager, VMM detecta el cambio y, en la mayoría de los casos, indica con cambios de estado la acción que se debe realizar en VMM.
Cuando se agrega un nodo a un clúster de hosts fuera de VMM, VMM detecta el nuevo nodo y lo agrega al clúster, con el estado Administración pendiente, en la vista Hosts. Hasta que se agregue el host, si cualquier máquina virtual de alta disponibilidad en cualquier otro nodo del clúster de hosts experimenta una conmutación por error al nuevo nodo, la máquina virtual presenta el estado Falta hasta que se agrega el nodo nuevo a VMM. Use la acción Agregar a clúster de hosts para agregar el host a VMM.
Nota
Después de agregar un nodo a un clúster de hosts de Hyper-V existente y de agregar el host a VMM, debe configurar el puerto de conexión remoto predeterminado como puerto 2179, que es el puerto de conexión remoto que usa Hyper-V. La propiedad se localiza en la ficha Remoto del cuadro de diálogo Propiedades de host.
VMM también detecta cuándo se quita un nodo de un clúster de hosts fuera de VMM. En ese caso, VMM establece la propiedad Clustered del nodo en False y comienza a administrar el host como host independiente en el grupo host primario del clúster de hosts. Use la acción Quitar clúster de hosts para quitar el host de VMM. Para obtener más información, consulte Quitar un host.
Nota
Si quita un nodo de un clúster de hosts con PRO habilitado y desea continuar usando PRO en el host, debe configurar manualmente como mínimo una ruta de máquina virtual predeterminada en el host para su uso durante la selección de ubicación de la máquina virtual. Para especificar las rutas de máquina virtual predeterminadas, use la ficha Selección de ubicación en el cuadro de diálogo Propiedades de host. Para obtener más información, consulte Establecimiento de opciones de selección de ubicación para un host.
Al hacer una copia de seguridad de las máquina virtuales, debe hacer una copia de seguridad de todos los volúmenes que hospedan archivos de la máquina virtual, entre los que se incluye el archivo InitialStore.xml (de forma predeterminada, en C:\ProgramData\Microsoft\Windows\Hyper-V) y los volúmenes que contienen los archivos VHD y los archivos XML de configuración. Por ejemplo, si los archivos de configuración de la máquina virtual se almacenan en el volumen D: y los archivos de la unidad de disco duro de la máquina virtual (VHD) se almacenan en el volumen E: volumen y el archivo InitialStore.xml se almacena en C: volumen, debe hacer una copia de seguridad de C:,D: y E: .
1. Las máquinas virtuales que no tengan instalados los servicios de integración se colocarán en un estado guardado mientras se crea la instantánea VSS.
2. Las máquinas virtuales que ejecutan sistemas operativos que no son compatibles con VSS, como Microsoft Windows 2000 o Windows XP, se colocarán en un estado guardado mientras se crea la instantánea VSS.
3. En el caso de máquinas virtuales que contienen discos dinámicos, la copia de seguridad se debe realizar sin conexión.
Nota: Copias de seguridad de Windows Server no es compatible con la copia de seguridad de máquinas virtuales Hyper-V en volúmenes compartidos de clúster (volúmenes CSV).
Consideraciones al hacer Backup
| Location of cluster group | Cluster resource state | Configuration resource state | Storage resource state | Backup type | Action required to prepare for a backup |
| Node 1 | Online | Online | Online | Online | None |
| Node 1 | Online | Online | Online | Offline (due to storage configuration of the virtual machine) | Use the Cluster service to take the virtual machine cluster resource offline |
| Node 1 | Offline | Offline | Online | Offline | None |
| Node 1 | Offline | Online | Online | Offline | None |
| Node 2 | Any state | Any state | Any state | Virtual machine not reported for backup on node 1 | Move the virtual machine to node 1 |
Consideraciones a la hora de restaurar.
| Location | Cluster resource state | Configuration resource state | Storage resource state | Action required to prepare for a restore |
| Node 1 | Online | Online | Online | Take the cluster resource and configuration resource offline. |
| Node 1 | Offline | Online | Online | Take the configuration resource offline. |
| Node 1 | Offline | Offline | Offline | None |
| Node 2 | Any state | Any state | Any state | Take the cluster resource and the configuration resource offline on Node 2 to avoid a conflict. Final del formulario |
Para restaurar máquinas virtuales, siga estos pasos:
1. Inicie Copias de seguridad de Windows Server en Herramientas administrativas.
2. En el menú Actions, haga clic en Recuperar.
3. Seleccione el servidor del que desea recuperar datos y, a continuación, haga clic en Siguiente.
4. Seleccione la fecha y la hora a partir de la que desea realizar la recuperación y haga clic en Siguiente.
5. Seleccione el tipo de recuperación Aplicaciones y, a continuación, haga clic en Siguiente.
6. Seleccione Hyper-V y, a continuación, haga clic en Siguiente.
7. Seleccione la ubicación de restauración y, a continuación, haga clic en Siguiente.
8. Haga clic en Recuperar para iniciar el proceso de restauración.
Nota: se restaurarán todos los volúmenes que alojen archivos de la máquina virtual. No es posible restaurar máquinas virtuales individuales mediante Copias de seguridad de Windows Server.
Las máquinas virtuales que contienen dos o más instantáneas no se recuperarán. Para solucionar temporalmente este problema, siga estos pasos:
1. Inicie Administrador de Hyper-V en Herramientas administrativas.
2. Elimine la máquina virtual que no se ha restaurado.
3. Inicie Copias de seguridad de Windows Server en Herramientas administrativas.
4. En el menú Actions, haga clic en Recuperar.
5. Seleccione el servidor del que desea recuperar datos y, a continuación, haga clic en Siguiente.
6. Seleccione la fecha y la hora a partir de la que desea realizar la recuperación y haga clic en Siguiente.
7. Seleccione el tipo de recuperación Archivos y carpetas y, a continuación, haga clic en Siguiente.
8. Seleccione el directorio donde se almacenan las instantáneas y, a continuación, haga clic en Siguiente.
Nota: de manera predeterminada, las instantáneas se encuentran en el directorio siguiente:
C:\ProgramData\Microsoft\Windows\Hyper-V\Snapshots
9. Seleccione la ubicación donde se deben restaurar las instantáneas y, a continuación, haga clic en Siguiente.
10. Haga clic en Recuperar para iniciar el proceso de restauración.
11. Una vez finalizada la restauración, realice otra restauración. Sin embargo, utilice el tipo de recuperación Aplicaciones y seleccione Hyper-V para restaurar correctamente las máquinas virtuales.
VMM 2008 R2 admite la migración en vivo de máquinas virtuales en clústeres de hosts creados en Windows Server 2008 R2 y la migración rápida de máquinas virtuales en clústeres de hosts creados en Windows Server 2008 o Windows Server 2008 R2. Con la migración en vivo de Hyper-V, puede mover las máquinas virtuales en ejecución de un host en clúster de Hyper-V a otro sin que haya una interrupción en el servicio o se perciba un período de inactividad. Con la migración rápida de Hyper-V, hay un breve período de inactividad, sin pérdida de estado, cuando se migra una máquina virtual de un host en clúster de Hyper-V a otro. VMM 2008 admite la migración rápida de máquinas virtuales en clústeres de conmutación por error de Windows Server 2008.
Todos los archivos y discos de acceso directo para las máquinas virtuales deben residir en discos en clúster. Para obtener más información acerca de la configuración del almacenamiento para un clúster de conmutación por error de Hyper-V, consulte el tema sobre agregar almacenamiento a un clúster de conmutación por error (http://go.microsoft.com/fwlink/?LinkId=128068) (puede estar en inglés) en la Ayuda de Windows Server 2008.
En VMM 2008 R2, cuando se usa una transferencia SAN para migrar una HAVM a un clúster de hosts desde un host no en clúster, VMM comprueba todos los nodos del clúster para asegurarse de que todos los nodos pueden ver el LUN y automáticamente crea un recurso de disco de clúster para el LUN. Aunque VMM configura automáticamente el recurso de disco de clúster, no lo valida. Se debe usar el Asistente para validar una configuración de la Administración de clúster de conmutación por error para validar el recurso de disco de clúster recién creado.
Los clientes que migran a VMM 2008 R2 y desean consolidar sus máquinas virtuales existentes en un LUN de un solo volumen compartido en clúster (CSV) pueden usar la nueva característica de migración de almacenamiento rápida para migrar el almacenamiento de una máquina virtual en ejecución a otro host o a otra ubicación en el mismo host con períodos de inactividad mínimos y sin pérdida de estado. En la vista Máquinas virtuales de la Consola de administrador de VMM, use la acción Migrar almacenamiento. Para obtener más información, consulte Migración de almacenamiento de archivos de máquina virtual. En una infraestructura de VMware administrada, VMM usará VMware Storage VMotion si está disponible.
En VMM 2008 R2, las máquinas virtuales con discos de acceso directo conectados a SAN pueden migrarse a un host no en clúster o almacenarse en la biblioteca mediante la migración de SAN si el disco de acceso directo de SAN es accesible para el servidor de biblioteca o el host de destino. Sin embargo, debe convertir los discos de acceso directo a discos duros virtuales (archivos .vhd) si los discos de acceso directo son locales o no son accesibles para el servidor de biblioteca o el host de destino. En VMM 2008, debe convertir todos los discos de acceso directo antes de mover una HAVM a un servidor de biblioteca o a un host no en clúster. Para convertir un disco de acceso directo a un disco duro virtual, actualice la configuración de disco en la ficha Configuración de hardware de las propiedades de la máquina virtual.
Para obtener información adicional acerca de las opciones de almacenamiento de los clústeres de hosts de Hyper-V administrados por VMM 2008 R2, consulte Configuración de clústeres de hosts en VMM para la compatibilidad con máquinas virtuales de alta disponibilidad. Par obtener información acerca de los requisitos de configuración de SAN específicos para VMM, consulte Configuración de un entorno de SAN para VMM. Para obtener información general sobre los requisitos de almacenamiento para los clústeres de conmutación por error en Windows Server 2008, consulte el tema sobre agregar almacenamiento a un clúster de conmutación por error (http://go.microsoft.com/fwlink/?LinkId=128068).
Para ver la razón por la que una HAVM tiene el estado de configuración de clúster no admitida, muestre la ficha Configuración de hardware en el cuadro de diálogo Propiedades de máquina virtual. A continuación, en las opciones de Avanzado, haga clic en Disponibilidad. Si la máquina virtual tiene el estado de configuración de clúster no admitida, se muestra el error que generó el estado de la máquina virtual en el área Detalles.
Las siguientes situaciones pueden generar el estado de configuración de clúster no admitida:
1. La máquina virtual está en un LUN no de CSV que contiene más de una máquina virtual.
2. Si ha configurado máquinas virtuales de alta disponibilidad en Hyper-V para compartir el mismo LUN y el LUN no está en un volumen del sistema de archivos en clúster (CSV), debe actualizar las configuraciones de máquina virtual en la Administración de clúster de conmutación por error y en Hyper-V para que cada una resida en su propio LUN sin compartir.
3. La máquina virtual usa almacenamiento no en clúster.
4. Si la HAVM se almacena en una unida de sistema C: o cualquier disco que no está en clúster, la máquina virtual se coloca en el estado Configuración de clúster no admitida. Para resolver este problema, asegúrese de que todos los archivos y discos de acceso directo pertenecientes a la máquina virtual residen en discos en clúster.
5. Uno o más adaptadores de red virtuales en la máquina virtual no se conectan a una red virtual común.
6. Si las redes virtuales en todos los hosts del clúster no muestran la misma configuración, es posible que una máquina virtual de alta disponibilidad conectada a dicha red virtual pierda la conectividad cuando se migre o realice una conmutación por error a otro nodo de clúster. Las redes virtuales que tienen una configuración idéntica se denominan redes virtuales comunes. Para localizar las redes virtuales comunes para un clúster de hosts, en la Consola de administrador de VMM, consulte la ficha Redes en las propiedades del clúster de host. Para configurar las redes virtuales en los hosts, use la ficha Redes en las propiedades del host. Para obtener más información acerca de la configuración de redes virtuales, consulte Agregar o modificar redes virtuales en un host.
Para que VMM considere una red virtual común y disponible para máquinas virtuales de alta disponibilidad en un clúster de hosts, cada red virtual en el clúster de hosts debe cumplir los siguientes requisitos:
El nombre de la red virtual debe ser idéntico en cada host en el clúster. En VMM 2008, las redes virtuales se reconocen como redes virtuales comunes únicamente si coinciden las mayúsculas y minúsculas de todas las letras de los nombres de red. Esta restricción se eliminó en VMM 2008 R2. Cuando identifica redes virtuales comunes, VMM 2008 R2 no evalúa las mayúsculas y minúsculas de las letras de los nombres de red.
Los adaptadores de red host a los que está conectada la red virtual en cada host del clúster deben tener la misma ubicación.
Asimismo, el nombre de la red virtual debe tener la misma etiqueta en cada host del clúster.
Después de actualizar las configuraciones de red virtual en todos los nodos, actualice el clúster para que cada red virtual se detecte como común. A continuación, en las propiedades del clúster de hosts, consulte la ficha Redes para verificar que las redes se han agregado al mismo.
En VMM 2008, se adjunta una imagen ISO a las máquinas virtuales de alta disponibilidad. Este problema se resolvió en VMM 2008 R2.
Con frecuencia, la imagen ISO es c:\windows\system32\vmguest.iso. Para resolver este problema, quite la imagen ISO con el Administrador de Hyper-V. Posteriormente, actualice la máquina virtual en VMM con la acción Reparar. Haga clic con el botón secundario en la máquina virtual, luego en Reparar y después haga clic en Ignorar.
