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

부록 E 비클러스터 인식 응용 프로그램 요구 사항

일반 비클러스터 인식 응용 프로그램은 고가용성(HA)의 후보가 되기 위해 특정 요구 사항을 충족해야 합니다. 응용 프로그램 적합성 분석 절에 이 요구 사항이 나열되어 있습니다. 이 부록에서는 해당 목록의 특정 항목에 대한 추가 정보를 제공합니다.

자원을 자원 그룹에 구성하여 응용 프로그램의 가용성을 높입니다. 응용 프로그램의 데이터를 가용성이 높은 클러스터 파일 시스템에 배치하여 하나의 서버가 실패한 경우 남은 서 버에서 데이터를 액세스할 수 있게 합니다. 클러스터 파일 시스템에 대한 자세한 내용은 Solaris OS용 Sun Cluster 개념 안내서를 참조하십시오.

네트워크의 클라이언트에서 네트워크를 액세스하기 위해 동일한 자원 그룹에 데이터 서비스 자원으로 포함된 논리 호스트 이름 자원에 논리 네트워크 IP 주소가 구성됩니다. 데이터 서비스 자원 및 네트워크 주소 자원이 함께 페일오버하면 데이터 서비스의 네트워크 클라이언트가 새로운 호스트에서 데이터 서비스 자원을 액세스하게 됩니다.

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

멀티호스트된 데이터

가용성이 높은 클러스터 파일 시스템의 장치는 멀티호스트되기 때문에 물리적 호스트가 충돌할 경우 충돌에서 살아남은 호스트 중 하나가 이 장치를 액세스할 수 있습니다. 가용성이 높은 응용 프로그램을 만들려면 해당 데이터의 가용성이 높아야 하므로 응용 프로그램 데이터가 여러 클러스터 노드에서 액세스할 수 있는 파일 시스템에 있어야 합니다. Sun Cluster에서 지원하는 가용성이 높은 파일 시스템의 예에는 전역 HA 파일 시스템, FFS(Failover File System) 및 Oracle Real Application Clusters을 사용하는 환경의 경우 QFS 공유 파일 시스템이 포함됩니다.

클러스터 파일 시스템은 독립 항목으로 만들어진 장치 그룹에 마운트됩니다. 개발자는 일부 장치 그룹을 마운트된 클러스터 파일 시스템으로 사용하고 다른 일부는 HA Oracle 소프트웨어 같은 데이터 서비스용 원시 장치로 사용하도록 선택할 수 있습니다.

응용 프로그램에는 명령줄 스위치나 데이터 파일의 위치를 가리키는 구성 파일이 있을 수 있습니다. 응용 프로그램에서 하드 연결된 경로 이름을 사용하는 경우 응용 프로그램 코드를 변경하지 않고 클러스터 파일 시스템의 파일을 가리키는 심볼릭 링크로 경로 이름을 변경할 수 있습니다. 심볼릭 링크 사용에 대한 자세한 내용은 멀티 호스트된 데이터 배치에 심볼릭 링크 사용을 참조하십시오.

최악의 경우 응용 프로그램의 소스 코드를 수정하여 실제 데이터 위치를 가리키는 기법을 제공해야 합니다. 추가 명령줄 인자를 생성하여 이 기법을 구현할 수 있습니다.

Sun Cluster 소프트웨어는 볼륨 관리자에 구성된 UNIX UFS 파일 시스템 및 HA 원시 장치의 사용을 지원합니다. Sun Cluster 소프트웨어 설치 및 구성 시 클러스터 관리자는 UFS 파일 시스템에 사용할 디스크 자원과 원시 장치에 사용할 디스크 자원을 지정해야 합니다. 일반적으로 데이터베이스 서버와 멀티미디어 서버에서만 원시 장치를 사용합니다.

멀티 호스트된 데이터 배치에 심볼릭 링크 사용

때로는 하드 연결된 경로 이름을 대체할 기법 없이 응용 프로그램 데이터 파일의 경로 이름이 하드 연결되는 경우가 있습니다. 응용 프로그램 코드의 수정을 방지하기 위해 때로 심볼릭 링크를 사용할 수 있습니다.

예를 들어, 응용 프로그램에서 하드 연결된 경로 이름/etc/mydatafile을 사용하여 데이터 파일의 이름을 지정하는 것으로 가정합시다. 개발자는 논리 호스트 파일 시스템 중 하나에 있는 파일을 가리키는 값을 가지는 심볼릭 링크로 파일 경로를 변경할 수 있습니다. 예를 들어, 경로를 /global/phys-schost-2/mydatafile에 대한 심볼릭 링크로 만들 수 있습니다.

응용 프로그램이나 관리 절차 중 하나에서 해당 내용뿐만 아니라 데이터 파일 이름을 수정할 경우 이 심볼릭 링크 사용에 문제가 생길 수 있습니다. 예를 들어, 응용 프로그램에서 먼저 새로운 임시 파일 /etc/mydatafile.new를 만들어 업데이트를 수행한다고 가정합니다. 그런 다음 rename() 시스템 호출이나 mv 명령을 사용하여 임시 파일이 실제 파일 이름을 갖도록 이름을 변경합니다. 데이터 서비스는 임시 파일을 만든 다음 이름을 실제 파일 이름으로 변경하여 데이터 파일 내용이 항상 올바로 구성되도록 보장합니다.

유감스럽게도 rename() 작업을 수행하면 심볼릭 링크가 완전히 삭제됩니다. 이제 /etc/mydatafile 이름은 정규 파일이며 클러스터의 클러스터 파일 시스템이 아니라 /etc 디렉토리와 동일한 파일 시스템에 있습니다. /etc 파일 시스템은 각 호스트에서 개인 파일 시스템이기 때문에 페일오버 또는 스위치오버 후에는 해당 데이터를 사용할 수 없습니다.

이 상황에서 발생할 수 있는 문제는 기존 응용 프로그램이 심볼릭 링크를 인식하지 못하여 심볼릭 링크를 처리하도록 작성되지 않았다는 것입니다. 심볼릭 링크를 사용하여 데이터 액세스를 논리 호스트의 파일 시스템으로 재지정하려면 응용 프로그램 구현에서 심볼릭 링크를 제거하지 않는 방식으로 작동해야 합니다. 따라서 심볼릭 링크는 클러스터의 파일 시스템에 데이터를 배치하는 문제에 대한 완벽한 해결책이 아닙니다.

호스트 이름

데이터 서비스에서 데이터 서비스가 실행 중인 서버의 호스트 이름을 알 필요가 있는지 여부를 결정해야 합니다. 알아야 하는 경우 데이터 서비스에서 물리적 호스트 이름 대신 논리 호스트 이름을 사용하도록 수정해야 할 수도 있습니다. 이때 논리 호스트 이름은 응용 프로그램 자원과 동일한 자원 그룹에 있는 논리 호스트 이름 자원으로 구성된 호스트 이름입니다.

때로 데이터 서비스의 클라이언트-서버 프로토콜에서 서버는 클라이언트에 대한 메시지 내용의 일부로 고유한 호스트 이름을 클라이언트에 반환합니다. 그런 프로토콜의 경우 클라이언트는 서버에 연결할 때 사용할 호스트 이름으로 이 반환된 호스트 이름을 사용할 수 있습니다. 페일오버 또는 스위치오버 후 반환된 호스트 이름을 사용할 수 있게 하려면 호스트 이름은 물리적 호스트 이름이 아니라 자원 그룹의 논리 호스트 이름이어야 합니다. 이 경우 논리 호스트 이름을 클라이언트에 반환하려면 데이터 서비스 코드를 수정해야 합니다.

다중 홈 호스트

다중 홈 호스트는 둘 이상의 공용 네트워크에 있는 호스트를 설명합니다. 그런 호스트에는 여러 호스트 이름과 IP 주소가 있습니다. 각 네트워크에는 하나의 호스트 이름–IP 주소 쌍이 있습니다. Sun Cluster는 단 하나의 네트워크(다중 홈이 아닌 경우)를 포함하여 여러 네트워크에 호스트가 나타나도록 설계되어 있습니다. 물리적 호스트 이름에 여러 호스트 이름–IP 주소 쌍이 있는 것처럼 각 자원 그룹에는 각 공용 네트워크에 하나씩 여러 개의 호스트 이름–IP 주소 쌍이 있을 수 있습니다. Sun Cluster에서 자원 그룹을 하나의 물리적 호스트에서 다른 물리적 호스트로 이동하면 해당 자원 그룹의 전체 호스트 이름–IP 주소 쌍 세트가 이동됩니다.

자원 그룹에 대한 호스트 이름–IP 주소 쌍 세트는 자원 그룹에 포함된 논리 호스트 이름 자원으로 구성됩니다. 자원 그룹을 만들고 구성할 때 클러스터 관리자는 이러한 네트워크 주소 자원을 지정합니다. Sun Cluster Data Service API에는 이 호스트 이름–IP 주소 쌍을 쿼리하는 기능이 포함되어 있습니다.

Solaris 운영 체제용으로 작성된 대부분의 사용 가능 데이터 서비스 데몬은 이미 다중 홈 호스트를 올바로 처리합니다. 많은 데이터 서비스에서는 Solaris 와일드카드 주소 INADDR_ANY에 바인드하여 모든 네트워크 통신을 수행합니다. 이렇게 바인드하면 자동으로 데이터 서비스에서 모든 네트워크 인터페이스의 모든 IP 주소를 처리합니다. INADDR_ANY는 시스템에 현재 구성된 모든 IP 주소에 효율적으로 바인드합니다. 일반적으로 Sun Cluster 논리 네트워크 주소를 처리하기 위해 INADDR_ANY를 사용하는 데이터 서비스 데몬을 변경할 필요는 없습니다.

`INADDR_ANY`에 바인드 대 특정 IP 주소에 바인드

다중 홈이 아닌 호스트를 사용할 경우에도 Sun Cluster 논리 네트워크 주소 개념을 사용하면 시스템에 둘 이상의 IP 주소가 있을 수 있습니다. 시스템에는 자체 물리적 호스트에 대한 하나의 IP 주소와 현재 시스템에서 마스터하는 각 네트워크 주소(논리 호스트 이름) 자원에 대한 추가 IP 주소가 있습니다. 시스템이 네트워크 주소 자원의 마스터가 될 경우 시스템에서는 동적으로 추가 IP 주소를 가져옵니다. 시스템이 네트워크 주소 자원의 마스터를 포기한 경우 동적으로 IP 주소를 양도합니다.

일부 데이터 서비스는 INADDR_ANY에 바인드될 경우 Sun Cluster 환경에서 올바로 작동하지 않습니다. 이 데이터 서비스에서는 자원 그룹이 마스터되거나 마스터 해제될 때 자신이 바인드되는 IP 주소 세트를 동적으로 변경해야 합니다. 재바인드를 완료하기 위한 한 가지 방법은 이 데이터 서비스에 대한 시작 및 중지 메소드를 사용하여 데이터 서비스 데몬을 다시 시작하는 것입니다.

Network_resources_used 자원 등록 정보에서는 최종 사용자가 응용 프로그램 자원을 바인드할 특정 네트워크 주소 자원 세트를 구성할 수 있도록 허용합니다. 이 기능이 필요한 자원 유형의 경우 해당 자원 유형의 RTR 파일에서 Network_resources_used 등록 정보를 선언해야 합니다.

RGM에서 자원 그룹을 온라인이나 오프라인으로 전환할 경우 RGM은 호출 데이터 서비스 자원 메소드를 호출하는 시기와 관련하여 네트워크 주소를 연결, 연결 해제, 활성으로 구성 및 비활성으로 구성하는 특정 순서를 따릅니다. 사용할 Start 및 Stop 메소드 결정을 참조하십시오.

데이터 서비스의 Stop 메소드가 반환될 때까지는 자원 그룹의 네트워크 주소를 사용하여 데이터 서비스를 중지했어야 합니다. 마찬가지로 Start 메소드가 반환될 때까지는 네트워크 주소를 사용하려면 데이터 서비스를 시작했어야 합니다.

데이터 서비스가 개별 IP 주소가 아니라 INADDR_ANY에 바인드될 경우 데이터 서비스 자원 메소드를 호출하는 순서와 네트워크 주소 메소드를 호출하는 순서는 관련이 없습니다.

데이터 서비스의 Stop 및 Start 메소드가 데이터 서비스의 데몬을 강제 종료하고 다시 시작하여 해당 작업을 완료하면 적절한 시간에 네트워크 주소를 사용하여 데이터 서비스가 중지 및 시작됩니다.

클라이언트 재시도

네트워크 클라이언트에게 페일오버 또는 스위치오버는 빠른 재부트가 수반되는 논리 호스트의 충돌로 나타납니다. 이상적으로 클라이언트 응용 프로그램과 클라이언트-서버 프로토콜은 어느 정도의 재시도를 수행하도록 구성되어 있습니다. 응용 프로그램과 프로토콜에서 이미 단일 서버 충돌 및 재부트를 처리한 경우 자원 그룹의 페일오버 또는 스위치 오버도 처리할 수 있습니다. 일부 응용 프로그램에서는 무한대로 재시도하도록 선택할 수 있습니다. 좀더 복잡한 응용 프로그램에서는 사용자에게 시간이 오래 걸리는 재시도가 진행 중임을 알리고 사용자가 계속할지 여부를 선택하도록 할 수 있습니다.