D'abord, merci pour l'accueil que vous avez réservé à mes questions, et merci pour vos réponses.
En terme de volume, on sert une quinzaine de teras de données.
En terme de perfs, on est vraiment très tolérants. On ne mesure pas vraiment car le besoin n'existe pas.
En terme de RTO, j'avoue qu'on ne se pose pas vraiment la question en terme de délais, mais plus simplement, on souhaite automatiser au maximum de sorte à éviter toute intervention humaine lors du recovery.
D'où le choix du cluster actif/actif dès que possible, avec systématiquement du STONITH.
Pour l'instant, ce choix s'est avéré judicieux, et de nombreux crashs (dû à des facteurs externes - pannes elec, saturation réseau, erreurs humaines...) sont passés inaperçus aux users grâce à de tels mécanismes.
Au sujet de Gluster et du replica-3, il est en effet possible de désigner l'un des nœuds comme simple arbitrer : ce nœud se contentera de stocker les meta-données et jouera son rôle de juge de paix en cas de split-brain, mais il n'hébergera aucune données. L'un de nos clusters est construit ainsi, mais j'avoue ne l'avoir par torturé autant que notre cluster OCFS2 pour en dire autant de bien.
Je reste surpris que la clusterisation des serveurs de fichiers ne soit pas davantage systématique, et qu'on évoque des délais de restauration quand j'imaginais concentrer la question sur l'implémentation de solution active/active à base de logiciel libre.
Vos utilisateurs sont-ils plus tolérants que les miens ? (J'en doute)
[^] # Re: Essentiel
Posté par Nicolas Ecarnot (site web personnel) . En réponse au journal Système de fichiers clusterisé - OCFS2, GFS2, GlusterFS, autres. Évalué à 3.
Bonsoir,
D'abord, merci pour l'accueil que vous avez réservé à mes questions, et merci pour vos réponses.
En terme de volume, on sert une quinzaine de teras de données.
En terme de perfs, on est vraiment très tolérants. On ne mesure pas vraiment car le besoin n'existe pas.
En terme de RTO, j'avoue qu'on ne se pose pas vraiment la question en terme de délais, mais plus simplement, on souhaite automatiser au maximum de sorte à éviter toute intervention humaine lors du recovery.
D'où le choix du cluster actif/actif dès que possible, avec systématiquement du STONITH.
Pour l'instant, ce choix s'est avéré judicieux, et de nombreux crashs (dû à des facteurs externes - pannes elec, saturation réseau, erreurs humaines...) sont passés inaperçus aux users grâce à de tels mécanismes.
Au sujet de Gluster et du replica-3, il est en effet possible de désigner l'un des nœuds comme simple arbitrer : ce nœud se contentera de stocker les meta-données et jouera son rôle de juge de paix en cas de split-brain, mais il n'hébergera aucune données. L'un de nos clusters est construit ainsi, mais j'avoue ne l'avoir par torturé autant que notre cluster OCFS2 pour en dire autant de bien.
Je reste surpris que la clusterisation des serveurs de fichiers ne soit pas davantage systématique, et qu'on évoque des délais de restauration quand j'imaginais concentrer la question sur l'implémentation de solution active/active à base de logiciel libre.
Vos utilisateurs sont-ils plus tolérants que les miens ? (J'en doute)