Progettazione di esempio di un'architettura logica: siti di collaborazione
Contenuto dell'articolo:
Informazioni sul modello
Obiettivi di progettazione globali
Server farm
Utenti, aree e autenticazione
Siti di amministrazione
Pool di applicazioni
Applicazioni Web
Raccolte siti
Database del contenuto
Aree e URL
Criteri per le aree
Backup e ripristino dei siti di collaborazione
Progettazione per collaborazioni esterne protette
In questo articolo viene descritta un'implementazione pratica dei componenti dell'architettura logica per ottenere una progettazione efficiente. Le informazioni incluse in questo articolo devono essere utilizzate con il modello Esempio di progettazione di architettura logica: collaborazione in Windows SharePoint Services (informazioni in lingua inglese) (https://go.microsoft.com/fwlink/?linkid=124861&clcid=0x410) (informazioni in lingua inglese) .
Informazioni sul modello
Nel modello viene illustrata una distribuzione per una società fittizia denominata Fabrikam, Inc. Se si sta pianificando una soluzione con uno o più dei tipi di sito di collaborazione rappresentati in questo modello, è possibile utilizzare tale modello come base per il proprio progetto.
Nel modello è illustrata una distribuzione generica di Microsoft Windows SharePoint Services 3.0 con tre tipi diversi di sito di collaborazione:
Siti del team
Siti in modalità self-service
Siti di collaborazione tra partner
Nel modello vengono applicati quasi tutti i componenti dell'architettura logica e viene illustrato in che modo tali componenti vengono integrati nella progettazione complessiva. In questo articolo vengono descritti gli obiettivi di progettazione per il modello e viene spiegato in che modo tali obiettivi possono essere raggiunti utilizzando i componenti dell'architettura logica illustrati nel modello.
Ognuno dei tipi di sito di collaborazione:
Ospita dati con caratteristiche diverse.
È soggetto a un profilo utente diverso.
Richiede una diversa strategia di gestione delle autorizzazioni.
Le scelte di progettazione del modello hanno pertanto lo scopo di ottimizzare le prestazioni e la protezione di ogni applicazione.
Siti del team
I siti del team sono siti di collaborazione altamente strutturati e gestiti nei quali:
È presente un numero inferiore di raccolte siti principali e tali raccolte siti sono progettate per includere una grande quantità di dati, al contrario dei siti in modalità self-service.
Gli URL principali sono significativi per tutti i team.
Vengono dedicati sforzi di pianificazione maggiori per gerarchie, tassonomie e personalizzazioni dei siti.
Il contenuto di ogni team si trova in un database distinto e può essere gestito separatamente.
Nel diagramma seguente viene illustrata la gerarchia dei siti del team:
.gif "Organizzazione dei siti del team")
Siti in modalità self-service
I siti in modalità self-service rappresentano un'alternativa ai siti del team, altamente gestiti. È possibile consentire agli utenti e ai team di creare raccolte siti personalizzate tramite Gestione siti in modalità self-service, attivabile nella pagina Amministrazione centrale. Questo metodo è indicato se si desidera consentire a gruppi o community di creare siti. Funziona anche se si ospitano siti e si desidera consentire agli utenti di creare siti senza attendere l'esecuzione di un processo dettagliato.
Le caratteristiche dei siti in modalità self-service sono diverse da quelle dei siti altamente gestiti. Alcune delle caratteristiche sono le seguenti:
Numero elevato di raccolte siti principali.
Quantità ridotta di dati per ogni raccolta siti.
URL generati automaticamente ma in genere non significativi.
Nel diagramma seguente vengono illustrati i siti in modalità self-service implementati nell'esempio di progettazione:
.gif "Siti per la creazione di siti in modalità self-service")
Esistono diversi svantaggi di cui tener conto durante la pianificazione dell'implementazione dei siti in modalità self-service, svantaggi che influenzeranno la modalità di gestione di tali tipi di sito:
Anziché implementare una tassonomia ad-hoc, i siti vengono creati in base alla volontà dei creatori senza seguire un preciso criterio organizzativo valido per tutti i siti. Poiché ogni nuovo sito rappresenta una raccolta siti, i modelli e lo spostamento non possono essere condivisi tra siti in modalità self-service.
Poiché ogni raccolta siti consente di eseguire ricerche solo nel contenuto della raccolta siti stessa, non è possibile l'aggregazione dei risultati delle ricerche tra raccolte siti.
Le dimensioni e l'utilizzo delle raccolte siti può variare notevolmente.
I siti possono essere abbandonati facilmente.
La gestione dei siti in modalità self-service può includere la gestione dell'archiviazione del contenuto basata sulle dimensioni di destinazione dei database del contenuto e l'eliminazione regolare dei siti non più utilizzati.
Per ulteriori informazioni sull'implementazione di Gestione siti in modalità self-service, vedere Plan process for creating sites (Windows SharePoint Services).
Siti di collaborazione tra partner
L'applicazione Web partner ospita siti disponibili esternamente per la collaborazione protetta con i dipendenti delle società partner. Questa applicazione consente ai dipendenti di creare con facilità siti protetti per la collaborazione. I fattori chiave che indirizzano le scelte di progettazione per questa applicazione includono:
**Isolamento del contenuto **Ai partner non è consentito accedere ad altri tipi di contenuto ospitati nella server farm.
**Autenticazione separata degli account partner **Gli account partner vengono gestiti tramite l'autenticazione Forms e non vengono aggiunti alla directory aziendale.
**Gestione delle autorizzazioni **I proprietari dei singoli siti gestiscono le autorizzazioni per i relativi siti, invitando a collaborare solo i partecipanti necessari.
Nel diagramma seguente vengono illustrati i siti di collaborazione tra partner.
.gif "Gerarchia dei siti di progetto in un'applicazione Web partner")
Obiettivi di progettazione globali
Nel modello viene illustrata un'implementazione pratica delle caratteristiche di Microsoft Windows SharePoint Services 3.0 con diversi tipi di applicazioni per la collaborazione (siti del team, siti in modalità self-service e siti dei partner). In questo articolo vengono descritte le implementazioni di progettazione per ogni singola applicazione del sito. Gli obiettivi di progettazione chiave per il modello includono:
Creazione di un framework per la progettazione di un ambiente ampliabile. Le decisioni di progettazione prese per le singole applicazioni per la collaborazione non devono impedire l'aggiunta di altre applicazioni. Ad esempio, una distribuzione iniziale potrebbe includere solo i siti del team di collaborazione oppure solo i siti dei partner. L'utilizzo di una simile progettazione dell'architettura logica consente di aggiungere alla soluzione gli altri tipi di siti per la collaborazione senza modificare la progettazione di quelli iniziali. In altri termini, la progettazione non comprende scelte che limitano le possibilità di utilizzo dell'ambiente.
Disponibilità dell'accesso per diverse classi di utenti senza compromettere la protezione del contenuto all'interno delle diverse applicazioni per la collaborazione. Gli utenti di aree della rete diverse, sia interni sia esterni, con provider di autenticazione diversi possono partecipare alla collaborazione. Gli utenti possono inoltre accedere solo al contenuto al quale sono destinati. La scelta di una progettazione dell'architettura logica di questo tipo consente di fornire accesso agli utenti in più posizioni e con obiettivi diversi. La progettazione iniziale potrebbe ad esempio essere prevista solo per l'accesso di dipendenti interni. L'utilizzo di questo tipo di progettazione offre tuttavia l'opportunità di consentire l'accesso anche a dipendenti, partner e anche clienti remoti.
Garanzia dell'usabilità della progettazione in un ambiente Extranet. È possibile adottare precise scelte di progettazione per garantire che le server farm possano essere distribuite in sicurezza in una rete perimetrale o all'interno di qualsiasi topologia Extranet illustrata in Design extranet farm topology (Windows SharePoint Services).
Nella restante parte di questo articolo viene descritto ogni componente logico presente nel modello (dall'alto verso il basso) e vengono illustrate le scelte di progettazione applicate al modello. Lo scopo di questo approccio è illustrare i diversi modi in cui è possibile configurare i componenti dell'architettura logica in base all'applicazione.
Server farm
Nel modello viene illustrata una farm con cinque server, ma il modello può essere applicato a farm di qualsiasi dimensione, incluse quelle a server singolo. Ogni server farm inclusa nel modello è composta da cinque server con la topologia seguente:
Due server Web front-end.
Un server applicazioni per ogni server
Due server database in cluster o in mirroring
Nel modello viene illustrata l'architettura logica di Microsoft Windows SharePoint Services 3.0 indicando che:
Tutti i siti hanno esatti corrispondenti nei siti Web front-end.
Il sito Amministrazione centrale è installato in un server applicazioni per impedire l'accesso diretto degli utenti.
Il numero di computer server e la topologia della server farm non sono in realtà importanti per l'architettura logica, se non per migliorare la capacità e le prestazioni, se necessario. L'architettura logica può essere progettata in modo indipendente dalla topologia della server farm. Il processo di pianificazione della capacità e delle prestazioni consentirà di creare server farm con le dimensioni necessarie per soddisfare gli obiettivi stabiliti in termini di prestazioni e capacità. Per ulteriori informazioni, vedere Plan for performance and capacity (Windows SharePoint Services).
Utenti, aree e autenticazione
Nel modello vengono illustrate cinque classi di utenti diverse, ognuna delle quali è assegnata a un'area diversa. 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. Una farm che ospita più applicazioni Web può supportare le richieste degli utenti da più di cinque aree di rete (fino a cinque aree per ogni applicazione Web). Nel modello vengono tuttavia illustrate solo cinque aree.
Utenti e autenticazione
Nel modello viene illustrata la modalità di applicazione dell'autenticazione agli utenti di aree di rete diverse. Nella tabella seguente viene inoltre illustrata l'autenticazione applicata a ogni tipo di utente e area.
| Area | Utenti | Autenticazione |
|---|---|---|
Intranet |
Dipendenti interni |
NTLM (integrata in Windows) |
Predefinito |
Dipendenti remoti |
NTLM (autenticazione integrata di Windows) o autenticazione Forms con LDAP (Lightweight Directory Access Protocol). |
Extranet |
Dipendenti di partner |
Autenticazione Forms |
Dipendenti interni
L'area Intranet viene utilizzata per l'accesso dei dipendenti interni. Viene utilizzata l'autenticazione integrata di Windows.
Dipendenti remoti
L'area Predefinita viene utilizzata per l'accesso dei dipendenti remoti. Gli obiettivi di progettazione per l'area Predefinita sono i seguenti:
Eseguire l'autenticazione nell'ambiente del servizio directory Active Directory interno.
Semplificare la gestione delle autorizzazioni utilizzando l'autenticazione di Windows sia per i dipendenti interni sia per i dipendenti remoti. Questo obiettivo è importante, in quanto se gli utenti si collegano ai siti tramite due provider di autenticazione diversi, in Microsoft Windows SharePoint Services 3.0 verranno creati due account diversi per ogni utente e ogni account dovrà disporre di autorizzazioni.
Nel modello vengono presentate due opzioni diverse per l'autenticazione dei dipendenti remoti. La prima opzione, ovvero l'autenticazione integrata di Windows con NTLM, consente di raggiungere entrambi gli obiettivi. La seconda opzione, ovvero l'autenticazione Forms con LDAP, soddisfa il primo obiettivo, ma non il secondo. La prima opzione rappresenta pertanto la modalità preferita per i dipendenti remoti.
Nella tabella seguente sono riepilogate le differenze tra queste due opzioni di autenticazione.
| Tipo di confronto | Autenticazione integrata di Windows con NTLM | Autenticazione Forms con un provider LDAP |
|---|---|---|
Funzionalità |
Questo metodo si basa sull'utilizzo di Internet Security and Acceleration (ISA) Server 2006 o Intelligent Application Gateway (IAG 2007) per l'autenticazione degli utenti e il successivo invio delle credenziali utente a Microsoft Windows SharePoint Services 3.0. Questi server utilizzano l'autenticazione Forms per autenticare gli utenti nell'ambiente Active Directory. Inoltrano quindi le credenziali di Windows a Microsoft Windows SharePoint Services 3.0. Per ulteriori informazioni sull'autenticazione in ISA Server 2006 e sulla configurazione avanzata di IAG, vedere le risorse seguenti:
Poiché l'area corrisponde a quella Predefinita, l'autenticazione NTLM viene utilizzata per soddisfare un requisito del componente di indicizzazione. Per ulteriori informazioni, vedere "Configurazione dei requisiti dell'area predefinita" più avanti in questo articolo. |
Microsoft Windows SharePoint Services 3.0 utilizza l'autenticazione Forms con un provider LDAP per autenticare i dipendenti remoti nell'ambiente Active Directory interno. |
Vantaggi |
In Microsoft Windows SharePoint Services 3.0 non vengono creati due account diversi per gli utenti che lavorano sia internamente sia in modalità remota, consentendo una notevole semplificazione della gestione delle autorizzazioni. |
Non è richiesto un server proxy per l'autenticazione degli utenti e l'inoltro delle credenziali. |
Svantaggi |
È richiesto il coordinamento e la configurazione aggiuntivi di ISA Server 2006, IAG 2007 o di un altro prodotto server proxy. |
Se gli utenti si connettono a Microsoft Windows SharePoint Services 3.0 sia internamente sia in modalità remota, in Microsoft Windows SharePoint Services 3.0 verranno creati due account utente diversi. Entrambi gli account dovranno pertanto disporre delle autorizzazioni necessarie per siti e documenti. È necessario che i dipendenti gestiscano le autorizzazioni di entrambi gli account per i propri siti personali e documenti nel caso prevedano di lavorare sia internamente sia in modalità remota. |
Dipendenti di partner
I dipendenti partner accedono alla rete tramite la zona Extranet e vengono autenticati mediante l'autenticazione Forms. Questo metodo richiede l'utilizzo di una directory e di un provider distinti, ad esempio un database e un provider Microsoft SQL Server, per l'archiviazione degli account partner nella rete Extranet. I vantaggi di questo approccio sono rappresentati dalla possibilità di gestire gli account partner in modo separato e dal fatto che non è necessario aggiungere gli account partner alla directory dei dipendenti interni.
In alternativa, è possibile utilizzare Single Sign-On (SSO) Web per eseguire l'autenticazione in una directory personale del partner. Questo approccio richiede tuttavia un'area separata per ogni directory partner.
Poiché nel modello si presuppone che Fabrikam stia collaborando con i partner di diverse società all'interno della stessa applicazione partner, viene utilizzata l'autenticazione Forms. La directory e il provider non vengono specificati.
Aree
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 descritte le decisioni incluse nel modello.
Requisiti di configurazione dell'area Predefinita
L'area che deve essere considerata con maggiore attenzione è l'area Predefinita. Microsoft Windows SharePoint Services 3.0 presenta i requisiti seguenti rispetto alla modalità di configurazione dell'area Predefinita:
Quando la richiesta di un utente non può essere associata a un'area, vengono applicati l'autenticazione e i criteri dell'area Predefinita. Di conseguenza, l'area Predefinita deve essere l'area più protetta.
Per eseguire la ricerca per indicizzazione nel contenuto, il componente di indicizzazione richiede l'accesso al contenuto almeno tramite un'area. Il componente di indicizzazione utilizza l'autenticazione NTLM. Pertanto, per eseguire la ricerca per indicizzazione nel contenuto, è necessario che almeno una delle aree sia configurata per l'utilizzo dell'autenticazione NTLM. Il crawler esegue inoltre il polling delle aree, nell'ordine area Predefinita, area Intranet, area Internet, area Personalizzata e area Extranet, fino a quando non viene individuata un'area tramite la quale eseguire l'autenticazione. Se tuttavia il crawler individua prima un'area configurata per l'utilizzo dell'autenticazione Kerberos, di base o del digest, non eseguirà l'autenticazione e non tenterà di accedere all'area successiva. Assicurarsi pertanto che la configurazione delle aree non impedisca al componente di indicizzazione di eseguire la ricerca per indicizzazione nel contenuto. Per ulteriori informazioni sui requisiti di autenticazione correlati alla ricerca per indicizzazione nel contenuto, vedere Plan authentication methods.
Vengono inviati messaggi di posta elettronica amministrativi con collegamenti relativi all'area Predefinita. Sono inclusi messaggi di posta elettronica ai proprietari di siti che stanno raggiungendo i limiti di quota. Di conseguenza, gli utenti che ricevono questo tipo di messaggio 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 nell'area Predefinita. Per accedere alle raccolte siti con nome basato sull'host, gli utenti devono utilizzare l'area Predefinita.
Nel modello l'area Predefinita viene utilizzata per l'accesso dei dipendenti remoti per i motivi seguenti:
I dipendenti possono accedere ai collegamenti nei messaggi di posta elettronica amministrativi indipendentemente dal fatto che accedano ai siti internamente o in modalità remota.
I nomi dei server e gli URL interni non vengono esposti quando la zona associata a una richiesta dell'utente non può essere determinata. Poiché l'area Predefinita è già configurata per i dipendenti remoti, gli URL non consentono l'esposizione di dati riservati quando è applicata quest'area.
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 reti diverse. Nel modello gli utenti avviano richieste dalla rete interna, da Internet e dalle società partner.
Gli utenti possono collaborare nell'ambito di più applicazioni Web. Ad esempio, dipendenti interni e remoti possono potenzialmente contribuire al contenuto e amministrarlo in tutte le applicazioni Web, ovvero siti del team, siti in modalità self-service e siti Web 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.
Nel modello l'area Predefinita di ogni applicazione Web è configurata in modo identico per l'accesso dei dipendenti remoti. Inoltre, l'area Intranet è configurata in modo identico in tutte le applicazioni Web per l'accesso dei dipendenti interni. L'area Extranet è configurata solo per un'unica applicazione Web.
I mapping di accesso alternativo vengono creati automaticamente quando si crea l'area. Tuttavia, se per rendere i siti disponibili da Internet si utilizza un server proxy o un gateway, sarà necessario aggiungere una voce del mapping di accesso alternativo per ogni area. Ciò garantisce che gli URL restituiti agli utenti al di fuori della rete interna siano disponibili agli utenti in base al contesto della loro area. Per ulteriori informazioni, vedere Plan alternate access mappings.
Se le aree delle varie applicazioni Web non sono speculari e i collegamenti alle risorse esterne non sono appropriati, potrebbero presentarsi i rischi seguenti:
Nomi di server, nomi DNS (Domain Name System) e indirizzi IP potrebbero essere esposti all'esterno della rete interna.
Gli utenti potrebbero non essere in grado di accedere a siti Web e altre risorse.
Siti di amministrazione
Nel modello il sito Amministrazione centrale è ospitato nel server di ricerca. Il sito viene in tal modo protetto dal contatto diretto con gli utenti. Se un collo di bottiglia delle prestazioni o una violazione della protezione influisce sulla disponibilità dei server Web front-end, il sito Amministrazione centrale rimarrà comunque disponibile. Inoltre, il sito Amministrazione centrale è ospitato all'interno di un pool di applicazioni e di un'applicazione Web dedicati.
Gli URL con carico bilanciato per i siti di amministrazione non vengono indicati in questo modello o in questo articolo. I suggerimenti includono i seguenti:
Se negli URL amministrativi vengono utilizzati numeri di porta, utilizzare porte non standard. I numeri di porta vengono inclusi negli URL per impostazione predefinita. Mentre i numeri di porta non vengono in genere utilizzati negli URL pubblici, l'utilizzo di numeri di porta per siti amministrativi può migliorare la protezione limitando l'accesso a tali siti su porte non standard.
Creare voci DNS distinte per siti di amministrazione.
Pool di applicazioni
Per ottenere l'isolamento dei processi nei siti, vengono in genere implementati pool di applicazioni Internet Information Services (IIS) distinti. I pool di applicazioni consentono di eseguire più siti nello stesso computer server, pur mantenendo tali siti i propri processi di lavoro e la propria identità. In questo modo viene attenuato qualsiasi rischio di protezione in un sito che consente a chi effettua un attacco di inserire codice nel server per attaccare altri server.
In termini pratici, prendere in considerazione l'utilizzo di un pool di applicazioni dedicato per ogni scenario seguente:
Per separare il contenuto autenticato dal contenuto anonimo.
Per isolare i siti destinati principalmente alla collaborazione con partner o clienti esterni. In questo modo gli account esterni vengono isolati in siti all'interno di un pool di applicazioni.
Per isolare siti in cui gli utenti hanno maggiore libertà di creazione e amministrazione di siti e di collaborazione al relativo contenuto.
Nel modello i pool di applicazioni vengono utilizzati nel modo seguente:
Il sito di amministrazione è ospitato in un pool di applicazioni dedicato. Questo è un requisito di Microsoft Windows SharePoint Services 3.0.
I siti di collaborazione interni, ovvero siti del team e siti in modalità self-service, sono ospitati in un pool di applicazioni.
L'applicazione Web partner è ospitata in un pool di applicazioni dedicato.
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).
È in generale consigliabile utilizzare applicazioni Web dedicate per:
Separare il contenuto anonimo da quello autenticato.
Isolare utenti. Nel modello il Web partner è ospitato in un'applicazione Web e in un pool di applicazioni dedicati per garantire che i partner non abbiano accesso al contenuto Intranet.
Applicare autorizzazioni. Un'applicazione Web dedicata offre l'opportunità di applicare autorizzazioni utilizzando la pagina Criteri per l'applicazione Web in Amministrazione centrale. È ad esempio possibile creare un criterio nei siti di collaborazione interni per negare in modo esplicito l'accesso agli account partner. 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. I siti garantiscono prestazioni migliori se vengono inseriti in applicazioni Web con altre applicazioni aventi caratteristiche dei dati simili. Ad esempio, le caratteristiche dei dati dei siti in modalità self-service includono 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. Nel modello i siti del team e quelli in modalità self-service non hanno requisiti di isolamento dei dati univoci, in quanto condividono lo stesso pool di applicazioni. I siti del team e quelli in modalità self-service sono stati tuttavia inseriti in applicazioni Web distinte per ottimizzare le prestazioni.
Ottimizzare la gestibilità. Poiché la creazione di applicazioni Web separate determina la creazione di siti e database distinti, è possibile implementare limiti diversi per i siti (Cestino, scadenza e dimensioni) e negoziare contratti di servizio diversi. È ad esempio possibile consentire più tempo per il ripristino del contenuto dei siti in modalità self-service se questo non è il tipo di contenuto più importante dell'organizzazione. In questo modo sarà possibile ripristinare una quantità maggiore di contenuto critico prima di ripristinate tali siti. Nel modello i siti in modalità self-service sono inseriti in un'applicazione Web distinta per consentire agli amministratori di gestirne la crescita in modo più efficace rispetto ad altre applicazioni.
Raccolte siti
Le raccolte siti rappresentano il collegamento tra l'architettura logica e l'architettura delle informazioni. Gli obiettivi di progettazione per le raccolte siti del modello consentono di soddisfare i requisiti per la progettazione di URL e creare divisioni logiche del contenuto.
Per soddisfare i requisiti per la progettazione di URL, ogni applicazione Web include una raccolta siti al livello radice. I percorsi gestiti vengono utilizzati per incorporare un secondo livello di raccolte siti principali. Per ulteriori informazioni sui requisiti degli URL e sull'utilizzo di percorsi gestiti, vedere "Aree e URL" più avanti in questo articolo. Oltre il secondo livello di raccolte siti, ogni sito è un sito secondario.
Nella figura seguente viene illustrata la gerarchia dei siti del team.
.jpg "Architettura logica dei siti di collaborazione")
Dato il requisito per una raccolta siti a livello radice, le decisioni di progettazione vertono intorno al secondo livello di raccolte siti. Nel modello sono incluse scelte prese in base alla natura dell'applicazione.
Siti in modalità self-service
Nel modello i siti in modalità self-service includono un sito principale con l'URL http://siti. Mediante l'inclusione di caratteri jolly, viene incorporato un percorso gestito che consente un numero indefinito di siti creati dall'utente. Tutti i siti al di sotto del percorso gestito sono raccolte siti indipendenti che ereditano il modello di sito utilizzato per creare il sito principale. Nella figura seguente vengono illustrati i siti in modalità self-service.
Per ulteriori informazioni sui siti in modalità self-service, vedere Plan process for creating sites (Windows SharePoint Services).
Siti del team
Durante la progettazione di raccolte siti all'interno di un'applicazione per i siti del team, è consigliabile creare un numero finito di raccolte siti, a seconda delle esigenze operative dell'organizzazione. In questo approccio le raccolte siti vengono create da un amministratore di Microsoft Windows SharePoint Services 3.0. Dopo la creazione della raccolta siti, i team possono creare siti all'interno della raccolta in base alle necessità.
Questo approccio consente di implementare una tassonomia ad-hoc che organizza la modalità di gestione e sviluppo dei siti del team. Consente inoltre maggiori opportunità di condividere modelli e strutture di spostamento tra i progetti e i team che condividono una raccolta siti. La sfida per gli architetti informatici consiste nel creare un secondo livello di raccolte siti efficaci per l'organizzazione. Nella tabella seguente vengono elencati alcuni suggerimenti per diversi tipi di organizzazioni.
| Tipo di organizzazione | Tassonomie di raccolte siti consigliate |
|---|---|
Sviluppo prodotto |
|
Ricerca |
|
Istituto di istruzione superiore |
|
Ufficio affari legislativi |
|
Ufficio legale aziendale |
|
Produzione |
|
Web partner
Il Web partner è destinato alla collaborazione con partner esterni su progetti con ambiti limitati o durate limitate. In base alla progettazione, i siti all'interno dell'applicazione Web partner non sono destinati a essere correlati. I requisiti per il Web partner prevedono la verifica degli aspetti seguenti:
I proprietari dei progetti possono creare con facilità siti per la collaborazione con il partner.
I partner e gli altri collaboratori hanno accesso solo ai progetti su cui lavorano.
Le autorizzazioni vengono gestite dai proprietari del sito.
I risultati delle ricerche eseguite dall'interno di un progetto non determinano l'esposizione del contenuto di altri progetti.
Gli amministratori possono identificare con facilità i siti che non vengono più utilizzati e quindi eliminarli.
Per soddisfare questi requisiti, nel modello è inclusa una raccolta siti per ogni progetto. In questo modo, si ottengono i vantaggi seguenti:
Singole raccolte siti offrono il livello appropriato di isolamento tra i progetti.
Può essere implementata la creazione di siti in modalità self-service.
Database del contenuto
Per includere database del contenuto nella progettazione, è possibile utilizzare i due approcci seguenti (nel modello vengono utilizzati entrambi):
Stabilire le dimensioni di destinazione per i database del contenuto con valori di soglia degli avvisi per le dimensioni appropriati. Creare un nuovo database quando si raggiungono i valori di soglia degli avvisi per le dimensioni. Con questo approccio, le raccolte siti vengono aggiunte automaticamente al database o ai database disponibili esclusivamente in base agli obiettivi di dimensione.
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 sceglie di associare le raccolte siti a database del contenuto specifici, sarà possibile utilizzare i metodi 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 relative alla capacità del database:
Numero di siti prima della generazione di un evento di avviso = 1
Numero massimo di siti che possono essere creati in questo database = 1
Aggiungere un gruppo di raccolte siti a un database dedicato completando i passaggi seguenti:
All'interno dell'applicazione Web creare il database e impostare il relativo stato 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.
Siti del team
Nel modello è incluso un database dedicato per ogni raccolta siti del team. Questo approccio consente di gestire ogni database del team in modo indipendente per scopi di backup, ripristino e migrazione. Quando un progetto viene completato, risulta inoltre più facile archiviare il database associato al progetto.
Siti in modalità self-service
Per i siti in modalità self-service, il modello raggiunge l'efficienza a livello di dimensioni mediante la gestione dei database nella loro dimensione di destinazione massima. Per raggiungere questo obiettivo, vengono configurate le impostazioni seguenti:
Dimensioni massime spazio di archiviazione del sito Questa impostazione, che è possibile configurare nella pagina Modelli quote in Amministrazione centrale, consente di limitare le dimensioni di un sito personale.
Cestino secondario Questa impostazione, che è possibile configurare nella pagina Impostazioni generali applicazione Web, consente di determinare la quantità di spazio aggiuntivo assegnata al cestino secondario.
Numero massimo di siti che possono essere creati in questo database Questa impostazione viene configurata al momento della creazione del database. Calcolare la dimensione totale consentita di siti utilizzando i numeri specificati per i due valori precedenti. Quindi, in base all'obiettivo di dimensione per ogni database, determinare il numero di siti che rientreranno nel database.
Nel modello sono incluse le impostazioni di dimensione di esempio seguenti, basate su una dimensione di destinazione del database di 100 GB e una dimensione di destinazione dei siti personali di 500 MB:
Limiti di dimensione del sito per ogni sito = 500 MB
Dimensione di destinazione del database = 100 GB
Numero massimo di siti = 200
Avviso numero siti = 175
Quando si raggiunge il valore relativo all'avviso per il numero di siti, creare un nuovo database. Dopo aver creato il nuovo database, i nuovi siti in modalità self-service verranno aggiunti alternativamente al nuovo database e al database esistente fino a quando non verrà raggiunto il numero massimo di siti per uno dei database.
Web partner
Analogamente ai siti in modalità self-service, il Web partner raggiunge l'efficienza a livello di dimensioni mediante la gestione dei database nella loro dimensione di destinazione massima.
Poiché il Web partner è ospitato in un'applicazione Web dedicata, è possibile creare i limiti di dimensione più appropriati per i tipi di dimensione creati. Nel modello vengono utilizzate le impostazioni di esempio seguenti per le dimensioni:
Dimensione di destinazione del database = 100 GB
Quota di spazio di archiviazione per ogni sito = 5 GB
Numero massimo di siti = 20
Aree e URL
Nel modello viene illustrato come coordinare gli URL tra più applicazioni all'interno di una distribuzione aziendale.
Obiettivi di progettazione
Gli obiettivi seguenti influenzano le decisioni di progettazione per gli URL:
Le convenzioni per gli URL non consentono di limitare le aree tramite le quali è possibile accedere il contenuto.
Le porte HTTP e HTTPS (80 e 443) standard possono essere utilizzate in tutte le applicazioni del modello.
I numeri di porta non sono inclusi negli URL. In effetti, i numeri di porta non vengono in genere utilizzati negli ambienti di produzione.
Principi di progettazione
Per raggiungere gli obiettivi di progettazione illustrati, vengono applicati i principi di progettazione seguenti:
Le raccolte siti con nome basato sull'host non vengono utilizzate. Si noti che le raccolte siti con nome basato sull'host sono diverse dalle intestazioni host di IIS, in quanto non utilizzano la caratteristica di mapping di accesso alternativo. Tale caratteristica è necessaria per accedere allo stesso contenuto tramite più URL di dominio. Di conseguenza, quando vengono utilizzati siti con nome basato sull'host, tali siti sono disponibili solo tramite l'area Predefinita. La caratteristica di mapping di accesso alternativo fornisce inoltre il supporto per la terminazione off-box di SSL (Secure Sockets Layer), che consente l'utilizzo di SSL (HTTPS) in scenari che prevedono l'accesso di dipendenti remoti e partner. Per ulteriori informazioni sull'utilizzo delle raccolte siti con nome basato sull'host, vedere White paper: Create shared hosting solutions on Windows SharePoint Services.
Ogni applicazione include un'unica raccolta siti radice, requisito necessario per l'utilizzo di mapping di accesso alternativo. Se all'interno di un'applicazione Web sono necessarie più raccolte siti radice e si prevede di utilizzare solo l'area Predefinita per l'accesso degli utenti, le raccolte siti con nome basato sull'host rappresentano una soluzione valida.
Per le applicazioni che includono più raccolte siti di alto livello in cui ogni raccolta siti rappresenta un team o un progetto di alto livello (ad esempio siti del team), il modello include percorsi gestiti. I percorsi gestiti consentono di esercitare un maggiore controllo sugli URL per questi tipi di sito.
Svantaggi di progettazione
Il conseguimento degli obiettivi di progettazione comporta alcuni svantaggi, inclusi i seguenti:
Gli URL sono troppo lunghi.
Le raccolte siti con nome basato sull'host non vengono utilizzate.
Progettazione di URL con carico bilanciato
Quando si crea un'applicazione Web, è necessario scegliere un URL con carico bilanciato da assegnare all'applicazione. È inoltre necessario creare un URL con carico bilanciato per ogni area che si crea all'interno di un'applicazione Web. L'URL con carico bilanciato include il protocollo, lo schema, il nome host e la porta, se utilizzata. L'URL con carico bilanciato deve essere univoco in tutte le applicazioni Web e aree. Di conseguenza, ogni applicazione e ogni area all'interno di ogni applicazione richiede un URL univoco nel modello.
Siti di collaborazione interni
Entrambi i tipi di siti di collaborazione interni richiedono un URL univoco. Nel modello i gruppi di destinatari per questi siti sono i dipendenti interni e i dipendenti remoti. Nella tabella seguente vengono elencati gli URL per l'accesso dei dipendenti interni e remoti a ogni applicazione.
| Applicazione | URL dipendente interno | URL dipendente remoto |
|---|---|---|
Siti del team |
http://team |
https://team.fabrikam.com |
Siti in modalità self-service |
http://siti |
https://siti.fabrikam.com |
Web partner
Al Web partner illustrato nel modello accedono i dipendenti interni, i dipendenti remoti e i dipendenti del partner. Sebbene sia i dipendenti remoti sia i dipendenti esterni accedono al Web partner esternamente utilizzando SSL (HTTPS), per usufruire dei vantaggi derivanti dall'utilizzo di aree separate, ovvero metodi di autenticazione diversi e criteri per le aree diversi, è necessario un URL diverso per ogni dipendente. Nella tabella seguente vengono elencati gli URL utilizzati per l'accesso al Web partner da parte dei dipendenti interni, dei dipendenti remoti e dei dipendenti dei partner .
| Area | URL |
|---|---|
URL dipendente interno |
http://webpartner |
URL dipendente remoto |
https://webpartnerremoto.fabrikam.com |
URL partner |
https://webpartner.fabrikam.com |
Utilizzo di inclusioni esplicite o di caratteri jolly per i percorsi URL
Mediante la definizione di percorsi gestiti è possibile specificare i percorsi 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 esistono in corrispondenza di un percorso distinto sotto il sito radice. Senza percorsi gestiti, tutti i siti creati sotto la raccolta siti radice fanno parte di tale raccolta siti radice.
È possibile creare i due tipi di percorsi gestiti seguenti:
Inclusione esplicita Raccolta siti a cui è stato assegnato l'URL esplicito. Un'inclusione esplicita viene applicata solo a una raccolta siti. È possibile creare molte inclusioni esplicite sotto una raccolta siti radice. Un esempio di URL per una raccolta siti creata con questo metodo è http://team/Team1.
Inclusione di caratteri jolly Percorso aggiunto all'URL. Questo 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 la creazione di siti in modalità self-service. Un esempio di URL per una raccolta siti creata con questo metodo è http://siti/sito1.
Nel modello vengono utilizzati entrambi i tipi come descritto nelle sezioni seguenti.
Inclusioni esplicite: siti del team
Nel modello in entrambe le applicazioni per i siti del team è incluso l'utilizzo delle inclusioni esplicite.
Siti del team
All'interno dell'applicazione per i siti del team viene utilizzata un'inclusione esplicita per ogni raccolta siti del team. Il limite per le dimensioni delle raccolte siti create con un'inclusione esplicita è di circa 100 siti. Le procedure di governance ottimali prevedono di mantenere il numero di siti del team principali entro un valore gestibile. È inoltre necessario che la tassonomia per i siti del team sia coerente con la modalità operativa dell'azienda. Un limite di 100 siti risulta adeguato per molte organizzazioni. Se l'organizzazione necessita di dimensioni maggiori per i siti del team, utilizzare un'inclusione con caratteri jolly.
Nel modello l'utilizzo di inclusioni esplicite determina la creazione degli URL riportati nella tabella seguente.
| Dipendente interno (area Intranet) | Dipendente remoto (area Predefinita) |
|---|---|
http://team/Team1 |
https://team.fabrikam.com/Team1 |
http://team/Team2 |
https://team.fabrikam.com/Team2 |
http://team/Team3 |
https://team.fabrikam.com/Team3 |
In questo esempio la raccolta siti principale, ovvero http://team, non ospita necessariamente il contenuto per gli utenti.
Inclusioni di caratteri jolly: Web partner e siti in modalità self-service
Sia nel Web partner sia nei siti in modalità self-service viene utilizzata un'inclusione di caratteri jolly. Le inclusioni di caratteri jolly sono ideali per le applicazioni che consentono agli utenti di creare raccolte siti personali. Un'inclusione di caratteri jolly indica che l'elemento successivo al carattere jolly corrisponde a un sito principale di una raccolta siti.
Siti in modalità self-service
Nel modello i siti in modalità self-service contengono un'inclusione di caratteri jolly denominata /siti (http://selfservice/siti).
Verranno creati URL nei formati illustrati nella tabella seguente.
| Dipendente interno (area Intranet) | Dipendente remoto (area Predefinita) |
|---|---|
http://selfservice/siti/sito1 |
https://selfservice.fabrikam.com/siti/sito1 |
http://selfservice/siti/sito2 |
https://selfservice.fabrikam.com/siti/sito2 |
http://selfservice/siti/utente3 |
https://selfservice.fabrikam.com/personale/utente3 |
Web partner
Il Web partner è progettato per consentire ai dipendenti di creare con facilità siti protetti per la collaborazione con partner esterni. Per supportare questo obiettivo, è consentita la creazione di siti in modalità self-service.
Nel modello il Web partner contiene un'inclusione di caratteri jolly denominata /siti (http://webpartner/siti). Verranno creati URL nei formati illustrati nella tabella seguente.
| Dipendente interno (area Intranet) | Dipendente remoto (area Predefinita) |
|---|---|
http://webpartner/siti/progetto1 |
https://webpartnerremoto.fabrikam.com/siti/progetto1 |
http://webpartner/siti/progetto2 |
https://webpartnerremoto.fabrikam.com/siti/progetto2 |
http://webpartner/siti/progetto3 |
https://webpartnerremoto.fabrikam.com/siti/progetto3 |
I collaboratori dei partner possono accedere ai siti Web partner utilizzando gli URL elencati nella tabella seguente.
| Partner (area Extranet) |
|---|
https://webpartner.fabrikam.com/siti/progetto1 |
https://webpartner.fabrikam.com/siti/progetto2 |
https://webpartner/fabrikam.com/siti/progetto3 |
Criteri per le aree
È possibile creare un criterio per un'applicazione Web per applicare autorizzazioni al livello dell'applicazione Web. È possibile definire un criterio per l'applicazione Web in generale o solo per un'area specifica. L'utilizzo di un criterio determina l'applicazione delle autorizzazioni a tutto il contenuto dell'applicazione Web o dell'area. 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.
Nel modello viene illustrato un esempio: la negazione dell'accesso agli account partner ai siti di collaborazione interni.
Backup e ripristino dei siti di collaborazione
Sono disponibili diverse opzioni per il backup e il ripristino del contenuto appropriate per i siti di collaborazione:
Strumenti di backup e ripristino predefiniti — Utilizzare gli strumenti inclusi in Microsoft Windows SharePoint Services 3.0 se se dimensioni dei database non superano i 100 GB e non sono presenti molte personalizzazioni, oppure le personalizzazioni sono disponibili in un pacchetto di soluzione.
Strumenti di backup e ripristino di Microsoft SQL Server 2005 — Utilizzare questi strumenti se è presente un amministratore di database SQL.
Per ulteriori informazioni, vedere Choose backup and recovery tools (Windows SharePoint Services).
Progettazione per collaborazioni esterne protette
L'esempio di progettazione include una panoramica di come pianificare una collaborazione esterna protetta. In questa sezione è disponibile il testo introduttivo di ogni elemento e collegamenti agli articoli corrispondenti in TechNet.
| Suggerimento di progettazione | Informazioni |
|---|---|
Scegliere una topologia Extranet |
Proteggere la server farm utilizzando un firewall di confine o collocando la server farm in una rete perimetrale. Per ulteriori informazioni vedere gli articoli seguenti in TechNet:
|
Proteggere la comunicazione client-server |
La collaborazione protetta in un ambiente Extranet si basa sulla comunicazione protetta tra i computer client e l'ambiente della server farm. Se appropriato, utilizzare Secure Sockets Layer (SSL) per proteggere la comunicazione tra i computer client e i server. Per ulteriori informazioni vedere gli articoli seguenti in TechNet: |
Proteggere i server back-end e il sito Amministrazione centrale |
La collaborazione protetta esterna richiede server con connessione Internet. È possibile limitare l'esposizione al traffico proveniente da Internet posizionando un firewall tra i server Web e gli altri server e ospitando il sito Amministrazione centrale in un server back-end. Per ulteriori informazioni vedere gli articoli seguenti in TechNet:
|
Configurare i mapping di accesso alternativo |
I mapping di accesso alternativo supportano scenari di distribuzione Internet nei quali l'URL di una richiesta Web ricevuta da Internet Information Services (IIS) non corrisponde all'URL digitato da un utente finale. Ciò si verifica con maggiore probabilità negli scenari di distribuzione che includono la pubblicazione su proxy inverso e il bilanciamento del carico. I proxy inversi, ad esempio, possono eseguire funzionalità avanzate quali la ricezione di una richiesta Web su Internet tramite SSL (HTTPS) e inoltrare tale richiesta al server utilizzando HTTP. Questa procedura viene definita "terminazione off-box di SSL". Per ulteriori informazioni, vedere Plan alternate access mappings. |
Scaricare il manuale
Questo argomento è incluso nel manuale seguente, che può essere scaricato per una lettura e una stampa più agevoli:
Vedere l'elenco completo dei manuali disponibili visitando la pagina Web Manuali scaricabili per Windows SharePoint Services (informazioni in lingua inglese).