Partage Sur Un M

[HenriT]

Bonsoir,

premiers essais de ISCSI sur DS409+ II :

* Sous Win Seven en Virtual Machine : pas de pb, la SCSI target est toujours remontée au reboot avec les fichiers que l'on y a injectés ;

* Le même volume accédé à partir de deux PC sous XP : le disque ISCSI ne remonte pas après reboot : il est pourtant "actif" dans l'Initiator et présent dans le Disk Manager d'XP.

* Si l'on dépose des fichiers à partir d'un poste (XP ou Seven), ils ne sont pas toujours visibles par les autres postes connectés (droits d'accès ?)

* Si l'on a le malheur de changer, avec un autre poste, le nom d'un fichier déposé sur le ISCSI avec un premier poste, le fichier devient inutilisable.

Il n'y a pas de visibilité sur le volume ISCSI dans File Manager, ne permettant dons pas un back-up à partir des fonctions du SAN : mais c'est sans doute parce que l'on a le choix du format de ce volume virtuel, et que l'OS du SAN ne peut pas tout prévoir/accepter en matière de formats.

Je continue à creuser, mais apparemment le partage ISCSI paraît assez bogué.

Cdt

HT

[Invité Sum67]

Je continue à creuser, mais apparemment le partage ISCSI paraît assez bogué.

Ce n'est pas une question de bug c'est juste qu'iSCSI n'est pas fait pour partager des volumes dans la mesure où un volume iSCSI est en mode bloc et pas en mode fichier ce qui empêche des modifications par deux sources différentes...

C'est comme si vous demandiez à booter sur un même disque physique depuis deux PC différents : Ce n'est tout simplement pas possible car ce n'est pas pertinent.

[poppan]

C'est surtout que 7 utilise par defaut le ntfs et que le ntfs n'est pas un FS cluster aware.

Ca n'a honnetemment que peu d'interet en utilisation

[PatrickH]

Ca fait un peu "d

[deadlock80]

Bonjour

[Sp@r0]

Premi

[MS_Totor]

je crois qu'il doit râler après un autre modèle de matériel, et comme il a vu nas-forum, il s'exprime!...

par contre aucune idée dudit matériel donc tout cela ne sert pas à grand chose sans l'élément essentiel.........

je voulais faire cela, j'ai acheté ce matériel, mais je ne peux pas faire ce que je voulais

sans doute du malheureusement comme cela arrive souvent à une mauvaise étude préalable du fonctionnement des programmes désirés et le dimensionnement du besoin, cela entraine un cahier des charges faussé et aléatoire, donc une mauvaise connaissance réelle des capacités du matériel adapté et un mauvais achat au final ou une mauvaise utilisation...

idem que toi, je ne vois pas grand chose en commun entre ce propos et l'utilisation iscsi sur Nas synology, je m'en sert sur un 1010+ pour déporter mes os virtualisés, et il est clair que le débit lecture/écriture dans ce cas ne peut transiter en cpl mais en débit max, câble/switch adaptés au gigabit sinon cela ne vaut pas le coup.

suivant....

[deadlock80]

Premi

[MS_Totor]

bon je dois m'absenter...cela vas donc etre très rapide

déjà non tu n'as pas bien étudié ton projet ou trop vite à ce que je lis, tu as été obligé de passer par iscsi car tu ne sais pas faire autrement pour activer un partage entre linux et windows

commence par comprendre quelques éléments essentiels en usage réseau

ne jamais mettre tous œufs dans le même panier, hors tu mélange perso et boulot, un qnap ou un nas synology ne sert pas à une sauvegarde mais à un stockage redondant, idem cela doit bien etre assimilé, si tes données pro sont vitales, le qnap doit à son tour être sauvegardé via un DD externe usb ou esata, et en général pour y rajouter une couche un onduleur pour eviter toute perte du à une coupure de courant.

le partage réseau se comporte comme un lecteur supplémentaire à c: ou d: donc je ne vois pas ce qui empêche de travailler avec, rien si ce n'est une mauvaise connaissance de netbios ou du trafic nécessaire, ce sont des ports udp et tcp à laisser passer entre ton nas et ton pc, via réglage du firewall et des antivirus réseau ou tout autre gadget servant à bloquer ou filtrer etc...et partage windows activé si c'est des PC windows

connaissant les limites de iscsi, il est aberrant de laisser deux utilisateurs dont un novice se servir de cela sans contrôle

avoir tout sur iscsi est aussi à éviter, vu les contraintes de sauvegardes, c'est tout ou rien, , privilégie vu le niveau de connaissance "à priori" réseau l'apprentissage du partage réseau simple, sur le qnap tu dois pourvoir activer ces fonctions simplement, tu as un forum qnap dédié à ce genre de support

ne te prends pas la tête à pester, et potasse le partage réseau, dans mon profil tu as quelques trucs que j'ai mis à dispo sur nas synology, map de lecteurs réseau, et voisinage réseau tu peux largement t'en sortir avec en adaptant à ton matériel et son panel web d'administration.

je file

@++

[Sp@r0]

bon je dois m'absenter...cela vas donc etre tr

[deadlock80]

Merci pour ce retour rapide.

>>> "d

[Sp@r0]

De toute fa

[deadlock80]

"par principe un seul ordinateur peux le contr

[Sp@r0]

"par principe un seul ordinateur peux le contr

[MS_Totor]

et oui !

pour le reste je parie 10 kopec qu'il finira par faire ce qu'on lui conseille depuis le début, même si sa réticence est grande... ou alors il ne râle plus et assume ces choix et les risques liés à la gestion de ces données.

-1 utiliser isci pour un flux direct sur une partie de son taf seulement, celle dont il a besoin réellement et ponctuellement effectuer des transfert entre isci et partage réseau mappé en lecteur, en vérifiant bien entendu par un test d'abord que le débit en écriture et lecture est correct, sans goulet d'étranglement réseau, y compris la charge cpu/ram du nas, puisqu'il se plaint de latence...

-quel est le débit réel entre ces données et le traitement sur la station

-quel est le débit en lecture/écriture des ces DD sur le nas

-donc vérifier sur une courte période qu'il n'y a pas de perte de paquets, ou de saturation de flux à un débit trop faible pour du isci confortable, contrôler la qualité des câbles (cat 6), le switch (certifié gigabit)

-le reste en partage windows réseau et lecteur mappé, pour gérer ces sauvegardes incrémentielles et/ou différentielles, et séparer son taf de ses données perso, par des partages séparés et mappés en lecteurs séparés, droits sur ces partages pour éviter toutes sortes d' ennuis comme ceux qu'il a décrit...

c'est ce que j'ai fait comme test avant de coller des données en isci sur le 1010+ et c'est la gestion décrite dans ce propos que j'ai adopté et cela marche très bien..sur un raid1 + sauvegarde

[Dex]

-le reste en partage windows réseau et lecteur mappé, pour gérer ces sauvegardes incrémentielles et/ou différentielles, et séparer son taf de ses données perso, par des partages séparés et mappés en lecteurs séparés, droits sur ces partages pour éviter toutes sortes d' ennuis comme ceux qu'il a décrit...

Juste pour info, l'outil qu'il utilise (Acronis) ne permet pas la sauvegarde de lecteur mappés dans sa version de base, je ne sais pas ce qu'il en est pour les version pro.

Je n'y connais rien en ISCSI mais j'ai du mal à comprendre le concept :

"Pas tout à fait. Le iSCSI, lui, oui, il se comporte de la sorte. Le partage réseau fait transiter les données via http complété via une couche SAMBA ou autre."

A partir du moment ou les données ne sont pas sur le même point réseau les faire transiter d'un point à un autre nécessite forcement de les faire transiter via le reseau, je ne vois pas comment il pourrait en être autrement... Je passe la couche http qui n'a rien à faire ici.

Qu'ensuite on obtienne des différences de perf selon le protocole (samba, FTP, etc..), parfaitement OK.

" Le comportement est différent. Un logiciel capable de lire les fichiers (distants), vous double-cliquez dessus et votre fichier s'ouvre. C'est parfait mais ce type de logiciel est loin d'être la majorité."

Il faudrait préciser quel type de logiciel est utilisé, l'immense majorité des softs que j'utilise ne font pas la différence à 2 exceptions :

- True Image Home (du moins ma version) qui ne permet pas de sauvegarder des ressources reseau.

- Un antivirus qui nécessite une version payante pour scanner les répertoires réseau.

Tour les autres ne font aucune différence ou presque entre une partition de disque et un lecteur mappé.

" Pour le reste, vous double-cliquez dessus => soit il le télécharge en local avant de l'ouvrir, soit il ne l'ouvre pas (vous devez le downloader manuellement avant, soit il l'ouvre mais il faut aller chercher le dit fichier via le menu fichier > ouvrir URL ou fichier > ouvrir en pointant sur vos favoris réseau."

La je nage....

[MS_Totor]

isci pour SES APPLIS , bien je ne pense pas qu'il ait besoin de 900 go pour cela en isci ou alors il décrit un peu son taf et les applis qu'il utilise....

les données pour les applis sont traitées via le isci, le volume concerné sera sauvegardé par une opération de sauvegarde sur le nas, vers le dd usb, pas de possibilité de sauvegarde incrémentielle/différentielle, car on traite en block.

rien n'empêche de garder le reste de ces données en lecteur mappés, ou de les transférer chaque jour via un script, donc physiquement présente sur le nas et sur un volume normal, en raid1 ou pas etc..et là la sauvegarde sera directement faite via le gestionnaire du nas, selon les réglages effectués sur le nas, .incrémentielle/différentielle, vers le dd en esata ou usb

je répète voir mon profile ci dessous ou lire cela pour un texte basique

http://windows.micro...a-network-drive

sauvegarder un lecteur mappé avec acronis ? la question ne doit pas être posée....

car ces données sont présentes physiquement sur le nas et accessibles via le réseau et le n° de lecteur qui pointe dessus vu du PC, (mapage de lecteurs réseau cf google) donc si le nas lui même est en raid1 plus la sauvegarde externe....et un onduleur pour protéger le tout cela me semble raisonnable..

oui son propos sur url et samba est étrange et j'ai éludé directement, ou alors je ne saisis pas non plus ce qu'il fait ou veux expliquer par là, mais cela n'ayant rien à voir avec des lecteurs mappés, on peux se servir de lecteurs mappés ou de partages réseaux avec des applis client/serveur et heureusement.....

il y a bien deux volumes distincts, un volume crée et géré par le nas, en raid 1 ou pas, au format linux, comme sur nos syno et l'espace occupé par isci

je laisse la main , il y a bien d'autres avis qui trainent pour l'aider à mettre en place ce qu'il veut faire en mieux, avec d'autres variantes que celle que je propose, il y a tellement de possibilités avec ces petits nas

[MS_Totor]

up

soit le membre a trouv

[Sp@r0]

up

soit le membre a trouvé sa solution au final ou soit attends d'autres contres propositions

la solution abordée convient elle pour nos éminents membres, cela à but d'historique et pour les prochaines questions dans ce sens,

ou vous voyez bien mieux et plus simple à mettre en place

bonne soirée

Moi j'ai une contre proposition :

- du papier

- unstylo

- une photocopieuse

- un coffre à la banque pour les sauvegardes

:D

[MS_Totor]

Moi j'ai une contre proposition :

- du papier

- unstylo

- une photocopieuse

- un coffre

[Sp@r0]

waou ca c'est de la valeur ajout

[cricx]

Je crois que le vrai problème est bien lié à l'incompréhension de ce qu'est l'iscsi. Il ne s'agit pas d'un protocole de partage (pas plus de fichier que de disque), mais de transport de données et de commandes à un bas niveau, comparable à atapi pour les interfaces ide.

La manip faite (accéder à une même cible par deux "clients") revient à démonter un disque dur d'une machine pour le mettre sur une autre, en espérant que le bios comme le système d'exploitation, le système de fichiers iront le lire (et l'écrire) de la même manière que la première (sachant que l'accès est effectué à un bas niveau (blocs disque) dont très dépendant de nombreux paramètres, et sans prise en compte d'accès concurrents.

Les informaticiens qui ont étudié depuis des années le problème d'accès et de partage des données ont bien compris que cela passait nécessairement par une couche applicative supplémentaire (samba, nfs, afs ou autres systèmes de fichier réseau).

L'iscsi n'est absolument pas fait pour cela. Il faut voir un accès iscsi comme un disque branché physiquement à une machine.

Pour la petite histoire, la gestion calamiteuse du réseau par microsoft (souvenez-vous qu'il a inventé netbeui !) fait que certaines applications fonctionnent différemment sur un "mappage" réseau. Ce n'est pas le cas sur les systèmes unix/linux pour lesquelles un module (un driver) gère l'accès : cifs, nfs et les multiples modules fuse comme gmailfs [un compte gmail apparait comme un disque local], ou un simple montage dans l'arborescence permet l'accès natif au système de fichiers distant comme s'il était local.

Mais voilà, utiliser un protocole de manière inadaptée avec un système obsolète...

Un petit détail : la corruption a été probablement été provoquée par le poste client et pas par le nas. Il faudrait cependant rechercher un peu si ce n'est pas une corruption côté nas a provoqué cette perte de données (ce qui peut arriver même sans iscsi)

[Nounours44]

Bonjour,

pourrais-je avoir une explication de la page d'aide concernant l'iSCSI ?

Sessions multiples

Activez des sessions multiples pour permettre à plusieurs initiateurs de se connecter au même iSCSI target. Vou pouvez utiliser le système de fichiers de disque partagé pour éviter la corruption de fichiers et une perte de données inattendue.

Merci par avance.

[olivier78]

Bonjour,

pourrais-je avoir une explication de la page d'aide concernant l'iSCSI ?

Merci par avance.

Tres bonne question... Je me l'a suis pos

[xlockes]

Bonjour,

A mon avis c'est une option pour des cas tr