Projetando um farm do SharePoint Server no Azure
APLICA-SE A:
2013 
2016 2019 Subscription Edition SharePoint no Microsoft 365
Este artigo fornece uma descrição geral do suporte para farms do SharePoint Server nos serviços de infraestrutura do Azure e um processo passo a passo e recomendações e melhores práticas para conceber o ambiente do Azure, incluindo recursos de rede, armazenamento e computação.
Farms do SharePoint Server nos serviços de infraestrutura do Azure
A execução de farms do SharePoint Server em qualquer ambiente de Infraestrutura como Serviço (IaaS) pode tirar partido do seguinte:
Capacidade sob demanda e a capacidade de escala de máquinas virtuais (elasticidade)
Terceirização parcial
Outros locais com investimento mínimo
Redução de custo
Aqui estão as situações nas quais os farms do SharePoint devem ser executados de um ambiente IaaS:
Farm de desenvolvimento/teste, piloto ou prova de conceito
Infraestrutura híbrida
Recuperação de desastres
Farm de produção
Suporte do SharePoint Server no Azure
A Microsoft suporta os seguintes cenários de implementação do SharePoint Server em máquinas virtuais IaaS (VMs) do Azure:
Farms que não são de produção, como os usados para ambientes de desenvolvimento e teste ou prova de conceito
Como um destino de recuperação após desastre através do envio de registos, grupos de disponibilidade AlwaysOn do SQL Server ou Azure Site Recovery
Farms de produção, que usam o armazenamento premium do Azure para servidores que executam a função de pesquisa
Também há suporte para farms de produção que executam o SharePoint 2013. O SharePoint 2010 não está mais no suporte básico, entretanto, ele pode ser instalado em VMs do Azure para teste e validação de cenários de migração.
Assim como ocorre com outras cargas de trabalho da Microsoft, o licenciamento é gerenciado pela Mobilidade de Licenciamento por meio do Software Assurance. Para obter mais informações, veja Licenciamento de produtos de servidor microsoft para utilização em ambientes virtuais.
O processo de conceção para farms do SharePoint Server no Azure
O ambiente de serviços de infraestrutura do Azure é diferente dos centros de dados locais e exige planejamento adicional. O processo de design a seguir percorre as etapas para determinar os seguintes elementos da infraestrutura Azure:
Grupos de recursos
Conectividade
Armazenamento
Identidade
Segurança
Máquinas virtuais
Cada passo inclui melhores práticas e recomendações específicas para os requisitos dos farms do SharePoint Server.
No final do processo de conceção, terá determinado o conjunto de componentes nos serviços de infraestrutura do Azure que estão prontos para o farm do SharePoint Server.
Dica
Esse processo baseia-se em Projetar serviços de infraestrutura do Azure para hospedar um aplicativo de LOB de várias camadas.
Etapa 1: Grupos de recursos
Os grupos de recursos são contêineres para vários elementos do Azure que podem ser gerenciados em conjunto. Por exemplo, você pode criar listas de controle de acesso que permitem que somente as contas de usuários específicos modifiquem o conjunto de elementos em um grupo de recursos.
Pode colocar todos os recursos do farm do SharePoint Server no mesmo grupo de recursos, mas isto é altamente desencorajado para implementações de produção. Em vez disso, a recomendação é usar grupos de recursos diferentes para:
Componentes de infraestrutura e rede
Por exemplo, um grupo de recursos chamado Networking_RG que contém a rede virtual (VNet), os grupos de segurança de rede e os balanceadores de carga.
As funções separadas do farm do SharePoint
Por exemplo, utilize grupos de recursos separados para o front-end, pesquisa, aplicação, cache distribuída, dados e funções combinadas de um farm típico do SharePoint Server. Em cada grupo de recursos separado, coloque os conjuntos de disponibilidade, as interfaces de rede e as máquinas virtuais dessa função.
Para seus grupos de recursos, preencha a tabela a seguir antes de criá-los, usando quantas linhas forem necessárias.
| Nome do grupo de recursos | Local do Azure (região) |
|---|---|
Etapa 2: Conectividade
A conectividade inclui:
Acesso aos servidores em execução no farm do SharePoint Server, tanto para administração como para os recursos do farm, a partir da intranet e da Internet.
Acesso para os servidores do farm entre si, para a intranet e para a Internet.
Os elementos de conectividade incluem redes virtuais (VNets), sub-redes dentro das VNets, sistema de nomes de domínio (DNS) para o registro de nome e resolução, distribuição de tráfego e endereçamento para máquinas virtuais.
VNets
O contêiner necessário para máquinas virtuais em serviços de infraestrutura do Azure é o Azure VNet. Existem dois tipos de VNets:
Apenas Nuvem
Não tem conexão com uma rede local. Use esse tipo de VNet quando você estiver implantando um farm do SharePoint voltado para a Internet que usa uma floresta autônoma do Windows Server Active Directory (AD).
Entre locais
Tem uma conexão com uma rede local e deve ser atribuído um espaço de endereço exclusivo da sua intranet. Use esse tipo de VNet quando você estiver implantando um farm do SharePoint baseado em intranet que usa uma floresta local do Windows Server AD.
Embora seja possível colocar as VMs de uma função de servidor de um farm do SharePoint em VNets diferentes, isso não é recomendado porque o tráfego de rede entre VMs precisaria percorrer uma conexão de VNet para VNet ou de emparelhamento de VNet. A recomendação é colocar todos os servidores de um farm em uma única VNet.
Quando você cria a VNet, deve atribuir um espaço de endereço a ela, que pode consistir em um ou vários blocos de roteamento entre domínios (CIDR) (também conhecido como prefixos de rede). Isso é semelhante a atribuir um espaço de endereço a um novo datacenter que conterá várias sub-redes e cargas de trabalho de TI. O espaço de endereço que você escolher depende do tipo de VNet:
Apenas Nuvem
Pode ter qualquer espaço de endereço do espaço de endereço particular IPv4 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), se não sobrepuser os espaços de endereço de outras VNets interconectadas.
Entre locais
Deve ser um espaço de endereço exclusivo e sem sobreposição do seu espaço de endereço de intranet, que pode incluir espaços de endereço públicos e privados.
Para sua VNet, preencha a tabela a seguir.
| Nome da VNet | Tipo de VNet | Nome do grupo de recursos | Espaço de endereçamento |
|---|---|---|---|
Coloque a VNet no grupo de recursos para componentes de infraestrutura ou rede.
Observe que você pode usar uma VNet existente que hospeda cargas de trabalho de TI nas máquinas virtuais no Azure ou você pode criar uma nova VNet.
Sub-redes
Assim como as sub-redes em seu datacenter, as sub-redes de uma VNet do Azure são divisões lógicas do espaço de endereço IPv4 para nós de rede de grupo e separados e seu tráfego. O Azure dá suporte a três tipos de sub-redes:
Hospedagem de VMs (obrigatório)
Hospeda as VMs de uma carga de trabalho de TI. Um exemplo são todos os servidores que executam o serviço de cache distribuída de um farm do SharePoint Server.
Gateway
Hospeda os gateways do Azure para uma conexão VPN de VNet para VNet ou entre locais. Esta sub-rede deve ser chamada de "GatewaySubnet".
Gerenciamento (recomendado)
Hospeda duas ou mais VMs que fornecem conexões da área de trabalho remota para os servidores na VNet e em funções de gerenciamento de rede de suporte.
Assim como os datacenters no local, a recomendação no Azure é usar uma sub-rede de hospedagem de VMs separada para cada conjunto ou VMs que fornecem a mesma função de servidor para seu farm. Com sub-redes separadas, você pode usar grupos de segurança de rede do Azure para definir o tráfego de entrada e saída permitido e realizar o isolamento de sub-rede.
O espaço de endereço para cada sub-rede deve ser uma parte do espaço de endereço VNet expresso como um único bloco CIDR, também conhecido como prefixo de rede. Escolha espaço de endereço suficiente para acomodar o conjunto de servidores projetado que executa essa função de servidor comum.
| Número de servidores | Comprimento do prefixo de rede |
|---|---|
| 1 a 3 |
/29 |
| 4 a 11 |
/28 |
| 12 a 27 |
/27 |
| 18 a 59 |
/26 |
A recomendação para o GatewaySubnet é usar um comprimento de prefixo de rede /27 e atribuí-lo na última parte do espaço de endereço VNet. Para saber mais, confira Calcular o espaço de endereço da sub-rede do gateway para as redes virtuais do Azure.
Para as sub-redes de sua VNet, preencha a tabela a seguir antes de criá-los, usando quantas linhas forem necessárias.
| Nome da sub-rede | Espaço de endereçamento |
|---|---|
| GatewaySubnet (se necessário) | |
DNS
Todas as VMs em um VNet do Azure por padrão são atribuídas a um conjunto de servidores DNS para executar o registro e a resolução de nome. Você pode substituir isso ao atribuir servidores DNS a interfaces de rede de VMs individuais.
Para um farm do SharePoint Server no Azure que utiliza o Microsoft Entra Domain Services, atribua os endereços IP do serviço como servidores DNS.
Para um farm do SharePoint Server no Azure que contém um conjunto de controladores de domínio do Windows Server AD que também funcionam como servidores DNS, atribua os endereços IP dos controladores de domínio como servidores DNS. Para uma VNet entre locais, são necessários dois conjuntos de servidores DNS:
Um conjunto de servidores DNS na rede local que suas VMs do controlador de domínio usam ao ingressarem no domínio e são promovidas a controladores de domínio.
Depois que as VMs tiverem se tornado servidores DNS, redefina os servidores DNS para os endereços IP dos controladores de domínio.
Para os endereços IP do servidor DNS atribuir ao seu VNet, preencha a tabela a seguir usando quantas linhas forem necessárias.
| Endereços IP do servidor DNS |
|---|
Distribuição de tráfego
Os farms do SharePoint de produção típica usam balanceadores de carga para distribuir tráfego entre os servidores de uma função comum. Os serviços de infraestrutura do Azure incluem um balanceador de carga interno que pode ser usado das seguintes maneiras:
Voltado para a Internet: Usado em conjunto com um endereço IP público para distribuir tráfego da Internet para os membros da máquina virtual de um conjunto de carga balanceada.
Interno: Usado junto com um endereço IP de uma sub-rede na VNet para distribuir tráfego da Internet para os membros da máquina virtual de um conjunto de carga balanceada.
Aqui estão as recomendações para usar balanceadores de carga do Azure em seu farm do SharePoint Server 2016 no Azure:
Use o balanceador de carga do Azure ou um aparelho de rede de balanceador de carga para os servidores de front-end. Se o farm do SharePoint tiver sido criado para ser acessível a partir da Internet, use um balanceador de carga voltado para a Internet.
Use um balanceador de carga interno do Azure ou um aparelho de rede de balanceador de carga para o conjunto de servidores que executam aplicativos e para o cluster do servidor do SQL (usando o endereço IP ouvinte).
Crie os balanceadores de carga do Azure ou carregue aparelhos de rede de balanceadores de carga no grupo de recursos de infraestrutura ou rede.
Aumente o tempo limite de conexão ociosa para lidar com conexões de longa duração de clientes do SharePoint com o comando do Azure PowerShell AzureLoadBalancedEndpoint conjunto - IdleTimeoutInMinutes 15.
O teste de integridade de máquina virtual pode ser um HTTP get message ou ICMP Echo Request (ping) message, a menos que o aparelho de rede de balanceamento de carga esteja funcionando na camada 4 e, nesse caso, um HTTP get message deve ser usado.
Para os balanceadores de carga do Azure, preencha a tabela a seguir antes de criá-los, usando quantas linhas forem necessárias.
| Nome do balanceador de carga | Objetivo | Tipo (voltado para a Internet ou interno) |
|---|---|---|
Endereços estáticos
Você pode atribuir endereços IP estáticos a interfaces de rede de máquina virtual do espaço de endereço de sub-rede disponível. Se você estiver usando um balanceador de carga interno do Azure para distribuir tráfego entre os servidores de uma função comum, atribua o balanceador de carga a um endereço IP estático da sub-rede que contém os membros do conjunto de carga balanceada.
Para um farm do SharePoint Server no Azure, a Microsoft recomenda que atribua um endereço IP estático para cada servidor que execute o SQL Server ou o SharePoint Server.
Para endereços IP estáticos, preencha a tabela a seguir, usando quantas linhas forem necessárias.
| Nome da VM ou do balanceador de carga | Endereço IP estático |
|---|---|
Endereços IP públicos
Um endereço IP público permite acesso a um balanceador de carga ou máquina virtual da Internet. Para reduzir a área de superfície de ataques, a Microsoft recomenda que você use endereços IP públicos apenas para o seguinte:
Para VMs de jumpbox em uma rede somente na nuvem.
Uma VM de jumpbox é uma máquina virtual a partir da qual você inicia conexões da área de trabalho remota para gerenciar remotamente outras VMs na VNet. Você não precisará de endereços IP públicos para cada máquina virtual.
Para um balanceador de carga voltado para a Internet para farms voltados externamente.
O endereço IP público fornece acesso aos servidores na função de front-end do farm.
Para endereços IP públicos, preencha a tabela a seguir, usando quantas linhas forem necessárias.
| Nome da VM ou do balanceador de carga |
|---|
O Azure atribui endereços IP públicos no momento em que são solicitados para a VM ou balanceador de carga.
Etapa 3: Armazenamento
Os recursos de armazenamento para VMs no Azure, que incluem os discos que cada máquina virtual usa, são discos gerenciados.
O Azure dá suporte a tipos padrão e premium de armazenamento. Para estar numa configuração suportada, tem de utilizar o armazenamento premium para os servidores que executam o SharePoint Server que alojam a função de pesquisa. A Microsoft recomenda que utilize o armazenamento premium para todas as VMs com o SQL Server ou o SharePoint Servers. Outras VMs do farm, como controladores de domínio e VMs na sub-rede de gerenciamento, podem usar o armazenamento padrão.
Etapa 4: Identidade
O SharePoint Server requer a associação a um domínio do Windows Server AD. Por conseguinte, um farm do SharePoint Server no Azure tem de ter acesso a um domínio do Windows Server AD com VMs a funcionar como controladores de domínio ou com o Microsoft Entra Domain Services.
Ao usar VMs atuando como controladores de domínio:
Para um farm somente para Internet em uma VNet somente na nuvem, crie uma floresta autônoma do Windows Server AD com pelo menos duas VMs para disponibilidade.
Para um farm de intranet em uma VNet entre locais, você pode usar controladores de domínio no local. No entanto, a Microsoft recomenda usar pelo menos dois controladores de domínio de réplica para floresta local do Windows Server AD na VNet que contém o farm do SharePoint.
Etapa 5: Segurança
Use os seguintes elementos do Azure para fornecer segurança para os servidores do farm do SharePoint:
Para VNets somente na nuvem, use uma máquina virtual jumpbox para conexões da área de trabalho remota e atribua o único endereço IP público para a VM do jumpbox. As VMs do jumpbox são opcionais para VNets entre locais porque as VMs do farm do SharePoint podem ser alcançadas diretamente da intranet.
Use grupos de segurança de rede baseados em sub-rede para isolamento de sub-redes. Os grupos de segurança de rede e as regras que definem o tráfego permitido de e para a sub-rede. Coloque os grupos de segurança de rede no grupo de recursos para componentes de infraestrutura ou rede.
Para seus grupos de segurança de rede, preencha a tabela a seguir antes de criá-los, usando quantas linhas forem necessárias.
| Nome do grupo de segurança de rede | Nome da sub-rede | Regras |
|---|---|---|
Etapa 6: Máquinas virtuais
Para máquinas virtuais do farm do SharePoint, faça o seguinte:
Crie um conjunto de disponibilidade para cada conjunto de VMs em uma função comum e coloque todas as VMs com a mesma função de servidor nela.
Crie o conjunto de disponibilidade no grupo de recursos para a função de servidor.
Use no mínimo duas VMs para cada função de servidor.
Se estiver a utilizar Grupos de Disponibilidade AlwaysOn do SQL Server e planear utilizar apenas dois servidores SQL, também tem de utilizar o servidor de nós minoritários para o cluster.
Coloque as interfaces de rede e as VMs no grupo de recursos para a função de servidor.
Aqui estão os tamanhos de VMs mínimos recomendados:
Controladores de domínio do AD do Windows Server: Standard_D2
SQL Servers: Standard_DS4
Servidor de nós minoritário: Standard_D2
Servidores do SharePoint: Standard_DS4
Endereços para interfaces de rede:
Utilize endereços IP privados estáticos para todas as interfaces de VMs que sejam controladores de domínio ou que executem o SharePoint Server ou o SQL Server.
Use um endereço IP público somente para a VM de jumpbox.
Use um endereço IP público para o balanceador de carga voltado para a Internet para os servidores de front-end se o farm for exposto para a Internet.
Cada máquina virtual do Azure inclui um disco do sistema operacional. Você pode adicionar discos extras quando cria a máquina virtual ou adicioná-los mais tarde. Use a tabela a seguir para os discos extras mínimos para as VMs em um farm do SharePoint.
| Tipo de servidor | Discos extras |
|---|---|
| Controladores de domínio do AD do Windows Server |
Um disco de 40 GB extra para armazenar informações do Windows Server AD |
| SQL Servers |
Três discos extras de 1 TB para dados, logs e dados temporários |
| Servidores de aplicação ou pesquisa |
Um disco de 100 GB extra para logs, um disco de 200 GB extra para o índice de pesquisa |
| Servidores de front-end ou cache distribuído |
Um disco de 100 GB extra para logs |
Para os conjuntos de disponibilidade, preencha a tabela a seguir antes de criá-los, usando quantas linhas forem necessárias.
| Nome do conjunto de disponibilidade | Função da farm do SharePoint | Grupo de recursos |
|---|---|---|
Para as interfaces de rede de VMs, preencha a tabela a seguir antes de criá-los, usando quantas linhas forem necessárias.
| Nome da interface de rede | Grupo de recursos | Nome da sub-rede | Endereço IP estático | Instância do balanceador de carga (se necessário) |
|---|---|---|---|---|
Para as VMs, preencha a tabela a seguir antes de criá-los, usando quantas linhas forem necessárias.
| Nome da máquina virtual | Objetivo | Tamanho | Conjunto de disponibilidade | Grupo de recursos | Nome da interface de rede |
|---|---|---|---|---|---|
Próximas etapas
Se estiver pronto para criar uma configuração de prova de conceito ou dev/teste de um farm do SharePoint Server na intranet no Azure, veja Intranet SharePoint Server in Azure dev/test environment (Ambiente de desenvolvimento/teste do SharePoint Server na Intranet).
Se estiver pronto para implementar um farm do SharePoint Server pronto para produção e de elevada disponibilidade no Azure, veja Deploying SharePoint Server with SQL Server AlwaysOn Availability Groups in Azure (Implementar o SharePoint Server com Grupos de Disponibilidade AlwaysOn do SQL Server no Azure).
Confira também
Conceitos
Instalar e configurar o SharePoint Server 2016