Blogmotion est hébergé chez Yulpa, qui propose maintenant des serveurs VPS sous forme de container.
J'ai pu tester un serveur VPS avec l'intégration complète dans le panel maison IWAL.
Container
Yulpa propose ce service d'hébergement sous forme de container Linux en exploitant la technologie LXD, qui est un logiciel libre développé par Canonical sous forme de surcouche logicielle à LXC (LinuX Container).
Je rappelle qu'un VPS est un serveur dédié, vous avez accès à la totalité de la machine, mais il est virtuel. C'est à dire que ce n'est pas un serveur physique mais un serveur virtuel, ce qui évite les pannes matérielles. En contrepartie vous partagez des ressources (CPU, mémoire) avec d'autres clients.
Choix de l'OS
Plusieurs systèmes d'exploitation sont proposés : Ubuntu, CentOS et Debian. Avec pour chaque distribution plusieurs versions possibles :
L'installation se fait en quelques clics et le serveur est disponible très rapidement, je dirai environ 1 minute pour ma part. Derrière c'est une infrastructure KVM qui se charge de la virtualisation.
Voici les spécifications de mon serveur VPS :
L'accès se fait via un utilisateur au choix à l'installation, l'accès root n'est pas autorisé pour des raisons de sécurité. Mais rien ne vous empêche de modifier la configuration SSH si vous aimez le risque.
Comme Yulpa dispose de son propre AS forcément la latence est très réduite :
PING google.com (216.58.209.238) 56(84) bytes of data. icmp_seq=1 ttl=57 time=0.887 ms icmp_seq=2 ttl=57 time=1.10 ms icmp_seq=3 ttl=57 time=1.01 ms icmp_seq=4 ttl=57 time=0.938 ms icmp_seq=5 ttl=57 time=0.927 ms icmp_seq=6 ttl=57 time=0.949 ms icmp_seq=7 ttl=57 time=0.900 ms
L’intérêt du container est un cloisonnement total au niveau de l'OS mais un partage du même noyau linux, contrairement à une machine virtuelle qui dispose de son propre kernel linux.
Pour la gestion du container vous pouvez prendre la main à travers un fake KVM pour se retrouver virtuellement face à l'écran :
En cas de plantage il est possible d'arrêter, redémarrer ou démarrer le serveur via IWAL.
La force de Yulpa
Le gros plus de Yulpa concerne l'aspect sauvegarde, inclut en mode snapshot du système de fichiers. Avec possibilité de restauration sélective ou complète sur plusieurs heures/semaines/mois. Faites le tour de la concurrence et faites-moi signe si vous voyez une granularité aussi forte à ce tarif là.
A noter également que l'infrastructure devrait passer en 10G prochainement, même si côté performances pour l'instant je n'ai rien à dire ça répond au doigt et à l’œil.
3 offres
Plusieurs offres sont proposées chez Yulpa :
Évidemment ce sont les performances qui varient en fonction des ressources : vCPU, mémoire vive et capacité disque. La bande passante et le nombre d'IP sont identiques sur toutes les offres.
Le tarif est plus intéressant si vous payez sur 12 mois, mais rien n'empêche d'essayer pour un mois.
Attention : docker n'est pas supporté.
Conclusion
Si avez avez un besoin d'hébergement rapide, ou pour des tests, un labo... je pense que ce type de container est plutôt adapté. Avec un boot ultra et une installation rapides, le tout est fluide et réactif. Si l'on compare tout ceci à un serveur physique qui met plusieurs minutes à démarrer à cause des tests de boot, c'est le jour et la nuit.
Et sans parler de l'impossibilité de panne, comme tout est virtualisé et sous maitrise chez Yulpa... pas de risque de perdre la carte PERC, une grappe raide, une barrette mémoire...
C'est aussi un bon moyen d'apprendre à utiliser un serveur grâce au système de snapshots, vous pouvez facilement revenir en arrière en cas de bêtise.
Retrouvez tous les détails des offres sur la page dédiée.
Auteur : Mr Xhark
Fondateur du blog et passionné par les nouvelles techno, suivez-moi sur twitter
4 commentaires
Salut,
Personnellement ça fait deux mois que j'ai basculé mon site devenu bien trop gourmand en ressources d'un mutualisé Yulpa à un container, je regrette pas l'investissement (j'ai dû prendre la plus grosse offre pour avoir de la marge). Le support hyper réactif et les sauvegardes ça a de quoi faire pencher la balance, surtout quand on est totalement débutant dans ce domaine comme moi.
Yo,
C'est bizarre comment tu parles de l'impossibilité de panne, ça a beau être virtualisé, ça repose sur un serveur physique. Si le serveur physique tombe, tout ce qu'il y a dessus tombe aussi.
Tcho !
@Cascador: quand tu virtualises tu répartis sur plusieurs serveurs, même chose pour les disques, cartes, etc. Et la probabilité que tout tombe en même temps est... proche de zéro 🙂
Je suis très étonné de cet échange car je ne suis pas du tout d'accord avec toi. J'espère que je ne te gonfle pas d'ailleurs, c'est pas du tout le but.
En 10 ans de sysadmin, j'ai systématiquement vu plusieurs VM sur une machine physique. Point. Après d'un point de vue architecture tu gères les fails genre avec une architecture en étoile, tu déplaces la VM à chaud sur le serveur B si le serveur physique A montre des soucis/limites par exemple.
J'ai rarement vu (mais ça existe) du PRA, une VM éteinte ou synchronisée régulièrement qui est up puis synchronisée immédiatement après un gros fail. Mais clairement chez un hébergeur, les PRA ce sont des options payantes et j'ai jamais vu une VM doublée.
On se comprend peut-être pas ou un truc m'échappe ?
Sur yulPa : "Reposant sur notre infrastructure interne à Paris (NCP1), les serveurs de virtualisation pour vos containers sont dans un cluster VMware HA, permettant d'assurer une disponibilité et une stabilité de l'hôte". Mais c'est toujours pareil, on coupe le courant du cluster, il y a plus rien, le switch tombe en panne, il y a plus rien, etc. L'impossibilité de panne, c'est un gros mot j'ai envie de dire lol.
Tcho !