Questo documento descrive le opzioni di configurazione avanzate per i trasferimenti del file system, tra cui:
- Copia di dati su volumi CIFS o SMB
- Utilizzare le credenziali dell'account di servizio
- Regolazione della memoria massima dell'agente
- Limitazione dell'accesso alla directory degli agenti
- Coordinare gli agenti con Kubernetes
- Utilizzo di un proxy di inoltro
- Copia in un bucket con un criterio di conservazione
- Opzioni per ottenere una maggiore larghezza di banda di rete
Copia dei dati su volumi CIFS o SMB
Gli agenti di trasferimento non sono supportate direttamente sui server Windows. Tuttavia, è possibile spostare i dati memorizzati su qualsiasi file system compatibile con POSIX montando su un server Linux o una macchina virtuale (VM) per poi eseguire un agente Server o VM Linux per copiare i dati in Cloud Storage.
Per spostare i dati da un volume CIFS o SMB:
Esegui il provisioning di un server o di una VM Linux.
Per i sistemi operativi supportati, vedi Prerequisiti.
Esegui il comando seguente sul server o sulla VM Linux di cui hai eseguito il provisioning monta il volume:
sudo mount -t cifs -o username=WINDOWS-SHARE-USER,password=WINDOWS-SHARE-PASSWORD //IP-ADDRESS/SHARE-NAME /mnt
Sostituisci quanto segue:
IP-ADDRESS
: l'indirizzo IP del server Microsoft Server Windows su cui si trova il volume CIFS o SMB.SHARE-NAME
: il nome della condivisione che stai montando.WINDOWS-SHARE-USER
: un utente autorizzato per che accede al volume CIFS o SMB.WINDOWS-SHARE-PASSWORD
: la password per utente autorizzato del volume CIFS o SMB.
Verifica che il volume CIFS sia montato eseguendo questo comando:
findmnt -l
Verifica che l'utente che eseguirà l'agente possa elencare e copiare i file su il volume montato eseguendo questi comandi:
sudo -u USERNAME cp /mnt/FILE1 /mnt/FILE2
Sostituisci quanto segue:
USERNAME
: l'utente che eseguirà l'agente.FILE1
: il file da cui eseguire la copia.FILE2
: nome file in cui copiare.
Utilizzo delle credenziali dell'account di servizio
Puoi utilizzare le credenziali dell'account di servizio per eseguire l'agente. Utilizzo dell'account di servizio le credenziali consentono di autenticare l'agente di trasferimento senza basandosi su un unico account utente. Per ulteriori informazioni tipi di account, consulta la sezione Entità.
Creare una chiave dell'account di servizio. Per ulteriori informazioni, vedi Creazione e gestione delle chiavi degli account di servizio.
Passa il percorso della chiave di servizio al comando di creazione dell'agente:
gcloud transfer agents install --pool=POOL_NAME --count=NUM_AGENTS \ --mount-directories=MOUNT_DIRECTORIES \ --creds-file=RELATIVE_PATH_TO/KEY_FILE.JSON
Il file delle credenziali viene montato automaticamente da
gcloud transfer
e non non deve essere specificato con il flag--mount-directories
.
Regolazione della memoria massima degli agenti in corso...
Gli agenti di trasferimento utilizzano per impostazione predefinita un massimo di 8 GiB di memoria di sistema. Puoi
regolare la memoria massima utilizzata dagli agenti per adattarla al tuo ambiente passando
--max-physical-mem=MAXIMUM-MEMORY
, in sostituzione
MAXIMUM-MEMORY
con un valore adatto al tuo ambiente.
- Memoria minima: 1 GiB
- Memoria minima per supportare caricamenti ad alte prestazioni: 6 GiB
Consigliamo il valore predefinito di 8 GiB.
La seguente tabella descrive esempi di formati accettabili per
MAXIMUM-MEMORY
:
max-physical-mem valore |
Impostazione memoria massima |
---|---|
6g |
6 gigabyte |
6gb |
6 gigabyte |
6GiB |
6 gibibyte |
Limitazione dell'accesso alla directory degli agenti
Gli utenti in grado di creare job di trasferimento possono recuperare i dati da scaricare i dati in qualsiasi directory di file system accessibile all'agente.
Se gli agenti vengono eseguiti come root e hanno accesso all'intero file system, un utente malintenzionato potrebbe essere in grado di assumere il controllo dell'host. È Ti consigliamo vivamente di limitare l'accesso dell'agente solo alle autorizzazioni .
Per limitare l'accesso di un agente a directory specifiche:
gcloud
Per specificare le directory a cui l'agente può accedere in un file system, utilizza
Flag --mount-directories
con gcloud transfer agents install
:
gcloud transfer agents install --pool=POOL_NAME --count=NUM_AGENTS \
--mount-directories=MOUNT_DIRECTORIES
Specifica più directory separandole con una virgola e senza spazi:
gcloud transfer agents install --pool=POOL_NAME --count=NUM_AGENTS \
--mount-directories=MOUNT_DIRECTORY_1,MOUNT_DIRECTORY_2
Se specifichi un file di credenziali utilizzando il flag --creds-file
,
gcloud transfer
monta automaticamente il file delle credenziali. Altri file in
della stessa directory del file delle credenziali non sono montate.
docker run
per specificare le directory a cui l'agente può accedere durante l'esecuzione di una
trasferimento, superamento
-v HOST_DIRECTORY:CONTAINER_DIRECTORY
all'agente, dove:
HOST_DIRECTORY
è la directory sulla macchina host da cui intendi effettuare la copia.CONTAINER_DIRECTORY
è la directory mappata all'interno il container dell'agente.
HOST_DIRECTORY
e
Il campo CONTAINER_DIRECTORY
deve essere lo stesso, in modo che l'agente
individuare i file da copiare.
Quando utilizzi questa opzione:
- Non specificare
--enable-mount-directory
. - Non inserire
/transfer_root
all'inizio del percorso del file.
L'opzione --enable-mount-directory
monta l'intero file system sotto la
/transfer_root
sul container. Se --enable-mount-directory
è
specificato, le restrizioni della directory non vengono applicate.
Puoi utilizzare più di un flag -v
per specificare directory aggiuntive
da cui eseguire la copia. Ad esempio:
sudo docker run --ulimit memlock=64000000 -d -rm --volumes-from gcloud-config \ -v /usr/local/research:/usr/local/research \ -v /usr/local/billing:/usr/local/billing \ -v /tmp:/tmp \ gcr.io/cloud-ingest/tsop-agent:latest \ --project-id=PROJECT_ID \ --hostname=$(hostname) \ --agent-id-prefix=ID_PREFIX
Se utilizzi un account di servizio, assicurati di montare il file delle credenziali
nel container e passare
--creds-file=CREDENTIAL_FILE
. Ad esempio:
sudo docker run --ulimit memlock=64000000 -d -rm \ -v HOST_DIRECTORY:CONTAINER_DIRECTORY \ -v /tmp:/tmp \ -v FULL_CREDENTIAL_FILE_PATH:FULL_CREDENTIAL_FILE_PATH \ gcr.io/cloud-ingest/tsop-agent:latest \ --project-id=PROJECT_ID \ --creds-file=CREDENTIAL_FILE \ --hostname=$(hostname) \ --agent-id-prefix=ID_PREFIX
Sostituisci quanto segue:
HOST_DIRECTORY
: la directory sulla macchina host da cui intendi effettuare la copia.CONTAINER_DIRECTORY
: la directory mappata all'interno di un container di agenti in tempo reale.FULL_CREDENTIAL_FILE_PATH
: il percorso completo al file delle credenziali.PROJECT_ID
: il valore ID progetto che ospita le risorse di trasferimento vengono create e fatturate.CREDENTIAL_FILE
: un account di servizio in formato JSON delle credenziali. Per ulteriori informazioni sulla generazione di un account di servizio il file delle credenziali, consulta creazione e gestione delle chiavi degli account di servizio.ID_PREFIX
: il prefisso anteposto all'agente ID che consente di identificare l'agente o la relativa macchina nella console Google Cloud. Quando , l'ID agente è formattato comeprefix + hostname + Docker container ID
.
Coordinare gli agenti con Kubernetes
Docker è un runtime dei container supportato per Kubernetes. Puoi utilizzare Kubernetes per orchestrare l'avvio e l'arresto di molti agenti contemporaneamente. Dal punto di vista di Kubernetes, il container dell'agente è considerato stateless, per permetterti di seguire Istruzioni di Kubernetes per il deployment di un'applicazione stateless.
Utilizzo di endpoint API privati in Cloud Interconnect
Per utilizzare gli endpoint API privati in Cloud Interconnect:
Accedi all'host on-premise su cui intendi eseguire l'agente.
Configurare l'accesso privato Google. Per ulteriori informazioni, vedi Configurare l'accesso privato Google per gli host on-premise.
Conferma di poterti connettere alle API Cloud Storage:
- Per le API Cloud Storage, esegui il comando seguente dalla stessa
come agente di trasferimento per testare lo spostamento di un file
Bucket Cloud Storage:
gcloud storage cp test.txt gs://MY-BUCKET
doveMY-BUCKET
è il nome del tuo nel bucket Cloud Storage. Se il trasferimento funziona, il test ha esito positivo.
- Per le API Cloud Storage, esegui il comando seguente dalla stessa
come agente di trasferimento per testare lo spostamento di un file
Bucket Cloud Storage:
Utilizzo di un proxy di inoltro
Il supporto degli agenti di trasferimento mediante un proxy di inoltro sulla rete viene trasmesso
HTTPS_PROXY
variabile di ambiente.
Ad esempio:
sudo docker run -d --ulimit memlock=64000000 --rm \ --volumes-from gcloud-config \ -v /usr/local/research:/usr/local/research \ --env HTTPS_PROXY=PROXY\ gcr.io/cloud-ingest/tsop-agent:latest \ --enable-mount-directory \ --project-id=PROJECT_ID \ --hostname=$(hostname) \ --agent-id-prefix=ID_PREFIX
Sostituisci quanto segue:
PROXY
: l'URL HTTP e la porta del server proxy. Assicurati di specificare l'URL HTTP e non un URL HTTPS per evitare delle richieste con doppio wrapping nella crittografia TLS. Richieste con doppio wrapping impedire al server proxy di inviare richieste in uscita valide.PROJECT_ID
: il valore ID progetto che ospita le risorse di trasferimento vengono create e fatturate.ID_PREFIX
: il prefisso anteposto all'agente ID che consente di identificare l'agente o la relativa macchina nella console Google Cloud. Quando , l'ID agente è formattato comeprefix + hostname + Docker container ID
.
Copia in un bucket con un criterio di conservazione
Per eseguire il trasferimento a un bucket con un criterio di conservazione, consigliamo quanto segue di elaborazione:
Crea un bucket Cloud Storage all'interno della stessa regione del bucket finale. Assicurati che l'applicazione del bucket non ha un criterio di conservazione.
Per ulteriori informazioni sulle regioni, consulta Bucket di località.
Usa Storage Transfer Service per trasferire i tuoi dati nel bucket temporaneo creati senza un criterio di conservazione.
Esegui un trasferimento da bucket a bucket a trasferire i dati nel bucket con un criterio di conservazione.
Elimina il bucket Cloud Storage creato per archiviare temporaneamente i dati.
Opzioni per ottenere una maggiore larghezza di banda di rete
Esistono diverse opzioni per ottenere una larghezza di banda di rete maggiore per il file system trasferimenti. L'aumento della larghezza di banda della rete contribuisce a ridurre tempi di trasferimento più lunghi, soprattutto per set di dati di grandi dimensioni.
Peering con Google: il peering è il punto in cui ti connetti direttamente per consentire a Google di supportare lo scambio di traffico. Abbiamo località di peering diretto in tutto il mondo. Per ulteriori informazioni sui vantaggi e sulle nostre norme, consulta Peering.
Cloud Interconnect: Cloud Interconnect è simile al peering, ma utilizzerai un'interconnessione per connetterti a Google. Esistono due tipi di interconnect tra cui scegliere:
Dedicated Interconnect: ti connetti direttamente dal tuo data center a un data center Google tramite una piattaforma privata connessione. Per ulteriori informazioni, vedi Panoramica di Dedicated Interconnect.
Partner Interconnect: collabori con un fornitore di servizi per stabilire una connessione a un data center Google tramite un servizio rete del partner. Per ulteriori informazioni, vedi Panoramica di Partner Interconnect.
Ottenere larghezza di banda dal tuo ISP: il tuo provider di servizi internet (ISP) potrebbe essere in grado di offrire una maggiore larghezza di banda per le tue esigenze. Ti consigliamo di contattare questa persona a chiedi quali opzioni hanno a disposizione.