# Résolution de noms très lente

**URL:** <https://www.debian-fr.org/t/resolution-de-noms-tres-lente/83540>\
**Category:** Support Debian\
**Created:** [Décembre 14, 2020, 8:54 UTC](https://www.debian-fr.org/t/resolution-de-noms-tres-lente/83540 "2020-12-14T08:54:31Z")\
**Posts on this page:** 19\
**Page:** 1

<div class="post-metadata">

**Author:** ![udine1981](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/u/ecae2f/32.png) [@udine1981](https://www.debian-fr.org/u/udine1981)\
**Post date:** [Décembre 14, 2020, 8:54 UTC](https://www.debian-fr.org/t/resolution-de-noms-tres-lente/83540/1 "2020-12-14T08:54:31Z")

</div>

Bonjour tout le monde,

J’ai en ma possession une machine virtuelle VMWare hébergée chez OVH en Debian 9. Celle-ci me permet d’héberger un petit site Internet donc j’ai la configuration suivante NGINX 1.10, PHP7.4, Joomla et MySQL 5.5.

Tout fonctionnait très bien la semaine dernière, mais depuis jeudi c’est la catastrophe. La résolution des noms est très lente voire n’aboutie pas du tout. Aucune action de ma part sur ce site / machine.

J’ai tenté quelques petites choses déjà comme modifier mes nameserver, ajouter des options dans le fichier resolv.conf (comme timeout, rotate), désactiver IPv6, redémarrer plusieurs fois ma VM… Pourtant rien n’y fait.

Si je ping 8.8.8.8, aucun souci. Si je ping [google.fr](http://google.fr) ça ne passe plus. Un apt-get update n’abouti pas sur tous les serveurs (aléatoirement).

Tout ceci me provoque des erreurs PHP du type : Php\_network\_getaddresses: getaddrinfo failed: Temporary failure in name resolution

Ou encore des erreurs de passerelle 504 (bad gateway) sur NGINX.

Toute aide serait fortement appréciée. Je continue de chercher de mon côté.

---

<div class="post-metadata">

**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\
**Post date:** [Décembre 14, 2020, 9:56 UTC](https://www.debian-fr.org/t/resolution-de-noms-tres-lente/83540/2 "2020-12-14T09:56:46Z")

</div>

Que contiennent les fichiers /etc/resolv.conf et /etc/nsswitch.conf ?  
Que donne l’envoi de requêtes DNS aux adresses listées dans resolv.conf avec `dig`, `host` ou `nslookup` ?  
Y a-t-il des règles de filtrage iptables ou nftables ?

---

<div class="post-metadata">

**Author:** ![udine1981](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/u/ecae2f/32.png) [@udine1981](https://www.debian-fr.org/u/udine1981)\
**Post date:** [Décembre 14, 2020, 10:09 UTC](https://www.debian-fr.org/t/resolution-de-noms-tres-lente/83540/3 "2020-12-14T10:09:46Z")

</div>

Merci beaucoup.

Contenu de `resolv.conf`

```nohighlight
search WORKGROUP
nameserver 208.67.222.222
nameserver 208.67.220.220

```

`nsswitch.conf`

```nohighlight
passwd: compat
group: compat
shadow: compat
gshadow: files
hosts: files dns
networks: files
protocols: db files
services: db files
ethers: db files
rpc: db files
netgroup: nis

```

Régles iptables : `iptables -L`

```nohighlight
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination

```

`dig google.fr` :

```nohighlight
; <<>> DiG 9.10.3-P4-Debian <<>> google.fr
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58657
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;google.fr. IN A
;; ANSWER SECTION:
google.fr. 300 IN A 216.58.213.163
;; Query time: 11 msec
;; SERVER: 208.67.222.222#53(208.67.222.222)
;; WHEN: Mon Dec 14 11:06:30 CET 2020
;; MSG SIZE rcvd: 54

```

`nslookup google.fr` :

```nohighlight
Server: 208.67.222.222
Address: 208.67.222.222#53
Non-authoritative answer:
Name: google.fr
Address: 216.58.213.163

```

Je n’ai pas `nftables` d’installé.

---

<div class="post-metadata">

**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\
**Post date:** [Décembre 14, 2020, 10:23 UTC](https://www.debian-fr.org/t/resolution-de-noms-tres-lente/83540/4 "2020-12-14T10:23:07Z")

</div>

Ça a l’air de bien répondre. Que donne une requête de type AAAA (adresse IPv6) ?

---

<div class="post-metadata">

**Author:** ![udine1981](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/u/ecae2f/32.png) [@udine1981](https://www.debian-fr.org/u/udine1981)\
**Post date:** [Décembre 14, 2020, 10:33 UTC](https://www.debian-fr.org/t/resolution-de-noms-tres-lente/83540/5 "2020-12-14T10:33:21Z")

</div>

Faut m’aider pour celle là, désolé. Que dois-je taper ?

J’ai normalement désactivé entièrement IPv6 en faisant ça :

```nohighlight
sysctl -p
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.all.autoconf = 0
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.default.autoconf = 0

```

---

<div class="post-metadata">

**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\
**Post date:** [Décembre 14, 2020, 10:35 UTC](https://www.debian-fr.org/t/resolution-de-noms-tres-lente/83540/6 "2020-12-14T10:35:52Z")

</div>

> [@udine1981](#):
>
> Faut m’aider pour celle là, désolé. Que dois-je taper ?

Il faut spécifier le type dans la commande, voir les pages de manuel pour les détails. Par exemple :

```
dig aaaa debian-fr.org
host -t aaaa debian-fr.org
nslookup -q=aaaa debian-fr.org

```

> [@udine1981](#):
>
> J’ai normalement désactivé entièrement IPv6 en faisant ça :

Non, ça ne désactive pas entièrement IPv6. Cela ne fait que désactiver l’utilisation d’IPv6 sur les interfaces réseau, mais d’une part cela n’empêche pas le gestionnaire de réseau de le réactiver sur une interface donnée en fonction de la configuration définie, et d’autre part cela n’empêche pas l’envoi de requêtes DNS de type AAAA.

---

<div class="post-metadata">

**Author:** ![udine1981](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/u/ecae2f/32.png) [@udine1981](https://www.debian-fr.org/u/udine1981)\
**Post date:** [Décembre 14, 2020, 10:43 UTC](https://www.debian-fr.org/t/resolution-de-noms-tres-lente/83540/7 "2020-12-14T10:43:13Z")

</div>

Ok bon ça va, je m’attendais à plus complexe.

DIG :

```nohighlight
; <<>> DiG 9.10.3-P4-Debian <<>> aaaa debian-fr.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51655
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;debian-fr.org. IN AAAA
;; ANSWER SECTION:
debian-fr.org. 49 IN AAAA 2a01:4f8:202:6091::100
;; Query time: 27 msec
;; SERVER: 208.67.220.220#53(208.67.220.220)
;; WHEN: Mon Dec 14 11:37:32 CET 2020
;; MSG SIZE rcvd: 70

```

Host, 1ère tentative :

```nohighlight
;; connection timed out; no servers could be reached

```

La deuxième :

```nohighlight
debian-fr.org has IPv6 address 2a01:4f8:202:6091::100

```

Nslookup :

```nohighlight
Server: 208.67.220.220
Address: 208.67.220.220#53
Non-authoritative answer:
debian-fr.org has AAAA address 2a01:4f8:202:6091::100
Authoritative answers can be found from:

```

Ok compris pour IPv6, merci pour les explications.

---

<div class="post-metadata">

**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\
**Post date:** [Décembre 14, 2020, 11:20 UTC](https://www.debian-fr.org/t/resolution-de-noms-tres-lente/83540/8 "2020-12-14T11:20:43Z")

</div>

Je constate que c’était 208.67.222.222 (listé en premier dans resolv.conf) qui répondait aux requêtes de type A (adresse IPv4), alors que c 'est 208.67.220.220 qui a répondu aux requêtes de type AAAA. Tu as changé l’ordre dans resolv.conf ? Sinon, il y a eu un délai avant la réponse ?

---

<div class="post-metadata">

**Author:** ![udine1981](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/u/ecae2f/32.png) [@udine1981](https://www.debian-fr.org/u/udine1981)\
**Post date:** [Décembre 14, 2020, 12:02 UTC](https://www.debian-fr.org/t/resolution-de-noms-tres-lente/83540/9 "2020-12-14T12:02:47Z")

</div>

Non je n’ai rien changé du tout depuis qu’on discute ensemble. J’ai quand même vérifier.

Oui il y a eu un certains délai, effectivement, ça ne s’est pas fait en un claquement de doigt. D’ailleurs j’ai eu un timeout sur la première requête host.

Par contre je viens de voir dans le fichier /etc/network/interfaces :

```nohighlight
gateway XXX.XXX.XXX.XXX
# dns-* options are implemented by the resolvconf package, if installed
dns-nameservers 8.8.8.8
dns-search WORKGROUP

```

Est-ce que ça jouerait ? Je n’ai pas le même nameservers, je précise qu’au début de mon problème j’utilisais ceux de Google. J’ai changé /etc/resolv.conf avec ceux d’OpenDNS mais je n’ai pas changé dans ce fichier «&nbsp;interfaces&nbsp;».

---

<div class="post-metadata">

**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\
**Post date:** [Décembre 14, 2020, 12:09 UTC](https://www.debian-fr.org/t/resolution-de-noms-tres-lente/83540/10 "2020-12-14T12:09:36Z")

</div>

> [@udine1981](#):
>
> Oui il y a eu un certains délai, effectivement, ça ne s’est pas fait en un claquement de doigt. D’ailleurs j’ai eu un timeout sur la première requête host.

Dans ce cas il se pourrait que le délai soit causé par le premier serveur qui ne répond pas aux requêtes AAAA. Tu peux essayer de les permuter pour voir.

> [@udine1981](#):
>
> Est-ce que ça jouerait ?

Seules les adresses inscrites dans /etc/resolv.conf sont utilisées par le résolveur DNS.

Par contre si le paquet resolvconf est installé et si l’interface à laquelle l’option dns-nameservers est attachée est activée, alors les adresses figurant dans cette option devraient être inscrites dans /etc/resolv.conf.

---

<div class="post-metadata">

**Author:** ![udine1981](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/u/ecae2f/32.png) [@udine1981](https://www.debian-fr.org/u/udine1981)\
**Post date:** [Décembre 14, 2020, 12:24 UTC](https://www.debian-fr.org/t/resolution-de-noms-tres-lente/83540/11 "2020-12-14T12:24:32Z")

</div>

Ok j’ai fait l’inversion et repassé les commandes dig host et nslookup (en IPv6), ça a été beaucoup plus rapide. Voire instantané.

Pour autant toujours pas de ping sur un nom de domaine, mais ok sur une IP. Impossible de récupérer les sources lors d’un apt-get update.

J’essaie d’appeler OVH car une fois il y avait un problème sur leurs switchs (VM Network) lors d’une migration automatique. La conf n’avait pas suivi le changement.

Je n’ai pas grand espoir mais le caractère «&nbsp;soudain&nbsp;» de mon problème m’étonne quand même. Sachant que je seul à avoir accès à tout ça et que je n’ai absolument pas travaillé sur cette infra.

EDIT : un ping sur 8.8.8.8 est passé, un ping sur 8.8.4.4 ne passe pas, c’est vraiment très étrange.

---

<div class="post-metadata">

**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\
**Post date:** [Décembre 14, 2020, 12:26 UTC](https://www.debian-fr.org/t/resolution-de-noms-tres-lente/83540/12 "2020-12-14T12:26:01Z")

</div>

> [@udine1981](#):
>
> Ok j’ai fait l’inversion et repassé les commandes dig host et nslookup (en IPv6), ça a été beaucoup plus rapide.

Et en IPv4 (type A) ?

> [@udine1981](#):
>
> toujours pas de ping sur un nom de domaine

C’est-à-dire ? Quelle commande ? Que retourne la commande ?

---

<div class="post-metadata">

**Author:** ![udine1981](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/u/ecae2f/32.png) [@udine1981](https://www.debian-fr.org/u/udine1981)\
**Post date:** [Décembre 14, 2020, 12:27 UTC](https://www.debian-fr.org/t/resolution-de-noms-tres-lente/83540/13 "2020-12-14T12:27:52Z")

</div>

Rien du tout en fait, je suis obligé d’interrompre.

```nohighlight
root@SiteWeb:~# ping www.google.fr
^C
root@SiteWeb:~# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=113 time=4.02 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=113 time=4.04 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=113 time=4.04 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=113 time=4.07 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=113 time=4.01 ms
64 bytes from 8.8.8.8: icmp_seq=6 ttl=113 time=4.04 ms
64 bytes from 8.8.8.8: icmp_seq=7 ttl=113 time=4.03 ms
64 bytes from 8.8.8.8: icmp_seq=8 ttl=113 time=4.03 ms
64 bytes from 8.8.8.8: icmp_seq=9 ttl=113 time=4.04 ms
64 bytes from 8.8.8.8: icmp_seq=10 ttl=113 time=4.07 ms
64 bytes from 8.8.8.8: icmp_seq=11 ttl=113 time=4.05 ms
64 bytes from 8.8.8.8: icmp_seq=12 ttl=113 time=4.07 ms
64 bytes from 8.8.8.8: icmp_seq=13 ttl=113 time=4.02 ms
64 bytes from 8.8.8.8: icmp_seq=14 ttl=113 time=4.04 ms
64 bytes from 8.8.8.8: icmp_seq=15 ttl=113 time=4.06 ms
64 bytes from 8.8.8.8: icmp_seq=16 ttl=113 time=4.03 ms
64 bytes from 8.8.8.8: icmp_seq=17 ttl=113 time=4.09 ms
64 bytes from 8.8.8.8: icmp_seq=18 ttl=113 time=4.40 ms
^C
--- 8.8.8.8 ping statistics ---
18 packets transmitted, 18 received, 0% packet loss, time 17019ms
rtt min/avg/max/mdev = 4.018/4.068/4.409/0.092 ms
root@SiteWeb:~# 

```

```nohighlight
root@SiteWeb:~# ping 8.8.4.4
PING 8.8.4.4 (8.8.4.4) 56(84) bytes of data.
^C
--- 8.8.4.4 ping statistics ---
17 packets transmitted, 0 received, 100% packet loss, time 16383ms
root@SiteWeb:~# ping 8.8.4.4
PING 8.8.4.4 (8.8.4.4) 56(84) bytes of data.
^C
--- 8.8.4.4 ping statistics ---
47 packets transmitted, 0 received, 100% packet loss, time 47088ms

```

---

<div class="post-metadata">

**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\
**Post date:** [Décembre 14, 2020, 12:32 UTC](https://www.debian-fr.org/t/resolution-de-noms-tres-lente/83540/14 "2020-12-14T12:32:17Z")

</div>

Ce sont des adresses IP, pas des noms de domaine.  
8.8.4.4 ne répond pas au ping, c’est son droit le plus strict, et ça n’a rien à voir avec la résolution de noms.

---

<div class="post-metadata">

**Author:** ![udine1981](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/u/ecae2f/32.png) [@udine1981](https://www.debian-fr.org/u/udine1981)\
**Post date:** [Décembre 14, 2020, 12:32 UTC](https://www.debian-fr.org/t/resolution-de-noms-tres-lente/83540/15 "2020-12-14T12:32:26Z")

</div>

> [@PascalHambourg](#):
>
> `nslookup -q=aaaa debian-fr.org`

```plaintext
root@SiteWeb:~# dig a debian-fr.org
; <<>> DiG 9.10.3-P4-Debian <<>> a debian-fr.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7377
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;debian-fr.org. IN A
;; ANSWER SECTION:
debian-fr.org. 418 IN A 148.251.85.151
;; Query time: 26 msec
;; SERVER: 208.67.220.220#53(208.67.220.220)
;; WHEN: Mon Dec 14 13:30:19 CET 2020
;; MSG SIZE rcvd: 58
root@SiteWeb:~# 

```

```plaintext
root@SiteWeb:~# host -t a debian-fr.org
debian-fr.org has address 148.251.85.151
root@SiteWeb:~# 

```

```plaintext
root@SiteWeb:~# nslookup -q=a debian-fr.org
;; connection timed out; no servers could be reached
root@SiteWeb:~#

```

---

<div class="post-metadata">

**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\
**Post date:** [Décembre 14, 2020, 12:34 UTC](https://www.debian-fr.org/t/resolution-de-noms-tres-lente/83540/16 "2020-12-14T12:34:03Z")

</div>

Il semblerait qu’un des deux serveurs DNS ne répond pas aux requêtes A et l’autre ne répond pas aux requêtes AAAA. Nous voilà frais…

Edit : Non, j’ai lu trop vite. En tout cas ils ne répondent pas tout le temps.

Change de serveurs DNS. OVH n’en fournit pas ?

---

<div class="post-metadata">

**Author:** ![udine1981](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/u/ecae2f/32.png) [@udine1981](https://www.debian-fr.org/u/udine1981)\
**Post date:** [Décembre 14, 2020, 1:08 UTC](https://www.debian-fr.org/t/resolution-de-noms-tres-lente/83540/17 "2020-12-14T13:08:20Z")

</div>

Merci merci !

Je viens de raccrocher avec OVH (36 minutes au tel) ! Il y a effectivement un souci sur mon infra réseau (mes switchs virtuels et mes VLANs). En fait j’ai deux hôtes dans le même POOL, et ça bascule automatiquement de l’un à l’autre en fonction de la charge de chacun.

Tout fonctionne à nouveaux correctement dès lors où je désactive ce mécanisme automatique et force ma VM a être sur un hôte en particulier.

Ils m’en fournissent un de secours en remplacement du «&nbsp;problématique&nbsp;». Pour le moment je suis donc sur une seule patte !

Ma VM et mon système ne sont pas en cause du coup.

En tout cas, mille merci pour on aide et ton temps. J’ai appris de nouvelles commandes aujourd’hui.

---

<div class="post-metadata">

**Author:** ![anon90668717](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/3e96dc/32.png) [@anon90668717](https://www.debian-fr.org/u/anon90668717)\
**Post date:** [Décembre 16, 2020, 7:44 UTC](https://www.debian-fr.org/t/resolution-de-noms-tres-lente/83540/18 "2020-12-16T07:44:07Z")

</div>

Salut ton message a attisé ma curiosité: quel soft vmware as tu installé sur ton vps?  
Tu as une plateforme vmware sur laquelle tu as installé des vms dont celle qui te sert de serveur web?  
Peux tu m’en dire plus peut etre ds ‹&nbsp;trucs et astuces&nbsp;› car j’avoue avoir envisagé l’utilisation de containers pour une plateforme multisites mais jamais je n’aurais pensé que ovh permette ce que tu as fait…je suis curieux

---

<div class="post-metadata">

**Author:** ![udine1981](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/u/ecae2f/32.png) [@udine1981](https://www.debian-fr.org/u/udine1981)\
**Post date:** [Décembre 23, 2020, 3:31 UTC](https://www.debian-fr.org/t/resolution-de-noms-tres-lente/83540/19 "2020-12-23T15:31:51Z")

</div>

Salut, un peu tardivement désolé.

Ce ne sont pas des produits type VPS dont je dispose, mais ce qu’ils appellent Private Cloud.  
En fait tu choisis ton offre, dans mon cas j’ai deux hôtes avec 32Go de RAM sur deux sites, Roubaix et Strasbourg. Ces deux hôtes, sur chaque site, je les administre avec VMWare vSphere Client (la version Web pour Strasbourg et le client PC pour Roubaix). J’administre tout ça comme une infra virtuelle disons classique et je peux créer des VMs dessus peu importe le système que j’installe ensuite sur la VMs (J’ai du Linux, du Windows Server 2016, du FreeBSD). Faire des snapshots etc.  
Il a fallu que j’achète chez eux aussi des blocs d’IPs pour pouvoir les lier à mes VMs. Avec ces IPs je peux lier à mes domaines, sous domaines, des VMs. Chose que je n’ai pas vraiment fait dans mon cas (enfin si deux). Mon site Internet est en frontal sur le web (celui qui me posait souci dans ce post) et les services que je mets à disposition de mes users lui est derrière un pare-feu qui lui s’occupe du routage vers la bonne VM derrière en fonction du port, des règles etc.

Entre les deux sites, j’ai également souscrit à Zerto, sur deux VMs en particulier dites «&nbsp;sensibles&nbsp;» chez moi. Ainsi grâce aux fonctionnalités inhérentes à VMWare, en fonction de la charge, cela bascule sur un hôte ou l’autre du même site (système DRS) et en plus de ça, si un site tombe, je peux basculer presque (j’ai bien dit presque) automatiquement sur l’autre site et continuer de fournir mon service.

Si un site tombe, le Zerto me permet d’avoir entre 10 et 15 secs d’écart entre les statuts des VMs. Selon la doc OVH…

Alors je n’ai pas vraiment de «&nbsp;trucs et astuces&nbsp;», j’ai découvert un peu sur le tas il y a deux ans maintenant.  
Globalement je suis plutôt content des produits auxquels j’ai souscrit. Les problèmes que j’ai eu étaient surtout dus aussi au switch virtuel qui est avec et non les hôtes ou VMs à proprement parlé. Ce post était le deuxième cas de figure un peu compliqué à solutionner.

Ah si, lorsque tu créé la VM, tu as le choix entre deux types de stockage, un SSD et un classique. Une fois un SSD est tombé, bah rien à faire, j’ai tout perdu. Heureusement la VM n’était pas essentielle. Et on m’a juste répondu que ce type de stockage était plus soumis aux défaillances… Un peu léger. Elle n’était pas dans mon Zerto.

Et enfin pour faire court, bien ça s’administre et se configure comme une vraie infra virtuelle VMWare.

Pas de «&nbsp;trucs et astuces&nbsp;» mais un petit retour d’expérience…