Cerrar
InicioEsquemasRequisitos de HW y SW para una Infraestructura IT de Comunicaciones Unificadas para PYMES (Parte I de IV)

Requisitos de HW y SW para una Infraestructura IT de Comunicaciones Unificadas para PYMES (Parte I de IV)

En algunas ocasiones me han llegado varios correos con la misma consulta: ¿Qué recursos necesito para implementar una solución de Comunicaciones Unificadas con MSFT? Si tiramos de KB la respuesta es clara: Determinar los requisitos del sistema para Lync Server 2013 y Requisitos para el entorno de Skype Empresarial Server 2015. El “problema” viene cuando queremos ajustar estos requisitos a nuestros entornos, no tan grandes como plantea MSFT en sus documentos (pulsar en la imagen para verla a tamaño real):

Esquema_Basico_ST.jpg
Aquí os dejo un escenario (como otros muchos) que puede os puede ser útil, partiendo de la base de un cliente que quiera tener un entorno MSFT contando con:
  • Directorio Activo
  • Skype For Business 2015
  • Exchange Server 2010/2013
  • Servidor de Ficheros
  • Reporting (Opcional)
He creado cuatro esquemas básicos a nivel de infraestructura para que los podáis tomar como referencia, tanto a nivel de Software como de Hardware de comunicaciones (Switch, Router). Lo primero comentaros que la idea es disponer de un entorno de virtualización “sencillo”, aquí tenéis las características que he expuesto para poder dar alcance a un proyecto para una PYME (pulsar en la imagen para verla a tamaño real):
Esquema_Basico_ST-HW-SW_2016.jpg
Hardware para Comunicaciones:

Hardware y Software para Virtualización:

  • Servidor Cisco UCS (u otro fabricante) con las siguientes características:
    • 2HDD SAS de 146GB cada uno para la instalación del Sistema Opertivo (en RAID1)
    • 4HDD SAS de 1TB cada uno para el almacenamiento de las MV (VHDX) (RAID 5 o 10)
    • 64GB de RAM (para repartir entre las MV y el HOST) hoy en día no es nada descabellado
    • 4 NIC de 1GB para la configuración de la red Virtual (vSwitch) en Hyper-V
  • Windows Server 2012 R2 DataCenter (aquí cada uno tiene que ver el mejor esquema de licenciamiento)
    • Número de Procesadores
    • Número de MV a configurar
  • Exchange Server 2013
  • Skype For Business 2015

Backup:

  • Microsoft Azure Backup: súper flexible y económico, para muchos entornos de PYMES (y no PYMES) es el compañero ideal

Monitorización:

Pues con todo esto, podemos disponer de una infraestructura IT On-Premises muy “decende” sin tener que invertir una cantidad de dinero importante. Está claro que no es gratis, pero para una PYME debería ser más que asumible. Mi idea es implementar para un cliente una solución On-Premises (si, aún hay clientes que así lo prefieren) con toda la plataforma de Comunicaciones Unificadas. OJO, estos requisitos son estimados para una empresa de más o menos 50 usuarios, pero tampoco os agarréis a esto a muerte, puesto que siempre debéis analizar los requisitos de vuestros clientes. Podéis tener clientes que tengan un uso intensivo de Exchange o del servidor de ficheros, etc… por lo que tendréis que ajustar los recursos a asignar a cada servidor virtual (pulsar en la imagen para verla a tamaño real):

Esquema_Basico_ST- SFT.jpg
Si a todo esto queréis añadir una capa de alta disponible de forma económica, podéis adquirir un servidor con las mismas características y replicar las MV entre ambos servidores: Replicar MV en Hyper-V con Windows Server 2012. Esto permite a “bajo coste” tener un sistema replicado, pero ojo: NO ES UN CLUSTER (que sería más costoso).

En cuanto al backup (obligatorio si o si), el utilizar Microsoft Azure Backup (Azure Backup) os permitirá tener vuestras copias de seguridad en la nube de forma sencill, pero esto no hace que nos tengáis o debáis implementar una solución de backup On-Premises. Lo suyo sería tenerlo online siempre y cuando tengáis las líneas de datos necesarias y os encajen las planficiaciones  y escenarios de recuperación de Azure. Aquí os dejo alguna guía de implementación de Azure Backp:

En cuanto a la monitorización, a día de hoy es algo indispensable para todos los sistemas, desde el más crítico hasta el que necesita una disponibilidad básica de sus servicios. Con PRTG tenéis la oportunidad de implementar una solución profesional a coste 0 hasta 100 monitores, creo que está muy bien por lo menos para que le déis una oportunidad de probarlo: https://shop.paessler.com/shop/free_license/?showkey=1&download=1&_ga=1.253790667.230753048.1451758233

En cuanto a las comunicaciones aquí tenemos múltiples configuraciones, podemos crear nuestra topología en base al hardware que tenemos (y las características que tengan) o diseñar un sistema de red complejo con hardware más sofisticado. Entiendo que en muchos casos tenéis que ajustaros el primer escenario, “con lo que tengo” debo hacer funcionar todo y “bien”. Bueno, pues llegados aquí es donde os muestro varios escenarios más o menos simples y que casi con cualquier hardware podemos realizar esta implementaciones. La idea es que que los servicios de Skype for Business y Exchange Server estén disponibles desde Internet (Federaciones, Usuarios Externos,  OWA, ActiveSync, etc…), de ahí que las MV que tienen el EDGE y el Reverse-Proxy se “recomiende” que tengan dos interfaces con subredes IP diferentes (como mínimo) y a ser posible en VLAN diferentes que no tengan nunca acceso entre ellas de forma directa. Vamos, que desde la red “pública” del EDGE o Reverse-Proxy no se tenga conexión física ni lógica con la subred de la interface LAN en donde están los equipos de la red. Para ello, lo suyo es tener cableado diferente o configurar VLAN en el Switch para asignar cada interface de cada MV a dicha VLAN (esto se puede realizar de múltiples formas). Eso que parece “complejo” es más “simple” de lo que parece, pero para ello si debemos disponer de un hardware que permite dichas configuraciones. Igualmente, os mostraré distintas configurafciones que también disponen de un buen nivel de seguridad sin que tengamos que invertir una cantidad de dinero importante en este tipo de hardware (pero lo suyo sería eso).

He recreado 4 escenarios que suelen ser muy comunes en las empresas, en donde tenemos un Router/Firewall y un Switch (o varios) para ofrecer niveles de comunicación internos y externos a los usuarios. Según vaya comentando algunos escenarios, trataré de mostraros las distintas configuraciones que podéis realizar (yo utilizaré hardware Cisco para las comunicaciones, pero en otro hardware podréis hacerlo igualmente), y en donde pueda hacer referencia a algún artículo del blog así lo haré.

El escenario en cuanto a virtualización es “básico”, utilizaremos Hyper-V para crear nuestro entorno de virtualización en donde iremos desplegando las distintas máquinas virtuales y en base a las configuraciones de red, utilizaremos distintas VLAN (a nivel de Hyper-V y Switch) para asignar las tarjetas de red a cada servidor. La VLAN200 es para la red local, en donde estarán todos los servidores y los clientes, los cuales estarán en la misma subred IP (192.168.0.0/24, cada uno que tenga la subred IP que considere). Luego tendremos la VLAN201 para los servidores que tienen dos tarjetas red y esta se dedicará a la parte “pública” de los servicios que en ellos estemos configurando (EDGE de SkypefB y Reverse-Proxy), estos servidores estarán en al subred 172.26.0.0/28 (sólo podréis tener HOST configurados con las siguientes IPs 172.26.0.1 – 172.26.0.14, esto siempre lo hago así para limitar la cantidad de equipos que tenemos en la subred pública, evitando así que tengamos algún equipo de “más” en dicha subred). Siempre suelo asignar la primera dirección del pool (172.26.0.1) al dispositivo que hace de enrutador y luego el resto a los HOST / Dispositivos de la misma subred, pero allá cada uno con sus propias configuraciones.

Pues dicho esto, vamos a empezar con el primer esquema de red, el cual será el más básico de todos, puesto que la configuración más “compleja” la tenemos en el router:

Esquema_Basico_ST_0.jpg
Como en el servidor de virtualización habíamos dicho que tenemos 4 interfaces de red, lo que haremos será configurar un TEAM (agrupación de intefaces de red para ofrece tolerancia a fallas o dotar de más rendimiento en cuanto a red se refiere al servidor, esto lo haremos con Windows Server 2012) con tres tarjetas, y la que nos queda libre la dejaremos para el acceso al HOST de virtualización. Dicho TEAM lo asignaremos a Hyper-V, aquí os dejo un artículo básico de cómo configurar un TEAM en Windows Server 2012 (en R es igual):

De esta forma tendremos tres tarjetas de red funcionando como una sola tarjeta de red, pero ofreciendo mayor rendimiento y disponibildad. De esta forma, si por lo que sea se desconecta/estropea alguna de las tarjetas de red, el sistema seguirá funcionando con total normalidad, puesto que el resto de tarjetas estarán operativas y con los datos de configuración intactos. Como lo que queremos en disponer de diferentes VLAN y hemos configurado un TEAM entre nuestras tarjetas, debemos realizar una pequeña configuración en el Switch para que permita transportar tráfico de diferentes VLANs por ese grupo de interfaces, que para él se comporta como si fuese un único enlace. Por lo que si especificamos una VLAN en el Switch todo el tráfico irá etiquetado con esa misma VLAN y nosotros queremos transportar las VLAN 200 y 201. La configuración del puerto del Switch Cisco sería la siguiente (sólo estoy mostrando la parte de la configuración del TEAM, la creación de las VLAN es trivial y entiendo que la conocéis):

SwitchCisco(config)# interface port-channel 1
SwitchCisco(config-if)# switchport mode trunk
SwitchCisco(config-if)# switchport trunk allowed vlan remove 200,201 (opcional pero recomendado)

Las dos primeras líneas de configuración establecen el grupo de puertos configurado para el TEAM a TRUNK (la interface port-channel1 es un puerto virtual configurado con 802.3ad, es la parte de configuración del TEAM a nivel Cisco (opcional) (http://www.cisco.com/c/en/us/td/docs/ios/12_2sb/feature/guide/gigeth.html)). La tercera línea es para restringir las VLANs a transportar por dicho enlace, evitando así que se configure de forma errónea alguna VLAN que no exista en el Switch y pueda inundar de tráfico el propio Switch y genera una denegación de servicio innecesaria).  Hecho esto, únicamente debemos asignar las interfaces virtuales a las MV y en su configuración especificar la VLAN con la que van a etiquetar el tráfico de cada red a la que tengan que pertener cada servidor. Este proceso es muy sencillo, únicamente debemos editar la interface de red virtual de cada servidor y especificar la VLAN en la que se encuentra:

Esquema_Basico_ST_0_RED.jpg

Esto debemos hacerlo con cada servidor, porque como os comentaba el inicio del artículo, nosotros tenemos dos VLAN:

  • 200: Red LAN – 192.168.0.0/24
  • 201: Red DMZ – 172.26.0.0 /28

De esta forma, cada servidor no sólo tendrá comunicación con su misma subred no sólo por la red IP a la que pertenezca, sino por la VLAN a la que pertenezca su tarjeta de red. Con esto podemos aislar el tráfico entre MV, evitando así conexiones entre redes no deseadas, además de aislar los servicios públios y LAN en sus propias redes.

Por último nos queda conectar ahora el router a cada subred y VLAN, en este caso como el router tiene dos interfaces LAN, únicamente debemos asignarle una dirección IP de cada subred y luego conectar cada interface LAN al Switch a dos puertos configurados cada uno en su VLAN. Como os había comentado anteriormente, la primera IP de cada subred yo la suelo establecer al Router/Firewall que tenga, de tal forma que la configuración del Router sería la siguiente:

Configuración A: Interfaces de físicas de Capa 3

interface FastEhernet0
 description Red Local
 ip address 192.168.0.1 255.255.255.0
 ip nat inside
interface FastEhernet1
 description Red Local
 ip address 172.26.0.1 255.255.255.240
 ip nat inside

Configuración B: Interfaces de virtuales de Capa 3

interface Vlan200
 description Red Local
 ip address 192.168.0.1 255.255.255.0
 ip nat inside
interface Vlan201
 description Red Local
 ip address 172.26.0.1 255.255.255.240
 ip nat inside
Ahora no me voy a parar mucho en esta configuración, pero sólo comentaros que en base al router que tengáis podéis realizar la configuración A o B. Disculpad que ahora no me parece con ello, pero es bastante más extenso de explicar y os prometo un artículo con ello, pero ahora mismo quedaros con que el router tiene dos interfaces LAN y cada una tiene una IP de un rango de las subredes que tenemos en nuestra topología. Por último, debemos conectar cada interface a una VLAN configurada en el Switch, eso es así porque el Router no tiene las VLAN como tal creadas y las MV tiene sus interfaces en distintas VLAN y queremos darle conectividad de Internet a los dos segmentos, por lo que ahora tenemos que conectar cada interface en la VLAN correspondientes para que los servidores virtuales tengan “salida a Internet” através del router. Pues bien, el Switch debe tener dos puertos libres para conectar las interfaces del router y ambos deben estar configurados como puertos de acceso con la VLAN correspondiente:
interface GigabitEthernet0/0
 description VLAN Interface LAN del Router Cisco
 switchport access vlan 200
 switchport mode access
interface GigabitEthernet0/1
 description VLAN Interface DMZ del Router Cisco
 switchport access vlan 201
 switchport mode access

Con esta configuración en el Switch y cada interface LAN del router conectada a su puerto correspondiente, los equipos de la red local y DMZ ya tienen acceso a Internet (si el router da ese servicio, que en nuestro caso si). Pero aún nos falta algo por configurar, porque como cualquier dispositivo de Capa 3 su función es la de enrutar (interconectar dos redes IP diferentes) y ahora tenemos conexión entre ambas redes IP cosas que no queremos. Para ello en el router creamos dos listas de acceso (ACL) que aplicaremos a cada interface LAN evitando que tenga acceso a la otra interface vía L3:

ACL asignada a la Interface GigabitEthernet0/0

  • access-list 120 deny ip 192.168.0.0 0.0.0.255 172.26.0.0 0.0.15
  • access-list 120 permit ip 192.168.0.0 0.0.0.255 any
ACL asignada a la Interface GigabitEthernet0/1
  • access-list 121 deny ip  172.26.0.0 0.0.15 192.168.0.0 0.0.0.255
  • access-list 121 permit ip 172.26.0.0 0.0.15 any

La primera línea de cada ACL evita que la subred local de la interface se conecte con la otra interface local del router en la otra subred, y la segunda entrada de la ACL permite el acceso a los equipos de la subred IP que tiene cada interface a cualquier destino. En Cisco como en otras tecnologías las reglas se leen de forma sencuencial de arriba abajo, por lo que en cuanto una línea de configuración tenga aplicación se aplica al momento. Dicho esto, como cada ACL se aplica a la interface correspondiente, lo primero que hará será denegar el tráfico entre las subred IP internas que tiene el router configuradas y luego sólo permitirá el tráfico en dichas interfaces que provegan de la subred que tienen configuradas. Aquí os muestro como se aplica la configuración de cada ACL a cada interface LAN de red del router:

Configuración A: Interfaces de físicas de Capa 3
interface FastEhernet0
 description Red Local
 ip address 192.168.0.1 255.255.255.0

 ip access-group 120 in
 ip nat inside

interface FastEhernet1
 description Red Local
 ip address 172.26.0.1 255.255.255.240

 ip access-group 121 in
 ip nat inside
Configuración B: Interfaces de virtuales de Capa 3
interface Vlan200
 description Red Local
 ip address 192.168.0.1 255.255.255.0

 ip access-group 120 in
 ip nat inside

interface Vlan201
 description Red Local
 ip address 172.26.0.1 255.255.255.240

 ip access-group 121 in
 ip nat inside

La configuración de la ACL es la misma siempre (en cuanto a la estructura) y la forma de aplicarse a la interface, para ello utilzaremos el comando ip access-group <número ACL> IN (IN porque el tráfico es de entrada a la interface LAN). Ahora sí que ya tenemos todo lo que necesitamos:

  • Dirección IP de cada subredes en cada interface del router
  • Switch con las VLAN creadas y asignadas en las interfaces en donde conectaremos el Router
  • Interface para la configuración de 802.3ad para el TEAM con Windows Server y dicho puerto en modo TRUNK (para transportar tráfico de distintas VLANs)
  • Los servidores virtuales con las interfaces de RED asignadas a cada VLAN

Ahora ya tenemos ambas subredes con conexión a Internet y sin conexión directa en ellas, por lo que los sevidores estarán en sus propias subredes asiladas entre sí (es lo que buscamos). Ahora el resto que nos quedaría sería implementar el resto de servicios:

  • Directorio Activo
  • Exchange
  • Skype for Business
  • Etc..

Aquí os dejo un artículo resumen con la instalación de Lync (aplicable a Skype For Business en casi el 90% de la solución) y publicación de servicios (aplicables 100% a Skype For Business):

Encontraréis la publicación de los servicios de móvil para Lync/SkypefB, EDGE, etc… por lo que ya no los vuelvo a poner aquí nuevamente.  Es posible que este artículo os pareza muy similar a este otro, pero aquí quiero darle otros matices que iréis viendo: 9 Posibles esquemas de red para nuestras implementaciones de Lync Server

Topologías Lync 2013_10.jpg

Con esto doy por terminado el primer artículo de los 4 de los que se compone este megaartículo, espero que no os haya liado más y haya servido para dar algo de luz en algunos aspectos iniciales de vuestros proyectos.

En breve el segundo artículo, mientras tanto si tenéis alguna duda sobre este, por favor dejar vuestros comentarios.

Último Artículo de
Lync Server 2013 Cum

sbuytrago@asirsl.com

2 COMENTARIOS
  • José Daniel Nuño / 5 febrero, 2018

    No se ve las imágenes. Ponlas… por favor!

    • Santiago Buitrago Reis / 6 febrero, 2018

      Hola José Daniel,

      Este artículo ya tienes las imágenes,

      Un saludo

Este sitio web utiliza cookies. Si continúas navegando, consideramos que aceptas su uso. Puedes obtener más información en nuestra política de cookies. ACEPTAR

Aviso de cookies
Share This