Minimiser les temps d'indisponibilité d'un serveur 4D (notamment la sauvegarde)

Bonjour,

Nous avons une application client/serveur et un site web Extranet sur le même serveur.

Nous avons de plus en plus d’exigences en terme de disponibilité de l’application, notamment sur la partie Web.

Il y a 2 points bloquants :

  • un traitement de nuit qui doit accomplir certaines mises à jour sans contrainte de verrou ou d’intégrité (sur des transactions en cours). Là on peut agir sur le code et optimiser les choses .

  • la sauvegarde.
    Nous faisons 2 sauvegardes la nuit, une avant et une autre après le traitement de nuit pour minimiser le journal et comme cela, accélérer notablement les temps de reprises en cas de crash dans la journée (testé et éprouvé…).
    Donc chaque sauvegarde dure 45mn, sans compression et sans interlacing et sans redondance.

Le problème majeure de la sauvegarde est que nous n’avons aucun contrôle et le serveur fige tous les process en cours y compris les process web. Nous pourrions nous en passer car nous sommes sur un serveur virtualisé avec synchro d’une image toutes les 20mn, mais je ne suis pas chaud pour que l’on se passe du journal…

Donc quelles stratégie avez vous mis en place pour minimiser ces temps d’indisponibilités ?

Merci de partages vos expériences.

Vincent

Bonjour Vinceent

Dans ce cas il faut un 4D serveur miroir.
Le 4D serveur production va générer des fichiers historiques.
Le miroir va périodiquement intégrer les fichiers historiques ainsi créés (commande INTEGRATE MIRROR LOG FILE).

C’est le miroir qui s’occupe des sauvegardes ainsi le serveur production est toujours disponible.
Nous avons cela sur plusieurs sites sans soucis

Cordialement
Didier

Un serveur miroir est LA solution !

C’est ainsi que nous procédons pour des serveurs à très hautes disponibilités.

Quand à la sauvegarde image de la VM, j’ai vraiment beaucoup de réserve sur cette solution…

Juste pour savoir: quels types de disques ? vous parlez de machine virtuelle OK.
Mais si le temps de la sauvegarde dépend de la vitesse de copie de fichier sur le disque que votre data est gros et que vos disques ne sont pas des SSD rapides, il ne faut pas s’étonner.

Pour rappel: il n’y a aucune verification du fichier lors d’un backup (cela me choque toujours autant mais passons…), c’est une simple copie donc il ne reste que le temps de copie que l’on peut optimiser.

Oui le serveur miroir est certainement la meilleure solution.

: Maurice INZIRILLO

Quand à la sauvegarde image de la VM, j’ai vraiment beaucoup de
réserve sur cette solution…
Tu as raison Maurice, le snapshot de la VM n’est pas une solution fiable. Dans le cas présent, avec un snapshot toutes les 20 minutes, il est tout à fait possible que le snapshot soit déjà dans un état dégradé, que la mémoire soit déjà dans l’état qui a provoqué le problème… De plus, il y a de gros risques de déphasage entre la mémoire et le stockage.
Le snapshot, c’est bien pour restaurer rapidement un environnement système sain mais pas une base de données.
En cas de problème sur la VM originale, on restaure le dernier snapshot, on redémarre la VM, on restaure le backup de la base et on intègre son journal.
Cordialement,
Damien

: Manuel PIQUET

JPour rappel: il n’y a aucune verification du fichier lors d’un
backup (cela me choque toujours autant mais passons…)
S’il y avait une vérification lors d’un backup, ça augmenterait d’autant le temps de backup : il vaut donc mieux que la vérification soit dissociée.

Après il y a deux sortes de vérif :

1/ base en live
-> verifier fichier de données ouvert
J’ai posté le code de vérification que j’utilise https://forums.4d.com/Post/FR/30119663/1/30119675#30119664ici>, en suivant les conseils de Maurice (il y a une question restée sans réponse dans ce fil, si quelqu’un se sent d’y répondre…)

2/ fichier 4DD non ouvert
-> verifier fichier de données
Ça me semble parfait pour qui voudrait vérifier un backup après qu’il ait été produit. Maintenant, pour avoir déjà eu à automatiser une extraction de 4bk dans un contexte autre, ça demande du code (extraire le 4dd du 4bk, de gros fichiers à balader, etc.), j’ai pas eu le courage.

Bon, du coup je me contente de 1/, c’est dommage car verifier fichier de données est donné comme plus “regardant” que verifier fichier de données ouvert.

: Damien FUZEAU

Le snapshot, c’est bien pour restaurer rapidement un environnement
système sain mais pas une base de données.
Ha, un peu comme Time Machine, quoi. Cela dit, il y a une solution du pauvre possible avec ce type d’outil, mettre hardiment les backups sur le même volume que la base 4D (je vais me faire tuer, c’est sûr). Le robot va copier les backups avec le reste, et comme un 4bk est un vrai sarcophage, peu de chances qu’il se déforme pendant la copie.

Question : en virtuel, on le met où, l’historique ?

Bonjour,

J’étais absent hier et je découvre toutes vos réponses qui sont intéressantes.

Je vais regarder dans les bases de connaissances les informations sur le mirroring.

Merci pour vos conseils.

Vincent

: Arnaud DE MONTARD

Question : en virtuel, on le met où, l’historique ?
Le journal étant une sauvegarde de l’activité de la base depuis le dernier backup, mieux vaut le positionner à côté de celui-ci. En tout cas pas sur le même volume que le data car si le volume a un problème, tu peux dire adieu à ton journal…
Cordialement,
Damien

Avant le mirroring (qui engendre quand même un certain coût : il faut une seconde machine), tu n’as pas répondu à la question de ta configue actuelle sur quelle sorte de disque est ta base courante et vers où(quoi) tu procèdes à ton backup ?

Parce qu’une copie de fichier qui dur 45 minutes… :roll:

En fait j’avais préparé une réponse très complète dans un premier post mais je dois avoir 2 mains gauches ce matin il a disparu quand j’ai validé… Du coup j’en ai fait un simplifié.

Oui j’ai dit une bêtise, le backup dure 45mn mais pour l’ensemble des 2 backups (avant et après le traitement de nuit), donc 22mn environ par backup.

La base + index font 40Go.

La sauvegarde se fait sur un disque local non SSD pour des raisons de volumétrie (mais avant elle se faisait sur le même disque que la base en SSD et il n’y a quasi aucune différence de perf).
Les backups sont ensuite copiés sur un serveur réseau distant par sécurité.

40Go OK mais 22 minutes pour copier cela me semble beaucoup ?
Encore une fois de où à où ? d’un SSD vers un autre SSD ?

: Vincent HENNIQUE

La sauvegarde se fait sur un disque local non SSD pour des raisons de
volumétrie (mais avant elle se faisait sur le même disque que la base
en SSD et il n’y a quasi aucune différence de perf).
C’est étonnant, à chaque fois que j’ai fait l’inverse (HD remplacé par SSD), ça a vraiment réduit le temps du backup.

La base est sur un disque SSD.

Le backup est sur un disque non SSD (sata 6Gb/s).

Sauf que nous sommes sur un serveur qui est virtualisé (mais dédié au serveur 4D), peut être que l’on paie la couche de virtualisation quelque part.

Cela donne un temps de sauvegarde de 30Mo/s.

Quelles sont vos temps moyens de backups ? Bien meilleurs que cela ?

Je ne sais pas précisément, mais même le plus naze des SSD externes semble faire mieux :wink:

Voir l’article https://www.tomshardware.fr/comparatif-24-ssd-externes-portables-testes-lequel-choisir/4/ici>

La virtualisation c’est bien, mais rien ne vaux https://www.apple.com/fr/mac-mini/un petit mac mini recent> ; je te parle même pas du SSD interne qui t’explose littéralement … :mrgreen:

Je te conseille vivement la lecture de https://www.macg.co/tests/2018/11/test-du-mac-mini-2018-104324cet article> surtout le passage sur le SSD et le transfert de fichier bien instructif

Un petit passage croustillant :
Il faut à peine plus d’une minute pour transférer 50 Go entre deux Mac mini connectés sur un réseau Ethernet 10 Gb/s (820 Mo/s).

: Vincent HENNIQUE

Quelles sont vos temps moyens de backups ?

  • mac pro mi-2012, un backup de 15Go prend entre 1 et 2 minutes
  • mac mini serveur “late 2012”, 8Go en une 20aine de secondes
    Dans les deux cas, 2 SSD internes. Je ne sais pas comment avoir un mac récent à 2 disques internes, d’ailleurs, c’est couillon.

Pour les macs récents, avec le https://www.apple.com/fr/thunderbolt/Thunderbolt 3>, plus besoin d’avoir des internes…

: Arnaud DE MONTARD

Dans les deux cas, 2 SSD internes. Je ne sais pas comment avoir un
mac récent à 2 disques internes, d’ailleurs, c’est couillon.

Y aura pourtant bien deux emplacements de SSD dans https://www.apple.com/mac-pro/la dernière râpe à fromage d’Apple>
Après le prix donne de quoi s’étouffer :mrgreen:

Pas le choix… Mais l’offre a mis du temps à s’étoffer et un externe t3 coûte encore dans les lapoducu. L’autre souci est que je n’aime pas, mais alors pas du tout, ce que ça ajoute comme câbles (alimentation et interface serveur) ; à croire qu’il est écrit dessus « au nom de saint bilan carbone arrachez-moi par pitié ».