Come eseguire AEM con lo standby a freddo TarMK

Introduzione

La capacità di standby a freddo del Tar Micro Kernel consente a una o più istanze di AEM di standby di connettersi a un'istanza primaria. Il processo di sincronizzazione è un modo solo che significa che viene eseguito solo dalle istanze primarie alle istanze di standby.

Lo scopo delle istanze di standby è quello di garantire una Live Data Copy dell’archivio principale e garantire un rapido switch senza perdita di dati nel caso in cui il master non sia disponibile per qualsiasi motivo.

Il contenuto viene sincronizzato in modo lineare tra l’istanza primaria e le istanze di standby senza alcun controllo dell’integrità per quanto riguarda la corruzione del file o dell’archivio. A causa di questa progettazione, le istanze di standby sono copie esatte dell'istanza primaria e non possono contribuire a mitigare le incongruenze sulle istanze primarie.

NOTA

La funzione Standby a freddo ha lo scopo di proteggere gli scenari in cui è richiesta un'elevata disponibilità sulle istanze author. Per le situazioni in cui è richiesta un'elevata disponibilità sulle istanze publish utilizzando il Kernel Tar Micro, l'Adobe consiglia di utilizzare una farm di pubblicazione.

Per informazioni su ulteriori distribuzioni disponibili, consulta la pagina Implementazioni consigliate .

NOTA

Quando l’istanza Standby viene impostata o derivata dal nodo Principale, consente l’accesso solo alle due console seguenti (per le attività relative all’amministrazione):

  • CRXDE Lite
  • Console web OSGI

Altre console non sono accessibili.

Come funziona

Nell'istanza AEM primaria viene aperta una porta TCP in ascolto dei messaggi in arrivo. Attualmente, ci sono due tipi di messaggi che gli schiavi invieranno al padrone:

  • un messaggio che richiede l’ID segmento dell’intestazione corrente
  • un messaggio che richiede dati di segmento con un ID specificato

Lo standby richiede periodicamente l'ID del segmento dell'intestazione corrente del primario. Se il segmento è localmente sconosciuto, verrà recuperato. Se è già presente, i segmenti vengono confrontati e, se necessario, verranno richiesti anche i segmenti a cui si fa riferimento.

NOTA

Le istanze di standby non ricevono alcun tipo di richieste, perché sono in esecuzione in modalità di solo sincronizzazione. L'unica sezione disponibile in un'istanza di standby è la Web Console, al fine di facilitare la configurazione dei bundle e dei servizi.

Una tipica implementazione TarMK Cold Standby:

chlimage_1-86

Altre caratteristiche

Robustezza

Il flusso di dati è progettato per rilevare e gestire automaticamente i problemi di connessione e di rete. Tutti i pacchetti sono raggruppati con checksum e non appena si verificano problemi con la connessione o i pacchetti danneggiati si verificano nuovi tentativi meccanismi vengono attivati.

Spettacolo

Abilitare lo standby a freddo TarMK sull'istanza primaria non ha quasi alcun impatto misurabile sulle prestazioni. Il consumo aggiuntivo della CPU è molto basso e l'I/O del disco rigido e della rete extra non deve produrre problemi di prestazioni e prestazioni.

In standby è possibile prevedere un elevato consumo di CPU durante il processo di sincronizzazione. Poiché la procedura non è multithread, non può essere accelerata utilizzando più core. Se non vengono modificati o trasferiti dati, non vi sarà alcuna attività misurabile. La velocità di connessione varia a seconda dell’ambiente hardware e di rete, ma non dipende dalle dimensioni dell’archivio o dall’utilizzo SSL. Tieni presente questo aspetto quando stimi il tempo necessario per una sincronizzazione iniziale o quando nel frattempo molti dati sono stati modificati sul nodo principale.

Sicurezza

Supponendo che tutte le istanze siano eseguite nella stessa area di sicurezza Intranet, il rischio di violazione della sicurezza è notevolmente ridotto. Tuttavia, puoi aggiungere un livello di sicurezza aggiuntivo abilitando le connessioni SSL tra gli slave e il master. In questo modo si riduce la possibilità che i dati siano compromessi da un uomo in mezzo.

È inoltre possibile specificare le istanze in standby consentite per la connessione limitando l’indirizzo IP delle richieste in arrivo. Questo dovrebbe aiutare a garantire che nessuno nella Intranet possa copiare l’archivio.

NOTA

Si consiglia di aggiungere un load balancer tra il Dispatcher e i server che fanno parte della configurazione di Coldy Standby. Il load balancer deve essere configurato in modo da indirizzare il traffico dell’utente solo all’istanza primaria al fine di garantire la coerenza e impedire che il contenuto venga copiato sull’istanza di standby con mezzi diversi dal meccanismo di standby a freddo.

Creazione di una configurazione di standby a freddo AEM TarMK

ATTENZIONE

Il PID per l’archivio dei nodi di segmento e il servizio di archivio in standby è cambiato in AEM 6.3 rispetto alle versioni precedenti come segue:

  • da org.apache.jackrabbit.oak.plugins.segment.standby.store.StandbyStoreService a org.apache.jackrabbit.oak.segment.standby.store.StandbyStoreService
  • da org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService a org.apache.jackrabbit.oak.segment.SegmentNodeStoreService

Assicurati di apportare le regolazioni di configurazione necessarie per riflettere questa modifica.

Per creare una configurazione di standby a freddo TarMK, devi prima creare le istanze di standby eseguendo una copia del file system dell'intera cartella di installazione della cartella principale in una nuova posizione. È quindi possibile avviare ogni istanza con una modalità runmode che ne specifichi il ruolo ( primary o standby).

Di seguito è riportata la procedura da seguire per creare una configurazione con un master e un'istanza di standby:

  1. Installa AEM.

  2. Arresta l’istanza e copia la relativa cartella di installazione nel percorso da cui verrà eseguita l’istanza di standby a freddo. Anche se eseguito da computer diversi, assicurati di assegnare a ciascuna cartella un nome descrittivo (come aem-primary o aem-standby) per distinguere tra le istanze.

  3. Vai alla cartella di installazione dell'istanza primaria e:

    1. Controlla ed elimina tutte le configurazioni OSGi precedenti che potresti avere in aem-primary/crx-quickstart/install
    2. Crea una cartella denominata install.primary in aem-primary/crx-quickstart/install
    3. Crea le configurazioni richieste per l'archivio dei nodi e l'archivio dei dati preferiti in aem-primary/crx-quickstart/install/install.primary
    4. Crea un file denominato org.apache.jackrabbit.oak.segment.standby.store.StandbyStoreService.config nella stessa posizione e configuralo di conseguenza. Per ulteriori informazioni sulle opzioni di configurazione, consulta Configurazione.
    5. Se utilizzi un'istanza AEM TarMK con un archivio dati esterno, crea una cartella denominata crx3 in aem-primary/crx-quickstart/install denominata crx3
    6. Posiziona il file di configurazione dell’archivio dati nella cartella crx3 .

    Se, ad esempio, esegui un'istanza AEM TarMK con un archivio dati file esterno, hai bisogno di questi file di configurazione:

    • aem-primary/crx-quickstart/install/install.primary/org.apache.jackrabbit.oak.segment.SegmentNodeStoreService.config
    • aem-primary/crx-quickstart/install/install.primary/org.apache.jackrabbit.oak.segment.standby.store.StandbyStoreService.config
    • aem-primary/crx-quickstart/install/crx3/org.apache.jackrabbit.oak.plugins.blob.datastore.FileDataStore.config

    Di seguito trovi configurazioni di esempio per l’istanza primaria:

    Esempio di org.apache.jackrabbit.oak.segment.SegmentNodeStoreService.config

    org.apache.sling.installer.configuration.persist=B"false"
    customBlobStore=B"true"
    standby=B"false"
    

    Esempio di org.apache.jackrabbit.oak.segment.standby.store.StandbyStoreService.config

    org.apache.sling.installer.configuration.persist=B"false"
    mode="primary"
    port=I"8023"
    

    Esempio di org.apache.jackrabbit.oak.plugins.blob.datastore.FileDataStore.config

    org.apache.sling.installer.configuration.persist=B"false"
    path="./crx-quickstart/repository/datastore"
    minRecordLength=I"16384"
    
  4. Avvia l'attività primaria assicurandoti di specificare la modalità di esecuzione primaria:

    java -jar quickstart.jar -r primary,crx3,crx3tar
    
  5. Crea un nuovo logger di registrazione Sling Apache per il pacchetto org.apache.jackrabbit.oak.segment . Imposta il livello di registro su "Debug" e punta l'output del registro su un file di registro separato, come /logs/tarmk-coldstandby.log. Per ulteriori informazioni, consulta Registrazione.

  6. Vai alla posizione dell'istanza standby e avviala eseguendo il jar.

  7. Crea la stessa configurazione di registrazione della principale. Quindi, ferma l'istanza.

  8. Quindi, prepara l'istanza di standby. A questo scopo, esegui gli stessi passaggi dell’istanza primaria:

    1. Elimina tutti i file che potrebbero essere presenti in aem-standby/crx-quickstart/install.

    2. Crea una nuova cartella denominata install.standby in aem-standby/crx-quickstart/install

    3. Crea due file di configurazione denominati:

      • org.apache.jackrabbit.oak.segment.SegmentNodeStoreService.config
      • org.apache.jackrabbit.oak.segment.standby.store.StandbyStoreService.config
    4. Crea una nuova cartella denominata crx3 in aem-standby/crx-quickstart/install

    5. Crea la configurazione dell’archivio dati e inseriscila in aem-standby/crx-quickstart/install/crx3. Per questo esempio, il file da creare è:

      • org.apache.jackrabbit.oak.plugins.blob.datastore.FileDataStore.config
    6. Modifica i file e crea le configurazioni necessarie.

    Di seguito sono riportati alcuni file di configurazione di esempio per una tipica istanza di standby:

    Esempio di org.apache.jackrabbit.oak.segment.SegmentNodeStoreService.config

    org.apache.sling.installer.configuration.persist=B"false"
    name="Oak-Tar"
    service.ranking=I"100"
    standby=B"true"
    customBlobStore=B"true"
    

    Esempio di org.apache.jackrabbit.oak.segment.standby.store.StandbyStoreService.config

    org.apache.sling.installer.configuration.persist=B"false"
    mode="standby"
    primary.host="127.0.0.1"
    port=I"8023"
    secure=B"false"
    interval=I"5"
    standby.autoclean=B"true"
    

    Esempio di org.apache.jackrabbit.oak.plugins.blob.datastore.FileDataStore.config

    org.apache.sling.installer.configuration.persist=B"false"
    path="./crx-quickstart/repository/datastore"
    minRecordLength=I"16384"
    
  9. Avvia l'istanza standby utilizzando la modalità di esecuzione standby:

    java -jar quickstart.jar -r standby,crx3,crx3tar
    

Il servizio può essere configurato anche tramite la console Web tramite:

  1. Andando alla console Web all'indirizzo: https://serveraddress:serverport/system/console/configMgr
  2. Sto cercando un servizio chiamato Apache Jackrabbit Oak Segment Tar Cold Standby Service e fai doppio clic su di esso per modificare le impostazioni.
  3. Salvataggio delle impostazioni e riavvio delle istanze in modo che le nuove impostazioni possano avere effetto.
NOTA

Puoi controllare il ruolo di un'istanza in qualsiasi momento controllando la presenza delle modalità di esecuzione primary o standby nella console Web delle impostazioni Sling.

Per farlo, vai su http://localhost:4502/system/console/status-slingsettings e controlla la riga "Run Modes".

Prima sincronizzazione

Una volta completata la preparazione e avviato lo standby per la prima volta, il traffico di rete tra le istanze sarà intenso, in quanto lo standby raggiunge il livello principale. È possibile consultare i registri per osservare lo stato della sincronizzazione.

Nel file di standby tarmk-coldstandby.log, vedrai voci come queste:

    *DEBUG* [defaultEventExecutorGroup-2-1] org.apache.jackrabbit.oak.segment.standby.store.StandbyStore trying to read segment ec1f739c-0e3c-41b8-be2e-5417efc05266

    *DEBUG* [nioEventLoopGroup-3-1] org.apache.jackrabbit.oak.segment.standby.codec.SegmentDecoder received type 1 with id ec1f739c-0e3c-41b8-be2e-5417efc05266 and size 262144

    *DEBUG* [defaultEventExecutorGroup-2-1] org.apache.jackrabbit.oak.segment.standby.store.StandbyStore got segment ec1f739c-0e3c-41b8-be2e-5417efc05266 with size 262144

    *DEBUG* [defaultEventExecutorGroup-2-1] org.apache.jackrabbit.oak.segment.file.TarWriter Writing segment ec1f739c-0e3c-41b8-be2e-5417efc05266 to /mnt/crx/author/crx-quickstart/repository/segmentstore/data00016a.tar

Nel file error.log dello standby, dovrebbe essere presente una voce come questa:

*INFO* [FelixStartLevel] org.apache.jackrabbit.oak.segment.standby.store.StandbyStoreService started standby sync with 10.20.30.40:8023 at 5 sec.

Nello snippet di log di cui sopra, 10.20.30.40 è l'indirizzo IP del principale.

In primary tarmk-coldstandby.log, vedrai voci come queste:

    *DEBUG* [nioEventLoopGroup-3-2] org.apache.jackrabbit.oak.segment.standby.store.CommunicationObserver got message ‘s.d45f53e4-0c33-4d4d-b3d0-7c552c8e3bbd’ from client c7a7ce9b-1e16-488a-976e-627100ddd8cd

    *DEBUG* [nioEventLoopGroup-3-2] org.apache.jackrabbit.oak.segment.standby.server.StandbyServerHandler request segment id d45f53e4-0c33-4d4d-b3d0-7c552c8e3bbd

    *DEBUG* [nioEventLoopGroup-3-2] org.apache.jackrabbit.oak.segment.standby.server.StandbyServerHandler sending segment d45f53e4-0c33-4d4d-b3d0-7c552c8e3bbd to /10.20.30.40:34998

    *DEBUG* [nioEventLoopGroup-3-2] org.apache.jackrabbit.oak.segment.standby.store.CommunicationObserver did send segment with 262144 bytes to client c7a7ce9b-1e16-488a-976e-627100ddd8cd

In questo caso, il "client" menzionato nel registro è l'istanza standby.

Una volta che queste voci smettono di comparire nel registro, puoi tranquillamente presumere che il processo di sincronizzazione sia completo.

Sebbene le voci di cui sopra mostrano che il meccanismo di polling funziona correttamente, spesso è utile capire se ci sono dati in fase di sincronizzazione mentre si verifica il polling. A questo scopo, cerca voci come:

*DEBUG* [defaultEventExecutorGroup-156-1] org.apache.jackrabbit.oak.segment.file.TarWriter Writing segment 3a03fafc-d1f9-4a8f-a67a-d0849d5a36d5 to /<<CQROOTDIRECTORY>>/crx-quickstart/repository/segmentstore/data00014a.tar

Inoltre, quando si esegue con un FileDataStore non condiviso, messaggi come quello che segue confermano che i file binari vengono trasmessi correttamente:

*DEBUG* [nioEventLoopGroup-228-1] org.apache.jackrabbit.oak.segment.standby.codec.ReplyDecoder received blob with id eb26faeaca7f6f5b636f0ececc592f1fd97ea1a9#169102 and size 169102

Configurazione

Per il servizio di standby a freddo sono disponibili le seguenti impostazioni OSGi:

  • Configurazione persistente: se abilitata, la configurazione verrà memorizzata nell’archivio invece dei file di configurazione OSGi tradizionali. Si consiglia di mantenere questa impostazione disabilitata sui sistemi di produzione in modo che la configurazione primaria non venga estratta dallo standby.

  • Modalità (mode): scegli la modalità di esecuzione dell’istanza.

  • Porta (porta): la porta da utilizzare per la comunicazione. Il valore predefinito è 8023.

  • Host primario (primary.host): - l'host dell'istanza primaria. Questa impostazione è applicabile solo per lo standby.

  • Intervallo di sincronizzazione (interval): questa impostazione determina l’intervallo tra la richiesta di sincronizzazione ed è applicabile solo per l’istanza di standby.

  • Intervalli IP consentiti (primary.allowed-client-ip-ranges): gli intervalli IP da cui il principale consentirà le connessioni.

  • Protetto (secure): abilita la crittografia SSL. Per utilizzare questa impostazione, deve essere abilitata su tutte le istanze.

  • Timeout di lettura dello standby (standby.readtimeout): timeout per le richieste emesse dall'istanza di standby in millisecondi. Il valore predefinito utilizzato è 60000 (un minuto).

  • Standby Automatic Cleanup (standby.autoclean): chiama il metodo di pulizia se la dimensione dell'archivio aumenta su un ciclo di sincronizzazione.

NOTA

È vivamente consigliato che il principale e lo standby abbiano ID archivio diversi per renderli identificabili separatamente per servizi come Offloading.

Il modo migliore per assicurarsi che questo sia coperto è eliminando il file sling.id sullo standby e riavviando l'istanza.

Procedure di failover

Nel caso in cui l'istanza primaria non riesca per qualsiasi motivo, è possibile impostare una delle istanze di standby per assumere il ruolo del primario modificando la modalità di esecuzione iniziale come descritto di seguito:

NOTA

Anche i file di configurazione devono essere modificati in modo che corrispondano alle impostazioni utilizzate per l'istanza primaria.

  1. Vai nel punto in cui è installata l'istanza di standby e interromperla.

  2. Se hai un load balancer configurato con la configurazione, a questo punto puoi rimuovere il principale dalla configurazione del load balancer.

  3. Esegui il backup della cartella crx-quickstart dalla cartella di installazione di standby. Può essere utilizzato come punto di partenza quando si imposta un nuovo standby.

  4. Riavvia l'istanza utilizzando la modalità di esecuzione primary:

    java -jar quickstart.jar -r primary,crx3,crx3tar
    
  5. Aggiungi il nuovo primario al load balancer.

  6. Crea e avvia una nuova istanza di standby. Per ulteriori informazioni, consulta la procedura precedente su Creazione di una configurazione di standby a freddo AEM TarMK.

Applicazione degli hotfix a una configurazione di standby a freddo

Il modo consigliato per applicare gli hotfix a una configurazione stanby a freddo è installarli nell'istanza primaria e poi clonarli in una nuova istanza standby a freddo con gli hotfix installati.

Per farlo, segui i passaggi descritti di seguito:

  1. Interrompi il processo di sincronizzazione sull'istanza di standby a freddo andando alla console JMX e utilizzando il org.apache.jackrabbit.oak: Stato ("Standby") fagiolo. Per ulteriori informazioni su come eseguire questa operazione, consulta la sezione su Monitoraggio.
  2. Arrestare l'istanza di standby a freddo.
  3. Installa l'hotfix sull'istanza primaria. Per ulteriori dettagli su come installare un hotfix, consulta Come lavorare con i pacchetti.
  4. Testa l'istanza per i problemi successivi all'installazione.
  5. Rimuovere l'istanza standby a freddo eliminando la relativa cartella di installazione.
  6. Arrestare l'istanza primaria e clonarla eseguendo una copia del file system dell'intera cartella di installazione nella posizione dello standby a freddo.
  7. Riconfigura il clone appena creato per fungere da istanza di standby a freddo. Per ulteriori dettagli, consulta Creazione di una configurazione di standby a freddo AEM TarMK.
  8. Avviare sia le istanze di standby principale che quelle di standby a freddo.

Monitoraggio

La funzione espone le informazioni utilizzando JMX o MBeans. In questo modo è possibile controllare lo stato corrente dello standby e del master utilizzando la console JMX. Le informazioni si trovano in un MBean di type org.apache.jackrabbit.oak:type="Standby"denominato Status.

Standby

Osservando un'istanza di standby si espone un nodo. L’ID è in genere un UUID generico.

Questo nodo ha cinque attributi di sola lettura:

  • Running: valore booleano che indica se il processo di sincronizzazione è in esecuzione o meno.
  • Mode: Client: seguito dall’UUID utilizzato per identificare l’istanza. Tieni presente che questo UUID cambierà ogni volta che la configurazione viene aggiornata.
  • Status: una rappresentazione testuale dello stato corrente (come running o stopped).
  • FailedRequests:il numero di errori consecutivi.
  • SecondsSinceLastSuccess: il numero di secondi dall'ultima comunicazione riuscita con il server. Se non è stata effettuata una comunicazione corretta, verrà visualizzato -1.

Sono inoltre disponibili tre metodi richiamabili:

  • start(): avvia il processo di sincronizzazione.
  • stop(): interrompe il processo di sincronizzazione.
  • cleanup(): esegue l'operazione di pulizia in standby.

Principale

Osservando il principale si espongono alcune informazioni generali tramite un MBean il cui valore ID è il numero di porta utilizzato dal servizio di standby TarMK (8023 per impostazione predefinita). La maggior parte dei metodi e degli attributi sono gli stessi utilizzati per lo standby, ma alcuni sono diversi:

  • Mode: mostrerà sempre il valore primary.

È inoltre possibile recuperare informazioni per un massimo di 10 client (istanze di standby) collegati al master. L'ID MBean è l'UUID dell'istanza. Non esistono metodi richiamabili per questi MBeans, ma alcuni attributi di sola lettura molto utili:

  • Name: ID del client.
  • LastSeenTimestamp: la marca temporale dell’ultima richiesta in una rappresentazione testuale.
  • LastRequest: l’ultima richiesta del client.
  • RemoteAddress: l’indirizzo IP del client.
  • RemotePort: la porta utilizzata dal client per l’ultima richiesta.
  • TransferredSegments: il numero totale di segmenti trasferiti a questo client.
  • TransferredSegmentBytes:il numero totale di byte trasferiti al client.

Manutenzione dell'archivio in standby a freddo

Pulizia revisioni

ATTENZIONE

Non eseguire la pulizia revisioni offline in standby. Non è necessario e non ridurrà la dimensione del segmentstore.

NOTA

Se si esegue Pulizia revisioni online sull'istanza primaria, la procedura manuale illustrata di seguito non è necessaria. Inoltre, se utilizzi il cleanup delle revisioni online, l'operazione cleanup () sull'istanza di standby verrà eseguita automaticamente.

L'Adobe consiglia di eseguire regolarmente la manutenzione per evitare una crescita eccessiva del repository nel tempo. Per eseguire manualmente la manutenzione dell'archivio in standby a freddo, segui i passaggi seguenti:

  1. Arresta il processo di standby sull'istanza di standby andando alla console JMX e utilizzando il org.apache.jackrabbit.oak: Stato ("Standby") fagiolo. Per ulteriori informazioni su come eseguire questa operazione, consulta la sezione precedente su Monitoraggio.

  2. Interrompi l'istanza AEM primaria.

  3. Esegui lo strumento di compattazione oak sull'istanza primaria. Per ulteriori dettagli, vedere Mantenimento del repository.

  4. Avvia l'istanza primaria.

  5. Avvia il processo di standby sull'istanza di standby utilizzando lo stesso fagiolo JMX come descritto nel primo passaggio.

  6. Controlla i registri e attendi il completamento della sincronizzazione. È possibile che in questo momento si assista a una crescita sostanziale nell'archivio di standby.

  7. Esegui l'operazione cleanup() sull'istanza di standby, utilizzando lo stesso fagiolo JMX come descritto nel primo passaggio.

Potrebbe essere necessario più tempo del solito perché l'istanza di standby completi la sincronizzazione con la principale, in quanto la compattazione offline riscrive efficacemente la cronologia dell'archivio, rendendo il calcolo delle modifiche negli archivi più tempo. Va inoltre notato che una volta completato questo processo, la dimensione dell’archivio sullo standby sarà approssimativamente uguale alla dimensione dell’archivio sul principale.

In alternativa, l'archivio primario può essere copiato manualmente sullo standby dopo aver eseguito la compattazione sul primario, essenzialmente ricostruendo lo standby ogni volta che la compattazione viene eseguita.

Archivio dati raccolta oggetti inattivi

È importante eseguire la raccolta degli oggetti inattivi sulle istanze del datastore del file di tanto in tanto come altrimenti, i file binari eliminati rimarranno sul filesystem, infine riempire l'unità. Per eseguire la raccolta degli oggetti inattivi, segui la procedura seguente:

  1. Eseguire la manutenzione dell'archivio in standby a freddo come descritto nella sezione sopra.

  2. Al termine del processo di manutenzione e al riavvio delle istanze:

    • Sul primario, esegui la raccolta degli oggetti inattivi dell'archivio dati tramite i fagioli JMX pertinenti come descritto in questo articolo.
    • Nello standby, la raccolta degli oggetti inattivi nell'archivio dati è disponibile solo tramite BlobGarbageCollection MBean - startBlobGC(). Il MBean RepositoryManagement non è disponibile nello standby.
    NOTA

    Nel caso in cui non si utilizzi un archivio dati condiviso, la raccolta degli oggetti inattivi dovrà prima essere eseguita sul computer primario e poi sul sistema di standby.

In questa pagina