|
|
|
# Dimensionnement initial du réseau
|
|
|
|
|
|
|
|
Avant tout il faut commencer par là un cluster ne fonctionnera pas sans une conf réseau pensée pour *avant* la mise en place !
|
|
|
|
|
|
|
|
Les serveurs comportent 6 ports Gb + 1 port iLo. l'objectif est de trouver la configuration optimale en terme de perfs et de fiabilité.
|
|
|
|
En théorie il faudrait faire 4 réseaux physiques distincts :
|
|
|
|
- reseau NET : services
|
|
|
|
- reseau SN : synchro des disques
|
|
|
|
- réseau SYNC : syncro du cluster
|
|
|
|
- réseau ILO : administration du hardware
|
|
|
|
Les réseaux SYNC et SN doivent impérativment être redondants, car sinon une coupure va tout planter.
|
|
|
|
## bande passante
|
|
|
|
### SN
|
|
|
|
l'acès aux données situées sur les autres noeuds et la répartition des données entre les noeuds se fait sur ce réseau. La pire situation est la panne d'un disque, obligeant sa reconstruction depuis un miroir. Le temps de reconstruction est : la taille du disque en Mo / le débit en Mo/s. Pour un disque de 1,2To on a `1200000/120=10000 s̀ . Soit 3H environ. Durant tout ce temps le cluster sera ralenti, et la redondance moins forte.
|
|
|
|
En mettant 3 ou 4 liens aggrégés on tombe sous 1h, ce qui est acceptable. afin d'avoir de la redondance, il est préférable répartir les liens sur 2 switches indépendants. Si les switches ne permettent pas le LACP multi-switches, on utilise le mode 5 ou 6, qui dans notre cas d'une topologie fixe seront aussi performants et ne demandent pas de configuration des switches.
|
|
|
|
### SYNC
|
|
|
|
Ce sont les boucles de synchronisation Corosync. les noeuds échangent des infos en multicast, et s'autocontrôlent entre eux. Il est impératif que la communication passe avec une latence très faible, sinon les noeuds se désynchronisent et le cluster se bloque. Il faut absolument avoir deux boucles sur 2 switches différents. Il est déconseillé de partager physiquement les interfaces SN, en revanche sur NET cela peut marcher...
|
|
|
|
Mon expérience sur les clusters en prod que j'ai monté est que le problème vient toujours de ce lien. On n'a pas assez d'interfaces, on ne veut pas sacrifier la bande passant pour un truc qui ne srt à rien, donc on partage, et puis un jour, généralement avec une très forte charge cela se met à déconner, des noeuds se déconnectent, les vm sont figées, et là bon courage... Mieux vaut sacrifier une interface et être tranquille.
|
|
|
|
### NET
|
|
|
|
Le réseau de service, la redondance n'est pas obligatoire, mais faire un bond avec 2 liens permettra de mieux répartir la charge. On fait du LACP et donc il faut également le configurer sur le switch (trunk sur hp/aruba, etherchannel sur cisco). On met tous les vlans utiles pour les vm dans ce lien en mode tagged. Les interfaces sur le proxmox seront donc du type bond0.x, x étant le numéro du vlan.
|
|
|
|
### iLo
|
|
|
|
soit on utilise le port dédié, soit on partage une interface de NET. Les 2 fonctionnent, le mode dédié a l'avantage de permettre de gérer de façon globale les 3 serveurs, mais il faut trois prises en plus sur un switch...
|
|
|
|
|
|
# conf initiale ilo
|
|
# conf initiale ilo
|
|
|
|
|
|
# installation des dépôts hpe
|
|
# installation des dépôts hpe
|
... | | ... | |