BlaireauLinux - Contributions [fr]

Trucs & astuces

2025-10-10T14:43:55Z

AdminWiki : /* Afficher en colonnes */

[[Category:linux]]

=Vérifier le type d'un fichier=

Si vous ne savez plus ce que contient un fichier, utilisez la commande file qui vous le dira, parfois de façon très détaillée.

Exemples :

$ file toto.txt
toto.txt: ASCII text
$ file "01 - Surfing With the Alien.ogg"
01 - Surfing With the Alien.ogg: Ogg data, Vorbis audio, stereo, 44100 Hz, ~160000 bps, created by: Xiph.Org libVorbis I (1.1.0 RC1)

=Lister les partitions du disque dur=

Pour obtenir la liste des partitions de vos disques, tapez

fdisk -l

=Faire une calculatrice sous bash=

On peut facilement faire des calculs directement en ligne de commande. Attention, ça ne fonctionne qu'avec des nombres entiers.

# echo $((1 + 2 * 3 ))
# 7 Ca marche aussi avec des variables.
# i=5; echo $(( $i + $i ))
# 10 Le plus efficace reste quand même d'utiliser "bc".

=Voir le partage de connexions=

Pour voir les connexion en cours sur votre machine tapez :

netstat -M

=Rechercher un texte dans plusieurs fichiers=

==si tous les fichiers sont dans le même répertoire==

# grep "mon_texte" *

On va alors obtenir la liste des fichiers qui contiennent le texte, suivie de la ligne du fichier contenant le texte.

Pour voir le numéro de la ligne concernée on mettra '''grep -n'''.

Pour ne voir que le nom des fichiers on mettre '''grep -l'''.

==si les fichiers sont dans des répertoires différents==

# find . -type f -exec grep -l "mon_texte" {} \;

explication :

* find . => rechercher à partir du répertoire courant
* -type f => on cherche un fichier
* -exec => à chaque fichier trouvé on exécute la commande qui suit
* grep -l "mon_texte" {} => on recherche "mon_texte" dans les fichiers ({} remplace le nom des fichiers trouvés) et on affiche le nom du fichier
* \; => fin de l'option exec

'''remarques'' : cette procédure n'affiche que le nom des fichiers, mais pas la ligne de texte correspondante. Si on veut voir la ligne de texte, il faut retirer l'iption "-l", mais dans ce cas on ne voit plus le nom du fichier... On peut encore remplacer "-l" par "-n", dans ce cas on voit la ligne de texte avec le numéro de ligne, mais là encore, on ne voit plus le nom du fichier. Je n'ai pas trouvé de moyen simple (sans passer par un script) d'afficher à la fois le nom du fichier et la ligne de texte. Si quelqu'un sait faire, ça m'intéresse ;-).

=Dernière connexion=

Pour savoir quand l'utilisateur fred s'est connecté la dernière fois :

lastlog -u fred

=Surveiller à intervalles réguliers=

La commande watch permet de voir le résultat d'une commande à intervalles réguliers :

watch cat /proc/meminfo

==> permet de voir l'évolution de la mémoire

watch -n 6 ls /home/fred

==> permet de voir le contenu de /home/fred (utile pour voir la progression d'une copie de fichiers par exemple).
L'option -n 6 permet de rafraîchir toutes les 6 secondes (2 secondes par défaut).

=Geler / dégeler un terminal=

pour geler :
ctrl-s
pour dégeler :
ctrl-q

=Ignorer les alias=

Si vous voulez utiliser une commande sans passer par les alias pour retrouver ses paramètres par défaut, précédez la d'un \.
Par exemple :
\ls

=Code ASCII d'une touche=

Pour connaitre le code ASCII d'une touche, faites : '''showkey -a''' puis appuyez sur la/les touche(s) désirées. Tapez '''ctrl-d''' pour sortir.

=Concaténer des PDF=

Pour concaténer des fichiers PDF :
texexec --pdfarrange --result=fic-final.pdf fic1.pdf fic2.pdf fic3.pdf

=changer la résolution de l'écran en mode texte=

Lorsqu'on est sur un serveur, on est souvant en mode texte. Par défaut, on est en 640x480, ce qui n'est pas toujours pratique. Avec grub, on peut facilement changer ça en éditant le fichier /boot/grub/menu.lst, et en ajoutant "vga=711" à la fin de la ligne qui commence par "kernel". La valeur "771" est à adapter en fonction du tableau ci-dessous. La modification ne sera prise en compte qu'au prochain reboot.

Exemple de ligne sur CentOS 5.3 pour passer en 800x600 en 8 bits :
kernel /vmlinuz-2.6.18-164.el5 ro root=/dev/vg00/lvroot vga=771

{|class="wikitable alternance centre"
|-
| || 640x480 || 800x600 || 1024x768 || 1280x1024 || 1600x1200 || demander à l'utilisateur
|-
| 8 bits || 769 || 771 || 773 || 775 || 796 || ask
|-
| 16 bits || 785 || 788 || 791 || 794 || 798 || ask
|-
| 32 bits || 786 || 789 || 792 || 795 || 799 || ask
|}

=Afficher en colonnes=
Parfois, il peut être utile d'afficher une liste ou la sortie d'une commande en colonne. L'utilitaire "pr" permet de faire ça. On peut choisir le nombre de colonne, la largeur d'affichage et si l'ordre se fait par ligne ou par colonnes. Voici deux exemples, un peu bidon, certes, mais clairs.

Options : -4 pour le nombre de colonnes, -w pour la largeur d'affichage en nombre de caractères (72 par défaut), -a pour classer par ligne (voir exemple 2), -t sinon ça ne va pas fonctionner dans ce cas.

# ls -1 /etc | pr -t -4 -w 80 |head -6
abrt filesystems ld.so.conf.d phpMyAdmin
adjtime filezilla libaudit.conf pinforc
aliases firefox libblockdev pkcs11
alsa firewalld libibverbs.d pkgconfig
alternatives flatpak libnl pki
anaconda flexiblasrc libreport plymouth

# ls -1 /etc | pr -t -4 -w 80 -a |head -6
abrt adjtime aliases alsa
alternatives anaconda anacrontab anthy-unicode.conf
asound.conf audit authselect avahi
bash_completion.d bashrc bindresvport.blackl binfmt.d
bluetooth brlapi.key brltty brltty.conf
ceph chkconfig.d chromium chrony.conf

Trucs & astuces

2025-10-10T14:43:07Z

AdminWiki : /* Afficher en colonnes */

[[Category:linux]]

=Vérifier le type d'un fichier=

Si vous ne savez plus ce que contient un fichier, utilisez la commande file qui vous le dira, parfois de façon très détaillée.

Exemples :

$ file toto.txt
toto.txt: ASCII text
$ file "01 - Surfing With the Alien.ogg"
01 - Surfing With the Alien.ogg: Ogg data, Vorbis audio, stereo, 44100 Hz, ~160000 bps, created by: Xiph.Org libVorbis I (1.1.0 RC1)

=Lister les partitions du disque dur=

Pour obtenir la liste des partitions de vos disques, tapez

fdisk -l

=Faire une calculatrice sous bash=

On peut facilement faire des calculs directement en ligne de commande. Attention, ça ne fonctionne qu'avec des nombres entiers.

# echo $((1 + 2 * 3 ))
# 7 Ca marche aussi avec des variables.
# i=5; echo $(( $i + $i ))
# 10 Le plus efficace reste quand même d'utiliser "bc".

=Voir le partage de connexions=

Pour voir les connexion en cours sur votre machine tapez :

netstat -M

=Rechercher un texte dans plusieurs fichiers=

==si tous les fichiers sont dans le même répertoire==

# grep "mon_texte" *

On va alors obtenir la liste des fichiers qui contiennent le texte, suivie de la ligne du fichier contenant le texte.

Pour voir le numéro de la ligne concernée on mettra '''grep -n'''.

Pour ne voir que le nom des fichiers on mettre '''grep -l'''.

==si les fichiers sont dans des répertoires différents==

# find . -type f -exec grep -l "mon_texte" {} \;

explication :

* find . => rechercher à partir du répertoire courant
* -type f => on cherche un fichier
* -exec => à chaque fichier trouvé on exécute la commande qui suit
* grep -l "mon_texte" {} => on recherche "mon_texte" dans les fichiers ({} remplace le nom des fichiers trouvés) et on affiche le nom du fichier
* \; => fin de l'option exec

'''remarques'' : cette procédure n'affiche que le nom des fichiers, mais pas la ligne de texte correspondante. Si on veut voir la ligne de texte, il faut retirer l'iption "-l", mais dans ce cas on ne voit plus le nom du fichier... On peut encore remplacer "-l" par "-n", dans ce cas on voit la ligne de texte avec le numéro de ligne, mais là encore, on ne voit plus le nom du fichier. Je n'ai pas trouvé de moyen simple (sans passer par un script) d'afficher à la fois le nom du fichier et la ligne de texte. Si quelqu'un sait faire, ça m'intéresse ;-).

=Dernière connexion=

Pour savoir quand l'utilisateur fred s'est connecté la dernière fois :

lastlog -u fred

=Surveiller à intervalles réguliers=

La commande watch permet de voir le résultat d'une commande à intervalles réguliers :

watch cat /proc/meminfo

==> permet de voir l'évolution de la mémoire

watch -n 6 ls /home/fred

==> permet de voir le contenu de /home/fred (utile pour voir la progression d'une copie de fichiers par exemple).
L'option -n 6 permet de rafraîchir toutes les 6 secondes (2 secondes par défaut).

=Geler / dégeler un terminal=

pour geler :
ctrl-s
pour dégeler :
ctrl-q

=Ignorer les alias=

Si vous voulez utiliser une commande sans passer par les alias pour retrouver ses paramètres par défaut, précédez la d'un \.
Par exemple :
\ls

=Code ASCII d'une touche=

Pour connaitre le code ASCII d'une touche, faites : '''showkey -a''' puis appuyez sur la/les touche(s) désirées. Tapez '''ctrl-d''' pour sortir.

=Concaténer des PDF=

Pour concaténer des fichiers PDF :
texexec --pdfarrange --result=fic-final.pdf fic1.pdf fic2.pdf fic3.pdf

=changer la résolution de l'écran en mode texte=

Lorsqu'on est sur un serveur, on est souvant en mode texte. Par défaut, on est en 640x480, ce qui n'est pas toujours pratique. Avec grub, on peut facilement changer ça en éditant le fichier /boot/grub/menu.lst, et en ajoutant "vga=711" à la fin de la ligne qui commence par "kernel". La valeur "771" est à adapter en fonction du tableau ci-dessous. La modification ne sera prise en compte qu'au prochain reboot.

Exemple de ligne sur CentOS 5.3 pour passer en 800x600 en 8 bits :
kernel /vmlinuz-2.6.18-164.el5 ro root=/dev/vg00/lvroot vga=771

{|class="wikitable alternance centre"
|-
| || 640x480 || 800x600 || 1024x768 || 1280x1024 || 1600x1200 || demander à l'utilisateur
|-
| 8 bits || 769 || 771 || 773 || 775 || 796 || ask
|-
| 16 bits || 785 || 788 || 791 || 794 || 798 || ask
|-
| 32 bits || 786 || 789 || 792 || 795 || 799 || ask
|}

=Afficher en colonnes=
Parfois, il peut être utile d'afficher une liste ou la sortie d'une commande en colonne. L'utilitaire "pr" permet de faire ça. On peut choisir le nombre de colonne, la largeur d'affichage et si l'ordre se fait par ligne ou par colonnes. Voici deux exemples, un peu bidon, certes, mais clairs.

Options : -4 pour le nombre de colonnes, -w pour la largeur d'affichage en nombre de caractères (72 par défaut), -t sinon ça ne va pas fonctionner dans ce cas.

# ls -1 /etc | pr -t -4 -w 80 |head -6
abrt filesystems ld.so.conf.d phpMyAdmin
adjtime filezilla libaudit.conf pinforc
aliases firefox libblockdev pkcs11
alsa firewalld libibverbs.d pkgconfig
alternatives flatpak libnl pki
anaconda flexiblasrc libreport plymouth

# ls -1 /etc | pr -t -4 -w 80 -a |head -6
abrt adjtime aliases alsa
alternatives anaconda anacrontab anthy-unicode.conf
asound.conf audit authselect avahi
bash_completion.d bashrc bindresvport.blackl binfmt.d
bluetooth brlapi.key brltty brltty.conf
ceph chkconfig.d chromium chrony.conf

Trucs & astuces

2025-10-10T14:39:00Z

AdminWiki : afficher en colonnes

[[Category:linux]]

=Vérifier le type d'un fichier=

Si vous ne savez plus ce que contient un fichier, utilisez la commande file qui vous le dira, parfois de façon très détaillée.

Exemples :

$ file toto.txt
toto.txt: ASCII text
$ file "01 - Surfing With the Alien.ogg"
01 - Surfing With the Alien.ogg: Ogg data, Vorbis audio, stereo, 44100 Hz, ~160000 bps, created by: Xiph.Org libVorbis I (1.1.0 RC1)

=Lister les partitions du disque dur=

Pour obtenir la liste des partitions de vos disques, tapez

fdisk -l

=Faire une calculatrice sous bash=

On peut facilement faire des calculs directement en ligne de commande. Attention, ça ne fonctionne qu'avec des nombres entiers.

# echo $((1 + 2 * 3 ))
# 7 Ca marche aussi avec des variables.
# i=5; echo $(( $i + $i ))
# 10 Le plus efficace reste quand même d'utiliser "bc".

=Voir le partage de connexions=

Pour voir les connexion en cours sur votre machine tapez :

netstat -M

=Rechercher un texte dans plusieurs fichiers=

==si tous les fichiers sont dans le même répertoire==

# grep "mon_texte" *

On va alors obtenir la liste des fichiers qui contiennent le texte, suivie de la ligne du fichier contenant le texte.

Pour voir le numéro de la ligne concernée on mettra '''grep -n'''.

Pour ne voir que le nom des fichiers on mettre '''grep -l'''.

==si les fichiers sont dans des répertoires différents==

# find . -type f -exec grep -l "mon_texte" {} \;

explication :

* find . => rechercher à partir du répertoire courant
* -type f => on cherche un fichier
* -exec => à chaque fichier trouvé on exécute la commande qui suit
* grep -l "mon_texte" {} => on recherche "mon_texte" dans les fichiers ({} remplace le nom des fichiers trouvés) et on affiche le nom du fichier
* \; => fin de l'option exec

'''remarques'' : cette procédure n'affiche que le nom des fichiers, mais pas la ligne de texte correspondante. Si on veut voir la ligne de texte, il faut retirer l'iption "-l", mais dans ce cas on ne voit plus le nom du fichier... On peut encore remplacer "-l" par "-n", dans ce cas on voit la ligne de texte avec le numéro de ligne, mais là encore, on ne voit plus le nom du fichier. Je n'ai pas trouvé de moyen simple (sans passer par un script) d'afficher à la fois le nom du fichier et la ligne de texte. Si quelqu'un sait faire, ça m'intéresse ;-).

=Dernière connexion=

Pour savoir quand l'utilisateur fred s'est connecté la dernière fois :

lastlog -u fred

=Surveiller à intervalles réguliers=

La commande watch permet de voir le résultat d'une commande à intervalles réguliers :

watch cat /proc/meminfo

==> permet de voir l'évolution de la mémoire

watch -n 6 ls /home/fred

==> permet de voir le contenu de /home/fred (utile pour voir la progression d'une copie de fichiers par exemple).
L'option -n 6 permet de rafraîchir toutes les 6 secondes (2 secondes par défaut).

=Geler / dégeler un terminal=

pour geler :
ctrl-s
pour dégeler :
ctrl-q

=Ignorer les alias=

Si vous voulez utiliser une commande sans passer par les alias pour retrouver ses paramètres par défaut, précédez la d'un \.
Par exemple :
\ls

=Code ASCII d'une touche=

Pour connaitre le code ASCII d'une touche, faites : '''showkey -a''' puis appuyez sur la/les touche(s) désirées. Tapez '''ctrl-d''' pour sortir.

=Concaténer des PDF=

Pour concaténer des fichiers PDF :
texexec --pdfarrange --result=fic-final.pdf fic1.pdf fic2.pdf fic3.pdf

=changer la résolution de l'écran en mode texte=

Lorsqu'on est sur un serveur, on est souvant en mode texte. Par défaut, on est en 640x480, ce qui n'est pas toujours pratique. Avec grub, on peut facilement changer ça en éditant le fichier /boot/grub/menu.lst, et en ajoutant "vga=711" à la fin de la ligne qui commence par "kernel". La valeur "771" est à adapter en fonction du tableau ci-dessous. La modification ne sera prise en compte qu'au prochain reboot.

Exemple de ligne sur CentOS 5.3 pour passer en 800x600 en 8 bits :
kernel /vmlinuz-2.6.18-164.el5 ro root=/dev/vg00/lvroot vga=771

{|class="wikitable alternance centre"
|-
| || 640x480 || 800x600 || 1024x768 || 1280x1024 || 1600x1200 || demander à l'utilisateur
|-
| 8 bits || 769 || 771 || 773 || 775 || 796 || ask
|-
| 16 bits || 785 || 788 || 791 || 794 || 798 || ask
|-
| 32 bits || 786 || 789 || 792 || 795 || 799 || ask
|}

=Afficher en colonnes=
Parfois, il peut être utile d'afficher une liste ou la sortie d'une commande en colonne. L'utilitaire "pr" permet de faire ça. On peut choisir le nombre de colonne, la largeur d'affichage et si l'ordre se fait par ligne ou par colonnes. Voici deux exemples, un peu bidon, certes, mais clairs.

# ls -1 /etc | pr -t -4 -w 80 |head -6
abrt filesystems ld.so.conf.d phpMyAdmin
adjtime filezilla libaudit.conf pinforc
aliases firefox libblockdev pkcs11
alsa firewalld libibverbs.d pkgconfig
alternatives flatpak libnl pki
anaconda flexiblasrc libreport plymouth

# ls -1 /etc | pr -t -4 -w 80 -a |head -6
abrt adjtime aliases alsa
alternatives anaconda anacrontab anthy-unicode.conf
asound.conf audit authselect avahi
bash_completion.d bashrc bindresvport.blackl binfmt.d
bluetooth brlapi.key brltty brltty.conf
ceph chkconfig.d chromium chrony.conf

Accueil

2025-06-06T12:45:31Z

AdminWiki :

'''Bienvenue''' sur le wiki de '''BlaireauLinux.fr !'''

Ce site est un recueil de notes personnelles que j'ai essayé de rendre claires et accessibles pour tout le monde.

Attention : certaines pages ne sont plus du tout à jour.

Vous pouvez cliquer dans le menu à gauche ou choisir une des catégories ci-dessous. Bonne visite.

== Liste des catégories ==
* [http://blaireaulinux.fr/wiki/index.php?title=Catégorie:Linux Linux]
* [http://blaireaulinux.fr/wiki/index.php?title=Catégorie:Solaris Solaris]
* [http://blaireaulinux.fr/wiki/index.php?title=Catégorie:BSD BSD]
* [http://blaireaulinux.fr/wiki/index.php?title=Catégorie:AIX AIX]
* [http://blaireaulinux.fr/wiki/index.php?title=Catégorie:HP-UX HP-UX]
* [http://blaireaulinux.fr/wiki/index.php?title=Catégorie:Windows Windows]
* [http://blaireaulinux.fr/wiki/index.php?title=Catégorie:Nagios Nagios]
* [http://blaireaulinux.fr/wiki/index.php?title=Catégorie:MySQL MySQL]
* [http://blaireaulinux.fr/wiki/index.php?title=Catégorie:PHP PHP]
* [http://blaireaulinux.fr/wiki/index.php?title=Catégorie:Perl Perl]
* [http://blaireaulinux.fr/wiki/index.php?title=Catégorie:Divers Divers]
* [mailto:unixmaniax@gmail.com M'écrire]

Accueil

2025-05-25T16:46:36Z

AdminWiki : /* Liste des catégories */

'''Bienvenue''' sur le wiki de '''BlaireauLinux.fr !'''

Vous pouvez cliquer dans le menu à gauche ou choisir une des catégories ci-dessous. Bonne visite.

== Liste des catégories ==
* [http://blaireaulinux.fr/wiki/index.php?title=Catégorie:Linux Linux]
* [http://blaireaulinux.fr/wiki/index.php?title=Catégorie:Solaris Solaris]
* [http://blaireaulinux.fr/wiki/index.php?title=Catégorie:BSD BSD]
* [http://blaireaulinux.fr/wiki/index.php?title=Catégorie:AIX AIX]
* [http://blaireaulinux.fr/wiki/index.php?title=Catégorie:HP-UX HP-UX]
* [http://blaireaulinux.fr/wiki/index.php?title=Catégorie:Windows Windows]
* [http://blaireaulinux.fr/wiki/index.php?title=Catégorie:Nagios Nagios]
* [http://blaireaulinux.fr/wiki/index.php?title=Catégorie:MySQL MySQL]
* [http://blaireaulinux.fr/wiki/index.php?title=Catégorie:PHP PHP]
* [http://blaireaulinux.fr/wiki/index.php?title=Catégorie:Perl Perl]
* [http://blaireaulinux.fr/wiki/index.php?title=Catégorie:Divers Divers]
* [mailto:unixmaniax@gmail.com M'écrire]

Accueil

2025-05-25T15:22:58Z

AdminWiki :

'''Bienvenue''' sur le wiki de '''BlaireauLinux.fr !'''

Vous pouvez cliquer dans le menu à gauche ou choisir une des catégories ci-dessous. Bonne visite.

== Liste des catégories ==

* [[:Category:Linux|Linux]]
* [[:Category:Solaris|Solaris]]
* [[:Category:BSD|BSD]]
* [[:Category:AIX|AIX]]
* [[:Category:HP-UX|HP-UX]]
* [[:Category:Windows|Windows]]
* [[:Category:Nagios|Nagios]]
* [[:Category:MySQL|MySQL]]
* [[:Category:PHP|PHP]]
* [[:Category:Perl|Perl]]
* [[:Category:Divers|Divers]]
* [mailto:unixmaniax@gmail.com M'écrire]

Accueil

2025-05-25T15:21:14Z

AdminWiki : /* Liste des catégories */

'''Bienvenue''' sur le wiki de '''BlaireauLinux.fr !'''

Vous pouvez dérouler le menu à gauche et cliquez sur le lien de votre choix, ou choisir une des catégories ci-dessous. Bonne visite.

== Liste des catégories ==

* [[:Category:Linux|Linux]]
* [[:Category:Solaris|Solaris]]
* [[:Category:BSD|BSD]]
* [[:Category:AIX|AIX]]
* [[:Category:HP-UX|HP-UX]]
* [[:Category:Windows|Windows]]
* [[:Category:Nagios|Nagios]]
* [[:Category:MySQL|MySQL]]
* [[:Category:PHP|PHP]]
* [[:Category:Perl|Perl]]
* [[:Category:Divers|Divers]]
* [mailto:unixmaniax@gmail.com M'écrire]

Accueil

2025-05-25T15:04:06Z

AdminWiki :

'''Bienvenue''' sur le wiki de '''BlaireauLinux.fr !'''

Vous pouvez dérouler le menu à gauche et cliquez sur le lien de votre choix, ou choisir une des catégories ci-dessous. Bonne visite.

== Liste des catégories ==

* [http://blairex.cluster021.hosting.ovh.net/wiki/index.php?title=Catégorie:Linux Linux]
* [http://blairex.cluster021.hosting.ovh.net/wiki/index.php?title=Catégorie:Solaris Solaris]
* [http://blairex.cluster021.hosting.ovh.net/wiki/index.php?title=Catégorie:BSD BSD]
* [http://blairex.cluster021.hosting.ovh.net/wiki/index.php?title=Catégorie:AIX AIX]
* [http://blairex.cluster021.hosting.ovh.net/wiki/index.php?title=Catégorie:HP-UX HP-UX]
* [http://blairex.cluster021.hosting.ovh.net/wiki/index.php?title=Catégorie:Windows Windows]
* [http://blairex.cluster021.hosting.ovh.net/wiki/index.php?title=Catégorie:Nagios Nagios]
* [http://blairex.cluster021.hosting.ovh.net/wiki/index.php?title=Catégorie:MySQL MySQL]
* [http://blairex.cluster021.hosting.ovh.net/wiki/index.php?title=Catégorie:PHP PHP]
* [http://blairex.cluster021.hosting.ovh.net/wiki/index.php?title=Catégorie:Perl Perl]
* [http://blairex.cluster021.hosting.ovh.net/wiki/index.php?title=Catégorie:Divers Divers]
* [mailto:unixmaniax@gmail.com M'écrire]

Logrotate

2025-05-15T14:22:14Z

AdminWiki : /* Compléments */

[[Category:linux]]

=Présentation=

Logrotate est la partie de syslog qui gère la rotation des fichiers de log, évitant ainsi qu'ils ne deviennent trop gros ou trop nombreux. Chaque log est paramétrable indépendament des autres.

Logrotate possède un fichier de configuration principal : '''/etc/logrotate.conf'''.

En général, logrotate.conf inclue tout le répertoire '''/etc/logrorate.d/''', ce qui permet d'avoir autant de sous-fichiers de configuration que l'on veut dans ce répertoire. La totalité du sous-répertoire est parcourue. On peut en inclure d'autres. La syntaxe pour inclure /etc/logrotate.d est :

include /etc/logrotate.d

Donc quand on veut ajouter une configuration, on peut au choix modifier logrotate.conf ou ajouter un nouveau fichier dans logrotate.d, pour ne pas surcharger le fichier principal.

=Exemple : modifier les droits des logs=

Il peut être intéressant de modifier les droits de certains fichiers de log pour les rendre lisibles à certains comptes, par exemple un compte de surveillance, qui a besoin d'un accès en lecture seule sur des logs qui ne sont nativements accessibles qu'à root.

Bien sûr, on peut faire un chmod directement dessus, mais à la prochaine rotation de fichier, le nouveau log reprendra les droits par défaut.

Voici justement comment modifier les droits par défaut du fichier /var/log/maillog.

Editer le fichier /etc/logrotate.conf, et ajouter les lignes suivantes :

# ajout des droits 644 sur maillog
/var/log/maillog {
create 644 root root
}

Les options après le mot '''create''' sont, dans l'ordre, les droits, le propriétaire, le groupe. Ici le fichier appartiendra à root:root avec les droits 644.

Remarque : ce changement de droits ne sera effectué qu'à la prochaine rotation du fichier log.

Attention : si les logs sont dans un répertoire qui est accessible en écriture à un groupe autre que root, logrotate va renvoyer une erreur. Dans ce cas, il faut ajouter une ligne '''su'''.

Exemple :

$ ls -ld /var/log/mon_appli/
drwxrwxr-x 6 appli_user appli_grp 20480 4 juin 15:08 /var/log/mon_appli/

$ cat /etc/logrotate.d/mon_appli.conf
/var/log/mon_appli.log
{
create 644 root root
su root root
...
}

=Exemple plus complet=

Voici notre fichier d'exemple :

# cat /etc/logrotate.d/httpd
/var/log/httpd/*log {
create 644 apache apache
compress
daily
delaycompress
rotate 7
missingok
notifempty
sharedscripts
postrotate
/sbin/service httpd reload > /dev/null 2>/dev/null || true
endscript
}

Explications :
* '''/var/log/httpd/*log {''' => ce qui va être contenu entre les { } concernera tous les fichiers /var/log/httpd/*log
* '''create 644 apache apache''' => les fichiers appartiendront à apache:apache avec les droits 644 (il ne faut pas mettre les ":" entre le user et le group.
* '''compress''' => les fichiers seront compressés...
* '''delaycompress''' => ... sauf le log courant et le précédent
* '''daily''' => la rotation se fait tous les jours
* '''rotate 7''' => on garde 7 logs en archive (en plus du log courant)
* '''missingok''' => si un fichier de log est manquant, on passe au suivant sans générer d'erreur
* '''notifempty''' => la rotation ne se fait pas si le log est vide
* '''sharedscripts''' => les scripts qui suivent ne seront exécutés qu'une seule fois par rotation, et non une fois par rotation et par fichier rencontré
* '''postrotate/endscript''' => les lignes qui se trouvent entre ''postrotate'' et ''endscript'' seront exécutées après la rotation du fichier de log.
* '''}''' => fin

Voici à quoi ressemblent les fichiers de logs après quelques semaines :

# ls -lh /var/log/httpd/
total 158M
-rw-r--r-- 1 root root 47M Jun 6 15:29 access_log
-rw-r--r-- 1 root root 91M Jun 6 04:02 access_log.1
-rw-r--r-- 1 root root 3.9M Jun 6 04:02 access_log.2.gz
-rw-r--r-- 1 root root 1.9M Jun 5 04:02 access_log.3.gz
-rw-r--r-- 1 root root 2.1M Jun 4 04:02 access_log.4.gz
-rw-r--r-- 1 root root 4.0M Jun 3 04:02 access_log.5.gz
-rw-r--r-- 1 root root 3.9M Jun 2 04:02 access_log.6.gz
-rw-r--r-- 1 root root 5.1M Jun 1 04:02 access_log.7.gz
-rw-r--r-- 1 root root 1.6K Jun 6 14:55 error_log
-rw-r--r-- 1 root root 578 Jun 6 04:02 error_log.1
-rw-r--r-- 1 root root 11K Jun 6 04:02 error_log.2.gz
-rw-r--r-- 1 root root 363 Jun 5 04:02 error_log.3.gz
-rw-r--r-- 1 root root 276 Jun 4 04:02 error_log.4.gz
-rw-r--r-- 1 root root 521 Jun 3 04:02 error_log.5.gz
-rw-r--r-- 1 root root 480 Jun 2 04:02 error_log.6.gz
-rw-r--r-- 1 root root 717 Jun 1 04:02 error_log.7.gz

=Les autres options de logrotate=

Au lieu de faire une rotation quotidienne, comme c'est le cas dans l'exemple précédent, une option courante est d'effectuer la rotation dès que le log atteint une certaine taille. Dans ce cas on utilise l'option "size" suivie de la taille en octets. Exemple :

size 300M

Sinon, la page man est tellement bien faite qu'il n'est pas utile de tout refaire. Vous trouverez tout ici : [http://www.delafond.org/traducmanfr/man/man8/logrotate.8.html http://www.delafond.org/traducmanfr/man/man8/logrotate.8.html]

=Compléments=

Logrotate est appelé par la crontab. Donc il n'y a rien à relancer après avoir modifié la conf.

On peut malgré tout le forcer manuellement avec l'option "-f" :

logrotate -f /etc/logrotate.conf

Ceci va forcer l'exécution de toutes les confs logrotate. Si on veut juste forcer un script, par exemple pour tester sa syntaxe, on spécifie le fichier :

logrotate -f /etc/logrotate.d/mon_logrotate

On peut aussi tester la conf avec l'option -d (pour debug) :

logrotate -d /etc/logrotate.conf

Apt

2023-06-15T13:07:18Z

AdminWiki : /* Principales commandes */

[[Category:linux]]

Note : je ne fais ici qu'une brève présentation d'apt, avec les commandes qui servent le plus souvent. Pour avoir un cours complet, allez voir les liens dans le chapitre "Plus d'infos" en bas de cet article.

=Présentation=

Le gestionnaire de paquets par défaut de debian et ses dérivés, est dpkg. Apt est une surcouche de dpkg, qui automatise et simplifie de nombreuses commandes dpkg, notamment en gérant tout seul les dépendances. Apt est une suite d'outils, dont le principal est apt "tout court" (anciennement apt-get), qui sert à l'installation et la désinstallation des packages, et à la mise à jour du système.

Les packages pour debian ont l'extention ".deb".

Pour ceux qui n'aiment pas la ligne de commande, il existe "synaptic" qui est un excellent gestionnaire de packages graphique, qui s'appuie sur apt.

=Dépôts=

Pour installer un package, ou mettre à jour le système, apt va chercher les informations sur internet. Pour savoir où chercher, il va interroger le fichier /etc/apt/sources.list qui contient une liste de serveurs. Pour installer certains packages exotiques, ne figurants pas sur les mirroirs par défaut, il faudra rajouter une ou plusieurs lignes dans ce fichier (la ligne exacte à rajouter est quasiment toujours indiquée sur le site web du package en question, si une version debian existe).

=Principales commandes=

{|class="wikitable alternance centre"
|-
| apt update || mettre à jour la liste des packages disponibles dans les dépôts
|-
| apt upgrade || met à jour tous les packages installés sur le système (demande confirmation avant)
|-
| apt dist-upgrade || comme apt upgrade, mais si une nouvelle version de la distribution est disponible, l'installe. Dans ce cas, on aura mis avant à jour /etc/apt/sources.list avec les nouveaux dépôts. Attention, pour les dérivées de debian, il est préférable d'utiliser les outils fournis (cas d'ubuntu qui propose la mise à jour depuis l'interface graphique) ou d'aller voir la procédure complète sur la page web de la distribution.
|-
| apt install nom_package || installe le package "nom_package"
|-
| dpkg -i ./nom_package.deb || installe (ou met à jour) le package "nom_package.deb", précédement téléchargé sur le disque dur.
|-
| apt remove nom_package || désinstalle le package "nom_package", mais sans supprimer ses fichiers de configuration.
|-
| apt remove --purge nom_package || désinstalle totalement le package "nom_package" (y compris ses fichiers de configuration)
|-
| apt list || affiche la liste de tous les paquets, installés ou non
|-
| apt list --installed || affiche la liste de tous les paquets installés
|-
| apt clean || vide le cache de apt, qui peut parfois occuper plusieurs centaines de Mo (fichier téléchargés par apt pour les installations, qui ne sont pas supprimés automatiquement).
|-
| apt autoclean || idem, mais ne supprime que les paquets qui ne sont plus disponibles sur les dépôts.
|-
| apt-cache search nom_paquet || recherche des infos sur le package "nom_paquet" installé ou non.
|-
| dpkg --get-selections "*nom_paquet*" (ou dpkg -l) || affiche la liste des packages installés (ou désinstallés sans le --purge)
|-
| apt-file search nom_fichier || recherche à quel package appartient le fichier "nom_fichier". Nécessite d'avoir fait au moins une fois "apt-file update". Nécessite le package apt-file, non installé par défaut. Sinon, préférer dkpg -S.
|-
| dkpg -S nom_fichier || recherche à quel package appartient le fichier "nom_fichier". Equivalent de "yum provides" chez Redhat.
|-
| dpkg -L nom_package || affiche la liste des fichiers du package (package installé)
|}

=Proxy=

Pour utiliser apt derrière un serveur mandataire (proxy), éditez le fichier /etc/apt/apt.conf (il faut le créer s'il n'existe pas) et ajoutez la ligne :

Acquire::http::Proxy "http://proxy:port";

ou

Acquire::http::Proxy "http://login:password@proxy:port";

=Plus d'infos=

Pour avoir plus d'informations et plus de commandes et options sur l'utilisation de apt et dpkg, allez sur le site [http://www.debian.org/doc/manuals/apt-howto/index.fr.html http://www.debian.org/doc/manuals/apt-howto/index.fr.html] ou sur [http://www.math-linux.com/spip.php?article58 http://www.math-linux.com/spip.php?article58].

Apt-get

2022-08-10T13:22:19Z

AdminWiki : AdminWiki a déplacé la page Apt-get vers Apt : apt-get => apt

#REDIRECTION [[Apt]]

Apt

2022-08-10T13:22:19Z

AdminWiki : AdminWiki a déplacé la page Apt-get vers Apt : apt-get => apt

[[Category:linux]]

Note : je ne fais ici qu'une brève présentation d'apt, avec les commandes qui servent le plus souvent. Pour avoir un cours complet, allez voir les liens dans le chapitre "Plus d'infos" en bas de cet article.

=Présentation=

Le gestionnaire de paquets par défaut de debian et ses dérivés, est dpkg. Apt est une surcouche de dpkg, qui automatise et simplifie de nombreuses commandes dpkg, notamment en gérant tout seul les dépendances. Apt est une suite d'outils, dont le principal est apt "tout court" (anciennement apt-get), qui sert à l'installation et la désinstallation des packages, et à la mise à jour du système.

Les packages pour debian ont l'extention ".deb".

Pour ceux qui n'aiment pas la ligne de commande, il existe "synaptic" qui est un excellent gestionnaire de packages graphique, qui s'appuie sur apt.

=Dépôts=

Pour installer un package, ou mettre à jour le système, apt va chercher les informations sur internet. Pour savoir où chercher, il va interroger le fichier /etc/apt/sources.list qui contient une liste de serveurs. Pour installer certains packages exotiques, ne figurants pas sur les mirroirs par défaut, il faudra rajouter une ou plusieurs lignes dans ce fichier (la ligne exacte à rajouter est quasiment toujours indiquée sur le site web du package en question, si une version debian existe).

=Principales commandes=

{|class="wikitable alternance centre"
|-
| apt update || mettre à jour la liste des packages disponibles dans les dépôts
|-
| apt upgrade || met à jour tous les packages installés sur le système (demande confirmation avant)
|-
| apt dist-upgrade || comme apt upgrade, mais si une nouvelle version de la distribution est disponible, l'installe. Dans ce cas, on aura mis avant à jour /etc/apt/sources.list avec les nouveaux dépôts. Attention, pour les dérivées de debian, il est préférable d'utiliser les outils fournis (cas d'ubuntu qui propose la mise à jour depuis l'interface graphique) ou d'aller voir la procédure complète sur la page web de la distribution.
|-
| apt install nom_package || installe le package "nom_package"
|-
| dpkg -i ./nom_package.deb || installe le package "nom_package.deb", précédement téléchargé sur le disque dur.
|-
| apt remove nom_package || désinstalle le package "nom_package", mais sans supprimer ses fichiers de configuration.
|-
| apt remove --purge nom_package || désinstalle totalement le package "nom_package" (y compris ses fichiers de configuration)
|-
| apt list || affiche la liste de tous les paquets, installés ou non
|-
| apt list --installed || affiche la liste de tous les paquets installés
|-
| apt clean || vide le cache de apt, qui peut parfois occuper plusieurs centaines de Mo (fichier téléchargés par apt pour les installations, qui ne sont pas supprimés automatiquement).
|-
| apt autoclean || idem, mais ne supprime que les paquets qui ne sont plus disponibles sur les dépôts.
|-
| apt-cache search nom_paquet || recherche des infos sur le package "nom_paquet" installé ou non.
|-
| dpkg --get-selections "*nom_paquet*" (ou dpkg -l) || affiche la liste des packages installés (ou désinstallés sans le --purge)
|-
| apt-file search nom_fichier || recherche à quel package appartient le fichier "nom_fichier". Nécessite d'avoir fait au moins une fois "apt-file update". Nécessite le package apt-file, non installé par défaut. Sinon, préférer dkpg -S.
|-
| dkpg -S nom_fichier || recherche à quel package appartient le fichier "nom_fichier". Equivalent de "yum provides" chez Redhat.
|-
| dpkg -L nom_package || affiche la liste des fichiers du package (package installé)
|}

=Proxy=

Pour utiliser apt derrière un serveur mandataire (proxy), éditez le fichier /etc/apt/apt.conf (il faut le créer s'il n'existe pas) et ajoutez la ligne :

Acquire::http::Proxy "http://proxy:port";

ou

Acquire::http::Proxy "http://login:password@proxy:port";

=Plus d'infos=

Pour avoir plus d'informations et plus de commandes et options sur l'utilisation de apt et dpkg, allez sur le site [http://www.debian.org/doc/manuals/apt-howto/index.fr.html http://www.debian.org/doc/manuals/apt-howto/index.fr.html] ou sur [http://www.math-linux.com/spip.php?article58 http://www.math-linux.com/spip.php?article58].

Apt

2022-08-10T13:21:56Z

AdminWiki : apt-get vers apt + apt list

[[Category:linux]]

Note : je ne fais ici qu'une brève présentation d'apt, avec les commandes qui servent le plus souvent. Pour avoir un cours complet, allez voir les liens dans le chapitre "Plus d'infos" en bas de cet article.

=Présentation=

Le gestionnaire de paquets par défaut de debian et ses dérivés, est dpkg. Apt est une surcouche de dpkg, qui automatise et simplifie de nombreuses commandes dpkg, notamment en gérant tout seul les dépendances. Apt est une suite d'outils, dont le principal est apt "tout court" (anciennement apt-get), qui sert à l'installation et la désinstallation des packages, et à la mise à jour du système.

Les packages pour debian ont l'extention ".deb".

Pour ceux qui n'aiment pas la ligne de commande, il existe "synaptic" qui est un excellent gestionnaire de packages graphique, qui s'appuie sur apt.

=Dépôts=

Pour installer un package, ou mettre à jour le système, apt va chercher les informations sur internet. Pour savoir où chercher, il va interroger le fichier /etc/apt/sources.list qui contient une liste de serveurs. Pour installer certains packages exotiques, ne figurants pas sur les mirroirs par défaut, il faudra rajouter une ou plusieurs lignes dans ce fichier (la ligne exacte à rajouter est quasiment toujours indiquée sur le site web du package en question, si une version debian existe).

=Principales commandes=

{|class="wikitable alternance centre"
|-
| apt update || mettre à jour la liste des packages disponibles dans les dépôts
|-
| apt upgrade || met à jour tous les packages installés sur le système (demande confirmation avant)
|-
| apt dist-upgrade || comme apt upgrade, mais si une nouvelle version de la distribution est disponible, l'installe. Dans ce cas, on aura mis avant à jour /etc/apt/sources.list avec les nouveaux dépôts. Attention, pour les dérivées de debian, il est préférable d'utiliser les outils fournis (cas d'ubuntu qui propose la mise à jour depuis l'interface graphique) ou d'aller voir la procédure complète sur la page web de la distribution.
|-
| apt install nom_package || installe le package "nom_package"
|-
| dpkg -i ./nom_package.deb || installe le package "nom_package.deb", précédement téléchargé sur le disque dur.
|-
| apt remove nom_package || désinstalle le package "nom_package", mais sans supprimer ses fichiers de configuration.
|-
| apt remove --purge nom_package || désinstalle totalement le package "nom_package" (y compris ses fichiers de configuration)
|-
| apt list || affiche la liste de tous les paquets, installés ou non
|-
| apt list --installed || affiche la liste de tous les paquets installés
|-
| apt clean || vide le cache de apt, qui peut parfois occuper plusieurs centaines de Mo (fichier téléchargés par apt pour les installations, qui ne sont pas supprimés automatiquement).
|-
| apt autoclean || idem, mais ne supprime que les paquets qui ne sont plus disponibles sur les dépôts.
|-
| apt-cache search nom_paquet || recherche des infos sur le package "nom_paquet" installé ou non.
|-
| dpkg --get-selections "*nom_paquet*" (ou dpkg -l) || affiche la liste des packages installés (ou désinstallés sans le --purge)
|-
| apt-file search nom_fichier || recherche à quel package appartient le fichier "nom_fichier". Nécessite d'avoir fait au moins une fois "apt-file update". Nécessite le package apt-file, non installé par défaut. Sinon, préférer dkpg -S.
|-
| dkpg -S nom_fichier || recherche à quel package appartient le fichier "nom_fichier". Equivalent de "yum provides" chez Redhat.
|-
| dpkg -L nom_package || affiche la liste des fichiers du package (package installé)
|}

=Proxy=

Pour utiliser apt derrière un serveur mandataire (proxy), éditez le fichier /etc/apt/apt.conf (il faut le créer s'il n'existe pas) et ajoutez la ligne :

Acquire::http::Proxy "http://proxy:port";

ou

Acquire::http::Proxy "http://login:password@proxy:port";

=Plus d'infos=

Pour avoir plus d'informations et plus de commandes et options sur l'utilisation de apt et dpkg, allez sur le site [http://www.debian.org/doc/manuals/apt-howto/index.fr.html http://www.debian.org/doc/manuals/apt-howto/index.fr.html] ou sur [http://www.math-linux.com/spip.php?article58 http://www.math-linux.com/spip.php?article58].

MediaWiki:Sidebar

2022-08-10T13:14:22Z

AdminWiki : apt-get => apt

* Éléments du menu
* Linux
** Linux présentation|présentation
** Accéder à des partitions BSD sous Linux|accéder à des partitions BSD sous Linux
** Ajout de disques à chaud - linux|ajout de disques à chaud
** Apache|apache
** Apt|apt
** Arborescence des répertoires|arborescence des répertoires
** Bande passante - linux|Bande passante
** Bash - les commandes| bash - les commandes
** Les scripts bash|bash - les scripts
** Clamav - antivirus|Clamav - antivirus
** Configurer / compiler le noyau|configurer / compiler le noyau
** Controle de ressources - Linux|Controle de ressources
** Daemon - syntaxe|Daemon - syntaxe
** ftp washington|ftp washington
** Introduction à gcc/g++|gcc/g++ - introduction
** GlusterFS|GlusterFS
** Les lecteurs de bande sous linux|lecteurs de bande
** Les logiciels|logiciels
** Logrotate|logrotate
** Mandriva - utilisation de URPM|Mandriva - urpm
** proftpd|proftpd
** postfix|postfix
** Protéger un fichier avec un mot de passe (avec gpg)|protéger un fichier avec un mot de passe (avec gpg)
** Puppet|puppet
** Les packages RPM|rpm
** Rsync|Rsync
** Samba - serveur d'impression|Samba - serveur d'impression
** Sauvegarder et partitionner son disque dur (Partimage & QTParted)|sauvegarder et partitionner son disque dur (Partimage & QTParted)
** Sécurité - iptables|sécurité - iptables
** sendmail|sendmail
** Single user - linux|single user
** SVN - Subversion|SVN - Subversion
** Systemd|Systemd
** Tar et cpio|tar et cpio
** Tcpdump|Tcpdump
** Trucs & astuces|trucs & astuces
** Déterminer le type de FS|type de filesystem
** Vi|vi
** Yum|yum

* Solaris
** Solaris présentation|présentation
** Booter en mode maintenance|booter en mode maintenance
** Solaris - Consommation de ressources|Consommation de ressources
** Controle de ressources - Solaris|Controle de ressources
** Création d'un compte utilisateur|création d'un compte utilisateur
** Date d'installation - Solaris|date d'installation
** Disques durs et systèmes de fichiers|Disques durs et systèmes de fichiers
** Du - script - Solaris|du - script
** En cas d'appel au support : explorer|En cas d'appel au support : explorer
** Erreurs matérielles - Solaris|Erreurs matérielles
** Faire une copie d'un disque|Faire une copie d'un disque
** Faire une installation avec Jumpstart|Faire une installation avec Jumpstart
** ftp washington|ftp washington
** Gestion du swap|Gestion du swap
** Impression - Solaris|Impression
** Informations sur le matériel|Informations sur le matériel
** Les logs|Les logs
** Monter une image iso - Solaris|Monter une image iso
** NFS - Solaris|NFS
** OBP (Open Boot Prom) et NVRAM|OBP (Open Boot Prom) et NVRAM
** Oracle VM Server (LDOM)|Oracle VM Server (LDOM)
** Packages - Solaris|Packages
** Password - solaris|Password
** Patch - Solaris|Patch
** proftpd|proftpd
** Quel process écoute sur un port|Quel process écoute sur un port
** Réseau- Solaris|Réseau Solaris 8,9,10
** Réseau Solaris 11|Réseau Solaris 11
** SAN - Solaris|SAN
** Services - Solaris|Services
** Solaris Volume Manager (SVM)|Solaris Volume Manager (SVM)
** Tcpdump|Tcpdump
** Déterminer le type de FS|type de filesystem
** Veritas Volume Manager (VxVM)|Veritas Volume Manager (VxVM)
** Version de Solaris|Version de Solaris
** XSCF|XSCF
** ZFS|ZFS
** Zombie|Zombie
** Zones - Solaris|Zones

* BSD
** BSD présentation|présentation
** Accéder à des partitions BSD sous Linux|Accéder à des partitions BSD sous Linux
** Tcpdump|Tcpdump

* AIX
** AIX - Présentation|Présentation
** Arrêt - relance - AIX|Arrêt - relance
** Backups - AIX|Backups
** Erreur matérielle - AIX|Erreur matérielle
** LVM - AIX|LVM
** Packages - AIX|Packages
** Process - classer par conso cpu - AIX|Process - classer par conso cpu
** Process - classer par conso mémoire - AIX|Process - classer par conso mémoire
** proftpd|proftpd
** Réseau - AIX|Réseau
** RPM - AIX|RPM
** Services - AIX|Services

* HP-UX
** HP-UX|HP-UX

* Windows
** Windows|Windows

* Nagios
** Nagios|Nagios
** Installation de nagios|Installation
** Event_handler|event_handler
** Scripts nagios - exemples|Exemples de scripts
** pnp4nagios|pnp4nagios
** Pnp4nagios - Template|pnp4nagios-template
** Installation de Shinken|Shinken - Installation

* MySQL
** Administration de MySQL|Administration de MySQL
** Perte du mot de passe root - MySQL|Perte du mot de passe root
** Sauvegardes - MySQL|Sauvegardes
** MySQL - Tâches courantes|Tâches courantes
** Vérifier et réparer les tables - MySQL|Vérifier et réparer les tables

* PHP
** Afficher la date au format "dd-mmmm-yyyy" - PHP|Afficher la date au format "dd-mmmm-yyyy"
** Faire une galerie d'images - PHP|Galerie d'images
** Liens - PHP|Liens
** Scanner une plage d'adresses ip - PHP|Scanner une plage d'adresses ip

* Perl
** Perl|Perl
** Perl - exemples|Exemples

* Divers
** Baie de disques HP MSA1OOO - Command Line Interface (CLI)|Baie de disques HP MSA1OOO - Command Line Interface (CLI)
** Liens|Liens

* M'écrire
** mailto:unixmaniax@gmail.com|M'envoyer un email

ZFS

2022-02-25T11:50:22Z

AdminWiki : /* Récupération de zpools détruits */

[[Category:solaris]]

=Présentation=

ZFS est un système de fichiers développé par Sun Microsystems pour remplacer UFS. ZFS est également un gestionnaire de volumes logiques et de raid logiciel. Il est donc le remplaçant du couple UFS+SVM (Solaris Volume Manager ou SDS=Solstice Disk Suite pour les anciens [[File:smiley-langue.gif|frameless]]). C'est donc un concurrent de LVM+JFS2 d'AIX ou mdtools+LVM2+Ext4 de linux. En effet, ce que linux gère avec trois outils différents (raid logiciel+gestionnaire de volumes+filesystem), Solaris le gère maintenant avec un seul : ZFS. Je ne dit pas ça pour dire du mal de linux, que j'utilise au quotidien, mais là, Solaris est clairement en avance.

ZFS s'appuie, comme ses concurrents, sur des partitions de disques dur (difficile de faire autrement...). Dans le langage ZFS, une partition dont il a le contrôle s'appelle un vDev (virtual device), c'est l'équivalent d'un PV en LVM. Par dessus, on va créer des zpools, équivalent des groupes en LVM. C'est au moment ou on créé le zpool qu'on va également définir le niveau de raid. Comme on le verra plus tard, il suffit de lui indiquer le niveau de raid souhaité et les partitions qu'il doit prendre en compte, et il fait tout tout seul. On peut même lui ajouter à chaud des disques pour agrandir les volumes. Ensuite, on va créer les filesystems (FS). Et là, tout devient très différent de ce qu'on a l'habitude de voir, car on ne précise pas la taille du FS. Tous les FS créés dans le zpool se partagent l'espace disque automatiquement, un peu comme des répertoires se partagent l'espace disque sur une partition. Tout se fait de manière dynamique extrêmement rapidement. Les méta-données sont également allouées dynamiquement, donc plus besoin de pré-allouer des inodes, donc plus de risque de saturation du nombre d'inodes. Vous allez me dire : "cette méthode est dangereuse car un FS qui grossit trop va remplir tout le zpool et tous les FS vont être bloqués". Je répondrai : "oui et non". Chaque FS créé avec ZFS peut se voir attribuer des quotas et des réservations. Les quotas sont une limite de taille que le FS ne pourra pas dépasser, et les réservations une taille minimum qui lui est garantie. Il est d'ailleurs fortement recommandé d'utiliser ces quotas et réservations pour prévenir tout problème de remplissage incontrôlé. Cette façon de voir les choses est un peu déroutante au début, mais elle est beaucoup plus souple. Il est très rapide de modifier une valeur de quota et de réservation, alors qu'il prend du temps (parfois beaucoup) sous LVM pour modifier la taille d'un volume, puis du FS qui est sur ce volume.

Autre avantage de ZFS : il s'auto répare. ZFS créé des sommes de contrôle de ses données et méta-données et est capable de détecter et réparer les erreurs. Dans un raid, si une donnée est perdue, ZFS va la récupérer sur une autre branche du raid et remettre la bonne valeur. Tout ça est géré automatiquement en arrière plan par le système, aucune intervention humaine n'est nécessaire.

En cas de coupure de courant, pas de problème : ZFS est un système de fichiers transactionnel qui garanti en permanence la cohérence des données sur les disques. C'est à la fois plus rapide et plus efficace que la journalisation. Le principe de transaction est très utilisé dans les bases de données. Plus de détails ici : [http://fr.wikipedia.org/wiki/Transaction_informatique http://fr.wikipedia.org/wiki/Transaction_informatique].

ZFS permet également de faire très rapidement des snapshots et des clones de FS. Les FS peuvent être compressés.

Au quotidien, ZFS fait gagner beaucoup de temps à l'administrateur. Non seulement les commandes sont moins nombreuses à taper, et la gestion des volumes simplifiée, mais les montages se font tout automatiquement et il n'est plus nécessaire de remplir la vfstab.

Pour finir avec cette présentation, parlons de chiffres. ZFS est un système de fichiers 128 bits. Ceci lui permet d'avoir des FS d'une taille maximale de 256 quadrillions de zetta-octets. J'imagine que cela ne vous parle pas trop, alors précisons : un zetta-octet (Zo) est égal à 1 milliard de To, et un quadrillion est égal à un million de milliards de milliards. Donc pour résumer, la taille maximale d'un FS ZFS est de 256 millions de milliards de milliards de To ! Autant dire qu'on est tranquille pour quelques temps... Quant au nombre maximal de fichiers que peut contenir un répertoire, il est de 256 trillions, soit 256 milliards de milliards. Bref, ça a été un peu mieux pensé que le FAT32... [[File:smiley-dents.gif|frameless]]

=Les bases de ZFS par l'exemple=

Voici quelques petits exemples pour pouvoir utiliser rapidement ZFS. Nous verrons les détails plus tard.

==Les zpools==

On a un disque c0t2d0 qui possède deux partitions de 20Go : c0t2d0s0 et c0t2d0s1.

Créons un datapool sur chacune des partitions et visualisons le résultat :

# zpool create testpool c0t2d0s0
# zpool create testpool2 c0t2d0s1
# zpool list
NAME SIZE ALLOC FREE CAP HEALTH ALTROOT
testpool 19.9G 95.5K 19.9G 0% ONLINE -
testpool2 19.9G 95.5K 19.9G 0% ONLINE -
#
# zfs list
NAME USED AVAIL REFER MOUNTPOINT
testpool 72K 19.6G 21K /testpool
testpool2 72K 19.6G 21K /testpool2

==Les systèmes de fichiers==

===Systèmes de fichiers simples, quotas et réservations===

On va maintenant créer deux systèmes de fichiers simples dans testpool :

# zfs create testpool/test
# zfs create testpool/test/foo
# zfs list
NAME USED AVAIL REFER MOUNTPOINT
testpool 130K 19.6G 22K /testpool
testpool/test 42K 19.6G 21K /testpool/test
testpool/test/foo 21K 19.6G 21K /testpool/test/foo
testpool2 72K 19.6G 21K /testpool2

On voit que les filesystems (FS) créés ont la même taille que leur pool. D'ailleurs, il n'y a pas besoin de préciser leur taille. Tous les FS créés se partagent l'espace disponible sur le pool. Cependant, on peut leur affecter des quotas et des réservations (ou les deux à la fois). Les quotas servent à limiter la taille maximale utilisable par un FS, et la réservation sert à garantir au FS un espace minimum qui lui sera réservé, pour être sûr que les autres FS ne prendront pas toute la place. On peut également activer la compression sur un FS. Voyons un exemple.

# zfs create -o quota=1g testpool/test/foo2
# zfs create -o reservation=1g -o compression=on testpool/test/foo3
# zfs list
NAME USED AVAIL REFER MOUNTPOINT
testpool 1.00G 18.6G 22K /testpool
testpool/test 1.00G 18.6G 24K /testpool/test
testpool/test/foo 21K 18.6G 21K /testpool/test/foo
testpool/test/foo2 21K 1024M 21K /testpool/test/foo2
testpool/test/foo3 21K 19.6G 21K /testpool/test/foo3
testpool2 72K 19.6G 21K /testpool2

On voit que l'espace disponible dans testpool diminue de 1Go, ce qui correspond à la taille réservée à testpool/test/foo3. Par contre, la taille disponible pour ce dernier est toujours de 19,6Go car aucun autre FS n'a réservé d'espace disque. On remarque également que l'espace disponible pour testpool/test/foo2 est de 1024Mo, car c'est le quota qu'on lui a fixé.

La compression activée pour testpool/test/foo3 n'est pas visible avec "'''zfs list'''". Pour la voir il faut utiliser "'''zfs get'''" qu'on verra plus tard. Ou plus simplement "'''zfs list -o compression'''", mais on ne verra plus les autres informations. Pour tout voir : "'''zfs list -o name,used,avail,refer,mountpoint,compression'''". Il existe encore d'autres valeurs qu'on peut afficher, mais je vous laisse lire la page man pour les voir, car elles évoluent avec les versions de ZFS.

# zfs list -o compression
COMPRESS
off
off
off
off
on
off
# zfs list -o name,used,avail,refer,mountpoint,compression
NAME USED AVAIL REFER MOUNTPOINT COMPRESS
testpool 1.00G 18.6G 22K /testpool off
testpool/test 1.00G 18.6G 24K /testpool/test off
testpool/test/foo 21K 18.6G 21K /testpool/test/foo off
testpool/test/foo2 21K 1024M 21K /testpool/test/foo2 off
testpool/test/foo3 21K 19.6G 21K /testpool/test/foo3 on
testpool2 72K 19.6G 21K /testpool2 off

Une remarque importante sur la compression : celle-ci compresse les données à la volée. C'est à dire que les nouveaux fichiers seront compressés, mais les anciens resteront non compressés. Il faut donc penser à la compression avant d'avoir des problèmes d'espace disque ! A noter que les différents benchs que j'ai pu lire montrent que la compression ne fait pas perdre de performance et en fait même gagner dans quelques cas. Ça peut donc être une bonne idée de l'activer dès la création du FS.

Les valeurs de quota et de réservation peuvent se changer à tout moment. Exemple.

# zfs set quota=2g testpool/test/foo2
# zfs set reservation=512m testpool/test/foo2
# zfs list
NAME USED AVAIL REFER MOUNTPOINT
testpool 1.50G 18.1G 22K /testpool
testpool/test 1.50G 18.1G 25K /testpool/test
testpool/test/foo 21K 18.1G 21K /testpool/test/foo
testpool/test/foo2 21K 2.00G 21K /testpool/test/foo2
testpool/test/foo3 21K 19.1G 21K /testpool/test/foo3
testpool2 72K 19.6G 21K /testpool2

On remarque les changements de valeur USED et AVAIL qui se répercutent sur les différents FS de testpool. On ne peut pas changer deux valeurs à la fois avec "'''zfs set'''", il faut faire plusieurs lignes.

Si on veut supprimer un quota ou une réservation, il faut remplacer la valeur par "'''none'''" :

# zfs set quota=none testpool/test/foo2

===Points de montage===

Par défaut, les FS sont montés dans l'arborescence qui correspond au nom du zfs (par exemple, testpool/test est monté dans /testpool/test) et les répertoires correspondants sont automatiquement créés. Cependant, on peut modifier le point de montage, soit à la création, soit après coup. Exemples.

# zfs create -p -o mountpoint=/data testpool/users/data
# zfs set mountpoint=/testpool/foo2 testpool/test/foo2
# zfs list
NAME USED AVAIL REFER MOUNTPOINT
testpool 1.50G 18.1G 24K /testpool
testpool/test 1.50G 18.1G 25K /testpool/test
testpool/test/foo 21K 18.1G 21K /testpool/test/foo
testpool/test/foo2 21K 2.00G 21K /testpool/foo2
testpool/test/foo3 21K 19.1G 21K /testpool/test/foo3
testpool/users 42K 18.1G 21K /testpool/users
testpool/users/data 21K 18.1G 21K /data
testpool2 72K 19.6G 21K /testpool2

Et voilà. On remarque au passage l'option "'''-p'''" de "'''zfs create'''" qui permet, à la manière de "'''mkdir -p'''", de créer de manière récursive l'arborescence de testpool/users/data. Sans cette option, il aurait fallu commencer pour faire "'''zfs create testpool/users'''" puis "'''zfs create testpool/users/data'''".

On peu également ne pas vouloir qu'un FS ou un zpool ne soit pas monté. On peut le préciser avec l'option "'''mountpoint=none'''" à la création ou après coup, comme dans l'exemple suivant. A noter que si on le fait après coup, le répertoire de montage sera supprimé au passage.

# zfs set mountpoint=none testpool/test/foo3
# zfs list testpool/test/foo3
NAME USED AVAIL REFER MOUNTPOINT
testpool/test/foo3 21K 19.1G 21K none

A noter que tous les points de montage sont inscrits dans les databases (ou méta données) internes de ZFS, ce qui fait qu'il n'est plus nécessaire de renseigner /etc/vfstab. Les montages seront automatiquement remontés au reboot.

===Obtenir des infos sur les FS===

Pour obtenir des informations sur les FS, on utilise la commande "'''zfs get'''". On obtient la totalité des informations avec "'''zfs get all'''". Je ne donnerai pas d'exemple ici, car avec les quelques FS qu'on vient de créer, ça nous affiche déjà 345 lignes d'informations !

Mais on peut limiter l'affichage aux seules informations qui nous intéressent, par exemple les quotas ou la compression. On peut réduire encore plus la sélection en précisant le FS. Exemples.

# zfs get quota
NAME PROPERTY VALUE SOURCE
testpool quota none default
testpool/test quota none default
testpool/test/foo quota none default
testpool/test/foo2 quota 2G local
testpool/test/foo3 quota none default
testpool/users quota none default
testpool/users/data quota none default
testpool2 quota none default
# zfs get compression
NAME PROPERTY VALUE SOURCE
testpool compression off default
testpool/test compression off default
testpool/test/foo compression off default
testpool/test/foo2 compression off default
testpool/test/foo3 compression on local
testpool/users compression off default
testpool/users/data compression off default
testpool2 compression off default
# zfs get compression testpool/test/foo
NAME PROPERTY VALUE SOURCE
testpool/test/foo compression off default

On peut également utiliser "'''zfs list'''" avec les options souhaitées, comme on l'a vu plus haut. Exemple : "'''zfs list -o name,used,avail,refer,mountpoint,compression'''".

===Suppression de FS===

On utilise "'''zfs destroy'''".

'''ATTENTION : cette commande ne demande aucune confirmation !!!''' A utiliser avec la plus grande précaution donc.

# zfs list
NAME USED AVAIL REFER MOUNTPOINT
testpool 1.50G 18.1G 25K /testpool
testpool/test 1.50G 18.1G 24K /testpool/test
testpool/test/foo 21K 18.1G 21K /testpool/test/foo
testpool/test/foo2 21K 2.00G 21K /testpool/foo2
testpool/test/foo3 21K 19.1G 21K /testpool/test/foo3
testpool/users 42K 18.1G 21K /testpool/users
testpool/users/data 21K 18.1G 21K /data
testpool2 72K 19.6G 21K /testpool2
# zfs destroy testpool/users/data
# zfs destroy testpool/users
# zfs list
NAME USED AVAIL REFER MOUNTPOINT
testpool 1.50G 18.1G 25K /testpool
testpool/test 1.50G 18.1G 24K /testpool/test
testpool/test/foo 21K 18.1G 21K /testpool/test/foo
testpool/test/foo2 21K 2.00G 21K /testpool/foo2
testpool/test/foo3 21K 19.1G 21K /testpool/test/foo3
testpool2 72K 19.6G 21K /testpool2

Et voilà, les deux FS ont été détruits sans sommation !

Pour les pools, on utilise la commande "'''zpool destroy nom-du-pool'''" qui est aussi radicale, même si le pool contient des FS ! On peut donc perdre énormément de données en un instant.

Voilà, nous avons vu la plupart des commandes utiles au quotidien pour ZFS. Il reste encore un point important à voir dans le détail avant de se lancer dans l'administration ZFS chez votre patron : la gestion des niveaux de raid avec les zpools. Let's go !

=Les zpools dans le détail=

Comme nous l'avons vu dans la présentation de ZFS, les zpools sont l'équivalent des Volume Group (VG) dans LVM. Mais ce sont également eux qui s'occupent des niveaux de raid (c'est le cas du LVM d'AIX, mais pas de celui de linux). Ceci se gère dès la création du zpool.

Dans les exemples qui suivent, nous avons effacé les zpools précédemment créés et nous repartons avec 7 partitions de 5Go chacune : c0t2d0s0 à c0t2d0s6.

==Création d'un pool simple==

# zpool create zp_simple c0t2d0s0
# zpool list
NAME SIZE ALLOC FREE CAP HEALTH ALTROOT
zp_simple 4.97G 95.5K 4.97G 0% ONLINE -
# zfs list
NAME USED AVAIL REFER MOUNTPOINT
zp_simple 72K 4.89G 21K /zp_simple

Et voilà. Le résultat est instantané et "'''zfs list'''" nous indique qu'un FS a été créé et est déjà monté dans /zp_simple.

Supposons maintenant qu'on voulait le créer compressé et sans point de montage.

# zpool destroy zp_simple
# zpool create -m none -O compression=on zp_simple c0t2d0s0
# zpool list
NAME SIZE ALLOC FREE CAP HEALTH ALTROOT
zp_simple 4.97G 152K 4.97G 0% ONLINE -
# zfs list -o name,used,avail,refer,mountpoint,compress
NAME USED AVAIL REFER MOUNTPOINT COMPRESS
zp_simple 82.5K 4.89G 21K none on

Et voilà, c'est aussi simple que ça. A noter que les options ne sont pas les mêmes qu'avec la commande zfs. Avec zpool, le point de montage se précise avec l'option "'''-m'''" (mise à none ici) et les options concernant les futurs FS se passent avec "'''-O'''" (lettre o majuscule). Je dis bien les futurs FS, car la compression sur un zpool n'a pas vraiment de sens, mais il faut savoir que les propriétés d'un FS sont, par défaut, héritées du FS père, ou du zpool père s'il n'y a pas de FS père. Donc dans ce dernier exemple, tous les FS créés dans zp_simple seront compressés et n'auront pas de point de montage. Mais si on spécifie un point de montage au prochain FS créé, alors ses descendants hériteront de son point de montage.

Une autre option qui peut être utile est "'''-f'''". Si le disque a déjà été utilisé en UFS, il est probable que zpool se rende compte qu'il a déjà servi et refuse de créer le pool, car il y a risque de conflit avec un FS existant, qui serait utilisé SVM (anciennement SDS). Si on est sûr que le disque est bien disponible, on va utiliser l'option "'''-f'''" qui va forcer la création du zpool.

==Création d'un pool en raid0==

# zpool create zp_raid0 c0t2d0s1 c0t2d0s2
# zpool list
NAME SIZE ALLOC FREE CAP HEALTH ALTROOT
zp_raid0 9.94G 97K 9.94G 0% ONLINE -
zp_simple 4.97G 166K 4.97G 0% ONLINE -
# zfs list
NAME USED AVAIL REFER MOUNTPOINT
zp_raid0 73.5K 9.78G 21K /zp_raid0
zp_simple 84K 4.89G 21K none

Difficile de faire plus simple...

Nous allons en profiter pour voir une nouvelle commande : "'''zpool status'''" qui peut se taper seule ou avec une liste de zpools en argument. Exemple.

# zpool status zp_raid0
pool: zp_raid0
state: ONLINE
scrub: none requested
config:

NAME STATE READ WRITE CKSUM
zp_raid0 ONLINE 0 0 0
c0t2d0s1 ONLINE 0 0 0
c0t2d0s2 ONLINE 0 0 0

errors: No known data errors

Cette commande nous permet de voir l'état et la configuration du zpool. On peut voir précisément de quels vdevs (partitions) il est composé, et l'état de chacun des vdevs.

==Création d'un pool en miroir (raid1)==

On va rajouter le mot clé "'''mirror'''" pour préciser à zpool qu'il s'agit d'un mirroir.

# zpool create zp_raid1 mirror c0t2d0s3 c0t2d0s4
# zpool list
NAME SIZE ALLOC FREE CAP HEALTH ALTROOT
zp_raid0 9.94G 78K 9.94G 0% ONLINE -
zp_raid1 4.97G 95.5K 4.97G 0% ONLINE -
zp_simple 4.97G 88.5K 4.97G 0% ONLINE -

On voit bien que zp_raid1 ne fait que la moitié de la somme de ses deux vdevs.

==Création d'un pool en raid 1+0==

Il s'agit ici de créer deux miroirs qu'on va assembler. Commençons par supprimer les pools précédents.

# zpool destroy zp_simple ; zpool destroy zp_raid0 ; zpool destroy zp_raid1
# zpool create zp_raid10 mirror c0t2d0s0 c0t2d0s1 mirror c0t2d0s2 c0t2d0s3
# zpool list
NAME SIZE ALLOC FREE CAP HEALTH ALTROOT
zp_raid10 9.94G 97K 9.94G 0% ONLINE -
# zpool status
pool: zp_raid10
state: ONLINE
scrub: none requested
config:

NAME STATE READ WRITE CKSUM
zp_raid10 ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
c0t2d0s0 ONLINE 0 0 0
c0t2d0s1 ONLINE 0 0 0
mirror-1 ONLINE 0 0 0
c0t2d0s2 ONLINE 0 0 0
c0t2d0s3 ONLINE 0 0 0

errors: No known data errors

'''zpool status''' nous permet de bien voir que zp_raid10 est composé de deux mirroirs, chacun composé de deux vdevs. On peut ajouter autant de miroirs qu'on veut.

==Création d'un zpool en raidz==

En langage zfs, on ne parle pas de raid5 mais de raidz ou raidz1. En fait, le raidz est identique au raid5, à part que le calcul de la parité est différent. A la place du mot clé "'''mirror'''", on va mettre "'''raidz'''" ou "'''raidz1'''".

On va également introduire une nouvelle notion : celle de spare disk. Un spare disk est le disque qui va prendre le relais en cas de panne d'un des disques actifs. On ajoute le (ou les) spare disk(s) avec le mot clé "'''spare'''" suivit du ou des vdevs. Les spare disks fonctionnent également avec tous les niveaux de raid vu précédemment.

# zpool create zp_raid5 raidz c0t2d0s0 c0t2d0s1 c0t2d0s2 c0t2d0s3 spare c0t2d0s4
# zpool status
pool: zp_raid5
state: ONLINE
scrub: none requested
config:

NAME STATE READ WRITE CKSUM
zp_raid5 ONLINE 0 0 0
raidz1-0 ONLINE 0 0 0
c0t2d0s0 ONLINE 0 0 0
c0t2d0s1 ONLINE 0 0 0
c0t2d0s2 ONLINE 0 0 0
c0t2d0s3 ONLINE 0 0 0
spares
c0t2d0s4 AVAIL

errors: No known data error
# zpool list
NAME SIZE ALLOC FREE CAP HEALTH ALTROOT
zp_raid5 19.9G 147K 19.9G 0% ONLINE -

Pour les grandes quantités de disques, Oracle recommande l'utilisation de raidz2. Il s'agit d'un raid6, c'est à dire un raid5 avec double calcul de parité, pour pouvoir supporter la perte de deux disques. Les dernières versions de ZFS incluent également un niveau raidz3.

==Import / export de zpools==

Il peut être utile d'exporter et d'importer un zpool. Par exemple, dans le cas de deux serveurs reliés au même SAN, pour transférer le zpool sur l'autre serveur.

Pour exporter le zpool, on utilise "'''zpool export'''" et pour importer "'''zpool import'''". "'''zpool import'''" sert également à voir la liste des zpool possibles à importer ; utile pour vérifier que le zpool est bien visible du serveur.

# zpool list
NAME SIZE ALLOC FREE CAP HEALTH ALTROOT
zp_raid5 19.9G 147K 19.9G 0% ONLINE -
# zpool export zp_raid5
# zpool list
no pools available
# zpool import
pool: zp_raid5
id: 8634237456648565539
state: ONLINE
action: The pool can be imported using its name or numeric identifier.
config:

zp_raid5 ONLINE
raidz1-0 ONLINE
c0t2d0s0 ONLINE
c0t2d0s1 ONLINE
c0t2d0s2 ONLINE
c0t2d0s3 ONLINE
spares
c0t2d0s4
# zpool list
no pools available
# zpool import zp_raid5
# zpool list
NAME SIZE ALLOC FREE CAP HEALTH ALTROOT
zp_raid5 19.9G 198K 19.9G 0% ONLINE -

==Récupération de zpools détruits==

Si on a supprimé par erreur un zpool avec "'''zpool destroy'''", tout espoir n'est pas perdu. Il faut utiliser "'''zpool import [-D]'''".

# zpool list
NAME SIZE ALLOC FREE CAP HEALTH ALTROOT
zp_raid5 19.9G 147K 19.9G 0% ONLINE -
# zpool destroy zp_raid5
# zpool list
no pools available
# zpool status zp_raid5
cannot open 'zp_raid5': no such pool
# zpool import
no pools available to import
# zpool import -D
pool: zp_raid5
id: 8634237456648565539
state: ONLINE (DESTROYED)
action: The pool can be imported using its name or numeric identifier.
config:

zp_raid5 ONLINE
raidz1-0 ONLINE
c0t2d0s0 ONLINE
c0t2d0s1 ONLINE
c0t2d0s2 ONLINE
c0t2d0s3 ONLINE
spares
c0t2d0s4
# zpool import -D zp_raid5
# zpool list
NAME SIZE ALLOC FREE CAP HEALTH ALTROOT
zp_raid5 19.9G 198K 19.9G 0% ONLINE -

On remarque l'état "'''ONLINE (DESTROYED)'''" renvoyé par "'''zpool import -D'''".

==Renommer un zpool==

Il n'est pas possible de renommer un zpool actif. La solution est de l'exporter et de l'importer sous un nouveau nom. Par contre, le zpool est indisponible le temps de la manipulation. Même si ça ne dure que quelques secondes, c'est à réfléchir sur un serveur de production...

# zpool list
NAME SIZE ALLOC FREE CAP HEALTH ALTROOT
zp_raid5 19.9G 147K 19.9G 0% ONLINE -
# zpool export zp_raid5
# zpool import zp_raid5 zp_data
# zpool list
NAME SIZE ALLOC FREE CAP HEALTH ALTROOT
zp_data 19.9G 198K 19.9G 0% ONLINE -

==Lister les disques d'un zpool==

Il faut utiliser une commande que nous avons vu au début, lors de la création d'un zpool. La commande est "'''zpool status'''", qui peut se taper seule ou avec une liste de zpools en argument. Exemple.

# zpool status zp_raid0
pool: zp_raid0
state: ONLINE
scrub: none requested
config:

NAME STATE READ WRITE CKSUM
zp_raid0 ONLINE 0 0 0
c0t2d0s1 ONLINE 0 0 0
c0t2d0s2 ONLINE 0 0 0

errors: No known data errors

=Compléments sur les FS=

Nous avons vu toutes les fonctionnalités courantes dans le chapitre "''Les bases de ZFS par l'exemple''". Mais il y a encore quelques points intéressants à voir.

==Montage et démontage==

On monter et démonter des FS ZFS avec les commandes "'''zfs mount nom-du-FS'''" et "'''zfs umount nom-du-FS'''". Cette action est différente de "'''zfs set mountpoint=none'''". Cette dernière commande démonte le FS, mais supprime également le point de montage de la config ZFS et supprime le répertoire, alors que "'''zfs umount'''" ne fait que démonter le FS, mais conserve répertoire et config ZFS. Exemple.

# zfs list
NAME USED AVAIL REFER MOUNTPOINT
zp_data 10.1M 14.6G 10.0M /zp_data
zp_data/foo 31.4K 2.00G 31.4K /zp_data/foo
# df -h /zp_data/foo
Filesystem size used avail capacity Mounted on
zp_data/foo 2.0G 31K 2.0G 1% /zp_data/foo
# zfs umount /zp_data/foo
# df -h /zp_data/foo
Filesystem size used avail capacity Mounted on
zp_data 15G 10M 15G 1% /zp_data
# zfs list
NAME USED AVAIL REFER MOUNTPOINT
zp_data 10.1M 14.6G 10.0M /zp_data
zp_data/foo 31.4K 2.00G 31.4K /zp_data/foo
# zfs set mountpoint=none zp_data/foo
# df -h /zp_data/foo
df: (/zp_data/foo) not a block device, directory or mounted resource
# zfs list
NAME USED AVAIL REFER MOUNTPOINT
zp_data 10.2M 14.6G 10.0M /zp_data
zp_data/foo 31.4K 2.00G 31.4K none

==Partage NFS==

On peut partager un FS avec ZFS dès sa création avec "'''zfs create -o sharenfs=ro ...'''" ou par la suite avec "'''zfs set sharenfs=ro ...'''". L'option peut être "'''=ro'''" pour un partage en lecture seule, ou "'''=on'''" pour un partage en lecture écriture.

On peut désactiver le partage (sans le supprimer) avec "'''zfs unshare nom-du-fs'''" et le réactiver avec "'''zfs share nom-du-fs'''". Au lieu du nom du FS, on peut mettre "'''-a'''" et ça va s'appliquer à tous les FS partagés avec ZFS.

On peut supprimer complètement le partage avec "'''zfs set sharenfs=off'''".

Voici un exemple.

# zfs list -o name,used,avail,refer,mountpoint,sharenfs
NAME USED AVAIL REFER MOUNTPOINT SHARENFS
zp_data 10.2M 14.6G 10.0M /zp_data off
zp_data/foo 31.4K 2.00G 31.4K /zp_data/foo off
# share
# zfs set sharenfs=ro zp_data/foo
# zfs list -o name,used,avail,refer,mountpoint,sharenfs
NAME USED AVAIL REFER MOUNTPOINT SHARENFS
zp_data 10.2M 14.6G 10.0M /zp_data off
zp_data/foo 31.4K 2.00G 31.4K /zp_data/foo ro
# share
- /zp_data/foo sec=sys,ro ""
# zfs unshare zp_data/foo
# zfs list -o name,used,avail,refer,mountpoint,sharenfs
NAME USED AVAIL REFER MOUNTPOINT SHARENFS
zp_data 10.2M 14.6G 10.0M /zp_data off
zp_data/foo 31.4K 2.00G 31.4K /zp_data/foo ro
# share
# zfs share zp_data/foo
# share
- /zp_data/foo sec=sys,ro ""
# zfs set sharenfs=off zp_data/foo
# share
# zfs list -o name,used,avail,refer,mountpoint,sharenfs
NAME USED AVAIL REFER MOUNTPOINT SHARENFS
zp_data 10.2M 14.6G 10.0M /zp_data off
zp_data/foo 31.4K 2.00G 31.4K /zp_data/foo off

===Sous Solaris 11===

La syntaxe a évolué sous Solaris 11. Il faut maintenant mettre les paramètres dans la valeur "share" et "sharenfs" n'accepte plus que "on" ou "off". Exemple :

zfs set share=name=mon_partage,path=/chemin,prot=nfs,rw=10.36.208.71 rpool/foo
zfs set sharenfs=on rpool/foo

==Informations détaillées sur un FS==

On peut obtenir tous les détails sur un FS particulier avec '''zfs get all''' comme dans l'exemple ci-dessous :

# zfs get all rpool/export/home
NAME PROPERTY VALUE SOURCE
rpool/export/home aclinherit restricted default
rpool/export/home aclmode discard default
rpool/export/home atime on default
rpool/export/home available 196G -
rpool/export/home canmount on default
rpool/export/home casesensitivity mixed -
rpool/export/home checksum on default
rpool/export/home compression off default
rpool/export/home compressratio 1.00x -
rpool/export/home copies 1 default
rpool/export/home creation Wed Jun 5 7:59 2013 -
rpool/export/home dedup off default
rpool/export/home devices on default
rpool/export/home encryption off -
rpool/export/home exec on default
rpool/export/home keychangedate - default
rpool/export/home keysource none default
rpool/export/home keystatus none -
rpool/export/home logbias latency default
rpool/export/home mlslabel none -
rpool/export/home mounted yes -
rpool/export/home mountpoint /export/home inherited from rpool/export
rpool/export/home multilevel off -
rpool/export/home nbmand off default
rpool/export/home normalization none -
rpool/export/home primarycache all default
rpool/export/home quota none default
rpool/export/home readonly off default
rpool/export/home recordsize 128K default
rpool/export/home referenced 34K -
rpool/export/home refquota none default
rpool/export/home refreservation none default
rpool/export/home rekeydate - default
rpool/export/home reservation none default
rpool/export/home rstchown on default
rpool/export/home secondarycache all default
rpool/export/home setuid on default
rpool/export/home shadow none -
rpool/export/home share.* ... inherited
rpool/export/home snapdir hidden default
rpool/export/home sync standard default
rpool/export/home type filesystem -
rpool/export/home used 2.19G -
rpool/export/home usedbychildren 2.19G -
rpool/export/home usedbydataset 34K -
rpool/export/home usedbyrefreservation 0 -
rpool/export/home usedbysnapshots 0 -
rpool/export/home utf8only off -
rpool/export/home version 6 -
rpool/export/home vscan off default
rpool/export/home xattr on default
rpool/export/home zoned off default

=Snapshots et clones=

==Les snapshots==

Un snapshot (ou instantanné) est une copie en lecture seule d'un FS à un instant donné. Comme sous LVM, un snapshot ne prend aucune place au départ, mais grossi au fur et à mesure que les fichiers changent.

===Création d'un snapshot===

La commande est "'''zfs snapshot'''" suivie du nom du FS auquel on attache un "'''@'''" puis un nom quelconque. Il convient quand même de mettre un nom compréhensible par ses collègues...

# zfs snapshot [-r] pool/home@monday

===Lister les snapshots===

# zfs list -t snapshot

===Détruire un snapshot===

# zfs destroy [-r] pool/home@monday

===Renommer un snapshot===

# zfs rename pool/home@monday pool/home@2011-10-06
# zfs rename pool/home@monday @2011-10-06
# zfs rename pool/home@monday 2011-10-06
# zfs rename -r pool/home@monday 2011-10-06

Les exemples ci-dessus montrent que lorsqu'on renomme un snapshot, la partie de nom qui précède l'"@" est facultative, ainsi que l'"@" lui-même. C'est logique, puisque le snapshot est attaché à son FS et ne peut pas être déplacé ailleurs.

===Revenir à l'état au moment du snapshot (annulation des modifs qui ont suivi la création du snapshot)===

# zfs rollback pool/home@wednesday

Cette commande ne va fonctionner qu'avec le snapshot le plus récent (s'il y en a plusieurs).
Si on veut revenir à un snapshot antérieur, il faut soit faire un rollback successif de tous les snapshots,
soit forcer avec l'option "'''-r'''".

==Les clones==

Un clone est une copie en lecture/écriture d'un FS à un instant donné. Comme le snapshot,
il ne consomme initialement aucun espace disque. On peut créer un snapshot d'un clone.
Le clone se créé obligatoirement à partir d'un snapshot. Il peut se trouver dans une autre
arborescence, mais obligatoirement dans le même zpool. Le snapshot ne pourra pas être détruit
tant que le clone existera. Le clone n'hérite pas des propriétés du snapshot ni du FS d'origine
(quota, etc...).

Un clone n'est donc pas un copier/coller d'un FS. Pour ce faire, il faut utiliser '''zfs send''' et '''zfs recv''' (voir juste après).

===Créer un clone===

# zfs snapshot pool/home/toto@thursday
# zfs clone pool/home/toto@thursday pool/test/bug123

===Détruire un clone===

# zfs destroy pool/test/bug123

===Remplacer un FS par un clone de ce même FS.===

# zfs create pool/test
# zfs create pool/test/foo
# zfs snapshot pool/test/foo@tuesday
# zfs clone pool/test/foo@tuesday pool/test/fooClone
# zfs list -r pool/test
# ==> USED à 0 sur snapshot et clone, mais à vraie valeur sur pool/test/foo
# zfs promote pool/test/fooClone
# zfs list -r pool/test
# ==> USED passe à 0 sur pool/test/foo et à vraie valeur sur pool/test/fooClone

Pour faire plus propre, on renome

# zfs rename pool/test/foo pool/test/fooOld
# zfs rename pool/test/fooClone pool/test/foo

Et éventuellement

# zfs destroy pool/test/fooOld

=Envoi et réception de données ZFS=

On utilise les commandes zfs send et zfs recv pour envoyer et recevoir une copie d'un flux de snapshot.

On peut envoyer le flux vers un autre pool et même vers un autre pool d'un autre serveur.

# zfs send pool/data@today | zfs recv pool2/foo
# zfs send pool/data@today | ssh rhost zfs recv pool2/foo

Le cas que nous venons de voir est l'envoi/réception d'un flux complet. Le FS de destination ne doit pas
exister (il est automatiquement créé). Mais on peut envoyer un flux incrémentiel avec l'option "'''-i'''".

# zfs send -i pool/data@yesterday pool/data@today | ssh rhost zfs recv pool2/foo

Dans ce cas, le zpool pool2 doit préalablement exister.

La commande suivante fait exactement la même chose :

# zfs send -i yesterday pool/data@tody > ssh rhost zfs recv pool2/foo

On peut également envoyer le flux de sortie dans un fichier.

# zfs send pool/data@yesterday | gzip > backup_zfs.gz

Exemple d'utilisation avec des fichiers.

# zfs send pool/data@today > /backup/data.bkp
# zfs recv pool2/foo < /backup/data.bkp

Autres options :

* -I : envoie tous les flux incrémentiels d'un snapshot à un snapshot cummulé. Permet de créer un clone. Le FS de destination doit préalablement exister.
* -i n'envoie que le snapshot le plus récent, -I envoie tous les snapshots créés entre les deux snapshots mis en arguments (voir exemple plus bas).
* -R : envoie le flux de réplication de tous les FS descendants. Les propriétés, snapshots, FS descendants et clones sont conservés

# zfs send -I pool/fs@snap1 pool/fs@snap4 > /backup/fs@all-I # => envoie tous les snapshots de snap1 à snap4
# zfs receive -d -F pool/fs < /backup/fs@all-I # => zfs list affichera bien snap1, snap2, snap3 et snap4

L'option -I permet également d'envoyer à la fois des snapshots et des clones.

Exemple de recopie complète d'une arborescence zfs dans un autre pool :

# zfs snapshot -r users@today
# zfs send -R users@today > /backup/users-R
# zfs create users2 mirror c0t1d1 c1t1d1
# zfs receive -F -d users2 < /backup/users-R

Un zfs list affichera un contenu identique (snapshots, clones, arborescence,...) pour les pools users et users2.

=Mirrorer le disque système=

Pour voir comment fonctionne le mirroring du système, on va suivre un exemple. Dans cet exemple, le disque système de départ est '''c1t0d0''' et celui qui va être son miroir est '''c1t1d0'''.

* Installer le système en ZFS sur c1t0d0 ; le pool garde le nom par défaut "rpool".
* Vérifier le statut du pool

# zpool status
pool: rpool
state: ONLINE
scrub: none requested
config:

NAME STATE READ WRITE CKSUM
rpool ONLINE 0 0 0
c1t0d0s0 ONLINE 0 0 0

errors: No known data errors

* copier le partitionnement du disque principal vers le miroir (le miroir doit être au moins aussi grand que le disque principal)

# prtvtoc /dev/rdsk/c1t0d0s2 | fmthard -s - /dev/rdsk/c1t1d0s2

* on attache le nouveau disque au premier, ce qui implique qu'il va être mis en miroir (si on ajoute "'''add'''" au lieu d'attacher "'''attach'''", on créé des volumes concaténés et pas mirrorés), puis on vérifie le nouvel état du pool

# zpool attach -f rpool c1t0d0s0 c1t1d0s0
Please be sure to invoke installboot(1M) to make 'c1t1d0s0' bootable.
Make sure to wait until resilver is done before rebooting.

# zpool status rpool
pool: rpool
state: ONLINE
status: One or more devices is currently being resilvered. The pool will
continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
scrub: resilver in progress for 0h0m, 28.90% done, 0h0m to go
config:

NAME STATE READ WRITE CKSUM
rpool ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
c1t0d0s0 ONLINE 0 0 0
c1t1d0s0 ONLINE 0 0 0 1.65G resilvered

errors: No known data errors

Attention, sur l'exemple ci-dessus, on voit que la synchronisation des disques est en cours (28.90%, sur la ligne qui commence par "'''scrub:'''"). Il faut bien attendre qu'elle soit terminée avant de passer à la suite. Quand c'est terminé, la ligne "'''scrub:'''" ressemble à ceci :

scrub: resilver completed after 0h4m with 0 errors on Thu Feb 3 16:42:44 2011

* rendre le disque bootable en appliquant les blocs d'initialisation au disque miroir

# installboot -F zfs /usr/platform/`uname -i`/lib/fs/zfs/bootblk /dev/rdsk/c1t1d0s0

* modifier l'OBP pour que les deux disques soient vus comme disques de boot

soit depuis l'OBP (conseillé)

ok nvalias zfsdisk /pci@0/pci@0/pci@2/scsi@0/disk@0,0:a
ok nvalias zfsmirror /pci@0/pci@0/pci@2/scsi@0/disk@1,0:a
ok setenv boot-device zfsdisk zfsmirror
ok setenv use-nvramrc? true
ok reset-all

soit depuis le serveur (moins conseillé, car parfois les lignes trop longues passent mal)

# eeprom "nvramrc=devalias zfsdsk /pci@0/pci@0/pci@2/scsi@0/disk@0,0:a zfsmirror /pci@0/pci@0/pci@2/scsi@0/disk@1,0:a"
# eeprom "boot-device= zfsdisk zfsmirror"
# eeprom "use-nvramrc?=true"

* on peut verifier que ça fonctionne en retirant un disque et en rebootant sur l'autre. Puis idem avec l'autre disque.

Lorsqu'on retire un des disques, le zpool status rpool renvoie un résultat du genre

# zpool status rpool
pool: rpool
state: DEGRADED
status: One or more devices has been removed by the administrator.
Sufficient replicas exist for the pool to continue functioning in a
degraded state.
action: Online the device using 'zpool online' or replace the device with
'zpool replace'.
scrub: none requested
config:

NAME STATE READ WRITE CKSUM
rpool DEGRADED 0 0 0
mirror-0 DEGRADED 0 0 0
c1t0d0s0 REMOVED 0 0 0
c1t1d0s0 ONLINE 0 0 0

errors: No known data errors

Normalement, lorsqu'on remet le disque, il se réactive tout seul. Sinon on peut le réactiver manuellement :

# zpool online c1t0d0s0

=Le swap sous ZFS=

Il est possible de faire une partition dédiée au swap sous ZFS, mais on ne peut pas créer un FS comme nous l'avons vu jusque là. Il faut créer ce qui s'appelle un volume ZFS. C'est quasiment pareil, sauf que la taille est fixe, et non redimensionnable. Il faut également préciser la taille du block, qui va être différente entre Sparc et x86. Exemples de création d'un volume de 30Go :

* sur Sparc :
# zfs create -V 30G -b 8k zp_data/swap

* sur x86 :
# zfs create -V 30G -b 4k zp_data/swap

Ceci va créer un volume qui sera accessible depuis '''/dev/zvol/dsk/zp_data/swap'''. C'est ce chemin qu'on va utiliser la vfstab et pour l'ajout à chaud :

# swap -a /dev/zvol/dsk/zp_data/swap
# swap -l
swapfile dev swaplo blocks free
/dev/zvol/dsk/zp_data/swap 256,1 16 62914544 62914544

Et voilà, notre volume de swap est activé et pris en compte.

'''Attention''' : il est fortement déconseillé par Oracle de mélanger des volumes swap "classiques" SVM et ZFS. Dans la pratique, il m'est arrivé de voir planter sans raison apparente un serveur configuré avec de la swap ZFS et SVM mélangés, et plus aucun plantage après n'avoir laissé que la swap ZFS (et aucun plantage non plus quand il n'y avait que de la swap "classique" SVM).

=Les datasets=

Les datasets permettent de déléguer la gestion des zfs à une zone. Dans la pratique, on créé un ZFS, sans point de montage, on le rajoute via zonecfg, et on redémarre la zone pour prise en compte. Ensuite, toutes les commandes zfs se font depuis la zone.

Je ne vais pas revenir sur la création d'un ZFS. Voici la syntaxe pour ajouter un dataset à une zone :

# zonecfg -z ma_zone
zonecfg:ma_zone> add dataset
zonecfg:ma_zone:dataset> set name=zp_mazone/apps
zonecfg:ma_zone:dataset> end

Le dataset peut également être un zpool.

Après reboot de la zone, on peut créer les zfs depuis la zone, à partir de ce zfs "père".
Avec les versions récentes de Solaris 11 (depuis la 11.2 il me semble), il n'est plus nécessaire de rebooter la zone pour prise en compte des datasets. Maintenant on peut "forcer" l'application de la configuration de la zone, avec la commande :

# zoneadm -z ma_zone apply

=Tunning=

==Cache (zfs_arc_max)==

Par défaut, ZFS s'octroie la totalité du swap, moins 1Go, comme mémoire cache. Si des applications en ont besoin, il la libère au fur et à mesure. Ça peut poser problème, car il peut mettre un peu de temps à rendre la mémoire, et ça peut être perturbant car on voit que le swap est utilisé quasiment à fond, alors que si on totalise la consommation des applications, on n’atteint pas la valeur réellement consommée. Il existe donc un moyen de limiter cette consommation excessive de swap, avec la variable '''zfs_arc_max''' dans '''/etc/system'''. Exemple de limitation, ligne à ajouter dans '''/etc/system''' :

* Limit ZFS ARC cache to 4GB
set zfs:zfs_arc_max=4294967296

Il faut rebooter pour que ce soit pris en compte.

Pour voir la valeur actuellement attribuée :

$ kstat zfs:0:arcstats:size
module: zfs instance: 0
name: arcstats class: misc
size 43336599728

$ echo $((43336599728/1024/1024/1024))
40

Ici on est à 40Go.

=Contraintes et préconisations d'Oracle=

* le nom d'un zpool ou d'un FS ne peut contenir que des caractères alphanumériques ainsi que des "-", "_", ":" ou "."
* la création de FS étant très peu coûteuse en temps et ressources, Oracle recommande de créer un FS par utilisateur, projet, etc. Ceci permet également de contrôler facilement les quotas, réservations et sauvegardes par utilisateur ou projet.
* Oracle recommande d'utiliser ZFS à partir de l'update 2 de Solaris (6/06)
* attention aux ACLs qui ne se gèrent plus de la même façon qu'un UFS. Elles sont plus complètes avec ZFS.

Utilisateur:AdminWiki

2021-12-14T10:59:05Z

AdminWiki :

=Astuces wiki=

==catégorie (enlever les espaces)==

[ [Category:linux] ]

==tableau (sans les cottes)==

'{|class="wikitable alternance centre"
|+ Titre
|-
| ligne 1 || donnée L1-A || donnée L1-B
|-
| ligne 2 || donnée L2-A || donnée L2-B
|}'

Résultat :

{|class="wikitable alternance centre"
|+ Titre
|-
| ligne 1 || donnée L1-A || donnée L1-B
|-
| ligne 2 || donnée L2-A || donnée L2-B
|}

==smiley dans texte==

[ [File:smiley-clin-oeil.png|frameless] ]

=Menu=

* http://localhost/wiki/index.php?title=MediaWiki:Sidebar - http://www.unixmaniax.fr/wiki/index.php?title=MediaWiki:Sidebar
* http://localhost/wiki/index.php?title=MediaWiki:NavTree
* http://localhost/wiki/index.php?title=MediaWiki:Common.css

=Version de php=

https://www.unixmaniax.fr/version-php.php

GlusterFS

2021-12-14T09:40:33Z

AdminWiki : /* Présentation */

[[Category:linux]]

=Présentation=

GlusterFS est un système de fichiers distribué, accessible par le réseau, en mode clients/serveurs.

On doit utiliser des systèmes de fichiers avec attributs étendus, comme XFS, ext4, ext3, ext2, ZFS, ReiserFS, btrfs et beaucoup d’autres. XFS est recommandé (https://docs.gluster.org/en/v3/Install-Guide/Common_criteria/).

Chaque serveur s’appelle un nœud ou brique. En réalité, une brique est le filesystem dédié à GlusterFS sur un nœud. Mais par abus de langage, dans la plupart des docs qu’on trouve, les nœuds sont appelés briques.

Minimum 2 briques. En réalité on peut en n’avoir qu’une, mais ça n’a aucun intérêt, autant faire un serveur NFS dans ce cas.

Il n'y a pas de notion maître/esclave.

Chaque fois qu'on ajoute une brique, le système devient plus performant.

Plusieurs types de volumes :
* volume distribué : comme du raid0, on perd une brique, on perd tout ! Mais volume total = somme des volumes :
[[Fichier:GlusterFS_volume_distribue_mini.jpg]]

* volume répliqué : autant de briques que de répliquas désirés. Avec 2 briques, revient à du raid1 = miroring :
[[Fichier:GlusterFS_volume_replique_mini.jpg]]

* volume distribué répliqué :
[[Fichier:GlusterFS_volume_distribue_replique.jpg|500px]]

=Mise en place=

Gluster stocke ses fichiers de conf dynamiquement dans '''/var/lib/glusterd'''. Si jamais le filesystem se rempli, ça pourrait rendre le service instable, voire le planter complètement. Il est donc conseillé de le séparer de /var/log, voire de le mettre tout seul.

==Installation des packages==

Exemple sur Debian10 :
# apt install glusterfs-server -y
# systemctl enable --now glusterd

Exemple sur CentOS 8 :
# dnf install centos-release-gluster -y
# dnf install -y glusterfs-server
# systemctl enable --now glusterd glusterfsd

==Ouverture des flux==

Sur CentOS 8, ou une autre distribution avec firewalld actif, il faut ouvrir le service glusterfs :
# firewall-cmd --zone=public --add-service=glusterfs
# firewall-cmd --zone=public --add-service=glusterfs --permanent

Ce service inclus les ports suivants : 24007/tcp, 24008/tcp, 24009/tcp, 38465/tcp, 38466/tcp, 38467/tcp, 38468/tcp, 38469/tcp et la plage 49152-49664/tcp.

A noter que cette liste me paraît très large. Sur le site de glusterfs, pour la 3.7.0 beta 1, ils ne parlent que de 24007/tcp, 24008/tcp et 49152 à 49156/tcp ([[https://docs.gluster.org/en/release-3.7.0beta1/Administrator%20Guide/Setting%20Up%20Clients/]]).

==Trusted pool==

Supposons que nous avons deux briques : brick1 et brick2.

Une fois que les briques sont installées, il faut les associer. Les briques se reconnaissent au sein de ce qu'on appelle un trusted pool.

Pour cela, aller sur une des briques, par exemple brick1, et taper :
brick1# gluster peer probe brick2
peer probe : success.

Pour vérifier :
# gluster peer status
Number of Peers: 1

Hostname: brick2
Uuid: 2b5f991b-8a43-43fc-836b-f6292157489a
State: Peer in Cluster (Connected)

Pour afficher la liste de briques :
# gluster pool list
UUID Hostname State
2b5f991b-8a43-43fc-836b-f6292157489a brick2 Connected
9189775d-c84f-48a8-93bc-85e3a10af75d localhost Connected

Si on veut supprimer une brique du pool :
# gluster peer detach brick2

==Création d'un volume répliqué==

Sur brick1, on a créé un point de montage /Gluster/Volumes en XFS.
Sur brick2, on a créé un point de montage /gluster/volumes en ext4.

On ne peut pas créer de volume directement sur un point de montage, donc on va créer des sous-répertoires.

Sur brick1, on créé /Gluster/Volumes/Volume1.
Sur brick2, on créé /gluster/volumes/volume1.

J'ai fait exprès de mettre des majuscules d'un côté et des minuscules de l'autre, pour montrer que ça n'a aucune importance d'avoir des noms et arborescences différentes sur les briques.

On va créer un volume miroir nommé "volume1", avec 2 replicas, en utilisant le transport tcp :
# gluster volume create volume1 replica 2 transport tcp brick1:/Gluster/Volumes/Volume1 brick2:/gluster/volumes/volume1
Replica 2 volumes are prone to split-brain. Use Arbiter or Replica 3 to avoid this. See:
http://docs.gluster.org/en/latest/Administrator%20Guide/Split%20brain%20and%20ways%20to%20deal%20with%20it/.
Do you still want to continue?
(y/n) y
volume create: volume1: success: please start the volume to access data

On voit l'avertissement disant qu'il est préférable d'avoir au moins 3 briques. Malgré tout, on créé le volume.
Pour voir :
# gluster volume list
volume1
root@emmabuntus:~# gluster volume status
Volume volume1 is not started

On voit que le volume est créé, mais pas démarré.
Pour le démarrer et vérifier :
# gluster volume start volume1
volume start: volume1: success

# gluster volume list
volume1

# gluster volume status
Status of volume: volume1
Gluster process TCP Port RDMA Port Online Pid
------------------------------------------------------------------------------
Brick brick1:/Gluster/Volumes/Volume1 49152 0 Y 1737
Brick brick2:/gluster/volumes/volume1 49152 0 Y 1925
Self-heal Daemon on localhost N/A N/A Y 1948
Self-heal Daemon on brick1 N/A N/A Y 1760

Task Status of Volume volume1
------------------------------------------------------------------------------
There are no active volume tasks

==Montage depuis un client==

Installer le package "glusterfs-client".
Monter en précisant une des briques et en indiquant le point de montage :
# mount -t glusterfs brick1:/volume1 /mnt
Ou depuis /etc/fstab :
brick1:/volume1 /mnt glusterfs defaults 0 0
A noter qu'au lieu d'utiliser le client natif gluster comme on vient de le faire, on peut aussi utiliser NFS ou CIFS/samba. Mais dans ce cas il est préférable de mettre les nœuds en cluster de type CTDB (cluster NFS) pour avoir de la haute disponibilité. C'est donc beaucoup plus contraignant.
Lors du montage, on doit indiquer le nom d'une des briques (ici brick1). Mais le client récupère ensuite la liste de toutes les briques et peut communiquer avec n'importe laquelle.

==Paramétrage du volume==

===Timeout===
Par défaut, le timeout pour qu'un client bascule d'une brique à l'autre, en cas d'indisponibilité, est de 42 secondes. Ça peut paraître très long. Voici comment le passer à 5 secondes.
# gluster volume set volume1 network.ping-timeout 5

===Limiter les accès===
Pour limiter l'accès d'un volume aux machines du réseau 10.34.210.0/24 :
# gluster volume set volume1 auth.allow 10.34.210.*
On peut mettre plusieurs ips ou réseaux en les séparant par des virgules.
Pour revenir au comportement par défaut, il faut autoriser "*".
A l'inverse, on peut autoriser tout le monde, sauf des ips, avec le paramètre '''auth.reject'''.
Dans ce cas, pour revenir au comportement par défaut, on va rejeter "NONE".

===Quotas===
On peut activer des quotas pour le volume au niveau des sous-répertoires.
Il faut d'abord activer les quotas :
# gluster volume quota volume1 enable
Puis on défini la valeur :
# gluster volume quota volume1 limit-usage /sous-repertoire 100M
Pour voir l'état des quotas :
# gluster volume quota volume1 list

===Corbeille===
On peut activer une corbeille pour conserver les fichiers supprimés. On peut également limiter la taille aux fichiers de moins de 10Mo.
# gluster volume set volume1 features.trash on
# gluster volume set volume1 features.trash-dir "Poubelle"
# gluster volume set volume1 features.trash-max-falesize 10485760
On peut également activer la corbeille pour les opérations internes comme "rebalance" (par défaut à off) :
# gluster volume set volume1 features.trash-internal-op on

=Administration courante=

==Retirer une brique==

Si on veut retirer une brique.
# gluster peer detach ma_brique

==Remplacement d'une brique (si panne par exemple)==

Nous avons actuellement un trusted pool composé des deux briques brick1 et brick2.

Supposons que brick1 est tombée en panne et n'est pas réparable. On a préparé un nouveau serveur "brick3" et on installé les packages comme expliqué aux chapitres 3.1 et 3.2. Il faut aussi avoir préparé une arborescence /Gluster/Volumes/Volume1 ou équivalente pour accueillir le volume.

Connectons-nous sur brick2 et ajoutons brick3 au trusted-pool :
# gluster peer probe brick3

Maintenant on remplace brick1 par brick3 dans la config du volume "volume1" :
# gluster volume replace-brick volume1 brick1:/Gluster/Volumes/Volume1 brick3:/Gluster/Volumes/Volume1 commit force

On réconcilie le volume :
# gluster volume heal volume1 full

Depuis la nouvelle brique brick3, on synchronise le volume en récupérant les infos de brick2 :
root@brick3 # gluster volume sync brick2 volume1

Il faut ensuite récupérer le volume id depuis les attributs étendus du serveur brick2, pour ensuite les recopier sur brick3.

Récupération volume id :
root@brick2 # getfattr -n trusted.glusterfs.volume-id /gluster/volumes/volume1/
fichier-depuis-client.rien .glusterfs/
[root@centos8-fred ~]# getfattr -n trusted.glusterfs.volume-id /gluster/volumes/volume1/
getfattr: Removing leading '/' from absolute path names
# file: gluster/volumes/volume1/
trusted.glusterfs.volume-id=0s2M71q2FpQoi19v6sUcnyqw==

Recopie volume id sur brick3 :
root@brick3 # setfattr -n trusted.glusterfs.volume-id -v '0s2M71q2FpQoi19v6sUcnyqw==' /Gluster/Volumes/Volume1/

Il ne reste plus qu'à retirer brick1 du trusted pool :
# gluster peer detach brick1

==Étendre un volume==

Actuellement, notre volume1 est sur un volume répliqué sur un cluster à 2 briques. On peut le voir avec la commande suivante :
# gluster volume info volume1 |egrep "Type|Number"
Type: Replicate
Number of Bricks: 1 x 2 = 2

Pour l'étendre, on peut agrandir les volumes sur chaque brique, si c'est possible. Sinon, on peut aussi ajouter des briques. C'est ce qu'on va faire ici. A noter qu'il faut ajouter un nombre de briques proportionnel au nombre de replicas, donc ici 2. Ou alors il faut modifier le nombre de replicas, c’est ce qu’on va voir au chapitre suivant « ajouter un replica ».

On va donc créer deux nouveaux serveurs brick3 et brick4, y installer les packages nécessaires et démarrer les services (voir chapitres 3.1 et 3.2).

On les ajoute au trusted pool depuis une des briques existantes :
brick1# gluster peer probe brick3
brick1# gluster peer probe brick4

Sur brick3 et brick4 on créé un point de montage /gluster/volumes/ avec un sous-répertoire volume1, comme présenté au chapitre 3.4.

Pour finir, on va ajouter les volumes des nouvelles briques à volume1 :
brick1# gluster volume add-brick volume1 brick3:/gluster/volumes/volume1 brick4:/gluster/volumes/volume1

On voit qu'on a maintenant un volume distribué-répliqué à 4 briques :
# gluster volume info volume1 |egrep "Type|Number"
Type: Distributed-Replicate
Number of Bricks: 2 x 2 = 4

Côté client, l'espace disque a doublé (si les volumes sont tous de taille identique).

Par contre, si on a étendu le volume parce que les montages étaient pleins sur brick1 et 2, alors c'est toujours le cas. Car l'ajout de briques ne réparti pas automatiquement les données sur l'ensemble des briques. On va donc le forcer avec la commande :
# gluster volume rebalance volume1 start

Et on peut voir la progression avec la commande :
# gluster volume rebalance volume1 status

==Ajouter un replica==

Repartons de la situation de départ ou volume1 était réparti uniquement sur 2 briques : brick1 et brick2. On va ajouter une brique brick3. Comme c’est un volume répliqué, ça va ajouter une brique répliquée, on va donc passer le replica à 3. Ça permettra de permettre la perte de 2 serveurs, mais n’augmentera pas la volumétrie. La syntaxe est la suivante.
# gluster volume add-brick volume1 replica 3 ubuntu-fred:/gluster/volumes/volume1

On vérifie que ça a fonctionné :
# gluster volume info volume1 |grep "Number of Bricks"
Number of Bricks: 1 x 3 = 3

==Infos détaillées et perfs==

root@debian-fred:~# gluster volume profile volume1 info
Brick: brick1:/Gluster/Volumes/Volume1
-------------------------------------------
Cumulative Stats:
%-latency Avg-latency Min-Latency Max-Latency No. of calls Fop
--------- ----------- ----------- ----------- ------------ ----
0.00 0.00 us 0.00 us 0.00 us 3 RELEASEDIR

Duration: 251 seconds
Data Read: 0 bytes
Data Written: 0 bytes

Interval 1 Stats:

Duration: 32 seconds
Data Read: 0 bytes
Data Written: 0 bytes

Brick: brick2:/gluster/volumes/volume1
--------------------------------------------
Cumulative Stats:
%-latency Avg-latency Min-Latency Max-Latency No. of calls Fop
--------- ----------- ----------- ----------- ------------ ----
0.00 0.00 us 0.00 us 0.00 us 3 RELEASEDIR

Duration: 252 seconds
Data Read: 0 bytes
Data Written: 0 bytes

Interval 1 Stats:

Duration: 32 seconds
Data Read: 0 bytes
Data Written: 0 bytes

=Comparaison avec Ceph=

Une explication détaillée est disponible ici : https://www.ionos.fr/digitalguide/serveur/know-how/glusterfs-vs-ceph/

GlusterFS

2021-12-14T09:40:16Z

AdminWiki : /* Présentation */

[[Category:linux]]

=Présentation=

GlusterFS est un système de fichiers distribué, accessible par le réseau, en mode clients/serveurs.

On doit utiliser des systèmes de fichiers avec attributs étendus, comme XFS, ext4, ext3, ext2, ZFS, ReiserFS, btrfs et beaucoup d’autres. XFS est recommandé (https://docs.gluster.org/en/v3/Install-Guide/Common_criteria/).

Chaque serveur s’appelle un nœud ou brique. En réalité, une brique est le filesystem dédié à GlusterFS sur un nœud. Mais par abus de langage, dans la plupart des docs qu’on trouve, les nœuds sont appelés briques.

Minimum 2 briques. En réalité on peut en n’avoir qu’une, mais ça n’a aucun intérêt, autant faire un serveur NFS dans ce cas.

Il n'y a pas de notion maître/esclave.

Chaque fois qu'on ajoute une brique, le système devient plus performant.

Plusieurs types de volumes :
* volume distribué : comme du raid0, on perd une brique, on perd tout ! Mais volume total = somme des volumes :
[[Fichier:GlusterFS_volume_distribue_mini.jpg]]

* volume répliqué : autant de briques que de répliquas désirés. Avec 2 briques, revient à du raid1 = miroring :
[[Fichier:GlusterFS_volume_replique_mini.jpg]]

* volume distribué répliqué :
[[Fichier:GlusterFS_volume_distribue_replique.jpg|600px]]

=Mise en place=

Gluster stocke ses fichiers de conf dynamiquement dans '''/var/lib/glusterd'''. Si jamais le filesystem se rempli, ça pourrait rendre le service instable, voire le planter complètement. Il est donc conseillé de le séparer de /var/log, voire de le mettre tout seul.

==Installation des packages==

Exemple sur Debian10 :
# apt install glusterfs-server -y
# systemctl enable --now glusterd

Exemple sur CentOS 8 :
# dnf install centos-release-gluster -y
# dnf install -y glusterfs-server
# systemctl enable --now glusterd glusterfsd

==Ouverture des flux==

Sur CentOS 8, ou une autre distribution avec firewalld actif, il faut ouvrir le service glusterfs :
# firewall-cmd --zone=public --add-service=glusterfs
# firewall-cmd --zone=public --add-service=glusterfs --permanent

Ce service inclus les ports suivants : 24007/tcp, 24008/tcp, 24009/tcp, 38465/tcp, 38466/tcp, 38467/tcp, 38468/tcp, 38469/tcp et la plage 49152-49664/tcp.

A noter que cette liste me paraît très large. Sur le site de glusterfs, pour la 3.7.0 beta 1, ils ne parlent que de 24007/tcp, 24008/tcp et 49152 à 49156/tcp ([[https://docs.gluster.org/en/release-3.7.0beta1/Administrator%20Guide/Setting%20Up%20Clients/]]).

==Trusted pool==

Supposons que nous avons deux briques : brick1 et brick2.

Une fois que les briques sont installées, il faut les associer. Les briques se reconnaissent au sein de ce qu'on appelle un trusted pool.

Pour cela, aller sur une des briques, par exemple brick1, et taper :
brick1# gluster peer probe brick2
peer probe : success.

Pour vérifier :
# gluster peer status
Number of Peers: 1

Hostname: brick2
Uuid: 2b5f991b-8a43-43fc-836b-f6292157489a
State: Peer in Cluster (Connected)

Pour afficher la liste de briques :
# gluster pool list
UUID Hostname State
2b5f991b-8a43-43fc-836b-f6292157489a brick2 Connected
9189775d-c84f-48a8-93bc-85e3a10af75d localhost Connected

Si on veut supprimer une brique du pool :
# gluster peer detach brick2

==Création d'un volume répliqué==

Sur brick1, on a créé un point de montage /Gluster/Volumes en XFS.
Sur brick2, on a créé un point de montage /gluster/volumes en ext4.

On ne peut pas créer de volume directement sur un point de montage, donc on va créer des sous-répertoires.

Sur brick1, on créé /Gluster/Volumes/Volume1.
Sur brick2, on créé /gluster/volumes/volume1.

J'ai fait exprès de mettre des majuscules d'un côté et des minuscules de l'autre, pour montrer que ça n'a aucune importance d'avoir des noms et arborescences différentes sur les briques.

On va créer un volume miroir nommé "volume1", avec 2 replicas, en utilisant le transport tcp :
# gluster volume create volume1 replica 2 transport tcp brick1:/Gluster/Volumes/Volume1 brick2:/gluster/volumes/volume1
Replica 2 volumes are prone to split-brain. Use Arbiter or Replica 3 to avoid this. See:
http://docs.gluster.org/en/latest/Administrator%20Guide/Split%20brain%20and%20ways%20to%20deal%20with%20it/.
Do you still want to continue?
(y/n) y
volume create: volume1: success: please start the volume to access data

On voit l'avertissement disant qu'il est préférable d'avoir au moins 3 briques. Malgré tout, on créé le volume.
Pour voir :
# gluster volume list
volume1
root@emmabuntus:~# gluster volume status
Volume volume1 is not started

On voit que le volume est créé, mais pas démarré.
Pour le démarrer et vérifier :
# gluster volume start volume1
volume start: volume1: success

# gluster volume list
volume1

# gluster volume status
Status of volume: volume1
Gluster process TCP Port RDMA Port Online Pid
------------------------------------------------------------------------------
Brick brick1:/Gluster/Volumes/Volume1 49152 0 Y 1737
Brick brick2:/gluster/volumes/volume1 49152 0 Y 1925
Self-heal Daemon on localhost N/A N/A Y 1948
Self-heal Daemon on brick1 N/A N/A Y 1760

Task Status of Volume volume1
------------------------------------------------------------------------------
There are no active volume tasks

==Montage depuis un client==

Installer le package "glusterfs-client".
Monter en précisant une des briques et en indiquant le point de montage :
# mount -t glusterfs brick1:/volume1 /mnt
Ou depuis /etc/fstab :
brick1:/volume1 /mnt glusterfs defaults 0 0
A noter qu'au lieu d'utiliser le client natif gluster comme on vient de le faire, on peut aussi utiliser NFS ou CIFS/samba. Mais dans ce cas il est préférable de mettre les nœuds en cluster de type CTDB (cluster NFS) pour avoir de la haute disponibilité. C'est donc beaucoup plus contraignant.
Lors du montage, on doit indiquer le nom d'une des briques (ici brick1). Mais le client récupère ensuite la liste de toutes les briques et peut communiquer avec n'importe laquelle.

==Paramétrage du volume==

===Timeout===
Par défaut, le timeout pour qu'un client bascule d'une brique à l'autre, en cas d'indisponibilité, est de 42 secondes. Ça peut paraître très long. Voici comment le passer à 5 secondes.
# gluster volume set volume1 network.ping-timeout 5

===Limiter les accès===
Pour limiter l'accès d'un volume aux machines du réseau 10.34.210.0/24 :
# gluster volume set volume1 auth.allow 10.34.210.*
On peut mettre plusieurs ips ou réseaux en les séparant par des virgules.
Pour revenir au comportement par défaut, il faut autoriser "*".
A l'inverse, on peut autoriser tout le monde, sauf des ips, avec le paramètre '''auth.reject'''.
Dans ce cas, pour revenir au comportement par défaut, on va rejeter "NONE".

===Quotas===
On peut activer des quotas pour le volume au niveau des sous-répertoires.
Il faut d'abord activer les quotas :
# gluster volume quota volume1 enable
Puis on défini la valeur :
# gluster volume quota volume1 limit-usage /sous-repertoire 100M
Pour voir l'état des quotas :
# gluster volume quota volume1 list

===Corbeille===
On peut activer une corbeille pour conserver les fichiers supprimés. On peut également limiter la taille aux fichiers de moins de 10Mo.
# gluster volume set volume1 features.trash on
# gluster volume set volume1 features.trash-dir "Poubelle"
# gluster volume set volume1 features.trash-max-falesize 10485760
On peut également activer la corbeille pour les opérations internes comme "rebalance" (par défaut à off) :
# gluster volume set volume1 features.trash-internal-op on

=Administration courante=

==Retirer une brique==

Si on veut retirer une brique.
# gluster peer detach ma_brique

==Remplacement d'une brique (si panne par exemple)==

Nous avons actuellement un trusted pool composé des deux briques brick1 et brick2.

Supposons que brick1 est tombée en panne et n'est pas réparable. On a préparé un nouveau serveur "brick3" et on installé les packages comme expliqué aux chapitres 3.1 et 3.2. Il faut aussi avoir préparé une arborescence /Gluster/Volumes/Volume1 ou équivalente pour accueillir le volume.

Connectons-nous sur brick2 et ajoutons brick3 au trusted-pool :
# gluster peer probe brick3

Maintenant on remplace brick1 par brick3 dans la config du volume "volume1" :
# gluster volume replace-brick volume1 brick1:/Gluster/Volumes/Volume1 brick3:/Gluster/Volumes/Volume1 commit force

On réconcilie le volume :
# gluster volume heal volume1 full

Depuis la nouvelle brique brick3, on synchronise le volume en récupérant les infos de brick2 :
root@brick3 # gluster volume sync brick2 volume1

Il faut ensuite récupérer le volume id depuis les attributs étendus du serveur brick2, pour ensuite les recopier sur brick3.

Récupération volume id :
root@brick2 # getfattr -n trusted.glusterfs.volume-id /gluster/volumes/volume1/
fichier-depuis-client.rien .glusterfs/
[root@centos8-fred ~]# getfattr -n trusted.glusterfs.volume-id /gluster/volumes/volume1/
getfattr: Removing leading '/' from absolute path names
# file: gluster/volumes/volume1/
trusted.glusterfs.volume-id=0s2M71q2FpQoi19v6sUcnyqw==

Recopie volume id sur brick3 :
root@brick3 # setfattr -n trusted.glusterfs.volume-id -v '0s2M71q2FpQoi19v6sUcnyqw==' /Gluster/Volumes/Volume1/

Il ne reste plus qu'à retirer brick1 du trusted pool :
# gluster peer detach brick1

==Étendre un volume==

Actuellement, notre volume1 est sur un volume répliqué sur un cluster à 2 briques. On peut le voir avec la commande suivante :
# gluster volume info volume1 |egrep "Type|Number"
Type: Replicate
Number of Bricks: 1 x 2 = 2

Pour l'étendre, on peut agrandir les volumes sur chaque brique, si c'est possible. Sinon, on peut aussi ajouter des briques. C'est ce qu'on va faire ici. A noter qu'il faut ajouter un nombre de briques proportionnel au nombre de replicas, donc ici 2. Ou alors il faut modifier le nombre de replicas, c’est ce qu’on va voir au chapitre suivant « ajouter un replica ».

On va donc créer deux nouveaux serveurs brick3 et brick4, y installer les packages nécessaires et démarrer les services (voir chapitres 3.1 et 3.2).

On les ajoute au trusted pool depuis une des briques existantes :
brick1# gluster peer probe brick3
brick1# gluster peer probe brick4

Sur brick3 et brick4 on créé un point de montage /gluster/volumes/ avec un sous-répertoire volume1, comme présenté au chapitre 3.4.

Pour finir, on va ajouter les volumes des nouvelles briques à volume1 :
brick1# gluster volume add-brick volume1 brick3:/gluster/volumes/volume1 brick4:/gluster/volumes/volume1

On voit qu'on a maintenant un volume distribué-répliqué à 4 briques :
# gluster volume info volume1 |egrep "Type|Number"
Type: Distributed-Replicate
Number of Bricks: 2 x 2 = 4

Côté client, l'espace disque a doublé (si les volumes sont tous de taille identique).

Par contre, si on a étendu le volume parce que les montages étaient pleins sur brick1 et 2, alors c'est toujours le cas. Car l'ajout de briques ne réparti pas automatiquement les données sur l'ensemble des briques. On va donc le forcer avec la commande :
# gluster volume rebalance volume1 start

Et on peut voir la progression avec la commande :
# gluster volume rebalance volume1 status

==Ajouter un replica==

Repartons de la situation de départ ou volume1 était réparti uniquement sur 2 briques : brick1 et brick2. On va ajouter une brique brick3. Comme c’est un volume répliqué, ça va ajouter une brique répliquée, on va donc passer le replica à 3. Ça permettra de permettre la perte de 2 serveurs, mais n’augmentera pas la volumétrie. La syntaxe est la suivante.
# gluster volume add-brick volume1 replica 3 ubuntu-fred:/gluster/volumes/volume1

On vérifie que ça a fonctionné :
# gluster volume info volume1 |grep "Number of Bricks"
Number of Bricks: 1 x 3 = 3

==Infos détaillées et perfs==

root@debian-fred:~# gluster volume profile volume1 info
Brick: brick1:/Gluster/Volumes/Volume1
-------------------------------------------
Cumulative Stats:
%-latency Avg-latency Min-Latency Max-Latency No. of calls Fop
--------- ----------- ----------- ----------- ------------ ----
0.00 0.00 us 0.00 us 0.00 us 3 RELEASEDIR

Duration: 251 seconds
Data Read: 0 bytes
Data Written: 0 bytes

Interval 1 Stats:

Duration: 32 seconds
Data Read: 0 bytes
Data Written: 0 bytes

Brick: brick2:/gluster/volumes/volume1
--------------------------------------------
Cumulative Stats:
%-latency Avg-latency Min-Latency Max-Latency No. of calls Fop
--------- ----------- ----------- ----------- ------------ ----
0.00 0.00 us 0.00 us 0.00 us 3 RELEASEDIR

Duration: 252 seconds
Data Read: 0 bytes
Data Written: 0 bytes

Interval 1 Stats:

Duration: 32 seconds
Data Read: 0 bytes
Data Written: 0 bytes

=Comparaison avec Ceph=

Une explication détaillée est disponible ici : https://www.ionos.fr/digitalguide/serveur/know-how/glusterfs-vs-ceph/

Fichier:GlusterFS volume distribue mini.jpg

2021-12-14T09:37:46Z

AdminWiki : AdminWiki a téléversé une nouvelle version de Fichier:GlusterFS volume distribue mini.jpg

Fichier:GlusterFS volume replique mini.jpg

2021-12-14T09:34:45Z

AdminWiki :

GlusterFS

2021-12-14T09:34:23Z

AdminWiki : /* Présentation */

GlusterFS

2021-12-14T09:25:17Z

AdminWiki : /* Présentation */

[[Category:linux]]

=Présentation=

GlusterFS est un système de fichiers distribué, accessible par le réseau, en mode clients/serveurs.

On doit utiliser des systèmes de fichiers avec attributs étendus, comme XFS, ext4, ext3, ext2, ZFS, ReiserFS, btrfs et beaucoup d’autres. XFS est recommandé (https://docs.gluster.org/en/v3/Install-Guide/Common_criteria/).

Chaque serveur s’appelle un nœud ou brique. En réalité, une brique est le filesystem dédié à GlusterFS sur un nœud. Mais par abus de langage, dans la plupart des docs qu’on trouve, les nœuds sont appelés briques.

Minimum 2 briques. En réalité on peut en n’avoir qu’une, mais ça n’a aucun intérêt, autant faire un serveur NFS dans ce cas.

Il n'y a pas de notion maître/esclave.

Chaque fois qu'on ajoute une brique, le système devient plus performant.

Plusieurs types de volumes :
* volume distribué : comme du raid0, on perd une brique, on perd tout ! Mais volume total = somme des volumes :
[[Fichier:GlusterFS_volume_distribue_mini.jpg]]

* volume répliqué : autant de briques que de répliquas désirés. Avec 2 briques, revient à du raid1 = miroring :
[[Fichier:GlusterFS_volume_replique.jpg]]

* volume distribué répliqué :
[[Fichier:GlusterFS_volume_distribue_replique.jpg|500px]]

=Mise en place=

Gluster stocke ses fichiers de conf dynamiquement dans '''/var/lib/glusterd'''. Si jamais le filesystem se rempli, ça pourrait rendre le service instable, voire le planter complètement. Il est donc conseillé de le séparer de /var/log, voire de le mettre tout seul.

==Installation des packages==

Exemple sur Debian10 :
# apt install glusterfs-server -y
# systemctl enable --now glusterd

Exemple sur CentOS 8 :
# dnf install centos-release-gluster -y
# dnf install -y glusterfs-server
# systemctl enable --now glusterd glusterfsd

==Ouverture des flux==

Sur CentOS 8, ou une autre distribution avec firewalld actif, il faut ouvrir le service glusterfs :
# firewall-cmd --zone=public --add-service=glusterfs
# firewall-cmd --zone=public --add-service=glusterfs --permanent

Ce service inclus les ports suivants : 24007/tcp, 24008/tcp, 24009/tcp, 38465/tcp, 38466/tcp, 38467/tcp, 38468/tcp, 38469/tcp et la plage 49152-49664/tcp.

A noter que cette liste me paraît très large. Sur le site de glusterfs, pour la 3.7.0 beta 1, ils ne parlent que de 24007/tcp, 24008/tcp et 49152 à 49156/tcp ([[https://docs.gluster.org/en/release-3.7.0beta1/Administrator%20Guide/Setting%20Up%20Clients/]]).

==Trusted pool==

Supposons que nous avons deux briques : brick1 et brick2.

Une fois que les briques sont installées, il faut les associer. Les briques se reconnaissent au sein de ce qu'on appelle un trusted pool.

Pour cela, aller sur une des briques, par exemple brick1, et taper :
brick1# gluster peer probe brick2
peer probe : success.

Pour vérifier :
# gluster peer status
Number of Peers: 1

Hostname: brick2
Uuid: 2b5f991b-8a43-43fc-836b-f6292157489a
State: Peer in Cluster (Connected)

Pour afficher la liste de briques :
# gluster pool list
UUID Hostname State
2b5f991b-8a43-43fc-836b-f6292157489a brick2 Connected
9189775d-c84f-48a8-93bc-85e3a10af75d localhost Connected

Si on veut supprimer une brique du pool :
# gluster peer detach brick2

==Création d'un volume répliqué==

Sur brick1, on a créé un point de montage /Gluster/Volumes en XFS.
Sur brick2, on a créé un point de montage /gluster/volumes en ext4.

On ne peut pas créer de volume directement sur un point de montage, donc on va créer des sous-répertoires.

Sur brick1, on créé /Gluster/Volumes/Volume1.
Sur brick2, on créé /gluster/volumes/volume1.

J'ai fait exprès de mettre des majuscules d'un côté et des minuscules de l'autre, pour montrer que ça n'a aucune importance d'avoir des noms et arborescences différentes sur les briques.

On va créer un volume miroir nommé "volume1", avec 2 replicas, en utilisant le transport tcp :
# gluster volume create volume1 replica 2 transport tcp brick1:/Gluster/Volumes/Volume1 brick2:/gluster/volumes/volume1
Replica 2 volumes are prone to split-brain. Use Arbiter or Replica 3 to avoid this. See:
http://docs.gluster.org/en/latest/Administrator%20Guide/Split%20brain%20and%20ways%20to%20deal%20with%20it/.
Do you still want to continue?
(y/n) y
volume create: volume1: success: please start the volume to access data

On voit l'avertissement disant qu'il est préférable d'avoir au moins 3 briques. Malgré tout, on créé le volume.
Pour voir :
# gluster volume list
volume1
root@emmabuntus:~# gluster volume status
Volume volume1 is not started

On voit que le volume est créé, mais pas démarré.
Pour le démarrer et vérifier :
# gluster volume start volume1
volume start: volume1: success

# gluster volume list
volume1

# gluster volume status
Status of volume: volume1
Gluster process TCP Port RDMA Port Online Pid
------------------------------------------------------------------------------
Brick brick1:/Gluster/Volumes/Volume1 49152 0 Y 1737
Brick brick2:/gluster/volumes/volume1 49152 0 Y 1925
Self-heal Daemon on localhost N/A N/A Y 1948
Self-heal Daemon on brick1 N/A N/A Y 1760

Task Status of Volume volume1
------------------------------------------------------------------------------
There are no active volume tasks

==Montage depuis un client==

Installer le package "glusterfs-client".
Monter en précisant une des briques et en indiquant le point de montage :
# mount -t glusterfs brick1:/volume1 /mnt
Ou depuis /etc/fstab :
brick1:/volume1 /mnt glusterfs defaults 0 0
A noter qu'au lieu d'utiliser le client natif gluster comme on vient de le faire, on peut aussi utiliser NFS ou CIFS/samba. Mais dans ce cas il est préférable de mettre les nœuds en cluster de type CTDB (cluster NFS) pour avoir de la haute disponibilité. C'est donc beaucoup plus contraignant.
Lors du montage, on doit indiquer le nom d'une des briques (ici brick1). Mais le client récupère ensuite la liste de toutes les briques et peut communiquer avec n'importe laquelle.

==Paramétrage du volume==

===Timeout===
Par défaut, le timeout pour qu'un client bascule d'une brique à l'autre, en cas d'indisponibilité, est de 42 secondes. Ça peut paraître très long. Voici comment le passer à 5 secondes.
# gluster volume set volume1 network.ping-timeout 5

===Limiter les accès===
Pour limiter l'accès d'un volume aux machines du réseau 10.34.210.0/24 :
# gluster volume set volume1 auth.allow 10.34.210.*
On peut mettre plusieurs ips ou réseaux en les séparant par des virgules.
Pour revenir au comportement par défaut, il faut autoriser "*".
A l'inverse, on peut autoriser tout le monde, sauf des ips, avec le paramètre '''auth.reject'''.
Dans ce cas, pour revenir au comportement par défaut, on va rejeter "NONE".

===Quotas===
On peut activer des quotas pour le volume au niveau des sous-répertoires.
Il faut d'abord activer les quotas :
# gluster volume quota volume1 enable
Puis on défini la valeur :
# gluster volume quota volume1 limit-usage /sous-repertoire 100M
Pour voir l'état des quotas :
# gluster volume quota volume1 list

===Corbeille===
On peut activer une corbeille pour conserver les fichiers supprimés. On peut également limiter la taille aux fichiers de moins de 10Mo.
# gluster volume set volume1 features.trash on
# gluster volume set volume1 features.trash-dir "Poubelle"
# gluster volume set volume1 features.trash-max-falesize 10485760
On peut également activer la corbeille pour les opérations internes comme "rebalance" (par défaut à off) :
# gluster volume set volume1 features.trash-internal-op on

=Administration courante=

==Retirer une brique==

Si on veut retirer une brique.
# gluster peer detach ma_brique

==Remplacement d'une brique (si panne par exemple)==

Nous avons actuellement un trusted pool composé des deux briques brick1 et brick2.

Supposons que brick1 est tombée en panne et n'est pas réparable. On a préparé un nouveau serveur "brick3" et on installé les packages comme expliqué aux chapitres 3.1 et 3.2. Il faut aussi avoir préparé une arborescence /Gluster/Volumes/Volume1 ou équivalente pour accueillir le volume.

Connectons-nous sur brick2 et ajoutons brick3 au trusted-pool :
# gluster peer probe brick3

Maintenant on remplace brick1 par brick3 dans la config du volume "volume1" :
# gluster volume replace-brick volume1 brick1:/Gluster/Volumes/Volume1 brick3:/Gluster/Volumes/Volume1 commit force

On réconcilie le volume :
# gluster volume heal volume1 full

Depuis la nouvelle brique brick3, on synchronise le volume en récupérant les infos de brick2 :
root@brick3 # gluster volume sync brick2 volume1

Il faut ensuite récupérer le volume id depuis les attributs étendus du serveur brick2, pour ensuite les recopier sur brick3.

Récupération volume id :
root@brick2 # getfattr -n trusted.glusterfs.volume-id /gluster/volumes/volume1/
fichier-depuis-client.rien .glusterfs/
[root@centos8-fred ~]# getfattr -n trusted.glusterfs.volume-id /gluster/volumes/volume1/
getfattr: Removing leading '/' from absolute path names
# file: gluster/volumes/volume1/
trusted.glusterfs.volume-id=0s2M71q2FpQoi19v6sUcnyqw==

Recopie volume id sur brick3 :
root@brick3 # setfattr -n trusted.glusterfs.volume-id -v '0s2M71q2FpQoi19v6sUcnyqw==' /Gluster/Volumes/Volume1/

Il ne reste plus qu'à retirer brick1 du trusted pool :
# gluster peer detach brick1

==Étendre un volume==

Actuellement, notre volume1 est sur un volume répliqué sur un cluster à 2 briques. On peut le voir avec la commande suivante :
# gluster volume info volume1 |egrep "Type|Number"
Type: Replicate
Number of Bricks: 1 x 2 = 2

Pour l'étendre, on peut agrandir les volumes sur chaque brique, si c'est possible. Sinon, on peut aussi ajouter des briques. C'est ce qu'on va faire ici. A noter qu'il faut ajouter un nombre de briques proportionnel au nombre de replicas, donc ici 2. Ou alors il faut modifier le nombre de replicas, c’est ce qu’on va voir au chapitre suivant « ajouter un replica ».

On va donc créer deux nouveaux serveurs brick3 et brick4, y installer les packages nécessaires et démarrer les services (voir chapitres 3.1 et 3.2).

On les ajoute au trusted pool depuis une des briques existantes :
brick1# gluster peer probe brick3
brick1# gluster peer probe brick4

Sur brick3 et brick4 on créé un point de montage /gluster/volumes/ avec un sous-répertoire volume1, comme présenté au chapitre 3.4.

Pour finir, on va ajouter les volumes des nouvelles briques à volume1 :
brick1# gluster volume add-brick volume1 brick3:/gluster/volumes/volume1 brick4:/gluster/volumes/volume1

On voit qu'on a maintenant un volume distribué-répliqué à 4 briques :
# gluster volume info volume1 |egrep "Type|Number"
Type: Distributed-Replicate
Number of Bricks: 2 x 2 = 4

Côté client, l'espace disque a doublé (si les volumes sont tous de taille identique).

Par contre, si on a étendu le volume parce que les montages étaient pleins sur brick1 et 2, alors c'est toujours le cas. Car l'ajout de briques ne réparti pas automatiquement les données sur l'ensemble des briques. On va donc le forcer avec la commande :
# gluster volume rebalance volume1 start

Et on peut voir la progression avec la commande :
# gluster volume rebalance volume1 status

==Ajouter un replica==

Repartons de la situation de départ ou volume1 était réparti uniquement sur 2 briques : brick1 et brick2. On va ajouter une brique brick3. Comme c’est un volume répliqué, ça va ajouter une brique répliquée, on va donc passer le replica à 3. Ça permettra de permettre la perte de 2 serveurs, mais n’augmentera pas la volumétrie. La syntaxe est la suivante.
# gluster volume add-brick volume1 replica 3 ubuntu-fred:/gluster/volumes/volume1

On vérifie que ça a fonctionné :
# gluster volume info volume1 |grep "Number of Bricks"
Number of Bricks: 1 x 3 = 3

==Infos détaillées et perfs==

root@debian-fred:~# gluster volume profile volume1 info
Brick: brick1:/Gluster/Volumes/Volume1
-------------------------------------------
Cumulative Stats:
%-latency Avg-latency Min-Latency Max-Latency No. of calls Fop
--------- ----------- ----------- ----------- ------------ ----
0.00 0.00 us 0.00 us 0.00 us 3 RELEASEDIR

Duration: 251 seconds
Data Read: 0 bytes
Data Written: 0 bytes

Interval 1 Stats:

Duration: 32 seconds
Data Read: 0 bytes
Data Written: 0 bytes

Brick: brick2:/gluster/volumes/volume1
--------------------------------------------
Cumulative Stats:
%-latency Avg-latency Min-Latency Max-Latency No. of calls Fop
--------- ----------- ----------- ----------- ------------ ----
0.00 0.00 us 0.00 us 0.00 us 3 RELEASEDIR

Duration: 252 seconds
Data Read: 0 bytes
Data Written: 0 bytes

Interval 1 Stats:

Duration: 32 seconds
Data Read: 0 bytes
Data Written: 0 bytes

=Comparaison avec Ceph=

Une explication détaillée est disponible ici : https://www.ionos.fr/digitalguide/serveur/know-how/glusterfs-vs-ceph/

GlusterFS

2021-12-14T09:24:54Z

AdminWiki : /* Présentation */

[[Category:linux]]

=Présentation=

GlusterFS est un système de fichiers distribué, accessible par le réseau, en mode clients/serveurs.

On doit utiliser des systèmes de fichiers avec attributs étendus, comme XFS, ext4, ext3, ext2, ZFS, ReiserFS, btrfs et beaucoup d’autres. XFS est recommandé (https://docs.gluster.org/en/v3/Install-Guide/Common_criteria/).

Chaque serveur s’appelle un nœud ou brique. En réalité, une brique est le filesystem dédié à GlusterFS sur un nœud. Mais par abus de langage, dans la plupart des docs qu’on trouve, les nœuds sont appelés briques.

Minimum 2 briques. En réalité on peut en n’avoir qu’une, mais ça n’a aucun intérêt, autant faire un serveur NFS dans ce cas.

Il n'y a pas de notion maître/esclave.

Chaque fois qu'on ajoute une brique, le système devient plus performant.

Plusieurs types de volumes :
* volume distribué : comme du raid0, on perd une brique, on perd tout ! Mais volume total = somme des volumes :
[[Fichier:GlusterFS_volume_distribue_mini.jpg]]

* volume répliqué : autant de briques que de répliquas désirés. Avec 2 briques, revient à du raid1 = miroring :
[[Fichier:GlusterFS_volume_replique.jpg|400px]]

* volume distribué répliqué :
[[Fichier:GlusterFS_volume_distribue_replique.jpg|500px]]

=Mise en place=

Gluster stocke ses fichiers de conf dynamiquement dans '''/var/lib/glusterd'''. Si jamais le filesystem se rempli, ça pourrait rendre le service instable, voire le planter complètement. Il est donc conseillé de le séparer de /var/log, voire de le mettre tout seul.

==Installation des packages==

Exemple sur Debian10 :
# apt install glusterfs-server -y
# systemctl enable --now glusterd

Exemple sur CentOS 8 :
# dnf install centos-release-gluster -y
# dnf install -y glusterfs-server
# systemctl enable --now glusterd glusterfsd

==Ouverture des flux==

Sur CentOS 8, ou une autre distribution avec firewalld actif, il faut ouvrir le service glusterfs :
# firewall-cmd --zone=public --add-service=glusterfs
# firewall-cmd --zone=public --add-service=glusterfs --permanent

Ce service inclus les ports suivants : 24007/tcp, 24008/tcp, 24009/tcp, 38465/tcp, 38466/tcp, 38467/tcp, 38468/tcp, 38469/tcp et la plage 49152-49664/tcp.

A noter que cette liste me paraît très large. Sur le site de glusterfs, pour la 3.7.0 beta 1, ils ne parlent que de 24007/tcp, 24008/tcp et 49152 à 49156/tcp ([[https://docs.gluster.org/en/release-3.7.0beta1/Administrator%20Guide/Setting%20Up%20Clients/]]).

==Trusted pool==

Supposons que nous avons deux briques : brick1 et brick2.

Une fois que les briques sont installées, il faut les associer. Les briques se reconnaissent au sein de ce qu'on appelle un trusted pool.

Pour cela, aller sur une des briques, par exemple brick1, et taper :
brick1# gluster peer probe brick2
peer probe : success.

Pour vérifier :
# gluster peer status
Number of Peers: 1

Hostname: brick2
Uuid: 2b5f991b-8a43-43fc-836b-f6292157489a
State: Peer in Cluster (Connected)

Pour afficher la liste de briques :
# gluster pool list
UUID Hostname State
2b5f991b-8a43-43fc-836b-f6292157489a brick2 Connected
9189775d-c84f-48a8-93bc-85e3a10af75d localhost Connected

Si on veut supprimer une brique du pool :
# gluster peer detach brick2

==Création d'un volume répliqué==

Sur brick1, on a créé un point de montage /Gluster/Volumes en XFS.
Sur brick2, on a créé un point de montage /gluster/volumes en ext4.

On ne peut pas créer de volume directement sur un point de montage, donc on va créer des sous-répertoires.

Sur brick1, on créé /Gluster/Volumes/Volume1.
Sur brick2, on créé /gluster/volumes/volume1.

J'ai fait exprès de mettre des majuscules d'un côté et des minuscules de l'autre, pour montrer que ça n'a aucune importance d'avoir des noms et arborescences différentes sur les briques.

On va créer un volume miroir nommé "volume1", avec 2 replicas, en utilisant le transport tcp :
# gluster volume create volume1 replica 2 transport tcp brick1:/Gluster/Volumes/Volume1 brick2:/gluster/volumes/volume1
Replica 2 volumes are prone to split-brain. Use Arbiter or Replica 3 to avoid this. See:
http://docs.gluster.org/en/latest/Administrator%20Guide/Split%20brain%20and%20ways%20to%20deal%20with%20it/.
Do you still want to continue?
(y/n) y
volume create: volume1: success: please start the volume to access data

On voit l'avertissement disant qu'il est préférable d'avoir au moins 3 briques. Malgré tout, on créé le volume.
Pour voir :
# gluster volume list
volume1
root@emmabuntus:~# gluster volume status
Volume volume1 is not started

On voit que le volume est créé, mais pas démarré.
Pour le démarrer et vérifier :
# gluster volume start volume1
volume start: volume1: success

# gluster volume list
volume1

# gluster volume status
Status of volume: volume1
Gluster process TCP Port RDMA Port Online Pid
------------------------------------------------------------------------------
Brick brick1:/Gluster/Volumes/Volume1 49152 0 Y 1737
Brick brick2:/gluster/volumes/volume1 49152 0 Y 1925
Self-heal Daemon on localhost N/A N/A Y 1948
Self-heal Daemon on brick1 N/A N/A Y 1760

Task Status of Volume volume1
------------------------------------------------------------------------------
There are no active volume tasks

==Montage depuis un client==

Installer le package "glusterfs-client".
Monter en précisant une des briques et en indiquant le point de montage :
# mount -t glusterfs brick1:/volume1 /mnt
Ou depuis /etc/fstab :
brick1:/volume1 /mnt glusterfs defaults 0 0
A noter qu'au lieu d'utiliser le client natif gluster comme on vient de le faire, on peut aussi utiliser NFS ou CIFS/samba. Mais dans ce cas il est préférable de mettre les nœuds en cluster de type CTDB (cluster NFS) pour avoir de la haute disponibilité. C'est donc beaucoup plus contraignant.
Lors du montage, on doit indiquer le nom d'une des briques (ici brick1). Mais le client récupère ensuite la liste de toutes les briques et peut communiquer avec n'importe laquelle.

==Paramétrage du volume==

===Timeout===
Par défaut, le timeout pour qu'un client bascule d'une brique à l'autre, en cas d'indisponibilité, est de 42 secondes. Ça peut paraître très long. Voici comment le passer à 5 secondes.
# gluster volume set volume1 network.ping-timeout 5

===Limiter les accès===
Pour limiter l'accès d'un volume aux machines du réseau 10.34.210.0/24 :
# gluster volume set volume1 auth.allow 10.34.210.*
On peut mettre plusieurs ips ou réseaux en les séparant par des virgules.
Pour revenir au comportement par défaut, il faut autoriser "*".
A l'inverse, on peut autoriser tout le monde, sauf des ips, avec le paramètre '''auth.reject'''.
Dans ce cas, pour revenir au comportement par défaut, on va rejeter "NONE".

===Quotas===
On peut activer des quotas pour le volume au niveau des sous-répertoires.
Il faut d'abord activer les quotas :
# gluster volume quota volume1 enable
Puis on défini la valeur :
# gluster volume quota volume1 limit-usage /sous-repertoire 100M
Pour voir l'état des quotas :
# gluster volume quota volume1 list

===Corbeille===
On peut activer une corbeille pour conserver les fichiers supprimés. On peut également limiter la taille aux fichiers de moins de 10Mo.
# gluster volume set volume1 features.trash on
# gluster volume set volume1 features.trash-dir "Poubelle"
# gluster volume set volume1 features.trash-max-falesize 10485760
On peut également activer la corbeille pour les opérations internes comme "rebalance" (par défaut à off) :
# gluster volume set volume1 features.trash-internal-op on

=Administration courante=

==Retirer une brique==

Si on veut retirer une brique.
# gluster peer detach ma_brique

==Remplacement d'une brique (si panne par exemple)==

Nous avons actuellement un trusted pool composé des deux briques brick1 et brick2.

Supposons que brick1 est tombée en panne et n'est pas réparable. On a préparé un nouveau serveur "brick3" et on installé les packages comme expliqué aux chapitres 3.1 et 3.2. Il faut aussi avoir préparé une arborescence /Gluster/Volumes/Volume1 ou équivalente pour accueillir le volume.

Connectons-nous sur brick2 et ajoutons brick3 au trusted-pool :
# gluster peer probe brick3

Maintenant on remplace brick1 par brick3 dans la config du volume "volume1" :
# gluster volume replace-brick volume1 brick1:/Gluster/Volumes/Volume1 brick3:/Gluster/Volumes/Volume1 commit force

On réconcilie le volume :
# gluster volume heal volume1 full

Depuis la nouvelle brique brick3, on synchronise le volume en récupérant les infos de brick2 :
root@brick3 # gluster volume sync brick2 volume1

Il faut ensuite récupérer le volume id depuis les attributs étendus du serveur brick2, pour ensuite les recopier sur brick3.

Récupération volume id :
root@brick2 # getfattr -n trusted.glusterfs.volume-id /gluster/volumes/volume1/
fichier-depuis-client.rien .glusterfs/
[root@centos8-fred ~]# getfattr -n trusted.glusterfs.volume-id /gluster/volumes/volume1/
getfattr: Removing leading '/' from absolute path names
# file: gluster/volumes/volume1/
trusted.glusterfs.volume-id=0s2M71q2FpQoi19v6sUcnyqw==

Recopie volume id sur brick3 :
root@brick3 # setfattr -n trusted.glusterfs.volume-id -v '0s2M71q2FpQoi19v6sUcnyqw==' /Gluster/Volumes/Volume1/

Il ne reste plus qu'à retirer brick1 du trusted pool :
# gluster peer detach brick1

==Étendre un volume==

Actuellement, notre volume1 est sur un volume répliqué sur un cluster à 2 briques. On peut le voir avec la commande suivante :
# gluster volume info volume1 |egrep "Type|Number"
Type: Replicate
Number of Bricks: 1 x 2 = 2

Pour l'étendre, on peut agrandir les volumes sur chaque brique, si c'est possible. Sinon, on peut aussi ajouter des briques. C'est ce qu'on va faire ici. A noter qu'il faut ajouter un nombre de briques proportionnel au nombre de replicas, donc ici 2. Ou alors il faut modifier le nombre de replicas, c’est ce qu’on va voir au chapitre suivant « ajouter un replica ».

On va donc créer deux nouveaux serveurs brick3 et brick4, y installer les packages nécessaires et démarrer les services (voir chapitres 3.1 et 3.2).

On les ajoute au trusted pool depuis une des briques existantes :
brick1# gluster peer probe brick3
brick1# gluster peer probe brick4

Sur brick3 et brick4 on créé un point de montage /gluster/volumes/ avec un sous-répertoire volume1, comme présenté au chapitre 3.4.

Pour finir, on va ajouter les volumes des nouvelles briques à volume1 :
brick1# gluster volume add-brick volume1 brick3:/gluster/volumes/volume1 brick4:/gluster/volumes/volume1

On voit qu'on a maintenant un volume distribué-répliqué à 4 briques :
# gluster volume info volume1 |egrep "Type|Number"
Type: Distributed-Replicate
Number of Bricks: 2 x 2 = 4

Côté client, l'espace disque a doublé (si les volumes sont tous de taille identique).

Par contre, si on a étendu le volume parce que les montages étaient pleins sur brick1 et 2, alors c'est toujours le cas. Car l'ajout de briques ne réparti pas automatiquement les données sur l'ensemble des briques. On va donc le forcer avec la commande :
# gluster volume rebalance volume1 start

Et on peut voir la progression avec la commande :
# gluster volume rebalance volume1 status

==Ajouter un replica==

Repartons de la situation de départ ou volume1 était réparti uniquement sur 2 briques : brick1 et brick2. On va ajouter une brique brick3. Comme c’est un volume répliqué, ça va ajouter une brique répliquée, on va donc passer le replica à 3. Ça permettra de permettre la perte de 2 serveurs, mais n’augmentera pas la volumétrie. La syntaxe est la suivante.
# gluster volume add-brick volume1 replica 3 ubuntu-fred:/gluster/volumes/volume1

On vérifie que ça a fonctionné :
# gluster volume info volume1 |grep "Number of Bricks"
Number of Bricks: 1 x 3 = 3

==Infos détaillées et perfs==

root@debian-fred:~# gluster volume profile volume1 info
Brick: brick1:/Gluster/Volumes/Volume1
-------------------------------------------
Cumulative Stats:
%-latency Avg-latency Min-Latency Max-Latency No. of calls Fop
--------- ----------- ----------- ----------- ------------ ----
0.00 0.00 us 0.00 us 0.00 us 3 RELEASEDIR

Duration: 251 seconds
Data Read: 0 bytes
Data Written: 0 bytes

Interval 1 Stats:

Duration: 32 seconds
Data Read: 0 bytes
Data Written: 0 bytes

Brick: brick2:/gluster/volumes/volume1
--------------------------------------------
Cumulative Stats:
%-latency Avg-latency Min-Latency Max-Latency No. of calls Fop
--------- ----------- ----------- ----------- ------------ ----
0.00 0.00 us 0.00 us 0.00 us 3 RELEASEDIR

Duration: 252 seconds
Data Read: 0 bytes
Data Written: 0 bytes

Interval 1 Stats:

Duration: 32 seconds
Data Read: 0 bytes
Data Written: 0 bytes

=Comparaison avec Ceph=

Une explication détaillée est disponible ici : https://www.ionos.fr/digitalguide/serveur/know-how/glusterfs-vs-ceph/

GlusterFS

2021-12-13T16:14:40Z

AdminWiki : /* Présentation */

[[Category:linux]]

=Présentation=

GlusterFS est un système de fichiers distribué, accessible par le réseau, en mode clients/serveurs.

On doit utiliser des systèmes de fichiers avec attributs étendus, comme XFS, ext4, ext3, ext2, ZFS, ReiserFS, btrfs et beaucoup d’autres. XFS est recommandé (https://docs.gluster.org/en/v3/Install-Guide/Common_criteria/).

Chaque serveur s’appelle un nœud ou brique. En réalité, une brique est le filesystem dédié à GlusterFS sur un nœud. Mais par abus de langage, dans la plupart des docs qu’on trouve, les nœuds sont appelés briques.

Minimum 2 briques. En réalité on peut en n’avoir qu’une, mais ça n’a aucun intérêt, autant faire un serveur NFS dans ce cas.

Il n'y a pas de notion maître/esclave.

Chaque fois qu'on ajoute une brique, le système devient plus performant.

Plusieurs types de volumes :
* volume distribué : comme du raid0, on perd une brique, on perd tout ! Mais volume total = somme des volumes :
[[Fichier:GlusterFS_volume_distribue_mini.jpg|300px]]

* volume répliqué : autant de briques que de répliquas désirés. Avec 2 briques, revient à du raid1 = miroring :
[[Fichier:GlusterFS_volume_replique.jpg|400px]]

* volume distribué répliqué :
[[Fichier:GlusterFS_volume_distribue_replique.jpg|500px]]

=Mise en place=

Gluster stocke ses fichiers de conf dynamiquement dans '''/var/lib/glusterd'''. Si jamais le filesystem se rempli, ça pourrait rendre le service instable, voire le planter complètement. Il est donc conseillé de le séparer de /var/log, voire de le mettre tout seul.

==Installation des packages==

Exemple sur Debian10 :
# apt install glusterfs-server -y
# systemctl enable --now glusterd

Exemple sur CentOS 8 :
# dnf install centos-release-gluster -y
# dnf install -y glusterfs-server
# systemctl enable --now glusterd glusterfsd

==Ouverture des flux==

Sur CentOS 8, ou une autre distribution avec firewalld actif, il faut ouvrir le service glusterfs :
# firewall-cmd --zone=public --add-service=glusterfs
# firewall-cmd --zone=public --add-service=glusterfs --permanent

Ce service inclus les ports suivants : 24007/tcp, 24008/tcp, 24009/tcp, 38465/tcp, 38466/tcp, 38467/tcp, 38468/tcp, 38469/tcp et la plage 49152-49664/tcp.

A noter que cette liste me paraît très large. Sur le site de glusterfs, pour la 3.7.0 beta 1, ils ne parlent que de 24007/tcp, 24008/tcp et 49152 à 49156/tcp ([[https://docs.gluster.org/en/release-3.7.0beta1/Administrator%20Guide/Setting%20Up%20Clients/]]).

==Trusted pool==

Supposons que nous avons deux briques : brick1 et brick2.

Une fois que les briques sont installées, il faut les associer. Les briques se reconnaissent au sein de ce qu'on appelle un trusted pool.

Pour cela, aller sur une des briques, par exemple brick1, et taper :
brick1# gluster peer probe brick2
peer probe : success.

Pour vérifier :
# gluster peer status
Number of Peers: 1

Hostname: brick2
Uuid: 2b5f991b-8a43-43fc-836b-f6292157489a
State: Peer in Cluster (Connected)

Pour afficher la liste de briques :
# gluster pool list
UUID Hostname State
2b5f991b-8a43-43fc-836b-f6292157489a brick2 Connected
9189775d-c84f-48a8-93bc-85e3a10af75d localhost Connected

Si on veut supprimer une brique du pool :
# gluster peer detach brick2

==Création d'un volume répliqué==

Sur brick1, on a créé un point de montage /Gluster/Volumes en XFS.
Sur brick2, on a créé un point de montage /gluster/volumes en ext4.

On ne peut pas créer de volume directement sur un point de montage, donc on va créer des sous-répertoires.

Sur brick1, on créé /Gluster/Volumes/Volume1.
Sur brick2, on créé /gluster/volumes/volume1.

J'ai fait exprès de mettre des majuscules d'un côté et des minuscules de l'autre, pour montrer que ça n'a aucune importance d'avoir des noms et arborescences différentes sur les briques.

On va créer un volume miroir nommé "volume1", avec 2 replicas, en utilisant le transport tcp :
# gluster volume create volume1 replica 2 transport tcp brick1:/Gluster/Volumes/Volume1 brick2:/gluster/volumes/volume1
Replica 2 volumes are prone to split-brain. Use Arbiter or Replica 3 to avoid this. See:
http://docs.gluster.org/en/latest/Administrator%20Guide/Split%20brain%20and%20ways%20to%20deal%20with%20it/.
Do you still want to continue?
(y/n) y
volume create: volume1: success: please start the volume to access data

On voit l'avertissement disant qu'il est préférable d'avoir au moins 3 briques. Malgré tout, on créé le volume.
Pour voir :
# gluster volume list
volume1
root@emmabuntus:~# gluster volume status
Volume volume1 is not started

On voit que le volume est créé, mais pas démarré.
Pour le démarrer et vérifier :
# gluster volume start volume1
volume start: volume1: success

# gluster volume list
volume1

# gluster volume status
Status of volume: volume1
Gluster process TCP Port RDMA Port Online Pid
------------------------------------------------------------------------------
Brick brick1:/Gluster/Volumes/Volume1 49152 0 Y 1737
Brick brick2:/gluster/volumes/volume1 49152 0 Y 1925
Self-heal Daemon on localhost N/A N/A Y 1948
Self-heal Daemon on brick1 N/A N/A Y 1760

Task Status of Volume volume1
------------------------------------------------------------------------------
There are no active volume tasks

==Montage depuis un client==

Installer le package "glusterfs-client".
Monter en précisant une des briques et en indiquant le point de montage :
# mount -t glusterfs brick1:/volume1 /mnt
Ou depuis /etc/fstab :
brick1:/volume1 /mnt glusterfs defaults 0 0
A noter qu'au lieu d'utiliser le client natif gluster comme on vient de le faire, on peut aussi utiliser NFS ou CIFS/samba. Mais dans ce cas il est préférable de mettre les nœuds en cluster de type CTDB (cluster NFS) pour avoir de la haute disponibilité. C'est donc beaucoup plus contraignant.
Lors du montage, on doit indiquer le nom d'une des briques (ici brick1). Mais le client récupère ensuite la liste de toutes les briques et peut communiquer avec n'importe laquelle.

==Paramétrage du volume==

===Timeout===
Par défaut, le timeout pour qu'un client bascule d'une brique à l'autre, en cas d'indisponibilité, est de 42 secondes. Ça peut paraître très long. Voici comment le passer à 5 secondes.
# gluster volume set volume1 network.ping-timeout 5

===Limiter les accès===
Pour limiter l'accès d'un volume aux machines du réseau 10.34.210.0/24 :
# gluster volume set volume1 auth.allow 10.34.210.*
On peut mettre plusieurs ips ou réseaux en les séparant par des virgules.
Pour revenir au comportement par défaut, il faut autoriser "*".
A l'inverse, on peut autoriser tout le monde, sauf des ips, avec le paramètre '''auth.reject'''.
Dans ce cas, pour revenir au comportement par défaut, on va rejeter "NONE".

===Quotas===
On peut activer des quotas pour le volume au niveau des sous-répertoires.
Il faut d'abord activer les quotas :
# gluster volume quota volume1 enable
Puis on défini la valeur :
# gluster volume quota volume1 limit-usage /sous-repertoire 100M
Pour voir l'état des quotas :
# gluster volume quota volume1 list

===Corbeille===
On peut activer une corbeille pour conserver les fichiers supprimés. On peut également limiter la taille aux fichiers de moins de 10Mo.
# gluster volume set volume1 features.trash on
# gluster volume set volume1 features.trash-dir "Poubelle"
# gluster volume set volume1 features.trash-max-falesize 10485760
On peut également activer la corbeille pour les opérations internes comme "rebalance" (par défaut à off) :
# gluster volume set volume1 features.trash-internal-op on

=Administration courante=

==Retirer une brique==

Si on veut retirer une brique.
# gluster peer detach ma_brique

==Remplacement d'une brique (si panne par exemple)==

Nous avons actuellement un trusted pool composé des deux briques brick1 et brick2.

Supposons que brick1 est tombée en panne et n'est pas réparable. On a préparé un nouveau serveur "brick3" et on installé les packages comme expliqué aux chapitres 3.1 et 3.2. Il faut aussi avoir préparé une arborescence /Gluster/Volumes/Volume1 ou équivalente pour accueillir le volume.

Connectons-nous sur brick2 et ajoutons brick3 au trusted-pool :
# gluster peer probe brick3

Maintenant on remplace brick1 par brick3 dans la config du volume "volume1" :
# gluster volume replace-brick volume1 brick1:/Gluster/Volumes/Volume1 brick3:/Gluster/Volumes/Volume1 commit force

On réconcilie le volume :
# gluster volume heal volume1 full

Depuis la nouvelle brique brick3, on synchronise le volume en récupérant les infos de brick2 :
root@brick3 # gluster volume sync brick2 volume1

Il faut ensuite récupérer le volume id depuis les attributs étendus du serveur brick2, pour ensuite les recopier sur brick3.

Récupération volume id :
root@brick2 # getfattr -n trusted.glusterfs.volume-id /gluster/volumes/volume1/
fichier-depuis-client.rien .glusterfs/
[root@centos8-fred ~]# getfattr -n trusted.glusterfs.volume-id /gluster/volumes/volume1/
getfattr: Removing leading '/' from absolute path names
# file: gluster/volumes/volume1/
trusted.glusterfs.volume-id=0s2M71q2FpQoi19v6sUcnyqw==

Recopie volume id sur brick3 :
root@brick3 # setfattr -n trusted.glusterfs.volume-id -v '0s2M71q2FpQoi19v6sUcnyqw==' /Gluster/Volumes/Volume1/

Il ne reste plus qu'à retirer brick1 du trusted pool :
# gluster peer detach brick1

==Étendre un volume==

Actuellement, notre volume1 est sur un volume répliqué sur un cluster à 2 briques. On peut le voir avec la commande suivante :
# gluster volume info volume1 |egrep "Type|Number"
Type: Replicate
Number of Bricks: 1 x 2 = 2

Pour l'étendre, on peut agrandir les volumes sur chaque brique, si c'est possible. Sinon, on peut aussi ajouter des briques. C'est ce qu'on va faire ici. A noter qu'il faut ajouter un nombre de briques proportionnel au nombre de replicas, donc ici 2. Ou alors il faut modifier le nombre de replicas, c’est ce qu’on va voir au chapitre suivant « ajouter un replica ».

On va donc créer deux nouveaux serveurs brick3 et brick4, y installer les packages nécessaires et démarrer les services (voir chapitres 3.1 et 3.2).

On les ajoute au trusted pool depuis une des briques existantes :
brick1# gluster peer probe brick3
brick1# gluster peer probe brick4

Sur brick3 et brick4 on créé un point de montage /gluster/volumes/ avec un sous-répertoire volume1, comme présenté au chapitre 3.4.

Pour finir, on va ajouter les volumes des nouvelles briques à volume1 :
brick1# gluster volume add-brick volume1 brick3:/gluster/volumes/volume1 brick4:/gluster/volumes/volume1

On voit qu'on a maintenant un volume distribué-répliqué à 4 briques :
# gluster volume info volume1 |egrep "Type|Number"
Type: Distributed-Replicate
Number of Bricks: 2 x 2 = 4

Côté client, l'espace disque a doublé (si les volumes sont tous de taille identique).

Par contre, si on a étendu le volume parce que les montages étaient pleins sur brick1 et 2, alors c'est toujours le cas. Car l'ajout de briques ne réparti pas automatiquement les données sur l'ensemble des briques. On va donc le forcer avec la commande :
# gluster volume rebalance volume1 start

Et on peut voir la progression avec la commande :
# gluster volume rebalance volume1 status

==Ajouter un replica==

Repartons de la situation de départ ou volume1 était réparti uniquement sur 2 briques : brick1 et brick2. On va ajouter une brique brick3. Comme c’est un volume répliqué, ça va ajouter une brique répliquée, on va donc passer le replica à 3. Ça permettra de permettre la perte de 2 serveurs, mais n’augmentera pas la volumétrie. La syntaxe est la suivante.
# gluster volume add-brick volume1 replica 3 ubuntu-fred:/gluster/volumes/volume1

On vérifie que ça a fonctionné :
# gluster volume info volume1 |grep "Number of Bricks"
Number of Bricks: 1 x 3 = 3

==Infos détaillées et perfs==

root@debian-fred:~# gluster volume profile volume1 info
Brick: brick1:/Gluster/Volumes/Volume1
-------------------------------------------
Cumulative Stats:
%-latency Avg-latency Min-Latency Max-Latency No. of calls Fop
--------- ----------- ----------- ----------- ------------ ----
0.00 0.00 us 0.00 us 0.00 us 3 RELEASEDIR

Duration: 251 seconds
Data Read: 0 bytes
Data Written: 0 bytes

Interval 1 Stats:

Duration: 32 seconds
Data Read: 0 bytes
Data Written: 0 bytes

Brick: brick2:/gluster/volumes/volume1
--------------------------------------------
Cumulative Stats:
%-latency Avg-latency Min-Latency Max-Latency No. of calls Fop
--------- ----------- ----------- ----------- ------------ ----
0.00 0.00 us 0.00 us 0.00 us 3 RELEASEDIR

Duration: 252 seconds
Data Read: 0 bytes
Data Written: 0 bytes

Interval 1 Stats:

Duration: 32 seconds
Data Read: 0 bytes
Data Written: 0 bytes

=Comparaison avec Ceph=

Une explication détaillée est disponible ici : https://www.ionos.fr/digitalguide/serveur/know-how/glusterfs-vs-ceph/

GlusterFS

2021-12-13T16:11:44Z

AdminWiki : /* Présentation */

[[Category:linux]]

=Présentation=

GlusterFS est un système de fichiers distribué, accessible par le réseau, en mode clients/serveurs.

On doit utiliser des systèmes de fichiers avec attributs étendus, comme XFS, ext4, ext3, ext2, ZFS, ReiserFS, btrfs et beaucoup d’autres. XFS est recommandé (https://docs.gluster.org/en/v3/Install-Guide/Common_criteria/).

Chaque serveur s’appelle un nœud ou brique. En réalité, une brique est le filesystem dédié à GlusterFS sur un nœud. Mais par abus de langage, dans la plupart des docs qu’on trouve, les nœuds sont appelés briques.

Minimum 2 briques. En réalité on peut en n’avoir qu’une, mais ça n’a aucun intérêt, autant faire un serveur NFS dans ce cas.

Il n'y a pas de notion maître/esclave.

Chaque fois qu'on ajoute une brique, le système devient plus performant.

Plusieurs types de volumes :
* volume distribué : comme du raid0, on perd une brique, on perd tout ! Mais volume total = somme des volumes :
{|class="wikitable alternance centre"
|-
| [[File:GlusterFS_volume_distribue_mini.jpg|frameless]]
|-
| Volume distribué
|}

[[Fichier:GlusterFS_volume_distribue_mini.jpg]]

* volume répliqué : autant de briques que de répliquas désirés. Avec 2 briques, revient à du raid1 = miroring :
[[Fichier:GlusterFS_volume_replique.jpg|500px]]

* volume distribué répliqué :
[[Fichier:GlusterFS_volume_distribue_replique.jpg|500px]]

=Mise en place=

Gluster stocke ses fichiers de conf dynamiquement dans '''/var/lib/glusterd'''. Si jamais le filesystem se rempli, ça pourrait rendre le service instable, voire le planter complètement. Il est donc conseillé de le séparer de /var/log, voire de le mettre tout seul.

==Installation des packages==

Exemple sur Debian10 :
# apt install glusterfs-server -y
# systemctl enable --now glusterd

Exemple sur CentOS 8 :
# dnf install centos-release-gluster -y
# dnf install -y glusterfs-server
# systemctl enable --now glusterd glusterfsd

==Ouverture des flux==

Sur CentOS 8, ou une autre distribution avec firewalld actif, il faut ouvrir le service glusterfs :
# firewall-cmd --zone=public --add-service=glusterfs
# firewall-cmd --zone=public --add-service=glusterfs --permanent

Ce service inclus les ports suivants : 24007/tcp, 24008/tcp, 24009/tcp, 38465/tcp, 38466/tcp, 38467/tcp, 38468/tcp, 38469/tcp et la plage 49152-49664/tcp.

A noter que cette liste me paraît très large. Sur le site de glusterfs, pour la 3.7.0 beta 1, ils ne parlent que de 24007/tcp, 24008/tcp et 49152 à 49156/tcp ([[https://docs.gluster.org/en/release-3.7.0beta1/Administrator%20Guide/Setting%20Up%20Clients/]]).

==Trusted pool==

Supposons que nous avons deux briques : brick1 et brick2.

Une fois que les briques sont installées, il faut les associer. Les briques se reconnaissent au sein de ce qu'on appelle un trusted pool.

Pour cela, aller sur une des briques, par exemple brick1, et taper :
brick1# gluster peer probe brick2
peer probe : success.

Pour vérifier :
# gluster peer status
Number of Peers: 1

Hostname: brick2
Uuid: 2b5f991b-8a43-43fc-836b-f6292157489a
State: Peer in Cluster (Connected)

Pour afficher la liste de briques :
# gluster pool list
UUID Hostname State
2b5f991b-8a43-43fc-836b-f6292157489a brick2 Connected
9189775d-c84f-48a8-93bc-85e3a10af75d localhost Connected

Si on veut supprimer une brique du pool :
# gluster peer detach brick2

==Création d'un volume répliqué==

Sur brick1, on a créé un point de montage /Gluster/Volumes en XFS.
Sur brick2, on a créé un point de montage /gluster/volumes en ext4.

On ne peut pas créer de volume directement sur un point de montage, donc on va créer des sous-répertoires.

Sur brick1, on créé /Gluster/Volumes/Volume1.
Sur brick2, on créé /gluster/volumes/volume1.

J'ai fait exprès de mettre des majuscules d'un côté et des minuscules de l'autre, pour montrer que ça n'a aucune importance d'avoir des noms et arborescences différentes sur les briques.

On va créer un volume miroir nommé "volume1", avec 2 replicas, en utilisant le transport tcp :
# gluster volume create volume1 replica 2 transport tcp brick1:/Gluster/Volumes/Volume1 brick2:/gluster/volumes/volume1
Replica 2 volumes are prone to split-brain. Use Arbiter or Replica 3 to avoid this. See:
http://docs.gluster.org/en/latest/Administrator%20Guide/Split%20brain%20and%20ways%20to%20deal%20with%20it/.
Do you still want to continue?
(y/n) y
volume create: volume1: success: please start the volume to access data

On voit l'avertissement disant qu'il est préférable d'avoir au moins 3 briques. Malgré tout, on créé le volume.
Pour voir :
# gluster volume list
volume1
root@emmabuntus:~# gluster volume status
Volume volume1 is not started

On voit que le volume est créé, mais pas démarré.
Pour le démarrer et vérifier :
# gluster volume start volume1
volume start: volume1: success

# gluster volume list
volume1

# gluster volume status
Status of volume: volume1
Gluster process TCP Port RDMA Port Online Pid
------------------------------------------------------------------------------
Brick brick1:/Gluster/Volumes/Volume1 49152 0 Y 1737
Brick brick2:/gluster/volumes/volume1 49152 0 Y 1925
Self-heal Daemon on localhost N/A N/A Y 1948
Self-heal Daemon on brick1 N/A N/A Y 1760

Task Status of Volume volume1
------------------------------------------------------------------------------
There are no active volume tasks

==Montage depuis un client==

Installer le package "glusterfs-client".
Monter en précisant une des briques et en indiquant le point de montage :
# mount -t glusterfs brick1:/volume1 /mnt
Ou depuis /etc/fstab :
brick1:/volume1 /mnt glusterfs defaults 0 0
A noter qu'au lieu d'utiliser le client natif gluster comme on vient de le faire, on peut aussi utiliser NFS ou CIFS/samba. Mais dans ce cas il est préférable de mettre les nœuds en cluster de type CTDB (cluster NFS) pour avoir de la haute disponibilité. C'est donc beaucoup plus contraignant.
Lors du montage, on doit indiquer le nom d'une des briques (ici brick1). Mais le client récupère ensuite la liste de toutes les briques et peut communiquer avec n'importe laquelle.

==Paramétrage du volume==

===Timeout===
Par défaut, le timeout pour qu'un client bascule d'une brique à l'autre, en cas d'indisponibilité, est de 42 secondes. Ça peut paraître très long. Voici comment le passer à 5 secondes.
# gluster volume set volume1 network.ping-timeout 5

===Limiter les accès===
Pour limiter l'accès d'un volume aux machines du réseau 10.34.210.0/24 :
# gluster volume set volume1 auth.allow 10.34.210.*
On peut mettre plusieurs ips ou réseaux en les séparant par des virgules.
Pour revenir au comportement par défaut, il faut autoriser "*".
A l'inverse, on peut autoriser tout le monde, sauf des ips, avec le paramètre '''auth.reject'''.
Dans ce cas, pour revenir au comportement par défaut, on va rejeter "NONE".

===Quotas===
On peut activer des quotas pour le volume au niveau des sous-répertoires.
Il faut d'abord activer les quotas :
# gluster volume quota volume1 enable
Puis on défini la valeur :
# gluster volume quota volume1 limit-usage /sous-repertoire 100M
Pour voir l'état des quotas :
# gluster volume quota volume1 list

===Corbeille===
On peut activer une corbeille pour conserver les fichiers supprimés. On peut également limiter la taille aux fichiers de moins de 10Mo.
# gluster volume set volume1 features.trash on
# gluster volume set volume1 features.trash-dir "Poubelle"
# gluster volume set volume1 features.trash-max-falesize 10485760
On peut également activer la corbeille pour les opérations internes comme "rebalance" (par défaut à off) :
# gluster volume set volume1 features.trash-internal-op on

=Administration courante=

==Retirer une brique==

Si on veut retirer une brique.
# gluster peer detach ma_brique

==Remplacement d'une brique (si panne par exemple)==

Nous avons actuellement un trusted pool composé des deux briques brick1 et brick2.

Supposons que brick1 est tombée en panne et n'est pas réparable. On a préparé un nouveau serveur "brick3" et on installé les packages comme expliqué aux chapitres 3.1 et 3.2. Il faut aussi avoir préparé une arborescence /Gluster/Volumes/Volume1 ou équivalente pour accueillir le volume.

Connectons-nous sur brick2 et ajoutons brick3 au trusted-pool :
# gluster peer probe brick3

Maintenant on remplace brick1 par brick3 dans la config du volume "volume1" :
# gluster volume replace-brick volume1 brick1:/Gluster/Volumes/Volume1 brick3:/Gluster/Volumes/Volume1 commit force

On réconcilie le volume :
# gluster volume heal volume1 full

Depuis la nouvelle brique brick3, on synchronise le volume en récupérant les infos de brick2 :
root@brick3 # gluster volume sync brick2 volume1

Il faut ensuite récupérer le volume id depuis les attributs étendus du serveur brick2, pour ensuite les recopier sur brick3.

Récupération volume id :
root@brick2 # getfattr -n trusted.glusterfs.volume-id /gluster/volumes/volume1/
fichier-depuis-client.rien .glusterfs/
[root@centos8-fred ~]# getfattr -n trusted.glusterfs.volume-id /gluster/volumes/volume1/
getfattr: Removing leading '/' from absolute path names
# file: gluster/volumes/volume1/
trusted.glusterfs.volume-id=0s2M71q2FpQoi19v6sUcnyqw==

Recopie volume id sur brick3 :
root@brick3 # setfattr -n trusted.glusterfs.volume-id -v '0s2M71q2FpQoi19v6sUcnyqw==' /Gluster/Volumes/Volume1/

Il ne reste plus qu'à retirer brick1 du trusted pool :
# gluster peer detach brick1

==Étendre un volume==

Actuellement, notre volume1 est sur un volume répliqué sur un cluster à 2 briques. On peut le voir avec la commande suivante :
# gluster volume info volume1 |egrep "Type|Number"
Type: Replicate
Number of Bricks: 1 x 2 = 2

Pour l'étendre, on peut agrandir les volumes sur chaque brique, si c'est possible. Sinon, on peut aussi ajouter des briques. C'est ce qu'on va faire ici. A noter qu'il faut ajouter un nombre de briques proportionnel au nombre de replicas, donc ici 2. Ou alors il faut modifier le nombre de replicas, c’est ce qu’on va voir au chapitre suivant « ajouter un replica ».

On va donc créer deux nouveaux serveurs brick3 et brick4, y installer les packages nécessaires et démarrer les services (voir chapitres 3.1 et 3.2).

On les ajoute au trusted pool depuis une des briques existantes :
brick1# gluster peer probe brick3
brick1# gluster peer probe brick4

Sur brick3 et brick4 on créé un point de montage /gluster/volumes/ avec un sous-répertoire volume1, comme présenté au chapitre 3.4.

Pour finir, on va ajouter les volumes des nouvelles briques à volume1 :
brick1# gluster volume add-brick volume1 brick3:/gluster/volumes/volume1 brick4:/gluster/volumes/volume1

On voit qu'on a maintenant un volume distribué-répliqué à 4 briques :
# gluster volume info volume1 |egrep "Type|Number"
Type: Distributed-Replicate
Number of Bricks: 2 x 2 = 4

Côté client, l'espace disque a doublé (si les volumes sont tous de taille identique).

Par contre, si on a étendu le volume parce que les montages étaient pleins sur brick1 et 2, alors c'est toujours le cas. Car l'ajout de briques ne réparti pas automatiquement les données sur l'ensemble des briques. On va donc le forcer avec la commande :
# gluster volume rebalance volume1 start

Et on peut voir la progression avec la commande :
# gluster volume rebalance volume1 status

==Ajouter un replica==

Repartons de la situation de départ ou volume1 était réparti uniquement sur 2 briques : brick1 et brick2. On va ajouter une brique brick3. Comme c’est un volume répliqué, ça va ajouter une brique répliquée, on va donc passer le replica à 3. Ça permettra de permettre la perte de 2 serveurs, mais n’augmentera pas la volumétrie. La syntaxe est la suivante.
# gluster volume add-brick volume1 replica 3 ubuntu-fred:/gluster/volumes/volume1

On vérifie que ça a fonctionné :
# gluster volume info volume1 |grep "Number of Bricks"
Number of Bricks: 1 x 3 = 3

==Infos détaillées et perfs==

root@debian-fred:~# gluster volume profile volume1 info
Brick: brick1:/Gluster/Volumes/Volume1
-------------------------------------------
Cumulative Stats:
%-latency Avg-latency Min-Latency Max-Latency No. of calls Fop
--------- ----------- ----------- ----------- ------------ ----
0.00 0.00 us 0.00 us 0.00 us 3 RELEASEDIR

Duration: 251 seconds
Data Read: 0 bytes
Data Written: 0 bytes

Interval 1 Stats:

Duration: 32 seconds
Data Read: 0 bytes
Data Written: 0 bytes

Brick: brick2:/gluster/volumes/volume1
--------------------------------------------
Cumulative Stats:
%-latency Avg-latency Min-Latency Max-Latency No. of calls Fop
--------- ----------- ----------- ----------- ------------ ----
0.00 0.00 us 0.00 us 0.00 us 3 RELEASEDIR

Duration: 252 seconds
Data Read: 0 bytes
Data Written: 0 bytes

Interval 1 Stats:

Duration: 32 seconds
Data Read: 0 bytes
Data Written: 0 bytes

=Comparaison avec Ceph=

Une explication détaillée est disponible ici : https://www.ionos.fr/digitalguide/serveur/know-how/glusterfs-vs-ceph/

Fichier:GlusterFS volume distribue mini.jpg

2021-12-13T16:10:21Z

AdminWiki :

GlusterFS

2021-12-13T16:07:59Z

AdminWiki : /* Présentation */

[[Category:linux]]

=Présentation=

GlusterFS est un système de fichiers distribué, accessible par le réseau, en mode clients/serveurs.

On doit utiliser des systèmes de fichiers avec attributs étendus, comme XFS, ext4, ext3, ext2, ZFS, ReiserFS, btrfs et beaucoup d’autres. XFS est recommandé (https://docs.gluster.org/en/v3/Install-Guide/Common_criteria/).

Chaque serveur s’appelle un nœud ou brique. En réalité, une brique est le filesystem dédié à GlusterFS sur un nœud. Mais par abus de langage, dans la plupart des docs qu’on trouve, les nœuds sont appelés briques.

Minimum 2 briques. En réalité on peut en n’avoir qu’une, mais ça n’a aucun intérêt, autant faire un serveur NFS dans ce cas.

Il n'y a pas de notion maître/esclave.

Chaque fois qu'on ajoute une brique, le système devient plus performant.

Plusieurs types de volumes :
* volume distribué : comme du raid0, on perd une brique, on perd tout ! Mais volume total = somme des volumes :
{|class="wikitable alternance centre"
|-
| [[File:GlusterFS_volume_distribue.jpg|frameless]]
|-
| Volume distribué
|}

[[Fichier:GlusterFS_volume_distribue_mini.jpg]]

* volume répliqué : autant de briques que de répliquas désirés. Avec 2 briques, revient à du raid1 = miroring :
[[Fichier:GlusterFS_volume_replique.jpg|500px]]

* volume distribué répliqué :
[[Fichier:GlusterFS_volume_distribue_replique.jpg|500px]]

=Mise en place=

Gluster stocke ses fichiers de conf dynamiquement dans '''/var/lib/glusterd'''. Si jamais le filesystem se rempli, ça pourrait rendre le service instable, voire le planter complètement. Il est donc conseillé de le séparer de /var/log, voire de le mettre tout seul.

==Installation des packages==

Exemple sur Debian10 :
# apt install glusterfs-server -y
# systemctl enable --now glusterd

Exemple sur CentOS 8 :
# dnf install centos-release-gluster -y
# dnf install -y glusterfs-server
# systemctl enable --now glusterd glusterfsd

==Ouverture des flux==

Sur CentOS 8, ou une autre distribution avec firewalld actif, il faut ouvrir le service glusterfs :
# firewall-cmd --zone=public --add-service=glusterfs
# firewall-cmd --zone=public --add-service=glusterfs --permanent

Ce service inclus les ports suivants : 24007/tcp, 24008/tcp, 24009/tcp, 38465/tcp, 38466/tcp, 38467/tcp, 38468/tcp, 38469/tcp et la plage 49152-49664/tcp.

A noter que cette liste me paraît très large. Sur le site de glusterfs, pour la 3.7.0 beta 1, ils ne parlent que de 24007/tcp, 24008/tcp et 49152 à 49156/tcp ([[https://docs.gluster.org/en/release-3.7.0beta1/Administrator%20Guide/Setting%20Up%20Clients/]]).

==Trusted pool==

Supposons que nous avons deux briques : brick1 et brick2.

Une fois que les briques sont installées, il faut les associer. Les briques se reconnaissent au sein de ce qu'on appelle un trusted pool.

Pour cela, aller sur une des briques, par exemple brick1, et taper :
brick1# gluster peer probe brick2
peer probe : success.

Pour vérifier :
# gluster peer status
Number of Peers: 1

Hostname: brick2
Uuid: 2b5f991b-8a43-43fc-836b-f6292157489a
State: Peer in Cluster (Connected)

Pour afficher la liste de briques :
# gluster pool list
UUID Hostname State
2b5f991b-8a43-43fc-836b-f6292157489a brick2 Connected
9189775d-c84f-48a8-93bc-85e3a10af75d localhost Connected

Si on veut supprimer une brique du pool :
# gluster peer detach brick2

==Création d'un volume répliqué==

Sur brick1, on a créé un point de montage /Gluster/Volumes en XFS.
Sur brick2, on a créé un point de montage /gluster/volumes en ext4.

On ne peut pas créer de volume directement sur un point de montage, donc on va créer des sous-répertoires.

Sur brick1, on créé /Gluster/Volumes/Volume1.
Sur brick2, on créé /gluster/volumes/volume1.

J'ai fait exprès de mettre des majuscules d'un côté et des minuscules de l'autre, pour montrer que ça n'a aucune importance d'avoir des noms et arborescences différentes sur les briques.

On va créer un volume miroir nommé "volume1", avec 2 replicas, en utilisant le transport tcp :
# gluster volume create volume1 replica 2 transport tcp brick1:/Gluster/Volumes/Volume1 brick2:/gluster/volumes/volume1
Replica 2 volumes are prone to split-brain. Use Arbiter or Replica 3 to avoid this. See:
http://docs.gluster.org/en/latest/Administrator%20Guide/Split%20brain%20and%20ways%20to%20deal%20with%20it/.
Do you still want to continue?
(y/n) y
volume create: volume1: success: please start the volume to access data

On voit l'avertissement disant qu'il est préférable d'avoir au moins 3 briques. Malgré tout, on créé le volume.
Pour voir :
# gluster volume list
volume1
root@emmabuntus:~# gluster volume status
Volume volume1 is not started

On voit que le volume est créé, mais pas démarré.
Pour le démarrer et vérifier :
# gluster volume start volume1
volume start: volume1: success

# gluster volume list
volume1

# gluster volume status
Status of volume: volume1
Gluster process TCP Port RDMA Port Online Pid
------------------------------------------------------------------------------
Brick brick1:/Gluster/Volumes/Volume1 49152 0 Y 1737
Brick brick2:/gluster/volumes/volume1 49152 0 Y 1925
Self-heal Daemon on localhost N/A N/A Y 1948
Self-heal Daemon on brick1 N/A N/A Y 1760

Task Status of Volume volume1
------------------------------------------------------------------------------
There are no active volume tasks

==Montage depuis un client==

Installer le package "glusterfs-client".
Monter en précisant une des briques et en indiquant le point de montage :
# mount -t glusterfs brick1:/volume1 /mnt
Ou depuis /etc/fstab :
brick1:/volume1 /mnt glusterfs defaults 0 0
A noter qu'au lieu d'utiliser le client natif gluster comme on vient de le faire, on peut aussi utiliser NFS ou CIFS/samba. Mais dans ce cas il est préférable de mettre les nœuds en cluster de type CTDB (cluster NFS) pour avoir de la haute disponibilité. C'est donc beaucoup plus contraignant.
Lors du montage, on doit indiquer le nom d'une des briques (ici brick1). Mais le client récupère ensuite la liste de toutes les briques et peut communiquer avec n'importe laquelle.

==Paramétrage du volume==

===Timeout===
Par défaut, le timeout pour qu'un client bascule d'une brique à l'autre, en cas d'indisponibilité, est de 42 secondes. Ça peut paraître très long. Voici comment le passer à 5 secondes.
# gluster volume set volume1 network.ping-timeout 5

===Limiter les accès===
Pour limiter l'accès d'un volume aux machines du réseau 10.34.210.0/24 :
# gluster volume set volume1 auth.allow 10.34.210.*
On peut mettre plusieurs ips ou réseaux en les séparant par des virgules.
Pour revenir au comportement par défaut, il faut autoriser "*".
A l'inverse, on peut autoriser tout le monde, sauf des ips, avec le paramètre '''auth.reject'''.
Dans ce cas, pour revenir au comportement par défaut, on va rejeter "NONE".

===Quotas===
On peut activer des quotas pour le volume au niveau des sous-répertoires.
Il faut d'abord activer les quotas :
# gluster volume quota volume1 enable
Puis on défini la valeur :
# gluster volume quota volume1 limit-usage /sous-repertoire 100M
Pour voir l'état des quotas :
# gluster volume quota volume1 list

===Corbeille===
On peut activer une corbeille pour conserver les fichiers supprimés. On peut également limiter la taille aux fichiers de moins de 10Mo.
# gluster volume set volume1 features.trash on
# gluster volume set volume1 features.trash-dir "Poubelle"
# gluster volume set volume1 features.trash-max-falesize 10485760
On peut également activer la corbeille pour les opérations internes comme "rebalance" (par défaut à off) :
# gluster volume set volume1 features.trash-internal-op on

=Administration courante=

==Retirer une brique==

Si on veut retirer une brique.
# gluster peer detach ma_brique

==Remplacement d'une brique (si panne par exemple)==

Nous avons actuellement un trusted pool composé des deux briques brick1 et brick2.

Supposons que brick1 est tombée en panne et n'est pas réparable. On a préparé un nouveau serveur "brick3" et on installé les packages comme expliqué aux chapitres 3.1 et 3.2. Il faut aussi avoir préparé une arborescence /Gluster/Volumes/Volume1 ou équivalente pour accueillir le volume.

Connectons-nous sur brick2 et ajoutons brick3 au trusted-pool :
# gluster peer probe brick3

Maintenant on remplace brick1 par brick3 dans la config du volume "volume1" :
# gluster volume replace-brick volume1 brick1:/Gluster/Volumes/Volume1 brick3:/Gluster/Volumes/Volume1 commit force

On réconcilie le volume :
# gluster volume heal volume1 full

Depuis la nouvelle brique brick3, on synchronise le volume en récupérant les infos de brick2 :
root@brick3 # gluster volume sync brick2 volume1

Il faut ensuite récupérer le volume id depuis les attributs étendus du serveur brick2, pour ensuite les recopier sur brick3.

Récupération volume id :
root@brick2 # getfattr -n trusted.glusterfs.volume-id /gluster/volumes/volume1/
fichier-depuis-client.rien .glusterfs/
[root@centos8-fred ~]# getfattr -n trusted.glusterfs.volume-id /gluster/volumes/volume1/
getfattr: Removing leading '/' from absolute path names
# file: gluster/volumes/volume1/
trusted.glusterfs.volume-id=0s2M71q2FpQoi19v6sUcnyqw==

Recopie volume id sur brick3 :
root@brick3 # setfattr -n trusted.glusterfs.volume-id -v '0s2M71q2FpQoi19v6sUcnyqw==' /Gluster/Volumes/Volume1/

Il ne reste plus qu'à retirer brick1 du trusted pool :
# gluster peer detach brick1

==Étendre un volume==

Actuellement, notre volume1 est sur un volume répliqué sur un cluster à 2 briques. On peut le voir avec la commande suivante :
# gluster volume info volume1 |egrep "Type|Number"
Type: Replicate
Number of Bricks: 1 x 2 = 2

Pour l'étendre, on peut agrandir les volumes sur chaque brique, si c'est possible. Sinon, on peut aussi ajouter des briques. C'est ce qu'on va faire ici. A noter qu'il faut ajouter un nombre de briques proportionnel au nombre de replicas, donc ici 2. Ou alors il faut modifier le nombre de replicas, c’est ce qu’on va voir au chapitre suivant « ajouter un replica ».

On va donc créer deux nouveaux serveurs brick3 et brick4, y installer les packages nécessaires et démarrer les services (voir chapitres 3.1 et 3.2).

On les ajoute au trusted pool depuis une des briques existantes :
brick1# gluster peer probe brick3
brick1# gluster peer probe brick4

Sur brick3 et brick4 on créé un point de montage /gluster/volumes/ avec un sous-répertoire volume1, comme présenté au chapitre 3.4.

Pour finir, on va ajouter les volumes des nouvelles briques à volume1 :
brick1# gluster volume add-brick volume1 brick3:/gluster/volumes/volume1 brick4:/gluster/volumes/volume1

On voit qu'on a maintenant un volume distribué-répliqué à 4 briques :
# gluster volume info volume1 |egrep "Type|Number"
Type: Distributed-Replicate
Number of Bricks: 2 x 2 = 4

Côté client, l'espace disque a doublé (si les volumes sont tous de taille identique).

Par contre, si on a étendu le volume parce que les montages étaient pleins sur brick1 et 2, alors c'est toujours le cas. Car l'ajout de briques ne réparti pas automatiquement les données sur l'ensemble des briques. On va donc le forcer avec la commande :
# gluster volume rebalance volume1 start

Et on peut voir la progression avec la commande :
# gluster volume rebalance volume1 status

==Ajouter un replica==

Repartons de la situation de départ ou volume1 était réparti uniquement sur 2 briques : brick1 et brick2. On va ajouter une brique brick3. Comme c’est un volume répliqué, ça va ajouter une brique répliquée, on va donc passer le replica à 3. Ça permettra de permettre la perte de 2 serveurs, mais n’augmentera pas la volumétrie. La syntaxe est la suivante.
# gluster volume add-brick volume1 replica 3 ubuntu-fred:/gluster/volumes/volume1

On vérifie que ça a fonctionné :
# gluster volume info volume1 |grep "Number of Bricks"
Number of Bricks: 1 x 3 = 3

==Infos détaillées et perfs==

root@debian-fred:~# gluster volume profile volume1 info
Brick: brick1:/Gluster/Volumes/Volume1
-------------------------------------------
Cumulative Stats:
%-latency Avg-latency Min-Latency Max-Latency No. of calls Fop
--------- ----------- ----------- ----------- ------------ ----
0.00 0.00 us 0.00 us 0.00 us 3 RELEASEDIR

Duration: 251 seconds
Data Read: 0 bytes
Data Written: 0 bytes

Interval 1 Stats:

Duration: 32 seconds
Data Read: 0 bytes
Data Written: 0 bytes

Brick: brick2:/gluster/volumes/volume1
--------------------------------------------
Cumulative Stats:
%-latency Avg-latency Min-Latency Max-Latency No. of calls Fop
--------- ----------- ----------- ----------- ------------ ----
0.00 0.00 us 0.00 us 0.00 us 3 RELEASEDIR

Duration: 252 seconds
Data Read: 0 bytes
Data Written: 0 bytes

Interval 1 Stats:

Duration: 32 seconds
Data Read: 0 bytes
Data Written: 0 bytes

=Comparaison avec Ceph=

Une explication détaillée est disponible ici : https://www.ionos.fr/digitalguide/serveur/know-how/glusterfs-vs-ceph/

GlusterFS

2021-12-13T16:05:44Z

AdminWiki : /* Présentation */

[[Category:linux]]

=Présentation=

GlusterFS est un système de fichiers distribué, accessible par le réseau, en mode clients/serveurs.

On doit utiliser des systèmes de fichiers avec attributs étendus, comme XFS, ext4, ext3, ext2, ZFS, ReiserFS, btrfs et beaucoup d’autres. XFS est recommandé (https://docs.gluster.org/en/v3/Install-Guide/Common_criteria/).

Chaque serveur s’appelle un nœud ou brique. En réalité, une brique est le filesystem dédié à GlusterFS sur un nœud. Mais par abus de langage, dans la plupart des docs qu’on trouve, les nœuds sont appelés briques.

Minimum 2 briques. En réalité on peut en n’avoir qu’une, mais ça n’a aucun intérêt, autant faire un serveur NFS dans ce cas.

Il n'y a pas de notion maître/esclave.

Chaque fois qu'on ajoute une brique, le système devient plus performant.

Plusieurs types de volumes :
* volume distribué : comme du raid0, on perd une brique, on perd tout ! Mais volume total = somme des volumes :
{|class="wikitable alternance centre"
|-
| [[File:GlusterFS_volume_distribue.jpg|frameless]]
|-
| Volume distribué
|}

[[Fichier:Gluster_vol_dist.png]]

* volume répliqué : autant de briques que de répliquas désirés. Avec 2 briques, revient à du raid1 = miroring :
[[Fichier:GlusterFS_volume_replique.jpg|500px]]

* volume distribué répliqué :
[[Fichier:GlusterFS_volume_distribue_replique.jpg|500px]]

=Mise en place=

Gluster stocke ses fichiers de conf dynamiquement dans '''/var/lib/glusterd'''. Si jamais le filesystem se rempli, ça pourrait rendre le service instable, voire le planter complètement. Il est donc conseillé de le séparer de /var/log, voire de le mettre tout seul.

==Installation des packages==

Exemple sur Debian10 :
# apt install glusterfs-server -y
# systemctl enable --now glusterd

Exemple sur CentOS 8 :
# dnf install centos-release-gluster -y
# dnf install -y glusterfs-server
# systemctl enable --now glusterd glusterfsd

==Ouverture des flux==

Sur CentOS 8, ou une autre distribution avec firewalld actif, il faut ouvrir le service glusterfs :
# firewall-cmd --zone=public --add-service=glusterfs
# firewall-cmd --zone=public --add-service=glusterfs --permanent

Ce service inclus les ports suivants : 24007/tcp, 24008/tcp, 24009/tcp, 38465/tcp, 38466/tcp, 38467/tcp, 38468/tcp, 38469/tcp et la plage 49152-49664/tcp.

A noter que cette liste me paraît très large. Sur le site de glusterfs, pour la 3.7.0 beta 1, ils ne parlent que de 24007/tcp, 24008/tcp et 49152 à 49156/tcp ([[https://docs.gluster.org/en/release-3.7.0beta1/Administrator%20Guide/Setting%20Up%20Clients/]]).

==Trusted pool==

Supposons que nous avons deux briques : brick1 et brick2.

Une fois que les briques sont installées, il faut les associer. Les briques se reconnaissent au sein de ce qu'on appelle un trusted pool.

Pour cela, aller sur une des briques, par exemple brick1, et taper :
brick1# gluster peer probe brick2
peer probe : success.

Pour vérifier :
# gluster peer status
Number of Peers: 1

Hostname: brick2
Uuid: 2b5f991b-8a43-43fc-836b-f6292157489a
State: Peer in Cluster (Connected)

Pour afficher la liste de briques :
# gluster pool list
UUID Hostname State
2b5f991b-8a43-43fc-836b-f6292157489a brick2 Connected
9189775d-c84f-48a8-93bc-85e3a10af75d localhost Connected

Si on veut supprimer une brique du pool :
# gluster peer detach brick2

==Création d'un volume répliqué==

Sur brick1, on a créé un point de montage /Gluster/Volumes en XFS.
Sur brick2, on a créé un point de montage /gluster/volumes en ext4.

On ne peut pas créer de volume directement sur un point de montage, donc on va créer des sous-répertoires.

Sur brick1, on créé /Gluster/Volumes/Volume1.
Sur brick2, on créé /gluster/volumes/volume1.

J'ai fait exprès de mettre des majuscules d'un côté et des minuscules de l'autre, pour montrer que ça n'a aucune importance d'avoir des noms et arborescences différentes sur les briques.

On va créer un volume miroir nommé "volume1", avec 2 replicas, en utilisant le transport tcp :
# gluster volume create volume1 replica 2 transport tcp brick1:/Gluster/Volumes/Volume1 brick2:/gluster/volumes/volume1
Replica 2 volumes are prone to split-brain. Use Arbiter or Replica 3 to avoid this. See:
http://docs.gluster.org/en/latest/Administrator%20Guide/Split%20brain%20and%20ways%20to%20deal%20with%20it/.
Do you still want to continue?
(y/n) y
volume create: volume1: success: please start the volume to access data

On voit l'avertissement disant qu'il est préférable d'avoir au moins 3 briques. Malgré tout, on créé le volume.
Pour voir :
# gluster volume list
volume1
root@emmabuntus:~# gluster volume status
Volume volume1 is not started

On voit que le volume est créé, mais pas démarré.
Pour le démarrer et vérifier :
# gluster volume start volume1
volume start: volume1: success

# gluster volume list
volume1

# gluster volume status
Status of volume: volume1
Gluster process TCP Port RDMA Port Online Pid
------------------------------------------------------------------------------
Brick brick1:/Gluster/Volumes/Volume1 49152 0 Y 1737
Brick brick2:/gluster/volumes/volume1 49152 0 Y 1925
Self-heal Daemon on localhost N/A N/A Y 1948
Self-heal Daemon on brick1 N/A N/A Y 1760

Task Status of Volume volume1
------------------------------------------------------------------------------
There are no active volume tasks

==Montage depuis un client==

Installer le package "glusterfs-client".
Monter en précisant une des briques et en indiquant le point de montage :
# mount -t glusterfs brick1:/volume1 /mnt
Ou depuis /etc/fstab :
brick1:/volume1 /mnt glusterfs defaults 0 0
A noter qu'au lieu d'utiliser le client natif gluster comme on vient de le faire, on peut aussi utiliser NFS ou CIFS/samba. Mais dans ce cas il est préférable de mettre les nœuds en cluster de type CTDB (cluster NFS) pour avoir de la haute disponibilité. C'est donc beaucoup plus contraignant.
Lors du montage, on doit indiquer le nom d'une des briques (ici brick1). Mais le client récupère ensuite la liste de toutes les briques et peut communiquer avec n'importe laquelle.

==Paramétrage du volume==

===Timeout===
Par défaut, le timeout pour qu'un client bascule d'une brique à l'autre, en cas d'indisponibilité, est de 42 secondes. Ça peut paraître très long. Voici comment le passer à 5 secondes.
# gluster volume set volume1 network.ping-timeout 5

===Limiter les accès===
Pour limiter l'accès d'un volume aux machines du réseau 10.34.210.0/24 :
# gluster volume set volume1 auth.allow 10.34.210.*
On peut mettre plusieurs ips ou réseaux en les séparant par des virgules.
Pour revenir au comportement par défaut, il faut autoriser "*".
A l'inverse, on peut autoriser tout le monde, sauf des ips, avec le paramètre '''auth.reject'''.
Dans ce cas, pour revenir au comportement par défaut, on va rejeter "NONE".

===Quotas===
On peut activer des quotas pour le volume au niveau des sous-répertoires.
Il faut d'abord activer les quotas :
# gluster volume quota volume1 enable
Puis on défini la valeur :
# gluster volume quota volume1 limit-usage /sous-repertoire 100M
Pour voir l'état des quotas :
# gluster volume quota volume1 list

===Corbeille===
On peut activer une corbeille pour conserver les fichiers supprimés. On peut également limiter la taille aux fichiers de moins de 10Mo.
# gluster volume set volume1 features.trash on
# gluster volume set volume1 features.trash-dir "Poubelle"
# gluster volume set volume1 features.trash-max-falesize 10485760
On peut également activer la corbeille pour les opérations internes comme "rebalance" (par défaut à off) :
# gluster volume set volume1 features.trash-internal-op on

=Administration courante=

==Retirer une brique==

Si on veut retirer une brique.
# gluster peer detach ma_brique

==Remplacement d'une brique (si panne par exemple)==

Nous avons actuellement un trusted pool composé des deux briques brick1 et brick2.

Supposons que brick1 est tombée en panne et n'est pas réparable. On a préparé un nouveau serveur "brick3" et on installé les packages comme expliqué aux chapitres 3.1 et 3.2. Il faut aussi avoir préparé une arborescence /Gluster/Volumes/Volume1 ou équivalente pour accueillir le volume.

Connectons-nous sur brick2 et ajoutons brick3 au trusted-pool :
# gluster peer probe brick3

Maintenant on remplace brick1 par brick3 dans la config du volume "volume1" :
# gluster volume replace-brick volume1 brick1:/Gluster/Volumes/Volume1 brick3:/Gluster/Volumes/Volume1 commit force

On réconcilie le volume :
# gluster volume heal volume1 full

Depuis la nouvelle brique brick3, on synchronise le volume en récupérant les infos de brick2 :
root@brick3 # gluster volume sync brick2 volume1

Il faut ensuite récupérer le volume id depuis les attributs étendus du serveur brick2, pour ensuite les recopier sur brick3.

Récupération volume id :
root@brick2 # getfattr -n trusted.glusterfs.volume-id /gluster/volumes/volume1/
fichier-depuis-client.rien .glusterfs/
[root@centos8-fred ~]# getfattr -n trusted.glusterfs.volume-id /gluster/volumes/volume1/
getfattr: Removing leading '/' from absolute path names
# file: gluster/volumes/volume1/
trusted.glusterfs.volume-id=0s2M71q2FpQoi19v6sUcnyqw==

Recopie volume id sur brick3 :
root@brick3 # setfattr -n trusted.glusterfs.volume-id -v '0s2M71q2FpQoi19v6sUcnyqw==' /Gluster/Volumes/Volume1/

Il ne reste plus qu'à retirer brick1 du trusted pool :
# gluster peer detach brick1

==Étendre un volume==

Actuellement, notre volume1 est sur un volume répliqué sur un cluster à 2 briques. On peut le voir avec la commande suivante :
# gluster volume info volume1 |egrep "Type|Number"
Type: Replicate
Number of Bricks: 1 x 2 = 2

Pour l'étendre, on peut agrandir les volumes sur chaque brique, si c'est possible. Sinon, on peut aussi ajouter des briques. C'est ce qu'on va faire ici. A noter qu'il faut ajouter un nombre de briques proportionnel au nombre de replicas, donc ici 2. Ou alors il faut modifier le nombre de replicas, c’est ce qu’on va voir au chapitre suivant « ajouter un replica ».

On va donc créer deux nouveaux serveurs brick3 et brick4, y installer les packages nécessaires et démarrer les services (voir chapitres 3.1 et 3.2).

On les ajoute au trusted pool depuis une des briques existantes :
brick1# gluster peer probe brick3
brick1# gluster peer probe brick4

Sur brick3 et brick4 on créé un point de montage /gluster/volumes/ avec un sous-répertoire volume1, comme présenté au chapitre 3.4.

Pour finir, on va ajouter les volumes des nouvelles briques à volume1 :
brick1# gluster volume add-brick volume1 brick3:/gluster/volumes/volume1 brick4:/gluster/volumes/volume1

On voit qu'on a maintenant un volume distribué-répliqué à 4 briques :
# gluster volume info volume1 |egrep "Type|Number"
Type: Distributed-Replicate
Number of Bricks: 2 x 2 = 4

Côté client, l'espace disque a doublé (si les volumes sont tous de taille identique).

Par contre, si on a étendu le volume parce que les montages étaient pleins sur brick1 et 2, alors c'est toujours le cas. Car l'ajout de briques ne réparti pas automatiquement les données sur l'ensemble des briques. On va donc le forcer avec la commande :
# gluster volume rebalance volume1 start

Et on peut voir la progression avec la commande :
# gluster volume rebalance volume1 status

==Ajouter un replica==

Repartons de la situation de départ ou volume1 était réparti uniquement sur 2 briques : brick1 et brick2. On va ajouter une brique brick3. Comme c’est un volume répliqué, ça va ajouter une brique répliquée, on va donc passer le replica à 3. Ça permettra de permettre la perte de 2 serveurs, mais n’augmentera pas la volumétrie. La syntaxe est la suivante.
# gluster volume add-brick volume1 replica 3 ubuntu-fred:/gluster/volumes/volume1

On vérifie que ça a fonctionné :
# gluster volume info volume1 |grep "Number of Bricks"
Number of Bricks: 1 x 3 = 3

==Infos détaillées et perfs==

root@debian-fred:~# gluster volume profile volume1 info
Brick: brick1:/Gluster/Volumes/Volume1
-------------------------------------------
Cumulative Stats:
%-latency Avg-latency Min-Latency Max-Latency No. of calls Fop
--------- ----------- ----------- ----------- ------------ ----
0.00 0.00 us 0.00 us 0.00 us 3 RELEASEDIR

Duration: 251 seconds
Data Read: 0 bytes
Data Written: 0 bytes

Interval 1 Stats:

Duration: 32 seconds
Data Read: 0 bytes
Data Written: 0 bytes

Brick: brick2:/gluster/volumes/volume1
--------------------------------------------
Cumulative Stats:
%-latency Avg-latency Min-Latency Max-Latency No. of calls Fop
--------- ----------- ----------- ----------- ------------ ----
0.00 0.00 us 0.00 us 0.00 us 3 RELEASEDIR

Duration: 252 seconds
Data Read: 0 bytes
Data Written: 0 bytes

Interval 1 Stats:

Duration: 32 seconds
Data Read: 0 bytes
Data Written: 0 bytes

=Comparaison avec Ceph=

Une explication détaillée est disponible ici : https://www.ionos.fr/digitalguide/serveur/know-how/glusterfs-vs-ceph/

GlusterFS

2021-12-13T16:03:08Z

AdminWiki : /* Présentation */

[[Category:linux]]

=Présentation=

GlusterFS est un système de fichiers distribué, accessible par le réseau, en mode clients/serveurs.

On doit utiliser des systèmes de fichiers avec attributs étendus, comme XFS, ext4, ext3, ext2, ZFS, ReiserFS, btrfs et beaucoup d’autres. XFS est recommandé (https://docs.gluster.org/en/v3/Install-Guide/Common_criteria/).

Chaque serveur s’appelle un nœud ou brique. En réalité, une brique est le filesystem dédié à GlusterFS sur un nœud. Mais par abus de langage, dans la plupart des docs qu’on trouve, les nœuds sont appelés briques.

Minimum 2 briques. En réalité on peut en n’avoir qu’une, mais ça n’a aucun intérêt, autant faire un serveur NFS dans ce cas.

Il n'y a pas de notion maître/esclave.

Chaque fois qu'on ajoute une brique, le système devient plus performant.

Plusieurs types de volumes :
* volume distribué : comme du raid0, on perd une brique, on perd tout ! Mais volume total = somme des volumes :
{|class="wikitable alternance centre"
|-
| [[File:GlusterFS_volume_distribue.jpg|frameless]]
|-
| Volume distribué
|}

[[Fichier:GlusterFS_volume_distribue2.jpg|500px]]

* volume répliqué : autant de briques que de répliquas désirés. Avec 2 briques, revient à du raid1 = miroring :
[[Fichier:GlusterFS_volume_replique.jpg|500px]]

* volume distribué répliqué :
[[Fichier:GlusterFS_volume_distribue_replique.jpg|500px]]

=Mise en place=

Gluster stocke ses fichiers de conf dynamiquement dans '''/var/lib/glusterd'''. Si jamais le filesystem se rempli, ça pourrait rendre le service instable, voire le planter complètement. Il est donc conseillé de le séparer de /var/log, voire de le mettre tout seul.

==Installation des packages==

Exemple sur Debian10 :
# apt install glusterfs-server -y
# systemctl enable --now glusterd

Exemple sur CentOS 8 :
# dnf install centos-release-gluster -y
# dnf install -y glusterfs-server
# systemctl enable --now glusterd glusterfsd

==Ouverture des flux==

Sur CentOS 8, ou une autre distribution avec firewalld actif, il faut ouvrir le service glusterfs :
# firewall-cmd --zone=public --add-service=glusterfs
# firewall-cmd --zone=public --add-service=glusterfs --permanent

Ce service inclus les ports suivants : 24007/tcp, 24008/tcp, 24009/tcp, 38465/tcp, 38466/tcp, 38467/tcp, 38468/tcp, 38469/tcp et la plage 49152-49664/tcp.

A noter que cette liste me paraît très large. Sur le site de glusterfs, pour la 3.7.0 beta 1, ils ne parlent que de 24007/tcp, 24008/tcp et 49152 à 49156/tcp ([[https://docs.gluster.org/en/release-3.7.0beta1/Administrator%20Guide/Setting%20Up%20Clients/]]).

==Trusted pool==

Supposons que nous avons deux briques : brick1 et brick2.

Une fois que les briques sont installées, il faut les associer. Les briques se reconnaissent au sein de ce qu'on appelle un trusted pool.

Pour cela, aller sur une des briques, par exemple brick1, et taper :
brick1# gluster peer probe brick2
peer probe : success.

Pour vérifier :
# gluster peer status
Number of Peers: 1

Hostname: brick2
Uuid: 2b5f991b-8a43-43fc-836b-f6292157489a
State: Peer in Cluster (Connected)

Pour afficher la liste de briques :
# gluster pool list
UUID Hostname State
2b5f991b-8a43-43fc-836b-f6292157489a brick2 Connected
9189775d-c84f-48a8-93bc-85e3a10af75d localhost Connected

Si on veut supprimer une brique du pool :
# gluster peer detach brick2

==Création d'un volume répliqué==

Sur brick1, on a créé un point de montage /Gluster/Volumes en XFS.
Sur brick2, on a créé un point de montage /gluster/volumes en ext4.

On ne peut pas créer de volume directement sur un point de montage, donc on va créer des sous-répertoires.

Sur brick1, on créé /Gluster/Volumes/Volume1.
Sur brick2, on créé /gluster/volumes/volume1.

J'ai fait exprès de mettre des majuscules d'un côté et des minuscules de l'autre, pour montrer que ça n'a aucune importance d'avoir des noms et arborescences différentes sur les briques.

On va créer un volume miroir nommé "volume1", avec 2 replicas, en utilisant le transport tcp :
# gluster volume create volume1 replica 2 transport tcp brick1:/Gluster/Volumes/Volume1 brick2:/gluster/volumes/volume1
Replica 2 volumes are prone to split-brain. Use Arbiter or Replica 3 to avoid this. See:
http://docs.gluster.org/en/latest/Administrator%20Guide/Split%20brain%20and%20ways%20to%20deal%20with%20it/.
Do you still want to continue?
(y/n) y
volume create: volume1: success: please start the volume to access data

On voit l'avertissement disant qu'il est préférable d'avoir au moins 3 briques. Malgré tout, on créé le volume.
Pour voir :
# gluster volume list
volume1
root@emmabuntus:~# gluster volume status
Volume volume1 is not started

On voit que le volume est créé, mais pas démarré.
Pour le démarrer et vérifier :
# gluster volume start volume1
volume start: volume1: success

# gluster volume list
volume1

# gluster volume status
Status of volume: volume1
Gluster process TCP Port RDMA Port Online Pid
------------------------------------------------------------------------------
Brick brick1:/Gluster/Volumes/Volume1 49152 0 Y 1737
Brick brick2:/gluster/volumes/volume1 49152 0 Y 1925
Self-heal Daemon on localhost N/A N/A Y 1948
Self-heal Daemon on brick1 N/A N/A Y 1760

Task Status of Volume volume1
------------------------------------------------------------------------------
There are no active volume tasks

==Montage depuis un client==

Installer le package "glusterfs-client".
Monter en précisant une des briques et en indiquant le point de montage :
# mount -t glusterfs brick1:/volume1 /mnt
Ou depuis /etc/fstab :
brick1:/volume1 /mnt glusterfs defaults 0 0
A noter qu'au lieu d'utiliser le client natif gluster comme on vient de le faire, on peut aussi utiliser NFS ou CIFS/samba. Mais dans ce cas il est préférable de mettre les nœuds en cluster de type CTDB (cluster NFS) pour avoir de la haute disponibilité. C'est donc beaucoup plus contraignant.
Lors du montage, on doit indiquer le nom d'une des briques (ici brick1). Mais le client récupère ensuite la liste de toutes les briques et peut communiquer avec n'importe laquelle.

==Paramétrage du volume==

===Timeout===
Par défaut, le timeout pour qu'un client bascule d'une brique à l'autre, en cas d'indisponibilité, est de 42 secondes. Ça peut paraître très long. Voici comment le passer à 5 secondes.
# gluster volume set volume1 network.ping-timeout 5

===Limiter les accès===
Pour limiter l'accès d'un volume aux machines du réseau 10.34.210.0/24 :
# gluster volume set volume1 auth.allow 10.34.210.*
On peut mettre plusieurs ips ou réseaux en les séparant par des virgules.
Pour revenir au comportement par défaut, il faut autoriser "*".
A l'inverse, on peut autoriser tout le monde, sauf des ips, avec le paramètre '''auth.reject'''.
Dans ce cas, pour revenir au comportement par défaut, on va rejeter "NONE".

===Quotas===
On peut activer des quotas pour le volume au niveau des sous-répertoires.
Il faut d'abord activer les quotas :
# gluster volume quota volume1 enable
Puis on défini la valeur :
# gluster volume quota volume1 limit-usage /sous-repertoire 100M
Pour voir l'état des quotas :
# gluster volume quota volume1 list

===Corbeille===
On peut activer une corbeille pour conserver les fichiers supprimés. On peut également limiter la taille aux fichiers de moins de 10Mo.
# gluster volume set volume1 features.trash on
# gluster volume set volume1 features.trash-dir "Poubelle"
# gluster volume set volume1 features.trash-max-falesize 10485760
On peut également activer la corbeille pour les opérations internes comme "rebalance" (par défaut à off) :
# gluster volume set volume1 features.trash-internal-op on

=Administration courante=

==Retirer une brique==

Si on veut retirer une brique.
# gluster peer detach ma_brique

==Remplacement d'une brique (si panne par exemple)==

Nous avons actuellement un trusted pool composé des deux briques brick1 et brick2.

Supposons que brick1 est tombée en panne et n'est pas réparable. On a préparé un nouveau serveur "brick3" et on installé les packages comme expliqué aux chapitres 3.1 et 3.2. Il faut aussi avoir préparé une arborescence /Gluster/Volumes/Volume1 ou équivalente pour accueillir le volume.

Connectons-nous sur brick2 et ajoutons brick3 au trusted-pool :
# gluster peer probe brick3

Maintenant on remplace brick1 par brick3 dans la config du volume "volume1" :
# gluster volume replace-brick volume1 brick1:/Gluster/Volumes/Volume1 brick3:/Gluster/Volumes/Volume1 commit force

On réconcilie le volume :
# gluster volume heal volume1 full

Depuis la nouvelle brique brick3, on synchronise le volume en récupérant les infos de brick2 :
root@brick3 # gluster volume sync brick2 volume1

Il faut ensuite récupérer le volume id depuis les attributs étendus du serveur brick2, pour ensuite les recopier sur brick3.

Récupération volume id :
root@brick2 # getfattr -n trusted.glusterfs.volume-id /gluster/volumes/volume1/
fichier-depuis-client.rien .glusterfs/
[root@centos8-fred ~]# getfattr -n trusted.glusterfs.volume-id /gluster/volumes/volume1/
getfattr: Removing leading '/' from absolute path names
# file: gluster/volumes/volume1/
trusted.glusterfs.volume-id=0s2M71q2FpQoi19v6sUcnyqw==

Recopie volume id sur brick3 :
root@brick3 # setfattr -n trusted.glusterfs.volume-id -v '0s2M71q2FpQoi19v6sUcnyqw==' /Gluster/Volumes/Volume1/

Il ne reste plus qu'à retirer brick1 du trusted pool :
# gluster peer detach brick1

==Étendre un volume==

Actuellement, notre volume1 est sur un volume répliqué sur un cluster à 2 briques. On peut le voir avec la commande suivante :
# gluster volume info volume1 |egrep "Type|Number"
Type: Replicate
Number of Bricks: 1 x 2 = 2

Pour l'étendre, on peut agrandir les volumes sur chaque brique, si c'est possible. Sinon, on peut aussi ajouter des briques. C'est ce qu'on va faire ici. A noter qu'il faut ajouter un nombre de briques proportionnel au nombre de replicas, donc ici 2. Ou alors il faut modifier le nombre de replicas, c’est ce qu’on va voir au chapitre suivant « ajouter un replica ».

On va donc créer deux nouveaux serveurs brick3 et brick4, y installer les packages nécessaires et démarrer les services (voir chapitres 3.1 et 3.2).

On les ajoute au trusted pool depuis une des briques existantes :
brick1# gluster peer probe brick3
brick1# gluster peer probe brick4

Sur brick3 et brick4 on créé un point de montage /gluster/volumes/ avec un sous-répertoire volume1, comme présenté au chapitre 3.4.

Pour finir, on va ajouter les volumes des nouvelles briques à volume1 :
brick1# gluster volume add-brick volume1 brick3:/gluster/volumes/volume1 brick4:/gluster/volumes/volume1

On voit qu'on a maintenant un volume distribué-répliqué à 4 briques :
# gluster volume info volume1 |egrep "Type|Number"
Type: Distributed-Replicate
Number of Bricks: 2 x 2 = 4

Côté client, l'espace disque a doublé (si les volumes sont tous de taille identique).

Par contre, si on a étendu le volume parce que les montages étaient pleins sur brick1 et 2, alors c'est toujours le cas. Car l'ajout de briques ne réparti pas automatiquement les données sur l'ensemble des briques. On va donc le forcer avec la commande :
# gluster volume rebalance volume1 start

Et on peut voir la progression avec la commande :
# gluster volume rebalance volume1 status

==Ajouter un replica==

Repartons de la situation de départ ou volume1 était réparti uniquement sur 2 briques : brick1 et brick2. On va ajouter une brique brick3. Comme c’est un volume répliqué, ça va ajouter une brique répliquée, on va donc passer le replica à 3. Ça permettra de permettre la perte de 2 serveurs, mais n’augmentera pas la volumétrie. La syntaxe est la suivante.
# gluster volume add-brick volume1 replica 3 ubuntu-fred:/gluster/volumes/volume1

On vérifie que ça a fonctionné :
# gluster volume info volume1 |grep "Number of Bricks"
Number of Bricks: 1 x 3 = 3

==Infos détaillées et perfs==

root@debian-fred:~# gluster volume profile volume1 info
Brick: brick1:/Gluster/Volumes/Volume1
-------------------------------------------
Cumulative Stats:
%-latency Avg-latency Min-Latency Max-Latency No. of calls Fop
--------- ----------- ----------- ----------- ------------ ----
0.00 0.00 us 0.00 us 0.00 us 3 RELEASEDIR

Duration: 251 seconds
Data Read: 0 bytes
Data Written: 0 bytes

Interval 1 Stats:

Duration: 32 seconds
Data Read: 0 bytes
Data Written: 0 bytes

Brick: brick2:/gluster/volumes/volume1
--------------------------------------------
Cumulative Stats:
%-latency Avg-latency Min-Latency Max-Latency No. of calls Fop
--------- ----------- ----------- ----------- ------------ ----
0.00 0.00 us 0.00 us 0.00 us 3 RELEASEDIR

Duration: 252 seconds
Data Read: 0 bytes
Data Written: 0 bytes

Interval 1 Stats:

Duration: 32 seconds
Data Read: 0 bytes
Data Written: 0 bytes

=Comparaison avec Ceph=

Une explication détaillée est disponible ici : https://www.ionos.fr/digitalguide/serveur/know-how/glusterfs-vs-ceph/

Fichier:GlusterFS volume distribue.jpg

2021-12-13T11:23:26Z

AdminWiki :

GlusterFS

2021-12-13T11:22:30Z

AdminWiki : /* Présentation */

[[Category:linux]]

=Présentation=

GlusterFS est un système de fichiers distribué, accessible par le réseau, en mode clients/serveurs.

On doit utiliser des systèmes de fichiers avec attributs étendus, comme XFS, ext4, ext3, ext2, ZFS, ReiserFS, btrfs et beaucoup d’autres. XFS est recommandé (https://docs.gluster.org/en/v3/Install-Guide/Common_criteria/).

Chaque serveur s’appelle un nœud ou brique. En réalité, une brique est le filesystem dédié à GlusterFS sur un nœud. Mais par abus de langage, dans la plupart des docs qu’on trouve, les nœuds sont appelés briques.

Minimum 2 briques. En réalité on peut en n’avoir qu’une, mais ça n’a aucun intérêt, autant faire un serveur NFS dans ce cas.

Il n'y a pas de notion maître/esclave.

Chaque fois qu'on ajoute une brique, le système devient plus performant.

Plusieurs types de volumes :
* volume distribué : comme du raid0, on perd une brique, on perd tout ! Mais volume total = somme des volumes :
{|class="wikitable alternance centre"
|-
| [[File:GlusterFS_volume_distribue.jpg|frameless]]
|-
| Volume distribué
|}

[[Fichier:GlusterFS_volume_distribue.jpg|500px]]

* volume répliqué : autant de briques que de répliquas désirés. Avec 2 briques, revient à du raid1 = miroring :
[[Fichier:GlusterFS_volume_replique.jpg|500px]]

* volume distribué répliqué :
[[Fichier:GlusterFS_volume_distribue_replique.jpg|500px]]

=Mise en place=

Gluster stocke ses fichiers de conf dynamiquement dans '''/var/lib/glusterd'''. Si jamais le filesystem se rempli, ça pourrait rendre le service instable, voire le planter complètement. Il est donc conseillé de le séparer de /var/log, voire de le mettre tout seul.

==Installation des packages==

Exemple sur Debian10 :
# apt install glusterfs-server -y
# systemctl enable --now glusterd

Exemple sur CentOS 8 :
# dnf install centos-release-gluster -y
# dnf install -y glusterfs-server
# systemctl enable --now glusterd glusterfsd

==Ouverture des flux==

Sur CentOS 8, ou une autre distribution avec firewalld actif, il faut ouvrir le service glusterfs :
# firewall-cmd --zone=public --add-service=glusterfs
# firewall-cmd --zone=public --add-service=glusterfs --permanent

Ce service inclus les ports suivants : 24007/tcp, 24008/tcp, 24009/tcp, 38465/tcp, 38466/tcp, 38467/tcp, 38468/tcp, 38469/tcp et la plage 49152-49664/tcp.

A noter que cette liste me paraît très large. Sur le site de glusterfs, pour la 3.7.0 beta 1, ils ne parlent que de 24007/tcp, 24008/tcp et 49152 à 49156/tcp ([[https://docs.gluster.org/en/release-3.7.0beta1/Administrator%20Guide/Setting%20Up%20Clients/]]).

==Trusted pool==

Supposons que nous avons deux briques : brick1 et brick2.

Une fois que les briques sont installées, il faut les associer. Les briques se reconnaissent au sein de ce qu'on appelle un trusted pool.

Pour cela, aller sur une des briques, par exemple brick1, et taper :
brick1# gluster peer probe brick2
peer probe : success.

Pour vérifier :
# gluster peer status
Number of Peers: 1

Hostname: brick2
Uuid: 2b5f991b-8a43-43fc-836b-f6292157489a
State: Peer in Cluster (Connected)

Pour afficher la liste de briques :
# gluster pool list
UUID Hostname State
2b5f991b-8a43-43fc-836b-f6292157489a brick2 Connected
9189775d-c84f-48a8-93bc-85e3a10af75d localhost Connected

Si on veut supprimer une brique du pool :
# gluster peer detach brick2

==Création d'un volume répliqué==

Sur brick1, on a créé un point de montage /Gluster/Volumes en XFS.
Sur brick2, on a créé un point de montage /gluster/volumes en ext4.

On ne peut pas créer de volume directement sur un point de montage, donc on va créer des sous-répertoires.

Sur brick1, on créé /Gluster/Volumes/Volume1.
Sur brick2, on créé /gluster/volumes/volume1.

J'ai fait exprès de mettre des majuscules d'un côté et des minuscules de l'autre, pour montrer que ça n'a aucune importance d'avoir des noms et arborescences différentes sur les briques.

On va créer un volume miroir nommé "volume1", avec 2 replicas, en utilisant le transport tcp :
# gluster volume create volume1 replica 2 transport tcp brick1:/Gluster/Volumes/Volume1 brick2:/gluster/volumes/volume1
Replica 2 volumes are prone to split-brain. Use Arbiter or Replica 3 to avoid this. See:
http://docs.gluster.org/en/latest/Administrator%20Guide/Split%20brain%20and%20ways%20to%20deal%20with%20it/.
Do you still want to continue?
(y/n) y
volume create: volume1: success: please start the volume to access data

On voit l'avertissement disant qu'il est préférable d'avoir au moins 3 briques. Malgré tout, on créé le volume.
Pour voir :
# gluster volume list
volume1
root@emmabuntus:~# gluster volume status
Volume volume1 is not started

On voit que le volume est créé, mais pas démarré.
Pour le démarrer et vérifier :
# gluster volume start volume1
volume start: volume1: success

# gluster volume list
volume1

# gluster volume status
Status of volume: volume1
Gluster process TCP Port RDMA Port Online Pid
------------------------------------------------------------------------------
Brick brick1:/Gluster/Volumes/Volume1 49152 0 Y 1737
Brick brick2:/gluster/volumes/volume1 49152 0 Y 1925
Self-heal Daemon on localhost N/A N/A Y 1948
Self-heal Daemon on brick1 N/A N/A Y 1760

Task Status of Volume volume1
------------------------------------------------------------------------------
There are no active volume tasks

==Montage depuis un client==

Installer le package "glusterfs-client".
Monter en précisant une des briques et en indiquant le point de montage :
# mount -t glusterfs brick1:/volume1 /mnt
Ou depuis /etc/fstab :
brick1:/volume1 /mnt glusterfs defaults 0 0
A noter qu'au lieu d'utiliser le client natif gluster comme on vient de le faire, on peut aussi utiliser NFS ou CIFS/samba. Mais dans ce cas il est préférable de mettre les nœuds en cluster de type CTDB (cluster NFS) pour avoir de la haute disponibilité. C'est donc beaucoup plus contraignant.
Lors du montage, on doit indiquer le nom d'une des briques (ici brick1). Mais le client récupère ensuite la liste de toutes les briques et peut communiquer avec n'importe laquelle.

==Paramétrage du volume==

===Timeout===
Par défaut, le timeout pour qu'un client bascule d'une brique à l'autre, en cas d'indisponibilité, est de 42 secondes. Ça peut paraître très long. Voici comment le passer à 5 secondes.
# gluster volume set volume1 network.ping-timeout 5

===Limiter les accès===
Pour limiter l'accès d'un volume aux machines du réseau 10.34.210.0/24 :
# gluster volume set volume1 auth.allow 10.34.210.*
On peut mettre plusieurs ips ou réseaux en les séparant par des virgules.
Pour revenir au comportement par défaut, il faut autoriser "*".
A l'inverse, on peut autoriser tout le monde, sauf des ips, avec le paramètre '''auth.reject'''.
Dans ce cas, pour revenir au comportement par défaut, on va rejeter "NONE".

===Quotas===
On peut activer des quotas pour le volume au niveau des sous-répertoires.
Il faut d'abord activer les quotas :
# gluster volume quota volume1 enable
Puis on défini la valeur :
# gluster volume quota volume1 limit-usage /sous-repertoire 100M
Pour voir l'état des quotas :
# gluster volume quota volume1 list

===Corbeille===
On peut activer une corbeille pour conserver les fichiers supprimés. On peut également limiter la taille aux fichiers de moins de 10Mo.
# gluster volume set volume1 features.trash on
# gluster volume set volume1 features.trash-dir "Poubelle"
# gluster volume set volume1 features.trash-max-falesize 10485760
On peut également activer la corbeille pour les opérations internes comme "rebalance" (par défaut à off) :
# gluster volume set volume1 features.trash-internal-op on

=Administration courante=

==Retirer une brique==

Si on veut retirer une brique.
# gluster peer detach ma_brique

==Remplacement d'une brique (si panne par exemple)==

Nous avons actuellement un trusted pool composé des deux briques brick1 et brick2.

Supposons que brick1 est tombée en panne et n'est pas réparable. On a préparé un nouveau serveur "brick3" et on installé les packages comme expliqué aux chapitres 3.1 et 3.2. Il faut aussi avoir préparé une arborescence /Gluster/Volumes/Volume1 ou équivalente pour accueillir le volume.

Connectons-nous sur brick2 et ajoutons brick3 au trusted-pool :
# gluster peer probe brick3

Maintenant on remplace brick1 par brick3 dans la config du volume "volume1" :
# gluster volume replace-brick volume1 brick1:/Gluster/Volumes/Volume1 brick3:/Gluster/Volumes/Volume1 commit force

On réconcilie le volume :
# gluster volume heal volume1 full

Depuis la nouvelle brique brick3, on synchronise le volume en récupérant les infos de brick2 :
root@brick3 # gluster volume sync brick2 volume1

Il faut ensuite récupérer le volume id depuis les attributs étendus du serveur brick2, pour ensuite les recopier sur brick3.

Récupération volume id :
root@brick2 # getfattr -n trusted.glusterfs.volume-id /gluster/volumes/volume1/
fichier-depuis-client.rien .glusterfs/
[root@centos8-fred ~]# getfattr -n trusted.glusterfs.volume-id /gluster/volumes/volume1/
getfattr: Removing leading '/' from absolute path names
# file: gluster/volumes/volume1/
trusted.glusterfs.volume-id=0s2M71q2FpQoi19v6sUcnyqw==

Recopie volume id sur brick3 :
root@brick3 # setfattr -n trusted.glusterfs.volume-id -v '0s2M71q2FpQoi19v6sUcnyqw==' /Gluster/Volumes/Volume1/

Il ne reste plus qu'à retirer brick1 du trusted pool :
# gluster peer detach brick1

==Étendre un volume==

Actuellement, notre volume1 est sur un volume répliqué sur un cluster à 2 briques. On peut le voir avec la commande suivante :
# gluster volume info volume1 |egrep "Type|Number"
Type: Replicate
Number of Bricks: 1 x 2 = 2

Pour l'étendre, on peut agrandir les volumes sur chaque brique, si c'est possible. Sinon, on peut aussi ajouter des briques. C'est ce qu'on va faire ici. A noter qu'il faut ajouter un nombre de briques proportionnel au nombre de replicas, donc ici 2. Ou alors il faut modifier le nombre de replicas, c’est ce qu’on va voir au chapitre suivant « ajouter un replica ».

On va donc créer deux nouveaux serveurs brick3 et brick4, y installer les packages nécessaires et démarrer les services (voir chapitres 3.1 et 3.2).

On les ajoute au trusted pool depuis une des briques existantes :
brick1# gluster peer probe brick3
brick1# gluster peer probe brick4

Sur brick3 et brick4 on créé un point de montage /gluster/volumes/ avec un sous-répertoire volume1, comme présenté au chapitre 3.4.

Pour finir, on va ajouter les volumes des nouvelles briques à volume1 :
brick1# gluster volume add-brick volume1 brick3:/gluster/volumes/volume1 brick4:/gluster/volumes/volume1

On voit qu'on a maintenant un volume distribué-répliqué à 4 briques :
# gluster volume info volume1 |egrep "Type|Number"
Type: Distributed-Replicate
Number of Bricks: 2 x 2 = 4

Côté client, l'espace disque a doublé (si les volumes sont tous de taille identique).

Par contre, si on a étendu le volume parce que les montages étaient pleins sur brick1 et 2, alors c'est toujours le cas. Car l'ajout de briques ne réparti pas automatiquement les données sur l'ensemble des briques. On va donc le forcer avec la commande :
# gluster volume rebalance volume1 start

Et on peut voir la progression avec la commande :
# gluster volume rebalance volume1 status

==Ajouter un replica==

Repartons de la situation de départ ou volume1 était réparti uniquement sur 2 briques : brick1 et brick2. On va ajouter une brique brick3. Comme c’est un volume répliqué, ça va ajouter une brique répliquée, on va donc passer le replica à 3. Ça permettra de permettre la perte de 2 serveurs, mais n’augmentera pas la volumétrie. La syntaxe est la suivante.
# gluster volume add-brick volume1 replica 3 ubuntu-fred:/gluster/volumes/volume1

On vérifie que ça a fonctionné :
# gluster volume info volume1 |grep "Number of Bricks"
Number of Bricks: 1 x 3 = 3

==Infos détaillées et perfs==

root@debian-fred:~# gluster volume profile volume1 info
Brick: brick1:/Gluster/Volumes/Volume1
-------------------------------------------
Cumulative Stats:
%-latency Avg-latency Min-Latency Max-Latency No. of calls Fop
--------- ----------- ----------- ----------- ------------ ----
0.00 0.00 us 0.00 us 0.00 us 3 RELEASEDIR

Duration: 251 seconds
Data Read: 0 bytes
Data Written: 0 bytes

Interval 1 Stats:

Duration: 32 seconds
Data Read: 0 bytes
Data Written: 0 bytes

Brick: brick2:/gluster/volumes/volume1
--------------------------------------------
Cumulative Stats:
%-latency Avg-latency Min-Latency Max-Latency No. of calls Fop
--------- ----------- ----------- ----------- ------------ ----
0.00 0.00 us 0.00 us 0.00 us 3 RELEASEDIR

Duration: 252 seconds
Data Read: 0 bytes
Data Written: 0 bytes

Interval 1 Stats:

Duration: 32 seconds
Data Read: 0 bytes
Data Written: 0 bytes

=Comparaison avec Ceph=

Une explication détaillée est disponible ici : https://www.ionos.fr/digitalguide/serveur/know-how/glusterfs-vs-ceph/

GlusterFS

2021-12-13T11:03:14Z

AdminWiki : /* Présentation */

[[Category:linux]]

=Présentation=

GlusterFS est un système de fichiers distribué, accessible par le réseau, en mode clients/serveurs.

On doit utiliser des systèmes de fichiers avec attributs étendus, comme XFS, ext4, ext3, ext2, ZFS, ReiserFS, btrfs et beaucoup d’autres. XFS est recommandé (https://docs.gluster.org/en/v3/Install-Guide/Common_criteria/).

Chaque serveur s’appelle un nœud ou brique. En réalité, une brique est le filesystem dédié à GlusterFS sur un nœud. Mais par abus de langage, dans la plupart des docs qu’on trouve, les nœuds sont appelés briques.

Minimum 2 briques. En réalité on peut en n’avoir qu’une, mais ça n’a aucun intérêt, autant faire un serveur NFS dans ce cas.

Il n'y a pas de notion maître/esclave.

Chaque fois qu'on ajoute une brique, le système devient plus performant.

Plusieurs types de volumes :
* volume distribué : comme du raid0, on perd une brique, on perd tout ! Mais volume total = somme des volumes :
{|class="wikitable alternance centre"
|-
| [[File:GlusterFS_volume_distribue.jpg|frameless]]
|-
| Volume distribué
|}

* volume répliqué : autant de briques que de répliquas désirés. Avec 2 briques, revient à du raid1 = miroring :
[[Fichier:GlusterFS_volume_replique.jpg|500px]]

* volume distribué répliqué :
[[Fichier:GlusterFS_volume_distribue_replique.jpg|500px]]

=Mise en place=

Gluster stocke ses fichiers de conf dynamiquement dans '''/var/lib/glusterd'''. Si jamais le filesystem se rempli, ça pourrait rendre le service instable, voire le planter complètement. Il est donc conseillé de le séparer de /var/log, voire de le mettre tout seul.

==Installation des packages==

Exemple sur Debian10 :
# apt install glusterfs-server -y
# systemctl enable --now glusterd

Exemple sur CentOS 8 :
# dnf install centos-release-gluster -y
# dnf install -y glusterfs-server
# systemctl enable --now glusterd glusterfsd

==Ouverture des flux==

Sur CentOS 8, ou une autre distribution avec firewalld actif, il faut ouvrir le service glusterfs :
# firewall-cmd --zone=public --add-service=glusterfs
# firewall-cmd --zone=public --add-service=glusterfs --permanent

Ce service inclus les ports suivants : 24007/tcp, 24008/tcp, 24009/tcp, 38465/tcp, 38466/tcp, 38467/tcp, 38468/tcp, 38469/tcp et la plage 49152-49664/tcp.

A noter que cette liste me paraît très large. Sur le site de glusterfs, pour la 3.7.0 beta 1, ils ne parlent que de 24007/tcp, 24008/tcp et 49152 à 49156/tcp ([[https://docs.gluster.org/en/release-3.7.0beta1/Administrator%20Guide/Setting%20Up%20Clients/]]).

==Trusted pool==

Supposons que nous avons deux briques : brick1 et brick2.

Une fois que les briques sont installées, il faut les associer. Les briques se reconnaissent au sein de ce qu'on appelle un trusted pool.

Pour cela, aller sur une des briques, par exemple brick1, et taper :
brick1# gluster peer probe brick2
peer probe : success.

Pour vérifier :
# gluster peer status
Number of Peers: 1

Hostname: brick2
Uuid: 2b5f991b-8a43-43fc-836b-f6292157489a
State: Peer in Cluster (Connected)

Pour afficher la liste de briques :
# gluster pool list
UUID Hostname State
2b5f991b-8a43-43fc-836b-f6292157489a brick2 Connected
9189775d-c84f-48a8-93bc-85e3a10af75d localhost Connected

Si on veut supprimer une brique du pool :
# gluster peer detach brick2

==Création d'un volume répliqué==

Sur brick1, on a créé un point de montage /Gluster/Volumes en XFS.
Sur brick2, on a créé un point de montage /gluster/volumes en ext4.

On ne peut pas créer de volume directement sur un point de montage, donc on va créer des sous-répertoires.

Sur brick1, on créé /Gluster/Volumes/Volume1.
Sur brick2, on créé /gluster/volumes/volume1.

J'ai fait exprès de mettre des majuscules d'un côté et des minuscules de l'autre, pour montrer que ça n'a aucune importance d'avoir des noms et arborescences différentes sur les briques.

On va créer un volume miroir nommé "volume1", avec 2 replicas, en utilisant le transport tcp :
# gluster volume create volume1 replica 2 transport tcp brick1:/Gluster/Volumes/Volume1 brick2:/gluster/volumes/volume1
Replica 2 volumes are prone to split-brain. Use Arbiter or Replica 3 to avoid this. See:
http://docs.gluster.org/en/latest/Administrator%20Guide/Split%20brain%20and%20ways%20to%20deal%20with%20it/.
Do you still want to continue?
(y/n) y
volume create: volume1: success: please start the volume to access data

On voit l'avertissement disant qu'il est préférable d'avoir au moins 3 briques. Malgré tout, on créé le volume.
Pour voir :
# gluster volume list
volume1
root@emmabuntus:~# gluster volume status
Volume volume1 is not started

On voit que le volume est créé, mais pas démarré.
Pour le démarrer et vérifier :
# gluster volume start volume1
volume start: volume1: success

# gluster volume list
volume1

# gluster volume status
Status of volume: volume1
Gluster process TCP Port RDMA Port Online Pid
------------------------------------------------------------------------------
Brick brick1:/Gluster/Volumes/Volume1 49152 0 Y 1737
Brick brick2:/gluster/volumes/volume1 49152 0 Y 1925
Self-heal Daemon on localhost N/A N/A Y 1948
Self-heal Daemon on brick1 N/A N/A Y 1760

Task Status of Volume volume1
------------------------------------------------------------------------------
There are no active volume tasks

==Montage depuis un client==

Installer le package "glusterfs-client".
Monter en précisant une des briques et en indiquant le point de montage :
# mount -t glusterfs brick1:/volume1 /mnt
Ou depuis /etc/fstab :
brick1:/volume1 /mnt glusterfs defaults 0 0
A noter qu'au lieu d'utiliser le client natif gluster comme on vient de le faire, on peut aussi utiliser NFS ou CIFS/samba. Mais dans ce cas il est préférable de mettre les nœuds en cluster de type CTDB (cluster NFS) pour avoir de la haute disponibilité. C'est donc beaucoup plus contraignant.
Lors du montage, on doit indiquer le nom d'une des briques (ici brick1). Mais le client récupère ensuite la liste de toutes les briques et peut communiquer avec n'importe laquelle.

==Paramétrage du volume==

===Timeout===
Par défaut, le timeout pour qu'un client bascule d'une brique à l'autre, en cas d'indisponibilité, est de 42 secondes. Ça peut paraître très long. Voici comment le passer à 5 secondes.
# gluster volume set volume1 network.ping-timeout 5

===Limiter les accès===
Pour limiter l'accès d'un volume aux machines du réseau 10.34.210.0/24 :
# gluster volume set volume1 auth.allow 10.34.210.*
On peut mettre plusieurs ips ou réseaux en les séparant par des virgules.
Pour revenir au comportement par défaut, il faut autoriser "*".
A l'inverse, on peut autoriser tout le monde, sauf des ips, avec le paramètre '''auth.reject'''.
Dans ce cas, pour revenir au comportement par défaut, on va rejeter "NONE".

===Quotas===
On peut activer des quotas pour le volume au niveau des sous-répertoires.
Il faut d'abord activer les quotas :
# gluster volume quota volume1 enable
Puis on défini la valeur :
# gluster volume quota volume1 limit-usage /sous-repertoire 100M
Pour voir l'état des quotas :
# gluster volume quota volume1 list

===Corbeille===
On peut activer une corbeille pour conserver les fichiers supprimés. On peut également limiter la taille aux fichiers de moins de 10Mo.
# gluster volume set volume1 features.trash on
# gluster volume set volume1 features.trash-dir "Poubelle"
# gluster volume set volume1 features.trash-max-falesize 10485760
On peut également activer la corbeille pour les opérations internes comme "rebalance" (par défaut à off) :
# gluster volume set volume1 features.trash-internal-op on

=Administration courante=

==Retirer une brique==

Si on veut retirer une brique.
# gluster peer detach ma_brique

==Remplacement d'une brique (si panne par exemple)==

Nous avons actuellement un trusted pool composé des deux briques brick1 et brick2.

Supposons que brick1 est tombée en panne et n'est pas réparable. On a préparé un nouveau serveur "brick3" et on installé les packages comme expliqué aux chapitres 3.1 et 3.2. Il faut aussi avoir préparé une arborescence /Gluster/Volumes/Volume1 ou équivalente pour accueillir le volume.

Connectons-nous sur brick2 et ajoutons brick3 au trusted-pool :
# gluster peer probe brick3

Maintenant on remplace brick1 par brick3 dans la config du volume "volume1" :
# gluster volume replace-brick volume1 brick1:/Gluster/Volumes/Volume1 brick3:/Gluster/Volumes/Volume1 commit force

On réconcilie le volume :
# gluster volume heal volume1 full

Depuis la nouvelle brique brick3, on synchronise le volume en récupérant les infos de brick2 :
root@brick3 # gluster volume sync brick2 volume1

Il faut ensuite récupérer le volume id depuis les attributs étendus du serveur brick2, pour ensuite les recopier sur brick3.

Récupération volume id :
root@brick2 # getfattr -n trusted.glusterfs.volume-id /gluster/volumes/volume1/
fichier-depuis-client.rien .glusterfs/
[root@centos8-fred ~]# getfattr -n trusted.glusterfs.volume-id /gluster/volumes/volume1/
getfattr: Removing leading '/' from absolute path names
# file: gluster/volumes/volume1/
trusted.glusterfs.volume-id=0s2M71q2FpQoi19v6sUcnyqw==

Recopie volume id sur brick3 :
root@brick3 # setfattr -n trusted.glusterfs.volume-id -v '0s2M71q2FpQoi19v6sUcnyqw==' /Gluster/Volumes/Volume1/

Il ne reste plus qu'à retirer brick1 du trusted pool :
# gluster peer detach brick1

==Étendre un volume==

Actuellement, notre volume1 est sur un volume répliqué sur un cluster à 2 briques. On peut le voir avec la commande suivante :
# gluster volume info volume1 |egrep "Type|Number"
Type: Replicate
Number of Bricks: 1 x 2 = 2

Pour l'étendre, on peut agrandir les volumes sur chaque brique, si c'est possible. Sinon, on peut aussi ajouter des briques. C'est ce qu'on va faire ici. A noter qu'il faut ajouter un nombre de briques proportionnel au nombre de replicas, donc ici 2. Ou alors il faut modifier le nombre de replicas, c’est ce qu’on va voir au chapitre suivant « ajouter un replica ».

On va donc créer deux nouveaux serveurs brick3 et brick4, y installer les packages nécessaires et démarrer les services (voir chapitres 3.1 et 3.2).

On les ajoute au trusted pool depuis une des briques existantes :
brick1# gluster peer probe brick3
brick1# gluster peer probe brick4

Sur brick3 et brick4 on créé un point de montage /gluster/volumes/ avec un sous-répertoire volume1, comme présenté au chapitre 3.4.

Pour finir, on va ajouter les volumes des nouvelles briques à volume1 :
brick1# gluster volume add-brick volume1 brick3:/gluster/volumes/volume1 brick4:/gluster/volumes/volume1

On voit qu'on a maintenant un volume distribué-répliqué à 4 briques :
# gluster volume info volume1 |egrep "Type|Number"
Type: Distributed-Replicate
Number of Bricks: 2 x 2 = 4

Côté client, l'espace disque a doublé (si les volumes sont tous de taille identique).

Par contre, si on a étendu le volume parce que les montages étaient pleins sur brick1 et 2, alors c'est toujours le cas. Car l'ajout de briques ne réparti pas automatiquement les données sur l'ensemble des briques. On va donc le forcer avec la commande :
# gluster volume rebalance volume1 start

Et on peut voir la progression avec la commande :
# gluster volume rebalance volume1 status

==Ajouter un replica==

Repartons de la situation de départ ou volume1 était réparti uniquement sur 2 briques : brick1 et brick2. On va ajouter une brique brick3. Comme c’est un volume répliqué, ça va ajouter une brique répliquée, on va donc passer le replica à 3. Ça permettra de permettre la perte de 2 serveurs, mais n’augmentera pas la volumétrie. La syntaxe est la suivante.
# gluster volume add-brick volume1 replica 3 ubuntu-fred:/gluster/volumes/volume1

On vérifie que ça a fonctionné :
# gluster volume info volume1 |grep "Number of Bricks"
Number of Bricks: 1 x 3 = 3

==Infos détaillées et perfs==

root@debian-fred:~# gluster volume profile volume1 info
Brick: brick1:/Gluster/Volumes/Volume1
-------------------------------------------
Cumulative Stats:
%-latency Avg-latency Min-Latency Max-Latency No. of calls Fop
--------- ----------- ----------- ----------- ------------ ----
0.00 0.00 us 0.00 us 0.00 us 3 RELEASEDIR

Duration: 251 seconds
Data Read: 0 bytes
Data Written: 0 bytes

Interval 1 Stats:

Duration: 32 seconds
Data Read: 0 bytes
Data Written: 0 bytes

Brick: brick2:/gluster/volumes/volume1
--------------------------------------------
Cumulative Stats:
%-latency Avg-latency Min-Latency Max-Latency No. of calls Fop
--------- ----------- ----------- ----------- ------------ ----
0.00 0.00 us 0.00 us 0.00 us 3 RELEASEDIR

Duration: 252 seconds
Data Read: 0 bytes
Data Written: 0 bytes

Interval 1 Stats:

Duration: 32 seconds
Data Read: 0 bytes
Data Written: 0 bytes

=Comparaison avec Ceph=

Une explication détaillée est disponible ici : https://www.ionos.fr/digitalguide/serveur/know-how/glusterfs-vs-ceph/

GlusterFS

2021-12-13T10:57:59Z

AdminWiki : /* Présentation */

[[Category:linux]]

=Présentation=

GlusterFS est un système de fichiers distribué, accessible par le réseau, en mode clients/serveurs.

On doit utiliser des systèmes de fichiers avec attributs étendus, comme XFS, ext4, ext3, ext2, ZFS, ReiserFS, btrfs et beaucoup d’autres. XFS est recommandé (https://docs.gluster.org/en/v3/Install-Guide/Common_criteria/).

Chaque serveur s’appelle un nœud ou brique. En réalité, une brique est le filesystem dédié à GlusterFS sur un nœud. Mais par abus de langage, dans la plupart des docs qu’on trouve, les nœuds sont appelés briques.

Minimum 2 briques. En réalité on peut en n’avoir qu’une, mais ça n’a aucun intérêt, autant faire un serveur NFS dans ce cas.

Il n'y a pas de notion maître/esclave.

Chaque fois qu'on ajoute une brique, le système devient plus performant.

Plusieurs types de volumes :
* volume distribué : comme du raid0, on perd une brique, on perd tout ! Mais volume total = somme des volumes :
[[Fichier:GlusterFS_volume_distribue.jpg|500px]]
* volume répliqué : autant de briques que de répliquas désirés. Avec 2 briques, revient à du raid1 = miroring :
[[Fichier:GlusterFS_volume_replique.jpg|500px]]
* volume distribué répliqué :
[[Fichier:GlusterFS_volume_distribue_replique.jpg|500px]]

=Mise en place=

Gluster stocke ses fichiers de conf dynamiquement dans '''/var/lib/glusterd'''. Si jamais le filesystem se rempli, ça pourrait rendre le service instable, voire le planter complètement. Il est donc conseillé de le séparer de /var/log, voire de le mettre tout seul.

==Installation des packages==

Exemple sur Debian10 :
# apt install glusterfs-server -y
# systemctl enable --now glusterd

Exemple sur CentOS 8 :
# dnf install centos-release-gluster -y
# dnf install -y glusterfs-server
# systemctl enable --now glusterd glusterfsd

==Ouverture des flux==

Sur CentOS 8, ou une autre distribution avec firewalld actif, il faut ouvrir le service glusterfs :
# firewall-cmd --zone=public --add-service=glusterfs
# firewall-cmd --zone=public --add-service=glusterfs --permanent

Ce service inclus les ports suivants : 24007/tcp, 24008/tcp, 24009/tcp, 38465/tcp, 38466/tcp, 38467/tcp, 38468/tcp, 38469/tcp et la plage 49152-49664/tcp.

A noter que cette liste me paraît très large. Sur le site de glusterfs, pour la 3.7.0 beta 1, ils ne parlent que de 24007/tcp, 24008/tcp et 49152 à 49156/tcp ([[https://docs.gluster.org/en/release-3.7.0beta1/Administrator%20Guide/Setting%20Up%20Clients/]]).

==Trusted pool==

Supposons que nous avons deux briques : brick1 et brick2.

Une fois que les briques sont installées, il faut les associer. Les briques se reconnaissent au sein de ce qu'on appelle un trusted pool.

Pour cela, aller sur une des briques, par exemple brick1, et taper :
brick1# gluster peer probe brick2
peer probe : success.

Pour vérifier :
# gluster peer status
Number of Peers: 1

Hostname: brick2
Uuid: 2b5f991b-8a43-43fc-836b-f6292157489a
State: Peer in Cluster (Connected)

Pour afficher la liste de briques :
# gluster pool list
UUID Hostname State
2b5f991b-8a43-43fc-836b-f6292157489a brick2 Connected
9189775d-c84f-48a8-93bc-85e3a10af75d localhost Connected

Si on veut supprimer une brique du pool :
# gluster peer detach brick2

==Création d'un volume répliqué==

Sur brick1, on a créé un point de montage /Gluster/Volumes en XFS.
Sur brick2, on a créé un point de montage /gluster/volumes en ext4.

On ne peut pas créer de volume directement sur un point de montage, donc on va créer des sous-répertoires.

Sur brick1, on créé /Gluster/Volumes/Volume1.
Sur brick2, on créé /gluster/volumes/volume1.

J'ai fait exprès de mettre des majuscules d'un côté et des minuscules de l'autre, pour montrer que ça n'a aucune importance d'avoir des noms et arborescences différentes sur les briques.

On va créer un volume miroir nommé "volume1", avec 2 replicas, en utilisant le transport tcp :
# gluster volume create volume1 replica 2 transport tcp brick1:/Gluster/Volumes/Volume1 brick2:/gluster/volumes/volume1
Replica 2 volumes are prone to split-brain. Use Arbiter or Replica 3 to avoid this. See:
http://docs.gluster.org/en/latest/Administrator%20Guide/Split%20brain%20and%20ways%20to%20deal%20with%20it/.
Do you still want to continue?
(y/n) y
volume create: volume1: success: please start the volume to access data

On voit l'avertissement disant qu'il est préférable d'avoir au moins 3 briques. Malgré tout, on créé le volume.
Pour voir :
# gluster volume list
volume1
root@emmabuntus:~# gluster volume status
Volume volume1 is not started

On voit que le volume est créé, mais pas démarré.
Pour le démarrer et vérifier :
# gluster volume start volume1
volume start: volume1: success

# gluster volume list
volume1

# gluster volume status
Status of volume: volume1
Gluster process TCP Port RDMA Port Online Pid
------------------------------------------------------------------------------
Brick brick1:/Gluster/Volumes/Volume1 49152 0 Y 1737
Brick brick2:/gluster/volumes/volume1 49152 0 Y 1925
Self-heal Daemon on localhost N/A N/A Y 1948
Self-heal Daemon on brick1 N/A N/A Y 1760

Task Status of Volume volume1
------------------------------------------------------------------------------
There are no active volume tasks

==Montage depuis un client==

Installer le package "glusterfs-client".
Monter en précisant une des briques et en indiquant le point de montage :
# mount -t glusterfs brick1:/volume1 /mnt
Ou depuis /etc/fstab :
brick1:/volume1 /mnt glusterfs defaults 0 0
A noter qu'au lieu d'utiliser le client natif gluster comme on vient de le faire, on peut aussi utiliser NFS ou CIFS/samba. Mais dans ce cas il est préférable de mettre les nœuds en cluster de type CTDB (cluster NFS) pour avoir de la haute disponibilité. C'est donc beaucoup plus contraignant.
Lors du montage, on doit indiquer le nom d'une des briques (ici brick1). Mais le client récupère ensuite la liste de toutes les briques et peut communiquer avec n'importe laquelle.

==Paramétrage du volume==

===Timeout===
Par défaut, le timeout pour qu'un client bascule d'une brique à l'autre, en cas d'indisponibilité, est de 42 secondes. Ça peut paraître très long. Voici comment le passer à 5 secondes.
# gluster volume set volume1 network.ping-timeout 5

===Limiter les accès===
Pour limiter l'accès d'un volume aux machines du réseau 10.34.210.0/24 :
# gluster volume set volume1 auth.allow 10.34.210.*
On peut mettre plusieurs ips ou réseaux en les séparant par des virgules.
Pour revenir au comportement par défaut, il faut autoriser "*".
A l'inverse, on peut autoriser tout le monde, sauf des ips, avec le paramètre '''auth.reject'''.
Dans ce cas, pour revenir au comportement par défaut, on va rejeter "NONE".

===Quotas===
On peut activer des quotas pour le volume au niveau des sous-répertoires.
Il faut d'abord activer les quotas :
# gluster volume quota volume1 enable
Puis on défini la valeur :
# gluster volume quota volume1 limit-usage /sous-repertoire 100M
Pour voir l'état des quotas :
# gluster volume quota volume1 list

===Corbeille===
On peut activer une corbeille pour conserver les fichiers supprimés. On peut également limiter la taille aux fichiers de moins de 10Mo.
# gluster volume set volume1 features.trash on
# gluster volume set volume1 features.trash-dir "Poubelle"
# gluster volume set volume1 features.trash-max-falesize 10485760
On peut également activer la corbeille pour les opérations internes comme "rebalance" (par défaut à off) :
# gluster volume set volume1 features.trash-internal-op on

=Administration courante=

==Retirer une brique==

Si on veut retirer une brique.
# gluster peer detach ma_brique

==Remplacement d'une brique (si panne par exemple)==

Nous avons actuellement un trusted pool composé des deux briques brick1 et brick2.

Supposons que brick1 est tombée en panne et n'est pas réparable. On a préparé un nouveau serveur "brick3" et on installé les packages comme expliqué aux chapitres 3.1 et 3.2. Il faut aussi avoir préparé une arborescence /Gluster/Volumes/Volume1 ou équivalente pour accueillir le volume.

Connectons-nous sur brick2 et ajoutons brick3 au trusted-pool :
# gluster peer probe brick3

Maintenant on remplace brick1 par brick3 dans la config du volume "volume1" :
# gluster volume replace-brick volume1 brick1:/Gluster/Volumes/Volume1 brick3:/Gluster/Volumes/Volume1 commit force

On réconcilie le volume :
# gluster volume heal volume1 full

Depuis la nouvelle brique brick3, on synchronise le volume en récupérant les infos de brick2 :
root@brick3 # gluster volume sync brick2 volume1

Il faut ensuite récupérer le volume id depuis les attributs étendus du serveur brick2, pour ensuite les recopier sur brick3.

Récupération volume id :
root@brick2 # getfattr -n trusted.glusterfs.volume-id /gluster/volumes/volume1/
fichier-depuis-client.rien .glusterfs/
[root@centos8-fred ~]# getfattr -n trusted.glusterfs.volume-id /gluster/volumes/volume1/
getfattr: Removing leading '/' from absolute path names
# file: gluster/volumes/volume1/
trusted.glusterfs.volume-id=0s2M71q2FpQoi19v6sUcnyqw==

Recopie volume id sur brick3 :
root@brick3 # setfattr -n trusted.glusterfs.volume-id -v '0s2M71q2FpQoi19v6sUcnyqw==' /Gluster/Volumes/Volume1/

Il ne reste plus qu'à retirer brick1 du trusted pool :
# gluster peer detach brick1

==Étendre un volume==

Actuellement, notre volume1 est sur un volume répliqué sur un cluster à 2 briques. On peut le voir avec la commande suivante :
# gluster volume info volume1 |egrep "Type|Number"
Type: Replicate
Number of Bricks: 1 x 2 = 2

Pour l'étendre, on peut agrandir les volumes sur chaque brique, si c'est possible. Sinon, on peut aussi ajouter des briques. C'est ce qu'on va faire ici. A noter qu'il faut ajouter un nombre de briques proportionnel au nombre de replicas, donc ici 2. Ou alors il faut modifier le nombre de replicas, c’est ce qu’on va voir au chapitre suivant « ajouter un replica ».

On va donc créer deux nouveaux serveurs brick3 et brick4, y installer les packages nécessaires et démarrer les services (voir chapitres 3.1 et 3.2).

On les ajoute au trusted pool depuis une des briques existantes :
brick1# gluster peer probe brick3
brick1# gluster peer probe brick4

Sur brick3 et brick4 on créé un point de montage /gluster/volumes/ avec un sous-répertoire volume1, comme présenté au chapitre 3.4.

Pour finir, on va ajouter les volumes des nouvelles briques à volume1 :
brick1# gluster volume add-brick volume1 brick3:/gluster/volumes/volume1 brick4:/gluster/volumes/volume1

On voit qu'on a maintenant un volume distribué-répliqué à 4 briques :
# gluster volume info volume1 |egrep "Type|Number"
Type: Distributed-Replicate
Number of Bricks: 2 x 2 = 4

Côté client, l'espace disque a doublé (si les volumes sont tous de taille identique).

Par contre, si on a étendu le volume parce que les montages étaient pleins sur brick1 et 2, alors c'est toujours le cas. Car l'ajout de briques ne réparti pas automatiquement les données sur l'ensemble des briques. On va donc le forcer avec la commande :
# gluster volume rebalance volume1 start

Et on peut voir la progression avec la commande :
# gluster volume rebalance volume1 status

==Ajouter un replica==

Repartons de la situation de départ ou volume1 était réparti uniquement sur 2 briques : brick1 et brick2. On va ajouter une brique brick3. Comme c’est un volume répliqué, ça va ajouter une brique répliquée, on va donc passer le replica à 3. Ça permettra de permettre la perte de 2 serveurs, mais n’augmentera pas la volumétrie. La syntaxe est la suivante.
# gluster volume add-brick volume1 replica 3 ubuntu-fred:/gluster/volumes/volume1

On vérifie que ça a fonctionné :
# gluster volume info volume1 |grep "Number of Bricks"
Number of Bricks: 1 x 3 = 3

==Infos détaillées et perfs==

root@debian-fred:~# gluster volume profile volume1 info
Brick: brick1:/Gluster/Volumes/Volume1
-------------------------------------------
Cumulative Stats:
%-latency Avg-latency Min-Latency Max-Latency No. of calls Fop
--------- ----------- ----------- ----------- ------------ ----
0.00 0.00 us 0.00 us 0.00 us 3 RELEASEDIR

Duration: 251 seconds
Data Read: 0 bytes
Data Written: 0 bytes

Interval 1 Stats:

Duration: 32 seconds
Data Read: 0 bytes
Data Written: 0 bytes

Brick: brick2:/gluster/volumes/volume1
--------------------------------------------
Cumulative Stats:
%-latency Avg-latency Min-Latency Max-Latency No. of calls Fop
--------- ----------- ----------- ----------- ------------ ----
0.00 0.00 us 0.00 us 0.00 us 3 RELEASEDIR

Duration: 252 seconds
Data Read: 0 bytes
Data Written: 0 bytes

Interval 1 Stats:

Duration: 32 seconds
Data Read: 0 bytes
Data Written: 0 bytes

=Comparaison avec Ceph=

Une explication détaillée est disponible ici : https://www.ionos.fr/digitalguide/serveur/know-how/glusterfs-vs-ceph/

Fichier:GlusterFS volume distribue replique.jpg

2021-12-13T10:56:32Z

AdminWiki :

Fichier:GlusterFS volume replique.jpg

2021-12-13T10:55:07Z

AdminWiki :

GlusterFS

2021-12-13T10:52:41Z

AdminWiki : /* Présentation */

[[Category:linux]]

=Présentation=

GlusterFS est un système de fichiers distribué, accessible par le réseau, en mode clients/serveurs.

On doit utiliser des systèmes de fichiers avec attributs étendus, comme XFS, ext4, ext3, ext2, ZFS, ReiserFS, btrfs et beaucoup d’autres. XFS est recommandé (https://docs.gluster.org/en/v3/Install-Guide/Common_criteria/).

Chaque serveur s’appelle un nœud ou brique. En réalité, une brique est le filesystem dédié à GlusterFS sur un nœud. Mais par abus de langage, dans la plupart des docs qu’on trouve, les nœuds sont appelés briques.

Minimum 2 briques. En réalité on peut en n’avoir qu’une, mais ça n’a aucun intérêt, autant faire un serveur NFS dans ce cas.

Il n'y a pas de notion maître/esclave.

Chaque fois qu'on ajoute une brique, le système devient plus performant.

Plusieurs types de volumes :
* volume distribué : comme du raid0, on perd une brique, on perd tout ! Mais volume total = somme des volumes :
[[Fichier:GlusterFS_volume_distribue.jpg]]
* volume répliqué : autant de briques que de répliquas désirés. Avec 2 briques, revient à du raid1 = miroring :
[[Fichier:GlusterFS_volume_replique.jpg]]
* volume distribué répliqué :
[[Fichier:GlusterFS_volume_distribue_replique.jpg]]

=Mise en place=

Gluster stocke ses fichiers de conf dynamiquement dans '''/var/lib/glusterd'''. Si jamais le filesystem se rempli, ça pourrait rendre le service instable, voire le planter complètement. Il est donc conseillé de le séparer de /var/log, voire de le mettre tout seul.

==Installation des packages==

Exemple sur Debian10 :
# apt install glusterfs-server -y
# systemctl enable --now glusterd

Exemple sur CentOS 8 :
# dnf install centos-release-gluster -y
# dnf install -y glusterfs-server
# systemctl enable --now glusterd glusterfsd

==Ouverture des flux==

Sur CentOS 8, ou une autre distribution avec firewalld actif, il faut ouvrir le service glusterfs :
# firewall-cmd --zone=public --add-service=glusterfs
# firewall-cmd --zone=public --add-service=glusterfs --permanent

Ce service inclus les ports suivants : 24007/tcp, 24008/tcp, 24009/tcp, 38465/tcp, 38466/tcp, 38467/tcp, 38468/tcp, 38469/tcp et la plage 49152-49664/tcp.

A noter que cette liste me paraît très large. Sur le site de glusterfs, pour la 3.7.0 beta 1, ils ne parlent que de 24007/tcp, 24008/tcp et 49152 à 49156/tcp ([[https://docs.gluster.org/en/release-3.7.0beta1/Administrator%20Guide/Setting%20Up%20Clients/]]).

==Trusted pool==

Supposons que nous avons deux briques : brick1 et brick2.

Une fois que les briques sont installées, il faut les associer. Les briques se reconnaissent au sein de ce qu'on appelle un trusted pool.

Pour cela, aller sur une des briques, par exemple brick1, et taper :
brick1# gluster peer probe brick2
peer probe : success.

Pour vérifier :
# gluster peer status
Number of Peers: 1

Hostname: brick2
Uuid: 2b5f991b-8a43-43fc-836b-f6292157489a
State: Peer in Cluster (Connected)

Pour afficher la liste de briques :
# gluster pool list
UUID Hostname State
2b5f991b-8a43-43fc-836b-f6292157489a brick2 Connected
9189775d-c84f-48a8-93bc-85e3a10af75d localhost Connected

Si on veut supprimer une brique du pool :
# gluster peer detach brick2

==Création d'un volume répliqué==

Sur brick1, on a créé un point de montage /Gluster/Volumes en XFS.
Sur brick2, on a créé un point de montage /gluster/volumes en ext4.

On ne peut pas créer de volume directement sur un point de montage, donc on va créer des sous-répertoires.

Sur brick1, on créé /Gluster/Volumes/Volume1.
Sur brick2, on créé /gluster/volumes/volume1.

J'ai fait exprès de mettre des majuscules d'un côté et des minuscules de l'autre, pour montrer que ça n'a aucune importance d'avoir des noms et arborescences différentes sur les briques.

On va créer un volume miroir nommé "volume1", avec 2 replicas, en utilisant le transport tcp :
# gluster volume create volume1 replica 2 transport tcp brick1:/Gluster/Volumes/Volume1 brick2:/gluster/volumes/volume1
Replica 2 volumes are prone to split-brain. Use Arbiter or Replica 3 to avoid this. See:
http://docs.gluster.org/en/latest/Administrator%20Guide/Split%20brain%20and%20ways%20to%20deal%20with%20it/.
Do you still want to continue?
(y/n) y
volume create: volume1: success: please start the volume to access data

On voit l'avertissement disant qu'il est préférable d'avoir au moins 3 briques. Malgré tout, on créé le volume.
Pour voir :
# gluster volume list
volume1
root@emmabuntus:~# gluster volume status
Volume volume1 is not started

On voit que le volume est créé, mais pas démarré.
Pour le démarrer et vérifier :
# gluster volume start volume1
volume start: volume1: success

# gluster volume list
volume1

# gluster volume status
Status of volume: volume1
Gluster process TCP Port RDMA Port Online Pid
------------------------------------------------------------------------------
Brick brick1:/Gluster/Volumes/Volume1 49152 0 Y 1737
Brick brick2:/gluster/volumes/volume1 49152 0 Y 1925
Self-heal Daemon on localhost N/A N/A Y 1948
Self-heal Daemon on brick1 N/A N/A Y 1760

Task Status of Volume volume1
------------------------------------------------------------------------------
There are no active volume tasks

==Montage depuis un client==

Installer le package "glusterfs-client".
Monter en précisant une des briques et en indiquant le point de montage :
# mount -t glusterfs brick1:/volume1 /mnt
Ou depuis /etc/fstab :
brick1:/volume1 /mnt glusterfs defaults 0 0
A noter qu'au lieu d'utiliser le client natif gluster comme on vient de le faire, on peut aussi utiliser NFS ou CIFS/samba. Mais dans ce cas il est préférable de mettre les nœuds en cluster de type CTDB (cluster NFS) pour avoir de la haute disponibilité. C'est donc beaucoup plus contraignant.
Lors du montage, on doit indiquer le nom d'une des briques (ici brick1). Mais le client récupère ensuite la liste de toutes les briques et peut communiquer avec n'importe laquelle.

==Paramétrage du volume==

===Timeout===
Par défaut, le timeout pour qu'un client bascule d'une brique à l'autre, en cas d'indisponibilité, est de 42 secondes. Ça peut paraître très long. Voici comment le passer à 5 secondes.
# gluster volume set volume1 network.ping-timeout 5

===Limiter les accès===
Pour limiter l'accès d'un volume aux machines du réseau 10.34.210.0/24 :
# gluster volume set volume1 auth.allow 10.34.210.*
On peut mettre plusieurs ips ou réseaux en les séparant par des virgules.
Pour revenir au comportement par défaut, il faut autoriser "*".
A l'inverse, on peut autoriser tout le monde, sauf des ips, avec le paramètre '''auth.reject'''.
Dans ce cas, pour revenir au comportement par défaut, on va rejeter "NONE".

===Quotas===
On peut activer des quotas pour le volume au niveau des sous-répertoires.
Il faut d'abord activer les quotas :
# gluster volume quota volume1 enable
Puis on défini la valeur :
# gluster volume quota volume1 limit-usage /sous-repertoire 100M
Pour voir l'état des quotas :
# gluster volume quota volume1 list

===Corbeille===
On peut activer une corbeille pour conserver les fichiers supprimés. On peut également limiter la taille aux fichiers de moins de 10Mo.
# gluster volume set volume1 features.trash on
# gluster volume set volume1 features.trash-dir "Poubelle"
# gluster volume set volume1 features.trash-max-falesize 10485760
On peut également activer la corbeille pour les opérations internes comme "rebalance" (par défaut à off) :
# gluster volume set volume1 features.trash-internal-op on

=Administration courante=

==Retirer une brique==

Si on veut retirer une brique.
# gluster peer detach ma_brique

==Remplacement d'une brique (si panne par exemple)==

Nous avons actuellement un trusted pool composé des deux briques brick1 et brick2.

Supposons que brick1 est tombée en panne et n'est pas réparable. On a préparé un nouveau serveur "brick3" et on installé les packages comme expliqué aux chapitres 3.1 et 3.2. Il faut aussi avoir préparé une arborescence /Gluster/Volumes/Volume1 ou équivalente pour accueillir le volume.

Connectons-nous sur brick2 et ajoutons brick3 au trusted-pool :
# gluster peer probe brick3

Maintenant on remplace brick1 par brick3 dans la config du volume "volume1" :
# gluster volume replace-brick volume1 brick1:/Gluster/Volumes/Volume1 brick3:/Gluster/Volumes/Volume1 commit force

On réconcilie le volume :
# gluster volume heal volume1 full

Depuis la nouvelle brique brick3, on synchronise le volume en récupérant les infos de brick2 :
root@brick3 # gluster volume sync brick2 volume1

Il faut ensuite récupérer le volume id depuis les attributs étendus du serveur brick2, pour ensuite les recopier sur brick3.

Récupération volume id :
root@brick2 # getfattr -n trusted.glusterfs.volume-id /gluster/volumes/volume1/
fichier-depuis-client.rien .glusterfs/
[root@centos8-fred ~]# getfattr -n trusted.glusterfs.volume-id /gluster/volumes/volume1/
getfattr: Removing leading '/' from absolute path names
# file: gluster/volumes/volume1/
trusted.glusterfs.volume-id=0s2M71q2FpQoi19v6sUcnyqw==

Recopie volume id sur brick3 :
root@brick3 # setfattr -n trusted.glusterfs.volume-id -v '0s2M71q2FpQoi19v6sUcnyqw==' /Gluster/Volumes/Volume1/

Il ne reste plus qu'à retirer brick1 du trusted pool :
# gluster peer detach brick1

==Étendre un volume==

Actuellement, notre volume1 est sur un volume répliqué sur un cluster à 2 briques. On peut le voir avec la commande suivante :
# gluster volume info volume1 |egrep "Type|Number"
Type: Replicate
Number of Bricks: 1 x 2 = 2

Pour l'étendre, on peut agrandir les volumes sur chaque brique, si c'est possible. Sinon, on peut aussi ajouter des briques. C'est ce qu'on va faire ici. A noter qu'il faut ajouter un nombre de briques proportionnel au nombre de replicas, donc ici 2. Ou alors il faut modifier le nombre de replicas, c’est ce qu’on va voir au chapitre suivant « ajouter un replica ».

On va donc créer deux nouveaux serveurs brick3 et brick4, y installer les packages nécessaires et démarrer les services (voir chapitres 3.1 et 3.2).

On les ajoute au trusted pool depuis une des briques existantes :
brick1# gluster peer probe brick3
brick1# gluster peer probe brick4

Sur brick3 et brick4 on créé un point de montage /gluster/volumes/ avec un sous-répertoire volume1, comme présenté au chapitre 3.4.

Pour finir, on va ajouter les volumes des nouvelles briques à volume1 :
brick1# gluster volume add-brick volume1 brick3:/gluster/volumes/volume1 brick4:/gluster/volumes/volume1

On voit qu'on a maintenant un volume distribué-répliqué à 4 briques :
# gluster volume info volume1 |egrep "Type|Number"
Type: Distributed-Replicate
Number of Bricks: 2 x 2 = 4

Côté client, l'espace disque a doublé (si les volumes sont tous de taille identique).

Par contre, si on a étendu le volume parce que les montages étaient pleins sur brick1 et 2, alors c'est toujours le cas. Car l'ajout de briques ne réparti pas automatiquement les données sur l'ensemble des briques. On va donc le forcer avec la commande :
# gluster volume rebalance volume1 start

Et on peut voir la progression avec la commande :
# gluster volume rebalance volume1 status

==Ajouter un replica==

Repartons de la situation de départ ou volume1 était réparti uniquement sur 2 briques : brick1 et brick2. On va ajouter une brique brick3. Comme c’est un volume répliqué, ça va ajouter une brique répliquée, on va donc passer le replica à 3. Ça permettra de permettre la perte de 2 serveurs, mais n’augmentera pas la volumétrie. La syntaxe est la suivante.
# gluster volume add-brick volume1 replica 3 ubuntu-fred:/gluster/volumes/volume1

On vérifie que ça a fonctionné :
# gluster volume info volume1 |grep "Number of Bricks"
Number of Bricks: 1 x 3 = 3

==Infos détaillées et perfs==

root@debian-fred:~# gluster volume profile volume1 info
Brick: brick1:/Gluster/Volumes/Volume1
-------------------------------------------
Cumulative Stats:
%-latency Avg-latency Min-Latency Max-Latency No. of calls Fop
--------- ----------- ----------- ----------- ------------ ----
0.00 0.00 us 0.00 us 0.00 us 3 RELEASEDIR

Duration: 251 seconds
Data Read: 0 bytes
Data Written: 0 bytes

Interval 1 Stats:

Duration: 32 seconds
Data Read: 0 bytes
Data Written: 0 bytes

Brick: brick2:/gluster/volumes/volume1
--------------------------------------------
Cumulative Stats:
%-latency Avg-latency Min-Latency Max-Latency No. of calls Fop
--------- ----------- ----------- ----------- ------------ ----
0.00 0.00 us 0.00 us 0.00 us 3 RELEASEDIR

Duration: 252 seconds
Data Read: 0 bytes
Data Written: 0 bytes

Interval 1 Stats:

Duration: 32 seconds
Data Read: 0 bytes
Data Written: 0 bytes

=Comparaison avec Ceph=

Une explication détaillée est disponible ici : https://www.ionos.fr/digitalguide/serveur/know-how/glusterfs-vs-ceph/

GlusterFS

2021-12-13T10:48:54Z

AdminWiki : /* Présentation */

[[Category:linux]]

=Présentation=

GlusterFS est un système de fichiers distribué, accessible par le réseau, en mode clients/serveurs.

On doit utiliser des systèmes de fichiers avec attributs étendus, comme XFS, ext4, ext3, ext2, ZFS, ReiserFS, btrfs et beaucoup d’autres. XFS est recommandé (https://docs.gluster.org/en/v3/Install-Guide/Common_criteria/).

Chaque serveur s’appelle un nœud ou brique. En réalité, une brique est le filesystem dédié à GlusterFS sur un nœud. Mais par abus de langage, dans la plupart des docs qu’on trouve, les nœuds sont appelés briques.

Minimum 2 briques. En réalité on peut en n’avoir qu’une, mais ça n’a aucun intérêt, autant faire un serveur NFS dans ce cas.

Il n'y a pas de notion maître/esclave.

Chaque fois qu'on ajoute une brique, le système devient plus performant.

Plusieurs types de volumes :
* volume distribué : comme du raid0, on perd une brique, on perd tout ! Mais volume total = somme des volumes :

* volume répliqué : autant de briques que de répliquas désirés. Avec 2 briques, revient à du raid1 = miroring :

* volume distribué répliqué :

=Mise en place=

Gluster stocke ses fichiers de conf dynamiquement dans '''/var/lib/glusterd'''. Si jamais le filesystem se rempli, ça pourrait rendre le service instable, voire le planter complètement. Il est donc conseillé de le séparer de /var/log, voire de le mettre tout seul.

==Installation des packages==

Exemple sur Debian10 :
# apt install glusterfs-server -y
# systemctl enable --now glusterd

Exemple sur CentOS 8 :
# dnf install centos-release-gluster -y
# dnf install -y glusterfs-server
# systemctl enable --now glusterd glusterfsd

==Ouverture des flux==

Sur CentOS 8, ou une autre distribution avec firewalld actif, il faut ouvrir le service glusterfs :
# firewall-cmd --zone=public --add-service=glusterfs
# firewall-cmd --zone=public --add-service=glusterfs --permanent

Ce service inclus les ports suivants : 24007/tcp, 24008/tcp, 24009/tcp, 38465/tcp, 38466/tcp, 38467/tcp, 38468/tcp, 38469/tcp et la plage 49152-49664/tcp.

A noter que cette liste me paraît très large. Sur le site de glusterfs, pour la 3.7.0 beta 1, ils ne parlent que de 24007/tcp, 24008/tcp et 49152 à 49156/tcp ([[https://docs.gluster.org/en/release-3.7.0beta1/Administrator%20Guide/Setting%20Up%20Clients/]]).

==Trusted pool==

Supposons que nous avons deux briques : brick1 et brick2.

Une fois que les briques sont installées, il faut les associer. Les briques se reconnaissent au sein de ce qu'on appelle un trusted pool.

Pour cela, aller sur une des briques, par exemple brick1, et taper :
brick1# gluster peer probe brick2
peer probe : success.

Pour vérifier :
# gluster peer status
Number of Peers: 1

Hostname: brick2
Uuid: 2b5f991b-8a43-43fc-836b-f6292157489a
State: Peer in Cluster (Connected)

Pour afficher la liste de briques :
# gluster pool list
UUID Hostname State
2b5f991b-8a43-43fc-836b-f6292157489a brick2 Connected
9189775d-c84f-48a8-93bc-85e3a10af75d localhost Connected

Si on veut supprimer une brique du pool :
# gluster peer detach brick2

==Création d'un volume répliqué==

Sur brick1, on a créé un point de montage /Gluster/Volumes en XFS.
Sur brick2, on a créé un point de montage /gluster/volumes en ext4.

On ne peut pas créer de volume directement sur un point de montage, donc on va créer des sous-répertoires.

Sur brick1, on créé /Gluster/Volumes/Volume1.
Sur brick2, on créé /gluster/volumes/volume1.

J'ai fait exprès de mettre des majuscules d'un côté et des minuscules de l'autre, pour montrer que ça n'a aucune importance d'avoir des noms et arborescences différentes sur les briques.

On va créer un volume miroir nommé "volume1", avec 2 replicas, en utilisant le transport tcp :
# gluster volume create volume1 replica 2 transport tcp brick1:/Gluster/Volumes/Volume1 brick2:/gluster/volumes/volume1
Replica 2 volumes are prone to split-brain. Use Arbiter or Replica 3 to avoid this. See:
http://docs.gluster.org/en/latest/Administrator%20Guide/Split%20brain%20and%20ways%20to%20deal%20with%20it/.
Do you still want to continue?
(y/n) y
volume create: volume1: success: please start the volume to access data

On voit l'avertissement disant qu'il est préférable d'avoir au moins 3 briques. Malgré tout, on créé le volume.
Pour voir :
# gluster volume list
volume1
root@emmabuntus:~# gluster volume status
Volume volume1 is not started

On voit que le volume est créé, mais pas démarré.
Pour le démarrer et vérifier :
# gluster volume start volume1
volume start: volume1: success

# gluster volume list
volume1

# gluster volume status
Status of volume: volume1
Gluster process TCP Port RDMA Port Online Pid
------------------------------------------------------------------------------
Brick brick1:/Gluster/Volumes/Volume1 49152 0 Y 1737
Brick brick2:/gluster/volumes/volume1 49152 0 Y 1925
Self-heal Daemon on localhost N/A N/A Y 1948
Self-heal Daemon on brick1 N/A N/A Y 1760

Task Status of Volume volume1
------------------------------------------------------------------------------
There are no active volume tasks

==Montage depuis un client==

Installer le package "glusterfs-client".
Monter en précisant une des briques et en indiquant le point de montage :
# mount -t glusterfs brick1:/volume1 /mnt
Ou depuis /etc/fstab :
brick1:/volume1 /mnt glusterfs defaults 0 0
A noter qu'au lieu d'utiliser le client natif gluster comme on vient de le faire, on peut aussi utiliser NFS ou CIFS/samba. Mais dans ce cas il est préférable de mettre les nœuds en cluster de type CTDB (cluster NFS) pour avoir de la haute disponibilité. C'est donc beaucoup plus contraignant.
Lors du montage, on doit indiquer le nom d'une des briques (ici brick1). Mais le client récupère ensuite la liste de toutes les briques et peut communiquer avec n'importe laquelle.

==Paramétrage du volume==

===Timeout===
Par défaut, le timeout pour qu'un client bascule d'une brique à l'autre, en cas d'indisponibilité, est de 42 secondes. Ça peut paraître très long. Voici comment le passer à 5 secondes.
# gluster volume set volume1 network.ping-timeout 5

===Limiter les accès===
Pour limiter l'accès d'un volume aux machines du réseau 10.34.210.0/24 :
# gluster volume set volume1 auth.allow 10.34.210.*
On peut mettre plusieurs ips ou réseaux en les séparant par des virgules.
Pour revenir au comportement par défaut, il faut autoriser "*".
A l'inverse, on peut autoriser tout le monde, sauf des ips, avec le paramètre '''auth.reject'''.
Dans ce cas, pour revenir au comportement par défaut, on va rejeter "NONE".

===Quotas===
On peut activer des quotas pour le volume au niveau des sous-répertoires.
Il faut d'abord activer les quotas :
# gluster volume quota volume1 enable
Puis on défini la valeur :
# gluster volume quota volume1 limit-usage /sous-repertoire 100M
Pour voir l'état des quotas :
# gluster volume quota volume1 list

===Corbeille===
On peut activer une corbeille pour conserver les fichiers supprimés. On peut également limiter la taille aux fichiers de moins de 10Mo.
# gluster volume set volume1 features.trash on
# gluster volume set volume1 features.trash-dir "Poubelle"
# gluster volume set volume1 features.trash-max-falesize 10485760
On peut également activer la corbeille pour les opérations internes comme "rebalance" (par défaut à off) :
# gluster volume set volume1 features.trash-internal-op on

=Administration courante=

==Retirer une brique==

Si on veut retirer une brique.
# gluster peer detach ma_brique

==Remplacement d'une brique (si panne par exemple)==

Nous avons actuellement un trusted pool composé des deux briques brick1 et brick2.

Supposons que brick1 est tombée en panne et n'est pas réparable. On a préparé un nouveau serveur "brick3" et on installé les packages comme expliqué aux chapitres 3.1 et 3.2. Il faut aussi avoir préparé une arborescence /Gluster/Volumes/Volume1 ou équivalente pour accueillir le volume.

Connectons-nous sur brick2 et ajoutons brick3 au trusted-pool :
# gluster peer probe brick3

Maintenant on remplace brick1 par brick3 dans la config du volume "volume1" :
# gluster volume replace-brick volume1 brick1:/Gluster/Volumes/Volume1 brick3:/Gluster/Volumes/Volume1 commit force

On réconcilie le volume :
# gluster volume heal volume1 full

Depuis la nouvelle brique brick3, on synchronise le volume en récupérant les infos de brick2 :
root@brick3 # gluster volume sync brick2 volume1

Il faut ensuite récupérer le volume id depuis les attributs étendus du serveur brick2, pour ensuite les recopier sur brick3.

Récupération volume id :
root@brick2 # getfattr -n trusted.glusterfs.volume-id /gluster/volumes/volume1/
fichier-depuis-client.rien .glusterfs/
[root@centos8-fred ~]# getfattr -n trusted.glusterfs.volume-id /gluster/volumes/volume1/
getfattr: Removing leading '/' from absolute path names
# file: gluster/volumes/volume1/
trusted.glusterfs.volume-id=0s2M71q2FpQoi19v6sUcnyqw==

Recopie volume id sur brick3 :
root@brick3 # setfattr -n trusted.glusterfs.volume-id -v '0s2M71q2FpQoi19v6sUcnyqw==' /Gluster/Volumes/Volume1/

Il ne reste plus qu'à retirer brick1 du trusted pool :
# gluster peer detach brick1

==Étendre un volume==

Actuellement, notre volume1 est sur un volume répliqué sur un cluster à 2 briques. On peut le voir avec la commande suivante :
# gluster volume info volume1 |egrep "Type|Number"
Type: Replicate
Number of Bricks: 1 x 2 = 2

Pour l'étendre, on peut agrandir les volumes sur chaque brique, si c'est possible. Sinon, on peut aussi ajouter des briques. C'est ce qu'on va faire ici. A noter qu'il faut ajouter un nombre de briques proportionnel au nombre de replicas, donc ici 2. Ou alors il faut modifier le nombre de replicas, c’est ce qu’on va voir au chapitre suivant « ajouter un replica ».

On va donc créer deux nouveaux serveurs brick3 et brick4, y installer les packages nécessaires et démarrer les services (voir chapitres 3.1 et 3.2).

On les ajoute au trusted pool depuis une des briques existantes :
brick1# gluster peer probe brick3
brick1# gluster peer probe brick4

Sur brick3 et brick4 on créé un point de montage /gluster/volumes/ avec un sous-répertoire volume1, comme présenté au chapitre 3.4.

Pour finir, on va ajouter les volumes des nouvelles briques à volume1 :
brick1# gluster volume add-brick volume1 brick3:/gluster/volumes/volume1 brick4:/gluster/volumes/volume1

On voit qu'on a maintenant un volume distribué-répliqué à 4 briques :
# gluster volume info volume1 |egrep "Type|Number"
Type: Distributed-Replicate
Number of Bricks: 2 x 2 = 4

Côté client, l'espace disque a doublé (si les volumes sont tous de taille identique).

Par contre, si on a étendu le volume parce que les montages étaient pleins sur brick1 et 2, alors c'est toujours le cas. Car l'ajout de briques ne réparti pas automatiquement les données sur l'ensemble des briques. On va donc le forcer avec la commande :
# gluster volume rebalance volume1 start

Et on peut voir la progression avec la commande :
# gluster volume rebalance volume1 status

==Ajouter un replica==

Repartons de la situation de départ ou volume1 était réparti uniquement sur 2 briques : brick1 et brick2. On va ajouter une brique brick3. Comme c’est un volume répliqué, ça va ajouter une brique répliquée, on va donc passer le replica à 3. Ça permettra de permettre la perte de 2 serveurs, mais n’augmentera pas la volumétrie. La syntaxe est la suivante.
# gluster volume add-brick volume1 replica 3 ubuntu-fred:/gluster/volumes/volume1

On vérifie que ça a fonctionné :
# gluster volume info volume1 |grep "Number of Bricks"
Number of Bricks: 1 x 3 = 3

==Infos détaillées et perfs==

root@debian-fred:~# gluster volume profile volume1 info
Brick: brick1:/Gluster/Volumes/Volume1
-------------------------------------------
Cumulative Stats:
%-latency Avg-latency Min-Latency Max-Latency No. of calls Fop
--------- ----------- ----------- ----------- ------------ ----
0.00 0.00 us 0.00 us 0.00 us 3 RELEASEDIR

Duration: 251 seconds
Data Read: 0 bytes
Data Written: 0 bytes

Interval 1 Stats:

Duration: 32 seconds
Data Read: 0 bytes
Data Written: 0 bytes

Brick: brick2:/gluster/volumes/volume1
--------------------------------------------
Cumulative Stats:
%-latency Avg-latency Min-Latency Max-Latency No. of calls Fop
--------- ----------- ----------- ----------- ------------ ----
0.00 0.00 us 0.00 us 0.00 us 3 RELEASEDIR

Duration: 252 seconds
Data Read: 0 bytes
Data Written: 0 bytes

Interval 1 Stats:

Duration: 32 seconds
Data Read: 0 bytes
Data Written: 0 bytes

=Comparaison avec Ceph=

Une explication détaillée est disponible ici : https://www.ionos.fr/digitalguide/serveur/know-how/glusterfs-vs-ceph/

GlusterFS

2021-12-13T10:46:56Z

AdminWiki : /* Comparaison avec Ceph */

[[Category:linux]]

=Présentation=

GlusterFS est un système de fichiers distribué, accessible par le réseau, en mode clients/serveurs.

On doit utiliser des systèmes de fichiers avec attributs étendus, comme XFS, ext4, ext3, ext2, ZFS, ReiserFS, btrfs et beaucoup d’autres. XFS est recommandé (https://docs.gluster.org/en/v3/Install-Guide/Common_criteria/).

Chaque serveur s’appelle un nœud ou brique. En réalité, une brique est le filesystem dédié à GlusterFS sur un nœud. Mais par abus de langage, dans la plupart des docs qu’on trouve, les nœuds sont appelés briques.

Minimum 2 briques. En réalité on peut en n’avoir qu’une, mais ça n’a aucun intérêt, autant faire un serveur NFS dans ce cas.

Il n'y a pas de notion maître/esclave.

Chaque fois qu'on ajoute une brique, le système devient plus performant.

Plusieurs types de volumes :

=Mise en place=

Gluster stocke ses fichiers de conf dynamiquement dans '''/var/lib/glusterd'''. Si jamais le filesystem se rempli, ça pourrait rendre le service instable, voire le planter complètement. Il est donc conseillé de le séparer de /var/log, voire de le mettre tout seul.

==Installation des packages==

Exemple sur Debian10 :
# apt install glusterfs-server -y
# systemctl enable --now glusterd

Exemple sur CentOS 8 :
# dnf install centos-release-gluster -y
# dnf install -y glusterfs-server
# systemctl enable --now glusterd glusterfsd

==Ouverture des flux==

Sur CentOS 8, ou une autre distribution avec firewalld actif, il faut ouvrir le service glusterfs :
# firewall-cmd --zone=public --add-service=glusterfs
# firewall-cmd --zone=public --add-service=glusterfs --permanent

Ce service inclus les ports suivants : 24007/tcp, 24008/tcp, 24009/tcp, 38465/tcp, 38466/tcp, 38467/tcp, 38468/tcp, 38469/tcp et la plage 49152-49664/tcp.

A noter que cette liste me paraît très large. Sur le site de glusterfs, pour la 3.7.0 beta 1, ils ne parlent que de 24007/tcp, 24008/tcp et 49152 à 49156/tcp ([[https://docs.gluster.org/en/release-3.7.0beta1/Administrator%20Guide/Setting%20Up%20Clients/]]).

==Trusted pool==

Supposons que nous avons deux briques : brick1 et brick2.

Une fois que les briques sont installées, il faut les associer. Les briques se reconnaissent au sein de ce qu'on appelle un trusted pool.

Pour cela, aller sur une des briques, par exemple brick1, et taper :
brick1# gluster peer probe brick2
peer probe : success.

Pour vérifier :
# gluster peer status
Number of Peers: 1

Hostname: brick2
Uuid: 2b5f991b-8a43-43fc-836b-f6292157489a
State: Peer in Cluster (Connected)

Pour afficher la liste de briques :
# gluster pool list
UUID Hostname State
2b5f991b-8a43-43fc-836b-f6292157489a brick2 Connected
9189775d-c84f-48a8-93bc-85e3a10af75d localhost Connected

Si on veut supprimer une brique du pool :
# gluster peer detach brick2

==Création d'un volume répliqué==

Sur brick1, on a créé un point de montage /Gluster/Volumes en XFS.
Sur brick2, on a créé un point de montage /gluster/volumes en ext4.

On ne peut pas créer de volume directement sur un point de montage, donc on va créer des sous-répertoires.

Sur brick1, on créé /Gluster/Volumes/Volume1.
Sur brick2, on créé /gluster/volumes/volume1.

J'ai fait exprès de mettre des majuscules d'un côté et des minuscules de l'autre, pour montrer que ça n'a aucune importance d'avoir des noms et arborescences différentes sur les briques.

On va créer un volume miroir nommé "volume1", avec 2 replicas, en utilisant le transport tcp :
# gluster volume create volume1 replica 2 transport tcp brick1:/Gluster/Volumes/Volume1 brick2:/gluster/volumes/volume1
Replica 2 volumes are prone to split-brain. Use Arbiter or Replica 3 to avoid this. See:
http://docs.gluster.org/en/latest/Administrator%20Guide/Split%20brain%20and%20ways%20to%20deal%20with%20it/.
Do you still want to continue?
(y/n) y
volume create: volume1: success: please start the volume to access data

On voit l'avertissement disant qu'il est préférable d'avoir au moins 3 briques. Malgré tout, on créé le volume.
Pour voir :
# gluster volume list
volume1
root@emmabuntus:~# gluster volume status
Volume volume1 is not started

On voit que le volume est créé, mais pas démarré.
Pour le démarrer et vérifier :
# gluster volume start volume1
volume start: volume1: success

# gluster volume list
volume1

# gluster volume status
Status of volume: volume1
Gluster process TCP Port RDMA Port Online Pid
------------------------------------------------------------------------------
Brick brick1:/Gluster/Volumes/Volume1 49152 0 Y 1737
Brick brick2:/gluster/volumes/volume1 49152 0 Y 1925
Self-heal Daemon on localhost N/A N/A Y 1948
Self-heal Daemon on brick1 N/A N/A Y 1760

Task Status of Volume volume1
------------------------------------------------------------------------------
There are no active volume tasks

==Montage depuis un client==

Installer le package "glusterfs-client".
Monter en précisant une des briques et en indiquant le point de montage :
# mount -t glusterfs brick1:/volume1 /mnt
Ou depuis /etc/fstab :
brick1:/volume1 /mnt glusterfs defaults 0 0
A noter qu'au lieu d'utiliser le client natif gluster comme on vient de le faire, on peut aussi utiliser NFS ou CIFS/samba. Mais dans ce cas il est préférable de mettre les nœuds en cluster de type CTDB (cluster NFS) pour avoir de la haute disponibilité. C'est donc beaucoup plus contraignant.
Lors du montage, on doit indiquer le nom d'une des briques (ici brick1). Mais le client récupère ensuite la liste de toutes les briques et peut communiquer avec n'importe laquelle.

==Paramétrage du volume==

===Timeout===
Par défaut, le timeout pour qu'un client bascule d'une brique à l'autre, en cas d'indisponibilité, est de 42 secondes. Ça peut paraître très long. Voici comment le passer à 5 secondes.
# gluster volume set volume1 network.ping-timeout 5

===Limiter les accès===
Pour limiter l'accès d'un volume aux machines du réseau 10.34.210.0/24 :
# gluster volume set volume1 auth.allow 10.34.210.*
On peut mettre plusieurs ips ou réseaux en les séparant par des virgules.
Pour revenir au comportement par défaut, il faut autoriser "*".
A l'inverse, on peut autoriser tout le monde, sauf des ips, avec le paramètre '''auth.reject'''.
Dans ce cas, pour revenir au comportement par défaut, on va rejeter "NONE".

===Quotas===
On peut activer des quotas pour le volume au niveau des sous-répertoires.
Il faut d'abord activer les quotas :
# gluster volume quota volume1 enable
Puis on défini la valeur :
# gluster volume quota volume1 limit-usage /sous-repertoire 100M
Pour voir l'état des quotas :
# gluster volume quota volume1 list

===Corbeille===
On peut activer une corbeille pour conserver les fichiers supprimés. On peut également limiter la taille aux fichiers de moins de 10Mo.
# gluster volume set volume1 features.trash on
# gluster volume set volume1 features.trash-dir "Poubelle"
# gluster volume set volume1 features.trash-max-falesize 10485760
On peut également activer la corbeille pour les opérations internes comme "rebalance" (par défaut à off) :
# gluster volume set volume1 features.trash-internal-op on

=Administration courante=

==Retirer une brique==

Si on veut retirer une brique.
# gluster peer detach ma_brique

==Remplacement d'une brique (si panne par exemple)==

Nous avons actuellement un trusted pool composé des deux briques brick1 et brick2.

Supposons que brick1 est tombée en panne et n'est pas réparable. On a préparé un nouveau serveur "brick3" et on installé les packages comme expliqué aux chapitres 3.1 et 3.2. Il faut aussi avoir préparé une arborescence /Gluster/Volumes/Volume1 ou équivalente pour accueillir le volume.

Connectons-nous sur brick2 et ajoutons brick3 au trusted-pool :
# gluster peer probe brick3

Maintenant on remplace brick1 par brick3 dans la config du volume "volume1" :
# gluster volume replace-brick volume1 brick1:/Gluster/Volumes/Volume1 brick3:/Gluster/Volumes/Volume1 commit force

On réconcilie le volume :
# gluster volume heal volume1 full

Depuis la nouvelle brique brick3, on synchronise le volume en récupérant les infos de brick2 :
root@brick3 # gluster volume sync brick2 volume1

Il faut ensuite récupérer le volume id depuis les attributs étendus du serveur brick2, pour ensuite les recopier sur brick3.

Récupération volume id :
root@brick2 # getfattr -n trusted.glusterfs.volume-id /gluster/volumes/volume1/
fichier-depuis-client.rien .glusterfs/
[root@centos8-fred ~]# getfattr -n trusted.glusterfs.volume-id /gluster/volumes/volume1/
getfattr: Removing leading '/' from absolute path names
# file: gluster/volumes/volume1/
trusted.glusterfs.volume-id=0s2M71q2FpQoi19v6sUcnyqw==

Recopie volume id sur brick3 :
root@brick3 # setfattr -n trusted.glusterfs.volume-id -v '0s2M71q2FpQoi19v6sUcnyqw==' /Gluster/Volumes/Volume1/

Il ne reste plus qu'à retirer brick1 du trusted pool :
# gluster peer detach brick1

==Étendre un volume==

Actuellement, notre volume1 est sur un volume répliqué sur un cluster à 2 briques. On peut le voir avec la commande suivante :
# gluster volume info volume1 |egrep "Type|Number"
Type: Replicate
Number of Bricks: 1 x 2 = 2

Pour l'étendre, on peut agrandir les volumes sur chaque brique, si c'est possible. Sinon, on peut aussi ajouter des briques. C'est ce qu'on va faire ici. A noter qu'il faut ajouter un nombre de briques proportionnel au nombre de replicas, donc ici 2. Ou alors il faut modifier le nombre de replicas, c’est ce qu’on va voir au chapitre suivant « ajouter un replica ».

On va donc créer deux nouveaux serveurs brick3 et brick4, y installer les packages nécessaires et démarrer les services (voir chapitres 3.1 et 3.2).

On les ajoute au trusted pool depuis une des briques existantes :
brick1# gluster peer probe brick3
brick1# gluster peer probe brick4

Sur brick3 et brick4 on créé un point de montage /gluster/volumes/ avec un sous-répertoire volume1, comme présenté au chapitre 3.4.

Pour finir, on va ajouter les volumes des nouvelles briques à volume1 :
brick1# gluster volume add-brick volume1 brick3:/gluster/volumes/volume1 brick4:/gluster/volumes/volume1

On voit qu'on a maintenant un volume distribué-répliqué à 4 briques :
# gluster volume info volume1 |egrep "Type|Number"
Type: Distributed-Replicate
Number of Bricks: 2 x 2 = 4

Côté client, l'espace disque a doublé (si les volumes sont tous de taille identique).

Par contre, si on a étendu le volume parce que les montages étaient pleins sur brick1 et 2, alors c'est toujours le cas. Car l'ajout de briques ne réparti pas automatiquement les données sur l'ensemble des briques. On va donc le forcer avec la commande :
# gluster volume rebalance volume1 start

Et on peut voir la progression avec la commande :
# gluster volume rebalance volume1 status

==Ajouter un replica==

Repartons de la situation de départ ou volume1 était réparti uniquement sur 2 briques : brick1 et brick2. On va ajouter une brique brick3. Comme c’est un volume répliqué, ça va ajouter une brique répliquée, on va donc passer le replica à 3. Ça permettra de permettre la perte de 2 serveurs, mais n’augmentera pas la volumétrie. La syntaxe est la suivante.
# gluster volume add-brick volume1 replica 3 ubuntu-fred:/gluster/volumes/volume1

On vérifie que ça a fonctionné :
# gluster volume info volume1 |grep "Number of Bricks"
Number of Bricks: 1 x 3 = 3

==Infos détaillées et perfs==

root@debian-fred:~# gluster volume profile volume1 info
Brick: brick1:/Gluster/Volumes/Volume1
-------------------------------------------
Cumulative Stats:
%-latency Avg-latency Min-Latency Max-Latency No. of calls Fop
--------- ----------- ----------- ----------- ------------ ----
0.00 0.00 us 0.00 us 0.00 us 3 RELEASEDIR

Duration: 251 seconds
Data Read: 0 bytes
Data Written: 0 bytes

Interval 1 Stats:

Duration: 32 seconds
Data Read: 0 bytes
Data Written: 0 bytes

Brick: brick2:/gluster/volumes/volume1
--------------------------------------------
Cumulative Stats:
%-latency Avg-latency Min-Latency Max-Latency No. of calls Fop
--------- ----------- ----------- ----------- ------------ ----
0.00 0.00 us 0.00 us 0.00 us 3 RELEASEDIR

Duration: 252 seconds
Data Read: 0 bytes
Data Written: 0 bytes

Interval 1 Stats:

Duration: 32 seconds
Data Read: 0 bytes
Data Written: 0 bytes

=Comparaison avec Ceph=

Une explication détaillée est disponible ici : https://www.ionos.fr/digitalguide/serveur/know-how/glusterfs-vs-ceph/

GlusterFS

2021-12-13T10:46:14Z

AdminWiki :

[[Category:linux]]

=Présentation=

GlusterFS est un système de fichiers distribué, accessible par le réseau, en mode clients/serveurs.

On doit utiliser des systèmes de fichiers avec attributs étendus, comme XFS, ext4, ext3, ext2, ZFS, ReiserFS, btrfs et beaucoup d’autres. XFS est recommandé (https://docs.gluster.org/en/v3/Install-Guide/Common_criteria/).

Chaque serveur s’appelle un nœud ou brique. En réalité, une brique est le filesystem dédié à GlusterFS sur un nœud. Mais par abus de langage, dans la plupart des docs qu’on trouve, les nœuds sont appelés briques.

Minimum 2 briques. En réalité on peut en n’avoir qu’une, mais ça n’a aucun intérêt, autant faire un serveur NFS dans ce cas.

Il n'y a pas de notion maître/esclave.

Chaque fois qu'on ajoute une brique, le système devient plus performant.

Plusieurs types de volumes :

=Mise en place=

Gluster stocke ses fichiers de conf dynamiquement dans '''/var/lib/glusterd'''. Si jamais le filesystem se rempli, ça pourrait rendre le service instable, voire le planter complètement. Il est donc conseillé de le séparer de /var/log, voire de le mettre tout seul.

==Installation des packages==

Exemple sur Debian10 :
# apt install glusterfs-server -y
# systemctl enable --now glusterd

Exemple sur CentOS 8 :
# dnf install centos-release-gluster -y
# dnf install -y glusterfs-server
# systemctl enable --now glusterd glusterfsd

==Ouverture des flux==

Sur CentOS 8, ou une autre distribution avec firewalld actif, il faut ouvrir le service glusterfs :
# firewall-cmd --zone=public --add-service=glusterfs
# firewall-cmd --zone=public --add-service=glusterfs --permanent

Ce service inclus les ports suivants : 24007/tcp, 24008/tcp, 24009/tcp, 38465/tcp, 38466/tcp, 38467/tcp, 38468/tcp, 38469/tcp et la plage 49152-49664/tcp.

A noter que cette liste me paraît très large. Sur le site de glusterfs, pour la 3.7.0 beta 1, ils ne parlent que de 24007/tcp, 24008/tcp et 49152 à 49156/tcp ([[https://docs.gluster.org/en/release-3.7.0beta1/Administrator%20Guide/Setting%20Up%20Clients/]]).

==Trusted pool==

Supposons que nous avons deux briques : brick1 et brick2.

Une fois que les briques sont installées, il faut les associer. Les briques se reconnaissent au sein de ce qu'on appelle un trusted pool.

Pour cela, aller sur une des briques, par exemple brick1, et taper :
brick1# gluster peer probe brick2
peer probe : success.

Pour vérifier :
# gluster peer status
Number of Peers: 1

Hostname: brick2
Uuid: 2b5f991b-8a43-43fc-836b-f6292157489a
State: Peer in Cluster (Connected)

Pour afficher la liste de briques :
# gluster pool list
UUID Hostname State
2b5f991b-8a43-43fc-836b-f6292157489a brick2 Connected
9189775d-c84f-48a8-93bc-85e3a10af75d localhost Connected

Si on veut supprimer une brique du pool :
# gluster peer detach brick2

==Création d'un volume répliqué==

Sur brick1, on a créé un point de montage /Gluster/Volumes en XFS.
Sur brick2, on a créé un point de montage /gluster/volumes en ext4.

On ne peut pas créer de volume directement sur un point de montage, donc on va créer des sous-répertoires.

Sur brick1, on créé /Gluster/Volumes/Volume1.
Sur brick2, on créé /gluster/volumes/volume1.

J'ai fait exprès de mettre des majuscules d'un côté et des minuscules de l'autre, pour montrer que ça n'a aucune importance d'avoir des noms et arborescences différentes sur les briques.

On va créer un volume miroir nommé "volume1", avec 2 replicas, en utilisant le transport tcp :
# gluster volume create volume1 replica 2 transport tcp brick1:/Gluster/Volumes/Volume1 brick2:/gluster/volumes/volume1
Replica 2 volumes are prone to split-brain. Use Arbiter or Replica 3 to avoid this. See:
http://docs.gluster.org/en/latest/Administrator%20Guide/Split%20brain%20and%20ways%20to%20deal%20with%20it/.
Do you still want to continue?
(y/n) y
volume create: volume1: success: please start the volume to access data

On voit l'avertissement disant qu'il est préférable d'avoir au moins 3 briques. Malgré tout, on créé le volume.
Pour voir :
# gluster volume list
volume1
root@emmabuntus:~# gluster volume status
Volume volume1 is not started

On voit que le volume est créé, mais pas démarré.
Pour le démarrer et vérifier :
# gluster volume start volume1
volume start: volume1: success

# gluster volume list
volume1

# gluster volume status
Status of volume: volume1
Gluster process TCP Port RDMA Port Online Pid
------------------------------------------------------------------------------
Brick brick1:/Gluster/Volumes/Volume1 49152 0 Y 1737
Brick brick2:/gluster/volumes/volume1 49152 0 Y 1925
Self-heal Daemon on localhost N/A N/A Y 1948
Self-heal Daemon on brick1 N/A N/A Y 1760

Task Status of Volume volume1
------------------------------------------------------------------------------
There are no active volume tasks

==Montage depuis un client==

Installer le package "glusterfs-client".
Monter en précisant une des briques et en indiquant le point de montage :
# mount -t glusterfs brick1:/volume1 /mnt
Ou depuis /etc/fstab :
brick1:/volume1 /mnt glusterfs defaults 0 0
A noter qu'au lieu d'utiliser le client natif gluster comme on vient de le faire, on peut aussi utiliser NFS ou CIFS/samba. Mais dans ce cas il est préférable de mettre les nœuds en cluster de type CTDB (cluster NFS) pour avoir de la haute disponibilité. C'est donc beaucoup plus contraignant.
Lors du montage, on doit indiquer le nom d'une des briques (ici brick1). Mais le client récupère ensuite la liste de toutes les briques et peut communiquer avec n'importe laquelle.

==Paramétrage du volume==

===Timeout===
Par défaut, le timeout pour qu'un client bascule d'une brique à l'autre, en cas d'indisponibilité, est de 42 secondes. Ça peut paraître très long. Voici comment le passer à 5 secondes.
# gluster volume set volume1 network.ping-timeout 5

===Limiter les accès===
Pour limiter l'accès d'un volume aux machines du réseau 10.34.210.0/24 :
# gluster volume set volume1 auth.allow 10.34.210.*
On peut mettre plusieurs ips ou réseaux en les séparant par des virgules.
Pour revenir au comportement par défaut, il faut autoriser "*".
A l'inverse, on peut autoriser tout le monde, sauf des ips, avec le paramètre '''auth.reject'''.
Dans ce cas, pour revenir au comportement par défaut, on va rejeter "NONE".

===Quotas===
On peut activer des quotas pour le volume au niveau des sous-répertoires.
Il faut d'abord activer les quotas :
# gluster volume quota volume1 enable
Puis on défini la valeur :
# gluster volume quota volume1 limit-usage /sous-repertoire 100M
Pour voir l'état des quotas :
# gluster volume quota volume1 list

===Corbeille===
On peut activer une corbeille pour conserver les fichiers supprimés. On peut également limiter la taille aux fichiers de moins de 10Mo.
# gluster volume set volume1 features.trash on
# gluster volume set volume1 features.trash-dir "Poubelle"
# gluster volume set volume1 features.trash-max-falesize 10485760
On peut également activer la corbeille pour les opérations internes comme "rebalance" (par défaut à off) :
# gluster volume set volume1 features.trash-internal-op on

=Administration courante=

==Retirer une brique==

Si on veut retirer une brique.
# gluster peer detach ma_brique

==Remplacement d'une brique (si panne par exemple)==

Nous avons actuellement un trusted pool composé des deux briques brick1 et brick2.

Supposons que brick1 est tombée en panne et n'est pas réparable. On a préparé un nouveau serveur "brick3" et on installé les packages comme expliqué aux chapitres 3.1 et 3.2. Il faut aussi avoir préparé une arborescence /Gluster/Volumes/Volume1 ou équivalente pour accueillir le volume.

Connectons-nous sur brick2 et ajoutons brick3 au trusted-pool :
# gluster peer probe brick3

Maintenant on remplace brick1 par brick3 dans la config du volume "volume1" :
# gluster volume replace-brick volume1 brick1:/Gluster/Volumes/Volume1 brick3:/Gluster/Volumes/Volume1 commit force

On réconcilie le volume :
# gluster volume heal volume1 full

Depuis la nouvelle brique brick3, on synchronise le volume en récupérant les infos de brick2 :
root@brick3 # gluster volume sync brick2 volume1

Il faut ensuite récupérer le volume id depuis les attributs étendus du serveur brick2, pour ensuite les recopier sur brick3.

Récupération volume id :
root@brick2 # getfattr -n trusted.glusterfs.volume-id /gluster/volumes/volume1/
fichier-depuis-client.rien .glusterfs/
[root@centos8-fred ~]# getfattr -n trusted.glusterfs.volume-id /gluster/volumes/volume1/
getfattr: Removing leading '/' from absolute path names
# file: gluster/volumes/volume1/
trusted.glusterfs.volume-id=0s2M71q2FpQoi19v6sUcnyqw==

Recopie volume id sur brick3 :
root@brick3 # setfattr -n trusted.glusterfs.volume-id -v '0s2M71q2FpQoi19v6sUcnyqw==' /Gluster/Volumes/Volume1/

Il ne reste plus qu'à retirer brick1 du trusted pool :
# gluster peer detach brick1

==Étendre un volume==

Actuellement, notre volume1 est sur un volume répliqué sur un cluster à 2 briques. On peut le voir avec la commande suivante :
# gluster volume info volume1 |egrep "Type|Number"
Type: Replicate
Number of Bricks: 1 x 2 = 2

Pour l'étendre, on peut agrandir les volumes sur chaque brique, si c'est possible. Sinon, on peut aussi ajouter des briques. C'est ce qu'on va faire ici. A noter qu'il faut ajouter un nombre de briques proportionnel au nombre de replicas, donc ici 2. Ou alors il faut modifier le nombre de replicas, c’est ce qu’on va voir au chapitre suivant « ajouter un replica ».

On va donc créer deux nouveaux serveurs brick3 et brick4, y installer les packages nécessaires et démarrer les services (voir chapitres 3.1 et 3.2).

On les ajoute au trusted pool depuis une des briques existantes :
brick1# gluster peer probe brick3
brick1# gluster peer probe brick4

Sur brick3 et brick4 on créé un point de montage /gluster/volumes/ avec un sous-répertoire volume1, comme présenté au chapitre 3.4.

Pour finir, on va ajouter les volumes des nouvelles briques à volume1 :
brick1# gluster volume add-brick volume1 brick3:/gluster/volumes/volume1 brick4:/gluster/volumes/volume1

On voit qu'on a maintenant un volume distribué-répliqué à 4 briques :
# gluster volume info volume1 |egrep "Type|Number"
Type: Distributed-Replicate
Number of Bricks: 2 x 2 = 4

Côté client, l'espace disque a doublé (si les volumes sont tous de taille identique).

Par contre, si on a étendu le volume parce que les montages étaient pleins sur brick1 et 2, alors c'est toujours le cas. Car l'ajout de briques ne réparti pas automatiquement les données sur l'ensemble des briques. On va donc le forcer avec la commande :
# gluster volume rebalance volume1 start

Et on peut voir la progression avec la commande :
# gluster volume rebalance volume1 status

==Ajouter un replica==

Repartons de la situation de départ ou volume1 était réparti uniquement sur 2 briques : brick1 et brick2. On va ajouter une brique brick3. Comme c’est un volume répliqué, ça va ajouter une brique répliquée, on va donc passer le replica à 3. Ça permettra de permettre la perte de 2 serveurs, mais n’augmentera pas la volumétrie. La syntaxe est la suivante.
# gluster volume add-brick volume1 replica 3 ubuntu-fred:/gluster/volumes/volume1

On vérifie que ça a fonctionné :
# gluster volume info volume1 |grep "Number of Bricks"
Number of Bricks: 1 x 3 = 3

==Infos détaillées et perfs==

root@debian-fred:~# gluster volume profile volume1 info
Brick: brick1:/Gluster/Volumes/Volume1
-------------------------------------------
Cumulative Stats:
%-latency Avg-latency Min-Latency Max-Latency No. of calls Fop
--------- ----------- ----------- ----------- ------------ ----
0.00 0.00 us 0.00 us 0.00 us 3 RELEASEDIR

Duration: 251 seconds
Data Read: 0 bytes
Data Written: 0 bytes

Interval 1 Stats:

Duration: 32 seconds
Data Read: 0 bytes
Data Written: 0 bytes

Brick: brick2:/gluster/volumes/volume1
--------------------------------------------
Cumulative Stats:
%-latency Avg-latency Min-Latency Max-Latency No. of calls Fop
--------- ----------- ----------- ----------- ------------ ----
0.00 0.00 us 0.00 us 0.00 us 3 RELEASEDIR

Duration: 252 seconds
Data Read: 0 bytes
Data Written: 0 bytes

Interval 1 Stats:

Duration: 32 seconds
Data Read: 0 bytes
Data Written: 0 bytes

=Comparaison avec Ceph=

https://www.ionos.fr/digitalguide/serveur/know-how/glusterfs-vs-ceph/

GlusterFS

2021-12-13T10:42:38Z

AdminWiki : Création initiale suite

[[Category:linux]]

=Présentation=

GlusterFS est un système de fichiers distribué, accessible par le réseau, en mode clients/serveurs.

On doit utiliser des systèmes de fichiers avec attributs étendus, comme XFS, ext4, ext3, ext2, ZFS, ReiserFS, btrfs et beaucoup d’autres. XFS est recommandé (https://docs.gluster.org/en/v3/Install-Guide/Common_criteria/).

Chaque serveur s’appelle un nœud ou brique. En réalité, une brique est le filesystem dédié à GlusterFS sur un nœud. Mais par abus de langage, dans la plupart des docs qu’on trouve, les nœuds sont appelés briques.

Minimum 2 briques. En réalité on peut en n’avoir qu’une, mais ça n’a aucun intérêt, autant faire un serveur NFS dans ce cas.

Il n'y a pas de notion maître/esclave.

Chaque fois qu'on ajoute une brique, le système devient plus performant.

Plusieurs types de volumes :

=Mise en place=

Gluster stocke ses fichiers de conf dynamiquement dans '''/var/lib/glusterd'''. Si jamais le filesystem se rempli, ça pourrait rendre le service instable, voire le planter complètement. Il est donc conseillé de le séparer de /var/log, voire de le mettre tout seul.

==Installation des packages==

Exemple sur Debian10 :
# apt install glusterfs-server -y
# systemctl enable --now glusterd

Exemple sur CentOS 8 :
# dnf install centos-release-gluster -y
# dnf install -y glusterfs-server
# systemctl enable --now glusterd glusterfsd

==Ouverture des flux==

Sur CentOS 8, ou une autre distribution avec firewalld actif, il faut ouvrir le service glusterfs :
# firewall-cmd --zone=public --add-service=glusterfs
# firewall-cmd --zone=public --add-service=glusterfs --permanent

Ce service inclus les ports suivants : 24007/tcp, 24008/tcp, 24009/tcp, 38465/tcp, 38466/tcp, 38467/tcp, 38468/tcp, 38469/tcp et la plage 49152-49664/tcp.

A noter que cette liste me paraît très large. Sur le site de glusterfs, pour la 3.7.0 beta 1, ils ne parlent que de 24007/tcp, 24008/tcp et 49152 à 49156/tcp ([[https://docs.gluster.org/en/release-3.7.0beta1/Administrator%20Guide/Setting%20Up%20Clients/]]).

==Trusted pool==

Supposons que nous avons deux briques : brick1 et brick2.

Une fois que les briques sont installées, il faut les associer. Les briques se reconnaissent au sein de ce qu'on appelle un trusted pool.

Pour cela, aller sur une des briques, par exemple brick1, et taper :
brick1# gluster peer probe brick2
peer probe : success.

Pour vérifier :
# gluster peer status
Number of Peers: 1

Hostname: brick2
Uuid: 2b5f991b-8a43-43fc-836b-f6292157489a
State: Peer in Cluster (Connected)

Pour afficher la liste de briques :
# gluster pool list
UUID Hostname State
2b5f991b-8a43-43fc-836b-f6292157489a brick2 Connected
9189775d-c84f-48a8-93bc-85e3a10af75d localhost Connected

Si on veut supprimer une brique du pool :
# gluster peer detach brick2

==Création d'un volume répliqué==

Sur brick1, on a créé un point de montage /Gluster/Volumes en XFS.
Sur brick2, on a créé un point de montage /gluster/volumes en ext4.

On ne peut pas créer de volume directement sur un point de montage, donc on va créer des sous-répertoires.

Sur brick1, on créé /Gluster/Volumes/Volume1.
Sur brick2, on créé /gluster/volumes/volume1.

J'ai fait exprès de mettre des majuscules d'un côté et des minuscules de l'autre, pour montrer que ça n'a aucune importance d'avoir des noms et arborescences différentes sur les briques.

On va créer un volume miroir nommé "volume1", avec 2 replicas, en utilisant le transport tcp :
# gluster volume create volume1 replica 2 transport tcp brick1:/Gluster/Volumes/Volume1 brick2:/gluster/volumes/volume1
Replica 2 volumes are prone to split-brain. Use Arbiter or Replica 3 to avoid this. See:
http://docs.gluster.org/en/latest/Administrator%20Guide/Split%20brain%20and%20ways%20to%20deal%20with%20it/.
Do you still want to continue?
(y/n) y
volume create: volume1: success: please start the volume to access data

On voit l'avertissement disant qu'il est préférable d'avoir au moins 3 briques. Malgré tout, on créé le volume.
Pour voir :
# gluster volume list
volume1
root@emmabuntus:~# gluster volume status
Volume volume1 is not started

On voit que le volume est créé, mais pas démarré.
Pour le démarrer et vérifier :
# gluster volume start volume1
volume start: volume1: success

# gluster volume list
volume1

# gluster volume status
Status of volume: volume1
Gluster process TCP Port RDMA Port Online Pid
------------------------------------------------------------------------------
Brick brick1:/Gluster/Volumes/Volume1 49152 0 Y 1737
Brick brick2:/gluster/volumes/volume1 49152 0 Y 1925
Self-heal Daemon on localhost N/A N/A Y 1948
Self-heal Daemon on brick1 N/A N/A Y 1760

Task Status of Volume volume1
------------------------------------------------------------------------------
There are no active volume tasks

==Montage depuis un client==

Installer le package "glusterfs-client".
Monter en précisant une des briques et en indiquant le point de montage :
# mount -t glusterfs brick1:/volume1 /mnt
Ou depuis /etc/fstab :
brick1:/volume1 /mnt glusterfs defaults 0 0
A noter qu'au lieu d'utiliser le client natif gluster comme on vient de le faire, on peut aussi utiliser NFS ou CIFS/samba. Mais dans ce cas il est préférable de mettre les nœuds en cluster de type CTDB (cluster NFS) pour avoir de la haute disponibilité. C'est donc beaucoup plus contraignant.
Lors du montage, on doit indiquer le nom d'une des briques (ici brick1). Mais le client récupère ensuite la liste de toutes les briques et peut communiquer avec n'importe laquelle.

==Paramétrage du volume==

===Timeout===
Par défaut, le timeout pour qu'un client bascule d'une brique à l'autre, en cas d'indisponibilité, est de 42 secondes. Ça peut paraître très long. Voici comment le passer à 5 secondes.
# gluster volume set volume1 network.ping-timeout 5

===Limiter les accès===
Pour limiter l'accès d'un volume aux machines du réseau 10.34.210.0/24 :
# gluster volume set volume1 auth.allow 10.34.210.*
On peut mettre plusieurs ips ou réseaux en les séparant par des virgules.
Pour revenir au comportement par défaut, il faut autoriser "*".
A l'inverse, on peut autoriser tout le monde, sauf des ips, avec le paramètre '''auth.reject'''.
Dans ce cas, pour revenir au comportement par défaut, on va rejeter "NONE".

===Quotas===
On peut activer des quotas pour le volume au niveau des sous-répertoires.
Il faut d'abord activer les quotas :
# gluster volume quota volume1 enable
Puis on défini la valeur :
# gluster volume quota volume1 limit-usage /sous-repertoire 100M
Pour voir l'état des quotas :
# gluster volume quota volume1 list

===Corbeille===
On peut activer une corbeille pour conserver les fichiers supprimés. On peut également limiter la taille aux fichiers de moins de 10Mo.
# gluster volume set volume1 features.trash on
# gluster volume set volume1 features.trash-dir "Poubelle"
# gluster volume set volume1 features.trash-max-falesize 10485760
On peut également activer la corbeille pour les opérations internes comme "rebalance" (par défaut à off) :
# gluster volume set volume1 features.trash-internal-op on

=Administration courante=

==Retirer une brique==

Si on veut retirer une brique.
# gluster peer detach ma_brique

==Remplacement d'une brique (si panne par exemple)==

Nous avons actuellement un trusted pool composé des deux briques brick1 et brick2.

Supposons que brick1 est tombée en panne et n'est pas réparable. On a préparé un nouveau serveur "brick3" et on installé les packages comme expliqué aux chapitres 3.1 et 3.2. Il faut aussi avoir préparé une arborescence /Gluster/Volumes/Volume1 ou équivalente pour accueillir le volume.

Connectons-nous sur brick2 et ajoutons brick3 au trusted-pool :
# gluster peer probe brick3

Maintenant on remplace brick1 par brick3 dans la config du volume "volume1" :
# gluster volume replace-brick volume1 brick1:/Gluster/Volumes/Volume1 brick3:/Gluster/Volumes/Volume1 commit force

On réconcilie le volume :
# gluster volume heal volume1 full

Depuis la nouvelle brique brick3, on synchronise le volume en récupérant les infos de brick2 :
root@brick3 # gluster volume sync brick2 volume1

Il faut ensuite récupérer le volume id depuis les attributs étendus du serveur brick2, pour ensuite les recopier sur brick3.

Récupération volume id :
root@brick2 # getfattr -n trusted.glusterfs.volume-id /gluster/volumes/volume1/
fichier-depuis-client.rien .glusterfs/
[root@centos8-fred ~]# getfattr -n trusted.glusterfs.volume-id /gluster/volumes/volume1/
getfattr: Removing leading '/' from absolute path names
# file: gluster/volumes/volume1/
trusted.glusterfs.volume-id=0s2M71q2FpQoi19v6sUcnyqw==

Recopie volume id sur brick3 :
root@brick3 # setfattr -n trusted.glusterfs.volume-id -v '0s2M71q2FpQoi19v6sUcnyqw==' /Gluster/Volumes/Volume1/

Il ne reste plus qu'à retirer brick1 du trusted pool :
# gluster peer detach brick1

==Étendre un volume==

Actuellement, notre volume1 est sur un volume répliqué sur un cluster à 2 briques. On peut le voir avec la commande suivante :
# gluster volume info volume1 |egrep "Type|Number"
Type: Replicate
Number of Bricks: 1 x 2 = 2

Pour l'étendre, on peut agrandir les volumes sur chaque brique, si c'est possible. Sinon, on peut aussi ajouter des briques. C'est ce qu'on va faire ici. A noter qu'il faut ajouter un nombre de briques proportionnel au nombre de replicas, donc ici 2. Ou alors il faut modifier le nombre de replicas, c’est ce qu’on va voir au chapitre suivant « ajouter un replica ».

On va donc créer deux nouveaux serveurs brick3 et brick4, y installer les packages nécessaires et démarrer les services (voir chapitres 3.1 et 3.2).

On les ajoute au trusted pool depuis une des briques existantes :
brick1# gluster peer probe brick3
brick1# gluster peer probe brick4

Sur brick3 et brick4 on créé un point de montage /gluster/volumes/ avec un sous-répertoire volume1, comme présenté au chapitre 3.4.

Pour finir, on va ajouter les volumes des nouvelles briques à volume1 :
brick1# gluster volume add-brick volume1 brick3:/gluster/volumes/volume1 brick4:/gluster/volumes/volume1

On voit qu'on a maintenant un volume distribué-répliqué à 4 briques :
# gluster volume info volume1 |egrep "Type|Number"
Type: Distributed-Replicate
Number of Bricks: 2 x 2 = 4

Côté client, l'espace disque a doublé (si les volumes sont tous de taille identique).

Par contre, si on a étendu le volume parce que les montages étaient pleins sur brick1 et 2, alors c'est toujours le cas. Car l'ajout de briques ne réparti pas automatiquement les données sur l'ensemble des briques. On va donc le forcer avec la commande :
# gluster volume rebalance volume1 start

Et on peut voir la progression avec la commande :
# gluster volume rebalance volume1 status

==Ajouter un replica==

Repartons de la situation de départ ou volume1 était réparti uniquement sur 2 briques : brick1 et brick2. On va ajouter une brique brick3. Comme c’est un volume répliqué, ça va ajouter une brique répliquée, on va donc passer le replica à 3. Ça permettra de permettre la perte de 2 serveurs, mais n’augmentera pas la volumétrie. La syntaxe est la suivante.
# gluster volume add-brick volume1 replica 3 ubuntu-fred:/gluster/volumes/volume1

On vérifie que ça a fonctionné :
# gluster volume info volume1 |grep "Number of Bricks"
Number of Bricks: 1 x 3 = 3

==Infos détaillées et perfs==

root@debian-fred:~# gluster volume profile volume1 info
Brick: brick1:/Gluster/Volumes/Volume1
-------------------------------------------
Cumulative Stats:
%-latency Avg-latency Min-Latency Max-Latency No. of calls Fop
--------- ----------- ----------- ----------- ------------ ----
0.00 0.00 us 0.00 us 0.00 us 3 RELEASEDIR

Duration: 251 seconds
Data Read: 0 bytes
Data Written: 0 bytes

Interval 1 Stats:

Duration: 32 seconds
Data Read: 0 bytes
Data Written: 0 bytes

Brick: brick2:/gluster/volumes/volume1
--------------------------------------------
Cumulative Stats:
%-latency Avg-latency Min-Latency Max-Latency No. of calls Fop
--------- ----------- ----------- ----------- ------------ ----
0.00 0.00 us 0.00 us 0.00 us 3 RELEASEDIR

Duration: 252 seconds
Data Read: 0 bytes
Data Written: 0 bytes

Interval 1 Stats:

Duration: 32 seconds
Data Read: 0 bytes
Data Written: 0 bytes

=Comparaison avec Ceph=

[[https://www.ionos.fr/digitalguide/serveur/know-how/glusterfs-vs-ceph/]]

GlusterFS

2021-12-13T10:30:51Z

AdminWiki : Création initiale

MediaWiki:Sidebar

2021-12-13T10:20:37Z

AdminWiki :

* Éléments du menu
* Linux
** Linux présentation|présentation
** Accéder à des partitions BSD sous Linux|accéder à des partitions BSD sous Linux
** Ajout de disques à chaud - linux|ajout de disques à chaud
** Apache|apache
** Apt-get|apt-get
** Arborescence des répertoires|arborescence des répertoires
** Bande passante - linux|Bande passante
** Bash - les commandes| bash - les commandes
** Les scripts bash|bash - les scripts
** Clamav - antivirus|Clamav - antivirus
** Configurer / compiler le noyau|configurer / compiler le noyau
** Controle de ressources - Linux|Controle de ressources
** Daemon - syntaxe|Daemon - syntaxe
** ftp washington|ftp washington
** Introduction à gcc/g++|gcc/g++ - introduction
** GlusterFS|GlusterFS
** Les lecteurs de bande sous linux|lecteurs de bande
** Les logiciels|logiciels
** Logrotate|logrotate
** Mandriva - utilisation de URPM|Mandriva - urpm
** proftpd|proftpd
** postfix|postfix
** Protéger un fichier avec un mot de passe (avec gpg)|protéger un fichier avec un mot de passe (avec gpg)
** Puppet|puppet
** Les packages RPM|rpm
** Rsync|Rsync
** Samba - serveur d'impression|Samba - serveur d'impression
** Sauvegarder et partitionner son disque dur (Partimage & QTParted)|sauvegarder et partitionner son disque dur (Partimage & QTParted)
** Sécurité - iptables|sécurité - iptables
** sendmail|sendmail
** Single user - linux|single user
** SVN - Subversion|SVN - Subversion
** Systemd|Systemd
** Tar et cpio|tar et cpio
** Tcpdump|Tcpdump
** Trucs & astuces|trucs & astuces
** Déterminer le type de FS|type de filesystem
** Vi|vi
** Yum|yum

* Solaris
** Solaris présentation|présentation
** Booter en mode maintenance|booter en mode maintenance
** Solaris - Consommation de ressources|Consommation de ressources
** Controle de ressources - Solaris|Controle de ressources
** Création d'un compte utilisateur|création d'un compte utilisateur
** Date d'installation - Solaris|date d'installation
** Disques durs et systèmes de fichiers|Disques durs et systèmes de fichiers
** Du - script - Solaris|du - script
** En cas d'appel au support : explorer|En cas d'appel au support : explorer
** Erreurs matérielles - Solaris|Erreurs matérielles
** Faire une copie d'un disque|Faire une copie d'un disque
** Faire une installation avec Jumpstart|Faire une installation avec Jumpstart
** ftp washington|ftp washington
** Gestion du swap|Gestion du swap
** Impression - Solaris|Impression
** Informations sur le matériel|Informations sur le matériel
** Les logs|Les logs
** Monter une image iso - Solaris|Monter une image iso
** NFS - Solaris|NFS
** OBP (Open Boot Prom) et NVRAM|OBP (Open Boot Prom) et NVRAM
** Oracle VM Server (LDOM)|Oracle VM Server (LDOM)
** Packages - Solaris|Packages
** Password - solaris|Password
** Patch - Solaris|Patch
** proftpd|proftpd
** Quel process écoute sur un port|Quel process écoute sur un port
** Réseau- Solaris|Réseau Solaris 8,9,10
** Réseau Solaris 11|Réseau Solaris 11
** SAN - Solaris|SAN
** Services - Solaris|Services
** Solaris Volume Manager (SVM)|Solaris Volume Manager (SVM)
** Tcpdump|Tcpdump
** Déterminer le type de FS|type de filesystem
** Veritas Volume Manager (VxVM)|Veritas Volume Manager (VxVM)
** Version de Solaris|Version de Solaris
** XSCF|XSCF
** ZFS|ZFS
** Zombie|Zombie
** Zones - Solaris|Zones

* BSD
** BSD présentation|présentation
** Accéder à des partitions BSD sous Linux|Accéder à des partitions BSD sous Linux
** Tcpdump|Tcpdump

* AIX
** AIX - Présentation|Présentation
** Arrêt - relance - AIX|Arrêt - relance
** Backups - AIX|Backups
** Erreur matérielle - AIX|Erreur matérielle
** LVM - AIX|LVM
** Packages - AIX|Packages
** Process - classer par conso cpu - AIX|Process - classer par conso cpu
** Process - classer par conso mémoire - AIX|Process - classer par conso mémoire
** proftpd|proftpd
** Réseau - AIX|Réseau
** RPM - AIX|RPM
** Services - AIX|Services

* HP-UX
** HP-UX|HP-UX

* Windows
** Windows|Windows

* Nagios
** Nagios|Nagios
** Installation de nagios|Installation
** Event_handler|event_handler
** Scripts nagios - exemples|Exemples de scripts
** pnp4nagios|pnp4nagios
** Pnp4nagios - Template|pnp4nagios-template
** Installation de Shinken|Shinken - Installation

* MySQL
** Administration de MySQL|Administration de MySQL
** Perte du mot de passe root - MySQL|Perte du mot de passe root
** Sauvegardes - MySQL|Sauvegardes
** MySQL - Tâches courantes|Tâches courantes
** Vérifier et réparer les tables - MySQL|Vérifier et réparer les tables

* PHP
** Afficher la date au format "dd-mmmm-yyyy" - PHP|Afficher la date au format "dd-mmmm-yyyy"
** Faire une galerie d'images - PHP|Galerie d'images
** Liens - PHP|Liens
** Scanner une plage d'adresses ip - PHP|Scanner une plage d'adresses ip

* Perl
** Perl|Perl
** Perl - exemples|Exemples

* Divers
** Baie de disques HP MSA1OOO - Command Line Interface (CLI)|Baie de disques HP MSA1OOO - Command Line Interface (CLI)
** Liens|Liens

* M'écrire
** mailto:unixmaniax@gmail.com|M'envoyer un email

Tcpdump

2021-07-30T14:04:18Z

AdminWiki : /* Exemples */

[[Category: Linux]]
[[Category: Solaris]]
[[Category: BSD]]

==Présentation==

Tcpdump est un utilitaire en ligne de commande qui permet de sniffer les paquets entrants et sortant sur les interfaces réseau.

On peut lui passer de nombreuses options et paramètres pour affiner les résultats. On peut voir les détails dans [http://www.tcpdump.org/tcpdump_man.html la page man]. La syntaxe est riche, mais peut vite devenir compliquée. Je vais juste présenter quelques exemples pratiques.

==Exemples==

* capturer ce qui arrive et sort sur l'interface principale :
tcpdump
(on peut ajouter les options -v ou -vv pour augmenter la verbosité
* ne capturer que ce qui transite sur l'interface eth1 :
tcpdump -i eth1
* ne capturer que ce qui transite sur l'interface eth1 et qui transite vers ou depuis l'hôte "serveur1" :
tcpdump -i eth1 host serveur1
* idem, mais n'affiche que ce qui transite via tcp :
tcpdump -i eth1 host serveur1 and tcp
* idem pour tcp ou icmp :
tcpdump -i eth1 host ubuntu-virt and tcp or icmp
* ne scanner que ce qui transite par les port tcp 22 et 23 :
tcpdump tcp port 22 or 23
* écrire le résultat dans un fichier pcap, pour une analyse précise avec wireshark :
tcpdump -i eth1 host serveur1 -w /tmp/fichier.pcap

Veritas Volume Manager (VxVM)

2021-07-12T13:37:03Z

AdminWiki : /* Vérifier l'espace restant sur un volume */

[[Category:solaris]]

=Introduction=

"Veritas Volume Manager" (ou VxVM) est un gestionnaire de volumes logiques propriétaire et payant, disponible pour de nombreux systèmes Unix, et même pour Windows. En France, on le trouve à peu près une fois sur deux sur les systèmes Solaris, à la place du gestionnaire de volumes logiques de Sun, "Solaris Volume Manager" ou "SVM" (anciennement "Solstice Disk Suite"), qui lui, est offert avec Solaris.

Par rapport à SVM et à beaucoup d'autres concurrents, VxVM apporte :

* pas de problème de nombre d'Inodes : il sont illimités sur VxVM
* transforme le niveau de Raid à chaud
* possibilité d'ajouter une patte en stripping (raid 0) à chaud
* réduction à chaud des partitions (uniquement si elles ont été formattées en VxFS – système de fichiers Veritas. Ne marche pas avec UFS – système de fichiers par défaut de Solaris).

Certains passages sont illustrés d'exemples ; ces exemples sont tirés d'un serveur Solaris 8 HW 7/03 avec Veritas Volume Manager 3.5.

Précision : cet article est issu de mon expérience personnelle, sur le "terrain", sans avoir reçu de "vraie" formation. Mais certaines commandes m'ont été données par des spécialistes du sujet. Aussi, les méthodes que j'utilise ne sont peut-être pas les meilleures, mais elles fonctionnent.

=Installation=

==Avant d'installer==

Avant de commencer quoique ce soit, il est préférable de faire une sauvegarde des données, et surtout une copie du disque système, surtout si des patchs sont nécessaires.

===Licence===

Veritas Volume Manager s'installe avec une clé de licence. Pour obtenir cette clé de licence, il faut contacter Sun (si vous avez acheté la licence chez eux) et leur fournir :

* le product name (inscrit sur le certificat de licence fournit avec le cd)
* le numéro de série (inscrit sur le certificat de licence fournit avec le cd)
* l'adresse de votre société
* un contact dans votre société (nom + téléphone + mail)
* le hostid du serveur (taper hostid sous Solaris)

===Préparation des disques durs===

Lorsqu'on met un disque dur sous contrôle de VxVM, on peut encapsuler ou non. Ne pas encapsuler signifie mettre le disque sous contrôle de VxVM en supprimant tout ce qui est dessus, ce qui ne nécessite aucun prérequis. Encapsuler signifie qu'on rajoute la couche VxVM sur un disque en conservant les données existantes, ce qui implique quelques prérequis. Pour qu'un disque soit "encapsulable", il faut qu'il ait deux partitions de libres au sens "format" du terme ; c'est à dire qu'il doit y avoir deux slices inutilisées et quelques Mo de non alloués aux autres slices (à prioris, un ou deux cylindres suffisent).

Ces deux slices seront ensuite utilisés par VxVM et taggués 14 et 15 (visible en faisant prtvtoc /dev/rdsk/cxtydzs2). La partition 15 est la "private", que VxVM utilise pour son fonctionnement interne. La 14 est la "public" qui couvre tout le disque (à l'identique de la slice 2 pour Solaris) et qui représente les données.

==Patcher Solaris==

Installer les patchs Sun Solaris pré-requis à l'installation des packages Veritas. Ces patchs dépendent de la version de Solaris, de la version de Veritas Volume Manager et des patchs déjà installés. Ils sont détaillés dans la documentation d'installation de Veritas Volume Manager fournie avec le cd d'installation. Les détails dépassent le cadre de ce document.

Avant de passer à la suite, il est préférable de rebooter le serveur et de vérifier que le serveur se comporte correctement, car certains patchs peuvent apporter des problèmes.

==Installer les packages Veritas Volume Manager==

Cette étape est facultative : si on ne la rentre pas tout de suite, elle sera demandée plus tard. Pour entrer la clé, taper la commande '''vxlicinst'''.

# vxlicinst

VERITAS License Manager vxlicinst utility version 3.00.007d
Copyright (C) VERITAS Software Corp 2002. All Rights reserved.

Enter your license key : XXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXX

License key successfully installed for VERITAS Volume Manager

==Installer / configurer Veritas==

Taper la commande vxinstall et suivre les instructions en répondant aux questions (des explications sont données au fur et à mesure). Il est conseillé de choisir "custom installation". Si on veut mettre le disque système sous contrôle de VxVM, il faut répondre "yes" à la question "Encapsulate boot disk ?". Pour cela, il faut que le disque soit "encapsulable" (voir chapitre ''Préparation des disques durs'').

Une fois l'installation terminée, il faudra rebooter le serveur. Ça sera l'occasion de vérifier que rien n'a été cassé par l'installation, et que tout démarre bien dans le cas où on a encapsulé le système.

=Mirrorer le disque système=

==Présentation==

Pour des raisons évidentes de sécurité, il est intéressant de faire un miroir du disque système. Le miroir étant un miroir logiciel géré par VxVM, il est bien sûr impératif que le disque système soit déjà sous contrôle de VxVM.

Dans l'explication qui suit, on considère que le disque système est '''c0t0d0''' et que le disque miroir est '''c0t2d0'''.

==Créer le mirroir==

Voici les différentes étapes :

* ajouter un nouveau disque dans le serveur
* vérifier avec format qu'il est bien reconnu par Solaris. S'il ne l'est pas, forcer la reconnaissance du nouveau matériel avec "devfsadm -v".
* vérifier qu'il est vu par VxVM avec "vxdisk list". S'il ne l'est pas, taper les commandes suivantes "drvconfig", puis "disks", puis "vxdctl enable". Vérifier que cette fois il est bien reconnu.
* mettre le nouveau disque sous contrôle de VxVM, l'appeler "rootmir" et le faire appartenir au même disk group (dg) que le disque système (si on a conservé les choix par défaut, le disque système s'appelle "rootdisk" et appartient au groupe "rootdg"). La commande à utiliser est "vxdiskadd c0t2d0" ; il suffit de répondre aux questions.
* Mirrorer les disques avec la commande interactive "vxdiskadm" :
** dans le menu, valider le choix "6 Mirror volumes on a disk"
** faire "list" pour vérifier qu'on voit bien "rootdisk" et "rootmir"
** lorsqu'il demande le disque à mirrorer, lui dire "rootdisk"
** lorsqu'il demande le disque de destination, lui dire "rootmir"
** confirmer. Il va alors mirrorer chaque volume existant d'un disque à l'autre, en affichant la progression.

On peut taper les commandes "'''prtvtoc /dev/rdsk/c0t2d0s2'''" pour vérifier que les tags 14 et 15 ont été créés, preuve que le disque est sous contrôle de VxVM.

# prtvtoc /dev/rdsk/c0t2d0s2
* /dev/rdsk/c0t2d0s2 partition map
*
* Dimensions:
* 512 bytes/sector
* 135 sectors/track
* 16 tracks/cylinder
* 2160 sectors/cylinder
* 3882 cylinders
* 3880 accessible cylinders
*
* Flags:
* 1: unmountable
* 10: read-only
*
* Unallocated space:
* First Sector Last
* Sector Count Sector
* 2095200 4292874256 2159
* 8380800 4288681696 2095199
* 3144960 615600 3760559
* 7497360 883440 8380799
*
* First Sector Last
* Partition Tag Flags Sector Count Sector Mount Directory
0 2 00 2160 2093040 2095199
1 3 01 2095200 1049760 3144959
2 5 01 0 8380800 8380799
3 15 01 0 2160 2159
4 14 01 2160 8378640 8380799
6 4 00 3760560 2097360 5857919
7 7 00 5857920 1639440 7497359

==Configurer l'Openboot Prom (OBP)==

Maintenant, il va falloir configurer l'OBP pour pouvoir booter sur l'un ou l'autre des disques. Pour cela, on va créer des alias "'''rootdisk'''" et "'''rootmir'''" qui vont pointer respectivement sur le disque principal et le mirroir.

Pour commencer, sous Solaris, il faut repérer le chemin long des deux devices :

# ls -l /dev/rdsk/c0t0d0s2 /dev/rdsk/c0t2d0s2
lrwxrwxrwx 1 root root 45 Oct 27 15:31 /dev/rdsk/c0t0d0s2 -> ../../devices/pci@1f,4000/scsi@3/sd@0,0:c,raw
lrwxrwxrwx 1 root other 45 Oct 27 15:31 /dev/rdsk/c0t2d0s2 -> ../../devices/pci@1f,4000/scsi@3/sd@2,0:c,raw

La partie à retenir, pour cet exemple, est "'''/pci@1f,4000/scsi@3/sd@0,0'''" et "'''/pci@1f,4000/scsi@3/sd@2,0'''", c'est à dire le chemin sans "'''../../devices'''" au début et sans "''':'''" et les caractères suivants à la fin. Si on a oublié de les noter, on pourra les retrouver dans l'OBP en tapant '''devalias''' et en repérant les disques "'''disk 0'''" et "'''disk 2'''".

Ensuite, il faut rebooter le serveur pour se retrouver dans l'OBP : init 0.

Une fois dans l'OBP, taper les commandes suivantes :

setenv use-nvramrc? True
nvalias rootdisk /pci@1f,4000/scsi@3/sd@0,0
nvalias rootmir /pci@1f,4000/scsi@3/sd@2,0
setenv boot-device rootdisk rootmir
reset-all

Le serveur va alors rebooter. Par défaut, il va booter sur "'''rootdisk'''". Pour le forcer à booter sur le miroir (il est conseillé de le faire pour vérifier qu'il marche), il faut taper "'''boot rootmir'''" dans l'OBP.

=Mettre un disque non système sous contrôle de VxVM=

==Lister les disques sous contrôle de VxVM==

Avant de mettre un disque sous contrôle de VxVM, on peut s'assurer qu'il n'y est pas déjà, ou simplement regarder quels sont les autres disques gérés par VxVM. Pour cela, on utilise la commande "'''vxdisk list'''".

# vxdisk list
DEVICE TYPE DISK GROUP STATUS
c0t0d0s2 sliced rootdisk rootdg online
c0t1d0s2 sliced - - error
c0t2d0s2 sliced rootmir rootdg online
c0t3d0s2 sliced - - error
c2t0d0s2 sliced - - error
c2t3d0s2 sliced - - error
c3t3d0s2 sliced - - error

==Si le disque n'est pas vu par VxVM==

Si le disque qu'on veut ajouter est bien vu par "'''format'''", mais n'est pas listé par "'''vxdisk list'''", alors exécuter les commandes suivantes : "'''drvconfig'''", puis "'''disks'''", puis "'''vxdctl enable'''". Maintenant, "'''vxdisk list'''" doit le voir.

Détail des commandes :

* '''drvconfig''' : scanne la chaîne scsi et détecte les nouveaux disques
* '''disks''' : créé les fichiers device dans /dev
* '''vxdctl enable''' : demande à VxVM de prendre les disques en compte

Note : la méthode ci-dessus est toujours fonctionnelle, mais maintenant il faudrait plutôt utiliser '''devfsadm''' pour remplacer les deux premières commandes. Ce qui nous donne, pour faire la même chose, les deux commandes suivantes :

* '''devfsadm -Cv''' : détecte et configure les nouveaux devices (le '''C''' est facultatif, il fait un clean des devices qui n'existent plus
* '''vxdctl enable''' : demande à VxVM de prendre les disques en compte

==Mettre le disque sous contrôle de VxVM (disk group)==

La commande à utiliser est '''vxdiskadd'''. Elle a pour effet d'associer le disque à un groupe (existant ou nouveau).

vxdiskadd c2t0d0

Il va alors demander si on veut ajouter le disque à un Disk Group existant (il affiche la liste) ou si on veut en créer un nouveau (il va demander le nom).

Il faut ensuite dire si le disque doit être encapsulé ou pas. Pour rappel, encapsuler consiste à conserver les données existantes, mais nécessite que le disque soit encapsulable (voir chapitre ''Préparation des disques durs''). Si le disque ne contient pas de données, il ne faut pas encapsuler.

Il existe une autre possibilité pour faire la même chose : taper "'''vxdiskadm" et choisir "1. Add or initialize one or more disks'''" dans le menu, et répondre aux questions comme avec '''vxdiskadd'''.

Il existe même une troisième méthode entièrement en ligne de commandes qui m'a un jour sauvé la vie, car les deux autres ne fonctionnaient pas, je n'ai jamais compris pourquoi (ça m'indiquait que le disque était invalide). La voici :

vxdg -g mondg adddisk mondg05=c2t0d0

A noter que "mondg05" est le nom du disque dans le disque group. On peut choisir le nom qu'on veut du moment qu'il n'est pas déjà pris. Avec les deux premières méthodes ce nom est déterminé automatiquement (nom du dg suivi de deux chiffres).

Remarque : lorsqu'un disque est géré par VxVM, son raw device n'est plus vu comme '''/dev/rdsk/...''', mais comme '''/dev/vx/rdsk...'''. De même, le spécial devient '''/dev/vx/dsk/...'''.

=Gestion des volumes=

==Créer un volume==

Pour créer un volume (une partition logique) dans un disk group (dg), on utilise la commande vxassist. Puis on formate le volume avec newfs ou mkfs, comme pour n'importe quelle partition physique. Pour finir, il faudra l'ajouter dans /etc/vfstab.

Syntaxe :

vxassist -b -g nom_disk_group make nom_volume taille

Exemple :

vxassist -b -g dbdg make oraclelv 20g

Création d'un filesystem UFS :

newfs /dev/vx/rdsk/nom_disk_group/nom_volume

Création d'un filesystem VxFS :

mkfs -F vxfs /dev/vx/rdsk/nom_disk_group/nom_volume

Ajout de la ligne correspondante dans /etc/vfstab :

/dev/vx/dsk/nom_disk_group/nom_volume /dev/vx/rdsk/nom_disk_group/nom_volume /point_de_montage vxfs defaults 1 2

Remarque : la création d'un filesystem VxFS nécessite une licence Veritas File System.

==Vérifier l'espace restant sur un volume==

Syntaxe :

vxdg [-g groupe] free

Renvoie la taille en blocs de 512 octets (colonne OFFSET=taille utilisée, LENGTH=taille restante)

Exemple :

# vxdg -g rootdg free
DISK DEVICE TAG OFFSET LENGTH FLAGS
rootdisk c0t0d0s2 c0t0d0 71109846 11556 n
rootmir c1t0d0s2 c1t0d0 24576723 5778 -
rootmir c1t0d0s2 c1t0d0 24588278 1 -
rootmir c1t0d0s2 c1t0d0 71121402 2889 -

Voici un script qui permet d'afficher les choses de façon plus claire :
#!/bin/bash
#
# Pour tous les dg veritas existant, affiche l'espace disponible en Go
# ainsi que l'espace utilise, l'espace total et le pourcentage d'utilisation.
#
LISTE_DG=$(vxdg -q list|awk '{print $1}' |sort |uniq)

echo -e "Disk Group \t Free space \t Used space \t Total space \t Percent used"
for i in ${LISTE_DG}
do
FREE=`echo $(vxdg -qg $i free |awk '{print $5}' |tr '\n' '+') |sed "s/.*/(0+&/"| sed "s/+$/)\/2\/1024\/1024/"|bc`
TEMP=`vxdisk -qg $i -o size list 2>/dev/null |awk '{print $2}' |tr '\n' '+'`
TOTAL=`echo "($TEMP" |sed "s/+$/)\/1024/g" |bc`
USED=`echo $(($TOTAL - $FREE))`
PERCENT_USED=`echo "scale=2 ; 100*$USED/$TOTAL"|bc`
# l'ajout du "0+" est indispensable pour les DG qui n'ont plus d'espace libre, car ils n'apparaissent pas avec "vxfg free"
echo -e "$i \t\t ${FREE} Go \t ${USED} Go \t ${TOTAL} Go \t ${PERCENT_USED}%"
done

Exemple de résultat :
# ./espace_dispo_sur_dg.sh
Disk Group Free space Used space Total space Percent used
zone1-applidg 55 Go 100 Go 155 Go 64.51%
zone2-datadg 0 Go 100 Go 100 Go 100.00%
zone2-applidg 0 Go 250 Go 250 Go 100.00%
zone3-applidg 59 Go 200 Go 259 Go 77.22%

==Agrandir ou réduire un volume==

Agrandir de 4 Go :

vxresize -g nom_disk_group nom_volume +4g

Réduire de 3 Go :

vxresize -g nom_disk_group nom_volume -3g

Bien sûr, tout ça se fait à chaud, sans avoir besoin de démonter les partitions. Tout le monde peut continuer à travailler. C'est formidable !

Si vxresize n'est pas dans le PATH, le rechercher avec "grep vxresize /var/sadm/install/contents". Il est normalement dans /usr/lib/vxvm/bin/.

==Renommer un volume (et renommer ses plexes)==

Si on veut changer le nom d'un volume, utiliser la syntaxe suivante :

vxedit rename oldlv newlv

Lorsqu'on fait vxprint, on remarque que le volume possède des plexes qui lui sont associés. Les plexes sont nécessaires au fonctionnement de VxVM, mais n'ont pas vraiment d'intérêt pour l'administrateur système. Cependant, lorsqu'on créé un volume, les plexes associés sont automatiquement créés avec un nom reprenant le nom du volume, mais renommer le volume ne renomme pas les plexes. Il peut être intéressant de renommer également les plexes pour garder une cohérence, notamment quand on fait un vxprint. La syntaxe pour renommer les plexes est la suivante :

vxedit -g rootdg -p rename oldlv-01 newlv-01

==Supprimer un volume==

Syntaxe :

vxassist -g nom_groupe remove volume nom_volume

Exemple :

vxassist -g dbdg remove volume oraclelv

==Voir la liste de tous les dg==

# vxdg list
NAME STATE ID
rootdg enabled 1247755677.135.uyqev3
exploitdg enabled 1151484964.148.uyqev3
tkappli00dg enabled 1142590040.99.uyqev3
tk00dg enabled 1142591823.119.uyqev3
tk01dg enabled 1171641444.4311.bakctl01
zonedg enabled 1141381993.11.uyqev3

=Retirer un disque d'un DG=

Nous allons suivre l'exemple d'un DG qui est réparti sur deux disques. La totalité des volumes occupe moins de place que la taille d'un disque. Nous allons donc migrer les volumes d'un disque pour tous les placer sur le même disque, puis retirer le disque qui n'a plus de données. Ainsi on pourra réutiliser le disque pour autre chose.

Dans l'exemple qui suit, le DG s'appelle exampledg composé de exampledg_01 et exampledg_02.

On regarde l'espace utilisé sur chacun des disques :

# vxdg -g exampledg free
DISK DEVICE TAG OFFSET LENGTH FLAGS
exampledg exampledg_01 emcpower108s2 emcpower108 34213888 175484928 -
exampledg exampledg_02 emcpower109s2 emcpower109 134217728 75481088 -

Maintenant on va déplacer les données de exampledg_01 vers exampledg_02 :

/etc/vx/bin/vxevac -g exampledg exampledg_01 exampledg_02

Ca peut être long. On peut regarder l'avancement avec "vxtask list".

A noter qu'il n'est pas impératif de préciser le disque de destination (exampledg_02 ici). Dans ce cas, vxvm déplace les données sur un des autres disques du DG.

Une fois que c'est fini, on vérifie que tout l'espace a bien été libéré :

# vxdg -g exampledg free
DISK DEVICE TAG OFFSET LENGTH FLAGS
exampledg_01 emcpower108s2 emcpower108 0 209698816 -
exampledg_02 emcpower109s2 emcpower109 168431616 41267200 -

On peut maintenant retirer le disque du DG :

# vxdg -g exampledg rmdisk exampledg_01

Et on vérifie qu'il ne fait plus partie du DG :

# vxdg -g exampledg free
DISK DEVICE TAG OFFSET LENGTH FLAGS
exampledg_02 emcpower109s2 emcpower109 168431616 41267200 -

=Retirer un disque du contrôle de VxVM=

Pour retirer un disque, il faut d'abord avoir supprimé tous les volumes qu'il contenait (voir Supprimer un volume), et également supprimer les disk group.

==Détruire un disk group==

vxdg destroy mon_dg

==Retirer le disque==

vxdisk rm c3t0d0

Puis vérifier que ça a bien fonctionné avec :

vxdctl enable
vxdisk list

=Échanger physiquement un disque sous contrôle de VxVM=

Pour changer un disque qui est sous contrôle de VxVM (par exemple parce qu'il est en fin de vie), le principe est de :

* avertir VxVM qu'on va changer le disque
* faire une copie du disque
* remettre le disque sous contrôle de VxVM

Les détails sont ci-dessous.

==Avertir VxVM qu'on va changer le disque==

Taper "'''vxdiskadm'''", choisir l'option "'''4. Remove a disk for replacement'''" et indiquer le volume (ex: datadg01, pour le premier volume du groupe datadg).

==Faire une copie du disque==

On peut maintenant faire une copie brute du disque vers le nouveau avec dd. C'est brutal, mais ça marche.

==Remettre le disque sous contrôle de VxVM==

Taper "'''vxdiskadm'''", choisir l'option "'''5. Replace a failed or removed disk'''" et indiquer le disque (ex: c1t1d0s2).

Il arrive que cette méthode ne fonctionne pas. Dans ce cas, on peut utiliser les outils en ligne de commande :

* '''/etc/vx/bin/vxreattach -b'''
* si ça ne marche pas : '''vxdg -g datadg -k adddisk datadg01=c1t1d0s2'''
* on vérifie que les volumes sont ENABLE : '''vxprint -Ath'''
* s'ils ne sont pas ENABLE, faire : '''vxvol -g datadg startall''' et si toujours pas ENABLE, forcer avec '''vxvol -g datadg -f startall'''

Pour finir, remonter les partitions associées avec mount.

Remarque : on peut également faire plus "propre" en copiant d'abord les données du disque, en ne prenant que le contenu des volumes VxVM qui sont sur le disque en question, mais c'est plus long à expliquer et je n'ai pas encore testé.

=Export / import=

Les disk group peuvent facilement s'exporter d'un serveur pour s'importer sur un autre serveur. Voici rapidement les différentes étapes sur un dg "testdg".

==Sur le serveur source==

1/ démonter les points de montage associés au dg
umount /directories

2/ stopper les volumes
vxvol -g testdg stopall

3/ exporter le dg
vxdg deport testdg

4/ déconnecter physiquement le disque ou la LUN du serveur

==Sur le serveur cible==

5/ connecter physiquement le disque ou la LUN sur le serveur

6/ importer le dg (veritas est capable tout seul de retrouver le dg sur le nouveau volume)
vxdg import testdg

7/ démarrer tous les volumes sur le nouveau système et resynchroniser les mirroirs en arrière plan
vxrecover -g testdg -sb

8/ monter les répertoires (créer si nécessaire les points de montage et éventuellement mettre à jour la vfstab)

Et voilà. C'est à peine plus compliqué que de passer une clé usb d'un pc à un autre !

==Voir le nom des DGs importables==

Si on ne connait pas le nom du DG à importer, on peut afficher la liste des disques et du DG associé avec la commande suivante :

vxdisk -o alldgs list

Les disques qui sont sur un DG qui n'a pas été importé vont apparaître avec le nom du DG entre parenthèses.

=Les quotas=

Les quotas s'appliquent pour un utilisateur ou un groupe. Pour un fs, on fixe une limite soft et hard en nombre de blocs et/ou en nombre d'inodes.

==Afficher la valeur actuelle==
Pour afficher les quotas, on utilise la commande '''vxquota''' avec le nom ou l'uid.

vxquota -v 1399
Disk quotas for (no account) (uid 1399):
Filesystem usage quota limit timeleft files quota limit timeleft
/export/home 41304 250000 250000 33 0 0

==Modifier les valeurs==

On utilise '''vxedquota''' avec le nom ou l'uid. On se retrouve dans un editeur.

vxedquota -u 1399
==>
fs /export/home blocks (soft = 250000, hard = 250000) inodes (soft = 0, hard = 0)

=Divers=

==Afficher la licence Veritas==

On utilise la commande vxlicrep.

# vxlicrep

VERITAS License Manager vxlicrep utility version 3.00.007d
Copyright (C) VERITAS Software Corp 2002. All Rights reserved.

Creating a report on all VERITAS products installed on this system

-----------------***********************-----------------

License Key = XXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXX
Product Name = VERITAS Volume Manager
Serial Number = 9547
License Type = PERMANENT_NODE_LOCK
OEM ID = 7
Node Lock Type = (Hostid and Architecture ID)

Features :=

VxVM = Enabled
CPU Count = Not Restricted

==Gestion des largefiles (fichiers de plus de 2 Go)==

Avec VxFS, on peut activer ou désactiver la gestion des fichiers de plus de 2 Go. C'est l'option "'''largefiles'''" qui gère ça. Cette option se met à la création du filesystem, mais peut bien sûr s'activer ou se désactiver à chaud... Il n'y a donc rien à modifier dans '''/etc/vfstab'''.

Seules les versions anciennes de VxFS n'activent pas les largefiles par défaut.

===Voir si les largefiles sont activés===

# fsadm -F vxfs /point/de/montage
nolargefiles

"-F vxfs" est facultatif.

===Les activer===

# fsadm -o largefiles /point/de/montage

===Les déactiver===

# fsadm -o nolargefiles /point/de/montage

==Faire un fsck d'un filesystem VxFS==

Si on doit faire un fsck sur un filesystem VxFS, la syntaxe est la suivante :

/usr/sbin/fsck -F vxfs -o nolog,full /dev/vx/rdsk/mon_dg/mon_volume

Explications :

* '''nolog''' : demande à fsck d'accéder directement au filesystem sans passer par le log
* '''full''' : force à vérifier le filesystem en entier

==Voir la liste des tâches en cours==

Pour voir la liste des actions en cours par Veritas (ainsi que la progression en poucentage), taper :

# vxtask list

On obtient également le numéro de tâche. Avec, on peut mettre en pause la tâche avec "'''vxtask pause task_id'''" et la relancer avec "'''vxtask resume task_id'''".

==Script d'affichage de l'espace restant dans un DG==

Voici un petit script qui permet d'afficher l'espace disque restant, utilisé, total et pourcentage utilisé, dans un DG.

#!/bin/bash
#
# Pour tous les dg veritas existant, affiche l'espace disponible en Go
# ainsi que l'espace utilise, l'espace total et le pourcentage d'utilisation.
#

LISTE_DG=$(vxdg -q list|awk '{print $1}' |sort |uniq)

echo -e "Disk Group \t Free space \t Used space \t Total space \t Percent used"
for i in ${LISTE_DG}
do
FREE=`echo $(vxdg -qg $i free |awk '{print $5}' |tr '\n' '+') |sed "s/.*/(0+&/"| sed "s/+$/)\/2\/1024\/1024/"|bc`
TEMP=`vxdisk -qg $i -o size list 2>/dev/null |awk '{print $2}' |tr '\n' '+'`
USED=`echo "($TEMP" |sed "s/+$/)\/1024/g" |bc`
TOTAL=`echo $(($FREE + $USED))`
PERCENT_USED=`echo "scale=2 ; 100*$USED/$TOTAL"|bc`
# l'ajout du "0+" est indispensable pour les DG qui n'ont plus d'espace libre, car ils n'apparaissent pas avec "vxfg free"
echo -e "$i \t\t ${FREE} Go \t ${USED} Go \t ${TOTAL} Go \t ${PERCENT_USED}%"
done

Exemple d'utilisation :

# /root/espace_dispo_sur_dg.sh
Disk Group Free space Used space Total space Percent used
bkpdg 359 Go 1400 Go 1759 Go 79.59%
datadg 403 Go 1200 Go 1603 Go 74.85%
zonedg 169 Go 200 Go 369 Go 54.20%

Ca permet de voir très rapidement où on en est.

Solaris Volume Manager (SVM)

2021-06-10T07:17:07Z

AdminWiki : /* Supprimer un meta-device */

[[Category:solaris]]

=Présentation=

"Solaris Volume Manager" (SVM) est le gestionnaire de volumes natif de Solaris. Avant Solaris 10, il s’appelait "Solstice Disk Suite". Il sait gérer à la fois les niveaux de raid et les volumes disques ; c'est donc l'équivalent sous linux des mdtools et de lvm réunis. Ça permet d'avoir tout dans un seul outil. SVM gère toutes ses fonctionnalités au niveau des slices (partitions) et pas au niveau du disque. Il est capable de faire du stripping (raid 0), du mirroring (raid 1), les deux combinés (0+1 et 1+0), du raid 5, de la concaténation (additionner les disques physiques pour n'en faire qu'un logique), gestion de hotspare, de pools de hotspares, les DiskSet (groupes de disques qu'on pourra débrancher d'un serveur pour les rebrancher sur un autre, en conservant ses caractéristiques). Le raid est également possible sur le disque système. SVM est également capable d'agrandir les volumes à chaud, mais la structure même d'UFS ne permet pas la réduction, même à froid. Le problème est exactement le même avec ZFS.

SVM se comporte comme une surcouche aux systèmes de fichiers UFS. A l'installation de l'OS, on ne peut donc pas mettre en place SVM, mais après on va "encapsuler" les données dans SVM et les gérer avec SVM.

Dans Solaris 9 et 10, SVM (ou Disk Suite) est installé par défaut avec le système. Dans Solaris 8 et précédents, il faut installer les packages SUNWmdr, SUNWmdu et SUNWmdx.

=Les Replica Databases=

SVM conserve sa structure dans des bases de données, qu'on appelle "Replica Databases". Ces databases font 4Mo chacune et doivent être créées dans un slice dédié sur chaque disque ; on lui attribue traditionnellement le slice 7, qui sera de petite taille (une trentaine de Mo suffit). L'ensemble des disques partagés s'appelle un "diskset". On a un maximum de 50 replica databases par diskset. Le principe est d'avoir un certain nombre de databases réparties sur chaque disque physique. Tant que le système peut accéder à au moins 50% des databases plus une, alors ça fonctionne. Sinon, il part en panic. Pendant le démarrage, les databases corrompues ou perdues peuvent être restaurées.

Attention : les replica databases doivent obligatoirement se trouver sur des disques locaux et surtout pas sur un volume SAN. C'est dû au fait qu'elles sont vues très tôt dans le mécanisme de démarrage.

Il est conseillé d'avoir au minimum 3 databases par disque lorsqu'on a 1 ou 2 disques, 2 databases si on a 3 ou 4 disques, et 1 database par disque pour 5 disques ou plus.

Pour un maximum de sécurité au niveau redondance, il est conseillé d'avoir les databases sur des contrôleurs disques différents.

'''En pratique :'''

Nous allons prendre pour exemple trois disques c0t0d0, c1t1d1 et c2t2d2. Les replica databases seront créées sur le slice 7. On suppose également que le système est actuellement installé sur c0t0d0 et qu'un petit slice 7 a été créé pour accueillir les databases.

On va utiliser la commande "prtvtoc" pour récupérer la table des partitions du disque système, et l'appliquer sur les deux autres disques avec "fmthard". Ainsi, on s'assure que les disques sont partitionnés à l'identique.

# prtvtoc /dev/rdsk/c0t0d0s2 | fmthard –s - /dev/rdsk/c1t1d1s2
# prtvtoc /dev/rdsk/c0t0d0s2 | fmthard –s - /dev/rdsk/c2t2d2s2

Maintenant on va créer les databases (3 par disque) :

# metadb –f –c 3 –a c0t0d0s7 c1t1d1s7 c2t2d2s7

Les options :

* -f : pour forcer la création initiale des databases
* -c 3 : nombe de databases par partition
* -a : pour ajouter

On peut visualiser les databases créées :

# metadb -i
flags first blk block count
a m p luo 16 8192 /dev/dsk/c0t0d0s7
a p luo 8208 8192 /dev/dsk/c0t0d0s7
a p luo 16400 8192 /dev/dsk/c0t0d0s7
a p luo 16 8192 /dev/dsk/c1t1d1s7
a p luo 8208 8192 /dev/dsk/c1t1d1s7
a p luo 16400 8192 /dev/dsk/c1t1d1s7
a p luo 16 8192 /dev/dsk/c2t2d2s7
a p luo 8208 8192 /dev/dsk/c2t2d2s7
a p luo 16400 8192 /dev/dsk/c2t2d2s7

r - la réplique ne contient pas d'informations de transfert de périphérique
o - réplique active avant la dernière modification de la configuration de la base de données du métapériphérique mddb
u - la réplique est mise à jour
l - le localisateur pour cette réplique a été lu avec succès
c - la réplique se trouvait dans /etc/lvm/mddb.cf
p - un patch a été appliqué à la réplique dans le noyau
m - la réplique est maître : elle est sélectionnée comme réplique d'entrée
W - la réplique contient des erreurs d'écriture de périphérique
a - la réplique est active, des validations ont lieu dans cette réplique
M - la réplique a rencontré des problèmes avec les blocs maîtres
D - la réplique a rencontré des problèmes avec les blocs de données
F - la réplique a rencontré des problèmes liés au format
S - la réplique est trop petite pour contenir la base de données actuelle
R - la réplique contenait des erreurs de lecture de périphérique

La création ou l'ajout de databases va mettre à jour les fichiers de configuration. Ils diffèrent selon les versions de Solaris :

* Solaris 10 : /kernel/drv/md.conf
* Solaris 9 : /etc/lvm/mddb.conf
* Solaris 8 : /etc/system + /etc/lvm/mddb.conf

Pour supprimer une database :

# metadb –d c2t2d2s7

=Création d'un volume (ou meta-device)=

Sous SVM, les volumes logiques s'appellent également des meta-devices. Ils peuvent être de type RAID 0, RAID 1 ou RAID 5. SVM gère également des Hot Spare Pools et des Soft Partitions. Nous allons voir tout ça en détail.

==Syntaxe générale==

Pour créer un volume, on utilise la commande metainit suivie de plusieurs paramètres :

# metainit <nom_volume> <nb_bandes> <nb_partition_dans_la_bande> <partition> [<nb_partition_dans_la_bande_suivante> <partition>]

Cette syntaxe n'est pas très parlante, mais va devenir plus clair avec les exemples qui vont suivre. Il faut noter que le nom des volumes n'est pas tout à fait libre : on doit choisir un nom compris entre "d0" et "d8192".

==Volume contaténé/strippé (RAID 0)==

===Volume simple===

Exemple :

# metainit d39 1 1 c1t1d1s5

On créé un volume qui s'appelle d39, composé d'une bande (strippe), elle-même composée d'une partition (c1t1d1s5).

===Volume concaténé===

Exemple :

# metainit d30 2 1 c1t1d1s6 1 c2t2d2s5

On créé un volume qui s'appelle d30, composé de deux bandes (strippes). La première bande est composée d'une partition (c1t1d1s6) et la deuxième d'une partition (c2t2d2s5).

===Volume strippé===

Exemple :

# metainit d31 1 2 c1t1d1s0 c2t2d2s0 –i 64k

On créé un volume qui s'appelle d31, composé d'une seule bande. Cette bande est composée de deux partitions (c1t1d1s0 et c2t2d2s0).

On ajoute également une nouvelle notion (facultative) via l'option "-i 64k". Cette option sert à préciser qu'on va utiliser un facteur d'entrelacement de 64ko.

===Volume contcaténé / strippé===

C'est simplement un volume à la fois concaténé et strippé, donc composé de plusieurs bandes, composées chacunes de plusieurs partitions.

===Ajout d'un slice à un volume===

'''Attention :''' on ne pourra pas le retirer, sauf avec perte des données, puisqu'on ne peut pas réduire UFS.

Exemple :

metattach d15 c2d0s5

la partition est donc agrandie de la taille de la nouvelle, mais pas le FileSystem.

Pour agrandir le FS :

growfs [-M /point_de_montage ] /dev/md/rdsk/d15

L'option "'''-M /point_de_montage'''" sert uniquement si on agrandit à chaud une partition montée.

===Utilisation de /etc/lvm/md.tab===

Plutôt que de taper les commandes à la main, on peut également remplir le fichier '''/etc/lvm/md.tab''' avec des lignes du type '''"d15 1 1 c1d0s5"''' (sans les guillemets), et taper '''"metainit d15"''' dans le shell.

Ce fichier ne sert que quand on lance metainit, mais il n'est pas lu au boot (ce sont les databases qui sont lues).

Il est quand même intéressant de le remplir car il peut serveur d'aide mémoire.

L'utilisation de ce fichier n'est pas limitée au raid 0, on peut s'en servir pour tous les niveau de raid.

===Création du système de fichier===

Jusque là, on a juste créé les volumes logiques, pas les filesystems. Voici comment faire.

Création du filesystem sur le meta-device :

newfs /dev/md/rdsk/d15

Dans /etc/vfstab on mettra :

#device to mount #device to check #montage #FS #ordre fsck #mount at boot #options
/dev/md/dsk/d15 /dev/md/rdsk/d15 /montage ufs 3 yes logging

===Limitations===

'''ATTENTION''' : il est interdit d'utiliser les volumes RAID 0 pour tout filesystem utilisé lors d'une installation ou upgrade, c'est-à-dire /, /usr, /var, /opt et les swap.

==Volume mirroré (RAID 1)==

On créé d'abord les éléments du miroir :

metainit d21 1 1 c3d0s0
metainit d22 1 1 c4d0s0

Puis on créé le miroir, d'abord avec un seul élément, comme ça on va conserver les données de cet élément (les données des éléments suivants seront perdues) :

metainit d20 -m d21

Et enfin on rajoute l'autre patte :

metattach d20 d22

Si on passe par /etc/lvm/md.tab, on met dans le fichier :

d21 1 1 c3d0s0
d22 1 1 c4d0s0
d20 -m d21

On initialise avec :

metainit d21 d22 d20

Puis on attache la deuxième patte pareil :

metattach d20 d22

Quand on va créér le système de fichiers, on le fera sur d20.

On peut également retirer une patte du miroir (par exemple pour faire une sauvegarde sans que les données bougent) :

metadetach d20 d21

Puis on la remet :

metattach d20 d21

Cette méthode a l'inconvénient de resynchroniser tout le disque quand on rattache, ce qui peut être long. Une autre possibilité est de mettre la patte "offline", puis la remettre "online". La synchro est alors optimisée et se fait seulement sur ce qui a bougé.

Mettre la patte "offline" :

metaoffline d20 d21

La remettre "online" :

metaonline d20 d21

Panne dans un miroir : on ne peut le savoir que en consultant /var/adm/messages ou en tapant metastat (ou dans Solaris Management Console).

Il faut alors :
* remplacer physiquement le disque deffectueux
* vérifier qu'il est bien vu avec format
* mettre à jour la référence du disque : "metadevadm -u c3d0"
* refaire le paritionnement (format ou prtvtoc+fmthard)
* identifier les databases à remplacer : "metadb -i"
* les recréer : "metadb -d c3d0s7", puis "metadb -a c3d0s7"
* si les partitions déffectueuses faisaient parti d'un raid : "metareplace -e d20 c3d0s0"
* si les partitions étaient dans des Soft Partition, plutôt utiliser : "metarecover c3d0s0 -d -p"

==Volume RAID 5==

metainit d50 -r c5d0s1 c6d0s1 c7d0s1 -i 128k
newfs /dev/md/rdsk/d50
mount -o logging /dev/md/dsk/d50 /point_de_montage

Dans /etc/vfstab :

/dev/md/dsk/d50 /dev/md/rdsk/d50 /point_de_montage ufs 3 yes logging

==Création d'un hot spare pool==

Un hotspare pool est un groupe de partitions de réserve, au cas ou des partitions utilisées seraient cassées. Le nom qu'on lui donne est obligatoirement de la forme hspxxx, xxx étant des chiffres :

Création :

metainit hsp000 c8d0s0

Association à un meta-device pendant sa création :

metainit d50 -h hsp000 ...

Association après coup :

metaparam -h hsp000 d50

Retirer le hot spare pool :

metaparam -h none d50

==Informations sur les meta-devices==

metastat [d15]

* sans options : version longue
* -c : plus lisible
* -p : plus compact (format utilisable dans /etc/lvm/md.tab)

Exemple :

# metastat d0
d0: Miroir
Sous-miroir 0: d10
Etat : Ok
Sous-miroir 1: d20
Etat : Ok
Accès : 1
Option de lecture : roundrobin (par défaut)
Option d'écriture : parallel (par défaut)
Taille : 41950000 blocs (20 GB)

d10: Sous-miroir de d0
Etat : Ok
Taille : 41950000 blocs (20 GB)
Bande 0 :
Périphérique Bloc de débu Base Etat Redis Tranche dynamique
c0t0d0s0 0 Non Ok Oui

d20: Sous-miroir de d0
Etat : Ok
Taille : 41950000 blocs (20 GB)
Bande 0 :
Périphérique Bloc de débu Base Etat Redis Tranche dynamique
c0t1d0s0 0 Non Ok Oui

Device Relocation Information:
Device Reloc Device ID
c0t0d0 Oui id1,sd@n5000c5001d64d883
c0t1d0 Oui id1,sd@n5000c5001d5f8b8f
#
#
# metastat -c d0
d0 m 20GB d10 d20
d10 s 20GB c0t0d0s0
d20 s 20GB c0t1d0s0

==Supprimer un meta-device==

Pour supprimer un metadevice simple :

metaclear d15

Pour supprimer un metadevice et sa sous-arborescence :

metaclear -r d0

==Les soft partitions==

Les soft partitions sont des partitions "virtuelles" crées à l'intérieur d'une partition physique ou d'un metadevice. Ça permet d'avoir autant de partitions (et donc de filesystems) qu'on veut à l'interieur d'un seul disque ou d'une seule partition physique.

Une soft partition étant une partition à part entière (même si elle est virtuelle), il faut préciser sa taille à la création. Il faut également préciser la partition sur laquelle on va créer la soft partition, pour cela on utilise l'option –p.

Exemples :

metainit d51 -p d50 1g
metainit d52 –p c1t2d3s4 –b 204800

Dans le premier exemple, on créé une soft partition "d51" à l'intérieur d'un volume d50, d'une taille de 1Go.

Dans le deuxième exemple, on créé une soft partition "d52" à l'intieur de la partition c1t2d3s4 d'une taille de 204800 blocs, soit 100Mo pour une taille de bloc de 512 octets.

=Mirrorer le disque système=

Cette page décrit la mise en place de l'encapsulation sous SVM du disque système du serveur UIRGS48, et de sa mise en miroir.

Solaris a été installé sur le disque c0t0d0 et le disque qui est destiné à être son miroir est c0t1d0.

Le principe est de :

* créer un slice pour accueillir les databases de SVM
* dupliquer la table des partitions sur le disque miroir
* créer les databases et les metadevices
* raccorder le premier disque au miroir et modifier les fichiers de conf pour préparer au reboot (/etc/vfstab)
* rebooter et vérifier que le miroir est actif
* raccorder le deuxième disque au miroir
* modifier l'OBP pour pouvoir booter sur n'importe lequel des deux disques
* tester que le boot fonctionne sur les deux

==État avant l'encapsulation==

Voici un extrait des infos obtenues avec "format" :

AVAILABLE DISK SELECTIONS:
0. c0t0d0 <SUN146G cyl 14087 alt 2 hd 24 sec 848>
/pci@0,600000/pci@0/pci@8/pci@0/scsi@1/sd@0,0
1. c0t1d0 <SUN146G cyl 14087 alt 2 hd 24 sec 848> Solaris
/pci@0,600000/pci@0/pci@8/pci@0/scsi@1/sd@1,0

Disk 0 :

Current partition table (original):
Total disk cylinders available: 14087 + 2 (reserved cylinders)

Part Tag Flag Cylinders Size Blocks
0 root wm 0 - 2060 20.00GB (2061/0/0) 41945472
1 swap wu 2061 - 5358 32.01GB (3298/0/0) 67120896
2 backup wm 0 - 14086 136.71GB (14087/0/0) 286698624
3 var wm 5359 - 8656 32.01GB (3298/0/0) 67120896
4 unassigned wm 0 0 (0/0/0) 0
5 unassigned wm 0 0 (0/0/0) 0
6 unassigned wm 0 0 (0/0/0) 0
7 unassigned wu 0 0 (0/0/0) 0

Disk 1 :

Volume: Solaris
Current partition table (original):
Total disk cylinders available: 14087 + 2 (reserved cylinders)

Part Tag Flag Cylinders Size Blocks
0 root wm 0 - 12 129.19MB (13/0/0) 264576
1 swap wu 13 - 25 129.19MB (13/0/0) 264576
2 backup wu 0 - 14086 136.71GB (14087/0/0) 286698624
3 unassigned wm 0 0 (0/0/0) 0
4 unassigned wm 0 0 (0/0/0) 0
5 unassigned wm 0 0 (0/0/0) 0
6 usr wm 26 - 14086 136.46GB (14061/0/0) 286169472
7 unassigned wm 0 0 (0/0/0) 0

Les partitions montées apparaissent encore en tant que "/dev/dsk/c0t0d0s0" :

# df -h|grep -v dg
Filesystem size used avail capacity Mounted on
/dev/dsk/c0t0d0s0 20G 5.0G 15G 26% /
/devices 0K 0K 0K 0% /devices
ctfs 0K 0K 0K 0% /system/contract
proc 0K 0K 0K 0% /proc
mnttab 0K 0K 0K 0% /etc/mnttab
swap 46G 1.7M 46G 1% /etc/svc/volatile
objfs 0K 0K 0K 0% /system/object
sharefs 0K 0K 0K 0% /etc/dfs/sharetab
fd 0K 0K 0K 0% /dev/fd
/dev/dsk/c0t0d0s3 32G 7.9G 23G 26% /var
swap 46G 213M 46G 1% /tmp
swap 46G 248K 46G 1% /var/run
swap 46G 0K 46G 0% /dev/vx/dmp
swap 46G 0K 46G 0% /dev/vx/rdmp
/dev/odm 0K 0K 0K 0% /dev/odm
/platform/sun4u-us3/lib/libc_psr/libc_psr_hwcap2.so.1 20G 5.0G 15G 26% /platform/sun4u-us3/lib /libc_psr.so.1
/platform/sun4u-us3/lib/sparcv9/libc_psr/libc_psr_hwcap2.so.1 20G 5.0G 15G 26% /platform/sun4u-us3/lib/sparcv9 /libc_psr.so.1

==Encapsulation du disque système et mise en place du miroir==

Il faut créer un slice n°7 de 20 Mo pour accueillir les metadb (4Mo par database, et 3 databases en tout par disque), à l'aide de format. Une fois que c'est fait, voici à quoi ressemble le partitionnement :

Format disk 0 :
Current partition table (original):
Total disk cylinders available: 14087 + 2 (reserved cylinders)

Part Tag Flag Cylinders Size Blocks
0 root wm 0 - 2060 20.00GB (2061/0/0) 41945472
1 swap wu 2061 - 5358 32.01GB (3298/0/0) 67120896
2 backup wm 0 - 14086 136.71GB (14087/0/0) 286698624
3 var wm 5359 - 8656 32.01GB (3298/0/0) 67120896
4 unassigned wm 0 0 (0/0/0) 0
5 unassigned wm 0 0 (0/0/0) 0
6 unassigned wm 0 0 (0/0/0) 0
7 unassigned wm 8657 - 8659 29.81MB (3/0/0) 61056

On copie la table des partitions sur le futur miroir :

# prtvtoc /dev/rdsk/c0t0d0s2 | fmthard -s - /dev/rdsk/c0t1d0s2

On vérifie avec un format du disk 1 que c'est ok :

Volume: Solaris
Current partition table (original):
Total disk cylinders available: 14087 + 2 (reserved cylinders)

Part Tag Flag Cylinders Size Blocks
0 root wm 0 - 2060 20.00GB (2061/0/0) 41945472
1 swap wu 2061 - 5358 32.01GB (3298/0/0) 67120896
2 backup wm 0 - 14086 136.71GB (14087/0/0) 286698624
3 var wm 5359 - 8656 32.01GB (3298/0/0) 67120896
4 unassigned wu 0 0 (0/0/0) 0
5 unassigned wu 0 0 (0/0/0) 0
6 unassigned wu 0 0 (0/0/0) 0
7 unassigned wm 8657 - 8659 29.81MB (3/0/0) 61056

On sauvegarde les fichiers /etc/vfstab et /etc/system, car ils vont être altérés par la suite.

# cp /etc/vfstab /etc/vfstab.20100414
# cp /etc/system /etc/system.20100414

On défini à l'avance la structure du futur miroir en ajoutant les lignes suivantes dans /etc/lvm/md.tab

# Partition /
d10 1 1 c0t0d0s0
d20 1 1 c0t1d0s0
d0 -m d10
# Partition de swap
d11 1 1 c0t0d0s1
d21 1 1 c0t1d0s1
d1 -m d11
# Partition /var
d13 1 1 c0t0d0s3
d23 1 1 c0t1d0s3
d3 -m d13

Les databases ne sont pas encore créés. On le vérifie ainsi :

# metadb -i

metadb: uirgs48: there are no existing databases

Création des databases

# metadb -f -c 3 -a c0t0d0s7 c0t1d0s7

Vérification :

# metadb -i
flags first blk block count
a u 16 8192 /dev/dsk/c0t0d0s7
a u 8208 8192 /dev/dsk/c0t0d0s7
a u 16400 8192 /dev/dsk/c0t0d0s7
a u 16 8192 /dev/dsk/c0t1d0s7
a u 8208 8192 /dev/dsk/c0t1d0s7
a u 16400 8192 /dev/dsk/c0t1d0s7
r - replica does not have device relocation information
o - replica active prior to last mddb configuration change
u - replica is up to date
l - locator for this replica was read successfully
c - replica's location was in /etc/lvm/mddb.cf
p - replica's location was patched in kernel
m - replica is master, this is replica selected as input
W - replica has device write errors
a - replica is active, commits are occurring to this replica
M - replica had problem with master blocks
D - replica had problem with data blocks
F - replica had format problems
S - replica is too small to hold current data base
R - replica had device read errors

Création des metadevices

# metainit -a -f
d10: Concat/Stripe is setup
d20: Concat/Stripe is setup
d0: Mirror is setup
d11: Concat/Stripe is setup
d21: Concat/Stripe is setup
d1: Mirror is setup
d13: Concat/Stripe is setup
d23: Concat/Stripe is setup
d3: Mirror is setup

Modifier le vfstab (avec metaroot pour /, et manuellement pour swap et /var):

# metaroot d0

==> modifie /etc/vfstab mais uniquement pour "/".

Pour le reste, il faut éditer manuellement /etc/vfstab pour obtenir le résultat suivant :

# vi /etc/vfstab
[...]
/dev/md/dsk/d0 /dev/md/rdsk/d0 / ufs 1 no -
/dev/md/dsk/d1 - - swap - no -
/dev/md/dsk/d3 /dev/md/rdsk/d3 /var ufs 1 no -
[...]

Rebooter en lockant les filesystems :

# lockfs -fa
# init 6

On vérifie qu'on a bien booté sur le raid :

# df -h |grep -v dg
Filesystem size used avail capacity Mounted on
/dev/md/dsk/d0 20G 5.0G 15G 26% /
/dev/md/dsk/d3 32G 7.9G 23G 26% /var
[...]

# swap -l
swapfile dev swaplo blocks free
/dev/md/dsk/d1 85,1 16 67120880 67120880

Modifier le périphérique de dump.

* avant :

# dumpadm
Dump content: kernel pages
Dump device: /dev/dsk/c0t0d0s1 (dedicated)
Savecore directory: /var/crash/uirgs48
Savecore enabled: yes

* on modifie :

# dumpadm -d swap
Dump content: kernel pages
Dump device: /dev/md/dsk/d1 (swap)
Savecore directory: /var/crash/uirgs48
Savecore enabled: yes

* après :

# dumpadm
Dump content: kernel pages
Dump device: /dev/md/dsk/d1 (swap)
Savecore directory: /var/crash/uirgs48
Savecore enabled: yes

On attache les partitions du deuxième disque au mirroirs :

# metattach d0 d20
# metattach d1 d21
# metattach d3 d23

On peut vérifier qu'ils sont bien attachés correctement :

# metastat |grep -i mirror
d3: Mirror
Submirror 0: d13
Submirror 1: d23
d13: Submirror of d3
d23: Submirror of d3
d1: Mirror
Submirror 0: d11
Submirror 1: d21
d11: Submirror of d1
d21: Submirror of d1
d0: Mirror
Submirror 0: d10
Submirror 1: d20
d10: Submirror of d0
d20: Submirror of d0

L'attachement est immediat, mais la copie des fichiers sur le mirroir prend du temps. On peut contrôler ou on en est avec :

# metastat |grep -i sync
State: Resyncing
Resync in progress: 2 % done
State: Resyncing
State: Resyncing
Resync in progress: 2 % done
State: Resyncing
State: Resyncing
Resync in progress: 5 % done
State: Resyncing

Ajouter une ligne dans /etc/system pour pouvoir booter en cas de panne disque :

# echo "set md:mirrored_root_flag=1" >> /etc/system

Configuration de l'OBP pour pouvoir booter sur n'importe lequel des deux disques (nommés "dsk10" pour le disque principal et "mir10" pour le mirroir). On peut le faire depuis Solaris, s'il est démarré, ou depuis l'OBP.

* depuis Solaris

# eeprom "nvramrc=devalias dsk10 /pci@0,600000/pci@0/pci@8/pci@0/scsi@1/disk@0,0:a mir10 /pci@0,600000/pci@0/pci@8/pci@0/scsi@1/disk@1,0:a"
# eeprom boot-device="dsk10 mir10"
# eeprom "use-nvramrc?=true"

* ou depuis l'OBP

ok> nvalias dsk10 /pci@0,600000/pci@0/pci@8/pci@0/scsi@1/disk@0,0:a
ok> mir10 /pci@0,600000/pci@0/pci@8/pci@0/scsi@1/disk@1,0:a
ok> setenv boot-device dsk10 mir10

Ensuite il faut vérifier qu'on peut booter avec les deux disques.
Rebooter avec "init 0".
Se connecter sur la console du domaine.
Booter avec "boot mir10", puis recommencer avec "boot dsk10".

Zones - Solaris

2021-05-12T08:13:55Z

AdminWiki : /* Création du fichier de configuration */

[[Category:solaris]]

=Présentation=

Les zones sont une solution de virtualisation intégré à Solaris. Elles sont à mi-chemin entre un chroot et un serveur virtuel. C'est à dire qu'on a un système d'exploitation hôte (appelé zone globale) dans lequel on fait tourner des process chrootés (donc qui ne voient pas les autres process de la zone globale ou des autres zones) qui sont en quelque sorte des "super process", car ils font tourner un système d'exploitation complet. Une partie des bibliothèques système sont communes entre les zones et la zone globale. C'est exactement le même principe que les jails BSD.

On peut créer des zones solaris 10 sparse (le type par défaut) ou big. Une zone sparse partage avec la zone globale les répertoires /usr, /lib, /sbin et /platform. Une big a une arborescence entièrement indépendante. La sparse va donc consommer moins d'espace disque, et lorsqu'on va patcher le système de la gloable, ça va patcher également les zones sparse. Ҫa peut-être soit un avantage soit un inconvénient. Il faut décider dès la création si on veut une sparse ou une big, car on ne peut pas changer après.

L'avantage de cette façon de virtualiser est qu'il n'y a pas besoin d'émuler la partie matérielle, gourmande en ressources. D'ailleurs, une zone qui ne fait pas tourner de process, ne consomme qu'une quarantaine de Mo.
L'inconvénient est qu'il faut adapter les systèmes d'exploitation pour qu'ils puissent tourner en tant que zone. Dans les premières versions de Solaris 10, on ne pouvait faire tourner que des zones solaris 10. Plus tard, on a introduit le concept de "branded zones", qui permettent de faire tourner d'autres systèmes d'exploitation en les adaptant. Depuis solaris 10 8/07, il existe des branded zones Solaris 8 et 9 (uniquement sur Sparc). Il existe aussi des branded zones opensolaris (et des solaris 10 pour opensolaris) et des linux. Les branded zones linux ne peuvent faire tourner que des Redhat et CentOS 3.5 à 3.8, donc un noyau 2.4.

Les zones sont gérées par deux daemons : zoneadmd pour la supervision et zsched qui est l'ordonnanceur.

=Les zones et le NFS=

Il faut noter qu'une zone ne peut pas être serveur NFS, il n'y a que la zone globale qui peut jouer ce rôle. Un astuce peut donc consister à monter le serveur NFS sur la globale et à partager un répertoire qui appartient à la zone (car la globale accède librement à tous les filesystems des zones via le zonepath – voir chapitre "''Installation/configuration d'une zone Solaris 10)''".

Par contre, n'importe quelle zone peut sans problème être client NFS.

Mise à jour : il paraît, mais je n'ai pas eu l'occasion de vérifier, qu'une zone peut être serveur NFS si elle a une interface réseau dédiée.

=Installation/configuration d'une zone Solaris 10=

==Prérequis==

Avant de créer une zone, il est nécessaire d'avoir prévu :

* un répertoire pour mettre son système (par exemple /zones/zone1), appelé "zonepath". Ce répertoire doit obligatoirement avec les droits 700, sans quoi l'installation échouera.
* une adresse ip
* l'interface réseau physique sur laquelle on va connecter cette ip (par exemple bge0)
* éventuellement les filesystems à créer, sinon on peut les rajouter après

==Création du fichier de configuration==

Pour créer/configurer une zone, on utilise l'outil zonecfg qui est un outil en mode texte avec un prompt particulier.
L'exemple ci-dessous montre assez clairement comment utiliser zonecfg :

# zonecfg –z zone1
create
set zonepath=/zones/zone1
set autoboot=true
add net
:set physical=bge0
:set address=10.36.210.56/22
:end
add fs
:set dir=/data
:set type=vxfs
:set raw=/dev/vx/rdsk/datadg/datalv
:set special=/dev/vx/dsk/datadg/datalv
:end
add fs
:set dir=/data2
:set type=zfs
:set special=zone1/data2
:end
verify
commit
exit

Remarques :

* on peut ajouter autant de filesystems (FS) qu'on veut ; on peut également n'en mettre aucun.
* '''Attention :''' pour les ZFS, pour qu'ils soient "montables" par la zone, il faut que sur la globale on ait '''"mountpoint=legacy"''' sur la globale.
* pour créer une zone big, il suffit de faire "create –b" au lieu de "create".
* verify et commit sont facultatifs. Verify sert à vérifier qu'il n'y a pas d'erreur ; il est conseillé de le faire. Commit sert à forcer l'enregistrement ; il est plutôt déconseillé de s'en servir, car il va enregistrer même s'il y a des erreurs. Exit va enregistrer et quitter.

En quittant, zonecfg créé un fichier /etc/zones/zone1.xml. Il est fortement déconseillé de modifier ce fichier directement, sans passer par zonecfg, sauf si on sait parfaitement ce qu'on fait.

==Installation de la zone==

Maintenant que le fichier de configuration est créé, on peut passer à l'installation de la zone (la création de tous les fichiers).

Attention : tous les filesystems déclarés à l'étape précédente avec "add fs" doivent être créés avant de passer à l'installation !

Pour installer la zone, une seule commande suffit :

# zoneadm –z zone1 install

Cette étape dure une dizaine de minutes (en fonction de la puissance du serveur). Ҫa va être un peu plus long pour une zone big.

==Booter et paramétrer la zone==

A ce stade, la zone est créée, mais est arrêtée. On va donc la démarrer. Au premier démarrage, on arrive dans l'utilitaire de configuration classique de Solaris, dans lequel on va choisir le type de clavier, la langue, le fuseau horaire, etc…

Pour booter la zone :

# zoneadm –z zone1 boot

Pour se connecter dessus en mode console :

# zlogin –C zone1

Pour quitter le mode console : taper "~.".

Notre zone "zone1" est maintenant accessible comme n'importe quel serveur.

=Installation/configuration de zones Solaris 8 et 9=

==Prérequis==

L'installation de containers Solaris 8 et 9 nécessite l'ajout de packages supplémentaires :

* SUNWs8brandk, SUNWs8brandr et SUNWs8brandu pour Solaris 8
* SUNWs9brandk, SUNWs9brandr et SUNWs9brandu pour Solaris 9

==Création d'une flash archive==

Une zone Solaris 8 ou 9 s'installe depuis une archive flash (fichier .flar). On peut trouver des archives de ce type sur le web, mais la plupart du temps, ces zones sont destinées à remplacer des serveurs physiques existants. On va donc créer une image flash depuis un serveur existant.

Voici un exemple de création d'image flash (à lancer depuis le serveur à sauvegarder) :

# flarcreate –S –c –n sol8_204 –x /u01 –x /u02 –x /backup /backup/sol8_204.flar

Explications :

* -S : évite de verifier l'espace dispo sur le disque de destination, et écrit l'image directement sur le disque (passe par la RAM sinon)
* -c : compresse l'image
* -n : label
* -x : filesystems à ne pas inclure. Attention : une image flash intègre par défaut l'ensemble des filesystems locaux et distants, il faut donc bien penser à exclure (ou préalablement démonter) les montages NFS et autres lecteurs DVD.
* à la fin de la commande, on met le nom du fichier de destination

==Création du fichier de configuration==

La création du fichier de configuration se fait également avec zonecfg.

A noter, quelques petites différences :

* lors du create, il faut taper respectivement pour des Solaris 8 et 9 :

create –t SUNWsolaris8
create –t SUNWsolaris9

* on peut ajouter les attributs suivants (utiles pour la migration d'un serveur existant, principalement pour des questions de licences :

> add attr
set name=hostid
set type=string
set value=<hostid du serveur à migrer>
end
> addattr
set name=machine
set type=string
set value=sun4u
end

'''ATTENTION :''' depuis les dernières versions de Solaris, cette méthode ne fonctionne plus pour le hostid. Il faut juste faire "'''set hostid=<valeur>'''". C'est encore plus simple.

==Installation de la zone==

On va maintenant procéder à l'installation, en utilisant l'archive flash, qu'on aura déposé au préalable sur la zone globale (par exemple /var/tmp/sol8_204.flar)

# zoneadm –z zone2 install –u –a /var/tmp/sol8_204.flar

L'option "-u" fait un unconfigure pour forcer la reconfiguration au boot.

==Booter et paramétrer la zone==

Ici, c'est exactement comme les zones Solaris 10.

# zoneadm –z zone2 boot
# zlogin –C zone2

=Gestion des zones=

==Lister==

Pour voir la liste des zones, on utilise "zoneadm list", de préférence avec les options "-cv" pour plus de détails.

Exemple :

root@uirgs37 # zoneadm list
global
uirgs39
uirgs40
uirgs41
uirgs42
uirgs43
uirgs44
uirgs45
uirgs46
uirgs85
uirgs38
root@uirgs37 # zoneadm list -cv
ID NAME STATUS PATH BRAND IP
0 global running / native shared
12 uirgs39 running /zones/uirgs39 native shared
13 uirgs40 running /zones/uirgs40 native shared
14 uirgs41 running /zones/uirgs41 solaris8 shared
15 uirgs42 running /zones/uirgs42 solaris9 shared
16 uirgs43 running /zones/uirgs43 solaris9 shared
17 uirgs44 running /zones/uirgs44 native shared
18 uirgs45 running /zones/uirgs45 native shared
19 uirgs46 running /zones/uirgs46 native shared
20 uirgs85 running /zones/uirgs85 solaris8 shared
21 uirgs38 running /zones/uirgs38 solaris8 shared
root@uirgs37 #

On voit que la globale apparait comme une zone dans la liste.

L'option "-cv" permet également de voir l'état d'une zone. Voici les principaux états que peut avoir une zone :

* configured : configurée, mais pas encore installée
* installed : installée et arrêtée
* running : elle fonctionne

==Connexion==

Pour se connecter à une zone, on utilise zlogin, suivi du nom de la zone.

# zlogin zone1

Pour se connecter comme si on était sur la console (permet par exemple de voir les messages au boot) :

# zlogin -C zone1

Pour quitter on fait ~. en tapant rapidement. Il est parfois nécessaire d'appuyer plusieurs fois sur ".". Il ne peut y avoir qu'une seule personne connectée en mode console.

==Arrêt/reboot==

Pour arrêter, démarrer ou rebooter une zone, on utilise :

# zoneadm –z zone1 halt
# zoneadm –z zone1 boot
# zoneadm –z zone1 reboot

==Forcer l'arrêt==

Il arrive parfois qu'une zone refuse de s'arrêter et reste dans l'état "down" ou "shutting down". Il est difficile de déterminer quel est ou quels sont les process qui refusent de mourir. Dans ce cas, la commande suivante peut nous sauver :

# pkill -9 -z zonename

Si même cette commande ne fonctionne pas, on est mal barré ! Il est probable qu'on soit obligé de rebooter la globale.

A noter que parfois il est nécessaire de relancer un "zoneadm -z zone halt" après le pkill.

=Supprimer une zone=

Pour supprimer une zone, il faut d'abort la passer à l'état "configured" :

# zoneadm –z zone3 uninstall

Puis on la supprime définitivement :

# zonecfg –z zone3 delete

=Cloner une zone=

Le clonage permet de dupliquer une zone existant sans avoir à refaire une archive flash. Le clone ne concerne que la partie système, c'est à dire qu'une fois le clone terminé, il va falloir recopier à la main les filesystems additionnels.

Dans l'exemple qui suit, on va cloner la zone "zoneA" vers "zoneB".

* exporter la configuration de la zone zoneA

# zonecfg –z zoneA export –f /tmp/zoneB.zonecfg

* éditer le fichier /tmp/zoneB.zonecfg et modifier tout ce qu'il faut adapter (adresse ip, zonepath, etc)
* créer les systèmes de fichiers qui seront utilisés par la zone zoneB
* modifier les droits du zonepath du futur clone

# chmod 700 /zones/zoneB

* créer la nouvelle zone

# zonecfg –z zoneB –f /tmp/zoneB.zonecfg

* arrêter zoneA (indispensable pour que la copie des fichiers soit cohérente)

# zlogin zoneA init 0

* cloner les contenus

# zoneadm –z zoneB clone zoneA

* redémarrer zoneA

# zoneadm –z zoneA boot

* on peut maintenant démarrer et configurer la nouvelle zone

# zoneadm –z zoneB boot
# zlogin –C zoneB

Dans certains cas, il peut être nécessaire de forcer la nouvelle zone à passer de l'état "configured" à "installed". On le fait avec la commande suivante :

# zoneadm –z zoneB attach -F

=Flying zones=

==Présentation==

Flying zone est le terme commercial employé par Sun/Oracle pour décrire la procédure qui consiste à migrer une zone d'une globale vers une autre. En réalité, tout se fait manuellement, rien n'est automatique, c'est 100 fois moins bien que vmware, mais le terme "Flying zone", ça pète !

Pour pouvoir migrer les données de la zone, il faut soit copier les données de la globale de départ vers celle d'arrivée, soit avoir ces données accessibles par les deux serveurs (par exemple un SAN).

Nous allons ici prendre l'exemple de la zone '''zone1''' qui se trouve sur la globale '''zglobale1''' et qu'on va migrer sur la '''zglobale2'''. Les données de la zone sont dans deux zpools "zp_zone1" et "zp_zone1_data". Les zpools sont sur un SAN connecté aux deux globales. Ils sont actuellement montés sur la première ; ils sont visibles de la deuxième, mais pas importés (on ne peut pas importer des zpools sur deux serveurs à la fois).

==Procédure==

La procédure se fait en 7 étapes.

'''Sur la première globale :'''

* éteindre la zone :

zglobale1# zlogin zone1 init 5

* detacher la zone

zglobale1# zoneadm -z zone1 detach

* exporter les zpools

zglobale1# zpool export zp_zone1
zglobale1# zpool export zp_zone1_data

'''Sur la deuxième globale :'''

* importer les zpools

zglobale2# zpool import zp_zone1
zglobale2# zpool import zp_zone1_data

* récuperer la configuration de la zone

zglobale2# scp zglobale1:/etc/zones/zone1.xml /etc/zones/

* attacher la zone

zglobale2# zoneadm -z zone1 attach

* démarrer la zone

zglobale2# zoneadm -z zone1 boot

'''Remarque :''' il se peut que l'attachement de la zone ne fonctionne pas la première fois, même en forçant avec l'option "-F". Dans ce cas, il faut ajouter une ligne dans le fichier '''/etc/zones/index''', puis refaire le attach :

zglobale2# echo 'zone1:configured:/zones/zone1:' >> /etc/zones/index
zglobale2# zglobale2# zoneadm -z zone1 attach

==Retour arrière==

On fait l'inverse, tout simplement...

* éteindre la zone

zglobale2# zlogin zone1 init 5

* détacher la zone

zglobale2# zoneadm -z zone1 detach

* exporter les zpools

zglobale2# zpool export zp_zone1
zglobale2# zpool export zp_zone1_data

* importer les zpools

zglobale1# zpool import zp_zone1
zglobale1# zpool import zp_zone1_data

* récuperer la configuration de la zone

zglobale2# scp /etc/zones/zone1.xml zglobale1:/etc/zones/

* attacher la zone

zglobale1# zoneadm -z zone1 attach

* démarrer la zone

zglobale1# zoneadm -z zone1 boot

=Gestion des ressources=

==Présentation==

Par défaut, les ressources RAM, swap et CPU sont communes à toutes les zones, y compris la globale. C'est-à-dire qu'une zone qui a un problème peut s'attribuer toutes les ressources, écrouler toutes les autres zones et même planter la globale. Il existe des moyens de limiter les ressources de chaque zone pour empêcher ça.

Toutes ces manipulations se font depuis la zone globale.

==Limitation de la RAM==

Pour voir la RAM actuellement attribuée aux zones :

# rcapstat -z
id zone nproc vm rss cap at avgat pg avgpg
1 uirgs50 - 833M 921M 8192M 0K 0K 0K 0K
2 uirgs52 - 712M 767M 8192M 0K 0K 0K 0K
3 uirgs49 - 2789M 2816M 8192M 0K 0K 0K 0K
[…]

Ҫa va afficher les valeurs pour toutes les zones. Il faut regarder la colonne "'''cap'''".

Pour modifier la valeur à chaud (attention, la modification sera perdue au prochain reboot) :

# rcapadm –z zone1 –m 4g

Il faut attendre quelques secondes pour que ce soit pris en compte.

Si on obtient un message du genre '''"rcapadm: resource caps not configured"''', alors c'est qu'il faut "enabler" les memory caps avec la commande suivante :

# rcapadm -E

Ensuite il faut retaper la commande rcapadm ci-dessus.

Pour limiter la RAM dans la configuration (pour qu'elle soit permanente à chaque reboot), suivre l'exemple suivant :

# zonecfg –z zone1
> add capped-memory
> set physical=4g
> end
> exit

La limitation ne sera effective qu'au prochain boot de la zone.

Si le paramètre "'''capped-memory'''" existe déjà, on peut le modifier de la manière suivante :

# zonecfg –z zone1
> select capped-memory
> set physical=4g
> end
> exit

==Limitation du swap==

Pour voir la quantité de swap actuellement allouée :

# prctl -n zone.max-swap -i zone zoneB
zone: 21: zoneB
NAME PRIVILEGE VALUE FLAG ACTION RECIPIENT
zone.max-swap
privileged 4,00GB - deny -
system 16,0EB max deny -

Il faut lire la ligne "'''privileged'''".

Pour modifier la valeur à chaud (attention, la modification sera perdue au prochain reboot) :

# prctl -r -n zone.max-swap -i zone -v 6g ma_zone

Attention, cette commande ne fonctionne que pour modifier une valeur existante. Si aucune limitation de swap n'a jamais été appliquée sur cette zone, utiliser la commande suivante :

# prctl -n zone.max-swap -v 6g -t privileged -e deny -s -i zone ma_zone

Re-attention, si vous venez de taper la commande ci-dessus alors que vous aviez déjà une limitation, alors vous n'avez pas modifié la limitation, vous en avez ajouté une deuxième ! Du coup, le système applique la plus restrictive. Pour réparer cette bêtise (c'est du vécu...), annulez la dernière commande avec :

# prctl -n zone.max-swap -i zone -t privileged -x ma_zone

Pour limiter le swap dans la configuration (pour qu'il soit permanent à chaque reboot), suivre l'exemple suivant :

# zonecfg -z zone1
> add capped-memory
> set swap=4g
> end
> exit

La limitation ne sera effective qu'au prochain boot de la zone.

Si le paramètre "'''capped-memory'''" existe déjà, on peut le modifier de la manière suivante :

# zonecfg -z zone1
> select capped-memory
> set swap=4g
> end
> exit

==Limitation du CPU==

Il y a trois méthodes possibles pour limiter l'utilisation CPU :

* '''le Fair Share Scheduler (FSS)''' : on attribue une part minimale de CPU à une zone
* '''les Ressource Pools''' : dédie exclusivement des CPUs à une zone
* '''les CPU caps''' : alloue statiquement des pourcentages de CPU à une zone

===Le Fair Share Scheduler (FSS)===

On alloue un certain nombre de parts de CPU à une zone. Il n'y a pas de nombre de parts prédéfini à partager. Le principe est que plus une zone a de parts, plus elle aura de temps CPU attribué. Par exemple, une zone qui a 20 parts aura deux fois plus de temps CPU qu'une zone à 10 parts. Peu importe le nombre total de parts, il ne représente rien de physique. Donc en fait, on attribue une priorité à chaque zone, et cette priorité ne sert que en cas de conflit. C'est à dire que si tous les cpus sont à 100%, les priorités s'appliquent, mais si les zones les plus prioritaires ne consomment pas de cpu, alors la totalité des cpus physiques peut être utilisé par une zone de petite priorité. C'est donc la manière la plus souple de gérer l'attribution cpu et celle que je recommande.

Par défaut, une zone possède une part.

Mise en œuvre :

# zonecfg –z zone1
> set cpu-shares=20
> exit

Remarque : on peut utiliser d'autres schedulers que le FSS, mais c'est celui qui est recommandé par Sun/Oracle.

===Les Ressource Pools===

On attribue exclusivement des CPUs à une zone.

Pour "donner" 3 cpus à la zone zone1 :

# zonecfg –z zone1
> add dedicated-cpu
> set ncpus=3
> end
> exit

L'utilisation des ressource pool peut être intéressante en cas d'utilisation de logiciels dont la licence est fonction du nombre de processeurs.

===Les CPU caps===

Les CPUs caps définissent un pourcentage d'utilisation maximum d'un CPU pour une zone. Par exemple, une valeur de 3 signifie qu'une zone pourra utiliser au maximum 3 CPUs ; une valeur de 0.37 signifie qu'elle ne pourra utiliser que 37% d'un CPU.

Mise en œuvre :

# zonecfg –z zone1
> add capped-cpu
> set ncpus=0.37
> end
> exit

Pour changer la valeur à chaud :

prctl -r -n zone.cpu-cap -i zone -v 37 zone1

A noter que pour avoir 37% d'un cpu, il faut mettre 0.37 dans zonecfg, alors qu'avec prctl il faut mettre 37.

==Monitoring==

Les zones étant des process de la zone globale, il est difficile de distinguer la part de ressources utilisée par une zone.

On trouve quand même quelques commandes capable de donner des informations fiables :

* prstat –Z : pour afficher la quantité de mémoire et le pourcentage de CPU utilisés par zone

# prstat -Z
PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/NLWP
17147 1303 1184M 1171M sleep 59 0 10:31:35 2,5% oracle/258
17137 1303 1184M 1166M sleep 39 0 11:12:27 2,5% oracle/258
17144 1303 1184M 1171M cpu10 19 0 12:33:59 2,5% oracle/258
[…]
1069 root 6752K 3048K sleep 59 0 0:00:13 0,0% top/1
9511 4109 46M 20M sleep 47 4 0:15:55 0,0% LINT/1
ZONEID NPROC SWAP RSS MEMORY TIME CPU ZONE
20 73 1394M 1417M 4,3% 69:11:11 11% uirgs85
12 129 3466M 3407M 10% 20:46:52 1,7% uirgs39
0 75 222M 228M 0,7% 39:42:54 0,9% global
21 86 2887M 2911M 8,9% 23:52:49 0,6% uirgs38
17 58 2417M 2490M 7,6% 1:57:15 0,0% uirgs44
19 76 1403M 1462M 4,5% 1:35:22 0,0% uirgs46
13 45 703M 761M 2,3% 1:16:57 0,0% uirgs40
18 69 857M 931M 2,8% 1:44:56 0,0% uirgs45
14 46 351M 155M 0,5% 2:09:13 0,0% uirgs41
16 46 3194M 3209M 9,8% 8:46:48 0,0% uirgs43
15 29 18M 19M 0,1% 0:12:19 0,0% uirgs42

Total: 732 processes, 7586 lwps, load averages: 5,23, 5,53, 5,50

* prctl : pour afficher les paramètres actuels d'une zone

# prctl -i zone uirgs69
zone: 21: uirgs69
NAME PRIVILEGE VALUE FLAG ACTION RECIPIENT
zone.max-swap
privileged 8,00GB - deny -
system 16,0EB max deny -
zone.max-locked-memory
system 16,0EB max deny -
zone.max-shm-memory
system 16,0EB max deny -
zone.max-shm-ids
system 16,8M max deny -
zone.max-sem-ids
system 16,8M max deny -
zone.max-msg-ids
system 16,8M max deny -
zone.max-lwps
system 2,15G max deny -
zone.cpu-cap
system 4,29G inf deny -
zone.cpu-shares
privileged 1 - none -
system 65,5K max none -

* pour voir la consommation cpu en temps réel, et la valeur du cappage, on peut utiliser kstat. Par contre, la valeur retournée est affichée avec l'id de la zone, pas son nom. Il faudra donc faire la correspondance. Exemple :

kstat -p 'caps::/^cpucaps_zone/:' |egrep ":usage|:value"
caps:1:cpucaps_zone_1:usage 114
caps:1:cpucaps_zone_1:value 770
caps:3:cpucaps_zone_3:usage 5
caps:3:cpucaps_zone_3:value 400
caps:26:cpucaps_zone_26:usage 1
caps:26:cpucaps_zone_26:value 50
caps:34:cpucaps_zone_34:usage 5
caps:34:cpucaps_zone_34:value 50
caps:36:cpucaps_zone_36:usage 146
caps:36:cpucaps_zone_36:value 800
caps:42:cpucaps_zone_42:usage 3
caps:42:cpucaps_zone_42:value 80

A noter que "value 770" correspond à un "ncpu 7.7". "zone_26" correspond à la zone dont l'id est 26 (visible avec "zoneadm list -cv".

* il y a également les utilitaires habituels vmstat, iostat, mpstat et sar qui fonctionnent à l'intérieur de zones, mais il faut être très méfiant avec leur résultat : certaines informations concernent uniquement la zone, d'autres concernent le serveur (la zone globale).

=Automatiser/scripter la configuration des zones=

Il est possible de scripter la configuration des zones, plutôt que d'aller systématiquement dans le shell interractif de zonecfg. Ceci est particulièrement utile pour configurer un grand nombre de zones.

* Première méthode : zonecfg sur une seule ligne

On peut passer tous les paramètres désirés à zonecfg pour que tout tienne sur une seule ligne. Voici un exemple :

# zonecfg –z zone2 'add capped-memory ; set swap=4g ; set physical=4g; end'

Ainsi, on peut facilement faire un script avec une ou quelques lignes par zone.

* Deuxième méthode : créer un fichier de configuration et l'injecter dans zonecfg (principe utilisé pour les clones)

D'abord, on créé un fichier de configuration. Par exemple :

# vi zoneC.conf
create
set zonepath=/zones/zoneC
set autoboot=true
set ip-type=shared
add inherit-pkg-dir
set dir=/lib
end
add inherit-pkg-dir
set dir=/platform
end
add inherit-pkg-dir
set dir=/sbin
end
add inherit-pkg-dir
set dir=/usr
end
add fs
set dir=/opt
set special=/dev/vx/dsk/datadg/zoneC-opt
set raw=/dev/vx/rdsk/datadg/zoneC-opt
set type=vxfs
end
add net
set address=10.36.209.207/22
set physical=bge0
end
add rctl
set name=zone.max-swap
add value (priv=privileged,limit=8589934592,action=deny)
end
add capped-memory
set physical=8G
end

Ensuite on insère le tout dans la conf de zoneC :

# zonecfg –z zoneC –f zoneC.conf

Apt

2021-05-11T09:31:48Z

AdminWiki : /* Principales commandes */

[[Category:linux]]

Note : je ne fais ici qu'une brève présentation d'apt-get, avec les commandes qui servent le plus souvent. Pour avoir un cours complet, allez voir les liens dans le chapitre "Plus d'infos" en bas de cet article.

=Présentation=

Le gestionnaire de paquets par défaut de debian et ses dérivés, est dpkg. Apt est une surcouche de dpkg, qui automatise et simplifie de nombreuses commandes dpkg, notamment en gérant tout seul les dépendances. Apt est une suite d'outils, dont le principal est apt-get, qui sert à l'installation et la désinstallation des packages, et à la mise à jour du système.

Les packages pour debian ont l'extention ".deb".

Pour ceux qui n'aiment pas la ligne de commande, il existe "synaptic" qui est un excellent gestionnaire de packages graphique, qui s'appuie sur apt.

=Dépôts=

Pour installer un package, ou mettre à jour le système, apt-get va chercher les informations sur internet. Pour savoir où chercher, il va interroger le fichier /etc/apt/sources.list qui contient une liste de serveurs. Pour installer certains packages exotiques, ne figurants pas sur les mirroirs par défaut, il faudra rajouter une ou plusieurs lignes dans ce fichier (la ligne exacte à rajouter est quasiment toujours indiquée sur le site web du package en question, si une version debian existe).

=Principales commandes=

{|class="wikitable alternance centre"
|-
| apt-get update || mettre à jour la liste des packages disponibles dans les dépôts
|-
| apt-get upgrade || met à jour tous les packages installés sur le système (demande confirmation avant)
|-
| apt-get dist-upgrade || comme apt-get upgrade, mais si une nouvelle version de la distribution est disponible, l'installe. Dans ce cas, on aura mis avant à jour /etc/apt/sources.list avec les nouveaux dépôts. Attention, pour les dérivées de debian, il est préférable d'utiliser les outils fournis (cas d'ubuntu qui propose la mise à jour depuis l'interface graphique) ou d'aller voir la procédure complète sur la page web de la distribution.
|-
| apt-get install nom_package || installe le package "nom_package"
|-
| dpkg -i ./nom_package.deb || installe le package "nom_package.deb", précédement téléchargé sur le disque dur.
|-
| apt-get remove nom_package || désinstalle le package "nom_package", mais sans supprimer ses fichiers de configuration.
|-
| apt-get remove --purge nom_package || désinstalle totalement le package "nom_package" (y compris ses fichiers de configuration)
|-
| apt-get clean || vide le cache de apt, qui peut parfois occuper plusieurs centaines de Mo (fichier téléchargés par apt pour les installations, qui ne sont pas supprimés automatiquement).
|-
| apt-get autoclean || idem, mais ne supprime que les paquets qui ne sont plus disponibles sur les dépôts.
|-
| apt-cache search nom_paquet || recherche des infos sur le package "nom_paquet" installé ou non.
|-
| dpkg --get-selections "*nom_paquet*" (ou dpkg -l) || affiche la liste des packages installés (ou désinstallés sans le --purge)
|-
| apt-file search nom_fichier || recherche à quel package appartient le fichier "nom_fichier". Nécessite d'avoir fait au moins une fois "apt-file update". Nécessite le package apt-file, non installé par défaut. Sinon, préférer dkpg -S.
|-
| dkpg -S nom_fichier || recherche à quel package appartient le fichier "nom_fichier". Equivalent de "yum provides" chez Redhat.
|-
| dpkg -L nom_package || affiche la liste des fichiers du package (package installé)
|}

=Proxy=

Pour utiliser apt-get derrière un serveur mandataire (proxy), éditez le fichier /etc/apt/apt.conf (il faut le créer s'il n'existe pas) et ajoutez la ligne :

Acquire::http::Proxy "http://proxy:port";

ou

Acquire::http::Proxy "http://login:password@proxy:port";

=Plus d'infos=

Pour avoir plus d'informations et plus de commandes et options sur l'utilisation de apt et dpkg, allez sur le site [http://www.debian.org/doc/manuals/apt-howto/index.fr.html http://www.debian.org/doc/manuals/apt-howto/index.fr.html] ou sur [http://www.math-linux.com/spip.php?article58 http://www.math-linux.com/spip.php?article58].

Zones - Solaris

2021-05-07T13:26:29Z

AdminWiki : /* Création du fichier de configuration */

[[Category:solaris]]

=Présentation=

Les zones sont une solution de virtualisation intégré à Solaris. Elles sont à mi-chemin entre un chroot et un serveur virtuel. C'est à dire qu'on a un système d'exploitation hôte (appelé zone globale) dans lequel on fait tourner des process chrootés (donc qui ne voient pas les autres process de la zone globale ou des autres zones) qui sont en quelque sorte des "super process", car ils font tourner un système d'exploitation complet. Une partie des bibliothèques système sont communes entre les zones et la zone globale. C'est exactement le même principe que les jails BSD.

On peut créer des zones solaris 10 sparse (le type par défaut) ou big. Une zone sparse partage avec la zone globale les répertoires /usr, /lib, /sbin et /platform. Une big a une arborescence entièrement indépendante. La sparse va donc consommer moins d'espace disque, et lorsqu'on va patcher le système de la gloable, ça va patcher également les zones sparse. Ҫa peut-être soit un avantage soit un inconvénient. Il faut décider dès la création si on veut une sparse ou une big, car on ne peut pas changer après.

L'avantage de cette façon de virtualiser est qu'il n'y a pas besoin d'émuler la partie matérielle, gourmande en ressources. D'ailleurs, une zone qui ne fait pas tourner de process, ne consomme qu'une quarantaine de Mo.
L'inconvénient est qu'il faut adapter les systèmes d'exploitation pour qu'ils puissent tourner en tant que zone. Dans les premières versions de Solaris 10, on ne pouvait faire tourner que des zones solaris 10. Plus tard, on a introduit le concept de "branded zones", qui permettent de faire tourner d'autres systèmes d'exploitation en les adaptant. Depuis solaris 10 8/07, il existe des branded zones Solaris 8 et 9 (uniquement sur Sparc). Il existe aussi des branded zones opensolaris (et des solaris 10 pour opensolaris) et des linux. Les branded zones linux ne peuvent faire tourner que des Redhat et CentOS 3.5 à 3.8, donc un noyau 2.4.

Les zones sont gérées par deux daemons : zoneadmd pour la supervision et zsched qui est l'ordonnanceur.

=Les zones et le NFS=

Il faut noter qu'une zone ne peut pas être serveur NFS, il n'y a que la zone globale qui peut jouer ce rôle. Un astuce peut donc consister à monter le serveur NFS sur la globale et à partager un répertoire qui appartient à la zone (car la globale accède librement à tous les filesystems des zones via le zonepath – voir chapitre "''Installation/configuration d'une zone Solaris 10)''".

Par contre, n'importe quelle zone peut sans problème être client NFS.

Mise à jour : il paraît, mais je n'ai pas eu l'occasion de vérifier, qu'une zone peut être serveur NFS si elle a une interface réseau dédiée.

=Installation/configuration d'une zone Solaris 10=

==Prérequis==

Avant de créer une zone, il est nécessaire d'avoir prévu :

* un répertoire pour mettre son système (par exemple /zones/zone1), appelé "zonepath". Ce répertoire doit obligatoirement avec les droits 700, sans quoi l'installation échouera.
* une adresse ip
* l'interface réseau physique sur laquelle on va connecter cette ip (par exemple bge0)
* éventuellement les filesystems à créer, sinon on peut les rajouter après

==Création du fichier de configuration==

Pour créer/configurer une zone, on utilise l'outil zonecfg qui est un outil en mode texte avec un prompt particulier.
L'exemple ci-dessous montre assez clairement comment utiliser zonecfg :

# zonecfg –z zone1
create
set zonepath=/zones/zone1
set autoboot=true
add net
:set physical=bge0
:set address=10.36.210.56/22
:end
add fs
:set dir=/data
:set type=vxfs
:set raw=/dev/vx/rdsk/datadg/datalv
:set special==/dev/vx/dsk/datadg/datalv
:end
add fs
:set dir=/data2
:set type=zfs
:set special==zone1/data2
:end
verify
commit
exit

Remarques :

* on peut ajouter autant de filesystems (FS) qu'on veut ; on peut également n'en mettre aucun.
* '''Attention :''' pour les ZFS, pour qu'ils soient "montables" par la zone, il faut que sur la globale on ait '''"mountpoint=legacy"''' sur la globale.
* pour créer une zone big, il suffit de faire "create –b" au lieu de "create".
* verify et commit sont facultatifs. Verify sert à vérifier qu'il n'y a pas d'erreur ; il est conseillé de le faire. Commit sert à forcer l'enregistrement ; il est plutôt déconseillé de s'en servir, car il va enregistrer même s'il y a des erreurs. Exit va enregistrer et quitter.

En quittant, zonecfg créé un fichier /etc/zones/zone1.xml. Il est fortement déconseillé de modifier ce fichier directement, sans passer par zonecfg, sauf si on sait parfaitement ce qu'on fait.

==Installation de la zone==

Maintenant que le fichier de configuration est créé, on peut passer à l'installation de la zone (la création de tous les fichiers).

Attention : tous les filesystems déclarés à l'étape précédente avec "add fs" doivent être créés avant de passer à l'installation !

Pour installer la zone, une seule commande suffit :

# zoneadm –z zone1 install

Cette étape dure une dizaine de minutes (en fonction de la puissance du serveur). Ҫa va être un peu plus long pour une zone big.

==Booter et paramétrer la zone==

A ce stade, la zone est créée, mais est arrêtée. On va donc la démarrer. Au premier démarrage, on arrive dans l'utilitaire de configuration classique de Solaris, dans lequel on va choisir le type de clavier, la langue, le fuseau horaire, etc…

Pour booter la zone :

# zoneadm –z zone1 boot

Pour se connecter dessus en mode console :

# zlogin –C zone1

Pour quitter le mode console : taper "~.".

Notre zone "zone1" est maintenant accessible comme n'importe quel serveur.

=Installation/configuration de zones Solaris 8 et 9=

==Prérequis==

L'installation de containers Solaris 8 et 9 nécessite l'ajout de packages supplémentaires :

* SUNWs8brandk, SUNWs8brandr et SUNWs8brandu pour Solaris 8
* SUNWs9brandk, SUNWs9brandr et SUNWs9brandu pour Solaris 9

==Création d'une flash archive==

Une zone Solaris 8 ou 9 s'installe depuis une archive flash (fichier .flar). On peut trouver des archives de ce type sur le web, mais la plupart du temps, ces zones sont destinées à remplacer des serveurs physiques existants. On va donc créer une image flash depuis un serveur existant.

Voici un exemple de création d'image flash (à lancer depuis le serveur à sauvegarder) :

# flarcreate –S –c –n sol8_204 –x /u01 –x /u02 –x /backup /backup/sol8_204.flar

Explications :

* -S : évite de verifier l'espace dispo sur le disque de destination, et écrit l'image directement sur le disque (passe par la RAM sinon)
* -c : compresse l'image
* -n : label
* -x : filesystems à ne pas inclure. Attention : une image flash intègre par défaut l'ensemble des filesystems locaux et distants, il faut donc bien penser à exclure (ou préalablement démonter) les montages NFS et autres lecteurs DVD.
* à la fin de la commande, on met le nom du fichier de destination

==Création du fichier de configuration==

La création du fichier de configuration se fait également avec zonecfg.

A noter, quelques petites différences :

* lors du create, il faut taper respectivement pour des Solaris 8 et 9 :

create –t SUNWsolaris8
create –t SUNWsolaris9

* on peut ajouter les attributs suivants (utiles pour la migration d'un serveur existant, principalement pour des questions de licences :

> add attr
set name=hostid
set type=string
set value=<hostid du serveur à migrer>
end
> addattr
set name=machine
set type=string
set value=sun4u
end

'''ATTENTION :''' depuis les dernières versions de Solaris, cette méthode ne fonctionne plus pour le hostid. Il faut juste faire "'''set hostid=<valeur>'''". C'est encore plus simple.

==Installation de la zone==

On va maintenant procéder à l'installation, en utilisant l'archive flash, qu'on aura déposé au préalable sur la zone globale (par exemple /var/tmp/sol8_204.flar)

# zoneadm –z zone2 install –u –a /var/tmp/sol8_204.flar

L'option "-u" fait un unconfigure pour forcer la reconfiguration au boot.

==Booter et paramétrer la zone==

Ici, c'est exactement comme les zones Solaris 10.

# zoneadm –z zone2 boot
# zlogin –C zone2

=Gestion des zones=

==Lister==

Pour voir la liste des zones, on utilise "zoneadm list", de préférence avec les options "-cv" pour plus de détails.

Exemple :

root@uirgs37 # zoneadm list
global
uirgs39
uirgs40
uirgs41
uirgs42
uirgs43
uirgs44
uirgs45
uirgs46
uirgs85
uirgs38
root@uirgs37 # zoneadm list -cv
ID NAME STATUS PATH BRAND IP
0 global running / native shared
12 uirgs39 running /zones/uirgs39 native shared
13 uirgs40 running /zones/uirgs40 native shared
14 uirgs41 running /zones/uirgs41 solaris8 shared
15 uirgs42 running /zones/uirgs42 solaris9 shared
16 uirgs43 running /zones/uirgs43 solaris9 shared
17 uirgs44 running /zones/uirgs44 native shared
18 uirgs45 running /zones/uirgs45 native shared
19 uirgs46 running /zones/uirgs46 native shared
20 uirgs85 running /zones/uirgs85 solaris8 shared
21 uirgs38 running /zones/uirgs38 solaris8 shared
root@uirgs37 #

On voit que la globale apparait comme une zone dans la liste.

L'option "-cv" permet également de voir l'état d'une zone. Voici les principaux états que peut avoir une zone :

* configured : configurée, mais pas encore installée
* installed : installée et arrêtée
* running : elle fonctionne

==Connexion==

Pour se connecter à une zone, on utilise zlogin, suivi du nom de la zone.

# zlogin zone1

Pour se connecter comme si on était sur la console (permet par exemple de voir les messages au boot) :

# zlogin -C zone1

Pour quitter on fait ~. en tapant rapidement. Il est parfois nécessaire d'appuyer plusieurs fois sur ".". Il ne peut y avoir qu'une seule personne connectée en mode console.

==Arrêt/reboot==

Pour arrêter, démarrer ou rebooter une zone, on utilise :

# zoneadm –z zone1 halt
# zoneadm –z zone1 boot
# zoneadm –z zone1 reboot

==Forcer l'arrêt==

Il arrive parfois qu'une zone refuse de s'arrêter et reste dans l'état "down" ou "shutting down". Il est difficile de déterminer quel est ou quels sont les process qui refusent de mourir. Dans ce cas, la commande suivante peut nous sauver :

# pkill -9 -z zonename

Si même cette commande ne fonctionne pas, on est mal barré ! Il est probable qu'on soit obligé de rebooter la globale.

A noter que parfois il est nécessaire de relancer un "zoneadm -z zone halt" après le pkill.

=Supprimer une zone=

Pour supprimer une zone, il faut d'abort la passer à l'état "configured" :

# zoneadm –z zone3 uninstall

Puis on la supprime définitivement :

# zonecfg –z zone3 delete

=Cloner une zone=

Le clonage permet de dupliquer une zone existant sans avoir à refaire une archive flash. Le clone ne concerne que la partie système, c'est à dire qu'une fois le clone terminé, il va falloir recopier à la main les filesystems additionnels.

Dans l'exemple qui suit, on va cloner la zone "zoneA" vers "zoneB".

* exporter la configuration de la zone zoneA

# zonecfg –z zoneA export –f /tmp/zoneB.zonecfg

* éditer le fichier /tmp/zoneB.zonecfg et modifier tout ce qu'il faut adapter (adresse ip, zonepath, etc)
* créer les systèmes de fichiers qui seront utilisés par la zone zoneB
* modifier les droits du zonepath du futur clone

# chmod 700 /zones/zoneB

* créer la nouvelle zone

# zonecfg –z zoneB –f /tmp/zoneB.zonecfg

* arrêter zoneA (indispensable pour que la copie des fichiers soit cohérente)

# zlogin zoneA init 0

* cloner les contenus

# zoneadm –z zoneB clone zoneA

* redémarrer zoneA

# zoneadm –z zoneA boot

* on peut maintenant démarrer et configurer la nouvelle zone

# zoneadm –z zoneB boot
# zlogin –C zoneB

Dans certains cas, il peut être nécessaire de forcer la nouvelle zone à passer de l'état "configured" à "installed". On le fait avec la commande suivante :

# zoneadm –z zoneB attach -F

=Flying zones=

==Présentation==

Flying zone est le terme commercial employé par Sun/Oracle pour décrire la procédure qui consiste à migrer une zone d'une globale vers une autre. En réalité, tout se fait manuellement, rien n'est automatique, c'est 100 fois moins bien que vmware, mais le terme "Flying zone", ça pète !

Pour pouvoir migrer les données de la zone, il faut soit copier les données de la globale de départ vers celle d'arrivée, soit avoir ces données accessibles par les deux serveurs (par exemple un SAN).

Nous allons ici prendre l'exemple de la zone '''zone1''' qui se trouve sur la globale '''zglobale1''' et qu'on va migrer sur la '''zglobale2'''. Les données de la zone sont dans deux zpools "zp_zone1" et "zp_zone1_data". Les zpools sont sur un SAN connecté aux deux globales. Ils sont actuellement montés sur la première ; ils sont visibles de la deuxième, mais pas importés (on ne peut pas importer des zpools sur deux serveurs à la fois).

==Procédure==

La procédure se fait en 7 étapes.

'''Sur la première globale :'''

* éteindre la zone :

zglobale1# zlogin zone1 init 5

* detacher la zone

zglobale1# zoneadm -z zone1 detach

* exporter les zpools

zglobale1# zpool export zp_zone1
zglobale1# zpool export zp_zone1_data

'''Sur la deuxième globale :'''

* importer les zpools

zglobale2# zpool import zp_zone1
zglobale2# zpool import zp_zone1_data

* récuperer la configuration de la zone

zglobale2# scp zglobale1:/etc/zones/zone1.xml /etc/zones/

* attacher la zone

zglobale2# zoneadm -z zone1 attach

* démarrer la zone

zglobale2# zoneadm -z zone1 boot

'''Remarque :''' il se peut que l'attachement de la zone ne fonctionne pas la première fois, même en forçant avec l'option "-F". Dans ce cas, il faut ajouter une ligne dans le fichier '''/etc/zones/index''', puis refaire le attach :

zglobale2# echo 'zone1:configured:/zones/zone1:' >> /etc/zones/index
zglobale2# zglobale2# zoneadm -z zone1 attach

==Retour arrière==

On fait l'inverse, tout simplement...

* éteindre la zone

zglobale2# zlogin zone1 init 5

* détacher la zone

zglobale2# zoneadm -z zone1 detach

* exporter les zpools

zglobale2# zpool export zp_zone1
zglobale2# zpool export zp_zone1_data

* importer les zpools

zglobale1# zpool import zp_zone1
zglobale1# zpool import zp_zone1_data

* récuperer la configuration de la zone

zglobale2# scp /etc/zones/zone1.xml zglobale1:/etc/zones/

* attacher la zone

zglobale1# zoneadm -z zone1 attach

* démarrer la zone

zglobale1# zoneadm -z zone1 boot

=Gestion des ressources=

==Présentation==

Par défaut, les ressources RAM, swap et CPU sont communes à toutes les zones, y compris la globale. C'est-à-dire qu'une zone qui a un problème peut s'attribuer toutes les ressources, écrouler toutes les autres zones et même planter la globale. Il existe des moyens de limiter les ressources de chaque zone pour empêcher ça.

Toutes ces manipulations se font depuis la zone globale.

==Limitation de la RAM==

Pour voir la RAM actuellement attribuée aux zones :

# rcapstat -z
id zone nproc vm rss cap at avgat pg avgpg
1 uirgs50 - 833M 921M 8192M 0K 0K 0K 0K
2 uirgs52 - 712M 767M 8192M 0K 0K 0K 0K
3 uirgs49 - 2789M 2816M 8192M 0K 0K 0K 0K
[…]

Ҫa va afficher les valeurs pour toutes les zones. Il faut regarder la colonne "'''cap'''".

Pour modifier la valeur à chaud (attention, la modification sera perdue au prochain reboot) :

# rcapadm –z zone1 –m 4g

Il faut attendre quelques secondes pour que ce soit pris en compte.

Si on obtient un message du genre '''"rcapadm: resource caps not configured"''', alors c'est qu'il faut "enabler" les memory caps avec la commande suivante :

# rcapadm -E

Ensuite il faut retaper la commande rcapadm ci-dessus.

Pour limiter la RAM dans la configuration (pour qu'elle soit permanente à chaque reboot), suivre l'exemple suivant :

# zonecfg –z zone1
> add capped-memory
> set physical=4g
> end
> exit

La limitation ne sera effective qu'au prochain boot de la zone.

Si le paramètre "'''capped-memory'''" existe déjà, on peut le modifier de la manière suivante :

# zonecfg –z zone1
> select capped-memory
> set physical=4g
> end
> exit

==Limitation du swap==

Pour voir la quantité de swap actuellement allouée :

# prctl -n zone.max-swap -i zone zoneB
zone: 21: zoneB
NAME PRIVILEGE VALUE FLAG ACTION RECIPIENT
zone.max-swap
privileged 4,00GB - deny -
system 16,0EB max deny -

Il faut lire la ligne "'''privileged'''".

Pour modifier la valeur à chaud (attention, la modification sera perdue au prochain reboot) :

# prctl -r -n zone.max-swap -i zone -v 6g ma_zone

Attention, cette commande ne fonctionne que pour modifier une valeur existante. Si aucune limitation de swap n'a jamais été appliquée sur cette zone, utiliser la commande suivante :

# prctl -n zone.max-swap -v 6g -t privileged -e deny -s -i zone ma_zone

Re-attention, si vous venez de taper la commande ci-dessus alors que vous aviez déjà une limitation, alors vous n'avez pas modifié la limitation, vous en avez ajouté une deuxième ! Du coup, le système applique la plus restrictive. Pour réparer cette bêtise (c'est du vécu...), annulez la dernière commande avec :

# prctl -n zone.max-swap -i zone -t privileged -x ma_zone

Pour limiter le swap dans la configuration (pour qu'il soit permanent à chaque reboot), suivre l'exemple suivant :

# zonecfg -z zone1
> add capped-memory
> set swap=4g
> end
> exit

La limitation ne sera effective qu'au prochain boot de la zone.

Si le paramètre "'''capped-memory'''" existe déjà, on peut le modifier de la manière suivante :

# zonecfg -z zone1
> select capped-memory
> set swap=4g
> end
> exit

==Limitation du CPU==

Il y a trois méthodes possibles pour limiter l'utilisation CPU :

* '''le Fair Share Scheduler (FSS)''' : on attribue une part minimale de CPU à une zone
* '''les Ressource Pools''' : dédie exclusivement des CPUs à une zone
* '''les CPU caps''' : alloue statiquement des pourcentages de CPU à une zone

===Le Fair Share Scheduler (FSS)===

On alloue un certain nombre de parts de CPU à une zone. Il n'y a pas de nombre de parts prédéfini à partager. Le principe est que plus une zone a de parts, plus elle aura de temps CPU attribué. Par exemple, une zone qui a 20 parts aura deux fois plus de temps CPU qu'une zone à 10 parts. Peu importe le nombre total de parts, il ne représente rien de physique. Donc en fait, on attribue une priorité à chaque zone, et cette priorité ne sert que en cas de conflit. C'est à dire que si tous les cpus sont à 100%, les priorités s'appliquent, mais si les zones les plus prioritaires ne consomment pas de cpu, alors la totalité des cpus physiques peut être utilisé par une zone de petite priorité. C'est donc la manière la plus souple de gérer l'attribution cpu et celle que je recommande.

Par défaut, une zone possède une part.

Mise en œuvre :

# zonecfg –z zone1
> set cpu-shares=20
> exit

Remarque : on peut utiliser d'autres schedulers que le FSS, mais c'est celui qui est recommandé par Sun/Oracle.

===Les Ressource Pools===

On attribue exclusivement des CPUs à une zone.

Pour "donner" 3 cpus à la zone zone1 :

# zonecfg –z zone1
> add dedicated-cpu
> set ncpus=3
> end
> exit

L'utilisation des ressource pool peut être intéressante en cas d'utilisation de logiciels dont la licence est fonction du nombre de processeurs.

===Les CPU caps===

Les CPUs caps définissent un pourcentage d'utilisation maximum d'un CPU pour une zone. Par exemple, une valeur de 3 signifie qu'une zone pourra utiliser au maximum 3 CPUs ; une valeur de 0.37 signifie qu'elle ne pourra utiliser que 37% d'un CPU.

Mise en œuvre :

# zonecfg –z zone1
> add capped-cpu
> set ncpus=0.37
> end
> exit

Pour changer la valeur à chaud :

prctl -r -n zone.cpu-cap -i zone -v 37 zone1

A noter que pour avoir 37% d'un cpu, il faut mettre 0.37 dans zonecfg, alors qu'avec prctl il faut mettre 37.

==Monitoring==

Les zones étant des process de la zone globale, il est difficile de distinguer la part de ressources utilisée par une zone.

On trouve quand même quelques commandes capable de donner des informations fiables :

* prstat –Z : pour afficher la quantité de mémoire et le pourcentage de CPU utilisés par zone

# prstat -Z
PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/NLWP
17147 1303 1184M 1171M sleep 59 0 10:31:35 2,5% oracle/258
17137 1303 1184M 1166M sleep 39 0 11:12:27 2,5% oracle/258
17144 1303 1184M 1171M cpu10 19 0 12:33:59 2,5% oracle/258
[…]
1069 root 6752K 3048K sleep 59 0 0:00:13 0,0% top/1
9511 4109 46M 20M sleep 47 4 0:15:55 0,0% LINT/1
ZONEID NPROC SWAP RSS MEMORY TIME CPU ZONE
20 73 1394M 1417M 4,3% 69:11:11 11% uirgs85
12 129 3466M 3407M 10% 20:46:52 1,7% uirgs39
0 75 222M 228M 0,7% 39:42:54 0,9% global
21 86 2887M 2911M 8,9% 23:52:49 0,6% uirgs38
17 58 2417M 2490M 7,6% 1:57:15 0,0% uirgs44
19 76 1403M 1462M 4,5% 1:35:22 0,0% uirgs46
13 45 703M 761M 2,3% 1:16:57 0,0% uirgs40
18 69 857M 931M 2,8% 1:44:56 0,0% uirgs45
14 46 351M 155M 0,5% 2:09:13 0,0% uirgs41
16 46 3194M 3209M 9,8% 8:46:48 0,0% uirgs43
15 29 18M 19M 0,1% 0:12:19 0,0% uirgs42

Total: 732 processes, 7586 lwps, load averages: 5,23, 5,53, 5,50

* prctl : pour afficher les paramètres actuels d'une zone

# prctl -i zone uirgs69
zone: 21: uirgs69
NAME PRIVILEGE VALUE FLAG ACTION RECIPIENT
zone.max-swap
privileged 8,00GB - deny -
system 16,0EB max deny -
zone.max-locked-memory
system 16,0EB max deny -
zone.max-shm-memory
system 16,0EB max deny -
zone.max-shm-ids
system 16,8M max deny -
zone.max-sem-ids
system 16,8M max deny -
zone.max-msg-ids
system 16,8M max deny -
zone.max-lwps
system 2,15G max deny -
zone.cpu-cap
system 4,29G inf deny -
zone.cpu-shares
privileged 1 - none -
system 65,5K max none -

* pour voir la consommation cpu en temps réel, et la valeur du cappage, on peut utiliser kstat. Par contre, la valeur retournée est affichée avec l'id de la zone, pas son nom. Il faudra donc faire la correspondance. Exemple :

kstat -p 'caps::/^cpucaps_zone/:' |egrep ":usage|:value"
caps:1:cpucaps_zone_1:usage 114
caps:1:cpucaps_zone_1:value 770
caps:3:cpucaps_zone_3:usage 5
caps:3:cpucaps_zone_3:value 400
caps:26:cpucaps_zone_26:usage 1
caps:26:cpucaps_zone_26:value 50
caps:34:cpucaps_zone_34:usage 5
caps:34:cpucaps_zone_34:value 50
caps:36:cpucaps_zone_36:usage 146
caps:36:cpucaps_zone_36:value 800
caps:42:cpucaps_zone_42:usage 3
caps:42:cpucaps_zone_42:value 80

A noter que "value 770" correspond à un "ncpu 7.7". "zone_26" correspond à la zone dont l'id est 26 (visible avec "zoneadm list -cv".

* il y a également les utilitaires habituels vmstat, iostat, mpstat et sar qui fonctionnent à l'intérieur de zones, mais il faut être très méfiant avec leur résultat : certaines informations concernent uniquement la zone, d'autres concernent le serveur (la zone globale).

=Automatiser/scripter la configuration des zones=

Il est possible de scripter la configuration des zones, plutôt que d'aller systématiquement dans le shell interractif de zonecfg. Ceci est particulièrement utile pour configurer un grand nombre de zones.

* Première méthode : zonecfg sur une seule ligne

On peut passer tous les paramètres désirés à zonecfg pour que tout tienne sur une seule ligne. Voici un exemple :

# zonecfg –z zone2 'add capped-memory ; set swap=4g ; set physical=4g; end'

Ainsi, on peut facilement faire un script avec une ou quelques lignes par zone.

* Deuxième méthode : créer un fichier de configuration et l'injecter dans zonecfg (principe utilisé pour les clones)

D'abord, on créé un fichier de configuration. Par exemple :

# vi zoneC.conf
create
set zonepath=/zones/zoneC
set autoboot=true
set ip-type=shared
add inherit-pkg-dir
set dir=/lib
end
add inherit-pkg-dir
set dir=/platform
end
add inherit-pkg-dir
set dir=/sbin
end
add inherit-pkg-dir
set dir=/usr
end
add fs
set dir=/opt
set special=/dev/vx/dsk/datadg/zoneC-opt
set raw=/dev/vx/rdsk/datadg/zoneC-opt
set type=vxfs
end
add net
set address=10.36.209.207/22
set physical=bge0
end
add rctl
set name=zone.max-swap
add value (priv=privileged,limit=8589934592,action=deny)
end
add capped-memory
set physical=8G
end

Ensuite on insère le tout dans la conf de zoneC :

# zonecfg –z zoneC –f zoneC.conf

Zones - Solaris

2021-05-07T13:25:51Z

AdminWiki : /* Création du fichier de configuration */

[[Category:solaris]]

=Présentation=

Les zones sont une solution de virtualisation intégré à Solaris. Elles sont à mi-chemin entre un chroot et un serveur virtuel. C'est à dire qu'on a un système d'exploitation hôte (appelé zone globale) dans lequel on fait tourner des process chrootés (donc qui ne voient pas les autres process de la zone globale ou des autres zones) qui sont en quelque sorte des "super process", car ils font tourner un système d'exploitation complet. Une partie des bibliothèques système sont communes entre les zones et la zone globale. C'est exactement le même principe que les jails BSD.

On peut créer des zones solaris 10 sparse (le type par défaut) ou big. Une zone sparse partage avec la zone globale les répertoires /usr, /lib, /sbin et /platform. Une big a une arborescence entièrement indépendante. La sparse va donc consommer moins d'espace disque, et lorsqu'on va patcher le système de la gloable, ça va patcher également les zones sparse. Ҫa peut-être soit un avantage soit un inconvénient. Il faut décider dès la création si on veut une sparse ou une big, car on ne peut pas changer après.

L'avantage de cette façon de virtualiser est qu'il n'y a pas besoin d'émuler la partie matérielle, gourmande en ressources. D'ailleurs, une zone qui ne fait pas tourner de process, ne consomme qu'une quarantaine de Mo.
L'inconvénient est qu'il faut adapter les systèmes d'exploitation pour qu'ils puissent tourner en tant que zone. Dans les premières versions de Solaris 10, on ne pouvait faire tourner que des zones solaris 10. Plus tard, on a introduit le concept de "branded zones", qui permettent de faire tourner d'autres systèmes d'exploitation en les adaptant. Depuis solaris 10 8/07, il existe des branded zones Solaris 8 et 9 (uniquement sur Sparc). Il existe aussi des branded zones opensolaris (et des solaris 10 pour opensolaris) et des linux. Les branded zones linux ne peuvent faire tourner que des Redhat et CentOS 3.5 à 3.8, donc un noyau 2.4.

Les zones sont gérées par deux daemons : zoneadmd pour la supervision et zsched qui est l'ordonnanceur.

=Les zones et le NFS=

Il faut noter qu'une zone ne peut pas être serveur NFS, il n'y a que la zone globale qui peut jouer ce rôle. Un astuce peut donc consister à monter le serveur NFS sur la globale et à partager un répertoire qui appartient à la zone (car la globale accède librement à tous les filesystems des zones via le zonepath – voir chapitre "''Installation/configuration d'une zone Solaris 10)''".

Par contre, n'importe quelle zone peut sans problème être client NFS.

Mise à jour : il paraît, mais je n'ai pas eu l'occasion de vérifier, qu'une zone peut être serveur NFS si elle a une interface réseau dédiée.

=Installation/configuration d'une zone Solaris 10=

==Prérequis==

Avant de créer une zone, il est nécessaire d'avoir prévu :

* un répertoire pour mettre son système (par exemple /zones/zone1), appelé "zonepath". Ce répertoire doit obligatoirement avec les droits 700, sans quoi l'installation échouera.
* une adresse ip
* l'interface réseau physique sur laquelle on va connecter cette ip (par exemple bge0)
* éventuellement les filesystems à créer, sinon on peut les rajouter après

==Création du fichier de configuration==

Pour créer/configurer une zone, on utilise l'outil zonecfg qui est un outil en mode texte avec un prompt particulier.
L'exemple ci-dessous montre assez clairement comment utiliser zonecfg :

# zonecfg –z zone1
create
set zonepath=/zones/zone1
set autoboot=true
add net
:set physical=bge0
:set address=10.36.210.56/22
:end
add fs
:set dir=/data
:set type=vxfs
:set raw=/dev/vx/rdsk/datadg/datalv
:set special==/dev/vx/dsk/datadg/datalv
:end
add fs
:set dir=/data2
:set type=zfs
:set special==zone1/data2
:end
verify
commit
exit

Remarques :

* on peut ajouter autant de filesystems (FS) qu'on veut ; on peut également n'en mettre aucun.
* Attention : pour les ZFS, pour qu'ils soient "montables" par la zone, il faut que sur la globale on ait '''"mountpoint=legacy"''' sur la globale.
* pour créer une zone big, il suffit de faire "create –b" au lieu de "create".
* verify et commit sont facultatifs. Verify sert à vérifier qu'il n'y a pas d'erreur ; il est conseillé de le faire. Commit sert à forcer l'enregistrement ; il est plutôt déconseillé de s'en servir, car il va enregistrer même s'il y a des erreurs. Exit va enregistrer et quitter.

En quittant, zonecfg créé un fichier /etc/zones/zone1.xml. Il est fortement déconseillé de modifier ce fichier directement, sans passer par zonecfg, sauf si on sait parfaitement ce qu'on fait.

==Installation de la zone==

Maintenant que le fichier de configuration est créé, on peut passer à l'installation de la zone (la création de tous les fichiers).

Attention : tous les filesystems déclarés à l'étape précédente avec "add fs" doivent être créés avant de passer à l'installation !

Pour installer la zone, une seule commande suffit :

# zoneadm –z zone1 install

Cette étape dure une dizaine de minutes (en fonction de la puissance du serveur). Ҫa va être un peu plus long pour une zone big.

==Booter et paramétrer la zone==

A ce stade, la zone est créée, mais est arrêtée. On va donc la démarrer. Au premier démarrage, on arrive dans l'utilitaire de configuration classique de Solaris, dans lequel on va choisir le type de clavier, la langue, le fuseau horaire, etc…

Pour booter la zone :

# zoneadm –z zone1 boot

Pour se connecter dessus en mode console :

# zlogin –C zone1

Pour quitter le mode console : taper "~.".

Notre zone "zone1" est maintenant accessible comme n'importe quel serveur.

=Installation/configuration de zones Solaris 8 et 9=

==Prérequis==

L'installation de containers Solaris 8 et 9 nécessite l'ajout de packages supplémentaires :

* SUNWs8brandk, SUNWs8brandr et SUNWs8brandu pour Solaris 8
* SUNWs9brandk, SUNWs9brandr et SUNWs9brandu pour Solaris 9

==Création d'une flash archive==

Une zone Solaris 8 ou 9 s'installe depuis une archive flash (fichier .flar). On peut trouver des archives de ce type sur le web, mais la plupart du temps, ces zones sont destinées à remplacer des serveurs physiques existants. On va donc créer une image flash depuis un serveur existant.

Voici un exemple de création d'image flash (à lancer depuis le serveur à sauvegarder) :

# flarcreate –S –c –n sol8_204 –x /u01 –x /u02 –x /backup /backup/sol8_204.flar

Explications :

* -S : évite de verifier l'espace dispo sur le disque de destination, et écrit l'image directement sur le disque (passe par la RAM sinon)
* -c : compresse l'image
* -n : label
* -x : filesystems à ne pas inclure. Attention : une image flash intègre par défaut l'ensemble des filesystems locaux et distants, il faut donc bien penser à exclure (ou préalablement démonter) les montages NFS et autres lecteurs DVD.
* à la fin de la commande, on met le nom du fichier de destination

==Création du fichier de configuration==

La création du fichier de configuration se fait également avec zonecfg.

A noter, quelques petites différences :

* lors du create, il faut taper respectivement pour des Solaris 8 et 9 :

create –t SUNWsolaris8
create –t SUNWsolaris9

* on peut ajouter les attributs suivants (utiles pour la migration d'un serveur existant, principalement pour des questions de licences :

> add attr
set name=hostid
set type=string
set value=<hostid du serveur à migrer>
end
> addattr
set name=machine
set type=string
set value=sun4u
end

'''ATTENTION :''' depuis les dernières versions de Solaris, cette méthode ne fonctionne plus pour le hostid. Il faut juste faire "'''set hostid=<valeur>'''". C'est encore plus simple.

==Installation de la zone==

On va maintenant procéder à l'installation, en utilisant l'archive flash, qu'on aura déposé au préalable sur la zone globale (par exemple /var/tmp/sol8_204.flar)

# zoneadm –z zone2 install –u –a /var/tmp/sol8_204.flar

L'option "-u" fait un unconfigure pour forcer la reconfiguration au boot.

==Booter et paramétrer la zone==

Ici, c'est exactement comme les zones Solaris 10.

# zoneadm –z zone2 boot
# zlogin –C zone2

=Gestion des zones=

==Lister==

Pour voir la liste des zones, on utilise "zoneadm list", de préférence avec les options "-cv" pour plus de détails.

Exemple :

root@uirgs37 # zoneadm list
global
uirgs39
uirgs40
uirgs41
uirgs42
uirgs43
uirgs44
uirgs45
uirgs46
uirgs85
uirgs38
root@uirgs37 # zoneadm list -cv
ID NAME STATUS PATH BRAND IP
0 global running / native shared
12 uirgs39 running /zones/uirgs39 native shared
13 uirgs40 running /zones/uirgs40 native shared
14 uirgs41 running /zones/uirgs41 solaris8 shared
15 uirgs42 running /zones/uirgs42 solaris9 shared
16 uirgs43 running /zones/uirgs43 solaris9 shared
17 uirgs44 running /zones/uirgs44 native shared
18 uirgs45 running /zones/uirgs45 native shared
19 uirgs46 running /zones/uirgs46 native shared
20 uirgs85 running /zones/uirgs85 solaris8 shared
21 uirgs38 running /zones/uirgs38 solaris8 shared
root@uirgs37 #

On voit que la globale apparait comme une zone dans la liste.

L'option "-cv" permet également de voir l'état d'une zone. Voici les principaux états que peut avoir une zone :

* configured : configurée, mais pas encore installée
* installed : installée et arrêtée
* running : elle fonctionne

==Connexion==

Pour se connecter à une zone, on utilise zlogin, suivi du nom de la zone.

# zlogin zone1

Pour se connecter comme si on était sur la console (permet par exemple de voir les messages au boot) :

# zlogin -C zone1

Pour quitter on fait ~. en tapant rapidement. Il est parfois nécessaire d'appuyer plusieurs fois sur ".". Il ne peut y avoir qu'une seule personne connectée en mode console.

==Arrêt/reboot==

Pour arrêter, démarrer ou rebooter une zone, on utilise :

# zoneadm –z zone1 halt
# zoneadm –z zone1 boot
# zoneadm –z zone1 reboot

==Forcer l'arrêt==

Il arrive parfois qu'une zone refuse de s'arrêter et reste dans l'état "down" ou "shutting down". Il est difficile de déterminer quel est ou quels sont les process qui refusent de mourir. Dans ce cas, la commande suivante peut nous sauver :

# pkill -9 -z zonename

Si même cette commande ne fonctionne pas, on est mal barré ! Il est probable qu'on soit obligé de rebooter la globale.

A noter que parfois il est nécessaire de relancer un "zoneadm -z zone halt" après le pkill.

=Supprimer une zone=

Pour supprimer une zone, il faut d'abort la passer à l'état "configured" :

# zoneadm –z zone3 uninstall

Puis on la supprime définitivement :

# zonecfg –z zone3 delete

=Cloner une zone=

Le clonage permet de dupliquer une zone existant sans avoir à refaire une archive flash. Le clone ne concerne que la partie système, c'est à dire qu'une fois le clone terminé, il va falloir recopier à la main les filesystems additionnels.

Dans l'exemple qui suit, on va cloner la zone "zoneA" vers "zoneB".

* exporter la configuration de la zone zoneA

# zonecfg –z zoneA export –f /tmp/zoneB.zonecfg

* éditer le fichier /tmp/zoneB.zonecfg et modifier tout ce qu'il faut adapter (adresse ip, zonepath, etc)
* créer les systèmes de fichiers qui seront utilisés par la zone zoneB
* modifier les droits du zonepath du futur clone

# chmod 700 /zones/zoneB

* créer la nouvelle zone

# zonecfg –z zoneB –f /tmp/zoneB.zonecfg

* arrêter zoneA (indispensable pour que la copie des fichiers soit cohérente)

# zlogin zoneA init 0

* cloner les contenus

# zoneadm –z zoneB clone zoneA

* redémarrer zoneA

# zoneadm –z zoneA boot

* on peut maintenant démarrer et configurer la nouvelle zone

# zoneadm –z zoneB boot
# zlogin –C zoneB

Dans certains cas, il peut être nécessaire de forcer la nouvelle zone à passer de l'état "configured" à "installed". On le fait avec la commande suivante :

# zoneadm –z zoneB attach -F

=Flying zones=

==Présentation==

Flying zone est le terme commercial employé par Sun/Oracle pour décrire la procédure qui consiste à migrer une zone d'une globale vers une autre. En réalité, tout se fait manuellement, rien n'est automatique, c'est 100 fois moins bien que vmware, mais le terme "Flying zone", ça pète !

Pour pouvoir migrer les données de la zone, il faut soit copier les données de la globale de départ vers celle d'arrivée, soit avoir ces données accessibles par les deux serveurs (par exemple un SAN).

Nous allons ici prendre l'exemple de la zone '''zone1''' qui se trouve sur la globale '''zglobale1''' et qu'on va migrer sur la '''zglobale2'''. Les données de la zone sont dans deux zpools "zp_zone1" et "zp_zone1_data". Les zpools sont sur un SAN connecté aux deux globales. Ils sont actuellement montés sur la première ; ils sont visibles de la deuxième, mais pas importés (on ne peut pas importer des zpools sur deux serveurs à la fois).

==Procédure==

La procédure se fait en 7 étapes.

'''Sur la première globale :'''

* éteindre la zone :

zglobale1# zlogin zone1 init 5

* detacher la zone

zglobale1# zoneadm -z zone1 detach

* exporter les zpools

zglobale1# zpool export zp_zone1
zglobale1# zpool export zp_zone1_data

'''Sur la deuxième globale :'''

* importer les zpools

zglobale2# zpool import zp_zone1
zglobale2# zpool import zp_zone1_data

* récuperer la configuration de la zone

zglobale2# scp zglobale1:/etc/zones/zone1.xml /etc/zones/

* attacher la zone

zglobale2# zoneadm -z zone1 attach

* démarrer la zone

zglobale2# zoneadm -z zone1 boot

'''Remarque :''' il se peut que l'attachement de la zone ne fonctionne pas la première fois, même en forçant avec l'option "-F". Dans ce cas, il faut ajouter une ligne dans le fichier '''/etc/zones/index''', puis refaire le attach :

zglobale2# echo 'zone1:configured:/zones/zone1:' >> /etc/zones/index
zglobale2# zglobale2# zoneadm -z zone1 attach

==Retour arrière==

On fait l'inverse, tout simplement...

* éteindre la zone

zglobale2# zlogin zone1 init 5

* détacher la zone

zglobale2# zoneadm -z zone1 detach

* exporter les zpools

zglobale2# zpool export zp_zone1
zglobale2# zpool export zp_zone1_data

* importer les zpools

zglobale1# zpool import zp_zone1
zglobale1# zpool import zp_zone1_data

* récuperer la configuration de la zone

zglobale2# scp /etc/zones/zone1.xml zglobale1:/etc/zones/

* attacher la zone

zglobale1# zoneadm -z zone1 attach

* démarrer la zone

zglobale1# zoneadm -z zone1 boot

=Gestion des ressources=

==Présentation==

Par défaut, les ressources RAM, swap et CPU sont communes à toutes les zones, y compris la globale. C'est-à-dire qu'une zone qui a un problème peut s'attribuer toutes les ressources, écrouler toutes les autres zones et même planter la globale. Il existe des moyens de limiter les ressources de chaque zone pour empêcher ça.

Toutes ces manipulations se font depuis la zone globale.

==Limitation de la RAM==

Pour voir la RAM actuellement attribuée aux zones :

# rcapstat -z
id zone nproc vm rss cap at avgat pg avgpg
1 uirgs50 - 833M 921M 8192M 0K 0K 0K 0K
2 uirgs52 - 712M 767M 8192M 0K 0K 0K 0K
3 uirgs49 - 2789M 2816M 8192M 0K 0K 0K 0K
[…]

Ҫa va afficher les valeurs pour toutes les zones. Il faut regarder la colonne "'''cap'''".

Pour modifier la valeur à chaud (attention, la modification sera perdue au prochain reboot) :

# rcapadm –z zone1 –m 4g

Il faut attendre quelques secondes pour que ce soit pris en compte.

Si on obtient un message du genre '''"rcapadm: resource caps not configured"''', alors c'est qu'il faut "enabler" les memory caps avec la commande suivante :

# rcapadm -E

Ensuite il faut retaper la commande rcapadm ci-dessus.

Pour limiter la RAM dans la configuration (pour qu'elle soit permanente à chaque reboot), suivre l'exemple suivant :

# zonecfg –z zone1
> add capped-memory
> set physical=4g
> end
> exit

La limitation ne sera effective qu'au prochain boot de la zone.

Si le paramètre "'''capped-memory'''" existe déjà, on peut le modifier de la manière suivante :

# zonecfg –z zone1
> select capped-memory
> set physical=4g
> end
> exit

==Limitation du swap==

Pour voir la quantité de swap actuellement allouée :

# prctl -n zone.max-swap -i zone zoneB
zone: 21: zoneB
NAME PRIVILEGE VALUE FLAG ACTION RECIPIENT
zone.max-swap
privileged 4,00GB - deny -
system 16,0EB max deny -

Il faut lire la ligne "'''privileged'''".

Pour modifier la valeur à chaud (attention, la modification sera perdue au prochain reboot) :

# prctl -r -n zone.max-swap -i zone -v 6g ma_zone

Attention, cette commande ne fonctionne que pour modifier une valeur existante. Si aucune limitation de swap n'a jamais été appliquée sur cette zone, utiliser la commande suivante :

# prctl -n zone.max-swap -v 6g -t privileged -e deny -s -i zone ma_zone

Re-attention, si vous venez de taper la commande ci-dessus alors que vous aviez déjà une limitation, alors vous n'avez pas modifié la limitation, vous en avez ajouté une deuxième ! Du coup, le système applique la plus restrictive. Pour réparer cette bêtise (c'est du vécu...), annulez la dernière commande avec :

# prctl -n zone.max-swap -i zone -t privileged -x ma_zone

Pour limiter le swap dans la configuration (pour qu'il soit permanent à chaque reboot), suivre l'exemple suivant :

# zonecfg -z zone1
> add capped-memory
> set swap=4g
> end
> exit

La limitation ne sera effective qu'au prochain boot de la zone.

Si le paramètre "'''capped-memory'''" existe déjà, on peut le modifier de la manière suivante :

# zonecfg -z zone1
> select capped-memory
> set swap=4g
> end
> exit

==Limitation du CPU==

Il y a trois méthodes possibles pour limiter l'utilisation CPU :

* '''le Fair Share Scheduler (FSS)''' : on attribue une part minimale de CPU à une zone
* '''les Ressource Pools''' : dédie exclusivement des CPUs à une zone
* '''les CPU caps''' : alloue statiquement des pourcentages de CPU à une zone

===Le Fair Share Scheduler (FSS)===

On alloue un certain nombre de parts de CPU à une zone. Il n'y a pas de nombre de parts prédéfini à partager. Le principe est que plus une zone a de parts, plus elle aura de temps CPU attribué. Par exemple, une zone qui a 20 parts aura deux fois plus de temps CPU qu'une zone à 10 parts. Peu importe le nombre total de parts, il ne représente rien de physique. Donc en fait, on attribue une priorité à chaque zone, et cette priorité ne sert que en cas de conflit. C'est à dire que si tous les cpus sont à 100%, les priorités s'appliquent, mais si les zones les plus prioritaires ne consomment pas de cpu, alors la totalité des cpus physiques peut être utilisé par une zone de petite priorité. C'est donc la manière la plus souple de gérer l'attribution cpu et celle que je recommande.

Par défaut, une zone possède une part.

Mise en œuvre :

# zonecfg –z zone1
> set cpu-shares=20
> exit

Remarque : on peut utiliser d'autres schedulers que le FSS, mais c'est celui qui est recommandé par Sun/Oracle.

===Les Ressource Pools===

On attribue exclusivement des CPUs à une zone.

Pour "donner" 3 cpus à la zone zone1 :

# zonecfg –z zone1
> add dedicated-cpu
> set ncpus=3
> end
> exit

L'utilisation des ressource pool peut être intéressante en cas d'utilisation de logiciels dont la licence est fonction du nombre de processeurs.

===Les CPU caps===

Les CPUs caps définissent un pourcentage d'utilisation maximum d'un CPU pour une zone. Par exemple, une valeur de 3 signifie qu'une zone pourra utiliser au maximum 3 CPUs ; une valeur de 0.37 signifie qu'elle ne pourra utiliser que 37% d'un CPU.

Mise en œuvre :

# zonecfg –z zone1
> add capped-cpu
> set ncpus=0.37
> end
> exit

Pour changer la valeur à chaud :

prctl -r -n zone.cpu-cap -i zone -v 37 zone1

A noter que pour avoir 37% d'un cpu, il faut mettre 0.37 dans zonecfg, alors qu'avec prctl il faut mettre 37.

==Monitoring==

Les zones étant des process de la zone globale, il est difficile de distinguer la part de ressources utilisée par une zone.

On trouve quand même quelques commandes capable de donner des informations fiables :

* prstat –Z : pour afficher la quantité de mémoire et le pourcentage de CPU utilisés par zone

# prstat -Z
PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/NLWP
17147 1303 1184M 1171M sleep 59 0 10:31:35 2,5% oracle/258
17137 1303 1184M 1166M sleep 39 0 11:12:27 2,5% oracle/258
17144 1303 1184M 1171M cpu10 19 0 12:33:59 2,5% oracle/258
[…]
1069 root 6752K 3048K sleep 59 0 0:00:13 0,0% top/1
9511 4109 46M 20M sleep 47 4 0:15:55 0,0% LINT/1
ZONEID NPROC SWAP RSS MEMORY TIME CPU ZONE
20 73 1394M 1417M 4,3% 69:11:11 11% uirgs85
12 129 3466M 3407M 10% 20:46:52 1,7% uirgs39
0 75 222M 228M 0,7% 39:42:54 0,9% global
21 86 2887M 2911M 8,9% 23:52:49 0,6% uirgs38
17 58 2417M 2490M 7,6% 1:57:15 0,0% uirgs44
19 76 1403M 1462M 4,5% 1:35:22 0,0% uirgs46
13 45 703M 761M 2,3% 1:16:57 0,0% uirgs40
18 69 857M 931M 2,8% 1:44:56 0,0% uirgs45
14 46 351M 155M 0,5% 2:09:13 0,0% uirgs41
16 46 3194M 3209M 9,8% 8:46:48 0,0% uirgs43
15 29 18M 19M 0,1% 0:12:19 0,0% uirgs42

Total: 732 processes, 7586 lwps, load averages: 5,23, 5,53, 5,50

* prctl : pour afficher les paramètres actuels d'une zone

# prctl -i zone uirgs69
zone: 21: uirgs69
NAME PRIVILEGE VALUE FLAG ACTION RECIPIENT
zone.max-swap
privileged 8,00GB - deny -
system 16,0EB max deny -
zone.max-locked-memory
system 16,0EB max deny -
zone.max-shm-memory
system 16,0EB max deny -
zone.max-shm-ids
system 16,8M max deny -
zone.max-sem-ids
system 16,8M max deny -
zone.max-msg-ids
system 16,8M max deny -
zone.max-lwps
system 2,15G max deny -
zone.cpu-cap
system 4,29G inf deny -
zone.cpu-shares
privileged 1 - none -
system 65,5K max none -

* pour voir la consommation cpu en temps réel, et la valeur du cappage, on peut utiliser kstat. Par contre, la valeur retournée est affichée avec l'id de la zone, pas son nom. Il faudra donc faire la correspondance. Exemple :

kstat -p 'caps::/^cpucaps_zone/:' |egrep ":usage|:value"
caps:1:cpucaps_zone_1:usage 114
caps:1:cpucaps_zone_1:value 770
caps:3:cpucaps_zone_3:usage 5
caps:3:cpucaps_zone_3:value 400
caps:26:cpucaps_zone_26:usage 1
caps:26:cpucaps_zone_26:value 50
caps:34:cpucaps_zone_34:usage 5
caps:34:cpucaps_zone_34:value 50
caps:36:cpucaps_zone_36:usage 146
caps:36:cpucaps_zone_36:value 800
caps:42:cpucaps_zone_42:usage 3
caps:42:cpucaps_zone_42:value 80

A noter que "value 770" correspond à un "ncpu 7.7". "zone_26" correspond à la zone dont l'id est 26 (visible avec "zoneadm list -cv".

* il y a également les utilitaires habituels vmstat, iostat, mpstat et sar qui fonctionnent à l'intérieur de zones, mais il faut être très méfiant avec leur résultat : certaines informations concernent uniquement la zone, d'autres concernent le serveur (la zone globale).

=Automatiser/scripter la configuration des zones=

Il est possible de scripter la configuration des zones, plutôt que d'aller systématiquement dans le shell interractif de zonecfg. Ceci est particulièrement utile pour configurer un grand nombre de zones.

* Première méthode : zonecfg sur une seule ligne

On peut passer tous les paramètres désirés à zonecfg pour que tout tienne sur une seule ligne. Voici un exemple :

# zonecfg –z zone2 'add capped-memory ; set swap=4g ; set physical=4g; end'

Ainsi, on peut facilement faire un script avec une ou quelques lignes par zone.

* Deuxième méthode : créer un fichier de configuration et l'injecter dans zonecfg (principe utilisé pour les clones)

D'abord, on créé un fichier de configuration. Par exemple :

# vi zoneC.conf
create
set zonepath=/zones/zoneC
set autoboot=true
set ip-type=shared
add inherit-pkg-dir
set dir=/lib
end
add inherit-pkg-dir
set dir=/platform
end
add inherit-pkg-dir
set dir=/sbin
end
add inherit-pkg-dir
set dir=/usr
end
add fs
set dir=/opt
set special=/dev/vx/dsk/datadg/zoneC-opt
set raw=/dev/vx/rdsk/datadg/zoneC-opt
set type=vxfs
end
add net
set address=10.36.209.207/22
set physical=bge0
end
add rctl
set name=zone.max-swap
add value (priv=privileged,limit=8589934592,action=deny)
end
add capped-memory
set physical=8G
end

Ensuite on insère le tout dans la conf de zoneC :

# zonecfg –z zoneC –f zoneC.conf

Oracle VM Server (LDOM)

2021-04-25T02:44:19Z

AdminWiki : /* Création et configuration */

[[Category:solaris]]

=Présentation=

Oracle VM Server (anciennement LDOM, pour "Logical Domains") est une solution de virtualisation disponible pour les architectures à base de processeurs Sparc T1 et T2. Elle n'est disponible que sous Solaris 10 et plus. Une couche logicielle doit être ajoutée au système Solaris 10 de base. Celle-ci va mettre un place un hyperviseur qui va s'appuyer sur des fonctions internes aux processeurs pour gérer les domaines logiques.

Un domaine logique est une machine virtuelle qui possède son propre système d'exploitation. Le système d'exploitation hôte est le domaine de contrôle. Les autres sont des domaines invités ; ils sont indépendants. Le domaine de contrôle est celui depuis lequel on peut gérer les autres.

=Installation du logiciel=

Il s'agit d'un simple package à installer.

Récupérer le fichier OracleVMServer2.0_<version>.zip en allant sur [http://www.oracle.com/virtualization http://www.oracle.com/virtualization].

Il faut ensuite décompresser le fichier et suivre les instructions du README. Je ne détaillerai, car cela peut dépendre de la version. Et puis c'est relativement simple.

=Configuration du domaine de contrôle=

==Création des services du domaine de contrôle.==

bash-3.00# ldm list
NAME STATE FLAGS CONS VCPU MEMORY UTIL UPTIME
primary active -n-c-- SP 32 16256M 0.1% 4d 21h 7m
bash-3.00# ldm add-vds primary-vds0 primary
bash-3.00# ldm list
NAME STATE FLAGS CONS VCPU MEMORY UTIL UPTIME
primary active -n-cv- SP 32 16256M 1.8% 4d 21h 14m
bash-3.00# ldm list-services primary
VDS
NAME LDOM VOLUME OPTIONS MPGROUP DEVICE
primary-vds0 primary

bash-3.00#
bash-3.00#
bash-3.00# ldm add-vcc port-range=5000-5100 primary-vcc0 primary
bash-3.00# ldm add-vsw net-dev=e1000g0 primary-vsw0 primary
bash-3.00#
bash-3.00#
bash-3.00# ldm list-services primary
VCC
NAME LDOM PORT-RANGE
primary-vcc0 primary 5000-5100

VSW
NAME LDOM MAC NET-DEV ID DEVICE LINKPROP DEFAULT-VLAN-ID PVID VID MTU MODE
primary-vsw0 primary 00:14:4f:fb:85:7d e1000g0 0 switch@0 1 1 1500

VDS
NAME LDOM VOLUME OPTIONS MPGROUP DEVICE
primary-vds0 primary

bash-3.00#

==Affecter des ressources au domaine de contrôle==

Affecter des vcpu et de la RAM au domaine primary. On peut également affecter des périphériques de cryptographie avec le paramètre "set-mau" ; il y en a un par cœur physique.

# ldm set-mau 1 primary
# ldm set-memory 2G primary
# ldm set-vcpu 4 primary
# ldm list
NAME STATE FLAGS CONS VCPU MEMORY UTIL UPTIME
primary active -n-cv- SP 4 2G 0.3% 12m

==Sauvegarde de la configuration==

Sauvegarde de la configuration, et vérification qu'elle est bien prise en compte

# ldm list-config
factory-default [next poweron]
#
# ldm add-config initial
#
# ldm list-config
factory-default
initial [current]

Si on modifie une valeur, il faut mettre à jour la config, sinon elle sera perdue au reboot.

# ldm set-config initial

==Activation du daemon du serveur de terminal du réseau virtuel==

Ce daemon est indispensable pour pouvoir se connecter à la console virtuelle de chaque domaine invité.

# svcadm enable vntsd

==Finalisation==

Il faut maintenant rebooter pour que tout soit pris en compte.

# init 6

=Création d'un domaine invité=

==Création et configuration==

Il faut avoir préparé un fichier, une partition ou un disque pour accueillir le système d'exploitation de l'invité. Par exemple, on va créer un volume ZFS de 20g pour accueillir le domaine invité UIRGS88.

# zfs create rpool/ldoms
# zfs create -V 20g rpool/ldoms/uirgs88

Création du domaine uirgs88.

# ldm add-domain uirgs88

Ajout de mémoire.

# ldm add-memory 12G uirgs88

Pour adapter la valeur après, on peut utiliser "delete-memory 2g" pour retirer 2Go ou "set-memory 10g" pour fixer à 10Go.

Ajout de vcpu ou de cores.

# ldm add-vcpu 16 uirgs88

Ou si on veut ajouter des cores entiers :

# ldm add-core 2 uirgs88

Et si on veut modifier par la suite :

# ldm set-core 3 uirgs88

Ajout d'un périphérique de réseau virtuel.

# ldm add-vnet [linkprop=phys-state] vnet1 primary-vsw0 uirgs88

L'option '''linkprop=phys-state''' est nécessaire si on monte deux interfaces pour faire de l'ipmp sur le ldom. Si ce n'est pas votre cas, ne pas utiliser l'option.

Si on doit ajouter des vlans :
# ldm set-vnet pvid=60 vid=61, 62, 63 vnet1 primary-vsw0 uirgs88

'''pvid''' est le vlan principal, celui qui est utilisé si on n'utilise pas de tagging, et aussi durant l'installation. Les '''vid''' sont les vlans accessibles si on fait du tagging.

Exporter le volume ZFS en tant que disque virtuel, en l'associant au domaine d'E/S (qui dans notre cas est le domaine de contrôle). (En dessous, respectivement le cas d'un disque dur local entier, une LUN gérée par Veritas (par exemple un DG veritas exporté d'un autre serveur) et un simple fichier).

Volume ZFS :
# ldm add-vdsdev /dev/zvol/dsk/rpool/ldoms/uirgs88 vol1@primary-vds0
Disque local :
# ldm add-vdsdev /dev/dsk/c2t1d0s2 vol2@primary-vds0
LUN sous veritas :
# ldm add-vdsdev /dev/vx/dmp/emc_clariion0_18s2 vol3@primary-vds0
Simple fichier :
# ldm add-vdsdev /chemin/vers/fichier vol4@primary-vds0

Assignation du volume ZFS au domaine invité.

# ldm add-vdisk vdisk1 vol1@primary-vds0 uirgs88

Définition des paramètres de l'eeprom.

# ldm set-var auto-boot\?=true uirgs88
# ldm set-var boot-device=vdisk1 uirgs88

Lier les ressources réseau avec le domaine de contrôle. On vérifie ensuite que le statut est passé à bound.

# ldm bind-domain uirgs88
# ldm list
NAME STATE FLAGS CONS VCPU MEMORY UTIL UPTIME
primary active -n-cv- SP 4 2G 0.5% 1d 1h 20m
uirgs88 bound ------ 5000 16 12G

Démarrer le LDOM et s'y connecter. Pour la connexion, il faut noter le port TCP retourné par la commande "ldm list" (ci-dessus c'est le port 5000). Le daemon vntsd doit obligatoirement être démarré.

# ldm start-domain uirgs88
# telnet localhost 5000

==Installation de Solaris sur un domaine invité==

On va maintenant installer Solaris sur le domaine invité. Ҫa peut se faire depuis un dvd, depuis une image iso ou depuis un serveur jumpstart. Nous allons voir comment faire depuis une image iso.

On suppose que l’image iso a été déposée dans /var/tmp/ sur le LDOM de contrôle, par exemple "/var/tmp/sol-10-u9-ga-sparc-dvd.iso".

Arrêter le domaine et dissocier son réseau

# ldm stop uirgs88
# ldm unbind uirgs88

Ajouter le fichier iso en tant que disque du domaine

# ldm add-vdsdev /var/tmp/sol-10-u9-ga-sparc-dvd.iso iso_vol@primary-vds0
# ldm add-vdisk sol10_dvd iso_vol@primary-vds0 uirgs88

Vérifier que le dvd est ajouté dans les volumes :

# ldm list-bindings
[...]
VDS
NAME VOLUME OPTIONS MPGROUP DEVICE
primary-vds0 vol1 /rpool/ldoms/uirgs88
iso_vol /var/tmp/sol-10-u9-ga-sparc-dvd.iso
[...]
DISK
NAME VOLUME TOUT ID DEVICE SERVER MPGROUP
vdisk1 vol1@primary-vds0 0
sol10_dvd iso_vol@primary-vds0 1

Avant de redémarrer le ldom, il est préférable, mais pas obligatoire, de désactiver l'auto-boot, pour pouvoir booter tranquillement sur l'image du dvd.

# ldm set-var auto-boot\?=false uirgs88

On associe et on démarre le ldom.

# ldm bind uirgs88
# ldm start uirgs88
LDom uirgs88 started

Ensuite on se connecte et on arrive au prompt "ok".

# telnet localhost 5000
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.

Connecting to console "uirgs88" in group "uirgs88" ....
Press ~? for control options ..

{0} ok

On va maintenant afficher les alias pour vérifier qu'on voit bien celui associé à notre DVD, puis on va booter sur le slice "f" de cd DVD.

{0} ok devalias
sol10_dvd /virtual-devices@100/channel-devices@200/disk@1
vdisk1 /virtual-devices@100/channel-devices@200/disk@0
vnet1 /virtual-devices@100/channel-devices@200/network@0
net /virtual-devices@100/channel-devices@200/network@0
disk /virtual-devices@100/channel-devices@200/disk@0
virtual-console /virtual-devices/console@1
name aliases
{0} ok boot sol10_dvd:f

Et cette fois l'installation démarre.

Dans le cas ou on n'arriverais pas à obtenir le prompt "ok" à cause de messages, on peut le forcer à y aller avec la combinaison de touches "~#" qui envoie un break ; ça revient à faire un ctrl-A.

Pour voir les séquences de touche existantes, il faut faire "~?".

Voici le résultat obtenu :

VNTSD commands
~# --Send break
~^B --Send alternate break
~. --Exit from this console
~w --Force write access
~n --Console next
~p --Console previous
~? --Help

==Retirer des ressources au domaine invité==

Voici quelques exemples de suppression de ressources :

ldm rm-vdisk [-f] emc_clariion0_34 mon_ldom
ldm rm-vnet monldom_vnet0 mon_ldom

Lorsqu'on retire un vdisk d'un ldom en marche, on peut avoir une erreur avec le message '''"Device being used by VxVM"'''. Ca arrive quand le vdisk était utilisé par VxVM (Veritas Volume Manager), même si on a retiré le vdisk du DG et qu'on a fait un '''"vxdisk rm"'''. Si c'est le cas, inutile de faire "vxdisk rm", à la place il faut libérer le vdisk avec :

vxdmpadm disable dmpnodename=emc_clariion0_27

Ensuite on peut faire '''"ldm rm-vdisk"'''.

==Supprimer un domaine invité==

ldm destroy mon_ldom