SteelEye 표준 제안서

1. SteelEye 소개 SteelEye Protection Suite

2. About SIOS Technology Corp. SIOS Business Area Cloud #1 Public Cloud Service (NikkeiBP) Open Source Solution Java 1997 2001 2005 2007～ Value for Business High Availability #2 HA Software #1 APAC Best Partner Award (RedHat) 1. About SIOS Technology • 1997: Company Founded • 2003: Business partnership with Red Hat • 2004: IPO on the JStock Exchange • 2005: Acquired SteelEye Technology, Inc 10년 이상 Open Source환경의 사업기반을 통해, 위 환경에서 최적화된 이중화 솔루션사업과 Cloud서비스로 사업영역을 확대 2. About SteelEye Solution • Established in 1999 as SteelEye Technology, part of SIOS Technology (publicly traded in Japan) since 2005 • Provides Best-In-Class High Availability, Data Replication and Disaster Recovery solutions • Over 35,000 licenses installed worldwide • Strategic Relationships with HP, IBM and SAP • Multi-time award winner for Linux High Availability with RedHat and Novell certified solutions • Microsoft Gold Certified Partner Long terms of Focus on Ensuring Availability and Architecture Consistency 1992 AT&T Bell Lab’s Cluster R&D 1996 NCR Spinout to NCR R&D in South Carolina 1999 SteelEye Combine Cluster & Data Replication 2006 SIOS Software for Innovation Open Solutions

3. 1. 제안 배경 2. SteelEye 소개 CONTENTS 별첨3. 데이터 복제 방식 비교 별첨5. DR정책 수립과 DR 고객 사례 3. SteelEye 구성 방안 별첨1. SteelEye 아키텍쳐 4. Reference 5. 결론 별첨2. H/A와 유사 솔류션 비교 별첨4. vAppKeeper 소개 별첨6. Heartbeat구성과 IO Fencing

4. 1. 제안 배경

5. Host 2. Linux환경으로의 변화 배경 3. IT 인프라 환경 변화 4. 변화에 따른 당면 과제 Unix Linux • RDB는 RAC를 쓰기 위해 고비용의 Oracle이 계속 강세로 갈것인가? • High-End 대용량 SAN Storage가 Scale-Out개념의 환경에 적합한가? • RDB이외의 Open Source 기반 S/W들의 이중화는 어떻게 할것 인가? • 과거의 이중화나 DR구축 방안들은 새로운 환경에 적합한가? 새로운 환경에 적합한 이중화 및 DR Solution 필요성 대두 • H/W, OS, S/W  Full One Vendor • 고가, Permanent License • H/W, OS  One vendor • S/W  Multi vendor • 개발, Support  각 Vendor • 고가, Permanent License • H/W, OS, S/W Full Multi vendor • Open Source • 개발, Support Multi vendor • 저가, Subscription License 1. IT Trend 변화 • ‘Linux’와 ‘x86’서버  성능, 가격, 안정성 검증 완료 • ‘가상화’와 ‘Cloud’ 필요성 대두 효율화, Scale-out, 상면, 저전력, 친환경 • UNIX  X86, Linux, 가상화, Cloud 환경 • Oracle DB  Open Source RDB • Vendor S/W  Open Source S/W  x86,가상화,Cloud환경을 지원하는가?  다양한 Linux배포판을 지원하는가?  Non-shared storage도 지원하는가?  다양한 이중화 대상 S/W를 지원하는가?  저비용/고효율 이중화/DR 구축 가능한가? 1. 제안 배경

6. 2. SteelEye 소개

7. 2. SteelEye 소개 기본 개념 Shared Storage Cluster Shared Nothing Cluster Fail-over Fail-over Active Stand by Active Stand by Server Data Instance Server Instance Data Server Instance Data Server Instance H/A H/A Replication  모니터링 Resource (Application, Server, Storage, Data, Network 등)을 주기적으로 감시하여, 장애발생시 자동으로 Fail-over하여 서비스를 복구  SteelEye는 Shared Storage환경”의 H/A Cluster 및 Shared Nothing 환경에서 Replication을 통한 H/A Cluster 두가지 구성 제공

8. 2. SteelEye 소개 Shared Storage vs. Shared Nothing Shared Storage Cluster Shared Nothing Cluster Fail-over Fail-over Active Stand by Active Stand by Instance Instance H/A • LAN or WAN recovery 환경도 가능 • Shared storage의 single point of failure 제거 • DR 구성에 적합 • 기존 Storage Replication 대비 비용 절감 • 복제된 데이터도 H/A Automated failover protection 의 한 구성 요소로 관리 Server Data Instance • Fibre Channel SAN, iSCSI or NAS 필요 • 동일 Data Center 내에서만 가능 • 데이터 정합성 보장을 위한 I/O fencing은 SCSI 3 PR 기본 제공(추가 fencing구성 가능) • 여러 storage type 지원 • 여러 Multi-Path solution 지원 • Storage에 Single Point of failure 존재 Server Data Server Data Server Instance H/A Replication

9. 2. SteelEye 소개 Shared Storage vs. Shared Nothing 항목 비교 설명 비용 Shared Nothing 우수 Shared Storage로 이중화 구성시, SAN Switch 및 외장 Storage로 공유환경을 구성하여야 하므로, Local Disk나 DAS로 Storage를 구성하는 환경에 비해 Storage 구성비용이 상대적으로 고가 Component 이중화 Shared Nothing 우수 Shared Storage환경으로 이중화 구성시, 서버 장애는 대비가 되지만, Storage장 애 시 서비스를 Fail-over할 수 없는 SPOF(Single Point of failure)가 존재 Active노드의 Write성능 Shared Storage 우수 Replication을 Async로 구성 시 는 성능이 동일하나, Sync 방식으로 구성 시, Standby노드 까지 Write가 완료 되어야만, Active노드의 Write가 완료되는 구조 이므로, Active노드의 Write작업에 일부 성능 저하 Active노드의 Read 성능 동일 Read는 Active 노드 단독으로만 처리하기 때문에 영향 없음 DR 구성 Shared Nothing Only Replication을 통한 DR구성 Replicated Storage 활용 임시 테스트 환경 Shared Nothing Only Standby노드로의 복제를 임시 중단하고, Standby 시스템을 테스트용으로 활용 가능하다. 테스트 완료 후 복제를 재개하면, 전체 스토리지 볼륨을 복제하는 것 이 아니고, 테스트 시에 변경된 블럭과 복제가 중단된 블록만 다시 Sync하여, 빠른 시간 안에 HA Standby로 복귀가 가능 Rolling Patch 작업 Shared Nothing Only 복제 구성 시, OS나 DB같은 시스템 S/W가 설치된 볼륨은 복제를 하지 않고, 데 이터 영역만 복제 구성을 합니다. OS, DB등의 S/W영역에만 변경이 일어나는 Patch와 같은 작업 시 일부 절체 시간의 중단만으로, Active노드를 변경하면서 작업이 가능

10. 2. SteelEye 소개 Scalable Availability Hybrid Shared Storage Cluster with WAN replication (DR) All configurations supported across both physical and virtual servers Single Node Monitoring & Recovery Two Node LAN Failover Cluster with Shared Storage Two Node LAN Failover Cluster with Data Replication N-Node WAN Failover Cluster with Data Replication (DR)

11. 2. SteelEye 소개 Product 구성 Combining High Availability with efficient Data Replication to ensure Business Continuity for your Mission Critical Apps! SteelEye Protection Suite Application Recovery Kits LifeKeeper DataKeeper  LifeKeeper: Server 및 Application의 장애 감지를 통한 자동 fail-over를 담당하는 H/A Cluster 모듈  DataKeeper: Real-time, High performance의 Data volume Replication 모듈로 LifeKeeper와 연동  ARK: Application의 장애 감지 및 fail-over를 위한 Built-in된 Knowledge 모듈로 LifeKeeper와 연동

12. 2. SteelEye 소개 Key feature 다양한 x86 환경 지원 우수한 복제 성능 다양한 Resource 지원  다양한 Enterprise Linux 배포판 지원  다양한 가상화, Cloud 환경 지원  Shared Storage 외 Local, DAS Storage 지원  각 스토리지 밴더의 multipath 드라이버 지원  LAN/WAN환경에서의 Host-based Replication  Sync/Async/Periodic 모드 복제 지원  Block 단위 Volumn/LUN 복제로 대용량 파일 처리에 적합  Fail-over시 자동 Source/Target변경  각각 다른 설정의 Multi-target 지원  Dirty block을 bitmap으로 관리하여 full resync 방지  복제 대역폭 제한 및 9단계의 압축 전송 지원  30여개의 주요한 Application에 최적화된 knowledge module  각 리소스 타입별 최적화된 기동/정지, 상태 check 제공  리소스 타입별로 2 level(quick/deep check) health check 제공 구성 및 운영 편의성  각 리소스 type 별 wizard를 통한 리소스 등록 및 관리  Java 기반 GUI 및 CLI 제공  비즈니스 변화에 따른 노드 증설, 변경 및 축소 용이함  클러스터 상태 모니터링을 위한 SMTP/SNMP trap 지원  Shared Storage 및 Shared Nothing 환경 지원  1:1, 1:N, N:1, DR, cross standby 구성 지원  Virtual, Physical 간의 자유로운 이중화 구성 지원 다양한 구성

13. 2. SteelEye 소개 Support Environment •Linux RHEL, SLES, OEL, CentOS, Asianux •Windows 2003,2008, 2012 Virtualizations •Citrix XenServer •MS Hyper-V •Red Hat KVM •OracleVM •Vmware ESX •Shared Storage SAN, iSCSI, NAS •Non-Shared Storage Internal Disk, DAS, Fusion IO Storage Type O/S Supported Environment

14. 2. SteelEye 소개 Support ARK Services Applications Application Recovery Kits •Apache •Samba •NFS •SW Raid(md) •SAP •WebSphere MQ •Exchange •Any Custom App •Oracle •MySQL •PostgreSQL •Sybase •DB2 •MSSQL Storage •DMMP •NAS •EMC PowerPath •Hitachi HDLM •IBM SDD •Data Replication Databases

15. 2. SteelEye 소개 GUI를 통한 리소스 등록 및 관리 가능 각 리소스 타입별 관리 메뉴 제공 각 리소스 타입별 설정 마법사 제공 각종 로그 조회 및 리소스 상태 관제 가능 GUI

16. 3. SteelEye 구성 방안

17. 3. SteelEye 구성 방안 기본 구성 Shared Storage Shared Nothing Active Stand by Active Stand by Server H/A H/A Data Instance Server Instance Data Server Instance Data Server Instance Replication 모든 구성에서 Server는 Physical, Virtual모두 가능 즉, PP, PV, VP, VV 모두 가능

18. 3. SteelEye 구성 방안 N:1 구성 Data2 Active Server Data1 Sync Active Server Data2 Server Data1 Instance2 Standby Instance2 Instance1 Instance1 Active Server Data1 Server Active Server Instance2 Sync Data2 Standby Instance2 Instance1 Instance1 Shared Nothing Shared Storage

19. 3. SteelEye 구성 방안 Crose Standby Active/Standby Server Instance1 Instance2 Data2 Sync Data1 Active/Standby Server Instance1 Instance2 Data1 Data2 Sync Shared Nothing Shared Storage Active/Standby Server Instance1 Instance2 Data1 Data2 Active/Standby Server Instance1 Instance2

20. 3. SteelEye 구성 방안 DR 구성 Active Server Instance Data Standby Server H/A H/A Instance Data Sync DR Server Instance Data Async Shared Nothing Shared Storage Active Server Data Instance Standby Server Instance DR Server Instance Data Async H/A H/A

21. 4. Reference

22. 5. 결론 SteelEye Protection Suite 10년이상 검증된 Architecture의 Consistency  x86(Linux, Windows), 가상화, Cloud 환경에 최적화  Open Source를 포함한 다양한 Linux배포 버전을 지원  다양한 Resource들을 Script작성 기반이 아닌 지능화된 Application감시 모듈  HA Fail-over, Data Replication, DR을 하나의 솔류션으로 구축 storage-based DR/Replication보다 유연하고 저가의 구축 가능  다양한 환경 구성(1:1, N:1, DR, cross standby, Shared Storage/Shared Nothing)  Block기반 복제로 빠른 성능 및 DB이외의 다양한 형태의 Replication 지원  설치, 구성, 운영 작업에 직관적인 Wizard 형태의 GUI 제공  Business 요구사항 변경에 따른 유연한 확장/변경 가능

23. 별첨1. SteelEye 아키텍처

24. 별첨1. SteelEye 아키텍처 LifeKeeper 아키텍쳐 Resource Monitoring Direction / Action LifeKeeper Configuration Database (LCD) Recovery LifeKeeper Communications Manager (LCM) Application Recovery Kit LifeKeeper core LifeKeeper GUI client LifeKeeper Recovery Action and Control Interface (LRACI) LifeKeeper Alarm Interface LCD Interface (LCDI) LifeKeeper Node To LCM on another node LifeKeeper GUI server

25. 별첨1. SteelEye 아키텍처 DataKeeper 아키텍쳐 bitmap file bitmap file Active의 디스크와 리모트의 디스크는 nbd와 software RAID를 통해 복제

26. 별첨1. SteelEye 아키텍처 Replication Workflow(Sync) 1 Read I/O 2 3 4 5 Write I/O bitmap file bitmap file 6 1) Source 서버 Write 발생 2) Source 서버의 Bitmap File Dirty 3) Target 서버의 Disk에 Write 수행 4) Source 서버의 Disk에 Write 수행 5) Source 서버의 Bitmap File clear 6) Write 완료

27. 별첨1. SteelEye 아키텍처 Replication Workflow(Async) 2 4 3 5 bitmap file bitmap file 6 1) Source 서버 Write 발생 2) Source 서버에 Bitmap File Dirty 3) Target 서버에 Write 요청 전달 4) Source 서버의 Disk에 Write 수행 5) Source 서버의 Bitmap File clear 6) Write 완료 Read I/O Write I/O 1

28. 별첨2. H/A와 유사 솔류션의 비교

29. 별첨2. H/A와 유사 솔류션의 비교 1. CDC 2. Storage Replication Server Instance Data Server Instance CDC Replication Data Backup / Test Data Active’ • CDC(Change Data Capture)솔류션을 통해 Source 노드의 변경사항을 Target에서 DML실행으로 동기화하는 방식 • Async방식이고, (일부)데이터가 논리적으로 동일한거지, 물리적으로 같은 DB라고 보기 어려워, 이중화로 활용 어렵다 • 부분 복제, 집계성 복제를 통한 별도의 Read/Write가능한 DB로 활용에 유리 • EMC의 BCV, Hitachi의 SI같은 Storage Replication 이용한 Storage이중화 방식 • 복제성능이 빠르고, 안정성이 검증되어 주로 백업부하 분산용과 복구용으로 유리 • 고가의 Enterprise Storage와 해당 벤더의 고가의 복제솔류션 필요 • 자동Fail-over구성 안되고, 일반적으로 특정 시점 기준으로 Sync되도록 구성 Active Server Active Instance Server Instance Data’

30. 별첨2. H/A와 유사 솔류션의 비교 3. Oracle: RAC 4. Oracle: Active Data Guard Active Active Active Read Only Server RAC Data Instance Server Instance Data Server Instance Data Server Instance • Storage 이중화가 안되어 있음 • Active-Active가 가능한 유일한 방법으로 고가의 Unix의 Oracle환경에서 유리 • Fail-over시간이 짧거나 무중단 서비스 가능 • Oracle만 가능 ADG • Oracle복구 방식으로 Block level동기화 방식 • 속도 빠르고 Target노드를 ReadOnly로 읽기부하 분산 및 백업 부하 분산용으로 활용 가능 • Read Only  ReadWrite전환 포함한 Fail-over 자동화 구성 안됨 • Oracle만 가능

31. 별첨2. H/A와 유사 솔류션의 비교 5. H/A Solution - Server Only 6. H/A Soution - Server+Data Active Stand by Active Stand by Server H/A Data Instance Server Instance Data Server Instance Data Server Instance • Server나 Instance 장애 시 중단 후 자동 Fail-over되어 서비스가 재개되는 구조 • 평상시에 Stand by서버가 유휴이므로, 상대적으로 저가인 Linux나 가상화 환경에서 유리 • Storage 이중화가 안되어 있음 • DB이외의 모든 서비스에 활용 가능 H/A Replication • Server, Instance, Storage에 장애 시 중단 후 자동 Fail-over되어 서비스가 재개되는 구조 • 평상시에 Stand by서버가 유휴이므로, 상대적으로 저가인 Linux나 가상화 환경에서 유리 • DB이외의 모든 서비스에 활용 가능

32. 별첨2. H/A와 유사 솔류션의 비교 이중화 구성 방안 이중화 Component 활용 범위 Fail-over 자동화 주 용도 Server Instance Data CDC - - - DB Ⅹ 부분 복제, 집계성 복제를 통 한 타시스템 IF나 읽기부하 분 산용 및 별도의 Read/Write가 능한 DB로 활용에 유리 Storage Replication - - - ALL Ⅹ 백업부하 분산 및 빠른 복구를 위한 1차 백업용으로 유리 Oracle: RAC O O Ⅹ Oracle O (무중단) RAC + ADG로 구성시 고가의 Oracle환경에서 장애복구, 읽 기부하 분산, 백업부하 분산용 Oracle: ADG △ △ O Oracle Ⅹ 으로 유리 HA – Server Only O O Ⅹ ALL O (중단후) 상대적으로 저가인 Linux 및 가상화 환경에서 DB를 포함한 여러 이중화 환경 구성에 유리 HA – Server+Data O O O ALL O (중단후)

33. 별첨3. 데이터 복제 방식 비교

34. 별첨3. 데이터 복제 방식 비교 CDC방식 Log Apply 방식 File 단위 복제 Block 단위 Volumn/LUN 복제 설명 Active node의 DML을 Log 에서 추출하여 Target node 에서 SQL execution하는 방 식 Active노드에서 발생한 DB 복구를 위한 Log를 Target node에서 Log apply(=recovery)를 하는 방 식 Active node에서 변 경된 파일을 Target node에 전송하는 방 식 Active node에서 변경된 Block 만을 Target node로 전송하는 방식 적용가능 범위 DB에만 사용 가능 DB에만 사용 가능 Raw Device를 제외 한 모든 File에 사용 가능 Raw Device를 포함한 모든 데 이터 복제에 사용 가능 솔류션 •SharePlex •Oracle Golden Gate •MySQL Replica 등 • Oracle Active Data Guard – Physical mode • Cubrid Replication BCV DataKeeper 등 동기화 방식 Async Async/Sync Async/Sync Async/Sync 성능 느림 중간 중간 빠름 전송량 적음 보통 많음 적음 비교 • 성능이 느린 경우가 많다. • 솔류션에 따라 읽기 정합 성이 순간 불일치 난다. • 데이터 불일치 상태를 모 니터링 하기 어렵다. • 동기화에 문제가 없으면 논리적으로 동일한 데이터 이지만, 물리적으로 동일하 지 않다 • DB벤더에서 제공하는 가 장 안정적인 DB복제 방식 • 복제 중간에 복제가 중단 되면, 이후에 복제를 따라 가기 위해서는 중간의 모 든 로그를 Apply해야만 한 다. 복제 Target을 읽기전 용과 같은 용도로 사용 가 능 • DB처럼 I/O의 단위 가 파일단위로 Write가 일어나지 않는 경우 적용이 어렵다. • 인프라적으로 가장 빠르고 안 정적으로 복제를 하는 방식이 다. • 물리적으로 동일하기 때문에, Fail-over나 DR구축 용으로 가 장 안정적인 복제 방식

35. 별첨4. vAppKeeper 소개

36. 별첨4. vAppKeeper 소개 VMWare HA의 한계 • VMware HA strength lies in protection against hardware failures • 80% of unplanned outages are the result of application failures, mis-config urations and other operational errors • Application awareness is essential to maximizing application availability

37. 별첨4. vAppKeeper 소개 vAppKeeper Brings Application Awareness to your VMware HA • Cost-effective high availability solution for applications that do not r equire multi-node clustering – No standby resources (hardware, software, etc.) necessary – Less complex to deploy and manage than multi-node clustering – Plugin allow management and monitoring through the vSphere Client • Allows customer to fully leverage VMware tools and automation wit hout compatibility issues

38. 별첨4. vAppKeeper 소개 vMotion HA DRS vSphere Client w/ vAppKeeper Plug-in VMware HA Application Monitoring API App OS OS OS OS SMC vAK App vAK App vAK App vAK HTTP Browser-Based vAppKeeper UI

39. 별첨4. vAppKeeper 소개 vAppKeeper • Monitors the health and applications (A) and their dependencies (D) • Withholds heartbeat to instruct VMware HA to respond to an application failure (restart, VMotion) VMware HA • Monitors physical host for failure • Monitors virtual machine for failure • Can monitor VMware Tools heartbeat to identify OS failure

40. 별첨4. vAppKeeper 소개 Visibility • vSphere Client dashboard and gran ular application hierarchy views Flexible Management Options • Brower-based user interface • Command-line interface • Multi-level policy • Temporal recovery logic

41. 별첨4. VMWare HA vs. vAppKeeper vs. SPS 구성 방안 이중화 구성 SPOF / 감지불가 자원 이중화 비용 비고 VMWare HA vAppKeeper LifeKeeper + ARK DataKeeper 구성1 ○ •Storage •Application •VM OS 0 • VM HA만을 사용하는 경우 가 상화 서버에 대한 HA만을 지원 • 가상화 서버내에서 수행되는 Application장애 감지를 위해서 는 vAppKeeper필요 구성2 ○ ○ •Storage •VM OS 5 구성3 ○ •Storage 10 • VM HA와 SPS를 같이 사용하 는 경우 SPS가 기 구성된 Standby node로 Fail-over를 하 게되면, VM HA는 장애난 Active 노드를 자동으로 기동하 여, 빠른 Fail-back이 가능하게 된다. • 즉, SPS를 사용하게 되더라도 VM HA를 같이 사용하는게 이 중화 측면에서는 유리하다 구성4 ○ ○ •Storage 10 구성5 ○ ○ - 20 구성6 ○ ○ ○ - 20 vAppKeeper는 vSphere환경의 Linux버전만 지원

42. 별첨5. DR정책 수립과 DR 고객 사례

43. DR 정책 수립 RPO & RTO RPO (Recovery Point Objective) What is the point of data revovery? RTO (Recovery Time Objective) How much time does it take to restart? Disaster Time Normal Operation Stop ReStart 2Weeks 1Week １Day ０ ??Days/Hours/Minuties

44. DR 정책 수립 Investment VS. RPO/RTO Investment RPO Disaster (Recovery Point Objective) What is the point of data revovery? RTO (Recovery Time Objective) How much time does it take to restart? It requires more investment if PRO/PRT closer to the Disater.

45. The Investment V.S. DR Solution RTO Investment Back Up Replication Cold Site RPO Warm Site Hot Site RPO’s cost depends on How to protective system HA Clustering RTO’s cost depends on How to build back-up site DR 정책 수립 SteelEye는 Replication을 포함한 HA Cluster로 Hot Site로 DR을 구성

46. DR Case Study – Central Bank of Russia • Customer’s payment system involves over • 600 bank offices • 1100 commercial banks • 2400 side offices. • Complicated daily account routines generate a tremendous flow of electronic payment documents • over a billion electronic filings every year • Ensuring data aggregation and integrity back to a central storage vault was mission critical • Ensure availability of key Oracle databases and customer applications while avoiding the single points of failure of shared storage • Minimize cost Challenge:

47. DR Case Study – Central Bank of Russia • SPS for Linux was implemented to ensure same and seamless failover of Oracle databases and Custom applications • Twin clusters were built at primary/backup Data Centers with continuous data replication between nodes. LifeKeeper’s scalability allows the customer to grow to geographically disperse clusters with ease. • The LifeKeeper cluster eliminates data loss due to any hardware or software faults and provides high availability for applications and processed data, even in the event of a total datacenter loss • Customer was able to easily and quickly meet their goals with minimal expense Solution Results “The SteelEye LifeKeeper solution allowed us to considerably improve availability of the payment data gathering system and to eliminate data loss by its replication while receiving data from remote data sources.“ -A. L. Danilov, Chief Engineer, Central Bank of Russia (ICI BR)

48. DR Case Study – U.S. Navy fleet • Customer needed to ensure continuous availability of infrastructure services needed to support combat systems • Solution needed to support commercially available hardware and software running on RedHat Linux • Required a solution that supported multi-site cluster configurations to protect against hardware losses • Required the ability to cascade application recovery across prioritized nodes Challenge:

49. DR Case Study – U.S. Navy fleet • SPS for Linux Multi-Site Cluster was implemented to ensure NFS services are high available to support mission critical systems. • At each location the customer implemented a 3-node hybrid cluster: • 2-nodes with iSCSI shared storage at primary data center (IBM Blades and DS3500 storage) • Replicated 3rd node at backup data center • The LifeKeeper multi-site cluster solution provides high availability for mission critical combat systems, even in the event of a total datacenter loss • Less expensive and more flexible than storage-based replication solutions. Customer needed to re-use existing mixed hardware/storage. Solution Results "As a leading alternative in reliable, flexible high availability clustering solutions for Linux, SPS for Linux Multi-Site Cluster Edition enables us to provide a disaster recovery infrastructure with the capability to support the critical weaponry of the U.S. Navy fleet." -Craig Black, GTS program manager for the CPS project

50. DR Case Study – Paraca Why DataKeeper? Request Replication for heavy data such as local map and the pictures of parking space Protection for code/encryption files Replication of Data ONLY Easy to set up DataKeeper １．High C/P ２．Block-level replication & groupware support ３．Low cost ４．Easy UI Restart in short time ５．Replication

51. DR Case Study – Paraca DataKeeper Other Application Data Compression 1 2 3 4 5 6 7 Data Compression 1 2 3 About 3 9 8 9 For long distance replication, DataKeeper could keep throughput by different compression ratio Why DataKeeper?

52. DR Case Study – Paraca DataKeeper Other Application Replication Replication Block level File level For long distance replication, DataKeeper could Copy data by block level Why DataKeeper?

53. DR Case Study – NewStar in England Configuration 12km WAN 460km 5,500km Exchange Exchange Exchange Exchange WAN Bermuda Ireland London A London B

54. Case Study – K사 구성도 xxx동(전산실) xxx동(DR Center) 20TB ECM Web 2TB 6TB ECM DB ECM Search EMC VNX7500 SAN Storage 20TB ECM Web 2TB 6TB ECM DB ECM Search EMC VNX5300 SAN Storage Virtualization Host Server KRASN130P Active Standby VIP:X.X.X.X Replication VIP:X.X.X.X Replication VIP:X.X.X.X HP DL380G8 • CPU: (2)2.50GHz (12Core) • RAM: 72GB • Disk1: 300Gx2(R1) • Disk2: 300Gx2(R1) • Disk3: STORAGE • OS: Win2008R2 HP DL380G8 • CPU: (2)2.50GHz (12Core) • RAM: 72GB • Disk1: 300Gx2(R1) • Disk2: 300Gx2(R1) • Disk3: STORAGE • OS: Win2008R2En • DB: SQL2012Std HP DL380G8 • CPU: (2)2.50GHz (12Core) • RAM: 72GB • Disk1: 300Gx2(R1) • Disk2: 300Gx2(R1) • Disk3: STORAGE • OS: Win2008R2En • DB: SQL2012Std ECM WEB ECM DB ECM 검색 섬 네일 PDF 변환 ECM WEB ECM DB ECM 검색 ECM 개발 Virtual Machine CPU : 2Core RAM: 10GB OS: Win2008R2 HP DL380G8 • CPU: (2)2.50GHz (12Core) • RAM: 72GB • Disk1: 300Gx4(R5) • Disk2: STORAGE • OS: Win2012 이중화 제외 서비스 Virtual Machine CPU : 2Core RAM: 10GB OS: Win2008R2 Virtual Machine CPU : 2Core RAM: 10GB OS: Win2008R2 Virtual Machine CPU : 2Core RAM: 10GB OS: Win2008R2 개발사 제품명 용도 SIOS SteelEye Service 와 Data 를 이중화 및 복제 솔루션 Microsoft Hyper - V 윈도우 서버 가상화 솔루션으로 물리머신에 여러 대의 가상 서버를 올려 주는 제품 구 분 총 가용량 (RAW) 사용량 (TB) 잔여공 간 NL-SAS 88 TB 67 TB 13 TB SAS 20 TB 14 TB 5.9 TB 구 분 총 가용량 (RAW) 사용량 (TB) 잔여 공간 SAS 36 TB 28TB 8TB

55. SteelEye 구성 방안 DR 구성 Active Server Instance Data Standby Server H/A H/A Instance Data Sync DR Server Instance Data Async Shared Nothing Shared Storage Active Server Data Instance Standby Server Instance DR Server Instance Data Async H/A H/A

56. 별첨6. Heartbeat구성과 IO Fencing

57. HeartBeat 구성 Split-brain 예방 HeartBeat2 (필수) HeartBeat1 (필수) Server Server HeartBeat3 (선택) Data SteelEye RHCS Heartbeat Line 복수 개 설정가능 (Service N/W, iSCSI망 구성 가능) 기본 Heartbeat Line  1개 HeartBeat N/W 장애 시 Service망을 사용 TTY(Serial cable) heartbeat 도 구성 가능 지원 안 함 Unicast 방식의 heartbeat Multicast 방식의 Heartbeat Service N/W HeartBeat N/W iSCSI N/W Serial Cable • 별도의 N/W 대역에 복수개의 HeartBeat구성을 권장 • Service N/W에 HeartBeat 이중화 구성 권고  Service가 정상적인 상황에서의 Split-brain 상황 방지 • 물리적으로 Serial Cabling이 가능한경우 TTY HeartBeat 추가 구성 권장  HeartBeat process 이중화 이득 • iSCSI Storage 사용시 HeartBeat 추가 구성 권장  Disk Heartbeat과 동일 효과 HeartBeat4 (선택)

58. I/O Fencing I/O Fencing  I/O Fencing 필요성  SCSI PR3 (기본 제공) SCSI Conflict를 인지한 Active Node를 Reboot으로 I/O Fencing  Quorum Witness Server (옵션)  STONITH (옵션) 제 3의 Witness Server에서 Active status 확인을 통해 불필요한 Fail-over 방지 SCSI Conflict를 인지한 Active Node의 전원 Off 수행  SCSI Conflict 감지로 인한 reboot수행을 위한 추가 방안 Shared Storage 환경에서 필요

59. I/O Fencing Fencing Chart Configuration SCSI Split-brain Hung Server Reservation (Default) Quorum Witness Server Watchdog STONITH ● ● ● ● ● ● ● ● ● ● Most Reliable Least Reliable

60. SteelEye for DR Conclusion SteelEye Protection Suite 10년이상 검증된 Architecture의 Consistency  x86(Linux, Windows), 가상화, Cloud 환경에 최적화  Open Source를 포함한 다양한 Linux배포 버전을 지원  다양한 Resource들을 Script작성 기반이 아닌 지능화된 Application감시 모듈  HA Fail-over, Data Replication, DR을 하나의 솔류션으로 구축 storage-based DR/Replication보다 유연하고 저가의 구축 가능  다양한 환경 구성(1:1, N:1, DR, cross standby, Shared Storage/Shared Nothing)  Block기반 복제로 빠른 성능 및 DB이외의 다양한 형태의 Replication 지원  설치, 구성, 운영 작업에 직관적인 Wizard 형태의 GUI 제공  Business 요구사항 변경에 따른 유연한 확장/변경 가능

SteelEye 표준 제안서

SteelEye 표준 제안서

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados(20)

Destaque

Destaque(10)

Similar a SteelEye 표준 제안서

Similar a SteelEye 표준 제안서(20)

Mais de Yong-uk Choe

Mais de Yong-uk Choe(7)

SteelEye 표준 제안서