현재 생산 중인 Brocade Silkworm 200e 스위치가 하나 있습니다. Corp exchange 서버와 3개의 ESX 3.5 호스트가 이를 통해 clariion cx3 어레이에 연결됩니다. 포트 0,1은 SPA0과 1이고, 포트 4,5는 SPB0과 1입니다.
내 계획은 200 옆에 Brocade Silkworm 300 스위치를 추가하고(이미 랙에 장착되어 전원이 켜져 있음) 데이터 센터로 가서 200에서 SPA1과 SPB0을 꺼내 300 스위치의 포트에 삽입하는 것입니다.
나는 생산 중인 FC 경로를 꺼내는 것에 대해 약간 편집증적입니다. 저는 모든 것이 SPA0과 SPB1, A1과 B0으로 장애 조치될 것이라는 논리적인 가정을 갖고 있습니다. 그러나 가능하다면 위험을 더욱 최소화하기 위해 무엇을 할 수 있는지 100% 확실히 이해하고 싶습니다.
현재 SPA가 LUN을 소유하고 있는 경우 라운드 로빈에서 자동으로 SPA0과 SPA1을 모두 활용합니까, 아니면 장애가 발생하지 않는 한 스위치는 특정 경로를 독점적으로 선호합니까? 예 - 교환 서버가 SPA0 또는 SPA1을 사용합니까, 아니면 0과 1 활성/활성을 모두 사용합니까?
SP 활성/활성에 대한 두 경로를 모두 사용하는 경우 다른 경로를 이미 문제 없이 사용하고 있다고 확신하기 때문에 둘 중 하나를 방해하는 것이 위험이 더 적다고 추측합니다. 이전에 사용하지 않은 대체 경로로 장애 조치를 강제로 수행한 후 케이블이 이상하다는 것을 알게 될까 두렵습니다.
잘못된 장애 조치가 발생하는 경우 데이터 손상이 발생하지 않도록 회사에 완전히 지장을 주고 모든 가상 머신과 교환 서버를 종료해야 합니까? 아니면 이건 과한 걸까요? 어느 쪽이든 전체 백업 주기 후에 즉시 작업을 수행하겠습니다.
장애 조치(failover)가 발생하면 어떻게 모니터링하시겠습니까? 브로케이드 200e에서는 자세하게 로그가 나오나요? 나는 플러그를 뽑았을 때 모든 것이 여전히 작동한다는 것을 최대한 보장하고 싶습니다. esx 호스트의 스토리지를 다시 검색하고 exchange의 powerpath 모니터를 볼 수 있습니다. 내가 할 수 있는 것보다 더 나은 것이 있나요?
나는 우리의 모든 계란이 이 한 바구니에 담겨 있을 때 처음으로 이런 일을 하는 것에 대해 과신적인 가정을 하는 것보다 상황의 이점보다 훨씬 더 조심하는 편이 낫습니다.
답변1
귀하의 계획이 두 번째 독립 패브릭을 설정하는 것이기를 바랍니다. 일반적으로 이는 좋은 생각으로 간주됩니다.
서버에 여러 개의 HBA가 있는지 여부는 밝히지 않았습니다. 중복 패브릭을 적절하게 재구성할 수 있기를 바랍니다. 그러나 그렇지 않은 경우 즉각적인 계획에 큰 영향을 미치지는 않습니다.
Powerpath는 Exchange 서버에 대한 페일오버를 처리하며 A0 연결이 끊어지면 A1을 통한 경로를 선택해야 하며, 두 SPA 포트 모두에 장애가 발생하지 않는 한 B0이나 B1이 아닌 경로를 선택해야 합니다. 작동하지 않는 경로가 있으면 이를 알려주거나 최소한 예상한 경로를 볼 수 없게 됩니다. 사용 중인 Powerpath 버전(예: SE 버전 또는 정식 라이센스 버전)에 따라 로드 밸런싱 다중 경로 정책이 활성화될 수 있지만 어떤 경우에도 설명하는 설정에 대해 경로 페일오버가 안정적이어야 합니다. 활성 경로의 연결이 끊어지면 Powerpath는 실패한 IO가 정상인 경우 대체 경로를 통해 해당 IO를 다시 라우팅합니다. Powerpath GUI 내에서 경로 상태를 확인하거나 명령줄을 사용하여 powermt check실패한\새 경로를 확인하거나 powermt restore데드\새 경로를 확인 및 제거\추가할 수 있습니다. 로드 밸런싱을 위한 경로 정책이 이미 설정되어 있고 SPA0과 SPA1을 모두 통해 표시되는 정상 경로가 있는 경우(예를 들어) 모든 것이 정상이라는 매우 높은 수준의 확신을 갖게 됩니다.
ESX 서버에서는 VI 클라이언트->구성->스토리지 탭 내에서 각 LUN에 사용 가능한 경로를 확인할 수 있습니다. 속성에서 활성 및 대기 상태의 사용 가능한 경로를 볼 수 있으며 경로 관리 대화 상자에서 정책(Fixed\MRU\Round Robin)을 변경할 수 있습니다. 아무 것도 변경할 필요가 없지만 다시 한 번 사용하려는 장애 조치 경로가 사용 가능한지 확인해야 합니다. 마찬가지로 ESX의 다중 경로 스택은 페일오버를 처리합니다. IO가 활성 경로에서 이동 중인 경우 IO가 실패했음을 감지하면 다른 경로로 다시 보냅니다. ESX 3.5는 실험적으로 라운드 로빈 다중 경로 지정만 지원하므로 이 경우에는 문제를 일으키고 싶지 않습니다. 사전 대응을 원할 경우 일시적으로 고정 경로 정책을 설정하고 LUN을 원하는 경로로 강제 이동할 수 있지만 CX3의 표준 설정은 MRU에 두는 것이므로 괜찮습니다.
두 경우 모두 장애 조치가 발생하기 전에 약간의 지연이 있을 수 있으며 IO가 잠시 멈출 수 있지만 중복 경로가 실제로 정상이라면 아무것도 실패하지 않아야 합니다.