Auteur/autrice : Guy VANDENBERGHE

La norme et les câbles USB

Publié le par Guy VANDENBERGHE

USB est l’abréviation de “Universal Serial Bus” ou “Bus Universel en Série”. Il s’agit du type de connexion standard dont sont dotés beaucoup d’ordinateurs et divers périphériques.

Avant l’USB, il existait d’autres connecteurs, de l’ADB au FireWire et au SCSI, chacun avec ses propres caractéristiques.

Comme c’est le cas pour de nombreuses normes, l’USB n’a cessé de s’améliorer et d’offrir de nouvelles fonctionnalités.

Les différentes vitesses USB

Les vitesses USB sont d’abord assez simple à comprendre, rappelez-vous qu’un mégaoctet est huit fois plus grand qu’un mégabit (Mb). Dans les détails :

  • L’USB 1.1 (Full-Speed) pouvait atteindre 12 mégabits par seconde (12Mbps), ce qui équivaut à 0,125 mégaoctet par seconde (Mbps).  
  • L’USB 2.0 (Hi-Speed) a une vitesse de 480 Mbps, soit 60 MBps.  
  • L’USB 3.0 (Super-Speed) a atteint de nouveaux sommets avec 5 gigabits par seconde (5Gbps), soit 625 MBps ou 5 000 Mbps.  

Cette dernière norme s’est diversifiée, la preuve en est avec sa version 3.1 et ses deux variantes : USB 3.1 Gen 1, identique à USB 3.0 SuperSpeed, à 5 000 Mbps, et USB 3.1 Gen 2, SuperSpeed+, à 10 000 Mbps.

L’USB 3.2 est uniquement destiné à l’USB-C, et non à l’USB-A. Il ressemble à l’USB 3.1, en proposant une vitesse maximale de 10 Gbps. 

Il est sujet à trois taux de transfert :  

  • USB 3.2 Gen 1 : USB SuperSpeed à 5 Gbps. 
  • USB 3.2 Gen 2 : USB SuperSpeed+ à 10 Gbps. 
  • USB 3.2 Gen 2×2 : USB SuperSpeed+ à 20 Gbps. 

Un connecteur USB-C dispose de quatre paires de broches pour transmettre et recevoir les données.

Thunderbolt

Le Thunderbolt 3 (T3) variante produit par Apple, ressemble au USB-C, néanmoins il est beaucoup plus rapide (40,000 Mbps) et performant. Il fournit des données PCI Express pour les disques durs, les disques SSD et les cartes graphiques, ainsi que la fonctionnalité DisplayPort.

Il s’agit également d’un câble à pair et non d’un câble hôte, il a donc pour but de connecter plusieurs périphériques.

Le Thunderbolt 4 (T4) permet d’utiliser des câbles plus longs (2 m contre 1m pour le T3) et d’autres fonctions intéressantes, telles que la protection des données par accès direct à la mémoire (DMA) et le Hub. Tous les appareils compatibles prennent en charge au moins deux écrans externes 4K, ou un seul écran 8K.

La certification Thunderbolt 4 exige que la bande passante PCIe soit doublée à 32 Gbps.

USB 4 ou 4.0

Déjà présenté en 2019, l’USB 4.0 ou l’USB 4 vise avant tout à simplifier la diversité confuse des différentes spécifications et donc la jungle des appellations. Depuis l’arrivée de l’USB 3.0 et de ses générations suivantes sur les marchés à partir de 2019, on a facilement perdu la vue d’ensemble, car les connecteurs de cette génération étaient tous identiques. Les utilisateurs d’Apple le savent suffisamment. De nouveaux câbles et connecteurs ont dû être achetés. C’était la naissance du connecteur USB Type C. Il a également permis d’améliorer de manière significative la vitesse et la quantité d’électricité.

L’USB tytpe 4 à venir est basé sur le protocole Thunderbolt 3 qui prend en charge un débit allant jusqu’à 40 Gbps. Il a exactement la même apparence que l’USB-C, l’USB 3.2 et les Thunderbolt 3 et 4.  

En plus de sa compatibilité avec le Thunderbolt 3, et sa rétrocompatibilité avec l’USB 3.2, ses spécifications minimales sont les suivantes : 20 Gbps, un écran 4K, une alimentation de 7,5 W, mais il peut aussi gérer jusqu’à 40 Gbps, deux écrans et une alimentation de 100 W.  

Il peut fournir une alimentation d’au moins 15 W aux accessoires et prendre en charge deux écrans 4K ou un seul écran 8K. 

Sinon, il existe aussi d’autres variantes :

  • L’USB4 Gen 2×2 avec une bande passante de 20Gbps.  
  • L’USB4 Gen 3×2 qui atteint 40Gbps, le plus rapide à ce jour. 

L’USB4 peut allouer dynamiquement et intelligemment la bande passante à la vidéo et aux données en fonction des besoins réels.

Nouvelle norme, nouveau logo:

USB 1.1

USB 1.1, développé en 1995, est le standard USB d’origine. Il gère deux vitesses de données : 12 Mbits/s pour les équipements comme les unités disques, qui nécessitent un débit élevé, et 1,5 Mbits/s pour les équipements comme les manettes de jeu, qui utilisent une bande passante bien moindre.

USB 2.0

En 2002, une nouvelle spécification, l’USB 2.0, ou USB 2.0 Hi-Speed, a été largement adoptée par les fabricants. Cette version est compatible à la fois en amont et en aval avec USB 1.1. Elle accélère le débit de la connexion entre le périphérique et le PC de 12 à 480 Mbits/s, soit un débit 40 fois plus rapide !

L’accroissement de bande passante améliore l’emploi de périphériques externes nécessitant des vitesses de transfert élevées, tels que les graveurs de CD/DVD, scanners, appareils photo numériques, équipements vidéo, etc. L’USB 2.0 prend en charge des applications exigeantes, comme la publication sue le Web, dans laquelle plusieurs appareils à haut débit fonctionnent en même temps. L’USB 2.0 est également pris en charge par Windows XP via une mise à jour.

USB 3.0

Le standard USB le plus récent, l’USB 3.0 ou « USB SuperSpeed » apporte de grandes améliorations par rapport à l’USB 2.0. L’USB 3.0 promet un débit allant jusqu’à 4,8 Gbits/s, presque dix fois celui de l’USB 2.0. L’USB 3.0 ajoute un bus physique fonctionnant en parallèle avec le bus 2.0 existant.

  • Connecteurs
    Il comprend la fiche USB plate de type A, mais à l’intérieur, il existe un autre jeu de connecteurs, et le bord de la fiche est bleu au lieu de blanc. La fiche type B a un aspect très différent avec un autre jeu de connecteurs.
  • Câble
    Le câble USB 3.0 comprend neuf conducteurs, soit quatre de plus que le câble USB 2.0 qui en possède une paire pour les données et une paire pour l’alimentation électrique. L’USB 3.0 se sert de deux paires supplémentaires pour les données, pour un total de huit conducteurs, plus un de masse. Ces paires supplémentaires permettent à l’USB 3.0 de prendre en charge le transfert asynchrone bidirectionnel de données en full-duplex au lieu de la méthode d’interrogation de l’USB 2.0 en half-duplex.
  • Plus de puissance
    L’USB 3.0 fournit 50% plus de puissance que l’USB 2.0 (150 mA contre 100 mA) aux dispositifs non configurés et jusqu’à 80% plus de puissance (900 mA contre 500 mA) aux appareils configurés. L’USB 3.0 gère aussi mieux l’énergie que l’USB 2.0 qui maintient l’alimentation quand le câble n’est pas utilisé.

Les caractéristiques USB définissent la vitesse et le fonctionnement du câble.

USB 2.0

C’est en 2002 que l’USB 2.0 (High-Speed) a été commercialisé. Cette version est rétrocompatible avec l’USB 1.1. Elle augmente la vitesse de connexion entre le périphérique et le PC de 12 Mo/s à 480 Mo/s, soit 40 fois supérieure à l’USB 1.1. Le nom du port comprend la mention « Enhanced », « Enhanced Host » ou « Universal Host ».

USB 3.1 Gen 1 (aussi appelé USB 3.0)

L’USB 3.0 (SuperSpeed) (2008) améliore les performances de l’USB 2.0. L’USB 3.0 peut atteindre une vitesse de 4,8 Go/s, soit 10 fois plus rapide que l’USB 2.0. L’USB 3.0 ajoute un bus physique actif en parallèle au bus 2.0 existant. L’USB 3.0 est rétrocompatible avec l’USB 2.0. Le nom du port indique USB 3.0.

USB 3.1 Gen 2

L’USB 3.1 (SuperSpeed+) offre une bande passante de 10 Go/s, un débit effectif de 3,4 Go/s et une alimentation de 900 mA en aval. A la différence de l’USB 2.0, la version 3.1 Gen 2 fonctionne en full duplex. La norme USB 3.1 Gen 2 est rétrocompatible avec les modèles 3.1 Gen 1 (ou 3.0) et USB 2.0.

Quels sont les différents types de raccords USB ?

USB Type A

  • On les trouve généralement côté hôte (PC, clavier, serveur, hub, câbles et petits périphériques)
  • Forme rectangulaire avec quatre broches en ligne
  • Raccord bleu facilement reconnaissable

USB Type B

  • Généralement utilisé sur les périphériques et autres appareils disposant d’un câble d’alimentation, comme les imprimantes
  • Format carré avec coins arrondis d’un côté
  • Quatre broches, une dans chaque coin.

USB Mini Type B

  • Forme rectangulaire avec cinq broches
  • Généralement utilisé sur les appareils photo et autres petits dispositifs

Micro Type-B avec câble 2.0

  • Appareils mobiles et portables
  • Forme rectangulaire avec cinq broches de 500 mA

USB Micro Type-B avec câble 3.1 Gen 1 (ou 3.0)

  • Appareils mobiles et portables
  • Alimentation de 900 mA

USB Type C

  • Compatible avec l’hôte et le périphérique. Les raccords sont les mêmes des deux côtés. Forme oblongue.
  • Compatible avec les modes alternés pour le transfert de données et autres à travers le raccord et le câble
  • Peut être fixé à un n’importe quel port. Le fonctionnement est défini par le matériel.
  • Prise réversible (haut ou bas)
  • Port réversible avec 24 broches. Fixation rapide et facile.
  • Débit jusqu’à 40 Go/s sur quatre voies de 10 Go/s chacune
  • Peut fournir ou consommer du courant et produire jusqu’à 100 W
  • Résiste à 10 000 cycles.
  • Rétrocompatible
Cartographie des connecteurs USB

NTP et Chrony en conteneur

NTP et Chrony en conteneur

Publié le par Guy VANDENBERGHE

La mise en conteneur d’environnement est classique de nos jours et est indiscutablement nécessaire.

Certains, se sont maintes fois heurtés à un mur sous formes d’insultes systèmes en installant le service de temps sous Linux; et notamment sous CentOS/RedHat.

Poursuivre la lecture « NTP et Chrony en conteneur »
Les influences directes de la version Red Hat Entreprise Linux (RHEL) 8.0

Les influences directes de la version Red Hat Entreprise Linux (RHEL) 8.0

Publié le par Guy VANDENBERGHE

Lors du dernier web-séminaire de RedHat, nous avons la confirmation du détail du cycle de vie des versions antérieures et actuelles de Linux RedHat. En résumé, et nous le savions déjà, la fin de support des versions antérieures à 8.0 depuis aout.


Version
General availability
Full support ends
Maintenance Support 1 ends
Maintenance Support 2 ends
9A venirA venir
807/05/20198.0 (se termine le 31/12/2021)
8.1 (se termine le 30 novembre 2021)
8.2 (se termine le 30 avril 2022)
8,4 (se termine le 30 mai 2023)		N/A 8.0 (se termine le 31/12/2021)
8.1 (se termine le 30 novembre 2021)
8.2 (se termine le 30 avril 2022)
8,4 (se termine le 30 mai 2023)
710/06/201406/08/201906/08/202030/06/2024
7 (System Z)10/04/201806/08/201906/08/202031/08/2021
7 (Power9)13/11/201706/08/201906/08/202031/08/2021
7 (ARM)13/11/201706/08/201906/08/202030/11/2020
610/11/202010/05/201630/11/202030/11/2020
515/063/200731/01/201431/03/201730/11/2020
Cycle de vie RedHat Entreprise Linux

Rappel sur les matrices de fin de vie

RedHat nous confirme les fins de supports niveau 2 pour ces mêmes versions pour mai 2021 concernant les architectures non Intel/AMD; et enfin juin 2024 pour Intel/ADM.

RedHat vend évidemment sa solution Ansible pour pouvoir effectuer les migrations rapidement des systèmes anciens ou en utilisant son outil facilitant cette dernière: LEAPP. LEAPP est bien prêt pour passer en version 8.0 les anciennes versions de RedHat EL.

Concernant le cursus de certification RedHat 8.0, il reste inchangé…

Guide de planification RHEL 8

Cycle de vie RHEL

DescriptionSupport completSupport
de
maintenance 1 (RHEL 6, & 7)12		Support
de maintenance (RHEL 8)13

Support
de
maintenance 2 (RHEL 6, & 7)12		Phase de durée de vie prolongée7Module complémentaire ELS (Extended Life Cycle Support)8Module complémentaire EUS (Extended Update Support)8
Accès au contenu précédemment publié via le portail client Red HatOuiOuiOuiOuiOuiOui
Auto-assistance via le portail client Red HatOuiOuiOuiOuiOuiOui
Soutien technique1IllimitéIllimitéIllimitéLimité9IllimitéIllimité
Errata de sécurité asynchrone (RHSA)10 11OuiOuiOuiNonOui8Oui8
Errata de correction de bogue asynchrone (RHBA)2 11OuiOuiOuiNonOuiOui
Versions mineuresOuiOuiOuiNonNonNon
Activation matérielle actualisée3IndigèneLimité4 IndigèneUtilisation de la virtualisationUtilisation de la virtualisationUtilisation de la virtualisationUtilisation de la virtualisation
Améliorations logicielles5Oui6NonNonNonNonNon
Images d’installation mises à jourOuiOuiOuiNonNonNon
  1. L’accès au support technique dépend du niveau de service inclus dans votre abonnement Red Hat Enterprise Linux.
  2. Red Hat peut choisir, à titre de mesure temporaire, de résoudre ces problèmes catastrophiques ayant un impact significatif sur l’activité des clients avec un correctif pendant la création de l’avis d’errata de correction de bogues (RHBA).
  3. L’activation matérielle native est fournie par le rétroportage des pilotes matériels, etc., vers la version appropriée de Red Hat Enterprise Linux. L’activation matérielle à l’aide de la virtualisation est obtenue en exécutant une version antérieure de Red Hat Enterprise Linux en tant qu’invité virtuel sur une version plus récente de Red Hat Enterprise Linux. Consultez la description de la virtualisation ci-dessous pour plus de détails. REMARQUE : la certification matérielle (y compris les limites matérielles associées) s’applique à la version de Red Hat Enterprise Linux utilisée comme hôte.
  4. L’activation matérielle native dans la phase 1 du support de maintenance est limitée à l’activation matérielle qui ne nécessite pas de modifications logicielles substantielles. Consultez la description du support de maintenance 1 ci-dessous pour plus de détails.
  5. Les améliorations logicielles sont des ajouts de nouvelles fonctionnalités au-delà de la correction de défauts ou de l’activation de fonctionnalités existantes sur une nouvelle génération de matériel.
  6. Les versions majeures sont le principal vecteur d’améliorations logicielles importantes, bien que des améliorations logicielles à faible impact puissent également être fournies dans les versions mineures.
  7. Voir la description de la phase de durée de vie prolongée ci-dessous.
  8. La prise en charge étendue des mises à jour (EUS) et la prise en charge du cycle de vie étendu (ELS) sont disponibles en tant que modules complémentaires facultatifs. Voir les descriptions EUS et ELS ci-dessous.
  9. Pour les installations existantes uniquement. Voir les détails ci-dessous pour d’autres limitations.
  10. Consultez la page Classification de la gravité des problèmes pour obtenir des classifications de gravité de sécurité.
  11. Tous les errata sont fournis à la discrétion de Red Hat.
  12. S’applique aux versions majeures 6 et 7 de RHEL ; ne s’applique pas à RHEL 8.
  13. Le support de maintenance pour RHEL 8 est l’équivalent du support de maintenance 2 pour toute la phase de maintenance.

Plus de détails: ici

Construisez votre cluster de virtualisation AMD au format Mini-ITX

Publié le par Guy VANDENBERGHE

Ce n’est pas nouveau, mais beaucoup d’ingénieur en informatique ou développeur cherche perpétuellement la bonne configuration pour construire son serveur pour un lab ou plus.

La problématique est que l’encombre d’un serveur au format tour ou rack est avéré.
Si l’on cherche à se retrouver seul chez soi avec son serveur, au lieu de la personne avec qui nous vivons, c’est la bonne démarche !

Après une configuration à base de Shuttle et d’intel I7-8700 créée en 2017, je vous propose un nouveau challenge:
Un VRAI serveur AMD en format Mini-ITX.
Vous allez me rétorquer, “Pffffuu, facile….”. Mais là je vous parle d’un VRAI serveur avec une carte serveur sans l’équipement de carte vidéo.
“Aahhhh ?”. Eh bien oui ! 🙂

Après sa fameuse carte mère X470D4U au format ATX, ASRock Rack, la filiale d’ASRock, a publié courant janvier une nouvelle version de cette fameuse carte mère. Plus rapide et pourvu du chipset X570 devenu un standard pour les cartes mères à base de processeurs AMD.
Mais cela n’est pas tout. Cette carte est au format Mini-ITX.

Cette nouvelle au final avec les problématiques de COVID, à pris beaucoup…beaucoup de retard sur la production venant de Chine.
Les premières livraisons sont arrivées au compte-gouttes courant Juin dans certains pays en Europe, et Juillet/Aout en France.

Pour couronner le tout, certains composants comme les alimentations se sont fait attendre également. Autant dire que les approvisionnements sont tendues à cause de ces épisodes d’épidémies et partout dans le monde.

Voici donc un exemple de configuration que je vous propose en versus Mini-ITX.

Le cahier des charges

Un serveur avec un processeur AMD et dépassant 10 cœurs.
Pas de blocage d’évolution de la RAM à 32 ou 64GB
La possibilité de mettre plus de deux disque de stockage
Un budget raisonnable pour ce genre de configuration

La carte mère

Cette X570D4I-2T est une bombe, et propose tous de sa petite sœur la X470. Attention cependant, cette carte mère est le premier centre de coût après le processeur. Comptez plus de 300€.:

X570D4I-2T

1 socket AMD AM4 pour processeur AMD Ryzen 3000
4 Slots mémoire DDR4 2133/2400/2666/2933 MHz  Dual-Channel (128 Go max.)
8 SATA 6Gb/s (par  OCulink) avec le support RAID 0/1/10
1 x M.2 PCIe 4.0 x4 / SATA 6 Gbps
1 port PCI-Express 4.0 16x
2 LAN 10 GbE Intel X550-AT2
1 port LAN mangement IPMI Realtek RTL8211E
1 Contrôleur Aspeed AST2500

Et oui, cette carte serveur possède sa carte graphique. Inutile de monopoliser un port PCI pour une carte graphique, car comme vous le savez, seul les AMD de la série Vega intègre le processeur graphique. Un sacré gain de place, de consommation. Et il nous reste un port PCI utilisable pour soit une carte graphique dédié pour du calcul GPU ou autre.

Il s’agit bien ici d’une carte mère serveur, car il y a la présence d’un BMC, car comme on peut le voir, un troisième port Ethernet est disponible. Il s’agit d’un port de management qui permet, comme beaucoup de carte mère serveur de prendre la main à distance (RSA, iLO, et cie). Et surtout de démarrer la carte mère et ses périphériques.

Add’On

Pour ajouter un petit plus (qui existait dans la configuration Shuttle), une carte Wifi en port PCI avec un chipset Intel, et … une puce bluetooth. De quoi être complet, non !?!

Le processeur

Deuxième centre de coût.

Mon objectif était de monté en puissance après ma configuration Shuttle à base d’Intel I7-8700.
Ainsi, de 12 Thread sur 6 Cœurs, j’ai fais le choix rapport/prix de passer à 12 Cœurs 24 Thread, soit doubler le compute.
Les EPYC étant trop cher, j’ai sélectionner le Ryzen 9 3900X 3800MHz.

La RAM

Troisième centre de coût. Le choix important et doit-être en compatibilité avec les recommandations constructeurs.
Deux barettes Crucial CT2K32G4SFD8266 propose ainsi 64 GB de RAM. Ainsi deux emplacements reste libre pour monter à 128GB la capacité maximale mémoire.

L’alimentation

Pour faire fonctionner cela, une bonne alimentation au format TFX, car au format Mini-ITX, c’est le format implicite.
J’ai choisi un bon rendement pour jouer la carte budget électrique et éviter des pertes dû au mauvais rendement. La TFX Power 2 300W Gold de chez BeQuiet me semblait une évidence pour rester dans un budget convenable. 300W, cela parait faible, mais cela est très suffisant, a moins d’utiliser des disques dur mécanique)

Le boitier

C’est très secondaire, mais au final, non. Il va accueillir tous l’ensemble et doit-être d’encombrement minimal. J’ai choisi le boitier BU12 de Chieftec, bien sur sans l’alimentation. Le boitier est de bonne facture pour un prix très raisonnable. Si on cherche à héberger beaucoup de disque dur il faudra changer pour un boitier un peu plus haut. Pour mon besoin, je suis parti pour deux unités à fortes capacités. (Nous en parlerons plus tard)

  • BU12 / Vue de derriere
  • BU12 / Vue de face

Ce boitier possède des emplacements 2,5″, 3,5″ et un pseudo 5 1/4″. Avec des berceaux d’adaptations à prix modique, il est donc possible de mettre en deux à quatre disque 2,5″.

Le Refroidissement

C’est un choix important pour éviter d’avoir trop de bruit et avoir une ventilation efficace. Par rapport à la hauteur du boitier, le choix est très dirigé.

C7 Cu

ATTENTION, ASRock impose un montage des ventilateurs au format LGA15xx, alors que le processeur est au format M2.

Certains constructeur de système de refroidissement propose des ventilateurs, ou ventirad pour les puristes, adaptables pour de nombreux format et cela peut import le socket du processeur.

C’est le cas du C7 de chez Cryorig, qui possède un look très sympa, sans cloisonnement qui provoque lorsque le ventilateur se voile, des bruits de frottement. La hauteur de ce ventirad nous laisse encore un petit de mou.

Le stockage

Comme je vous l’ai dit, j’ai choisi deux disques SATA SSD à fortes capacités. Selon son besoin, ils pourront être montés en RAID1 ou non en fonction. J’ai choisi un volume par disque Segate Baracuda 120 SSD. Ce choix est le meilleur compromis/prix avec IO supérieurs à Western Digital ou Crucial par exemple.

Enfin pour éviter de monopoliser l’un de ces pour le système de virtualisation, un disque M2 de 250 GB WD blue que je possédais. Très largement suffisant.

L’intégration

La carte mère s’intègre sans complication sur le boitier.
C’est côté alimentation que l’intégration doit-être soignée, car la place disponible est faible. Notamment près du ventilateur du boitier.
Une attention toute particulière est aussi sur le raccordement. Fourni avec l’alimentation TFX, BeQuiet! propose un adaptateur ATX vers ATX 12V. Il ne faut pas non plus oublier l’alimentation 12v du CPU, sinon la carte mère s’allumera de facto, mais sans CPU rien ne fonctionnera et sans aucune alerte sur la partie BMC.

Comme on peut le voir sur les illustrations, le raccordement des unités de disques de stockage SATA s’effectue par un câble OnLink. Attention ce câble est assez fin et peu, vite s’abimer. Via ce câble, quatre connexions SATA sont disponibles.

ATTENTION également, ASRock recommande d’utiliser les câbles d’alimentations venant de l’alimentation à découpage TFX et non de la carte mère pour éviter des dégradations de la carte mère. Tous dépends de l’alimentation utilisée ATX ou ATX12V.

Installation de l’hyperviseur

Aspeed AST2500 oblige, il faudra se contenter d’un port vidéo VGA. Mais cela n’est pas forcément utile, car nous disposons de notre BMC. Et là tout se fait à distance !
Précaution, tout de même, utilisez la version Java de la prise à distance. Cela vous permettra d’avoir plus d’options à disponibilité.

Cela parait simple, mais il y a toujours des mauvaises estimations de compatibilité avec un hyperviseur ou un autre.

ESXi 7

Avant l’achat, il est évident que des vérifications de compatibilités ont été réalisé notamment avec VMware. L’objectif était également de pouvoir installer un ESXi 7. Comme vous le savez, les drivers de l’ESXi 7 ont été complètement ré-écrit, ce qui ne peut pas forcément arranger les choses.

Force de dire que l’installation passe comme une lettre à la poste. Même la carte WIFI grace à son chipset Intel, est reconnue.

J’ai poussé le bouchon un peu plus loin en virtualisant un hyperviseur Linux, Proxmox. Bien évidement il est important d’activer le partage de l’hyper threading et affecter un nombre suffisant de CPU dédié à cette VM.

Ainsi nous disposons, d’un hyperviseur ESXi, et d’un hyperviseur Proxmox afin de virtualiser des containers LXC/LXD.

Chacun y trouvera son compte.

Proxmox 6.2.x

Installer un Proxmox au lieu d’un ESXi 7, ne pose aucun soucis de facto non plus. Noyau Linux oblige, c’est du gâteau !
Là aussi, tout est reconnu. Le petit plus, par rapport à une config Shuttle Intel, aucun besoin de toucher au configuration IOMMU pour éviter des instabilités, car ici TOUT est disponible et fonctionne sans rien faire.

Ainsi le partage en Pass-Thru des add’on PCI ou USB pour une VM, est fonctionnel.

Deux exemples de VM avec leur port PCI ou USB en mode Pass-Thru.

Installer un ESXi en mode Nested ne pose non plus aucun soucis. Il suffit de réserver un certains nombre de ressources CPU en mode CPU-Host par exemple pour profiter d’un hyperviseur VMware sous Proxmox.

Pour rappel sous linux, il est impératif de paramétrer les modules modprobe en fonction du fondeur du cpu:

Activation du support nested

Il faut commencer par contrôler si le paramètre nested est activé ou pas dans le processeur :

cat /sys/module/kvm_intel/parameters/nested
ou
cat /sys/module/kvm_amd/parameters/nested
# N ou 0

S’il est à N ou à 0, c’est qu’il n’est pas activé.

Pour activer l’activer, il suffit de positionner la variable à 1 à l’aide de la commande; Remplacez xxxx par le fondeur du cpu:

echo "options kvm-xxxx nested=1" > /etc/modprobe.d/kvm-xxxx.conf

Il faut ensuite redémarrer le module kvm. Pour cela il faut que toutes les vms soient arrêtée sur le serveur.

modprobe -r kvm-intel ou modprobe kvm-intel

On vérifie :

cat /sys/module/kvm_intel/parameters/nested
# Y ou 1

Côté hyperviseur, on est prêt !

Coté guest-OS, plus particulièrement l’hyperviseur virtualisé, il est impératif de paramétrer au niveau de l’enveloppe du guest le type de cpu à host.

Puis également, même si ce n’est pas forcément impératif, ajouter le paramètre : args: -enable-kvm dans le fichier de conf de la vm (Par exemple : /etc/pve/qemu-server/106.conf

C’est tout ! Vous voilà prêt pour virtualiser un hyperviseur…Heu mais que dis-je ? 🙂

La boucle est bouclée !

Le Cloud Computing, pour qui ?

Publié le par Guy VANDENBERGHE

Qu’est-ce que le Cloud ?

Le Cloud ou infrastructures en nuage donne un accès partagé à des données ainsi qu’à des programmes qui sont stockés sur un ensemble de serveurs informatiques distants et souvent répliqués sur divers sites géographiques dans différentes régions d’un même pays et/ou à l’internationale.

Poursuivre la lecture « Le Cloud Computing, pour qui ? »

Virtualiser sous iOS ?

Publié le par Guy VANDENBERGHE

Cela peut paraitre étonnant, mais un projet assez Fun se fait connaitre via les réseaux sociaux, en environnement de virtualisation (certes sommaire), pour virtualiser … sous votre iOS préféré. Un iPad, iPhone.

Oui, vous ne rêvez pas…Sur ces mobiles ou tablettes nous voyons développer des tâches de choses assez farfelus et innovateurs. Mais là…joker !

Rien de très spécifique, puisqu’il s’agit d’embarquer un QEMU et Spice.
C’est amusant, de voir un Windows sous un iOS, certes. Mais finalement il y a t’il un intérêt ?

Si vous y trouver un intéret dans un développement le projet GitHub ici.

Portainer…Plus qu’une WEBUI

Publié le par Guy VANDENBERGHE

Que vous soyez développeur ou que vous manipuliez du Docker voici un outil intéressant qui dépasse les 200 000 téléchargements à ce jour.
Portainer.io est mise à disposition en version OpenSource est une boite à outils permettant la gestion de vos conteneurs Docker et ainsi de créer, gérer et réaliser la maintenance via une interface WebUI unique.
Dans sa dernière version, Portanier supporte IPV6 et est actuellement en version 2.4.6 et s’interface avec Kubernetes.

Vous pouvez tester cet outil en démo sur le site de Portainer.

Portainer oui mais pour qui ?

Portainer est compatible avec les versions suivantes de Docker : Docker > 1.9
Cet outil peut être géré sur Docker Swarm, Docker Kubernetes, Docker sur Azur.

Architectures compatibles:

Portainer peut être déployé sur les plates-formes suivantes :

  • Linux plateforme amd64
  • Linux plateforme Arm
  • Linux plateforme arm64
  • Linux plateforme ppc64le
  • Linux plateforme s390x
  • Windows plateforme amd64
  • Darwin plateforme amd64 (MacOS)

Installation de Portainer à l’aide de Docker

L’ensemble du projet est disponible sur le Github du projet, mais n’est pas nécessaire.

Portainer est composé de deux éléments, le Portainer Server et le Portainer Agent. Les deux éléments fonctionnent comme des conteneurs pod Docker sur un moteur Docker ou dans un cluster Swarm, ou encore un Cluster K8s. Lié à Docker, il existe de nombreux scénarios de déploiement possibles. Le scénario présenté est celui le plus couramment utilisé. (si votre configuration n’est pas répertoriée, voir portainer.readthedocs.io pour des options supplémentaires).

Il faut notez que le mode de déploiement recommandé de l’outil est d’utiliser l’agent Portainer.
Vous devez donc déployer Portainer Server sur un cluster swarm ou autonome, soit LINUX Docker host/single node ou Windows Docker Host fonctionnant en mode “Linux containers”).

Utilisez les commandes suivantes de Docker pour déployer le Portainer Server ; notez que l’agent n’est pas nécessaire sur les hôtes autonomes, mais qu’il offre des fonctionnalités supplémentaires s’il est utilisé (voir le scénario du portainer et de l’agent ci-dessous):

$ docker volume create portainer_data
$ docker run -d -p 8000:8000 -p 9000:9000 --name=portainer --restart=always -v /var/run/docker.sock:/var/run/docker.sock -v portainer_data:/data portainer/portainer

Il vous suffit ensuite, d’accéder au port 9000 du moteur Docker où fonctionne portainer à l’aide de votre navigateur préféré.

Remarques

Le port 9000 est le port général utilisé par Portainer pour l’accès à l’interface utilisateur. Le port 8000 est utilisé exclusivement par l’agent EDGE pour la fonction de tunnel inverse. Si vous ne prévoyez pas d’utiliser l’agent edge, vous n’avez pas besoin d’exposer le port 8000 vers votre réseau.

L’option -v /var/run/docker.sock:/var/run/docker.sock ne peut être utilisée que dans les environnements Linux.
Vous pouvez déployer Portainer Server sur un Host Docker WINDOWS autonome (en exécutant des conteneurs Windows) mais attention il doit-être de version build Windows 1803 ou plus récent.

$ docker volume create portainer_data
$ docker run -d -p 8000:8000 -p 9000:9000 --name portainer --restart always -v \.\pipe\docker_engine:\.\pipe\docker_engine -v portainer_data:C:\data portainer/portainer

Il vous suffit ensuite, d’accéder au port 9000 du moteur Docker où fonctionne Portainer à l’aide de votre navigateur.

Remarque: l’option -v \.\pipe\docker_engine:\\\.\ peut être utilisée dans les environnements Windows 1803+ Container uniquement.
Gérer un cluster LINUX Swarm avec Portainer Server et le Portainer Agent.

Pour déployer Portainer et un Portainer Agent pour gérer un cluster Swarm, vous pouvez directement déployer Portainer en tant que service dans votre cluster Docker. Il est à noter que cette méthode déploiera automatiquement une seule instance du serveur Portainer et l’agent Portainer comme un service global sur chaque nœud de votre cluster.

$ curl -L https://downloads.portainer.io/portainer-agent-stack.yml -o portainer-agent-stack.yml
$ docker stack deploy --compose-file=portainer-agent-stack.yml portainer

Il vous suffit ensuite et comme à l’habitude d’accéder au port 9000 du moteur Docker où fonctionne Portainer à l’aide de votre navigateur.

Gérer un cluster WINDOWS Swarm avec Portainer Server et l’agent Portainer

Pour déployer Portainer et l’agent Portainer pour gérer un cluster Swarm sous Windows 2016 (1803) ou Windows 2019 (10903), vous pouvez déployer Portainer directement en tant que service dans votre cluster Docker. Notez que cette méthode déploiera automatiquement une seule instance du serveur Portainer, et déploiera l’agent Portainer en tant que service global sur chaque nœud de votre cluster. A peu près à l’identique que sous Linux.

$ curl https://downloads.portainer.io/portainer_windows_stack.yml -o portainer_windows_stack.yml
$ docker stack deploy --compose-file=portainer_windows_stack.yml portainer

Il vous suffit d’accéder ensuite au port 9000 du moteur Docker où fonctionne portainer à l’aide de votre navigateur.

Il est important de noter qu’il faut s’assurer que les ports réseaux requis sont exposés sur les hôtes Docker dans votre cluster AVANT de déployer la pile (et redémarrez votre hôte après avoir ajouté les règles).

netsh advfirewall firewall add rule name="cluster_management" dir=in action=allow protocol=TCP localport=2377
netsh advfirewall firewall add rule name="node_communication_tcp" dir=in action=allow protocol=TCP localport=7946
netsh advfirewall firewall add rule name="node_communication_udp" dir=in action=allow protocol=UDP localport=7946
netsh advfirewall firewall add rule name="overlay_network" dir=in action=allow protocol=UDP localport=4789
netsh advfirewall firewall add rule name="swarm_dns_tcp" dir=in action=allow protocol=TCP localport=53
netsh advfirewall firewall add rule name="swarm_dns_udp" dir=in action=allow protocol=UDP localport=53

DÉPLOIEMENT D’AGENTS DE TRANSPORT SEUL

Pour déployez Portainer Agent sur un cluster LINUX Swarm distant en tant que service d’essaimage, exécutez cette commande sur un nœud de gestion dans le cluster distant.

$ docker service create --name portainer_agent --network portainer_agent_network --publish mode=host,target=9001,published=9001 -e AGENT_CLUSTER_ADDR=tasks. portainer_agent --mode global --mount type=bind,src=//var/run/docker.sock,dst=/var/run/docker.sock --mount type=bind,src=//var/lib/docker/volumes,dst=/var/lib/docker/volumes --mount type=bind,src=/,dst=/host portainer/agent

Pour déployer Portainer Agent sur un Host Docker autonome LINUX distant (sans cluster), exécutez cette commande

$ docker run -d -p 9001:9001 --name portainer_agent --restart=always -v /var/run/docker.sock:/var/run/docker.sock -v /var/lib/docker/volumes:/var/lib/docker/volumes portainer/agent

Pour déployer Portainer Agent sur un serveur autonome Windows Server 2016 (ou ultérieur ) host Docker.

$ docker run -d -p 9001:9001 --name portainer_agent --restart=always -v \.\pipe\docker_engine:\\.\pipe\docker_engine portainer/agent

Pour déployer l’agent Portainer sur un serveur docker SINGLE Windows Server 2016 ( ou ultérieur) fonctionnant comme un nœud Swarm (pour les déploiements multi-noeuds, veuillez consulter les configurations avancées)

$ docker run -d -p 9001:9001 --name portainer_agent --restart=always -v \.\pipe\docker_engine:\.\pipe\docker_engine -e AGENT_CLUSTER_ADDR=tasks.agent portainer/agent

Note : les options ci-dessus ne font que déployer l’agent, vous devez vous connecter à l’agent à partir d’une instance existante de Portainer Server.
Pour d’autres scénarios de déploiement, et pour connaître les conseils et les techniques de déploiement avancées, consultez la documentation complète de Portainer.

Portainer est libre d’utilisation

… mais le support ne l’est pas, voici les modèles de supports facturables: