Reprise du message précédent :

"Ça dépend"
https://docs.microsoft.com/en-us/az [...] ound-rules

hm, j'ai peut-être mal expliqué (ou pas les yeux en face des trous ) mais je ne parle pas de connexions sortantes donc je l'ai pas l'impression que cette page concerne mon use case.
Je parle du chemin emprunté par les paquets retour/réponse (VM=>LB=>client), pas de connexions sortantes initiées par les VM.

 
va falloir être plus précis pour que je puisse te répondre car je vois pas ce que tu veux dire par un Hlb.  
C'est quoi ? un load balancer ? app load balancer ?
 

oui un load balancer (effectivement je ne sais pas d'où je sors cette terminologie "HLB" )

Hardware load balancer

 
Ok, c'est vraiment juste un LB avec 2 VMs.
 
donc le LB va porter une ip publique (externe) et un pool d'ip backends (ip interne du vnet).
 
Les 2 VMs doivent être dans le pool d'ip backends.
(https://docs.microsoft.com/fr-fr/azure/load-balancer/backend-pool-management)
 
Là, on arrive dans la magie Azure.
Azure va faire le routage automatiquement sans qu'on ai vraiment la main dessus.
Donc en toute franchise, si la route aller passe par le LB, la route retour doit passer par le LB mais aucune garantie là-dessus.
 

j'ai oublié de préciser, il n'y a pas d'IP, publique, c'est un service publié pour le réseau interne uniquement. Chaque VM a une unique IP, le LB a une IP front, ces 3 IP sont dans le même subnet (et même VNET ofc).

Au pire j'essaierai de voir pour faire un wireshark sur les VM et en voyant les IP source et destination des requêtes et des réponses j'aurai sûrement une meilleure idée de ce qu'il se passe, mais bon si je peux avoir la réponse directement je suis preneur. Le but étant d'éviter toute réponse impliquant des phénomènes magiques
En tout cas actuellement le LB n'est pas sur le chemin des paquets entre les clients et les VM et pourtant ça fonctionne.

 
nobody got fired for buying cisco  

 
Dans le cloud ?  

HLB = LB azure (basic? Standard ?) ou un truc custom ?

  C'est exactement ca

Non ça veut rien dire

 
standard

 
ok, type interne, on avance
 
Avant le wireshark, tu peux déjà regarder la config du LB.
 
go portail azure,  
ouvres le Load Balancer
envoies la config :
- Frontend IP address
- Backend pool -> quelles sont les IP dedans ?
 
tiens,

 
Autre élément qui va aider, le nsg (Network security groups) du subnet.
 
Virtual networks -> ouvres le bon -> subnets -> quel est le security group associé au subnet ?
et quelles sont les règles du nsg ?
 
 
 
 

j'ai pas accès à la console moi-même, mais j'ai regardé tout à l'heure avec un collègue et comme je disais, les frontend et backend sont les 3 dans le même subnet.
 
pour le security group il me semble que c'est à peu près open bar, mais de toute façon les security groups c'est uniquement de la gestion d'accès, pas du routage/nat, il me semble ?

https://docs.microsoft.com/fr-fr/az [...] loating-ip
Il y a un peu de magie. Lema plateforme change a la volee, l'IP source du paquet retour par celle du lb

ok je comprends, donc la VM backend verra arriver la requête avec la vraie IP source du client, lui répondra directement, et azure modifiera à la volée l'IP source de la réponse pour mettre l'IP du frontend LB

si c'est ça je comprends mieux la limitation que le LB et les backends doivent être dans le même VNET du coup, ça doit pas super passer à l'échelle ce genre de bricolage après c'est sûr c'est pratique

Au contraire, ça doit bien passer a l'échelle. C'est directement implanté comme virtual function du vswitch sur les hyperviseurs, pas besoin de faire passer le paquet dans des VM intermédiaires.
Doit y avoir un article deepdive qq part la dessus si ça t'intéresse

Je ne donne que la signification de l'acronyme hein  

 
Pour ma part je sais pas faire. Ou alors pas beaucoup, sur des décisions déjà prises: ça marche bien, tout le monde est satisfait, personne se plaint du coût, ce serait lourd et chronophage de faire une migration et tout ce que je vais gagner à intervenir, au mieux, c'est des coups.
 
Il y a quelques années je me suis pris à 1h du mat un scud de mon PDG en forme de sms. Je cite: "je viens de me faire réveiller avec la petite par cette putain d'alarme. On se voit demain matin. Les solutions pas cher on voit ce que ça donne".
 
La dernière phrase m'a fait bien mal au derche. Il parle de la télésurveillance et d'un fournisseur de système d'alarme qui nous avait été recommandé par le patron d'une boite d'élec qu'on a rachetée, fournisseur qui était aussi cher que ses petits copains
 
Donc faire économiser de l'argent tous les jours, c'est bien. Sauf qu'avec des dirigeants qui n'y comprennent rien, le jour où ça déconne, c'est forcément parce que c'était pas assez cher

Sachant que la solution initiale que t'avais proposée était trop chère

 

 
A savoir qu'on arrête d'enrichir les alarmistes du coin avec leurs marges indécentes (entre 200 et 300% easy), et qu'on pose/raccorde/configure nous-mêmes tous nos systèmes d'alarme. Parce que bon, tirer un pauvre bus, et mettre deux résistances en pont diviseur de tension à chaque capteur, vlà la technicité du truc
 
De mémoire, il m'avait dit qu'on peut pas tout faire nous-mêmes, qu'en cas de problème on ne serait pas certifiés, que c'était trop compliqué

 
Bah je comprends toujours pas

j-h != j/h

 
J'ai appris un truc. Je pensais que c'était une division justement pour dire "si on fait 5x sur les hommes, on met (en théorie) 5x moins de temps"

 
C’est le cas mais en multiplication : 10 jours homme c’est égal à 10 unités de temps multiplié par 1 unité de production ou 1 unité de temps multiplié par 10 unités de production.  
Après j’écris pas en maths donc jours-homme ou j/h ça signifie précisément la même chose.

BMenez: Bah non justement.
C'est de la manipulation d'unités niveau collège.

Si tu veux calculer le temps, tu divises bien la quantité de travail en jour·homme par le nombre d'hommes (faites-moi pas chier ).

Si t'avais une valeur en jour/homme, logiquement il faudrait la multiplier par ton nombre d'hommes pour obtenir le nombre de jours; donc plus t'as d'hommes, plus tu aurais de jours pour effectuer le travail.

C'est bien, maintenant vous allez pouvoir jouer avec les kW et les KWh...

La blague a justement été faite plus haut par Ivy gu.

Tu peux aller plus loin :
-les sauvegardes c'est pour ceux qu'on pas de couilles.

Et c’est les noobs qui sont pas loggés en root

Bon ben c'est pas chez nous alors

Remarque,  c'est assez vrai : plus il y a du monde à intervenir, plus ça prend du temps pour faire exactement la même chose....

Avec 9 femmes, on peut avoir un bébé en 1 mois !

la tu confonds charge et délai, une autre erreur très commune en gestion de projet  

 
Pour certain cette organisation par couche avec des inutiles serait même ultimement l'origine du rinçage et déclassement des millennials :
https://highline.huffingtonpost.com [...] als-print/

Tiens, un autre ticket des mêmes rigolos :
 
1. Sur un hôte en vieille version de XenServer 6.5 (donc pas dans le contrat de support)
2. Avec un disque PLEIN à 99%
3. « Je comprend pas j'arrive pas à migrer à chaud » (ce qui nécessite un snapshot, ce qui est compliqué quand tu as ton storage plein)
4. « J'ai effacé des snapshots ça n'a pas libéré de place ». Alors quand tu utilises XenServer depuis quasi 10 ans et tu connais pas encore le mécanisme derrière le snapshots, ça m'inquiète un peu… (supprimer le snapshot va déclencher un « coalesce » pour gagner ENSUITE de la place, mais à chaud, ça nécessite un snapshot… retour au problème 3).
 
Bref, j'ai expliqué 50 fois de pas avoir de storage plein… À la fin du ticket : « ah ok j'ai compris merci »…

Je suis né à la bonne époque tiens