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