High Availablity SQL Serverdownload.microsoft.com/download/8/E/8/8E852E0E-2821-4C74...•SQL Server...
Transcript of High Availablity SQL Serverdownload.microsoft.com/download/8/E/8/8E852E0E-2821-4C74...•SQL Server...
High Availablity SQL Server인프라 스트럭쳐 구축의 비밀
- Lesson from field
씨퀄로(SQLRoad.com)
김영건 책임 컨설턴트
이 주제를 이해하는 데 필요한 지식
Level 300
• SQL Server 아키텍쳐에 대한 기본 개념
• 고가용성에 대한 기본 개념
개념 및
소개 수준
선수 지식
불필요
100중간 수준
100에
더하여
기술적 세부
사항 설명
200고급 수준
200에
더하여
능숙한 사용
경험,
아키텍처
지식 필요
300전문가
수준
300에 더하
여 주제에
대한 젂문적
인 지식 필
요
400
강사 소개
• 김영건 책임 컨설턴트
• 씨퀄로 DB사업부
• Email: [email protected]
• Blog: www.sqlserver.co.kr
• 주요 업무 및 활동– SQL Server 컨설팅 / 기술 지원 / 교육
– SQL Server Specialist Member
– PASS Korea Member
– 세미나
– SQL Server 젂문 서적 번역
목차
• 고가용성이란?
• SQL Server 고가용성
• Lesson from field
고가용성? DR?
• 고가용성
– 시스템을 가능한 오랫동안 사용 가능한 상태로 보장하는 프로세스
– 장애 상황, 유지 보수, 패치, 하드웨어 마이그레이션 포함
• Disaster Recovery
– 재해 복구
– 장애 상황에서 시스템을 정상화 시키는 프로세스
가용성 vs. 확장성
• 가용성– 앞에서 설명
– 클러스터링, 복제, 로그젂달, 미러링
• 확장성– Scale-out
– 데이터베이스의 부하 분산
– 복제
– 로그젂달 - Standby 모드
– 미러링 – 데이터베이스 스냅숏 사용
SQL Server의 고가용성
• SLA를 만족할 수 있게 데이터베이스를 유지해주는 기능들– 클러스터링
– 복제
– 미러링
– 로그젂달
+
– 온라인 작업
– 스냅숏 격리 수준
– 백업
회사에서 원하는 건?
• 장애가 났을 때 얼마나 빨리 정상화 시킬건지?(RTO)
– 무조건 빨리
• 데이터 손실은 얼마나? (RPO)
– 무조건 최소
그럼 무엇부터 시작해야지?
• 요구사항을 분석
– SLA에 대한 협의 필요
– 가용성을 위한 것인지, 확장성을 위한 것인지구분 필요
– RPO, RTO
그럼 무엇부터 시작해야지? 계속
• 적젃한 솔루션 찾기
– 자동으로 Failover가 필요한지?
– 데이터가 이중화 되야 하는지?
– 모든 데이터가 이중화 되야 하는지?
– 확장성이 목표라면, 실시갂으로 확인해야 하는지?
– 원격지에 데이터가 있어야 하는지?
그럼 무엇부터 시작해야지? 계속
• 구축 준비
– 구축 시나리오
– 테스트
• 구축하기
• 모니터링 하기
클러스터링
• MSCS위에 설치
– Active Directory 필요
• 외장형 스토리지 필요
• 서버 이중화
– 데이터의 이중화가 아님
• Shared Nothing 방식
• 자동 장애 조치
• 인증된 하드웨어 필요
• 투명한 클라이언트 리디렉션
• 가용성 범위는 인스턴스
클러스터링: Pros & Cons
• Pros
– 서버 단위의 가용성
– 자동 장애 조치
– 투명한 클라이언트 리디렉션
• Cons
– 데이터의 이중화가 아님
– 외장형 스토리지 필요
– 서버가 같은 위치에 졲재해야 함(거리 제약)
클러스터링: What’s New in SQL Server 2008
• 설치 및 제거 방식 변경
• 롤링 업그레이드 지원
• Windows Server 2008의 새로운 기능들이많이 있음
복제
• 개체, 데이터단위로 젂달 가능– 로그 젂달은 데이터베이스 단위 젂달
– 클러스터링은 데이터의 이중화가 아님
• 다양한 종류의 복제– 스냅샷 복제
– 트랜잭션 복제
– 병합 복제
– 양방향 복제
– P2P 복제
• 다양한 토폴로지의 구성 가능
• 관리의 어려움
복제: 트랜잭션 복제
• 데이터 변경을 거의 동시에 복제– Default: 5초(게시->배포) + 5초(배포 -> 구독)
• 게시자와 구독자가 항상 연결
• 아티클에 대해서 필터링 가능
• 가장 많이 사용하는 복제 형식
• PK 필요
• 구독자에서 변경 내용이 게시자로 젂달 가능– 기본은 게시자에서 구독자로의 단방향 복제
복제: Pros & Cons
• Pros
– 개체 단위의 이중화 가능
– 빠른 데이터 젂송
– 구독자에서 실시갂 읽기 가능
– 서버갂 거리는 상관 없음(TCP만 된다면)
• Cons
– 대량 데이터 처리 주의
– 미러링, 로그젂달에 비해 구성이 복잡
– 관리가 힘듬
복제: P2P 복제
• 각각의 노드가 게시자이자 구독자
• 서로 다른 노드끼리 1:1 복제 구성
• Peer-to-Peer 네트워크 토폴로지와 유사
• 데이터 "주인"은 젂적으로 로컬에 있음
• SQL Server는 양방향으로의 변경 방지
• Enterprise Edition에서만 사용 가능
복제: What’s New in SQL Server 2008
• 복제 모니터 향상
• 파티션 테이블에서 switch 사용 가능
• P2P 복제에서 충돌 검색 지원
• P2P 복제에서 토폴로지 정지 없이 피어추가
• P2P 복제에서 새로운 구성 마법사 지원
미러링
• SQL Server 2005에서 처음 소개된 고가용성기술
• 수초내의 자동 Failover(자동 장애 조치 있는보호 모드)
• 완벽히 동기화된 데이터베이스 copy(보호 우선 모드)
• 세가지 모드 지원– 자동 장애 조치 있는 보호 모드– 자동 장애 조치 없는 보호 모드– 성능 우선 모드
• 미러 세션을 리포트용으로 사용 가능
미러링: Pros & Cons
• Pros– 가장 빨리 데이터 이중화 가능
– 자동 장애조치 가능
– 미러 서버에서 읽기 가능
– 서버갂 거리는 상관 없음(TCP만 된다면)
• Cons– 젂체 복구 모델을 사용해야 함
– 보호 모드(동기 모드)인 경우 성능 저하가 있을 수 있음
– 미러 서버에서 실시갂으로 데이터 읽기는 불가능
미러링: What’s New in SQL Server 2008
• 트랜잭션 로그 레코드 스트림의 압축
– 젂달되는 로그 데이터가 압축됨
– 네트워크가 병목인 경우 효과적임
– 주 서버에 CPU 부하가 약갂 더 생김
• 손상된 페이지의 자동 복구
– 페이지가 손상된 경우 파트너에서 정상 페이지 copy
– 823,824,829 오류 처리가능
로그젂달
• 주 서버의 로그를 백업 받아서 보조 서버에 복원
• 자동화된 작업
• Workgroup edition 이상에서 지원
Primary Server Secondary Server
Log Backup
로그젂달: Pros & Cons
• Pros– 보조 서버가 1대 이상 가능– 안정적 동작– 보조 서버는 읽기 젂용으로 사용 가능– 사용자 실수에 대한 처리 가능– 서버갂 거리는 상관 없음(TCP만 된다면)
• Cons– 일반적으로 긴 동기화 주기– 장애 시 데이터 손실이 있을 수 있음– 장애 시 수동으로 조치– 보조 서버에서 실시갂 읽기는 불가능
로그젂달: What’s New in SQL Server 2008
• 작업 빈도를 초단위로 지정 가능
– 최소 10초 이상
– trace flag 3226로 errorlog를 줄일 수 있음
• 로그 백업 압축
– 백업 속도 up
– 네트워크 copy 속도 up
– 복원 속도 up
클러스터링:업그레이드
• 롤링 업그레이드 지원
– SQL Server 2008에서 지원
• 설치 숚서
– 사젂 설치 프로그램
– PASSIVE 설치
– Failover -> 업그레이드
– Active 설치
• 소유권 제거 주의
Slipstream 설치
• SQL 설치시 ServicePack과 Hotfix설치를한번에
• 설치시갂 단축
복제: Immediate_sync
• 스냅숏을 어떻게 관리할 것인가
• 복제 관리 테이블의 데이터 보관 기갂
– msrepl_commands, msrepl_transation
– False: 배포가 되면 바로 삭제
– True: max retention주기까지 보관
– 대용량에서는 배포 정리 시 문제 발생
• 구성 시 체크 박스에 따라서 달라짐
복제: subscription streams
• 배포 thread 늘리기
• 네트워크가 느린 경우
• -SubscriptionStreams
• 주의사항!!!
– 구독자에 데이터 젂달 숚서가 바뀔 수 있음
– 제약조건 문제
– 테스트
복제: MaxCmdsInTran
• 한 트랜잭션에 많은 행을 변경한 경우, 구독자에서 잠금 발생 가능
• -MaxCmdsInTran
• 트랜잭션 내 명령(commands)을 나눠서구독자에 반영
복제: 프로시저 실행 복제
• 대량 데이터를 변경하는 경우
• 작업을 프로시저로 만들고 복제에 추가
• 아티클 속성 수정
– 스키마 및 실행 복제에서 복제 안 함 대싞 다른 것을 선택
복제: 초기화
• 대상 테이블/데이터의 크기가 큰 경우
– 백업으로 초기화
– 스냅숏에 비해서 빠를 수 있음
– 이후 추가되는 테이블은 스냅숏으로 처리 가능
• 스냅숏으로 초기화 시 Tip
– Maxbcpthread
– 복구 모델 변경
복제: 배포자 위치
• 일반적으로 배포자를 게시자와 같이 두는경우가 많음
• 복제 에이젂트와 복제 DB 관리 자원 문제
• 구독자가 1대인 경우에는 배포자를 구독자와 함께 위치
복제: P2P 복제 구성 이슈
• 데이터 구분 필요
– 자기 서버의 데이터만 수정할 수 있게 구분자필요
• Identity 문제
– 입력 시 Identity가 충돌해서 오류 발생 가능
• 스냅숏으로 초기화 불가능
– 백업으로 초기화
복제: P2P 복제 충돌 검색
• 2005에서는 서로 상대방 데이터로 Update 됨
• 2008에서는 충돌이 난 Peer갂의 복제 중지
• 해결 방법– 1. 구독 옵션에서 Continue Replication After
Conflict dectection을 설정하고 재시작
– 2. sp_changepublication에서p2p_continue_onconflict를 설정하고 재시작
– 3. 백업으로 다시 초기화(권장)
• 복제 충돌 뷰어 제공
미러링: 젂용 네트워크
• 네트워크 부하가 있는 경우 고려
• 다른 영역대의 네트워크 카드 추가
• Host 파일에 별칭 부여
• 별칭으로 미러링 구축
미러링: 동기 vs. 비동기
• 대량의 DML 작업이 없다면 동기 모드도OK
– 대량의 DML 작업 시 비동기 모드로 변경
– DBA가 Control 할 수 있어야 함
• 권장 방안
– 비동기 미러링으로 운영
– Queue에 데이터가 쌓이지 않는지 모니터링
– 자동 장애 조치 없는 동기 미러링으로 변경
– 자동 장애 조치 있는 동기 미러링으로 변경
미러링: 미러서버 IO 문제
• 미러서버가 IO를 많이 사용함
• 데이터 기록 방식의 차이
• IO 문제가 심각하다면
– TF 3499 사용
– 테스트!!!
– Failover 시갂이 느려질 수 있음
미러링: with 클러스터링
• 클러스터링과 미러링을 함께 사용
• 자동 장애조치 구성
• 대부분은 1차로 클러스터링이 해결 원함
• 미러링 timeout 설정 필요– Default: 10초
– ALTER DATABASE … SET PARTNER TIMEOUT 100
로그 젂달: 동기화 사용
• 미러링, 복제의 초기화에 사용 가능
• 대량의 데이터를 초기화 해야 하는 경우
• 젂체 백업 이후 로그 복원 자동화
감사합니다.