Blog des réseaux LAN WAN WIFI MPLS SDN Communications Unifiées Téléphonie Firewall VPN Virtualisation de Alain FAURE [audit informatique et audit reseau]
Vous vous rappelez sans doute de la comptine pour enfants « trempez la dans l’eau, trempez la dans l’huile … »à propos de la souris. Sans doute vous connaissez le watercooling technique permettant de refroidir les processeur qui sont les plus performants. C’est le cas de certaines cartes graphiques comme la Sapphire Vega 64 de Radéon.
Eh bien la firme Française Modulo C dont j’avais déjà parlé ici pour ces datacenter embarqués [voir: site moduloC] propose encore une innovation, cette fois c’est la technique de refroidissement du datacenter à l’huile. Il faut reconnaître que cette société est intéressante puisque elle propose régulièrement des nouveautés technologiques.
Le gros avantage pour nous autre geek : Beaucoup moins de bruit ! Eh oui comme la climatisation devient inutile, on a plus besoin des ventilateurs dans les équipements actifs. Vous imaginez un datacenter silencieux ?!
Comme autres avantages cette solution apporte une protection contre l’humidité et la poussière. La poussière est probablement une des causes de panne les plus courantes sur les équipements statiques (outre le câblage). Avec la poussière (surtout en provenance de la pollution), qui s’accumule sur des petits composants, ils chauffent et peuvent claquer.
La chaleur collectée par l’huile peut alors être réutilisée pour d’autres applications (dans une climatisation classique, cette chaleur est rejetée dans l’atmosphère), comme le chauffage des bureaux ou même en électricité.
Cette technologie s’appelle DTM pour Dynamic Thermal Management .
L’organisation résultante peut aussi être plus facile pour réaliser de l’audit informatique, car les racks et les équipements sont mieux organisés.
Si vous voulez en savoir plus, vous pouvez suivre ce lien : [ Refroidissement à Bain d'Huile DTM Datacenter moduloC ]
D’ailleurs voici une vidéo de ce système installé chez HPE à Genève, je vous avais fait quelques posts lors du HPETechDay sur leur centre de recherche au milieu de la nature et des abeilles :
Pour cette deuxième partie sur l’infrastructure événementielle mise en place pour The Ryder Cup par HPE, nous allons voir le périmètre nécessaire à la couverture de l’événement et à la gestion du quotidien des sportifs et des visiteurs sur The Ryder Cup.
Quelques chiffres :
objectifs plus de 270000 spectateurs en une semaine
env. 7000 personnes travaillant sur le site
env. 900 média accrédités
env. 150 téléphones IP
Et en terme d’infrastructure événementielle informatique, pour la partie sans-fil :
Aruba external WiFi AP : 386
Aruba internal WiFi AP : 361
Wireless Controler 7240XW : 6
Meridian bluetooth Beacon : 455
Meridian bluetooth Asset tag : 200
Sous une plateforme destinée au public, un AP WiFi.
Mais au-delà de l’aspect hardware, il y a l’exploitation. En effet, l’informatique événementielle demande d’être à 100 % tous les jours. Pas de droit à l’erreur, on imagine pas une coupure de diffusion de 15 secondes quand le meilleur joueur du monde va pousser la petite balle dans le trou.
L’installation doit être rapide, le démontage aussi d’ailleurs. Tout est pré-configuré. Tout est repéré et marqué. En tout plus de 50 personnes sont en charge de l’informatique et participent au déploiement. Le déploiement c’est l’installation des racks 42U pour les serveurs. Mais aussi le l’audit WiFi pour le positionnement des APs WiFi, L’intégration des switchs et des kilomètres de fibre optique.
La maintenance se fait en mode remplacement. Il n’est pas possible d’essayer de dépanner un équipement en recherchant la panne. S’il y a un problème, l’équipement est purement et simplement remplacé par un autre pré-configuré situé non loin dans une plate-forme de stockage.
Il est d’autant plus important d’assurer la redondance maximale des liaisons et des équipements en cas de panne, histoire de prendre le relais pendant la panne.
Une équipe dans le NOC veille sur tous les équipements, L’important est d’avoir une vue sur le maillage WiFi,
et sur l’état des switchs Ethernet à tout instant.
Voir l’effort nécessaire pour gérer l’installation, l’exploitation et la maintenance d’un événement est une expérience enrichissante. Chaque détail doit être pensé et chaque problème anticipé. C’est vraiment une expérience qui doit être vécu pour trouver des idées au quotidien sur un système plus statique.
Accessoirement, vous pourrez trouver mon site qui propose de l’audit WiFi, ici: audit WiFi.
Il y a un type d’infrastructure informatique dont on parle peu, mais qui est vraiment très intéressant en matière de recherche d’efficacité: l’informatique événementielle. HPE étant Fournisseur Officiel de The 2018 Ryder Cup, il lui est facile de monter son savoir-faire dans ce domaine et les techniques qui y sont employées. Et c’est pour cela que nous étions invités à visiter cette vitrine technologique.
The Ryder Cup est une compétition entre deux équipes de golfeurs (USA contre Europe). Cette année l’événement a lieux dans le sud de la région parisienne.
Mais tout d’abord quelques photos d’environnement comme vous commencez à en avoir l’habitude pour ce genre d’événements (cette fois tout est fait avec mon Galaxy S4, oui je sais y date un peu, mais il est fiable).
Départ en train vers les greens.
Au moins on est les bienvenus dans un autre monde, BMW, Rolex …
Vue du village avant la cérémonie d’ouverture
Premiers échauffements, premiers spectateurs
Trou de départ
Le centre des médias près du NOC (Network Operating Center) HPE, nous en parlerons un peu plus tard plus en détail.
Même les drones sont de la fête
Détail d’un green
Quelques grands noms du golf
Nos couleurs nationales, cette fois dans le bon ordre, à la cérémonie d’ouverture.
La solution HCX de VMware permet de travailler à la fois en mode cloud privé et en mode cloud public. Le principal intérêt de HCX est de présenter aux applications un environnement cloud unifié qu’il soit situé sur le cloud privé ou le cloud public. C’est aussi réalisé au moyen d’une couche sécurisée permettant une communication efficace entre sites distants. De cette façon sont augmenté les possibilités de PRA Plan de Recouvrement d’Activité en cas de sinistre par exemple.
VMware HCX permet de faciliter les migrations que se soit en terme de délais ou d’arrêt de service pour des modifications importantes.
Les principaux modules de VMware HCX :
HCX Enterprise Manager (HCX-MGR)
C’est le module central donnant un cadre pour le déploiement des services HCX
HCX WAN Interconnect Virtual Appliance (HCX-WAN-IX, CGW)
Permet la migration et des possibilité vMotion à travers les clouds privés/publics sur Internet et les liaisons privées.
HCX WAN Optimization Virtual Appliance (HCX-WAN-OPT) : Permet l’optimisation des liaisons WAN avec des techniques de gestion des données et des liaisons.
HCX Network Extension Virtual Appliance (HCX-NET-EXT, L2C, L2E)
Extension de la couche 2 OSI à 4/6 Go/secondes
Les utilisations les plus importantes de VMware HCX sont :
L’extension d’un Cloud pré-existant
Le support des applications sur différents type de Cloud
La mise en œuvre plus facile de PRA dans le Cloud
La mise en œuvre simplifiée du cloud pour un datacenter.
Vous pouvez en savoir plus sur le site VMware qui ne parle que de HCX (in english).
Workspace One est un des produits mis en valeur par Vmware pour ses 20ans.
La philosophie de VMware est de se consacrer à la prise en charge d’applications du serveur au poste de travail et c’est ce qu’il entend faire avec Workspace One.
Quand VMware parle de poste de travail il s’agit en fait de tout type de périphérique : smartphone Android, iPhone, tablette, PC desktop ou laptop en mode static ou mobile.
Workspace One permet à l’employé d’utiliser selon les besoins de ses responsabilités des applications dont le déploiement est centralisé. Bien entendu selon les politiques d’utilisation, d’authentification (avec LDAP par exemple), l’organisation peut attribuer et restreindre les possibilités d’accès à telle ou telle fonctionnalité.
L’utilisateur dispose alors d’un véritable catalogue d’applications disponibles selon des contraintes d’accès implémentées grâce à la double contrainte d’accès qu’est ‘l’accès conditionnel’ :
Validation des caractéristiques du poste client (Compliance Check)
Puis identification proprement dite
Cela va être utile pour valider techniquement la distribution d’applications vers des mobiles (Android, iPhone) selon leurs capacités techniques.
Workspace One est prévu pour supporter :
les tunnels VPN
les applications Cloud internes
les applications Web interne
les applications en mode SaaS
les applications actuelles et legacy Windows
Les utilisateurs peuvent voir leur expérience utilisateur enrichie par l’intégration des fonctionnalités suivantes :
VMware Identity Manager
VMware AirWatch Enterprise Mobility Management Suite
Horizon Air
Pour finir, j’aimerai aussi rappeler que VMware fait un effort particulier pour produire de la documentation en langue Française et cela mérite d’être soutenu.
Vous pouvez lire la FAQ en Français et la Datasheet aussi en Français.
VMware fait aussi un effort important en terme de documentation disponible au public. Donc, pour en savoir plus, je vous conseille de puiser dans ce document (in english).
Parmi les nouveautés mises en valeur pour les 20 ans de VMware, il y a son travail avec la technologie blockchain.
Pour VMware la technologie de la blockchain est utilisé comme un protocole de consensus et des contrats intelligents. La blockchain n’est pas seulement un outil pour le Bitcoin.
Concord-bft est une libraire de machine d’état générique. Cette librairie permet de prendre en compte le problème dit des ‘généraux byzantins’ (*).
Elle doit aussi permettre d’être une des pièces principales pour la réplication des bases de données réparties et est aussi une base pour mettre en œuvre les systèmes de blockchain.
(*) Le problème des généraux byzantins peut être expliqué comme cela (c’est une simplification approximative) :
Cinq généraux byzantins particulièrement retords sont plus préoccupés par leur carrière politique que par la victoire sur leurs ennemis. Pour ce faire, ils n’hésitent pas à falsifier, à inventer ou à cacher les ordres qu’ils se communiquent entre eux.
Mais pour gagner, ils doivent se mettre d’accord et donc décider à la majorité d’une stratégie commune (attaque à droite, attaque à gauche ou attaque au centre) et sans ambiguïté sur le contenu. Les informations doivent être aussi communiquées de façon fiable.
Chaque général doit communiquer sa décision aux autres généraux qui font une liste des 4 réponses reçues.
Chaque général inclus sa propre décision, puis ils envoient chacun leur liste à tous les autres qui peuvent comparer. Chaque général a maintenant les 4 listes et la sienne propre.
Chaque général peut faire une moyenne des décisions de chaque autre général et donc calculer la moyenne totale étant le consensus d’attaque majoritaire.
Le consensus final est le plus vraisemblable.
J’avais réalisé une série d’articles sur mon blog à propos de NSX de VMware (suite au salon VMworld), je vais parler maintenant de NSX-T et cela nous mènera vers l’offre VMware autour de Kubernetes dans le monde des containers et des PODs. De tout cela il a été question lors du Evolve 2018 à Paris.
NSX-T est en effet une série d’APIs permettant au logiciel de contrôler les réseaux (des couches 2 à 7 du modèle OSI). C’est à dire qu’il est possible de piloter par logiciel un switch virtuel, un routeur virtuel voire un répartiteur de charge, c’est ce dernier que nous allons voir dans cet article.
Actuellement (juin 2018) la version 2.2 qui est la version courante. On ne peut plus courante car je me base sur l’édition du 5 juin 2018 du guide d’installation. [NSX-T Installation Guide].
On notera que les besoins matériels sont de 4 CPU et 16GoRAM pour l’hyperviseur. Mais je vous laisse regarder les recommandations système dans la documentation VMware.
Dans NSX-T le répartiteur de charge s’appelle le ‘Logical Load Balancer’.
Ce répartiteur de charge a deux fonctions :
Répartir une charge applicative entre plusieurs serveurs
Assurer une haute disponibilité en cas de perte de serveurs
Les protocoles adressés par ce répartiteur de charge sont :
couche 4 OSI :TCP, UDP
couche 7 OSI :HTTP, HTTPS
Le répartiteur de charge est composé de serveurs virtuels, de groupe de serveurs et d’outils de surveillance d’état.
La surveillance d’état permet de savoir si un serveur est disponible, dans le cas contraire le répartiteur de charge peut supprimer le serveur du groupe des serveurs ‘up’. La surveillance est réalisée par un ‘moniteur actif’(HTTP, HTTPS, TCP, UDP, ICMP et ‘moniteur passif’). Les requêtes HTTP peuvent être des requêtes complexes. La réponse du serveur testé doit arriver dans un temps donné et sans erreur. Il y a un outil de surveillance d’état par groupe de serveur ‘server pool’. L’ors d’une interrogation HTTP, les paramètres possibles sont les suivants :
Méthode HTTP
Paramètre URL d’une Requête
Paramètre de la version d’une Requête
Paramètre ‘body’ d’une Requête
Paramètre ‘Code’ d’une Réponse (ce peut être les classiques 404,200 etc.)
Paramètre ‘Body’ d’une Réponse
Il existe aussi la surveillance passive ‘Passive Health Monitor’ qui se fait lors des requêtes clients. Si la réponse n’est pas dans les temps ou avec une erreur, le serveur peut être marqué comme ‘hors service’.
Le répartiteur de charge peut être organisé en deux architectures :
Topologie ‘INLINE’
Le LoadBalancer se trouve sur le trajet entre le client et le serveur, c’est une topologie classique. Le client et le serveur n’ont pas besoin de se trouver sur le même routeur Tier-1. Et il n’y a pas besoin de serveur virtuel SNAT.
Topologie ‘One-ARM’
Dans ce mode le répartiteur de charge, ne se trouve pas entre le client et le serveur. Ils peuvent être n’importe où. Ce mode nécessite un serveur SNAT ‘Source NAT’ pour forcer le trafic retour vers le client par le chemin qu’il a utilisé à l’aller.
Une petite vidéo sur le concept SNAT ‘Source NAT’
Enfin une autre fonctionnalité qui permet de décharger le serveur des calculs de sécurité: les ‘profil SSL’. Cela permet d’avoir des profils SSL indépendants des applications. C’est typiquement le cas de l’architecture en ‘SSL offloading’ HTTPS du client vers le serveur virtuel du load balancer et http du serveur virtuel vers le serveur applicatif.
C’est différent dans l’architecture ‘end-to-end SSL’ ou la communication est HTTPS de bout en bout, c’est à dire client vers serveur applicatif.
Il faut noter que ‘SSL-terminate-mode’ et ‘SSL-proxy-mode’ ne sont pas supportés sur la version limitée à l’exportation de NSX-T 2.2.
Il peut y avoir deux type de serveur virtuel dans le load balancer :
couche 4 OSI
couche 7 OSI
Un serveur virtuel sert de relais entre le flux applicatif arrivant du client et ce même flux partant vers un serveur applicatif réel. Un serveur virtuel a une adresse IP, un port et un protocole de définis. Pour un serveur de niveau 4, un range d’adresses peut être défini ce qui est utile dans le cas de protocoles dynamiques dans l’attribution des numéros de port.
Un serveur virtuel doit être associé à un groupe de serveur.
Les serveurs de couche 7 OSI sont basés sur le protocole TCP / HTTP. Mais il y a des règles définissant le comportement de la répartition de charge. Dans ce cadre seront utilisées les expressions régulières.
Cette année, VMware a organisé sa session ELVOVE 2018 à Paris dans un cadre original de l’Eléphant Paname situé entre Opéra et place Vendôme à Paris.
Voici quelques infos entendues lors de cet événement.
Sur les 2500 providers de Cloud en Europe, environ 500 se situent en Europe du sud.
On note en France un besoin de proximité, c’est à dire une préférence pour que le Datacenter soit situé sur le territoire national.
Pour ce qui concerne les applications critiques, on estime que 5 % sont dans les Datacenters des clients. Pour les applications plus classiques se sont les 2 tiers.
Les petits acteurs du Cloud présentent deux facteurs qui intéressent leurs clients :
la proximité ‘à une distance de voiture’ (mais aussi pour des besoins réglementaires)
la réactivité et accompagnement technique
Invité par VMware, Christophe LESUR présente la société Cloud Temple qui est un de ces provider de proximité.
Cloud Temple fourni de l’infrastructure Cloud pour ses clients en mode industriel.
Ses clients ont des besoins particuliers, comme la ‘nuit applicative’ c’est à dire le besoin de transport (départ de camion) à 4 heures du matin.
Le maître mot est automatisation, car la sécurité est un élément majeur de leur proposition en plus d’avoir des prix compétitifs.
Il existe donc un marché très vivant de providers de Cloud locaux qui est adressé de façon volontaire par VMware. J’aurais l’occasion de revenir sur d’autres sujets techniques évoqués lors de cette réunion par la suite.
