Bonjour, Je m'apprète à attaquer un PoC pour répliquer des fs ZFS avec du DRBD pour faire du stockage H.A. entre hyperviseurs.
Je n'ai pas une grand connaissance de ZFS mais à ce que j'ai compris, ca ressemble beaucoup à un couple RAID soft + LVM en terme de fonctionnement. Avec pas mal de trucs en plus type dedup, compress, self healing, etc ...
Sauf que les vgs s'appelle zpool et les lvs s'appellent zvols. Tout faux ?
Bref, d'après mon schéma, j'aurais deux façons de tester ça : 1) Créer une ressource DRBD par zvol puisqu'ils sont exportés sous forme de block device (ce qui ne semble pas le cas des zpool, dommage).
2) Créer une ressource DRBD par disque physique sous le zpool. Le zpool sera donc créé avec /dev/drbd0 et /dev/drbd1 au lieu des sda/sdb (et encore, il semble que par uuid, c'est mieux).
L'avantage de la solution 1, c'est que je peux mettre un ZIL sans risque qu'il conserve des écritures qui n'auront pas été répliquées en cas de crash. Mais ça m'oblige à créer une ressource DRBD pour chaque disque virtuel donné à mes VMs.
Il me restera encore pas mal de choses à tester comme les mécanismes de verrouillage pour éviter les écritures simultanées, les perfs, etc ...
Est-ce que quelqu'un s'est déjà lancé dans ce type de conf et aurait des retours, en particulier sur la stabilité du bouzin ?
Merci ! Julien
P.S. : si c'était nécessaire : je suis évidemment sous Linux avec ZoL et drbd 8.4.
Hello,
On 12/05/2015 15:58, Julien Escario wrote:
Je m'apprète à attaquer un PoC pour répliquer des fs ZFS avec du DRBD pour faire du stockage H.A. entre hyperviseurs.
Je ne connais pas ton use cas mais c'est surement une mauvaise idée si tu as besoin de perfs !...
Perso, je resterais sur un bon ext4 voire xfs si la partition est assez grosse, évt avec un cache SSD (flashcache, io enhance, cachecade, etc) si tu es concerné par les perfs (mais ça sera de toute façon mauvais en écriture avec DRBD).
À consulter absolument avant de se lancer la dedans : https://www.youtube.com/watch?v=l910kiEuHOM&feature=youtu.be
Mais jamais un DRBD ne permettra d'atteindre les perfs d'un ZFS bien tuné dès lors qu'il y a des opérations d'écritures. La latence introduite par DRBD est assez difficilement supportable.
Un truc assez cool avec ZFS c'est la possibilité de snapshoter le FS du maître et d'envoyer ce snapshot sur un réplicat.
http://docs.oracle.com/cd/E19253-01/820-2315/gbchx/index.html
Perso j'utilise zrep (http://www.bolthole.com/solaris/zrep/), ça ronronne depuis près de deux ans sans broncher, avec d'excellentes perfs (rien à voir notamment avec DRBD que j'avais avant et qui s'écroulait lamentablement aux heures de pointe).
À l'époque il y avait un petit soucit entre zrep et ZIL donc mes serveurs ZFS tournent sous omnios (dérivé d'open solaris).
Cette solution a cependant un inconvénient : ce n'est pas une réplication synchrone : en cas d'incident, je sais que je suis susceptible de perdre les modifications écrites quelques secondes auparavant sur le master. Dans mon métier, c'est un risque acceptable.
Cdlt,
Le 12/05/15 16:27, olc a écrit :
Un truc assez cool avec ZFS c'est la possibilité de snapshoter le FS du maître et d'envoyer ce snapshot sur un réplicat.
Oui j'allais le dire. Zfs send/receive est une option bien sympathique. Ça ressemble pas mal a du snapmirror netapp.
Perso j'utilise zrep (http://www.bolthole.com/solaris/zrep/), ça ronronne depuis près de deux ans sans broncher, avec d'excellentes perfs
Je connaissais pas, je vais jeter un oeil.
Cette solution a cependant un inconvénient : ce n'est pas une réplication synchrone : en cas d'incident, je sais que je suis susceptible de perdre les modifications écrites quelques secondes auparavant sur le master. Dans mon métier, c'est un risque acceptable.
Alors la réplication synchrone pose tellement de soucis qu'il vaut mieux être safe avec une réplication asynchrone régulière. C'est comme tenter de faire de l'actif/actif sur du stockage, ca parait sexy en théorie, mais en pratique...
La réplication synchrone qui pose soucis, tu parles de manière spécifique à zfs ?
On 12/05/2015 17:08, Raphael Mazelier wrote:
Le 12/05/15 16:27, olc a écrit :
Un truc assez cool avec ZFS c'est la possibilité de snapshoter le FS du maître et d'envoyer ce snapshot sur un réplicat.
Oui j'allais le dire. Zfs send/receive est une option bien sympathique. Ça ressemble pas mal a du snapmirror netapp.
Perso j'utilise zrep (http://www.bolthole.com/solaris/zrep/), ça ronronne depuis près de deux ans sans broncher, avec d'excellentes perfs
Je connaissais pas, je vais jeter un oeil.
Cette solution a cependant un inconvénient : ce n'est pas une réplication synchrone : en cas d'incident, je sais que je suis susceptible de perdre les modifications écrites quelques secondes auparavant sur le master. Dans mon métier, c'est un risque acceptable.
Alors la réplication synchrone pose tellement de soucis qu'il vaut mieux être safe avec une réplication asynchrone régulière. C'est comme tenter de faire de l'actif/actif sur du stockage, ca parait sexy en théorie, mais en pratique...
Le 12/05/15 17:10, frsag@jack.fr.eu.org a écrit :
La réplication synchrone qui pose soucis, tu parles de manière spécifique à zfs ?
Non en général. Le truc c'est que si tu veux que ce soit synchrone, chaque écriture doit être ack des deux cotés. Hors tu peux imaginer le désastre en terme de performance. En plus comme tout les sous systèmes trichent sur le fait de que la donnée soient *reelement* écrit sur le disque, tu te retrouve avec un truc complexe à gérer. Alors qu'au moins avec de l'asynchrone basé sur des snapshots, c'est simple et tu as au moins l'assurance d'avoir des datas cohérentes.
Il n'y a d'ailleurs pas masse de bonnes technologies de réplication synchrone.
Mouais j'sais pas trop J'utilise drbd sur l'intégralité de mes VM, quasiment aucun soucis
M'enfin
On 12/05/2015 18:06, Raphael Mazelier wrote:
Le 12/05/15 17:10, frsag@jack.fr.eu.org a écrit :
La réplication synchrone qui pose soucis, tu parles de manière spécifique à zfs ?
Non en général. Le truc c'est que si tu veux que ce soit synchrone, chaque écriture doit être ack des deux cotés. Hors tu peux imaginer le désastre en terme de performance. En plus comme tout les sous systèmes trichent sur le fait de que la donnée soient *reelement* écrit sur le disque, tu te retrouve avec un truc complexe à gérer. Alors qu'au moins avec de l'asynchrone basé sur des snapshots, c'est simple et tu as au moins l'assurance d'avoir des datas cohérentes.
Il n'y a d'ailleurs pas masse de bonnes technologies de réplication synchrone.
C'est des VM, donc actif-passif (la VM ne tourne que sur un côté à la fois) En revanche, cela reste synchrone
On 12/05/2015 18:30, Raphael Mazelier wrote:
Le 12/05/15 18:25, frsag@jack.fr.eu.org a écrit :
Mouais j'sais pas trop J'utilise drbd sur l'intégralité de mes VM, quasiment aucun soucis
En actif/actif ?
Le Tue, May 12, 2015 at 06:25:29PM +0200, frsag@jack.fr.eu.org [frsag@jack.fr.eu.org] a écrit:
Mouais j'sais pas trop J'utilise drbd sur l'intégralité de mes VM, quasiment aucun soucis
Mais les perfs s'en ressentent, forcément, sur les i/o (latence réseau pour le transfert + attente de l'ack)
Le 18/05/2015 15:00, Dominique Rousseau a écrit :
Le Tue, May 12, 2015 at 06:25:29PM +0200, frsag@jack.fr.eu.org [frsag@jack.fr.eu.org] a écrit:
Mouais j'sais pas trop J'utilise drbd sur l'intégralité de mes VM, quasiment aucun soucis
Mais les perfs s'en ressentent, forcément, sur les i/o (latence réseau pour le transfert + attente de l'ack)
En cross-connecte entre deux machines, ça peut aller. Et il reste le mode async (protocol A ou B) mais qui n'autorise pas le dual primary (ce qui n'empêche pas de passer en dual primary le jour où c'est nécessaire à chaud avec DRBD 8.4).
L'idéal étant de laisse tomber ethernet pour faire des trucs moins 'latenceux' comme infiniband (pas très cher si pas plus de deux nodes).
Bon, pour en revenir à DRBD/ZFS vs ZFS send/receive : dans mon cas, c'est pour stocker de l'image de VM. Je vois quand même venir un truc moche en prenant un besoin spécifique : de la base de données.
Soit on fait du mode synchrone et la perf en pâtis (pâtit ?) mais on est sûr que les I/O que le mariadb au dessus considère comme écris SONT écris.
Soit on fait du mode asynchrone (que ce soit DRBD A/B ou ZFS send/receive d'ailleurs) et on a aucune certitude que au moment où sa va repasser sur l'autre HV, la base de données va pouvoir retrouver ses petits, en particulier sur des trucs fragiles comme innodb (attention, troll inside).
Une idée pour avoir le meilleur des deux mondes ?
Julien
Le Mon, May 18, 2015 at 03:37:12PM +0200, Julien Escario [escario@azylog.net] a écrit: [...]
Soit on fait du mode asynchrone (que ce soit DRBD A/B ou ZFS send/receive d'ailleurs) et on a aucune certitude que au moment où sa va repasser sur l'autre HV, la base de données va pouvoir retrouver ses petits, en particulier sur des trucs fragiles comme innodb (attention, troll inside).
Une idée pour avoir le meilleur des deux mondes ?
Répliquer la base de données ? ;)
On Mon, May 18, 2015 at 03:37:12PM +0200, Julien Escario wrote:
Le 18/05/2015 15:00, Dominique Rousseau a écrit :
Le Tue, May 12, 2015 at 06:25:29PM +0200, frsag@jack.fr.eu.org [frsag@jack.fr.eu.org] a écrit:
Mouais j'sais pas trop J'utilise drbd sur l'intégralité de mes VM, quasiment aucun soucis
Mais les perfs s'en ressentent, forcément, sur les i/o (latence réseau pour le transfert + attente de l'ack)
En cross-connecte entre deux machines, ça peut aller. Et il reste le mode async (protocol A ou B) mais qui n'autorise pas le dual primary (ce qui n'empêche pas de passer en dual primary le jour où c'est nécessaire à chaud avec DRBD 8.4).
L'idéal étant de laisse tomber ethernet pour faire des trucs moins 'latenceux' comme infiniband (pas très cher si pas plus de deux nodes).
Bon, pour en revenir à DRBD/ZFS vs ZFS send/receive : dans mon cas, c'est pour stocker de l'image de VM. Je vois quand même venir un truc moche en prenant un besoin spécifique : de la base de données.
Soit on fait du mode synchrone et la perf en pâtis (pâtit ?) mais on est sûr que les I/O que le mariadb au dessus considère comme écris SONT écris.
Soit on fait du mode asynchrone (que ce soit DRBD A/B ou ZFS send/receive d'ailleurs) et on a aucune certitude que au moment où sa va repasser sur l'autre HV, la base de données va pouvoir retrouver ses petits, en particulier sur des trucs fragiles comme innodb (attention, troll inside).
Une idée pour avoir le meilleur des deux mondes ?
Si tu l'as, garde là pour toi et vend là, tu deviendras riche ;).
Trève de plaisanterie, comme je disais dans l'autre mail que j'ai envoyé aujourd'hui dans ce même thread, tu peux peut-être utiliser les deux : - réplication synchrone pour les base de données - réplication asynchrone (zfs send/recv, rsync, whatever) pour le reste
De toute façon, pour une base de données, il faudra obligatoirement répliquer le journal de façon synchrone pour ne pas perdre de données. Tu peux peut-être créer un setup qui ne réplique que le journal (il existe d'ailleurs peut-être des technos native avec ta base de données permettant de faire ça, ou alors tu devras le faire en mettant le journal sur un device spécifique tu répliques à l'aide de DRBD ou HAST), et ensuite lors d'un failover tu le rejoues au dessus de la dernière synchro (asynchrone) du fichier data de la base de données.
Mais bon voilà, rien qu'à lire le bloc de texte ci-dessus, ça sent le truc compliqué. Je ne dis pas que ce n'est pas à faire, mais il faut vraiment que ce soit justifié et pas uniquement pour la performance technique (jeu de mot intentionel). Cela étant dit, si tu veux faire un truc dans ce genre avec du MySQL ou du MariaDB, je suis sûr que certains outils Percona existent pour simplifier le tout. Mais ça reste complexe.
Le 18/05/2015 16:33, Jeremie Le Hen a écrit :
Une idée pour avoir le meilleur des deux mondes ?
Si tu l'as, garde là pour toi et vend là, tu deviendras riche ;).
OK, donc on est d'accords. Reliability, simplicity, cost, pick two.
Trève de plaisanterie, comme je disais dans l'autre mail que j'ai envoyé aujourd'hui dans ce même thread, tu peux peut-être utiliser les deux :
- réplication synchrone pour les base de données
- réplication asynchrone (zfs send/recv, rsync, whatever) pour le reste
De toute façon, pour une base de données, il faudra obligatoirement répliquer le journal de façon synchrone pour ne pas perdre de données. Tu peux peut-être créer un setup qui ne réplique que le journal (il existe d'ailleurs peut-être des technos native avec ta base de données permettant de faire ça, ou alors tu devras le faire en mettant le journal sur un device spécifique tu répliques à l'aide de DRBD ou HAST), et ensuite lors d'un failover tu le rejoues au dessus de la dernière synchro (asynchrone) du fichier data de la base de données.
Mais bon voilà, rien qu'à lire le bloc de texte ci-dessus, ça sent le truc compliqué. Je ne dis pas que ce n'est pas à faire, mais il faut vraiment que ce soit justifié et pas uniquement pour la performance technique (jeu de mot intentionel). Cela étant dit, si tu veux faire un truc dans ce genre avec du MySQL ou du MariaDB, je suis sûr que certains outils Percona existent pour simplifier le tout. Mais ça reste complexe.
Donc mon cas particulier, je ne maîtrise pas ce que mon client fait de sa VM, ce qui m'oblige à faire du synchrone, tant pis pour la perf. Ce qui finalement, n'interdit pas de le faire le mieux possible. Quid de l'incidence de stockage SSD ou hybrid par exemple ?
Donc, on en revient à DRBD. Je vous laisse décider si HAST est mieux ou moins bien, perso, j'ai eu suffisamment d'emmerdes avec DRBD pour considérer que je connais pas trop mal le produit maintenant.
CQFD ?
Julien
Bonjour la liste...
Si vous voulez avoir de plus amples infos sur ZFS (illumos, BSD, ZoL, Mac...) ne pas hésiter pas à venir nous voir pendant notre prochain summit Européen : http://www.meetup.com/OpenZFS-Europe/
C'est l'occasion de discuter avec la communauté OpenZFS et les core dev ;-)
Cordialement, Yacine
2015-05-18 16:54 GMT+02:00 Julien Escario escario@azylog.net:
Le 18/05/2015 16:33, Jeremie Le Hen a écrit :
Une idée pour avoir le meilleur des deux mondes ?
Si tu l'as, garde là pour toi et vend là, tu deviendras riche ;).
OK, donc on est d'accords. Reliability, simplicity, cost, pick two.
Trève de plaisanterie, comme je disais dans l'autre mail que j'ai envoyé
aujourd'hui dans ce même thread, tu peux peut-être utiliser les deux :
- réplication synchrone pour les base de données
- réplication asynchrone (zfs send/recv, rsync, whatever) pour le reste
De toute façon, pour une base de données, il faudra obligatoirement répliquer le journal de façon synchrone pour ne pas perdre de données. Tu peux peut-être créer un setup qui ne réplique que le journal (il existe d'ailleurs peut-être des technos native avec ta base de données permettant de faire ça, ou alors tu devras le faire en mettant le journal sur un device spécifique tu répliques à l'aide de DRBD ou HAST), et ensuite lors d'un failover tu le rejoues au dessus de la dernière synchro (asynchrone) du fichier data de la base de données.
Mais bon voilà, rien qu'à lire le bloc de texte ci-dessus, ça sent le truc compliqué. Je ne dis pas que ce n'est pas à faire, mais il faut vraiment que ce soit justifié et pas uniquement pour la performance technique (jeu de mot intentionel). Cela étant dit, si tu veux faire un truc dans ce genre avec du MySQL ou du MariaDB, je suis sûr que certains outils Percona existent pour simplifier le tout. Mais ça reste complexe.
Donc mon cas particulier, je ne maîtrise pas ce que mon client fait de sa VM, ce qui m'oblige à faire du synchrone, tant pis pour la perf. Ce qui finalement, n'interdit pas de le faire le mieux possible. Quid de l'incidence de stockage SSD ou hybrid par exemple ?
Donc, on en revient à DRBD. Je vous laisse décider si HAST est mieux ou moins bien, perso, j'ai eu suffisamment d'emmerdes avec DRBD pour considérer que je connais pas trop mal le produit maintenant.
CQFD ?
Julien
Liste de diffusion du FRsAG http://www.frsag.org/
Le 12/05/2015 17:08, Raphael Mazelier a écrit :
Le 12/05/15 16:27, olc a écrit :
Un truc assez cool avec ZFS c'est la possibilité de snapshoter le FS du maître et d'envoyer ce snapshot sur un réplicat.
Oui j'allais le dire. Zfs send/receive est une option bien sympathique. Ça ressemble pas mal a du snapmirror netapp.
Perso j'utilise zrep (http://www.bolthole.com/solaris/zrep/), ça ronronne depuis près de deux ans sans broncher, avec d'excellentes perfs
Je connaissais pas, je vais jeter un oeil.
Cette solution a cependant un inconvénient : ce n'est pas une réplication synchrone : en cas d'incident, je sais que je suis susceptible de perdre les modifications écrites quelques secondes auparavant sur le master. Dans mon métier, c'est un risque acceptable.
Alors la réplication synchrone pose tellement de soucis qu'il vaut mieux être safe avec une réplication asynchrone régulière. C'est comme tenter de faire de l'actif/actif sur du stockage, ca parait sexy en théorie, mais en pratique...
Alors ouep mais mon but n'est pas de faire un truc qui marche mais de tester sur une théorie est valide. ZFS send/receive, ce n'est pas un problème. Le but s'est d'arriver à de l'asynchrone qui marche, au moins sur le papier. On verra après si ca peut passer en production (critique, pas critique, perfs, etc ...).
J'en déduis que personne n'a testé le truc ? Bon ben va pour un poc bien documenté pour le retour d'expérience ;-)
Julien
Bonjour la liste,
Julien, as tu jeté un oeil du coté des "cluster file system" comme ceph, ocfs2 ou gluster?
Cordialement, Romain
Le 12/05/2015 15:58, Julien Escario a écrit :
Bonjour, Je m'apprète à attaquer un PoC pour répliquer des fs ZFS avec du DRBD pour faire du stockage H.A. entre hyperviseurs.
Je n'ai pas une grand connaissance de ZFS mais à ce que j'ai compris, ca ressemble beaucoup à un couple RAID soft + LVM en terme de fonctionnement. Avec pas mal de trucs en plus type dedup, compress, self healing, etc ...
Sauf que les vgs s'appelle zpool et les lvs s'appellent zvols. Tout faux ?
Bref, d'après mon schéma, j'aurais deux façons de tester ça :
- Créer une ressource DRBD par zvol puisqu'ils sont exportés sous forme
de block device (ce qui ne semble pas le cas des zpool, dommage).
- Créer une ressource DRBD par disque physique sous le zpool. Le zpool
sera donc créé avec /dev/drbd0 et /dev/drbd1 au lieu des sda/sdb (et encore, il semble que par uuid, c'est mieux).
L'avantage de la solution 1, c'est que je peux mettre un ZIL sans risque qu'il conserve des écritures qui n'auront pas été répliquées en cas de crash. Mais ça m'oblige à créer une ressource DRBD pour chaque disque virtuel donné à mes VMs.
Il me restera encore pas mal de choses à tester comme les mécanismes de verrouillage pour éviter les écritures simultanées, les perfs, etc ...
Est-ce que quelqu'un s'est déjà lancé dans ce type de conf et aurait des retours, en particulier sur la stabilité du bouzin ?
Merci ! Julien
P.S. : si c'était nécessaire : je suis évidemment sous Linux avec ZoL et drbd 8.4.
Liste de diffusion du FRsAG http://www.frsag.org/
Le 12/05/2015 20:11, Romain SIBILLE a écrit :
Bonjour la liste,
Julien, as tu jeté un oeil du coté des "cluster file system" comme ceph, ocfs2 ou gluster?
Alors ocfs2, c'est une vraie usine à gaz et gluster j'ai de mauvais souvenirs en terme de stabilité. Ca date ceci dit, 2/3 ans.
Reste Ceph qui m’intéresse beaucoup mais je n'ai pas les 4 ou 5 machines requises pour monter tout ça. Et ca semble tout de même avoir un petit côté usine à gaz mais en complément d'un cluster openstack, d'après ce que je lis ici et là, ça fait des miracles.
Julien
On 12/05/2015 22:17, Julien Escario wrote:
Alors ocfs2, c'est une vraie usine à gaz et gluster j'ai de mauvais souvenirs en terme de stabilité. Ca date ceci dit, 2/3 ans.
Tututut, y'a rien de plus simple qu'ocfs2 (si t'as un SAN). Juste, c'est un peu fragile et le fait que ça fonctionne sans trop d'efforts rend l'adminsys faignant. Erreur. Et paf les datas.
GlusterFS, c'est un peu pareil, mais à l'envers vu que c'est distribué. :)
Reste Ceph qui m’intéresse beaucoup mais je n'ai pas les 4 ou 5 machines requises pour monter tout ça. Et ca semble tout de même avoir un petit côté usine à gaz mais en complément d'un cluster openstack, d'après ce que je lis ici et là, ça fait des miracles.
Ceph <3. Mais 4/5 machines, c'est le strict minimum, pour jouer.
Hop,
----- Mail original -----
De: "olc" olc@glou.fr À: frsag@frsag.org Envoyé: Mardi 12 Mai 2015 22:37:18 Objet: Re: [FRsAG] ZFS et DRBD
On 12/05/2015 22:17, Julien Escario wrote:
Alors ocfs2, c'est une vraie usine à gaz et gluster j'ai de mauvais souvenirs en terme de stabilité. Ca date ceci dit, 2/3 ans.
Tututut, y'a rien de plus simple qu'ocfs2 (si t'as un SAN). Juste, c'est un peu fragile et le fait que ça fonctionne sans trop d'efforts rend l'adminsys faignant. Erreur. Et paf les datas.
GlusterFS, c'est un peu pareil, mais à l'envers vu que c'est distribué. :)
Reste Ceph qui m’intéresse beaucoup mais je n'ai pas les 4 ou 5 machines requises pour monter tout ça. Et ca semble tout de même avoir un petit côté usine à gaz mais en complément d'un cluster openstack, d'après ce que je lis ici et là, ça fait des miracles.
Ceph <3. Mais 4/5 machines, c'est le strict minimum, pour jouer.
+1
Mais pour faire un POC et voir comment ça marche tu peux :
- utiliser des machines virtuelles (Ok, tu testes pas la perf) - mettre tes serveurs OSD sur une même machine comportant au moins 3 disques. Il te faut du coup 2 machines : Celle ou tu met tes 3 MON et celle ou tu place tes 3+ OSD :)
Sinon, j'ai fait pour vous, DRDB en actif/actif avec GPFS dessus pour la gestion des écritures concurrentes en production (non, ne dites rien!). Je vous le déconseille fortement (split brain assurés en cas de redémarrage d'une machine - performances vraiment très décevantes).
Sauf erreur de ma part, ext4, xfs et ZFS ne sont pas distribués et ne gèreront pas correctement des écritures concomitantes provenant de deux (ou plus) serveurs avec de l'actif/actif DRDB.
@+,
Le 2015-05-13 15:29, Olivier DELHOMME a écrit :
Hop,
----- Mail original -----
De: "olc" olc@glou.fr À: frsag@frsag.org Envoyé: Mardi 12 Mai 2015 22:37:18 Objet: Re: [FRsAG] ZFS et DRBD
On 12/05/2015 22:17, Julien Escario wrote:
Alors ocfs2, c'est une vraie usine à gaz et gluster j'ai de mauvais souvenirs en terme de stabilité. Ca date ceci dit, 2/3 ans.
Tututut, y'a rien de plus simple qu'ocfs2 (si t'as un SAN). Juste, c'est un peu fragile et le fait que ça fonctionne sans trop d'efforts rend l'adminsys faignant. Erreur. Et paf les datas.
GlusterFS, c'est un peu pareil, mais à l'envers vu que c'est distribué. :)
Reste Ceph qui m’intéresse beaucoup mais je n'ai pas les 4 ou 5 machines requises pour monter tout ça. Et ca semble tout de même avoir un petit côté usine à gaz mais en complément d'un cluster openstack, d'après ce que je lis ici et là, ça fait des miracles.
Ceph <3. Mais 4/5 machines, c'est le strict minimum, pour jouer.
+1
Mais pour faire un POC et voir comment ça marche tu peux :
- utiliser des machines virtuelles (Ok, tu testes pas la perf)
- mettre tes serveurs OSD sur une même machine comportant au moins 3 disques. Il te faut du coup 2 machines : Celle ou tu met tes 3 MON et celle ou tu place tes 3+ OSD :)
Sinon, j'ai fait pour vous, DRDB en actif/actif avec GPFS dessus pour la gestion des écritures concurrentes en production (non, ne dites rien!). Je vous le déconseille fortement (split brain assurés en cas de redémarrage d'une machine - performances vraiment très décevantes).
Sauf erreur de ma part, ext4, xfs et ZFS ne sont pas distribués et ne gèreront pas correctement des écritures concomitantes provenant de deux (ou plus) serveurs avec de l'actif/actif DRDB.
@+,
GFS2 et Ceph semble être des pistes à regarder... GPFS, c'est la solution à IBM, c'est ça ?
Sinon DRBD, c'est une solution supportée par qui ?
Cdlt,
JYL
Bonjour,
[...]
Mais pour faire un POC et voir comment ça marche tu peux :
- utiliser des machines virtuelles (Ok, tu testes pas la perf)
- mettre tes serveurs OSD sur une même machine comportant au moins 3 disques. Il te faut du coup 2 machines : Celle ou tu met tes 3 MON et celle ou tu place tes 3+ OSD :)
Sinon, j'ai fait pour vous, DRDB en actif/actif avec GPFS dessus pour la gestion des écritures concurrentes en production (non, ne dites rien!). Je vous le déconseille fortement (split brain assurés en cas de redémarrage d'une machine - performances vraiment très décevantes).
Sauf erreur de ma part, ext4, xfs et ZFS ne sont pas distribués et ne gèreront pas correctement des écritures concomitantes provenant de deux (ou plus) serveurs avec de l'actif/actif DRDB.
@+,
GFS2 et Ceph semble être des pistes à regarder... GPFS, c'est la solution à IBM, c'est ça ?
Cette question m'a fait douté et, mybad, je me suis trompé (j'ai regardé mes vieilles docs), c'est GFS2 qu'on avait au dessus d'un "cluster" de deux machines.
Je pulsoie Ceph si c'est pour faire tourner de la VM.
Sinon DRBD, c'est une solution supportée par qui ?
Linbit, une société allemande il me semble :
@+,
Olivier.
Le 13/05/15 15:29, Olivier DELHOMME a écrit :
Hop,
met tes 3 MON et celle ou tu place tes 3+ OSD :)
Sinon, j'ai fait pour vous, DRDB en actif/actif avec GPFS dessus pour la gestion des écritures concurrentes en production (non, ne dites rien!).
J'ai le fait aussi dans mon jeu age. GFS2/OCFS2 même combat.
Je vous le déconseille fortement (split brain assurés en cas de redémarrage d'une machine - performances vraiment très décevantes).
Oui l'actif/actif ça semble beau sur le papier. Si tu cherches à distribuer les io(s) mieux vaut utiliser un truc fait pour.
Sauf erreur de ma part, ext4, xfs et ZFS ne sont pas distribués et ne gèreront pas correctement des écritures concomitantes provenant de deux (ou plus) serveurs avec de l'actif/actif DRDB.
Tout à fait. Et donc tant qu'a faire du distribué, autant faire du vrai distribué (ceph, gluster, moosefs, etc...)
Salut,
concernant les FS distribués, je peux faire un retour sur XtreemFS qui est très user friendly et très pratique mais qui engendre des pertes de performances vraiment importantes, notemment en WRITE.
Je suis en train d'écrire une procédure pour migrer le stockage XtreemFS vers du BeeGFS (anciennement FhGFS) qui annonce de bien meilleurs perfs.
L'astuce peut aussi être de jouer avec les types de données à répliquer (par exemple, ne répliquer que les données spécifiques issues d'un UnionFS).
++
2015-05-13 15:41 GMT+02:00 Raphael Mazelier raph@futomaki.net:
Le 13/05/15 15:29, Olivier DELHOMME a écrit :
Hop,
met tes 3 MON et celle ou tu place tes 3+ OSD :)
Sinon, j'ai fait pour vous, DRDB en actif/actif avec GPFS dessus pour la gestion des écritures concurrentes en production (non, ne dites rien!).
J'ai le fait aussi dans mon jeu age. GFS2/OCFS2 même combat.
Je vous le déconseille fortement (split brain assurés en cas de
redémarrage d'une machine - performances vraiment très décevantes).
Oui l'actif/actif ça semble beau sur le papier. Si tu cherches à distribuer les io(s) mieux vaut utiliser un truc fait pour.
Sauf erreur de ma part, ext4, xfs et ZFS ne sont pas distribués
et ne gèreront pas correctement des écritures concomitantes provenant de deux (ou plus) serveurs avec de l'actif/actif DRDB.
Tout à fait. Et donc tant qu'a faire du distribué, autant faire du vrai distribué (ceph, gluster, moosefs, etc...)
-- Raphael Mazelier
Liste de diffusion du FRsAG http://www.frsag.org/
Le 13/05/2015 15:41, Raphael Mazelier a écrit :
Oui l'actif/actif ça semble beau sur le papier. Si tu cherches à distribuer les io(s) mieux vaut utiliser un truc fait pour.
Alors justement, puisqu'on parle de distribué : ce n'est pas du tout l'objectif initial. Peut être un peu d'explication pour recentrer tout ça : l'idée finale s'est juste d'appairer deux hyperviseurs pour fournir aux VMs des block device qui ne seront actifs que d'un côté ou de l'autre. Je ne cherche pas le scalable à outrance, juste deux machine qui mirrorisent. En actif/actif pourquoi pas mais ce n'est même pas le but. Je veux juste avoir du disaster recovery qui me permette de faire repartir manuellement mes VMs sur le second hyperviseur si le premier crash. Dans un but de bonne utilisation des ressources, je pense que je vais couper mon stockage en deux : un actif sur chaque machine et son réplica passif sur l'autre, en croisé.
Voilà pourquoi j'ai pensé à DRBD. Au delà de deux machines, j'irais voir ailleurs, ca va de soi.
Julien
Ok, donc oui, drbdd corresponds tout à fait à ton besoin
Cela fonctionne très bien, tu devrais pouvoir l'utiliser avec zfs (je l'utilise avec LVM)
On 15/05/2015 10:37, Julien Escario wrote:
Le 13/05/2015 15:41, Raphael Mazelier a écrit :
Oui l'actif/actif ça semble beau sur le papier. Si tu cherches à distribuer les io(s) mieux vaut utiliser un truc fait pour.
Alors justement, puisqu'on parle de distribué : ce n'est pas du tout l'objectif initial. Peut être un peu d'explication pour recentrer tout ça : l'idée finale s'est juste d'appairer deux hyperviseurs pour fournir aux VMs des block device qui ne seront actifs que d'un côté ou de l'autre. Je ne cherche pas le scalable à outrance, juste deux machine qui mirrorisent. En actif/actif pourquoi pas mais ce n'est même pas le but. Je veux juste avoir du disaster recovery qui me permette de faire repartir manuellement mes VMs sur le second hyperviseur si le premier crash. Dans un but de bonne utilisation des ressources, je pense que je vais couper mon stockage en deux : un actif sur chaque machine et son réplica passif sur l'autre, en croisé.
Voilà pourquoi j'ai pensé à DRBD. Au delà de deux machines, j'irais voir ailleurs, ca va de soi.
Julien
Liste de diffusion du FRsAG http://www.frsag.org/
On Fri, May 15, 2015 at 10:37:53AM +0200, Julien Escario wrote:
Le 13/05/2015 15:41, Raphael Mazelier a écrit :
Oui l'actif/actif ça semble beau sur le papier. Si tu cherches à distribuer les io(s) mieux vaut utiliser un truc fait pour.
Alors justement, puisqu'on parle de distribué : ce n'est pas du tout l'objectif initial. Peut être un peu d'explication pour recentrer tout ça : l'idée finale s'est juste d'appairer deux hyperviseurs pour fournir aux VMs des block device qui ne seront actifs que d'un côté ou de l'autre. Je ne cherche pas le scalable à outrance, juste deux machine qui mirrorisent. En actif/actif pourquoi pas mais ce n'est même pas le but. Je veux juste avoir du disaster recovery qui me permette de faire repartir manuellement mes VMs sur le second hyperviseur si le premier crash. Dans un but de bonne utilisation des ressources, je pense que je vais couper mon stockage en deux : un actif sur chaque machine et son réplica passif sur l'autre, en croisé.
Merci de recentrer le sujet :).
En gros, ton choix se fera surtout entre les performances et l'intégrité.
Si tu fais du DRBD, tu impacteras les performances en écritures car celles-ci devront être acquitées par les deux machines avant que le process appelant ne puisse continuer. En contrepartie, une fois que l'écriture est acquitée auprès du process, elle ne sera pas perdue.
Si tu passes par de la syncho NFS (genre send/recv chaque minutes, ou même chaque N secondes), ton process n'attendra que l'acquitement local. En revanche tu pourras perdre jusqu'à une minute de données (ou N secondes).
J'ai oublié dans quel contexte business tu as besoin de ça, mais la solution que tu envisages (couper le stockage en deux) est peut-être pas mal si tu as par exemple des base de données (sur le DRBD) et des données statiques (typiquement serveur web) ou des applications qui checkpointent régulièrement de l'autre.
Hello,
<bsd mode=on>
Merci de recentrer le sujet :).
En gros, ton choix se fera surtout entre les performances et l'intégrité.
Si tu fais du DRBD, tu impacteras les performances en écritures car celles-ci devront être acquitées par les deux machines avant que le process appelant ne puisse continuer. En contrepartie, une fois que l'écriture est acquitée auprès du process, elle ne sera pas perdue.
Sur les FreeBSD qui font aussi du ZFS (hint ! hint !) il y a HAST.
Hast étant différent que DRBD, il donnera surement des choses plus "hum"... utiles que DRBD surtout au niveau des I/O car on sait bien que DRBD c'est bien mais ca tue les machines en I/O.
Après tu peux aussi coller du ZFS over HAST...
Personnellement j'avais fait du HAST pour synchro /var/db/mysql sur 2 VM et j'avais pas trop vu la différence au niveau perfs.
Après tu peux aussi ajouter du CARP + ifstated afin de relancer le bon deamon sans passer par une centrale nucléaire au niveau test Dead or Alive...
My 0,02€
</bsd>
Xavier
On Mon, May 18, 2015 at 02:37:52PM +0200, Xavier Beaudouin wrote:
Hello,
<bsd mode=on>
YEAHHHHH!!! LET'S TAKE OVER THE WORLD!!!!
Désolé.
Merci de recentrer le sujet :).
En gros, ton choix se fera surtout entre les performances et l'intégrité.
Si tu fais du DRBD, tu impacteras les performances en écritures car celles-ci devront être acquitées par les deux machines avant que le process appelant ne puisse continuer. En contrepartie, une fois que l'écriture est acquitée auprès du process, elle ne sera pas perdue.
Sur les FreeBSD qui font aussi du ZFS (hint ! hint !) il y a HAST.
Hast étant différent que DRBD, il donnera surement des choses plus "hum"... utiles que DRBD surtout au niveau des I/O car on sait bien que DRBD c'est bien mais ca tue les machines en I/O.
Ah oui ? Tu peux expliquer ? Je n'ai jamais utilisé ni l'un ni l'autre et pour moi conceptuellement, ils font la même chose. Aussi, si tu as des détails d'implémentation qui ont leur importance, je suis curieux !
Salut Jeremie
<bsd mode=on>
YEAHHHHH!!! LET'S TAKE OVER THE WORLD!!!!
Désolé.
:D
[...]
Ah oui ? Tu peux expliquer ? Je n'ai jamais utilisé ni l'un ni l'autre et pour moi conceptuellement, ils font la même chose. Aussi, si tu as des détails d'implémentation qui ont leur importance, je suis curieux !
Conceptuellement oui, après je ne suis pas rentré dans le code de l'un ou l'autre. Juste que le niveau d'intégration de hast est, à mon avis, mieux poussé que drdb (attention ceci n'est QUE mon avis pas du tout impartial, étant fan de FreeBSD).
Comment j'avais fait: en gros https://wiki.freebsd.org/HAST
Après j'avais fait quelque chose comme ça sans le iSCSI, mais ca donne un excellente idée : https://forums.freebsd.org/threads/failover-cluster-carp-lagg-hast-iscsi.383...
Les avantages de hast par rapport a drdb :
- solution maintenue par les mainteneurs de freebsd (hast, carp, zfs) - tout correctement fiabilisé (en général j'ai jamais eu de surprises avec les carp / zfs sur freebsd) - pas de patch à la con a gérer - commandes et scripts faciles.
Alors on peux parler de ucarp, c'est bien mais le seul pb de ucarp c'est qu'il fait un alias eth0:0 au lieu d'utiliser une adresse MAC carp. Ceci peut créer des emmerdes avec certains OS qui cachent (trop) les correspondances MAC -> IP.
/Xavier
Le Mon, May 18, 2015 at 03:06:56PM +0200, Xavier Beaudouin [kiwi@oav.net] a écrit: [... HAST c'est bon, mangez-en...]
Les avantages de hast par rapport a drdb :
- solution maintenue par les mainteneurs de freebsd (hast, carp, zfs)
- tout correctement fiabilisé (en général j'ai jamais eu de surprises
avec les carp / zfs sur freebsd)
- pas de patch à la con a gérer
Ça fait longtemps que drbd est intégré et distrbiué dans l'upstream, sans nécessiter de patch. Et la version "8" est stable.
- commandes et scripts faciles.
Ça je reconnais que drbdadm / drbdsetup, y'a de quoi perdre des poils de barbe...
Alors on peux parler de ucarp, c'est bien mais le seul pb de ucarp c'est qu'il fait un alias eth0:0 au lieu d'utiliser une adresse MAC carp. Ceci peut créer des emmerdes avec certains OS qui cachent (trop) les correspondances MAC -> IP.
Mais CARP, c'est pas HAST (et donc pas tout à fait dans le scope du fil).
Sur les FreeBSD qui font aussi du ZFS (hint ! hint !) il y a HAST.
Hast étant différent que DRBD, il donnera surement des choses plus "hum"... utiles que DRBD surtout au niveau des I/O car on sait bien que DRBD c'est bien mais ca tue les machines en I/O.
Après tu peux aussi coller du ZFS over HAST...
Personnellement j'avais fait du HAST pour synchro /var/db/mysql sur 2 VM et j'avais pas trop vu la différence au niveau perfs.
Après tu peux aussi ajouter du CARP + ifstated afin de relancer le bon deamon sans passer par une centrale nucléaire au niveau test Dead or Alive...
My 0,02€
</bsd>
Xavier
Bonjour,
HAST c’est super sur le papier et sur 2 VMs pour jouer. Dans les faits, si tu n’as pas deux machines avec reliées par du 10G, ça devient tout de suite très limité.
J’en ai en production, et ça pète régulièrement. On est en train de bouger sur une synchro rsync des volumes partagés (possibles parce que pas de gros fichiers binaires) toutes les 5 minutes.
Dans tous les cas, pour une sync un peu sérieuse entre deux DC, j’oublierais.
Mes 2c
-- Frederic de Villamil / @fdevillamil http://t37.net
Bonjour,
2015-05-12 22:37 GMT+02:00 olc olc@glou.fr:
On 12/05/2015 22:17, Julien Escario wrote:
Alors ocfs2, c'est une vraie usine à gaz et gluster j'ai de mauvais souvenirs en terme de stabilité. Ca date ceci dit, 2/3 ans.
Tututut, y'a rien de plus simple qu'ocfs2 (si t'as un SAN). Juste, c'est un peu fragile et le fait que ça fonctionne sans trop d'efforts rend l'adminsys faignant. Erreur. Et paf les datas.
Je suis tout à fait d'accord, Ocfs2 est *très* simple à mettre en oeuvre. Je l'utilise pour partager des gros fichiers (>100Go) entre deux serveurs. Le volume est sur un SAN iSCSI et ça marche sans aucun problème depuis un an.
Je m'étais penché sur DRBD et j'avais trouvé ça beaucoup plus complexe. Mais encore une fois je cherchais à partager un volume physique sur plusieurs machines.
Yop,
On 12/05/2015 20:11, Romain SIBILLE wrote:
Julien, as tu jeté un oeil du coté des "cluster file system" comme ceph, ocfs2 ou gluster?
Hmm .. C'est un peu trois solutions très différentes, mais c'est sans doute le but de ton mail d'ouvrir sur d'autres pistes.
D'une autre manière, c'était aussi un peu l'orientation de ma 1ère réponse : mais quel est donc le use case ? Ok, Julien dit qu'il veut faire un PoC sur le papier... et non, personne n'a sans doute testé le truc car il n'est a priori pas cohérent.
Cdlt,
Bonjour,
En effet, le but de mon intervention était de proposer d'autres axes de réflexion.
Je dois avouer que le message de Julien m'a aussitôt fait penser à ces technos.
Je précise cependant que je n'ai jamais testé ces solutions, je suis étudiant et mes tests se limitent à mettre en place quelques VMs pour voir comment cela fonctionne (donc ça vaut ce que ça vaut), et à lire les docs qui trainent ici et la.
Cordialement Romain
Le 12/05/2015 22:18, olc a écrit :
Yop,
On 12/05/2015 20:11, Romain SIBILLE wrote:
Julien, as tu jeté un oeil du coté des "cluster file system" comme ceph, ocfs2 ou gluster?
Hmm .. C'est un peu trois solutions très différentes, mais c'est sans doute le but de ton mail d'ouvrir sur d'autres pistes.
D'une autre manière, c'était aussi un peu l'orientation de ma 1ère réponse : mais quel est donc le use case ? Ok, Julien dit qu'il veut faire un PoC sur le papier... et non, personne n'a sans doute testé le truc car il n'est a priori pas cohérent.
Cdlt,
-
Benoit Garcia -
Damien MICHAUDET -
Dominique Rousseau -
Frederic de Villamil -
frsag＠jack.fr.eu.org -
Jean-Yves LENHOF -
Jeremie Le Hen -
Julien Escario -
olc -
Olivier DELHOMME -
Raphael Mazelier -
Romain SIBILLE -
Xavier Beaudouin -
Yacine Kheddache