Ajout de deux nouvelles nodes au serveur
Pierre Coimbra
parent
7258d91e7b
commit
28e6c66ee8
13
README.md
13
README.md
|
|
@ -21,13 +21,14 @@ charge de former leur successeurs.
|
|||
# Table des matières
|
||||
1. [Présentation du Projet](presentation_projet.md)
|
||||
2. [Proxmox](proxmox)
|
||||
1. [Introduction à la virtualisation](proxmox/introduction_a_la_virtualisation.md)
|
||||
1. [Introduction à la virtualisation](proxmox/proxmox/introduction_a_la_virtualisation.md)
|
||||
2. [Installation des hyperviseurs](proxmox/installation_hyperviseurs.md)
|
||||
3. [Systèmes de fichiers et sauvegardes](#)
|
||||
4. [Cluster](proxmox/cluster)
|
||||
5. [Haute Disponibilitée](#)
|
||||
6. [Gestion de l'authentification](#)
|
||||
7. [Sécurisation des conteneurs / VM](proxmox/securisation)
|
||||
3. [Système de fichiers](proxmox/systeme_de_fichier.md)
|
||||
4. [Système de sauvegarde](proxmox/systeme_de_sauvegarde.md)
|
||||
5. [Cluster](proxmox/cluster)
|
||||
6. [Haute Disponibilité](proxmox/haute_disponibilite.md)
|
||||
7. [Gestion de l'authentification](#)
|
||||
8. [Sécurisation des conteneurs / VM](proxmox/securisation)
|
||||
3. [Réseau](reseau)
|
||||
1. [Introduction à OpenvSwitch](reseau/introduction_ovs.md)
|
||||
2. [Topologie globale du réseau](reseau/topologie_globale.md)
|
||||
|
|
|
|||
|
|
@ -4,11 +4,7 @@ Cela consiste en la gestion des flux post firewall.
|
|||
## Présentation des conteneurs
|
||||
|
||||
Deux conteneurs Debian 10 identiques, un sur Alpha l'autre sur Bêta avec deux interfaces :
|
||||
- Sur Alpha le conteneur HAProxy a comme IP 10.0.0.6/24 sur DMZ et 10.0.1.6/24 sur CTF.
|
||||
- Sur Beta le conteneur HAProxy a comme IP 10.0.0.7/24 sur DMZ et 10.0.1.7/24 sur CTF
|
||||
L'option Firewall PVE des interfaces est désactivée
|
||||
|
||||
## Le conteneur
|
||||
Numéro 102 (Alpha)
|
||||
#### Trois interfaces
|
||||
- eth0 : vmbr1 / VLAN 10 / IP 10.0.0.6 / GW 10.0.0.254
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
|
||||
Nous allons ici mettre en place le serveur LDAP qui sera répliqué sur les deux nodes. Tout les services utiliseront LDAP pour l'authentification des utilisateurs.
|
||||
A noté que pour des questions pratique nous n'allons pas utilisé Fusion Directory, il faudra donc créer un schéma pour chaque service et modifier les utilisateur avec ldapadd et ldapmodify.
|
||||
Pour la sécurisation de LDAP nous allons utiliser LDAP avec STARTTLS.
|
||||
Pour la sécurisation de LDAP nous allons utiliser LDAP avec StartTLS.
|
||||
|
||||
## Le conteneur
|
||||
Numéro 107 (Alpha)
|
||||
|
|
|
|||
|
|
@ -2,14 +2,14 @@
|
|||
|
||||
### Infrastructure matérielle
|
||||
|
||||
Du côté infrastructure, nous disposons d'un rack 1U avec deux PC à l'intérieur possédant chacun 24Go de DDR3-ECC et un Xeon x5670 6 Coeurs cadencé à 2.93 GHz. Côté stockage, nous allons mettre en place un RAID1 ZFS avec deux disques par PC (les données du premier disque seront aussi présentes sur le second) ainsi le stockage sera répliqué pour éviter toute perte de données.
|
||||
Du côté infrastructure, nous disposons de deux rack 1U avec deux PC à l'intérieur possédant chacun 24Go de DDR3-ECC et un Xeon x5670 6 Coeurs cadencé à 2.93 GHz. Côté stockage, nous allons mettre en place un RAID1 ZFS avec deux disques par PC (les données du premier disque seront aussi présentes sur le second) ainsi le stockage sera répliqué pour éviter toute perte de données.
|
||||
|
||||
Les 2 nodes du serveur, que nous appellerons Alpha et Beta, auront Proxmox comme hyperviseur et seront en cluster grâce à Proxmox.
|
||||
Les 4 nodes du serveur, que nous appellerons Alpha, Beta, Gamma et Sigma, auront Proxmox comme hyperviseur et les trois premières d'entre elles seront en cluster grâce à Proxmox.
|
||||
|
||||
### Infrastructure logicielle
|
||||
|
||||
#### Infrastructure réseau du serveur
|
||||
Les conteneurs/VMs sensibles seront répliqués entre les deux nodes
|
||||
Les conteneurs/VMs sensibles seront répliqués entre les trois nodes de production
|
||||
|
||||
L'infrastructure réseau du club s'articulerait de la manière suivante (sur chaque node) :
|
||||
- Un bloc pare-feu / routeur (OPNSense).
|
||||
|
|
|
|||
|
|
@ -4,9 +4,9 @@ Vous trouverez ici toute la documentation relative au déploiement de Proxmox.
|
|||
# Table des matières
|
||||
1. [Introduction à la virtualisation](introduction_a_la_virtualisation.md)
|
||||
2. [Installation des hyperviseurs](installation_hyperviseurs.md)
|
||||
3. [Systèmes de fichiers](systeme_de_fichier.md)
|
||||
3. [Système de fichiers](systeme_de_fichier.md)
|
||||
4. [Système de sauvegarde](systeme_de_sauvegarde.md)
|
||||
5. [Cluster](cluster)
|
||||
6. [Haute Disponibilité](#)
|
||||
5. [Cluster](creation_cluster.md)
|
||||
6. [Haute Disponibilité](haute_disponibilite)
|
||||
7. [Gestion de l'authentification](#)
|
||||
8. [Sécurisation des conteneurs / VM](securisation)
|
||||
|
|
|
|||
|
|
@ -1,7 +0,0 @@
|
|||
# Mise en place du cluster
|
||||
|
||||
Vous trouverez ici toute la documentation relative à la mise en place du multicast pour le corosync, du cluster Proxmox et de l'instance de quorum.
|
||||
|
||||
# Table des matières
|
||||
1. [Montage du cluster](creation_cluster.md)
|
||||
2. [Instance de quorum](quorum.md)
|
||||
|
|
@ -1,40 +0,0 @@
|
|||
# Respect du quorum avec seulement deux nodes
|
||||
|
||||
La technologie corosync a besoin de 3 votes minimum pour avoir le quorum et éviter les risques de splitbrain en cas de crash d'une des nodes.
|
||||
|
||||
Nous ne disposons que de deux nodes, nous allons donc mettre en place un "Corosync External Vote". Il suffit d'un conteneur sur une autre machine que nous appellerons instance de quorum.
|
||||
|
||||
## Mise en place de l'instance de quorum
|
||||
|
||||
#### Sur le conteneur de l'instance de quorum
|
||||
```
|
||||
apt-get install corosync-qnetd
|
||||
systemctl enable corosync-qnetd
|
||||
systemctl start corosync-qnetd
|
||||
```
|
||||
|
||||
#### Sur nos deux nodes
|
||||
```
|
||||
apt-get install corosync-qdevice
|
||||
systemctl enable corosync-qdevice
|
||||
systemctl start corosync-qdevice
|
||||
```
|
||||
|
||||
#### Depuis chacune de nos nodes
|
||||
```
|
||||
ssh-copy-id -i /root/.ssh/id_rsa root@ip_autre_node
|
||||
ssh-copy-id -i /root/.ssh/id_rsa root@ip_instance_quorum
|
||||
```
|
||||
## Ajout de l'instance au cluster sigma depuis Alpha
|
||||
|
||||
Maintenant que notre instance de quorum est configurée, nous allons l'ajouter au cluster Sigma
|
||||
```
|
||||
pvecm qdevice setup <ip_instance_quorum>
|
||||
```
|
||||
|
||||
On vérifie que notre cluster contienne nos deux nodes et une instance de quorum
|
||||
```
|
||||
pvecm status
|
||||
```
|
||||
|
||||
Nous avons maintenant trois votes, il y a donc suffisamment d'instances pour éviter le split-brain en cas de crash d'une node car, même avec une node en moins, le quorum sera respecté.
|
||||
|
|
@ -0,0 +1,42 @@
|
|||
# Haute Disponibilité
|
||||
|
||||
Nous allons utiliser deux types de Hautes Disponibilité (HA) :
|
||||
- La solution de HA proposé par Proxmox qui permet de migrer des conteneurs entre des nodes,
|
||||
- De la Haute Disponibilité via une IP Virtuelle grâce à Keep-alived.
|
||||
|
||||
Pour les services vitaux (HAProxy, NGINX, LDAP...) nous utiliserons une IP virtuelle, les services seront déjà présent sur toute les nodes c'est keepalived qui s'occupera de toujours rendre accessible le service.
|
||||
|
||||
Pour les services moins important (Cloud, Git...) nous utiliserons la solution proposé par Proxmox.
|
||||
|
||||
Nous avons fait cette distinction car ZFS ne permet pas la migration instantanée d'un conteneur en cas de chute d'une node, surtout s'il doit migrer plusieurs conteneurs en même temps.
|
||||
|
||||
Les services redondés et utilisant keepalived seront :
|
||||
- HAProxy : un conteneur sur chaque node, celui de Alpha sera Master,
|
||||
- NGINX : un conteneur sur chaque node load-balancing par HAProxy,
|
||||
- LDAP : un conteneur sur chaque node, réplication des données grâce à slapd et accessibilité / loadbalancing via Keepalived,
|
||||
- Redis : un conteneur sur Alpha, un sur Sigma,
|
||||
- Service Mail : un conteneur sur Alpha, un sur Sigma,
|
||||
- DNS : un conteneur sur Alpha un sur Sigma.
|
||||
|
||||
|
||||
## Répartition non exhaustive des conteneurs entre les nodes
|
||||
|
||||
OPNSense -> Alpha, Beta et Sigma
|
||||
HAProxy -> Alpha, Beta et Sigma
|
||||
NGINX -> Alpha, Beta et Sigma
|
||||
Redis -> Alpha et Sigma
|
||||
LDAP -> Alpha et Sigma
|
||||
Git -> Alpha
|
||||
Mattermost -> Alpha
|
||||
NextCloud -> Beta
|
||||
Mail -> Alpha et Sigma
|
||||
CTF -> Beta (3 services)
|
||||
LDAPUI -> Alpha
|
||||
DNS -> Beta
|
||||
Proxy interne -> Beta
|
||||
Ansible -> Alpha
|
||||
Site Web KRKN -> Sigma
|
||||
Wiki KRKN -> Beta
|
||||
Etat des services -> Alpha
|
||||
|
||||
Possibilité d'héberger des VPS d'autres Club sur la node Sigma (VLAN dédié) si accord et si stabilité.
|
||||
|
|
@ -1,8 +1,8 @@
|
|||
# Installation des hyperviseurs
|
||||
|
||||
Proxmox étant un hyperviseur de type 1, nous allons l'installer sur les deux nodes du serveur.
|
||||
Proxmox étant un hyperviseur de type 1, nous allons l'installer sur les quatres nodes du serveur.
|
||||
|
||||
Pour cette installation, nous partons du principe que les deux nodes ont accès à internet soit via une IP publique soit via un réseau privé. Cela ne change rien car nous modifierons la configuration réseau par la suite.
|
||||
Pour cette installation, nous partons du principe que les quatres nodes ont accès à internet soit via une IP publique soit via un réseau privé. Cela ne change rien car nous modifierons la configuration réseau par la suite.
|
||||
|
||||
Pour l'installation il faut :
|
||||
- Une clé USB,
|
||||
|
|
@ -53,8 +53,14 @@ Vérifier la cohérence et lancer l'installation.
|
|||
### Sur la deuxième node (Beta)
|
||||
Même procédure, dans "Management Network Configuration" il faut juste remplacer le Hostname par **beta.krhacken.org**
|
||||
|
||||
### Sur la troisième node (Gamma)
|
||||
Même procédure, dans "Management Network Configuration" il faut juste remplacer le Hostname par **gamma.krhacken.org**
|
||||
|
||||
### Sur la deuxième node (Delta)
|
||||
Même procédure, dans "Management Network Configuration" il faut juste remplacer le Hostname par **delta.krhacken.org**
|
||||
|
||||
## Préparation des hyperviseurs
|
||||
La procédure est la même sur les deux nodes. Elle peut être faite via SSH (recommandé) ou sur l'interface d'administration **https://IP:8006**
|
||||
La procédure est la même sur les quatres nodes. Elle peut être faite via SSH (recommandé) ou sur l'interface d'administration **https://IP:8006**
|
||||
|
||||
### Mise à jour
|
||||
```
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ Proxmox est un hyperviseur de type 1 (bare metal). C’est une plateforme de vir
|
|||
|
||||
Contrairement à un hyperviseur de type 2 (VirtualBox par exemple), Proxmox ne s'exécute pas dans un autre OS mais dispose de son propre OS (basé sur Debian) adapté à la virtualisation.
|
||||
|
||||
Donc, Proxmox permet la virtualisation de plusieurs machines au sein d’un seul serveur. Proxmox nous permettra aussi des mettre les deux nodes du rack en cluster permettant entre autre de migrer des contenants d'une node à l'autre en cas de chute de l'une d'elles grâce aux fonctions de Haute Disponibilité de Proxmox.
|
||||
Donc, Proxmox permet la virtualisation de plusieurs machines au sein d’un seul serveur. Proxmox nous permettra aussi des mettre les quatres nodes du serveur en cluster permettant entre autre de migrer des contenants d'une node à l'autre en cas de chute de l'une d'elles grâce aux fonctions de Haute Disponibilité de Proxmox.
|
||||
|
||||
## Technologie de virtualisation
|
||||
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ On a quatres nodes dont 3 d'entre elle en production il faut donc limiter au max
|
|||
|
||||
Nous avons choisi d'avoir 4 pools ZFS indépendante pour que la réplication des données soit indépendante d'une node à l'autre.
|
||||
|
||||
## Avantage de ZFS
|
||||
## Avantages de ZFS
|
||||
|
||||
|
||||
## Mise en place des pools
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# Système de sauvegarde
|
||||
# Système de sauvegarde
|
||||
|
||||
Afin de limiter encore plus le risque de perte de données nous allons mettre en place un système de sauvegarde de tout les conteneurs / VMs. Nous allons utilisé BorgBackup, le réseau de sauvegarde est un réseau local, en effet la quatrième node sera dédié au système de sauvegarde. De ce fait elle ne sera pas dans le cluster, au niveau du système de fichier nous utiliserons la encore un RAID-1 ZFS. Les sauvegardes passerons par la VLAN 100 du switch administration (10.1.0.0/24).
|
||||
|
||||
|
|
|
|||
|
|
@ -12,10 +12,13 @@ Switch Wan VLAN 10
|
|||
Switch Interne VLAN 10
|
||||
- Proxmox Alpha :10.0.0.1
|
||||
- Proxmox Beta : 10.0.0.2
|
||||
- Firewall Alpha : 10.0.0.3
|
||||
- Firewall Beta : 10.0.0.4
|
||||
- HAProxy Alpha : 10.0.0.6
|
||||
- HAProxy Beta : 10.0.0.7
|
||||
- Proxmox Sigma : 10.0.0.3
|
||||
- Firewall Alpha : 10.0.0.4
|
||||
- Firewall Beta : 10.0.0.5
|
||||
- Firewall Sigma : 10.0.0.6
|
||||
- HAProxy Alpha : 10.0.0.7
|
||||
- HAProxy Beta : 10.0.0.8
|
||||
- HAProxy Sigma : 10.0.0.9
|
||||
- HAProxy VIP : 10.0.0.8
|
||||
- Proxy Interne : 10.0.0.252
|
||||
- DNS : 10.0.0.253
|
||||
|
|
@ -25,32 +28,45 @@ Switch Interne VLAN 10
|
|||
Switch Interne VLAN 20
|
||||
- HAProxy Alpha : 10.0.1.1
|
||||
- HAProxy Beta : 10.0.1.2
|
||||
- HAProxy Sigma : 10.0.1.3
|
||||
- Nginx Public Alpha : 10.0.1.3
|
||||
- Nginx Public Beta : 10.0.1.4
|
||||
- Mail : 10.0.1.10
|
||||
- Firewall Alpha : 10.0.1.250
|
||||
- Firewall Bêta : 10.0.1.251
|
||||
- Nginx Public Sigma : 10.0.1.3
|
||||
- Mail Alpha : 10.0.1.10
|
||||
- Mail Sigma : 10.0.1.11
|
||||
- Mail VIP : 10.0.1.12
|
||||
- Firewall Alpha : 10.0.1.247
|
||||
- Firewall Beta : 10.0.1.248
|
||||
- Firewall Sigma : 10.0.1.249
|
||||
- DNS Alpha : 10.0.1.250
|
||||
- DNS Sigma : 10.0.1.251
|
||||
- Proxy Interne : 10.0.1.252
|
||||
- DNS : 10.0.1.253
|
||||
- Firewall VIP : 10.0.0.254
|
||||
- DNS VIP : 10.0.1.253
|
||||
- Firewall VIP : 10.0.1.254
|
||||
|
||||
### INT
|
||||
Switch Interne VLAN 30
|
||||
- LDAP Alpha : 10.0.2.1
|
||||
- LDAP Bêta : 10.0.2.2
|
||||
- LDAP Beta : 10.0.2.1
|
||||
- LDAP Sigma : 10.0.2.2
|
||||
- LDAP VIP : 10.0.2.3
|
||||
- Nginx Public Alpha : 10.0.2.4
|
||||
- Nginx Public Beta : 10.0.2.5
|
||||
- Mail Frontend : 10.0.2.10
|
||||
- Mail Backend : 10.0.2.11
|
||||
- Nginx Public Sigma : 10.0.2.3
|
||||
- Mail Frontend : 10.0.2.9 (peut-être)
|
||||
- Mail Backend Alpha : 10.0.2.10
|
||||
- Mail Backend Sigma : 10.0.2.11
|
||||
- Mail Backend VIP : 10.0.2.12
|
||||
- LDAP WebUI : 10.0.2.15
|
||||
- Nextcloud : 10.0.2.20
|
||||
- Gitea : 10.0.2.21
|
||||
- [...]
|
||||
- Firewall Alpha : 10.0.2.250
|
||||
- Firewall Bêta : 10.0.2.251
|
||||
- Firewall Alpha : 10.0.2.247
|
||||
- Firewall Beta : 10.0.2.248
|
||||
- Firewall Sigma : 10.0.2.249
|
||||
- DNS Alpha : 10.0.2.250
|
||||
- DNS Sigma : 10.0.2.251
|
||||
- Proxy Interne : 10.0.2.252
|
||||
- DNS : 10.0.2.253
|
||||
- DNS VIP : 10.0.2.253
|
||||
- Firewall VIP : 10.0.2.254
|
||||
|
||||
|
||||
|
|
@ -58,24 +74,27 @@ Switch Interne VLAN 30
|
|||
Switch Interne VLAN 40
|
||||
- HAProxy Alpha : 10.0.3.1
|
||||
- HAProxy Beta : 10.0.3.2
|
||||
- Nginx CTF : 10.0.3.3
|
||||
- HAProxy Sigma : 10.0.3.3
|
||||
- Nginx CTF : 10.0.3.4
|
||||
- CTFd Open : 10.0.3.10
|
||||
- CTFd Special : 10.0.3.11
|
||||
- Environnement Système : 10.0.3.12
|
||||
- Environnement Web : 10.0.3.13
|
||||
- [...]
|
||||
- Firewall Alpha : 10.0.3.250
|
||||
- Firewall Bêta : 10.0.3.251
|
||||
- Firewall Alpha : 10.0.3.249
|
||||
- Firewall Bêta : 10.0.3.250
|
||||
- Firewall Sigma : 10.0.3.251
|
||||
- Proxy Interne : 10.0.3.252
|
||||
- Firewall VIP : 10.0.3.254
|
||||
|
||||
|
||||
### DIRTY :
|
||||
Switch Interne VLAN 50
|
||||
- Firewall Alpha : 10.0.4.250
|
||||
- Firewall Bêta : 10.0.4.251
|
||||
- Proxy Interne : 10.0.4.252
|
||||
- Firewall VIP : 10.0.4.254
|
||||
- Firewall Alpha : 10.0.4.6249
|
||||
- Firewall Bêta : 10.0.4.6250
|
||||
- Firewall Sigma : 10.0.4.251
|
||||
- Proxy Interne : 10.0.4.6252
|
||||
- Firewall VIP : 10.0.4.6254
|
||||
|
||||
Pas d'autres conteneurs permanent (10.0.4.0/24)
|
||||
|
||||
|
|
@ -83,28 +102,33 @@ Pas d'autres conteneurs permanent (10.0.4.0/24)
|
|||
Switch Interne VLAN 100
|
||||
- Alpha : 10.0.10.1
|
||||
- Beta : 10.0.10.2
|
||||
- Gamma : 10.0.10.3
|
||||
|
||||
### CoroSync internal
|
||||
Switch Administration VLAN 10
|
||||
- Alpha : 10.1.1.1
|
||||
- Beta : 10.1.1.2
|
||||
- Gamma : 10.1.1.3
|
||||
|
||||
### pfSync internal
|
||||
Switch Administration VLAN 20
|
||||
- Alpha : 10.1.2.1
|
||||
- Beta : 10.1.2.2
|
||||
- Gamma : 10.1.2.3
|
||||
|
||||
### GRE admin
|
||||
Switch Administration VLAN 30
|
||||
- Alpha : 10.1.10.1
|
||||
- Beta : 10.1.10.2
|
||||
- Gamma : 10.1.10.3
|
||||
|
||||
### Administration :
|
||||
Switch Administration VLAN 100
|
||||
- Firewall Alpha : 10.1.0.1
|
||||
- Firewall Bêta : 10.1.0.2
|
||||
- Proxmox Alpha : 10.1.0.3
|
||||
- Proxmox Beta : 10.1.0.4
|
||||
- Proxmox Alpha : 10.1.0.4
|
||||
- Proxmox Beta : 10.1.0.5
|
||||
- Proxmox Gamma : 10.1.0.6
|
||||
- [...]
|
||||
- Proxy Interne : 10.1.0.252
|
||||
- DNS : 10.1.0.253
|
||||
|
|
@ -120,7 +144,7 @@ La configuration et les branchement à faire sur le switch sera détaillé plus
|
|||
Cette partie consiste à mettre en place OpenvSwitch sur les deux nodes.
|
||||
|
||||
## Installation
|
||||
Commune aux deux nodes
|
||||
Commune aux trois nodes
|
||||
```
|
||||
apt-get update
|
||||
apt-get install openvswitch-switch
|
||||
|
|
@ -180,12 +204,14 @@ iface vmbr1 inet manual
|
|||
ovs_ports bond0 vx1
|
||||
up ovs-vsctl set Bridge ${IFACE} rstp_enable=true
|
||||
up ovs-vsctl --may-exist add-port vmbr1 gre1 -- set interface gre1 type=gre options:remote_ip='10.0.10.2'
|
||||
up ovs-vsctl --may-exist add-port vmbr1 gre2 -- set interface gre2 type=gre options:remote_ip='10.0.10.3'
|
||||
down ovs-vsctl --if-exists del-port vmbr1 gre1
|
||||
down ovs-vsctl --if-exists del-port vmbr1 gre2
|
||||
|
||||
#Admin Task
|
||||
allow-vmbr0 admintask
|
||||
iface vmbr0task inet static
|
||||
address 10.1.0.3
|
||||
address 10.1.0.4
|
||||
netmask 24
|
||||
ovs_type OVSIntPort
|
||||
ovs_bridge vmbr0
|
||||
|
|
@ -224,8 +250,10 @@ iface vmbr0 inet manual
|
|||
ovs_type OVSBridge
|
||||
ovs_ports eth2 vx2
|
||||
up ovs-vsctl set Bridge ${IFACE} rstp_enable=true
|
||||
up ovs-vsctl --may-exist add-port vmbr0 gre2 -- set interface gre2 type=gre options:remote_ip='10.1.10.2'
|
||||
down ovs-vsctl --if-exists del-port vmbr0 gre2
|
||||
up ovs-vsctl --may-exist add-port vmbr0 gre3 -- set interface gre3 type=gre options:remote_ip='10.1.10.2'
|
||||
up ovs-vsctl --may-exist add-port vmbr0 gre4 -- set interface gre4 type=gre options:remote_ip='10.1.10.3'
|
||||
down ovs-vsctl --if-exists del-port vmbr0 gre3
|
||||
down ovs-vsctl --if-exists del-port vmbr0 gre4
|
||||
```
|
||||
|
||||
### Pour Beta (/etc/network/interfaces)
|
||||
|
|
@ -280,12 +308,14 @@ iface vmbr1 inet manual
|
|||
ovs_ports bond0 vx1
|
||||
up ovs-vsctl set Bridge ${IFACE} rstp_enable=true
|
||||
up ovs-vsctl --may-exist add-port vmbr1 gre1 -- set interface gre1 type=gre options:remote_ip='10.0.10.1'
|
||||
up ovs-vsctl --may-exist add-port vmbr1 gre2 -- set interface gre2 type=gre options:remote_ip='10.0.10.3'
|
||||
down ovs-vsctl --if-exists del-port vmbr1 gre1
|
||||
down ovs-vsctl --if-exists del-port vmbr1 gre2
|
||||
|
||||
#Admin Task
|
||||
allow-vmbr0 admintask
|
||||
iface coro inet static
|
||||
address 10.1.0.4
|
||||
address 10.1.0.5
|
||||
netmask 24
|
||||
ovs_type OVSIntPort
|
||||
ovs_bridge vmbr0
|
||||
|
|
@ -318,12 +348,118 @@ iface vx2 inet static
|
|||
ovs_bridge vmbr0
|
||||
ovs_options tag=30
|
||||
|
||||
#OVS Bridge administation
|
||||
auto vmbr0
|
||||
iface vmbr0 inet manual
|
||||
ovs_type OVSBridge
|
||||
ovs_ports eth2 vx2
|
||||
up ovs-vsctl set Bridge ${IFACE} rstp_enable=true
|
||||
up ovs-vsctl --may-exist add-port vmbr0 gre3 -- set interface gre3 type=gre options:remote_ip='10.1.10.1'
|
||||
up ovs-vsctl --may-exist add-port vmbr0 gre4 -- set interface gre4 type=gre options:remote_ip='10.1.10.3'
|
||||
down ovs-vsctl --if-exists del-port vmbr0 gre3
|
||||
down ovs-vsctl --if-exists del-port vmbr0 gre4
|
||||
```
|
||||
|
||||
### Pour Gamma (/etc/network/interfaces)
|
||||
```
|
||||
#Bond eth1/eth3 pour vmbr1
|
||||
allow-vmbr1 bond0
|
||||
iface bond0 inet manual
|
||||
ovs_bonds eth1 eth3
|
||||
ovs_type OVSBond
|
||||
ovs_bridge vmbr1
|
||||
ovs_options bond_mode=active-backup
|
||||
|
||||
auto lo
|
||||
iface lo inet loopback
|
||||
|
||||
iface eth0 inet manual
|
||||
|
||||
iface eth1 inet manual
|
||||
|
||||
iface eth2 inet manual
|
||||
|
||||
iface eth3 inet manual
|
||||
|
||||
# WAN
|
||||
allow-vmbr0 wan
|
||||
iface lan inet static
|
||||
address X.X.X.X
|
||||
netmask YY
|
||||
gateway Z.Z.Z.Z
|
||||
ovs_type OVSIntPort
|
||||
ovs_bridge vmbr0
|
||||
ovs_options tag=10
|
||||
|
||||
allow-ovs vmbr0
|
||||
iface vmbr0 inet manual
|
||||
ovs_type OVSBridge
|
||||
ovs_ports eth0
|
||||
|
||||
#GRE vmbr1
|
||||
allow-vmbr1 vx1
|
||||
iface gre1 inet static
|
||||
address 10.0.10.3
|
||||
netmask 24
|
||||
ovs_type OVSIntPort
|
||||
ovs_bridge vmbr1
|
||||
ovs_options tag=100
|
||||
|
||||
#OVS Bridge interne
|
||||
auto vmbr1
|
||||
iface vmbr1 inet manual
|
||||
ovs_type OVSBridge
|
||||
ovs_ports bond0 vx1
|
||||
up ovs-vsctl set Bridge ${IFACE} rstp_enable=true
|
||||
up ovs-vsctl --may-exist add-port vmbr1 gre1 -- set interface gre1 type=gre options:remote_ip='10.0.10.1'
|
||||
up ovs-vsctl --may-exist add-port vmbr1 gre2 -- set interface gre2 type=gre options:remote_ip='10.0.10.2'
|
||||
down ovs-vsctl --if-exists del-port vmbr1 gre1
|
||||
down ovs-vsctl --if-exists del-port vmbr1 gre2
|
||||
|
||||
#Admin Task
|
||||
allow-vmbr0 admintask
|
||||
iface vmbr0task inet static
|
||||
address 10.1.0.6
|
||||
netmask 24
|
||||
ovs_type OVSIntPort
|
||||
ovs_bridge vmbr0
|
||||
ovs_options tag=100
|
||||
|
||||
#Corosync
|
||||
allow-vmbr0 coro
|
||||
iface coro inet static
|
||||
address 10.1.1.3
|
||||
netmask 24
|
||||
ovs_type OVSIntPort
|
||||
ovs_bridge vmbr0
|
||||
ovs_options tag=10
|
||||
|
||||
#pfSync
|
||||
allow-vmbr0 pfsync
|
||||
iface pfsync inet static
|
||||
address 10.1.2.3
|
||||
netmask 24
|
||||
ovs_type OVSIntPort
|
||||
ovs_bridge vmbr0
|
||||
ovs_options tag=20
|
||||
|
||||
#GRE vmbr0
|
||||
allow-vmbr0 vx2
|
||||
iface vx2 inet static
|
||||
address 10.1.10.3
|
||||
netmask 24
|
||||
ovs_type OVSIntPort
|
||||
ovs_bridge vmbr0
|
||||
ovs_options tag=30
|
||||
|
||||
#OVS Bridge administation
|
||||
auto vmbr0
|
||||
iface vmbr0 inet manual
|
||||
ovs_type OVSBridge
|
||||
ovs_ports eth2 vx2
|
||||
up ovs-vsctl set Bridge ${IFACE} rstp_enable=true
|
||||
up ovs-vsctl --may-exist add-port vmbr0 gre2 -- set interface gre2 type=gre options:remote_ip='10.1.10.1'
|
||||
down ovs-vsctl --if-exists del-port vmbr0 gre2
|
||||
up ovs-vsctl --may-exist add-port vmbr0 gre3 -- set interface gre3 type=gre options:remote_ip='10.1.10.1'
|
||||
up ovs-vsctl --may-exist add-port vmbr0 gre4 -- set interface gre4 type=gre options:remote_ip='10.1.10.2'
|
||||
down ovs-vsctl --if-exists del-port vmbr0 gre3
|
||||
down ovs-vsctl --if-exists del-port vmbr0 gre4
|
||||
```
|
||||
|
|
|
|||
Loading…
Reference in New Issue