captainadmin
18/01/2016, 16h05
Hello,
Je vais essayer de répondre à tes questions, mais pour ce genre de projet le service client OVH est pas mal.
1) VeamBackup a vraiment l'air intéressant car facile à utiliser et s'intégre bien avec la solution d'OVH.
Pour le coup, je ne sais pas comment cela se déploie car j'utilise une script perl qui fait des snapshots de mes vm et les envoie sur un datastore spécifique.
Ca fonctionne bien et ca évite de payer pour remettre une structure supplémentaire en place et ca marche plutot bien.
2) OVH propose bien des MSS, avec la formule microsoft azure tu as le droit à toutes les licences windows gratuites, enfin c'est ce qui est indiqué.
Apres on est dans un cas spécifique ou tu achètes une plateforme et tu déploies ce que tu veux dessus.
C'est la que le service commercial entre en jeu et tu pourras prévoir quelques licence meme sur des esx je pense
3) Le principe de la solution dedicated cloud c'est que quand un host physique est perdu, un autre (qui n'était pas affiché dans ton interface) prend le relai.
La redondance matériel fonctionne bien, pour avoir perdu 2 ou 3 fois un host, je n'ai pas constaté de coupure du service.
Tu n'auras donc pas besoin d'une seconde licence ni de prévoir de bascule de service.
Par contre ca ne t'empeche pas d'avoir 2 licences pour prévoir des mises à jour de tes serveurs ou que la partie dump de base se fasse sans impacter ton service.
Sachant que de temps à autre un windows aime bien les reboot, ce n'est pas négligeable de ce point de vu.
4) Pour les datastores, c'est plutôt ton organisation qui va primer
Il faut savoir la place que prend chacun de tes clients et la volumétrie ecriture/lecture pour l'IO généré.
Apres ca fonctionne comme de la virtualisation classique, tu as ton espace de stockage ou tu génères ton disque et c'est une mutualisation des ressources.
Ton disque ne pouvant dépasser la taille désigner, et en se disant que le client vont rarement à 80% de la consommation de l'espace disque, il faut calculer combien de client tu peux déposer par disque.
Ensuite il faut pas oublier une histoire d'IO, entre 10 et 15 vm par datastore c'est bien, ensuite au delà ca devient compliqué, à une 20aine tu vas commencer à voir nettement les performances décliner.
Mais si tu fais du volume plus que du nombre de requête ca ne devrait pas poser de problème.
5) Quand tu prends un datastore, du ajoute une ressource à ton environnement, tu n'as pas le choix de ce qui est mis en place. Il me semble que c'est du raid 10 mais je peux me tromper.
6) Je n'utilise que du SSD pour mes serveurs, c'est vrai que ca l'air intéressant le SSD-Accelerated Storage.
Pour une base de données qui plus est commune à plein de client, je garderai le SSD en place mais ce n'est qu'un point de vu.
7) Tu as un acces restreint en admin aux serveurs physiques, personnellement je fais du monitoring via shinken et ca fonctionne très bien. Avec quelques scripts tu avoir la liste des vm up down, la consommation par host ou sur le cluster entier voir par datacenter si ton infra est vraiment grosse, tu peux avoir une supervision et des remontés d'alerte assez nombreuses et qui correspond à pas mal de besoin.
Du moins j'ai réussi à combler tous mes besoins avec la communauté.
8) La solution est tres flexible, tu peux commander dans l'interface de ton esx plus de ressources serveurs ou plus de datastore, tu paie ce que tu consommes avec la possibilité de payer à l'heure.
Les migrations entre hosts peut se faire à chaud sauf en cas d'incident sur l'un de tes serveurs. Du coup basculer d'une solution à une autre ou avoir différentes gammes de serveurs dans l'infra marche bien, tu commandes les serveurs supplémentaires, tu lances la migration et tu résilies ceux dont tu n'as plus besoin.
La migration est aussi simple pour les datastores.
Pour résumer, ca fonctionne plutot bien, avec une tolérance de panne importante.
Je n'ai vécu que 2 incidents, la coupure réseau qui a impacté tout OVH il y a quelque mois, et suite à un probleme avec un des disque local de mes hosts, je n'arrivais plus à migrer mes vm. Et j'ai du reboot mes vm, donc impact relativement faible car préparé.
J'ai l'impression que les fichiers de configuration de toutes les vm est sur les disques SSD en local des hosts, et lorsqu'un host tombe, un autre peut facilement et rapidement prendre le relais.
D'ailleurs, mais je ne doute pas que c'est une évidence, il ne faut mettre aucune vm sur le disque local des serveurs, car tu perdrais le failover et la haute dispo sur ces vm.
J'espère avoir répondu a vos questions
Et si jamais je peux aider ou pour mettre l'infrastructure en place je suis disponible.
Bon courage
http://www.captainadmin.com
Je vais essayer de répondre à tes questions, mais pour ce genre de projet le service client OVH est pas mal.
1) VeamBackup a vraiment l'air intéressant car facile à utiliser et s'intégre bien avec la solution d'OVH.
Pour le coup, je ne sais pas comment cela se déploie car j'utilise une script perl qui fait des snapshots de mes vm et les envoie sur un datastore spécifique.
Ca fonctionne bien et ca évite de payer pour remettre une structure supplémentaire en place et ca marche plutot bien.
2) OVH propose bien des MSS, avec la formule microsoft azure tu as le droit à toutes les licences windows gratuites, enfin c'est ce qui est indiqué.
Apres on est dans un cas spécifique ou tu achètes une plateforme et tu déploies ce que tu veux dessus.
C'est la que le service commercial entre en jeu et tu pourras prévoir quelques licence meme sur des esx je pense
3) Le principe de la solution dedicated cloud c'est que quand un host physique est perdu, un autre (qui n'était pas affiché dans ton interface) prend le relai.
La redondance matériel fonctionne bien, pour avoir perdu 2 ou 3 fois un host, je n'ai pas constaté de coupure du service.
Tu n'auras donc pas besoin d'une seconde licence ni de prévoir de bascule de service.
Par contre ca ne t'empeche pas d'avoir 2 licences pour prévoir des mises à jour de tes serveurs ou que la partie dump de base se fasse sans impacter ton service.
Sachant que de temps à autre un windows aime bien les reboot, ce n'est pas négligeable de ce point de vu.
4) Pour les datastores, c'est plutôt ton organisation qui va primer
Il faut savoir la place que prend chacun de tes clients et la volumétrie ecriture/lecture pour l'IO généré.
Apres ca fonctionne comme de la virtualisation classique, tu as ton espace de stockage ou tu génères ton disque et c'est une mutualisation des ressources.
Ton disque ne pouvant dépasser la taille désigner, et en se disant que le client vont rarement à 80% de la consommation de l'espace disque, il faut calculer combien de client tu peux déposer par disque.
Ensuite il faut pas oublier une histoire d'IO, entre 10 et 15 vm par datastore c'est bien, ensuite au delà ca devient compliqué, à une 20aine tu vas commencer à voir nettement les performances décliner.
Mais si tu fais du volume plus que du nombre de requête ca ne devrait pas poser de problème.
5) Quand tu prends un datastore, du ajoute une ressource à ton environnement, tu n'as pas le choix de ce qui est mis en place. Il me semble que c'est du raid 10 mais je peux me tromper.
6) Je n'utilise que du SSD pour mes serveurs, c'est vrai que ca l'air intéressant le SSD-Accelerated Storage.
Pour une base de données qui plus est commune à plein de client, je garderai le SSD en place mais ce n'est qu'un point de vu.
7) Tu as un acces restreint en admin aux serveurs physiques, personnellement je fais du monitoring via shinken et ca fonctionne très bien. Avec quelques scripts tu avoir la liste des vm up down, la consommation par host ou sur le cluster entier voir par datacenter si ton infra est vraiment grosse, tu peux avoir une supervision et des remontés d'alerte assez nombreuses et qui correspond à pas mal de besoin.
Du moins j'ai réussi à combler tous mes besoins avec la communauté.
8) La solution est tres flexible, tu peux commander dans l'interface de ton esx plus de ressources serveurs ou plus de datastore, tu paie ce que tu consommes avec la possibilité de payer à l'heure.
Les migrations entre hosts peut se faire à chaud sauf en cas d'incident sur l'un de tes serveurs. Du coup basculer d'une solution à une autre ou avoir différentes gammes de serveurs dans l'infra marche bien, tu commandes les serveurs supplémentaires, tu lances la migration et tu résilies ceux dont tu n'as plus besoin.
La migration est aussi simple pour les datastores.
Pour résumer, ca fonctionne plutot bien, avec une tolérance de panne importante.
Je n'ai vécu que 2 incidents, la coupure réseau qui a impacté tout OVH il y a quelque mois, et suite à un probleme avec un des disque local de mes hosts, je n'arrivais plus à migrer mes vm. Et j'ai du reboot mes vm, donc impact relativement faible car préparé.
J'ai l'impression que les fichiers de configuration de toutes les vm est sur les disques SSD en local des hosts, et lorsqu'un host tombe, un autre peut facilement et rapidement prendre le relais.
D'ailleurs, mais je ne doute pas que c'est une évidence, il ne faut mettre aucune vm sur le disque local des serveurs, car tu perdrais le failover et la haute dispo sur ces vm.
J'espère avoir répondu a vos questions
Et si jamais je peux aider ou pour mettre l'infrastructure en place je suis disponible.
Bon courage
http://www.captainadmin.com