Configuration NAS Synology

[Sethenès]

il y a 1 minute, Fromgardens a dit :

Mais je ne comprends pas pourquoi un NAS derrière chaque poste puis NAS central ?

 

A la place d'un disque USB.

[pehache]

il y a 14 minutes, Sethenès a dit :

Oui, je trouve. Dans l'absolu bien sûr. Je pense ici bien sûr au cas du professionnel qui utilise soit des disques USBs ou TB pour stocker ses documents de travail.

SI tu as un portable par exemple, tu dois forcément "schéduler" les backups des disques externes pendant la journée, via ton ordinateur principal.

Mais il est vrai que dans mon idée d'origine, c'était plutôt d'avoir de petits NAS tb3 dédié pour chaque collaborateur, et ensuite un gros NAS central qui joue le rôle de serveur, de backup et d'archivage.

L'arrivée du TB3 et du réseau 10 Gbit diminue un peu l'utilité puisqu'il faut trop de disques et du coup, le prix d'une telle solution explose.

Le prix de l'équipement, et la complication de l'administration de l'ensemble (et donc le coût associé)...

La solution rationnelle ce sont des stations de travail fixes, qui ont accès à un NAS pour centraliser/backuper les données, et qui ont les disques internes/externes qu'il faut pour les besoins de travaux en local qui exigent un accès disque rapide.

 

[Sethenès]

Peut être.

N'empêche que si ça avait existé chez Syno, si je n'avais pas déjà un second NAS et si j'avais acheté le Mac Mini, je me serais acheté un second NAS comme ça.

J'aurais eu l'équivalent d'une connexion 10 Gbit sans acheté ni l'upgrade du Mac Mini, ni le switch, ni un NAS 10 Gbit pour le prix d'un câble TB3.

Et ceci dit, je ne dois pas être le seul à penser que c'est utile puisque ... https://www.ldlc.com/fr-be/informatique/reseau/serveur-nas/c4314/+fv17-14154.html

[pehache]

Il y a 2 heures, Sethenès a dit :

N'empêche que si ça avait existé chez Syno, si je n'avais pas déjà un second NAS et si j'avais acheté le Mac Mini, je me serais acheté un second NAS comme ça.

J'aurais eu l'équivalent d'une connexion 10 Gbit sans acheté ni l'upgrade du Mac Mini, ni le switch, ni un NAS 10 Gbit pour le prix d'un câble TB3.

Ca en fait des "si" !!!

Sérieusement, un boîtier TB (ou même USB3 si c'est pour des HDD) sur le Mini ça irait très bien. L'argument du backup qui oblige à laisser le Mini allumé me parait bien faible par rapport au surcoût d'un NAS supplémentaire...

[Sethenès]

il y a une heure, pehache a dit :

Ca en fait des "si" !!!

Sérieusement, un boîtier TB (ou même USB3 si c'est pour des HDD) sur le Mini ça irait très bien. L'argument du backup qui oblige à laisser le Mini allumé me parait bien faible par rapport au surcoût d'un NAS supplémentaire...

Je comprends que ça n'intéresse, ni ne convienne à tout le monde. Mais à défaut de capacité de stockage suffisant dans une machine, je trouve ça une alternative intéressante.

C'est le meilleur des deux mondes : la rapidité du disque externe, la fiabilité et la souplesse du NAS.

[Sethenès]

Tout à l'heure, je lisais la news de Synology et je repensais à une autre conclusion à laquelle j'étais déjà parvenue.

Si DSM est vraiment bien pour le particulier, le "prosumer", le "pro" qui travaille seul et la PME, il y a quand même un fossé qui le sépare d'autres solutions pour grandes entreprises.

Je n'ai pas fait d'étude de marché et je n'ai donc aucune idée de l'écart de prix qu'il y a entre les grosses configs à base de Synology (16+ disques) et celles de ses concurrents "pro" comme NetApp ou EMC.

Je suis tombé sur une liste de prix de NetApp, qui indiquerait des configs 12 disques à un peu moins de 10000$, disques 8 TB compris - ou - pour le même prix des disques "high performance" de 1,2TB. Mais d'une part, il y a un service next business day pour leurs remplacements et il est possible d'avoir un monitoring (payant) en externe des disques et de la machine. Si la machine a un souci, il ne faut même pas appeler le technicien, il y en a un qui vient d'office avec le disque (ou n'importe quelle autre composant défectueux) de remplacement le prochain jour ouvrable qui suit celui où la panne est détectée par le monitoring. 

En comparaison un "beau" Synology 12 disques est à 2500 avec des disques 7200 de 8 TB, cela revient (hors taxe) à 5700 euros. Donc l'un dans l'autre, à la moitié du prix, mais sans service. Donc avec service, il est probable que la tension sur le prix soit largement supérieure à un facteur 2.

Mais dans un environnement en grande entreprise, je n'opterais pas pour du Syno (sauf pour des petits serveurs comme la gestion des caméras de surveillance par exemple).

Même l'interface du DSM a quelque chose de "gadget", même s'ils ont fait des efforts. A la limite, ils devraient presque scinder le DSM en 2 versions, une consumer et une pro.

Heureusement, ils ne le font pas - mais - il y a quand même un début avec l'apparition de certains programmes à licence payante mais ce sont des fonctionnalités qui ne sont utiles que si on gère un parc de plusieurs (dizaines) de Syno.

Modifié 14 décembre 2018 par Sethenès

[pehache]

Il y a 16 heures, Sethenès a dit :

Tout à l'heure, je lisais la news de Synology et je repensais à une autre conclusion à laquelle j'étais déjà parvenue.

Si DSM est vraiment bien pour le particulier, le "prosumer", le "pro" qui travaille seul et la PME, il y a quand même un fossé qui le sépare d'autres solutions pour grandes entreprises.

Ah mais c'est clairement orienté particulier/TPE/PME (même s'ils commencent à avoir des modèles qui titillent les grands comptes). Le wiki d'ailleurs le dit "Sa mission est de fournir des fonctionnalités jusqu'alors réservées aux grandes entreprises à des coûts abordables et utilisables pour les petites entreprises." L'interface n'est pas trop gadget je trouve, je la trouve même plutôt bien foutue, et le but est visiblement qu'elle soit utilisable même par des gens n'ayant que des compétences limitées dans le domaine. Après c'est sûr qu'elle intègre des truc dont une entreprise n'a que faire.

[pehache]

L'astuce du jour : l'accès SSH est normalement restreint aux administrateurs du Syno. Pour activer l'accès SSH pour n'importe quel autre utilisateur, il suffit de remplacer dans /etc/passwd la chaîne "/sbin/nologin" par "/bin/sh" sur la ligne de l'utilisateur concerné.

Il faut néanmoins le refaire à chaque reboot du NAS, mais ça peut s'automatiser : https://andidittrich.de/2016/03/howto-re-enable-scpssh-login-on-synology-dsm-6-0-for-non-admin-users.html

[LolYangccool]

Donner un accès SSH à des utilisateurs non admin, ça me parait moyen niveau sécurité...

sudo rm -Rf /*

entre autres

...

Modifié 17 décembre 2018 par LolYangccool

[pehache]

à l’instant, LolYangccool a dit :

Donner un accès SSH à des utilisateurs non admin, ça me parait moyen niveau sécurité...

Si les permissions de ces utilisateurs sont correctement définies, je ne vois pas trop où est le problème. Mais j'avoue que la définition des permissions unix sur les fichiers utilisateurs du Syno est plutôt, euh, étrange... tout est en 777 partout (?!). Il n'y a que les dossiers systèmes qui sont correctement définis. Donc effectivement ça pose problème du coup.

[pehache]

Bon, en fait je n'ai pas besoin de donner un accès SSH aux utilisateurs : le but c'est de faire un montage de dossier partagé par SSHFS, mais pour ça il suffit que l'utilisateur ait accès à SFTP (et pour SFTP il n'y a aucune restriction aux administrateurs).

[pehache]

Il y a 15 heures, LolYangccool a dit :

Donner un accès SSH à des utilisateurs non admin, ça me parait moyen niveau sécurité...

sudo rm -Rf /*

entre autres

...

Pour préciser : par définition si l'utilisateur n'est pas admin, une commande de ce genre sur un machine unix classique n'aura pour effet que d'effacer ses propres fichiers à lui.

Sur le Syno ça pourrait aussi effacer tous les fichiers des autres utilisateurs, vu qu'ils sont tous en permissions 777... Mais en fait je me demande si les permissions ne sont tout simplement pas gérées par des ACL indépendantes des permissions unix. Auquel cas l'effacement ne serait pas possible non plus (je n'ai pas testé).

[Sethenès]

Il y a 2 heures, pehache a dit :

Sur le Syno ça pourrait aussi effacer tous les fichiers des autres utilisateurs, vu qu'ils sont tous en permissions 777... Mais en fait je me demande si les permissions ne sont tout simplement pas gérées par des ACL indépendantes des permissions unix. Auquel cas l'effacement ne serait pas possible non plus (je n'ai pas testé).

C'est le problème qu'ont toutes les solutions de partage. Ce qu'on fait dans la majorité des cas, c'est de mettre les permissions sur les shares. Et dans ce cas, il vaut mieux laisser tous les fichiers en accès libre, sinon tu as des catastrophes quand un utilisateur déplace un fichier d'un endroit à un autre (avec une copie, tu crées un nouveau fichier qui hérite donc de ceux du répertoire parent, avec un déplacement, le fichier garde ses droits d'origine). Idem évidemment pour des répertoires entier où tu as des personnes qui ne devraient pas avoir accès et qui y ont accès, ou l'inverse. Et ce, sans aucune logique, tu dois reparcourir tout l'arbre pour détecter les erreurs.

J'ai eu comme ça des directoires "zombies" sur un NetApp, parce qu'on m'avait obligé à donner les droits d'admin sur les fichiers à un groupe d'utilisateurs. Ils m'avaient tellement bien coupé tous les accès, qu'il n'y avait même plus de backup. Et que je ne pouvais même plus enlever ces répertoires. Il y avait probablement moyen de se connecter avec un shell comme "superadmin", mais les répertoires étant vide, j'ai laissé pisser.

Et si on travaille avec des permissions sur les shares, alors il ne faut surtout pas donner des accès aux utilisateurs sur la machine Unix elle même. Enfin, si on veut être "bullet proof" à court et à long terme (c'est typiquement le piège à con, ou trois ans après, tu as oublié une subtilité et tu te dis, ça pas de prob', et puis ça te pète en pleine figure).

Modifié 18 décembre 2018 par Sethenès

[pehache]

Le 01/12/2018 à 16:47, LolYangccool a dit :

Bin tu as un serveur Apache disponible hein donc c’est possible. Tu installes un serveur web (Web station) et avec un .htaccess contenant un Options -Indexes tu auras accès au contenu du dossier dans lequel il sera placé comme sur n’importe quel serveur Apache.

Il y a des trucs qui m'échappent dans Web Station.

J'ai installé le paquet, et du coup sur le port 80 j'ai une page qui dit "Web Station has been enabled. To finish setting up your website, please see the "Web Service" section of DSM Help."

Je vais dans la config de Web Station, et déjà je ne comprends pas pourquoi il faut absolument installer Apache et PHP alors qu'il y a déjà nginx, pour activer les sites sites web perso. Bon, j'installe... Je vais ensuite dans "Virtual Host" et je crée une entrée qui pointe sur un dossier partagé, en choisissant "basé sur le port" : ca marche, sauf que je ne peux pas choisir le port 80, il me dit qu'il est déjà utilisé. Comment faire pour utiliser le port 80 ?

 

[pehache]

il y a une heure, pehache a dit :

Il y a des trucs qui m'échappent dans Web Station.

J'ai installé le paquet, et du coup sur le port 80 j'ai une page qui dit "Web Station has been enabled. To finish setting up your website, please see the "Web Service" section of DSM Help."

Je vais dans la config de Web Station, et déjà je ne comprends pas pourquoi il faut absolument installer Apache et PHP alors qu'il y a déjà nginx, pour activer les sites sites web perso. Bon, j'installe... Je vais ensuite dans "Virtual Host" et je crée une entrée qui pointe sur un dossier partagé, en choisissant "basé sur le port" : ca marche, sauf que je ne peux pas choisir le port 80, il me dit qu'il est déjà utilisé. Comment faire pour utiliser le port 80 ?

OK, j'ai compris... Pas besoin d'activer les sites persos en fait, et du coup pas besoin d'installer Apache et PHP... Par contre le port 80 est bel et bien réservé par la config de base de nginx. On peut s'en tirer en définissant le VirtualHost par un nom d'hôte au lieu d'un port, ou en redirigeant le port 80 du routeur sur le port du VirtualHost.

[Sethenès]

Jusqu'ici, j'étais resté à la 6.1 car j'avais lu qu'il y avait une "dégradation" de Cloud Station Drive quand on passait à la 6.2 et qu'on serait forcé de passer à Drive., j'ai

Ces infos dataient de la bêta, mais malgré quelques recherches, je n'avais pas pu en apprendre davantage, donc, dans le doute ...

Mais il y a quelques temps, je me suis dit : "tiens pourquoi ne pas créer une machine virtuelle 6.2 afin de tester ?". Evidemment, rien ne garantissait qu'on puisse installer une VM 6.2 sur une installation 6.1 ... mais ça marche.

Premier effet "Kisscool", j'ai vu avec intérêt que Cloud Station Drive existe toujours sur la 6.2. Ce n'est que si on installe Drive que celle-ci est écrasée (il y a même une mise en garde  que cette opération n'est pas réversible).

Sur le VM de test, j'ai fait cet upgrade ... et second effet "Kisscool", j'ai cloné une machine virtuelle windows et j'ai pu tester la connexion Drive depuis la VM Windows vers la VM Synology.

Effectivement, ça fonctionne et Drive semble remplir les mêmes fonctions que Cloud Station Drive.

Malgré tout, j'ai choisi de rester avec Cloud Station Drive encore un moment, tellement cette fonctionnalité m'est devenue indispensable.

Mais ... j'ai procédé à l'upgrade du Syno Backup avant hier (ça peut paraitre bizarre, mais il est toujours conseillé d'avoir la version la plus à jour sur la machine "destination" plutôt que sur la machine "source").

C'est vraiment génial ces VM. Maintenant, c'est sûr, à chaque nouvelle version majeure, je ferai une machine de test.

[LolYangccool]

il y a une heure, Sethenès a dit :

Malgré tout, j'ai choisi de rester avec Cloud Station Drive encore un moment, tellement cette fonctionnalité m'est devenue indispensable.

Je suis passé assez vite sur Drive et je l'utilise aussi énormément cette fonction, elle m'est également indispensable, je vois pas en quoi le côté indispensable de CloudStation Drive disparait avec Synology Drive.

En revanche, à l'utilisation, je ne vois pas de différences entre les deux. La fonction interface web ne me servant pas.

Modifié 26 décembre 2018 par LolYangccool

[Sethenès]

Bon ... une petite déception avec Synology ... une fois n'est pas coutume, mais autant le savoir.

J'avais un disque avec un comportement bizarre mais comme il s'agissait que d'alertes, je n'ai pas remplacé par un spare et j'en ai commandé un nouveau. Entretemps, il y avait un bad block sur le disque et je l'ai remplacé. Bon, évidemment, je n'ai pas pu faire un check de surface vu que ça prend 1j / TB et que je ne voulais pas avoir un Raid dégradé pendant 3 jours. Le Raid fonctionnait parfaitement malgré le bad block, mais lorsque j'ai remplacé le disque problématique, le Raid est tout à fait logiquement passé en mode dégradé. Pour la petite histoire, il a fallu 9h30 pour la reconstruction d'un disque (5400 tpm) de 3 TB.

J'ai profité de la commande pour m'offrir un SSD en cache, puisque c'est une option sur le 918+.

Mais quelle ne fut pas ma déception en constatant qu'on ne peut associer le SSD qu'à un seul volume !

Avant j'avais ... 16 volumes ... depuis l'achat du second Syno, j'ai été plus raisonnable et je n'ai plus que 6 volumes (bon d'accord, il y en a 8 sur le second NAS ...).

Mais à minima, j'aurais bien voulu faire du caching sur 3 volumes au moins ! Ici, je ne peux en choisir qu'un seul

En plus, ce qui est ridicule, c'est que :

1. ce n'est pas clairement expliqué
2. il y a un assistant qui permet d'analyser la juste place
3. il y a moyen de n'allouer qu'une partie du SSD.

Mais une fois le SSD associé à un volume, plus moyen de créer d'autres caches.

Et ces fonctionnalités, je pouvais les tester sans le SSD (enfin tout sauf créer le cache et voir qu'après on ne pouvait plus créer de cache sur d'autres volumes !). J'ai vraiment été induit en erreur et je n'ai jamais pensé à une limitation pareille.

[pehache]

Oui, c'est un peu con comme limitation... C'est récent comme fonctionnalité ? Si oui, j'imagine que ce sera amélioré dans les versions à venir.

[Sethenès]

il y a 48 minutes, pehache a dit :

Oui, c'est un peu con comme limitation... C'est récent comme fonctionnalité ? Si oui, j'imagine que ce sera amélioré dans les versions à venir.

Je ne sais pas trop en fait, car je suspecte que ça existait déjà sur des plus gros modèles.

En plus, si ça avait été de "disque à disque", j'aurais compris. Un caching d'un disque SSD "entier" sur un disque HDD peut à la limite avoir un sens.

Mais ne limiter ça qu'à un volume car Il suffirait de partitionner le SSD et d'associer chaque partition à un volume particulier.

Je vais ouvrir un ticket en mode "naïf" je pense.

Soyons de bon compte, en tant qu'utilisateur unique, le caching ne va (évidemment) pas m'apporter grand chose. J'en étais bien conscient d'ailleurs.

De toute manière, je voulais me limiter au caching en lecture car en écriture, ça devient nettement plus tendu en cas de blème. Et je pense que c'est ça la motivation principale. Ils ont peur d'avoir des m..... avec le caching en écriture. D'ailleurs, pour du caching en écriture, il faut 2 SSD mais contrairement à ce que je pensais un peu naïvement, ce n'est pas un pour la lecture et un pour l'écriture, c'est parce qu'ils créent un Raid 1 avec les 2 SSD pour augmenter la sécurité.

Sur certains forums et articles, d'aucuns suggèrent de déplacer les shares dans un même volume et d'utiliser des quotas. Mais je trouve ça vraiment une erreur. On perd un niveau de gestion. Et d'ailleurs, la première chose que je fais en me connectant au NAS, c'est de jeter un oeil à l'occupation des volumes.

Je trouve ça très "carré" : 

Modifié 8 janvier 2019 par Sethenès

[aexm]

@Sethenès: c'est marrant parce que je n'utilise pas du tout la notion de volume.

Je n'en vois pas / comprends pas l'intérêt.

Un intérêt existe si on a plus de 4 disques … donc monter plusieurs RAID pour différentes destination (par ex. RAID 5 + RAID 1)

Et la notion de dossier partagé suffit à mon utilisation.

---

Oui les fonctions du cache SSD sont relativement limitées. J’espérais que c'était un début et que les fonctions allaient arriver …

mais ce n'est pas le cas … J'ai également investi dans des SSD et le retour sur résultats est pas immense.

---

C'est assez cohérent … c'est un cache donc … et pas un volume.

On pourrait souhaiter quoi mettre en cache … par exemple un dossier partagé … mais non.

de toute façon, c'est un algo qui gère basiquement les données "chaudes" … rien de plus à mon avis …

En environnement concurrent, et bcp d'I/O par contre ca doit améliorer grandement les perf. (mais je n'ai pas pu faire ces essais).

----

Sinon, Oui les transferts de fichiers vont à fond (saturation du lien gigabit depuis un poste), dans les deux sens.

Mais mes équipements réseaux ne peuvent pas suivre (pourtant en agrégation de liens - ça bloque vers 120 - 150 mo/s) avec deux ordi..

nota : mais c'est un peu compliqué que ça (ca dépend de pas mal de paramètres aussi) …

En interne, le NAS monte  > 250 Mo/s de mémoire avec une VM. Faut que je vérifie avec d'autres pilotes …

cf mon article à ce sujet.

[Sethenès]

@aexm :

Pour moi le principal intérêt est de segmenter les données par genre et d'allouer l'espace disponible en fonction de ça. Avec pour principal effet qu'en cas de blème (un volume qui s'accroit anormalement), je ne peux pas avoir de "disk full" sur d'autres volumes.

Dans mon cas, si on repart du bas. Le volume 6 est dédié aux machines virtuelles, rien de particulier à ajouter.

Le volume 5 est réservé aux backups des PCs sous Windows et le 4 à celui des Macs.

Le volume 3 contient les données partagées (shares).

Le volume 2 est dédié aux données de paquets Syno comme les fichiers multimédias par exemple (paquet Media Server). Sur le NAS backup, c'est dans ce même volume que sont placés les enregistrements des caméras pilotées par video station (800 GB).

Le volume 1 est réservé aux paquets eux-mêmes et aux données que je ne peux pas déplacer vers le 2. C'est notamment la que Synology implante certaines DB comme par exemple celle de Cloud Station Backup. Attention, pas les fichiers eux-mêmes, mais la DB.

Comme tu l'as peut-être remarqué, les 3 volumes avec des données (j'exclus ici volume 1, volume 6 et le volume "quotas"), ne sont occupés qu'à moins de 50%. C'est totalement voulu, comme ça s'il y a des encryptions par des malwares ou des écrasements, il y a assez de place pour que les anciennes versions des fichiers soient sauvegardées.

Car évidemment, tous les shares sont protégés par des snapshots locaux et des snapshots répliqués sur l'autre NAS. Mais pour ça, il faut au minimum le double de place. Raison pour laquelle il y a 50% de libre. Actuellement, un peu moins de 70% de l'espace disque total est alloué aux volumes (5,5 TB alloués et 2,7 de libre).

Je n'ai pas énormément de données en "GB" mais elles me sont très précieuses et certaines ne datent pas d'hier :

 

Modifié 9 janvier 2019 par Sethenès

[LolYangccool]

Je ne vois pas non plus l’intérêt de faire ça avec des volumes, j’utilise les dossier partagés pour segmenter, c’est bien plus simple et ça divise pas physiquement ton disque (ou tes disques).

[pehache]

Il y a 11 heures, LolYangccool a dit :

Je ne vois pas non plus l’intérêt de faire ça avec des volumes, j’utilise les dossier partagés pour segmenter, c’est bien plus simple et ça divise pas physiquement ton disque (ou tes disques).

Ben déjà sur les modèles qui utilisent extfs4 et pas brtfs il n'est pas possible de mettre des quotas sur les dossiers partagés, mais uniquement sur les volumes.

Après, on peut vouloir appliquer des politiques de RAID différentes suivant les volumes.

Par ailleurs les volumes ne segmentent pas réellement physiquement le disque, ce sont des volumes logiques.

[Sethenès]

Je reconnais que contrairement aux "NAS" de NetApp, il n'est pas possible de réduire l'espace alloué à un volume sur un Syno. Dès lors, l'administration demande un peu plus de réflexion.

Mais rien n'empêche de déplacer temporairement des ressources d'un volume à un autre, de supprimer celui-ci et d'en recréer un. La seule condition est d'avoir assez d'espace libre, soit dans les volumes existants, soit de l'espace non alloué. Si je n'avais pas eu cette place, je n'aurais pas pu migrer mes filesystems de l'ancien NAS vers des B-Tree.

Je ne sais pas si vous voyez l'impact que ça a eu sur la migration des données de l'ancien NAS vers le nouveau.

Ici, la migration a été enfantine :

1. création d'une réplication des données sur le nouveau NAS. 
2. promotion de cette réplication comme maitre sur le nouveau NAS.

Et c'est tout ... et j'ai tout gardé, dates et heures des fichiers, date et heures d'accès aux fichiers, etc.

Et ça, je ne le savais pas en 2012 quand j'ai configuré l'ancien Syno.