Componenti dell'architettura logica
Contenuto dell'articolo:
Server farm
Provider di servizi condivisi
Pool di applicazioni IIS
Applicazioni Web
Aree
Criteri per applicazioni Web
Database del contenuto
Raccolte siti
Siti
Raccolte siti con nome basato sull'host
Siti personali
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.
Per ulteriori informazioni sull'implementazione dei componenti di un'architettura logica in un esempio di progettazione, vedere Modello di architettura logica: distribuzione aziendale.
Server farm
Sebbene tecnicamente le server farm non costituiscano un componente di architettura logica, una server farm rappresenta tuttavia 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:
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 nonché utilizzare applicazioni Web distinte per ottenere l'isolamento a livello di applicazione Web.
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à.
In Microsoft Office SharePoint Server 2007 esistono altri fattori che potrebbero determinare la distribuzione di più server farm. Potrebbe essere necessario ad esempio utilizzare più server farm per soddisfare i requisiti relativi alle licenze o per implementare un ambiente di pubblicazione. Per ulteriori informazioni, vedere Pianificare le server farm.
Provider di servizi condivisi
Un provider di servizi condivisi consente di implementare un insieme comune di servizi e dati dei servizi per un raggruppamento logico di applicazioni Web e per i siti associati relativi. I servizi e i dati dei servizi includono:
Servizi di personalizzazione, ad esempio siti personali
Gruppi di destinatari
Catalogo dati business
Excel Services
Servizio di ricerca di Office SharePoint Server
Report di utilizzo del sito
I provider di servizi condivisi sono associati ad applicazioni Web, i cui siti vengono gestiti dal provider di servizi condivisi assegnato all'applicazione stessa. Un provider di servizi condiviso può ospitare servizi per più applicazioni Web.
Capacità
È possibile creare fino a 20 provider di servizi condivisi per farm. Per ottenere prestazioni accettabili, è consigliabile creare un numero di farm uguale o minore di tre.
Condivisione e isolamento
Provider di servizi condivisi distinti consentono di implementare l'isolamento dei processi per profili, contenuto e risultati di ricerca. Per realizzare l'isolamento dei processi, è necessario che vengano soddisfatte le condizioni seguenti:
Ogni provider di servizi condivisi risiede in un pool di applicazioni IIS distinto.
Ogni provider di servizi condivisi utilizza un insieme univoco di account di servizio per eseguire i servizi che implementa, ad esempio ricerca, ricerca per indicizzazione del contenuto e importazione dei profili.
Di seguito vengono indicati i criteri più importanti che determinare il numero di provider di servizi condivisi nell'architettura logica:
Necessità di condividere il contenuto e i dati dei profili tra siti che risiedono in applicazioni Web e pool di applicazioni IIS distinti. È possibile ad esempio condividere siti personali, siti del team e contenuto pubblicato in una rete Intranet stabilendo che tali siti vengano gestiti da un unico provider di servizi condivisi.
Necessità di isolare contenuto e gruppi di destinatari in siti specifici. Se ad esempio la server farm ospita applicazioni per più classi di utenti, l'utilizzo di provider di servizi condivisi distinti può contribuire a creare l'isolamento tra tali classi.
Elementi configurabili
Nella tabella seguente sono elencati gli elementi configurabili utili ai fini dell'isolamento e della condivisione.
| Elemento | Descrizione |
|---|---|
Autorizzazioni per i servizi condivisi |
È possibile delegare la gestione dei servizi condivisi ad altri utenti concedendo le autorizzazioni per uno o più servizi condivisi. Per visualizzare e gestire i servizi condivisi, gli utenti devono inoltre disporre delle autorizzazioni per il sito Web Amministrazione servizi condivisi. |
Percorsi attendibili dei siti personali |
In organizzazioni in cui più provider di servizi condivisi implementano i siti personali, questa caratteristica consente agli utenti di creare un sito personale nel provider di servizi condivisi specifico per il loro profilo, impedendo contemporaneamente la creazione di più siti personali nell'organizzazione. Per ulteriori informazioni, vedere la sezione relativa al coordinamento dei siti personali nell'organizzazione in Progettare l'architettura dei siti personali. |
Amministrazione
La configurazione e la gestione dei provider di servizi condivisi può essere delegata ad amministratori specializzati nella gestione di servizi di questo tipo, ad esempio ricerca e definizione di gruppi di destinatari.
In un ambiente di hosting gli amministratori possono configurare un provider di servizi condivisi per cliente e consentire agli utenti di gestire i propri servizi condivisi.
Per ulteriori informazioni sulla pianificazione dei ruoli di amministrazione dei provider di servizi condivisi, vedere Pianificare i ruoli di protezione (Office SharePoint Server).
Suggerimenti per la pianificazione
Configurare i provider di servizi condivisi per migliorare la condivisione delle informazioni tra più applicazioni Web o per isolare ulteriormente il contenuto in una singola applicazione Web.
È possibile ad esempio unire più siti che risiedono in applicazioni Web e pool di applicazioni diversi in un unico provider di servizi condivisi per implementare la condivisione del contenuto e dei profili in una rete Intranet. In questo modo è possibile realizzare la personalizzazione e la ricerca 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 i provider di servizi condivisi per migliorare gli obiettivi di isolamento complessivi. L'utilizzo di un provider di servizi condivisi 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 il provider di servizi condivisi in modo da isolare ulteriormente il contenuto tra le raccolte siti, eseguire le operazioni seguenti:
Limitare gli ambiti di ricerca alle singole raccolte siti.
Utilizzare gruppi di destinatari per assegnare contenuto a determinati gruppi di utenti.
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 una strategia per i provider di servizi condivisi, tenere in considerazione le modalità in cui è possibile configurare i servizi singoli in un provider per migliorare gli obiettivi di condivisione o di isolamento complessivi.
Pool di applicazioni
Un pool di applicazioni è un raggruppamento di uno o più URL, o siti Web come vengono rappresentati in IIS, gestiti da un processo di lavoro. A ogni pool di applicazioni sono associati un processo di lavoro e un'identità propri (account di protezione) che impediscono 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. Il limite per il numero di pool di applicazioni è influenzato dalla memoria disponibile nel sistema e viene stabilito da due fattori seguenti:
Memoria indirizzabile disponibile.
Dimensioni dell'applicazione 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 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.
Elementi configurabili
Utilizzare un'identità del pool di applicazioni distinta per ogni pool.
Amministrazione
Le attività amministrative includono la gestione di identità del pool di applicazioni distinte per ogni pool.
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 anonimo.
Isolamento di applicazioni che archiviano password e interazione con applicazioni aziendali esterne, ad esempio connessioni al Catalogo dati business.
Isolamento di applicazioni per cui gli utenti hanno ampia libertà di creazione e amministrazione di siti e di collaborazione sul contenuto.
Applicazioni Web
Un'applicazione Web è un sito Web IIS creato e utilizzato da Prodotti e tecnologie SharePoint. Ogni applicazione Web è rappresentata da un sito Web diverso in IIS e a ogni applicazione Web viene assegnato un nome di dominio univoco che contribuisce a impedire attacchi di cross-site scripting (XSS).
Capacità
Ogni pagina ASP.NET genera una DLL distinta per ogni applicazione Web. Le DLL separate utilizzano memoria, limitando il numero di applicazioni Web che è possibile eseguire in un server. In base alle linee guida per ottenere prestazioni accettabili, è consigliabile implementare un numero di applicazioni Web uguale o minore di 99 per ogni provider di servizi condivisi.
Condivisione e isolamento
Raccolte e i modelli vengono registrati nel database di configurazione per server farm. È possibile specificare le applicazioni Web che li possono utilizzare.
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 elencati gli elementi configurabili utili ai fini dell'isolamento e della condivisione.
| Elemento | Descrizione |
|---|---|
Provider di servizi condivisi |
Alle applicazioni Web sono associati i provider di servizi condivisi. Tutti i siti presenti in un'applicazione Web utilizzano i servizi dello stesso provider. Un provider di servizi condivisi può implementare servizi per più di un'applicazione Web, consentendo pertanto la condivisione di contenuto e di 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 classi di utenti di dimensioni elevate. |
Criteri per l'applicazione Web |
Creare un criterio "Tutte le aree" per applicare una condizione dei criteri utilizzabile in tutte le aree dell'applicazione Web. |
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. Un'applicazione Web dedicata offre l'opportunità di applicare autorizzazioni mediante criteri utilizzando la pagina Criteri per l'applicazione Web in Amministrazione centrale. È ad esempio possibile creare un criterio 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 applicazioni Web 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.
L'area Predefinita è quella creata inizialmente al momento della creazione di 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 elencati 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. |
SSL (Secure Sockets Layer) |
Attivare o disattivare SSL per ogni area. |
URL con bilanciamento del carico 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 protezione 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.
Requisiti di configurazione dell'area Predefinita
L'area che deve essere considerata con maggiore attenzione è l'area Predefinita. Di seguito vengono indicati i requisiti per la configurazione dell'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.
Per eseguire la ricerca per indicizzazione nel contenuto, il componente di indicizzazione richiede l'accesso al contenuto almeno tramite un'area. Per impostazione predefinita, il componente di indicizzazione utilizza l'autenticazione NTLM. L'amministratore del servizio di ricerca può configurare le regole di ricerca per indicizzazione per utilizzare l'autenticazione di base o un certificato client durante la ricerca per indicizzazione in un intervallo di URL specifico. Per eseguire la ricerca per indicizzazione del contenuto, è perciò necessario che almeno una delle aree sia configurata per l'utilizzo dell'autenticazione NTLM, dell'autenticazione di base o dei certificati. Il crawler esegue inoltre il polling delle aree nell'ordine riportato di seguito fino a quando non viene individuata un'area tramite la quale eseguire l'autenticazione, ovvero area Predefinita, area Intranet, area Internet, area Personalizzata e area Extranet. Se tuttavia individua per prima un'area configurata per l'autenticazione Kerberos non configurata per l'utilizzo di una porta, ovvero la porta 80 o 443, il crawler non eseguirà l'autenticazione e non tenterà di accedere all'area successiva. Assicurarsi pertanto che la configurazione delle aree che utilizzano l'autenticazione Kerberos non impedisca al componente di indicizzazione di eseguire la ricerca per indicizzazione del contenuto. Per ulteriori informazioni sui requisiti di autenticazione correlati alla ricerca per indicizzazione del contenuto, vedere Pianificare i metodi di autenticazione (Office SharePoint Server).
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.
Configurazione di aree per un ambiente Extranet
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 protezione per gli utenti a livello dell'applicazione stessa. Le autorizzazioni applicate tramite criteri sostituiscono tutte le altre impostazioni di protezione configurate per i siti e il contenuto.
È possibile configurare i criteri in base a utenti o gruppi di utenti, 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 dell'helpdesk di accedere a tutto il contenuto.
Negare l'accesso in scrittura ai partner oppure ai fornitori.
Negare l'accesso ai dati protetti a una classe 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 elencati gli elementi configurabili utili ai fini dell'isolamento e della condivisione.
| Elemento | Descrizione |
|---|---|
Area |
Applicare un criterio a un'area specifica dell'applicazione Web, ad esempio l'area Intranet, oppure a tutte le aree dell'applicazione. |
Utenti |
Specificare gli utenti cui applicare i criteri utilizzando una degli elementi seguenti:
|
Autorizzazioni |
Scegliere le autorizzazioni da applicare agli utenti:
Tali autorizzazioni sostituiscono tutte le autorizzazioni assegnate nell'applicazione Web, incluse quelle impostate per le raccolte siti, i siti, gli elenchi, i documenti e così via. |
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 classi di utenti di dimensioni elevate, 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 numero di database del contenuto uguale o minore di 99 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 massimo delle dimensioni desiderate 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 elencati 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. |
Impostazioni della capacità |
|
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 stabilite.
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 desiderate.
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 lo strumento da riga di comando Stsadm per creare una raccolta siti in un database specifico.
Dedicare un database a una singola raccolta siti mediante l'applicazione delle 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 = 1
Numero massimo di siti che è possibile creare nel database = 1
Aggiungere un gruppo di raccolte siti a un database dedicato completando i passaggi seguenti:
Creare il database nell'applicazione Web, quindi nella pagina Gestisci impostazioni database del contenuto in Amministrazione centrale impostare lo stato del database su Pronto.
Impostare lo stato di tutti gli altri database su Non in linea. Mentre i database del contenuto sono non in linea, non è possibile creare nuove raccolte siti. Le raccolte siti esistenti nei database non in linea sono tuttavia accessibili sia per le operazioni di lettura che di scrittura.
Creare le raccolte siti. Verranno aggiunte automaticamente al database.
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 uguale o minore di 50.000 per ogni applicazione Web. La realizzazione della scalabilità orizzontale mediante la distribuzione di raccolte siti tra più server 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:
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 Microsoft Office SharePoint Server 2007 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 elencati gli elementi configurabili in Amministrazione centrale 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 quote |
È possibile applicare un modello quote per limitare le risorse utilizzate per una raccolta siti. Sono disponibili i modelli seguenti:
|
Nella tabella seguente sono elencati 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 e pertanto questa operazione può essere automatizzata o delegata agli utenti. È possibile creare raccolte siti per i siti del team in modo centralizzato oppure è possibile consentire agli utenti di creare le proprie raccolte siti utilizzando Gestione siti in modalità self-service. Se si assegna una raccolta siti a un unico database, è possibile 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.
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.
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. 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.
Per ulteriori informazioni sulla progettazione di URL e l'utilizzo di percorso gestiti, vedere la sezione "Aree e URL" nell'articolo Modello di architettura logica: distribuzione aziendale.
Siti
Un sito è costituito da una o più pagine Web correlate ospitate in una raccolta siti.
Capacità
In base alle linee guida per ottenere prestazioni accettabili, è consigliabile implementare meno di 250.000 siti per raccolta. È possibile creare un numero complessivo molto elevato di siti Web tramite la nidificazione dei siti secondari. Se si creano ad esempio 100 siti, ognuno dei quali con 1.000 siti secondari, si otterranno 100.000 siti Web. Il numero massimo consigliato numero di siti e siti secondari è di 125 siti con 2.000 siti secondari ognuno, per un totale di 250.000 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 eseguire il backup e il ripristino di singoli siti, è possibile utilizzare Microsoft Office SharePoint Designer 2007. Per ulteriori informazioni sull'amministrazione di siti, vedere gli articoli seguenti:
Backup, ripristino o spostamento di un sito di SharePoint (https://go.microsoft.com/fwlink/?linkid=85710&clcid=0x410)
Pianificare la creazione e la manutenzione dei siti (Office SharePoint Server)
Suggerimenti per la pianificazione
Per informazioni sulla pianificazione di siti, vedere gli articoli seguenti:
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à di intestazione host. Tali raccolte vengono create tramite lo strumento da riga di comando Stsadm.
Le raccolte siti con nome basato sull'host consentono di esercitare maggiore controllo sugli URL. Sono presenti tuttavia svantaggi che comportano l'applicazione delle avvertenze seguenti:
Le raccolte siti con nome basato sull'host 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.
Nella raccolte siti con nome basato sull'host non è possibile utilizzare la caratteristica di mapping di accesso alternativo. Tale caratteristica supporta la terminazione off-box del protocollo SSL, che consente l'utilizzo di SSL (HTTPS) in scenari di accesso per dipendenti remoti e partner.
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 utilizzando lo strumento da riga di comando Stsadm.
Assegnazione di una voce DNS distinta per ogni raccolta siti con nome basato sull'host.
Suggerimenti per la pianificazione
Per informazioni sulla creazione di raccolte siti con nome basato sull'host tramite lo strumento da riga di comando Stsadm e l'utilizzo di tali raccolte in un ambiente di hosting, vedere White paper: Create shared hosting solutions on Windows SharePoint Services.
Siti personali
In Microsoft Office SharePoint Server 2007 i siti personali sono siti di SharePoint particolari personalizzati per ogni utente e abilitati per impostazione predefinita. Ogni utente in un'organizzazione dispone di un sito personale univoco. Per informazioni sulla capacità, la condivisione e l'isolamento e l'amministrazione, vedere la sezione "Siti" in precedenza in questo articolo.
Per informazioni sulla pianificazione dei siti personali, vedere le risorse seguenti:
Scaricare il manuale
Questo argomento è incluso nel manuale seguente, che può essere scaricato per una lettura e una stampa più agevoli:
Per un elenco completo dei manuali disponibili che è possibile scaricare per Office SharePoint Server 2007, vedere Downloadable content for Office SharePoint Server 2007 (informazioni in lingua inglese).