Test de Google Cloud Storage et d'autres

De Xala le 17/07/2017 - 1500285600

Alors oui, c'est étonnant pour un anti-GAFAM mais bon... nous ne pouvons pas toujours faire ce que l'on veut. Quand le client demande et qu'il reste sur sa position après nos alertes, on se tait et on fait... En tout cas, j'ai testé différentes offres et je voulais partager mon retour d'expérience et mes impressions.

Pour situer le contexte, le besoin du client est de pouvoir disposer d'un stockage cloud pas cher pour y stocker des archives et sauvegardes.

En premier lieu, le choix s'était porté sur OVH et ses offres "Object Storage" et "Cloud Archive", toutes deux basées sur OpenStack. Pour comprendre ce choix, le premier critère de sélection du client était le tarif et les solutions OVH entraient dans le budget. Je me lance donc sur la mise en œuvre d'un système d'archivage quasi automatique avec la documentation qui va bien. Après quelques mois de production l'accès au service OVH est coupé... Cela fait suite à des problèmes administratif entre OVH et mon client qui s'est terminé par la perte sèche de 2To de données. J'ai donc dû revoir mon projet d'archivage -comprendre tout refaire- sur une autre plateforme... Azure étant plus cher comparé à AWS et GCP, nous l'avons écarté du projet. Quand à GCP, il est très agressif sur ses tarifs. En effet, même si OVH propose des solutions avec une grille tarifaire très intéressante et proche de Google, ce dernier arrive à faire mieux. Nous optons donc pour la solution "Nearline" de Cloud Storage qui est le premier niveau de stockage froid (un mois minimum). La solution "Coldline étant le deuxième niveau (un an minimum). Note non négligeable concernant la tarification de l'offre Glacier (stockage froid) chez AWS, c'est que le coût peut très vite exploser lors de la récupération des données.

Pour commencer, il faut comprendre la notion de stockage chaud et froid proposée par toutes les plateformes citées précédemment. Car outre la tarification qui diffère entre les deux solutions, le coût de stockage étant moindre sur la solution froide, l'usage n'est pas le même non plus. En effet, sur une solution chaude, nous allons y stocker des données qui vont possiblement être téléchargées et/ou modifiées couramment alors que la solution froide est plus pour du stockage de données qui ne seront pas modifiées ou très peu. Comme le nom de l'offre OVH l'indique, la solution froide est disposée à du stockage d'archives, des sauvegardes par exemple. Ce qui correspond parfaitement au besoin du client.

D'un point de vue technique, comme pour OVH, l'installation des outils Google sur Debian est relativement simple. Pareil pour la configuration de l'environnement (authentification, projet GCP etc). Seul le vocabulaire change entre OVH et AWS/GCP. Par exemple, un espace de stockage nommé "container" sur OVH et appelé "bucket" chez Amazon et Google. Aussi, la cli des outils Amazon et Google est très similaire. J'imagine que ces deux plateformes utilisent les mêmes solutions sur leurs infrastructures. Cependant, j'ai pu noter une grande différence entre Amazon et Google et c'est au niveau de la documentation. En effet, Google a fait un gros effort sur la documentation en détaillant bien toutes options de ses outils. Tandis que chez Amazon, nous sommes parfois un peu dans le flou, que ce soit via l'aide en cli ou la documentation web.

Il y a un troisième point important à noter et qui est, encore, en faveur de Google. En effet ce type de stockage cloud a des limitations dans la taille des fichiers (objets). Bien évidemment, cette limitation diffère selon la plateforme choisi. Chez Amazon, la taille max. d'un objet est de 100Mo contre 5Go chez OVH et 5To chez Google. Donc si nous voulons envoyer sur notre bucket Amazon un fichier de 10Go, il faudra le "spliter". Pareil chez OVH. Petit détail négligeable, les outils d'OVH permettent un split de notre fichier de façon simple, alors que pour Amazon, il faudra utiliser l'outil 'split' disponible par défaut sur les distributions de la branche Debian.

Aussi, j'ai pu observer dans la documentation, que Google peut très bien interagir directement avec les solutions Amazon. Par exemple, via cli, nous pouvons très bien faire une copie d'un bucket S3 sur un bucket Cloud Storage:

gsutil rsync -d -r s3://my-aws-bucket gs://example-bucket

Ceci dit, en terme de facturation, je ne sais pas du tout comment ça se passe. Je sais que du côté de Google ce type de transfert est soumis à une grille tarifaire spécifique mais pour ce qui est du côté d'Amazon aucune idée. Dans tous les cas, le fait que cela soit possible est bon à savoir.

Points avantageux pour OVH, c'est que l'accès aux conteneurs n'est pas obligatoirement faisable avec l'utilitaire OpenStack Swift. En effet, OVH supporte aussi des connexions SCP/SFTP. Ce qui peut être un plus dans certains cas. Aussi, il semble possible de synchroniser un NAS Synology ou configurer Owncloud (et donc Nextcloud j'imagine) avec l'offre Object Storage (chaud).

Ce que je retiens de ma petite "étude" comparative, c'est que parmi ces quatre plateformes, seule deux sortent du lot, GCP et OVH (selon moi). Après, il faut noter que je n'ai testé qu'un seul produit isolé parmi les nombreux autres (calcul, réseau, big data et j'en passe) que proposent chacune de ces plateformes. Aussi, outre l’aspect technique, j'ai pu en apprendre un peu plus sur ce type d'offres, ainsi que des nouveaux termes comme la notion de stockage chaud et froid. Comme on dit, il n'y a pas de petits plaisirs :)

Travailler sur ce projet m'a aussi donné des idées d'usage personnel. Par exemple, avec un ami, nous sommes en train de concevoir un plan de sauvegarde pour nos données personnelles (papier administratif, photo, travail perso etc) entre nos syno. Parce que c'est cool d'avoir un NAS à la maison pour mettre à l’abri nos données d'un disque qui pète mais qu'est ce qui se passe si la maison brûle? D'où l'idée de géo-répliquer nos données sensible avec le NAS des copains (sauvegardes chiffrées bien sur). Mais mon ami est adepte des sauvegardes "3-2-1", c'est à dire, 3 copies, 2 supports distants, 1 cloud. Donc si un jour, on optait pour un support cloud, je pense que je me dirigerais volontiers vers une offre OVH ou Google. Toujours dans la condition de chiffrer les données avant l'envoi! Quitte à donner des sous pour ce type de services, autant se tourner vers l'entreprise Française qui en plus n'est pas (encore?) dans les rangs des GAFAM.


Article de Xala et photo de Gozha Net - Unsplash

Next Post Previous Post