Exportar (0) Imprimir
Expandir todo

SharePoint 2013 en la infraestructura de Azure

Actualizado: abril de 2014

Con los servicios de máquina virtual y red virtual de Azure, ahora es posible implementar y utilizar una granja de Microsoft SharePoint 2013 con conexión a Internet con SQL Server AlwaysOn en Azure. La siguiente figura muestra una configuración de ejemplo.

En este tema se describen las consideraciones, la arquitectura y las operaciones de diseño clave necesarias para hacerlo correctamente. En este tema se da por supuesto que tiene conocimientos prácticos básicos de SharePoint Server 2013 y que está familiarizado con los servicios que ofrece Azure.

Microsoft ofrece y otorga licencia de dos categorías de soluciones de granja de SharePoint. Estas soluciones están en la nube (SharePoint Online con Office 365) y de forma local (SharePoint 2013).

SharePoint 2013 utiliza la licencia y la instalación de software tradicionales. Puede instalar y configurar SharePoint para implementar una granja en equipos físicos o en un entorno virtual. También tiene la posibilidad de implementar y utilizar una granja en su propio centro de datos o en una infraestructura proporcionada por un servicio de hospedaje. Este conjunto de documentos de solución describe la implementación de una granja de SharePoint 2013 para usuarios de Internet con SQL Server AlwaysOn en los servicios de infraestructura de Azure.

SharePoint Server 2013 proporciona un conjunto completo de características para admitir una amplia variedad de actividades de colaboración para una organización. Sin embargo, estas características y capacidades pueden dificultar el planeamiento y el diseño debido a lo siguiente:

  • No hay ningún tamaño único genérico adecuado para el diseño de una granja. Las granjas implementadas en distintas organizaciones pueden parecer similares y tener el mismo número de servidores de la granja, pero un examen más cercano mostrará que hay algunas diferencias importantes entre dos granjas cualesquiera. Más adelante en este artículo se describen los patrones genéricos de topología que le ayudarán a diseñar una granja.

  • Aunque hay varias maneras de evaluar los requisitos de capacidad de una granja y de los servidores para realizar estimaciones de tamaño, no existe una única fórmula global para generar un diseño detallado de granja completo con cantidades y capacidades de servidor.

No se puede exagerar la importancia del planeamiento y el diseño de una granja de SharePoint. Un diseño inadecuado que tenga como consecuencia un diseño deficiente de una granja es la causa principal por la que las granjas de SharePoint pueden no estar a la altura de las expectativas de los usuarios y no satisfacer los objetivos de una organización. Los problemas de planeación y de diseño también contribuyen a un número significativo de llamadas al servicio de soporte técnico relacionadas con la capacidad y el rendimiento.

Es fundamental realizar un planeamiento completo y cuidadoso para asegurarse de que una granja de SharePoint se implementa correctamente y proporciona la funcionalidad esperada.

Los elementos siguientes son fundamentales para la planeación y el diseño de una granja:

  • Funciones y características: determine las funciones que desea que proporcione la granja e identifique las características necesarias para proporcionar esas funciones.

  • Servicios y aplicaciones de servicio: determine los servicios y las aplicaciones de servicio necesarios para las características que piensa utilizar.

  • Usuarios de la granja: determine cómo, con qué frecuencia y cuándo sus usuarios utilizarán las funciones que proporciona la granja.

  • Contenido de la granja: los tipos de contenido de la granja (por ejemplo, documentos, imágenes, vídeos, listas y artículos web) y el volumen (número de elementos y tamaño) determinan los requisitos de capacidad de la base de datos.

  • Uso previsto: el objetivo de implementar la granja o su uso previsto determinan el nivel de planeamiento y el tipo de diseño que se necesitan. Por ejemplo, una granja de evaluación de un producto, una granja para desarrolladores y una granja de pruebas previas a la producción tienen una base de usuarios diferente, distintos requisitos funcionales y diferentes requisitos de tamaño.

Los aspectos anteriores de planeamiento de una granja son los más obvios. Hay otros factores que también se deben tener en cuenta a la hora de planear una granja; por ejemplo, la seguridad, la alta disponibilidad y la escalabilidad. Para obtener más información, vea Planear en SharePoint 2013.

Después de identificar los requisitos de la granja, el paso siguiente consiste en diseñar la arquitectura de la granja. Esta arquitectura describe la organización lógica de todos los componentes que entregan las características y los servicios de la granja. Esta arquitectura lógica le permite crear una arquitectura física, o topología de granja, que identifica los elementos necesarios para implementar la arquitectura lógica. Una topología de granja de SharePoint identifica el número y la distribución de los servidores que se necesitan, y suele incluir información de tamaño de cada uno de los servidores. Para obtener más información, vea Planear arquitecturas lógicas para SharePoint 2013.

Puede instalar y configurar SharePoint en uno o varios servidores para admitir las características que piensa proporcionar en la granja de SharePoint. En cualquier granja determinada, el número de servidores que se utilizan y la capacidad de cada servidor varían. Hay muchos factores determinantes que afectan a la infraestructura de una granja de SharePoint. Por ejemplo, las funciones y características que la granja proporciona, el número de usuarios, y el volumen y el tipo de contenido que se almacena. Es preciso identificar y evaluar estos factores y otros muchos antes de calcular el tamaño, adquirir y aprovisionar servidores para la granja.

El diagrama de una topología de granja utiliza niveles, que no son más que una forma cómoda de organizar o categorizar servidores de la granja. La pertenencia a un nivel se basa en roles de servidor, que describen las características o los servicios que proporciona un servidor. Es importante tener en cuenta que los servidores de un nivel pueden hospedar los mismos servicios o subconjuntos del mismo servicio. Esto es bastante común en granjas de SharePoint muy grandes en las que la alta disponibilidad y el equilibrio de carga son objetivos de diseño. Salvo los servidores del nivel de base de datos, los servidores de los demás niveles tienen acoplamiento flexible. Esto significa que es relativamente fácil mover servidores entre distintos niveles para admitir picos de carga de trabajo o reemplazar un servidor que está produciendo errores.

Los niveles y los roles de servidor siguientes se utilizan para describir cada tipo de granja, como sitios de la intranet corporativa o sitios con conexión a Internet. Tenga en cuenta que el tamaño de una granja por sí mismo no es un factor determinante a la hora de decidir cuántos niveles hay que utilizar en una topología de granja. Sin embargo, en las granjas de SharePoint medianas y grandes suele haber tres niveles.

El rol de estos servidores, denominados normalmente servidores web front-end, es responder a solicitudes entrantes de contenido de los usuarios. Estos servidores enrutarán la solicitud a otro servidor o proporcionarán el contenido. En la mayoría de los casos, los servidores del nivel web tienen configuraciones idénticas o muy similares para que sean intercambiables y se puedan cambiar fácilmente dentro o fuera del nivel. Como los servidores del nivel web suelen tener equilibrio de carga y no ejecutan muchos servicios de SharePoint, no necesitan grandes cantidades de memoria o almacenamiento local.

Los servidores de este nivel ejecutan los servicios, las aplicaciones de servicio y los trabajos que admiten características de SharePoint. Un servidor de aplicaciones puede estar dedicado a hospedar un único servicio, admitir un subconjunto de una característica u hospedar más de un servicio. Según los requisitos de la granja, se pueden utilizar varios servidores de aplicaciones con equilibrio de carga para distribuir las cargas de trabajo y proporcionar alta disponibilidad.

Los servidores den este nivel, que se denomina a veces el nivel de base de datos back-end, están dedicados a hospedar la instancia del servidor de bases de datos que controla todos los aspectos del contenido de la granja de SharePoint, los datos de configuración de la granja y las bases de datos de aplicación de servicio.

SharePoint 2013 no admite el uso de una base de datos SQL de Azure como sustituto de un equipo servidor que ejecute SQL Server.

noteNota
Hay casos en los que las organizaciones comparten el servidor de bases de datos con más de una aplicación que usa SQL Server. Como esto puede ocasionar problemas importantes de rendimiento y capacidad, se recomienda usar un servidor de bases de datos dedicado a SharePoint.

Los ejemplos siguientes muestran cómo se puede implementar SharePoint en uno o más servidores usando topologías por niveles y roles de servidor para implementar un diseño de granja de servidores que satisfaga determinados objetivos.

Hay escenarios en los que tiene sentido instalar SharePoint en un solo servidor. Una granja de un solo servidor se utiliza normalmente para mostrar SharePoint, realizar una evaluación rápida de características de SharePoint o comparar SharePoint 2013 con sus versiones anteriores.

En una granja de dos niveles que se muestra en la Figura 1, el servidor de bases de datos se instala en un servidor y todos los demás roles se instalan en el segundo servidor. Este nivel de separación es el mínimo que se recomienda para implementar SharePoint en Azure. Esta topología resulta adecuada para la evaluación, el desarrollo y las pruebas detalladas de productos o para entornos de producción limitados que tienen un número reducido de usuarios (como una implementación piloto de SharePoint) y no necesitan alta disponibilidad.

Figura 1: granja de SharePoint de dos niveles

La topología de tres niveles que se muestra en la figura 2 siguiente consta de dos servidores web front-end, un servidor de aplicaciones y un servidor de bases de datos. Este modelo proporciona la base para implementar una granja que se puede escalar como respuesta a una mayor demanda de carga de trabajo o a una base de usuarios mayor.

Figura 2: granja multiservidor con dos servidores web, un servidor de aplicaciones y un servidor de bases de datos

También proporciona el marco para usar servidores redundantes con el fin de aumentar la capacidad y la disponibilidad de la granja, que se muestra en la Figura 3. Para proporcionar un servicio de alta disponibilidad, necesitará al menos dos servidores en cada nivel o para cada rol dentro de un nivel.

Ilustración 3: granja multiservidor con alta disponibilidad

Las granjas de SharePoint grandes, con mucha demanda, que admiten un gran número de usuarios simultáneos y un gran número de elementos de contenido utilizan la agrupación de servicios como parte de su estrategia de escalabilidad. Este enfoque implica ejecutar servicios en servidores dedicados, agrupando estos servicios y escalando horizontalmente después los servidores como un grupo. En la figura 4 se muestra un modelo de agrupación de servicios y servidores en una granja de tres niveles.

Figura 4: granja multiservidor grande con varios grupos de servidores

El tamaño se utiliza junto con las topologías para describir la arquitectura física de una granja. Las granjas de SharePoint se clasifican en pequeñas, medianas y grandes.

Una granja de servidores pequeña consta de lo siguiente:

  1. Dos servidores web

  2. Un servidor de bases de datos

Uno de los servidores web hospeda el sitio y los servicios de Administración central, y el otro se encarga de tareas adicionales, como las solicitudes de contenido de clientes entrantes. Esta granja se puede escalar horizontal hasta tres niveles mediante un servidor de aplicaciones dedicado. Vea la Figura 2 para obtener un ejemplo.

Una granja de servidores mediana normalmente dispone de lo siguiente:

  1. Dos o más servidores web

  2. Dos servidores de aplicaciones

  3. Al menos dos servidores de bases de datos

Vea la Figura 3 para obtener un ejemplo.

Una granja de servidores grande es el resultado de escalar una granja mediana para satisfacer los requisitos de capacidad y de rendimiento o con el fin de preparar la implementación de una solución de SharePoint 2013. Una topología de tres niveles suele utilizar servidores dedicados en cada nivel y los servidores se agrupan de acuerdo con su rol.

Vea la Figura 4 para obtener un ejemplo.

SharePoint Server está diseñado para admitir granularidad de los servicios y las aplicaciones de servicio, lo que significa que puede configurar una característica para que ejecute sus servicios o aplicaciones de servicio auxiliares en servidores individuales de un nivel o de niveles diferentes. Este enfoque de diseño proporciona un alto grado de flexibilidad para escalar una granja y se puede aplicar a todos los niveles.

Escalar verticalmente servidores de una granja o escalar horizontalmente una granja agregando servidores son alternativas aceptables para una granja de SharePoint Server. Además, los dos métodos de escalado pueden aplicarse a servidores físicos o a máquinas virtuales. La decisión de escalar una granja vertical u horizontalmente, como el diseño de la topología de una granja, depende de varios factores.

El costo, la flexibilidad y la velocidad de aprovisionamiento son los factores determinantes principales a la hora de tomar decisiones de escala cuando los servidores físicos, los periféricos y las redes proporcionan la infraestructura. Es más rápido y menos costoso actualizar hardware que agregar hardware.

Sin embargo, con Azure es más eficaz escalar agregando máquinas virtuales a la granja. El aprovisionamiento de nuevos servidores es más rápido, lo que permite una respuesta más rápida para los picos de demanda.

El escalado también proporciona dos otras ventajas importantes: mayor disponibilidad y menor tiempo de inactividad (planeado o sin planear). Desde la perspectiva de la alta disponibilidad, la flexibilidad y el costo de la virtualización permiten generar redundancia de servidores y servicios en el diseño de la granja de SharePoint. Esta redundancia puede reducir o eliminar dominios de error. La posibilidad de agregar rápidamente servidores adicionales a cualquiera de los niveles de la granja también reduce el tiempo de inactividad que supone realizar actualizaciones de software al sistema operativo, SQL Server o SharePoint.

Azure admite la implementación de granjas de SharePoint 2013 con máquinas virtuales y redes virtuales.

Azure le permite crear una máquina virtual que ejecute Windows Server u otros sistemas operativos. Después de crear una máquina virtual en Azure, puede acceder a ella como a cualquier otro servidor y eliminarla o crearla de nuevo siempre que lo necesite. Puede utilizar una máquina virtual en Azure para implementar un servidor basado en Windows Server 2012 R2.

Las máquinas virtuales de Azure se generan a partir de discos duros virtuales (VHD). Estos VHD son iguales que los VHD que utiliza Hyper-V y se pueden transferir hacia y desde el entorno existente. Azure también permite crear varias máquinas virtuales y equilibrar la carga del tráfico desde Internet entre ellas.

Azure proporciona combinaciones específicas de núcleos y memoria de CPU conocidos como tamaños de máquina virtual. Al crear una máquina virtual hay que seleccionar un tamaño específico. Este tamaño se puede cambiar después de la implementación. Los tamaños disponibles para las máquinas virtuales son los siguientes:

  • Extra pequeña (núcleo compartido, 768 MB de memoria)

  • Pequeña (1 núcleo, 1,75 GB de memoria)

  • Mediana (2 núcleos, 3,5 GB de memoria)

  • Grande (4 núcleos, 7 GB de memoria)

  • Extra grande (8 núcleos, 14 GB de memoria)

  • A6 (4 núcleos, 28 GB de memoria)

  • A7 (8 núcleos, 56 GB de memoria)

Las máquinas virtuales de Azure se crean a partir de una imagen o un disco. Todas las máquinas virtuales utilizan un disco del sistema operativo, un disco local temporal y posiblemente varios discos de datos. Todas las imágenes y los discos, excepto el disco local temporal, se crean a partir de archivos VHD almacenados como blobs de páginas en una cuenta de almacenamiento de Azure. Puede utilizar las imágenes de la plataforma que están disponibles en Azure para crear máquinas virtuales o puede cargar sus propias imágenes. Los discos que se crean a partir de imágenes también se almacenan en el almacenamiento de Azure. Puede crear fácilmente nuevas máquinas virtuales a partir de discos existentes.

Un archivo de VHD se almacena como un blob de página en almacenamiento de Azure y se puede utilizar para crear imágenes, discos del sistema operativo o discos de datos en Azure. Puede cargar un archivo de VHD en Azure y administrarlo igual que cualquier otro blob de página. Los archivos VHD se pueden copiar o mover, y se pueden eliminar siempre y cuando ningún disco haga referencia a ellos. Un archivo VHD se almacena como un blob de página en el almacenamiento de Azure y se puede utilizar para crear imágenes, discos del sistema operativo o discos de datos. Puede cargar un archivo de VHD en Azure y administrarlo igual que cualquier otro blob de página. Los archivos VHD se pueden copiar o mover, y se pueden eliminar siempre y cuando ningún disco haga referencia a ellos. Para obtener más información sobre los blobs en páginas, vea Descripción de los blobs en bloques y los blobs en páginas.

Un VHD puede tener un formato fijo o un formato dinámico, pero en Azure solo se admite el formato fijo para los archivos VHD. El formato fijo coloca el disco lógico linealmente en el archivo, de forma que el desplazamiento X del disco está almacenado en el desplazamiento X del blob. Al final del blob, hay un pequeño pie de página que describe las propiedades del disco duro virtual. El formato fijo suele desperdiciar espacio porque la mayoría de los discos tienen intervalos grandes sin utilizar. Sin embargo, en Azure, los archivos VHD fijos se almacenan en un formato disperso, lo que le permite disfrutar al mismo tiempo de las ventajas de los discos fijos y los discos dinámicos; esto incluye que solo se le facturan los bits que utiliza realmente. Para obtener más información sobre VHDs, vea Introducción a los discos duros virtuales.

Una imagen es un archivo VHD que se puede utilizar como plantilla para crear una nueva máquina virtual. Una imagen es una plantilla porque no tiene una configuración específica como una máquina virtual configurada, como el nombre de equipo y la configuración de la cuenta de usuario. Son como imágenes preparadas con la herramienta SysPrep. Puede utilizar Imágenes de la plataforma de la Galería de imágenes que proporciona Microsoft para crear máquinas virtuales o puede crear sus propias imágenes.

Todas las imágenes de Windows de la galería tienen ahora un tamaño de disco del sistema operativo de 127 GB. También hay varias imágenes de la galería que puede utilizar para generar granjas de SharePoint 2013, incluidas varias imágenes de SQL Server 2012. La imagen de evaluación de SharePoint 2013 tiene instalado SharePoint Server 2013; sin embargo, el asistente de configuración de tecnologías y productos de SharePoint no se ha ejecutado.

En la Figura 5 se muestra un ejemplo de la lista de imágenes que proporciona Azure.

Figura 5: ejemplo de la galería de imágenes de Azure.

La licencia de evaluación de SharePoint 2013 se puede actualizar a una versión con licencia completa. Para convertir un tipo de licencia y escribir la clave del producto, haga lo siguiente:

  1. Compruebe que ha iniciado sesión al servidor de SharePoint como miembro del grupo de Administradores de la granja de servidores de SharePoint en el equipo que ejecuta Administración central.

  2. En el sitio web de Administración central, en la sección Actualización y migración, haga clic en Convertir tipo de licencia de granja de servidores.

  3. En la página Convertir el tipo de licencia, en el cuadro Escribir la clave del producto, escriba su clave de producto de SharePoint 2013 y haga clic en Aceptar.

En Azure, los discos se utilizan de varias maneras con una máquina virtual. Un disco del sistema operativo es un disco duro virtual que se utiliza para proporcionar un sistema operativo para una máquina virtual. Un disco de datos es un disco duro virtual que se asocia a una máquina virtual para almacenar los datos de las aplicaciones. Puede crear y eliminar discos según lo desee.

Los discos se pueden crear de varias formas en función de las necesidades de la aplicación. Por ejemplo, una forma habitual de crear un disco del sistema operativo es utilizar una imagen de la Galería de imágenes para crear una máquina virtual: se crea automáticamente un disco del sistema operativo. Puede crear un disco de datos si conecta un disco vacío a una máquina virtual: se crea automáticamente un disco de datos. También puede crear un disco mediante un archivo VHD que se ha cargado o copiado en una cuenta de almacenamiento de la suscripción. No puede utilizar el portal para cargar archivos VHD, pero puede utilizar otras herramientas que funcionen con el almacenamiento de Azure para cargar o copiar el archivo, incluidos los comandos de Azure PowerShell. Para obtener más información, vea Los cmdlets de Azure PowerShell ahora admiten almacenamiento.

Un disco de datos es un disco duro virtual que se puede conectar a una máquina virtual en ejecución para almacenar los datos de las aplicaciones de forma permanente. Puede cargar y asociar a la máquina virtual un disco de datos que ya contiene datos, o puede utilizar el Portal de administración de Azure para asociar un disco vacío a la máquina. El tamaño máximo de un disco de datos es 1 TB y hay una limitación en cuanto al número de discos que puede conectar a una máquina virtual según el tamaño de la máquina. Los discos de datos se registran como unidades SCSI y puede hacer que estén disponibles para su uso dentro de Windows con el Administrador del servidor o el complemento de administración de discos. En la siguiente tabla se muestra el número de discos conectados permitido para cada tamaño de máquina virtual.

 

Tamaño Número máximo de discos conectados

Extra pequeña

1

Pequeña

2

Mediana

4

Grande

8

Extra grande

16

A6

8

A7

16

Cada máquina virtual que se crea tiene un disco local temporal que se etiqueta como la unidad D:. Este disco lo utilizan las aplicaciones y los procesos que se ejecutan en la máquina virtual para el almacenamiento transitorio y temporal de los datos. También se utiliza para almacenar los archivos de paginación del sistema operativo. Tenga en cuenta que esta letra de unidad no se puede cambiar y que los datos de la unidad D: no sobrevivirán a un error del equipo o a ninguna otra operación que requiera mover la máquina virtual a otro elemento de hardware.

El disco del sistema operativo y el disco de datos disponen de un almacenamiento en caché de host (que en ocasiones se denomina modo caché de host) que puede mejorar el rendimiento en algunas circunstancias. Sin embargo, esta configuración puede afectar negativamente al rendimiento en otras circunstancias, en función de la aplicación. Tenga en cuenta la configuración predeterminada:

  1. En los discos de datos, el almacenamiento en caché de host está desactivado tanto para las operaciones de lectura como de escritura.

  2. En los discos de sistemas operativos, el almacenamiento en caché de host está activado tanto para las operaciones de lectura como de escritura.

Puede acceder a nuevas máquinas virtuales por Internet mediante el Protocolo de escritorio remoto (RDP) y con sesiones de Windows PowerShell remotas. De forma predeterminada, Azure agrega asignaciones de entrada, conocidas como extremos, para los dos tipos de tráfico cuando crea la máquina virtual. Estos extremos permiten el RDP de entrada y las sesiones de Windows PowerShell remoto con las credenciales de usuario correspondientes.

Una red virtual de Azure es un contenedor lógico que puede hospedar máquinas virtuales agrupadas en subredes. Las máquinas virtuales agrupadas en subredes de una red virtual pueden comunicarse directamente entre ellas, exactamente igual que en las subredes de intranet, sin que ese tráfico recorra Internet. Esto contrasta con las máquinas virtuales de Azure que no se encuentran en una red virtual y que no pueden comunicarse entre ellas sin que el tráfico recorra Internet.

Hay dos tipos de redes virtuales:

  1. Red virtual entre locales: una red virtual que se conecta a la red de su organización en Internet mediante una conexión VPN de sitio a sitio. Las máquinas virtuales en una red virtual entre locales actúan como una extensión de la red de su organización, lo que ofrece aplicaciones y servicios a los usuarios de la intranet, los usuarios de Internet o ambos.

  2. Red virtual solo en la nube: una red virtual que no está conectada a la red de su organización. Las máquinas virtuales de una red virtual que solo está en la nube ofrecen aplicaciones y servicios a los usuarios de Internet.

Con las redes virtuales entre locales, los administradores de TI pueden ampliar las redes locales en la nube ejerciendo control sobre la topología de subred y la configuración de las direcciones IP privadas y los servidores DNS de la máquina virtual.

Debe crear siempre una red virtual dentro de Azure antes de implementar nuevas máquinas virtuales. La creación de una red virtual le permitirá agrupar las máquinas virtuales y dividir y determinar los intervalos de las direcciones IP asignadas a sus máquinas virtuales.

Cuando crea una red virtual entre locales, define un único intervalo de dirección IPv4 privado a la red de su organización para usar en todas las subredes que contendrá la máquina virtual También define un intervalo de dirección IPv4 para cada subred. Cuando crea una máquina virtual y la agrega a una subred, Azure asignará una dirección del intervalo de dirección IPv4 para la subred mediante DHCP. El tiempo de la concesión DHCP se establece como mínimo en 100 años, siempre y cuando la configuración de la dirección sea muy estable.

Es importante tener en cuenta que Azure por sí mismo utiliza varias direcciones del intervalo de dirección IPv4 para cada subred. La primera máquina virtual que agrega a una subred normalmente tiene la cuarta dirección IP en el intervalo. Por ejemplo, para la subred con el intervalo de dirección 10.0.0.0/24 (o 10.0.0.0 con la máscara de subred 255.255.255.0), la dirección IP de su primera máquina virtual será 10.0.0.4.

Para conectar la máquina virtual entre locales en Azure a su red local, debe crear una conexión VPN de sitio a sitio. Un dispositivo de puerta de enlace VPN en el límite de su red local crea una conexión segura a una puerta de enlace VPN de Azure en el borde de su red virtual. Para asegurarse de que puede alcanzar las máquinas virtuales desde su red local, debe configurar su infraestructura de enrutamiento con rutas para el espacio de dirección de la red virtual para que apunten a su dispositivo de puerta de enlace VPN.

Las conexiones de sitio a sitio de Azure usan el protocolo de seguridad de Internet estándar del sector (IPsec) para proporcionar una conexión segura entre su dispositivo de puerta de enlace VPN y una puerta de enlace VPN de Azure en el límite de su red virtual de Azure. Puede controlar el acceso a la red con su dispositivo de seguridad local. También puede controlar el tráfico entre su centro de datos y las máquinas virtuales que se ejecutan en Azure con el firewall de Windows estándar basado en host que incluye Windows Server.

Para minimizar la latencia de llevar a cabo la autenticación de las credenciales de usuario de intranet para el acceso y la administración de los sitios y los recursos de las granjas de SharePoint, debe implementar los controladores de dominio Active Directory Domain Services (AD DS) en la red virtual. Por redundancia, debe implementar al menos dos.

Para obtener información adicional, vea Instrucciones para implementar Active Directory de Windows Server en máquinas virtuales de Azure.

noteNota
SharePoint 2013 requiere pertenecer al dominio AD DS correspondiente al servidor donde se ejecuta. No puede usar Azure Active Directory (AD) como sustituto de pertenencia al dominio AD DS del servidor SharePoint 2013. Sin embargo, puede usar Azure AD para fines de autenticación de los usuarios que acceden a los recursos de SharePoint. Para obtener más información, vea Azure Active Directory con SharePoint 2013.

Cuando define una red virtual entre locales, debe configurar Azure con direcciones IP de servidores DNS que están asignadas a máquinas virtuales con DHCP. Estos servidores DNS puede que existan en servidores DNS locales o servidores DNS que creará dentro de la red virtual. También puede hospedar servidores DNS en los controladores de dominio AD DS de la red virtual.

noteNota
No debe realizar cambios a las conexiones de red de máquinas virtuales de una red virtual de Azure, por ejemplo, para ajustar la configuración de DNS u otro comportamiento. Debe usar Azure para proporcionar la configuración de conexión de red, de lo contrario quizás no pueda tener acceso a su máquina virtual.

Cuando crea una red virtual, puede crear un grupo de afinidad o especificar uno creado anteriormente. Al crear recursos en Azure, como cuentas de almacenamiento, un grupo de afinidad indicará a Windows Azure que desea que estos recursos estén ubicados juntos en el mismo centro de datos regional de Azure. Una vez que tiene un grupo de afinidad, siempre debe especificarlo al crear recursos relacionados.

Cuando crea una máquina virtual, es totalmente accesible desde las demás máquinas virtuales de su red virtual. Se admiten todos los protocolos TCP/IP, como TCP, UDP y ICMP, en una red virtual sujeta a la configuración de los firewalls basados en host, como Windows Firewall en Windows Server 2012.

Si desea acceder a sus máquinas virtuales desde Internet o hacer accesibles los recursos de sus máquinas virtuales a los usuarios de Internet, debe usar el nombre externo o la dirección IP pública del servicio en la nube que contiene la máquina virtual y configurar extremos. Los extremos son similares a las reglas de asignación o de reenvío de firewall y puerto y se pueden configurar para máquinas virtuales individuales en el Portal de administración de Azure.

De forma predeterminada, Azure configura extremos tanto para el tráfico de RDP como PowerShell remoto. Estos extremos utilizan números de puertos aleatorios para los puertos públicos que se asignan a los números de puertos privados apropiados en las máquinas virtuales.

noteNota
Para evitar que usuarios malintencionados de Internet intenten acceder a sus máquinas virtuales mediante RDP o PowerShell remoto, puede quitar estos extremos preconfigurados para redes virtuales entre locales. El inconveniente es que solo puede administrar las máquinas virtuales desde la red local. Los administradores ubicados en Internet primero deben obtener una conexión a la red local, por ejemplo, con una conexión de acceso remoto.

Para permitir el tráfico de Internet a su granja de SharePoint, debe configurar extremos en las máquinas virtuales del servidor web. Por ejemplo, podría configurar un extremo para el puerto TCP 80 público que asigna a un puerto TCP 80 privado (para el tráfico web estándar), o al puerto TCP en el que escucha el servidor de SharePoint.

Si ha configurado su infraestructura de enrutamiento para incluir el espacio de dirección de su red virtual entre locales, puede acceder a las máquinas virtuales de su red virtual entre locales como accedería a cualquier otro equipo en la red de su organización.

Azure también le permite equilibrar la carga del tráfico de red a una dirección pública y a un número de puerto público específico en varias máquinas virtuales. En la Figura 6 se muestra un ejemplo con dos servidores web, en el que ambos escuchan el tráfico web de entrada en el puerto TCP 3456 privado, en una configuración conocida como extremo con equilibrio de carga. Azure distribuirá aleatoriamente el tráfico entre los nodos. Puede tener hasta 50 máquinas virtuales detrás de un único extremo con equilibrio de carga.

Figura 6: direcciones y puertos públicos y privados con extremos

En el ejemplo de la Figura 6, el equilibrador de carga de Azure equilibra el tráfico de Internet de entrada para la dirección IP pública del servicio en la nube y el puerto TCP 80 entre dos máquinas virtuales (10.2.0.4 y 10.2.0.5). En la Figura 6, la primera fila es un extremo con equilibrio de carga.

Para obtener un extremo con equilibrio de carga, Azure distribuye aleatoriamente el tráfico entre las máquinas virtuales configuradas. Puede tener hasta 50 máquinas virtuales para un extremo con equilibrio de carga. Al agregar máquinas virtuales a un extremo con equilibrio de carga debe crear también un conjunto de disponibilidad.

Tenga en cuenta que solo puede equilibrar la carga de tráfico desde Internet a través de un extremo, que esté asignado a una dirección IP pública del servicio en la nube que contiene la máquina virtual. Azure no equilibra la carga entre máquinas virtuales para las direcciones IP privadas y los números de puerto.

Por ejemplo, si su granja de SharePoint también se utiliza para acceder a la intranet, los usuarios de su red accederán a los servidores de la granja a través de sus direcciones IP privadas. Si necesita equilibrar la carga de intranet entre los servidores de la granja, debe implementar su propio equilibrador de carga.

En aquellas cargas de trabajo que se requiera alta disponibilidad, debe implementar más de una máquina virtual para cada rol determinado. Cuando se usan varias máquinas virtuales, puede asegurarse de que la aplicación está disponible durante los errores de alcance de red locales, los errores de hardware de los discos locales y cualquier tiempo de inactividad planeado que la plataforma pueda necesitar.

Para administrar la disponibilidad de la aplicación que utiliza varias máquinas virtuales, debe agregar las máquinas a un conjunto de disponibilidad. Los conjuntos de disponibilidad están relacionados directamente con los dominios de error y los dominios de actualización. Un dominio de error en Azure se define evitando puntos únicos de error, como el conmutador de red o la unidad de alimentación de un bastidor de servidores. De hecho, un dominio de error equivale aproximadamente a un bastidor de servidores físicos. Cuando varias máquinas virtuales están conectadas juntas en un servicio en la nube, se puede utilizar un conjunto de disponibilidad para asegurarse de que todas las máquinas del conjunto no están inactivas al mismo tiempo durante las operaciones de mantenimiento y reduce el riesgo de error en todo el conjunto.

En la Figura 7 se muestran servidores en conjuntos de disponibilidad que están en dominios de error independientes.

Figura 7: Dominios de error y conjuntos de disponibilidad

Azure actualiza periódicamente el sistema operativo de las máquinas virtuales que hospeda las instancias de una aplicación. Una máquina virtual se apaga cuando se aplica una actualización. Un dominio de actualización se utiliza para asegurarse de que no todas las instancias de máquina virtual se actualizan al mismo tiempo. Cuando asigna varias máquinas virtuales a un conjunto de disponibilidad, Azure garantiza que las máquinas se asignan a distintos dominios de actualización.

En la Figura 7 se muestran dos máquinas virtuales que ejecutan Internet Information Services (IIS) en dominios de actualización diferentes y dos máquinas virtuales que ejecutan SQL Server también en dominios de actualización diferentes.

ImportantImportante
El suscriptor de Azure es responsable de instalar las actualizaciones en los servidores de la granja de SharePoint. Para obtener más información, vea "Aplicación de revisión y actualización" en este tema.

Debe utilizar una combinación de conjuntos de disponibilidad y extremos de equilibrio de carga para asegurarse de que la aplicación está siempre disponible y se ejecuta de forma eficaz. Para obtener más información sobre cómo utilizar extremos con equilibrio de carga, vea Equilibrar carga de máquinas virtuales.

El escalado horizontal es un principio fundamental básico de la infraestructura de Azure. Al planear una granja de SharePoint que se hospeda en Azure, diseñe la topología de la granja desde la perspectiva de usar varios servidores con menor capacidad en lugar de menos servidores con alta capacidad.

Utilizar una granja de SharePoint que se ejecuta en Azure no es distinto que utilizar una granja de SharePoint en cualquier otra parte. A pesar de la eficacia y la agilidad que le ofrece Azure, al final sigue teniendo que administrar Windows Server, SharePoint y sus dependencias. En los servidores locales puede utilizar una combinación de herramientas de administración de Windows Server y SharePoint, o puede administrar toda la granja mediante System Center. Se pueden utilizar las mismas herramientas y los mismos procedimientos cuando la granja se hospeda en una red virtual entre entornos de Azure.

Para obtener más información, vea Planear la supervisión en SharePoint 2013.

Sigue siendo responsable de aplicar revisiones al SO y sigue teniendo un control total sobre cómo y cuándo se deben aplicar. La aplicación de revisiones y actualizaciones a una granja de SharePoint 2013 puede variar bastante en función de la topología. Para obtener más información, vea Información general de las actualizaciones de software de SharePoint 2013.

Un área en la que Azure puede ser útil es a la hora de probar actualizaciones importantes. Puesto que puede crear recursos a petición, puede crear un entorno duplicado dentro de Azure y probar su estrategia y metodología de actualizaciones o de aplicación de revisiones antes de actualizar su entorno de producción.

La copia de seguridad y la recuperación de granjas de SharePoint en Azure es muy similar a una granja de SharePoint local. Hay que tener en cuenta que no debe sufrir ningún tiempo de inactividad significativo debido a un error de hardware. Puesto que Azure reparará y volverá a implementar automáticamente la máquina virtual, no tiene que realizar ninguna acción. Obtendrá tiempo de inactividad de hardware que se reparará automáticamente. Asegúrese de que las personalizaciones que realice o las aplicaciones que implemente pueden controlar esta recuperación automática. Azure simplifica considerablemente la implementación de más máquinas virtuales, lo que permite crear una granja con una disponibilidad muy alta.

Aunque puede usar la imagen de evaluación de SharePoint 2013 proporcionada por Microsoft en la galería de imágenes de la máquina virtual de Azure para sus servidores de SharePoint, también puede crear su propia imagen. Puede que desee hacerlo si tiene requisitos diferentes o si desea precargar otro software, como aplicaciones de SharePoint o software antimalware.

Azure permite crear imágenes Gold creando una imagen de disco a partir de un VHD existente. Esta imagen de disco contiene el sistema operativo y todas las personalizaciones que puede necesitar, como la instalación de software y la configuración de Windows personalizada. Esta imagen de disco se puede utilizar para crear nuevas máquinas virtuales de Azure. El uso de una imagen de disco significa que puede crear rápidamente varias copias del mismo servidor.

Para crear una imagen Gold, necesita una máquina virtual en la que se basará la imagen. Esta máquina virtual es simplemente una máquina virtual estándar de Azure que se ha personalizado. Para crear una imagen base con SharePoint 2013 instalado, se recomienda que no complete toda la instalación de SharePoint 2013. Esto se debe a las incompatibilidades con la herramienta SYSPREP, que es un paso necesario para preparar la imagen de disco.

A continuación se resumen los pasos a seguir para crear la imagen:

  1. Cree una nueva máquina virtual basada en la imagen del centro de datos de Windows Server 2012 R2 de la galería.

  2. Cree una conexión a escritorio remoto al nuevo servidor.

  3. En el nuevo servidor, descargue los archivos de instalación de SharePoint 2013.

  4. Instale los requisitos previos de SharePoint 2013.

  5. Ejecute la instalación de software de SharePoint 2013 pero no complete el asistente para la configuración de tecnologías y productos de SharePoint. Debe instalar SharePoint en la unidad del sistema operativo para que las unidades de datos no se capturen como parte del proceso SysPrep.

  6. Instale y configure todas las personalizaciones, incluidas las aplicaciones de SharePoint y el software antimalware.

  7. Ejecute SysPrep y apague la máquina virtual.

  8. Desde el Portal de administración de Azure, haga clic en Máquinas virtuales en el panel de navegación, luego en En ejecución en la columna de Estado de la máquina virtual y, a continuación, seleccione Capturar para ejecutar el asistente. Ahora puede usar esta imagen como plantilla para las nuevas máquinas virtuales.

Para obtener más información sobre cómo capturar una imagen, vea Cómo capturar una imagen de una máquina virtual que ejecuta Windows Server

Muchas de las operaciones que realiza en máquinas virtuales o en redes virtuales en Azure se pueden automatizar mediante PowerShell. Para obtener información, vea Azure PowerShell y Ejemplos para Azure PowerShell.

Para obtener las instrucciones detalladas para configurar SharePoint con SQL Server AlwaysOn en Azure con ocho máquinas virtuales, vea Implementar SharePoint con SQL Server AlwaysOn en Azure.

Para obtener más información sobre SharePoint 2013, vea los recursos siguientes:

Mostrar:
© 2014 Microsoft