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