Componenti dell'architettura logica (SharePoint Server 2010)
Si applica a: SharePoint Foundation 2010, SharePoint Server 2010
Ultima modifica dell'argomento: 2016-11-30
Nella progettazione di un'architettura logica i componenti possono essere disposti in numerosi modi. A ogni componente sono associate opportunità diverse relative alla condivisione e all'isolamento. Prima di iniziare la progettazione di un'architettura logica, è necessario tenere in considerazione gli aspetti seguenti:
Obiettivi di condivisione e di isolamento.
Compromessi da valutare per ogni scelta.
In ogni sezione del presente articolo viene descritto un componente specifico di un'architettura logica. Per ogni componente vengono esaminati fattori diversi, ad esempio la capacità, la condivisione e l'isolamento, gli elementi configurabili, l'amministrazione e i suggerimenti per la pianificazione.
Contenuto dell'articolo:
Server farm
Applicazioni di servizio
Pool di applicazioni
Applicazioni Web
Aree
Criteri per un'applicazione Web
Database del contenuto
Raccolte siti
Siti
Raccolte siti con nome basato sull'host
Siti personali
Server farm
Una server farm rappresenta l'elemento principale di una progettazione. Server farm singole consentono di implementare l'isolamento fisico.
Sul numero delle server farm necessarie possono influire diversi criteri determinati dall'organizzazione, ad esempio:
Un utilizzo intenso dei servizi potrebbe giustificare una o più farm dedicate.
Divisioni operative distinte delle responsabilità.
Fonti di finanziamento dedicate.
Posizioni dei data center distinte.
Requisiti di settore per l'isolamento fisico tra i siti.
È possibile tuttavia soddisfare numerosi requisiti di isolamento in un'unica server farm. È possibile ad esempio utilizzare pool di applicazioni IIS (Internet Information Services) con identità di processo diverse per ottenere l'isolamento a livello di processo sia per i siti che per le applicazioni di servizio.
Oltre ai requisiti di isolamento per cui potrebbero essere necessarie più server farm, un'organizzazione può implementare più server farm per soddisfare gli obiettivi relativi a prestazioni e scalabilità, i requisiti relativi alle licenze o le esigenze di un ambiente di pubblicazione.
Applicazioni di servizio
Un'applicazione di servizio offre una risorsa che può essere condivisa tra i siti di una farm o, in alcuni casi, tra più farm.
In SharePoint Server 2010, i servizi non sono contenuti in un provider di servizi condivisi. L'infrastruttura che ospita i servizi è infatti stata spostata in Microsoft SharePoint Foundation 2010 e la configurazione delle offerte di servizi è molto più flessibile. Singoli servizi possono essere configurati separatamente e terze parti possono aggiungere servizi alla piattaforma.
È possibile distribuire soltanto i servizi necessari in una farm. I servizi distribuiti vengono chiamati applicazioni di servizio.
Le applicazioni di servizio sono associate ad applicazioni Web. Ogni applicazione di servizio può essere configurata in modo diverso:
Le applicazioni Web possono essere configurate in modo da utilizzare soltanto i servizi necessari, anziché l'intero insieme dei servizi distribuiti.
È possibile distribuire più istanze dello stesso servizio in una farm e assegnare nomi univoci alle applicazioni di servizio risultanti.
È possibile condividere le applicazioni di servizio tra più applicazioni Web all'interno della stessa farm.
Alcune applicazioni di servizio possono essere condivise tra diverse farm.
Capacità
Non esiste alcun limite consigliato al numero di applicazioni di servizio in un'unica farm.
Condivisione e isolamento
È possibile condividere le applicazioni di servizio in due modi:
Condividendo l'applicazione di servizio e i dati del servizio. Questo è il comportamento predefinito per i servizi condivisi tra diverse applicazioni Web. I risultati della ricerca, ad esempio, vengono condivisi tra le applicazioni Web che utilizzano la stessa applicazione di ricerca.
Condividendo solo l'applicazione di servizio, ma isolando i dati tramite la distribuzione del servizio in modalità partizionata. In un ambiente ospitato, ad esempio, è possibile distribuire applicazioni di servizio in modalità partizionata utilizzando Windows PowerShell. I dati di ogni tenant vengono archiviati in una partizione separata nel database del servizio. L'ID sottoscrizione di un tenant viene utilizzato per mappare i dati del servizio del tenant ai relativi siti. Se ad esempio si distribuisce il servizio di ricerca in modalità partizionata, ogni tenant potrà visualizzare soltanto i risultati della ricerca per il proprio contenuto.
Nota
Non tutte le applicazioni di servizio supportano il partizionamento.
Al contrario, è possibile isolare le applicazioni di servizio in due modi:
Distribuendo più applicazioni di servizio in pool di applicazioni separati per ottenere l'isolamento dei processi dei servizi e dei dati dei servizi. Un team responsabile dell'amministrazione finanziaria potrebbe ad esempio giustificare un'applicazione del servizio di integrazione applicativa dei dati separata e dedicata.
Distribuendo i servizi in modalità partizionata. Questo approccio funziona in modo ottimale in ambienti ospitati in cui i dati dei servizi non verranno mai condivisi dai tenant. Potrebbe tuttavia rivelarsi non attuabile in ambienti caratterizzati da una combinazione di esigenze di isolamento e condivisione dei dati dei servizi.
Se necessario, è possibile isolare le applicazioni di servizio distribuendole in pool di applicazioni separati in modo da ottenere l'isolamento dei processi. I pool di applicazioni costituiscono tuttavia una risorsa limitata e l'utilizzo di un numero troppo elevato di pool di applicazioni può influire sulle prestazioni della farm. Per ulteriori informazioni, vedere la sezione Application pools in questo articolo.
Elementi configurabili
Nella tabella seguente sono riportati gli elementi configurabili utili ai fini dell'isolamento e della condivisione.
Elemento |
Descrizione |
Gruppo predefinito |
Per impostazione predefinita, tutte le applicazioni di servizio sono incluse nel gruppo predefinito. È possibile aggiungere e rimuovere le applicazioni di servizio nel gruppo predefinito in qualsiasi momento, ad esempio quando se ne crea una. Quando si crea un'applicazione Web, è possibile selezionare il gruppo predefinito oppure creare un gruppo personalizzato di servizi. Per creare un gruppo personalizzato di servizi, selezionare solo le applicazioni di servizio che si desidera vengano utilizzate dall'applicazione Web. |
Connessione (proxy) |
Quando si crea un'applicazione di servizio, viene creata contemporaneamente una connessione per l'applicazione di servizio. Una connessione è un'entità virtuale che connette le applicazioni Web alle applicazioni di servizio. Alcune applicazioni di servizio, ad esempio il servizio metadati gestiti, archiviano impostazioni nelle connessioni. In Windows PowerShell, le connessioni sono denominate proxy. |
Autorizzazioni applicazioni di servizio |
È possibile delegare la gestione delle applicazioni di servizio ad altri utenti concedendo le autorizzazioni per una o più applicazioni di servizio. |
Posizioni attendibili host siti personali |
In organizzazioni in cui vengono distribuite più applicazioni di servizio profili utente, questa caratteristica consente agli utenti di creare un sito personale nella posizione specifica per il loro profilo, impedendo contemporaneamente la creazione di più siti personali nell'organizzazione. |
Amministrazione
La configurazione e la gestione delle applicazioni di servizio possono essere delegate ad amministratori specializzati nella gestione di singoli servizi, ad esempio di ricerca, profili utente e metadati gestiti.
In un ambiente ospitato, i tenant possono gestire alcune impostazioni dei servizi per la rispettiva organizzazione.
Suggerimenti per la pianificazione
Configurare le applicazioni di servizio per condividere le risorse tra più applicazioni Web o per isolare il contenuto.
È possibile ad esempio unire più siti che risiedono in applicazioni Web e pool di applicazioni diversi condividendo i servizi nel gruppo di proxy predefinito per implementare la condivisione della tassonomia, del tipo di contenuto e dei profili in una rete Intranet. In questo modo è possibile realizzare la personalizzazione e la standardizzazione a livello aziendale in numerosi siti e applicazioni. Tale scelta rappresenta inoltre un esempio di equilibrio tra l'isolamento dei processi (implementando applicazioni Web e pool di applicazioni distinti) e la necessità aziendale di condividere informazioni e utilizzare dati dei profili tra le applicazioni.
È inoltre possibile configurare le applicazioni di servizio per migliorare gli obiettivi di isolamento complessivi. L'utilizzo di un insieme di servizi dedicato per la collaborazione tra partner, ad esempio, assicura che gli utenti partner non possano accedere a informazioni riservate o eseguire ricerche in tali informazioni all'interno dell'ambiente Intranet. Per configurare singoli servizi in modo da isolare ulteriormente il contenuto tra le raccolte siti, è ad esempio possibile eseguire le operazioni seguenti:
Limitare gli ambiti di ricerca alle singole raccolte siti.
Configurare il servizio profili utente in modo da visualizzare soltanto gli utenti appartenenti alla stessa unità organizzativa in Servizi di dominio Active Directory.
Utilizzare lo strumento da riga di comando Stsadm per configurare l'opzione Selezione utenti in modo da visualizzare solo gli utenti membri della raccolta siti.
Quando si definisce la strategia per i servizi per un'organizzazione, tenere in considerazione le modalità in cui è possibile configurare i singoli servizi per migliorare gli obiettivi di condivisione o di isolamento complessivi.
Quando si definisce una strategia per i servizi per un ambiente host, determinare quali servizi dovranno essere disponibili e partizionati.
Pool di applicazioni
In Internet Information Services (IIS) 7.0 un pool di applicazioni è un gruppo di uno o più URL gestiti da un processo di lavoro o un insieme di processi di lavoro.
Quando si creano raccolte siti e servizi in Prodotti SharePoint 2010, è possibile selezionare un pool di applicazioni da utilizzare oppure crearne uno nuovo. A ogni pool di applicazioni sono associati uno specifico processo di lavoro e un'identità distinta (account di sicurezza) che impedisce l'interazione tra due processi.
Capacità
L'overhead di memoria per un pool di applicazioni è di 30-50 megabyte (MB) più la memoria necessaria per le applicazioni in esecuzione nello spazio di processo del pool di applicazioni. Le diverse esigenze delle applicazioni in genere determinano per un pool di applicazioni un utilizzo di memoria di 800 MB o superiore. Il limite per il numero di pool di applicazioni è influenzato dalla memoria disponibile nel sistema e viene stabilito dai due fattori seguenti:
Memoria indirizzabile disponibile.
Quantità di memoria utilizzata dalle applicazioni in esecuzione nel pool di applicazioni.
In base alle linee guida per ottenere prestazioni accettabili, è consigliabile utilizzare un numero di pool di applicazioni uguale o minore di otto.
Condivisione e isolamento
I pool di applicazioni IIS consentono di eseguire più siti nello stesso computer server, mantenendo tuttavia i relativi processi di lavoro e identità. In questo modo è possibile evitare un exploit in un sito che consente a chi effettua un attacco di inserire malware in grado di attaccare siti in pool di applicazioni diversi. Questa strategia, soprattutto, isola il codice che introduce problemi di memoria o di altro tipo, impedendo così al codice problematico di influire su tutte le applicazioni.
Elementi configurabili
Per motivi di sicurezza e isolamento è consigliabile, se necessario, utilizzare un'identità del pool di applicazioni distinta per ogni pool.
Amministrazione
Se per ogni pool di applicazioni vengono utilizzate identità distinte, è necessario gestire ogni identità.
Suggerimenti per la pianificazione
In termini pratici, prendere in considerazione l'utilizzo di un pool di applicazioni dedicato per ognuno degli scopi seguenti:
Separazione del contenuto autenticato dal contenuto principalmente anonimo.
Isolamento di applicazioni che archiviano password e interazione con applicazioni aziendali esterne, ad esempio connessioni al servizio di integrazione applicativa dei dati.
Applicazioni Web
Un'applicazione Web è un sito Web IIS creato e utilizzato da Prodotti SharePoint 2010. È possibile estendere un'applicazione Web fino a quattro volte per creare quattro aree aggiuntive in Prodotti SharePoint 2010, ottenendo come risultato fino a cinque siti Web IIS associati a una singola applicazione Web, ognuno associato a una diversa area. A ogni applicazione Web può essere assegnato un nome di dominio univoco. Per ulteriori informazioni, vedere la sezione Zones in questo articolo.
Condivisione e isolamento
A ogni applicazione Web è associato un nome di dominio univoco, che consente di impedire attacchi di cross-site scripting (XSS).
Elementi configurabili
Nella tabella seguente sono riportati gli elementi configurabili utili ai fini dell'isolamento e della condivisione.
Elemento |
Descrizione |
Applicazioni di servizio |
Le applicazioni di servizio sono associate ad applicazioni Web. Quando si crea un'applicazione Web, è possibile selezionare il gruppo di proxy predefinito (insieme predefinito di applicazioni di servizio) oppure specificare per l'applicazione Web un insieme personalizzato di applicazioni di servizio. Tutti i siti presenti in un'applicazione Web utilizzano i servizi delle stesse applicazioni di servizio. Un'applicazione di servizio può implementare servizi per più di un'applicazione Web, consentendo pertanto la condivisione di contenuto e dati dei profili tra le applicazioni stesse. |
Aree |
In un'applicazione Web è possibile creare fino a cinque aree, che consentono di applicare condizioni di accesso e dei criteri diverse per gruppi di utenti di dimensioni elevate. |
Criteri per l'applicazione Web |
Creare criteri per applicare autorizzazioni in una o più aree di un'applicazione Web. È possibile creare criteri per un utente o un gruppo di utenti specifico. Per ulteriori informazioni, vedere la sezione Criteri per un'applicazione Web in questo articolo. |
Amministrazione
Le attività di amministrazione continuative non sono significative.
Suggerimenti per la pianificazione
È in generale consigliabile utilizzare applicazioni Web dedicate per:
Separare il contenuto disponibile agli utenti anonimi da quello disponibile agli utenti autenticati.
Isolare gli utenti. È possibile ad esempio garantire che i partner non possano accedere al contenuto Intranet inserendo siti partner in un'applicazione Web distinta.
Applicare autorizzazioni tramite criteri. È ad esempio possibile creare criteri per negare in modo esplicito l'accesso in scrittura a uno o più gruppi di utenti. I criteri per un'applicazione Web vengono applicati indipendentemente dalle autorizzazioni configurate nei singoli siti o documenti all'interno dell'applicazione Web.
Ottimizzare le prestazioni dei database. Le applicazioni offrono prestazioni migliori se vengono inserite in database del contenuto con altre applicazioni con caratteristiche dei dati simili. Ad esempio, le caratteristiche dei dati di siti personali includono in genere un numero elevato di siti di dimensioni contenute. Al contrario, i siti del team comprendono in genere un numero limitato di siti di dimensioni molto grandi. Se questi due tipi di siti vengono inseriti in applicazioni Web distinte, i database risultanti saranno composti da dati con caratteristiche simili, con conseguente ottimizzazione delle prestazioni dei database.
Ottimizzare la gestibilità. Poiché la creazione di applicazioni Web separate determina la creazione di siti e database distinti, è possibile implementare limiti diversi per il Cestino, la scadenza e le dimensioni di ogni sito e negoziare contratti di servizio differenti. È possibile ad esempio consentire una quantità di tempo maggiore per ripristinare siti di importanza non critica per l'azienda.
Aree
Le aree rappresentano percorsi logici diversi (URL) per ottenere l'accesso alla stessa applicazione Web. All'interno di ogni applicazione Web è possibile creare fino a cinque aree utilizzando uno dei nomi di area disponibili, ovvero Predefinita, Intranet, Internet, Personalizzata o Extranet. Ogni nome può essere selezionato una sola volta per applicazione Web. Ogni area è rappresentata da un diverso sito Web in IIS.
L'area Predefinita è quella creata inizialmente al momento della creazione di un'applicazione Web. Le altre aree vengono create estendendo un'applicazione Web.
Capacità
In un'applicazione Web è possibile creare un numero massimo di cinque aree. Le aree vengono coordinate in genere tra applicazioni Web in modo che le aree con lo stesso nome siano configurate per gli stessi utenti.
Condivisione e isolamento
Le aree consentono di partizionare gli utenti in base agli elementi seguenti:
Tipo di autenticazione: ogni area può essere configurata in modo da utilizzare un provider di autenticazione diverso, consentendo la condivisione dello stesso contenuto tra più società partner.
Area di rete: ogni area può essere configurata per supportare utenti che accedono da un'area di rete diversa, ad esempio Extranet o Internet.
Autorizzazioni concesse tramite criteri: è possibile consentire o negare in modo esplicito l'accesso in lettura o in scrittura al contenuto per ogni area in base a un account utente o a un account di gruppo.
Elementi configurabili
Nella tabella seguente sono riportati gli elementi configurabili utili ai fini dell'isolamento e della condivisione.
Elemento |
Descrizione |
Provider di autenticazione |
Ogni area può essere configurata in modo da utilizzare un provider di autenticazione diverso. |
Accesso anonimo |
Attivare o disattivare l'accesso anonimo per ogni area. |
SSL (Secure Sockets Layer) |
Attivare o disattivare SSL per ogni area. |
URL pubblico e mapping di accesso alternativo |
Specificare il nome di dominio che gli utenti dovranno digitare per accedere al contenuto dell'applicazione Web. In alternativa, utilizzare mapping di accesso alternativo per eseguire il mapping di URL descrittivi o appropriati per l'area a URL predefiniti (nome server e porta) per ogni area. Il mapping di accesso alternativo supporta la terminazione off-box del protocollo SSL. Tale terminazione si verifica quando un server proxy termina una richiesta SSL e successivamente la inoltra a un server Web tramite HTTP. In questo caso è possibile configurare i mapping di accesso alternativo per restituire tali richieste tramite SSL, mantenendo pertanto la comunicazione protetta tra il client e il server proxy. |
Criteri per l'applicazione Web |
Creare un insieme univoco di criteri per ogni area dell'applicazione Web. Se si dispone di un gruppo speciale di utenti per cui è necessario definire eccezioni per i criteri di sicurezza globale, prendere in considerazione l'utilizzo di un'area separata per la gestione di tali utenti. |
Amministrazione
Se si utilizza il mapping di accesso alternativo, tenere in considerazione che per tutti gli URL pubblici sono necessarie voci DNS (Domain Name System) per eseguirne il mapping all'indirizzo IP del servizio di bilanciamento del carico per la farm.
Suggerimenti per la pianificazione
Per la progettazione delle aree alcune decisioni chiave relative alla progettazione e alla configurazione delle aree seguenti determinano la buona riuscita della distribuzione:
Area Predefinita
Aree per l'accesso esterno.
Nelle sezioni seguenti vengono descritti alcuni suggerimenti per la pianificazione e alcuni requisiti relativi alle aree, inclusa l'area Predefinita.
Poiché vengono inviati messaggi di posta elettronica amministrativi con collegamenti relativi all'area Predefinita, in cui sono inclusi messaggi di posta elettronica ai proprietari di siti che stanno raggiungendo i limiti di quota, gli utenti che ricevono questo tipo di messaggi e di avvisi devono essere in grado di accedere ai collegamenti tramite l'area Predefinita. Questo è particolarmente importante per i proprietari di siti.
Le raccolte siti con nome basato sull'host sono disponibili solo tramite l'area Predefinita. Per accedere alle raccolte siti con nome basato sull'host, gli utenti devono utilizzare l'area Predefinita.
L'area Predefinita deve rappresentare l'area più protetta poiché quando la richiesta di un utente non può essere associata a un'area vengono applicati l'autenticazione e i criteri di tale area.
In un ambiente Extranet la progettazione delle aree è importante per i due motivi seguenti:
Le richieste degli utenti possono essere avviate da numerose reti diverse, ad esempio la rete interna, la rete della società partner o Internet.
Gli utenti utilizzano contenuto in più applicazioni Web. Un ambiente Intranet ad esempio potrebbe includere siti ospitati in diverse applicazioni Web e i dipendenti potrebbero inoltre disporre dell'accesso sia al contenuto Intranet che al contenuto di collaborazione della società partner.
In un ambiente Extranet verificare che vengano seguiti i principi di progettazione seguenti:
Configurare le aree in più applicazioni Web in modo che venga eseguito il mirroring reciproco. La configurazione dell'autenticazione e gli utenti previsti devono corrispondere. I criteri associati alle aree possono tuttavia differire tra le applicazioni Web. Assicurarsi ad esempio che l'area Intranet venga utilizzata per gli stessi dipendenti in tutte le applicazioni Web. In altri termini, non configurare l'area Intranet per i dipendenti interni in un'applicazione Web e per i dipendenti remoti in un'altra.
Configurare i mapping di accesso alternativo in modo corretto e accurato per ogni area e risorsa.
Criteri per un'applicazione Web
Un criterio definito per un'applicazione Web consente di applicare le autorizzazioni a tutto il contenuto di un'applicazione Web, consentendo di impostare criteri di sicurezza per gli utenti a livello dell'applicazione stessa. Le autorizzazioni applicate tramite criteri sostituiscono tutte le altre impostazioni di sicurezza configurate per i siti e il contenuto.
È possibile configurare i criteri in base a utenti o gruppi di utenti di Servizi di dominio Active Directory, ma non in base a gruppi di SharePoint ed è possibile inoltre definire un criterio per l'applicazione Web in generale o solo per un'area specifica.
Capacità
Non sono presenti limitazioni della capacità da applicare ai criteri per le applicazioni Web.
Condivisione e isolamento
Un criterio definito per un'applicazione Web consente di impostare autorizzazioni in base agli utenti e all'area tramite la quale accedono al contenuto.
Utilizzando un criterio è possibile ad esempio eseguire le operazioni seguenti:
Consentire al personale del supporto tecnico di accedere a tutto il contenuto.
Negare l'accesso in scrittura ai partner oppure ai fornitori.
Negare l'accesso ai dati sicuri a un gruppo di utenti indipendentemente dalla configurazione delle autorizzazioni eseguita dai proprietari del sito.
Garantire che un account per la ricerca per indicizzazione sia in grado di eseguire la ricerca per indicizzazione di tutto il contenuto.
Elementi configurabili
Nella tabella seguente sono riportati gli elementi configurabili utili ai fini dell'isolamento e della condivisione.
Elemento |
Descrizione |
Criteri utenti |
Creare criteri applicabili a utenti o gruppi di utenti:
È possibile modificare i livelli di autorizzazione predefiniti oppure creare nuovi livelli di autorizzazione facendo clic su Criteri di autorizzazione al momento della creazione dei criteri in Amministrazione centrale. |
Criteri accesso anonimo |
Se per l'applicazione Web o una o più aree è attivato l'accesso anonimo, è possibile creare criteri applicabili a tutti gli utenti anonimi. Le impostazioni predefinite dei criteri sono le seguenti:
I livelli dei criteri per gli utenti anonimi non possono essere modificati. |
Criteri di autorizzazione |
Modificare le specifiche autorizzazioni associate a uno dei livelli di autorizzazione predefiniti oppure creare un nuovo livello di criteri di autorizzazione. È inoltre possibile specificare le particolari autorizzazioni responsabili della concessione o della negazione per raccolte siti e siti. Dopo aver creato un nuovo livello di criteri di autorizzazione, è possibile creare criteri utente che utilizzano i criteri di autorizzazione. |
Amministrazione
Le attività di amministrazione continuative dei criteri per le applicazioni Web non sono significative.
Suggerimenti per la pianificazione
Poiché i criteri vengono gestiti in modo centralizzato, è consigliabile utilizzarli per gestire gruppi di utenti di grandi dimensioni, anziché singoli utenti.
Database del contenuto
Per impostazione predefinita, tutto il contenuto di un'applicazione Web viene archiviato in un database del contenuto. È possibile separare il contenuto in più database a livello di raccolta siti. In un database del contenuto possono essere presenti più raccolte siti, mentre una raccolta siti non può estendersi su più database. Il backup e il ripristino dei siti vengono eseguiti a livello di database del contenuto.
Capacità
In base alle linee guida per ottenere prestazioni accettabili, è consigliabile implementare un massimo di 100 database del contenuto per ogni applicazione Web.
Condivisione e isolamento
La pianificazione di database consente di ottimizzare l'efficienza (più raccolte siti che condividono un database) o l'isolamento (un database per ogni raccolta siti).
Per ottenere efficienza a livello di scalabilità, è necessario gestire i database fino alle dimensioni di destinazione massime. In questo caso configurare le impostazioni del database per aggiungere nuove raccolte siti ai database esistenti fino a quando non viene raggiunto il numero massimo di raccolte. Per calcolare il numero massimo di raccolte siti, valutare il valore medio o massimo delle dimensioni delle raccolte diviso il valore delle dimensioni di destinazione massime per il database. Questo metodo funziona in modo ottimale quando si prevede un numero elevato di raccolte siti di dimensioni ridotte, ad esempio i siti personali.
Per ottenere l'isolamento del contenuto tra team o progetti, limitare un database a un'unica raccolta siti. Questo approccio consente di gestire in modo indipendente il contenuto di team singoli. È possibile ad esempio gestire in modo indipendentemente il database di ogni team per eseguire il backup, il ripristino o la migrazione. In questo modo è possibile inoltre implementare contratti di servizio diversi per team o progetti distinti nonché gestire il contenuto durante tutto il ciclo di vita di un progetto, archiviandolo ad esempio quando il progetto viene completato.
Elementi configurabili
Nella tabella seguente sono riportati gli elementi configurabili utili ai fini dell'isolamento e della condivisione.
Elemento |
Descrizione |
Server database |
Specificare il computer SQL Server in cui viene creato un database del contenuto. |
Server di failover |
È possibile scegliere di associare un database del contenuto a un server di failover specifico utilizzato insieme al mirroring di database di SQL Server. |
Impostazioni della capacità |
È possibile specificare il numero di siti che può essere creato prima della generazione di un avviso e il numero massimo di siti che può essere creato in ogni database. |
Amministrazione
Un piano di amministrazione del database semplice da gestire consente di bilanciare il numero di database con le risorse necessarie per gestire i database.
L'amministrazione di database include le operazioni seguenti:
Creazione di nuovi database per i nuovi siti del team o per nuove raccolte siti per cui sono necessari database dedicati.
Monitoraggio delle dimensioni dei database e creazione di nuovi database quando vengono raggiunte le dimensioni di destinazione.
Backup e ripristino dei database.
Suggerimenti per la pianificazione
Scegliere uno dei due metodi seguenti:
Stabilire le dimensioni di destinazione per i database del contenuto con valori di soglia degli avvisi per le dimensioni appropriati. Creare nuovi database quando si raggiungono i valori di soglia degli avvisi per le dimensioni. Se si utilizza questo approccio, le raccolte siti vengono aggiunte automaticamente al database o ai database disponibili esclusivamente in base alle dimensioni di destinazione.
Associare raccolte siti a database del contenuto specifici. Questo approccio consente di inserire una o più raccolte siti in un database dedicato che può essere gestito in modo indipendente dagli altri.
Se si desidera associare le raccolte siti a database del contenuto specifici, è possibile eseguire le operazioni seguenti:
Utilizzare Windows PowerShell per creare una raccolta siti in un nuovo database.
Applicare le impostazioni seguenti nella pagina Gestisci impostazioni database del contenuto nel sito Web Amministrazione centrale SharePoint:
Numero di siti consentiti prima della generazione di un avviso = 0
Numero massimo di siti che è possibile creare nel database = 1
Aggiungere un gruppo di raccolte siti a un database dedicato completando i passaggi seguenti:
Aggiungere un database del contenuto per l'applicazione Web e verificare che lo stato del database sia impostato su Pronto.
Impostare lo stato di tutti gli altri database su Offline. Mentre i database del contenuto sono offline, non è possibile creare nuove raccolte siti. Le raccolte siti esistenti nei database offline sono tuttavia accessibili per le operazioni sia di lettura che di scrittura.
Creare le raccolte siti. Verranno aggiunte automaticamente al database online.
Reimpostare lo stato di tutti gli altri database su Pronto.
Raccolte siti
Una raccolta siti è un insieme di siti Web con lo stesso proprietario e in cui le impostazioni di amministrazione sono condivise. Ogni raccolta siti contiene un sito Web principale e, generalmente, uno o più siti secondari.
Capacità
In base alle linee guida per ottenere prestazioni accettabili, è consigliabile implementare un numero di raccolte siti inferiore a 50.000 per ogni database del contenuto. Un numero di circa 10.000 raccolte siti può tuttavia influire sulle prestazioni. La realizzazione della scalabilità orizzontale mediante la distribuzione di raccolte siti tra più server di database consente di aumentare la capacità di archiviazione e la velocità effettiva.
Condivisione e isolamento
Le raccolte siti comportano diverse opportunità di condivisione e di isolamento che influiscono sulle autorizzazioni, lo spostamento e la distribuzione di caratteristiche.
Gli elementi seguenti possono essere condivisi in una raccolta siti, ma non possono essere condivisi tra più raccolte siti (ad eccezione degli elementi archiviati in un file system, come le caratteristiche nella directory _layouts):
Pagine master
Layout di pagina
Immagini
Modelli di sito
Le autorizzazioni e lo spostamento vengono inoltre isolati a livello di raccolta siti nei modi seguenti:
I siti secondari di una raccolta siti possono ereditare autorizzazioni dal sito principale.
Le raccolte siti non possono ereditare le autorizzazioni da altre raccolte siti.
Non è disponibile uno spostamento predefinito da una raccolta siti a un'altra.
In SharePoint Server 2010 infine i risultati di ricerca vengono aggregati tra le raccolte siti in base alle autorizzazioni dell'utente, indipendentemente dal numero di raccolte siti o di database (a seconda degli ambiti di ricerca).
È importante tenere presente che, sebbene le autorizzazioni vengano applicate a singoli siti, questi ultimi sono comunque vulnerabile ad attacchi di cross-site scripting (XSS) da altri siti all'interno del dominio.
Elementi configurabili
Nella tabella seguente sono riportati gli elementi configurabili utili ai fini dell'isolamento e della condivisione.
Elemento |
Descrizione |
Amministratore della raccolta siti |
È possibile specificare un utente come amministratore della raccolta siti principale e un altro come amministratore della raccolta siti secondaria. In Amministrazione centrale non è possibile immettere più di un account né un account di gruppo per tali ruoli. |
Modello di sito |
Un modello di sito determina gli elenchi e le caratteristiche che saranno disponibili nel nuovo sito. Molti aspetti di un sito possono essere personalizzati dopo la creazione. Non è tuttavia possibile modificare il modello di sito dopo che il sito è stato creato. |
Modello quote |
È possibile applicare un modello quote per limitare le risorse utilizzate per una raccolta siti. Sono disponibili i modelli seguenti:
|
Nella tabella seguente sono riportati gli elementi configurabili in una raccolta siti utili ai fini dell'isolamento e della condivisione.
Elemento |
Descrizione |
Amministratori della raccolta siti |
È possibile specificare più account utente come amministratori della raccolta siti. Non è possibile aggiungere account di gruppo. |
Livello di autorizzazione |
Aggiungere gli account utente e di gruppo alle raccolte siti e specificare i livelli di autorizzazione per ognuno di essi. |
Amministrazione
Per la creazione delle raccolte siti non sono necessarie voci DNS (a meno che non vengano create raccolte siti con nome basato sull'host) e pertanto questa operazione può essere facilmente automatizzata o delegata agli utenti. È possibile creare raccolte siti per i siti del team in modo centralizzato oppure consentire agli utenti di creare le proprie raccolte siti utilizzando Gestione siti in modalità self-service.
L'utilizzo di un database dedicato per una raccolta siti consente di eseguire il backup e il ripristino a livello di raccolta siti.
Suggerimenti per la pianificazione
Le raccolte siti rappresentano il collegamento tra l'architettura logica e l'architettura delle informazioni. Quando si progettano le raccolte siti, tenere in considerazione le due attività seguenti:
Progettazione di URL coerenti all'interno dell'organizzazione.
Creazione di divisioni logiche del contenuto.
A meno che non vengano utilizzate raccolte siti con nome basato sull'host, ogni applicazione Web deve disporre di un'unica raccolta siti a livello radice in modo che il percorso URL relativo ai siti che risiedono nell'applicazione sia univoco. Questo requisito deve essere rispettato anche se si implementano più aree in un'applicazione Web. Per ulteriori informazioni, vedere la sezione Host-named site collections in questo articolo.
Molte organizzazioni pianificano l'implementazione di più raccolte siti in un'applicazione Web affinché siano utilizzate da team o divisioni diversi all'interno dell'organizzazione. Gli obiettivi di progettazione comuni sono i seguenti:
Mantenere una raccolta siti distinta e indipendente per ogni team.
Creare un URL univoco per ogni team.
Isolare il contenuto tra i team.
Per raggiungere questi obiettivi, è possibile utilizzare percorsi gestiti per inserire più raccolte siti principali in un'applicazione Web. Mediante la definizione di percorsi gestiti è possibile specificare le parti dello spazio dei nomi URL di un'applicazione Web da utilizzare per una raccolta siti. È possibile specificare che una raccolta siti o più raccolte siti esistano in corrispondenza di un percorso distinto sotto il sito radice. Senza percorsi gestiti, tutti i siti creati sotto la raccolta siti principale fanno parte di tale raccolta.
È possibile creare i due tipi di percorsi gestiti seguenti:
Inclusione esplicita: raccolta siti con l'URL specifico assegnato. Un'inclusione esplicita viene assegnata a un'unica raccolta siti. È possibile associare ognuna di queste raccolte siti a un database del contenuto diverso qualora si desideri gestire l'aumento delle dimensioni e disporre dell'opportunità di eseguire il backup e il ripristino di tali siti separatamente. Un esempio di URL per una raccolta siti creata tramite questo metodo è http://fabrikam/risorseumane. Il limite alle raccolte siti create con un'inclusione esplicita è di circa 100 raccolte in un'applicazione Web. 20 è tuttavia un limite massimo operativo valido. Se nell'organizzazione è necessario un numero di raccolte siti maggiore, utilizzare un'inclusione di caratteri jolly.
Inclusione di caratteri jolly: percorso aggiunto all'URL. Tale percorso indica che tutti i siti specificati direttamente dopo il nome del percorso sono raccolte siti univoche. Questa opzione viene in genere utilizzata per le applicazioni che supportano Gestione siti in modalità self-service, ad esempio siti personali o siti creati per la collaborazione tra partner. URL di esempio per le raccolte siti create con questo metodo sono http://webpartner/siti/progetto1 e http://webpartner/siti/progetto2. In questi esempi "http://webpartner" rappresenta la raccolta siti a livello radice e "/siti" rappresenta l'inclusione di caratteri jolly.
Siti
Un sito è costituito da una o più pagine Web correlate e altri elementi (come elenchi, raccolte e documenti) ospitati in una raccolta siti.
Capacità
In base alle linee guida per ottenere prestazioni accettabili, è consigliabile implementare meno di 250.000 siti per ogni raccolta siti. È possibile creare un numero complessivo molto elevato di siti Web tramite l'annidamento dei siti secondari. Un numero elevato di siti secondari annidati, tuttavia, può influire significativamente sul tempo necessario per l'aggiornamento dei siti. Un obiettivo operativo valido è costituito da 5.000 siti all'interno di una raccolta siti.
Condivisione e isolamento
In una raccolta siti lo spostamento da un sito secondario a un altro è predefinito. Non è invece disponibile uno spostamento predefinito da una raccolta siti a un'altra.
Analogamente alle raccolte siti, i siti distinti sono vulnerabili ad attacchi di cross-site scripting (XSS) da altri siti all'interno del dominio.
Elementi configurabili
Da ogni sito è possibile aggiungere account utente o di gruppo al gruppo dei proprietari di tale sito.
Amministrazione
Per il backup e il ripristino di singoli siti è possibile utilizzare diversi strumenti.
Raccolte siti con nome basato sull'host
Le raccolte siti con nome basato sull'host rappresentano un'alternativa quando si desidera creare più raccolte siti a livello radice in un'applicazione Web. Gli amministratori delle organizzazioni host possono ad esempio utilizzare raccolte siti con nome basato sull'host per creare più siti con nome basato sul dominio.
Per creare le raccolte siti con nome basato sull'host non è necessario utilizzare alcuna modalità speciale, ad esempio la modalità intestazione host. Tali raccolte vengono create tramite Windows PowerShell. Con Windows PowerShell è inoltre possibile utilizzare percorsi gestiti con le raccolte siti con nome basato sull'host (New-SPManagedPath –HostHeader).
Le raccolte siti con nome basato sull'host offrono maggiore controllo sugli URL, ma sono disponibili solo nell'area Predefinita. Gli account utente configurati per l'autenticazione tramite altre aree non possono accedere alle raccolte siti con nome basato sull'host.
In Prodotti SharePoint 2010 le raccolte siti con nome basato sull'host supportano la terminazione off-box di SSL. È tuttavia consentita la modifica off-box soltanto dello schema di protocollo (http:// o https://). Il server proxy inverso non può modificare il nome host o il numero di porta, tranne per il passaggio dalla porta SSL predefinita alla porta HTTP predefinita.
Capacità
È possibile creare fino a 100.000 raccolte siti con nome basato sull'host in un unico sito Web IIS.
Condivisione e isolamento
I nomi di dominio indipendenti risultanti da raccolte siti con nome basato sull'host consentono di impedire gli attacchi di cross-site scripting (XSS) tra due siti.
Amministrazione
Di seguito vengono indicate le attività amministrative da eseguire per le raccolte siti con nome basato sull'host:
Aggiunta di raccolte siti con nome basato sull'host tramite Windows PowerShell.
Assegnazione di una voce DNS distinta per ogni raccolta siti con nome basato sull'host.
Siti personali
I siti personali sono siti di SharePoint particolari personalizzati per ogni utente e abilitati per impostazione predefinita nell'ambito del servizio profili utente. Ogni utente in un'organizzazione può creare un sito personale univoco. Per informazioni sulla capacità, la condivisione, l'isolamento e l'amministrazione, vedere la sezione Siti in precedenza in questo articolo.