EMS(Emergency Message Service)의 활용

MCCS는 별도 상용 제품인 EMS(Emergency Message Service)를 통해서 해당 시스템의 심각한 오류나 장애가 발생했을 경우, 자동으로 서버 관리자와 MCCS 제품 서비스 담당자에게 문자 메시지를 전송합니다.
또한 웹 기반의 통합 관제 콘솔을 제공함으로써 인터넷을 통하여 언제 어디서든지 장애 현황을 한 눈으로 파악할 수 있으며, 과거의 장애 이력 검색, 관리, 보고서 작성 등을 쉽게 할 수 있습니다.

EMS 구성요소

EMS 에이전트

MCCS가 설치되는 서버에서 동작하는 프로그램으로 EMS 서버와 통신을 합니다.

EMS 서버

MCCS 제품 유지 보수를 담당하는 업체에 설치된 서버 프로그램을 말합니다.

EMS 업무 흐름

로그 저장

EMS 에이전트가 로그를 저장합니다.
다음과 같은 LogType 속성을 이용하여 EMS 서버에 저장될 로그 종류를 지정할 수 있습니다.

H

HA 관련 로그로 저장됩니다.
(파일감시만 지정 가능합니다.)

A

애플리케이션 관련 로그로 저장됩니다.
(파일감시만 지정 가능합니다.)

S

Windows 시스템 이벤트 로그로 저장됩니다.
(Windows event감시만 지정 가능합니다.)

P

프로세스 관련 로그로 저장됩니다.
(파일감시만 지정 가능합니다.)

로그 분석

EMS 서버 이용자는 EMS 서비스를 받고자 하는 시스템에 대하여 장애 레벨을 설정할 수 있습니다.
EMS 서버는 설정된 장애 레벨을 필터로 사용해서 EMS 에이전트가 실시간으로 전송한 운영 서버의 시스템 로그 및 MCCS 로그를 분석하여 장애 여부를 판단합니다.

SMS 통보

정해진 필터에 의해 장애 감지가 확인되면 EMS는 시스템 담당 운영자와 MCCS 제품 서비스 담당자의 휴대폰에 장애 내용을 SMS(문자메시지)로 통보하여 신속하게 대응할 수 있도록 합니다.

EMS 서버 접속 후, 장애 원인 분석

시스템 담당 운영자 및 MCCS 제품 서비스 담당자는 인터넷 연결이 가능한 곳에서 EMS 서버에 접속하여 장애가 발생한 서버의 로그를 살펴보고 장애 원인을 분석합니다.
또한 제조업 관련 고객사인 경우, EMS 서버를 별도로 구축하면 제품 제조 공정에서 운영되고 있는 수많은 이중화 서버들을 중앙에서 모니터링 할 수 있으며, 통계 정보를 통하여 기간별 장애 유형과 장애 처리 내용들을 검색할 수 있습니다.
다음은 EMS 시스템의 업무 흐름을 도식화 한 것입니다.

[그림] EMS 시스템의 업무 흐름도

EMS 서버의 통합 모니터링 화면

다음은 EMS 서버에서 제공하는 통합 모니터링 화면의 일부입니다.
장애가 발생한 서버는 붉은 색으로, 장애 발생 후에 서버 관리자가 이를 인지하고 정상화 과정에 있는 서버는 노란색으로 표시되며, 파란색으로 표시된 서버는 정상 상태임을 나타냅니다.
물론 EMS 서버에 등록된 사용자는 해당 사용자가 관리하는 서버에 대해서만 내용을 확인할 수 있습니다.

[그림] EMS 시스템의 이중화 서버 모니터링 화면

[그림] EMS 시스템의 통계 화면

서버 장애

각 장치(NIC, Raid Controller)의 드라이버 충돌, 기타 응용프로그램의 커널 드라이버 문제 등으로 시스템이 자동 재부팅 또는 셧다운 되는 경우입니다.

운영 서버 장애 

1. 서버의 정상 혹은 비정상 종료에 따른 MCCS의 역할에는 차이점이 없습니다. MCCS는 운영 서버에서 장애가 발생하면 대기 서버로 페일오버를 진행합니다.
   화면의 오른쪽에 있는 노드 관리에서 해당 서버를 선택하면 '리소스 상태' 및 '리소스 의존성' 화면을 통하여 장애를 확인할 수 있습니다.
   • 정상 종료 사용자가 운영체제에서 '시스템 종료'를 선택한 경우를 말합니다.
   • 비정상 종료 블루스크린 또는 예기치 않은 상황으로 인해 시스템 종료 혹은 재부팅 되는 경우를 말합니다.
   
   [그림] 운영 서버 장애 발생 화면
   
   
2. 서버 장애로 인해 데이터를 복제 할 수 없기 때문에 미러 디스크 리소스 부분 에표시가 생깁니다.
3. 서버 운영자는 장애를 발생시킨 부분을 확인하여 서버를 정상화 시켜야 합니다.
4. 장애가 발생한 서버가 다시 부팅이 되면 MCCS는 두 서버간의 상호 미러 역할을 확인 후 장애가 발생한 서버를 복제 타깃으로 설정하고 부분 동기화를 진행합니다.

대기 서버 장애

1. 대기 서버에 장애가 발생하면 MCCS는 해당 서버에 장애 발생을 표시합니다.
2. 대기 서버가 정상화 되기 전까지 데이터 복제를 잠시 중단합니다.
   
   [그림] 대기 서버 장애 발생 화면
   
   
3. I/O가 계속 발생된다면 데이터 동기화가 불가능해지고 미러 디스크가 'Paused' 상태()가 됩니다.
4. 만일, I/O 발생이 없다면 미러 디스크의 아이콘 부분에 아무런 변화가 나타나지 않지만 MCCS 로그 창에는 미러 디스크 관련 장애 메시지가 나타납니다.
5. 대기 서버에서 장애가 발생하면 운영 상에는 문제가 없지만 페일오버할 대상이 없으므로 서버 운영자는 반드시 MCCS 웹 콘솔을 통하여 장애를 확인하고 대기 서버를 정상화 시켜야 합니다.
6. 대기 서버가 다시 정상으로 돌아오면 'Paused'  에서 'Mirroring' 상태로 변경되면서  아이콘이 사라집니다.
   

응용프로그램 장애

운영중인 응용프로그램 리소스에 대하여 MCCS는 다음과 같은 4가지 요소에 의해 동작을 하게 됩니다.

• MonitorInterval (기본값=10초)
  설정된 값을 주기로 리소스를 감시합니다. 
• MonitorTimeout (기본값=10초)
  설정된 값 만큼 응답이 오지 않으면 장애로 판단합니다. 
• RestartLimit (기본값=0)
  설정된 값만큼 해당 응용프로그램 리소스를 재시작합니다. 
• OnlieTrustTime (기본값=600초) 
  리소스 재시작 횟수를 재설정하는 시간입니다. 
  위의 속성값들은 해당 리소스를 등록할 때 설정된 값이고, 사용자는 각 리소스의 속성 페이지를 통하여 값을 수정하거나 확인할 수 있습니다. 
  
  [그림] 리소스 속성값 수정 화면
  
  

1. MCCS는 MonitorInterval에 의해서 해당 리소스를 감시합니다.
2. MonitorTimeout에 설정된 시간만큼 응답이 없으면 해당 리소스가 장애라고 판단합니다.
3. RestartLimit에 설정된 횟수만큼 해당 리소스에 재시작 명령을 내려도 응답이 없으면 MCCS는 그 리소스가 속해 있는 그룹을 페일오버합니다.
4. 리소스가 OnlineTrustTime에 정의되어 있는 시간 동안 정상 상태를 유지하면 MCCS는 RestartLimit의 속성값을 초기화 합니다. 왜냐하면 리소스에 장애가 발생할 경우에 재시작 횟수를 보장하기 위해서입니다.
5. 응용프로그램 장애로 인해 페일오버가 되었다면 서버 운영자는 장애를 발생시킨 부분을 확인하여 정상화 시켜야 합니다.
6. 장애가 발생한 부분은 MCCS 웹 콘솔에서 확인할 수 있으며, 장애가 발생한 부분을 사용자가 확인한 후에 장애 표시를 제거해 주어야 다시 페일오버 기능이 활성화됩니다.
   자동으로 장애 표시를 제거하고자 할 경우에는 그룹 속성의 AutoFaultClearTime에 0보다 큰 값을 설정하면 됩니다. 
7. 장애가 발생한 서버가 다시 부팅이 되면 MCCS는 두 서버간의 상호 미러 역할을 확인한 후에 장애가 발생한 서버를 복제 타깃으로 설정하고 동기화를 진행합니다.
   
   
   [그림] 리소스 장애 표시 제거 화면
   
   

네트워크 장애 

네트워크 장애는 네트워크 스위치나 네트워크 카드 고장, 네트워크 케이블 단절 또는 특정 네트워크로의 Ping 타임아웃 발생 등의 문제로 통신 장애가 발생되는 경우를 말합니다.

• 서비스 네트워크 장애 

  운영 서버에서 서비스 네트워크 장애가 발생하면 MCCS 웹 콘솔의 네트워크 주소 또는 네트워크 카드 리소스부분에 장애 표시가 되고 대기 서버로 페일오버를 진행합니다.

  
  [그림] 네트워크 카드 장애 표시 화면

  
  

1. 서비스 네트워크 장애는 장애가 발생한 부분을 MCCS 웹 콘솔에서 확인할 수 있습니다.
2. MCCS는 네트워크 장애가 발생된 서버의 네트워크 케이블 단절 또는 특정 네트워크로의 Ping 타임아웃 발생 유무를 확인합니다.
3. 네트워크 주소 리소스가 장애 원인이라면 사용자는 네트워크 스위치 또는 네트워크 카드부터 점검해야 합니다. 네트워크와 관련된 물리적인 부분들이 정상화 된 후에는 MCCS  웹 콘솔에서 '장애표시제거' 메뉴를 선택하여 장애 표시 항목을 제거합니다. 이 때부터는 페일오버가 가능한 상태가 됩니다.
4. 자동으로 장애 표시를 제거하려면 그룹 속성의 AutoFaultClearTime에 0보다 큰 값을 설정하면 됩니다. 
   
   

• 핫빗 네트워크 장애 

  핫빗은 노드 상호간의 상태를 동기화하고 장애 상태를 결정하는 중요한 역할을 하기 때문에 반드시 이중화되어 있어야 합니다. 이중화된 핫빗 네트워크 중에서 어느 하나라도 장애가 발생하면 장애 내용은 로그창에 표시 됩니다. 
  하지만 MCCS 웹 콘솔에는 아무런 변화가 나타나지 않습니다. 이것은 운영 서버와 대기 서버에는 아무런 문제가 없다는 것을 뜻합니다. 
  이 때, 운영 서버에 문제가 생겨 대기 서버로 페일오버 해야 할 상황이 발생하면 MCCS는 장애가 발생하지 않은 정상적인 핫빗 네트워크를 이용하여 페일오버를 진행하게 됩니다. 
  만일 이중화된 핫빗 모두가 단절된 상황이라면 MCCS는 서비스 네트워크를 이용하여 핫빗 통신을 하게 됩니다.

          [그림] 핫빗 장애 발생 화면

1. 핫빗 장애는 MCCS 로그, 윈도우 시스템 로그에서 장애 내역을 확인할 수 있습니다. 
   핫빗 장애가 발생하면 서버 관리자는 서버의 TCP/IP, 물리적인 연결 상태 및 ping 테스트를 통해 핫빗이 정상적인 상태인지를 확인해야 합니다.
2. 만약 비정상적인 상황이라면 카드 불량, 케이블 연결 불량 혹은 케이블 단선 등을 확인하고 장애 원인을 제거해야 합니다.
   
   

• 복제 네트워크 장애 

  복제 네트워크에 장애가 발생하면 데이터 복제를 진행할 수 없으며, MCCS 웹 콘솔의 미러 디스크 리소스 부분이  'Pause' 상태()로 표시 됩니다.

  
  [그림] 복제 네트워크 장애 발생 화면

  
  

1. 복제 네트워크 장애는 MCCS 로그, 윈도우 시스템 로그에서 장애내역을 확인할 수 있습니다. 복제 네트워크 장애가 발생하면 서버 관리자는 서버의 TCP/IP, 물리적인 연결상태 및 ping 테스트를 통해 복제 네트워크가 정상적인 상태인지를 확인해야 합니다.
2. 만약 비정상적인 상황이라면 카드 불량, 케이블 연결 불량 혹은 케이블 단선 등을 확인하고 장애 원인을 제거해야 합니다.
   
   

• 단일 네트워크 스위치 장애 

  단일 네트워크 스위치로 구성된 환경에서 Public Network에 연결된 네트워크 스위치에 장애가 발생하면 운영 서버 및 대기 서버의 모든 그룹 리소스가 오프라인이 되며, 장애가 발생한 리소스는 '장애' 상태로 표시 됩니다.

  
  [그림] 네트워크 스위치 장애 발생 화면

  
  

1. 네트워크 스위치 장애는 MCCS 로그, 윈도우 시스템 로그에서 장애 내역을 확인할 수 있습니다. 
   서버 관리자는 케이블 연결 상태 및 ping 테스트를 통해 해당 네트워크 스위치 상태 및 네트워크 연결 상태를 확인하고 장애 원인을 제거해야 합니다.
2. 자동으로 장애 표시를 제거하려면 그룹 속성의 AutoFaultClearTime에 0보다 큰 값을 설정하면 됩니다.
3. 네트워크 스위치 장애에 대한 복구는 해당 제조사를 통하여 지원 받으시기 바랍니다.
   
   

디스크 장애

미러 디스크 장애 (내장 스토리지)

• 소스 디스크 장애 

  운영 서버의 미러 디스크 리소스에 장애가 발생하면 MCCS 웹 콘솔에 장애가 표시됩니다.
  MCCS는 해당 디스크에 Read/Write가 불가능한 상황이므로 장애로 인식하여 대기 서버로 페일오버를 진행합니다. 

   

  [그림] 미러 디스크 장애 발생 화면

  
  

1. MCCS에서 디스크에 대한 장애 감지 방식은 다음과 같습니다.
   • 해당 디스크가 마운트 되어 있는지 확인 합니다. 
   • 해당 디스크에 대해서 Read/Write를 실행합니다.
2. 디스크 장애 발생 요인은 다음과 같은 경우가 있을 수 있습니다. 위의 문제가 해결 된 후에 운영 체제는 변경된 디스크를 다시 인식합니다.이후 복제 소프트웨어에서 동기화를 진행합니다.
   • 디스크 컨트롤러 문제 하드웨어 자체의 문제는 해당 업체에서 해결해야 합니다.
   • 물리적인 디스크 문제 하드웨어 자체의 문제는 해당 업체에서 해결해야 합니다.
3. 미러 리소스에서 동기화가 진행되지 않으면 미러디스크 리소스를 삭제한 후에 다시 생성해야 합니다. 단, 삭제 시 리소스만 삭제가 아니라 생성된 미러까지 삭제하고 다시 생성해야 합니다. 
   
   

• 타깃 디스크 장애 

  대기 서버의 디스크에 장애가 발생하면 MCCS 웹 콘솔의 디스크 리소스 아이콘에 'Pause'가 표시됩니다. 그러나 소스 서버에서 운영중인 서비스에는 영향을 미치지 않습니다.

  
  [그림] 타깃 디스크 장애 발생 화면

  
  

1. MCCS에서 타깃 디스크에 대한 장애 감지는 해당 디스크의 드라이브 문자가 있는지 없는지 만을 판단합니다.
2. 디스크 장애 발생 요인은 다음과 같은 경우가 있을 수 있습니다.위의 문제가 해결 된 후에 운영 체제는 변경된 디스크를 다시 인식합니다.이후 복제 소프트웨어에서 동기화를 진행합니다.
   • 디스크 컨트롤러 문제 하드웨어 자체 문제는 해당 업체에서 해결해야 합니다.
   • 물리적인 디스크 문제 하드웨어 자체 문제는 해당 업체에서 해결해야 합니다.
3. 미러 리소스에서 동기화가 진행되지 않으면 미러디스크 리소스를 삭제한 후에 다시 생성해야 합니다. 단, 삭제 시 리소스만 삭제가 아니라 생성된 미러까지 삭제하고 다시 생성해야 합니다.  
   
   

• 미러 디스크 리소스의 Split Brain

  매우 드문 경우이지만 두 서버상에서 미러 디스크 역할이 모두 소스로 인식되는 경우입니다.
  이러한 상황은 타깃이 소스로 변경되는 시점에 기존 소스가 타깃으로 변경되지 못한 결과이며, 이 때는 서로 자신의 데이터를 동기화하려 하지만 데이터를 받는 상대 서버 역시 자신이 소스 서버인 상태이므로 역할 변경을 거부하게 됩니다.
  미러 디스크에서 Split Brain이 발생하는 상황은 다음과 같습니다.

1. 소스 서버(A) 장애로 인해 페일오버가 발생합니다.
2. MCCS에서 SWITCHOVERVOLUME 명령을 실행합니다.
3. 기존 소스 볼륨이 삭제되지 않고 타깃 서버(B)의 역할이 소스로 변경됩니다. (미러 디스크 역할 변경)
4. 최초의 소스 서버(A)를 재부팅합니다.
5. 최초의 소스 서버(A)가 부팅된 후에 타깃 서버(B)의 역할을 확인합니다.
6. 타깃 서버(B)가 소스이면 최초의 소스 서버(A)는 이미 정상적으로 페일오버 되었다고 판단하고 자신을 타깃으로 변경합니다.
7. 미러 네트워크 이상 또는 다른 오류로 인하여 부팅 시점에 이 역할을 확인할 수 없게 됩니다. (5, 6번 과정 확인 실패)
8. 양 서버의 미러 역할이 모두 소스가 됩니다. (Split Brain 발생)
   
   이러한 상태가 되면 MCCS 웹 콘솔상에서 미러 디스크 리소스의 아이콘 표시가 겹쳐서 나타나며(), MirrorRole 속성값이 두 서버에 대해 모두 'Source'로 표시됩니다.
   이러한 경우에는 미러 디스크 역할을 수동으로 변경해야 하며, 변경한 후에는 재동기화 과정이 발생합니다.
   미러 디스크 역할을 수동으로 변경하는 방법은 MCCS 웹 콘솔을 이용하면 됩니다.

•  MCCS 웹 콘솔을 사용해서 스플릿브레인을 해결하는 방법

1. 리소스 속성창을 확인합니다.
   
   [그림] 미러디스크 스플릿 브레인 확인

   
   

2. 미러 관리창을 확인합니다.

   
   [그림] 미러디스크 스플릿 브레인 확인

    

   1) 양 노드의 MirrorRole은 Source, MirrorState은 MIRROR_PAUSED 상태가 됩니다.
   2) 미러디스크의 TimeAquiredSourceRole을 확인합니다. (TimeAquiredSourceRole은 시스템의 시간이므로 최신 데이터의 유무를 결정할 수 있는 절대값이 아닙니다.)
   3) 스플릿 브레인이 발생했을 때 발생하는 로그가 출력됩니다. 
   (윈도우즈 이벤트 오류: An invalid attempt to establish a mirror occurred. Both systems were found to be Source. 
   Local Volume: F Remote system: 200.200.124.49 Remote Volume: F The mirror has been paused, or left in its current non-mirroring state. 
   Use the DataKeeper User Inteface to resolve this Split Brain condition.)
   4) 미러 관리창에서 미러 상태가 'SPLIT' 상태입니다.

3. 미러디스크를 선택하고 오른쪽 버튼을 클릭하여 '스플릿 브레인 해결'을 클릭합니다.
   
   [그림] 스플릿 브레인 해결  선택
   
   
4. 스플릿브레인에 대한 설명창이 출력됩니다.
    
   [그림] 소스 노드 선택에 대한 내용 확인
   
   
5. 소스노드를 선택합니다.
   
   [그림] 소스 롤 노드 선택
   
   
6. 선택한 소스노드에 대해 다시 한번 확인합니다.
   
   [그림] 소스 노드 선택 다시 확인
   
   
7. 스플릿해결 중인 화면입니다.
   
   [그림] 스플릿 브레인 해결 화면
   
   
8. 스플릿해결 완료 화면입니다.
   
   [그림] 스플릿 브레인 해결 완료 화면
   
   

9. 선택한 노드가 소스노드가 되고 미러디스크의 상태는 MIRRORING 상태로 바뀌게 됩니다. 
   
   [그림] 스플릿 브레인 해결
   
   

   노드 B 의 변경된 정보는 모두 덮어써지게 됩니다

    

공유 디스크 장애 (외장 스토리지)

외장 디스크의 연결 경로 및 디스크에 장애가 발생하면 해당 디스크의 Read/Write가 불가능하므로 MCCS는 장애를 표시하고 페일오버를 진행합니다.

[그림] 공유 디스크 장애 발생 화면

1. 외장 스토리지 장애는 MCCS 로그, 시스템 로그에서 장애 내역을 확인할 수 있습니다.

2. 외장 스토리지 자체에 문제가 생기면 스토리지를 복구 할 때까지 서버 운영이 중단 됩니다. 따라서 빠른 시간 내에 스토리지를 복구하거나 임시 스토리지(백업 스토리지)로 교체해서 사용해야 합니다.

3. 외장 스토리지와 관련된 장애는 해당 스토리지 업체에 문의하시기 바랍니다.

4. 장애가 발생한 서버의 외장 스토리지 연결 및 디스크가 정상화 되면 MCCS 커널 드라이버가 복구된 환경을 다시 인식할 수 있도록 서버를 재부팅 해야 합니다.

5. 또한 해당 스토리지 벤더를 통해 스토리지의 이중화 대책을 마련해야 합니다.

NetBIOS 장애

Direct-Hosted SMB 사용

Windows 2000 이상에서 지원하는 SMB는 Direct-Hosted 방식을 지원합니다. 이 기능은 NetBIOS 인터페이스를 사용하지 않고 직접 파일공유 서비스를 지원합니다.
이름의 IP주소 해결을 위해 DNS 를 통한 조회가 발생하고 NetBIOS 이름해결 절차는 사용되지 않습니다.

송수신 동작

• 기본적으로 리디렉터(워크스테이션 서비스)는 NetBIOS 장치와 SMB 장치 모두에 대해 호출하며, 파일 서버는 NetBIOS 장치와 SMB 장치 모두에 대한 호출을 수신합니다.
• 파일 서버의 SMB 장치는 기존 TCP를 통한 NetBIOS 포트 139가 아닌 TCP 포트 445에서 호출을 받으려 우선 대기합니다.
• SMB 세션이 445 포트로 실패할 경우 139(NetBT) 포트를 사용합니다. 만일 둘다 실패하면 연결이 실패됩니다.

즉, NetBIOS 에이전트를 사용하면서 DNS 서버와 연동할 경우에는 클라이언트가 파일서버에 대부분 Direct-Hosted SMB 방식으로 연결됩니다.

관련 캐시 플러시

에이전트 동작 확인 시, 관련 캐시를 플러시합니다. 

NetBIOS table 캐시 플러시 방법

netbtstat -R

DNS 캐시 플러시 방법

ipconfig /flushdns

ARP 캐시 플러시 방법

arp -d

방화벽 설정해제

NetBIOS 통신관련 해제 대상 포트번호는 다음과 같습니다.

DNS 서버 업데이트, WINS 서버 업데이트에 관련된 포트번호는 다음과 같습니다.

워크스테이션(Workstation) 서비스 중단 시 고려사항

Windows 서비스에서 Workstation 서비스는 SMB 프로토콜을 사용하여 원격 서버에 대한 클라이언트 네트워크 연결을 만들고 유지합니다.
이 서비스가 중지되면 해당 연결을 사용할 수 없습니다. 이 서비스를 사용하지 않으면 이 연결을 명시적으로 사용하는 다음 서비스를 시작할 수 없습니다.
워크스테이션 서비스를 중지 할때는 주의해야 합니다.

서버(Server) 서비스 중단 시 고려사항

Windows 서비스에서 Server 서비스는 이 컴퓨터에 대해 파일, 인쇄 및 명명된 파이프를 네트워크를 통해 공유할 수 있도록 지원합니다.
이 서비스가 중지되면 이런 기능을 사용할 수 없게 됩니다. 이 서비스가 사용할 수 없게 설정되면 이 서비스에 종속성이 있는 다음 서비스는 시작할 수 없게 됩니다.

Server 서비스를 중지 할때는 주의해야 합니다.

파일공유가 안 될 경우

가상이름이 아닌 노드의 원래 NetBIOS 컴퓨터 이름으로 파일공유가 되는지 먼저 확인합니다.
클라이언트에서 dir, start, explorer 또는 net view 명령으로 노드 파일에 정상적으로 접근이 가능한지 확인합니다.
DIR 명령으로 확인합니다.
DIR 명령은 다음의 명령어로 실행합니다.

dir \\virtual_name\shared_folder 

START 명령으로 확인합니다.
START 명령은 다음의 명령어로 실행합니다.

start \\virtual_name

EXPLORER 명령으로 확인합니다.
EXPLORER 명령은 다음의 명령어로 실행합니다.

explorer \\virtual_name

NET VIEW 명령으로 확인합니다.
NET VIEW 명령은 다음의 명령어로 실행합니다.

net view virtual_name

컴퓨터의 파일과 인쇄 공유 목록이 생성됩니다. 지정된 컴퓨터에서 사용할 수 있는 파일이나 인쇄 공유가 없으면 "목록에 항목이 없습니다." 메시지가 나타납니다.
페일오버된 상황에서 클라이언트가 갖고 있는 가상이름의 IP주소가 페일오버 전 노드의 주소를 갖는 경우가 발생하면 클라이언트의 NetBIOS 케시가 플러시 될때까지 수 분 동안 통신이 안될 수 도 있습니다.
WINS 서버를 사용하는 경우 이런 상황이 발생 가능합니다 . 따라서 이런 경우 클라이언트 프로그램은 이중화 동작이 발생하는 환경 임을 인지 할 수 있어야 합니다.

SCSI Lock 장애

SCSI3-PR 을 사용하는 볼륨매니저와 연동할 때

볼륨 매니져(예: 시멘택의 SFW 같이 SCSI3-PR 예약 기능을 사용하는 제품)는 SCSI Lock 에이전트와 같이 사용할 수 없습니다.

SCSI3-PR을 지원하는지 확인할 때

디스크가 SCSI3-PR 기능을 지원하는지 scsicmd.cmd 명령으로 PR 타입을 확인합니다.

sg_scan.exe 또는 sg_persist.exe 패스를 못 찾을 때

해당명령이 %MCCS_HOME%/bin 에 존재하는지 확인합니다.

공유 디스크 에이전트와 연동할 때

공유디스크 에이전트와 SCSI Lock 에이전트를 연동할 경우, 공유디스크 에이전트 동작이 정상임을 확인 한 후에 SCSI Lock 에이전트를 등록합니다.
이때 SCSI Lock 에이전트의 디스크 사용목적은 H/W적인 LOCK 장치로 사용하기 위함이지 디스크의 내용을 사용하지는 않습니다.
따라서 디스크의 크기는 작아도 되며 내용은 보호하지 않습니다.

등록 키 충돌 오류가 날 때

scsicmd.cmd -c 옵션 혹은 scsicmd.cmd -cf 옵션 으로 예약키 또는 등록키를 모두 제거한 후 다시 설정해야합니다.
그리고 리소스 등록전에는 등록된 키는 없는지 확인하고 있으면 제거후 등록해야 합니다.
참고로 현재 키는 노드의 MAC 주소를 사용하여 자동으로 설정합니다.
여러개의 네트웍 어탭터중에서 첫 번째 어탭터의 MAC 주소를 사용합니다. 이 키는 설정파일에 자동 기록합니다.
설정파일에 키가 존재할 경우에는 키를 새로 만들지 않습니다.

하나의 디스크에 여러 레터가 존재할 경우 한개의 레터에 예약 시 나머지에 레터에 접근을 못할 때

SCS Lock 대상 디스크는 기본 디스크와 단일 레터를 지원합니다.
동적 디스크나 다중 볼륨(하나의 LUN에 여러 파티션을 구성하는 경우)을 사용하는 디스크는 사용하지 마십시요.

에이전트 등록 후 DUID가 해결되지 못한 상태로 유지될 때

레터를 정의하고 활성화를 요청해야 main.json에 해당 레터에 연결된 DUID 정보가 기록됩니다.

에이전트 삭제할 때

SCSI Lock 에이전트가 삭제될때 예약을 해제합니다.
따라서 예약대상 공유디스크가 상대 노드에서 사용될 가능성을 염두에 두고 삭제를 해야 합니다.
즉 삭제할 경우에는 상대 노드를 다운시킨 후 작업하십시요.

서포트 파일을 수집하는 방법

MCCS 에 문제가 생겼을 경우 로그와 환경 정보의 수집을 위해서 서포트 파일을 수집할 수 있습니다.
서포트 파일을 수집하는 방법은 다음과 같이 2가지가 있습니다.

웹 콘솔로 수집하는 방법

1. MCCS 웹 콘솔에서 메뉴바의 '파일'을 클릭하여 서포트 파일을 수집할 수 있습니다.
   
   [그림] 메뉴바에서 서포트 파일 수집  
   
   
2. MCCS의 툴바 아이콘을 클릭하면 서포트 파일을 수집할 수 있습니다.
   
   [그림] 툴바에서 서포트 파일 수집
   
   
3. 서포트 파일을 수집할 노드의 선택과 이전에 받은 서포트파일을 다시 받을 수 있습니다.
   
   [그림] 서포트 파일 노드 선택 및 이전 서포트 파일 선택 여부
   
   

확인 버튼을 누르면 서포트 파일을 수집합니다.

[그림] 서포트 파일 수집 중 화면

1. 아래와 같이 다운로드 창이 열리게 되고 다운받으시면 됩니다.
   
   
   
   [그림] 서포트 파일 수집 확인
   
   

스크립트 파일로 수집하는 방법

스크립트 파일의 위치는 아래와 같습니다.

%MCCS_HOME%\bin\Support\support.cmd

수집된 서포트 파일은 다음의 위치에 생성됩니다.

%MCCS_HOME%\support-%COMPUTERNAME%\%COMPUTERNAME.zip