슬라이드 1

Size: px

Start display at page:

Download "슬라이드 1"

칠 형
5 years ago
Views:

1 ucloud biz 사용자교육 I. ucloud biz 서비스의이해 3. 고가용성시스템구축 Cloud 기술팀

2 개요 서버는이중화 / 다중화구성한다 백업한다 일시적인트래픽폭주에는서버 scale-in/out 으로대처한다 서비스 IP 주소의변경을지양한다 Zone 또는지역단위의장애에대비, Multi-AZ 시스템을구성한다 ucloud biz 기반으로 legacy/cloud 시스템의 DR 시스템을구축한다 AZ : Availability Zone DR : Disaster Recovery

3 3-1 고가용성관점에서보는 ucloud biz 인프라 데이터센터의모든전력, 냉방시설은이중화 / 삼중화되어있다 모든네트워크장비와회선은이중화되어있다 스토리지컨트롤러는이중화되어있고, 디스크는 RAID 구성되어있다 다수의데이터센터와다수의 Availability Zone 를운영하고있다 Multi-AZ 시스템을구성할수있다 AZ 간 DR 시스템을구성할수있다 물리서버는클러스터구성되어있어, 특정물리서버의장애가발생해도 가상서버는다른물리서버에서재구동된다 (cloud HA, 다운타임 10~30 분 ) 가상서버를이중화하지않아도, 어느정도의가용성은확보할수있다

4 3-2 고가용성관점에서보는 ucloud biz 서비스 서버이중화를위해 L4 로드밸런서서비스를제공하고있다 이중화된 VM 을분산하여생성할수있는기능을제공하고있다 (multi-zone, cloud+legacy) DR 구성을위해 GSLB 서비스를제공하고있다 백업솔루션기반의백업서비스와스냅샷서비스를제공하고있다 스냅샷으로생성한서버이미지로서버복제가가능하며, auto-scaling 서비스를제공하고있다 공유스토리지기반클러스터구성을위한 i-scsi NAS 를제공하고있다 (MarketPlace 상품 ) 서버이중화를위한 MCCS 솔루션을제공하고있다

5 3-3 서버이중화 / 다중화구성 (1/3) LB 기반의이중화 / 다중화 8vcore 8G VM 2 대보다 (VM 1 개장애시처리용량 50% 감소 ) 4vcore 4G VM 4 대가유리하다 (VM 1 개장애 = 처리용량 25% 감소 ) DNS 를 LB 로활용할수도있지만, DNS 는서버의장애를인식하지못하기때문에장애가발생한서버에도계속트래픽을보내준다 GSLB 를 LB 로활용할수도있지만, 클라이언트가아닌상위 DNS 기준으로트래픽을분배하므로균등한분배가어렵고, 서버장애시에도 TTL 시간동안에는클라이언트의접속오류가발생할수있다

6 3-3 서버이중화 / 다중화구성 (2/3) 추천할만한오픈소스 SW 솔루션 HAproxy + keepalived 를활용하여 Active-Standby HA LB 를구현할수있다 (A-1) Rsync (linux), deltacopy (windows) 를활용하여두서버의데이터를비실시간 (eventually) 동기화시킬수있다 (A-2) DRBD 를활용하여두리눅스서버의데이터를실시간동기화시킬수있다 (A-3) OCFS2/GFS 를활용하여공유스토리지기반의 Active-Active 리눅스클러스터시스템을구현할수있다 (A-3) DRBD + heartbeat/corosync + Pacemaker 를활용하여리눅스서버를 Active- Standby HA 구성할수있다 (A-3) OCFS2/GFS + DRBD + heartbeat/corosync + Pacemaker 를활용하여이중화된스토리지기반의 Active-Active 리눅스클러스터시스템을구현할수있다 (A-3) Tomcat/JBOSS 등에는 session clustering 기능이있으며 (A-11), in-memory DB 인 Redis 를활용해서도 session manager 를구현할수있다

7 3-3 서버이중화 / 다중화구성 (3/3) 주요 RDBMS 이중화방식 DB node 1 DB node 2 DB-Master DB-Slave Replication / Mirroring Slave 가 read transaction 을분담할수도있음 Async 방식의데이터동기화는디스크간데이터동기화가불완전할수있으므로자동절체실패위험 Sync 방식의데이터동기화는약간의성능저하가있으며동기화실패시 Master 의장애유발도가능함 공유스토리지 공유스토리지기반의 Clustering 단일스토리지의장애및데이터유실가능성에대비해야함 서버만절체하므로자동절체구성이비교적용이함 Active-Active Active-Standby Replication / Mirroring MariaDB Galera Cluster (A-5) MySql NDB cluster (A-4) MySql Replication ( 자동절체 x, A-4) MS-SQL Mirroring (A-6) PPAS EDB Failover manager (A-8) 공유스토리지기반의 Clustering Oracle RAC (A-7) Tibero TAC MS-SQL cluster (A-6)

8 3-4 백업 백업솔루션기반의서버백업 NAS 볼륨스냅샷 VM 디스크스냅샷

9 3-5 서비스 IP 주소의변경을지양함 DNS 기반으로서비스하는것이바람직하나, IP 주소기반으로서비스해야하는경우에는서비스 IP 의변경을최대한지양해야한다 LB 서비스를활용하면계정이교체되어도서비스 IP 주소를유지할수있다. 동일한 zone, 동일한그룹계정에속한다른계정을연결하면된다 LB 서비스를활용하지않아도, 서비스 IP 주소를유지하면서 VM 을교체할수있다 Source NAT 의경우 : 기존 VM 의포트포워딩설정을새로운 VM 으로옮기면된다 Static NAT 의경우 : 기존 VM 에매핑된공인 IP 를새로운 VM 으로매핑하면된다 포트포워딩또는 Static NAT 설정은클라우드콘솔 ucloud server 네트워크화면에서할수있다 부득이서비스 IP 주소를변경하는경우에는 DNS 에서해당도메인의 TTL (Time to Live) 값을일시적으로감소시키는것이좋다 : 클라이언트가새로변경된 IP 로전환하는시간이단축된다 GSLB 를활용하면 DNS 에서서비스 IP 를변경하는것과동일한결과를얻을수있다 새로운 IP 를 GSLB 에추가로등록하고 기존의 IP 는삭제

3-6 Multi-AZ 구성 https://ucloudbiz.olleh.com/portal/ktcloudportal. epc.productintro.multizone.

10 3-6 Multi-AZ 구성 epc.productintro.multizone.html LB GSLB Front-end 서버는 GSLB 를활용하여 Active-Active 또는 Active-Standby 구성한다 각 zone 에 CIP 를, zone 간에는 inter-az 를구성하여 zone 간내부연동경로를구성한다 Inter-AZ 는 L3 스위치를경유하여연결된다 (zone 간 subnet 분리 ) VR VR Web 1 Web 2 Web 3 Zone-1 CIP Inter-AZ Zone-2 CIP DB-Master DB-Slave Zone 1 (as primary) MS-SQL Mirroring MySql Replication Zone 2 (for DR)

11 3-7 Legacy 시스템의 DR 시스템구축 클라우드기반의 DR 서비스를활용하면저렴한비용으로편리하게 DR 을운영할수있다 DR 의비용은데이터볼륨 ( 회선속도 ), 희망하는 RTO, RPO 수준에따라변한다 GSLB 서비스를이용하면 재해상황에서도클라이언트가서비스 IP 를변경하지않아도된다 ( 도메인기반서비스 ) 주시스템과 DR 시스템을 Active-Active ( 부하분산 ) 형태로도운영할수있다 스토리지기반 DR 서비스 대용량 SAN/NAS 데이터나고성능 DB 데이터등단위시간당데이터변경의볼륨이큰경우에는스토리지기반의데이터복제장비와고속전용회선구성이필요하다 이경우, 베어메탈서버의 DR 은베어메탈서버로구성해야하며, 가상서버의 DR 도양측의가상화솔루션이서로동일해야한다 서버기반 DR 서비스 단위시간당데이터변경의볼륨이크지않은경우에는서버에설치되는데이터복제 SW 기반으로도 DR 구성이가능하다 이경우, 가상서버로도베어메탈서버의 DR 을구성할수있다

12 첨부

13 A-1 로드밸런서 : HAproxy + keepalived HAproxy & keepalived HAproxy : TCP/HTTP 로드밸런서 Reverse proxy 형태로구성 : 서버로들어오는요청을대신받아서서버에전달하고요청한곳에그결과를다시전달 Keepalived 서버상태를체크하여 Virtual IP 를절체 HAproxy HAproxy 주요기능 로드밸런싱알고리즘 Roundrobin, static-rr, leastconn, first, source, uri, url_param, hdr, rdp-cookie X-Forwarded-For 기능 Reverse proxy 이기때문에서버로전달되는패킷헤더에서는클라이언트 IP 가 HAproxy IP 주소로대치됨 X-Forwarded-For 옵션을사용하면서버가클라이언트 IP 를인식할수있음 ACL (Access Control Lists) 기능 패킷내용에따라컨텐츠스위칭, 필터링등을수행할수있는기능 Sticky session 지원 특정 cookie 기반으로 stickiness 보장 SSL termination 지원 1.5.x 버전부터지원. HTTPS 패킷을복호화하여 HTTP 로전달 Web1 Web2 Web3 HAproxy 로웹서버로드밸런싱 ( 로드밸런서는이중화구성하지않음 ) HAproxy1 keepalived (VRRP) Virtual IP HAproxy2 Web1 Web2 Web3 2개의 HAproxy 로드밸런서를 keepalived 기반으로이중화

14 A-2 서버간비실시간데이터동기화 : Rsync / DeltaCopy Rsync or DeltaCopy File synchronization utility SW Data transfer 를최소화하면서파일과디렉토리를원격복제하는리눅스용오픈소스솔루션으로윈도우용은 delta copy 라는솔루션이있다. Rsync How it works How it works File 단위의복제방식으로동기화방식 수정시간및파일의크기변동을체크하여동기화할파일을결정한다. Advantages 라이선스비용없음 간단하고효율적인 copy 및 move 지원 Disadvantages 실시간동기화로는사용이어려움 ( 성능문제 ) 동기화파일수가많아지면동기화속도가많이느림 트랜잭션이나변경사항이많은서버에대해서는실시간동기화가거의불가능 log backup 등용도가제한적

A-3 리눅스서버간실시간데이터동기화 : DRBD DRBD Distributed Replication Block Device 디스크블록레벨의미러링복제 복제방식은 Asynchronous, memory synchronous, synchronous 선택가능 장점 (synchronous 방식 ) 디스크블록의실시간동기화 클러스터솔루션과결합하여 HA

15 A-3 리눅스서버간실시간데이터동기화 : DRBD DRBD Distributed Replication Block Device 디스크블록레벨의미러링복제 복제방식은 Asynchronous, memory synchronous, synchronous 선택가능 장점 (synchronous 방식 ) 디스크블록의실시간동기화 클러스터솔루션과결합하여 HA (auto-failover) 구성가능 (asnychronous 방식 ) DRBD proxy 솔루션과결합하여원격지간데이터동기화를안정적으로구현 DR 구성가능 주의할점 메모리버퍼 ( 예 : MySql innodb 엔진의 innodbbuffer-pool) 까지복제하지는않음 메모리버퍼가큰경우, Active 서버장애시데이터정합성이깨질수있다 Synchronous 방식에서다소간의성능저하발생 ( 데이터변화속도, 서버간네트워킹품질 ) 파일시스템이 DRBD 를통해데이터를 disk driver 전달하고 disk driver 가물리적인 disk 에기록한다. 이때 DRBD 는 TCP/IP 통신을통해서클러스터로구성된서버 2 의 DRBD 에알리고이를통해서데이터는 mirroring 된다.

A-3 리눅스 HA 구성 : DRBD + Enterprise Linux 의 HA 옵션에채택된 SW 조합 (SUSE HA extension, RHEL HA add-on) Active-Standby 구성 : DRBD + Heartbeat/Corosync + Pacemaker Active-Active 구성 : DRBD + Heartbeat/Corosync +

16 A-3 리눅스 HA 구성 : DRBD + Enterprise Linux 의 HA 옵션에채택된 SW 조합 (SUSE HA extension, RHEL HA add-on) Active-Standby 구성 : DRBD + Heartbeat/Corosync + Pacemaker Active-Active 구성 : DRBD + Heartbeat/Corosync + Pacemaker + OCFS2/GFS2 DRBD Heartbeat or Corosync Pacemaker OCFS2 or GFS2 서버간데이터동기화 Single-primary mode for Active-Standby Dual-primary mode for Active-Active 복제방식은 synchronous 로설정 클러스터자원감시자 이중화된서비스 / 자원의생사확인 상황의변화를 Pacemaker 에리포트 클러스터자원관리자 서비스 / 자원제어, 자동절체실행 비정상상황에서데이터오염이발생하지않도록대비필요 (fencing by STONITH) Active-Active 구성시, master-max=2 로설정 공유디스크파일시스템 Active-Active 이중화구성에필요 공유스토리지의동시성제어를수행 Active-Standby 구성에서는필요없음

17 A-3 리눅스클러스터구성 : OCFS2/GFS2 MySQL Active 1 MySQL Active 2 with 공유디스크파일시스템 클러스터 Oracle Cluster File System by Oracle Global File System by Redhat Active-Active 클러스터구성 공유스토리지의동시성제어를수행 비정상상황에서데이터오염이발생하지않도록대비필요 (fencing with STONITH) OCFS2/ GFS2 스토리지다중화 with DRBD 2 개디스크로전체적인 IOPS 향상효과 2 배성능은아님 : 데이터동기화오버헤드 DRBD 복제방식은 synchronous 로설정 MySQL Active 1 MySQL Active 2 DRBD OCFS2/ GFS2 DRBD OCFS2/ GFS2

18 A-4 MySql : Replication (1/3) 구성요소 1 Master & possibly multiple slaves 이중화원리 Replication 은 Slave Server 가 replication 을위한 Request 를보낸다. Master Server 는 Slave Server 의 Credential 을확인한후 transaction file 인 binlog 파일의 event 를 Slave Server 로보낸다. Slave 는위 event 를바탕으로 relaylog 를쓴다. Slave 의 thread 가 relaylog 를읽고실행한다. < 기본개념도 > Web Servers Advantages Scale-out for read, Geo-replication 가능 Slow 네트워크나네트워크순간단절에도동작 (Asynchronous 시 ) LB for read, HA for read Master(read/write) LB Disadvantages No Automatic Failover No Guarantee on data consistency(async) No scalability on write Master Master 로구성도가능하나실제로는 DB 정합성에문제가있어상용으로는사용안함 Replication slave(read) slave(read) slave(read) Applications Master(write), slave(read) Read transaction 의 scale out 을통한부하분산용으로가장많이쓰임 < 응용개념도 >

19 A-4 MySql : Replication (2/3) Replication 방식 Topologies Asynchronous : slave 의 acknowledge 없이 transaction 이 commit 되는것으로간주 (Default) 1) Semi-synchrous : 최소한하나의 slave 로부터 ACK 를확인해야 master 의 transaction commit 이완료됨. MySQL 5..5 부터제공 Synchronous : MySQL Cluster 버전에서만제공 아래와같이다양한 topologies 가적용가능하며한개의 topology 에두가지이상의방식을혼용해서사용하기도한다. Master-slave(1:1) Master-slave (1 : n) Master-slaves of slaves Master-Master Multi-master ring Slave(read) Slave(read) Master (read/write) Slave(read) Master (read/write) Master (read/write) Master (read/write) Slave(read) Slave(read) 관리용이, 기본구조 최소비용 Read load balancing Slave 중하나의 ack 이있어도 master 는동기화된것으로 client 에게보임 구성비교적용이 read load balancing Master 만 read/write 1 차 slave 는 2 차 slave 의 master 역할 설정및유지보수어려움 계층구조로동기화어려움 loosely coupled synch 구조 변경이나수정이많이없는페이지나정보구성에이용 read & write load balancing write 성능향상 데이터정합성 (Integrity) 깨지기쉬음 상용환경에서는잘쓰이지않음 read & write load balancing write 성능향상 데이터정합성 (Integrity) 깨지기쉬움 구성하기복잡함 복잡하고관리가어려움 이론적인구조

20 A-4 MySQL : Replication (3/3) Synchronous Asynchronous Semi-Synchronous 개념 master 가 slave 로부터 acknowledge 를받았을때 transaction 이 commit slave 의 acknowledge 없이 transaction 이 commit 되는것으로간주 (Default) slave 에는 asynchronous, client 에는 synchronous (delayed -acknowledgment commits) 장점 Master 와 slave 간에데이터동기화가가장잘보장됨 Transaction 완료시간이빠름 (slave 의 commit 여부와상관없음 ) 여러 slave 중하나만동기화되어도해당 slave 는 read load 분산을위해 client 에 available 하다 비교적빠른 transaction 완료시간 ( 세방식중중간 ) DB client 들에게 master slave 간데이터동기화보장 여러 slave 중하나만동기화되어도해당 slave 는 read load 분산을위해 client 에 available 하다 단점 MySQL Cluster 버전에서만제공 Transaction 완료시간이세가지방식중가장느림 ( 성능 ) 평상시데이터동기화지연현상발생가능 장애시 Master 와 slave 간의데이터불일치가능성이세가지방식중가장큼 장기간운영시 master slave 간데이터불일치발생 Transaction 완료시간은 asynchronous 방식보다느림 Master 장애시데이터동기화는 synchronous 방식보다는잘보장되지않음

A-4 MySQL : NDB Clustering 구성요소 이중화원리 Advantages Disadvantages Applications MySQL 과통신 MySQL servers SQL commands 처리및 NDB 와통신 NDB cluster Query 처리와결과를 MySQL 에 return Application, MySQL, NDB 가독립적으로

21 A-4 MySQL : NDB Clustering 구성요소 이중화원리 Advantages Disadvantages Applications MySQL 과통신 MySQL servers SQL commands 처리및 NDB 와통신 NDB cluster Query 처리와결과를 MySQL 에 return Application, MySQL, NDB 가독립적으로 scale out 가능한구조 Data 가 peer Data Nodes Cluster 안에서 Synchronous 하게복제된다. 각각의데이터노드는다른데이터노드들과모두연결되어있고데이터는여러개의데이터노드에저장된다. No Single Point of Failure 운영중테이블변경, 데이터노드추가가능 HA, High Performance(Active-Active) Automatic failover NDB 의성능이느려서상용으로는잘쓰이지않음 ( 데이터분산저장으로인한 Join query 등이느림 ) 고가의라이선스비용으로상용으로사용하는예는거의없음

A-4 MySQL : geo-replication 구성방법 MySQL Cluster-replication 구성 데이터센터내에 MySQL cluster 구성 데이터센터간 replication 구성 Replication 구성 데이터센터간 replication 으로만구성

Cluster 간동기화는 MySQL 에서제공하는 collision detection 및 resolution 기능이용 사용자에게보다가깝게데이터를위치시켜 latency 영향을최소화 Disaster recovery 구성으로안정성강화 Master Slave 천안 Cluster 데이터센터간

22 A-4 MySQL : geo-replication 구성방법 MySQL Cluster-replication 구성 데이터센터내에 MySQL cluster 구성 데이터센터간 replication 구성 Replication 구성 데이터센터간 replication 으로만구성 기타여러가지구성조합이가능 천안 이중화원리 Advantages 같은데이터센터내에서는 synchronous 구성을통한 Cluster 를구성한다 데이터센터간에는 asynchronous replication 을통한데이터동기화를통해 DR 구성이가능하다. Cluster 간동기화는 MySQL 에서제공하는 collision detection 및 resolution 기능이용 사용자에게보다가깝게데이터를위치시켜 latency 영향을최소화 Disaster recovery 구성으로안정성강화 Master Slave 천안 Cluster 데이터센터간 Replication(Asynch) 김해 Disadvantages 데이터센터간 network latency 가 bottleneck Master 노드장애시 asynchronous replication 에따른데이터동기화 (consistency) 문제발생 Cluster NDB 의성능문제, 고가의라이선스비용 Master 김해 Cluster Slave

A-4 MySQL : Case study 1 사례설명 ucloud 고객인게임전문회사 A 사가 replication 과 sharding 을이용하여시스템을확장한사례 응용기술 scale-out(was) memcache replication sharding LB 이중화

23 A-4 MySQL : Case study 1 사례설명 ucloud 고객인게임전문회사 A 사가 replication 과 sharding 을이용하여시스템을확장한사례 응용기술 scale-out(was) memcache replication sharding LB 이중화 WAS 의 scaling out 을통한 LB DB 에대한 read cache 역할로 DB 쿼리에대한성능향상 모든 DB 서버를 1 Master, 2 Slave 로구성하여 read transaction 을부하분산 Account DB 의테이블을수평적으로분할하여부하를분산

A-4 MySQL : Case study 2 사례설명 ucloud 고객인 D 그룹 replication, DRBD 와 keepalived 를이용한시스템구축사례 DB1 master active DB2 master standby DB3 replication slave MySQL replication DRBD DB1을 Master DB3를 slave 로

24 A-4 MySQL : Case study 2 사례설명 ucloud 고객인 D 그룹 replication, DRBD 와 keepalived 를이용한시스템구축사례 DB1 master active DB2 master standby DB3 replication slave MySQL replication DRBD DB1을 Master DB3를 slave 로 replication 구성 No auto-failover DB3로수평적확장및 read load 분산 Block device 단위복제를위해 DRBD 를사용하여 DB1의데이터를 DB2와동기화하였다. Keepalived keepalived 간에는 heartbeat 를서로송수신하여문제발생시 failover 기능지원 Keepalived1 은 DB1 과 DB2 간의 active-standby auto-failover Keepalived2 은 DB1 과 DB3 간의 LB 를통한 read load 분산

25 A-4 MySQL : Cluster vs Replication Cluster Replication 개념 Transaction-safe Real time 복제 Active-Active 구조 App, MySQL, NDB가독립적인 Scale-out Master Slave 구조 Active-standby Active-Active(write-read) 장점 Clustering 으로 DB 서버 HA 보장 Scale-out True DB redundancy 데이터이중화 Scale-out for read 단점 고가의라이선스비용 네트워크기반의동기화및복제에따른성능저하로상용환경에서는많이쓰이지않음 No automatic failover Data consistency Not guaranteed (Asynchronous) 용도 LB, HA, 가필요한 application Read-intensive 한 application

A-5 MariaDB : Galera Cluster 구성요소 이중화원리 Advantages Disadvantages DB MySQL or Maria DB 사용 wsrep wsrep API 로노드간통신 Galera Replication Synchronous 방식의 Replication 을제공 동기방식의데이터복제 Active-Active 방식의다중마스터구성

26 A-5 MariaDB : Galera Cluster 구성요소 이중화원리 Advantages Disadvantages DB MySQL or Maria DB 사용 wsrep wsrep API 로노드간통신 Galera Replication Synchronous 방식의 Replication 을제공 동기방식의데이터복제 Active-Active 방식의다중마스터구성 클러스터내노드자동컨트롤 특정노드장애시자동으로해당노드제거 자동으로신규노드추가가능 행단위로완벽한병렬적리플리케이션 기존의 MySQL 클라이언트방식으로동작 마스터 / 슬레이브간데이터동기화지연없음 트랜잭션유실이없음 읽기 / 쓰기모두확장이가능 클라이언트에대기시간이길지않음 최소 3 개노드로구성해야함 노드추가시마다데이터복제로부하발생 서버간그룹커뮤니케이션부하발생 모든노드에동일한데이터를유지로공간낭비

27 A-6 MS-SQL : Clustering (MSCS or WSFC) 개념 이중화원리 SQL 서버단위의 clustering 공유스토리지보유 Active-Standby 구성모두가능 Cluster 로구성된서버들간에 heartbeat 을체크하여 Active-Standby 구조라면 Standby 서버로 automatic failover 된다. Advantages Clustering 으로 DB 서버 HA 보장 Disadvantages 공유스토리지는 scale-out 할수없음 DB 서버만 HA, LB 됨 AD 서버가있어야함 보완 공유스토리지는별도로이중화등을구성할수있다. ucloud 환경에서공유스토리지는 ucloud NAS 로구성가능함

Synchronous for consistency Asynchronous for performance Advantages Synchronization replication 의경우 automatic failover

28 A-6 MS-SQL : Mirroring 개념 Principle server 만서비스, Mirror server 는 principle server 장애시 failover(automatic/manual) DB 의 HA 를확장하는개념 ( 스토리지포함 ) 이중화원리 Principle server 가 Log record 를 mirror 서버로보내서복제를하며 synch 방식과 asynch 방식이있다. Synchronous for consistency Asynchronous for performance Advantages Synchronization replication 의경우 automatic failover 가능 (auto-failover 위해 Witness 서버필요 ) DB 와스토리지 HA ( 공유스토리지가아니라복제스토리지사용 ) Disadvantages No LB for DB 서버 평상시 Principle 만가용하고장애시는 mirror 만가용함

A-6 MS-SQL : Replication 개념 Publisher 가 transaction 에대해생산한로그를 Distributor 가해석하고이를바탕으로 subscriber(s) 들에게제공하여 Publisher 와 subscriber(s) 사이에 consistency 유지 이중화원리 Transactional: 최초 snapshot 동기화후

29 A-6 MS-SQL : Replication 개념 Publisher 가 transaction 에대해생산한로그를 Distributor 가해석하고이를바탕으로 subscriber(s) 들에게제공하여 Publisher 와 subscriber(s) 사이에 consistency 유지 이중화원리 Transactional: 최초 snapshot 동기화후 transaction 에의한동기화 Merge: 최초 snapshot 동기화그후 Distributor 가 Publisher 와 Subscriber(s) 의 Update 을동기화 Snapshot: 주기적으로 Publisher 에서 Subscriber(s) 로 snapshot 보내서동기화 Advantages Subscriber(s) 를 read-only 로구성하여 LB 가능 Subscriber(s) 가 write, read LB 가능 (Only Merge replication) Disadvantages No Automatic Failover No Guarantee on data consistency(async) No scalability on write

30 A-6 MS-SQL : AlwaysOn AlwaysOn MS-SQL 2012 부터제공되기시작한 HA 및 DR 솔루션 Enterprise edition only AG + FCI 조합으로구성가능 AG Availability Group 기존 mirroring 의발전된형태 1 primary + 최대 4 secondary 지원 Auto-failover 에 Witness server 불필요 Availability mode : 동기, 비동기 - 동기모드의 secondary 는 auto-failover 가능 - 원격지의 secondary 는비동기구성권장 Active secondary : read workload 를분산하거나, 백업서버의용도로사용가능 ( 기존 mirroring 기능에서는불가 ) FCI as primary Async secondary Backup IDC FCI Failover Cluster Instance 기존 clustering 의발전된형태 Multi-site clustering : IP 주소영역이다른서버간의 clustering 구성도가능 구성예 : Primary IDC 주전산센터에 failover cluster 로 HA 구성, 백업센터는비동기 replica 구성. 전체가하나의 Availability group

31 A-6 MS-SQL Clustering, Replication & Mirroring Clustering Mirroring Replication 개념 DB server HA 제공 공유스토리지보유 Active-Passive 구성 하나의데이터베이스에대한 2 개의복사본을서로다른 SQL server 에보관하는것 Principle server 만서비스, Mirror server 는 principle server 장애시 failover(automatic/manual) 같은데이터베이스에대한복사본을여러개의다른서버에보관하는것 Publisher-Subscriber(s) Active-Standby 구조 Principle-Mirror Synchronous/Asynchronous LB for read subscriber(s) 장점 DB 서버레벨의 Clustering Clustering 으로 DB 서버 HA 보장 HA for DB server (Automatic Failover) LB for subscriber(s) read & write(merge replication) Replication 을 DB, table 등의단위로선택가능 단점 공유스토리지는별도로이중화구축 DB 서버만 HA, LB 됨 공유스토리지는 scale-out 할수없음 Mirror DB 정상동작시접근불가 No LB No automatic failover 용도 DB Server 의가용성이중요하나스토리지성능의 scale-out 이필요없는곳 DB 가용성향상이필요하나 DB 및스토리지의 scale-out 은필요없는곳 Read 성능 scale-out

A-7 Oracle : RAC(Real Application Clusters) 개념구성요소이중화원리장점 Cluster 구성의 shared-nothing, shared disk 의한계를 shared cache 아키텍쳐로극복하여 DB 의 scalability 와 HA 를동시에보장한다 Oracle instances: 각호스트에 DB 인스턴스 Oracel

32 A-7 Oracle : RAC(Real Application Clusters) 개념구성요소이중화원리장점 Cluster 구성의 shared-nothing, shared disk 의한계를 shared cache 아키텍쳐로극복하여 DB 의 scalability 와 HA 를동시에보장한다 Oracle instances: 각호스트에 DB 인스턴스 Oracel clusterware: cluster 구성이필요한기능들을제공하고관리하며 oracle DB 와독립적으로설치될수도있다. 호스트별로 DB 인스턴스를생성하고 Clusterware 를이용하여각호스트들을관리하고메모리를공유하는구조를가짐으로써 DB 의 HA 와 LB 를동시에가능하게한다. LB for DB server (throughput 향상 ) Clustering 으로 DB 서버 HA 보장 RAC 기본구성도 SAN 스위치 1 SAN 스위치 2 유의사항 클라우드에대한라이선스정책이슈로과다비용발생 대부분의가상화환경을 certi. 하지않음 공유스토리지는 scale-out 불가하며, Single Point of Failure 로작용할수있음 Shared nothing : 분산컴퓨팅아키텍쳐에서여기서는이중화 DB 아키텍쳐에서노드간에메모리를공유하지않고독자적인메모리를가지는것 Shared disc: : 디스크즉스토리지를공유하는것 [ 으로스토리지가기존 MS-SQL clustering 은스토리지가 single point of failure 가된다. DB 서버 2 RAC 스위치 1 RAC 스위치 2 스토리지 W 사사례 CI 서버 AP 서버 1-6

33 A-7 Cluster 기술비교 MySQL MS-SQL Oracle RAC 개념 Transaction-safe Real time 복제 Active-Active 구조 App, MySQL, NDB 가독립적인 Scale-out 하나의데이터베이스에대한 2 개의 복사본을서로다른 SQL server 에보관하는것 Shared Nothing 구조 Cluster 구성의 shared-nothing, shared disk 의한계를 shared cache 아키텍쳐로극복하여 DB 의 scalability 와 HA 를동시에보장한다 Shared Everything 구조로메모리공유 Shared nothing 구조 ( 메모리공유안함 ) 장점 No Single Point of Failure Clustering 으로 DB 서버 HA 보장 운영중테이블변경, 데이터노드추가가능 LB for DB server cluster(throughput 향상 ) Clustering 으로 DB 서버 HA 보장 Clustering 으로 DB 서버 HA 보장 LB for DB server cluster(throughput 향상 ) 단점 네트워크기반의 NDB 동기화및복제에따른성능저하로상용환경에서는많이쓰이지않음 공유스토리지에대해 scale-out 불가 공유스토리지가 Single Point of Failure : 별도로이중화필요 공유스토리지에대해 scale-out 불가 공유스토리지가 Single Point of Failure : 별도로이중화필요 고가의라이선스비용 용도 소용량의데이터로간단한쿼리를실행하는 App. 웹사이트세션저장, 파일스토리지메타데이터저장등 기업용 DB 로상용으로많은 reference 가있다. 스토리지는 SAN 이나스토리지컨트롤러이중화, RAID 구성등으로보완할수있다. 다소고가이기는하지만안정적인 DB 환경을원하는기업고객들이많이사용하고있다.

34 A-8 PPAS EDB Failover manager PPAS EDB Failover manager 다른방법 Postgres Plus Advanced Server PostgreSQL 의 Enterprise Edition. Oracle DB 와의호환성이매우뛰어남 EnterpriseDB 에서제공 PPAS 에기본제공되는 HA 솔루션 Primary + 1 replica. 로구성 Streaming replication 기반. Sync/Async 복제 Client 는 Virtual IP 또는 LB 를통해 DB 서버와연동 Witness node : split brain 을방지하는역할. Replica 가 primary 의장애를인지하더라도, witness 의승인을얻어야 auto-failover 가실행됨 Active-Standby 클러스터 공유스토리지 + Pacemaker + heartbeat 기반으로 Active-Standby 클러스터를구성할수있음 이경우, 데이터의보전을위해 log shipping 에기반한 redundant DB 서버를구성할수도있음 xdb replication multi-master PPAS 에기본제공됨 Multi-master replication 기능을제공하지만, 그자체로는 auto-failover 미지원. edb-failover-manager

35 A-9 NoSQL Cassandra 의이중화 Cassandra Big data 의분산처리를위한데이터베이스로유연한스키마구성 (row 마다속성을다르게구성가능 ) 이하고 key-value 구조로빠른성능을보임 Clients 1 이중화원리 Redundancy 구성은다음과같이이뤄진다 1. clients 가 write opeation 을 cassandra 의어느노드에한다. 2. Cordinator 노드가데이터를노드들과다른존에복제한다. 3. 노드들이 ack 을 Coordinator 들에 return 한다. 4. Coordinator 가 ack 을노드들에 return 한다. 5. 데이터가 internal commit log 디스크에기록된다. Zone C ) Zone A Zone A Advantages Fault-tolerant with replication No single point of failure Read/write scalability ( 여러노드가장애시에도남아있는노드에서서비스가능 ) Zone C 3 Zone B 5 Disadvantages Join opertion 지원안됨 새노드추가시데이터재분배시간소요 메모리보다큰 object 들은저장이어려움 Zone B 1) 그림에서 zone 은 data center 단위라고바꿔서생각해도됨

36 A-10 In-memory DB Redis 의이중화 Replication Master-Slave 형태의계층형 replication 을지원 (Master-Master 불가능 ) 성능향상을위해 Async 방식을사용 Master 에는 read/write 설정이가능하며, Slave 에는 read 설정만가능함 Replication 구성 Master Sentinel Redis 의 Failover Solution Master 노드장애발생시 Slave 노드중하나를 Master 로동작하게함 Master-Slave 로구성하며, Sentinel 모드를작동 (Redisserver 에 sentinel 옵션을사용하여별도의 sentinel 프로세스를실행시킴 ) 시켜 Redis instance 의상태를모니터링 Sentinel 이 Master 가다운됐다고판단할때 Sdown(Subjectively Down) 과 Odown(Objectively Down) 를이용하며 Odown 이감지되었을때 fail-over 를수행함 1st Slave 1 st Slave 2nd Slave 2nd Slave Replication 동작원리 (Async 방식 ) 1 Request Sentinel 동작원리 Client Master Master Slave Master Slave Master New Master 2 Response 4 Apply Repl 3 Binlog Copy Sentinel Sentinel Sentinel Slave Master 정보입력시자동으로 Slave 감지 Master 장애발생시 (ping 체크 ) Slave 를 Master 로변경

A-11 Tomcat Session Clustering (1/2) 개요 Session Clustering 구성으로웹서비스의확장성과고가용성 (HA) 제공 Loadbalancer 가 Cluster 내어플리케이션서버의앞단에위치하여웹트래픽을적당한클러스터멤버로 redirecting 과동시에부하를분배 AJP 구성요소 구성시유의사항 Apache ~ Tomcat 연동

37 A-11 Tomcat Session Clustering (1/2) 개요 Session Clustering 구성으로웹서비스의확장성과고가용성 (HA) 제공 Loadbalancer 가 Cluster 내어플리케이션서버의앞단에위치하여웹트래픽을적당한클러스터멤버로 redirecting 과동시에부하를분배 AJP 구성요소 구성시유의사항 Apache ~ Tomcat 연동 mod_jk, mod_proxy_http 와같은 Apache Module 을이용하여 JSP 또는 servlet 요청을 AJP 프로토콜을통해 Tomcat 으로전달 Cluster 구성 Cluster 내의 Tomcat Instance 간통신을위해 IP 멀티캐스트통신을사용 (Tomcat 의 server.xml 에서 Membership 요소 (mcastaddr, mcastport 등 ) 를 Tomcat Instances 에서동일하게설정 ) Tomcat Instances 의버전을동일하게구성 Apache, Tomcat 버전에따른적합한 module 선택웹어플리케이션의 web.xml 파일에 distributable 를정의 각 Tomcat instance 에서동일한웹어플리케이션구동시 Session State 복제를하기위함 jvmroute 설정 Apache 에서의 worker name 을 Tomcat 에서동일하게설정하여 session 전송을가능하게함 Apache Mod_proxy or mod_jk With load balancing Increasing load from incoming requests Tomcat1 AJP Tomcat2 AJP Tomcat3 Multicast Communication Multicast Communication

38 A-11 Tomcat Session Clustering (2/2) Session 공유방식 In-memory session replication Tomcat 내부의 SimpleTcpCluster 를이용하여 Cluster 내 Instance 간 Session Data 를 TCP 를통한복제수행 DeltaManager: 모든 cluster member 에게 session 복제를수행, cluster 가커지면비효율적임 BackupManager: session data 를오직하나의 backup instance 에만복제 ( 충분한검증안됨 ) 공유된파일시스템에세션상태를저장공유된 DB 에세션상태를저장 Session 공유방법 Session State 유지를위해 SessionID 를이용 Apache 로부터의 request 를 SessionID 값과일치하는 worker 에매칭시켜전달 각 instance 간 SessionID 가일치할경우 session replication 진행 Session 정보가있는 cookie 를지원하지않는환경일경우 URL Rewrite 기법 : SessionID 를 cookie 에심어보내지않고 URL 에 SessionID 를심어보냄 SSL ID 이용방법 : https 를이용하여연결시, SSL ID 가생성되고이값을 SessionID 로사용 초기구성 Session Tomcat A, Crash 발생 Tomcat A, Crash 발생 Tomcat A, 복구 Apache Apache Apache Apache Invalidated call Tomcat A Tomcat B Tomcat A Tomcat B Tomcat A Tomcat B Tomcat A Tomcat B Session Replication Crash Session Replication Crash Membership 정보차단 복구시 재구성

Cloud Friendly System Architecture

Cloud Friendly System Architecture -Service Clients Administrator 1. -Service 구성도 : ( 좌측참고 ) LB(LoadBlancer) 2. -Service 개요 ucloud Virtual Router F/W Monitoring 개념 특징 적용가능분야 Server, WAS, DB 로구성되어 web service 를클라우드환경에서제공하기위한 service architecture