¿Busca una solución que ayuda a reducir los costos de TI, al tiempo que aumenta la agilidad de su organización?
System Center Virtual Machine Manager Self-Service Portal 2.0 (SSP) te permite construir las bases para una infraestructura de Cloud en la empresa, lo que le permite ofrecer IT como un servicio para su organización.
Utilizando SSP, puede responder con mayor eficacia, y con un menor coste, a las necesidades cambiantes de su organización. SSP está libremente disponible y es totalmente compatible con Microsoft.
Características principales: • Automatización y Orientación: Para evaluar, planear y diseñar la infraestructura de la nube Privada. • Cliente / unidad de negocio on-boarding: flujos de trabajo automatizados para lanzar las unidades de negocio en los departamentos de IT a su grupo de recursos virtualizados compartido • Motor para Dynamic Provisioning : Para la provisión de infraestructura virtualizada con rapidez relacionada con el centro del sistema y Hyper-V • Portal de Autoservicio: Potenciar asi a los usuarios de IT para solicitar la prestación y la infraestructura para las aplicaciones / servicios • Extensibilidad de Socio: Habilitar socios para exponer sus capacidades únicas de hardware a través de tecnoologias conocidas de Scripting de Microsoft proporcionando variedad y flexibilidad al grupo de IT Próximos pasos: • Descargar Download System Center Virtual Machine Manager Self-Servicing Portal 2.0 para su testeo.
Ventajas clave El portal de auto-servicio tiene un soporte completo, tratandose de una solucion extensible construida sobre Windows Server 2008 R2, la tecnología Hyper-V y System Center VMM.
Le permite agrupar, asignar y gestionar los recursos para ofrecer la infraestructura como un servicio y establecer las bases para una plataforma en la nube privada dentro de su centro de datos. Se incluye un sistema preconfigurado y un portal de autoservicio basado en roles, para ambos, tanto para el centro de datos como para los administradores de la unidad de negocio de IT del consumidor y de un motor de aprovisionamiento dinámico.
El portal reduce el tiempo necesario para la provisión de infraestructuras y sus componentes por lo que ofrece la creación de unidades de "on-boarding”, la solicitud de infraestructura y la gestión del cambio. También incluye una guía detallada sobre cómo implementar el portal dentro de su entorno.
Esperamos que este nuevo paquete de gestión os resulte de utilidad.
Grupo de Soporte Microsoft.
Hola!
En esta ocasión, vamos a hablar un poco sobre el concepto de Split Tunelling utilizado en una conexión VPN y como configurarlo en Windows.
Siempre que realizamos una conexión VPN, y de manera predeterminada, se añade una nueva ruta por defecto (Gateway) en nuestra tabla de rutas para apuntar al servidor VPN al que nos conectamos.
De esta manera, todo el tráfico tanto interno (Intranet) como externo (Internet) pasará a través del servidor VPN.
Además de ineficiente para el tráfico externo, también podemos encontrarnos con el problema de que el servidor VPN no permita enrutar tráfico externo.
Este comportamiento es debido a que, por defecto, la opción Use default Gateway on remote network está marcada.
Si por el contrario desmarcamos dicha opción y realizamos la conexión VPN, la ruta por defecto no se verá modificada.
En lugar de esto, una nueva entrada (con el ID de red correspondiente a la dirección IP obtenida en la conexión VPN) es agregada a la tabla de rutas.
Gracias a ello, el tráfico externo será enviado por la Gateway original del cliente VPN, mientras que únicamente el tráfico interno correspondiente a la subred del cliente VPN será enviado al servidor VPN.
¿Qué pasa si, además de la subred donde se encuentra el cliente VPN, tenemos máquinas en otras subredes (internas) a las cuales necesitamos acceder?
Pues que debemos agregar las distintas entradas necesarias en nuestra tabla de rutas una vez nos hayamos conectado por VPN.
(Además, dichas entradas deberían desaparecer cuando nos desconectamos de la misma...)
¿Cómo podemos hacer esto?
Método 1: Crear una conexión a través de CMAK
Podemos optar por crear una conexión a través de CMAK (Connection Manager Administration Kit) y añadir un fichero de rutas personalizado a la conexión.
Podéis encontrar más información sobre cómo realizar esto en los siguientes enlaces:
291950 - Connection Manager Route Management Split Tunneling for Concurrent Access to the Internet and an Intranet
291950 - Connection Manager Route Management
Split Tunneling for Concurrent Access to the Internet and an Intranet
NOTA: Para que las rutas personalizadas se apliquen correctamente, es necesario que los usuarios de las máquinas cliente sean administradores locales de las mismas.
(Permiso necesario para poder alterar la tabla de rutas).
Método 2: Configurar rutas a través de las opciones de Scope en DHCP
Otra opción disponible sería utilizar opciones de Scope de un servidor DHCP para definir las rutas personalizadas.
Por supuesto que esta opción requiere que el servidor VPN asigne las direcciones a través de un servidor DHCP (y nunca de un pool estático de direcciones).
Más información en el siguiente enlace:
Classless Static Route Option for DHCP
The Classless Static Route Option for DHCP allows the client to query a DHCP server to obtain routing information to enable a remote access client to send traffic to the target network without treating the target network as the default route. For example, this allows a remote client to simultaneously view sites on the Internet as well as sites on the target network
Esperamos que esta información os haya sido de utilidad.
Un saludo,
Javier Rama.
Un rollup para Hyper-V (KB2264080) se ha publicado en Windows Update como una actualización opcional.
Este rollup incluye los fixes documentados en los siguientes KBs:
975530 Stop error message on a Windows Server 2008 R2-based computer that has the Hyper-V role installed and that uses one or more Intel CPUs that are code-named Nehalem: "0x00000101 - CLOCK_WATCHDOG_TIMEOUT"
http://support.microsoft.com/default.aspx?scid=kb;EN-US;975530
974909 The network connection of a running Hyper-V virtual machine is lost under heavy outgoing network traffic on a Windows Server 2008 R2-based computer
http://support.microsoft.com/default.aspx?scid=kb;EN-US;974909
981791 "STOP: 0x0000001a" error message on a computer that has an Intel Westmere processor together with the Hyper-V role installed on Windows Server 2008 SP2 or on Windows Server 2008 R2
http://support.microsoft.com/default.aspx?scid=kb;EN-US;981791
Aquí tenéis una captura del update en WU:
Un saludo.
Raúl del Moral
Técnico de Soporte Plataformas
Buenos días a tod@s,
Curioseando en el blog de debugging he localizado este video donde se explica la relación entre VSS y DPM 2007.
Tras haberlo revisado creo que es muy útil para entender este componente, aunque esta en ingles recomiendo que lo reviséis.
Understanding VSS in DPM
Soporte Plataformas.
Estamos muy emocionados de anunciar la disponibilidad de los servicios de Hyper-V de Integración Linux para Linux versión 2.1. Este lanzamiento marca otro hito en el suministro de una plataforma de virtualización integral a nuestros clientes. Los clientes que tienen la necesidad de un entorno heterogéneo de sistema operativo de su plataforma de virtualización para proporcionar apoyo a todos los sistemas operativos que se puedan presentar en sus centros de datos. Hemos apoyado Linux como sistema operativo invitado en nuestra plataforma de virtualización desde los días de Virtual Server y continuamos mejorando nuestro apoyo en ese sentido.
Las siguientes funciones están incluidas en la versión 2.1 :
Compatibilidad de controladores para los dispositivos sintéticos: Linux Integration Services admite el controlador de red synthetic y el controlador de almacenamiento synthetic que se desarrollaron específicamente para Hyper-V.
Los dispositivos de arranque aprovechan el bloque de virtualización de servicios de clientes (VSC) para proporcionar un mejor rendimiento.
Timesync: El reloj dentro de la máquina virtual se mantiene sincronizado con el reloj en el host.
Integrated Shutdown: Las máquinas virtuales con Linux se puede apagar con de forma controlada desde cualquiera de las plataformas, Hyper-V Manager o System Center Virtual Machine Manager.
Symmetric Multi-Processing (SMP) Support: Soporte a distribuciones de Linux que pueden usar hasta 4 procesadores virtuales (VP) por cada máquina virtual.
Heartbeat: Permite al host para detectar si el cliente está en ejecución y con respuesta.
Pluggable Time Source: Un módulo conectable de fuente de reloj se incluye para proporcionar una fuente de tiempo más precisa a los clientes.
Esta versión de los servicios de integración de Hyper-V soporta Novell SUSE Linux Enterprise Server 10 SP3, SUSE Linux Enterprise Server 11, and Red Hat Enterprise Linux 5.2 / 5.3 / 5.4 / 5.5.
¿Dónde puedo conseguirlo?
Los clientes externos la posibilidad de obtener los IC’s de Linux a través del Centro de descarga de Microsoft en este enlace: http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=eee39325-898b-4522-9b4c-f4b5b9b64551
¿Dónde puedo ofrecer comentarios?
Por favor enviar todos los comentarios a linuxic (linuxic@microsoft.com). Para preguntas de soporte técnico, por favor utilizar el Foro de Integración Linux Servicios aquí:http://social.technet.microsoft.com/Forums/en-US/linuxintegrationservices/threads
FAQ
Q: ¿Los Servicios de Integración Linux habilitar el soporte de ratón?
A: Soporte para el ratón no está incluido en los servicios de integración de Linux. Sin embargo, consulte la readme para obtener información sobre dónde obtener el controlador InputVSC que proporciona soporte para el ratón cuando se utiliza en una conexión RDP.
Q: ¿Red Hat Enterprise Linux 6.0 es soportada?
A: En este momento Red Hat 6.0 (actualmente) en versión beta no es compatible. Nuestro objetivo es trabajar con Red Hat para respaldar los servicios de acceso a Hyper-V Linux integración desde el árbol de kernel.org . Sin embargo, esto sólo ocurrirá una vez que nuestros pilotos están fuera del área de ensayo en el kernel. No tenemos una línea de tiempo para esto, pero compartiremos más información sobre este a medida que continuamos trabajando con la comunidad Linux.
Q: ¿Desarrollo Citrix estos drivers?
A: No. Los Linux IC’s fueron desarrollados por un equipo dentro de Microsoft Open Source Technology Center.
Q: ¿Es necesario ejecutar el kernel Xen con las hypercall?
A: No, el Xen kernel ya no se utiliza.
Q: ¿Cómo se relaciona esto con el anuncio de Microsoft que aportan el código de Linux IC bajo GPLv2 al kernel de Linux?
A: Este paquete proporciona los componentes de integración para las distribuciones que apoyamos (SLES y Red Hat). Una vez que el IC se haya hecho compatible en el kernel estarán disponibles en las distribuciones, poco a poco iremos facilitando progresivamente el paquete por separado de IC.
Q: ¿Esta el SUSE Linux Enterprise Server 11 Service Pack 1 soportado?
A: Ahora que tenemos el RTM versión 2.1, Novell realizara un backport en el Service Pack 1 SLES 11 que será lanzado por Novell en los próximos meses . A partir de entonces, los clientes recibirán el Linux Hyper-V como una parte de la distribución de SLES 11 SP1. No será necesaria la descarga independiente o la instalación.
Q: ¿Se aportaran estas capacidades en la línea principal del núcleo de Linux?
A: Sí, vamos a realizar parches con estas capacidades para el núcleo principal de Linux también.
Soporte a Plataformas
Recientemente un cliente nos comentó lo siguiente:
“Como parte de nuestro proyecto de migración a Windows 7 desde Windows XP hemos estado evaluando el funcionamiento de EFS.
· Hemos descubierto que en Windows 7, si compartes una carpeta y un usuario cifra un archivo en local (equipo destino), el mismo usuario puede acceder al archivo y descifrarlo remotamente (desde otro equipo) sin que la maquina donde reside el archivo este configurado para que se confíe en ella para la delegación (de credenciales kerberos)
· Si el usuario cierra sesión en el equipo destino, deja de poder descifrar el archivo desde un equipo remoto, recibiéndose el mensaje “Acceso denegado”. Si vuelve a iniciar sesión en el equipo destino y abre cualquier archivo cifrado con su (el mismo) certificado EFS, vuelve a poder descifrar y abrir el archivo original desde el equipo remoto
· Tenemos dudas de si se trata de un comportamiento erróneo o de un fallo de seguridad en Windows 7, puesto que en estas pruebas (realizadas con notepad y archivos de texto cifrados) no se observa el mismo comportamiento si el equipo destino donde reside el archivo cifrado es Windows XP
· Puesto que los equipos destino no están marcados para que se confíe en ellos para la delegación, entendemos que lo observado en Windows 7 es contrario a lo descrito en el siguiente artículo:
Using Encrypting File System (Remote Decryption on File Shares) “
Tras investigar el comportamiento, determinamos lo siguiente:
En realidad, la posibilidad de descifrar archivos EFS en remoto sin que el equipo destino este configurado para la delegación también existe en Windows XP: siempre que existe un “handle” abierto localmente al archivo EFS y el mismo usuario tiene una sesión iniciada en el equipo destino.
(Las pruebas realizadas en este escenario se hicieron con Notepad, pero Notepad cierra el handle al archivo EFS en cuanto termina de descifrarlo, por tanto los resultados observados no son predecibles, y en la mayoría de los casos dará el resultado de que no se puede descifrar el archivo de texto en remoto. Si tenemos la suerte de acceder al archivo en remoto e intentar abrirlo mientras la clave aún está cargada por el “handle” que notepad tiene al archivo, logramos descifrarlo con éxito. Como ejemplo, en Windows XP un archivo zip mantiene abierto el “handle” durante más tiempo)
En resumen:
Información adicional:
Tolu Igbon
Ingeniero de Soporte de Microsoft
¡Hola!
Hoy me apetece hablar de algo que seguro nos habéis oído a muchos de nosotros cuando habéis sufrido algún problema de discos en un cluster y es eso de las “Reservas Persistentes de SCSI-3”.
Lo primero de todo es saber qué es eso de SCSI-3… Como siempre en estos casos y, aunque hay que utilizarla con cuidado, la Wikipedia nos viene muy bien:
http://es.wikipedia.org/wiki/SCSI SCSI, acrónimo inglés de Small Computers System Interface (Sistema de Interfaz para Pequeñas Computadoras), es una interfaz estándar para la transferencia de datos entre distintos dispositivos del bus de la computadora. Algunos profesionales lo castellanizan como escasi, por la pronunciación en inglés de su sigla, otros por el contrario prefieren deletrearlo. Para montar un dispositivo SCSI en un ordenador es necesario que tanto el dispositivo como la placa madre dispongan de un controlador SCSI. Es habitual que el dispositivo venga con un controlador de este tipo, pero no siempre es así, sobre todo en los primeros dispositivos. Se utiliza habitualmente en los discos duros y los dispositivos de almacenamiento sobre cintas, pero también interconecta una amplia gama de dispositivos, incluyendo escáneres, unidades CD-ROM, grabadoras de CD, y unidades DVD. De hecho, el estándar SCSI entero promueve la independencia de dispositivos, lo que significa que teóricamente cualquier cosa puede ser hecha SCSI (incluso existen impresoras que utilizan SCSI).
http://es.wikipedia.org/wiki/SCSI
SCSI, acrónimo inglés de Small Computers System Interface (Sistema de Interfaz para Pequeñas Computadoras), es una interfaz estándar para la transferencia de datos entre distintos dispositivos del bus de la computadora. Algunos profesionales lo castellanizan como escasi, por la pronunciación en inglés de su sigla, otros por el contrario prefieren deletrearlo.
Para montar un dispositivo SCSI en un ordenador es necesario que tanto el dispositivo como la placa madre dispongan de un controlador SCSI. Es habitual que el dispositivo venga con un controlador de este tipo, pero no siempre es así, sobre todo en los primeros dispositivos. Se utiliza habitualmente en los discos duros y los dispositivos de almacenamiento sobre cintas, pero también interconecta una amplia gama de dispositivos, incluyendo escáneres, unidades CD-ROM, grabadoras de CD, y unidades DVD. De hecho, el estándar SCSI entero promueve la independencia de dispositivos, lo que significa que teóricamente cualquier cosa puede ser hecha SCSI (incluso existen impresoras que utilizan SCSI).
¿Y qué significa el 3?
Como hemos visto, SCSI es un estándar. Dicho estándar está mantenido por un comité técnico responsable de la definición de la arquitectura SCSI (cómo deben conectarse los dispositivos SCSI, qué señales deben enviar, qué funciones implementar, etc) llamado T10.
http://www.t10.org/index.html
Dicho comité decidió que se debía ampliar la funcionalidad de la arquitectura SCSI que existía entonces, y se pasó a ampliar SCSI a la tercera generación, es decir, SCSI-3.
Windows Server 2008 está diseñado para utilizar únicamente comandos y especificaciones SCSI-3 y exactamente eso son las reservas persistentes.
Las reservas se utilizan para que un dispositivo SCSI sea capaz de procesar comandos de un set específico de lo que se llama I_T Nexus (combinación de puertos iniciadores accediendo puertos destino, Initiators-Targets) y rechazar cualquier comando proveniente de otro I_T Nexus diferente.
Asimismo, el mecanismo de las reservas persistentes permite que se preserven dichas reservas incluso ante fallos de los dispositivos Iniciadores SCSI como un hard reset, reset lógico o pérdida del par Initiator-Target. Aun así, una reserva persistente de un I_T Nexus que esté fallando puede ser confiscada por otro I_T Nexus como parte del proceso de recuperación ante fallos.
Por tanto las reservas persistentes se mantendrán hasta que se liberen, se confisquen o se limpien por mecanismos de limpieza.
Por último, para realizar una reserva persistente y liberarla se utilizan los comandos PERSISTENT RESERVE OUT y PERSISTENT RESERVE IN.
Bien, os preguntaréis cómo se traduce toda esta teoría en algo útil, algo que conozcamos, ¿no?
Empecemos por suponer un cluster Windows Server 2008 de dos nodos con una cabina de discos.
En ese caso, las HBAs de nuestros nodos son los Iniciadores SCSI y los volúmenes de la cabina son los Targets.
Si la HBA1 del nodo 1 tiene el control de los discos 1 y 2 de la cabina, el puerto de la HBA1 será nuestro puerto Iniciador y los puertos de los discos 1 y 2 serán nuestros puertos Target, teniendo así nuestro set I_T Nexus. Por tanto, los discos 1 y 2 solo podrán interpretar comandos lanzados desde el nodo 1. En caso de fallo del nodo 1, el nodo 2 podrá hacerse con el control de los discos confiscando las reservas.
Empecemos por el principio… Durante el arranque del cluster el nodo que va a hacerse con el control de uno de los discos intenta reservar el disco de la siguiente forma:
1. El driver de cluster lanza a través de la pila la instrucción para reservar el volumen (IOCTL_STORAGE_PERSISTENT_RESERVE_IN)
2. El driver de disco intercepta el comando y lo transforma en un paquete de Entrada/Salida (IRP) que pasa al driver de Multipathing
3. El driver MPIO pasa la petición al DSM (Device Specific Module). El DSM es el segundo componente de una solución Multipathing dependiente del fabricante de la cabina. Dicho componente debe asegurarse que la petición de reserva se envía a través de todos los caminos.
4. El registro de la reserva se realiza en una tabla de reservas en el inicio del volumen
El mismo procedimiento se sigue para liberar una reserva de un volumen.
Como vemos en los pasos descritos en la imagen anterior, existe una tabla de reservas persistentes con la información de los dispositivos que pueden acceder al volumen. Dicha tabla se almacena al principio del volumen:
Tal y como aparece, el nodo 1 es el que tiene el disco reservado ya que es su clave (key 1) la que está anotada en la tabla. Por tanto será el nodo 1 el que pueda acceder y gestionar el disco. Vemos también que el nodo 2 está intentando registrar una reserva pero será rechazada al existir ya una reserva sobre el disco. Si este intento no es rechazado, el nodo 2 se hará con el control del disco, confiscando así la reserva.
En numerosas ocasiones nos encontramos con situaciones en las que, tras un reinicio inesperado o algún otro error, uno de los nodos de un cluster no puede unirse al cluster o no se pueden ver los discos desde la consola de cluster. Asimismo, podemos encontrarnos con eventos refiriéndose a un cambio de firmas en los discos o que no se pueden añadir volúmenes nuevos a la pestaña available storage de la consola Failover Cluster Management. Por ejemplo, podemos encontrar los siguientes eventos:
Log Name: System
Source: Microsoft-Windows-FailoverClustering
Date: 30/06/2009 13:54:51
Event ID: 1205
Task Category: (3)
Level: Error
Keywords:
User: SYSTEM
Computer: MyNode
Description:
The Cluster Service failed to bring the Resource Group " Available Storage" completely online or offline.
Event ID: 1069
Cluster resource 'Cluster Disk 1' in clustered service or application ' Available Storage' failed.
Igualmente, en el log de cluster podemos encontrar (entre otras) entradas como las siguientes:
0000151c.00001094::2009/06/30-08:54:40.995 ERR [RES] Physical Disk <Cluster Disk 1>: Open: Unable to get disk identifier. Error: 5023.
0000151c.00001584::2009/06/30-11:54:51.648 ERR [RES] Physical Disk <Cluster Disk 1>: Failed to register key, status 1
0000151c.00001584::2009/06/30-11:54:51.648 ERR [RES] Physical Disk <Cluster Disk 1>: OnlineThread: Unable to arbitrate for the disk. Error: 1.
0000151c.00001584::2009/06/30-11:54:51.648 ERR [RES] Physical Disk <Cluster Disk 1>: OnlineThread: Error 1 bringing resource online.
Esto indica que el comando para liberar la reserva persistente registrada en la tabla de reservas no se ha procesado correctamente y dicha reserva no se ha liberado. En muchas ocasiones ocurre que el otro nodo no ha sido capaz de confiscar dicha reserva y, por tanto, el volumen queda reservado por nadie (no existe el par Iniciador).
Normalmente, esto ocurre cuando el DSM no es capaz de procesar correctamente la petición de liberación de reserva y esta no llega al volumen.
Como hemos visto, las reservas persistentes son algo que se almacenan en los propios volúmenes de las cabinas de discos. Es por ello que cuando nos encontramos en un escenario de reservas persistentes no liberadas correctamente, es recomendable contactar con el fabricante de la cabina ya que suelen disponer de herramientas específicas para liberar las reservas sin correr el riesgo de borrar ningún otro dato del volumen.
Aun así, en caso de necesitar recuperar urgentemente un cluster, Windows Server 2008 incluye un nuevo comando para liberar las reservas persistentes:
CLUSTER NODE /CLEARPR:disknumber
Este comando se debe lanzar desde uno de los nodos que vea el volumen en el administrador de discos del sistema operativo, que será de donde obtengamos el disknumber.
Hay que tener en mente que este comando solo lo debemos usar en casos realmente urgentes ya que, como decíamos, podemos borrar más información de los volúmenes aparte de las reservas persistentes.
Espero que os haya gustado. ¡Nos vemos en el siguiente post!
Rafael Basterra Careaga Platforms Support Engineer