Questions diverses

CDN

Les CDN Azure conservent les sessions TCP ouvertes avec les backends pendant 90 secondes et les réutilisent pour différents clients. Le timeout de session TCP est plus court de notre côté, on renvoie un paquet de fin de session TCP quand le 
CDN demande a réutiliser la session. Ça explique l’erreur renvoyée en quelques millisecondes. La solution est d’augmenter la durée maximale des sessions TCP de notre côté.
Scenario:
We see that AFD sending a HTTP request to the server backend, so there can be a race between AFD (the HTTP client) sending a new request on a kept alive connection and the backend (the HTTP server) timing out in the idle connection by 
returning a TCP FIN. Also, we see that idle timeout on backend is set too low and ERROR_WINHTTP_INVALID_SERVER_RESPONSE can happen due to this race, because kept-alive connections are relatively idle. Specifically, this can happen when AFD 
sees the TCP FIN and it re-uses an left-idle kept-alive connection and starts sending a new HTTP request. AFD interpret that TCP FIN as a bad response. Since a TCP FIN is received, AFD has no choice but to fail the request. It is not safe 
for AFD to resend the request since there’s no way to tell whether the request may have already been processed by the backend.
Further Suggestions :
AFD has an TCP idle timeout of 90 seconds but the backend (Web server) has an idle timeout less than Front door time out value. And we need to change the idle timeout on backend which can be higher than AFD or else we disable the Keep alive 
time out on web server to mitigate the issue.

PRA / Failover

Question 1 :
Tu me disais ce matin qu’il y a 2 modes pour une VM et/ou un recovery plan
•	« test Failover » sur un «Test failover network » (test de bascule)
•	« Failover»  sur le «Target network » (la VRAIE bascule)
 
Reponse 1 :
Oui c’est ça. Et dans le cas d’ELSAN « Test Failover » et « Failover » se font dans le même VNET cible (c’est un choix du client, dicté par des contraintes techniques sur la base de donnée SAP).


Question 2 :
Lors d’un « test Failover », les VMs d’origine restent vivantes sur le site principal. Alors que j’ai 2 questions :
•	Comment on se connecte à une VM basculée en mode « test Failover », qui se trouve sur son «Test failover network » (qui peut être identique à son «Target network ») ?
•	Comment ça se présente au niveau des VMs : on aura des VMs en doublons (avec les mêmes noms ?) ?

Réponse 2 :
Le Test failover est une simulation de bascule, les VMs d’origine ne sont nullement impactées.
Les VMs basculées en mode « test failover »  où « failover » vont se trouvées dans le même VNET-DR (10.237.0.0/16), nous avons déjà prédéfini les subnets cible pour chaque VM.
Dans le cas d’un « test failover », la VM basculera dans le subnet prédéfini et y recupérera une IP en dhcp (pour les IPs privées)
Dans le cas d’un « failover », la VM basculera dans le subnet prédéfini et y recupérera  l’IP préallouée.
Pour les VMs qui ont une IP sur le site principal, une IP public est préservée pour l’ASR et le client doit faire 
Les VMs ASR ont un suffixe asr dans leur nom (il n’est pas possible d’avoir 2 VMs avec le même dans la même souscription), cependant la VM ASR aura le même hostname que la VM d’origine. D’où un changement des IPs dans la zone DNS privée lors d’un failover.


Question 3 :
Lors d’un « Failover » :
•	les VMs d’origine sont dans quel état sur le site principal ? 
•	Comment ça se présente au niveau des VMs : on aura des VMs en doublons (avec les mêmes noms ?) ?
•	Comment on se connecte à une VM basculée qui se trouve sur son «Target network » (depuis RDSH) ?

Réponse 3 :
Si on fait un failover, ce la suppose que le site principal est indisponible quel que soit la raison, panne Azure, indisponibilité d’un service, ou même arrêt intentionnel dans le but de faire un test (Ce que prévoit de faire Richard)
Pour le Client ELSAN, les 2 VNET sont routés via l’expressoute, toutes les VMs (ASR ou pas) s’y trouvant sont accessibles depuis l’AO (RDSH).
A la fin du failover, il faut faire failback, rechangere les IPs privsé dans la zone DNS et relancé le site principal.