1. Yann Dupont & Yoann Juet
Service IRTS
DSI de l' Université de Nantes
Mécanismes de haute-
disponibilité côté système
Retours d'expérience sous
Gnu/Linux
2. Points discutés
● État des lieux à l'Université de Nantes
– Étude de cas : Mise en place des baies multi-
services
– Détails techniques sur les mécanismes de
haute disponibilité déployés
4. 4
États des lieux à l'Université de Nantes
Saint-Nazaire, Nantes
Saint-Nazaire, Nantes
3 sites géographiques répartis
à plus de 70 Km
La Roche/Yon
La Roche/Yon
5. 5
États des lieux à l'Université de Nantes
Connexions IP à
10 Gbps.
+ Connexions dédiées stockage
à 2 Gbps
7. 7
États des lieux à l'Université de Nantes
Sur Nantes,
3 plaques géographiques principales
inter-connectées et fédérant les sites
8. 8
États des lieux à l'Université de Nantes
Site Lombarderie
Cœur du réseau
Sciences et Sciences
humaines
Site Chantrerie
École polytechnique
Site Loire
Médecine-Présidence
9. 9
États des lieux à l'Université de Nantes
Site Lombarderie
Cœur du réseau
Sciences et Sciences
humaines
Site Chantrerie
École polytechnique
Site Loire
Médecine-Présidence
10. 10
États des lieux à l'Université de Nantes
Connexions IP
10 Gbps.
+ Connexions dédiées stockage
à 2 x4Gbps
11. 11
États des lieux à l'Université de Nantes
Passé, présent
les services applicatifs centraux les plus critiques -
messagerie, DNS, reverses-proxies, annuaires, etc. - sont déjà
redondés à chaud depuis plusieurs années
Partage de charge avec Round robin DNS, LVS, Heartbeat,
Round robin DNS, LVS, Heartbeat, ..
l'infrastructure de cœur de réseau n'est pas en reste
Routage dynamique, VRRP, double attachement avec spanning-
tree, agrégat de liens, lots de spare, etc.
Présent, avenir
l'architecture logicielle et matérielle actuelle donne entière
satisfaction même si des axes d'amélioration existent
plus de 20 sites sont aujourd'hui raccordés en FO au cœur de
réseau de l'Université
chacun assure une sécurité périmétrique et propose des
services applicatifs de proximité
12. 12
États des lieux à l'Université de Nantes
Présent, avenir
la plupart des sites ne disposent pas aujourd'hui d'une
infrastructure (serveurs, pare-feu...) en haute-disponibilité à
chaud ou même parfois à froid
l'impact sur l'usager in situ peut vite s'avérer désastreuse en
cas de défaillance d'un ou plusieurs éléments de
l'infrastructure locale
Comment améliorer le niveau de service au plus prêt de
Comment améliorer le niveau de service au plus prêt de
l'usager ?
l'usager ?
13. Points discutés
– État des lieux à l'Université de Nantes
● Étude de cas : Mise en place des baies multi-
services
– Détails techniques sur les mécanismes de
haute disponibilité déployés
14. 14
Concept de Baie Multi-Service
Baie réseau 42U installée sur site et comprenant
15. 15
Concept de Baie Multi-Service
Baie réseau 42U installée sur site et comprenant
● 1 onduleur
16. 16
Concept de Baie Multi-Service
Baie réseau 42U installée sur site et comprenant
● 1 onduleur
● 2 serveurs rack 1U
double attachement
GigaEthernet et FC
17. 17
Concept de Baie Multi-Service
Baie réseau 42U installée sur site et comprenant
● 1 onduleur
● 2 serveurs rack 1U
double attachement
GigaEthernet et FC
● 1 pile de 2 commutateurs
24 ports Giga cuivre
18. 18
Concept de Baie Multi-Service
Baie réseau 42U installée sur site et comprenant
● 1 onduleur
● 2 serveurs rack 1U
double attachement
GigaEthernet et FC
● 1 pile de 2 commutateurs
24 ports Giga cuivre
● 1 commutateur Fibre Channel
19. 19
Concept de Baie Multi-Service
Baie réseau 42U installée sur site et comprenant
● 1 onduleur
● 2 serveurs rack 1U
double attachement
GigaEthernet et FC
● 1 pile de 2 commutateurs
24 ports Giga cuivre
● 1 commutateur Fibre Channel
● des U pour les besoins à venir :
serveurs 1U supplémentaires,
blades, baies de stockage, etc.
20. 20
Concept de Baie Multi-Service
● 2 serveurs rack 1U
double attachement
GigaEthernet et FC
KVM
KVM
K
V
M
V
s
e
r
v
e
r
● Une bonne dose de virtualisation
(KVM, Vserver over KVM)
●
Des mécanismes de
Des mécanismes de
haute disponibilité
haute disponibilité
21. 21
Concept de Baie Multi-Service
Services fournis par une BMS
Invité KVM : pare-feu ip(6)tables haute-disponibilité
pare-feu ip(6)tables haute-disponibilité
Invité KVM : DHCP+DRBL
DRBL - usage de la fonction relai DHCP
sur le commutateur L3 du site -
Invité VSERVER over KVM : tout le reste, selon les besoins
spécifiques du site considéré
DNS : dynamique - couplage avec le DHCP -, DNS primaire pour
la ou les zones privées en vigueur,
Samba,LDAP
,LDAP
Collecteur Syslog, TFTP, Nagios...
Double connectivité IPv4, IPv6
Facilité de mutualisation de la BMS pour les « petits » sites co-
localisés sur une même plaque
Fourniture au cas par cas du service de haute-disponibilité
Fourniture au cas par cas du service de haute-disponibilité
selon les besoins et les caractéristiques du site
selon les besoins et les caractéristiques du site
22. 22
Concept de Baie Multi-Service
Services fournis par une BMS
Dans l'avenir, Brique décentralisée de stockage
Dans l'avenir, Brique décentralisée de stockage
24. 24
Concept de Baie Multi-Service
Objectifs visés par la BMS
Améliorer la disponibilité des services applicatifs locaux en les
virtualisant ainsi qu'en les redondant
Services ayant une portée locale (ex. DHCP)
Services ayant une visibilité inter-sites (ex. gestion des congés,
des emplois du temps)
En corollaire, faciliter les opérations de mise à jour applicative
Mise à jour correctives, de sécurité, fonctionnelles
Moderniser l'infrastructure de tête des sites
contenir la prolifération de PC de bureau reconditionnés en
serveurs hébergeant des services locaux plus ou moins critiques
(ex. pare-feu, proxies/caches, samba)
mettre à plat les architectures réseau et logicielles : zones
démilitarisées, réseau d'administration des équipements actifs,
spécialisation des machines virtuelles...
25. 25
Concept de Baie Multi-Service
Objectifs visés par la BMS
Homogénéiser les procédures de production/maintenance des
pare-feu, des applicatifs
Paradigme 1 applicatif = 1 machine virtuelle
1 applicatif = 1 brique fonctionnelle = 1 groupe de travail = 1 ou
plusieurs documents de référence partagés entre les
informaticiens
De ces procédures communes débouchera une expérience
partagée d'où un support élargi à de nombreux informaticiens et
non plus à une poignée de personnes d'un service central
comme la DSI de l'Université
Plus qu'un concept, une réalité ! La première BMS est en
cours de déploiement sur un nouveau site devant accueillir
300 chercheurs et enseignants-chercheurs
26. Points discutés
– État des lieux à l'Université de Nantes
– Étude de cas : Mise en place des baies multi-
services
● Détails techniques sur les mécanismes de
haute disponibilité déployés
27. Points discutés
– État des lieux à l'Université de Nantes
– Étude de cas : Mise en place des baies multi-
services
– Détails techniques sur les mécanismes de
haute disponibilité déployés
● Pare-feu haute-disponibilité
avec Heartbeat2, conntrackd...
28. 28
Brique pare-feu haute-disponibilité
Empilement de composants open-source
Virtualisation de la machine pare-feu
KVM
http://www.linux-kvm.org
Couche d'abstraction à KVM
http://libvirt.org/
Système d'exploitation du maître et des invités : Debian Lenny
Mise en œuvre de la Politique de Sécurité
Netfilter, iptables, ip6tables (...)
Gestion graphique des règles avec FirewallBuilder 3
http://www.fwbuilder.org/
Synchronisation des règles sur les nœuds avec csync2
http://oss.linbit.com/csync2/
29. 29
Brique pare-feu haute-disponibilité
Empilement de composants open-source
Cluster formé de deux nœuds en mode actif/passif
Heartbeat2
http://www.linux-ha.org/
Gestion graphique du cluster avec hb_gui
Synchronisation de la table des sessions (conntrack)
Conntrackd
http://conntrack-tools.netfilter.org/
Emploi immodéré des interfaces vlan (vconfig), des bridges
(brctl), des interfaces virtuelles (tunctl)
34. Points discutés
– État des lieux à l'Université de Nantes
– Étude de cas : Mise en place des baies multi-
services
– Détails techniques sur les mécanismes de
haute disponibilité déployés
● Partage de charge : Round robin DNS
35. 35
Round robin DNS
Exemple sur des LDAP
dupont-y@Bastion:~$ dig ldap.univ-nantes.prive
...
;; ANSWER SECTION:
ldap.univ-nantes.prive. 300 IN A 172.20.12.90
ldap.univ-nantes.prive. 300 IN A 172.20.12.88
ldap.univ-nantes.prive. 300 IN A 172.20.12.89
36. 36
Round robin DNS (2)
Exemple sur des LDAP
dupont-y@tomintoul:~$ ping ldap.univ-nantes.prive
PING ldap.univ-nantes.prive (172.20.12.89) 56(84) bytes of data.
64 bytes from Ldap2.univ-nantes.prive (172.20.12.89): icmp_seq=1
ttl=63 time=0.256 ms
dupont-y@tomintoul:~$ ping ldap.univ-nantes.prive
PING ldap.univ-nantes.prive (172.20.12.88) 56(84) bytes of data.
64 bytes from Ldap1.univ-nantes.prive (172.20.12.88): icmp_seq=1
ttl=63 time=0.310 ms
37. 37
Round robin DNS (3)
Haute disponibilité bon marché : simple, rapide
Mécanisme statique, non intelligent.
En cas de panne d'un des serveurs, il y a des
comportements différents suivant les programmes, les
systèmes d'exploitation.
Au mieux, des gros ralentissements,
Au pire, des problèmes applicatifs
38. Points discutés
– État des lieux à l'Université de Nantes
– Étude de cas : Mise en place des baies multi-
services
– Détails techniques sur les mécanismes de
haute disponibilité déployés
● Partage de charge intelligente : IPVS
40. 40
Vue du directeur
Directeur-1-U12:~# ipvsadm
IP Virtual Server version 1.2.1 (size=1048576)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP cacheinterne.univ-nantes.fr: wlc
-> Cache-1.C12.prive:3128 Masq 1 13 276
-> Cache-3.C12.prive:3128 Masq 10 102 2508
-> Cache-2.C12.prive:3128 Masq 1 11 263
État sur le directeur associé
une politique WLC a été utilisée.
Nous gagnons à la fois en fiabilité et en performance
41. Points discutés
– État des lieux à l'Université de Nantes
– Étude de cas : Mise en place des baies multi-
services
– Détails techniques sur les mécanismes de
haute disponibilité déployés
● Disponibilité des systèmes de fichiers
42. 42
Serveur de fichiers – construction
classique
Commutateur
Fibre channel
Baie de stockage
Serveur
Lun : XFS
ext3 ...
Clients
43. 43
Serveur de fichiers – construction
classique
Commutateur
Fibre channel
Baie de stockage
Serveur
Lun : XFS
ext3 ...
Clients
Aucune haute disponibilité
(à part celle du matériel)
55. 55
Sécurisation d'un serveur de
fichiers
LUN (ext3)
1er Serveur
2nd
Serveur
Même LUN partagé
par les 2 serveurs
Les systèmes de fichiers traditionnel
Les systèmes de fichiers traditionnel
(ext2/3/4, XFS, JFS, reiserfs, btrfs...)
(ext2/3/4, XFS, JFS, reiserfs, btrfs...)
ne sont pas conçus
ne sont pas conçus
pour un accès concurrent.
pour un accès concurrent.
Toute utilisation
Toute utilisation
en accès concurrent
en accès concurrent
se solde par une
se solde par une
corruption des données.
corruption des données.
58. 58
Utilisation d'Heartbeat + LVM2
LUN (ext3)
1er Serveur (actif)
2nd
Serveur (attente)
Heartbeat
Real IP 1
Real IP 2
Virtual
IP
59. 59
Utilisation d'Heartbeat + LVM2
LUN (ext3)
1er Serveur (actif)
2nd
Serveur (attente)
Heartbeat
Real IP 1
Real IP 2
Virtual
IP
Accès exclusif au LUN
1 seul serveur actif en simultané
Le module LVM2 heartbeat empêche le montage
Sur un noeud non actif.
60. 60
Utilisation d'Heartbeat + LVM2
LUN (ext3)
1er Serveur (inactif)
ou en panne
2nd
Serveur actif
Heartbeat
Real IP 1
Real IP 2
Real IP 2
Virtual
IP
61. 61
Cluster FS à média partagé
LUN :
Cluster FS
Le LUN est maintenant
Formaté avec un
Cluster file system
(OCFS2 ou GFS2)
62. 62
Cluster FS à média partagé
LUN :
Cluster FS
Le LUN est maintenant
Formaté avec un
Cluster file system
(OCFS2 ou GFS2)
Les accès
Au LUN
Sont concurrents
63. 63
Cluster FS à média partagé
LUN :
Cluster FS
Mais à chaque opération
chaque nœud doit prévenir ses
pairs des accès qu'il réalise
via le réseau
64. 64
Cluster FS à média partagé
LUN :
Cluster FS
Engendrant beaucoup de
paquets réseau
(et un ralentissement
des opérations)
65. 65
Fichier de configuration d'OCFS2
cluster:
node_count = 2
name = mon_cluster
node:
ip_port = 7777
ip_address = 192.168.21.1
number = 1
name = noeud1
cluster = mon_cluster
node:
ip_port = 7777
ip_address = 192.168.21.2
number = 2
name = noeud2
cluster = mon_cluster
Formatage du LUN sur un
des noeuds.
mkfs.ocfs2 /dev/nomdevice
Par défaut, provision pour 4
noeuds.
Simple montage sur chacun
des noeuds.
66. 66
En cas de soucis sur la baie ?
LUN :
Cluster FS
71. 71
En cas de soucis sur la baie ?
Replication de type bloc
Synchrone / Asynchrone
Propriétaire – Nécessite
deux baies de même
constructeur
Généralement couteux
Attention à l'intégrité des
données
Couplage avec heartbeat
sur les serveurs
72. 72
DRBD
Si seulement 2
serveurs sont
concernés
Les machines
dupliquent les
données
Couplage à
Heartbeat
Mode actif/passif
Mode actif/actif si
utilisation d'un
Cluster FS
Actif
Passif
75. 75
Cluster FS type réseau
Volumes virtuels
Volumes virtuels
répartis
répartis
à tolérance de
à tolérance de
panne et répartition
panne et répartition
géographique
géographique
76. 76
Cluster FS type réseau
Volumes virtuels
Volumes virtuels
répartis
répartis
à tolérance de
à tolérance de
panne et répartition
panne et répartition
géographique
géographique
77. 77
Cluster FS type réseau
Volumes virtuels
Volumes virtuels
répartis
répartis
à tolérance de
à tolérance de
panne et répartition
panne et répartition
géographique
géographique
78. 78
Cluster FS type réseau
Volumes virtuels
Volumes virtuels
répartis
répartis
à tolérance de
à tolérance de
panne et répartition
panne et répartition
géographique
géographique
79. 79
Cluster FS type réseau
Volumes virtuels
Volumes virtuels
répartis
répartis
à tolérance de
à tolérance de
panne et répartition
panne et répartition
géographique
géographique
82. 82
Gluster FS
configuration d'un client -2
# file: /etc/glusterfs/glusterfs-client.vol
volume replicate1
volume replicate1
type cluster/replicate
type cluster/replicate
subvolumes remote1 remote2
subvolumes remote1 remote2
end-volume
end-volume
volume replicate2
volume replicate2
type cluster/replicate
type cluster/replicate
subvolumes remote3 remote4
subvolumes remote3 remote4
end-volume
end-volume
volume distribute
volume distribute
type cluster/distribute
type cluster/distribute
subvolumes
subvolumes replicate1
replicate1 replicate2
replicate2
end-volume
end-volume
Pas de module noyau spécifique – Fonctionne via FUSE.
Montage via l'utilitaire glusterfs
83. 83
Conclusion
Gnu/Linux offre de multiples briques open-source fiables,
performantes et efficaces pour garantir un service de haute-
disponibilité quel que soit le contexte d'emploi
Clusters à n nœuds : Heartbeat2,
Répartiteur de charge : LVS,
Synchronisation de la table des sessions : Conntrackd,
Keepalived, ucarp, vrrpd - il manque aujourd'hui le support de
VRRP3 pour l'IPv6 -
Système de fichiers répartis et à haute disponibilité
Ces briques s'intègrent parfaitement avec des technologies
de virtualisation comme KVM et VSERVER
Réduction des coûts matériels
Optimisation de l'usage des ressources matérielles
Multi-vlan facilitant l'intégration de toutes sortes de services
ainsi que la mutualisation des matériels
84. Yann Dupont & Yoann Juet
Service IRTS
DSI de l' Université de Nantes
Merci de votre attention.
Des questions ?
