3 votes

Dr. Faust avatar

Linux / Multipath n'utilise pas tous les chemins, et n'utilise pas le sélecteur de chemin de longueur de file d'attente ?

Demandé el 8 de Juillet, 2011
Quand la question a-t-elle été
9444 affichage
Nombre de visites la question a
3 Réponses
Nombre de réponses aux questions
Résolu
Situation réelle de la question

Je dispose du matériel suivant :

  • 2x serveurs SuperMicro (128GB RAM, 2x 8 core AMDs)
  • 2x/serveur LSI SAS2008 PCIe MPT-Fusion2 HBAs (2 ports SAS par carte)
  • 1x LSI CTS2600 DAS avec 24 disques W.D. 15,7k RPM 600GB SAS.

Le serveur fonctionne sous OpenSuSE 11.4, avec une version personnalisée de multipath-tools construite en amont et incorporant le jeu de correctifs OpenSuSE 11.3. Les 4 ports SAS de chaque serveur sont connectés au DAS, 2 à chacun des contrôleurs RAID du DAS.

Le DAS est configuré avec 22 disques dans un RAID10, 128k stripe. J'ai créé un seul groupe de volume de 500 Go sur la matrice et je l'ai exporté vers l'un des serveurs.

Multipath est configuré pour multiplier les E/S vers le LUN de 500 Go exporté vers le serveur. Voici le fichier multipath.conf :

defaults {
    path_checker            "directio"
    path_selector           "queue-length 0"
    path_grouping_policy    "multibus"
    prio                    "random"
    features                "1 queue_if_no_path" #queue IO if all paths are lost
}

multipath -l de la production :

pg (360080e50001b658a000005104df8c650) dm-0 LSI,INF-01-00
size=500G features='3 queue_if_no_path pg_init_retries 50' hwhandler='1 rdac' wp=rw
|-+- policy='round-robin 0' prio=0 status=active
| |- 4:0:0:1 sda 8:0   active undef running
| `- 5:0:0:1 sde 8:64  active undef running
`-+- policy='round-robin 0' prio=0 status=enabled
  |- 4:0:1:1 sdc 8:32  active undef running
  `- 5:0:1:1 sdg 8:96  active undef running

Remarquez que pour le deuxième ensemble de chemins, "status=enabled", et non "status=active" comme pour les deux premiers. Maintenant, un coup d'œil à iostat montre qu'en effet nous n'utilisons que les deux premiers chemins :

Linux 2.6.37.6-0.5-default (slipdb01-primary)   07/07/2011      _x86_64_        (16 CPU)                                                       

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await  svctm  %util                                      
sda               0.00     0.00    1.18  441.70    30.44  4748.62    21.58     0.79    1.79   0.24  10.60                                      
sdb               0.00     0.00    0.00    0.00     0.00     0.00    14.22     0.00   83.56  82.92   0.00                                      
sdc               0.00     0.00    0.00    0.00     0.00     0.00     8.06     0.00  334.53 331.73   0.02                                      
sdd               0.00     0.00    0.00    0.00     0.00     0.00    16.99     0.00   98.73  95.76   0.00                                      
sde               0.00     0.00    1.18  441.70    30.43  4747.77    21.58     0.79    1.79   0.24  10.60                                      
sdf               0.00     0.00    0.00    0.00     0.00     0.00    14.43     0.00   77.17  76.66   0.00                                      
sdg               0.00     0.00    0.00    0.00     0.00     0.00     8.06     0.00  301.72 297.05   0.02                                      
sdh               0.00     0.00    0.00    0.00     0.00     0.00    14.29     0.00   83.12  82.69   0.00                                      
sdi               0.00     0.00    0.08    0.48     8.73    35.82   159.00     0.06   99.95   1.08   0.06                                      
sdj               0.00  2311.06    0.00  340.49     0.01 10606.18    62.30     0.04    0.12   0.08   2.83                                      
dm-0              0.02  1353.74    2.36  883.40    60.86  9496.39    21.58     0.95    1.08   0.13  11.20                                      
dm-2              0.00     0.00    2.38 2237.14    60.86  9496.39     8.54     1.90    0.84   0.05  11.20

Si je comprends bien, le fait de définir path_grouping_policy sur 'multibus' devrait équilibrer l'IO sur TOUS les chemins, donc je devrais voir 4 chemins actifs. Si je change path_grouping_policy en 'failover', je vois les mêmes 2 chemins actifs.

De plus, je remarque que path_selector est réglé sur "queue-length 0" alors que la sortie de "multipath -l" montre clairement qu'il utilise round-robin.

Quelqu'un a-t-il une idée de la raison pour laquelle multipath-tools n'utilise pas les 4 chemins, et pourquoi il ignore mon choix d'algorithme de sélection de chemin ?

Merci beaucoup...

Demandé el 8 de Juillet, 2011 par Dr. Faust

Réponses

Trop de publicités?

2voto

mattdwen avatar
mattdwen Points 181

Eh bien, il semble que la matrice ne soit pas active/active de la manière que je pensais et de la manière que je pensais être la définition commune. CTS2600 est une matrice active/active dans la mesure où elle peut servir le LUN1 du contrôleur A et le LUN2 du contrôleur B, mais pas le LUN1 des contrôleurs A et B. Il semble donc que je ne puisse pas obtenir les 4 chemins vers un LUN.

Cependant, j'ai découvert que je pouvais répartir la charge des entrées-sorties sur les deux contrôleurs. Pour ce faire, j'ai créé un groupe de volumes RAID10 de 22 disques sur la matrice CTS2600, créé deux volumes et défini le chemin préféré pour le volume A sur le contrôleur A, et sur le contrôleur B pour le volume B, puis je les ai exportés sur le serveur. Je les ai ensuite initialisés en tant que volumes physiques LVM2 en utilisant les noms sous /dev/mapper/. J'ai ensuite créé un groupe de volumes LVM2 contenant les deux volumes physiques. Comme j'ai deux LUN, j'ai ajouté l'option "--stripes 2" lors de l'exécution de "lvcreate". J'ai ensuite formaté, monté et utilisé le périphérique comme d'habitude. En regardant à la fois 'iostat' et le moniteur de performance intégré de SANtricity, il était clair que l'IO était répartie sur les deux contrôleurs, comme prévu.

Merci à un gentil monsieur sur #postgres de m'avoir indiqué l'option --stripes pour réaliser cela (d'autant plus que LSI n'a pas voulu ou pu m'aider).

Répondu el 27 de Juillet, 2011 par mattdwen (181 Points )

1voto

Dr. Faust avatar
Dr. Faust Points 361

En outre, j'ai omis les détails concernant les bits de longueur de file d'attente et de sélecteur de chemin. Le périphérique de stockage que j'utilise est déjà dans la base de données multipath, et a donc certains paramètres par défaut, comme queue-length et path_selector. Il manquait à mon fichier /etc/multipath.conf une section " devices { device { ", qui est l'endroit où l'on peut surcharger les options par défaut. Après avoir fait ce changement, j'ai pu confirmer que je pouvais modifier (et que multipath utiliserait) queue-length et path_selector. La partie que j'ai ajoutée à /etc/multipath.conf :

   devices {
     device {
     vendor  "LSI"
     product "INF-01-00"
     no_path_retry   fail
     features        0
     #path_grouping_policy   "multibus"
     }
   }

J'espère que cela aidera quelqu'un.

Répondu el 7 de Septembre, 2011 par Dr. Faust (361 Points )

1voto

clrhs avatar
clrhs Points 1

Cette situation est parfois appelée "Dual Active" et n'est pas la véritable FC active/active à laquelle les ingénieurs SAN sont habitués. Les fournisseurs pourraient mieux décrire les limites de leurs produits basés sur la technologie SAS. Cet article explique tous les modes assez bien.

Répondu el 30 de Janvier, 2012 par clrhs (1 Points )

Questions en vedette

Top Tags

Dans notre réseau

SistemesEz.com

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

Powered by:

Yandex
X