AlwaysOn 가용성 그룹 구축 # 2 : Windows Server 2016 + MS SQL 2016 / None AD

이어서 AlwaysOn  가용성 그룹 구축을 진행한다.

전 글에서 진행한 방식은 기존 SQL 미러링 구성과 유사하다. 

주 와 보조 간의 데이타 동기화 및 장애 발생시 역할 변경이 동일하다고 볼 수 있다. 

- OS : Windows Server 2016

- DBMS : MS SQL Server 2016 SP2

- 테스트 서버 : AO_TEST_01 (192.168.1.121) / AO_TEST02 (192.168.1.122) 

- 클러스터 IP : 192.168.1.123 

- 수신기 IP : 192.168.1.125

- 방화벽 정책 추가 : In/Outbound : TCP 135, 445, 3343 / UDP 3343

- 공인 아이피로 구성할 때에는 각 서버의 C:\Windows\System32\drivers\etc\hosts 파일의 내용을 필히 아래와 같이 수정

192.168.1.121 AO-TEST-01 192.168.1.122 AO-TEST-02 192.168.1.123 AOT

 

이번에는 이 구성에 VIP 를 추가하여, 주와 보조의 역할이 변경되더라도 동일한 IP 로 DB 에 접근이 가능하도록 구성한다.

"가용성 그룹 수신기" 를 구성하면 우리가 필요한 기능을 사용 할 수 있다. 

 

 

# 1

AO_TEST_01 의 SSMS 에서 가용성 그룹 - AO_DB - 우클릭 - 수신기 추가 를 선택한다. 

하위 트리의 가용성 그룹 수신기 에서 우클릭해서 만들어도 된다.

 

 

수신기 DNS 이름은 AO_DB 그룹에서 사용되는 고유값을 작성해야 한다.

가용성 그룹은 다중 등록이 가능하므로, 해당 그룹에서만 사용되는 고유 수신기를 등록해야 한다.

수신기 DNS 이름 : AO_Listener  포트 : 1433 네트워크 모드 : 고정 IP IP 주소 : 192.168.1.120

 

한 번에 쉽게 됐으면 테스트를 당연히 안하겠지만, 또 오류 나와버린다.

윈도우 장애 조치 클러스터 어쩌구 저쩌구 오류인데, 클러스터 상태는 정상이다. 

 

아이피를 바꿔서 다시 해본다. 

IP 주소 : 192.168.1.100

 

수신기 생성 진행 중일 때, 클러스터 관리자의 상태는 아래와 같이 표시된다

 

또 오류 뜨면서 실패한다. 

다시 아이피 바꿔서 입력한다.

IP 주소 : 192.168.1.125

 

이번에도 오류가 뜨지만 내용이 다르게 나온다. 

DNS 어쩌구 저쩌구란다. AD 구성시 설정하던 DNS 가 갑자기 튀어 나온다. 

 

MS 기술 문서에서 상세 내용을 훑고 온다. 

https://docs.microsoft.com/ko-kr/sql/database-engine/availability-groups/windows/create-or-configure-an-availability-group-listener-sql-server?view=sql-server-ver15

AD 에서 소속 그룹에 도메인을 추가 하듯이, AO 구성 서버에도 DNS 접미사 및 NetBIOS 컴퓨터 이름이 필요하다는 얘기다. 

그럼 추가 하러 간다. AO_TEST_01 과 AO_TEST_02 둘 다 해야한다.

 

시스템 속성 - 변경 - 자세히 - 이 컴퓨터의 주 DNS 접미사 에 "값" 입력 / "도메인 구성원 자격이 변경되면 주 DNS 접미사 변경" 항목 체크

적용하고 리부팅 1회 진행한다.

 

 

 

다시 SSMS 랑 클러스터 관리자 실행한다.

수신기 추가 단계로 다시 간다.

수신기 DNS 이름 : AO_Listener  포트 : 1433 네트워크 모드 : 고정 IP IP 주소 : 192.168.1.124

 

당연히 또 오류가 나겠거니 했는데 진짜 나온다. 

이번에는 리소스 제어 API 가 오류 코드 5057 을 보냈단다. 

 

sql error 41009 로 구글링 하니깐 외국 SQL 전문가 분이 작성한게 나왔다. 

그래서 따라한다. 

cmd 켜서 "net helpmsg 5057" 입력한다.

 

 

 

 

 

내가 입력한 IP 가 이미 사용 중이란다. 고민하지 말고 그냥 다른 아이피 넣는다. 

IP 주소 : 192.168.1.125

 

이번에는 오류 없이 처리가 됐다. 로딩이 길어져서 실패인가 했는데 정상적으로 구성 됐다. 

안 될 때는 그냥 계속 아이피 변경해서 넣는게 답이다. 

 

 

AO_TEST_01 에서 아이피 조회시, 클러스터 및 리스너 IP 를 소유하고 있음을 확인 할 수 있다.

 

 

# 2

속칭 VIP 구성까지 완료가 되었으니깐 장애 조치 (Failover) 를 순차적으로 해본다.

 

1) AO_TEST_01 서버 전원 OFF

 

AO_TEST_01 전원 OFF 된 후의 상태이다. 

클러스터 호스트 및 소유자, 클러스터 IP, 리스너 IP 모두 AO_TEST_02 가 소유하고 있다. 

 

 

AO_TEST_02 의 SSMS 에서도 변경 된 역할 확인 된다.

 

2) SSMS 에서 장애 조치 진행

 

AO_TEST_02 가 주 로 역할이 변경되었으니깐, 다시 AO_TEST_01 을 주 로 변경하는 작업을 한다.

서버 전원 OFF 로 하는 것은 위에서 했으니깐, AO_TEST_01 서버 전원을 올리고 SSMS 에서 역할 변경을 진행한다.

 

정상 완료 후, AO_DB 클러스터 소유자 및 서버 할당 아이피를 확인한다.

 

AO_TEST_01

 

AO_TEST_02

 

클러스터 IP 는 AO_TEST_02 가 소유하고 있고, 리스너 IP 는 AO_TEST_01 이 소유하고 있음을 알 수 있다. 

 

 

# 3

위 두 가지 방식의 장애 조치 (Failover) 테스트만 진행해도 어떤 구조로 돌아가는지는 이해됐을 테니깐 여기서 종료한다.

윈도우 자체 기능을 통한 DB 이중화 및 장애 조치 클러스터를 구축했는데, 관건은 DB 서버간 데이타 전송시의 속도와 트래픽량이다.

서버끼리 사설 네트워크 구성해서 해당 구간으로는 실시간 동기화를 진행하고, 공인 네트워크로는 DB 커넥션만 되도록 구성하면 어느 정도 해결은 될 것 같다.

SQL 2016 AlwaysOn 에 추가 된 기능 중, 보조 영역을 "읽기 전용" 으로 구성하여 분산 처리하는 방식은 나~중에 시간 나면 해보자.