En post anteriores hemos realizado una incursión sobre el nuevo diseño de Exchange 2013 y como hay una justificación para la simplicidad y el ahorro.

Exchange 2013: Disponibilidad y fiabilidad (Conceptos)

Exchange 2013: Disponibilidad y fiabilidad (conclusiones)

Exchange 2013. Principios de Diseño (1)

En este momento vemos que la creación de varios sitios da la posibilidad de que nuestro entorno sea, además de altamente disponible, máximamente resilente. Os podeis hacer una idea en una contribución excelente de Boris Lokhvitsky. Con todo ello, podemos entender la propuesta de Microsoft.

Recordamos algunos principios:

• Disponibilidad
• Resilencia
• Ahorro de costes

Simplicidad/Sencillez

Yo hubiera elegido sencillez. Lo que es simple, es complejo, lo es en extremo. Lo que si está claro es que  la posibilidad de un fallo es algo real y, en cierto sentido, inevitable. La forma que hemos visto para mitigar el fallo es establecer redundancia en aquellos dominios independientes para evitar su contagio a los dependientes. Esta redundancia, aún así, es cara si no se toman medidas precisas. En el caso del almacenamiento es así.

El cambio ha sido dejar a un lado el diseño basado en SAN, para pasarlo a un sistema de almacenamiento redundado SAS/SATA en una configuración JBOD. Esto se basa en la replicación del almacenamiento a un coste barato, con una redundancia que cumple con la fiabilidad del sistema.

Esto se ha hecho a través de software, dentro de Exchange, como replica por diseño. Ahora ya no es relevante el tener todos los dominios de fallo redundandos de forma cara y compleja, sino tener un almacenamiento barato, en ordenadores baratos, replicando y creando dominios de fallo independientes.

Costes/Complejidad

Esta sencillez ataca no sólo a los costes, sino también reducimos la complejidad. La complejidad aumenta las posibilidades de fallo. El dejar de atacar la disponibilidad dominio a dominio de fallo, dependientes, por un sistema de redundancia del dominio de fallo más importante, almacenamiento. Siendo un sistema de replica por software, podemos tener un sistema de replicación que predice el fallo. Es un sistema que, dado el caso de fallo, activa el almacenamiento, al activar una copia de la base de datos afectada.

Esta elección tiene unas implicaciones precisas y vamos a desarrollar las posibilidades que tenemos para que el marco de esta recomendación se entienda con toda su amplitud.

Siguiendo los dos post anteriores:

Exchange 2013: Disponibilidad y fiabilidad (Conceptos)

Exchange 2013: Disponibilidad y fiabilidad (conclusiones)

podemos lanzar unas recomendaciones sobre los principios que pueden guiar el diseño de Exchange 2013.

[…]

Siguiendo el post anterior sobre Exchange 2013: Disponibilidad y fiabilidad (Conceptos) esta segunda parte trata de reconocer el la forma de entender los dominios de fallo para entender que se puede redundar.

Dominios de fallo

En lo que hemos visto hasta ahora es relevante reconocer que estamos hablando de que uno u otro componente, este o aquel, es el que puede fallar. Eso se corresponde con un dominio de fallo. El fallo o error en un dominio rompe la independencia o la redundancia de los componentes que combina. Por ejemplo, el fallo de hardware de servidor en un servidor con varios roles significa que todas las funciones de Exchange en este servidor dejan de estar disponibles; en consecuencia, el fracaso de un contenedor de discos o una matriz SAN significa que todas las copias de bases de datos alojados en esta matriz no estarán disponibles.

Supongamos dos escenarios:

1. Todo esta en un servidor, varios roles. CAS+MBx

2. Los roles se reparten entre dos servidores. CAS y MBx separados

En el primer caso, o esta disponible el servidor o no lo está. Siguiendo el anterior post,

En el segundo caso, tienen que estar los dos servidores disponibles para poder dar servicio y por la ley de la probabilidad, A × A = A2.

A<1, A2 < A

Porque el problema es que los sistemas dependientes lo son por que ser independientes ellos mismos. Si fallan, los dependientes fallan aunque este funcionando, por eso tomamos cada elemento como parte independiente y dependiente a la vez. Poniendo varios roles en el mismo servidor evitamos sistemas intermedios que hacen menos disponibles todo el sistema.

Segunda cuestión: almacenamiento

Ahora consideremos otro escenario de dominio de fallo (dos copias de bases de datos que comparten la misma matriz de almacenamiento), y comparamos la disponibilidad de bases de datos en los dos casos siguientes:
1. Dos copias de bases de datos alojados en el mismo almacenamiento compartido (matriz SAN o espacio DAS), que tiene la probabilidad de fallo de P;
2.Las mismas copias de bases de datos hospedadas en dos sistemas de almacenamiento separados, cada uno tiene la misma probabilidad de fallo;

En el primer caso, almacenamiento compartido representa un dominio de fallo.

Al igual que en el escenario anterior, esto significa que ambas copias de bases de datos están disponibles o no disponibles de forma simultánea, por lo que la disponibilidad general es de nuevo A = 1 – p

En el segundo caso, el servicio en general estará disponible si al menos un sistema está disponible, y no estará disponible sólo si ambos sistemas fallan. Los sistemas de almacenamiento en cuestión son independientes; Por lo tanto, la probabilidad de fallo para el servicio en general es P × P = P2, y la disponibilidad global del servicio correspondiente es A = 1 – P2.

Una vez más, como P <1, significa que P2 <P, y por lo tanto 1 – P2> 1 – P. Esto significa que la disponibilidad en el segundo caso es más alta. Poner las de bases de datos en el mismo sistema de almacenamiento disminuye la disponibilidad general del servicio.

Por tanto, se trata de establecer la relación entre roles compartidos en el servidor, por sus dependencias si fueran distribuidos, por ser dominios de fallo independientes, y la relación entre redundancia de componentes que pertenecen al mismo dominio de fallo.

Con ello, de forma más o menos grafica, queremos explicar que la Disponibilidad va a depender de establecer con claridad los únicos puntos de fallo, dominios, y reconocer su redundancia.

El siguiente post tratará ese diseño posible.

Siempre que un español habla de algo, pierde valor y no tiene sentido, es una chapuza de salida. Si, por el contrario, repite lo que dice un extranjero, la cosa cambia. Voy a citar y resumir un artículo de otro.  En mis clases, he explicado mil veces estos conceptos antes de encontrar este artículo interesantísimo.

Apliquemos pues Itil a Exchange 2013.

[…]

Se ha consolidado la creación de varios roles dentro del diseño de Exchange en forma de 2 roles fundamentales

• Client Access Server
• Mailbox Server

Client Access Server

Es el rol que permite conectarse a los clientes de correo con el Mailbox autenticando, redirigiendo o pasando las peticiones a los Maibox apropiados. Tiene dos componentes esenciales. El Servicio de Client Acccess, que realiza las conexiones de los clientes, y el servicio Frond End Transport, para filtrar algún tipo de tráfico como el que sale fuera de nuestra organización.

En resumen, gestiona:

1. Autenticación
2. Redirección (limitada)
3. Proxy Services para HTTP, POP, IMAP y SMTP
4. Thin Server y Stateless Server
5. No renderiza dato alguno
6. No encola ni realiza tareas de almacenamiento alguno, excepto los logs.

Mailbox Server

Mailbox almacena las bases de datos que contienen los buzones y los datos de las carpetas públicas. Como en 10, tenemos a nuestra disposición la gestión de Alta Disponibilidad por medio del DAG (Database Availability Group). Realiza, además, servicios de Transporte:

• Hub Transport service: El Hub Transport 07/10 enrrutando el correo de la organización y realizando la conexión con el servicio entre el Front End transport service y el Mailbox Transport service
• Mailbox Transport service-. Es quien pasa los mensajes de correo entre HT y MBX database.

En resumen, gestiona:

• Client Access Protocols
• Transport Service
• Mailbox Databases
• Unified Messaging (Excepto el SIP Redirection)
• Todas las actividades del MBX

Así que el CAS y MBX se reparten los roles del HT, Mensajería Unificada y no hay servidor Edge. Funcionaria con uno del 07 o 10 pero parece que va a desaparecer, por lo poco que se ha instalado realmente.

Antes

Servidores en 10

Las funciones de servidor de Exchange Server 2010 son:

◾ Servidor Buzón de correo (MBX) – aloja las bases de datos de buzones y carpetas públicas

◾ Servidor de Acceso de clientes (CAS) – proporciona conectividad a los clientes (por ejemplo, Outlook, Outlook Web App, ActiveSync) a los buzones

◾ Servidor Concentrador de Transporte (HubT) – responsable de todo el flujo de correo en la organización

◾ Servidor de Transporte perimetral (Edge) – un servidor de transporte especial destinados a ser instalados en las redes DMZ para proporcionar un flujo seguro de entrada / salida de correo electrónico para la organización

◾ Unified Messaging Server – ofrece correo de voz y otra de integración de telefonía con Exchange.

Es un contenedor que se ve en Active Directory Users and Computers, View, Advanced Features. En ese contenedor aparecen los objetos huérfanos. Estos son los que no tienen una relación explicita con un objeto superior, padre. Estos aparecen tras replicaciones que no han tenido éxito.

Esto puede ocurrir cuando se realizan cambios por varios administradores. Si las modificaciones se dan en dos atributos diferentes y sin relación, se asumen los dos.

Si los cambios se producen en dos objetos dependientes, pueden aparecer en Lost and Found como objetos huérfanos. Por ejemplo, si un administrador crea un usuario en una OU y otro administrador borra esa OU dentro de un intervalo de sincronización, el usuario aparece como objeto huérfano al ser creado  perder su contenedor.

Las herramientas que tenemos, de salida, son para Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, o Windows Server 2012, en el origen, para llevarlos roles y características del Windows 2012 R2. Nos posicionamos en el modo de servidor a servidor y no in-place, que analizaremos a parte.

Los roles que necesitan la migración detallada y con herramientas dedicadas son:

• Migrate Active Directory Federation Services Role Services to Windows Server 2012

• Migrate Health Registration Authority to Windows Server 2012

• Migrate Hyper-V to Windows Server 2012

• Migrate IP Configuration to Windows Server 2012

• Migrating Network Policy Server to Windows Server 2012

• Migrate Print and Document Services to Windows Server 2012

• Migrate Remote Access to Windows Server 2012

• Migrate Windows Server Update Services to Windows Server 2012

Para el conjunto de herramientas anteriores a Windows 2012 R2 y para este mismo OS están resueltas en una sola localización.

La instalación y configuración de las Herramientas de Migración

Los administradores pueden usar Herramientas de migración de Windows Server para migrar los roles de servidor, características, configuración del sistema operativo y otros datos y acciones a los equipos que ejecutan Windows Server 2012 R2 o Windows Server ® 2012.

Preparación

1. Instalación  en los servidores de destino que ejecutan Windows Server 2012 R2 o Windows Server 2012.
2. Creación de carpetas de implementación en los servidores destino de la migración, para copiar en los servidores origen.
3. Copia de las carpetas de implementación de los servidores destino en los servidores  origen.
4. Registrar las Herramientas de migración en los servidores de origen.

En el origen:

Preparar. Sea cual sea el OS, 23 MG de espacio libre para las herramientas. Para Windows 2008, instalar PowerShell. Para Windows 2003 instalar PowerShell 1.o y Microsoft .NET Framework  2.0.

La instalación

Cambia si se trata de W12R2 a W12R2 con respecto a W12, W2008, 2008 R2, y 2003. En el primer caso, siendo la misma versión, nada hay que preparar. Para la segunda opción tenemos que realizar dos pasos previos:

1. Crear en las maquinas de origen la carpeta de despliegue con smigdeploy.exe en el servidor de destino (está incluida en las Windows Server Migration Tools).
2. Registrar Windows Server Migration Tools en la máquina de origen en las maquinas con Windows Server 2012, Windows Server 2008 R2, Windows Server 2008 o Windows Server 2003 usando la herramienta SmigDeploy.exe.

Creación de las carpetas del despliegue

Instalamos las herramientas para cada versión. Tras ello, lanzamos una cmd y nos posicionamos en

cd %Windir%\System32\ServerMigrationTools\

y lanzamos smigdeploy.exe con las siguientes opciones y teniendo en cuenta la arquitectura amd64 o X86 y la carpeta de cada OS. Por ejemplo:

W12

SmigDeploy.exe /package /architecture amd64 /os WS12 /path <deployment folder path>

W2008R2

SmigDeploy.exe /package /architecture amd64 /os WS08R2 /path <deployment folder path>

Copiar en el origen

1. La carpeta que hemos creado en el anterior paso, lo copiamos en los servidores de origen siguiendo la arquitectura presente en ellos.
2. Abrimos un cmd en el servidor de origen, nos ponemos en la carpeta que hemos copiado y lanzamos

.\Smigdeploy.exe

para registrar el servidor

Seguiremos con otros post sobre estas Herramientas.

Esto que contaremos ahora, si venimos desde antes de Windows 2012, tenemos que considerar lo que desaparece con ese sistema operativo y que se acumula a lo siguiente -,)

Voy a comentaros lo que cambia en W12R2, en lo que considero más relevante, que hay que observar con cuidado.

1. En Directorio Activo, tenemos que migrar la replicación que manteníamos en FRS-based SYSVOLs para pasar a usar Distributed File System Replication. Si no lo hemos realizado hasta la fecha, desde Windows 2008 SP1, ahora va a ser el momento.

Un vistazo para empezar en la TechNet.

2. Desaparece el rol de Aplication Server y se dispersa como características y roles separados. (Deprecado)

3. DFS

Desaparecen, entre otras cosas, dos clásicos: Dfscmd.exe y Nfsshare.exe para pasar a ser parte de PoweShell

4. IIS Manager 6.0 (Deprecado)

Cambia de consola.

5. Network Access Protection (NAP) (Deprecado)

Nos pasamos a DirectAccess, Windows Web Application Proxy y otras soluciones de 3ºs

6. El servidor Network Information Service (NIS) desaparece (Deprecado)

Recordar que era la integración del Directorio con máquinas UNIX

7. Telnet (Deprecado en el servidor)

Pasamos a Remote Desktop

8. Windows Identity Foundation (WIF) 3.5 (Deprecado)

Se reemplaza con WIF 4.5, así que nos toca migrar aplicaciones a WIF 4.5 o Windows .NET Framework 4.5

9. SQL Lite (Deprecado)

Tenemos que buscar alternativas como SQL LocalDb

10. File Backup and Restore (Deprecado)

Tenenos que usar File History

11. Morirá el  SMTP (Deprecado)

Ya estábamos deprimidos con la desaparición del Telnet, y ahora el SMTP. ¿Qué vamos a hacer?

En el post anterior, de un forma sencilla y pobre, hemos descrito lo significa el DSC. Como vemos el DSC es desarrollar una serie de configuraciones y poder ejecutarlas en una maquina. Hay un nuevo objeto en PowerShell 4.0 que es Configuration. Con él podemos crear los contenidos el MOF.

La primera pega que hemos escuchado es que no soporta orquestación como lo hace System Center o el Workflow de PowerShell. El poder lanzar a varias maquinas y al necesitamos orquestación, tenemos que pensar que usar.

Y así parece que es: podemos lanzar configuraciones dedicadas a nuestras máquinas y tendremos que ver en que momentos sería útil frente a otras formas de hacerlo. Personalmente, estoy recopilando la información sobre lo relevante de esta nueva funcionalidad para traerla al blog.

Os recomiendo, no obstante, el recorrer la pagina de Lido Paglia dónde están los paso a paso del DSC y poder probarlo.

Introducción

El Estado deseado de configuración son unas herramientas basadas en PowerShell que sirve para la gestión de entornos Microsoft. Estas extensiones sólo están presentes en Windows 2012 R2 y Windows 8.1.

Usamos los proveedores WMI, unos 12, que habilitan la configuración de roles, características, gestiona servicios, y mucho más. Podemos crear nuestros propios proveedores.

Implementación

Podemos realizar dos tipos de implementaciones: push o pull y seguimos tres pasos para ellos.

• La primera fase es la Authoring
• La segunda es la Stating (en el modo Pull)
• La tercera es la fase de Implementation

Primera fase: Authoring

Se crea un DSC con PowerShell o herramientas de terceros, creando uno o más MOF (Management Object Format) dónde está la configuración.

Segunda fase: Stating

En el modo pull, los datos de DSC y cualquier proveedor personalizado están en el servidor Pull que es un servidor IIS. El sistema destino pasa un URI (Uniform Resource Identifier) y le envía el servidor pull la configuración y los proveedores necesarios si no los tiene. En la forma push todo ello tiene que estar instalado en el destino.

Tercera fase: Fase de implementación

Los datos DSC, enviados en pull o en push, llegan al Almacenamiento Local de la Configuración, y el proveedor WMI apropiado implementa la configuración que llega en el DSC.

Alcance de las funciones del DSC

• Instalar roles y características
• Gestionar la configuración del registro
• Gestionar archivos y directorios
• Parar, arrancar o gestionar procesos y servicios
• Gestionar grupos y usuarios locales
• Instalar y gestionar paquetes, como .msi o .exe
• Gestionar variables de entorno
• Lanzar scripts de PowerShell
• Ejecutar la configuración deseada
• Descubrir el estado actual de la configuración