-----------------------------------

Acquista i software ArcGIS tramite Studio A&T srl, rivenditore autorizzato dei prodotti Esri.

I migliori software GIS, il miglior supporto tecnico!

I migliori software GIS, il miglior supporto tecnico!
Azienda operante nel settore GIS dal 2001, specializzata nell’utilizzo della tecnologia ArcGIS e aderente ai programmi Esri Italia Business Network ed Esri Partner Network

-----------------------------------



Visualizzazione post con etichetta ArcGIS Server Site. Mostra tutti i post
Visualizzazione post con etichetta ArcGIS Server Site. Mostra tutti i post

giovedì 10 marzo 2016

La sicurezza prima di tutto!

A partire da ArcGIS Server 10.4 abbiamo a disposizione un tool da eseguire da riga di comando chiamato serverScan.py. Il tool esegue la scansione del tuo site ArcGIS Server per verificare se è stato configurato seguendo le best practise raccomandate da Esri per quel che riguarda la sicurezza.
Il tool è presente nella cartella

C:\Program Files\ArcGIS\Server\tools\admin
e, una volta eseguito, restituisce un report html.
Come potete notare dall'estensione del file è un tool scritto in Python.
Analogamente è presente un tool chiamato portalScan.py ( ..\Portal\tools\security) che controlla la configurazione del Portal per verificare che siano rispettate le best practise raccomandate da Esri.

Qui potete vedere un esempio di report generato dal tool.


Il tool analizza 12 problematiche legate alla sicurezza dividendole in tre livelli di severità: critico, importante e raccomandato. Qui potete trovare l'elenco.

I parametri da passare al tool sono il nome completo della macchina, la user/password dell'admin del site e la cartella di output dove generare il report.

Con ArcGIS Server federato è possibile anche passare il token (-t in riga di comando) generato dal portal da https://mydomain/portal/sharing/rest/generateToken con Client impostato a Webapp URL al nome del dominio (esempio https://mydomain ) al posto della user/password del PSA
Mentre, se si genera il token dall'administrator directory di ArcGIS Server ( arcgis/admin/generateToken ), occorre impostare per il Client Request IP.



Esempio:

python serverScan.py -n gisserver.domain.com -u admin -p mypassword -o C:\Temp


Vediamo ora nel dettaglio i criteri che vengono verificati:

SS01 Critico
Verifica se la comunicazione con ArcGIS Server è criptata su canale ssl derminando se è abilitato l'https. Se il web adaptor è installato è raccomandato che la comunicazione sia protetta.
In questo caso viene evidenziato che la connessione avviene solo in http con arcgis server.


Inoltre abbiamo la possibilità di specificare i protocolli SSL. I predefiniti ArcGIS Server sono il TLS v1.0, TLS v1.1 e il TLS v1.2. Sono stati tolti SSL 2.0 e SSL 3.0 perché obsoleti e insicuri. Se decidiamo di abilitare solo il TLS v1.2 - attualmente il più sicuro in base ai cifrari utilizzati e comunque quello che supporta le criptazioni autenticate più moderne (ad esempio AEAD) - occorrerà verificare il web server che ospita il web adaptor possa comunicare con il TLS 1.2. Il TLS v1.0 è un protocollo legacy che viene ancora utilizzato ma, se possibile, è meglio evitarlo visto che anche se i moderni browser mitigano le sue debolezze presenta comunque problemi.

Per disabilitare SSL2  e SSL3 in Windows occorre

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols\SSL 2.0\Client]
“DisabledByDefault”=dword:00000001
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols\SSL 2.0\Server]
“Enabled”=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols\SSL 3.0\Client]
“DisabledByDefault”=dword:00000001
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols\SSL 3.0\Server]
“Enabled”=dword:00000000

Inoltre è raccomandato disabilitare l'algoritmo di cifratura RC4 che è insicuro

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 128/128]
"Enabled"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 40/128]
"Enabled"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 56/128]
"Enabled"=dword:00000000

Per disabilitare Diffie-Hellman vedi questo articolo.

Inoltre dovrebbe essere evitate le seguenti obsolete primitive crittografiche:
- Anonymous Diffie-Hellman (ADH) non forniscono autenticazione;
- NULL cipher non forniscono crittografia.
- Export cipher sono insicuri quando negoziati in una connessione, ma possono anche essere utilizzati con server che preferiscono cipher forti
- cipher deboli  (tipicamente di 40 e 56 bits) usano crittografia che può essere decifrata.
- 3DES è lento e debole.

Questa potrebbe essere un buon punto di partenza come sequenza di cifratori da utilizzare

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256

Purtroppo di cifrari occorre prevederne più di uno per la retrocompatibilità con i client che utilizzano il servizio e pertanto, per garantire la compatibilità, occorre trovare il miglior compromesso di suite di priorità di ordine.

Se volete testare il vostro ssl utilizzate l'indirizzo: ssllabs

Per ricevere un rating A+ su sistemi windows occorre avere solo abilitato il TLS 1.2 e l'HSTS (vedi questo articolo per abilitarlo su IIS)





  


SS02 Critico
Verifica se le query standardizzate sono imposte da ArcGIS Server. Per fornire protezione ad attacchi di SQL injection - essendo tale livello considerato critico - l'opzione è abilitata e ArcGIS Server verifica le query non consentendo di utilizzare specifiche funzioni e sintassi del database sottostante.
Qui puoi vedere come utilizzare le funzioni con query standardizzate.
Se non presente, è abilitato mentre se occorre disabilitarlo bisogna dichiararlo in system->properties

SS03 Critico
Verifica se la generazione del token via GET è supportata. Quando viene generato il token via GET le credenziali sono inviate come parte dell'URL e possono così essere visualizzate attraverso la history del browser o i log della rete. Dovrebbe essere disabilitato a meno che sia richiesto esplicitamente da altre applicazioni. Se non presente, è false altrimenti occorre dichiararlo in security->tokens. L'impostazione predefinita è false.

SS04 Critico
Verifica se la generazione del token via POST con le credenziali nei parametri della query string è supportata. Le problematiche sono le stesse dell'SS3 e pertanto andrebbe disabilitato. Se non presente è false altrimenti occorre dichiararlo in security->tokens. L'impostazione predefinita è false.


SS05 Critico
Visualizza un elenco di feature service dove la proprietà filter web content è disabilitata. Disabilitando questa proprietà, consenti all'utente di inserire nei campi di input qualsiasi cosa, ciò potrebbe esporre il servizio a potenziali attacchi XSS. Questa proprietà è abilitata in modo  predefinito e, a meno di entità o attributi HTML richiesti, non deve essere abilitata. Qui potete vedere la lista delle entità e attributi HTML supportati.



SS06 Critico
Controlla se i permessi non predefiniti sono applicati alla cartella System nel Server Manager.
L'impostazione predefinita consente solo agli amministratori e ai pubblicatori di avere accesso ai servizi contenuti nella cartella System.



SS07 Importante
Controlla se la directory dei servizi REST è accessibile attraverso un web browser. A meno che non venga utilizzata attivamente per cercare e trovare servizi da parte degli utenti, dovrebbe essere disattivata per ridurre la possibilità che i servizi possano essere visualizzati, trovati tramite una ricerca su web o interrogati tramite i moduli HTML. Inoltre fornisce un'ulteriore protezione contro attacchi XSS. In system->handlers->rest->servicesdirectory->edit può essere disabilitata.


SS08 Importante
Controlla se le richieste cross - domain sono limitate a specifici domini. Per ridurre la possibilità che applicazioni sconosciute inviino comandi malevoli ai tuoi servizi web, una best practice è limitare l'utilizzo dei tuoi servizi web alle applicazioni ospitate solo ai domini sicuri. Pertanto in system->handlers->rest->servicesdirectory->edit è possibile impostare nella casella AllowedOrigins al posto dell'asterisco la lista dei domini consentiti separati da una virgola (es: http://host.arcgis.com, https://gisserver.example.com)


SS09 Importante
Visualizza una lista di servizi dove il database può essere accessibile via workspace dinamici.
Abilitare il servizio ai workspace dinamici deve essere adeguatamente salvaguardato per evitare che accessi di terze parti possano creare dei danni alla banca dati connettendosi via rest. Pertanto la funzionalità deve essere abilitata solo se realmente necessaria all'applicazione web. In quest'ultimo caso occorrerà connettersi al database dando solo i privilegi minimi di sola lettura alle tabelle strettamente necessarie.


SS10 Raccomandato
Verifica se uno o più web adaptor sono registrati su HTTPS. Per consentire al Server Manager di reindirizzare in https, tutti i web adaptor dovrebbero essere registrati su HTTPS.


SS11 Raccomandato

Verifica se l'account del PSA è abilitato. E' consigliato disabilitare questo account per assicurarsi che non ci sia altro modo di amministrare ArcGIS Server se non tramite i gruppi o i ruoli specificato nell'identity store.  In security->psa è possibile disabilitare l'account PSA.




SS12 Raccomandato
Visualizza una lista di servizi feature che ha le operazioni di update e delete abilitate e non sono protetti.


Questo consente che i dati possano essere modificati o cancellati senza autenticazione.




martedì 31 luglio 2012

ArcGIS Server: FDGB vs EGDB

Quando si distribuisce un sito di ArcGIS Server, è necessario decidere dove memorizzare i dati utilizzati dai servizi GIS. Vi sarete chiesti: ma è meglio utilizzare i geodatabase ArcSDE (EGDB) o i file geodatase (FGDB)? Illustriamo ora alcuni scenari che aiutano nella scelta migliore.

Quando utilizzare geodabase ArcSDE rispetto a file geodatabase


In genere è consigliabile utilizzare un geodatabase ArcSDE enterprise per gestire i dati per i servizi.
ArcSDE offre supporto per alta disponibilità, backup e ripristino, concorrenza, scalabilità e una tendenza a fornire throughput superiori.
Tuttavia, questa scelta è consigliata col presupposto che l'organizzazione disponga di un amministratore di database (DBA) per ottimizzare, eseguire tuning e mantenere il geodatabase ArcSDE enterprise in condizioni di massima efficienza.
Se l'organizzazione non dispone di un DBA nel personale a sua disposizione e i dati pubblicati sono relativamente statici, l’utilizzo di un file geodatabase può essere una buona alternativa.
I file geodatabase generalmente forniscono ottime prestazioni senza la necessità di configurazioni aggiuntive o di tuning. A seconda delle caratteristiche dei dati GIS, in alcuni casi potrebbero essere necessarie ulteriori ottimizzazioni e tuning di un geodatabase ArcSDE enterprise per superare le prestazioni di un file geodatabase.
In flussi di lavoro di caching di mappe e di globi dove vengono effettuate molte chiamate di sola lettura ai dati in rapida successione, l’accesso ai file geodatabase attraverso percorsi locali spesso è migliore rispetto ai geodatabase ArcSDE.
Prima di optare per l’utilizzo di un file geodatabase, occorre ricordarsi che alcune funzionalità del geodatabase ArcSDE, quali versioning, repliche geodatabase e archiving, non sono disponibili nei file geodatabase. Inoltre, le funzionalità standard dei DBMS come logging, backup e ripristino e configurazione di failover non sono disponibili nei file geodatabase.


Considerazioni per i file geodatabase


Quando si utilizzano i file geodatabase per la memorizzazione dei dati, è necessario posizionare una copia identica del file geodatabase su ogni macchina server GIS. Ad esempio, in un sito di ArcGIS Server con tre server GIS, ogni server GIS deve accedere alla propria copia del file geodatabase. I server GIS non dovrebbero accedere allo stesso file geodatabase attraverso la rete.
Questa configurazione riduce al minimo il traffico di rete tra le diverse componenti di ArcGIS Server e riduce i conflitti I/O quando si accede al file geodatabase. Fattori che influenzano potenziali conflitti di I/O su disco per un file geodatabase condiviso includono il numero di layer nel servizio di mappa, i tipi di dati nel file geodatabase e il dispositivo di memorizzazione dei file.
I file geodatabase sono destinati per l'utilizzo in sola lettura con ArcGIS Server.
Per questo motivo, in scenari in cui il file geodatabase è una pubblicazione di geodatabase (in flussi di lavoro di replica one-way), la sincronizzazione di repliche deve verificarsi durante i periodi di inattività del servizio di mappa o rilasciando il file geodatabase dall’utilizzo da parte del servizio di mappa. Il rilascio del geodatabase può essere effettuato arrestando il servizio o, per i siti su più computer, rimuovendo temporaneamente le macchine server GIS dal sito, quindi ricollegarle dopo che il file geodatabase è stato aggiornato.
Una replica one-way è un'ottima soluzione per pubblicare ad esempio feature class da un sistema di coordinate ad un altro in fase di pubblicazione (ad esempio dal proprio sistema proiettato a web mercator adatto per la pubblicazione). Per maggiori dettagli http://support.esri.com/en/knowledgebase/techarticles/detail/34129
http://support.esri.com/en/knowledgebase/techarticles/detail/34143

L’ArcGIS Server non può disabilitare il blocco dello schema sui file geodatabase.

File geodatabase e caching di mappe


I file geodatabase funzionano bene per scenari di caching di mappa. Ponendo un file geodatabase identico su ogni macchina a lavorare sulla cache, è possibile eliminare molte chiamate al database ArcSDE che avrebbe bisogno di attraversare la rete. Questo può alleggerire il carico sul database e velocizzare la produzione di cache. È possibile utilizzare repliche one-way da ArcSDE per creare questi file geodatabase e, come già detto, possiamo anche replicare nella proiezione della mappa che verrà memorizzata nella cache. L’esempio classico è memorizzare la cache di una mappa web nella proiezione WGS 1984 Web Mercator (sfera ausiliaria) utilizzata da ArcGIS Online, Bing Maps e Google Maps. Questa non è solitamente una proiezione consigliata per memorizzare i propri dati in ArcSDE, ma è una buona proiezione per creare cache di una mappa web da un file geodatabase.

sabato 30 giugno 2012

ArcGIS for Server 10.1: scenari di distribuzione

Il rilascio della nuova versione ArcGIS Server 10.1, ha portato significativi cambiamenti nell’architettura, nelle funzionalità e nei workflow.
Esistono diversi modi per poter progettare il nostro sito ArcGIS Server e per soddisfare differenti capacità e requisiti di alta affidabilità.
I seguenti termini sono utilizzati per aiutare a spiegare ogni scenario di distribuzione:
Site: un sito è costituito da diversi componenti, come ad esempio un GIS server ed un ArcGIS Web Adaptor, che può essere opzionalmente distribuito tra più macchine per aumentare la ridondanza e la potenza di calcolo. Per una descrizione più dettagliata, vedere Inside and ArcGIS Server site.

GIS Server: il componente principale del sito si occupa di soddisfare le richieste proventienti dal Web Adaptor (se presente) per i servizi web GIS. Un GIS server si occupa di: renderizzare mappe, trovare le coordinate geografiche corrispondenti ad un indirizzo (geocoding), eseguire operazioni di interrogazione e molte altre operazioni fornite da ArcGIS (geoprocessing).

ArcGIS Web Adaptor: componente facoltativo che consente di configurare un punto di accesso web nel nostro sito. Si integra con il vostro web server e redirige le richieste dal web server al/i GIS server. Per ulteriori informazioni, vedere About the ArcGIS Web Adaptor.

Server directories: un insieme di directory contenenti determinati tipi di file a supporto dei servizi. Questi file includono cache, indici di ricerca e risultati dei processi di geoprocessing. Per ulteriori informazioni, vedere About server directories.

Configuration store: una posizione che contiene informazioni di configurazione come ad esempio l'elenco dei GIS server che partecipano al sito. Per funzionare, la configuration store deve essere disponibile per il sito. Per ulteriori informazioni, vedere About the configuration store.

Data: i dati utilizzati dai servizi web, come ad esempio le feature class, gli strumenti, le immagini e i locator. Per ulteriori informazioni, vedere Making your data accessible to ArcGIS Server.

I seguenti scenari sono presentati come guide su come progettare il sito di ArcGIS Server. Anche se si potrebbe configurare il sito esattamente come presentato in uno degli scenari, queste configurazioni sono flessibili e possono essere configurate per adattarle alle proprie esigenze e alle risorse hardware.


Sito per ambiente di sviluppo

Quando stiamo sviluppando o semplicemente stiamo sperimentando ArcGIS Server, è possibile installare il GIS server senza installare un server web o un Web Adaptor.



Il sito contiene un GIS server. I dati, le server directories e il configuration store risiedono localmente sul server GIS.

In questo scenario, il sito è configurato con un GIS server. I dati, le server directories e il configuration store risiedono localmente sul server GIS. Un database di Microsoft SQL Server Express è una buona opzione per la creazione di un'istanza di un geodatabase sul GIS server.

I client che accedono al sito si collegano direttamente al GIS server tramite HTTP sulla porta 6080. Ad esempio, l'URL del sito sarà http://myserver:6080. Il GIS server ospita solo servizi; non c'è nessun web server in questa configurazione per ospitare applicazioni web.

Casi d’uso e vantaggi del sito per ambiente di sviluppo
Questa configurazione è ideale per servizi di test e per avere un ambiente isolato. È relativamente semplice da installare e mantenere.

Svantaggi del sito per ambiente di sviluppo
Questa configurazione non è molto sicura, poiché ArcGIS Server Manager e ArcGIS Server Administrator Directory sono esposti attraverso la stessa porta che chiunque utilizza per accedere ai servizi. Inoltre, questa configurazione non può ospitare applicazioni web e non c'è nessuna opzione di failover se il GIS server va offline.


Sito su singola macchina

La più semplice configurazione appropriata per un sito in produzione è quella di esporre un GIS server attraverso il Web Adaptor. L’ArcGIS Web Adaptor consente ad ArcGIS for Server di integrarsi con l’esistente web server. E’ compatibile con IIS e con Java EE servers come WebSphere e WebLogic.

L'adattatore Web è consigliato perché le richieste in arrivo possono così passare attraverso il server web stabilito. Questo dà più opzioni di sicurezza e la capacità di ospitare applicazioni web. Se siamo a corto di risorse o non dobbiamo soddisfare molte richieste simultanee, è possibile installare il GIS server e il Web Adaptor su una singola macchina. Questa macchina deve anche avere un server web installato.

Ad esempio, il sito nella seguente immagine è configurato con un Web Adaptor sulla porta 80 e per accederci si utilizza l'URL http://server. Il Web Adaptor inoltra le richieste dei client in ingresso al server GIS sulla porta 6080. Gli amministratori del server dovrebbero accedere al Manager o all’ Administrator Directory tramite la porta 6080. 



Sito su singola macchina con Web Adaptor installato sul GIS server.

E’ possibile progettare il sito per utilizzare parti dell'infrastruttura IT esistente della nostra organizzazione. Nell’immagine sottostante, il Web Adaptor è stato spostato in un server web su un computer separato. Allo stesso modo, i dati, le server directories e il configuration store sono stati messi su un server di dati dedicato. Ciò mostra che la frase "sito su singola macchina" tecnicamente significa "sito su singolo GIS server."


Sito con un GIS server con Web Adaptor e dati ‘scaricati’ su macchine separate.

Mettere il server web sul proprio computer può essere desiderabile in organizzazioni dove il server web ha amministratori o politiche di accesso differenti rispetto al server GIS.

Mettere i dati su una macchina separata consente di aggiungere e rimuovere GIS server dal sito senza alcuna interruzione alle impostazioni di percorso dei dati. Mettere le server directories e la configuration store su un dispositivo di memorizzazione di rete ridondante migliora le capacità di backup e recupero per queste risorse.

Casi d’uso e vantaggi del sito su singola macchina
Il sito su singola macchina come illustrato sopra con un Web Adaptor è ideale per ospitare un piccolo numero di utenti simultanei. È anche utile in scenari di sviluppo o test dove è desiderata più sicurezza o la possibilità di ospitare applicazioni web. Il sito su singola macchina è relativamente semplice da configurare e può integrarsi nell’architettura esistente del web server e della memorizzazione dei dati.

Svantaggi del sito su singola macchina
Il sito della singola macchina non possiede nessuna capacità di failover se il GIS server va offline. Inoltre, la capacità del GIS server è limitata alle caratteristiche hardware della singola macchina.

Sito su più macchine
Un sito può includere più GIS server per gestire del traffico aumentato o per fornire funzionalità di backup nel caso in cui uno dei GIS server vada offline.
La configurazione con molteplici GIS Server gestiti da un Web Adaptor permette di evitare problemi di offline del servizio, perchè il Web Adaptor nel caso in cui il GIS Server vada offline il Web Adaptor può continuare a distribuire le richieste che arrivano ai rimanenti GIS Server che fanno parte del sito.
L’immagine seguente mostra il modo più semplice per configurare un sito con più GIS server. Il Web Adaptor rileva i GIS server che partecipano al sito e inoltra le richieste a ciascuno in modalità round-robin. Le macchine GIS Server poi comunicano tra di loro per determinare quale specifica macchina è disponibile e alla quale dovrebbe essere assegnata la richiesta. 



Sito con più GIS server dove i dati risiedono su un server di dati in alta affidabilità.

Ci sono due strategie per la memorizzazione dei dati quando si utilizzano più GIS server. L'approccio indicato sopra mantiene i dati in un'unica posizione centralizzata visibile a ogni GIS server. Solo i dati devono essere mantenuti in un unico luogo e questa configurazione è consigliata se hai una buona connessione intranet.

Un altro approccio per la memorizzazione dei dati, mostrata qui sotto, è di mettere una copia locale dei dati su ogni macchina GIS server in un percorso identico. Questa strategia riduce le chiamate sulla rete e può aumentare le prestazioni, se la velocità della tua connessione intranet è lenta. Tuttavia con questa architettura, è difficile mantenere grandi dataset e frequenti cambiamenti ai dataset.


Sito con più GIS server dove i dati vengono memorizzati localmente su ciascun GIS server.

Se la domanda aumenta, in entrambi gli scenari sopra, ulteriori macchine GIS server possono essere aggiunte al sito sia manualmente che automaticamente attraverso script (Example: Join a machine to a site). Questa architettura è adatta al cloud computing, in cui qualsiasi GIS server può essere aggiunto o rimosso dal sito in qualsiasi momento.

Vantaggi dei cluster
Siti di grandi dimensioni con due o più GIS server possono approfittare dei cluster. Un cluster è un gruppo di GIS server che è stato configurato per eseguire un dedicato sottoinsieme di servizi. Nell’immagine sottostante, il Cluster A potenzialmente potrebbe essere configurato per eseguire servizi di mappa, mentre il Cluster B (con maggiore potenza di elaborazione) potrebbe essere configurato per eseguire servizi di geoprocessing.


Sito con più macchina e con cluster. Ogni cluster esegue il proprio sottoinsieme di servizi.

Alcune operazioni sul server, come ad esempio la geocodifica batch, richiedono un utilizzo intensivo di CPU. Utilizzando server cluster per questo tipo di operazione si può aiutare a liberare altre macchine nel sito affinché i servizi rimanenti possano rimanere online. Il clustering è anche utile quando si dispone di risorse hardware più disparate. Ad esempio, un server più vecchio o più lento potrebbe essere collocato proprio nel cluster per eseguire lavori di priorità inferiore.
Per ulteriori informazioni, vedere About GIS server clusters.

Utilizzo di più server web
Per aiutare a garantire un'elevata disponibilità del sito, è anche possibile stabilire ridondanza a livello di web server. Nell’immagine sottostante, due web server con installato Web Adaptor agiscono come punti di ingresso identici nel sito sulla porta 80. Questo aiuta a mantenere il sito in esecuzione in caso di interruzioni non pianificate su uno dei web server. Può anche aiutare a ridurre il carico sulla prima macchina web server.



Sito con ridondanza a livello di web server. I cluster sono facoltativi.

Casi d’uso e vantaggi del sito su più macchine
Il sito su più macchine è ideale per distribuzioni a livello enterprise che necessitano di ospitare più utenti rispetto a quelli che può gestire una singola macchina. Questa architettura può essere scalata per includere tante macchine quante sono necessarie, quindi, moltiplicando la potenza di elaborazione del sito. I GIS Server possono essere aggiunti anche in risposta alla domanda dell’utente. Questo è utile in ambienti cloud come Amazon EC2 che offrono il ridimensionamento automatico basato sulle statistiche di utilizzo.

Il sito su più macchine è anche adatto per i siti che non possono permettersi di avere tempi di inattività. Se un GIS server va offline, gli altri GIS server possono mantenere il sito in esecuzione.

Svantaggi del sito su più macchine
Il sito su più macchine richiede un livello extra di setup e ovviamente più risorse hardware. Poiché il sito è in grado di continuare ad elaborare anche se un GIS server va offline, l'amministratore del server deve impostare il proprio programma di monitoraggio o di schedulazione degli alert per capire se una macchina non è disponibile.



ArcGIS Server è progettato per ospitare piccole e grandi distribuzioni. Quando si inizia a progettare il sito, si potrebbe voler iniziare in piccolo ed installare tutti i componenti su una singola macchina. Se si è pronti per distribuire il sito di produzione, o se si ha bisogno di gestire più utenti, è possibile aggiungere ulteriori GIS server. È inoltre possibile integrare il proprio sito nella propria infrastruttura IT esistente utilizzando il proprio web server enterprise (tramite il Web Adaptor) o data server. Infine, molti dei componenti dell'architettura di ArcGIS Server possono essere duplicati o eseguiti in parallelo per evitare un singolo punto di errore.