none
Contuinité des services AD, DNS, File Server RRS feed

  • Question

  • Bonjour tous.

    Je suis à la recherche de solution pour assurer la continuité des services Windows server Active directory, DNS, serveur de fichier installés sur deux sites distant. 

    Je souhaite un basculement (ou Load Balancing) des services cités ci haut du site primaire vers le site secondaire en cas d'indisponibilité du site primaire. 

    J'ai appris que pour le rôle Server de fichier, la Fonctionnalité Cluster de Basculement pourrais faire l'affaire mais j'en sais pas plus et pour ce qui concerne les services AD le fait de joindre un second serveur (Celui du site secondaire) au domaine pourrait il faire l'affaire ?. 

    Merci pour vos conseil. 

    mardi 15 décembre 2020 16:43

Toutes les réponses

  • Bonjour Deep,

    Pour le rôle AD et DNS il faut ajouter un autre contrôleur de domaine afin d'avoir la redondance.

    https://rdr-it.com/ajouter-un-controleur-de-domaine-ad-ds-dans-un-domaine-existant/

    Pour le rôle file server tu peux le mettre en cluster.

    https://docs.microsoft.com/fr-fr/windows-server/failover-clustering/deploy-two-node-clustered-file-server

    Tu peux aussi faire un cluster de basculement DHCP

    http://idum.fr/spip.php?article290

    Tu peux aussi réaliser un cluster de basculement hyperv

    https://rdr-it.com/cluster-hyper-v-installation-configuration/

    Tu peux aussi faire du replica hyperv

    https://docs.microsoft.com/fr-fr/windows-server/virtualization/hyper-v/manage/set-up-hyper-v-replica


    "Marquer comme réponse" les réponses qui ont résolu votre problème


    mardi 15 décembre 2020 20:59
  • Tu trouveras dans le lien suivant la liste des rôles pouvant être mis en cluster de basculement :

    https://docs.microsoft.com/fr-fr/windows-server/failover-clustering/create-failover-cluster

    Here's how to create a clustered role:
    1. Use Server Manager or Windows PowerShell to install the role or feature that is required for a clustered role on each failover cluster node. For example, if you want to create a clustered file server, install the File Server role on all cluster nodes.

      The following table shows the clustered roles that you can configure in the High Availability Wizard and the associated server role or feature that you must install as a prerequisite.

      Table 2
      Clustered Role Role or Feature Prerequisite
      Namespace Server Namespaces (part of File Server role)
      DFS Namespace Server DHCP Server role
      Distributed Transaction Coordinator (DTC) None
      File Server File Server role
      Generic Application Not applicable
      Generic Script Not applicable
      Generic Service Not applicable
      Hyper-V Replica Broker Hyper-V role
      iSCSI Target Server iSCSI Target Server (part of File Server role)
      iSNS Server iSNS Server Service feature
      Message Queuing Message Queuing Services feature
      Other Server None
      Virtual Machine Hyper-V role
      WINS Server WINS Server feature
    2. In Failover Cluster Manager, expand the cluster name, right-click Roles, and then select Configure Role.

    3. Follow the steps in the High Availability Wizard to create the clustered role.

    4. To verify that the clustered role was created, in the Roles pane, make sure that the role has a status of Running. The Roles pane also indicates the owner node. To test failover, right-click the role, point to Move, and then select Select Node. In the Move Clustered Role dialog box, select the desired cluster node, and then select OK. In the Owner Node column, verify that the owner node changed.


    "Marquer comme réponse" les réponses qui ont résolu votre problème

    mardi 15 décembre 2020 21:04
  • AD gère nativement la tolérance de panne, il suffit de multiplier le nombre de contrôleur de domaine pour un même domaine.

    Pour les services de fichiers c'est pas si simple de faire un cluster CSV entre deux sites distant.

    Si c'est juste du serveur de fichier, DFS peut être suffisant, néanmoins attention qu conflit si les deux sites sont actifs et si le même document peut être modifié des deux côtés. Le dernier a synchronisé sa modification gagne.

    Quel type de connexion tu disposes ? Débit ? Fiabilité des liens ? Combien de poste par site ?

    mardi 15 décembre 2020 22:09
  • Je rejoins Philippe pour le cluster de fichier sur 2 sites.

    Pour le DFS, je ne l'utiliserais pas de cette façon a cause des risques qu'il explique.

    Peut être une solution plus naturelle pour ce type de situation est d'utiliser le cloud MICROSOFT AZURE.

    Monter 1 ou 2  VM (serveur files) simplement en GRS + sauvegarde des VM + accès par VPN site à site et voila !

    https://docs.microsoft.com/fr-fr/azure/storage/common/storage-redundancy

    Azure storage maintains at least 3 replicas of our data wither within the same data center using locally redundant storage (LRS), or secondary data center either in zone-redundant storage (ZRS), geo-redundant storage (GRS), or read-access geo-redundant storage (RA-GRS). With this, Azure preserves our application up-time in the case of failures.
    1. Locally redundant storage (LRS)
      It helps to replicate our data in the same data center, and it is a low-cost data redundancy technique. LRS is the lowest-cost replication option and offers the least durability compared to other options. It provides at least 99.999999999% (11 nines) durability of objects over a given year.

      This is helpful when we can easily reconstruct the data in case of data loss, or we have restricted data to replicate only within the country/region.
    2. Zone-redundant storage (ZRS)
      It helps us for excellent performance, low latency and replicate our data synchronously across three storage clusters in a single region. Each storage cluster is physically separated but within the same region. ZRS offers durability for storage objects of at least 99.9999999999% (12 9's) over a given year.
    3. Geo-redundant storage (GRS)
      As I explained above it helps us in replicating our data to another region which is far away hundreds of miles away from the primary region. It provides at least 99.99999999999999% (16 9's) durability of objects over a given year. GRS replicates our data to another region, but data will be available to be read-only if Microsoft initiates a failure from primary to the secondary region.
    4. Read-access geo-redundant storage (RA-GRS)
      It is based on the GRS, but it also provides an option to read from the secondary region, regardless of whether Microsoft initiates a failover from the primary to the secondary region.


    "Marquer comme réponse" les réponses qui ont résolu votre problème






    mercredi 16 décembre 2020 04:46
  • Bonjour Barth. 

    J'ai une Liaison LS de 2Mbps entre les 2 sites qui sont connectés par VPN et 300 users environs. Je rappel que le site 01 existe dejà. 

    Concernant la réplication DFS, j'ai cru savoir qu'on peut choisir un site comme actif et planifier les réplications sur l'autre site en standby.

    Dans le cas de Serveur de Fichier, une RPO d'une journée de travail est acceptable et donc les réplications peuvent se faire chaque soir en fin de journée à partir de 21H, les requetes sont donc envoyés vers le serveur actif. On est donc dans une situation de reprise d'activité. 

    Une réplication DFS pourrait elle faire l'affaire dans ce cas de figure ?

     


    • Modifié Deep_IT mercredi 16 décembre 2020 12:20
    mercredi 16 décembre 2020 10:06
  • Hello Jérôme. 

    Merci pour ta contribution et également j'avais pensé à Microsoft Azure et même AWS, mais la Finance n'est pas prête pour se lancer dans des couts OPEX. 

    En effet, il y'a déjà un existant en terme de serveur, stockage et réseau qu'il va falloir déployer sur un second site. Donc je dois juste proposer une architecture ou une solution pour assurer un petit semblant de reprise ou de continuité IT d'où ma publication actuelle celle de comprendre si la réplication DFS pourrait faire l'affaire. 

    Surtout si on se place dans le cas d'une reprise d'activité IT, j'ai cru comprendre qu'avec les réplications DFS, il est possible que l'un des serveur soit actif et l'autre en standby et planifier les réplications à des heures définis. 

    En fait on pourrait tolérer un RPO (Recovery Time Objectif) d'une journée au pire des cas.  


    • Modifié Deep_IT mercredi 16 décembre 2020 12:20
    mercredi 16 décembre 2020 10:15
  • Bonjour Deep_IT

    Tout à fait ! Une limitation du DFS est qu'il ne gère pas le "lock" des fichiers sur le même fichier est modifié sur plusieurs "Folder target link" (ce qu'indiquait Philippe). 

    Cependant, il existe des app. tierces qui peuvent gérer cette limitation, mais faut sortir sa bourse et pas  que des pièces rouges. Ex. Peer-Lock (https://www.peersoftware.com/solutions/edge-file-management/)Le principe : à chaque fois qu'un fichier est ouvert sur un folder Target link, il lock le même fichier sur les autres filers.

    Autre solution sans sortir le porte monnaie :

    DFSShare

    ------------- \\Server1\share : Actif

    ------------- \\Server2\share : Inactif

    Server1  est sur le site local, Server22 dans ton Datacenter ou sur un autre site. 

    Nota : Pour des questions de rapidité tu pourrais avoir certains partage DFS qui sont actifs sur un site et d'autres sur l'autre site.

    En cas de désastre Server1 vient de tomber : Un script (que tu devras avoir préparé à l'avance, sinon c'est à la mano et ça va prendre plus de temps) qui va basculer les liens actifs sur le serveur de site2.

    On peut même envisager la chose suivante :

    • - Test en permanence la disponibilité d'un serveur
    • - Si serveur tombe bascule des liens DFS actifs de ce serveur vers autre serveur.

    Pas tout à fait de la continuité de service, mais de la reprise d'activité et de la tolérance de panne.

    La bascule à la mano est possible bien entendu, mais ça va prendre beaucoup plus de temps et tu peux te louper en menant les opérations. 

    Résumé : Haute-disponibilité via "publication" des partages via des partages DFS avec plusieurs folder Target Link (serveurs cibles) pour chaque partage DFS. Réplication quasi-temps réel via le DFS-R. Pas de réelle continuité de service mais reprise d'activité rapide (merci le script, ... PS fo course Medhi :-) ).

    Pour les services : DC/DNS HA by desgin car rôles redondées. DHCP par mise en place d'un DHCP failover (ne pas oublier de mettre les IP des 2 serveurs DHCP en IPHelper au niveau des équipements réseau, ... sinon ça va pô bien marcher).

    Cordialement

    Olivier

    mercredi 16 décembre 2020 14:01
  • Dans le cas de Serveur de Fichier, une RPO d'une journée de travail est acceptable et donc les réplications peuvent se faire chaque soir en fin de journée à partir de 21H, les requetes sont donc envoyés vers le serveur actif. On est donc dans une situation de reprise d'activité

    Tu as une estimation du volume de données ? Et du volume modifié a resynchroniser chaque jour ?

    2Mo cela pourrait être insuffisant, surtout pour la synchro initiale.

    Une réplication DFS pourrait elle faire l'affaire dans ce cas de figure ?

    oui, non, peut être, cela va dépendre du volume de données de la répartition des personnes, si tu as 295 personnes sur le site 1 et 5 sur le deux, c'est pas pareil que 150 et 150. Si les sites regroupes des service et groupe d'utilisateur qui utilise les mêmes partages tu peux avoir un partage actif et un autre passif pour chaque partage et le noeud actif serait sur le site. 

    Les offres inclus dans les abonnements Offices peuvent être des alternative intéressante, puisqu'elle facilite la collaboration à travers des outils comme Teams et qu'en plus il offre des options comme la coédition des documents Office. Maintenant tout dépend des licences ou abonnements dont tu disposes.

    mercredi 16 décembre 2020 16:41
  • Bonsoir Barth. 

    Merci beaucoup pour ton aide et tes précieuses remarques et conseil.  

    Tu as une estimation du volume de données ? Et du volume modifié à resynchroniser chaque jour ? 2Mo cela pourrait être insuffisant, surtout pour la synchro initiale. 

    Oui le volume de données actuellement sur le server de fichier existant est de 1,8 To. Et le volume modifié à resynchroniser chaque jour tourne autour de 200Mo.

    Pour la Synchro initiale j’avais prévu de la faire sur le même site. C’est-à-dire le serveur de fichier 01 et le serveur de fichier 02 se trouveront dans le même segment LAN afin de bénéficier du débit des interfaces GigabitEthernet, et une fois cette synchronisation initiale effectuée, je pourrais déplacé le second serveur vers son site final (Il y’aura donc changement d’IP lors de son arrivé sur le site final).

    Oui, non, peut-être, cela va dépendre du volume de données de la répartition des personnes, si tu as 295 personnes sur le site 1 et 5 sur le deux, ce n’est pas pareil que 150 et 150. Si les sites regroupent des service et groupe d'utilisateur qui utilise les mêmes partages tu peux avoir un partage actif et un autre passif pour chaque partage et le noeud actif serait sur le site

    Je suis plutôt présentement dans une architecture multi site avec 20 branchs Office (15 users max par branche Office d’où 05 users max actif pour lecture/écriture dans le partage) et 01 Headquarter (Abritant le serveur de fichier existant).

    Pour l’instant tout se passe sans problème majeur, les 2 Mo de débit LS sont partagé entre les 20 Branchs Office qui effectuent des requêtes en lecture/écriture sur des fichiers partagés en commun. L’interconnexion entre Banch Office et Headquarter est assurée par un VPN.

    Mais aujourd’hui ce serveur de fichier présente un risque majeur car il n’est pas redondé et donc en cas de perte de ce serveur, c’est 05 années de boulot perdu. A court terme je souhaite le redonder sur un autre site (Second Headquarter) étant donné que j’ai un existant en terme de Stockage, Compute et Réseau, puis à long terme proposé un plan de contuinité/reprise d’activité IT solide.

    Les offres inclus dans les abonnements Offices peuvent être des alternatives intéressantes, puisqu'elle facilite la collaboration à travers des outils comme Teams et qu'en plus il offre des options comme la coédition des documents Office. Maintenant tout dépend des licences ou abonnements dont tu disposes.

    Et oui pour office comme alternative en ce qui concerne les documents offices, mais nous n’avons pas encore de licence dans ce sens, restriction de budget oblige pour l’instant. Nous aurions souhaité déplacé certains services sensibles dans le Cloud Azure, AWS ou tout autre Cloud Provider mais encore une fois, nous faisons face à la finance qui exige qu’elle veut un RSI avec l’existant qui est sous exploité et effectivement je suis d’accord avec elle sur ce plan, vu qu’à mon initiative nous avons pu libérer trois gros serveur qui étaient sous utilisés ce qui permet de les redéployer sur le second headquarter en attendant un plan robuste de Disaster Recovery



    • Modifié Deep_IT jeudi 17 décembre 2020 00:27
    mercredi 16 décembre 2020 23:50
  • Bonjour Deep_IT

    Je vois que cela avance et c'est très bie mais que tu te poses encore quelques questions tout à fait légitimes.

    [...Mais aujourd’hui ce serveur de fichier présente un risque majeur car il n’est pas redondé et donc en cas de perte de ce serveur, c’est 05 années de boulot perdu....]

    Dans le passé, j'avais un archi proche de la tienne (quoique nettement plus importante et sites et en taille de données). Sur chaque site un serveur de sauvegarde. A l'époque la déduplication à la source n'était pas envisageable et il fallait donc une infra de backup par site ... avec une petite librairie de bandes associée ben entendu. Par d'équipe IT locale ... et les pbs surviennent : qui alimente la librairie ? secrétaire, hôtesse d'accueil généralement, pas compliqué mais pas impliquées. Bilan on n'avait que rarement des backup corrects. On a pris la décision de supprimer tous les backup locaux. C'est là, qu'on arrive dans le même cas que toi. A l'époque les utilisateurs accédaient à leurs données via des partages DFS, ... mais  chaque partage n'avait qu'un seul folder taget link pointant sur leur serveur local. J'ai créé une palanquée de VM sur le site central, mis en place les folders Target LInks qui vont bien vers ces derniers, mis en place une réplication DFS-R qui va bien, et enfin une sauvegarde des VMs en central (En Datacenter, il y a tout ce qu'il faut, y compris équipe IT). Naturellement, j'ai été confronté à la réplication initiale et la durée de celle-ci. J'ai d'abord commencé par quelques petits sites afin d'estimer le temps. J'ai ensuite fait une estimation du temps pour les plus gros. Trop long ! OK, Copie des dates sur un disque externe, et envoi du disque au Datacenter, et recopie. Ensuite réplication DFS-R en suivant un process spécifique (on peut retrouver cela sur le net).

    Dans le même style, j'ai eu un cas encore plus extrême. Appliance de sauvegarde avec déduplication capacité 80 To de disques (imagine la volumétrie des datas, sachant qu'avec les types de datas qu'on avait, il y avait un facteur de déduplication de x20). On voulait avoir un copie en central des backup locaux. Pb de la réplication initiale bien entendu. La ça a été : Appliance temporaire mobile. Copie locale Appliance==>ApplianceMobile pilotée par infra de backup of course, transport de l'appliance mobile en central, copie Appliance mobile ==> Très Gros Appliance en central toujours pilote par infra de backup. Nettoyage de la BD Backup ce la copie intermédiaire (sinon, elle aurait eu 3 copîes). Appliance mobile repart sur autre site ... et on recommence. Appliance dans caisson sur roulette type matos de tournées des musicos. Fermé à clé, et transport sécurisé par société spécialisée. Accepté en très haut lieu, car les données n'étaient pas en clair mais dédupliquées et si tu ne connais pas l'algo de déduplication, pas facile de piquer les données.

    Voilà, j'espère qu'à travers ces 2 exemples, dont le premier ressemble fort au tien, cela t'inspirera pour que le vent de la solution ultime te souffle à l'oreille (c'est beau, je me sens d'humeur ... poétique ce matin, ... mais je pense que ça claquerais encore mieux en anglais.).

    Cordialement

    Olivier

    jeudi 17 décembre 2020 07:31
  • Mais aujourd’hui ce serveur de fichier présente un risque majeur car il n’est pas redondé et donc en cas de perte de ce serveur, c’est 05 années de boulot perdu

    Les sauvegardes sont la pour éviter de perdre plusieurs années de travail. Les mécanismes de comme DFS sont la pour réduire le temps d'interruption de service lorsqu'un sinistre ce produit. 

    jeudi 17 décembre 2020 10:50
  • Hello Olivier.

    Merci pour ta contribution. 

    Pour ce qui est du use case semblable au mien, tu peux m'en dire plus ? 

    Je suis un peu perdu. 

    Merci. 

    jeudi 17 décembre 2020 16:11