Mise en miroir depuis Cloud Storage

Un miroir Cloud Storage fournit un service de synchronisation automatisé et basé sur des événements qui met en miroir en continu les fichiers d'un bucket Cloud Storage vers un répertoire Managed Lustre. La mise en miroir n'est possible que dans un sens, de Cloud Storage vers Managed Lustre.

Les miroirs Cloud Storage ne sont disponibles que sur demande. Pour indiquer votre intérêt, envoyez le formulaire de demande de mise en miroir Cloud Storage.

Pour obtenir de l'aide concernant les miroirs Cloud Storage actifs, contactez google-cloud-managed-lustre-support@google.com.

Comparaison entre les miroirs Cloud Storage et les transferts de données à la demande

Managed Lustre accepte deux mécanismes de déplacement des données avec Cloud Storage :

Fonctionnalité Miroirs Cloud Storage Transferts de données à la demande
Sens Cloud Storage vers Managed Lustre Cloud Storage vers Managed Lustre

Managed Lustre vers Cloud Storage
Déclencheur Basée sur les événements ; synchronisation automatique lors de la création, de la mise à jour et de la suppression d'objets Manuel
Espace de noms hiérarchique Non compatible Compatible et recommandé pour des vitesses de transfert accélérées
Buckets Rapid Storage Non compatible Non compatible

Pour en savoir plus sur les transferts à la demande, consultez Transférer des données vers ou depuis Cloud Storage.

Fonctionnement d'un miroir Cloud Storage

Un miroir Cloud Storage exécute des transferts basés sur des événements entre une source Cloud Storage et un répertoire Managed Lustre cible. La source Cloud Storage peut être un bucket ou un préfixe d'objet spécifique dans un bucket. La mise en miroir s'effectue en deux phases : une synchronisation initiale lorsque vous créez le miroir, suivie d'une réplication continue des modifications ultérieures.

Synchronisation initiale

Lorsque vous créez un miroir Cloud Storage, le service effectue une synchronisation initiale pour copier tous les objets existants du chemin d'accès Cloud Storage source vers le répertoire Managed Lustre cible.

Réplication continue basée sur des événements

Après la synchronisation initiale, le service de mise en miroir écoute les notifications de bucket et réplique les modifications.

La plupart des objets peuvent être répliqués en quelques minutes. Lorsqu'un objet est créé ou modifié, l'intégralité du fichier est copiée.

  • La création d'un objet dans Cloud Storage crée automatiquement le fichier correspondant dans Managed Lustre.

  • La modification d'un objet existant dans Cloud Storage écrase le fichier dans Managed Lustre, ce qui supprime toutes les modifications locales apportées au système de fichiers.

  • Les modifications apportées aux attributs de métadonnées POSIX personnalisés sur les objets Cloud Storage, tels que l'UID, le GID, le mode ou mtime, sont mises à jour dans le fichier Managed Lustre correspondant.

  • Par défaut, la suppression d'un objet dans Cloud Storage supprime le fichier dupliqué dans Managed Lustre. Vous pouvez modifier ce comportement à l'aide de l'option --deleted-files-retained. Les répertoires parents vides restent sur le système de fichiers après la suppression du dernier fichier qu'ils contiennent.

  • Les modifications apportées aux fichiers dupliqués dans Managed Lustre ne sont pas recopiées dans le bucket source. Si l'objet source est mis à jour ultérieurement, le fichier Managed Lustre est écrasé par le contenu de l'objet source, ce qui supprime toutes les modifications locales.

  • La suppression d'un fichier mis en miroir dans Managed Lustre ne supprime pas l'objet correspondant dans Cloud Storage.

Vitesses de transfert

Les vitesses de transfert suivantes s'appliquent aux miroirs Cloud Storage dont les buckets et les instances se trouvent dans la même région Google Cloud  :

  • La synchronisation initiale copie les données existantes à un débit maximal de 100 Gbit/s pour les fichiers de plus de 32 Mo, et jusqu'à 10 000 objets par seconde pour les petits fichiers.

  • La réplication continue synchronise automatiquement les modifications en cours, les performances de transfert variant en fonction de la taille des fichiers :

    • Les fichiers volumineux de 10 Mo ou plus sont transférés à un débit maximal de 3,5 Gbit/s.
    • Les petits fichiers de 4 ko ou moins sont transférés à un débit maximal de 4 900 objets par seconde.

Si les données sont écrites dans Cloud Storage plus rapidement que le miroir ne peut les copier, les événements sont mis en file d'attente dans un backlog, ce qui augmente le temps nécessaire pour que les modifications apparaissent dans Managed Lustre. Le miroir rattrape automatiquement son retard une fois que le taux de modification diminue.

La vitesse de transfert est limitée par :

  • Le débit maximal d'une instance, qui correspond à la capacité de l'instance multipliée par le niveau de performances.

  • La bande passante de sortie Cloud Storage, qui est limitée à 200 Gbit/s, ou 25 Go/s, par région et par projet. Pour obtenir une bande passante de sortie plus élevée, demandez une augmentation de quota.

  • Latence du réseau pour les transferts interrégionaux. Placez le bucket source et l'instance dans la même région pour des performances optimales.

Tarifs

Un miroir Cloud Storage entraîne des frais Cloud Storage standards, qui sont facturés au projet contenant le bucket source :

  • La synchronisation initiale effectue des opérations de liste de classe A et des opérations de lecture de classe B sur le bucket source, et la réplication continue effectue des opérations de lecture de classe B, qui entraînent des frais d'opération Cloud Storage.
  • La mise en miroir des données d'un bucket source situé dans une région différente de celle de votre instance Managed Lustre entraîne des frais de transfert de données interrégionaux.

Avant de commencer

Pour créer un miroir Cloud Storage, vous devez :

  • Une instance Managed Lustre à l'état ACTIVE.
  • Un bucket Cloud Storage existant à utiliser comme source de mise en miroir. Les buckets avec l'espace de noms hiérarchique activé, les buckets Rapid Storage et les buckets avec les paiements par le demandeur activés ne sont pas compatibles.

Autorisations, rôles et ressources requis

Les autorisations, rôles et ressources IAM suivants sont requis pour créer et gérer des miroirs Cloud Storage.

Autorisations des utilisateurs

Pour créer et gérer des miroirs, votre compte utilisateur ou votre compte de service doit disposer du rôle Administrateur Managed Lustre, roles/lustre.admin.

Si vous utilisez un rôle personnalisé, celui-ci nécessite les autorisations suivantes :

  • lustre.mirrors.create pour créer un miroir.
  • lustre.mirrors.get pour décrire un miroir.
  • lustre.mirrors.list pour lister les miroirs.
  • lustre.mirrors.update pour mettre à jour un miroir.
  • lustre.mirrors.delete pour supprimer un miroir.

Initialisation de l'agent de service Cloud Storage

L'agent de service Cloud Storage doit exister dans votre projet pour pouvoir publier des événements de notification de bucket :

gcloud storage service-agent --project=PROJECT_ID

Remplacez PROJECT_ID par l'ID du projet Google Cloud .

Autorisations de l'agent de service Managed Lustre

L'agent de service Managed Lustre géré par Google doit avoir accès à votre bucket Cloud Storage source. Pour savoir comment trouver ou initialiser l'identité de votre agent de service, consultez Agent de service Managed Lustre.

L'agent de service nécessite les autorisations suivantes sur le bucket Cloud Storage source :

  • storage.buckets.get
  • storage.buckets.update
  • storage.objects.get
  • storage.objects.list

Créez un rôle personnalisé contenant les autorisations suivantes :

gcloud iam roles create lustreMirrorUser \
  --project=PROJECT_ID \
  --title="Lustre mirror user" \
  --permissions=storage.buckets.get,storage.buckets.update,storage.objects.get,storage.objects.list

Attribuez le rôle personnalisé à l'agent de service Managed Lustre sur le bucket source :

gcloud storage buckets add-iam-policy-binding gs://BUCKET_NAME \
  --member="serviceAccount:service-PROJECT_NUMBER@gcp-sa-lustre." \
  --role="projects/PROJECT_ID/roles/lustreMirrorUser"

Remplacez les éléments suivants :

  • PROJECT_ID : ID de votre projet Google Cloud .
  • BUCKET_NAME : nom de votre bucket Cloud Storage source.
  • PROJECT_NUMBER : numéro de votre projet Google Cloud .

Créer un miroir Cloud Storage

Vous pouvez créer un miroir Cloud Storage par instance Managed Lustre.

Vous ne pouvez pas créer de miroir Cloud Storage lorsqu'une opération d'importation ou d'exportation est en cours sur l'instance.

gcloud

Exécutez la commande mirrors create : 

gcloud lustre instances mirrors create MIRROR_NAME \
  --instance=INSTANCE_ID \
  --location=LOCATION \
  --direction=from-cloud-storage \
  --gcs-path-uri="gs://BUCKET_NAME/PREFIX/" \
  --lustre-path="/LUSTRE_DIRECTORY"

Où :

  • MIRROR_NAME est le nom de cette ressource de mise en miroir. Il doit comporter entre 1 et 63 caractères, ne contenir que des lettres minuscules, des chiffres et des traits d'union, commencer par une lettre et se terminer par une lettre ou un chiffre.
  • INSTANCE_ID est l'ID de votre instance Managed Lustre.
  • LOCATION est la zone de votre instance. Exemple : us-central1-a.
  • --direction spécifie la direction de la mise en miroir. Doit être from-cloud-storage.
  • --gcs-path-uri est le bucket Cloud Storage source et le préfixe d'objet facultatif. Si vous spécifiez un préfixe d'objet, le chemin d'accès doit se terminer par une barre oblique : gs://<var>BUCKET_NAME</var>/<var>PREFIX</var>/.
  • --lustre-path est le répertoire cible sur le système de fichiers Managed Lustre. Il doit s'agir d'un chemin absolu commençant par /, par exemple /data ou /data/subdir. La valeur par défaut est le répertoire racine, /. Si le répertoire spécifié n'existe pas, il est créé.

Les paramètres facultatifs suivants sont disponibles :

  • --deleted-files-retained ou --no-deleted-files-retained : contrôle si les fichiers supprimés dans Cloud Storage sont conservés dans Managed Lustre. La valeur par défaut est --no-deleted-files-retained.
  • --description=DESCRIPTION_TEXT : description facultative du miroir.

REST

Envoyez une requête POST à la méthode instances.mirrors.create :

POST https://lustre.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION/instances/INSTANCE_ID/mirrors?mirrorId=MIRROR_NAME
Authorization: Bearer YOUR_ACCESS_TOKEN
Content-Type: application/json

{
  "gcsPath": {
    "uri": "gs://BUCKET_NAME/PREFIX/"
  },
  "lustrePath": {
    "path": "/LUSTRE_DIRECTORY"
  },
  "direction": "FROM_CLOUD_STORAGE"
}

Où :

  • PROJECT_ID est l'ID de votre projet Google Cloud .
  • LOCATION est la zone de votre instance Managed Lustre. Exemple :us-central1-a
  • INSTANCE_ID est l'ID de votre instance.
  • MIRROR_NAME est le nom de cette ressource de mise en miroir. Il doit comporter entre 1 et 63 caractères, ne contenir que des lettres minuscules, des chiffres et des traits d'union, commencer par une lettre et se terminer par une lettre ou un chiffre.
  • gcsPath contient un champ uri avec le bucket Cloud Storage source et un préfixe d'objet facultatif. Si vous spécifiez un préfixe d'objet, le chemin d'accès doit se terminer par une barre oblique : gs://<var>BUCKET_NAME</var>/<var>PREFIX</var>/.
  • lustrePath est le répertoire cible sur le système de fichiers Managed Lustre. Il doit s'agir d'un chemin absolu commençant par /, par exemple /data ou /data/subdir. La valeur par défaut est le répertoire racine, /. Si le répertoire spécifié n'existe pas, il est créé.
  • direction spécifie la direction de la mise en miroir. Doit être FROM_CLOUD_STORAGE.

Le corps de la requête accepte également les champs facultatifs suivants :

  • deletedFilesRetained : définissez cette option sur true pour conserver les fichiers dans Managed Lustre après la suppression des fichiers correspondants de Cloud Storage. La valeur par défaut est false.
  • description : description facultative du miroir.

Attributs de fichier

Lorsqu'un fichier est copié d'un bucket Cloud Storage vers une instance Managed Lustre, les attributs du fichier dans l'instance Managed Lustre sont définis de l'une des deux manières suivantes :

  • Si l'objet Cloud Storage comporte des métadonnées personnalisées, comme décrit pour l'exportation de données, alors :
    • L'UID, le GID, le mode et le mtime du fichier sont définis en fonction des métadonnées personnalisées de l'objet.
    • La valeur atime du fichier est identique à celle de mtime.
  • Si l'objet Cloud Storage ne comporte pas de métadonnées personnalisées :
    • L'UID et le GID du fichier sont définis sur 0 (root).
    • Le mode du fichier est défini sur rwxr-xr-x (755).
    • Les valeurs atime et mtime du fichier sont définies sur l'heure de création de l'objet Cloud Storage.

Dans les deux cas :

  • La valeur ctime d'un fichier est définie sur l'heure à laquelle le fichier a été écrit sur l'instance.
  • Les valeurs atime, ctime et mtime d'un répertoire sont définies sur l'heure de création du répertoire sur l'instance.

Gérer les miroirs Cloud Storage

Vous pouvez lister, décrire, mettre à jour et supprimer des miroirs Cloud Storage à l'aide de l'outil Google Cloud CLI ou de l'API REST. Pour modifier le chemin d'accès source ou cible d'un miroir existant, vous devez supprimer le miroir existant et en créer un autre.

Répertorier un miroir

Pour afficher un miroir configuré sur une instance :

gcloud 

gcloud lustre instances mirrors list \
  --instance=INSTANCE_ID \
  --location=LOCATION

REST

Envoyez une requête GET à la méthode instances.mirrors.list :

GET https://lustre.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION/instances/INSTANCE_ID/mirrors
Authorization: Bearer YOUR_ACCESS_TOKEN

Décrire un miroir

Pour afficher la configuration et l'état opérationnel d'un miroir :

gcloud 

gcloud lustre instances mirrors describe MIRROR_NAME \
  --instance=INSTANCE_ID \
  --location=LOCATION

REST

Envoyez une requête GET à la méthode instances.mirrors.get :

GET https://lustre.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION/instances/INSTANCE_ID/mirrors/MIRROR_NAME
Authorization: Bearer YOUR_ACCESS_TOKEN

États de mise en miroir

Le champ state renvoyé par les commandes list et describe indique l'état du miroir dans son cycle de vie :

État Description
CREATING La ressource miroir est en cours de création.
INITIAL_SYNC La synchronisation initiale copie les objets existants depuis Cloud Storage.
ACTIVE Le miroir synchronise les modifications au fur et à mesure qu'elles se produisent.
DELETING Le miroir est en cours de suppression.

Mettre à jour un miroir

Vous pouvez mettre à jour la description et les libellés d'un miroir, et indiquer si vous souhaitez conserver les fichiers supprimés.

Les chemins d'accès Cloud Storage et Managed Lustre ne peuvent pas être modifiés. Pour faire pointer un miroir vers un autre chemin d'accès, supprimez-le et créez-en un autre.

La mise à jour d'un miroir ne relance pas la synchronisation initiale.

gcloud 

gcloud lustre instances mirrors update MIRROR_NAME \
  --instance=INSTANCE_ID \
  --location=LOCATION \
  --description="DESCRIPTION_TEXT"

REST

Envoyez une requête PATCH à la méthode instances.mirrors.patch avec un paramètre de requête updateMask :

PATCH https://lustre.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION/instances/INSTANCE_ID/mirrors/MIRROR_NAME?updateMask=description
Authorization: Bearer YOUR_ACCESS_TOKEN
Content-Type: application/json

{
  "description": "DESCRIPTION_TEXT"
}

Supprimer un miroir

Pour supprimer un miroir :

gcloud 

gcloud lustre instances mirrors delete MIRROR_NAME \
  --instance=INSTANCE_ID \
  --location=LOCATION

REST

Envoyez une requête DELETE à la méthode instances.mirrors.delete :

DELETE https://lustre.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION/instances/INSTANCE_ID/mirrors/MIRROR_NAME
Authorization: Bearer YOUR_ACCESS_TOKEN

La suppression d'un miroir arrête la synchronisation future entre Cloud Storage et Managed Lustre. Les fichiers qui ont déjà été copiés dans Managed Lustre ne sont pas supprimés lorsque le miroir est supprimé.

Les transferts de fichiers en cours au moment de la suppression d'un miroir sont annulés. Les transferts incomplets peuvent laisser des fichiers temporaires au format de nom FILENAME.cloud_transfer.UUID.NUMBER.tmp dans le répertoire miroir après la suppression du miroir. Vous pouvez supprimer ces fichiers.

Afficher les journaux

Les journaux de mise en miroir identifient les fichiers individuels qui n'ont pas pu être synchronisés.

Les journaux sont acheminés vers Cloud Logging pour la ressource lustre.googleapis.com/Instance, sous le nom de journal mirror.

Pour afficher les journaux des opérations de mise en miroir :

  1. Accédez à l'explorateur de journaux.

  2. Saisissez la requête suivante :

    resource.type="lustre.googleapis.com/Instance"
logName="projects/PROJECT_ID/logs/lustre.googleapis.com%2Fmirror"
resource.labels.instance_id="INSTANCE_ID"

Dépannage

PERMISSION_DENIED sur le bucket source

Si la création du miroir échoue avec une erreur PERMISSION_DENIED, si les fichiers ne se synchronisent pas ou si des journaux affichent des erreurs "PERMISSION_DENIED" :

  1. Vérifiez que l'agent de service Cloud Storage a été initialisé :

    gcloud storage service-agent --project=PROJECT_ID

  2. Vérifiez que l'agent de service Managed Lustre dispose des autorisations requises sur le bucket source. Pour en savoir plus, consultez Accorder des autorisations à l'agent de service.

Les modifications apportées à Cloud Storage ne sont pas répliquées dans Managed Lustre

Si l'état de la mise en miroir est ACTIVE, mais que les objets nouveaux ou modifiés dans Cloud Storage n'apparaissent pas dans Managed Lustre, vérifiez que la configuration de notification de bucket existe sur votre bucket source.

  1. Répertoriez les notifications de bucket :

    gcloud storage buckets notifications list --bucket=BUCKET_NAME

  2. Si la sortie est vide, vous devez supprimer le miroir existant et en créer un autre :

    gcloud lustre instances mirrors delete MIRROR_NAME \
  --instance=INSTANCE_ID \
  --location=LOCATION

    Une fois la suppression terminée, créez un miroir.

Erreurs liées à des conflits de noms

Si vous remarquez qu'il manque des fichiers dans Managed Lustre après les avoir ajoutés à Cloud Storage, recherchez les erreurs de conflit de nom dans Cloud Logging :

  • Si un objet créé dans Cloud Storage porte le même nom qu'un répertoire existant dans Managed Lustre, le transfert échoue avec une erreur file exists et le répertoire existant n'est pas écrasé. Le transfert ayant échoué laisse un fichier temporaire au format de nom FILENAME.cloud_transfer.UUID.NUMBER.tmp dans le répertoire parent.
  • Si un objet créé dans Cloud Storage contient un préfixe de chemin d'accès correspondant à un fichier standard existant dans Managed Lustre, le transfert échoue avec une erreur not a directory et le fichier existant n'est pas écrasé. Par exemple, si models est un fichier existant dans Managed Lustre, le transfert d'un objet nommé models/weights.bin depuis Cloud Storage échoue, car le répertoire models/ ne peut pas être créé.

Pour résoudre ces conflits, renommez ou supprimez le répertoire ou le fichier en conflit dans Managed Lustre, supprimez tous les fichiers .tmp restants, puis réimportez l'objet dans Cloud Storage pour déclencher la synchronisation.

ABORTED: unable to queue the operation

Si vous recevez une erreur ABORTED: unable to queue the operation lors de la création d'un miroir ou du lancement d'un job de transfert à la demande :

  • Assurez-vous qu'aucune opération import-data ou export-data n'est en cours d'exécution sur l'instance avant de créer un miroir.
  • Attendez que la création du miroir et la synchronisation initiale soient terminées avant de tenter d'autres opérations de données administratives sur l'instance.

FILESYSTEM_NO_SPACE_ON_DEVICE

Si la mise en miroir s'arrête et que les journaux indiquent des erreurs d'espace, il est possible que votre système de fichiers Managed Lustre manque d'inodes ou de capacité de disque. Vous pouvez supprimer les fichiers inutiles pour libérer de l'espace ou augmenter la capacité de stockage pour étendre votre système de fichiers.