none
Storage /DAG/Exchange 2013 RRS feed

  • Question

  • Bonjour,

    Je dois monter un DAG pour un client sur deux sites distants ( 2000 MBX)
    Il y aura un host physique par site hébergeant chacun deux VM.
    Chaque VM aura les 3 rôles CAS/HUB/MBX.
    Chaque serveur hébergera une base active + 3 passives.

    Ma question concerne le storage.
    Le role calculator d'Exchange 2013 me propose une base de 1 To par serveur.
     - ne vaudrait'il pas mieux 2 DB de 500 Go par serveur plutot qu'une de 1To ?
     - vous installeriez un disque physique par DB + un disque physique pour les logs ou un seul pour les deux ? (recommandation MS)
     - vous installeriez l'EDB de la base active et les EDB des bases passives sur le meme disques ou sur un meme volume ou chaque DB aura un disque dur ? (sachant que si ça crash, ce n'est pas critique vu qu'il y aurait 3 autres réplicats ...)

    Merci


    La Connaissance s'accroît quand on la partage!

    vendredi 3 octobre 2014 10:05

Réponses

  • Bonjour, 

    Ce sont des questions très intéressantes, la réponse dépend essentiellement du contexte.

    Pour chaque base de données qui tournent, il existe un process de vérification des bases en fond de tâche (BDM) qui réalise des *grosses* opérations de lecture, plus particulièrement il va faire des IOPS de 256KB pour chaque base. Ce sont des IO séquentielles par bases de données, donc il n'envoi qu'un IO a la fois par base, mais plus vous avez de bases de données, plus il y a de process BDM en arrière plan.

    Ce process implique que si vous avez besoin d'économiser des IOPS, vous utilisez moins de base, mais de plus grosse taille.

    A l'opposé, lors d'une opération de reseed de base de données, la vitesse de reseed est fonction de plusieurs facteurs, et pas seulement de la bande passante, sur une unique base de données d'ailleurs c'est à peine perceptible (~30MB/s en général). Du coup si on veut un reseed plus rapide, c'est interessant d'avoir plusieurs petites bases de données.

    Enfin il y a la question de l'espace, si vous colocalisez plusieurs bases sur le même volume, vous allez économiser un peu d'espace par rapport a des bases uniques par volume, pour les opérations d'index merging en particulier. 

    Pour résumer :

    - des grosses bases si vous avez des problèmes d'IOPS

    - des petites bases si vous avez un RTO faible et voulez économiser un peu d'espace.



    Bruce Jourdain de Coutance - Consultant MVP Exchange http://blog.brucejdc.fr

    vendredi 3 octobre 2014 12:14
    Modérateur
  • Si vous êtes sur une architecture en DAG, il n'y a pas spécialement de besoin d'isoler les LOG des disques EDB, on le faisait sur un serveur autonome pour avoir plus d'option de récupération.

    Si vous perdez une copie à cause d'un disque défaillant, vous aurez toujours 3 autres copies prêtes à prendre le relais dans le cas d'un DAG, et cela réduit les probabilités d'avoir un disque défaillant sur l'ensemble de l'environnement.


    Bruce Jourdain de Coutance - Consultant MVP Exchange http://blog.brucejdc.fr

    vendredi 3 octobre 2014 14:01
    Modérateur

Toutes les réponses

  • Bonjour, 

    Ce sont des questions très intéressantes, la réponse dépend essentiellement du contexte.

    Pour chaque base de données qui tournent, il existe un process de vérification des bases en fond de tâche (BDM) qui réalise des *grosses* opérations de lecture, plus particulièrement il va faire des IOPS de 256KB pour chaque base. Ce sont des IO séquentielles par bases de données, donc il n'envoi qu'un IO a la fois par base, mais plus vous avez de bases de données, plus il y a de process BDM en arrière plan.

    Ce process implique que si vous avez besoin d'économiser des IOPS, vous utilisez moins de base, mais de plus grosse taille.

    A l'opposé, lors d'une opération de reseed de base de données, la vitesse de reseed est fonction de plusieurs facteurs, et pas seulement de la bande passante, sur une unique base de données d'ailleurs c'est à peine perceptible (~30MB/s en général). Du coup si on veut un reseed plus rapide, c'est interessant d'avoir plusieurs petites bases de données.

    Enfin il y a la question de l'espace, si vous colocalisez plusieurs bases sur le même volume, vous allez économiser un peu d'espace par rapport a des bases uniques par volume, pour les opérations d'index merging en particulier. 

    Pour résumer :

    - des grosses bases si vous avez des problèmes d'IOPS

    - des petites bases si vous avez un RTO faible et voulez économiser un peu d'espace.



    Bruce Jourdain de Coutance - Consultant MVP Exchange http://blog.brucejdc.fr

    vendredi 3 octobre 2014 12:14
    Modérateur
  • Merci.

    Je suis d'accord avec vous.

    Concernant les logs et les db, vous les mettez sur le meme disque physique ?
    Ce serait apparement dans les best practices mais je vois pas la logique....


    La Connaissance s'accroît quand on la partage!

    vendredi 3 octobre 2014 13:12
  • Si vous êtes sur une architecture en DAG, il n'y a pas spécialement de besoin d'isoler les LOG des disques EDB, on le faisait sur un serveur autonome pour avoir plus d'option de récupération.

    Si vous perdez une copie à cause d'un disque défaillant, vous aurez toujours 3 autres copies prêtes à prendre le relais dans le cas d'un DAG, et cela réduit les probabilités d'avoir un disque défaillant sur l'ensemble de l'environnement.


    Bruce Jourdain de Coutance - Consultant MVP Exchange http://blog.brucejdc.fr

    vendredi 3 octobre 2014 14:01
    Modérateur
  • Merci

    La Connaissance s'accroît quand on la partage!

    vendredi 3 octobre 2014 15:01