VPS cloud, VPS SSD, OVH, Scaleway, retours d'expériences

[kameleon1er]

Salut à tous

Je remonte mon post lié à https://forum.yunohost.org/t/souscription-a-un-vps-ssd-chez-ovh/5068/7 qui date d’un bon moment

Bon ! j’ai envie de passer le cap. Qui plus est après la lecture de Exadot.fr sur la sécurité.

je ne suis pas admin-sys, mais ai quand même quelques bagages en plus sur le sujet que Mme Michu.

Je suis sur des VPS depuis quelques années maintenant, au début avec panel sauce-ovh et aide d’amis admin-sys, ne souahitant pas à l’époque passer au Terminal et Debian.

Tout évolue Plus un jour sans le bon vieux Term de lancé.

J’ai un VPS chez Scaleway qui héberge 3/4 wordpress et un autre qui me servait de serveur de mail. La semaine dernière j’ai explosé le premier après un upgrade de Jessie > Strech moche !

J’ai tout de même réussi à tout réparer merci google à ce propos, l’a fallu en parcourir des forums dans toutes les langues. Mais comme je commence à avoir une bonne vision des ensembles formant un Lamp, étape par étape… M’en suis sorti.

Dernier point; les amis qui aident, c’est super, mais ils config quand même des trucs pas tout à fait clairs sans vous le dire, ne maintiennent pas forcément…

Donc… Je compte reprendre un VPS (cloud semble le plus souple) chez OVH (scaleway ; impossible de réinstaller une machine snapshotée sans d’abord la détruire, en recommander une nouvelle quand il y en a de dispo…)

Ce que je compte faire ; mes sites tournent sur l’instance scaleway donc suis pas au pièces ; installer Yunohost pour les mails déjà + j’aurais bien besoin de softs collaboratifs, genre Kanban ou Restya ou Wecan… chais pô encore…

Une fois que j’aurais un peu plus la bête en main, migrer mes sites, bien que je me souviens que Yunohost ne conseille pas de faire du “hosting” pour l’insant. Mais bon avec 4 sites, je pense que ça reste du “Michu-Hosting” ?

J’hésite aussi entre VPS SSD et VPS cloud, mais le VPS cloud même petit me parait revenir mensuellement aux alentours de 6€ (0,0080 € HT/heure) soit 0,0096 TTC > 24 = 0,23 X 30jrs pour juste 10 Go et 2 Go ram / pour le S1-4 on passe à 17 € si je ne me trompe pas.

à l’heure actuelle en faisant un [ top ] sur mon scaleway 4Go ça donne ça :

top - 21:45:51 up 2 days, 24 min,  1 user,  load average: 0.08, 0.06, 0.07
Tasks: 112 total,   1 running, 111 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem :  4045672 total,   946480 free,   477880 used,  2621312 buff/cache
KiB Swap:        0 total,        0 free,        0 used.  3145004 avail Mem 

Si je souhaite à terme déplacer mes sites sur Yunohost j’ai bien peur que les 2 Go de la S1-2 du vps cloud soit trop juste.

[Limezy]

Regarde plutôt les coûts au mois, qui sont 2x moins chers que les coûts à l’heure chez OVH !

Ensuite, je te conseille vivement de construire ton VPS dès le départ sur un mode OS sur le disque du SSD, et données sur un disque attaché. Il est toujours possible de faire des déplacements plus tard, mais c’est stressant et générateur d’erreurs. Commencer avec un tout petit disque attaché et le faire “grandir” au fur et à mesure de tes besoins est plus safe car tu peux sauvegarder ton disque seul et faire des manips dessus sans toucher à l’OS en lui-même.

Et d’ailleurs, car OVH facture au “poids”, faut pas s’embêter à tout mettre sur un gros disque. Plus j’utilise mon VPS plus je multiplie les disques. Tout me paraît mieux organisé. Un disque pour les emails, un pour Nextcloud, un pour l’hébergement d’un site…

EDIT : Ah oui et en effet, surtout prends un VPS cloud et non pas SSD. Le prix est le même mais la souplesse bien meilleure sur le cloud. Possibilité de plusieurs disques attachés, sauvegarde indépendante des disques etc… La complexité de mise en route est très légèrement supérieure mais c’est anecdotique comparé aux avantages.

My 2 cents

[kameleon1er]

Salut Limezy, merci pour ce retour.

Oui effectivement j’avais zappé le petit bouton “au mois”

Quand tu dis “splitter” au maximum les données, concept avec lequel je serais plutôt d’accord, c’est ce que tu fais par exemple pour Wordpress ? Genre, BDD sur un serveur et wp-content sur un autre ou sur un DD rattaché ? Parce que ça j’ai jamais fait encore.

En terme de contribution à Yunohost, je serais assez partant pour rédiger à plusieurs un How-To dans cette problématique spécifique du petit herbergement WPress avvec éventuellement quelques apps externes utiles pour des Mme et M. Michu (sécurité correcte (pas forcément de ouf non plus, bonnes pratiques) , backups <–> restore --> migration, calendrier, mails, kanban, tiketing…) sans être exhaustive, une liste dans le genre.

Je sais qu’il y a tout ça dans les forums et tutos partout sur le net, mais généralement il n’y a jamais rien de complet d’un coup, il faut recouper dans tous les sens.

Pour ma part je suis un auto-hébergé (VPS) moyen et je continue d’en apprendre tous les jours, mais j’ai encore par mal de territoires “sombres” dans ma map mentale. Normalement je suis plus enclin à faire des sites, et/ou conseiller des solutions utilisateur final. Mais aujourd’hui il faut toucher un peu à tout.

Yuno, me semble un bon point de départ pour couvrir pas mal d’aspects d’un petit hosting SaaS de qualité et moderne administrable sans être admin-sys forcément.

J’ai bien sûr pas mal parcouru le forum ces derniers temps, et je vois tout de même des utilisateurs très avancés Linux et système. Ce qui est super bien sûr, mais il manque peut-être quelques “directives” pour des utilisateurs situés entre le newbie total, le newbie qui a déjà fait un peut de chemin et l’expert, ce qui me semble un peu dommage au regard des intentions qu’il m’a semblé comprendre d’un tel projet.

Et ainsi remonter également à la team développement, des idées, des retours d’expérience d’utilisateurs non-experts.

En tout cas, si ça intéresse quelqu’un… welcome

Merci

[Limezy]

Hello @kameleon1er, je suis d’accord qu’il y a un peu un creux de documentation entre le newbie total et l’expert Linux / développeur. Je suis moi-même dans cette catégorie.
Il y aurait évidemment un intérêt à créer de la doc pour “notre” niveau d’utilisateurs, qui est peut-être d’ailleurs en proportion la plus importante parmi les utilisateurs de Yunohost.

Néanmoins, je me dis quand même que ce forum est peut-être en fait notre meilleur outil. On comprend globalement ce qu’y s’y passe ainsi que les explications données par les “grands maîtres”, on est capables de suivre les tutos même les plus cossus, on est capables d’avoir une idée d’où viennent nos problèmes et de les faire remonter ici pour qu’ils soient corrigés par les plus experts etc…
Je me demande donc si dans la plupart des cas le mieux n’est pas justement de fréquenter ce forum et de le faire vivre, en faisant profiter les plus débutants de notre niveau intermédiaire - ce qui décharge notemment les plus experts et leur laisse plus de temps pour continuer à développer Yunohost !

Pour répondre plus précisément à ta question, je n’héberge pas de site, je ne me suis donc jamais penché sur les problématiques purement liées à Wordpress. Mon Yunohost est plutôt mon “nuage privé anti-google”, avec Nextcloud, emails, Keeweb, Wallabag, sondages, etc…

En termes de saucissonage des données, j’ai en gros un disque pour les emails et un disque pour le nextcloud de chacun des (quelques) utilisateurs de mon serveur.

[rodinux]

Bonjour,
je m’inspire de votre discussion pour installer un service avec un public cloud chez ovh. J’ai ajouté un disque, que j’ai formaté et monté. Mais si je veux dès l’installation mettre mes données sur ce disque, comment dois-je le monter ? Pour l’instant le disque externe est monté sur /mnt/disk dans le fstab. Peut-on dès l’installation de yunohost utiliser ce disque pour les données ?

[rodinux]

En gros, après une post-installation, quelle partition monter sur le disque externe ?

[Limezy]

Hello,

C’est personnel et je pense qu’il n’y a pas de solution parfaite, mais j’ai un disque pour les emails monté dans /var/mail et un disque de stockage (notamment Nextcloud) monté dans /home. Tout le reste tient (amplement) sur les 10GB par défaut du serveur.
Si mes utilisateurs commencent à vraiment consommer beaucoup de donnée, je monterai certainement un disque dédié dans chaque /home/yunohost.app/nextcloud/data/user (accessoirement ça permet de savoir exactement combien me coûte le stockage de chacun, de faire des sauvegardes indépendantes etc…).

[Limezy]

Attention à bien faire un copy -a quand tu déplaces les données sinon tu risques de tout casser.
L’idée est de garder tous les attributs de tes fichiers (propriétaire, dates de création / modification, permissions etc…)

[martoni35]

Hello,
Et pourquoi pas Kimsufi de chez OVH ? (En plus, tu peux suivre les promo sur dealabs et te mettre une alerte ) Pour le prix, tu en prends 2 comme ça tu peux externaliser tes sauvegardes ou configuré un serveur de secours que tu mets à jour de manière régulière.
En cas de crash, une simple redirection DNS et c’est reparti
Je suis chez eux depuis presque 1 an pour yunohost et c’est bien.
J’en ai pris 2 car comme c’est des serveurs dédié et physique, il se peut qu’un matériel lâche et pour le secours, j’en ai pris un second qui stock mes backups 3x/semaine.

martoni

[gannonwoto]

Je confirme ce que tu dis.
J’utilise un serveur dedié Kimsufi depuis plus de 2 - 3 ans il me semble et j’ai jammais eu de problème avec le serveur ou avec Yunohost.
Enfin yunohost oui, mais c’etait avec une application en “testing”

Cependant, et c’est quand meme à prendre en compte : je suis presque le seul à l’utiliser.

[rodinux]

Du coup j’essaie un cloud ovh, mais une offre petite. Mon idée est de faire un outil de communication interne pour une association, donc nous serions plusieurs utilisateurs. C’est un peu un test…
Cependant je me demande comment bien configurer les emails avec un site en ynh.fr sur un cloud ? Sinon, ça peut rester un outil interne où les mails des utilisateurs ne servent que aux applications internes du serveur…

[ljf]

@rodinux

Cependant je me demande comment bien configurer les emails avec un site en ynh.fr sur un cloud ? Sinon, ça peut rester un outil interne où les mails des utilisateurs ne servent que aux applications internes du serveur…

Ben si c’est en ynh.fr il faut juste penser à mettre le reverse DNS chez ton fournisseur de VPS. Et croiser les doigts pour qu’il supporte reverse ipv4 et ipv6…

Sinon pour info chez ARN, on fournit des VPS en dehors des gros hébergeurs mondiaux, et on supporte yunohost en OS pré-installé (ubuntu et debian aussi). Il est également possible de fair el’installation soi même par exemple pour chiffrer le disque. vps.arn-fai.net
Bon faut pas perdre de vue qu’ARN c’est associatif, militant, libristes etc…

[rodinux]

Merci pour tes précieuses infos. Du coup, j’ai pu mettre un reverse dns pour l’ipv4, pour l’ipv6 j’ai un message d’erreur pour l’instant… Je crois que l’ipv6 n’est pas bien pris en compte avec ovh…
J’ai aperçu ce tutto: https://docs.ovh.com/fr/public-cloud/configurer-ipv6/#preambule
Mais j’ai des doutes…
Je me rend compte par exemple que mon fichier /etc/network/interfaces ressemble à ceci:

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

    source /etc/network/interfaces.d/*

    # The loopback network interface
    auto lo
    iface lo inet loopback

    # The primary network interface
    allow-hotplug ens4
    iface ens4 inet dhcp

est-ce que je devrait pas mettre ‘static’ au lieu de ‘dhcp’ ?
si je veux ajouter l’ipv6 pris en compte, dois-je rajouter une ligne comme ceci:

iface ens4 inet6 static
address YOUR_IPV6
netmask IPV6_PREFIX
post-up /sbin/ip -6 route add IPV6_GATEWAY dev ens4
post-up /sbin/ip -6 route add default via IPV6_GATEWAY dev ens4
pre-down /sbin/ip -6 route del default via IPV6_GATEWAY dev ens4
pre-down /sbin/ip -6 route del IPV6_GATEWAY dev ens4

Ce qui me trouble c’est cette connexion ens4, est-ce que ‘dev ens4’ existe vraiment ?

[rodinux]

En tous les cas, je retiens ton adresse de FAI chatons et vais y réfléchir aussi.

[Limezy]

Je n’ai jamais essayé les produits « Kimsufi » de OVH, mais je vois quelques (petits) inconvénients.
Ça concerne surtout la possibilité d’expansion de ton serveur (disques rattachés, possibilité de migrer sur plus de puissance sans tout réinstaller etc…).
Sachant que sauf erreur les tarifs Kimsufi sont exactement les mêmes que l’entrée de gamme Public Cloud (2.99€ HT par mois pour un VPS de base) je trouve ça dommage de se priver de l’option plus “pro” et flexible !

[Limezy]

OK après vérification :

• Le Kimsufi a pour lui un très léger avantage, car il donne 20GB de disque sur le VPS en natif, contrairement aux 10GB de l’entrée de gamme Public Cloud (au même prix exactement)
• Néanmoins, le Kimsufi n’autorise qu’un seul disque supplémentaire, et les disques supplémentaires sont forcément “standards” (pas d’accès aux disques haute performance, donc).
• Les snapshots sont possibles sur Kimsufi, mais en manuel uniquement (mes snapshots sont automatisés tous les mois)

En bref, pour un Yunohost sur lequel on est seul et pour lequel on est certain de ne jamais avoir besoin de trop de données, le Kimsufi est très légèrement avantageux.
Pour le reste -> Public Cloud !

[crustyourmind]

Interessé par ce thread, j’ai un VPS SSD chez OVH
Messagerie, plusieurs domaines, dokuwiki, site statique, WP
Je suis cette discussion et si vous voulez un retourn d’expérience sur cette config précise, pas de soucis

Longtemps hésité entre le kimsufi, le contabo… Finalement ai pris le SSD d’OVH car déjà client et relativement rassurant

[rodinux]

J’ai une question subsidiaire. Est-ce qu’il ne faut pas changer un peu le fstab pour optimiser les écritures sur les disques d’un Public Cloud ? C’est un disque SSD j’imagine ? Quoi que OVH semble utiliser IOP, je ne sais pas la différence ?
Voici mon fstab sur ce cloud:

$ cat /etc/fstab 
# partition root sur sda
UUID=7e172576-0bfc-4956-94cd-c7f79b58ec98 / ext4 errors=remount-ro,discard 0 1
# partition home sur sdb
UUID=7ed1f365-6294-4e64-b216-a123b4b0f8de /home ext4 nodev,nosuid 0 2
# Entry for /swapfile :
/home/file.swap none swap sw 0 0

Je trouve bizarre par exemple avoir un discard pour le disque root ? Est-ce que l’on peut réduire les écritures de tmpfs ? Un peu comme suggéré dans ce topic Linux SSD ? Ce n’est peut-être pas conseillé sur un serveur ?
Déjà on ne trouve pas le paquet zram-config sur le serveur, bizarre…
Par contre sur mon serveur auto-hébergé, j’ai ajouté au fstab une ligne:

tmpfs /tmp tmpfs defaults,relatime,mode=1777,nosuid,size=4196M 0 0

C’est contre-indiqué ?

[rodinux]

Bonjour,
je galère encore pour bien configurer l’ipv6 sur un Public cloud d’ovh.

J’ai essayé d’éditer le fichier /etc/network/interfaces comme ici:

auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug ens4
iface ens4 inet dhcp

# add ipv6 address
iface ens3 inet6 static
address 20xx:xxxx:xxx:xxxx::f4c
netmask 128
post-up /sbin/ip -6 route add 20xx:xxxx:xxx:xxxx::1 dev ens3
post-up /sbin/ip -6 route add default via 20xx:xxxx:xxx:xxxx::1 dev ens3
pre-down /sbin/ip -6 route del default via 20xx:xxxx:xxx:xxxx::1 dev ens3
pre-down /sbin/ip -6 route del 20xx:xxxx:xxx:xxxx::1 dev ens3

Sachant que j’ai ceci:

ens3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet XXX.XXX.XXX.XXX  netmask 255.255.255.255  broadcast XXX.XXX.XXX.XXX
        inet6 feXX::XXXX:XXX:XXX:XXX  prefixlen 64  scopeid 0x20<link>
        inet6 20XX:XXXX:XXX:XXXX::f4c  prefixlen 128  scopeid 0x0<global>
        ether fa:16:3e:80:e4:bb  txqueuelen 1000  (Ethernet)
        RX packets 286112  bytes 43109113 (41.1 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 399495  bytes 89399971 (85.2 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1  (Local Loopback)
        RX packets 265840  bytes 60368625 (57.5 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 265840  bytes 60368625 (57.5 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

et dans mon registar j’ai essayé de mettre

m_n_d.tld. 0 AAAA 20XX:XXXX:XXX:XXXX::f4c
*m_n_d.tld. 0 AAAA 20XX:XXXX:XXX:XXXX::f4c
et d’ajouter l’ipv6 pour le MX, mais ça cloche encore…
Je dois me tromper, où ? peut-être une histoire entre le ens4 et le ens3 ?

Pardon, c’est résolu depuis un moment, je viens de retomber sur ce fil de discussion…

[rodinux]

Je relance une demande ici, est-ce que l’un d’entre vous à tenter la migration de Yunohost pour passer de la version Stretch à Buster sur un Public Cloud OVH ?
Je pose la question avant de me lancer car j’ai un peu peur de la gestion des kernels Debian chez ovh qui est parfois particulière. Sinon je pense d’abord faire un snapshot avant de me lancer au cas où ça plante…