클러스터 리소스 관리

리소스 관리자는 올바른 네트워크 인터페이스 세트가 연결되고, 올바른 스토리지 풀이 활성화되고, 수많은 구성 매개변수가 두 클러스터형 컨트롤러 간에 동기화 상태를 유지하는지 확인해야 합니다. 이 부속 시스템의 작동 중 대부분은 관리자가 눈으로 확인할 수 없지만 한 가지 중요한 양상이 나타납니다. 리소스는 여러 유형으로 분류되어 리소스를 가져오는 시기와 가져올지 여부(활성화)를 관리합니다. 활성화의 정의는 리소스 클래스에 따라 달라집니다. 예를 들어, 네트워크 인터페이스는 네트 클래스에 속하며 인터페이스가 시작될 때 활성화됩니다.

가장 중요한 3가지 리소스 유형은 싱글톤, 개인 및 복제입니다.

• 복제본 리소스 - 복제본은 가장 간단한 유형으로서, 관리자에게 노출되거나 클러스터 구성 화면에 나타나지 않습니다. 복제는 항상 존재하며 두 컨트롤러에 항상 활성화되어 있습니다. 일반적으로 이러한 리소스는 두 컨트롤러 간에 동기화되어야 하는 서비스 등록 정보의 컨테이너 역할을 합니다.

• 싱글톤 리소스 - 싱글톤 리소스도 복제본과 마찬가지로 상태 동기화를 제공하지만, 싱글톤은 항상 한 컨트롤러에서만 활성화되어 있습니다. 관리자는 각 싱글톤이 일반적으로 활성화되어야 하는 컨트롤러를 선택할 수 있습니다. 해당 컨트롤러에 장애가 발생할 경우 피어가 싱글톤을 가져옵니다. 싱글톤은 클러스터링의 가용성 특성에 있어 중요한 요소이며, 일반적으로 장애가 발생한 컨트롤러에서 작동 중인 피어로 리소스가 이동한다고 가정하고 네트워크 인터페이스와 스토리지 풀을 포함합니다. 네트워크 인터페이스는 클라이언트에서 알려진 스토리지 서비스 세트를 찾는 데 사용하는 IP 주소의 모음이므로, 스토리지 풀 클라이언트가 인터페이스의 주소에 액세스할 때 찾는 같은 컨트롤러에 각 인터페이스를 지정하는 것이 중요합니다. 그림 4와 같이 PrimaryA 인터페이스와 연관된 모든 주소는 항상 pool-0을 가져온 컨트롤러에 의해 제공되며, PrimaryB는 항상 pool-1과 같은 컨트롤러에 의해 제공됩니다.

• 개인 리소스 - 개인 리소스는 지정된 컨트롤러에만 알려지며, 장애 발생 시 인계되지 않습니다. 이는 일반적으로 네트워크 인터페이스에만 유용합니다. 특정 용례에 대한 다음 설명을 참조하십시오.

그림 16  ZS3-2 클러스터링 예

그 밖에도 몇 가지 리소스 유형이 있지만 관리자에게는 노출되지 않는 구현 세부정보입니다. 이러한 유형 중에는 가져오고 내보낼 때 한 리소스가 다른 리소스를 따르는 공생 유형이 있습니다. 스토리지 풀의 디스크와 플래시 장치를 나타내는 것이 이 리소스 유형의 가장 중요한 용도입니다. 이러한 리소스를 디스크 세트라고도 하며 항상 포함한 ZFS 풀보다 먼저 가져와야 합니다. 각 디스크 세트는 외부 스토리지 외장 장치에 있는 디스크의 절반으로 구성됩니다. 클러스터화된 스토리지 시스템에 연결할 수 있는 디스크 세트의 수에는 제한이 없으며(하드웨어 지원에 따라 다름) 하나 이상의 디스크 세트에 있는 스토리지 장치에서 각 ZFS 풀이 형성됩니다. 디스크 세트에는 ATA 장치가 포함되어 있으므로 다중 경로가 지정된 환경에 사용되는 ATA 장치와 관련된 특정 연계 관련 동작이 발생되지 않도록 이를 명시적으로 가져오고 내보내야 합니다. 디스크를 리소스로 나타내면 이러한 작동을 적시에 간단하게 수행할 수 있습니다. 관리자가 스토리지 풀의 소유권을 설정하거나 변경하면 이와 연관된 디스크 세트의 소유권 지정도 동시에 투명하게 변경됩니다. 모든 공생 유형과 마찬가지로 디스크 세트 리소스도 클러스터 구성 사용자 인터페이스에 나타나지 않습니다.

표 43  클러스터 리소스 관리

리소스 아이콘 편재 장애 발생 시 인수 싱글톤 아니오 예 복제 없음 예 해당 없음 개인 아니오 아니오 공생 유형 없음 부모 유형과 동일 부모 유형과 동일

새 리소스가 생성되면 먼저 해당 리소스가 생성 중인 컨트롤러에 지정됩니다. 컨트롤러가 AKCS_OWNER 상태가 아닌 한 이 소유권은 변경되지 않으므로 해당 컨트롤러에 일반적으로 소유해야 하는 리소스를 만들거나 리소스 소유권을 변경하기 전에 인계해야 합니다. 내보낸 스토리지 풀은 삭제할 수 없지만 두 컨트롤러 중 하나에서 리소스를 삭제할 수 있습니다. 컨트롤러가 지정된 소유자인 것과 관계없이 현재 리소스를 제어 중인 컨트롤러에서 리소스를 삭제하는 것이 가장 좋습니다.

서비스 등록 정보, 사용자, 역할, ID 매핑 규칙, SMB 오토홈 규칙 및 iSCSI 개시자 정의를 비롯한 대부분의 구성 설정은 자동으로 두 컨트롤러에 복제됩니다. 그러므로 클러스터 상태에 관계없이 두 컨트롤러에서 이러한 설정을 구성할 필요가 없습니다. 구성 변경 시 한 어플라이언스의 작동이 중지된 경우 다음 부트 시 클러스터를 재결합할 때 다른 어플라이언스로 복제되어 서비스를 제공합니다. 몇 가지 예외가 있습니다.

• 공유 및 LUN 정의와 옵션은 해당 풀이 원래 지정된 컨트롤러에 관계없이 기본 풀을 제어하는 컨트롤러에만 설정할 수 있습니다.

• "ID" 서비스의 구성(예: 어플라이언스 이름 및 위치)은 복제되지 않습니다.

• 섀시에 지정된 이름은 해당 이름이 지정된 컨트롤러에서만 볼 수 있습니다.

• 각 네트워크 경로는 특정 인터페이스로 바인딩됩니다. 각 컨트롤러가 특정 서브넷의 주소가 있는 인터페이스에 지정되고 해당 서브넷에 어플라이언스에서 트래픽을 전송할 라우터가 있는 경우 같은 게이트웨이 주소를 사용하더라도 이러한 각 인터페이스에 대해 경로를 만들어야 합니다. 이렇게 하면 기본 네트워크 리소스의 제어권이 두 컨트롤러 간에 전환되므로 각 경로가 개별적으로 활성화됩니다. 자세한 내용은 네트워킹에 대한 클러스터링 고려 사항을 참조하십시오.

• SSH 호스트 키는 복제 및 공유되지 않습니다. 그러므로 개인 관리 인터페이스가 구성되지 않은 경우에는 실패한 노드에 지정된 주소를 사용하여 CLI에 로그인하려고 할 때 중대한 실수가 발생할 수 있습니다. BUI에 액세스하는 데 사용되는 SSL 인증서에도 같은 제한이 적용됩니다.

기본 모델에 일반 구성이 투명하게 복제되고 나면 관리자가 리소스 모음을 각 어플라이언스 컨트롤러에 지정합니다. 이러한 리소스 지정을 통해 클라이언트가 예상한 대로 스토리지 리소스에 네트워크 주소가 차례로 바인딩됩니다. 어떤 어플라이언스에서 리소스 모음을 제어하는지에 관계없이 클라이언트는 원하는 네트워크 위치에서 필요한 스토리지에 액세스할 수 있습니다.

관련 항목

• 클러스터화된 구성 종료(CLI)