"Stratégie de messagerie", sous Exchange

Messieurs,

Je dois rédiger un document de “x” pages, sur la “Stratégie de <ma_boîte> pour la messagerie”.
Au delà du fait que cela me soit imposé, va bien falloir que je fasse des propositions pour améliorer l’architecture existante.

Forcément, je me dis qu’ici il y aura les bons conseils.

> Architecture existante:

[indent][URL=http://img64.imageshack.us/i/capturewkk.png/][/URL] [URL=http://img405.imageshack.us/i/capture2ds.png/][/URL][/indent]

Basée autour d’une architecture Exchange 2007, sous Windows 2008 SP1:
[ul]
[li]2 serveurs de BAL composent un cluster “CCR” (copie de serveur A vers B ),[/li][li]2 serveurs CAS (webmail) et HUB (transport) virtuels sous une VM VMware 4.x,[/li][li]2 serveurs de dossiers publics PF et PF2 en VM VMware 4.x,[/li][li]7 groupes de stockage pour les BAL (mais on va passer sur 4 groupes de stockage de 160 Go chacun),[/li][li]2 groupes de stockage pour les dossiers publics,[/li][li]385 BAL utilisateurs,[/li][li]plus de 6000 dossiers publics (répliqués sur les deux serveurs PF et PF2),[/li][li]groupes de stockage hébergés sur un SAN NetApp dans des LUN,[/li][li]4 contrôleurs de domaine sous Windows 2008 R2,[/li][li]serveur BlackBerry Express 5 pour environ une centaine de terminaux.[/li][/ul]
> Ce qui marche bien:
[ul]
[li]L’antispam externe à Exchange, sous IronMail,[/li][li]Le cluster CCR et sa reprise d’activité en cas de rupture d’un des deux serveurs,[/li][li]Les CAS/HUB en VM marchent nickel,[/li][li]Les serveurs de messagerie du cluster CCR sont des monstres (8 CPU, 16 Go).[/li][/ul]
> Ce qui marche pas terrible:
[ul]
[li]Les performances du SAN sont juste dégueulasses (près de 125 ms en lecture) alors que les groupes de stockage Exchange sont montés sur des disque 15000 t./mn 600 Go…[/li][li]Les dossiers publics sont énormément utilisés. C’est l’un des points faibles de l’architecture. Bien que les serveurs PF et PF2 se répliquent entre eux à un intervalle d’1 minute, c’est sur ces dossiers publics que l’on rencontre le plus de soucis. Il faut que je fasse “évoluer” cela et pour cela j’ai deux scénarii : “basculer” les dossiers publics sur le cluster CCR, ou passer sur SharePoint (flippage).[/li][/ul]
> Pistes d’évolution :
[ul]
[li]remonter les dossiers publics des deux serveurs PF et PF2 dans le cluster CCR,[/li][li]Améliorer les putains de performance de merde du SAN (oui mais comment),[/li][li]Passer sous Exchange 2010 ? (oui mais pourquoi ? faudrait que je puisse le justifier techniquement),[/li][/ul]
> Mes questions :
[ul]
[li]Y’a un intérêt d’envisager en 2011 de passer sous Exchange 2010 ?[/li][li]SharePoint à l’air d’une usine à gaz, et faire bouger tous les utilisateurs vers cette nouvelle façon de travailler me paraît une tâche impossible… De3s retours là dessus ?[/li][li]Remonter les groupes de stockage de dossiers publics dans le cluster CCR : bonne idée ou cauchemard ?[/li][/ul]

J’ai n’ai pas d’aide a te proposer mais instinctivement balancer des schemas de ton archi interne , les versions des applis etc , avec une URL dans le schema , publiquement sur le net c’est pas le top de la securite non ?

J’me sens seul, je viens de me faire griller.
Certes, mais je suis méga confiant sur notre système de sécurité car … ce n’est pas moi qui le gère.

On a même une appliance réseau qui « simule » la présence de faux serveurs lors d’une attaque/query (port scan, tentative DOS).
Je sais plus son nom mais c’est assez vicieux : chaque fois que l’on a un port scan (par exemple) sur nos adresses IP publiques (et on en a une chiée), l’appliance répond sur de fausses adresses et de faux ports et simule ainsi la présence de fausses machines.
Huhu.
Cela nous coûte un rein mais on a pas le choix.

Wow, ça c’est de la super sécurité. :rolleyes:

Mais sinon, sur les vrais systèmes, on détecte le scan et on blackliste les IP src…

BIM A�?E.
Non mais ils ont cela aussi ^^.

C’est pas moi qui fait la sécurité réseau, heureusement. ^^
Bon, ok, de la à mettre mon schéma Exchange sur WikiLeaks ^^