Bonjour,
 
Je me permets de venir chercher quelque conseils sur la migration des partages CIFS qui était géré dans l'infra jusqu'à présent via la baie et qui va maintenant l'être par une VM windows.
La vm est prête les robocopy ont été fait sur de nombreux fichiers qu'on avait sans aucun problème.
 
Cependant, nous avons des profils itinérants qui étaient stockés sur la baie. Lorsqu'un profil est en cours d'utilisation, on ne peut pas le copier.
 
Quelle solution préconisez vous pour ce genre d'opération ?
 
Pour l'instant la meilleure solution que j'ai est de lancer des robocopy la nuit en espérant du cou éviter d'avoir le plus d'erreur possible et pour les cas isolé les faire à la main le jour J en fermant la session  
faire le robocopy et réouvrir la session.
 
Je précise que le DFS est utilisé donc à priori le nom du serveur n'influence pas.
 
 
Autre question en rapport avec la vm serveur de fichier :
 
1) La baie n'aura pas la fonctionnalité de dédup activé car elle ne fonctionne pas bien à priori pour l'instant (unity 300) donc on pense à l'activer sur le serveur de fichier via windows. Je voudrais savoir si cela pose problème lorsqu'on sauvegarde ensuite la VM avec avamar qui lui fait des sauvegarde tous les jours et refait de la dédup derrière.  
 
2) La haute disponibilité de ce serveur risque d'arrivé bientot car une vm windows n'est pas ausssi solide qu'une baie netapp (l'ancienne donc ), aujourd'hui je suppose que c'est toujours le cluster qui est utilisé ?  
Dans notre cas vu qu'on fait du DFS je sais qu'on ne pourra pas avoir un cluster actif/actif (CSV si ma mémoire ne se trompe pas !)  
 
Derrière ce système de cluster, est ce qu'il y a des problèmes souvent parce qu'on a personne qui a de compétence la dedans, et si un soucis arrive au niveau du cluster, faut qu'on soit en mesure de trouver la solution rapidement.
 
De mon coté, je me souviens que lorsqu'on a 2 vm ou plus d'ailleurs on fait toujours un quorum (disque ntfs de 1Go ou alors dossier partagé) et que le cluster fonctionne tant que le nombre de noeud (le quorum contant comme un noeud) = (nombre total de noeud / 2) +1

ta baie unity est double controleur ? tu as la licence fichier ? pourquoi monter une vm windows ?
(drôle d'idée de quitter netapp ... ça marche si bien pour ce qu'on lui demande de faire ... avis perso)

Bonjour,
 
Le but de mon post n'est vraiment pas de chercher à faire changer les choix qui ont été définis.
Je souhaite juste avoir un peu d'aide pour mener à bien cette migration.
Oui la unity a bien 2 controleurs pourquoi ?
 
Ca marche bien oui, mais disons qu'un fas2020 ne répond plus du tout au besoin. Que la baie est à la ramasse complet en terme de CPU raison pour laquelle elle a été remplacée.

Quel type de sauvegarde fais-tu ? Avec agent filer ou une sauvegarde complète de la VM ? Si avec Agent, la dédup Windows n'entrera du tout en conflit, elle n'optimisera pas non plus ton backup, car ton agent va interroger le service windows pour parser les données. En gros que ton serveur soit dedupliqué ou pas ... Aucune incidence.
 
Si par contre tu fais une savegarde complète de la vm (VHDX ou VMDK) là par contre la dédupe à une incidence :
+ tu auras moins de volumétrie à sauvegarder
- la restauration granulaire d'un élément ne sera plus possible, il faudra restaurer TOUT le VMDK/VHDX, le monter sur un serveur qui tourne sur le meme os (2012 ou 2012R2) et là recopier le fichier. En effet, la base de dedup est stockée sur le même disque que les données.
 

Les cluster de fichier c'est extrêmement résilient ! tu ne pourras pas faire de l'actif/actif sur un cluster de fichier à moins de multiplier les rôles ce que je ne saurais trop de déconseiller si ton besoin n'est pas énorme ... DFS ou pas. D'ailleurs, tu me confirme que tu utilises du DFS N et pas deu DFS R ? Car dans le second cas, tu auras un pb sur la base de synchro. Aujourd'hui on utilise des cluster de fichier en 2012 avec du DFS N et des réplication par la baie de stockage (compellent chez nous) pour PRA et tout tourne parfaitement (PRA joué à minima 1 fois par an).
 

Si la conf est bonne de base ... Aucun soucis sur du cluster de fichier ... C'est largement éprouvé, et ça ne bouge plus tellement (a voir sur 2016 ... Mais je ne crois pas avoir lu grand chose là dessus). Avec 2 noeuds tu auras toujours un quorum effectivement. pour un cluster de fichier ... Tu as très peu d'action et de conf niveau Cluster et rôle.

au niveau des sauveharde on save toute l enveloppe aujourd hui donc a priori pas compatible avec la dedup si je comprends bien.
dommage le ddpeval nous indique 50% de gain.
 
nous n avons pas de dfs r mais uniquement du dfs je savais pas qu on disait dfs n dans ce cas !
d ailleurs ce sont nos 2 dc qui font dfs je l aurai plutot mis sur les serveur de fichier pour ma part mais bon...
 
et ok pour le cluster faut que je regarde un peu ce qu il vaut mieux qu on utilise dans notre cas pour le temoin mais aussi comment faire avec une baie fc ! j avais fait qu en isci en lab et un initiator.
 
bref merci en tous cas pour ton avis !

si si c'est compatible, mais la restauration est plus compliquée. La plupart des softs de sauvegardes permettant la restauration granulaire même dans une enveloppe. Après le gain est sympa sur la fenêtre de sauvegarde, à voir si tu dois souvent restaurer des données ou pas, et suivant la volumétrie.Il n'y a pas de bonne ou mauvaise méthodes, juste celle qui te conviens le mieux.

iscsi ou fc tu n'as aucune différence côté hyperviseur. c'est juste le zoning qui importe sur toute la chaîne réseau+contrôleur.

DFS N = Namespace
DFS R = Réplication

je comprends , on avait un FAS2020 , on l'a remplacé par un FAS2554 , beaucoup plus rapide
la unity a 2 controleur , si un tombe , l'autre prend le relais , tu as un double attachement reseau par controleur je pense , donc ta baie Unity est deja un cluster  
si tu perds la salle complete, tu en as une de replication ?

Pour le cluster tu peux même n'avoir aucune coupure coté client si tes OS serveurs et clients sont suffisamment récents (8.1/2012 R2) avec le SMB3.

 
avant on avait backup exec donc on sauvegarde les fichiers directement.
aujourd hui on restaure environs 1 fois par mois mais on va pas restaurer 2to de donnees (notre fs) pour 2 fichiers...
 
je parle de la mise en cluster du role serveur de fichier. il me semble que ca se fait au sein de ma vm et non pas au niveau de l hote du cou...
 
 
 
oui il y a bien 2 controleur avec chacun 2 attachements.
on a une salle secondaire avec recovery point qui doit etre mis en place la semaine prochaine pour avoir la replication de baie a baie. mais c est pour un pra ca donc pas de rapport avec un serveur de fichier en cluster au sens microsoft.
 
ah ! pour le cluster me semblait qu on perdait 1 ping pour la bascule ! par contre meme si le fs est en 2012r2 les postes clients c est du 7 pro

recover point marche aussi pour la partie fichier

bien sur puisque ce sera pour la replication baie a baie. mais ce type de scenario ne sera activer que si la salle principale tombe completement et non pas si la vm serveur de fichier a un soucis. donc pour moi aucune relation a afaire entre les deux

par contre si quelqu'un a une idée sur comment migrer du cou les profil utilisateurs je dis pas non
 
Je dois migrer la gpo de redirection des dossier car elle était \\nomdelabaie vers \\DFS dans un premier temps
et a priori, c'est pas si simple que ca... Puisque je me retrouve avec des redirection qui n'ont pas l'air de fonctionner.
 
et ensuite arriver à copier tout les dossiers des profils itinérant... schant que certains seront en cours d'utilisation.

Pour les produits itinérants, tu n'as vraiment le choix : prévois une coupure de service. Si tu fais ça en pleine journée, tu risques de corrompre des profils.

oui ca pas de soucis pour prevoir une coupure mais meme malgre ca je ne vois pas quand meme...
vu que c est sur la baie si j arrete le partage de fichier je ne peux plus copier...
et aujourd hui ils vont chercher le profil avec le nom de laa baie et pas le dfs...
 
peut ere voir si il y a aune option au niveau cifs pour limiter a une seule ip comme ca plus personne peut y acceder... sauf moi pour la copie

Si tu coupes l'accès à tes serveurs TSE, personne ne va utiliser ses profils.
Pour le sécuriser, tu peux aussi modifier les permissions du partage : tu retires les accès utilisateurs, et tu ne mets que des accès pour toi.

ca va etre la mouise sur les profils itinerant a cause des droits sur les dossiers users...
ou faut etre proprio pour changer les droits.
pas grave pour les tse une coupure a lieu toures les semain es

Parce que tes comptes administrateurs ont pas les droits dessus ?

Sur du profil itinérant de base personne n'a de droit si ce n'est l'utilisateur. C'est comme ça depuis un moment.

Les comptes admins ont les droits sur certains mais pas tous.
Il y a des dossier ou il faut que je me rende proprio.

Voila comme le dit sniper.

En fait, dans l'AD on remplit le champs profil utilisateur et en plus de ca on a la redirection des dossier bureau + mes documents via GPO

je cherche sur le fas2020 ou je peux voir pour autoriser que quelques ip ^^

Tout dépend de comment tu gères tes ACLs sur ton partage. Si c'est bien géré, tu peux octroyer par défaut un accès aux Administrateurs. C'est quand même quasi indispensable pour certains dépannages, et du coup pour la migration à faire.

Perso je séparerai la partie profils utilisateurs sur une autre machine, les faire coexister avec d'autres données ce n'est vraiment pas top.

C'est sur une lun différente mais sur la même baie.
Aujourd'hui, ca va etre sur un volume différent donc un vhdx différent, mais ce sera sur la même lun, on a fait uniquement 2 lun. 1 par controleur et ca devrait répondre à notre besoin.
 
Le problème c'est comment migrer ces données. Je ne trouve pas le menu de la restriction IP c'est pas possible que ca ne soit pas faisable alors que sur une simple distrib debian style OMV on a ca...

On t'a déjà répondu : tu coupes l'accès aux serveurs RDS le temps de la manip. En espérant que seuls les utilisateurs RDS ont ce genre de profil et pas les autres.

Et accessoirement, au lieu de gérer le paramètre compte par compte avec l'onglet "Profil des services Bureau à Distance", ce serait mieux de gérer ça par GPO directement.

bé non justement...
Je suis pas assez clair peut etre.
Tous nos postes fixes utilisent la redirection de profil donc c'est pas aussi simple pour les tse aucun soucis ^^

Et wolfman je suis tout à fait d'accord avec toi... Sauf que la hierarchie n'est pas du même avis...

Redirection de profils ou profils itinérants (ou les deux) ? Vous n'avez qu'un seul filer ?

A valider avec AVAMAR, mais du coup la dédup windows ... Je pense que tu peux faire une croix dessus.
 

Je parlais du montage des volumes. Les CSV de ton cluster de VM peuvent être remontés sur tes VM de 2 façon :
- Tu joins directement les CSV au VM via des HBA émulés
 
Ah ben non en fait t'as pas le choix ... Tu peux pas utiliser le direct attach de l'hyperviseur ... SAD !
 

Pour du filer, client windows 7 et cluster de fichier 2012 tu ne perdra pas les sessions actives. Ce n'est pas sensible au ping le filer. Ce sera donc transparent, ca va juste créer une latence pour les gens qui seraient en cours d'ouverture d'un fichier au moment de la bascule. (Et je parle de vécu, nos Cluster de fichiers ont étés montés pendant que nos clients étaient en W7).

Je n'offrirai pas de garanties là-dessus, le Transparency Failover c'est à partir de SMB3 donc Windows 8.1 minimum...

En quoi est-ce un problème ?

En résumé, tu veux passer d'un mode stockage des profile sur une LUN présentée à un serveur de fichier, à un mode où tu encapsules tout ça dans un .vhdx que tu présentes à un namespace DFS.
 
Si tu sais faire un peu de powershell...
 
1 - Tu créés un namespace DFS qui pointe vers les répertoires utilisateurs actuel
2 - Tu créés un script powershell qui modifie tous les chemins vers tes profiles utilisateurs AD vers le namespace
3 - Tu contrôles que tout va bien
4 - Tu rajoutes les droits au compte admin sur les dossiers
5 - Un robocopy de tout ceci sur ton nouveau serveur de fichier en conservant les droits NTFS
6 - Tu modifies juste la cible DFS quand tu te sens prêt.
 
L'avantage de cette solution, tu as 2 coupures certes, mais très courtes (pas le temps de copie entière) et tu as un rollback sûr en cas de problème.

J'ai bien parlé des fichiers déjà ouverts ... Donc en cache sur le poste. Les fichiers LCK étant toujours sur le serveur lors de la bascule.
 
Par contre on est d'accord, lors de la bascule ... Tu as une latence pour les ouvertures qui se feraient pendant la bascule. soit quelques secondes. C'est tout de même pas mal je trouve.

Nous avons bien une seule baie oui.
Comme énoncé nous avons la redirection des dossier activé ainsi que les profils itinérants.

Tout e que tu décris la chatton2 sinon pour la migration, ca a été fait depuis longtemps. En gros, à midi tout a été migré sauf la partie profil itinérant + redirection de dossier. La baie ne sertplus qu'a ca aujourd'hui. toute la partie serveur de fichier que faisait la baie est maintenant réalisé par le serveur de fichier qui a un 4 disque dur (systeme, FS, profil user, archives).

Ben si tu as déplacé les données ... Il ne te reste qu'à modifier les comptes non ?

les donnees des profils itinerants non !
le appdata etc on peut pas le copier car il est en cour d utilisation pour les personbes qui ont un pc !

Mais en fait je comprends pas la difficulté. A partir du moment où tu prévoies de faire ça hors prod, quel est le problème ?

mais je peux pas prevoir le hors prod en fait...
fin je trouve pas l option sur la baie pour ne pas que les utilisateur puisse s y connecter mais que mou je puisse continuer min robocopy.

Tu désactives le compte AD le temps de la manip (mais c'est vraiment crade)

Mais on va pas les faire 1 par un xD
on a 400 users ^^

Faut que je trouve un moyen pour que les users ne puissent pas s'y connecter.
Peut etre mettre en place une tache planifié sur les poste pour qu'ils s'éteignent tel jour à telle heure (par exemple 12H) et faire le robocopy a ce moment la.

Je l'ai dit plus haut : tu coupes l'accès au partage pour les utilisateurs.  

MMmmmmm  
donc en gros dans les securité de partage j'enleve tout le monde c'est bien ca que tu me dis ?

Au niveau du partage oui. Et tu n'autorises que ton compte d'administration qui te servira à la migration.