스토리지에 대한 클러스터링 고려 사항
클러스터에 사용하기 위해 Oracle ZFS Storage Appliance의 크기를 조정할 때는 두 가지 추가 사항을 고려해야 합니다. 아마도 가장 중요한 사항은 모든 스토리지 풀에 동일한 헤드 소유권을 지정할지 아니면 별도로 지정할지를 결정하는 것입니다. 이 경우 아래 표와 같이 장단점이 있습니다. 일반적으로 공칭 작업 중 처리량을 위해 최적화하거나 페일오버 성능을 고려하지 않아도 될 때를 제외하고, 풀은 단일 헤드에서 구성해야 합니다. 페일오버 상태에서 성능 특성을 정확히 변경하는 것은 작업량의 특성과 크기에 따라 크게 달라집니다. 일반적으로 헤드가 특정 축에 대해 제공하는 성능이 최대화될수록 작업량이 해당 헤드의 피어에 의해 인계될 때 해당 축의 성능 저하가 더 커집니다. 물론 여러 풀을 사용하는 경우 이러한 저하는 두 작업량 모두에 적용됩니다.
어떤 구성이든 ReadZilla 장치는 해당 장치가 지정된 풀을 해당 풀의 소유권이 지정된 헤드에서 가져올 때만 사용할 수 있습니다. 즉, 헤드 장애로 인해 풀이 인계된 경우에는 해당 풀을 가져온 헤드에 미사용 ReadZilla가 설치된 경우에도 해당 풀에 대해 읽기 캐시를 사용할 수 없습니다. 이러한 이유로, 능동-수동 클러스터의 ReadZilla는 Chapter 5, 스토리지 구성 설명서에 나와 있는 대로 구성해야 합니다. 이는 스토리지 패브릭에 있고 풀을 가져온 헤드에서 항상 액세스할 수 있는 LogZilla 장치에는 적용되지 않습니다.
표 10-5 스토리지에 대한 클러스터링 고려 사항
|
|
|
|
총 처리량(공칭 작업)
|
특정 시점에 총 CPU 리소스의 50%, DRAM의 50% 및 총 네트워크 연결의 50%까지 서비스 제공에 사용할 수 있습니다. 이는 매우 간단합니다. 즉, 단일 헤드만 계속 클라이언트 요청에 대해 서비스를 제공하므로 다른 헤드는 유휴 상태로 있습니다.
|
특정 시점에 모든 CPU 및 DRAM 리소스를 서비스 제공에 사용할 수 있습니다. 특정 시점에 모든 네트워크 연결의 50%까지 사용할 수 있습니다. 사용되지 않는 네트워크 장치는 각 헤드에서 페일오버를 지원하는 데 필요합니다.
|
|
총 처리량(페일오버)
|
공칭 작업과 관련된 처리량의 변화는 없습니다.
|
작동 중인 헤드 리소스의 100%가 서비스 제공에 사용됩니다. 공칭 작업과 관련된 총 처리량은 공칭 작업 중의 사용량에 따라 약 40%-100%까지 달라질 수 있습니다.
|
|
I/O 대기 시간(페일오버)
|
페일오버 작업 중에는 사용 가능한 읽기 캐시에 발생한 과도한 읽기 작업량으로 인해 대기 시간이 크게 늘어나므로 ReadZilla를 사용할 수 없습니다. 쓰기 작업의 대기 시간에는 영향을 주지 않습니다.
|
페일오버 작업 중에는 사용 가능한 읽기 캐시에 발생한 과도한 읽기 작업량으로 인해 대기 시간이 크게 늘어나므로 ReadZilla를 사용할 수 없습니다. 헤드 리소스의 경합이 증가하면 읽기 및 쓰기 작업의 대기 시간이 모두 길어질 수 있습니다. 이는 평소의 헤드가 아닌 작동 중인 헤드에서만 두 작업량이 실행되기 때문에 발생합니다. 각 헤드의 공칭 작업량이 헤드의 최대 성능에 도달하면 페일오버 상태의 대기 시간이 크게 늘어날 수 있습니다.
|
|
스토리지 유연성
|
사용 가능한 모든 물리적 스토리지를 공유 및 LUN에 사용할 수 있습니다.
|
특정 풀에 할당된 스토리지만 해당 풀의 공유 및 LUN에 사용할 수 있습니다. 스토리지는 여러 풀에서 공유되지 않으므로 한 풀이 채워지고 다른 풀에 여유 공간이 있는 경우 일부 스토리지가 낭비될 수 있습니다.
|
|
네트워크 연결
|
헤드가 서비스를 제공하는 동안 각 헤드의 모든 네트워크 장치를 사용할 수 있습니다.
|
헤드가 서비스를 제공하는 동안 각 헤드의 네트워크 장치를 절반만 사용할 수 있습니다. 따라서 물리적으로 분리 네트워크의 절반에만 각 풀을 연결할 수 있습니다.
|
|
스토리지에 대한 두번째 중요 고려 사항은 NSPF(No Single Point of Failure)와 풀 구성의 사용입니다. 클러스터링을 사용하는 경우 응용 프로그램의 가용성이 매우 중요하므로 단일 JBOD의 오류로 인해 가용성이 손실될 수 있는 방식으로 스토리지 풀을 구성할 이유가 없습니다. 이 방식의 단점은 NSPF 구성에 단일 오류 지점 구성보다 더 많은 JBOD가 필요하다는 것입니다. 필요한 용량이 매우 적은 경우 원하는 RAID 레벨의 NSPF를 위해 JBOD를 필요한 대로 설치하는 것은 경제적이지 않을 수 있습니다.
