파이버 채널 패브릭을위한 새로운 8Gb 스위치가 제공됩니다. 기본 데이터 센터의 포트가 부족하여 두 가지 데이터 센터간에 최소 8Gb ISL을 둘 수 있습니다.
파이버가 작동함에 따라 두 개의 데이터 센터는 약 3.2km 떨어져 있습니다. 우리는 몇 년 동안 견고한 4Gb 서비스를 받고 있으며 8Gb를 유지할 수 있기를 바랍니다.
저는 현재 이러한 새로운 스위치를 수용하도록 패브릭을 재구성하는 방법을 알아 내고 있습니다. 몇 년 전 비용 결정으로 인해 우리는 완전히 분리 된 이중 루프 패브릭을 실행 하지 않습니다 . 전체 중복 비용은 스위치 고장의 다운 타임보다 비용이 많이 드는 것으로 나타났습니다. 그 결정은 내 시간 전에 이루어졌으며 그 이후로 많은 것이 개선되지 않았습니다.
이 기회를 통해 스위치 오류 (또는 FabricOS 업그레이드)에 직면 할 때 패브릭을보다 탄력적으로 만들려고합니다.
다음은 내가 계획하고있는 것을 보여주는 다이어그램입니다. 파란색 항목은 새롭고 빨간색 항목은 (이동) 될 기존 링크입니다.
(출처 : sysadmin1138.net )
빨간색 화살표는 현재 ISL 스위치 링크이며 두 ISL 모두 같은 스위치에서 나옵니다. EVA6100은 현재 ISL이있는 16/4 스위치 모두에 연결되어 있습니다. 새로운 스위치를 사용하면 원격 DC에 두 개의 스위치를 사용할 수 있으며 장거리 ISL 중 하나가 새 스위치로 이동합니다.
이것의 장점은 각 스위치가 다른 스위치에서 2 홉을 넘지 않고 EVA- 복제 관계에있는 2 개의 EVA4400이 서로 1 홉이라는 것입니다. 차트의 EVA6100은 구형 EVA이며 다른 EVA4400으로 대체 될 것입니다.
차트의 아래쪽 절반은 대부분의 서버가있는 위치이며 정확한 배치에 대한 우려가 있습니다. 거기에 들어가야 할 것 :
- 10 개의 VMWare ESX4.1 호스트
- EVA6100의 리소스에 액세스
- 하나의 장애 조치 클러스터 (파일 서버 클러스터)에있는 Windows Server 2008 서버 4 대
- EVA6100 및 원격 EVA4400의 리소스에 액세스
- 두 번째 장애 조치 클러스터의 Windows Server 2008 서버 2 개 (칠판 콘텐츠)
- EVA6100의 리소스에 액세스
- 2 개의 MS-SQL 데이터베이스 서버
- 매일 밤 DB를 EVA4400으로 내보내는 EVA6100의 리소스에 액세스
- 2 개의 LTO4 테이프 드라이브가있는 1 개의 LTO4 테이프 라이브러리. 각 드라이브에는 고유 한 파이버 포트가 있습니다.
- 백업 서버 (이 목록에 없음)가 서버에 스풀링됩니다.
현재 ESX 클러스터는 공간을 확보하기 위해 VM을 종료하기 전에 최대 3 개의 호스트, 4 개의 호스트가 다운되는 것을 허용 할 수 있습니다. 다행히 모든 것이 MPIO를 켰습니다.
현재 4Gb ISL 링크는 내가 주목 한 채도에 가깝지 않습니다. 두 개의 EVA4400 복제시 변경 될 수 있지만 ISL 중 적어도 하나는 8Gb입니다. 내가 EVA4400-A에서 얻는 성능을 보면 복제 트래픽이 있어도 4Gb 회선을 통과하는 데 어려움을 겪을 것이라고 확신합니다.
4 노드 파일 서비스 클러스터는 SAN1SW4에 2 개의 노드를, SAN1SW1에 2 개의 노드를 가질 수 있습니다. 그러면 두 스토리지 배열이 모두 한 홉 거리에 놓이게됩니다.
10 개의 ESX 노드가 다소 머리를 긁었습니다. SAN1SW4에 3 개, SAN1SW2에 3 개, SAN1SW1에 4 개는 옵션이며 레이아웃에 대한 다른 의견을 듣고 싶습니다. 이들 중 대부분에는 이중 포트 FC 카드가 있으므로 몇 개의 노드를 두 번 실행할 수 있습니다. 그들 모두는 아니지만 하나의 스위치가 모든 것을 죽이지 않고 실패 할 수있을 정도로 충분합니다.
두 MS-SQL 박스는 SAN1SW3 및 SAN1SW2에서 기본 스토리지에 근접해야하고 db-export 성능이 덜 중요하므로 SAN1SW3과 SAN1SW2로 이동해야합니다.
LTO4 드라이브는 현재 메인 스 트리머의 SW2 및 2 홉에 있으므로 작동 방식을 이미 알고 있습니다. 그것들은 SW2와 SW3에 남아있을 수 있습니다.
사용 가능한 포트 수를 66에서 62로 줄이고 SAN1SW1은 25 % ISL이므로 차트의 아래쪽 절반을 완전히 연결된 토폴로지로 만들고 싶지 않습니다. 그러나 그것이 강력히 권장된다면 그 길을 갈 수 있습니다.
업데이트 : 아마도 유용한 성능 수치입니다. 나는 이런 종류의 문제에 유용하다고 생각했습니다.
위 차트의 EVA4400-A는 다음을 수행합니다.
- 근무일 동안 :
- I / O ops는 파일 서버 클러스터 ShadowCopy 스냅 샷 (약 15-30 초 동안) 동안 4500으로 급상승하는 평균 1000 미만입니다.
- MB / s는 일반적으로 10-30MB 범위로 유지되며 ShadowCopies 동안 최대 70MB 및 200MB로 급증합니다.
- 밤 동안 (백업) 실제로 페달을 빠르게 밟을 때입니다.
- I / O ops는 평균 약 1500이고 DB 백업 중에 최대 5500이 급증합니다.
- MB / s는 매우 다양하지만 몇 시간 동안 약 100MB로 실행되며 SQL 내보내기 프로세스 중에 약 15 분 동안 300MB / s의 인상적인 펌핑을 수행합니다.
EVA6100은 ESX 클러스터, MSSQL 및 전체 Exchange 2007 환경의 홈이기 때문에 훨씬 더 바쁩니다.
- 하루 동안 I / O ops는 평균 약 2000 개 (최대 데이터베이스 프로세스)가 잦은 급격한 증가와 평균 20-50MB / s의 MB / s로 약 2000입니다. 최대 MB / s는 파일 서비스 클러스터에서 ShadowCopy 스냅 샷 중 발생하며 (~ 240MB / s) 1 분 미만 지속됩니다.
- 밤 동안 오전 1 시부 터 오전 5 시까 지 실행되는 Exchange Online 조각 모음은 7800 (이 스핀들 수에 임의로 액세스하기 위해 측면 속도에 가깝습니다) 및 70MB / s의 라인으로 펌프 I / O Op를 펌핑합니다.
당신이 가진 제안에 감사드립니다.
답변
지연 돼서 죄송합니다.
당신이 가진 것과 당신이 달성하고자하는 것을 보았을 때, 나는 몇 가지 생각을했습니다. 여기에 멋진 그림이 있습니다 …
- 지금 당장 사이트간에 8Gbps 링크를 사용하는 것은 아무 의미가 없습니다. 그 이유는 원격 4400의 4Gbps 포트에 의해 제약을 받았기 때문에 이미 안정적인 4Gbps를 가지고 있으며 가용 대역폭이 실제 사용 요구 사항보다 훨씬 높습니다 -오늘날 24×8 스위치 중 하나를 설치하는 것은 낭비입니다. 원격 사이트에서 16x4Gb 스위치 중 2 개를 사용합니다.
- 새로운 24×8 스위치를 주요 ‘핵심’스위치로 사용하고 싶습니다. 대부분의 트래픽은 서버 대 6100이며 새 상자는 훨씬 빠릅니다. 이렇게하면 새로운 스위치에 더 큰 버퍼와 대기 시간이 줄어들 기 때문에 약간의 작은 성능 향상을 볼 수있을뿐만 아니라 6100을 교체 할 때와 동일하게 원하는 때에 8Gb로 이동할 서버를 선택하고 선택할 수 있습니다. 4600에는 기본 8Gb 포트가 있지만 아직 공식적이지는 않습니다.;)).
- 그런 다음 두 가지 옵션이있는 디자인의 일부로 들어갑니다. 순전히 포트 수를 기준으로 두 개의 16x4Gb ‘중간 스위치’를 유지하거나 버립니다. 기본적으로 24×8 스위치를 코어 박스로 사용하는 경우 3 개의 예비 포트만 있습니다 (18 개의 서버에 18을 사용하고 6100에 2를 사용하고 21을 사용하는 ISL 링크를 사용함). 넌 할 수있어로컬 4400을 24×8 스위치에 연결하면 테이프 드라이브에 정확히 1 개의 포트를 사용할 수 있지만 사용 가능한 포트는 0이됩니다. 내가 유혹하고 싶은 것은 2 개의 16x4Gb ‘중간 스위치’를 로컬 4400 및 테이프 드라이브를 처리하거나 원하는 경우 사이트 간 ISL 링크를 처리하는 보조 로컬 스위치로 사용하는 것입니다. 원하는 경우 24x8Gb 스위치에서 무료로 직접 수행 할 수 있습니다. 정말 비슷하기 때문에 두 가지를 모두 표시하지 않았습니다.
그래서 그것은 내 생각입니다-온갖 조정이 있지만 내 일반적인 아이디어가 있습니다-어떤 명확한 설명으로 나에게 자유롭게 돌아 오십시오.