Aller au contenu

Remplacer les disques d'un Synology sans Raid et sans Spare


Sethenès

Messages recommandés

  • Réponses 530
  • Créé
  • Dernière réponse

Top contributeurs dans ce sujet

Top contributeurs dans ce sujet

Posted Images

Ceci dit, ça donne aussi une idée de la superficialité d'un test SMART qui doit prendre moins d'1 h / TB. Ici écrire et vérifier prend 4 h / TB

ok merci ;)

 

il existe un test smart étendu chez Synology mais je ne sais pas à quoi cela correspond.

 

Il est bien plus long (> 10h) pour 8 To.

 

--

 

Si c'est trop long pour badblocks (ici 8 jours avec les 2 en parallèle),

je pense qu'au bout de la phase n°3 voire 4, je vais arrêter la vérification.

Lien vers le commentaire
Partager sur d’autres sites

Ca se tient. Je suggère effectivement de le faire après la vérification (lecture) de l'écriture des 0x55, donc la P4.

 

S'il y a un secteur défectueux, tu seras déjà passé dessus 4x (2 écritures & 2 lectures).

 

Surtout qu'après tu dois encore tester les deux autres.

 

Moi je suis stoïque ... 2,5 jours x 2, donc 5-6 jours, ça ne représente pas grand chose face aux 5 ans que j'espère tenir la machine.

 

L'autre intérêt du test est de pouvoir remballer le disque très rapidement s'il y a un souci.

Lien vers le commentaire
Partager sur d’autres sites

Ca se tient. Je suggère effectivement de le faire après la vérification (lecture) de l'écriture des 0x55, donc la P4.

 

S'il y a un secteur défectueux, tu seras déjà passé dessus 4x (2 écritures & 2 lectures).

 

Surtout qu'après tu dois encore tester les deux autres.

 

Moi je suis stoïque ... 2,5 jours x 2, donc 5-6 jours, ça ne représente pas grand chose face aux 5 ans que j'espère tenir la machine.

 

L'autre intérêt du test est de pouvoir remballer le disque très rapidement s'il y a un souci.

il n'y a pas que ça.

 

La je fais des vérif. pour moi mais ensuite je vais "vendre" cette prestation.

Donc étant donné puisque nous vendons du temps (en info.), je dois trouver des solutions acceptables pour ne pas passer

ces 8 jours à vérifier les disques.

 

1 - Je ne peux les vérifier avant et faire du stock.

2 - Huit jours (pour 8 To c'est rare hein) de délais c'est trop long pour être réactif.

3 - avoir une vérification fiable (avant ET pendant)

i.e badblocks ou vérif. constructeur

puis smart chaque semaine avec smart étendu tous les 3 ou 6 mois

+ monitoring temp / capacité / espace dispo.

+ alerte si découverte secteur défectueux

ET changement de disque préventif à 3 ou 5 ans.

 

Juste pour les disques d'ailleurs …

 

--

 

En parallèle je valide un serveur SNMP via docker mais rien ne fonctionne correctement …

 

Je sais pas si ça vient des containers ou de docker sur Synolgy mais c'est pas encourageant …

 

> controleur Unifi, monitoring SNMP, gestion ticket, gestion CRM

Lien vers le commentaire
Partager sur d’autres sites

Si je devais vendre ça au niveau pro, je ferais comme suit :

- NAS avec au moins 5 baies,

- Raid 5 avec un disque de parité sur 4 disques + 1 disque spare (donc il y a bien 2 disques perdus : 1 pour les parités, 1 pour le spare). Sur ce disque la, qui n'est quand même pas utilisé, je ferais le test pendant la mise en service chez le client.

 

En cas de blème (en tout cas chez NetApp c'est comme ça), le système Raid initie de lui même la reconstruction du Raid dès qu'un disque défectueux est détecté et envoie une alerte au support. C'est le genre d'alerte que tu devrais traquer si possible en provenance du Syno. Bon évidemment, chez NetApp si tu as le support, le lendemain matin, un technicien est la avec un nouveau disque. Il retire le disque défectueux et place celui de remplacement qui devient le nouveau spare.

 

Sur 42 disques, j'ai quand même eu deux fois le cas et chaque fois dans les 6 mois qui ont suivi l'achat (d'abord 28 qu'on a étendu ensuite à 42).

 

Evidemment, au début, je n'ai pas eu besoin des 28 disques. Donc j'avais 5-6 spares, que j'ajoutais au Raid 4 (avec 2 disques de parité fixe) au fur et à mesure que j'en avais besoin. Il faut dire aussi qu'il y avait en fait 2 NAS et que j'assignais d'abord un disque au NAS avant de l'assigner en spare.

 

Car un raid dégradé, dans un environnement pro, c'est sueurs froides assurées et baisse dramatique de performance, en ce compris pendant la reconstruction. Et comme on travaille moins de 12h par jour, j'ai eu la chance que les 2x c'étaient en pleine nuit et le raid était reconstruit le lendemain matin. Il faut dire aussi que les disques étaient de petites tailles (des 144 GB ou des 288 GB, je ne me souviens plus).

Lien vers le commentaire
Partager sur d’autres sites

Aussi au niveau pro, j'essaierai de vendre un NAS avec plus de disques mais plus petits. Pas pour faire de la thune, mais pour :

- diminuer le poids des disques perdus car perdre 2 disques / 8 ou 12, c'est nettement moins qu'en perdre 2 / 5. 

- le responsable du support NetApp de ma boite disait (en interne donc, hors système commercial) qu'il fallait augmenter le nombre de "spindle" pour augmenter les performances (n'oublions pas qu'en pro, on parle de nombreux accès concurrents). Plus de 100 personnes étaient présentes en même temps à mon taf. Cet argument du spindle est l'un de ceux qui me faisait de l'oeil pour le 3018xs avec la 5ème baie pour le spare. Ici mon spare sera juste à côté ;)

 

Une raison moins objective mais plus "viscérale" qui est de ne pas mettre tous les oeufs dans le même panier. Et aussi quand même d'opter pour des disques aux capacités sûres. Des 3 TB, ajd il a du s'en vendre un sacré paquet comparé aux 8 TB par exemple. Je ne dis pas que 3 TB est la taille optimale actuellement. C'est difficile à suggérer d'ailleurs car les WD Red 5 TB ont disparu du marché et dieu sait pourquoi.  D'ailleurs comme j'ai un 5 qui n'était pas très vieux, j'aurais bien acheté 3 autres 5 pour bâtir mon DS918+. En l'absence de 5 TB, j'ai préféré opter pour 4 nouveaux disques, mais je n'ai pris que des 3 TB (et aussi j'ai les 2 anciens 3 TB qui pourront servir de spare). Je n'aurai que 9 TB mais c'est largement assez (Raid 5 sans spare) et c'est sans compter que sur l'ancien NAS j'ai 17 TB s'il faut ;)

 

Et enfin, je choisirais une taille de compromis qui serait potentiellement acceptée par tous mes clients et j'aurais "quelques" disques de cette taille en réserve pour le cas où il y aurait un problème.

Lien vers le commentaire
Partager sur d’autres sites

Je ne me souvenais pas de telles disparités entre les disques, ça interpelle quand même quand on sait qu'ils sont du même bain et ont le même bios :

 

228811Capturedcran20171107104048.png

 

Que l'écriture soit un peu plus longue que la lecture n'est pas le problème. Mais entre les deux disques, l'écart de vitesse est de l'ordre de 2%.

 

Je vais voir ce que ça donne avec les 2 derniers.

 

Pour du Raid, c'est quand même interpellant. Je précise que je n'ai aucune info ni dans un sens, ni dans un autre par rapport au Raid, la seule chose dont j'ai entendu parler, c'est le temps de "réveil" du disque qui peut jouer des tours s'il est très différent d'un disque à l'autre.

 

J'ai vérifié et assez logiquement, c'est la vitesse du disque le plus lent qui dicte la vitesse du Raid. Et par voie de conséquence ce n'est pas un "problème",  c'est même prévu en fait. Ceci dit, raison de plus pour moi d'opter pour des disques du même constructeur avec les mêmes technologies.

 

Je crois que je vais mettre les disques dans l'ordre suivant : le plus lent dans la baie 1 et ainsi de suite.

Lien vers le commentaire
Partager sur d’autres sites

@Sethenès : effectivement en environnement pro c'est rare que les données les plus utilisées atteignent une telle capacité.

 

D'où l'intérêt d'un RAID avec cache SSD (cf DS918+) d'ailleurs.

 

Mais je n'ai pas à ce jour ce type de clientèle (RAID 6 d'ailleurs je préconise ici).

 

Les seuls clients qui consomment autant de data (> 10 To) sont les pro. de la vidéo (réal. / boite prod. / agence comm.)

et de l'image (photographes, 3D, drone, achi. urbaniste (chercheurs)).

 

Et ce n'est pas pour la prod. / partage, c'est pour du stockage / archivage.

 

Donc les performances LAN ne sont pas hyper importantes sauf pour 100 Go max. de data en partage / mouvement (> la réponse est le SSD cache).

Et bien souvent c'est leur réseau anémique qui bloque … Je gère plus de la TPE/PME qui n'a pas de vision IT bien précise :D.

(comprendre qu'avant mon arrivée ils ont ce qu'on leur a vendu, pas une archi. cohérente).

 

Par ailleurs avec de tels clients (= garantie de services), j'aurai un peu peur de proposer du Synology (plus gros clients avec Syno. à 15 user).

nota : meme si pour du samba, on peut monter sans pb (j'ai eu des soucis avec les copier coller et les pb de caractères à une époque donc je flippe :D ).

 

J'aurai plus confiance en KVM + CentOS + Bacula (en RAID 1 (dont 1 spare) avec SSD cache), controleur AD (SMB), 2x10 Gbe SFP etc …

 

Mais je ne suis pas encore mature pour mettre ça en prod. (suis seul (indépendant) et me repose sur partenaires dans ce cas si besoin).

 

--

 

intéressant au sujet des disques effectivement.

 

Je te dirai quand j'utiliserai le RAID 6 avec le SSD :D

 

--

 

Au sujet du choix des disques, faut être attentif au nombre de plateaux.

 

Généralement les capacités intermédiaires (750 Go, 3 To) (pas certain mais j'ai cette analyse en mémoire)

ont statistiquement plus de pannes parce que plus de plateaux / composants.

 

Quoi qu'il en soit, de toute facon, le choix du matériel dépend grandement de la QoS et des garanties demandées par le client.

Et quand tu sais que j'ai du faire 2 PRA/PCA sur une 50 aine clients pro en 8 ans … ça montre la clientèle et les besoins :D

Lien vers le commentaire
Partager sur d’autres sites

Merci pour ces précisions, ça permet de mieux cerner le problème. J'avoue que CentOS, je ne connais pas du tout.

 

Ceci dit, pour avoir travaillé avec NetApp, QNAP & Syno, les deux premiers dans le monde pro, le dernier en privé, il n'y a pas photo : le seul que je recommanderais pour des PME de 20+, c'est NetApp. Je ne dis pas QNAP et Syno ce n'est pas bien, mais il y a quand même une sacrée différence avec un NetApp.

 

Ceci dit, même si on m'offrait un NetApp pour chez moi au prix du Syno, je ne le prendrais pas car le NetApp ne fait que le NAS. Pas d'Apps, pas de VPN, pas (à ma connaissance) de VM, de Cloud Station (ça, bien utilisé, c'est génial), etc.

Lien vers le commentaire
Partager sur d’autres sites

Ca me fait rager parce que les pass ont planté deux fois (sur chaque disque) depuis le départ.

 

Apparemment pb de mémoire / stabilité badblocks ?? …

 

Je vais donc lancer un pattern à la fois, avec écriture sur une clé usb externe (fichier + sortie erreur) …

 

Parce que le résultat n'est donné qu'à la fin des 4 pattern …

 

--

 

C'était quoi les paramètres et la durée ? T'as le modèle 4 Go ?

 

--

 

Sur NAS Forum certains utilisateurs utilisent le paramètre -n au lieu du -w et prétendent que c'est suffisant.

Je ne sais pas quels sont leurs besoins mais je ne comprends pas trop la logique …

tous les cas 0 et 1 (combinaisons et changement d'état) ne sont pas vérifiés …

 

Est ce bien raisonnable de penser ainsi ?

 

Ils évoquent aussi l'utilisation abusive de la réallocation / réparation des blocs défectueux qui entamerait la durée de vie de disque.

Dire ça alors que les disques sont neufs ???

 

--

 

Par ailleurs, il existe un autre paramètre (-f) (non recommandé)

qui permet de forcer la commande (cf discussion avec badblocks bloqué sur DS918+).

Lien vers le commentaire
Partager sur d’autres sites

Je me cite :

 

Lancer la "fameuse commande" : sudo ./screen /bin/sh -c '/usr/local/diskutils/sbin/badblocks -wv -b 4096 -c 4096 /dev/sdc > /root/badblocks_sdc.log 2>&1' 
 

 

C'est la commande que j'ai utilisée il y a 5 ans, l'an dernier et il y a 3 jours. Et elle fonctionne parfaitement. A l'occasion j'irai voir le rôle des paramètres -b et -c, mais je l'avais trouvée sur un site, essayée et adoptée telle quelle.

 

Oui, l'output, c'est quand les 4 passes sont terminées.

 

C'est le modèle 3 TB et ça a pris 2,5 j pour les 4 passes.

Lien vers le commentaire
Partager sur d’autres sites

Met le disque dans le Syno et réessaye avec la commande que je suggère, sans rien changer.

 

Tu ne touches à rien dans l'interface du Syno, c'est pas nécessaire.

 

Fait simple, c'est souvent ce qui marche le mieux.

 

Ah oui, et surtout le but de la commande screen c'est d'empêcher que le test ne s'interrompe si tu perds le shell.

Lien vers le commentaire
Partager sur d’autres sites

D'après ce lien, Les besoins en mémoire de badblocks sont proportionnels au nombre de blocs à tester simultanément en mode lecture-seule, à deux fois ce nombre en mode lecture-écriture, et à trois fois ce nombre en mode lecture-écriture non destructif.

 

Bref, le paramètre -c augmente l'efficacité de badblocks …

 

--

 

OK je vais faire ça avec le DS918+ … ce qui m'embête c'est que avec ces tailles de disques,

les essais coutent chers en temps  …

Lien vers le commentaire
Partager sur d’autres sites

C'est pour ça que je ne fais pas d'essais ;) Je le fais ou ... je ne le fais pas.

 

https://youtu.be/8U9X6I0xVNc?t=30s

 

Mais 4096 alors que le défaut, c'est 16 ne me parait pas trop bas.

 

En plus les problèmes mémoires que tu as sont visiblement liés alors pourquoi t'entêter et ne pas essayer 4096 comme je le suggère depuis le 1er post de la discussion ?

Lien vers le commentaire
Partager sur d’autres sites

C'est ce que je vais faire …

 

Seulement par expérience je préfère réfléchir et définir puis agir

plutôt que partir tete baisser … (je commence à me connaitre).

 

Ici il me semble que j'ai perdu …

 

nota : je dois vérifier 2 x 8 to de nouveau pour un client, je verrai bien (les autres tournent en ce moment).

Lien vers le commentaire
Partager sur d’autres sites

J'ai seulement pu lancer le test des 2 autres disques hier, mais grosse surprise au niveau des performances.

 

Temps pour écrire 0xaa sur la totalité du disque : 

D1 : 7h32  (baie 3)

D2 : 7h24  (baie 4)

D3 : 6h50  (baie 3)

D4 : 7h29  (baie 4)

 
Le disque 3 est quasi 10% plus rapide que les autres (42 minutes sur 410 minutes).
 
Comme vous le constatez, ce n'est pas une question de baie puisque sur le second cycle, le disque le plus rapide est dans la même baie que le plus lent du premier cycle.
 
Si un des 4 avait été beaucoup plus lent que les autres, je l'aurais laissé en dehors du raid. Ici, j'hésite mais je ne vois pas quelle utilité en tirer.
Lien vers le commentaire
Partager sur d’autres sites

Oui, ca y est c'est fait !

 

sur le second disque, essai non destructif :

sudo badblocks -nsv -b 4096 -c 5000 /dev/sdb > /home/liveuser/Desktop/sdb.log 2<&1

67:25:15 elapsed. (0/0/0 errors)100.00% done, 67:25:16 elapsed. (0/0/0 errors)done                                                 
Pass completed, 0 bad blocks found. (0/0/0 errors)

 

sur le premier disque, essai destructif : arrêt fin 3eme phase - 5 jours.

sudo badblocks -wv -b 4096 -c 50000 /dev/sda > /home/liveuser/Desktop/sda.log 2<&1

L'essai a été arrêté après la 3eme passe, aucun pb.

 

Puis j'ai lancé - après installation dans NAS de prod - la vérification d'intégrité sur le groupe de disque créé.

nota : oui j'en ai créé un pour voir.

 

La vérification est à 78% à cet instant.

 

-----

 

Prochaines étapes :

 

1 - transfert données / migration.

Je pars à blanc puisque l'ancien système de fichiers étant ext4

et choix de btrfs (gain de place / essai).

L'outil de migration n'est donc pas adapté pour cela (conserver données).

 

2 - essai d'un SSD en cache lecture & écriture.

 

5 VM à minima vont être installées …

donc le cache de lecture sera certainement un gain en chargement.

 

Pour l'écriture, j'ai moins de besoin (peu d'utilisateurs en parallèle).

 

3 - utilisation du banc d'essai sur dock USB dual disk (vérif. différence durée essai ).

Permettre de lancer indépendamment les badblocks, sans arrêter les autres essais encours …

 

Je pensais peut être par erreur que les essais avec disque interne seraient plus longs …

Nous verrons maintenant que je dispose d'éléments de {base|comparaison} ..

Lien vers le commentaire
Partager sur d’autres sites

 

Du coup, c'est le bon moment pour avoir les deux avec la même version de DSM et d'opérer le changement en douceur car je compte faire une simple translation des 4 disques actuels entre les machines.

BTRFS est le système de fichiers de l'avenir chez Synology; si je devais changer de machine, j'en profiterais en prenant un DS416play; mais ça oblige à repartir de zéro.

 

 

Tu as eu une riche idée d'attirer mon attention sur la dispo de ce nouveau file system chez Syno.

 

Je suis en train de migrer les données, de la manière la plus propre possible.

 

1) Etape 1 : créer un BTRFS sur le nouveau serveur et installer le paquet Snapshot Replication sur les deux machines

2) Etape 2 (optionnelle) si les shares (répertoire partagés) sont sur un volume ext4 actuellement, il faut s'arranger pour créer un volume BTRFS sur l'ancien NAS et déplacer les share à l'intérieur (c'est très facile, dans Control Panel / Shares)

3) Etape 3 : Sur l'ancien serveur, répliquer le share de l'ancien serveur vers le nouveau via l'outil Snapshot Replication. Le résultat est qu'un nouveau share en lecture seule est crée sur le nouveau serveur. Ce share contient toutes les données avec leurs dates d'accès etc.

4) Etape 4 : Sur le nouveau serveur, Aller dans le tab Recovery. Un bouton "Action" qui n'est habituellement pas présent apparait lorsque la réplication est terminée (et qu'aucune autre n'est en cours). Dans le bouton Action, cliquer sur la première option "Switchover". Le résultat est d'inverser le rôle des deux share. Celui en lecture seule se trouve désormais sur l'ancien NAS et le "maitre" qui peut être modifié se trouve sur le nouveau.

5) Attribuer les permissions sur le share du nouveau serveur.

6) Vous pouvez alors supprimer la réplication et vous disposez des données transférées. Vous pouvez aussi conserver la réplication et vos données seront sauvegardées.

Lien vers le commentaire
Partager sur d’autres sites

moi je me tâte sur la procédure …

 

- j'hésite entre migration comme tu l'évoques,

par contre il y a des conditions non … c'est pas comme avec le cluster HA ?

 

- l'utilisation de Synology Cloud Sync (il fait des oublies parfois),

ou autre outil de sauvegarde.

 

- et le bon vieux transfert à la main avec beyond compare ou assimilé …

avec un logiciel de reprise automatique de transfert etc …

 

Bref, je vais creuser avec Snapshot replicator parce que je vais l'utiliser avec les NAS clietns certainement.

Lien vers le commentaire
Partager sur d’autres sites

moi je me tâte sur la procédure …

 

- j'hésite entre migration comme tu l'évoques,

par contre il y a des conditions non … c'est pas comme avec le cluster HA ?

Conditions ? Aucune à part un BTRFS au départ et à l'arrivée.

 

moi je m- l'utilisation de Synology Cloud Sync (il fait des oublies parfois),

ou autre outil de sauvegarde.

Cloud Station & cie sont des gadgets plutôt. Ici, la réplication c'est vraiment une réplication totale, à l'identique d'une ressource.

 

En plus, c'est "LA" solution pour de la redondance des données entre 2 machines, chacune restant autonome. Et en cas de problème, tu promotes (le fameux Switchover). Evidemment statistiquement tu perds la moitié des données modifiées entre 2 réplications (comme avec un backup). Mais la on parle de disaster recovery. Au pire, tu laisses le répertoire en lecture seule.

 

moi je m- et le bon vieux transfert à la main avec beyond compare ou assimilé …

avec un logiciel de reprise automatique de transfert etc …

 

Bref, je vais creuser avec Snapshot replicator parce que je vais l'utiliser avec les NAS clietns certainement.

Tester la réplication, c'est l'adopter. En plus, le système te propose d'utiliser un média (comme un disque externe) pour la première synchronisation puisqu'en principe les suivantes sont beaucoup plus petites, n'étant constituées que des deltas.

 

Paradoxalement, je vais plus vite pour répliquer le TB d'un NAS à l'autre sur le même switch (tous les deux avec 2 câbles réseaux, en // mais pas en LAG) que pour déplacer le même TB d'un disque ext4 vers un BTRFS sur le même Syno (l'ancien ici évidemment). Il faut compter un peu plus de 4 heures de NAS à NAS et 8 heures sur le même NAS, toujours pour 1 TB.

Lien vers le commentaire
Partager sur d’autres sites

J'y faisais allusion dans ma dernière réponse, il y a deux choses que je n'ai pas réussi à migrer "proprement". Toutes deux ont un point commun, ce sont des fonctionnalités de Synology.

 

La première, ce sont les "homes" qui sont automatiquement crées par le système. J'avais activé l'option sur le nouveau serveur avant de la désactiver. Donc peut être ai-je "loupé" le coche, mais toujours est-il que lorsque par la suite, j'ai voulu synchroniser le share "homes" de l'ancien syno, il a crée un "homes-replicated" sur le nouveau. Et évidemment, pas moyen de le renommer en "homes"

 

La seconde, c'est un peu lié. J'ai en effet du repartir de zéro avec Cloud Station (alors que j'avais transféré le QuickConnectID sur la nouvelle machine).

 

Dernier détail, lors de la synchronisation, les utilisateurs déjà crée sur le nouveau syno et qui ont le même nom que sur l'ancien, ont directement accès avec les bonnes permissions sur les shares synchronisés.

Lien vers le commentaire
Partager sur d’autres sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Invité
Répondre à ce sujet…

×   Collé en tant que texte enrichi.   Coller en tant que texte brut à la place

  Seulement 75 émoticônes maximum sont autorisées.

×   Votre lien a été automatiquement intégré.   Afficher plutôt comme un lien

×   Votre contenu précédent a été rétabli.   Vider l’éditeur

×   Vous ne pouvez pas directement coller des images. Envoyez-les depuis votre ordinateur ou insérez-les depuis une URL.

Chargement



×
×
  • Créer...