Hypothese .....
3 serveur Virtuels : Virtuel_1, Virtuel_2 et Virtuel_3....
Seul le Virtuel_1 possède une ressource de type partage de fichier appelée
Share_1
Question : Comment ce fait-il que la ressource Share_1 est visible (et
connectable) de tous les serveurs virtuels tournants sur le même noeud
physique que le Virtuel_1
Donc : Possibilité de problème si on fait un mappage permanent de
\\Virtuel_2\Share_1 et que les 2 vituels sont ensuite séparés sur des noeuds
phyisques différents car à ce moment.... Share_1 ne sera visible que des
virtuels tournants sur le même noeud que Virtuel_1
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
Jacques Barathon [MS]
Problème connu depuis les débuts du cluster sous NT4 (ah, Wolfpack...) lié sans doute au fait que tous les serveurs virtuels hébergé par un noeud du cluster reposent sur une instance unique du service Server. L'accès virtuel_1 ou à virtuel_2 donne donc les mêmes résultats.
A ma connaissance il n'y a toujours pas de solution. Il faut donc faire attention à utiliser une liste unique de partages sur l'ensemble des serveurs virtuels du cluster, et pas seulement ceux qui sont par défaut sur un même noeud physique car il faut gérer les conflits éventuels en cas de bascule d'un noeud à l'autre.
Une solution de contournement pourrait consister à utiliser DFS dont les liens de premier niveau seraient les noms des serveurs virtuels. Les partages apparaîtraient sous ces liens, et là je pense que la présence de noms similaires ne dérangerait pas. Mais cela rend la solution globale plus complexe à gérer.
Jacques
"Migxi" wrote in message news:
Hypothese ..... 3 serveur Virtuels : Virtuel_1, Virtuel_2 et Virtuel_3.... Seul le Virtuel_1 possède une ressource de type partage de fichier appelée Share_1
Question : Comment ce fait-il que la ressource Share_1 est visible (et connectable) de tous les serveurs virtuels tournants sur le même noeud physique que le Virtuel_1
Donc : Possibilité de problème si on fait un mappage permanent de Virtuel_2Share_1 et que les 2 vituels sont ensuite séparés sur des noeuds phyisques différents car à ce moment.... Share_1 ne sera visible que des virtuels tournants sur le même noeud que Virtuel_1
Problème connu depuis les débuts du cluster sous NT4 (ah, Wolfpack...) lié
sans doute au fait que tous les serveurs virtuels hébergé par un noeud du
cluster reposent sur une instance unique du service Server. L'accès
\virtuel_1 ou à \virtuel_2 donne donc les mêmes résultats.
A ma connaissance il n'y a toujours pas de solution. Il faut donc faire
attention à utiliser une liste unique de partages sur l'ensemble des
serveurs virtuels du cluster, et pas seulement ceux qui sont par défaut sur
un même noeud physique car il faut gérer les conflits éventuels en cas de
bascule d'un noeud à l'autre.
Une solution de contournement pourrait consister à utiliser DFS dont les
liens de premier niveau seraient les noms des serveurs virtuels. Les
partages apparaîtraient sous ces liens, et là je pense que la présence de
noms similaires ne dérangerait pas. Mais cela rend la solution globale plus
complexe à gérer.
Jacques
"Migxi" <Migxi@discussions.microsoft.com> wrote in message
news:1FBB528C-B855-4ADE-906F-7ABDF6E70DEE@microsoft.com...
Hypothese .....
3 serveur Virtuels : Virtuel_1, Virtuel_2 et Virtuel_3....
Seul le Virtuel_1 possède une ressource de type partage de fichier appelée
Share_1
Question : Comment ce fait-il que la ressource Share_1 est visible (et
connectable) de tous les serveurs virtuels tournants sur le même noeud
physique que le Virtuel_1
Donc : Possibilité de problème si on fait un mappage permanent de
\Virtuel_2Share_1 et que les 2 vituels sont ensuite séparés sur des
noeuds
phyisques différents car à ce moment.... Share_1 ne sera visible que des
virtuels tournants sur le même noeud que Virtuel_1
Problème connu depuis les débuts du cluster sous NT4 (ah, Wolfpack...) lié sans doute au fait que tous les serveurs virtuels hébergé par un noeud du cluster reposent sur une instance unique du service Server. L'accès virtuel_1 ou à virtuel_2 donne donc les mêmes résultats.
A ma connaissance il n'y a toujours pas de solution. Il faut donc faire attention à utiliser une liste unique de partages sur l'ensemble des serveurs virtuels du cluster, et pas seulement ceux qui sont par défaut sur un même noeud physique car il faut gérer les conflits éventuels en cas de bascule d'un noeud à l'autre.
Une solution de contournement pourrait consister à utiliser DFS dont les liens de premier niveau seraient les noms des serveurs virtuels. Les partages apparaîtraient sous ces liens, et là je pense que la présence de noms similaires ne dérangerait pas. Mais cela rend la solution globale plus complexe à gérer.
Jacques
"Migxi" wrote in message news:
Hypothese ..... 3 serveur Virtuels : Virtuel_1, Virtuel_2 et Virtuel_3.... Seul le Virtuel_1 possède une ressource de type partage de fichier appelée Share_1
Question : Comment ce fait-il que la ressource Share_1 est visible (et connectable) de tous les serveurs virtuels tournants sur le même noeud physique que le Virtuel_1
Donc : Possibilité de problème si on fait un mappage permanent de Virtuel_2Share_1 et que les 2 vituels sont ensuite séparés sur des noeuds phyisques différents car à ce moment.... Share_1 ne sera visible que des virtuels tournants sur le même noeud que Virtuel_1
Ludovik DOPIERALA
C'est comme avec Exchange 200x qui ne peut avoir que 4 groupes de stockage (50 dans E12) si un cluster actif / actif il y en a 3 sur chaque ... ça va poser un problème pour redémarrer les services sur le second... -- Ludovik DOPIERALA http://www.c2points.com MCSE, MCT Microsoft MVP Windows System - Infrastructure Architect CCEA Citrix Metaframe
Problème connu depuis les débuts du cluster sous NT4 (ah, Wolfpack...) lié sans doute au fait que tous les serveurs virtuels hébergé par un noeud du cluster reposent sur une instance unique du service Server. L'accès virtuel_1 ou à virtuel_2 donne donc les mêmes résultats.
A ma connaissance il n'y a toujours pas de solution. Il faut donc faire attention à utiliser une liste unique de partages sur l'ensemble des serveurs virtuels du cluster, et pas seulement ceux qui sont par défaut sur un même noeud physique car il faut gérer les conflits éventuels en cas de bascule d'un noeud à l'autre.
Une solution de contournement pourrait consister à utiliser DFS dont les liens de premier niveau seraient les noms des serveurs virtuels. Les partages apparaîtraient sous ces liens, et là je pense que la présence de noms similaires ne dérangerait pas. Mais cela rend la solution globale plus complexe à gérer.
Jacques
"Migxi" wrote in message news:
Hypothese ..... 3 serveur Virtuels : Virtuel_1, Virtuel_2 et Virtuel_3.... Seul le Virtuel_1 possède une ressource de type partage de fichier appelée Share_1
Question : Comment ce fait-il que la ressource Share_1 est visible (et connectable) de tous les serveurs virtuels tournants sur le même noeud physique que le Virtuel_1
Donc : Possibilité de problème si on fait un mappage permanent de Virtuel_2Share_1 et que les 2 vituels sont ensuite séparés sur des noeuds phyisques différents car à ce moment.... Share_1 ne sera visible que des virtuels tournants sur le même noeud que Virtuel_1
C'est comme avec Exchange 200x qui ne peut avoir que 4 groupes de stockage
(50 dans E12) si un cluster actif / actif il y en a 3 sur chaque ... ça va
poser un problème pour redémarrer les services sur le second...
--
Ludovik DOPIERALA
http://www.c2points.com
MCSE, MCT Microsoft
MVP Windows System - Infrastructure Architect
CCEA Citrix Metaframe
Problème connu depuis les débuts du cluster sous NT4 (ah, Wolfpack...) lié
sans doute au fait que tous les serveurs virtuels hébergé par un noeud du
cluster reposent sur une instance unique du service Server. L'accès
\virtuel_1 ou à \virtuel_2 donne donc les mêmes résultats.
A ma connaissance il n'y a toujours pas de solution. Il faut donc faire
attention à utiliser une liste unique de partages sur l'ensemble des
serveurs virtuels du cluster, et pas seulement ceux qui sont par défaut sur
un même noeud physique car il faut gérer les conflits éventuels en cas de
bascule d'un noeud à l'autre.
Une solution de contournement pourrait consister à utiliser DFS dont les
liens de premier niveau seraient les noms des serveurs virtuels. Les
partages apparaîtraient sous ces liens, et là je pense que la présence de
noms similaires ne dérangerait pas. Mais cela rend la solution globale plus
complexe à gérer.
Jacques
"Migxi" <Migxi@discussions.microsoft.com> wrote in message
news:1FBB528C-B855-4ADE-906F-7ABDF6E70DEE@microsoft.com...
Hypothese .....
3 serveur Virtuels : Virtuel_1, Virtuel_2 et Virtuel_3....
Seul le Virtuel_1 possède une ressource de type partage de fichier appelée
Share_1
Question : Comment ce fait-il que la ressource Share_1 est visible (et
connectable) de tous les serveurs virtuels tournants sur le même noeud
physique que le Virtuel_1
Donc : Possibilité de problème si on fait un mappage permanent de
\Virtuel_2Share_1 et que les 2 vituels sont ensuite séparés sur des
noeuds
phyisques différents car à ce moment.... Share_1 ne sera visible que des
virtuels tournants sur le même noeud que Virtuel_1
C'est comme avec Exchange 200x qui ne peut avoir que 4 groupes de stockage (50 dans E12) si un cluster actif / actif il y en a 3 sur chaque ... ça va poser un problème pour redémarrer les services sur le second... -- Ludovik DOPIERALA http://www.c2points.com MCSE, MCT Microsoft MVP Windows System - Infrastructure Architect CCEA Citrix Metaframe
Problème connu depuis les débuts du cluster sous NT4 (ah, Wolfpack...) lié sans doute au fait que tous les serveurs virtuels hébergé par un noeud du cluster reposent sur une instance unique du service Server. L'accès virtuel_1 ou à virtuel_2 donne donc les mêmes résultats.
A ma connaissance il n'y a toujours pas de solution. Il faut donc faire attention à utiliser une liste unique de partages sur l'ensemble des serveurs virtuels du cluster, et pas seulement ceux qui sont par défaut sur un même noeud physique car il faut gérer les conflits éventuels en cas de bascule d'un noeud à l'autre.
Une solution de contournement pourrait consister à utiliser DFS dont les liens de premier niveau seraient les noms des serveurs virtuels. Les partages apparaîtraient sous ces liens, et là je pense que la présence de noms similaires ne dérangerait pas. Mais cela rend la solution globale plus complexe à gérer.
Jacques
"Migxi" wrote in message news:
Hypothese ..... 3 serveur Virtuels : Virtuel_1, Virtuel_2 et Virtuel_3.... Seul le Virtuel_1 possède une ressource de type partage de fichier appelée Share_1
Question : Comment ce fait-il que la ressource Share_1 est visible (et connectable) de tous les serveurs virtuels tournants sur le même noeud physique que le Virtuel_1
Donc : Possibilité de problème si on fait un mappage permanent de Virtuel_2Share_1 et que les 2 vituels sont ensuite séparés sur des noeuds phyisques différents car à ce moment.... Share_1 ne sera visible que des virtuels tournants sur le même noeud que Virtuel_1
