Comment convaincre la direction que les 3560/3750 sont une mauvaise idée dans votre DC?

Les 3560/3750 ont de petits tampons et font de bons commutateurs de placard de câblage. Cependant, je vois très souvent ces commutateurs assis dans les DC. Beaucoup de gens ont tendance à les utiliser car ils sont généralement capables de 1 Go et L3.

Existe-t-il un moyen de prouver à quel point ils sont mauvais dans les déploiements DC? J'entends assez souvent des gens dire qu'ils ont retiré leur 3750 dès qu'ils le pouvaient, mais je n'ai pas encore entendu de scénario de défaillance réel qui pourrait être utilisé pour informer la direction de les retirer.

FWIW J'ai eu de l'expérience avec les 3750 (3750G, puis plus tard 3750E / 3560E) à grande échelle dans une configuration TOR; d'abord avec les ports port L2 / GLBP (variantes de 2x1G et 2x2G et les rares 2x4G pour les racks db), puis avec L3 au TOR (est allé avec cela pour 3750E / 3560E et 10G au cœur). J'en parle par milliers. Nous n'avons vu que des problèmes avec les tampons pour les services les plus gourmands en bande passante, et à ce moment-là, nous cherchions de la 10G pour l'hôte (et des boîtes à pizza denses avec 24-48 SFP +).

Que vous puissiez ou non prouver quoi que ce soit à la direction dépendra vraiment de l'application et de vos devoirs sur les exigences de votre conception et de l'application, et de savoir exactement quelles sont les spécifications de l'application , ainsi que sa vitesse de croissance attendue. Configurez une revue de conception avec votre chaîne de gestion ainsi qu'avec les principaux propriétaires / clients du réseau.

La direction veut voir les données , et si vous n'avez pas les ressources pour tester complètement la box (trouvez un plan de test, connectez-le à un matériel de génération de trafic, étendez-le complètement et testez-le aux spécifications de conception, etc) cela va être difficile à faire. Ils ne vont pas être impressionnés par des preuves anecdotiques, et trouver ce type de données dures peut s'avérer difficile, car je suis sûr que les gens qui publient ce genre de chose violeraient toutes sortes de NDA.

Tout le monde qui est affiché une réponse à ce qui a décrit la jolie « zones à problèmes » de la plate - forme 3750 bien: modes d'empilement et d' échec bizarre qui lui sont inhérents, la taille du tampon, etc. Il y a aussi cette question qui donne un aperçu des problèmes avec la collecte de statistiques SNMP sur les gouttes de file d'attente de sortie - les tampons sont partagés entre les ASIC, donc toutes les statistiques que vous obtenez avec cela via SNMP seront les mêmes pour des plages de ports spécifiques (cela pourrait être un point critique que vous pourriez apporter à votre chaîne de gestion).

Pour résumer, je dirais que le 3750/3560 conviendrait à la plupart des déploiements, même à des échelles assez importantes. Évitez de les empiler si vous le pouvez, mais je dirais que ce n'est pas trop horrible de le faire en très petites quantités et gérables.

Cela dépend vraiment de votre scénario de déploiement. Les 3560/3750 sont d'excellents commutateurs, ont des tampons décents et fonctionnent généralement bien pour la plupart des applications. Si votre centre de données voit des flux de trafic qui nécessitent des tampons plus importants, vous devriez pouvoir extraire des statistiques des commutateurs, comme l'utilisation du tampon et les pertes de paquets. Convaincre la direction de supprimer les commutateurs qui abandonnent leurs paquets ne devrait pas être trop difficile. Je pense.

Au début du 3750, en particulier la technologie d'empilement qui a été lancée juste avant 2010, il y avait beaucoup de problèmes avec les pannes de commutateur provoquant la défaillance de la pile d'une manière pas si gracieuse. Combinez cela avec le fait que la mise à niveau d'une pile n'était pas le processus le plus intuitif (il s'est amélioré depuis lors), le 3750 a vraiment eu une mauvaise réputation qui a collé depuis.

Dans les petits centres de données, la pile 3750 représente une option relativement peu coûteuse pour obtenir la densité de ports sans le coût d'un commutateur basé sur le châssis. J'ai moi-même installé pour un plus petit client une solution de centre de données impliquant quelques serveurs Cisco UCS C220 M3 avec un Netapp FAS2240, et j'ai utilisé une pile de 3750 pour fournir une redondance multi-châssis etherchannel à chaque nouveau périphérique ainsi qu'à tous leurs anciens serveurs pendant la transition. Ça a vraiment très bien fonctionné.

Alors - le 3750 a-t-il des problèmes? Probablement le même que tout autre commutateur qui existe depuis si longtemps. Le 6500 a eu ses problèmes au début de son cycle de vie, et maintenant qu'il est sorti depuis des années, ce n'est pas si mal. Je vous recommande de regarder ce que vous allez y jeter, et si les mesures de performance se maintiennent, assurez-vous de surveiller leurs performances avec vigilance.

Honnêtement, la façon la plus courante dont j'ai vu les 3750 heurter le trottoir était lorsque les commutateurs principaux ont été mis à niveau vers le Nexus 7k. Habituellement (mais pas toujours) une partie de cette actualisation consiste à déplacer TOR vers les Nexus 2000 FEX ou Nexus 5000.

Même si les 3750 n'ont pas les plus grands tampons, dans l'esprit de la plupart des gens, ils fonctionnent "assez bien" dans la plupart des environnements DC d'entreprise.

À moins que vous puissiez mettre une valeur en dollars sur les problèmes causés par la présence de 3560/3750 dans un DC, je doute que vous seriez en mesure de convaincre la direction de les remplacer en dehors d'un cycle de rafraîchissement de produit normal.

@mellowd a certainement raison, ces commutateurs ne sont pas des commutateurs CC très utilisables, en raison des tampons très limités, ils vont microrafler et baisser le trafic.

Considérez que vous avez une entrée 2 * 1GE et une sortie 1 * 1GE. Le pire scénario est que le port de sortie commence à chuter après que les ports d'entrée ont envoyé en même temps pendant 2 ms. Dans le meilleur des cas, vous pouvez gérer une rafale de 8 ms.

Vous avez 2 Mo de tampon de sortie pour 4 ports, donc 2 Mo / (1 Gbit / s) = 16 ms maximum et 16/4 = 4 ms minimum. Divisez ce nombre par le nombre de ports d'entrée à envoyer, et vous obtenez le nombre de fois que vous pouvez le gérer. Autrement dit, plus vous ajoutez de ports (serveurs) d'entrée, moins vous pouvez gérer les microrafales.

Si vous devez vivre avec 3750/3560, vous devriez lire ce document pour maximiser l'utilisation du tampon. Et si vous continuez à abandonner, utilisez LACP sur la sortie, même si vos graphiques montrent que la demande moyenne de sortie est très faible.

Pour prouver à vos gestionnaires que les tampons sont insuffisants, surveillez / appuyez / étendez vos réseaux actuels pour commuter toutes les liaisons descendantes, alors vous aurez des horodatages et des tailles de paquets qui sortiront et vous pouvez calculer combien de plus de 1 Gbps votre demande instantanée est et combien tampon dont vous aurez besoin pour le gérer.

Les performances sont certainement un problème important et sont bien abordées ci-dessus, mais il y a aussi beaucoup de différenciation en fonction des fonctionnalités et des ensembles de fonctionnalités:

1. Le besoin d'unités RPS externes est un énorme problème dans de nombreuses installations - un commutateur 1U devient plus cher en termes de coûts initiaux, d'espace perdu et de gestion continue. L'alimentation redondante doit être considérée comme une nécessité absolue dans tous les environnements de centre de données, sauf les plus petits.

2. Beaucoup, beaucoup de code inutile pour la connectivité de l'utilisateur final est en cours d'exécution - plus de possibilités pour les défauts, les problèmes de sécurité et les temps d'arrêt.

3. Les fonctionnalités DC (ISSU, DCB, stockage, certains éléments de script sur boîte) ne sont pas - et ne seront pas - sur les appareils axés sur le campus. Les mécanismes de gestion et de mise à l'échelle de l'extension L2 d'une manière saine (c'est-à-dire FabricPath / TRILL, OTV, VXLAN, etc.) ont également tendance à être absents de l'état actuel et des feuilles de route en dehors des produits DC. La liste ici ne fera que s'allonger - virtualisation sur boîte, prise en charge des mécanismes d'assistance matérielle, etc.

4. Évolutivité - Comment développez-vous l'infrastructure? Beaucoup, beaucoup de commutateurs (coûteux à gérer)? L'empilement (opérationnellement difficile, problèmes de câblage majeurs) est un gâchis. De plus, la flexibilité des types d'interface (fibre vs cuivre, par exemple) à la densité peut être difficile.

En général, les différences entre la commutation CC et la commutation de placard augmentent. Dans le monde Cisco, il existe des systèmes d'exploitation distincts (NXOS vs IOS) pour de très bonnes raisons - des exigences très différentes donnent des solutions divergentes. La vitesse des fonctionnalités pour les mécanismes d'authentification des utilisateurs (802.1x) ou l'intégration AV sophistiquée ne sont pas nécessaires dans le centre de données, tandis que la capacité de terminer des tonnes de 10GE n'est pas nécessaire dans le placard de câblage. Différents outils pour différents emplois. Un boîtier Nexus reliant des bureaux serait également un plan moins qu'idéal.

Je voudrais également vous indiquer les différents guides de conception (CVD, etc.) qui expliquent les types de commutateurs utilisés à différents points du réseau. Il y a quelque chose à dire pour les solutions qui ressemblent généralement aux meilleures pratiques courantes de l'industrie, et les commutateurs que vous mentionnez n'ont généralement pas leur place dans le DC - à l'exception des réseaux de gestion ou de certaines situations de connectivité locale dans certains cas particuliers.

J'ai un client qui les a déployés en tant que pile de commutateurs SAN (utilisant 3750X) avec le SAN connecté à 10 Gbit, puis leurs hôtes ESX connectés à Gbit (ou plusieurs Gbit à l'aide de LAG) et la quantité de chutes de sortie est astronomique, peu importe comment vous essayez de régler les tampons.

Le même client a deux autres piles 3750 dans le même DC pour d'autres réseaux et elles sont toutes propres.

TL; DR: Cela dépend vraiment du type de trafic que vous allez passer à travers la pile et de l'endroit où se trouvent vos goulots d'étranglement.

Les alimentations / ventilateurs du 3560/3750 ne sont pas remplaçables à chaud / une fois le commutateur monté et la panne inévitable de ces périphériques se produit, tous les serveurs doivent être débranchés du 3560/3750 pendant qu'il est démonté et remplacé par le RMA.

De plus, la direction du ventilateur sur les 3560/3750 devient un problème avec l'allée chaude / l'allée froide et d'autres configurations de refroidissement. Le montage des commutateurs là où les ports du commutateur font face à l'arrière des serveurs crée une situation où les ventilateurs du commutateur soufflent dans la mauvaise direction. Cela surchauffe le commutateur, ce qui le rend plus susceptible d'échouer / doit être remplacé.