안녕하세요. iSCSI Failover 시간에 대한 글 하나 남깁니다.
아래 내용은 사실 퓨어스토리지 웹사이트에 잘 설명이 되어있어서 그냥 옮긴것이라고 보시면 됩니다.
호스트에서 케이블을 제거할 경우에는 호스트입장에서 케이블이 다운된것을 바로 인지할 수 있기 때문에, (SCSI Sense code 중 No connection 등이 발생함으로) Failover 에 걸리는 시간이 오래 걸리지 않지만, 스토리지에서 Failover 가 발생할 때에는 ESXi 입장에서는 물리 Cable 연결이 끊어진것이 아니기 때문에, 해당 Path 가 다운되었다라는 부분을 인지할 때까지 필요한 시간이 있습니다.
그렇게 되는 이유는 아래와 같은 시간이 필요하기 때문입니다.
기본적으로 ESXi 는 스토리지쪽으로 NOP-out request 라는 것을 보냅니다. (스토리지에서 호스트로 보내는것은 NOP-in 이라고 합니다.)
ESXi 에서는 기본적으로 15초에 한번씩 NOP-out request 스토리지로 보내도록 되어있고 (NoopOutInterval) 이라는 값이 지정이 되어있습니다. (물론 경우에 따라 15초보다 짧은 시간안에 나갈수도 있습니다.)
그럼 ESXi 는 Request 를 보낸뒤에 최대 얼마동안 기다리느냐, 10초까지 기다리도록 되어있습니다. (NoopOutTimeout)
만약 10초동안 응답이 오지 않으면 ESXi 는 자체적으로 iSCSI 세션을 Recovery 하는 시도를 하게 됩니다. 그럼 이 시도를 얼마동안 하느냐 10초동안 합니다(iSCSI Recovery time). 디폴트로 10초로 정의되어있고, 최소 1초, 맥시멈 120초로 설정할 수 있습니다.
정리하면,
- NOP-OUT request 가 iSCSI Target (스토리지) 쪽으로 15초마다 보내짐.
- ESXi 는 스토리지로부터 Response 가 올때까지 (NOP-in) 최대 10초를 기다림.
- 10초안 응답이 오지 않으면 iSCSI Session recovery 시도가 10초 동안 진행됌.
- 실제 Path 에 문제가 있는경우 Recovery IO 가 전달되지 않기 때문에, Path 가 Dead 로 마킹됌.
그럼 15 + 10 + 10 해서 35초가 최대 로 해당 Path 로의 I/O 가 중단될 수 있는 시간이라 보면 되며, 보통은 25~28초 정도 소요되는 편입니다.
그럼 VM 입장에서 봤을 때 하나의 Path 가 죽었을 때 왜 문제가 될 수 있느냐, 일반적으로 Storage I/O 는 이전에 보낸 I/O 가 Complete 되어야 다음 I/O 를 보낼 수 있기 떄문입니다. 앞의 I/O 가 끝나지 않으면 iSCSI Initiator 는 앞의 I/O 가 완료되거나 아님 실패난것으로 확인될때까지 I/O 를 추가적으로 보내지 않고 대기하게 됩니다. 완전히 Path 가 죽었다고 판단할때까지 I/O 는 중단되는 것이죠.
윈도우의 경우 디스크 타임아웃(Host disk timeout)이 60초, 리눅스의 경우 180초로 설정이 되기 때문에 (- VMware tools 설치시) 35초 정도의 Failover 타임은 잠깐 I/O 가 멈출수는 있으나 OS 차원에서 문제가 되는 수준은 아닙니다. 다만 어플리케이션에 따라서 DB 와 같은 것들은 I/O 에 민감함으로 문제가 될 수 있습니다.
그럼 위에 값을 줄일 수 있느냐, 위에서 이야기한 NoopOutInterval & Recovery Time 은 좀 더 줄일 수 있습니다. 다만 줄인다는 이야기는 그만큼 Path 의 상태에 민감해진다는 의미로, False positive 를 발생시킬 수 있는 요인이기도 합니다.
참고로 위 설정 조정하면 Reboot 필요합니다.
퓨어 쪽에서 권장하는 설정값 조정은 다음과 같습니다. (조정이 필요한 경우)
NoopOutInterval – 5 seconds
NoopOutTimeout – 10 seconds
RecoveryTime – 5 seconds
위 경우라면 보통 15~16초 사이에서 failover 가 된다고 하네요.
참조 KB : Understanding the storage path failover sequence in VMware ESXi native multipathing (1027963)
추가적으로 Failover 발생시에는 모든 링크에서의 I/O 도 중단 되는데요, 그 이유는 다음과 같습니다.
So why does all I/O pause for that amount of time when a single path is lost? Well, since applications are often reliant on previous I/O completing the initiator pauses all I/O to the target, down all paths, until the state of the suspect path(s) and all pending I/Os are determined. Since there is a chance it could recover and I/O is just completing slower than normal it doesn’t want to prematurely fail or retry until it is certain things are down. After all, recovery of an environment, especially prematurely, can cause just as many problems. That is what timers are for after all to dictate safe zones for specific actions to be taken!