Pillole di Sharepoint

Oggi, nell'angolo della Powershell, vediamo come trovare siti, liste e singoli elementi ai quali non risulta assegnato alcuna lista di autorizzazioni.

Lo script viene eseguito ricorsivamente su tutti i siti secondari esisitenti a qualsiasi livello.

#
# Search for sites, libraries and items with no permission
#

#add-pssnapin microsoft.sharepoint.powershell

function CheckZeroPermission ($Pweb)
    {
        $site = get-spweb ($Pweb)
        
        if (($site.HasUniqueRoleAssignments) -and ($site.RoleAssignments.Count -eq 0))
        {
         
            "Sito: " + $site.Title + " - " + $site.url
        }
            
        foreach($list in $site.Lists)
            {
                if (($list.HasUniqueRoleAssignments) -and ($list.RoleAssignments.Count -eq 0))
                    {
                        ”     Lista: ” + $list.Title + " - " + $list.defaultviewurl
                    }
            
                foreach ($item in $list.Items)
                    {
                        if (($item.HasUniqueRoleAssignments) -and ($item.roleassignments.count -eq 0))
                            {
                             ”          Elemento:  | ” + $item.ID + “ | ” + $item.Name
                            }
                    }
             } 
         
            foreach ($subsite in $site.webs)
                {
                    CheckZeroPermission ($subsite.url)
                }
                
            $web.Dispose()        
    }

CheckZeroPermission("http://")

Non ho mai sentito nessuno lamentarsi che SharePoint è troppo veloce, al contrario ho perso il conto delle critiche sulla lentezza di SharePoint. Vediamo allora alcuni suggerimenti per ridurre il più possibile queste critiche e dare agli utenti un’esperienza emozionante.

Infrastruttura

Una farm correttamente dimensionata è il primo passo verso uno SharePoint veloce e scattante: che si tratti una struttura ad uno, due o più livelli, è importante che le macchine siano “ben carrozzate”.

Microsoft fornisce per diverse topologie di farm dei requisiti minimi (vedi: SharePoint 2013, SharePoint 2010) che potrebbero però non essere sufficienti a supportare il nostro SharePoint. Il corretto dimensionamento di CPU e RAM dei server deve tener conto non solo di questi requisiti, ma anche del carico di utenti e contenuti che SharePoint dovrà sostenere.

Un altro componente da valutare attentamente è il disco, utilizzato intensamente da SharePoint. NAS, raid, SSD o qualunque sia la soluzione di storage scelta, l’importante è che i dischi siano performanti e combinati in una soluzione che non ne deteriori le prestazioni.

Anche la rete ha la sua importanza, specialmente nel caso di farm distribuite geograficamente; riassumendo possiamo dire che maggior banda disponibile = minori tempi di risposta delle web application.

L’ultima raccomandazione riguarda le farm create in ambienti virtuali. Anche in questo caso, a prescindere dalla soluzione adottata, è necessario che le risorse fisiche siano correttamente configurate ed allocate ad uso esclusivo per la farm SharePoint, e che non siano in condivisione con altri server.

Database

Come accennato in precedenza SQL Server riveste un’importanza strategica nel determinare le performance di SharePoint, come spiega Brian Alderman in Tuning SQL Server 2012 for SharePoint 2013. Le stesse indicazioni si possono applicare anche nel caso di SharePoint 2010 e SQL Server 2008.

Tra i vari temi trattati nel Webcast spiccano la corretta configurazione dell’autogrow dei file di database e log ed il posizionamento su diversi dischi dei vari file di database.

SharePoint

Cache

L’utilizzo della cache riduce le richieste al server SQL, con indubbi vantaggi soprattutto per i tempi di risposta che il sistema offre agli utenti; SharePoint mette a disposizione diverse tipologie di caching; ecco come abilitarle e configurarle sia per SharePoint 2010 che per SharePoint 2013.

Service Application

E’ buona norma creare ed utilizzare solo le Service Application realmente necessarie alle Web Application di SharePoint. In questo modo si eviterà di avere servizi inutilizzati che sottraggono risorse alle altre applicazioni concorrenti.

Sempre a proposito delle Service Application, un altro punto importante è definire se farle girare tutte attraverso un unico Application Pool (e relativo utente di servizio) oppure se utilizzare per ognuna un App Pool dedicato, con i seguenti pro e contro.

App Pool	Vantaggi	Svantaggi
Condiviso	Utilizza un unico thread IIS per tutte le SA	Il malfunzionamento di una SA può ripercuotersi su tutte le restanti SA. Il crash dell’App Pool rende indisponibili tutte le SA
Dedicato	Utilizza per ogni SA un thread IIS dedicato	Il crash di una singola SA o App Pool non si propaga alle restanti SA

Il trade off quindi è tra privilegiare le performance (App Pool singolo) a discapito della disponibilità dei servizi in caso di crash, o viceversa. Solo una valutazione dell’ambito di utilizzo di SharePoint può far propendere per una o per l’altra soluzione.

Web Application

Le stesse considerazioni fatte per le Service Application possono essere fatte per le Web Application, ma in questo caso si tende a prediligere la soluzione con Application Pool dedicati.

Per quanto riguarda le Web Application, inoltre, SharePoint mette a disposizione una serie di opzioni che permettono di gestire le risorse disponibili, evitando che alcune applicazioni “fuori controllo” (vedi tra qualche riga l'annoso problema delle “Large List”) possano far degradare le performance delle altre. Tutto ciò viene gestito attraverso le opzioni di Resource Throttling.

Site collection

E’ possibile ottimizzare le prestazioni di una farm SharePoint intervenendo anche a livello di Site Collection, attuando una “revisione applicativa”.

Dal momento della sua ideazione e creazione, una Site Collection passa attraverso numerose revisioni in termini di funzionalità, tipologia di contenuti, ed i dati tendono ad aumentare, a volte in modo incontrollato od imprevisto. In questa fase è necessario rivedere le funzionalità della Site Collection per valutarne le debolezze e quindi intervenire:

Large list

Liste e raccolte con numerosi elementi (parliamo di decine di migliaia) sarebbero da evitare; a tal proposito è buona cosa seguire le indicazioni proposte da Microsoft per gestire tali situazioni.

In aggiunta è possibile implementare un “Datawarehouse”, che può essere una semplice lista parallela, in cui spostare il contenuto obsoleto (soluzione più semplice) oppure una Site Collection o Web Application dedicata. I criteri per cui spostare gli elementi nel Datawarehouse dipendono quasi esclusivamente dalla natura dei dati, ma in genere si possono archiviare gli elementi in base all’anno, allo stato, alla versione, … Una soluzione più complessa, ma certamente interessante per alcune realtà, è l’utilizzo di un Record o Document Center, caratteristica di cui SharePoint è orgogliosamente dotato.

Autorizzazioni

Argomento delicato non solo da un punto di vista tecnico, ma anche operativo ed in alcuni casi legale, la gestione delle autorizzazioni può influire in positivo o in negativo sulle performance di una farm SharePoint.

Va fatta particolare attenzione nel gestire permessi specifici per ogni singolo elemento. Il motivo è semplice: per ogni autorizzazione esclusiva viene creata una ACL (consultata dal sistema ad ogni risorsa richiesta) per determinare se mostrare o meno l'elemento all’utente. Queste verifiche comportano letture su SQL e tempo di CPU. Se ogni singolo utente richiede di visualizzare una lista contenente diverse migliaia di elementi, e questa attività la fanno più utenti contemporaneamente, il degrado di performance è dietro l'angolo. Un’alternativa è l’uso di cartelle con autorizzazioni specifiche, soluzione che riduce le singole ACL create, e di conseguenza non penalizza le prestazioni.

Workflow

Anche i workflow posso essere oggetto di revisione ed ottimizzazione, implementando le stesse funzionalità con una logica differente, sia sfruttando le funzionalità OOB, sia ricorrendo, se necessario, a soluzioni di terze parti.

Altre attività che influenzano le performance

Crawling

Anche le attività di indicizzazione impattano pesantemente sulle performance. E’ buona norma pianificare le attività di crawling tenendo conto di due particolari parametri:

Orario: le attività più intensive quali i full crawl devono essere schedulati in momenti di traffico basso o assente, ad esempio in orario notturno o durante le tipiche pause di lavoro (es. pranzo)

Variabilità dei contenuti: un contenuto che si rinnova spesso necessita di essere indicizzato più frequentemente rispetto ad un contenuto più statico, per cui le indicizzazioni possono essere pianificate con frequenze differenti in base alla variabilità del contenuto delle Site Collection.

Backup

Per il backup vale quanto detto in precedenza per il crawling: che si tratti di un backup del database, di un'esportazione tramite powershell o di un backup della macchina virtuale, la raccomandazione è di pianificarlo in giorni ed orari di scarso o (meglio) nullo utilizzo.

Pillole di Sharepoint

martedì 5 gennaio 2016