What it is all about :
Si vous pensez ou discutez de Ceph, la question la plus courante qui vous vient à l’esprit est “Quel matériel dois-je choisir pour mon cluster de stockage CEPH ?” et oui si vous avez vraiment pensé à cette question dans votre esprit, félicitations, vous semblez être sérieux au sujet de la technologie Ceph et vous devriez l’être parce que CEPH EST L’AVENIR DU STOCKAGE.
Ceph fonctionne sur du matériel de commodité, Ohh Yeah ! ! tout le monde le sait maintenant . Il est conçu pour construire un cluster de stockage de plusieurs pétaoctets tout en offrant des fonctionnalités d’entreprise. Pas de point de défaillance unique , mise à l’échelle jusqu’à exaoctets , autogestion et auto-guérison ( économise les coûts opérationnels ) , fonctionne sur du matériel de commodité ( pas de verrouillage du vendeur , économise l’investissement en capital )
Ceph Overview :-

La sole du cluster de stockage ceph est RADOS ( Reliable Autonomic Distributed Object Store ). Ceph utilise le puissant algorithme CRUSH (Controlled Replication Under Scalable Hashing) pour optimiser le placement des données, l’autogestion et l’auto-guérison. L’interface RESTful est fournie par Ceph Object Gateway (RGW) aks Rados GateWay et les disques virtuels sont provisionnés par Ceph Block Device (RBD)

Ceph Overview – Crédit image : Inktank

# Ceph OSD ( Object Storage Daemons ) stockage des données dans des objets , gère la réplication des données , la récupération , le rééquilibrage et fournit des informations sur les étapes à Ceph Monitor. Son recommandé d’utiliser 1 OSD par disque physique.
# Ceph MON ( Monitors ) maintient la santé globale du cluster en gardant l’état de la carte du cluster, y compris la carte Monitor , la carte OSD , la carte Placement Group ( PG ) , et la carte CRUSH . Les moniteurs reçoivent des informations d’état d’autres composants pour maintenir les cartes et faire circuler ces cartes vers d’autres nœuds Monitor et OSD.
# Ceph RGW ( Object Gateway / Rados Gateway ) interface API RESTful compatible avec Amazon S3 , OpenStack Swift .
# Ceph RBD ( Raw Block Device ) Fournit un stockage de blocs aux VM / bare metal ainsi qu’aux clients ordinaires , supporte OpenStack et CloudStack . Comprend des fonctionnalités d’entreprise telles que le snapshot , le thin provisioning , la compression.
# CephFS ( File System ) distribué stockage NAS POSIX.
Quelques règles de base :-

• Exécuter OSD sur un nœud de stockage dédié ( serveur avec plusieurs disques ) , les données réelles sont stockées sous la forme d’objets.
• Exécuter Monitor sur un matériel dédié distinct ou coexiste avec des nœuds clients ceph ( autres que le nœud OSD ) tels que RGW , nœud CephFS . Pour la production, il est recommandé d’exécuter les moniteurs sur des serveurs dédiés à faible coût car les moniteurs ne sont pas gourmands en ressources.

Configuration matérielle du moniteur :-
Le moniteur maintient la santé de l’ensemble du cluster , il contient les journaux PG et les journaux OSD . Un minimum de trois nœuds de moniteurs est recommandé pour un quorum de cluster. Les nœuds de surveillance Ceph ne sont pas gourmands en ressources, ils peuvent fonctionner correctement avec un processeur et une mémoire assez faibles. Un serveur 1U avec un processeur E5-2603 à bas prix, 16GB de RAM et un réseau 1GbE devrait être suffisant dans la plupart des cas. Si les journaux PG, Monitor et OSD sont stockés sur le disque local du nœud de moniteur, assurez-vous d’avoir une quantité suffisante de stockage local afin qu’il ne se remplisse pas.
Les clusters malsains nécessitent plus de stockage pour les journaux , peut atteindre jusqu’à GB et même des centaines de Go si le cluster est laissé malsain pendant très longtemps . Si la sortie verbeuse est définie sur les nœuds de surveillance, alors ceux-ci sont tenus de générer une énorme quantité d’informations de journalisation. Reportez-vous à la documentation de ceph pour le réglage de la journalisation du moniteur.
Ils sont recommandés d’exécuter le moniteur sur des nœuds distants plutôt que sur tous sur un seul nœud ou sur des machines virtuelles sur des machines physiques séparées pour éviter un point de défaillance unique.
L’étape de planification :-
Déployer un cluster ceph en production nécessite un peu de devoirs , vous devez rassembler les informations ci-dessous afin que vous puissiez concevoir un cluster ceph meilleur et plus fiable et évolutif pour s’adapter à vos besoins informatiques. Ces informations sont très spécifiques à vos besoins et à votre environnement informatique. Ces informations vous aideront à mieux concevoir votre besoin de stockage.

• Business Requirement
• Budget ?
• Avez-vous besoin du cluster Ceph pour les opérations quotidiennes ou SPECIAL
• Technical Requirement
• Quelles applications seront exécutées sur votre cluster Ceph ?
• Quel type de données seront stockées sur votre cluster ceph ?
• Le cluster ceph doit-il être optimisé pour la capacité et les performances ?
• Quelle doit être la capacité de stockage utilisable ?
• Quel est le taux de croissance prévu ?
• Combien d’IOPS le cluster doit-il supporter ?
• Combien de débit le cluster doit-il supporter
• Combien de réplication de données ( niveau de fiabilité ) vous avez besoin ?

Collectez autant d’informations que possible pendant la phase de planification , le donnera toutes les réponses nécessaires pour construire un meilleur cluster ceph.
Le nœud physique et la technique de clustering:-
En plus des informations collectées ci-dessus , prenez également en compte la densité du rack et le budget de puissance , le coût du pace de l’espace du centre de données pour dimensionner la configuration optimale du nœud. Ceph réplique les données sur plusieurs nœuds dans un cluster de stockage pour fournir la redondance des données et une plus grande disponibilité. Son important de considérer.

• Le nœud répliqué doit-il être sur le même rack ou plusieurs racks pour éviter le SPOF ?
• Le trafic OSD doit-il rester dans le rack ou s’étendre à travers le rack dans un réseau dédié ou partagé ?
• Combien de nœuds défaillants peuvent être tolérés ?
• Si les nœuds sont séparés sur plusieurs racks, le trafic réseau augmente et l’impact de la latence et du nombre de sauts de commutateur réseau doit être pris en compte.

# Environnement POC – Peut avoir un minimum de 3 nœuds physiques avec 10 OSD chacun. Cela permet d’assurer une disponibilité du cluster de 66% en cas de défaillance d’un nœud physique et une disponibilité de 97% en cas de défaillance d’un OSD. Les nœuds RGW et Monitor peuvent être mis sur des nœuds OSD mais cela peut avoir un impact sur les performances et n’est pas recommandé pour la production.
# Environnement de production – un minimum de 5 nœuds séparés physiquement et un minimum de 100 OSD @ 4TB par OSD la capacité du cluster est de plus de 130TB et fournit une disponibilité de 80% sur une panne de nœud physique et 99% sur une panne d’OSD. RGW et les moniteurs doivent être sur des nœuds séparés.
Sur la base du résultat de la phase de planification et des nœuds physiques et de l’étape de clustering, vous avez un regard sur le matériel disponible sur le marché en fonction de votre budget.
Sélection du CPU de l’OSD :-
< En construction … Restez à l’écoute >

.