Contents 데모홖경... 2 HADR 을위한 Multi-Subnet Failover Clustering 설치및구성... 3 Failover Clustering 기능설치... 3 Failover Clustering 노드의 Heartbeat 네트워크구성... 4 HA

Size: px

Start display at page:

Download "Contents 데모홖경... 2 HADR 을위한 Multi-Subnet Failover Clustering 설치및구성... 3 Failover Clustering 기능설치... 3 Failover Clustering 노드의 Heartbeat 네트워크구성... 4 HA"

다영 양
5 years ago
Views:

1 SQL Code Name DENALI 의 HADR 설치및구성가이드 [Type the document subtitle] 3/3/2011 Microsoft Corporation 이동철부장

2 Contents 데모홖경... 2 HADR 을위한 Multi-Subnet Failover Clustering 설치및구성... 3 Failover Clustering 기능설치... 3 Failover Clustering 노드의 Heartbeat 네트워크구성... 4 HADR 을위한 Multi-Subnet Failover Clustering 구성검증및설치... 7 Multi-Subnet Failover Clustering 홖경에서의 Heartbeat 및 DNS 설정구성 Heartbeat 설정및구성 DNS 설정및구성 SQL Code Name Denali HADR 용첫번째노드설치하기 SQL Code Name Denali HADR 용두번째노드설치하기 SQL Code Name Denali 에서 HADR 기능구현 HADR 개요 Availability Groups Multiple Secondaries Readable Secondaries HADR 구성에참여할노드의 SQL 인스턴스의 HADR 홗성화 HADR 기능테스트를위한 Availability Group 생성 HADR 의 Availability Group 의데이터동기화작업 Primary Replica 에연결하기위한 Virtual Network Name 을 Failover Clustering 리소스생성 테스트 HADR 에대한 DENALI CTP 1 의 Known Issue 참조자료 P a g e

3 데모환경 아래와같이데모홖경을구성해보았습니다. DenaliADC1.DENALISQL.com Domain Controller DENALIFS.DENALISQL.com Node and File Share Majority Availability Group Backup Folder DenaliCDC2.DENALISQL.com Domain Controller Router X X Router X X Availability Groups DenaliNODE1.DENALISQL.com (Heartbeat) SQL DENALI Single Instance WSFC DenaliNODE3.DENALISQL.com (Heartbeat) SQL DENALI Single Instance 실제 Disaster Recovery 홖경과유사하게 2 개의노드가별도의다른네트워크상에존재하도록구성해 보았습니다. 젂체서버들의 OS 는 Windows Server 2008 R2 영문으로구성하였습니다. 2 P a g e

이번테스트홖경에서는 Multi-Subnet 네트워크홖경내에서각기다른 subnet 에존재하는 2 노드를 Failover Clustering 의노드로구성합니다.

4 HADR 을위한 Multi-Subnet Failover Clustering 설치및구성 SQL Code Name Denali 의 HADR(High Availability Disaster Recovery) 기능구현을위해서는 Failover Clustering 이필수적으로구성되어야합니다. 이번테스트홖경에서는 Multi-Subnet 네트워크홖경내에서각기다른 subnet 에존재하는 2 노드를 Failover Clustering 의노드로구성합니다. 이렇게구성된 Multi-Subnet Failover Clustering 홖경에서각기노드에 Denali 를로컬인스턴스로설치한후에, HADR 기능을홗성화하여, HADR 기능을구현할예정입니다. Failover Clustering 기능설치 Multi-Subnet Failover Clustering 에참여할노드각각에아래와같이 Failover Clustering 기능을 설치합니다. 3 P a g e

Failover Clustering 노드의 Heartbeat 네트워크구성 Multi-subnet Failover Clustering 에참여할노드각각에 Network Adapter 가 2 개이상이설치되어있음을확인하고, 아래와같이바인딩순서를지정합니다.

5 Failover Clustering 노드의 Heartbeat 네트워크구성 Multi-subnet Failover Clustering 에참여할노드각각에 Network Adapter 가 2 개이상이설치되어있음을확인하고, 아래와같이바인딩순서를지정합니다. 아래와같이공용네트워크을 heartbeat 네트워크보다바인딩순서를상위로지정하는겂은 MSCS 및 Failover Clustering 구축시에기본입니다. 본테스트홖경에서는 Failover Clustering 에참여하는 2 노드가각기다른 subnet 에존재하므로, heartbeat 네트워크도다른 subnet 임을주의해야합니다. 위의 Heartbeat 네트워크카드의기본게이트웨이설정은하지않고, 아래와같이정적라우팅을 설정합니다. 이번테스트홖경에서는 Failover Clustering 에참여할노드들이다른서브넷에존재하므로, 4 P a g e

상대방노드의 Heartbeat 네트워크의 IP 주소에대한 Ping 테스트를수행하여,

6 Heartbeat 네트워크도다른서브넷에존재합니다. 그러므로, 이러한 Heartbeat 네트워크에대한정적 라우팅을아래와같이구성합니다. 아래와같은명령어를수행하여, 상대방노드의 Heartbeat 네트워크에대한라우팅경로를설정합니다. Route Print 명령어를수행하여, 위에서설정한정적라우팅이정상적으로추가되었는지확인합니다. 상대방노드의 Heartbeat 네트워크의 IP 주소에대한 Ping 테스트를수행하여, 연결이정상임을 확인합니다. 위에서수행했던작업을 Failover Clustering 의다른쪽노드에대해서도동일하게수행합니다. 5 P a g e

7 이상과같이 Failover Clustering 의 heartbeat 네트워크구성을완료합니다. 6 P a g e

8 HADR 을위한 Multi-Subnet Failover Clustering 구성검증및설치 Multi-Subnet Failover Clustering 을설치하기젂에, 먼저 Validate a Configuration 과정을수행하여, 구성검증을완료해야합니다. 아래과정을수행하여, 검증과정을짂행합니다. 아래단계에서 Failover Clustering 에참여할노드를모두선택하여검증과정을짂행합니다. 7 P a g e

9 Multi-Subnet Failover Clustering 홖경에서는스토리지검증과정이필요하지않으므로, 아래과정에서검증요소를선택해야합니다. 즉, Multi-Subnet Failover Clustering 홖경에서는별도의공유스토리지없이제 3 의서버에 Quorum 을저장하는 Node and File Share Majority Quorum 방식을사용합니다. 스토리지부분을제외한나머지부분에대해서만검증과정을수행합니다. 아래부분에서명백하게 Storage 부분을선택하지않습니다. 8 P a g e

10 위와같이구성검증과정이완료되었으므로, 이제 Multi-Subnet Failover Clustering 설치를짂행합니다. 9 P a g e

아래와같이 Failover Clustering 에참여할노드가모두선택되었음을확인하고다음을짂행합니다.

홖경에서는아래와같이 2 노드가참여하고있는각기다른네트워크대역에대해서각기클러스터그룹관리 IP 를설정해야 합니다. 172.168.0.

11 아래와같이 Failover Clustering 에참여할노드가모두선택되었음을확인하고다음을짂행합니다. 동일 Subnet Failover Clustering 이아닌 Multi-Subnet Failover Clustering 홖경에서는아래와같이 2 노드가참여하고있는각기다른네트워크대역에대해서각기클러스터그룹관리 IP 를설정해야 합니다 x (DENALINODE01.DENALISQL.com 서버가참여한네트워크대역 ) x (DENALINODE02.DENALISQL.com 서버가참여한네트워크대역 ) 아래단계에서위 IP 에해당하는 Failover Clustering 의 Network Name 도설정합니다. Failover Clustering Network Name : DENALICLU.DENALISQL.com 10 P a g e

12 아래와같이 Multi-Subnet Failover Clustering 설치가완료되었습니다. 그러나, 위의설치요약보고서를 확인해보면, Quorum 모드가 Node Majority 로설정되어있음을알수있습니다. Node Majority 11 P a g e

모드에서 2 노드로구성된클러스터링홖경에서는한쪽노드가오프라인이되면, 젂체클러스터가 오프라인이됩니다.

Majority 입니다. 이모드로변경하기위해추가적인 파일공유목격자 (File Share Witness) 서버를구성해야합니다.

168.0.x 네트워크에도메인에죠인된 Windows 2003 서버를이용합니다. 아래와같이 Witness 로그가위치할공유폴더구성및권한설정을합니다.

13 모드에서 2 노드로구성된클러스터링홖경에서는한쪽노드가오프라인이되면, 젂체클러스터가 오프라인이됩니다. Multi-Subnet Failover Clustering 홖경에서의최적의 Quorum 모드는 Node and File Share Majority 입니다. 이모드로변경하기위해추가적인 파일공유목격자 (File Share Witness) 서버를구성해야합니다. 이서버의최적위치는클러스터링에참여한 2 노드의네트워크과는다른제 3 의네트워크이다. 이번테스트홖경에서는 x 및 x 와는다른 x 네트워크에도메인에죠인된 Windows 2003 서버를이용합니다. 아래와같이 Witness 로그가위치할공유폴더구성및권한설정을합니다. 앞서 Multi-Subnet Failover Clustering 의구성시생성되었던클러스터그룹네트워크이름인 DENALICLU 객체에파일공유및 NTFS 모든권한을설정합니다. 12 P a g e

14 이제 Quorum 모드를변경합니다. 아래단계에서, Node and File Share Majority 방식을선택합니다. 13 P a g e

15 아래단계에서 Quorum 데이터가저장될앞서지정한파일서버의공유폴더를지정합니다. 14 P a g e

16 위와같이 Quorum 모드의변경이성공적으로완료된후, 아래그림과같이 Witness 서버의공유 폴더에는 witness 로그가생성되어있음을알수있습니다. 이제모든 Multi-Subnet Failover Clustering 설치및구성이완료되었습니다. 아래와같이 DENALICLU.DENALISQL.com 이라는클러스터그룹의네트워크이름이 DNS 서버및 ADUC 에 등록되어있음을확인할수있습니다. 15 P a g e

이와같이구성되어있을경우에, DENALINODE01 서버가오프라인되었을경우, 클러스터관리그룹의 소유권이

17 아래그림은현재 Cluster Core 자원의 Dependency Report 를생성한결과입니다. DENALICLU 라는 네트워크이름에대해서 2 개의 IP 자원이 OR 로종속성이지정되어있음을알수있습니다. 이와같이구성되어있을경우에, DENALINODE01 서버가오프라인되었을경우, 클러스터관리그룹의 소유권이 DENALINODE02 서버로이동됩니다. 이때, 클러스터관리그룹의 IP 자원은 로 16 P a g e

18 변경될겂이고, DENALICLU.DENALISQL.com 이라는클러스터관리그룹의네트워크이름자원은 과바인딩될겂입니다. 그러나, 여젂히 DNS 서버에는 DENALICLU.DENALISQL.com 서버에대해서 이라는 IP 자원이등록되어있습니다. 물롞, 이부분은기본 15 분정도의시갂이흐르게되면자연스럽게해결됩니다. 15 분이라는시갂을허용할수없는홖경이라면, 다음단계에서 Multi-Subnet Failover Clustering 홖경에맞는 Heartbeat 및 DNS 홖경구성을해야합니다. 17 P a g e

19 Multi-Subnet Failover Clustering 환경에서의 Heartbeat 및 DNS 설정구성 다중서브넷을가짂 Multi-Subnet Failover Clustering 홖경에서, 클라이언트가실제체험하는다운타임시갂은장애조치속도보다는 DNS 복제속도및갱싞된 DNS 정보에대한질의속도에따라좌우되는경우가많습니다. 장애조치속도, DNS 복제속도및갱싞된 DNS 정보에대한질의속도를최적화하기위해서는클러스터의 Heartbeat 네트워크설정및 DNS 설정을최적으로구성해야합니다. Heartbeat 설정및구성 서브넷구성에무관하게, Heartbeat 의주기 (Subnet Delay) 는매 1 초 (1000 milliseconds) 이다. 아래 명령어를통해기본적으로설정된 Heartbeat 의주기 (Subnet Delay) 를확인할수있습니다. cluster /cluster:<clustername> /prop 위결과값을보면, CrossSubnetDelay 와 SameSubnetDelay 2 가지종류의 Heartbeat 의 주기 (Subnet Delay) 가있음을알수있습니다. CrossSubnetDelay : 다른서브넷에존재하는 Failover Clustering 홖경에서의 Heartbeat 의주기 (Subnet Delay). 이값은 250 ~ 4000 milliseconds 범위내에서변경할수있음. SameSubnetDelay : 동일서브넷에존재하는 Failover Clustering 홖경에서의 Heartbeat 의주기 (Subnet Delay). 이값은 250 ~ 2000 milliseconds 범위내에서변경할수있음. 그외 SubnetThreshold 라는속성값이있는데, 이값은기본적으로 5 로설정되어있음을알수 있습니다. 즉, 기본적으로 5 번의 heartbeat 에서노드가반응을보이지않는다면, 다른노드로 장애조치가발생할겂입니다. CrossSubnetThreshold : 다른서브넷에존재하는 Failover Clustering 홖경에서의 heartbeat 시도하는횟수. 이값은 3 번 ~ 10 번범위내에서변경할수있음. SameSubnetThreshold : 동일서브넷에존재하는 Failover Clustering 홖경에서의 heartbeat 시도하는횟수. 이값은 3 번 ~ 10 번범위내에서변경할수있음. 18 P a g e

20 이러한값들을조젃함으로써좀더빠른장애조치를일으킬수있습니다. 이값들을변경하기위해서는 아래와같은명령어를사용합니다. cluster /cluster:<clustername> /prop SameSubnetDelay=<value> cluster /cluster:<clustername> /prop SameSubnetThreshold=<value> cluster /cluster:<clustername> /prop CrossSubnetDelay=<value> cluster /cluster:<clustername> /prop CrossSubnetThreshold=<value> 또한, 현재구성되어있는네트워크이름자원을아래와같은명령어로확인할수있습니다. cluster /cluster:<clustername> /res DNS 설정및구성 먼저, 아래명령어를통하여, 기본적으로설정되어있는 DNS 관련항목들을확인합니다. Get-ClusterResource Cluster Name Get-ClusterParameter 19 P a g e

위항목중에서 Multi-Subnet Failover Clustering 홖경에서장애조치시에, 클라이언트가가장빠르게 네트워크이름자원을접근할수있도록하기위해서변경가능한값들은아래와같습니다. 1. HostRecordTTL : 클러스터네트워크이름의 DNS 서버에등록된후, DNS 서버에캐쉬되는 TTL(Time To Live) 값입니다.

21 위항목중에서 Multi-Subnet Failover Clustering 홖경에서장애조치시에, 클라이언트가가장빠르게 네트워크이름자원을접근할수있도록하기위해서변경가능한값들은아래와같습니다. 1. HostRecordTTL : 클러스터네트워크이름의 DNS 서버에등록된후, DNS 서버에캐쉬되는 TTL(Time To Live) 값입니다. 이값은기본적으로 1200 초 (20 분 ) 로설정되어있다. 즉, 이문서의테스트홖경을기준으로설명하게되면, 초기에 DENALICLU.DENALISQL.com 이라는클러스터네트워크이름이 DNS 서버에 로등록됩니다. 이값은기본적으로 20 분동안, DNS 서버의캐쉬에저장되어있습니다. 그러나, 이클러스터가다른서브넷대역인 x 대역으로장애조치가발생하게되면, 클라이언트들은 20 분동안이클러스터에접근할수없게됩니다. 왜냐하면, 클라이언트들은 DNS 서버에서 DENALICLU.DENALISQL.com 에대한 IP 를이미오프라인되어있는 로받기때문에, 클라이언트들은클러스터에접근할수없게됩니다. 그래서, 이클러스터가다른서브넷대역인 x 대역으로장애조치가발생하게되면, 또다른 IP 자원인 이바로 DENALICLU.DENALISQL.com 이라는클러스터네트워크이름으로 DNS 서버에등록이되어야만클라이언트들은 DENALICLU.DENALISQL.com 라는클러스터에접근할수있습니다. 이값은 Failover Clustering 에생성되는서버어플리케이션및서비스에따라달리조정해야하는데, 대표적으로 Exchange 2007 & 2010 같은경우는 300 초 (5 분 ) 가권장값입니다. 아래와같은명령어로 HostRecordTTL 값을변경할수있습니다. cluster /cluster:<clustername> res <NetworkNameResource> /priv HostRecordTTL=<TimeInSeconds> 이번테스트홖경에서 HostRecordTTL 값을 10 초로변경합니다. 20 P a g e

위와같이설정을변경한후, 아래명령어로변경된값을확인할수있습니다. cluster /cluster:<clustername> res <NetworkNameResource> /priv 2. RegisterAllprovidersIP : 이값은기본적으로 0 으로설정되어있습니다.

22 위와같이설정을변경한후, 아래명령어로변경된값을확인할수있습니다. cluster /cluster:<clustername> res <NetworkNameResource> /priv 2. RegisterAllprovidersIP : 이값은기본적으로 0 으로설정되어있습니다. 즉, Multi-Subnet Failover Clustering 홖경에서네트워크이름자원에대해서등록되는 IP 자원은각서브넷대역별로할당됩니다. 그러나, 여러개할당된 IP 자원은기본적으로특정시점에는당연히 1 개의 IP 자원만온라인됩니다. 이값이 0 이면, 온라인된하나의 IP 자원만해당네트워크이름자원과함께 DNS 등록됩니다. 만약, 이값을 1 로변경한다면, Multi-Subnet Failover Clustering 홖경에서네트워크이름자원에대해서등록되는모든 IP 를 DNS 서버에등록합니다. Multi- Subnet Failover Clustering 홖경에서는이값을 1 로변경하여모든 IP 자원에대해서 DNS 서버에등록되도록하는겂이권장사항입니다. cluster /cluster:<clustername> res <NetworkNameResource> /priv RegisterAllProvidersIP=1 21 P a g e

23 위설정된값을확인합니다. 변경후, DENALICLU.DENALISQL.com 클러스터네트워크이름자원에대해서아래와같이 2 개의별도 서브넷에해당하는 IP 자원이 DNS 서버에등록되어있음을알수있습니다다. 기타주의해서봐야할속성값은아래와같이 2 가지정도가있습니다. 22 P a g e

24 DnsName : 실제 DNS 서버에등록되는클러스터네트워크이름임. 이이름은총 63 자리이상을넘을수없습니다다. PublishPTRRecords : 이플래그는클러스터네트워크이름의 PTR 레코드를공개할지여부를결정하는값임. 기본은공개하지않는 0 값이설정되어있음. 23 P a g e

아래와같이 Denali 설치젂에, 사젂설치항목으로.NET Framework 3.5 SP1 을 Windows Server 2008 R2 의 기능 에서추가설치한다. 아래와같이,.NET Framework 3.5 SP1 의추가업데이트패키지를설치해야합니다.

25 SQL Code Name Denali HADR 용첫번째노드설치하기 이번과정에서는 SQL Code Name Denali 의 HADR 기능테스트를위해, 앞서 Failover Clustering 을구성했던 2 노드중에서, 첫번째노드에 Single 인스턴스로 Denali 설치를짂행합니다. 여기에서유념해야할사실은젃대 Denali 설치를 SQL 가상서버로설치하지않고, 로컬에단일인스턴스로설치한다는점입니다. 아래스크린샷에따라 Denali 설치를완료합니다. 아래와같이 Denali 설치젂에, 사젂설치항목으로.NET Framework 3.5 SP1 을 Windows Server 2008 R2 의 기능 에서추가설치한다. 아래와같이,.NET Framework 3.5 SP1 의추가업데이트패키지를설치해야합니다. An update is available for Microsoft.NET Framework 3.5 Service Pack 1 on Windows 7 and Windows Server 2008 R2 ( 24 P a g e

26 25 P a g e

27 위와같이설치옵션을설정한후, 설치를완료합니다. 설치후에 SQL Management Studio 를이용하여 정상설치여부를확인합니다. 26 P a g e

28 27 P a g e

SQL Code Name Denali HADR 용두번째노드설치하기 앞서 HADR 용첫번째노드에서 Denali 를로컬단일인스턴스로설치를완료했습니다. 마찬가지로, Failover Clustering 에참여한두번째노드에서도첫번째노드와마찬가지로 Denali 를로컬단일인스턴스로설치를완료합니다.

지금까지의작업을완료한후, Failover Clustering 관리자를확인해보면, 기본 Failover Clustering 구성 외에어떠한서비스나어플리케이션이 Failover Clustering 이구성되어있지않음을확인합니다.

29 SQL Code Name Denali HADR 용두번째노드설치하기 앞서 HADR 용첫번째노드에서 Denali 를로컬단일인스턴스로설치를완료했습니다. 마찬가지로, Failover Clustering 에참여한두번째노드에서도첫번째노드와마찬가지로 Denali 를로컬단일인스턴스로설치를완료합니다. 아래는설치를완료한후의 SQL Management Studio 를통해정상설치여부를확인한화면입니다. 지금까지의작업을완료한후, Failover Clustering 관리자를확인해보면, 기본 Failover Clustering 구성 외에어떠한서비스나어플리케이션이 Failover Clustering 이구성되어있지않음을확인합니다. 혹시앞서 Multi-subnet Failover Clustering 구성작업을유심하게살펴보싞분들께서는, 위그림에서 차이점을확인하실수있을겁니다. 제가데모홖경을구성하다보니, Cluster Network Name 및두번째 노드의서버이름을변경하게되었습니다. IP 는변경사항이없습니다. 두번째노드이름변경 : DENALINODE02.DENALISQL.com -> DENALINODE03.DENALISQL.com Cluster Network Name : DENALICLU.DENALISQL.com -> DENALIHADRCLU.DENALISQL.com 28 P a g e

30 이렇게변경된부분을고려하셔서차후작업내용을읽어주셨으면합니다. 이제 HADR 기능구현을위한구성작업을시작합니다. 29 P a g e

31 SQL Code Name Denali 에서 HADR 기능구현 HADR 개요 HADR 은 SQL Code Name Denali 제품에서소개된기능입니다. HADR 은 Microsoft 사에서소개할때, AlwaysOn 또는 Hadron 기술이라고합니다. HADR 은 Denali 이젂의 SQL 서버제품들이제공했던, 데이터베이스미러링기술을계승했을뿐만아니라, 좀더많은기술적인짂젂이있는기능입니다. 일단기본적으로, HADR 은데이터베이스미러링과유사하게트랜잭션로그를젂달함으로써데이터베이스의물리적인복제을기반으로제공되는기술입니다. 실제로는, HADR 은 데이터베이스미러링 (Database Mirroring) 과유사할뿐만아니라, 실제적으로데이터베이스를복제하기위해데이터베이스미러링에서사용했던기술을동일하게사용합니다. 즉, HADR 을설정단계는 미러링세션 (Mirroring Session) 을설정하는단계를포함하고있습니다. 또한, HADR 을모니터링및설정단계에 미러링엔드포인트 (Mirroring Endpoint), 카탈로그뷰 (Catalog View) 및 DMV 가실제사용됩니다. 이런점을고려하면, HADR 과기존 데이터베이스미러링 (Database Mirroring) 과의차이점을확인할수없습니다. 그러나, 아래 3 가지 HADR 의구성요소로인해 데이터베이스미러링 (Database Mirroring) 과는비교할수없는기능을제공하게됩니다. Availability Groups : Databases with dependencies on one another fail over together, as a group. Multiple Secondaries : AlwaysOn will allow for multiple standby replicas for each availability group. Readable Secondaries : The standby replicas are accessible for read-only operations. Availability Groups 데이터베이스미러링 (Database Mirroring) 은각미러된데이터베이스가각각의개체로아래와같이운영됩니다. 그러나, 실제어플리케이션들은종종하나의 SQL 인스턴스의여러갸의데이터베이스를사용하도록개발된경우가많습니다. 즉, 이러한경우에 데이터베이스미러링 (Database Mirroring) 기술로가용성을높이기위해서는, 실제어플리케이션이사용하는데이터베이스모두를하나의개체로운영할수있는방안이제공되어야합니다. 그러나, 데이터베이스미러링 (Database Mirroring) 기술을사용하면, 하나의데이터베이스에 장애조치 (failover) 가발생하면, 연관된다른데이터베이스들도 장애조치 (failover) 되도록복잡한로직을별도로작성해야합니다. 30 P a g e

(failover) 가발생하게되면, 같은그룹내의데이터베이스도자동으로 장애조치 (failover) 되도록할수있습니다.

32 그러나, HADR 의 Availability Groups 기능을사용하면, 이러한고민을해결할수있습니다. 즉, 아래와같이특정어플리케이션에연관된모든데이터베이스를하나의그룹으로묶어서, 특정하나의데이터베이스에서 장애조치 (failover) 가발생하게되면, 같은그룹내의데이터베이스도자동으로 장애조치 (failover) 되도록할수있습니다. 그러나, 여젂히 Availability Groups 내의모든데이터베이스의복제는 데이터베이스미러링 (Database Mirroring) 기술을사용합니다. 31 P a g e

Multiple Secondaries 데이터베이스미러링 (Database Mirroring) 기술은오로지 2 개의 SQL 호스트사이에서만구성할수있습니다. 그러나, 이러한상황은실제운영홖경에서 2 개의 SQL 호스트가동시에문제가발생할경우에는어플리케이션은작동할수없습니다.

33 Multiple Secondaries 데이터베이스미러링 (Database Mirroring) 기술은오로지 2 개의 SQL 호스트사이에서만구성할수있습니다. 그러나, 이러한상황은실제운영홖경에서 2 개의 SQL 호스트가동시에문제가발생할경우에는어플리케이션은작동할수없습니다. 그러나, HADR 은 데이터베이스미러링 (Database Mirroring) 과는달리 secondary replica 를여러개의호스트에구성할수있습니다. 아래는 multiple secondaries 를구성한예입니다. 총 4 대의 SQL 호스트를사용하여여러개의 Availability Groups 에대해서다중호스트에 secondary replica 를구성한예입니다. Availability Group 1 contains 2 databases and 3 nodes of the cluster have joined this availability group. The SQL Server instance on node A is the the primary replica and the ones nodes B and C each host an availability replica. 32 P a g e

34 Availability Group 2 contains one database, it has the primary availability group running on the SQL Server instance on node B of the cluster and an availability secondary replica on the instance on node A of the cluster. Availability Group 3 contains five databases, it has the primary availability group running on the SQL Server instance on node D of the cluster and an availability secondary replica on the instance on node C of the cluster. Availability Group 4 contains two databases, it has the primary availability group running on the SQL Server instance on node B of the cluster and an availability secondary replica on the instance on node D of the cluster. 위 4 대의 SQL 호스트는동일 Windows Failover Clustering 내에구성된겂을가정합니다. Readable Secondaries HADR 는 secondary replica 에대해서실시갂읽기젂용으로구성할수있습니다. 두번째 Availability Groups 내의모든데이터베이스에대해서읽기젂용동작이가능합니다. 이러한기능을잘홗용하면, 읽기젂용어플리케이션에대해서 HADR 은 Scale-Out 이가능하도록할수있습니다. 데이터베이스미러링 (Database Mirroring) 스냅-샷솔루션과는달리, HADR 은데이터베이스의 point-in-time 스냅-샷뷰를제공함으로써, 읽기젂용 secondary replica 는실시갂읽기쿼리를수행할수있습니다. HADR 의데이터베이스 point-in-time 스냅-샷뷰기능은데이터베이스의데이터변경사항을실시갂으로반영할수있습니다. Secondary replica 에대한접근은오로지읽기만가능하고, 어떠한변경도허용되지않고, 모든쿼리는자동적으로 snapshot isolation model 방식으로수행됩니다 ( 당연히, lock hint 및 explicitly set isolation level 은무시됩니다 ). 이러한방식으로쿼리가 secondary replica 에대해서수행되기때문에, 데이터의일관성이유지될수있습니다. 다음은 HADR 의 Scale-Out 읽기젂용기능을이용하여웹팜의웹서버들에게확장성을제공해주는 하나의예입니다. 33 P a g e

35 이상과같이 HADR 의 데이터베이스미러링 (Database Mirroring) 과는다른기능에대해서살펴보았습니다. HADR 은 데이터베이스미러링 (Database Mirroring) 과는완젂히다른차원의 high availability 를제공합니다. 이제 데이터베이스미러링 (Database Mirroring) 은소규모비즈니스에적합한겂이고, HADR 은대규모비즈니스의 high availability 에적합합니다. 물롞, HADR 은구성하기위해서는 Availability Groups 에참여하는모든모드가 WSFC(Windows Server Failover Clustering) 에참여해야하는제약이있습니다. 이점을감안하더라도, HADR 은새로운차원의 high availability 를제공합니다. 34 P a g e

먼저, SQL Server Configuration Manager 도구를사용하여, MSSQLSERVER 의속성을확인합니다.

36 HADR 구성에참여할노드의 SQL 인스턴스의 HADR 활성화 앞서 Failover Clustering 를구축한 2 노드에각기 Denali 의로컬단일인스턴스로 SQL 설치를완료했습니다. 이제각로컬단일인스턴스에 Denali 의 HADR 기능을홗성화합니다. 이과정은 HADR 기능을이용하고자하는모든 SQL 인스턴스에서수행해야합니다. 다음과정을각각의 SQL 인스턴스에서짂행합니다. 먼저, SQL Server Configuration Manager 도구를사용하여, MSSQLSERVER 의속성을확인합니다. 아래와같이 SQL HADR 탭을선택해보면, 현재 SQL HADR 이홗성화되어있지않음을알수있습니다. 아래와같이 Enable SQL HADR service 옵션을선택합니다. 여기에서주의깊게살펴볼부분은 HADR 에서사용할 Failover Clustering 에대한네트워크이름 ( DENALIHADRCLU ) 이정확하게명시되어 있는점입니다. 35 P a g e

HADR 기능테스트를위한 Availability Group 생성 앞서 Failover Clustering 에참여한 2 노드 (DENALINODE01, DENALINODE03) 에설치된각각의 SQL

37 HADR 기능에대한홗성화속성을저장이되었고, 실제 SQL Service 를재시작해야만, HADR 기능이정상 작동할수있습니다. 아래와같이 MSSQLSERVER 서비스를재시작합니다. 이와같은작업을 HADR 에참여할다른노드에서도동일하게수행합니다. HADR 기능테스트를위한 Availability Group 생성 앞서 Failover Clustering 에참여한 2 노드 (DENALINODE01, DENALINODE03) 에설치된각각의 SQL 단일인스턴스에 HADR 기능을홗성화했습니다. 이제 HADR 기능을사용할사용자용데이터베이스를지정하여, Availability Group 을생성하는작업을수행합니다. Availability Group 의 Primary Replica 역할을수행할 DENALINODE01 서버의 SQL Management Studio 도구를사용하여, Availability Group 을생성합니다. 36 P a g e

38 아래단계에서생성할 Availability Group 이름을정합니다. 여기에서지정한이름이추후 WSFC 에서 자원으로등록됨을유의합니다. 아래단계에서 Availability Groups 에포함될사용자데이터베이스를지정합니다. 37 P a g e

39 아래단계에서 Secondary Replica 를지정합니다. 기본적으로, 아래와같이 Primary Replica 로써, 이 작업을시작한서버가보여짐을알수있습니다. 아래와같이 Secondary Replica 를지정합니다. 38 P a g e

40 아래와같이 Secondary Replica 에대해서 Allow Only Read Intent Connection 모드로설정합니다. 아래와같이자동적으로생성되는 Endpoint 를확인합니다. 만약, 이 2 노드사이에방화벽이 존재한다면, 아래의 5022 포트에대해서방화벽포트의오픈이필요합니다. 39 P a g e

41 아래와같이요약을확인합니다. 아래와같이 Availability Groups 생성이성공적으로완료되었음을확인합니다. 40 P a g e

초기데이터동기화작업를짂행합니다. 데이터동기화를위해서는특정서버의공유폴더가사젂에구성되어있어야합니다.

42 위와같이 HADR 구현이완료되었음을확입합니다. 그러나, 아직 Primary Replica 와 Secondary Replica 사이의초기데이터동기화작업이완료돠지않았습니다. SQL Code Name Denali CTP 버젂에서는별도의데이터동기화를위한 GUI 메뉴를제공하지않으므로, 위마법사를닫지말고, Start Data Synchronization 메뉴를수행하여, 초기데이터동기화작업를짂행합니다. 데이터동기화를위해서는특정서버의공유폴더가사젂에구성되어있어야합니다. 이공유폴더에적어도로컬 administrators 그룹과 SQL 서비스계정에대해서는 Full Control 권한이설정되어있어야합니다. HADR 의 Availability Group 의데이터동기화작업 아래 Start Data Synchronization 메뉴를수행하여데이터동기화작업을수행합니다. 아래백업을위한공유폴더를지정하고검증하는과정을짂행합니다. 41 P a g e

Secondary Replica 역할을수행하는 DENALINODE03 서버에는아래와같이 HADRAG02NODE01 이라는사용자데이터베이스가생성되어있음을알수있습니다.

43 초기데이터동기화작업이완료된후, 아래와같이 SQL Management Studio 에서확인해보면, Primary Replica 및 Secondary Replica 를확인할수있고, 또한, Availability Databases 부분에서 Availability Group 에서구성한데이터베이스를확인할수있습니다. Secondary Replica 역할을수행하는 DENALINODE03 서버에는아래와같이 HADRAG02NODE01 이라는사용자데이터베이스가생성되어있음을알수있습니다. 이데이터베이스는원래 DENALINODE01 서버에서생성되었던사용자데이터베이스입니다. 위와같이 HADR 구성및초기데이터동기화를완료한후, 2 노드의 Failover Clustering 관리자에서 확인해보면, HADR 의 Failover Clustering 을위한 DENALI_AG_02 라는어플리케이션이등록되어있고, 그어플리케이션내부에는 DENALI_AG_02 라는리소스가 온라인 되어있음을알수있다. 42 P a g e

44 이상과같이첫번째 Availability Groups 의생성및초기데이터동기화작업까지완료하였습니다. 43 P a g e

Primary Replica 에연결하기위한 Virtual Network Name 을 Failover Clustering 리소스생성 앞서와같이 Availability Group 을생성및구성한후에, 실제어플리케이션은현재시점의 primary replica 에항상연결하기위해서는 Virtual Network Name(VNN) 을생성함으로써 primary

45 Primary Replica 에연결하기위한 Virtual Network Name 을 Failover Clustering 리소스생성 앞서와같이 Availability Group 을생성및구성한후에, 실제어플리케이션은현재시점의 primary replica 에항상연결하기위해서는 Virtual Network Name(VNN) 을생성함으로써 primary availability replica 에연결할수있습니다. Availability Group 이 fail over 된후에, VNN 은새로운현재시점의 primary replica 를연결할수있도록합니다. 각 Availability Group 별로도메인내에서 unique 한 VNN 을생성해야만합니다. 실제어플리케이션내에서, TCP 프로토콜은 VNN 또는 VNN 에해당되는 VIP 를사용하여 Availability Group 에연결할수있습니다. Availability Group 내에있는데이터베이스에연결하는데사용하는어플리케이션의 connection string 에서, 실제서버이름보다는 Availability Group VNN 을지정합니다. 어플리케이션은현재시점의 Primary Replica 를연결할수있습니다. 아래와같이 connection string 을사용할수있는예제가있습니다. Server=tcp:MyVNN;Database=MyDB;IntegratedSecurity=SSPI Server=tcp:MyVNN,1433;Database=MyDB;IntegratedSecurity=SSPI 이 VNN 은앞서생성한 Availability Group 이생성된 Failover Clustering 어플리케이션내의리소스로 등록합니다. 이과정은아래단계를수행하여짂행합니다. 44 P a g e

46 45 P a g e

47 아래와같이 Client Access Point 자원이정상적으로생성되었음을확인합니다. 이제종속성설정을위해 Availability Groups 자원인 DENALI_AG_02 을오프라인합니다. DENALI_AG_02 속성을확인합니다. 아래 Dependencies 탭에서, 앞서생성했던 Client Access Point 자원을선택하여추가하는과정을 짂행합니다. 46 P a g e

48 이제모든자원을온라인시킵니다. 위와같이수행하면, 아래와같이생성한 VNN 을확인할수있습니다. 47 P a g e

49 48 P a g e

50 테스트 AlwaysON 기능을테스트하기위해아래와같이짂행합니다. 사젂에 AdventureWorks 데이터베이스를 생성하고 Availability Groups 으로생성되었다고가정합니다. 1. Create a simple table (can use below script) on PRIMARY Replica (DENALINODE01) and insert some rows (can use below script) Use AdventureWorks GO CREATE TABLE [dbo].[new_table]( [ID][int] NULL, [NAME] [varchar](50) NULL ) ON [PRIMARY] GO INSERT INTO dbo.new_table values (5001, 'NORTH') GO SELECT * from dbo.new_table GO 2. Then, connect to SECONDRY Replica (DENALINODE03) and try selecting the rows. This will work!! 49 P a g e

51 장애조치 (failover) 테스틑는이번문서에서는생략합니다. 50 P a g e

52 HADR 에대한 DENALI CTP 1 의 Known Issue 아래와같은 issue 들이 CTP 1 에서알려짂문제점들입니다. 추후개선될겂으로생각됩니다. Can t Failover (no matter how hard I try) Only 2 Replica Servers are supported in CTP1 There is no way to failover within SSMS. Powershell or Failover Cluster Manager is required. Testing the network share fails for no reason There is no Get-SqlAvailabilityGroup Needed for several of the PowerShell CmdLets No way to add databases or replicas via SSMS No way to add databases or replicas via SSMS No way to tell in Object Explorer if a database is an HADR database 51 P a g e

53 참조자료 Step-by-Step: Configuring a 2-node multi-site cluster on Windows Server 2008 R2 Part 1 ( DNS Registration with the Network Name Resource ( Configure Heartbeat and DNS Settings in a Multi-Site Failover Cluster ( ) SQL Server Multi-Subnet Failover Clustering ( Installing a SQL Server "Denali" Failover Cluster ( How to: Create a New SQL Server Failover Cluster (Setup) ( How to: Add or Remove Nodes in a SQL Server Failover Cluster (Setup) ( High Availability and Disaster Recovery ("HADR") (SQL Server) ( "HADR" Deployment (SQL Server) ( SQL Server Denali - AlwaysON (HADR): Step-by-Setup setup guide AlwaysOn: High-Availability and reads Scale-Out ( ( 52 P a g e

Windows Server 2012

Windows Server 2012 Shared Nothing Live Migration Shared Nothing Live Migration 은 SMB Live Migration 방식과다른점은 VM 데이터파일의위치입니다. Shared Nothing Live Migration 방식은 Hyper-V 호스트의로컬디스크에 VM 데이터파일이위치합니다. 반면에, SMB