Hello, sur mysql j'ai utilisé la réplication en mode maitre/esclave pour synchroniser une base avant une migration. C'est efficace, la donnée est écrite sur le maitre et automatiquement répliqué sur l'esclave. Ca prend un peu prêt 4 minutes à mettre en place.
Mais je n'ai pas testé le cas de crash du maitre comment redirigé vers l'esclave. Je suppose qu'il faut mettre un haproxy devant pour que cela soit transparent pour les utilisateurs/application.
Pour moi il y a deux niveaux :
- faire en sorte qu'un serveur reste disponible;
- faire en sorte qu'une appli reste disponible.
1er niveau : le serveur, tout comme pour un serveur physique, on doit faire le max pour qu'il reste online (merde, un peu de respect pour l'uptime ;) ). L'objectif est de réduire au max le temps de latence pendant le transfert d'un hôte à un autre. Quand je parle de transfert c'est uniquement pour la partie vcpu/vram/réseau, le stockage des VM est commun à tous les hôtes d'un cluster. Forcément la latence aura un impact sur les appli de chaque VM.
2eme niveau : l'appli doit rester disponible. C'est effectivement le plus délicat et encore plus pour les bases de données. J'ai retourné le truc un peu dans tout les sens :
maitre/esclave;
actif/actif;
actif/passif;
...
Il y a forcément un moment où une info se perd même si c'est commité toutes les demi-secondes ou même "instantanément". Une coupure en plein milieu d'un commit et réplication entre base... Et hop incohérence. C'est ici que s'arrête mon "expertise" :D
[^] # Re: CEPH c'est bien mais ...
Posté par Philippe M (site web personnel) . En réponse au journal Proxmox et le HA. Évalué à 2.
Hello, sur mysql j'ai utilisé la réplication en mode maitre/esclave pour synchroniser une base avant une migration. C'est efficace, la donnée est écrite sur le maitre et automatiquement répliqué sur l'esclave. Ca prend un peu prêt 4 minutes à mettre en place.
Mais je n'ai pas testé le cas de crash du maitre comment redirigé vers l'esclave. Je suppose qu'il faut mettre un haproxy devant pour que cela soit transparent pour les utilisateurs/application.
Pour moi il y a deux niveaux :
- faire en sorte qu'un serveur reste disponible;
- faire en sorte qu'une appli reste disponible.
1er niveau : le serveur, tout comme pour un serveur physique, on doit faire le max pour qu'il reste online (merde, un peu de respect pour l'uptime ;) ). L'objectif est de réduire au max le temps de latence pendant le transfert d'un hôte à un autre. Quand je parle de transfert c'est uniquement pour la partie vcpu/vram/réseau, le stockage des VM est commun à tous les hôtes d'un cluster. Forcément la latence aura un impact sur les appli de chaque VM.
2eme niveau : l'appli doit rester disponible. C'est effectivement le plus délicat et encore plus pour les bases de données. J'ai retourné le truc un peu dans tout les sens :
Il y a forcément un moment où une info se perd même si c'est commité toutes les demi-secondes ou même "instantanément". Une coupure en plein milieu d'un commit et réplication entre base... Et hop incohérence. C'est ici que s'arrête mon "expertise" :D
Born to Kill EndUser !