XigmaNAS

Bonjour,

Ayant un ordinateur relativement puissant pour m'en servir à faire d'autres choses que de juste faire tourner NAS4Free, j'ai envisagé la solution de la virtualisation : ce qui en plus me permet de lancer à ma convenance le NAS.

Connaissant déjà (un peu) VirtualBox je me suis tourné vers ce logiciel multi-plateformes pour faire quelques essais il y a maintenant quelques mois.

J'ai donc essayé de virtualiser NAS4Free sous une Debian 7, et à ce que je me souvienne (et pense avoir compris) il faut ajouter chaque disque physique comme un disque utilisable dans (et par) la machine virtuelle créée ? Corrigez moi si je me trompe car je ne voudrais pas faire ou dire de bêtises. Mais alors, quelques chose me gêne à l'idée que VirtualBox devienne de ce fait incontournable pour lire les données des disques ? Je me trompe :

Comment seront stockées les données sur les disques et surtout pourrais-je revenir à une solution non virtualisée sans avoir à tout reformater et perdre toutes les données ?

Je me pose aussi la question pour passer dans l'autre sens : passer d'un NAS4Free non virtualisé déjà constitué et bien rempli à une version virtualisée sans perdre les données sur les disques ?

J'ai déjà pu tester avec succès le déplacement des disques sur une autre machine en important la configuration et les disques mais j'ai peur de louper quelque chose ou de me retrouver un jour coincé avec cette virtualisation.

Je tenterais bien simplement de faire le RAID directement sous Debian mais je ne sais pas si on peut faire un RAID-Z2 et j'apprécie bien l'interface graphique de NAS4Free notamment pour activer/désactiver facilement un service particulier à distance avec un smartphone : impossible en ligne de commande (ou alors moins intuitif pour moi) sur un smartphone ou une tablette.

Merci de votre aide.

Salut salut

Premier P2v V2p V2v

- Le P2V et V2P
Basculer des machines physiques vers de la virtualisation se fait très bien, en général c'est des environnements Windows en sources vers de Windows hyper-v ou de l'esxi de Vmware pour ne citer que ces deux la.
Il existe des applications plus ou moins gratuites et libre pour faire cela, on utilise des applications comme disk-to-vhd pour hyper-v qui vous permettra de virtualiser d'une machine complète à une partition donnée vers un disque ou machine virtuelle.
- V2V
La copie de Vm entre une solution identique ; hyper-v vers hyper-v ou même version de Vmware se fait simplement.
La copie de Vm d'une solution différente ; ex hyper-v vers Vmware ou autre se fait par des étapes intermédiaires avec des outils de migration assez bien conçu.

Dans le monde professionnel, le p2v se fait de plus en plus car les entreprise ont une forte pression financière pour diminuer leur empreinte carbone, et du coup font appellent à la virtualisation de toute ou partie systèmes d'information.
L'opération inverse le V2P se fait moins pour les raisons prés citées.
Par contre le V2V se fait très souvent voir couramment, ne serrais que dans les grands groupes ayant mis en place de clusteurs à basculement et ou à haute disponibilité qui copie des vm à la volé au grée des besoin, mais la migration de solution de l'éditeur x vers y se fait bien pour des environnements linux ou windows, pour les unix j'ai eu des soucis avec certain, et du bsd aussi donc là je resterait prudent, la meilleur solution pour ces cas la fut pour ma part de recréer les vm et de transférer les données via le réseau par le migration des structures des disques n'avaient été faite correctement et je me suis retrouvé avec un os migré corrompu.

Point suivant virtualiser un Nas

Les NAS sont des espace des stockages réseau qui sont prévus pour être mis en fonction h24/24 et j7/7 et 365j/ans et NE PAS ETRE stoppé tous les soirs pour être rallumés au matin, pour des raisons logique un serveur quelqu il soit n'aime pas etre stoppé à tout bout de champs, et matériellement à chaque redémarrage le serveur se prends un pic de tension sur tout les composant ce qui les fragilises à cour terme.
Par essence un nas n'est pas virtualisé car ils servent se qui est leur fonction première à recevoir des données plus ou moins grande et que suivant les applications qui vont stocker les données sur ces nas ont besoin de temps d'accès disques très cours la virtualisation augmente ces temps là.
De plus virtualiser un serveur de stockage demande de l'espaces de stockage ce qui est une aberration.
Nous avons plusieurs façon de faire avec les nas et la virtualisation.
- La première
Le disques virtuels et les vm sont intégralement créés sur les nas et seul l'hyperviser gère les ressources des vm au quel cas la nas est monté derrière le serveur de virtualisation, la je préconiserait une machine puissante cpu et ram pour la virtu, avec peu d'espace disque (os hyperviser + iso d'installation) et une machine peu puissante peu de ram et cpu low conso pour le stockage mais avec des controleurs raid et disque qui vont avec et la distribution qui vous voulez
- La deuxième
votre nas sert aussi bien héberger vos donnée partagé que vous vm, les configurations restent les mêmes sauf que le montage réseau diffère la les deux machines seront sur le même segment
- La troisième
Un mixte des deux, vous ajouté une carte réseau sur votre nas, une carte vers votre lan qui repondre à toutes les requetes d'accès à vous données partagées, et l'autre qui ne sera visible que par votre serveur de virtualisaiton par une emulation iscsi
- Le quatrièmement.
Le nas sert de stockage déporté des disques partagé des vm. Là c'est les os hébergé qui ont un lien iscsi vers le nas pour les partages de donnée.
- Le Cinquième ( mon préféré) la haute disponibilité
Pour ma part je suis sur une solution de virtualisation et stockage à haute disponibilité, la raison en est simple même avec un réseau électrique domestique stable, j'ai de temps en temps des fluctuations, et je dois aussi pouvoir intervenir sur une machine sans pour autant devoir arrêter toutes mes vm pour changer un disque ou de la ram par exemple. L'architecture matériel est simple 4 machine (2 pour virtu, 2 pour stockage de data) si je stoppe un serveur de virtu les vm sont automatiquement up sur le deuxième de manière presque transparente, si c'est l'un des nas que je coupe étant donné que je suis sur une synchronisation nas/nas du coté des hyperviseur cela est plus que transparent.


Dernier Point
Virtualiser un Nas ( le systèmes et les données) n'est pas une bonne chose, je ne le fait que pour réaliser des testes sur les fonctionnalités, mais sur tout pas en production.

Bonjour,

On peut tout à fait virtualiser N4F, cela ne pose pas de soucis.

Avant toute chose il faut savoir si votre machine est concue pour de la virtualisation (VT-x, Vt-d ?)
Une machine qui a été construite pour de la virtualisation a un écart (physique-virtuel) moins important qu'une machine n''ayant pas ce genre de fonction.

Quel volume voulez-vous traiter ? quel type de données, quel usage ?
Quel performance vous voulez ?

Pour ma part j'utilise désormais ZOL (ZfsOnLinux) qui est totalement compatible N4F/FreeBSD et intégré au noyau Linux. J'ai laissé tomber ZFS-fuse qui était instable et qui n'était pas compatible N4F.

J'ai une Debian 7 avec un LVM sur des disques SAS
J'ai aussi un disque SAS qui est utilisé directement par virtualbox en "physique" (pour avoir un N4F virtualisé "respectable")

Je travaille essentielement sur la déduplication et je déduplique avec un bi-xéon et je passe ensuite le travail avec zfs send sur les 775 qui seraient trop lent (j'utilise la déduplication pour du stockage)

Je n'ai pas fais l'essai de reprendre un disque "physique" virtualisé pour la debian directement, si vous pouvez faire l'essai, c'est bien, sinon, je peux faire l'essai ... un jour !

On peut faire "pleins de choses" et faire des tas de montages différents, ce n'est pas toujours facile de trouver son bonheur.
On peut faire du raid matériel, normal et virtuel.

Le tout est de rester simple, de pouvoir s'y retrouver en cas de clash.
Il faut bien positionner ses rsync, ses snapshots pour voir ou se trouve la sécurité parmis tout cela.
Il faut aussi comprendre ce que ZFS veut faire avec "sa machinerie", car son "moteur" doit être "bien placé" pour travailler correctement.

Qu'avez-vous comme machine puissante ? ... car tout est relatif

Bonjour,

J'ai fais les essais suivants sur ma machine perso

En fait, j'avais déjà sous la main, un disque de 300Go qui était utilisé sous vbox directement (par vboxmanage internalcommands createrawvmdk ...).
Il est utilisé par un N4F rev943 (virtualisé donc).

Je suis sous Linux/Debian "stable", c'est à dire la 7.x avec ZOL (ZfsOnLinux), j'ai débuté avec ZFS-fuse, mais ZOL est beaucoup mieux: directement intégré au noyau donc plus rapide, stable et surtout compatible avec N4F sans upgrade (ZFS-fuse est plus ancien et nécessité un "zpool upgrade" et est moins complet)

Sur le N4F virtualisé:
- destruction et re-création d'un pool "toto" (car il a eu été utilisé auparavant)
- ajout d'un fichier "toto.txt"
- arrêt de la mv

Sur le Linux (l'hôte):
- import du pool depuis Linux ... OK
- lecture du répertoire /toto ... OK (le fichier est bien là)
- état du pool ... OK
- copie du fichier toto.txt en titi.txt en le faisant plus gros
- export du pool

Sur le N4F virtualisé:
- lancement de la mv
- import du pool toto (je n'utilise jamais le webgui pour les pools, je fais tout à la main)
- lecture du répertoire ... OK
- copie de toto.txt en tutu.txt (en le faisant encore plus gros que titi.txt)
- arrêt de la mv

Sur le Linux (l'hôte):
- import du pool ... OK
- lecture du répertoire /toto ... OK (le fichier tutu.txt est bien là, en plus des autres)
- état du pool ... OK

Ensuite,
Sur le N4F virtualisé:
- lancement de la mv (N4F/943 pour rappel)
- destruction du pool "toto"
- ajout d'une cible iscsi "ztoto" en utilisant le disque en tant que périphérique direct
Sur le Linux (l'hôte):
- découverte de la cible depuis Linux ... OK (iscsiadm -m discovery -t sendtargets -p 192.168.0.221)
- login de la cible (iscsiadm -m node -T iqn.prout:ztoto -p 192.168.0.221 --login)
- import automatique des pools (depuis Linux) ... toto trouvé, toto importé ! ... donc OK
- lecture du répertoire toto ... les 3 fichiers sont là ... OK
- export du pool
- logout de la cible
Sur le Linux (l'hôte):
- import depuis Linux (listage des import possible) ... toto
- import de toto ... OK

Donc, en gros:
- on peut se faire une machine puissante, créer des pool sur un ou des disques, les utiliser depuis l'hôte
- les exporter
- lance une mv avec un N4F virtualisé et importer les disques
- les exporter
- importer les disques directement sur l'hôte

On peut aussi:
- mettre ses disques en iscsi
- les importer depuis un Linux ou un N4F, en réel ou en virtualisé, le tout est que les disques soit géré en "mode-bloc"

Coté performances (disque utilisé: Seagate Cheetah 15k7 SAS)
200Mo/s pour le disque directement sous Linux
157Mo/s sous vbox avec N4F virtualisé en utilisation directe en UFS
155Mo/s sous vbox avec N4F virtualisé en utilisation directe en ZFS
20Mo/s sous vbox avec N4F virtualisé en iscsi (attention la machine était occupée à d'autres tâches réseaux et l'iscsi a été loggé sur le réseau normal, il ne s'agit donc pas d'un essai de perfomances réel mais d'un test de fonctionnement)

Tout ceci pour dire que Linux en ZOL et N4F est totalement réversible* (localement et/ou en iscsi)

(*) Attention toutefois:
ceci est un essai, pour qu'il soit "complet" (démarche scientifique), il faudrait le refaire, plusieurs fois, avec des machines différentes et avec des "charges" diverses et avec des structures de pools variées (FS et raid/raidz)