Reprise du message précédent :

Ça me concerne car je cherche des solutions aux problèmes de mes clients

C'est une fibre dédiée entre ses deux DC. Ça me concerne car on backup avec des streams (sans cache local). Autrement dit, ça va à la vitesse du backup repository le plus lent. Dans ce cas, il faut une gestion quasi asynchrone du backup pour pas ralentir celui qui se faire sur le backup repo dans le même datacenter.

La solution « simple » c'est de faire un autre job dédié au backup distant. Mais le plus propre ça serait dans le même job de permettre de faire un backup distant en même temps sans pénaliser le job local.

Ya plusieurs pistes à essayer (certaines assez fun ou tu crées un nouveau stream à partir de celui écrit sur le backup repo local (qui va plus vite mais on s'en fout puisqu'il doit être stocké au final) et qui va écrite à distance

Sinon le truc qu'à l'air de faire VEEAM : dire que dans ce job, tu fais aussi une copie ailleurs mais asynchrone (pas bloquante pour le backup local)

 
ouch… J'ai 11ms entre nos bureaux (vides en ce moment) et notre DC (Grenoble et Lyon). Parfait pour mon backup hors-site en attendant d'avoir un rack aux US

j'ai rien compris. il backup son storage xen ?

Il backup ses VMs XCP-ng via Xen Orchestra. Tu peux avoir plusieurs partages/NAS pour un même job, XO va multiplexer le flux (un export, envoyé vers plusieurs NFS).

Le truc c'est qu'avec un flux, tu as la backpressure, donc si un des deux NFS rame, ton backup entier va ramer. Ça va toujours à la vitesse du plus lent (sinon faut stocker quelque part)

oui mais nfs avec gros ping quoi  
 
kindly help

 
 
Sur les liens a forte latence, il y a de l'opti réseau possible. L'idée c'est de jouer sur les fenêtres de transmission TCP (si c'est bien du TCP). Le concept, c'est de ne pas trop attendre les accusés de réception pour émettre la suite des données. Tout ça est très dépendant de l'applicatif. Si c'est du transactionnel par exemple (ça semble être le cas chez toi), il est compliqué de limiter les temps mort a attendre les accusé de réception.  Attention aussi a prendre en compte l'implémentation de la pile au niveau système. Le buffer de transmission peut être limité par l'allocation mémoire réservée a la socket. (c'était systématiquement le cas avec scp et openssh dont les buffer de transmission était limité en dur, ce qui avait donné naissance a un fork : hpn-ssh)
 
les mot clés, c'est long fat network, bandwith delay product optimisation ou tcp rwin and latency.

Et ya pas du tweaking NFS ou TCP a faire sur du wan ?
Arf j'aurai du changer de page avant de répondre haha

nan mais ce qui ralentit c'est le fait que ce soit sans dout en sync le NFS, c'est juste que c pas le bon protocole pour du WAN
 
autant le monter en async pour maximiser la vitesse de transfer et faire un check a posteriori (si y'a erreur, la donnée n'est pas perdue)

 
Tu peux passer NFS en async ou bufferiser des morceaux plus gros, pour éviter la pénalité de la latence forcément très forte sur des tas de petits blocs.
 
Le soucis c'est que c'est pas généralisable. Si demain j'ai un client sur un lien 100M avec 400ms de latence, tu auras beau optimiser, tu seras pas bien
 
Donc faut trouver une réponse plus pérenne. Mais bien sûr en attendant, on lui trouve des workarounds

Oh putain  

 
l'important c'est de bien faire ses backups distants, même si c'est lent

Hi
 
we are in bangalore and mounting our nfs server in los angeles is slow.
 
kindly help

Non mais c'est sûr que ça va arriver et c'est pas illogique (d'avoir des backups très lointains).

Au lieu de créer un job séparé, ça serai top d'ajouter un "async backup repository" au même job (voir sur un schedule différent)

Storage Replica quoi

 
On parle de backup là Backup de backup in fine

et sinon, XOA fait le café et revenir ta femme ?

Je vois pas le soucis de répondre à un besoin utilisateur qui me parait légitime

+1, j'aime bien suivre tes aventures, parfois ya un risque de réinventer la roue mais c'est ce qui justement permet de sortir de nouvelles idées, avec le potentiel d'en trouver de meilleures que "on a toujours fait comme ça". Bon ya aussi le risque de trouver des idées pourries, c'est le jeu

Du coup  Elon Musk pourra faire des backup mars <->  terre avec des latences de 21 minutes ?

Faut compter l'A/R, donc un ping de plus de 2 500 000 ms

edit : bon déjà faut négocier un deal avec Elon pour avoir du XCP-ng sur Mars Mais bon, on avance, on a bien des articles sur nous sur The New Stack

https://www.journaldunet.com/web-te [...] vegardees/
 
operation de maintenance sur les onduleurs le matin de l'incendie
ca va piquer

Bon certes c'est pas la même taille d'onduleur, mais du coup je me demande sérieusement si j'ai raison de changer les batteries plutôt que l'ensemble quand ça a 7 ans ++

j'en ai vu récemment des changés, la moitié des batteries avaient lourdement gonflés (j'ai vu de loin, mais même de loin c'était tangible), j'aurais pas eu ocnfiance

Il y a 7-8 ans j'avais le souci une fois sur deux, sur la dernière fournée de batterie changée au bout de 4/5 ans, ras.

J'en change pas mal à mon échelle de 12v 4 ou ~7Ah, la dernière fois que j'en ai amené en rachat au ferraillage j'en avais 188 Kg
Et je vais devoir bientôt faire une fournée, je dois être à la moitié de ça.

C'est plus pour les étages de conversion de puissance que je m'inquiète, même si ça doit être assez logiquement pas mal protégé, en plus d'être souvent de nos jours de la découpe haut rendement en PWM (type IGBT).

Serieusement ....

Fédé    de la Lose (@FFLose) aime ça  

Leur offre avec VMware ?

après ça ne devait pas être caché je pense, mais une analyse précise des conditions de l'offre devait quand même laisser voir que c'était pas très très utile comme backup (juste un backup contre le wipe accidentel en gros)

De toute façon même avec des backup distants ce ne serait pas plus secure de faire les backup chez un autre presta d'hébergements ?

Il y a déjà eu des hébergeur qui se sont pris des cryptolocker sur leur infra de prod ?

A vue de gros pif tout a l'heure, c'est mentionné backup sur serveur distinct avec alimentation électrique distincte.
Donc tu peux t'en douter mais c'est pas écrit que c'est sgb1 et sgb2

ok, en gros ils sont couverts, ils offraient l'option pour cocher la case sur le catalogue mais pas forcément que ce soit utile.
 
Curieux, ce choix, vu qu'a défaut d'être HDG dans leurs équipements ils ont plutot pas mal de DC distincts.

mais bon je suis quand même d'avis qu'il faut autant que faire se peu les soutenir
 
parce que le cloud souverain, c'est OVH ou rien.

 
comment ça, pas très utile ? je pense que les incidents "gros doigts" sont bien plus fréquents que les incendies.

 
Le "cloud" a pris du plomb dans l'aile quand même...

 
Le gouvernement avait craché à la gueule d'OVH pour prendre du OBS / Cloudwatt à l'époque hein.
 
L'état s'en tape d'OVH  

 
Je dirais même que le cloud est parti en fumé !  

C'est une redondance pour un service, pas une solution contre un désastre.

La, ça tourne même si tu plantes, en cas de coupure planifiée... Et ta latence/temps de backup se passe bien

Cette phrase qui nous rappelle qu'on a tellement rien de souverain  

Quand je pense à Linux, on étaient bien positionné au départ et pouf...

Pas de mail, de cloud, etc...  

On avait le label PUR Hadopi  

Bon y'a pas la milliards magique de la scilicon valley, mais qu'est-ce qui fait qu'OVH reste coincé quand même un peu dans son image d'hébergeur de l'internet cheapouille ?
y'a 7 ans déja j'avais eu l'occasion de comparer un peu par rapport à AWS, et ça tenait pas la comparaison
 
et maintenant ? Ils arrivent pas à lever de la thune ?
 
ou bien quitte à dire du mal, Octave serait un bon founder, CTO geek mais pas le bon CEO ? (parce qu'il faudrait un X HEC Enarque pour faire signer ses potes du CAC40)
 
bah clairement t'es le CAC, tu vois OVH, t'es plus gros qu'eux, tu te poses des questions
t'es le CAC, tu vois les GAFAM, t'es plus petit qu'eux donc tu te dis que ton IT va être plus sûre chez eux.