Bonjour,
Il y a t’il un moyen de vérifier la taille d’une base (mail/agenda/contact) consommé pour un utilisateur ?
Merci d’avance
Bonjour,
Pour les mails, vous pouvez regarder les logs du job QuotaGatheringJob. Celui-ci fait relevé de l’utilisation des quotas par utilisateur.
ou plus simplement en verifiant la taille du folder imap de l’utilisateur dans \var\spool\cyrus\data…
Pour les contact et l’agenda c’est dans la DB donc difficile d’obtenir une taille eventuellement un nombre de ligne via un ptit script
mais de tout maniére cela ne reprenste pas grand chose en taille, pour vous donnée une idée avec 10 utilisateur et 3 ans en production j’ai une base de donné total de ±100Mo
Merci.
C’est en effet ce que j’ai fait, aller voir dans le \var\spool\cyrus\data… C’est quand même peu pratique…
On migrent d’ici quelques semaines de Lotus Domino vers BM…
Et je n’ai pas encore tranché sur la taille des bases mails et des quotas…
J’ai actuellement 1938 base lotus pour 281 Go. (hors archives) avec un quota de 400Mo à 800Mo
Avez vous un quota sur vos bases ?
Oui j’ai activé les Quota.
Ayant peux d’utilisateur et suffisament de place cela varie de 500Mo a 5Go.
Il est aussi possible d’interroger les index ES pour obtenir la taille des BALs (avec ou sans les archivés).
Plus généralement, il est préférable de prévoir un moyen simple permettant d’agrandir l’espace disque du spool de mail (LVM, technologies de baie de disque…) et commencer “petit”.
Par exemple, avec 1938 utilisateurs et que vous souhaitez leur donner 10Go de quota principal et 10Go de quota d’archive, il faut prévoir d’avoir ~2To pour les boîtes principales et ~2To pour les archives.
Au départ, vous avez 280Go de mail, et si vous activez l’archivage automatique dès le début, prévoir 1To pour les boîtes principales et 1To pour les archives permet de démarrer sereinement. Il sera toujours possible d’augmenter ces espaces par la suite, en fonction des besoins.
Merci Toony
Ce que je comprends donc si je veux 10Go de quota principal et 10Go d’archives pour environ 1950 utilisateurs j’ai besoin d’un espace disque total de 2 To pour les boites principale + 2 To pour les archives…
Comment calcul tu cela ?
Pour moi 2 To = 2 000 Go – 2 000 Go / 2000 Utilisateurs = 1 Go
En fait j’aurai 2 serveurs identiques pour la HA et déduplication avec :
- 12 coeurs
- 64 Go Ram
- Raid 1 (2x300 Go) → 300 Go (15k/rpm) pour le système Debian
- Raid 5 (3x600 Go) → 1,2 To (15k/rpm) → a priori 600Go c’est le maxi chez HP en 15k
- Raid 5 (3x6 To) → 12 To (7,2k/rpm)
La question :
Quel quota (mail / archives) pour mes bases mails (a savoir 2000 j’arrondi, 1600 Boites individuelles (nombre de mes licenses), 400 Boites partagées) et comment organiser le stockage avec l’espace disponible.
Index ES c’est pour ElasticSearch ? On les interroge comment ?
Désolé, effectivement avec 10G de quota, c’est bien 20To - ou 2T avec 1G de quota. J’ai changé d’avis durant la rédaction de mon post et ai mal corrigé les chiffres…
Je vais rectifier mon précédent post.
Concernant la déduplication, BlueMind - Cyrus - intègre un mécanisme qui ne stocke physiquement qu’une copie d’un mail donné, et crée des liens physiques dans les BALs de utilisateurs qui l’ont reçu. Ça permet un gain de place relatif, notamment pour les gros mails envoyés à de nombreux destinataires.
Vous compter utiliser de la virtualisation sur ces serveurs ?
Le backup sera fait comment ? En général, il est préférable d’avoir un espace dédié hors des serveurs - serveur dédié, ou plus simplement montage NFS.
Une chose à prendre en compte est que BlueMind indexe les BALs en utilisant ElasticSearch. Ce service permet de fortement diminuer le besoin d’I/O au niveau Cyrus - donc sur le spool de mail (BAL principale+archives) - en détournant les opérations consommatrices - recherches par exemple - vers le service ES.
La contre partie est que le service ES a besoin de disques rapides.
Il faut considérer que la taille de l’index est de ~10% de la taille totale des mails - BAL principale+archives.
Avec votre architecture, il serait bien d’utiliser les 12To pour l’espace BAL principale, ce qui permettrait un quota de ~6G par BAL - soit ~10 fois plus qu’actuellement. Et utiliser les 1.2To pour les index ES.
Les mails archivés sont accessibles de façon transparente depuis le webmail et les clients lourds supportés (Thunderbird et Outlook), les autres clients - téléphones notamment - afficheront les mails archivés sans les contenus d’origine, un lien permet d’ouvrir le mail en vue web, ce qui est moins transparent pour les utilisateurs.
Pour cela, il est préférable de ne pas archiver trop rapidement les mails - en général l’archivage automatique archive les mails vieux de plus de 3 mois - paramétrable par utilisateur/groupe.
L’installation n’utiliserait pas l’archivage au départ, cette option pourra être activée simplement par la suite, lorsque les 12To seront utilisés.
L’archivage de BlueMind peut se faire de façon déportée sur un serveur dédié, ou via un simple montage NFS.
Pas de virtualisation, pas de NAS ni SAN,…
Architecture imposée.
[quote=Toony]
Le backup sera fait comment ? En général, il est préférable d’avoir un espace dédié hors des serveurs - serveur dédié, ou plus simplement montage NFS.[/quote]
Backup sur les serveurs. L’idée c’est d’avoir un serveur Master et l’autre en Slave qui fait office de sauvegarde externe au serveur de production. Les deux serveurs sont dans des lieux différents (5 Km) reliés par fibre optique.
[quote=Toony]
Avec votre architecture, il serait bien d’utiliser les 12To pour l’espace BAL principale, ce qui permettrait un quota de ~6G par BAL - soit ~10 fois plus qu’actuellement. Et utiliser les 1.2To pour les index ES.[/quote]
En fait ce qu’on dit ne tient plus…
Je suis bien dans le … Les disques de 6To n’existent pas en 2,5" chez HP. Pas de RAID 5 12 To… A mieux je peux a priori espérer 2,4 To sauf à faire enter un disque 3,5" dans un rack 2,5"… :mad: :mad: :mad: :mad: :mad: :mad:
Donc je vais certainement devoir migrer sans donner plus de souplesse à mes utilisateurs.
Ah, ça change des choses effectivement…
Par contre, il s’agit d’un projet avec un de nos partenaires intégrateurs. Personnellement, je ne suis pas au fait de ce que vous vous êtes dit exactement concernant votre architecture.
Pour aller plus avant, je pense que le forum n’est pas le bon endroit dans votre cas, il faudrait faire un point avec notre partenaire pour prendre une décision. Je remonte ces informations de mon côté.
Un point est prévu vendredi avec eux.
L’idée était plus générale au départ sur le dimensionnement des bases mails avec les problématiques de sauvegardes…
12 To à sauvegarder c’est pas forcément facile avec certains systèmes…
En théorie je n’aurai pas fait comme cela parce qu’en théorie tout va bien…
Effectivement, pour de grosses volumétries de mail (12To par exemple), il est préférable de regarder vers les mécanismes de backup des baies par exemple.
Certains de nos clients se basent sur les fonctionnalités de snapshot de celle-ci. Dans ce cas, le backup BlueMind sauvegarde tout, sauf les mails.