Compartilhar via


Farm de servidores de federação do AD FS herdado com o SQL Server

Essa topologia do AD FS (Serviços de Federação do Active Directory) é diferente do farm de servidores de federação que usa a topologia de implantação do WID (Banco de Dados Interno do Windows), pois não replica os dados para cada servidor de federação do farm. Em vez disso, todos os servidores de federação do farm podem ler e gravar dados em um banco de dados comum armazenado em um servidor que executa o Microsoft SQL Server localizado na rede corporativa.

Importante

Caso você deseje criar um farm do AD FS e usar o SQL Server para armazenar seus dados de configuração, use o SQL Server 2008 e versões mais recentes, incluindo o SQL Server 2012 e o SQL Server 2014.

Considerações de implantação

Esta seção descreve várias considerações sobre o público-alvo, os benefícios e as limitações que estão associadas a essa topologia de implantação.

Quem deve usar esta topologia?

  • Grandes organizações com mais de 100 relações de confiança que precisam fornecer aos usuários internos e externos acesso SSO (logon único) a aplicativos ou serviços federados

  • Organizações que já usam o SQL Server e querem aproveitar as ferramentas e as experiências existentes

Quais são os benefícios de usar essa topologia?

  • Suporte para um número maior de relações de confiança (mais de 100)

  • Suporte para detecção de reprodução de token (um recurso de segurança) e resolução de artefatos (parte do protocolo SAML (Security Assertion Markup Language) 2.0)

  • Suporte para os benefícios completos do SQL Server, como espelhamento de banco de dados, clustering de failover, relatórios e ferramentas de gerenciamento

Quais são as limitações de usar essa topologia?

  • Essa topologia não fornece redundância de banco de dados por padrão. Embora um farm de servidores de federação com a topologia do WID replique automaticamente o banco de dados do WID em cada servidor de federação do farm, a topologia do farm de servidores de federação com o SQL Server contém apenas uma cópia do banco de dados

    Observação

    O SQL Server dá suporte a muitas opções diferentes de redundância de dados e aplicativos, incluindo clustering de failover, espelhamento de banco de dados e vários tipos diferentes de replicação do SQL Server.

O departamento de TI (Tecnologia da Informação) da Microsoft usa o espelhamento de banco de dados do SQL Server no modo de alta segurança (síncrono) e o clustering de failover para fornecer suporte de alta disponibilidade para a instância do SQL Server. A replicação transacional (ponto a ponto) e de mesclagem do SQL Server não foram testadas pela equipe de produtos do AD FS na Microsoft. Para obter mais informações sobre o SQL Server, confira Visão geral das soluções de alta disponibilidade ou Como selecionar o tipo apropriado de replicação.

Versões do SQL Server com suporte

Há suporte para as seguintes versões do SQL Server no AD FS no Windows Server 2012 R2:

  • SQL Server 2008 / R2

  • SQL Server 2012

  • SQL Server 2014

Recomendações de posicionamento do servidor e layout de rede

Semelhante ao farm de servidores de federação com a topologia do WID, todos os servidores de federação do farm são configurados para usar um nome DNS (Serviço de Nomes de Domínio) de cluster (que representa o nome do Serviço de Federação) e um endereço IP de cluster como parte da configuração do cluster NLB (Balanceamento de Carga de Rede). Isso ajuda o host do NLB a alocar as solicitações de cliente para os servidores de federação individuais. Os proxies do servidor de federação podem ser usados para as solicitações de cliente proxy para o farm de servidores de federação.

A ilustração a seguir mostra como a empresa fictícia Contoso Pharmaceuticals implantou o topologia do farm de servidores de federação com o SQL Server na rede corporativa. Também mostra como a empresa configurou a rede de perímetro com acesso a um servidor DNS, um host do NLB adicional que usa o mesmo nome DNS do cluster (fs.contoso.com) usado no cluster do NLB da rede corporativa e com dois proxies de aplicativo Web (wap1 e wap2).

Illustration that shows how the fictional Contoso Pharmaceuticals company deployed its federation server farm with SQL Server topology in the corporate network.

Para obter mais informações sobre como configurar seu ambiente de rede para uso com servidores de federação ou proxies de aplicativo Web, consulte a seção "Requisitos de resolução de nomes" em Requisitos do AD FS e Planejar a infraestrutura WAP (Proxy de aplicativo Web).

Opções de alta disponibilidade para farms de SQL Server

No AD FS do Windows Server 2012 R2, há duas novas opções para dar suporte à alta disponibilidade em farms do AD FS usando SQL Server.

  • Suporte para os grupos de disponibilidade AlwaysOn do SQL Server

  • Suporte para alta disponibilidade distribuída geograficamente usando replicação de mesclagem do SQL Server

Esta seção descreve cada uma dessas opções, quais problemas eles resolvem respectivamente e algumas considerações importantes para decidir quais opções implantar.

Observação

Os farms do AD FS que usam WID (Banco de Dados Interno do Windows) fornecem redundância de dados básica com acesso de leitura/gravação no nó do servidor de federação primário e acesso somente leitura em nós secundários.  Isso pode ser usado em uma topologia geograficamente local ou distribuída geograficamente.

Ao usar o WID, lembre-se das limitações a seguir:

  • Um farm WID terá um limite de 30 servidores de federação se você tiver 100 ou menos objetos de confiança de terceira parte confiável.
  • Um farm WID não dá suporte à detecção de reprodução de token nem à resolução de artefatos (parte do protocolo SAML, Security Assertion Markup Language).

A tabela a seguir fornece um resumo para usar um farm WID:

1 a 100 relações de confiança de RP Mais de 100 relações de confiança de RP
1 a 30 nós do AD FS: Suporte ao WID 1 a 30 nós do AD FS: Sem suporte para uso do WID – O SQL é exigido
Mais de 30 Nós do AD FS: Sem suporte para uso do WID – O SQL é exigido Mais de 30 Nós do AD FS: Sem suporte para uso do WID – O SQL é exigido

Grupos de disponibilidade AlwaysOn

Visão geral

Os grupos de disponibilidade AlwaysOn foram introduzidos no SQL Server 2012 e fornecem uma nova maneira de criar uma instância de SQL Server de alta disponibilidade.  Os grupos de disponibilidade AlwaysOn combinam elementos de clustering e espelhamento de banco de dados para redundância e failover na camada da instância do SQL e na camada do banco de dados.  Ao contrário das opções anteriores de alta disponibilidade, os grupos de disponibilidade AlwaysOn não exigem um armazenamento comum (ou uma rede de área de armazenamento) na camada de banco de dados.

Um grupo de disponibilidade é composto por uma réplica primária (um conjunto de bancos de dados primários de leitura-gravação) e uma a quatro réplicas de disponibilidade (conjuntos de bancos de dados secundários correspondentes).  O grupo de disponibilidade dá suporte a uma única cópia de leitura/gravação (a réplica primária) e uma a quatro réplicas de disponibilidade somente leitura.  Cada réplica de disponibilidade deve residir em um nó diferente de um único cluster do WSFC (Windows Server Failover Clustering).  Para obter mais informações sobre os Grupos de Disponibilidade AlwaysOn, consulte Visão geral de grupos de disponibilidade AlwaysOn (SQL Server).

Da perspectiva dos nós de um farm de SQL Server do AD FS, o grupo disponibilidade AlwaysOn substitui a única instância do SQL Server como o banco de dados de política/artefato.  O ouvinte do grupo de disponibilidade é o que o cliente (o serviço de token de segurança do AD FS) usa para se conectar ao SQL.

O diagrama a seguir mostra um Farm de SQL Server do AD FS com o grupo disponibilidade AlwaysOn.

Diagram that shows an AD FS SQL Server Farm with AlwaysOn Availability group.

Observação

Os grupos de disponibilidade AlwaysOn exigem que as instâncias de SQL Server residam em nós WSFC (Clustering de failover do Windows Server).

Observação

Apenas uma réplica de disponibilidade pode atuar como um destino de failover automático, as outras três dependerão de failovers manuais.

Principais considerações sobre a implantação

Se você planeja usar grupos de disponibilidade AlwaysOn em combinação com a replicação de mesclagem do SQL Server, anote os problemas descritos em "Principais considerações de implantação para usar o AD FS com a replicação de mesclagem do SQL Server" abaixo.  Em particular, quando um grupo de disponibilidade AlwaysOn contendo um banco de dados que é um assinante de replicação executar failover, a assinatura de replicação apresentará falha. Para retomar a replicação, um administrador de replicação deve reconfigurar o assinante manualmente.  Consulte a descrição do SQL Server de um problema específico em Assinantes de replicação e grupos de disponibilidade AlwaysOn (SQL Server) e instruções de suporte geral para grupos de disponibilidade AlwaysOn com opções de replicação em Replicação, Controle de Alterações, captura de dados de alterações e grupos de disponibilidade AlwaysOn (SQL Server).

Configuração do AD FS para uso de um grupo de disponibilidade AlwaysOn

A configuração de um farm do AD FS com grupos de disponibilidade AlwaysOn requer uma pequena modificação no procedimento de implantação do AD FS:

  1. Os bancos de dados que você deseja fazer backup devem ser criados antes que os grupos de disponibilidade AlwaysOn possam ser configurados.  O AD FS cria seus bancos de dados como parte da configuração e da definição inicial do primeiro nó de serviço de federação de um novo farm de SQL Server do AD FS.  Como parte da configuração do AD FS, você deve especificar uma cadeia de conexão SQL, portanto, precisará configurar o primeiro nó de farm do AD FS para se conectar diretamente a uma instância do SQL (isso é apenas temporário).   Para obter diretrizes específicas sobre como configurar um farm do AD FS, incluindo a configuração de um nó de farm do AD FS com uma cadeia de conexão do SQL Server, consulte Configurar um servidor de federação.

  2. Depois que os bancos de dados do AD FS tiverem sido criados, atribua-os a grupos de disponibilidade AlwaysOn e crie o ouvinte TCPIP comum usando ferramentas de SQL Server e processo em Criação e configuração de grupos de disponibilidade (SQL Server).

  3. Por fim, use o PowerShell para editar as propriedades do AD FS para atualizar a cadeia de conexão SQL para usar o endereço DNS do ouvinte do grupo de disponibilidade AlwaysOn.

    Exemplo de comandos PSH para atualizar a cadeia de conexão SQL para o banco de dados de configuração do AD FS:

    PS:\>$temp= Get-WmiObject -namespace root/ADFS -class SecurityTokenService
    PS:\>$temp.ConfigurationdatabaseConnectionstring="data source=<SQLCluster\SQLInstance>; initial catalog=adfsconfiguration;integrated security=true"
    PS:\>$temp.put()
    
    
  4. Exemplo de comandos PSH para atualizar a cadeia de conexão SQL para o banco de dados do serviço de resolução de artefatos do AD FS:

    PS:\> Set-AdfsProperties –artifactdbconnection "Data source=<SQLCluster\SQLInstance >;Initial Catalog=AdfsArtifactStore;Integrated Security=True"
    

Replicação de mesclagem do SQL Server

Também introduzida no SQL Server 2012, a replicação de mesclagem permite a redundância de dados de política do AD FS com as seguintes características:

  • Capacidade de leitura e gravação em todos os nós (não apenas no primário)

  • Quantidades menores de dados replicados de forma assíncrona para evitar a introdução da latência ao sistema

O diagrama a seguir mostra farms de SQL Server do AD FS geograficamente redundantes com replicação de mesclagem (1 editor, 2 assinantes):

server farm using SQL

Principais considerações de implantação para usar o AD FS com replicação de mesclagem do SQL Server (anote os números no diagrama acima)

Para obter instruções mais detalhadas sobre como configurar o AD FS para usar uma replicação de mesclagem do SQL Server, consulte Configurar redundância geográfica com replicação do SQL Server.

Consulte Também

Planejar sua topologia de implantação do AD FSGuia de design do AD FS no Windows Server 2012 R2