-
Notifications
You must be signed in to change notification settings - Fork 0
01. Réflexions et 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 et réseau public ceph
- reseau SN : synchro des disques ceph
- réseau SYNC : syncro du cluster corosync
- réseau ILO : administration du hardware
Les réseaux SYNC et SN doivent impérativment être redondants, car sinon une coupure va tout planter.
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. Le calcul de base est 3 x BP de NET 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, Or les switches HP ne permettent pas d'avoir l'aggrégation LACP sur plusieurs switches. Il faut donc avoir une autres tratégie pour la redondance . Voir plus loin.
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... Rien à voir avec Ceph, c'est un niveau au dessus, c'est ce qui permet d'avoir une conf partagée entre les 3 serveurs. Il me semble que c'est ausi le réseau utilisé par qemu pour migrer les VM? Corosync permet de définir plusieurs réseaux redondants. 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.
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.
le réseau public-ceph est le réseau entre les osd et les clients ( dans notre cas les disques rbd kvm des vm). Vu notre config, les clients sont sur les mêmes machines que les osd, et donc dans la majorité des cas on ne sort pas de la machine, et donc pas de limite de bande passante. Le cas où cela pourrait se produire : un serveur a un disque en rade ou est trop lent, et donc l'accès aux données se fait sur son voisin plus rapide via le réseau public. La redondance n'est pas nécessaire pour la cohérence ceph, mais la perte de connectivité peut bloquer les I/O des vm du noeud concerné.
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... En revanche ce n'est pas forcément un switch de tête de réseau.