Editar

Executar um farm do SharePoint Server 2016 de elevada disponibilidade no Azure

Azure ExpressRoute
Azure Managed Disks
Azure Virtual Machines
Azure Virtual Network
Azure VPN Gateway

Esta arquitetura de referência mostra práticas comprovadas para implementar um farm do SharePoint Server 2016 de elevada disponibilidade no Azure com a topologia MinRole e os grupos de disponibilidade AlwaysOn do SQL Server. O farm do SharePoint é implantado em uma rede virtual segura sem ponto de extremidade ou presença voltada para a Internet.

Arquitetura

Architecture diagram that shows a highly available SharePoint Server 2016 farm in Azure.

Transfira um ficheiro do Visio desta arquitetura.

Essa arquitetura se baseia na mostrada em [Executar VMs do Windows para um aplicativo de N camadas][windows-n-tier]. Ele implanta um farm do SharePoint Server 2016 com alta disponibilidade dentro de uma rede virtual do Azure. Esta arquitetura é adequada para um ambiente de teste ou produção, uma infraestrutura híbrida do SharePoint com o Microsoft 365 ou como base de um cenário de recuperação após desastre.

Componentes

  • Os grupos de recursos são contêineres que contêm recursos relacionados do Azure. Um grupo de recursos é usado para os servidores do SharePoint e outro grupo de recursos é usado para componentes de infraestrutura que são independentes de máquinas virtuais (VMs), como a rede virtual e os balanceadores de carga.

  • A Rede Virtual do Azure é o bloco de construção fundamental para redes privadas no Azure. As VMs são implantadas em uma rede virtual com um espaço de endereço de intranet exclusivo. A rede virtual é ainda subdividida em sub-redes.

  • As VMs são recursos de computação escalonáveis sob demanda que estão disponíveis com o Azure. As VMs são implantadas na rede virtual e os endereços IP estáticos privados são atribuídos a todas as VMs. Os endereços IP estáticos são recomendados para as VMs que executam o SQL Server e o SharePoint Server 2016, para evitar problemas com a colocação em cache de endereços IP e as alterações de endereços após um reinício.

  • Os conjuntos de disponibilidade são agrupamentos lógicos de VMs. Coloque as VMs de cada função do SharePoint em conjuntos de disponibilidade separados e provisione pelo menos duas VMs para cada função. Essa configuração torna as VMs qualificadas para um SLA (contrato de nível de serviço) mais alto.

  • O Balanceador de Carga do Azure distribui o tráfego de solicitação do SharePoint da rede local para os servidores Web front-end do farm do SharePoint. Esta solução utiliza um balanceador de carga interno. Alternativa para o tráfego HTTP, o Gateway de Aplicativo do Azure pode ser usado.

  • Os grupos de segurança de rede filtram o tráfego em uma rede virtual do Azure. Para cada sub-rede que contém VMs, um grupo de segurança de rede é criado. Use grupos de segurança de rede para restringir o tráfego de rede dentro de uma rede virtual, a fim de isolar sub-redes.

  • O Azure ExpressRoute ou uma VPN site a site, como o Gateway de VPN do Azure, fornece uma conexão entre sua rede local e a rede virtual do Azure. Para obter mais informações, veja Ligar uma rede no local ao Azure.

  • Os controladores de domínio do Ative Directory (AD) do Windows Server autenticam usuários em um domínio. Os controladores de domínio nesta arquitetura de referência são executados na rede virtual do Azure e têm uma relação de confiança com a floresta do AD do Windows Server local. As solicitações da Web de cliente para recursos de farm do SharePoint são autenticadas na rede virtual em vez de enviar esse tráfego de autenticação através da conexão de gateway para a rede local. No DNS, são criados registos de intranet A ou CNAME para que os utilizadores da intranet possam resolver o nome do farm do SharePoint para o endereço IP privado do balanceador de carga interno.

    O SharePoint Server 2016 também oferece suporte ao uso dos Serviços de Domínio Microsoft Entra. Os Serviços de Domínio Microsoft Entra fornecem serviços de domínio gerenciado para que você não precise implantar e gerenciar controladores de domínio no Azure.

  • Os grupos de disponibilidade Always On do SQL Server fornecem uma solução de alta disponibilidade e recuperação de desastres. Nós os recomendamos para alta disponibilidade do banco de dados do SQL Server. Duas VMs são usadas para o SQL Server. Um contém a réplica do banco de dados primário e o outro contém a réplica secundária.

  • Uma VM de nó majoritário permite que o cluster de failover estabeleça um quórum. Para obter mais informações, veja Compreender as Configurações do Quórum num Cluster de Ativação Pós-falha.

  • O SharePoint Server fornece uma plataforma para acesso compartilhado. Os servidores do SharePoint efetuam as funções de front-end Web, colocação em cache, aplicação e pesquisa.

  • Uma caixa de salto, que também é chamada de host bastião, é uma VM segura na rede que os administradores usam para se conectar às outras VMs. A caixa de salto tem um grupo de segurança de rede que permite o tráfego remoto apenas de endereços IP públicos em uma lista segura. O grupo de segurança de rede deve permitir o tráfego de área de trabalho remota (RDP).

Recomendações

Os requisitos podem ser diferentes da arquitetura descrita aqui. Utilize estas recomendações como um ponto de partida.

Recomendações para grupos de recursos

Recomendamos a separação dos grupos de recursos de acordo com a função de servidor e ter um grupo de recursos separado dos componentes de infraestrutura que sejam recursos globais. Nesta arquitetura, os recursos do SharePoint formam um grupo, enquanto que o SQL Server e outros elementos do utilitário formam outro.

Recomendações para redes virtuais e sub-redes

Use uma sub-rede para cada função do SharePoint, além de uma sub-rede para o gateway e uma para a caixa de salto.

A sub-rede de gateway tem de ter o nome GatewaySubnet. Atribua o espaço de endereços da sub-rede de gateway a partir da última parte do espaço de endereços de rede virtual. Para obter mais informações, veja Ligar uma rede no local ao Azure com um gateway de VPN.

Recomendações de VMs

Esta arquitetura requer um mínimo de 44 núcleos:

  • Oito servidores SharePoint no Standard_DS3_v2 (4 núcleos cada) = 32 núcleos
  • Dois controladores de domínio do Ative Directory no Standard_DS1_v2 (1 núcleo cada) = 2 núcleos
  • Duas VMs do SQL Server em Standard_DS3_v2 = 8 núcleos
  • Um nó majoritário em Standard_DS1_v2 = 1 núcleo
  • Um servidor de gerenciamento em Standard_DS1_v2 = 1 núcleo

Para todas as funções do SharePoint, exceto o Indexador de Pesquisas, recomendamos a utilização do tamanho de VM Standard_DS3_v2. O Indexador de Pesquisas deve ter, no mínimo, o tamanho Standard_DS13_v2. Para obter mais informações, veja Requisitos de hardware e software para o SharePoint Server 2016. Para as VMs do SQL Server, recomendamos um mínimo de 4 núcleos e 8 GB de RAM. Para obter mais informações, veja Planeamento e configuração do armazenamento e da capacidade do SQL Server (SharePoint Server).

Recomendações do grupo de segurança de rede

Recomendamos ter um grupo de segurança de rede para cada sub-rede que contém VMs, para habilitar o isolamento de sub-rede. Se desejar configurar o isolamento de sub-rede, adicione regras de grupo de segurança de rede que definam o tráfego de entrada ou saída permitido ou negado para cada sub-rede. Para obter mais informações, veja Filtrar o tráfego de rede com grupos de segurança de rede.

Não atribua um grupo de segurança de rede à sub-rede do gateway, ou o gateway deixará de funcionar.

Recomendações de armazenamento

A configuração de armazenamento das VMs no farm deve corresponder às melhores práticas adequadas utilizadas para implementações no local. Os servidores do SharePoint devem ter um disco separado para registos. Os servidores do SharePoint que alojam funções do índice de pesquisa requerem espaço em disco adicional para o armazenamento do índice de pesquisa. Para o SQL Server, a prática padrão é separar dados e registos. Adicione mais discos para armazenamento de cópias de segurança da base de dados e utilize um disco separado para tempdb.

Para garantir a melhor fiabilidade, recomendamos a utilização do Managed Disks do Azure. Os discos geridos asseguram que os discos para VMs num conjunto de disponibilidade estão isolados para evitar pontos únicos de falha.

Utilize discos geridos Premium para todas as VMs do SharePoint e do SQL Server. Pode utilizar discos geridos Padrão para o servidor de nó principal, os controladores de domínio e o servidor de gestão.

Recomendações para o SharePoint Server

Antes de configurar o farm do SharePoint, certifique-se de que tem uma conta de serviço do Windows Server Active Directory por serviço. Para essa arquitetura, você precisa, no mínimo, das seguintes contas de nível de domínio para isolar o privilégio por função:

  • Conta de Serviço do SQL Server
  • Conta de Configuração do Utilizador
  • Conta de Farm de Servidores
  • Conta de Serviço de Pesquisa
  • Conta de Acesso a Conteúdo
  • Contas de Conjunto de Aplicações Web
  • Contas de Conjunto de Aplicações de Serviço
  • Conta de Superutilizador de Cache
  • Conta de Superleitor de Cache

Para cumprir o requisito de suporte de débito de disco mínimo de 200 MB por segundo, certifique-se de que planeia a arquitetura de Pesquisa. Veja Planear a arquitetura de pesquisa empresarial no SharePoint Server 2013. Além disso, siga as diretrizes em Práticas recomendadas para rastreamento no SharePoint Server 2016.

Além disso, armazene os dados de componente de pesquisa numa partição ou volume de armazenamento separado com elevado desempenho. Para reduzir a carga e melhorar o débito, configure as contas de utilizador de cache de objetos, as quais são necessárias nesta arquitetura. Divida os ficheiros do sistema operativo Windows Server, os ficheiros de programa do SharePoint Server 2016 e os registos de diagnóstico por três partições ou volumes de armazenamento separados com um desempenho normal.

Para obter mais informações sobre estas recomendações, veja Implementação administrativa inicial e contas de serviço no SharePoint Server 2016.

Cargas de trabalho híbridas

Essa arquitetura de referência implanta um farm do SharePoint Server 2016 que pode ser usado como um ambiente híbrido do SharePoint, ou seja, estendendo o SharePoint Server 2016 para o SharePoint Online. Se tiver o Office Online Server, veja Suportabilidade do Office Web Apps e do Office Online Server no Azure.

Os aplicativos de serviço padrão nesta solução são projetados para suportar cargas de trabalho híbridas. Todas as cargas de trabalho híbridas do SharePoint Server 2016 e do Microsoft 365 podem ser implantadas neste farm sem alterações na infraestrutura do SharePoint, com uma exceção: o Aplicativo de Serviço de Pesquisa Híbrida na Nuvem não deve ser implantado em servidores que hospedam uma topologia de pesquisa existente. Por conseguinte, é necessário adicionar uma ou mais VMs baseadas em funções de pesquisa ao farm para suportar este cenário híbrido.

Grupos de disponibilidade Always On do SQL Server

Essa arquitetura usa VMs do SQL Server porque o SharePoint Server 2016 não pode usar o Banco de Dados SQL do Azure. Para suportar elevada disponibilidade no SQL Server, recomendamos a utilização de grupos de disponibilidade Always On, os quais especificam um conjunto de bases de dados que efetuam a ativação pós-falha em conjunto, tornando-os altamente disponíveis e recuperáveis. Para obter mais informações, veja Criar o grupo de disponibilidade e adicionar as bases de dados do SharePoint.

Também recomendamos adicionar um endereço IP de ouvinte ao cluster, que é o endereço IP privado do balanceador de carga interno para as VMs do SQL Server.

Para obter os tamanhos de VM recomendados e outras recomendações de desempenho para o SQL Server em execução no Azure, veja Melhores práticas de desempenho do SQL Server nas Máquinas Virtuais do Azure. Siga também as recomendações em Melhores práticas do SQL Server num farm do SharePoint Server 2016.

Recomendamos que o servidor do nó principal resida em um computador separado dos parceiros de replicação. O servidor permite ao servidor do parceiro de replicação secundário numa sessão do modo de alta segurança reconhecer se deve iniciar uma ativação pós-falha automática. Ao contrário dos dois parceiros, o servidor de nó principal não serve a base de dados, mas suporta a ativação pós-falha automática.

Considerações

Essas considerações implementam os pilares do Azure Well-Architected Framework, que é um conjunto de princípios orientadores que podem ser usados para melhorar a qualidade de uma carga de trabalho. Para obter mais informações, consulte Microsoft Azure Well-Architected Framework.

Escalabilidade

Para aumentar a escala dos servidores existentes, altere o tamanho da VM.

Com a capacidade MinRoles no SharePoint Server 2016, pode aumentar horizontalmente os servidores com base na função do servidor, bem como remover servidores de uma função. Ao adicionar servidores a uma função, pode especificar qualquer uma das funções únicas ou uma das funções combinadas. No entanto, se adicionar servidores à função Pesquisa, também tem de reconfigurar a topologia de pesquisa através do PowerShell. Também pode converter as funções atrevés de MinRoles. Para obter mais informações, veja Gerir um Farm de Servidores MinRole no SharePoint Server 2016.

O SharePoint Server 2016 não oferece suporte ao uso de Conjuntos de Dimensionamento de Máquina Virtual para dimensionamento automático.

Disponibilidade

Essa arquitetura de referência dá suporte à alta disponibilidade em uma região do Azure porque cada função tem pelo menos duas VMs implantadas em um conjunto de disponibilidade.

Para proteção contra uma falha regional, crie um farm de recuperação após desastre separado numa região do Azure diferente. Os objetivos de tempo de recuperação (RTOs) e os objetivos de ponto de recuperação (RPOs) irão determinar os requisitos de configuração. Para obter detalhes, veja Escolher uma estratégia de recuperação após desastre para o SharePoint 2016. A região secundária deve ser uma região emparelhada com a região primária. Em caso de uma falha abrangente, a recuperação de uma região tem prioridade em cada par. Para obter mais informações, veja Continuidade empresarial e recuperação após desastre (BCDR): Regiões Emparelhadas do Azure.

Capacidade de gestão

Para operar e manter servidores, farms de servidores e sites, siga as práticas recomendadas para operações do SharePoint. Para obter mais informações, veja Operações para o SharePoint Server 2016.

As tarefas a considerar quando gerir o SQL Server num ambiente do SharePoint podem divergir das normalmente consideradas para uma aplicação de base de dados. Uma melhor prática é criar uma cópia de segurança completa de todas as bases de dados do SQL Server semanalmente com cópias de segurança incrementais durante a noite. Crie uma cópia de segurança dos registos de transações a cada 15 minutos. Outra prática é implementar tarefas de manutenção do SQL Server nas bases de dados ao desativar as incorporadas no SharePoint. Para obter mais informações, veja Planeamento e configuração do armazenamento e da capacidade do SQL Server.

Segurança

A segurança oferece garantias contra ataques deliberados e o abuso de seus valiosos dados e sistemas. Para obter mais informações, consulte Visão geral do pilar de segurança.

As contas de serviço de nível de domínio usadas para executar o SharePoint Server 2016 exigem controladores de domínio do Windows Server AD ou Serviços de Domínio Microsoft Entra para processos de ingresso no domínio e autenticação. No entanto, para ampliar a infraestrutura de identidade do Windows Server AD já em vigor na intranet, esta arquitetura específica utiliza duas VMs como controladores de domínio de réplica do Windows Server AD de uma floresta do Windows Server AD no local existente.

Além disso, é sempre aconselhado planear a proteção de segurança. Outras recomendações incluem:

  • Adicione regras a grupos de segurança de rede para isolar sub-redes e funções.
  • Não atribuir endereços IP públicos a VMs.
  • Para deteção de intrusões e análise de payloads, considere a utilização de uma aplicação de rede virtual à frente dos servidores Web de front-end em vez de um balanceador de carga do Azure interno.
  • Como opção, utilize políticas IPsec para encriptação de tráfego de texto não encriptado entre servidores. Se você também estiver fazendo isolamento de sub-rede, atualize as regras do grupo de segurança de rede para permitir o tráfego IPsec.
  • Instale agentes antimalware para as VMs.

Otimização de custos

A otimização de custos consiste em procurar formas de reduzir despesas desnecessárias e melhorar a eficiência operacional. Para obter mais informações, consulte Visão geral do pilar de otimização de custos.

Utilize a calculadora de preços do Azure para prever os custos. Aqui estão alguns fatores para otimizar o custo dessa arquitetura.

Active Directory Domain Services

Considere ter o Active Directory Domain Services como um serviço partilhado que é consumido por várias cargas de trabalho para reduzir os custos. Para obter mais informações, consulte Preços dos Serviços de Domínio Ative Directory para obter mais informações.

Gateway de VPN

O modelo de faturação baseia-se na quantidade de tempo em que o gateway está aprovisionado e disponível. Consulte Preços do VPN Gateway.

Todo o tráfego de entrada é gratuito. Todo o tráfego de saída é cobrado. São aplicados os custos com a largura de banda da Internet ao tráfego de saída da VPN.

Rede Virtual

A Rede Virtual é gratuita. Todas as subscrições podem criar até 50 redes virtuais em todas as regiões. Todo o tráfego com origem dentro dos limites de uma rede virtual é gratuito. Assim, a comunicação entre duas VMs na mesma rede virtual é gratuita.

Essa arquitetura se baseia na arquitetura implantada em [Run Windows VMs for an N-tier application][windows-n-tier].

Para obter mais informações, veja a secção de custos Well-Architected Framework do Microsoft Azure.

DevOps

Considere a utilização de grupos de recursos separados para ambientes de produção, desenvolvimento e teste. A utilização de grupos de recursos separados torna mais fácil gerir as implementações, eliminar as implementações de teste e atribuir direitos de acesso. Em geral, coloque os recursos com o mesmo ciclo de vida no mesmo grupo de recursos. Utilize o escalão Programador para ambientes de desenvolvimento e teste. Para minimizar os custos durante a pré-produção, implemente uma réplica do seu ambiente de produção, execute os testes e, em seguida, encerre.

Use modelos do Azure Azure Resource Manager ou modelos do Azure Bicep para definir a infraestrutura. Em ambos os casos, você segue a prática de infraestrutura como código (IaC) para implantar os recursos. Para automatizar a implementação da infraestrutura, pode utilizar o Azure DevOps Services ou outras soluções CI/CD. O processo de implementação também é idempotente, ou seja, repetível para produzir os mesmos resultados. O Azure Pipelines faz parte do Azure DevOps Services e executa compilações, testes e implementações automatizados.

Estruture seus modelos de implantação seguindo os critérios de carga de trabalho, identifique unidades únicas de trabalho e inclua-as em seu próprio modelo. Nesse cenário, pelo menos sete cargas de trabalho são identificadas e isoladas em seus próprios modelos: a rede virtual do Azure e o gateway VPN, a caixa de salto de gerenciamento, controladores de domínio do AD e VMs do SQL Server, o cluster de Failover e o grupo de disponibilidade e as regras VMs Restantes, nó primário do Sharepoint, cache do SharePoint e grupo de segurança de rede. O isolamento da carga de trabalho facilita a associação dos recursos específicos da carga de trabalho a uma equipa, para que esta possa gerir de forma independente todos os aspetos desses recursos. Esse isolamento permite que o DevOps execute integração contínua e entrega contínua (CI/CD). Essa configuração também permite o preparo de suas cargas de trabalho, o que significa implantar em vários estágios e executar validações em cada estágio antes de passar para o próximo. Dessa forma, você pode enviar atualizações para seus ambientes de produção de forma altamente controlada e minimizar problemas de implantação imprevistos.

Considere usar o Azure Monitor para analisar e otimizar o desempenho de sua infraestrutura, monitorar e diagnosticar problemas de rede sem fazer logon em suas VMs.

Para obter mais informações, consulte a seção DevOps no Azure Well-Architected Framework.

Próximos passos

Para obter mais informações sobre as partes individuais da arquitetura da solução, consulte os seguintes tópicos: