Accueil
» Comment faire
»
Configurer le stockage Blob S3 pour ownCloud Infinite Scale
Configurer le stockage Blob S3 pour ownCloud Infinite Scale
Pour stocker le contenu des fichiers utilisateur dans S3 avec ownCloud Infinite Scale (oCIS), configurez le service Storage-Users pour utiliser le s3ngpilote, pointez-le vers un compartiment pré-créé et conservez le répertoire de métadonnées du service sur un stockage POSIX persistant. S3 héberge les objets binaires de fichiers ; il ne remplace pas tous les chemins d'accès aux données oCIS locaux.
La configuration ci-dessous est conforme à la documentation d'ownCloud Infinite Scale 8.2. Avant toute modification d'un système de production, comparez les noms des variables et les exemples de déploiement avec la documentation de votre version installée.
Vérifiez la configuration du stockage avant de procéder à la configuration.
Dans ce contexte, un blob représente le contenu stocké d'un fichier, et les métadonnées sont les informations utilisées par oCIS pour organiser et retrouver les fichiers. Avec S3NG, les blobs sont stockés sur un espace de stockage d'objets compatible S3, tandis que les métadonnées restent sur un système de fichiers POSIX. Ce système de fichiers doit être monté de manière permanente et inclus dans les sauvegardes. Le pilote de stockage système doit rester inchangé ocis.
Utilisez cette courte liste de vérification avant vol :
Choisissez un fournisseur S3 et confirmez son point de terminaison, sa région, le nom de son compartiment, les opérations d'API S3 prises en charge et les limites multiparties.
Créez le compartiment avant de démarrer oCIS. La configuration S3NG documentée suppose l'existence d'un compartiment.
Créez une identité d'accès dédiée pour oCIS et stockez sa clé et son secret dans le gestionnaire de secrets de votre déploiement ou dans les paramètres d'environnement protégé.
Choisissez un chemin d'accès persistant pour les métadonnées locales et vérifiez que le processus oCIS peut le lire et l'écrire.
Pour une installation existante, planifiez une migration prise en charge avant de modifier le pilote de stockage. La modification d'un paramètre du système de stockage principal n'équivaut pas à une copie ou une migration des données de fichiers existantes.
Les notes relatives à l'organisation du stockage ownCloud précisent quelles informations restent en dehors du compartiment S3. C'est pourquoi la restauration du seul compartiment ne constitue pas un plan de récupération complet.
Exemple des trois paramètres de stockage de base : S3NG pour les blobs utilisateur, une racine de métadonnées POSIX persistante et le pilote système oCIS.
Créez le compartiment et accordez l'accès requis
Configurez le compartiment dans la console ou les outils d'infrastructure de votre fournisseur, puis accordez à l'identité de service oCIS uniquement les accès nécessaires à ce compartiment. La page ownCloud S3 décrit une politique de base pour une API S3 de type AWS. Remplacez « votre compartiment » bucket-namepar votre nom de compartiment et adaptez la syntaxe de la politique à votre fournisseur s'il est compatible S3 plutôt qu'Amazon S3.
L'ARN au niveau du compartiment et l'ARN au niveau de l'objet sont différents : le premier permet de lister les objets du compartiment ; le second applique des actions aux objets qu'il contient. Respectez les exigences de la politique relative aux compartiments S3 d'ownCloud et la documentation de politique en vigueur de votre fournisseur. Ne collez pas d'identifiants dans un fichier de politique, un dépôt de code source ou une capture d'écran.
L'exemple distingue l'autorisation de liste de compartiments des autorisations d'objets et de téléchargement en plusieurs parties ; remplacez l'ARN de compartiment de substitution.
Définir les variables S3NG de Storage-Users
Pour un environnement de service ou un fichier Compose acceptant les variables d'environnement oCIS standard, définissez les valeurs suivantes. Ces exemples de valeurs sont des espaces réservés ; utilisez le point de terminaison et la région attribués par votre fournisseur.
Montez le répertoire racine /var/lib/ocis/storage/users(ou le répertoire racine que vous avez sélectionné) sur un stockage POSIX durable. Ne faites pas pointer ce chemin de métadonnées vers le compartiment S3. Injectez la clé d'accès et le secret de manière sécurisée ; les références aux variables ci-dessus supposent que votre déploiement fournit ces valeurs secrètes. Le point de terminaison doit être accessible depuis le service oCIS, et le nom du compartiment, la région et les informations d'identification doivent correspondre au même compte fournisseur et au même compartiment.
Si vous utilisez l'exemple modulaire Compose d'ownCloud ocis_full, son overlay S3 optionnel utilise une configuration spécifique S3NGet un s3ng.ymlfichier de configuration distinct. Suivez cet exemple comme modèle de déploiement complet plutôt que de le combiner sans discernement avec un autre fichier Compose. Consultez l' exemple de déploiement Compose officiel d'oCIS et la documentation de référence sur l'environnement Storage-Users .
Saisissez le point de terminaison, la région et le compartiment de votre fournisseur ; ne comportez pas de clés d’accès et de clés secrètes dans la configuration validée.
Taille des téléchargements en plusieurs parties pour les fichiers que vous attendez
Les fichiers volumineux sont chargés par fragments. Amazon S3 indique une taille maximale d'objet de 5 Tio et une limite de 10 000 fragments ; la taille de chaque fragment doit être comprise entre 5 Mio et 5 Gio. La taille de fragment par défaut de S3NG est de 16 Mio. Avec cette valeur par défaut, la limite du nombre de fragments peut constituer le plafond pratique avant la taille maximale d'objet définie par le fournisseur. La page 8.2 d'ownCloud estime ce plafond par défaut à 160 Gio ; utilisez la taille de fragment configurée et les règles de votre fournisseur pour calculer une limite maximale sûre et prévoyez une marge.
Le seul paramètre multipart configurable documenté par ownCloud est STORAGE_USERS_S3NG_PUT_OBJECT_PART_SIZEla taille des parties. Augmentez cette taille si la taille de votre fichier nécessite plus de 10 000 parties. La valeur étant un uint64entier non signé, configurez-la en octets, et non comme une chaîne de caractères avec « MiB » ajouté. Veillez à respecter la plage documentée de 5 Mio à 5 Gio et vérifiez que votre fournisseur S3 prend en charge la valeur choisie. Pour un objet de 5 Tio réparti sur 10 000 parties, la taille moyenne des parties devrait être de 500 Mio.
Réservez également un espace de stockage temporaire sur l'hôte ou le conteneur oCIS : ownCloud indique avoir besoin d'une capacité temporaire au moins égale à la taille du fichier le plus volumineux prévu pour mettre en mémoire tampon les données entrantes. Un compartiment et des identifiants valides ne suffisent pas à empêcher les échecs dus à une limite de taille de partition insuffisante ou à un disque temporaire saturé. Consultez les limites de chargement S3 d'ownCloud et la documentation relative aux types de variables d'environnement .
Appliquer, vérifier et protéger les données
Après avoir enregistré la configuration, redémarrez ou redéployez oCIS en suivant la procédure d'installation. Consultez les journaux de service pour détecter les erreurs de configuration, de point de terminaison, d'autorisation ou de connexion. Exécutez ensuite la vérification du blobstore dans le même environnement d'exécution configuré que oCIS.
ocis storage-users blobstore check
Cette commande de maintenance utilise le stockage Blobstore configuré et effectue un aller-retour (chargement, téléchargement et suppression) avec une charge utile de test aléatoire. Il s'agit d'un contrôle ciblé du stockage, et non d'une garantie de réussite pour tous les flux de travail destinés aux utilisateurs ou les chargements volumineux. La documentation de la commande Blobstore détaille ses options, notamment la taille configurable de la charge utile de test.
Exécutez cette commande avec la même configuration oCIS pour vérifier le blobstore configuré ; l’image ne montre aucun résultat de test.
Enfin, téléchargez un petit fichier de test via le client ou l'interface web et vérifiez qu'il s'affiche et s'ouvre correctement. Pour le déploiement de fichiers volumineux, testez également un fichier de taille représentative avant de valider la configuration. Un aller-retour réussi avec un petit fichier ne permet pas de valider la capacité de partage multipart ni l'espace disque temporaire disponible.
Sauvegardez les objets S3, les métadonnées POSIX, la configuration et les autres données oCIS requises de manière coordonnée. Les recommandations de sauvegarde d'ownCloud préconisent d'arrêter l'instance pendant la sauvegarde et de traiter séparément les blobs S3 stockés en externe. Conservez des copies récupérables des deux couches de stockage et testez une procédure de restauration avant de considérer le déploiement comme protégé : considérations relatives à la sauvegarde d'ownCloud .
Liste de vérification rapide pour la validation
STORAGE_USERS_DRIVERest s3ng; le stockage système reste ocis.
La racine des métadonnées est un stockage POSIX persistant, et le compartiment S3 existe déjà.
Le point de terminaison, la région, le compartiment, les informations d'identification et la politique correspondent au même compte fournisseur.
La taille des pièces en plusieurs parties, une capacité de 10 000 pièces et le stockage temporaire couvrent le plus grand fichier prévu.
La vérification du blobstore réussit, un véritable chargement client s'ouvre correctement et les métadonnées ainsi que le contenu du compartiment sont inclus dans les plans de sauvegarde et de restauration.