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
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. 제안 배경
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 간의 자유로운 이중화 구성 지원
다양한
구성
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모두 가능
즉, PP, PV, VP, VV 모두 가능
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
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 요구사항 변경에 따른 유연한 확장/변경 가능
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
(중단후)
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구축 용으로 가
장 안정적인 복제 방식
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버전만 지원
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
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 요구사항 변경에 따른 유연한 확장/변경 가능
