Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Windows Windows 2000 Win 2000 Serveur Miroring de partage

Miroring de partage

5 réponses
Avatar
Dave
Salut :
Un de mes collaborateurs me dit qu'il est possible avec=20
windows 2000 serveur de mirorer un partage de mani=E8re =E0 ce=20
que si l'un des serveur tombe, l'autre le remplace, et ce=20
=E0 la vol=E9.=20
Excepter de faire un cluster sur une baie de disque=20
distincte, ou de gerer les partages via un acc=E9s Active=20
directory avec un systeme de copie de partage que je ne=20
connais pas, je vois pas de quoi ce collaborateur parle
Quelques pourrait il me rencarder la dessus ...
Merci
Signaler un problème avec ce contenu

5 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Avatar
Cyrille de Pardieu [MS]
Dans le post :b48301c3b8f3$d579aa30$,
Dave a dit :
Salut :
Un de mes collaborateurs me dit qu'il est possible avec
windows 2000 serveur de mirorer un partage de manière à ce
que si l'un des serveur tombe, l'autre le remplace, et ce
à la volé.
[...]

Quelques pourrait il me rencarder la dessus ...
Merci


Bonjour,

Votre collègue doit vous parler de DFS : Distributed File System.
Ce système permet de présenter un point unique de partage pour des shares
présents sur différentes machines. Histoire de simplifier la vie aux
utilisateurs. Pour faire court, vous créer une racine DFS qui aura, par
exemple, le nom du domaine (DFS de domaine) et dessous vous créer un lien
compta qui pointe sur le serveur de la compte, un partage rh qui pointe sur
un partage du serveur des RHs, etc...
Un des intérets de ce système est qu'on peut créer des réplicas d'un lien.
Ex : compta pointe sur compta1share1 et sur compta2share2.
DFS va automatiquement configurer le service FRS (File Replication System)
pour que le contenu de ces deux partages soient les mêmes. Ainsi si compta1
tombe, les données restent disponibles.
Cette option permet de gérer la notion de site. On met compta1 sur un site
et compta2 sur l'autre site et les utilisateurs se connecteront au serveur
le plus proche.

Plus d'informations sur
http://www.microsoft.com/WindowsServer2003/technologies/fileandprint/file/dfs/default.mspx

Cordialement
--
Cyrille de Pardieu
Ingénieur support
Equipe Plateforme / Domaine et sécurité
Microsoft France

Merci de poster vos questions sur ce forum afin que tous puissent
profiter des réponses qui sont données.
----------------------------------------------------------------

Avatar
Maurice POLARD
Bonjour,

Votre collègue doit vous parler de DFS : Distributed File System.
Ce système permet de présenter un point unique de partage pour des shares
présents sur différentes machines. Histoire de simplifier la vie aux
utilisateurs. Pour faire court, vous créer une racine DFS qui aura, par
exemple, le nom du domaine (DFS de domaine) et dessous vous créer un lien
compta qui pointe sur le serveur de la compte, un partage rh qui pointe
sur

un partage du serveur des RHs, etc...
Un des intérets de ce système est qu'on peut créer des réplicas d'un
lien.

Ex : compta pointe sur compta1share1 et sur compta2share2.
DFS va automatiquement configurer le service FRS (File Replication
System)

pour que le contenu de ces deux partages soient les mêmes. Ainsi si
compta1

tombe, les données restent disponibles.
Cette option permet de gérer la notion de site. On met compta1 sur un
site

et compta2 sur l'autre site et les utilisateurs se connecteront au
serveur

le plus proche.


Bonjour,

L'exemple que vous citez me semble inadéquat puisque les données comptables
se présentent généralement sous la forme d'informations stockées dans des
bases de données multiutilisateurs et relationnelles. Je ne crois pas que
DFS pourra gérer les cas où l'intégrité référentielle est importante. Dans
l'immédiat, il me semble que mettre en oeuvre ce type de tolérance au sein
d'un annuaire AD ne peut se concevoir que vis à vis de données
"mono-utilisateur" et "à plat"...

Je me trompe...

Cordialement,
Maurice POLARD

Avatar
Thierry Frache [MVP]
En effet. DFS est généralement utilisé pour diffuser une information
davantage en lecture seule (logiciels au travers des stratégies de groupe
par exemple). Explication: Si j'ai un document Word qui est répliqué sur
deux serveurs, je n'ai aucun moyen d'empêcher Alice d'écrire sur le document
depuis le serveur A tandis que Bob l'utilise également mais depuis le
serveur B (via sa réplique).

--
Cdlt,

Thierry Frache
MVP Windows Servers

"Maurice POLARD" a écrit dans le message de
news:
Bonjour,

Votre collègue doit vous parler de DFS : Distributed File System.
Ce système permet de présenter un point unique de partage pour des
shares


présents sur différentes machines. Histoire de simplifier la vie aux
utilisateurs. Pour faire court, vous créer une racine DFS qui aura, par
exemple, le nom du domaine (DFS de domaine) et dessous vous créer un
lien


compta qui pointe sur le serveur de la compte, un partage rh qui pointe
sur

un partage du serveur des RHs, etc...
Un des intérets de ce système est qu'on peut créer des réplicas d'un
lien.

Ex : compta pointe sur compta1share1 et sur compta2share2.
DFS va automatiquement configurer le service FRS (File Replication
System)

pour que le contenu de ces deux partages soient les mêmes. Ainsi si
compta1

tombe, les données restent disponibles.
Cette option permet de gérer la notion de site. On met compta1 sur un
site

et compta2 sur l'autre site et les utilisateurs se connecteront au
serveur

le plus proche.


Bonjour,

L'exemple que vous citez me semble inadéquat puisque les données
comptables

se présentent généralement sous la forme d'informations stockées dans des
bases de données multiutilisateurs et relationnelles. Je ne crois pas que
DFS pourra gérer les cas où l'intégrité référentielle est importante. Dans
l'immédiat, il me semble que mettre en oeuvre ce type de tolérance au sein
d'un annuaire AD ne peut se concevoir que vis à vis de données
"mono-utilisateur" et "à plat"...

Je me trompe...

Cordialement,
Maurice POLARD




Avatar
Dave
Merci de vos precieuses informations
Si donc je dois assurer de la redondance d'information, et
que je dois me mettre à l'abri d'un panne serveur, je me
trouve soit dans le cas ou (merci de me corriger):
Je positionne DFS, plusieurs pointeur sur des partage
différents, et rfs joue le réplicat, quid des synchro sur
BD et fichiers distinct en cas d'acces concomittant de
client différent ?
Soit, je joue le clustering.
Y aurait moyen de jouer le FRS et sans autoriser l'accés
sure l'un des partages et en cas de panne, du premier
partage, rendre transparent l'activation du second ...
Peut être que je rêve non ?

-----Message d'origine-----
En effet. DFS est généralement utilisé pour diffuser une
information

davantage en lecture seule (logiciels au travers des
stratégies de groupe

par exemple). Explication: Si j'ai un document Word qui
est répliqué sur

deux serveurs, je n'ai aucun moyen d'empêcher Alice
d'écrire sur le document

depuis le serveur A tandis que Bob l'utilise également
mais depuis le

serveur B (via sa réplique).

--
Cdlt,

Thierry Frache
MVP Windows Servers

"Maurice POLARD" a écrit
dans le message de

news:
Bonjour,

Votre collègue doit vous parler de DFS : Distributed
File System.



Ce système permet de présenter un point unique de
partage pour des



shares
présents sur différentes machines. Histoire de
simplifier la vie aux



utilisateurs. Pour faire court, vous créer une racine
DFS qui aura, par



exemple, le nom du domaine (DFS de domaine) et
dessous vous créer un



lien
compta qui pointe sur le serveur de la compte, un
partage rh qui pointe



sur
un partage du serveur des RHs, etc...
Un des intérets de ce système est qu'on peut créer
des réplicas d'un



lien.
Ex : compta pointe sur compta1share1 et sur
compta2share2.



DFS va automatiquement configurer le service FRS
(File Replication



System)
pour que le contenu de ces deux partages soient les
mêmes. Ainsi si



compta1
tombe, les données restent disponibles.
Cette option permet de gérer la notion de site. On
met compta1 sur un



site
et compta2 sur l'autre site et les utilisateurs se
connecteront au



serveur
le plus proche.


Bonjour,

L'exemple que vous citez me semble inadéquat puisque
les données


comptables
se présentent généralement sous la forme d'informations
stockées dans des


bases de données multiutilisateurs et relationnelles.
Je ne crois pas que


DFS pourra gérer les cas où l'intégrité référentielle
est importante. Dans


l'immédiat, il me semble que mettre en oeuvre ce type
de tolérance au sein


d'un annuaire AD ne peut se concevoir que vis à vis de
données


"mono-utilisateur" et "à plat"...

Je me trompe...

Cordialement,
Maurice POLARD




.





Avatar
Thierry Frache [MVP]
Euh. Si on considère qu'un client accède aux données du serveur le plus
proche (notion de site Active Directory), on pourrait considérer la création
d'un site logique (sur un réseau différent) essentiellement dédié à
l'hébergement d'une seconde réplique. N'ayant aucun client sur le site, cela
permettrait de s'assurer que personne ne travaille sur les fichiers à cet
emplacement. Sur le papier, ça me semble jouable.

"Dave" a écrit dans le message de
news: 005101c3b9b1$88f54070$
Merci de vos precieuses informations
Si donc je dois assurer de la redondance d'information, et
que je dois me mettre à l'abri d'un panne serveur, je me
trouve soit dans le cas ou (merci de me corriger):
Je positionne DFS, plusieurs pointeur sur des partage
différents, et rfs joue le réplicat, quid des synchro sur
BD et fichiers distinct en cas d'acces concomittant de
client différent ?
Soit, je joue le clustering.
Y aurait moyen de jouer le FRS et sans autoriser l'accés
sure l'un des partages et en cas de panne, du premier
partage, rendre transparent l'activation du second ...
Peut être que je rêve non ?

-----Message d'origine-----
En effet. DFS est généralement utilisé pour diffuser une
information

davantage en lecture seule (logiciels au travers des
stratégies de groupe

par exemple). Explication: Si j'ai un document Word qui
est répliqué sur

deux serveurs, je n'ai aucun moyen d'empêcher Alice
d'écrire sur le document

depuis le serveur A tandis que Bob l'utilise également
mais depuis le

serveur B (via sa réplique).

--
Cdlt,

Thierry Frache
MVP Windows Servers

"Maurice POLARD" a écrit
dans le message de

news:
Bonjour,

Votre collègue doit vous parler de DFS : Distributed
File System.



Ce système permet de présenter un point unique de
partage pour des



shares
présents sur différentes machines. Histoire de
simplifier la vie aux



utilisateurs. Pour faire court, vous créer une racine
DFS qui aura, par



exemple, le nom du domaine (DFS de domaine) et
dessous vous créer un



lien
compta qui pointe sur le serveur de la compte, un
partage rh qui pointe



sur
un partage du serveur des RHs, etc...
Un des intérets de ce système est qu'on peut créer
des réplicas d'un



lien.
Ex : compta pointe sur compta1share1 et sur
compta2share2.



DFS va automatiquement configurer le service FRS
(File Replication



System)
pour que le contenu de ces deux partages soient les
mêmes. Ainsi si



compta1
tombe, les données restent disponibles.
Cette option permet de gérer la notion de site. On
met compta1 sur un



site
et compta2 sur l'autre site et les utilisateurs se
connecteront au



serveur
le plus proche.


Bonjour,

L'exemple que vous citez me semble inadéquat puisque
les données


comptables
se présentent généralement sous la forme d'informations
stockées dans des


bases de données multiutilisateurs et relationnelles.
Je ne crois pas que


DFS pourra gérer les cas où l'intégrité référentielle
est importante. Dans


l'immédiat, il me semble que mettre en oeuvre ce type
de tolérance au sein


d'un annuaire AD ne peut se concevoir que vis à vis de
données


"mono-utilisateur" et "à plat"...

Je me trompe...

Cordialement,
Maurice POLARD




.