Baisser le cout du stockage - grosse volumétries
Bonjour à tous, Je suis face à une problématique, que beaucoup aujourdhui doivent rencontrer. Dans ce monde hyperconnecté, on se retrouve souvent à gérer des grosses volumétries. Aujourdhui, nous sommes équipés avec des baies HPE 3PAR 7200 (SSD/FC/NL) et 8400 (Full SSD). Ces baies sont vraiment super, on en content du service. Cependant le cout du stockage au To est assez important. Cela allait tant quon gérait des quantités « Raisonnables » mais là dernièrement ceci explose et ça ne devrait pas sarrêter. Passage de 50To utiles à 200 en 3 ans. Si vous avez ce genre de réflexion, nhésitez pas ! Partager vos pensées et vos solutions pour faire face aux couts astronomiques du stockage. Bonne soirée à tous ! -- Bruno LEAL DE SOUSA Ingénieur Système et Infrastructure
Ceph On 09/10/2017 23:48, Bruno LEAL DE SOUSA wrote:
Bonjour à tous,
Je suis face à une problématique, que beaucoup aujourd’hui doivent rencontrer.
Dans ce monde hyperconnecté, on se retrouve souvent à gérer des grosses volumétries.
Aujourd’hui, nous sommes équipés avec des baies HPE 3PAR 7200 (SSD/FC/NL) et 8400 (Full SSD).
Ces baies sont vraiment super, on en content du service. Cependant le cout du stockage au To est assez important.
Cela allait tant qu’on gérait des quantités « Raisonnables » mais là dernièrement ceci explose et ça ne devrait pas s’arrêter. Passage de 50To utiles à 200 en 3 ans.
Si vous avez ce genre de réflexion, n’hésitez pas ! Partager vos pensées et vos solutions pour faire face aux couts astronomiques du stockage.
Bonne soirée à tous !
--
Bruno LEAL DE SOUSA
Ingénieur Système et Infrastructure
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
-- "UNIX was not designed to stop its users from doing stupid things, as that would also stop them from doing clever things." – Doug Gwyn
bonjour, peut être que gluster correspond plus à l'aspect stockage/coûts http://technologyadvice.com/blog/information-technology/ceph-vs-gluster/ Le 9 octobre 2017 23:48:35 GMT+02:00, Bruno LEAL DE SOUSA <bruno.ld.sousa@gmail.com> a écrit :
Bonjour à tous,
Je suis face à une problématique, que beaucoup aujourdhui doivent rencontrer.
Dans ce monde hyperconnecté, on se retrouve souvent à gérer des grosses volumétries.
Aujourdhui, nous sommes équipés avec des baies HPE 3PAR 7200 (SSD/FC/NL) et 8400 (Full SSD).
Ces baies sont vraiment super, on en content du service. Cependant le cout du stockage au To est assez important.
Cela allait tant quon gérait des quantités « Raisonnables » mais là dernièrement ceci explose et ça ne devrait pas sarrêter. Passage de 50To utiles à 200 en 3 ans.
Si vous avez ce genre de réflexion, nhésitez pas ! Partager vos pensées et vos solutions pour faire face aux couts astronomiques du stockage.
Bonne soirée à tous !
--
Bruno LEAL DE SOUSA
Ingénieur Système et Infrastructure
-- Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.
Salut la liste, Bien que nous ne soyons qu'une « petite » collectivité, la problématique est la même... Nos baies EMC (panachage SSD/HDD) rempli totalement son rôle mais pour un coût.... Nous avons donc acquis 2 petites baies Qnap et déportons dessus les datas les moins sensibles, typiquement le multimédia (souvent énorme et peu « important »). Ce n'est évidemment pas parfait, mais vu le prix d'une simple extension EMC notre système est rentabilisé... Bien sûr, il y a eu quelques sueurs froides lorsque le connecteur Iscsi d'une Qnap a disparu soudainement (« grâce » à l'intervention d'un collègue) mais rien n'a jamais disparu. Je ne suis pas la personne directement en charge de cette partie donc mes connaissances sont limitées, mais si quelqu'un veut d'autres précisions je pourrai les obtenir assez facilement. Bonne journée, (et bonne grève pour les concernés...) [Bruno Cortès] ü Pour la planète : échangez par courriel et n'imprimez que si nécessaire. De : FRsAG [mailto:frsag-bounces@frsag.org] De la part de Bruno LEAL DE SOUSA Envoyé : lundi 9 octobre 2017 23:49 À : frsag@frsag.org Objet : [FRsAG] Baisser le cout du stockage - grosse volumétries Bonjour à tous, Je suis face à une problématique, que beaucoup aujourd'hui doivent rencontrer. Dans ce monde hyperconnecté, on se retrouve souvent à gérer des grosses volumétries. Aujourd'hui, nous sommes équipés avec des baies HPE 3PAR 7200 (SSD/FC/NL) et 8400 (Full SSD). Ces baies sont vraiment super, on en content du service. Cependant le cout du stockage au To est assez important. Cela allait tant qu'on gérait des quantités « Raisonnables » mais là dernièrement ceci explose et ça ne devrait pas s'arrêter. Passage de 50To utiles à 200 en 3 ans. Si vous avez ce genre de réflexion, n'hésitez pas ! Partager vos pensées et vos solutions pour faire face aux couts astronomiques du stockage. Bonne soirée à tous ! -- Bruno LEAL DE SOUSA Ingénieur Système et Infrastructure
Bonjour tout le monde, Alors, personnellement, je dirais Ceph parce que c'est quand même le plus polyvalent et avec la nouvelle release de Red Hat Storage, on aura le nfs et bien d'autres choses dont j'ai hâte de pouvoir y mettre les mains dessus. Sinon, en vendor dans l'ère du temps, je partirais sur Infinidat. Excellente journée à tous
Bonjour,
Alors, personnellement, je dirais Ceph parce que c'est quand même le plus polyvalent et avec la nouvelle release de Red Hat Storage, on aura le nfs et bien d'autres choses dont j'ai hâte de pouvoir y mettre les mains dessus.
Sans forcément attendre la release de RedHat, on peut déjà jouer avec la dernière mouture Luminous (12.2.1) de Ceph, j'ai commencé un peu à tester et même si la peinture n'est pas fraiche, ça permet de prendre en main les nouvelles fonctionnalités. Je n’ai par contre pas encore tout regardé coté NFS (ils utilisent Ganesha), mais les 1èrs tests de passerelle entre la radosgw et NFS ne m'ont pas semblé concluant (erreur d'écriture par exemple), mais je ne sais pas si le problème vient de ma config ou de ceph lui-même J'ai par contre testé un peu plus CephFS (filesystem POSIX distribué) et ça me semble plus prometteur que faire du NFS. Pour mes tests, j'utilise le playbook ceph-ansible[1] pour déployer mon cluster. Il me faut moins de 2h pour avoir un cluster fonctionnel from scratch sur des serveurs barmetals (incluant application de script de reset bios/ipmi/config raid, installation ubuntu pxe kickstart, exécution du playbook ceph-ansible). J'utilise une Ubuntu 16.04 LTS. 1. https://github.com/ceph/ceph-ansible La communauté est assez réactive tant sur IRC (#ceph sur oftc) que sur la mailing-list d'ailleurs. Enfin, de l'expérience que j'ai de ceph, pour du block device (rados bloc device), ceph n'est pas le plus approprié si besoin de faible latence ou de beaucoup d'I/O en mono thread (ie un seul client) pour des workloads globales avec de la virtu, ça rend un bon service et c'est plutôt résilient. Bonne journée à tous -- Yoann Moulin linkedin.com/in/yoannmoulin twitter.com/ymoulin
Oui, le NFS est vraiment une solution "bancale" (c'est du NFS hein ...) : c'est probablement fonctionnel, mais vraiment dédié aux gens qui sont "bloqués" sur le NFS (pour des raisons d'OS propriétaire, de connecteur hardware ou que sais-je) Si tu as le choix, n'utilise pas NFS :) Par rapport à Ceph, je trouve que le projet est globalement conservateur Ils font du stockage, et sont sérieux en conséquence, contrairement à certains systèmes de fichier (zapperfs par exemple !) Ceph te permet également de faire des choses très charmante, telle qu'une redondance inter-dc sans coût (au niveau latence etc), permettant l'implémentation d'un PRA facilement J'aime également la méthode permettant, toujours sans impacter la production, de mixer disque dur et SSD (les clients utilisent les SSD, les disques dur ne sont utilisés qu'en arrière plan, pour la redondance, donc sans impact sur les performances) Bref, c'est vraiment un projet à tester et à retester, à mon avis ! On 10/10/2017 10:30, Yoann Moulin wrote:
Bonjour,
Alors, personnellement, je dirais Ceph parce que c'est quand même le plus polyvalent et avec la nouvelle release de Red Hat Storage, on aura le nfs et bien d'autres choses dont j'ai hâte de pouvoir y mettre les mains dessus.
Sans forcément attendre la release de RedHat, on peut déjà jouer avec la dernière mouture Luminous (12.2.1) de Ceph, j'ai commencé un peu à tester et même si la peinture n'est pas fraiche, ça permet de prendre en main les nouvelles fonctionnalités.
Je n’ai par contre pas encore tout regardé coté NFS (ils utilisent Ganesha), mais les 1èrs tests de passerelle entre la radosgw et NFS ne m'ont pas semblé concluant (erreur d'écriture par exemple), mais je ne sais pas si le problème vient de ma config ou de ceph lui-même
J'ai par contre testé un peu plus CephFS (filesystem POSIX distribué) et ça me semble plus prometteur que faire du NFS.
Pour mes tests, j'utilise le playbook ceph-ansible[1] pour déployer mon cluster. Il me faut moins de 2h pour avoir un cluster fonctionnel from scratch sur des serveurs barmetals (incluant application de script de reset bios/ipmi/config raid, installation ubuntu pxe kickstart, exécution du playbook ceph-ansible). J'utilise une Ubuntu 16.04 LTS.
1. https://github.com/ceph/ceph-ansible
La communauté est assez réactive tant sur IRC (#ceph sur oftc) que sur la mailing-list d'ailleurs.
Enfin, de l'expérience que j'ai de ceph, pour du block device (rados bloc device), ceph n'est pas le plus approprié si besoin de faible latence ou de beaucoup d'I/O en mono thread (ie un seul client) pour des workloads globales avec de la virtu, ça rend un bon service et c'est plutôt résilient.
Bonne journée à tous
-- "UNIX was not designed to stop its users from doing stupid things, as that would also stop them from doing clever things." – Doug Gwyn
Bonjour, On 10/10/2017 10:37 AM, frsag@jack.fr.eu.org wrote:
Ceph te permet également de faire des choses très charmante, telle qu'une redondance inter-dc sans coût (au niveau latence etc), permettant l'implémentation d'un PRA facilement
Tu penses à la fonctionnalité ajoutée « récemment » (un daemon supplémentaire dont j'ai oublié le nom) qui est valable pour le rados block device _uniquement_, c'est bien ça ?
J'aime également la méthode permettant, toujours sans impacter la production, de mixer disque dur et SSD (les clients utilisent les SSD, les disques dur ne sont utilisés qu'en arrière plan, pour la redondance, donc sans impact sur les performances)
Fichtre alors, là je vois pas trop quelle fonctionnalité de ceph permet cela ? Je connais la notion de « primary affinity » par exemple qui permet des trucs comme ça via la CRUSH map mais c'est juste valable pour la lecture, pas pour l'écriture. -- François Lafont
On 10/10/2017 11:09, Francois Lafont wrote:
Bonjour,
On 10/10/2017 10:37 AM, frsag@jack.fr.eu.org wrote:
Ceph te permet également de faire des choses très charmante, telle qu'une redondance inter-dc sans coût (au niveau latence etc), permettant l'implémentation d'un PRA facilement
Tu penses à la fonctionnalité ajoutée « récemment » (un daemon supplémentaire dont j'ai oublié le nom) qui est valable pour le rados block device _uniquement_, c'est bien ça ? Pas vraiment, je pense plutôt à min_size pour l'écriture, et affinity pour la lecture
J'aime également la méthode permettant, toujours sans impacter la production, de mixer disque dur et SSD (les clients utilisent les SSD, les disques dur ne sont utilisés qu'en arrière plan, pour la redondance, donc sans impact sur les performances)
Fichtre alors, là je vois pas trop quelle fonctionnalité de ceph permet cela ? Je connais la notion de « primary affinity » par exemple qui permet des trucs comme ça via la CRUSH map mais c'est juste valable pour la lecture, pas pour l'écriture.
Pour moi, c'est la même chose Dans la mesure où tu as X size et Y min_size, même si la différence entre Y et X est "loin" (autre DC, stockage lent, etc), cela n'a aucune importance : lorsque les Y replica seront validés (et donc, sur les SSD / sur le DC proche), l'écriture sera acquittée Me tromperai-je ? -- "UNIX was not designed to stop its users from doing stupid things, as that would also stop them from doing clever things." – Doug Gwyn
On 10/10/2017 11:28 AM, frsag@jack.fr.eu.org wrote:
Pas vraiment, je pense plutôt à min_size pour l'écriture, et affinity pour la lecture
Ok pour la priority affinity par rapport à la lecture uniquement en effet. Mais par contre je suis pas d'accord pour le min_size qui, pour ce que j'ai compris de Ceph, n'a pas de rapport avec la redondance inter-dc. Pour moi, le min_size d'un pool en mode réplication c'est juste le nombre minimum de replicas en dessous duquel une écriture est impossible. En clair, si tu as un pool avec size == 3 (3 réplications de chaque objet stocké) et un min_size égal à 2, si un client ceph doit écrire dans le pool mais que l'écriture ne peut se faire que sur 1 seul OSD (car par exemple les 2 autres sont down à ce moment là), alors l'I/O est bloquée. Pour moi c'est tout ce que fait min_size.
Pour moi, c'est la même chose Dans la mesure où tu as X size et Y min_size, même si la différence entre Y et X est "loin" (autre DC, stockage lent, etc), cela n'a aucune importance : lorsque les Y replica seront validés (et donc, sur les SSD / sur le DC proche), l'écriture sera acquittée
Me tromperai-je ?
Pour moi oui mais ton expression « la différence entre Y et X est "loin" » me met le doute (j'ai l'impression qu'on ne parle pas du tout de la même chose du coup). Pour moi size et min_size, c'est ce que tu définis sur un replicated pool avec la commande : ceph osd pool set poolname size 3 ceph osd pool set poolname min_size 2 Dans le cas ci-dessus : * Une écriture d'un objet sera faite en 3 exemplaires (3 réplicas) a priori sur 3 OSD distincts. * Si les 3 OSDs sont UP, lors d'une écriture, un client sera acquittée uniquement lorsque l'écriture s'est faite sur les 3 OSDs, pas avant. * Pas d'acquittement d'écriture au client si seulement 0 ou 1 OSD peut écrire l'objet, par contre avec 2 OSDs ça passera. Voilà, pour moi c'est comme ça que ça fonctionne sur des replicated pool et il n'est pas question de topologie ici (OSD dans un DC, OSD SSD etc). Je suis relativement sûr que ça fonctionnait comme ça il y a 1 an ou 2 (car c'est à ce moment là que j'ai un peu creusé la question) mais peut-être que depuis les choses ont changé. J'espère ne pas avoir dit trop de bêtises. Je serais heureux qu'on me rectifie si c'est le cas. -- François Lafont
Est-ce que vous vous êtes penché du coté de la déduplication? Je sais que ZFS le fait, Windows Server également. Mais coté constructeur je ne sais pas s'il existe des solutions. Sont-elles fiables? Qu'en est-il des performances?
Hello,
Est-ce que vous vous êtes penché du coté de la déduplication? Je sais que ZFS le fait, Windows Server également. Mais coté constructeur je ne sais pas s'il existe des solutions. Sont-elles fiables? Qu'en est-il des performances?
Netapp et Isilon le fait... Après les perfs elles sont là si tu as un bon portefeuille.... (Ce qui ne fait pas baisser le coût du stockage IMHO). Ceci dit, la question n'est pas le coût du stockage mais le coût de tes données. Comprendre est-ce que tu es prêt a perdre l'accès a ton stockage pour 1 journée ou pas... (dans le "ou pas" alors penses que tu ne baissera pas le coût, jamais... jamais, jamais)... Voila :) Xavier
Bonsoir à tous! Je suis épaté par les nombreuses réponses reçues. Cela prouve bien que le sujet est une vraie problèmatique de nos jours. Si je résume vaguement les réponses, beaucoup tendent vers des solutions open-source et notamment Ceph, Gluster et Openio. C'est toutes des bonnes solutions mais nous sommes dans un industrie qui a besoin de tourner H24. Les solutions comme Ceph semblent demander pas mal de compétences et maîtrise et peuvent devenir complexe dans l'usage au quotidien. Nous avons commencé à regarder pour des solutions du commerce comme des Nas Synology haute performance ou encore l'utilisation de la virtualisation du stockage avec Datacore. En tout merci à tous pour ce partage. Bonne journée. Bruno LEAL DE SOUSA Le 10 oct. 2017 21:53, "Xavier Beaudouin" <kiwi@oav.net> a écrit :
Hello,
Est-ce que vous vous êtes penché du coté de la déduplication? Je sais que ZFS le fait, Windows Server également. Mais coté constructeur je ne sais pas s'il existe des solutions. Sont-elles fiables? Qu'en est-il des performances?
Netapp et Isilon le fait... Après les perfs elles sont là si tu as un bon portefeuille.... (Ce qui ne fait pas baisser le coût du stockage IMHO).
Ceci dit, la question n'est pas le coût du stockage mais le coût de tes données. Comprendre est-ce que tu es prêt a perdre l'accès a ton stockage pour 1 journée ou pas... (dans le "ou pas" alors penses que tu ne baissera pas le coût, jamais... jamais, jamais)...
Voila :) Xavier _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
mercredi 11 octobre 2017, 13:30:30 CEST Bruno LEAL DE SOUSA wrote:
C'est toutes des bonnes solutions mais nous sommes dans un industrie qui a besoin de tourner H24.
Je ne vois pas pourquoi vous mettez un « mais ». Le libre fait tourner plus de la moitié des serveurs web des sites les plus vus au monde, ils ne font pas ça 12h sur 24, mais bien h24. Et je ne parle que des serveurs web, je ne parle pas des mails, des bases de données, etc. Je ne vois pas en quoi des solutions libres ne seraient pas compatibles avec une nécessité de haute disponibilité. Vous devriez pouvoir trouver une entreprise qui vous fournira le support h24 sur du libre. Amicalement, -- Luc https://fiat-tux.fr/ https://luc.frama.io/ Internet n'est pas compliqué, Internet est ce que vous en faites.
Oui Si tu as 3 disques dur, et 2 SSD, un size = 3 et min_size = 2, et une map cohérente, l'écriture va se faire sur les 2 SSD et sur un disque dur Lorsque deux écritures seront validés, l'IO sera valider Une timeline: t: début de l'IO t + 1: écriture sous-jacente sur SSD1, SSD2 et HDD1 t + 2: SSD1 ack, SSD2 ack, HDD1 travaille encore, l'IO est validé au client t + 3: HDD1 ack (mais à ce niveau, le client est déjà parti, ce n'est plus que de la réplication) Autrement dit, dans ce cas, tes performances en écriture sont directement relié à tes min_size OSD les plus performants On 10/10/2017 21:31, Francois Lafont wrote:
On 10/10/2017 11:28 AM, frsag@jack.fr.eu.org wrote:
Pas vraiment, je pense plutôt à min_size pour l'écriture, et affinity pour la lecture
Ok pour la priority affinity par rapport à la lecture uniquement en effet.
Mais par contre je suis pas d'accord pour le min_size qui, pour ce que j'ai compris de Ceph, n'a pas de rapport avec la redondance inter-dc.
Pour moi, le min_size d'un pool en mode réplication c'est juste le nombre minimum de replicas en dessous duquel une écriture est impossible. En clair, si tu as un pool avec size == 3 (3 réplications de chaque objet stocké) et un min_size égal à 2, si un client ceph doit écrire dans le pool mais que l'écriture ne peut se faire que sur 1 seul OSD (car par exemple les 2 autres sont down à ce moment là), alors l'I/O est bloquée. Pour moi c'est tout ce que fait min_size.
Pour moi, c'est la même chose Dans la mesure où tu as X size et Y min_size, même si la différence entre Y et X est "loin" (autre DC, stockage lent, etc), cela n'a aucune importance : lorsque les Y replica seront validés (et donc, sur les SSD / sur le DC proche), l'écriture sera acquittée
Me tromperai-je ?
Pour moi oui mais ton expression « la différence entre Y et X est "loin" » me met le doute (j'ai l'impression qu'on ne parle pas du tout de la même chose du coup).
Pour moi size et min_size, c'est ce que tu définis sur un replicated pool avec la commande :
ceph osd pool set poolname size 3 ceph osd pool set poolname min_size 2
Dans le cas ci-dessus :
* Une écriture d'un objet sera faite en 3 exemplaires (3 réplicas) a priori sur 3 OSD distincts. * Si les 3 OSDs sont UP, lors d'une écriture, un client sera acquittée uniquement lorsque l'écriture s'est faite sur les 3 OSDs, pas avant. * Pas d'acquittement d'écriture au client si seulement 0 ou 1 OSD peut écrire l'objet, par contre avec 2 OSDs ça passera.
Voilà, pour moi c'est comme ça que ça fonctionne sur des replicated pool et il n'est pas question de topologie ici (OSD dans un DC, OSD SSD etc). Je suis relativement sûr que ça fonctionnait comme ça il y a 1 an ou 2 (car c'est à ce moment là que j'ai un peu creusé la question) mais peut-être que depuis les choses ont changé.
J'espère ne pas avoir dit trop de bêtises. Je serais heureux qu'on me rectifie si c'est le cas.
-- "UNIX was not designed to stop its users from doing stupid things, as that would also stop them from doing clever things." – Doug Gwyn
Hello,
Pas vraiment, je pense plutôt à min_size pour l'écriture, et affinity pour la lecture
Ok pour la priority affinity par rapport à la lecture uniquement en effet.
Mais par contre je suis pas d'accord pour le min_size qui, pour ce que j'ai compris de Ceph, n'a pas de rapport avec la redondance inter-dc.
Pour moi, le min_size d'un pool en mode réplication c'est juste le nombre minimum de replicas en dessous duquel une écriture est impossible. En clair, si tu as un pool avec size == 3 (3 réplications de chaque objet stocké) et un min_size égal à 2, si un client ceph doit écrire dans le pool mais que l'écriture ne peut se faire que sur 1 seul OSD (car par exemple les 2 autres sont down à ce moment là), alors l'I/O est bloquée. Pour moi c'est tout ce que fait min_size.
Pour moi, c'est la même chose Dans la mesure où tu as X size et Y min_size, même si la différence entre Y et X est "loin" (autre DC, stockage lent, etc), cela n'a aucune importance : lorsque les Y replica seront validés (et donc, sur les SSD / sur le DC proche), l'écriture sera acquittée
Me tromperai-je ?
Pour moi oui mais ton expression « la différence entre Y et X est "loin" » me met le doute (j'ai l'impression qu'on ne parle pas du tout de la même chose du coup).
Pour moi size et min_size, c'est ce que tu définis sur un replicated pool avec la commande :
ceph osd pool set poolname size 3 ceph osd pool set poolname min_size 2
Dans le cas ci-dessus :
* Une écriture d'un objet sera faite en 3 exemplaires (3 réplicas) a priori sur 3 OSD distincts. * Si les 3 OSDs sont UP, lors d'une écriture, un client sera acquittée uniquement lorsque l'écriture s'est faite sur les 3 OSDs, pas avant. * Pas d'acquittement d'écriture au client si seulement 0 ou 1 OSD peut écrire l'objet, par contre avec 2 OSDs ça passera.
Voilà, pour moi c'est comme ça que ça fonctionne sur des replicated pool et il n'est pas question de topologie ici (OSD dans un DC, OSD SSD etc). Je suis relativement sûr que ça fonctionnait comme ça il y a 1 an ou 2 (car c'est à ce moment là que j'ai un peu creusé la question) mais peut-être que depuis les choses ont changé.
J'espère ne pas avoir dit trop de bêtises. Je serais heureux qu'on me rectifie si c'est le cas.
Oui
Si tu as 3 disques dur, et 2 SSD, un size = 3 et min_size = 2, et une map cohérente, l'écriture va se faire sur les 2 SSD et sur un disque dur Lorsque deux écritures seront validés, l'IO sera valider
Une timeline: t: début de l'IO t + 1: écriture sous-jacente sur SSD1, SSD2 et HDD1 t + 2: SSD1 ack, SSD2 ack, HDD1 travaille encore, l'IO est validé au client t + 3: HDD1 ack (mais à ce niveau, le client est déjà parti, ce n'est plus que de la réplication)
Autrement dit, dans ce cas, tes performances en écriture sont directement relié à tes min_size OSD les plus performants
ce n'est pas ma compréhension du min_size, je n'ai jamais entendu parlé de ce coté « optimisation des écritures » (ça ne veut pas dire que c'est faux hein), mais pour moi ça permet de choisir le niveau de résilience, de disponibilité et d'intégrité, j'aurais donc plutôt la compréhension de François pour le coup size = nombre de replica de l'objet (et il faut le ACK de TOUS les journaux pour valider une écriture et pas seulement le min_size) min_size = nombre minimum de replica online pour fournir la donnée si on a size=3 min_size=1 il faut un seul replica online pour accéder à la donnée (avec les risques que ça a d'avoir un réplica) => disponibilité plus grande, mais risque de perte d'intégrité plus grande si on a size=3 min_size=2 si on perd un replica, la donnée est disponible, si on en perd 2, on ne peut plus accéder aux données, le cluster bloque les I/O jusqu'a ce qu'un autre replica revienne online. => disponibilité moindre, mais une plus grande protection de l'intégrité des données. http://docs.ceph.com/docs/master/rados/operations/pools/ min_size description: Sets the minimum number of replicas required for I/O. See Set the Number of Object Replicas for further details. Replicated pools only. bonne soirée -- Yoann Moulin linkedin.com/in/yoannmoulin twitter.com/ymoulin
On 10/10/2017 11:36 PM, Yoann Moulin wrote:
si on a size=3 min_size=2 si on perd un replica, la donnée est disponible, si on en perd 2, on ne peut plus accéder aux données, le cluster bloque les I/O jusqu'a ce qu'un autre replica revienne online.
J'aurais tendance à penser que, dans ce cas, seules les écritures sont bloquées mais la lecture reste encore possible. Bon, sur ce point pour le coup je suis largement moins sûr de moi. -- François Lafont
Au temps pour moi, je pensais que c'était plus subtil mais en fait non Merci pour la précision, je vais pouvoir arrêter de penser (et raconter) de la derm à ce sujet :p /me est un peu déçu néanmoins On 10/10/2017 23:58, Francois Lafont wrote:
On 10/10/2017 11:36 PM, Yoann Moulin wrote:
si on a size=3 min_size=2 si on perd un replica, la donnée est disponible, si on en perd 2, on ne peut plus accéder aux données, le cluster bloque les I/O jusqu'a ce qu'un autre replica revienne online.
J'aurais tendance à penser que, dans ce cas, seules les écritures sont bloquées mais la lecture reste encore possible. Bon, sur ce point pour le coup je suis largement moins sûr de moi.
-- "UNIX was not designed to stop its users from doing stupid things, as that would also stop them from doing clever things." – Doug Gwyn
Hello, J'avoue je n'ai pas pris le temps de lire le thread mais j'ai retenu "baisser le coût du stockage" et "CEPH". Je vous propose de regarder la solution développée par des copains : http://www.openio.io/ C'est opensource, il y a des options soumises à licence comme la GUI. Il y a eu un summit semaine dernière chez eux pour l'inauguration de leurs nouveaux locaux. J'y ai notamment écouté Solvik Bum qui a expliqué comment Teezily devrait à terme économiser 400 k€ en stockant ses données sur un OpenIO chez Online plutôt que chez AWS S3. Il semble que la raison pour laquelle Dailymotion les a choisi était d'avantage l’hétérogénéité matérielle et l'ouverture des APIs. Bref, si ça peut aider au débat. OpenIO, c'est à Hem, à côté de Lille. A bientôt, Le 11 octobre 2017 à 14:36, <frsag@jack.fr.eu.org> a écrit :
Au temps pour moi, je pensais que c'était plus subtil mais en fait non
Merci pour la précision, je vais pouvoir arrêter de penser (et raconter) de la derm à ce sujet :p
/me est un peu déçu néanmoins
On 10/10/2017 23:58, Francois Lafont wrote:
On 10/10/2017 11:36 PM, Yoann Moulin wrote:
si on a size=3 min_size=2 si on perd un replica, la donnée est disponible, si on en perd 2, on ne peut plus accéder aux données, le cluster bloque les I/O jusqu'a ce qu'un autre replica revienne online.
J'aurais tendance à penser que, dans ce cas, seules les écritures sont bloquées mais la lecture reste encore possible. Bon, sur ce point pour le coup je suis largement moins sûr de moi.
-- "UNIX was not designed to stop its users from doing stupid things, as that would also stop them from doing clever things." – Doug Gwyn _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
-- Olivier Duquesne aka DaffyDuke http://www.coincoin.fr.eu.org
Eh je l'ai évoqué en prems =) et les deux réference sont bien Daily et Online, dont les ops sont des gens à qui je confierais mon infra, c'est dire que je les truste. -- Raphael Mazelier On 11/10/2017 21:57, Olivier Duquesne (DaffyDuke) wrote:
Hello,
J'avoue je n'ai pas pris le temps de lire le thread mais j'ai retenu "baisser le coût du stockage" et "CEPH". Je vous propose de regarder la solution développée par des copains : http://www.openio.io/ C'est opensource, il y a des options soumises à licence comme la GUI. Il y a eu un summit semaine dernière chez eux pour l'inauguration de leurs nouveaux locaux. J'y ai notamment écouté Solvik Bum qui a expliqué comment Teezily devrait à terme économiser 400 k€ en stockant ses données sur un OpenIO chez Online plutôt que chez AWS S3. Il semble que la raison pour laquelle Dailymotion les a choisi était d'avantage l’hétérogénéité matérielle et l'ouverture des APIs.
Bref, si ça peut aider au débat. OpenIO, c'est à Hem, à côté de Lille.
-
Ah oui, du coup j'ai lu au moins le tiens. Pareil, totale confiance dans les admins d'openio, mais je suis pas objectif, on a passé pas mal de temps ensemble il y a quelques années sur un petit hébergeur de mails (50 millions de boîtes mails en 2010). C'est de là qu'est venu le projet d'ailleurs. Ça me fait penser que j'avais promis de les inviter ici et que je ne l'ai pas encore fait.... Le jeu. 12 oct. 2017 21:14, Raphael Mazelier <raph@futomaki.net> a écrit :
Eh je l'ai évoqué en prems =)
et les deux réference sont bien Daily et Online, dont les ops sont des gens à qui je confierais mon infra, c'est dire que je les truste.
--
Raphael Mazelier
On 11/10/2017 21:57, Olivier Duquesne (DaffyDuke) wrote:
Hello,
J'avoue je n'ai pas pris le temps de lire le thread mais j'ai retenu "baisser le coût du stockage" et "CEPH". Je vous propose de regarder la solution développée par des copains : http://www.openio.io/ C'est opensource, il y a des options soumises à licence comme la GUI. Il y a eu un summit semaine dernière chez eux pour l'inauguration de leurs nouveaux locaux. J'y ai notamment écouté Solvik Bum qui a expliqué comment Teezily devrait à terme économiser 400 k€ en stockant ses données sur un OpenIO chez Online plutôt que chez AWS S3. Il semble que la raison pour laquelle Dailymotion les a choisi était d'avantage l’hétérogénéité matérielle et l'ouverture des APIs.
Bref, si ça peut aider au débat. OpenIO, c'est à Hem, à côté de Lille.
- _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
-- Oliver Duquesne aka DaffyDuke http://www.coincoin.fr.eu.org Excusez les éventuelles erreurs, ce message a été envoyé depuis un mobile.
On 12/10/2017 21:20, Olivier Duquesne (DaffyDuke) wrote:
Ah oui, du coup j'ai lu au moins le tiens. Pareil, totale confiance dans les admins d'openio, mais je suis pas objectif, on a passé pas mal de temps ensemble il y a quelques années sur un petit hébergeur de mails (50 millions de boîtes mails en 2010). C'est de là qu'est venu le projet d'ailleurs.
50 millions de mailbox, ce n'est pas vraiment un "petit" hébergeur. Fabien
2017-10-12 21:26 GMT+02:00 Fabien Germain <fabien@klipz.fr>:
On 12/10/2017 21:20, Olivier Duquesne (DaffyDuke) wrote:
Ah oui, du coup j'ai lu au moins le tiens. Pareil, totale confiance dans les admins d'openio, mais je suis pas objectif, on a passé pas mal de temps ensemble il y a quelques années sur un petit hébergeur de mails (50 millions de boîtes mails en 2010). C'est de là qu'est venu le projet d'ailleurs.
50 millions de mailbox, ce n'est pas vraiment un "petit" hébergeur.
#ironie, non ? :) Et pour préciser ce qu'évoque Fabien, Openio provient d'un dev interne chez Atos Worldline qui a été opensourcé ensuite. Et Atos est connu pour gérer (ou avoir géré, j'ai pas suivi récemment si c'est toujours le cas) toute la plateforme email de Wanadoo/Orange. Donc oui, ils avaient "quelques" mailbox à gérer. Openio raconte un peu ça sur leur doc : http://docs.openio.io/arch-design/team.html -- Florent
:)
Et pour préciser ce qu'évoque Fabien, Openio provient d'un dev interne chez Atos Worldline qui a été opensourcé ensuite. Et Atos est connu pour gérer (ou avoir géré, j'ai pas suivi récemment si c'est toujours le cas) toute la plateforme email de Wanadoo/Orange. Donc oui, ils avaient "quelques" mailbox à gérer.
Openio raconte un peu ça sur leur doc : http://docs.openio.io/arch-design/team.html
C'est d'autant plus intérresssant que cela stockait des millions de petits objets ce qui est toujours plus difficile que de stocker des gros chunks. -- Raphael Mazelier
On 10/10/2017 10:34 PM, frsag@jack.fr.eu.org wrote:
Si tu as 3 disques dur, et 2 SSD, un size = 3 et min_size = 2, et une map cohérente, l'écriture va se faire sur les 2 SSD et sur un disque dur
On peut en effet cibler les OSDs (les disques) pour un pool donné avec la CRUSH map, ça on est d'accord.
Lorsque deux écritures seront validés, l'IO sera valider
Une timeline: t: début de l'IO t + 1: écriture sous-jacente sur SSD1, SSD2 et HDD1 t + 2: SSD1 ack, SSD2 ack, HDD1 travaille encore, l'IO est validé au client
Pas d'accord sur ce dernier point (t+2). Le min_size ne signifie pas que l'IO sera acquitté au bout de <min_size> acks sur les OSDs (ie les disques pour être clair). Ceci est faux à mon humble avis. Pour moi, ton client ne sera acquitté de l'IO _que_ lorsque tu auras un ack de SSD1, SSD2 _et_ _aussi_ de HDD1, pas avant.
t + 3: HDD1 ack (mais à ce niveau, le client est déjà parti, ce n'est plus que de la réplication)
Autrement dit, dans ce cas, tes performances en écriture sont directement relié à tes min_size OSD les plus performants
Pour moi c'est une « légende urbaine » sur le paramètre min_size. Regarde le schéma juste au _dessus_ de ce lien : http://docs.ceph.com/docs/master/architecture/#dynamic-cluster-management Tu pourras constater que le ack envoyé au client se produit seulement une fois l'écriture faite les 3 OSDs (l'OSD primaire, celui avec qui le client est en contact direct, et les OSDs secondaires). « The client writes the object to the identified placement group in the primary OSD. Then, the primary OSD with its own copy of the CRUSH map identifies the secondary and tertiary OSDs for replication purposes, and replicates the object to the appropriate placement groups in the secondary and tertiary OSDs (as many OSDs as additional replicas), and responds to the client once it has confirmed the object was stored successfully. » Le paramètre min_size ne change rien à cela. Comme je disais dans mon message précédent, il t'assure seulement qu'en mode dégradé (ie quand tous les OSDs ne sont pas UP) aucune écriture ne sera possible s'il n'y a pas au moins <min_size> ODS(s) UP. C'est tout. -- François Lafont
Salut. Vu que tout le monde parle de CEPH, GlusterFS et autres joyeuseries, je pars sur un autre axe. Ayant bossé sur du HP pendant assez longtemps pour savoir qu'au niveau stockage, leur rapport qualité/prix n'est pas le meilleur existant (sauf si les disques sont en or massif livrés dans un étui en peau de couilles). Les technos libres/gratuites sont sympa pour bricoler, mais montrent leurs limites et nécessitent beaucoup de temps (j'ai bossé sur du ceph et du glusterfs, et clairement, ça ne prend pas 5 mins). De plus, ça nécessite du matériel, dont le coût n'est jamais neutre. As-tu eu l'occasion de faire le tour des grands noms du stockage, genre NetAPP, EMC, etc... ?? Tu as aussi toutes les solutions de "Software defined storage" (nom très hype pour dire "on rebrand une *BSD avec du ZFS et une zolie interface web") comme DataCore, qui peut t'éviter le passage par les grands constructeurs qui ne seront pas neutres au niveau coût, et tu pourrais limite réutiliser ton matos actuel après migration. J'avais eu l'occasion de monter Datacore sur un POC avec des clés USB et plusieurs hubs USB sur un laptop, donc voilà, ça prend n'importe quel type de techno de stockage, tant qu'on lui présente un truc qu'il supporte (blocs et NFS à l'époque), et il se débrouille et fait sa tambouille pour te fournir un LUN, un partage NFS/CIFS, ou autre. Merci. From: "Bruno LEAL DE SOUSA" <bruno.ld.sousa@gmail.com> To: "French SysAdmin Group" <frsag@frsag.org> Sent: Monday, 9 October, 2017 23:48:35 Subject: [FRsAG] Baisser le cout du stockage - grosse volumétries Bonjour à tous, Je suis face à une problématique, que beaucoup aujourd’hui doivent rencontrer. Dans ce monde hyperconnecté, on se retrouve souvent à gérer des grosses volumétries. Aujourd’hui, nous sommes équipés avec des baies HPE 3PAR 7200 (SSD/FC/NL) et 8400 (Full SSD). Ces baies sont vraiment super, on en content du service. Cependant le cout du stockage au To est assez important. Cela allait tant qu’on gérait des quantités « Raisonnables » mais là dernièrement ceci explose et ça ne devrait pas s’arrêter. Passage de 50To utiles à 200 en 3 ans. Si vous avez ce genre de réflexion, n’hésitez pas ! Partager vos pensées et vos solutions pour faire face aux couts astronomiques du stockage. Bonne soirée à tous ! -- Bruno LEAL DE SOUSA Ingénieur Système et Infrastructure _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/ -- Cyril Lavier
Je ne sais pas si ça répond au besoin ou aux performances demandées par Bruno mais je n'ai jamais eu à me plaindre de FreeNAS. Il me semble qu'il y a de nombreuses archis déployées de plusieurs dizaines de TB utilisant FreeNAS et des baies HBA/JBOD. Je vais peut-être me faire atomiser, mais on m'a dit aussi que la solution Microsoft de storage sur des baies HBA fonctionnait très très bien :) Le 10 oct. 2017 à 15:00, Cyril Lavier a écrit :
Salut.
Vu que tout le monde parle de CEPH, GlusterFS et autres joyeuseries, je pars sur un autre axe.
Ayant bossé sur du HP pendant assez longtemps pour savoir qu'au niveau stockage, leur rapport qualité/prix n'est pas le meilleur existant (sauf si les disques sont en or massif livrés dans un étui en peau de couilles).
Les technos libres/gratuites sont sympa pour bricoler, mais montrent leurs limites et nécessitent beaucoup de temps (j'ai bossé sur du ceph et du glusterfs, et clairement, ça ne prend pas 5 mins). De plus, ça nécessite du matériel, dont le coût n'est jamais neutre.
As-tu eu l'occasion de faire le tour des grands noms du stockage, genre NetAPP, EMC, etc... ??
Tu as aussi toutes les solutions de "Software defined storage" (nom très hype pour dire "on rebrand une *BSD avec du ZFS et une zolie interface web") comme DataCore, qui peut t'éviter le passage par les grands constructeurs qui ne seront pas neutres au niveau coût, et tu pourrais limite réutiliser ton matos actuel après migration.
J'avais eu l'occasion de monter Datacore sur un POC avec des clés USB et plusieurs hubs USB sur un laptop, donc voilà, ça prend n'importe quel type de techno de stockage, tant qu'on lui présente un truc qu'il supporte (blocs et NFS à l'époque), et il se débrouille et fait sa tambouille pour te fournir un LUN, un partage NFS/CIFS, ou autre.
Merci.
From: "Bruno LEAL DE SOUSA" <bruno.ld.sousa@gmail.com> To: "French SysAdmin Group" <frsag@frsag.org> Sent: Monday, 9 October, 2017 23:48:35 Subject: [FRsAG] Baisser le cout du stockage - grosse volumétries
Bonjour à tous,
Je suis face à une problématique, que beaucoup aujourd’hui doivent rencontrer. Dans ce monde hyperconnecté, on se retrouve souvent à gérer des grosses volumétries.
Aujourd’hui, nous sommes équipés avec des baies HPE 3PAR 7200 (SSD/FC/NL) et 8400 (Full SSD). Ces baies sont vraiment super, on en content du service. Cependant le cout du stockage au To est assez important. Cela allait tant qu’on gérait des quantités « Raisonnables » mais là dernièrement ceci explose et ça ne devrait pas s’arrêter. Passage de 50To utiles à 200 en 3 ans.
Si vous avez ce genre de réflexion, n’hésitez pas ! Partager vos pensées et vos solutions pour faire face aux couts astronomiques du stockage.
Bonne soirée à tous !
-- Bruno LEAL DE SOUSA Ingénieur Système et Infrastructure
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
-- Cyril Lavier _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Très vaste sujet que le stockage de nos jours. Un des vrais points de départ qu'il faut trancher c'est a t'on besoin d'un accès type fs, ou un accès type s3/objet suffit. Cela oriente réellement le choix, sachant que de nos jours "l'interface" s3 est le nouveau standard de facto. Quelques retour d'expérience : * datacore san symfony : très bon souvenir, meme si ce n'est plus trop dans la tendance actuelle, car cela présente "juste" du bloc en iscsi fiber. Mais c'est rock solid. En revanche le pricing était complexe (lié à la volumétrie). * scality pour de l'object store (et plus meme si c'est moins bon) : excellent. On a un petit cluster (1.2Po), et ca juste marche. Bon support, prix ok. Des innovations (connecteurs S3, couche d'abstraction S3 multi provider : zenko). Bref je recommande. * openio : concurrent opensource de scality (meme si le support existe et est bon). Très bon retour, beaucoup de camarades recommandent. En moins bon : * ceph : ca marche, mais je trouve personnelement que c'est relativement complexe à administrer. * isilon : emc a tué le produit, qui est devenu complexe, hors de prix avec un support médiocre. -- Raphael Mazelier On 10/10/2017 15:00, Cyril Lavier wrote:
Salut.
Vu que tout le monde parle de CEPH, GlusterFS et autres joyeuseries, je pars sur un autre axe.
Ayant bossé sur du HP pendant assez longtemps pour savoir qu'au niveau stockage, leur rapport qualité/prix n'est pas le meilleur existant (sauf si les disques sont en or massif livrés dans un étui en peau de couilles).
Les technos libres/gratuites sont sympa pour bricoler, mais montrent leurs limites et nécessitent beaucoup de temps (j'ai bossé sur du ceph et du glusterfs, et clairement, ça ne prend pas 5 mins). De plus, ça nécessite du matériel, dont le coût n'est jamais neutre.
As-tu eu l'occasion de faire le tour des grands noms du stockage, genre NetAPP, EMC, etc... ??
Tu as aussi toutes les solutions de "Software defined storage" (nom très hype pour dire "on rebrand une *BSD avec du ZFS et une zolie interface web") comme DataCore, qui peut t'éviter le passage par les grands constructeurs qui ne seront pas neutres au niveau coût, et tu pourrais limite réutiliser ton matos actuel après migration.
J'avais eu l'occasion de monter Datacore sur un POC avec des clés USB et plusieurs hubs USB sur un laptop, donc voilà, ça prend n'importe quel type de techno de stockage, tant qu'on lui présente un truc qu'il supporte (blocs et NFS à l'époque), et il se débrouille et fait sa tambouille pour te fournir un LUN, un partage NFS/CIFS, ou autre.
Merci.
Bonjour, A job-1, sur des volumétrie inférieures, on était parti sur des NAS Synology. Avec les options cache rw SSD ou full SSD, le iSCSI Target, la HA, etc. on obtiens des fonctionnalité assez proches des baies de stockage de grand constructeurs pour une fractions du cout ! D'autant plus qu'on peut acheter les disques que l'on veut ou on veut (voir quand même la liste des HD certifiés compatibles suivant la baie). Coté couts humain, l'effort de mise en œuvre n'est pas le même qu'avec un CEPH, Gluster ou autre ! En terme de volumétrie, leur plus grosse baie actuelle a 16 emplacements et accepte 2 extensions de 12, soit un total de 40 HD. Imaginons 4 SSD en RAID 10 pour le cache RW, reste 36 HD de 12 To soit 432 To brut. Après je ne suis pas un expert SAN et je n'ai jamais eu l'occasion de comparer en live avec une baie HP, NetAPP, EMC, ou autre (c'était hors budget !). Mais vu le différentiel prix, AMHA ça se vaut le coup de faire un PoC (avec des baies plus petites). Au pire ça ourra servir pour stocker les sauvegardes. :) mes 2 cents... Bonne journée, Fabrice Le 09/10/2017 à 23:48, Bruno LEAL DE SOUSA a écrit :
Bonjour à tous,
Je suis face à une problématique, que beaucoup aujourd’hui doivent rencontrer.
Dans ce monde hyperconnecté, on se retrouve souvent à gérer des grosses volumétries.
Aujourd’hui, nous sommes équipés avec des baies HPE 3PAR 7200 (SSD/FC/NL) et 8400 (Full SSD).
Ces baies sont vraiment super, on en content du service. Cependant le cout du stockage au To est assez important.
Cela allait tant qu’on gérait des quantités « Raisonnables » mais là dernièrement ceci explose et ça ne devrait pas s’arrêter. Passage de 50To utiles à 200 en 3 ans.
Si vous avez ce genre de réflexion, n’hésitez pas ! Partager vos pensées et vos solutions pour faire face aux couts astronomiques du stockage.
Bonne soirée à tous !
--
*Bruno LEAL DE SOUSA*
Ingénieur Système et Infrastructure
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Bonjour a tous Nous utilisons beaucoup ZFS sur notre infra de stockage dans divers mode (block -> Zvol +FC ou iscsi) ou filesystem. Notre base est un/des serveur Dell R720 et baie de stockage Dell MD1200 ou MD3060e en jbod le tout sous solaris Notre plus grosse machine heberge environ 500TB et la plus redondante est très proche de ce que propose un metro cluster netapp (ecriture synchrone entre 2 salle machine et fail over d'un noeud frontal qui fait du NFS et CIFS) pour 300TB net. Cette infra est en prod depuis 4 ans sans problème majeur et s'est révél assez simple a gérer ( avec une bonne experience UNIX) Bonne journée On 10/10/2017 03:37 PM, Fabrice Vincent wrote:
Bonjour,
A job-1, sur des volumétrie inférieures, on était parti sur des NAS Synology. Avec les options cache rw SSD ou full SSD, le iSCSI Target, la HA, etc. on obtiens des fonctionnalité assez proches des baies de stockage de grand constructeurs pour une fractions du cout ! D'autant plus qu'on peut acheter les disques que l'on veut ou on veut (voir quand même la liste des HD certifiés compatibles suivant la baie). Coté couts humain, l'effort de mise en œuvre n'est pas le même qu'avec un CEPH, Gluster ou autre !
En terme de volumétrie, leur plus grosse baie actuelle a 16 emplacements et accepte 2 extensions de 12, soit un total de 40 HD. Imaginons 4 SSD en RAID 10 pour le cache RW, reste 36 HD de 12 To soit 432 To brut.
Après je ne suis pas un expert SAN et je n'ai jamais eu l'occasion de comparer en live avec une baie HP, NetAPP, EMC, ou autre (c'était hors budget !). Mais vu le différentiel prix, AMHA ça se vaut le coup de faire un PoC (avec des baies plus petites). Au pire ça ourra servir pour stocker les sauvegardes. :)
mes 2 cents...
Bonne journée, Fabrice
Le 09/10/2017 à 23:48, Bruno LEAL DE SOUSA a écrit :
Bonjour à tous,
Je suis face à une problématique, que beaucoup aujourd’hui doivent rencontrer.
Dans ce monde hyperconnecté, on se retrouve souvent à gérer des grosses volumétries.
Aujourd’hui, nous sommes équipés avec des baies HPE 3PAR 7200 (SSD/FC/NL) et 8400 (Full SSD).
Ces baies sont vraiment super, on en content du service. Cependant le cout du stockage au To est assez important.
Cela allait tant qu’on gérait des quantités « Raisonnables » mais là dernièrement ceci explose et ça ne devrait pas s’arrêter. Passage de 50To utiles à 200 en 3 ans.
Si vous avez ce genre de réflexion, n’hésitez pas ! Partager vos pensées et vos solutions pour faire face aux couts astronomiques du stockage.
Bonne soirée à tous !
--
*Bruno LEAL DE SOUSA*
Ingénieur Système et Infrastructure
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
-- ___________________________________________________________________ ARMANET Stephane Network and Data Services (ILL - DPT/SI) Institut Laue langevin 38042 Grenoble Cedex 9 France Tel: (33)4.76.20.78.56 email: armanets@ill.fr http://www.ill.eu
Bonjour, Pour ceux qui utilise du Ceph, c’est du home made ou plus appliance type HP apollo, Mars200 ? Merci, On 10 October 2017 at 16:00:42, Armanet Stephane (armanets@ill.fr) wrote: Bonjour a tous Nous utilisons beaucoup ZFS sur notre infra de stockage dans divers mode (block -> Zvol +FC ou iscsi) ou filesystem. Notre base est un/des serveur Dell R720 et baie de stockage Dell MD1200 ou MD3060e en jbod le tout sous solaris Notre plus grosse machine heberge environ 500TB et la plus redondante est très proche de ce que propose un metro cluster netapp (ecriture synchrone entre 2 salle machine et fail over d'un noeud frontal qui fait du NFS et CIFS) pour 300TB net. Cette infra est en prod depuis 4 ans sans problème majeur et s'est révél assez simple a gérer ( avec une bonne experience UNIX) Bonne journée On 10/10/2017 03:37 PM, Fabrice Vincent wrote: Bonjour, A job-1, sur des volumétrie inférieures, on était parti sur des NAS Synology. Avec les options cache rw SSD ou full SSD, le iSCSI Target, la HA, etc. on obtiens des fonctionnalité assez proches des baies de stockage de grand constructeurs pour une fractions du cout ! D'autant plus qu'on peut acheter les disques que l'on veut ou on veut (voir quand même la liste des HD certifiés compatibles suivant la baie). Coté couts humain, l'effort de mise en œuvre n'est pas le même qu'avec un CEPH, Gluster ou autre ! En terme de volumétrie, leur plus grosse baie actuelle a 16 emplacements et accepte 2 extensions de 12, soit un total de 40 HD. Imaginons 4 SSD en RAID 10 pour le cache RW, reste 36 HD de 12 To soit 432 To brut. Après je ne suis pas un expert SAN et je n'ai jamais eu l'occasion de comparer en live avec une baie HP, NetAPP, EMC, ou autre (c'était hors budget !). Mais vu le différentiel prix, AMHA ça se vaut le coup de faire un PoC (avec des baies plus petites). Au pire ça ourra servir pour stocker les sauvegardes. :) mes 2 cents... Bonne journée, Fabrice Le 09/10/2017 à 23:48, Bruno LEAL DE SOUSA a écrit : Bonjour à tous, Je suis face à une problématique, que beaucoup aujourd’hui doivent rencontrer. Dans ce monde hyperconnecté, on se retrouve souvent à gérer des grosses volumétries. Aujourd’hui, nous sommes équipés avec des baies HPE 3PAR 7200 (SSD/FC/NL) et 8400 (Full SSD). Ces baies sont vraiment super, on en content du service. Cependant le cout du stockage au To est assez important. Cela allait tant qu’on gérait des quantités « Raisonnables » mais là dernièrement ceci explose et ça ne devrait pas s’arrêter. Passage de 50To utiles à 200 en 3 ans. Si vous avez ce genre de réflexion, n’hésitez pas ! Partager vos pensées et vos solutions pour faire face aux couts astronomiques du stockage. Bonne soirée à tous ! -- *Bruno LEAL DE SOUSA* Ingénieur Système et Infrastructure _______________________________________________ Liste de diffusion du FRsAGhttp://www.frsag.org/ _______________________________________________ Liste de diffusion du FRsAGhttp://www.frsag.org/ -- ___________________________________________________________________ ARMANET Stephane Network and Data Services (ILL - DPT/SI) Institut Laue langevin 38042 Grenoble Cedex 9 France Tel: (33)4.76.20.78.56 email: armanets@ill.fr http://www.ill.eu _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Hello, On 10 Oct 2017 16:29, "professor geek" <prg33k@gmail.com> wrote: Bonjour, Pour ceux qui utilise du Ceph, c’est du home made ou plus appliance type HP apollo, Mars200 ? Ici on a deux clusters Ceph 'homemade' avec du R730 et 96 OSD mécaniques sur chaque cluster, journaux SSD. Sent from my phone
Bonjour,
Pour ceux qui utilise du Ceph, c’est du home made ou plus appliance type HP apollo, Mars200 ?
Home made, déploiement avec ceph-ansible sur commodity hardware (18 nodes, 180 OSDs et 36 SSDs pour les journaux) je fais principalement du S3 mais j'ai un peu de rbd, et je teste cephfs sur un cluster de test en luminous (4 nodes, 40 OSDs et 8 SSDs pour WAL et rockDB). Yoann
On 10 October 2017 at 16:00:42, Armanet Stephane (armanets@ill.fr <mailto:armanets@ill.fr>) wrote:
Bonjour a tous
Nous utilisons beaucoup ZFS sur notre infra de stockage dans divers mode (block -> Zvol +FC ou iscsi) ou filesystem.
Notre base est un/des serveur Dell R720 et baie de stockage Dell MD1200 ou MD3060e en jbod le tout sous solaris
Notre plus grosse machine heberge environ 500TB et la plus redondante est très proche de ce que propose un metro cluster netapp (ecriture synchrone entre 2 salle machine et fail over d'un noeud frontal qui fait du NFS et CIFS) pour 300TB net.
Cette infra est en prod depuis 4 ans sans problème majeur et s'est révél assez simple a gérer ( avec une bonne experience UNIX)
Bonne journée
On 10/10/2017 03:37 PM, Fabrice Vincent wrote:
Bonjour,
A job-1, sur des volumétrie inférieures, on était parti sur des NAS Synology. Avec les options cache rw SSD ou full SSD, le iSCSI Target, la HA, etc. on obtiens des fonctionnalité assez proches des baies de stockage de grand constructeurs pour une fractions du cout ! D'autant plus qu'on peut acheter les disques que l'on veut ou on veut (voir quand même la liste des HD certifiés compatibles suivant la baie). Coté couts humain, l'effort de mise en œuvre n'est pas le même qu'avec un CEPH, Gluster ou autre !
En terme de volumétrie, leur plus grosse baie actuelle a 16 emplacements et accepte 2 extensions de 12, soit un total de 40 HD. Imaginons 4 SSD en RAID 10 pour le cache RW, reste 36 HD de 12 To soit 432 To brut.
Après je ne suis pas un expert SAN et je n'ai jamais eu l'occasion de comparer en live avec une baie HP, NetAPP, EMC, ou autre (c'était hors budget !). Mais vu le différentiel prix, AMHA ça se vaut le coup de faire un PoC (avec des baies plus petites). Au pire ça ourra servir pour stocker les sauvegardes. :)
mes 2 cents...
Bonne journée, Fabrice
Le 09/10/2017 à 23:48, Bruno LEAL DE SOUSA a écrit :
Bonjour à tous,
Je suis face à une problématique, que beaucoup aujourd’hui doivent rencontrer.
Dans ce monde hyperconnecté, on se retrouve souvent à gérer des grosses volumétries.
Aujourd’hui, nous sommes équipés avec des baies HPE 3PAR 7200 (SSD/FC/NL) et 8400 (Full SSD).
Ces baies sont vraiment super, on en content du service. Cependant le cout du stockage au To est assez important.
Cela allait tant qu’on gérait des quantités « Raisonnables » mais là dernièrement ceci explose et ça ne devrait pas s’arrêter. Passage de 50To utiles à 200 en 3 ans.
Si vous avez ce genre de réflexion, n’hésitez pas ! Partager vos pensées et vos solutions pour faire face aux couts astronomiques du stockage.
Bonne soirée à tous !
--
*Bruno LEAL DE SOUSA*
Ingénieur Système et Infrastructure
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
-- ___________________________________________________________________ ARMANET Stephane Network and Data Services (ILL - DPT/SI)
Institut Laue langevin 38042 Grenoble Cedex 9 France
Tel: (33)4.76.20.78.56 email: armanets@ill.fr http://www.ill.eu
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
-- Yoann Moulin linkedin.com/in/yoannmoulin twitter.com/ymoulin
participants (20)
-
"Florent H. CARRÉ (COLUNDRUM)" -
adrien nayrat -
Armanet Stephane -
Bruno LEAL DE SOUSA -
CORTES Bruno -
Cyril Lavier -
David Ponzone -
Fabien Germain -
Fabrice Vincent -
Florent Rivoire -
Francois Lafont -
frsag＠jack.fr.eu.org -
Guillaume -
Kevin Decherf -
Luc Didry -
Olivier Duquesne (DaffyDuke) -
professor geek -
Raphael Mazelier -
Xavier Beaudouin -
Yoann Moulin