Nous obtenons une paire de nouveaux commutateurs 8 Gb pour notre structure Fibre Channel. C'est une bonne chose car nous manquons de ports dans notre centre de données principal, et cela nous permettra d'avoir au moins un ISL 8 Go fonctionnant entre nos deux centres de données.
Nos deux centres de données sont distants d'environ 3,2 km lorsque la fibre fonctionne. Nous obtenons un service 4Gb solide depuis quelques années maintenant, et j'ai bon espoir qu'il puisse également supporter 8Gb.
J'essaie actuellement de reconfigurer notre structure pour accepter ces nouveaux commutateurs. En raison de décisions en matière de coûts il y a quelques années, nous n'exécutons pas de structure à double boucle entièrement séparée. Le coût d'une redondance totale était considéré comme plus cher que le temps d'indisponibilité improbable d'une panne de commutateur. Cette décision a été prise avant mon temps, et depuis lors, les choses ne se sont pas beaucoup améliorées.
Je voudrais profiter de cette occasion pour rendre notre structure plus résistante face à une panne de commutateur (ou à une mise à niveau de FabricOS).
Voici un schéma de ce que je pense pour une mise en page. Les éléments bleus sont nouveaux, les éléments rouges sont des liens existants qui seront (re) déplacés.
(source: sysadmin1138.net )
La ligne fléchée rouge est la liaison actuelle du commutateur ISL, les deux ISL proviennent du même commutateur. L'EVA6100 est actuellement connecté aux deux commutateurs 16/4 dotés d'un ISL. Les nouveaux commutateurs nous permettront d'avoir deux commutateurs dans le DC distant, certains des ISL à longue portée se déplacent vers le nouveau commutateur.
L'avantage est que chaque commutateur n'est pas à plus de 2 sauts d'un autre commutateur et que les deux EVA4400, qui seront dans une relation de réplication EVA, sont à 1 saut l'un de l'autre. L'EVA6100 dans le tableau est un appareil plus ancien qui sera éventuellement remplacé, probablement par un autre EVA4400.
La moitié inférieure du graphique indique l'emplacement de la plupart de nos serveurs, et je m'inquiète du placement exact. Ce qui doit y aller:
- 10 hôtes VMWare ESX4.1
- Accède aux ressources sur l'EVA6100
- 4 serveurs Windows Server 2008 dans un cluster à basculement unique (cluster de serveurs de fichiers)
- Accède aux ressources de l'EVA6100 et de l'EVA4400 distant
- 2 serveurs Windows Server 2008 dans un deuxième cluster de basculement (contenu Blackboard)
- Accède aux ressources sur l'EVA6100
- 2 serveurs de base de données MS-SQL
- Accède aux ressources sur l'EVA6100, avec des exportations nocturnes de DB vers l'EVA4400
- 1 bandothèque LTO4 avec 2 lecteurs de bande LTO4. Chaque disque possède son propre port de fibre.
- Les serveurs de sauvegarde (pas dans cette liste) se mettent en file d'attente vers eux
Pour le moment, le cluster ESX peut tolérer jusqu'à 3, voire 4, hôtes qui ne fonctionnent pas avant de devoir arrêter les machines virtuelles pour de l'espace. Heureusement, tout a été activé par MPIO.
Les liens ISL 4Gb actuels ne sont pas proches de la saturation que j'ai remarquée. Cela peut changer avec la réplication des deux EVA4400, mais au moins l'un des ISL sera de 8 Go. En regardant les performances que je tire de l'EVA4400-A, je suis très certain que même avec du trafic de réplication, nous aurons du mal à traverser la ligne 4Gb.
Le cluster de serveurs de fichiers à 4 nœuds peut avoir deux nœuds sur SAN1SW4 et deux sur SAN1SW1, car cela mettra les deux baies de stockage à un bond.
Les 10 nœuds ESX sont un peu effrayants. Trois sur SAN1SW4, trois sur SAN1SW2 et quatre sur SAN1SW1 est une option, et je serais très intéressé d'entendre d'autres opinions sur la mise en page. La plupart d'entre eux ont des cartes FC à double port, donc je peux exécuter deux nœuds en double. Pas tous , mais suffisamment pour permettre à un seul commutateur de tomber en panne sans tout tuer.
Les deux boîtiers MS-SQL doivent aller sur SAN1SW3 et SAN1SW2, car ils doivent être proches de leur stockage principal et les performances d'exportation de base de données sont moins importantes.
Les lecteurs LTO4 sont actuellement sur SW2 et 2 sauts de leur streamer principal, donc je sais déjà comment cela fonctionne. Ceux-ci peuvent rester sur SW2 et SW3.
Je préférerais ne pas faire de la moitié inférieure du graphique une topologie entièrement connectée car cela réduirait notre nombre de ports utilisables de 66 à 62, et SAN1SW1 serait de 25% ISL. Mais si c'est fortement recommandé, je peux emprunter cette voie.
Mise à jour: quelques chiffres de performances qui seront probablement utiles. Je les avais, j'ai juste espacé qu'ils sont utiles pour ce genre de problème.
EVA4400-A dans le tableau ci-dessus fait ce qui suit:
- Pendant la journée de travail:
- Les opérations d'E / S en moyenne sous 1000 avec des pointes à 4500 pendant les instantanés ShadowCopy du cluster de serveurs de fichiers (dure environ 15-30 secondes).
- Les Mo / s restent généralement dans la plage de 10 à 30 Mo, avec des pointes allant jusqu'à 70 Mo et 200 Mo pendant ShadowCopies.
- Pendant la nuit (sauvegardes) c'est quand ça pédale vraiment vite:
- Les opérations d'E / S se situent en moyenne autour de 1500, avec des pointes jusqu'à 5500 lors des sauvegardes de bases de données.
- Le Mo / s varie beaucoup, mais fonctionne sur environ 100 Mo pendant plusieurs heures et pompe un impressionnant 300 Mo / s pendant environ 15 minutes pendant le processus d'exportation SQL.
L'EVA6100 est beaucoup plus occupé, car il héberge le cluster ESX, MSSQL et un environnement Exchange 2007 complet.
- Au cours de la journée, les opérations d'E / S atteignent en moyenne environ 2000 avec des pics fréquents allant jusqu'à environ 5000 (davantage de processus de base de données) et des Mo / s en moyenne entre 20 et 50 Mo / s. Le pic de Mo / s se produit pendant les instantanés ShadowCopy sur le cluster de service de fichiers (~ 240 Mo / s) et dure moins d'une minute.
- Pendant la nuit, la défragmentation en ligne Exchange qui fonctionne de 1 h à 5 h pompe des E / S Ops vers la ligne à 7800 (proche de la vitesse de flanc pour un accès aléatoire avec ce nombre de broches) et 70 Mo / s.
J'apprécierais toute suggestion que vous pourriez avoir.