수많은 어플라이언스 구성은 서비스 등록 정보 또는 공유/LUN 등록 정보로 표현됩니다. 공유 및 LUN 등록 정보는 사용자 데이터와 함께 스토리지 풀에 저장되어 항상 스토리지 리소스의 현재 소유자가 액세스할 수 있는 반면, 서비스 구성은 각 컨트롤러 내에 저장됩니다. 두 컨트롤러가 모두 일관성 있는 서비스를 제공하기 위해서는 변경이 발생하거나 이전에 중지된 컨트롤러가 해당 피어와 재결합할 때 모든 서비스 등록 정보가 동기화되어야 합니다. 모든 서비스는 복제 리소스로 표현되므로 두 컨트롤러 중 하나에서 등록 정보가 변경되면 어플라이언스 소프트웨어가 이 동기화를 자동으로 수행합니다.
따라서 관리자가 구성 변경을 복제하는 것은 중복 작업이므로 필요하지 않습니다. 표준 운영 절차에 이 속성이 반영되어야 하며 초기 클러스터 구성이 완료된 후에는 두 컨트롤러 중 하나만 변경해야 합니다. 기존의 모든 구성을 새로 구성된 피어에 복제하는 초기 클러스터 구성 프로세스도 마찬가지입니다. 일반적으로 클러스터화된 구성의 변경사항을 적용하는 두 가지 최적의 사용법은 다음과 같습니다.
현재 기본 스토리지 또는 네트워크 인터페이스 리소스를 제어하는(또는 새 리소스가 생성되고 있는 경우 제어할) 컨트롤러에서 모든 스토리지와 네트워크 관련 구성의 변경사항을 적용합니다.
두 컨트롤러 중 하나에서 다른 모든 변경 작업을 수행하지만 둘 다에서 수행하면 안됩니다. 사이트 정책은 이 용도의 마스터로 간주할 컨트롤러를 지정해야 하며, 작동하는 컨트롤러 및 구성된 스토리지 풀 수에 따라 결정해야 합니다. 어플라이언스 소프트웨어에서는 이 사항을 구분하지 못합니다.
구성 변경사항이 해체되고 이어서 각 컨트롤러에서 손실되는 한편 해당 피어가 작동하지 않는다는 기억 상실의 문제는 크게 과장된 것입니다. 이는 특수한 경우로 각 컨트롤러의 시스템 구성에 변경사항을 개별적으로 적용하는 메커니즘이 없는 Oracle ZFS Storage Appliance에 해당됩니다. 이러한 단순화 덕분에 중앙 집중식 구성 저장소의 필요성이 줄어들고 더 간단한 접근 방식을 사용할 수 있습니다. 현재 작동 중인 컨트롤러는 구성이 올바른 것으로 간주되어 부트 시 해당 피어가 이를 동기화합니다. 향후 제품이 향상되면 구성의 차이를 해결할 수 있는 대체 정책을 선택할 수 있겠지만 이 기본 접근 방식이 가장 간단하면서 이해하기가 쉽습니다. 두번째 컨트롤러는 이미 기존 운용 시스템에서 사용되는 일련의 구성 매개변수를 사용합니다. 따라서 구성이 정확할 확률이 높습니다. 이 설정을 유지하기 위해 관리자는 장애 발생 컨트롤러가 복구되는 즉시 클러스터를 재결합하도록 설정해야 합니다.
관련 항목