SQL Server Scale-Out 솔루션과 Oracle9i RAC 비교

SQL Server Scale-Out 솔루션과 Oracle9i RAC 비교 박명은 (mepark@microsoft.com) Technical Specialist Enterprise Partner Group Microsoft Korea

Agenda • Clustering 기술 • Oracle9i RAC • SQL Server Scale-Out clustering 기술 • 가용성 및 확장성 비교 • 구현 비용 및 총 소유비용 비교 • SQL Server Scale-Up 솔루션 • 요약

Scale–Out Clustering 기술 연합데이터 ( SQL Server) 공유데이터 ( Oracle RAC )

RAC의 기능 Node1 Node2 Instance A Instance B Parallel Cache Management DLM DLM Cluster Manager Comm. Layer Cluster Manager Comm. Layer Cluster Interconnect Shared Disk Driver Shared Disk Driver SAN이나 NAS 기술의 사용여부에 따라 HBA나 NIC필요 각 노드 당 표준 네트워크 인터페이스 카드 사용 (허브나 스위치를 통해 연결 ) Shared Disk Sub-System

RAC 구성요소들 • Cluster Manager • Global Cache Services 상태를 관리하고, 인스턴스의 버퍼 캐시에 데이터 블록을 전송하며, Global Resource Directory에 있는 리소스 정보를 조회하기 위해 버퍼 캐시 관리자와 통합 • Global Resource Directory 모든 인스턴스에 분산되어 있는 데이터 블록을 포함하여 리소스에 대한 상태 정보를 보유하고 있음 • Global Enqueue Services ( GES) 어떤 노드에서 어떤 데이터베이스 리소스가 마스터 되었는지를 추적하고, 사용자 프로세스에 의해 만들어진 데이터 작업을 동기화하기 위해 리소스를 할당 내지는 반환함 • 클러스터 상호 연결 및 프로세스 간 통신 • 작업거부 ( quiesce)데이터 베이스 기능 • 공유 디스크 하위시스템

RAC상에서 트랜잭션 처리 • 요청된 행들이 로컬 캐시에 있는지 확인 • 만약 있다면, 요청된 행들은 호출자에게 바로 전달 • 만약 없을 경우, 호출된 노드는 클러스터내의 다른 노드에 캐시 되어 있는지 확인 • 다른 노드에 캐시 되어 있다면, 캐시 블록을 호출한 노드에 보내주기 위한 일련의 프로세스가 시작되고 요청된 행을 호출자 에게 전달 • 어느 노드에서 캐시 되지 않은 경우에는 일반 읽기 작업이 수행됨

노드간 메시지의 효율성 • 각 동기화 sequence 에 필요한 메시지의 개수 • 동기화 횟수 – 적을수록 좋음 • 노드간 통신의 대기 시간 또는 속도

동기화를 위한 메시지 수 • 공동작업에 필요한 메시지 개수는 클러스터 데이터베이스의 GES구현과 복잡하게 연결됨 • 일부 데이터를 액세스 하는 경우, 아래와 같은 방식으로 이루어짐 • 데이터를 로컬이나 원격 캐시에서 사용할수 없는 경우 • 데이터가 로컬 캐시에 있는 경우 – 최상의 성능 • 데이터가 원격 캐시에 있는 경우 - 사용자 프로세스는 원격 노드상의 Global cache services 프로세스에 노드간 메시지 생성 - Global Cache services와 인스턴스 프로세스는 차례로 메모리 내부 Global Resource Directory를 업데이트하고 블록을 요청하는 사용자 프로세스로 보냄

노드간 메시지 대기 시간 • Cache fusion은 효율적으로 작동하기 위해 적은 대기 시간의 통신 프로토콜을 필요로 함 • RAC의 기능성이나 사용의 편리성은 클러스터 상호 연결과 관련된 구성 요소의 성능 및 용량 에 따라 크게 달라짐

SQL Server Clustering 기술 • SQL Server는 높은 성능과 안정성을 제공 • 최상의 총 소유비용 제공 • 최상의 가격대비 성능을 제공 • 자동화된 리소스 관리를 통한 관리에 소요되는 비용을 줄임

SQL Server Active / Passive Cluster 기술 Client Failover Clustering은 최대 8개 노드까지 지원 Primary Node \\VirtualServer1 Windows Server 2003 Secondary Node Windows Server 2003 RAID Array

Client Client //VirtualServer1 //VirtualServer2 Windows Server 2003 Windows Server 2003 Primary Node for //VirtualServer1 Secondary Node for //VirtualServer2 SQL Server SQL Server Primary Node for //VirtualServer2 Secondary Node for //VirtualServer1 Active-Active Cluster 기술 Failover Clustering은 최대 8개 노드까지 지원

SQL Server 연합서버 클러스터된 비즈니스 서비스 계층 • COM+ 구성 요소는 클러스터된 비즈니스 서비스 계층을 형성하기 위해 디자인됨 • 각 서버는 동일한 COM+ 구성 요소 집합을 가짐 • 최소의 처리 로드를 가진 서버에 새 요청을 보냄으로써 클러스터 처리 로드의 균형을 유지 인터넷 IIS COM+ ASP 데이터 서비스 계층 • 업데이트 가능한 분산 분할된 뷰 지원 • 각 노드별 자율적 작동 • 독립적 관리, 독립적 데이터 ,프로세스 지원 • 서로 협동하여 작업로드를 처리하는 자율서버 그룹 SQL Server 2000 연합서버

IIS IIS IIS IIS IIS IIS IIS IIS IIS IIS IIS IIS SQL Server CREATE VIEW Customers ASSELECT <Svr1>.Customers1 UNION ALLSELECT <Svr2>.Customers2 UNION ALLSELECT <Svr3>.Customers3 UNION ALLSELECT <Svr4>.Customers4 UNION ALLSELECT <local>.Customers5 UNION ALLSELECT <Svr6>.Customers6 SQL Server 연합서버 Svr1 Svr2 Svr3 Svr4 Svr5 Svr6 CREATE VIEW Customers ASSELECT <local>.Customers1 UNION ALLSELECT <Svr2>.Customers2 UNION ALLSELECT <Svr3>.Customers3 UNION ALLSELECT <Svr4>.Customers4 UNION ALLSELECT <Svr5>.Customers5 UNION ALLSELECT <Svr6>.Customers6

RAC의 가용성 여전히 배제할 수 없는 다운타임 존재 • 사용자 패치를 적용해야 할 경우, Oracle의 데이터 사전을 업데이트해줘야 하기 때문에 시스템은 제한 모드이어야 함 • 즉 시스템이 “다운” 되지는 않지만, 본질적으로 사용자는 사용할 수 없는 것임. • 사용자가 데이터를 입력하는 중이거나, 전자상거래 사이트의 고객트랜잭션을 완료하는 도중에 이런 경험을 하는 것은 시스템 종료와 마찬가지 임

RAC의 가용성 트랜잭션은 자동으로 장애조치를 취하지 못함 • OCI를 이용하고 있는 Oracle의 TAF(Transparent Application Failover)를 이용하는 어플케이션을 구축해야 함 • 어플리케이션이 서버의 상태를 추적하여 현재 어떤 어플리케이션이 연결되어 있는지를 알아 낼 수 있음 • 연결된 서버가 실패할 경우에도 어플리케이션은 자동으로 어플리케이션은 쿼리를 다시 보내고 또는 그 쿼리를 여유 노드로 보낼 수 있음. • 그러나 트랜잭션 상태가 항상 저장되어 있기 때문에 이 기능을 사용하는 것은 심각한 부담을 줄 수 있음

RAC 가용성 요약 • 제품 자체적으로는 자동적인 고 가용성을 제공하지 않음 • 대부분의 기업내의 Biz App들은 자동화된 트랜잭션 장애조치 기능을 보유하지 않음 • 다운타임은 여전히 존재 • 특정 Patch는 여전히 다운타임이 요구됨 • TAF (Transparent Application Failover)로 개발되지 못한 어플리케이션의 장애 • TAF 로 개발된 어플리케이션들은 트랜잭션이 중단되는 일이 없는 반면, 시스템 작동이 늦어짐

SQL Server 가용성 클러스터된 비즈니스 서비스 계층 • COM+ 구성 요소는 클러스터된 비즈니스 서비스 계층을 형성하기 위해 디자인됨 • 각 서버는 동일한 COM+ 구성 요소 집합을 가짐 • 최소의 처리 로드를 가진 서버에 새 요청을 보냄으로써 클러스터 처리 로드의 균형을 유지 인터넷 IIS COM+ ASP 데이터 서비스 계층 • 업데이트 가능한 분산 분할된 뷰 지원 • 각 노드별 자율적 작동 • 독립적 관리, 독립적 데이터 ,프로세스 지원 • 서로 협동하여 작업로드를 처리하는 자율서버 그룹 SQL Server 2000 연합서버

Client PCs Server B Server A Cluster management Client PCs Heartbeat Server A SQL Server Server B Exchange Server Disk cabinet A Server A Server B Cluster management Disk cabinet B Heartbeat Server B Exchange Server SQL Server Server A SQL Server Disk cabinet A Disk cabinet B SQL Server 가용성

RAC의 확장성 • RAC이 OPS의 주요 병목지점인 디스크 입출력 프로세스를 제거했다고는 할지라도, 이는 다른 영역으로 옮겨놓은 정도일 뿐임 • 노드간 상호 연결의 본래 대기시간은 SMP 시스템 버스에서 경험하는 시간보다 현저히 높다 • 더 용량의 NIC나 스위치를 사용하는 것은 단순히 최고 한도를 약간 올려주는 정도임. 그 이유는 RAC의 설계에 있기 때문 • RAC의 설계는 저장소와 연결된 구간에서 심한 리소스 충돌을 일으키기 때문

RAC의 확장성 다음 그림은 노드의 수가 증가함에 따라 어떻게 클러스터 상호 연결이 각 노드가 발생시키는 트랜잭션에 의해 지배당 할 수 있는 가를 보여주는 예임 2002년 9월 15일자 출처 : www.tpc.org

RAC 확장성 요약 • 확장성 측면에서는 10g에서 향상되었지만, SMP System에는 여전히 부족함 • Writes가 많은 시스템인 경우는 제대로 성능을 내지 못할 수 있음 • Oracle을 사용하고 있는 대규모의 사이트들은 SMP Sever을 사용하고 있음 • SQL Server는 TPC-C, TPC-W, SAP, Onyx등과 같은 각종 업계 벤치마크에서 선두적인 입지를 차지함 • 수평적 확장 벤치마크 전용인 SQL Server 노드 진행 (16, 24, 32노드) 부분에 있어 Oracle RAC에서 보여주지 못했던 확장성을 보여주고 있음

RAC은 총 소유 비용 절감? • RAC구현 시 유일한 비용절감은 값비싼 Unix 시스템에서 Intel 기반 제품 시스템으로 옮기는 경우 • 사용자가 이미 Intel 기반 서버를 사용하고 있다면 RAC을 구현할지라도 경비 절감을 할수 없으며 오히려 RAC을 구현하기 위한 총 소요비용은 더욱 높아짐 • 추가 서버 및 네트워킹 하드웨어 • 스토리지 솔루션 ( 내장된 스토리지는 작동안됨) • 광 연결 솔루션 ( 노드가 두개 이상 ) • 추가 Oracle 데이터베이스 라이센스 ( 노드 별 ) • 훈련된 운영자와 관리 • 마이그레이션 및 인증 서비스 • 기존 하드웨어와 오래된 하드웨어 재사용 안됨 • 그 외에 인프라요구사항과 DBA및 Network 관리자의 관리작업에 소요되는 비용이 추가됨.

RAC은 총 소유 비용 절감? • ACME ERP 시스템 • 10,000 동시 사용자 지원 • 시스템은 총 8-CPU와 16GB RAM을 필요로 함 단일 서버, 최소 고 가용성 기능 가상 시나리오

RAC은 총 소유 비용 절감? • 동일한 ACME ERP 시스템 • 10,000 명의 동시 사용자 지원 • 시스템은 총 8-CPU와 16GB RAM 을 필요로 함 • 장애 조치 클러스터링 중복 저장소 기능 보유 • 각각의 노드는 노드 오류가 발생하는 경우 나머지 작동되는 노드가 전체 부하를 제어하고 아무런 문제없이 실행되도록 하기 위해 8-CPU와 16GB RAM을 보유하고 있음 고 가용성 장애 조치 클러스터 ( SQL Server 2000과 같이 ) 8-CPU 16GB RAM 8-CPU 16GB RAM

RAC 은 총 소유 비용 절감 ? RAC 구성에 대한 잘못된 가정 • 동일한 ACME ERP 시스템 • 10,000 명의 동시 사용자 지원 • 시스템은 총 8-CPU와 16GB RAM 을 필요로 함 • 장애조치 클러스터링과 중복 저장소 기능 보유 • 각각의 노드는 4CPU, 8GB 보유 • 오류 발생시, 작동중인 노드는 과부하 상태에 이르게 되며, 10,000 명의 사용자에 대한 부하를 지원할 수 없기 때문에 약 50%의 사용자는 서비스를 받 을 수 없음 4-CPU 8GB RAM - 오류 - 4-CPU 8GB RAM - 과부하 -

RAC은 총 소유 비용 절감? RAC를 포함한, 고 가용성 클러스터를 위한 올바른 배포 • 동일한 ACME ERP 시스템 • 10,000 명의 동시 사용자 지원 • 시스템은 총 8-CPU와 16GB RAM 을 필요로 함 • 장애 조치 클러스터링과 중복 저장소 기능 보유 • 각각의 노드는 8CPU, 16GB 보유 • 오류발생시, 작동중인 노드가 모든 부하를 담당하며, 아무런 문제없이 작동함 8-CPU 16GB RAM - 오류 - 8-CPU 16GB RAM - 정상처리 -

RAC은 총 소유 비용 절감? • 4CPU, 8GB 를 보유하고 있는 하나의 기계가 5,000명의 사용자를 지원 할수 있다고 할때, 10,000 명의 사용자를 지원할 수 있는 것은 아님 • Oracle은 두번째 노드 추가시 85% 성능의 증가를 확보한다고 했으며, 노드의 수가 증가할수록 노드별 성능증가는 현저하게 감소 • 실제, 최상의 가용성을 보유하고 있는 시스템인 경우, SQL Server clustering 기술과 비교하여 추가로 필요한 구성 요소들이 있기 때문에 하드웨어, 소프트웨어, 관리비용이 증가됨 • SQL Server clustering 기술보다 총소요비용 증가 (데이터베이스 소프트웨어 와 서비스비용 및 관리비용은 절대 절감되지 않음)

Clustering 구현비용 2004년 1월 Oracle, Microsoft Website에 기재된 List Price 기준( CPU기준) X : Not Available V : Server 라이센스에 포함 $ : 추가비용 발생

Cost Savings Scalability Manageability 64-bit Database PlatformHigh-performance computing • Windows Server 2003 64bit 에 최적화 • 최상의 성능 • 대용량 메모리 어드레싱 (up to 32 TB) • 거의 무한대의 가상메모리 (up to 8 TB) • 대용량 메모리 버퍼 풀 지원에 따른 I/O 가 적어짐 • SQL Server 2000 32bit과 T-SQL 코드 호환가능 • 8 node 클러스터링 지원 • 32-bit 과 같은 데이터 format을 사용함으로 마이그레이션 쉬움 • RDBMS and BI 모두 64bit 지원 • 고가의 Unix 솔루션을 위한 대안

Scale-Up 서버 확장

요약 • SQL Server는 TPC-C, TPC-W, SAP, Onyx등과 같은 각종 업계 벤치마크에서 선두적인 입지를 차지하고 있음 • SQL Server는 높은 성능과 안정성을 필요로 하는 사용자를 위해 최상의 총 소유 비용을 제공함 • SQL Server는 최상의 가격대비 성능을 제공 • SQL Server는 지능적이고 자동화된 리소스 관리 기능을 제공함으로써, 관리부담도 줄여줌

SQL Server Scale-Out 솔루션과 Oracle9i RAC 비교