J'étudie la possibilité d'héberger mes propres VM à la place de la gamme VPS (SSD ou Cloud).
Mon idée est de passer par des serveurs SP-32 et comme stockage centralisé d'utiliser un NAS fournit par OVH.
Mes tests donnent de bons résultats mais je suis tombé là dessus : http://docs.ovh.ca/fr/products-nas-ha.html
Et notamment ce passage :
[quote]Il y a deux choses importantes à retenir de tout ceci:
ZFS garde une copie des donné que vous supprimez ou modifiez pour permettre les rollbacks
ZFS garde aussi la trace des transactions IO
Note
Ceci veux dire qu’un nombre important des transactions
IO peut éventuellement saturer votre espace disque. Donc mettre une
image de Machine Virtuelle active sur un NAS n’est peut-être pas la
meilleur idée (dépendament de vos besoins) car elle causera beaucoup de
transactions IO.[/quote]
Si j'ai bien compris les IO sur le NAS vont remplir l'espace de stockage ?
C'est toujours d'actualité ? Possibilité de désactiver ça ?
Stockage et sauvegarde-old - NAS comme stockage de machine virtuelle
Related questions
- Augmenter la taille maximum de chargement de fichiers
14136
14.11.2016 14:06
- Augmenter la taille maximum de chargement de fichiers pour prestashop
11232
29.04.2018 20:53
- Déplacement de fichier volumineux
4925
07.04.2017 11:56
- S3 api pour OVH Object Storage ?
4598
08.05.2017 16:46
- Accès Cloud Disk Array via l'interface vRack
3858
30.07.2019 11:04
- Quelle solution de sauvegarde pour une TPE ?
3390
28.01.2019 20:26
- Suhosin.post.max_vars = 5000 suhosin.request.max_vars = 5000
3150
31.01.2020 16:54
- Quelle solution de sauvegarde est la plus adaptée ?
3112
09.12.2016 00:23
- [Cloud Disk Array] Parfois de mauvaise perf
3070
07.11.2017 16:37
Bonjour,
Effectivement, nos NAS HA ne sont pas tellement prévus pour cela.
Au delà de cette problématique, le réseau n'est pas garantie et donc niveau performances je ne recommande pas cette solution.
Je te conseille plutôt un serveur dédié de la gamme Stockage avec un serveur compatible vrack (Hosting ou Infra qui sont dans le même ordre de prix que les SP). Tu auras de cette manière une solution beaucoup plus efficace.
Cordialement, Alexandre R.
Ou du Ceph https://www.ovh.com/fr/cloud/cloud-disk-array/ si tu ne veux pas gérer ton stockage.
Etienne
Vi enfin le ceph si c'est pour se retrouver avec les mêmes problèmes que la gamme Cloud c'est pas la peine...
Et pour les serveurs dédiés le problème c'est qu'il en faut 2 si on veux faire de la HA... Du coup le prix de l'infra de base augmente très vite.
Sans parler du problème de perfs sur du sata en raid logiciel...
Pour que ce soit à la hauteur il faudrait du SAS voir du SSD, mais là le prix augmente vite et la capacité ne suit pas (en ssd).
Bref merci du retour d'info, je vais regarder tout ça de plus près.
J'utilise NAS HA pour le stockage de VM. Je n'avais jamais vu cette contrainte de iops (et je ne l'ai jamais subit). Les performances de NAS HA sont très supérieures à celles de l'offre Ceph (dans cette configuration, c'est à dire, comme un datastore proxmox).
Par contre Alexandre, je ne comprends pas ce que tu veux dire par "le réseau n'est pas garantie" ? NAS ne passe (pour l'instant) pas par vrack, et il me semble la sla est supérieure sur le lien public que sur le vrack. On travaille donc sur la possibilité d'avoir un NAS HA "entier" qui pourrait être configuré en mode sync pour éviter l'incident qu'on a eu lors d'une bascule de tête un peu trop longue.
L'intérêt de NAS HA est justement de ne pas avoir à monter un cluster de stockage sur des FS puisque l'admin du stockage est effectué par OVH en offrant un service à la fois redondé et snapshoté.
Je précise qu'on utilise ça en prod depuis une dizaine de mois.
Je comprends très bien ce que tu décris et il se peut que cela puisse fonctionner.
Néanmoins, on ne peut pas en garantir le bon fonctionnement, notamment pour ce type d'utilisation.
Ce que je voulais dire par là c'était plutôt que, le réseau n'étant pas garantie (débit), du coup il ne s'agissait pas de la meilleure solution.
La SLA est effectivement meilleure mais disons que ça passe par Internet malgré tout, et que donc on n'est pas à l’abri d'une déconvenue.
Après évidemment cela permet de faire abstraction de la couche gestion de FS... :wink:
Cordialement, Alexandre R.
Merci pour ton retour.
De mon côté durant mes très petits tests je n'ai remarqué aucun problème que ce soit au niveau perfs / stabilité. Mais c'est vrai qu'il n'y a pas de garantie.
Mais vu la garantie des cloud je préfère un service sans garantie et qui fonctionne qu'un service avec garantie qui plante....
Et comme je l'ai dis, pour faire du HA il faut 2 serveurs, et pour de bonnes perfs il faut du SAS... Ce qui fait exploser le cout du stockage.... Valable si on a une dizaine de serveur rempli de VM... Mais ce n'est pas mon cas.
Bonjour,
Je me permets juste d'intervenir de nouveau afin de préciser une chose :
Les disques sont dédiés avec un cache SSD, cela ne pose donc techniquement pas de problème pour du stockage dynamique.
Pour ce qui est de la saturation des I/O, il s'agissait d'une erreur cela a donc été corrigé.
Cordialement, Alexandre R.
Merci d'avoir pris le temps de revenir sur ce sujet :)
Je suis en phase de déploiement de mon côté, uniquement 2 VM pour le moment.
Au final c'est 3 SP-32 + 1 nas pour faire le boulot.
Il faudra surement basculer sur des SP-64 par la suite, mais vais déjà "remplir" ces 3 serveurs !
Je reprends ce sujet car j'ai un soucis. J'ai posé la question au support mais bon, faut pas espérer grand chose quand on ouvre un ticket le vendredi après midi.
J'ai mes 3 serveurs SP-32 dans le même subnet (149.202.221.0/24). Les serveurs sont sous proxmox 4. Ils sont connectés à un NAS.
Je n'ai aucun soucis avec les hosts, mais ce sont les guests qui me posent problèmes.
En effet au bout de 10/15min les accès réseaux commencent à devenir très problématiques. Pertes de paquets, débits en chute libres, etc.
Cela concerne aussi bien les VM avec stockage local ou sur le NAS.
Mais le plus étonnant, étant que les accès depuis le même subnet fonctionnent parfaitement bien !
Si j'essaie d'accéder à une VM sur l'host 1 depuis l'host 3 je n'ai aucun soucis. Pas de perte de paquets, pas de baisse de débit.
Mais du moment que je me connecte depuis un autre subnet ça rame.... Le pire étant que je si reboot ma VM ça remarche normalement pendant 10/15min puis ça retombe....
Je n'ai pas la moindre idée d'où peux provenir ce problème. La seule idée qui me vient c'est quelque chose par rapport au routeur puisque les connexion au sein du subnet fonctionnent normalement.
La seule piste qui me reste serait d'ajouter un autre serveur dans le cluster, qui je l'espère, sera dans un autre subnet... Et voir si le problème persiste....
Quelqu'un a déjà été confronté à ce genre de problème ? Ou quelqu'un a un début d'idée pour essayer de comprendre ce qui se passe ?
La moindre petite piste est bonne à prendre car là je sèche.
[EDIT]
Bon ben un serveur de plus dans un autre subnet rencontre le même problème apparemment...
[/EDIT]
[EDIT2]
Bon, je me suis rendu compte dans mes tests que le problème se pose uniquement en download et non pas en upload.
Chose intéressante le problème se pose également sur le serveur host si on lui attribue une IP FO.
Pour valider que cela n'a rien à voir avec la config de proxmox j'ai installé une debian 8 sur laquelle j'ai uniquement configuré une IP FO. Résultat, même problème au bout de quelques minutes.
A noter que ce problème ne se pose pas avec un autre serveur sur RBX. Mais ceux que je test à SBG ont ce problème.
La seule solution que je vois c'est une config au niveau des routeurs sur SBG pour limiter la bande passante descendante des IP FO (c'est à dire tout le trafic qui va vers l'IP FO (download depuis le serveur, upload depuis un autre).
A priori vu que ce problème ne se pose pas quand on est sur le même subnet, qu'il se pose uniquement sur les IP FO, et uniquement dans un sens semble démontrer qu'il y'a une config quelque part sur les routeurs à SBG.......
Quelqu'un de chez OVH pour explorer cette piste ?
[/EDIT2]
Petit UP en espérant que quelqu'un de l'équipe OVH passe par là.
Ticket 7360333686 - Compte client sy4612.