Bonjour,
On parle de plus en plus de stockage objet, et donc, j'ai décidé de regarder tout ceci d'un point de vue "informatique personnel", et donc mon choix s'est porté sur 2 softs que j'ai trouvé (si vous en avez d'autres à proposer, je répète, pour "informatique personnel", donc pas ceph ni de solutions à base de k8s )
Le premier est un container docker lancé par la start up Français Scality: S3server:
Scality S3 server
Le second est un petit logiciel qui lui même dit qu'il ne doit pas être déployé en prod:minio
MinIO
Installation
Scality S3 Server
L'installation du container est clairement expliqué ici:
https://buildmedia.readthedocs.org/media/pdf/s3-server/doc-adddoc/s3-server.pdf (il y a aussi les explications pour installer en dur)
Bref, on déploie le container et le couple AK/SK est fourni (on eux aussi le définir au lancement du container)
Minio
L'installation de MinIO est autant, voir plus, aisé, puisque le package est fourni sur des nombreuses distribution.
Le fichier de conf est dans /etc/minio/minio.conf
Et ensuite, un coup de systemctl pour autoriser et lancer le service
Configuration
Scality
Il offre plus de choix, notamment du fait de proposer un accès en SSL , et des accès divers.
Je ne me suis intéressé qu'à la modification du couple AK/SK, et à l'ajout d'utilisateur.
Scality offre ici un soft qui permet d'ajouter des utilisateur dans la conf
Minio
La conf semble simplissime à l'installation:
\% cat /etc/minio/minio.conf
\# Local export path.
\MINIO_VOLUMES="/srv/minio/data/"
\# Access Key of the server.
\# MINIO_ACCESS_KEY=Server-Access-Key
\# Secret key of the server.
\# MINIO_SECRET_KEY=Server-Secret-Key
\# Use if you want to run Minio on a custom port.
\# MINIO_OPTS="--address :9199"
Utilisation
j'ai fait quelques test: créer un utilisateur, créer un bucket, et put un file
Scality:
Bon, scality ne semble accepter l'ajout d'utilisateur que par la configuration du container. Le transfert d'un fichier de 1Go se fait avec un debit de 50 Mo/s en local. Aucune webui n'est fourni et les clients habituels fonctionnent bien.
Les données sont stockés dans le container, mais c'est modifiable en selectionnant où stocker les data et les metadata au lancement du container
Minio
Minio fournit une interface web très ergonomique facilitant la création de bucket et l'envoi de ficher, mais accepte aussi les requête par les outils habituels (aws cli pour ma part) . LA gestion du multi utilisateur n'est accepté qu'avec l'utilisation du client natif mcli. Le transfert d'un fichier de 1Go se fait avec un debit de 70 Mo/s en local.
Les fichiers sont stockés directement dans le repertoire indiqué dans la conf
Conclusion:
Les deux serveurs se ressemblent beaucoup, simple à déployer "nu" et un peu plus complexe pour des configurations avancées. Ils offrent des performances similaires
Toutefois , je trouve un grand avantage au déploiement d'une webui pour minio.
En cas pratique, on peux penser à déployer des applis S3 à la maison pour être stockés sur le SAN de la maison.
Par ailleurs, existe t'il desserveurs similaires pour les blobs, swift, ou cloud storage ?
# MinIO en production
Posté par Victor . Évalué à 5.
Où as-tu vu que MinIO n'était pas fait pour la prod ?
Quand on lit sur la page wikipedia :
On a du mal à y croire.
Sinon pour info la page dockerhub pour s3 server dit que c'est une vieille version et que la bonne semble être celle-ci : https://hub.docker.com/r/zenko/cloudserver/
J'ai utilisé MinIO avec succès, jamais utilisé la solution de Zenko en revanche.
[^] # Re: MinIO en production
Posté par Eh_Dis_Mwan . Évalué à 1.
C'est vrai, j'ai vu ça après. Mes premières sources dataient ss doute un peu.. Zenko est juste un data mover. Cloudserver est le nouveau nom mais l'image est, je crois, que peu modifié. Enfin, je vérifierais quand même. Merci.
[^] # Re: MinIO en production
Posté par Firwen (site web personnel) . Évalué à 3. Dernière modification le 24 novembre 2019 à 22:46.
Petite expérience: Pour avoir tester MiniIO pendant quelques mois, je le déconseillerais.
En mono noeud, l'expérience est satisfaisante. En multi noeud (cluster de dix noeuds), on a eu à faire à des crashs, des problèmes de réplications, et une incapacité à supporter une forte charge ( perf qui dégrade assez rapidement ).
L'évaludation était en début d'année dernière (2018) et sur machines virtualisées je précise, ça s'est peut être amélioré depuis.
Fait est que nous avons maintenant un cluster Ceph avec le support S3 fourni par RadosGW qui est d'un tout autre niveau en terme de stabilité.
# Utilisation
Posté par barmic 🦦 . Évalué à 5.
Je connais les grandes lignes de ce qu'est S3, mais je suis curieux de savoir l'intérêt. Sur AWS c'est un service de stockage qui se veut performant et pas cher, mais à hébergé quel est l'intérêt d'un stockage objet ? Et en particulier pour un particulier ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Utilisation
Posté par Pol' uX (site web personnel) . Évalué à 8.
Hérétique. C'est une révolution !
Adhérer à l'April, ça vous tente ?
[^] # Re: Utilisation
Posté par Ruminant . Évalué à 5. Dernière modification le 23 novembre 2019 à 22:01.
De ce que j’en sais et en ai utilisé, le stockage "objet" te permet, entre autre:
L’implémentation d’un stockage objet utilisera sans aucun doute des systèmes de fichiers classiques, mais la manière de présenter le tout sera différente.
Personnellement, je ferais l’analogie de "Objet vs FS" avec "SQL vs CSV" : tes données sont toujours bien présentes, et peut-être bien qu’elles sont stockées dans des CSV, mais l’interface qui t’est donnée est du SQL et te permet de faire plus de choses qu’un simple CSV.
L’usage pour un particulier je ne sais pas, l’usage pour une application en revanche, si on prend MinIO et AWS, c’est d’avoir une API compatible et donc de pouvoir être auto-hébergé sans devoir (ré)écrire des clients supplémentaires pour des application existantes.
On pourrait prendre OwnCloud : s’ils proposent un stockage sur AWS, utiliser MinIO se fera bien plus facilement parce que l’API est compatible.
Maintenant, de savoir si cette API est une bonne idée, ce n’est pas l’objet de mon message :)
[^] # Re: Utilisation
Posté par Eh_Dis_Mwan . Évalué à 1.
L'intérêt est de repasser les données à la maison sans refaire tous les développements réalisés par Amazon. Ensuite, en effet, cela donne l'impression d'être devant un filesystem avec des noms et des policies différents de POSIX.
S3 parle d'account et d'arn users là où POSIX parle de root/groupe et users.
POSIX parle login/mdp là où S3 parle accesskey/secretkey
POSIX parle répertoire là où s3 parle bucket
POSIX parle droits là où POSIX parle policy.
Et justement, les policies peuvent apparaître plus simple que poser des droits POSIX. Chaque utilisateurs appartient à un account et l'account est root de sa propre org.
Enfin la conf est plus simple qu'avec samba ou nfs.
[^] # Re: Utilisation
Posté par Moonz . Évalué à 2.
En terme de simplicité c’est très très difficile de battre ssh + sshfs.
[^] # Re: Utilisation
Posté par Eh_Dis_Mwan . Évalué à 1.
Non, j'ai jamais dit l'inverse, perso, je préfère posix, je citais queques arguments entendus ça et là
[^] # Re: Utilisation
Posté par damaki . Évalué à 1.
Selon moi, l'intérêt numéro 1 est le stockage illimité et une abstraction au dessus des filesystems. c'est devenu le plus gros standard dans ce domaine.
Pour un particulier, tout dépend de tes besoins en stockage de données. L'utilisation la plus évidente est de brancher ton joli NAS sur une instance compatible S3 pour de la réplication ou des backups réguliers. QNAP ou même OpenMediaVault sont compatibles.
[^] # Re: Utilisation
Posté par Alex G. . Évalué à 2.
Le gros avantage du stockage objet c'est la scalabilité (extensibilité) horizontale que proposent ces logiciels en général. Tu manque de stockage: tu ajoute un serveur. Tu peux aussi avoir les données dupliquées sur plusieurs serveur et être résilient (même à une coupure réseau). Tu peux aussi avoir un routing intelligent de l'accès aux données (par exemple le serveur choisi le nœud le plus proche qui possède le fichier).
Enfin S3 est devenu un standard de fait, donc tu trouves facilement une offre nuagique où tu n'as pas à gérer le logiciel sous jacent, et tu paye seulement au nombre de Mo réellement consommés (et la granularité est vraiment chaque objet/fichier).
Les systèmes de fichiers distribués comme CEPH sont en fait une abstraction du système de fichier classique, par dessus un stockage de type objet.
# NOTICE: s3server is NOT MAINTAINED
Posté par Mimoza . Évalué à 4.
Il faut aller voir la nouvelle image cloudserver
[^] # Re: NOTICE: s3server is NOT MAINTAINED
Posté par Eh_Dis_Mwan . Évalué à 1.
Merci, le soucis est en cliuant "run cludserver with docker", et bien, n se retrouve sur la page de S3 server
Bon plus d'info ici:
https://s3-server.readthedocs.io/en/latest/DOCKER.html
Donc en effet,; j'ai relancé le nouveau container:
docker run --restart unless-stopped --name cloudserver -p 8000:8000 zenko/cloudserver
[^] # Re: NOTICE: s3server is NOT MAINTAINED
Posté par Eh_Dis_Mwan . Évalué à 1.
Et ça ne fonctionne pas, et d'ailleurs une page indique que pour faire fnctionne cloudserver, il faut l'image s3server
https://s3-server.readthedocs.io/en/latest/DOCKER.html
Bref, à priori, l'image seul s3server n'est lus maintenu, et cloudserver est un ensemble incluant s3server, mais aussi redis etc….
# Informatique personnel
Posté par Anonyme . Évalué à 4.
Je sais pas de quoi tu parle, j'ai un cluster Kubernetes personnel avec Ceph pour le stockage.
[^] # Re: Informatique personnel
Posté par Eh_Dis_Mwan . Évalué à -1.
Très bien, moi j'ai une famille
[^] # Re: Informatique personnel
Posté par Anonyme . Évalué à 5.
Moi aussi, c'est justement pour ça que j'ai un cluster k8s. Comment j'hébergerais les services du foyer sinon ? 😛
[^] # Re: Informatique personnel
Posté par Eh_Dis_Mwan . Évalué à 0.
K8s je connais pas et cela me semble être un investissement pour y aller. Et je n'ai qu'un laptop donc l'interêt est limité
[^] # Re: Informatique personnel
Posté par Psychofox (Mastodon) . Évalué à 2.
Kubernetes ça peut être léger avec des distribs comme k3s et tu peux même imaginer une installation sur un seul noeud.
Par contre ceph ça n'est prévu que pour un minimum de 3 noeuds pour avoir un quorum, ça ne me parait donc pas hyper pertinent pour la maison si ce n'est pas pour se former.
[^] # Re: Informatique personnel
Posté par barmic 🦦 . Évalué à 1.
Avec un seul nœud k8s apporte plus de complexité que d'avantages par rapport à docker-compose.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Informatique personnel
Posté par damaki . Évalué à 1. Dernière modification le 25 novembre 2019 à 10:26.
Et jusqu'à arriver à un niveau de complexité où Kubernetes commence à briller, Ansible fera largement l'affaire. Franchement, si vos applis ne sont pas répliquées sur un paquet de serveurs, le ratio gain d'opérabilité/augmentation de la complexité n'est pas très favorable à Kubernetes.
Mais sinon, c'est un jouet amusant sur un petit cluster, oui. Ça n'a pas forcément besoin d'être utile, de toute façon ;)
Ah et en passant, K3S n'est pas encore considéré comme utilisable en production à caise de la haute dispo pas encore assez solide. Mais c'est très chouette pour faire des POCs.
[^] # Re: Informatique personnel
Posté par damaki . Évalué à 1. Dernière modification le 26 novembre 2019 à 14:31.
Je retire ce que j'ai dit, la 1.0.0 vient de sortir et la haute disponibilité a débarqué.
[^] # Re: Informatique personnel
Posté par steph1978 . Évalué à 2.
Commence par Docker. Ça finira par te donner envie de k8s… ou pas.
# GridFS
Posté par ash . Évalué à 2.
Salut, perso j'utilise GridFS sur un projet perso. Je ne sais pas si on peut dire que c'est du stockage objet mais ca fait le job si on utilise mongodb c'est intégré.
[^] # Re: GridFS
Posté par damaki . Évalué à 1. Dernière modification le 25 novembre 2019 à 10:29.
Il existe une façade S3 pour GridFS donc ça n'est pas hors-sujet.
[^] # Re: GridFS
Posté par Eh_Dis_Mwan . Évalué à 1.
Merci, je testerai ceci .
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.