1 : Types de stockage
1. Périphérique de stockage autonome
DAS (stockage directement connecté, qui est directement connecté au bus de la carte mère de l'ordinateur)
IDE, SATA, SCSI, SAS, disque d'interface USB
L'interface dite est un périphérique de stockage piloté Un périphérique de disque qui fournit un stockage de niveau bloc
● NAS (Network Attached Storage, qui est un stockage attaché au système de fichiers hôte actuel via le réseau)
NFS, CIFS,
le stockage au niveau du système de fichiers FTP est lui-même un système de fichiers bien conçu. Après la sortie dans l'espace utilisateur via l'interface nfs , Le client établit une communication réseau avec l'hôte distant en fonction du module du noyau et le convertit pour l'utiliser comme un système de fichiers local. Ce type de service de stockage ne peut pas le formater à nouveau pour créer un bloc de système de fichiers
●SAN (réseau de stockage)
Protocole SCSI (utilisé uniquement pour transmettre les opérations d'accès aux données, la couche physique utilise des câbles SCSI pour la transmission), FCSAN (la couche physique utilise la fibre optique pour la transmission), iSCSI (la couche physique utilise Ethernet pour la transmission)
C'est aussi une sorte de stockage réseau, mais la différence est que l'interface fournie par le SAN à l'hôte client est un stockage au niveau des blocs
Problèmes avec le stockage autonome
●Capacité de stockage et de traitement insuffisante
La valeur d'E/S de l'IDE traditionnel est de 100 fois/s, celle du disque SSD SATA est de 500 fois/s et celle des disques durs à semi-conducteurs atteint 2 000 à 4 000 fois /s. Même si la capacité d'E/S du disque est des dizaines de fois supérieure, elle n'est toujours pas suffisante pour résister à l'accès simultané de centaines de milliers, de millions voire de centaines de millions d'utilisateurs pendant la période de pointe d'accès au site Web, qui est également limitée par la capacité d'E/S du réseau hôte.
●Capacité de stockage insuffisante
Quelle que soit la capacité d'un seul disque, il ne peut pas atteindre la limite de capacité de données requise par les utilisateurs pour un accès normal.
● Point de défaillance unique
Il existe un point de défaillance unique pour les données stockées sur une seule machine
Deux : Solutions de stockage commerciales
EMC, NetAPP, IBM, DELL, Huawei, Inspur
Trois stockages distribués (stockage défini par logiciel SDS)
Ceph, TFS, FastDFS, MooseFS (MFS), GlusterFS (GFS)
Le mécanisme de stockage dispersera et stockera les données sur plusieurs nœuds, ce qui présente les avantages d'une évolutivité élevée, de hautes performances et d'une haute disponibilité.
#Types de stockage distribué
Stockage de blocs (tel qu'un disque dur, généralement un stockage est monté par un serveur, adapté à l'allocation de volume de stockage de conteneur ou de machine virtuelle, au stockage de journaux, au stockage de fichiers) le stockage de blocs fournit un volume de stockage qui fonctionne comme un disque dur, organisé en
blocs de même taille. Généralement, soit le système d'exploitation formate un volume de stockage basé sur des blocs avec un système de fichiers, soit des applications (telles que des bases de données) y accèdent directement pour stocker des données.
● Le stockage de fichiers (tel que NFS, résout le problème selon lequel le stockage de blocs ne peut pas être partagé et un stockage peut être monté par plusieurs serveurs en même temps, adapté au stockage de la structure de répertoires et au stockage des journaux) permet d'organiser les données sous forme de fichier
traditionnel système. Les données sont conservées dans un fichier qui a un nom et des métadonnées associées telles que l'horodatage de modification, le propriétaire et les autorisations d'accès. Fournit un stockage basé sur des fichiers à l'aide d'une hiérarchie de répertoires et de sous-répertoires pour organiser la manière dont les fichiers sont stockés.
● Stockage d'objets (tel que OSS, un stockage peut être consulté par plusieurs services en même temps, dispose des capacités de lecture et d'écriture à grande vitesse du stockage par blocs et présente également les caractéristiques du partage de stockage de fichiers, adapté au stockage d'images et à la vidéo stockage) stockage de fichiers fourni sur la base de l'interface API,
chaque fichier A est un objet et la taille du fichier est différente, et les métadonnées et les données réelles du fichier sont stockées ensemble.
Le stockage d'objets permet de stocker des données et des métadonnées arbitraires en tant qu'unité, étiquetées avec un identifiant unique dans un pool de stockage plat. Stockez et récupérez des données à l'aide d'API au lieu d'accéder aux données sous forme de blocs ou dans des hiérarchies de système de fichiers.
2 Introduction à Ceph
Ceph est développé à l'aide du langage C++ et est un système de stockage distribué open source qui est ouvert, autoréparateur et autogéré. Il présente les avantages d'une grande évolutivité, de hautes performances et d'une grande fiabilité.
Ceph est actuellement pris en charge par de nombreux fournisseurs de cloud computing et est largement utilisé. RedHat, OpenStack et Kubernetes peuvent tous être intégrés à Ceph pour prendre en charge le stockage back-end des images de machines virtuelles.
On estime approximativement que 70 à 80 % des plates-formes cloud de mon pays utilisent Ceph comme plate-forme de stockage sous-jacente, ce qui montre que Ceph est devenu la configuration standard des plates-formes cloud open source. À l'heure actuelle, les entreprises nationales qui utilisent Ceph pour construire des systèmes de stockage distribués ont plus de succès, telles que Huawei, Ali, ZTE, H3C, Inspur, China Mobile, Netease, LeTV, 360, Tristar Storage, Shanyan Data, etc.
Trois avantages Ceph
● Évolutivité élevée : décentralisée, prend en charge l'utilisation de serveurs X86 ordinaires, prend en charge l'échelle de milliers de nœuds de stockage et prend en charge l'extension du niveau TB au niveau EB.
●Haute fiabilité : pas de point de défaillance unique, plusieurs copies de données, gestion automatique, réparation automatique.
●Haute performance : en abandonnant le schéma d'adressage traditionnel des métadonnées de stockage centralisé, en utilisant l'algorithme CRUSH, la distribution des données est équilibrée et le degré de parallélisme est élevé.
● Fonctions puissantes : Ceph est un système de stockage unifié qui intègre une interface de stockage de blocs (RBD), une interface de stockage de fichiers (CephFS) et une interface de stockage d'objets (RadosGW). Il convient donc à différents scénarios d'application.
Architecture à quatre Ceph
De bas en haut, le système Ceph peut être divisé en quatre niveaux :
Système de stockage de base RADOS (Reliab1e, Autonomic, Distributed object store, c'est-à-dire un stockage d'objets fiable, automatisé et distribué)
RADOS est le module fonctionnel le plus bas de Ceph, et c'est un service de stockage d'objets extensible à l'infini qui peut désassembler des fichiers Il est décomposé en d'innombrables objets (fragments) et stockés sur le disque dur, ce qui améliore considérablement la stabilité des données. Il est principalement composé d'OSD et de Monitor. OSD et Monitor peuvent être déployés sur plusieurs serveurs. C'est l'origine de la distribution ceph et l'origine de la haute évolutivité.
● LIBRADOS La bibliothèque de base
Librados permet d'interagir avec RADOS et fournit des interfaces d'API de service Ceph aux applications de couche supérieure. Par conséquent, les RBD, RGW et CephFS de couche supérieure sont tous accessibles via Librados. Actuellement, PHP, Ruby, Prise en charge de Java, Python, Go, C et C++ pour le développement d'applications clientes directement sur RADOS (plutôt que sur Ceph complet).
● Interface d'application de haut niveau : comprend trois parties 1) Interface de stockage d'objets L'interface de passerelle
RGW (RADOS Gateway) , basée sur le système de stockage d'objets développé par Librados, fournit une interface API RESTful compatible avec S3 et Swift.
2) Interface de stockage de bloc RBD (Reliable Block Device)
fournit une interface de périphérique de bloc basée sur Librados, qui est principalement utilisée pour Host/VM.
3) L'interface de stockage de fichiers CephFS (Ceph File System)
Le système de fichiers Ceph fournit un système de fichiers compatible POSIX qui utilise le cluster de stockage Ceph pour stocker les données utilisateur sur le système de fichiers. Basé sur l'interface de système de fichiers distribué fournie par Librados.
●Couche application : diverses applications développées sur la base d'interfaces de haut niveau ou de la bibliothèque de base Librados, ou de nombreux clients tels que Host et VM
Cinq composants principaux de Ceph
Ceph est un système de stockage basé sur des objets qui divise chaque flux de données à gérer (tels que des fichiers et d'autres données) en une ou plusieurs données d'objet (Objet) de taille fixe (par défaut 4 mégaoctets), et l'utilise comme une unité atomique ( Atom est la plus petite unité d'un élément) pour compléter la lecture et l'écriture des données.
●OSD (Object Storage Daemon, processus démon ceph-osd)
est un processus responsable du stockage physique, et est généralement configuré pour correspondre aux disques un par un, et un disque démarre un processus OSD. La fonction principale est de stocker des données, de copier des données, d'équilibrer des données, de restaurer des données et d'effectuer des vérifications de pulsation avec d'autres OSD, et est responsable du processus de retour de données spécifiques en réponse aux demandes des clients. Généralement, au moins 3 OSD sont nécessaires pour la redondance et la haute disponibilité.
●PG (Groupe de Placement)
PG est un concept virtuel et n'existe pas physiquement. Il est similaire à l'index dans la base de données dans l'adressage des données : Ceph mappe d'abord chaque donnée d'objet à un PG via l'algorithme HASH, puis mappe le PG à l'OSD via l'algorithme CRUSH.
●Pool
Pool est une partition logique pour le stockage d'objets et fonctionne comme un espace de noms. Chaque pool contient un certain nombre (configurable) de PG. Le pool peut être utilisé comme domaine d'isolation des pannes, qui n'est pas uniformément isolé selon les différents scénarios d'utilisation.
Deux types de stockage de données sont pris en charge dans #Pool :
Répliqué : similaire à raid1, les données d'un objet sont enregistrées avec 3 copies par défaut et placées dans différents OSD
Code d'effacement : similaire à raid5, qui consomme moins de CPU Légèrement plus grand, mais économise du disque espace, et une seule copie des données d'objet est enregistrée. Étant donné que certaines fonctions de Ceph ne prennent pas en charge les pools de codage d'effacement, ce type de pool de stockage n'est pas beaucoup utilisé
Relation #Pool, PG et OSD :
il existe de nombreux PG dans un pool ; un PG contient un ensemble d'objets, et un objet ne peut appartenir qu'à un seul PG ; les PG sont divisés en maîtres et esclaves, et un PG est réparti sur différents OSD (pour le type Triple copie)
●Monitor (le processus démon ceph-mon)
est utilisé pour enregistrer les métadonnées de l'OSD. Responsable de la maintenance des vues de mappage de l'état du cluster (Cluster Map : OSD Map, Monitor Map, PG Map et CRUSH Map), de la maintenance de divers graphiques montrant l'état du cluster et de la gestion de l'authentification et de l'autorisation du client du cluster. Un cluster Ceph nécessite généralement au moins 3 ou 5 nœuds Monitor (nombre impair) pour obtenir une redondance et une haute disponibilité, et ils synchronisent les données entre les nœuds via le protocole Paxos.
● Le gestionnaire (démon ceph-mgr)
est responsable du suivi des métriques d'exécution et de l'état actuel du cluster Ceph, y compris l'utilisation du stockage, les métriques de performances actuelles et la charge du système. Fournit une surveillance et des interfaces supplémentaires aux systèmes de surveillance et de gestion externes, tels que zabbix, prometheus, cephmetrics, etc. Un cluster Ceph nécessite généralement au moins 2 nœuds mgr pour atteindre une haute disponibilité, et la synchronisation des informations entre les nœuds est réalisée sur la base du protocole raft.
●MDS (Metadata Server, processus démon ceph-mds)
est un service de métadonnées dont dépendent les services CephFS. Responsable de la sauvegarde des métadonnées du système de fichiers et de la gestion de la structure des répertoires. Le stockage d'objets et le stockage de périphérique de bloc ne nécessitent pas de services de métadonnées ; si vous n'utilisez pas CephFS, vous ne pouvez pas l'installer.
Six back-end de stockage OSD
Les OSD ont deux façons de gérer les données qu'ils stockent. Dans Luminous 12.2.z et les versions ultérieures, le backend par défaut (et recommandé) est BlueStore. Avant la sortie de Luminous, FileStore était la seule option par défaut.
● Filestore
FileStore est une ancienne méthode de stockage d'objets dans Ceph. Il s'appuie sur un système de fichiers standard (uniquement XFS) combiné à une base de données clé/valeur (traditionnellement LevelDB, maintenant BlueStore est RocksDB) pour stocker et gérer les métadonnées.
FileStore est bien testé et largement utilisé en production. Cependant, en raison de sa conception globale et de sa dépendance aux systèmes de fichiers traditionnels, il présente de nombreuses lacunes en termes de performances.
● Bluestore
BlueStore est un backend de stockage spécial conçu spécifiquement pour la gestion de la charge de travail OSD des données sur disque. La conception de BlueStore est basée sur une décennie d'expérience dans le support et la gestion des Filestores. Comparé à Filestore, BlueStore offre de meilleures performances et sécurité en lecture et en écriture.
Les principales fonctions de #BlueStore incluent :
1) BlueStore gère directement les périphériques de stockage, c'est-à-dire qu'il utilise directement des périphériques de blocs bruts ou des partitions pour gérer les données sur les disques. Cela évite l'intervention de couches d'abstraction (telles que les systèmes de fichiers locaux tels que XFS), qui peuvent limiter les performances ou augmenter la complexité.
2) BlueStore utilise RocksDB pour la gestion des métadonnées. La base de données clé/valeur de RocksDB est intégrée afin de gérer les métadonnées internes, y compris le mappage des noms d'objets pour bloquer les emplacements sur le disque.
3) Toutes les données et métadonnées écrites sur BlueStore sont protégées par une ou plusieurs sommes de contrôle. Aucune donnée ou métadonnée n'est lue à partir du disque ou renvoyée à l'utilisateur sans vérification.
4) Prise en charge de la compression en ligne. Les données peuvent éventuellement être compressées avant d'être écrites sur le disque.
5) Prend en charge la superposition de métadonnées multi-appareils. BlueStore permet à son journal interne (journal d'écriture anticipée WAL) d'être écrit sur un périphérique haut débit séparé (tel que SSD, NVMe ou NVDIMM) pour des performances améliorées. Les métadonnées internes peuvent être stockées sur des appareils plus rapides s'il y a beaucoup de stockage plus rapide disponible.
6) Prise en charge efficace de la copie sur écriture. Les instantanés RBD et CephFS s'appuient sur le mécanisme de clonage de copie sur écriture efficacement mis en œuvre dans BlueStore. Cela se traduira par des E/S efficaces pour les instantanés réguliers et les pools à code d'effacement (qui reposent sur des clones pour une validation efficace en deux phases).
Sept procédures stockées de données Ceph
1) Le client obtient la dernière carte de cluster de mon
2) Dans Ceph, tout est objet. Les données stockées par Ceph seront divisées en un ou plusieurs objets de taille fixe (Objet). La taille de l'objet peut être ajustée par l'administrateur, généralement 2M ou 4M.
Chaque objet aura un OID unique, qui est composé de ino et ono :
ino : le FileID du fichier, qui est utilisé pour identifier de manière unique chaque fichier globalement
ono : le numéro de la tranche
Par exemple : un fichier FileID est A , il est découpé en deux objets, l'un est numéroté 0 et l'autre est numéroté 1, alors les oids de ces deux fichiers sont A0 et A1.
L'avantage d'OID est qu'il peut identifier de manière unique chaque objet différent et stocker l'affiliation entre l'objet et le fichier. Étant donné que toutes les données de Ceph sont virtualisées en objets uniformes, l'efficacité de la lecture et de l'écriture sera relativement élevée.
3) Obtenez un code de fonctionnalité hexadécimal en utilisant l'algorithme HASH sur l'OID, prenez le reste du code de fonctionnalité et le nombre total de PG dans le pool, et le numéro de série obtenu est PGID.
C'est-à-dire, Pool_ID + HASH(OID) % PG_NUM pour obtenir PGID
4) Le PG se répliquera en fonction du nombre de copies définies et calculera les ID des OSD primaires et secondaires cibles dans le PG en utilisant l'algorithme CRUSH sur le PGID, et les stockera sur différents nœuds OSD (en fait, tous les objets dans le PG sont stockés sur l'OSD) .
Autrement dit, grâce à CRUSH (PGID), les données dans PG sont stockées dans chaque groupe OSD
Cycle de vie des huit versions de Ceph
À partir de la version Nautilus (14.2.0), Ceph aura une nouvelle version stable publiée chaque année, qui devrait être publiée en mars de chaque année. Chaque année, la nouvelle version aura un nouveau nom (par exemple, "Mimic ") et un numéro de version principal (par exemple, 13 pour Mimic, puisque "M" est la 13e lettre de l'alphabet).
Le format du numéro de version est xyz, x indique le cycle de publication (par exemple, 13 pour Mimic, 17 pour Quincy), y indique le type de version de publication, c'est-à-dire x.0.z : y est égal à 0, indiquant le
développement version
x.1.z : y est égal à 1, indiquant une version candidate (pour les clusters de test)
x.2.z : y est égal à 2, indiquant une version stable/corrigée (pour les utilisateurs)
Déploiement de neuf clusters Ceph
À l'heure actuelle, Ceph fournit officiellement une variété de méthodes pour déployer des clusters Ceph.Les méthodes couramment utilisées sont ceph-deploy, cephadm et binary:
● cephadm : utilisez cephadm pour déployer des clusters ceph à partir d'Octopus et de versions plus récentes, utilisez des conteneurs et systemd pour installer et gérer des clusters Ceph. Non recommandé pour les environnements de production pour le moment.
●Binaire : déploiement manuel, déploiement du cluster Ceph étape par étape, prise en charge d'une plus grande personnalisation et compréhension des détails du déploiement, et l'installation est plus difficile.
Dix expériences : Déployer le cluster Ceph basé sur ceph-deploy
// Recommandation d'environnement de production Ceph :
1. Tous les clusters de stockage utilisent un réseau 10 Gigabit
2. Réseau de cluster (réseau de cluster, utilisé pour la communication interne du cluster) et réseau public (réseau public, utilisé Accès externe au cluster Ceph)
3. Mon, mds et osd sont déployés séparément sur différents hôtes (dans l'environnement de test, un nœud hôte peut exécuter plusieurs composants)
4. L'OSD peut également utiliser SATA
5. Planification du cluster en fonction de la capacité
6 Processeur Xeon E5 2620 V3 ou supérieur, mémoire de 64 Go ou supérieure
7. Déploiement distribué des hôtes du cluster pour éviter les pannes d'alimentation ou de réseau de l'armoire
Planification de l'environnement Ceph
Nom d'hôte Réseau public Rôle réseau du cluster
admin 192.168.50.25 admin (le nœud de gestion est responsable du déploiement global du cluster)
node01 192.168.50.23 192.168.50.23 mon, mgr, osd
node02 192.168.50.24 192.168.50.24 mon, mgr, osd nœud
03 192.168.50.25 192.168.50.25 mon, osd
clinet 192.168.50.20 client
1. Fermer selinux et pare-feu
systemctl disable --now firewalld
setenforce 0
sed -i 's/enforcing/disabled/' /etc/selinux/config
2. Définissez le nom d'hôte selon le plan :
hostnamectl set-hostname admin
hostnamectl set-hostname node01
hostnamectl set-hostname node02
hostnamectl set-hostname node03
hostnamectl set-hostname client
3, placez les hôtes parse
cat >> /etc/hosts << EOF
192.168.50.25 admin
192.168.50.22 node01 192.168.50.23
node02
192.168.50.24 node03
192.168.50.20 client
EOF
4. Installez les logiciels communs et les packages dépendants
yum -y install epel-release
yum -y install yum-plugin-priorities yum-utils ntpdate python-setuptools python-pip gcc gcc-c++ autoconf libjpeg libjpeg-devel libpng libpng-devel freetype freetype-devel libxml2 libxml2-devel zlib zlib-devel glibc glibc-devel glib2 glib2 -devel bzip2 bzip2-devel zip unzip ncurses ncurses-devel curl curl-devel e2fsprogs e2fsprogs-devel krb5-devel libidn libidn-devel openssl openssh openssl-devel nss_ldap openldap openldap-devel openldap-clients openldap-servers libxslt-devel libevent-devel ntp libtool-ltdl bison libtool vim-enhanced python wget lsof iptraf strace lrzsz kernel-devel kernel-headers pam-devel tcl tk cmake ncurses-devel bison setuptool popt-devel écran net-snmp perl-devel pcre-devel écran net-snmp tcpdump rsync sysstat man iptables sudo libconfig git bind-utils tmux elinks numactl iftop bwm-ng net-tools expect snappy leveldb gdiskpython-argparse gperftools-libs conntrack ipset jq libseccomp socat chrony sshpass
5. Configurez ssh sur le nœud de gestion admin pour vous connecter à tous les nœuds sans mot de passe
ssh-keygen -t rsa -P '' -f ~/.ssh/id_rsa
sshpass -p '123' ssh-copy-id -o StrictHostKeyChecking= non root@admin
sshpass -p '123' ssh-copy-id -o StrictHostKeyChecking=no root@node01
sshpass -p '123' ssh-copy-id -o StrictHostKeyChecking=no root@node02
sshpass -p '123' ssh- copy-id - o StrictHostKeyChecking=no root@node03
6. Configurer la synchronisation de l'heure
systemctl enable --now chronyd
timedatectl set-ntp true #Ouvrir NTP
timedatectl set-timezone Asia/Shanghai #Définir le fuseau horaire
chronyc -a makestep #Synchroniser de force l'état de l'horloge système
timedatectl #Afficher l'état de synchronisation de l'heure
chronyc sources - v #Afficher les informations du serveur source ntp
timedatectl set-local-rtc 0 #Ecrire l'heure UTC actuelle dans l'horloge matérielle
#Redémarrer les services qui dépendent de l'heure système
systemctl restart rsyslog
systemctl restart crond
#Fermer les services non pertinents
systemctl disable --now postfix
7. Configurez la source
wget de Ceph yum https://download.ceph.com/rpm-nautilus/el7/noarch/ceph-release-1-1.el7.noarch.rpm --no-check-certificate
rpm -ivh ceph-release-1-1.el7.noarch.rpm --force
À ce stade, le fichier ceph.repo est généré dans l'entrepôt yum et l'adresse de téléchargement à l'intérieur est une source étrangère, qui peut être directement modifiée en une source miroir nationale avec sed
sed -i 's#download.ceph.com#mirrors.aliyun.com/ceph#' ceph.repo
8. Redémarrez tous les hôtes après avoir effectué toutes les opérations ci-dessus (facultatif)
sync #改盘
reboot #Reboot
Déployer le cluster Ceph
1. Créez un répertoire de travail Ceph pour tous les nœuds, et le travail de suivi sera effectué dans ce répertoire
mkdir -p /etc/ceph
2. Installez l'outil de déploiement ceph-deploy
cd /etc/ceph
yum install -y ceph-deploy #Install sur le nœud de gestion
ceph-deploy --version
3. Installez le progiciel Ceph sur le nœud de gestion pour les autres nœuds
#ceph-deploy 2.0.1 Le déploiement par défaut est la version mimique de Ceph. Si vous souhaitez installer d'autres versions de Ceph, vous pouvez utiliser --release pour spécifier manuellement la version
cd /etc/ceph
ceph -deploy install --release nautilus node0{1..3} admin
#ceph-deploy install exécute essentiellement les commandes suivantes :
yum clean all
yum -y install epel-release
yum -y install yum-plugin-priorities
yum -y install ceph-release ceph ceph-radosgw
#Vous pouvez également installer manuellement le package Ceph, exécutez la commande suivante sur d'autres nœuds pour déployer le package d'installation Ceph :
yum install -y ceph-mon ceph-radosgw ceph-mds ceph-mgr ceph-osd ceph-common ceph
Ajouter un disque dur et une carte réseau à node01 node02 node03
Actualiser l'interface du disque et actualiser le disque nouvellement ajouté
echo "- - -" >/sys/class/scsi_host/host0/scan
echo "- - -" >/sys/class/scsi_host/host1/scan
echo "- - -" >/sys/class/scsi_host/host2/scan
ou redémarrer directement
Modifier le fichier de configuration de la carte réseau intranet
cd /etc/sysconfig/network-script/
cp ifcfg-ens33 ifcfg-ens35
4. Générez la configuration initiale
#Exécutez la commande suivante sur le nœud de gestion pour indiquer à ceph-deploy quel est le nœud de surveillance mon
cd /etc/ceph
ceph-deploy new --public-network 192.168.50.0/24 --cluster-network 192.168 .100.0 /24 nœud01 nœud02 nœud03
#Une fois la commande exécutée avec succès, le fichier de configuration sera généré sous /etc/ceph
ls /etc/ceph
ceph.conf #ceph configuration file
ceph-deploy-ceph.log #monitor log
ceph.mon.keyring #monitor key ring document
5. Initialisez mon node
cd /etc/ceph sur le noeud de gestion
#Créer un nœud mon. Étant donné que le moniteur utilise l'algorithme Paxos, le nombre de nœuds de cluster à haute disponibilité nécessite un nombre impair supérieur ou égal à 3. ceph
-deploy mon create node01 node02 node03
#Configurer le nœud mon initial et synchroniser la configuration sur tous les nœuds
ceph-deploy --overwrite-conf mon create-initial
# --overwrite-conf paramètre est utilisé pour indiquer l'écrasement obligatoire du fichier de configuration
ceph-deploy rassemblekeys node01 #Opération facultative, collectez toutes les clés du nœud node01
#Afficher le processus mon ouvert automatiquement sur le nœud mon
ps aux | grep ceph
#Afficher l'état du cluster Ceph sur le nœud de gestion
cd /etc/ceph
ceph -s
#Vérifier l'élection du cluster mon
ceph quorum_status --format json-pretty | grep leader
#Expand mon node
ceph-deploy mon add <node name>
6. Déployer des nœuds capables de gérer des clusters Ceph (facultatif)
#Peut implémenter des commandes ceph sur chaque nœud pour gérer le cluster
cd /etc/ceph
ceph-deploy --overwrite-conf config push node01 node02 node03 #Synchronize configuration to all mon nodes, Assurez-vous que le contenu de ceph.conf sur tous les nœuds mon doit être cohérent
ceph-deploy admin node01 node02 node03 #Ce livre sert à copier le fichier d'authentification du cluster ceph.client.admin.keyring sur chaque nœud
#Afficher ls /etc/ceph sur le nœud mon
7. Déployer des nœuds de stockage osd
#Ne partitionnez pas l'hôte après avoir ajouté le disque dur, utilisez directement
lsblk
#S'il s'agit d'un ancien disque dur, vous devez d'abord effacer (supprimer la table de partition) le disque (facultatif, un nouveau disque dur sans données ne peut pas être créé) cd /etc/ceph ceph-
deploy
disk zap node01 /dev/sdb
ceph-deploy disque zap node02 /dev/sdb
ceph-deploy disque zap node03 /dev/sdb
#Ajouter un nœud osd (ajouter un nœud adimin)
ceph-deploy --overwrite-conf osd create node01 --data /dev/sdb
ceph-deploy --overwrite-conf osd create node02 --data /dev/sdb
ceph-deploy - -overwrite-conf osd créer node03 --data /dev/sdb
Afficher l'état de l'osd ceph osd stat
Installez l'opération ci-dessus et ajoutez le disque dur /dev/sdc /dev/sdd de node01 node02 node03
8. Déployer le nœud mgr
Le démon #ceph-mgr s'exécute en mode actif/veille, ce qui garantit qu'en cas de défaillance du nœud actif ou de son démon ceph-mgr, l'une des instances de secours peut prendre en charge ses tâches sans interruption de service. Selon les principes officiels de l'architecture, mgr doit avoir au moins deux nœuds pour fonctionner.
manager节点
cd /etc/ceph
ceph-deploy mgr create node01 node02
#Solution HEALTH_WARN problème dans la figure ci-dessus : les mons autorisent la récupération non sécurisée de global_id problème :
désactiver le mode non sécurisé : ceph config set mon auth_allow_insecure_global_id_reclaim false
#Expand mgr node
ceph-deploy mgr create <node name>
9. Allumez le module de surveillance
et vérifiez d'abord quel nœud est le nœud actif mgr !
ceph -s | grep gestionnaire
#Exécutez la commande node01
yum install -y ceph-mgr-dashboard sur le nœud actif ceph-mgr
cd /etc/ceph
module de gestion ceph ls | tableau de bord grep
#Open dashboard module
ceph mgr module enable dashboard --force
#Désactiver la fonction ssl du tableau de bord
ceph config set mgr mgr/dashboard/ssl false
#Configurer l'adresse et le port surveillés par le tableau de bord
ceph config set mgr mgr/dashboard/server_addr 0.0.0.0
ceph config set mgr mgr/dashboard/server_port 8000
#重启 dashboard
ceph mgr module disable dashboard
ceph mgr module enable dashboard --force
#Confirmer l'accès aux services du tableau de bord url
ceph mgr
#Définir le compte et le mot de passe du tableau de bord
echo "12345678" > dashboard_passwd.txt
tableau de bord ceph set-login-credentials admin -i dashboard_passwd.txt
Accès au navigateur : http://192.168.50.22:8000, le mot de passe du compte est admin/12345678
Gestion des pools de ressources
Ci-dessus, nous avons terminé le déploiement du cluster Ceph, mais comment stockons-nous les données dans Ceph ? Nous devons d'abord définir un pool de ressources Pool dans Ceph. Pool est un concept abstrait pour stocker des objets Object dans Ceph. Nous pouvons le comprendre comme une partition logique sur le stockage Ceph. Le pool est composé de plusieurs PG ; les PG sont mappés sur différents OSD via l'algorithme CRUSH ; en même temps, le pool peut définir la taille du réplica et le nombre par défaut de réplicas est de 3 .
Le client Ceph demande l'état du cluster au moniteur et écrit des données dans le pool.En fonction du nombre de PG, les données sont mappées sur différents nœuds OSD via l'algorithme CRUSH pour réaliser le stockage des données. Ici, nous pouvons comprendre Pool comme une unité logique pour stocker des données d'objet ; bien sûr, le cluster actuel n'a pas de pool de ressources, il doit donc être défini.
Créez un pool de ressources de pool, son nom est mypool et le nombre de PG est défini sur 64. Lors de la définition des PG, vous devez également définir PGP (généralement, les valeurs des PG et des PGP sont les mêmes): PG (groupe de placement ), pg est un concept virtuel
, utilisé pour stocker des objets, PGP (groupe de placement à des fins de placement), équivaut à un arrangement et une combinaison osd stockés dans pg
cd /etc/ceph
pool ceph osd créer monpool 64 64
Comment calculer le nombre de pg que devrait avoir le pool pauvre ?
Si le nombre d'OSD est inférieur à 5, réglez le nombre de pages sur 128 ;
Le nombre d'OSD est de 5 à 10 et le nombre de pages est défini sur 512 ;
Le nombre d'OSD est compris entre 10 et 50 et le nombre de pages est défini sur 4096 ;
Le nombre d'OSD est supérieur à 50, reportez-vous à la formule
( PG cibles par OSD ) x ( # OSD ) x ( % Données ) / ( Taille )
Signification : cibler Pgs par osd # et combien de PG sont assignés à chaque OSD
osd # Le nombre d'osd
%data #pool pourcentage de l'espace total
taille : nombre de doublons
Pour plus de détails, consultez le site officiel de Ceph
Ceph Homepage - Ceph
#Afficher les informations sur le pool de clusters
ceph osd pool ls ou rados lspools
ceph osd lspools
#Afficher le nombre de copies du pool de ressources
ceph osd pool get mypool size
#Vérifiez le nombre de PG et PGP
ceph osd pool get mypool pg_num
ceph osd pool get mypool pgp_num
#Modifiez le nombre de pg_num et pgp_num à 128
ceph osd pool set mypool pg_num 128
ceph osd pool set mypool pgp_num 128
pool ceph osd obtenir mon pool pg_num
pool ceph osd obtenir mon pool pgp_num
#Modifier le nombre de copies du pool à 2
ceph osd pool set mypool size 2
pool ceph osd obtenir la taille de mypool
#Modifier le nombre de copies par défaut à 2
vim ceph.conf
......
osd_pool_default_size = 2
ceph-deploy --overwrite-conf config push node01 node02 node03 # Synchronisation de la configuration du nœud de gestion avec les nœuds de données
Une fois la modification terminée, les nœuds node1 node2 node3 doivent redémarrer le service
#Delete Pool pool de ressources
1) Il existe un risque de perte de données dans la commande de suppression du pool de stockage. Ceph interdit ce type d'opération par défaut. L'administrateur doit activer l'opération de suppression du pool de stockage dans le fichier de configuration ceph.conf vim ceph.conf …
[
mon
]
mon autoriser la suppression du pool = vrai
2) Envoyez le fichier de configuration ceph.conf à tous les nœuds mon
ceph-deploy --overwrite-conf config push node01 node02 node03
3) Tous les nœuds mon redémarrent ceph-mon service
systemctl restart ceph-mon.target
4) Exécutez la commande delete Pool
ceph osd pool rm pool01 pool01 --yes-i-really-really-mean-it
Afficher l'état de l'OSD ceph osd status
Afficher l'utilisation de l'OSD
Deux : créer une interface MDS de système de fichiers CephFS
// opération de serveur
1) Créer le service mds
cd /etc/ceph
ceph-deploy mds créer node01 node02 node03 sur le nœud de gestion
2) Afficher le service mds de chaque nœud
ssh root@node01 systemctl status ceph-mds@node01
ssh root@node02 systemctl status ceph-mds@node02 ssh
root@node03 systemctl status ceph-mds@node03
3) Créez un pool de stockage et activez le système de fichiers ceph
Le système de fichiers ceph nécessite au moins deux pools rados, un pour le stockage des données et un pour le stockage des métadonnées. À ce stade, le pool de données est similaire au répertoire partagé du système de fichiers.
pool ceph osd créer cephfs_data 128 #Créer un pool de données
pool ceph osd créer cephfs_metadata 128 #Créer un pool de métadonnées
#Créer cephfs, format de commande : ceph fs new <FS_NAME> <CEPHFS_METADATA_NAME> <CEPHFS_DATA_NAME>
ceph fs new mycephfs cephfs_metadata cephfs_data #Activer ceph, le pool de métadonnées est à l'avant et le pool de données est à l'arrière
ceph fs ls #Voir cephfs
4) Vérifiez l'état du mds, l'un est actif et les deux autres sont en veille. Le travail en cours est le service mds ceph
sur node01
-s mds : mycephfs:1 {0=node01=up:active} 2 up:standby
ceph mds stat
mycephfs:1 {0=node01=up:active} 2 up:standby
5) Créer un utilisateur
Format de syntaxe : ceph fs autorise <fs_name> client.<client_id> <path-in-cephfs> rw
#Le compte est client.zhangsan, le nom d'utilisateur est zhangsan et zhangsan a des autorisations de lecture et d'écriture sur le répertoire racine / du système de fichiers ceph (et non le répertoire racine du système d'exploitation) ceph fs autorise mycephfs client.zhangsan /
rw | tee /etc/ceph/ zhangsan.porte-clés
# Le compte est client.lisi, le nom d'utilisateur est lisi, lisi n'a qu'un droit de lecture sur le répertoire racine / du système de fichiers et un droit de lecture et d'écriture sur le sous-répertoire /test du répertoire racine du système de fichiers ceph fs autoriser mycephfs client.lisi / r /
test rw | tee /etc/ceph/lisi.keyring
//opération cliente
1) Le client doit être dans le réseau public
2) Créez un répertoire de travail mkdir /etc/ceph sur le client
3) Copiez le fichier de configuration ceph ceph.conf et les fichiers de trousseau de clés de compte zhangsan.keyring, lisi.keyring
scp ceph.conf zhangsan.keyring lisi.keyring root@client:/etc/ceph sur le nœud de gestion ceph vers le client
4) Installez le package ceph côté client
cd /opt
wget https://download.ceph.com/rpm-nautilus/el7/noarch/ceph-release-1-1.el7.noarch.rpm --no-check - certificat
rpm -ivh ceph-release-1-1.el7.noarch.rpm
yum install -y ceph
5) Créez un fichier de clé secrète côté client
cd /etc/ceph
ceph-authtool -n client.zhangsan -p zhangsan.keyring > zhangsan.key #Exportez la clé secrète de l'utilisateur zhangsan vers zhangsan.keyl
ceph-authtool - n client.lisi -p lisi.keyring > lisi.key
6) Montage client
●Méthode 1 : Format de syntaxe basé sur le noyau
: mount -t ceph node01:6789,node02:6789,node03:6789:/ <répertoire de point de montage local> -o name=<nom d'utilisateur>,secret=<clé secrète> mount
- t ceph node01:6789,node02:6789,node03:6789:/ <répertoire de point de montage local> -o name=<nom d'utilisateur>,secretfile=<fichier de clé secrète>
Exemple :
mkdir -p /data/zhangsan
mount -t ceph node01:6789,node02:6789,node03:6789:/ /data/zhangsan -o name=zhangsan,secretfile=/etc/ceph/zhangsan.key
Exemple :
mkdir -p /data/lisi
mount -t ceph node01:6789,node02:6789,node03:6789:/ /data/lisi -o name=lisi,secretfile=/etc/ceph/lisi.key
#Verify user permissions
cd /data/lisi
echo 123 > 2.txt
-bash: 2.txt : Autorisations insuffisantes
echo 123 > test/2.txt
chat test/2.txt
123
Exemple 3 :
#Stop the mds service on node02
ssh root@node02 "systemctl stop ceph-mds@node02"
ceph -s
#Testez le point de montage du client est toujours disponible, si vous arrêtez tous les mds, le client ne sera pas disponible
●Méthode 2 : basée sur l'outil fuse
1) Copiez le fichier de configuration ceph ceph.conf et les fichiers de trousseau de clés de compte zhangsan.keyring, lisi.keyring
scp ceph.client.admin.keyring root@client sur le nœud de gestion ceph vers le client :/etc/ceph
2) Installez ceph-fuse côté client
yum install -y ceph-fuse
3) Client mount
cd /opt/test
ceph-fuse -m node01:6789,node02:6789,node03:6789 /data/aa [-o nonempty] #Lors du montage, si le point de montage n'est pas vide, il montera Échec pour charger, spécifiez -o non vide peut être ignoré
Créer une interface RBD du système de stockage de blocs Ceph
1. Créer un pool de stockage nommé rbd-demo dédié à RBD (fonctionnement du nœud d'administration)
ceph osd pool create rbd-demo 64 64
2. Convertissez le pool de stockage en mode RBD
ceph osd pool application enable rbd-demo rbd
3. Initialisez le pool de stockage
rbd pool init -p rbd-demo # -p équivaut à --pool
4. Créez un miroir
rbd create -p rbd-demo --image rbd-demo1.img --size 10G
Peut être abrégé en :
rbd create rbd-demo/rbd-demo2.img --size 10G
5. Gestion des miroirs
//Vérifiez quels miroirs existent sous le pool de stockage
rbd ls -l -p rbd-demo
//Afficher les détails de l'image
rbd info -p rbd-demo --image rbd-demo1.img
image rbd 'rbd-demo.img' :
taille 10 Gio dans 2560 objets #La taille de l'image miroir et le nombre de bandes qu'elle est divisée en
ordre 22 (objets 4 Mio) #Le nombre de bandes, la plage effective est de 12 à 25, correspondant à 4K à 32M, et 22 représente 2 à la puissance 22, soit exactement 4M snapshot_count
: 0 , la valeur par défaut est de 2 fonctionnalités : layering , exclusive-lock, object-map, fast-diff, deep-flatten #Features of the current image op_features: #Optional features flags:
//Modifier la taille de l'image
rbd resize -p rbd-demo --image rbd-demo1.img --size 20G
rbd info -p rbd-demo --image rbd-demo1.img
#Utilisez resize pour ajuster la taille de l'image. Il est généralement recommandé de ne faire qu'augmenter mais pas de diminuer. Si c'est pour diminuer, vous devez ajouter l'option --allow-shrink rbd resize
-p rbd-demo --image rbd -demo1.img --taille 5G --allow-shrink
//Supprimer le miroir
#Supprimer directement le miroir
rbd rm -p rbd-demo --image rbd-demo2.img
rbd remove rbd-demo/rbd-demo2.img
#Il est recommandé d'utiliser la commande trash. Cette commande supprime l'image dans la corbeille. Si vous souhaitez la récupérer, vous pouvez restaurer
rbd trash move rbd-demo/rbd-demo1.img
rbd ls -l -p rbd-démo
rbd corbeille liste -p rbd-demo
5fc98fe1f304 rbd-demo1.img
#Restaurer l'image
rbd corbeille restaurer rbd-demo/5fc98fe1f304
rbd ls -l -p rbd-démo
6. Utilisation du client Linux
Il existe deux manières pour le client d'utiliser RBD :
● Mapper l'image sur le périphérique de bloc local du système via le module de noyau KRBD, généralement le fichier de configuration est : /dev/rbd* ● L'autre
via l'interface librbd, généralement la machine virtuelle KVM utilise ce type d'interface.
Cet exemple utilise principalement le client Linux pour monter l'image RBD en tant que disque local. Avant de commencer, vous devez installer le package ceph-common sur les nœuds clients requis, car le client doit appeler la commande rbd pour mapper l'image RBD sur le local en tant que disque dur commun. Et vous devez également copier le fichier de configuration ceph.conf et le fichier de trousseau de clés d'autorisation sur le nœud correspondant.
Gérer les opérations de nœud
//Créez et autorisez un utilisateur sur le nœud de gestion à accéder au pool de stockage RBD spécifié
#Exemple, spécifiez l'ID utilisateur comme client.osd-mount, disposez de toutes les autorisations sur OSD et disposez d'autorisations en lecture seule sur Mon
ceph auth get- or-create client.osd-mount osd "allow * pool=rbd-demo" mon "allow r" > /etc/ceph/ceph.client.osd-mount.keyring
//Modifier les fonctionnalités d'image RBD, CentOS7 ne prend en charge que les fonctionnalités de superposition et de segmentation par défaut, vous devez désactiver les autres fonctionnalités
.
//Envoie le fichier de trousseau de clés de l'utilisateur et le fichier ceph.conf au répertoire /etc/ceph du client
cd /etc/ceph
scp ceph.client.osd-mount.keyring ceph.conf root@client:/etc/ceph
// opération du client Linux
#Installer le paquet ceph-common
yum install -y ceph-common
#Exécuter le mappage client
cd /etc/ceph
rbd map rbd-demo/rbd-demo1.img --keyring /etc/ceph/ceph.client.osd-mount.keyring --user osd-mount
#Exécuter le mappage client
cd /etc/ceph
rbd map rbd-demo/rbd-demo1.img --keyring /etc/ceph/ceph.client.osd-mount.keyring --user osd-mount
#View mapping
rbd showmapped
rbd device list
#Disconnect mapping
rbd unmap rbd-demo/rbd-demo1.img
#Formater et monter
mkfs.xfs /dev/rbd0
mkdir -p /data/bb
mount /dev/rbd0 /data/bb
#Extension en ligne
Ajuster la taille de l'image sur le nœud de gestion
rbd resize rbd-demo/rbd-demo1.img --size 30G
Actualiser le fichier de périphérique
xfs_growfs /dev/rbd0 côté client #Actualiser la capacité du système de fichiers xfs
resize2fs /dev/rbd0 #Actualiser la capacité du système de fichiers de type ext4
7. Gestion des instantanés
La prise d'un instantané de l'image rbd peut conserver l'historique d'état de l'image, et elle peut également utiliser la technologie de superposition de l'instantané pour cloner l'instantané dans une nouvelle image.
//Ecrit un fichier sur le client
echo 1111 > /data/bb/11.txt
echo 2222 > /data/bb/22.txt
echo 3333 > /data/bb/33.txt
//Créer un instantané de l'image sur le nœud de gestion
rbd snap create --pool rbd-demo --image rbd-demo1.img --snap demo1_snap1
Peut être abrégé en :
rbd snap create rbd-demo/rbd-demo1.img@demo1_snap1
// Liste tous les instantanés de l'image spécifiée
rbd snap list rbd-demo/rbd-demo1.img
# Sortie au format json :
rbd snap list rbd-demo/rbd-demo1.img --format json --pretty-format
//Rollback mirror to specified
Avant de restaurer l'instantané, vous devez démapper le miroir, puis revenir en arrière.
#Opérer côté client
rm -rf /data/bb/*
umount /data/bb
rbd unmap rbd-demo/rbd-demo1.img
#Operate
rbd snap rollback sur le nœud de gestion rbd-demo/rbd-demo1.img@demo1_snap1
# Remappez et montez
la carte rbd côté client rbd-demo/rbd-demo1.img --keyring /etc/ceph/ceph.client.osd-mount.keyring --user osd-mount mount
/dev/rbd0 /data / bb
ls /data/bb # Trouvé que les données ont été restaurées
// Limite le nombre d'instantanés pouvant être créés par le miroir
rbd snap limit set rbd-demo/rbd-demo1.img --limit 3
#Remove the limit:
rbd snap limit clear rbd-demo/rbd-demo1.img
//Supprimer l'instantané
#Supprimez l'instantané spécifié :
rbd snap rm rbd-demo/rbd-demo1.img@demo1_snap1
#Supprimer tous les instantanés :
rbd snap purge rbd-demo/rbd-demo1.img
// superposition d'instantanés
La superposition d'instantanés prend en charge l'utilisation de clones d'instantanés pour générer de nouvelles images, qui sont presque identiques aux images créées directement et prennent en charge toutes les opérations sur les images. La seule différence est que l'image clonée fait référence à un instantané en amont en lecture seule, et cet instantané doit être protégé.
#snapshot clone
1) Définissez l'instantané en amont en mode protégé :
rbd snap create rbd-demo/rbd-demo1.img@demo1_snap666
rbd snap protect rbd-demo/rbd-demo1.img@demo1_snap666
2) Clonez l'instantané en tant que nouvelle image
rbd clone rbd-demo/rbd-demo1.img@demo1_snap666 --dest rbd-demo/rbd-demo666.img
rbd ls -p rbd-démo
3) Commande pour afficher les sous-miroirs
rbd enfants rbd-demo/rbd-demo1.img@demo1_snap666 de l'instantané une fois le clonage terminé
//instantané aplati
Généralement, l'image obtenue par clonage d'instantané conserve une référence à l'instantané parent. À ce stade, l'instantané parent ne peut pas être supprimé, sinon il sera affecté.
rbd snap rm rbd-demo/rbd-demo1.img@demo1_snap666
#l'instantané d'erreur 'demo1_snap666' est protégé contre la suppression.
Si vous souhaitez supprimer un instantané mais que vous souhaitez conserver son sous-miroir, vous devez d'abord aplatir son sous-miroir, et le temps d'aplatissement dépend de la taille du miroir 1) Aplatir
le sous-miroir
rbd flatten rbd-demo/rbd-demo666.img
2) Déprotéger l'instantané
rbd snap déprotéger rbd-demo/rbd-demo1.img@demo1_snap666
3) Supprimez l'instantané
rbd snap rm rbd-demo/rbd-demo1.img@demo1_snap666
rbd ls -l -p rbd-demo #Après avoir supprimé l'instantané, vérifiez que le sous-miroir existe toujours
8. Exportation et importation d'images miroir
//Exporter l'image
rbd export rbd-demo/rbd-demo1.img /opt/rbd-demo1.img
//Importer l'image
#Désinstaller le client mount et démapper
umount /data/bb
rbd unmap rbd-demo/rbd-demo1.img
#Effacer tous les instantanés sous le miroir et supprimer le miroir
rbd snap purge rbd-demo/rbd-demo1.img
rbd rm rbd-demo/rbd-demo1.img
rbd ls -l -p rbd-démo
#import miroir
rbd import /opt/rbd-demo1.img rbd-demo/rbd-demo1.img
rbd ls -l -p rbd-démo
Créer l'interface RGW du système de stockage d'objets Ceph
1. Concept de stockage d'objets
Le stockage d'objets (stockage d'objets) est une méthode de stockage pour les données non structurées. Chaque élément de données dans le stockage d'objets est stocké en tant qu'objet séparé avec une adresse unique pour identifier les données objet. Il est généralement utilisé dans un environnement de cloud computing.
Contrairement aux autres méthodes de stockage de données, le stockage basé sur les objets n'utilise pas d'arborescences de répertoires.
Bien qu'il existe des différences dans la conception et la mise en œuvre, la plupart des systèmes de stockage d'objets présentent des types de ressources de base similaires au monde extérieur. Du point de vue du client, il est divisé en unités logiques suivantes :
Amazon S3 :
Fournit
1. Utilisateur (User)
2. Seau de stockage (Bucket)
3. Object (Object)
La relation entre les trois est :
1. L'utilisateur stocke les objets dans le compartiment sur le système
2. Le compartiment appartient à un certain utilisateur et peut contenir des objets. Un compartiment est utilisé pour stocker plusieurs objets
3. Le même utilisateur peut avoir plusieurs compartiments, différents utilisateurs sont autorisés à utiliser des compartiments avec le même nom, de sorte que le nom d'utilisateur peut être utilisé comme espace de noms du compartiment
●OpenStack Swift :
fournit l'utilisateur, le conteneur et l'objet correspondant respectivement aux utilisateurs, aux compartiments de stockage et aux objets, mais il fournit également un compte de composant parent pour l'utilisateur, qui est utilisé pour représenter un projet ou un utilisateur, de sorte qu'un compte peut contenir un à plusieurs utilisateurs , ils peuvent partager le même ensemble de conteneurs et fournir des espaces de noms pour les conteneurs
● RadosGW :
fournit l'utilisateur, le sous-utilisateur, le compartiment et l'objet. L'utilisateur correspond à l'utilisateur de S3 et le sous-utilisateur correspond à l'utilisateur de Swift. Cependant, ni l'utilisateur ni le sous-utilisateur ne prennent en charge la fourniture d'espaces de noms pour les compartiments, de sorte que les compartiments de stockage des différents utilisateurs Le même nom n'est pas autorisé ; cependant, depuis la version bijou, RadosGW a introduit un locataire (tenant) pour fournir des espaces de noms pour les utilisateurs et les buckets, mais il s'agit d'un composant facultatif.
Il ressort de ce qui précède que les types de ressources de base de la plupart des stockages d'objets sont similaires, tels qu'Amazon S3, OpenStack Swift et RadosGw. Parmi eux, S3 et Swift ne sont pas compatibles entre eux. Afin d'être compatible avec S3 et Swift, Ceph fournit une couche d'abstraction de données RGW (RadosGateway) et une couche de gestion sur la base du cluster RadosGW, qui peut être nativement compatible avec S3 et API rapide.
S3 et Swift peuvent compléter l'échange de données basé sur http ou https, et le Civetweb intégré de RadosGW fournit des services. Il peut également prendre en charge les serveurs proxy, y compris nginx, haproxy, etc. pour recevoir les demandes des utilisateurs sous forme de proxys, puis les transmettre. les au processus RadosGW.
La fonction de RGW dépend de l'implémentation du démon de passerelle d'objet, qui est chargé de fournir l'interface API REST au client. Pour les exigences d'équilibrage de charge redondantes, il existe généralement plusieurs démons RadosGW sur un cluster Ceph.
2. Créez une interface RGW.
Si vous devez utiliser une interface telle que S3 ou Swift, vous devez déployer/créer une interface RadosGW. RadosGW est généralement utilisé comme stockage d'objets, similaire à Alibaba Cloud OSS.
//Créer un processus démon RGW sur le nœud de gestion (ce processus nécessite généralement une haute disponibilité dans un environnement de production, qui sera présenté ultérieurement)
cd /etc/ceph
ceph-deploy rgw create node01
ceph -s
# Après une création réussie, par défaut, une série de
pools de stockage pour
RGW sera automatiquement créée . default.rgw.buckets.index #est l'information de compartiment rgw, générée après l'écriture des données default.rgw.buckets.data #est l'information réelle des données stockées, générée après l'écriture des données
#Par défaut, RGW écoute le port 7480
ssh root@node01 netstat -lntp | grep 7480
curl node01:7480
<?xml version="1.0" encoding="UTF-8"?><ListAllMyBucketsResult xmlns="http://s3.amazonaws.com/doc/2006-03-01/"> <
ListAllMyBucketsResult xmlns= "http://s3.amazonaws.com/doc/2006-03-01/">
<Owner>
<ID>anonyme</ID>
<DisplayName/>
</Owner>
<Buckets/>
</ListAllMyBucketsResult>
//Activer http+https, changer le
démon du port de surveillance RadosGW mis en œuvre en interne par Civetweb, grâce à la configuration de Civetweb peut compléter la gestion de base de RadosGW.
#Pour activer SSL sur Civetweb, vous avez d'abord besoin d'un certificat et générez un certificat sur le nœud rgw
node1 node operation
1) Générer la clé privée du certificat CA :
openssl genrsa -out civetweb.key 2048
2) Générer la clé publique du certificat CA :
openssl req -new -x509 -key civetweb.key -out civetweb.crt -days 3650 -subj "/CN=192.168.80.11"
#3. Fusionner le certificat généré dans pem
cat civetweb.key civetweb.crt > /etc/ceph/civetweb.pem
#Changer le port d'écoute
Civetweb écoute par défaut sur le port 7480 et fournit le protocole http.Si vous avez besoin de modifier la configuration, vous devez éditer le fichier de configuration ceph.conf sur le nœud de gestion cd /etc
/ceph
vim ceph.conf
......
[client.rgw.node01]
rgw_host = node01
rgw_frontends = "civetweb port=80+443s ssl_certificate=/etc/ceph/civetweb.pem num_threads=500 request_timeout_ms=60000"
-------------------------------------------------- ----------
●rgw_host : le nom ou l'adresse IP RadosGW correspondant
●rgw_frontends : configurez ici le port d'écoute, s'il faut utiliser https, et quelques configurations courantes :
•port : s'il s'agit d'un port https, il doit être derrière le port Ajouter un s.
• ssl_certificate : spécifie le chemin d'accès au certificat.
• num_threads : le nombre maximum de connexions simultanées, la valeur par défaut est 50, ajustée en fonction des besoins, généralement cette valeur doit être supérieure dans l'environnement du cluster de production • request_timeout_ms : délai d'
envoi et de réception, en ms, la valeur par défaut est
30000 chemin du journal, la valeur par défaut est vide
error_log_file : chemin du journal des erreurs, la valeur par défaut est vide
--------------------------------- --- ------------------------
# Après avoir modifié le fichier de configuration ceph.conf, vous devez redémarrer le service RadosGW correspondant, puis pousser le fichier de configuration
ceph-deploy --overwrite-conf config push node0{1..3}
ssh root@node01 systemctl redémarrer ceph-radosgw.target
#Afficher le port sur le nœud rgw
netstat -lntp | grep -w 80
netstat -lntp | grep 443
#Vérification d'accès côté client
curl http://192.168.80.11:80
curl -k https://192.168.80.11:443
// Créer un compte RadosGW
Utilisez la commande radosgw-admin sur le nœud de gestion pour créer un compte RadosGW
radosgw-admin user create --uid="rgwuser" --display-name="rgw test user"
......
"keys": [
{ "user": "rgwuser", "access_key": "ER0SCVRJWNRIKFGQD31H" , "clé_secrète": "YKYjk7L4FfAu8GHeQarIlXodjtj1BXVaxpKv2Nna" } ],
#Une fois la création réussie, les informations de base de l'utilisateur seront affichées et les deux informations les plus importantes sont access_key et secret_key. Une fois l'utilisateur créé avec succès, si vous oubliez les informations de l'utilisateur, vous pouvez utiliser la commande suivante pour afficher
les informations de l'utilisateur radosgw-admin --uid="rgwuser"
// Test d'accès à l'interface S3
1) Installez python3 et python3-pip côté client
yum install -y python3 python3-pip
python3 -V
Python 3.6.8
pip3 -V
pip 9.0.3 de /usr/lib/python3.6/site-packages (python 3.6)
2) Installez le module boto pour tester la connexion à S3
pip3 install boto
3) Tester l'accès à l'interface S3
echo 123123 > /opt/123.txt
vim test.py
#coding:utf-8
import ssl
import boto.s3.connection
from boto.s3.key import Key
try:
_create_unverified_https_context = ssl._create_unverified_context
except AttributeError:
pass
else:
ssl._create_default_https_context = _create _unverified_https_context
#test user's keys information
access_key = "ER0SCVRJWNRIKFGQD31H" #Entrez la access_key du compte RadosGW
secret_key = "YKYjk7L4FfAu8GHeQarIlXodjtj1BXVaxpKv2Nna" #Entrez la secret_key du compte RadosGW
#rgw's ip and port
host = "192.168.80.11" #Entrez l'adresse réseau publique de l'interface RGW
#Si vous utilisez le port 443, le lien suivant doit être défini is_secure=True
port = 443
#Si vous utilisez le port 80, le lien suivant doit être défini is_secure=False
#port = 80
conn = boto.connect_s3(
aws_access_key_id=access_key,
aws_secret_access_key =secret_key,
host =host,
port=port,
is_secure=True,
validate_certs=False,
calling_format=boto.s3.connection.OrdinaryCallingFormat()
)
#1 : Créez un compartiment
#conn.create_bucket(bucket_name='bucket01')
#conn.create_bucket(bucket_name='bucket02')
#2: Déterminez s'il existe, renvoyez None
exists = conn.lookup('bucket01')
print(exists)
#exists = conn.lookup('bucket02')
#print(exists)
#3 : Obtenez un compartiment
#bucket1 = conn.get_bucket('bucket01')
#bucket2 = conn.get_bucket('bucket02')
#4 : Afficher les fichiers sous un compartiment
#print(list(bucket1.list()))
#print(list(bucket2.list()))
#5 : Stockez les données sur s3, la source de données peut être un fichier, un flux ou une chaîne
#5.1, téléchargez des fichiers
#bucket1 = conn.get_bucket('bucket01')
# La valeur de name est la clé des données
#key = Key (bucket= bucket1, name='myfile')
#key.set_contents_from_filename('/opt/123.txt')
# Lire le contenu du fichier dans s3, renvoyer la chaîne qui est le contenu du fichier 123.txt
#print(key .get_contents_as_string())
#5.2, upload string
# Si vous avez déjà obtenu l'objet auparavant, vous n'avez pas besoin de l'obtenir à plusieurs reprises
bucket2 = conn.get_bucket('bucket02')
key = Key(bucket=bucket2, name='mystr')
key. set_contents_from_string('hello world')
print(key. get_contents_as_string())
#6 : Pour supprimer un bucket, toutes les clés du bucket doivent être supprimées lors de la suppression du bucket lui-même
bucket1 = conn.get_bucket('bucket01')
for key in bucket1 :
key.delete()
bucket1.delete()
4) Suivez les étapes ci-dessus pour exécuter le test de script python
python3 test.py
Simulation et récupération de panne OSD
1. Simuler une panne OSD
S'il y a des milliers d'osd dans le cluster ceph, il est normal que 2 à 3 pannes chaque jour, nous pouvons simuler un osd
#Si le démon osd fonctionne normalement, l'osd down reviendra rapidement à la normale, vous devez donc arrêter le démon
ssh root@node01 systemctl stop ceph-osd@0
#down 掉 osd
ceph osd down 0
arborescence ceph osd
2. Expulsez l'osd cassé du cluster
//Méthode 1 :
#Déplacez osd.0 hors du cluster, le cluster commencera à synchroniser automatiquement les données
ceph osd sur osd.0
#Remove osd.0 de crushmap
ceph osd crush remove osd.0
#Supprimez les informations de compte correspondant au processus démon
ceph auth rm osd.0
liste d'authentification ceph
#Supprimer osd.0
ceph osd rm osd.0
ceph osd stat
ceph -s
//Méthode 2 :
ceph osd en sortie osd.0
# En suivant les étapes complètes, supprimez la configuration de l'osd cassé dans le fichier de configuration
ceph osd purge osd.0 --yes-i-really-mean-it
3. Rejoindre le cluster après avoir réparé l'osd cassé d'origine
#Créer osd sur le nœud osd, pas besoin de spécifier le nom, il générera automatiquement
cd /etc/ceph selon le numéro de série
créer ceph osd
#创建账户
ceph-authtool --create-keyring /etc/ceph/ceph.osd.0.keyring --gen-key -n osd.0 --cap mon 'autoriser le profil osd' --cap mgr 'autoriser le profil osd ' --cap osd 'autoriser *'
#Importer la nouvelle clé de compte
ceph auth import -i /etc/ceph/ceph.osd.0.keyring
liste d'authentification ceph
#Mettre à jour le fichier de trousseau de clés dans le dossier osd correspondant
ceph auth get-or-create osd.0 -o /var/lib/ceph/osd/ceph-0/keyring
#Join crushmap
ceph osd crush add osd.0 1.000 host=node01 #1.000 représente le poids
#Rejoindre le cluster
ceph osd dans osd.0
arborescence ceph osd
#Redémarrer le démon osd
systemctl restart ceph-osd@0
ceph osd tree #Après un certain temps, l'état de l'osd est activé
//如果重启失败
报错：
La tâche pour [email protected] a échoué car le démarrage du service a été tenté trop souvent. Voir "systemctl status [email protected]" et "journalctl -xe" pour plus de détails.
Pour forcer un démarrage, utilisez à nouveau "systemctl reset-failed [email protected]" suivi de "systemctl start [email protected]".
#运行
systemctl reset-failed [email protected] && systemctl restart [email protected]