Remaniement diskless
This commit is contained in:
parent
c22191309f
commit
e49602eb70
38
HowtoDRBD.md
38
HowtoDRBD.md
|
|
@ -47,7 +47,7 @@ Sur une installation DRBD on définit :
|
|||
- des **ressources** : chaque ressource DRBD a plusieurs paramètres, notamment le second serveur vers qui envoyer/recevoir la réplication
|
||||
- des **volumes** : chaque ressource DRBD peut avoir un ou plusieurs volumes, chaque volume est accessible via un périphérique unique nommé `/dev/drbdXX`
|
||||
|
||||
La configuration des ressources DRBD est dans le répertoire `/etc/drbd.d/` ; voici un exemple simple d'une ressource _foo_ avec un volume `/dev/drbd42` définie dans un fichier `/etc/drbd.d/foo.res` entre deux serveurs nommés _tic_ et _tac_ (cette exemple sera repris par la suite) :
|
||||
La configuration des ressources DRBD est dans le répertoire `/etc/drbd.d/` ; voici un exemple simple d'une ressource _foo_ avec un volume `/dev/drbd42` définie dans un fichier `/etc/drbd.d/foo.res` entre deux serveurs nommés _tic_ et _tac_ (cet exemple sera repris par la suite) :
|
||||
|
||||
~~~
|
||||
resource "foo" {
|
||||
|
|
@ -102,7 +102,7 @@ On peut également piloter un volume d'une ressource en indiquant la syntaxe _[r
|
|||
# drbdadm secondary foo/0
|
||||
~~~
|
||||
|
||||
**drbdadm** pilote principalement les commandes bas niveau `drbdsetup` et `drbdmeta`. Son mode "dry-run" est très utile car il va lister les commandes bas niveau effectuées (sans les appliquer). Par exemple pour voir tous les changements de configuration non appliqués :
|
||||
**drbdadm** pilote principalement les commandes bas niveau `drbdsetup` et `drbdmeta`. Son mode « dry-run » est très utile car il va lister les commandes bas niveau effectuées (sans les appliquer). Par exemple pour voir tous les changements de configuration non appliqués :
|
||||
|
||||
~~~
|
||||
# drbdadm -d adjust all
|
||||
|
|
@ -425,7 +425,7 @@ volume 2 {
|
|||
}
|
||||
~~~
|
||||
|
||||
On utilise ensuite `drbdsetup` sur chaque serveur avec le _device minor_ correspondant au volume volume à supprimer :
|
||||
On utilise ensuite `drbdsetup` sur chaque serveur avec le _device minor_ correspondant au volume à supprimer :
|
||||
|
||||
~~~
|
||||
tic# drbdsetup secondary 45
|
||||
|
|
@ -694,7 +694,7 @@ On peut surveiller l'état des volumes DRBD via Nagios via <https://exchange.nag
|
|||
|
||||
<https://www.drbd.org/en/doc/users-guide-84/s-resolve-split-brain>
|
||||
|
||||
Un _split-brain_ signifie que des écritures ont été réalisées sur deux volumes primaires et desynchronisés, le seul moyen est de choisir manuellement un volume à réinitialiser !
|
||||
Un _split-brain_ signifie que des écritures ont été réalisées sur deux volumes primaires et désynchronisés, le seul moyen est de choisir manuellement un volume à réinitialiser !
|
||||
|
||||
Sur le serveur en _Standalone_ qu'on veut réinitialiser :
|
||||
|
||||
|
|
@ -738,7 +738,7 @@ il faut créer le périphérique avec `drbdsetup new-minor` …ou plus simple av
|
|||
|
||||
### Erreur _Diskless_
|
||||
|
||||
Si l'on obtient un état "Diskless" cela peut vouloir dire que la ressource n'est pas ou plus attachée.
|
||||
Si l'on obtient un état « Diskless » cela peut vouloir dire que la ressource n'est pas ou plus attachée.
|
||||
|
||||
> *Note* : Une ressource peut être automatiquement détachée suite à des erreurs d'I/O.
|
||||
|
||||
|
|
@ -749,6 +749,14 @@ Si l'on obtient un état "Diskless" cela peut vouloir dire que la ressource n'es
|
|||
|
||||
On corrigera avec un `drbdadm attach` de la ressource en question.
|
||||
|
||||
Cela peut aussi être le cas avec un VG LVM qui serait activé sur un hyperviseur par exemple. On pourra le corriger avec un :
|
||||
|
||||
~~~
|
||||
# vgchange -an /dev/<vgname>
|
||||
~~~
|
||||
|
||||
Pour éviter que le noyau active le VG voir : <https://wiki.evolix.org/HowtoLVM#filter-la-d%C3%A9tection-des-vg>
|
||||
|
||||
### Peut-on avoir plusieurs serveurs ?
|
||||
|
||||
Une ressource DRBD doit être définie entre deux serveurs, mais rien n'enpêche d'avoir d'autres ressources liées à différents serveurs.
|
||||
|
|
@ -848,22 +856,4 @@ tic# drbdadm primary foo
|
|||
|
||||
### Réplication truck-base
|
||||
|
||||
Plus fort que l'[IPoAC](https://fr.wikipedia.org/wiki/IP_over_Avian_Carriers), DRBD décrit la [réplication truck-based](https://www.drbd.org/en/doc/users-guide-84/s-truck-based-replication)
|
||||
|
||||
### Erreur Diskless
|
||||
|
||||
Erreur du type :
|
||||
|
||||
~~~
|
||||
block drbd8: peer( Unknown -> Secondary ) conn( WFReportParams -> Connected ) pdsk( DUnknown -> Diskless )
|
||||
Connected Secondary/Secondary Diskless/Diskless _myvol vdb virtio
|
||||
~~~
|
||||
|
||||
Cela signifie que drbd ne peut pas accéder au backend device, soit parcequ'il n'existe pas, soit parcequ'il n'a pas les droits.
|
||||
Cela peut être le cas avec un volume group LVM qui serait activé sur un hyperviseur par exemple. On pourra le corriger avec un :
|
||||
|
||||
~~~
|
||||
# vgchange -an /dev/<vgname>
|
||||
~~~
|
||||
|
||||
Pour éviter que le noyau active le VG voir : <https://wiki.evolix.org/HowtoLVM#filter-la-d%C3%A9tection-des-vg>
|
||||
Plus fort que l'[IPoAC](https://fr.wikipedia.org/wiki/IP_over_Avian_Carriers), DRBD décrit la [réplication truck-based](https://www.drbd.org/en/doc/users-guide-84/s-truck-based-replication)
|
||||
Loading…
Reference in a new issue