Condividi tramite

Ottimizzazione di SQL e risoluzione dei problemi di latenza con AD FS

In un aggiornamento per AD FS 2016sono stati introdotti i miglioramenti seguenti per ridurre la latenza tra database. Un prossimo aggiornamento per AD FS 2019 includerà questi miglioramenti.

In-Memory aggiornamento della cache nel thread in esecuzione in background

Nelle distribuzioni di disponibilità Always On precedenti (AoA) esiste una latenza per qualsiasi operazione di "lettura" perché il nodo master può trovarsi in un data center separato. La chiamata tra due data center diversi ha generato una latenza.

Nell'aggiornamento più recente ad AD FS, una riduzione della latenza si ottiene tramite l'aggiunta di un thread in background per aggiornare la cache di configurazione di AD FS e un'impostazione per definire il periodo di intervallo per l'aggiornamento. Il tempo impiegato per una ricerca di database è notevolmente ridotto nel thread di richiesta, perché gli aggiornamenti della cache del database vengono spostati nel thread in background.

Quando il backgroundCacheRefreshEnabled è impostato su true, AD FS consentirà al thread in background di eseguire gli aggiornamenti della cache. La frequenza di recupero dei dati dalla cache può essere personalizzata in un valore di ora impostando cacheRefreshIntervalSecs. Il valore predefinito è impostato su 300 secondi quando backgroundCacheRefreshEnabled è impostato su true. Dopo la durata del valore impostato, AD FS inizia ad aggiornare la cache e, mentre l'aggiornamento è in corso, i dati della cache precedenti continueranno a essere usati.

Quando AD FS riceve una richiesta per un'applicazione, AD FS recupera l'applicazione da SQL e la aggiunge alla cache. Quando si raggiunge il valore cacheRefreshIntervalSecs, l'applicazione nella cache viene aggiornata utilizzando il thread in background. Finché esiste una voce nella cache, le richieste in arrivo utilizzeranno la cache mentre è in corso l'aggiornamento in background. Se una voce non viene consultata per 5 * cacheRefreshIntervalSecs, viene eliminata dalla cache. La voce meno recente può anche essere eliminata dalla cache dopo il raggiungimento del valore configurabile maxRelyingPartyEntries.

Nota

I dati della cache verranno aggiornati al di fuori del valore cacheRefreshIntervalSecs se AD FS riceve una notifica da SQL che indica che si è verificata una modifica nel database. Questa notifica attiverà l'aggiornamento della cache.

Raccomandazioni per l'impostazione dell'aggiornamento della cache

Il valore predefinito per l'aggiornamento della cache è cinque minuti. È consigliabile impostarlo su 1 ora per ridurre un aggiornamento dei dati non necessario da AD FS perché i dati della cache verranno aggiornati se si verificano modifiche SQL.

AD FS registra un callback per le modifiche di SQL e, in caso di modifica, AD FS riceve una notifica. Tramite questo metodo, AD FS riceve ogni nuova modifica da SQL non appena si verifica.

In caso di errore di rete, che causa l'assenza della notifica SQL da PARTE di AD FS, AD FS verrà aggiornato all'intervallo specificato dal valore di aggiornamento della cache. Se si sospettano problemi di connettività tra AD FS e SQL, è consigliabile impostare il valore di aggiornamento della cache su un valore inferiore a 1 ora.

Istruzioni per la configurazione

Il file di configurazione supporta più voci della cache. L'elenco seguente può essere configurato in base alle esigenze dell'organizzazione.

L'esempio seguente abilita l'aggiornamento della cache in background e imposta il periodo di aggiornamento della cache su 1800 secondi o 30 minuti. Questa operazione deve essere eseguita in ogni nodo AD FS e il servizio AD FS deve essere riavviato in seguito. Le modifiche non influiscono sugli altri nodi e testano il primo nodo prima di apportare la modifica in tutti i nodi.

  1. Passare al file di configurazione di AD FS (percorso predefinito C:\Windows\ADFS\Microsoft.IdentityServer.ServiceHost.exe.config) e nella sezione "Microsoft.IdentityServer.Service", aggiungere la voce seguente:
  • backgroundCacheRefreshEnabled : specifica se la funzionalità della cache in background è abilitata. Valori "vero/falso".
  • cacheRefreshIntervalSecs : valore in secondi in cui AD FS aggiornerà la cache. AD FS aggiornerà la cache in caso di modifiche in SQL. AD FS riceverà una notifica SQL e aggiornerà la cache.

Nota

Tutte le voci nel file di configurazione fanno distinzione tra maiuscole e minuscole. <cache cacheRefreshIntervalSecs="1800" > backgroundCacheRefreshEnabled="true" />

Valori configurabili aggiuntivi supportati:

  • maxRelyingPartyEntries - Numero massimo di voci delle entità fidate che AD FS manterrà in memoria. Questo valore viene usato anche dalla cache delle autorizzazioni dell'applicazione oAuth. Se sono presenti più autorizzazioni dell'applicazione rispetto agli indirizzi IP e se tutto verrà archiviato in memoria, questo valore deve essere il numero di autorizzazioni dell'applicazione. Il valore predefinito è 1000.
  • maxIdentityProviderEntries: si tratta del numero massimo di voci del provider di attestazioni che AD FS manterrà in memoria. Il valore predefinito è 200.
  • maxClientEntries - Questo rappresenta il numero massimo di record dei client OAuth che AD FS manterrà in memoria. Il valore predefinito è 500.
  • maxClaimDescriptorEntries - Numero massimo di voci del descrittore di attestazioni che AD FS manterrà in memoria. Il valore predefinito è 500.
  • maxNullEntries: viene usata come cache negativa. Quando AD FS cerca una voce nel database e non viene trovata, AD FS la aggiunge alla cache negativa. Questa è la dimensione massima della cache. È presente una cache negativa per ogni tipo di oggetti, non è una singola cache per tutti gli oggetti. Il valore predefinito è 50.0000.

Supporto per database di artefatti su più data center

Per le configurazioni precedenti di più data center, AD FS supporta solo un singolo database artifact, causando la latenza tra data center durante le chiamate di recupero.

Per ridurre la latenza tra data center, un amministratore di AD FS può ora distribuire più istanze del database degli artefatti e quindi modificare il file di configurazione di un nodo AD FS in modo che punti a istanze di database artefatte diverse. La stringa di connessione al database di artefatti può essere fornita nel file di configurazione, consentendo un database di artefatti per ogni nodo. Se la stringa di connessione non è presente all'interno del file di configurazione, il nodo eseguirà il fallback alla progettazione precedente per usare il database dell'artefatto, presente nel database di configurazione. Gli ambienti ibridi sono supportati anche con questa configurazione.

Requisiti

Prima di configurare il supporto di più database artefatti, eseguire un aggiornamento in tutti i nodi e aggiornare i file binari perché si verificano chiamate a più nodi tramite questa funzionalità.

  1. Generare lo script di distribuzione per creare il database artefatto: per distribuire più istanze del database artefatto, un amministratore dovrà generare lo script di distribuzione SQL per il database artefatto. Come parte di questo aggiornamento, il cmdlet Export-AdfsDeploymentSQLScriptesistente è stato aggiornato per accettare facoltativamente un parametro che specifica il database AD FS per cui generare uno script di distribuzione SQL.

Ad esempio, per generare lo script di distribuzione solo per artifact DB, specificare il parametro -DatabaseType e passare il valore "Artifact". Il parametro facoltativo -DatabaseType specifica il tipo di database AD FS e può essere impostato su: All (impostazione predefinita), Artifact o Configuration. Se non viene specificato alcun parametro -DatabaseType, lo script configurerà sia gli script Artifact che Configuration.

PS C:\> Export-AdfsDeploymentSQLScript -DestinationFolder <script folder where scripts will be created> -ServiceAccountName <domain\serviceaccount> -DatabaseType "Artifact"

Lo script generato deve essere eseguito nel computer SQL per creare i database necessari e assegnare all'account del servizio AD FS le autorizzazioni sql sa per tali database.

  1. Creare l'Artifact DB usando lo script di distribuzione. Copiare i CreateDB.sql appena generati e SetPermissions.sql script di distribuzione nel computer SQL Server ed eseguirli per creare il database artefatto locale.

  2. Modificare il file di configurazione per aggiungere la connessione Artifact DB. Passare al file di configurazione del nodo AD FS e nella sezione "Microsoft.IdentityServer.Service", aggiungere un punto di ingresso al database ArtifactDB appena configurato.

Nota

I valori artifactStore e connectionString fanno distinzione tra maiuscole e minuscole. Assicurarsi che siano configurati correttamente. <artifactStore connectionString="Data Source=.\SQLInstance; Sicurezza integrata=True; Initial Catalog=AdfsArtifactStore" />

Usare un valore origine dati corrispondente alla connessione SQL.

  1. Riavviare il servizio AD FS per rendere effettive le modifiche.

Nota

Non è consigliabile usare la replica SQL o la sincronizzazione tra i database degli artefatti. È consigliabile configurare un database per gli artefatti per datacenter.

Failover e ripristino del database tra diversi data center

È consigliabile creare database degli artefatti di failover nello stesso data center del database degli artefatti master. Se si verifica un failover, non verrà generato alcun aumento della latenza. Non è consigliabile utilizzare database di artefatti di failover tra i centri dati. Di seguito viene spiegato come funzionano le chiamate per OAuth, SAML, ESL e il rilevamento della riproduzione di token con più database di artefatti.

  • OAuth e SAML

    Per le richieste di artefatti OAuth e SAML, il nodo creerà l'artefatto nel database dell'artefatto presente nel file di configurazione. Se il file di configurazione non contiene una connessione al database artefatto, userà il database dell'artefatto comune. Quando la richiesta successiva per recuperare l'artefatto arriva a un altro nodo, quest'ultimo effettuerà una richiesta API REST al primo nodo per recuperare l'artefatto dal database degli artefatti. Questa operazione è necessaria perché i diversi nodi potrebbero avere database di artefatti diversi e i nodi non lo conoscono. Se il primo nodo è inattivo, la risoluzione degli artefatti avrà esito negativo. A causa di questa progettazione, la replica del database dell'artefatto in data center diversi non è necessaria. Se un intero data center è inattivo, molto probabilmente il nodo che ha creato l'artefatto è inattivo, significa che l'artefatto non può più essere risolto.

  • blocco Extranet

    Il database Artifact a cui si fa riferimento nel file di configurazione verrà usato per i dati di blocco Extranet. Tuttavia, per la funzionalità ESL, AD FS sceglie un master, che scrive i dati nel database dell'artefatto. Tutti i nodi effettuano una chiamata API REST al nodo master per ottenere e impostare le informazioni più recenti su ogni utente. Se sono in uso più database di artefatti, l'amministratore deve selezionare un nodo master per ogni database o data center artefatto.

    Per selezionare un nodo come master ESL, passare al file di configurazione del nodo AD FS e nella sezione "Microsoft.IdentityServer.Service" aggiungere quanto segue:

    Nel master aggiungere la voce seguente. Tutte e tre le chiavi fanno distinzione tra maiuscole e minuscole.

    <useractivityfarmrole masterFQDN=[FQDN della primaria selezionata] isMaster="true"/>

    Negli altri nodi aggiungere la voce seguente:

    <useractivityfarmrole masterFQDN=[FQDN del server primario selezionato] isMaster="false"/>

    Nota

    Poiché più database di artefatti non sincronizzano i dati, i valori ESL non verranno sincronizzati tra database di artefatti. Un utente può potenzialmente raggiungere un data center diverso per una richiesta, rendendo quindi ExtranetLockoutThreshold dipendente dal numero di database artefatti, ExtranetLockoutThreshold * Numero di database artefatti.

    • rilevamento del riutilizzo dei token

      I dati di rilevamento della riproduzione dei token vengono sempre recuperati dal database centrale Artifact. AD FS salva il token dall'attendibilità del provider di attestazioni, assicurandosi che lo stesso token non possa essere riprodotto. Se un utente malintenzionato tenta di riprodurre lo stesso token, AD FS verifica se il token esiste nel database artifact. Se il token è presente, la richiesta verrà rifiutata. Il database dell'artefatto centrale viene usato per la sicurezza, poiché i dati di Artifact DB non vengono replicati, un utente malintenzionato potrebbe inviare la richiesta a un altro data center e riprodurre un token. La creazione di copie aggiuntive di sola lettura di ArtifactDB non impedirà la latenza tra data center in questo scenario, perché viene usato solo il database artifact centrale.