Google Distributed Cloud (GDC) air-gapped offre funzionalità di deployment che garantiscono alta disponibilità e ripristino di emergenza. Questa funzionalità è definita multizona in questa pagina.
La funzionalità multizona ti consente di eseguire carichi di lavoro mission-critical disconnessi su GDC fornendo funzionalità di alta disponibilità (HA) e ripristino di emergenza RER) simili a quelle dei provider di servizi cloud hyperscale pubblici. GDC fornisce servizi gestiti e di infrastruttura resilienti ai guasti locali. Per alcuni servizi, devi decidere il livello di resilienza richiesto dal tuo workload. Ecco alcuni esempi di servizi che forniscono funzionalità multizona:
Per un elenco completo dei servizi che forniscono funzionalità multizona, consulta Servizi GDC supportati per più zone.
GDC multizona offre funzionalità di gestione delle risorse globali per semplificare la gestione delle risorse nelle zone GDC. Puoi visualizzare tutte le risorse e tutti i servizi GDC gestiti in un universo con visibilità su avvisi, stato, utilizzo, logging, monitoraggio e fatturazione.
Gli universi multizona in GDC richiedono risorse globali e simmetria hardware. Questa simmetria significa che hardware e organizzazioni devono essere gli stessi in tutte le zone e non possono essere modificati in modo indipendente in una zona specifica.
La funzionalità multizona ti offre anche i componenti di base per raggiungere i tuoi obiettivi di ripristino di emergenza e continuità operativa. Esistono tre funzionalità principali che la funzionalità multizona ti offre:
Continuità dei servizi del control plane. In caso di disastro zonale, le funzionalità critiche necessarie per il recupero di un'organizzazione e dei relativi servizi saranno già presenti in un'altra zona.
Risorse multizona. Ad esempio, la replica asincrona dell'archiviazione tra le zone GDC.
Servizi gestiti multizona. Ad esempio, i bilanciatori del carico offrono varianti multizona controllate da un servizio gestito.
Che cos'è una zona?
Ogni zona può essere un dominio di disastro indipendente a seconda della sua posizione. Ad esempio, due zone posizionate a 1 km di distanza l'una dall'altra in una zona di subduzione si troverebbero nello stesso dominio di emergenza. Ogni zona è un'implementazione completa di GDC con air gap, una soluzione hardware e software che non richiede connettività a Google Cloud in nessun momento. Una zona gestisce l'infrastruttura, i servizi, le API e gli strumenti che utilizzano un control plane locale.
Una zona GDC con air gap è composta da quattro livelli:
Hardware: l'hardware sottostante e il design del rack definiti da Google.
Infrastruttura: gestisce l'hardware e fornisce astrazioni che consentono ai livelli software di essere eseguiti senza riferimento a configurazioni specifiche dell'hardware.
Service Platform: un framework per la creazione di servizi su Distributed Cloud che garantisce la coerenza tra i servizi gestiti e i servizi del marketplace.
Servizi gestiti e Marketplace: servizi cloud rivolti ai clienti in esecuzione su GDC.
Un gruppo di zone air-gap connesse è chiamato universo. Per eseguire il deployment di applicazioni a tolleranza di errore con alta disponibilità che contribuiscono a proteggere da guasti imprevisti, devi eseguire il deployment delle applicazioni in più zone di un universo.
Che cos'è una regione?
Una regione è un raggruppamento di zone in un universo all'interno dei nostri requisiti di latenza definiti. Una zona senza peer sufficientemente vicini è considerata una regione a sé stante. Le zone di una regione devono essere separate da almeno 10 km per garantire che siano domini di ripristino di emergenza separati in molti regimi di conformità.
Le regioni possono distare centinaia di chilometri l'una dall'altra. Per questo motivo, GDC offre solo servizi sincroni all'interno delle regioni; i servizi asincroni sono disponibili all'interno e tra le regioni.
I servizi asincroni eseguono la replica in background, fornendo RPO (Recovery Point Objective) bassi ma diversi da zero. In genere, i servizi asincroni rimangono disponibili durante le partizioni di rete.
Esempi di servizi asincroni con air gap di GDC includono:
- Archiviazione a blocchi
- Archiviazione di oggetti
Le zone all'interno di una singola regione devono soddisfare i requisiti di latenza che consentono la fornitura di servizi fortemente coerenti. I servizi sincroni eseguono immediatamente la replica, garantendo che ogni scrittura sia disponibile in almeno due zone. Questo è il passaggio principale necessario per raggiungere un RPO pari a zero. In genere, i servizi sincroni hanno una latenza maggiore rispetto ai servizi non replicati e potrebbero non essere disponibili durante le partizioni di rete.
Esempi di servizi sincroni con air gap di GDC includono:
- Condivisioni file NFS
- Archiviazione di oggetti
Che cos'è un universo?
Le zone con connettività di rete diretta, indipendentemente dalla distanza o dalla latenza, e un piano di gestione e controllo condiviso appartengono a un universo. Un universo può avere un massimo di sei zone.
Ogni universo può essere costituito da più zone organizzate in regioni interconnesse. Ad esempio, due regioni nello stato della Virginia, negli Stati Uniti, e ad Amsterdam, nei Paesi Bassi, rispettivamente, ciascuna con tre zone:
GDC Region 1 (Virginia)
- Zona 1 (us-virginia1-a)
- Zona 2 (us-virginia1-b)
- Zona 3 (us-virginia1-c)
Regione GDC 2 (Paesi Bassi)
- Zona 1 (eu-ams1-a)
- Zona 2 (eu-ams1-b)
- Zona 3 (eu-ams1-c)
Il seguente diagramma mostra un esempio di universo GDC.
Un universo può avere da 1 a 6 zone e uno o due centri operativi.
Gli universi offrono le seguenti strategie di recupero automatico, indipendentemente dalla configurazione della regione:
- Per gli universi con due zone, il recupero deve essere attivato manualmente.
- Per gli universi con tre o più zone, il recupero può essere attivato automaticamente.
Per ulteriori informazioni, contatta il tuo operatore.
Risorse di zona
Le risorse di zona operano all'interno di una singola zona. Le interruzioni a livello di zona possono interessare alcune o tutte le risorse della zona. Un esempio di risorsa di zona è un'istanza di macchina virtuale (VM) che risiede in una zona specifica. Per saperne di più su come vengono gestite le risorse a livello di zona in un universo GDC, vedi Server API Management.
Risorse globali
Le risorse globali sono risorse di cui viene eseguito il deployment in tutte le zone di un universo, ad esempio le organizzazioni. Ciò offre loro una maggiore disponibilità rispetto alle risorse di zona. Le risorse globali vengono sottoposte a deployment e gestite nel server API di gestione globale.
Per ogni organizzazione, esistono server API di gestione globali e di zona.
Domini di emergenza
Un dominio di disastro rappresenta una raccolta di risorse che potrebbero essere interessate contemporaneamente a causa della vicinanza fisica delle risorse. Pertanto, si tratta di un costrutto correlato alla durabilità utilizzato per semplificare i requisiti per la separazione delle zone. In genere, un singolo dominio di emergenza corrisponde a un singolo campus.
Nella maggior parte degli universi GDC, Google non possiede le strutture, ma collabora con fornitori di colocation che dispongono di data center che forniscono accesso a un'infrastruttura solida, alimentazione ridondante e connettività ad alta velocità. Questo approccio offre prestazioni e tempo di attività ottimali per applicazioni e servizi in base alla strategia e alle best practice di Google per l'alta disponibilità e iREza.
Contatta il tuo operatore per ulteriori informazioni sulle specifiche del dominio di emergenza per il tuo universo.
API globali e zonali
GDC air-gapped offre due livelli di API del piano di gestione per creare e gestire risorse globali e di zona: API globali e API di zona. Consulta la documentazione sui server API di gestione globali e zonali per informazioni su come vengono gestiti questi tipi di API in un universo GDC.
Le API globali e di zona sono API dichiarative di Kubernetes pubblicate su endpoint diversi e le risorse GDC sono rappresentate come risorse personalizzate di Kubernetes nei server API. I server API globali condividono un singolo cluster etcd distribuito tra le zone per fornire elevata coerenza con la tolleranza agli errori, a costo di una latenza maggiore e di un numero di query al secondo (QPS) ridotto rispetto ai server API zonali. In ogni organizzazione, un server API di gestione zonale fornisce l'API zonale per consentire ad amministratori e sviluppatori di gestire le risorse zonali, mentre un server API di gestione globale fornisce l'API globale per gestire le risorse globali.
Per ulteriori informazioni sulle API in GDC, consulta la panoramica delle API.
interfaccia a riga di comando gcloud
gdcloud CLI fornisce modi per interagire con l'API zonale o globale per gestire le risorse e la loro implementazione, tra cui:
- Accedi all'URL della console zonale o globale utilizzando la CLI
- Utilizza un flag CLI zonale per azioni specifiche della zona
L'URL globale è quello configurato per impostazione predefinita quando inizializzi gcloud CLI. Puoi aggiornare la configurazione di gdcloud per impostare gli URL di zona e accedere per completare le attività specifiche della zona.
Allo stesso modo, gcloud CLI offre un flag --zone che puoi impostare per molte attività di gestione delle risorse nei gruppi di comandi. Quando accedi alla configurazione URL globale, le azioni della CLI sulle risorse globali vengono applicate a tutte le zone per le quali sono incluse nell'ambito.
Per saperne di più sull'utilizzo di gcloud CLI per i servizi di zona e globali, consulta Gestire le risorse tra le zone.
Console GDC
La console GDC per una determinata organizzazione è accessibile da ogni zona all'interno dello stesso universo. Pertanto, puoi utilizzare la console GDC per gestire tutte le risorse globali e di zona all'interno di un'organizzazione.
Le seguenti funzionalità multizona sono disponibili dalla console GDC:
Naviga utilizzando un nome di dominio completo (FQDN): puoi utilizzare il nome di dominio completo globale per risolvere automaticamente l'endpoint della console di zona più appropriato. Se la risoluzione del nome di dominio completo (FQDN) globale non va a buon fine per qualsiasi motivo o se vuoi connetterti a una zona specifica, puoi utilizzare il nome di dominio completo (FQDN) zonale per accedere a un endpoint della console specifico in una zona di destinazione.
Gestisci la creazione di risorsa di zona: quando crei una risorsa a livello di zona, è disponibile un selettore di zona che determina la zona in cui viene creata una risorsa. Al contrario, il selettore di zona non è visibile quando crei una risorsa globale.
Visualizza le risorse esistenti nelle zone: varie pagine delle risorse nella console GDC mostrano le risorse per zona. Puoi utilizzare il selettore della zona per visualizzare le risorse della zona scelta. È possibile accedere alle risorse di tutte le zone passando agli URL della console GDC globali e zonali e selezionando la zona appropriata nel selettore, ma non esiste una visualizzazione aggregata delle risorse di tutte le zone.
Per ulteriori informazioni sulla gestione delle risorse in più zone in un universo GDC con la console GDC, vedi Gestire le risorse in più zone.
GDC è progettato per essere resiliente agli errori. Pertanto, se viene rilevato un problema di connettività di zona, la console GDC mostra un banner persistente che ti avvisa che potresti non essere in grado di apportare modifiche alle risorse globali.
Container di risorse
Un'organizzazione definisce un limite di sicurezza delle risorse da amministrare insieme. Ogni organizzazione in GDC air-gapped fornisce un'API globale e un'API di zona per consentire la creazione di risorse globali e di zona all'interno dell'organizzazione. Quando crei un'organizzazione globale, l'operatore è responsabile del deployment delle zone e della configurazione delle impostazioni di zona, ad esempio la quantità di spazio di archiviazione e il numero di server fisici disponibili per i carichi di lavoro degli utenti.
Per ulteriori informazioni sulla configurazione di zone specifiche per la tua organizzazione, contatta il tuo operatore.
Un progetto fornisce un raggruppamento logico delle risorse di servizio all'interno di un'organizzazione e fornisce un ciclo di vita e un limite dei criteri per la gestione delle risorse. Per impostazione predefinita, tutti i progetti sono globali e coprono le zone che hai configurato nel tuo universo.
Sebbene tutte le risorse di servizio debbano essere create in un progetto, non tutti i servizi sono globali. Per i servizi supportati solo a livello di zona, devi eseguirne il deployment e gestirli all'interno delle zone che scegli. Per ulteriori informazioni, consulta la documentazione appropriata di un tipo di risorsa.
IAM
I seguenti servizi Identity and Access Management (IAM) devono essere configurati come risorse globali:
- Provider di identità (IdP) per l'autenticazione
- Controllo degli accessi basato su ruoli (RBAC)
- Identità di servizio
Ogni configurazione IAM si estende a tutte le zone di un universo.
Autenticazione
Devi connettere un IdP alla tua organizzazione utilizzando la risorsa globale
IdentityProviderConfig. Questa risorsa garantisce che tu utilizzi lo stesso IdP per connetterti alla tua organizzazione per tutte le zone dell'universo.
Per saperne di più, vedi Stabilire la connessione a un provider di identità.
Accesso
A ogni utente o gruppo deve essere assegnata una risorsa globale
IAMRoleBinding
per accedere ai server API di gestione globali e di zona e ai cluster Kubernetes in modo coerente in ogni zona dell'organizzazione.
Accesso al server API Global Management:
IAMRoleBindingviene propagato comeClusterRoleBindingoRoleBindinga unClusterRolepredefinito nel server API globale.Accesso al server API Management zonale:
IAMRoleBindingviene propagato comeClusterRoleBindingoRoleBindingnel server API Management zonale.Accesso al cluster Kubernetes:
IAMRoleBindingviene propagato comeProjectRoleeProjectRoleBindingda propagare comeRoleeRoleBindingdi Kubernetes agli spazi dei nomi Kubernetes nel server API di gestione e nei cluster Kubernetes, corrispondenti al progetto in cui si trovanoProjectRoleeProjectRoleBinding.
Per maggiori informazioni, vedi Concedere e revocare l'accesso.
Identità di servizio
I service account sono entità utente utilizzate da servizi e workload per
utilizzare le risorse in modo programmatico e accedere in sicurezza ai microservizi. Si tratta di un tipo speciale di identità utilizzata da un'applicazione o da un workload anziché da una persona. Analogamente a un account utente, ai service account possono essere concessi autorizzazioni
e ruoli, ma non possono accedere come un utente umano. La funzionalità
identità del servizio è inclusa
nella risorsa globale
ProjectServiceAccount.
Per ulteriori informazioni, consulta Autenticarsi con i service account.
Networking
Puoi configurare i seguenti servizi di rete per le tue zone GDC:
- Servizi Anycast
- Bilanciamento del carico
- Policy di rete del progetto
- DNS
Configura i servizi di rete globali e di zona per gestire il traffico di rete tra zone e all'interno della zona nel tuo universo GDC.
Servizi Anycast
Multi-zone fornisce servizi di rete Anycast per garantire l'alta disponibilità tra le risorse di più zone. Allo stesso modo, le opzioni di interconnessione dei data center (DCI) vengono implementate come una mesh completa per interconnettere più zone air-gap GDC. Ciò consente a GDC di fornire protezione da disastri multizona in più località, soddisfacendo al contempo il requisito di disconnessione completa da qualsiasi infrastruttura Google.
I servizi Anycast sono rappresentati da prefissi IPv4 /32 univoci, forniti utilizzando il protocollo Border Gateway Protocol (BGP) alle strutture del cliente, garantendo la raggiungibilità da qualsiasi rete connessa. Sebbene ogni servizio Anycast sia accessibile da tutte le zone all'interno della rete isolata GDC, l'endpoint effettivo a cui viene indirizzato il traffico dipende da fattori come la vicinanza e la preferenza di zona in base al criterio di routing personalizzato.
La distribuzione del traffico viene ottimizzata indirizzandolo all'istanza di servizio disponibile più vicina, sempre all'interno della stessa zona della connessione del cliente. Ciò non solo riduce la latenza, ma migliora anche le prestazioni e la reattività complessive del servizio. Ad esempio, se un servizio Anycast viene implementato nelle zone 1, 2 e 3, una richiesta del cliente proveniente dalla zona 2 viene in genere indirizzata all'istanza del servizio all'interno della zona 2, in quanto è l'opzione più vicina e, pertanto, più efficiente.
Sebbene l'intervallo Anycast sia accessibile a livello globale, viene fornito solo ai clienti delle zone specifiche in cui il servizio è attivamente implementato. Questa configurazione di accesso significa che un servizio di cui è stato eseguito il deployment nella zona 1 sarebbe disponibile solo per i clienti connessi alla zona 1 e non per quelli connessi ad altre zone.
Inoltre, GDC implementa un sistema di preferenze per le zone
in cui alle zone viene assegnato un valore numerico durante la creazione, indipendentemente dal
nome della zona, che imposta l'attrazione dei clienti. Ad esempio, se un servizio Anycast viene
implementato in zone con valori numerici 1, 2 e 3, il traffico dei clienti
viene generalmente indirizzato verso la zona con il valore più basso impostato prima
delle altre zone come posizione preferita. Questo sistema di preferenze offre un
certo grado di prevedibilità e controllo sui pattern di traffico, ma include anche
meccanismi di failover integrati. In caso di errore o interruzione che interessa la
zona preferita, il sistema sposta automaticamente il traffico in un'altra zona,
garantendo la disponibilità del servizio senza interruzioni.
In una configurazione multizona, l'accesso ai servizi all'interno di una zona specifica richiede un'interconnessione dalla tua rete a quella zona. Per un deployment multizona coerente, gli interconnessioni create in ogni zona del tuo universo devono essere identiche in termini di capacità e configurazione. Ogni zona a cui intendi accedere deve avere un'interconnessione corrispondente, dove queste interconnessioni sono identiche tra loro.
Per ulteriori informazioni, contatta il tuo operatore.
Bilanciamento del carico
GDC fornisce un bilanciatore del carico pass-through L4 per Kubernetes e carichi di lavoro delle VM. Questo bilanciatore del carico fornisce le seguenti configurazioni:
- Protocollo TCP o UDP.
- Nessun proxy tra il workload e il client.
- Bilanciamento del carico dedicato per zone specifiche o a livello globale in tutte le zone dell'universo.
- Traffico di rete interno all'interno dell'organizzazione o traffico di rete esterno tra le organizzazioni.
Il seguente diagramma illustra i componenti di un bilanciatore del carico passthrough esterno di livello 4 in un universo GDC:
Il bilanciatore del carico può essere ottimizzato per funzionare all'interno di una singola zona o a livello globale per tutte le zone.
Per saperne di più sul bilanciamento del carico in GDC, consulta Gestire i bilanciatori del carico.
Policy di rete del progetto
I criteri di rete del progetto definiscono regole di trasferimento di dati in entrata o in uscita per un progetto. Poiché i progetti sono una risorsa globale, devi definire le policy di rete di un progetto anche a livello globale, per consentire il traffico di rete tra zone per i servizi e i carichi di lavoro all'interno di un progetto.
Per saperne di più, consulta la pagina Configurare i criteri di rete del progetto.
DNS
I servizi DNS (Domain Name System) sono globali e si estendono su più zone. Se un'istanza del servizio DNS diventa inaccessibile in una zona, i client vengono serviti senza problemi da un'altra istanza del servizio DNS in un'altra zona.
Ogni organizzazione in una zona contiene tre server DNS autorevoli globali:
Server interno dell'infrastruttura globale:il server autorevole che risolve le richieste DNS all'interno della rete Virtual Private Cloud (VPC) dell'infrastruttura. Questo server gestisce solo i carichi di lavoro dell'infrastruttura. I carichi di lavoro utente non interagiscono con questo componente. Tutti i deployment interni dell'infrastruttura globale per un'organizzazione in tutte le zone sono accessibili con un indirizzo IP Anycast.
Server interno del cliente globale:il server autorevole che risolve le richieste DNS all'interno della rete Virtual Private Cloud (VPC) del cliente. Questo server gestisce solo i carichi di lavoro degli utenti, ad esempio un pod in un cluster Kubernetes o una macchina virtuale (VM), e risolve tutte le richieste DNS provenienti da questi carichi di lavoro degli utenti. Tutti i deployment interni dei clienti globali per un'organizzazione in tutte le zone sono accessibili con un indirizzo IP anycast. Poiché i VPC si estendono su più zone, una richiesta di risoluzione di un nome di dominio completo (FQDN) globale da una zona può essere indirizzata a una qualsiasi delle zone integre.
Server esterno del cliente globale:il server autorevole che risolve le richieste DNS provenienti dalla rete del cliente. Tutti i deployment esterni dei clienti globali per un'organizzazione in tutte le zone sono accessibili con un indirizzo IP anycast.
Puoi connetterti a GDC con una rete esterna dedicata o una rete esterna condivisa. Questi tipi di rete determinano in che modo GDC risolve le tue richieste DNS.
Una rete esterna dedicata si connette direttamente al server DNS esterno globale del cliente, che risolve la richiesta. In alternativa, una rete esterna condivisa si connette alla radice della gerarchia DNS. Questo server radice fornisce il record NS (Name Server) della richiesta per la zona DNS appropriata al server DNS esterno del cliente globale. Il resolver DNS risolve quindi la richiesta in modo ricorsivo.
GDC fornisce la risoluzione DNS per il traffico interno ed esterno a livello globale e all'interno di una singola zona.
Le richieste provenienti dalla tua rete esterna vengono instradate dal tuo resolver DNS. Allo stesso modo, le richieste DNS interne provengono dai tuoi carichi di lavoro all'interno di un universo GDC.
Le richieste DNS hanno il seguente formato FQDN:
- Richieste DNS globali:
SERVICE_NAME.ORG_NAME.SUFFIX, ad esempioservice-1.org-1.google.com. - Richieste DNS di zona:
SERVICE_NAME.ORG_NAME.ZONE_NAME.SUFFIX, ad esempioservice-1.org-1.zone-1.google.com.
Per ulteriori informazioni su come configurare il networking all'interno di un universo GDC, consulta Panoramica del networking.
Archiviazione
Per la versione 1.14.4 e successive, gli universi multizona offrono l'utilizzo di risorse di archiviazione replicate, come volumi e bucket, in modalità asincrona per scenari di ripristino di emergenza. Queste opzioni di risorse di archiviazione forniscono la replica asincrona dei dati tra due zone qualsiasi dello stesso universo. La replica asincrona viene eseguita in background, fornendo un RPO basso, ma non nullo, in caso di emergenza. Tutti i dati replicati sono online e immediatamente accessibili, ma potrebbero richiedere una procedura di failover manuale per abilitare la scrittura nella zona secondaria.
Replica asincrona dei blocchi:fornisce volumi replicati in modo asincrono (PV), che mantengono l'equivalenza dei blocchi tra i volumi primario e secondario. A causa della natura asincrona, il volume secondario rifletterà lo stato del volume primario in un momento del passato (RPO diverso da zero). Il volume secondario non è montabile finché rimane la destinazione della replica, il che richiede un intervento manuale per terminare la relazione e consentire le scritture.
Replica asincrona dei bucket:i bucket replicati vengono accoppiati tra le zone, creando una relazione di replica dei dati bidirezionale. I dati degli oggetti scritti nei bucket della zona principale o secondaria utilizzando questa funzionalità vengono copiati nell'altra zona. Poiché i dati vengono copiati in modo asincrono, i bucket potrebbero non contenere le stesse versioni degli oggetti in un determinato momento, ma alla fine diventeranno coerenti se non vengono apportate modifiche aggiuntive. A differenza della replica dei volumi, i bucket replicati sono scrivibili durante le partizioni di zona. Ogni scrittura in un oggetto produce una versione diversa e l'ultima versione in una zona sarà lo stato finale dopo il ripristino della connettività.
Requisiti di latenza
Per assicurarti di poter pianificare le posizioni delle zone GDC per le funzionalità attuali e future, basiamo i requisiti di latenza su Google Cloud. Questo approccio ti consente di scegliere con sicurezza le posizioni air-gapped di GDC sapendo se queste zone si troveranno nella stessa regione.
La latenza massima supportata è inferiore a 1 ms di tempo di round trip (RTT) a livello fisico tra due zone qualsiasi di una regione. Poiché il calcolo della latenza a livello fisico richiede apparecchiature specializzate non disponibili nella maggior parte delle istanze, questa può essere approssimata misurando la lunghezza della fibra tra due zone.
Una lunghezza della fibra per le zone di una regione di 50 km sul percorso principale e 100 km sul percorso secondario supporterà i servizi regionali. In una rete ad anello, questo requisito significa che ogni segmento di fibra non può superare i 50 km.
Contatta il tuo operatore per ulteriori informazioni sui requisiti di latenza specifici.
Passaggi successivi
- Scopri di più sui server API globali e di zona disponibili in un universo GDC.
- Consulta la Guida all'alta disponibilità per assicurarti che la tua applicazione sia resiliente ai guasti della zona locale.
- Per ulteriori informazioni su come vengono gestite le risorse in modo gerarchico all'interno di una zona, consulta la pagina Gerarchia delle risorse.