Scaleway => Discussion démarrée par: Phach le 22 juin 2020 à 12:01:34 Scaleway => Discussion démarrée par: Phach le 22 juin 2020 à 12:01:34Pour vous remercier pour votre confiance, nous vous offrons :
Vos frais de désarchivage et de transferts de données C14 Classic.
Le montant de votre facture C14 Cold Storage de Juin 2020 si vous migrez vos données C14 Classic vers C14 Cold Storage en Juin 2020 ! Pour bénéficier de cette offre, vous avez jusqu’au Mardi 30 Juin 2020 inclus pour nous communiquer vos identifiants Scaleway Dedibox et Scaleway Elements
Enfin, afin de vous organiser au mieux pour basculer vos données, le processus de fin de vie se fera progressivement, en deux temps :
26 Juin 2020 : Vous n’aurez plus la possibilité d’archiver de nouvelles données depuis C14 Classic. Mais aurez toujours la possibilité de désarchiver vos données existantes.
26 Novembre 2020 : Interruption et suppression du service C14 Classic.
Oh purée :o :oavec 1mois, dans certaines boites tu n'as meme pas le temps de caler 1 réunion que le service est déjà stoppé xD
Ils sont malade chez Scaleway... Un service de cold storage tué 4 ans après sa création... N'importe quoi!
Ils vont faire fuir les clients avec ce genre de pratique. Franchement, ça n'est pas sérieux du tout.
Je me rappelle d'Arnaud (De Bermingham) qui nous disait que les "4 ans" dans le contrat, c'était juste pour le contrat, et que c'était bien un service pour durer bien plus de 10 ans. Sans commentaire.
Et le délai de prévenance serait de seulement 1 mois (fin mai à fin juin) pour l'ajout de nouvelles données. Une entreprise qui a développé un SI (ou pire, fait développer un SI) autour de C14 n'a pas forcément le temps de se retourner en seulement 1 mois!
Scaleway continue à descendre sérieusement dans mon estime. Ils nous avaient habitué à mieux quand même.
Il est beau le cloud européen, il est beau. Et c'est pas Gaia-X qui pourra changer quelque chose si nos acteurs ne se mettent pas au niveau en pensant client avant tout.
Leon.
Globalement, ils n'ont rien prévu pour migrer de c14 classic à c14 object storage via l'interface et en restant sur leur réseau interne. Faut tout faire à la main et tout transite par le poste qui fait le clonage.Tu avais suivi ce guide, pour faire la migration?
Soit j'ai loupé un truc, soit c'est clairement mal expliqué. Mais en tout cas, dans mon cas, ca tourne très très très très lentement. Et je vais pas louer une machine pour faire ça.
Salut Phach, Tu avais suivi ce guide, pour faire la migration?
Je crois comprendre qu'ils ont prévu un outil spécial pour migrer les données. Mais je ne suis pas certain de tout comprendre.
https://www.scaleway.com/en/docs/data-migration-c14-classic/#-Data-Migration-using-C14CLI
Leon.
le C14 classic c'etait du S3 classique, maintenant c'est cold storage ou rien ?
Malheureusement, ca ressemble à du ovh qui annonce un super truc innovant pour le tuer quelques temps après.C'est là où la promesse du Cloud n'est pas tenue chez OVH et chez Scaleway: les offres n'assurent pas de compatibilité ascendante et descendante.
Cher client,
Le 29 Mai, nous vous annoncions que le service C14 Classic entrait dans un processus de fin de vie. Cette solution, qui a prouvé sa fiabilité, ne s'intègre plus dans notre volonté de proposer des solutions plus flexibles et ouvertes sur les standards actuels.
Nous vous rappelons donc que ce service et vos données seront supprimés le 26 Novembre 2020. Nous vous rappelons également que la récupération de vos données est totalement gratuite.
Attention à ne pas confondre stockage S3 et S3 cold storage (Glacier). Ton NAS gère probablement le S3 classique mais je doute qu'il sache faire du cold storage, il y a une notion d'archivage et desarchivage avec des délais, ce n'est pas facile à automatiser.Désolé, j'utilise le mauvais terme en effet. C'est "Object Storage" qui est présenté comme compatible avec Hyper Backup de Syno.
Il faut se poser la question si le cold storage est acceptable pour du backup ou pas, il peut y avoir un délais de plusieurs jours avant de pouvoir accéder aux fichiers, en cas de restauration, est-ce acceptable ?
Les tarifs me semblent pourtant clairs, stocker 100 Go revient à payer 25 Go puisque 75 sont offerts. Et ensuite chaque Go supplémentaire est facturé bien sûr.
Transfert de données sortantes intra-région gratuit
Transfert de données sortantes inter-région 75 Go gratuits chaque mois
Salut,Effectivement, le tuto fourni n'est qu'une assistance à l'utilisation d'rclone.
Oui c'est l'outil que j'utilise et je suis scrupuleusement la doc. Ca simplifie la configuration de rclone.
Mais de ce que je constate, comme je l'ai dit plus haut, ca utilise la connexion du poste sur lequel est lancé la commande comme intermédiaire. Hier, j'ai réussi à transférer 70 Go, là je termine avec les 15 derniers Go. L'outil m'annonce 18 minutes pour faire le transfert.
Je pense faire parti des chanceux qui n'ont qu'une petite quantité de données à migrer.
J'ai rencontré des problèmes au début de la migration, à cause d'une mauvaise compréhension de la doc (sur la taille des chunks qui n'est pas clair du tout) qui a conduit à des erreurs sur certains fichiers que j'ai du renvoyer à la main. Une fois la config remise par défaut, tout s'est déroulé sans erreur.
#!/bin/bash
if [ "$#" -lt 3 ] ; then
echo "$0 <bucket-name> <bucket-subdir> <file1|dir1> [file2|dir2] ..."
exit 1
fi
BUCKET_NAME=${1}
BUCKET_SUBDIR=${2}
TEMP_DIR="/media/dd/Media/Temp/"
# Tant qu'il reste des fichiers/dossiers à zipper
while [ ! -z "${3}" ] ; do
to_zip=$(basename "${3}")
# Remplacement des caractères accentués, par leurs équivalents non accentués
# + Remplacement par "_" des caractères autres que ceux autorisés
# cf. https://docs.aws.amazon.com/AmazonS3/latest/dev/UsingMetadata.html#object-key-guidelines
zip_file=$(echo -n "${to_zip}.zip" | iconv -f utf8 -t ascii//TRANSLIT | tr -c 'A-Za-z0-9_.\-\(\)' '_')
# Afficher les commandes avant exécution
set -x
# Zip (0% de compression) + envoi du zip vers AWS S3 GLACIER
zip -Z store -r "${TEMP_DIR}/${zip_file}" "${to_zip}" && \
aws s3 cp "${TEMP_DIR}/${zip_file}" "s3://${BUCKET_NAME}/${BUCKET_SUBDIR}/" --storage-class GLACIER && \
rm "${TEMP_DIR}/${zip_file}"
# Désactivation set -x
{ set +x ;} 2> /dev/null
# Argument++
shift
doneCertains ici utilisent le service object-storage de Scaleway ? Et leur option Cold storage ?Je confirme, j'ai constaté des mêmes problèmes, probablement causé par des caractères non pris en charge.
J'ai très très régulièrement des problèmes pour restaurer des objets depuis GLACIER. Parfois ça se fait en quelques minutes, d'autres fois rien du tout après plusieurs jours. Obligé de contacter le support, et comme par magie quelques heures après le fichier sort du glacier. Parfois avec une explication du support (les espaces dans les noms d'objets n'étaient pas pris en charge LOL), parfois juste ils "constatent" que le fichier a été restauré, comme par hasard après plusieurs jours et après les avoir contacté...
C'est super relou, c'est censé être un truc automatique. Je comprend bien le délais pour la restauration, ça peut s'automatiser sans soucis. Mais s'il faut contacter le support pour débloquer une situation c'est nul.
Sans compter que le support est assez chaotique. Une fois sur 2, on tombe sur un N1 qui n'y connait rien et répond à côté. Quand il comprend et transfère au N2, le N2 répond en demandant des infos. On envoit la réponse, c'est un N1 qui répond et qui re-transfère au N2... Génial.
| Caractères alphanumériques | Caractères spéciaux |
| 0-9 a-z A-Z | ! - _ . * ' ( ) |
Ma conclusion est que la migration risque de faire fuire des clients. Il y a de fortes chances que les clients utilisent cet outil aussi pour aller voir ailleurs (AWS par exemple) surtout quand un service annoncé comme pérenne s’arrête au bout de 4 ans.Complètement d'accord !
Ils auraient clairement du développer un truc pour que la migration se fasse de manière automatisée via l'interface.
Mon point de vue est que le système classic n'était pas pleinement satisfaisant pour scaleway en terme de maintenance. Il ne répondait pas à la demande des pros qui veulent une compatibilité S3.
Malheureusement, ca ressemble à du ovh qui annonce un super truc innovant pour le tuer quelques temps après.
Ce qui est piégeux, c'est que la commande "aws s3 cp" accepte les caractères problématiques (espaces, caractères accentués ...) sans broncher.
Mais j'ai constaté sur certains de ces fichiers, qu'il m'était impossible de les récupérer (opération de changement de classe CLASSIER > CLASSIC qui dure des heures et n'aboutit jamais).
Résultat des courses, des offres bâclées, des bêta sans en voir le bout et un service instable qui se casse la figure au bout de seulement quatre ans.Ils reproduisent ce qui a fait la réussite d'OVH !
Comme quoi, partir d'un hébergeur de qualité et plutôt classique/conservateur, et en faire un cloud provider hyper tendance, innovant, et aller concurrencer les AWS et Google, ça n'est pas si simple...
Leon.
Petite info concernant l'object storage.
Officiellement aujourd'hui, les buckets sont supportés jusqu'à 500000 objets. Même s'il est possible d'y mettre plus, ils deviennent souvent instables et obligent à passer par le support pour résolution.
Le support vient de m'informer qu'une mise à jour du service est prévue pour la fin d'année (sans garantie de délais) pour lever cette limite technique.