Mais pourquoi ? Le réseau ne suffit pas ?
Un backbone IP/MPLS n'est pas suffisant à l'heure actuelle pour répondre à tous les besoins clients (et aussi ceux d'un opérateur).
Par exemple, nos radius, nos serveurs DNS/MAIL/Monitoring, notre source de vérité, notre cloud doivent bien être virtualisés quelque part. On ne va pas acheter/configurer/racker un serveur dédié pour un service ! L'addition serait salée 😃
Notre but est donc de pouvoir virtualiser un certains nombres de services. Idéalement, je voudrai "deux clouds" : un privé (pour les besoins infra opérateur) et un public (pour les demandes clients). Etant un petit opérateur, je ne vais pas pouvoir, au début, en avoir deux malheureusement 🙁
Se pose la question de quel système utiliser. Je souhaite, idéalement, un hyperviseur open source, basé sur linux, bon forum, grande communauté, l'implémentation du SDN (vous allez voir pourquoi après) et du HCI. Un petit tableau récapitulatif :
| VMware | HyperV | Proxmox | XEN | OpenStack | OpenNebula | |
|---|---|---|---|---|---|---|
| Tier | 1 | 1 | 1 | 1 | Orchestrateur multi hyperviseur | Orchestrateur multi hyperviseur |
| Open Source | Non | Non | Oui | Oui | Oui | Oui |
| OS | VMware | Windows | Debian | XCP-NG | Ca depend | Alma / RHEL |
| Prix | Fuck Broadcom | Fuck Microsoft | Gratuit | Gratuit | Gratuit | Gratuit |
| SDN | Oui via NSX | Oui | Oui | Oui | Oui | Oui |
| Stockage Hyperconvergence | VSAN | S2D | Ceph | Ceph | Ceph | Ceph |
OpenStack et OpenNebula sont plus des clouds public, VMware et HyperV c'est non !
Reste plus que Xen ou Promox. Etant plus à l'aise avec Promox, j'ai décidé de partir là dessus !
Solutions Proxmox
- PVE : Proxmox Virtual Environment (un serveur où on installe l'OS Proxmox).
- PBS : Proxmox Backup Server (un serveur qui permet de backuper les VM)
- PDM : Proxmox Datacenter Manager (un serveur qui permet de gouverner les PVE que ce soit en multi cluster, mono cluster)
Installation Proxmox
Ce blog ne tend pas à montrer comment installer Proxmox, il existe déjà un wiki bien documenté et un OS fourni (ou installation via paquets). J'ai juste installé mon OS sur deux disques ZFS en mirror (équivalent au RAID1 mais sans la carte matérielle pour faire du RAID !).
Configuration réseau Proxmox
Au lieu de faire du L2 entre les leafs et les serveurs, je souhaite pousser l'EVPN/VXLAN au bout !
Utilisant la version 9 de proxmox, on a accès au SDN intégré en GUI. Cependant, je le trouve assez limité (si ce n'est inutile) quand il s'agit de relier le cluster à une fabric externe (comme ma fabric Arista). J'ai l'impression qu'ils ont pensé au SDN que pour les membres d'un cluster Proxmox.
Donc j'ai préféré utiliser la bonne vieille CLI de Debian. On verra par la suite si j'arrive à basculer sur le SDN de Proxmox (peut-être à la version 9.1). Proxmox est basé sur FRR donc bon ! Retour aux sources 😄
Je vais utiliser cette architecture au début : (rien de bien compliqué, mon vEOS est un leaf qui fait EVPN/VXLAN avec un hôte derrière)
L'interco se fait dans le subnet 192.168.100.0/24 (.1 pour l'Arista et .2 pour Proxmox).
La Loopback de PVE1 est 172.16.1.51 et 172.16.1.1 pour l'Arista.
La conf du fichier /etc/network/interfaces du PVE :
root@pve1:~# cat /etc/network/interfaces
auto lo
iface lo inet loopback
iface ens18 inet manual
auto vmbr0
iface vmbr0 inet static
address 192.168.1.154/24
gateway 192.168.1.254
bridge-ports ens18
bridge-stp off
bridge-fd 0
auto ens19
iface ens19 inet static
address 192.168.100.2/24
auto lo1
iface lo1 inet manual
pre-up ip link add lo1 type dummy
address 172.16.1.51/32
L'interface ens18 et le vmbr0 c'est uniquement pour le management.
Et côté FRR ?
pve1# sh run
Building configuration...
Current configuration:
!
frr version 10.3.1
frr defaults datacenter
hostname pve1
log syslog informational
service integrated-vtysh-config
!
router bgp 65051
bgp router-id 172.16.1.51
timers bgp 20 60
neighbor 192.168.100.1 remote-as 65051
neighbor 192.168.100.1 update-source 192.168.100.2
neighbor 192.168.100.1 capability extended-nexthop
!
address-family ipv4 unicast
redistribute connected
exit-address-family
!
address-family l2vpn evpn
neighbor 192.168.100.1 activate
advertise-all-vni
exit-address-family
exit
!
end
Sur l'Arista, rien de nouveau :
TEST#sh run | s bgp
router bgp 65051
router-id 172.16.1.1
timers bgp 20 60
distance bgp 20 200 200
graceful-restart-helper long-lived
maximum-paths 8 ecmp 16
neighbor 192.168.100.2 remote-as 65051
neighbor 192.168.100.2 update-source Ethernet1
neighbor 192.168.100.2 description PVE1
neighbor 192.168.100.2 ebgp-multihop 2
neighbor 192.168.100.2 send-community extended
!
vlan 1000
rd 65051:1000
route-target both 1:1
route-target both 65051:1000
redistribute learned
!
address-family evpn
neighbor 192.168.100.2 activate
!
address-family ipv4
neighbor 192.168.100.2 activate
redistribute connected
TEST#sh run int vxlan1
interface Vxlan1
vxlan source-interface Loopback1
vxlan udp-port 4789
vxlan encapsulation ipv4
vxlan vlan 1000 vni 1000
Mes sessions EVPN montent bien :
pve1# sh bgp evpn summary
BGP router identifier 172.16.1.51, local AS number 65051 VRF default vrf-id 0
BGP table version 0
RIB entries 7, using 896 bytes of memory
Peers 2, using 47 KiB of memory
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd PfxSnt Desc
192.168.100.1 4 65051 2077 1584 46 0 0 05:55:58 2 2 N/A
Total number of neighbors 1
Maintenant, il faut créer une interface bridge linux qu'on va attribuer à la VM et qu'on link à une interface VXLAN. De retour dans le fichier /etc/network/interfaces :
auto VNET1000
iface VNET1000
bridge_ports vxlan_VNET1000
bridge_stp off
bridge_fd 0
mtu 1450
auto vxlan_VNET1000
iface vxlan_VNET1000
vxlan-id 1000
vxlan-learning off
bridge-learning off
vxlan-local-tunnelip 172.16.1.51
mtu 1450
On restart le démon networking et on regarde en GUI ce que ca donne :
Plus qu'à tester ! On créer une VM et on lui attribue l'interface VNET1000 :
On lui attribue une IP : 10.0.0.1/24 et l'hôte derrière l'Arista 10.0.0.2/24.
On a bien les MACs dans les VNI sur les deux VTEPs :
pve1# sh evpn mac vni 1000
Number of MACs (local and remote) known for this VNI: 2
Flags: N=sync-neighs, I=local-inactive, P=peer-active, X=peer-proxy
MAC Type Flags Intf/Remote ES/VTEP VLAN Seq #'s
bc:24:11:8f:74:b6 local fwpr100p0 0/0
50:00:00:1b:00:00 remote 172.16.1.1 0/0
TEST#sh mac address-table vlan 1000
Mac Address Table
------------------------------------------------------------------
Vlan Mac Address Type Ports Moves Last Move
---- ----------- ---- ----- ----- ---------
1000 5000.001b.0000 DYNAMIC Et2 1 7:25:25 ago
1000 bc24.118f.74b6 DYNAMIC Vx1 1 0:10:08 ago
Total Mac Addresses for this criterion: 2
On voit bien que les VTEPs se découvrent de façon dynamique :
pve1# sh evpn vni 1000
VNI: 1000
Type: L2
Vlan: 1
Bridge: VNET1000
Tenant VRF: default
VxLAN interface: vxlan_VNET1000
VxLAN ifIndex: 106
SVI interface: VNET1000
SVI ifIndex: 107
Local VTEP IP: 172.16.1.51
Mcast group: 0.0.0.0
Remote VTEPs for this VNI:
172.16.1.1 flood: HER
Number of MACs (local and remote) known for this VNI: 2
Number of ARPs (IPv4 and IPv6, local and remote) known for this VNI: 1
Advertise-gw-macip: No
Advertise-svi-macip: No
Un petit ping ?
[admin@MikroTik] > /ping 10.0.0.1
SEQ HOST SIZE TTL TIME STATUS
0 10.0.0.1 56 64 2ms2us
1 10.0.0.1 56 64 2ms800us
2 10.0.0.1 56 64 2ms546us
sent=3 received=3 packet-loss=0% min-rtt=2ms2us avg-rtt=2ms449us
max-rtt=2ms800us
EZ l'EVPN/VXLAN entre nos hyperviseurs et les leafs !!!
Wireshark
Rien de nouveau, on observe bien l'entête VXLAN entre nos deux VTEPs :
Limitations et conclusion
Pour le premier épisode de l'infra hosting, j'ai décidé de ne pas me baser sur le SDN intégré à la GUI de Proxmox, j'ai eu beaucoup de mal à monter l'EVPN entre les deux VTEPs et impossible de monter le VXLAN en utilisant la méthode d'apprentissage dynamique des VTEPs ... Obligé de mettre les peer en statique donc autant dire pas ouf.
De plus, il semblerait que je ne puisse pas faire du vlan-aware-bundle pour le VXLAN. Ce qui signifie un VLAN = une VNI = un RD. Dommage 😦
Le SDN Proxmox est basé sur IfUpDown2 (https://github.com/CumulusNetworks/ifupdown2) qui ne supporte pas le VXLAN en IPv6 ... Une discussion est en cours (https://github.com/CumulusNetworks/ifupdown2/pull/315). Il semblerait que le PR résout le problème mais NVIDIA ne l'a jamais passé en prod. Dans un monde qui tend en IPv6, c'est pas sérieux du tout !
C'est pour cela que j'ai décidé de passer en CLI 😃
Prochain épisode : Mise en cluster des Proxmox et si tout fonctionne, on commence à tâter du CEPH !
Je termine sur un mot de fin : recherche travail por favor (service infra/production/exploitation/avant vente d'un opérateur BtoB)