Bonjour,
Nous utilisons actuellement Plesk sur un VPS, pour de l'hébergement de site internet.
Nous souhaitons expérimenter le Public Cloud, afin d'avoir des ressources dédiés et flexible.
Nous avons donc pris un B2-7, avec un Block Storage de 100 Go, que nous avons monté.
Sur Plesk, il détecte bien deux disques durs, celui de l'instance et celui du Block Storage, mais comme deux disques séparés, donc inutile.
Est-il possible de fusionner les deux disques afin d'avoir un seul et même stockage ou alors est-il possible de dire à Plesk d'utiliser le Block Storage et non le disque de l'instance ?
Après plusieurs heures de recherche, aucune réponse, je ne dois pas comprendre un point.
Merci pour vos lumières !
Block Storage sur une instance, fusionner les disques pour Plesk
Sujets apparentés
- Monter un PFSENSE en public cloud ?
9393
08.12.2016 16:11
- Ubuntu 18.04 (IPv6 - netplan)
7502
27.04.2018 13:34
- Créer un accès ftp pour un dossier précis avec un server cloud
6614
19.04.2017 13:08
- Backup par Snapshot Public Cloud Instance
5793
02.03.2017 11:14
- Nouvelles images sur le Public Cloud
5117
13.06.2017 16:21
- Installation de OpenStack Mistral (snapshots automatiques)
3782
18.04.2019 15:08
- Kubernetes-as-a-Service chez OVH : partagez-nous vos besoins et obtenez un accès à la b
3679
21.05.2018 14:21
- [Cloud web - Model 1] Hébergement ReactJs et API Node
3536
22.09.2020 13:56
- VPN avec VRack et réseaux multiples à router
3410
16.10.2016 11:02
- Disk addionnels et IOPS
3201
13.02.2017 21:59
Bonjour,
pour info la "fusion" des deux disque reviens à faire un JBOD ou RAID0 (selon la solution utilisé), ce qui veux dire que si pour une raison X ou Y le "block storage" est inaccessible, dans le meilleur des cas vous perdez juste l'accès à ces données.
Da,ns le pire des cas, vous perdez l'accès à l'ensemble des données.
Sans compter le fait que le "block storage" va "brider" le stockage SSD de l'instance.
Du coup perso je ne vous conseil pas de chercher à fusionner.
Pour le reste il faudrait voir dans la documentation de plesk ou avec leur support.
Cordialement, janus57
Bonjour,
Merci pour votre réponse !
Dans ce cas, le public cloud n'est pas adapté pour de l'hébergement web, avec des besoins des stockages ?
Je souhaite juste avoir une machine, avec 1To de stockage, et flexible, afin de pouvoir augmenté le stockage, la ram, le CPU, .... afin de pouvoir faire évoluer la machine dans le temps.
Bonjour,
de mon point de vue c'est pas comme ça qu'il faut raisonner.
Déjà je rappel le principe du public cloud : votre machine peut "mourir" à tout moment sans impacter votre production, cela doit être considéré comme une machine "volatile".
Exemple : si le serveur hôte crash, OVH sa chercher à le redémarrer sans bouger les machines virtuel, donc que je serveur physique soir réparé en 1H ou 4H, c'est pas grave, au pire il y aura la SLA et OVH aura perdu quelques € (voir contrats).
Là de ce que j'ai compris de votre postula c'est :
- Maintenant avec le cloud je prend une machine avec le stricte minimum, puis j'augmente si besoin, osef de faire un calcul de prévision
- Il me faut un système évolutif avec 1To minimum de stockage (SSD ? HDD ?)
Perso je partirai dans le sens inverse :
- c'est quoi mon cas d'usage : 1 site avec beaucoup de données (documents/videos ?)
- Est-ce que dans 3/6/9/12 mois ma quantité de data va faire x1.5 ou x10 (vous allez vite voir qu'un public cloud le prix aussi peut faire x10 comparé a un bon vieux serveur dédié).
- Qu'est-ce que je consomme exactement comme ressource CPU/RAM/Disk et est-ce que je ne pourrais pas déporté la partie DATA ?
Le public cloud c'est bien, mais pas pour tout les usages et surtout il faut bien prendre en compte tout les petites choses cachés qui soit vont faire gonfler le prix, soit qui n'ont pas été pensé à l'origine.
Exemple dans votre cas : vous allez faire vos backup où de vos 1To de données ?
Cordialement, janus57
Je vous remercie pour votre réponse complète ! Je vais être plus précis pour mieux comprendre mon cas.
Je suis développeur web, et j'ai peu de connaissance en réseau, j'ai donc choisi la solution Plesk pour gérer la partie sécurité, réseau, etc...
Lorsque je créer un site pour un de mes clients, je lui offre la possibilité, contre rémunération, de faire office d'hébergeur web. Cela fonctionne parfaitement depuis plus de 3 ans, sous un VPS Confort.
Le problème est qu'il est complexe d'évaluer les besoins en RAM et CPU, qui d'après les monitoring, pose aucun problème pour le moment.
Le souci, est du coté des performances (qui sont partagés avec les autres utilisateurs du VPS), et la limite du stockage, de 640Go chez OVH.
Je voulais donc partir sur une machine plus puissance (en test afin de me former petit par petit), donc un serveur dédié ou un serveur Cloud.
Le serveur dédié c'est cool, mais si je souhaite augmenter la RAM, le CPU, ou le stockage pour upgrade la machine, et accueillir plus de client, c'est complexe, sans faire un changement complet de machine. Et coté maintenance, si je me trompe pas, c'est à nous de vérifier l'état des différents composants afin de demander à OVH un remplacement, contrairement au VPS où tout est virtualisé.
J'ai donc opté, suite aux conseils de OVH, au Cloud, afin de prendre une instance, que je peux upgrade à volonté, et à un Block Storage, que je peux également Upgrade, mais les prix commencent à piquer à partir de 1 To.
L'objectif est d'avoir une machine, puissante pour héberger plusieurs dizaines de sites internet à faible et moyen traffic, et avec suffisamment de stockage pour ne pas être limité, du style 1 ou 2 To, qui me permettrait, d'héberger une 100ène de site sans aucun soucis (à voir après du coté des perfs ^^).
Donc dans ce cas, le VPS est pas assez puisant mais flexible, le dédié est plus puissante (ou pas ?) mais pas flexible, et le Cloud est flexible, puissant mais pas adapté à ce style d'usage :/
Que me conseillez-vous ?
Hello,
Bon déjà premier conseil, faites votre boulot de dev, et laissez le boulot de gérer un serveur à un autre qui sait faire. Vous allez y gagner en sérénité, en sécurité et vous pourrez vous concentrer sur ce que vous savez faire.
Deuxième point, je vous recommande d'isoler vos clients.
1 client = 1 vps. Ne prenez pas les publics cloud, ils ne sont pas adaptés à votre usage.
Allez plutôt là dessus : https://www.ovhcloud.com/fr/vps/
Ils sont très bien, vraiment. Et pour chaque client, vous lui prenez son VPS.
Mieux, le client se prends son VPS, se le paie lui même et il vous met contact tech, vous pouvez tjrs lui facturer un petit + pour prendre soin du vps. Du moins de façon superficielle (via un plesk par exemple).
3° point, revenons au Public Cloud.
Ce n'est pas adapté à vos besoins. Le PCI c'est plutôt pour des instances "jetables", j'ai besoin de puissance, je spawn une instance, ça baisse je la delete. Voir sur des solutions derrière un load balancer avec plusieurs frontaux web qui ne vont pas stocker de données. Là c'est très bien. Dans votre cas c'est une mauvaise solution.
Il faut savoir que les disques additionnels ont des perfs de merde, vraiment.
En gros vous hébergez votre SGBD sur le disque principal de votre instance, et uniquement les données de vos sites sur le disque additionnel.
Mais si vous voulez rester sur un seul gros serveur il me semble qu'il n'y a pas de limite au nbr de disque additionnel que peuvent avoir des instances PCI. Donc là le mieux c'est de prendre 1 disque additionnel / client. Surtout que vous êtes limité en nombre d'IOPS / disque, donc là au moins chaque client a son lot d'IOPS pour lui.
Bon à vérifier dans les faits, @FabL tu confirmes ou non si il y a des limitations en nbr de disques additionnels sur les PCI ?
Maintenant côté prix le PCI c'est de la merde (je l'ai déjà dis que j'étais pas fan du PCI non ?).
Je prends l'exemple du serveur dédié RISE1. C'est du 1er prix chez OVH en dédié.
On est sur 65€ HT / mois. 12 threads, 32Go de RAM, 500Go de disque NVME.
Prenons la "même chose" sur du PCI. C'est la gamme C2 (pour avoir une puissance / thread proche).
Le + proche serait le C2-30 avec 8vcore et 30Go de RAM. Donc on est déjà inférieur au rise1, et le prix est le double, 125€ HT. Et disque SSD mutualisé et non pas NVMe dédié. Enorme différence de perfs.
Là dessus on ajoute un disque additionnel, allez je vais être gentil, juste 300Go en high speed (l'entrée de gamme, c'est de la merde). Encore 24€ / mois à ajouter. Donc un total de 150€ HT / mois.
A peu près 90€ d'écart par mois... Prenez un dédié, vous aurez de meilleures perfs, ce sera + stable, et avec la différence prenez un infogérant...
Et cette différence de prix s'accentue de façon exponentielle qd on monte en gamme.
Maintenant la question principale que j'ai envie de vous poser c'est l'intérêt d'héberger vos clients. L'intérêt d'héberger les sites sois même c'est d'avoir accès à la config du serveur, les logs, le paramétrage. Mais visiblement ce n'est pas votre truc vu que vous gérez ça via Plesk.
Donc pourquoi tenez vous à héberger les sites de vos clients vous mêmes ?
Pour monter en expérience ? Pour marger un peu + ? Pour proposer une offre "tout en un" au client ?
Je l'ai dis au début, votre job c'est dev, je vous conseille de rester dessus (si vous bossez seul).
Maintenant si vous ne margez pas sur l'hébergement et que vous n'y trouvez pas d'argument commercial valable laissez tomber. Vous n'y gagnerez pas grand chose, et qd il y aura un problème (et ça arrivera) vous allez vous en mordre les doigts et les clients vont vous allumer là dessus.
Si vous tenez vraiment à héberger les sites il faut déterminer le pourquoi.
Si c'est pour un accès tech + poussé va falloir bosser vos compétences là dessus, ou je le redis, bossez avec quelqu'un qui sait faire.
Si c'est pour une offre "tout en un", voyez pour de l'hébergement mutualisé en mode revendeur. ça coûtera bcp moins cher, et vous éviterez des soucis.
Ou alors un autre presta en Suisse propose un système d'affiliation, le client se prends son offre via un lien d'affiliation, vous touchez une petite marge, mais ce n'est plus votre boulot ensuite.
Si vraiment vous tenez à vous y mettre allez en parler avec un infogérant, voyez ce que ce service peut réellement apporter à votre activité et combien vous pouvez le facturer / marger dessus.
Si vous souhaitez rester seul, passez sur un VPS / client. Au moins en cas de problème vous n'aurez pas ts vos clients en rade en même temps. Et ça bah c'est pas négligeable.
Et petite note, qd je dis de rester sur ce que vous savez faire ce n'est pas une critique mais un conseil. Vous êtes probablement bcp + productif dans votre métier de dev que sur la gestion d'un serveur. Le temps que vous passez dessus vous pouvez le vendre bien + cher... Et le temps qui ne rapporte rien, prenez le pour passer du temps avec vos proches, c'est mieux...
C'est aussi ce que je préconise avec les hébergements mutualisés.
c'est la base.
- Le client peut changer de presta qd il veut, il a le contrôle de ses données et de son hébergement. Point important pour moi.
- Le presta ne doit pas avancer l'argent, en cas d'impayé ovh coupe directement.
Si on héberge le client le "risque financier" repose sur nous.
C'est aussi ce que j'explique.
Il s'agit là d'un respect mutuel.
Bonjour,
alors oui et non, on peut très bien répartir le tout sur plusieurs machines ce qui en plus permet d'avoir moins de client en panne en cas de passe grave sur le serveur.
oui, sur VPS vous vous affranchissez de la partie matérielle, mais il reste tout de même toute la partie logiciel, un plesk/cpanel & cie c'est bien joli, mais il faut quand même savoir administrer la bête (car le panel est souvent la première chose qui va tomber en cas de problème majeur) et surtout être très rigoureux sur la mise à jour du panel propriétaire (faille de sécu power), et comme dit par @Sich à un moment c'est plus un boulot de dev, mais bien un boulot de sysadmin.
oui, c'est normal de manière générale le public cloud est cher quand on commence à demander autant de ressources d'un serveur dédié, car OVH prend en compte le coût humain pour surveiller l'infrastructure.
franchement, cela va dépendre de ce que vous souhaitez faire très exactement, comme déjà répété par @Sich administrer de plus en plus de clients, sans réelles connaissances en administration système cela va mal finir quand vous allez commencer à avoir des problèmes (c'est qu'une question de temps).
Cela va également dépendre de la technologie utilisez par vos sites, car le plus simple serait effectivement une offre revendeur ou l'hébergeur s'occupe de tout (matériel/logiciel voir sauvegardes) et vous vous avez simplement a créer vos espaces client et déployer le site.
Je reprends votre exemple du VPS :
Si on part sur un "elite" à 8vCPU/16Go de RAM/640 Go de SSD + licence plesk "web host" : 99,99 €/mois, mais vous allez quand même devoir gérer les problèmes/sécurité/sauvegardes et vous allez sans doute faire tenir de 20 à 50 clients (selon le site/charge du site, etc.)
Je regarde chez le suisse mentionné par @Sich :
8vCPU/24Go de RAM (package RAM/CPU) / 640Go de SSD (uniquement de DATA, cela les BDD n'ont pas de quota) / 50 espaces d'hébergement **isolés** / PHP 8.1 - 8.0 / 7.4 - 7.3 / 5.6 / Sauvegarde des fichiers Quotidienne & géographiquement distante / support de node.js et d'autres
Prix : 184€/mois sauf que vous avez 0 administration serveur à gérer (comme par exemple réparer un serveur à minuit suite à une alerte de monitoring), c'est l'hébergeur qui endosse la responsabilité via le contrat.
Donc comme dit à plusieurs reprise par @Sich vous devez savoir ce que vous vous souhaitez faire :
1 - juste pouvoir proposer de l'hébergement à vos clients (sans prise de tête)
2 - proposer de l'hébergement à vos clients + commencer à devenir administrateur système en plus de dev
Car question con; là actuellement avec votre VPS vous faite comment vos sauvegardes ?
Demain un pirate prend le contrôle de votre VPS et efface tout, est-ce que vous êtes capable de tout remonter ?
Sous quel délai ?
Vous allez perdre combien d'heures de datas ?
Le datacenter de OVH a un problème, est-ce que vos backups sont toujours en sécurité (qui a parlé de Strasbourg ??) ou êtes en mesure d'y avoir accès rapidement ?
Spoiler : toutes ces questions un administrateur de serveur doit pouvoir y répondre.
Cordialement, janus57
Bonjour,
Merci pour ta réponse !
Dans un premier temps, je suis développeur web, mais je suis en constante demande d'apprentissage de nouveau domaine, et l'hébergement web est un domaine très complémentaire et intéressant.
Les raisons de ce choix, est dans un premier temps de proposé un package tout en un aux clients, c'est à dire, qu'ils n'ont pas à s'occuper de la partie technique, souscription, création de compte chez OVH, etc...
Le client s'inscrit via un formulaire de souscription, et un workflow rentre en jeu pour l'automatisation des paiements, des factures, des renouvellements, etc...
Le deuxième point est également le complément de revenu, qui sur 1 client n'est pas rentable, mais sur 30-40 clients, cela commence à devenir intéressant.
Je comprend que faire cela est risqué, car je deviens responsable des données de mes clients, et en cas de problème, il faut réagir rapidement. Lors de l'incendie chez OVH il y a quelques mois, le VPS était down, et les 30 sites de mes clients ce sont retrouvés HS, heureusement que j'avais prévu le coup avec des backups journalière, des entrainements pour gérer ce genre de situation, et une machine PRA prête, les sites étaient de nouveau opérationnel 6h après l'incendie, sur une nouvelle machine.
Et un gros avantage, est d'avoir, sous la main, accès à l'ensemble des sites de mes clients en quelques clics, pouvoir gérer les différentes versions de PHP, pouvoir faire des configurations plus poussé qu'avec un mutualisé.
Donc pour résumé, le mieux est de prendre un dédié, comme par exemple un Advance-1, mais le problème sera le même puisque le dédié est livré avec 2DD, donc toujours deux partitions (ou alors c'est du RAID0 ?). Et pour avoir à la fois du SSD ou MVME, et du stockage, il faut aligner un peu plus ! Je suppose que du HDD pour des sites internet n'est pas top en terme de vitesse.
Bonjour !
Malgré le fait que je m'occupe de l'hébergement de mes clients, ils ont tous un accès client pour avoir accès à la partie facturation mais également la partie du site internet (FTP, BDD, MAIL, Fichiers, etc...).
Le client est donc libre de changer de prestataire, sans même devoir faire appel à mes services.
Si le client ne paye pas, l'avantage d'un dédié est qu'il est possible de suspendre son hébergement, sans devoir payer cher, tout en attendant un retour du client.
Exactement, on peux mettre en place plusieurs dédiés et split les clients afin de minimiser les risques de pannes et repartir les charges, mais quels dédié serait adapté à un usage web.
Actuellement, une sauvegarde est effectué chaque nuit, en local, chez AWS et chez Google, ce qui permet d'avoir un backup complet de Plesk. Lors du dernier gros problème, qui était l'incendie, qui à down à 100% le VPS, le temps de remise en route de l'ensemble du serveur, était d'environ 6h. Le temps de mettre en place le nouveau serveur, de remettre en place la sauvegarde et de modifier les DNS de chaque domaine pour pointer vers le nouveau serveur.
Je n'ai pas de grosse compétence en réseau, même si je suis en progression quotidienne, mais pour contrer cela, je mets beaucoup de temps et budget dans la partie sécurité et sauvegarde.
Mais oui, un infogéré serait une solution pour ne plus avoir de problème et de contrainte, même si l'option de simplicité n'est pas forcement le plus excitant dans le métier :)
Avant de me lancer sur un VPS, j'était pendant 1 an sur un VPS PLESK infogeré par OVH, j'ai pû donc apprendre à utiliser au mieux ce logiciel, et à apprendre les erreurs "basiques".
Bonjour,
comme dit en hait, cela va dépendre de votre cas d'usage.
Il faut voir ce qu'un client vous "coute" en terme de CPU/RAM/Disk et faire une estimation sur 10/50/100/200 clients.
Car vous parlez de 1To de stockage, mais si c'est juste la partie site web, cela fait un poil beaucoup selon le nombre de client (ou alors c'est déjà une estimation qui inclus web/data site/sgbd/mails etc.).
Déjà perso je serais partie sur un serveur physique en tant qu'hyperviseur, et derrière 1VM = 1 client, le tout derrière une VM "firewall" (comme ça aucun client n'a un accès directe au net et il est possible de contrôler les flux), parce que j'ai horreur des solution propriétaire à la pelsk & cie.
Mais dans votre cas si cela vous conviens alors là j'aurais eu tendances à vouloir essayer ce qui existe sur le marché, à savoir le mix Cloudlinux OS + plesk, mais ça fait déjà 496€/an (ce sont les plus haut niveau de licences) de licences, sans compter le coût du serveur.
Donc si je fait l'exercice avec un serveur avec pas mal de stockage :
Licences : 496€/an => 41.33€ HT/mois
Serveur Rise-1 [Intel Xeon-E 2136 - 6c/12t - 3.3GHz/4.5GHz] / 64Go de RAM / NVMe 1.92TB Datacenter Class : 122,99 € HT /mois
==> 165€ HT/mois (arrondi).
Et cela n'inclus pas le coût des backups, et si pas de gros site consommateur, avec de l'over-provisionning (genre 2 clients pour 1vCPU et 2Go de RAM), on peut minimum monter à 24clients sur 1 serveur.
Pire si on on se dit qu'on fait un PCA, on fait x2 car en faite on prend 2 serveur sur 2 sites physiques différents (mais si c'est bien géré c'est possible de tout relancer en quelques heures avec quelques heures de perte de data).
Pour finir, ces simulations n'inclus pas les coût humain de maintenance/surveillance.
Cordialement, janus57
Vous avez l'air décidé...
Restez en aux VPS, ne passez pas sur du public cloud.
Ce n'est pas le bon produit pour vous.
Note : mes dédiés sont biens + stables et ont moins de downtime que les quelques PCI qu'il me reste... Certes il faut gérer la partie hardware, mais la seule que vous avez vraiment à gérer ce sont les disques. Et ça fait des années que je n'ai pas remonté un raid (merci les disques ssd/nvme).
Je reste sur ma proposition d'isoler vos clients / vps. C'est + sûr, ça vous permet de mieux gérer la montée en activité et ça évite que tout tombe en même temps.
Et les VPS peuvent se commander via l'API OVH pour être intégré à vos outils automatiquement.
Bonjour à tous,
@Sich, effectivement, il y aura des limitations en fonction de l'offre PCI sélectionnée. Par exemple pour le block storage, il est conseillé de ne pas dépasser les 4To par volume.
Les infos sont disponibles sur les pages ci-dessous :
- https://www.ovhcloud.com/fr/public-cloud/object-storage/
- https://www.ovhcloud.com/fr/public-cloud/cloud-archive/
- https://www.ovhcloud.com/fr/public-cloud/instance-backup/
- https://www.ovhcloud.com/fr/public-cloud/volume-snapshot/
^FabL
c'était pas ma question ;)
Je parlais du nbr de disque additionnel que l'on peut ajouter / instance en PCI.
Pas de la taille / disque.
Bonjour,
Effectivement, je parle de 1 To mais cela est sur-estimer. Pour le moment, je tourne 45 sites internet, consomme en moyenne 6Go de RAM, et 80GO de stockage (Data, BDD, mails, etc,... ) et le CPU est rarement utilisé à plus de 15% (VPS DE 6 vCores).
L'objectif, est, par exemple, de proposer 20Go de stockage à chaque client, ce qui est déjà assez large pour un bon site e-commerce avec des mails. Donc si je bride la machine à 100 Clients, il faudrait, dans ce cas, environ 1 To, sachant que la plus part des clients utilise moins de 2 Go, donc en soit le 1 To est inutile, c'est plus un argument commercial. C'est un peu comme du surbooking.
Donc complexe de faire une estimation de ce qu'à besoin d'un site internet, en ressource réel, mais si je prend le site internet le plus consommateur du serveur, il consomme 1,2Go de RAM et environ 30% des 6vCores, donc 2vCores, sur des pics dans la journée. Les autres sites, sont des petits sites internet avec moins de 100 visiteurs par jours.
Si je comprend bien, un dédié avec un CPU de 6c/12t, c'est l'équivalent d'un VPS de 12vCores ? Les threads sont les vCores ? Dans le nombre de coeur (6c) sert à quoi sur un serveur web si c'est le vCores (12t) qui compte ?
Pour ce qui est du second serveur, celui-ci ne doit pas être forcement prêt à l'emploi, mais mon workflow et mes backups me permettent, en quelques heures, dans l'urgence, de louer un nouveau VPS et de tout remettre en route, le temps de régler le problème sur le serveur principal.
Je te remercie pour tes réponses !
Je comprends l'idée, mais si un datacenter tombe, comme par exemple un incendie, si j'ai 100 VPS, les 100 VPS tombes ensemble, donc pour tout remettre en route, il faut remettre en route 100 VPS, avec 100 backups ?
Comparé à un serveur, avec tout les clients, et 1 backups, où lors d'un problème, il y a juste un serveur à remettre en route ?
Après je comprend l'idée d'isolé les clients, pour limiter les risques, mais d'un point de vue économique, cela n'est plus aussi rentable.
Pour ce qui est du choix de la technologie, j'abandonne donc le Cloud, qui n'est pas adapté et trop cher, comparé à un dédié ou un VPS.
Dans tous les cas, VPS ou dédié, dès que le nombre de client sera plus important, je mettrai en place plusieurs dédié ou VPS, pour splitter les clients, et réduire le nombre de client en panne en cas de serveur down.
Vous pouvez héberger vos VPS sur plusieurs DCs.
Mais comme je l'ai dit avant, il faut voir où vous faites votre marge et quel est votre "métier".
Si votre marge est faite sur des sites, vendez des sites...
Vous parlez de plusieurs petits sites qui ne doivent pas consommer grd chose, la plupart d'entre eux fonctionnent probablement très bien sur un hébergement mutualisé à quelques € / an...
Tite question, comment vous "isolez" vos clients ? Je ne connais pas plesk, le peu que j'ai eu à y mettre les doigts j'ai eu des boutons. Tout tourne sur le même UID ? Avec les mêmes droits au niveau du filesystem ? Chaque client est sur un compte user différent, un pool php différent ? C'est de la curiosité en fait, pour savoir comment tourne le panel.
Je comprends l'intérêt de la mutualisation pour vous, mais perso j'ai arrêté de bosser comme ça, je ne veux pas qu'un client bouffe les ressources d'un autre, ou qu'un site mal maintenu aille pourrir les autres sites (ne serait ce que par surconsommation de ressources).
Ensuite pour parler du DC qui crame... Bon ça fait + de 15 ans que je suis dans le métier, ce n'est arrivé qu'une fois et j'espère bien ne pas le revoir de si tôt...
Et oui j'ai remonté 1 serveur / client (sauf quelques petits que j'ai remonté ensemble).
Mais ayant tous les backups et quelques scripts d'install ça s'est plutôt bien fait...
J'ai du remonter autour de 5000 sites en 2 jours...
Je n'avais pas prévu dans mon PRA une telle catastrophe...
L'idée de mettre un client par VPS, est intéressant pour les sites internet qui commence à devenir lourd en terme de traffic. C'est l'idée que j'utilise, dès qu'un site internet commence à devenir important, je bascule mon client sur un VPS, dédié pour son site.
Mais pour les petits clients, avec des sites à 10-50 visiteurs par jours, le VPS n'est pas du tout rentable. Donc ce que je propose est un hébergement mutualisé, sans réel ressource garantie. Par contre, Plesk propose la possibilité de limité l'usage du CPU, de la RAM ou des E/S, afin que les sites gourmand, ne viennent pas manger sur ressource des petits sites.
Mon activité principale est la création de site internet, mais pour chaque site créer, c'est un revenu récurrent supplémentaire, et par rapport au coût d'un VPS (20€ chez OVH), 5 clients finances le coût du VPS et des backups, et les 50 autres clients, c'est du rentable.
Je parle de rentable, car tout se passe bien, mais dans le prix est compté la maintenance, les potentiels problèmes, etc... Quand l'incendie est arrivé, j'ai passé +6h de maintenance, pour remettre en place tous les sites internet, en total transparence pour le client et sans demander de paiement supplémentaire.
Pour Plesk, je ne sais pas comment il fonctionne d'un point de vue technique, mais chaque client à un compte user différent, et ne peux accéder que à ces fichiers ou ces BDD, le tout, sur la même partition. Plesk, comme cPanel, gère tout la partie technique (après est-ce qu'il à des failles, je ne sais pas ! Mais j'espère pas au vue de la taille de l'entreprise).
**Donc pour résumé, j'ai deux types de clients:**
- Ceux qui veulent du stable, de la performance, avec des sites à fort traffic --> VPS dédié (et à l'avenir, un dédié avec plusieurs VM, lorsque mes compétences me permettront de gérer cela à 100%).
- Ceux qui veulent que sa fonctionne, avec quelques visiteurs par jours (La boulangerie du coin) --> Mutualisé avec les autres petits clients sous Plesk.
Mais, un VPS de 6vCores et 18 Go de Ram, pour des petits sites, c'est déjà du bon mutualisé, mais pas assez à mes yeux, d'où l'idée de se professionnaliser plus dans ce domaine, et de vouloir passer à la vitesse supérieur, avec un dédié, afin de proposer plus de ressource à chaque client.
L'idée n'est pas de mettre 500 clients sur un seul dédié ! Mais plutôt, 100 clients par dédié par exemple, en changeant par exemple les DCs pour chaque dédié.
Bonjour,
oui et non, oui sur le nombre mais non sur la fréquence car selon les VPS la fréquence peut être plus basse que le dédié, donc à cœur équivalent moins performant.
pas trop compris là.
si on parle d'un PCA, normalement si (un PCA c'est pour continuer l'activité le plus rapidement possible).
ça c'est un PRA, et c'est très bien !
Note : c'est pas une critique, juste une explication
Note2 : vous faite mieux que certaines agences qui ont tout perdu à Strasbourg par manque de backup…
la taille de l'entreprise ne veux rien dire, cela reste des humains qui code.
Exemple passé : https://www.cve.org/CVERecord?id=CVE-2020-11583 & https://www.cve.org/CVERecord?id=CVE-2021-35976
Cordialement, janus57
Quel est la différente entre les Cores, les vCores et les thread ? Sur un dédié, par exemple, on parle de 6c/12t, alors que sur des VPS on parle de 1vCore par exemple.
D'accord, je vois la différence. Un PCA peut-être une bonne solution pour une continuité d'activité, en cas de problème.
Oui, chaque système n'est pas infaillible, d'où l'objectif de se former pour mieux comprendre comment fonctionne un serveur web.
Merci pour les conseils !
Bonjour,
1vcore = 1 cour virtuel, donc va dépendre de la définition que l'hébergeur lui donne, mais bien souvent cela va correspondre à 1thread.
Dans la pratique on peut lui donner la valeur qu'on veux, par exemple je peux créer une VM avec 2vCPU, ce qui va "consommer" 2threads sauf que je peut également limiter l'utilisation du vCPU à 50% de la puissance d'origine.
Je suis déjà tomber chez un hébergeur ou 1vcpu était un vCPU virtuel était à 500MHz (oui vous avez bien lu 500MHz, même mon raspberry pi était plus rapide…).
Cordialement, janus57
D'accord, donc si on veux garantir 1vCores pour chaque client, sur un dédié à 6c/12t, on ne peux mettre que 12 sites internet. Ou alors, il y a 12 threads par Cores, donc 6x12 vCores ?
Dans ce cas, à quoi sert le nombre de Cores, si c'est les threads qui sont important ?
Merci pour tes explications, tout deviens plus clair, également sur certaines pratique commercial, comme OVH qui garantie 1vCores sur le mutualisé Performance, sans parler de la fréquence.
Sur un adv2 le thread peut monter à 4,6Ghz là où sur du PCI on va + souvent être sur du 2,4Ghz max...
De + sur un dédié toute la puissance du serveur vous est dédié, là où sur un PCI il y a forcément une mutualisation des ressources (bande passante cpu, ram, disque, iops, etc).
Le rapport puissance / prix entre un dédié et une PCI est sans aucune comparaison....
Par contre oui faut gérer le hardware, mais ça devient rare, je n'ai pas eu de panne depuis des années perso... Et même il y a 10/15 ans cela restait rare, en moyenne max 1x / an, et concernait essentiellement les disques...
Et autre point le dédié n'est pas évolutif. Mais ça osef, vu la différence de prix on peut tjrs monter en gamme qd le besoin se fait sentir, ou partir sur un 2° dédié...
Et je ne parle même pas des adv5/6 où là on a 48 threads.... Pour un prix pas si choquant si on le compare à du PCI...
Je comprend mieux.
Mais comme expliqué ci-dessus, si on veux garantir 1vCores par site internet, c'est à dire 1 thread, sur un adv4 à 32 threads, on ne peux donc mettre que 32 sites internet ?
Donc c'est les threads qui sont importants et non le nombre de Cores, est-ce utile d'avoir 16 Cores sur un serveur web ?
Bonjour,
1 cœur physique == 2threads (si le cpu à la techno)
car certains processeur n'ont pas cette technologie d'hyperthreading, donc faire attention car parfois 6 cores == 6threads
et encore là on parle des serveur que loue OVH, j'ai un client il a un cluster composé de 3 serveurs physique, chaque serveur physique à 2 CPU AMD à 64c/128t & 1To de RAM (de mémoire) [384c/768t & 3To de RAM].
oui mais les offres à garantie sont souvent cher (exemple le PCI -> garantie, le mutu -> non).
Si vous comptiez vendre une offre à ressources garantie à 10€/mois, vous pouvez déjà oublier cette idée, car en plus il faut en générale prévoir 1coeur de réserve pour l'OS (quand on fait du garantie).
Cordialement, janus57
Top ! Merci pour toutes vos lumières, tout deviens plus facile à comprendre ;)
Et pour retourner sur le sujet principal du topic, si on part sur un dédié, ADV4 par exemple, avec 2x960Go SSD NVme en RAID, cela veux dire qu'on peux les mettre en RAID0 pour avoir presque 2To, ou en RAID1 pour la sécurité pour que tout soit dupliqué ? Mais sur Linux (donc plesk), en RAID0, va t'il voir un disque de 2To, ou deux disques de 960Go, et donc, un des deux disques ne sera pas utilisé, car Plesk ne gère que un disque.
Bonjour,
déjà oublier le RAID0, RAID0 == vos data ne sont pas importante/volatile.
Cordialement, janus57
Un RAID0, pour avoir une grande capacité de stockage, si il y a des backups, les données sont en "sécurité" ?
Ou alors en RAID1, pour dupliqué les données, mais si un disque tombe, au yeux de Linux (donc Plesk), comment cela va être vu ? Est-ce que Plesk va automatiquement basculer sur le disque 2, ou cela est plus complexe que ça ?
Bonjour,
parti de ce principe => oui
Mais au moindre pet de travers au niveau du stockage -> RAID KO => utilisation de la sauvegardes (et perte des données qui vont avec).
Je rappel que le principe du RAID0 est de couper la données en 2 et de mettre 50% sur la disque A et 50 sur le disque B, le disque A et/ou B ne sont plus visible (même 1secondes) => plus de données car désynchronisation.
Même sur du SSD, NVMe et class entreprise je ne m'amuserais pas à jouer avec les données des clients (question de principe/éthique)
y a pas de bascule, les données sont lu/écrit sur les 2 en parallèle, si un disque tombe, normalement le serveur continue à fonctionner jusqu’au remplacement du disque KO (qui peut être fait à chaud sans éteindre le serveur).
Cordialement, janus57
Je comprend mieux, c'est très intéressant d'en savoir plus. Donc c'est minimum un RAID1.
Les données sont écrites et lue sur les deux disques en parallèles, donc Linux ne voit qu'un disque. En cas de défaillance d'un disque, le disque 2 prend le relai, jusqu'au remplacement du disque 1, et ensuite, le disque 2 ré-écrit à nouveau sur le nouveau disque 1.
Même si cela est extrêmement rare, en cas de défaillance de disque, c'est OVH qui prend un charge le changement ?
Bonjour,
OVH prend en charge tout problème matériel pendant la durée de location.
J'ai déjà eu une carte mère de changé suite à un défaut.
Cordialement, janus57
D'accord.
Et un ADV4, avec 2 SSD de 960Go, et 2 HDD de 6TB ou alors 4 SSD de 960Go, on peux imaginer un RAID10, pour avoir 2 To de stockage, avec un RAID0, et la sécurité avec le RAID1 ?
Et est-il possible d'upgrade les disques sur un dédié ?
Bonjour,
non
non il faut 4 disque de taille identique pour un RAID10
Cordialement, janus57
D'accord ! Merci pour toutes les informations, c'était très instructif.
Avant de partir du un dédié, je vais approfondir mes compétences dans le domaine.
Excellente journée à vous !
Pour info OVH va peut être changer votre disque, mais ne va pas reconstruire le raid...
or changer le disque sans reconstruire le raid ça ne sert à rien...
Autre point, ne prenez pas de sata, c'est trop lent, sauf besoin d'énorme espace de stockage (backup pour ma part).
Hello @Sich,
Après avoir consulté la team concernée, voici l'information.
Il est possible d'ajouter jusqu'à 25 disques par instance. :)
https://docs.ovh.com/fr/public-cloud/public-cloud-faq/#combien-de-volumes-additionnels-puis-je-attacher-a-chaque-instance
À votre dispo,
^FabL
Merci !
Les écritures sont faites sur les deux disques. Les lectures sont contrebalancées entre les deux disques ce qui augmente la performance.
La panne d'un disque est tellement invisible qu'on ne s'en rend même pas nécessairement compte s'il n'y a pas un monitoring.
Jusqu'au reboot parfois, voir qd le 2° rend l'âme aussi.....