SMPFR

Depuis 2008 j'ai un serveur dédié chez Dedibox (Online.net), qui me sert principalement de sandbox, pour bidouiller et apprendre sur le tas. J'ai aujourd'hui plus ou moins l'équivalent d'une dédibox LT (l'ancien DELL R210) (http://www.online.net/fr/serveur-dedie/dedibox-lt), sur lequel tourne un hyperviseur Xen et trois VM :

VM1 (Debian): Web
------------------
- FTP (proftpd)
- Web (apache)
- Reverse Proxy (Squid)
- P2P

VM2 (Debian): Minecraft
------------------
- Web (apache)
- Minecraft

VM3 (Debian): SQL
------------------
- Web (apache)
- MySQL
- PHPMyAdmin

Tout fonctionne bien, j'ai appris à me familiariser avec Xen, ce qui était le but de l'opération. Online a récemment revu ses tarifs à la baisse, du coup j'hésite à changer de serveur pour en prendre d'autres, moins puissants, dans l'optique de jouer avec la haute disponibilité et l'administration de multiples serveurs, chose avec laquelle je ne suis pas trop familiarisé actuellement. Dans l'idéal, j'aimerai bien tester Puppet, un système de fichier distribué, HeartBeat et compagnie.

Du coup, au lieu de prendre un serveur a 49.99, je passerai a 5 serveurs à 9.99 ou 1 à 29.99 et 2 à 9.99. Je me demande si je gagne au change en prenant plusieurs serveurs ou si au contraire, c'est mieux de jouer sur des machines virtuelles, sur une unique et plus grosse bécane.

Je suis également preneur de conseils, de suggestions sur les softs sympa à découvrir pour gérer/manager/surveiller un cluster

tu veux faire de la haute dispo dans quel but ?

En gros, y a 2 types de clusters
- Cluster passif : 1 machine maitre, des esclaves, le but est de maintenir une disponibilité maximum
- Cluster actif ou load-balancing : ici on cherche à répartir la charge en balancant les requetes sur les serveurs, le but premier n'est pas d'améliorer la disponibilité

Et aussi, ça dépend de ton application

- Système de fichiers : compliqué
- Serveur web : simple
- Base de données : géré directement par la bdd

Dans le but de me familiariser avec HeartBeat et compagnie, je le vois souvent revenir dans la mailing list de Xen, sans jamais avoir eu l'occasion de l'utiliser.

Du coup je pense qu'un cluster passif correspond plus à ce que je recherche, je n'ai pas assez de trafic pour mettre en place une solution de load balancing.

ZFS ne permet pas de gérer la réplication à la volée d'un FS ? Je crois avoir lu ça quelque part (encore faut-il que je retrouve la source)

Quelques news : je suis passé sur une Dedibox LT 2013 (par défaut, ils sont submergés par la demande sur les Classic+), avec un hyperviseur Esxi pour me faire la main.

J'ai l'impression de régresser avec l'interface graphique qui simplifie tout, à contrario de Xen, où tout était en lignes de commandes et fichiers de configurations. Si je souhaite travailler dans le réseau/admin, j'ai un quelconque intérèt à maitriser ESXi ?

Sinon j'ai également joué avec PfSense, qui me sert de firewall et qui redirige les différents trafics sur les différentes VM. Egalement, ça fait tout bizarre de mettre des règles dans une interface web plutôt que de faire des iptables à la main !

La prochaine étape va être de s'intéresser à Puppet, et de regarder ce que je peux faire du côté de heartbeat en cas de crash de la vm web (ceci dit, l'intérèt semble limité vu que le serveur qui prendra le relais est sur la même machine physique)

Si je souhaite travailler dans le réseau/admin, j'ai un quelconque intérèt à maitriser ESXi ?
---
si tu pose la question c'est que tu n'es pas prêt

Si je souhaite travailler dans le réseau/admin, j'ai un quelconque intérèt à maitriser ESXi ?
---
si tu pose la question c'est que tu n'es pas prêt

Moi je dirais, ça dépend où

alllllezzzzzzzzzzzz on parle d'un produit esx/esxi qui existe chez 90% des boites d'info un peu grosses

J'ai jamais touché à ce truc

Tu fais parti des 10%.

ca fait pas longtemps que j'y suis donc je sais pas encore tout ce qui s'y passe mais dans ma boite y a les 2 ^^ et de ce que j'ai pu voir :
xen pour les application
ESX 3.5 pour tout le reste

ca fait pas longtemps que j'y suis donc je sais pas encore tout ce qui s'y passe mais dans ma boite y a les 2 ^^ et de ce que j'ai pu voir :
xen pour les application
ESX 3.5 pour tout le reste

c'est vieux 3.5

Oui mais compatibilité matérielle beaucoup plus large.

ESX 4.0 et 4.1 : bcp plus de problèmes de matos.

HAST + CARP sous FreeBSD ça roxx pour faire de la haute dispo !

HAST s'occupe de la réplication du disque, c'est hyper simple à utiliser et efficace. CARP ça permet de partager une ip virtuelle pour reprendre l'ip en cas de soucis.

C'est VRAIMENT plus simple que heartbeat-corosync + DRDB, y a pas photo !

et Windows ?

et Windows ?

Connaît pas [:dauphine974:1], mais ça m'intéresse pas c'est pas de l'Unix

heartbeat-corosync + DRDB, y a pas photo !

C'est fou qu'on trouve ce procédé encore maintenant en HA.
Ça bouffe tellement de IOPS débit & co ... :/

C'est fou qu'on trouve ce procédé encore maintenant en HA.
Ça bouffe tellement de IOPS débit & co ... :/

ben tu veux faire comment ? Faut bien que le disque soit synchro en permanence de chaque côté

ben tu veux faire comment ? Faut bien que le disque soit synchro en permanence de chaque côté

ZFS

ZFS

ça revient au même d'avoir un zfs-stream en permanence ^^

ça revient au même d'avoir un zfs-stream en permanence ^^

Pas du tout ! Ca pompe beaucoup moins en IOPS !!!

Aussi, avec Nexenta qui propose du HA
... http://www.nexenta.com/corp/support/res ... tion/63#HA



++

Pas du tout ! Ca pompe beaucoup moins en IOPS !!!

Aussi, avec Nexenta qui propose du HA
... http://www.nexenta.com/corp/support/res ... tion/63#HA



++

En quoi ça consomme mois d'IOPS ?

En quoi ça consomme mois d'IOPS ?

Dans les différentes études que j'avais fait pour bien connaître ZFS, il était indiqué avec schéma & vidéo le pourquoi du comment.

Dès que je le retrouve, je le poste.

++

ok ca m'intéresse aussi parceque ca n'a aucune logique

ok ca m'intéresse aussi parceque ca n'a aucune logique

Ce qui est logique, c'est que transférer une incrémental de snapshot (avec zfs-send et zfs-receive) à interval régulier pour synchroniser des pools consomme moins d'I/O que de faire en temps réel. Sauf que c'est pas du temps réel.

Alors après, faire un zfs-stream, peut-être qu'il y a moins de données transférées étant donné qu'on parler de système de fichier, et non de réplication de type bloc, mais je pense pas que ce soit très différent après...

Ou alors, zfs envoie par petits paquets (genre 5-10 secondes) pour regrouper des commandes et éviter des choses inutiles et ne fais pas une bête synchro temps réelle, mais ça ferait perdre ce temps de buffer en cas de coupure. [:dauphine974:1]

voila et pour une quantité données ( que ce soit FS ou bloc on arrive toujours à une unité de découpe mini) de disque en temps réel y'a pas moyen de baisser les iops