DC에서 3560/3750이 나쁜 아이디어라고 경영진에게 어떻게 확신합니까?

3560/3750에는 버퍼가 작고 배선 실 스위치가 우수합니다. 그러나 나는 종종이 스위치들이 DC에 앉아있는 것을 본다. 많은 사람들이 일반적으로 1Gb 및 L3를 지원하므로 사용하는 경향이 있습니다.

DC 배포에서 얼마나 나쁜지 증명할 수있는 방법이 있습니까? 사람들이 최대한 빨리 3750을 제거했다는 말을 자주 듣지만 경영진이이를 알리는 데 사용할 수있는 실제 실패 시나리오는 아직 듣지 못했습니다.

FTORW 저는 TOR 설정에서 3750 년대 (3750G 이후 3750E / 3560E)를 경험 한 적이 있습니다. 처음에는 L2 포트 채널 / GLBP (2x1G 및 2x2G의 변형 및 db 랙의 경우 희귀 한 2x4G)가 있고 TOR에 L3이 있습니다 (3750E / 3560E 및 10G가 코어에 전송 됨). 나는 그들 중 수천을 이야기하고 있습니다. 우리는 가장 대역폭 집약적 인 서비스에 대한 버퍼 문제 만 보았고 , 그 시점에서 우리는 어쨌든 호스트를 10G로 바라 보았습니다 (24-48 SFP +의 밀도가 높은 피자 박스).

경영진에게 무엇인가를 증명할 수 있는지 여부는 실제로 응용 프로그램에 달려 있으며 설계 및 응용 프로그램의 요구 사항에 대한 숙제를하고 응용 프로그램 의 사양이 무엇 인지 정확히 알고 있어야합니다. 그것의 예상 성장 속도뿐만 아니라. 네트워크의 기본 소유자 / 고객뿐만 아니라 관리 체인을 사용하여 설계 검토를 설정하십시오.

경영진은 데이터 를보고 싶어하며 , 상자를 완전히 테스트 할 리소스가없는 경우 (테스트 계획이 나오면 일부 트래픽 생성 하드웨어에 연결하고, 전체 범위를 지정하고 설계 사양에 따라 스트레스 테스트를 수행하십시오. 등) 이것은 어려울 것입니다. 그들은 일화적인 증거에 감명받지 않을 것이며, 이런 종류의 자료를 출판하는 사람들이 모든 종류의 NDA를 위반할 것이라고 확신하기 때문에 이런 종류의 하드 데이터를 찾는 것이 어려울 수 있습니다.

이에 대한 답변을 게시 한 다른 모든 사람들은 3750 플랫폼의 "문제 영역"을 매우 훌륭하게 설명했습니다. 스태킹 및 이상한 장애 모드, 버퍼 크기 등. 출력 대기열 삭제시 SNMP 통계 수집 관련 문제를 설명하는 이 질문 도 있습니다. -버퍼는 ASIC에서 공유되므로 SNMP를 통해이 통계와 함께 얻는 통계는 특정 포트 범위에서 동일합니다 (관리 체인을 유지할 수있는 하나의 고집이 될 수 있음).

요약하자면, 3750/3560은 규모가 큰 경우에도 대부분의 배포 환경에서 "정밀"하다고 말할 수 있습니다. 가능하면 쌓아 두지 마십시오. 그러나 아주 작고 관리하기 쉬운 수량으로 이렇게하는 것이 너무 끔찍한 것은 아닙니다 .

실제로 배포 시나리오에 따라 다릅니다. 3560/3750은 훌륭한 스위치이며 적절한 버퍼를 가지고 있으며 대부분의 응용 프로그램에서 정상적으로 작동합니다. 데이터 센터에 더 큰 버퍼가 필요한 트래픽 흐름이 표시되면 버퍼 사용 및 패킷 삭제와 같은 스위치에서 통계를 가져올 수 있어야합니다. 패킷을 삭제하는 스위치를 삭제하도록 설득력있게 관리하는 것은 그리 어려운 일이 아닙니다. 내 생각 엔

3750 년대 초반, 특히 2010 년 이전에 출시 된 스태킹 기술에서는 스위치 오류로 인해 스택이 비정상적이지 않은 방식으로 실패하는 많은 문제가있었습니다. 스택을 업그레이드하는 것이 가장 직관적 인 프로세스가 아니라는 사실과 결합한 이후 (3750 년 이후로 개선 된) 3750은 그 이후로 명성이 나빠졌습니다.

소규모 데이터 센터에서 3750 스택은 섀시 기반 스위치 비용없이 포트 밀도를 얻는 비교적 저렴한 옵션을 나타냅니다. 저는 소규모 고객을 위해 Netapp FAS2240과 함께 일부 Cisco UCS C220 M3 서버와 관련된 데이터 센터 솔루션을 설치했으며 3750 개의 스택을 사용하여 각 새 장치와 모든 이전 서버에 다중 섀시 이더넷 채널 중복성을 제공했습니다. 전환하는 동안. 정말 잘 작동했습니다.

그렇다면-3750에 문제가 있습니까? 아마도 오랫동안 주변에 있었던 다른 스위치와 동일 할 것입니다. 6500은 수명주기 초기에 문제가 있었으며 이제 몇 년이 지났으므로 그렇게 나쁘지 않습니다. 무엇을 던질 지 살펴보고 성능 지표가 유지되는 경우 경계를 통해 성능을 모니터링해야합니다.

솔직히, 3750이 연석에 부딪 치는 것을 본 가장 일반적인 방법은 코어 스위치가 Nexus 7k로 업그레이드되었을 때였습니다. 일반적으로 이러한 새로 고침의 일부는 TOR을 Nexus 2000 FEX 또는 Nexus 5000으로 이동하는 것입니다.

3750에는 가장 큰 버퍼가 없지만 대부분의 사람들이 생각하기에 대부분의 엔터프라이즈 DC 환경에서 "충분히 작동"합니다.

DC에 3560/3750을 사용하여 발생하는 문제에 1 달러의 가치를 부여 할 수 없다면, 정기적 인 제품 교체주기 이외의 문제로 경영진이 교체하도록 설득 할 수 있을지 의심됩니다.

@mellowd는 확실히 옳습니다.이 스위치는 매우 사용 가능한 DC 스위치가 아닙니다. 버퍼가 매우 제한되어 있기 때문에 트래픽이 마이크로 버스트되고 떨어질 것입니다.

2 * 1GE 수신 및 1 * 1GE 송신이 있다고 가정하십시오. 최악의 시나리오는 송신 포트가 동시에 2ms 동안 전송 된 후 송신 포트가 드롭되기 시작한다는 것입니다. 가장 좋은 시나리오는 8ms 버스트를 처리 할 수 ​​있다는 것입니다.

4 포트 당 2MB의 송신 버퍼가 있으므로 2MB / (1Gbps / 8) = 최대 16ms 및 최소 16/4 = 4ms입니다. 전송하고자하는 수신 포트 수로이 수를 나누면 처리 할 수있는 시간이 늘어납니다. 즉, 더 많은 수신 포트 (서버)를 추가할수록 처리 할 수있는 마이크로 버스트가 줄어 듭니다.

3750/3560으로 살아야하는 경우 버퍼 사용을 최대화하려면 이 문서를 읽어야 합니다. 그리고 그래프에서 평균 송신 요구가 매우 낮음에도 불구하고 송신에서 LACP를 계속 사용하지 않는 경우.

버퍼가 부족하여 모니터 / 탭 / 스팬이 충분하지 않다는 것을 관리자에게 입증하기 위해 현재 네트워크가 모든 다운 링크를 전환하면 타임 스탬프와 패킷 크기가 커지고 순간적인 요구량과 1Gbps가 얼마인지 계산할 수 있습니다 버퍼 처리해야합니다.

성능은 확실히 중요한 문제이며 위에서 잘 다루어졌지만 기능 및 특징 세트에 따라 많은 차별화가 있습니다.

1. 외부 RPS 장치의 필요성은 많은 설치에서 큰 문제입니다. 1U 스위치는 초기 비용, 공간 손실 및 지속적인 관리 측면에서 더 비쌉니다. 가장 작은 데이터 센터 환경을 제외한 모든 환경에서 중복 전원을 절대적으로 고려해야합니다.

2. 최종 사용자 연결을위한 수많은 불필요한 코드가 실행 중이므로 결함, 보안 문제 및 가동 중지 시간이 늘어날 수 있습니다.

3. DC 기능 (ISSU, DCB, 스토리지, 특정 온 박스 스크립팅 요소)은 캠퍼스 중심 장치에 있지 않으며 앞으로도 그러하지 않을 것입니다. 또한 L2 확장을 적절하게 관리하고 확장하는 메커니즘 (예 : FabricPath / TRILL, OTV, VXLAN 등)도 현재 상태와 DC 제품 외부의 로드맵에서 누락되는 경향이 있습니다. 여기의 목록은 온 박스 가상화, HW- 어시스트 메커니즘 지원 등으로 증가 할 것입니다.

4. 확장 성 – 인프라를 어떻게 확장합니까? 많은 스위치가 있습니까 (관리 비용이 많이 듭니다)? 스태킹 (작동 상 어려움, 주요 케이블 문제)은 엉망입니다. 또한 밀도가 높은 인터페이스 유형 (예 : 섬유 대 구리)의 유연성이 어려울 수 있습니다.

일반적으로 DC와 옷장 스위칭의 차이가 커지고 있습니다. Cisco 세계에는 별개의 운영 체제 (NXOS 대 IOS)가 있으며, 그 이유는 매우 다양한 요구 사항으로 인해 다양한 솔루션을 제공합니다. 데이터 센터에는 사용자 인증 메커니즘 (802.1x) 또는 멋진 AV 통합을위한 기능 속도가 필요하지 않지만 배선 실에는 10GE 톤을 종료 할 수있는 기능이 필요하지 않습니다. 작업마다 다른 도구. 데스크톱을 연결하는 Nexus 박스도 이상적인 계획이 아닙니다.

또한 네트워크의 다양한 지점에서 사용되는 스위치 유형에 대한 이론적 근거를 제시하는 다양한 설계 가이드 (CVD 등)를 알려드립니다. 일반적으로 업계에서 가장 일반적인 관행과 유사한 솔루션에 대해 언급해야 할 사항이 있으며 언급 한 스위치는 일반적으로 관리 네트워크 나 특정 특수한 로컬 연결 상황을 제외하고는 DC에 존재하지 않습니다.

SAN을 10Gbit로 연결 한 후 3750X를 사용하여 SAN 스위치 스택으로 배치 한 고객이 있고 그 ESX 호스트가 Gbit (또는 LAG를 사용하여 여러 Gbit)로 연결되어 있고 출력 드롭의 양이 천문학적입니다. 버퍼를 시도하고 조정하는 방법.

동일한 고객은 다른 네트워크에 대해 동일한 DC에 두 개의 다른 3750 스택을 가지고 있으며 모두 깨끗합니다.

TL; DR : 실제로 스택을 통과 할 트래픽 유형과 병목 현상이있는 위치에 따라 다릅니다.

3560/3750 내의 전원 공급 장치 / 팬은 핫 스왑이 가능하지 않으며 스위치가 장착되고 이러한 장치의 불가피한 고장이 발생하면 3560/3750에서 모든 서버의 플러그를 뽑아 RMA로 교체해야합니다.

또한 3560/3750의 팬 방향은 열기 통로 / 냉기 통로 및 기타 냉각 설정에서 문제가됩니다. 스위치 포트가 서버의 후면을 향하는 위치에 스위치를 장착하면 스위치 팬이 잘못된 방향으로 날아가는 상황이 발생합니다. 스위치가 과열되어 고장 나거나 교체해야 할 가능성이 높아집니다.