Présentation de l'architecture des numéros d'unité logique d'Exchange 2010
Dernière rubrique modifiée : 2010-01-22
Souvent, le disque physique, ou numéro d'unité logique (LUN) optimal, reconnu par le système d’exploitation résume le matériel utilisé pour présenter le disque au système d’exploitation. L'architecture de numéros d'unité logique est utilisée dans Microsoft Exchange Server 2010.
S'il existe de nombreuses manières de concevoir les numéros d'unité logique dans Exchange 2010, il est néanmoins recommandé d'utiliser les conceptions suivantes pour limiter la complexité :
- Un numéro d'unité logique (LUN) par base de données
- Deux numéros d'unité logique (LUN) par base de données
- Deux numéros d'unité logique (LUN) par ensemble de sauvegardes
Un numéro d'unité logique (LUN) par base de données
L'architecture d'un numéro d'unité logique par base de données signifie que la base de données et les fichiers journaux correspondants se trouvent sur le même numéro d'unité logique. Pour déployer une architecture qui n'utilise qu'un numéro d'unité logique par base de données, vous devez disposez d'un groupe de disponibilité de base de données (DAG) comportant au moins deux copies et ne pas utiliser une solution matérielle de service de cliché instantané des volumes (VSS).
Les avantages que présente cette stratégie sont notamment les suivants :
- administration de stockage simplifiée et réduction du nombre de numéros d'unité logique à gérer ;
- réduction (possible) du nombre de tâches de sauvegarde ;
- possibilité d'isoler les performances entre les groupes de stockage lors du non-partage de pile entre plusieurs numéros d'unité logique.
Cette stratégie présente néanmoins l'inconvénient de limiter les procédures de sauvegarde et de restauration VSS basées sur du matériel (par exemple, les clichés de clones). Pour plus d'informations sur VSS, voir la rubrique Recommandations pour l'utilisation du service VSS avec Exchange Server 2003.
Retour au début
Deux numéros d'unité logique (LUN) par base de données
Dans Exchange 2010, avec un maximum de 100 bases de données, le nombre de numéros d'unité logique configuré dépend de votre stratégie de sauvegarde. Si votre objectif de temps de récupération est très court ou si vous utilisez des clones VSS pour une récupération rapide, il peut être judicieux de placer chaque base de données dans son propre numéro d'unité logique de journal des transactions et son numéro d'unité logique de base de données. Comme cette approche augmente le nombre de lettres de lecteur disponibles, des points de montage de volume doivent être utilisés.
Les avantages que présente cette stratégie sont notamment les suivants :
- activation du service VSS basé sur le matériel au niveau de la base de données, qui assure une sauvegarde et une restauration d'une seule base de données ;
- possibilité d'isoler les performances entre les groupes de stockage lors du non-partage de pile entre plusieurs numéros d'unité logique ;
- fiabilité accrue, car un problème de capacité ou d'altération se produisant sur un numéro d'unité logique n'affectera qu'une base de données. Ce point est important si vous ne tirez pas parti des fonctionnalités intégrées de résilience des boîtes aux lettres.
Les problèmes que présente cette stratégie sont notamment les suivants :
- 100 bases de données requièrent 200 numéros d'unité logique, ce qui dépasse la limite de certaines baies de stockage ;
- un numéro d'unité logique distinct pour chaque base de données peut engendrer plusieurs numéros d'unité logique par serveur, ce qui augmente les coûts et la complexité d'administration.
Retour au début
Deux numéros d'unité logique (LUN) par ensemble de sauvegardes
Un ensemble de sauvegardes correspond au nombre de bases de données totalement sauvegardées au cours d'une nuit. Une solution exécutant une sauvegarde complète sur 1/7ème des bases de données au cours d'une nuit (par exemple, une sauvegarde complète hebdomadaire ou bimensuelle avec des sauvegardes incrémentielles ou différentielles quotidiennes) peut réduire la complexité en plaçant toutes les bases de données à sauvegarder sur le même numéro d'unité logique de base de données et le même fichier journal associé. Cela peut réduire le nombre de numéros d'unité logique sur le serveur.
Les avantages que présente cette stratégie sont notamment les suivants :
- administration de stockage simplifiée et réduction du nombre de numéros d'unité logique à gérer ;
- réduction (possible) du nombre de tâches de sauvegarde.
Les problèmes que présente cette stratégie sont notamment les suivants :
- elle limite les procédures de sauvegarde et de restauration VSS basées sur du matériel (par exemple, les clichés de clones). Pour plus d'informations sur VSS, voir la rubrique Recommandations pour l'utilisation du service VSS avec Exchange Server 2003.
- un problème de capacité ou d'altération se produisant sur un seul numéro d'unité logique peut affecter plusieurs bases de données.
Retour au début