Azure y System Center Configuration Manager

23.10.2017 -  Alejandro Tejero COMPAREX

 

Podemos usar Azure usando IAAS o SAAS

 

IAAS

Podemos usar un escenario de IAAS usando Azure como CPD adicional.  Configuration Manager puede ejecutarse en máquinas virtuales de la misma forma que se ejecuta en local. Se puede utilizar Configuration Manager con máquinas virtuales Azure en los siguientes escenarios:

  • Escenario 1: Ejecutar el Administrador de configuración de una máquina virtual Azure y utilizarlo para administrar los clientes que están instalados en otras máquinas virtuales Azure.
  • Escenario 2: Ejecutar el Administrador de configuración de una máquina virtual Azure y se utiliza para gestionar los clientes que no se están ejecutando en Azure.
  • Escenario 3: Se puede ejecutar diferentes roles de “Configuration Manager Site System” en las máquinas virtuales de Azure incluso habiendo otros roles en la red local.

Hay que valorar el uso de las comunicaciones entre el sitio local y el Azure, ya que se va a mover tráfico y depende de los servicios que alojemos en Azure podremos tener un mayor consumo con su correspondiente coste.

Las comunicaciones de sitio a sitio (basadas en archivos y replicación de bases de datos) es muy ventajosa si existe proximidad con Azure.  Sin embargo, todo el tráfico relacionado con el cliente estaría alejado de los “Site Servers” y “Site Systems”.  Si utiliza una conexión de red rápida y fiable entre Azure y la intranet con un plan de datos ilimitado, el alojamiento de toda la infraestructura en Azure sería una buena opción.

Sin embargo, si utiliza un plan de datos medido y el ancho de banda disponible o el coste es un valor importante (que suele serlo), o la conexión de red entre Azure y la intranet no es rápida o poco fiable, hay que considerar colocar sitios específicos y utilizar los controles de ancho de banda incorporados en Configuration Manager.

Son los mismos requisitos que tiene System Center Configuration Manager para redes, configuraciones admitidas y requisitos de hardware para tenerlo en su red corporativa física, también se aplican a la instalación en máquinas virtuales de Azure.

SAAS

Podemos utilizar Servicios en Azure que se integra con SCCM sin la necesidad de crear VM en azul.  Podemos utilizar 2 servicios: “Cloud distribution point and cloud management gateway”

Punto de distribución de la nube

Un punto de distribución basado en la nube es un punto de distribución de System Center Configuration Manager que está alojado en Microsoft Azure.

Escenarios
Además, hay muchos escenarios diferentes mezclando los expuestos aquí (por ejemplo, la ubicación de los sitios primarios o secundarios en los diagramas se encuentran en Datacenters locales, pero podemos usar las máquinas virtuales Azure en su lugar)


Jerarquía
 n primer lugar, tenemos que hablar de las diferentes jerarquías que podemos usar en un despliegue de sccm.
Las topologías abarcan desde un único sitio primario independiente hasta un grupo de sitios primarios y secundarios conectados con un sitio de administración central en el sitio de nivel superior (nivel superior) de la jerarquía. El controlador clave del tipo y el recuento de sitios para usar en una jerarquía suele ser el número y el tipo de dispositivos que deben ser compatibles:
 
•  Sitio primario independiente: Utilice un sitio primario autónomo cuando un solo sitio principal puede admitir la administración de todos sus dispositivos y usuarios. Esta topología también tiene éxito cuando hay diferentes ubicaciones geográficas que pueden ser atendidas con éxito por un único sitio principal y el uso de servidores remotos para la distribución de contenido.
 
•  Sitio de administración central con uno o más sitios primarios niño: Utilice esta topología en caso de requerir más de un sitio principal para apoyar la gestión de todos los dispositivos y usuarios. Es necesario cuando se necesita utilizar más de un sitio primario único.

Servicios adicionales en jerarquía

Para cada sitio primario vamos a implementar servidores para diferentes servicios como la distribución, el punto de actualización de software y punto de administración.

• Sitio secundario

Dan la capacidad para soportar casi todo el tráfico de clientes para lugares remotos mediante la colocación de un “Management Point” y “Software Update Point”, así como un punto distribución en ese lugar remoto. The traffic sent back to primary site is then scheduled and throttled as well. El tráfico enviado de vuelta al sitio principal también se programa y se estrangula también. Without a secondary site in the mix, client to MP and client to SUP traffic is not controlled in this manner. Sin un sitio secundario en el entorno, el tráfico del cliente al MP y al SUP no se controla de esta manera.
 
Al usar un sitio de administración central
• Un sitio principal puede admitir miles de clientes cuando conviven SQL en el mismo servidor, y pueden soportar un mayor número de clientes que si SQL is on a separate server.está en un servidor separado. Se decide basado en el número de clientes el número de sitio primario y Cas.
• Un sitio primario puede tener un máximo de 250 sitios secundarios. If need more secondary sites a CAS and multiple primary sites will be needed Si se necesitan más sitios secundarios se necesitará un CAS y múltiples sitios primarios
• Un sitio primario solo tiene una limitación en el número de puntos de distribución. And Secondary sites support 250 distribution points each, so you can add secondary sites below a primary to add additional distribution points, up to a maximum of 5,000 per primary and its secondary sites. Y los sitios secundarios soportan 250 puntos de distribución de cada uno, para que pueda agregar sitios secundarios por debajo de un primario hay que agregar puntos de distribución adicionales, hasta un máximo de 5.000 y sus sitios secundarios. Si necesitamos más de 5000 DP, se necesitará un CAS y múltiples sitios primarios

La división de la carga a través de dos sitios principales:
Con un sitio de administración central (CAS), y dos o más Primarias podemos dividir los clientes a través de múltiples sitios primarios, con la idea de que si usted perdió una primaria, todavía se podía soportar la mitad de su entorno hasta que se recupere la otra primaria. Los Pros y Contras de esto son los siguientes:
• Pros
Si pierde la CAS o la Primaria, al menos una Primaria sigue funcionando, al igual que sus Sitios Secundarios hasta que la CAS u otra Primaria se vuelva a poner en línea. (El factor determinante de si este es realmente un Pro es "¿Cuánto tiempo me llevará a volver a poner en línea el CAS o el otro sitio principal?"), Así como lo que el SLA solicita, ya que se aplica al administrador de configuración dentro de la organización.

- Normalmente, se tarda alrededor de 3 horas para recuperar sitios SCCM si tiene SCCM DB como copia de seguridad de sitio SCCM disponible.
-Los usuarios no notarán que el servidor no está operativo y puede funcionar como de costumbre.

Elimina el escenario Punto Único de Falla del diseño, ya que los clientes asignados a otras primarias podrían seguir informándose y ser administrados
•    Contras
Esto agrega múltiples puntos de fallo individuales, uno para cada sitio principal y el CAS.

Aumento de los costos de licencias
Aumento de los costes de hardware
Mayor duplicación de SQL


Impacto de la interrupción de la base de datos:
Las bases de datos SQL están asociadas con el servidor de sitio de administración central (CAS) y el servidor de sitio principal. Las paradas de la base de datos en cada uno de estos niveles producirán diferentes niveles de impacto.Para entender el impacto de la base de datos es importante entender la topología de replicación SQL de SCCM:


Impacto de la interrupción de la base de datos en CAS
Si la base de datos está en el CAS, se verá el siguiente impacto:
• Impacto for para adminstradores:

Los administradores no podrán conectarse a la consola SCCM que se está conectando al CAS
Los administradores que ya accedían a la Consola SCCM en el CAS tendrán que restablecer manualmente la conexión para apuntar al servidor principal del sitio

Los informes en el CAS se detendrán y los usuarios que apunten al CAS para acceder a los informes de SCCM tendrán que apuntar al servidor principal del sitio

• Impacto para Usuarios Finales

No se pueden crear nuevos paquetes de aplicaciones en el CAS y distribuirse, aunque las aplicaciones se pueden crear en el servidor principal de sitios
Los nuevos parches no se pueden sincronizar con el sitio web de Microsoft, aunque los parches existentes estarán disponibles para todos los clientes
Las definiciones de antivirus basadas en SCCM no se aplicarán, aunque pueden aplicarse a través de una ruta UNC en otro servidor


Impacto de la interrupción de la base de datos en el servidor principal del sitio
Si la base de datos está en el nivel de servidor principal de sitio, se verá el impacto siguiente:


• Impacto for para administradores:

SCCM no podrá almacenar inventario de nuevos clientes
Ninguna nueva actualización del Secondary Site Server subirá la jerarquía en SCCM
El descubrimiento de datos de los clientes no se actualizarán a la base de datos
El descubrimiento por “hearbeat” no se actualizará en la base de datos


• Impacto for para Usuarios Finales


Los nuevos despliegues de cualquiera de las siguientes no se anunciarán a los clientes:
Solicitud Actualizaciones
Software
Antivirus
Imagen
No se pueden crear nuevos paquetes de aplicaciones en el servidor de sitio principal, aunque estas aplicaciones no se crearán en el servidor de sitio principal de forma predeterminadaSi el Servidor del Sitio Primario desaparece justo después de instalar SCCM en un nuevo cliente,
No aparecerá en SCCM
Cualquier implementación de SCCM en ese nuevo cliente no ocurrirá
Los nuevos clientes no reciben las políticas de antivirus
Los nuevos clientes no recibirán parches

Los nuevos clientes no obtendrán ninguna aplicación o políticas de línea de base
 

Impacto de la interrupción de la base de datos en Secondary Site Server

Si la base de datos está inactiva en el nivel de servidor de sitio secundario, se verá el siguiente impacto:


Las actualizaciones de cliente no se replicarán entre el servidor de sitio primario y secundario, es decir,
Las actualizaciones de inventario no fluirán al Servidor principal de sitios
Los datos meta de los paquetes también llamados como los datos del sitio no se replicarán entre los servidores de sitio primario y secundario
Los nuevos despliegues de cualquiera de las cargas útiles siguientes no se anunciarán a los clientes asignados al sitio secundario:
Solicitud  Actualizaciones
Software
Antivirus

Imagen


Escenario A - CAS en Azure utilizando el modelo IaaS y un sitio principal para cada zona

 

Este es un ejemplo del escenario más complejo.  Cada sitio primario puede tener sitios secundarios para grandes oficinas de cada Zona.
Con un sitio principal tendremos un punto de administración en lugares remotos y el tráfico de los clientes de la zona al punto de administración será contra el CPD de la Zona. Existirá el tráfico de replicación de SQL entre el sitio principal y el CAS.
 
•  Pros:
Comunicaciones de los clientes estarán contra el servidor en cada zona
En caso de fallo del sitio principal, sólo los clientes asignados a ese sitio se verán afectados
•     Contras
Diseño complejo
Gran diferencia en hardware y costos de licencias
Gastos generales de administración
Solución de problemas difíciles
Múltiples puntos de fallo, uno por cada sitio primario y el CAS Sql traffic replication between primary sites and CAS
Replicación de tráfico Sql entre sitios primarios y CAS
No hay soporte para PXE en la zona sin servidores dedicados I
 

Escenario B - Standalone jerarquía de sitios primaria

El servidor primario y el sitio se encuentra en un CPD en la zona 1 y en este CPD hay diferentes servidores con todos los roles requeridos (punto de administración, punto de distribución, PXE, el punto de notificación de servicios, bases de datos, software de punto de actualización, etc.).
Para apoyar al resto de zonas podrá haber un servidor dedicado ubicado en el CPD de cada zona con las siguientes funciones:
•     Punto de distribución: mayor consumo de ancho de banda. It will hold al content that can be distributed to clients at the Zone . Tendrá los paquetes que se pueden distribuir a los clientes en la zona.
•    Soporte para arranque de red para nuevas máquinas sin sistema operativo o para actualizar una antigua. Este servicio utiliza tftp y es sensible a las altas latencias de la red.
•    SUP: Función de punto de actualización de software para admitir el despliegue de actualizaciones de software.
El servidor (o servidores) en la Zona Data Center proporcionará servicios a las pequeñas localidades remotas mientras que en oficinas más grandes podría haber un servidor dedicado.
 
También hay un punto de distribución de Cloud en Azure utilizando un enfoque SaaS que puede dar soporte a clientes fuera de la Lan para muchas funciones (implementación de aplicaciones, implementación de actualizaciones, descarga de contenido, recuperación de políticas, etc.)
•    Pros
Diseño simple
Fácil de administrar y delegar
Bajo número de servidores y costo en hardware / licencias
Fácil escalabilidad              
•   Contras
Comunicaciones para el tráfico punto de administración de todos los clientes a través de WAN a punto de administración en la zona 1 Data Center Centro de datos
Único punto de fallo en caso de SQL de fallo del sitio principal (RTO de 3 horas o menos)
No hay soporte para PXE en la oficina sin servidores dedicados
 
 
 
Escenario C – - Azure SaaS

Con un sitio secundario tendremos un punto de administración en lugares remotos y el tráfico de los clientes de la Zona al punto de administración será contra el CPD de la zona.
No hay coste adicional para agregar un sitio secundario porque el hardware usado para dar soporte a DP, sup y Pxe puede albergar el rol de sitio secundario y usará la DB de SQL Express sin coste de licencia.
También hay un punto de distribución de Cloud y un punto de administración de proxy en Azure utilizando en modo SaaS que puede dar soporte a clientes fuera de la Lan para muchas funciones (implementación de aplicaciones, implementación de actualizaciones, descarga de contenido, recuperación de políticas, etc.)
•  Pros
Diseño simple
Fácil de administrar y delegar
Bajo número de servidores y costo en hardware / licencias
Fácil escalabilidad
 Comunicaciones de los clientes estarán con el servidor de cada zona
•  Contras
Único punto de fallo en caso de SQL
Replicación de tráfico Sql entre sitios secundarios y sitios primarios
 No hay soporte para PXE en la zona sin servidores dedicados

 

 

 

23.10.2017 | Azure y System Center Configuration Manager

Podemos usar un escenario de IAAS usando Azure como CPD adicional. Configuration Manager puede ejecutarse en máquinas virtuales de la misma forma que se ejecuta en local. Más información +
 

15.10.2017 | ¿Te interesa actualiza tus infraestructuras locales sin incurrir en costes añadidos?

Para adaptarse con agilidad a los nuevos requisitos de los negocios, no basta con moverse al cloud. Nuestras infraestructuras locales necesitan dinamismo en una realidad híbrida que hay que gestionar con sencillez y eficacia. ¿Qué hacer para modernizarlas? Más información +
 

18.09.2017 | Las ventajas indiscutibles que presenta construir cualquier negocio con estrategias en la nube

En COMPAREX acompañamos a nuestros clientes a lo largo de todo el ciclo de vida en el Cloud, y no dudamos de las ventajas que conlleva construir un negocio con Office 365, precisamente siempre estamos pendientes de toda la innovación y así lo trasladamos a nuestros clientes. Más información +
 

Pages: 1

Social Media

Por favor hacer click en el icono de abrir perfil Social Media en una nueva pestaña:


Contacto

  •  Parque Empresarial Alvento
     C/ Vía de los Poblados Nº 1,
     Edificio C, 6ª planta
  •  ES-28033 Madrid
  •  +34 91 598 14 06