Làm thế nào để bạn thuyết phục quản lý rằng 3560/3750 là một ý tưởng tồi trong DC của bạn?

3560/3750 có bộ đệm nhỏ và làm công tắc tủ quần áo tốt. Tuy nhiên tôi rất thường thấy các công tắc này ngồi trong DC. Rất nhiều người có xu hướng sử dụng chúng vì chúng thường có khả năng 1Gb và L3.

Có cách nào để chứng minh họ tệ như thế nào trong việc triển khai DC không? Tôi thường nghe mọi người nói rằng họ đã loại bỏ 3750 của họ ngay khi họ có thể, nhưng tôi chưa nghe thấy một kịch bản thất bại thực tế nào có thể được sử dụng để cho quản lý biết để đưa họ ra ngoài.

FWIW Tôi đã có kinh nghiệm với 3750 (3750G, và sau đó là 3750E / 3560E) ở quy mô trong thiết lập TOR; ban đầu với các kênh cổng L2 / GLBP (các biến thể của 2x1G và 2x2G và 2x4G hiếm cho các giá đỡ db) và sau đó với L3 thành TOR (đi kèm với điều này là 3750E / 3560E và 10G cho lõi). Tôi đang nói về hàng ngàn người trong số họ. Chúng tôi chỉ thấy các vấn đề với bộ đệm cho các dịch vụ cần nhiều băng thông nhất và tại thời điểm đó, chúng tôi đã xem xét 10G cho máy chủ (và các hộp pizza dày đặc với 24-48 SFP +).

Việc bạn có thể chứng minh bất cứ điều gì cho quản lý hay không thực sự phụ thuộc vào ứng dụng và bạn làm bài tập về các yêu cầu của thiết kế và ứng dụng của bạn là gì, và biết chính xác các thông số kỹ thuật của ứng dụng là gì , cũng như tốc độ tăng trưởng dự kiến ​​của nó. Thiết lập đánh giá thiết kế với chuỗi quản lý của bạn cũng như chủ sở hữu / khách hàng chính của mạng.

Ban quản lý muốn xem dữ liệu và nếu bạn không có tài nguyên để kiểm tra đầy đủ hộp (đưa ra kế hoạch kiểm tra, hãy kết nối nó với một số phần cứng tạo lưu lượng, tìm hiểu đầy đủ và kiểm tra căng thẳng với thông số thiết kế, vv) điều này sẽ khó thực hiện. Họ sẽ không ấn tượng với bằng chứng giai thoại và việc tìm kiếm loại dữ liệu cứng này có thể gây khó khăn, vì tôi chắc chắn rằng những người xuất bản loại điều này sẽ vi phạm tất cả các loại NDA.

Mọi người khác mà nhân đăng một câu trả lời cho điều này đã vạch ra "vấn đề khu vực" nền tảng của 3750 khá độc đáo: xếp chồng và thất bại lạ chế độ vốn có với nó, đệm kích thước, vv Ngoài ra còn có câu hỏi này mà phác thảo những vấn đề với việc thu thập số liệu SNMP trên giọt hàng đợi đầu ra - các bộ đệm được chia sẻ trên các ASIC, do đó, bất kỳ số liệu thống kê nào bạn nhận được thông qua SNMP này sẽ giống nhau cho các phạm vi cổng cụ thể (đây có thể là một điểm gắn bó bạn có thể đưa ra với chuỗi quản lý của mình).

Tóm lại, tôi muốn nói rằng 3750/3560 sẽ "ổn" đối với hầu hết các triển khai, ngay cả ở quy mô hơi lớn. Tránh xếp chồng chúng nếu bạn có thể, nhưng tôi nói rằng sẽ không quá kinh khủng khi làm điều này với số lượng rất nhỏ và có thể quản lý được.

Nó thực sự phụ thuộc vào kịch bản triển khai của bạn. 3560/3750 là công tắc tuyệt vời, có bộ đệm tốt và chúng thường hoạt động tốt cho hầu hết các ứng dụng. Nếu trung tâm dữ liệu của bạn nhìn thấy các luồng lưu lượng yêu cầu bộ đệm lớn hơn, bạn sẽ có thể lấy số liệu thống kê từ các công tắc, như sử dụng bộ đệm và giảm gói. Quản lý thuyết phục để loại bỏ các công tắc đang bỏ các gói của họ không phải là một thách thức quá lớn. Tôi nghĩ.

Trong những ngày đầu của 3750, đặc biệt là công nghệ xếp chồng được phát hành ngay trước năm 2010 hoặc lâu hơn, đã có rất nhiều vấn đề với lỗi chuyển đổi khiến cho ngăn xếp bị hỏng theo cách không duyên dáng. Kết hợp với thực tế rằng việc nâng cấp một ngăn xếp không phải là quá trình trực quan nhất (nó đã được cải thiện kể từ đó), 3750 thực sự có tiếng xấu đã bị mắc kẹt kể từ đó.

Trong các trung tâm dữ liệu nhỏ, ngăn xếp 3750 đại diện cho một tùy chọn chi phí tương đối thấp để có được mật độ cổng mà không tốn chi phí chuyển đổi dựa trên khung. Bản thân tôi chỉ cài đặt cho một khách hàng nhỏ hơn một giải pháp trung tâm dữ liệu liên quan đến một vài máy chủ Cisco UCS C220 M3 với Netapp FAS2240 và tôi đã sử dụng một chồng 3750 để cung cấp dự phòng etherchannel đa khung cho mỗi thiết bị mới cũng như tất cả các máy chủ cũ của họ trong quá trình chuyển đổi. Nó làm việc thực sự, thực sự tốt.

Vậy - 3750 có vấn đề gì không? Có lẽ giống như bất kỳ công tắc nào khác đã tồn tại lâu nay. 6500 có vấn đề sớm trong vòng đời của nó, và bây giờ nó đã được phát hành trong nhiều năm và nó không quá tệ. Tôi khuyên bạn nên xem những gì bạn sẽ ném vào nó, và nếu các số liệu về hiệu suất giữ vững, thì hãy chắc chắn rằng bạn theo dõi hiệu suất của chúng một cách thận trọng.

Thành thực mà nói, cách phổ biến nhất mà tôi thấy 3750 đã vào lề đường, là khi các công tắc cốt lõi được nâng cấp lên Nexus 7k. Thông thường (nhưng không phải luôn luôn) một phần của việc làm mới đó là chuyển TOR sang Nexus 2000 FEX hoặc Nexus 5000.

Mặc dù những chiếc 3750 không có bộ đệm lớn nhất, nhưng trong suy nghĩ của hầu hết mọi người, chúng vẫn hoạt động "đủ tốt" trong hầu hết các môi trường DC của doanh nghiệp.

Trừ khi bạn có thể đặt giá trị đồng đô la cho các vấn đề gây ra bởi việc có 3560/3750 trong DC, tôi nghi ngờ bạn có thể thuyết phục ban quản lý thay thế chúng ngoài chu kỳ làm mới sản phẩm thông thường.

@mellowd chắc chắn là đúng, những công tắc này không phải là công tắc DC rất tiện dụng, do bộ đệm rất hạn chế, chúng sẽ vi mạch và giảm lưu lượng.

Hãy xem xét bạn có 2 * 1GE xâm nhập và đi ra 1 * 1GE. Trường hợp xấu nhất là, cổng đầu ra bắt đầu giảm sau khi các cổng vào được gửi cùng lúc trong 2ms. Trường hợp tốt nhất là, bạn có thể xử lý vụ nổ 8ms.

Bạn có 2 MB bộ đệm đầu ra cho mỗi 4 cổng, vì vậy 2MB / (1Gbps / 8) = tối đa 16ms và tối thiểu 16/4 = 4ms. Chia số đó cho số lượng cổng vào muốn gửi và bạn sẽ nhận được số lượng thời gian bạn có thể xử lý nó. Đó là, bạn càng thêm nhiều cổng vào (máy chủ), bạn càng ít xử lý vi mạch.

Nếu bạn phải sống với 3750/3560, bạn nên đọc tài liệu này để tối đa hóa việc sử dụng bộ đệm. Và nếu bạn vẫn bỏ sử dụng LACP khi đi ra, mặc dù biểu đồ của bạn cho thấy nhu cầu đi ra trung bình rất thấp.

Để chứng minh cho người quản lý của bạn biết rằng bộ đệm không đủ màn hình / tap / span mạng hiện tại của bạn chuyển tất cả các liên kết xuống, sau đó bạn sẽ có dấu thời gian và kích thước gói đi ra và bạn có thể tính toán nhu cầu tức thời của bạn trên 1Gbps là bao nhiêu và bao nhiêu bộ đệm bạn sẽ cần phải xử lý nó.

Hiệu suất chắc chắn là một vấn đề quan trọng và được giải quyết tốt ở trên nhưng cũng có nhiều điểm khác biệt dựa trên các tính năng và bộ tính năng:

1. Nhu cầu về các đơn vị RPS bên ngoài là một vấn đề lớn trong nhiều cài đặt - công tắc 1U trở nên đắt hơn về chi phí ban đầu, mất không gian và quản lý liên tục. Công suất dự phòng nên được coi là phải tuyệt đối trong tất cả các môi trường ngoại trừ trung tâm dữ liệu nhỏ nhất.

2. Rất nhiều và rất nhiều mã không cần thiết cho kết nối người dùng cuối đang chạy - nhiều cơ hội hơn cho các lỗi, vấn đề bảo mật và thời gian chết.

3. Các tính năng DC (ISSU, DCB, lưu trữ, một số yếu tố kịch bản trên hộp) không - và sẽ không - trên các thiết bị tập trung vào khuôn viên trường. Các cơ chế để quản lý và mở rộng quy mô mở rộng L2 theo cách lành mạnh (ví dụ FabricPath / TRILL, OTV, VXLAN, v.v.) cũng có xu hướng bị thiếu trong cả trạng thái hiện tại và lộ trình bên ngoài các sản phẩm DC. Danh sách ở đây sẽ chỉ phát triển - ảo hóa trên hộp, hỗ trợ các cơ chế hỗ trợ CTNH, v.v.

4. Khả năng mở rộng - Làm thế nào để bạn phát triển cơ sở hạ tầng? Rất nhiều và rất nhiều thiết bị chuyển mạch (đắt tiền để quản lý)? Xếp chồng (hoạt động khó khăn, các vấn đề cáp lớn) là một mớ hỗn độn. Ngoài ra, tính linh hoạt của các loại giao diện (ví dụ như sợi so với đồng) ở mật độ có thể là thách thức.

Nhìn chung, sự khác biệt giữa DC và chuyển đổi tủ quần áo đang gia tăng. Trong thế giới của Cisco, có các hệ điều hành riêng biệt (NXOS so với IOS) vì những lý do rất chính đáng - những yêu cầu rất khác nhau mang lại giải pháp khác nhau. Tốc độ tính năng cho các cơ chế xác thực người dùng (802.1x) hoặc tích hợp AV ưa thích không cần thiết trong trung tâm dữ liệu trong khi khả năng chấm dứt hàng tấn 10GE không cần thiết trong tủ nối dây. Công cụ khác nhau cho các công việc khác nhau. Một hộp Nexus kết nối máy tính để bàn cũng sẽ là một kế hoạch ít hơn lý tưởng.

Tôi cũng sẽ chỉ cho bạn các hướng dẫn thiết kế khác nhau (CVD, v.v.) để đưa ra lý do cho các loại công tắc được sử dụng tại các điểm khác nhau trong mạng. Có điều gì đó để nói về các giải pháp thường giống với thực tiễn phổ biến nhất trong ngành và các thiết bị chuyển mạch mà bạn đề cập thường không có chỗ trong DC - ngoài mạng quản lý hoặc một số tình huống kết nối cục bộ đặc biệt.

Tôi đã có một khách hàng đã triển khai chúng như một ngăn xếp chuyển đổi SAN (sử dụng 3750X) với SAN được kết nối ở mức 10Gbit và sau đó các máy chủ ESX của họ được kết nối tại Gbit (hoặc nhiều Gbit sử dụng LAG) và lượng giảm đầu ra là không có vấn đề cách bạn cố gắng và điều chỉnh bộ đệm.

Cùng một khách hàng có hai ngăn xếp 3750 khác trong cùng một DC cho các mạng khác và tất cả đều sạch.

TL; DR: Nó thực sự phụ thuộc vào loại lưu lượng truy cập bạn sẽ đi qua ngăn xếp và nơi tắc nghẽn của bạn.

Bộ nguồn / quạt trong vòng 3560/3750 không thể hoán đổi nóng / một khi công tắc được gắn và sự cố không thể tránh khỏi của các thiết bị này xảy ra, tất cả các máy chủ phải được rút ra khỏi 3560/3750 trong khi nó không được ngắt và thay thế bằng RMA.

Ngoài ra, hướng quạt trên 3560s / 3750 trở thành một vấn đề với lối đi nóng / lối đi lạnh và các thiết lập làm mát khác. Việc gắn các công tắc nơi các cổng chuyển đổi đối diện với mặt sau của máy chủ sẽ tạo ra tình huống quạt công tắc thổi sai hướng. Điều này quá nóng công tắc làm cho nó có nhiều khả năng thất bại / cần thay thế.