3 votes

Faire en sorte que ceph minimise la propagation des parties de fichiers sur les OSDs

J'envisage l'option de ceph comme système de fichiers distribué pour mon MAID (massive array of idle drives) fait maison.

D'après ce que j'ai compris, Ceph est orienté pour une utilisation en cluster et répartit les données de manière égale sur les OSD (en ce qui concerne les cartes CRUSH) et essaie d'utiliser le parallélisme des opérations de lecture sur différents nœuds.

Dans mon cas, je n'ai pas besoin de maximiser la répartition et le débit, dans le cas idéal, il devrait remplir les N premiers OSD (où N est le facteur de réplication) et seulement ensuite commencer à remplir les N OSD suivants, afin de minimiser le nombre de disques actifs requis pour la récupération des données adjacentes.

Puis-je obtenir un tel comportement en modifiant le nombre de groupes de placement et les cartes CRUSH ? Ou si ce n'est pas possible, puis-je au moins faire en sorte que ceph arrête de diviser les fichiers en plus d'un bloc ?

0 votes

D'après mon expérience, je ne pense pas que Ceph puisse faire cela (bien que je n'aie jamais vraiment essayé, mais je ne peux pas imaginer comment vous pourriez y parvenir). Il a été conçu comme étant un stockage d'objets distribué, pas autre chose. Pour autant que je puisse dire, vous ne cherchez pas vraiment quelque chose de distribué ? Je vous oriente vers une solution beaucoup plus simple, comme le LVM à allocation fine, qui fait un peu la même chose que ce que vous recherchez.

0 votes

Je cherche quelque chose de distribué, car les disques durs seront sur différentes machines du réseau. Je pourrais utiliser LVM sur NBD, mais ce n'est pas aussi flexible que le stockage Ceph, au cas où je devrais quand même introduire des fs sur le bloc LVM, donc si j'ajoute ou retire des disques durs du système, cela entraînera un certain désordre avec le redimensionnement des fs.

1voto

OliviervdAkker Points 55

Je ne pense pas que quelque chose de similaire à ce que vous voulez réaliser soit possible avec Ceph. D'après ce que je comprends, ceph est une système de fichiers distribué et qu'il assure une haute tolérance aux pannes en utilisant la réplication. Lisez ici :

L'objectif premier de Ceph est d'être entièrement distribué, sans point de défaillance unique, évolutif jusqu'au niveau de l'exaoctet et disponible gratuitement.

La puissance de Ceph réside dans son évolutivité et sa haute disponibilité :

Évolutivité et haute disponibilité

Dans les architectures traditionnelles, les clients s'adressent à un composant centralisé (par ex. (par exemple, une passerelle, un courtier, une API, une façade, etc. ), qui agit comme un point d'entrée unique dans un sous-système complexe. Cela impose une limite à la fois à la performance et l'évolutivité, tout en introduisant un point unique de point de défaillance (c'est-à-dire que si le composant centralisé tombe en panne, tout le système tombe aussi en panne). système s'arrête également).

Ceph élimine la passerelle centralisée pour permettre aux clients d'interagir avec les OSD Daemons de Ceph directement. Les démons Ceph OSD créent des répliques sur d'autres nœuds Ceph pour garantir la sécurité et la haute disponibilité des données. disponibilité des données. Ceph utilise également un cluster de moniteurs pour assurer la haute disponibilité. Pour éliminer la centralisation, Ceph utilise un algorithme appelé CRUSH.

Ce que j'essaie de souligner, c'est que ceph est conçu pour prendre en charge l'utilisation des disques physiques dans un environnement de cluster afin d'assurer plus de résilience, de haute disponibilité et de transparence. Ce n'est pas vraiment ce que vous recherchez.

Si vous êtes préoccupé par les performances ou les E/S du disque, il existe une option appelée Affinité primaire qui peut être utilisé, par exemple, pour donner la priorité aux disques SAAS sur les disques SATA. Lire la suite aquí y aquí .

Affinité primaire

Lorsqu'un client Ceph lit ou écrit des données, il contacte toujours l'OSD primaire dans l'Actin. l'OSD primaire de l'ensemble actif. Pour l'ensemble [2, 3, 4], osd.2 est le principal. primaire. Parfois, un OSD n'est pas bien adapté pour agir en tant que primaire primaire par rapport aux autres OSD (par exemple, il a un disque lent ou un contrôleur contrôleur lent). Pour éviter les goulots d'étranglement en termes de performances (en particulier de lecture) tout en maximisant l'utilisation de votre matériel, vous pouvez définir l'affinité primaire d'un OSD Ceph afin que CRUSH soit moins susceptible d'utiliser l'OSD en tant que primaire dans une situation d'intérim. OSD en tant que primaire dans un jeu de rôles.

ceph osd primary-affinity <osd-id> <weight>

L'affinité primaire est de 1 par défaut (c'est-à-dire qu'un OSD peut agir comme un primaire). Vous pouvez définir l'affinité primaire de l'OSD de 0 à 1, où 0 signifie que l'OSD ne peut PAS être utilisé comme primaire et 1 signifie qu'un OSD peut être utilisé comme primaire. primaire. Lorsque la pondération est < 1, il est moins probable que CRUSH sélectionne le Ceph OSD Daemon pour agir en tant que primaire.

Je sais que cela ne répond pas exactement à toutes vos questions, mais cela peut donner matière à réflexion.

Voir les détails ici : http://docs.ceph.com/docs/master/rados/operations/crush-map/#primary-affinity

Et aquí est un blog sympa expliquant le cluster ceph.

0 votes

Accédera-t-il au second osd si le premier est plein ? Ou cet ensemble d'OSDs est calculé pour chaque objet individuellement ?

0 votes

Non, ce ne sera pas le cas. C'est plutôt pour améliorer les performances. Voir ma réponse mise à jour.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X