Informazioni sulla gestione degli errori

La topologia cluster estesa di Oracle Fusion Middleware (FMW) è resiliente agli errori in qualsiasi singolo componente.

Ogni sito segue le procedure ottimali per l'alta disponibilità descritte nella topologia di distribuzione Oracle FMW Enterprise, assicurando che la ridondanza locale protegga dalle interruzioni a livello di componente (ad esempio il load balancer, le istanze di Oracle HTTP Server, Oracle WebLogic Server o l'istanza di database).

Le considerazioni per affrontare scenari quali un errore di livello completo all'interno di un sito o un errore totale del sito sono discusse nelle sezioni seguenti.

Gestire l'errore di tutti i server Web in un unico sito

Se un sito perde tutte le istanze di Oracle HTTP Server, il sistema frontend (che sia un load balancer globale o un criterio di indirizzamento per la gestione del traffico di Oracle Cloud Infrastructure (OCI)) deve contrassegnare il sito come in cattivo stato.

Tutte le richieste del cliente, indipendentemente dalla loro preferenza del sito, saranno indirizzate all'altro sito.

Pertanto, i server Oracle WebLogic del sito con server Web non riusciti non riceveranno nuove richieste. Possono continuare a eseguire alcune elaborazioni (ad esempio, l'elaborazione dei composti di Oracle SOA e dei messaggi JMS (Java Message Service). Tuttavia, qualsiasi callback HTTP generato internamente da questi server non riuscirà perché puntano al proprio sito, i cui server Web non sono riusciti.

Il diagramma seguente mostra gli errori in tutti i server Web di un sito

Descrizione dell'illustrazione failure-all-web-servers-one-site.png

guasti-tutti-server-web-un-sito-oracle.zip

Recupera da errore

Non è necessario alcun intervento manuale per il recupero immediato da un guasto in tutti i server web di un sito.

I client vengono reindirizzati automaticamente all'altro sito grazie ai criteri di indirizzamento di Oracle Cloud Infrastructure (OCI) Traffic Management o al load balancer globale (GLBR).

Se il ripristino delle istanze del server Web perse non è possibile a breve termine, è possibile eseguire le operazioni riportate di seguito per utilizzare i server WebLogic del sito con il livello Web non riuscito.

1. Configurare le istanze di Oracle HTTP Server (OHS) nell'altro sito per instradare le richieste alle istanze di Oracle WebLogic Server nel sito in cui si è verificato l'errore.
   1. Aggiornare la configurazione OHS e impostare il parametro DynamicServerList su ON.
   2. Applicare questa modifica riavviando OHS in sequenza per evitare tempi di inattività.
   3. Inoltre, assicurarsi che la comunicazione tra più aree sia consentita dai server Web ai server WebLogic dell'altro sito.
2. Per evitare errori nei callback del protocollo HTTP (Hypertext Transfer Protocol) provenienti dal sito con server OHS non disponibili, aggiornare la voce per il nome del frontend nel file /etc/hosts degli host del server WebLogic o nel DNS (Private Domain Name System) per puntare al load balancer nell'altro sito.

Dopo aver reso disponibili i server non riusciti:

1. Avviare i processi OHS nel sito con errori.

   Non appena Oracle Cloud Infrastructure Health Checks sarà nuovamente a posto, il criterio di indirizzamento della gestione del traffico bilancierà il carico delle richieste client tra entrambi i siti, in base alle regole definite.

2. Impostare nuovamente DynamicServerList su OFF nell'altro sito.
3. Ripristinare qualsiasi modifica nel file /etc/hosts (o nel DNS privato) dei server WebLogic in modo che puntino di nuovo al load balancer del proprio sito.

L'immagine seguente mostra i messaggi di coda di Java Message Service (JMS) e le richieste client non riuscite durante un errore di tutti i server Web in un sito:

Descrizione dell'illustrazione failure-messages-all-web-servers-one-site.png

Obiettivo tempo di recupero previsto

Quando si utilizzano i criteri di indirizzamento per la gestione del traffico di Oracle Cloud Infrastructure (OCI) per il bilanciamento globale, gli errori vengono osservati durante un periodo di circa 1 minuto + DNS time to live (TTL).

L'aggiornamento DNS interessa i client la cui preferenza del criterio di indirizzamento è impostata sull'area non riuscita. Il valore TTL determina per quanto tempo questi client continueranno a utilizzare la vecchia voce prima di aggiornarla per puntare al sito in buono stato. Il tempo aggiuntivo (circa 1 minuto) dipende dalla frequenza e dal timeout dei controlli dello stato configurati nel criterio di indirizzamento OCI (nel test precedente sono stati utilizzati 30 secondi per l'intervallo di controllo dello stato e un timeout di 10 secondi).

Quando si utilizza un load balancer globale (GLBR, global load balancer), il tempo di indisponibilità dipende dalla frequenza dei controlli dello stato configurati in GLBR. Non appena il GLBR contrassegna un pool come malsano, le richieste in entrata verranno reindirizzate all'altro sito. Con un GLBR, non c'è alcun aggiornamento DNS, quindi il valore TTL della voce front-end è irrilevante.

Gestire l'errore di tutti i server Oracle WebLogic in un unico sito

Quando tutti i server WebLogic vengono disattivati in un sito, l'altro sito continua a elaborare le richieste.

Il load balancer del sito in cui si è verificato l'errore restituirà una risposta non riuscita, pertanto la funzione di bilanciamento globale frontend, basata sui criteri di indirizzamento del traffico e sui controlli dello stato di Oracle Cloud Infrastructure (OCI), dovrebbe contrassegnare il sito come in cattivo stato. Tutte le richieste del cliente, indipendentemente dalla loro preferenza, saranno indirizzate all'altro sito.

I servizi WebLogic JMS (Java Message Service) e JTA (Java Transaction API) eseguiranno automaticamente la migrazione ai server nell'altro sito quando si utilizza la migrazione automatica dei servizi insieme alle aree di memorizzazione persistenti JDBC (Java Database Connectivity).

Nel caso SOA di Oracle Fusion Middleware (FMW), se il master del cluster di recupero automatico è ospitato nei server con errori, verrà generato un nuovo master del cluster nel sito disponibile. Questo server esegue il recupero automatico delle istanze SOA avviate nell'altro sito.

Il seguente diagramma mostra l'errore di tutti i server WebLogic in un unico sito:

Descrizione dell'illustrazione failure-all-weblogic-servers-one-site.png

errori-all-weblogic-servers-one-site-oracle.zip

L'immagine seguente mostra le richieste client non riuscite e i messaggi JMS per server quando tutti i server WebLogic non riescono in un sito.

Descrizione dell'illustrazione failure-messages-all-weblogic-servers-one-site.png

Nel grafico dei messaggi JMS sono presenti quattro righe, ognuna delle quali rappresenta la coda JMS di un server. Le linee verde e blu (che sono quasi sovrapposte) corrispondono ai server che sono stati uccisi. Il numero di messaggi JMS per queste code non aumenta dopo l'inizio dell'interruzione.

Le linee rosso e giallo rappresentano i server che rimangono nella regione 2. Quando tutte le richieste vengono reindirizzate a quest'area, ogni server rimanente riceve il 50% del carico totale. Tuttavia, la frequenza con cui i messaggi si accumulano nelle code è diversa. Ciò è dovuto al fatto che i server JMS dei server non riusciti sono stati migrati a uno dei server rimanenti, pertanto i messaggi in tale server sono ora elaborati da tre code. Di conseguenza, la pendenza appare più bassa in quella gialla (si noti che lo strumento di monitoraggio non visualizza il conteggio dei messaggi per le code migrate).

Recupera da errore

Non è necessario alcun intervento manuale per il ripristino immediato da un errore in tutti i server Oracle WebLogic Server in un unico sito.

Dopo aver reso disponibili i server non riusciti:

1. Avviare i server gestiti nel sito con errori.
2. Non appena Oracle Cloud Infrastructure Health Checks sarà nuovamente in buono stato, il criterio di indirizzamento Gestione del traffico bilancierà il carico delle richieste client tra entrambi i siti, in base alle regole definite.

Obiettivo tempo di recupero previsto

Quando si utilizzano i criteri di indirizzamento per la gestione del traffico di Oracle Cloud Infrastructure (OCI) per il bilanciamento globale, gli errori vengono osservati durante un periodo di circa 1 minuto + DNS time to live (TTL).

Questo è simile allo scenario in cui c'è un errore in tutti i server web su un sito,

L'aggiornamento DNS interessa i client la cui preferenza del criterio di indirizzamento è impostata sull'area non riuscita. Il valore TTL determina per quanto tempo questi client continueranno a utilizzare la vecchia voce prima di aggiornarla per puntare al sito in buono stato. Il tempo aggiuntivo (circa 1 minuto) dipende dalla frequenza e dal timeout dei controlli dello stato configurati nel criterio di indirizzamento Gestione traffico OCI (30 secondi sono stati utilizzati nel test per l'intervallo di controllo dello stato e un timeout di 10 secondi).

Quando si utilizza un load balancer globale (GLBR, global load balancer), il tempo di indisponibilità dipende dalla frequenza dei controlli dello stato configurati in GLBR. Non appena il GLBR contrassegna un pool come malsano, le richieste in entrata verranno reindirizzate all'altro sito. Con un GLBR, non c'è alcun aggiornamento DNS, quindi il valore TTL della voce front-end è irrilevante.

Gestisci errori nel database: switchover e failover Data Guard

Se un problema interessa solo il database primario, eseguire lo switchover o il failover del database nell'altro sito il prima possibile.

La stringa dell'URL di Java Database Connectivity (JDBC) e la configurazione di Oracle Notification Service (ONS) fornita in precedenza in "Imposta origini dati WebLogic" garantiscono che la riconnessione venga eseguita automaticamente al nuovo database primario. Per questi test precisi (utilizzando Oracle Fusion Middleware (FMW) SOA FOD e anche con carichi di lavoro elevati di 160 richiami concorrenti), lo switchover o il failover del database richiede meno di un paio di minuti. Questa volta può variare in base alla configurazione del sistema e all'ambiente. Nei sistemi ottimizzati, i tempi di switchover di 1-5 minuti sono comuni, ma fattori come le dimensioni del sistema, le risorse, il carico di lavoro, la sincronizzazione dei redo log e le prestazioni della rete possono influire sulla durata totale. Consulta la sezione Esplora altro per i collegamenti alla documentazione di Oracle Data Guard e ad altre risorse.

Durante uno switchover o un failover del database si verificheranno errori dell'applicazione. Inoltre, i server WebLogic che utilizzano la migrazione del servizio possono essere arrestati e riavviati automaticamente da Node Manager se non sono in grado di aggiornare la tabella di leasing. Il comportamento previsto con i parametri di leasing predefiniti è:

1. Se l'interruzione del database è molto breve (<1-2 minuti), non è previsto alcun riavvio automatico del server WebLogic.
2. Se l'indisponibilità del database è più lunga (2-10 minuti), i server WebLogic possono riavviarsi automaticamente a causa della perdita di un leasing quando il database viene riavviato.

   Il limite inferiore può essere aumentato eseguendo il tuning dei nuovi tentativi di leasing del database di WebLogic, come descritto in precedenza in "Configure Tuning WebLogic Database Leasing".

3. Se l'indisponibilità del database è molto più lunga (>10 minuti), i server WebLogic possono riavviarsi automaticamente a causa di altri errori come la perdita dell'accesso alle aree di memorizzazione JDBC critiche ("l'area di memorizzazione JDBC di JTA non è disponibile").

Il diagramma seguente mostra lo switchover del database nella topologia dei cluster estesi FMW

Descrizione dell'illustrazione stretched-clusters-db-switchover.png

stretched-clusters-db-switchover-oracle.zip

L'immagine riportata di seguito mostra le prestazioni delle richieste client e i messaggi JMS (Java Message Service) per coda server durante uno switchover del database in un cluster esteso FMW.

Descrizione dell'illustrazione stretched-clusters-db-switchover-messages.png

Recupera da errore

Per eseguire immediatamente il ripristino da un errore del database:

1. Eseguire uno switchover del database utilizzando la console di Oracle Cloud Infrastructure (OCI) o l'interfaccia della riga di comando del broker Oracle Data Guard.
2. Se il database primario non è disponibile, eseguire un failover del database dal server in standby.

   I server di Oracle WebLogic Server si riconnettono automaticamente al nuovo database primario, pertanto non sono necessarie azioni manuali ad eccezione del ripristino da errori specifici dell'applicazione in base alle esigenze (ad esempio, in Oracle SOA Suite potrebbe essere necessario recuperare i composti in Error Hospital).

Dopo aver reso disponibili i server non riusciti:

1. Ripristinare il database in errore se è stato eseguito un failover del database.

   Questa azione non è necessaria se è stato eseguito uno switchover.

2. Eseguire uno switchback del database al sito originale.

Obiettivo tempo di recupero previsto

Per uno switchover pianificato, il tempo totale di recupero è breve e dipende dal tempo necessario al database per lo switchover o il failover.

Per i test eseguiti, lo switchover richiede meno di 2 minuti.

Per uno switchover o un failover non pianificato, il tempo di inattività totale dipende dal tempo di inattività del database:

• Se si esegue il failover o lo switchover del database quasi immediatamente, il tempo totale per il recupero è breve. Dipende dal tempo necessario al database per lo switchover o il failover. Per i test eseguiti, lo switchover richiede meno di 2 minuti, quindi il recovery time objective (RTO) previsto è il seguente:

  RTO = DB DOWNTIME + SHORT TIME (1-2 min)

• Se il tempo di inattività del database è più lungo, possono verificarsi errori aggiuntivi, come il riavvio automatico di Oracle WebLogic Server, che aumentano l'RTO. In questo caso la RTO prevista è:

  RTO = DB DOWNTIME + WEBLOGIC START TIME

Gestire gli errori nel server di amministrazione WebLogic

Gli errori di processo per il server di amministrazione vengono gestiti da Node Manager WebLogic in tale nodo.

Node Manager riavvierà automaticamente il server non riuscito in loco.

Tuttavia, è necessario eseguire il failover del server di amministrazione su un nodo diverso se un'interruzione interessa completamente l'host in cui viene eseguito il server di amministrazione.

In sostanza, questo consiste nel riavviare il server di amministrazione in un nodo diverso, assicurandosi che punti alla posizione che contiene la directory del dominio del server di amministrazione e che utilizzi un indirizzo di ascolto mappato all'IP virtuale appropriato (VIP).

Questa directory del dominio del server di amministrazione può essere una posizione di memorizzazione condivisa disponibile per nodi diversi nella stessa area o un ripristino da un backup o da una replica del file system resa disponibile per i nodi in un'area diversa.

Nota

Indipendentemente dalla configurazione del cluster estesa, si prevede che siano in atto le procedure di backup appropriate per il dominio Oracle WebLogic.

Pertanto, in una topologia cluster estesa di Oracle Fusion Middleware (FMW), si applicano considerazioni diverse quando si esegue la migrazione del server di amministrazione a un nodo in un'area diversa rispetto a quando si esegue la migrazione a un nodo nella stessa area.

Il diagramma seguente mostra il failover del server di amministrazione sull'altro sito nel cluster esteso FMW

Descrizione dell'illustrazione failure-admin-server.png

errori-admin-server-oracle.zip

Failover in un'area diversa

Per eseguire il failover del server di amministrazione in un'area diversa, attenersi alla procedura riportata di seguito.

1. Rendere disponibile il backup della directory di dominio del server di amministrazione (ASERVER_HOME) nel sito di failover.
2. Ripristinare la directory ASERVER_HOME (compresa la directory del dominio e delle applicazioni) nel sito di failover in modo che la stessa struttura di directory del dominio sia coerente con il sito originale.
3. Le subnet nell'area 1 e nell'area 2 in genere utilizzano blocchi CIDR (Classless Inter-Domain Routing) diversi. Di conseguenza, l'IP virtuale (VIP) utilizzato dal server di amministrazione nell'area 1 (ad esempio 10.10.10.1) non è valido nell'area 2. Quando il server di amministrazione viene eseguito nell'area 2, verrà utilizzato un VIP diverso (ad esempio 20.20.20.1). Aggiornare la risoluzione del nome host in modo che l'indirizzo di ascolto del server di amministrazione (ADMINHOSTVHN) sia mappato al nuovo VIP.
   1. Assegna e collega un IP virtuale all'host che eseguirà il server di amministrazione nell'area 2, come descritto nel blog Uso di un IP virtuale (VIP) in Oracle Cloud Infrastructure.
   2. Aggiornare le viste private /etc/hosts o DNS (Domain Name System) in entrambe le aree per modificare il record ADMINHOSTVHN dall'IP precedente (ad esempio 10.10.10.1) al nuovo IP (ad esempio 20.20.20.1).
4. Modificare il file $NM_HOME/nodemanager.domains nel nodo in cui verrà ripristinato il server di amministrazione per includere il file ASERVER_HOME e riavviare Node Manager:

   domain_name=MSERVER_HOME;ASERVER_HOME

5. Avviare il server di amministrazione nel nuovo host.
6. Le istanze di Oracle HTTP Server utilizzano una cache DNS, controllata dalla direttiva WLDNSRefreshInterval in mod_wl_ohs.conf. È 0 per impostazione predefinita, che significa "cache per sempre". È necessario riavviare OHS per aggiornare la cache di risoluzione DNS. Sono disponibili due approcci:
   1. Riavviare i server OHS per aggiornare la cache di risoluzione DNS.
   2. Oppure impostare un valore diverso da zero per WLDNSRefreshInterval in mod_wl_ohs.conf.

   In caso contrario, OHS continuerà a cercare di connettersi al server di amministrazione con l'indirizzo IP precedente.

Verificare che il server di amministrazione funzioni correttamente accedendo sia alla WebLogic Remote Console che a Oracle Enterprise Manager Fusion Middleware Control.

Failover nella stessa area

Per eseguire il failover del server di amministrazione su un host nella stessa area, non è necessario copiare la directory di dominio del server di amministrazione e il valore dell'IP virtuale (VIP) non cambia.

Pertanto, la procedura di failover è la stessa descritta in Enterprise Deployment Guide per il server di amministrazione, in Verifica del failover manuale del server di amministrazione.

Per gestire l'IP virtuale (VIP) del server di amministrazione nei sistemi Oracle Cloud Infrastructure (OCI), è possibile utilizzare i passi descritti nel blog Using a Virtual IP (VIP) in Oracle Cloud Infrastructure

Gestisci errore dell'intera area che ospita il database primario

Se un'indisponibilità interessa l'intera area 1, eseguire lo switchover o il failover del database nell'altro sito/area il prima possibile.

Le istanze di Oracle WebLogic Server nel sito rimanente si riconnetteranno automaticamente al nuovo database primario se utilizzano la configurazione consigliata descritta nella sezione precedente.

Il load balancer del sito non riuscito restituirà una risposta non riuscita, pertanto la funzione di bilanciamento globale front-end deve contrassegnare il sito come in cattivo stato. Tutte le richieste del cliente, indipendentemente dalla loro preferenza, saranno indirizzate all'altro sito.

I servizi JMS e JTA WebLogic eseguiranno automaticamente la migrazione ai server nell'altro sito quando si utilizza la migrazione automatica del servizio insieme alle aree di memorizzazione persistenti JDBC. Nel caso di Oracle Fusion Middleware (FMW) Oracle SOA Suite, se il master del cluster di recupero automatico è ospitato nei server con errori, nel sito disponibile verrà generato un nuovo master del cluster. Il nuovo cluster manager eseguirà il recupero automatico delle istanze SOA avviate nell'altro sito.

Il diagramma seguente mostra il guasto dell'intera area 1 nella topologia dei cluster estesi FMW:

Descrizione dell'illustrazione failure-entire-region.png

guasti-intera-regione-oracle.zip

Recupera da errore

Per eseguire immediatamente il ripristino da un errore completo nell'area 1:

1. Eseguire uno switchover del database utilizzando la console di Oracle Cloud Infrastructure (OCI) o l'interfaccia della riga di comando del broker Oracle Data Guard.

   Se il database primario non è disponibile, eseguire un failover del database dal server in standby.

2. Le istanze di Oracle WebLogic Server si riconnettono automaticamente al nuovo database primario, pertanto non sono necessarie azioni manuali ad eccezione del ripristino da errori specifici dell'applicazione (ad esempio, in Oracle SOA Suite potrebbe essere necessario recuperare i composti in Error Hospital).
3. Se necessario, eseguire un failover del server di amministrazione nell'area 2.

Dopo il recupero del sito non riuscito ed è nuovamente disponibile:

1. Riavviare i processi negli host con errori: server HTTP Oracle, server di amministrazione WebLogic e server gestiti.

   Assicurarsi che l'IP virtuale (VIP) del server di amministrazione sia impostato e che non esistano file isolati che impediscano l'avvio.

2. Ripristinare il database in errore se è stato eseguito un failover del database.

   Questa azione non è necessaria se è stato eseguito uno switchover.

3. Eseguire uno switchover del database al sito originale.

Obiettivo tempo di recupero previsto

Mentre il database è inattivo, il sistema non sarà disponibile.

I server nel sito rimanente possono continuare a elaborare le richieste non appena il database viene nuovamente eseguito nel sito rimanente, quindi il tempo di inattività dipende dal tempo utilizzato prima di passare al database.

• Se si esegue il failover o lo switchover del database quasi immediatamente, il tempo totale per il recupero è breve. Dipende dal tempo necessario al database per lo switchover o il failover. Per il test eseguito, lo switchover richiede meno di 2 minuti, quindi l'RTO previsto è:

  RTO = DB DOWNTIME + SHORT TIME (1-2 min).

• Se il tempo di inattività del database è più lungo, possono verificarsi errori aggiuntivi, come il riavvio automatico di Oracle WebLogic Server, che aumentano l'RTO. L'RTO previsto è:

  RTO = DB DOWNTIME + WEBLOGIC START TIME

Gestisci errore dell'intera area che ospita il database in standby

Se un errore interessa l'intera area 2, la funzione di bilanciamento globale del frontend deve contrassegnare il sito come in cattivo stato.

Tutte le richieste del client, indipendentemente dalle preferenze del sito, verranno instradate all'area 1, che continua a elaborare le richieste. I servizi JMS e JTA WebLogic eseguiranno automaticamente la migrazione ai server nel sito 1 quando si utilizza la migrazione automatica del servizio insieme alle aree di memorizzazione persistenti JDBC.

Nel caso Oracle Fusion Middleware (FMW) con Oracle SOA Suite, se il master del cluster di recupero automatico è ospitato nei server con errori, nel sito disponibile verrà generato un nuovo master del cluster. Questo server esegue il recupero automatico delle istanze SOA avviate nell'altro sito.

Non è necessario eseguire uno switchover del database poiché l'indisponibilità non influisce sul database primario.

Il diagramma seguente mostra l'errore dell'intera area 2 nella topologia dei cluster estesi FMW.

Descrizione dell'illustrazione failure-standby-db-region.png

errori-standby-db-region-oracle.zip

Recupera da errore

Non è necessario alcun intervento manuale per il recupero immediato da un guasto completo nella regione 2.

Dopo che il sito non riuscito sarà di nuovo disponibile, riavviare i processi negli host non riusciti per i server HTTP Oracle e i server gestiti WebLogic.

Assicurarsi che non siano presenti file isolati che impediscono l'avvio di WebLogic.

Grazie alla funzione di load balancer globale (criteri di indirizzamento per la gestione del traffico di Oracle Cloud Infrastructure o un load balancer globale), le richieste del client verranno ribilanciate tra i 2 siti.

Obiettivo tempo di recupero previsto

Quando si utilizzano i criteri di indirizzamento del traffico di Oracle Cloud Infrastructure (OCI) per il bilanciamento globale, il periodo con errori è di circa 1 minuto in più rispetto al time to live (TTL) della voce frontend definita nel criterio di indirizzamento.

L'aggiornamento del DNS (Domain Name System) influisce sui client in cui l'area 2 è impostata come preferenza nel criterio di indirizzamento della geolocalizzazione. L'aggiornamento DNS interessa i client la cui preferenza del criterio di indirizzamento è impostata sull'area non riuscita. Il valore TTL determina per quanto tempo questi client continueranno a utilizzare la vecchia voce prima di aggiornarla per puntare al sito in buono stato. Il tempo aggiuntivo (circa 1 minuto) dipende dalla frequenza e dal timeout dei controlli dello stato configurati nel criterio di indirizzamento di gestione del traffico OCI (30 secondi sono stati utilizzati nel test precedente per l'intervallo di controllo dello stato e un timeout di 10 secondi).

Quando si utilizza un load balancer globale (GLBR, global load balancer), il tempo di indisponibilità dipende dalla frequenza dei controlli dello stato configurati in GLBR. Non appena il GLBR contrassegna un pool come malsano, le richieste in entrata verranno reindirizzate all'altro sito. Con un GLBR, non c'è alcun aggiornamento DNS, quindi il valore TTL della voce front-end è irrilevante.