none
SQL 2008 / R2 - Architectures DB Mirroring + Witness RRS feed

  • Question

  • Bonjour,

    Dans une architecture DB Mirroring, si l'on veut faire du failover synchrone auto, il faut un témoin (witness). La question est la suivante:

    en temps normal, on utilise un témoin pour une archi DB Mirroring (2 serveurs + 1 witness: 1 licence STD ou Ent pour le serveur nominal + 1 express (gratuit pour le témoin), le serveur mirroré (pas de besoin de licence)

    Peut-on mutualiser différentes archis DB Mirroring avec un seul témoin ? (dans ce cas, il faudrait peut-être un "vrai" serveur (physique ou virtuel))

    Est-il possible de sécuriser les témoins ? (mirroing de témoins, cluster de témoins, log shipping de témoin, réplication de témoin ?)

    Peut-on installer plusieurs instances de témoins sur un seul serveur témoin, avec inst-tem1 pour mirroring DB 1, ins-tem2 pour mirroring DB2, etc ?

    Existe-il une solution pour monitorer les témoins ? (remontée d'alertes: bascules, quel(s) noeuds sont dispos, envois d'alertes diverses)

    Outils existants, web services pouvant remonter ce genre d'alertes ?

    Merci


    Thanks for advance for your ideas / help - Regards - Have a nice day ! RHUM2
    mardi 4 mai 2010 14:35

Réponses

  • Bonjour,

    Un serveur témoin peut très bien servir plusieurs ensembles de serveurs en miroir. Ce serveur n'est pas vraiment sollicité en terme de ressources.

    Vous pouvez sécuriser le témoin mais je n'en vois pas vraiment l'intérêt et l'administration s'en retrouverait alourdi. Il vaut peut être mieux implémenter une solution à base d'alertes.

    Quelques pistes de monitoring :

    Utilisation de la vue sys.databases avec la colonne mirroring_state_desc, scripts powershell etc ...

    ++


    MCDBA | MCITP SQL Server 2005 / SQL Server 2008 | LPI Linux 1
    mercredi 5 mai 2010 16:21
    Modérateur

Toutes les réponses

  • Bonjour,

    Un serveur témoin peut très bien servir plusieurs ensembles de serveurs en miroir. Ce serveur n'est pas vraiment sollicité en terme de ressources.

    Vous pouvez sécuriser le témoin mais je n'en vois pas vraiment l'intérêt et l'administration s'en retrouverait alourdi. Il vaut peut être mieux implémenter une solution à base d'alertes.

    Quelques pistes de monitoring :

    Utilisation de la vue sys.databases avec la colonne mirroring_state_desc, scripts powershell etc ...

    ++


    MCDBA | MCITP SQL Server 2005 / SQL Server 2008 | LPI Linux 1
    mercredi 5 mai 2010 16:21
    Modérateur
  • Bonjour,

    Je suis dans un contexte d'hébergement de solutions de DB mirroring.

    Exemple: 5o clients différents avec chacun une solution DB mirroring avec temoin

    D'où les questions suivantes:

    1 seul serveur témoin pour l'ensemble des plateformes ?

    Si le témoin est "out" , donc plus de surveillance. D'où l'idée de "sécuriser" le témoin avec une techno type "mirroring de témoin, cluster de témoin ou autre possibilité ?

    2 serveurs témoins en H.A pour l'ensemble des plateformes ? si l'un est "out", l'autre prend automatiquement le relais ?

    1 serveur sur lequel on installe " x " instances de témoin (en fonction du nombre de DB mirroring plateforme)

    Si il n'existe pas de solutions OOB, je me dirigerais donc vers des jobs d'alertes (avec remontées, web services ou autres possibilités.


    Thanks for advance for your ideas / help - Regards - Have a nice day ! RHUM2
    jeudi 6 mai 2010 12:43
  • Le traffic réseau que subit un serveur témoin est léger. 50 sessions de mirroring me paraît vraiment raisonnable pour un seul serveur témoin.

    Si vous voulez sécuriser le témoin vous pouvez le "clusteriser" avec tout le surplus d'administration que cela représente. Mirrorer un témoin ne me paraît pas une solution viable car le nom du serveur change dans ce cas et celui-ci ne sera donc plus accessible par les serveurs.

    ++


    MCDBA | MCITP SQL Server 2005 / SQL Server 2008 | LPI Linux 1
    jeudi 6 mai 2010 20:31
    Modérateur