test

Solaris OS용 Sun Cluster 데이터 서비스 개발 안내서

7장 자원 유형 정의

이 장에서는 자원 유형을 디자인 및 구현하는 데 있어 DSDL의 일반적인 용도를 살펴봅니다. 또한 자원 유형을 디자인하여 자원 구성을 검증하고 자원을 시작, 정지 및 모니터링하는 것에 초점을 맞추어 설명합니다. 마지막으로 DSDL을 사용하여 자원 유형 콜백 메소드를 구현하는 방법에 대해 설명합니다.

rt_callbacks(1HA) 설명서 페이지에서는 이 장의 설명에 대한 추가 정보를 확인할 수 있습니다.

이러한 작업을 수행하려면 자원의 등록 정보 설정에 액세스해야 합니다. DSDL 유틸리티 scds_initialize()는 자원 등록 정보에 액세스하기 위한 일관된 방법을 제공합니다. 각 콜백 메소드의 시작 부분에서 호출되도록 설계된 이 유틸리티 함수는클러스터 프레임워크에서 자원의 모든 등록 정보를 검색하여 scds_getname() 함수 계열에 사용할 수 있게 합니다.

이 장은 다음 내용으로 구성되어 있습니다.

RTR 파일

자원 유형 등록(RTR) 파일은 자원 유형의 중요한 구성 요소입니다. 이 파일은 Sun Cluster에 대해 자원 유형의 세부 정보를 지정합니다. 이러한 세부 정보에는 구현에 필요한 등록 정보, 이러한 등록 정보의 데이터 유형과 기본값, 자원 유형 구현을 위한 콜백 메소드의 파일 시스템 경로, 시스템 정의 등록 정보의 다양한 설정 등이 포함됩니다.

DSDL과 함께 제공되는 샘플 RTR 파일은 대부분의 자원 유형 구현에 충분해야 합니다. 사용자는 단순히 자원 유형 이름 및 자원 유형 콜백 메소드의 경로 이름과 같은 몇 가지 기본 요소만 편집하면 됩니다. 자원 유형을 구현하기 위해 새 등록 정보가 필요한 경우 자원 유형 구현의 자원 유형 등록(RTR) 파일에서 이를 확장 등록 정보로 선언한 다음 DSDL scds_get_ext_property() 유틸리티를 사용하여 새 등록 정보에 액세스할 수 있습니다.

Validate 메소드

Validate 자원 유형 메소드 구현은 다음 두 조건 중 하나의 경우에서 RGM에 의해 호출됩니다.

이러한 두 시나리오는 자원의 Validate 메소드에 전달되는 -c(작성) 또는 -u(업데이트) 명령줄 옵션의 존재로 구별할 수 있습니다.

Validate 메소드는 자원 유형 등록 정보 INIT_NODES의 값으로 정의되는 노드 집합의 각 노드에서 호출됩니다. INIT_NODES가 RG_PRIMARIES로 설정된 경우 Validate는 자원을 포함하는 자원 그룹을 호스팅할 수 있는(즉, 이러한 그룹의 기본이 될 수 있는) 각 노드에서 호출됩니다. INIT_NODES가 RT_INSTALLED_NODES로 설정된 경우 자원 유형 소프트웨어가 설치되는 각 노드(일반적으로 클러스터의 모든 노드)에서 Validate가 호출됩니다. INIT_NODES의 기본값은 RG_PRIMARIES입니다(rt_reg(4) 참조). Validate 메소드가 호출되는 시점에 RGM은 아직 자원을 만들지 않았거나(작성 콜백의 경우) 업데이트 중인 등록 정보의 업데이트된 값을 아직 적용하지 않았습니다(업데이트 콜백의 경우). 자원 유형 구현의 Validate 콜백 메소드의 목적은 제안된 자원 설정(자원의 제안된 등록 정보 설정에 지정된 대로)이 자원 유형에 허용되는지 확인하는 것입니다.

주 –

HAStoragePlus에서 관리하는 로컬 파일 시스템을 사용할 경우 scds_hasp_check를 사용하여 HAStoragePlus 자원의 상태를 확인합니다. 자원에 대해 정의된 Resource_dependencies 또는 Resource_dependencies_weak 시스템 등록 정보를 사용하여 자원이 의존하는 모든 SUNW.HAStoragePlus(5) 자원의 상태(온라인 또는 기타)에서 이 정보를 가져옵니다. scds_hasp_check 호출에서 반환된 전체 상태 코드 목록은 scds_hasp_check(3HA)를 참조하십시오.

DSDL 함수 scds_initialize()는 다음과 같은 방법으로 이러한 상황을 처리합니다.

자원 등록 정보의 검증을 구현하는 함수를 svc_validate()라고 하고 이 함수가 scds_get_name() 계열의 함수를 사용하여 검증할 등록 정보를 찾는다고 가정합니다. 허용되는 자원 설정이 이 함수의 반환 코드 0으로 표시된다고 가정하면 자원 유형의 Validate 메소드는 다음 코드 단편과 같이 나타날 수 있습니다. 


int
main(int argc, char *argv[])
{
   scds_handle_t handle;
   int rc;

   if (scds_initialize(&handle, argc, argv)!= SCHA_ERR_NOERR) {
   return (1);   /* Initialization Error */
   }
   rc = svc_validate(handle);
   scds_close(&handle);
   return (rc);
}

검증 함수는 또한 자원 검증이 실패한 이유를 기록해야 합니다. 이에 대한 실제적인 처리 방법은 다음 장에서 자세히 설명하기로 하고, 간단한 예 svc_validate() 함수를 다음과 같이 구현할 수 있습니다. 


int
svc_validate(scds_handle_t handle)
{
   scha_str_array_t *confdirs;
   struct stat    statbuf;
   confdirs = scds_get_confdir_list(handle);
   if (stat(confdirs->str_array[0], &statbuf) == -1) {
   return (1);   /* Invalid resource property setting */
   }
   return (0);   /* Acceptable setting */
}

따라서 자원 유형 개발자는 svc_validate() 함수의 구현만 신경 쓰면 됩니다. 자원 유형 구현의 일반적인 예로 app.conf라는 응용 프로그램 구성 파일이 Confdir_list 등록 정보에 존재하도록 설정하는 것을 들 수 있습니다. 이것은 Confdir_list 등록 정보에서 파생된 해당 경로 이름에 대한 stat() 시스템 호출을 통해 편리하게 구현할 수 있습니다.

Start 메소드

자원 유형 구현의 Start 콜백 메소드는 자원을 시작하기 위해 선택된 클러스터 노드에서 RGM에 의해 호출됩니다. 명령줄에 자원 그룹 이름, 자원 이름 및 자원 유형 이름이 전달됩니다. Start 메소드는 클러스터 노드에서 데이터 서비스 자원을 시작하는 데 필요한 작업을 수행합니다. 일반적으로 여기에는 자원 등록 정보 검색, 응용 프로그램 특정 실행 파일 및/또는 구성 파일 찾기, 해당 명령줄 인자로 응용 프로그램 시작 등의 작업이 포함됩니다.

DSDL의 경우 자원 구성은 이미 scds_initialize() 유틸리티에 의해 검색됩니다. 응용 프로그램에 대한 시작 작업은 svc_start() 함수에 포함될 수 있습니다. 다른 함수 svc_wait()를 호출하여 응용 프로그램이 실제로 시작되었는지 확인할 수 있습니다. Start 메소드에 대한 단순화된 코드는 다음과 같이 나타납니다. 


int
main(int argc, char *argv[])
{
   scds_handle_t handle;

   if (scds_initialize(&handle, argc, argv)!= SCHA_ERR_NOERR) {
   return (1);   /* Initialization Error */
   }
   if (svc_validate(handle) != 0) {
   return (1);   /* Invalid settings */
   }
   if (svc_start(handle) != 0) {
   return (1);   /* Start failed */
   }
   return (svc_wait(handle));
}

이 시작 메소드 구현에서 svc_validate()를 호출하여 자원 구성을 검증합니다. 실패할 경우 자원 구성과 응용 프로그램 구성이 일치하지 않거나 해당 클러스터 노드에 시스템과 관련된 문제가 있는 것입니다. 예를 들어, 자원에 필요한 전역 파일 시스템을 해당 클러스터 노드에서 사용하지 못할 수 있습니다. 이러한 경우 해당 클러스터 노드에서 자원을 시작하려는 시도는 아무 소용이 없으며RGM으로 하여금 다른 노드에서 자원을 시작하도록 하는 것이 좋습니다. 그러나 위에서는 svc_validate()가 응용 프로그램에 절대적으로 필요한 클러스터 노드의 자원만 검사하도록 제한되어 있으며 그렇지 않을 경우 모든 클러스터 노드에서 자원이 시작되지 않아 START_FAILED 상태가 될 수 있다고 가정합니다. 이 상태에 대한 자세한 내용은 scswitch( 1M) 및 Sun Cluster Data Services Planning and Administration Guide for Solaris OS를 참조하십시오.

svc_start() 함수는 노드에서 자원 시작에 성공한 경우 0을 반환해야 하며문제가 발생한 경우에는 0이 아닌 값을 반환해야 합니다. 이 함수가 실패할 경우 RGM은 다른 클러스터 노드에서 해당 자원을 시작하려고 합니다.

DSDL을 가능한 많이 활용하기 위해 svc_start() 함수는 scds_pmf_start() 유틸리티를 사용하여 PMF (Process Management Facility)에서 응용 프로그램을 시작할 수 있습니다. 이 유틸리티는 또한 PMF의 실패 콜백 작업 기능(pmfadm(1M)의 - a 작업 플래그 참조)을 사용하여 프로세스 실패 감지를 구현합니다.

Stop 메소드

자원 유형 구현의 Stop 콜백 메소드는 응용 프로그램을 중지하기 위해 클러스터 노드에서 RGM에 의해 호출됩니다. Stop 메소드의 콜백 의미는 다음을 요구합니다.

DSDL 유틸리티 scds_pmf_stop()은 SIGTERM을 통해 응용 프로그램을 유연하게 중지하려고 시도(응용 프로그램이 scds_pmf_start()를 통해 PMF에서 시작되었다고 가정)한 다음 프로세스에 SIGKILL을 전달하므로 대부분의 응용 프로그램을 중지할 수 있습니다. 이 유틸리티에 대한 자세한 내용은 PMF 함수를 참조하십시오.

지금까지 사용했던 코드 모델에 따라 응용 프로그램을 중지하기 위한 응용 프로그램 특정 함수를 svc_stop()이라고 가정하면 Stop 메소드를 다음과 같이 구현할 수 있습니다. 여기에서 svc_stop() 구현이 scds_pmf_stop()을 사용하는지 여부는 논외로 하며 응용 프로그램을 Start 메소드를 통해 PMF에서 시작했는지 여부에 따라 달라질 것입니다. 

if (scds_initialize(&handle, argc, argv)!= SCHA_ERR_NOERR)
{
   return (1);   /* Initialization Error */
}
return (svc_stop(handle));

svc_validate() 메소드는 Stop 메소드 구현에 사용되지 않습니다. 이는 시스템에 문제가 있는 경우에도 Stop 메소드가 해당 노드에서 응용 프로그램의 중지를 시도해야 하기 때문입니다.

Monitor_start 메소드

RGM은 자원에 대한 오류 모니터를 시작하기 위해 Monitor_start 메소드를 호출합니다. 오류 모니터는 자원이 관리하는 응용 프로그램의 상태를 모니터합니다. 자원 유형 구현은 일반적으로 백그라운드에서 실행되는 별도의 데몬으로 오류 모니터를 구현합니다. Monitor_start 콜백 메소드는 이 데몬을 적절한 인자로 시작하는 데 사용됩니다.

모니터 데몬 자체에 오류가 발생할 수 있으므로(예를 들어, 모니터 데몬이 중지되어 응용 프로그램이 모니터되지 않을 수 있음) PMF를 사용하여 모니터 데몬을 시작해야 합니다. DSDL 유틸리티 scds_pmf_start()는 오류 모니터를 시작하기 위한 지원을 기본으로 제공합니다. 이 유틸리티는 모니터 데몬 프로그램의 상대 경로 이름(자원 유형 콜백 메소드 구현의 위치에 대한 RT_basedir에 상대적)을 사용합니다. 이 유틸리티는 데몬이 무제한적으로 재시작되는 것을 방지하기 위해 DSDL에 의해 관리되는 Monitor_retry_interval 및 Monitor_retry_count 확장 등록 정보를 사용합니다. 모니터 데몬이 RGM에 의해 직접 호출되지 않더라도 모든 콜백 메소드에 정의된 명령줄 구문(즉, -R resource -G resource_group -T resource_type)이 모니터 데몬에 동일하게 적용됩니다. 이것은 모니터 데몬 구현 자체에서 scds_initialize() 유틸리티를 사용하여 고유한 환경을 설정할 수 있게 합니다. 작업을 위한 노력의 대부분은 모니터 데몬 자체를 디자인하는 데 필요합니다.

Monitor_stop 메소드

RGM은 Monitor_start 메소드를 통해 시작된 오류 모니터 데몬을 정지하기 위해 Monitor_stop 메소드를 호출합니다. 이 콜백 메소드의 실패는 Stop 메소드의 실패와 똑같은 방식으로 처리됩니다. 따라서 Monitor_stop 메소드는 Stop 메소드처럼 멱등원이거나 견고해야 합니다.

scds_pmf_start() 유틸리티를 사용하여 오류 모니터 데몬을 시작한 경우 scds_pmf_stop() 유틸리티를 사용하여 오류 모니터 데몬을 중지합니다.

Monitor_check 메소드

자원에 대한 Monitor_check 콜백 메소드는 클러스터 노드가 자원을 마스터할 수 있는지(즉, 자원에 의해 관리되고 있는 응용 프로그램을 노드에서 성공적으로 실행할 수 있는지) 여부를 확인하기 위해 지정된 자원의 노드에서 호출됩니다.). 일반적으로 이러한 상황에는 응용 프로그램에 필요한 모든 시스템 자원을 실제로 클러스터 노드에서 사용할 수 있는지 확인하는 것이 포함됩니다. Validate 메소드에 설명된 것처럼 개발자에 의해 구현되는 svc_validate() 함수의 목적은 최소한 이러한 점을 확인하는 데 있습니다.

자원 유형 구현에 의해 관리되는 특정 응용 프로그램에 따라 Monitor_check 메소드를 작성하여 몇 가지 추가 작업을 수행할 수 있습니다. Monitor_check 메소드는 동시에 실행되는 다른 메소드와 충돌하지 않도록 구현해야 합니다. DSDL을 사용하는 개발자의 경우 자원 등록 정보의 응용 프로그램 특정 검증을 구현하는 목적으로 작성된 svc_validate() 함수를 Monitor_check 메소드에서 사용하는 것이 좋습니다.

Update 메소드

RGM은 시스템 관리자에 의한 모든 변경 사항을 활성 자원의 구성에 적용하기 위해 자원 유형 구현의 Update 메소드를 호출합니다. Update 메소드는 자원이 현재 온라인 상태인 노드(있을 경우)에서만 호출됩니다.

RGM은 Update 메소드를 실행하기 전에 자원 유형의 Validate 메소드를 실행하므로 이제 막 변경된 자원 구성은 자원 유형 구현에 허용될 수 있습니다. Validate 메소드는 자원 또는 자원 그룹 등록 정보가 변경되기 전에 호출되며 제안된 변경 사항이 Validate 메소드에 의해 거부될 수 있습니다. 활성(온라인) 자원이 새 설정을 인식할 수 있도록 변경 사항이 적용된 후에 Update 메소드가 호출됩니다.

자원 유형 개발자는 동적으로 업데이트할 수 있기를 원하는 등록 정보를 신중하게 결정하고 RTR 파일에서 TUNABLE = ANYTIME 설정으로 이러한 등록 정보에 표시해야 합니다. 일반적으로 자원 유형 개발자는 Update 메소드 구현이 최소한 모니터 데몬을 다시 시작하는 경우 오류 모니터 데몬이 사용하는 자원 유형 구현의 모든 등록 정보를 동적으로 업데이트할 수 있어야 한다는 것을 지정할 수 있습니다.

가능한 등록 정보는 다음과 같습니다.

이러한 등록 정보는 오류 모니터 데몬이 서비스의 상태를 검사하는 방법, 상태를 검사하는 빈도, 오류를 추적하기 위해 사용하는 기록 간격, PMF에 의해 오류 모니터 데몬에 설정되는 재시작 임계값 등에 영향을 미칩니다. 이러한 등록 정보의 업데이트를 구현하기 위해 scds_pmf_restart() 유틸리티가 DSDL에서 제공됩니다.

자원 등록 정보를 동적으로 업데이트할 수 있어야 하지만 해당 등록 정보의 수정으로 인해 실행 중인 응용 프로그램이 영향을 받을 수 있는 경우 해당 등록 정보에 대한 업데이트가 실행 중인 임의의 응용 프로그램 인스턴스에 정확하게 적용되도록 적절한 작업을 구현해야 합니다. 현재로서는 DSDL을 통해 이 작업을 용이하게 하는 방법이 없습니다. Validate와 마찬가지로 Update는 명령줄의 수정된 등록 정보가 전달되지 않습니다.

Init, Fini 및 Boot 메소드

이러한 메소드는 자원 관리 API 사양에 의해 정의되는 일회성 작업 메소드입니다. DSDL에 포함된 샘플 구현은 이러한 메소드의 사용을 보여주지 않습니다. 그러나 자원 유형 개발자는 이러한 메소드가 필요한 경우 DSDL의 모든 기능을 이러한 메소드에서도 사용할 수 있습니다. 일반적으로 Init 및 Boot 메소드는 자원 유형 구현에서 일회성 작업을 구현한다는 점에서 동일합니다. Fini 메소드는 일반적으로 Init 또는 Boot 메소드의 작업을 실행 취소하는 작업을 수행합니다.

오류 모니터 데몬 디자인

DSDL을 사용한 자원 유형 구현은 일반적으로 다음 작업을 담당하는 오류 모니터 데몬을 가집니다.

DSDL 유틸리티는 오류 모니터 데몬의 주 루프가 이 장의 끝에 나오는 의사 코드로 표시될 수 있도록 설계되었습니다.

DSDL을 사용하여 구현한 오류 모니터의 경우

대부분의 경우 응용 프로그램 특정 상태 검사 작업은 별도의 독립 실행형 유틸리티(예: svc_probe())에서 구현되고 다음과 같은 일반적인 주 루프와 통합될 수 있습니다. 


for (;;) { 

   / * sleep for a duration of thorough_probe_interval between
   *  successive probes. */
   (void) scds_fm_sleep(scds_handle,
   scds_get_rs_thorough_probe_interval(scds_handle));

   /* Now probe all ipaddress we use. Loop over
   * 1. All net resources we use.
   * 2. All ipaddresses in a given resource.
   * For each of the ipaddress that is probed,
   * compute the failure history. */
   probe_result = 0;
   /* Iterate through the all resources to get each
    * IP address to use for calling svc_probe() */
   for (ip = 0; ip < netaddr->num_netaddrs; ip++) {
   /* Grab the hostname and port on which the
   * health has to be monitored.
   */
   hostname = netaddr->netaddrs[ip].hostname;
   port = netaddr->netaddrs[ip].port_proto.port;
   /*
   * HA-XFS supports only one port and
   * hence obtaint the port value from the
   * first entry in the array of ports.
   */
   ht1 = gethrtime(); /* Latch probe start time */
   probe_result = svc_probe(scds_handle, 

   hostname, port, timeout);
   /*
   * Update service probe history,
   * take action if necessary.
   * Latch probe end time.
   */
   ht2 = gethrtime();
   /* Convert to milliseconds */
   dt = (ulong_t)((ht2 - ht1) / 1e6);

   /*
   * Compute failure history and take
   * action if needed
   */
   (void) scds_fm_action(scds_handle,
   probe_result, (long)dt);
   }       /* Each net resource */
   }       /* Keep probing forever */