> Là où ça peut « coincer » ce sera sur les performances en > routage/forwarding liées au passage dans les interfaces réseaux > virtualisées (ça représente forcément quelques copies supplémentaires en > mémoire, entre la carte réseau, l'hyperviseur, le noyau de la vm, etc.).
En fait, plus vraiment. Deux trois papiers sur le sujet : 1° Network DMA, extensions VTq et notion de DMA remapping https://software.intel.com/en-us/blogs/2009/06/25/understanding-vt-d-intel-virtualization-technology-for-directed-io https://www.usenix.org/system/files/conference/hotos15/hotos15-paper-kaufmann.pdf http://docs.oracle.com/cd/E19604-01/821-0406/usingniuhybridio/index.html En clair, la mémoire est accédée directement depuis la carte réseau sans passer par le CPU (DMA), et en environnement virtualisé, c'est idem au prix d'un "petit" NAT pour supporter la partie virtualisée. Bref, ça coute pas bien cher en latence. VTq permet aussi que la VM "voit" de manière indirecte le hardware sous jacent. Attention à ne pas confondre avec PCI-Passthrough où la VM a un accès 1:1 avec ce même hardware. Latence quasi native dans ce dernier mode. 2° SR-IOV simili-virtualisation poussée sur le hardware (norme PCI). Couplé à un PCI-passthrough permet à la VM d'accéder de manière exclusive au hardware ... sans être si exclusif (permet de "découper" une carte réseau en instance). Latence à peine plus élevée qu'en PCI-passthrough standard. Ces deux points ont l'air super ? En fait, ils niquent l'intérêt des VMs (indépendance au hardware réel, gestion de drivers physiques en environnement virtuels, possibilité de migration à chaud, etc...) Donc on en arrive à 3° DPDK en environnement virtuel/paravirtuel http://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/techpaper/intel-dpdk-vsphere-solution-brief-white-paper.pdf http://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/techpaper/vmware-tuning-telco-nfv-workloads-vsphere-white-paper.pdf https://vietstack.wordpress.com/2016/01/24/the-evolution-of-io-virtualization-and-dpdk-ovs-implementation-in-linux/ Comme toujours, ça demande un tunning fin quand on monte aux perf extremes, mais tenir du 10G en forwarding sur une simple VM Linux est maintenant à la portée du premier venu, ou presque. Le N x 10G c'est un peu plus complexe, mais à peine en L3/L4. En L7 ... là par contre, ça commence à être rigolo (typiquement, du Snort, du WAF, etc.). Bien prendre en compte la notion de noeud NUMA pour le sizing max (pas la peine de créer une VM qui s'étale sur plusieurs noeuds), et puis les recommandations classiques : ne pas mixer des VMs 8/16 vCPU à coté de VMs à 1 vCPU (problemes de co-stop), bien réserver la RAM (pas de swap), creuser la conf de ses drivers, voir désactiver les fonctions à la con qui ont tendance à mettre la grouille (TCP offload, etc...) Le 28 octobre 2016 à 14:28, Aurélien Guillaume <footp...@gmail.com> a écrit : > > > > On 28 Oct 2016, at 11:51, Dominique Rousseau <d.rouss...@nnx.com> wrote: > > > > Le Thu, Oct 27, 2016 at 09:18:07PM +0200, Richard MATOS [ > r.matospa...@gmail.com] a écrit: > >> Est-ce que certains d'entre vous qui utilisent Quagga, Bird ou Vyos... > le > >> font sur des machines virtuelles? si oui quels sont les retours > >> d???expérience en terme de performance? de gestion...? > > > > Pour la partie BGP, je vois aucun soucis "a priori", lié au fait que ton > > Quagga ou Bird tourne dans une VM, tant qu'elle est correctement > > dimensionnée en RAM et vCPU (pas surbookés :) > > > > Là où ça peut « coincer » ce sera sur les performances en > > routage/forwarding liées au passage dans les interfaces réseaux > > virtualisées (ça représente forcément quelques copies supplémentaires en > > mémoire, entre la carte réseau, l'hyperviseur, le noyau de la vm, etc.). > > > > Penser aussi à des choses qui peuvent (ou pas) être impactantes selon > l’utilisation envisagées: > > - Etat des optiques > - Etat physique des cartes réseau pas propagé à la VM (routes “connected” > qui ne tombent pas) > - Ralentissements ponctuels lors de snapshots ou mouvements d’un hôte à > l’autre selon l’hyperviseur > > > Sinon, au sujet de VyOS j’ai des retours mitigés de l’époque où cela > s’appelait Vyatta avant le rachat par Brocade - donc assez vieux. J’avais > trouvé le fonctionnement plutôt stable à partir du moment où on ne touche > pas. La CLI permet(tait ?) facilement de faire vautrer les sous-systèmes si > on ne sépare pas certaines opérations avec des commits distincts (par ex, > sur la suppression de configuration de VLAN et d’interfaces dans le même > commit); aussi, je n’ai jamais réussi à utiliser correctement des > peer-groups BGP, la conf partait facilement en vrille et obligé de reload. > Cela a probablement été corrigé ou amélioré depuis. > > Cordialement, > -- > Aurélien Guillaume > footp...@gmail.com > > --------------------------- > Liste de diffusion du FRnOG > http://www.frnog.org/ > -- Cordialement, Guillaume BARROT --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
