iSCSI 가상 IP 장애 조치에서 Xen DomU 루트 파일 시스템이 읽기 전용이 됨

내 Xen 서버는 iSCSI SAN 클러스터에 대한 open-iscsi가있는 openSUSE 11.1입니다. SAN 모듈은 이니시에이터가 연결하는 가상 IP 뒤의 IP 장애 조치 그룹에 있습니다.

기본 SAN 서버가 다운되면 보조 서버가 대상 역할을 수행합니다. 이것은 모두 LeftHand SAN / iQ 소프트웨어에 의해 처리되며 대부분의 상황에서 잘 작동합니다.

내가 가진 문제는 때때로 내 Xen DomU의 일부가 IP 장애 조치 후 루트 파일 시스템이 읽기 전용으로 이동한다는 것입니다. 일관성이 없으며 장애 조치가 발생할 때마다 다른 하위 집합에 발생합니다. 그들은 모두 동일한 openSUSE 11.1 소프트웨어 이미지를 실행하고 있습니다.

각 DomU의 루트 파일 시스템은 Dom0에서 open-iscsi로 마운트 된 다음 Xen은 표준 블록 장치 드라이버를 사용하여 DomU에 노출시킵니다.

정확한 증상은 루트 권한으로 touch /test"읽기 전용 파일 시스템"오류를 반환한다는 것입니다. 그러나 출력은 mount읽기-쓰기로 마운트 된 것으로 표시합니다. 물론, domU의 다른 모든 I / O도이 시점에서 실패하므로 시스템이 다운됩니다. xmiSCSI 세션을 다시 연결하지 않고도 Dom0에서 다시 시작하기 만하면 모든 것이 다시 작동합니다.

Dom0 측에서 페일 오버 중 syslog 메시지는 다음과 같습니다.

kernel: connection1:0: iscsi: detected conn error (1011)
iscsid: Kernel reported iSCSI connection 1:0 error (1011) state (3)
iscsid: connection1:0 is operational after recovery (1 attempts) 

이 문제를 디버깅 할 계층을 파악하는 데 어려움을 겪고 있습니다. DomU 커널에 있습니까? 또는 Dom0 또는 Xen 수준입니까? 어딘가에 시간 초과를 늘리기 위해 조정해야 할 매개 변수가 있다고 생각하지만 어디를 봐야할지 모르겠습니다.

연결된 블록 장치가 여전히 Dom0에서 읽고 쓸 수 있기 때문에 open-iscsi의 문제라고 생각하지 않습니다.

결국 open-iscsi 설명서의 다음 조언과 설정을 사용 하여이 문제를 해결했습니다.

8.2 iSCSI settings for iSCSI root
---------------------------------

When accessing the root parition directly through a iSCSI disk, the
iSCSI timers should be set so that iSCSI layer has several chances to try to
re-establish a session and so that commands are not quickly requeued to
the SCSI layer. Basically you want the opposite of when using dm-multipath.

For this setup, you can turn off iSCSI pings by setting:

node.conn[0].timeo.noop_out_interval = 0
node.conn[0].timeo.noop_out_timeout = 0

And you can turn the replacement_timer to a very long value:

node.session.timeo.replacement_timeout = 86400

위에서 설명한대로 각 LUN에 대한 연결을 설정 한 후 장애 조치는 몇 분이 걸리더라도 매력처럼 작동합니다.

이것은 dom0에서 실행되는 iSCSI 초기 자의 문제처럼 들립니다. 이니시에이터는 SCSI 오류를 스택으로 빠르게 보내지 않아야합니다. iscsi.conf에서 ConnFailTimeout을 설정하고 싶을 것입니다. 이것은 연결 실패를 오류로 간주하기 전의 시간을 결정하고 해당 오류를 SCSI 스택으로 보냅니다.

또한 장애 조치가 실제로 걸리는 시간을 살펴보고 예상보다 오래 걸릴 수 있습니다. 그렇다면 ARP 관련 문제로 인해 VIP 장애 조치가 너무 오래 걸리는 것 같습니다.

장애 조치시 dom0에 모든 종류의 읽기 / 쓰기 오류 또는 scsi 오류를 나타내는 메시지가 있습니까? 그렇다면이 쓰기 오류가 domU로 전달되는 것처럼 보입니다. domU는 iSCSI 장치임을 "알지 못"하므로 기본 디스크가 사라진 것처럼 동작하고 파일 시스템을 읽기 전용으로 다시 마운트합니다 (mount (1) 맨 페이지-참조 errors=continue / errors=remount-ro / errors=panic).

dom0의 관점에서는 읽기 전용으로 변경되지 않습니다.이 읽기 전용 동작은 블록 장치 시맨틱이 아니라 파일 시스템 시맨틱입니다.

현재 "다른 모든 I / O가 실패했습니다"라고 언급했습니다. domU 또는 dom0을 의미합니까?

일반적으로 HA iSCSI 솔루션을 설정할 때 가상 IP 인계 대신 다중 경로를 사용합니다. 호스트에 대한 가시성을 높이고 iSCSI 세션이 갑자기 사라지지 않고 다시 시작해야 할 필요가 없습니다. 항상 2 개만 있습니다 . 이 환경에서 이것이 옵션입니까?

음 ... 문제의 일부는 RO를 실행하지 않는다는 것입니다. 보안 모범 사례에서는 "/"를 ro로 마운트하고 rw가 필요한 모든 파일 시스템을 별도로 마운트해야합니다 (예 : / var 및 / tmp). / etc에 쓰기가 필요한 디렉토리가 있으면 / var / etc / path로 이동하고 / etc로 심볼릭 링크해야합니다.

"/"는 단일 사용자 모드에서만 RW로 마운트되어야합니다.

이 방식으로 설정하면 다른 제안과 함께 위의 상황에서 segfault를 방지 할 수 있습니다.