Migration hébergements 2016/2017 vers 2022
Cette page est régulièrement mise à jour.
Dernière mise à jour
28 juillet : augmentation des ressources de toutes les offres
21 décembre : augmentation des limites IO (x4) de toutes les offres
Les migrations sont faites à la demande, pour les utilisateurs qui le souhaitent.
Veuillez noter que la migration ne permet aucun retour arrière sur l’ancienne infrastructure.
Si vous souhaitez migrer votre hébergement, les instructions sont en fin de page.
Les clients souhaitant rester sur l’ancienne infrastructure peuvent y rester, aucune migration n’est imposée.
En 2022 YULPA a lancé des nouvelles offres d’hébergements. Ces offres sont mono-serveur pour les rôles suivants :
fichiers
serveur FTP
serveur SSH
publication web HTTP
sauvegardes
Les rôles DNS et emails eux restent gérés par la plate-forme Zimbra et DNS mais vous conservez la gestion dans le manager au sein du même service d’hébergement.
Le but est d’apporter de meilleures performances, en effet nos anciennes offres reposant sur une architecture multi-serveurs fournissaient des performances assez aléatoires selon les sites et nombres de nos clients se plaignaient de lenteurs. Les premiers sites migré, ont des temps de chargement divisés par 3 à 6.
Par ailleurs, ces offres se voient appliquer des limitations en termes de ressources car l’ancienne infrastructure étaient souvent monopolisés par certains sites au détriment d’autres sans limitations possible de notre côté.
Une offre One permet à nouveau de bénéficier d’un hébergement pour un petit site web à faible coût.
Nous avons conçu un script de migration pour vous assister dans cette migration. Nous nous chargeons de quasiment toutes les étapes.
Cependant vous devrez effectuer des actions, merci de prendre connaissance de ce qui est listé en bas de cette page.
Le nombre d’éléments au sein d’un hébergement ne change pas, les offres Start 2022 ont les mêmes ressources que les Start 2017, idem pour les autres hébergements. Seul le quota d’espace disque est doublé car les sauvegardes SQL sont désormais stockées dans l’hébergement et l’espace occupé par les snapshots est pris également de votre espace disque.
Sur les hébergements 2016 et 2017, les snapshots sont en amonts de votre hébergement. Si vous avez 25Go vous pouvez les utiliser et les 6 mois de sauvegardes ne consomment rien.
Sur les hébergements 2022, les snapshots sont enfants de votre hébergement, si vous avez 25Go et effacez 5Go, ces 5Go seront toujours occupés durant 3 mois dans les snapshots.
Cela nous permet lorsque vous résiliez d’effacer toutes les données, y compris les sauvegardes et donc d’aller au delà des règles imposées par le RGPD.
Attention si vous avez une offre Web4all 2016, les quotas des offres YULPA 2017 ne sont pas les mêmes ⚠ Vérifiez avant sur le site http://yulpa.io les quotas des offres actuelle pour savoir si vous pouvez basculer en offre 2022.
Si vous avez une offre YULPA 2017 : vous allez conserver les mêmes quotas en offre 2022.
Element | Hébergement 2016/2017 | Hébergement 2022 |
|---|---|---|
Adresse IP | 185.49.20.101 | Dépend du serveur sur lequel vous êtes, zone DNS à adapter en fonction. |
Serveur MySQL | Accessible de l’extérieur selon le serveur sur lequel la base est créée. | Non accessible de l’extérieur. |
Sauvegardes MySQL | Stockées dans l’hébergement depuis mars 2022. | Stockées dans l’hébergement. |
Sauvegardes Fichiers | Externe à l’hébergement. N’impacte pas le quotas de stockage. Rétention 6 mois. Accessible depuis le manager. | Interne à l’hébergement. Est pris sur l’espace de stockage. Rétention 3 mois. Accessible depuis le manager et en SSH dans .zfs/snapshots |
Sites web | Stockés dans var/www/ | Stockés dans sites/ |
Quota Espace disque |
|
|
Ressources CPU | Non limité |
|
Ressources RAM | Non limité |
|
Ressources IOPS | Non limité |
|
Ressources IO | Non limité |
|
Ressources Processus | Non limité |
|
Mails envoyés depuis un site | Aucun suivi possible. | Possibilité de suivre les mails sortants dans la console Spam-Expert. Possibilité de recevoir les bounces en créant un alias ou adresse website@domain.tld Limite de mails :
|
Journaux Apache (visites sites web) | Copiés dans l’hébergement si demandés. Visible depuis iWal serveur par serveur sans fusion. | Stockés dans l’hébergement. Visible depuis iWal et en SSH en live. |
Ports ouvert en sortie | Tous |
le port 25 est fermé, vous ne pouvez pas utiliser un SMTP externe sur le port 25. |
Si vous souhaitez migrer votre hébergement :
ouvrez un ticket au support en indiquant l’hébergement que vous avez actuellement et à quel jour et heure vous souhaitez que la migration soit effectuée. Vous devrez modifier les paramètres SQL juste après la migration.
le support YULPA créera un nouvel hébergement à 0€ avec la même date d'échéance que l’actuel puis lancera le script de migration.
vous serez informé dans le ticket quand la migration sera terminée, l’ancien hébergement sera détruit.
Ce qui sera effectué sans impact :
Les délégations héritées du compte client seront valable sur le nouvel hébergement.
Tous les domaines de la partie “Synthèse des domaines” seront rattachés au nouvel hébergement.
Toute la partie Email Zimbra sera rattaché au nouvel hébergement.
Ce qui sera effectué avec impact :
Les utilisateurs FTP seront modifiés si une restriction d’accès est définies : var/www sera remplacé par sites. L’impact est à voir au cas par cas pour vos utilisateurs externes.
Les sauvegardes MySQL et fichiers ne seront pas copiés, vous perdez donc l’historique des sauvegardes.
Les entrées DNS seront modifiées de 185.49.20.101 à 185.49.20.10x (102, 103, 104… selon le serveur de destination). Une coupure de service de quelques minutes à une heure peut se faire.
Un utilisateur sortant sera créé sur Spam-Expert pour chaque site web. Il est nommé sous la forme website@domain.tld et apparaitra en return-path des mails envoyés. Cela doit être sans impact sauf si vous avez des utilisation particulière des mails envoyés via vos sites.
Des quotas de mails par heure, jour, mois… sont mis en place, voir le tableau ci-dessus.
Le compte SSH sera créé avec un nouveau mot de passe aléatoire. Il n’est pas possible de le changer depuis iWal, vous pouvez cependant mettre votre clé SSH dans le home de l’utilisateur.
Ce que vous devez effectuer :
Les délégations directes sur l’hébergement ne seront pas valable sur le nouvel hébergement. Vous devrez les recréer.
Les bases de données et utilisateurs MySQL seront renommées. Si l'élément se nommait 100010_wordpress (ID hébergement 100010) il sera renommé par exemple en 171989_wordpress (nouvel ID). Il faut donc mettre à jour vos fichiers de configuration SQL. ⚠ ⚠ ⚠ ATTENTION si vous avez des utilisateurs / bases datant d’avant 2011, préfixé avec 4 chiffres ou sans préfix (ex : 1213_madb et 100010_madb), un préfixe de 6 chiffres et _ sera ajouté / remplacé, il ne faut pas qu’un autre utilisateur préfixé ait au final le même nom (ex : 1213_madb → 171600_madb et 100010_madb → 171600_madb ). ⚠ ⚠ ⚠
⚠ ⚠ ⚠ Si vous avez des vues SQL, l’utilisateur lié aux vues n’existant plus sur les nouvelles DB, vous devez exporter les vues et les recréer avec le(s) bon(s) utilisateur(s) / droits.⚠ ⚠ ⚠
Le serveur MySQL change de nom, vous aviez avant mysql x .yulpa.io (X étant un numéro), il devient webhost XX .yulpa.io (XX est un numéro type 01, 02…). Il faut donc mettre à jour vos fichiers de configuration SQL.
Les fichiers User sont copiés de votre ancien hébergement vers le nouveau : ce qui était dans home/yulpaXXXXX sera copié dans home/
Les fichiers des sites sont copiés de votre ancien hébergement vers le nouveau : ce qui était dans var/www sera copié dans sites/ (les utilisateurs FTP et les crons sont modifiés à la volée par le script de migration), vous devez modifier vos fichiers de configurations / données en bases si vous utilisez des chemins absolus.
De même, si vous utilisez des .htaccess pour l’authentification des utilisateurs, vous devez modifier le chemin absolu pointant vers le auth_user_file.
⚠ ⚠ ⚠ Les entrées DNS qui ne sont pas gérés par YULPA sont à modifier de 185.49.20.101 à 185.49.20.10x (102, 103, 104… selon le serveur de destination). ⚠ ⚠ ⚠
Le nom de l’utilisateur SSH change vu qu’il est lié à l’ID de l’hébergement.